WO2023132049A1 - 個人情報制御方法、情報処理装置、及び個人情報制御プログラム - Google Patents

個人情報制御方法、情報処理装置、及び個人情報制御プログラム Download PDF

Info

Publication number
WO2023132049A1
WO2023132049A1 PCT/JP2022/000326 JP2022000326W WO2023132049A1 WO 2023132049 A1 WO2023132049 A1 WO 2023132049A1 JP 2022000326 W JP2022000326 W JP 2022000326W WO 2023132049 A1 WO2023132049 A1 WO 2023132049A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
attribute
personal information
personal
disclosure
Prior art date
Application number
PCT/JP2022/000326
Other languages
English (en)
French (fr)
Inventor
陸大 小嶋
秀暢 小栗
孝一 矢崎
大 山本
和明 二村
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2022/000326 priority Critical patent/WO2023132049A1/ja
Publication of WO2023132049A1 publication Critical patent/WO2023132049A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules

Definitions

  • the present invention relates to personal information control technology.
  • Society 5.0 is a human-centered society that achieves both economic development and the resolution of social issues through a system that highly integrates cyberspace (virtual space) and physical space (real space).
  • cyberspace virtual space
  • physical space real space
  • IdP Identity Provider
  • the IdP can obtain information including the personal information held by the user and the services used by the user, It poses serious privacy risks.
  • Personal information includes information indicating user attributes.
  • DID Decentralized Identity
  • VCs Verifiable Credentials
  • the DID document referenced by the DID contains information about the public key, and the VCs contain personal credential information whose signature can be verified with that public key. Credential information is an example of personal information.
  • DID documents are immutable and highly resistant to tampering by being stored in a distributed system such as blockchain.
  • ION Identity Overlay Network
  • ION Identity Overlay Network
  • Patent Document 1 In relation to cyberspace, a method of generating a trustworthy community in a secure communication system is known (see Patent Document 1, for example). Bloom filters and cuckoo filters, which are probabilistic data structures, are also known (see, for example, Non-Patent Document 3 and Non-Patent Document 4).
  • the above-mentioned VCs are exchanged among three parties: the issuer (VCs Issuer), the owner (VCs Holder), and the verifier (VCs Verifier).
  • the issuer issues the VC to the owner, and the verifier verifies the VC signature provided by the owner to confirm the validity of the VC.
  • the use of VC is based on the premise that the owner actively provides his/her own credential information to the verifier, so the owner himself/herself selects the VC to be provided.
  • the operation of selecting VCs may become an obstacle.
  • the present invention aims to control the disclosure of personal information that indicates that the owner has specific attributes.
  • the attribute management information includes a plurality of attribute information, and the attribute range indicated by one attribute information among the plurality of attribute information is the attribute range indicated by attribute information higher than the attribute information. It has a hierarchical structure contained in
  • the computer accepts a disclosure request requesting disclosure of personal information that indicates that the personal information owner has a specific attribute.
  • the computer determines whether or not the first attribute indicated by the first attribute information and the second attribute indicated by the second attribute information higher than the first attribute information correspond to specific attributes. judgment processing is performed.
  • the first attribute information corresponds to one or more pieces of personal information held by the personal information owner.
  • the computer selects one or a plurality of pieces of personal information as personal information to be disclosed based on the result of the determination process.
  • FIG. 3 illustrates the generation and storage of VCs;
  • FIG. 13 illustrates verification of VCs;
  • 1 is a functional configuration diagram of a smartphone;
  • FIG. 10 is a diagram showing the procedure for generating and storing VC;
  • FIG. 10 is a diagram showing a procedure for verifying VC;
  • FIG. 4 is a functional configuration diagram of a smartphone of a comparative example;
  • FIG. 10 is a diagram showing a procedure for policy setting and VC verification in a comparative example; It is a figure which shows operation
  • 1 is a functional configuration diagram of an information processing apparatus according to an embodiment;
  • FIG. It is a flow chart of personal information control processing.
  • 1 is a configuration diagram of an information processing system;
  • FIG. 3 is a functional configuration diagram of an issuer device;
  • FIG. FIG. 10 is a diagram showing an attribute tree;
  • FIG. 10 is a diagram showing tagged VC generation processing;
  • FIG. 13 illustrates tagged VCs; It is a figure which shows the process which produces
  • FIG. 10 is a diagram illustrating a process of synthesizing two Bloom filters;
  • FIG. 10 is a diagram showing processing for adding a new node;
  • FIG. 10 illustrates a verification policy;
  • 1 is a functional block diagram of an owner device;
  • FIG. It is a figure which shows determination processing.
  • It is a figure which shows the determination process of CHK(p) 0.
  • FIG. 4 is a flowchart of VC issuing processing; 10 is a flowchart of tagged VC generation processing; 10 is a flowchart of VC provision processing; 10 is a flowchart (part 1) of VP generation processing; FIG. 11 is a flowchart (part 2) of VP generation processing; FIG. 2 is a hardware configuration diagram of an information processing apparatus; FIG.
  • Figure 1 shows an example of VC generation and storage.
  • the issuer 101 is the personnel department of X company
  • the owner 102 is employee A of X company
  • the verifier 103 is employee B of Y company who has concluded a contract with X company.
  • the issuer 101 issues A's employee ID card VC111 to the owner 102, and the verifier 103 verifies the employee ID card VC111 provided by the owner.
  • the employee ID card VC 111 is generated and stored according to the following procedure.
  • the owner 102 requests the issuer 101 to issue a VC.
  • the owner 102 requests issuance of VC by reading a two-dimensional code for issuing VC using, for example, a smartphone.
  • (P2) Issuer 101 generates a private key and a public key corresponding to owner 102 .
  • the issuer 101 issues the DID document 112 containing the DID and public key, and registers it in the Verifiable Data Registry 104, which is a registry that cannot be falsified.
  • a blockchain network for example, is used as the verifiable data registry 104 .
  • DID documents 112 can be retrieved by anyone using the corresponding DID.
  • the issuer 101 generates an employee ID card VC 111 and issues it to the owner 102.
  • the employee ID card VC 111 includes Claim, DID, and signature.
  • Claim includes the information that "A is an employee of Company X," and DID represents the DID included in DID document 112 .
  • a signature is an electronic signature for Claim and DID and is generated using a private key.
  • the owner 102 saves the employee ID card VC 111 in the Credential Repository.
  • the credential information repository for example, the internal storage of the smart phone is used.
  • Fig. 2 shows an example of VC verification. Verification of the employee ID card VC 111 in FIG. 1 is performed in the following procedure.
  • the owner 102 obtains a VC presentation request from the verifier 103.
  • the owner 102 acquires the VC presentation request by reading the two-dimensional code for request acquisition using, for example, a smartphone.
  • the owner 102 selects an employee ID card VC 111 from among multiple VCs stored in the credential information repository and provides it to the verifier 103 as a verifiable presentation (VP) 211.
  • VP verifiable presentation
  • the verifier 103 uses the DID included in the employee ID card VC111 in the VP211 to refer to the DID document 112 in the verifiable data registry 104 to obtain the public key.
  • the verifier 103 verifies the signature included in the employee ID card VC111 using the public key, and confirms the legitimacy of the employee ID card VC111. Verifier 103 then provides a predetermined service to owner 102 .
  • FIG. 3 shows a functional configuration example of the smartphone held by the owner 102.
  • a smartphone 301 of FIG. 3 includes a registration unit 311 , a storage unit 312 and a provision unit 313 .
  • VC321 corresponds to employee ID card VC111 in FIG. 1
  • VP325 corresponds to VP211 in FIG.
  • FIG. 4 shows an example of a VC generation and storage procedure using the smartphone 301 of FIG.
  • the generation and storage of the VC321 are performed in the following procedure.
  • the registration unit 311 requests the issuer 101 to issue a VC.
  • the issuer 101 generates an employee ID card VC 111 for the owner 102.
  • the issuer 101 transmits the employee ID card VC111 of the owner 102 to the smartphone 301 as the VC321, and the registration unit 311 receives the VC321.
  • the registration unit 311 requests the owner 102 to confirm the registration of the VC 321 by displaying the registration confirmation screen 331 including the VC 321 .
  • the registration unit 311 instructs the storage unit 312 to store the VC 321.
  • the storage unit 312 stores the VC 321 in the internal storage and outputs a list of stored VCs to the registration unit 311.
  • the list of saved VCs includes VC321-VC323.
  • the registration unit 311 displays a list of saved VCs.
  • FIG. 5 shows an example of a VC verification procedure using the smartphone 301 of FIG. Verification of the VC 321 is performed in the following procedure.
  • (P41) Owner 102 notifies verifier 103 that he is employee A of company X and requests verification of VC.
  • the verifier 103 transmits a credential query (CQ) 324 to the smartphone 301 as a VC presentation request.
  • CQ credential query
  • the providing unit 313 requests the storage unit 312 for the VC related to the CQ324.
  • the storage unit 312 displays a transmission confirmation screen 332 including a list of VCs related to the CQ324.
  • the list of VCs associated with CQ324 includes VC321-VC323.
  • the owner 102 selects the VC 321 from among the VCs displayed on the transmission confirmation screen 332.
  • the storage unit 312 outputs the VC 321 to the provision unit 313.
  • the providing unit 313 converts the VC321 to the VP325 and transmits a response including the VP325 to the verifier 103.
  • the verifier 103 acquires the VC321 from the VP325 and verifies the VC321.
  • the verifier 103 provides the smartphone 301 with a predetermined service.
  • the selection operation of the owner 102 in the procedure (P45) can be executed relatively quickly. be done.
  • the work of the owner 102 or verifier 103 may become an obstacle.
  • the verifier 103 wants to confirm whether the document received from the owner 102 is really a document issued by the owner 102, the verifier 103 separately uses contact means such as e-mail and telephone. , requests the owner 102 to present the employee ID card VC. In this case, the task of requesting the owner 102 to present the employee ID card VC becomes an obstacle.
  • a comparative example is explained as a simple solution to remove these obstacles.
  • a policy indicating VCs to be presented in response to a VC presentation request received by the owner 102 is set in the smartphone 301 in advance.
  • FIG. 6 shows a functional configuration example of the smartphone 301 of the comparative example.
  • a smartphone 301 in FIG. 6 has the same configuration as the smartphone 301 in FIG. 3 .
  • the policy 602 is information indicating which VC should be presented to each CQ among the multiple VCs stored in the smartphone 301 .
  • the policy 602 is described in an if-then format, and includes information indicating, for example, "present an employee ID card VC when requested to present a VC indicating that the employee is an employee".
  • FIG. 7 shows an example of the procedure for setting the policy 602 and verifying the VC 321 in the comparative example.
  • the setting of the policy 602 and the verification of the VC 321 are performed in the following procedure.
  • the storage unit 312 displays a policy setting screen 601 including a list of stored VCs.
  • the owner 102 sets the policy 602 for each displayed VC, and the provider 313 assigns the policy 602 to each VC.
  • Verifier 103 notifies owner 102 that it will verify the VC indicating that owner 102 is employee A of X company.
  • the verifier 103 transmits CQ324 to the smartphone 301 as a VC presentation request.
  • the provision unit 313 requests the storage unit 312 for the VC to be presented to the CQ 324.
  • the storage unit 312 outputs the VC 321 to the provision unit 313 according to the policy 602.
  • the providing unit 313 converts the VC321 to the VP325 and transmits a response including the VP325 to the verifier 103.
  • the verifier 103 acquires the VC321 from the VP325 and verifies the VC321.
  • the verifier 103 provides the smartphone 301 with a predetermined service.
  • the owner 102 sets a policy 602 corresponding to all CQs. This increases the workload of the owner 102 .
  • VC provision failure indicates that the smart phone 301 fails to select a VC even though it holds a valid VC for the CQ.
  • Leakage of VC indicates that the smart phone 301 provides VC for CQ from an inappropriate verifier.
  • FIG. 8 shows an operation example of the smartphone 301 of the comparative example.
  • FIG. 8(a) shows an example of normal operation.
  • the verifier server 801 transmits to the smart phone 301 a CQ stating, "Please show that you are an employee of Company F.”
  • the smart phone 301 transmits a VP 811 including information on the employee ID card VC to the verifier server 801 as a response.
  • FIG. 8(b) shows an example of an operation in which VC provision failure occurs.
  • the verifier server 802 transmits to the smart phone 301 a CQ stating "Please show that you are an office worker.”
  • Company X's employee ID card VC is a valid VC for CQ.
  • the smart phone 301 fails to select a VC because it does not hold a direct VC indicating that it is a company employee.
  • the smart phone 301 then sends a response including an error “no suitable VP found” to the verifier server 802 .
  • the verifier server 802 will experience a processing load such as retransmission of the CQ.
  • FIG. 8(c) shows an example of an operation in which VC leakage occurs.
  • the verifier server 803 which attempts to illegally acquire the personal information of the owner 102, transmits to the smart phone 301 a CQ stating "Please present your medical history.”
  • the smart phone 301 sends a VP 812 including the VC related to the anamnestic history to the verifier server 803 as a response.
  • FIG. 9 shows a functional configuration example of the information processing device (computer) of the embodiment.
  • An information processing apparatus 901 in FIG. 9 includes a reception unit 911 , a determination unit 912 and a selection unit 913 .
  • FIG. 10 is a flowchart showing an example of personal information control processing performed by the information processing device 901 of FIG.
  • the reception unit 911 receives a disclosure request requesting disclosure of personal information indicating that the personal information owner has a specific attribute (step 1001).
  • the determination unit 912 determines that the first attribute indicated by the first attribute information and the second attribute indicated by the second attribute information higher than the first attribute information correspond to specific attributes in the attribute management information. Determination processing is performed to determine whether or not (step 1002).
  • the attribute management information has a hierarchical structure in which a range of attributes indicated by one piece of attribute information among the plurality of pieces of attribute information is included in a range of attributes indicated by attribute information higher than the attribute information.
  • the first attribute information corresponds to one or more pieces of personal information held by the personal information owner.
  • the selection unit 913 selects one or a plurality of pieces of personal information as personal information to be disclosed based on the result of the determination process (step 1003).
  • the information processing device 901 of FIG. 9 it is possible to control disclosure of personal information indicating that the owner has a specific attribute.
  • FIG. 11 shows a configuration example of an information processing system including the information processing device 901 of FIG.
  • the information processing system of FIG. 11 includes owner device 1101 , issuer device 1102 , verifier device 1103 , and verifiable data registry 1104 .
  • Owner device 1101 corresponds to information processing device 901 in FIG.
  • the owner device 1101 is the owner's information processing device that owns the VC.
  • the owner device 1101 may be a mobile terminal device such as a smart phone, tablet, or notebook PC (Personal Computer).
  • VC includes information such as employee ID card, certificate of enrollment, graduation certificate, vaccination certificate, driver's license, qualification certificate, learning history, training completion certificate, birth certificate, etc.
  • VC corresponds to personal information
  • owner corresponds to the owner of personal information.
  • the issuer device 1102 is the information processing device of the issuer that issues the VC
  • the verifier device 1103 is the information processing device of the verifier that verifies the VC.
  • Issuer device 1102 and verifier device 1103 may be servers or PCs.
  • a verifier is an example of a personal information requester.
  • the verifiable data registry 1104 is a tamper-proof storage system. Verifiable data registry 1104 may be a blockchain network.
  • Owner device 1101 , issuer device 1102 , verifier device 1103 , and verifiable data registry 1104 can communicate with each other via communication network 1105 .
  • the communication network 1105 is, for example, a WAN (Wide Area Network).
  • Communication network 1105 may include a wireless communication network.
  • the verifier device 1103 when the information processing system is applied to an entrance/exit gate, the verifier device 1103 includes a communication device provided at the entrance/exit gate.
  • the owner is the user who passes through the entrance/exit gate, and the owner device 1101 is the owner's portable terminal device.
  • the owner can pass through the entrance/exit gate by providing the employee ID card VC or the like to the verifier device 1103 using the owner device 1101 .
  • FIG. 12 shows a functional configuration example of the issuer device 1102 of FIG. Issuer device 1102 of FIG.
  • the communication unit 1211 communicates with the owner device 1101 and the verifiable data registry 1104 via the communication network 1105 .
  • the storage unit 1214 stores an owner attribute tree 1221 and a verification policy 1222.
  • the attribute tree 1221 is a multi-tree data structure and includes multiple nodes having a hierarchical structure.
  • the attribute tree 1221 corresponds to attribute management information and each node corresponds to attribute information.
  • the verification policy 1222 is an example of disclosure condition information.
  • FIG. 13 shows an example of the attribute tree 1221 of FIG.
  • the attribute tree 1221 in FIG. 13 includes nodes 1301-1306.
  • Node 1301 is the parent node of node 1302
  • node 1302 is the parent node of nodes 1303 and 1304
  • node 1304 is the parent node of nodes 1305 and 1306 .
  • Arrows pointing from child nodes to parent nodes represent edges.
  • Each node includes id, name, bf, and parent_id as elements.
  • id represents the identification information of the node
  • name represents the unique name of the attribute represented by the node.
  • bf represents the bloom filter of the node and parent_id represents the id of the parent node.
  • Bloom filter is an example of a data structure that can quickly retrieve elements from a set and calculate the union of multiple sets. Bloom filters are probabilistic data structures, so they can give false positives, but they never give false negatives. A false positive is when an element that is not in the set is determined to be in the set, and a false negative is when an element in the set is determined not to be in the set. Represents an event that is
  • the bf contained in a node contains the name information of that node and the name information of each higher-level node that can be reached by tracing edges from that node. Therefore, bf indicates that attribute tree 1221 contains those nodes. bf is an example of control information.
  • the id of the node 1301 is "t4asdf"
  • the name is "Employee”
  • the bf is "0b0010101".
  • "0b” is a prefix representing a binary number. Since node 1301 is the root node, parent_id is empty.
  • the id of the node 1302 is "sfe13f", the name is “Belonging to Company F”, the bf is “0b0011101", and the parent_id is "t4asdf".
  • a node 1301 is a higher-level node that can be reached from the node 1302 by following an edge.
  • Nodes 1301 and 1302 are higher nodes that can be reached from the node 1304 by tracing edges.
  • Nodes 1301 , 1302 , and 1304 can be reached from the node 1306 by tracing edges.
  • the range of attributes indicated by the name of the parent node is wider than the range of attributes indicated by the name of the child node. Therefore, the attribute range indicated by the node name is included in the attribute range indicated by the name of each higher-level node that can be reached by following the edge from the node.
  • the node 1301 attribute "company employee” includes the node 1302 attribute "belonging to company F".
  • the attribute of the node 1302 “F company affiliation” includes the attribute of the node 1304 “laboratory affiliation”.
  • the attribute of node 1304 “laboratory affiliation” includes the attribute of “labor union member” of node 1305 and the attribute of “position” of node 1306 .
  • a “title” may be, for example, “project manager”.
  • FIG. 14 shows an example of tagged VC generation processing performed by the registration unit 1212 of FIG.
  • the registration unit 1212 Upon receiving a VC creation request from the owner device 1101, the registration unit 1212 generates a private key and a public key corresponding to the owner. Then, the registration unit 1212 generates a DID document including the DID and public key, and transmits it to the verifiable data registry 1104 via the communication unit 1211 . Verifiable data registry 1104 stores received DID documents.
  • the registration unit 1212 generates a VC 1401 containing Claim and DID, and a signature generated using the private key. Then, the registration unit 1212 extracts the attribute name from the claim in the VC 1401, searches the attribute tree 1221 for the extracted name, and identifies the node containing the name.
  • the registration unit 1212 adds a new node indicating that name to the attribute tree 1221.
  • the position of the new node within the attribute tree 1221 is specified by the publisher, for example.
  • the registration unit 1212 generates a URL (Uniform Resource Locator) that includes the id of the specified node or the added node and that allows the owner device 1101 to refer to that node. Then, the registration unit 1212 adds the generated URL as a tag to the VC 1401 to generate the tagged VC 1223 and stores it in the storage unit 1214 . The attributes of the VC 1401 are thereby registered in the attribute tree 1221 .
  • a URL Uniform Resource Locator
  • the registration unit 1212 transmits the generated tagged VC 1223 to the owner device 1101 via the communication unit 1211 .
  • FIG. 15 shows an example of tagged VC 1223 in FIG.
  • Attribute tree 1501, VC 1502, and tagged VC 1503 correspond to attribute tree 1221, VC 1401, and tagged VC 1223, respectively.
  • the attribute tree 1501 includes nodes 1301 to 1304 in FIG. 13, and Claim in the VC 1502 includes "Affiliated to Research Institute of Company F" as an attribute name.
  • the registration unit 1212 performs a character string analysis on "Affiliated to Research Institute of Company F" and searches the attribute tree 1501 to identify a node 1304 including "Affiliated to Research Institute” among "Affiliated to Research Institute of Company F”. . Then, the registration unit 1212 generates a tagged VC 1503 by adding a URL including the id of the node 1304 to the VC 1502 as a tag 1511 .
  • the owner device 110 uses a REST API (Representational State Transfer Application Programming Interface) GET request to request information on the node 1304 indicated by the URL from the issuer device 1102.
  • the control unit 1213 acquires information on the node 1304 from the attribute tree 1501 and transmits it to the owner device 1101 via the communication unit 1211 .
  • the owner device 1101 can acquire the information of the node 1304 in JSON (JavaScript (registered trademark) Object Notation).
  • the registration unit 1212 When adding a new node indicating the name of an attribute extracted from the VC 1401 to the attribute tree 1221, the registration unit 1212 generates id, name, bf, and parent_id of the new node. Of these, the name of the extracted attribute is used as name, and the id of the parent node of the new node is used as parent_id.
  • bf is generated from bf of the parent node and name of the new node.
  • the registration unit 1212 converts the name information of the new node into a Bloom filter to be registered. Then, the registration unit 1212 generates a synthesized Bloom filter by synthesizing the Bloom filter to be registered and the bf of the parent node, and uses the synthesized Bloom filter as the bf of the new node.
  • the registration unit 1212 initializes BF by setting m bit values BF[i] to logical values “0”.
  • the registration unit 1212 generates a Bloom filter to be registered by changing BF[H1(x)] to BF[Hk(x)] from logical values "0" to logical values "1".
  • FIG. 16 shows an example of processing for generating a Bloom filter to be registered.
  • FIG. 17 shows an example of processing for synthesizing two Bloom filters.
  • m 16.
  • the registration unit 1212 receives the Bloom filter 1701 and the Bloom filter 1702 as inputs and performs an OR operation for each bit to generate a synthetic Bloom filter 1703 .
  • the bit position of "1" included in the synthesis Bloom filter 1703 corresponds to the bit position of "1" included in the Bloom filter 1701 or Bloom filter 1702. Therefore, information on both the Bloom filter 1701 and the Bloom filter 1702 is registered in the synthesis Bloom filter 1703 .
  • the registration unit 1212 can synthesize the Bloom filter to be registered and the bf of the parent node by performing the same OR operation as in FIG.
  • the registration unit 1212 changes the parent_id of the child node N2 to the id of the new node. Then, the registration unit 1212 changes the bf of the child node N2 to a synthesized Bloom filter obtained by synthesizing the bf and the Bloom filter to be registered. Furthermore, the registration unit 1212 changes the bf of each lower-level node reachable from the child node N2 by tracing the edge to a synthesized Bloom filter obtained by synthesizing the bf and the Bloom filter to be registered.
  • FIG. 18 shows an example of processing for adding a new node.
  • node 1304 is added as a new node in the state where attribute tree 1501 in FIG. 15 includes nodes 1301 to 1303 .
  • a Bloom filter 1801 represents the bf of the node 1302
  • a Bloom filter 1802 represents a registered Bloom filter of the node 1304
  • a Bloom filter 1803 represents the bf of the node 1304 .
  • the registration unit 1212 converts the character string “laboratory affiliation” indicated by the name of the node 1304 into the Bloom filter 1802 .
  • the registration unit 1212 synthesizes the Bloom filter 1801 and the Bloom filter 1802 to generate the Bloom filter 1803 and registers the Bloom filter 1803 as bf of the node 1304 .
  • FIG. 19 shows an example of the verification policy 1222 of FIG.
  • the verification policy 1222 of FIG. 19 includes each verifier's name and credentials.
  • name represents the name of the verifier to whom personal information is disclosed, and credentials represents one or more disclosure target attributes.
  • the name of the verifier is an example of identification information of the personal information disclosure party. Below, the name of the verifier may be referred to as the verifier name.
  • the verifier indicated by the name included in the verification policy 1222 is a valid verifier confirmed by the issuer. Each verifier is authorized to use a VC containing each attribute indicated by the corresponding credentials.
  • Control unit 1213 acquires verification policy 1222 from storage unit 1214 in response to a request from owner device 1101 and transmits it to owner device 1101 via communication unit 1211 .
  • credentials in FIG. 19 include English attributes such as “company”, they may include Japanese attributes such as "company employee”.
  • FIG. 20 shows a functional configuration example of the owner device 1101 of FIG. Owner device 1101 in FIG.
  • the receiving unit 2013, the determining unit 2014, and the selecting unit 2015 correspond to the receiving unit 911, the determining unit 912, and the selecting unit 913 in FIG. 9, respectively.
  • the communication unit 2011 communicates with the issuer device 1102 and the verifier device 1103 via the communication network 1105 .
  • the communication unit 2011 receives the tagged VC 1223 from the issuer device 1102.
  • the registration unit 2012 requests the owner to confirm the registration of the VC by displaying a registration confirmation screen including the VC in the received tagged VC 1223 .
  • the owner enters a response permitting registration of the VC on the registration confirmation screen, and the registration unit 2012 stores the tagged VC 1223 in the storage unit 2016.
  • the storage unit 2016 stores one or more tagged VCs 1223 .
  • the VCs contained in tagged VCs 1223 correspond to personal information held by the owner.
  • Verifier device 1103 sends CQ2021 to owner device 1101 and requests the VP most suitable for CQ2021.
  • CQ 2021 includes the verifier name and attributes specified by the verifier.
  • CQ2021 corresponds to a disclosure request requesting disclosure of personal information indicating that the owner has a specific attribute.
  • the verifier name is an example of identification information of the personal information requester, and the attribute specified by the verifier is an example of a specific attribute.
  • the communication unit 2011 receives the CQ 2021 from the verifier device 1103 , and the reception unit 2013 receives the received CQ 2021 and stores it in the storage unit 2016 .
  • the determination unit 2014 performs determination processing to determine whether the attribute indicated by the name included in the specific node in the attribute tree 1221 corresponds to the attribute included in the CQ 2021.
  • Specific nodes include nodes corresponding to VCs included in tagged VCs 1223 and each higher-level node reachable from that node by following an edge.
  • the node corresponding to the VC included in the tagged VC 1223 corresponds to the first attribute information, and the attribute indicated by the name included in that node corresponds to the first attribute.
  • Each upper node that can be reached by tracing an edge from that node corresponds to the second attribute information, and the attribute indicated by the name included in each upper node corresponds to the second attribute.
  • the selection unit 2015 selects one or a plurality of tagged VCs 1223 as VCs to be disclosed based on the result of the determination process.
  • FIG. 21 shows an example of determination processing performed by the determination unit 2014 in FIG.
  • the determination unit 2014 requests the verification policy 1222 from the issuer device 1102 via the communication unit 2011 , acquires the verification policy 1222 from the issuer device 1102 , and stores it in the storage unit 2016 .
  • the determination unit 2014 extracts the verifier name and attributes from the CQ2021.
  • the determination unit 2014 uses the verification policy 1222 to check the validity of the verifier. If the verifier name extracted from the CQ 2021 is included in the verification policy 1222, the determination unit 2014 determines that the verifier is valid.
  • the determination unit 2014 determines that the verifier is unauthorized. In this case, the determination unit 2014 outputs an error message "The verifier who requested the VC is unauthorized" and recommends normal verification to the owner. In normal verification, the owner selects a VC and transmits it to the verifier device 1103 according to the procedure shown in FIG. 5, thereby actively requesting the verifier to verify the VC. If the verifier is unauthorized, the determination unit 2014 does not perform determination processing.
  • a VC is provided to a verifier not intended by the owner. can be prevented.
  • the determination unit 2014 uses the verification policy 1222 to check the validity of the requested attributes. If the attribute extracted from the CQ 2021 is included in the credentials corresponding to the verifier name extracted from the CQ 2021 in the verification policy 1222, the determination unit 2014 determines that the requested attribute is valid.
  • the determination unit 2014 determines that the requested attribute is not subject to verification. judge. In this case, the determination unit 2014 outputs an error message "the requested attribute is not subject to verification" and recommends normal verification to the owner. If the requested attribute is not subject to verification, the determination unit 2014 does not perform determination processing.
  • control unit 1213 updates the verification policy 1222 based on the owner's instructions each time normal verification is performed.
  • the owner device 1101 displays an inquiry screen including an inquiry "Do you want to automatically execute this verification from now on?” when normal verification is performed. Then, when the consent of the owner is obtained, the owner device 1101 transmits the verifier and VC information to the issuer device 1102 .
  • the control unit 1213 updates the verification policy 1222 by registering the received verifier and VC information in the verification policy 1222 . This keeps the verification policy 1222 always up-to-date.
  • the determination unit 2014 performs determination processing.
  • the determination unit 2014 refers to nodes included in the attribute tree 1221 using tags included in the tagged VC 1223 . Specifically, determination unit 2014 requests issuer device 1102 via communication unit 2011 for bf of a node indicated by a tag included in tagged VC 1223 . Then, determination unit 2014 acquires bf from issuer device 1102 and stores the acquired bf in storage unit 2016 as BF 2022 .
  • the issuer device 1102 store the attribute tree 1221 and the owner device 1101 store the tagged VC 1223
  • the information contained in each node of the attribute tree 1221 can be flexibly changed. For example, even if the data structure or specification of bf included in the node is changed, there is no need to change the tag included in the tagged VC 1223, and the owner device 1101 uses the tag to store the changed bf can be referred to.
  • Tagged VCs 2101-1 to Tagged VCs 2101-N (N is an integer equal to or greater than 1) in FIG. represents the BF 2022 obtained using the tags contained in .
  • the determination unit 2014 searches the attribute tree 1221 for the attribute extracted from the CQ 2021 using BF2102-1 to BF2102-N. First, the determination unit 2014 calculates hash values H1(y) to Hk(y) of the attribute character string y extracted from the CQ 2021 .
  • the determination unit 2014 calculates a determination value CHK(p) for each BF 2102-p using the following equation.
  • Equation (1) represents the logical product of k BFs[Hj(y)].
  • True indicates that the attribute indicated by name included in a specific node in the attribute tree 1221 corresponds to the attribute included in the CQ 2021.
  • False indicates that the attribute indicated by name included in the specific node in the attribute tree 1221 does not correspond to the attribute included in the CQ 2021.
  • the selection unit 2015 selects the tagged VC 2101-p corresponding to that BF 2102-p. If True is output for two or more BFs 2102-p, the selection unit 2015 includes tags that refer to the highest nodes among the two or more tagged VCs 2101-p corresponding to those BFs 2102-p. Select tagged VC2101-p.
  • the selection unit 2015 extracts the VCs included in the selected tagged VCs 2101-p as VCs to be disclosed, converts the extracted VCs into VPs 2023, and stores them in the storage unit 2016. The selection unit 2015 then transmits a response including the VP 2023 to the verifier device 1103 via the communication unit 2011 .
  • the selection unit 2015 outputs an error message “No VC indicating the requested attribute was found” and returns a normal message to the owner. Recommend verification.
  • determination section 2014 calculates CHK(p) for BF 2102-p using equation (1).
  • determination section 2014 calculates CHK(p) for BF 2102-p using equation (1).
  • the attribute tree 1221 in FIG. 13 is referenced and the owner has only tagged VC 2101-1 will be described.
  • the attribute indicated by the VC of tagged VC 2101-1 is "belonging to F company”
  • the attribute included in CQ 2021 is "employee”. Therefore, the range of attributes contained in CQ 2021 is wider than the range of attributes indicated by the VCs of tagged VC 2101-1.
  • the tag of the tagged VC 2101-1 is used to obtain the bf of the node 1302 including "belonging to F company". Since bf of node 1302 contains the information of “employee” of node 1301, which is the parent node, CHK(p) calculated using the hash value of “employee” extracted from CQ 2021 is 1. Become. Therefore, the tagged VC 2101-1 is selected, and the disclosed VC is extracted from the tagged VC 2101-1.
  • the attribute tree 1221 in FIG. 13 is referenced and the owner owns tagged VCs 2101-1 to 2101-3 will be described.
  • the attribute indicated by the VC of the tagged VC 2101-1 is "laboratory affiliation”
  • the attribute indicated by the tagged VC 2101-2 is "post”
  • the VC of the tagged VC 2101-1 is The attribute shown is "unionist”.
  • the attribute included in the CQ2021 is "laboratory affiliation”.
  • the tag of the tagged VC 2101-1 is used to obtain the bf of the node 1304 that includes "Affiliated to Laboratory”. Since the bf of the node 1304 includes the information of “laboratory affiliation”, CHK(p) calculated using the hash value of “laboratory affiliation” extracted from CQ 2021 is 1.
  • the tag of the tagged VC 2101-2 is used to obtain the bf of the node 1306, which includes "post". Since the bf of the node 1306 contains the information of the “laboratory affiliation” of the parent node 1304, CHK(p) calculated using the hash value of the “laboratory affiliation” extracted from the CQ 2021 is 1.
  • the bf of the node 1305 containing "unionist” is obtained. Since the bf of the node 1305 contains the information of the “laboratory affiliation” of the parent node 1304, CHK(p) calculated using the hash value of the “laboratory affiliation” extracted from the CQ 2021 is 1.
  • the tagged VC 2101-1 including the tag referring to the highest node 1304 is selected from the tagged VC 2101-1 to the tagged VC 2101-3, and the VC to be disclosed is extracted from the tagged VC 2101-1. be.
  • the VC indicating specific personal information such as "position” or “labor union member” can be prevented from being provided to the verifier. This makes it possible to properly protect the owner's privacy.
  • the verifier device 1103 acquires the VC from the VP 2023 received from the owner device 1101 and verifies the acquired VC. If the verification succeeds, the verifier device 1103 notifies the owner device 1101 of the verification success and provides a predetermined service to the owner device 1101 or the owner. For example, when the information processing system is applied to an entrance/exit gate, the verifier device 1103 controls opening of the entrance/exit gate.
  • the issuer device 1102 automatically registers the attributes of the VC in the attribute tree 1221 when issuing the VC. Therefore, the owner does not need to create a policy indicating which VCs should be presented to CQ2021. Since the attributes of the VC owned by the owner are registered without omission in the attribute tree 1221, it is possible to prevent search failure due to omission of attribute registration.
  • owner device 1101 when owner device 1101 receives CQ 2021 from verifier device 1103 , it automatically selects a VC corresponding to CQ 2021 while referring to attribute tree 1221 and transmits it to verifier device 1103 .
  • the disclosure of VCs held by owners can be automatically controlled.
  • the VC corresponding to CQ2021 can be promptly provided to the verifier device 1103. For example, even when the owner passes through the entrance/exit gate, the employee ID card VC or the like is promptly provided to the verifier device 1103, so the employee ID card VC or the like can be verified at high speed. Also, even when the verifier requests the owner to present the VC, the VC can be quickly obtained from the owner device 1101 without using communication means such as e-mail and telephone.
  • FIG. 24 is a flowchart showing an example of VC issuing processing in the information processing system of FIG. First, registration unit 2012 of owner device 1101 transmits a VC creation request to issuer device 1102 via communication unit 2011 (step 2401).
  • the communication unit 1211 of the issuer device 1102 receives the VC creation request from the owner device 1101 (step 2402). Next, registration unit 1212 generates a private key and a public key corresponding to the owner (step 2403). Then, the registration unit 1212 generates a DID document including the DID and public key (step 2404), and transmits it to the verifiable data registry 1104 via the communication unit 1211 (step 2405).
  • the verifiable data registry 1104 After confirming the received DID document, the verifiable data registry 1104 stores it in the verifiable data registry 1104 (step 2406).
  • the registration unit 1212 generates a VC including Claim, DID, and a signature generated using the private key (step 2407). Then, registration unit 1212 generates tagged VC 1223 including the generated VC (step 2408), and transmits the generated tagged VC 1223 to owner device 1101 via communication unit 1211 (step 2409). .
  • the communication unit 2011 of the owner device 1101 receives the tagged VC 1223 from the issuer device 1102, and the registration unit 2012 stores the received tagged VC 1223 in the storage unit 2016 (step 2410).
  • FIG. 25 is a flow chart showing an example of tagged VC generation processing in step 2408 of FIG.
  • the registration unit 1212 acquires the attribute character string x from Claim in the VC (step 2501), and acquires the attribute tree 1221 from the storage unit 1214 (step 2502).
  • the registration unit 1212 searches for the character string x from the attribute tree 1221 (step 2503) and checks whether any node of the attribute tree 1221 contains the character string x (step 2504).
  • the registration unit 1212 adds a new node indicating the character string x to the attribute tree 1221 (step 2505). Then, the registration unit 1212 generates a URL including the id of the added node as a tag (step 2507).
  • the registration unit 1212 acquires id from that node (step 2506). Then, the registration unit 1212 generates a URL including the acquired id as a tag (step 2507).
  • the registration unit 1212 generates a tagged VC 1223 by adding the generated tag to the VC (step 2508).
  • FIG. 26 is a flowchart showing an example of VC provision processing in the information processing system of FIG. First, verifier device 1103 transmits CQ2021 to owner device 1101 (step 2601).
  • the communication unit 2011 of the owner device 1101 receives the CQ2021 from the verifier device 1103, and the reception unit 2013 receives the received CQ2021 (step 2602). Then, determination unit 2014 requests verification policy 1222 from issuer device 1102 via communication unit 2011 (step 2603).
  • the control unit 1213 of the issuer device 1102 transmits the verification policy 1222 to the owner device 1101 via the communication unit 1211 (step 2604).
  • the determination unit 2014 and selection unit 2015 of the owner device 1101 use the verification policy 1222 to perform VP generation processing for generating the VP 2023 (step 2605). Then, the selection unit 2015 checks whether or not the VP 2023 has been generated by the VP generation process (step 2606). If VP 2023 has not been generated (step 2606, NO), owner device 1101 terminates processing.
  • the selection unit 2015 transmits a response including the VP 2023 to the verifier device 1103 via the communication unit 2011 (step 2607).
  • FIGS. 27A and 27B are flowcharts showing an example of VP generation processing in step 2605 of FIG.
  • the determination unit 2014 acquires the verification policy 1222 received from the issuer device 1102 (step 2701).
  • the determination unit 2014 acquires the verifier name from the CQ 2021 (step 2702), and checks whether the acquired verifier name is included in the verification policy 1222 (step 2703).
  • the determination unit 2014 If the verifier name is not included in the verification policy 1222 (step 2703, NO), the determination unit 2014 outputs an error message "the verifier who requested the VC is unauthorized" (step 2704). The determination unit 2014 then recommends normal verification to the owner (step 2705). In this case, the VP 2023 is not generated by the VP generation process.
  • the determination unit 2014 acquires attributes from the CQ 2021 (step 2706).
  • the determination unit 2014 generates a Bloom filter BF from each character string included in the credentials corresponding to the verifier name acquired from the CQ 2021 in the verification policy 1222 (step 2707).
  • the determination unit 2014 converts each character string into BF in the same manner as in the Bloom filter to be registered.
  • the determination unit 2014 calculates hash values H1(y) to Hk(y) of the attribute character string y obtained from the CQ 2021, and calculates the determination value CHK for each BF.
  • CHK is calculated from Hj(y) and BF in the same manner as CHK(p) in equation (1). Then, the determination unit 2014 checks the determination result indicated by CHK for each BF (step 2708).
  • the determination unit 2014 If the determination result indicated by CHK for all BFs is False (step 2708, NO), the determination unit 2014 outputs an error message "the requested attribute is not subject to verification" (step 2709). The determination unit 2014 then recommends normal verification to the owner (step 2710). In this case, the VP 2023 is not generated by the VP generation process.
  • the determination unit 2014 determines whether the determination result indicated by CHK for any BF is True (step 2708, YES). If the determination result indicated by CHK for any BF is True (step 2708, YES), the determination unit 2014 generates an empty VC list (step 2711).
  • the determination unit 2014 selects any tagged VC 2101-p from the tagged VCs 2101-1 to 2101-N owned by the owner, and acquires the tag from the tagged VC 2101-p. (step 2712).
  • the determination unit 2014 requests the issuer device 1102 for the bf of the node indicated by the tag included in the tagged VC 2101-p via the communication unit 2011, and acquires the BF 2102-p from the issuer device 1102. (Step 2713).
  • the determination unit 2014 uses the hash value Hj(y) of the character string y of the attribute obtained from the CQ 2021 to calculate the determination value CHK(p) for the BF 2102-p according to Equation (1). Then, determination section 2014 outputs the determination result indicated by CHK(p) to selection section 2015 .
  • the selection unit 2015 checks the determination result output from the determination unit 2014 (step 2714). If the determination result is True (step 2714, YES), the selection unit 2015 adds the VC included in the tagged VC 2101-p to the VC list (step 2715).
  • the determination unit 2014 checks whether or not all tagged VCs 2101-p have been selected (step 2716). If unselected tagged VCs 2101-p remain (step 2716, NO), owner device 1101 repeats the processing from step 2712 onwards for the next tagged VC 2101-p.
  • step 2714 the owner device 1101 performs the processing from step 2716 onwards. Then, if all tagged VCs 2101-p have been selected (step 2716, YES), the selection unit 2015 checks whether the VC list is empty (step 2717).
  • the selection unit 2015 If the VC list is empty (step 2717, YES), the selection unit 2015 outputs an error message "No VC showing the requested attribute was found" (step 2718). The selection unit 2015 then recommends normal verification to the owner (step 2719). In this case, the VP 2023 is not generated by the VP generation process.
  • the selection unit 2015 checks whether two or more VCs are included in the VC list (step 2720).
  • the selection unit 2015 selects the VC corresponding to the highest node among those VCs (step 2721).
  • the VC corresponding to the top-level node is the VC that was included in tagged VC 2101-p that contains the tag that references the top-level node.
  • the selection unit 2015 selects that VC (step 2722).
  • the selection unit 2015 generates the VP2023 by converting the selected VC into the VP2023 (step 2723).
  • the VP 2023 is generated by the VP generation process.
  • the configuration of the information processing device 901 in FIG. 9 is merely an example, and some components may be omitted or changed according to the usage or conditions of the information processing device 901.
  • the configuration of the information processing system in FIG. 11 is merely an example, and some components may be omitted or changed according to the usage or conditions of the information processing system.
  • the configurations of the issuer device 1102 in FIG. 12 and the owner device 1101 in FIG. 20 are merely examples, and some components may be omitted or changed according to the use or conditions of the information processing system.
  • FIGS. 10 and 24 to 27B are merely examples, and part of the processing may be omitted or changed according to the configuration or conditions of the information processing device 901 or the information processing system.
  • the generation and storage of VC shown in Figures 1 and 4 are only examples, and the generation and storage of VC varies depending on the usage or conditions of the VC.
  • the VC verification shown in FIGS. 2 and 5 is only an example, and the VC verification will vary depending on the VC's application or conditions.
  • the configuration of the smartphone 301 in FIGS. 3 and 6 is merely an example, and some components may be omitted or changed according to the usage or conditions of the smartphone 301.
  • the policy setting and VC verification procedure shown in FIG. 7 is merely an example, and the policy setting and VC verification procedure varies depending on the use or conditions of the VC.
  • the operation of the smartphone 301 shown in FIG. 8 is merely an example, and the operation of the smartphone 301 changes depending on the application or conditions of the VC.
  • the attribute tree 1221 shown in FIG. 13 is merely an example, and attribute management information of another data structure may be used.
  • the information held by each node of the attribute tree 1221 is merely an example, and part of the information may be omitted or changed according to the configuration or conditions of the information processing system.
  • the Bloom filter instead of the Bloom filter, other control information such as a Cuckoo filter may be used.
  • the number and attributes of nodes included in the attribute tree 1221 change according to the usage or conditions of the VC.
  • the tagged VC generation process shown in FIGS. 14 and 15 is merely an example, and the issuer device 1102 may generate the tagged VC 1223 by another method.
  • the Bloom filters shown in FIGS. 16-18, 22, and 23 are only examples, and Bloom filters will vary depending on the application or conditions of the VC.
  • the verification policy 1222 shown in FIG. 19 is merely an example, and other forms of disclosure condition information may be used.
  • the determination process shown in FIG. 21 is merely an example, and the owner device 1101 may perform the determination process using another method.
  • Formula (1) is merely an example, and determining section 2014 may calculate determination value CHK(p) using another formula.
  • FIG. 28 shows a hardware configuration example of an information processing device used as the information processing device 901 in FIG. 9, the issuer device 1102 in FIG. 12, and the owner device 1101 in FIG.
  • the information processing device of FIG. 28 includes a CPU (Central Processing Unit) 2801, a memory 2802, an input device 2803, an output device 2804, an auxiliary storage device 2805, a media drive device 2806, and a network connection device 2807. These components are hardware and are interconnected by bus 2808 .
  • CPU Central Processing Unit
  • the memory 2802 is, for example, a ROM (Read Only Memory), a RAM (Random Access Memory), a semiconductor memory such as a flash memory, and stores programs and data used for processing.
  • Memory 2802 may operate as storage unit 1214 in FIG. 12 or storage unit 2016 in FIG.
  • the CPU 2801 (processor) operates as the receiving unit 911, the determining unit 912, and the selecting unit 913 of FIG. 9 by executing programs using the memory 2802, for example.
  • the CPU 2801 also operates as the registration unit 1212 and the control unit 1213 of FIG. 12 by executing programs using the memory 2802 .
  • the CPU 2801 also operates as the registration unit 2012, reception unit 2013, determination unit 2014, and selection unit 2015 in FIG. 20 by executing programs using the memory 2802. FIG.
  • the input device 2803 is, for example, a keyboard, pointing device, etc., and is used for inputting instructions or information from the user or operator.
  • the output device 2804 is, for example, a display device, a printer, a speaker, etc., and is used for outputting an inquiry to the user or operator or a processing result.
  • the auxiliary storage device 2805 is, for example, a magnetic disk device, an optical disk device, a magneto-optical disk device, a tape device, or the like.
  • the auxiliary storage device 2805 may be a hard disk drive or SSD (Solid State Drive). If the information processing device is a smart phone, the auxiliary storage device 2805 may be flash memory.
  • the information processing device can store programs and data in the auxiliary storage device 2805 and load them into the memory 2802 for use.
  • the auxiliary storage device 2805 may operate as the storage unit 1214 in FIG. 12 or the storage unit 2016 in FIG.
  • a medium drive device 2806 drives a portable recording medium 2809 and accesses its recorded contents.
  • a portable recording medium 2809 is a memory device, flexible disk, optical disk, magneto-optical disk, or the like.
  • the portable recording medium 2809 may be a CD-ROM (Compact Disk Read Only Memory), a DVD (Digital Versatile Disk), a USB (Universal Serial Bus) memory, or the like.
  • a user or operator can store programs and data in the portable recording medium 2809 and load them into the memory 2802 for use.
  • a computer-readable recording medium for storing programs and data used for processing may be a physical (non-temporary) recording medium such as memory 2802, auxiliary storage device 2805, or portable recording medium 2809. is a medium.
  • a network connection device 2807 is a communication interface circuit that is connected to the communication network 1105 and performs data conversion associated with communication.
  • the information processing device can receive programs and data from an external device via the network connection device 2807 and load them into the memory 2802 for use.
  • the network connection device 2807 may operate as the communication unit 1211 in FIG. 12 or the communication unit 2011 in FIG.
  • the information processing device does not need to include all the components shown in FIG. 28, and it is possible to omit or change some of the components depending on the application or conditions.
  • the input device 2803 and the output device 2804 may be omitted if no user or operator interface is required. If the information processing device does not use the portable recording medium 2809, the medium drive device 2806 may be omitted.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

属性管理情報は、複数の属性情報を含み、かつ、複数の属性情報のうち１つの属性情報が示す属性の範囲が、その属性情報よりも上位の属性情報が示す属性の範囲に含まれる階層構造を有する。コンピュータは、個人情報所有者が特定の属性を有することを示す個人情報の開示を要求する開示要求を受け付ける。コンピュータは、属性管理情報において、第１属性情報が示す第１属性と、第１属性情報よりも上位の第２属性情報が示す第２属性とが、特定の属性に対応するか否かを判定する判定処理を行う。第１属性情報は、個人情報所有者が保有する１つ又は複数の個人情報それぞれに対応する。コンピュータは、判定処理の結果に基づいて、１つ又は複数の個人情報の何れかを開示対象の個人情報として選択する。

Description

個人情報制御方法、情報処理装置、及び個人情報制御プログラム
　本発明は、個人情報制御技術に関する。
　近年、政府から国内外に向けて、Society5.0の実現が提唱されている。Society5.0は、サイバー空間（仮想空間）とフィジカル空間（現実空間）を高度に融合させたシステムにより、経済発展と社会的課題の解決を両立する、人間中心の社会である。Society5.0の根幹となる法人認証及びトラストサービス基盤の実現のため、人、組織、及び物の認証とデータの完全性とを確保する技術のニーズが年々高まっている。
　特に、サイバー空間において、ユーザを識別するためのデジタルアイデンティティをどのように扱うかは、Society5.0の実現に向けた重要な課題の１つである。単一のＩｄＰ（Identity　Provider）がユーザＩＤを仲介して複数のサービスを提供する場合、ＩｄＰは、ユーザが保有する個人情報とユーザが利用したサービスとを含む情報を取得することが可能となり、深刻なプライバシーリスクに繋がる。個人情報は、ユーザの属性を示す情報を含む。
　これに対して、ＩｄＰ等の中央集権的なシステムを介することなく、個人が保有する個人情報を自らの意思で制御できるようにするべきであるという考え方が存在する（例えば、非特許文献１を参照）。この考え方は、自己主権型アイデンティティ（Self-Sovereign　Identity，ＳＳＩ）と呼ばれ、近年、欧米を中心として活発に議論されている。
　現在、ＳＳＩを実現できるデジタルアイデンティティ発行の具体的な方法の標準化が、Ｗ３Ｃ（World　Wide　Web　Consortium）等の国際団体によって進められている。標準化が進められている方法は、分散型アイデンティティ（Decentralized　Identity，ＤＩＤ）と、検証可能な資格情報（Verifiable　Credentials，ＶＣｓ）である（例えば、非特許文献１及び非特許文献２を参照）。
　ＤＩＤによって参照されるＤＩＤ文書には、公開鍵に関する情報が含まれており、ＶＣｓには、その公開鍵で署名検証が可能な個人の資格情報が含まれている。資格情報は、個人情報の一例である。ＤＩＤ文書は、ブロックチェーン等の分散型システム内に保管されることによって、不変性及び高い改ざん耐性を有する。一例として、Microsoft社が提供するＩＤ基盤であるＩＯＮ（Identity　Overlay　Network）では、Bitcoinネットワークのセカンドレイヤが利用されている。
　サイバー空間に関連して、セキュアな通信システムにおいて信頼できるコミュニティを生成する方法が知られている（例えば、特許文献１を参照）。確率的データ構造であるブルームフィルタ及びカッコウフィルタも知られている（例えば、非特許文献３及び非特許文献４を参照）。
米国特許第６１３４３２７号明細書
"デジタルアイデンティティ～自己主権型/分散型アイデンティティ～"、株式会社野村総合研究所、NRIセキュアテクノロジーズ株式会社、株式会社ジェーシービー、２０１９年１１月、［online］、［令和３年１２月６日検索］、インターネット＜ＵＲＬ：https://www.nri.com/-/media/Corporate/jp/Files/PDF/service/ips/technology_1.pdf＞ "Verifiable　Credentialsとは？｜LasTrust｜note"、LasTrust、２０２０年１０月１９日、［online］、［令和３年１２月６日検索］、インターネット＜ＵＲＬ：https://note.com/lastrust/n/nb40b2f8a3ba2＞ A.　Abdennebi　et　al.,　"A　Bloom　Filter　Survey:　Variants　for　Different　Domain　Applications",　arXiv:2106.12189v1,　June　23,　2021,　pages　1－30 B.　Fan　et　al.,　"Cuckoo　Filter:　Practically　Better　Than　Bloom",　CoNEXT　'14:　Proceedings　of　the　10th　ACM　International　on　Conference　on　Emerging　Networking　Experiments　and　Technologies,　December　2014,　pages　75－88
　上述したＶＣは、発行者（VCs　Issuer）、所有者（VCs　Holder）、及び検証者（VCs　Verifier）の三者の間でやり取りされる。発行者は、所有者に対してＶＣを発行し、検証者は、所有者から提供されたＶＣの署名を検証することで、そのＶＣの正当性を確認する。
　現在、ＶＣを活用する多数のアプリケーションが提案されている。例えば、大学の在学証明又は卒業証明のデジタル証明書の場合、大学の事務局が在学証明又は卒業証明のＶＣを発行し、学生がＶＣを所有し、企業の面接担当者がＶＣを検証する。ワクチン接種証明のデジタル証明書の場合、医療機関がワクチン接種証明のＶＣを発行し、ワクチン接種者がＶＣを所有し、税関がＶＣを検証する。
　一方、ＶＣの活用は、所有者が能動的に自身の資格情報を検証者に提供することを前提としているため、所有者自身が提供対象のＶＣを選択する操作を行う。しかしながら、ＶＣの用途によっては、ＶＣを選択する操作が障害となることがある。
　なお、かかる問題は、所有者がＶＣを提供する場合に限らず、所有者が様々な個人情報を開示する場合において生ずるものである。
　１つの側面において、本発明は、所有者が特定の属性を有することを示す個人情報の開示を制御することを目的とする。
　１つの案では、属性管理情報は、複数の属性情報を含み、かつ、複数の属性情報のうち１つの属性情報が示す属性の範囲が、その属性情報よりも上位の属性情報が示す属性の範囲に含まれる階層構造を有する。
　コンピュータは、個人情報所有者が特定の属性を有することを示す個人情報の開示を要求する開示要求を受け付ける。コンピュータは、属性管理情報において、第１属性情報が示す第１属性と、第１属性情報よりも上位の第２属性情報が示す第２属性とが、特定の属性に対応するか否かを判定する判定処理を行う。第１属性情報は、個人情報所有者が保有する１つ又は複数の個人情報それぞれに対応する。コンピュータは、判定処理の結果に基づいて、１つ又は複数の個人情報の何れかを開示対象の個人情報として選択する。
　１つの側面によれば、所有者が特定の属性を有することを示す個人情報の開示を制御することができる。
ＶＣの生成及び保管を示す図である。 ＶＣの検証を示す図である。 スマートフォンの機能的構成図である。 ＶＣの生成及び保管の手順を示す図である。 ＶＣの検証の手順を示す図である。 比較例のスマートフォンの機能的構成図である。 比較例におけるポリシーの設定及びＶＣの検証の手順を示す図である。 比較例のスマートフォンの動作を示す図である。 実施形態の情報処理装置の機能的構成図である。 個人情報制御処理のフローチャートである。 情報処理システムの構成図である。 発行者装置の機能的構成図である。 属性ツリーを示す図である。 タグ付きＶＣ生成処理を示す図である。 タグ付きＶＣを示す図である。 登録対象ブルームフィルタを生成する処理を示す図である。 ２つのブルームフィルタを合成する処理を示す図である。 新規ノードを追加する処理を示す図である。 検証ポリシーを示す図である。 所有者装置の機能的構成図である。 判定処理を示す図である。 ＣＨＫ（ｐ）＝１の判定処理を示す図である。 ＣＨＫ（ｐ）＝０の判定処理を示す図である。 ＶＣ発行処理のフローチャートである。 タグ付きＶＣ生成処理のフローチャートである。 ＶＣ提供処理のフローチャートである。 ＶＰ生成処理のフローチャート（その１）である。 ＶＰ生成処理のフローチャート（その２）である。 情報処理装置のハードウェア構成図である。
　以下、図面を参照しながら、実施形態を詳細に説明する。
　図１は、ＶＣの生成及び保管の例を示している。発行者１０１は、Ｘ社の人事部であり、所有者１０２は、Ｘ社の社員Ａであり、検証者１０３は、Ｘ社と契約を締結しているＹ社の社員Ｂである。
　発行者１０１は、所有者１０２に対して、Ａの社員証ＶＣ１１１を発行し、検証者１０３は、所有者から提供された社員証ＶＣ１１１を検証する。この場合、社員証ＶＣ１１１の生成及び保管は、以下のような手順で行われる。
　（Ｐ１）所有者１０２は、発行者１０１に対してＶＣの発行を要求する。所有者１０２は、例えば、スマートフォンを用いて、ＶＣ発行用の２次元コードを読み取ることで、ＶＣの発行を要求する。
　（Ｐ２）発行者１０１は、所有者１０２に対応する秘密鍵及び公開鍵を生成する。
　（Ｐ３）発行者１０１は、ＤＩＤ及び公開鍵を含むＤＩＤ文書１１２を発行し、改ざん不可能なレジストリである検証可能データレジストリ（Verifiable　Data　Registry）１０４に登録する。検証可能データレジストリ１０４としては、例えば、ブロックチェーンネットワークが用いられる。ＤＩＤ文書１１２は、対応するＤＩＤを用いて誰でも検索することができる。
　（Ｐ４）発行者１０１は、社員証ＶＣ１１１を生成し、所有者１０２に対して発行する。社員証ＶＣ１１１は、Ｃｌａｉｍ（主張）、ＤＩＤ、及び署名を含む。Ｃｌａｉｍは、「ＡはＸ社の従業員である」という情報を含み、ＤＩＤは、ＤＩＤ文書１１２に含まれるＤＩＤを表す。署名は、Ｃｌａｉｍ及びＤＩＤに対する電子署名であり、秘密鍵を用いて生成される。
　（Ｐ５）所有者１０２は、資格情報リポジトリ（Credential　Repository）に社員証ＶＣ１１１を保存する。資格情報リポジトリとしては、例えば、スマートフォンの内部ストレージが用いられる。
　図２は、ＶＣの検証の例を示している。図１の社員証ＶＣ１１１の検証は、以下のような手順で行われる。
　（Ｐ１１）所有者１０２は、検証者１０３からＶＣ提示要求を取得する。所有者１０２は、例えば、スマートフォンを用いて、要求取得用の２次元コードを読み取ることで、ＶＣ提示要求を取得する。
　（Ｐ１２）所有者１０２は、資格情報リポジトリに保存されている複数のＶＣの中から社員証ＶＣ１１１を選択し、検証可能なプレゼンテーション（Verifiable　Presentation，ＶＰ）２１１として検証者１０３に提供する。
　（Ｐ１３）検証者１０３は、ＶＰ２１１内の社員証ＶＣ１１１に含まれているＤＩＤを用いて、検証可能データレジストリ１０４内のＤＩＤ文書１１２を参照し、公開鍵を取得する。
　（Ｐ１４）検証者１０３は、公開鍵を用いて、社員証ＶＣ１１１に含まれる署名を検証し、社員証ＶＣ１１１の正当性を確認する。その後、検証者１０３は、所有者１０２に対して所定のサービスを提供する。
　図３は、所有者１０２が保持するスマートフォンの機能的構成例を示している。図３のスマートフォン３０１は、登録部３１１、保存部３１２、及び提供部３１３を含む。ＶＣ３２１は、図１の社員証ＶＣ１１１に対応し、ＶＰ３２５は、図２のＶＰ２１１に対応する。
　図４は、図３のスマートフォン３０１を用いたＶＣの生成及び保管の手順の例を示している。ＶＣ３２１の生成及び保管は、以下のような手順で行われる。
　（Ｐ２１）所有者１０２は、ＷｅｂフォームからＶＣの発行を申請する。
　（Ｐ２２）登録部３１１は、発行者１０１に対してＶＣの発行を要求する。
　（Ｐ２３）発行者１０１は、所有者１０２に対する本人認証を行う。
　（Ｐ２４）発行者１０１は、所有者１０２の社員証ＶＣ１１１を生成する。
　（Ｐ２５）発行者１０１は、所有者１０２の社員証ＶＣ１１１を、ＶＣ３２１としてスマートフォン３０１へ送信し、登録部３１１は、ＶＣ３２１を受信する。
　（Ｐ２６）登録部３１１は、ＶＣ３２１を含む登録確認画面３３１を表示することで、所有者１０２に対してＶＣ３２１の登録確認を要求する。
　（Ｐ２７）所有者１０２は、ＶＣ３２１の登録を許可する応答を登録確認画面３３１に入力する。
　（Ｐ２８）登録部３１１は、保存部３１２に対してＶＣ３２１の保存を指示する。
　（Ｐ２９）保存部３１２は、ＶＣ３２１を内部ストレージに保存し、保存済みＶＣのリストを登録部３１１へ出力する。保存済みＶＣのリストは、ＶＣ３２１～ＶＣ３２３を含む。
　（Ｐ３０）登録部３１１は、保存済みＶＣのリストを表示する。
　図５は、図３のスマートフォン３０１を用いたＶＣの検証の手順の例を示している。ＶＣ３２１の検証は、以下のような手順で行われる。
　（Ｐ４１）所有者１０２は、Ｘ社の社員Ａであることを検証者１０３に通知して、ＶＣの検証を要求する。
　（Ｐ４２）検証者１０３は、資格情報クエリ（credentialQuery，ＣＱ）３２４を、ＶＣ提示要求としてスマートフォン３０１へ送信する。
　（Ｐ４３）提供部３１３は、ＣＱ３２４に関連するＶＣを保存部３１２に要求する。
　（Ｐ４４）保存部３１２は、ＣＱ３２４に関連するＶＣのリストを含む送信確認画面３３２を表示する。ＣＱ３２４に関連するＶＣのリストは、ＶＣ３２１～ＶＣ３２３を含む。
　（Ｐ４５）所有者１０２は、送信確認画面３３２に表示されたＶＣの中からＶＣ３２１を選択する。
　（Ｐ４６）保存部３１２は、ＶＣ３２１を提供部３１３へ出力する。
　（Ｐ４７）提供部３１３は、ＶＣ３２１をＶＰ３２５に変換し、ＶＰ３２５を含む応答を検証者１０３へ送信する。
　（Ｐ４８）検証者１０３は、ＶＰ３２５からＶＣ３２１を取得し、ＶＣ３２１を検証する。
　（Ｐ４９）検証者１０３は、検証成功を所有者１０２に通知する。
　（Ｐ５０）検証者１０３は、スマートフォン３０１に対して所定のサービスを提供する。
　このように、所有者１０２が検証者１０３に対して能動的にＶＣの検証を要求して、サービスの提供を受ける場合、手順（Ｐ４５）における所有者１０２の選択操作は、比較的速やかに実行される。一方、以下のようなケースにおいては、所有者１０２又は検証者１０３の作業が障害となることがある。
（１）高速な検証が行われるケース
　社員証ＶＣを用いて入退場ゲートを通過する場合のように、社員であることを示すＶＣの検証を高速に行うことが望ましい場合、所有者１０２が画面上でＶＣを選択する作業が障害となる。
（２）検証者１０３が能動的に検証を行うケース
　検証者１０３が所有者１０２から受領した文書が、本当に所有者１０２から発行された文書であるか否かを確認したい場合、検証者１０３は、別途、電子メール、電話等の連絡手段を用いて、所有者１０２に社員証ＶＣの提示を要求する。この場合、所有者１０２に社員証ＶＣの提示を要求する作業が障害となる。
　これらの障害を取り除く単純な解決策として、比較例を説明する。比較例では、所有者１０２が受け取ったＶＣ提示要求に対して提示すべきＶＣを示すポリシーが、事前にスマートフォン３０１に設定される。
　図６は、比較例のスマートフォン３０１の機能的構成例を示している。図６のスマートフォン３０１は、図３のスマートフォン３０１と同様の構成を有する。
　ポリシー６０２は、スマートフォン３０１内に保存されている複数のＶＣのうち、各ＣＱに対して提示すべきＶＣを示す情報である。ポリシー６０２は、ｉｆ－ｔｈｅｎ形式で記述され、例えば、「社員であることを示すＶＣの提示を要求された場合、社員証ＶＣを提示する」ことを示す情報を含む。
　図７は、比較例におけるポリシー６０２の設定及びＶＣ３２１の検証の手順の例を示している。ポリシー６０２の設定及びＶＣ３２１の検証は、以下のような手順で行われる。
　（Ｐ６１）保存部３１２は、保存済みＶＣのリストを含むポリシー設定画面６０１を表示する。
　（Ｐ６２）所有者１０２は、表示された各ＶＣに対するポリシー６０２を設定し、提供部３１３は、各ＶＣにポリシー６０２を付与する。
　（Ｐ６３）検証者１０３は、所有者１０２がＸ社の社員Ａであることを示すＶＣの検証を行うことを、所有者１０２に通知する。
　（Ｐ６４）検証者１０３は、ＣＱ３２４を、ＶＣ提示要求としてスマートフォン３０１へ送信する。
　（Ｐ６５）提供部３１３は、ＣＱ３２４に対して提示すべきＶＣを保存部３１２に要求する。
　（Ｐ６６）保存部３１２は、ポリシー６０２に従って、ＶＣ３２１を提供部３１３へ出力する。
　（Ｐ６７）提供部３１３は、ＶＣ３２１をＶＰ３２５に変換し、ＶＰ３２５を含む応答を検証者１０３へ送信する。
　（Ｐ６８）検証者１０３は、ＶＰ３２５からＶＣ３２１を取得し、ＶＣ３２１を検証する。
　（Ｐ６９）検証者１０３は、検証成功を所有者１０２に通知する。
　（Ｐ７０）検証者１０３は、スマートフォン３０１に対して所定のサービスを提供する。
　しかしながら、比較例では、複数のＣＱの発生が想定される場合、所有者１０２は、すべてのＣＱに対応するポリシー６０２を設定することになる。このため、所有者１０２の作業負荷が増大する。
　また、所有者１０２が意図しないＶＣの提供失敗又は漏洩が発生する可能性もある。ＶＣの提供失敗は、スマートフォン３０１が、ＣＱに対して有効なＶＣを保持しているにもかかわらず、そのＶＣの選択に失敗することを表す。ＶＣの漏洩は、不適切な検証者からのＣＱに対して、スマートフォン３０１がＶＣを提供してしまうことを表す。
　図８は、比較例のスマートフォン３０１の動作例を示している。図８（ａ）は、正常動作の例を示している。検証者サーバ８０１は、「Ｆ社の従業員であることを提示してください」というＣＱを、スマートフォン３０１へ送信する。スマートフォン３０１は、社員証ＶＣの情報を含むＶＰ８１１を、応答として検証者サーバ８０１へ送信する。
　図８（ｂ）は、ＶＣの提供失敗が発生する動作の例を示している。検証者サーバ８０２は、「会社員であることを提示してください」というＣＱを、スマートフォン３０１へ送信する。
　この場合、Ｘ社の社員証ＶＣは、ＣＱに対して有効なＶＣである。しかし、スマートフォン３０１は、会社員であることを示す直接的なＶＣを保持していないため、ＶＣの選択に失敗する。そして、スマートフォン３０１は、「適切なＶＰが見つかりませんでした」というエラーを含む応答を、検証者サーバ８０２へ送信する。
　このように、ポリシーの設定漏れによって、本来自動的に応答できるはずであったＣＱに対してＶＰが返信されない場合、検証者サーバ８０２において、ＣＱの再送等の処理負荷が発生する。
　図８（ｃ）は、ＶＣの漏洩が発生する動作の例を示している。所有者１０２の個人情報を不正に取得しようとする検証者サーバ８０３は、「既往歴を提示してください」というＣＱを、スマートフォン３０１へ送信する。スマートフォン３０１は、既往歴に関するＶＣを含むＶＰ８１２を、応答として検証者サーバ８０３へ送信する。
　このように、ポリシーの設定ミス等によって、悪意のある検証者サーバ８０３からのＣＱに対して自動的にＶＰが返信された場合、プライバシー漏洩等のリスクが生じる。
　図９は、実施形態の情報処理装置（コンピュータ）の機能的構成例を示している。図９の情報処理装置９０１は、受付部９１１、判定部９１２、及び選択部９１３を含む。
　図１０は、図９の情報処理装置９０１が行う個人情報制御処理の例を示すフローチャートである。まず、受付部９１１は、個人情報所有者が特定の属性を有することを示す個人情報の開示を要求する開示要求を受け付ける（ステップ１００１）。
　次に、判定部９１２は、属性管理情報において、第１属性情報が示す第１属性と、第１属性情報よりも上位の第２属性情報が示す第２属性とが、特定の属性に対応するか否かを判定する判定処理を行う（ステップ１００２）。
　属性管理情報は、複数の属性情報を含み、かつ、複数の属性情報のうち１つの属性情報が示す属性の範囲が、その属性情報よりも上位の属性情報が示す属性の範囲に含まれる階層構造を有する。第１属性情報は、個人情報所有者が保有する１つ又は複数の個人情報それぞれに対応する。
　次に、選択部９１３は、判定処理の結果に基づいて、１つ又は複数の個人情報の何れかを開示対象の個人情報として選択する（ステップ１００３）。
　図９の情報処理装置９０１によれば、所有者が特定の属性を有することを示す個人情報の開示を制御することができる。
　図１１は、図９の情報処理装置９０１を含む情報処理システムの構成例を示している。図１１の情報処理システムは、所有者装置１１０１、発行者装置１１０２、検証者装置１１０３、及び検証可能データレジストリ１１０４を含む。所有者装置１１０１は、図９の情報処理装置９０１に対応する。
　所有者装置１１０１は、ＶＣを保有する所有者の情報処理装置である。所有者装置１１０１は、スマートフォン、タブレット、ノート型ＰＣ（Personal　Computer）等の携帯端末装置であってもよい。
　ＶＣは、社員証、在学証明、卒業証明、ワクチン接種証明、運転免許証、有資格証明書、学習履歴、研修修了証、出生証明書等の情報を含む。ＶＣは、個人情報に対応し、所有者は、個人情報所有者に対応する。
　発行者装置１１０２は、ＶＣを発行する発行者の情報処理装置であり、検証者装置１１０３は、ＶＣを検証する検証者の情報処理装置である。発行者装置１１０２及び検証者装置１１０３は、サーバ又はＰＣであってもよい。検証者は、個人情報要求者の一例である。
　検証可能データレジストリ１１０４は、改ざん不可能な記憶システムである。検証可能データレジストリ１１０４は、ブロックチェーンネットワークであってもよい。
　所有者装置１１０１、発行者装置１１０２、検証者装置１１０３、及び検証可能データレジストリ１１０４は、通信ネットワーク１１０５を介して、互いに通信することができる。通信ネットワーク１１０５は、例えば、ＷＡＮ（Wide　Area　Network）である。通信ネットワーク１１０５は、無線通信ネットワークを含んでいてもよい。
　例えば、情報処理システムが入退場ゲートに適用される場合、検証者装置１１０３は、入退場ゲートに設けられた通信装置を含む。この場合、所有者は、入退場ゲートを通過するユーザであり、所有者装置１１０１は、所有者の携帯端末装置である。所有者は、所有者装置１１０１を用いて、社員証ＶＣ等を検証者装置１１０３に提供することで、入退場ゲートを通過することができる。
　図１２は、図１１の発行者装置１１０２の機能的構成例を示している。図１２の発行者装置１１０２は、通信部１２１１、登録部１２１２、制御部１２１３、及び記憶部１２１４を含む。
　通信部１２１１は、通信ネットワーク１１０５を介して、所有者装置１１０１及び検証可能データレジストリ１１０４と通信する。
　記憶部１２１４は、所有者の属性ツリー１２２１及び検証ポリシー１２２２を記憶する。属性ツリー１２２１は、多分木のデータ構造であり、階層構造を有する複数のノードを含む。属性ツリー１２２１は、属性管理情報に対応し、各ノードは、属性情報に対応する。検証ポリシー１２２２は、開示条件情報の一例である。
　図１３は、図１２の属性ツリー１２２１の例を示している。図１３の属性ツリー１２２１は、ノード１３０１～ノード１３０６を含む。ノード１３０１は、ノード１３０２の親ノードであり、ノード１３０２は、ノード１３０３及びノード１３０４の親ノードであり、ノード１３０４は、ノード１３０５及びノード１３０６の親ノードである。子ノードから親ノードへ向かう矢印は、エッジを表す。
　各ノードは、ｉｄ、ｎａｍｅ、ｂｆ、及びｐａｒｅｎｔ＿ｉｄを要素として含む。ｉｄは、ノードの識別情報を表し、ｎａｍｅは、ノードが表す属性の固有名称を表す。ｂｆは、ノードのブルームフィルタを表し、ｐａｒｅｎｔ＿ｉｄは、親ノードのｉｄを表す。
　ブルームフィルタは、集合から要素を高速に検索でき、かつ、複数の集合の和集合を計算できるデータ構造の一例である。ブルームフィルタは確率的データ構造であるため、偽陽性を示す可能性があるが、偽陰性を示すことはない。偽陽性は、集合に含まれていない要素が、その集合に含まれていると判定される事象を表し、偽陰性は、集合に含まれている要素が、その集合に含まれていないと判定される事象を表す。
　ノードに含まれるｂｆは、そのノードのｎａｍｅの情報と、そのノードからエッジを辿って到達可能な上位の各ノードのｎａｍｅの情報とを含む。したがって、ｂｆは、属性ツリー１２２１がそれらのノードを含むことを示している。ｂｆは、制御情報の一例である。
　例えば、ノード１３０１のｉｄは、“ｔ４ａｓｄｆ．．．”であり、ｎａｍｅは、“会社員”であり、ｂｆは、“０ｂ００１０１０１．．．”である。“０ｂ”は、２進数を表すプレフィックスである。ノード１３０１は、ルートノードであるため、ｐａｒｅｎｔ＿ｉｄは空である。
　ノード１３０２のｉｄは、“ｓｆｅ１３ｆ．．．”であり、ｎａｍｅは、“Ｆ社所属”であり、ｂｆは、“０ｂ００１１１０１．．．”であり、ｐａｒｅｎｔ＿ｉｄは、“ｔ４ａｓｄｆ．．．”である。
　ノード１３０２からエッジを辿って到達可能な上位のノードは、ノード１３０１である。ノード１３０４からエッジを辿って到達可能な上位のノードは、ノード１３０１及びノード１３０２である。ノード１３０６からエッジを辿って到達可能な上位のノードは、ノード１３０１、ノード１３０２、及びノード１３０４である。
　親ノードのｎａｍｅが示す属性の範囲は、子ノードのｎａｍｅが示す属性の範囲よりも広い。したがって、ノードのｎａｍｅが示す属性の範囲は、そのノードからエッジを辿って到達可能な上位の各ノードのｎａｍｅが示す属性の範囲に含まれる。
　例えば、ノード１３０１の“会社員”という属性は、ノード１３０２の“Ｆ社所属”という属性を含む。ノード１３０２の“Ｆ社所属”という属性は、ノード１３０４の“研究所所属”という属性を含む。ノード１３０４の“研究所所属”という属性は、ノード１３０５の“労働組合員”という属性と、ノード１３０６の“役職”という属性とを含む。“役職”は、例えば、“プロジェクトマネージャ”であってもよい。
　図１４は、図１３の登録部１２１２が行うタグ付きＶＣ生成処理の例を示している。所有者装置１１０１からＶＣ作成依頼を受信した場合、登録部１２１２は、所有者に対応する秘密鍵及び公開鍵を生成する。そして、登録部１２１２は、ＤＩＤ及び公開鍵を含むＤＩＤ文書を生成し、通信部１２１１を介して、検証可能データレジストリ１１０４へ送信する。検証可能データレジストリ１１０４は、受信したＤＩＤ文書を記憶する。
　次に、登録部１２１２は、Ｃｌａｉｍ及びＤＩＤと、秘密鍵を用いて生成された署名とを含む、ＶＣ１４０１を生成する。そして、登録部１２１２は、ＶＣ１４０１内のＣｌａｉｍから属性の名称を抽出し、抽出された名称を属性ツリー１２２１から検索して、その名称を含むノードを特定する。
　抽出された名称を含むノードが存在しない場合、登録部１２１２は、その名称を示す新規ノードを属性ツリー１２２１に追加する。属性ツリー１２２１内における新規ノードの位置は、例えば、発行者によって指定される。
　次に、登録部１２１２は、特定されたノード又は追加されたノードのｉｄを含み、かつ、所有者装置１１０１からそのノードを参照できるようなＵＲＬ（Uniform　Resource　Locator）を生成する。そして、登録部１２１２は、生成されたＵＲＬをタグとしてＶＣ１４０１に付加することで、タグ付きＶＣ１２２３を生成し、記憶部１２１４に格納する。これにより、ＶＣ１４０１の属性が属性ツリー１２２１に登録される。
　次に、登録部１２１２は、生成されたタグ付きＶＣ１２２３を、通信部１２１１を介して、所有者装置１１０１へ送信する。
　図１５は、図１４のタグ付きＶＣ１２２３の例を示している。属性ツリー１５０１、ＶＣ１５０２、及びタグ付きＶＣ１５０３は、属性ツリー１２２１、ＶＣ１４０１、及びタグ付きＶＣ１２２３にそれぞれ対応する。この例では、属性ツリー１５０１は、図１３のノード１３０１～ノード１３０４を含み、ＶＣ１５０２内のＣｌａｉｍは、属性の名称として“Ｆ社研究所所属”を含む。
　登録部１２１２は、“Ｆ社研究所所属”に対する文字列解析を行って、属性ツリー１５０１を検索することで、“Ｆ社研究所所属”のうち“研究所所属”を含むノード１３０４を特定する。そして、登録部１２１２は、ノード１３０４のｉｄを含むＵＲＬを、タグ１５１１としてＶＣ１５０２に付加することで、タグ付きＶＣ１５０３を生成する。タグ１５１１としては、例えば、“http://companyF.com/attribute_tree/id=as8rg5.../request”のようなＵＲＬが用いられる。
　所有者装置１１０１は、例えば、ＲＥＳＴ　ＡＰＩ（Representational　State　Transfer　Application　Programming　Interface）のＧＥＴリクエストを用いて、ＵＲＬが示すノード１３０４の情報を、発行者装置１１０２に対して要求する。制御部１２１３は、属性ツリー１５０１からノード１３０４の情報を取得し、通信部１２１１を介して、所有者装置１１０１へ送信する。これにより、所有者装置１１０１は、ノード１３０４の情報をＪＳＯＮ（JavaScript（登録商標）　Object　Notation）で取得することができる。
　ＶＣ１４０１から抽出された属性の名称を示す新規ノードを、属性ツリー１２２１に追加する場合、登録部１２１２は、新規ノードのｉｄ、ｎａｍｅ、ｂｆ、及びｐａｒｅｎｔ＿ｉｄを生成する。このうち、ｎａｍｅとしては、抽出された属性の名称が用いられ、ｐａｒｅｎｔ＿ｉｄとしては、新規ノードの親ノードのｉｄが用いられる。
　ｂｆは、親ノードのｂｆ及び新規ノードのｎａｍｅから生成される。登録部１２１２は、新規ノードのｎａｍｅの情報を、登録対象ブルームフィルタに変換する。そして、登録部１２１２は、登録対象ブルームフィルタと親ノードのｂｆとを合成することで、合成ブルームフィルタを生成し、合成ブルームフィルタを新規ノードのｂｆとして用いる。
　登録対象ブルームフィルタは、ｍビット（ｍは１以上の整数）のビット列ＢＦにより表され、ＢＦのｉ番目のビット値は、ＢＦ［ｉ］（ｉ＝０～ｍ－１）により表される。まず、登録部１２１２は、ｍ個のビット値ＢＦ［ｉ］を論理値“０”に設定することで、ＢＦを初期化する。
　次に、登録部１２１２は、ハッシュ関数Ｈ１～ハッシュ関数Ｈｋ（ｋは１以上の整数）を用いて、新規ノードのｎａｍｅの文字列ｘのハッシュ値Ｈ１（ｘ）～ハッシュ値Ｈｋ（ｘ）を計算する。Ｈｊ（ｘ）（ｊ＝１～ｋ）は、０～ｍ－１の何れかを示す整数である。
　次に、登録部１２１２は、ＢＦ［Ｈ１（ｘ）］～ＢＦ［Ｈｋ（ｘ）］を論理値“０”から論理値“１”に変更することで、登録対象ブルームフィルタを生成する。
　図１６は、登録対象ブルームフィルタを生成する処理の例を示している。この例では、ｍ＝１６、かつ、ｋ＝３である。登録部１２１２は、文字列ｘのハッシュ値を計算し、Ｈ１（ｘ）＝６、Ｈ２（ｘ）＝２、及びＨ３（ｘ）＝１３という計算結果を得る。そこで、登録部１２１２は、ＢＦ［２］、ＢＦ［６］、及びＢＦ［１３］を“０”から“１”に変更することで、登録対象ブルームフィルタ１６０１を生成する。
　図１７は、２つのブルームフィルタを合成する処理の例を示している。この例では、ｍ＝１６である。登録部１２１２は、ブルームフィルタ１７０１及びブルームフィルタ１７０２を入力として、ビット毎にＯＲ演算を行うことで、合成ブルームフィルタ１７０３を生成する。
　合成ブルームフィルタ１７０３に含まれる“１”のビット位置は、ブルームフィルタ１７０１又はブルームフィルタ１７０２に含まれる“１”のビット位置に対応している。したがって、合成ブルームフィルタ１７０３には、ブルームフィルタ１７０１及びブルームフィルタ１７０２の両方の情報が登録されている。
　登録部１２１２は、図１７と同様のＯＲ演算を行うことで、登録対象ブルームフィルタと親ノードのｂｆとを合成することができる。
　既に存在する親ノードＮ１と子ノードＮ２の間に新規ノードが挿入された場合、登録部１２１２は、子ノードＮ２のｐａｒｅｎｔ＿ｉｄを新規ノードのｉｄに変更する。そして、登録部１２１２は、子ノードＮ２のｂｆを、そのｂｆと登録対象ブルームフィルタとを合成した合成ブルームフィルタに変更する。さらに、登録部１２１２は、子ノードＮ２からエッジを辿って到達可能な下位の各ノードのｂｆを、そのｂｆと登録対象ブルームフィルタとを合成した合成ブルームフィルタに変更する。
　図１８は、新規ノードを追加する処理の例を示している。この例では、図１５の属性ツリー１５０１がノード１３０１～ノード１３０３を含んでいる状態において、ノード１３０４が新規ノードとして追加される。
　ブルームフィルタ１８０１は、ノード１３０２のｂｆを表し、ブルームフィルタ１８０２は、ノード１３０４の登録対象ブルームフィルタを表し、ブルームフィルタ１８０３は、ノード１３０４のｂｆを表す。
　登録部１２１２は、ノード１３０４のｎａｍｅが示す文字列“研究所所属”を、ブルームフィルタ１８０２に変換する。そして、登録部１２１２は、ブルームフィルタ１８０１及びブルームフィルタ１８０２を合成することで、ブルームフィルタ１８０３を生成し、ブルームフィルタ１８０３をノード１３０４のｂｆとして登録する。
　図１９は、図１２の検証ポリシー１２２２の例を示している。図１９の検証ポリシー１２２２は、各検証者のｎａｍｅ及びｃｒｅｄｅｎｔｉａｌｓを含む。ｎａｍｅは、個人情報開示先である検証者の名称を表し、ｃｒｅｄｅｎｔｉａｌｓは、１つ又は複数の開示対象属性を表す。検証者の名称は、個人情報開示先の識別情報の一例である。以下では、検証者の名称を検証者名と記載することがある。
　検証ポリシー１２２２に含まれるｎａｍｅが示す検証者は、発行者によって確認済みの正当な検証者である。各検証者に対して、対応するｃｒｅｄｅｎｔｉａｌｓが示す各属性を含むＶＣの利用が許可される。制御部１２１３は、所有者装置１１０１からの要求に応じて、記憶部１２１４から検証ポリシー１２２２を取得し、通信部１２１１を介して、所有者装置１１０１へ送信する。
　なお、図１９のｃｒｅｄｅｎｔｉａｌｓは、“ｃｏｍｐａｎｙ”等の英語の属性を含んでいるが、“会社員”等の日本語の属性を含んでいてもよい。
　図２０は、図１１の所有者装置１１０１の機能的構成例を示している。図２０の所有者装置１１０１は、通信部２０１１、登録部２０１２、受付部２０１３、判定部２０１４、選択部２０１５、及び記憶部２０１６を含む。受付部２０１３、判定部２０１４、及び選択部２０１５は、図９の受付部９１１、判定部９１２、及び選択部９１３にそれぞれ対応する。
　通信部２０１１は、通信ネットワーク１１０５を介して、発行者装置１１０２及び検証者装置１１０３と通信する。
　通信部２０１１は、発行者装置１１０２からタグ付きＶＣ１２２３を受信する。登録部２０１２は、受信したタグ付きＶＣ１２２３内のＶＣを含む登録確認画面を表示することで、所有者に対してＶＣの登録確認を要求する。
　所有者は、ＶＣの登録を許可する応答を登録確認画面に入力し、登録部２０１２は、タグ付きＶＣ１２２３を記憶部２０１６に格納する。記憶部２０１６は、１つ又は複数のタグ付きＶＣ１２２３を記憶する。タグ付きＶＣ１２２３に含まれるＶＣは、所有者が保有する個人情報に対応する。
　検証者装置１１０３は、ＣＱ２０２１を所有者装置１１０１へ送信し、ＣＱ２０２１に最も適したＶＰを要求する。ＣＱ２０２１は、検証者名と、検証者によって指定された属性とを含む。ＣＱ２０２１は、所有者が特定の属性を有することを示す個人情報の開示を要求する開示要求に対応する。検証者名は、個人情報要求者の識別情報の一例であり、検証者によって指定された属性は、特定の属性の一例である。
　通信部２０１１は、検証者装置１１０３からＣＱ２０２１を受信し、受付部２０１３は、受信したＣＱ２０２１を受け付けて、記憶部２０１６に格納する。
　判定部２０１４は、属性ツリー１２２１内の特定のノードに含まれるｎａｍｅが示す属性が、ＣＱ２０２１に含まれる属性に対応するか否かを判定する判定処理を行う。特定のノードは、タグ付きＶＣ１２２３に含まれるＶＣに対応するノードと、そのノードからエッジを辿って到達可能な上位の各ノードとを含む。
　タグ付きＶＣ１２２３に含まれるＶＣに対応するノードは、第１属性情報に対応し、そのノードに含まれるｎａｍｅが示す属性は、第１属性に対応する。そのノードからエッジを辿って到達可能な上位の各ノードは、第２属性情報に対応し、上位の各ノードに含まれるｎａｍｅが示す属性は、第２属性に対応する。
　選択部２０１５は、判定処理の結果に基づいて、１つ又は複数のタグ付きＶＣ１２２３の何れかを開示対象のＶＣとして選択する。
　図２１は、図２０の判定部２０１４が行う判定処理の例を示している。判定部２０１４は、通信部２０１１を介して、発行者装置１１０２に検証ポリシー１２２２を要求し、発行者装置１１０２から検証ポリシー１２２２を取得して、記憶部２０１６に格納する。
　次に、判定部２０１４は、ＣＱ２０２１から検証者名及び属性を抽出する。そして、判定部２０１４は、検証ポリシー１２２２を用いて、検証者の正当性をチェックする。ＣＱ２０２１から抽出された検証者名が検証ポリシー１２２２に含まれている場合、判定部２０１４は、検証者は正当であると判定する。
　一方、ＣＱ２０２１から抽出された検証者名が検証ポリシー１２２２に含まれていない場合、判定部２０１４は、検証者は非認可であると判定する。この場合、判定部２０１４は、「ＶＣを要求した検証者は非認可です」というエラーメッセージを出力し、所有者に対して通常の検証を推奨する。通常の検証では、図５に示した手順により、所有者がＶＣを選択して検証者装置１１０３に送信することで、検証者に対して能動的にＶＣの検証を要求する。検証者が非認可である場合、判定部２０１４は、判定処理を行わない。
　このように、情報漏えいに配慮して、発行者によって確認済みの正当な検証者の名称を検証ポリシー１２２２に登録しておくことで、所有者が意図しない検証者に対してＶＣが提供されることを防止できる。
　検証者が正当である場合、判定部２０１４は、検証ポリシー１２２２を用いて、要求された属性の正当性をチェックする。ＣＱ２０２１から抽出された属性が、検証ポリシー１２２２において、ＣＱ２０２１から抽出された検証者名に対応するｃｒｅｄｅｎｔｉａｌｓに含まれている場合、判定部２０１４は、要求された属性は正当であると判定する。
　一方、ＣＱ２０２１から抽出された属性が、検証ポリシー１２２２において、ＣＱ２０２１から抽出された検証者名に対応するｃｒｅｄｅｎｔｉａｌｓに含まれていない場合、判定部２０１４は、要求された属性は検証対象外であると判定する。この場合、判定部２０１４は、「要求された属性は検証対象外です」というエラーメッセージを出力し、所有者に対して通常の検証を推奨する。要求された属性が検証対象外である場合、判定部２０１４は、判定処理を行わない。
　このように、各検証者に対して提供可能なＶＣの属性を検証ポリシー１２２２に登録しておくことで、所有者が意図しないＶＣが検証者に対して提供されることを防止できる。
　図１２の発行者装置１１０２において、制御部１２１３は、通常の検証が行われる度に、所有者の指示に基づいて検証ポリシー１２２２を更新する。
　例えば、所有者装置１１０１は、通常の検証が行われた場合に、「以降、この検証を自動的に実行しますか？」という問い合わせを含む問い合わせ画面を表示する。そして、所有者の同意が得られた場合、所有者装置１１０１は、検証者及びＶＣの情報を発行者装置１１０２へ送信する。
　制御部１２１３は、受信した検証者及びＶＣの情報を検証ポリシー１２２２に登録することで、検証ポリシー１２２２を更新する。これにより、検証ポリシー１２２２は、常に最新の状態に保たれる。
　要求された属性が正当である場合、判定部２０１４は、判定処理を行う。判定処理において、判定部２０１４は、タグ付きＶＣ１２２３に含まれるタグを用いて、属性ツリー１２２１に含まれるノードを参照する。具体的には、判定部２０１４は、通信部２０１１を介して、タグ付きＶＣ１２２３に含まれるタグが示すノードのｂｆを、発行者装置１１０２に要求する。そして、判定部２０１４は、発行者装置１１０２からｂｆを取得し、取得されたｂｆをＢＦ２０２２として記憶部２０１６に格納する。
　発行者装置１１０２が属性ツリー１２２１を記憶し、所有者装置１１０１がタグ付きＶＣ１２２３を記憶することで、属性ツリー１２２１の各ノードに含まれる情報を柔軟に変更することが可能になる。例えば、ノードに含まれるｂｆのデータ構造又は仕様が変更された場合であっても、タグ付きＶＣ１２２３に含まれるタグを変更する必要はなく、所有者装置１１０１は、タグを用いて変更後のｂｆを参照することができる。
　図２１のタグ付きＶＣ２１０１－１～タグ付きＶＣ２１０１－Ｎ（Ｎは１以上の整数）は、Ｎ個のタグ付きＶＣ１２２３を表し、ＢＦ２１０２－ｐ（ｐ＝１～Ｎ）は、タグ付きＶＣ２１０１－ｐに含まれるタグを用いて取得されたＢＦ２０２２を表す。各ＢＦ２１０２－ｐは、ｍビットのビット列ＢＦにより表され、ＢＦのｉ番目のビット値は、ＢＦ［ｉ］（ｉ＝０～ｍ－１）により表される。
　判定部２０１４は、ＢＦ２１０２－１～ＢＦ２１０２－Ｎを用いて、ＣＱ２０２１から抽出された属性を属性ツリー１２２１から検索する。まず、判定部２０１４は、ＣＱ２０２１から抽出された属性の文字列ｙのハッシュ値Ｈ１（ｙ）～ハッシュ値Ｈｋ（ｙ）を計算する。Ｈｊ（ｙ）（ｊ＝１～ｋ）は、０～ｍ－１の何れかを示す整数である。
　次に、判定部２０１４は、各ＢＦ２１０２－ｐについて、次式により、判定値ＣＨＫ（ｐ）を計算する。
ＣＨＫ（ｐ）
＝ＢＦ［Ｈ１（ｙ）］　ＡＮＤ　・・・　ＡＮＤ　ＢＦ［Ｈｋ（ｙ）］　　　（１）
　式（１）の右辺は、ｋ個のＢＦ［Ｈｊ（ｙ）］の論理積を表す。上述したように、ＢＦは、そのＢＦを含むノードが示す属性の情報と、そのノードからエッジを辿って到達可能な上位の各ノードが示す属性の情報とを含む。したがって、ＣＨＫ（ｐ）＝１の場合、それらのノードの何れかが示す属性が文字列ｙに一致する可能性が高い。一方、ＣＨＫ（ｐ）＝０の場合、何れのノードが示す属性も文字列ｙには一致しない。
　そこで、判定部２０１４は、ＣＨＫ（ｐ）＝１の場合、判定結果としてＴｒｕｅを出力し、ＣＨＫ（ｐ）＝０の場合、判定結果としてＦａｌｓｅを出力する。Ｔｒｕｅは、属性ツリー１２２１内の特定のノードに含まれるｎａｍｅが示す属性が、ＣＱ２０２１に含まれる属性に対応することを表す。Ｆａｌｓｅは、属性ツリー１２２１内の特定のノードに含まれるｎａｍｅが示す属性が、ＣＱ２０２１に含まれる属性に対応しないことを表す。
　このように、ＣＱ２０２１から抽出された属性をＢＦ２１０２－ｐを用いて検索することで、属性ツリー１２２１内の特定のノードが示す属性が、ＣＱ２０２１に含まれる属性に対応するか否かを容易に判定することができる。
　何れかのＢＦ２１０２－ｐについて判定部２０１４からＴｒｕｅが出力された場合、選択部２０１５は、そのＢＦ２１０２－ｐに対応するタグ付きＶＣ２１０１－ｐを選択する。２つ以上のＢＦ２１０２－ｐについてＴｒｕｅが出力された場合、選択部２０１５は、それらのＢＦ２１０２－ｐに対応する２つ以上のタグ付きＶＣ２１０１－ｐのうち、最上位のノードを参照するタグを含むタグ付きＶＣ２１０１－ｐを選択する。
　次に、選択部２０１５は、選択されたタグ付きＶＣ２１０１－ｐに含まれるＶＣを、開示対象のＶＣとして抽出し、抽出されたＶＣをＶＰ２０２３に変換して、記憶部２０１６に格納する。そして、選択部２０１５は、通信部２０１１を介して、ＶＰ２０２３を含む応答を検証者装置１１０３へ送信する。
　すべてのＢＦ２１０２－ｐについて判定部２０１４からＦａｌｓｅが出力された場合、選択部２０１５は、「要求された属性を示すＶＣは見つかりませんでした」というエラーメッセージを出力し、所有者に対して通常の検証を推奨する。
　図２２は、ＣＨＫ（ｐ）＝１の判定処理の例を示している。この例では、ｍ＝１６、かつ、ｋ＝３である。判定部２０１４は、文字列ｙ１のハッシュ値を計算し、Ｈ１（ｙ１）＝６、Ｈ２（ｙ１）＝２、及びＨ３（ｙ１）＝１３という計算結果を得る。
　次に、判定部２０１４は、ＢＦ２１０２－ｐについて、式（１）により、ＣＨＫ（ｐ）を計算する。この場合、ＢＦ［Ｈ１（ｙ１）］＝ＢＦ［Ｈ２（ｙ１）］＝ＢＦ［Ｈ３（ｙ１）］＝１であるため、ＣＨＫ（ｐ）＝１となる。
　図２３は、ＣＨＫ（ｐ）＝０の判定処理の例を示している。この例では、ｍ＝１６、かつ、ｋ＝３である。判定部２０１４は、文字列ｙ２のハッシュ値を計算し、Ｈ１（ｙ２）＝６、Ｈ２（ｙ２）＝４、及びＨ３（ｙ２）＝９という計算結果を得る。
　次に、判定部２０１４は、ＢＦ２１０２－ｐについて、式（１）により、ＣＨＫ（ｐ）を計算する。この場合、ＢＦ［Ｈ１（ｙ２）］＝ＢＦ［Ｈ２（ｙ２）］＝１、かつ、ＢＦ［Ｈ３（ｙ２）］＝０であるため、ＣＨＫ（ｐ）＝０となる。
　タグが示すノードの属性だけでなく、そのノードよりも上位のノードの属性も対象として、ＣＱ２０２１の属性を検索することで、タグ付きＶＣ２１０１－ｐが示す属性よりも広い範囲の属性を検索することができる。したがって、より広い範囲の属性を含むＣＱ２０２１を検証者装置１１０３から受信した場合であっても、適切なＶＣを選択して提供することができる。
　一例として、図１３の属性ツリー１２２１が参照され、かつ、所有者がタグ付きＶＣ２１０１－１のみを保有している場合について説明する。この例では、タグ付きＶＣ２１０１－１のＶＣが示す属性は、“Ｆ社所属”であり、ＣＱ２０２１に含まれる属性は、“会社員”である。したがって、ＣＱ２０２１に含まれる属性の範囲は、タグ付きＶＣ２１０１－１のＶＣが示す属性の範囲よりも広い。
　この場合、タグ付きＶＣ２１０１－１のタグを用いて、“Ｆ社所属”を含むノード１３０２のｂｆが取得される。ノード１３０２のｂｆは、親ノードであるノード１３０１の“会社員”の情報を含んでいるため、ＣＱ２０２１から抽出された“会社員”のハッシュ値を用いて計算されるＣＨＫ（ｐ）は１となる。そこで、タグ付きＶＣ２１０１－１が選択され、タグ付きＶＣ２１０１－１から開示対象のＶＣが抽出される。
　別の例として、図１３の属性ツリー１２２１が参照され、かつ、所有者がタグ付きＶＣ２１０１－１～タグ付きＶＣ２１０１－３を保有している場合について説明する。この例では、タグ付きＶＣ２１０１－１のＶＣが示す属性は、“研究所所属”であり、タグ付きＶＣ２１０１－２のＶＣが示す属性は、“役職”であり、タグ付きＶＣ２１０１－１のＶＣが示す属性は、“労働組合員”である。また、ＣＱ２０２１に含まれる属性は、“研究所所属”である。
　この場合、タグ付きＶＣ２１０１－１のタグを用いて、“研究所所属”を含むノード１３０４のｂｆが取得される。ノード１３０４のｂｆは、“研究所所属”の情報を含んでいるため、ＣＱ２０２１から抽出された“研究所所属”のハッシュ値を用いて計算されるＣＨＫ（ｐ）は１となる。
　次に、タグ付きＶＣ２１０１－２のタグを用いて、“役職”を含むノード１３０６のｂｆが取得される。ノード１３０６のｂｆは、親ノードであるノード１３０４の“研究所所属”の情報を含んでいるため、ＣＱ２０２１から抽出された“研究所所属”のハッシュ値を用いて計算されるＣＨＫ（ｐ）は１となる。
　次に、タグ付きＶＣ２１０１－３のタグを用いて、“労働組合員”を含むノード１３０５のｂｆが取得される。ノード１３０５のｂｆは、親ノードであるノード１３０４の“研究所所属”の情報を含んでいるため、ＣＱ２０２１から抽出された“研究所所属”のハッシュ値を用いて計算されるＣＨＫ（ｐ）は１となる。
　この場合、タグ付きＶＣ２１０１－１～タグ付きＶＣ２１０１－３のうち、最上位のノード１３０４を参照するタグを含むタグ付きＶＣ２１０１－１が選択され、タグ付きＶＣ２１０１－１から開示対象のＶＣが抽出される。
　最上位のノード１３０４を参照するタグを含むタグ付きＶＣ２１０１－１を選択して、開示対象のＶＣを抽出することで、“役職”又は“労働組合員”等の具体的な個人情報を示すＶＣが検証者に提供されることを防止できる。これにより、所有者のプライバシーを適切に保護することが可能になる。
　検証者装置１１０３は、所有者装置１１０１から受信したＶＰ２０２３からＶＣを取得し、取得されたＶＣを検証する。検証が成功した場合、検証者装置１１０３は、検証成功を所有者装置１１０１に通知するとともに、所有者装置１１０１又は所有者に対して所定のサービスを提供する。例えば、情報処理システムが入退場ゲートに適用される場合、検証者装置１１０３は、入退場ゲートを開く制御を行う。
　図１１の情報処理システムによれば、発行者装置１１０２は、ＶＣの発行時に、ＶＣの属性を自動的に属性ツリー１２２１に登録する。したがって、所有者は、ＣＱ２０２１に対して提示すべきＶＣを示すポリシーを作成する必要がない。属性ツリー１２２１には、所有者が保有するＶＣの属性が漏れなく登録されているため、属性の登録漏れによる検索の失敗を防止できる。
　また、所有者装置１１０１は、検証者装置１１０３からＣＱ２０２１を受信したとき、属性ツリー１２２１を参照しながら、ＣＱ２０２１に対応するＶＣを自動的に選択して、検証者装置１１０３へ送信する。したがって、所有者が保有するＶＣの開示を自動的に制御することができる。
　所有者は画面上でＶＣを選択する作業を行う必要がないため、ＣＱ２０２１に対応するＶＣを速やかに検証者装置１１０３に提供することができる。例えば、所有者が入退場ゲートを通過する場合であっても、社員証ＶＣ等が検証者装置１１０３に速やかに提供されるため、社員証ＶＣ等の検証を高速に行うことができる。また、検証者が所有者にＶＣの提示を要求する場合であっても、電子メール、電話等の連絡手段を用いることなく、所有者装置１１０１から速やかにＶＣを取得することができる。
　図２４は、図１１の情報処理システムにおけるＶＣ発行処理の例を示すフローチャートである。まず、所有者装置１１０１の登録部２０１２は、通信部２０１１を介して、ＶＣ作成依頼を発行者装置１１０２へ送信する（ステップ２４０１）。
　発行者装置１１０２の通信部１２１１は、所有者装置１１０１からＶＣ作成依頼を受信する（ステップ２４０２）。次に、登録部１２１２は、所有者に対応する秘密鍵及び公開鍵を生成する（ステップ２４０３）。そして、登録部１２１２は、ＤＩＤ及び公開鍵を含むＤＩＤ文書を生成し（ステップ２４０４）、通信部１２１１を介して、検証可能データレジストリ１１０４へ送信する（ステップ２４０５）。
　検証可能データレジストリ１１０４は、受信したＤＩＤ文書を確認した後、検証可能データレジストリ１１０４内に保存する（ステップ２４０６）。
　次に、登録部１２１２は、Ｃｌａｉｍ及びＤＩＤと、秘密鍵を用いて生成された署名とを含む、ＶＣを生成する（ステップ２４０７）。そして、登録部１２１２は、生成されたＶＣを含むタグ付きＶＣ１２２３を生成し（ステップ２４０８）、生成されたタグ付きＶＣ１２２３を、通信部１２１１を介して、所有者装置１１０１へ送信する（ステップ２４０９）。
　所有者装置１１０１の通信部２０１１は、発行者装置１１０２からタグ付きＶＣ１２２３を受信し、登録部２０１２は、受信したタグ付きＶＣ１２２３を、記憶部２０１６に保存する（ステップ２４１０）。
　図２５は、図２４のステップ２４０８におけるタグ付きＶＣ生成処理の例を示すフローチャートである。まず、登録部１２１２は、ＶＣ内のＣｌａｉｍから属性の文字列ｘを取得し（ステップ２５０１）、記憶部１２１４から属性ツリー１２２１を取得する（ステップ２５０２）。
　そして、登録部１２１２は、属性ツリー１２２１から文字列ｘを検索し（ステップ２５０３）、属性ツリー１２２１の何れかのノードに文字列ｘが含まれているか否かをチェックする（ステップ２５０４）。
　何れのノードにも文字列ｘが含まれていない場合（ステップ２５０４，ＮＯ）、登録部１２１２は、文字列ｘを示す新規ノードを属性ツリー１２２１に追加する（ステップ２５０５）。そして、登録部１２１２は、追加されたノードのｉｄを含むＵＲＬを、タグとして生成する（ステップ２５０７）。
　一方、何れかのノードに文字列ｘが含まれている場合（ステップ２５０４，ＹＥＳ）、登録部１２１２は、そのノードからｉｄを取得する（ステップ２５０６）。そして、登録部１２１２は、取得されたｉｄを含むＵＲＬを、タグとして生成する（ステップ２５０７）。
　次に、登録部１２１２は、生成されたタグをＶＣに付加することで、タグ付きＶＣ１２２３を生成する（ステップ２５０８）。
　図２６は、図１１の情報処理システムにおけるＶＣ提供処理の例を示すフローチャートである。まず、検証者装置１１０３は、ＣＱ２０２１を所有者装置１１０１へ送信する（ステップ２６０１）。
　所有者装置１１０１の通信部２０１１は、検証者装置１１０３からＣＱ２０２１を受信し、受付部２０１３は、受信したＣＱ２０２１を受け付ける（ステップ２６０２）。そして、判定部２０１４は、通信部２０１１を介して、発行者装置１１０２に検証ポリシー１２２２を要求する（ステップ２６０３）。
　発行者装置１１０２の制御部１２１３は、通信部１２１１を介して、検証ポリシー１２２２を所有者装置１１０１へ送信する（ステップ２６０４）。
　所有者装置１１０１の判定部２０１４及び選択部２０１５は、検証ポリシー１２２２を用いて、ＶＰ２０２３を生成するＶＰ生成処理を行う（ステップ２６０５）。そして、選択部２０１５は、ＶＰ生成処理によってＶＰ２０２３が生成されたか否かをチェックする（ステップ２６０６）。ＶＰ２０２３が生成されていない場合（ステップ２６０６，ＮＯ）、所有者装置１１０１は、処理を終了する。
　一方、ＶＰ２０２３が生成された場合（ステップ２６０６，ＹＥＳ）、選択部２０１５は、通信部２０１１を介して、ＶＰ２０２３を含む応答を検証者装置１１０３へ送信する（ステップ２６０７）。
　図２７Ａ及び図２７Ｂは、図２６のステップ２６０５におけるＶＰ生成処理の例を示すフローチャートである。まず、判定部２０１４は、発行者装置１１０２から受信した検証ポリシー１２２２を取得する（ステップ２７０１）。
　次に、判定部２０１４は、ＣＱ２０２１から検証者名を取得し（ステップ２７０２）、取得された検証者名が検証ポリシー１２２２に含まれているか否かをチェックする（ステップ２７０３）。
　検証者名が検証ポリシー１２２２に含まれていない場合（ステップ２７０３，ＮＯ）、判定部２０１４は、「ＶＣを要求した検証者は非認可です」というエラーメッセージを出力する（ステップ２７０４）。そして、判定部２０１４は、所有者に対して通常の検証を推奨する（ステップ２７０５）。この場合、ＶＰ生成処理によって、ＶＰ２０２３は生成されない。
　一方、検証者名が検証ポリシー１２２２に含まれている場合（ステップ２７０３，ＹＥＳ）、判定部２０１４は、ＣＱ２０２１から属性を取得する（ステップ２７０６）。
　次に、判定部２０１４は、検証ポリシー１２２２において、ＣＱ２０２１から取得された検証者名に対応するｃｒｅｄｅｎｔｉａｌｓに含まれている各文字列から、ブルームフィルタＢＦを生成する（ステップ２７０７）。ステップ２７０７において、判定部２０１４は、登録対象ブルームフィルタの場合と同様にして、各文字列をＢＦに変換する。
　次に、判定部２０１４は、ＣＱ２０２１から取得された属性の文字列ｙのハッシュ値Ｈ１（ｙ）～ハッシュ値Ｈｋ（ｙ）を計算し、各ＢＦに対する判定値ＣＨＫを計算する。ＣＨＫは、式（１）のＣＨＫ（ｐ）と同様にして、Ｈｊ（ｙ）及びＢＦから計算される。そして、判定部２０１４は、各ＢＦに対するＣＨＫが示す判定結果をチェックする（ステップ２７０８）。
　すべてのＢＦに対するＣＨＫが示す判定結果がＦａｌｓｅである場合（ステップ２７０８，ＮＯ）、判定部２０１４は、「要求された属性は検証対象外です」というエラーメッセージを出力する（ステップ２７０９）。そして、判定部２０１４は、所有者に対して通常の検証を推奨する（ステップ２７１０）。この場合、ＶＰ生成処理によって、ＶＰ２０２３は生成されない。
　一方、何れかのＢＦに対するＣＨＫが示す判定結果がＴｒｕｅである場合（ステップ２７０８，ＹＥＳ）、判定部２０１４は、空のＶＣリストを生成する（ステップ２７１１）。
　次に、判定部２０１４は、所有者が保有するタグ付きＶＣ２１０１－１～タグ付きＶＣ２１０１－Ｎの中から、何れかのタグ付きＶＣ２１０１－ｐを選択し、そのタグ付きＶＣ２１０１－ｐからタグを取得する（ステップ２７１２）。
　次に、判定部２０１４は、通信部２０１１を介して、タグ付きＶＣ２１０１－ｐに含まれるタグが示すノードのｂｆを、発行者装置１１０２に要求し、発行者装置１１０２からＢＦ２１０２－ｐを取得する（ステップ２７１３）。
　次に、判定部２０１４は、ＣＱ２０２１から取得された属性の文字列ｙのハッシュ値Ｈｊ（ｙ）を用いて、式（１）により、ＢＦ２１０２－ｐに対する判定値ＣＨＫ（ｐ）を計算する。そして、判定部２０１４は、ＣＨＫ（ｐ）が示す判定結果を、選択部２０１５へ出力する。
　次に、選択部２０１５は、判定部２０１４から出力された判定結果をチェックする（ステップ２７１４）。判定結果がＴｒｕｅである場合（ステップ２７１４，ＹＥＳ）、選択部２０１５は、タグ付きＶＣ２１０１－ｐに含まれているＶＣを、ＶＣリストに追加する（ステップ２７１５）。
　次に、判定部２０１４は、すべてのタグ付きＶＣ２１０１－ｐを選択したか否かをチェックする（ステップ２７１６）。未選択のタグ付きＶＣ２１０１－ｐが残っている場合（ステップ２７１６，ＮＯ）、所有者装置１１０１は、次のタグ付きＶＣ２１０１－ｐについて、ステップ２７１２以降の処理を繰り返す。
　判定結果がＦａｌｓｅである場合（ステップ２７１４，ＮＯ）、所有者装置１１０１は、ステップ２７１６以降の処理を行う。そして、すべてのタグ付きＶＣ２１０１－ｐが選択された場合（ステップ２７１６，ＹＥＳ）、選択部２０１５は、ＶＣリストが空であるか否かをチェックする（ステップ２７１７）。
　ＶＣリストが空である場合（ステップ２７１７，ＹＥＳ）、選択部２０１５は、「要求された属性を示すＶＣは見つかりませんでした」というエラーメッセージを出力する（ステップ２７１８）。そして、選択部２０１５は、所有者に対して通常の検証を推奨する（ステップ２７１９）。この場合、ＶＰ生成処理によって、ＶＰ２０２３は生成されない。
　一方、ＶＣリストが空ではない場合（ステップ２７１７，ＮＯ）、選択部２０１５は、ＶＣリストに２つ以上のＶＣが含まれているか否かをチェックする（ステップ２７２０）。
　ＶＣリストに２つ以上のＶＣが含まれている場合（ステップ２７２０，ＹＥＳ）、選択部２０１５は、それらのＶＣのうち、最上位のノードに対応するＶＣを選択する（ステップ２７２１）。最上位のノードに対応するＶＣは、最上位のノードを参照するタグを含むタグ付きＶＣ２１０１－ｐに含まれていたＶＣである。
　一方、ＶＣリストに１つのＶＣのみが含まれている場合（ステップ２７２０，ＮＯ）、選択部２０１５は、そのＶＣを選択する（ステップ２７２２）。
　次に、選択部２０１５は、選択されたＶＣをＶＰ２０２３に変換することで、ＶＰ２０２３を生成する（ステップ２７２３）。この場合、ＶＰ生成処理によって、ＶＰ２０２３が生成される。
　図９の情報処理装置９０１の構成は一例に過ぎず、情報処理装置９０１の用途又は条件に応じて一部の構成要素を省略又は変更してもよい。
　図１１の情報処理システムの構成は一例に過ぎず、情報処理システムの用途又は条件に応じて一部の構成要素を省略又は変更してもよい。図１２の発行者装置１１０２及び図２０の所有者装置１１０１の構成は一例に過ぎず、情報処理システムの用途又は条件に応じて一部の構成要素を省略又は変更してもよい。
　図１０及び図２４～図２７Ｂのフローチャートは一例に過ぎず、情報処理装置９０１又は情報処理システムの構成又は条件に応じて一部の処理を省略又は変更してもよい。
　図１及び図４に示したＶＣの生成及び保管は一例に過ぎず、ＶＣの生成及び保管は、ＶＣの用途又は条件に応じて変化する。図２及び図５に示したＶＣの検証は一例に過ぎず、ＶＣの検証は、ＶＣの用途又は条件に応じて変化する。
　図３及び図６のスマートフォン３０１の構成は一例に過ぎず、スマートフォン３０１の用途又は条件に応じて一部の構成要素を省略又は変更してもよい。
　図７に示したポリシーの設定及びＶＣの検証の手順は一例に過ぎず、ポリシーの設定及びＶＣの検証の手順は、ＶＣの用途又は条件に応じて変化する。図８に示したスマートフォン３０１の動作は一例に過ぎず、スマートフォン３０１の動作は、ＶＣの用途又は条件に応じて変化する。
　図１３に示した属性ツリー１２２１は一例に過ぎず、別のデータ構造の属性管理情報を用いてもよい。属性ツリー１２２１の各ノードが有する情報は一例に過ぎず、情報処理システムの構成又は条件に応じて一部の情報を省略又は変更してもよい。例えば、ブルームフィルタの代わりに、カッコウフィルタ等の別の制御情報を用いてもよい。属性ツリー１２２１に含まれるノードの個数及び属性は、ＶＣの用途又は条件に応じて変化する。
　図１４及び図１５に示したタグ付きＶＣ生成処理は一例に過ぎず、発行者装置１１０２は、別の方法でタグ付きＶＣ１２２３を生成してもよい。図１６～図１８、図２２、及び図２３に示したブルームフィルタは一例に過ぎず、ブルームフィルタは、ＶＣの用途又は条件に応じて変化する。図１９に示した検証ポリシー１２２２は一例に過ぎず、別の形式の開示条件情報を用いてもよい。
　図２１に示した判定処理は一例に過ぎず、所有者装置１１０１は、別の方法で判定処理を行ってもよい。式（１）は一例に過ぎず、判定部２０１４は、別の計算式を用いて判定値ＣＨＫ（ｐ）を計算してもよい。
　図２８は、図９の情報処理装置９０１、図１２の発行者装置１１０２、及び図２０の所有者装置１１０１として用いられる情報処理装置のハードウェア構成例を示している。図２８の情報処理装置は、ＣＰＵ（Central　Processing　Unit）２８０１、メモリ２８０２、入力装置２８０３、出力装置２８０４、補助記憶装置２８０５、媒体駆動装置２８０６、及びネットワーク接続装置２８０７を含む。これらの構成要素はハードウェアであり、バス２８０８により互いに接続されている。
　メモリ２８０２は、例えば、ＲＯＭ（Read　Only　Memory）、ＲＡＭ（Random　Access　Memory）、フラッシュメモリ等の半導体メモリであり、処理に用いられるプログラム及びデータを記憶する。メモリ２８０２は、図１２の記憶部１２１４又は図２０の記憶部２０１６として動作してもよい。
　ＣＰＵ２８０１（プロセッサ）は、例えば、メモリ２８０２を利用してプログラムを実行することにより、図９の受付部９１１、判定部９１２、及び選択部９１３として動作する。
　ＣＰＵ２８０１は、メモリ２８０２を利用してプログラムを実行することにより、図１２の登録部１２１２及び制御部１２１３としても動作する。ＣＰＵ２８０１は、メモリ２８０２を利用してプログラムを実行することにより、図２０の登録部２０１２、受付部２０１３、判定部２０１４、及び選択部２０１５としても動作する。
　入力装置２８０３は、例えば、キーボード、ポインティングデバイス等であり、ユーザ又はオペレータからの指示又は情報の入力に用いられる。出力装置２８０４は、例えば、表示装置、プリンタ、スピーカ等であり、ユーザ又はオペレータへの問い合わせ又は処理結果の出力に用いられる。
　補助記憶装置２８０５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。補助記憶装置２８０５は、ハードディスクドライブ又はＳＳＤ（Solid　State　Drive）であってもよい。情報処理装置がスマートフォンである場合、補助記憶装置２８０５は、フラッシュメモリであってもよい。
　情報処理装置は、補助記憶装置２８０５にプログラム及びデータを格納しておき、それらをメモリ２８０２にロードして使用することができる。補助記憶装置２８０５は、図１２の記憶部１２１４又は図２０の記憶部２０１６として動作してもよい。
　媒体駆動装置２８０６は、可搬型記録媒体２８０９を駆動し、その記録内容にアクセスする。可搬型記録媒体２８０９は、メモリデバイス、フレキシブルディスク、光ディスク、光磁気ディスク等である。可搬型記録媒体２８０９は、ＣＤ－ＲＯＭ（Compact　Disk　Read　Only　Memory）、ＤＶＤ（Digital　Versatile　Disk）、ＵＳＢ（Universal　Serial　Bus）メモリ等であってもよい。ユーザ又はオペレータは、可搬型記録媒体２８０９にプログラム及びデータを格納しておき、それらをメモリ２８０２にロードして使用することができる。
　このように、処理に用いられるプログラム及びデータを格納するコンピュータ読み取り可能な記録媒体は、メモリ２８０２、補助記憶装置２８０５、又は可搬型記録媒体２８０９のような、物理的な（非一時的な）記録媒体である。
　ネットワーク接続装置２８０７は、通信ネットワーク１１０５に接続され、通信に伴うデータ変換を行う通信インタフェース回路である。情報処理装置は、プログラム及びデータを外部の装置からネットワーク接続装置２８０７を介して受信し、それらをメモリ２８０２にロードして使用することができる。ネットワーク接続装置２８０７は、図１２の通信部１２１１又は図２０の通信部２０１１として動作してもよい。
　なお、情報処理装置が図２８のすべての構成要素を含む必要はなく、用途又は条件に応じて一部の構成要素を省略又は変更することも可能である。例えば、ユーザ又はオペレータとのインタフェースが不要である場合は、入力装置２８０３及び出力装置２８０４を省略してもよい。情報処理装置が可搬型記録媒体２８０９を利用しない場合は、媒体駆動装置２８０６を省略してもよい。
　図１１の検証者装置１１０３及び検証可能データレジストリ１１０４としては、図２８と同様の情報処理装置を用いることができる。
　開示の実施形態とその利点について詳しく説明したが、当業者は、特許請求の範囲に明確に記載した本発明の範囲から逸脱することなく、様々な変更、追加、省略をすることができるであろう。

Claims (15)

  1. 　個人情報所有者が特定の属性を有することを示す個人情報の開示を要求する開示要求を受け付け、
    　複数の属性情報を含み、かつ、前記複数の属性情報のうち１つの属性情報が示す属性の範囲が、前記複数の属性情報のうち前記１つの属性情報よりも上位の属性情報が示す属性の範囲に含まれる階層構造を有する属性管理情報において、前記個人情報所有者が保有する１つ又は複数の個人情報それぞれに対応する第１属性情報が示す第１属性と、前記第１属性情報よりも上位の第２属性情報が示す第２属性とが、前記特定の属性に対応するか否かを判定する判定処理を行い、
    　前記判定処理の結果に基づいて、前記１つ又は複数の個人情報の何れかを開示対象の個人情報として選択する、
    　処理をコンピュータが実行することを特徴とする個人情報制御方法。
  2. 　前記第１属性情報は、前記属性管理情報が前記第１属性情報及び前記第２属性情報を含むことを示す制御情報を含み、
    　前記判定処理は、
    　　前記第１属性情報から前記制御情報を取得する処理と、
    　　前記開示要求及び前記制御情報に基づいて、前記第１属性及び前記第２属性が前記特定の属性に対応するか否かを判定する処理と、
    　を含むことを特徴とする請求項１記載の個人情報制御方法。
  3. 　前記１つ又は複数の個人情報それぞれには、前記属性管理情報に含まれる前記第１属性情報を示すタグが付加されており、
    　前記第１属性情報から前記制御情報を取得する処理は、前記タグを用いて、前記属性管理情報に含まれる前記第１属性情報を参照する処理を含むことを特徴とする請求項２記載の個人情報制御方法。
  4. 　前記開示要求は、前記個人情報の開示を要求する個人情報要求者の識別情報を含み、
    　１つ又は複数の個人情報開示先それぞれの識別情報を含む開示条件情報と、前記個人情報要求者の識別情報とに基づいて、前記判定処理を行うか否かを決定する処理を、前記コンピュータがさらに実行することを特徴とする請求項１乃至３の何れか１項に記載の個人情報制御方法。
  5. 　前記開示条件情報は、１つ又は複数の開示対象属性をさらに含み、
    　前記１つ又は複数の開示対象属性と前記特定の属性とに基づいて、前記判定処理を行うか否かを決定する処理を、前記コンピュータがさらに実行することを特徴とする請求項４記載の個人情報制御方法。
  6. 　個人情報所有者が特定の属性を有することを示す個人情報の開示を要求する開示要求を受け付ける受付部と、
    　複数の属性情報を含み、かつ、前記複数の属性情報のうち１つの属性情報が示す属性の範囲が、前記複数の属性情報のうち前記１つの属性情報よりも上位の属性情報が示す属性の範囲に含まれる階層構造を有する属性管理情報において、前記個人情報所有者が保有する１つ又は複数の個人情報それぞれに対応する第１属性情報が示す第１属性と、前記第１属性情報よりも上位の第２属性情報が示す第２属性とが、前記特定の属性に対応するか否かを判定する判定処理を行う判定部と、
    　前記判定処理の結果に基づいて、前記１つ又は複数の個人情報の何れかを開示対象の個人情報として選択する選択部と、
    　を備えることを特徴とする情報処理装置。
  7. 　前記第１属性情報は、前記属性管理情報が前記第１属性情報及び前記第２属性情報を含むことを示す制御情報を含み、
    　前記判定部は、前記第１属性情報から前記制御情報を取得し、前記開示要求及び前記制御情報に基づいて、前記第１属性及び前記第２属性が前記特定の属性に対応するか否かを判定することを特徴とする請求項６記載の情報処理装置。
  8. 　前記１つ又は複数の個人情報それぞれには、前記属性管理情報に含まれる前記第１属性情報を示すタグが付加されており、
    　前記判定部は、前記タグを用いて、前記属性管理情報に含まれる前記第１属性情報を参照することを特徴とする請求項７記載の情報処理装置。
  9. 　前記開示要求は、前記個人情報の開示を要求する個人情報要求者の識別情報を含み、
    　前記判定部は、１つ又は複数の個人情報開示先それぞれの識別情報を含む開示条件情報と、前記個人情報要求者の識別情報とに基づいて、前記判定処理を行うか否かを決定することを特徴とする請求項６乃至８の何れか１項に記載の情報処理装置。
  10. 　前記開示条件情報は、１つ又は複数の開示対象属性をさらに含み、
    　前記判定部は、前記１つ又は複数の開示対象属性と前記特定の属性とに基づいて、前記判定処理を行うか否かを決定することを特徴とする請求項９記載の情報処理装置。
  11. 　個人情報所有者が特定の属性を有することを示す個人情報の開示を要求する開示要求を受け付け、
    　複数の属性情報を含み、かつ、前記複数の属性情報のうち１つの属性情報が示す属性の範囲が、前記複数の属性情報のうち前記１つの属性情報よりも上位の属性情報が示す属性の範囲に含まれる階層構造を有する属性管理情報において、前記個人情報所有者が保有する１つ又は複数の個人情報それぞれに対応する第１属性情報が示す第１属性と、前記第１属性情報よりも上位の第２属性情報が示す第２属性とが、前記特定の属性に対応するか否かを判定する判定処理を行い、
    　前記判定処理の結果に基づいて、前記１つ又は複数の個人情報の何れかを開示対象の個人情報として選択する、
    　処理をコンピュータに実行させるための個人情報制御プログラム。
  12. 　前記第１属性情報は、前記属性管理情報が前記第１属性情報及び前記第２属性情報を含むことを示す制御情報を含み、
    　前記判定処理は、
    　　前記第１属性情報から前記制御情報を取得する処理と、
    　　前記開示要求及び前記制御情報に基づいて、前記第１属性及び前記第２属性が前記特定の属性に対応するか否かを判定する処理と、
    　を含むことを特徴とする請求項１１記載の個人情報制御プログラム。
  13. 　前記１つ又は複数の個人情報それぞれには、前記属性管理情報に含まれる前記第１属性情報を示すタグが付加されており、
    　前記第１属性情報から前記制御情報を取得する処理は、前記タグを用いて、前記属性管理情報に含まれる前記第１属性情報を参照する処理を含むことを特徴とする請求項１２記載の個人情報制御プログラム。
  14. 　前記開示要求は、前記個人情報の開示を要求する個人情報要求者の識別情報を含み、
    　前記個人情報制御プログラムは、１つ又は複数の個人情報開示先それぞれの識別情報を含む開示条件情報と、前記個人情報要求者の識別情報とに基づいて、前記判定処理を行うか否かを決定する処理を、前記コンピュータにさらに実行させることを特徴とする請求項１１乃至１３の何れか１項に記載の個人情報制御プログラム。
  15. 　前記開示条件情報は、１つ又は複数の開示対象属性をさらに含み、
    　前記個人情報制御プログラムは、前記１つ又は複数の開示対象属性と前記特定の属性とに基づいて、前記判定処理を行うか否かを決定する処理を、前記コンピュータにさらに実行させることを特徴とする請求項１４記載の個人情報制御プログラム。
     
PCT/JP2022/000326 2022-01-07 2022-01-07 個人情報制御方法、情報処理装置、及び個人情報制御プログラム WO2023132049A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/000326 WO2023132049A1 (ja) 2022-01-07 2022-01-07 個人情報制御方法、情報処理装置、及び個人情報制御プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/000326 WO2023132049A1 (ja) 2022-01-07 2022-01-07 個人情報制御方法、情報処理装置、及び個人情報制御プログラム

Publications (1)

Publication Number Publication Date
WO2023132049A1 true WO2023132049A1 (ja) 2023-07-13

Family

ID=87073519

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/000326 WO2023132049A1 (ja) 2022-01-07 2022-01-07 個人情報制御方法、情報処理装置、及び個人情報制御プログラム

Country Status (1)

Country Link
WO (1) WO2023132049A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7485187B1 (ja) 2023-10-20 2024-05-16 日本電気株式会社 端末、システム、端末の制御方法及びプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015057870A (ja) * 2011-12-01 2015-03-26 株式会社Ｇｅｏｈｅｘ 位置データ加工サーバ、携帯通信端末およびコンピュータプログラム
JP2019040537A (ja) * 2017-08-28 2019-03-14 日本電信電話株式会社 本人確認情報提供方法および本人確認情報提供サーバ
JP2020184182A (ja) * 2019-05-08 2020-11-12 三菱電機株式会社 開示制御装置、開示制御方法および開示制御プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015057870A (ja) * 2011-12-01 2015-03-26 株式会社Ｇｅｏｈｅｘ 位置データ加工サーバ、携帯通信端末およびコンピュータプログラム
JP2019040537A (ja) * 2017-08-28 2019-03-14 日本電信電話株式会社 本人確認情報提供方法および本人確認情報提供サーバ
JP2020184182A (ja) * 2019-05-08 2020-11-12 三菱電機株式会社 開示制御装置、開示制御方法および開示制御プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7485187B1 (ja) 2023-10-20 2024-05-16 日本電気株式会社 端末、システム、端末の制御方法及びプログラム

Similar Documents

Publication Publication Date Title
Ocheja et al. Managing lifelong learning records through blockchain
US20210286868A1 (en) Method For Providing An Authenticated Digital Identity
US10110584B1 (en) Elevating trust in user identity during RESTful authentication and authorization
US9805213B1 (en) Identity validation and verification system and associated methods
KR101590076B1 (ko) 개인정보 관리 방법
US11176553B2 (en) Method and system providing peer effort-based validation
JP7083892B2 (ja) デジタル証明書のモバイル認証相互運用性
US20120124655A1 (en) Apparatus for connecting a human key identification to objects and content or identification, tracking, delivery, advertising, and marketing
CN113056741A (zh) 基于分布式账本的简档验证
Van Dijck et al. Electronic identity services as sociotechnical and political-economic constructs
US20130024769A1 (en) Apparatus and method for processing a document
Belmann et al. de. NBI Cloud federation through ELIXIR AAI
WO2023132049A1 (ja) 個人情報制御方法、情報処理装置、及び個人情報制御プログラム
Otta et al. A systematic survey of multi-factor authentication for cloud infrastructure
KR20210109164A (ko) 블록체인을 이용한 최초 저작권자 인증 시스템 및 그 방법
CN117397205A (zh) 引导对去中心化标识符的信任
US20080209218A1 (en) Methods and systems for providing independent verification of information in a public forum
US20080320102A1 (en) Information retrieval system
JP2003085141A (ja) シングルサインオン対応認証装置、ネットワークシステム、及びプログラム
Deng et al. Towards a cross‐context identity management framework in e‐health
Garibyan et al. Access and identity management for libraries: controlling access to online information
JP2013020643A (ja) 個人情報提供装置、および個人情報提供方法
JP2021140299A (ja) データマッチングシステム、情報処理装置およびデータマッチング方法
Kim et al. Reducing security overhead to enhance service delivery in Jini IoT
Santiago et al. Blockchain applied to academic environments as a way to ensure educational process quality control

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22918638

Country of ref document: EP

Kind code of ref document: A1