Computer program product, system and method for updating detection models and maintaining data privacy

Abstract

A system for updating a detection model includes at least one local node, the at least one local node including a monitoring module, a diagnostic module, and an evaluation module. The system receives at least one model update and analyzes the model update and the current model and data present in the local node and determines whether the update should be applied. In some embodiments, the local node can generate a model update for use in other local nodes without sharing private data present in the local node.

Description

Technical Field

[0001] The present application generally relates to systems and methods of using the same for evaluating and sharing detection models while maintaining data privacy. Background Art

[0002] Analytical models for event detection are important for a range of fields and industries. For example, different analytical models are used to detect bank fraud, help regulatory compliance, and many other complex data-driven problems. Many fields require the latest models for accurate and timely event detection. In some fields (e.g., many types of fraud), third-party agents are actively working to evade detection by current analytical models. Thus, a system for updating detection models is needed that allows distribution, analysis, and implementation of model updates on multiple local nodes of the system in a fast manner. Further, since the manual creation of updated detection models can be a slow and time-consuming process, a system is needed that creates its own model updates from successful event detections, and then distributes the created model updates to the rest of the system while maintaining data privacy at the location where the model updates were created. Summary of the invention

[0003] One aspect of the present invention provides a system for updating a detection model, comprising: at least one local node, including: a monitoring module; a diagnostic module; an evaluation module; one or more current detection models; and a memory, which includes instructions executed by at least one processor, the instructions being configured to: receive a model update by the monitoring module; determine the current monitoring model by the diagnostic module; determine by the evaluation module whether the model update should be applied to the current monitoring model; determine by the evaluation module whether the local node has permission to apply the model update; and update the current detection model by the evaluation module using the model update.

[0004] In some embodiments, the system further includes at least a second local node; a central module, wherein the monitoring module of each local node is in electronic communication with the central module; and a memory including instructions executed by at least one processor, the instructions being configured to: create a model update, the model update comprising: detecting a significant change in system data by the diagnostic module; determining by the diagnostic a list of all current detection models involved in the detection step; analyzing by the diagnostic module the system data involved in the detection step; generating the model update by the diagnostic module; transmitting by the monitoring module; distributing the model update, comprising: receiving the model update by the central module; analyzing by the central module a database of available models; determining by the central module a priority for the model update; determining by the central module which local nodes should receive the model update; and transmitting by the central module; and updating at least one local node, comprising: receiving the model update by at least one monitoring module; determining by at least one diagnostic module the current monitoring model; determining by at least one evaluation module whether the model update should be applied to the current monitoring model; determining by at least one evaluation module whether the local node has permission to apply the model update; and updating the current detection model with the model update by at least one evaluation module.

[0005] According to another aspect of the present invention, a computer-implemented method in a data processing system is provided, the data processing system comprising a processor and a memory, the memory comprising instructions, the instructions being executed by the processor to enable the processor to implement a system for updating a detection model, the method comprising: updating at least one local node, comprising: receiving a model update by a monitoring module of at least one local node; determining by a diagnostic module of the local node the current monitoring model being used by the local node; determining by an evaluation module of the local node whether the model update should be applied to the current monitoring model; determining by the evaluation module of the local node whether the local node has permission to apply the model update; and updating the current detection model using the model update by the evaluation module of the local node.

[0006] According to another aspect of the present invention, a computer program product for updating a detection model is provided, the computer program product comprising at least one computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processor so that the processor updates at least one local node through the following operations: receiving the model update by at least one monitoring module; determining the current detection model by at least one diagnostic module; determining whether the model update should be applied to the current detection model by at least one evaluation module; determining whether the local node has permission to apply the model update by at least one evaluation module; and updating the current detection model by using the model update by at least one evaluation module.

[0007] According to another aspect of the present invention, a computer program product for creating and updating a detection model is provided, the computer program product comprising at least one computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a processor to cause the processor to: create a model update, the model update comprising: detecting a significant change in system data by a diagnostic module; determining by the diagnostic module a list of all current detection models involved in detecting the significant change; analyzing by the diagnostic module the system data involved in detecting the significant change; generating by the diagnostic module the model update, wherein the generated model update does not include any system data; and transmitting by a monitoring module the model update; distributing the model update The invention relates to a novel novel detection system, comprising: receiving the model update by a central module; analyzing a database of available models by the central module; determining a priority for the model update by the central module; determining which local nodes should receive the model update by the central module; and transmitting the model update to at least one local node by the central module; and updating at least one local node, comprising: receiving the model update by at least one monitoring module; determining a current detection model by at least one diagnostic module; determining whether the model update should be applied to the current detection model by at least one evaluation module; determining whether the local node has permission to apply the model update by at least one evaluation module; and updating the current detection model by using the model update by at least one evaluation module.

[0008] According to another aspect of the present invention, a computer program product for creating and updating a detection model is provided, the computer program product comprising at least one computer-readable storage medium having program instructions embodied therein, which program instructions can be executed by a processor to cause the processor to: create a model update, comprising: detecting a significant change in system data by a first diagnostic module; determining a list of all current detection models involved in detecting the significant change by the first diagnostic module; analyzing the system data involved in detecting the significant change by the first diagnostic module; generating the model update by the first diagnostic module, wherein the generated model update does not include any system data; and transmitting the model update by a first monitoring module; and updating at least a second local node, comprising: receiving the model update by at least a second monitoring module; determining the current detection model by at least a second diagnostic module; determining whether the model update should be applied to the current detection model by at least a second evaluation module; determining whether the local node has permission to apply the model update by at least the second evaluation module; and updating the current detection model using the model update by at least the second evaluation module.

[0009] Additional features and advantages of the present disclosure will become apparent from the following detailed description of illustrative embodiments, which proceeds with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The foregoing and other aspects of the disclosure are best understood from the following detailed description when read in conjunction with the accompanying drawings. For the purpose of illustrating the disclosure, presently preferred embodiments are shown in the drawings, however, it is to be understood that the disclosure is not limited to the specific embodiments disclosed.

[0011] Figure 1 depicts a block diagram of an exemplary update system including a single local node;

[0012] Figure 2 depicts a block diagram of an exemplary update system including a plurality of local nodes connected via a central module;

[0013] Figure 3 depicts a block diagram of an exemplary update system including a plurality of directly connected local nodes;

[0014] Figure 4 A flow chart illustrating an exemplary method of updating an analysis system using an update system and manually created model updates;

[0015] Figure 5 A flow chart depicting an exemplary method of updating an analysis system using a model update created by one of the local nodes; wherein the local nodes are connected by a central module;

[0016] Figure 6 A flow chart depicting an exemplary method of updating an analysis system using an updated model created by one of the local nodes, wherein the local nodes are directionally connected; and

[0017] Figure 7 A block diagram of an example data processing system is depicted in which aspects of the illustrative embodiments may be implemented. DETAILED DESCRIPTION

[0018] The description and claims may utilize the terms "one," "at least one," and "one or more" with respect to particular features and elements of the illustrative embodiments. It should be understood that these terms and phrases are intended to state that there is at least one of a particular feature or element in a particular illustrative embodiment, but more than one may also be present. That is, these terms / phrases are not intended to limit the description or claims to a single feature / element being present or to require the presence of a plurality of such features / elements. Rather, these terms / phrases require only at least a single feature / element, wherein a plurality of such features / elements may be within the scope of the description and claims.

[0019] In addition, it should be understood that the following description uses multiple different examples of various elements of the illustrative embodiments to further illustrate exemplary implementations of the illustrative embodiments and to aid in understanding the mechanisms of the illustrative embodiments. These examples are intended to be non-limiting and not exhaustive of the various possibilities for implementing the mechanisms of the illustrative embodiments. In view of this specification, it will be apparent to one of ordinary skill in the art that there are many other alternative implementations of these different elements that may be utilized in addition to or in place of the examples provided herein without departing from the scope of the present disclosure.

[0020] The present disclosure may be a system, method, and / or computer program product. The computer program product may include one or more computer-readable storage media having computer-readable program instructions thereon for causing a processor to perform aspects of the present invention.

[0021] Computer readable storage medium can be a tangible device that can retain and store instructions for use by instruction execution devices. Computer readable storage medium can be, for example but not limited to, electronic storage device, magnetic storage device, optical storage device, electromagnetic storage device, semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, head disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encoding device such as punch card or a protruding structure in a groove with instructions recorded thereon, and any suitable combination of the above. Computer readable storage medium as used herein should not be interpreted as a temporary signal itself, such as radio waves or other free propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (e.g., light pulses passing through fiber optic cables) or electrical signals emitted by wires.

[0022] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network), or downloaded to an external computer or external storage device. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0023] Computer readable program instructions for performing operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java. TM, Smalltalk, C++, etc.), and conventional procedural programming languages ​​(such as "C" programming language or similar programming languages). Computer-readable program instructions can be executed entirely on a user's computer, partially on a user's computer, as a stand-alone software package, partially on a user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any type of network (including a LAN or WAN), or can be connected to an external computer (e.g., using an Internet service provider through the Internet). In some embodiments, electronic circuits including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) can execute computer-readable program instructions by personalizing the electronic circuit using state information of the computer-readable program instructions so as to perform various aspects of the present disclosure.

[0024] Various aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of boxes in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0025] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which causes the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium in which the instructions are stored includes a manufactured product containing instructions for implementing aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0026] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in or in multiple boxes in the flowchart and / or block diagram.

[0027] The present invention will be described below with reference to the flowchart and / or block diagram of the method, device (system) and computer program product according to the embodiment of the present invention. It should be understood that each box of the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer readable program instructions.

[0028] The flow chart and block diagram in the accompanying drawings show the architecture, function and operation of the possible implementation of the system, method and computer program product according to different embodiments of the present invention. To this end, each box in the flow chart or block diagram may represent a module, segment or part of an instruction, which includes one or more executable instructions for realizing the specified logical function. In some alternative embodiments, the function indicated in the box may not occur in the order indicated in the figure. For example, depending on the function involved, the two blocks shown in succession can actually be performed substantially simultaneously, or these blocks can sometimes be performed in reverse order. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be realized by a dedicated hardware-based system that performs a specified function or action or performs a combination of special hardware and computer instructions.

[0029] As an overview, a cognitive system is a specialized computer system or collection of computer systems configured with hardware and / or software logic (in combination with the hardware logic on which the software executes) to emulate human cognitive functions. These cognitive systems apply human-like characteristics to convey and manipulate ideas, which, when combined with the inherent strength of digital computing, can solve problems with high accuracy and resilience at scale. IBM Watson TM is an example of a cognitive system that can process human-readable language at a much faster rate and on a much larger scale than humans and identify inferences between passages of text with human-like accuracy. Typically, such a cognitive system can perform the following functions:

[0030] Navigating the complexities of human language and understanding

[0031] Ingest and process large amounts of structured and unstructured data

[0032] Generate and evaluate hypotheses

[0033] Weigh and evaluate responses based only on relevant evidence

[0034] Provide specific consultation, insights and guidance

[0035] Improve knowledge through the machine learning process and learn with each iteration and interaction

[0036] Enable decision making at the point of impact (contextual guidance)

[0037] Scale proportionally to the task

[0038] Extending and amplifying human expertise and cognition

[0039] Identify resonance, human attributes, and characteristics of natural language

[0040] Infer various language-specific or language-agnostic properties from natural language

[0041] From a highly relevant collection of data points (images, text, speech, memory and recall)

[0042] Situational awareness prediction and awareness based on experience in human cognition

[0043] Answer questions based on natural language and specific evidence.

[0044] Embodiments herein relate to systems for updating analysis models across multiple local nodes. As used herein, a separate "local node" refers to software installed by an end user (such as an individual or a company). In some embodiments, the local node includes a computer system. In some embodiments, the local node includes multiple computer systems or servers controlled by the end user. In some embodiments, each local node in the system uses a set of current analysis models specific to the local node. In some embodiments, each local node in the system accesses and analyzes system data generated by one or more analysis models. This system data is dedicated to each local node and may include sensitive or confidential information.

[0045] As used herein, a separate "analytic model" or just a "model" is a software algorithm designed to detect certain events using data analysis techniques. In some embodiments, the analytical model detects data anomalies. In some embodiments, the analytical model detects fraud events. In some embodiments, the data analysis techniques used by the analytical model include, but are not limited to, data preprocessing techniques, calculations of one or more statistical parameters, statistical ratios based on classifications or groups, calculations of probabilities, classification techniques such as data clustering and data matching, regression analysis, and gap analysis. In some embodiments, the software of the local node includes one or more analytical models. In some embodiments, the software of the local node includes one or more analytical models and deterministic rules. In some embodiments, the software of the local node includes one or more analytical models for fraud detection. In some embodiments, the software of the local node includes one or more analytical models for regulatory compliance or non-compliance. In some embodiments, the software of the local node includes one or more models and deterministic rules for fraud detection. In some embodiments, the software of the local node includes one or more models and deterministic rules for regulatory compliance or non-compliance.

[0046] In some embodiments, the update system receives one or more model updates and pushes these updates to applicable local nodes. In some embodiments, the update system pushes updates to all local nodes in the system. In some embodiments, the update system pushes updates only to selected local nodes. In some embodiments, the update system determines which local nodes receive model update pushes.

[0047] In some embodiments, each individual local node that receives a model update checks the update against the current model of the analysis system, and if applicable, the update system updates the current model. In some embodiments, the update system receives one or more manually created model updates. In some embodiments, the update system receives one or more model updates created by local nodes of the update system. In some embodiments, the local nodes of the update system are connected by a central hub or module that is not itself a local node. In some embodiments, the local models of the update system are directly connected to each other, for example as a decentralized network.

[0048] In some embodiments, the update system, including any local nodes, is a standalone system that creates and pushes model updates to any software system that uses the analytical model. In some embodiments, the update system itself is a component or subsystem of a larger analytical system (e.g., an analytical system for fraud detection).

[0049] Figure 1 Depicted is a block diagram representation of the components, outputs, and data flows of an exemplary single local node of the update system 100. The local node includes three main modules or subsystems: a monitoring module 101, a diagnostic module 102, and an evaluation module 103.

[0050] The monitoring module 101 monitors one or more factors to determine whether a model update process is needed. In some embodiments, the monitoring module 101 checks the time since the last update process and initiates the update process if sufficient time has passed. In some embodiments, the monitoring module 101 initiates the update process if 6 hours, 12 hours, 1 day, 2 days, 3 days, 4 days, 5 days, 6 days, 7 days, 10 days, 15 days, 30 days, 1 month, 2 months, 3 months, 6 months, or 1 year have passed since the last update process. In some embodiments, the monitoring module 101 initiates the update process in the event that a model update is pushed from a source external to the local node 100. For example, the monitoring module 101 may receive a model update pushed from a central module of the update system, another local node, or directly from an update system administrator.

[0051] In some embodiments, the monitoring module 101 may initiate an update process when signaled by the diagnostic module 102. In some embodiments, the diagnostic module 102 analyzes the system data 104 and may signal the monitoring module 101 to initiate an update process if one or more data thresholds have been met. For example, if the diagnostic module's analysis of the system data 104 indicates that event detection has increased above a data threshold or event detection has decreased below a data threshold, the diagnostic module 102 may signal the monitoring module 101. In some embodiments, the data threshold may be manually set, for example, by an end user. In some embodiments, the data threshold may be automatically determined by the diagnostic module 102, for example, if the event detection rate increases by a significant value over a one-week moving average detection rate.

[0052] When the update process is initiated, the monitoring module 101 will query for available model updates. In some embodiments, the monitoring module 101 will query a central module of the update system, another local module, or an update system administrator. In some embodiments, if the update process is initiated by a model update pushed from a source external to the local node 100, the monitoring module 101 will not query for additional available model updates. In some embodiments, if the update process is initiated by a model update pushed from a source external to the local node 100, the monitoring module 101 will still query for additional available model updates.

[0053] When the monitoring module 101 has completed all available queries and has received at least one model update, the monitoring module 101 passes the model update to the diagnostic module 102. The diagnostic module 102 compares the model update to the database of current models 105 available in the local node. In some embodiments, the diagnostic module 102 will classify model updates to current models 105, regardless of whether those current models 105 are actively used. In some embodiments, the diagnostic module 102 will classify model updates to system data 104 generated by applying active current models 105.

[0054] When the diagnostic module 102 has received a model update and at least compared the model update to the database of current models 105, the diagnostic module 102 will pass the model update and all available comparison and other analysis data to the evaluation module 103. The evaluation module 103 will evaluate the model update to determine whether the update 106 should be applied. In some embodiments, the evaluation module 103 will automatically apply the model update, thereby changing or modifying the current model 105 with the model update. In some embodiments, the evaluation module 103 will analyze the model update to determine whether such a model already exists in the database of current models 105. In some embodiments, the evaluation module 103 will run the model update on the relevant system data 104 or the relevant classification data generated by the diagnostic module 102 to determine whether the model update will provide the local node 100 with system data that is different from the system data that the current model 105 can generate. In some embodiments, the evaluation module 103 will not automatically apply any updates or perform any analysis unless authorized by the end user or administrator of the local node 100.

[0055] Figure 2 A block diagram representing components, outputs and data flows of an update system having a plurality of local nodes 200 is depicted. The update system comprises a central module 201 connecting all local nodes in the update system 200. Figure 2 Two local nodes, generally categorized as 210 and 220, are depicted. In some embodiments, there is no limit to the number of local nodes that may be present in update system 200. It should be understood that local nodes 210 and 220 are generally associated with Figure 1 2, each including a monitoring module 211, 221, a diagnostic module 212, 222, and an evaluation module 213, 223. Each local node further includes its own database of system data 214, 224 and current model 215, 225. It should be understood that each local node may have different system data and current model. In some embodiments, system data 214 may or may not be the same as or similar to system data 224. In some embodiments, current model 215 may or may not be the same as or similar to current model 225.

[0056] The central module 201 does not exist in any local node, but exists in a separate location, such as a centralized management server. In some embodiments, the central module 201 can send and receive information from the monitoring modules 211, 221. In some embodiments, the central module 201 can send and receive information from any monitoring module in the update system. The central module 201 can access the main database of available models 202 of the update system. The database of available models 202 is a list of all possible analysis models currently present in the update system. In some embodiments, the database of current models in a separate node (e.g., current model 215) is equivalent to the data set of available models 202. In some embodiments, the database of current models in a separate node (e.g., current model 215) is not equivalent to the data set of available models 202, but contains at least one model in common with the database of available models 202.

[0057] In some embodiments, when a monitoring module in an individual node (eg, monitoring module 211 ) initiates a query for available model updates, the monitoring module will electronically communicate with central module 201 .

[0058] In some embodiments, each individual node may communicate with one or more end users. Figure 2 In some embodiments, the evaluation module 213 of the node 210 can communicate with the end user 217. In some embodiments, any module of the separate node can communicate with the end user. In some embodiments, the separate node communicates with the end user to provide the end user with information about the update process. In some embodiments, the separate node communicates with the end user to provide the end user with information about the results of the update, such as which models are updated. In some embodiments, the separate node communicates with the end user to request the end user's authorization before updating any model.

[0059] Figure 3 Another block diagram representation of the components, outputs, and data flows of an update system having multiple local nodes 300 is depicted. The update system 300 depicts two local nodes, generally categorized as 310 and 320. In some embodiments, there is no limit to the number of local nodes that may be present in the update system 300. It should be understood that the local nodes 310 and 320 are similar to the local nodes 310 and 320. Figure 1 and 231, 321, a diagnostic module 312, 322, and an evaluation module 313, 323. Each local node further includes its own database of system data 314, 324 and current models 315, 325. It should be understood that each local node may have different system data and current models. In some embodiments, system data 314 may or may not be the same as or similar to system data 324. In some embodiments, current model 315 may or may not be the same as or similar to current model 325.

[0060] and Figure 2 Unlike the update system 300, the update system 300 does not have any type of central module that connects all local nodes. Instead, each local node is directly connected to each other via a network. In some embodiments, each monitoring module is in electronic communication with each other monitoring module in the update system 300. For example, Figure 3 As shown, monitoring module 311 is in electronic communication with monitoring module 321 .

[0061] In some embodiments, when the update process has been initiated in a separate node, the monitoring module of the node will query another local node in the update system 300. For example, when the update process is initiated in the local node 310, the monitoring module 311 will query the monitoring module 321 of the local node 320. In some embodiments, when the update process has been initiated in a separate node, the monitoring module of the node will query all other local nodes in the update system 300. In some embodiments, when the update process has been initiated in a separate node, the monitoring module of the node will only query selected other nodes in the update system 300. In some embodiments, when the update process is initiated in a separate node, the monitoring module of the node will only query one other node in the update system 300.

[0062] In any embodiment herein, the system administrator can create an updated model and manually add it to the update system. For example, the system administrator can create an updated model and submit the model to the central module 201, such as Figure 2 As another example, the system administrator can create an updated model and submit the model to the monitoring module 321, such as Figure 3 In some embodiments, when an updated model has been added to any update system described herein, an update process may be initiated in all nodes of all nodes in the update system.

[0063] In any embodiments herein, any local node of the update system can initiate a model update and automatically push it to the rest of the update system. In some embodiments, it is advantageous for a local node to generate its own model updates because this allows the update system to quickly respond to increases in fraud detection without requiring end-user or administrator involvement. For example, Figure 2 The diagnostic module 212 shown analyzes the system data 214 and detects an increase in fraud detection greater than a preset threshold. The diagnostic module 212 continues to list one or more models for detecting an increase in fraud, and analyzes the system data 214 to determine key features and conditions of the connection between one or more models and the data. The diagnostic module 212 then strips the model of any specific data to the system data 214 and the local node 210. The monitoring module 211 then sends the model to the central module 201, which then determines whether the model is suitable for use as a model update to update the system 200.

[0064] In any embodiment where a local node initiates a model update of an update system, it is important that the specific system data of the local node is not shared with any central hub or other local nodes in the update system. In some embodiments, the diagnostic module that creates the model to be shared with the update system creates a new model that is independent of any specific system data from the local node. In some embodiments, the new model includes one or more of the following: one or more algorithms, creation date and time, the number of events detected in a given time period, metadata or advanced aggregate statistics (such as total transaction time value), and one or more threshold points for triggering an update. In some embodiments, the new model includes ratio statistics of one or more data group averages. In some embodiments, the new model can detect deviations from ratio statistics of one or more data group averages to determine future positive results. In some embodiments, the new model includes one or more networks or image graphs representing one or more models. In some embodiments, the new model includes one or more networks or image graphs representing the new model.

[0065] In any embodiment herein, the components of the update system may be stored, for example, in the same location as the software installed in the internal server system at a company (such as a bank). In some embodiments, some components of any update system disclosed herein are stored in different locations, such as as part of a cloud-based service.

[0066] Figure 4 A flow chart depicts an exemplary method for pushing model updates using manually created models in an update system having a central module 400. In some embodiments, the method 400 may be used with Figure 2401. First, a system administrator manually creates a new model to be used to update system 401. In some embodiments, the new model includes a new or updated algorithm or multiple algorithms. In some embodiments, the new model includes information about the criteria necessary for the use of the new model, such as the type of business, the amount of system data required, or the type of detection performed by the model. In some embodiments, the new model includes priority information about how critical the model is to the update system. For example, a new model that must be pushed out to all local nodes will be given the highest possible priority. In some embodiments, the priority information is classified as low priority, medium priority, or high priority.

[0067] Next, the new model created by the system administrator is pushed to the update system which receives the model 402. In some embodiments, the central module of the update system receives the model. Upon receiving the model 402, the central module then updates the model database 403. For example, the central module 201 updates Figure 2 The database of available models 202 in the updating system 200 is depicted in FIG.

[0068] The update system will then determine applicable end users for the new model 404. In some embodiments, the central module determines which end users are applicable. In some embodiments, in addition to the priority information of the new model, the central module determines which end users the model update is applicable to by comparing the standard information in the new model with the information about each end user. For example, if the model update for credit card fraud detection has a medium priority, the central module will identify which local nodes in the update system are involved in credit card fraud detection, and then push the model 405 to those identified local nodes. The model update will not be pushed to any remaining local nodes, however, when each of those remaining local nodes initiates the update process, for example, if enough time has passed to trigger the monitoring module without an update, the local node can receive the update. In another example, if the model update for credit card fraud detection has a high priority, the central module will output the model 405 to all local nodes. In another example, if the model update for credit card fraud detection has a low priority, the central module will not immediately push the model to any local node, but wait for each local node to initiate the update process itself.

[0069] Once the model update has been sent from the central module, it is received by at least one local node 411. In some embodiments, the model update is received by multiple local nodes simultaneously. In some embodiments, the model update is received by the monitoring module of any embodiment described herein.

[0070] In some embodiments, once a local node receives a model update 411, it is not automatically installed. First, the local node will consult the current model database to see if the model update will replace any existing models 412. Then, the local node will determine the relevance of the model update to the node 413. For example, in Figure 2 In the local node 210 of the update system 200 depicted in FIG, the model update is received by the monitoring module 211 and then passed to the diagnostic module 212. The diagnostic module 212 first consults the current model 215 database and then determines the relevance of the model update to the local node 210. In some embodiments, the diagnostic module 212 will end the update process after the determine relevance step 413. In some embodiments, if the diagnostic module 212 determines that the model update is not needed for the local node, the diagnostic module 212 will end the update process after the determine relevance step 413. In some embodiments, if the diagnostic module 212 determines that the model update is already present in the local node, the diagnostic module 212 will end the update process after the determine relevance step 413. In some embodiments, if the model update carries a high priority, the diagnostic module 212 will automatically bypass the determine relevance step 413.

[0071] In some embodiments, once the local node has determined that a model update will be relevant or necessary, the local node will determine whether it has permission to apply the model update 414. In some embodiments, the evaluation module of the local node determines whether the local node has permission to apply the model update. In some embodiments, the local node will not have permission to install the model update. In some embodiments, the local node will not have automatic permission to install any model update. In some embodiments, the local node must consult or ask for permission from the end user before installing the model update 416. For example, once the diagnostic module 212 has determined that the model update is relevant or the model update has a high enough priority to bypass the determine relevance step 413, the model update is passed to the evaluation module 213. The evaluation module 213 then checks the update permission settings of the local node. In some embodiments, if the evaluation module 213 determines that it does not have permission to install the model update, the evaluation module 213 will end the update process. In some embodiments, before installing the model update, the evaluation module 213 will consult the end user, for example, by issuing a user prompt or by sending an email or other communication to the end user.

[0072] Once the local node determines that it has permission to do so 415, the local node will install the model update. In some embodiments, the assessment module installs the model update. In some embodiments, any module of the update system installs the model update. In some embodiments, the model update installs one or more new models to the current model database in the local node. In some embodiments, the model update replaces one or more models in the current model database in the local node. For example, after permission has been established, the assessment module 213 updates the current model 215 database with the model update.

[0073] In some embodiments, once the update 415 is complete, the local node creates an output report 417. In some embodiments, the output report is shared with the end user. In some embodiments, the output report is shared with a central module of the update system. In some embodiments, the output report contains information about the model update, including, for example, the type of model updated, whether any old models are replaced, the date and time of the update, whether the new model is currently valid, or any combination thereof.

[0074] Figure 5 A flow chart depicts an exemplary method of pushing model updates in an update system having a central module, wherein model updates are automatically created from local nodes in the update system 500. In some embodiments, the method 500 may be used with Figure 2 501 . First, a local node in the update system will detect changes in the results from its existing model 501. In some embodiments, the local node in the update system will detect a change in the fraud detection rate. In some embodiments, the change in the fraud detection rate is an increase in fraud detections that is greater than a preset threshold. In some embodiments, the change in the fraud detection rate is a significant increase or decrease in fraud over a given time period. In some embodiments, the local node in the update system will detect a change in the magnitude of fraud detected. In some embodiments, the change in the magnitude of fraud is an increase in the value or dollar amount of a detected fraudulent event that is greater than a preset threshold. In some embodiments, the change in the magnitude of fraud is a significant increase in the value or dollar amount of a detected fraudulent event compared to a moving average or average of the detected events. For example, as Figure 2 The diagnostic module 212 depicted in FIG. 2 analyzes the system data 214 and detects an increase in the fraud detection rate that is greater than a standard deviation from a 3-month moving average fraud detection rate.

[0075] Once a change in results from their existing models has been detected 501, the local node will list all models involved in the detection 502. In some embodiments, the local node will list all models directly involved in producing the event detected in step 501. In some embodiments, the local node will list all models directly and indirectly involved in producing the event detected in step 501. In some embodiments, the local node will list all models that were actively running when the event was detected in step 501. For example, by accessing both the system data 214 and current models 215 databases, the diagnostic module 212 will list all algorithmic models directly and indirectly involved in producing the fraud event previously detected in step 501.

[0076] Once the local node has listed the models 502 associated with the detected changes 501, the local node will analyze the data 503 involved in generating the events that led to the detected changes. In some embodiments, the local node analyzes system data to determine the features and conditions associated with the models listed in step 502 in generating the events detected in step 501. In some embodiments, the local node analysis may include, but is not limited to, ordinary least squares, penalized regression, generalized additive models, quantile regression, logistic regression, and gated linear models. In some embodiments, the local node analysis will be a transformed variant of one or more related models that reduce the complexity of those models. For example, monotonicity constraints are imposed on nonlinear, non-monotonic models to orient the model around variable relationships that are known to be true, or the use of monotonic neural networks for machine learning applications. In some embodiments, the relevant visualization will be a related but less complex model that approximates an applicable model or models, especially machine learning models. For example, alternative models, locally interpretable model-agnostic explanations (LIME), maximum activation analysis, linear regression, and sensitivity analysis.

[0077] Once the local node has listed the model 502 and analyzed the relevant data 503, the local node can generate features 504 of the model update that will be sent to the rest of the update system. In some embodiments, the diagnostic module of the local node generates the model features 504. In some embodiments, the features of the model update are agnostic to the local node, that is, the model update can be used by any local node in the update system. Therefore, the model update generated by the local node is stripped of any specific data of the local node. In some embodiments, the model update features include one or more of the following: one or more algorithms, creation date and time, the number of events detected over a given time period, metadata or high-level aggregate statistics (such as total transaction time value), and one or more threshold points for triggering updates. In some embodiments, the model update features include ratio statistics of one or more data group averages. In some embodiments, the model update can detect deviations from the ratio statistics of one or more data group averages to determine future positive results. In some embodiments, the model update features include one or more network or image graphs representing one or more models. In some embodiments, the model update features include one or more network or image graphs representing new models.

[0078] Once the local node has generated the model features 504, the local node may output a model update 505. In some embodiments, the local node will output the model update to a central module of the update system that receives the model update 506. For example, the monitoring module 211 of the local node 210 may receive the model update from the diagnostic module 212, and then the monitoring module 211 may send the model update to the central module 201 that receives the model update.

[0079] Upon receiving a model update 506 from a local node, the central module of the update system will then consult the model database 507. In some embodiments, the central module consults the model database to determine whether the model update already exists. In some embodiments, the central module consults the model database to determine whether the model update replaces an existing model in the database or is a new model for the database. In some embodiments, when the central module consults the model database and determines that the model update can replace or modify an existing model in the database, the central module can pull model information about the existing model. In some embodiments, the model information can include one or more of the following: the model creation date and time, the date and time the model was last updated, and how many local nodes currently use the model. For example, upon receiving a model update from a local node 210, the central module 201 checks the model update against the available models 202 database. The central module 201 determines whether the model update already exists in the available models 202 database, and if so, the central module 201 will pull relevant information about any existing models.

[0080] After the central module of the update system consults the model database 507, the central module will then determine the priority of the model update 508. In some embodiments, the priority of the model update will be listed as high, medium, or low. In some embodiments, the priority level of the model update will be listed on a numerical scale, such as between a range of 1 to 10 or other common numerical ranges. In some embodiments, the central module determines the priority of the model update by comparing the model update characteristics to a predetermined scale. In some embodiments, the central module determines the priority of the model update by comparing the model update characteristics to the model database. In some embodiments, the central module determines the priority of the model update by comparing the model update characteristics to the model information stored in the existing model database. In some embodiments, the comparison of the model update characteristics to the existing model information produces a priority level, which is then converted into a priority level.

[0081] For example, after the central module 201 of the update system 200 checks the model update for credit card fraud detection against the available model database 202, the central module 201 determines that a similar model already exists in the database and pulls information about the existing model. The central module 201 then compares the model update features with the existing model information and calculates a priority level. As a first example, the central module determines that the existing model for credit card fraud detection has not been updated in a year, the model update is a direct replacement of the existing model, and the model update can increase the performance of detecting credit card fraud over a certain range of usage conditions. These differences result in a high priority level, which the central module 201 changes to a high priority level. As a second example, the central module determines that the existing model for credit card fraud detection has been updated recently, and the model update will only be expected to improve the performance of detecting credit card fraud with a sufficiently large user base that only a few end users are known to have. These differences result in a relatively low priority level, which the central module 201 changes to a medium priority level.

[0082] After determining the priority, the update system will then determine the end users 509 to which the new model is applicable. In some embodiments, the central module determines which end users are applicable. In some embodiments, in addition to the priority information of the new model, the central module determines which end users the model update is applicable to by comparing the model update features with the information about each end user. For example, if the model update for credit card fraud detection has a medium priority, the central module will identify which local nodes in the update system are involved in credit card fraud detection, and then push the model 510 to those identified local nodes. The model update will not be pushed to any remaining local nodes, but when each of those remaining local nodes initiates the update process, for example, if enough time has passed to trigger the monitoring module without an update, the local node can receive the update. In another example, if the model update for credit card fraud detection has a high priority, the central module will output the model 510 to all local nodes. In another example, if the model update for credit card fraud detection has a low priority, the central module will not immediately push the model to any local node, but wait for each local node to initiate the update process itself.

[0083] Once the model update has been sent from the central module, it is received by at least one local node 511. In some embodiments, the model update is received by multiple local nodes simultaneously. In some embodiments, the model update is received by the monitoring module of any embodiment described herein.

[0084] In some embodiments, once a local node receives a model update 511, it is not automatically installed. First, the local node will consult the current model database to see if the model update will replace any existing models 512. Then, the local node will determine the relevance of the model update to the node 513. For example, in Figure 2 In the local node 210 of the update system 200 depicted in FIG, the model update is received by the monitoring module 211 and then passed to the diagnostic module 212. The diagnostic module 212 first consults the current model 215 database and then determines the relevance of the model update to the local node 210. In some embodiments, the diagnostic module 212 will end the update process after the determine relevance step 513. In some embodiments, if the diagnostic module 212 determines that the model update is not needed for the local node, the diagnostic module 212 will end the update process after the determine relevance step 513. In some embodiments, if the diagnostic module 212 determines that the model update is already present in the local node, the diagnostic module 212 will end the update process after the determine relevance step 513. In some embodiments, if the model update carries a high priority, the diagnostic module 212 will automatically bypass the determine relevance step 513.

[0085] In some embodiments, once the local node has determined that a model update will be relevant or necessary, the local node will determine whether it has permission to apply the model update 514. In some embodiments, the evaluation module of the local node determines whether the local node has permission to apply the model update. In some embodiments, the local node will not have permission to install the model update. In some embodiments, the local node will not have automatic permission to install any model update. In some embodiments, the local node must consult or ask for permission from the end user before installing the model update 516. For example, once the diagnostic module 212 has determined that the model update is relevant or the model update has a high enough priority to bypass the determined relevance step 513, the model update is passed to the evaluation module 213. The evaluation module 213 then checks the update permission settings of the local node. In some embodiments, if the evaluation module 213 determines that it does not have permission to install the model update, the evaluation module 213 will end the update process. In some embodiments, before installing the model update, the evaluation module 213 will consult the end user, for example, by issuing a user prompt or by sending an email or other communication to the end user.

[0086] Once the local node determines 515 that it has permission to do so, the local node will install the model update. In some embodiments, the assessment module installs the model update. In some embodiments, any module of the update system installs the model update. In some embodiments, the model update installs one or more new models to the current model database in the local node. In some embodiments, the model update replaces one or more models in the current model database in the local node. For example, after permission has been established, the assessment module 213 updates the current model 215 database with the model update.

[0087] In some embodiments, once the update 515 is complete, the local node creates an output report 517. In some embodiments, the output report is shared with the end user. In some embodiments, the output report is shared with a central module of the update system. In some embodiments, the output report contains information about the model update, including, for example, the type of model updated, whether any old models are replaced, the date and time of the update, whether the new model is currently valid, or any combination thereof.

[0088] Figure 6 A flowchart depicts an exemplary method for pushing model updates in an update system without a central module, wherein model updates are automatically created from local nodes in the update system 600. In some embodiments, the method 600 may be used with Figure 3601. In some embodiments, the local node in the update system will detect a change in the results from its existing model 601. In some embodiments, the local node in the update system will detect a change in the fraud detection rate. In some embodiments, the change in the fraud detection rate is an increase in fraud detections that is greater than a preset threshold. In some embodiments, the change in the fraud detection rate is a significant increase or decrease in fraud over a given time period. In some embodiments, the local node in the update system will detect a change in the magnitude of fraud detected. In some embodiments, the change in the magnitude of fraud is an increase in the value or dollar amount of a detected fraudulent event that is greater than a preset threshold. In some embodiments, the change in the magnitude of fraud is a significant increase in the value or dollar amount of a detected fraudulent event compared to a moving average or average of the detected events. For example, as Figure 3 The diagnostic module 312 depicted in FIG. 3 analyzes the system data 314 and detects an increase in the fraud detection rate that is greater than the standard deviation of the 3 month moving average fraud detection rate.

[0089] Once a change in results from its existing models has been detected 601, the local node will list all models involved in the detection 602. In some embodiments, the local node will list all models directly involved in producing the event detected in step 601. In some embodiments, the local node will list all models directly and indirectly involved in producing the event detected in step 601. In some embodiments, the local node will list all models that were actively running when the event 601 was detected in step. For example, by accessing both the system data 314 and the current model database 315, the diagnostic module 312 will list all algorithmic models directly and indirectly involved in producing the fraud event previously detected in step 601.

[0090] Once the local node has listed the model 602 associated with the detected change 601, the local node will analyze the data 603 involved in the event that caused the detected change. In some embodiments, the local node analyzes system data to determine the features and conditions associated with the model listed in step 602 when generating the event detected in step 601. In some embodiments, the local node analysis can include, but is not limited to, ordinary least squares, penalized regression, generalized additive models, quantile regression, logistic regression, and gated linear models. In some embodiments, the local node analysis will be a transformed variant of one or more related models that reduce the complexity of those models. For example, monotonicity constraints are imposed on nonlinear, non-monotonic models to orient the model around variable relationships that are known to be true, or the use of monotonic neural networks for machine learning applications. In some embodiments, the relevant visualization will be a related but less complex model that approximates an applicable model or models, especially machine learning models. For example, alternative models, locally interpretable model-agnostic explanations (LIME), maximum activation analysis, linear regression, and sensitivity analysis.

[0091] Once the local node has listed the model 602 and analyzed the relevant data 603, the local node can generate features 604 of the model update that will be sent to the rest of the update system. In some embodiments, the diagnostic module of the local node generates the model features 604. In some embodiments, the features of the model update are agnostic to the local node, that is, the model update can be used by any local node in the update system. Therefore, the model update generated by the local node is stripped of any specific data of the local node. In some embodiments, the model update features include one or more of the following: one or more algorithms, creation date and time, the number of events detected over a given time period, metadata or high-level aggregate statistics (such as total transaction time value), and one or more threshold points for triggering updates. In some embodiments, the model update features include ratio statistics of one or more data group averages. In some embodiments, the model update can detect deviations from the ratio statistics of one or more data group averages to determine future positive results. In some embodiments, the model update features include one or more network or image graphs representing one or more models. In some embodiments, the model update features include one or more network or image graphs representing new models.

[0092] Once the local node has generated the model features 604, the local node may output a model update 605. In some embodiments, the local node will output the model update to at least one other local node of the update system, which receives the model update 611. In some embodiments, the local node will output the model update to all other local nodes of the update system. For example, the monitoring module 311 of the local node 310 may receive the model update from the diagnostic module 312, and then the monitoring module 311 may send the model update to another local node 320 that receives the model update.

[0093] In some embodiments, once a local node receives a model update 611, it is not automatically installed. First, the local node will consult the current model database to see if the model update will replace any existing models 612. Then, the local node will determine the relevance of the model update to the node 613. For example, in Figure 3 In the local node 310 of the update system 300 depicted in FIG, the model update is received by the monitoring module 311 and then passed to the diagnostic module 312. The diagnostic module 312 first queries the current model database 315 and then determines the relevance of the model update to the local node 310. In some embodiments, the diagnostic module 312 will end the update process after the determine relevance step 613. In some embodiments, if the diagnostic module 312 determines that the local node does not need a model update, the diagnostic module 312 will end the update process after the determine relevance step 613. In some embodiments, if the diagnostic module 312 determines that the model update already exists in the local node, the diagnostic module 312 will end the update process after the determine relevance step 613.

[0094] In some embodiments, once the local node has determined that a model update will be relevant or necessary, the local node will determine whether it has permission to apply the model update 614. In some embodiments, the evaluation module of the local node determines whether the local node has permission to apply the model update. In some embodiments, the local node will not have permission to install the model update. In some embodiments, the local node will not have automatic permission to install any model update. In some embodiments, the local node must consult or ask for permission from the end user before installing the model update 616. For example, once the diagnostic module 312 has determined that the model update is relevant, the model update is passed to the evaluation module 313. The evaluation module 313 then checks the update permission settings of the local node. In some embodiments, if the evaluation module 313 determines that it does not have permission to install the model update, the evaluation module 313 will end the update process. In some embodiments, before installing the model update, the evaluation module 313 will consult the end user, for example, by issuing a user prompt or by sending an email or other communication to the end user.

[0095] Once the local node determines that it has permission to do so 615, the local node will install the model update. In some embodiments, the assessment module installs the model update. In some embodiments, any module of the update system installs the model update. In some embodiments, the model update installs one or more new models to the current model database in the local node. In some embodiments, the model update replaces one or more models in the current model database in the local node. For example, after permission has been established, the assessment model 313 updates the current model database 315 with the model update.

[0096] In some embodiments, once the update 615 is complete, the local node creates an output report 617. In some embodiments, the output report is shared with the end user. In some embodiments, the output report is shared with a central module of the update system. In some embodiments, the output report contains information about the model update, including, for example, the type of model updated, whether any old models are replaced, the date and time of the update, whether the new model is currently valid, or any combination thereof.

[0097] In some embodiments, the user of any system disclosed herein can be one or more human users, such as known "human-in-the-loop" systems. In some embodiments, the user of any system disclosed herein can be a computer system, artificial intelligence ("AI"), cognitive or non-cognitive algorithm, etc.

[0098] The following table is a non-exclusive and non-exhaustive list of examples of using any of the systems and methods disclosed herein:

[0099]

[0100] Figure 7 A block diagram of an example data processing system 700 in which aspects of the illustrative embodiments are implemented is depicted. Data processing system 700 is an example of a computer (such as a server or client) in which computer usable code or instructions implementing the processes for any disclosed illustrative embodiments described herein are located. In some embodiments, Figure 7 represents a server computing device, such as a server, that implements a system for interpreting analysis results described herein.

[0101] In the depicted example, data processing system 700 may employ a hub architecture that includes north bridge and memory controller hub (NB / MCH) 701 and south bridge and input / output (I / O) controller hub (SB / ICH) 702. Processing unit 703, main memory 704, and graphics processor 705 may be connected to NB / MCH 701. Graphics processor 705 may be connected to NB / MCH 701 via an accelerated graphics port (AGP). Network adapter 706 is connected to SB / ICH 702. Audio adapter 707, keyboard and mouse adapter 708, modem 709, read-only memory (ROM) 710, hard disk drive (HDD) 711, optical disk drive (CD or DVD) 712, universal serial bus (USB) ports and other communication ports 713, and PCI / PCIe devices 714 may be connected to SB / ICH 702 via bus system 716. PCI / PCIe devices 714 may include Ethernet adapters, plug-in cards, and PC cards for notebook computers. ROM 710 may be, for example, a flash memory basic input / output system (BIOS). HDD 711 and optical drive 712 may use an integrated drive electronics (IDE) or a serial advanced technology attachment (SATA) interface. Super I / O (SIO) device 715 may be connected to SB / ICH 702.

[0102] An operating system may run on processing unit 703. The operating system may coordinate and provide control of the various components within data processing system 700. As a client, the operating system may be a commercially available operating system. An object-oriented programming system (such as Java) may be used to program the data. TM A programming system) may run in conjunction with the operating system and provide calls to the operating system from object-oriented programs or applications executing on data processing system 700. As a server, data processing system 700 may be a server running an advanced interactive execution operating system or Operating System eServer TM System Data processing system 700 may be a symmetric multiprocessor (SMP) system which may include multiple processors in processing unit 703. Alternatively, a single processor system may be employed.

[0103] Instructions for the operating system, object-oriented programming system, and applications or programs are located on a storage device, such as HDD 711, and are loaded into main memory 704 for execution by processing unit 703. The processes of an embodiment of the medical record error detection system may be performed by processing unit 703 using computer usable program code, which may be located in a memory, such as main memory 704, ROM 710, or one or more peripheral devices.

[0104] The bus system 716 may include one or more buses. The bus system 716 may be implemented using any type of communication structure or architecture that can provide data transmission between different components or devices attached to the structure or architecture. A communication unit (such as a modem 709 or a network adapter 706) may include one or more devices that can be used to transmit and receive data.

[0105] Those of ordinary skill in the art will recognize that the hardware required to run any of the systems and methods described herein may vary depending on the embodiment. Other internal hardware or peripherals, such as flash memory, equivalent non-volatile memory, or optical drives, may be used in addition to or in place of the hardware depicted. Furthermore, any system described herein may take the form of any of many different data processing systems, including but not limited to client computing devices, server computing devices, tablet computers, laptop computers, telephones or other communication devices, personal digital assistants, and the like. In essence, any system described herein may be any known or later developed data processing system, without architectural limitations.

[0106] The system and method of the accompanying drawings are not exclusive. Other systems and processes can be derived according to the principles of the embodiments described herein to achieve the same purpose. It should be understood that the embodiments and modifications shown and described herein are only for illustrative purposes. Without departing from the scope of the present embodiment, those skilled in the art can modify the current design. As described herein, different systems, subsystems, agents, managers and processes can be implemented using hardware components, software components and / or combinations thereof.

[0107] Although the present invention has been described with reference to exemplary embodiments, the present invention is not limited thereto. It will be appreciated by those skilled in the art that many changes and modifications may be made to the preferred embodiments of the present invention. Therefore, the appended claims are intended to be interpreted as covering all such equivalent changes that fall within the scope of the present invention.

Claims

1. A computer program product for updating a detection model, the computer program product comprising at least one computer-readable storage medium, the at least one computer-readable storage medium comprising program instructions, the program instructions being executable by a processor to cause the processor to perform the following operations: Create model updates, including: detecting changes in system data by a diagnostic module; In response to detecting a change in the system data, determining, by the diagnostic module, a list of all currently detected models involved in detecting the change; In response to detecting a change in the system data, analyzing, by the diagnostic module, the system data involved in detecting the change; as well as generating, by the diagnostic module, a model update, wherein the generated model update does not include any system data of a local node generating the model update; Update at least one local node, including: Receiving the model update by a monitoring module of at least one local node; Determining the current detection model by a diagnostic module of at least one local node; determining, by an evaluation module of at least one local node, whether the model update should be applied to the current detection model; determining, by an evaluation module of at least one local node, whether the local node has permission to apply the model update; and updating the current detection model using the model update by an evaluation module of at least one local node, The model update includes a model update feature for updating the detection model. 2 . The computer program product of claim 1 , wherein program instructions executable by the processor further cause the processor to distribute the model update to the at least one local node.

3. The computer program product of claim 2, wherein the model update is distributed to at least two local nodes.

4. The computer program product of claim 2, wherein the model updates are distributed to the at least one local node by a central module.

5. The computer program product of claim 4, wherein the central module distributes the model update to the at least one local node by: receiving, by the central module, the model update; Analyzing the database of available models by the central module; determining, by the central module, a priority for updating the model; determining, by the central module, which local nodes should receive the model update; as well as The model update is transmitted by the central module to the at least one local node.

6. The computer program product of claim 5, wherein the database of available models includes models available to all local nodes.

7. The computer program product of claim 5, wherein the priority is determined by comparing characteristics of the model update with model information in an existing model database.

8. The computer program product of claim 2, wherein the model update is distributed to the at least one local node by another local node.

9. The computer program product of claim 1 , wherein the generated model updates include one or more elements selected from the group consisting of: one or more algorithms, a creation date and time, a number of events detected within a given time period, aggregate statistics, and one or more threshold points for triggering the model updates.

10. The computer program product of claim 1, wherein the monitoring module transmits the model updates to a central module external to the local node.

11. The computer program product of claim 1 , wherein the monitoring module transmits the model update to the monitoring module from another local node.

12. A system for updating a detection model, comprising: At least one local node, including: Monitoring module; Diagnostic module; Assessment module; one or more current detection models; and system data generated by the current detection model; and A memory comprising instructions executed by at least one processor, the instructions being configured to: Create model updates, including: detecting, by the diagnostic module, changes in system data; In response to detecting a change in the system data, determining, by the diagnostic module, a list of all currently detected models involved in detecting the change; In response to detecting a change in the system data, analyzing, by the diagnostic module, the system data involved in detecting the change; and generating, by the diagnostic module, a model update, wherein the generated model update does not include any system data of a local node generating the model update; Updating the at least one local node comprises: Receiving a model update by a monitoring module of at least one local node; Determining the current detection model by a diagnostic module of at least one local node; determining, by an evaluation module of at least one local node, whether the model update should be applied to the current detection model; determining, by an evaluation module of at least one local node, whether the local node has permission to apply the model update; and updating the current detection model using the model update by an evaluation module of at least one local node, The model update includes a model update feature for updating the detection model.

13. The system of claim 12, wherein the system further comprises at least two local nodes.

14. The system of claim 13, wherein the system further comprises a central module, and wherein the monitoring module of each local node is in electronic communication with the central module.

15. The system of claim 14, wherein the system further comprises a database of all available models of the system in electronic communication with the central module.

16. The system of claim 14, wherein the monitoring module is configured to receive model updates.

17. The system of claim 16, wherein the monitoring module is capable of receiving model updates from a system administrator or from a local node.

18. The system of claim 12, wherein the generated model updates include one or more elements selected from the group consisting of: one or more algorithms, a creation date and time, a number of events detected within a given time period, aggregate statistics, and one or more threshold points for triggering the model updates.

19. The system of claim 12, further comprising: a central module, wherein the monitoring module of each local node is in electronic communication with the central module; as well as a database of all available models of said system in electronic communication with said central module; as well as A memory comprising instructions executed by at least one processor, the instructions being configured to: Distribution model updates, including: receiving, by the central module, the model update; Analyzing the database of available models by the central module; determining, by the central module, a priority for updating the model; determining, by the central module, which local nodes should receive the model update; and The model updates are transmitted by the central module.

20. A computer-implemented method in a data processing system, the data processing system comprising a processor and a memory, the memory comprising instructions executed by the processor to cause the processor to implement a system for updating a detection model, the method comprising: Create model updates, including: detecting changes in system data by a diagnostic module; In response to detecting a change in the system data, determining, by the diagnostic module, a list of all currently detected models involved in detecting the change; In response to detecting a change in the system data, analyzing, by the diagnostic module, the system data involved in detecting the change; and generating, by the diagnostic module, a model update, wherein the generated model update does not include any system data of a local node generating the model update; Update at least one local node, including: Receiving a model update by a monitoring module of at least one local node; Determining, by a diagnostic module of at least one local node, a current detection model being used by the local node; determining, by an evaluation module of at least one local node, whether the model update should be applied to the current detection model; determining, by an evaluation module of at least one local node, whether the local node has permission to apply the model update; and updating the current detection model using the model update by an evaluation module of at least one local node, The model update includes a model update feature for updating the detection model.

21. The method of claim 20, wherein the method further comprises updating at least two local nodes.

22. The method of claim 21, wherein the method further comprises distributing the model updates by a central module.

23. The method of claim 22, wherein the method further comprises analyzing, by the central module, a database of available models.

24. The method of claim 22, wherein the method further comprises determining, by the central module, a priority for the model update.

25. The method of claim 22, wherein the method further comprises determining, by the central module, which local nodes should receive the model update.

26. The method of claim 20, wherein the generated model updates include one or more elements selected from the group consisting of: one or more algorithms, a creation date and time, a number of events detected within a given time period, aggregate statistics, and one or more threshold points for triggering the model update.

27. The method of claim 20, further comprising: Distribute said model updates, including: Receiving the model update by the central module; The database of available models is analyzed by a central module; determining, by the central module, a priority for updating the model; determining, by the central module, which local nodes should receive the model update; and The model update is transmitted by the central module to at least one local node.

Images