Information processing device, information processing system, and computer program

Abstract

To enable verification of compatibility of records in recording history relating to data.SOLUTION: An information processing device of the present disclosure includes: a reception unit that receives a verification request of compatibility for a verification object of a handling agreement record or a handling execution record relating to data handling; a search unit that searches a storage system storing at least one handling agreement record and at least one handling execution record on the basis of the verification request to acquire the handling agreement record or the handling execution record of the verification object, and a handling agreement record or a handling execution record related to the verification object; a period calculation unit that calculates at least one of an agreement period and a disagreement period on the basis of the acquired handling agreement record; and a verification unit that verifies the compatibility on the basis of at least one of the agreement period and the disagreement period, and the acquired handling execution record.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] An embodiment of the present invention relates to an information processing device, an information processing system, and a computer program. [Background technology]

[0002] The Act on the Protection of Personal Information (hereinafter referred to as the Personal Information Protection Act) requires that a personal information handling business operator obtain the prior consent of the individual, i.e., the owner of the personal data, before providing the personal data to a third party. Personal information handling business operators create a record of such consent and confirm whether or not such consent has been obtained when providing personal data to a third party.

[0003] In addition, in order to make it possible to trace the flow of personal data provision, when providing personal data to a third party, a record of the provision is required to be created and stored for a certain period of time. For example, a personal information handling entity records the provision of personal data together with the name of the owner, the owner's consent, the items of personal data, the name of the third party to whom the data was provided, and the like. In addition, for example, the third party to whom the personal data was provided, in other words, the user device of the personal data, confirms the name of the personal information handling entity that provided the data and the circumstances by which the personal information handling entity obtained the provided data, and records the fact that the personal data was received together with these. It is required to verify the consistency of such records, such as whether the records are correctly made, for example, whether consent is recorded before the provision of personal data is recorded. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent Publication No. 2021-48546 [Patent Document 2] International Publication No. 2021 / 124568 [Patent Document 3] JP 2020-98972 A [Patent Document 4] JP 2020-77347 A Summary of the Invention [Problem to be solved by the invention]

[0005] An embodiment of the present invention aims to be able to verify the integrity of records in a record history relating to data. [Means for solving the problem]

[0006] The information processing device of the present disclosure includes a receiving unit that receives a request for verifying consistency for a handling agreement record or a handling execution record regarding data handling, a search unit that performs a search on a storage system that stores at least one handling agreement record and at least one handling execution record based on the verification request, and acquires the handling agreement record or handling execution record to be verified and the handling agreement record and handling execution record related to the verification target, a period calculation unit that calculates at least one of the consent period and the non-consent period based on the acquired handling agreement record, and a verification unit that verifies the consistency based on at least one of the consent period and the non-consent period and the acquired handling execution record. [Brief description of the drawings]

[0007] [Figure 1] 1 is a block diagram showing an example of an information processing system according to an embodiment of the present invention; [Diagram 2] FIG. 13 is a diagram showing an example of a blockchain generated by processing according to the present embodiment. [Diagram 3] Figure continued from Figure 2. [Figure 4] 3 is a schematic flowchart of the overall process in this embodiment. [Diagram 5] Flowchart continuing from Figure 4. [Figure 6] FIG. 11 is a diagram for explaining another example of recording. [Figure 7] FIG. 1 is a block diagram of a verification device according to an embodiment of the present invention. [Figure 8]11 is a flowchart of an example of the operation of Verification Example 1. [Figure 9] A diagram showing how blockchain records are traced in the operation of Figure 8. [Figure 10] 13 is a flowchart of an example of the operation of Verification Example 2. [Figure 11] 13 is a flowchart of an example of the operation of Verification Example 3. [Figure 12] 13 is a flowchart showing an example of the operation of Verification Example 4. [Figure 13] 13 is a flowchart showing an example of the operation of Verification Example 5. [Figure 14] Flowchart continuing from Figure 13. [Figure 15] FIG. 2 is a block diagram showing an example of a hardware configuration according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0009] Fig. 1 is a block diagram showing an example of an information processing system according to an embodiment of the present invention. The information processing system according to this embodiment includes an information processing device 101 of a data related person, an information processing device 102 of a data handler, an information processing device 103 of a data user who is a third party who is neither a data related person nor a data handler, a blockchain system 104, and a verification device 105. The verification device 105 is an information processing device that verifies various records written in the blockchain system 104. In Fig. 1, the verification device 105 is shown as a device separate from the related person device 101, the handler device 102, and the user device 103, but may be the same device as at least one of the related person device 101, the handler device 102, and the user device 103.

[0010] For ease of explanation, hereinafter, the information processing device 101 of the data related party, the information processing device 102 of the data handler, and the third party's information processing device 103 will be respectively referred to as the related party device 101, the handler device 102, and the user device 103. Note that the related party device 101, the handler device 102, and the user device 103 are not limited to one device, and may be multiple devices.

[0011] In the information processing system of this embodiment, the data handler device 102 handles data of the data related party. Various handling methods are assumed, and as one of the handling methods, the data handler device 102 may transmit the data to the user device 103. In other words, the data handler may provide the data of the data related party to a third party, that is, a data user. For example, a personal information handling business (PDS business) that operates a PDS (Personal Data Store) that stores personal data is the data handler, and the PDS business may provide the personal data to a third party after obtaining the consent of the person or his / her agent. Note that, when the data handler does not collect data by itself, but acquires data from the data related party and provides it to the data user, the data handler is the primary recipient of the data, and the data user can be said to be the secondary recipient of the data.

[0012] It should be noted that the data related party, data handler, and data user are not limited to specific persons, and may be individuals or corporations. Furthermore, the data related party simply means a person associated with the data, and is not limited to a specific person. For example, the data related party may be a consenter who has agreed to the handling of data by the data handler, the data owner, or an agent of the data owner. Furthermore, the data related party may be a person identified by the data. For example, the data may indicate an address, gender, age, etc., and a person identified by the address, etc. may be the data related party. In this way, a person who consents to the data or is related to the data itself is assumed to be the data related party.

[0013] In addition, the type of data handled in the present embodiment and the method of transmitting and receiving the data are not limited to a specific type or method. For example, the target data may be personal data or industrial data.

[0014] In this embodiment, records of data are written to the blockchain provided by the blockchain system 104. The fact that consent to the handling of data has been given, that the handling has been carried out, that the data has become available as a result of the handling being carried out, and so on are written to the blockchain. For example, the fact that data has been provided to a third party, or that data has been acquired, received, analyzed, edited, or deleted, etc. may be written to the blockchain. In this embodiment, the acquisition of data means that the data handler acquires data from the data related party, and the receipt of data means that data is acquired from the data handler. However, acquisition and receipt may be unified into one or the other.

[0015] By keeping records of such data, the traceability of the data is ensured. For example, when data is provided to a third party, the data owner can confirm to which user the data was provided and the consent that was the basis for the provision. In addition, by managing the records using blockchain, the resistance to falsification of the records can be improved.

[0016] The blockchain is distributed and managed by information processing devices belonging to a P2P network related to the blockchain. The P2P network can also be said to be a network for forming a consensus on the contents to be written to the blocks of the blockchain. The related party device 101, the handler device 102, and the user device 103 may directly or indirectly write records related to data to the blockchain. That is, the related party device 101, the handler device 102, and the user device 103 may belong to the blockchain system 104, in other words, the P2P network related to the blockchain, and directly write to the blocks of the blockchain. Alternatively, the related party device 101, the handler device 102, and the user device 103 may not belong to the blockchain system 104, and may request an information processing device belonging to the blockchain system 104 to write to the blockchain. In other words, writing to the blockchain may be realized indirectly by sending the record to be written to an information processing device belonging to the blockchain.

[0017] Also, the related party device 101, the operator device 102, and the user device 103 may write to the block of the blockchain individually, or any one of them may write on behalf of the other. For example, the related party device 101 may write a record of consent to the block of the blockchain, and the operator device 102 may recognize the consent by monitoring the blockchain. Alternatively, the operator device 102 may obtain information indicating consent from the related party device 101 via a medium other than the blockchain, such as an email or a web page, and write a record of consent to the block of the blockchain based on the information.

[0018] In addition, the method of writing to the blockchain may use a known technique, and will not be described in detail in this embodiment. For example, a digital signature may be attached to the record to be written to indicate security, and the digital signature may be generated from the private key of the involved party device 101 or the private key of the handler device 102. In addition, since it is relatively difficult for the data involved party to safely manage the private key, there may be cases where the management of the private key is entrusted to the data handler. Therefore, the handler device 102 may generate a digital signature from the private key of the involved party device 101 instead of the involved party device 101 and transmit it to the involved party device 101.

[0019] The verification device 105 receives a request to verify the integrity of any record written in the blockchain from another device, searches for the record in the blockchain based on the verification request, and verifies the integrity of the record. The device that requests the verification request may be the related party device 101, the operator device 102, or the user device 103, or may be a device different from these. The verification device 105 does not belong to the blockchain system 104, and may request a search in the blockchain from an information processing device that belongs to the blockchain system 104. In FIG. 1, the verification device 105 is shown as a device separate from the related party device 101, the operator device 102, and the user device 103, but at least one of the related party device 101, the operator device 102, and the user device 103 may also serve as the verification device 105.

[0020] Note that the subjects involved in the information processing system are not limited to the subjects shown in Fig. 1, and other subjects may exist. For example, it is assumed that data of related parties is stored by a data administrator other than the data handler. In this case, the information processing device of the data administrator acquires data from the related party device 101, and the information processing device of the data administrator transmits the data to the user device 103 upon receiving an instruction from the handler device 102. In other words, the information processing device of the data administrator functions as a part of the handler device 102.

[0021] Fig. 2 is a diagram showing an example of a blockchain according to this embodiment. Fig. 3 is a diagram following Fig. 2. Below, the blockchains in Fig. 2 and Fig. 3 will be described, and then the process of generating the blockchain and the verification device 105 that verifies the records written in the blockchain will be described.

[0022] 2 and 3 show a blockchain including blocks 300 to 318. Records related to data, more specifically, records related to data handling, are written in the blockchain. The transaction IDs shown in blocks 300 to 318 are identifiers of the processes (transactions) indicated by each record. The BC user IDs shown in blocks 300 to 318 refer to user IDs in the blockchain and indicate the subject of the processes indicated by each record.

[0023] Block 300 shows a record (handling consent record) that a data related person with a BC user ID of "hanako" has consented to the handling of data acquisition by a data handler with a BC user ID of "dealer1". The effective date of the consent is after August 11, 2021. The type of handling is "acquisition", the type of record is "handling consent", and the status is "consent". "hanako" may be a real name or a pseudonym, but in this embodiment, it is assumed to be a pseudonym.

[0024] In this embodiment, the acquisition of data may include the storage of the acquired data. In other words, consenting to the acquisition of data means consenting to the storage of the acquired data. However, the acquisition of data and the storage of the acquired data may be defined separately as different types of handling.

[0025] Block 301 also shows a record of consent to handling. Block 301 shows that "hanako" has given consent to the provision of data, provided that the data source is "dealer1" and the data recipient is a data user with BC user ID "company1". This can also be considered consent to the receipt of data by "company1". In this record, the type of handling is "provision" and the type of record is "consent to handling". Similarly, block 302 shows that "hanako" has given consent to the provision of data, provided that the data source is "dealer1" and the data user is "company2". This can also be considered consent to the receipt of data by "company2". As with block 301, the type of handling is "provision" and the type of record is "consent to handling".

[0026] Blocks 303 and 304 indicate the same records (handling agreement records) as blocks 301 and 302, respectively, except for the different BC user IDs. The BC user IDs indicated in blocks 303 and 304 are changed according to the user (recipient). In other words, the BC user ID is a dedicated identifier for each user. The BC user ID is an identifier that uniquely corresponds to a combination of a related party and a user, and the data related party "hanako" is represented by a different identifier depending on the user. Even for the same user, the identifier differs depending on the related parties that are combined. A handling agreement record in which the BC user ID of the handling agreement record is rewritten to an identifier for the user corresponding to the related party is called a handling agreement re-record. For this reason, the type of record is "handling agreement re-record" in both blocks 303 and 304.

[0027] Blocks 305 and 306 indicate the same handling agreement record as block 300, except for the BC user ID. The BC user ID indicated in blocks 305 and 306 is an identifier that uniquely corresponds to a combination of a related person and a user, similar to blocks 303 and 304.

[0028] Block 307 is a transaction execution record related to data acquisition. The subject of the acquisition is "dealer1", and it shows that the data acquisition was performed on August 13, 2021. The record type is "transaction execution", and the transaction type is "acquisition". A transaction execution record with a transaction type of "acquisition" may be referred to as a transaction execution record related to acquisition or a transaction execution record of acquisition.

[0029] Block 308 is a transaction execution record related to the data provision by "dealer1". The record type is "dealing execution" and the transaction type is "provision". A transaction execution record with a transaction type of "provision" may be referred to as a transaction execution record related to provision or a transaction execution record of provision.

[0030] Block 309 is a usage record of data receipt by "campany1" corresponding to the data provision by "dealer1". The provider of the data can be known from the provider "dealer1" with the referenced provision consent ID=03. The record type is "handling execution" and the handling type is "receiving". A handling execution record with a handling type of "receiving" may be called a handling execution record related to receiving or a handling execution record of receiving.

[0031] Similarly, block 310 is a transaction execution record regarding the data provision by "dealer1", and block 311 is a usage record regarding the receipt of data by "campany2" corresponding to the data provision by "dealer1". Blocks 310 and 311 have the same contents as blocks 308 and 309, respectively, but differ from blocks 308 and 311 in the provision consent ID and acquisition consent ID, etc.

[0032] Block 312 is a transaction execution record indicating the use of data by "dealer1". The type of record is "transaction execution", and the type of transaction is "use". The person involved in the data is BC user ID "hanako" with the referenced consent ID=00. "dealer1" corresponds to a data handler (see Figure 1), but data can be used not only by data users, but also by data handlers. In other words, a data handler can also be a data user.

[0033] Block 313 shows a record (handling consent record) that a data related person with a BC user ID of "hanako" has revoked consent to data acquisition by a data handler "dealer1." In block 313, the status is "non-consent."

[0034] Blocks 314 and 315 each show the same handling agreement record as block 313, except for the different BC user IDs. The BC user IDs shown in blocks 314 and 315 change depending on the user, in other words, they are identifiers that uniquely correspond to the user. In blocks 314 and 315, the type of record is "handling agreement retry" and the status is "non-agreement."

[0035] Block 316 shows a record (handling consent record) that a data-related person with a BC user ID of "hanako" has revoked consent to the handling of data, that is, the provision of data from "dealer1" to "company1".

[0036] Block 317 shows the same handling agreement record as block 316, except for the different BC user ID. The BC user ID shown in block 317 changes depending on the user, and is an identifier that uniquely corresponds to the user. In block 317, the type of record is "handling agreement retry" and the status is "non-agreement."

[0037] Block 318 is a transaction execution record indicating the deletion of data by “dealer1.” The party concerned with the data is “hanako” indicated by the BC user ID in block 313 of the referenced agreement ID (transaction ID)=13.

[0038] In addition, the records written in the blockchain may include various information. For example, the handling agreement record regarding acquisition (e.g., block 300) may include where the handler obtains the data, in other words, the source of the data. In addition, the handling execution record regarding acquisition (e.g., block 307) may include where the handler obtains the data, in other words, the source of the data. In addition, for example, the handling agreement record regarding provision (e.g., block 308) may include data items indicating that all of the data may be provided, or which part of the data may be provided. In addition, in these handling agreement records and handling execution records, the data destination may be explicitly included, or, as described above, if the data destination can be determined by referring to other records, the data destination may be omitted.

[0039] Also, in the examples of Figures 2 and 3, one record is written in one block, but this is not necessarily one-to-one, and multiple records may be written in one block. For example, a handling consent record regarding acquisition and a handling consent record regarding provision may be written in one block. Also, multiple items of the same type may be written in one record. For example, multiple consents such as consent to acquisition and consent to provision may be included in one handling consent record. Alternatively, one handling consent record regarding acquisition may include consent to acquisition for each of multiple parties. Also, when multiple data are provided at once based on multiple consents, the handling execution record regarding data provision may include information indicated by multiple handling consent records regarding data provision.

[0040] Furthermore, as long as necessary information can be read from the block, the record may be written in any manner. For example, a part or the whole of the record may be included in the block as meta information.

[0041] In this way, by writing records in the blockchain, traceability can be ensured. Note that since the blocks of the blockchain can be used by any information processing device that belongs to the blockchain system (P2P network), confidentiality becomes an issue, but the blockchains in Figures 2 and 3 also have measures in place to ensure confidentiality. For example, in Figures 2 and 3, the BC user ID is indicated by an identifier (pseudonym) called "hanako," but if the identifier is unrelated to an actual individual's name, it is difficult to identify the individual. By using a technique such as pseudonymization, in which an individual's name is replaced with another character string, number, etc. based on a predetermined rule, it is possible to make it difficult to identify the individual.

[0042] In addition, various information may be added to the records written in the blockchain. For example, details of the data acquired, provided, etc. may be added. When the handler device 102 provides a part of the data passed from the related party device 101 to the user device 103, information that can recognize the part, such as the item name and the position in the data, may be recorded. In addition, when there is only one handler device 102, the BC user ID of the handler device 102 that provides the data may not be included in the record.

[0043] The process of generating the blockchain shown in Figures 2 and 3 will be described below. Fig. 4 is a schematic flowchart of the overall process in this embodiment, and Fig. 5 is a flowchart following Fig. 4.

[0044] As a premise, the entity that writes to the flock chain can change. For example, consent records are written by the data related parties, and handling records and usage records are written by the device of the entity that handled or used them (handler device, user device). However, it is also possible to request another device to write the record, and for the requested device to write the record. In the following explanation, the record to be written is described as the subject, and the entity that writes the record may be omitted, but as mentioned above, records can be written by any device.

[0045] In addition, the flow of the handled data may be performed before the record is written to the blockchain, or the order may be reversed, or it may be performed simultaneously. For example, the data may be received after the handling consent record for acquisition is written, or the handling consent record for acquisition may be written after the data is received together with the acquisition consent. In addition, when multiple data are handled in parallel, multiple copies of this flow are processed in parallel. This flow will be described in detail below.

[0046] An agreement is reached between the data party and the data handler that the data handler ("dealer1" in the example of FIG. 3) may acquire the data, and a handling agreement record relating to the agreement is written to the blockchain (S101). This generates block 300 in FIG. 2. Note that the processing of step S101 may be performed when the data handler device 102 receives data from the data party, or the handling agreement record may be generated first and written to the blockchain before such data is received. The latter case is assumed here.

[0047] Furthermore, the data related party agrees that the data may be provided to the first user, and a handling agreement record indicating that the data may be provided to the first user ("company1" in the example of FIG. 3) is written to the blockchain (S102). In this record, a normal identifier (a pseudonym "hanako" in the example of FIG. 3) is used as the BC user ID of the data related party. In addition, the data related party agrees that the data may be provided to the second user ("company2" in the example of FIG. 3), and a handling agreement record indicating that the data may be provided to the second user is written to the blockchain (S103). In this record, the normal identifier (pseudonym) is also used as the BC user ID of the data related party. Blocks 301 and 302 in FIG. 2 are generated by the processing of steps S102 and S103.

[0048] Furthermore, the identifier of the data related party in the handling consent record of block 301 ("hanako") is changed to a unique identifier for the first user ("g7h8i9" in the example of FIG. 3), and the changed handling consent record is rewritten to the blockchain (S104). When the rewritten handling consent record is to be distinguished from the handling consent record written with the normal BC user ID ("hanako"), the type of record is written as "handling consent re-recording" as a handling consent re-recording. In addition, the identifier of the data related party in the handling consent record of block 302 ("hanako") is changed to a unique identifier for the second user ("j1k2m3" in the example of FIG. 3), and the changed handling consent record is rewritten to the blockchain (S105). By the processing of steps S104 and S105, blocks 303 and 304 in FIG. 2 are generated.

[0049] The provision of data enables the data user to use the data. In the case of a transaction that allows the user to use the data when executed, such as data provision, the identifier of the data related party in the transaction agreement record is changed to an identifier that uniquely corresponds to the user, and then rewritten, as in steps S104 and S105 described above.

[0050] The identifier uniquely corresponding to the user can be determined appropriately. An identifier uniquely corresponding to the user may be obtained by converting a part or all of the normal BC user ID in accordance with a predetermined rule, or a unique identifier may be newly assigned to the user. For example, the normal BC user ID may be converted based on an individual key held by each third party (user). Also, an identifier uniquely corresponding to the user may be obtained by converting the normal BC user ID based on a combination of an individual key held by each third party and an individual key held by the data stakeholder. Also, the normal BC user ID may be encrypted.

[0051] Next, even with an identifier for each user, the record for the data related party represented by the identifier can be traced. For example, if it is not known that "g7h8i9" corresponds to "hanako" (only from block 300 to block 304), it is not possible to recognize whether the data related party "hanako" corresponding to "g7h8i9" has given consent to the acquisition of data to the data handler. Therefore, an information processing device that recognizes the correspondence between identifiers before and after the change, for example, the data handler device 102, detects a handling agreement record in which the data related party is represented by a normal identifier BC user ID ("hanako" in the example of FIG. 3) from the blockchain. The data handler device 102 changes the identifier "hanako" of the data related party in the detected handling agreement record to an identifier for the first user ("g7h8i9" in the example of FIG. 3), and re-records the changed handling agreement record in the blockchain (S106). This generates block 305 indicating the handling agreement re-recording for the handling agreement record in block 300. Block 305 allows even a user who knows only the BC user ID "g7h8i9" to recognize that the data stakeholder "hanako" corresponding to "g7h8i9" has consented to the acquisition of data by the data handler.

[0052] Similarly, the identifier of the data related party in the detected handling agreement record is changed to an identifier for the second user ("j1k2m3" in the example of FIG. 3) and re-recorded in the blockchain (S107). This generates block 306, which indicates the handling agreement re-recording for the handling agreement record in block 300.

[0053] The handler device 102 attempts to acquire data. In this case, the handler device 102 acquires the data after confirming based on the blockchain (block 300) that the data may be acquired (S108). A block 307 indicating a handling execution record regarding data acquisition is generated, including information indicating a handling agreement record (agreement ID=00). The sender of the data may be the related party device 101 or another information processing device.

[0054] After that, the administrator device 102 attempts to provide data to the first user. In this case, the administrator device 102 confirms based on the blockchain (block 301 or 303) that it is OK to provide the data to the first user, and then transmits the data to the user device 103 of the first user (S109). Meanwhile, the user device 103 of the first user receiving the data confirms based on the blockchain (blocks 303 and 305) that it is OK to receive the data, and then receives the data (S110).

[0055] The confirmation of whether the data can be provided and whether the data can be received may be made using a BC user ID corresponding to the user device 103 of the data recipient. In the example of FIG. 3, when data of "hanako" is to be provided to "company1", the BC user ID "g7h8i9" of "hanako" for "company1" is used as a key for detecting the handling consent record. This allows the detection of block 303 and block 305 in which the handling consent record of "g7h8i9" is written, and it is found that consent regarding the provision and acquisition has been made. Note that the confirmation that data may be provided to the first user and that the first user may receive the data may include a confirmation that the data handler may acquire data from the data related party (block 305).

[0056] The handler device 102 and the user device 103 may directly check whether the information can be provided and whether the information can be received by referring to the blockchain. Alternatively, the handler device 102 and the user device 103 may request other information processing devices belonging to the blockchain system 104 to determine whether the information can be provided and whether the information can be received. If multiple information processing devices belonging to the blockchain system 104 determine whether the information can be provided and whether the information can be received, there is an advantage in that transparency in the determination can be ensured.

[0057] Thereafter, a handling execution record regarding the data handler's provision of data to the first user is written to the blockchain, including information identifying the handling agreement record including the identifier for the first user (S111). This generates block 308 in Fig. 2. Also, a usage record regarding the first user's receipt of data is written to the blockchain, including information identifying the handling agreement record including the identifier for the first user (S112). This generates block 309 in Fig. 2.

[0058] In these handling execution records (block 308) and usage records (block 309), identifiers other than the identifier for the first user (such as ordinary identifiers) are excluded. This prevents a third party from matching the data to determine which related party the data belongs to. Block 308 includes transaction ID03 of the handling agreement record for provision, which includes the identifier "g7h8i9" for the first user, as the agreement ID. Meanwhile, block 309 includes transaction ID03 and ID05 of the handling agreement records for provision and acquisition, which include the identifier "g7h8i9" for the first user.

[0059] When the operator device 102 is to provide data to a second user, the same process as when the operator device 102 is to provide data to a first user is carried out.

[0060] More specifically, as shown in FIG. 5, the operator device 102 confirms based on the blockchain (block 302 or 304) that data may be provided to the second user, and then transmits the data to the user device 103 of the second user (S113). Meanwhile, the user device 103 of the second user receiving the data confirms based on the blockchain (blocks 304 and 306) that data may be received, and then receives the data (S114). Then, a handling execution record regarding the data provision to the second user is written to the blockchain, including information indicating a handling agreement record including an identifier for the second user (S115). This generates a block 310. Also, a usage record regarding the second user's data reception is written to the blockchain, including information indicating a handling agreement record including an identifier for the second user (S116). This generates a block 311.

[0061] The IDs indicating the handling consent records contained in blocks 310 and 311 all indicate handling consent records for the identifier "j1k2m3" for the second user. As a result, blocks 308 and 310 are both handling execution records related to provision, but since the users to which the data is provided are different, the provision consent IDs contained in each are different. Also, blocks 309 and 311 are both usage records related to receipt, but since the receiving users are different, the provision consent IDs and acquisition consent IDs contained in each are different.

[0062] The handler device 102 uses the data. For example, the handler device 102 generates a handling execution record and writes the handling execution record to the blockchain. This generates a block 312 (S117).

[0063] The data related party withdraws consent that the data handler ("dealer1" in the example of FIG. 3) may acquire the data, and the related party device 101, for example, writes a handling consent record related to the consent to the blockchain (S118). This generates block 313.

[0064] Next, consent can be traced even by identifiers for each user. An information processing device that recognizes the correspondence between identifiers before and after the change, for example, the data handler device 102, generates a data handling consent re-record by changing the identifier (normal identifier) ​​of the data related party in the data handling consent record (block 313) to an identifier for the first user. The generated data handling consent re-record is written to the blockchain (S119). In the example of FIG. 3, a record (data handling consent re-record) is generated in which "hanako" in block 313 is changed to the identifier "g7h8i9" for the first user. This generates block 314. This block 314 allows a user who only knows the BC user ID "g7h8i9" to recognize that the data related party corresponding to "g7h8i9" has revoked consent.

[0065] Similarly, for example, the data handler device 102 generates a handling agreement re-record by changing the identifier (normal identifier) ​​of the data related party in the handling agreement record (block 313) to an identifier for the second user ("j1k2m3" in the example of FIG. 3) (S120). The generated handling agreement re-record is written to the blockchain (same S120). This generates block 315 indicating the handling agreement re-record for the handling agreement record in block 313.

[0066] When consent to acquisition is revoked, if the corresponding consent to provision is not recorded in the blockchain, a handling consent record for revoking consent to provision is written in the blockchain by, for example, the related party device 101 or the handler device 102 (S121). This generates block 316.

[0067] As in the case of revoking acquisition, for example, the data handler device 102 generates a data handling agreement re-record in which the normal identifier in block 316 is changed to an identifier for the first user (S122). Each data handling agreement re-record is written to the blockchain (same S122). This generates block 317.

[0068] After confirming the withdrawal of consent (agreement to acquisition) by the data related party based on block 313, the data handler device 102 deletes the stored data (S123). The data handler device 102 generates a handling execution record regarding the data deletion, and the generated handling execution record includes information indicating the handling agreement record (agreement ID=13) (same S123). The generated handling execution record is written to the blockchain (same S123). This generates block 318.

[0069] In this way, when records are written to the blockchain, even if data is leaked, the disadvantage of information identifying the parties involved being leaked can be reduced by data matching, while consent to provision to third parties and the history of provision can be confirmed.

[0070] For example, the data related party can confirm whether the content of the consent is as intended by the data related party by reading the handling consent record written in the block on the blockchain using the BC user ID of the normal identifier as a key. In the example of Fig. 3, the related party device 101 can detect blocks 300, 301, 302, and 313 using "hanako" as a key. This makes it possible to confirm whether the consent to acquisition (consent to storage), the consent to provision to the first user, company1, and the consent to provision to the second user, company2, are valid.

[0071] Furthermore, at the time of step S112, the user device 103 of the first user can detect blocks 303 and 305 using the identifier "g7h8i9" for the first user as a key. This makes it possible to confirm that the received data was provided with consent and that the process of acquisition is clear. Furthermore, at the time of step S115, the user device 103 of the second user can detect blocks 304 and 306 using the identifier "j1k2m3" for the second user as a key, and can perform a similar confirmation.

[0072] In this way, traceability is ensured by generating a blockchain using the processes shown in Figures 4 and 5.

[0073] Furthermore, the first user cannot recognize that the identifier "j1k2m3" for the second user represents the same data related party as the identifier "g7h8i9" for the first user. Similarly, the second user cannot recognize that the identifier "g7h8i9" for the first user represents the same data related party as the identifier "j1k2m3" for the second user. Therefore, even if one of the first and second users leaks data, the other cannot identify that the data is "hanako" data by comparing the data. Therefore, the disadvantages caused by data leakage can be reduced.

[0074] Note that, depending on the system specifications, the generation of blocks 301 and 302 may be omitted, for example, when the data parties know the data user identifier and traceability can be ensured even with the data user identifier. In addition, when the generation of blocks 301 and 302 is omitted, an inquiry may be made to an information processing device that recognizes the correspondence between the normal identifier and the unique identifier for each user. This makes it possible to confirm the normal identifier or user identifier of the data parties who have given consent to data provision or data acquisition, etc.

[0075] In addition, after the related party device 101 agrees to the data provision, the consent to the data provision may be revoked. Therefore, it is preferable to be able to confirm that the consent to the data provision has not been revoked when providing data. In other words, when the related party device 101 revoks the consent to the data provision, a record of the revocation of the consent to the data provision is written in the blockchain. When providing data, the handler device 102 preferably searches the blockchain using the BC user ID of the related party device 101 as a key to determine whether the consent to the data provision has been revoked. In addition, when an expiration date is indicated in the consent to the data provision, it is preferable to confirm whether the expiration date indicated in the consent to the data provision has expired. In this way, it is preferable to confirm the validity of the consent to the data provision when providing data.

[0076] In the above, only dealer1 is described as a data handler, but there may be multiple handlers. In that case, the BC user ID of the data related party may be changed for each of the multiple data handlers. In addition, the BC user ID of the data related party may be changed for each combination of data handler and data user. For example, "g7h8i9" is used for the handling consent record of data provision from a data handler named dealer1 to a data user company1. An identifier other than "g7h8i9" is used for the handling consent record of data provision from another data handler named dealer2 to the data user company1. This can reduce the disadvantage caused by data leakage.

[0077] 2 and 3 are merely examples, and various records may be written in the blockchain. For example, records of usage other than receipt of data may be written, such as a record of a data user analyzing, editing, or deleting data. In addition, the item of the received data, the BC user ID of the data provider device 102 that provided the data, etc. may be recorded in the usage record related to receipt.

[0078] Figure 6 is a diagram for explaining another example of a record. Figure 6 shows three example blocks of records, all of which are excerpts from records written in the blockchain for explanatory purposes.

[0079] Block 501 describes the data provider and data recipient (the entity that obtained the data) as the data acquisition history. "Provider=company3" means that the data was actually sent to dealer1 by company3, not by the data related party "hanako". As described above, data may not be received from related party device 101, but may be received from another information processing device such as a data administrator. In such a case, as in block 501, the data provider (company3 in this example) may be included in the record and a record of the acquisition history may be generated.

[0080] In block 502, the provider is "dealer1" and the provider is "company1." The acquisition history by the provider "dealer1" is indicated by the acquisition history record in block 501 with acquisition history ID=100.

[0081] Block 503 is a block showing a handling execution record indicating that the handler device of "BC user ID=company1" received data. In block 503, "acquisition history ID=100" is shown as the basis for receiving the data. The acquisition history is the history of data acquisition by the data provider. "Provision consent ID=101" shown in block 503 indicates the handling consent record of block 502.

[0082] An acquisition history record may be generated for each data related party. If the acquisition history is the same for all data related parties, one common acquisition history record may be generated for all data related parties. Block 501 is an example in which one common acquisition history record is generated for all data related parties. If an acquisition history record is generated for each data related party, the BC user ID of the data related party may be included in the acquisition history record.

[0083] The following describes the verification device 105 that verifies the consistency of records written in the blockchain.

[0084] The consistency verification is performed based on the following rules 1 to 8 for the handling agreement record, handling execution record, and handling execution by the handler and user. In other words, the consistency verification verifies whether rules 1 to 8 are followed based on the records written in the blockchain. If the following rules 1 to 8 are followed when writing records related to the blockchain in Figures 2 and 3 described above, and when handling (acquisition, receipt, use, deletion, etc.) by the handler and user, no inconsistency will be detected in the consistency verification. Rules 1 to 8 are merely examples, and rules other than rules 1 to 8 may exist. Furthermore, all of rules 1 to 8 are not necessarily required, and at least one rule may be present. Furthermore, the content of each rule may be changed. Furthermore, part of the content included in each rule may be removed.

[0085] [Rule 1] The types of handling of the handling consent record are "acquisition (storage)" and "provision." In this embodiment, acquisition is defined as including storage, but acquisition and storage can be distinguished. In this case, the types of handling may be acquisition, storage, and provision. Consent to acquire data includes consent to the processor acquiring data as well as consent to the processor using data. The record of consent to acquisition includes items such as transaction ID, BC user ID, record type, type of processing, processor, status, and effective date. The record of consent to acquisition means consent to the processor acquiring data from the related party indicated by the BC user ID. The consent to data provision includes consent for the provider to provide data to the recipient, as well as consent for the recipient to use the data. The consent record for data provision includes items such as transaction ID, BC user ID, record type, handling type, provider, recipient, status, and effective date. The consent is valid from 00:00 on the effective date. The date that can be specified as the effective date is the day after the date and time of consent record.

[0086] [Rule 2] The types of handling consent re-recording shall be "acquisition" and "provision." The contents of the handling consent re-recording shall be the same as the handling consent record from which the handling consent re-recording was generated (the handling consent record corresponding to the handling consent re-recording), except for the transaction ID and BC user name.

[0087] [Rule 3] The types of handling of the handling execution record shall be "acquisition," "use," "provision," "receipt," and "deletion." Each transaction execution record for data acquisition, use, provision, and deletion includes the following items: transaction ID, BC user ID, record type, transaction type, consent ID, and transaction date. The data receipt handling execution record includes items such as transaction ID, BC user ID, record type, handling type, provision consent ID, acquisition consent ID, and handling date. The data acquisition is carried out based on the consent record for the data acquisition. The use of data is carried out based on the consent record of the data acquisition. The data handler in the consent record of the data acquisition can use the data. Or, the use of data is carried out based on the consent record of the data provision / contract re-recording. The recipient of the consent record of the data provision / contract re-recording can use the data. The execution of data provision and the execution of data receipt are carried out based on the re-recording of the consent for the processing of the data. Data deletion is performed based on the acquisition consent record where the data subject to deletion is listed in the data subject item and the status is non-consent. Alternatively, data deletion is performed based on the provision consent record where the data subject to deletion is provided to the data subject device and the status is non-consent.

[0088] [Rule 4] When writing a consent record for acquisition with a non-consent status, if the status of the consent record for the provision of the corresponding data is consent, a consent record for provision with a non-consent status is generated. Also, when writing a consent record for acquisition with a non-consent status, if there is a re-recording of consent for the provision of the corresponding data and the status is consent, a consent record for provision with a non-consent status is generated for the user identifier used in the consent record for processing. At this time, if multiple user identifiers are used in the consent record for processing, all user identifiers may be targeted.

[0089] [Rule 5] The data deletion is performed during the non-consent period immediately following the effective date of the handling consent record of the acquisition in which the status is non-consent, or the data deletion is performed during the non-consent period immediately following the effective date of the handling consent record of the provision in which the status is non-consent, when the provision destination is the data processor device.

[0090] [Rule 6] Processing based on multiple consents (acquisition, use, provision, receipt) takes place during a period in which all consent periods overlap. The use or provision of data requires consent for the processor to acquire or receive data, in addition to consent for the processor to use or provide the data.

[0091] [Rule 7] You cannot use, provide, or delete data that you have not acquired or received.

[0092] [Rule 8] The transaction date of the transaction execution record for the provision of data is the same as the transaction date of the transaction execution record for the receipt of said data.

[0093] Variations of Rules 1-8 or other rule examples are given below. After consent is revoked, the data may be suspended without being deleted. If the handler device 102 and the user device 103 do not use a common blockchain system, only one of the provision record or the receipt record may be verified. In Rules 1 to 8, the unit of the consent period is one day, but other units such as one hour, one week, or one month may also be used. The consent may be valid from the time the handling consent record is written to the blockchain. In this case, the recording date and time may be written in the handling consent record, and the recording date and time may also serve as the validity start date and time. The validity period may be determined by the order of the blocks indicating the records of consent to processing. In other words, the validity period may be the period from when a block indicating the record of consent is written to when a block indicating the record of revoking said consent is written. In this case, the consent record does not need to include the recording date and time and the validity date and time. When consent to acquisition is revoked, there is no need to generate and write a record of the revocation of consent to provision. In the case of withdrawal of consent to provision, if the provision destination is a user device, the data received by the user device may be deleted.

[0094] The verification device 105 will be described in detail below with reference to FIG. 7 is a block diagram of the verification device 105. The verification device 105 includes a receiving unit 111, a searching unit 112, a verification unit 113, a transmitting unit 115, and a storage unit 116. The verification unit 113 includes a period calculating unit 114.

[0095] The receiving unit 111 receives a request for verifying the consistency of records related to data handling (handling agreement records or handling execution records) (a consistency verification request) from the requesting device. The requesting device may be any device, such as the related party device 101, a management device that manages related party data, a device operated by an auditing agency for the handler, the user device 103, or a device operated by an auditing agency for the user, and is not limited to a specific device. The storage unit 116 stores identifier correspondence information, which is information including the correspondence between a BC user ID based on an identifier for a user and a BC user ID based on a normal identifier (pseudonym or real name). When the verification device 105 is a device other than the handler device (e.g., the user device 103), the identifier correspondence information may not be stored in the storage unit 116. Alternatively, when the verification device 105 is the user device 103, the identifier correspondence information may include only the correspondence between a user identifier corresponding to the user device 103 and a normal identifier.

[0096] The search unit 112 searches the storage system 104 (blockchain in this example) based on the conditions included in the verification request, and obtains the mutually related handling agreement record and handling execution record. That is, the search unit 112 sends a search request to the storage system 104, and receives the mutually related handling agreement record and the handling execution record that satisfy the conditions from the storage system 104 as a response. At this time, if the search unit 112 needs to identify a normal identifier from a user identifier, it uses the identifier correspondence information in the storage unit 116. The handling agreement record or the handling execution record is searched for based on the conditions specified in the verification request. As an example, the above conditions specify the values ​​of items included in the handling agreement record or the handling execution record.

[0097] The period calculation unit 114 calculates at least one of the consent period and non-consent period of the parties involved regarding the handling of data, based on the acquired handling agreement record.

[0098] The verification unit 113 verifies consistency based on at least one of the consent period and the non-consent period and the acquired handling execution record.

[0099] The transmitting unit 115 transmits information indicating the result of the verification of the consistency to the device that issued the request for verification.

[0100] The operation of the verification device 105 will be described in detail below using a concrete example.

[0101] [Verification example 1: Starting from the receipt handling execution record, verify with the normal (real name or pseudonymous) BC user ID] In this example, it is assumed that the verification device 105 is the operator device 102, but the verification device 105 may be any of a related person's device, an operator device, or a user device, or may be another information processing device. FIG. 8 is a flowchart of an example of the operation of the verification example 1. FIG. 9 is a diagram showing how the records of the blockchain are traced in the operation of FIG.

[0102] (Step S101) The receiving unit 111 receives a request for verifying the integrity of the transaction execution record of the receipt, as shown in block 309 of FIG.

[0103] <Obtain relevant handling agreement records and handling execution records> (Step S102) The search unit 112 searches for a handling agreement re-record related to the handling execution record of the block 309 to be verified. Since the transaction IDs of the handling agreement re-records referenced by the handling execution record of block 309 are ID03 (block 303) and ID05 (block 305), blocks 303 and 305 are obtained from the blockchain system. If either of the handling agreement re-records does not exist on the blockchain, the verification unit 113 detects an inconsistency (S114). Alternatively, it is possible for the verification unit 113 to detect an inconsistency if both handling agreement re-records do not exist on the blockchain, and not detect an inconsistency if either of the acquisition consent re-records exists.

[0104] The type of transaction in the transaction execution record in block 309 is "received" and the BC user ID is "company1". Therefore, the verification unit 113 checks whether the type of transaction is "provision" and the destination is "company1" in the transaction agreement re-recording in block 303. If at least one of the acquisition type and the destination does not exist or is different, the verification unit 113 detects an inconsistency. Since the provider in the transaction agreement re-recording of the provision in block 303 is "dealer1", the verification unit 113 checks whether the type of transaction is "acquisition" and the dealer is "dealer1" in the transaction agreement re-recording of the acquisition in block 305. If at least one of the transaction type and the dealer does not exist or is different, the verification unit 113 detects an inconsistency by determining that the corresponding transaction agreement re-recording does not exist (S114).

[0105] (Step S103) The search unit 112 searches for a handling agreement record corresponding to the handling agreement re-recording acquired in step S102. Here, the verification device 105 has identifier correspondence information including the correspondence between the BC user ID by the identifier for the user and the BC user ID of the normal identifier (pseudonym or real name). The search unit 112 obtains the BC user ID "hanako" of the corresponding normal identifier from the BC user ID "g7h8i9" of the block 303 using the identifier correspondence information. The search unit 112 searches for a handling agreement record in which the BC user ID is "hanako" and other items except the transaction ID and the record type match the block 303, and obtains the block 301. Similarly, the search unit 112 searches for a handling agreement record in which the BC user ID is "hanako" and other items except the transaction ID and the record type match the block 305, and obtains the block 300. The verification unit 113 detects an inconsistency if either of the handling agreement records does not exist. Alternatively, the verification unit 113 can detect an inconsistency if both handling agreement records do not exist on the blockchain, but not detect an inconsistency if either one of the acquisition agreement records exists.

[0106] (Step S104) The search unit 112 searches for a handling agreement record whose BC user ID, record type, handling type, and handler match the handling agreement record (block 301) and whose status is non-agreement, and obtains block 316.

[0107] (Step S105) The search unit 112 searches for a handling agreement record whose BC user ID, record type, handling type, and handler match the handling agreement record (block 300 ) and whose status is non-agreement, and obtains block 313 .

[0108] (Step S106) The search unit 112 searches for the acquisition handling execution record that references the acquisition handling agreement record (block 300 ) and obtains block 307 .

[0109] (Step S107) The search unit 112 searches for a transaction execution record of the provision whose provision agreement ID is ID03, the same as the transaction execution record of the receipt (block 309), and obtains block 308. If the transaction execution record of the provision does not exist, the verification unit 113 detects an inconsistency.

[0110] (Step S108) The search unit 112 searches for a deletion transaction execution record that references a transaction agreement record whose status is non-agreement (block 313 ), and obtains block 318 .

[0111] <Get consent and non-consent periods> (Step S109) The period calculation unit 114 calculates the consent period and non-consent period based on the handling agreement records acquired in the steps up to this point. In this example, since multiple handling agreement records were acquired, the period in which the periods of each agreement overlap is set as the consent period. More details are as follows.

[0112] Block 303 referred to by block 309 is a handling consent re-recording, and the handling consent record corresponding to this handling consent re-recording is block 301. The handling type of the handling consent record of block 301 is "provision", the status is "consent", and the effective date is "August 12, 2021". The handling consent record having the oldest effective date after this effective date, the handling type is "provision", and the status is "non-consent" is block 316. The effective date of block 316 is "August 20, 2021". Therefore, the consent period of "provision" is "August 12, 2021 to August 19, 2021".

[0113] Block 305 referenced by block 309 is a processing consent re-recording, and the processing consent record corresponding to this processing consent re-recording is block 300. The processing type of the processing consent record of block 300 is "acquisition", the status is "consent", and the effective date is "August 11, 2021". The processing consent record having the oldest effective date after this effective date, the processing type is "acquisition", and the status is "non-consent" is block 313. The effective date of block 313 is "August 20, 2021". The consent period for "acquisition" is from August 11, 2021 to August 19, 2021.

[0114] The consent period will be the period during which the consent period for "acquisition" and the consent period for "provision" overlap, which will be "August 12, 2021 to August 19, 2021."

[0115] <Determine consistency based on records and consent period> (Step S110) The verification unit 113 judges whether the transaction date of the transaction execution record to be verified is included in the agreement period. If the transaction date is not included in the synchronization period, the verification unit 113 detects an inconsistency (S114). If the transaction date is included in the agreement period, the process proceeds to the next step S111.

[0116] In this example, the transaction date of the transaction execution record to be verified is August 14, 2021 from block 309, and the agreement period is "August 12, 2021 to August 19, 2021." Since the transaction date is included in the agreement period, the verification unit 113 does not detect an inconsistency. Therefore, proceed to the next step S111.

[0117] (Step S111) The verification unit 113 judges whether the handling date of the handling execution record of the receipt of data is after the acquisition or receipt by the provider of the data. If the handling date is before the acquisition or receipt, an inconsistency is detected (S114). The verification unit 113 also judges whether the handling date of the acquisition or receipt is included in the consent period of "acquisition" or "provision", and detects an inconsistency if it is not included in the synchronization period of "acquisition" or "provision" (S114). If the handling date is after the acquisition or receipt and the handling date of the acquisition or receipt is included in the consent period of "acquisition" or "provision", the process proceeds to the next step S112.

[0118] In this example, the handling date of the receipt handling execution record (block 309) to be verified is August 14, 2021. The handling date of the acquisition handling execution record (block 307) is August 13, 2021. Therefore, since the receipt occurs after the acquisition and the acquisition is within the consent period of the "acquisition", the verification unit 113 does not detect an inconsistency. Therefore, proceed to the next step S112.

[0119] (Step S112) The verification unit 113 judges whether there is a deletion handling execution record between the acquisition handling execution record and the receipt handling execution record. If there is a deletion handling execution record, the verification unit 113 detects an inconsistency (S114), and if there is no deletion handling execution record, the verification unit 113 proceeds to step S113. In this example, the transaction date of the deletion transaction execution record (block 318) is August 20, 2021. Since there is no deletion transaction execution record between the acquisition transaction execution record and the receipt transaction execution record, no inconsistency is detected.

[0120] (Step S113) The verification unit 113 judges whether the handling date of the receipt handling execution record matches the handling date of the provision handling execution record corresponding to the receipt handling execution record. If they do not match, the verification unit 113 detects an inconsistency (S114). If they match, the verification unit 113 judges that no inconsistency exists in the handling execution record to be verified (S115).

[0121] In this example, the transaction execution record of receipt (block 309) and the transaction execution record of provision corresponding to the transaction execution record of receipt (block 308) both have a transaction date of August 14, 2021, and the two transaction dates match. Therefore, it is determined that there is no inconsistency in the transaction execution record to be verified (block 309) (S115).

[0122] If it is determined in step S115 that no inconsistency exists, the transmission unit 115 transmits information indicating that no inconsistency was detected to the requesting device as the verification result. If an inconsistency is detected in step S114, the transmission unit 115 transmits information indicating that an inconsistency was detected to the requesting device as the verification result. At this time, the verification result may include the reason why the inconsistency was detected.

[0123] [Verification example 2: Starting from the receipt handling execution record, verify with the BC user ID using the user identifier] In this example, it is assumed that the verification device 105 is the user device 103, but the verification device 105 may be any of a related person's device, an operator's device, or a user device, or may be any other information processing device. FIG. 10 is a flowchart of an example of the operation of Verification Example 2.

[0124] (Step S201) The receiving unit 111 receives a request for verifying the integrity of the transaction execution record of the receipt, as indicated in block 309 .

[0125] <Obtain relevant handling agreement records and handling execution records> (Step S202) The search unit 112 searches for the provision handling agreement re-recording and the acquisition handling execution re-recording related to the receipt handling execution record to be verified. This obtains blocks 303 and 305. If either of the handling agreement re-recordings does not exist on the blockchain, the verification unit 113 detects an inconsistency (S210). Alternatively, the verification unit 113 can detect an inconsistency if both handling agreement re-recordings do not exist on the blockchain, and not detect an inconsistency if either of the acquisition agreement re-recordings exists. This step is the same as step S102 in FIG. 8.

[0126] (Step S203) The search unit 112 searches for a handling agreement re-record whose BC user ID, record type, handling type, and handler match the handling agreement re-record provided (block 303 ), and obtains block 317 .

[0127] (Step S204) The search unit 112 searches for a handling agreement re-recording whose BC user ID, record type, handling type, and handler match the obtained handling agreement re-recording (block 305 ), and obtains block 314 .

[0128] (Step S205) A transaction execution record of the provision, in which the provision agreement ID is the same as the transaction execution record of the receipt (block 309), is searched for, and block 308 is obtained. If the transaction execution record of the provision does not exist, the verification unit 113 detects an inconsistency (S210).

[0129] (Step S206) <Get consent and non-consent periods> The period calculation unit 114 obtains the consent period and non-consent period based on the handling consent re-recordings acquired in the steps up to this point. In this example, since multiple handling consent re-recordings have been acquired, the period in which the periods of each handling consent re-recording overlap is set as the consent period.

[0130] Block 303 referenced by block 309 is a processing consent re-recording, with a processing type of "provision", a status of "consent", and an effective date of "August 12, 2021". The processing consent re-recording with the oldest effective date after this effective date, a processing type of "provision", and a status of "non-consent" is block 317. The effective date of block 317 is "August 20, 2021". Therefore, the consent period for "provision" is "August 12, 2021 to August 19, 2021".

[0131] Block 305 referenced by block 309 is a processing consent re-recording, with a processing type of "acquisition", a status of "consent", and an effective date of "August 11, 2021". The processing consent re-recording with the oldest effective date after this effective date, a processing type of "acquisition", and a status of "non-consent" is block 314. The effective date of block 314 is "August 20, 2021". Therefore, the consent period for "acquisition" is from August 11, 2021 to August 19, 2021. The period in which the consent period for "acquisition" and the consent period for "provision" overlap is the consent period, and the consent period is "August 12, 2021 to August 19, 2021".

[0132] <Determine consistency based on records and consent period> (Step S207) The verification unit 113 judges whether the transaction date of the transaction execution record to be verified is included in the agreement period. If the transaction date is not included in the agreement period, the verification unit 113 detects an inconsistency (S210). If the transaction date is included in the agreement period, the process proceeds to the next step S208.

[0133] In this example, the transaction date of the receipt transaction execution record indicated by the block 309 to be verified is August 14, 2021, which is included in the agreement period "August 12, 2021 to August 19, 2021", so no inconsistency is detected. Therefore, proceed to step S208.

[0134] (Step S208) The verification unit 113 judges whether the handling date of the receipt handling execution record matches the handling date of the provision handling execution record corresponding to the receipt handling execution record. If they do not match, the verification unit 113 detects an inconsistency. If they match, the verification unit 113 judges that no inconsistency exists (S115). In this example, it is judged that no inconsistency exists, similar to step S113 in FIG. 10.

[0135] [Verification example 3: Using usage records as a starting point, verification is performed based on the normal (real name or pseudonymous) BC user ID] In this example, it is assumed that the verification device 105 is the operator device 102, but the verification device 105 may be either a related party device or a user device, or may be another information processing device. FIG. 11 is a flowchart of an example of the operation of Verification Example 3.

[0136] (Step S301) The receiving unit 111 receives a request for verifying the integrity of the transaction execution record of the usage, as indicated by block 312 .

[0137] <Obtain relevant handling agreement records and handling execution records> (Step S302) The search unit 112 searches for the transaction agreement record and transaction execution record related to the transaction execution record to be verified. More specifically, the search unit 112 searches for the transaction agreement record referred to by the transaction execution record of the block 312, and obtains the block 300 from the blockchain system. The verification unit 113 detects an inconsistency if the transaction agreement record does not exist on the blockchain (S311). The transaction type of the transaction execution record of the block 312 is "use", and the BC user ID is "dealer1". Therefore, the verification unit 113 judges whether the transaction agreement record of the block 300 satisfies either the condition that the transaction type is "acquisition" and the dealer is "dealer1", or the condition that the transaction type is "provision" and the recipient is "dealer1". If neither condition is met, the verification unit 113 detects an inconsistency by determining that the corresponding transaction agreement record does not exist (S311). In this example, the type of transaction in the transaction agreement record referenced by block 312 is "acquisition" and the dealer is "dealer1", so the former condition is met.

[0138] (Step S303) The search unit 112 searches for a transaction execution record that references the transaction agreement record (block 300 ) and obtains block 307 .

[0139] (Step S304) The search unit 112 searches for a handling agreement record whose BC user ID, record type, handling type, and handler match the handling agreement record (block 300 ) and whose status is non-agreement, and obtains block 313 .

[0140] (Step S305) The search unit 112 searches for a deletion transaction execution record that references a transaction agreement record whose status is non-agreement (block 313 ), and obtains block 318 .

[0141] <Get consent and non-consent periods> The period calculation unit 114 obtains the consent period and non-consent period based on the handling agreement record acquired in the steps up to this point. (Step S306)

[0142] The handling consent record of block 300 referenced by block 312 to be verified has a handling type of "acquired", a status of "agreed", and an effective date of "August 11, 2021". The handling consent record with the oldest effective date after this effective date, a handling type of "acquired", and a status of "non-agreed" is block 313. The effective date of block 313 is "August 20, 2021". Therefore, the consent period is from August 11, 2021 to August 19, 2021.

[0143] <Determine consistency based on records and consent period> (Step S307) The verification unit 113 judges whether the transaction date of the transaction execution record to be verified is included in the agreement period. If the transaction date is not included in the agreement period, the verification unit 113 detects an inconsistency (S311). If the transaction date is included in the agreement period, the process proceeds to the next step S308.

[0144] In this example, the transaction date of the transaction execution record of the usage indicated by the block 312 to be verified is August 15, 2021, which is included in the consent period "August 12, 2021 to August 19, 2021." Therefore, no inconsistency is detected at this time, and the process proceeds to the next step S308.

[0145] (Step S308) The verification unit 113 judges whether the handling date of the handling execution record of the use is after the acquisition or receipt by the handler of the data related to the use. If the handling date is before the acquisition or receipt, the verification unit 113 detects an inconsistency (S311). The verification unit 113 also detects an inconsistency if the acquisition or receipt is not included in the agreement period (S311). On the other hand, if the handling date is after the acquisition or receipt and the acquisition or receipt is within the agreement period, the process proceeds to the next step S309.

[0146] In this example, the transaction date of the transaction execution record (block 312) of the usage to be verified is August 15, 2021. The transaction date of the transaction execution record (block 307) of the acquisition is August 13, 2021. Therefore, the receipt occurs after the acquisition, and the acquisition is within the agreement period. Therefore, no inconsistency is detected, and the process proceeds to the next step S309.

[0147] (Step S309) The verification unit 113 judges whether a transaction execution record of deletion exists between the transaction date of acquisition and the transaction execution record of receipt. If a transaction execution record of deletion exists, the verification unit 113 detects an inconsistency (S311). If a transaction execution record of deletion does not exist, the verification unit 113 judges that no inconsistency exists in the transaction execution record of use to be verified (S310).

[0148] In this example, the transaction date of the deletion transaction execution record (block 320) is August 20, 2021, and there is no deletion transaction execution record between the acquisition and receipt. Therefore, the verification unit 113 determines that there is no inconsistency in the transaction execution record to be verified (S310).

[0149] [Verification example 4: Verification based on normal (real name or pseudonymous) BC user ID, starting from deletion record] In this example, it is assumed that the verification device 105 is the operator device 102, but the verification device 105 may be any of a related person's device, an operator device, or a user device, or may be any other information processing device. FIG. 12 is a flowchart showing an example of the operation of Verification Example 4.

[0150] (Step S401) The receiving unit 111 receives a request for verifying the integrity of the deletion transaction execution record, as indicated by block 318 .

[0151] <Obtain relevant handling agreement records and handling execution records> (Step S402) The search unit 112 searches for a handling agreement record related to the handling execution record of the deletion to be verified. If the handling agreement record does not exist in the blockchain, the verification unit 113 detects an inconsistency (S410).

[0152] In this example, the transaction agreement record referenced by the transaction execution record in block 318 is searched for and block 313 is obtained from the blockchain system.

[0153] The type of the transaction in the transaction execution record in block 318 is "delete" and the BC user ID is "dealer1". Therefore, the verification unit 113 judges whether the transaction type in the transaction agreement record referred to by the block 313 is "acquire", the dealer is "dealer1", and the status is "non-agreement", or the transaction type is "receive", the delivery destination is "dealer1", and the status is "non-agreement". If either of the conditions is satisfied, the process proceeds to the next step S403. If neither of the conditions is satisfied, the verification unit 113 detects an inconsistency (S410). In this example, the former condition is satisfied, so the process proceeds to the next step S403. In this example, the type of transaction in the transaction agreement record referred to by the block 313 is "acquire", but the same applies to the case of "receive".

[0154] (Step S403) The search unit 112 searches for a handling agreement record whose BC user ID, record type, handling type, and handler match those of the handling agreement record (block 313) and whose status is "Agreed." From the handling agreement records (search results) found by the search, the handling agreement record (block 300) with the most recent effective date that is before the effective date of the handling agreement record (block 313) is obtained. Also, the handling agreement record with the oldest effective date that is after the effective date of the handling agreement record (block 313) is obtained (in this example, there is no corresponding handling agreement record).

[0155] (Step S404) The search unit 112 searches for transaction execution records that reference the transaction agreement record (block 300) and obtains block 307 from the blockchain.

[0156] <Get consent and non-consent periods> (Step S405) The period calculation unit 114 obtains the consent period and non-consent period based on the handling agreement record acquired in the steps up to this point. In this example, based on block 300 and block 313, the consent period is from August 11, 2021 to August 19, 2021, and the non-consent period is from August 20, 2021 to the time of verification. Note that if a block of a handling consent record indicating re-consent is written to the blockchain after the effective date of the handling consent record of the withdrawal of consent indicated by block 318, the non-consent period may be the period from the effective date of the handling consent record of the withdrawal of consent to the period before re-consent.

[0157] <Determine consistency based on records and consent period> (Step S406) The verification unit 113 judges whether the transaction date of the transaction execution record of the deletion to be verified is included in the non-agreement period. If the transaction date is not included in the non-agreement period, the verification unit 113 detects an inconsistency (S410). If the transaction date is included in the non-agreement period, the verification unit 113 does not detect an inconsistency and proceeds to the next step S407.

[0158] In this example, the transaction date of the transaction execution record of block 318 to be verified is August 20, 2021, and this transaction date falls within the non-consent period "the period from August 20, 2021 to the time of verification," so no inconsistency is detected and the process proceeds to the next step S407.

[0159] (Step S407) The verification unit 113 judges whether the handling date of the handling execution record of the deletion of data is after the acquisition or receipt by the handler of the data. If the handling date is before the acquisition or receipt, the verification unit 113 detects an inconsistency (S410). The verification unit 113 also judges whether the acquisition or receipt is included in the consent period, and if it is not included in the consent period, the verification unit 113 also detects an inconsistency (S410). If the handling date of the deletion is after the handling date of the acquisition or receipt and the acquisition or receipt is included in the consent period, the verification unit 113 does not detect an inconsistency and proceeds to the next step S408.

[0160] In this example, the transaction date of the transaction execution record (block 318) of the deletion to be verified is August 20, 2021. The transaction date of the transaction execution record (block 307) of the acquisition is August 13, 2021. Therefore, the deletion occurs after the acquisition. In addition, the acquisition is included in the consent period. Therefore, the verification unit 113 does not detect an inconsistency and proceeds to the next step S408.

[0161] (Step S408) The verification unit 113 judges whether there is another deletion handling execution record between the deletion handling execution record and the receipt (or acquisition) handling execution record. If there is another deletion handling execution record, the verification unit 113 detects an inconsistency (S410). If there is no other deletion handling execution record, the verification unit 113 judges that there is no inconsistency in the deletion handling execution record to be verified (S409).

[0162] In this example, the handling date of the deletion handling execution record (block 318) is August 20, 2021, and the handling date of the acquisition handling execution record (block 307) is August 13, 2021. Since there is no other deletion handling execution record between the acquisition handling execution record and the deletion handling execution record, the verification unit 113 determines that there is no inconsistency (S409).

[0163] [Verification example 5: Verification based on normal (real name or pseudonymous) BC user ID, starting from the withdrawal of consent to acquisition] In this example, it is assumed that the verification device 105 is the operator device 102, but similar to examples 1 to 4, the verification device 105 may be another device. Fig. 13 is a flowchart showing an example of the operation of Verification Example 5. Fig. 14 is a flowchart continuing from Fig. 13.

[0164] The receiving unit 111 receives a consistency verification request for a handling agreement re-recording (block 314) in which the status is non-agreement (step S501).

[0165] <Obtain relevant handling agreement records and handling execution records> (Step S502) The search unit 112 obtains a BC user ID of a corresponding normal identifier (real name or pseudonym) from the BC user ID based on the user's identifier in the handling agreement re-recording to be verified, using the identifier correspondence information. The search unit 112 searches for a handling agreement record that has the BC user ID of the obtained normal identifier and whose other items, except for the transaction ID and state, match the handling agreement re-recording.

[0166] In this example, the identifier correspondence information is used to obtain the BC user ID "hanako" of the corresponding normal identifier from the BC user ID "g7h8i9" in the handling agreement re-recording (block 314). A handling agreement record is searched for in which the BC user ID is "hanako" and other items except for the transaction ID and state match those in the handling agreement re-recording (block 314). As a result, blocks 300 and 313 are obtained.

[0167] (Step S503) The search unit 112 searches for a transaction execution record that references the transaction agreement record (block 300 ) and obtains block 307 .

[0168] (Step S504) The search unit 112 searches for a delete transaction execution record that references a transaction agreement record whose status is non-agreement (block 313), and obtains block 318. If the transaction execution record does not exist in the blockchain, an inconsistency is detected.

[0169] (Step S505) If consent to acquisition has been revoked (block 314), consent to provision must be revoked. A search is performed for a handling consent re-recording for provision that corresponds to the handling consent re-recording (block 314). The search unit 112 searches for a handling consent re-recording with the BC user ID "g7h8i9", the record type "handling consent re-recording", the handling type "provision", the provider is the dealer "dealer1" in block 314, and the effective date is earlier than the effective date in block 314. This obtains block 317.

[0170] The search unit 112 uses the identifier correspondence information to obtain the corresponding identifier "hanako" from the BC user ID "g7h8i9" in the handling agreement re-recording in block 317. The search unit 112 searches for a handling agreement record whose BC user ID is "hanako" and whose items other than the transaction ID match the handling agreement re-recording (block 317), and obtains block 316. If the handling agreement record and the handling agreement re-recording do not exist in the blockchain, the verification unit 113 detects an inconsistency (S511).

[0171] <Get consent and non-consent periods> (Step S506) The period calculation unit 114 obtains the consent period and non-consent period based on the handling agreement record acquired in the steps up to this point. Based on Block 300 and Block 313, the consent period is set to be from August 11, 2021 to August 19, 2021. The non-consent period is set to be "the period from August 20, 2021 to the time of verification."

[0172] <Detect inconsistencies from records and consent periods> (Step S507) If the blockchain contains a transaction execution record for the acquisition or receipt of data that falls within the consent period, proceed to step S508; if not, proceed to step S509. In this example, since there is a handling execution record (block 307) for obtaining the corresponding data, the process proceeds to step S508.

[0173] (Step S508) The verification unit 113 judges whether or not there is a deletion handling execution record during the non-consent period. If there is, no inconsistency is detected (S510), and if there is no record, the verification unit 113 detects an inconsistency (S511). In this example, no inconsistency is detected because a deletion transaction execution record (block 318) with a transaction date of "August 20, 2021" exists during the non-consent period "from August 20, 2021 to the time of verification."

[0174] (Step S509) The verification unit 113 judges whether or not there is a deletion handling execution record during the non-consent period. If there is, an inconsistency is detected (S511), and if there is no record, no inconsistency is detected (S510).

[0175] The examples of Figures 13 and 14 show a case where a consistency verification request for a handling consent re-recording (block 314) whose status is non-consent is received. Since the verification target uses a user identifier (in this example, "g7h8i9"), the verification was performed focusing on the identifier of the user. Similarly, when a consistency verification request for a handling consent record (block 313) whose status is non-consent is received, since the verification target uses a normal ID, verification is performed for all corresponding user identifiers, and a handling consent re-recording (block 314, block 315) having an identifier (in this example, "g7h8i9" and "j1k2m3") corresponding to the BC user ID "hanako" is searched for (Search 1). A provision handling consent record (block 316) whose status is non-consent that corresponds to the acquisition handling consent record (block 313) whose status is non-consent is searched for (Search 2). In addition, a provision handling consent re-recording (block 317) whose BC user ID is the user identifier and whose items other than the transaction ID are the same as the handling consent record (block 316) is searched for (Search 3). If no corresponding record exists in Search 1 to Search 3, the verification unit 113 may detect an inconsistency. In the example of the blockchain in Fig. 2 and Fig. 3, in Search 3, among the handling agreement records of the provision whose status is non-consent, there is no record in which the BC user ID is "j1k2m3", the provider is "dealer1", and the provider is "company2", so the verification unit 113 detects an inconsistency.

[0176] [Variation 1] In each of the above verification examples, the consent period and non-consent period were determined based on the effective date included in the handling consent record, but this is not limited to this method. For example, the handling consent record may be valid (the effective period may start) from the time the handling consent record is written. Alternatively, time information or timestamp information added to the handling consent record or block may be used. Alternatively, the order of blocks may be used. The consent period and non-consent period may be recorded in the state on the blockchain, and the recorded consent period and non-consent period may be obtained.

[0177] [Variation 2] In verifying consistency for the example record shown in Figure 6 above, the acquisition history ID is used instead of the acquisition agreement ID in the receipt record in the verification example described above, and an inconsistency is detected if the block indicated by the acquisition history ID does not exist.

[0178] [Variation 3] By referencing the handling agreement information in the handling execution record, it is possible to omit including content that overlaps with the handling agreement information in the handling execution record. Alternatively, it is not necessary to omit the overlapping content.

[0179] [Variation 4] The handling consent record and handling execution record may include detailed data items and usage purposes. Examples of data items include medical information, measurement results, blood test results, findings, etc. Examples of usage purposes may include business purposes, research purposes, etc., and may be more detailed. Data items and usage purposes may be hierarchical. For example, medical information may include measurement results, blood test results, findings. A study may include multiple studies (e.g., Study A, Study B). When searching for related handling consent records and handling execution results, search conditions may include data items and usage purposes. The range of data items and usage purposes of the corresponding handling consent record may be broader than the range of data items and usage purposes in the handling execution record. For example, the data items included in the handling execution record may be blood test results, and the data items included in the corresponding handling consent record may be medical information. More generally, in addition to searching for handling consent records or handling execution records that match the values ​​of items in the handling execution record or the values ​​of items specified in the search request, it is also possible to search for handling consent records or handling execution records whose item values ​​are included in the values ​​of the specified items.

[0180] [Variation 5] When the status of the handling agreement record X is "Agreement" and the handling agreement record Y with the status "No Agreement" is written to revoke the consent, the handling agreement record Y may refer to the handling agreement record X. When searching for related handling agreement records, the reference information may be used. For example, in the verification, the handling agreement record Y (first handling agreement record) referred to by the handling execution record may be obtained, and the handling agreement record X (second handling agreement record) referred to by the handling agreement record Y may be obtained to confirm the contents of the handling agreement record Y. The handling agreement record Y (first handling agreement record) may indicate the withdrawal of consent (status is "No Agreement"), and the handling agreement record X (second handling agreement record) may indicate consent (status is "Agreement"). In addition, when at least a part of the items of the handling execution record are the same as the handling agreement record Y or the item X of the handling agreement record, and the at least a part of the items are omitted in the handling execution record, the search unit 112 may specify the values ​​of at least a part of the omitted items by referring to the related handling agreement record Y or the handling agreement record X.

[0181] [Variation 6] In the flowcharts used to explain each of the verification examples described above, a handling agreement record or handling execution record with a non-agreement status was initially specified as the verification target, but other designation methods such as the following may also be used.

[0182] Specify the parties to be verified. When specifying the parties, some or all of them may be specified. If the handling execution record references a handling agreement record and the BC user ID of the party to be verified is omitted in the handling execution record, identify the BC user ID of the party to be verified from the handling agreement record to be referenced, and search for the handling agreement record of the party to be verified and for the corresponding BC user ID in the identifier correspondence information. Furthermore, search for handling execution records that reference the searched handling agreement record. Specify the handling agreement records with a non-agreement status among the searched handling agreement records and all the searched handling execution records as the verification targets.

[0183] [Variation 7] When searching, the search range (verification range) may be specified based on the creation time of the record or the block order. The verified range may be recorded, and the next verification may only cover the unverified range. For example, records up to a certain creation time may be recorded as the verified range, and records created after that time may be verified next. The verified range may be recorded based on the number of blocks from the first block, and the blocks from the next block onwards may be verified next.

[0184] [Variation 8] The handling agreement record or handling execution record may include the name of the data owner and the name of the third party to whom the data is provided, and this information may be made accessible from a normal ID.

[0185] In the above embodiment, the data is deleted after the withdrawal of consent is confirmed, but instead of deleting the data, the data may be suspended. In this case, by replacing "delete" in the description of this embodiment with "suspend use", the same processing as for deletion can be performed for "suspend use".

[0186] As described above, according to this embodiment, a handling agreement record regarding handling that allows a third party (user, etc.) to use data, such as a handling agreement record of provision, is written to the blockchain by changing the identifier of the related party from a normal identifier (real name or pseudonym) to an identifier dedicated to the user. That is, a handling agreement record that is a normal identifier (real name or pseudonym) before the related party's identifier is changed is detected, the related party's identifier of the detected handling agreement record is changed to an identifier for the user, and written as a handling agreement re-record. As a result, even if data is leaked from a third party (user, etc.), the acquirer of the leaked data cannot uniquely identify the data related party (e.g., the owner of the data), and it is possible to prevent the data related party from being identified. In addition, even if a person recognizes only one of the identifiers before and after the change, the process, history, etc. of the data provision can be confirmed without omission by sending a verification request to this information processing device based on the identifier.

[0187] According to this embodiment, it is possible to detect inconsistencies between the handling agreement record and the handling execution record. Furthermore, even if the identifier of the related party is changed to an identifier for the user, it is possible to verify the record by using the correspondence information of the identifier. Furthermore, by using the correspondence information, it is also possible to verify the existence of a handling agreement record corresponding to a handling agreement re-recording in which the identifier of the related party has been changed to an identifier for the user. Even if a person only recognizes one of the identifiers before and after the change, it is possible to detect inconsistencies between the handling agreement record and the handling execution record corresponding to that identifier by sending a verification request to this information processing device based on that identifier.

[0188] At least a part of the information processing devices (verification device, related party device, operator device, user device) in the above embodiments may be realized by a dedicated electronic circuit (i.e., hardware) such as an IC (Integrated Circuit) that implements a processor, memory, etc. Also, at least a part of the above embodiments may be realized by executing software (programs). For example, it is possible to realize the processing of the above embodiments by using a general-purpose computer device as basic hardware and having a processor such as a CPU mounted on the computer device execute a program.

[0189] For example, the computer can become the device of the above embodiment by reading out the dedicated software stored in a computer-readable storage medium. The type of storage medium is not particularly limited. Also, the computer can become the device of the above embodiment by installing the dedicated software downloaded via a communication network. In this way, the information processing by the software is specifically implemented using hardware resources.

[0190] 15 is a block diagram showing an example of a hardware configuration according to an embodiment of the present invention. An information processing device (verification device, related person device, operator device, user device) according to this embodiment includes a processor 41, a main memory device 42, an auxiliary memory device 43, a network interface 44, and a device interface 45, and can be realized as a computer device 4 in which these are connected via a bus 46.

[0191] The processor 41 is an electronic circuit including a computer control device and an arithmetic device. The processor 41 performs arithmetic processing based on data and programs input from each device in the internal configuration of the computer device 4, and outputs the arithmetic results and control signals to each device. Specifically, the processor 41 executes the OS (operating system) and applications of the computer device 4, and controls each device constituting the computer device 4. The processor 41 is not particularly limited as long as it can perform the above processing.

[0192] The main memory device 42 is a memory device that stores instructions executed by the processor 41 and various data, and information stored in the main memory device 42 is directly read by the processor 41. The auxiliary memory device 43 is a memory device other than the main memory device 42. These memory devices refer to any electronic components capable of storing electronic information, and may be either memories or storage. Memory may be volatile memory or nonvolatile memory, and either may be used.

[0193] The network interface 44 is an interface for connecting to the communication network 5 wirelessly or by wire. The network interface 44 may be one that conforms to an existing communication standard. The network interface 44 may exchange information with an external device 6A that is connected for communication via the communication network 5.

[0194] The device interface 45 is an interface such as a USB that directly connects to the external device 6B. The external device 6B may be an external storage medium or a storage device such as a database.

[0195] The external devices 6A and 6B may be output devices. The output devices may be, for example, display devices for displaying images, or devices for outputting sound, etc. Examples of the output devices include, but are not limited to, LCDs (Liquid Crystal Displays), CRTs (Cathode Ray Tubes), PDPs (Plasma Display Panels), and speakers.

[0196] The external devices 6A and 6B may be input devices. The input devices include devices such as a keyboard, a mouse, and a touch panel, and provide information input by these devices to the computer device 4. Signals from the input devices are output to the processor 41.

[0197] Although one embodiment of the present invention has been described above, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and transitions can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims.

[0198] [Note] [Item 1] A receiving unit that receives a request for verifying consistency of a handling agreement record or a handling execution record regarding the handling of data; a search unit that searches a storage system that stores at least one handling agreement record and at least one handling execution record based on the verification request, and acquires the handling agreement record or the handling execution record of the verification target, and the handling agreement record and the handling execution record related to the verification target; a period calculation unit that calculates at least one of a consent period and a non-consent period based on the acquired handling agreement record; A verification unit that verifies the consistency based on at least one of the consent period and the non-consent period and the acquired transaction execution record; [Item 2] The search unit searches for the handling agreement record or the handling execution record of the verification target, or the handling agreement record or the handling execution record related to the verification target, based on conditions specified in the verification request. Item 1. An information processing device according to item 1. [Item 3] The condition specifies the value of an item included in the handling agreement record or handling execution record of the verification target, or the value of an item included in the handling agreement record or handling execution record related to the verification target. Item 3. An information processing device according to item 2. [Item 4] The search unit searches for a handling agreement record or a handling execution record whose value of an item matches or is included in or includes the value of the item specified in the verification request. Item 2. The information processing device according to item 2 or 3. [Item 5] The search unit acquires a first handling agreement record referenced by the handling execution record, and acquires a second handling agreement record referenced by the first handling agreement record. 5. The information processing device according to any one of items 1 to 4. [Item 6] At least a portion of the items in the handling execution record are the same as the items in the first handling agreement record or the second handling agreement record, and the at least a portion of the items are omitted in the handling execution record; The search unit identifies values ​​of the at least some of the items by referring to the first handling agreement record or the second handling agreement record. Item 5. An information processing device according to item 5. [Item 7] The verification unit detects an inconsistency when at least one of the handling agreement record and the handling execution record related to the verification target cannot be acquired from the storage system. 7. The information processing device according to any one of items 1 to 6. [Item 8] one of the handling agreement records in the storage system is a handling agreement re-record including a second identifier obtained by converting a first identifier of a related party in the handling agreement record; The search unit identifies the first identifier corresponding to the second identifier included in the handling agreement record based on identifier correspondence information, and searches for the handling agreement record including the first identifier. 8. The information processing device according to any one of items 1 to 7. [Item 9] The storage system is a blockchain. 9. The information processing device according to any one of items 1 to 8. [Item 10] The period calculation unit calculates at least one of the consent period and the non-consent period based on the validity periods of one or more of the handling agreement records. 10. The information processing device according to any one of items 1 to 9. [Item 11] The period calculation unit determines the validity period based on time information included in the handling agreement record. 11. The information processing device according to any one of items 1 to 10. [Item 12] The storage system is a blockchain; The period calculation unit determines the consent period or the non-consent period based on the order of a plurality of blocks including the handling agreement record and the handling execution record. 10. The information processing device according to any one of items 1 to 9. [Item 13] The search unit acquires a plurality of handling agreement records related to the handling execution record, The period calculation unit calculates at least one of the consent period and the non-consent period based on a period during which the valid periods of the multiple handling agreement records overlap. 13. The information processing device according to any one of items 10 to 12. [Item 14] The type of transaction in the acquired transaction execution record is acquisition, The verification unit determines whether the transaction date of the transaction execution record, whose type of transaction is the acquisition, is included in the agreement period, and detects an inconsistency if the transaction date is not included in the agreement period. 14. The information processing device according to any one of items 1 to 13. [Item 15] The type of transaction in the transaction execution record obtained is provision or receipt, The verification unit determines whether the transaction date of the transaction execution record, in which the type of transaction is the provision or the receipt, is included in the agreement period, and detects an inconsistency if the transaction date is not included in the agreement period. 15. The information processing device according to any one of items 1 to 14. [Item 16] The verification unit detects an inconsistency if there is no transaction execution record in which the handler is the first party and the transaction type is acquisition, or the handler is the first party and the transaction type is receipt, before the transaction date of the transaction execution record in which the type of transaction is provision or receipt and the provider is a first party. 16. The information processing device according to any one of items 1 to 15. [Item 17] The verification unit detects an inconsistency if there is a transaction execution record in which the type of transaction is deletion during the period from the transaction date of the transaction execution record in which the type of transaction is acquisition or receipt and the handler or recipient is a first person to the transaction date of the transaction execution record in which the type of transaction is provision or receipt and the provider is the first person. 17. The information processing device according to any one of items 1 to 16. [Item 18] The verification unit is If there is no transaction execution record in which the transaction type is a receipt corresponding to the transaction execution record in which the transaction type is a provision, If the transaction date of the transaction execution record in which the transaction type is provision is different from the transaction date of the transaction execution record in which the transaction type is receipt corresponding to the transaction execution record in which the transaction type is provision, If there is no transaction execution record in which the transaction type is provision corresponding to the transaction execution record in which the transaction type is receipt, or When the handling date of the transaction execution record in which the type of transaction is receipt is different from the handling date of the transaction execution record in which the type of transaction is provision corresponding to the transaction execution record in which the type of transaction is receipt Detecting inconsistencies 18. The information processing device according to any one of items 1 to 17. [Item 19] receiving a request for verifying the integrity of a data handling agreement record or a data handling execution record; performing a search in a storage system storing at least one handling agreement record and at least one handling execution record based on the verification request, and obtaining the handling agreement record or the handling execution record to be verified, and the handling agreement record and the handling execution record related to the verification request; A step of calculating at least one of a consent period and a non-consent period based on the acquired handling consent record; verifying the consistency based on at least one of the consent period and the non-consent period and the acquired transaction execution record; A computer program for causing a computer to execute the above. [Item 20] A storage system for storing at least one data handling agreement record and at least one data handling execution record; A receiving unit that receives a request for verifying consistency of the handling agreement record or the handling execution record as a verification target; a search request unit that searches the storage system based on the verification request to obtain the handling agreement record or the handling execution record of the verification target and the handling agreement record and the handling execution record related to the verification request; a period calculation unit that calculates at least one of a consent period and a non-consent period based on the acquired handling agreement record; A verification unit that verifies the consistency based on at least one of the consent period and the non-consent period and the acquired transaction execution record; An information processing system comprising: [Item 21] The period calculation unit determines the validity period based on timestamp information included in the handling agreement record. An information processing device according to claims 1 to 9 and 13 to 18. [Item 22] The search unit transmits a search request to the storage system based on the verification request, and receives information on the consent period and the non-consent period from the storage system as a response. An information processing device according to any one of items 1 to 18 and 21. [Item 23] the verification request specifies a transaction execution record to be verified; The consent period is the period from the effective date of the first handling consent record referenced by the handling execution record to be verified to the effective date of the second handling consent record indicating the withdrawal of consent in the handling consent record. 23. The information processing device according to any one of items 1 to 18, 21 and 22. [Item 24] When the second handling agreement record indicating the withdrawal of the consent does not exist, the verification unit determines that the consent period is the period from the effective date of the first handling agreement record referred to by the handling execution record to be verified to the time when the verification unit performs the verification. Item 24. An information processing device according to item 23. [Item 25] The verification request specifies a consent withdrawal handling consent record to be verified; The verification unit sets, for the handling consent record of the consent withdrawal, a consent period from the effective date of the handling consent record indicating the consent that is the basis for the consent withdrawal to the effective date of the handling consent record of the consent withdrawal, The verification unit determines a non-consent period to be a period from the effective date of the handling agreement record of the consent withdrawal to the date before the handling agreement record indicating re-consent. The information processing device according to any one of items 1 to 18 and 21 to 24. [Item 26] When the handling consent record indicating the second consent does not exist, the verification unit sets the non-consent period to the period from the effective date of the handling consent record of the previous consent withdrawal to the time when the verification unit performs the verification. Item 26. An information processing device according to item 25. [Item 27] The verification unit detects an inconsistency when the transaction date of the transaction execution record in which the type of transaction is deletion is not included in the non-agreement period. An information processing device according to any one of items 1 to 18 and 21 to 26. [Item 28] The verification unit detects an inconsistency when the transaction date of the transaction execution record in which the transaction type is deletion is not after the transaction date of the transaction execution record of the acquisition or receipt of the data related to the deletion. An information processing device according to any one of items 1 to 18 and 21 to 27. [Item 29] The verification unit detects an inconsistency if there is another transaction execution record whose type of transaction is deletion between the transaction execution record whose type of transaction is acquisition or receipt and the transaction execution record whose type of transaction is deletion. The information processing device according to any one of items 1 to 18 and 21 to 28. [Item 30] The verification unit detects an inconsistency when a transaction execution record of a transaction type of acquisition or receipt, the transaction type of which includes a transaction date in the agreement period, exists for a transaction agreement record indicating a withdrawal of consent, and a transaction execution record of a transaction type of deletion, the transaction type of which includes a transaction date in the non-agreement period, does not exist. An information processing device according to any one of items 1 to 18 and 21 to 29. [Item 31] The verification unit detects an inconsistency when, for a handling agreement record indicating the withdrawal of consent, there is no handling execution record of a handling type of acquisition or receipt whose handling date is included in the consent period, and there is a handling execution record of a handling type of deletion whose handling date is included in the non-consent period. An information processing device according to any one of items 1 to 18 and 21 to 30. [Explanation of symbols]

[0199] 101 Personnel Equipment 102 Handler Equipment 103 User equipment 104 Blockchain system (memory system) 105 Verification device (information processing device) 111 Receiving unit 112 Search Department 113 Verification Department 114 Period Calculation Section 115 Transmitter 116 Memory section 41 Processors 42 Main storage 43 Auxiliary storage device 44 Network Interface 45 Device Interfaces 46 Bus

Claims

1. A receiving unit that receives a request for verifying consistency of a handling agreement record or a handling execution record regarding the handling of data; a search unit that searches a storage system that stores at least one handling agreement record and at least one handling execution record based on the verification request, and acquires the handling agreement record or the handling execution record of the verification target, and the handling agreement record and the handling execution record related to the verification target; a period calculation unit that calculates at least one of a consent period and a non-consent period based on the acquired handling agreement record; A verification unit that verifies the consistency based on at least one of the consent period and the non-consent period and the acquired transaction execution record, one of the handling agreement records in the storage system is a handling agreement re-record including a second identifier obtained by converting a first identifier of a related party in the handling agreement record; The search unit identifies the first identifier corresponding to the second identifier included in the handling agreement record based on identifier correspondence information, and searches for the handling agreement record including the first identifier. Information processing device.

2. The search unit searches for the handling agreement record or the handling execution record of the verification target, or the handling agreement record or the handling execution record related to the verification target, based on conditions specified in the verification request. The information processing device according to claim 1 .

3. The condition specifies the value of an item included in the handling agreement record or handling execution record of the verification target, or the value of an item included in the handling agreement record or handling execution record related to the verification target. The information processing device according to claim 2 .

4. The search unit searches for a handling agreement record or a handling execution record whose value of an item matches or is included in or includes the value of the item specified in the verification request.

4. The information processing device according to claim 2 or 3.

5. The search unit acquires a first handling agreement record to which the handling execution record refers, and acquires a second handling agreement record to which the first handling execution record refers. The information processing device according to any one of claims 1 to 4.

6. At least a portion of the items in the handling execution record are the same as the items in the first handling agreement record or the second handling agreement record, and the at least a portion of the items are omitted in the handling execution record; The search unit identifies values ​​of the at least some of the items by referring to the first handling agreement record or the second handling agreement record. The information processing device according to claim 5 .

7. The verification unit detects an inconsistency when at least one of the handling agreement record and the handling execution record related to the verification target cannot be acquired from the storage system. The information processing device according to any one of claims 1 to 6.

8. The storage system is a blockchain. The information processing device according to any one of claims 1 to 7.

9. The period calculation unit calculates at least one of the consent period and the non-consent period based on the validity periods of one or more of the handling agreement records. The information processing device according to any one of claims 1 to 8.

10. The period calculation unit determines the validity period based on time information included in the handling agreement record. The information processing device according to claim 9.

11. The storage system is a blockchain; The period calculation unit determines the consent period or the non-consent period based on the order of a plurality of blocks including the handling agreement record and the handling execution record. The information processing device according to any one of claims 1 to 8.

12. The search unit acquires a plurality of handling agreement records related to the handling execution record, The period calculation unit calculates at least one of the consent period and the non-consent period based on a period during which the valid periods of the multiple handling agreement records overlap. The information processing device according to claim 9 or 10.

13. The type of transaction in the acquired transaction execution record is acquisition, The verification unit determines whether the transaction date of the transaction execution record, whose type of transaction is the acquisition, is included in the agreement period, and detects an inconsistency if the transaction date is not included in the agreement period. The information processing device according to any one of claims 1 to 12.

14. The type of transaction in the transaction execution record obtained is provision or receipt, The verification unit determines whether the transaction date of the transaction execution record, in which the type of transaction is the provision or the receipt, is included in the agreement period, and detects an inconsistency if the transaction date is not included in the agreement period. The information processing device according to any one of claims 1 to 13.

15. The verification unit detects an inconsistency if there is no transaction execution record in which the handler is the first party and the transaction type is acquisition, or the handler is the first party and the transaction type is receipt, before the transaction date of the transaction execution record in which the type of transaction is provision or receipt and the provider is the first party. The information processing device according to any one of claims 1 to 14.

16. The verification unit detects an inconsistency if a handling execution record in which the type of handling is deletion exists during the period from the handling date of the handling execution record in which the type of handling is acquisition or receipt and the handler or recipient is the first person to the handling date of the handling execution record in which the type of handling is provision or receipt and the provider is the first person. The information processing device according to any one of claims 1 to 15.

17. The verification unit is If there is no transaction execution record in which the transaction type is a receipt corresponding to the transaction execution record in which the transaction type is a provision, If the transaction date of the transaction execution record in which the transaction type is provision is different from the transaction date of the transaction execution record in which the transaction type is receipt corresponding to the transaction execution record in which the transaction type is provision, If there is no transaction execution record in which the transaction type is provision corresponding to the transaction execution record in which the transaction type is receipt, or When the handling date of the transaction execution record in which the type of transaction is receipt is different from the handling date of the transaction execution record in which the type of transaction is provision corresponding to the transaction execution record in which the type of transaction is receipt Detecting inconsistencies The information processing device according to any one of claims 1 to 16.

18. A first step of receiving a request for verifying the integrity of a data handling agreement record or a data handling execution record; a second step of searching a storage system that stores at least one handling agreement record and at least one handling execution record based on the verification request, and obtaining the handling agreement record or the handling execution record of the verification target, and the handling agreement record and the handling execution record related to the verification target; A third step of calculating at least one of a consent period and a non-consent period based on the acquired handling consent record; A fourth step of verifying the consistency based on at least one of the consent period and the non-consent period and the acquired transaction execution record; Run the following on your computer: one of the handling agreement records in the storage system is a handling agreement re-record including a second identifier obtained by converting a first identifier of a related party in the handling agreement record; The second step is to identify the first identifier corresponding to the second identifier included in the handling agreement record based on identifier correspondence information, and to search for the handling agreement record including the first identifier. Computer program.

19. A storage system for storing at least one handling agreement record and at least one handling execution record regarding handling of data; A receiving unit that receives a request for verifying consistency of the handling agreement record or the handling execution record as a verification target; a search request unit that searches the storage system based on the verification request to obtain the handling agreement record or the handling execution record of the verification target and the handling agreement record and the handling execution record related to the verification target; a period calculation unit that calculates at least one of a consent period and a non-consent period based on the acquired handling agreement record; A verification unit that verifies the consistency based on at least one of the consent period and the non-consent period and the acquired transaction execution record; Equipped with one of the handling agreement records in the storage system is a handling agreement re-record including a second identifier obtained by converting a first identifier of a related party in the handling agreement record; The search request unit identifies the first identifier corresponding to the second identifier included in the handling agreement record based on identifier correspondence information, and searches for the handling agreement record including the first identifier. Information processing system.

Images