Patent Description:
As taught herein, some event data management tools and processes are tailored to improve computing system efficiency by applying an entity extraction rule in a different context than the context where the rule was initially formed, e.g., a context including a different data source or a different user or both. Similarly, some embodiments taught herein enhance the effectiveness of event data parsing by automatically identifying and recommending candidate entity extraction rules instead of requiring users to manually reformulate suitable rules.

Some embodiments for efficient parsing to populate entity properties based on event data which are presented herein include a processor, a digital memory in operable communication with the processor, a set of entity identifiers with each entity identifier having an entity property identifier, an entity extraction rules database containing entity extraction rules with each entity extraction rule specifying a parsing mechanism to parse an entity field of event data, and an entity extraction rule recommender. In operation, the entity extraction rule recommender examines particular event data from an event data source and produces a recommendation. The recommendation cites an entity extraction rule and also targets an entity identifier for use in extracting entity field values from the particular event data and using the extracted entity field values to populate corresponding entity properties.

Some embodiments or embodiment environments presented herein provide or utilize actions that include managing baseline event data from a baseline set of event data sources, collecting multiple entity extraction examples from output of the event data management tool based on the baseline event data, and computing an entity extraction rule based on at least one collected entity extraction example, with each computed entity extraction rule specifying a parsing mechanism to parse at least one entity field. After receiving additional event data from an additional event data source which is not in the baseline set of event data sources, an embodiment applies the parsing mechanism specified by one of the entity extraction rules to extract one or more entity field values from the additional event data and to populate one or more corresponding entity properties using one or more extracted entity field values.

Other technical mechanisms, structures, and activities pertinent to teachings herein will also become apparent to those of skill in the art. The examples given are merely illustrative. Rather, this Summary is provided to introduce - in a simplified form - some technical concepts that are further described below in the Detailed Description. The innovation is defined with claims, and to the extent this Summary conflicts with the claims, the claims should prevail.

A more particular description will be given with reference to the attached drawings. These drawings only illustrate selected aspects and thus do not fully determine coverage or scope.

Many innovations expand beyond their origins, but understanding an innovation's origins can help one more fully appreciate the innovation. In the present case, some teachings presented herein were motivated by a technical challenge of simplifying and improving a process of entity extraction in a Security Information and Event Management (SIEM) product, after recognizing that the existing entity extraction approach took significant time to maintain and required uncommon expertise. Other technical challenges addressed by the innovations taught here will also be apparent to one of skill from the discussion provided below.

In some SIEM systems, users have a way to import custom log data. The SIEM system is unfamiliar with these logs and their structure beforehand. In order for the system to be able to include these logs and their information in advanced scenarios such as data enrichment, behavioral analytics, security alerting, and so on, some mechanism for extracting the important information that is embedded in the logs is required. One may refer this process as "data normalization", as "entity extraction", or as something else, but regardless of the name used a goal is to extract values of interest from a data stream or log or other data source to populate data structures that drive the advanced scenarios to generate alerts, security control activations, visualizations, summaries, filtered or enhanced data, or other useful results.

A given computing environment may include many types of entities, such as an Account, a Host or IP address, and so on. Each entity may have multiple identifier types in different data structures. For example, in some environments running Microsoft® software, an Account can be defined by a SID (security identifier), by a Windows NT® domain name, or a User Principal Name (UPN) (marks of Microsoft Corporation). These are valid identifiers used with different structures. Extracting entities (via their identifiers) may require high expertise, e.g., when a user is called on to define the entity extraction rules in a relatively complex language and also expected to be familiar with the source and target fields.

Some embodiments disclosed herein automatically find and suggest entity extraction rules for source data. This can be accomplished by learning which rules are defined by (relatively advanced) users and applying the learned knowledge to other users. Rules applied by other users, or used against other data sources, or both, can be presented to the user in question as a recommendation for entity extraction. The rule can be automatically used in a service, e.g., as an internal use whose extraction results are provided to the user even though the underlying extraction rule is not made explicit to the user.

For example, assume multiple users have created a mapping from a field that has a structure of a SID (user security identifier) into a SID property of an Account entity (an entity which may be implemented, e.g., as an object or other data structure which digitally represents an account). A SID may look something like "S-<NUM>-<NUM>" or "S-<NUM>-<NUM>-<NUM>". Then a new user accesses a new log type that contains a field with a similar structure. An embodiment may suggest that the user create (or approve) the same entity extraction rule as the previous users.

Some embodiments described herein may be viewed by some people in a broader context. For instance, concepts such as copying, data, parsing, recommendations, and rules may be deemed relevant to a particular embodiment. However, it does not follow from the availability of a broad context that exclusive rights are being sought herein for abstract ideas; they are not. Rather, the present disclosure is focused on providing appropriately specific embodiments whose technical effects fully or partially solve particular technical problems, such as how to efficiently recommend tool extensions that tend to make development more productive. Other configured storage media, systems, and methods involving copying, data, parsing, recommendations, or rules are outside the present scope. Accordingly, vagueness, mere abstractness, lack of technical character, and accompanying proof problems are also avoided under a proper understanding of the present disclosure.

More generally, one of skill will recognize that not every part of this disclosure, or any particular details therein, are necessarily required to satisfy legal criteria such as enablement, written description, or best mode. Also, embodiments are not limited to the particular programming languages, tools, contexts, identifiers, fields, properties, files, or other implementation choices described herein. Any apparent conflict with any other patent disclosure, even from the owner of the present innovations, has no role in interpreting the claims presented in this patent disclosure.

The technical character of embodiments described herein will be apparent to one of ordinary skill in the art, and will also be apparent in several ways to a wide range of attentive readers. Some embodiments address technical activities that are rooted in computing technology and improve the functioning of computing systems by making those systems more efficient. Specifically, some embodiments increase data parsing efficiency by expanding the contexts in which a data extraction rule is applied. Without the context expansion, parsing would be done only after the delay inherent in reformulating suitable extraction rules, or would not be done at all. Likewise, security, usability, and other characteristics that rely on prompt parsing of gigabytes of data are improved when parsing occurs sooner and more broadly than would have been the case if the entity extraction rules that define parsing mechanisms were reformulated instead of being ported to new contexts. Other advantages based on the technical characteristics of the teachings will also be apparent to one of skill from the description provided.

Some acronyms, abbreviations, and names are defined below. Others are defined elsewhere herein, or do not require definition here in order to be understood by one of skill.

The meaning of terms is clarified in this disclosure, so the claims should be read with careful attention to these clarifications. Specific examples are given, but those of skill in the relevant art(s) will understand that other examples may also fall within the meaning of the terms used, and within the scope of one or more claims. Terms do not necessarily have the same meaning here that they have in general usage (particularly in non-technical usage), or in the usage of a particular industry, or in a particular dictionary or set of dictionaries. Reference numerals may be used with various phrasings, to help show the breadth of a term. Omission of a reference numeral from a given piece of text does not necessarily mean that the content of a Figure is not being discussed by the text. The inventors assert and exercise the right to specific and chosen lexicography. Quoted terms are being defined explicitly, but a term may also be defined implicitly without using quotation marks. Terms may be defined, either explicitly or implicitly, here in the Detailed Description and/or elsewhere in the application file.

As used herein, a "computer system" may include, for example, one or more servers, motherboards, processing nodes, laptops, tablets, personal computers (portable or not), personal digital assistants, smartphones, smartwatches, smartbands, cell or mobile phones, other mobile devices having at least a processor and a memory, video game systems, augmented reality systems, holographic projection systems, televisions, wearable computing systems, and/or other device(s) providing one or more processors controlled at least in part by instructions. The instructions may be in the form of firmware or other software in memory and/or specialized circuitry.

A "multithreaded" computer system is a computer system which supports multiple execution threads. The term "thread" should be understood to include any code capable of or subject to scheduling (and possibly to synchronization), and may also be known by another name, such as "task," "process," or "coroutine," for example. The threads may run in parallel, in sequence, or in a combination of parallel execution (e.g., multiprocessing) and sequential execution (e.g., time-sliced).

A "processor" is a thread-processing unit, such as a core in a simultaneous multithreading implementation. A processor includes hardware. A given chip may hold one or more processors. Processors may be general purpose, or they may be tailored for specific uses such as vector processing, graphics processing, signal processing, floating-point arithmetic processing, encryption, I/O processing, and so on.

"Kernels" include operating systems, hypervisors, virtual machines, BIOS code, and similar hardware interface software.

"Code" means processor instructions, data (which includes constants, variables, and data structures), or both instructions and data. "Code" by itself and "software" are used interchangeably herein. Executable code, interpreted code, and firmware are some examples of code. Code which must be interpreted or compiled in order to execute is referred to as "source code".

"Program" is used broadly herein, to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, services, cloud infrastructure components, middleware, and other code written by programmers (who are also referred to as developers) and/or automatically generated.

"Service" means a consumable program offering in a cloud computing environment or other network or computing system environment.

"Cloud" means pooled resources for computing, storage, and networking which are elastically available for measured on-demand service. A cloud may be private (e.g., on-premises), public, community, or a hybrid, and cloud services may be offered in the form of infrastructure as a service, platform as a service, software as a service, or another service. Unless stated otherwise, any discussion of reading from a file or writing to a file includes reading/writing a local file or reading/writing over a network, which may be a cloud network or other network, or doing both (local and networked read/write).

Unless otherwise indicated, "field" refers to data or a data location in a data source such as a data stream or a log, whereas "property" refers to data or a data location in an object or other data structure that represents an entity. Thus, data is said to be extracted from a field and placed in a property.

For present purposes, "entity extraction rules" includes, e.g., rules for extracting two or more field values into respective properties of an entity, rules for extracting two or more field values into respective properties which are associated with multiple entities, and rules for extracting a single field value into a single property or another destination. Accordingly, some entity extraction rules may also be accurately referred to as "property extraction rules" or "field extraction rules" or the like.

As used herein, "include" allows additional elements (i.e., includes means comprises) unless otherwise stated.

"Optimize" means to improve, not necessarily to perfect. For example, it may be possible to make further improvements in a program or an algorithm which has been optimized.

"Process" is sometimes used herein as a term of the computing science arts, and in that technical sense encompasses resource users, namely, coroutines, threads, tasks, interrupt handlers, application processes, kernel processes, procedures, and object methods, for example. "Process" is also used herein as a patent law term of art, e.g., in describing a process claim as opposed to a system claim or an article of manufacture (configured storage medium) claim. Similarly, "method" is used herein at times as a technical term in the computing science arts (a kind of "routine") and also as a patent law term of art (a "process"). Those of skill will understand which meaning is intended in a particular instance, and will also understand that a given claimed process or method (in the patent law sense) may sometimes be implemented using one or more processes or methods (in the computing science sense).

"Automatically" means by use of automation (e.g., general purpose computing hardware configured by software for specific operations and technical effects discussed herein), as opposed to without automation. In particular, steps performed "automatically" are not performed by hand on paper or in a person's mind, although they may be initiated by a human person or guided interactively by a human person. Automatic steps are performed with a machine in order to obtain one or more technical effects that would not be realized without the technical interactions thus provided.

One of skill understands that technical effects are the presumptive purpose of a technical embodiment. The mere fact that calculation is involved in an embodiment, for example, and that some calculations can also be performed without technical components (e.g., by paper and pencil, or even as mental steps) does not remove the presence of the technical effects or alter the concrete and technical nature of the embodiment. Operations such as parsing data to identify a field value, copying data into an entity or other object, populating properties with field values, updating a database of extraction rules, calculating an extraction rule correctness certainty value, and modifying a computing system display device are understood herein as inherently digital. A human mind cannot interface directly with a CPU or network interface card or other processor, or with RAM or other digital storage, to read and write the necessary data and perform the necessary operations on digital values to perform the entity extraction and other data processing steps taught herein. This would be well understood by persons of skill in the art in view of the present disclosure, but others may sometimes need to be informed or reminded of the facts. Unless stated otherwise, embodiments are also presumed to be capable of operating at scale (i.e., one gigabyte or more of event data into or through a system per day) in production environments, or in testing labs for production environments, as opposed to being mere thought experiments.

"Computationally" likewise means a computing device (processor plus memory, at least) is being used, and excludes obtaining a result by mere human thought or mere human action alone. For example, doing arithmetic with a paper and pencil is not doing arithmetic computationally as understood herein. Computational results are faster, broader, deeper, more accurate, more consistent, more comprehensive, and/or otherwise provide technical effects that are beyond the scope of human performance alone. "Computational steps" are steps performed computationally. Neither "automatically" nor "computationally" necessarily means "immediately". "Computationally" and "automatically" are used interchangeably herein.

"Proactively" means without a direct request from a user. Indeed, a user may not even realize that a proactive step by an embodiment was possible until a result of the step has been presented to the user. Except as otherwise stated, any computational and/or automatic step described herein may also be done proactively.

Throughout this document, use of the optional plural "(s)", "(es)", or "(ies)" means that one or more of the indicated features is present. For example, "processor(s)" means "one or more processors" or equivalently "at least one processor".

For the purposes of United States law and practice, use of the word "step" herein, in the claims or elsewhere, is not intended to invoke means-plus-function, step-plus-function, or <NUM> United State Code Section <NUM> Sixth Paragraph / Section <NUM>(f) claim interpretation. Any presumption to that effect is hereby explicitly rebutted.

For the purposes of United States law and practice, the claims are not intended to invoke means-plus-function interpretation unless they use the phrase "means for". Claim language intended to be interpreted as means-plus-function language, if any, will expressly recite that intention by using the phrase "means for". When means-plus-function interpretation applies, whether by use of "means for" and/or by a court's legal construction of claim language, the means recited in the specification for a given noun or a given verb should be understood to be linked to the claim language and linked together herein by virtue of any of the following: appearance within the same block in a block diagram of the figures, denotation by the same or a similar name, denotation by the same reference numeral, a functional relationship depicted in any of the figures, a functional relationship noted in the present disclosure's text. For example, if a claim limitation recited a "zac widget" and that claim limitation became subject to means-plus-function interpretation, then at a minimum all structures identified anywhere in the specification in any figure block, paragraph, or example mentioning "zac widget", or tied together by any reference numeral assigned to a zac widget, or disclosed as having a functional relationship with the structure or operation of a zac widget, would be deemed part of the structures identified in the application for zac widgets and would help define the set of equivalents for zac widget structures.

Throughout this document, unless expressly stated otherwise any reference to a step in a process presumes that the step may be performed directly by a party of interest and/or performed indirectly by the party through intervening mechanisms and/or intervening entities, and still lie within the scope of the step. That is, direct performance of the step by the party of interest is not required unless direct performance is an expressly stated requirement. For example, a step involving action by a party of interest such as applying, assigning, calculating, citing, collecting, computing, determining, displaying, executing, extracting, getting, identifying, managing, mapping, parsing, performing, populating, producing, querying, receiving, recommending, sending, specifying, targeting (and applies, applied, assigns, assigned, etc.) with regard to a destination or other subject may involve intervening action such as forwarding, copying, uploading, downloading, encoding, decoding, compressing, decompressing, encrypting, decrypting, authenticating, invoking, and so on by some other party, yet still be understood as being performed directly by the party of interest.

Whenever reference is made to data or instructions, it is understood that these items configure a computer-readable memory and/or computer-readable storage medium, thereby transforming it to a particular article, as opposed to simply existing on paper, in a person's mind, or as a mere signal being propagated on a wire, for example. For the purposes of patent protection in the United States, a memory or other computer-readable storage medium is not a propagating signal or a carrier wave or mere energy outside the scope of patentable subject matter under United States Patent and Trademark Office (USPTO) interpretation of the In re Nuijten case. No claim covers a signal per se or mere energy in the United States, and any claim interpretation that asserts otherwise in view of the present disclosure is unreasonable on its face. Unless expressly stated otherwise in a claim granted outside the United States, a claim does not cover a signal per se or mere energy.

Moreover, notwithstanding anything apparently to the contrary elsewhere herein, a clear distinction is to be understood between (a) computer readable storage media and computer readable memory, on the one hand, and (b) transmission media, also referred to as signal media, on the other hand. A transmission medium is a propagating signal or a carrier wave computer readable medium. By contrast, computer readable storage media and computer readable memory are not propagating signal or carrier wave computer readable media. Unless expressly stated otherwise in the claim, "computer readable medium" means a computer readable storage medium, not a propagating signal per se and not mere energy.

An "embodiment" herein is an example. The term "embodiment" is not interchangeable with "the invention". Embodiments may freely share or borrow aspects to create other embodiments (provided the result is operable), even if a resulting combination of aspects is not explicitly described per se herein. Requiring each and every permitted combination to be explicitly and individually described is unnecessary for one of skill in the art, and would be contrary to policies which recognize that patent specifications are written for readers who are skilled in the art. Formal combinatorial calculations and informal common intuition regarding the number of possible combinations arising from even a small number of combinable features will also indicate that a large number of aspect combinations exist for the aspects described herein. Accordingly, requiring an explicit recitation of each and every combination would be contrary to policies calling for patent specifications to be concise and for readers to be knowledgeable in the technical fields concerned.

The following list is provided for convenience and in support of the drawing figures and as part of the text of the specification, which describe innovations by reference to multiple items. Items not listed here may nonetheless be part of a given embodiment. For better legibility of the text, a given reference number is recited near some, but not all, recitations of the referenced item in the text. The same reference number may be used with reference to different examples or different instances of a given item. The list of reference numerals is:.

With reference to <FIG>, an operating environment <NUM> for an embodiment includes at least one computer system <NUM>. The computer system <NUM> may be a multiprocessor computer system, or not. An operating environment may include one or more machines in a given computer system, which may be clustered, client-server networked, and/or peer-to-peer networked within a cloud. An individual machine is a computer system, and a group of cooperating machines is also a computer system. A given computer system <NUM> may be configured for end-users, e.g., with applications, for administrators, as a server, as a distributed processing node, and/or in other ways.

Human users <NUM> may interact with the computer system <NUM> by using displays, keyboards, and other peripherals <NUM>, via typed text, touch, voice, movement, computer vision, gestures, and/or other forms of I/O. A screen <NUM> may be a removable peripheral <NUM> or may be an integral part of the system <NUM>. A user interface may support interaction between an embodiment and one or more human users. A user interface may include a command line interface, a graphical user interface (GUI), natural user interface (NUI), voice command interface, and/or other user interface (UI) presentations, which may be presented as distinct options or may be integrated.

System administrators, network administrators, software developers, hardware developers, engineers, security personnel, and end-users are each a particular type of user <NUM>, although it is contemplated that most users will likely be administrators or security personnel who are end-users of an event data management tool. Automated agents, scripts, playback software, and the like acting on behalf of one or more people may also be users <NUM>, e.g., to facilitate testing a system <NUM>, but end-users are people (not processes) unless clearly indicated otherwise. Storage devices and/or networking devices may be considered peripheral equipment in some embodiments and part of a system <NUM> in other embodiments, depending on their detachability from the processor <NUM>. Other computer systems not shown in <FIG> may interact in technological ways with the computer system <NUM> or with another system embodiment using one or more connections to a network <NUM> via network interface equipment, for example.

Each computer system <NUM> includes at least one processor <NUM>. The computer system <NUM>, like other suitable systems, also includes one or more computer-readable storage media <NUM>. Storage media <NUM> may be of different physical types. The storage media <NUM> may be volatile memory, non-volatile memory, fixed in place media, removable media, magnetic media, optical media, solid-state media, and/or of other types of physical durable storage media (as opposed to merely a propagated signal or mere energy). In particular, a configured storage medium <NUM> such as a portable (i.e., external) hard drive, CD, DVD, memory stick, or other removable non-volatile memory medium may become functionally a technological part of the computer system when inserted or otherwise installed, making its content accessible for interaction with and use by processor <NUM>. The removable configured storage medium <NUM> is an example of a computer-readable storage medium <NUM>. Some other examples of computer-readable storage media <NUM> include built-in RAM, ROM, hard disks, and other memory storage devices which are not readily removable by users <NUM>. For compliance with current United States patent requirements, neither a computer-readable medium nor a computer-readable storage medium nor a computer-readable memory is a signal per se or mere energy under any claim pending or granted in the United States.

The storage medium <NUM> is configured with binary instructions <NUM> that are executable by a processor <NUM>; "executable" is used in a broad sense herein to include machine code, interpretable code, bytecode, and/or code that runs on a virtual machine, for example. The storage medium <NUM> is also configured with data <NUM> which is created, modified, referenced, and/or otherwise used for technical effect by execution of the instructions <NUM>. The instructions <NUM> and the data <NUM> configure the memory or other storage medium <NUM> in which they reside; when that memory or other computer readable storage medium is a functional part of a given computer system, the instructions <NUM> and data <NUM> also configure that computer system. In some embodiments, a portion of the data <NUM> is representative of real-world items such as product characteristics, inventories, physical measurements, settings, images, readings, targets, volumes, and so forth. Such data is also transformed by backup, restore, commits, aborts, reformatting, and/or other technical operations.

Although an embodiment may be described as being implemented as software instructions executed by one or more processors in a computing device (e.g., general purpose computer, server, or cluster), such description is not meant to exhaust all possible embodiments. One of skill will understand that the same or similar functionality can also often be implemented, in whole or in part, directly in hardware logic, to provide the same or similar technical effects. Alternatively, or in addition to software implementation, the technical functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without excluding other implementations, an embodiment may include hardware logic components <NUM>, <NUM> such as Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip components (SOCs), Complex Programmable Logic Devices (CPLDs), and similar components. Components of an embodiment may be grouped into interacting functional modules based on their inputs, outputs, and/or their technical effects, for example.

In addition to processors <NUM> (e.g., CPUs, ALUs, FPUs, and/or GPUs), memory / storage media <NUM>, and displays <NUM>, an operating environment may also include other hardware <NUM>, such as batteries, buses, power supplies, wired and wireless network interface cards, for instance. The nouns "screen" and "display" are used interchangeably herein. A display <NUM> may include one or more touch screens, screens responsive to input from a pen or tablet, or screens which operate solely for output. In some embodiments peripherals <NUM> such as human user I/O devices (screen, keyboard, mouse, tablet, microphone, speaker, motion sensor, etc.) will be present in operable communication with one or more processors <NUM> and memory. Software processes may be users <NUM>, but unless clearly indicated otherwise, end-users are human.

In some embodiments, the system includes multiple computers connected by a network <NUM>. Networking interface equipment <NUM> can provide access to networks <NUM>, using components such as a packet-switched network interface card, a wireless transceiver, or a telephone network interface, for example, which may be present in a given computer system. However, an embodiment may also communicate technical data and/or technical instructions through direct memory access, removable nonvolatile storage media, or other information storage-retrieval and/or transmission approaches.

One of skill will appreciate that the foregoing aspects and other aspects presented herein under "Operating Environments" may form part of a given embodiment. This document's headings are not intended to provide a strict classification of features into embodiment and non-embodiment feature sets.

One or more items are shown in outline form in the Figures, or listed inside parentheses, to emphasize that they are not necessarily part of the illustrated operating environment or all embodiments, but may interoperate with items in the operating environment or some embodiments as discussed herein. It does not follow that items not in outline or parenthetical form are necessarily required, in any Figure or any embodiment. In particular, <FIG> is provided for convenience; inclusion of an item in <FIG> does not imply that the item, or the described use of the item, was known prior to the current innovations.

Examples are provided herein to help illustrate aspects of the technology, but the examples given within this document do not describe all of the possible embodiments. Embodiments are not limited to the specific configurations, implementations, arrangements, displays, features, groupings, approaches, or scenarios provided herein. A given embodiment may include additional or different technical features, mechanisms, sequences, components, or data structures, for instance, and may otherwise depart from the examples provided herein.

<FIG> illustrates aspects of some event data processing architectures that are suitable for some embodiments taught herein. Event data <NUM> is obtained from one or more event sources <NUM> such as logs, data streams, monitoring agents, Splunk® forwarders (mark of Splunk, Inc. ), or similar software. Field values <NUM> are embedded within the event data. The event data is consumed by an event data management tool <NUM>, <NUM>, which generally has a user interface <NUM> and code for processing the event data. In particular, the tool <NUM> may have monitoring code <NUM> or alerting code <NUM>. Instead of working directly with the event data in the raw form sent by the data source, the tool <NUM> extracts values from fields <NUM> that are found in the raw data and places copies of the found values in properties <NUM> of objects or of other entities <NUM> that have semantics tailored for the monitoring, alerting, visualization, behavior analysis, and other processing that can be done through the tool <NUM>.

The field value extraction is implemented using parsing mechanisms <NUM> of entity extraction rules <NUM>. The entity extraction rules allow the tool <NUM> to locate IP addresses or usernames, for example, in the raw data <NUM>, and to parse the IP address values <NUM>, username values <NUM>, and so on, in order to separate them from the surrounding raw data. The entity extraction rules <NUM> also indicate where the located values should be placed, that is, which values <NUM> should be copied into which properties <NUM> of which entities <NUM>.

<FIG> illustrates some examples of entity properties <NUM>. Properties can be described in various ways, e.g., by their names, the entity(ies) they are used in, their data type, or their semantic functionality. As shown, the semantic functionality of properties may include identifying users, identifying domains, identifying virtual or physical machines, identify digital or non-digital locations, and identifying security controls.

<FIG> illustrates some examples of entity extraction rules <NUM>. Rules <NUM> can be described in various ways, e.g., by their names, by the field(s) or property(ies) or entity(ies) they are used with, by the data type of extracted values, or by the rules' syntax assumptions or capabilities. As shown, rules may be characterized in particular by whether they parse JSON formatted data, by whether they define or use a regular expression, or by which characters are assigned special roles such as field separators. <FIG> presents only some of the many possible examples of extraction rules, and one of skill will acknowledge that field values may be located in event data using other parsing mechanisms which are not specifically shown, e.g., comma-separated value (CSV) formats, XML formats, and formats particular to a given programming language.

<FIG> adds to the rule modeling aspects <NUM> shown in <FIG>. In particular, <FIG> shows queries <NUM> and query results <NUM>. Some event data management tools <NUM> pose queries <NUM> which search event data and produce results <NUM>. To produce query results, the tool <NUM> applies entity extraction rules <NUM> to obtain field values from event data, and then performs further processing using the extracted values to obtain a useful outcome for the user. As just a few of the many possibilities, a query <NUM> might seek as a result <NUM> the names of all host machines <NUM> which received a ping request in the past hour, or the source IP addresses of all failed login attempts during the past day, or the organizational units whose traffic currently includes more than ten percent of the total VoIP traffic. Other items shown in <FIG>, and items presented in <FIG>, are discussed elsewhere herein.

Some embodiments provide or utilize an entity extraction system for efficient parsing to populate entity properties based on event data. An illustrative system includes a processor <NUM>, a digital memory <NUM> in operable communication with the processor <NUM>, and a set of entity identifiers <NUM> with each entity identifier including at least one entity property identifier <NUM>. This example system also includes an entity extraction rules database <NUM> containing a plurality of entity extraction rules <NUM>. Each entity extraction rule specifies a parsing mechanism <NUM> to parse at least one entity field <NUM> of event data <NUM>. This example system also includes an entity extraction rule recommender <NUM> which, upon execution by the processor, examines particular event data from an event data source <NUM> and produces a recommendation <NUM>. The recommendation <NUM> cites at least one entity extraction rule <NUM> and also targets at least one entity identifier <NUM>. The recommendation effectively recommends the cited rule <NUM> for use in extracting one or more entity field values <NUM> from the particular event data and for using the one or more extracted entity field values to populate one or more corresponding entity properties <NUM>.

Some embodiments further include an entity parser <NUM>. Upon execution, the parser <NUM> receives the recommendation <NUM> and applies the parsing mechanism <NUM> specified by the entity extraction rule (the rule cited in the recommendation) to extract one or more entity field values <NUM> from the particular event data and to populate one or more corresponding entity properties <NUM> using the one or more extracted entity field values.

Some embodiments include a user interface <NUM>, which does not necessarily reside in the tool <NUM>, or even on the same machine as the tool <NUM>. The rule <NUM> is located in or through the entity extraction rules database <NUM>. In this example, the entity parsing recommender <NUM> also recommends at least one entity identifier <NUM>, along with the recommended rule <NUM>, as being items which correspond to the particular event data <NUM> and hence could be used to fruitfully process that data.

In some embodiments, the entity properties <NUM> identified in the set of entity identifiers <NUM> include at least two of the following: a user identification property <NUM>, a domain identification property <NUM>, an access control identification property <NUM>, a security property <NUM>, a non-digital-location identification property <NUM>, a digital-location identification property <NUM>, a physical machine identification property <NUM>, or a virtual machine identification property <NUM>.

In some embodiments, the entity extraction rules <NUM> in the entity extraction rules database <NUM> include at least one of the following: a rule <NUM> which extracts at least one entity field value from event data <NUM> that has a JSON format, a rule <NUM> which includes a regular expression definition <NUM>, or a rule which identifies a particular character <NUM> as being a data splitting character <NUM>.

Some embodiments include an entity extraction example collector <NUM> which upon execution collects at least one entity extraction example <NUM>. In some embodiments, at least one collected entity extraction example in the system includes a query directed at event data.

Some embodiments include an entity extraction rules modeler <NUM> which upon execution computes an entity extraction rule <NUM> based on at least one collected entity extraction example <NUM>, and which alters the entity extraction rules database <NUM> to include the computed entity extraction rule in the database.

In some embodiments, the entity extraction rules modeler includes a frequency calculation code <NUM> which calculates a relative or absolute frequency <NUM> of candidate entity extraction rules, to allow the entity extraction rules modeler <NUM> to favor rules <NUM> that have greater frequency than other rules. Some embodiments generate a model which is frequency based using an edit distance metric. For example, a regular expression that is in common use may be considered as a common entity extraction rule and be proposed to other users.

When rules have the same frequency, or as an alternative to using frequency, an edit distance metric may be used. An edit distance metric pertains to words which are similar but not equal. For example, a distance can be measured between "username", "username1", and "myusername", e.g., by the number of single-character operations (deletion, addition, or substitution) which is sufficient to transform one word to another word. The edit distance metric defines the distance (i.e., similarity) between the words. Similar words ("user", "user1") are closer to each other than less-similar words ("user", "host").

In some embodiments, the entity extraction rules modeler includes a machine learning classifier <NUM> that is trained to classify candidate rules according to their resemblance to other rules that have been applied to a similar data source, or applied to populate the same or similar entities <NUM>, to allow the entity extraction rules modeler <NUM> to favor candidate rules <NUM> that have been classified as sufficiently close to positively scored training set rules. In some embodiments, the classifier <NUM> is trained on a set of {data sources, extraction object} tuples, and then when a new data source is observed the classifier predicts the extraction object. One suitable classifier <NUM> technology is neural networks technology.

Other system embodiments are also described herein, either directly or derivable as system versions of described methods or configured media, informed by the extension discussion herein of computing hardware.

Technical methods shown in the Figures or otherwise disclosed will be performed automatically, e.g., by an enhanced event data management tool <NUM> having one or more of the enhancement components <NUM>, unless otherwise indicated. No method contemplated as innovative herein is entirely manual. In a given embodiment zero or more illustrated steps of a method may be repeated, perhaps with different parameters or data to operate on. Steps in an embodiment may also be done in a different order than the top-to-bottom order that is laid out in <FIG>. Steps may be performed serially, in a partially overlapping manner, or fully in parallel. In particular, the order in which the flowchart <NUM> is traversed to indicate the steps performed during a method may vary from one performance of the method to another performance of the method. The flowchart traversal order may also vary from one method embodiment to another method embodiment. Steps may also be omitted, combined, renamed, regrouped, be performed on one or more machines, or otherwise depart from the illustrated flow, provided that the method performed is operable and conforms to at least one claim.

With reference to <FIG>, some embodiments provide or use an entity extraction method for efficient parsing to populate entity properties based on event data. Methods may be considered from an administrator perspective which includes data processing activities of an event data management tool and activities that enhance entity extraction to support that data processing.

In one example, an event data processing and entity extraction method includes an event data management tool <NUM> managing <NUM> baseline event data from a baseline set of event data sources. An entity extraction enhancer <NUM> (which may be integrated in the tool <NUM> or external to it) collects <NUM> multiple entity extraction examples from one or more outputs of the event data management tool based on the baseline event data, and computes <NUM> with a digital processor at least one entity extraction rule <NUM> based on at least one collected entity extraction example. Each computed entity extraction rule specifies <NUM> a parsing mechanism <NUM> to parse at least one entity field. The event data management tool receives <NUM> additional event data from an additional event data source which is not in the baseline set of event data sources. The entity extraction enhancer <NUM> applies <NUM> the parsing mechanism specified by one of the entity extraction rules to extract <NUM> one or more entity field values from the additional event data and to populate <NUM> one or more corresponding entity properties using the one or more extracted entity field values.

In some embodiments, collecting <NUM> multiple entity extraction examples includes collecting <NUM> queries <NUM> written by users and collecting <NUM> results <NUM> of the queries.

In some embodiments, computing <NUM> an entity extraction rule includes determining <NUM> a mapping from a column name <NUM> to an entity property <NUM>.

Some embodiments assign <NUM> a correctness certainty level <NUM> to an entity extraction rule. As one example of many possible examples showing how the correctness certainty level could be calculated and used, assume there is historical data for <NUM> users who manually extracted IP address value into an entity. Assume <NUM> of these users took the value <NUM> that was stored in a column named "IP_Address", and the other <NUM> users did different things, e.g., <NUM> users took the value from a column named "DestAddress", <NUM> users employed a regular expression on data in a column called "Meta data", and so on. The output in each extraction matched a template of the form #. #, as expected for an IPv4 address in dot decimal format).

In this situation, assume as a first case that a new user connects to a new data source, wherein the data source has a column called "IP_Address" and contains data matching the #. This context matches the similar behavioral context of the <NUM> out of <NUM> users in the historical data. The correctness certainty level could this be calculated as <NUM> out of <NUM>, or <NUM>%, or on a normalized scale between zero and one as <NUM>.

By contrast, suppose that in a second case a new user connects to a new data source, wherein the data source has a column called "Meta data" containing free text which in some cases includes a substring matching the #. This context matches the similar behavioral context of <NUM> of the <NUM> users in the historical data. The correctness certainty level could this be calculated as <NUM> out of <NUM>, or <NUM>%, or on a normalized scale between zero and one as <NUM>. Regardless of the particular scale used, the certainty in the first case is much higher than in the second case.

In some embodiments and some situations, the event data contains sufficient values <NUM> to populate every property <NUM> of a given entity. In other cases, no value corresponding to a given property (or given set of properties) is present in the event data. Regardless of whether sufficient values are present in the event data, one or more properties may go unpopulated. For instance, a user is represented in different ways by different systems. For example, many systems employ the user alias as an identifier <NUM>. Microsoft Active Directory® products use a GUID to identify a user and call that property ObjectID. Some applications know the user's geo-location and can add it to the entity that represents the user, while other applications don't have that information. Accordingly, in some embodiments the extraction method populates <NUM> between <NUM> and N-<NUM> of the properties of an entity which has N properties, where N is greater than <NUM>.

Some embodiments include a configured computer-readable storage medium <NUM>. Storage medium <NUM> may include disks (magnetic, optical, or otherwise), RAM, EEPROMS or other ROMs, and/or other configurable memory, including in particular computer-readable storage media (which are not mere propagated signals). The storage medium which is configured may be in particular a removable storage medium <NUM> such as a CD, DVD, or flash memory. A general-purpose memory, which may be removable or not, and may be volatile or not, can be configured into an embodiment using items such as an entity extraction rules database <NUM>, entity extraction rules modeler <NUM>, entity extraction example collector <NUM>, entity extraction rule recommender <NUM>, or entity extraction rule recommendation <NUM>, or combination thereof, in the form of data <NUM> and instructions <NUM>, read from a removable storage medium <NUM> and/or another source such as a network connection, to form a configured storage medium. The configured storage medium <NUM> is capable of causing a computer system to perform technical process steps for entity extraction rules harvesting and performance, as disclosed herein. The Figures thus help illustrate configured storage media embodiments and process embodiments, as well as system and process embodiments. In particular, any of the process steps illustrated in <FIG>, or otherwise taught herein, may be used to help configure a storage medium to form a configured storage medium embodiment.

Some embodiments provide or use an entity extraction method for efficient parsing to populate entity properties based on event data. Some methods may be viewed from an extraction enhancement perspective.

In some embodiments, a storage medium <NUM> is configured with code which upon execution by one or more processors <NUM> performs an entity extraction method for efficient parsing to populate entity properties based on event data. In one example, the method includes collecting <NUM> multiple entity extraction examples from one or more outputs of an event data management tool based on baseline event data, computing <NUM> an entity extraction rule based on at least one collected entity extraction example (with the computed entity extraction rule specifying <NUM> a parsing mechanism to parse at least one entity field, altering <NUM> an entity extraction rules database to include the computed entity extraction rule in the database, and applying <NUM> the parsing mechanism specified by the entity extraction rule to extract <NUM> one or more entity field values from additional event data and to populate <NUM> one or more corresponding entity properties using the one or more extracted entity field values.

In some embodiments, the method further includes displaying <NUM> to a user an association indicating that a set of entity properties are associated with a particular computing technology product <NUM> which is not the event data management tool or any tool performing the method. For instance, entities and properties associated with a word processor, spreadsheet, intrusion detection program, intrusion prevention program, anti-malware program, order processing application, database management program, operating system, web browser, or other software product could be displayed <NUM>.

In some embodiments, the method further includes displaying <NUM> to a user multiple property names which each correspond to the same entity field. For instance, an IP address field <NUM> might correspond to IP_Address, IP, SrcAddress, and DestAddress properties. <FIG> also show examples in which a data field corresponds to different column names and through them to various entity properties.

In some embodiments, the method collects <NUM> one or more entity extraction examples, computes <NUM> an entity extraction rule based on those collected entity extraction examples, alters <NUM> the entity extraction rules database to include the computed entity extraction rule, and applies <NUM> the parsing mechanism specified by the entity extraction rule to extract one or more entity field values from additional event data and to populate one or more corresponding entity properties using the one or more extracted entity field values; this set of actions collectively constitutes performing <NUM> efficient parsing. In some cases with some embodiments, a total real-world time occupied by said collecting, computing, altering, and applying (i.e., performing <NUM>) is less than X, where X is thirty seconds. In some cases, X is fifteen seconds. In some, X is one minute.

In most of not all cases, however, the maximum entity extraction performance time X is less than the average time it would take a human user to search through available data, select an extraction rule from a set of visually displayed rules or formulate a new rule based on rules previously used by other users or previously used against other data sources, and apply the selected rule. The human user would not, for instance, have access to a database of rules that includes rules applied in other contexts, rule derived from queries, rules with assigned correctness certainty levels, and other structures and procedures described herein. As a result, taking advantage of the teachings herein substantially improves the harvesting and performance of entity extraction rules to support visualizations, analyses, and other event data processing operations.

Some embodiments use or provide a system or method to automatically extract entities from security events and alerts based on a form of crowdsourcing. Some learn the entities <NUM> to be extracted from the event data <NUM> by watching what other users <NUM> did, and consolidate or construct a model <NUM> and generate recommendations <NUM> based on that model.

In some cases, the set of possible entities <NUM> is known and defined by a particular product <NUM>. For example, some products have a UserAccount entity <NUM> with properties UserName, Domain, SID, Location, and others. Some have an Endpoint entity <NUM> with properties IPaddress and Port. Some have a Machine entity <NUM> with properties MachineName, ComputerName. One of skill will recognize that these are just of few of the many possibilities. In this example, and with reference to <FIG>, UserName is a user identification property <NUM>, Domain is a domain identification property <NUM>, SID is an access control identification property <NUM> and also a security property <NUM>, Location is a non-digital location identification property <NUM>, IPaddress and Port are each a digital location identification property <NUM>, and so on.

In some cases, automatically extracting entities <NUM> and their properties <NUM> from data of a given data source <NUM> is based on an understanding of a schema of the data and the way information is saved in the data at the data source. By way of illustration, <FIG>, and <FIG> show some data schemas. All three Figures show the same field values, but the values are embedded in data <NUM> in different ways, by different data sources.

In order to extract into the UserAccount entity from data of a first data source (<FIG>), the following query can be used:
SELECT User AS UserAccount. UserName,
Domain AS UserAccount. Domain,
ExtractJson(MoreData. UserSID) AS UserAccount. SID
FROM DataSource1.

In order to extract into the UserAccount entity from data of a second data source (<FIG>), the following query can be used:
SELECT splitSlash(ExtractJson(UserDetails. user), 'after') AS UserAccount. UserName,
splitSlash(ExtractJson(UserDetails. user), 'before') AS UserAccount. Domain,
ExtractJson(UserDetails. userSID) AS UserAccount. SID
FROM DataSource2.

In order to extract into the UserAccount entity from data of a third data source (<FIG>), the following query can be used:
SELECT regex(Trace, "*\[] '(S-*") AS UserAccount. UserName,
regex(Trace, "User '[]\ '(S-*") AS UserAccount. Domain,
regex(Trace, "*('[]')*") AS UserAccount. SID
FROM DataSource3.

One of skill will understand that the MoreData and User Details fields contain data in a JSON format, that the line wrapping present in the query of DataSource2 as formatted in this disclosure has no semantic or functional effect, that DataSource2 uses a slash character as a data splitting character, that DataSource3 data is in a form often used by traces, that "regex" stands for "regular expression", that entities are not limited to those used with Microsoft® products, and that the IP address values shown in this disclosure have been sanitized whereas in a production environment the data <NUM> may well include public routable IP addresses.

The extracted property values for all three queries above is the same. This example also illustrates populating less than all of the properties of the UserAccount entity. Once the correct values are in the correct properties, populated entities and their connections can be used to generate new security alerts and to investigate them, for example. However, because an understanding of data formats and item names is involved, the underlying actions for locating desired data and extracting it into entities can be frustrating and very prone to mistakes when done manually. Teachings presented herein can assist users by reducing or removing reliance of specific technical details, and can help a system monitor data for changes.

<FIG> shows an example portion of a recommendation <NUM>, in the form of a result of applying a recommended extraction rule. The results could be displayed <NUM> with text such as "We noticed a new data source was added lately. Do the examples below accurately reflect the UserAccount?" and response buttons. One response button could be labeled "Let me review" or the like. Pressing this button will show the user additional info, such as a query created to extract values <NUM>. The query may be editable by the user. Another response button could be labeled "Yes, map entity" or the like. Pressing this button will map the entity using the recommended rule, and start generating populated entities for existing data or newly added data.

As an additional architectural example, some embodiments operate in three phases:.

Phase I - Collecting Learning Data. In order to make recommendations <NUM> to users regarding entity extraction, a system is taught what are the entities <NUM>, what form the entities take, and how users have previously extracted values into them. Based on that knowledge, one can generate a model. Data of users who already mapped their data sources to entities is collected <NUM>. The data collection includes collecting <NUM> such as queries the users wrote and their results <NUM>. Other implicit extraction rule examples, and explicit extraction rule examples, may also be collected <NUM>. For instance, extraction rules may be inferred from examples that include Splunk® props. conf file content or other configuration file content (mark of Splunk, Inc.

Phase II - Creating Entity Extraction Model. Based on the data collected in Phase I, a model is created. The model reflects syntactic patterns of values. For example, in many of not all instances a SID property <NUM> of a UserAccount entity <NUM> has a structure matching (S-#-#-#). A system can learn the pattern of query results by users who configured extraction into this entity. Another learning activity uses column names <NUM>. If most of the users historically mapped a column called 'user' or 'username' to the UserName property of the UserAccount entity, then the enhanced system can offer a different user the same behavior.

Phase III - Generating New Extraction Proposals. Once an extraction logic <NUM> exists, it is used for different customers or different data sources, or both, than were present in the context of the examples on which the extraction logic <NUM> was based.

In some embodiments, Phase II and Phase III are combined and collectively referred to as a single phase. In others, Phase I and Phase II are combined and collectively referred to as a single phase.

<FIG> illustrates an architecture in some embodiments during a Learning Phase. Data <NUM> flows from one or more data sources <NUM> to a SIEM system <NUM> which is controlled by commands flowing from a management interface <NUM>. Data extraction examples <NUM> are collected from the SIEM system <NUM> by a collector <NUM>, which feeds a modeler <NUM>, which builds a database <NUM> of models (extraction rules). In this example, the management interface <NUM> is where a user configures the system to identify the data sources <NUM> being used. The examples <NUM> include extractions performed for a user, e.g., queries <NUM>, and the extraction results <NUM>, <NUM>.

<FIG> illustrates the same architecture as <FIG>, or an overlapping architecture, during a Recommendation Phase. Data <NUM> flows from an additional data source <NUM> to the SIEM system <NUM>, which is still controlled by commands flowing from the management interface <NUM>. The new data source's data, as gathered by the SIEM system, is fed to a recommender <NUM>, along with candidate extraction rules from the database <NUM>.

One of skill will acknowledge that although processing large amounts of event data is a common task in SIEM systems, it could be relevant in any security system that collects events and needs the data to be normalized. In addition to SIEM systems <NUM>, event data management tools <NUM> that may benefit from teachings provided herein include user and entity behavior analytics (UEBA) systems, and machine learning (ML) based detection engines, for instance.

One usage scenario includes a customer <NUM> adding a new data source <NUM>. Data <NUM> of the data source is scanned and a recommendation <NUM> to extract its entities is presented in the user interface. The recommendation can include examples to make effects and options clearer to the user, e.g. "By applying the suggested extraction the Entity 'SID' will look like. " and the enhanced system may present a list of examples from the customer's own data.

Another usage scenario includes periodically or at least intermittently scanning a set of existing data sources for changes. In many cases the data sources provide traces <NUM> or logs <NUM> of operational actions. The traces (which are often formatted as free text) may be changed and in particular new entities can be added. Precautionary scanning can catch <NUM> these changes and allow an enhanced system to produce a recommendation on entities that were recently added to existing data sources. In familiar environments, it can be very hard to manually track existing data sources, therefore users were often unaware of such entity changes, and missed an opportunity to extract relevant values, due to a lack of resources. Some embodiments notify <NUM> users upon detecting newly added entities.

Some usage scenarios include an internal use of a computed entity extraction rule. That is, the enhanced system does not explicitly suggest use of a certain extraction to the customer, but instead automatically <NUM> applies <NUM> the extraction rule. The automation can be done based on a certainty level <NUM>. Another option is to let the customer choose whether to enable automated extraction application or not. These options can also be combined, e.g., the user can choose an option to "automate extraction only when the certainty level is at least Y, otherwise notify me before applying an extraction rule I did not explicitly enter into the system".

In another usage scenario, an organization has a dedicated system for entrance management. Every time an employee uses an employee badge to enter or exit the building, that action is recorded, together with details such as the badge ID, timestamp, and the door used. The security department wants to connect that badge tracking system to the SIEM solution <NUM> they are using, to correlate badge activity with security events which are triggered from any IP address located inside the organization's office building. The badge tracking data <NUM> is stored on an Entrance Management System server as hourly-updated *. The SIEM system will have connection code running periodically which fetches those csv files to the SIEM system. If a user added entity extraction rule examples (e.g., queries <NUM>), they will also be collected, and the query results <NUM> such as an extracted populated TrackedUser entity will be collected.

In another usage scenario, the organization is a chocolate factory which has IoT (Internet of Things) solutions including hundreds of sensors monitoring their manufacturing machines' behavior to make sure they are all working as expected (as to temperature, batch weight, etc.). The sensor data <NUM> is collected through an IoT sensor hub into an event hub. The SIEM system has a connection to read the data <NUM> from the event hub in real-time. If a user added entity extraction rule examples (e.g., queries <NUM>), they will also be collected, and the query results <NUM> such as an extracted populated MixingVat entity will be collected.

Any of these combinations of code, data structures, logic, components, communications, and/or their functional equivalents may also be combined with any of the systems and their variations described above. A process may include any steps described herein in any subset or combination or sequence which is operable. Each variant may occur alone, or in combination with any one or more of the other variants. Each variant may occur with any of the processes and each process may be combined with any one or more of the other processes. Each process or combination of processes, including variants, may be combined with any of the configured storage medium combinations and variants describe above.

In short, with the benefit of teachings provided herein, Security Information and Event Management tools <NUM>, <NUM>, log management tools <NUM>, log analysis tools <NUM>, and other event data management tools <NUM> are enhanced. Enhancements <NUM> harvest entity extraction rules <NUM> from queries <NUM>, from query results <NUM>, and from other examples <NUM> involved in the extraction of field values <NUM> from large amounts of data <NUM>. Enhancements <NUM> also help systems perform <NUM> entity extraction efficiently. Entity extraction operations locate IP addresses, usernames, and other field values <NUM> that are embedded in logs or data streams, for example, and populate <NUM> object properties <NUM> with extracted values <NUM>. Previously used extraction rules <NUM> are applied in new contexts with different users <NUM>, different data sources <NUM>, or both. An entity extraction rules database <NUM> serves as a model that contains rules <NUM> specifying parsing mechanisms <NUM>. Parsing mechanisms <NUM> may include regular expressions <NUM>, or separation character <NUM> definitions, for example. Parsing mechanisms <NUM> may process particular file formats such as CSV, or object notation formats such as JSON, or markup language formats such as XML, for example. A recommender <NUM> suggests <NUM> one or more extraction rules <NUM> to users, based on frequency <NUM>, machine learning classifications <NUM>, correctness certainty <NUM>, or other considerations.

Although particular embodiments are expressly illustrated and described herein as processes, as configured storage media, or as systems, it will be appreciated that discussion of one type of embodiment also generally extends to other embodiment types. For instance, the descriptions of processes in connection with <FIG>, <FIG>, and <FIG> also help describe configured storage media, and help describe the technical effects and operation of systems and manufactures like those discussed in connection with other Figures. It does not follow that limitations from one embodiment are necessarily read into another. In particular, processes are not necessarily limited to the data structures and arrangements presented while discussing systems or manufactures such as configured memories.

Those of skill will understand that implementation details may pertain to specific code, such as specific APIs, specific fields, and specific sample programs, and thus need not appear in every embodiment. Those of skill will also understand that program identifiers and some other terminology used in discussing details are implementation-specific and thus need not pertain to every embodiment. Nonetheless, although they are not necessarily required to be present here, such details may help some readers by providing context and/or may illustrate a few of the many possible implementations of the technology discussed herein.

Reference herein to an embodiment having some feature X and reference elsewhere herein to an embodiment having some feature Y does not exclude from this disclosure embodiments which have both feature X and feature Y, unless such exclusion is expressly stated herein. All possible negative claim limitations are within the scope of this disclosure, in the sense that any feature which is stated to be part of an embodiment may also be expressly removed from inclusion in another embodiment, even if that specific exclusion is not given in any example herein. The term "embodiment" is merely used herein as a more convenient form of "process, system, article of manufacture, configured computer readable storage medium, and/or other example of the teachings herein as applied in a manner consistent with applicable law. " Accordingly, a given "embodiment" may include any combination of features disclosed herein, provided the embodiment is consistent with at least one claim.

Not every item shown in the Figures need be present in every embodiment. Conversely, an embodiment may contain item(s) not shown expressly in the Figures. Although some possibilities are illustrated here in text and drawings by specific examples, embodiments may depart from these examples. For instance, specific technical effects or technical features of an example may be omitted, renamed, grouped differently, repeated, instantiated in hardware and/or software differently, or be a mix of effects or features appearing in two or more of the examples. Functionality shown at one location may also be provided at a different location in some embodiments; one of skill recognizes that functionality modules can be defined in various ways in a given implementation without necessarily omitting desired technical effects from the collection of interacting modules viewed as a whole.

Reference has been made to the figures throughout by reference numerals. Any apparent inconsistencies in the phrasing associated with a given reference numeral, in the figures or in the text, should be understood as simply broadening the scope of what is referenced by that numeral. Different instances of a given reference numeral may refer to different embodiments, even though the same reference numeral is used. Similarly, a given reference numeral may be used to refer to a verb, a noun, and/or to corresponding instances of each, e.g., a processor <NUM> may process <NUM> instructions by executing them.

As used herein, terms such as "a" and "the" are inclusive of one or more of the indicated item or step. In particular, in the claims a reference to an item generally means at least one such item is present and a reference to a step means at least one instance of the step is performed.

Headings are for convenience only; information on a given topic may be found outside the section whose heading indicates that topic.

Claim 1:
An entity extraction system for efficient parsing to populate entity properties (<NUM>) based on event data (<NUM>), the system comprising:
a processor (<NUM>);
a digital memory (<NUM>) in operable communication with the processor;
a set of entity identifiers (<NUM>), each entity identifier comprising at least one entity property identifier (<NUM>);
an entity extraction rules database (<NUM>) containing a plurality of entity extraction rules (<NUM>), each entity extraction rule specifying a parsing mechanism (<NUM>) to parse at least one entity field (<NUM>) of event data (<NUM>); and
an entity extraction rule recommender (<NUM>) which upon execution by the processor examines particular event data from an event data source and produces a recommendation (<NUM>) for automatic use in a service citing at least one entity extraction rule (<NUM>) in the entity extraction rules database (<NUM>) and also targeting at least one entity identifier for use in extracting one or more entity field values from the particular event data and using the one or more extracted entity field values to populate one or more corresponding entity properties; and
an entity extraction rules modeler (<NUM>) which includes a machine learning classifier (<NUM>) that upon execution classifies the entity extraction rule according to its resemblance to other rules that have been applied to a similar data source or applied to populate same or similar entities (<NUM>).