Requirement identification device, requirement identification method, and requirement identification program

Abstract

To allow a legal system requirement of personal data to consider to be efficiently specified when a system which uses the personal data is developed.SOLUTION: A classification reception unit 21 receives a specified classification as the classification of the personal data. A usage method reception unit 22 receives the method for specification as a method for using the personal data. A request specification unit 23 specifies a requirement to consider as to usage of the personal data which corresponds to the specified classification received by the classification reception unit 21 and the method for specification received by the usage method reception unit 22.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a technology for identifying requirements to be considered regarding the use of personal data. [Background technology]

[0002] Advances in internet technology have stimulated efforts by businesses to collect and utilize personal data. Accordingly, legal systems regarding personal data have been enacted in various countries. For example, Japan has enacted the Act on the Protection of Personal Information. However, legal systems regarding personal data contain many requirements. It has been difficult for system developers to understand which of the requirements written in legal systems regarding personal data should be taken into consideration in the systems they develop.

[0003] Patent Document 1 describes an apparatus for improving the efficiency of requirements extraction work. In Patent Document 1, requirements extraction conditions and requirement types that match the requirements extraction conditions are stored in association with each other. The requirements extraction conditions are conditions for determining whether requirements related to a processing system for performing processing related to laws and regulations are included in the provisions of the laws and regulations. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2012-203725 Summary of the Invention [Problem to be solved by the invention]

[0005] In the legal system regarding personal data, it is possible to efficiently identify the requirements to be complied with by utilizing a combination of the classification of personal data used by a system and the method of using that personal data. Patent Document 1 only considers the data name and the type of requirement. In other words, Patent Document 1 does not consider the classification of personal data. The present disclosure aims to enable efficient identification of legal requirements for personal data that should be taken into consideration when developing a system that uses personal data. [Means for solving the problem]

[0006] The requirement identification device according to the present disclosure includes: a classification receiving unit that receives a designated classification that is a classification of personal data; a usage method receiving unit that receives a designated method, which is a method of using the personal data; a requirement specifying unit that specifies consideration requirements to be considered regarding the use of the personal data, corresponding to the designated classification accepted by the classification accepting unit and the designated method accepted by the usage method accepting unit; Equipped with. [Effects of the Invention]

[0007] In the present disclosure, the consideration requirements are identified using designated classifications, which are classifications of personal data, thereby enabling efficient identification of legal requirements for personal data that should be considered. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a configuration diagram of a requirement specifying device 10 according to a first embodiment. [Figure 2] FIG. 3 is an explanatory diagram of requirement data 31 according to the first embodiment. [Figure 3] FIG. 3 is an explanatory diagram of a search rule 32 according to the first embodiment. [Figure 4] 3 is a flowchart showing the flow of processing of the requirement identifying device 10 according to the first embodiment. [Figure 5]FIG. 10 is a configuration diagram of a requirement specifying device 10 according to a first modified example. [Figure 6] FIG. 10 is a configuration diagram of a requirement specifying device 10 according to a second embodiment. [Figure 7] FIG. 10 is an explanatory diagram of requirement data 31 according to the second embodiment. [Figure 8] FIG. 10 is an explanatory diagram of inclusion information 33 according to the second embodiment. [Figure 9] FIG. 10 is an explanatory diagram of a search rule 32 according to the second embodiment. [Figure 10] FIG. 11 is an explanatory diagram of requirement data 31 according to the third embodiment. [Figure 11] FIG. 11 is an explanatory diagram of tagging according to the third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] Embodiment 1 ***Configuration Description*** The configuration of a requirement specifying device 10 according to the first embodiment will be described with reference to FIG. The requirement specifying device 10 is a computer. The requirement identification device 10 includes hardware such as a processor 11, a memory 12, a storage 13, and a communication interface 14. The processor 11 is connected to other hardware via signal lines and controls the other hardware.

[0010] The processor 11 is an IC that performs processing. IC stands for Integrated Circuit. Specific examples of the processor 11 include a CPU, a DSP, and a GPU. CPU stands for Central Processing Unit. DSP stands for Digital Signal Processor. GPU stands for Graphics Processing Unit.

[0011] The memory 12 is a storage device that temporarily stores data. Specific examples of the memory 12 include SRAM and DRAM. SRAM stands for Static Random Access Memory. DRAM stands for Dynamic Random Access Memory.

[0012] The storage 13 is a storage device that stores data. A specific example of the storage 13 is an HDD. HDD is an abbreviation for Hard Disk Drive. The storage 13 may also be a portable recording medium such as an SD (registered trademark) memory card, CompactFlash (registered trademark), NAND flash, a flexible disk, an optical disk, a compact disk, a Blu-ray (registered trademark) disk, or a DVD. SD is an abbreviation for Secure Digital. DVD is an abbreviation for Digital Versatile Disk.

[0013] The communication interface 14 is an interface for communicating with external devices. Specific examples of the communication interface 14 include Ethernet (registered trademark), USB, and HDMI (registered trademark) ports. USB stands for Universal Serial Bus. HDMI stands for High-Definition Multimedia Interface.

[0014] The requirement identification device 10 includes, as functional components, a classification receiving unit 21, a usage method receiving unit 22, and a requirement identification unit 23. The functions of the functional components of the requirement identification device 10 are realized by software. The storage 13 stores a program that realizes the function of each functional component of the requirements identification device 10. The program is read into the memory 12 by the processor 11 and executed by the processor 11. In this way, the function of each functional component of the requirements identification device 10 is realized.

[0015] The storage 13 stores requirement data 31 and search rules 32. The requirement data 31 and search rules 32 may be stored in a storage device external to the requirement identifying device 10.

[0016] 1 shows only one processor 11. However, there may be a plurality of processors 11, and the plurality of processors 11 may cooperate to execute programs that realize the respective functions.

[0017] ***Explanation of Operation*** The operation of the requirement identifying device 10 according to the first embodiment will be described with reference to FIGS. The operation procedure of the requirement identification device 10 according to the embodiment 1 corresponds to the requirement identification method according to the embodiment 1. Moreover, the program that realizes the operation of the requirement identification device 10 according to the embodiment 1 corresponds to the requirement identification program according to the embodiment 1.

[0018] The requirement data 31 according to the first embodiment will be described with reference to FIG. In the requirement data 31, a set of requirements is set for each combination of the classification of personal data and the method of using the personal data. The classification of personal data is a classification established within the legal system regarding personal data. For example, in Japan's Personal Information Protection Act, personal data is classified into "personal information," "personal data," and "retained personal data." The method of using personal data is a classification that shows how the personal data will be used in the system. For example, in Japan's Personal Information Protection Act, the methods of using personal data include "handling," "acquiring," and "providing to a third party." Requirements are those stipulated in the legal system regarding personal data. Prerequisites are those that must be observed when using personal data. For example, requirements include "obtaining the individual's consent when providing the data to a third party" and "publicizing the purpose of use."

[0019] Here, {A,B,C,...} represents a set, and φ represents the empty set. As shown in the first row of Figure 2, the set of requirements for "handling" "personal information" on the system is {Requirement 1, Requirement 2}. In other words, when "handling" "personal information" on the system, both Requirement 1 and Requirement 2 must be taken into consideration. As shown in the fourth row of Figure 2, the set of requirements for "providing personal data to a third party" on the system is {Requirement 1, Requirement 2, Requirement 3, Requirement 4}. When "providing personal data to a third party" on the system, requirements 1, 2, 3, and 4 must all be taken into consideration.

[0020] The search rule 32 according to the first embodiment will be described with reference to FIG. Search rule 32 is a rule that defines a method for searching requirement data 31 and identifying a set of considerations that should be taken into account when using personal data. Search rule 32 takes as input the classification of personal data and the method of use of the personal data. Search rule 32 defines a method for identifying a set of considerations that should be taken into account when using personal data indicated by the input classification in the input method of use.

[0021] The search rule 32 shown in FIG. 3 will be explained. Step S11: Classification C is input. Step S12: The usage method M is input. Step S13: The requirement data 31 is referenced, and a requirement set S of rows in which the classification is C and the usage method is M is obtained. Step S14: The requirement set S obtained in step S13 is output.

[0022] The flow of processing performed by the requirement identifying device 10 according to the first embodiment will be described with reference to FIG. Here, we will explain an example of acquiring a set of consideration requirements to be taken into account in a system that includes the process of "providing personal data to a third party." In this case, we will explain the case where requirement data 31 shown in Figure 2 and search rules 32 shown in Figure 3 are used.

[0023] (Step S1: Classification reception process) The classification receiving unit 21 receives a designated classification that is a classification of personal data. Here, the category receiving unit 21 receives "personal data" as the designated category.

[0024] (Step S2: Usage method acceptance process) The usage method receiving unit 22 receives a designated method, which is a method of using personal data. Here, the usage method receiving unit 22 receives "Provide to a third party" as the specified method.

[0025] (Step S3: Rule acquisition process) The requirement specifying unit 23 acquires the search rules 32 from the storage 13 . Here, the requirement specifying unit 23 acquires the search rule 32 shown in FIG.

[0026] (Step S4: Requirement identification process) The requirement specifying unit 23 executes the search rule 32 acquired in step S3 to specify a set of consideration requirements. Specifically, in step S11, the requirements identification unit 23 receives as input the designated classification received in step S1. In step S12, the requirements identification unit 23 receives as input the designated method received in step S2. In step S13, the requirements identification unit 23 refers to the requirements data 31 to identify a requirements set S of rows where the classification is the designated classification and the usage method is the designated method. Then, in step S14, the requirements identification unit 23 outputs the requirements set S as a set of consideration requirements.

[0027] Here, in step S11, the specified classification "personal data" is input. In step S12, the specified method "provide to a third party" is input. In step S13, the requirement data 31 shown in FIG. 2 is referenced, and the requirement set S of the row where the classification is "personal data" and the usage method is "provide to a third party" is identified. Here, the requirement set S is {requirement 1, requirement 2, requirement 3, requirement 4}. In step S14, {requirement 1, requirement 2, requirement 3, requirement 4} is output as a set of consideration requirements.

[0028] (Step S5: Requirement output process) The requirement identification unit 23 outputs the set of consideration requirements output in step S4 as the execution result of the search rule 32. For example, the requirement identification unit 23 displays the set of consideration requirements on a display device connected to the requirement identification device 10. Here, {Requirement 1, Requirement 2, Requirement 3, Requirement 4} is output. In other words, {Requirement 1, Requirement 2, Requirement 3, Requirement 4} is output as a set of requirements to be taken into account in a system that includes the process of "providing personal data to a third party."

[0029] ***Effects of the First Embodiment*** As described above, the requirement specifying device 10 according to the first embodiment specifies a set of consideration requirements based on the classification of personal data, thereby making it possible to efficiently specify legal requirements for personal data that should be considered.

[0030] ***Other Configurations*** <Variation 1> In the first embodiment, each functional component is realized by software. However, as a first modification, each functional component may be realized by hardware. The differences between the first embodiment and the first modification will be described below.

[0031] The configuration of the requirement identifying device 10 according to the first modification will be described with reference to FIG. When each functional component is realized by hardware, the requirements identification device 10 includes an electronic circuit 15 instead of the processor 11, the memory 12, and the storage 13. The electronic circuit 15 is a dedicated circuit for realizing the functions of each functional component, the memory 12, and the storage 13.

[0032] The electronic circuit 15 may be a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, a logic IC, a GA, an ASIC, or an FPGA. GA stands for Gate Array. ASIC stands for Application Specific Integrated Circuit. FPGA stands for Field-Programmable Gate Array. Each functional component may be realized by one electronic circuit 15, or each functional component may be realized by distributing it among a plurality of electronic circuits 15.

[0033] <Variation 2> As a second modification, some of the functional components may be realized by hardware, and other functional components may be realized by software.

[0034] The processor 11, memory 12, storage 13, and electronic circuit 15 are collectively referred to as a processing circuit. In other words, the functions of the respective functional components are realized by the processing circuit.

[0035] Embodiment 2 The second embodiment differs from the first embodiment in that the second embodiment improves the efficiency of setting requirements in the requirement data 31. In the second embodiment, this difference will be explained, and explanation of the same points will be omitted.

[0036] In the first embodiment, as shown in Fig. 2, requirements data 31 has duplicated requirements set in the requirement column of each row. For example, in Fig. 2, "requirement 1, requirement 2" is recorded in the requirement column of the first row, and "requirement 1, requirement 2" is also recorded in the requirement set columns of the second and fourth rows. In other words, the same requirement is entered in multiple rows. Therefore, the amount of data in requirement data 31 is large. In the second embodiment, an inclusion relationship is set between the individual classifications of personal data. Also, an inclusion relationship is set between the individual usage methods of personal data. Search rule 32 uses these two inclusion relationships to search requirement data 31. This eliminates the need to set the same requirement in multiple lines in requirement data 31.

[0037] The following is a specific example of an inclusion relationship between categories. Under Japan's Personal Information Protection Act, between "personal data" and "personal information," "personal data" is included in "personal information." In other words, "personal data" ⊆ "personal information." A specific example of an inclusion relationship between usage methods is as follows: Between "providing to a third party" and "handling," "providing to a third party" is included in "handling." In other words, "providing to a third party" ⊆ "handling."

[0038] ***Configuration Description*** The configuration of a requirement specifying device 10 according to the second embodiment will be described with reference to FIG. 1 in that inclusion information 33 is stored in the storage 13. The inclusion information 33 may be stored in a storage device external to the requirement identification device 10, similar to the requirement data 31 and the search rules 32.

[0039] ***Explanation of Operation*** The operation of the requirement identifying device 10 according to the second embodiment will be described with reference to FIGS. The operation procedure of the requirements identification device 10 according to the second embodiment corresponds to the requirements identification method according to the second embodiment. Moreover, the program that realizes the operation of the requirements identification device 10 according to the second embodiment corresponds to the requirements identification program according to the second embodiment.

[0040] The requirement data 31 according to the second embodiment will be described with reference to FIG. In the requirement data 31, a set of requirements is set for each combination of the classification of personal data and the method of using the personal data, as in the first embodiment, except that the requirement column is set to prevent duplication of the same requirement. Specifically, the requirements data 31 sets, for each combination of classification and usage method, requirements corresponding to that combination, excluding requirements corresponding to a superset, which is a combination in which at least one of the classification and usage method is a superset.

[0041] For example, "personal data" is included in "personal information." Therefore, in the second line of Figure 7, {Requirement 1, Requirement 2} set for "personal information" in the first line is excluded, and only {Requirement 3} is set. Also, "personal data" is included in "personal information," and "providing to a third party" is included in "handling." Therefore, in the fourth line of Figure 7, {Requirement 1, Requirement 2} set in the first line is excluded. Also, {Requirement 3} set in the second line is excluded. And only {Requirement 4} is set.

[0042] The inclusion information 33 according to the second embodiment will be described with reference to FIG. Inclusion relationships between categories and inclusion relationships between usage methods are set in the inclusion information 33. As long as the inclusion relationships can be expressed, the format in which they are set is arbitrary. In Figure 8, when X is included in Y, the inclusion relationship is set in the functional form of upper(X) = Y. For example, upper(personal data) = personal information indicates that personal data is included in personal information.

[0043] The search rule 32 according to the second embodiment will be described with reference to FIG. The search rule 32 is a rule for searching the requirement data 31 by using the inclusion relationship indicated by the inclusion information 33 .

[0044] The search rule 32 shown in FIG. 9 will be explained. The processing from step S21 to step S22 is the same as the processing from step S11 to step S12 in FIG.

[0045] Step S23: The inclusion information 33 is referenced to determine whether upper (C) has been defined. "Upper (C) has been defined" means that upper (C) is included in the inclusion information 33. For example, suppose that category C is "personal data." In this case, upper (personal data) is included in the inclusion information 33, so the determination result is "Yes." Suppose that category C is "personal information." In this case, upper (personal information) is not included in the inclusion information 33, so the determination result is "No." If the determination result is YES, the process proceeds to step S24, whereas if the determination result is NO, the process proceeds to step S25. Step S24: The search rule 32 is recursively executed. Specifically, the classification upper (C) is input in step S21, and the usage method M is input in step S22, and the search rule 32 is executed. Then, the output of step S30, which will be described later, is set in the requirement set S1. Step S25: An empty set φ is set to the requirement set S1.

[0046] Step S26: It is determined whether upper(M) has been defined by referring to the inclusion information 33. "Upper(M) has been defined" means that upper(M) is included in the inclusion information 33, just like in the case of upper(C). If the determination result is YES, the process proceeds to step S27, whereas if the determination result is NO, the process proceeds to step S . Step S27: The search rule 32 is recursively executed. Specifically, the classification C is input in step S21, and the usage method upper(M) is input in step S22, and the search rule 32 is executed. Then, the output of step S30, which will be described later, is set in the requirement set S2. Step S28: An empty set φ is set to the requirement set S2.

[0047] Step S29: As in step S13 of FIG. 3, the requirement data 31 is referenced, and a requirement set S of rows in which the classification is C and the usage method is M is obtained. Step S30: A union S1∨S2∨S3 of requirement sets S1, S2, and S3 is output. Here, when there are sets A and B, A∨B represents the union of sets A and B.

[0048] The flow of processing performed by the requirement identifying device 10 according to the second embodiment will be described with reference to FIG. Here, we will explain an example of acquiring a set of consideration requirements to be taken into account in a system that includes the process of "providing personal data to a third party." In this case, we will explain using requirement data 31 shown in Fig. 7, inclusion information 33 shown in Fig. 8, and search rules 32 shown in Fig. 9.

[0049] The processing from step S1 to step S3 is the same as in embodiment 1. Here, the classification receiving unit 21 receives "personal data" as the specified classification. The usage method receiving unit 22 receives "provide to a third party" as the specified method. The requirement identification unit 23 acquires the search rule 32 shown in FIG. 9.

[0050] (Step S4: Requirement identification process) The requirement specifying unit 23 executes the search rule 32 acquired in step S3 to specify a set of consideration requirements. Specifically, in step S21, the requirements identification unit 23 receives the specified classification received in step S1 as input. In step S22, the requirements identification unit 23 receives the specification method received in step S2 as input. In steps S23 to S29, the requirements identification unit 23 identifies requirement sets S1, S2, and S3. Then, in step S30, the requirements identification unit 23 outputs the union S1∨S2∨S3 of requirement sets S1, S2, and S3 as a set of consideration requirements.

[0051] <First rule begins> Search rule 32 is executed. The search rule 32 executed here is called the first rule. In the first rule, in step S21, the designated classification "personal data" is input as classification C. In step S22, the designated method "provide to a third party" is input as usage method M.

[0052] In step S23, since upper (personal data) has already been defined, the judgment result is YES. Therefore, the process proceeds to step S24. In step S24, search rule 32 is recursively executed using "upper (personal data)" as classification C and "provide to a third party" as usage method M as input. Upper (personal data) is "personal information." The search rule 32 executed here is called the second rule.

[0053] <Start of second rule> In the second rule, "personal information" which is upper (personal data) is input as classification C. "Provide to a third party" is input as usage method M. In step S23, since upper (personal information) has not been defined, the determination result is NO. Therefore, the process proceeds to step S25. In step S25, an empty set φ is set to the requirement set S1. In step S26, since upper (providing to a third party) has already been defined, the result of the judgment is YES. Therefore, the process proceeds to step S27. In step S27, search rule 32 is recursively executed using "personal information" as the classification C and upper (providing to a third party) as the usage method M as input. Upper (providing to a third party) is "handle." The search rule 32 executed here is called the third rule.

[0054] <The third rule begins> In the third rule, "personal information" is input as classification C. "Handling", which is upper (providing to a third party), is input as usage method M. In step S23, since upper (personal information) has not been defined, the determination result is NO. Therefore, the process proceeds to step S25. In step S25, an empty set φ is set to the requirement set S1. In step S26, since upper (handles) has not been defined, the result of the determination is NO. Therefore, the process proceeds to step S28. In step S28, an empty set φ is set to the requirement set S2. In step S29, the requirement data 31 shown in Figure 7 is referenced, and the requirement set of the row where the classification is "personal information" and the usage method is "handle" is identified. The identified requirement set is set as requirement set S3. Here, {requirement 1, requirement 2} in the first row of Figure 7 is set as requirement set S3. In step S30, requirement set S1 ∨ requirement set S2 ∨ requirement set S3 = φ ∨ φ ∨ {requirement 1, requirement 2} = {requirement 1, requirement 2} is output.

[0055] <Second Rule Resumption> In step S27, the output of the third rule, {requirement 1, requirement 2}, is set in requirement set S2. In step S29, the requirement data 31 shown in Figure 7 is referenced, and the requirement set of the row where the classification is "personal information" and the usage method is "provided to a third party" is identified. The identified requirement set is set as requirement set S3. Here, the empty set φ in the third row of Figure 7 is set as requirement set S3. In step S30, requirement set S1 ∨ requirement set S2 ∨ requirement set S3 = φ ∨ {requirement 1, requirement 2} ∨ φ = {requirement 1, requirement 2} is output.

[0056] <First rule resumption> In step S24, the output of the second rule, {requirement 1, requirement 2}, is set in the requirement set S1. In step S26, since upper (providing to a third party) has already been defined, the result of the judgment is YES. Therefore, the process proceeds to step S27. In step S27, search rule 32 is recursively executed using "personal data" as classification C and upper (providing to a third party) as usage method M as input. Upper (providing to a third party) is "handle." The search rule 32 executed in this step is called the fourth rule.

[0057] <The fourth rule begins> In the third rule, "personal data" is input as classification C. "Handling", which is upper (providing to a third party), is input as usage method M. In step S23, since upper (personal data) has already been defined, the judgment result is YES. Therefore, the process proceeds to step S24. In step S24, search rule 32 is recursively executed using "upper (personal data)" as classification C and "handle" as usage method M as input. Upper (personal data) is "personal information." The search rule 32 executed here is called the fifth rule.

[0058] <5th Rule Begins> The processing of the fifth rule is the same as the processing of the third rule. Therefore, just like the third rule, {requirement 1, requirement 2} is output in step S30.

[0059] <4th Rule Restart> In step S24, the output of the fifth rule, {requirement 1, requirement 2}, is set in the requirement set S1. In step S26, since upper (handles) has not been defined, the result of the determination is NO. Therefore, the process proceeds to step S28. In step S28, an empty set φ is set to the requirement set S2. In step S29, the requirement data 31 shown in Figure 7 is referenced, and a requirement set of a row in which the classification is "personal data" and the usage method is "handle" is identified. The identified requirement set is set as requirement set S3. Here, {requirement 3} in the second row of Figure 7 is set as requirement set S3. In step S30, requirement set S1 ∨ requirement set S2 ∨ requirement set S3 = {requirement 1, requirement 2} ∨φ ∨ {requirement 3} = {requirement 1, requirement 2, requirement 3} is output.

[0060] <First rule resumption> In step S27, the output of the fourth rule, {requirement 1, requirement 2, requirement 3}, is set in requirement set S2. In step S29, the requirement data 31 shown in Figure 7 is referenced, and a requirement set in a row where the classification is "personal data" and the usage method is "provided to a third party" is identified. The identified requirement set is set as requirement set S3. Here, {requirement 4} in the fourth row of Figure 7 is set as requirement set S3. In step S30, requirement set S1 ∨ requirement set S2 ∨ requirement set S3 = {requirement 1, requirement 2} ∨ {requirement 1, requirement 2, requirement 3} ∨ {requirement 4} = {requirement 1, requirement 2, requirement 3, requirement 4} is output.

[0061] As described above, when the search rule 32 shown in FIG. 9 is used, the same results as when the search rule 32 shown in FIG. 3 is used are obtained.

[0062] ***Effects of the Second Embodiment*** As described above, the requirement identification device 10 according to the second embodiment can efficiently set requirements in the requirement data 31 by using the inclusion relationship between the classification and the usage method. This makes it possible to reduce the amount of data in the requirement data 31.

[0063] Embodiment 3 The third embodiment differs from the second embodiment in that there are mutually contradictory requirements. In the third embodiment, this difference will be explained, and explanation of the same points will be omitted.

[0064] In the second embodiment, the union of requirement set S1, requirement set S2, and requirement set S3 is output in step S30 of search rule 32. However, requirement set S1, requirement set S2, and requirement set S3 may contain contradictory requirements. For example, suppose requirement set S1 is {"obtain the individual's consent or make public the purpose of use"}, requirement set S2 is {"consent must be obtained from the individual"}, and requirement set S3 is the empty set φ. In this case, taking the union will output {"obtain the individual's consent or make public the purpose of use"} ∨ {"consent must be obtained from the individual"} ∨ φ = {"obtain the individual's consent or make public the purpose of use", "consent must be obtained from the individual"}. The requirement "obtain the individual's consent or make public the purpose of use" and the requirement "consent must be obtained from the individual" included in this output are contradictory.

[0065] In the third embodiment, a tag is attached to each requirement in advance. When performing calculations on the requirement sets S1, S2, and S3, the tags are used to perform calculations that take into account conflict resolution. This prevents the occurrence of conflicts such as those described above.

[0066] ***Explanation of Operation*** The operation of the requirement identifying device 10 according to the third embodiment will be described with reference to FIGS. The operation procedure of the requirements identification device 10 according to the third embodiment corresponds to the requirements identification method according to the third embodiment. Moreover, the program that realizes the operation of the requirements identification device 10 according to the third embodiment corresponds to the requirements identification program according to the third embodiment.

[0067] The requirement data 31 according to the third embodiment will be described with reference to FIG. In the requirement data 31, a set of requirements is set for each combination of the classification of personal data and the method of using the personal data, as in the first embodiment, except that the requirements set in the requirement column are tagged requirements. Here, the requirements X (X=1, 2, 3, 4) shown in FIG. 7 are tagged and changed to requirements Y (Y=A, B, C, D).

[0068] The tagging according to the third embodiment will be described with reference to FIG. Requirement Y includes content and a tag. The content is requirement X shown in Fig. 7. The tag is information attached to requirement X. For example, requirement A has content of requirement 1 and tag a.

[0069] The process of step S30 of the search rule 32 shown in FIG. 9 will be described. In step S30, the tags are used to resolve contradictions in the requirements, where a set of requirements S1 OR*, a set of requirements S2 OR*, and a set of requirements S3 are calculated. Here, when there are requirement sets A and B, A OR* B = {a_i|a_i∈A, a_i's tag does not belong to {b_j's tag|b_j∈B}} ∨ B. In other words, when there are requirement sets A and B, if the tag of requirement a_i included in requirement set A matches the tag of any requirement b_j in requirement set B, requirement a_i is removed and the union is calculated.

[0070] For example, suppose that a set of requirements is obtained, where S1={requirement A, requirement B}, S2={requirement C}, and S3=φ. In this case, requirement A and requirement C are in contradiction. Each requirement is tagged as shown in Figure 11. Then, in step S30, the following calculation is performed: Requirement set S1 OR* Requirement set S2 OR* Requirement set S3 ={Requirement A, Requirement B} OR* {Requirement C} OR* φ ={Requirement A:{Content:"Requirement 1",Tag:"Tag a"},Requirement B:{Content:"Requirement 2",Tag:"Tag b"}}OR*{Requirement C:{Content:"Requirement 3",Tag:"Tag a"}}OR*φ ={Requirement B:{Content:”Requirement 2”,Tag:”Tag b”},Requirement C:{Content:”Requirement 3”,Tag:”Tag a”}} ={Requirement B, Requirement C} That is, among requirements A and C that include the same tag a, requirement A included in the previous requirement set S1 is excluded. As a result, the two contradictory requirements A and C are not included in the calculation result.

[0071] In the search rule 32 shown in Figure 9, the requirement set obtained by changing the classification to a superset is requirement set S1. Similarly, the requirement set obtained by changing the usage method to a superset is requirement set S2. Therefore, when the requirements included in the previous requirement set are removed from among multiple requirements that include the same tag, only the requirements that correspond to the lowest set among the requirements with the same tag remain.

[0072] As described above, when there are mutually incompatible and contradictory requirements, the requirement specifying device 10 according to the third embodiment can output a set of consideration requirements in which the contradictions are resolved.

[0073] In addition, the word "unit" in the above description may be read as a "circuit," "step," "procedure," "process," or "processing circuit."

[0074] The embodiments and modifications of the present disclosure have been described above. Some of these embodiments and modifications may be combined and implemented. Also, one or more of them may be implemented partially. Note that the present disclosure is not limited to the above embodiments and modifications, and various modifications are possible as needed.

[0075] Various aspects of the present disclosure are summarized below as appendices. (Appendix 1) a classification receiving unit that receives a designated classification that is a classification of personal data; a usage method receiving unit that receives a designated method, which is a method of using the personal data; a requirement specifying unit that specifies consideration requirements to be considered regarding the use of the personal data, corresponding to the designated classification accepted by the classification accepting unit and the designated method accepted by the usage method accepting unit; A requirements specification device comprising: (Appendix 2) The requirement specification unit specifies the consideration requirements by specifying the requirements corresponding to the combination of the designated classification and the designated method from requirement data that stores requirements to be considered for each combination of the classification and the usage method. Requirement identification device as described in Appendix 1. (Appendix 3) an inclusion relationship is defined between the classification and the usage method; In the requirement data, for each of the combinations, requirements corresponding to the combinations are set, excluding requirements corresponding to superset combinations that are combinations that superset at least one of the classifications and the usage methods, The requirement specification unit specifies the requirements corresponding to a combination of the designated classification and the designation method from the requirement data, and specifies the requirements corresponding to each superset combination obtained by changing at least one of the designated classification and the designation method to a superset, thereby specifying the consideration requirements. Requirement identification device as described in Appendix 2. (Appendix 4) The requirement identification unit sets a combination of the specified classification and the specified method as a target combination, and then identifies a superordinate combination as a new target combination when the classification in the target combination is changed to a superordinate set, and identifies a superordinate combination as a new target combination when the usage method in the target combination is changed to a superordinate set, recursively, thereby identifying each superordinate combination. Requirement identification device as described in Appendix 3. (Appendix 5) The requirements are tagged, The requirement specifying unit includes only one of the identified requirements having the same tag in the consideration requirements. Requirement identification device as described in Appendix 3 or 4. (Appendix 6) The requirement specifying unit includes only requirements corresponding to the lowest set among the requirements tagged with the same tag in the consideration requirements. Requirement identification device as described in Appendix 5. (Appendix 7) The computer accepts the designated classification, which is the classification of personal data, The computer receives a designated method for using the personal data, A requirements specification method in which a computer specifies requirements to be considered regarding the use of the personal data, which correspond to the specified classification and the specified method. (Appendix 8) A classification reception process for receiving a designated classification that is a classification of personal data; a usage method reception process for receiving a designated method, which is a method of using the personal data; a requirement specification process for specifying requirements to be considered regarding the use of the personal data, which correspond to the designated classification accepted by the classification acceptance process and the designated method accepted by the usage method acceptance process; A requirements identification program as a requirements identification device. [Explanation of symbols]

[0076] 10 Requirement identification device, 11 Processor, 12 Memory, 13 Storage, 14 Communication interface, 15 Electronic circuit, 21 Classification reception unit, 22 Usage method reception unit, 23 Requirement identification unit, 31 Requirement data, 32 Search rules, 33 Containment information.

Claims

1. a classification receiving unit that receives a designated classification that is a classification of personal data; a usage method receiving unit that receives a designated method, which is a method of using the personal data; a requirement specifying unit that specifies requirements that should be considered regarding the use of the personal data by specifying requirements that correspond to the designated category accepted by the category accepting unit and the designated method accepted by the use method accepting unit from requirement data that stores requirements that should be considered for each combination of the category and the use method; A requirements specification device comprising:

2. an inclusion relationship is defined between the classification and the usage method; In the requirement data, for each of the combinations, requirements corresponding to the combinations are set, excluding requirements corresponding to superset combinations that are combinations that superset at least one of the classifications and the usage methods, The requirement specification unit specifies the requirements corresponding to a combination of the designated classification and the designation method from the requirement data, and specifies the requirements corresponding to each superset combination obtained by changing at least one of the designated classification and the designation method to a superset, thereby specifying the consideration requirements. The requirements identification device according to claim 1 .

3. The requirement identification unit sets a combination of the specified classification and the specified method as a target combination, and then identifies a superordinate combination as a new target combination when the classification in the target combination is changed to a superordinate set, and identifies a superordinate combination as a new target combination when the usage method in the target combination is changed to a superordinate set, recursively, thereby identifying each superordinate combination. The requirements specification device according to claim 2 .

4. The requirements are tagged, The requirement specifying unit includes only one of the identified requirements having the same tag in the consideration requirements.

4. The requirement specifying device according to claim 2 or 3.

5. The requirement specifying unit includes only requirements corresponding to the lowest set among the requirements tagged with the same tag in the consideration requirements. The requirements specification device according to claim 4.

6. The computer accepts the designated classification, which is the classification of personal data, The computer receives a designated method for using the personal data, A requirements identification method in which a computer identifies requirements that should be taken into consideration regarding the use of personal data by identifying requirements that correspond to the specified classification and the specified method from requirements data that stores requirements that should be taken into consideration for each combination of the classification and the method of use.

7. A classification reception process for receiving a designated classification that is a classification of personal data; a usage method reception process for receiving a designated method, which is a method of using the personal data; a requirement specification process for specifying requirements that should be considered regarding the use of the personal data by specifying requirements that correspond to the designated category accepted by the classification acceptance process and the designated method accepted by the usage method acceptance process from requirement data that stores requirements that should be considered for each combination of the category and the usage method; A requirements specification program that causes a computer to function as a requirements specification device that performs the above.

Images