JP2022548945A - Updating detection models and maintaining data confidentiality - Google Patents

Abstract

A system for updating detection models comprises at least one local node comprising a monitoring module, a diagnostic module and an evaluation module. The system receives at least one model update and analyzes the model update and current models and data residing at the local node to determine if the update should be applied. In some embodiments, local nodes may generate model updates for use by other local nodes, but do not share private data residing on local nodes.

Description

This application relates generally to systems for evaluating and sharing detection models while maintaining data confidentiality, and methods for using such systems.

Analytical models for event detection are important to various fields and industries. For example, various analytical models are used to detect financial fraud, aid in regulatory compliance, and many other complex data-driven problems. Many fields require state-of-the-art models for accurate and timely event detection. In some areas (eg, many types of fraud), third-party operatives actively seek to escape detection by current analytical models. Accordingly, there is a need for a system for updating detection models that allows model updates to be distributed across multiple local nodes of the system, analyzed, and implemented in a rapid manner. In addition, manual creation of updated detection models can be a slow and time-consuming process, so the nodes create their own model updates from successful event detections, and then the locations where the model updates were created. What is needed is a system that distributes generated model updates to other parts of the system while maintaining data confidentiality.

One aspect of the present invention provides a system for updating detection models, the system includes a monitoring module, a diagnostic module, an evaluation module, one or more current detection models, and and a memory containing instructions, the instructions being executed by the at least one processor and receiving model update information by the supervisory module. determining, by the diagnostic module, the current detection model; determining, by the evaluation module, whether the model update information should be applied to the current detection model; It is configured to perform the steps of determining whether permission to apply the model update information is obtained, and updating a current detection model using the model update information by the evaluation module.

In some embodiments, the system includes at least a second local node, a central module, and electronic communication with the central module, wherein a monitoring module of each local node is in electronic communication with the central module. a database of all models available in the system for performing diagnostic detecting, by a module, significant changes in system data; determining, by a diagnostic module, a list of all current detection models involved in the detection step; creating and distributing model updates, including analyzing the data, generating model updates by a diagnostic module, and sending model updates by a monitoring module; , receiving model update information by a central module; analyzing a database of available models by the central module; prioritizing model update information by the central module; distributing and updating at least one local node, including determining which local nodes should receive the model update information; and sending the model update information by the central module. receiving model update information by at least one monitoring module; determining a current detection model by at least one diagnostic module; determining whether the model update information should be applied to the model; determining, by at least one evaluation module, whether the local node is authorized to apply the model update information; and updating a current detection model using the information.

According to another aspect of the invention, a computer-implemented method is provided in a data processing system comprising a processor and a memory containing instructions, the instructions being executed by the processor, causing the processor to: Having a system update detection model implemented, the method includes receiving, by at least one local node's monitoring module, model update information; Determining a detection model; determining by an evaluation module of the local node whether model update information should be applied to the current detection model; at least one local node, including determining whether it has permission to apply the update information; and updating a current detection model using the model update information by an evaluation module of the local node. including updating the

According to another aspect of the invention, a computer program product is provided for updating a detection model, the computer program product comprising at least one computer readable storage medium having program instructions embodied therein. , program instructions executable by a processor and instructing the processor to receive model update information by at least one monitoring module; to determine a current detection model by at least one diagnostic module; determining, by one evaluation module, whether model update information should be applied to a current detection model; and obtaining permission for at least one local node to apply the model update information, by at least one evaluation module. and updating the current detection model using the model update information by at least the evaluation module to update the local node.

According to yet another aspect of the invention, a computer program product is provided for creating and updating a detection model, the computer program product comprising at least one computer readable storage having program instructions embodied therein. The medium comprises program instructions executable by a processor, the processor producing model update information, detecting, by a diagnostic module, significant changes in system data; determining a list of all current detection models involved in detecting the significant change; analyzing, by the diagnostic module, system data involved in detecting the significant change; , generating model update information, wherein the generated model update information does not include any system data; and transmitting the model update information by the monitoring module. distributing the model update information, receiving the model update information by the central module, analyzing the database of available models by the central module, and distributing the model update information by the central module. determining priority; determining by the central module which local nodes should receive the model update information; and transmitting the model update information to at least one local node by the central module. updating at least one local node, receiving model update information by at least one monitoring module; and updating current detected models by at least one diagnostic module. determining, with at least one evaluation module, whether the model update information should be applied to the current detection model; and at least one evaluation module, with the local node applying the model update information. Determining whether permission is obtained; and updating, by at least one evaluation module, a current detection model using the model update information is performed.

According to yet another aspect of the invention, a computer program product is provided for creating and updating a detection model, the computer program product comprising at least one computer readable storage having program instructions embodied therein. The medium comprises program instructions executable by a processor, the processor producing model update information, detecting, by a first diagnostic module, a significant change in system data; Determining a list of all current detection models involved in detecting significant changes by one diagnostic module and system data involved in detecting significant changes by the first diagnostic module generating model update information by the first diagnostic module, wherein the generated model update information does not include any system data; generating by the first monitoring module , sending model update information, updating at least a second local node, receiving the model update information by at least a second monitoring module, and at least determining a current detection model by a second diagnostic module; determining by at least a second evaluation module whether model update information should be applied to the current detection model; and at least a second evaluation. determining, by the module, whether the local node has permission to apply the model update information; and updating, by at least a second evaluation module, the current detection model using the model update information. including, updating and running.

Other features and advantages of the present disclosure will become apparent from the following detailed description of example embodiments that proceeds with reference to the accompanying drawings.

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

FIG. 2 shows a block diagram of an exemplary update system with a single local node; FIG. 1 shows a block diagram of an exemplary update system comprising multiple local nodes connected by a central module; 1 depicts a block diagram of an exemplary update system comprising multiple directly connected local nodes; FIG. FIG. 3 depicts a flow chart of an exemplary method of updating an analysis system using an update system and manually created model update information. FIG. 4 depicts a flow chart of an exemplary method in which local nodes are connected by a central module and update an analysis system using model update information made by one of the local nodes. FIG. 10 depicts a flow chart of an exemplary method in which local nodes are directly connected and update an analysis system using model update information made by one of the local nodes. 1 depicts a block diagram of an exemplary data processing system in which aspects of example embodiments may be implemented; FIG.

The description and claims use the terms “a,” “at least one of,” and “one or more of” with respect to specific features and elements of example embodiments. I have something to do. These terms and phrases are intended to state that at least one of the particular features or elements present in a particular example embodiment is present, but there may be more than one. should be understood. That is, these terms/phrases are not intended to limit the description or claims to any single feature/element present, rather than requiring the presence of a plurality of such features/elements. nor is it intended to be On the contrary, these terms/phrases require at least a single feature/element only, and multiple such features/elements may be present within the description and claims.

In addition, the following description uses multiple different examples of various elements of the example embodiments to further describe example implementations of the example embodiments and aid in understanding the mechanisms of the example embodiments. It should be understood that. These examples are intended to be non-limiting and do not exhaust the various possible implementations of the mechanisms of the example embodiments. In view of the present description, many other examples of these various elements may be utilized in addition to or in place of the examples provided herein without departing from the scope of the present disclosure. It will be apparent to those skilled in the art that alternative implementations exist.

The present disclosure may be a system, method, or computer program product, or any combination thereof. The computer program product may include a computer-readable storage medium containing computer-readable program instructions for causing a processor to perform aspects of the present disclosure.

A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. not. A non-exhaustive list of more specific examples of computer readable storage media include portable floppy disks, head disks, random access memory (RAM), read only memory (ROM). -only memory), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM: compact disc read-only memory), digital versatile disk (DVD: digital versatile disk), memory stick, floppy (R) disk, punch card or in a slot containing instructions Including mechanically encoded devices such as raised structures, and any suitable combination thereof. As used herein, a computer-readable storage medium is itself a radio wave or other freely propagating electromagnetic wave, or an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., passing through a fiber optic cable). It should not be interpreted as a transient signal such as a light pulse) or an electrical signal sent over a wire.

The computer readable program instructions described herein can be transferred from a computer readable storage medium to each computing device/processing device or over a network (e.g., Internet, local area network (LAN), wide area network). (wide area network (WAN), or wireless network, or a combination thereof) to an external computer or external storage device. The network may comprise copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing device/processing device receives computer readable program instructions from the network and translates those computer readable program instructions into a computer readable network within each computing device/processing device. Transfer for storage on a storage medium.

Computer readable program instructions for performing the operations of the present disclosure include assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or any one or more programming languages, including object-oriented programming languages such as Java(R)(TM), Smalltalk, C++, and traditional procedural programming languages such as the "C" programming language or similar programming languages. It may be source code or object code written in combination. The computer-readable program instructions may execute wholly on the user's computer, partially on the user's computer as a stand-alone software package, partially on the user's computer and partially on the remote computer, respectively. It can run on a remote computer or run entirely on a server. In the latter scenario, the remote computer may be connected to the user's computer via any kind of network, including a LAN or WAN, or the connection may be via the Internet (e.g., using an Internet service provider). via) to an external computer. In some embodiments, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) are used to implement aspects of the present disclosure. ) may execute computer readable program instructions to customize the electronic circuit by utilizing the state information of the computer readable program instructions.

Aspects of the disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions are the means by which instructions executed via a processor of a computer or other programmable data processing apparatus perform the functions/acts specified in the flowchart illustrations and/or block diagrams. For production, it may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine. These computer readable program instructions are specific such that the computer readable storage medium on which the instructions are stored comprises instructions for implementing aspects of the functions/operations specified in the flowchart and/or block diagram blocks. stored in a computer-readable storage medium and capable of instructing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in any manner.

Computer readable program instructions are instructions that are executed on a computer or other programmable apparatus or device to perform the functions/acts specified in the flowcharts and/or block diagrams. , computer, other programmable data processing apparatus, or other device, thereby producing a series of operational steps on the computer, other programmable apparatus, or computer-implemented process. Make it run on other devices.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products, according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing the specified logical function. . In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or possibly in the reverse order, depending on the functionality involved. Each block in the block diagrams and/or flowchart illustrations, and combinations of blocks contained in the block diagrams and/or flowchart illustrations, perform the specified function or operation, or implement a combination of dedicated hardware and computer instructions. Note also that it may be implemented by a dedicated hardware-based system for execution.

As an overview, a cognitive system is a specialized computer system, or set of computer systems, configured with hardware logic or software (combined with hardware logic on which software executes) to emulate human cognitive functions. Constructed using logic or both. These cognitive systems apply human-like characteristics to communicating and manipulating ideas to solve large-scale problems with great precision and flexibility when combined with the inherent strengths of digital computing. be able to. IBM(R) Watson(TM) is an example of such a cognitive system, which processes human-readable language and makes inter-passage estimations of text with human-like accuracy, much faster and faster. Large numbers can be identified. In general, such cognitive systems are capable of performing the following functions.

Embodiments herein relate to a system for updating analytical models across multiple local nodes. As used herein, an individual "local node" refers to software installed by an end user, such as an individual or company. In some embodiments, the local node comprises one computer system. In some embodiments, the local node includes multiple computer systems or servers controlled by end users. In some embodiments, each local node in the system uses a current set of analytical models that are unique to that local node. In some embodiments, each local node in the system accesses and analyzes system data generated by one or more analytical models. This system data is unique to each local node and may contain sensitive or private information.

As used herein, an individual "analytic model" or simply "model" is a software algorithm designed to detect specific events using data analysis techniques. In some embodiments, the analytical model detects anomalies in data. In some embodiments, the analytical model detects fraudulent events. In some embodiments, the data analysis techniques used by the analytical model include data preprocessing techniques, computation of one or more statistical parameters, statistical proportions based on classifications or groups, computation of probabilities, clustering of data and Including, but not limited to, classification techniques such as data collation, regression analysis, and gap analysis. In some embodiments, the local node's software includes one or more analytical models. In some embodiments, the local node's software includes one or more analytical models and deterministic rules. In some embodiments, the local node's software includes one or more analytical models for fraud detection. In some embodiments, the local node's software includes one or more analytical models for regulatory compliance or non-compliance. In some embodiments, local node software includes one or more models and deterministic rules for fraud detection. In some embodiments, the local node's software includes one or more models and deterministic rules for regulatory compliance or non-compliance.

In some embodiments, an update system receives one or more model updates and pushes those 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 to selected local nodes only. In some embodiments, the update system determines which local nodes receive pushes of model update information.

In some embodiments, each local node that receives model update information checks the update information 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 made by local nodes of the update system. In some embodiments, the local nodes of the update system are connected by a central hub or central module that is not itself a local node. In some embodiments, the local nodes of the update system are directly connected to each other, eg, as a distributed network.

In some embodiments, the update system, including any local node, is a standalone system that creates and pushes model update information for any software system that uses analytical models. In some embodiments, the update system itself is a component or subsystem of a larger analysis system (eg, analysis system for fraud detection).

FIG. 1 shows a block diagram representation of the components, outputs and data flows of an exemplary single local node of update system 100 . The local node contains three main modules or subsystems: monitoring module 101, diagnostic module 102, and evaluation module 103.

Monitoring module 101 monitors one or more factors to determine if a model update process is required. In some embodiments, the monitoring module 101 checks the time since the last update process and initiates the update process if enough time has passed. In some embodiments, the monitoring module 101 updates 6 hours, 12 hours, 1 day, 2 days, 3 days, 4 days, 5 days, 6 days, 7 days, 10 days, 15 days after the last update process. , 30 days, 1 month, 2 months, 3 months, 6 months, or 1 year, initiate the renewal process. In some embodiments, the monitoring module 101 initiates the update process when it receives model update information pushed from a source external to the local node 100 . For example, the monitor module 101 can receive model update information pushed from a central module of the update system, from another local node, or directly from an update system administrator.

In some embodiments, the monitoring module 101 can initiate the update process when signaled by the diagnostic module 102 . In some embodiments, diagnostic module 102 analyzes system data 104 and signals monitoring module 101 to initiate an update process when one or more data thresholds are met. be able to. For example, diagnostic module 102 may notify monitoring module 101 if diagnostic module analysis of system data 104 indicates an increase in event detections above a data threshold or a decrease in event detections below a data threshold. can be signaled to In some embodiments, the data threshold can be set manually, eg, by an end user. In some embodiments, the data threshold may be automatically determined by the diagnostic module 102, for example, when the event detection rate increases by a significant value above the weekly moving average of the detection rate. can.

When the update process is initiated, the monitor module 101 queries for available model update information. In some embodiments, the monitoring module 101 queries a central module of the update system, another local node, or an update system administrator. In some embodiments, if the update process was initiated by model update information pushed from a source external to the local node 100, the monitor module 101 does not query for additional available model update information. In some embodiments, if the update process was initiated by model update information pushed from a source external to the local node 100, the monitoring module 101 further queries for additional available model update information.

When the monitor module 101 has completed all available queries and received at least one model update, the monitor module 101 passes the model update information to the diagnostic module 102 . The diagnostic module 102 compares model update information with a database 105 of current models available at the local node. In some embodiments, diagnostic module 102 classifies model updates into current models 105 regardless of whether those current models 105 are actively in use. In some embodiments, diagnostic module 102 classifies model update information into system data 104 generated by application of active current model 105 .

When the diagnostic module 102 receives the model update information and at least compares the model update information to the current model database 105, the diagnostic module 102 analyzes the model update information and all available comparisons and other analytical data. Pass to evaluation module 103 . Evaluation module 103 evaluates model updates to determine whether updates 106 should be applied. In some embodiments, evaluation module 103 automatically applies model updates and uses model updates to change or modify current model 105 . In some embodiments, the evaluation module 103 analyzes the model update information to determine whether such models already exist in the current model database 105 . In some embodiments, the assessment module 103 performs model updates on relevant system data 104 or relevant categorical data generated by the diagnostic module 102, and the model update information is the current model 105 determines whether to provide system data to the local node 100 that is different than what the . In some embodiments, the assessment module 103 does not automatically apply any updates or perform any analysis unless authorized by the end user or administrator of the local node 100 .

FIG. 2 shows a block diagram representation of the components, outputs and data flows of an update system including multiple local nodes 200 . The update system comprises a central module 201 connecting all local nodes within the update system 200 . FIG. 2 shows two local nodes generally labeled 210 and 220 . In some embodiments, there is no limit to the number of local nodes that can exist within update system 200 . It will be appreciated that local nodes 210 and 220 are generally the same as the local nodes described in FIG. It should be. Each local node further includes its own system data 214,224 and current model database 215,225. It should be appreciated that each local node may contain different system data and current models. In some embodiments, system data 214 may be the same as or similar to system data 224 or may not be the same or similar to system data 224 . In some embodiments, current model 215 may be the same as or similar to current model 225 or may not be the same or similar to current model 225 .

The central module 201 does not reside in any local node, but in a separate location such as a centralized management server. In some embodiments, central module 201 can send and receive information from monitoring modules 211 , 221 . In some embodiments, central module 201 can send and receive information from any monitoring module in the update system. The central module 201 has access to a master database 202 of models available to the update system. The available models database 202 is a list of all possible analytical models that currently exist in the update system. In some embodiments, the database of current models (eg, current models 215 ) in individual nodes is equivalent to dataset 202 of available models. In some embodiments, the database of current models (e.g., current models 215) in an individual node is not equivalent to dataset 202 of available models, but is common to database of available models 202. contains at least one model that

In some embodiments, when a supervisory module (e.g., supervisory module 211) within an individual node initiates a query for available model update information, the supervisory module electronically communicates with central module 201. .

In some embodiments, individual nodes can communicate with one or more end users. In FIG. 2, for example, assessment module 213 of node 210 may communicate with end user 217 . In some embodiments, any module of an individual node can communicate with end users. In some embodiments, a separate node communicates with the end user and provides the end user with information regarding the update process. In some embodiments, a separate node communicates with the end user and provides the end user with information about the results of the update (eg, which models have been updated). In some embodiments, an individual node communicates with the end user and asks the end user for permission before updating any models.

FIG. 3 shows another block diagram representation of the components, outputs and data flows of an update system that includes multiple local nodes 300 . Update system 300 shows two local nodes generally labeled as 310 and 320 . In some embodiments, there is no limit to the number of local nodes that can exist within update system 300 . that local nodes 310 and 320 are generally the same as the local nodes described in FIGS. 1 and 2 and include monitoring modules 311, 321, diagnostic modules 312, 322, and evaluation modules 313, 323, respectively; should be understood. Each local node further includes its own system data 314,324 and current model database 315,325. It should be appreciated that each local node may contain different system data and current models. In some embodiments, system data 314 may be the same as or similar to system data 324 or may not be the same or similar to system data 324 . In some embodiments, current model 315 may be the same as or similar to current model 325 or may not be the same or similar to current model 325 .

Unlike FIG. 2, update system 300 does not include any kind of central module connecting all local nodes. Instead, each local node is directly connected to each other through the network. In some embodiments, each monitor module is in electronic communication with every other monitor module within update system 300 . For example, as shown in FIG. 3, monitor module 311 is in electronic communication with monitor module 321 .

In some embodiments, when an update process is initiated on an individual node, that node's monitoring module queries another local node in the update system 300 . For example, when an update process is initiated on local node 310 , monitoring module 311 queries monitoring module 321 on local node 320 . In some embodiments, when an update process is initiated on an individual node, that node's monitoring module queries all other local nodes in the update system 300 . In some embodiments, when an update process is initiated on an individual node, that node's monitoring module queries only selected other nodes in the update system 300 . In some embodiments, when an update process is initiated on an individual node, that node's monitoring module queries only one other node in the update system 300 .

In any of the embodiments herein, a system administrator can create updated models and manually add them to the update system. For example, a system administrator can create an updated model and submit it to central module 201 as shown in FIG. In another example, a system administrator can create an updated model and submit it to monitoring module 321, as shown in FIG. In some embodiments, when an updated model is added to any of the update systems shown herein, an update process may be initiated across all or some of the nodes in the update system. .

In any of the embodiments herein, any local node of the update system can generate and automatically push model updates to other local nodes of the update system. In some embodiments, local nodes that generate their own model updates are advantageous because the update system can quickly respond to increases in fraud detections without end-user or administrator involvement. . For example, as shown in FIG. 2, diagnostic module 212 analyzes system data 214 and detects an increase in fraud detections greater than a preset threshold. Diagnostics module 212 was then used to detect increases in fraud and analyze system data 214 to determine key features and conditions of connections between one or more models and data. , to create a list of one or more models. Diagnostic module 212 then removes system data 214 and all data specific to local node 210 from the model. The monitoring module 211 then sends the model to the central module 201, which then determines whether the model is applicable to the update system 200 as model update information.

In any embodiment where a local node is generating model update information for the update system, that local node's unique system data is not shared with the central hub or other local nodes in the update system. This is very important. In some embodiments, the diagnostic module that creates the model shared with the update system creates a new model that is independent of any unique system data from the local node. In some embodiments, this new model uses one or more algorithms, date and time of creation, number of events detected over a period of time, metadata or high-level data such as total transactional value of time. Contains one or more of the level aggregation statistics and one or more threshold points used to trigger updates. In some embodiments, the new model includes average ratio statistics for one or more data groups. In some embodiments, the new model can detect deviations from the mean proportion statistics of one or more data groups to determine future positive outcomes. In some embodiments, the new model includes one or more network or image graphics representing one or more models. In some embodiments, the new model includes one or more network or image graphics representing the new model.

In any of the embodiments herein, the components of the update system can be co-located, for example, as software installed within an enterprise's internal server system, such as a bank. In some embodiments, some of the components of any update system disclosed herein are stored in different locations, such as part of a cloud-based service.

FIG. 4 shows a flow chart of an exemplary method for pushing model update information to an update system, including central module 400, using a manually created model. In some embodiments, method 400 can be used in the update system shown in FIG. First, a system administrator manually created 401 a new model that was used to update the system. In some embodiments, the new model includes one or more new or updated algorithms. In some embodiments, the new model includes information regarding criteria required for use of the new model (eg, type of business, amount of system data required, or type of detection performed by the model). In some embodiments, the new model includes priority information regarding how important the model is to the update system. For example, new models that must be output to all local nodes are given the highest possible priority. In some embodiments, priority information is categorized as either low priority, medium priority, or high priority.

A new model created by the system administrator is then pushed to the update system, which receives the model (402). In some embodiments, a central module of the update system receives the model. After receiving the model (402), the central module updates (403) the model database. For example, central module 201 updates available model database 202 in update system 200 shown in FIG.

The update system then determines 404 the end users applicable to the new model. In some embodiments, the central module determines which end users are applicable. In some embodiments, the central module determines which end users can apply model update information by comparing baseline information in the new model with information about each end user, in addition to the priority information in the new model. determine whether For example, if the model update information for credit card fraud detection has a medium priority, the central module determines which local nodes in the update system are involved in credit card fraud detection. identify and then output the model to those identified local nodes (405). Model update information is not output to any remaining local nodes, but when each of those remaining local nodes begins the update process, e.g. If so, the local node may receive updates. In another example, if the model update information for credit card fraud detection has high priority, the central module outputs (405) the model to all local nodes. In another example, if the model update information for credit card fraud detection has a low priority, the central module does not immediately output the model to any local node, but instead outputs the model to each local node. • Wait for the node to start the update process on its own.

After the model update information is sent from the central module, the model update information is received (411) by at least one local node. In some embodiments, model update information is received simultaneously by multiple local nodes. In some embodiments, model update information is received by a monitoring module in any of the embodiments described herein.

In some embodiments, the model update information is not automatically installed after the local node receives 411 the model update information. First, the local node queries the current model database to see if the model update replaces any existing models (412). Next, the local node determines (413) the relevance of the model update information with the node. For example, at local node 210 of update system 200 shown in FIG. 2, model update information is received by monitoring module 211 and then passed to diagnostic module 212 . The diagnostic module 212 first queries the current model database 215 and then determines the relevance of the model update information with the local node 210 . In some embodiments, diagnostic module 212 terminates the update process after step 413 of determining relevance. In some embodiments, after the relevance determining step 413, the diagnostic module 212 terminates the update process if the diagnostic module 212 determines that model update information is not required for the local node. . In some embodiments, after the step of determining relevance 413, the diagnostic module 212 terminates the update process if the diagnostic module 212 determines that model update information already exists on the local node. . In some embodiments, diagnostic module 212 automatically bypasses determining relevance step 413 if the model update information has a high priority.

In some embodiments, after the local node determines that the model update information is relevant or required, the local node determines whether it has permission to apply the model update information. Determine (414). In some embodiments, an evaluation module at the local node determines whether the local node has permission to apply model updates. In some embodiments, the local node does not have permission to install model updates. In some embodiments, the local node does not have automatic permission to install model updates. In some embodiments, the local node must query or ask the end user for permission before installing the model update (416). For example, the diagnostic module 212 either determines that the model update information is relevant, or that the model update information has a sufficiently high priority to avoid step 413 of determining relevance. After determining the model update information is passed to the evaluation module 213 . Next, the evaluation module 213 checks the update permission settings of the local node. In some embodiments, if the evaluation module 213 determines that permission to install the model update information is not obtained, the evaluation module 213 terminates the update process. In some embodiments, the evaluation module 213 prompts the end user, for example, by issuing a prompt to the user or by sending an email or other communication to the end user, before installing the model update information. - Ask the user.

After determining that the local node has permission to install the model update, the local node installs the model update (415). In some embodiments, the evaluation module installs model updates. In some embodiments, any module of the update system installs model updates. In some embodiments, the model update information installs one or more new models into the current model database within the local node. In some embodiments, model update information replaces one or more models in the current model database in the local node. For example, after authorization is established, evaluation module 213 updates current model database 215 using model update information.

In some embodiments, after the update 415 is completed, the local node creates an output report (417). In some embodiments, output reports are shared with end users. In some embodiments, the output report is shared with the central module of the update system. In some embodiments, the output report includes information about model update information, e.g., what models were updated, whether any old models were replaced, date and time of update, which new models are currently active Whether or not it contains any combination of these.

FIG. 5 shows a flow chart of an exemplary method of pushing model update information to an update system, including a central module, where model update information is automatically created from local nodes within update system 500 . ing. In some embodiments, method 500 can be used in the update system shown in FIG. First, a local node in the update system detects (501) a change in results from an existing model. In some embodiments, local nodes within the update system detect changes in fraud detection rates. In some embodiments, the change in fraud detection rate is an increase in fraud detections greater than a preset threshold. In some embodiments, the change in fraud detection rate is a significant increase or decrease in fraud over a specified period of time. In some embodiments, a local node within the update system detects changes in the magnitude of detected frauds. In some embodiments, the change in fraud magnitude is an increase in the value or amount of detected fraud events greater than a preset threshold. In some embodiments, the change in fraud magnitude is a significant increase in the value or amount of detected fraud events compared to a moving average of detected events. For example, diagnostic module 212 as shown in FIG. 2 analyzes system data 214 and detects an increase in fraud detection rate that is more than a standard deviation away from the 3-month moving average of fraud detection rate. .

After a change in results from an existing model is detected (501), the local node creates a list (502) of all models involved in the detection. In some embodiments, the local node creates a list of all models directly involved in generating the event detected in step 501 . In some embodiments, the local node creates a list of all models that were directly and indirectly involved in generating the event detected in step 501 . In some embodiments, the local node creates a list of all models that were actively executing when the event was detected in step 501 . For example, if diagnostic module 212, which has access to both system data 214 and current model database 215, is responsible for all of the actions that were directly and indirectly involved in generating the fraud event previously detected in step 501. Create a list of algorithmic models.

After the local node has created (502) a list of models associated with the detected change (501), the local node analyzes the data involved in generating the events leading to the detected change ( 503). In some embodiments, the local node, in analyzing system data and generating events detected in step 501, determines features and conditions associated with the models listed in step 502. . In some embodiments, the local node analysis uses ordinary least squares, penalized regression, generalized additive models, quantile regression, logistic regression, and gated linear models. can include, but are not limited to: In some embodiments, the analysis of local nodes becomes a transformed variant of one or more associated models, reducing the complexity of those models. Examples include imposing monotonicity constraints on non-linear, non-monotonic models in order to adapt the model around variable relationships known to be true, or monotonic neural in machine learning applications.・The use of networks is mentioned. In some embodiments, the relevant visualization is a relevant but less complex model that approximates one or more applicable models, particularly machine learning models. Examples include surrogate models, local interpretable model-agnostic explanations (LIME), maximum activation analysis, linear regression, and sensitivity analysis.

After the local node has created the list of models (502) and analyzed the associated data (503), the local node generates model update features that are sent to other local nodes in the update system. (504). In some embodiments, the diagnostic module of the local node generates (504) model features. In some embodiments, the features of the model update information are independent of local nodes, i.e. the model update information can be used by any local node within the update system. Therefore, all unique data for the local node is removed from the model update information generated by the local node. In some embodiments, model update information features metadata or high-level aggregate statistics such as one or more algorithms, date and time of creation, number of events detected over a specific time period, total transaction time value; and one or more of one or more threshold points used to trigger updates. In some embodiments, model update information features include average ratio statistics for one or more data groups. In some embodiments, model update information can detect deviations from average proportion statistics for one or more data groups to determine future positive outcomes. In some embodiments, model update information features include one or more network or image graphics representing one or more models. In some embodiments, model update information features include one or more network or image graphics representing the new model.

After the local node generates model features (504), the local node can output model update information (505). In some embodiments, the local node outputs model update information to a central module of the update system, which receives the model update information (506). For example, the monitoring module 211 of the local node 210 can receive model update information from the diagnostic module 212, after which the monitoring module 211 can send the model update information to the central module 201, and the central module 201 can Receive model updates.

After receiving model update information from the local node (506), the central module of the update system queries the model database (507). In some embodiments, the central module queries the model database to determine if model update information already exists. In some embodiments, the central module queries the model database to determine if the model update replaces an existing model in the database or is a new model to the database. In some embodiments, if the central module queries the model database and determines that model update information can replace or modify existing models in the database, the central module updates the model information to It can be applied to existing models. In some embodiments, the model information may include one or more of the date and time the model was created, the date and time the model was last updated, and the number of local nodes currently using the model. . For example, when central module 201 receives model update information from local node 210 , it checks model update information against available model database 202 . The central module 201 determines whether model update information already exists in the available model database 202, and if so, the central module 201 applies the relevant information to all existing models.

After the central module of the update system queries the model database (507), the central module determines the priority of the model update information (508). In some embodiments, the priority list for model update information is created as high, medium, or low. In some embodiments, the list of model update priorities is created on a numerical scale, eg, within a range of 1-10, or within other common numerical ranges. In some embodiments, the central module prioritizes model updates by comparing characteristics of the model updates to predetermined measures. In some embodiments, the central module prioritizes model updates by comparing characteristics of the model updates with a model database. In some embodiments, the central module prioritizes model updates by comparing characteristics of model updates with model information stored in existing model databases. In some embodiments, a comparison of features of model update information with existing model information yields priority grades, which are then converted to priorities.

For example, after the central module 201 of the update system 200 checks the model update information for credit card fraud detection against the available model database 202, the central module 201 checks if a similar model is in the database. Determine what already exists and apply the information to the existing model. The central module 201 then compares the features of the model update information with the existing model information and calculates a priority grade. As a first example, the central module determines that an existing model for credit card fraud detection has not been updated in over a year, that the model update information is a direct replacement for the existing model, and model update information can improve the performance of detecting credit card fraud across various conditions of use. These differences result in a high priority grade, which the central module 201 converts to high priority. As a second example, the central module may determine that an existing model for credit card fraud detection has been recently updated, and that the model update information is with a sufficiently large user base and few We decide that we can only hope to improve our ability to detect fraud on credit cards that only end users are known to have. These differences result in a relatively low priority grade, which the central module 201 converts to medium priority.

After determining the priorities, the update system determines (509) which end users are applicable to the new model. In some embodiments, the central module determines which end users are applicable. In some embodiments, the central module determines which end users can apply the model update by comparing features of the model update with information about each end user, in addition to the new model priority information. determine whether For example, if the model update information for credit card fraud detection has medium priority, the central module determines which local nodes in the update system are involved in credit card fraud detection. identify and then output the model to those identified local nodes (510). Model update information is not output to any of the remaining local nodes, but when each of those remaining local nodes begins the update process, e.g. If so, the local node may receive updates. In another example, if the model update information for credit card fraud detection has high priority, the central module outputs the model to all local nodes (510). In another example, if the model update information for credit card fraud detection has a low priority, the central module does not immediately output the model to any local node, but instead outputs the model to each local node. • Wait for the node to initiate the update process on its own.

After the model update information is sent from the central module, the model update information is received (511) by at least one local node. In some embodiments, model update information is received simultaneously by multiple local nodes. In some embodiments, model update information is received by a monitoring module in any of the embodiments described herein.

In some embodiments, the model update information is not automatically installed after the local node receives 511 the model update information. First, the local node queries the current model database to see if the model update replaces any existing models (512). Next, the local node determines (513) the relevance of the model update information with the node. For example, at local node 210 of update system 200 shown in FIG. 2, model update information is received by monitoring module 211 and then passed to diagnostic module 212 . The diagnostic module 212 first queries the current model database 215 and then determines the relevance of the model update information with the local node 210 . In some embodiments, diagnostic module 212 terminates the update process after step 513 of determining relevance. In some embodiments, after the relevance determining step 513, the diagnostic module 212 terminates the update process if the diagnostic module 212 determines that model update information is not required for the local node. . In some embodiments, after the determining relevance step 513, the diagnostic module 212 terminates the update process if the diagnostic module 212 determines that model update information already exists on the local node. . In some embodiments, the diagnostic module 212 automatically bypasses the determining relevance step 513 if the model update information has a high priority.

In some embodiments, after the local node determines that model update information is relevant or required, the local node determines whether it has permission to apply the model update information. Determine (514). In some embodiments, an evaluation module at the local node determines whether the local node has permission to apply model updates. In some embodiments, the local node does not have permission to install model updates. In some embodiments, the local node does not have automatic permission to install model updates. In some embodiments, the local node must query or ask the end user for permission before installing the model update (516). For example, the diagnostic module 212 either determines that the model update information is relevant, or that the model update information has a sufficiently high priority to avoid step 513 of determining relevance. After determining the model update information is passed to the evaluation module 213 . Next, the evaluation module 213 checks the update permission settings of the local node. In some embodiments, if the evaluation module 213 determines that permission to install the model update information is not obtained, the evaluation module 213 terminates the update process. In some embodiments, the evaluation module 213 prompts the end user, for example, by issuing a prompt to the user or by sending an email or other communication to the end user, before installing the model update information. - Ask the user.

After determining that the local node has permission to install the model update, the local node installs the model update (515). In some embodiments, the evaluation module installs model updates. In some embodiments, any module of the update system installs model updates. In some embodiments, the model update information installs one or more new models into the current model database within the local node. In some embodiments, the model update information replaces one or more models in the current model database within the local node. For example, after authorization is established, evaluation module 213 updates current model database 215 using model update information.

In some embodiments, after the update 515 is completed, the local node creates an output report (517). In some embodiments, output reports are shared with end users. In some embodiments, the output report is shared with the central module of the update system. In some embodiments, the output report includes information about model update information, e.g., what models were updated, whether any old models were replaced, date and time of update, which new models are currently active Whether or not it contains any combination of these.

FIG. 6 shows a flow chart of an exemplary method for pushing model updates to an update system that does not include a central module, where model updates are automatically created from local nodes within update system 600. It is In some embodiments, method 600 can be used in the update system shown in FIG. First, a local node in the update system detects (601) a change in results from an existing model. In some embodiments, local nodes within the update system detect changes in fraud detection rates. In some embodiments, the change in fraud detection rate is an increase in fraud detections greater than a preset threshold. In some embodiments, the change in fraud detection rate is a significant increase or decrease in fraud over a specified period of time. In some embodiments, a local node within the update system detects changes in the magnitude of detected frauds. In some embodiments, the change in fraud magnitude is an increase in the value or amount of detected fraud events greater than a preset threshold. In some embodiments, the change in fraud magnitude is a significant increase in the value or amount of detected fraud events compared to a moving average of detected events. For example, diagnostic module 312 as shown in FIG. 3 analyzes system data 314 and detects an increase in fraud detection rate that is more than a standard deviation away from the 3-month moving average of fraud detection rate. .

After a change in results from an existing model is detected (601), the local node builds a list of all models involved in the detection (602). In some embodiments, the local node creates a list of all models that are directly involved in generating the event detected in step 601 . In some embodiments, the local node creates a list of all models that were directly and indirectly involved in generating the event detected in step 601 . In some embodiments, the local node creates a list of all models that were actively executing when the event was detected at step 601 . For example, if diagnostic module 312, which has access to both system data 314 and current model database 315, is responsible for all of the actions that were directly and indirectly involved in generating the fraud event previously detected in step 601. Create a list of algorithmic models.

After the local node has created (602) the list of models associated with the detected change (601), the local node analyzes the data involved in generating the events leading to the detected change ( 603). In some embodiments, the local node, in analyzing system data and generating events detected in step 601, determines features and conditions associated with the models listed in step 602. . Although in some embodiments local node analysis can include ordinary least squares, penalized regression, generalized additive models, quantile regression, logistic regression, and gated linear models. , but not limited to. In some embodiments, the analysis of local nodes becomes a transformed variant of one or more associated models, reducing the complexity of those models. Examples include placing monotonicity constraints on non-linear, non-monotonic models in order to adapt the model around variable relationships known to be true, or monotonic neural in machine learning applications.・The use of networks is mentioned. In some embodiments, the relevant visualization is a relevant but less complex model that approximates one or more applicable models, particularly machine learning models. Examples include surrogate models, local interpretable model-agnostic explanations (LIME), maximum activation analysis, linear regression, and sensitivity analysis.

After the local node has created the list of models (602) and analyzed the associated data (603), the local node generates model update features that are sent to other local nodes in the update system. (604). In some embodiments, the diagnostic module of the local node generates 604 model features. In some embodiments, the features of the model update information are independent of local nodes, i.e. the model update information can be used by any local node within the update system. Therefore, all unique data for the local node is removed from the model update information generated by the local node. In some embodiments, model update information features metadata or high-level aggregate statistics such as one or more algorithms, date and time of creation, number of events detected over a specific time period, total transaction time value; and one or more of one or more threshold points used to trigger updates. In some embodiments, model update information features include average ratio statistics for one or more data groups. In some embodiments, model update information can detect deviations from average proportion statistics for one or more data groups to determine future positive outcomes. In some embodiments, model update information features include one or more network or image graphics representing one or more models. In some embodiments, model update information features include one or more network or image graphics representing the new model.

After the local node generates model features (604), the local node can output model update information (605). In some embodiments, the local node outputs the model update information to at least one other local node of the update system, and those local nodes receive the model update information (611). In some embodiments, local nodes output model update information to all other local nodes in the update system. For example, the monitoring module 311 of the local node 310 can receive model update information from the diagnostic module 312, after which the monitoring module 311 can send the model update information to other local nodes 320, which can of local nodes 320 receive the model update information.

In some embodiments, the model update information is not automatically installed after the local node receives 611 the model update information. First, the local node queries the current model database to see if the model update replaces any existing models (612). Next, the local node determines (613) the relevance of the model update information with the node. For example, at local node 310 of update system 300 shown in FIG. 3, model update information is received by monitoring module 311 and then passed to diagnostic module 312 . The diagnostic module 312 first queries the current model database 315 and then determines the relevance of the model update information with the local node 310 . In some embodiments, diagnostic module 312 terminates the update process after step 613 of determining relevance. In some embodiments, after the relevance determining step 613, the diagnostic module 312 terminates the update process if the diagnostic module 312 determines that model update information is not required for the local node. . In some embodiments, after the step of determining relevance 613, the diagnostic module 312 terminates the update process if the diagnostic module 312 determines that model update information already exists on the local node. .

In some embodiments, after the local node determines that model update information is relevant or required, the local node determines whether it has permission to apply the model update information. Determine (614). In some embodiments, an evaluation module at the local node determines whether the local node has permission to apply model updates. In some embodiments, the local node does not have permission to install model updates. In some embodiments, the local node does not have automatic permission to install model updates. In some embodiments, the local node must query or ask the end user for permission before installing the model update (616). For example, model update information is passed to evaluation module 313 after diagnostic module 312 determines that the model update information is relevant. Next, the evaluation module 313 checks the update permission settings of the local node. In some embodiments, if the evaluation module 313 determines that permission to install the model update information is not obtained, the evaluation module 313 terminates the update process. In some embodiments, the evaluation module 313 prompts the end user, for example, by issuing a prompt to the user or by sending an email or other communication to the end user, before installing the model update information. - Ask the user.

After determining that the local node has permission to install the model update, the local node installs the model update (615). In some embodiments, the evaluation module installs model updates. In some embodiments, any module of the update system installs model updates. In some embodiments, the model update information installs one or more new models into the current model database within the local node. In some embodiments, model update information replaces one or more models in the current model database in the local node. For example, after authorization is established, evaluation module 313 updates current model database 315 using model update information.

In some embodiments, after the update 615 is completed, the local node creates an output report (617). In some embodiments, output reports are shared with end users. In some embodiments, the output report is shared with the central module of the update system. In some embodiments, the output report includes information about model update information, such as what models were updated, whether any old models were replaced, date and time of update, which new models are currently active Whether or not it contains any combination of these.

In some embodiments, the user of any of the systems disclosed herein can be one or more human users, such as those known as "human-in-the-loop" systems. . In some embodiments, users of any of the systems disclosed herein can be computer systems, artificial intelligence (AI), cognitive or non-cognitive algorithms, and the like.

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

FIG. 7 depicts a block diagram of an exemplary data processing system 700 in which aspects of the example embodiment may be implemented. Data processing system 700 is an example of a computer, such as a server or client, having computer usable code or instructions implementing the processes of any of the example embodiments of the present disclosure described herein. In some embodiments, FIG. 7 represents a server computing device, such as a server, that implements the system for interpreting analysis results described herein.

In the example shown, data processing system 700 includes a north bridge and memory controller hub (NB/MCH) 701 and a south bridge and input/output (I/O) controller hub. (SB/ICH: south bridge and input/output (I/O) controller hub) 702 may be employed. A processing unit 703 , a main memory 704 and a graphics processor 705 can be connected to the NB/MCH 701 . Graphics processor 705 may be connected to NB/MCH 701 via an accelerated graphics port (AGP). Network adapter 706 connects 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 drive (CD or DVD) 712 , universal serial bus (USB) ports and other communication ports 713 , and PCI/PCIe devices 714 can connect to SB/ICH 702 via bus system 716 . PCI/PCIe devices 714 may include Ethernet adapters, add-in cards, and PC cards for notebook computers. ROM 710 may be, for example, a flash basic input/output system (BIOS). HDD 711 and optical drive 712 may use integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interfaces. A super I/O (SIO) device 715 can be connected to the SB/ICH 702 .

An operating system can run on the processing unit 703 . The operating system may coordinate and control various components within data processing system 700 . As a client, the operating system can be any commercial operating system. An object oriented programming system, such as the Java(R)(TM) programming system, runs in conjunction with the operating system and provides calls to the operating system from object oriented programs or applications running on data processing system 700. You can As a server, data processing system 700 may be, for example, an IBM(R) eServer(TM) System running an Advanced Interactive Executive operating system or a LINUX(R) operating system. Data processing system 700 may be a symmetric multiprocessor (SMP) system in which multiple processors may be included in processing unit 703 . Alternatively, a single processor system may be employed.

Operating systems, object oriented programming systems, and application or program instructions are located in a storage device such as HDD 711 and read into main memory 704 for execution by processing unit 703 . The processes of embodiments of the medical record error detection system can be performed by processing unit 703 using computer usable program code, which computer usable program code may be, for example, It may be located in a memory such as main memory 704, ROM 710, or in one or more peripherals.

Bus system 716 may consist of one or more buses. Bus system 716 may be implemented using any type of communication fabric or architecture capable of providing transfer of data between different components or devices connected to the communication fabric or architecture. . A communication unit such as modem 709 or network adapter 706 can include one or more devices that can be used to send and receive data.

Those skilled in the art will appreciate that the hardware required to implement any of the systems and methods described herein may vary depending on implementation. Other internal hardware or peripherals, such as flash memory, equivalent non-volatile memory, or optical disk drives, may be used in addition to or instead of the hardware shown. you can Additionally, any of the systems described herein may be used as a client computing device, a server computing device, a tablet computer, a laptop computer, a telephone or other communication device, a personal digital assistant. It can take the form of any of a number of different data processing systems, including but not limited to. Essentially, any of the systems described herein can be any known or hereafter developed data processing system, without architectural limitation.

The illustrated systems and methods are not exclusive. Other systems and processes may be obtained in accordance with the principles of the embodiments described herein to accomplish the same purpose. It should be understood that the embodiments and variations shown and described herein are for illustrative purposes only. Modifications to the current design may be implemented by those skilled in the art without departing from the scope of the embodiments. As described herein, various systems, subsystems, agents, managers, and processes may be implemented using hardware or software components, or combinations thereof.

Although the present invention has been described with reference to example embodiments, it is not limited to those example embodiments. Those skilled in the art will appreciate that numerous changes and modifications may be made to the preferred embodiments of the invention. It is therefore intended that the appended claims be construed to cover all such equivalent variations as included within the scope of this invention.

Claims (35)

A computer program product for updating a detection model, said computer program product comprising at least one computer readable storage medium having program instructions embodied therein, said program instructions being executable by a processor. Yes, in said processor,
receiving the model update information by at least one monitoring module;
determining the current detection model by at least one diagnostic module;
determining by at least one evaluation module whether the model update information should be applied to the current detection model;
determining, by at least one evaluation module, whether at least one local node is authorized to apply the model update;
A computer program product that causes at least an evaluation module to update the local node by updating the current detection model using the model update information. 2. The computer program product of claim 1, wherein said program instructions are executable by said processor to cause said processor to further distribute said model update information to at least one local node. 3. The computer program product of claim 2, wherein the model update information is distributed to at least two local nodes. 3. The computer program product of claim 2, wherein the model update information is distributed to at least one local node by a central module. The central module receives the model update information by:
receiving, by the central module, the model update information;
analyzing a database of available models by the central module;
determining, by the central module, the priority of the model update information;
determining by the central module which local nodes should receive the model update information;
5. The computer program product of claim 4, wherein the central module distributes the model update information to at least one local node by sending the model update information to at least one local node. 6. The computer program product of claim 5, wherein the database of usable models includes models usable by all local nodes. 6. The computer program product of claim 5, wherein the priority is determined by comparing characteristics of the model update information with model information in an existing model database. 3. The computer program product of claim 2, wherein the model update information is distributed to at least one local node by another local node. 2. The computer program product of claim 1, wherein the program instructions are executable by the processor to further cause the processor to create model update information. 10. The computer program product of claim 9, wherein said creation of model update information occurs at a local node. The creating of the model update information includes:
detecting, by the diagnostic module, a significant change in system data;
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 the model update information by the diagnostic module;
11. The computer program product of claim 10, generated by said monitoring module and sending said model update information. The generated model update information includes one or more algorithms, date and time of creation, number of events detected over a specified time period, aggregate statistics, and one or more used to trigger updating of the model. 12. The computer program product of claim 11, comprising one or more elements selected from the group consisting of threshold points of . 12. The computer program product of claim 11, wherein the generated model update information does not include any system data specific to the local node that generated the model update information. 12. The computer program product of claim 11, wherein said monitoring module sends said model update information to a central module external to said local node. 12. The computer program product of claim 11, wherein said monitoring module sends said model update information to a monitoring module of another local node. A system for updating a detection model, comprising:
monitoring module,
diagnostic module,
evaluation module,
at least one local node comprising one or more current detection models and system data generated by said current detection models;
a memory containing instructions, the instructions being executed by at least one processor;
receiving model update information by the monitoring module;
determining, by the diagnostic module, the current detection model;
determining, by the evaluation module, whether the model update information should be applied to the current detection model;
determining, by the evaluation module, whether the local node is authorized to apply the model update;
and updating, by the evaluation module, the current detection model using the model update information. 17. The system of claim 16, wherein said system further comprises at least two local nodes. 18. The system of claim 17, wherein said system further comprises a central module, said monitoring module of each local node being in electronic communication with said central module. 19. The system of claim 18, wherein said system further comprises a database of all models available on said system in electronic communication with said central module. 19. The system of claim 18, wherein the monitor module is configured to receive model update information. 21. The system of claim 20, wherein the monitoring module is capable of receiving model update information from a system administrator or local node. said instruction
detecting, by the diagnostic module, significant changes in system data;
determining, by the diagnostic module, a list of all current detection models involved in the detection step;
analyzing, by the diagnostic module, the system data involved in the detecting step;
generating, by the diagnostic module, the model update information;
18. The system of claim 17, further configured by the monitoring module to perform the steps of: sending the model update information. The generated model update information includes one or more algorithms, date and time of creation, number of events detected over a specified time period, aggregate statistics, and one or more used to trigger updating of the model. 23. The system of claim 22, comprising one or more elements selected from the group consisting of threshold points of . 23. The system of claim 22, wherein the generated model update information does not include any system data specific to the local node that generated the model update information. 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;
a database of all models available on said system in electronic communication with said central module;
a memory containing instructions, the instructions being executed by at least one processor;
creating a model update, comprising:
detecting, by the diagnostic module, significant changes in system data;
determining, by the diagnostic module, a list of all current detection models involved in the detection step;
analyzing, by the diagnostic module, the system data involved in the detecting step;
generating, by the diagnostic module, the model update information;
said creating step comprising sending said model update information by said monitoring module;
Distributing model updates, comprising:
receiving, by the central module, the model update information;
analyzing, by the central module, the database of available models;
determining, by the central module, the priority of the model update information;
determining by the central module which local nodes should receive the model update information;
said distributing step comprising sending said model update information by said central module;
updating at least one local node, comprising:
receiving model update information by at least one monitoring module;
determining the current detection model by at least one diagnostic module;
determining by at least one evaluation module whether the model update information should be applied to the current detection model;
determining, by at least one evaluation module, whether the local node is authorized to apply the model update;
and updating the current detection model using the model update information, at least by an evaluation module. A computer-implemented method in a data processing system comprising a processor and a memory containing instructions, the instructions being executed by the processor to cause the processor to implement a system update detection model, the method comprising: ,
receiving model update information by a monitoring module of at least one local node;
determining, by a diagnostic module of the local node, the current detection model in use by the local node;
determining by an evaluation module of the local node whether the model update information should be applied to the current detection model;
determining by the evaluation module of the local node whether the local node is authorized to apply the model update;
updating the current detection model using the model update information by the evaluation module of the local node; and updating at least one local node. 27. The method of claim 26, wherein the method further comprises updating at least two local nodes. 28. The method of claim 27, said method further comprising distributing said model update information by a central module. 29. The method of claim 28, wherein the method further comprises analyzing, by the central module, a database of available models. 29. The method of claim 28, wherein the method further comprises prioritizing, by the central module, the model update information. 29. The method of claim 28, wherein the method further comprises determining, by the central module, which local nodes should receive the model update information. said method comprising:
detecting, by the diagnostic module, significant changes in system data;
determining, by the diagnostic module, a list of all current detection models involved in the detection step;
analyzing, by the diagnostic module, the system data involved in the detecting step;
generating, by the diagnostic module, the model update information;
28. The method of claim 27, further comprising creating model update information, including sending the model update information by the monitor module. The generated model update information includes one or more algorithms, date and time of creation, number of events detected over a specified time period, aggregate statistics, and one or more used to trigger updating of the model. 33. The method of claim 32, comprising one or more elements selected from the group consisting of threshold points of . 33. The method of claim 32, wherein the generated model update information does not include any system data specific to the local node that generated the model update information. creating a model update, comprising:
detecting, by the diagnostic module, significant changes in system data;
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 information;
said creating step comprising sending said model update information by said monitoring module;
distributing the model update information, comprising:
receiving, by a central module, said model update information;
analyzing, by said central module, a database of available models;
determining, by the central module, the priority of the model update information;
determining, by said central module, which local nodes should receive said model update information;
said distributing step comprising sending, by said central module, said model update information to at least one local node;
updating at least one local node, comprising:
receiving the model update information by at least one monitoring module;
determining the current detection model by at least one diagnostic module;
determining by at least one evaluation module whether the model update information should be applied to the current detection model;
determining, by at least one evaluation module, whether the local node is authorized to apply the model update;
27. The method of claim 26, further comprising updating, by at least an evaluation module, the current detection model using the model update information.

Images