Abnormality detector, method for detecting abnormality, and abnormality detection program

Abstract

To confirm the operation situation of abnormality detection.SOLUTION: An alert definition setting unit sets an alert definition and an alert definition execution unit executes the set alert definition. An execution result generation unit determines an abnormality of an alert target on the basis of the result of executing the alert definition and generates the result of determination by the abnormality determination. An execution history generation unit generates an execution history of the executed alert definition. An output control unit controls output of the generated determination result and the execution history to an output apparatus. A manager such as an inside control manager thus can confirm the operation situation of abnormality detection on the basis of the execution history of the alert definition.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to an anomaly detection device, an anomaly detection method, and an anomaly detection program. [Background technology]

[0002] Patent Document 1 (JP 2019-135602 A) discloses an information management system that associates work data before and after a correction that has been registered and determines the legitimacy of the correction.

[0003] This information management system holds data, and holds in a storage device rule information including multiple pairs of rules to be applied to the data and first indices indicating the validity of a difference between two pieces of data that conform to the rules. When new data is input, a processor identifies rules included in the rule information that conform to the new data and data held in the storage device, and sums the first indices corresponding to the identified rules. The processor then determines the validity of a difference between the two pieces of data based on the sum of the first indices, and outputs the result of the validity determination and the basis for the validity determination. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2019-135602 A Summary of the Invention [Problem to be solved by the invention]

[0005] In recent years, there has been an increasing trend of fraudulent acts on business data such as accounting or auxiliary ledgers. In response to this, there is a demand for the development of an anomaly detection device that automatically detects anomalies in business data. The anomaly detection device automatically judges anomalies, and depending on the judgment result, a person in charge such as a business checker judges whether the anomaly is due to a deterioration in the business situation or due to an intentional fraudulent act, and takes the necessary measures.

[0006] An internal control manager or other responsible person must check whether such operations are being carried out correctly, but if there is no data that can be used to check the operational status, it becomes difficult to check the operational status of anomaly detection.

[0007] The present invention has been made in consideration of the above-mentioned problems, and aims to provide an anomaly detection device, an anomaly detection method, and an anomaly detection program that enable the operational status of anomaly detection to be confirmed. [Means for solving the problem]

[0008] In order to solve the above-mentioned problems and achieve the object, the anomaly detection device of the present invention has an alert definition setting unit that sets an alert definition, an alert definition execution unit that executes the set alert definition, an execution result generation unit that performs an anomaly judgment for the alert target based on the execution result of the alert definition and generates a judgment result based on the anomaly judgment, an execution history generation unit that generates an execution history of the executed alert definition, and an output control unit that controls output of the generated judgment result and execution history to an output device.

[0009] Furthermore, in order to solve the above-mentioned problems and achieve the object, the anomaly detection method according to the present invention includes an alert definition setting step in which an alert definition setting unit sets an alert definition, an alert definition execution step in which an alert definition execution unit executes the set alert definition, an execution result generation step in which an execution result generation unit performs an anomaly determination for the alert target based on the execution result of the alert definition and generates a determination result based on the anomaly determination, an execution history generation step in which an execution history generation unit generates an execution history of the executed alert definition, and an output control step in which an output control unit controls the output of the generated determination result and execution history to an output device.

[0010] Furthermore, in order to solve the above-mentioned problems and achieve the object, the anomaly detection program of the present invention causes a computer to function as an alert definition setting unit that sets an alert definition, an alert definition execution unit that executes the set alert definition, an execution result generation unit that performs an anomaly judgment on the alert target based on the execution result of the alert definition and generates a judgment result based on the anomaly judgment, an execution history generation unit that generates an execution history of the executed alert definition, and an output control unit that controls the output of the generated judgment result and execution history to an output device. Effect of the Invention

[0011] The present invention can confirm the operational status of anomaly detection. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a block diagram illustrating a hardware configuration of an anomaly detection device according to an embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of the preset data table. [Diagram 3] FIG. 3 is a diagram illustrating an example of the alert definition table. [Figure 4] FIG. 4 is a diagram illustrating an example of the alert definition group table. [Diagram 5] FIG. 5 is a diagram illustrating an example of the alert definition group member table. [Figure 6]FIG. 6 is a diagram illustrating an example of the alert execution history detail table. [Figure 7] FIG. 7 is a diagram illustrating an example of the determination result table. [Figure 8] FIG. 8 is a diagram illustrating an example of the volume forecast alert result table. [Figure 9] FIG. 9 is a diagram showing an example of the assumed cost alert result table. [Figure 10] FIG. 10 is a diagram showing an example of the determination result message data. [Figure 11] FIG. 11 is a diagram showing an example of the determination result comment table. [Figure 12] FIG. 12 is a diagram illustrating an example of a definition change history data table. [Figure 13] FIG. 13 is a diagram illustrating an example of an alert definition history data table. [Figure 14] FIG. 14 is a diagram illustrating an example of an alert definition generation management table. [Figure 15] FIG. 15 is a diagram illustrating an example of the alert definition history table. [Figure 16] FIG. 16 is a diagram showing an example of the alert security history data table. [Figure 17] FIG. 17 is a diagram illustrating an example of the alert definition security generation management table. [Figure 18] FIG. 18 is a diagram illustrating an example of the alert definition group security generation management table. [Figure 19] FIG. 19 is a diagram illustrating an example of a user-defined relationship history table. [Figure 20] FIG. 20 is a diagram showing an example of a user group definition relation history table, a user definition group relation history table, and a user group definition group relation history table. [Figure 21] FIG. 21 is a diagram showing an example of the algorithm setting screen. [Figure 22]FIG. 22 is a diagram illustrating an example of settings of the alert definition generation management table and the alert definition history table. [Figure 23] FIG. 23 is a diagram showing an example of inputting changes to an alert definition based on the algorithm setting screen. [Figure 24] FIG. 24 is a diagram for explaining the update process of the alert definition generation management table and the alert definition history table when a change to the alert definition is input. [Diagram 25] FIG. 25 is a diagram showing an example of the security registration screen. [Figure 26] FIG. 26 is a diagram illustrating an example of an alert definition security generation management table, a user definition relation history table, and a user group definition relation history table. [Figure 27] FIG. 27 is a diagram showing an example of security change input based on the security registration screen. [Figure 28] FIG. 28 is a diagram for explaining the update process of the alert definition security generation management table, the user definition relation history table, and the user group definition relation history table when a security change is input. [Figure 29] FIG. 29 is a diagram for explaining the abnormality determination operation. [Diagram 30] FIG. 30 is a diagram showing an example of displaying the abnormality determination result. [Diagram 31] FIG. 31 is a diagram showing an example of an abnormal value determination result table to which input is made based on an abnormality determination result, and a determination result comment table to which a comment on the abnormality determination result is input. [Diagram 32] FIG. 32 is a diagram showing an example of an alert AI operation status confirmation screen. [Diagram 33] FIG. 33 is a diagram for explaining details of the filter section of the alert AI operation status confirmation screen. [Diagram 34] FIG. 34 is a diagram for explaining details of the message section of the alert AI operation status confirmation screen. [Diagram 35]FIG. 35 is a diagram showing data of various tables acquired when displaying the execution status of the alert definition on the alert AI operation status confirmation screen. [Diagram 36] FIG. 36 is a diagram showing the display form of various graphs indicating that the alert definition is being executed normally. [Figure 37] FIG. 37 is a diagram showing the display form of a graph when an alert definition is not executed normally. [Figure 38] FIG. 38 is a diagram showing data of various tables acquired when displaying the abnormality detection status on the alert AI operation status confirmation screen. [Figure 39] FIG. 39 is a diagram showing data of another table acquired when displaying the abnormality detection status on the alert AI operation status confirmation screen. [Diagram 40] FIG. 40 is a diagram showing the display form of the graph when anomaly detection is being performed normally. [Diagram 41] FIG. 41 is a diagram showing the display form of the graph when anomaly detection is not performed normally. [Diagram 42] FIG. 42 is a diagram showing data of various tables acquired when displaying details of anomaly detection status on the alert AI operation status confirmation screen. [Diagram 43] FIG. 43 is a diagram showing data of another table acquired when displaying details of anomaly detection status on the alert AI operation status confirmation screen. [Diagram 44] FIG. 44 is a diagram showing data of various tables acquired when displaying the monthly response status of anomalies on the alert AI operation status confirmation screen. [Diagram 45] FIG. 45 is a diagram showing other data of various tables acquired when displaying the monthly response status of anomalies on the alert AI operation status confirmation screen. [Figure 46] FIG. 46 is a graph showing a case where a detected abnormality is dealt with normally. [Figure 47] FIG. 47 is a graph showing a case where a detected abnormality is not properly dealt with. [Figure 48] FIG. 48 is a diagram showing data of various tables acquired when generating an alert definition change history. [Figure 49] FIG. 49 is a diagram showing data of various other tables acquired when generating the alert definition change history. [Figure 50] FIG. 50 is a diagram showing an example of an alert definition change history etc. when an alert definition has been changed normally. [Figure 51] FIG. 51 is a diagram showing an example of an alert definition change history etc. when an alert definition has not been changed normally. [Figure 52] FIG. 52 is a diagram for explaining the generation of security generation management data. [Figure 53] FIG. 53 is a diagram for explaining the generation of the change detailed data. [Figure 54] FIG. 54 is a diagram showing an example of the alert security change history etc. [Figure 55] FIG. 55 is a diagram showing an example of an alert security change history etc., showing a normal change example of security. [Figure 56] FIG. 56 is a diagram showing an example of an alert security change history showing an example of an unauthorized change in security. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An anomaly detection device according to an embodiment of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that the present invention is not limited to the following embodiment.

[0014] (Hardware configuration) 1, an anomaly detection device 1 according to an embodiment includes a storage unit 2, a control unit 3, a communication interface unit 4, and an input / output interface unit 5. An input device 6 and an output device 7 are connected to the input / output interface unit 5. The output device 7 corresponds to a display unit of a monitor device (including a home television), a printing device, a speaker device, or the like. The input device 6 may be a keyboard device, a mouse device, a microphone device, or a monitor device that cooperates with a mouse device to realize a pointing device function.

[0015] The communication interface unit 4 is connected to a network 35, for example, a wide area network such as the Internet or a private network such as a LAN (Local Area Network). An accounting server device 36 in which business data such as accounting or auxiliary ledgers is stored is connected to the network 35. The anomaly detection device 1 of the embodiment performs anomaly detection processing based on a predetermined alert definition, as described below, on the business data stored in the accounting server device 36 or the business data acquired from the accounting server device 36 and stored in the storage unit 2.

[0016] A storage device such as a ROM (Read Only Memory), a RAM (Random Access Memory), an HDD (Hard Disk Drive), or an SSD (Solid State Drive) can be used as the storage unit 2. The storage unit 2 stores an anomaly detection program that detects anomalies in business data such as accounting or auxiliary ledgers, and generates data that allows the operational status of the anomaly detection to be confirmed, thereby enabling the operational status of the anomaly detection to be confirmed.

[0017] The storage unit 2 also stores a preset data table 11, an alert execution history detail table 12, a judgment result table 13, and a definition change history data table 14, which will be described later. Note that the "tables" are the respective storage areas provided within the storage unit 2 (or may be within an external memory, etc.).

[0018] As shown in FIG. 2, the pre-configured data table 11 includes an alert definition table 51, an alert definition group table 52, an alert definition group member table 53, an alert definition generation management table 54, and an alert definition history table 55.

[0019] The alert definition table 51 is a table that manages the settings of the algorithm used for judgment or the update contents of the judgment result, and is composed of a definition number (definition ID), a definition code (definition CD), a definition name, a result table name, an algorithm used for anomaly detection, such as the approximation curve method or the Hotelling method, and a definition of the algorithm, as shown in FIG.

[0020] The alert definition group table 52 is a table for managing groups of alert definitions, and includes a definition group ID and a definition group name as shown in Fig. 4. The alert definition group member table 53 is a table for managing alert definitions belonging to alert definition groups, and includes a definition group ID and a definition ID as shown in Fig. 5.

[0021] The alert execution history detail table 12 is a table that manages summary information of the determination of whether the executed anomaly detection was completed normally or not, and the execution information is updated every time an abnormal value determination is executed based on the alert definition. Fig. 6 is a diagram showing the alert execution history detail data stored in the alert execution history detail table 12. As shown in Fig. 6, the alert execution history detail table 12 stores alert execution history detail data such as the execution history detail ID, definition code, alert definition name, status (normal completion or error), number of data items, number of abnormal items, number of normal items, and update date.

[0022] The judgment result table 13 is a table for managing the result of the abnormal value judgment, the corresponding status, and the comment after the abnormality judgment is executed. This judgment result table 13 includes an alert result table 60, a judgment result message data table 63, and a judgment result comment table 64 as shown in FIG.

[0023] The alert result table 60 is a table that manages information on data used for judgment, the presence or absence of an abnormality, and the response status, and one abnormal value judgment result table is created for one alert definition in the alert result table 60. The example in Fig. 7 is an example in which a production volume forecast alert result table 61, an assumed cost alert result table 62, etc. are created in the alert result table 60.

[0024] The progress forecast alert result table 61 is an abnormal value judgment result table created for the alert definition of the progress forecast of the construction. As shown in Fig. 8, the progress forecast alert result table 61 includes an execution history detail ID, a line number, a judgment result (abnormal or normal), a judgment result status (not yet addressed, in progress, no action required, or addressed), a construction progress rate, a project name, and a fiscal year and month.

[0025] The assumed cost alert result table 62 is an abnormal value judgment result table created for the alert definition of the assumed cost of construction. As shown in Fig. 9, the assumed cost alert result table 62 includes an execution history detail ID, a line number, a judgment result (abnormal or normal), a judgment result status (not yet handled, in process, no action required, handled), a cost amount, and an accounting year and month.

[0026] The judgment result message data table 63 is a table for managing messages generated in response to detected abnormalities. As shown in Fig. 10, the judgment result message data table 63 includes an execution history detail ID, a line number, and a message generated in response to a detected abnormality.

[0027] The judgment result comment table 64 is a table for managing comments generated according to the detection result of an anomaly. As shown in Fig. 11, the judgment result comment table 64 includes a comment ID, an execution history detail ID, a line number, a comment content, a response status, and an update date.

[0028] The definition change history data table 14 is a table for managing the change history of the alert definition and the alert security, and includes an alert definition history data table 65 and an alert security history data table 66, as shown in FIG.

[0029] The alert definition history data table 65 is a table in which history updated when an alert definition is created, changed, or deleted is stored. As shown in Fig. 13, the alert definition history data table 65 includes an alert definition generation management table 71, an alert definition history table 72, a preprocessing definition history table 73, a preprocessing result item history table 74, and an aggregation condition history table 75. The alert definition history data table 65 also includes an aggregation result item history table 76, an extraction condition history table 77, a result message template history table 78, a message icon history table 79, a judgment result table information history table 80, a definition data mapping history table 81, and a definition schedule mapping history table 82.

[0030] The alert definition generation management table 71 is a table that manages the change history of the alert definition as a generation. As shown in Fig. 14, the alert definition generation management table 71 includes a definition generation ID, a definition ID, a sequence number, a status (completed, deleted, etc.), a latest flag indicating whether the alert definition is the latest generation definition (TRUE) or an old generation definition (FALSE), the name of the user who updated the alert definition of that generation (update user name), and the update date and time.

[0031] The alert definition history table 72 is a table that manages the alert definitions that manage the algorithms, parameters, and abnormal value determination result table names by generation. As shown in Fig. 15, the alert definition history table 72 includes a definition generation ID, a definition ID, a definition code, a definition name, a result table name in which the determination result created by executing the alert definition is stored, the algorithm of the alert definition, and a specific definition.

[0032] The preprocessing definition history table 73 is a table that manages preprocessing definitions by generation that manage information on preprocessing of data used for judgment. The preprocessing result item history table 74 is a table that manages preprocessing result item information by generation that manages information on columns newly created when preprocessing is performed. The aggregation condition history table 75 is a table that manages aggregation conditions by generation that manage information on aggregation of data used for judgment.

[0033] Furthermore, the aggregation result item history table 76 is a table that manages, by generation, aggregation result item information that manages information on columns newly created when aggregation is performed.The extraction condition history table 77 is a table that manages, by generation, extraction conditions that manage information on thresholds used for judgment.The result message template history table 78 is a table that manages, by generation, result message templates that manage message templates that are the basis for judgment results.

[0034] Furthermore, the message icon history table 79 is a table that manages message icons that manage icons corresponding to anomaly ranks by generation. The judgment result table information history table 80 is a table that manages judgment result table information that manages column information of the judgment result table 13 by generation. The definition data mapping history table 81 is a table that manages definition data mapping that manages association information of data used in alert definitions by generation. The definition schedule mapping history table 82 is a table that manages definition schedule mapping that manages association information of schedules used in alert definitions by generation.

[0035] The anomaly detection device 1 of the embodiment is capable of setting handling authority by "user" or "user group" for "each alert definition" or for "each alert definition group" which is a grouping of multiple alert definitions.

[0036] 16, the alert security history data table 66 includes an alert definition security generation management table 85, an alert definition group security generation management table 86, a user definition relation history table 87, a user group definition relation history table 88, a user defined group relation history table 89, and a user group definition group relation history table 90. This alert security history data table 66 stores history that is updated when security settings for an alert definition are newly set, changed, or deleted.

[0037] That is, the alert definition security generation management table 85 is a table that manages the security change history for the alert definition as a generation. As shown in Fig. 17, the alert definition security generation management table 85 includes a security generation ID, a definition ID, a sequence number, a latest flag indicating whether the security generation is the latest generation (TRUE) or an old generation (FALSE), the user name of the user who updated the security of the generation (updating user name), and the update date and time.

[0038] The alert definition group security generation management table 86 is a table that manages the security change history for the alert definition group as a generation. As shown in Fig. 18, the alert definition group security generation management table 86 includes a security generation ID, a definition group ID, a sequence number, a latest flag indicating whether the group security is the latest generation group security (TRUE) or an older generation group security (FALSE), the user name of the user who updated the group security of the generation (updating user name), and the update date and time.

[0039] The user-defined relation history table 87 is a table that manages user-defined relations by generation that manage the authority of alert definitions for users. As shown in FIG. 19, the user-defined relation history table 87 is configured to include a security generation ID, a user ID, a user name, a definition ID, an output authority flag, and a query authority flag. The output authority flag is a flag (information) that indicates whether each user has output authority (TRUE or FALSE) for each alert definition. The query authority flag is a flag (information) that indicates whether each user has query authority (TRUE or FALSE) for each alert definition.

[0040] The user group definition relation history table 88 is a table that manages user group definition relations by generation, which manage the authority of alert definitions for user groups. As shown in FIG. 20(a), the user group definition relation history table 88 is configured to include a security generation ID, a user group ID, a user group name, a definition ID, an output authority flag, and a query authority flag. The output authority flag is a flag (information) that indicates whether or not each user group has output authority for each alert definition (TRUE or FALSE). The query authority flag is a flag (information) that indicates whether or not each user group has query authority for each alert definition (TRUE or FALSE).

[0041] The user-defined group relation history table 89 is a table that manages user-defined group relations by generation, which manage the authority of alert definition groups for users. As shown in FIG. 20(b), the user-defined group relation history table 89 is configured to include a security generation ID, a user ID, a user name, a definition group ID, an output authority flag, and a query authority flag. The output authority flag is a flag (information) that indicates whether or not each user has output authority (TRUE or FALSE) for each alert definition group. The query authority flag is a flag (information) that indicates whether or not each user has query authority (TRUE or FALSE) for each alert definition group.

[0042] The user group definition group relation history table 90 is a table that manages the user group definition group relations that manage the authority of the alert definition group for the user group by generation. As shown in FIG. 20(c), the user group definition group relation history table 90 is configured to include a security generation ID, a user group ID, a user group name, a definition group ID, an output authority flag, and a query authority flag. The output authority flag is a flag (information) that indicates whether or not each user group has output authority for each alert definition group (TRUE or FALSE). The query authority flag is a flag (information) that indicates whether or not each user group has query authority for each alert definition group (TRUE or FALSE).

[0043] (Functional configuration of anomaly detection device) Next, the control unit 3 executes the anomaly detection program stored in the memory unit 2, and thereby functions as an alert definition setting unit 21, an alert definition execution unit 22, an execution result generation unit 23, a definition change history generation unit 24, a display control unit 25, an authority setting unit 26, and an authority change history generation unit 27, as shown in FIG. 1.

[0044] The alert definition setting unit 21 sets an alert definition for anomaly detection. The alert definition execution unit 22 executes the set alert definition. The execution result generation unit 23 performs anomaly determination for an alert target (business data, as an example) based on the execution result of the alert definition, and generates a determination result based on the anomaly determination.

[0045] The definition change history generating unit 24 generates an execution history of executed alert definitions. This "execution history" is various data stored in the alert execution history detail table 12 shown in FIG.

[0046] The output control unit controls the output of the generated judgment results and execution history to an output device. As the output control unit, the display control unit 25 may be provided with a print control unit, an audio output control unit, etc. When the display control unit 25 is provided as the output control unit, the display control unit 25 displays a predetermined screen and the execution result of the alert definition, etc., via the output device 7 which is a display unit. When the print control unit is provided as the output control unit, the print control unit prints out a predetermined screen and the execution result of the alert definition, etc., via the output device 7 which is a printer. When the audio output control unit is provided as the output control unit, the audio output control unit controls the output of a predetermined screen, the execution result of the alert definition, etc., via the output device 7 which is a speaker device.

[0047] The definition change history generating unit 24 generates a definition change history of an alert definition when the alert definition is changed. This "definition change history" is the alert definition generation management table 71 and the alert definition history table 72 shown in Fig. 14. The output control unit controls the output of this definition change history to an output device together with the judgment result and the execution history.

[0048] The authority setting unit 26 sets the handling authority for the alert definition. The "handling authority" is, for example, the "output authority" and / or the "inquiry authority" set by the output authority flag and / or the inquiry authority flag of the user-defined relationship history table 87 shown in Fig. 19 or the user-group-defined relationship history table 88 shown in Fig. 20.

[0049] When such a handling authority is changed, the authority change history generating unit 27 generates an authority change history of the handling authority. The output control unit controls the output of this authority change history to an output device together with the judgment result, the execution history, and the definition change history.

[0050] When an alert definition is changed, the definition change history generating unit 24 generates a definition change history in which generation information indicating that the changed alert definition is the latest alert definition is added, and generates a definition change history in which generation information indicating that the other alert definitions are older generations is added. For example, the latest flag (latest FLG) illustrated in the alert definition generation management table 71 of FIG. 14 corresponds to this "generation information". In the example of FIG. 14, the "generation information indicating that the alert definition is the latest" is flag information of "TRUE", and the "generation information indicating that the alert definition is an older generation" is flag information of "FALSE".

[0051] When the handling authority is changed, the authority change history generating unit 27 generates an authority change history in which generation information indicating that the handling authority after the change is the latest handling authority is added to the handling authority after the change, and generates an authority change history in which generation information indicating that the handling authority is an older generation is added to other handling authorities. For example, the latest flag (latest FLG) illustrated in the alert definition security generation management table 85 in FIG. 17 and the alert definition group security generation management table 86 in FIG. 18 corresponds to this "generation information". In the examples of FIG. 17 and FIG. 18, the "generation information indicating that the handling authority is the latest" is flag information of "TRUE", and the "generation information indicating that the handling authority is an older generation" is flag information of "FALSE".

[0052] (Alert definition setting behavior) Next, the setting operation of the alert definition will be described. Note that the setting of the alert definition is executed by the control unit 3 functioning mainly as the display control unit 25 and the alert definition setting unit 21 based on the abnormality detection program stored in the storage unit 2.

[0053] When setting a desired alert definition, the operator specifies the display of an algorithm setting screen. This causes the display control unit 25 to display an algorithm setting screen, as exemplified in FIG. 21(a), via the output device 7. The operator inputs a definition code of the desired alert definition and a desired algorithm via this algorithm setting screen. The example in FIG. 21 is an example in which an algorithm of "approximate curve method" is set for an alert definition of "volume forecast alert."

[0054] Details of the algorithm of this "approximate curve method" are set on an approximate curve setting screen shown in Fig. 21(b) that is displayed by the display control unit 25. The example of Fig. 21(b) is an example in which the approximate curve method is set with the X-axis item being "progress rate of construction period", the Y-axis item being "cumulative progress rate", the approximate function candidate being "not specified", and the significance level being "0.025".

[0055] When such an algorithm for the alert definition is input, the alert definition setting unit 21 sets the definition generation ID, definition ID, sequence number, status, and latest flag corresponding to the set alert definition in the alert definition generation management table 71, as shown in Fig. 22(a). Since this example is at the stage where the initial alert definition has been set, the latest flag information is "TRUE", indicating that it is an alert definition of the latest generation.

[0056] 22(b), the alert definition setting unit 21 sets the definition generation ID, definition ID, definition code, definition name, result table name, algorithm, definition, etc. corresponding to the set alert definition in the alert definition history table 72. This example shows that the set alert definition is an alert definition for a volume forecast alert, and the storage destination of the abnormality determination result by this alert definition is the volume forecast alert result table 61. This example also shows that the approximation curve method is used as the algorithm, the definition does not specify an approximation function candidate, and the significance level is set to 0.025.

[0057] (Alert definition change behavior) Next, when changing the alert definition thus set, the operator again specifies the display of the algorithm setting screen. As a result, the display control unit 25 displays the algorithm setting screen exemplified in FIG. 23(a) via the output device 7. The example in FIG. 23(a) is an example of changing the alert definition of the above-mentioned volume forecast alert. For example, when changing the significance level of the alert definition of the volume forecast alert, the operator changes and inputs the significance level from the above-mentioned "0.025" to, for example, "0.05" in the approximation curve setting screen shown in FIG. 23(b) displayed by the display control unit 25.

[0058] When this change input is made, the control unit 3 functions as a definition change history generating unit 24 based on the anomaly detection program, and generates new records corresponding to this change input in the alert definition generation management table 71 and the alert definition history table 72, as shown in Fig. 24(a) and Fig. 24(b), respectively. That is, in the example of Fig. 24(a), the record in the first row is a record of the alert definition that was initially set, and the record in the second row is a record of the alert definition that corresponds to the change input. Similarly, in the example of Fig. 24(b), the record in the first row is a record of the alert definition that was initially set, and the record in the second row is a record of the alert definition that corresponds to the change input.

[0059] In this way, by generating a new record every time a change is input, records of each generation are stacked as history in the alert definition generation management table 71 and the alert definition history table 72. Therefore, a person in charge such as an internal control administrator can easily check the transition state of changes to the alert definition.

[0060] Furthermore, the definition change history generating unit 24 sets the latest flag of the record of the new generation corresponding to the change input among the latest flags of the alert definition generation management table 71 shown in Fig. 24(a) to "TRUE", and updates the latest flag of the record of the generation that has become old due to the change input to "FALSE". This allows a person in charge such as an internal control manager to easily recognize the latest alert definition (= the alert definition with the latest flag of "TRUE") among each alert definition.

[0061] (Security permission settings) Next, the operation of setting security authority, which is the authority to output and inquire about alert definitions for each user and each user group, will be described. Note that the setting of security authority is performed by the control unit 3 functioning mainly as the display control unit 25 and the authority setting unit 26 based on the anomaly detection program stored in the storage unit 2.

[0062] When setting a desired security authority, the operator specifies the display of a security registration screen. This causes the display control unit 25 to display the security registration screen illustrated in FIG. 25 via the output device 7. This security registration screen displays check boxes for setting whether output authority is granted for each user and for each user group, and check boxes for setting whether inquiry authority is granted. Using this security registration screen, the operator inputs a check icon into the check box of the user or user group to which output authority is granted for each alert definition, and also inputs a check icon into the check box of the user or user group to which inquiry authority is granted.

[0063] When the security authority of each user and each user group is set for each alert definition in this manner, the authority setting unit 26 inputs the security generation ID of "SV1001" and the like into the alert definition security generation management table 85 for each alert definition shown in FIG. 26(a), and sets the latest flag to "TRUE" to indicate that the security authority for the security generation ID of "SV1001" is the latest generation.

[0064] Furthermore, as shown in Fig. 26(b), the authority setting unit 26 sets the output authority and inquiry authority of each user set via the security registration screen shown in Fig. 25 for a user-defined relation history table 87 for each alert definition. Similarly, as shown in Fig. 26(c), the authority setting unit 26 sets the output authority and inquiry authority of each user group set via the security registration screen shown in Fig. 25 for a user-group-defined relation history table 88 for each alert definition.

[0065] This example is an example in which both the output authority and inquiry authority for the production volume forecast alert are set to "FALSE" for user "U0001" as shown in Fig. 26(b). Also, this is an example in which "TRUE" is set as the output authority for the production volume forecast alert and "FALSE" is set as the inquiry authority for user "U0002" as shown in Fig. 26(b).

[0066] This example is an example in which the output authority for the volume forecast alert is set to "FALSE" and the inquiry authority is set to "TRUE" for the user group "UG0001" as shown in Fig. 26(c). Also, this is an example in which both the output authority and the inquiry authority are set to "TRUE" for the user group "UG0002" as shown in Fig. 26(c).

[0067] (Security permission change behavior) Next, the operation of changing security authority, which is the output authority and inquiry authority of the alert definition for each user and each user group, will be described. When changing the desired security authority, the operator again specifies the display of the security registration screen. As a result, the display control unit 25 displays the security registration screen illustrated in FIG. 27 via the output device 7. The operator changes the security authority by inputting or deleting a check icon for the check box that sets the output authority and inquiry authority of this security registration screen. The example of FIG. 27 is an example in which the security authority granted to "user 2" and "user group 1" is cancelled by deleting the record of "user 2" and the record of "user group 1", and the security authority of "output authority" is newly granted to "user 3". Also, the example of FIG. 27 is an example in which the security authority of "inquiry authority" is granted to "user 1" who was not granted either "output authority" or "inquiry authority".

[0068] When the security authority of each user and / or each user group is changed in this manner, the control unit 3 functions as the authority change history generation unit 27 based on the anomaly detection program, and generates a record of a new security generation ID of "SV1002" in the alert definition security generation management table 85 shown in Fig. 28(a). Then, the authority change history generation unit 27 sets the latest flag of the record of the old security generation of "SV1001" to "FALSE", and sets the latest flag of the record of the new security generation of "SV1002" to "TRUE". This makes it possible to indicate that the record of the security generation of "SV1002" is the record of the latest security generation.

[0069] Furthermore, the authority change history generating unit 27 generates, in the user definition relationship history table 87, a record for user "U0001" that remains without being deleted due to the current security authority change operation, and a record for user "U0003" to which new security authority has been granted. Then, the security generation ID of "SV1002", which indicates a new security generation, is assigned to the records for user "U0001" and user "U0003".

[0070] In addition, the authority change history generation unit 27 sets the output authority flag of the records of each user, "U0001" and "U0003", to which the security generation ID of "SV1002" has been assigned, to indicate the presence or absence of output authority set on the security registration screen (TRUE or FALSE), and sets the inquiry authority flag of the records of each user, to indicate the presence or absence of inquiry authority (TRUE or FALSE).

[0071] Furthermore, the authority change history generating unit 27 generates a record for the user group "UG0002" that remains without being deleted due to the current security authority change operation in the user group definition relation history table 88. Then, the security generation ID of "SV1002" indicating a new security generation is assigned to the record for the user group "UG0002".

[0072] In addition, the authority change history generation unit 27 sets the output authority flag of the record of the user group "UG0002" to which the security generation ID "SV1002" has been assigned to indicate the presence or absence of output authority set on the security registration screen (TRUE or FALSE), and sets the inquiry authority flag of the record of each user to indicate the presence or absence of inquiry authority (TRUE or FALSE).

[0073] This enables a responsible person such as an internal control manager to easily recognize the latest security authority (= output authority flag or inquiry authority flag of "TRUE") of each user and each user group.

[0074] (Abnormality judgment operation) Next, an abnormality judgment operation based on the alert definition set as described above will be described. When the date and time set in the alert definition arrives or an abnormality judgment is specified by the operator, the control unit 3 functions as the alert definition execution unit 22 based on the abnormality detection program, and executes an abnormality judgment for the business data shown in Fig. 1 based on the alert definition. When the alert definition is executed, the alert definition execution unit 22 inputs an execution history detail ID that is automatically numbered for each execution, the definition ID of the executed alert definition, the execution status (execution completed or error, etc.), the number of data items, the number of abnormal items, and the number of normal items to the alert execution history detail table 12, as shown in Fig. 29(a).

[0075] The control unit 3 also functions as the execution result generating unit 23 based on the anomaly detection program, and inputs a message corresponding to the execution result of the alert definition to a judgment result message data table 63 illustrated in Fig. 29(b). The execution result generating unit 23 also inputs the judgment result, etc., of the alert result table 60 illustrated in Fig. 29(c) (the example in Fig. 29(c) is an example of a volume forecast alert result table 61) based on the execution result of the alert definition.

[0076] As a result, in the alert execution history detail table 12 shown in FIG. 29(a), records including the definition ID, status, number of data items, number of abnormal items, and number of normal items of the executed alert definition are stored as history in a stacked form for each execution of the alert definition. Also, in the judgment result message data table 63 shown in FIG. 29(b), records of messages of judgment results of business data based on the alert definition are stored as history in a stacked form. Furthermore, in the alert result table 60 shown in FIG. 29(c) (the example of FIG. 29(c) is an example of a volume forecast alert result table 61), records of abnormality judgment results based on the alert definition and the like are stored as history in a stacked form.

[0077] A responsible person such as an internal control manager can easily recognize the execution status and anomaly judgment results of each alert definition based on the execution history of these tables 12, 63, 60 (61).

[0078] (Check the result) Next, when an anomaly determination result is generated by executing the alert definition as described above, the business checker checks it and updates the comment. When checking this anomaly determination result and updating the comment, the business checker specifies the display of the analysis job screen via the input device 6. When this specification is made, the display control unit 25 refers to the determination result message data table 63 shown in Fig. 29(b), and displays, via the output device 7, an analysis job screen including a list of alerts, such as the detection date, the alert definition name, and the message, for the alert definition in which a high degree of anomaly has been detected, as shown in Fig. 30(a).

[0079] The person in charge of checking the operations checks the messages in this alert list one by one and specifies the creation of a comment. When the creation of a comment is specified, the display control unit 25 displays the response status and comment input screen shown in Fig. 30(b) on the output device 7. The person in charge of checking the operations inputs a response status, for example, one of "not yet handled," "in process," or "handled," along with a desired comment, for example, "checking with person in charge," and operates the registration button.

[0080] When the registration button on this status / comment input screen is operated, the execution result generation unit 23 updates the determination result status in the volume forecast alert result table 61 to, for example, "in progress" based on the response status input on the status / comment input screen, as shown in Fig. 31(a). Also, the execution result generation unit 23 updates the response status in the determination result comment table 64 to, for example, "in progress" based on the response status input on the status / comment input screen, as shown in Fig. 31(b). Also, the execution result generation unit 23 updates the response status in the determination result comment table 64 to, for example, "checking with the person in charge" based on the comment input on the status / comment input screen, as shown in Fig. 31(b).

[0081] (Visualization of operation status) Next, the response status and comments corresponding to the determination result of an anomaly in the business data by executing such an alert definition are displayed on an alert AI operation status confirmation screen described below. This alert AI operation status confirmation screen visualizes data related to the operation status in an easy-to-understand manner. By periodically checking this alert AI operation status confirmation screen, a person in charge such as an internal control manager can grasp the operation status of the alert definition for anomaly detection. This alert AI operation status confirmation screen is configured so that it is easy to notice if there is a problem with the operation status of the alert definition, and if there is a problem, the person in charge such as an internal control manager will check the situation with the person in charge and make corrections. This makes it possible to operate the anomaly detection device 1 appropriately.

[0082] That is, Fig. 32 is a diagram showing an example of an alert AI operation status check screen. The display control unit 25 displays this alert AI operation status check screen via the output device 7 based on the anomaly detection program at a timing designated by a person in charge, etc. As shown in Fig. 32, the alert AI operation status check screen includes display areas for a filter section, a message section, and a details display section.

[0083] As shown in Fig. 33, the filter section includes an input field for the output period, an input field for the definition code, and a display button. By selecting the output period and the definition code for the output target, it is possible to narrow down the data to be displayed in the message section and the detailed display section. If the output period and definition code are not specified, the display control section 25 extracts and displays all existing data as the output target. The display control section 25 also displays the output period of "the past year from the start date" and the definition code of "not specified" in the filter section as the initial display.

[0084] Next, the display control unit 25 displays a message for the items requiring operational confirmation in the message section, as shown in Fig. 34. Further specific examples are given below.

[0085] 1. Messages regarding execution status For example, the message "An execution error has occurred twice. Please check the execution status" is displayed if an error occurs during anomaly detection. Since there is a possibility that the anomaly judgment that should have been executed has not been executed, the person in charge checks the graph of the execution status to confirm what kind of error has occurred in which definition.

[0086] 2. Messages regarding detection status (1) For example, the message "The number of detected items was 0. Please check the detection status and definition contents." is displayed if the number of items determined to be abnormal when abnormal value judgment is performed is 0. A certain amount of anomalies are expected to be detected, but in some cases none have been detected, and the judgment may be inappropriate. Therefore, check the alert definition to ensure that the expected judgment results are obtained.

[0087] 3. Messages regarding detection status (2) For example, the message "The number of detected cases exceeds 30% of the total. Please check the detection status and definition contents" is displayed if the number of cases determined to be abnormal when abnormal value judgment is performed exceeds 30% of the total. There is a possibility that the number of detections has become too great to handle, or that unnecessary things are being detected, so the person in charge looks at the detection status graph to see how many cases have been detected by which alert definition.

[0088] 4. Message regarding response status For example, the message "There are three detections that have not been addressed. Please check the response status" is displayed if there are cases in which the response status to the anomaly detection results detected after the anomaly detection has been performed has not been changed. There is a concern that despite the anomalies being detected, they may be left unaddressed for a long period of time, so the person in charge looks at the response status graph and checks which alert definitions have not been updated.

[0089] 5. Message regarding alert definition change history For example, the message "The alert definition has been changed twice. Please check that the changes match what was expected" will be displayed if there is a history of the alert definition being changed. Because there is concern that unexpected changes have been made to the alert definition, which may result in correct judgments being made, the person in charge checks the table of alert definition change history to confirm the changes made and the user who made them.

[0090] 6. Message regarding alert security change history For example, the message "Alert AI security settings have been changed twice. Please check that the changes match what you expected" will be displayed if there is a history of changes to alert security. Since unexpected changes have been made to the alert definition and security privileges may have been granted to a user who does not have security privileges to view data, the person in charge checks the alert security change history table to confirm the changes or the user who changed the alert definition.

[0091] (Check the status according to the message) Next, the person in charge who sees such a message displays the confirmation screen specified in the message and checks the execution status of the alert definition, etc. The display control unit 25 displays the specified confirmation screen in the detail display section of the alert AI operation status confirmation screen.

[0092] (Displays execution status confirmation screen) First, when the display of the confirmation screen for the execution status is designated based on the above-mentioned "1. Messages regarding the execution status", the display control unit 25 refers to the alert execution history detail table 12 and counts the number (number of times) by status (successful completion and error) as shown in Fig. 35(a). Then, the display control unit 25 displays a pie chart shown in Fig. 36 based on the counting result.

[0093] Furthermore, the display control unit 25 refers to the alert execution history detail table 12 and tallies the numbers by month and by situation, as shown in Fig. 35(b). Then, the display control unit 25 displays a stacked bar graph shown in Fig. 36 based on the tallied results.

[0094] Furthermore, the display control unit 25 refers to the alert execution history detail table 12 and tallies the last update date and time and the last update status (error or normal end) of each alert definition, as shown in Fig. 35(c). Also, the display control unit 25 refers to the alert execution history detail table 12 and tallies the number of normal end times and the number of error end times for each alert definition, as shown in Fig. 35(d). Then, the display control unit 25 displays the last update date and time, the last update status (error or normal end), the number of normal end times, and the number of error end times for each alert definition, as shown in Fig. 36.

[0095] Based on the execution status confirmation screen shown in FIG. 36, the person in charge makes the following considerations.

[0096] <Expected confirmation contents> Is the abnormal value determination being carried out normally as scheduled? <Possible Situation> Abnormal value judgment is not performed, and the target cannot be detected. <Confirmation image> Check whether the alert definition is executed periodically → If there are times when it is not executed along the way, it may not be executed at the expected time. Is the latest update date correct? (If it has not been executed, it is earlier than expected.) If it has not been executed, check the alert definition (you can move to the setting screen by clicking the button to check the definition) Check whether any errors have occurred (the number of error terminations is increasing) -> If an error has occurred, identify the type of error from the log viewer and take appropriate action.

[0097] Fig. 36 shows a confirmation screen for the execution status when anomaly detection is operating normally with each alert definition. In contrast, Fig. 37 shows a confirmation screen for the execution status when anomaly detection is not operating normally with each alert definition. The example in Fig. 37(a) is an example where many errors occur, and Fig. 37(b) is an example where there is a period where anomaly detection is not performed.

[0098] (Displays the confirmation screen for the detection status) Next, when the display of the confirmation screen for the detection status is designated based on the above-mentioned "2. Message (1) regarding the detection status", the display control unit 25 refers to the alert execution history detail table 12 and tallies the abnormality ratios of the last updated records by alert definition as shown in Figures 38(a) and 38(c). Also, the display control unit 25 refers to the alert execution history detail table 12 and tallies the abnormality ratios by alert definition and execution as shown in Figure 38(b).

[0099] Furthermore, when the display of a confirmation screen for the detection status is specified based on the above-mentioned “3. Message regarding the detection status (2)”, the display control unit 25 refers to the alert definition table 51 shown in FIG. 3, and acquires the definition code of each alert definition and the “result table name” of each alert definition, as shown in FIG. 42(a).

[0100] In addition, as shown in Figure 42(b), the display control unit 25 obtains the execution history detail ID corresponding to the update date from the alert execution history detail table 12, and combines it with, for example, the production volume forecast alert result table 61 shown in Figure 42(c) and / or the assumed cost alert result table 62 shown in Figure 42(d).

[0101] Next, the display control unit 25 acquires the execution history detail ID, line number and judgment result status of the record having the judgment result of “1: Abnormal” from, for example, the production volume forecast alert result table 61 shown in FIG. 8 and the assumed cost alert result table 62 shown in FIG. 9 corresponding to the acquired result table name (FIGS. 42(c) and 42(d)).

[0102] Next, as shown in FIG. 42(b), the display control unit 25 combines the combination result of the result table name and the execution history detail ID, the judgment result message data table 63 shown in FIG. 42(e), and the judgment result comment table 64 shown in FIG. 43(a) with the execution history detail ID and row number. The display control unit 25 also acquires a message from the judgment result message data table 63, and if a "row" exists in the judgment result comment table 64, acquires the latest date among the update dates for each execution history detail ID and row number as the last update date. If a "row" does not exist in the judgment result comment table 64, acquires the update date of the alert execution history detail table 12 as the last update date. Then, based on such aggregation results, an overall aggregation result as shown in FIG. 43(b) is generated.

[0103] Based on the tabulation results, the display control unit 25 displays the execution details (detection result details by definition) shown in FIG. 40. In the execution details in FIG. 40, the "normal number" is the number of data items that were determined to be within the normal range among the data items that were subject to abnormal value judgment by definition. The "abnormal number" is the number of data items that were determined to be abnormal among the data items that were subject to abnormal value judgment by definition. The "abnormal rate" is a rate calculated using the formula "number of abnormal detections / (number of normal detections+number of abnormal detections)". The "maximum abnormal rate" is the maximum value of the abnormal rate by definition calculated for each execution. The "minimum abnormal rate" is the minimum value of the abnormal rate by definition calculated for each execution.

[0104] Furthermore, the display control unit 25 extracts data of the alert definition selected in the execution details of Fig. 42 (assuming that the deemed cost alert is selected) from the data corresponding to the output period shown in Fig. 33 from the alert execution history details table 12 as shown in Fig. 39. Then, based on the extraction result, a stacked bar graph of the number of data determined to be normal and the number of data determined to be abnormal for each execution date of the anomaly detection is displayed as shown in Fig. 40 (result status by execution date).

[0105] Based on the detection status confirmation screen shown in FIG. 40, the person in charge makes the following considerations.

[0106] <Expected confirmation contents> Is the data that should be detected being detected correctly? <Possible Situation> The outliers are detecting too many things, meaning unnecessary things are being detected, reducing the effectiveness of the system. The abnormal value determination is not detecting anything at all, i.e., things that should be detected are not being detected, reducing the effectiveness of the system. <Confirmation image> Is the overall number of abnormalities too high? → If so, check the response status described below (4. Messages regarding response status) Is there a period in which the number of anomalies has been extremely small? If they have suddenly stopped being detected, check the alert definition change history described below to see if the alert definition has been changed (5. Messages related to the alert definition change history)

[0107] In the detection status confirmation screen shown in FIG. 40, the abnormality rate is not too high, and the upper limit of the number of abnormalities per execution of anomaly detection is low. For this reason, it is clear that normal operation is being performed. In contrast, FIG. 41(a) to FIG. 41(c) are examples of abnormal operation. That is, the examples of FIG. 41(a) and FIG. 41(b) have a high abnormality rate, and the abnormality rate is always high in the details. For this reason, it is clear that normal operation is not being performed. In addition, in the example of FIG. 41(c), the abnormality rate is normal, but the maximum abnormality rate is high and the minimum abnormality rate is low. And when looking at the graph, the abnormal results are rapidly decreasing. For this reason, it is clear that normal operation is not being performed.

[0108] (Displays confirmation screen for compatibility status) Next, when a request to display a confirmation screen for the response status to an alert is specified based on the above-mentioned “4. Message regarding response status”, the display control unit 25 refers to the alert definition table 51 shown in FIG. 44(a) and acquires the definition code and result table name of each alert definition.

[0109] In addition, as shown in Figure 44(b), the display control unit 25 obtains the execution history detail ID corresponding to the update date from the alert execution history detail table 12, and combines it with, for example, the production volume forecast alert result table 61 shown in Figure 44(c) and / or the assumed cost alert result table 62 shown in Figure 44(d).

[0110] In addition, the display control unit 25 detects records whose judgment result is “1: Abnormal”, as shown in Figures 44(c) and 44(d), for example, from the production volume forecast alert result table 61 shown in Figure 8 and the assumed cost alert result table 62 shown in Figure 9.

[0111] In addition, the display control unit 25 counts the number of statuses (not yet addressed, in process, and addressed) indicating the response situation corresponding to the judgment result of "1: Abnormal" in the production volume forecast alert result table 61 shown in Figure 8 and the assumed cost alert result table 62 shown in Figure 9, for each status, as shown in Figure 44(e) and Figure 44(f).

[0112] After tallying up each status in this way, the display control unit 25 adds up the numbers of each status in each alert result table 61, 62, as shown in Fig. 44(g). Then, based on the result of this addition, the display control unit 25 displays a graph showing the proportion of response status for each status for alerts determined to be "1: Abnormal", as shown in "Response Status Graph" in Fig. 46.

[0113] The same is true for the "monthly response status", where the display control unit 25 refers to the alert definition table 51 shown in FIG. 45(a) and acquires the definition code and result table name of each alert definition.

[0114] In addition, as shown in Figure 45(b), the display control unit 25 obtains the execution history detail ID corresponding to the update date from the alert execution history detail table 12, and combines it with, for example, the production volume forecast alert result table 61 shown in Figure 45(c) and / or the assumed cost alert result table 62 shown in Figure 45(d).

[0115] In addition, the display control unit 25 detects records whose judgment result is “1: Abnormal”, as shown in Figures 45(c) and 45(d), for example, from the production volume forecast alert result table 61 shown in Figure 8 and the assumed cost alert result table 62 shown in Figure 9.

[0116] In addition, the display control unit 25 tally up the number of statuses (not yet addressed, in process, and addressed) indicating the response situation corresponding to the judgment result of "1: Abnormal" in the production volume forecast alert result table 61 shown in Figure 8 and the assumed cost alert result table 62 shown in Figure 9, by status and by month, as shown in Figure 45(e) and Figure 45(f).

[0117] After tallying up each status by month in this way, the display control unit 25 adds up the number of each status by month in each alert result table 61, 62, as shown in Fig. 45(g). Then, based on the result of this addition, the display control unit 25 displays a bar graph indicating the monthly response status of each alert determined to be "1: Abnormal", as shown in the bar graph of "Monthly Response Status" in Fig. 46.

[0118] In Figure 46, past statuses are marked as "Resolved," and the most recent cases (December alerts) have statuses of "Responding" or "Not Resolved." Based on the graph in Figure 46, this shows that each alert is being properly handled.

[0119] In contrast, the graph in Figure 47(a) shows that there are "unhandled" alerts for past alerts (April). Also, the graph in Figure 47(b) shows that there are a large number of alerts for recent alerts (October to December), and that the number of "handled" and "unhandled" alerts is increasing. In such cases, it can be seen that the alerts are not being properly handled.

[0120] Based on the confirmation screen for the response status to the alert shown in FIG. 47, the person in charge will make the following considerations.

[0121] <Expected confirmation contents> Are corrective measures being taken in response to what is detected? <Possible Situation> The judgement information is left unaddressed → The abnormal situation is forgotten and not dealt with, or it is not dealt with intentionally. Or, there are too many detections and the response cannot be kept up. <Confirmation image> Check the monthly response status to see if any past cases have a status other than "resolved" (because the graph is displayed by execution month, if there are any cases that are backlogged, the past month section will show "not resolved" or "in progress" as legend). If past cases remain "not resolved" or "in progress" on the graph, click on the graph for the "not resolved" section to narrow down the details, open this analysis screen, and check the comments. Then identify the person in charge and check the details of the response status.

[0122] (Displays the confirmation screen for the alert definition change history) Next, when the display of a confirmation screen for the change history of an alert definition is specified based on the above-mentioned "5. Messages Regarding the Change History of Alert Definitions", the display control unit 25 refers to the alert definition generation management table 71 shown in FIG. 48(a), and generates change content data indicating the change user name, status (change completion or deletion), and change content of each alert definition, as shown in FIG. 48(b). Note that in the change content data in FIG. 48(b), "New" in "Change Content" corresponds to "1 (first updated)" in the sequence (SEQ), and indicates that this is the oldest alert definition. Also, "Modified" in "Change Content" indicates that the alert definition has been modified.

[0123] Next, the display control unit 25 adds the result table name of each alert definition acquired from the alert definition table 51 shown in FIG. 3 as a “definition name” to the change content data, and generates the combined data shown in FIG. 49(a).

[0124] Next, the display control unit 25 extracts, from the combined data, as shown in Fig. 49(b), a record corresponding to the definition code of the alert definition specified in the filter section of the alert AI operation status confirmation screen shown in Fig. 32. The example of Fig. 49(b) is an example in which an alert definition of a volume forecast alert is specified in the filter section of the alert AI operation status confirmation screen, and therefore a record of the definition ID of this volume forecast alert, "D0001", is extracted from the combined data.

[0125] Furthermore, the example in Figure 49(b) shows that the alert definition for the volume forecast alert was newly set on "October 10, 2022" and revised on "December 15, 2022." Therefore, the alert definition for the volume forecast alert set on "October 10, 2022" is an older generation definition (FALSE), and the alert definition for the volume forecast alert revised on "December 15, 2022" is the latest generation definition (TRUE). Additionally, the number of changes is "1 time."

[0126] Furthermore, the display control unit 25 refers to the alert definition history table 72 shown in Fig. 15, compares the alert definition of the production volume forecast alert before and after the correction, and detects the changed parts, column names, algorithms, definitions, etc. in the alert definition of the production volume forecast alert before and after the correction, as shown in Fig. 49(c) and Fig. 49(d). Then, the display control unit 25 displays the number of changes to the alert definition, the change history, and change details, as shown in Fig. 50.

[0127] The example in Figure 50 shows that the number of changes was "1", and that the alert definition was revised on "December 15, 2022". The example in Figure 50 also shows that the change made to the "algorithm" was that the significance level was revised from "0.025" to "0.05". In the example in Figure 50, the number of changes to the alert definition was only "1", and the changes to the significance level were also within the normal range. This shows that anomaly detection using the alert definition is operating normally.

[0128] In contrast, in the example in Figure 51, the alert definition has been changed an extremely large number of times, at "30 times," and the value of the algorithm's significance level after the change has been deleted (the value has been set to "0"). This is an act that makes it difficult to detect fraud, and shows that anomaly detection using the alert definition is not working properly.

[0129] Based on the confirmation screens for the change history of the alert definition shown in Figures 50 and 51, the person in charge will make the following considerations.

[0130] <Expected confirmation contents> Have any unauthorized changes been made to the abnormal value determination definition? <Possible Situation> The alert definition has been illegally changed -- the administrator of the alert definition has made a mistake in the settings, or the definition has been intentionally changed to make it difficult to detect something that should have been detected. <Confirmation image> Check the change history to see if the changes were within the expected range → Important changes have been made at a time when operations should not have changed. Or, unexpected changes or changes that seem fraudulent have been made. In this case, check the situation with the administrator.

[0131] (Display of confirmation screen for Alert AI security definition change history) Next, when the display of the confirmation screen for the change history of the alert AI security definition is specified based on the above-mentioned "6. Message regarding the alert security change history", the display control unit 25 refers to the alert definition security generation management table 85 shown in Fig. 17, and extracts records corresponding to the alert definition specified in the filter section of the alert AI operation status confirmation screen shown in Fig. 32, as shown in Fig. 52(a). This extracts records of each user or user group that has been granted security authority such as output authority or inquiry authority (see Fig. 25) for the specified alert definition.

[0132] Similarly, the display control unit 25 refers to the alert definition group security generation management table 86 shown in Fig. 18, and extracts records corresponding to the alert definition specified in the filter section of the alert AI operation status confirmation screen, as shown in Fig. 52(b). This extracts records of each user or user group that has been granted security authority such as output authority or inquiry authority for the specified alert definition.

[0133] Next, the display control unit 25 combines the extracted records of each user and each user group to generate security generation management data shown in Fig. 52(c). This security generation management data may be displayed.

[0134] Next, the display control unit 25 refers to the alert definition generation management table 71 shown in Fig. 14 based on this security generation management data, and extracts records before and after the correction corresponding to the alert definition extracted as the security generation management data, as shown in Fig. 52(d). Furthermore, the display control unit 25 generates change detail data including the change contents of the alert definition for each user and each user group, and the presence or absence of security authority (output authority and / or inquiry authority) of each user and each user group, as shown in Fig. 53(a), based on the extracted records before and after the correction, the user definition relation history table 87 shown in Fig. 53(b) and Fig. 53(c), and the user group definition relation history table 88 shown in Fig. 53(d).

[0135] Then, the display control unit 25 displays the number of times the security settings have been changed, the change history of the alert security, and details of the changes, as shown in FIG. 54, based on the security generation management data shown in FIG. 52(c), the records before and after the correction corresponding to the alert definition in FIG. 52(d), and the change detail data shown in FIG. 53(a).

[0136] In FIG. 54, the display control unit 25 compares the records before and after the correction according to the definition of the details (records) selected in "Alert security change history", and displays the changes in the "Change details" display area.

[0137] Also, the manner in which the "Change details" are displayed is similar, but the display control unit 25 displays the "Change details" by referring to various tables and various data corresponding to the alert definition or alert definition group selected in the details (record) of the "Alert security change history".

[0138] That is, Fig. 55 is an example in which "inventory management definition group", which is an alert definition group, is selected in "alert security change history". In this case, the display control unit 25 generates change detail data and the like based on the alert definition group security generation management table 86, the user defined group relation history table 89, and the user group defined group relation history table 90, and displays "change details" including the changed part, user category, display name, presence or absence of output authority, and presence or absence of inquiry authority together with "alert security change history", as shown in Fig. 55.

[0139] 56 is an example in which "output forecast alert definition" is selected in "alert security change history". In this case, the display control unit 25 generates change detail data and the like based on the alert definition security generation management table 85, the user definition relation history table 87, and the user group definition relation history table 88, and displays "change details" including the change location, user classification, display name, whether or not there is an output authority, and whether or not there is an inquiry authority, together with the "alert security change history", as shown in FIG.

[0140] FIG. 55 shows an example of an alert security change history showing a normal security change example. In the example of FIG. 55, the number of security setting changes is "2 times", and the security setting of the "inventory management definition group" was changed by "User A" on "December 21, 2022", and the security setting of the "output forecast alert" was changed on "December 15, 2022". In the example of FIG. 55, the number of security setting changes is small at "2 times". In addition, the security authority settings are set within the expected range. Therefore, it can be seen that anomaly detection by the alert definition group is operating normally.

[0141] In contrast, Figure 56 shows an example of an alert security change history that shows an example of unauthorized security changes. In the example of Figure 56, the number of times the security settings were changed is extremely high at "40 times," and security privileges have been set for users who are unlikely to be granted security privileges. This shows that anomaly detection using alert definitions is not working properly.

[0142] Based on the confirmation screens for the change history of the alert definition shown in FIGS. 55 and 56, the person in charge will make the following considerations.

[0143] <Expected confirmation contents> Have the security permissions to view the analysis screen for anomaly detection by each alert definition (see Figure 32, etc.) been set only for users who should be set them? <Possible Situation> The data is now viewable by users who should not have been allowed to view it, which suggests some kind of manipulation was done to conceal the fraud. <Confirmation image> Check whether there are any unexpected changes in the change history. If there are any unexpected changes or changes that seem to be fraudulent, check the situation with the administrator.

[0144] (Effects of the embodiment) As is clear from the above description, the anomaly detection device 1 of the embodiment can accumulate data such as system execution history, judgment result information, and definition change history, which are necessary for operational confirmation. In addition, the data can be visualized (including display, printing, and audio output) to make it easier to check the operational status. This allows a responsible person such as an internal control manager to easily check the operational status of the anomaly detection device 1.

[0145] In addition, since the operating status of the anomaly detection device 1 can be confirmed, any abnormal operating conditions can be quickly noticed and corrective measures can be taken.

[0146] In addition, the PDCA cycle for internal control can be properly implemented, improving the level of control. The PDCA cycle is a method for continuously improving and streamlining operations by repeating the steps of "Plan → Do → Check → Act."

[0147] [Contribution to the United Nations-led Sustainable Development Goals (SDGs)] This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, and can therefore contribute to Goals 8 and 9 of the SDGs.

[0148] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to the achievement of Goals 12, 13, and 15 of the SDGs.

[0149] Furthermore, this embodiment can contribute to strengthening control and governance, making it possible to contribute to Goal 16 of the SDGs.

[0150] [Other embodiments] The present invention may be embodied in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

[0151] For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods.

[0152] In addition, the processing procedures, control procedures, specific names, information including parameters such as registered data and search conditions for each process, screen examples, and database configurations shown in this specification and drawings may be changed as desired unless otherwise specified.

[0153] Moreover, with regard to the anomaly detection device 1, each of the components shown in the figures is merely a functional concept, and does not necessarily have to be physically configured as shown in the figures.

[0154] For example, the processing functions of the anomaly detection device 1, particularly the control unit 3 and each processing function performed by the control unit 3, may be realized in whole or in part by a CPU (Central Processing Unit) and a program interpreted and executed by the CPU, or may be realized as hardware using wired logic. The program is recorded in a non-transient computer-readable recording medium containing programmed instructions for causing the information processing device to execute the processes described in this embodiment, and is mechanically read by the anomaly detection device 1 as necessary. That is, a computer program for giving instructions to the CPU in cooperation with the OS and performing various processes is recorded in a storage unit such as a ROM or HDD. This computer program is executed by being loaded into a RAM, and constitutes the control unit 3 in cooperation with the CPU.

[0155] In addition, the anomaly detection program of this anomaly detection device 1 may be stored in another server device connected to the anomaly detection device 1 via any network, and it is also possible to download all or part of it as necessary.

[0156] The anomaly detection program for executing the process described in this embodiment may be stored in a non-transient computer-readable recording medium, or may be configured as a program product. Here, the term "recording medium" includes any "portable physical medium" such as a memory card, a Universal Serial Bus (USB) memory, a Secure Digital (SD) card, a flexible disk, a magneto-optical disk, a ROM, an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable and Programmable Read Only Memory (EEPROM (registered trademark)), a Compact Disk Read Only Memory (CD-ROM), a Magneto-Optical Disk (MO), a Digital Versatile Disk (DVD), and a Blu-ray (registered trademark) Disc.

[0157] Moreover, a "program" is a data processing method written in any language or description method, and may be in any form, such as source code or binary code. Note that a "program" is not necessarily limited to a single configuration, but also includes a distributed configuration as multiple modules or libraries, and a program that achieves its function by working with a separate program, such as an OS. Note that well-known configurations and procedures can be used for the specific configuration and reading procedure for reading a recording medium in the anomaly detection device 1 shown in the embodiment, as well as the installation procedure after reading.

[0158] The memory unit 2 is a storage means such as a memory device such as RAM or ROM, a fixed disk device such as a hard disk, a flexible disk, or an optical disk, and stores various programs, tables, databases, and web page files used for various processes and providing websites.

[0159] The anomaly detection device 1 may be configured as an information processing device such as a known personal computer device or a workstation, or may be configured as an information processing device to which any peripheral device is connected. The information processing device may be realized by implementing software (including programs or data, etc.) that realizes the processing described in this embodiment.

[0160] Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the drawings, and all or part of them can be functionally or physically distributed and integrated in any unit according to various additions or functional loads. In other words, the above-mentioned embodiments can be implemented in any combination, or the embodiments can be implemented selectively. [Industrial Applicability]

[0161] The present invention is suitable for application to anomaly detection in accounting and other types of business. [Explanation of symbols]

[0162] 1. Anomaly detection device 2 Storage section 3. Control Unit 4. Communication Interface Section 5 Input / Output Interface Section 6 Input Devices 7 Output Devices 11 Pre-configured Data Tables 12 Alert Execution History Details Table 13 Judgment result table 14 Definition change history data table 21 Alert definition setting section 22 Alert definition execution part 23 Execution result generation unit 24 Definition change history generation section 25 Display control section 26 Permission Setting Section 27 Authority change history generation unit 35 Network 36 Accounting server device

Claims

1. An alert definition setting section for setting an alert definition; an alert definition execution unit that executes the set alert definition; an execution result generation unit that performs an abnormality determination for an alert target based on an execution result of the alert definition and generates a determination result based on the abnormality determination; an execution history generating unit that generates an execution history of the executed alert definition; an output control unit that controls output of the generated determination result and the execution history to an output device; An anomaly detection device having the above configuration.

2. a definition change history generating unit that generates a definition change history of the alert definition when the alert definition is changed, the output control unit controls output of the definition change history to the output device together with the determination result and the execution history; The anomaly detection device according to claim 1 .

3. An authority setting unit that sets handling authority for the alert definition; and an authority change history generating unit that generates an authority change history of the handling authority when the handling authority is changed, the output control unit controls output of the authority change history to the output device together with the determination result, the execution history, and the definition change history; The anomaly detection device according to claim 2 .

4. the definition change history generation unit, when the alert definition is changed, generates the definition change history in which generation information indicating that the changed alert definition is the latest alert definition is added to the alert definition after the change, and generates the definition change history in which generation information indicating that the other alert definitions are older generations is added to the alert definition after the change; The anomaly detection device according to claim 3 .

5. the authority change history generating unit, when the handling authority is changed, generates the authority change history by adding generation information indicating that the changed handling authority is the latest handling authority to the handling authority after the change, and generates the authority change history by adding generation information indicating that the other handling authorities are handling authorities of older generations; The anomaly detection device according to claim 4 .

6. The alert definition setting unit includes an alert definition setting step for setting an alert definition; an alert definition execution step in which an alert definition execution unit executes the set alert definition; an execution result generating step in which an execution result generating unit performs an abnormality determination for an alert target based on an execution result of the alert definition, and generates a determination result based on the abnormality determination; an execution history generating step in which an execution history generating unit generates an execution history of the executed alert definition; an output control step in which an output control unit controls output of the generated determination result and the execution history to an output device; The anomaly detection method includes the steps of:

7. Computer, An alert definition setting section for setting an alert definition; an alert definition execution unit that executes the set alert definition; an execution result generation unit that performs an abnormality determination for an alert target based on an execution result of the alert definition and generates a determination result based on the abnormality determination; an execution history generating unit that generates an execution history of the executed alert definition; functioning as an output control unit that controls output of the generated determination result and the execution history to an output device; An anomaly detection program characterized by:

Images