Continuous anomaly detection based on behavior modeling and heterogeneous information analysis

[0001] This application is a continuation of U.S. patent application Ser. No. 12/941,849, filed Nov. 8, 2010, which claims the benefit of U.S. Provisional Patent Application No. 61/280,791 filed on Nov. 6, 2009. The contents of all the above-listed patent applications are hereby incorporated by reference in their entirety.

[0002] The present disclosure falls into the general area of anomaly detection, and more particularly, anomaly in human behavior analyzed from electronic data. It can be applied to a number of domain-specific scenarios such as compliance monitoring or risk management in high-risk domains such as investment banking or intelligence. It is also applicable to malicious insider detection in areas ranging from corporate theft to counter-intelligence or the broader intelligence community.

[0003] Anomaly detection is a general goal that can fulfill a number of missions, ranging from the prevention of activities perpetrated by malicious insiders to unintentional threats, as well as more generally managing human and operational risk.

[0004] Previous approaches to anomaly detection have included:

• • [0005] Rule-based compliance systems based on keyword matches or content identification (for example using a fingerprinting technology).
  • [0006] Correlation engines where different types of events are put in relation and the rules to trigger an alert are somewhat more flexible than the previous type of systems (producing for example one-dimensional anomalies based on histograms).

[0007] There are essential limitations shared by all these systems. One of the main limitations is that they can be circumvented due to the static character of the rules used to configure them, so that they are unable to cover the infinite spectrum of potentially damaging behaviors and actions that can take place in a large organization.

[0008] In addition, even the most efficient of these previous systems are restricted to a vertical business domain, as the definition of the rules and correlation methods is highly dependent on the underlying business data and processes. Furthermore, even very domain-specific work is usually done in a cross-media, cross-system manner, in which (for example) emails, instant messages and phone calls can be an integral part of processes which in theory are implemented with a dedicated application. Nevertheless such unstructured, out-of-band communication is usually ignored by existing systems. An example of such a vertical domain is the banking and financial services industry in which compliance systems are very often tied to specific transactional systems.

[0009] Also, the fact that these systems rely on rules or patterns which, even when they are learned automatically by a machine, correspond to confirmed signs of malicious or otherwise risk-carrying activities, implies that they only detect these events after the fact, and that there is no way to anticipate them. This is a major limitation in their detection capabilities, since recent studies of espionage and IT sabotage cases have shown that nearly half of malicious insiders exhibited some inappropriate, unusual, or concerning behavior prior to the incident, but had no recorded incidents of violating organizational policies.

[0010] Most of these systems are limited in their analysis scope to data sources located within a particular organization, without the capability to take into account external sources such as public websites or personal communication channels [156] on which insiders also interact and exchange information.

[0011] Finally, most anomaly detection systems only report threats once they have harmed the organization or its employees. In particular, malicious insiders are typically flagged once they have perpetrated their actions (when they are flagged) and the associated damage can then only be mitigated rather than prevented.

[0012] The present disclosure addresses the prior limitations noted above.

[0013] Firstly, the present system is considerably more difficult, and in most situations almost impossible, to circumvent. This is because it builds a holistic model, which covers both structured and unstructured data, but which also covers human behavior, including communications [123] among people and interactions between people and data. That model can be integrated with the organization's infrastructure to provide complete coverage of human and machine activities. A key aspect of this model is the determination of regularity in behavior, both at the individual and group level; behavior, especially in an organizational context, is anything but random. This disclosure is data-driven, and not primarily rule-driven, so that it can automatically adapt to changes in the analyzed data or in the environment, including when human behavior itself is changing. (It should be noted however that this disclosure also supports the definition of rules as an essential requirement, since they are an intrinsic part of many regulatory or internal policies in place in large organizations.)

[0014] Secondly, the problem of applicability scope mentioned above is also addressed by the present disclosure, as it is suitable for any type of domain. This is because it does not require the explicit definition of a set of rules or anomalous patterns, but also because it handles unstructured data in a generic manner, and is able to correlate that data with the type of structured data to which vertical anomaly detection systems are often restricted.

[0015] Thirdly, the present disclosure establishes a multi-dimensional behavioral model that is based on normalcy, i.e. on how people habitually communicate, work, and interact, rather than on expected behavior defined by a predefined number of dimensions. Every risk-generating activity is characterized by at least some change in behavior: even malicious insiders who go to great lengths to circumvent detection mechanisms in place will leave some trace in electronic form that will result in a deviation from baseline behavior—whether from their own established baseline or that of their peer group—even when no rule has been violated, and when the malicious activities in question do not fit any scenario known a priori.

[0016] Finally, in contrast to the reactive mode of operation of most anomaly detection systems, the present disclosure provides techniques that allow an organization to proactively detect such threats by spotting precursory signs of malicious activity, and thus intervene and prevent the threats from being executed. Such signs always precede the perpetration of the malicious insider's actions however they are only detectable by a system which performs holistic analysis and which detects any significant and therefore possibly relevant deviations from normal behavior—as opposed to a finite number of pre-defined rule violations (also known as patterns or “signatures”).

[0017] The novel way in which the systems and methods of the present disclosure solves these and other common limitations relies heavily on the following characteristics:

• • [0018] A holistic analysis of information, which takes into account relationships between data items, between comparable individuals and groups, between formal or informal processes, and across these different entities (for example, a method called document lifecycle analysis allows the present disclosure to model relationships between people and the data they exchange or manipulate).
  • [0019] A rich, extensible mechanism to accurately model human behavior and to detect anomalies in this behavior with respect to temporal, organizational, or other dimensions.
  • [0020] A scalable method of applying these behavior modeling and holistic information analysis capabilities to massive volumes of data, processed in a continuous manner.
  • [0021] A unique combination of reactive and proactive anomaly detection mechanisms—this combination produces a manageable quantity of alerts that are consistent and directly interpretable. Without being able to constrain the number of alerts and manage their quality, an anomaly detection system such as the one described here would not be realistically deployable.
  • [0022] Automatic quality assessment and performance guarantees obtained by auto-adjustment of the system, both with respect to data characteristics and to user input.

[0023] An extensible application framework to efficiently visualize patterns derived from analyzing electronic data and human behavior, and to show how those patterns evolve over time and across the organization.

[0024] In one embodiment, the present disclosure describes a system and a method to enable a holistic and continuous analysis of information to accurately model human behavior and to detect anomalies in this behavior with respect to, but not limited to, temporal, organizational, or other dimensions.

[0025] The system is able to infer potentially damaging activities, whether of unintentional or malicious nature, without requiring the prior definition of the type and characteristics of these activities. It relies on the analysis of potentially massive volumes of heterogeneous electronic data (includes both text-bearing and non-text-bearing records) stored inside or outside any organization. That analysis can be performed either in discrete increments or in real-time. The present disclosure establishes structural and semantic patterns from the analyzed data and builds a predictive multi-dimensional model of both individual and collective behavior which allows detecting abnormal patterns in these behaviors as well.

[0026] Some embodiments of this system are intended to run at a much smaller scale than much of what is described here. The smallest scale is at the level of individual personal use, to observe or monitor one's personal ecosystem through all available communication channels, including social media such as Facebook or Twitter. Such personal usage would not include a compliance system for example, but could be used to do things such as observe shifts in popularity, influence, stress within one's circle, and other things that are described in this application and in previous ones. Somewhat larger scale usage for small business would likewise be unlikely to have enterprise systems present such as an HR system, an accounting system, or a compliance system, but could nevertheless very beneficially be used to do things like identify which processes were causing friction amongst the staff, who is “buck passing”, etc.

[0027] Some embodiments will therefore make suggestions directly to the user based on evidence. To take a simple example, in single user use, the system could point out that the user was very slow to respond to their grandmother—maybe it is time to call her or send her mail; that the user tends to “yell” about certain topics and should avoid doing so in future; or that they are spending way more time this year than they did last year on the NCAA betting pool during working hours, etc.

Overview

[0150] The present disclosure efficiently performs continuous monitoring of data produced or circulating within an entity, or social network, whether it is within a specific entity or on the world wide web, especially when relying on a high volume of electronic data, and uses novel behavioral analysis techniques in order to detect, report and/or make users aware of possibly preventable damaging events, of an accidental or fraudulent nature.

[0151] FIGS. 1, 2, and 3 depict the key elements and concepts of the system described in accordance with an embodiment of the present disclosure.

[0152] Event [100]: The central unit of analysis of the present disclosure. Depending on its origin, an event can be an observed event [102] exogenous to the system, a derived event [104] produced by the system, or user input [106] manually entered through an embodiment of the disclosure.

[0153] Evidence [108] is derived by the system after collecting, processing, and analyzing events [100]. Evidence is represented by the system as OSF [110] or order sorted features structures for which grammar [112] rules can be defined. OSF's [110] are stored as a hypergraph [114] model in one embodiment.

[0154] Token [116]: The smallest unit of analysis of the disclosure. In one embodiment, this atomic unit of analysis is a linguistic term. In another embodiment, it is a single character. N-grams [118] are continuous sequences of tokens [116] of length n, where n is a fixed, pre-determined integer.

[0155] Pattern [120]: A model for a number of features shared by multiple items [122] and to represent the structure underlying those items [122]. Each such pattern [120] can be matched by one or more pieces of evidence [108] derived by the system. A textblock pattern [124] is a model for contiguous blocks of text that is associated with one author, and is substantive enough to be treated potentially as an independent object in the system. Textblock patterns [124] are derived by the system from building a textblock graph [160] which contains transitions between n-grams [118]. A periodic pattern [126] is a model of events [100] that are occurring at exactly or approximately regular intervals over time. A workflow process [128] is a formal or ad hoc source of evidence [108] that constrains specific events [100] to be performed according to a number of workflow stages [154]

[0156] Discussion [136]: A possibly heterogeneous partially ordered set of electronic record items [122] for which it is presumed that any item [122] is causally related to all items [122] immediately following it by one or more sources of evidence [108].

[0157] Items [122], such as electronic communications [123] collected from any kind of communication channel [156] or electronic documents [162] can; upon processing by this disclosure, be assigned a number of item tags [142] which are a form of metadata [140] computed by the system on the basis of categorization components [146] such as an ontology [148] composed of a set of ontology classifiers [150], or a topic detection [152] method. A discussion [136] in which items [122] have been marked using item tags [142] constitutes a tagged sequence [138].

[0158] Actor [220]: A human or computer system which produces items [122] and is associated with one or more distinct electronic identities [235] such as email accounts, IM handles, system logins, etc. An actor [220] may be deemed to have more than one personality [230] if the content created or received by at least one of the different electronic identities [235] varies significantly from that of the others, where an electronic identity [235] can be an electronic alias [240] on some communication channel [156] or any reference to an individual, for example by name [245].

[0159] A group [225] is a container object for actors [220]. They can be formal groups [250], for example when an organizational chart is available to the system. Other types of groups [225] can be derived by the system from sociological and behavioral analysis, such as cliques [255] also known as circles of trust, which are a set of actors who consistently correspond in a closed loop with one another.

[0160] A typed update [107] is a light representation of an incremental change to an evidence or event that can be forwarded to different components, A typed update [107] references one or several evidences or events that are affected by the changes. Because we are dealing with continuous and very large streams of data, forwarding typed updates [107] instead of resending whole results every time an evidence or event is updated greatly reduces the amount of traffic between components, especially when it comes to updating previously computed results. In some embodiments, typed updates [107] can take the form of deltas or simple incremental data changes. In other embodiments, a typed update [107] can consist of a function or set of declarations and operations to be applied to existing data in order to mutate it.

[0161] According to one aspect, anomaly detection means that the system is able to infer potentially damaging activities, whether of unintentional or malicious nature, without requiring the prior definition of the type and characteristics of these activities.

[0162] According to one aspect, heterogeneous information analysis means that all kinds of electronic information stored in a corporation or another kind of organization can be processed by the system in a unified manner and consistently lend themselves to the detection of abnormal patterns in the data. This includes both text-bearing and non-text-bearing records.

[0163] According to one aspect, multi-dimensional behavioral modeling means that in addition to analyzing pieces of information, the building of a predictive multi-dimensional model of both individual and collective behaviors allows detecting abnormal patterns in these behaviors as well.

[0164] The present disclosure describes a method for building and continuously maintaining a behavioral model [200]. This model represents assessed behavior [205] which can be either individual behavior [210] or collective behavior [215]. In order to detect anomalies [270], the system establishes baseline behaviors [260] which are a synthetic representation of communication habits and normal interactions, then assesses deviations [265] by comparing assessed behaviors [205] to such a baseline. This allows the detection of anomalies in recent or past behavior, however the system also attempts to predict behavior [262] in the near future based on the behavioral model [200]. To compute that behavioral model [200], the disclosure relies on a number of behavioral traits [295] which are dimensions according to which an actor's [220] personality and behavior can be reliably measured, and are computed based on a set of behavioral metrics [290]. Actors [220] and their assessed behaviors [205] can then be evaluated on an absolute scale using scores [285], and on a relative scale using ranking [275] mechanisms, in order to assess the relevance [280] of any detected anomaly [270].

[0165] The behavioral model [200] computed by the system, as well as the anomalies [270] produced, are presented by the system using supporting evidence [202] and visualizations [204] in one embodiment.

[0166] A visualization [204] is produced in several stages. Data is generated [365] over time either by an iterative process over batches of data [370], or on a continuous basis [375] using for example a sliding window mechanism [380]. Input data [365] for a particular visualization [204] is then selected [360] either automatically by the system or interactively by a user. A layout [355] is then produced to efficiently display [350] the visualization as part of the system's user interface [300].

[0167] The system continuously raises alerts [305] about behavior flagged as anomalous, for which notifications can be automatically sent to the user. An alert [305] can be a past alert [306] based solely on already analyzed events [100], or a predicted alert [307] based on the likelihood of some events [100] occurring in a near future and associated to anomalous behavior or patterns. Alternatively, reports [310] on behavior and information analysis can be regularly scheduled or generated on-demand. The system can be set up to continuously monitor specific queries [325]. Finally, a complete audit trail [330] is available that comprises collected data as well as all types of evidence [100] stored in the collection repository [320]. Access to this audit trail [330], like the rest of the application data [315], is restricted by access controls [335] whose scope is determined by a coloring scheme [345] and whose restrictions are defined at a fine-grained level using an anonymization scheme [340].

[0168] FIG. 4 illustrates the general architecture of the system in accordance with an embodiment of the present disclosure.

[0169] A user of the system [455] is typically an analyst or human operator whose role is to respond to alerts raised by the system before a malicious act is perpetrated, or right after unintentional damage has occurred, as well as to actively investigate any leads or patterns with the help of the system's analysis results.

[0170] A central event passing infrastructure [460] is used by all components in the system to exchange data. That infrastructure can be distributed and ideally tries to keep data in flight as much as possible to maximize the system's throughput. That exchanged data comprises:

• • [0171] Observed events [102] that have been collected and captured by the data collection component, including but not limited to documents [162], messages exchanged on a communication channel [156] such as email, instant messages, phone logs and voicemail, as well as structured events such as database records;
  • [0172] Derived events [104] including but not limited to the output of the processing and analysis layer [402] (discussions [136], patterns [120], item tags [142], detected anomalies [270]); and
  • [0173] Any kind of user input [106].

[0174] Data handled by the event passing infrastructure [460] is pushed to components in the processing and analysis layer [402]. In one embodiment, events [100] are serialized as OSFs [110].

[0175] A set of scoping policies [485], such as sliding windows [380] over the incoming data stream, are used in some embodiments to regulate the processing of events [100] by downstream components. The data collection component [400] collects data continuously or in batch mode from a variety of heterogeneous data sources [401], extracts their content and their metadata and stores the extraction results for access by downstream components of the system.

[0176] The continuous categorization component [420] analyzes the incoming stream of events [100] to assign one or more categories to those events [100], using any number and variety of categorization components [146], and maintaining the validity and quality of the results even in the case of categorization components [146] that are inherently data-dependent.

[0177] The continuous discussion building component [410] establishes discussions [136] as a structure linking causally related items [122]. The discussion-building mechanism described in the present disclosure builds on the disclosure described in U.S. Pat. No. 7,143,091 to support a continuous mode of operation [375] in a highly-scalable manner.

[0178] The continuous clustering component [412] produces clusters of items [122] or events [100] from the incoming data stream on a continuous basis. It is a required stage of continuous discussion building [410].

[0179] The continuous periodic patterns detection component [405] analyzes the incoming stream of events [100] to find event sequences [166] that are recurrent over time and occur at roughly periodic intervals, thereby constructing periodic patterns [126] on a continuous basis.

[0180] The continuous workflow analysis component [465] automatically detects ad hoc workflow processes [128] from the incoming stream of events [100] and analyzes the workflow instances [134] corresponding to those processes [128], including the detection of anomalies [270] in their realization.

[0181] The continuous emotive tone analysis component [435] is used in some embodiments by the system to identify and analyze occurrences of emotional expression in electronic communications [123], which provide valuable categorization information to other components of the system, particularly the behavioral modeling component [445].

[0182] The pragmatic tagging component [430] is another component used in some embodiments of the system which is based on linguistic analysis: it categorizes the communicative and discourse properties of electronic communications [123]. In particular, its output produces an abstract workflow model that lets the system detect and analyze workflow processes [128] associated to the realization of specific tasks.

[0183] The textblock detection component [470] automatically identifies maximum contiguous sequences of sentences or sentence fragments which can likely be attributed to a single author. Once these textblock patterns [124] have been detected, any item [122] that contains that textblock or a significant portion of it is flagged by the system as a textblock hit [130], which allows the system to assess how information is exchanged or disseminated by specific actors [220].

[0184] The behavioral modeling component [445] builds and maintains a model [200] of individual behavior [210] and collective behavior [215], which is defined by any number of behavioral and personality traits [295] that can be determined in the specific scenario at hand. A user of the system [455] can view that behavioral model [200] using a number of visualizations [204] described in the present disclosure.

[0185] The anomaly detection component [450] continuously monitors the incoming stream of events [100] (both observed [102] and derived [104], including the behavioral model [200]) with the main goal of spotting anomalous behavior and anomalous patterns in the data based on statistical, analytical, and other types of properties associated to both recent data and historical data. The anomaly detection component [450] also produces alerts [305] by aggregating anomalies [270] and reports [310] sent to the user [455]. The system also comprises time-based and behavior-based continuous visualizations [204] of those alerts [305]. Anomalies [270] detected by this component are also fed to visualizations [204] in order to highlight anomalous patterns to the user [455], and can optionally trigger mitigating or preventive actions. In some embodiments, the anomaly detection component [450] includes an anomaly detection tuning scheme which maintains the relevance and the accuracy of produced anomalies [270] based among other things on anomaly feedback [158] However, in most such embodiments, all alerts [305] are still calculated and the user [455] is informed when significant numbers of different types of anomalies [270] associated with the same actor [220] are observed by the system; at any rate, all such instances are logged. These measures are to prevent the system behavior largely defaulting to that of a traditional system if users [455] should treat it as a rule-based system (e.g. by specifying what types of anomalies [270] they do want to see and which ones they don't, thus defeating the idea that change or deviation is by itself interesting and potentially critically important.)

[0186] The continuous multi-dimensional scaling component [425] computes a low-dimensional layout of an incoming stream of events [100]. Its output is particularly useful for the sequence viewer [440] which shows a potentially massive number of tagged sequences [138], for example those corresponding to the realization of a particular workflow process [128], thereby outlining dominant patterns and outliers in the instances [134] of that workflow process [128].

[0187] The alias usage browser [478] is a visualization [204] used in the present disclosure to efficiently display and navigate through the results of actor analysis [480], for example performed as described in U.S. Pat. No. 7,143,091 which is incorporated by reference herein for all purposes.

[0188] Finally, a number of continuous visualizations [204] show patterns [120] derived by the system from the data and from human interactions and behaviors, as well as the anomalies [270] that may have been detected in those patterns. These continuous visualizations [204] include, but are not limited to: animated actor graph visualizations [471], the social you-niverse visualization [472], the stressful topics visualization [473], the temperature gauges visualization [474], the buck passing visualization [475], the pecking order visualization [476], and the love life visualization [477]

[0189] In the following sections, each of these components is specified in more details, along with one or more embodiments and how it relates to the other components in the present disclosure.

Data Sources

[0190] The system described in the present disclosure processes and analyzes electronic data continuously collected from any number of data sources [401]. Those data sources can be of virtually any type: a particular embodiment of the present disclosure only needs to extract the data and metadata from types of data sources relevant to the scenario at hand. Types of data sources that can be leveraged by the system for behavioral modeling and anomaly detection purposes include, but are not limited to the following.

[0191] Electronic communication channels: emails (collected from email clients or from email transfer agents), instant messaging, calendar events, etc.

[0192] Electronic document sources: document management systems, file shares, desktop files, etc.

[0193] Phone data sources, including phone logs, phone conversation transcripts, and voicemail.

[0194] Log files: application log files, system log files such as syslog events [100], etc.

[0195] Databases: changes to table rows in a relational database or more generally events [100] captured in real time during a transaction.

[0196] Public social networks, such as Facebook, Twitter, etc.

[0197] Other public data feeds: market data feeds, news feeds, etc.

[0198] Physical data sources: physical access logs (keycards, biometrics, etc.), sensors and sensor networks (including RFID readers), geo-location information collected from portable devices, etc.

[0199] External monitoring system: as described in this disclosure, any external monitoring system can be integrated as a data source, for example rule-based compliance systems or network intrusion detection systems.

[0200] Individual data collected from internal sources: travel and financial information, background check and psychological evaluations of individuals in the organization, results of internal investigations, etc.

[0201] Individual data collected from external sources, personal communication channels (such as email accounts, weblogs or websites), data publicly available on the internet, data subpoenaed in the case of a law enforcement organization, wiretaps and intelligence collected from the field in the case of an intelligence organization, etc.

Scoping Policies

[0202] The first component which regulates how data flows through the system in many embodiments is the scoping policies component [485]. In presence of a quasi-infinite stream of data, as is usually the case with continuous applications, the system needs to possess extensive data flow management and data aging policies.

[0203] This role is carried out by the scoping policies component [485]. Its functionality is transversally used by all other data manipulating components of the system. Most embodiments maintain an audit trail of changes to the scoping policies. The scoping policies component may have multiple policies defined, the highest priority being executed first. The scoping policies component [485] is essential to the continuous mode of operation of other components, such as the data collection component [400] and the continuous clustering component [412].

[0204] One of the simplest examples of a scoping policy is an aging policy where a sliding window [380] of time is maintained over the incoming stream of data. Every time a piece of data falls out of the window [380], a notification message is sent to all the components notifying them that they are free to discard that data.

[0205] Another type of scoping policy can evict data based on a set of predicates. For example, a predicate that states that every email coming from a certain group of actors [225] should be first to be discarded when resources are low, or based upon an order from a properly authorized user of the system [455] requiring certain sensitive data be removed from the system.

[0206] The scoping policies component [485], based on the configuration, will or will not attempt to enforce any action to be taken by processing and analysis components. In case the scoping policies component [485] is configured to not enforce its policies, the other components should decide by themselves what to do when they receive the notifications.

[0207] In one embodiment, asynchronous procedures can be launched to effectively “garbage collect” the discarded records from the caches. Some policies, such as the aging policy illustrated above, can also be coupled with archival systems or historical databases which will guarantee exploration of the data outside of the continuous flow. Setting up archival systems or historical databases is optional, however, and is not necessary for the proper operation of the system.

Data Collection

[0208] The data collection stage of the present disclosure builds on the method described in U.S. Provisional Patent Application No. 61/280,791, the disclosure of which is incorporated by reference herein for all purposes, while integrating that method into an anomaly detection scenario and adapting it to a continuous mode of operation [375]. The main implication of the latter requirement is that due to new data being processed continuously by the system, a pruning mechanism is necessary to keep the volume of persisted data bounded, or at least to keep the increase rate of that volume bounded.

[0209] As shown in FIG. 5, data collection is performed by the data collection component [400] within a collection session [500] in any combination of the following ways.

• • [0210] A human user launching a collection session [500] from a machine hosting the data collection component [400] or remotely [505].
  • [0211] The data collection component [400] automatically collecting data in a continuous mode [510].
  • [0212] The data collection component [400] automatically collecting data in incremental mode [515], i.e. as a series of batch operations.

[0213] Any of these collection modes can be combined within the same collection session [500]. In particular, when the system is being run for the first time, collection will be initiated in a continuous mode [510] to collect future data (such as data captured in real-time from external data sources [401]) but the user can also at the same time, or at a later time, set up incremental collections [515] from data sources [401] hosting historical data. This allows the system to provide input data [365] to analytical visualizations [204] as early as possible, while other components such as the behavioral modeling component [445] require historical data to have been processed and analyzed in order to establish a behavioral baseline [260].

Collection Rate Adaptation

[0214] The continuous data collection component [400] described in the present disclosure has a collection rate adaptation scheme which takes into account several elements to adjust the rate, including but not limited to the following:

• • [0215] 1. Data collection throughput and load from the various data sources [401], in order to avoid any disruption of live sources [401] (such as mail servers) and ensure a pre-defined level of quality of service. In one embodiment of the present disclosure, a set of performance goals are defined in the system configuration, which consists of a maximum CPU usage ratio, and of a maximum I/O usage ratio on each machine hosting all or part of a data source [401].
  • [0216] 2. Data processing throughput, which is maximized with respect to the other constraints. In one embodiment, a performance goal is defined in the system configuration by a minimum processing throughput value. In another embodiment, the performance goal is the priority threshold above which a data source [401] must be fully processed (i.e. the entirety of its events [100] must be collected and analyzed by the system in any given time interval). To ensure that the performance goal for processing throughput is achieved, the data collection component [400] is able to enroll additional processing machines at any time to distribute the load; conversely, it is able to free processing machines when the performance goal is exceeded by a pre-defined value.
  • [0217] 3. Priorities of the different data sources [401] (and the fine-grained locations within each data source [401]), depending both on user prioritization and on system judgments. In one embodiment of the present disclosure, the system checks at regular intervals whether data collection throughput is saturated; if it is, then the data source [401] with lowest priority is set into an inactive state; in the contrary case, the inactive source [401] with highest priority is activated.
    Collection Scope

[0218] Data collection covers both structured and unstructured data available from locations, including but not limited to:

• • [0219] At the organization's boundaries (internet, intranet)
  • [0220] On servers (document repositories, file shares, etc.)
  • [0221] At the endpoints (desktops, laptops, mobile devices, etc.)
  • [0222] From public data sources [401] (for example, information about a company publicly available on the web, financial market data, data from social networking platforms—whether business-oriented or not)

[0223] The data model underlying the collection process is detailed in U.S. Pat. No. 7,143,091, the disclosure of which is incorporated by reference herein for all purposes. One of its most important characteristics is that it models associations between structured and unstructured data (more precisely, attributes and textual content are indexed and processed identically) as well as associations between business transactional data and generic professional data (in particular using actor analysis [480] and discussion building [410]).

[0224] The new, fundamentally different characteristic in the context of the present disclosure is that the model, in addition to being highly scalable, needs to be pruned over time since it represents an infinite data stream. Different strategies are described in the rest of this section which allow the present disclosure to prune, among other elements, the index, the item relationships (entity to instance, parent entity to child entity, etc.), and the actor and communication graph. Possible pruning strategies are explained in the section on Collection management. Additionally, the model also needs to deal with discussions [136] that are still in progress, i.e. have not reached a resolution or another form of completion.

Structure of Collection Instances

[0225] Collection instances [545] are central elements of the system's mode of operation. They are designed to fulfill the requirements of this invention, namely to provide a single data structure underlying all analytical tasks, including the storage of the complete revision history of documents and allowing the system of the present disclosure to determine the origin of all analyzed data.

[0226] As described in FIG. 6, a collection comprises a number of elements and properties, which can be categorized under collection parameters and collection artifacts.

[0227] The collection operation's definition and parameters [640] in some embodiments include:

• • [0228] Configuration [645] of the data sources [401]
  • [0229] Complete audit trail [650] of the collection, including which data has been collected and stored in the collection repository [655], which data has been collected and submitted for analysis [660], but then discarded to only retain the derived model, and which data has been ignored due to configuration (initial or overriding parameters) of the data collection component [670].
  • [0230] User-specified properties of the collection [665] including its name, optional description, associated matters or projects, collection mode (batch mode [370] or continuous mode [375]), owner, delete-by-date property.

[0231] The processing artifacts [610] include:

• • [0232] The set of all original items [122].
  • [0233] The results of extracting, processing, and post-processing those original items [122] (unless explicitly configured not to skip some of these stages on a particular data set) including indexed content [615] (both data and metadata), relationships between data elements [620], and custodial information [635].
  • [0234] Optionally, a collection instance [545] contains the full lifecycle of the original data items [122], i.e. the revisions [625] (deletion, creation, and data modification) associated with the relevant data sources [401] and the collection.

[0235] Collection instances [545] are stored in one or more secure collection repositories that are only accessible to administrators of the system, and any other users to whom an administrator has explicitly granted access.

[0236] Such a repository may contain collections of different natures. In particular, it holds both dynamic collection instances [545] and static collection instances [545]: the former corresponds to the results of ongoing collection using the data collection component in continuous mode [375], the latter to the results of a single collection operation or of a data intake from a set of physical media. It is important to provide a single point of storage for both kinds of collected data.

[0237] Collection instances [545] thus contain information about the lifecycle of the original data items. This means in particular that each collected item is flagged in the collection repository with a number of attributes including the following: which custodians or systems currently have which revisions of the item [122] (if more than one revision exists), which custodians (or systems) deleted or edited the item [122] and when these edits were made, and optionally the full item [122] revision history. (This is optional because it can increase storage requirements and the volume of information to post-process.)

[0238] Note that the persistence of the full information lifecycle allows the anomaly detection component of the system to detect anomalies [270] related to that lifecycle, including the following examples:

• • [0239] A document [162] was edited an unusually large number of times, and in an unusual number of ways.
  • [0240] A document [162] was edited by an unusual number of actors [220] relative to what is normal for this type of document [162]
  • [0241] Many custodians of a particular document [162] all deleting it within a very short time span of one another.

[0242] As described above, the collection audit trail contains information about different types of data, namely the items [122] that have been collected and stored; the items [122] that have been collected and discarded; finally, the items [122] that have been ignored.

[0243] To illustrate the point of organizing the collected data in this way, the case of ephemeral data can be considered. For example, system and application logs produce far too much content to store persistently over the long run, however the patterns that can be automatically inferred from these logs (such as periodic usage patterns) are interesting to observe since any significant aberration from such patterns would be worth showing.

[0244] More generally, one the fundamental benefits of the system is that there is no need to exhaustively store the whole data that has been analyzed, since in most cases the patterns resulting from statistical analysis of that data are sufficient to establish a behavioral baseline [260] and thus to detect anomalies [270]. In particular, this yields—if desired—very strong privacy protection guarantees because the original data items [122] collected from different sources are not necessarily persisted by the system, and also because in case they contain confidential data, some of their properties can still be leveraged by the behavioral model [200] without infringing on privacy by looking at the data.

Data Collection Scenarios

[0245] Different usage scenarios will benefit from different levels of accuracy and completeness in the collection model, which is the main rationale for the previously defined flexible model.

[0246] Very coarse-grained collections can be configured in some specific scenarios, which in turn speeds up processing of collection results. In a common application scenario, a collection session is designed to support a long-term investigation or monitoring case based on a substantial amount of previously collected data. In that case, analysis results from that prior data can be leveraged by the anomaly detection component [450], hence it is of great benefit to store the full history of successive item revisions [625] in the repository [655], including but not limited to the following reasons:

• • [0247] A complex model of what constitutes normal behavior in the organization (part of the baseline model [200] built by the system) will have been inferred from months or years of collected data, thus allowing reliable detection of anomalous behavior as soon as continuous monitoring starts on recent data.
  • [0248] Conversely, the system-derived model, including document lifecycles, allows the system to derive associations between actors [220] on the one hand, and events [100] on the other hand, based on who actually does what—and how. In one embodiment of the present disclosure, this allows the system to determine which actors [220] are typically involved in the lifecycle of any particular type of document [162], for example the quarterly filing of a corporation's financial results.
    Collection Management

[0249] In one embodiment of the present disclosure, collection management is performed in the administration console, and offers various maintenance and administration functionalities, detailed in the rest of this section.

[0250] Merging [530] collection instances [545]: A common and convenient operation is merging two independently created collection instances [545] This means that the original data sets are merged into a new collection instance [545], along with all associated processing artifacts.

[0251] Pruning [525] collection instances [545]: The size of collection artifacts from collection operations, both in batch mode [370], and in continuous mode [375], tends to increase on the long term. After running for several weeks or months they may contain extremely large volumes of extracted data and metadata, especially when complete item revision [625] histories are stored.

[0252] In that case, collection instances [545] can be manually pruned, by removing information prior to a given date, or for particular manually performed investigations and data analysis operations that are no longer relevant, or for particular custodians of the data, etc.

[0253] In addition, the system optionally performs automatic pruning [525] of the collection instances [545]. This is done by assigning a pruning mode to any given collection instance [545], which is enforced by the scoping policies component [485]. As described earlier in this disclosure, the scoping policies component [485] provides a number of scoping policy types, which when applied to collection instances include but are not limited to the following:

• • [0254] Aging policy specified by the length of the sliding window [380], so that the data collection component [400] will at any time only retain data in that collection instance [545] which is for example at most 6 months old.
  • [0255] Predicate-based policy, for example a least-relevant-data-first pruning strategy: In conjunction with a maximum volume assigned to the collection instance [545], this policy enforces the predicate that data deemed the least relevant to the matter or project at hand will be pruned to keep the volume of a collection instance [545] below that limit.

[0256] Splitting [540] collection instances [545]: Dividing collection instances [545] according to certain criteria is useful when, for example, a new investigation or monitoring case has to be processed which corresponds to a subset of the data collected for a prior case.

[0257] Complementing [520] collection instances [545]: This consists of creating a new collection instance [545] from a prior collection session [500] and running it in an incremental mode so as to collect data that has been added since the prior collection session [500], but also metadata updates, deleted data, etc.

[0258] Discarding [535] collection instances [545]: Finally, collection instances [545] can finally be deleted in a safe and verifiable manner, for example to comply with a destruction order or a retention policy. In one embodiment, all constituents of the collection instance [545] are erased.

Continuous Clustering

[0259] The continuous clustering component [412] produces clusters of items [122] or more generally events [100] from a set or a data stream on a continuous basis. A cluster is defined as a grouping of events [100] similar with respect to some observed features. The similarity measures are configurable.

Preliminary Definitions

[0260] A similarity measure is a function that ascertains similarity between events. In its simplest form, it takes two events [100] and returns true if they should be considered similar, or false if not. Similarity measures can also provide a degree of similarity between two events instead of a binary answer. A degree of similarity can be a number in a specific interval, usually from 0 to 1. This allows us to perform fuzzy clustering. Custom similarity measures can be defined to fit the different types of data that are being processed.

[0261] An embodiment of a similarity measure can be set up to receive two emails and return true if their tf-idf vectors' cosine exceeds a certain threshold, and false otherwise.

[0262] Another embodiment can take two phone logs and return true if the caller and receiver on both phone logs are the same, and false otherwise.

[0263] Another embodiment can be a set to operate on any type of event [100] that represents a communication [123] between two actors [220] and return true if two events have exactly the same set of actors [220], regardless of the type or channel [156] of the event [100]

[0264] A similarity measure definition is thus very flexible, and is not necessarily constrained by the use of heterogeneous event [100] types.

[0265] The method is fully continuous, which implies that it produces usable results (sets of clusters) and updates them as it acquires the events [100] from the underlying data stream.

[0266] The method is stable and incremental. Running it on the same set of events [100] streamed in different orders produces the same result.

[0267] The method runs on heterogeneous types of electronic events [100] as long as a similarity measure can be defined on them.

[0268] The method can be configured to prioritize the processing of certain events [100].

[0269] We assume a stream of events [100] flowing into the continuous clustering component [412]. In case the system needs to operate on a static dataset (i.e. in batch mode [370]), we can simply iterate through the static dataset and provide the events [100] to the system as a stream, hence adding no additional difficulty when processing static datasets.

Workflow

[0270] The continuous clustering is organized around a flow of events [100] through a set of components that process the events [100] as they receive them, and immediately forward the results needed by the downstream components, usually in the form of typed updates.

[0271] Raw event stream [905]: The continuous clustering component [412] connects to a provider of raw events [100] which in the default embodiment of the present disclosure is the event passing infrastructure [460] which relays data collected by the data collection component [400] from any other source of raw electronic events such as:

• • [0272] Financial market data feeds
  • [0273] Online Press data feeds
  • [0274] Others: news articles, editorials, blogs, tweets

[0275] Feature collection phase [910]: A feature is a labeled and typed value copied directly or derived from an event [100] or its underlying items. In case of a derived value, the derivation is free to use information from other events [100] but a resulting feature is directly associated to the event [100] itself. A feature can be shared among multiple events [100]. Depending on their type, sets of operations can be defined between different features or structures of features, notably, some of those operations establish equality, equivalence or order between two or more features.

[0276] A few examples of features are:

• • [0277] The set of all named entities directly extracted from an email text
  • [0278] A list of key terms from the text of an email with their tf-idf score calculated by using document frequency information from other emails
  • [0279] A duration of a phone call written on a phone log

[0280] Feature collection: The feature collection phase collects, for each observed event, the necessary information needed by the downstream components. It is a fully configurable component allowing the specification of all the subsets of the data stream, as well as the snippets of information to retain from each event. Its high level functions are described in FIG. 10:

• • [0281] 1. Filter incoming events [100] using filtering predicates [1010]
  • [0282] 2. Prioritize incoming events [100] based on configurable prioritization predicates [1020]
  • [0283] 3. Extract features necessary for the remaining of the overall computation by the downstream components. This results in a lighter process since only the necessary subset of events data is forwarded [1035]
  • [0284] 4. Extract time stamps needed by the downstream components [1040]
  • [0285] 5. Allow update of the filtering and feature extraction configurations live, while the system is still running

[0286] This example illustrates filtering and feature extraction. An embodiment of a feature collector can be set up to only pass emails and IMs to the downstream components (filtering out, for example, phone logs, key card accesses and any other non email or IM records).

[0287] This feature collector could then be set up to extract, for each email and IM, the sent date, which will be used as a time stamp, the title, the sender, receivers and other participants, and instead of passing around the whole raw content, would extract a shorter set of the named entities of the content and their modifying verbs, the feature collector would then compress the whole set of features and pass it along to the next component.

[0288] This example illustrates prioritization. An embodiment of a feature collector can be set up to automatically prioritize certain types of events [100] by attaching a priority level to every event that satisfies a prioritization predicate. Examples of such prioritization predicates can be:

• • [0289] A communication [123] occurs within a specific group of actors [225].
  • [0290] A financial order with a certain symbol and a price that surpasses a certain threshold from a high frequency trading firm is acquired
  • [0291] A key card access to a critical server room within a software company is acquired
    Every time an event is acquired and matches a specified prioritization predicate, the feature collector will prioritize its processing [1030]. If there already are prioritized events being processed, the latest prioritized event will be queued for rapid processing, along with the other prioritized events, in a position corresponding to its priority level [1080].
    Light Event Representation and Forwarding

[0292] Each event [100] not filtered out by the aforementioned feature collection phase now has an internal lightweight representation consisting of only the data needed by the downstream components.

[0293] Those events [100] are forwarded as they come to the other components guaranteeing the continuous nature of the whole method

Continuous Clustering Component

[0294] The continuous clustering component [412] creates and updates sets of clusters of events [100] continuously as it receives them (in our current setting, from the feature collector).

[0295] The clustering method is an extension of the document [162] clustering method described in U.S. Pat. No. 7,143,091, the disclosure of which is incorporated by reference herein for all purposes. At a high level, the current method augments the previous one with the following functionalities:

• • [0296] The process is now made continuous and every new event [100] is immediately clustered, and the result is immediately forwarded to downstream components.
  • [0297] The clustering component now listens to notifications from a scoping policies component [485] which notifies of which event [100] is to be discarded.
    The Continuous Aspect

[0298] In an embodiment of the continuous clustering component [412], the main operations are performed using of two main data structures:

• • [0299] A main event index or lookup table which maps every event ID with the event data and allows its retrieval in constant time
  • [0300] An inverted index which is another lookup table that associates for every feature the set of event IDs that possess that feature. The associated set of IDs is called a posting

[0301] The continuous aspect is achieved by performing the following operations every time a new event [100] is acquired:

• • [0302] 1. For every extracted feature of the newly acquired event [100], retrieve an initial set of other events [100] that share the same feature. That set is the posting that we can retrieve by using the inverted index.
  • [0303] 2. Collect and de-duplicate all the postings associated with each of its features. The events [100] whose IDs constitute the postings are called a neighborhood. They can be looked up in constant time using the event index. The remaining operations will be performed only on the neighborhood which will greatly reduce the amount of computation since the neighborhood's size is smaller than the whole set of events [100].
  • [0304] 3. Apply a similarity measure between elements of the neighborhood to reduce the set and maintain only a smaller set consisting of the events [100] that are close enough to the new event [100] with respect to the similarity measure. The small subset of the neighborhood will be referred to as a clump.
  • [0305] 4. Check if the newly computed clump can be merged with existing clusters. Merge or split if needed.
  • [0306] 5. Forward the changes to the downstream components in the form of deltas.

[0307] The above operations can also be performed in other embodiments by using data structures other than the ones listed here. In essence, every data structure that allows constant time lookup of the events [100] coupled with any data structure that allows the retrieval of a given event's [100] neighborhood, based on similarity of their features, can be used.

Handling of Scoping Policy Notifications

[0308] Upon reception of a discard notification from a scoping policies component [485], an embodiment of the clustering component [412] could do the following:

• • [0309] 1. Locate the events [100] to be discarded from its index and remove them.
  • [0310] 2. For every feature of every event [100] removed from the index, look up its posting and remove the event [100] from the list of associated events [100].
  • [0311] 3. Create and send a delta notification with the appropriate removal declarations to all the components that use clustering results.
    Live Operations

[0312] The continuous clustering component [412] also provides methods to query and manipulate its state while it is still running. In some embodiments, examples of those methods are:

• • [0313] 1. Iterate through all current clusters
  • [0314] 2. Get all events [100] of a cluster
  • [0315] 3. Remove an event [100] from all clusters
  • [0316] 4. Remove a cluster from the set of available clusters
    Incremental Updates to Clusters

[0317] Creation and changes to clusters are propagated by sending change representations we will refer to as deltas [925]

[0318] Deltas are a form of typed update [107] used in order to avoid re-sending whole clusters around when a change has been made to them. In its simplest embodiment, a delta is made of a cluster identifier, and a set of update declarations. The update declarations are either additions to the identified cluster or removals from the identified cluster. A simple example of delta can be represented as:
delta=(id0,{−event0,+event1,+event2})  (Eq-1)
This will be interpreted as: the cluster with identifier id0, has gained two events: [100] event1 and event2 and has lost the event [100] event0.

[0319] This way of only propagating update information in the form of deltas is a significant gain on performance and overall load on the computational resources. On large scale deployments, where different components reside on different machines connected via a network, this greatly reduces the amount of network traffic and the amount of update information to be processed.

[0320] Each update declaration is also interpreted as an idempotent operation, therefore, if by any forwarding or network glitch, the same delta is received twice or more by any component, it will have the same effect as if it was received only once.

[0321] Notice that this representation of deltas still allows the representation of the whole content of any duster if need be. Representing the whole duster comes down to making sure all the events contained in the cluster are stated as additions in the delta.

[0322] This abstract structure is the basis on which the downstream components which use clustering information depend.

Continuous Detection of Periodic Patterns

[0323] We describe a method that finds within a set or a stream of events [100], sequences of events [166] that are recurrent over time and occur at roughly periodic intervals. The method yields the actual sequences of events [166] that correspond to the realization of those periodic patterns [166], and are called periodic sequences [132]. It does this without any prior indication of the periodicity (for example daily, weekly, yearly, or every six hours and twenty minutes) or any prior indication of what the possible recurring events [101] themselves might be.

Preliminary Definitions

[0324] A unique identifier is synthesized for every event [100], calculated as described in U.S. Pat. No. 7,143,091. Examples of events [100] considered by the periodic patterns detection component [405] in one embodiment of the present disclosure are:

• • [0325] An email with its associated sent date
  • [0326] An IM session with its associated start date
  • [0327] A phone log with its associated call time
  • [0328] An electronic meeting invitation note with the associated meeting date
  • [0329] An electronic meeting invitation note with its associated sent time (as opposed to the time when the actual meeting is supposed to take place)
  • [0330] A Financial market order and its associated time stamp
  • [0331] A Financial stock tick with its associated time stamp
  • [0332] A key card usage record with its associated time stamp
  • [0333] A document with its associated creation, update or delete time stamps
  • [0334] A record of actor [220] A communicating with actor [220] B in private (regardless of the communication channel [156] used) with the communication's [123] date and time

[0335] Notice the heterogeneous types of items or combination thereof that can be considered events [100] for the periodic patterns detection component [405].

[0336] Each association between a type of event [100] and the right type of time stamps is either directly inferred when there is no ambiguity, or can be configured. Some events [100] also have a duration.

[0337] It should be noted that the definition of an event [100] does not require a one-to-one relationship with an electronic item. A simple class of events can be defined as a dialogue of a certain maximum duration, another class of events [100] can consist of all the electronic records constituting a financial transaction. The periodic patterns detection component [405] therefore allows any logical, identifiable and detectable bundle or derivative of electronic behavior, to be treated as an event [100].

[0338] A periodic pattern [126] is an event [100] or a group of events that is recurrent over time and occurs at roughly periodic intervals. Examples of such patterns [126] are:

• • [0339] A weekly meeting
  • [0340] A yearly employee review process

[0341] A periodic sequence [132] is an actual sequence of events that matches a periodic pattern [126].

[0342] This section describes a method that finds within a set or a stream of events [100], the periodic patterns [126] and yields the actual sequences of events [100] that correspond to the realization of the periodic patterns [126]. It does this without any prior indication of the periodicity or possible periodic events [100] themselves.

[0343] The method even finds the periodic patterns [126] that have changing frequency components over time.

[0344] The method is fully continuous, updating relevant periodic patterns [126] as new events [100] enter the system.

[0345] The method is robust against incomplete or locally irregular data and localized changes of frequencies of the events [100].

[0346] To illustrate this previous point, let us imagine a particular sequence of meeting invitations in a company, scheduled every week, on Monday, for a year. We continuously receive all data as they become available, starting from the beginning of the year. All meeting-related data is buried among the other types of data and we are not told in advance that this particular sequence of meetings will be a candidate for periodicity. If the sequence is ideal and always occurs every Monday, It will result in our method identifying a periodic pattern [126] of period one week that covers a year. Now, let us imagine that there is still a weekly company meeting but sometimes, maybe due to schedule conflicts, it is held another day of the week instead of Mondays. Each two successive meetings are not necessarily separated by exactly one week anymore. In addition to those slight irregularities, it often happens that such real-life events are skipped for a considerable period of time, maybe the attendants of the meeting have gone on vacation, perhaps for a few months. To finish, there can also be a different type of change: a frequency change when the previously weekly meeting turns into a daily meeting for a few months, maybe due to some tight deadline to meet.

[0347] This illustration presents some of the challenges solved by the present disclosure in most datasets, because regardless of those irregularities, it still identifies the relevant periodic patterns [126]. This method is designed from the ground up to take them into account and still come up with a comprehensive result.

[0348] The method will return, for this illustration:

• • [0349] A periodic pattern [126] consisting of two distinct frequencies, a weekly frequency followed by a daily frequency
  • [0350] A clear indication of the small disturbances (when the meetings were not held on Mondays but later in the week) and gaps (when everyone was in vacation) within the periodic patterns [126]

[0351] It should be noted that those results will be yielded and updated as soon as the data is processed and we do not need to wait until the end of the year to produce the first results: The results are available on a continuous basis.

[0352] The resulting set of periodic patterns [126] can also be queried by both its structural information: What periodic sequences share the same gap? What periodic sequences have a gap of size X during time period Y?

[0353] Or its semantic information: Which periodic sequences [132] correspond to meetings? Which ones correspond to professional activities? Which ones have changes that coincide with external events [170] ?

[0354] This method can also recombine previously discovered periodic patterns [126] into higher order periodic patterns [126] that provide a richer picture of the regularities or irregularities of the data set or data stream.

[0355] The present disclosure assumes a stream of events [100] flowing into the periodic patterns detection component [405] In case the system needs to operate on a static dataset (i.e. in batch mode [370]), it simply iterates through the static dataset and provide the events [100] to the periodic patterns detection component [405], hence adding no additional difficulty when processing static datasets.

Workflow

[0356] The periodic patterns detection component [405] operates on a set of clusters of events [100] forwarded by the continuous clustering component [412] described in this disclosure. It receives a set of deltas [See section below for a definition of deltas] and updates the periodic patterns [126] that have the elements of the dusters as their underlying events [100].

[0357] In order to continuously build the dusters of events [100] and forward them to the periodic patterns detection component [405], the following steps are performed by the clustering component [412] described earlier in this disclosure:

• • [0358] Raw event streams listener
  • [0359] Feature collection phase
  • [0360] Light event representation and forwarding
  • [0361] Continuous clustering component
  • [0362] Incremental updates to clusters
    The following describes the periodic pattern [126] detection steps performed once the deltas are received from the clustering component [412].
    Periodic Patterns Detection

[0363] Detection: The periodic patterns detection component [405] performs the following actions:

• • [0364] 1. Continuously receives a stream of deltas,
  • [0365] 2. Searches for frequency components within each cluster,
  • [0366] 3. Attempts to combine the periodic patterns found within different dusters to form higher order periodic patterns if possible.

[0367] An embodiment of a method to find the periodic patterns [126] is outlined below.

Binned Sequence

[0368] Upon reception of a delta, a process is spun off by the periodic patterns detection component [405] and locally reloads all necessary information for continuing the analysis of the corresponding clusters.

[0369] The search for frequency components happens at different fixed time resolutions. The available time resolutions can, for example, range from a very fine grained resolution such as second or below, to coarser grained resolutions such as hour, day, week, month, etc. The analysis starts with the smallest resolution.

[0370] For each resolution, the list of events [100] is sorted and binned according to the resolution. The resulting binned sequence can be treated as an array with each of its elements corresponding to the content of an individual time bin. Each element of the binned sequence can therefore represent:

• • [0371] A single event [100] within a time bin
  • [0372] A list of several events [100] that ended up together in the same time bin
  • [0373] An empty time bin representing a non-event, which can be interpreted as a time bin where nothing relevant was observed.

[0374] Once a binned sequence has been built, the system proceeds to reading it into a sparse transition matrix.

[0375] From here the system only operates within a specific time resolution at a time, meaning the time axis is slotted into time bins of constant width. This helps reduce upfront a set of small variances and errors in time interval measurement. This also implies that several events [100] can end up in the same time bin. In the rest of this section, the term time bin will sometimes be used as a unit of measure or time just like a natural unit would be used such as day or month.

Sparse Transition Matrix

[0376] The sparse transition matrix T is a matrix that has event classes on its rows and integers on its columns. An event class is defined here as a set of events [100] that are similar. An example of event class is a set of all instances of a particular meeting notification email.

[0377] An entry T[i,j] of the matrix is a structure a containing an integer indicating the number of times instances of events [100] of the class denoted by the index i follow each other separated by a distance of j time bins. This number contained in the entry will be referred to as a repetition count. If the integer contained in the structure s of the entry T[e,4] is 10, that implies that events [100] of class e have been recorded to succeed each other every 4 time bins 10 times. The structure s also records the intervals where those successions occur in order to allow the location of the time intervals when those transitions occur. It also records, for each event class encountered in a time bin, the number of instances of that class observed.

Updating the Sparse Transition Matrix

[0378] Let us illustrate the creation and update of a sparse transition matrix with a small example:

[0379] Let us consider a binned sequence containing two classes of events. The class e={e1, e2, e3, e4, e5, e6, e7, e8, . . . } and the class f={f1, f2, f3, . . . }

(Portion 1) e1|*|e2|*|e3|*|e4|*|*|*|e5 f1|*|e6|f2|*e7|*|e8 f3

[0380] Reading this binned sequence will produce or update a sparse transition matrix with the following repetition counts (we omit detailing the whole structure of the entries).

T[e,2]=6 repetitions, at intervals [1, 7] [11, 17]

T[e,4]=1 repetition, at interval [7, 11]

T[f,3]=2 repetition, at interval [11, 17]

[0381] The creation and update of a sparse transition matrix is a linear operation with respect to the size of the binned sequence. Using two pointers along the binned sequence, one could record all transitions for each event class in one pass.

Detecting Frequency Components

[0382] From this matrix we only consider entries that have a minimum number of repetitions, and satisfy a minimum set of contiguous disjoint occurrences (derived from looking at the intervals). The minimum number of repetitions can be adjusted for each time resolution in the above example, if our minimum repetition is 2, then we only consider entries T[e,2] and T[f,3].

[0383] We can automatically infer from these entries the frequency component (e,*) which means an event [100] of class e occurs every 2 time bins as well as the frequency component (f,*,*) meaning an event [100] of class f occurs every 3 time bins. (The symbol * denotes a contextual non-event, or more generally a time bin when observations do not participate in the periodic pattern [126] considered).

[0384] It should be noted that the frequency components will still be detected even if noise—in the form of a set of unrelated events [100] scattered across the binned sequence—is added to the binned sequence. This adds to the robustness of the method.

[0385] Furthermore, because we record the number of instances of every event class per time bin, we are able to produce periodic patterns with accurate amplitude information. As a simple example, if we augment the sequence represented by (Portion 1) in order to have two instances of the event class e at each occurrence:

(Portion 1 augmented) e1 e101|*|e2 e102|*|e3 e103|*|e4 e104|*|*|*|e5 e105 f1|*|e6 e106|f2|e7 e107|*|e8 e108 f3

We would be able to detect the corresponding, more informative frequency component (2e,*) indicating that two occurrences of events of class e occur every 2 time bins.

Recombination and Higher-Order Periodic Patterns

[0386] Once the basic frequency components and periodic patterns [126] are detected a new step is taken to recombine them into higher-order periodic patterns [126].

[0387] A higher-order periodic pattern is any complex periodic pattern obtained via recombination of previously detected standalone periodic patterns.

[0388] Previously built periodic patterns [126] can be automatically recombined if they satisfy two types of conditions:

• • [0389] Semantic conditions
  • [0390] Structural conditions
    Semantic Conditions

[0391] A semantic condition is any condition that triggers a recombination attempt while not being based on the pure periodic structure of the periodic patterns [126] to be recombined. Such conditions include, for example, an attempt to recombine two periodic patterns [126] because their underlying event classes have been declared similar and therefore merged into the same cluster by an upstream component. Semantic conditions, even though they serve as triggers, are sometimes not sufficient to mandate a recombination. Often, the recombination needs to be validated by satisfying further structural conditions.

Structural Conditions

[0392] A structural condition is any condition based solely on the structure of the periodic pattern [126]. Structural conditions are built around information about periodicity, time span, intervals of occurrence, disturbances or gaps. Everything else not related to the structure of the periodic pattern [126] is labeled as a semantic condition.

[0393] To illustrate an embodiment of a recombination step, let us consider the following binned sequence:

(Recombination) e1|f1|e2|*|e3|f2|e4|*|e5|f2|e6|e7|f2|e8|*|

[0394] This binned sequence yields at first two distinct periodic patterns [126]: A first one with a frequency component (e,*) which indicates that an event of class e occurs every 2 time bins and a second one (f,*,*,*) which indicates that an event of class f occurs every 4 time bins.

[0395] An automatic recombination of these two periodic patterns [126] will result in a richer higher order periodic pattern [126] (e,f,e,*) indicating an event [100] of class a followed by an event [100] of class f followed again by an event [100] of class e every 4 time bins.

[0396] Structural conditions, in this example where both original periodic patterns [126] are flat, can be stated as follows:

• • [0397] The length of one of the periodic patterns [126] must be a multiple of the other, with a bounded multiplicative factor selected based on the time resolution at which the binned sequence has been built.
  • [0398] The two periodic sequences [132] must satisfy a set of structural invariants, one example of which is a notion of bounded phase difference variance meaning that the oriented difference of positions between pivotal events [100] of each occurrence of the periodic patterns [126] is constant or bounded to a small variation with respect to the time resolution at which the binned sequence has been built. A simple example of a pivotal event is the one that starts every occurrence or repetition of a periodic pattern.

[0399] Those two examples are sufficient for flat periodic patterns [126] such as the ones illustrated here to be automatically recombined. The periodic patterns [126] (e,*) and (f,*,*,*) have respective period or length of 2 and 4 which are multiples. Furthermore, we can observe that every fi is always preceded and followed by a pair ei, ej. This satisfies the bounded phase difference variance condition, giving us enough confidence to recombine the two periodic patterns [126].

[0400] It should be noted that because we store the intervals and positions where the actual events [100] take place in our sparse transition matrix, the above structural conditions are tested in less than linear time (with respect to the binned sequence's length). These conditions can therefore be reevaluated as needed when the underlying event [100] sets are updated to ascertain whether or not the periodic patterns [126] should be kept combined or not.

[0401] Structural conditions are not limited to the one illustrated in the above example. In addition to hounded phase difference variance, other conditions such as alignments of disturbances or gaps, where the time intervals representing the disturbances or gaps of a set of periodic pattern line up with a very small variation, can also be used.

[0402] In one embodiment of the present disclosure, recombinations can also be made offline by using the querying mechanism on periodic patterns [126] stored by the system in a periodic patterns [126] database.

Continuous Caching

[0403] Every time the system finishes wrapping up frequency components into periodic patterns [126], a set of attributes is cached until the underlying clusters that contain the events [100] are updated again, requiring an update of the associated periodic patterns [126]. The cached attributes contain:

• • [0404] The current state of the different sparse transition matrices and their associated time resolutions, with flags on the entries allowing changes to be versioned. This allows operations such as: “provide from a sparse transition matrix only the entries modified after version X”
  • [0405] The list of IDs of the underlying clusters
  • [0406] A set of information kept around to avoid rebuilding the binned sequences ail over again every time the underlying clusters change. This information allows the frequency component detection to be carried only on the new binned sequences built from the deltas associated with a cluster change. A summary of that information includes:
    • [0407] saving the overall length of the binned sequence,
    • [0408] saving the latest position of each last instance of every class of event,
    • [0409] a saving all events [100] in the most recent time bin for every time resolution.

[0410] These attributes are indexed in a constant-access memory cache backed up by a persistent store by the cluster IDs and the periodic pattern IDs allowing a fast retrieval when clusters or periodic patterns need to be updated.

Handling of Scoping Policy Notifications

[0411] Upon reception of a notification from a scoping policies component [485] declaring for example that an event [100] has been aged out, an embodiment of the periodic patterns detection component [405] could remove the corresponding event [100] from its caches and persistent stores and keep only its identifier and time stamp within a compressed representation of the periodic patterns [126] the event [100] appears in. This is another way to save the amount of space used for caching results from continuous periodic pattern detection.

Parallelization and Distributability

[0412] Because all the events [100] are only read and never modified during the usually very short frequency detection phase, which in addition operates on a partitioned subset of the available clusters, the system ends up with a high number of very localized and short processes. Every frequency detection and periodic pattern [126] update process is therefore spun off within its own parallel process for every subset. This factor allows the system to scale the computation through the parallelization and distribution of the frequency detection processes on the whole data stream. Depending on the concurrency mechanism available, an independent short lived process can be dedicated to any local set of classes of events for each update.

Incremental Aspect of the Process

[0413] In addition to the operations described above, every sparse matrix is continuously updatable and the frequency component detection happens incrementally.

[0414] This also means that any binned sequence need not be passed to the system in its entirety in one pass. Being able to build the whole binned sequence in one shot is often impossible anyway because of the continuous nature of the system: the periodic patterns detection component [405] processes events [100] as it receives them.

[0415] Therefore, small sections of the binned sequence are built as the underlying events [100] are acquired from the continuous clustering component [412] using for example deltas (see FIG. 11):

• • [0416] In case the stream of events [100] needed to build a binned sequence arrives in increasing order with respect to their timestamps, the previously processed portion of the binned sequence is not needed since every newly arriving event falls at the end of the previously built binned sequence. A continuation of the binned sequence can be built only from the newly acquired events and used to update the sparse transition matrix [1115]. This operation is therefore akin to an “append”.
  • [0417] In case the stream of events [100] arrives in no particular order, the newly acquired events are first sorted in increasing order. If the earliest event [100] from the newly acquired events [100] happened after the last time bin of the previous binned sequence, the previous portion of the binned sequence does not have to be reloaded or rebuilt [1140]. Otherwise, a sub-portion of the previously processed portion of the binned sequence is reloaded up to the position corresponding to the earliest of the newly acquired events [100].

[0418] To continue with the above illustration, let us assume that new events [100] are added to the binned sequence (Portion 1) in the form of (Portion 2) below (We assume that we are using time bins of the same length). This will happen very often as deltas are received from the clustering component [412]:

(Portion 2) e9|*|e10|*|e11|*|e12

[0419] If the earliest of the newly acquired events [100], represented by e9, had a timestamp such that, relative to the previous portion (Portion 1) of the binned sequence, e9 falls after the time bin that contains e8 and f3, we can carry on without reloading any previous portion of the binned sequence and updating the sparse transition matrix will be the same as if we have had the whole binned sequence in one pass.

[0420] However, if e9 fell within the previous portion (Portion 1), say at position 9, which was previously occupied by a non-event, we would have to reload only the sub-portion of the previous array up to, and including position 9, meaning:

(Reloaded sub-portion) . . . *|*|e5 f1|*|e6|f2|e7|*|e8 f3 . . . .

[0421] And we would insert the newly acquired events [100] to obtain

(Reloaded sub-portion updated) . . . e9|*|e5 f1 e10|*|e6 e11|f2|e7 e12|*|e8 f3 . . . .

[0422] Notice that in this last case the number of occurrences in this time interval as well as a previous gap at position 9 will have to be updated.

[0423] Only the entry T[e,2] will have changed triggering only an update of the frequency component (e,*) and its associated intervals of occurrence and positions information.

[0424] This type of incrementality can be achieved using a dirty flag for each matrix and setting it to true every time an update is made to the matrix, along with the set of two indices pointing to the modified entries. After a matrix is updated from a new binned sequence, process only the entries that have been marked as updated and reset the dirty flag to false.

[0425] The possibility to locally carry on the computation and still produce meaningful updates without having to reload or rebuild previously used portions of the binned sequence is yet another win in terms of computational performance since we avoid, when the events being acquired are mostly sorted, many slow computer input/output operations and/or network traffic that would occur with high demand for previously computed data such as previous portions of binned sequences or unchanged entries in sparse transition matrices.

Representations

[0426] The data structure representing a periodic pattern [126] has, but is not limited to, the following attributes:

• • [0427] 1. A unique periodic pattern ID
  • [0428] 2. A label which is a short, readable text typically used in displays to label the periodic pattern [126]. Labels are modifiable by external labeling programs even after a periodic pattern [126] has been created.
  • [0429] 3. A set of cluster IDs representing the event [100] clusters from which the pattern [126] has been detected
  • [0430] 4. A list of the frequency components found in the periodic pattern [126] and the time resolutions at which they were detected
  • [0431] 5. For each frequency component, a list of segments and disturbances.
    • [0432] a. A segment is an interval delimiting contiguous disjoint matches of a pattern [126] in a time binned sequence. It is therefore dependent on a specified time resolution. It simply corresponds to the intervals where a pattern [126] occurs when looking at a binned sequence derived from sorting and binning the events [100].
    • [0433] b. A disturbance is an interval which delimits spans of time where a pattern [126] did not occur even though it should have when inferring from it frequency components.
  • [0434] 6. The list of all event IDs constituting the periodic sequence [132]

[0435] To these attributes can optionally be added any number of other attributes such as the different actors [220] linked to every periodic pattern [126].

[0436] Segments and disturbances are also continuously indexed to allow querying based on time intervals. An embodiment of the data structure used to index segments and disturbances is a slightly modified version of an interval tree as described in [Cormen 2009] in which an extra annotation is added to every interval node to point to the corresponding periodic pattern ID.

[0437] Periodic patterns [126] are not forwarded to other components or databases in their entirety. Because the present disclosure supports operating in a continuous mode where it must produce results as it receives events [100] and update results accordingly, creations and updates of periodic patterns [126] are forwarded in the form of periodic pattern mutations.

[0438] A periodic pattern mutation is a form of typed update [107] consisting of enough information needed by any component receiving it to construct a new periodic pattern [126] or update an existing one. Its attributes include but are not limited to:

• • [0439] 1. A unique periodic pattern ID
  • [0440] 2. A set of cluster IDS representing the event [100] clusters from which the periodic pattern [126] has been detected
  • [0441] 3. A list of newly added events [100]
  • [0442] 4. A list of the frequency components to add to the periodic pattern [126] and the time resolutions at which they were detected
  • [0443] 5. A list of frequency components to remove from the periodic pattern [126] and the time resolutions at which they where detected
  • [0444] 6. For each frequency component, a list of segments and disturbances to add to the existing ones using interval merging operations (or create if there are no existing ones)
  • [0445] 7. For each frequency component, a list of segments and disturbances to remove from the existing ones using interval subtraction operations
  • [0446] 8. An optional new label.

[0447] An example of a consumer of such periodic pattern mutations is the periodic patterns database which upon reception of each periodic pattern mutation updates or creates the corresponding periodic pattern [126] and saves it in the database for future use.

Incremental Production and Updates to Periodic Patterns

[0448] This process performs the following actions upon reception of a periodic pattern mutation data structure:

• • [0449] 1. For a newly found periodic pattern and its associated periodic sequence, store into database
  • [0450] 2. For a continuous update to an existing periodic pattern, update stored information within the database.
    Periodic Patterns Database

[0451] The periodic patterns database [940] is the main repository for all periodic sequences [132] and their associated periodic patterns [126]. It is continuously updated.

[0452] It is internally designed to allow:

• • [0453] 1. Real-time queries and structural analysis based on structural information such as periodic sequence [132] length, periods, gaps, etc
  • [0454] 2. Real-time queries and semantic analysis based on semantic information
    In the default embodiment, structural analysis queries take the following forms:
  • [0455] 1. Given a time interval, find all periodic sequences [132] that have an overlap with that interval.
  • [0456] 2. Given a periodic sequence [132], find all periodic sequences [132] that have an overlap with that periodic sequence [132]. The results can be sorted by decreasing overlap.
  • [0457] 3. Bring up all periodic sequence [132] clusters (i.e. groups of most similar periodic sequences [132] with respect to the time intervals during which they occur or not)
    The database [940] also allows ad hoc combinations of similar periodic sequences [132] to form new ones.
    Continuous Categorization

[0458] The present disclosure comprises a continuous categorization component [420], which is leveraged in multiple ways, including but not limited to the following use cases:

• • [0459] Whenever categorization is used and its results are continuously evaluated and updated: the categorization results are taken into account, in addition to various features built and continuously updated in the data model. This allows the anomaly detection component [450] to produce categorization anomalies as appropriate.
  • [0460] Whenever an alert [305] is raised or any other type of preventive or mitigation action is taken, categories that have been automatically associated to the corresponding data are reflected in the alert [305]. Thus the alerts [305] themselves, and similarly all types of post-analysis actions, are systematically categorized.
  • [0461] Finally, a user of the system can also perform online queries on any processed data using the different categories available. Continuous categorization here guarantees that up-to-date results are returned.

[0462] The categorization model [1470] is initially built during system setup, and is later maintained throughout the system operation. Its primary purpose is to evaluate the results produced by the categorization components [1400] and to ensure their consistency and quality. The structure of the categorization model [1460] is summarized in FIG. 16, which shows a particular snapshot of the model. The complete history of the categorization model [1460] is actually persisted, along with the system or user decisions that resulted in each new model version.

[0463] This model is initially built on the results of knowledge engineering (which includes defining and tuning ontology classifiers [1410] and other categorization components [1400]) and on the reference data provided to the system, where reference data includes but is not limited to the following constituents:

• • [0464] Monitoring rules such as compliance rules [865] used by the anomaly detection component [450] to detect specific types of anomalies [270]
  • [0465] Organizational structure information including an organizational chart if one was provided to the system, information on actors [220] and groups [225], and a list and definition of workflow processes [128].

[0466] After the initial construction of the categorization model [1470] and once the system has been continuously running for a while, the relevance model stores elements of information including but not limited to:

• • [0467] History of all successive versions of the knowledge base (ontology classifiers [150], custom queries [1530], etc.)
  • [0468] History of all successive versions of the categorization components [1670]
  • [0469] History of all successive versions of the classification rules [1680]
  • [0470] History of all categorization results [1590], including detected profile changes [1465] as described later in this section.

[0471] FIG. 14 shows the preferred embodiment of the categorization process, which can be broken down into three main phases: initialization, adaptation, and iteration.

Initialization Phase:

• • [0472] Knowledge engineering [1405] is composed of several sub-steps and consists in building, maintaining, and enhancing a set of categorization components [1420] available to the system.
  • [0473] The set of categorization components [1420] initially built or modified during maintenance of the process are manually validated by a series of sanity checks [1410].

[0474] An analyst configures the process by defining the scope of the categorization process, its performance targets, and all parameters determining the exact process behavior [1415].

Adaptation Phase:

• • [0475] The user reviews data sampled by the system [1425].
  • [0476] A “best fit” of categorization components [1420] that generalize sampling decisions to newly collected data in a near-optimal manner, as described for example in U.S. Provisional Patent Application No. 61/280,791, the disclosure of which is incorporated by reference herein for all purposes [1430].
  • [0477] The user then performs a series of sanity checks on the classification rules that have been modified during an execution of this phase [1440]
    Iteration Phase:
  • [0478] Data is collected as described in another section of this disclosure [1445].
  • [0479] Data is processed [1450], which includes data and metadata extraction and item tagging among other stages.
  • [0480] The system then automatically applies the classification rules [1400] computed previously to all content extracted from the data [1455].
  • [0481] This produces new categorization results [1460], which are then used to update the categorization model [1470].
  • [0482] In parallel, the distribution of categorized data is monitored, which prevents deterioration of the process performance by detecting profile changes [1465] and re-running the adaptation phase when appropriate
    Categorization Components

[0483] The set of categorization components [1420] available to the system comprises components of different types, as shown in FIG. 14. This enumeration is not exhaustive and can be extended to include any method defining subsets of the data set.

[0484] An initial set of components [1420] is built at the beginning of the continuous categorization process. These components [1420] are continuously maintained, meaning that some new components [1420] can be added and existing components [1420] can be deleted or modified. This happens either when a significant model change has been automatically detected in the data, or when an administrator needs to implement a new policy (whether internal or external to the organization).

[0485] The following describes multiple methods provided by the system to assess quality of categorization results and automatically adapt in response to deteriorating quality or unexpected results.

Classification Rules Validation

[0486] The system automatically evaluates the classification rules [1400] produced at the query fitting stage [1430] with respect to performance goals defined in the categorization scope. This comprises many variants of validity checks, for example by computing performance targets either on the basis of each classification rule [1400] retained by the algorithm, or on the basis of the final categorization decisions resulting from applying the whole set of rules [1400] Different validity checks are also available when some categorization codes include unknown values or values corresponding to a high level of uncertainty.

[0487] Further statistical validation can optionally be performed to assess the generalization power of the classification rules [1400]: for example, verifying the self-similarity of the categorization results [1460] (by expanding categorization beyond the manual sample) ensures that there is no major over-fitting with respect to the manual sample [1425].

[0488] In addition to these automatic validation mechanisms, a manual validation stage [1440] needs to be performed. This verification is a sanity check, mainly consisting of controlling that the associations established between categorization rules [1400] and category codes make sense and that there are no obvious indications of over-fitting, i.e. of excessive adaptation of the rules [1400] to the data sample that clearly would not generalize to the data in its entirety. Also, manual validation of the classification rules [1400] is made easier by having the rules contain as much human-readable information as possible, for example, ontology classifiers [150] have an expressive name and a textual description.

Categorization Results Evaluation

[0489] Following the assignment of category codes to the content of a batch or of data collected in real-time, the continuous categorization component [420] automatically evaluates the categorization results against the categorized data. This evaluation is done in addition to the manual and automatic validation steps already performed on the classification rules themselves. Furthermore, the user [455] implicitly evaluates the global categorization results by reading the reports generated by the process.

[0490] A variety of techniques are used in this assessment: a basic technique consists of comparing results from a manual sample with results generalized over the whole data set.

Profile Change Detection

[0491] Profile change detection is a key step in assessing and guaranteeing quality of the output produced by the continuous categorization component [420]. When the data profile, i.e. the statistical distribution of the data analyzed by the system in a continuous manner, changes over time, the classification rules and the categorization components [1420] themselves risk becoming obsolete and decrease both in recall and in accuracy, thus deteriorating the quality of data processing and hence the overall quality of anomaly detection. Therefore in such cases an analyst needs to be notified that either manual re-sampling or component [1420] updating is necessary.

[0492] There are different types of profile changes. Some profile changes can be automatically detected by the model: for example when a connector allows data collection from HR applications, the appearance of a large volume of data associated to a new employee can be related by the categorization process to that employee's information recorded in the HR system. This case of profile change usually does not reveal any flaw in the categorization components [1420] and only requires sampling data for the new actor [220].

[0493] In most cases however, profile changes cannot be directly explained and a manual decision is necessary: such changes may indicate changes in the categorization results [1460], changes in the set of topics detected, changes in the actors [220] and groups [225] involved with the data, etc. In order to automatically detect as many changes as possible, the system relies on the categorization model [1470] described previously.

[0494] The different types of categorization model [1470] refinements following a profile change include, but are not limited to, the following:

• • [0495] 1. Patching existing categorization components [1420]
  • [0496] 2. Creation of a new component [1420]
  • [0497] 3. Suppression of an obsolete or invalid component [1420]
  • [0498] 4. Combination or re-organization of existing components [1420]

[0499] A variety of profile changes can be monitored, depending on the particular usage scenario. In the default embodiment of this disclosure, a default set of data profile changes are monitored, including but not limited to the following list (which also suggests examples of typical cases where such a change occurs):

• • [0500] The hit ratio of a categorization component [1420] decreases significantly: Insufficient coverage by a component [1420] may indicate an incompletely defined ontology [148].
  • [0501] The hit ratio of a categorization component [1420] increases significantly: The component [1420] may overlap with unrelated content recently that has appeared in the data, such as a commonly occurring topic [144].
  • [0502] Change in topic map has been detected: New topics [144] are discovered, or previously important topics [144] are no longer present in the data.
  • [0503] Mismatch between ontology-based classification and unsupervised clustering: Several items [122] with highly similar content are categorized differently by the ontology [148]. This may be due to over-fitting of the ontology classifiers [150].
  • [0504] A significant volume of data is categorized as relevant but not attributed to any actor [220]: Some new actors [220] have appeared that are involved with relevant data, or it may indicate any other kind of important change in actor [220] interactions and social status.
  • [0505] The volume of data categorized as relevant for an actor [220] decreases significantly. This may reveal insufficient accuracy of a categorization component [1420] in the context of this actor's [220] data or it may indicate any other kind of important change in actor interactions and social network relationships.
  • [0506] Instances of a formal or ad-hoc workflow disappear this happens when business processes are formally updated or when work habits simply evolve over time.

[0507] In the absence of such changes, re-sampling is still performed at a regular frequency, the interval between such re-samplings being optionally defined at the process configuration stage.

[0508] It should be noted that each such profile change depends on a number of criteria. In the default embodiment, these criteria are available as detection thresholds including but not limited to the following.

• • [0509] Absolute thresholds: for example, the minimum ratio of relevant data that should be attributed to an actor [220] (given that there will necessarily always be some content that cannot be assigned, such as unsolicited data or personal communications [123].
  • [0510] Relative thresholds: for example, the relative variation in the hit ratio of a categorization component [1420] that should be flagged as a profile change.
  • [0511] Other metrics: for example, detection of a mismatch between the results of ontology classifiers [150] and those of an unsupervised clustering method [1510] depends on a clustering similarity metric. The most appropriate metric depends on the exact typology of the categorized data; however general scale-invariant metrics can also be used such as the variation of information distance.
    Continuous Discussion Building

[0512] The previously described method in U.S. Pat. No. 7,143,091, the disclosure of which is incorporated by reference herein for all purposes, works by building a sub-graph in a regular graph (that is, not a hypergraph [114]), and then finding within it skeletons which conform to discussions [136].

[0513] We now extend the prior invention with the use of a hypergraph [114] data structure, which greatly increases expressivity over a conventional graph, as edges [115.20] can now be incident on any number of vertices [115.21] or other edges [115.20]. Using this model, a much greater variety of structures can be represented in the hypergraph [114] in a more efficient and easier to use fashion. Many embodiments will also use the hypergraph [114] to cache partial results in computations where doing so has advantages over re-deriving them (though there are many cases where rederivation can be superior, there are tradeoffs in both directions). The hypergraph [114] system defined here is designed to be used in an environment where elements are continuously added to the hypergraph [114] and may trigger incremental computations to update derived structures in the hypergraph [114], of which discussions [136] are an important example.

[0514] As discussed in more detail below, most embodiments rebuild the sections of the hypergraph [114] in a localized area around where a new evidence [108] is detected. The closure and traversal hypergraph operations [115.26] are particularly good for this. Most embodiments will opt to accumulate some number of changes to be triggered in batches at a later time. A set of hypergraph operations [115.26] are defined which facilitate different strategies for defining the neighborhood of an element.

[0515] In most embodiments including the default one, the continuous embodiment of discussion [136] building is based on accumulation of relationships between actors [220], events [100] and items [122] stored in a hypergraph [114] data structure. These relationships and the subsequent structures built on them are all considered evidences [108] to be used in the discussion [136] building procedure. The hypergraph [114] system is a generic framework supporting incremental hypergraph [114] computations, described here for the purpose of building discussions [136] on a continuous basis. In the default embodiment the hypergraph [114] is represented as a set of OSF [110] values serialized and stored in records [115.24] in a hypergraph store [115.22] which in most embodiments consists of one or more large archives. Rather than using a keyed database, in these embodiments OSF [110] records [115.24] are referred to via their address in the hypergraph store [115.22]. In the default embodiment the hypergraph store [115.22] is tiled into segments [115.23], and addresses have the form of a segment [115.23] and an offset within that segment [115.23]. A segment table [115.25] is stored which contains state information over all segments [115.23] allocated at any time. If a segment [115.23] is unused it can be reallocated as an active segment [115.23], but the entries for prior uses of the segment [115.23] will be retained in the segment table [115.25]. New OSF [110] records [115.24] are added to the end of the newest segment [115.23] as they come in. Records [115.24] are only retained in the hypergraph [114] for a certain period of time, old records [115.24] and in some embodiments shadowed records [115.24] that are no longer accessible are removed from the hypergraph store [115.22] via the garbage collection scheme. The other main feature is that OSF [110] records [115.24] are immutable. When updating an existing record, a new version of a record to be updated is appended to the hypergraph store [115.22]. In the case where an updated record is used in the computation of derived records [115.24] or is otherwise referred to by existing records [115.24], new versions of those records [115.24] must be appended in order to make it visible. In practice this fits very well with the continuous computation model, as new evidence [108] added to the hypergraph [114] will trigger revisiting existing discussions [136] or other structures for which it is relevant. Thus the relevant entities that may have to be updated will be anyway visited as part of the incremental algorithm.

[0516] In the default embodiment garbage collection is effected by simply removing segments [115.23] when they pass an age threshold. In this embodiment, items [122] that have become too aged are no longer directly used in the computation of new discussions [136] or other structures. It is important to note that different embodiments will implement the notion of “too old” in different manners depending on their primary use cases. While some embodiments may simply use a calendar threshold, others will operate on the basis of obsolescence. For example, data relating to an actor [220] who is no longer on the scene may be deemed obsolete faster than the same sorts of data for an actor [220] who remains in the universe. Likewise data relating to routine occurrences of something is less valuable than data which involves anomalous behavior [270], and therefore will be slower to obsolesce. One reason for doing this is to be able to make all computations responsive to recent trends in the data and not be completely overwhelmed by historical patterns. However, longer term trends are important as well, even if they have a smaller effect in most computations. Therefore a special set of segments [115.23] is set aside for storing models of these long term trends, patterns and other statistics. These segments [115.23] are handled differently; in most embodiments they don't store OSF [110] records [115.24] and are mutable and periodically updated with information in old segments [115.23] being removed from the hypergraph store [115.22] The segment table [115.25] entries for collected segments [115.23] are not removed but rather modified to indicate that any references to records [115.24] previously stored in those segments [115.23] will be handled specialty. In most embodiments, the process attempting to access those records [115.24] will be notified that they are no longer active and will be directed to the relevant segment(s) [115.23] containing trend information.

[0517] For purposes of scalability the system focuses on locality in hypergraph operations [115.26], that is, operations based on looking at elements in the hypergraph [114] within a neighborhood of a triggering element or set of triggering elements. In the embodiment described here, additional subsystems are used for storing the original data from which records [115.24] in the hypergraph [114] have been derived as well as for storing the final computed structures, such as discussions [136], used by downstream modules and applications. Other embodiments may choose to store all or some of this data in the hypergraph store [115.22] as well. In such embodiments, segments [115.23] would be tagged for different roles, and only those segments [115.23] involved in incrementally computed results would undergo a collection process. Other embodiments may flag collected segments [115.23] so as to redirect the referring process to an external, longer term data store.

[0518] There are many important advantages to immutability in the data store. Multi-threaded or multi-process access to the hypergraph store [115.22] becomes much simplified, with minimal to no requirements for record locking. The use of the OSF [110] formalism and the concept of unification of structures creates many opportunities for sharding and layering of the hypergraph [114] in a consistent and efficient manner. The key concept is that hypergraph [114] elements can be split up in different ways and unification can be used to rejoin them. The type system implemented for OSFs [110] allows us to place constraints on allowable modifications to parts of an element that have been placed in separate locations, thus helping to enforce consistency when they are eventually rejoined. These characteristics can be used to simplify sharding of a hypergraph [114], e.g. splitting it up into subsets to be distributed. Subsets can contain redundant information, or can split apart elements. New OSF [110] types can be created and sent with the shard to be used as constraints to make sure that modifications are handled consistently. Layering of the hypergraph [114] can be handled by splitting all elements in the hypergraph [114] based on subsets of features.

[0519] Additionally, a general philosophy of recombining smaller pieces of an entity when the whole entity is needed allows us to make algorithms lazy in more ways. This is a benefit to incremental computations as we build up partial results during complex computations. In general those results will be stored as new hypergraph [114] elements. It is likely that only a smaller subset of those elements will be useful to more derived results such as discussions [136], e.g. not all actor identities [235] will show up in a discussion [136] for example. If we spend less resources to place the partial results in the hypergraph [114], then we avoid extra work for those that are not used in later computations.

[0520] Most embodiments of the system define a set of hypergraph operations [115.26] on the hypergraph [114] including but not limited to the following: closure, projection, traversal and a set of hypergraph [114] path algebra operations. In the OSF-based embodiment [110] described here these operations may specify additional OSF [110] constraints [115.9]. For example the projection operation [115.28] would start with a set of edges [115.20] and select only those that unified with an OSF [110] value to be used as a constraint [115.9]. The system uses an additional method of constraining the elements that these hypergraph operations [115.26] can access, called “boxing”. A box [115.15] is simply a set of atoms [115.19] from the hypergraph [114]. The purpose of boxing [115.15] is to create groups of hypergraph [114] elements that are related by more complex relationships than can easily be expressed in queries [115.1]. These groups may also be determined by external factors not stored in or referenced from the hypergraph [114]. In many cases the boxes [115.15] may simply be useful for optimizing constraints during query [115.1] execution, by effectively pre-caching the relevant sets of items [122] conforming to the constraint. In the default embodiment, a box [115.15] is defined for each discussion [136]. In addition to the core elements of the discussion [136] (e.g. the external items and relationships between them) these boxes [115.15] may also include other elements of the hypergraph [114] that were considered to be the relevant evidence for the discussion [136] or related to the discussion [136] in other ways.

[0521] In most embodiments, a query [115.1] mechanism is used both for ad-hoc retrieval of records [115.24] from the hypergraph store [115.22] as well as to continuously evaluate an active query [115.1] set on new records [115.24] as they are added to the hypergraph store [115.22]. In a normal graph representation, vertices and edges can be indexed fairly simply. For the hypergraph [114] implementation the system implements a set of query operators [115.30] to deal with the more complex nature of the hypergraph [114] elements.

[0522] Incremental computations are triggered when records [115.24] are matched by the continuous queries [115.1]. In the default OSF [110] based embodiment, query matches [115.16] are produced as an OSF [110] value. These values include descriptions of the matched items [122] built up during query [115.1] evaluation, using unification constraints [115.9] in a manner similar to unification based parsing systems, or logic languages like prolog. When a query [115.1] is matched, the resulting match record [115.16] will determine which of the incremental update procedures should be triggered. The query [115.1] language is designed so that the query operators [115.30] can be used to build up a working set [115.17] of related hypergraph [114] elements during the evaluation of the query [115.1].

[0523] In most embodiments, external indices are built to aid in query [115.1] execution. In the OSF [110] embodiment described here, skip lists are used as the indexing [115.11] mechanism. In this embodiment, the indexing [115.11] is used to speed up linear scans over records [115.24] from the hypergraph store [115.22] rather than fast random access. Some embodiments may also include index [115.11] schemes emphasizing random access, such as b-tree indices. Any of the skip list solutions described here could also be augmented to an inverted index [115.13] representation as commonly used in text search engines. Indexing [115.11] boxes [115.15] uses a form of skip lists as well.

[0524] The primary goal for this default embodiment is to be able to build all of these indices by simply appending new entries without modification to the older entries. Thus the indices are meant to be read backwards, from the newest entries to the oldest. This works well in conjunction with the structure of the hypergraph store [115.22] in which newer versions of a record shadow the older ones. Various embodiments may use different methods for detecting when elements have been shadowed. One embodiment assigns a logical ID to records [115.24]. When a new version of a record is written, both records [115.24] share the same ID. Many embodiments will simply include the address of the earlier version of the record as an attribute. In both cases the query matching procedure [115.10] needs to keep a set of the first seen IDs or addresses that will indicate that later records [115.24] are shadowed. OSF [110] based embodiments can also use type information attached to a record to determine how it is related to the prior version. In one embodiment there are two types of records [115.24], records [115.24] storing just the changes between the two versions and records [115.24] that replace the prior version. Many other schemes are possible, so long as they efficiently and effectively dispatch data events [100] to the appropriate handler based on the record types.

Some Comments on OSF Values

[0525] OSF [110] values and OSF [110] records [115.24] (an OSF [110] value serialized and stored in an archive record) are referenced frequently throughout the description of the hypergraph [114] system. The acronym OSF [110] refers to a particular type of feature structure called an “Order Sorted Feature Structure”, which is well documented in research literature. Feature structures are used throughout AI and natural language processing applications, again we refer to the literature for standard definitions and usages where these concepts well developed and widely understood. The central operation of feature structures is unification, which in essence merges two feature structures (where the values for features that appear in both structures are themselves unified). Only those usages that differ from common practice will be noted here.

[0526] The most relevant feature of the OSF [110] formalism for purposes of the present disclosure is the type system. Types in a feature structure system are handled somewhat differently than in a conventional programming language. Types are themselves represented as feature structures and are available as values which can be unified against. This also means that types can be defined dynamically at runtime. While types are defined within a type lattice, in the default OSF [110] embodiment described here, one or more types can be attached to an OSF [110] value as long as they are consistent (i.e. can be unified with) the value, rather than the value being an instance of the type. In essence types are used to tag values. However types can also contain instance values in addition to the general classes (such as String, Number, Feature Structure and so on). This can make types useful a templates that store values common to all members of the type. In some embodiments these instantiated values are never stored directly in instance values, instead the implementation looks up the value from a type associated in the instance when it is not present. Values can also be uninstantiated and in this way function similarly to a type, i.e. the value represents a class of potential values. The default embodiment defines some additional intrinsic types in addition to those normally found in feature structure implementations; one representing a set of Choices over an enumerated set of values, and another for ranges for values that have a natural order associated with them.

[0527] When constraints [115.9] are referenced in the context of an OSF [110] embodiment the representation is that of a set of OSF [110] values that are the equivalent of a set of unification equations as seen in common practice. One of the characteristics of feature structures is that multiple features (or feature paths) in the structure may point to the same value instance. This is what distinguishes feature structures from representations such as nested property lists. When setting up a constraint [115.9], the set of OSF [110] values each become a feature of a larger OSF [110] value, and some feature (paths) that exist in multiple of the OSF [110] values are modified to point to the same value instance. In this way, when we unify against the value of one of the subfeatures in the constraint [115.9], some of the resulting feature values may then be visible in other subfeature's. This property makes constraints [115.9] bi-directional, which is exploited in query [115.1] representations. If we have a chain of constraints [115.9], we can impose a restriction on all members of the chain by unifying a value against the final sub-feature value in the chain to produce a new, restricted constraint [115.9]. When a matching network [115.5] in an OSF [110] embodiment is generated, the operator nodes [115.7] are linked via a tree of dependent constraints [115.9] (e.g. the values produced from constraints [115.9] on sub-trees in the network [115.5] are used as inputs to the constraint [115.9] on their common root node [115.7]). In this case one of the subfeatures is designated the right hand side of the equation (the RHS) and will be used as the OSF [110] value derived for the root node [115.7] after unifying values reported from the node's [115.7] children in the matching network [115.5].

Key Object Types

[0528] Hypergraph: The mathematical definition extends standard graphs to allow for edges connecting any number of vertices. The hypergraph [114] system described here extends this definition further by allowing an edge [115.20] to connect any number of vertices [115.21] and edges [115.20]. The list of atoms [115.19] composing an edge [115.20] are subject to an ordering constraint. There are three classes of ordering constraint. The simplest defines no ordering relationships at all, resulting in an unordered edge [115.20]. The most common case is that a total order is specified, which is straightforwardly represented as the order of occurrence of the atoms [115.19] comprising an edge [115.20]. In the most extreme case a separate partial order is defined and can be referenced as the ordering constraint for the edge [115.20]. The partial order is defined separately so that it can be reused across edges [115.20].

[0529] Hypergraph store: the physical unit of storage for elements of the hypergraph [114]. It should be noted that there is no requirement that only hypergraph [114] elements appear in the hypergraph store [115.22]. The hypergraph [114] may be represented as one subset out of all the records [115.24] in the hypergraph store [115.22].

[0530] Store address: An important characteristic of the system is that records [115.24] in the hypergraph store [115.22] are accessed via a direct address rather than by keyed lookup as would be done in database systems. In one embodiment this address consists of segment id and offset parts, indicating an offset into a of data in the hypergraph store [115.22] In such embodiments the hypergraph store [115.22] maintains a master table.

[0531] Atom [115.19]: Any hypergraph [114] element. As stated before, the default embodiment uses OSF [110] records [115.24] to store all atoms [115.19] will be referred to as the OSF [110] embodiment. Other embodiments may use data representations other than OSF [110] so long as they store a sufficient description of the atom [115.19]. In OSF-based embodiments [110], a set of types will be predefined by the system that correspond to the two kinds of atoms [115.19]. There may be more than one type defined for each kind of atom [115.19] because for example the system may allow successive versions of an atom [115.19] to be represented either by storing only the differences between the pairs or by adding a record that completely shadows the old version. In such an embodiment, records [115.24] of multiple types could then be used in the same hypergraph store [115.22], allowing the system flexibility when to use one method versus the other (for instance small atoms [115.19] may use the shadowing method, whereas large atoms [115.19] may use the difference method). In some embodiments atoms [115.19] may require an attribute that represents a “logical ID”, i.e. an id that uniquely identifies the atom [115.19] and is shared across successive versions of the atom [115.19] in the underlying hypergraph store [115.22].

[0532] Vertex [115.21]: The fundamental unit from which hypergraphs [114] are formed. The OSF [110] embodiment will predefine a base type for OSF [110] records [115.24] representing vertices [115.21].

[0533] Edge [115.20]: A relationship between a set of atoms [115.19]. Edges [115.20] minimally require an attribute containing a list of atoms [115.19]. In some embodiments the edges [115.20] may be ordered, the equivalent to directed edges in conventional graphs. The OSF [110] embodiment will predefine a base type for OSF [110] records [115.24] representing edges [115.20]. Additionally subtypes for distinguishing ordered and unordered edges [115.20] may be defined. Ordered edges [115.20] are the hypergraph [114] equivalent to directed edges in a conventional graph, where the directed edge places an ordering on the pair of vertices that it relates. One point of difference from conventional graphs is that there is no advantage to storing a reversed version of an ordered edge [115.20]. In a conventional graph it is often an advantage to index edges by either head or tail, which can then entail storing reverted versions of edges. As the hypergraph [114] has a more complex structure traversal, retrieval and other operations on the hypergraph [114] need to use a more general model.

[0534] Index [115.11]: The hypergraph [114] system relies on additional structures to aid in the location and retrieval of atoms [115.19] from the hypergraph store [115.22]. The indices stored by the system do not necessarily aid in quickly finding a random element of the hypergraph store [115.22]. In particular they are more often used to iterate over elements in the hypergraph store [115.22] more efficiently. The goal for these indices is that they be very cheap to update as new data elements are added to the hypergraph store [115.22]. For this reason the skip list data structure is often useful: there is a standard body of practice on using skip lists to efficiently create balanced index structures.

[0535] Hypergraph operations: The system defines a generic set of high level operations for working with the hypergraph [114]. These operations work by modifying a working set [115.17] consisting of atoms [115.19]. There are three core operations listed below.

[0536] Closure operation: The set of elements reachable from an initial atom [115.19] or set of atoms [115.19]. The system defines a closure operation [115.29] that computes and adds this set of atoms [115.19] to a working set [115.17]. Closures potentially can be quite large and encompass the whole hypergraph [114] therefore most embodiments of the system use constraints [115.9] to only return elements of the closure that fall in some smaller neighborhood. In addition to the constraints [115.9], the closure operation [115.29] implements some extra conditions which separate it from a traversal operation [115.27]. An additional notion of consistency is often used when determining which atoms [115.19] are reachable. Different embodiments may choose from any number of consistency measures. In the OSF [110] embodiment described here, closure results in a set of edges [115.20]. The resulting set is restricted to be edges [115.20] that share a minimum number of atoms [115.19] in common. This measure is evaluated over the whole set. This calculation corresponds to a limited form of clustering and is intended to partially or fully replace the clustering operations that were used in prior implementations of the discussion [136] building process.

[0537] Projection operation: Removes elements from a working set [115.17]. The elements are chosen via constraints [115.9] and other filters. Embodiments may use characteristics such as edge [115.20] weights, arity and so on to select edges [115.20] in the projection. In some embodiments edge [115.20] paths contained in the working set [115.17] are replaced with new edges [115.20]. This is accomplished through the use of a path algebra. In the default embodiment the path algebra operations are specified via an OSF [110] value and a set of types are predefined for that purpose.

[0538] Traversal operation: Adds elements to a working set [115.17], starting from elements that are in the working set [115.17] and following edges [115.20] incident on those elements. The operation shares similarities with the closure operation [115.29], but is focused on more fine grained control of the traversal rather than properties of the resulting set. The operation can be parameterized to run according to a traversal pattern. In the default OSF [110] embodiment the traversal pattern is specified via an OSF [110] record. Breadth-first patterns add elements from successive neighborhoods out to a certain number of layers or hops. Depth-first patterns are used to select paths out to a certain number of hops. For example, a depth-first pattern may specify the first n-many paths, or the n highest weighted paths.

[0539] Hypergraph Query: The system implements an engine for running queries [115.1] against atoms [115.19] in the hypergraph [114]. A query [115.1] is represented as a nested expression [115.2]. Expressions [115.2] consist of terms [115.4] and functions [115.3] over terms [115.4] and functions [115.3]. Terms [115.4] define a match condition. In OSF [110] embodiments a term [115.4] is represented as a feature value pair. The feature is used to select a value from the OSF [110] value representing an atom [115.19] and the match condition is satisfied if the two values can be unified successfully. Query expressions [115.2] map to a set of operators [115.30]. These operators [115.30] operate on match records [115.16] that contain a payload [115.18] value and a working set [115.17] of atoms [115.19]. One set of operators [115.30] simply wrap the hypergraph operations [115.26] defined by the system. The modifications to the working set [115.17] performed by these operators [115.30] are limited by a set of constraints [115.91], i.e. only atoms [115.19] that pass the constraints [115.9] may be added/removed (or considered for addition/removal depending on what is most efficient for the operator [115.30] in question). Typically there will be several constraints [115.9] active. Most of the individual operators [115.30] will take a constraint [115.9] argument and there are other constraint mechanisms described below. As defined earlier, in OSF [110] embodiments constraints [115.9] are implemented via unification equations. This also means that a new OSF [110] record will be created as a result of evaluating the equation. Thus in OSF [110] embodiments constraints [115.9] can be used both as a mechanism for licensing an operation and for building up OSF [110] records [115.24] that describe the atoms [115.19] in a working set [115.17] in a match [115.16]. It should also be noted that operators [115.30] may define new transitory edges [115.20] that only exist in the working set [115.17]. In some cases those edges [115.20] may be placed back in the hypergraph store [115.22], but often this mechanism is used to reconstruct an edge [115.20] that was never directly placed in the hypergraph store [115.22]. This is used to implement lazy algorithms.

[0540] Query Operators: These are the operators [115.30] used to specify queries [115.1] against hypergraph [114] elements. When evaluated a query operator [115.30] works on one working set [115.17], but a query procedure [115.10] maintains a list of working sets [115.17]. Each atom [115.19] initially matched in a query [115.1] spawns a working set [115.17] which may be expanded during the evaluation of query operators [115.30]. An embodiment of a set of query operators [115.30] appears later in this section.

[0541] Box: An additional indexing [115.11] mechanism over atoms [115.19]. This mechanism is used to implement constraints that are in force during a query [115.1]. As stated earlier a box [115.15] is simply a set of atoms [115.19]. In some embodiments boxes [115.15] may simply be one type of edge [115.20] stored in the hypergraph [114]. In the embodiment described here boxes [115.15] are stored in a supplementary store. Boxes [115.15] are related to each other by containment, so the set of boxes [115.15] can be placed in their own graph structure with directed edges [115.20] from each box [115.15] to the largest boxes [115.15] contained within it. This means that if boxA contains boxB contains boxC, links only exist from A to B and B to C. Mathematically this structure is a finite lattice. Hypergraph [114] query operators [115.30] can specify that sub-operators [115.30] are constrained to work within (or outside of) a box [115.15]. Boxes [115.15] can be selected in several ways, and there are query operators [115.30] that can change the current box [115.15] by moving up or down in the hierarchy.

Hypergraph Store Implementation

[0542] In one embodiment, the hypergraph store [115.22] is an archive or set of archives that are split up into segments [115.23]. New segments [115.23] are allocated as the hypergraph [114] grows, and aged elements are removed from the hypergraph [114] by removing segments [115.23]. In order to allocate a new segment [115.23] the system first looks to see if there are any collected segments [115.23] (i.e. they have been removed from active use), or extends the archive to allocate a new segment [115.23]. The hypergraph store [115.22] has a master segment table [115.25] that indicates the type and status of a segment [115.23]. New entries are always appended when a segment [115.23] is allocated, This is because there may be dangling references to collected segments [115.23] in the active part of the hypergraph store [115.22]. The record for the freed segment [115.23] will contain information used to determine how dangling references are resolved as described earlier in this document. In the OSF [110] embodiment OSF [110] records [115.24] are stored at offsets into a segment [115.23], therefore they can be addressed with a segment id:offset pair as the address. As already noted, the OSF [110] records [115.24] represent elements of the hypergraph [114], called atoms [115.19]. However they are not restricted to that purpose, therefore the hypergraph [114] may be augmented with additional record types, or these additional records [115.24] may be used to do bookkeeping for storing partial state of an ongoing computation, etc. In one OSF-based embodiment [110], the OSF [110] records [115.24] are immutable. As discussed above, this places additional requirements on how hypergraph [114] structures are to be updated, but greatly simplifies management of the hypergraph store [115.22], particularly in multi-threaded or multi-process implementations. As the hypergraph store [115.22] is to be continuously updated, we seek to minimize the cost of adding new elements to the hypergraph store [115.22]. Hypergraph [114] computations that are triggered by the addition of new elements will then use lazy algorithms that only build out structures that are directly needed. The motivating factor for this design is that in many cases it can take more time to compute a result and store it in a way that it can be efficiently retrieved than to simply re-derive it as and when necessary. The hypergraph [114] system is designed to take advantage of these cases wherever possible.

[0543] As described earlier, all OSF [110] records [115.24] are associated with one or more types. One set of types will determine what kind of atom [115.19] the record represents. However additional types associated to the record can be used to determine how the record should be handled by the system. Here we describe two of these additional distinctions: how a record is related to prior versions and the inclusion of special processing instructions for individual atoms [115.19].

[0544] In one OSF [110] embodiment new versions of a record can be added by either completely shadowing the prior version or by describing a set of differences from the old version. For example when dealing with a large edge [115.20] the system may only store new members added to the edge [115.20] rather than storing an entirely new copy. Using this differential storage creates opportunities for new synergies with the query matching procedure [115.22] described below. For example, in a case where the query [115.1] only specifies the traversal of the most recent n paths in a match [115.16], those paths will usually be found in the last delta added for an edge [115.20]. In that case we have avoided retrieving and updating the edge [115.20] as well as any other atoms [115.19] dependent on it, by only storing the difference into the hypergraph [114]. This scheme has potential costs as well, since we need to retrieve multiple records [115.24] to reconstruct the state of the whole edge [115.20]. The OSF [110] type system enables the implementation to select a tradeoff between these methods atom [115.19] by atom [115.19]. The details of specialized handling of records [115.24] are hidden behind the hypergraph operations [115.26] described above. This allows the system to evolve and add new representations without modifying existing applications.

[0545] When analyzing real world data, no algorithm is perfect. When problems are identified, OSF-based [110] embodiments of the system allow for “fixes” to be placed in the hypergraph [114] in the form of specialized processing instructions in most embodiments. Embodiments using other record formats may be able to implement a similar scheme. In the OSF [110] embodiments, a predefined set of OSF [110] types represent additional instructions that can be given to the various algorithms used by the system. In an embodiment that computes actor identities [235] as elsewhere described, a possible problem might be that a particular pair of aliases [240] is erroneously associated with the same actor identity [235]. This system would allow an annotation to be placed on the respective alias [240] atoms [115.19] ing the combination of the two. These could be added to elements due to user feedback or other procedures detecting inconsistencies or problems in derived hypergraph [114] structures.

Hypergraph Query Mechanism

[0546] Queries [115.1] have two purposes: to retrieve elements from the hypergraph [114] and to trigger hypergraph [114] computations in response to new atoms [115.19] being added to the hypergraph store [115.22]. The same query matching procedure [115.10] is used for both purposes.

[0547] The query [115.1] functionality covers three areas in most embodiments: matching features of OSF [110] records [115.24], augmenting a query working set [115.17] with hypergraph operations [115.26], and placing constraints on the hypergraph operations [115.26] either by additional feature tests or by membership or non-membership in a box [115.15].

[0548] The default embodiment described here represents query operators [115.30] as a set of functions [115.3], whose arguments are either other query operators [115.30] or feature structures to use as terms or to use as constraints [115.9]. Functions [115.3] accept match records [115.16] from their constituent arguments and produce a match record [115.16] if their condition is met. Match records [115.16] are represented as an OSF [110] record. This record contains bookkeeping information about the partial match [115.16] as well as a “payload” [115.18] feature that pulls some or all of the values out of its arguments. The initial match records [115.16] are created by comparing the leaf feature structures to atoms [115.19] in the hypergraph store [115.22]. If the feature structure unifies, a match record [115.16] created with the unified result as the payload [115.18]. If the operator [115.30] has a constraint [115.9], we attempt to unify the constraint [115.9] values against a match record [115.16] and the constraint [115.9] is satisfied if it succeeds. In one embodiment the constraint [115.9] is a unification equation that relates values in two feature structures. The resulting match record [115.16] contains the RHS value after successful unification of incoming match records [115.16] against the LHS. Note this same mechanism can be used to introduce new values into the match record [115.16] as well.

[0549] In one embodiment the set of operators [115.30] is represented as a network [115.5] of vertices representing the operators [115.30] and edges that link operators [115.30] to any enclosing operators [115.30] The highest operator [115.30] is linked to a final reporting node [115.8]. Any match records [115.16] that flow through to that node [115.8] are reported as results.

[0550] Note that this structure can represent multiple queries [115.1], as the penultimate node [115.7] must be unique to each query [115.1]. When building the hypergraph [114] we reuse sub-queries [115.1] and only add nodes [115.7] for new ones. We can also turn off queries [115.1] by keeping a reference count of the number of active downstream nodes [115.7]. To deactivate a query [115.1] set the reference count on its penultimate node [115.7] to zero, and walk through its children decrementing the count. Only those nodes [115.7] with a positive reference count will report results forward.

Query Language Operators

[0551] The query procedure [115.10] effectively creates a working set [115.17] for each atom [115.19] that it examines. Some query operators [115.30] are just wrappers around hypergraph operations [115.26] that expand or filter that working set [115.17]. We do not distinguish between atom [115.19] types in most embodiments as that can be done by selecting the atoms [115.19] that go into an index [115.11], as well as by feature matching and constraints [115.9].

[0552] In most embodiments query operators [115.30] will include, but will not be limited to, the following:

• • [0553] Is(feat, value) [118.05]: if the atom [115.19] contains “feat” and its value unifies with value, then create a partial match record [115.16] containing the unified value.
  • [0554] IsNot(feat, value, [opt] pattern) [118.10]: if the atom [115.19] doesn't contain “feat” or it does and the value does not unify, create a match record [115.16]. If the optional third argument is specified, return the part of the atom [115.19] matching pattern.
  • [0555] And(operator+, constraint) [118.15]: if all operator arguments produce a match record [115.16], pass on a new match record [115.16] based on a merge of the incoming match record [115.16]. The constraint [115.9] maps values from the incoming match records [115.16] to the result
  • [0556] AndNot(operator, operator) [118.20]: if arg1 matches and arg2 does not, then pass on arg1.

[0557] Or(operator+) [118.25]: pass through first matching argument, alternately pass through unification of all match records [115.16]

• • [0558] Close(operator, constraint) [118.30]: calculate the closure of an atom [115.19], i.e. find the set of all directly connected elements. i.e. if edge123 shares an atom [115.19] with edge234 they are both in the same closure. The operator allows for a feature structure that can be used as a constraint/filter on items [122] that are added to a closure. Closure calculation specifies the amount of overlap required between items [122], (e.g. only if they share x % atoms [115.19]) this is just a modified form of what we do in the clustering framework with hashes, so in fact we can use the closure operator [115.30] to do clustering.
  • [0559] Project(operator, [opt] expression, constraint) [118.35]: take a subset of the working set [115.17]. As above a feature argument can be used as a fitter. A path algebra expression can be used in some embodiments to create a new working set [115.17] with edges [115.20] based on paths found in the current working set [115.17]. In OSF [110] embodiments the path algebra expression will be represented as an OSF [110] record.
  • [0560] Traverse(operator, [opt] expression, constraint) [118.40]: expand the working set [115.17]. By default this just adds the neighborhood for atoms [115.19] in the working set [115.17]. The operator [115.30] accepts an optional expression controlling the traversal as described for the hypergraph [114] traversal operation [115.27] In OSF [110] embodiments the traversal instructions are passed in as an OSF [110] record.
  • [0561] Within(box, operator) [118.45]: a box [115.15] is selected based on arg1. All operations within arg2 are constrained to atoms [115.19] within this box [115.15]. This box [115.15] overrides any box [115.15] selected by enclosing operators [115.30], similarly a sub-operator [115.30] may specify a box [115.15] that overrides the one chosen at this level. In OSF [110] embodiments argument1 is an OSF [110] record that is to be matched against a list of box [115.15] descriptors.
  • [0562] Outside(box, operator) [118.50]: as above but the constraint is reversed.
  • [0563] Widen(constraint, operator, mode) [118.55]: it is an error if no enclosing operator [115.30] specifies a box [115.15]. Select a box [115.15] that is higher in the hierarchy, using arg1 as a constraint against the box [115.15] descriptor. Arg3 determines whether all boxes [115.15] matching the constraint are used or the first one.
  • [0564] Narrow(constraint, operator, mode) [118.60]: as above but move down in the hierarchy
  • [0565] Union(operator+, mode) [118.65]: the mode determines whether or not we try to unify match record [115.16] payloads [115.18] or not. If unification is indicated the operation proceeds only if the payloads [115.18] can be unified and the unified result is used as the new match record's [115.16] payload [115.18]. Otherwise, a new OSF [110] value is created that contains each of the original payloads [115.18] as a feature. The union of the working sets [115.17] from argument match records [115.16] is returned.
  • [0566] Intersection(operator, operator+) [118.70]: only succeeds if the intersection is non empty. The mode argument specifies how to handle the payloads [115.18] of arguments that have members in the resulting working set [115.17]. If unification is indicated the operation proceeds only if the payloads [115.18] can be unified and the unified result is used as the new match record's [115.16] payload [115.18]. Otherwise, a new OSF [110] value is created that contains each of the original payloads [115.18] as a feature. The intersection of the working sets [115.17] from argument match records [115.16] is returned.
  • [0567] Annotate(operator, constraint) [118.75]: in the OSF [110] embodiments, the constraint [115.9] will create a new match record [115.16]. If the match record [115.16] unifies with the constraint [115.9] LHS pass on a new match record [115.16] constructed from the constraint's [115.9] RHS.
    Maintaining Indices

[0568] The embodiments of the system described here have all assumed the presence of an index [115.11] based on skip lists. The system in fact does not necessarily require the presence of an index [115.11], any of the techniques described here can be used by scanning through the OSF [110] records [115.24] in the hypergraph store [115.22]. The value of skip lists is two fold: they are very cheap to maintain, and they implement a technique to speed traversal of the indexes [115.11]. The embodiment of skip lists described here orders the atoms [115.19] they index by time of arrival in the hypergraph store [115.22]. Alternatively they can support indexing based on other orders, but generally at a cost which is greater than the technique described here.

[0569] We describe an embodiment of the system in which the skip lists are built in reverse order. The normal skip list model needs to be augmented so that we know how far forward a skip will go and there also needs to be a way to coordinate skip lengths across the indices. All indices will add atoms [115.19] in the same order, and a simple solution to the second problem is just to add every atom [115.19] whether its a useful member of the list or not. However, that simple solution is not very desirable and can be improved by counting the atoms [115.19] that are not members of the list in the skip lengths.

[0570] The base entries [116.05] in the list each contain a pair of the feature value for an atom [115.19] and its address. Additionally entries [116.05] contain a variable length array of pointer and skip count pairs [116.10] that are used to link entries together. Skip list entries can therefore be a member of multiple linked lists. The technique used here is that each successive level in the skip list skips a larger number of entries in the list. The goal is to be able to skip over a large number of entries in a small number of steps. In order to skip a number of entries [116.05] from the current entry [116.05], find the level with the largest skip count that is less than or equal to the remaining number of entries [116.05] to skip. Follow the pointer to the next entry on that level and subtract the skip counter from the remaining number of entries, terminating when the remaining count reaches zero. This procedure is used during query [115.1] execution to speed traversal of the hypergraph [114] when there are multiple query terms [115.4] Every time query [115.1] matching fails for an atom [115.19], we can skip over the entries [116.05] for that atom [115.19] in the lists that have not yet been visited for that atom [115.19]. As a consequence of the design, queries [115.1] that are more restrictive and/or have a larger number of terms [115.4] and sub-expressions [115.2] will gain the most, due to being able to maximize skip lengths. This is because in general more skips will accumulate before revisiting one of the later index [115.11] lists. An embodiment may optimize query [115.1] execution speed by ordering term [115.4] tests such that indices referencing fewer atoms [115.19] or indices or tests that are determined to be more likely to fail are visited first. In this way the procedure can find skips both earlier and by visiting a smaller number of index [115.11] lists. As we only visit the later lists when the query [115.1] evaluation for an atom [115.19] has not already failed, this has the result of producing larger skips in those lists.

[0571] Construction of the list is relatively simple and requires a counter that is incremented for each new item added to the hypergraph store [115.22]. When a new item is added to the hypergraph store [115.22], determine which skip lists to update. For each skip list, add a new entry [116.05], and determine how many levels of the skip list to include it in. For instance to have skips of increasing orders of magnitude, place it in the second level if the current counter is a multiple of 10, and in the third level if a multiple of 100 and so on. When there are atoms [115.19] that are not to be included in a list, this may result in more level entries than necessary. In one embodiment this problem is handled by keeping a separate relative counter for atoms [115.19] added to the list and use that counter to determine the number of levels, however record the skip count based on the first counter. This will require that the last positions used at each level from the first counter be tracked. When adding entries to a skip list with a level array [116.10] of length x we first increment the head's [116.15] skip counters for each level then copy the first x level pairs from the head [116.15] of the list into the new entry's [116.05] level list [116.10] and update the first x level pointers in the head to point to the new entry [116.05]. Finally, set the first x skip counters to zero.

[0572] Augmenting the skip list to be an inverted index [115.13] is fairly straightforward. It has the same structure as the skip list above (see [116.20] [116.25] [116.30]), however the level lists are constructed slightly differently. An inverted index [115.13] essentially acts like a collection of skip lists in this context. We add an extra table [116.35] that maps from each feature value entry to the head [116.30] of a set of skip list levels used for just that value. The construction procedure is the same as above with the change that we append together the level lists [116.30] for each of the skip lists that reference the atom [115.19]. One embodiment will retain the feature value in skip list entries [116.20] so that values contained in the head table [116.35] may be used to denote a range of possible values (which can be used to reduce the number of posting lists). In this embodiment each value contained at the head table [116.35] must be able to successfully unify with all of the values contained in its associated set of levels [116.30] [116.25].

[0573] The skip list index [115.31] used for boxes [115.15] has an additional purpose beyond the skip lists described above. It is desirable to be able to directly enumerate the members of a box [115.15]. To do this we add to the skip list representation above a set of levels consisting of <boxId, pointer> pairs. These allow us to chase pointers to recover the members of a box [115.15] as well as skipping using the other levels. One set of skip list levels [117.05] [117.10] [117.15] is constructed similarly to the skip lists described above, however a feature value is not required to be stored in the base list entry [117.05]. An additional set of levels [117.20] is added for each of the box [115.15] membership lists, along with an array of the heads of each level [117.25]. In order to be more space efficient, an embodiment can choose to store only those containing boxes [115.15] at the bottom of the box [115.15] hierarchy. For example in FIG. 117, Box1, Box2, Box4 are the only ones that would need to be placed in membership lists [117.20]. Membership in other boxes [115.15] could be found by searching the parents of these boxes [115.15] in the hierarchy. The embodiments described use a separate data structure to track the hierarchy of containment relationships between boxes [115.15]. In one embodiment the box [115.15] hierarchy is simply kept in the hypergraph [114] itself.

Hypergraph Query Matching Procedure

[0574] The following description of query [115.1] matching is written assuming an OSF [110] embodiment. However the logic of the procedure [115.10] is not dependent on an OSF [110] representation. There are some asides in the description below that apply to an OSF [110] record representation and they do not limit the applicability of the procedure [115.10].

[0575] FIG. 119 defines the logical structure of the query matching procedure [115.10] that will be used in many embodiments. The figure contains branches for both indexed and continuous queries [115.1]. For indexed queries [115.1] a list of indexes [115.11] is kept. An index [115.11] is marked as exhausted when the procedure [115.10] reaches the end of the index [115.11]. If an index [115.11] entry refers to an atom [115.19] from a segment [115.23] that has been collected, then depending on the garbage collection strategy used by the embodiment, the end of the list may have effectively been reached. Each index [115.11] is associated with a particular feature, and an additional list of the tests based on that feature is kept for each index [115.11].

[0576] When running a continuous query [115.1] the procedure [115.10] has access to the OSF [110] record itself in most embodiments. An embodiment may choose to bypass the scan over indices and scan over atoms [115.19] in the hypergraph [114], retrieving the OSF [110] records [115.24] and Tests for the continuous queries [115.1] first retrieve a value from the atom [115.19] based on the feature. The test can specify whether or not the value is required to be non-empty. If it can be non-empty the test succeeds vacuously, otherwise the test succeeds if the test value can be unified against the retrieved value. The following text describes the workflow used in one embodiment.

[0577] Starting from [119.05] an indexed query procedure [115.10] enters a top level loop that scans through the set of indices. First it selects an index [115.11] [119.10]. If the index [115.11] is exhausted [119.15] then check to see if there are any more indices [119.20]. If not then the procedure [115.10] terminates. Otherwise we enter a loop that evaluates all the initial feature tests [119.35].

[0578] A continuous query procedure [115.10] [119.30] will bypass the loop that scans through indices and start at [119.35] as well. At [119.35] the procedure [115.10] selects the next test and checks to see if it is satisfied [119.40]. If so then we create an initial match record [115.16] and advance it to all target nodes [115.7] associated with that test [119.45]. If a test appears in more than one immediately containing expression [115.2], then it is linked to the operator nodes [115.7] created for all those expressions [115.2]. When a match record [115.16] is advanced to a node [115.7] it may become active. The activation of an operator node [115.7] depends on its type. However the decision is generally based on receiving the appropriate arguments and any initial tests or constraints [115.9] to be satisfied. If a node [115.7] does not become active then the match record [115.16] advanced to it will be stored, in case other match records [115.16] are reported to the node [115.7] later in the procedure [115.10] and it then becomes active. The procedure [115.10] next moves all nodes [115.7] that became active in the last step into the active node queue [119.60]. If there are more tests [119.55] then the procedure [115.10] continues [119.35]. Otherwise we move to a loop [119.70] that continues attempting to activate operator nodes [115.7]. Note that if we are running an indexed query [115.1], then at [119.55] the test checks to see if any tests remain in the list for the current index [115.11].

[0579] It should be noted that the operator nodes [115.7] corresponding to the outermost query expressions [115.2] are linked to a final reporting node [115.8]. The final node [115.8] does not become active as operator nodes [115.7] do, rather when a match record [115.16] is advanced to the final node [115.8] it is reported as a query [115.1] match. While there are more nodes [115.7] in the active node queue [119.70], remove an operator node [115.7] from the queue and evaluate it [119.75]. If the evaluation fails [119.80] then continue with the loop. Otherwise, we create a match record [115.16] and advance it to any down stream nodes [115.7] [119.95]. As with the initial tests, during generation of the matching network [115.5] an embodiment may detect shared sub-expressions [115.2] and connect the sub-network [115.5] generated for the sub-expression [115.2] to the operator nodes [115.7] generated for all immediately containing expressions [115.2]. Any nodes [115.7] that became active in the prior step are placed in the queue [119.90].

[0580] When the queue empties [119.35], any completed query matches [116.16] will have been advanced to the final node [115.8] and reported. The procedure [115.10] resets the matching network [115.5] state by removing all match records [115.16] from operator nodes [115.7] [119.100]. If this is a continuous query [115.1] [119.85] then we are finished. Otherwise if there are no more atoms [115.19] [119.65] then we are finished. Otherwise we advance to the next atom [115.19] [119.50] and reenter the initial loop [119.10]. In one embodiment the procedure [115.10] only need check that there are unexhausted indices and it will set the current atom [115.19] to the next atom [115.19] in the next entry of the first index [115.11] it chooses.

[0581] There are several conceivable ways that embodiments can optimize this procedure [115.10], the optimizations will in general be different for the continuous and indexed cases. One of the most valuable areas to optimize is the initial tests against feature values. One embodiment will substitute more inexpensive test routines for commonly recognized patterns in the OSF [110] values and thereby avoid the unification step. This procedure [115.10] may be simplified by introducing a set of OSF [110] types for which optimizations have been determined. In continuous queries [115.1] one embodiment unifies several or all of the test conditions so that they can all be checked with only one unification operation. For example several tests feeding into an “and” operator [115.30] may be combined this way. This lets the unification code find the most optimal strategy for the two values. Again, the type system may be used within the unification implementation to dispatch to possible optimizations.

Discussion Building Architecture

[0582] The following procedure describes how the hypergraph [114] system is used to enable building of discussions [136] in a continuous usage mode. It should be noted that the hypergraph [114] system described here is a general purpose tool; it is used to continuously compute a large variety of complex structures in addition to discussions [136]. The embodiments referenced here reference discussions [136] but the use of the system is not limited to this one procedure.

[0583] For continuous processing a large set of queries [115.1] are set up to be run continuously. These queries [115.1] are intended to trigger computations in response to new atoms [115.19] added to the hypergraph [114]. The system contains a set of dispatch rules that determine which incremental computation (if any) should be run in response to query matches [115.16]. These rules trigger computations intended to synthesize new pieces of evidence as well as the procedure(s) used to create or update discussions [136].

[0584] In one OSF [110] embodiment queries [115.1] produce OSF [110] values as part of the matching procedure [115.10]. These queries [115.1] also contain constraints [115.9] expressed as unification equations that are used to build up the resulting match record [115.16] values. These queries [115.1] do not have to look for particular values, and would not be very useful for incremental computation if they did. In the OSF [110] embodiment queries [115.1] can easily be set up to detect broad classes of evidence. This is because OSF [110] feature structures can contain empty, typed values as well as choice and range values that can unify against a set of possible values. This OSF [110] embodiment will also use constraints [115.9] to represent the dispatch rules triggering incremental computations. As elsewhere: these constraints [115.9] can be used to construct a new OSF [110] value based on the value that they unify against. In this context that functionality can be used to pass instructions on to the routine carrying out the incremental computation. One way of describing this system is as a feed-forward inference engine, and is subject to the same sorts of optimizations as those systems. When a computation is triggered both the payload [115.18] and working set [115.17] from the match record [115.16] are passed to the triggered procedure.

[0585] An example of the general flow of processing is as follows. An email is added to the hypergraph [114]. Evidence rules are triggered which perform computations such as resolving aliases of the sender and recipients of the email to actors, possibly creating new actors [220] as a side effect. Various other relationships might be found for content in the email and so on. As any new evidences are added to the hypergraph [114] new query matches [115.16] may be produced. At some point, a query [115.1] which checks to see if the actors [220] associated to the email are consistent with actors [220] in one or more discussions [136] or emails (via the closure query operator [115.30]) triggers a computation to see if the email should be added to one or more of those discussions [136] or cause the formation of a new one.

[0586] Embodiments have a great deal of flexibility in how to handle this flow. For example an embodiment may run match records [115.16] or incrementally triggered computations in batches to share work in computing updates. The order in which computations are triggered may be important as well. Embodiments may use a queueing methodology, embed conditions in the dispatch rules or other mechanisms to establish orderings. Any such approaches are heavily dependant on the rules used, the set of computations that are available and details of how they work.

[0587] The structure of the procedure is fairly straightforward. When a match record [115.16] is reported [120.05] it is compared to a list of dispatch rules. For each rule that is matched, if it is an evidence rule (e.g. used to calculate some intermediate result), an evidence calculation procedure is triggered [120.10] The procedure may run immediately at this point or be scheduled to run later or in a batch. At the point the procedure runs, it may either enumerate the current evidences that are affected by the new data, or simply produce a new evidence and in the next step the overlapping or otherwise affected evidences are determined [120.15]. Once this set is determined a set of updates to the hypergraph [114] have to be decided [120.20], as noted elsewhere these updates may be new atoms [115.19] that shadow the old definition or atoms [115.19] that specify a set of changes to the earlier version of the atom [115.19]. The decisions here are dependant on the type and content of the new evidence•atom(s) [115.19].

[0588] If a matched rule triggers a discussion [136] building computation the sequence is somewhat more involved. First the working set [115.17] of the query [115.1] is expanded to produce an on the fly hypergraph [114] of evidences (i.e. the working set [115.17]) related to the item and any discussions [136] that triggered the computation [120.25]. This expansion of the working set [115.17] may also create new transitory edges [115.20] reflecting heuristics and other ad-hoc methods for specifying or limiting relationships. At a broad level the discussion [136] is built by taking a projection from this evidence hypergraph [114] [120.30]. Projection in this sense is defined similarly to the hypergraph [114] projection operation [115.28]. In one embodiment the working set [115.17] is transformed into a set of pairwise edges [115.20] and the projection is found by running a maximum spanning tree algorithm. In other embodiments the algorithm is modified to run on a hypergraph [114] directly. The algorithm is further augmented by conditions that disallow links to be used by the algorithm. The general result of this is that the algorithm will act as if the hypergraph [114] is split into components and spanning trees will be computed for each of the components.

[0589] As with the calculation of evidences the set of current affected discussions [136] is enumerated [120.35]. The new discussions [136] are added to the hypergraph [114]. [120.40]. In one embodiment discussions [136] are represented as an edge [115.20] and a partial order on the items on other constituent structures in the discussion [136]. In an alternate embodiment the edge [115.20] is unordered and any process viewing the discussion [136] will decide how to order and display the members of the discussion [136] based on retrieving associated edges [115.20]. In what is perhaps the most flexible scheme, an embodiment will simply define a discussion [136] as a box [115.15], and the reported result will be the ID of the box [115.15]. A process can then construct a view of the discussion [136] or discussions [136] related to an item by running a query [115.1] constrained by the box [115.15], or simply return all the members of the box [115.15]. The system assumes that the discussions [136] are reported [120.45] to an external process or store or other similar mechanism. In one embodiment the address of a discussion [136] edge [115.20] is reported. In this manner the client can be notified when there are changes to a discussion [136] or a new discussion [136] has been added. Then rather than running a query [115.1], the client can directly retrieve the edge [115.20] and traverse to related atoms [115.19].

Mapping Data Sources to the Hypergraph

[0590] An important assumption is that atoms [115.19] describe a subset of relevant characteristics of source actors [220], items and events. In most embodiments, the source data for these entities will be archived separately and atoms [115.19] will contain location data for the source data corresponding to each atom [115.19]. In the description below, as elsewhere, an OSF [110] based embodiment will be assumed. Embodiments that use other representations will need to be able to at least minimally represent the characteristics described below.

[0591] The core concept is that the structure of atoms [115.19] be defined by a set of facet types [121.40]. The intent is that the structure of an atom [115.19] can be determined by unifying a list of facet types. The implication of this is that facet types do not define individual values contained in atoms [115.19], rather they are a slice of the final atom [115.19]. The set of facet types associated with an atom [115.19] provide an efficient mechanism for dispatching to incremental computation procedures. The set of types is intended to have the effect that most dispatch rules need only test for one or more of these types in order to determine what to trigger for an atom [115.19].

[0592] FIG. 121 provides a highly schematic example of how atoms [115.19] are associated with facet types in one embodiment. A type EmailItem [121.45] is defined as the unification of the types ItemIdentity [121.05], ActorBroadcast [121.20], ArchivedContent [121.25] and EdgeAtom [121.35]. EdgeAtom [121.35] defines the set of characteristics necessary for an edge [115.20] atom, i.e. an address, a logical ID, a list of incident atoms [115.19] and so on. ItemIdentity [121.05] contains characteristics that identify the source item. ActorBroadcast [121.20] is used for messages that are broadcast from sender to a list of recipients. ArchivedContent [121.25] defines fields that specify where the email's content can be found. For comparison, a type IMConversation [121.50] represents a set of IM messages that have been determined to be part of one conversation. Therefore it is associated with a collection of items and uses the CollectionIdentity [121.10] facet. The set of actors [220] associated with a conversation (in some IM systems conference rooms can be set up which allow for more than 2 participants) is an unstructured list, therefore the ActorPool [121.15] facet is used. The content of the conversation is structured into a hierarchy of exchanges, turns and so on which is represented via the HierarchicalContent [121.30] facet.

[0593] The Cataphora system is deployed in a world with an extremely broad variety of real world data sources and use cases. In the real world, many companies and other environments will have unique types of items. As an example consider an email system such as Lotus Notes, where templates for forms and other custom message types can be added to the system. In such cases, messages that can be handled as conventional email are a just a subset of the traffic carried by the internal, potentially highly customized Lotus Notes system.

[0594] One embodiment of the Cataphora system will have a set of complex computational procedures that will be difficult to implement and change. For all practical purposes these are a fixed set, though they can be changed and updated over time. In order to bridge the gap, these procedures are built to recognize facets of items. The system does not have any intrinsic notion of email, but rather what types of relationships are relevant to a message that is broadcast to a list of recipients.

[0595] The strategy employed to integrate data sources into most embodiments of the Cataphora system is to determine what set of facets best represents each item items are archived external to the hypergraph store [115.22], and an OSF [110] record is created conforming to the set of facet types chosen for each item or event or other object to be represented in the system. An advantage of the OSF [110] formalism as opposed to other formalisms for feature structure types is that it does not require total typing, i.e. an OSF [110] Value can have features and values in addition to those specified by the type of the value. The implication for the system is that we associate a set of types to a value rather than making it an instance of a type per se.

[0596] Since every organizational computing environment is different, most embodiments support the addition of arbitrary new types of evidence sources [108]. An evidence source [108] is defined to be any system which produces regular records that can reliably be linked to one or more actors in the relevant universe. Most valid evidence sources [108] will have a time and date stamp associated with each unique event record that they generate, however some embodiments will support evidence sources [108] that lack this, and instead use indirect means to infer a time and date (such as the arrival of an event between two other events which do have such a timestamp.) Common examples of evidence sources [108] include but are certainly in no way limited to: transactional systems, scheduling systems, HR systems, accounting systems, intelligence monitoring systems, and systems which crawl the web looking for comments in areas of specific interest.

[0597] Each new evidence source [108] represents at least one new dimension in the model; what is really the case is that each distinct type of event does. For example, transactions which are cancelled in a trading system are likely to be considered a different vector than transactions which exceed some externally specified level of risk. In many embodiments therefore, each broad class of event will be considered a vector in a minimal integration, though of course whoever is performing the integration can decide what vectors make sense for their particular purposes if they wish. Most embodiments will also allow non-orthogonal vectors to be expressed because so doing will often add significant value. For example, a marked overall increase in the dimension of emotive tone on the part of an actor may be considered noteworthy in many instances of the system's deployment that such increase is largely the result of a particular topic or is in relation to another specific actor is also often well worth knowing in such cases. While this of course can be set up manually, many embodiments will also automatically perform such combinations whenever it is merited by a statistically uneven distribution of data such as in the example just above. Some such embodiments will generalize and expand the dimensionality of the model based on such empirical observation. Some embodiments may opt to maintain a “virgin” model that factors in no user feedback as a security control.

[0598] This approach is critical to being able to describe a rich, high dimensional model of behavior which allows for even relatively small, subtle changes in behavior to be trapped. Even more importantly, such a model can be defined without any definition of rules, which tend to have a very limiting effect. That is, they look for behavior that is believed to be bad based on some prior incident, rather than having the aim of identifying unexplained changes in behavior that especially when used in conjunction with other types of data or evidence sources [108] can help predict a dangerous incident before it occurs.

Continuous Workflow Analysis

[0599] As described in U.S. Pat. No. 7,143,091, the disclosure of which is incorporated by reference herein, ad hoc workflows are processes [128] that differ from formal processes [128] in at least one of two ways: they are not documented (or not documented thoroughly) as formal workflow processes [128], and they are not subjected to such strict enforcement as formal workflow processes [128], i.e. they can tolerate various kinds of deviations from the expected model, such as missing stages [154], additional stages [154], unusual number of iterations, etc. The present invention expands on this definition to continuously detect the presence of significant workflow processes [128] and to assess how regularly these workflows are performed by various actors [220], which in turn allows detection of anomalies [270] in assessed behavior [205] in that regard.

[0600] More precisely, ad-hoc workflow models are detected during the analysis of the input event stream by the continuous workflow analysis component [465]. In the default embodiment, a new workflow model is built whenever a statistically significant volume of event sequences [166] are identified which conform to a particular pattern, including but not limited to the following types of patterns:

• • [0601] 1. A sequence of documents [162] (including templated documents) of given nature (i.e. document type) and function (i.e. business attributes) appear in the same relative order. For example, a recruitment process in a small or medium business may be characterized by the exchange of candidate resumes, of interviewer feedback following interviews, and of an offer letter—all these events involving actors [220] within the HR department as well as within another specific department.
  • [0602] 2. A sequence of communications [123] or other events [100] involving actors [220] within a given group [225] and have topical and/or pragmatic tagging constraints. For example the development of a service proposal for a customer may not be formalized within the corporation but follow an informal, iterative review process on topic [144] X, with pragmatic tags [172] such as the following: a work product is sent, a work product's reception is acknowledged, agreement or disagreement with some work product, approval or rejection of the final version of the work product, etc.
  • [0603] 3. A combination of any of the previous patterns. For example, transactions in a financial organization involving over-the-counter instruments (i.e. those not traded on a public exchange) tend to follow similar series of steps although these are not strictly formalized or constrained in the daily course of business: back-and-forth negotiation of a deal between a trader and one or more brokers (using any type of communication channel [156]), followed by a confirmation phone call, followed by a back-office operation to record the deal in the bank's database systems, etc.

[0604] In one embodiment of the present disclosure, once a pattern has been detected as significant in the baseline data analyzed for the whole set of actors [220] or a subset of those, the workflow model is built as a higher-order Markov chain whose states are composed of the individual event [100] and item [122] patterns, including but not limited to:

• • [0605] Type of event [100]
  • [0606] Document [162] attributes in the case of the creation, modification, deletion, check-in, check-out, etc. of a document
  • [0607] Topics [144] and pragmatic tags [172] associated to the event [100]
  • [0608] Sender and recipient group [225] when the event [100] is an electronic communication [123]

[0609] These states are augmented with primitives to accommodate the expressiveness of ad-hoc workflow processes [128]:

• • [0610] Fork primitive to represent parallel paths in the workflow
  • [0611] Iteration primitive to represent basic loops in the workflow (where the number of iterations is by default unbounded).
  • [0612] Conditional loops, whereby each iteration step is condition on a predicate being satisfied.

[0613] In another embodiment for better completeness and space efficiency, a probabilistic suffix automaton is used instead of a higher-order Markov chain.

[0614] In either case, as described in the following, the model is trained on a training set defined for example as a group's baseline window of events. In the default embodiment, re-training occurs at regular intervals defined in the system configuration (which, depending on the business domain considered, may be in the order of weeks or months). In another embodiment, a load-balancing component adapts the training frequency so as to find an adequate trade-off between maintaining a recent model and not overload the machines hosting the various components of the processing and analysis layer [402].

[0615] The ad-hoc workflow model thus built is leveraged by the present disclosure in two different ways: anomaly visualization and outlier detection.

Workflow Anomaly Visualization

[0616] Firstly, as described in U.S. Pat. No. 7,519,589, the disclosure of which is incorporated by reference herein for all purposes, the ad-hoc workflow model is visualized so as to very efficiently spot any abnormal information flow or steps in any process, particularly a critical one. Such anomalies include but are not limited to:

• • [0617] Missing stages [154] in the workflow.
  • [0618] Additional, unexpected stages [154] in the workflow (including when the process unexpectedly morphs into several workflows)
  • [0619] Unusual number of iterations in a looping step (for example, for a deal negotiation that usually requires at least 3 rounds of deal terms review, there is never more than a single round when a given sales person is in charge of the deal).
  • [0620] Unexpected time intervals between events [100] (either significantly shorter or significantly longer than the usual delay).

[0621] Anomaly in the workflow structure: for example if a parallel step is supposed to be performed under certain conditions (such as a background check when hiring for an executive position), that parallel step may be bypassed when the conditions are met, or conversely may be unduly performed to eliminate specific candidates from the hiring process.

• • [0622] Anomalies detected outside the workflow process [128], but affecting some of the actors/groups involved in the workflow and within the same time frame: e.g. 2 actors systematically changing their communication patterns at a given step of the process, or an external event that exhibits a strong correlation with the process [128].
    Outlier Workflow Detection

[0623] Secondly, the model is used to detect outlier workflow instances [134]: these are instances [134] that match the informal process [128] definition (because they exhibit the properties previously described in terms of document types, actors [220] and groups [225], topics [144] and pragmatic tags [172], etc.) but have a very low probability of having been generated by the model.

[0624] Using the implementation artifacts described above (higher-order Markov chains and probabilistic suffix automata), this outlier detection mechanism is straightforward as the generation probability is given by the model.

[0625] For example, when the workflow process [128] is modeled by a probabilistic suffix automata, one embodiment of the present disclosure uses the following similarity measures for detecting outliers:

• • [0626] Compute the probability that an input workflow instance [134] has been generated by the model as the product of all transition probabilities and compare this probability to the probability of its being a randomly generated sequence as the product of the distribution probabilities of each state. If the first probability is higher than the second, the workflow instance [134] is flagged as an outlier.
  • [0627] Alternatively, compute the normalized log-probability of the input workflow instance with respect to the workflow model. If this probability is within a given multiple of standard deviations (typically 3) from the average probability of workflow instances [134] within the training set, this instance [134] is flagged as an outlier.

[0628] It should be noted that outliers, as well as anomalies, are defined by assessing the normalcy of an input workflow instance [134] with respect to a model derived from the observation of instances [134] as training set. As is the case for the general case of detecting anomalies by deviation [805], this training set or referential can be defined in a number of ways, including but not limited to the following important definitions:

• • [0629] Instances for the same actor groups [225] at a prior time (peer-group referential, as formalized in the section on Anomaly detection). This allows detection of deviations from an informal workflow process [128] over time within a certain set of individual actors [220] in the organization, as well as specific actors [220] who do not follow the same workflow as the majority of the other actors [220] in the group [225] (for example, it might be interesting to detect actors [220] who are systematically sloppy and skip important stages [154] in a workflow process [128]).
  • [0630] Instances for the exact same actors [220] at a prior time (called baseline referential). This allows the system to detect deviations associated to a particular actor [220]. The benefit of this referential compared to the previous one is that by definition, ad-hoc workflow processes [128] do not impose strict constraints on the sequence of stages [154] that constitute them, and the fact that an actor usually performs a process in a different way from the rest of his peers does not constitute an anomaly [270] by itself but only denotes somewhat different working habits or modes of communication and interaction. However, the fact that the workflow performed by that particular actor [202] exhibits significant and a priori unexplained changes at some point in time, is worth being flagged as unusual by the system.
    Emotive Tone Analysis

[0631] We claim a method and system to identify and analyze occurrences of subjective emotional expression in electronic communication. Human evaluation involves subjective and objective components. If we judge a steak by saying “This steak is prime, by USDA standards”, the judgment is relatively objective. If we judge a steak by saying, “Wow! What a delicious steak!”, subjective elements are in play. Systems of “sentiment analysis” or “opinion mining” (comprehensively surveyed in [Pang 2008], pp. 1-135) typically don't distinguish these different (but sometimes overlapping) forms of evaluation and expression. While they often do recognize a distinction between subjective and objective aspects of appraisal, the relevant notion of subjectivity is decoupled from direct emotional expression. Focusing on direction emotional expression of an individual provides important and useful information about the relation of that individual to events in the immediate environment as well as insight into the relation of that individual to those he or she is communicating with.

[0632] The emotive tone analysis method included in the present invention has the following characteristics:

[0633] It distinguishes emotional expression (subjective component) from appraisal (objective component). Identifying emotional expression depends on a variety of indicators: lexical choice (specific words and phrases, including the interjections and the “responsive cries” studied in [Goffman 1981]), person distinctions (first person (“I”, “me”, “my”, “mine”, “we”, etc.), involvement is especially important), tense distinctions (favoring present tense), syntactic constructions (such as exclamative structures like “What a beautiful day it is!”), modification. Different factors play different roles for different emotions.

[0634] The emotive tone analysis component [435] recognizes a set of basic emotions and cognitive states. These include (among others) anger, surprise, fear, confusion, frustration. These overlap with, but are not coextensive with the set of basic emotions identified and studied by Paul Ekman that are typically communicated not linguistically, but by physiognomic gestures (see [Ekman 2003]).

[0635] Like the emotions signaled physiognomically, these basic emotions are scalar in nature. In the case of physiognomic gestures, greater intensity is indicated by increased magnitude of the gesture. In the case of linguistically communicated emotions, scalar properties are indicated in a variety of ways:

• • [0636] lexically: “livid” is a description of a more extreme range of anger than “angry” (a claim that can be supported by the range of modifiers that occur with the two expressions);
  • [0637] by augmentative modifiers like “very” or “extremely” that indicate an increase in the range of intensity;
  • [0638] by mitigating modifiers like “a bit” or “somewhat” that indicate a diminution or decrease in the range of intensity;
  • [0639] by punctuation or capitalization or other forms of Loud Talking (see that Digital Mirror section)

[0640] In one embodiment of the system, the range of any emotion can be modeled by the emotive tone analysis component [435] as an open interval. Basic individual expressions (“livid”, “angry”, “upset”, etc.) can be associated with a basic sub-interval of such an interval. Modifiers can be interpreted as affecting this range. The basic observation is that initial modification has a greater effect than subsequent modification. For example, the difference between A and B below is greater than the difference between C and D:

[0641] A: “I'm angry.”

[0642] B: “I'm very angry.”

[0643] C: “I'm very very very very very very very very angry.”

[0644] D: “I'm very very very very very very very very very angry.”

[0645] In another embodiment of the system, the range of any emotion can be modeled by the emotive tone analysis component [435] as a partial ordering. The utility of this model is that in a partial ordering, different modes of increasing intensity may not be directly comparable. FIG. 38 shows a simple Hasse diagram (where points higher on the diagram indicate greater intensity) that illustrates two modes of increasing intensity are indicated: capitalization and modification by intensifiers (here, “very”). These two modes are compatible (which forms an upper bound for both in the diagram), but the two modes are not easy to rank subjectively in relative intensity.

[0646] In some cases, there are causal links between specific basic emotions and specific cognitive states. For example, ignorance is a cause of confusion. These causal links can be exploited in both directions: confessions of ignorance can be interpreted as evidence for confusion; expressions of anger may be linked to interesting causal events. (The existence of such stable links is an important reason to study and analyze emotional expression.)

[0647] In the model computed by the emotive tone analysis component [435], emotional intensity varies across individual actors [220], across pairs of actors [220], across events [100], across social groups [225], etc. Measuring intensity (as described above) makes it possible to filter and analyze emotionally expressive communication in various ways. In one implementation, the focus of interest may be the statistical outliers in emotional expression, on the assumption that these occurrences are most likely to correlate with other events of interest.

[0648] The analysis of emotional expression performed by the emotive tone analysis component [435] is compatible without restriction with a wide variety of other analytic methods: topical [144] filtering, actor-based [220] or domain-based filtering, temporal filtering (by interval, by time of day, etc.).

[0649] Finally, the emotive tone analysis component [435] can identify and analyze emotional expression either statically, i.e. on a fixed dataset, when the system is running in batch mode [370] or dynamically, i.e. on a data stream, when the system is running in continuous mode [375]. In continuous mode, the analysis of emotional expression can be carried out not only retrospectively (as in the case of a fixed static dataset), but also prospectively so that future emotionally-involved events may be anticipated.

Pragmatic Tagging

Overview

[0650] The system described in the present invention includes a pragmatic tagging component [430] that will categorize the communicative and discourse properties of individual electronic communications [123]. This pragmatic tagging component [430] is a further development and implementation of the system described in U.S. Pat. No. 7,143,091, the disclosure of which is incorporated by reference herein for all purposes, and is designed to support a variety of functions, including but not limited to the following.

[0651] Workflow analysis: an important feature of electronic communications [123] is how they relate to a workflow processes [128] i.e. the set of corporate tasks associated with normal business. Salient aspects of such communications [123] include requests for information or deliverables, negotiations concerning such requests, status updates, delivery of results, acknowledgment of receipt of information or deliverables, etc., together with a range of communicative information related to the social relations of those communicating (such as positive and negative forms of politeness, including thanks, praise, etc.).

[0652] Discussion building: sets of electronic communications [123] (on any kind of communication channel [156]) typically have various levels of structure, including a first-order structure involving the individual elements of the set, and higher order structures that link first-order structures together in various ways (see, e.g., U.S. Pat. No. 7,143,091 for details). A very simple example is a case in which an email message that ends with a request is linked to a subsequent message acknowledging the request and perhaps fulfilling it. It is possible to postulate hypothetical links between first-order electronic communications [123] based completely on their metadata [140]: what actors [220] are involved, what temporal properties are involved, common properties of subject lines (including indications of forwarding or response added by a mailer or other software application used to format and transfer electronic communications [123]). Pragmatic tags [172] offer a different basis for postulating hypothetical links, one which can be used to strengthen or confirm hypotheses based on other sources of information.

[0653] Lexical analytics: the form of words that individuals use in communicating about a workflow process [128] or topics [144] of mutual interest often reveals attitudes and presumptions that the communicants convey directly or indirectly; access to these overt or implicit attitudes is often useful in assessing motives with regard to the tasks at hand or to other actions or events.

[0654] Relational analytics: linguistic aspects of email communication also convey mutual understanding of the personal and social relations among the participants, including points at which the strength of these relations is tested in some way and points at which such relations undergo significant changes.

Pragmatic Tagging Architecture

[0655] An adequate system of pragmatic tagging requires:

• • [0656] An abstract model of social interaction and social communication;
  • [0657] A set of pragmatic tags [172] that are, on the one hand, interpretable in this abstract model (so that the presence of a particular pragmatic tag [172] provides evidence of the existence of a specific kind of social event or social interaction or social communication) and can, on the other hand, be defined directly by linguistic properties (that is, by the presence of specific expressions or specific syntactic combinations of specific expressions);
  • [0658] A method of analysis of individual electronic communications [123] through which the linguistic reflexes of particular pragmatic tags [172] can be identified.

[0659] In one implementation, such a system can be realized as a cascade of transducers, as illustrated in FIG. 17. For example, an electronic document is passed through a linguistic filter [1700] token by token. Individual words and grammatical constructions (such as inverted sentences of the kind that occur in English yes-no questions or wh-questions) are detected. Each detected instance is replaced by an intermediate tag [1710]; non-matching tokens [116] are disregarded (though in some implementations it may be useful to count them or measure the distance from the onset of a message to the first recognized expression or the distance between recognized expressions). The resulting set of intermediate tags is then analyzed further, with the intermediate tags possibly replaced by a final set of projected tags [1720].

[0660] Transducers of this kind have the property that they preserve the relative order of the input expressions: that is, if tag_i follows tag_k at a given level, then the evidence for tag_i follows the evidence for tag_k at the previous level. This is not a trivial property. If the word “Thanks” appears initially in a communication [123], it serves as an acknowledgment or appreciation of a previous action on the part of the addressee of the communication [123]. If it appears following a request (as in: “Please get back to me with the requested information by 5:00 this afternoon. Thanks.”), it serves to acknowledge a presumptive acceptance of the request it immediately follows. If the relative order of information is not preserved, this distinction is lost. And in the absence of correct order information, the effectiveness of the tagging in linking different messages together correctly would be degraded.

[0661] A further reason to have a cascade of transducers (as in the implementation favored here) involves the complex relation between linguistic form and pragmatic interpretation (in terms of speech acts and dialogue acts). It is well known that speech act or dialogue act interpretation is constrained in important ways by syntactic form. Consider the examples:

[0662] “Pass the salt!”

[0663] “Did you pass me the salt?”

[0664] “You passed me the salt.”

[0665] The first can be used as a command or request. The second two cannot. The second can be used to request information. The first and third cannot. The third can be used to make an assertion. The first and second cannot. But in a variety of more complex cases, the relation between syntactic form and pragmatic interpretation is less straightforward.

[0666] In the cases of commands, for example, we find a hierarchy based on directness and explicitness, very partially represented below:

[0667] “Pass the salt, dammit!”

[0668] “Pass the salt, please.”

[0669] “Could you pass the salt.”

[0670] “Can you please pass the salt.”

[0671] “Do you think you could pass the salt.”

[0672] “Would you mind passing the salt.”

[0673] As many authors have noted, a sentence like “Can you pass the salt?” can be interpreted as a request for information or as a request for salt. (Of course, when “please” is inserted, it can only be a request for salt, not for information.) But as a request, it is less demanding than the explicit “Pass the salt, dammit.” We model this abstractly in the presumptions these speech acts make and the effect they have on the relations of the conversational participants. Theoretically, one would like to appeal to a logic of conversation (to use Grice's terminology) that allows one to derive the associated presumptions and effects from properties of form (the individual components of the expression and its structure) and properties of the context. But for practical purposes, it is enough to recognize and respect the relevant differences: that is, while each of the above sentences can be used to make a request, the requests are themselves organized in a way that reflects a decrease in directness and a concomitant increase in deference to the addressee.

[0674] The same kind of distinction can be made with respect to other basic speech act types. In the case of requests for information, we have a hierarchy similar to the one above:

[0675] “Who won the battle of Alma?”

[0676] “Do you know who won the battle of Alma?”

[0677] “Can you tell me you won the battle of Alma?”

[0678] “Do you happen to know who won the battle of Alma?”

[0679] The last of these represents less of an imposition on the addressee (and thus represents a decrease in potential threat to the addressee's “face”, to use terminology of Goffman adapted by Brown and Levinson.)

[0680] And we have a similar hierarchy for representatives (to use a term of Searle's that covers assertions as a special case):

[0681] “It's raining.”

[0682] “Are you aware that it's raining?”

[0683] “Did I mention that it's raining?”

[0684] “You might want to check whether it's raining.” (Uttered when the speaker knows that its raining.)

[0685] Each of these sentences can be used to inform the addressee or make the addressee aware that it's raining. But like the previous cases, they have different presumptions governing their appropriateness in context and they have different effects on these contexts. For example, in some cases, it is regarded as perhaps more tactful to be more indirect—but this is a way of saying that the possible risk to the social relations between speaker and addressee is playing a more prominent role.

[0686] As mentioned above, there are many possible approaches to such phenomena. At one extreme is an approach which attempts to derive all these effects from first principles. In another implementation, the grammatical system (first-level transducer) is sensitive both to basic properties of syntactic and to a set of sentence-initial operators:

[0687] [Imperative Sentence]

[0688] can you (please) . . . .

[0689] could you (please) . . . .

[0690] do you think you can . . . .

[0691] do you think you could . . . .

[0692] would you mind . . . .

[0693] . . . .

[0694] do you know . . . .

[0695] does anybody know . . . .

[0696] can you tell me . . . .

[0697] can anyone tell me . . . .

[0698] do you happen to know . . . .

[0699] would anyone know . . . .

[0700] Each of these operators is associated with a pair of pragmatic tags [172]: one associates a basic speech act type with the sentence as a whole; the other provides scalar information associated with the pragmatic context—particularly the way the pragmatic interpretation of the sentence bears on the social relations between speaker and addressee.

[0701] A third reason to have a cascade of transducers involves context-dependent information. The study of indirect speech acts has brought out the ambiguity or vagueness of such sentences as “Can you jump over that wall”, and has emphasized the social utility that indirectness involves. Yet context often reveals how the utterance of such a sentence is interpreted by the conversational participants. If the answer to “Can you jump over that wall” is “ok”, the answerer interprets the sentence as a request for a jump. If the answer is “I believe so”, it seems more likely in this case that the speaker interprets the sentence as a request for information, not action. It is simpler to resolve the vagueness or ambiguity of this question at an intermediate level than at the lowest level.

[0702] A fourth reason to have a cascade of transducers, related to the third, involves the fact that information in dialogue is typically distributed across different dialogue acts (or “dialogue turns”). A central example of this involves questions and their answers. From a question like “Did you receive the documents?”, one cannot infer that the addressee either received the documents in question or did not receive the documents in question. Suppose the answer is “Yes, I did”. From this elliptical sentence, one can also not in general infer that the speaker either received the documents or did not receive the documents. But suppose the utterances of these two sentences are appropriately coupled in dialogue (or similar electronic communication [123]), as below:

A: “Did you receive the documents?”

B: “Yes, I did.”

[0703] This structured dialogue supports the inference that B received the documents in question (assuming such things as that B is trustworthy). This inference process is enhanced by one or more intermediate levels of representation. To consider the nature of these levels of representation, it is useful to examine in more detail the nature of questions and their answers.

[0704] Our system employs a novel framework for the analysis of question/answer dialogue structures. This system analyzes the overall problem into a set of cases, with each case being associated with a variety of linguistic forms (on the one hand) and with a set of inference-supporting properties (on the other). (For brevity, we focus here on direct yes/no questions.)

[0705] Case 1. The answer completely resolves the question.

[0706] Question: “Did you receive the documents?”

[0707] Complete answers: “Yes”/“No”/“Absolutely”/“Not at all”/ . . . .

[0708] Case 2. The answer resolves a more general question or a more particular question.

[0709] Question: “Did you receive the documents?”

[0710] Answer to a narrower question: “Not from Jonathan”

[0711] Question: “Did you receive the documents?”

[0712] Answer to a broader question: “And not just the documents.”

[0713] Question: “Did you receive the documents?”

[0714] Answer to a broader question: “Not yet.”

[0715] [provides more information than a simple “no”]

[0716] Case 3. Answerer responds with information about what he/she knows about the situation:

[0717] Question: “Did you receive the documents?”

[0718] Answer: “I don't know. I haven't checked my mail yet today.”

[0719] Question: “Did you receive the documents?”

[0720] Answer: “Not that I know of.”

[0721] Case 4. Answerer cannot resolve the question, but can address the possibility of a positive or a negative answer:

[0722] Question: “Did you receive the documents?”

[0723] Answer: “Possibly: I haven't checked my mail today.”

[0724] Question: “Does 9 divide 333?”

[0725] Answer: “Well, 3 divides 333 . . . ” (implicates that the speaker doesn't know (other things being equal), but that the answer is still possibly positive).

[0726] Case 5. Answerer cannot resolve the question, but can assess the probability of a positive or a negative answer

[0727] Question. “Did you receive the documents?”

[0728] Answer: “They're probably in my mailbox.”

[0729] (As used here, “possibility” involves what set of situations are relevant to the event space; “probability” involves an association of a scalar (or something like a scalar) with an element of the event space.)

An Abstract Workflow Model.

[0730] We model workflow and other social interaction both abstractly and (in specific implementations) concretely.

[0731] At the abstract level, for each relevant pair of actors [220] (or groups of actors [225], when the group plays the role of an individual), we recognize different types of relations holding between them (personal relations, familial relations, professional relations of different kinds). For example, it is not unknown for a doctor or a professor to have personal relations with a patient or a student. (A special role is played by the notion of a possibly distinguished personality [230] associated with a specific electronic alias [240]. The set of relations posited here is the counterpart of this notion at the level of personal interaction.)

[0732] For each relevant pair and each posited relation holding between them, we may associate a shared agenda: a mutually recognized set of tasks or obligations or benefits that they are mutually committed to; in addition, each member A of a relevant pair {A,B} may be associated with a private agenda—not shared and not necessarily mutually committed to—which directs, governs, or constraints actions and responses by A toward B.

[0733] Particular agenda items will in general have many specific particular properties. Items on the agenda may range from very general requirements (“share amusing pieces of information”) to very specific tasks (“read and sign the 10-K form by tomorrow at noon”), and these vary greatly across different kinds of social relations. One of the virtues of abstraction is that these particulars may be ignored in modeling properties of the postulated agenda. The basic questions are:

• • [0734] How does a task get added to an agenda?
  • [0735] How does a task get removed from an agenda?

[0736] These basic questions generate a variety of subsidiary questions which may or may not arise in specific circumstances:

• • [0737] How are the specifications of a task negotiated in advance?
  • [0738] How is the addition of a task acknowledged by the parties concerned?
  • [0739] What intermediate status reports are involved and how are they initiated and responded to?
  • [0740] How is the completion/abandonment of a task communicated and acknowledged, so that the task is no longer regarded as part of the mutual agenda?

[0741] This abstract workflow model corresponds to a simple finite state machine, illustrated in FIG. 18. The required flow through this machine is from an initial state representing a new task [1800] through an intermediate required state representing the addition of a task to the agenda [1810] to a final state representing the removal of the task from the agenda [1830].

[0742] All the subsidiary questions of the kind just discussed above correspond to loops around task request [1810], task acceptance [1820], or task completion [1830]. The loops around task request [1810] correspond to negotiations concerning the nature of the task. The loops around task acceptance [1820] correspond to communications [123] among the participants during the period that task is mutually recognized but not discharged. Loops around task completion [1830] correspond to acknowledgments and thanks and other later assessments.

[0743] A specific task can fall off the agenda in more than way, including but not limited to:

• • [0744] The task can be satisfactorily completed;
  • [0745] The task can be abandoned or die off (via a sunset clause, or . . . )

[0746] In some embodiments, the model of generic tasks (such as marriage vows) may never reach task acceptance [1820] or may involve linking sub-models representing the agendas of individual members of a pair. Mutually dependent situations of this kind may be modeled to a first approximation by finite state transducers (like a FSA, but with arcs labeled by pairs), where the first element of any pair represents the cause of the transition, and the second represents the value to one or the other party.

Actor Influence Analysis

[0747] This behavioral modeling component [445] allows the system to compute several measures of influence for a particular actor [220] by assessing the changes in behavior [205] of people around that actor [220] before, during, after a significant absence of some kind, both in terms of how completely their behavior returns to the norm after that period, and how quickly it does so.

[0748] In general, measuring the individual behavior [210] and collective behavior [215] of people around an actor [220] both before and after a period of absence or lack of interaction with the rest of the network is a very insightful measure of that actor's [220] influence level, because if the person is important enough then the behavior of the network will snap back to its prior behavior quickly—and completely—once the person has returned. Conversely, if the person's influence was fragile or not shared by the majority of people interacting with her, not only will the behavior in her neighborhood take much longer to go back to normal, but the new norm will also be significantly different from the former baseline behavior [260], with new connections created to third-parties, more erratic communication patterns, etc.

[0749] A period of absence can be due to whether vacation, business travel that causes the person to be largely out of touch, dealing with family issues, etc. In one embodiment these periods of absence are derived using a number of methods including but not limited to:

• • [0750] Data pulled from HR systems
  • [0751] Automatic out-of-the-office email replies
  • [0752] Detection of inactivity periods, for example using the very common statistical criterion that the number of events [100] originating from the actor is below the average over the baseline by at least k standard deviations, typically with k=3.

[0753] Every time a period of absence or inactivity has been detected, the system computes a divergence on the distribution of per-actor activities between a baseline period P₁ (e.g. sliding window of 1 year) and a period P₂ of inactivity (typically a small number of weeks) for the actor [220] which will be referred to as the subject in the following. The distributions are computed over all actors [220] having significantly interacted with the subject in one of these periods. Both for P₁ and P₂: we prune the elements in which the subject is involved (for P₂ this is to get rid of the residual activity, such as a long-running discussion [136] that was started in the presence of the subject). Pruning is done either by only removing individual events [100] involving the subject, or by removing all discussions [136] containing at least one such event [100].

[0754] Furthermore, any divergence metric can be used. In one embodiment the K−L divergence H(P₁, P₂)−H(P₁) is used where H refers to the entropy of a distribution. In another embodiment the system uses the variation of information H(P₁)+H(P₂)−2I(P₁, P₂) where I(P₁, P₂) is the mutual information between P₁ and P₂. The divergence measured by this method constitutes an assessment of how the absence of the subject impacts her environment and her closest professional or social contacts.

[0755] The activity model used in this method is also entirely configurable. Activities taken into account in the default embodiment cover all types of communication channels [156], from which the system derives events [104] that are either individual communications [123] (i.e. random variables taking values such as “A emails B” or “A calls B”) or entire discussions [136] (i.e. random variables taking a value such as “A emails B,C; B emails A”).

[0756] An additional, closely related assessment of the subject's influence takes P₁ to be the period of inactivity and P₂ to be the same-duration period following the actor's return: by comparing it to the baseline behavior [260], this gives an indication of how completely and quickly the environment returns to normal. This is called the snapback effect exerted by the subject on the rest of the network. When taken together, these two metrics evaluate the importance of the subject: how badly others miss her when she is away, and how easily others get over her instead of returning to normal behavior once she is back.

[0757] Also, when evaluating influence, actors [220] such as managers whose sign-off is necessary to approve certain actions and events are excluded from consideration by the system. This is because such actors [220] will by definition impact the behavior of people reporting to them, without that causal relationship bearing any implication on their actual level of influence.

Detecting Textblocks Via N-Gram Transition Graphs

[0758] Textblocks are defined in U.S. Pat. No. 7,143,091: “Textblocks consist of the maximum contiguous sequence of sentences or sentence fragments which can be attributed to a single author. In certain cases, especially emails, a different author may interpose responses in the midst of a textblock. However, the textblock retains its core identity for as long as it remains recognizable.”

[0759] A method is also given there for detecting textblocks. That method has certain limitations in terms of both recall and memory footprint. The method described here is superior in both respects (see FIG. 19). This method is also amenable to continuous computation and hence provides the preferred embodiment for the textblock detection component [470]. The idea of this method is to find collections of text fragments in different text-containing items [122] which are similar enough to infer that they were duplicated from a single original item [122], and hence have a single author. We shall distinguish between an abstraction of such a collection of fragments, which we shall call a textblock pattern [124], and a particular fragment of text in a particular item, which we shall call a textblock hit [130].

[0760] We begin by constructing a graph of n-gram [118] transitions within the universe of items [122] (see FIG. 20), also called a textblock graph [160]. For each item [122], examine its text one token [116] at a time. Form n-grams [118] of successive tokens [116] for some value of n that will remain constant throughout and which is small compared to the size of a typical item [122]. Successive n-grams [118] may overlap. For example, in the text “one two three four five”, the 2-grams would be “one, two”, “two, three”, “three, four”, and “four, five”. Keep a sliding window of size k over the successive n-grams [118]. This window will initially contain the first k n-grams [118] in the document [162]. At each step, the window will be moved forward so that the first n-gram [118] in the window will be removed and the next n-gram [118] in the document [162] will be added to the end of the window.

[0761] We will produce a graph of transitions between n-grams [118] in this sliding window. Begin with an empty graph. Add each of the k n-grams [118] initially in the window as vertices to the graph. For each of the k*(k−1)/2 pairs of n-grams [118] in the sliding window, add a directed edge with weight 1 between the corresponding vertices, with the head corresponding to the n-gram [118] appearing first in the window, and the tail corresponding to the latter n-gram [118].

[0762] Each time the sliding window moves forward, an n-gram [118] is added to it. Add this n-gram [118] as a vertex to the graph if it was not already there. For each of the up to k−1 other n-grams [118] in the window, do a look-up for a directed, weighted edge in the graph pointing from that n-gram [118] to the one that was just added. If such an edge did not exist, add it to the graph and give it a weight of 1. If such an edge did exist, increase its weight by 1. In the example given above, if k=3, we would create, or increment the weight of, the following edges:

“one, two”→“two, three”

“one, two”→“three, four”

“two, three”→“three, four”

“two, three”→“four, five”

“three, four”→“four, five”

[0763] Continue in this way for each item [122] in the universe of items [122]. Textblock patterns [124] consist of tokens [116] that are used in roughly the same sequence over and over again, with some modification. This means that their n-grams [118] will be used in roughly the same order. To the extent that these n-grams [118] are not commonly used in other contexts, we expect to see a particular pattern in the local environment of each such n-gram [118] within the graph.

[0764] Consider the neighborhood N of an n-gram [118] p. That is. N contains all vertices which are connected to p by edges, as well as p itself. Let M be the maximum number of directed edges possible with both head and tail in N, excluding loops. Then M=|N|*(|N|−1), where |N| is the size of N. For each pair of vertices q and r in N, let w(q, r) be defined as:

w(q, r)=weight of the edge from q to r, if such an edge exists

w(q, r)=0, otherwise

Let W be max(w(q,r)) for all q, r in N. Define the local clusterability of p, LC(p), to be (see FIG. 25);

LC(p)=(sum of w(q, r) over all q, r in N)/(M*W)

[0765] LC(p) provides a measure of how evenly interconnected the neighborhood of p is, and as such is key to this algorithm for detecting textblocks. Now consider a relatively unique sequence of terms, such that its n-grams [118] are found within the universe of items [122] only within this sequence (although the sequence may be repeated in its entirety many times within the universe). Consider an n-gram [118] P that appears in the middle of this sequence. Then we expect that n-gram [118] P to be connected in the graph we are making to the k−1 n-grams [118] before it, and to the k−1 n-grams [118] after of it, and nothing else. N contains all the neighbors of P plus P itself, so |N|=2(k−1)+1=2k−1, and M=(2k−1)*(2k−2). All edges in N will have the same weight, so w(q, r)=W for any q, r in N such that q and r share an edge, and 0 otherwise.

[0766] Now consider how many edges there will be in N. The edges that are within N (i.e. both the head and tail of the edges are in N) are precisely those created by the k positions of the sliding window such that the window contains P. As the sliding window moves along, P goes from being the last item [122] in the window to being the first. In the window's first such position, every n-gram [118] is connected by one edge to every other, so this window contains k*(k−1)/2 edges. Whenever the window moves forward, a new n-gram [118] is added and is connected to every n-gram [118] before it in the window by one edge, so this adds k−1 more edges (all other edges in this window were already present in the previous window). The window moves forward k−1 times (once for each of the k positions under consideration except the initial position), so the total number of edges in N is k*(k−1)/2+(k−1)². Thus:

[0767] $\begin{array}{c}\mathrm{LC}\left(P\right)=W*\left[k*\left(k-1\right)/2+{\left(k-1\right)}^2\right]/\left[\left(2k-1\right)*\left(2k-2\right)*W\right]\\ =\left[k*\left(k-1\right)/2+{\left(k-1\right)}^2\right]/\left[\left(2k-1\right)*\left(2k-2\right)\right]\end{array}$
So the expected local clusterability depends only on the size of the sliding window.

[0768] The sequence of tokens [116] we have considered is a type of textblock-exactly the same sequence of tokens, which form n-grams [118] that are not used anyplace else. In practice, we are interested in finding cases where the sequence is sometimes different, additional tokens [116] are added or removed, and/or tokens [116] are re-ordered. In this case the graph connecting tokens [116] in the textblock will look similar to what we have considered, but the edges will not all have exactly the same weight, and there may be additional edges with low weights. This will affect local clusterability by an amount roughly proportional to how large such changes are. Likewise, an n-gram [118] in a textblock may appear in more than one context within the universe of items [122]. If it only appears once within the textblock pattern [124] and appears in that pattern much more often than in other contexts, its local clusterability will be close to the expected value calculated above. Thus, most n-grams [118] within the textblock will have LC close to the expected value.

[0769] We obtain textblock patterns [124] from the transition graph [160] as follows (see FIG. 21). Examine the vertices of the graph [160] one at a time. For each vertex, compute its local clusterability. If this value differs from the expected value by less than some pre-chosen threshold ε, mark the vertex as a textblock-vertex. When this is done, remove any vertices that are not textblock-vertices. Now find and label the connected components within the remaining graph [160]. Each of these connected components represents a textblock pattern [124].

[0770] The most time-consuming part of this algorithm is the local clusterability calculation. Because it may require comparing every pair of items [122] in a neighborhood N, it's running time may be O(|N|²). Since this must be done for every vertex, the running time of this calculation would be O(n³), where n is the number of vertices in the graph [160], if the graph [160] were nearly completely connected. (However, in common natural language prose, few n-grams [118] will be this highly connected.) In one embodiment, the algorithm handles this problem by not considering vertices for which |N| is greater than some pre-chosen threshold. The most connected n-grams [118] are unlikely to be useful in detecting textblocks, so this has little effect on the accuracy of this method. The rest of the algorithm described so far runs in time that grows linearly with the total summed length of the items in the universe, provided that all graph look-up and modification steps run in constant time. This is possible if the graph [160] is small enough to fit in constant-access memory.

[0771] This method for finding patterns has two phases-a first phase in which the transition graph [160] is built, and a second phase in which the transition graph [160] is pruned and connected components and identified. The first phase considers only one item [122] at a time and hence can be performed against a pseudo-infinite stream of text-containing items [122] in a continuous monitoring context. The second phase cannot. In one embodiment, the graph [160] is periodically cloned so that a separate process can perform the second phase and update the set of textblock patterns [124]. While this pruning occurs, the original process can continue to add new incoming items [122] to the graph [160]. In a second embodiment, textblock patterns [124] are detected within overlapping time periods. For instance, textblock patterns [124] might be detected within bins of two months each, with each bin overlapping the bin after it by one month. In a third embodiment, patterns [124] are kept for some pre-determined amount of time and then discarded. In a fourth embodiment, patterns are discarded after some amount of time following when the most recent hit for that pattern was detected.

[0772] We find textblock hits [130] for textblock patterns [124] in an item [122] as follows (see FIG. 22). Begin by creating an initially empty lookup-table “CountMap”. This table will have as keys the IDs of textblock patterns [124] currently being considered as potential matches, and maps each such ID “A” to a tuple CountMap(A)=[a, b, c], where “a” is the number of edges found which might be in “A,” “b” is the number of non-matching edges, and “c” is the number of trailing non-matching edges. Now proceed in a manner similar to that used to find the patterns [124]. Examine the tokens [116] of the item [122] in order. Run a sliding window of size k over the resulting n-grams [118], using the same values of n and k used to find the patterns [124]. For each transition edge E, do a lookup in the graph [160] to determine if the edge is part of a pattern [124]. If the edge is found in the graph [160] and has pattern [124] ID A, and if there is no current entry CountMap(A), then set CountMap(A)=[1, 0, 0]. If CountMap(A) already has a value [a, b, c], increment a by 1 and set c to 0 For every pattern [124] ID X in CountMap where X does not equal A (or, if the edge E was not in a pattern [124], then for every pattern ID in CountMap), look up CountMap(X)=[a, b, c]. First increment both b and c each by 1, then decide whether to drop this pattern [124] from consideration. In one embodiment, we drop from consideration any pattern [124] for which c is above a pre-set threshold. Whenever a pattern [124] drops from consideration, first determine whether the edges found so far constitute a hit [130], then remove the entry for that pattern [124] from CountMap. Likewise, when the end of the item [122] is found, consider whether the edges found so far constitute a match for each value in CountMap, then clear CountMap. In another embodiment, we determine whether edges found constitute a hit [130] using pre-chosen thresholds for recall (were enough edges from the pattern [124] found in the item [122]?) and precision (were enough of the edges from the item [122] in the pattern [124]?).

[0773] A hit [130] found in this manner will not constitute an entire textblock under the definition given above, but rather will constitute a portion of a textblock. In general, textblocks may be broken into pieces by n-grams [118] that are used in many contexts, or by the presence of even smaller segments which are also repeated by themselves. Also, at the beginning and end of the textblock n-grams [118] may not have the clusterability predicted here. But once we have found a set of items [122] containing hits [130] of a common textblock pattern [124], we can expand the hits [130] using standard methods for inexact string matching which would not be feasible on the entire universe. These methods may include dynamic programming or suffix tree construction.

[0774] It should be obvious to a practitioner skilled in the art that, assuming the computer running this algorithm has sufficient constant-access memory to allow constant time look-ups in the transition graph [160], the hit [130] finding algorithm will run in time linear in the length of the text of the item [122] so examined. Hence, finding hits [130] in the universe of items will run in time linear to the total length of all items [122] in the universe.

[0775] As the method for finding textblock hits [130] considers only one text-containing item [122] at a time and compares it against a static graph, it can be used in a continuous monitoring context against a pseudo-infinite stream of items [122].

Improvements

[0776] The textblock pattern [124] detection portion of this method will run poorly if the transition graph [160] is so large that it cannot be held in constant-access memory. In some embodiments, only a subset of transitions will be recorded as edges so as to reduce the total size of the graph [160]. In one embodiment a list of functional words appropriate to the language of the text is used (see FIG. 26). In English, for example, prepositions, articles, and pronouns might be used. Only n-grams [118] immediately following such functional words are placed in the sliding window. In another embodiment, the full list of n-grams [118] is produced, but is then reduced to a smaller list using a winnowing method similar to that described in [Schleimer 2003] (see FIG. 27). N-grams [118] are hashed and the hashes are placed in a sliding window. The smallest hash at any given time will be noted, and the n-gram [118] it came from will be placed in the derived list. If, for a given window position, the n-gram [118] with the smallest hash is the same as it was in the last window position, then it is not added again. From the derived list, transitions will be recorded as edges.

[0777] A modification of this algorithm will perform well even when the transition graph [160] is too large to fit in random-access memory (see FIG. 23). Proceed as before, but place a maximum size on how large the transition graph [160] is allowed to grow. In one embodiment, when the graph [160] reaches this size, the entire graph [160] is written to disk (or some other slower portion of the memory hierarchy) and the constant-access memory structure is emptied. In another embodiment, vertices in the graph [160] are held in memory in a Least-Recently Used (LRU) cache. When a vertex is ejected from the cache, edges within its neighborhood are written to disk (or other form of slower memory) and then purged from constant-access memory. In any embodiment the portion written to disk (or slower memory) is recorded as ordered triples of n-grams [118] connected by edges. For example, in the text “one two three four five”, using 1-grams we would record:

“one, two, three”

“one, two, four”

“one, two, five”

“one, three, four”

“one, three, five”

“one, four, five”

“two, three, four”

“two, three, five”

“two, four, five”

“three, four, five”

[0778] These ordered triples are written to a file or similar storage structure, one per line: followed by a weight, which will initially be one. Periodically, this file can be compressed. To do so, sort the file. Lines containing the same triplet will now be adjacent. In another pass over the file, replace n lines containing the same triplet with 1 line containing their summed total weight. This process can be parallelized by having multiple processors or different computers examine different sets of items [122], where such items [122] partition the universe of items [122], and each processor will write to its own file. When this process is done, the various files can be joined using the merge-sort algorithm, and lines containing the same triplet can be combined. Sorting and merging files on disk is a well-studied problem, and can generally be done in running time that is O(n*log(n)), where n is the total length of the files involved. Hence, the entire process so far will run in time O(n*log(n)), where n is the total length of all items [122] in the universe.

[0779] Once the final list has been created, iterate over it from the beginning. Because the list is sorted, for any n-gram [118] P, all lines containing P in the first position will be adjacent in the list. Thus we can reconstruct the approximate neighborhood of each vertex, and calculate its local clusterability, one vertex at a time, without ever holding more than one neighborhood in constant-access memory at a time, and without doing random-access disk lookups. Some information about a neighborhood may be lost because P's neighbors are found adjacent in a window in which P itself is not found, but in general this will not unduly affect the results.

Information Dissemination Profiles

[0780] The system creates and continuously maintains content re-use profiles that characterize the extent to which individual actors [220] produce a certain category of information, how they modify such information, and how they consume it.

[0781] Valuable information can be defined in any number of ways. In the default embodiment, valuable content is generally defined as the result of filtering all items [122] collected and processed by ontology classifiers [150] associated to business-relevant topics [144]. Alternatively and in a more specific corporate application scenario within a corporate environment, valuable content is defined as intellectual property assets such as research artifacts or software code.

[0782] The system relies on continuous textblock detection as described in this invention. Two libraries of textblocks are maintained: a global library of textblocks and a library of recently disseminated textblocks.

[0783] To build and maintain the global library of textblocks, the algorithm described previously is run over a large dataset, such as all historical valuable data or all valuable data in the past n years. Once the textblock patterns [124] have been discovered, all textblock hits [130] (which represent usage of that content) are scanned and sorted by date, then used as the basis for building content-relaying events. Each content-relaying event is a (Textblock pattern, Date, Sender, Recipient) tuple. One such tuple is created for each (Sender, Recipient) pair associated to the item [122] in which the textblock hit [130] was found—by definition there can be one or more such pairs per item [122]. The date of a content re-use event is defined as the representative date of the item [122] in which the textblock hit [130] occurs. In one embodiment of the present disclosure, the representative date is the sent date of an electronic communication [123] (such as an email message or an IM turn), the last modification date of an item [122] collected from a file (or from a database table), etc.

[0784] The system will then compute scores, called create-score, consume-score, and relay-score, for each actor [220]. In addition, a list of all received textblock patterns [124] is maintained for each actor [220]. To do this, it scans all content re-use events in date-ascending order.

[0785] The first time a given textblock pattern [124] is encountered during this scan, the create-score of the sender is updated. In one embodiment of the present disclosure, this update consists of a unit increment of the create-score. In another embodiment, it is an increasing function of the textblock pattern [124] length. In yet another embodiment, it is a decreasing function of the number of textblock hits [130] found for the pattern [124] throughout the whole dataset.

[0786] For every re-use event, the receive-score of the recipient is updated (the update function is similar to the update of the send-score described previously), the textblock pattern [124] is added to the list of received patterns [124] for the recipient if it was not already present, and if the textblock pattern [124] belonged to the list of received patterns [124] for the sender then the sender's relay-score is updated. In one embodiment of the present disclosure, the update of the relay-score consists of a unit increment. In another embodiment, it is proportional to the ratio of the textblock hit [130] length over the textblock pattern [124] length. In a third embodiment, the list of received patterns [124] is augmented to keep track of the token [116] range of each received pattern [124] that has also been relayed, and the update consists of adding the ratio of the textblock pattern [124] length that was not covered (in other words, this differs from the previous embodiment in that information relayed multiple times is only counted once).

[0787] The present invention is not restricted to a specific dissemination profile calculation method. In the default embodiment of the system, the scores defined above simply measure the level and type of interaction among actors [220] by counting items exchanged through communication channels [156] or loose documents [162]. In another embodiment, they also take into account how often that content is being viewed, downloaded or copied, and, by contrast, which content is simply ignored. The resulting profiles are much more accurate and more difficult to game than simple counts in large enterprise networks, where actors [220] who tend to send superfluous content in large quantities are often not contributing to the overall productivity of that organization. In yet another embodiment, scores are also a function of the actual roles and responsibilities of actors [220] as derived from example from their involvement in discussions [136] that represent workflow processes [128], including but not limited to how often they initiate, close, or contribute to discussions [136], whether they are decision-makers (as defined by the measure of that trait [295] in the behavioral model [200]), whether they review work products, etc.

[0788] Possible enterprise application scenarios of information dissemination profiling include but are not limited to.

• • [0789] Determination of who to promote, who to demote, or lay off;
  • [0790] Assessment of the impact of an organizational change, such as a merger or acquisition or a major restructuring;
  • [0791] More generally, the rewarding of employees who are collaborative, and who focus on what is good for the overall organization rather than for their own promotion or their particular business unit.

[0792] Finally, the system ranks each actor [220] along a number of information dissemination profiles based on the scores [285] that have just been computed. In one embodiment of the present disclosure, information dissemination profiles are:

• • [0793] Creator, which represents an actor's [220] tendency to create valuable content, i.e. content that is re-used by others in meaningful ways;
  • [0794] Curator, which indicates to what extent the actor [220] spots valuable information then relays part or all of it across the network, potentially modifying it along the way:
  • [0795] Consumer, which quantifies the volume of valuable information which is simply received by the actor [220].

[0796] The ranking [275] mechanism can be configured by the user. By default, actors 1220 are ranked as follows: creators are ranked by decreasing their sender-score, consumers are ranked by decreasing their receive-score, and curators are ranked by decreasing their relay-score.

[0797] Once the system has been initialized by building the global library of textblocks, it starts maintaining a library of recently disseminated textblocks, which allows analysis of trends in dissemination behaviors.

[0798] In one embodiment of the invention, a library of recently disseminated textblocks is built at regular intervals (for example, on a monthly basis). The list of content re-use events is computed similarly to the global library construction, except that the create-score of the sender of a re-use event is updated only when the textblock pattern [124] is encountered for the first time in this scan and it is not present in the global library. If either condition is not satisfied, then the sender's relay-score is updated as in the global library construction. The result of this scan over re-use events is a ranking of actors [220] on the corresponding time period.

[0799] FIG. 28 shows a graph visualization of information dissemination profiles provided by the system.

[0800] This visualization shows actors [220] as nodes in the graph, and dissemination relationships as edges. The identity [2820] (potentially anonymized depending on the anonymization scheme [340] in place) of the actor [220] decorates each node. Around a given actor [220], zero, one or more annuli [2800] (also called donuts) are drawn to represent that actor's [220] dissemination profiles computed as previously described. Some nodes, such as [2820], do not have any circle because they do not significantly contribute to dissemination of information deemed as valuable in the particular context of that visualization (i.e. they are not involved in items [122] filtered during input data selection [360]).

[0801] The width of annuli [2800] (i.e. the difference between their external and internal radii) drawn around an actor denotes the relative amount of information respectively produced, received, or relayed.

[0802] Color codes are used to distinguish profiles. In the default embodiment, blue circles indicate creators [2805], green circles indicate curators [2810], and red circles indicate consumers [2815]. In addition, a saturation level is used as a visual indicator of the content's value or relevance: the darker the color, the more valuable the information created, relayed, or consumed. This provides an additional dimension to the dissemination profile established by the system. For example, the darker the blue circle around an actor [220], the more likely that actor [220] is to be a thought leader; the darker a green circle around an actor [220], the more actively that actor [220] is contributing to spreading knowledge or expertise throughout the organization.

[0803] Optionally, valuable information can be further categorized by the system using any type of categorization component [146]. In an intelligence application scenario for example, a set of categories would be classification levels, thus adding another dimension to the visualization. Each annulus [2800] is split into one or more annular sectors [2825], with the angle of a sector proportional to the relative volume of the corresponding category found in that actor's [220] dissemination profile. For instance in FIG. 27, the actor identified as “actor 13” creates significant volumes of information categorized as A or B [2825] in roughly equal proportions, but produces comparatively little if any information categorized as C.

[0804] The evolution of rankings [275] over time can also be visualized in an animated variant of the graph of information dissemination profiles graph described previously.

Behavioral Profiles

[0805] The behavioral modeling component [445] leverages the output of the other components in the processing and analysis layer [402] to establish a behavioral model [200] which is the core model from which a behavioral norm is determined and anomalies are detected by the anomaly detection component [450] based among other things on deviations from that norm.

[0806] To build that behavioral model [200], the present disclosure defines the concept of an individual behavior profile, which can be used for different purposes, including but not limited to the following.

[0807] First, an individual behavior profile is useful in and of itself to show a behavioral portrait of the person (whether a snapshot of assessed behavior [205] over a recent period of time, or a baseline behavior [260] computed over a decade), while letting a human analyst derive any conclusions on his own. For example, certain organizations may want to investigate any actor [220] who has been deemed to possess an inflated ego and also appears to exhibit a low level of satisfaction with respect to his job.

[0808] Second, an individual behavior [210] can be leveraged to analyze changes over time in the individual's behavior, in order to derive a level of associated risk or alternatively to produce anomalies [270] that should be investigated further. For example, someone who isolates himself from the rest of the organization (whether socially, professionally, or in both respects) over a period of time has a situation worth investigating.

[0809] Third, an individual behavior [210] can be used to contrast the individual's behavior with her peers' behavior in order to yield another kind of assessment of anomalous behavior as with changes over time. For example, someone whose level of stress increases considerably more than his co-workers' stress is a significant anomaly, much more so than a collective increase in stress levels which might be imputable to internal tensions and difficulties or to exogenous circumstances.

Personality Archetypes

[0810] The primary function accomplished by the construction and maintenance of the behavioral model [200] in the present invention is to map each important actor [220] in the electronic dataset to one or more individual personality types. Note that these personality types can also be called archetypes since they are a necessarily simplified model of any real human personality, in that the more complex traits have been omitted while emphasizing other traits more relevant to the particular scenario, for example psychopathological traits.

[0811] An actor [220] that matches at least one of these archetypes would typically be flagged for investigation if for example the corresponding archetype(s) suggest a level of present or future insider threat, where an insider threat is defined as a series of malevolent or unintentional actions by a person trusted by the organization with access to sensitive or valuable information and/or assets.

[0812] In particular, the behavioral model [200] can provide evidence suggesting that the individual in question is a malicious insider. This covers three main types of situations described below, each of which presents a significant threat to the organization if it goes undetected until irreversible malicious acts are committed, unless a system such as the one described in this invention flags those individuals by raising alerts [305] based on the established behavioral model [200].

• • [0813] A first type of malicious insider is an individual starting to work for the organization with the intention of committing malicious actions, but undetected until now.
  • [0814] A second type of malicious insider is an individual starting with good intentions, being turned around by another individual or another organization for a variety of reasons (typically a mixture of greed, ideology, and other internal or external conflicts)
  • [0815] A third type of malicious insider that the behavioral model [200] helps to detect is an individual with psychopathological tendencies or other predispositions to commit such malicious acts in the future. Such an individual may have been allowed to enter the organization because he or she was not filtered out in the initial recruiting process, or who developed those tendencies later.

[0816] The set of personality archetypes is completely configurable, to allow for either a very generally applicable model of human personality, or a custom model more targeted toward a specific organization.

[0817] In one embodiment, the set of personality archetypes represents the Big Five factors, which are a scientifically validated definition of human personality along five broad domains: Extraversion, Agreeableness, Conscientiousness. Neuroticism, and Openness. The advantage of such a generic model, besides lending itself to cross-validation of results produced by the present invention and by another personality assessment scheme, is that it does not assume a unique categorical attribute to define an individual personality, since the Big Five factors are modeled as 5 numerical features (generally expressed as a percentile value). Thus for example, by selecting the two factors Neuroticism and Agreeableness, the system provides a picture of actors [220] prone to anger control issues.

[0818] In another embodiment, the set of personality archetypes is defined to represent the main behavioral risk factors present in any business organization, and are as follows:

• • [0819] Personal dissatisfaction: this essentially consists of self-esteem issues, such as the actor [220] not living in harmony with reality and experiencing conflicts about himself or herself intrinsically (as opposed for instance to physical appearance)
  • [0820] Professional dissatisfaction: this archetype is similar to personal satisfaction issues but pertains to the actor's [220] Job and overall work life as opposed to her personal life
  • [0821] Negativity: this archetype corresponds to the actor [220] expressing repeatedly high levels of negative sentiment and showing durable signs of physical, mental, or emotional tension
  • [0822] Sociability issues: this archetype corresponds to the actor [220] avoiding almost any interaction (or interacting very poorly) with other individual actors [220] or groups [225], thereby establishing no personal relationships or failing to sustain them.
    Behavioral Traits

[0823] The behavioral model [200] involved in the present invention relies on the assessment of the presence and intensity of a number of behavioral and personality traits [295] for every individual actor [220] or group [225] for which a sufficient volume of data has been processed and analyzed. Each personality type—or archetype—as described previously is then detectable by the presence of behavior traits that are associated to such a personality. In the default embodiment of the invention, each behavioral trait is associated to a positive or negative correlation with each archetype based on empirical and/or theoretical data: for example, when using the Big Five factors as personality archetypes, undervaluation is a behavioral trait that is measured by the system as positively correlated to the Neuroticism factor; once all behavioral traits have been accounted for, numerical values are available for each individual along each factor—from which percentile values can further be deduced using a reference sample appropriate to the scenario at hand.

[0824] Note that a behavioral trait [295] might correlate to several archetypes; in some cases it might even correlate positively to an archetype and negatively to another. For instance, egocentric personalities are characterized (among other things) by a lack of empathy whereas influenceable personalities can be manipulated by others using their empathy (either towards the manipulator or a third party in case the manipulator resorts to coercion). In other words, the model assumes that each pair of random variables composed of a behavioral trait [295] and a personality type shows either no correlation, a positive correlation, or a negative correlation. In one embodiment, all such correlations are assumed to be linear correlations in the sense that actors [220] are scored along a personality type using a weighted sum (with positive or negative coefficients) over all behavioral traits [295] for which a score [285] has been computed.

[0825] The rest of this section lists a number of behavioral traits [295] provided by the default embodiment of this invention. This list is not limitative, and a key characteristic of this invention is to support augmenting the anomaly detection mechanism with any behavioral trait [295] that can be measured for a given actor [220]. For each trait, a brief explanation is given of how to score an actor [220] along that trait [295] in one embodiment among all possible embodiments; essentially each trait [295] can be measured along a number of vectors either directly observable in the data or derived during processing or post-processing by the system. For clarity, the behavioral traits [295] supported by the system are broken down into broad categories: in this default embodiment, the categories are job performance, job satisfaction, perception by peers, communication patterns, and character traits.

Traits Related to Job Performance

[0826] Job performance traits correspond to professional achievements and work habits, but also a measure of reliability, i.e. how well the actor [220] performs her job. The rest of this section describes such traits [295] that can be measured in the default embodiment of this invention.

Disengagement

[0827] Disengagement measures the actor's [220] involvement in various professional responsibilities.

[0828] In the default embodiment of the Invention, an actor's [220] disengagement is measured by first filtering discussions [136] computed by the system to retain those that involve the actor [220] as a primary participant, are business-relevant, and optionally by filtering according to topics addressed in the elements of those discussions [136]. Then the system computes a number of behavioral metrics [290] including but not limited to:

• • [0829] The lengths of those discussions [136] either over time or with the discussions [136] involving the actor's [220] peers,
  • [0830] Their frequency over time.
  • [0831] The actor's [220] level of participation. The level of participation can be measured using the results of a tagging subsystem, for example pragmatic tags [172]: in one embodiment, this is computed as A−U/T where A is the number of requests replied to by the actor [220] (by sending a work product or any relevant answer), U=R−A the number of requests left unanswered, R the total number of requests sent to the actor [220] (for example request for work product, for feedback, etc.), and T the total number of communications [123] received and sent by the actor [220].

[0832] In the default embodiment, the system lets a user visualize patterns of disengagement for a given actor [220] by using the sequence viewer described in this invention to show discussions [136] involving that actor [220].

Stability

[0833] Stability measures the regularity and stability in the distribution of time and effort for a given actor [220] across workflow processes [128] such as business workflows and activities.

[0834] In one embodiment, stability is measured using periodic patterns [126] derived by the periodic patterns detection component [405]; both a high frequency and an increasing frequency of gaps and disturbances in the business-relevant periodic patterns [126] involving the actor [220] denote an unstable behavior.

[0835] In the default embodiment: the system lets a user visualize patterns of stability for a given actor [220] by using the gap viewer described in this invention to show periodic patterns [126] involving that actor.

Delegation

[0836] This behavioral trait [295] assesses how the actor [220] delegates professional tasks and responsibilities.

[0837] In one embodiment, the level of delegation for a given actor [220] is measured as the centrality measure in the graph of instruction relaying (as defined in U.S. Pat. No. 7,143,091). Optionally, the graph can be filtered to only retain explicitly actionable instructions, such as those accompanied by an attached email or a list of tasks, which provide a more accurate reflection of work delegation than the transmission of more vague, non-directly actionable instructions, or mere forwards.

[0838] The system allows the user to efficiently visualize delegation patterns: either when an anomaly [270] has been flagged, or on-demand by the means of a particular type of animated actor graph [471].

Diligence

[0839] This behavioral trait [295] assesses the actors [220] ability to respect deadlines and to complete tasks delegated to her.

[0840] Measurements of an actor's [220] diligence include, but are not limited to the level of regularity in periodic sequences [132] originating from that actor [220], such as the submission of reports following a regularly scheduled meeting, or the frequency of indicators found in the analyzed data that the actor [220] was late or absent from important meetings without a valid reason being found for that absence or lateness.

Discipline

[0841] This behavioral trait [295] assesses the level of discipline shown by an actor [220] in the workplace, as well as her respect for procedures and hierarchy.

[0842] Measures of an actor's [220] level of discipline include but are not limited to:

• • [0843] Degree of absenteeism or unusual work schedules, as measured, for example, from a data source providing keycard access logs;
  • [0844] Explicit disregard for authority, as measured, for example, from applying the appropriate ontology classifiers [150] to messages sent by the actor [220] but also messages about the actor [220], such as language used by other people and suggesting that the subject is “dragging his feet”, or that he should receive a warning;
  • [0845] Non-compliance with internal policies, as measured, for example, from the output produced by a compliance system communicating with the present invention.
    Job Performance

[0846] In the default embodiment of the present invention, two types of definitions are combined for assessing an actors [220] job performance: an objective definition and a subjective definition.

[0847] Objective performance is assessed based on criteria including but not limited to production of high-quality content (i.e. frequently and broadly re-used in content authored by other actors [220]), or the dominant archetype taken by the actor [220] using role assessment (e.g. leader who frequently initiates discussions [136] vs. follower who passively observes discussions [136]).

[0848] Subjective performance is assessed based on criteria including but not limited to results of performance review (as directly recorded in numerical values in an HR system or as a polarity value evaluated from linguistic analysis of those reviews'content), any sanctions received by the employee, as well as the expression of a particularly positive or negative judgment on the actor's [220] performance as inferred from hits produced by appropriate ontology classifiers [150].

Mixing Professional and Personal Contexts

[0849] This behavioral trait [295] corresponds to an actor spending a lot of time and directing significant attention or effort towards non-business issues and topics [144] during work hours, as well as to repeated and impactful interferences of personal issues with behavior in the workplace.

[0850] It should be noted that another interesting trait [295] to measure is the reverse of this one, i.e. where electronic data produced during time out of the office contains large amounts of work products and other job-related content.

[0851] In the default embodiment of this invention, this is measured by criteria including but not limited to:

• • [0852] The proportion of items pertaining to at least one personal and one professional topic [144], as derived, for example, from running ontology classifiers [150] on electronic communications [123] authored by the actor [220];
  • [0853] The amount of time spent by the actor [220] on non-business-related activities using electronic systems and applications in the workplace;
  • [0854] Attention shift toward external contacts, as observed from an increasing proportion of communications [123] being sent to actors [220] external to the organization.
    Traits Related to Job Satisfaction

[0855] Job satisfaction describes how the considered actor [220] feels about her job at a given point in time or over time. The behavioral model [200] should contain as many traits [295] as possible in this category to reliably quantify the level of satisfaction as well as assess the topics [144] and related entities associated to the highest (resp. the lowest) degree of satisfaction for a particular actor [220]. The rest of this section describes such traits [295] that can be measured in the default embodiment of this invention.

Disgruntlement

[0856] This behavioral trait [295] corresponds to chronic discontentment transpiring in the organization.

[0857] In the default embodiment of this invention, this is measured by the volume of negative language related to the actor's [220] current responsibilities, to organizational policies, to coworkers, etc. In particular, the system measures resentment expressed by the actor [220] about people higher up than she is.

[0858] When measuring this behavioral trait [295], the system discounts any changes in sociability that are health- or family-related. An exception to this is when those personal issues become so critical that they turn into motivations for harming other actors [220], the organization, or the society, for example if they result from financial distress; this can be measured by linguistic analysis, or any method for monitoring the actor's [220] financial situation.

Grievance

[0859] This behavioral trait [295] corresponds to indicators of envy, jealousy, or any presence of grief in an actor [220], including a vindictive attitude.

[0860] This is measured by criteria including but not limited to:

• • [0861] Repeated expression of envy or jealousy towards other actors [220]
  • [0862] Being often irritable, directing anger toward a multitude of unrelated topics [144] or actors [220], particularly in light of the success of others. In the default embodiment of this invention, the system detects this situation by observing internal and external events [100] such as someone else getting promoted, getting married, or anyone else in the actor's [220] community or workgroup getting lots of non-negative attention regardless of the specific reason;
  • [0863] A passive-aggressive behavior, which can e.g. be detected as a combination of derogatory comments toward another actor [220] and repeatedly ignoring that other actor's [220] request for advice or for input in their professional tasks.

[0864] In one embodiment, the system lets a user visualize grievance patterns exhibited by a particular actor [220] using the stressful topics visualization described in this invention, using that actor [220] as the subject of interest.

Greed

[0865] This behavioral trait [295] is defined as the manifestation of excessive greed, but also more generally of an overachievement behavior. This is particularly important for anomaly detection aimed at spotting malicious behavior since excessive greed is often characteristic of an individual ready to go to extreme lengths, including malevolent ones, to reach her goals; such individuals try to rationalize unreasonable financial aspirations, thereby suggesting that they are struggling with internal conflicts due to considering malicious or otherwise unauthorized actions.

[0866] In one embodiment, excessive greed is detected by ontology classifiers [150] capturing constructs such as repeated complaints of “wanting a better X” for various values of X, or reflecting an obsession about the recognition (financial or other) of one's achievements
Undervaluation

[0867] In the default embodiment of the present invention, two types of definitions are combined for assessing an actor's [220] sense of undervaluation, similarly to the case of job performance assessment: an objective definition and a subjective definition.

[0868] Subjective undervaluation can be measured by criteria including but not limited to:

• • [0869] The actor [220] complaining in electronic communications that he is passed over for a promotion by less able individuals:
  • [0870] The actor [220] complaining in electronic communications [123] that she feels underpaid;

[0871] Objective undervaluation can be measured by criteria including but not limited to:

• • [0872] Increase in actual responsibility without being promoted, as observed from a formal HR system if available, or from pragmatic analysis combined with the detection of work projects and responsibilities;
  • [0873] How often the actor [220] is consulted on her domain of expertise;
  • [0874] How often the actor [220] uses her specific skills.
    Traits Related to Perception by Peers

[0875] These traits [295] constitute the external perception of the actor by a number of different people and together provide a collective wisdom portrait which constitutes a far more accurate and reliable picture of an actor's [220] personality and baseline behavior [260] than when only looking at that actor's [220] own point of view. The rest of this section describes such traits [295] that can be measured in the default embodiment of this invention.

Acceptance of Criticism

[0876] This behavioral trait [295] corresponds to how well the actor [220] receives feedback and constructive criticism, as well as her willingness to acknowledge and learn from past errors.

[0877] In one embodiment of the invention, acceptance of criticism is measured by methods including but not limited to:

• • [0878] Detecting events [100] related to the assessment of the actor's [220] performance then assessing their emotional impact by analyzing mood changes following such events [100], especially the strongly negative ones. Relevant events [100] comprise job performance reviews, informal evaluation by peers or hierarchical superiors, and more indirect evidence [108] such as the presence of calendar events for one-to-one meetings with a manager:
  • [0879] Assessing whether the actor [220] takes into account feedback and guidance that have been provided to her into her behavior or ignores them, and how often and how completely she incorporates into her work products changes suggested by others. The latter can be assessed using textblock analysis to compute the lineage of work-related documents [162] produced by the actor [220], and looking if the versions of such documents are updated to include a textblock pattern [124] found in content sent or otherwise submitted by a peer.
    Perceptive Bias

[0880] This behavioral trait [295] corresponds to how closely the way others see the actor [220] matches her own self-perception.

[0881] Measuring this trait [295] is particularly useful because a high contrast between how a person is perceived by others and their self-perception is often associated to discontentment and in more extreme cases to psychological troubles.

[0882] In one embodiment of the invention, the level of perceptive bias for an actor [220] is measured by methods including but not limited to.

• • [0883] Assessing the similarity of other actors' [220] negative (resp. positive) language relative to the actor's competence with her own expression of her skills and value;
  • [0884] Analyzing how fairly and realistically the actor [220] presents her own achievements. This can be detected by linguistic constructs such as other people blaming the actor [220] for taking undue credit, and the actor [220] reacting very strongly or inappropriately to criticism from management or from peers.
    Influence

[0885] This behavioral trait [295] measures the breadth and the level of influence exerted by the actor [220] over his peers, for example his co-workers.

[0886] A low level of influence occurs when the actor [220] has no significant impact on others, which depending on the context might be an important anomaly [270] to detect. Also, a suddenly increasing level of influence might reveal that the actor [220] is trying to become a power broker, possibly with the intent to extort information from others or coerce them for malicious purposes.

[0887] In one embodiment of the invention, the level of influence exerted by an actor [220] is measured by methods including but not limited to:

• • [0888] Computing the importance of the actor [220] in the communication graph filtered appropriately, for example using the graph of relaying implicit instructions (also called Mere Forwards, as described in U.S. Pat. No. 7,519,589, the disclosure of which is incorporated by reference herein for all purposes):
  • [0889] Detecting memes that originate from the actor [220], which provides a measure of linguistic or topical influence;
  • [0890] Assessing the role of the actor [220] in discussions [136] based on the relative frequency with which the actor [220] is a primary actor in discussions [306], where the primary actor is defined as the originator of one or more resolution items (as described in U.S. Pat. No. 7,143,091).
  • [0891] Assessing the impact of the actor's [220] presence or absence on the other actors [220], as described in the section on Actor influence analysis.
    Reliability

[0892] Reliability as a behavioral trait [295] indicates how dependable the actor [220] is considered, in particular how much actual trust others put into her beyond purely professional interactions.

[0893] In one embodiment of the invention, the reliability of an actor [220] is measured by methods including but not limited to:

• • [0894] Identification of linguistic markers of respect and deference (and lack thereof);
  • [0895] Detection of negative judgments, repeated criticism, and derogatory language about that actor [220], especially when coming from multiple actors [220] who are not closely related to one another.
    Popularity

[0896] This behavioral trait [295] indicates the status of an actor [220] in the eyes of her peers, particularly in the domain of their professional interactions.

[0897] In one embodiment of the invention, the popularity of an actor [220] is measured by methods including but not limited to:

• • [0898] Assessing the level of formality of interactions between that actor [220] and other actors [220], especially when that level is asymmetric (e.g. when the actor [220] is very formal in his messages but replies from various other people are unusually terse and informal);
  • [0899] Measuring the responsiveness of others to requests made by the actor [220];
  • [0900] Measuring how often the actor [220] is blown off by others [220];
  • [0901] Conversely, measuring how often the actor [220] is consulted by others;
  • [0902] Assessing how often the actor [220] is included in events or distribution lists after the fact: for example, someone who is often added to email recipient lists, especially on sensitive issues, is typically more popular than the average since others think about including her in the loop and implicitly value her opinion;
  • [0903] Computing the actor's [220] pecking order score (see section on Pecking order visualization);
  • [0904] Computing a measure of authority for that actor [220] in the graph built from invitations to meetings, which can be done using a well-known hubs and authority algorithm. It should be noted that meeting invitations are an essential behavioral indicator in many organizational environments, especially those where the more relevant or risky facts are rarely put in writing. Thus the graph of who invites, and demonstrably does not invite, whom to meetings is very valuable and can be used to assess an individual's perception by his peers. A measure of an authority for the node representing an actor [220] in the graph of meeting invitations thus indicates how many people invite her who are themselves considered important enough to be invited to other meetings, thereby providing an important objective component in the assessment of that actor's [220] popularity. Connectedness

[0905] This behavioral trait [295] measures the extent to which an actor [220] is included in business workflows, and how much she interacts with coworkers.

[0906] This trait [295] is an important component of an individual behavior [210] since isolation patterns, which reflect a significant lack of interaction or generally poor-quality interactions, are a worrying sign in most organizations. Conversely, the unexplained disappearance of isolation patterns is also suspicious in many situations, since e.g. someone reclusive who becomes very popular might actually be trying to manipulate people in the parent organization in order to gain unauthorized access to sensitive information.

[0907] In one embodiment of the invention, the connectedness of an actor [220] is measured by methods including but not limited to:

• • [0908] Computing the hub value for that actor [220] in the communication graph filtered by work-related content and where connections across distant groups [225] are more heavily weighed, once again using a classical hubs and authority algorithm:

[0909] Computing a measure of betweenness for that actor [220] in the graph of meeting invitations (described in the paragraph on popularity assessment). In a graph where nodes represent actors [220] and edges represent a certain type of connection, a measure of betweenness for a particular node indicates how many pairs of otherwise disconnected actors [220] the considered actor [220] connects with each other: therefore, the betweenness in the graph of meeting invitations is a reliable indicator of connectedness with the rest of the organization;

• • [0910] Measuring how often the actor [220] makes regular and significant contributions to collective tasks, and how often she collaborates on coworkers' assignments. This can be measured for example using pragmatic tags [172] computed on workflow instances [134], as performed by the pragmatic tagging component [430].

[0911] The system allows the user to efficiently visualize connectedness assessment for a particular actor [220], either when an anomaly [270] has been flagged or on-demand by the means of a graph showing changes of position within the actor network, which is one of the animated actor graphs [471] provided by the system.

Confrontational Behavior

[0912] This behavioral trait [295] reflects the tendency of an actor [220], in the face of conflicts involving other actors [220] in the organization, to either make those conflicts worse by her actors or speech, or, in contrast, to attempt to nip emerging conflicts in the bud, or more generally to solve existing interpersonal issues.

[0913] In one embodiment of the invention, an actor's [220] propensity to confrontation is measured by methods including but not limited to:

• • [0914] Detecting language and behavior causing aggravation of conflicts, such as frequent use of an aggressive tone;
  • [0915] Conversely, detect language and behavior causing mitigation of conflicts, such as using a neutral tone in consecutive communications [123] resulting in an agreement being reached between the parties involved in the conflict;
  • [0916] Measuring the impact of the actor's [220] involvement in a discussion [136]. In the default embodiment, this is measured by computing two different scores for an actor [220], as explained in the following.

[0917] When assessing an actor's [220] tendency towards confrontational behavior, the reply-based confrontation score [285] takes into account that actor's [220] response to negative sentiment. For example, if in the course of a discussion [136] that contains very little (if any) negative sentiment, the actor [220] sends out a very aggressive email, this will significantly increase her reply-based confrontation score [285]. By contrast, the effect-based confrontation score [285] takes into account that actor's [220] communications'[123] effects on others. For example, if in the course of a highly tense discussion [136] the actor [220] sends a neutral reply that has a clear mitigating effect on the following items [122] in the discussion [136], this will significantly decrease the actor's [220] effect-based confrontation score [285]. These two scores [285] take positive values and are computed as follows in the default embodiment. We denote n the length of a discussion [136], stm_i the polarity of the i-th item [122] in the discussion [136] for 1<=i<=n (positive values indicate positive sentiment), and author; its author (e.g. sender of an email). Then, to compute A's reply-based confrontation score, we tally all values taken by the expression
1≦i≦k, stm_i<0, author_j=A, i<j≦n, author_j≠A: Max(−stm_j,0)
and compute its mean over all discussions [136]. To compute A's effect-based confrontation score [285] we tally all values taken by the expression
1≦i≦k, stm_i<0, author_i=A, i<j≦n, author_j≠A: −stm_i/(n−j)*Σ_j<k≦nMax(−stm_j,0)
and compute its mean over all discussions [136].
Traits Related to Communication Patterns

[0918] The following describes behavioral traits [295] related to individual and collective communication patterns and how they can be measured in the default embodiment of this invention.

Self-Centeredness

[0919] This behavioral trait [295] assesses whether the actor [220] is only concerned with her own interests or has other people's interests in mind.

[0920] In one embodiment of the invention, an actor's [220] self-centered behavior is measured by methods including but not limited to:

• • [0921] The presence of generic linguistic markers of narcissism and egotism. In particular, someone who talks about herself more than the norm, especially in a strictly professional context, is suspicious;
  • [0922] The absence of expressed interest for others;
  • [0923] The lack of thankful language as detected using pragmatic tags [166] derived from discourse analysis.
    Stress Management Issues

[0924] In one embodiment of the system, stress management issues are detected using linguistic markers including but not limited to:

• • [0925] A significant increase in the amount of negative sentiment detected in communications [123] sent by the actor [220];
  • [0926] The adoption or a terse language structures, as observed e.g. from punctuation usage;
  • [0927] More specific signs of stress such as changes in the structure of the actor's [220] email replies, e.g. no longer taking case of in-lining replies within the original email's content.
    Polarized Behavior

[0928] Polarized behavior corresponds to the presence of both highly negative and highly positive sentiments expressed by the actor [220] on a certain topic [144] or relative to certain actor [220].

[0929] This is important in many situations as a factor of behavioral risk because polarized interactions and responses can suggest a vindictive attitude, but also more generally identity issues, especially when originating from the effort to maintain a façade of allegiance to the parent organization.

[0930] In one embodiment of the invention, a polarized attitude is detected by methods including but not limited to:

• • [0931] Measuring the presence of reverse sentiments expressed by the actor [220] toward other actors [220] or actor groups [225] when communicating with different audiences (for example, trusted persons and confidants vs. distant relationships);
  • [0932] Detecting the use of deceptive language, including flattery, which might imply in some cases that the actor [220] is hiding or distorting the truth to promote a hidden agenda. In that embodiment, deceptive language is detected using linguistic cues generally associated to deceptive writing, such as reduced first-person usage, increased usage of negative-emotion terms, a lower volume of exclusive terms, and a higher volume of action verbs.
    Information Dissemination

[0933] Information dissemination analyzes how specific knowledge and data spreads through the organization, e.g. if it typically travels through a single level of management, or more vertically, and how long it takes to become general knowledge, etc.

[0934] This behavioral trait [295] is particularly useful for analyzing the spread of highly valuable or sensitive information, as well as the effectiveness of knowledge acquisition throughout the organization.

[0935] To measure information dissemination behavior, actor profiles are built according to a model of knowledge creation and transfer. In the default embodiment of this invention, profiles are creators of information, couriers, and consumers. A method to rank actors [220] against each such profile is described in the section on Information dissemination profiles, along with a novel way to efficiently visualize these profiles on the whole actor network.

[0936] Optionally, the input data can be filtered by topic [144] or by ontology classifier [150], etc. to only retain information relevant to a specific scenario.

Clique Emergence

[0937] This behavioral trait [295] measures a particularly interesting social network pattern, namely the emergence of cliques [255], i.e. groups of tightly connected people. This is especially relevant in relation to other significant patterns or topics [144], and especially when these cliques [255] have a secretive nature.

[0938] In addition, people tend to aggregate around their likes, so that clique [255] members will often share similar behavioral traits [295], which can provide supporting evidence for the system's behavioral model [200] construction that an actor [220] matches a particular profile type. In other words, anomalous patterns for this behavioral trait [295] include, but are not limited to, a sudden change in an actor's [220] tendency to form cliques [255], and the inclusion of an actor [220] in one or more cliques [255] around another actor [220] who has previously been flagged—manually or automatically—as suspicious.

[0939] In the default embodiment of the invention, an actor's [220] tendency to form cliques [255] is assessed by detecting patterns including but not limited to:

• • [0940] A small group of actors [220] who have no common professional responsibilities and mostly communicate on a personal level, except that they systematically regroup after the occurrence of some event in the organization (e.g. they exchange IM to agree to meet offline after every internal meeting on a particular project);
  • [0941] Distinct communication channels [156] between certain groups [225], in comparison to official channels. This is considered particularly suspicious behavior when work groups [220] are supposed to be separated by clear boundaries, because somebody trying to gather info they should not have access to would go out of their way to socialize with members of other groups [220], which is often reflected in communication channels [156] that are clearly separate from the organizational ones.

[0942] The system allows the user to efficiently visualize the emergence, decay, and evolution of cliques. This is done either upon detecting an anomaly in relation to cliques [255] including a particular actor [220], or on demand from the user, by the means of an animated graph of cliques, which is one of the animated actor graphs [471] provided by the system.

Social Proximity

[0943] This behavioral trait [295] measures an actor's [220] tendency to develop and sustain personal relationships with co-workers.

[0944] In one embodiment of the invention, the level of social proximity of an actor [220] is assessed by computing metrics [290] including but not limited to:

• • [0945] The number of topics discussed with other actors [220];
  • [0946] The average level of formality between that actor [220] and all other actors [220] with whom she socially interacts;
  • [0947] The variety of emotive tones in that actor's [220] social interactions;
  • [0948] The number of communication channels [156] for each actor [220] she socially interacts with;
  • [0949] The number of foreign languages spoken (when applicable);
  • [0950] The time-spread of social interactions, such as time of day or day of week;

[0951] The frequency of invitations to social events;

[0952] The length of non-work-related discussions [136];

• • [0953] The proportion of time spent in social interactions;
  • [0954] The actor's [220] ability to form long-lasting relationships, e.g. measured as how often the actor [220] keeps in touch with former co-workers and for how long.

[0955] The system allows the user to efficiently visualize and assess social proximity and its evolution for a particular actor [220] on a continuous basis, using the Social You-niverse visualization [472].

Elicitation Patterns

[0956] Elicitation patterns detected by the system include but are not limited to:

• • [0957] Use of flattery to force other actors [220] to cooperate or unknowingly provide information;
  • [0958] Attempts to defuse a defensive reaction when seemingly trying to extort sensitive or otherwise valuable information.

[0959] In one embodiment of the invention, elicitation is detected using methods such as:

• • [0960] Flagging linguistic markers of flattery and elicitation attempts. For example phrases such as “Can I ask you a favor” might be an attempt to defuse a defensive reaction when trying to extort sensitive information. Also, malicious insiders often manage to convince others that they are committing their acts for a good cause, e.g. that leaking confidential information outside the organization actually helps that organization by demonstrating the ineffectiveness of the data leak prevention systems it has put in place. Therefore, phrases such as “We're all on the same side here” are also positively correlated with elicitation attempts;
  • [0961] Detecting drastic changes in the level of influence between two actors [220], which is one of many indicators that elicitation attempts could be succeeding.
    Character Traits

[0962] In addition to observed behavioral traits [295], some indicators of an actor's [220] personality or character are valuable for anomaly detection. The rest of this section describes such traits [295] and how they can be measured in the default embodiment of this invention.

Self-Esteem Issues

[0963] This character trait [295] corresponds to detecting extreme values of an actor's [220] apparent self-esteem. Both extremes result in anti-social behavior that might put the organization or other individuals at risk: a lack of self-esteem might lead the actor [220] to be easily influenced or to act irrationally, and when extremely low can even denote socio-pathological tendencies. Conversely, an inflated ego—and ego satisfaction issues in general—results in a lack of consideration for others and in a tendency to manipulate other actors [220] while rationalizing malicious actions. Also, a major decrease in self-esteem is also considered a cause for concern and therefore such a pattern is flagged by the system as anomalous.

[0964] In one embodiment of the invention, the likely existence of self-esteem issues is assessed using the following methods:

• • [0965] Detecting patterns where the actor [220] repeatedly seeks out those who flatter her. This can be done by measuring quality time (as shown in the Quality time visualization [478]) and computing proximity based on communication [123] initiation;
  • [0966] Conversely, detecting patterns where the actor [220] tries to avoid others to the extent possible especially after expressive negative feelings about herself;
  • [0967] Significant mood swings according to whom the actor [220] is primarily interacting with;
  • [0968] Signs of an inflated ego, detected using linguistic constructs and ontology classifiers [150], which include an inability to cope with delayed gratification, a strong sense of entitlement, and constant looking for validation by other actors [220].
    Individual Behavior Assessment

[0969] Based on a number of behavioral traits [295] including but not limited to the ones previously described, each of which can be scored along one or more behavioral metrics [290], the system establishes an assessment of the behavior of all individual actors [220] as follows.

[0970] For each behavioral trait [295], a per-actor [220] score [285] is computed as a linear combination of the values taken by each normalized metric [290] for that trait. Metrics [290] are normalized against all actors [220] for which they are defined (since no value might be available if for example no data relevant to the metric [290] is associated to a particular actor [220]) so as to have a zero mean and unit standard deviation. The set of weights involved in the linear combination of metric scores [285] is independent from the actor [220] considered. In one embodiment of the invention, the user [455] completely specifies the weight for each metric [290] of a given trait. In another embodiment, the system is initialized with identical weights, following which those weights are continuously adjusted based on user feedback [160], as described in the section on Anomaly detection tuning. This allows the system to fine-tune the assessment of a behavioral trait [295] based on input from a human expert since the comparative reliability e.g. of an actor network metric and of an ontology classifier metric is subject to interpretation and therefore can not be automatically determined by the system.

[0971] This linear combination yields a scalar value for each actor [220] against a particular behavioral trait [295], which in turn does not need to be normalized since it constitutes a relative scoring mechanism across the actor set; the system thus uses these values to rank the actors [220] by decreasing score [285]. These rankings [275] can then be leveraged in multiple ways, including having the system automatically generate alerts [305] for the top-ranked actors [220] against a particular trait [295] (as described in the section on Anomaly detection) or by letting the user query the behavioral model [200] against a trait [295] and returning the top-ranked actors [220].

Collective Behavior Assessment

[0972] The system is also able to determine the main characteristics of actor groups [225] using a model similar to the one used in individual behavior [210] assessment. This is useful to measure behavior at a coarser granularity than on a per-actor [220] basis. It is also essential to application scenarios where risk is presumed to originate not only from malicious insiders acting on their own or with accomplices external to the organization but also from conspiracies involving multiple actors [220].

[0973] To do this, the system defines and measures a number of collective behavioral traits [295] Which together compose a collective behavior [215]. Each of these traits [295] is derived from the individual behavior traits [295] of the group [225] members—which are measured as described previously—in a straightforward manner using simple aggregate metrics [290]. This allows the system to rank actor groups [225] against each of these traits [295] and thus lets the anomaly detection component [450] raise behavioral alerts [305] as appropriate. Those alerts [305] will thus be imputed to a group [225] rather than a single actor [220].

[0974] In the default embodiment of the invention, the system aggregates every single behavioral trait [295] for each actor [220] who belongs to a given group [225] by simply computing the average score [285]. This allows for example, to determine a score [285] and thus a ranking [275] for all formal or informal groups [225] against the disengagement trait described previously.

[0975] The system presents the resulting collective behavior [215] model to the user by underlining simple statistical measures over the corresponding behavioral traits [295]; such as the average score [285] against that trait [295], highest and lowest score [285], and standard deviation, for each actor group [225] for which the trait [295] has been measured. In one embodiment, this last condition is defined as having a significant number of individual trait measurements, for example at least 6 individual actor [220] scores [285].

[0976] In addition, all visualizations [204] of behavioral patterns described in this invention can be adapted to represent group behavior [215] rather than individual behavior [210]. For example, the social universe visualization uses planets [4820] to represents either individual actors [220] or groups [225]; matrix visualizations such as stressful topics and emotive tones represent either individual actors [220] or groups [225] as rows in the matrix; and visualizations [204] based on selecting input data [360] according to the actors [220] involved, such as the sequence viewer, can also filter that data according to the groups [225] involved.

Anomaly Detection

[0977] FIG. 8 shows a partial hierarchy of anomalies [270] generated by the anomaly detection component [450] of the system.

[0978] An anomaly [270] is associated to one or more events [100] that triggered the anomalous patterns, and to zero, one or more subjects [272], each subject [272] being an actor [220], a group [225], a workflow process [128], or an external event [170] to which the anomaly is imputed. The anomaly subject is defined as follows:

• • [0979] If the behavioral modeling component [445] has flagged an individual behavior as anomalous for a particular actor [220] or group [225], that actor [220] or group [225] is the subject of the anomaly.
  • [0980] If the continuous workflow analysis component [465] has detected an outlier workflow instance [134], the corresponding workflow process [128] is the subject of the anomaly.
  • [0981] If the anomaly detection component [450] has correlated the anomaly with a particular point in time or external circumstances, the corresponding external event [170] is the subject of the anomaly.

[0982] The quality of the output produced by a reliable anomaly detection system cannot be evaluated by a single metric. Therefore, an anomaly [270] generated by the present invention possesses a set of properties: confidence [870], relevance [880], and severity [875], which are described in the following.

[0983] Confidence [870] is a property endogenous to the model and indicates the current likelihood (as a positive numerical value estimated by the system) that the facts underlying the anomaly [270] are deemed valid in the physical world. This includes, but is not limited to, the following considerations: how strong the chain of evidence [100] is, and how many associations are established to produce the anomaly [270].

[0984] Relevance [280] is a property which is computed by combining user input [106] and information derived by the system. It represents the importance of the risk associated to the anomaly [270]. That is, a highly relevant anomaly [270] indicates behavior that can be malevolent or accidental but carries a significant risk (business risk, operational risk, etc.) whereas a low relevance [280] indicates abnormal but harmless behavior. Relevance [280] is a positive numerical value initialized to 1 for any newly detected anomaly [270]

[0985] Severity [875] is a property defined by human users and indicates the impact (for example in terms of material or financial damage) that the anomaly [270] would lead to if it is actually confirmed and carries a risk. In the default embodiment of the invention, the severity [870] is defined by a set of system-configurable parameters and is assigned to alerts [305] and other actions posterior to anomaly detection, but is not used by the system in its computations.

[0986] Anomalies [270] are generated by the anomaly detection component [450] and can be of different types, including but not limited to:

• • [0987] An atomic anomaly [830] is the most basic type of anomaly. An atomic anomaly [830] can be triggered by an anomalous event [835], which corresponds to observed events [102] having features which are abnormal in and of themselves. An atomic anomaly [830] can also be triggered by a rule violation [855] which corresponds to an observed event [102] having breached a compliance rule [865] or any part of an internal or regulatory policy.
  • [0988] A categorization anomaly [825] corresponds to unexpected categorization results of the data associated with a subject [272] with respect to that subject's [272] past categorization results.
  • [0989] An anomaly by association [850] groups several anomalies [270] that have strong causal relationship as derived from evidence links [108].
  • [0990] An anomaly by deviation [805] indicates that an individual actor [220], a group of actors [225], or even a workflow process [128] is showing characteristics that are unusual with respect to their normal characteristics, where normal is defined either with respect to past behavior or to the behavior of similar actors [220] or groups [225].
  • [0991] A behavioral trait anomaly [840] indicates that relatively to other actors [220] in the organization, an actor [220] has one of the most anomalous scores [285] with respect to a particular behavioral trait [295], as described in the section on the Behavioral model.

[0992] Each of these types of anomalies [270] is described in more detail in the following sections, along with one or more proposed methods for detecting such anomalies [270]. It should be noted that these anomaly types are not mutually exclusive: for example, an anomaly [270] may be justified by a single anomalous event [835] which also triggered a categorization anomaly [825].

Atomic Anomalies

[0993] The simplest type of anomaly [270] that is raised by the anomaly detection component [450] is an atomic anomaly [830] due to an anomalous event [835]. For example, emotive tone analysis as described in this invention may have detected derogatory or cursing language on certain internal communication channels [156], which can constitute anomalous behavior which should be further investigated, and thus results in an atomic anomaly [830] imputed to the author of these communications [123].

[0994] In one embodiment of the system, the anomaly detection component [450] can also be configured to trigger atomic anomalies [830] based on rule violations [855], such as compliance rules [865]. An example of rule violation is when a particular topic [144] may have been blacklisted so as to express that no communications [123] pertaining to that topic [144] should be exchanged among certain actors [220]. In this case, the communication [123] between two such actors [220], or alternatively the creation by one such actor [220], of a document [162] associated to that topic [144] is flagged by the system as a rule violation.

Categorization Anomalies

[0995] Categorization anomalies [825] are produced on two types of categorical features.

[0996] The first type of categorical features corresponds to categories produced by any type of categorization component [146] as part of the continuous categorization component [420], such as detected topics [144]. An example of categorization anomaly in that case is when the topical map for a given subject [272] shows an abrupt and unjustified change at some point in time.

[0997] The Second type of categorical features corresponds to built-in features of the system, such as detected emotive tones or entities (event names, people names, geographical locations, etc.) which are derived from the analysis of data and metadata extracted from events [100], including periodic sequences [132] that match a periodic pattern [126]. An example of categorization anomaly in that case is when the set of closest actors [220] has significantly changed for a given actor [220].

[0998] Categorization anomalies [825] are produced for any profile change detected as explained in the section on Continuous categorization

Anomalies by Association

[0999] Some events [100] can be flagged as an anomaly not by itself but because it is associated with another anomaly [270] by dint of some relationship inferred from one or more pieces of evidence [108], including but not limited to:

• • [1000] Content similarity
  • [1001] Causal relationship (as detected by discussion building)
  • [1002] Referential relationship (as detected by entity analysis)
  • [1003] Temporal relationship (for example temporal proximity between the two events [100], or proximity with different instances of a periodic sequence [132])
  • [1004] Geographical proximity
  • [1005] Organizational proximity, including involvement of the same actor [220]
  • [1006] Common topics [144].

[1007] In one embodiment of the system, anomalies by association [850] are computed as follows. The system configuration defines indirection levels that are incorporated into anomalies [270] when events [100] are correlated with other events [100]. In one embodiment of the present invention, an indirection level is a value I between 0 and 1 which is used to compute the new confidence level [870] every time a new relationship is established using the following expression;
conf_A-B=Max(conf_A,conf_B)+IMin(conf_A,conf_B)

[1008] Values of I are for example:

• • [1009] I=1 for strong sources of causal evidence [108], such as formal or informal workflow processes [128], shared attachments or textblock patterns [124], and for any topical, organizational, or referential association.
  • [1010] I=0.5 for weaker sources of causal evidence [108], such as lexical content similarity, or communications [123] joined based on pragmatic tagging.

[1011] For temporal associations, I is a function of the time difference between the associated events [100], namely I=exp(−γ|t_A−t_B|), with γ dependent on the type of events [100] considered (since different event types correspond to very different time scales).

Baseline Referentials

[1012] Baseline values for all types of behavioral features (including statistical measures and periodic features), computed for a particular subject [272] called the target subject [272], are stored in the baseline repository. They are continuously adapted by the behavioral modeling component [445] using the accumulation of collected data.

[1013] Every behavioral feature lends itself to one of several pair-wise comparisons, each based on the definition of a referential [3000]. FIG. 30 shows the types of referentials [3000] provided by the anomaly detection component [450] in a default embodiment of the invention. The value tested for anomalies [270] is called the analyzed feature [3075], while the value representing the norm is called the reference feature [3070].

[1014] Note also that features can correspond to absolute or relative values. To take a statistical measure as an example, such as number of emails sent by an actor (individual or aggregate), the feature can be either the absolute number of emails sent or the fraction it represents relative to the total number of emails sent by all actors [220] or by actors [220] in one of the groups [225] to which he belongs to.

[1015] Many other referentials can be used. In an alternative embodiment, the system lets the user combine several of these built-in referentials (for example an around-event referential [3020] and a peer-group referential [3005]). In yet another alternative embodiment, referentials [3000] can be created whose definition themselves depend on the analyzed and reference features, such as a filter on their reference events [100] (for example, when these features are statistical features related to electronic communications [123], custom peer groups can be defined by restricting the actors [220] to those having discussed a particular topic [144]).

[1016] When the referential [3000] is a baseline referential [3015], the target subject's [272] baseline value [3035] (considered her normal behavior) and her current value [3045] are compared. The rationale for this kind of comparison is that individual actors [220] as well as actor groups [225] are creatures of habit who tend to develop their own patterns of communication, of interaction with the data and other actors [220], etc. The system thus aims at modeling as many idiosyncrasies of the considered actor [220] or group [225] as possible, and at detecting the cases where the current model diverges from the past model. In addition to this goal, observing permanent change, either individually or at a group level, is also of utmost importance since it guarantees the accuracy of the anomaly detection process as well as often provides insightful information on the data itself.

[1017] When the referential [3000] is a historical referential [3010] the current value [3045] is compared to a historical value [3040] (i.e. a fixed amount of time in the past).

[1018] When the referential [3000] is an around-event referential [3020], the target subject's [272] baseline values before and after an external event [170] are compared: the value before that point in time [3050] is the reference feature, while the value after that point in time [3055] is the analyzed feature. The idea here is that if the behavior of a subject [272] tends to change significantly following a particularly sensitive external event [170], this may suggest that the subject [272] was specifically involved in that external event [170].

[1019] When the referential [3000] is a periodic event referential [3025], the changes in the target subjects [272] feature values [3065] around a more recent external event [170] are compared to the same feature values [3060] around an older external event [170].

[1020] When the referential [3000] is a peer-group referential [3005], the target subject's [272] baseline value [3035] is compared to the baseline values of similar subjects [272] defined as a peer group [3030]. This is particularly useful in the cases where no normal behavior can be easily defined on the subject [272], but more generally it provides a much more exhaustive way to detect behavioral anomalies, especially in presence of malicious activities: intuitively, in order to escape the detection capabilities of the present invention, an individual who wants to commit fraud would need not only to hide its own malicious actions so they do not appear suspicious with respect to his past behavior, but would also need to ensure that they do not appear suspicious in the light of other people's actions. The baseline values of similar subjects [272] represented as a peer group [3035] are computed as summaries of the behaviors of similar actors [220] or groups [225], for example by averaging each relevant (observed or derived) feature. A peer group [3035], can be defined in a number of ways, which include but are not limited to:

• • [1021] Actors [220] with an identical function or a peer-level, different function in the company, as defined for example in an organizational chart.
  • [1022] Actors [220] or groups of actors [225] having the same responsibilities within the company, as reflected in their work habits.
  • [1023] Actors [220] who are closest to the considered actor [220] (based on a variety of properties such as the most frequent email recipients, the whole list being defined in U.S. Pat. No. 7,143,091). In one embodiment the n closest actors [220] are selected, in another embodiment the cutoff occurs at a proximity threshold.
  • [1024] Other actors belonging to the same circle of trust [255] as the considered actor [220]. (Where circles of trust [255] are defined in U.S. Pat. No. 7,143,091 and comprise professional circles of trust, personal cliques or friendship-based circles of trust, and event- or crisis-motivated circles of trust.)
  • [1025] Formal workflows belonging to the same business line as the considered workflow process [128].
  • [1026] Ad-hoc workflow processes similar to the considered workflow process [128] in any of the following meanings: shared workflow stages [154], shared media (i.e. type of communication channel [1568] or of document [162]), involvement of the same actors [220], and similar timeframes.

[1027] The methods available in the present invention to detect anomalies by deviation [805] are detailed in the rest of this section.

Defecting Anomalies by Deviation

[1028] Anomalies by deviation [805] can be detected on any type of feature [2900] associated to events [100]. As illustrated in FIG. 29, in the default embodiment of the invention, the following types of features [2900] are supported by the system:

• • [1029] Scalar features [2915] are all numerical features [2905] that take a single value. An anomaly by deviation [805] on a scalar feature represents an unexpected trend in that feature [2900], intuitively meaning that the habits of particular actors [220] have changed drastically. An example of such an anomaly by deviation is when the daily volume of communications [123] sent by an individual actor [220] on a particular communication channel [156] has significantly changed over time.
  • [1030] Vector features [2920] are the multidimensional variant of scalar features [2915].
  • [1031] Periodicity features [2925] correspond to periodic patterns [126] that disappear or are modified, meaning that regularities in the occurrence of specific events [100] have changed or disappeared. An example of deviation from a periodic pattern [126] is when irregularities occur in a meeting scheduled at a fixed interval, or in recurring data archiving operations.

[1032] Periodicity features [2925] can always be treated as a combination of scalar features and categorical features by considering the time elapsed between successive instances of the periodic pattern [126] as a specific type of scalar feature [2915], as well as including all features [2900] attached to each occurrence (i.e. to each periodic sequence [132]). Therefore only numerical features [2905] and categorical features [2910] actually need to be considered.

[1033] The amplitude of each deviation is mapped into the interval [0,1] where 1 represents the absence of deviation, and this value is used as a multiplier of the confidence level [870] of the considered anomaly [270].

[1034] In order to detect anomalies by deviation [805] on a given feature [2900], a few parameters are needed to configure the model for each actor [220] or group [225]. Note that as for most parameters used for tuning the system, these parameters should not be exposed to the user and should remain as stable as possible so as to minimize their impact on recall rate and precision. Also, a default value is available for these parameters, but this value can be overridden to reflect that different actors [220] have different behavioral characteristics (for example, the time scales for answering email messages can vary tremendously across individuals, which must be accounted for in the behavioral model [200].)

[1035] These parameters include:

• • [1036] v: length of the sliding time window [380] for baseline pattern computation
  • [1037] w: length of the sliding time window [380] for computation of the current trend (w is typically an order of magnitude smaller than v)
  • [1038] For each observed or derived feature [2920], a threshold multiplier A to detect abnormal deviations. Another embodiment of the invention defines 2 levels of anomaly so that 2 thresholds are needed, with the lower threshold indicating suspicious, potentially abnormal observations that need to be confirmed by subsequent abnormal observations before becoming flagrant anomalies. Possible values for the threshold multiplier are given in the next section.

[1039] The first step in detecting anomalies by deviation is to define the reference features [3070] against which analyzed features [3075] will be compared.

[1040] A feature descriptor [3080] is an aggregated value computed over a time interval. In one embodiment of the invention, one or more of the following definitions are available for a feature descriptor [3080]:

• • [1041] The average value of the feature [2920];
  • [1042] The linear regression of the feature [2920];
  • [1043] The variance of the feature [2920];
  • [1044] Any combination of the previous values.

[1045] Once the descriptor [3080] has been defined for a given feature [2920], it is straightforward to compute it on an analyzed feature [3075]: this analyzed feature [3075] is usually defined as a sliding window [380] of recent data for the target subject [272], or as a window around an event [100] (unique or recurring) in the case where behaviors around two different events [100] have to be compared.

[1046] Computing the descriptor [3080] on a reference feature [3070] is somewhat less obvious, and is described in the following paragraph. We can already distinguish two cases:

[1047] To compute the descriptor [3080] on a reference feature [3070] in the case of a time-based referential (i.e. not a peer-group referential [3005]), in the default embodiment of the system, the descriptor [3080] is the average feature value over all observations in time. In another embodiment, the descriptor [3080] is the feature value of the best exemplar among the observations, i.e. the value that minimizes the sum of distances to the other observations.

[1048] To compute the descriptor [3080] on a reference feature [3070] in the case of a peer-group referential [3005], the same method is used after replacing the set of observations at different points in time by the set of subjects [272] that constitute the reference group [3030].

Computing Reference Features

[1049] This paragraph describes in more detail how a descriptor [3080] is computed on a reference feature [3070], and in particular what information needs to be stored and updated for that computation.

[1050] In the case of a baseline referential [3015], the system only needs to maintain two descriptors [3080] for the target subject [272], in a sliding time window [380] of size w and a sliding time window [380] of size v, both ending at the current time.

[1051] In the case of a historical referential [3010], the system only needs to maintain two descriptors [3080] for the target subject [272], in a sliding time window [380] of size w ending at the current time t and a sliding time window of size w ending at t−T. (Note that necessarily T≦w in the case of a recurring event.)

[1052] In the case of an around-event referential [3020], the system only needs to maintain two descriptors [3080] for the target subject [272], in a time window of size w starting at the event's end time and a time window of size w ending the event's end time. When the event [100] is a recurring event [101], the positions of these windows are updated every time a new occurrence of the event has been detected.

[1053] The case of a peer-group referential [3005] is the least simple one to compute. Firstly, the reference group [3030] can be defined either exogenously or endogenously to the feature [2900] considered. For any given feature [2900], the system may use an exogenous definition of the reference group [3030], or an endogenous definition, or both.

[1054] As mentioned previously, exogenous definitions for a reference group [3030] include but are not limited to:

• • [1055] Group [225] of closest actors of the target actor [220] (when the subject [272] is an actor [220])
  • [1056] Set of actors [220] having the same role as the target actor [220]
  • [1057] Set of ad-hoc workflows most similar to the target workflow process [128].

[1058] To compute an endogenous reference group [3030], the system sorts a list of all subjects [272] homogenous to the target subject [272]. Homogeneous means a subject of the same type (actor [220] to actor [220], group [225] to group [225], or workflow process [128] to workflow process [128]) or of a compatible type (actor [220] to group [225]. The list is sorted according to a distance defined over feature descriptors [3080]. In the default embodiment the distance is the Euclidian distance between the feature descriptors [3080]. In another embodiment it is a linear combination of the Euclidian distance between the feature descriptors [3080] and of the Euclidian distance between the variances of the feature descriptors [3080].

[1059] Finally, the system re-computes the reference group [3030] (be it endogenously or exogenously defined) at regular intervals. In one embodiment of the invention this interval is a fixed multiple of w, for example 10w. In another embodiment, the interval is adapted to the feature [2900] considered: for example if characteristic time scales are available for that feature then the median value of these time scales over the reference group is used as the time interval for the next computation of the reference group.

[1060] The mechanism to detect anomalies by deviation [805] is executed at fixed time interval w. Two cases have to be considered depending on the type of referential [3000].

[1061] In the case of a time-based referential (i.e. any referential [3000] which is not a peer-group referential [3005]), a deviation is detected when the absolute value of the difference between the analyzed feature descriptor [3080] and the reference feature descriptor [3080] is larger than A times the variance of the reference feature descriptor [3080] across the reference observations.

[1062] In the case of a peer-group referential [3005], a deviation is detected using the same criterion after replacing the variance across the set of observations in time with the variance across the set of subjects comprising the reference group.

[1063] In one embodiment, the threshold multiplier A has a default value of 10, and is tuned to larger or smaller values based on feedback given by the user regarding detected anomalies by deviation (see the section on Anomaly detection tuning).

Predicted Behavior

[1064] By leveraging behavioral norms and deviations from those norms in the behavioral model [200] built and continuously maintained by the behavioral modeling component [445], the system also predicts individual behavior; in other words it uses the past to predict the near future.

[1065] Predicted behavior [262] computed by this invention includes anomalous behavior and also more generally includes any kind of future events [100] that are deemed to have a high likelihood of occurring, based on past events [100]. Examples of behavior predicted by the system in the default embodiment include but are not limited to:

• • [1066] Using the behavioral trait [295] measuring acceptance of criticism and described previously in this invention, the system has recorded in the model that a particular actor [220] always reacts very aggressively to negative performance reviews. Then, when the occurrence of the next performance review is detected by any kind of mechanism (for example, an ontology classifier [150] flagging review language in electronic communication [123]), the system will raise an alert at a future point in time at which the subjects negativity is expected to peak, such as 2 weeks after the results of the review have been communicated.
  • [1067] Using the behavioral trait [295] measuring social proximity between a pair of actors and described previously in this invention, the system has recorded several situations in the past in which members of a particular group of actors [225] severed a strong relationship with some other actor [220]. These past situations shared a number of precursory signs, such as the discussion of a (presumably sensitive) topic [144] in the month preceding the severance of the relationship, or the involvement of a common third-party in the electronic communications [123]. Then, when the same patterns are observed at some point in time for another member of that same group [225], the system will predict that the social relationship will be similarly damaged within a short time frame.
  • [1068] When an anomaly [270] has been detected soon after several past occurrences of a recurring event [101], the system will predict a similar anomaly [270] when a new occurrence of the same recurring event [101] has been detected. For instance, if a particular group of actors [225] always takes a discussion [136] offline (which is described as a call-me event, along with a method to detect it, in U.S. Pat. No. 7,519,589, the disclosure of which is incorporated by reference herein for all purposes) after a regularly-occurring meeting, the system will predict a call-me event right after the next occurrence of the meeting. As a result, an analyst or operator of the system would have good reasons to investigate the content of that particular discussion [136] among those actors [220].

[1069] Similarly to anomalies [270] raised on past events, the system automatically assigns a confidence level [870] to predicted anomalies [270]. In the default embodiment, the confidence [870] of a predicted anomaly [270] is always lower than if all events [100] had already been observed. The confidence level [870] is derived from the confidence [870] of the corresponding past anomaly [270] by applying an uncertainty factor, which is simply the prior probability that missing events [100] will be observed given all the events [100] that have been observed so far. For example, in the case in which the missing events [100] are part of a workflow process [128], which is modeled by the default embodiment as a higher-order Markov chain (as described in the section on continuous workflow analysis), the probability of those missing events [100] is directly inferred from the parameters of that Markov chain.

[1070] As previously described, one fundamental type of anomalous behavior raised by the system are anomalies by deviation [805], which are detected on any kind of feature [2900] present in the stream of events [100]. Similarly, predicted behavior [202] is inferred on the basis of particular referentials [3000] whenever an analyzed feature [3075] matches the corresponding reference feature [3070], rather than when a deviation is observed between the analyzed feature [3075] and the reference feature [3070]. The fact that the pair-wise comparison operates on baseline behavior [260] guarantees the reliability of this prediction, reference features [3070] are statistically significant as they result from aggregating patterns of behavior over a significant period of time (for example in the case of a baseline referential [3010]) or over a large number of actors [220] (for example in the case of a peer-group referential [3005]).

Alert Generation

[1071] The system generates alerts [305] for detected anomalies [270] that meet specific criteria of importance. In the default embodiment of the invention, the unique criterion is Conf*Rel≧κ where Conf is the confidence level [870] of the anomaly, Rel its relevance [280], and κ is a threshold for alert generation.

[1072] FIG. 31 shows the states in which an alert [305] generated by the system exists, and the transitions between those states:

[1073] An alert [305] is generated by an alert profile, which is defined as follows:

• • [1074] Alerts [305] apply to one or more actors [220], groups [225], or workflow processes [128], sorted by level of involvement in the alert [305]. In the default embodiment, the level of involvement is simply the actor presence in the associated discussions [136] and singleton events [100]. In another embodiment, the number of different personae involved in the associated data increases an actor's [220] involvement in the alert [305].)
  • [1075] Alerts [305] are defined against a given time window.
  • [1076] List of data sources considered for this alert profile.
  • [1077] Alert production mode: email (SMTP or IMAP), syslog event, SNMP trap.

[1078] In addition to the system-level parameter κ, the alert [305] generation mechanism is parameterized by the following values:

• • [1079] A maximum aggregation time period t_a is defined for anomaly detection (i.e. only events [100] within this timeframe are correlated to possibly trigger an alert [305]. In one embodiment, only events [100] occurring within a sliding window [380] of size t_a are aggregated into an alert [305]. In an alternative embodiment, a window of size t_a is considered around each occurrence of recurring external events, so that events [100] occurring in disjoint windows [380] can be aggregated into an alert [305].
  • [1080] A minimum number of independent isolated events [100] to trigger an alert [305] can also be defined.

[1081] In one embodiment of this invention, the user can modify the parameter t_a on which anomalies [270] are accumulated to build up an alert [305], using a slider rule widget with a logarithmic scale with windows ranging from as small as 1 hour to as large as 1 month.

[1082] In particular, the definition of these configuration parameters implies that since the number of individual actors [220] covered by the system and the data processing throughput are bounded, then the frequency of generated alerts [305] is in general bounded.

[1083] In addition, the user can provide feedback [160] regarding the actual importance of one or more generated alerts [305], as described in the section on Anomaly detection tuning.

Post-Processing Actions

[1084] In addition to alert [305] generation, a number of various actions can be configured, including:

• • [1085] Custom report [310] generation;
  • [1086] Quarantine [312]: data items [122] and evidence [202] that are associated to a detected alert [305] can be stored in a quarantine for further investigation, for example by a compliance officer in the corporate organization;
  • [1087] Logging [313]: when an anomaly is detected, the logging functionality either stores metadata relative to the data associated to this anomaly, or stores the native data itself. In the latter case, the way data items are stored can be configured more finely: data can be made anonymous and if the data item is an email, attachments can be stored as well or simply discarded;
  • [1088] Notification [314]: the notification functionality notifies the actor [220] responsible for a suspicious activity, for example the sender of an email that violated a compliance rule. The objective here is to educate employees on corporate policies.

[1089] Furthermore, the system can be configured to trigger mitigation and preventive actions as soon as it is notified of an anomaly. The benefits of mitigation and preventive actions are twofold.

[1090] First, this is necessary because it provides an extra safety mechanism, thus further reducing the operational risk.

[1091] Moreover, these automatically-triggered actions can limit damages resulting from fraudulent or accidental behaviors in cases where human individuals have failed to react to the anomalies [270] (either by negligence or by malevolence).

[1092] Examples of mitigation and preventive actions are:

• • [1093] Blocking traffic: this action blocks the suspicious traffic, for example on the SMTP server if the data is email, or by sending a TCP reset if the data is transmitted over HTTP;
  • [1094] Restricting credentials: this action restricts the authorization and access levels of an individual actor [220] or a whole group [225] that is the subject [385] of an alert [305];
  • [1095] Inhibiting functionality: this action blocks specific functionalities of an enterprise application (either for an individual [220], for a group [225], or globally).
    Anomaly Detection Tuning
    User Feedback

[1096] Feedback given by a user of the system on an alert [305] consists of assessing the relevance of the alert [305], i.e. the risk it represents. Based on that feedback, the system updates the relevance [280] of the underlying anomalies.

[1097] The system lets the user enter feedback [158] on:

• • [1098] A single alert [305] instance;
  • [1099] Or every instance of a periodically-occurring alert [305];
  • [1100] Or a cluster of alerts [305] computed by the system:
  • [1101] Or an anomaly class [3200] defined against that alert as described later in this section.
    Anomaly Classes

[1102] A key feature of the anomaly detection tuning mechanism described in this invention is the ability to define a whole anomaly class [3200] showing a particular similarity and providing specific feedback [158] for all the anomalies [270] contained in this class [3200].

[1103] An anomaly class [3200] can be defined in a number of ways. In the default embodiment, a class is defined by one or more expansion criteria. Each criterion defines a set of anomalies [270] (including the set of initial anomalies [270] contained in the alert on which the user is entering feedback [158]), and the combination of multiple criteria is interpreted as a conjunction, so that the resulting anomaly class [3200] is the intersection of the anomaly sets. In another embodiment, an additional operator allows combination of several classes [3200], in which case the combination is interpreted as a disjunction; this allows the ability to capture the union of anomaly classes [3200] using a single set of criteria.

[1104] In another embodiment, as illustrated in FIG. 32, an anomaly class [3200] can be defined in two different ways. The first is to define a class by relaxing constraints [3205] on a given anomaly [270], which allows the capture of very targeted classes [3200], in which all anomalies [270] share many properties with the initial anomaly [270]. The second is to define a class [3200] by specifying similarity constraints [3210] with respect to a given anomaly [270], which allows the system to capture broader classes [3200], in which anomalies [270] only share one or a few properties with the initial anomaly [270].

[1105] An anomaly class [3200] can be defined by constraint relaxation [3205] on anomaly A by using any number of the following constraints [3260]:

• • [1106] Actor criteria [3220]: Include anomalies [270] involving any actors [220]; alternatively, include anomalies [270] involving only some of the actors [220] a₁, . . . , a_n of A; alternatively, include anomalies [270] where actors [220] a₁, . . . , a_n of A are expanded to the group [225] of similar actors (which can be defined in a number of ways including personal cliques [255], similar business roles, etc.).
  • [1107] Time criteria [3225]: Include anomalies [270] with any time frame; alternatively, include anomalies [270] matching a given time specification (which is matched by A).

[1108] Topic criteria [3215]: Include anomalies [270] having any associated topics [144]; alternatively, include anomalies [270] containing only some of the topics [144] t₁, . . . , t_n of A.

• • [1109] Deviation referentials [3230]: In case A is an anomaly by deviation, include anomalies by deviation detected against other referentials [3000].
  • [1110] Named entities criteria [3265]: Include anomalies referring only to some of the named entities E₁, . . . , E_n of A.
  • [1111] Evidence links [3235]: In case A is an anomaly by association, [850], include anomalies [270] carrying only some of the evidence links [108] L₁, . . . L_n of A. For any type of anomaly [270], include anomalies [270] which are associated to A by a given evidence link [108], even if the confidence of that evidence [108] is not necessarily above the detection threshold. Types of evidence links that can be specified by the user include but are not limited to: causal relationship, shared workflow process [128], shared textblock pattern [124], shared periodic pattern [126], association to an external event [170].
  • [1112] System type criteria [3255]: Include anomalies [270] involving only some of the systems S₁, . . . , S_n of A (where systems are either machines or applications).
  • [1113] Item type criteria [3245]: Include anomalies [270] involving only some of the item types T₁, . . . , T_n of A.
  • [1114] Interaction type criteria [3240]: Include anomalies [270] involving only some of the action types A₁, . . . , A_n appearing in A. In one embodiment, interaction types that can be specified by the user include but are not limited to: actor-actor communications [123] (exchanging some message, belonging to the same list of recipients), collaboration (shared meeting attendance, work on creating common content), actor-data interactions (check-in operations, data modifications), and system or application interactions (logging into a system, creating a document in an application, creating data on a particular machine).
  • [1115] Geo-location criteria [3250]: Include anomalies involving only some of the geographical locations g₁, . . . , g_n appearing in A.

[1116] Alternatively, an anomaly class [3200] can be defined by constraint specification on the basis of anomaly [270] A by using any number of the following criteria:

• • [1117] Capture all anomalies [270] involving the same actors [220] as A; alternatively, capture all anomalies [270] sharing actors [220] a₁, . . . , a_n of A; alternatively, capture all anomalies [270] including actors [220] similar to actors a₁ . . . , a_n of A (where similar actors [220] can be defined in a number of ways including personal cliques [255], similar business roles, etc.)

[1118] Capture all anomalies [270] having textblock hits [130] for some textblock patterns [124] c₁, . . . , c_n that also correspond to textblock hits [130] in A.

• • [1119] Actor criteria [3220]: Capture all anomalies [270] overlapping the time frame of A; alternatively, capture all anomalies [270] overlapping the time frame of events [100] e₁, . . . , e_n of A; alternatively, capture all anomalies [270] in the temporal neighborhood of A (where proximity is defined for example by specifying the size of a time window).
  • [1120] Topic criteria [3215]: Capture all anomalies [270] sharing topics t₁, . . . , t_n with A.
  • [1121] Named entities criteria [3265]: Capture all anomalies [270] sharing named entities E₁, . . . , E_n with A.
  • [1122] System type criteria [3255]: Capture all anomalies [270] sharing systems S₁, . . . , S_n with A (where systems are either machines or applications)
  • [1123] Item type criteria [3245]: Capture all anomalies [270] sharing item types T₁ . . . , T_n with A.
  • [1124] Workflow criteria [3270]: Capture all anomalies [270] involving workflow processes [128] W₁, . . . , W_n also present in A; alternatively, capture all anomalies [270] involving some specific workflow stages [154] within these workflow processes [128].
  • [1125] Interaction type criteria [3240]: Capture all anomalies [270] sharing action types A₁, . . . , A_n with A
  • [1126] Geo-location criteria [3250]: Capture all anomalies [270] sharing geographical locations g₁, . . . , g_n with A.

[1127] The feedback [158] given by the user on an anomaly [270] or an anomaly class [3200] is a binary value, “relevant” or “irrelevant”, meaning that the anomaly [270] is confirmed [3105] or refuted [3110]. The next section explains how the system automatically tunes the anomaly detection component [450] using that feedback [158].

Feedback on Atomic Anomalies

[1128] The first type of anomaly [270] that the user can give feedback [158] on is an atomic anomaly [830]. For example, if the event [100] corresponds to a previously blacklisted topic [144], the user may decide to relax the constraint on this topic [144] by applying a lower index of relevance to all events [100] corresponding to the detection of this topic [144].

[1129] In addition, some abnormal events are defined with respect to a threshold value, so that another way to tune the detection of this type of anomaly is to simply change the threshold at which an event [100] is considered abnormal: for example, what minimal value of a shared folder's volatility will constitute an anomaly [270].

Feedback on Anomalies by Association

[1130] Anomalies by association can also be tuned by a user at a fine-grained level, in addition to the indirection level of each association type described in the section on Anomaly detection, which is part of the system configuration.

[1131] For example, if a topical association indicates that two events [100] share a given topic [144] T, feedback [158] can then be given in the following ways:

• • [1132] Either by indicating the relevance [280] of this whole class of association, so that all topical associations will be impacted.
  • [1133] Or by indicating the relevance [280] of similar association instances, so that in this case all associations of events [100] sharing topic [144] T will be impacted.
  • [1134] Or by indicating the relevance [280] of this specific association only.
    Feedback on Anomalies by Deviation

[1135] FIG. 33 shows the process by which a user can give feedback [158] on an anomaly by deviation [805]. Such feedback [158] includes the following options:

• • [1136] 1. Confirms the anomaly [3305]: this validates that the anomaly [270] is indeed relevant and presents some risk;
  • [1137] 2. Mark the anomaly as unique exception [3310]: this implies that this occurrence will be discarded, but also that any future occurrence of the same anomaly [270] will be detected;
  • [1138] 3. Take an action with respect to the baseline:
    • [1139] a. Decrease sensitivity [3330]: this means that the deviation threshold will be increased for the relevant feature (thus indicating that this occurrence is a false positive and will be refuted [3110]);
    • [1140] b. Mark the anomaly as a temporary exception [3315]: for a given period of time, the relevant feature will not be monitored, after which the same baseline is expected to resume, so that the same anomaly [270] would be detected again;
    • [1141] c. Mark this observation as new baseline [3320]: when choosing this option, the user indicates that a sudden baseline change is known to have happened, and that the data-driven monitor should override the baseline trend with the recent trend;
    • [1142] d. Mark as ongoing baseline change [3325]: when choosing this option, the user indicates that a slow baseline change is known to be happening, and that the data-driven monitor should update the baseline trend as long as this change is occurring, then start monitoring again when the trend has stabilized.

[1143] In addition, as in the general case previously described, when indicating a change to the baseline trend, the user may wish to apply the change to a whole class [3200] of similar anomalies, such as those concerning other actors [220] or those covering another topic [144].

[1144] It should also be noted that the real-world facts known by an analyst can also be indirectly fed into the system, by giving feedback [158] including but not limited to the following types:

• • [1145] A slow change or trend is taking place;
  • [1146] Exceptional circumstances require making temporary exceptions in the definition of abnormality in a given context (topic, actors, time, etc.).
    Threshold Adjustment

[1147] The anomaly detection component [450] in this invention contains an additional mechanism to fine-tune the detection of anomalies by deviation [805]. Rather than the specific types of Boolean feedback previously described (whereby the user indicates whether an anomaly [270] or anomaly class [3200] is absolutely relevant or absolutely irrelevant), this additional mechanism allows a user to manually change the threshold at which a deviation is detected on a given feature.

[1148] For example, the user [455] adjusts the threshold (as defined in the section on Anomaly detection tuning) used for detecting abnormal variations of the information flow between two actors [220], or abnormal variations of the measure of centrality of a given actor [220], or the breach in the theoretical workflow process [128] for a given type of document [162].

[1149] Also, the user can adjust the weights associated with each behavioral metric [290] used to assess individual behavior [210] or collective behavior [215] associated with a particular trait [295], as described in the Individual Behavior Assessment Section. In one embodiment of the invention, this is done by manually setting the numeric weights of each metric [290]. In another embodiment, this is done using a slider widget acting as a lever to adjust the weight of each metric [290] while visually controlling the impact of those adjustments on the actor rankings [275], as described in the Alert Visualizations Section.

[1150] In the default embodiment of the invention, the threshold adjustment mechanism is available only to advanced users of the application since it requires a lower-level understanding of the anomaly detection model. The benefit of this additional mechanism is that it allows more accurate feedback on which dimensions of a detected anomaly [270] need to be given more (or less) importance.

Anomaly Relevance Adjustment

[1151] The most straightforward mechanism by which the system adjusts the relevance level of detected anomalies [270] is based on user feedback [158].

[1152] As described previously, this feedback [158] can be a Boolean value (relevant/irrelevant), in which case the anomaly relevance [280] is either set to 0 or left at its original value, a relative value (increase/decrease relevance [280])—for example in the case of periodic anomalies—, or this feedback [158] can be a numeric value whereby the user directly indicates the relevance [280] to assign.

[1153] An additional mechanism aims to automatically prevent false negatives in the anomaly detection process in the case of anomaly bursts and is referred to as anomaly burst adjustment.

[1154] Whenever a new anomaly [270] is detected by the system, the time elapsed since the last anomaly [270] is taken into account to adjust the relevance [280] of the newer anomaly. The goal of this mechanism is thus to account for the case of several anomalies detected within a short timeframe which are part of a burst phenomenon and which all have a root cause: the user's attention should be focused on this event [100] (or sequence of events [100]) rather than on every individual anomaly [270].

[1155] In one embodiment of the invention, a burst interval is defined: when the interval between two successive anomalies [270] is longer than the burst interval, no burst adjustment is applied; when the interval is shorter, the adjustment is an exponential function of the time interval. The negative exponent factor in this exponential function is optimized by the system at regular intervals in order to minimize disagreements between successive anomalies [270], under the hypothesis that all such disagreements are due to burst phenomena and that all agreements occur outside of bursts.

Feedback Relevance Adjustment

[1156] In addition to adjusting the relevance [280] of previously detected anomalies [270], the system also automatically adjusts the relevance of feedback [158] entered by the user in two different situations: feedback decay governs the evolution of feedback relevance over time, while feedback reinforcement describes the impact of recent user feedback on prior feedback.

[1157] First, every time new feedback [158] is given by the user to indicate the actual relevance [280] of a particular anomaly [270] or an entire anomaly class [3200], this feedback [158] will not be given the same importance in the future: this is because a variety of factors inside or outside the corporate environment may totally or partially invalidate that user decision at a later point in time. This mechanism is referred to as feedback decay. Ideally the user would then remove that feedback [158] from the system (which is allowed by the present invention). However the reliability of the anomaly detection scheme cannot depend upon every user remembering to update their manual input whenever the context requires it. In addition, the other automated tuning mechanism (described in the next paragraph) is contingent on later anomalies [270] being presented to the user for confirmation or refutation; if future data happens not to contain any such similarly abnormal events, this alternative tuning mechanism will not be offered to the user. This is why anomaly feedback [158] entered by a user of the system is subjected to natural decay.

[1158] Automatic tuning of the weight of user feedback [158] follows a simple decay scheme so that more recent decisions may optionally be given a greater weight (in this case, a value of relevance [280]) than older ones. The main goal of this mechanism is to avoid false negatives resulting from assigning a constant important over time to past decisions even when the data profile has changed significantly (and also in some cases, when these past decisions are no longer relevant to the users of the system).

[1159] In the default embodiment of the invention, user feedback decay follows an exponential decay scheme—as commonly found for example in voting expert systems. Thus, for example, if the value for the half-life of such feedback [158] is one month, the relevance weight associated with these decisions is halved every month.

[1160] User feedback [160] is given on two main types of objects produced by the invention: anomalies (as part of the anomaly detection process) and changes in the data profile (as part of the data discovery mechanism optionally provided by the data collection component [400]).

[1161] For anomaly feedback [158], the half-life of feedback is optionally adjusted based on the nature of the anomaly, so that the characteristic timescales of the respective actors, data types, and processes involved in the anomaly will be taken into account to compute the feedback half-life for that anomaly.

[1162] For data profile feedback [162], the system configuration governs the definition of the decay parameter. The configurations available include, but are not limited to:

• • [1163] A decay parameter which is proportional to the time elapsed since the change (similarly to the case of anomaly feedback).
  • [1164] A decay parameter which is proportional to the volume of data analyzed (so that for low data throughputs, the decisions will remain valid for a longer period of time).

[1165] In addition to the natural adjustment of feedback weights described previously as feedback decay, the system described in this invention automatically adapts past feedback [158] based on more recent feedback [160] entered by the same or another user: this mechanism, called feedback reinforcement, allows the incorporation of a dynamic knowledge base into the relevance model rather than a static knowledge base built on a case-by-case basis. Furthermore the system guarantees the consistency of relevance decisions with respect to past decisions; additionally, by boosting decisions that have been made multiple times, it also increases the recall rate of actual anomalies [270].

[1166] More precisely, when past feedback [160] is positively reinforced by recent feedback [160], its relevance is increased; when it is negatively reinforced, its relevance is decreased.