DE112020003693T5 - UPDATE COLLECTION MODELS AND COMPLY WITH PRIVACY - Google Patents

Abstract

A system for updating acquisition models has at least one local node that has 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 present in the local node and determines whether the update should be applied. In some embodiments, a local node can generate a model update for use in other local nodes, but private data present in the local node is not shared.

Description

TECHNICAL AREA

The present application relates generally to systems for evaluating and sharing acquisition models while maintaining privacy, and methods of using the same.

BACKGROUND

Event capture analytics models are important to a number of domains and industries. For example, various analysis models are used to detect bank fraud, support regulatory compliance, and many other complex data-driven problems. Many fields require the most up-to-date models for accurate and timely event capture. In some areas, for example many types of fraud, a third party agent actively works to evade detection by current analytical models. Thus, what is needed is a system for updating acquisition models that allows a model update to be rapidly distributed, analyzed, and implemented across multiple local nodes of the system. Furthermore, since manually creating updated capture models can be a slow and time-consuming process, what is needed is a system that creates its own model updates from a successful event capture and then distributes the created model update to the rest of the system while respecting the privacy of the location that created the model update.

SUMMARY OF THE INVENTION

One aspect of the present invention provides a system for updating acquisition models, comprising: at least one local node, comprising: a monitor module; a diagnostic module; an evaluation module; one or more current acquisition models; and memory having instructions executed by at least one processor configured to: receive, by the monitor module, a model update; determining, by the diagnostic module, the current acquisition models; determining, by the evaluation module, whether the model update should be applied to the current detection models; determining, by the evaluation module, whether the local node is authorized to apply the model update; and updating the current detection models with the model update by the evaluation module.

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

According to another aspect of the invention, there is provided a computer-implemented method in a data processing system having a processor and memory having instructions executed by the processor to provide a system for updating acquisitions implement solution models, the method comprising: updating at least one local node, comprising: receiving, by a monitor module, a model update from at least one local node; determining, by a diagnostics module of the local node, the current acquisition models used by the local node; determining, by an evaluation module of the local node, whether the model update should be applied to the current detection models; determining, by the local node's evaluation module, whether the local node is authorized to apply the model update; and updating the current detection models with the model update by the local node evaluation module.

According to a further aspect of the invention, a computer program product for updating acquisition models is provided, the computer program product having at least one computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by a processor to cause the processor to have at least one local node to be carried out by: receiving the model update by at least one monitoring module; determining the current acquisition models by at least one diagnostic module; determining, by at least one evaluation module, whether the model update should be applied to the current detection models; determining, by at least one evaluation module, whether the local node is authorized to apply the model update; and updating the current collection models with the model update by at least one evaluation module.

According to yet another aspect of the invention, there is provided a computer program product for creating and updating acquisition models, the computer program product comprising at least one computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by a processor to cause the processor to: creating a model update, comprising: detecting, by the diagnostic module, a significant change in the 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, wherein the generated model update does not include the system data; and sending the model update by the monitoring module; Distributing the model update, comprising: receiving, by a central module, the model update; analyzing a database with available models by the central module; determining a priority level for the model update by the central module; determining, by the central module, which local nodes should receive the model update; and sending the model update to at least one local node by the central module; and updating at least one local node, comprising: receiving, by at least one monitoring module, a model update; determining the current acquisition models by at least one diagnostic module; determining, by at least one evaluation module, whether the model update should be applied to the current detection models; determining, by at least one evaluation module, whether the local node is authorized to apply the model update; and updating the current collection models with the model update by at least one evaluation module.

According to yet another aspect of the invention, there is provided a computer program product for creating and updating acquisition models, the computer program product comprising at least one computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by a processor to cause the processor to: creating a model update, comprising: detecting, by a first diagnostic module, a significant change in the system data; determining, by the first diagnostic module, a list of all current detection models involved in detecting the significant change; analyzing, by the first diagnostic module, the system data involved in detecting the significant change; generating, by a first diagnostic module, the model update, the generated model update not including any of the system data; and sending the model update by the first monitoring module; and updating at least one second local node, comprising: receiving the model update by at least one second monitoring module; determining the current detection models by at least a second diagnostic module; determining, by at least a second evaluation module, whether the model update should be applied to the current detection models; determining, by at least the second evaluation module, whether the local node is authorized to apply the model update; and updating the current detection models with the model update by at least the second evaluation module.

Additional features and advantages of this disclosure will become apparent from the following detailed description of illustrative embodiments with reference to the accompanying drawings.

character list

• 1 stellt ein Blockschaubild eines beispielhaften Aktualisierungssystems dar, das einen einzelnen lokalen Knoten aufweist;
• 2 stellt ein Blockschaubild eines beispielhaften Aktualisierungssystems dar, das mehrere lokale Knoten aufweist, die durch ein Zentralmodul verbunden sind;
• 3 stellt ein Blockschaubild eines beispielhaften Aktualisierungssystems dar, das mehrere direkt verbundene lokale Knoten aufweist;
• 4 stellt einen Ablaufplan eines beispielhaften Verfahrens zum Aktualisieren von Analysesystemen durch Verwenden eines Aktualisierungssystems und einer manuell erstellten Modellaktualisierung dar;
• 5 stellt einen Ablaufplan eines beispielhaften Verfahrens zum Aktualisieren von Analysesystemen durch Verwenden eine Modellaktualisierung dar, die durch einen der lokalen Knoten erstellt wird; wobei die lokalen Knoten durch ein Zentralmodul verbunden sind;
• 6 stellt einen Ablaufplan eines beispielhaften Verfahrens zum Aktualisieren von Analysesystemen durch Verwenden eines aktualisierten Modells dar, das durch einen der lokalen Knoten erstellt wird, wobei die lokalen Knoten direkt verbunden sind; und
• 7 stellt ein Blockschaubild eines beispielhaften Datenverarbeitungssystems dar, in dem Aspekte der veranschaulichenden Ausführungsformen umgesetzt werden können.

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

• 1 Figure 12 illustrates a block diagram of an example update system having a single local node;
• 2 Figure 12 illustrates a block diagram of an exemplary update system having multiple local nodes connected by a central module;
• 3 Figure 12 illustrates a block diagram of an example update system having multiple directly connected local nodes;
• 4 Figure 12 illustrates a flowchart of an example method for updating analysis systems by using an update system and a manually created model update;
• 5 Figures 12 illustrates a flowchart of an example method for updating analysis systems by using a model update created by one of the local nodes; the local nodes being connected by a central module;
• 6 Figure 12 depicts a flowchart of an example method for updating analysis systems by using an updated model created by one of the local nodes, where the local nodes are directly connected; and
• 7 12 depicts a block diagram of an example data processing system in which aspects of the illustrative embodiments may be implemented.

DETAILED DESCRIPTION OF EMBODIMENTS

This specification and claims may use the terms "a," "at least one of," and "one or more of" with respect to particular features and elements of the illustrative embodiments. It should be understood that the terms and phrases are intended to indicate that at least one of the particular features or elements is present in the particular illustrative embodiment, but that more than one may be present. That is, these terms/phrases are in no way intended to limit the description or claims to the presence of a single feature/element or to require that a plurality of such features/elements be present. On the contrary, these terms/phrases require only at least a single feature/element, with the possibility of a plurality of such features/elements within the scope of the specification and claims

Additionally, it should be understood that the following description uses a variety of different examples of various elements of the illustrative embodiments to further clarify example implementations of the illustrative embodiments and to aid in understanding the mechanisms of the illustrative embodiments. These examples are in no way meant to be limiting and are not exhaustive of the various ways to implement the mechanisms of the illustrative embodiments. Those skilled in the art, given the present invention, will appreciate that there are many alternative implementations for these various elements that may be used in addition to or in place of the example provided herein without departing from the spirit and scope of the present disclosure.

The present disclosure may be a system, method, and/or computer program product. The computer program product may include a computer-readable storage medium (or media) storing computer-readable program instructions for causing a processor to carry out aspects of the present disclosure.

The computer-readable storage medium may be a physical device that can retain and store instructions for use by an instruction-executing device. The 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 of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory ( EPROM or flash memory), static random access memory (SRAM), portable CD-ROM, DVD, memory stick, floppy disk, a mechanically encoded device such as punched cards or raised structures in a groove that has instructions stored, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, should not be construed as transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., through a fiber optic cable conducted pulses of light) or electrical signals transmitted through a wire.

Computer-readable program instructions described herein may be carried from a computer-readable storage medium onto respective computing/processing devices or over a network such as the Internet, a local area network (LAN), a wide area network (WAN), and/or a wireless network downloaded to an external computer or storage device. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routers, firewalls, switches, gateway computers, and/or edge servers. A network adapter card or network interface in each computing/processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing/processing unit.

Computer-readable program instructions for performing operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code Written in any combination of one or more programming languages, including object-oriented programming languages such as Java™, Smalltalk, C++ or similar, as well as traditional procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server will. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including LAN or WAN, or the connection can be made to an external computer (for example, over the Internet using an Internet service provider) . In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGA), or programmable logic arrays (PLA), can execute the computer-readable program instructions by using state information of the computer-readable program instructions to execute the personalize electronic circuits to perform aspects of the present disclosure.

Aspects of the present 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 should 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 using computer readable program instructions.

These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable computing device to create a machine such that the instructions executed by the processor of the computer or other programmable computing device provide a means for implementing the Block or the blocks of the flowcharts and / or block diagrams specified Create functions/steps. These computer-readable program instructions may also be stored on a computer-readable storage medium capable of controlling a computer, programmable computing device, and/or other device to operate in a particular manner such that the computer-readable storage medium, a product of manufacture having instructions stored thereon, including instructions that implement aspects of the function/step identified in the flowchart block(s) and/or block diagrams.

The computer-readable program instructions may also be loaded onto a computer, other programmable data processing device, or other device to cause a series of operational steps to be performed on the computer, other programmable device, or other device to cause a computer implemented process such that the instructions executed on the computer, other programmable device, or other entity implement the functions/steps indicated in the block(s) of the flowchart diagrams and/or block diagrams.

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 should 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 using computer readable program instructions.

The flowchart 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 the flowchart or block diagrams 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 block may occur out of the order noted in the figures. For example, two blocks shown sequentially may actually be executed in substantially parallel, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It is further noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by specific hardware-based systems that perform the specified functions or acts, or combinations of special-purpose hardware and execute computer instructions.

• Navigieren durch die und Verstehen der Komplexitäten von menschlicher Sprache Aufnehmen und Verarbeiten von umfangreichen Mengen von strukturierten und unstrukturierten Daten
• Generieren und Auswerten von Hypothesen
• Gewichten und Auswerten von Antworten, die nur auf relevantem Nachweis beruhen Bereitstellen von situationsspezifischem Rat, situationsspezifischen Erkenntnissen und Orientierung
• Verbessern von Wissen und Lernen mit jeder Wiederholung und Interaktion durch Maschinenlernprozesse
• Ermöglichen einer Entscheidungsfindung zum Auswirkungszeitpunkt (z.B. kontextbezogene Orientierung)
• Skalieren in Proportion zur Aufgabe
• Erweitern und Vergrößern von menschlichem Fachwissen und kognitiver Leistung Identifizieren von Resonanz-, menschenähnlichen Attributen und Zügen von natürlicher Sprache
• Ableiten verschiedener sprachspezifischer oder agnostischer Attribute von natürlicher Sprache
• Sammlung mit hohem Grad von Relevanz von Datenpunkten (Bilder, Text, Sprache) (z.B. Speicherung und Erinnerung)
• Vorhersagen und Spüren mit einem Situationsbewusstsein, das menschliche kognitive Leistung auf Grundlage von Erfahrungen nachahmt
• Beantworten von Fragen auf Grundlage von natürlicher Sprache und spezifischem Nachweis

In summary, a cognitive system is a specialized computer system or set of computer systems configured with hardware and/or software logic (in combination with hardware logic on which the software runs) to emulate human cognitive functions. These cognitive systems apply human-like characteristics to thought transmission and processing that, when combined with the inherent powers of digital computing, can solve problems at scale with high accuracy and resilience. IBM's Watson™ is an example of such a cognitive system, capable of processing human-readable speech and interference between passages of text with human-like accuracy far faster and on a much larger scale than humans. In general, such cognitive systems are able to perform the following functions:

• Navigating through and understanding the complexities of human language ingesting and processing large amounts of structured and unstructured data
• Generation and evaluation of hypotheses
• Weight and evaluate responses based only on relevant evidence Provide situation-specific advice, insight and guidance
• Improving knowledge and learning with every iteration and interaction through machine learning processes
• Enable decision-making at impact time (e.g. contextual orientation)
• Scale in proportion to the task
• Extending and augmenting human expertise and cognitive performance. Identifying resonant, human-like attributes and traits of natural language
• Deriving various language-specific or agnostic attributes from natural language
• Collection of high relevance data points (images, text, speech) (e.g. storage and recall)
• Predict and sense with situational awareness that mimics human cognitive performance based on experience
• Answering questions based on natural language and specific evidence

Embodiments herein relate to a system for updating analysis models across multiple local nodes. As used herein, a single "local node" refers to software installed by an end user, such as an individual or corporation. In some embodiments, a 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 that local node. In some embodiments, each local node in the system accesses and analyzes system data generated by one or more analysis models. System data is specific to each local node and may include sensitive or confidential information.

As used herein, a single “analysis model” or just “model” is a software algorithm designed to capture specific events using data analysis techniques. In some embodiments, the analysis model detects data anomalies. In some embodiments, the analytics models capture fraud events. In some embodiments, the data analysis techniques used by the analysis models include data processing techniques, calculation of one or more statistical parameters, statistical ratios based on classifications or groups, calculation of probabilities, classification techniques such as data grouping and data matching, regression analysis, and gap analysis. In some embodiments, the local node software includes one or more analysis models. In some embodiments, the local node software includes one or more analysis models and deterministic rules. In some embodiments, the local node software includes one or more analysis models for fraud detection. In some embodiments, the local node software includes one or more regulatory compliance or non-compliance analysis models. In some embodiments, the local node software includes one or more models and deterministic rules for fraud detection. In some embodiments, the local node software includes one or more models and deterministic rules for regulatory compliance or non-compliance.

In some embodiments, the update system receives one or more model updates and pushes those updates to applicable local nodes. In some execution systems, the update system pushes updates to all local nodes in the system. In some execution systems, the update system only pushes updates to selected local nodes. In some embodiments, the update system determines which local nodes receive the model update deferral.

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

In some embodiments, the update system, including all local nodes, is a standalone system that creates and pushes model updates for each software system that Analysis models used. In some embodiments, the update system is itself a component or subsystem of a larger analysis system, for example a fraud detection analysis system.

1 Figure 12 is a block diagram showing components, outputs, and data streams of an exemplary single local node of an update system 100. The local node has three main modules or subsystems: a monitoring module 101, a diagnostics module 102, and an evaluation module 103.

The monitoring module 101 monitors one or more factors to determine whether a model update process is required. In some embodiments, the monitoring module 101 checks the time since the last update process and initiates an update process when sufficient time has elapsed. In some embodiments, the monitor module 101 initiates an update process when 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 has passed since the last update process. In some embodiments, the monitor module 101 initiates an update process when it receives a model update pushed to the local node 100 from an external source. For example, the monitoring module 101 may receive a model update pushed by a central module of the update system, another local node, or directly by an administrator of the update system.

In some embodiments, the monitoring module 101 may initiate an update process when signaled by the diagnostics module 102 . In some embodiments, diagnostic module 102 analyzes system data 104 and may signal monitor module 101 to initiate an update process when one or more data thresholds have been met. For example, the diagnostic module 102 may signal the monitoring module 101 when the diagnostic module's analysis of the system data 104 shows an increase in event detection above a data threshold or a decrease in event detection below a data threshold. In some embodiments, the data threshold can be set manually, for example by an end user. In some embodiments, the data threshold may be determined automatically by the diagnostic module 102 when, for example, the event capture rate increases by a significant amount over the week-long average capture rate.

When an update process has been initiated, the monitor module 101 asks for available model updates. In some embodiments, the monitoring module 101 queries a central module of the update system, another local node, or an administrator of the update system. In some embodiments, if the update process was initiated by a model update pushed from a source remote from the local node 100, the monitor module 101 does not prompt for additional available model updates. In some embodiments, if the update process was initiated by a model update pushed from a source remote from the local node 100, the monitor module 101 will still ask for additional available model updates.

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 to the diagnostic module 102. The diagnostic module 102 compares the model update to a database of current models 105 available in the local node. In some embodiments, the diagnostic module 102 categorizes the model update for current models 105 regardless of whether those current models 105 are in use. In some embodiments, the diagnostic module 102 categorizes the model update for the system data 104 generated by the application of the active current models 105.

When the diagnostic module 102 has received the model update and compared at least the model update with the database of current models 105, the diagnostic module 102 passes the model update and any available comparison and other analysis data to the evaluation module 103. The evaluation module 103 evaluates the model update in order to determine whether update 106 should be applied. In some embodiments, the evaluation module 103 applies the model update automatically, changing or modifying the current models 105 with the model update. In some embodiments, the evaluation module 103 analyzes the model update to determine whether such a model is already in the current models database 105 is present. In some embodiments, the evaluation module 103 performs the model update for relevant system data 104 or relevant categorical data generated by the diagnostic module 102 to determine whether the model update provides the local node 100 with different system data than that which the current models 105 generate be able. In some embodiments, the evaluation module 103 does not automatically apply any updates or perform any analysis unless authorized by an end user or the local node 100 administrator.

2 FIG. 12 is a block diagram showing components, outputs and data streams of an update system with multiple local nodes 200. The update system has a central module 201 that connects all local nodes in the update system 200. FIG. 2 represents two local nodes, generally categorized as 210 and 220. In some embodiments, there is no upper limit to the number of local nodes that update system 200 could have. It should be clear that local nodes 210 and 220 are generally the same as the local node contained in 1 has been described, each having a monitoring module 211, 221, a diagnostic module 212, 222 and an evaluation module 213, 223. Each local node also has its own system data 214,224 and database of current models 215,225. It should be clear that each local node can have different system data and current models. In some embodiments, system data 214 may not be identical or similar to system data 224 . In some embodiments, current models 215 may not be identical or similar to current models 225 .

The central module 201 does not reside in any local node but in a separate storage location such as a centralized administration 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 each monitoring module in the update system. The central module 201 can access a master database of available models 202 for the update system. The database of available models 202 is a listing of all possible analysis models currently in the update system. In some embodiments, a database of current models in a single node, e.g., current models 215, corresponds to the record of available models 202. In some embodiments, a database of current models in a single node, e.g., current models 215, corresponds to the Data set of available models 202 does not, but contains at least one model common to the database of available models 202.

In some embodiments, when a monitor module in a single node, for example monitor module 211, initiates a query for available model updates, the monitor module is in electronic communication with central module 201.

In some embodiments, each individual node may be in communication with one or more end users. For example, in 2 the evaluation module 213 of a node 210 with an end user 217 are in data communication. In some embodiments, each module of a single node may be in communication with an end user. In some embodiments, a single node communicates with an end user to provide the end user with information related to the update process. In some embodiments, a single node communicates with an end user to provide the end user with information regarding the results of an update, for example which models have been updated. In some embodiments, a single node communicates with an end user to ask the end user for authorization before updating any models.

3 FIG. 3 illustrates another block diagram representation of components, outputs, and data streams of an update system having multiple local nodes 300. Update system 300 illustrates two local nodes, categorized generally as 310 and 320. FIG. In some embodiments, there is no upper limit to the number of local nodes that could be present in the update system 300. It should be clear that local nodes 310 and 320 are generally the same as the local nodes included in 1 and 2 have been described, each having a monitoring module 311, 321, a diagnostic module 312, 322 and an evaluation module 313, 323. Each local node also has its own system data 314,324 and database of current models 315,325. It should be clear that each local node can have different system data and current models. In some embodiments, system data 314 may not be the same as system data 324 or be similar to this. In some embodiments, current models 315 may not be identical or similar to current models 325 .

In contrast to 2 For example, the update system 300 does not have any type of central module that connects all local nodes. Instead, all nodes are directly connected to each other via a network. In some embodiments, each monitoring module is in electronic communication with every other monitoring module in update system 300 . Like for example in 3 shown, the monitoring module 311 has an electronic data connection with the monitoring module 321.

In some embodiments, when an update process has been initiated in a single node, that node's monitoring module polls another local node in the update system 300 . For example, when an update process has been initiated in the local node 310 , the monitoring module 311 queries the monitoring module 321 of the local node 320 . In some embodiments, when an update process has been initiated in a single node, that node's monitoring module polls all other local nodes in the update system 300 . In some embodiments, when an update process has been initiated in a single node, that node's monitoring module only polls selected other local nodes in the update system 300 . In some embodiments, when an update process has been initiated in a single node, that node's monitoring module only polls another local node in the update system 300 .

In any embodiment herein, a system administrator can create an updated model and manually add it to the update system. For example, a system administrator can create an updated model and forward this model to the central module 201, as in 2 shown. As another example, a system administrator can create an updated model and forward this model to the monitoring module 321, as in 3 shown. In some embodiments, when an updated model has been added to any system illustrated herein, the update process may be initiated for all or some of the nodes in the update system.

In each embodiment herein, any local node of an update system can spawn a model update and automatically push it to the rest of the update system. In some embodiments, local nodes generating their own model updates is advantageous because it allows the update system to respond quickly to increases in fraud detection without end-user or administrator involvement. For example, the diagnostic module 212 analyzes as in 2 shown, the system data 214 and detects an increase in fraud detection that is greater than a preset threshold. The diagnostic module 212 proceeds to list the model or models used to detect the increase in fraud and analyzes the system data 214 to determine the critical characteristics and conditions of the relationship between the model or models and the data to determine. The diagnostic module 212 then extracts from the model all specific data for the system data 214 and the local node 210. The monitoring module 211 then sends the model to the central module 210, which would then determine whether the model is applicable as an update model for the update system 200.

In any embodiment where a local node originates a model update for the update system, it is important that that local node's specific system data is not shared with any central hub or other local node 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, date and time of creation, number of events recorded over a specified time period, metadata or aggregated statistics at a high level, such as total transaction value over time, and the threshold point or the threshold points used to trigger the model update. In some embodiments, the new model includes a ratio statistic of one or more data group averages. In some embodiments, the new model can capture a deviation from the ratio statistics of one or more data group averages to determine future positive outcomes. In some embodiments, the new model includes one or more network or map graphics representing one or more models. In some embodiments, the new model includes one or more network or map graphics that represent the new model.

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

3 12 depicts a flowchart of an exemplary method using a manually created model to move a model update in an update system having a central module 400. FIG. In some embodiments, the method 400 can be performed with the in 2 update system shown can be used. First, a system administrator manually creates a new model that is used to update the 401 system. In some embodiments, the new model includes new or updated algorithm(s). In some embodiments, the new model includes information about what criteria are necessary for using the new model, for example 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 needs to be pushed to all local nodes would be given the highest possible priority. In some embodiments, priority information is categorized as low priority, medium priority, or high priority.

Next, the new model created by the system administrator is pushed to the update system that receives the model 402 . In some embodiments, a central module of an update system receives the model. After receiving the model 402, the central module updates the model database 403. For example, the central module 201 would update the database of available models 202 in the in 2 update system 200 shown update.

The update system would then determine the end users applicable to the new model 404. In some embodiments, the central module determines which end users are applicable. In some embodiments, the central module determines which end-users are applicable for the model update by comparing criteria information in the new model with information about each end-user in addition to the new model's priority information. For example, if the model update for credit card fraud detection has a medium priority, the central module identifies which local nodes in the update system are involved in credit card fraud detection and then moves the model 405 to those identified local nodes. However, the model update would not be pushed to any remaining local nodes if each of those local nodes initiates an update process, for example if sufficient time has elapsed without an update to trigger the monitor module that a local node can subsequently receive the update. In another example, if the model update for detecting credit card fraud has a high priority, the central module issues the model 405 to all local nodes. In another example, if the model update for detecting credit card fraud has a low priority, the central module does not immediately push the model to any local node, but instead waits for each local node to initiate its own update process.

When the model update has been sent out by the central module, it is received by at least one local node. In some embodiments, the model update is received from multiple local nodes simultaneously. In some embodiments, the model update is received from the monitoring module in each of the embodiments described herein.

In some embodiments, when a local node has received a model update 411, it is not installed automatically. First, the local node queries the current model database to determine if the model update replaces any of the existing models 412. Thereafter, the local node determines the relevance of the model update for the node 413. In the local node 210 of the in 2 For example, in the update system 200 shown, the model update is received by the monitoring system 211 and then passed to the diagnostic module 212. The diagnostics module 212 first queries the current database of current models 215 and then determines the relevance of the model update to the local node. In some embodiments, the diagnostic module 212 terminates the update process after the determining relevance step 413. In some embodiments, the diagnostic module 212 terminates the updating process after the determining relevance step 413 if the diagnostic module 212 determines that the model update for the local node fails is required. In some embodiments, the diagnostic mo ends dul 212 the update process after the step of determining relevance 413 if the diagnostic module 212 determines that the model update already exists in the local node. In some embodiments, the diagnostic module 212 bypasses the determining relevance step 413 when the model update has a high priority.

In some embodiments, once the local node has determined that the model update would be relevant or necessary, the local node determines whether it has permission to apply the model update 414 . In some embodiments, the local node's evaluation module determines whether the local node is authorized to apply the model update. In some embodiments, a local node does not have permission to install the model update. In some embodiments, a local node does not automatically have permission to install any model update. In some embodiments, a local node must query an end user or ask for authorization before the model update 416 is installed. For example, the model update is passed to the evaluation module 213 when the diagnostic module 212 has either determined that the model update is relevant or that the model update has a sufficiently high priority to bypass the determining relevance step 413 . The evaluation module 214 then checks the local node's permission settings. In some embodiments, if the evaluation module 213 determines that it does not have permission to install the model update, the evaluation module 213 terminates the update process. In some embodiments, the evaluation module 213 queries an end user, for example, by issuing a user prompt or sending an email or other communication to the end user prior to installing the model update.

The local node installs the model update if the local node determines that it is authorized 415. In some embodiments, an evaluation module installs the model update. In some embodiments, each module of the update system installs the model update. In some embodiments, the model update installs one or more new models in a current models database in the local node. In some embodiments, the model update replaces one or more models in a current model database in the local node. For example, after creating the entitlement, the evaluation module 213 updates the database of current models 215 with the model update.

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

5 FIG. 5 depicts a flowchart of an exemplary method for moving a model update in an update system having a central module in which the model update was automatically created by a local node in the update system 500. FIG. In some embodiments, the method 500 can be performed with the in 2 update system shown can be used. First, a local node in an update system detects a change in the results from its existing models 501. In some embodiments, a local node in an update system detects a change in fraud detection rates. In some embodiments, the change in fraud detection rates is an increase in fraud detection that is greater than a preset threshold. In some embodiments, the change in fraud detection rate is a significant increase or decrease in fraud occurrences over a period of time. In some embodiments, a local node in an update system detects a change in detected fraud size. In some embodiments, the change in fraud magnitude is an increase in the value or dollar amount of a detected fraud event that is greater than a preset threshold. In some embodiments, the change in fraud size is a significant increase in the value or dollar amount of a detected fraud event compared to a running average or median of detected events. For example, the diagnostic module 212 analyzes as in 2 1, the system data 214 and detects an increase in fraud detection rate that is greater than a standard deviation from the 3 month running average fraud detection rate.

When a change in results from the existing models has been detected 501, the local node lists all models involved in that detection 502. In some embodiments, the local node lists all models directly involved in generating the events captured in step 501 . In some embodiments, the local node lists all models directly and indirectly involved in generating the events captured in step 501 . In some embodiments, the local node lists all actively running models when the events at step 501 are captured. For example, with access to both the system data 214 and the current models database 215, the diagnostics module 212 lists all algorithm models directly and indirectly involved in generating the fraud events previously detected in step 501 .

When a local node has listed 502 the models relevant to the detected change 501, the local node analyzes the data involved in generating the events leading to the detected change 501. In some embodiments, the local node analyzes the System data to determine the characteristics and conditions relevant to the steps 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, least squares, disadvantaged regressions, generalized additive models, quantile regressions, logistic regressions, and closed linear models. In some embodiments, transformed variants of the relevant model(s) are the local node analysis, which reduce the complexity of these models. For example, placing monotonicity constraints on a nonlinear, nonmonotonic model to orient the model around a variable relationship that is known to be true, or using monotonic neural networks for machine learning applications. In some embodiments, the relevant visualizations are related but less complex models that approximate the applicable model(s), particularly machine learning models. For example surrogate models, local interpretable model agnostic explanations (LIME), maximal activation analysis, linear regression and sensitivity analysis.

When a local node has listed the models 502 and analyzed the relevant data 503, the local node can then generate the characteristics of the model update 504, which is sent to the rest of the update system. In some embodiments, a local node diagnostics module generates the model features 504. In some embodiments, the features of the model update are local node independent, i.e., the model update is usable by any of the local nodes in the update system. Therefore, the model update generated by the local node is stripped of all data specific to that local node. In some embodiments, the model update characteristics include one or more of the following: one or more algorithms, date and time of creation, number of events recorded over a period of time, metadata or aggregated statistics at a high level such as total transaction value over time and the threshold point or the threshold points used to trigger the model update. In some embodiments, the model update features include a ratio statistic of one or more data group averages. In some embodiments, the model update may detect a deviation from the ratio statistics of one or more data group averages to determine future positive outcomes. In some embodiments, the model update features include one or more network or map graphics representing one or more models. In some embodiments, the model update features include one or more network or map graphics that represent the new model.

When a local node has generated the model features, 504, the local node may issue the model update, 505. In some embodiments, the local node issues the model update to a central module of the update system, which receives the model update, 506. For example, the monitoring module 211 of the local node 210 receive a model update from the diagnostic model 212, and then the monitoring module 211 can send the model update to the central module 201, which receives the model update.

Upon receiving a model update from a local node 506, a host module of an update system then queries 507 a model database. In some embodiments, the host module queries a model database to determine if the model update already exists. In some embodiments, the central module queries a model database to determine whether the model update replaces an existing model in the database or is a new model for the database. If the central module in some embodiments querying the model database and determining that the model update could replace or modify an existing model in the database, the central module can retrieve model information from the existing model. In some embodiments, the model information may include one or more of the following: the date and time the model was created, the date and time the model was last updated, and how many local nodes are currently using the model. For example, upon receiving the model update from the local node 210, the central module 201 checks the model update against the available model database 202. The central module 201 determines whether the model update already exists in the available model database 202, and should this be the case , the central module 201 extracts relevant information about all existing models.

After the central module of an update system queries a model database, the central module determines the priority level of the model update, 508. In some embodiments, the priority level of the model update is listed as high, medium, or low. In some embodiments, the priority level of the model update is listed on a numeric scale, for example in a range of 1 to 10 or some other general numeric range. In some embodiments, the central module determines the priority level of the model update by comparing the model update features to a predetermined scale. In some embodiments, the central module determines the priority level of the model update by comparing the model update features against a model database. In some embodiments, the central module determines the model update priority level by comparing the model update features to model information stored in an existing model database. In some embodiments, comparing the model update features to the existing model information results in a priority level, which is then converted to a priority level.

For example, after the central module 201 of the update system 200 has checked the model update against the available model database 202 for detection of credit card fraud, the central module 201 determines that a similar model already exists in the database and pulls information about the existing one model off. The central module 201 then compares the model update characteristics with the existing model information and calculates a priority level. As a first example, the central module determines that the existing credit card fraud detection model has not been updated for more than a year, that the model update is a direct replacement of the existing model, and that the model update improves the performance of a credit card fraud detection over an area of terms of use can increase. These differences lead to a high priority level, which the central module 201 converts to a high priority level. As a second example, the central module determines that the existing credit card fraud detection model has recently been updated, and that the model update would only be expected to improve performance in detecting credit card fraud with a sufficiently large user base known to have few end users have it. These differences lead to a relatively low priority level, which the central module 201 converts to a medium priority level.

After determining the priority, the update system would then determine the end users applicable to the new Model 509. In some embodiments, the central module determines which end users are applicable. In some embodiments, the central module determines which end users are applicable for the model update by comparing model update information with information about each end user in addition to the priority information of the new model. For example, if the model update for credit card fraud detection has a medium priority, the central module identifies which local nodes in the update system are involved in credit card fraud detection and then moves the model 510 to those identified local nodes. However, the model update would not be pushed to any remaining local nodes if each of those local nodes initiates an update process, for example if sufficient time has elapsed without an update to trigger the monitor module that a local node can subsequently receive the update. In another example, if the model update for detecting credit card fraud has a high priority, the central module issues the model 510 to all local nodes. In another example, if the model update for detecting credit card fraud has a low priority, the central module does not immediately push the model to any local node, but instead waits for each local node to initiate its own update process.

When the model update has been sent out by the central module, it is received by at least one local node 511. In some embodiments, the model update is performed by received from several local nodes at the same time. In some embodiments, the model update is received from the monitoring module in each of the embodiments described herein.

In some embodiments, when a local node has received a model update 511, it is not installed automatically. First, the local node queries the current model database to determine if the model update replaces any of the existing models 512 . Thereafter, the local node determines the relevance of the model update for the node 513. In the local node 210 of the in 2 For example, in the update system 200 shown, the model update is received by the monitoring system 211 and then passed to the diagnostic module 212. The diagnostics module 212 first queries the current database of current models 215 and then determines the relevance of the model update to the local node. In some embodiments, the diagnostic module 212 terminates the update process after the determining relevance step 513. In some embodiments, the diagnostic module 212 terminates the updating process after the determining relevance step 513 if the diagnostic module 212 determines that the model update for the local node fails is required. In some embodiments, the diagnostic module 212 terminates the update process after the determining relevance step 513 if the diagnostic module 212 determines that the model update already exists in the local node. In some embodiments, the diagnostic module 212 bypasses the determining relevance step 513 when the model update has a high priority.

In some embodiments, once the local node has determined that the model update would be relevant or necessary, the local node determines whether it has permission to apply the model update 514 . In some embodiments, the local node's evaluation module determines whether the local node is authorized to apply the model update. In some embodiments, a local node does not have permission to install the model update. In some embodiments, a local node does not automatically have permission to install any model update. In some embodiments, a local node must query or ask for authorization 516 from an end user before installing the model update. For example, the model update is passed to the evaluation module 213 when the diagnostic module 212 has either determined that the model update is relevant or that the model update has a sufficiently high priority to bypass the determining relevance step 513 . The evaluation module 213 then checks the local node's update permission settings. In some embodiments, if the evaluation module 213 determines that it does not have permission to install the model update, the evaluation module 213 terminates the update process. In some embodiments, the evaluation module 213 queries an end user, for example, by issuing a user prompt or sending an email or other communication to the end user prior to installing the model update.

The local node installs the model update if the local node determines that it is authorized to do so 515. In some embodiments, an evaluation module installs the model update. In some embodiments, each module of the update system installs the model update. In some embodiments, the model update installs one or more new models in a current models database in the local node. In some embodiments, the model update replaces one or more models in a current model database in the local node. For example, after creating the entitlement, the evaluation module 213 updates the database of current models 215 with the model update.

In some embodiments, upon completion of the update 515, the local node creates an output report 517. In some embodiments, the output report is shared with an end user. In some embodiments, the output report is shared with a central module of an update system. In some embodiments, the release report contains information about the model update including, for example, the type of the updated model, whether any of the old models have been replaced, the date and time of the update, whether the new model is currently active, or a combination thereof.

6 FIG. 6 depicts a flowchart of an exemplary method for moving a model update in an update system without a central module, in which the model update was automatically created by a local node in the update system 600. FIG. In some embodiments, the method 600 can be performed with the in 3 update system shown can be used. First, a local node in an update system detects a change in the results of its existing models 601. In some embodiments, a local node in an update system detects a change in fraud detection rates. In some embodiments, a change in fraud detection rates is an increase in fraud detection that is greater than a preset threshold. In some embodiments, the change in fraud detection rates is a significant increase or decrease in fraud instances over a period of time. In some embodiments, a local node in an update system detects a change in detected fraud size. In some embodiments, the change in fraud size is an increase in the value or dollar amount of a detected fraud event that is greater than a preset threshold. In some embodiments, the change in fraud size is a significant increase in the value or dollar amount of a detected fraud event compared to a running average or median of detected events. For example, the diagnostic module 312 analyzes as in 3 1, the system data 314 and detects an increase in fraud detection rate that is greater than a standard deviation from the 3 month running average fraud detection rate.

If a change in the results from the existing models has been detected 601, the local node lists all models involved in this detection 602. In some embodiments, the local node lists all models directly involved in generating the in step 601 recorded events are involved. In some embodiments, the local node lists all models directly and indirectly involved in generating the events captured in step 601 . In some embodiments, the local node lists all actively running models when the events at step 601 are captured. For example, with access to both the system data 314 and the current models database 315, the diagnostics module 312 lists all algorithm models directly and indirectly involved in generating the fraud events previously detected in step 601 .

When a local node has listed 602 the models relevant to 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 analyzes the System data to determine the characteristics and conditions relevant to the steps listed in step 602 in generating the events detected in step 601. In some embodiments, the local node analysis may include, but is not limited to, least squares, disadvantaged regressions, generalized additive models, quantile regressions, logistic regressions, and closed linear models. In some embodiments, transformed variants of the relevant model(s) are the local node analysis, which reduce the complexity of these models. For example, placing monotonicity constraints on a nonlinear, nonmonotonic model to orient the model around a variable relationship that is known to be true, or using monotonic neural networks for machine learning applications. In some embodiments, the relevant visualizations are related but less complex models that approximate the applicable model(s), particularly machine learning models. For example surrogate models, local interpretable model agnostic explanations (LIME), maximal activation analysis, linear regression and sensitivity analysis.

When a local node has listed the models 602 and analyzed the relevant data 603, the local node can then generate the characteristics of the model update 604, which is sent to the rest of the update system. In some embodiments, a local node diagnostics module generates the model features 604. In some embodiments, the features of the model update are local node independent, i.e., the model update is usable by any of the local nodes in the update system. Therefore, the model update generated by the local node is stripped of all data specific to that local node. In some embodiments, the model update characteristics include one or more of the following: one or more algorithms, date and time of creation, number of events recorded over a period of time, metadata or aggregated statistics at a high level such as total transaction value over time and the threshold point or the threshold points used to trigger the model update. In some embodiments, the model update features include a ratio statistic of one or more data group averages. In some embodiments, the model update may detect a deviation from the ratio statistics of one or more data group averages to determine future positive outcomes. In some embodiments, the model update features include one or more network or map graphics representing one or more models. In some embodiments, the model update features include one or more network or map graphics that represent the new model.

When a local node has generated the model features 604, the local node may issue the model update 605. In some embodiments, the local node issues the model update to at least one other local node of the update system that receives the model update 611. In some embodiments the local node issues the model update to all other local nodes of the update system. For example, the monitoring module 311 of the local node 310 can receive a model update from the diagnostic model 312, and then the monitoring module 311 can send the model update to the other local node 320 that receives the model update.

In some embodiments, when a local node has received 611 a model update, it is not installed automatically. First, the local node queries the current model database to determine whether the model update replaces any of the existing models 612. The local node then determines the relevance of the model update to the node 613. In the local node 310 of the in 3 For example, in the update system 300 shown, the model update is received by the monitoring system 311 and then passed to the diagnostic module 312. The diagnostics module 312 first queries the current database of current models 315 and then determines the relevance of the model update to the local node. In some embodiments, the diagnostic module 312 terminates the update process after the determining relevance step 613. In some embodiments, the diagnostic module 312 terminates the update process after the determining relevance step 613 when the diagnostic module 312 determines that the model update for the local knot is not required. In some embodiments, the diagnostic module 312 terminates the update process after the step of determining relevance 613 if the diagnostic module 312 determines that the model update already exists in the local node.

In some embodiments, once the local node has determined that the model update would be relevant or necessary, the local node determines whether it has permission to apply the model update 614. In some embodiments, the local node's evaluation module determines whether the local node is authorized is to apply the model update. In some embodiments, a local node does not have permission to install the model update. In some embodiments, a local node does not automatically have permission to install any model update. In some embodiments, a local node must query an end user or ask for permission before installing the model update 616. For example, if 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 local node's update permission settings. In some embodiments, if the evaluation module 313 determines that it does not have permission to install the model update, the evaluation module 313 ends the update process. In some embodiments, the evaluation module 313 queries an end user, for example, by issuing a user prompt or sending an email or other communication to the end user before installing the model update.

The local node installs the model update if the local node determines that it is authorized 615. In some embodiments, an evaluation module installs the model update. In some embodiments, each module of the update system installs the model update. In some embodiments, the model update installs one or more new models in a current models database in the local node. In some embodiments, the model update replaces one or more models in a current model database in the local node. For example, after creating the entitlement, the evaluation module 313 updates the current model database 315 with the model update.

In some embodiments, upon completion of the update 615, the local node creates an output report 617. In some embodiments, the output report is shared with an end user. In some embodiments, the output report is shared with a central module of an update system. In some embodiments, the release report contains information about the model update including, for example, the type of the updated model, whether any of the old models have been replaced, the date and time of the update, whether the new model is currently active, or a combination thereof.

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

The following table is a non-exclusive and non-exhaustive list of examples using any of the systems and methods disclosed herein. A credit card company uses multiple analysis models to evaluate transactional credit fraud. The models capture abnormal variations and fraud events, which are analyzed by the update system's diagnostic module. The diagnostic module triggers the monitor module to check if any model updates are available from a central module server so that the system has the most up-to-date models to analyze the abnormal variations. An insurance company uses multiple analysis models to generate an aggregate result that is used in insurance fraud investigations. In generating the results, some of the models under certain circumstances show a significant increase in detection of a specific type of fraud. The diagnostic module detects this significant increase and creates a model update that includes the models showing the increase, the date and time the event was detected, what type of fraud was detected, and under what circumstances the fraud was detected. The diagnostic module extracts all specific company data from the model update and creates a general model that can be applied to all system data. The monitoring module sends this new model update to a central module server where the update is analyzed and prioritized and then in turn sent to other local nodes/end users in the update system. A bank uses a feedback mechanism that combines analysis results from multiple models with human research results to determine that a new type of fraud is becoming more common. Feedback from human findings is used by the diagnostics module to determine the specific model features used to detect this emerging fraud. The diagnostic module transfers the model features used to detect this new type of fraud to the monitoring module and triggers feature generation so that existing models can use these new features to perform better detection. An insurance company uses a variety of models to perform event detection analysis, the results of which are sent to another model that examines trends in detection over time. This trend analysis finds that certain types of event coverage increase during certain time frames, such as natural weather events. The diagnostic module transmits this trend analysis result to the monitoring module, which then transmits the information to a central server. The trend analysis update is then broadcast to certain other local nodes.

7 FIG. 7 depicts a block diagram of an example data processing system 700 in which aspects of the illustrative embodiments are implemented. A data processing system 700 is an example of a computer, such as a server or client, residing on computer usable code or instructions that implement the process for illustrative embodiments of all disclosures described herein. In some embodiments 7 represents a server computing device, such as a server, that implements the system for interpreting analysis results described herein.

In the illustrated example, data processing system 700 may have a hub architecture with north bridge and memory controller hub (NB/MCH) 701 and south bridge and input/output (I/O) controller hub (SB/ICH) use 702. A processing unit 703, a main memory 704 and a graphics processor 705 can be connected to the NB/MCH 701. The graphics processor 705 can be connected to the NB/MCH 701 via an accelerated graphics port (AGP). Network adapter 706 is connected to SB/ICH 702. The audio adapter 707, a keyboard and mouse adapter 708, a modem 709, a read only memory (ROM) 710, a hard disk drive (HDD) 711, an optical drive (CD or DVD) 712, Universal Serial Bus (USB) ports and other data transmission ports 713 and PCI/PCIe devices 714 may be connected to the SB/ICH 702 via a bus system 716. PCI/PCIe devices 714 may include Ethernet adapters, add-in cards, and PC cards for notebook computers. The ROM 710 can be, for example, a basic flash input/output system (BIOS). The HDD 711 and the optical drive 712 can be an Integrated Drive Elect ronics (IDE) or Serial Advanced Technology Attachment (SATA) interface. The Super I/O (SIO) unit 715 can be connected to the SB/ICH 702.

An operating system can be executed on the processing unit 703 . The operating system may coordinate and provide control of various components in data processing system 700 . As a client, the operating system can be a commercially available operating system. An object-oriented programming system, such as the Java™ programming system, can run alongside 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, the data processing system 700 can be an ^IBM® eServer™ System ^p® running the Advanced Interactive Executive operating system or the ^LINUX® operating system. The data processing system 700 can be a symmetric multiprocessor (SMP) system with a plurality of processors in the processing unit 703 . Alternatively, a single processor system can be used.

Instructions for the operating system, object-oriented programming system, and applications or programs reside on storage devices such as HDD 711 and are loaded into main memory 704 for execution by processing unit 703. The processes for embodiments of the patient record error tracking system may be performed by the processing unit 703 using computer usable program code, which may reside in memory such as main memory 704, ROM 710, or in one or more peripheral units.

A bus system 716 can consist of one or more buses. The bus system can be implemented using any type of data transfer structure or architecture that provides transfer of data between various components or entities associated with the structure or architecture. A communications device such as modem 709 or network adapter 706 may include one or more devices used to transmit and receive data.

Those skilled in the art will appreciate that the hardware required to implement the systems and methods described herein may vary by implementation. Other internal hardware or peripheral devices such as flash memory, equivalent non-volatile memory, or optical disk drives may be used in addition to or in place of the hardware shown. Furthermore, all of the systems described herein may take the form of any of a number of different computing systems, including client computing devices, server computing devices, tablet computers, laptop computers, telephone or other communications devices, personal digital assistants (PDA), or the like , but you are not limited to it. Essentially, all systems described herein may be any known or later developed data processing system without architectural limitation.

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

While the present invention has been described with reference to exemplary embodiments, it is not limited thereto. It will be apparent to those skilled in the art that numerous changes and modifications can be made in the preferred embodiments of the invention. Therefore, it should be understood that the appended claims are intended to cover all such equivalent variations that fall within the scope of the invention.

Claims (35)

A computer program product for updating acquisition models, the computer program product having at least one computer readable storage medium embodied thereon comprises program instructions, the program instructions being executable by a processor to cause the processor to update at least one local node by: receiving the model update by at least one monitor module; determining the current acquisition models by at least one diagnostic module; determining, by at least one evaluation module, whether the model update should be applied to the current detection models; determining, by at least one evaluation module, whether the local node is authorized to apply the model update; and updating the current collection models with the model update by at least one evaluation module. computer program product claim 1 , wherein the program instructions executable by the processor further cause the processor to distribute the model update to at least one local node. computer program product claim 2 , where the model update is distributed to at least two local nodes. computer program product claim 2 , wherein the model update is distributed to at least one local node by a central module. computer program product claim 4 wherein the central module distributes the model update to at least one local node by: receiving the model update by the central module; analyzing a database with available models by the central module; determining a priority level for the model update by the central module; determining, by the central module, which local nodes should receive the model update; and sending the model update to at least one local node by the central module. computer program product claim 5 , where the available models database has available models for all local nodes. computer program product claim 5 , where the priority level is determined by comparing characteristics of the model update to model information in a database of existing models. computer program product claim 2 , where the model update is distributed to at least one local node by another local node. computer program product claim 1 wherein the program instructions executable by the processor further cause the processor to create a model update. computer program product claim 9 , where creating a model update occurs in a local node. computer program product claim 10 , wherein creating the model update is performed by: detecting a significant change in the system data by the 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 the model update by the diagnostic module; and the monitor module sending the model update. computer program product claim 11 , wherein the generated model update comprises one or more items selected from the group consisting of: one or more algorithms, date and time of creation, number of collected over a given time period events, aggregate statistics, and the threshold point or points used to trigger the model update. computer program product claim 11 , where the generated model update has no system data specific to the local node that generated the model update. computer program product claim 11 , wherein the monitoring module sends the model update to a central module outside the local node. computer program product claim 11 , wherein the monitor module sends the model update to a monitor module from another local node. System for updating acquisition models, comprising: at least one local node that has: a monitoring module; a diagnostic module; an evaluation module; one or more current acquisition models; and system data generated by the current acquisition models; and memory having instructions executed by at least one processor configured to: receiving, by the monitoring module, a model update; determining, by the diagnostic module, the current acquisition models; determining, by the evaluation module, whether the model update should be applied to the current detection models; determining, by the evaluation module, whether the local node is authorized to apply the model update; and Update the current collection models with the model update by the evaluation engine. system after Claim 16 , the system further comprising at least two local nodes. system after Claim 17 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. system after Claim 18 , the system further comprising a database with all available models for the system, which is in electronic communication with the central module. system after Claim 18 , wherein the monitoring module is configured to receive model updates. system after claim 20 , wherein the monitoring module can receive a model update from a system administrator or from a local node. system after Claim 17 , the instructions being further configured to: detect, by the diagnostic module, a significant change in the system data; determining, by the diagnostic module, a list of all current acquisition models involved in the acquisition step; analyzing, by the diagnostic module, the system data involved in the detecting step; generating the model update by the diagnostic module; Sending the model update by the monitoring module. system after Claim 22 , wherein the generated model update comprises one or more items selected from the group consisting of: one or more algorithms, date and time of creation, number of events recorded over a specified time period, aggregated statistics, and the threshold point or points , which are used to trigger the model update. system after Claim 22 , where the generated model update has no system data specific to the local node that generated the model update. system after Claim 16 , further comprising: at least a second local node; a central module, the monitoring module of each local node being in electronic communication with the central module; and a database of all available models for the system in electronic communication with the central module; and memory comprising instructions executed by at least one processor configured to: create a model update comprising: the diagnostic module detecting a significant change in the system data; determining, by the diagnostic module, a list of all current acquisition models involved in the acquisition step; analyzing, by the diagnostic module, the system data involved in the detecting step; generating the model update by the diagnostic module; the monitor module sending the model update; Distributing a model update, comprising: receiving, by the central module, the model update; analyzing the database of available models by the central module; determining a priority level for the model update by the central module; determining, by the central module, which local nodes should receive the model update; and sending the model update by the monitoring module; and updating at least one local node, comprising: receiving, by at least one monitoring module, a model update; determining the current acquisition models by at least one diagnostic module; determining, by at least one evaluation module, whether the model update should be applied to the current detection models; determining, by at least one evaluation module, whether the local node is authorized to apply the model update; and updating the current collection models with the model update by at least one evaluation module. A computer-implemented method in a data processing system having a processor and memory having instructions executed by the processor to cause the processor to implement a system for updating acquisition models, the method comprising: Updating at least one local node that has: receiving, by a monitor module, a model update from at least one local node; determining, by a diagnostics module of the local node, the current acquisition models used by the local node; determining, by an evaluation module of the local node, whether the model update should be applied to the current detection models; determining, by the local node's evaluation module, whether the local node is authorized to apply the model update; and Update the current collection models with the model update by the local node evaluation engine. procedure after Claim 26 , the method further comprising updating at least two local nodes. procedure after Claim 27 , the method further comprising distributing the model update by a central module. procedure after claim 28 , the method further comprising analyzing, by the central module, a database with available models. procedure after claim 28 , the method further comprising determining, by the central module, a priority level of the model update. procedure after claim 28 , the method further comprising determining, by the central module, which local nodes should receive the model update. procedure after Claim 27 , the method further comprising: creating a model update, comprising: detecting, by the diagnostic module, a significant change in the system data; determining, by the diagnostic module, a list of all current acquisition models involved in the acquisition step; analyzing, by the diagnostic module, the system data involved in the detecting step; generating the model update by the diagnostic module; Sending the model update by the monitoring module. procedure after Claim 32 , wherein the generated model update comprises one or more items selected from the group consisting of: one or more algorithms, date and time of creation, number of events recorded over a specified time period, aggregated statistics, and the threshold point or points , which are used to trigger the model update. procedure after Claim 32 , where the generated model update has no system data specific to the local node that generated the model update. procedure after Claim 26 , further comprising: creating a model update, comprising: detecting, by the diagnostic module, a significant change in the 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 by the diagnostic module; and sending the model update by the monitoring module; Distributing the model update, comprising: receiving, by a central module, the model update; analyzing a database with available models by the central module; determining a priority level for the model update by the central module; determining, by the central module, which local nodes should receive the model update; and sending the model update to at least one local node by the central module; and updating at least one local node, comprising: receiving, by at least one monitoring module, the model update; determining the current acquisition models by at least one diagnostic module; determining, by at least one evaluation module, whether the model update should be applied to the current detection models; determining, by at least one evaluation module, whether the local node is authorized to apply the model update; and updating the current collection models with the model update by at least one evaluation module.

Images