Information processing device, information processing method, and computer program

Abstract

To allow for preservation of various records while preventing leakage of relations between persons concerned and third persons.SOLUTION: An information processing apparatus of an embodiment comprises: a processing unit which identifies a first consent record including both an identifier for a first operator which identifies a person concerned and is exclusively assigned to the first operator, and consent of the person concerned for executing a first operation on data of the person concerned by the first operator and detects a person-concerned identifier corresponding to the identifier for the first operator included in the first consent record on the basis of correspondence data; and a retrieval unit which retrieves a second consent record including consent of the person concerned for executing a second operation on the data by a second operator, from a first storage system, on the basis of the person-concerned identifier. The processing unit generates an audit record including a record identifier of the first consent record and information about presence or absence of the second consent record on the basis of a result of the retrieval for the second consent record.SELECTED DRAWING: Figure 9

Description

Technical Field

[0001] This embodiment relates to an information processing apparatus, an information processing method, and a computer program.

Background Art

[0002] According to the Act on the Protection of Personal Information (hereinafter referred to as the Personal Information Protection Act), personal information handling businesses are required to obtain consent from the individual, that is, the owner of the personal data, in advance regarding the purpose of use, provision of personal data to a third party, and receipt from a third party, when obtaining and using personal information that requires special consideration. For example, a personal information handling business creates a record regarding the consent, and when executing a process that requires the consent of the owner, confirms the presence or absence of consent based on the record.

[0003] In order to make the flow of personal data provision traceable, when a personal information handling business provides personal data to a third party, it is required to create a record regarding the provision and store it for a certain period. For example, a personal information handling business records the provision of personal data together with the name of the owner, the consent of the owner, the items of personal data, the name of the third party to which it is provided, etc. In addition, a personal information handling business that is the third party to which personal data has been provided is required to confirm the process by which the personal data provided by the original personal information handling business was obtained, and create a record regarding the receipt of the personal data and store it for a certain period. For example, a third party to which personal data has been provided, in other words, a business that becomes the user of the personal data, confirms the name of the original personal information handling business and the process by which the original personal information handling business obtained the provided personal data, and records the receipt of the personal data together with the confirmed information.

[0004] To make it possible to verify the processing performed on personal data, in addition to records of provision (provision records) and receipt (receipt records), it is common practice for personal data handlers to create and retain for a certain period records of acquisition (acquisition records), generation (e.g., data generation by processing personal data) (generation records), and deletion (deletion records). These records are collectively referred to as processing records. Acquisition means obtaining personal data from the owner of the personal data or their agent (primary acquisition), and receipt means obtaining personal data from a person who has obtained personal data from an individual or agent (secondary acquisition). However, acquisition and receipt may be unified into one or the other, or other expressions may be used.

[0005] When personal data is provided to multiple third parties, in order to mitigate the disadvantages of data breaches (such as cross-referencing leaked personal data with other data) while still allowing verification of the owner's consent to the provision to third parties and the history of provision to third parties, for example, the owner's identifier included in the consent record is changed to a different identifier that uniquely corresponds to each third party before being stored. If both the pre- and post-change consent records are stored, anyone with access to both sets of consent records can deduce from the matching items in the consent records that the set of identifiers before and after the change corresponds to a set of users (owners) who consented to the provision to a particular third party. This could lead to the leakage of the correspondence table of identifiers before and after the change. Furthermore, storing both the pre- and post-change consent records puts a strain on the storage system capacity. [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 2022-074414 [Overview of the project] [Problems that the invention aims to solve]

[0007] This embodiment provides an information processing device, an information processing method, and a computer program that enable the storage of various records while preventing the leakage of information about relationships between individuals and other related parties and third parties. [Means for solving the problem]

[0008] The information processing apparatus according to this embodiment includes a processing unit that, from records held in a first storage system which holds at least one of records relating to the handling of data of a party concerned and records relating to the consent of the party concerned to the handling of said data, identifies a first consent record that includes a first business identifier that identifies the party concerned and is exclusively assigned to the first business operator, and the party concerned's consent for the first business operator to perform a first handling on the party concerned's data; a party concerned identifier that identifies the party concerned and has a value different from the first business operator identifier, and the first business operator identifier, based on corresponding data that associates the party concerned and the first business operator identifier; and a search unit that, based on the party concerned identifier, searches the first storage system for a second consent record that includes the party concerned's consent for the second business operator to perform a second handling on the data. The first handling and the second handling are related in such a way that the first business operator can perform the first handling on the data when the second business operator performs the second handling on the data. The processing unit generates an audit record to be stored in the first storage system, which includes a record identifier that identifies the first consent record and information regarding the existence of the second consent record, based on the search results of the second consent record. [Brief explanation of the drawing]

[0009] [Figure 1] A block diagram showing an example of a data management system, which is an information processing system according to one embodiment of the present invention. [Figure 2] A diagram illustrating an example of a blockchain according to this embodiment. [Figure 3] Figure 2 follows this one. [Figure 4]Schematic flowchart of the overall process in this embodiment. [Figure 5] Flowchart following FIG. 4. [Figure 6] Diagram showing the extraction of the audit record blocks in FIGS. 2 and 3. [Figure 7] Diagram showing an excerpt of the block shown in FIG. 2 for explanation. [Figure 8] Diagram for explaining another example of a record. [Figure 9] Block diagram of the verification / audit device. [Figure 10] Flowchart of an example of the operation of Verification Example 1. [Figure 11] Diagram showing how to trace the blockchain record in the operation of FIG. 10. [Figure 12] Flowchart of an example of the operation of Verification Example 2. [Figure 13] Flowchart showing an example of the operation of Verification Example 3. [Figure 14] Flowchart following FIG. 13. [Figure 15] Flowchart of an example of the operation of the verification / audit device. [Figure 16] Diagram showing an example of a data access log. [Figure 17] Diagram showing an example of a communication log. <00​​​​​​​​​​​​​​​​​​​​​​​​ The information processing system according to this embodiment includes a stakeholder device 501 which is an information processing device of a stakeholder (e.g., the owner of data) of data, a data management device 101 which is an information processing device of a data handler (a second business operator), a user device 701 which is an information processing device of a data user (a first business operator) who is a third party that is neither a data stakeholder nor a data handler, a first storage system 201 (in this example, a blockchain system), and a verification / audit device 1. The verification / audit device 1 is an information processing device that performs verification on various records written in the blockchain system 201 and generates audit records and the like. A block diagram of the verification / audit device 1 is shown in FIG. 9 described later.

[0013] In FIG. 1, the verification / audit device 1 is shown as a device separate from the stakeholder device 501, the data management device 101, and the user device 701, but it may be the same device as at least any one of the stakeholder device 501, the data management device 101, and the user device 701.

[0014] The data management device 101 is connected to a second storage system 601 that stores logs of various operations performed by the data management device 101 (data access logs, communication logs, authentication logs, etc., as described later). The data management device 101 is equipped with a user identifier correspondence table 91 (hereinafter referred to as the correspondence table 91 or correspondence data), as described later. Note that the related party device 501, the data management device 101, and the user device 701 are not limited to one unit, but may be multiple units. In the information processing system of this embodiment, the data management device 101 handles the data (personal data) of data related parties (data owners). Various handling methods are envisioned, but one such handling method is that the data management device 101 can transmit the data to the user device 701. In other words, a data handler can provide the data of a data related party to a third-party data user. For example, a personal information handling business operator (PDS operator) that operates a PDS (Personal Data Store) that stores personal data is a data handler, and it is conceivable that the PDS operator provides personal data to a third party after obtaining the consent of the individual or their representative. When a data handler obtains data from a data-related party and provides it to a data user, the data handler is the primary recipient of the data, and the data user can be considered the secondary recipient. It should be noted that data-related parties, data handlers, and data users are not limited to specific entities; they can be individuals or corporations. Furthermore, a data-related party simply refers to anyone associated with the data, and is not limited to specific individuals. For example, a data-related party could be a person who has consented to the handling of their data by the data handler, the data holder, or an agent of the holder. A data-related party could also be a person identified by the data. For example, if the data indicates address, gender, age, etc., then the person identified by that address, etc., could be considered a data-related party. Thus, anyone who has consented to the data, or who is related to the data itself, is generally considered a data-related party.

[0015] Furthermore, the types of data handled in this embodiment, as well as the methods for sending and receiving data, are not limited to any particular type or method. For example, the data in question may be personal data or industrial data.

[0016] Furthermore, in this embodiment, records of data are written to the blockchain provided by the blockchain system 201. Records such as consent being given for handling data, the handling being performed, and the data becoming available as a result of the handling being performed are written to the blockchain. For example, consent being given for the provision of data, data being provided to a third party, or data acquisition, receipt, analysis, editing, or deletion may be written to the blockchain. In this embodiment, data acquisition means that a data handler obtains data from a data party, and data receipt means that a data user obtains data from a data handler, but the meaning is not limited to this. Acquisition and receipt may be unified into one or the other.

[0017] By keeping records of such data, data traceability is ensured. For example, if data is provided to a third party, data stakeholders can verify to which user the data was provided and the consent that formed the basis for the provision. Furthermore, by managing these records using blockchain technology, resistance to tampering with those records can be improved.

[0018] The blockchain is managed in a distributed manner across information processing devices belonging to a P2P network related to the blockchain. This P2P network can also be described as a network for reaching consensus on the content to be written to the blockchain blocks. The participant device 501, the data management device 101, and the user device 701 only need to be able to write records related to data to the blockchain directly or indirectly. That is, the participant device 501, the data management device 101, and the user device 701 may belong to the blockchain system 201, or in other words, the P2P network related to the blockchain, and directly write to the blockchain blocks. Alternatively, the participant device 501, the data management device 101, and the user device 701 may not belong to the blockchain system 201 and may request information processing devices belonging to the blockchain system 201 to write to the blockchain. In other words, writing to the blockchain can be achieved indirectly by sending the record to be written to an information processing device belonging to the blockchain.

[0019] Furthermore, the stakeholders' device 501, the data management device 101, and the user device 701 may individually write to blocks on the blockchain, or any one of them may write on behalf of the others. For example, the stakeholders' device 501 may write a record of consent to a block on the blockchain, and the data management device 101 may recognize the consent by monitoring the blockchain. Alternatively, the data management device 101 may obtain information indicating consent from the stakeholders' device 501 via a medium other than the blockchain, such as email or a web page, and write a record of consent to a block on the blockchain based on that information.

[0020] The method for writing to the blockchain can be any known technology and will not be described in detail in this embodiment. For example, a digital signature may be attached to the record being written to demonstrate security, and this digital signature may be generated from the private key of the participant device 501 or from the private key of the data management device 101. Furthermore, since it is relatively difficult for data participants to securely manage private keys, the management of private keys may be entrusted to the data handler. For this reason, the data management device 101 may generate a digital signature from the private key of the participant device 501 on behalf of the participant device 501 and send it to the participant device 501.

[0021] Verification / Audit Device 1 receives a request from another device to verify the integrity of any record written to the blockchain, searches the blockchain for the record based on the verification request, and verifies the integrity of the record. The requesting device for verification may be the participant device 501, the data management device 101, or the user device 701, or it may be a different device. Verification / Audit Device 1 does not have to belong to the blockchain system 201, and may request a search on the blockchain from an information processing device belonging to the blockchain system 201. In Figure 1, Verification / Audit Device 1 is shown as a separate device from the participant device 501, the data management device 101, and the user device 701, but at least one of the participant device 501, the data management device 101, and the user device 701 may also function as Verification / Audit Device 1. Furthermore, Verification / Audit Device 1 also incorporates the functions of the auditor device (auditor device) described later, and generates audit records.

[0022] It should be noted that the entities involved in the information processing system are not limited to those shown in Figure 1; other entities may also exist. For example, it is conceivable that the data of stakeholders may be stored by a data manager separate from the data handler. In this case, the data manager's information processing device can acquire data from the stakeholders' device 501, and the data manager's information processing device can then transmit the data to the user device 701 upon receiving instructions from the data management device 101. In other words, the data manager's information processing device can function as part of the data management device 101.

[0023] Figure 2 shows an example of a blockchain according to this embodiment. Figure 3 is a follow-up to Figure 2. The blockchains in Figures 2 and 3 will be described below. Figures 2 and 3 show a blockchain containing multiple blocks. The blockchain contains records of data, and more specifically, records of data handling. The transaction ID shown in each block is an identifier for the process (transaction) indicated by each record. The transaction ID is simply a value that identifies each block, and the order of the values ​​does not need to match the order in which the blocks are generated. Also, the transaction IDs do not need to be consecutive values. The BC user ID shown in each block represents the user ID in the blockchain and indicates the entity responsible for the process indicated by each record.

[0024] Block 300 shows a record (handling consent record) indicating that a data user with BC User ID "hanako" has consented to the handling of data by a data handler with BC User ID "dealer1". The consent is valid from August 11, 2021 onwards. The type of handling is "acquisition", and the type of record is "handling consent". The status is "consented". "hanako" can be a real name or a pseudonym, but in this embodiment, we assume it is a pseudonym.

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

[0026] Block 303 also shows a data handling consent record. Block 303 shows that "g7h8i9", corresponding to "hanako", has given consent regarding the provision of data, stating that it is acceptable to provide data to data users whose data provider is "dealer1" and whose data recipient is BC user ID "company1". This can also be considered the user's consent to "company1" receiving the data. In this record, the type of handling is "Provision", and the type of record is "Handling Consent". A record of such consent is called a provision consent. Similarly, Block 304 shows that "j1k2m3", corresponding to "hanako", has given consent that it is acceptable to provide data to data users whose data provider is "dealer1" and whose data user is "company2". This can also be considered the user's consent to "company2" receiving the data. Similar to Block 301, the type of handling is "Provision", and the type of record is "Handling Consent" (Provision Consent).

[0027] The BC User IDs shown in blocks 303 and 304 are assigned to each user (recipient) as identifiers that identify data stakeholders. In other words, the BC User ID is a unique identifier for each user that identifies stakeholders. That is, the data stakeholder "hanako" is represented by a different identifier for each user. Even for the same user, the identifier will differ depending on the stakeholders combined. The correspondence between the BC User ID "hanako" (stakeholder identifier), which indicates the user's pseudonym (or real name), and the unique user identifiers "g7h8i9" and "j1k2m3" (first business operator identifiers) for each user is stored in the user identifier correspondence table 91 (corresponding data). In this embodiment, the user's consent for "dealer1" to provide data to "company1" and "company2" includes the user's consent for "company1" and "company2" to receive the data. This eliminates the need to have duplicate consent for receiving and providing data, thus saving storage capacity. However, it is possible to have both "company1" and "company2" agreeing to receive the funds, which may overlap with the agreement to provide the funds.

[0028] Block 307 is a record of an action taken regarding data acquisition. The entity that performed the acquisition is "dealer1," and it indicates that the data acquisition took place on August 13, 2021. The record type is "action taken," and the type of action is "acquisition." An action taken record with an action type of "acquisition" is sometimes called an "action taken record related to acquisition," an "action taken record for acquisition," or simply an "acquisition record."

[0029] Block 308 is a record of the handling of data provision by "dealer1". The record type is "Handling Execution", and the handling type is "Provision". The recipient of the data can be seen as "company1" from the recipient of the referenced consent ID 03. A record of handling with the handling type "Provision" is sometimes called a "record of handling related to provision", a "record of handling of provision", or a "provision record".

[0030] Block 309 is a record of the handling of data received by "company1," corresponding to the data provided by "dealer1." The provider of the data is "dealer1," as can be seen from the source of the referenced consent ID 03. The record type is "Handling Execution," and the handling type is "Receipt." A handling execution record with a handling type of "Receipt" is sometimes called a "Handling Execution Record for Receipt," a "Handling Execution Record for Receipt," or a "Receipt Record." In this embodiment, a mechanism to refer to consent ID 00 to confirm whether "dealer1" has consent to acquire data is not employed. The reason for this is that if a mechanism to refer to consent ID 00 were employed, it would be possible to determine or infer that "hanako" and "g7h8i9" correspond from the correspondence between items in Block 300 and Block 303. In this embodiment, as will be described later, in order to confirm that the acquisition process of "dealer1" is legitimate, the acquisition process record of ID 111 (Block 320) or the audit record of ID 200 (Block 322) is referred to.

[0031] The acquisition history record in block 320 is a record that shows that the data acquisition process by "dealer1" was legitimate when BC user "company1" received data from "dealer1".

[0032] Similarly, block 310 is a record of the handling of data provision by "dealer1" to "company2" (provision record), and block 311 is a record of the handling of data receipt by "company2" corresponding to the data provision by "dealer1" (receipt record). Blocks 310 and 311 have the same content as blocks 308 and 309, respectively, but differ from blocks 308 and 311 in terms of the provision consent ID and acquisition history ID. In this embodiment, as will be described later, in order to confirm that the acquisition history of "dealer1" is legitimate, the acquisition history record of ID 112 (block 321) or the audit record of ID 201 (block 323) is referred to.

[0033] The acquisition history record in block 321 is a record that shows the legitimate nature of the data acquisition by "dealer1" when BC user "company2" receives data from "dealer1".

[0034] Block 312 is a transaction execution record representing the use of data by "dealer1". The record type is "Transaction Execution", and the transaction type is "Use". Records related to such transactions are called use records. The person involved in this data (owner) is BC user ID "hanako" of the referenced consent ID 00. Note that "dealer1" corresponds to the data handler (see Figure 1), but data can be used not only by data users but also by data handlers. In other words, data handlers can also be data users. Consent to acquire data also serves as consent to use it.

[0035] Block 313 shows a record (handling consent record) indicating that a data user with BC User ID "hanako" withdrew their consent to data acquisition by a data handler named "dealer1". In Block 313, the status is "Disagreement".

[0036] Block 317 shows a record (handling consent record) indicating that a data handler named "g7h8i9," whose BC user ID corresponds to "hanako," withdrew their consent to "dealer1" providing data to "company1." The BC user ID shown in Block 317 is a unique ID specific to each user, identifying the data handler and serving as a unique identifier corresponding to the user.

[0037] Block 318 shows a record (handling consent record) indicating that a data handler named "j1k2m3," whose BC user ID corresponds to "hanako," withdrew their consent to provide data from "dealer1" to "company2." The BC user ID shown in Block 318 is a unique ID specific to each user, serving as an identifier that identifies the data handler and uniquely corresponds to the user.

[0038] As mentioned above, in this embodiment, there is no overlap in consent regarding receipt consent and consent regarding provision. Similarly, regarding the withdrawal of consent, by not having overlapping withdrawal of receipt consent and withdrawal of provision consent, the capacity of the storage system used can be saved.

[0039] Block 319 is an execution record (deletion record) indicating that "dealer1" deleted the data. The person involved with the deleted data is "hanako," as indicated by the BC user ID in block 313 of the referenced consent ID (transaction ID) 13.

[0040] Blocks 322 and 323 are audit record blocks. The audit record in block 322 is a record indicating that there is a consent record (block 300) indicating that the data provider "dealer1", indicated in the consent record for the consent of the data provider in block 303 indicated by consent ID 03, has obtained consent for the data to be acquired. The audit record in block 323 is a record indicating that there is a consent record (block 300) indicating that the data provider "dealer1", indicated in the consent record for the consent of the data provider in block 304 indicated by consent ID 04, has obtained consent for the data to be acquired. Details of blocks 322 and 323 will be described later.

[0041] Blocks 324 and 325 are audit record blocks. The audit record in block 324 shows that there is a consent record (block 313) indicating that the data provider "dealer1" in the consent record for withdrawal (non-consent) of consent to provide, as indicated by block 317 of consent ID 17, has obtained a withdrawal (non-consent) of consent to acquire the data. The audit record in block 325 shows that there is a consent record (block 313) indicating that the data provider "dealer1" in the consent record for withdrawal (non-consent) of consent to provide, as indicated by block 318 of consent ID 18, has obtained a withdrawal (non-consent) of consent to acquire the data. Details of blocks 324 and 325 will be described later.

[0042] Furthermore, records written to the blockchain can contain various types of information. For example, a consent record for acquisition (e.g., block 300) may include where the handler obtains the data from, in other words, the data source. Similarly, a record of execution of acquisition (e.g., block 307) may include where the handler obtained the data from, in other words, the data source. Also, a consent record for provision (e.g., block 308) may include data items indicating whether all of the data can be provided, or which parts of the data can be provided. Moreover, in these consent and execution records, the recipient of the data may be explicitly included, or, as mentioned above, if the recipient can be determined by referring to other records, the recipient may be omitted.

[0043] Furthermore, while the examples in Figures 2 and 3 show one record written in one block, this does not necessarily have to be a one-to-one correspondence; multiple records may be written in a single block. For example, a record of consent for handling data acquisition from data stakeholders and a record of consent for handling data provision (provision consent) may be written in a single block. Also, multiple items of the same type may be included within a single record. For example, multiple consents such as consent for acquisition and consent for provision (provision consent) may be included in a single handling consent record. Alternatively, a single handling consent record for acquisition may include the consents for acquisition from multiple stakeholders. In addition, if multiple data are provided at once based on multiple consents, the handling execution record for data provision (provision record) may include information indicating multiple handling consent records (provision consent) related to data provision.

[0044] Furthermore, the record can be written to the block in any way, as long as the necessary information can be read from the block. For example, part or all of the record may be included in the block as metadata.

[0045] In this way, traceability can be guaranteed by writing records to the blockchain. However, since blockchain blocks can be used by any information processing device belonging to the blockchain system (P2P network), confidentiality becomes an issue. However, the blockchains in Figures 2 and 3 have measures in place to address confidentiality. For example, in Figures 2 and 3, the BC user ID is shown by the identifier (pseudonym) "hanako". If this identifier is not related to an actual person's name, it is difficult to identify the person. By using a technique called pseudonymization, which replaces personal names with other strings, numbers, etc., based on predetermined rules, it is possible to make it difficult to identify individuals.

[0046] Furthermore, various types of information may be added to the records written to the blockchain. For example, details of the data being acquired or provided may be added. If the data management device 101 provides a portion of the data received from the related device 501 to the user device 701, information that allows the user to identify that portion, such as the item name and its position within the data, may be included in the record. Also, if there is only one data management device 101, the BC user ID of the providing data management device 101 does not need to be included in the record.

[0047] In this way, when records are written to the blockchain, even if data is leaked, the disadvantage of information that could identify data stakeholders through data matching is reduced, while also allowing confirmation of consent to provide data to third parties and the history of such provision.

[0048] For example, a data user can use their BC user ID, a standard identifier, as a key to read the consent record written to the block on the blockchain, and verify whether the consent is what the data user intended. In the example in Figure 3, the user device 501 can detect blocks 300 and 313 using "hanako" as the key. This allows the user to verify whether the consent for acquisition (which also includes consent for storage and use) is valid.

[0049] Furthermore, user A cannot recognize that the identifier "j1k2m3" for user B represents the same data source as the identifier "g7h8i9" for user A. Similarly, user B cannot recognize that the identifier "g7h8i9" for user A represents the same data source as the identifier "j1k2m3" for user B. Therefore, even if one of user A or user B leaks data, the other cannot identify that this data belongs to "hanako" through matching. Thus, the disadvantages caused by data leakage can be reduced.

[0050] Furthermore, if the data provider knows the data user identifier, blocks 303 and 317 can be detected using "g7h8i9" as the key, corresponding to "hanako". This allows verification of whether the consent to provide data to user A, company1, is valid. Similarly, blocks 304 and 318 can be detected using "j1k2m3" as the key, corresponding to "hanako". This allows verification of whether the consent to provide data to user B, company2, is valid. Alternatively, the regular identifier or user identifier of a data provider who has given consent for data provision or acquisition can be confirmed by querying an information processing device that recognizes the correspondence between the data provider's regular identifier and a unique identifier assigned to each user that identifies the data provider.

[0051] As shown in Figure 3 above, it is possible that the related device 501 may withdraw its consent to provide data after it has given its consent. Therefore, it is preferable to be able to confirm that the consent to provide data has not been withdrawn when providing data. That is, if the related device 501 withdraws its consent to provide data, a record of the withdrawal of consent is written to the blockchain. It is preferable for the data management device 101 to search the blockchain using the BC user ID of the related device 501 as a key when providing data to determine whether the consent to provide data has not been withdrawn. Furthermore, if an expiration date is indicated in the consent to provide data, it is preferable to confirm whether the expiration date indicated in the consent to provide data has not expired. In this way, it is preferable to confirm the validity of the consent to provide data when providing data.

[0052] In the above, only dealer1 was described as a data handler (second business operator), 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. Alternatively, the BC user ID of the data-related party may be changed for each combination of data handler (second business operator) and data user (first business operator). For example, the consent record for data provision from data handler dealer1 to data user company1 uses "g7h8i9". The consent record for data provision from another data handler, dealer2, to data user company1 uses a different identifier than "g7h8i9". This can reduce the disadvantages caused by data leakage.

[0053] Note that the blockchains in Figures 2 and 3 are illustrative examples, and various records may be written to the blockchain. For example, usage records such as records of data users performing actions such as data analysis, editing, or deletion may be written as transaction execution records. In addition, the transaction execution record for receipt may include the items of the received data, the BC user ID of the data management device 101 that provided the data (the BC user ID of the data sender), etc.

[0054] The following explains the process for generating the blockchain shown in Figures 2 and 3. Figure 4 is a schematic flowchart of the overall process in this embodiment. Figure 5 is a flowchart following Figure 4.

[0055] As a prerequisite, the entity writing to the flock chain can change. For example, consent records are written by data stakeholders, while records of handling actions such as acquisition and use are written by the device of the entity that performed the acquisition or use (handler device, user device). However, it is also possible to request another device to write the record, and the requested device will write the record. In the following explanation, the record being written will be used as the subject, and the entity writing the record may be omitted, but as mentioned above, records can be written by any device.

[0056] Furthermore, the flow of data being handled may occur before, in a different order than, the writing of records to the blockchain, or simultaneously. For example, the data may be received after the consent record for handling the acquisition has been written, or the consent record for handling the acquisition may be written after the data has been received along with the consent for acquisition. Also, when handling multiple data in parallel, this flow will be processed multiple times in parallel. The following describes this flow in detail.

[0057] As a prerequisite, when user "company1" initiates a transaction with dealer "dealer1", it is assumed that company1's user device creates block 320 after confirming the legitimacy of "dealer1's" data acquisition (consent from "dealer1" to acquire data from data-related parties). When user "company2" initiates a transaction with dealer "dealer1", it is assumed that company2's user device creates block 321 after confirming the legitimacy of "dealer1's" data acquisition (consent from "dealer1" to acquire data from data-related parties). However, as will be described later, the timing of creating blocks 320 and 321 is not limited to these timings.

[0058] Based on the data subject's consent that the data handler (in the example in Figure 2, "dealer1") may acquire the data subject, a record of the consent to handle the transaction is written to the blockchain (A101). This generates block 300 in Figure 2. Alternatively, the process in step A101 may be triggered when the data management device 101 receives data from the data subject, or the consent to handle the transaction may be generated and written to the blockchain before such data is received. Here, we assume the latter case.

[0059] Furthermore, based on the consent of the data stakeholders that the data handler may provide the data to user A (in the example of Figure 3, "company1"), a record of consent to provide the data to user A (first consent record) is written to the blockchain (A102). In this record, the regular identifier (in the example of Figure 2, a pseudonym "hanako") is changed by the data management device 101 to a unique identifier for user A (in the example of Figure 2, "g7h8i9"), and the changed identifier is used as the BC user ID of the data stakeholders. Also, based on the consent of the data stakeholders that the data handler may provide the data to user B (in the example of Figure 2, "company2"), a record of consent to provide the data to user B (first consent record) is written to the blockchain (A103). In this record, the regular identifier ("hanako") is changed by the data management device 101 to a unique identifier for user A (in the example of Figure 3, "j1k2m3"), and the changed identifier is used as the BC user ID of the data stakeholders. The processes in steps A102 and A103 generate blocks 303 and 304 in Figure 2.

[0060] The provision of data enables data users to receive and use the data. In cases where the action, once performed, allows users to receive and use the data, such as the provision of data, the identifier of the data party in the consent record is changed to an identifier that uniquely corresponds to the user, as described in steps A102 and A103 above, and then written.

[0061] The identifier unique to each user may be determined as appropriate. A unique identifier may be obtained by converting part or all of the regular BC user ID according to a predetermined rule, or a new unique identifier may be assigned to each user. For example, the regular BC user ID may be converted based on individual keys held by each third party (user). Alternatively, a unique identifier may be obtained by converting the regular BC user ID based on a combination of individual keys held by each third party and individual keys held by data stakeholders. Furthermore, the regular BC user ID may be encrypted. The identifier unique to each user (first-party identifier) ​​is associated with the user's regular identifier (stakeholder identifier) ​​and stored in the user identifier correspondence table 91.

[0062] When the data management device 101 attempts to acquire data, it confirms, based on the blockchain (block 300), that it is permissible to acquire the data before acquiring it (A106). Block 307, which shows the execution record of the data acquisition process, is generated, including information (consent ID 00) indicating the consent record for the process. The data source may be the related device 501 or another information processing device.

[0063] Subsequently, the data management device 101 attempts to provide the data to user A. In this case, the data management device 101 confirms, based on the blockchain (block 303), that it is permissible to provide the data to user A, and then transmits the data to user A's user device 701 (A107). Meanwhile, user A's user device 701, which is receiving the data, confirms, based on the blockchain (blocks 303 and 320 (acquisition history record)), that it is permissible to receive the data, and then receives the data (A108).

[0064] More specifically, confirmation of whether data can be provided and whether it can be received is performed using the BC user ID corresponding to the recipient user device 701. In the example in Figure 3, when attempting to provide data from "hanako" to "company1", the BC user ID "g7h8i9" for "hanako" and "company1" is used as the key for detecting the handling consent record. This allows block 303, where the handling consent record for "g7h8i9" is written, to be detected, confirming that consent for provision has been given. Furthermore, confirmation that data may be provided to user A and confirmation that user A may receive the data includes confirming that the data handler may obtain data from data stakeholders based on block 303 and block 320 (acquisition history record). Here, confirmation that data may be received was performed based on block 303 and block 320 (acquisition history record), but depending on the timing of the audit, if an audit record (see block 322) already exists at this point (if an audit has already been performed), it may also be performed based on block 303 and the audit record. In other words, whether to perform the verification based on Block 303 and Block 320 (acquisition history record) or based on Block 303 and audit records may be optional, depending on the timing of the audit.

[0065] In addition to the data management device 101 and user device 701 directly checking the blockchain to determine whether data can be provided and whether it can be received, the data management device 101 and user device 701 may also request other information processing devices belonging to the blockchain system 201 to make a determination regarding whether data can be provided and whether it can be received. Furthermore, having multiple information processing devices belonging to the blockchain system 201 make determinations regarding whether data can be provided and whether it can be received has the advantage of ensuring transparency in the determination process.

[0066] Subsequently, the transaction execution record regarding the data provider's provision to user A is written to the blockchain, including information identifying the transaction consent record which includes an identifier for user A (A109). This generates block 308 in Figure 2. In addition, the transaction execution record regarding user A's receipt of data is written to the blockchain, including information identifying the transaction consent record which includes an identifier for user A (Provision Consent ID 03) (A110). This generates block 309 in Figure 2.

[0067] In the transaction execution records for provision (block 308) and receipt (block 309), identifiers other than the identifier for user A (such as regular identifiers) are excluded. This prevents third parties from identifying which party the data belongs to by matching the data. Block 308 includes transaction ID 03 of the transaction consent record for provision, which includes the identifier for user A "g7h8i9", as the consent ID. Block 309 includes transaction ID 03 of the transaction consent record for provision and receipt, and transaction ID 111 of the acquisition history record, which include the identifier for user A "g7h8i9".

[0068] When the data management device 101 attempts to provide data to user B, the same process as when it attempts to provide data to user A is performed. More specifically, as shown in Figure 5, the data management device 101 confirms, based on the blockchain (block 304), that it is permissible to provide data to user B, and then transmits the data to user B's user device 701 (A111). On the other hand, user B's user device 701, which receives the data, confirms, based on the blockchain (blocks 304 and 321 (acquisition history record)), that it is permissible to receive the data, and then receives the data (A112). Then, the transaction execution record regarding the provision of data to user B is written to the blockchain, including information indicating a transaction consent record that includes an identifier for user B (provision consent ID 04) (A113). This generates block 310. In addition, the transaction execution record regarding the receipt of data by user B is written to the blockchain, including information indicating a transaction consent record that includes an identifier for user B (provision consent ID 04) (A114). This generates block 311. Block 311 includes transaction ID 04, which is a record of consent to provide and receive the data, and transaction ID 112, which is a record of the acquisition process, both of which include the identifier "j1k2m3" for user B. Here, confirmation that user B's user device 701 is permitted to receive data was performed based on blocks 304 and 321 (acquisition history record). However, depending on the timing of the audit, if an audit record (see block 323) already exists at this point (i.e., if an audit has already been conducted), confirmation may be performed based on block 304 and the audit record. In other words, whether to perform confirmation based on blocks 304 and 321 (acquisition history record) or based on block 304 and the audit record may be an option depending on the timing of the audit.

[0069] All IDs indicating the handling consent record (provision consent) included in Block 310 and Block 311 indicate the handling consent record related to the identifier "j1k2m3" for user B.

[0070] Therefore, although both Block 308 and Block 310 are transaction execution records related to provision, the provision consent IDs included in each are different because the recipient users are different. Also, although both Block 309 and Block 311 are transaction execution records related to receipt, the provision consent IDs and acquisition history IDs included in each are different because the recipient users are different.

[0071] The data management device 101 utilizes the data (for example, analyzes it). Note that utilization is one example of data handling. As a result, the data management device 101 generates a record of the data handling process and writes this record to the blockchain. This generates block 312 (A115).

[0072] Subsequently, the consent to allow the data handler (in the example in Figure 2, "dealer1") to acquire the data is withdrawn by the data stakeholders, and for example, the stakeholders' device 501 writes the consent record related to that consent to the blockchain (A116). This generates block 313.

[0073] If consent to acquire is withdrawn and the corresponding withdrawal of consent to provide is not recorded on the blockchain, then, for example, a related device 501 or a data management device 101 will write a record of consent to provide to the blockchain (A117). This generates block 317 containing an identifier for user A and block 318 containing an identifier for user B.

[0074] The data management device 101 deletes the stored data after confirming that the data owner has withdrawn their consent (consent to acquisition) based on block 313 (A120). The data management device 101 generates an execution record of the data deletion, and the generated execution record includes information indicating the consent record (consent ID 13) (same as A120). The generated execution record is written to the blockchain (same as A120). This generates block 319.

[0075] Next, processing is performed to enable tracing of records for data stakeholders represented by identifiers, even from identifiers specific to each user. For example, if one does not know that "g7h8i9" corresponds to "hanako" (using only blocks 300, 303, and 304), a third party cannot recognize whether the data stakeholder "hanako" corresponding to "g7h8i9" has given consent to the data handler regarding data acquisition. Therefore, the information processing device, the search unit 112 (see Figure 9) of the verification / audit device 1 in this embodiment, which recognizes the correspondence between identifiers before and after the change, searches the blockchain and detects the data acquisition consent record where the data stakeholder is represented by a normal identifier, the BC user ID (in the example of Figure 3, "hanako"). The processing unit 113 of the verification / audit device 1 obtains the user identifier correspondence table 91 from the data management device 101 and stores it in the storage unit 116. The processing unit 113 of the verification / audit device 1 identifies a handling consent record (first consent record) (block 303) relating to the first handling (e.g., provision), which includes an identifier for user A as a representation of the data stakeholders. It generates an audit record indicating that there is an acquisition handling consent record (second consent record) (block 300) corresponding to the identified handling consent record (block 303), and records it in the first storage system 201 (A131). This generates block 322, which indicates the existence of the handling consent record in block 300. The identification of the handling consent record (first consent record) may be performed by acquiring the handling consent record from the device that generated block 303, or by searching the first storage system 201.

[0076] Figure 6 shows blocks 322 to 325 of the audit record in Figures 2 and 3. Block 322 indicates that there is an acquisition handling consent record (block 300) corresponding to block 303, which is provision consent ID 03 ("Yes"). The record type is "Audit," and the BC user ID is "auditor1," which indicates the auditor or verification / audit device 1. "auditor1" corresponds to the auditor's identifier. Block 322 allows a user who only knows the BC user ID "g7h8i9" to recognize that the data party corresponding to "g7h8i9" ("hanako") has consented to the data handler acquiring the data. However, even in this case, the user does not know that the normal identifier of the data party corresponding to "g7h8i9" is "hanako."

[0077] Similarly, a data handler consent record (first consent record) (block 304) relating to the first handling (e.g., provision) is identified, including an identifier for user B as a representation of the data handler. An audit record is generated indicating that there is a corresponding data handler consent record (second consent record) (block 300) to the identified data handler consent record (first consent record), and this record is recorded in the first storage system 201 (A132). This generates block 323, which indicates the existence of the data handler consent record in block 300. The contents of block 323 are the same as block 322, except that the provision consent ID is different.

[0078] Furthermore, the processing unit 113 of the verification / audit device 1, which is an information processing device that recognizes the correspondence between identifiers before and after the change, records as an audit record that there is a withdrawal (disagreement) handling consent record corresponding to block 317 (A133). This generates block 324 (audit record) in Figure 3 or Figure 6, which indicates the existence of the handling consent record for block 313 (withdrawal of consent to data acquisition). Block 324 allows even a user who only knows the BC user ID "g7h8i9" to recognize that the data person corresponding to "g7h8i9" ("hanako") has withdrawn the data acquisition by the data handler. However, even in this case, the user does not know that the data person corresponding to "g7h8i9" is "hanako".

[0079] Similarly, the processing unit 113 of the verification / auditing device 1 records as an audit record that there is a withdrawal (non-consent) handling consent record corresponding to block 318 (A134). This generates block 325 (audit record) in Figure 3 or Figure 6, which indicates the existence of the handling consent record for block 313 (withdrawal of consent to data acquisition).

[0080] In this way, when records are written to the blockchain, even if data is leaked, the disadvantage of information that could identify data stakeholders through data matching is reduced, while also allowing confirmation of consent to provide data to third parties and the history of such provision.

[0081] For example, a data user can use their BC user ID, a standard identifier, as a key to read the consent record written to the block on the blockchain, thereby verifying whether the consent is what the data user intended. In the examples in Figures 2 and 3, the user device 501 can detect blocks 300 and 313 using "hanako" as the key. This allows verification of whether the consent for acquisition (or storage) is valid.

[0082] Furthermore, at step A110, user A's device 701 can detect block 303 using the identifier "g7h8i9" for user A as the key. This allows confirmation that the received data was provided with consent. Whether block 322 (audit record) can be detected depends on the timing of the audit. Block 322 (audit record) or block 320 (acquisition history record) allows confirmation that the acquisition history of the received data is clear. Similarly, at step A113, user B's device 701 can detect block 304 using the identifier "j1k2m3" for user B as the key and perform the same confirmation.

[0083] Thus, traceability is ensured by generating a blockchain using the processes shown in Figures 4 and 5.

[0084] Figure 7 shows excerpts of blocks 320 and 321 from Figure 2 for illustrative purposes. Block 320 is an example where a single record of the acquisition history is generated for all data stakeholders, and the data provider is not listed. In the example above, block 320 is created before "company1" receives data from "dealer1". Specifically, when "company1" starts a transaction with "dealer1", it is created by company1's user device after confirming the legitimacy of "dealer1's" data acquisition or receipt. As another example, the acquisition history record in block 320 may be generated by company1's user device when the user device of "BC User ID = company1" receives data from "Handler = dealer1".

[0085] Similarly, block 321 represents the record of the acquisition process for data received from "dealer=dealer1" with "BC User ID=company2". Except for the different BC User ID, block 321 is the same as block 321. Therefore, a detailed explanation of block 321 is omitted.

[0086] Figure 8 illustrates another example of a record. Figure 8 shows two example blocks of records, both excerpted for illustrative purposes from records written to the blockchain.

[0087] Block 803 is a block that shows the execution record of the handling of data, indicating that the device with "BC User ID = company1" received the data. The "Provision Consent ID = 03" shown in Block 803 indicates the handling consent record in Block 303. The "Acquisition History ID = 100" in Block 803 indicates the acquisition history record (Block 801) which is the basis for the receipt of the data. The acquisition history refers to the process by which the data provider acquired the data. The acquisition history record with ID 100 shows the acquisition process by the provider "dealer1".

[0088] More specifically, block 801 describes the data provider and recipient (the entity that acquired the data) as part of the data acquisition process. "Provider = company3" means that it was company3, not "hanako," one of the data stakeholders, that actually sent the data to dealer1. As mentioned above, data may not be acquired or received from the stakeholders' device 501, but from another information processing device such as a data administrator. In such cases, as in block 801, the data provider (company3 in this example) may be included in the record, and a record of the acquisition process may be generated. Also, in the acquisition process records shown in blocks 320 and 321 of Figure 2, the BC user IDs are company1 and company2, but in the acquisition process record shown in block 801, the BC user ID is dealer1.

[0089] A record of the acquisition process may be generated for each data stakeholder. If the acquisition process is the same for all data stakeholders, a single record of the acquisition process common to all data stakeholders may be generated. Block 801 is an example where a single record of the acquisition process common to all data stakeholders is generated. When generating a record of the acquisition process for each data stakeholder, the BC user ID of the data stakeholder may be included in the record of the acquisition process.

[0090] Furthermore, the record of the acquisition history of block 801 may be generated when the user receives the data. Alternatively, it may be created before the user receives the data from the handler. Specifically, when "company1" initiates a transaction with "dealer1", the user device of company1 may create the record after verifying the legitimacy of "dealer1's" data acquisition or receipt.

[0091] The following describes Verification / Auditing Device 1, which verifies the integrity of records written to the blockchain. Verification of consistency will be based on the consent record for handling, the record of handling, and the handling actions performed by the handler / user.

[0092] Figure 9 is a block diagram of the verification / audit device 1. The verification / audit device 1 comprises a receiving unit 111, a search unit 112, a processing unit 113, a transmitting unit 115, and a storage unit 116. The processing unit 113 includes a period calculation unit 114.

[0093] The receiving unit 111 receives a request for consistency verification (consistency verification request) for records relating to data handling (handling consent records or handling execution records) from the requesting device. The requesting device may be any device, such as the related party device 501, the data management device 101 that manages the related party's data, a device operated by an auditing body for handlers, the user device 701, or a device operated by an auditing body for users, and is not limited to a specific device. The storage unit 116 stores identifier correspondence information, which is information that includes the correspondence between BC user IDs using user identifiers and BC user IDs using normal identifiers (pseudonyms or real names). If the verification / auditing device 1 is a device other than the data management device 101 (for example, the user device 701), the storage unit 116 does not need to store identifier correspondence information. Alternatively, if the verification / auditing device 1 is the user device 701, the identifier correspondence information may only include the correspondence between the user identifier corresponding to the user device 701 and the normal identifier.

[0094] The search unit 112 performs a search on the first storage system 201 (the blockchain in this example). As an example, the search unit 112 performs a search on the first storage system 201 based on the conditions included in the verification request and obtains related transaction consent records and transaction execution records. That is, the search unit 112 sends a search request to the first storage system 201 and receives as a response from the first storage system 201 related transaction consent records and transaction execution records that satisfy the conditions. In this case, if the search unit 112 needs to identify a regular identifier from a user identifier, it uses identifier correspondence information in the storage unit 116. Based on the conditions specified in the verification request, it searches for the transaction consent records or transaction execution records. As an example, the above conditions specify the values ​​of items included in the transaction consent records or transaction execution records.

[0095] The period calculation unit 114 calculates at least one of the consent period and non-consent period of the parties concerned regarding the handling of the data, based on the acquired consent records for handling the data.

[0096] The processing unit 113 verifies consistency based on at least one of the consent period and the non-consent period, and the acquired transaction execution record. The processing unit 113 also generates the aforementioned audit record.

[0097] The transmitting unit 115 transmits information indicating the consistency verification result to the device that requested the verification.

[0098] The processing unit 113 identifies a data handling consent record (e.g., block 303) relating to the first handling (e.g., provision), which includes an identifier for the user (e.g., "company1") as a representation of the data stakeholders. This data handling consent record corresponds to the first consent record.

[0099] The identifier included in the handling consent record is converted to a regular identifier. Based on the converted regular identifier, the search unit 112 is instructed to search for the handling consent record (second consent record) for the second handling (e.g., acquisition) represented by the regular identifier BC user ID for the data handler ("dealer1"). The data handler (first business operator) executing the second handling makes it possible for the data user (second business operator) to execute the first handling.

[0100] The search unit 112 searches the first storage system 201 in accordance with the instructions of the processing unit 113 and detects a data handler ("dealer1") and a data handler consent record for a second handling (e.g., acquisition) in which the data handler is represented by the BC user ID ("hanako"), which is a normal identifier. This handling consent record corresponds to the second consent record.

[0101] The processing unit 113 may issue a search instruction periodically, or it may receive notification from the device that generated the user consent record or the device that wrote the user consent record to the first storage system 201 that a user consent record containing a user identifier has been generated, and perform the search according to the timing of the notification. The user identifier to be processed may be included in the notification, may be identified sequentially from the correspondence table 91, or may be designated by the auditor.

[0102] Based on the search results from the search unit 112, the processing unit 113 generates an audit record that includes a record identifier (transaction ID) that identifies the user's consent record for handling the first handling (first consent record) and whether or not the data handler has a consent record for handling the second handling (second consent record).

[0103] For example, if the search is successful, an audit record is generated indicating that the handling consent record (second consent record) exists. The processing unit 113 transmits to the device that writes to the first storage system 201 (e.g., data management device 101) via the transmission unit 115 that the audit record should be written to the first storage system 201. In this case, the audit record includes a record identifier (transaction ID) that identifies the handling consent record (first consent record) relating to the user's first handling, and information indicating that the handling consent record (second consent record) relating to the data handler's second handling exists. If the verification / auditing device 1 is able to write to the first storage system 201, the processing unit 113 may perform the process of writing the audit record to the first storage system 201.

[0104] If the search yields no results, an audit record is generated indicating that the handling consent record (second consent record) does not exist. The processing unit 113 transmits to the device that writes to the first storage system 201 (e.g., data management device 101) via the transmission unit 115 that the audit record should be written to the first storage system 201. In this case, the audit record includes a record identifier (transaction ID) that identifies the handling consent record (first consent record) relating to the user's first handling, and information indicating that the handling consent record (second consent record) relating to the data handler's second handling does not exist. If the verification / audit device 1 is able to write to the first storage system 201, the processing unit 113 may perform the process of writing the audit record to the first storage system 201.

[0105] The verification operation of Verification / Auditing Device 1 will be explained in detail below using a specific example.

[0106] [Verification Example 1: Starting from the receipt transaction execution record, verification is performed using a regular (real name or pseudonym) BC user ID.] In this example, we assume that verification / auditing device 1 is data management device 101, but verification / auditing device 1 can be any of the following: a participant device, a data management device (handler device), or a user device, and it can also be any other information processing device.

[0107] Figure 10 is a flowchart showing an example of the operation in Verification Example 1. Figure 11 shows how the blockchain record is traced during the operation described in Figure 10.

[0108] (Step S101) The receiving unit 111 receives a request for consistency verification of the receipt handling execution record shown in block 309 of Figure 2.

[0109] <Obtain relevant consent records and execution records for handling procedures> (Step S102) The search unit 112 searches for the transaction consent record related to the transaction execution record of block 309, which is the block to be verified. Since the transaction IDs of the transaction consent record and acquisition history record referenced by the transaction execution record of block 309 are ID03 (block 303) and ID111 (block 320), blocks 303 and 320 are obtained from the blockchain system. If either the transaction consent record or the acquisition history record does not exist on the blockchain, the processing unit 113 detects an inconsistency (S114). Alternatively, the processing unit 113 may detect an inconsistency if both the transaction consent record and the acquisition history record do not exist on the blockchain, but not if either the transaction consent record or the acquisition history record exists.

[0110] The type of transaction in the transaction execution record of block 309 is "received" and the BC user ID is "company1". Therefore, the processing unit 113 checks in the transaction consent record of block 303 whether the type of transaction is "provided" and the recipient is "company1". If at least one of the acquisition type and recipient does not exist or is different, the processing unit 113 detects an inconsistency. Since the provider of the transaction consent record for provision in block 303 is "dealer1", the processing unit 113 checks in the acquisition history record of block 320 whether the handler is "dealer1". If the handler does not exist or is different, the processing unit 113 detects an inconsistency by stating that there is no corresponding transaction consent re-record (S114).

[0111] (Step S103) The search unit 112 searches for a handling consent record corresponding to the handling consent record obtained in step S102. Here, the verification / auditing device 1 has identifier correspondence information that includes the correspondence between BC user IDs using user identifiers and BC user IDs using normal identifiers (pseudonyms or real names). The search unit 112 uses the identifier correspondence information to obtain the corresponding normal identifier BC user ID "hanako" from the BC user ID "g7h8i9" in block 303. The search unit 112 searches for a handling consent record where the BC user ID is "hanako", the handler matches block 320, and the type of handling is acquisition, and obtains block 300. The processing unit 113 detects an inconsistency if no handling consent record exists.

[0112] (Step S104) The search unit 112 searches for a consent record in which the BC user ID, record type, handling type, and handler match the consent record in block 303, and the status is "not consented," and obtains block 317.

[0113] (Step S105) The search unit 112 searches for a consent record (block 300) in which the BC user ID, record type, handling type, and handler match, and the status is "not consented," and obtains block 313.

[0114] (Step S106) The search unit 112 searches for the acquisition handling execution record that refers to the acquisition handling consent record (block 300) and obtains block 307.

[0115] (Step S107) The search unit 112 searches for a provision handling execution record in which the provision consent ID is the same as the receipt handling execution record (block 309), ID 03, and obtains block 308. If no provision handling execution record exists, the processing unit 113 detects an inconsistency.

[0116] (Step S108) The search unit 112 searches for the deletion operation execution record that refers to the operation consent record (block 313) whose status is non-consent, and obtains block 319.

[0117] <Obtain consent and non-consent periods> (Step S109) The period calculation unit 114 calculates the consent period and the non-consent period based on the consent records obtained in the previous steps. In this example, since multiple consent records were obtained, the consent period is the period during which the periods of each consent overlap. More details are as follows.

[0118] Block 303, referenced by Block 309, is a consent record for handling, with the handling type being "Provision," the status being "Consent," and the effective date being "August 12, 2021." The oldest consent record for handling with an effective date after this date, with the handling type being "Provision" and the status being "Disagreement," is Block 317. The effective date of Block 317 is "August 20, 2021." Therefore, the consent period for "Provision" is set to "August 12, 2021 to August 19, 2021."

[0119] Block 300, obtained in step S103, is a consent record for handling, with the handling type being "Acquired," the status being "Consent," and the effective date being "August 11, 2021." The oldest consent record for handling with an effective date after this effective date, with the handling type being "Acquired" and the status being "Disagreement," is Block 313. The effective date of Block 313 is "August 20, 2021." The consent period for "Acquired" is set from August 11, 2021 to August 19, 2021.

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

[0121] <Consistency determination based on records and consent period> (Step S110) The processing unit 113 determines whether the processing date of the processing execution record to be verified is included in the agreement period. If the processing date is not included in the synchronization period, the processing unit 113 detects an inconsistency (S114). If the processing date is included in the agreement period, the process proceeds to the next step S111. In this example, the transaction date of the transaction execution record being verified is August 14, 2021, starting 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 processing unit 113 does not detect an inconsistency. Therefore, the process proceeds to the next step S111.

[0122] (Step S111) The processing unit 113 determines whether the processing date of the data receipt execution record is after the acquisition or receipt by the data provider. If the processing date is before the acquisition or receipt, an inconsistency is detected (S114). The processing unit 113 also determines whether the processing date of the acquisition or receipt is included in the agreement period, and if it is not included in the synchronization period, an inconsistency is detected (S114). If the processing date is after the acquisition or receipt, and the processing date of the acquisition or receipt is included in the agreement period, the process proceeds to the next step S112.

[0123] In this example, the transaction date of the receipt execution record (block 309) being verified is August 14, 2021. The transaction date of the acquisition execution record (block 307) is August 13, 2021. Therefore, since the receipt occurred after the acquisition, and the acquisition occurred within the agreement period, the processing unit 113 does not detect an inconsistency. Thus, the process proceeds to the next step S112.

[0124] (Step S112) The processing unit 113 determines whether there is a deletion operation record between the acquisition operation record and the receipt operation record. If a deletion operation record exists, the processing unit 113 detects an inconsistency (S114); otherwise, it proceeds to step S113.

[0125] In this example, the execution date of the deletion operation record (block 319) is August 20, 2021. Since there is no deletion operation record between the acquisition operation record and the receipt operation record, no inconsistency is detected.

[0126] (Step S113) The processing unit 113 determines whether the processing date of the receipt processing execution record matches the processing date of the provision processing execution record corresponding to the receipt processing execution record. If they do not match, the processing unit 113 detects an inconsistency (S114). If they do match, the processing unit 113 determines that there is no inconsistency in the processing execution record being verified (S115).

[0127] In this example, both the transaction execution record for receipt (block 309) and the transaction execution record for provision corresponding to the said transaction execution record for receipt (block 308) have the same transaction date: August 14, 2021. Therefore, it is determined that there is no inconsistency in the transaction execution record under verification (block 309) (S115).

[0128] If the transmitting unit 115 determines that no inconsistencies exist in step S115, it transmits information indicating that no inconsistencies were detected as a verification result to the requesting device. If an inconsistency is detected in step S114, the transmitting unit 115 transmits information indicating that an inconsistency was detected as a verification result to the requesting device. In this case, the reason why the inconsistency was detected may also be included in the verification result.

[0129] [Verification Example 2: Starting from the receipt transaction execution record, verification is performed using the BC User ID, which is a user identifier.] In this example, we assume that verification / audit device 1 is user device 701, but verification / audit device 1 can be any of the following: a party-related device, a data management device (handler device), or a user device, and it can also be any other information processing device.

[0130] Figure 12 is a flowchart showing an example of the operation in Verification Example 2. (Step S201) The receiving unit 111 receives a request for consistency verification of the receipt handling execution record indicated by block 309.

[0131] <Obtain relevant consent records and execution records for handling procedures> (Step S202) The search unit 112 searches for the provision handling consent record and acquisition history record related to the handling execution record of the receipt subject to verification. This yields blocks 303 and 320. If either the handling consent record or the acquisition history record does not exist on the blockchain, the processing unit 113 detects an inconsistency (S210). Alternatively, the processing unit 113 may detect an inconsistency if both the handling consent record and the acquisition history record do not exist on the blockchain, but not if either the handling consent record or the acquisition history record exists. This step is the same as step S102 in Figure 10.

[0132] (Step S203) The search unit 112 searches for a handling consent record in which the BC user ID, record type, handling type, and handler match the provided handling consent record (block 303), and obtains block 317.

[0133] (Step S205) The processing unit 113 searches for a provisioning execution record in which the provisioning consent ID is the same as the receipt execution record (block 309), and obtains block 308. If no provisioning execution record exists, the processing unit 113 detects an inconsistency (S210).

[0134] (Step S206) <Obtain consent and non-consent periods> The period calculation unit 114 obtains the consent period and the non-consent period based on the re-recording of the consent to handle the transaction obtained in the previous steps. Block 303, referenced by Block 309, is a consent record for handling, with the handling type being "Provision," the status being "Consent," and the effective date being "August 12, 2021." The oldest consent record for handling with an effective date after this date, with the handling type being "Provision" and the status being "Disagreement," is Block 317. The effective date of Block 317 is "August 20, 2021." Therefore, the consent period for "Provision" is set to "August 12, 2021 to August 19, 2021."

[0135] <Consistency determination based on records and consent period> (Step S207) The processing unit 113 determines 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 processing unit 113 detects an inconsistency (S210). If the transaction date is included in the agreement period, the process proceeds to the next step S208.

[0136] In this example, the processing date of the receipt execution record shown in block 309 under verification is August 14, 2021, which falls within the agreement period "August 12, 2021 to August 19, 2021," so no inconsistency is detected. Therefore, proceed to step S208.

[0137] (Step S208) The processing unit 113 determines whether the processing date of the receipt processing execution record matches the processing date of the provision processing execution record corresponding to the receipt processing execution record. If they do not match, the processing unit 113 detects an inconsistency. If they do match, the processing unit 113 determines that no inconsistency exists (S115). In this example, similar to step S113 in Figure 9, it is determined that no inconsistency exists.

[0138] [Verification Example 3: Verification based on a regular (real name or pseudonym) BC user ID, starting with the withdrawal of consent to acquisition] In this example, we assume that verification / auditing device 1 is data management device 101, but as with verification examples 1 and 2, verification / auditing device 1 may be any other device.

[0139] Figure 13 is a flowchart illustrating an example of the operation in Verification Example 3. Figure 14 is a flowchart following Figure 13. The receiving unit 111 receives a request for consistency verification of a handling consent record (block 313) whose status is "not consented" (step S501).

[0140] <Obtain relevant consent records and execution records for handling procedures> (Step S502) The search unit 112 searches for a transaction consent record that has the BC user ID of the transaction consent record to be verified, and whose items, excluding the transaction ID and status, match those of the transaction consent record. In this example, we search for a transaction consent record (block 313) where the BC user ID is "hanako" and all items except the transaction ID and status match those in the transaction consent record (block 313). This yields block 300.

[0141] (Step S503) The search unit 112 searches for the handling execution record that refers to the handling consent record (block 300) and obtains block 307.

[0142] (Step S504) The search unit 112 searches for the deletion execution record, which refers to the execution consent record (block 313) whose status is "disagreement," and obtains block 319. If the execution record does not exist in the blockchain, an inconsistency is detected.

[0143] (Step S505) If consent to acquisition has been withdrawn (block 313), consent to provision must also have been withdrawn. The system searches for the provision handling consent record corresponding to the handling consent record (block 313). The search unit 112 obtains the BC user ID corresponding to the user's identifier from the BC user ID of the usual identifier (real name or pseudonym) using identifier correspondence information. Using identifier correspondence information from the BC user ID of the usual identifier "hanako", the system obtains the corresponding BC user IDs "g7h8i9" and "j1k2m3". The system searches for the handling consent record where the BC user ID is "g7h8i9" or "j1k2m3", the record type is "Handling Consent", the handling type is "Provision", the provider is the handler "dealer1" in block 313, and the effective date is before the effective date in block 313. This obtains blocks 317 and 318.

[0144] The processing unit 113 detects an inconsistency if the consent record does not exist on the blockchain (S511).

[0145] <Obtain consent and non-consent periods> (Step S506) The period calculation unit 114 obtains the consent period and the non-consent period based on the consent records obtained in the previous steps. Based on Blocks 300 and 313, the consent period will be from August 11, 2021 to August 19, 2021. The non-consent period will be "from August 20, 2021 until the time of verification."

[0146] <Detecting inconsistencies from records and consent periods> (Step S507) If a record of the data acquisition or receipt process included in the agreement period exists on the blockchain, proceed to step S508; otherwise, proceed to step S509. In this example, since there is an execution record (block 307) for handling the acquisition of the corresponding data, the process proceeds to step S508.

[0147] (Step S508) The processing unit 113 determines whether a record of the deletion operation exists during the non-consent period. If it exists, no inconsistency is detected (S510); otherwise, the processing unit 113 detects an inconsistency (S511). In this example, no inconsistency is detected because a deletion execution record (block 319) with an execution date of "August 20, 2021" exists within the non-consent period "the period from August 20, 2021 to the time of verification".

[0148] (Step S509) The processing unit 113 determines whether a record of the deletion operation exists during the non-consent period. If it exists, an inconsistency is detected (S511); otherwise, no inconsistency is detected (S510). In the blockchain examples in Figures 2 and 3, no inconsistency is detected.

[0149] [Verification Example 4-1: Verification of Processing Records and Data Access Logs] Verification / auditing device 1 accesses correspondence table 91 and verifies the consistency between the processing records and data access logs for each data stakeholder. Figure 15 is a flowchart showing an example of the operation of verification / auditing device 1.

[0150] Step S301: Verification / Auditing device 1 receives a integrity verification request for the BC user ID (e.g., owner identifier) ​​of the data party.

[0151] Step S302: Verification / auditing device 1 obtains the BC User ID (owner identifier), which is the identifier for the user, from correspondence table 91 based on the BC User ID (owner identifier) ​​of the data person concerned.

[0152] Step S303: Verification / auditing device 1 obtains a transaction ID (consent information identifier) ​​for handling consent, including the BC user ID (owner identifier or user identifier), from the first storage system 201.

[0153] Step S304: Verification / auditing device 1 obtains the transaction ID (consent information identifier) ​​of the transaction consent from the first storage system 201, and the transaction ID of the transaction execution that includes the consent ID item. If the transaction execution record (record of processing) includes the BC user ID (user identifier) ​​of the data person concerned, the device may also obtain the transaction ID of the transaction execution that includes the BC user ID (owner identifier or user identifier) ​​of the data person concerned from the first storage system 201.

[0154] Step S305: Verification / Auditing device 1 verifies the consistency between the handling consent (record of consent) and the handling execution record (record of processing). The verification method is not limited to a specific one.

[0155] Step S306: Verification / auditing device 1 obtains data access logs (see Figure 16 below) related to the BC user IDs of data stakeholders (data owners, etc.) from the second storage system 601. In the data access logs, the BC user ID for the target recording business operator is used as the BC user ID of the data stakeholder (even for the same data stakeholder, the BC user ID will differ depending on the recording business operator). A recording business operator is a business operator that writes, reads, or deletes data, and can be a data handler, data user, or any other business operator.

[0156] Step S307: Verification / auditing device 1 verifies the consistency between the transaction execution record (records related to processing) that includes the BC user ID of the target record provider, obtained in Step S304, and the data access log. Verification / auditing device 1 detects an inconsistency if there is no consistency between the record source and the log source. The verification method is not limited to a specific one.

[0157] Step S308: The verification / audit device 1 determines that no inconsistencies are detected overall if no inconsistencies are detected in both Step S305 and Step S307. The verification / audit device 1 may output information (e.g., displayed on the screen) indicating that no inconsistencies are detected overall. If an inconsistency is determined in at least one of Step S305 and Step S307, the verification / audit device 1 determines that an inconsistency is detected overall. The verification / audit device 1 may output information indicating that an inconsistency has been detected overall. In this case, information identifying whether the inconsistency was detected in Step S305 or Step S307 may also be displayed on the screen.

[0158] The following provides specific examples of how each step works. Step S301: Verification / Auditing device 1 receives a integrity verification request for BC user ID (hanako).

[0159] Step S302: Verification / auditing device 1 obtains BC User ID (g7h8i9), which is the identifier for user A corresponding to BC User ID (hanako), and BC User ID (j1k2m3), which is the identifier for user B, from correspondence table 91.

[0160] Step S303: Verification / auditing device 1 retrieves transaction IDs 00, 03, 04, 13, 17, and 18 of the handling consent, which include BC user ID (hanako, g7h8i9, j1k2m3), from the first storage system 201.

[0161] Step S304: Verification / auditing device 1 retrieves transaction IDs 07, 08, 09, 10, 11, 12, 19 of transaction executions from the first storage system 201, which include transaction IDs 00, 03, 04, 13, 17, 18 of transaction consent as consent IDs.

[0162] Step S305: Verification / Auditing device 1 verifies the consistency between the handling consent (record of consent) and the handling execution record (record of processing). It determines that no inconsistencies are detected.

[0163] Step S306: Verification / auditing device 1 obtains data access logs related to BC user ID (hanako) from the second storage system 601 (see Figure 1).

[0164] Figure 16 shows an example of data access log 4-1. Log lines 1-5 are obtained from the data access log in Figure 16. The BC user ID of the target record maker is assumed to be dealer1. Based on dealer1, transaction IDs 07, 08, 10, 12, and 19 are obtained for the executed transactions.

[0165] Step S307: Verification / Auditing device 1 verifies the consistency between the record of the transaction execution and the data access log. In the verification of the starting point of the record, it is determined that the first line of the data access log corresponds to the acquisition record of transaction ID 07, ​​the second line of the data access log corresponds to the provision record of transaction ID 08, the third line of the data access log corresponds to the provision record of transaction ID 10, the fourth line of the data access log corresponds to the usage record of transaction ID 12, and the fifth line of the data access log corresponds to the deletion record of transaction ID 18. No inconsistencies are detected in the verification of the starting point of the record.

[0166] In log-based verification, it is determined that the first line of the data access log corresponds to the acquisition record of transaction ID 07, ​​and the fifth line of the data access log corresponds to the deletion record of transaction ID 18. No inconsistencies are detected in the log-based verification. Alternatively, it may be determined that the data access logs in lines 2-4 correspond to transactions IDs 08, 10, and 12 respectively, and that no inconsistencies are detected.

[0167] Therefore, verification / auditing device 1 determines that no inconsistency is detected between the handling execution record (record related to processing) and the data access log.

[0168] Step S308: Verification / auditing device 1 determines that no inconsistencies are detected overall, since no inconsistencies are detected in both Step S104 and Step S106.

[0169] [Verification Example 4-2: Verification of Processing Records and Communication Logs] Verification / auditing device 1 accesses correspondence table 91 and verifies the consistency between the handling execution record (records related to processing) and the communication log for each data stakeholder. Regarding the operation of the verification / auditing device in verification example 4-2, steps S301 to S305 and S308 in verification example 4-1 are also applied to verification example 4-2. The operation corresponding to steps S306 and S307 differs from that in verification example 4-1.

[0170] Step S306: Verification / auditing device 1 obtains communication logs regarding the BC user IDs of data personnel from the second storage system 601.

[0171] Step S307: Verification / Auditing device 1 verifies the consistency between the transaction execution record (records related to processing) that includes the BC user ID of the target record maker, which is indicated by the transaction ID obtained in Step S304, and the communication log. If inconsistency is determined in at least one of the record source and the log source, an inconsistency is detected (inconsistency is determined).

[0172] The following provides specific examples of how each step works. Steps S301-S305: These are the same as in Verification Example 4-1 and are therefore omitted. Step S306: Verification / auditing device 1 obtains a communication log related to BC user ID (hanako, g7h8i9, j1k2m3) from the second storage system 601.

[0173] Figure 17 shows an example of communication log 4-2. Verification / auditing device 1 is assumed to acquire only communication logs of personal data transmission and reception from the second storage system 601, and acquires lines 4-6 of the communication log in Figure 17. The BC user ID of the target record maker is assumed to be dealer1. Based on dealer1, transaction IDs 07, 08, 10, 12, and 19 of the transaction execution are acquired.

[0174] Step S307: Verification / Auditing device 1 verifies the consistency between the record of the transaction execution and the communication log. In the verification of the recording origin, line 4 of the communication log corresponds to transaction ID 07 (acquisition record), line 5 of the communication log corresponds to transaction ID 08 (provision record), and line 6 of the communication log corresponds to transaction ID 10 (provision record). No inconsistencies are detected in the verification of the recording origin.

[0175] In log-based verification, transaction ID 08 (provided record) corresponds to line 5 of the communication log, and transaction ID 10 (provided record) corresponds to line 6 of the communication log. No inconsistencies are detected in log-based verification. In this example, transaction ID 07 (acquisition record) exists corresponding to line 4 of the communication log, but it is also possible that transaction ID 07 (acquisition record) does not exist corresponding to line 4 of the communication log. For example, in the receipt or acquisition of personal data, after receiving personal data via the communication network, it is permissible to check whether consent for acquisition exists, and if there is no record of consent or the consent status is not consented, the operation of not writing the personal data is permissible. Therefore, the absence of an acquisition record corresponding to data reception is not necessarily an inconsistency. Thus, in log-based verification, it is not necessarily required to check whether transaction ID 07 (acquisition record) exists corresponding to line 4 of the communication log, and such a check is not performed in this example.

[0176] Therefore, verification / auditing device 1 determines that no inconsistency is detected between the handling execution record (record related to processing) and the communication log.

[0177] Step S308: This step is the same as in Verification Example 4-2 and is therefore omitted.

[0178] [Verification Example 4-3: Verification of Consent Records and Communication Logs] Verification / auditing device 1 accesses correspondence table 91 and verifies the consistency between consent records and communication logs for each data stakeholder. Regarding the operation of the verification / auditing device in verification example 4-3, steps S301 to S305 and S308 in verification example 4-1 are also applied to verification example 4-3. The operation corresponding to steps S306 and S307 differs from that in verification example 4-1.

[0179] Step S306: Verification / auditing device 1 obtains communication logs regarding the BC user IDs of data stakeholders from the second storage system 601. The BC user ID for the target processing operator is used in the log of receiving consent from the data stakeholders.

[0180] Step S307: Verification / Auditing device 1 verifies the consistency between the transaction ID obtained in Step S304, which indicates the handling consent, and the communication log, including the BC user ID of the target processing operator (record of consent). If there is no consistency between the record source and the log source, an inconsistency is detected (inconsistency is not found).

[0181] The following provides specific examples of the operation of each step. The data stakeholders' devices (stakeholder devices) do not directly access the first storage system 201, but access it via the target processing operator (e.g., the data handling operator's data management device 101). Therefore, the processing operator's device (e.g., the data management device 101) holds the communication log corresponding to the record of consent, and the handling operator's device (e.g., the data management device 101) is the recipient that receives the owner's consent.

[0182] Steps S301-S305: These are the same as in Verification Example 4-1 and are therefore omitted.

[0183] Step S306: Verification / auditing device 1 obtains communication logs related to BC user ID (hanako) from the second storage system 601. Assuming that only communication logs for receiving consent from data stakeholders are obtained, lines 1-3 and 7 of the communication log in Figure 17 are obtained. The BC user ID of the target processing operator is assumed to be dealer1. Based on dealer1, transaction IDs 00, 03, 04, 13, 17, and 18 for handling consent are obtained.

[0184] Step S307: Verification / Auditing device 1 verifies the consistency between the record of the handling consent (consent information) and the communication log. In the verification of the starting point of the record, it is determined that the first line of the communication log corresponds to the consent to acquire transaction ID 00, the second line of the communication log corresponds to the consent to provide transaction ID 03, the third line of the communication log corresponds to the consent to provide transaction ID 04, and the seventh line of the communication log corresponds to the withdrawal of consent to acquire transaction ID 13. The withdrawal of consent to provide for transaction ID 17 and transaction ID 18 is generated as an internal process based on the withdrawal of consent to acquire transaction ID 13, so there is no corresponding communication log. No inconsistency is detected in the verification of the starting point of the record.

[0185] In log-based verification, the first line of the communication log corresponds to the consent to acquire transaction ID 00, the second line corresponds to the consent to provide transaction ID 03, the third line corresponds to the consent to provide transaction ID 04, and the seventh line corresponds to the withdrawal of consent to acquire transaction ID 13. No inconsistencies are detected in the log-based verification.

[0186] Therefore, verification / auditing device 1 determines that no inconsistency is detected between the consent record and the communication log.

[0187] Step S308: This step is the same as in Verification Example 4-1 and is therefore omitted.

[0188] [Verification Example 4-4: Verification of Consent Records and Authentication Logs] Verification / auditing device 1 verifies the consistency between the consent record (consent information) and the authentication log for each data stakeholder (e.g., owner). It is assumed that the processing operator performing authentication for the data stakeholder has the authentication log corresponding to the consent record, or that Verification / auditing device 1 can access the authentication log.

[0189] When a data user gives consent to the data management device 101 for processing, and the data management device 101 registers consent information (a record of consent) based on the owner's consent, the data management device 101 authenticates the data owner. Any authentication method is acceptable, such as electronic certificate authentication, one-time password authentication, or multi-factor authentication. The data user accesses the data management device 101 using the user device 501 and inputs the information necessary to give consent (e.g., owner identifier, information specifying the content of consent, etc.) and the information necessary for authentication. The data management device 101 authenticates the data user based on the input information, and if authentication is successful, decides to register the consent information based on that consent; otherwise, rejects the registration of the consent information. The result of the authentication process (success or failure) is provided to and stored in the second storage system 601 as an authentication log.

[0190] In Verification Example 4-4, Verification / Auditing Device 1 accesses Correspondence Table 91 and verifies the consistency between consent records and authentication logs for each data stakeholder. Regarding the operation of the Verification / Auditing Device in Verification Example 4-4, steps S301-S305 and S308 in Verification Example 4-1 are also applied to Verification Example 4-4. The operations corresponding to steps S306 and S307 differ from those in Verification Example 4-1.

[0191] Step S306: Verification / auditing device 1 obtains an authentication log regarding the BC user ID of the data party from the second storage system 601. In the authentication log of the data party, the BC user ID for the target processing operator is used as the BC user ID of the data party. The processing operator is an operator that performs processing on behalf of the data party (for example, an operator that writes to or reads from the first storage system on behalf of the data party). The data party performs authentication regarding the legitimacy of the data party in order to request processing from the processing operator (specifically, this is done between the party device 501 and the data management device 101), and the result of the authentication is kept as an authentication log.

[0192] Step S307: Verification / Auditing device 1 verifies the consistency between the acquired consent (record of consent) which includes the BC user ID of the target processing operator among the handling consents indicated by the transaction ID obtained in Step S304, and the authentication log.

[0193] The following provides specific examples of the operation of each step. The data stakeholders' devices (stakeholder devices) do not access the first storage system 201 directly, but access it via the target processing operator's devices (e.g., data management device 101). Therefore, the processing operator's devices (e.g., data management device 101) hold the authentication log corresponding to the handling consent (record of consent).

[0194] Steps S301-S305: These are the same as in Verification Example 4-1 and are therefore omitted.

[0195] Step S306: Verification / auditing device 1 obtains an authentication log related to BC user ID (hanako) from the second storage system 601.

[0196] Figure 18 shows an example of authentication log 4-4. Verification / auditing device 1 acquires only the authentication logs of data stakeholders, and in this example, lines 1-4 of the authentication log in Figure 18 are acquired. The contents of the authentication log include whether authentication was successful or failed. The date and time is the date and time the authentication was performed, and may have a finer granularity than the date and time of the processing record. "Stakeholder" is the identifier of the person who was authenticated.

[0197] Furthermore, the BC user ID of the target processing operator (dealer1) will be used. Based on dealer1, transaction IDs 00, 03, 04, 13, 17, and 18 for handling consent will be obtained.

[0198] Step S307: Verification / Auditing device 1 verifies the consistency between the record of the handling consent (consent information) and the authentication log. In the verification of the recording origin, the first line of the authentication log corresponds to the acquisition consent for transaction ID 00, the second line of the authentication log corresponds to the provision consent for transaction ID 03, the second line of the authentication log corresponds to the provision consent for transaction ID 04, and the fourth line of the authentication log corresponds to the withdrawal of acquisition consent for transaction ID 13. The withdrawal of provision consent for transaction ID 17 and transaction ID 18 is generated as an internal process based on the withdrawal of acquisition consent for transaction ID 13, so there is no corresponding authentication log. No inconsistencies are detected in the verification of the recording origin.

[0199] Therefore, verification / auditing device 1 determines that no inconsistency is detected between the handling consent (record of consent) and the authentication log.

[0200] Step S308: This step is the same as in Verification Example 4-1 and is therefore omitted.

[0201] As described above, according to this embodiment, by using audit records or acquisition history records, it is possible to store various records in the first storage system while preventing the leakage of relationships between individuals and other related parties and third parties (users, first business operators), i.e., relationships shown in the identifier correspondence table. Furthermore, by avoiding duplicate records of receipt consent and provision consent, the impact on the capacity of the first storage system can be reduced. In addition, by using acquisition history records, it becomes possible to verify that the user has the legitimate consent of the relevant parties regarding the handling of the data.

[0202] (Second embodiment: Using audit records for consistency verification) In the first embodiment, acquisition history records were used for consistency verification (see, for example, step S103 in Figure 10). As mentioned above, acquisition history records can be created after each user confirms the legitimacy of receiving data from the data handler when initiating a transaction with the data handler. In this case, when a provision agreement record is created for each user as the recipient, it is assumed that the respective acquisition history records already exist. On the other hand, audit records are created by the auditor or the auditor's device after the provision agreement record has been created. Therefore, depending on the timing of the audit, a situation may occur where a provision agreement record exists but an audit record does not. Thus, the process of generating the blockchain in the first embodiment includes the next step in which the user uses audit records or acquisition history records. In this embodiment, the auditor's device is also the verification / audit device 1. However, the auditor's device may be a different device from the verification / audit device 1. In the following description, the process related to the generation of audit records will partially overlap with the description of the first embodiment.

[0203] User device 701 of user A, who is receiving the data, confirms that it is permissible to receive the data based on the blockchain (e.g., blocks 303 and 320) before receiving the data (A108 in Figure 4).

[0204] User device 701 of user B, who is receiving the data, confirms that it is permissible to receive the data based on the blockchain (e.g., blocks 304 and 321) before receiving the data (A112).

[0205] More specifically, at step A110, user A's device 701 can detect block 303 using the identifier "g7h8i9" for user A as the key, and further detect block 320 of the acquisition history. This allows confirmation that the received data was provided with consent, and that the acquisition history of the received data is clear. Similarly, at step A113, user B's device 701 can detect block 304 using the identifier "j1k2m3" for user B as the key, and further detect block 321 of the acquisition history, thereby performing a similar confirmation.

[0206] Here, if the data source is not listed in the acquisition history record to prevent the leakage of the correspondence between identifiers representing data stakeholders, then simply checking the acquisition history record will not confirm the consent record for handling the acquisition of individual data stakeholders. Therefore, the process of generating the blockchain includes the following steps by the auditor or the auditor's device (verification / audit device 1).

[0207] The verification / auditing device 1 records as an audit record that there is a handling consent record corresponding to block 303 (A131 in Figure 5). This generates block 322, which indicates the existence of the handling consent record for block 300. Block 322 allows even a user who only knows the BC user ID "g7h8i9" to recognize that the data handler's contact person "hanako," corresponding to "g7h8i9," has consented to the data handler acquiring the data. Similarly, it records as an audit record that there is a handling consent record corresponding to block 304 (A132 in Figure 5). This generates block 323, which indicates the existence of the handling consent record for block 300. The steps for generating these audit records may be performed at times other than steps A131 and A132 in Figure 5, depending on when the audit is performed. For example, each audit record may be performed at any time after steps A102 and A103 in Figure 4 (for example, between step A102 and step A106, or between step A103 and step A106). If we assume that the audit record blocks generated at times other than steps A131 and A132 are blocks 322a and 323a, then the "execution date" of blocks 322a and 323a may differ from that of blocks 322 and 323, but the contents of the other items in blocks 322a and 323a will match those of blocks 322 and 323.

[0208] In this case, it is desirable that user A confirms the consent record for handling the provision for which a corresponding audit record exists using block 322a in step A108 of Figure 4, and user B confirms it using block 323a in step A112 of Figure 4.

[0209] Similarly, for step S202 (see Figure 12) of Verification Example 2 of the first embodiment, a variation in which audit records are used instead of acquisition history records is shown below as step S202'.

[0210] (Step S202') The search unit 112 searches for the handling consent record and audit record of the provision that are related to the handling execution record of the receipt to be verified. This yields blocks 303 and 322 (see Figure 11). Block 303 is the reference to the handling execution record of the receipt. Block 322 references block 303 as the provision consent ID. If either the handling consent record or the audit record does not exist on the blockchain, the processing unit 113 detects an inconsistency (S210). Alternatively, the processing unit 113 may detect an inconsistency if both the handling consent record and the audit record do not exist on the blockchain, but not if either the handling consent record or the acquisition history record exists.

[0211] In step S102 (see Figure 10) of Verification Example 1 of the first embodiment, the acquisition history record is searched, and in step S103, the corresponding acquisition handling consent record is used. This is because it is assumed that the verifier in Verification Example 1 has access to the user identifier correspondence table. The same applies to Verification Example 3. On the other hand, in Verification Example 2, it is assumed that the verifier does not have access to the user identifier correspondence table, so verification using the corresponding acquisition handling consent record is not possible. Therefore, the existence of the corresponding acquisition handling consent record is confirmed in the audit record.

[0212] In the example shown in Figure 6, audit records are generated for each consent to provide, from block 322 to block 325.

[0213] Figure 19 shows variations in audit records. Audit records may be generated for multiple provision consents together, as shown in blocks 326, 327, and 328. When consolidating, all provision consents with handling consent for a certain period may be grouped together (block 326), or provision consents with handling consent for each recipient may be grouped together (blocks 327, 328). However, grouping by data stakeholders should be avoided as it could lead to the leakage of correspondence tables.

[0214] The audit record may be generated as "Yes" if consent for handling exists, or as "No" if consent for handling does not exist, or both. Alternatively, the audit record may be generated if consent for handling exists, but not if it does not exist. Alternatively, the audit record may not be generated if consent for handling exists, but may be generated if consent for handling does not exist.

[0215] As described above, according to this embodiment, by using audit records, it is possible to store various records in the first storage system while preventing the leakage of relationships between individuals and other related parties and third parties (users, first business operators), i.e., relationships shown in the identifier correspondence table. Furthermore, it becomes possible to verify that the user has the legitimate consent of the relevant parties regarding the handling of data using audit records.

[0216] (Third embodiment: Verification of the integrity of audit records and logs) It is also conceivable that the verification / audit device 1 would perform consistency verification of the auditor's audit records against the logs. When the auditor's device (verification / audit device 1 in this example) accesses the first storage system 201 via the data management device 101, the auditor's communication logs, authentication logs, or both are stored in the second storage system 601. In this case, verification / audit device 1 corresponds to the first device that generates the audit records including the auditor's identifier, and data management device 101 corresponds to the second device that receives the audit records and writes them to the first storage system 201. Therefore, similar consistency verification is possible for the auditor's communication logs and authentication logs. However, even when verification / audit device 1 accesses the first storage system 201 without going through data management device 101, similar consistency verification is possible for the auditor's communication logs and authentication logs, as long as they can be obtained.

[0217] [Verification Example 4-3': Verification of Audit Records and Communication Logs] Verification / audit device 1 verifies the consistency between the audit record and the communication log for each auditor. Regarding the operation of the verification / audit device in Verification Example 4-3', step S308 in Verification Example 4-3 (see Figure 15) is also applied to Verification Example 4-3'. The operations corresponding to steps S301, S303, S305, S306, and S307 differ from Verification Example 4-3 and are changed to the following steps S301', S303', S305', S306', and S307'. Steps S302 and S304 are unnecessary. Step S308 is the same as in Verification Example 4-3.

[0218] Step S301': Verification / auditing device 1 receives a integrity verification request for the auditor's BC user ID.

[0219] Step S302: Not required.

[0220] Step S303': Verification / auditing device 1 obtains the transaction ID (consent information identifier) ​​of the audit record, including the BC user ID, from the first storage system 201.

[0221] Step S304: Not required.

[0222] Step S305': Verification / audit device 1 verifies the consistency between the handling consent (record of consent) and the audit record. For example, there is a method as shown in the second embodiment. The verification method is not limited to any particular one.

[0223] Step S306': Verification / auditing device 1 obtains a communication log regarding the auditor's BC user ID from the second storage system 601.

[0224] Step S307': Verification / auditing device 1 verifies the consistency between the audit record indicated by the transaction ID obtained in step S303' and the communication log. If there is inconsistency between the record source and the log source, it is determined that an inconsistency has been detected (inconsistency).

[0225] The following provides specific examples of the operation of each step. The verification / audit device 1 does not directly access the first storage system 201, but accesses it via the target processing operator (in this embodiment, the data management device 101 of the data handling operator). In this embodiment, the verification / audit device 1 also serves as the auditor device, but the auditor device may be a different device from the verification / audit device 1. The processing operator's device (in this embodiment, the data management device 101) holds the communication log corresponding to the audit record, and the receiver that receives the audit record is the processing operator's device (in this embodiment, the data management device 101).

[0226] Step S301': Verification / auditing device 1 receives a integrity verification request for BC user ID (auditor1).

[0227] Step S303': Verification / auditing device 1 retrieves transaction IDs 200, 201, 202, and 203 (see Figure 6) of the audit record, including the BC user ID (auditor1), from the first storage system 201.

[0228] Step S305': This is omitted as it is the same as in the second embodiment.

[0229] Step S306': Verification / auditing device 1 obtains a communication log related to BC user ID (auditor1) from the second storage system 601. Assuming that only the communication log for receiving the audit record is to be obtained, lines 8 to 11 of the communication log in Figure 17 are obtained.

[0230] Step S307': Verification / auditing device 1 verifies the consistency between the audit record and the communication log. In the verification of the recording origin, it is determined that line 8 of the communication log corresponds to transaction ID 200, line 9 of the communication log corresponds to transaction ID 201, line 10 of the communication log corresponds to transaction ID 202, and line 11 of the communication log corresponds to transaction ID 203. No inconsistencies are detected in the verification of the recording origin.

[0231] Log-based verification shows that line 8 of the communication log corresponds to transaction ID 200, line 9 corresponds to transaction ID 201, line 10 corresponds to transaction ID 202, and line 11 corresponds to transaction ID 203. No inconsistencies are detected in the log-based verification.

[0232] Therefore, verification / auditing device 1 determines that no inconsistency is detected between the audit record and the communication log.

[0233] Step S308: This step is the same as in Verification Example 4-1 and is therefore omitted.

[0234] [Verification Example 4-4': Verification of Audit Records and Authentication Logs] Verification / auditing device 1 verifies the consistency between the audit record and the authentication log for each auditor. Regarding the operation of the verification / auditing device in Verification Example 4-4', steps S301'~S305' and S308 in Verification Example 4-3' are also applied to Verification Example 4-4'. The operations corresponding to steps S306' and S307' differ from Verification Example 4-4' and are changed to the following steps S306'' and S307''.

[0235] Step S306'': Verification / auditing device 1 obtains an authentication log regarding the auditor's BC user ID from the second storage system 601.

[0236] Step S307'': Verification / auditing device 1 verifies the consistency between the audit record indicated by the transaction ID obtained in step S303' and the authentication log.

[0237] The following provides specific examples of the operation of each step. Verification / auditing device 1 does not directly access the first storage system 201, but accesses it via the device of the target processing operator (e.g., data management device 101). Therefore, the authentication log corresponding to the audit record is held by the processing operator's device (e.g., data management device 101).

[0238] Steps S301' to S305': These are the same as in Verification Example 4-3' and are therefore omitted.

[0239] Step S306'': Verification / auditing device 1 obtains an authentication log related to BC user ID (auditor1) from the second storage system 601.

[0240] Assuming we only want to obtain the auditor's authentication log, we obtain the 5th line of authentication log 4-4 ​​in Figure 18.

[0241] Step S307'': Verification / auditing device 1 verifies the consistency between the audit record and the authentication log. In the verification of the recording origin, the 5th line of the authentication log corresponds to transaction ID 200, the 5th line of the authentication log corresponds to transaction ID 201, the 5th line of the authentication log corresponds to transaction ID 202, and the 5th line of the authentication log corresponds to transaction ID 203. No inconsistencies are detected in the verification of the recording origin.

[0242] Therefore, verification / auditing device 1 determines that no inconsistency is detected between the audit record and the authentication log.

[0243] Step S308: This step is the same as in Verification Example 4-1 and is therefore omitted.

[0244] In this embodiment, communication logs and authentication logs were used as logs of operations related to the generation of audit records, but other logs can also be used. For example, if the verification / auditing device 1 can directly write audit records to the first storage system 201, access logs may be used.

[0245] As described above, according to this embodiment, it becomes possible to verify the integrity of audit records by using logs of operations performed in relation to the generation of audit records (communication logs, authentication logs, etc.).

[0246] (Hardware configuration) Figure 20 shows the hardware configuration of the verification / audit device 1 (information processing device). The data management device 101, the personnel device 501, and the user device 701 have similar hardware configurations. The verification / audit device 1 is composed of a computer 900. The computer 900 comprises a CPU 901, an input interface 902, a display device 903, a communication device 904, a main memory 905, and an external memory device 906, which are interconnected by a bus 907.

[0247] The CPU (Central Processing Unit) 901 executes an information processing program, which is a computer program, on the main memory 905. The information processing program is a program that implements each of the above-described functional configurations of the verification / auditing device 1. The information processing program may not be a single program, but rather a combination of multiple programs or scripts. Each functional configuration is realized when the CPU 901 executes the information processing program.

[0248] The input interface 902 is a circuit for inputting operation signals from input devices such as keyboards, mice, and touch panels to the verification / auditing device 1.

[0249] The display device 903 displays the data output from the verification / auditing device 1. The display device 903 is, for example, an LCD (liquid crystal display), an organic electroluminescent display, a CRT (cathode ray tube), or a PDP (plasma display), but is not limited to these.

[0250] The communication device 904 is a circuit for the verification / auditing device 1 to communicate with an external device wirelessly or via a wired connection. Data can be input from an external device via the communication device 904. The data input from the external device can be stored in the main memory 905 or the external memory 906.

[0251] The main memory 905 stores information processing programs, data necessary for the execution of the information processing programs, and data generated by the execution of the information processing programs. The information processing programs are deployed and executed on the main memory 905. The main memory 905 is, for example, RAM, DRAM, or SRAM, but is not limited to these. Each storage unit or database of the verification / auditing device 1 may be built on the main memory 905.

[0252] The external storage device 906 stores information processing programs, data necessary for the execution of the information processing programs, and data generated by the execution of the information processing programs. These information processing programs and data are read into the main storage device 905 when the information processing programs are executed. The external storage device 906 is, for example, a hard disk, optical disk, flash memory, and magnetic tape, but is not limited to these. Each storage unit or database of the verification / audit device 1 may be built on the external storage device 906.

[0253] The information processing program may be pre-installed on the computer 900, or it may be stored on a storage medium such as a CD-ROM. Furthermore, the information processing program may be uploaded to the internet.

[0254] Furthermore, the verification / auditing device 1 may consist of a single computer 900, or it may be configured as a system consisting of multiple interconnected computers 900.

[0255] It should be noted that the present invention is not limited to the embodiments described above, and the components can be modified and implemented in practice without departing from the spirit of the invention. Furthermore, various inventions can be formed by appropriately combining the multiple components disclosed in the embodiments described above. For example, a configuration in which some components are removed from all the components shown in each embodiment is also conceivable. Moreover, components described in different embodiments may be appropriately combined. [Explanation of Symbols]

[0256] 1 Verification / Audit Device (Information Processing Device) 4-1 Data Access Log 4-2 Communication Log 4-4 Authentication Log 91 Identifier Correspondence Table 101 Data Management Device (Handler Device, Information Processing Device) 111 Receiver 112 Search Section 113 Processing Section 114 Period Calculation Section 115 Transmitter 116 Memory Section 201 First Memory System (Block Chain System) 501 Related Person Device 601 Second Memory System 701 User Device (Information Processing Device) 900 Computer 901 CPU 902 Input Interface 903 Display Device 904 Communication Device 905 Main Memory Device 906 External Memory Device 907 Bus

Claims

1. From records held in a first storage system that holds at least one of records relating to the handling of the data of a party concerned and records relating to the consent to the handling of said data, a first consent record is identified which includes a first business identifier that identifies the party concerned and is exclusively assigned to the first business operator, and the party concerned's consent for the first business operator to perform the first handling on the party concerned's data. A processing unit that detects the relevant party identifier corresponding to the first business identifier included in the first consent record, based on correspondence data that associates the relevant party identifier with the first business identifier, and a relevant party identifier that identifies the relevant party and has a value different from the first business identifier. The system includes a search unit that retrieves from the first storage system a second consent record, which includes the consent of the said party to perform the second handling on the said data, based on the said party identifier, The relationship between the first handling and the second handling is such that the second business operator performing the second handling on the data enables the first business operator to perform the first handling on the data. The processing unit generates an audit record to be stored in the first storage system, which includes a record identifier that identifies the first consent record and information regarding the existence of the second consent record, based on the search results of the second consent record. Information processing device.

2. The processing unit generates the audit record, which includes the record identifier of the first consent record and information indicating the existence of the second consent record, when the second consent record is detected. The information processing apparatus according to claim 1.

3. The processing unit generates the audit record, which includes the record identifier of the first consent record and information indicating that the second consent record does not exist, if the second consent record is not detected. The information processing apparatus according to claim 1.

4. The first handling includes the first business operator receiving or acquiring the data from the second business operator. The information processing apparatus according to claim 1.

5. The second handling includes the second business operator receiving or acquiring the data from the relevant parties. The information processing apparatus according to claim 4.

6. Multiple of the aforementioned first businesses are each assigned a first business identifier with a different value. The information processing apparatus according to claim 1.

7. The data includes a receiving unit that receives a request to verify the consistency of the transaction execution record indicating that the first business operator performed the first transaction, The search unit searches the first storage system for the operation execution record based on the verification request. The processing unit obtains an identifier for the first consent record, which includes the consent of the parties concerned to perform the first handling for the first business operator, from the handling execution record. The search unit searches the first consent record from the first storage system based on the identifier of the first consent record. The first storage system retrieves an audit record containing an identifier for the first consent record and information indicating whether or not the second consent record exists. The processing unit verifies the consistency of the handling execution record based on the first consent record and the audit record. The information processing apparatus according to claim 1.

8. The processing unit detects an inconsistency in the transaction execution record if at least one of the first consent record and the audit record, which includes information indicating the existence of the second consent record, is not detected. The information processing apparatus according to claim 7.

9. The processing unit detects an inconsistency in the handling execution record when the audit record, which includes information indicating that the first consent record and the second consent record do not exist, is detected. The information processing apparatus according to claim 7.

10. The aforementioned audit record includes the auditor's identifier, The system includes a receiving unit that receives a request to verify the integrity of the audit record, which includes the identifier of the auditor, The processing unit retrieves the log associated with the auditor's identifier from a second storage system that stores logs of operations performed in connection with the generation of the audit record, associated with the auditor's identifier. The processing unit verifies the integrity of the audit record based on the log. The information processing apparatus according to claim 1.

11. The second storage system maintains the log of communications relating to the audit record between the first device that generates the audit record including the auditor's identifier and the second device that receives the audit record and writes it to the first storage system. The processing unit verifies the integrity of the audit record based on whether or not the receipt of the audit record, which includes the auditor's identifier, is included in the communication log. The information processing apparatus according to claim 10.

12. The second storage system maintains the log of communications relating to the audit record between the first device that generates the audit record including the auditor's identifier and the second device that receives the audit record and writes it to the first storage system. The system retrieves the audit record, which includes the auditor's identifier related to the log of the aforementioned communication, from the first storage system, and verifies the integrity of the audit record according to the search results of the audit record. The information processing apparatus according to claim 10.

13. The second storage system performs the authentication process for the auditor and, if the authentication process is successful, stores the audit record in the first storage system. The log of the results of the authentication process performed by the third device is stored in the first storage system. The processing unit verifies the integrity of the audit record depending on whether the successful authentication of the auditor is included in the log. The information processing apparatus according to claim 10.

14. The processing unit sends a request to the device that writes records to the first storage system to write the audit record to the first storage system. The information processing apparatus according to claim 1.

15. The first memory system is a blockchain. The information processing apparatus according to claim 1.

16. From records held in a first storage system that holds at least one of records relating to the handling of the data of a party concerned and records relating to the consent to the handling of said data, a first consent record is identified which includes a first business identifier that identifies the party concerned and is exclusively assigned to the first business operator, and the party concerned's consent for the first business operator to perform the first handling on the party concerned's data. Based on the correspondence data that associates a related party identifier that identifies the related party and has a value different from the first business operator identifier with the first business operator identifier, the related party identifier corresponding to the first business operator identifier included in the first consent record is detected. Based on the aforementioned party identifier, the first storage system retrieves a second consent record, which includes the consent of the party to perform the second handling on the data, The relationship between the first handling and the second handling is such that the second business operator performing the second handling on the data enables the first business operator to perform the first handling on the data. Based on the search results for the second consent record, an audit record to be stored in the first storage system is generated, which includes a record identifier that identifies the first consent record and information regarding the existence of the second consent record. Information processing methods.

17. Steps of identifying a first consent record from records held in a first storage system that holds at least one of records relating to the handling of data of a party concerned and records relating to the consent of the party concerned to the handling of said data, including a first business identifier that identifies the party concerned and is exclusively assigned to the first business operator, and the party concerned's consent for the first business operator to perform the first handling on the party concerned's data, A step of detecting the relevant party identifier corresponding to the first business identifier included in the first consent record, based on correspondence data that associates the relevant party identifier having a value different from the first business identifier with the first business identifier, A step of retrieving from the first storage system a second consent record, which includes the consent of the said party to perform the second handling on the said data, based on the said party identifier, A step of generating an audit record to be stored in the first storage system, which includes a record identifier that identifies the first consent record and information regarding the existence of the second consent record, based on the search results of the second consent record. Have the computer run it, The first handling and the second handling are related by a computer program such that the second business operator can perform the second handling on the data, thereby enabling the first business operator to perform the first handling on the data.

Images