JP7809018B2 - Requirement identification device, requirement identification method, and requirement identification program - Google Patents

Description

This disclosure relates to technology for identifying requirements to be considered regarding the use of personal data.

With the development of internet technology, businesses are increasingly collecting and utilizing personal data. Accordingly, various countries are enacting legal systems regarding personal data. 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 determine which of the requirements written in legal systems regarding personal data should be taken into consideration in the systems they develop.

Patent Document 1 describes a device for streamlining requirements extraction work. In this device, requirements extraction conditions are stored in association with requirement types that match the requirements extraction conditions. The requirements extraction conditions are used to determine whether requirements related to a processing system for performing legal processing are included in the provisions of the law.

JP 2012-203725 A

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 the system and the method of using that personal data. In Patent Document 1, only the data name and the type of requirement are considered. 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.

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;
The system is equipped with a requirement specification unit that specifies considerations that should be taken into account regarding the use of the personal data, corresponding to the designated classification accepted by the classification acceptance unit and the designated method accepted by the usage method acceptance unit.

In this disclosure, designated classifications, which are classifications of personal data, are used to identify the requirements for consideration. This makes it possible to efficiently identify the legal requirements for personal data that should be considered.

FIG. 1 is a configuration diagram of a requirement specifying device 10 according to a first embodiment. FIG. 3 is an explanatory diagram of requirement data 31 according to the first embodiment. FIG. 3 is an explanatory diagram of a search rule 32 according to the first embodiment. 4 is a flowchart showing the flow of processing by the requirement identifying device 10 according to the first embodiment. FIG. 10 is a configuration diagram of a requirement specifying device 10 according to a first modified example. FIG. 10 is a configuration diagram of a requirement specifying device 10 according to a second embodiment. FIG. 10 is an explanatory diagram of requirement data 31 according to the second embodiment. FIG. 10 is an explanatory diagram of inclusion information 33 according to the second embodiment. FIG. 10 is an explanatory diagram of a search rule 32 according to the second embodiment. FIG. 11 is an explanatory diagram of requirement data 31 according to the third embodiment. FIG. 11 is an explanatory diagram of tagging according to the third embodiment.

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 identification device 10 is a computer.
The requirement identification device 10 includes the following hardware components: a processor 11, a memory 12, a storage 13, and a communication interface 14. The processor 11 is connected to other hardware components via signal lines and controls the other hardware components.

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

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

Storage 13 is a storage device that stores data. A specific example of storage 13 is an HDD. HDD stands for Hard Disk Drive. 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 stands for Secure Digital. DVD stands for Digital Versatile Disk.

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.

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 programs that realize the functions of the functional components of the requirements identification device 10. These programs are loaded into the memory 12 by the processor 11 and executed by the processor 11. As a result, the functions of the functional components of the requirements identification device 10 are realized.

Storage 13 stores requirement data 31 and search rules 32. Note that requirement data 31 and search rules 32 may be stored in a storage device external to the requirement identification device 10.

In Figure 1, only one processor 11 is shown. However, there may be multiple processors 11, and the multiple processors 11 may work together to execute programs that realize each function.

***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 requirements identification device 10 according to the first embodiment corresponds to the requirements identification method according to the first embodiment. Moreover, the program that realizes the operation of the requirements identification device 10 according to the first embodiment corresponds to the requirements identification program according to the first embodiment.

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,""personaldata," 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."

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""personalinformation" on the system is {Requirement 1, Requirement 2}. In other words, when "handling""personalinformation" 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.

The search rule 32 according to the first embodiment will be described with reference to FIG.
The search rule 32 is a rule that defines a method for searching the requirement data 31 and identifying a set of considerations that should be taken into account when using personal data. The search rule 32 receives as input the classification of personal data and the method of use of the personal data. The 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.

The search rule 32 shown in FIG. 3 will be described.
Step S11: Class 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.

The flow of processing by the requirement identifying device 10 according to the first embodiment will be described with reference to FIG.
Here, an example will be described in which a set of consideration requirements to be taken into account in a system including a process of "providing personal data to a third party." In this case, the explanation will be given assuming that requirement data 31 shown in Fig. 2 and search rules 32 shown in Fig. 3 are used.

(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.

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

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

(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 the designated classification received in step S1 as input. In step S12, the requirements identification unit 23 receives the designated method received in step S2 as input. In step S13, the requirements identification unit 23 refers to the requirements data 31 to identify a requirements set S of rows in which 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.

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 requirements data 31 shown in Figure 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 the set of consideration requirements.

(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."

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

***Other configurations***
<Modification 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 following describes the differences between the first embodiment and the first modification.

The configuration of the requirement specifying 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.

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.

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

The processor 11, memory 12, storage 13, and electronic circuit 15 are collectively referred to as the processing circuit. In other words, the functions of each functional component are realized by the processing circuit.

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.

In the first embodiment, as shown in Fig. 2, the requirement 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 the 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. The search rule 32 uses these two inclusion relationships to search the requirement data 31. This eliminates the need to set the same requirement in multiple lines in the requirement data 31.

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,""personaldata" 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."

***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 requirements identification device 10, similar to the requirements data 31 and the search rules 32.

***Explanation of Operation***
The operation of the requirement specifying 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.

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 in such a way that duplication of the same requirement is suppressed.
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.

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.
Furthermore, "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.

The inclusion information 33 according to the second embodiment will be described with reference to FIG.
The inclusion relationships between the categories and the inclusion relationships between the usage methods are set in the inclusion information 33. The format for setting the inclusion relationships is arbitrary as long as the inclusion relationships can be expressed.
In Fig. 8, when X is included in Y, the inclusion relationship is set in the form of a function, upper(X) = Y. For example, upper(personal data) = personal information indicates that personal data is included in personal information.

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 .

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

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 upper classification (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 (described later) is set in the requirement set S1.
Step S25: An empty set φ is set to the requirement set S1.

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

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.

The flow of processing by the requirement specifying device 10 according to the second embodiment will be described with reference to FIG.
Here, an example will be described in which a set of consideration requirements to be taken into account in a system including a process of "providing personal data to a third party." In this case, the explanation will be given assuming that requirement data 31 shown in Fig. 7, inclusion information 33 shown in Fig. 8, and search rules 32 shown in Fig. 9 are used.

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 Figure 9.

(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 requirement identification unit 23 receives the designated classification received in step S1 as input. In step S22, the requirement identification unit 23 receives the designation method received in step S2 as input. In steps S23 to S29, the requirement identification unit 23 identifies requirement sets S1, S2, and S3. Then, in step S30, the requirement identification unit 23 outputs the union S1∨S2∨S3 of requirement sets S1, S2, and S3 as a set of consideration requirements.

<First rule begins>
The 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.

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. Upper (personal data) is "personal information." The search rule 32 executed here is called the second rule.

<Second rule begins>
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 (provided to a third party) has already been defined, the result of the determination 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 (provided to a third party) as the usage method M as input. Upper (provided to a third party) is "handle." The search rule 32 executed here is called the third rule.

<The third rule begins>
In the third rule, "personal information" is input as the classification C. "Handling", which is upper (providing to a third party), is input as the 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 (handled) 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 FIG. 7 is referenced, and a requirement set of a row in which 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 FIG. 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.

<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 FIG. 7 is referenced, and a requirement set in a row in which 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 FIG. 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.

<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 (provided to a third party) has already been defined, the result of the determination is YES. Therefore, the process proceeds to step S27. In step S27, search rule 32 is recursively executed using "personal data" as the classification C and upper (provided to a third party) as the usage method M as input. Upper (provided to a third party) is "handle." The search rule 32 executed in this step is called the fourth rule.

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

<The fifth rule begins>
The processing of the fifth rule is the same as the processing of the third rule, so as with the third rule, {requirement 1, requirement 2} is output in step S30.

<Fourth Rule Resumption>
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 (handled) 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 FIG. 7 is referenced, and a requirement set in a row where 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 FIG. 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.

<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 FIG. 7 is referenced, and a requirement set in a row in which 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 FIG. 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.

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

***Effects of the Second Embodiment***
As described above, the requirements identification device 10 according to the second embodiment can efficiently set requirements in the requirements data 31 by using the inclusion relationships of the classifications and usage methods. This makes it possible to reduce the amount of data in the requirements data 31.

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.

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

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

***Explanation of Operation***
The operation of the requirement specifying 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.

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. However, 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).

Referring to FIG. 11, tagging according to the third embodiment will be described.
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.

The process of step S30 of the search rule 32 shown in FIG. 9 will be described.
In step S30, the contradictions in the requirements are resolved using the tags, where a requirement set S1 OR*, a requirement set S2 OR*, and a requirement set 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.

For example, suppose a set of requirements is obtained, where S1 = {requirement A, requirement B}, S2 = {requirement C}, and S3 = φ. In this case, it is assumed that requirement A and requirement C are in contradiction. Each requirement is tagged as shown in FIG. 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.

In the search rule 32 shown in Figure 9, the set of requirements obtained by changing the classification to a superset becomes requirement set S1. Furthermore, the set of requirements obtained by changing the usage method to a superset becomes requirement set S2. Therefore, when requirements included in the previous requirement set are removed from among multiple requirements that contain the same tag, only the requirements corresponding to the lowest set of requirements with the same tag remain.

As described above, the requirements identification device 10 according to embodiment 3 can output a set of consideration requirements that resolves contradictions when mutually incompatible, contradictory requirements exist.

Note that the word "part" in the above description may also be interpreted as "circuit," "process," "procedure," "processing," or "processing circuit."

The above describes embodiments and variations of the present disclosure. Some of these embodiments and variations may be implemented in combination. Furthermore, one or more of them may be implemented partially. Note that the present disclosure is not limited to the above embodiments and variations, and various modifications are possible as needed.

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 requirements identification device comprising: a requirements identification unit that identifies considerations that should be taken into account regarding the use of the personal data, corresponding to the designated classification accepted by the classification acceptance unit and the designated method accepted by the usage method acceptance unit.
(Appendix 2)
The requirements identification unit is a requirements identification device described in Appendix 1 that identifies the requirements to be considered by identifying the requirements corresponding to the combination of the specified classification and the specified method from requirements data that stores requirements to be considered for each combination of the classification and the usage method.
(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 requirements identification unit identifies the requirements corresponding to the combination of the designated classification and the designated method from the requirements data, and identifies the requirements corresponding to each higher-level combination obtained by changing at least one of the designated classification and the designated method to a higher-level set, thereby identifying the requirements to be considered.
(Appendix 4)
The requirements identification unit sets a combination of the specified classification and the specified method as a target combination, and then recursively identifies a higher-level combination when the classification of the target combination is changed to a higher-level set as a new target combination, and also identifies a higher-level combination when the usage method of the target combination is changed to a higher-level set as a new target combination, thereby identifying each higher-level combination.
(Appendix 5)
The requirements are tagged,
5. The requirements identification device according to claim 3, wherein the requirements identification unit includes only one of the identified requirements that have the same tag attached thereto as the consideration requirements.
(Appendix 6)
6. The requirements identification device according to claim 5, wherein the requirements identification unit includes, as the consideration requirements, only requirements that correspond to the lowest set among the requirements tagged with the same tag.
(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 requirements identification program as a requirements identification device that performs a requirements identification process to identify considerations that should be taken into account regarding the use of the personal data, corresponding to the designated classification accepted by the classification acceptance process and the designated method accepted by the usage method acceptance process.

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 (7)

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 requirements identification device comprising: a requirements identification unit that identifies requirements that should be taken into consideration regarding the use of the personal data by identifying requirements that correspond to the designated classification accepted by the classification acceptance unit and the designated method accepted by the usage method acceptance unit from requirements data that stores requirements that should be taken into consideration for each combination of the classification and the usage method. 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 requirements identification device according to claim 1, wherein the requirements identification unit identifies the requirements corresponding to the combination of the designated classification and the designated method from the requirements data, and identifies the requirements corresponding to each superset combination obtained by changing at least one of the designated classification and the designated method to a superset, thereby identifying the consideration requirements. 3. The requirements identification device according to claim 2, wherein the requirements identification unit sets a combination of the specified classification and the specified method as a target combination, and then recursively identifies a higher-level combination as a new target combination when the classification of the target combination is changed to a higher-level set, and also identifies a higher-level combination as a new target combination when the usage method of the target combination is changed to a higher-level set . The requirements are tagged,
4. The requirements identification device according to claim 2 , wherein the requirements identification unit includes, among the identified requirements, only one requirement that has the same tag attached thereto as the consideration requirements. The requirements identification device according to claim 4 , wherein the requirements identification unit includes, as the consideration requirements, only requirements that correspond to a lowest set among requirements tagged with the same tag. 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. 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 requirements identification program that causes a computer to function as a requirements identification device that performs a requirements identification process that identifies requirements that should be taken into consideration regarding the use of the personal data by identifying requirements that correspond to the designated classification accepted by the classification acceptance process and the designated method accepted by the usage method acceptance process from requirements data that stores requirements that should be taken into consideration for each combination of the classification and the usage method.