Information processing device, information processing method, and computer program

Abstract

To provide an information processing device, an information processing method, and a computer program that enable verification of whether or not processing indicated in a record is properly executed.SOLUTION: An information processing device according to an embodiment comprises a processing unit that acquires, from a first storage system that holds at least one of records of processing of data and a record of consent to processing of data, the record, acquires, form a second storage system that holds a log of an action taken in connection with at least one of the processing and the consent, the log, and verifies, on the basis of the log acquired, consistency related to the acquired record.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present embodiment relates to an information processing device, an information processing method, and a computer program. [Background technology]

[0002] The Act on the Protection of Personal Information (hereinafter referred to as the Personal Information Protection Act) requires that businesses handling personal information (including sensitive personal information) obtain the consent of the individual, i.e., the owner of the personal data, in advance when acquiring, using, etc., that personal information (including sensitive personal information). For example, businesses handling personal information will create a record of such consent and confirm whether or not the owner's consent is given when carrying out a process that requires such consent.

[0003] In order to make it possible to trace the flow of personal data provision, when a personal information handling business entity provides personal data to a third party, the entity is required to create a record of the provision and store the record for a certain period of time. For example, the personal information handling business entity records the provision of personal data together with the name of the owner, the owner's consent, the items of personal data, the name of the third party to whom the data was provided, and the like. In addition, the personal information handling business entity, which is the third party to whom the personal data was provided, is required to confirm how the personal information handling business entity that provided the personal data acquired the provided personal data, create a record of receipt, and store the record for a certain period of time. For example, the third party to whom the personal data was provided, in other words, the user of the personal data, confirms the name of the personal information handling business entity that provided the data and how the personal information handling business entity that provided the data acquired the provided personal data, and records the receipt of the personal data together with the confirmed information.

[0004] In order to make it possible to verify the processing performed on personal data, in addition to records of provision (provision records) and receipt (reception records), personal information handlers also prepare and retain for a certain period of time, for example, records of acquisition of personal data (acquisition records), records of generation (e.g. data generated by processing personal data) (generation records), and records of deletion (deletion records). These records are collectively referred to as processing records. A mechanism is needed for owners or auditors to verify whether the processing of personal data by personal information handling entities is actually being performed as shown in the records, that is, whether the processing records reflect the execution of the processing by the personal information handling entity, but such a mechanism does not currently exist. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Patent Publication No. 2021-48546 Summary of the Invention [Problem to be solved by the invention]

[0006] The present embodiment provides an information processing device, an information processing method, and a computer program that enable verification of whether a process indicated in a record has been properly executed. [Means for solving the problem]

[0007] The information processing device of this embodiment includes a processing unit that acquires records regarding processing of data and / or records regarding consent to processing of data from a first storage system that holds the records, acquires the logs from a second storage system that holds logs of operations performed in relation to at least one of the processing and the consent, and verifies the consistency of the acquired records based on the acquired logs. [Brief description of the drawings]

[0008] [Figure 1]1 is a diagram showing the overall configuration of a data management system according to a first embodiment. [Diagram 2] FIG. 2 is a diagram showing an example of personal data and its attribute information. [Diagram 3] FIG. 13 is a diagram showing examples of data types and details, an example of a business identifier, an example of an identifier for the purpose of data processing (purpose identifier), and an example of a revocation identifier related to handling when consent information is revoked. [Figure 4] 4A to 4C are diagrams showing examples of attribute information, request information, and consent information of personal data. [Diagram 5] FIG. 11 is a diagram showing other examples of attribute information, request information, and consent information of personal data. [Figure 6] 13 is a diagram showing still another example of attribute information, request information, and consent information of personal data. [Figure 7] FIG. 13 shows an example of a record of provision and an example of a record of receipt. [Figure 8] 11A and 11B are diagrams showing examples of attribute information of analysis result data (generated data) and examples of analysis records. [Figure 9] FIG. 13 is a diagram showing an example of acquisition record. [Figure 10] 4 is a flowchart of an example of processing according to the first embodiment. [Figure 11] FIG. 11 is a diagram showing an example of a data access log. [Figure 12] FIG. 13 is a diagram showing an example of a deletion record. [Figure 13] FIG. 4 is a diagram showing an example of a communication log according to the first embodiment. [Figure 14] FIG. 11 is a diagram showing another example of the communication log according to the first embodiment. [Figure 15] 11 is a flowchart of an example of an operation according to the first to third embodiments. [Figure 16] FIG. 11 is a diagram showing an example of consent information (information on revocation of consent). [Figure 17] FIG. 4 is a diagram showing an example of an authentication log according to the first embodiment. [Figure 18] FIG. 11 is a diagram showing the overall configuration of a data management system according to a second embodiment. [Figure 19] FIG. 11 is a diagram showing an example of a correspondence table according to the second embodiment. [Figure 20]FIG. 13 is a diagram showing an example of a correspondence table in which owner identifiers 2 are pseudonyms. [Figure 21] 10 is a flowchart illustrating an example of the operation of a verification apparatus according to the second embodiment. [Figure 22] FIG. 11 is a diagram showing another example of the data access log according to the second embodiment. [Figure 23] FIG. 11 is a diagram showing an example of a communication log according to the second embodiment. [Figure 24] FIG. 13 is a block diagram showing an example of a data management system according to a third embodiment. [Diagram 25] FIG. 13 is a diagram showing an example of a blockchain according to a third embodiment. [Figure 26] Continued from Figure 25. [Figure 27] 13 is a flowchart illustrating an example of the operation of the verification apparatus according to the third embodiment. [Figure 28] FIG. 13 is a diagram showing an example of a data access log according to the third embodiment. [Figure 29] FIG. 13 is a diagram showing an example of a communication log according to the third embodiment. [Diagram 30] FIG. 13 is a diagram showing an example of an authentication log according to the third embodiment. [Diagram 31] FIG. 2 is a diagram showing a hardware configuration of a verification device (information processing device). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In the drawings, the same elements are given the same reference numerals, and descriptions thereof will be omitted as appropriate, except for modified or expanded processes.

[0010] (First embodiment) <Embodiment 1-1>

[0011] Fig. 1 is an overall configuration diagram of a data management system which is an information processing system according to the first embodiment. The data management system in Fig. 1 includes a verification device 1 which is an information processing device according to the present embodiment, a data management device 101, a consent information / history information storage system 201 (hereinafter, referred to as the first storage system 201), a data transmission source device 301, a data reception device 401, an owner device 501, and a second storage system 601.

[0012] The verification device 1 is connected to the first storage system 201 and the second storage system 601 via a communication network. The data management device 101 is connected to the first storage system 201, the data source device 301, the data destination device 401, and the second storage system 601 via a communication network. The data management device 101 may be connected to the owner device 501 via a communication network. The owner device 501 is connected to the first storage system 201 via a communication network. The data source device 301 and the data destination device 401 may be connected to the first storage system 201 via a communication network. Each communication network may be a wide area network such as the Internet or a mobile network, a local area network such as Ethernet or a wireless LAN (Local Area Network), or a cable such as a serial communication cable. The data management device 101 is configured by a computer including a processor such as a CPU (Central Processing Unit) and a memory, for example.

[0013] The data management device 101 receives request information requesting processing of data related to a certain individual from a device or system of a business entity that manages the data management device 101, a data source device 301, a data destination device 401, or an owner device 501. The transmission of request information from the data source device 301 or the data destination device 401 to the data management device 101 may be performed by the device or system of the business entity that manages the data management device 101 or the owner device 501 requesting the data source device 301 or the data destination device 401 to transmit the request information. Data related to an individual is, for example, personal data, analysis result data obtained by analyzing personal data (data generated based on personal data), etc. In the following, when simply described as data, it means data related to an individual, and may be either personal data or analysis result data. The request information is, for example, information requesting the provision of data to another business entity, the use of data (analysis, etc.), or the acquisition of data from an individual. The provision of data to another business entity means at least one of receiving and holding (storing) data from the perspective of the other business entity. Therefore, a request for the provision of data includes at least one of a request to receive and hold (storage) the data. The data management device 101 acquires consent information (a record related to consent) including consent conditions under which an individual agrees to processing of his / her personal data from the first storage system 201. The data management device 101 determines whether or not processing can be performed on the data based on the acquired consent information and request information. The data management device 101 performs processing on the data depending on the result of the determination of whether or not processing can be performed. When processing is performed, the data management device 101 creates a record indicating the content of the processing, etc., and registers the record in the first storage system 201.

[0014] The owner device 501 is a device operated by an individual who is the owner of personal data. Examples of the owner device 501 include a notebook or desktop personal computer (PC), a smartphone, and a tablet terminal. The individual can register one or more pieces of consent information in the first storage system 201 from the owner device 501. The individual can also transmit personal data from the owner device 501 to the data management device 101. In other words, the data management device 101 can receive (acquire) personal data from the owner device 501.

[0015] The first storage system 201 stores consent information of one or more individuals. The first storage system 201 also stores a record history indicating the contents of the processing performed by the data management device 101. The first storage system 201 is a system capable of storing information. The part of the first storage system 201 that stores consent information corresponds to a consent information storage unit, and the part that stores the record history corresponds to a record storage unit. The first storage system 201 is, for example, a blockchain system or a database. When the first storage system 201 is a blockchain system, the consent information and the record may be managed as transactions in the same blockchain, or may be managed in separate blockchain systems. When the first storage system 201 is a database, the consent information and the record may be managed in the same database, or may be managed in separate databases.

[0016] The data transmission source device 301 is a device that requests the data management device 101 to process (provide, use (analyze, etc.), acquire, etc.) data such as personal data. Alternatively, the data transmission source device 301 may receive a request for data processing from a device or system (a device or system other than the data management device 101 shown in the figure) of a business entity that manages the data management device 101, or from the owner device 501. The data transmission source device 301 may request the data management device 101 to process data based on the request. As an example, the data transmission source device 301 is operated by an employee (user) who works for the business entity that manages the data transmission source device 301. The data transmission source device 301 transmits request information to the data management device 101. Alternatively, the data transmission source device 301 receives a request and transmits request information to the data management device 101 in response to the request. Depending on the type of request information, the data to be processed is also transmitted to the data management device 101. The data transmission source device 301 may be a data management device other than the data management device 101 (a device having the same configuration as the data management device 101). The operator who manages the data management device 101 and the operator who manages the data transmission source device 301 may be the same operator. The operator who manages the data management device 101 and the operator who manages the data transmission source device 301 may be different operators. The data transmission source device 301 may be the same as the owner device 501.

[0017] The data receiving device 401 is a device that receives data (personal data or analysis result data, etc.) from the data management device 101. The data receiving device 401 may receive a request for processing (provision, use (analysis, etc.)) of data from a device or system (a device or system other than the data management device 101 shown in the figure) of a business entity that manages the data management device 101 or from the owner device 501. The data receiving device 401 may request the data management device 101 to process data based on the request. The data receiving device 401 may also request the data management device 101 to process (provision, use (analysis, etc.), acquisition, etc.) data such as personal data. The data receiving device 401 is operated by an employee (user) working for the business entity that manages the data receiving device 401, as an example. The data receiving device 401 may transmit request information to the data management device 101. Alternatively, the data receiving device 401 may receive a request and transmit request information to the data management device 101 in response to the request. The data receiving device 401 receives data from the data management device 101. The data receiving device 401 may be a data management device (a device having a configuration equivalent to that of the data management device 101) different from the data management device 101. The operator managing the data management device 101 and the operator managing the data receiving device 401 may be the same operator. The operator managing the data management device 101 and the operator managing the data receiving device 401 may be different operators.

[0018] The operator of the data receiving device 401 may be the same as the operator of the data sending device 301. Also, the data receiving device 401 and the data sending device 301 may be the same device. Also, the operator of the data management device 101 may be the same as at least one of the operator of the data sending device 301 and the operator of the data receiving device 401.

[0019] The following explains "personal data," "consent information," and "request information." FIG. 2 shows personal data 1 and attribute information 1 as examples of personal data and its attribute information. The attribute information includes one or more attributes of the personal data. The attribute information of the personal data 1 is attribute information 1. The attribute information 1 includes a data owner identifier, a data type (type), and one or more data details (details). It is possible that no details are included. In the example of FIG. 2, detail 1, detail 2, and detail 3 are shown.

[0020] The owner identifier is an identifier assigned to the owner (individual) of the data. In this embodiment, the owner identifier uses a common value in the data management device 101, the first storage system 201, the second storage system 601, the data transmission device 301, the data reception device 401, and the verification device 1. The type and details values ​​are an identifier, a character string, date type data, a numeric value, or the like.

[0021] Fig. 3(A) shows an example of data type and details. The type is represented by a data type identifier, and the details are represented by a data detail identifier. The data type identifier T0001 indicates healthcare data. T0001 is associated with data detail identifiers D0001, D0002, and D0003. D0001, D0002, and D0003 represent body temperature, weight, and number of steps, respectively.

[0022] In the example of FIG. 2 above, the value of Detail 1 is D0001. Detail 2 is a date, and Detail 3 is an arbitrary numerical value (e.g., an index number, etc.). Personal data 1 in FIG. 2 includes the body temperature values ​​for each day in August 2020 of an individual with owner identifier U000001.

[0023] Figure 3(B) shows an example of an enterprise identifier. Figure 3(C) shows an example of an identifier of the purpose of data processing (purpose identifier). Figure 3(D) shows an example of a revocation identifier related to handling when consent information is revoked. The information in Figures 3(B) to 3(D) is used in consent information and request information, etc., which will be described later.

[0024] Next, the consent information will be explained. The consent information includes a consent information identifier, an owner identifier, a data type (type), details, one or more businesses, the event to which consent is given, the consent status for the event (consent / non-consent), consent period, handling at the time of withdrawal, consent date and time, etc. In some cases, details may not be included.

[0025] The right side of Figure 4 shows consent information 7 (indirectly acquired consent) as an example of consent information. Consent information 7 includes a consent information identifier, an owner identifier, a type, details, a provider, a recipient, the event to which consent is given, the consent status to the event to which consent is given (consent / non-consent), the consent period, handling at the time of withdrawal, and the date and time of consent. There may be cases where the consent information does not include details. Events to which consent is given include, for example, receipt of data by the recipient, retention of data by the recipient, use for a purpose through receipt or retention, and storage of consent information and records. A recipient is a business that receives data, and may retain or store the received data. A consent information identifier is information that identifies consent information.

[0026] The right side of FIG. 5 shows consent information 3 (directly acquired consent) as another example of consent information. Consent information 3 includes a consent information identifier, an owner identifier, a type, details, an acquiring business, an event to which consent is given, a consent status to the event to which consent is given (consent / non-consent), a consent period, handling at the time of withdrawal, consent date and time, and the like. Consent information may not include details. Events to which consent is given include, for example, data acquisition by an acquiring business, data retention (storage) by an acquiring business, use for the purpose of acquisition, and storage of consent information and records. An acquiring business is a business that acquires personal data from an individual's owner device 501 or a data source device 301, and in the example shown in the figure, is the business (C001) of the data management device 101.

[0027] Next, the request information will be described. The request information is information that requests processing to the data management device 101. The types of requests include, for example, provision, use (analysis, etc.), and acquisition.

[0028] The center of Figure 4 shows request information 1 as an example of request information when the request type is "provision." When the request type is "provision," the request information includes an owner identifier, a data type (type), details, a provider, a recipient, and the purpose of receipt and retention (storage) by one or more recipients. Request information 1 may not include details. Providing requests the recipient recipient to receive and retain (storage).

[0029] The center of Figure 5 shows request information 2 as an example of request information when the request type is acquisition. When the request type is acquisition, the request information includes an owner identifier, a data type (type), details, an acquiring entity, and one or more acquiring entities' purpose of acquisition. There may be cases where request information 2 does not include details.

[0030] The center of FIG. 6 shows request information 3 as an example of request information when the request type is use. When the request type is use, the request information includes an owner identifier, a data type (type), details, a user business (the analysis business in the example of the figure), and a purpose of data use by one or more user businesses (the analysis business in the example of the figure). There may be cases where request information 3 does not include details. Data use includes performing some kind of processing on data (first data) to generate new data (second data). For example, healthcare data may be analyzed to generate analysis result data regarding health conditions.

[0031] Below, each unit of the data management device 101 will be described. The data management device 101 includes a data storage unit 11, a consent information acquisition unit 12, a judgment processing unit 13, a history registration unit 14, an input unit 15, an output unit 16, and a data analysis unit 17. The elements included in the data management device 101 are not limited to these, and the data management device 101 may include, for example, an input interface for inputting information or instructions, and an output interface such as a display device for displaying information or data.

[0032] The input unit 15 receives request information requesting processing (provision, use (analysis, etc.), or acquisition, etc.) from the device or system of the business operator managing the data source device 301 or the data destination device 401 or the owner device 501 or the data management device 101, and sends the received request information to the judgment processing unit 13. The input unit 15 is an example of a receiving unit that receives request information. In addition, the input unit 15 receives data related to an individual (personal data, etc.) from the data source device 301, and sends the received data to the data storage unit 11. As described above, the input unit 15 may receive at least one of the request information and data from a device other than the data source device 301. For example, the input unit 15 may receive at least one of the request information and data from a device operated by the administrator of the data management device 101 or the owner device 501, etc.

[0033] The determination processing unit 13 receives request information from the input unit 15, and sends an instruction to the consent information acquisition unit 12 to acquire consent information based on the received request information.

[0034] The consent information acquisition unit 12 requests the first storage system 201 to read consent information with a matching owner identifier based on the request information, and receives the consent information from the first storage system 201. The consent information acquisition unit 12 may receive only the latest consent information (e.g., consent information with the latest consent date) from the first storage system 201. The consent information acquisition unit 12 may also receive all consent information or all consent information for a certain period of time. The consent information may also receive all consent information with a matching owner identifier. Consent information in which one or more other items match in addition to the owner identifier of the request information may also be received.

[0035] The determination processing unit 13 receives the consent information acquired by the consent information acquisition unit 12, and determines whether or not the process requested by the request information can be executed depending on whether the request information satisfies the consent information. The determination processing unit 13 sends information indicating the determination result to the data storage unit 11 and the output unit 16.

[0036] A first example of the determination method performed by the determination processing unit 13 will be described with reference to FIG.

[0037] Assume that the request information is the request information 1 in FIG. 4. Consent information that matches the comparison items such as the owner identifier, type, details, provider, receiving business, and the receiving business's purpose of receiving (or holding) is identified. As for the purpose, the purpose of the consent information only needs to include the purpose of the request information 1, and the consent information may include a purpose that does not exist in the request information 1. In the identified consent information, when the consent state to data reception by the receiving business, the consent state to data holding (data storage) by the receiving business, and the consent state to the purpose included in the request information 1 are all "consented," the request information 1 satisfies the consent information. A purpose that does not exist in the request information 1 may be non-consented in the consent information. When there are multiple pieces of consent information identified, the latest consent information is used as the target to determine each consent state. When the request information 1 satisfies the consent information, it is determined that the process requested by the request information 1 is executable. The consent information 7 in FIG. 4 is consent information that the request information 1 satisfies. Therefore, when the consent information 7 is acquired, it is determined that the process requested by the request information 1 is executable. If there is no consent information that satisfies the request information 1, it is determined that the process requested by the request information 1 cannot be executed. For example, even if there is consent information with matching comparison items, if the consent status is "disagreement", it is determined that the process cannot be executed. As an example, whether the consent information is the latest can be determined from the consent date (agreement date and time) included in the consent information. Alternatively, a timestamp may be attached to the consent information registered in the first storage system 201, and the determination may be made based on the timestamp.

[0038] A second example of the determination method by the determination processing unit 13 will be described with reference to FIG. 6 described above. The type of request in the request information 3 shown in FIG. 6 is use. The consent information is identified in which the owner identifier, type, and details of the request information 3 all match, the user business of the request information 3 (the analysis business in this example) matches the user business of the consent information, and the purpose that matches the purpose of use of the business of the request information 3. As for the purpose, it is sufficient that the purpose of the consent information includes the purpose of the request information 3, and a purpose that does not exist in the request information 3 may be included in the consent information. In the identified consent information, when all consent states for use of the purpose included in the request information 3 are "agreement", the request information 3 satisfies the consent information. A purpose that does not exist in the request information 3 may be disagreed with in the consent information. When there are multiple pieces of identified consent information, the latest consent information is used as the target to determine each consent state. When the request information 3 satisfies the consent information, it is determined that the process requested by the request information 3 is executable. The consent information 7 in FIG. 6 described above is consent information that the request information 3 satisfies. If there is no consent information that satisfies the request information 3, it is determined that the execution of the process requested by the request information 3 is not permitted. For example, even if there is consent information with matching comparison items, if the consent status is "not consented," it is determined that the execution of the process is not permitted.

[0039] A third example of the determination method by the determination processing unit 13 will be described with reference to FIG. 5 described above. The type of request of the request information 2 shown in FIG. 5 is acquisition. The consent information is identified in which the owner identifier, type, and details of the request information 2 all match, the acquirer of the request information 2 (the acquirer of the data management device 101 in this example) matches the acquirer of the consent information, and includes a purpose that matches the purpose of acquisition of the acquirer of the request information 2. As for the purpose, the consent information only needs to agree with the purpose of the request information 2, and may not agree with a purpose that does not exist in the request information 2. In the identified consent information, when all the consent states for the purpose included in the request information 2 are "agreement", the request information 2 satisfies the consent information. When there are multiple pieces of identified consent information, the latest consent information is used as the target to determine each consent state. When the request information 2 satisfies the consent information, it is determined that the process requested by the request information 2 is executable. The consent information 3 in FIG. 5 described above is consent information that the request information 2 satisfies. When there is no consent information that satisfies the request information 2, it is determined that the process requested by the request information 2 cannot be executed. For example, even if there is consent information with matching comparison items, if the consent state is "disagreement," it is determined that execution of the process is not permitted.

[0040] When the request information requests the provision of data (e.g., personal data) to the data management device 101 as a process (storage and receipt of the data by the data management device 101), the data storage unit 11 receives the data to be stored from the input unit 15. When the determination result by the determination processing unit 13 indicates that the process can be executed, the data is stored in an internal memory unit. When the process cannot be executed, the data is deleted. The input unit 15 may receive data from the data transmission source device 301 after the determination processing unit 13 has determined that the process can be executed. In this case, if it is determined that the process cannot be executed, the data is not received, and therefore the operation of deleting the data is unnecessary.

[0041] When the request information requests the provision (transmission) of data (e.g., personal data) as a process to the data receiving device 401, the data storage unit 11 reads the data from an internal storage unit after the determination processing unit 13 determines whether the process can be executed. The data storage unit 11 transmits the data to the data receiving device 401 via the output unit 16. Note that the destination of the data may be a device other than the data receiving device 401.

[0042] When the request information requests the use (e.g., analysis) of data (e.g., personal data) as a process, after the judgment processing unit 13 determines that the process can be executed, the data storage unit 11 reads out one or more data to be analyzed from an internal memory unit and sends them to the data analysis unit 17.

[0043] The data analysis unit 17 performs a predetermined analysis on the data and sends the analysis result data to the data storage unit 11. The analysis result data includes attribute information, and the attribute information includes multiple attributes of the analysis result data. The data storage unit 11 stores the analysis result data in an internal memory unit. If the data analysis request includes a request for provision of analysis data, the data storage unit 11 sends the analysis result data to the output unit 16.

[0044] The output unit 16 transmits the determination result of the determination processing unit 13 as to whether or not the process can be executed to the data transmission source device 301 or the data receiving device 401, which is the transmission source of the request information. The determination result may be transmitted to the device or system of the business entity that manages the owner device 501 or the data management device 101, which is the transmission source of the request information. In addition, the output unit 16 transmits the data (personal data, analysis result data, etc.) received from the data storage unit 11 to the data receiving device 401 of the business entity designated as the receiving business entity, the user business entity, the acquiring business entity, etc. Note that if the user business entity or the acquiring business entity is the business entity of the data management device 101 and the data transmission source device 301 or the data receiving device 401 is the same device as the data management device 101, transmission is not necessary. The output unit 16 is an example of a transmission unit that transmits the determination result or data, etc.

[0045] The history registration unit 14 generates a record indicating the content of the processing in order to record the history of the processing performed by the data storage unit 11. The record includes attribute information, and the attribute information includes multiple attributes of the record. Examples of processing include the provision, use (analysis, etc.) and acquisition of data (personal data or analysis result data, etc.). If there is an entity that receives the data, a record of receipt may be generated. The history registration unit 14 sends the record to the first storage system 201. The first storage system 201 registers the received record internally. The record may be used for auditing.

[0046] A specific example of record generation will be described with reference to FIG. 4 and FIG. 4 shows attribute information 2, request information 1, and consent information 7 as examples of attribute information, request information, and consent information of personal data. Request information 1 requests that personal data of attribute information 2 be provided from business entity C002 (provider) to business entity C001 (recipient), and request information 1 satisfies consent information 7.

[0047] An example of a record of provision is shown on the left side of Fig. 7. The record of provision includes a record identifier, a type of record ("provision" in this example), the recording company (provider) that recorded in the first storage system 201, the name of the receiving company, a consent information identifier, information for identifying the personal data (owner identifier, type, details, etc.), and date and time (date of provision). After the personal data is provided, the history registration unit 14 of the data management device 101 generates a record of provision.

[0048] The right side of FIG. 7 shows an example of a receipt record. The receipt record includes a record identifier, a type of record ("received" in this example), the record business (receiving business) that recorded in the first storage system 201, the name of the provider, a consent information identifier, the acquisition history, information that identifies the data (data attributes), and the date of provision. The acquisition history specifies document 1 that includes information on how the provider acquired the personal data. Document 1 is, for example, a purchase and sale contract for personal data, a contract showing the acquisition history, the provider's website showing the acquisition history, a document in which the provider pledges that the provider has obtained the individual's consent, consent information, or the like. The device of the business C001 that received the personal data (the data management device 101 in this example) generates a record of the receipt (storage) of the personal data and registers the record in the first storage system 201.

[0049] When the operator of the data management device 101 is a provider, the data management device 101 creates a record of the provision and registers it in the first storage system 201. Then, the device of the receiving company (for example, the operator of the data receiving device 401) creates a record of the receipt and stores it in the device of the receiving company. Alternatively, the device of the receiving company may register the record in the first storage system 201. That is, the first storage system 201 may be shared between the operators, and the provider and the receiving company may register the record in the same first storage system 201. On the other hand, when the operator of the data management device 101 is a recipient, the data management device 101 creates a record of the receipt and registers it in the first storage system 201. Then, the device of the provider (for example, the operator of the data sending device 301) creates a record of the provision and stores it in the device of the provider. Alternatively, the device of the provider may register the record in the first storage system 201.

[0050] Another specific example of recording will be described with reference to FIG. 6 and FIG. 6 shows attribute information 2, request information 3, and consent information 7 as examples of attribute information, request information, and consent information of personal data. Request information 3 requests that business entity C001 (owning business entity) use (assuming analysis here) the personal data of attribute information 2, and request information 3 satisfies consent information 7.

[0051] The history registration unit 14 of the data management device 101 generates a record of the analysis based on the data analysis results by the data analysis unit 17. More specifically, the data analysis unit 17 of the data management device 101 (business operator C001) analyzes personal data having attribute information 2 and generates analysis result data. The analysis result data is an example of data (generated data) generated by using data. The analysis result data (generated data) includes the data body and attribute information. The analysis result data is stored in the data storage unit 11. The history registration unit 14 creates a record of use (analysis in this case) based on the analysis result data.

[0052] The left side of Figure 8 shows attribute information 3 as an example of attribute information of analysis result data (generated data). The right side of Figure 8 shows an example of an analysis record. The analysis record includes a record identifier, a type of record ("generation" in this example), the recording company (analysis company) that recorded in the first storage system 201, a consent information identifier, information identifying one or more used data (used data owner identifier, used data type, used data details, etc.; in this example, information of attribute information 2), and information identifying the generated data (generated data owner identifier, generated data type, generated data details, date and time the generated data was generated). The information identifying the generated data corresponds to attribute information 3 in this example.

[0053] Another specific example of recording will be described with reference to FIG. 5 and FIG. 5 shows attribute information 1, request information 2, and consent information 3 as examples of attribute information, request information, and consent information of personal data. Request information 2 requests that business entity C001 acquire personal data of attribute information 2 from an individual. Request information 2 satisfies consent information 3.

[0054] The history registration unit 14 of the data management device 101 generates a record of acquisition based on the acquisition of personal data.

[0055] 9 shows an example of an acquisition record. The acquisition record includes a record identifier, a type of record, a record business (acquiring business), consent information, information for identifying the acquired data (information of attribute information 1 in this example), and an acquisition date and time.

[0056] In the first embodiment, the owner identifier uses a common value in the data management device 101, the first storage system 201, the data source device 301, and the data destination device 401. Among the items included in the record related to the process, items that are the same as the consent information (record related to consent) referenced by the record related to the process may be omitted by referring to the record related to consent. Items to be omitted include, for example, the owner identifier, type, details, etc. in the record related to the process.

[0057] The log storage unit 21 of the second storage system 601 stores a log of writing to the data storage unit 11, a log of reading from the data storage unit 11, and a log of deletion in the data storage unit 11. These logs are collectively called data access logs. The storage period of the logs in the second storage system 601 may be shorter than the storage period of the records in the first storage system 201. The user (verifier) ​​who operates or manages the verification device 1 may be either the owner or the auditor. The second storage system 601 may be a log management system provided by a cloud service provider. The reliability of the integrity verification provided by this embodiment is increased when the recording service provider cannot tamper with the logs.

[0058] The verification device 1 includes an input unit 1A and a processing unit 1B. The processing unit 1B includes an acquisition unit 1C and a verification unit 1D.

[0059] The input unit 1A receives various instructions from a user. For example, the input unit 1A receives a request from a user to verify the consistency of a record. The verification request may include conditions related to the subject of verification. The conditions related to the subject of verification may include at least one of an identifier that identifies an individual and an identifier that identifies a business entity. The conditions related to the subject of verification may also include conditions related to the period to be verified. The conditions related to the subject of verification may include other conditions.

[0060] When the processing unit 1B receives a request for verifying consistency, it performs a process of verifying consistency using the acquisition unit 1C and the verification unit 1D. The acquisition unit 1C acquires records (at least one of records related to the process and records related to the consent) from the first storage system 201. The acquisition unit 1C acquires logs (logs of operations performed in relation to at least one of the process and the consent) from the second storage system 601. The acquisition unit 1C may acquire records that satisfy the conditions included in the verification request from the first storage system 201, and acquire logs that satisfy the conditions included in the verification request from the second storage system 601.

[0061] The verification unit 1D verifies the consistency of the acquired records based on the acquired log. For example, the verification unit 1D verifies the consistency between the records (records related to the process or records related to the consent) and the data access log. The verification unit 1D determines that there is no consistency when the acquired log does not include a log of an operation corresponding to the process or consent indicated in the acquired record. The verification unit 1D also determines that there is no consistency when the acquired record does not include a record indicating the process or consent corresponding to the operation indicated by the acquired log. Also, it is assumed that when multiple operations (for example, writing and reading to the data storage unit 11) are performed in relation to one process, multiple logs corresponding to the multiple operations are held in the second storage system 601. The verification unit 1D acquires multiple logs corresponding to multiple operations performed for one process from the second storage system 601, and identifies a log corresponding to the last operation among the acquired multiple logs. It may be determined that there is no consistency when the acquired record does not include a record indicating a process corresponding to the operation indicated by the identified log.

[0062] The processing unit 1B may verify the consistency of the consent record and the processing record as the consistency of the records (at least one of the processing record and the consent record) in addition to verifying the consistency of the records and the logs. For example, the acquisition unit 1C acquires the processing record and the consent record from the first storage system 201 based on the conditions included in the verification request. If the consent record for the processing indicated in the processing record cannot be acquired, the processing unit 1B determines that there is no consistency. Also, based on the acquired consent record, the processing unit 1B acquires or calculates the consent period or non-consent period, and determines that there is no consistency if the time of the processing indicated in the processing record (e.g., date and time) is not included in the consent period or is included in the non-consent period.

[0063] The processing unit 1B may record the verification result in the verification device 1, the second storage system 601, or another device. When recording the verification result, a part of the data access log (for example, the log used for the verification) or all of the data access log may be erased from the second storage system 601. The processing unit 1B may transmit instruction data to the second storage system 601 to instruct the second storage system 601 to erase a part of the data access log or all of the data access log, and the second storage system 601 may erase a part of the data access log or all of the data access log based on the instruction data. In this case, the verification of the consistency between the record and the log may be performed for a set period of time.

[0064] 10 is a flowchart of an example of processing according to the first embodiment. In this processing, the verification device 1 verifies the consistency between the records related to processing and the data access log for each owner.

[0065] Step S101: The verification device 1 receives a request for verifying the integrity of the owner identifier. For example, the user specifies the owner identifier using an operation unit (keyboard, mouse, touch panel, etc.) and presses a button in an application window displayed on the screen to instruct the verification of the integrity.

[0066] Step S102: The verification device 1 acquires, from the first storage system 201, the consent information identifier of the consent information including the owner identifier. Step S103: The verification device 1 obtains a record identifier of a record that includes the consent information identifier in a consent information item from the first storage system 201. If the record related to the process includes an owner identifier, the verification device 1 may obtain a record identifier of a record that includes the owner identifier from the first storage system 201. Step S104: The verification device 1 verifies the consistency between the record regarding consent (consent information) and the record regarding the process (record). For example, it verifies whether it can be confirmed from the consent information that the process indicated in the record has been consented to by the owner. The verification method is not limited to a specific one.

[0067] There are two types of consent: indirect acquisition consent (indirect acquisition consent) and direct acquisition consent (direct acquisition consent). Indirect acquisition corresponds to the receipt of data provided by a third party. Direct acquisition corresponds to the acquisition of data provided by the owner. Indirect acquisition consent and direct acquisition consent are collectively called storage consent. There is also consent corresponding to a third party providing data (provision consent).

[0068] Verification of the consistency between the record regarding the processing and the data access log can be performed by record-based verification and log-based verification. Log-based verification does not allow a simple comparison. The details are as follows. In receiving or acquiring personal data, an operation is permitted in which indirectly acquired consent or directly acquired consent is confirmed after receiving personal data via a communication network, and if there is no record regarding consent or the consent state is non-consent, the personal data is not written to the data storage unit 11. In providing personal data, an operation is permitted in which consent to provision is confirmed after reading personal data from the data storage unit 11, and if there is no record regarding consent or the consent state is non-consent, the personal data is not transmitted to the destination via a communication network. In generating personal data, an operation is permitted in which indirectly acquired consent or directly acquired consent is confirmed after reading personal data from the data storage unit 11, and if there is no record regarding consent or the consent state is non-consent, the personal data is not generated and the personal data is not written to the data storage unit 11. In other words, the final log of a series of operations in the processing corresponds to the record regarding the processing.

[0069] The correspondence between the record and the log refers to the fact that the description (type, details, etc.) that identifies the data in the consent record that the processing record refers to matches the description that identifies the data in the data access log, or the latter is included as a subset of the former (requirement 1-1-1). If the processing record includes a description that identifies the data, the description (type, details, etc.) that identifies the data in the processing record matches the description that identifies the data in the data access log, or the latter is included as a subset of the former (requirement 1-1-2). In addition to requirement 1-1-1 or requirement 1-1-2, the fact that the date and time (year, month, day) identified in the processing record and the date and time identified in the data access log are closer to each other than a threshold (requirement 1-1-3) may be added. The threshold may be fixed in advance or may be variable by user input.

[0070] The detailed operation of verifying the consistency between the process record and the data access log will be described later.

[0071] Step S105: The verification device 1 acquires the data access log related to the owner identifier from the second storage system 601. Step S106: The verification device 1 verifies the consistency between the records related to the process including the target recorder among the records including the record identifier acquired in step S103 and the data access log. The target recorder may be fixed in advance or may be variable by user input. An example of the operation of the consistency verification is shown below.

[0072] In verifying the record start point, a receipt record that includes a consent information identifier for indirectly acquired consent or consent to provision in its consent information item is determined to be inconsistent if there is no corresponding write log. A provision record that includes a consent information identifier for indirectly acquired consent or consent to provision in its consent information item is also determined to be inconsistent if there is no corresponding read log. An acquisition record that includes a consent information identifier for directly acquired consent in its consent information item is also determined to be inconsistent if there is no corresponding write log. A creation record that includes a consent information identifier for indirectly acquired consent or directly acquired consent in its consent information item is also determined to be inconsistent if there is no corresponding read or write log. A deletion record that includes a consent information identifier for indirectly acquired consent or directly acquired consent in its consent information item is also determined to be inconsistent if there is no corresponding deletion log.

[0073] In the verification of the log origin, if there is no corresponding acquisition record, receipt record, or creation record for a write log, it is determined to be inconsistent. Also, if there is no corresponding deletion record for a deletion log, it is determined to be inconsistent.

[0074] When it is determined that there is no consistency in at least one of the record start point and the log start point, the verification device 1 determines that an inconsistency has been detected (no consistency).

[0075] Step S107: If no inconsistency is detected in both step S104 and step S106, the verification device 1 determines that no inconsistency is detected overall. The verification device 1 may output (for example, display on a screen) information indicating that no inconsistency is detected overall. If it is determined that there is no consistency in at least one of step S104 and step S106, it determines that an inconsistency is detected overall. The verification device 1 may output information indicating that an inconsistency is detected overall. At this time, information identifying whether the inconsistency was detected in step S104 or step S106 may also be displayed on the screen.

[0076] The order of the consistency verification in step S104 and the consistency verification in step S106 may be reversed, or both may be performed in parallel. Also, if it is determined that there is no consistency in either step S104 or step S106, it is not necessary to perform the consistency verification in the other step. If an inconsistency is detected overall, information on the location that caused the determination that there was no consistency may be output.

[0077] An example of the operation of each step in the flowchart of FIG. 10 will be specifically described below.

[0078] (Example 1) Step S101: The verification device 1 receives a consistency verification request for U000001 as the owner identifier.

[0079] Step S102: The verification device 1 acquires from the first storage system 201 the consent information identifier C000007 (indirectly acquired consent) of the consent information including the owner identifier U000001.

[0080] Step S103: The verification device 1 acquires R000001 (provision record), R000002 (received record), and R000004 (created record) as record identifiers of records that include the consent information identifier (C000007) in the consent information item from the first storage system 201. In this example, since the record related to the process includes an owner identifier, the verification device 1 may acquire record identifiers (R000001, R000002, R000004) of records that include U000001 as the owner identifier from the first storage system 201.

[0081] Step S104: The verification device 1 verifies the consistency between the record regarding the consent and the record regarding the process, and determines that no inconsistency is detected.

[0082] Step S105: The verification device 1 acquires the data access log related to the owner identifier (U000001) from the second storage system 601.

[0083] FIG. 11 shows an example of the data access log 1-1. The types of data access logs include write, read, and delete. The recorder of the data access log is C001, and C001 corresponds to the data management device 101. However, more specifically, the first and second lines may correspond to the input unit 15, and the third and fourth lines may correspond to the data analysis unit 17. Alternatively, the recorder may be a personal account of a person involved in personal data processing. The access destination is a set of an owner identifier, a type, and details, but the access destination may be an address in the second storage system 601. In this case, data indicating the correspondence between the address, the owner identifier, the type, and the details may be held in a separate table. The date and time is the date and time when the data access was performed, and may be finer in granularity than the date and time of the record related to the processing.

[0084] In this example, to obtain the data access log related to the owner identifier (U000001), the logs on the 1st, 3rd, and 4th lines in the data access log 1-1 are obtained. From the obtained log, the target record business is set to C001, and from the record identifiers (R000001, R000002, R000004), the record identifiers R000002 and R000004 of the records that include C001 are obtained.

[0085] Step S106: The verification device 1 verifies the consistency between the record including the acquired record identifier and the data access log. In the verification of the record start point, the record with record identifier R000002 corresponds to the first line of the data access log, and the record with record identifier R000004 corresponds to the third and fourth lines of the data access log. No inconsistency is detected in the verification of the record start point. In the verification of the log start point, the record with record identifier 000002 corresponds to the first line of the data access log, and the record with record identifier R000004 corresponds to the fourth line of the data access log. No inconsistency is detected in the verification of the log start point. Therefore, it is determined that no inconsistency is detected between the record related to the process and the data access log.

[0086] Step S107: The verification device 1 determines that no inconsistency is detected overall, since no inconsistency is detected in both step S104 and step S106.

[0087] (Example 2) Step S101: The verification device 1 receives a consistency verification request for the owner identifier U000002.

[0088] Step S102: The verification device 1 acquires from the first storage system 201 the consent information identifiers C000003 and C000010 (directly acquired consent) of the consent information including the owner identifier U000002.

[0089] Step S103: The verification device 1 acquires from the first storage system 201 the record identifiers R000003 (acquired record) and R000005 (deleted record) of the records that include the consent information identifiers C000003 and C000010 in the consent information items.

[0090] 12 shows an example of a record (deletion record) with record identifier R000005. In this example, since the record related to the process includes an owner identifier, record identifiers R000003 and R000005 of the records including the owner identifier U000002 may be obtained from the first storage system 201.

[0091] Step S104: The verification device 1 verifies the consistency between the record regarding the consent and the record regarding the process, and determines that no inconsistency is detected.

[0092] Step S105: The verification device 1 obtains the data access log for the owner identifier U000002 from the second storage system 601. The logs in the second and fifth lines of the data access log in FIG. 11 are obtained. In addition, the target recording company is C001. The recording company of the records with the above-mentioned record identifiers R000003 and R000005 is both C001.

[0093] Step S106: The verification device 1 verifies the consistency between the record and the data access log. In verifying the record start point, it is determined that the record with record identifier R000003 corresponds to the second line of the data access log, and that the record with record identifier R000005 corresponds to the fifth line of the data access log. In verifying the record start point, it is determined that the record with record identifier R000003 corresponds to the second line of the data access log, and that the record with record identifier R000005 corresponds to the fifth line of the data access log. In verifying the log start point, it is determined that the inconsistency is not detected. Therefore, it is determined that no inconsistency is detected between the record related to the process and the data access log.

[0094] Step S107: The verification device 1 determines that no inconsistency is detected overall, since no inconsistency is detected in both step S104 and step S106.

[0095] (Example 3) Instead of inputting the owner identifier in step S101, the owner identifier may be obtained from a record related to consent referenced by the record related to the process stored in the first storage system 201. If the record related to the process includes an owner identifier, the owner identifier may be obtained from the record related to the process stored in the first storage system 201. Also, the owner identifier may be obtained from a data access log stored in the second storage system 601.

[0096] (Example 4) The verification device 1 may perform consistency verification between the record related to the processing and the data access log in the order of storage in the first storage system 201 or the order of storage in the second storage system 601, instead of performing consistency verification for each owner. The records and logs correspond, and the logs and records correspond, refer to the fact that a description identifying data in the record related to the consent referenced by the processing (owner identifier, type, details, etc.) matches a description identifying data in the data access log, or the latter is included as a subset of the former. When a description identifying data is included in the record related to the processing, it refers to the fact that a description identifying data in the record related to the processing (owner identifier, type, details, etc.) matches a description identifying data in the data access log, or the latter is included as a subset of the former. There is no substantial change in the judgment items related to correspondence, and the difference is whether the judgment regarding the owner identifier is performed first or later.

[0097] An example of the operation of Example 4 is shown below. Step S101: The verification device 1 receives a consistency verification request.

[0098] Step S102: The verification device 1 acquires from the first storage system 201 the consent information identifiers C000003 (directly acquired consent), C000007 (indirectly acquired consent), and C000010 (directly acquired consent).

[0099] Step S103: The verification device 1 acquires from the first storage system 201 the record identifiers R000001 (provision record), R000002 (reception record), R000003 (acquisition record), R000004 (creation record), and R000005 (deletion record).

[0100] Step S104: The verification device 1 performs consistency verification on the record related to the consent and the record related to the process, and determines that no inconsistency is detected.

[0101] Step S105: The verification device 1 acquires the data access log from the second storage system 601. The logs from the first to fifth lines in Fig. 11 are acquired. In addition, the target recording entity is assumed to be C001. Record identifiers R000002, R000003, R000004, and R000005 of the records including the recording entity C001 are used.

[0102] Step S106: The verification device 1 verifies the consistency between the record and the data access log. In the verification of the record start point, it is determined that the record with the record identifier R000002 corresponds to the first line of the data access log, the record with the record identifier R000003 corresponds to the second line of the data access log, the record with the record identifier R000004 corresponds to the third and fourth lines of the data access log, and the record with the record identifier R000005 corresponds to the fifth line of the data access log. In the verification of the record start point, it is determined that the record with the record identifier R000002 corresponds to the first line of the data access log, the record with the record identifier R000003 corresponds to the second line of the data access log, the record with the record identifier R000004 corresponds to the fourth line of the data access log, and the record with the record identifier R000005 corresponds to the fifth line of the data access log. No inconsistency is detected by the verification of the log origin. Therefore, it is determined that no inconsistency is detected for the records related to the processing and the data access log.

[0103] Step S107: The verification device 1 determines that no inconsistency is detected overall, since no inconsistency is detected in both step S104 and step S106.

[0104] (Example 5) The following is an example in which the verification device 1 determines that there is no consistency in step S106: The target recording business operator is C001. Assume that the third line of the data access log 1-1 in FIG. 11 stored in the second storage system 601 does not have a log. In this case, in the verification of the record start point in step S106, it corresponds to the case where there is no read log corresponding to the generated record (FIG. 8). Therefore, it is determined that there is no consistency.

[0105] Assume that records with record identifiers R000003 (acquisition record), R000004 (creation record), and R000005 (deletion record) are not stored in the first storage system 201. In this case, no inconsistency is detected in the verification of the consistency between the agreement-related record and the processing-related record in steps S102 to S104. On the other hand, in the verification of the log start point in step S106, since there is no acquisition record, receipt record, or creation record corresponding to the writing log, and there is no deletion record corresponding to the deletion log, it is determined that there is no consistency.

[0106] A specific example of the operation of the flowchart in FIG. 10 has been shown above, but operations other than the above example are also possible.

[0107] (Modification) This shows a modified example in which a function is added to enhance reliability. A hash value of data is added as an item to the receipt record, acquisition record, and creation record. The verification device 1 calculates a hash value of the data stored in the data storage unit 11 in steps S102 to S104, and compares the calculated hash value with the hash value of the item in the record. If they do not match, it may be determined that there is no consistency.

[0108] In the consent record, instead of the purpose identifier (see Figure 3), a consent document describing the purpose of use may be referenced.

[0109] The hash value of the consent document may be included as an item in the consent record. In steps S102 to S104, the hash value of the consent document stored in the data storage unit 11 may be compared with the hash value in the record, and if they do not match, it may be determined that there is no consistency.

[0110] For documents referenced in the receipt record in the process of acquisition, the hash value of the document may be included as an item in the record. In steps S102 to S104, the hash value of the document stored in the data storage unit 11 may be compared with the hash value in the record, and if they do not match, it may be determined that there is no consistency.

[0111] 1, the second storage system 601 is connected to the data management device 101 and stores the data access log of the data management device 101. As another configuration example, the second storage system 601 may be connected to the owner device 501, the data source device 301, or the data destination device 401 and store the data access log of the connection destination. The target recording entity is the entity that manages or owns the device of each connection destination.

[0112] Also, the entire data storage unit 11 may be searched to confirm that specific data does not exist, and the confirmation result may be used in place of the deletion log. The entire data storage unit 11 may be searched to confirm that specific data does exist, and the confirmation result may be used in place of the writing log. These confirmation results may be used as information equivalent to the data access log. In these cases, the date and time need not be compared in the consistency verification in step S106.

[0113] <Embodiment 1-2> The verification device 1 verifies the consistency between the records related to the process and the communication log for each owner. Regarding the operation of the verification device 1 in the embodiment 1-2, steps S101 to S104 and S107 in the embodiment 1-1 are also applied to the embodiment 1-2. The operations corresponding to steps S105 and S106 are different from those in the embodiment 1-1.

[0114] The consistency verification between the record related to the process and the communication log is performed at the record start point and the log start point. The record and the log correspond to each other, meaning that the description (type, details, etc.) that identifies the data in the record related to the consent that the record related to the process refers to matches the description that identifies the data in the communication log, or the latter is included as a subset of the former (requirement 1-2-1). If the record related to the process includes a description that identifies the data, the description (type, details, etc.) that identifies the data in the record related to the process matches the description that identifies the data in the communication log, or the latter is included as a subset of the former (requirement 1-2-2). In addition to requirement 1-2-1 or requirement 1-2-2, the date and time (year, month, day) identified in the record related to the process and the date and time identified in the communication log may be closer to each other than a threshold (requirement 1-2-3). The threshold may be fixed in advance or may be variable by user input.

[0115] Step S105: The verification device 1 acquires a communication log related to the owner identifier from the second storage system 601. It is also possible to acquire only the communication log of personal data transmission and reception.

[0116] Step S106: The verification device 1 verifies the consistency between the records related to the process including the target record business among the records including the record identifier acquired in step S103 and the communication log of the personal data transmission and reception. The target record business may be fixed in advance or may be variable by user input.

[0117] In verifying the record start point, if there is no corresponding personal data reception log for a receipt record that includes a consent information identifier for indirectly acquired consent or consent to provision in the consent information item, it is determined to be inconsistent. If there is no corresponding personal data transmission log for a provision record that includes a consent information identifier for indirectly acquired consent or consent to provision in the consent information item, it is determined to be inconsistent. If there is no corresponding personal data reception log for an acquisition record that includes a consent information identifier for directly acquired consent in the consent information item, it is determined to be inconsistent.

[0118] In log-based verification, if there is no corresponding provision record for the personal data transmission log, it is determined to be inconsistent.

[0119] When there is no consistency in at least one of the record start point and the log start point, the verification device 1 detects an inconsistency (determines that there is no consistency).

[0120] A specific example of the operation of each step will be shown below.

[0121] (Example 1) Step S101: The verification device 1 receives a consistency verification request for the owner identifier U000001.

[0122] Steps S102 to S104: Omitted as they are the same as in embodiment 1-1.

[0123] Step S105: The verification device 1 acquires the communication log related to the owner identifier U000001 from the second storage system 601. FIG. 13 shows an example of a communication log 1-2A. The verification device 1 acquires the second and third lines of the log from the communication log 1-2A. Also, assume that the target record operator is C001. Based on the owner identifier U000001 and the record operator C001, record identifiers R000002 (received record) and R000004 (created record) are acquired. R000004 (created record) is not used for verifying with the communication log because it is not related to sending or receiving. R000002 (received record) is used for verifying with the communication log.

[0124] Step S106: The verification device 1 verifies the consistency between the record and the communication log. In the verification of the record start point, it is determined that the third line of the communication log corresponds to the record identifier R000002. In the verification of the record start point, no inconsistency is detected. In the verification of the log start point, there is no transmission log of personal data for the record operator C001. In the verification of the log start point, no inconsistency is detected. Therefore, the verification device 1 determines that no inconsistency is detected between the record related to the processing and the communication log.

[0125] Step S107: Omitted since it is the same as in embodiment 1-1.

[0126] (Example 2) Step S101: The verification device 1 receives a consistency verification request for the owner identifier U000002.

[0127] Steps S102 to S104: Omitted as they are the same as in embodiment 1-1.

[0128] Step S105: The verification device 1 acquires a communication log related to the owner identifier U000002 from the second storage system 601. The logs of the 1st, 4th, and 5th lines are acquired from the communication log 1-2A in FIG. 13. The target recording company is assumed to be C001. Based on the owner identifier U000002 and the recording company C001, record identifiers R000003 (acquired record) and R000005 (deleted record) are acquired. R000005 (deleted record) is not used for verification with the communication log because it is not related to sending or receiving.

[0129] Step S106: The verification device 1 verifies the consistency between the record and the communication log. In the verification of the record start point, it is determined that the fourth line of the communication log corresponds to the record identifier R000003. In the verification of the record start point, no inconsistency is detected. In the verification of the log start point, there is no transmission log of personal data for the record operator C001. In the verification of the log start point, no inconsistency is detected. Therefore, the verification device 1 determines that no inconsistency is detected between the record related to the processing and the communication log.

[0130] Step S107: Omitted since it is the same as in embodiment 1-1.

[0131] (Example 3) Step S101: The verification device 1 receives a consistency verification request.

[0132] Steps S102 to S104: Omitted as they are the same as in embodiment 1-1.

[0133] Step S105: The verification device 1 acquires the communication log from the second storage system 601. The logs from the first to fifth lines in the communication log 1-2A in FIG. 13 are acquired. In addition, the target record operator is assumed to be C001. Based on the record operator C001, record identifiers R000002 (received record), R000003 (acquired record), R000004 (created record), and R000005 (deleted record) are acquired. R000004 (created record) and R000005 (deleted record) are not used for verification with the communication log because they are not related to sending or receiving.

[0134] Step S106: The verification device 1 verifies the consistency between the record and the communication log. In the verification of the record start point, it is determined that the third line of the communication log corresponds to record identifier R000002, and the fourth line of the communication log corresponds to record identifier R000003. In the verification of the record start point, no inconsistency is detected. In the verification of the log start point, there is no transmission log of personal data for recording operator C001. In the verification of the log start point, no inconsistency is detected. Therefore, the verification device 1 determines that no inconsistency is detected between the record related to the processing and the communication log.

[0135] Step S107: Omitted since it is the same as in embodiment 1-1.

[0136] (Example 4) The following is an example in which the verification device 1 determines that there is no consistency in the verification of consistency between the record related to the process and the communication log in step S106. Assume that the target record business operator is C001.

[0137] In the communication log 1-2A in Fig. 13, it is assumed that there is no log in the third line. In this case, in the verification of the record start point in step S106, there is no corresponding reception log for the receipt record. The verification device 1 determines that there is no consistency.

[0138] Instead of the content item in the communication log (see FIG. 13), an item of a type that distinguishes between receipt of consent from the owner or receipt of personal data may be used.

[0139] Fig. 14 shows an example of a communication log 1-2B including the item of this type. In this case, by distinguishing between receipt of consent from the owner and receipt of personal data, consistency verification may be performed using a simplified correspondence between the record and the log. A simplified correspondence between the record and the log means that the description identifying each item in the record related to the processing (owner identifier and recording business operator) matches the description identifying each item in the communication log (sender and receiver).

[0140] The communication logs shown in Figures 13 and 14 are merely examples, and other examples of communication logs are also possible. For example, the communication log may include not only the sender and the receiver, but also intermediate parties between the sender and the receiver. Alternatively, if there is a process performed after reception, this process may be included in the communication log as the final receiver.

[0141] <Embodiment 1-3> The verification device 1 verifies the consistency between the consent-related records and the communication logs for each owner. This is premised on the fact that the processing business operator (provider, receiver, or acquirer) has the communication logs corresponding to the consent-related records, or that the verification device 1 can access them.

[0142] The verification device 1 verifies the consistency between the consent-related record and the communication log, starting from the record and the log. The consent to provision is unconditionally (automatically) revoked when the prerequisite consent to storage is revoked. Correspondence between the record and the log means that the description identifying each item in the consent-related record (such as consent state) matches the description identifying each item in the communication log, and the date and time (year, month, and day) identified in the consent-related record and the date and time identified in the communication log are closer to each other than a threshold value. The threshold value may be fixed in advance or may be variable by user input.

[0143] Fig. 15 is a flowchart of an example of the operation according to embodiment 1-3. Steps S101 to S104 and S107 are the same as those in Fig. 10 used in the description of embodiment 1-1.

[0144] Step S105: The verification device 1 acquires a communication log related to the owner identifier from the second storage system 601. It is also possible to acquire only the communication log of receipt of consent by the data owner.

[0145] Step S106: The verification device 1 verifies the consistency between the consent information (record of consent) including the identifier of the target data processor among the consent information of the consent information identifier acquired in step S102 and the communication log of the receipt of consent by the data owner. The target data processor may be fixed in advance or may be variable by user input.

[0146] In the record-start verification, for indirectly acquired consent and directly acquired consent, if there is no consent receipt log from the corresponding owner, it is determined to be inconsistent. Also, for consent to provision that is not based on the revocation of consent to storage, if there is no consent receipt log from the corresponding owner, it is determined to be inconsistent.

[0147] In the log-origin verification, if the received log of consent from the owner does not have a corresponding indirect acquisition consent, direct acquisition consent, or provision consent (not based on the revocation of storage consent), it is determined to be inconsistent.

[0148] The verification device 1 detects an inconsistency (determines that there is no consistency) when there is no consistency in at least one of the verification of the record start point and the verification of the log start point.

[0149] An example of the operation of each step in the flowchart of Fig. 15 is specifically described below. The owner device 501 does not directly access the first storage system 201, but accesses the first storage system 201 via the target processing company. Therefore, the processing company's device has a communication log corresponding to the record of consent, and the recipient that receives the owner's consent is the processing company's device.

[0150] (Example 1) Step S101: The verification device 1 receives a consistency verification request for the owner identifier U000001.

[0151] Steps S102 to S104: Omitted as they are the same as in embodiment 1-1.

[0152] Step S105: The verification device 1 acquires a communication log related to the owner identifier U000001 from the second storage system 601. The sender and receiver of the communication log (see FIG. 13) each have an owner identifier or a processing company listed, but an IP address or the like may be listed and the correspondence between the IP address and the owner identifier or the processing company may be stored in a separate table. In the content item of the communication log, in the case of receiving consent from the owner, the value of each item of the record related to consent is set. In the case of sending and receiving data as the execution of processing, a set of the owner identifier, type, and details is set. The date and time in the communication log is the date and time when the communication was executed, and may be finer than the date and time of the record related to the processing. The log in the second and third lines is acquired as a log containing the owner identifier U000001 in the content item of the communication log. Based on the receiver item of the acquired log, the target processing company is set to C001. The consent information identifier C000007 (indirectly acquired consent) of the consent information containing the owner identifier U000001 is acquired.

[0153] Step S106: The verification device 1 verifies the consistency between the consent information (record related to consent) of the consent information identifier C000007 and the communication log. In the verification of the record start point, the second line of the communication log corresponds to the consent information of the consent information identifier C000007. In the verification of the record start point, no inconsistency is detected.

[0154] In the log-start verification, the second line of the communication log corresponds to the consent information with the consent information identifier C000007. In the log-start verification, no inconsistency is detected.

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

[0156] Step S107: Omitted since it is the same as in embodiment 1-1.

[0157] (Example 2) Step S101: The verification device 1 receives a consistency verification request for the owner identifier U000002.

[0158] Steps S102 to S104: Omitted as they are the same as in embodiment 1-1.

[0159] Step S105: The verification device 1 acquires the communication log related to the owner identifier U000002 from the second storage system 601. The logs of the 1st, 4th, and 5th lines are acquired from the communication log in Fig. 13. The target processing business operator is assumed to be C001. The consent information identifiers C000003 and C000010 (directly acquired consent) of the consent information (record related to consent) including the owner identifier U000002 are acquired. Step S106: The verification device 1 verifies the consistency between the consent information of the consent information identifier and the communication log. In the verification of the record start point, it is determined that the first line of the communication log corresponds to the consent information of the consent information identifier C000003, and the fifth line of the communication log corresponds to the consent information of the consent information identifier C000010. In the verification of the record start point, no inconsistency is detected.

[0160] The log-start verification determines that the consent information with the consent information identifier C000003 corresponds to the first line of the communication log, and that the consent information with the consent information identifier C000010 corresponds to the fifth line of the communication log. No inconsistencies are detected by the log-start verification.

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

[0162] Step S107: Omitted since it is the same as in embodiment 1-1.

[0163] (Example 3) Step S101: The verification device 1 receives a consistency verification request.

[0164] Steps S102 to S104: Omitted as they are the same as in embodiment 1-1.

[0165] Step S105: The verification device 1 acquires communication logs from the second storage system 601. The logs from the first to fifth lines of Fig. 13 (all logs) are acquired. The target processing business operator is designated as C001. In addition, the consent information identifiers C000003 (directly acquired consent), C000007 (indirectly acquired consent), and C000010 (directly acquired consent) are acquired as the consent information identifiers of all consent information (records related to consent).

[0166] Step S106: The verification device 1 verifies the consistency between the consent information identifier and the communication log. In the verification of the record start point, it is determined that the first line of the communication log corresponds to the consent information identifier C000003, the second line of the communication log corresponds to the consent information identifier C000007, and the fifth line of the communication log corresponds to the consent information identifier C000010. In the verification of the record start point, no inconsistency is detected.

[0167] The log-start verification determines that the consent information with consent information identifier C000003 corresponds to the first line of the communication log, the consent information with consent information identifier C000007 corresponds to the second line of the communication log, and the consent information with consent information identifier C000010 corresponds to the fifth line of the communication log. No inconsistencies are detected by the log-start verification.

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

[0169] Step S107: Omitted since it is the same as in embodiment 1-1.

[0170] (Example 4) The following is an example in which it is determined that there is no consistency between the consent record and the communication log in step S106. The target data processor is C001.

[0171] 13 stored in the second storage system 601. In this case, in the verification of the record start point in step S106, it corresponds to the case where there is no corresponding reception log for the direct acquisition consent, and it is determined that there is no consistency.

[0172] FIG. 16 shows an example of consent information (consent revocation information). It is assumed that there is no consent information with consent information identifier C000010 (revocation of directly acquired consent) in FIG. 16 for the consent records stored in the first storage system 201. In this case, in the verification of consistency between the consent records and the processing records in step S104, since there is a reception log of non-consent that is not based on the revocation of consent, it is determined that there is no consistency. Furthermore, in the verification of the log start point in step S106, if there is no corresponding indirectly acquired consent, directly acquired consent, or provision consent that is not based on the revocation of storage consent for the reception log of consent from the owner, it is determined that there is no consistency.

[0173] Even if the communication log does not include content items, it is possible to distinguish between receipt of the owner's consent and receipt of personal data (see Figure 14) and perform consistency verification using a simplified correspondence between the record and the log. A simplified correspondence between the record and the log means that the descriptions identifying each item in the consent record (owner identifier and processing business operator) match the descriptions identifying each item in the communication log (sender and receiver).

[0174] <Embodiment 1-4> The verification device 1 verifies the consistency between the consent record (consent information) and the authentication log for each owner. This is premised on the fact that the processing business operator (provider, receiver, or acquirer) has an authentication log corresponding to the consent record, or that the verification device 1 has access to the authentication log. When the data owner gives consent to the processing to the data management device 101 and the data management device 101 registers consent information (a record related to consent) based on the owner's consent, the determination processing unit 13 in the data management device 101 authenticates the data owner. The authentication method may be any method such as electronic certificate authentication, one-time password authentication, multi-factor authentication, etc. The data owner uses the owner device 501 to access the data management device 101 and inputs information required for consent (e.g., an owner identifier, information identifying the contents of consent, etc.) and information required for authentication. The determination processing unit 13 authenticates the data owner based on the input information, and if the authentication is successful, decides to register the consent information based on the consent, and if the authentication is unsuccessful, rejects the registration of the consent information. The result of the authentication process (success or failure) is provided to the log storage unit 21 as an authentication log and is stored. An authentication unit that authenticates the data owner may be provided separately from the determination processing unit 13.

[0175] FIG. 17 shows an example of an authentication log 1-4. Content items of the authentication log include authentication success or authentication failure. The date and time is the date and time when the authentication was performed, which may be more granular than the date and time of the record related to the process. The data owner is the owner identifier of the owner who was the subject of authentication.

[0176] The operation example of the embodiment 1-4 is basically the same as that of the embodiment 1-1 (steps S101 to S104 and S107 are the same), but steps S105 and S106 are different.

[0177] Verification of consistency between the consent record and the authentication log is performed from the record start point. A record and a log correspond to each other when the description (owner identifier) ​​identifying the data owner in the consent record matches the description identifying the data owner in the authentication log, and when the date and time (year, month, and day) identified in the consent record and the date and time identified in the authentication log are closer to each other than a threshold value. The threshold value may be fixed in advance or may be variable by user input.

[0178] Step S105: The verification device 1 obtains an authentication log related to the owner identifier from the second storage system 601. It is also possible to obtain only the authentication log of the owner.

[0179] Step S106: The verification device 1 verifies the consistency between the consent record including the identifier of the target data processor among the consent records (consent information) including the consent information identifier acquired in step S102 and the authentication log of the owner. The target data processor may be fixed in advance or may be variable by user input.

[0180] In the verification of the record start point, the verification device 1 determines that there is no consistency when there is no corresponding owner authentication success log for the indirect acquisition consent and the direct acquisition consent. Also, the verification device 1 determines that there is no consistency when there is no corresponding owner authentication success log for the provision consent that is not based on the withdrawal of the storage consent.

[0181] An example of the operation of each step is specifically shown below. The owner device 501 does not directly access the first storage system 201, but accesses the first storage system 201 via the target data processor's device (e.g., the data management device 101, the second storage system 601, the data source device 301, and the data destination device 401). Therefore, the data processor's device has an authentication log of the owner.

[0182] (Example 1) Step S101: The verification device 1 receives a consistency verification request for the owner identifier U000001.

[0183] Steps S102 to S104: Omitted as they are the same as in embodiment 1-1.

[0184] Step S105: The verification device 1 acquires the authentication log related to the owner identifier U000001 from the second storage system 601. The log in the second line is acquired from the authentication log in Fig. 17. In addition, the target processing company is assumed to be C001. Based on the owner identifier U000001 and the processing company C001, the consent information identifier C000007 (indirectly acquired consent) is acquired. Step S106: The verification device 1 verifies the consistency between the consent information of the consent information identifier and the authentication log. In the verification of the record start point, the second line of the authentication log corresponds to the consent information identifier C000007. In the verification of the record start point, no inconsistency is detected. Therefore, the verification device 1 determines that no inconsistency is detected between the record regarding consent and the authentication log.

[0185] Step S107: Omitted since it is the same as in embodiment 1-1.

[0186] (Example 2) Step S101: The verification device 1 receives a consistency verification request for the owner identifier U000002.

[0187] Steps S102 to S104: Omitted as they are the same as in embodiment 1-1.

[0188] Step S105: The verification device 1 acquires the authentication log related to the owner identifier U000002 from the second storage system 601. The logs of the first and third lines of the authentication log in Fig. 17 are acquired. In addition, the target processing company is assumed to be C001. Based on the owner identifier U000002 and the processing company C001, consent information identifiers C000003 and C000010 (directly acquired consent) are acquired.

[0189] Step S106: The verification device 1 verifies the consistency between the consent information of the consent information identifier and the authentication log. In the verification of the record start point, the first line of the authentication log corresponds to the consent information identifier C000003, and the third line of the authentication log corresponds to the consent information identifier C000010. No inconsistency is detected in the verification of the record start point. Therefore, the verification device 1 determines that no inconsistency is detected between the record regarding consent and the authentication log.

[0190] Step S107: Omitted since it is the same as in embodiment 1-1.

[0191] (Example 3) Step S101: The verification device 1 receives a consistency verification request.

[0192] Steps S102 to S104: Omitted as they are the same as in embodiment 1-1.

[0193] Step S105: The verification device 1 acquires the authentication log of the owner from the second storage system 601. The logs from the first to third lines of Fig. 17 (all logs) are acquired. The target processing business operator is C001. In addition, the consent information identifiers C000003 (directly acquired consent), C000007 (indirectly acquired consent), and C000010 (directly acquired consent) are acquired as the consent information identifiers for all consent information.

[0194] Step S106: The verification device 1 verifies the consistency between the consent information of the consent information identifier and the authentication log. In the verification of the record start point, the consent information identifier C000003 corresponds to the first line of the authentication log, the consent information identifier C000007 corresponds to the second line of the authentication log, and the consent information identifier C000010 corresponds to the fifth line of the authentication log. No inconsistency is detected in the verification of the record start point. Therefore, the verification device 1 determines that no inconsistency is detected between the record regarding consent and the authentication log.

[0195] Step S107: Omitted since it is the same as in embodiment 1-1.

[0196] (Example 4) The following is an example in which the verification of the consent-related record and the authentication log in step S106 determines that there is no consistency.

[0197] 17 stored in the second storage system 601, it is assumed that there is no log in the second line or the value of the content item is authentication failure. In this case, in the verification of the record start point in step S106, it corresponds to the case where there is no corresponding authentication success log for the indirectly acquired consent, and it is determined that there is no consistency.

[0198] Second embodiment <Embodiment 2-1> 18 is a diagram showing the overall configuration of a data management system which is an information processing system according to the second embodiment. A data management device 101 further includes an identifier correspondence storage unit 41 and an identifier conversion unit 42. The same elements as those in the first embodiment are given the same reference numerals and descriptions thereof will be omitted as appropriate.

[0199] In the second embodiment, for the same data owner (individual), the data management device 101, the first storage system 201, the data source device 301, and the data destination device 401 use different owner identifiers from each other.

[0200] The identifier correspondence storage unit 41 stores a correspondence table 41A between the owner identifiers of the devices (101, 201, 301, 401). The correspondence table 41A is stored by the administrator of the data management device 101 or the like.

[0201] 19 shows an example of the correspondence table 41A. As an example, the owner identifier 1 is an identifier used for managing (identifying) the owner in the first storage system 201, and the owner identifier 2 is an identifier used for managing the owner in the data management device 101. Also, the owner identifier 3 is an identifier used for managing the owner in the data sending device 301, and the owner identifier 4 is an identifier used for managing the owner in the data receiving device 401. When the owner identifier is common to a plurality of devices, the correspondence table 41A may be for two or three types of owner identifiers instead of four types. For example, the correspondence table 41A may be for owner identifier 2 and owner identifier 3. The correspondence table 41A may be generated by associating the previously obtained owner identifier with the newly acquired owner identifier.

[0202] The identifier conversion unit 42 receives information including the owner identifier to be converted (information to be converted) and information on the output destination of the information including the converted owner identifier (output destination information). The identifier conversion unit 42 obtains the corresponding owner identifier j (j=1,...,4,j≠i) from the owner identifier i (i=1,...,4) included in the information to be converted based on the correspondence table 41A. The identifier conversion unit 42 generates information in which the owner identifier i in the information to be converted is replaced with the owner identifier j as converted information. In this way, the owner identifier i included in the information to be converted is converted to the owner identifier j. The identifier conversion unit 42 outputs the converted information including the converted owner identifier j to the output destination indicated by the output destination information.

[0203] The operation of the data management device 101 of the second embodiment differs from that of the first embodiment in that, when an exchange occurs between devices that handle different owner identifiers, a process of converting the owner identifier is added in the identifier conversion unit 42. When the owner identifier is common between some of the multiple devices, the process of converting the owner identifier in the identifier conversion unit 42 is not necessary in the exchange between the devices that have the common owner identifier.

[0204] As described above, by adding the identifier correspondence relationship storage unit 41 and the identifier conversion unit 42, even if different owner identifiers are used in each system or device, it is possible to confirm and record consent.

[0205] The owner identifier (owner identifier 2) used in the data storage unit 11 may be a pseudonym. The pseudonym is, for example, a random character string that does not overlap with other characters. Although an individual cannot be identified by the pseudonym alone, the individual can be identified by using the correspondence table 41A.

[0206] 20 shows an example of correspondence table 41A in which owner identifier 2 is a pseudonym. Owner identifiers other than owner identifier 2 may be pseudonyms. Also, more than one of owner identifiers 1 to 4 may be pseudonyms. By using a pseudonym, data can be stored under a pseudonym, and individual privacy can be protected.

[0207] The verification device 1 accesses the correspondence table 41A and verifies the consistency between the records related to the processing and the data access log for each owner. The operation of the verification device 1 will be described below with reference to FIG.

[0208] FIG. 21 is a flowchart of an example of the operation of the verification device 1 according to the second embodiment.

[0209] Step S201: The verification device 1 receives a request for verifying consistency with the owner identifier 1 (or 2).

[0210] Step S202: The verification device 1 obtains the owner identifier 2 (or 1) corresponding to the owner identifier 1 (or 2) from the correspondence table 41A.

[0211] Step S203: The verification device 1 acquires the consent information identifier of the consent information including the owner identifier 1 from the first storage system 201.

[0212] Step S204: The verification device 1 obtains a record identifier of a record including the consent information identifier in a consent information item from the first storage system 201. If the record related to the transaction includes the owner identifier 1, the verification device 1 may obtain a record identifier of a record including the owner identifier from the first storage system 201.

[0213] Step S205: The verification device 1 verifies the consistency between the record regarding the consent (consent information) and the record regarding the process.

[0214] The correspondence between the record and the log means that the description (owner identifier 1) that identifies the data in the consent record that the processing record refers to corresponds to the description (owner identifier 2) that identifies the data in the data access log. This corresponds to the case in the first embodiment where the owner identifiers match each other.

[0215] Step S 206 : The verification device 1 obtains the data access log related to the owner identifier 2 from the second storage system 601 .

[0216] Step S207: The verification device 1 verifies the consistency between the record related to the process including the target recording business operator among the records including the record identifier acquired in step S204 and the acquired data access log.

[0217] Step S208: When it is determined that there is no consistency in at least one of the verification of the record start point and the verification of the log start point, the verification device 1 outputs information that an inconsistency has been detected (no consistency).

[0218] An example of the operation of each step is specifically shown below. The owner identifier 2 is assumed to be a pseudonym. It is assumed that a real name corresponding to the owner identifier 2 is used in the data management device, and the owner identifier 2 (pseudonym) is used in the data storage unit 11.

[0219] (Example 1) Step S201: The verification device 1 receives a consistency verification request for the owner identifier 1 (U000001). Step S202: The verification device 1 obtains the owner identifier 2 (DKGLANCK) corresponding to the owner identifier 1 (U000001) from the correspondence table 41A.

[0220] Steps S203 to S205: These are the same as steps S102 to S104 in the embodiment 1-1, and therefore will be omitted.

[0221] Step S206: The verification device 1 acquires the data access log related to the owner identifier 2 (DKGLANCK) from the second storage system 601. 22 shows an example of a data access log 2-1. The verification device 1 acquires the logs of the first, third, and fourth lines in the data access log of FIG. The target record business operator is C001. The verification device 1 acquires record identifiers R000002 (received record) and R000004 (created record) based on the record business operator C001 and the owner identifier 1 (U000001).

[0222] Step S207: The verification device 1 verifies the consistency between the record and the data access log. In the verification of the record start point, it is determined that the record with record identifier R000002 corresponds to the first line of the data access log, and the record with record identifier R000004 corresponds to the third and fourth lines of the data access log. In the verification of the record start point, no inconsistency is detected. The log origin verification determines that the record with record identifier R000002 corresponds to the first line of the data access log, and the record with record identifier R000004 corresponds to the fourth line of the data access log. The log origin verification does not detect any inconsistencies. Therefore, the verification device 1 determines that no inconsistency is detected between the record related to the process and the data access log.

[0223] Step S208: This is the same as step S107 in embodiment 1-1, and therefore will be omitted.

[0224] (Example 2) Step S201: The verification device 1 receives a consistency verification request for the owner identifier 1 (U000002).

[0225] Step S202: The verification device 1 obtains the owner identifier 2 (PEQZLFMA) corresponding to the owner identifier 1 (U000002) from the correspondence table 41A.

[0226] Steps S203 to S205: These are the same as steps S102 to S104 in the embodiment 1-1, and therefore will be omitted.

[0227] Step S206: The verification device 1 obtains the access log relating to the owner identifier 2 (PEQZLFMA) from the second storage system 601. The verification device 1 obtains the log of the second and fifth lines in the data access log of FIG. The target record business operator is C001. The verification device 1 acquires record identifiers R000003 (acquired record) and R000005 (deleted record) based on the record business operator C001 and the owner identifier 1 (U000002).

[0228] Step S207: The verification device 1 verifies the consistency between the record and the data access log. In the verification of the record start point, the record with record identifier R000003 corresponds to the second line of the data access log, and the record with record identifier R000005 corresponds to the fifth line of the data access log. In the verification of the record start point, no inconsistency is detected. In the log origin verification, the record with record identifier R000003 corresponds to the second line of the data access log, and the record with record identifier R000005 corresponds to the fifth line of the data access log. In the log origin verification, no inconsistency is detected. Therefore, the verification device 1 determines that no inconsistency is detected between the record related to the process and the data access log.

[0229] Step S208: Omitted since it is the same as in embodiment 1-1.

[0230] (Example 3) This shows a modified example in which a function is added to enhance reliability. A hash value of the correspondence relationship of the owner identifier used is added as an item to the provision record, receipt record, and acquisition record. In steps S203 to S205, the verification device 1 calculates a hash value of the correspondence relationship of the owner identifier stored in the identifier correspondence storage unit 41, and compares the calculated hash value with the hash value of the item in the record. If they do not match, it may be determined that there is no consistency. A plurality of types of owner identifiers may be used. In this case, a plurality of types of owner identifiers 2 may be included in the access destination of the data access log.

[0231] <Embodiment 2-2> The verification device 1 accesses the correspondence table 41A and verifies the consistency between the records related to the processing and the communication log for each owner. Regarding the steps of the operation of the verification device 1 in the embodiment 2-2, steps S203 to S205 and S208 in the embodiment 2-1 are also applied to the embodiment 2-2. The operations corresponding to steps S201, S202, S206, and S207 are different from those in the embodiment 2-1.

[0232] The correspondence between the record and the log means that the description (owner identifier 1) that identifies the data in the record related to the process corresponds to the description (owner identifier i, i=1,...,4) that identifies the data in the communication log. This corresponds to the case where the owner identifiers match in the first embodiment.

[0233] Steps S201 and S202: The verification device 1 receives a consistency verification request for the owner identifier i (i=1, ..., 4). The verification device 1 obtains the owner identifier j (j=1, ..., 4, j≠i) corresponding to the owner identifier i (i=1, ..., 4) from the correspondence table 41A.

[0234] Step S206: The verification device 1 acquires from the second storage system 601 a communication log relating to the owner identifier i (i=1, . . . , 4).

[0235] Step S207: The verification device 1 verifies the consistency between the records related to the process including the target recorder among the records including the record identifier acquired in step S204 and the communication log. If it is determined that there is no consistency in at least one of the verification of the record start point and the verification of the log start point, an inconsistency is detected (determined that there is no consistency).

[0236] An example of the operation of each step will be specifically described below. The owner identifier 2 is a real name. It is assumed that the owner identifier 2 (real name) is used in the data management device, and a pseudonym corresponding to the owner identifier 2 is used in the data storage unit 11.

[0237] (Example 1) Steps S201 and S202: The verification device 1 receives a consistency verification request for the owner identifier 2 (V000001). The verification device 1 obtains the owner identifier 1 (U000001) and the owner identifier 3 (Username1) for the owner identifier 2 (V000001) from the correspondence table 41A.

[0238] Steps S203 to S205: Omitted as they are the same as in embodiment 1-1.

[0239] Step S206: The verification device 1 acquires from the second storage system 601 a communication log relating to the owner identifier 2 (V000001) and the owner identifier 3 (Username1). Fig. 23 shows an example of a communication log 2-2. The verification device 1 acquires the logs on the second and third lines from the communication log in Fig. 23. Also, assume that the target record operator is C001. Based on the record operator C001 and the owner identifier 1 (U000001), record identifiers R000002 (receiving record) and R000004 (creating record) are acquired. R000004 (creating record) is not used for verification with the communication log because it is not related to sending or receiving. R000002 (receiving record) is used for verification with the communication log.

[0240] Step S207: The verification device 1 verifies the consistency between the record and the communication log. In the verification of the record start point, it is determined that the third line of the communication log corresponds to the record with the record identifier R000002. In the verification of the record start point, no inconsistency is detected. Log-based verification shows that there are no logs of personal data transmission. Log-based verification does not detect any inconsistencies. Therefore, the verification device 1 determines that no inconsistency is detected between the record related to the process and the communication log.

[0241] Step S208: Omitted since it is the same as in embodiment 1-1.

[0242] (Example 2) Steps S201 and S202: The verification device 1 receives a consistency verification request for the owner identifier 2 (V000002). The verification device 1 obtains the owner identifier 1 (U000002) and the owner identifier 3 (Username2) corresponding to the owner identifier 2 (V000002) from the correspondence table 41A.

[0243] Steps S203 to S205: Omitted as they are the same as in embodiment 1-1.

[0244] Step S206: The verification device 1 obtains the communication log relating to the owner identifier 2 (V000002) and the owner identifier 3 (Username2) from the second storage system 601. The logs of the first, fourth and fifth lines of the communication log in FIG. The target record operator is C001. Based on record operator C001 and owner identifier 1 (U000002), record identifiers R000003 (acquired record) and R000005 (deleted record) are obtained. R000005 (deleted record) is not used for verification with the communication log because it is not related to sending or receiving. R000003 (acquired record) is used for verification with the communication log.

[0245] Step S207: The verification device 1 verifies the consistency between the record and the communication log. In the verification of the record start point, the fourth line of the communication log corresponds to the record with the record identifier R000003. In the verification of the record start point, no inconsistency is detected. Log-based verification shows that there are no logs of personal data transmission. Log-based verification does not detect any inconsistencies. Therefore, the verification device 1 determines that no inconsistency is detected between the record related to the process and the communication log.

[0246] Step S208: Omitted since it is the same as in embodiment 1-1.

[0247] The communication log shown in Fig. 23 is an example, and other examples of communication logs are also possible. For example, the owner identifiers written in the sender, receiver, and content items may be pseudonyms. Furthermore, the owner identifier 3, which is an identifier used to manage the owner in the data sending device 301, may be of multiple types, for example, depending on the data sending source. The owner identifier 4, which is an identifier used to manage the owner in the data receiving device 401, may be of multiple types, for example, depending on the data receiving destination.

[0248] <Embodiment 2-3> The verification device 1 accesses the correspondence table 41A and verifies the consistency between the consent-related record (consent information) and the communication log for each owner. Regarding the operation steps of the verification device in embodiment 2-3, steps S203 to S205 and S208 in embodiment 2-1 are similarly applied to embodiment 2-3, and steps S201 and S202 in embodiment 2-2 are similarly applied to embodiment 2-3. The operations corresponding to steps S206 and S207 are different from those in embodiment 2-1 and embodiment 2-2.

[0249] The correspondence between the record and the log means that the description (owner identifier 1) that identifies the data in the record related to the agreement corresponds to the description (owner identifier i, i=1,...,4) that identifies the data in the communication log. This corresponds to the owner identifiers matching in the first embodiment.

[0250] Step S206: The verification device 1 acquires from the second storage system 601 a communication log relating to the owner identifier i (i=1, . . . , 4).

[0251] Step S207: The verification device 1 verifies the consistency between the consent information (record related to consent) including the target processing company among the consent information of the consent information identifier acquired in step S203 and the communication log. If there is no consistency in at least one of the verification of the record start point and the verification of the log start point, the verification device 1 detects an inconsistency (determines there is no consistency).

[0252] A specific example of the operation of each step will be shown below.

[0253] (Example 1) Step S201: The verification device 1 receives a consistency verification request for the owner identifier 2 (V000001).

[0254] Step S202: Omitted since it is the same as in embodiment 2-2.

[0255] Steps S203 to S205: Omitted as they are the same as in embodiment 1-1.

[0256] Step S206: The verification device 1 obtains the log relating to the owner identifier 2 (V000001) and the owner identifier 3 (Username1) from the communication log in the second storage system 601. The logs in the second and third lines in the communication log in FIG. In addition, the target data processor is C001. Based on the data processor C001 and the owner identifier (U000001), a consent information identifier C000007 (indirectly acquired consent) is acquired.

[0257] Step S207: The verification device 1 verifies the consistency between the consent information (record related to consent) of the consent information identifier and the communication log. In the verification of the record start point, it is determined that the second line of the communication log corresponds to the consent information of the consent information identifier C000007. In the verification of the record start point, no inconsistency is detected. In the log-start verification, the second line of the communication log corresponds to the consent information with the consent information identifier C000007. In the log-start verification, no inconsistency is detected. Therefore, the verification device 1 determines that no inconsistency is detected between the record regarding the consent and the communication log.

[0258] Step S208: Omitted since it is the same as in embodiment 1-1.

[0259] (Example 2) Step S201: The verification device 1 receives a consistency verification request for the owner identifier 2 (V000002).

[0260] Step S202: Omitted since it is the same as in embodiment 2-2.

[0261] Steps S203 to S205: Omitted as they are the same as in embodiment 1-1.

[0262] Step S206: The verification device 1 obtains the communication log relating to the owner identifier 2 (V000002) and the owner identifier 3 (Username2) from the communication log in the second storage system 601. The logs in the first, fourth, and fifth lines in the communication log in FIG. In addition, the target data processing business operator is C001. Based on the data processing business operator C001 and the owner identifier 2 (U000002), consent information identifiers C000003 and C000010 (directly acquired consent) are obtained.

[0263] Step S207: The verification device 1 verifies the consistency between the consent information (record related to consent) of the consent information identifier and the communication log. In the verification of the record start point, the first line of the communication log corresponds to the consent information of the consent information identifier C000003, and the fifth line of the communication log corresponds to the consent information of the consent information identifier C000010. In the verification of the record start point, no inconsistency is detected. In the log starting verification, the consent information with the consent information identifier C000003 corresponds to the first line of the communication log, and the consent information with the consent information identifier C000010 corresponds to the fifth line of the communication log. No inconsistencies are detected in the log starting verification. Therefore, the verification device 1 determines that no inconsistency is detected between the record related to the process and the communication log.

[0264] Step S208: Omitted since it is the same as in embodiment 1-1.

[0265] (Third embodiment) <Embodiment 3-1> FIG. 24 is a block diagram showing an example of a data management system which is an information processing system according to an embodiment of the present invention. The same or corresponding elements as those in FIG. 1 are given the same reference numerals, and detailed description is omitted as appropriate. The information processing system according to this embodiment includes a related party device 501 (corresponding to the owner device 501 in FIG. 1) which is an information processing device of a data related party (e.g., a data owner), a data management device 101 which is an information processing device of a data handler, a user device 701 which is an information processing device of a data user who is a third party who is neither a data related party nor a data handler, a first storage system 201 (a blockchain system in this example), and a verification device 1. The verification device 1 is an information processing device that performs verification regarding various records written in the blockchain system 201. In FIG. 1, the verification device 1 is shown as a device separate from the related party device 501, the data management device 101, and the user device 701, but may be the same device as at least one of the related party device 501, the data management device 101, and the user device 701. The data management device 101 is connected to a second storage system 601. The data management device 101 has a user-oriented identifier correspondence table 91 (hereinafter, correspondence table 91). The correspondence table 91 is stored in a data storage unit or another storage unit. The block configurations of the verification device 1, the data management device 101, and the second storage system 601 are assumed to be the same as those in FIG. 1.

[0266] The number of related party device 501, data management device 101, and user device 701 is not limited to one, and may be multiple. The user device 701 corresponds to the data source device 301 or the data destination device 401 in FIG. 1, for example. However, the user device 701 may be the data management device 101.

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

[0268] It should be noted that the data parties, data handlers, and data users are not limited to specific persons, and may be individuals or corporations. Furthermore, the data parties simply mean persons associated with the data, and are not limited to specific persons. For example, the data parties may be consenters who have agreed to the handling of data by the data handler, data owners, or agents of such owners. Furthermore, the data parties may be persons identified by the data. For example, the data may indicate an address, gender, age, etc., and a person identified by such an address, etc. may be considered as a data party. In this way, consent to the data or persons related to the data itself are envisioned as data parties.

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

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

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

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

[0273] Also, the related party device 501, the data management device 101, and the user device 701 may write to the block of the blockchain individually, or any one of them may write on behalf of the other. For example, the related party device 501 may write a record of consent to a block of 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 related party device 501 via a medium other than the blockchain, such as an email or a web page, and write a record of consent to a block of the blockchain based on the information.

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

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

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

[0277] Fig. 25 is a diagram showing an example of a block chain according to this embodiment. Fig. 26 is a diagram following Fig. 25. The block chains in Figs. 25 and 26 will be described below.

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

[0279] The relationship between the third embodiment and the terms used in the explanation of the first and second embodiments will be explained. The data stakeholders in the third embodiment correspond to the data owners in the first and second embodiments. The transaction ID corresponds to the consent information identifier or record identifier in the first and second embodiments. The BC user ID corresponds to the owner identifier or recording business operator in the first and second embodiments. "Handling" is used in the same sense as "processing" in the first and second embodiments. The records related to processing include a provision record, a receipt record, an acquisition record, a creation record, a deletion record, and a usage record. Note that there is no example of a creation record in the third embodiment. Records of consent (consent information) include records of directly acquired consent, records of indirectly acquired consent, and records of consent to provision. In the third embodiment, there is no example of indirectly acquired consent, but consent to provision where the recipient is a data handler corresponds to indirectly acquired consent.

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

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

[0282] Block 301 also indicates a record of consent to handling. Block 301 indicates that "hanako" has given consent to the provision of data, stating that data may be provided if the data source is "dealer1" and the data recipient is a data user with BC user ID "company1". This can also be considered consent to the receipt of data by "company1". In this record, the type of handling is "provision" and the type of record is "consent to handling". A record of such consent is called consent to provision. Similarly, block 302 indicates that "hanako" has given consent to the provision of data, stating that data may be provided if the data source is "dealer1" and the data user is "company2". This can also be considered consent to the receipt of data by "company2". As with block 301, the type of handling is "provision" and the type of record is "consent to handling" (consent to provision).

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

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

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

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

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

[0288] Block 312 is a transaction execution record showing the use of data by "dealer1". The type of record is "transaction execution" and the type of transaction is "use". A record of such transactions is called a usage record. The party involved in the data is the BC user ID "hanako" of the referencing consent ID 00. "dealer1" corresponds to a data handler (see Figure 1), but data can be used not only by data users but also by data handlers. In other words, a data handler can also be a data user.

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

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

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

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

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

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

[0295] In addition, in the examples of FIG. 25 and FIG. 26, one record is written in one block, but it is not necessarily one-to-one, and multiple records may be written in one block. For example, a handling consent record regarding acquisition (direct acquisition consent) and a handling consent record regarding provision (provision consent) may be written in one block. Also, multiple items of the same type may be described in one record. For example, multiple consents such as consent to acquisition (direct acquisition consent) and consent to provision (provision consent) may be included in one handling consent record. Alternatively, one handling consent record regarding acquisition (direct acquisition consent) may include consent regarding acquisition for each of multiple related parties. Also, when multiple data are provided at once based on multiple consents, the handling execution record regarding data provision (provision record) may include information indicated by multiple handling consent records regarding data provision (provision consent).

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

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

[0298] Various information may be added to the records written in the blockchain. For example, details of the data to be acquired, provided, etc. may be added. When the data management device 101 provides a part of the data passed from the related party device 501 to the user device 701, information that allows the part to be recognized, such as the item name and the position in the data, may be recorded. Also, when there is only one data management device 101, the BC user ID of the data management device 101 that provides the data may not be included in the record.

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

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

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

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

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

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

[0305] 25 and 26 are merely examples, and various records may be written in the blockchain. For example, records of usage other than receipt of data may be written, such as a record of a data user analyzing, editing, or deleting data. Furthermore, the item of the received data, the BC user ID of the data management device 101 that provided the data, and the like may be recorded in the usage record related to receipt.

[0306] The verification device 1 accesses the correspondence table 91 and verifies the consistency between the records regarding the processing and the data access log for each data related party.

[0307] FIG. 27 is a flowchart of an example of the operation of the verification device 1 according to the third embodiment.

[0308] Step S301: The verification device 1 receives a consistency verification request for the BC user ID (eg, owner identifier) ​​of a data related person.

[0309] Step S302: The verification device 1 acquires a BC user ID, which is an identifier for a user, from the correspondence table 91 based on the BC user ID (owner identifier) ​​of the data related person.

[0310] Step S303: The verification device 1 acquires from the first storage system 201 a transaction ID (agreement information identifier) ​​of the handling agreement including a BC user ID (an owner identifier or an identifier for a user).

[0311] Step S304: The verification device 1 acquires a transaction ID of a handling execution that includes the transaction ID (consent information identifier) ​​of the handling agreement in the agreement ID item from the first storage system 201. If the handling execution record (record related to the processing) includes the BC user ID (identifier for the user) of the data related party, the verification device 1 may acquire a transaction ID of a handling execution that includes the BC user ID (owner identifier or identifier for the user) of the data related party from the first storage system 201.

[0312] Step S305: The verification device 1 verifies the consistency between the handling agreement (a record related to the agreement) and the handling execution record (a record related to the processing).

[0313] Step S306: The verification device 1 acquires a data access log (see FIG. 28 described later) related to the BC user ID of the data related party (such as the data owner) from the second storage system 601. In the data access log, the BC user ID for the target recording company is used as the BC user ID of the data related party (the BC user ID is different for each recording company even for the same data related party).

[0314] Step S307: The verification device 1 verifies the consistency between the handling execution record (record related to processing) including the BC user ID of the target recording business operator among the handling execution records of the transaction ID acquired in step S304 and the data access log. In verifying the record start point, the same process as in embodiment 1-1 is performed. Furthermore, when the transaction execution record is a usage record, if there is no corresponding read log for the usage record, it is determined that there is no consistency. The verification device 1 detects an inconsistency (determines that there is no consistency) when there is no consistency in at least one of the record start point and the log start point.

[0315] Step S308: If no inconsistency is detected in both step S305 and step S307, the verification device 1 determines that no inconsistency is detected overall. The verification device 1 may output (for example, display on a screen) information indicating that no inconsistency is detected overall. If it is determined that there is no consistency in at least one of step S305 and step S307, it determines that an inconsistency is detected overall. The verification device 1 may output information indicating that an inconsistency is detected overall. At this time, information identifying whether the inconsistency was detected in step S305 or step S307 may also be displayed on the screen.

[0316] A specific example of the operation of each step will be shown below. (Example 1) Step S301: The verification device 1 receives a consistency verification request for the BC user ID (hanako). Step S302: The verification device 1 obtains from the correspondence table 91 the BC user ID (g7h8i9) which is an identifier for the first user and the BC user ID (j1k2m3) which is an identifier for the second user, which correspond to the BC user ID (hanako).

[0317] Step S303: The verification device 1 acquires from the first storage system 201 the transaction IDs 00, 01, 02, 03, 04, 05, 06, 13, 14, 15, 16, and 17 of the handling agreement including the BC user ID (hanako, g7h8i9, j1k2m3). Step S304: The verification device 1 acquires from the first storage system 201 the transaction IDs 07, 08, 09, 10, 11, 12, and 18 of the handling execution, which include the transaction IDs 00, 01, 02, 03, 04, 05, 06, 13, 14, 15, 16, and 17 of the handling agreement in the agreement ID.

[0318] Step S304: The verification device 1 verifies the consistency between the handling agreement (agreement record) and the handling execution record (processing record). It is determined that no inconsistency is detected.

[0319] Step S306: The verification device 1 acquires the data access log related to the BC user ID (hanako) from the second storage system 601. Fig. 28 shows an example of data access log 3-1. The log of lines 1 to 5 is obtained from the data access log of Fig. 28. The BC user ID of the target recording business is dealer1. Based on dealer1, transaction IDs 07, 08, 10, 12, and 18 of handling execution are obtained.

[0320] Step S307: The verification device 1 verifies the consistency between the record of the transaction execution and the data access log. In verifying the record start point, it is determined that the first line of the data access log corresponds to the acquisition record of transaction ID07, the second line of the data access log corresponds to the provision record of transaction ID08, the third line of the data access log corresponds to the provision record of transaction ID10, the fourth line of the data access log corresponds to the usage record of transaction ID12, and the fifth line of the data access log corresponds to the deletion record of transaction ID18. In verifying the record start point, no inconsistency is detected. The log-start verification determines that the acquisition record of transaction ID 07 corresponds to the first line of the data access log, and that the deletion record of transaction ID 18 corresponds to the fifth line of the data access log. The log-start verification does not detect any inconsistencies. Therefore, the verification device 1 determines that no inconsistency is detected between the transaction execution record (record related to the processing) and the data access log.

[0321] Step S308: This is the same as step S107 in embodiment 1-1, and therefore will be omitted.

[0322] <Embodiment 3-2> The verification device 1 accesses the correspondence table 91 and verifies the consistency between the handling execution record (record related to processing) and the communication log for each data related person. Regarding the operation of the verification device in embodiment 3-2, steps S301 to S305 and S308 in embodiment 3-1 are also applied to embodiment 3-2. The operations corresponding to steps S306 and S307 are different from those in embodiment 3-1.

[0323] Step S306: The verification device 1 acquires from the second storage system 601 a communication log related to the BC user ID of the data related person. Step S307: The verification device 1 verifies the consistency between the transaction execution record (record related to the process) including the BC user ID of the target record business operator among the transaction execution records indicated by the transaction ID acquired in step S304 and the communication log. If it is determined that there is no consistency in at least one of the record start point and the log start point, an inconsistency is detected (determined to be no consistency).

[0324] A specific example of the operation of each step will be shown below.

[0325] Steps S301 and S302: Omitted since they are the same as those in embodiment 3-1.

[0326] Steps S303 to S305: Omitted because they are the same as in embodiment 3-1.

[0327] Step S306: The verification device 1 acquires from the second storage system 601 a communication log relating to the BC user ID (hanako, g7h8i9, j1k2m3). Figure 29 shows an example of communication log 3-2. Assuming that only the communication log of personal data transmission and reception is to be obtained, lines 4 to 6 of the communication log in Figure 29 are obtained. The BC user ID of the target recording business operator is dealer1. Based on dealer1, transaction IDs 07, 08, 10, 12, and 18 of handling execution are obtained.

[0328] Step S307: The verification device 1 verifies the consistency between the transaction execution record and the communication log. In the verification of the record start point, the fourth line of the communication log corresponds to transaction ID07 (acquisition record), the fifth line of the communication log corresponds to transaction ID08 (provision record), and the sixth line of the communication log corresponds to transaction ID10 (provision record). In the verification of the record start point, no inconsistency is detected. In the log-start verification, transaction ID08 (provision record) corresponds to the fifth line of the communication log, and transaction ID10 (provision record) corresponds to the sixth line of the communication log. In the log-start verification, no inconsistency is detected. In this example, transaction ID07 (acquisition record) exists corresponding to the fourth line of the communication log, but there may be cases where transaction ID07 (acquisition record) exists corresponding to the fourth line of the communication log. For example, in the receipt or acquisition of personal data, after receiving personal data via a communication network, indirect acquisition consent or direct acquisition consent is confirmed, and if there is no record regarding consent or the consent state is non-consent, an operation of not writing personal data to the data storage unit 11 is permitted. For this reason, the absence of an acquisition record corresponding to data reception is not necessarily an inconsistency. Therefore, in the log-start verification, it is not necessarily necessary to confirm whether transaction ID07 (acquisition record) exists corresponding to the fourth line of the communication log, and such a confirmation is not performed in this operation example. Therefore, the verification device 1 determines that no inconsistency is detected between the transaction execution record (record related to the process) and the communication log.

[0329] Step S308: Omitted since it is the same as in embodiment 1-1.

[0330] <Embodiment 3-3> The verification device 1 accesses the correspondence table 91 and verifies the consistency between the agreement-related records and the communication logs for each data related person. Regarding the operation of the verification device in embodiment 3-3, steps S301 to S305 and S308 in embodiment 3-1 are also applied to embodiment 3-3. The operations corresponding to steps S306 and S307 are different from those in embodiment 3-1.

[0331] Step S306: The verification device 1 acquires a communication log related to the BC user ID of the data related person from the second storage system 601. In the reception log of the consent of the data related person, the BC user ID for the target processing company is used.

[0332] Step S307: The verification device 1 verifies the consistency between the handling agreement (record related to the agreement) including the BC user ID of the target processing company among the handling agreements indicated by the transaction ID acquired in step S304, and the communication log. If there is no consistency between at least one of the record start point and the log start point, an inconsistency is detected (determined to be inconsistent).

[0333] An example of the operation of each step is specifically shown below. The data related party's device (related party device) does not directly access the first storage system 201, but accesses it via the target processing company (e.g., the data management device 101 of the data handling company). Therefore, the processing company's device (e.g., the data management device 101) has a communication log corresponding to the record regarding the consent, and the processing company's device (e.g., the data management device 101) is the receiver that receives the owner's consent.

[0334] Steps S301 and S302: Omitted since they are the same as those in embodiment 3-1.

[0335] Steps S303 to S305: Omitted because they are the same as in embodiment 3-1.

[0336] Step S306: The verification device 1 acquires a communication log related to the BC user ID (hanako) from the second storage system 601. Assuming that only the communication log of receiving consent from the data related party is to be acquired, the first to third and seventh lines of the communication log in FIG. 29 are acquired. The BC user ID of the target processing company is dealer1. Based on dealer1, transaction IDs 00, 01, 02, 13 and 16 of handling consent are acquired.

[0337] Step S307: The verification device 1 verifies the consistency between the record of the handling agreement (agreement information) and the communication log. In verifying the record start point, it is determined that the first line of the communication log corresponds to the direct acquisition agreement for transaction ID 00, the second line of the communication log corresponds to the provision agreement for transaction ID 01, the third line of the communication log corresponds to the provision agreement for transaction ID 02, and the seventh line of the communication log corresponds to the withdrawal of direct acquisition agreement for transaction ID 13. The withdrawal of provision agreement for transaction ID 16 is generated as an internal process based on the withdrawal of direct acquisition agreement for transaction ID 13, so there is no corresponding communication log. No inconsistency is detected in the record start verification. In the log-based verification, the first line of the communication log corresponds to the direct acquisition agreement for transaction ID 00, the second line of the communication log corresponds to the provision agreement for transaction ID 01, the third line of the communication log corresponds to the provision agreement for transaction ID 02, and the seventh line of the communication log corresponds to the revocation of direct acquisition agreement for transaction ID 13. No inconsistencies are detected in the log-based verification. Therefore, the verification device 1 determines that no inconsistency is detected between the record regarding the consent and the communication log.

[0338] Step S308: Omitted since it is the same as in embodiment 1-1.

[0339] <Embodiment 3-4> The verification device 1 accesses the correspondence table 91 and verifies the consistency between the consent-related record and the authentication log for each data related person. Regarding the operation of the verification device in embodiment 3-4, steps S301 to S305 and S308 in embodiment 3-1 are also applied to embodiment 3-4. The operations corresponding to steps S306 and S307 are different from those in embodiment 3-1.

[0340] Step S306: The verification device 1 acquires an authentication log related to the BC user ID of the data related person from the second storage system 601. In the authentication log of the data related person, the BC user ID for the target processing company is used as the BC user ID of the data related person. Step S307: The verification device 1 verifies the consistency between the acquired agreement (agreement record) including the BC user ID of the target processing company among the handling agreements indicated by the transaction ID acquired in step S304, and the authentication log.

[0341] An example of the operation of each step is specifically shown below. The device of the data related party (related party device) does not directly access the first storage system 201, but accesses it via the device of the target data processor (e.g., data management device 101). Therefore, the authentication log corresponding to the handling agreement (records related to the agreement) is held by the data processor device (e.g., data management device 101).

[0342] Steps S301 and S302: Omitted since they are the same as those in embodiment 3-1.

[0343] Steps S303 to S305: Omitted because they are the same as in embodiment 3-1.

[0344] Step S306: The verification device 1 obtains the authentication log related to the BC user ID (hanako) from the second storage system 601. Fig. 30 shows an example of the authentication log 3-4. Assuming that only the authentication log of the data related person is to be obtained, the first to fourth lines of the authentication log in Fig. 30 are obtained. In addition, the BC user ID of the target processing company is (dealer1). Based on dealer1, transaction IDs 00, 01, 02, 13, and 16 of the handling agreement are obtained.

[0345] Step S307: The verification device 1 verifies the consistency between the record of the handling consent (consent information) and the authentication log. In the verification of the record start point, the first line of the authentication log corresponds to the direct acquisition consent for transaction ID 00, the second line of the authentication log corresponds to the provision consent for transaction ID 01, the second line of the authentication log corresponds to the provision consent for transaction ID 02, and the fourth line of the authentication log corresponds to the revocation of direct acquisition consent for transaction ID 13. The revocation of provision consent for transaction ID 16 is generated as an internal process based on the revocation of direct acquisition consent for transaction ID 13, so there is no corresponding authentication log. No inconsistency is detected in the verification of the record start point. Therefore, the verification device 1 determines that no inconsistency is detected between the handling agreement (record related to the agreement) and the authentication log.

[0346] Step S308: Omitted since it is the same as in embodiment 1-1.

[0347] (Hardware configuration) 31 shows the hardware configuration of the verification device 1 (information processing device). The data management device 101, the data source device 301, the data destination device 401, and the owner device (related person device) 501 also have the same hardware configuration. The verification device 1 is composed of a computer 900. The computer 900 includes a CPU 901, an input interface 902, a display device 903, a communication device 904, a main storage device 905, and an external storage device 906, which are interconnected by a bus 907.

[0348] The CPU (Central Processing Unit) 901 executes an information processing program, which is a computer program, on the main memory device 905. The information processing program is a program that realizes each of the above-mentioned functional configurations of the verification device 1. The information processing program may be realized by a combination of multiple programs or scripts, rather than a single program. Each functional configuration is realized by the CPU 901 executing the information processing program.

[0349] The input interface 902 is a circuit for inputting operation signals from input devices such as a keyboard, a mouse, and a touch panel to the verification device 1.

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

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

[0352] The main memory device 905 stores an information processing program, data required for executing the information processing program, data generated by executing the information processing program, etc. The information processing program is expanded and executed on the main memory device 905. The main memory device 905 is, for example, a RAM, a DRAM, or an SRAM, but is not limited to these. Each storage unit or database of the verification device 1 may be constructed on the main memory device 905.

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

[0354] The information processing program may be pre-installed in the computer 900, or may be stored in a storage medium such as a CD-ROM. The information processing program may also be uploaded onto the Internet.

[0355] Furthermore, the verification device 1 may be configured as a single computer 900, or may be configured as a system made up of a plurality of computers 900 connected to each other.

[0356] The present invention is not limited to the above-described embodiments as they are, and the components can be modified and embodied in the implementation stage without departing from the gist of the invention. Various inventions can be formed by appropriately combining multiple components disclosed in the above-described embodiments. For example, a configuration in which some components are deleted from all the components shown in each embodiment can also be considered. Furthermore, the components described in different embodiments can be appropriately combined. [Explanation of symbols]

[0357] 1. Verification device 1A Input section 1B Processing section 1C Acquisition Department 1D Verification Department 11 Data Storage Department 12 Consent information acquisition department 13 Judgment processing unit 14 History Registration Section 15 Input section 16 Output section 17 Data Analysis Section 21 Log Storage Department 41 Identifier correspondence storage unit 41A Owner Identifier Correspondence Table 42 Identifier conversion unit 91 User Identifier Correspondence Table (Correspondence Table) 101 Data management device 201 Consent information / history information storage system (first storage system, blockchain system) 301 Data sending device 401 Data receiving device 501 Owner device (related party device) 601 Secondary Storage System 701 User equipment 900 Computers 902 Input Interface 903 Display device 904 Communication equipment 905 Main storage 906 External storage device 907 Bus

Claims

1. Retrieving the records from a first storage system that holds at least one of records regarding processing of data and records regarding consent to processing of data; Retrieving the log from a second storage system that maintains a log of actions taken in connection with the transaction and / or the consent; A processing unit that verifies consistency of the acquired record based on the acquired log; Equipped with The record relating to the process is a record of a process involving writing, reading, or deleting data, determining that there is no consistency when a log of writing, reading, or deleting the data corresponding to the record related to the process is not included in the acquired log; Information processing device.

2. an input unit for receiving a request for verifying consistency of the data, the request including a condition related to a verification target; Obtaining a record that satisfies the condition from the first storage system, and obtaining a log that satisfies the condition from the second storage system. The information processing device according to claim 1 .

3. The processing unit determines that there is no consistency when a log of an operation corresponding to the process or consent indicated in the acquired record is not included in the acquired log.

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

4. The processing unit determines that there is no consistency when a record indicating a process or consent corresponding to an action indicated by the acquired log is not included in the acquired record. The information processing device according to any one of claims 1 to 3.

5. when a plurality of operations are performed in relation to the process, a plurality of logs corresponding to the plurality of operations are stored in the second storage system, The processing unit acquires a plurality of logs corresponding to the plurality of operations from the second storage system, identifies a log corresponding to the operation performed last from among the acquired plurality of logs, and determines that there is no consistency when a record indicating a process corresponding to the operation indicated by the identified log is not included in the acquired records. The information processing device according to any one of claims 1 to 4.

6. the processing unit acquires information regarding a correspondence relationship between a first identifier included in the record held in the first storage system and a second identifier included in a log stored in the second storage system from a data management device that holds information regarding the correspondence relationship; The processing unit verifies the consistency further based on the correspondence relationship indicated in the information. The information processing device according to claim 1 .

7. The processing unit detects a second identifier corresponding to the first identifier included in the acquired record from the correspondence relationship, and determines that there is no consistency when a value calculated based on the detected second identifier and the first identifier included in the acquired record differs from a value included in an item of the acquired record. The information processing device according to claim 6.

8. The processing unit acquires the data that is the subject of the processing related to the recording from a data management device that stores the data; The processing unit determines that there is no consistency when a value included in an item of the acquired record differs from a value calculated from the acquired data. The information processing device according to any one of claims 1 to 7.

9. When a value included in the consent record differs from a value calculated from a consent document specified in an item of the consent record, it is determined that there is no consistency. The information processing device according to any one of claims 1 to 8.

10. The processing unit acquires a record regarding the processing and a record regarding consent to the processing, When there is no record regarding consent to the processing, or when a consent period specified based on the record regarding consent to the processing does not include a time of the processing indicated in the record regarding the processing, the inconsistency is determined. The information processing device according to any one of claims 1 to 9.

11. The record relating to the processing is at least one of a receipt record, a provision record, an acquisition record, a creation record, a deletion record, and a usage record; The processing unit includes: determining that there is no consistency when a log of writing data corresponding to the receipt record is not included in the acquired log; determining that there is no consistency when a log of reading data corresponding to the provision record is not included in the acquired log; determining that there is no consistency when a log of writing data corresponding to the acquired record is not included in the acquired log; determining that there is no consistency when the read log or the write log of the data corresponding to the generation record is not included in the acquired log; determining that there is no consistency when a log of deletion of data corresponding to the deletion record is not included in the acquired log; When a log of reading data corresponding to the usage record is not included in the acquired log, it is determined that there is no consistency. The information processing device according to any one of claims 1 to 10.

12. The processing unit includes: determining that there is no consistency when the acquisition record, receipt record, or creation record corresponding to the data writing log is not included in the acquired record; When a deletion record corresponding to the log of data deletion is not included in the acquired records, it is determined that there is no consistency. The information processing device according to any one of claims 1 to 11.

13. The record relating to the processing is at least one of a receipt record, a provision record, and an acquisition record; The processing unit includes: determining that there is no consistency when a reception log of data corresponding to the receipt record is not included in the acquired log; When a transmission log of data corresponding to the provision record is not included in the acquired log, it is determined that there is no consistency; When a reception log of data corresponding to the acquired record is not included in the acquired log, it is determined that there is no consistency. The information processing device according to any one of claims 1 to 12.

14. The processing unit determines that there is no consistency when a provision record corresponding to the data transmission log is not included in the acquired record. The information processing device according to any one of claims 1 to 13.

15. The record regarding the consent includes at least one of a record of consent to storage and a record of consent to provision; The processing unit includes: When a receipt log of consent corresponding to the storage consent is not included in the acquired log, it is determined that there is no consistency; When the acquired records do not include a record of the withdrawal of the consent to storage and the acquired logs do not include a receipt log of consent corresponding to the consent to provision, it is determined that there is no consistency. The information processing device according to any one of claims 1 to 14.

16. The processing unit determines that there is no consistency when one of a record of the indirectly acquired consent, the directly acquired consent, and the provision consent corresponding to the consent reception log is not included in the acquired record. The information processing device according to any one of claims 1 to 15.

17. the log maintained in the second storage system includes a result of an authentication process for the relevant person performed by a device that accepts consent to the processing by the relevant person of the data, performs an authentication process for the relevant person, and provides a record of the consent to the first storage system if the authentication process is successful; The record regarding the consent includes at least one of a record of consent to storage and a record of consent to provision; The processing unit includes: If there is no log of authentication success corresponding to the record of the storage agreement, it is determined that there is no consistency; When the acquired records do not include a record of the withdrawal of consent to storage and there is no log of successful authentication corresponding to the record of consent to provision, it is determined that there is no consistency. The information processing device according to any one of claims 1 to 16.

18. Retrieving the records from a first storage system that holds at least one of records regarding processing of data and records regarding consent to processing of data; Retrieving the log from a second storage system that maintains a log of actions taken in connection with the transaction and / or the consent; Verifying the consistency of the acquired records based on the acquired logs; The record relating to the process is a record of a process involving writing, reading, or deleting data, determining that there is no consistency when a log of writing, reading, or deleting the data corresponding to the record related to the process is not included in the acquired log; A computer-implemented information processing method.

19. Retrieving the records from a first storage system that holds at least one of records regarding processing of data and records regarding consent to processing of data; retrieving said log from a second storage system that maintains a log of actions taken in connection with said transaction and / or said consent; verifying consistency of the acquired record based on the acquired log; Run the following on your computer: The record relating to the process is a record of a process involving writing, reading, or deleting data, The step of verifying the consistency includes determining that the consistency is not present when a log of writing, reading, or deleting the data corresponding to the record related to the process is not included in the acquired log. Computer program.

Images