Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/12/2025 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Regarding claim 1, and 11, the claims are objected to because of the following informalities: Claim 1 and 11 recites in the preamble “a computing environment” but subsequently recites detecting anomalous behavior across “an organization’s digital environment”. It appears that these expressions are intended to refer to the same environment. Applicant is requested to amend the claim to provide consistent terminology, for example, by reciting “the computing environment” or “the organization’s computing environment”. In line 4, “one or more of cyber security monitoring systems” should read “one or more cyber security monitoring systems” Appropriate correction is required.
Regarding claim 2, and 12, the claims are objected to because of the following informalities: Claim 2 and 12 recites “analyzing the input data”, whereas claim 1 introduces “an input associated with a data source.” Applicant is requested to provide proper antecedent terminology, for example, by replacing “the input data” with “the input” or by amending claim 1 is to initially recite “input data”. Appropriate correction is required.
Regarding claim 5, and 15, the claims are objected to because of the following informalities: Claim 5 and 15 recites “deduplicating assets using a multi-source matching process to generate a unified representation for each entity”. The change in terminology between “assets” and “each entity” makes the intended referent unnecessarily unclear. Applicant is requested to clarify whether the claimed unified representation is generated for each asset, each asset entity, or each entity of the target schema. Suggested correction if assets are intended “to generate a unified representation for each asset”. Appropriate correction is required.
Regarding claim 8, and 18, the claims are objected to because of the following informalities: Claim 8 and 18 recites “leveraging dynamic updates to a security knowledge graph.”. The expression “leveraging dynamic updates” is unnecessarily vague. Applicant is requested to clarify the language for example by reciting “dynamically updating a security knowledge graph.” if that is the intended operation. Appropriate correction is required.
Regarding claim 10, and 20, the claims are objected to because of the following informalities: Claim 10 and 20 recites “generating actionable insights to mitigate identified security risks”, but the immediately preceding limitation recites identifying “exposures or deviations from expected behavior” rather than identifying “security risks”. Applicant is requested to provide proper antecedent and clarify whether the recited exposures or deviations constitute the “identified security risks.” . Claims should recite “ identifying security risks comprising exposures or deviations from expected behavior …and generating actionable insights to mitigate the identified security risks”. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2 and 3 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the limitation “identify a plurality of diverse rows as a representative sample” renders the scope of the claim unclear. The term diverse is relative term or term of degree. The claim does not recite an objective criterion, threshold, or degree of difference by which it can be determined whether particular rows are sufficiently “diverse” to fall within scope of the claim. Although the specification describes for example selecting rows that differ in structure or content and further refers to selection using a diversity metric, see [0244] [0251], neither the claim nor the specification establishes an objective boundary for determining how much difference is required before rows constitute the claimed “diverse rows”. For example, it is unclear whether rows having merely different values, different fields, different structures, different semantic content or some specified amount of difference satisfy the limitation. Examiner suggest applicant to clarify the scope of the claim. Same applies for mirror claim 12.
Claim 3 recites the limitation “preexisting mappings of similar data sources” renders the scope of the claim unclear. The term “similar” is a relative term, and the claim does not recite an objective standard for determining when one data source is sufficiently similar to another data source to satisfy the limitation. The specification explains that an LLM may use a source type to locate comparable sources having existing mappings, [0240]; however, the disclosure does not establish an objective boundary for the claimed degree or type of similarity. For example, it is unclear whether similarity is determined based on a common source type, common vendor, common schema, common API structure, overlapping fields, semantic similarity pr some other characteristic. Examiner suggest applicant to clarify the scope of the claim. Same applies for mirror claim 13.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Independent claims 1, and 11:
Step1:
Claims 1 is drawn to “a method”, and claim 11 is drawn to “system”, therefore each of these claim groups falls under one of four categories of statutory subject matter (process/method, machines/products/apparatus, manufactures, and compositions of matter).
Step 2A, Prong 1:
Claims 1, and 11 are directed to a judicially recognized exception of an abstract idea without significantly more. Each of claims 1 and 11 recites limitations “receiving an input associated with a data source, wherein the data source comprises one or more of cybersecurity monitoring systems, Identity and Access Management (IAM) platforms, endpoint telemetry feeds, vulnerability scanners, and cloud service providers”, “mapping content within the input to entities of a target schema associated with a data fabric”, “integrating logs received from the data source within the data fabric based on the mapping, wherein the data fabric comprises a unified asset inventory constructed by deduplicating and harmonizing data from a plurality of heterogeneous sources”,” and “utilizing the data fabric to detect anomalous behavior across an organization's digital environment.” that under its broadest reasonable interpretation, enumerates a mental evaluation and abstract ideas including evaluating and organizing information. Other than reciting a generic “one or more processors” (Claim 11), nothing in the claims preclude the steps from practically being performed in the human mind. For example, other than the “computer processors” language, the claims encompass a user visually and manually categorize information, determine correspondence between information, reconcile duplicate information, and evaluate information to identify an anomaly. The mere nominal recitation of a generic computer component (computer processor) to automate the mental and abstract ideas does not take the claim limitations out of the abstract mental concepts (See MPEP 2106.04(a)(2)(I)(III)).
Step 2A, Prong 2:
Claims 1 and 11 recites additional element of receiving information from cybersecurity monitoring systems, IAM platforms, endpoint telemetry feeds, vulnerability scanners, and cloud service providers, and integrating the information within a data fabric having a unified asset inventory “one or more memory” to store computer program instructions and “one or more computer processors” to execute the computer program instructions do not integrate the abstract idea into practical application. Rather, these limitations provide the technological environment and data upon which the recited information analysis is performed. The claim does not recite a particular technical mechanism or algorithm for performing the mapping, deduplication, harmonization, or anomaly detection, not does it recite as particular improvement to the operation of a computer, data fabric, or cybersecurity system. The computer readable storage media and the computer processor are recited at a high level of generality (i.e., as generic computer components performing generic computer functions to store and to process data respectively). These generic computer functions are no more than mere instructions to apply the exception using generic computer components. The combination of these additional elements does not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea (MPEP 2106.05(f)).
Step 2B:
The additional elements “one or more computer readable storage media” to store computer program instructions and “one or more computer processors” to execute the computer program instructions are no more than generic, off-the-shelf computer components, and the Symantec, TLI, OIP Techs, and Versata court decisions cited in MPEP 2106.05(d)(II) indicate that mere collection/receipt of data over a network and/or storing and retrieving information in memory are well-understood, routine, and conventional functions when it is claimed in a merely generic manner (See MPEP 2106.05(d)(II)(IV)). As such, claims 1, and 11 are not patent eligible.
Dependent claims 2-10, and 12-20:
Step 1:
Claims 2-10 are drawn to “a method” and 12-20 are drawn to “system” therefore each of these claims falls under one of four categories of statutory subject matter (process/method, machines/products/apparatus, manufactures, and compositions of matter).
Steps 2A-2B:
Dependent claims 2-10, and 12-20 are also ineligible for the same reasons given with respect to claims 1 and 11. Claims 2-10, and 12-20 recite further abstract mental ideas of selecting diverse rows as a representative sample, using LLM to assist in mapping, tailoring mappings for individual tenants based on account configurations and schemas, multi-source matching and deduplication to generate a unified representation, cross referencing flagged events with threat intelligence feeds, using feedback to fine tune machine learning models, dynamically updating a security knowledge graph, selecting representative samples, analyzing metadata and documentation, inferring relationships, and generating mappings, and evaluating data using a security knowledge graph, identifying exposures or deviations, and generating actionable insights. (MPEP 2106.04(a)(2)(I)). Claims 2-10, and 12-20 fail to recite any additional elements/steps that might integrate the abstract idea into a practical application. As such, claims 2-10, and 12-20 are not patent eligible.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 5, 8, 10, 11, 15, 18 and 20 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Rogers (US 20220004546 A1).
Regarding claim 1, Rogers teaches method for managing exposure and detecting anomalous behavior in a computing environment, comprising steps of:
receiving an input associated with a data source, wherein the data source comprises one or more of cybersecurity monitoring systems, Identity and Access Management (IAM) platforms, endpoint telemetry feeds, vulnerability scanners, and cloud service providers (Rogers, Executing on the workstation system 112 (e.g., on a processor 52 of the workstation) are one or more entity event collectors 110, which, in general, collect event data pertaining to the computer environment 5 from a plurality of data sources 12, [0087] the entity event collectors 110 collect the event data by connecting to each data source 12 and retrieving the event data available from that source 12. an entity event collector 110 connects to the intended data source 12, typically via an application programming interface (API) 13 implemented by the data source 12, The user of the system provides any credentials necessary to access the APIs 13 of the data sources 12, which are passed to the entity event collectors 110 when they are configured to run on the workstation system 112 and are used by the entity event collectors 110 to access the API 13 of the data sources 12, [0088] The entity event collectors 110 provide the collected event data to the ingestion engine 114 of the server system 118. The ingestion engine 114 receives the collected event data from the entity event collectors 110 and generates aggregated, cleaned correlated, normalized and confirmed entity relationship information and/or event data based on the collected event data and provides the aggregated, cleaned correlated, normalized and confirmed entity relationship information and/or event data to the tracking and remediation subsystem 116, [0095-0096] vulnerability finding nodes 10-g representing results of the vulnerability scans, and CVE nodes 10-h representing publicly available security flaws that pertain to the computer environment 5, [0122] . Some examples of the data sources 12 include, but are not limited to, public cloud infrastructure, identity and access management products, vulnerability scanning products, endpoint management products, SIEM products, ticketing systems, networking infrastructure, network firewalls, etc., [0126]);
mapping content within the input to entities of a target schema associated with a data fabric (Rogers, the entity event collectors 110, ingestion engine 114, and/or the entity relationship graph subsystem 126, in conjunction with the schema service 170 generate the entity relationship information, including the entity relationship graph 162, based on predetermined and/or user-specified type definitions formatted according to the declarative schema definition language, the type definitions including markup specifying particular properties and relationships for different entity types such as those described above, [0137] the schema definition language includes explicit markup fields that define relations to external types. This allows data corresponding to this schema to be automatically transformed from an object representation into a graph representation, [0153] the entity event collector 110 interrogates the entity type via the schema service 170 to ensure the entity attributes are collected, valid, and recorded properly, The entity event collector 110 also uses this understanding of the entity type schema to recognize, resolve and validate references to other related entities 8, [0160]);
integrating logs received from the data source within the data fabric based on the mapping, wherein the data fabric comprises a unified asset inventory constructed by deduplicating and harmonizing data from a plurality of heterogeneous sources (Rogers, such data collection include monitoring log files, listening on event queues for events generated by various technologies and data sources, or pulling information from existing systems in the computer environment that are already aggregating data from multiple sources, [0014] The entity event collectors 110 provide the collected event data to the ingestion engine 114 of the server system 118. The ingestion engine 114 receives the collected event data from the entity event collectors 110 and generates aggregated, cleaned correlated, normalized and confirmed entity relationship information and/or event data based on the collected event data and provides the aggregated, cleaned correlated, normalized and confirmed entity relationship information and/or event data to the tracking and remediation subsystem 116, [0095-0096] the event data is received by the ingestion engine 114 which then performs entity data normalization and rationalization by applying a set of programmed rules 210, The normalized and rationalized event data is then sent to the entity relationship graph subsystem 126 in step 304, [0128]) [Examiner interprets that system collecting logs/event data, applying normalizing/rationalizing according to schema driven processing, and integrating the resulting information into the entity relationship graph/database as limitation above]; and
utilizing the data fabric to detect anomalous behavior across an organization's digital environment (Rogers, The present system also uses machine learning techniques and learned attribute sets and interaction patterns to help identify, group or categorize entities or to identify patterns which are indicative of anomalies that might be due to nefarious actions or compromised security, [0017] One of the many factors which is expected to be considered in many target use cases is whether entities are behaving in a “normal” or “abnormal” way, The machine learning subsystem discussed above is further capable of applying machine learning and pattern matching techniques to automatically detect abnormal behavior of an entity. By tracking the attributes and relationships of each entity in the graph, and by building machine learning models which are responsive to these attributes and relationships, the present system and method can employ MI, models to automatically determine if an entity is behaving in an abnormal way. An illustrative example would be that a machine learning model is built to categorize compute node entities based on the operating system and software packages running on them, the network segment they are running on, the ports they have open for receiving network connections and the other systems they interact with over the network, [0286] In addition to classifying or existing unclassified data elements such as entities 8, the machine learning engine 124 also identifies patterns in the entity relationship graph 162 indicating abnormal conditions of the computer environment 5 using the trained machine learning models. Additionally, the machine learning engine 124 determines whether detected changes in the entity relationship graph indicate abnormal conditions of the computer environment 5 based on the processing by the particular machine learning models to which detected changes are determined to pertain, [0287]).
Regarding claim 5, Rogers teaches the method of claim 1, wherein the step of integrating logs into the data fabric further comprises deduplicating assets using a multi-source matching process to generate a unified representation for each entity (Rogers, The ingestion engine 114 receives the collected event data from the entity event collectors 110 and generates aggregated, cleaned correlated, normalized and confirmed entity relationship information and/or event data based on the collected event data and provides the aggregated, cleaned correlated, normalized and confirmed entity relationship information and/or event data to the tracking and remediation subsystem 116, [0096] , in the stored and/or presented graphs 162, individual entities 8 are modeled or represented as vertices, or entity nodes 10. Attributes about the entities 8 can be stored and/or presented as attributes on the entity nodes 10. Relationships between entities 8 are modeled or represented as edges 11 between the entity nodes 10. The edges 11 can also have attributes or properties associated with them. The stored graphs, presented graphs, entity nodes 10, and edges 11 will be described in further detail below with respect to subsequent figures, [0102] there are several data sources 12 that have information about the same entity 8, examples of the data sources 12 include, but are not limited to, public cloud infrastructure, identity and access management products, vulnerability scanning products, endpoint management products, SIEM products, ticketing systems, networking infrastructure, network firewalls, etc. In some cases, that information from different data sources 12 about the same entities 8, [0126] the ingestion engine 114 operates according to configurable rules for dealing with joining the event data from different data sources 12 and/or resolving conflicting information from different sources 12 as collected by the entity event collectors 110 and then storing the result in the entity relationship graph 162 and underlying relational database 140 of the graph subsystem 126, a possible configuration for collection, normalization, and rationalization of data, with reference to steps of a data collection, normalization, and rationalization process performed by the depicted configuration, [0127])
Regarding claim 8, Rogers teaches the method of claim 1, further comprising leveraging dynamic updates to a security knowledge graph to reflect new inputs, emerging threat signatures, and evolving system configurations across the organization's computing environment (Rogers, the entity event collectors 110 specifically detect relevant changes to the computer environment 5 and/or look for event data indicating the relevant changes, including a presence in the computer environment 5 of new entities 8 that were previously unknown, disappearances from the computer environment 5 of entities 8 that were previously identified as being present in the computer environment 5, and/or changes to properties of entities 8 that were previously identified as being present in the computer environment 5, [0091] when the system 100 detects and/or retrieves the event data indicating the relevant changes, generating the entity relationship information may comprise only modifying existing entity relationship information to reflect the relevant changes in the computer environment 5 in response to determining that the relevant changes are not already represented in the existing entity relationship information, [0092] vulnerability finding nodes 10-g representing results of the vulnerability scans, and CVE nodes 10-h representing publicly available security flaws that pertain to the computer environment 5, [0122] showing how actions resulting from organic changes to the computer environment 5 such as those described above could result in additional attribute and relationship data being added to the graph 162 and/or actions performed to manipulate the computer environment 5, which could, in turn, trigger other rules. In step 1300, organic changes to the environment occur and are reflected in the collected event data and the entity relationship graph 162 in step 1302. In step 1304, the changes to the graph 162 are detected, resulting in rules being triggered by the rules engine 120 in step 1306. In step 1308, the triggered rules result in specified actions for the rules being performed by the rules engine 120. These actions might include updating the entity relationship graph in step 1310, in which case the graph change is again detected in step 1304, triggering further rules, and so forth. The actions executed in step 1308 could also effect changes or manipulation in the computer environment 5 in step 1312, in which case these environmental changes causes changes to the entity relationship graph 162, which are then detected, triggering further rules, and so forth, [0181] the graph server 248 records the state of the entity relationship graph 162 as it changes over time, [0207]).
Regarding claim 10, Rogers teaches the method of claim 1, wherein utilizing the data fabric comprises:
continuously evaluating harmonized data using a security knowledge graph implemented within the data fabric (Rogers, The ingestion engine 114 receives the collected event data from the entity event collectors 110 and generates aggregated, cleaned correlated, normalized and confirmed entity relationship information and/or event data based on the collected event data and provides the aggregated, cleaned correlated, normalized and confirmed entity relationship information and/or event data to the tracking and remediation subsystem 116, [0096] the event data is received by the ingestion engine 114 which then performs entity data normalization and rationalization by applying a set of programmed rules 210, [0128] A rule is considered “triggered” whenever the result set returned from the query for its condition graph pattern changes or whenever the attributes on any node or edge returned by the query changes, [0171] the entity relationship graph subsystem 126 generates a change alert indicating that one or more changes have been made to the entity relationship graph 162. …the rules engine 120 re-executes the query representing the specified conditions for only the identified rules determined to be potentially affected by the change…. if a change to the entity relationship graph 162 involves modifying the value of an attribute on a node 10 representing an entity 8, if a rule's condition graph pattern does not explicitly reference that modified attribute, the change is determined to have no impact on the result of the query representing the specified conditions of the rule, and the change can be ignored for that rule, [0174] query that is continuously monitored (e.g., with respect to the entity relationship graph 162) by the rules engine 120, [0268]);
identifying exposures or deviations from expected behavior based on predefined controls, policies, and graph traversal logic (Rogers, a recurring scheduled task would be the periodic execution of a query against the graph 162 to identify entities 8 that are out of compliance with some policy, [0120] by exposing a mechanism to issue graph traversal or graph pattern queries, the presently disclosed system and method provides answers to these more complicated relationship-based questions efficiently, [0162] sing the returned software component as the starting point, the dependency mapping function submits a query to the graph access service 246 to recursively traverse all edges 11 of a type considered to represent a dependency, for example, the RUNS_ON edges 11-g, BINDS_TO edges 11-h, HOSTS edges 11-i, and CONNECTS_TO edges 11-k: MATCH (sw:Software)-[:BINDS_TO]-(p:Port {portNmbr: ‘443’})-[:HOSTS]-(:IPAddr)-[:RESOLVES_TO]-(dns:DNSName {fqdn: ‘store.acme.corn’}) match path=(root)-[:RUNS_ON :BINDS TO :HOSTS :CONNECTS_TO*1.20]-(1) where id(root)=id(sw) return path, [0248-0249] The machine learning subsystem discussed above is further capable of applying machine learning and pattern matching techniques to automatically detect abnormal behavior of an entity. By tracking the attributes and relationships of each entity in the graph, and by building machine learning models which are responsive to these attributes and relationships, the present system and method can employ MI, models to automatically determine if an entity is behaving in an abnormal way, system and method can automatically categorize entities in the graph, detect abnormal behavior for that category, and tag the entities accordingly. This abnormal behavior tag can then be used to trigger rules and corresponding actions or otherwise draw the attention of IT or cybersecurity professionals, [0286] For query-validated mitigations a graph query is specified as the evaluation criteria, which will be used to identify the existence of any control failures or gaps indicating that the control is not properly implemented, [0306]); and
generating actionable insights to mitigate identified security risks (Rogers, system includes proactive orchestration and automation capabilities to automatically remediate errant entities or bring them into compliance with policy, [0018] a recurring scheduled task would be the periodic execution of a query against the graph 162 to identify entities 8 that are out of compliance with some policy. The action might be to execute a workflow on the entities 8 returned by the query, where the workflow notifies some person(s) to take some action, or the workflow executes some automated action by calls to APIs of other software programs within or related to the computer environment 5 to remediate the policy violation, [0120] Other actions might be intended to employ a program, script or workflow executed as the result of a rule being triggered to perform automated activities to manipulate entities S to bring them, or the overall environment 5, into compliance with some desired state, [0180] “Remediate Vulnerabilities” indicating that actions performed at that step are concerned with remediating vulnerabilities within the computer environment 5, [0188] a user of the system and method can drill into risk objects 262, related risk scenarios 264, and related mitigating controls 266 to determine the most significant aspects contributing to the overall risk score, [0318]).
Regarding claim 11, Rogers teaches a system for managing exposure and detecting anomalous behavior in a computing environment, comprising: one or more processors and memory storing instructions that, when executed, cause the one or more processors to perform steps of (Rogers, The processing device 52 represents one or more general-purpose processing devices.. The computer system 50 may or may not include a data storage device that includes instructions 68-3 stored in a computer-readable medium 58, [0105-0106]):
Regarding claim 15, 18 and 20, Claims 15 and 20 recite commensurate subject matter as claims 5, 8 and 10 respectively. Therefore, they are rejected for the same reasons
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 9, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Rogers (US 20220004546 A1) in view of Morganstern (US 20210303569 A1).
Regarding claim 2, Rogers teaches method of claim 1, further comprising
Rogers does not explicitly teach:
analyzing the input data to identify a plurality of diverse rows as a representative sample prior to mapping content to the target schema
However, Morganstern teaches:
analyzing the input data to identify a plurality of diverse rows as a representative sample prior to mapping content to the target schema (Morganstern, Schema crawler 125 analyzes data in processed data storage 120 to identify raw fields from the processed data and map them to common fields used in the data storage layer 130. Schema crawlers crawl data to determine schemas and/or raw data fields for different data sets. schema crawlers can take non-tabular data (e.g., JSON) and extract out all the fields into individual columns. Schema crawlers in accordance with a variety of embodiments can crawl the data to identify raw fields and map the raw fields to common fields in the view extraction system, [0040] schema crawlers may evaluate only a portion of the new data to identify the raw fields of the incoming data and/or to map the incoming raw fields to common fields the evaluated portion is selected by randomly sampling from the available data in the raw data storage, [0042] the percentage to be scanned can depend on a heterogeneity in formats from a given data source, when data from a particular data source is highly variable (e.g., in the number of fields and/or field names), a larger percentage of the data may be scanned in a given crawl, [0043] Schema crawlers in accordance with many embodiments can sample data from different data sources, records, and/or events for the different bins., [0044] Example records in accordance with a number of embodiments of the invention can be randomly sampled from the data to provide a representative sample of field values, [0051] Process 800 identifies (810) raw fields from the processed source data. In numerous embodiments, processes can identify raw fields from a subset of the processed source data. The subset of the processed source data in accordance with certain embodiments can be randomly sampled from the processed source data, the percentage to be scanned can depend on a heterogeneity in formats from a given data source, [0071] Process 800 maps (815) the identified raw fields to common fields, [0042]) [Examiner interprets that system selecting a plurality of records constituting a representative sample including sampling records across different sources/events and adjusting the sampling based on heterogeneity of the input data as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Rogers to include a concept of analyzing the input data to identify a plurality of diverse rows as a representative sample prior to mapping content to the target schema as taught by Morganstern for the purpose of mapping the identified raw fields to common fields by determining similarities between a raw field and each of the common fields, identifying a target common field based on the determined similarities, and mapping the raw field to the target common field [Morganstern:0003].
Regarding claim 9, Rogers teaches method of claim 1, wherein the mapping comprises:
analyzing metadata, schema information, and Application Programming Interface (API) documentation associated with the data source to infer structural relationships (Rogers, These APIs 13 could be any programable interfaces appropriate for collecting metadata that describes conditions within the computer environment 5,[0132] system and method is configured to consume user-specified type definitions, for example, according to a computer-readable schema. definition language and format built on and extending standards such as JSONSchema and OpenAPI (for example). This schema definition language supports the definition of details about each entity type including, among other things, what attributes the entity type can, or must, include and what other entity types it can, or must, have relationships to, [0136] the schema definition language includes explicit markup fields that define relations to external types This allows data corresponding to this schema to be automatically transformed from an object representation into a graph representation…. descriptions of existing enterprise application data and interfaces are available in JSONschema or OpenAPI format. This schema language allows definition of graph-specific markup, including relationships, constraints and derived properties, using the same schema language, [0153-0154]); and
generating entity-specific mappings for aligning data fields with the entities of the target schema (Rogers, the type definition comprises a series of attribute fields nested at various levels with respect to each other, with each attribute comprising a textual label and a value indicating a data type expected to be associated with the label in instances of nodes 10 representing actual entities 8 having the entity type defined by the type definition, [0139] the schema definition language includes explicit markup fields that define relations to external types. This allows data corresponding to this schema to be automatically transformed from an object representation into a graph representation, [0153] when a new entity 8 is discovered the entity event collector 110 interrogates the entity type via the schema service 170 to ensure the entity attributes are collected, valid, and recorded properly. The entity event collector 110 also uses this understanding of the entity type schema to recognize, resolve and validate references to other related entities 8, [0160]).
Rogers does not explicitly teach:
conducting a pre-processing step on raw data received from the data source to identify representative samples
However, Morganstern teaches:
conducting a pre-processing step on raw data received from the data source to identify representative samples (Morganstern, Data ingestion pipeline 115 processes data from raw data storage 110 to process the data for processed data storage 120, [0036] Data ingestion pipelines in accordance with a variety of embodiments can perform a number of different processing tasks on data of the raw data storage, such as (but not limited to) data conversions (e.g., XML to JSON, etc.), data normalization, and/or adding new fields (e.g., enriched time stamps, other metadata, etc.). In certain embodiments, data ingestion pipelines can separate composite data from the raw data into individual components, [0037] schema crawlers may evaluate only a portion of the new data to identify the raw fields of the incoming data and/or to map the incoming raw fields to common fields. In some embodiments, the evaluated portion is selected by randomly sampling from the available data in the raw data storage, [0042] mapping metadata tables can include separate tables for raw metadata and common field metadata, which can be joined to determine the mappings of the raw fields to the common fields…multiple example records may be stored (e.g., in a single field, in a separate table, etc.) for a given field. Example records in accordance with a number of embodiments of the invention can be randomly sampled from the data to provide a representative sample of field values, [0051] Process 800 processes (805) source data, [0070] Process 800 identifies (810) raw fields from the processed source data. In numerous embodiments, processes can identify raw fields from a subset of the processed source data. The subset of the processed source data in accordance with certain embodiments can be randomly sampled from the processed source data, [0071]) [Examiner interprets that system preprocessing before the schema crawler performs its field identification and mapping , selecting only part of the raw/source data as a sample as limitation above]. Same motivation applies same as claim 2.
Regarding claim 12 and 19, Claims 12 and 19 recite commensurate subject matter as claims 2 and 9. Therefore, they are rejected for the same reasons.
Claims 3, 7, 13 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rogers (US 20220004546 A1) in view of Retinraj (US 20230023645 A1).
Regarding claim 3, Rogers teaches the method of claim 1,
Rogers does not explicitly teach:
wherein mapping content to entities of the target schema comprises performing automated Large Language Model (LLM) invocations to assist in entity-specific and field-specific mapping based on pre-existing mappings of similar data sources
However, Retinraj teaches:
wherein mapping content to entities of the target schema comprises performing automated Large Language Model (LLM) invocations to assist in entity-specific and field-specific mapping based on pre-existing mappings of similar data sources (Retinraj, generating a database schema using trained machine learning models that, in some embodiments, may include graph neural networks (GNN)…. the GNN may identify source to target database schema mappings using, among other features of the graph, context data associated with each node in a graph… The system may use this context data (and other graph data) in combination with a trained GNN model to generate a mapping between one or more source database entities to corresponding target database entities, [0022] the feature extractor 108 may identify data entities associated with a database schema that include tables, arrays, files, sets, fields, and/or other types of data objects, The feature extractor 108 may then identify, within these various data objects, attribute names, attribute definitions, attribute descriptions, permitted field values and/or permitted field value types (e.g., integer, string, alphanumeric characters). The feature extractor 108 may then process the identified entities, entity types, and/or attributes to generate one or more feature vectors, [0031] training a GNN may occur in stages, first using a generic dataset, whether a publicly available NLP training dataset (e.g., an NLP training dataset, such as those available from commoncrawl or Wikipedia®) or a generically pre-trained model (e.g., OpenAI GPT-3, Google® BERT, Microsoft® CodeBERT, Facebook® RoBERTa)… The machine learning (ML) engine 110 may be trained using data entities associated with a target database schema. Once trained, the trained ML engine 110 may be applied to a source database schema to identify data entities within the source database schema that are analogous to target database entities, Once the analogs are identified, the ML engine 110 may generate a mapping so that the source database schema may be translated into the target database schema, [0042] the graph analyzer 116 may execute an analysis that compares specific field and/or attribute values, such as via NLP analysis, [0047] a user may manually intervene in the process to alter mappings that are generated by the system (e.g., provided via a client device 102). The manual updates may be provided to the GNN or other trained machine learning model to update training data. Essentially the user may alter a label via a user interface so that a correct association between a source database schema data entity and a corresponding target database schema entity are stored in the system, [0089]) [Examiner interprets that system teaching automated machine learning schema mapping system that determines correspondence between source entities/fields and target entities/fields, using NLP processing such as GPT3 and retaining corrected prior source to target associations as training information that influences the subsequent schema mappings as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Rogers to include a concept of mapping content to entities of the target schema comprises performing automated Large Language Model (LLM) invocations to assist in entity-specific and field-specific mapping based on pre-existing mappings of similar data sources as taught by Retinraj for the purpose of generating a database schema using trained machine learning models and using this context data (and other graph data) in combination with a trained GNN model to generate a mapping between one or more source database entities to corresponding target database entities [Retinraj: 0022].
Regarding claim 7, Rogers teaches method of claim 1, further comprising
Rogers does not explicitly teach:
establishing a feedback loop wherein feedback provided by users or administrators regarding mapping accuracy is used to fine- tune machine learning models performing mapping operations
However, Retinraj teaches:
establishing a feedback loop wherein feedback provided by users or administrators regarding mapping accuracy is used to fine- tune machine learning models performing mapping operations (Retinraj, the clients 102A, 102B may be configured to enable a user to provide user feedback via a GUI regarding the accuracy of the ML application 104 analysis, That is, a user may label, using a GUI, an analysis generated by the ML application 104 as accurate or not accurate, thereby further revising or validating training data. This latter feature enables a user to label data analyzed by the ML application 104 so that the ML application 104 may update its training, [0027] The ML application 104 of the system 100 may be configured to train one or more ML models using training data, prepare target data before ML analysis, and analyze data so as to map a source database schema to a target database schema, thereby enabling the integration or inter-operation of database schemas, [0028] Training may further be refined by applying one or more filters to the training data to restrict some aspects of the training data., [0040] The machine learning (ML) engine 110 may be trained using data entities associated with a target database schema. Once trained, the trained ML engine 110 may be applied to a source database schema to identify data entities within the source database schema that are analogous to target database entities, Once the analogs are identified, the ML engine 110 may generate a mapping so that the source database schema may be translated into the target database schema, [0042] a user may manually intervene in the process to alter mappings that are generated by the system (e.g., provided via a client device 102). The manual updates may be provided to the GNN or other trained machine learning model to update training data. Essentially the user may alter a label via a user interface so that a correct association between a source database schema data entity and a corresponding target database schema entity are stored in the system, [0089]) [Examiner interprets that system updating/refining an already trained ML model using corrected mapping labels as limitation above].Same motivation applies as claim 3.
Regarding claim 13 and 17, Claims 13 and 17 recite commensurate subject matter as claims 3 and 7. Therefore, they are rejected for the same reasons.
Claims 4, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Rogers (US 20220004546 A1) in view of Suresh (US 20190171651 A1).
Regarding claim 4, Rogers teaches method of claim 1, further comprising providing tailored mapping adjustments for individual tenants in a multi-tenant cloud-based system by (Rogers, The tenant service 172 runs on the server system 11.8 and is responsible for managing, creating, updating, deleting and providing information about separate tenants in a multi-tenant version of the system 100, [0117] the type definitions enable customization by the user of entity types specific to the computer environment 5 and/or organization managing the computer environment 5, [0141] the system 100 is a multi-tenant system, and a new type having a type definition in a file on the filesystem “--/types/MyCustomType.yam1.” is being loaded into a tenant called “ar02”, [0152] there are organization-specific variations in the types of entities which need to be tracked in the system… the present system and method supports the ability for additional types to be defined and imported into the system, [0159])
Rogers does not explicitly teach:
aligning mappings with existing account configurations and schemas specific to each tenant
However, Suresh teaches:
aligning mappings with existing account configurations and schemas specific to each tenant (Suresh, Business objects are used to represent enterprise data across different information systems in a standardized way. Business applications interact with business objects via logical operations, which are mapped by the EAIS to physical operations specific to each information system, [0025] a single instance of the software runs on a server, serving multiple client organizations (tenants). With a multi-tenant architecture, a software application is designed to partition its data and configuration virtually, and each client organization works with a customized virtual application instance, Multi-tenancy is also regarded as one of the essential attributes of cloud computing, [0027] The multi-tenant manager 212 contains tenant configurations for Tenant 1 (600), Tenant 2 (602), and Tenant 3 (603)… the customers may access any of the client companies via resort to the appropriate tenant configuration in the multi-tenancy manager, [0035] The tenant “tenant1” has one business object “Store” which is mapped to the relational database table “Store” that is accessible through a Java database (JDBC) connection: TABLE-US-00002 [0036] Business objects can be linked to an information system through a binding that defines how the data elements and operations of the business object map to data elements and operations of the information system. A business object may have separate bindings for each information system, [0040] The business object “Store” maps to the table “store” and its fields map to columns as follows: the field “storeID” maps to the column “storeID”; the field “enabled” maps to the column “classifier_2”: TABLE-US-00004, [0041] Business objects are predefined and can be reused. In this example, the Order, Order Status, Shipment, and Shipment Status comprise the business objects. For each call from a customer 610a, 610b, 610c, the business object logic 800 identifies the tenant configuration to use to connect to the order status and shipping status services of the appropriate client and to use the appropriate business objects accordingly. If a call belongs to Company 1, then the system identifies that Shipper A is the shipping configuration and it connects to the Shipper A server using the business objects order status and shipment status. If call belongs to Company 2, then the system identifies that Shippers A and B comprise the shipping configuration and it connects to the Shipper A and/or B server using same business objects order status and shipment status…., [0042]) [Examiner interprets that system using business objects that can be organized by tenant, each tenant has distinct configuration, and the data associated with the information systems is mapped into the applicable standardized business object schema as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Rogers to include a concept of mapping content to entities of the target schema comprises performing automated Large Language Model (LLM) invocations to assist in entity-specific and field-specific mapping based on pre-existing mappings of similar data sources as taught by Suresh for the purpose of allowing customer to access any of the client companies via resort to the appropriate tenant configuration in the multi-tenancy manager, [Suresh:0035].
Regarding claim 14, Claim 14 recites commensurate subject matter as claim 4, Therefore, it is rejected for the same reasons.
Claims 6, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Rogers (US 20220004546 A1) in view of Vasseur (US 20170279836 A1).
Regarding claim 6, Rogers teaches the method of claim 1,
Rogers does not explicitly teach:
wherein utilizing the data fabric further comprises detecting anomalous behavior by cross-referencing flagged events against known threat intelligence feeds integrated within the data fabric
However, Vasseur teaches:
wherein utilizing the data fabric further comprises detecting anomalous behavior by cross-referencing flagged events against known threat intelligence feeds integrated within the data fabric (Vasseur, system relates to distributed feedback loops from threat intelligence feeds to distributed learning systems, [0002] DLA 400a may analyze traffic data regarding its local network using an unsupervised, machine learning-based anomaly detection mechanism. If the assessed traffic is statistically anomalous, DLA 400a may flag the anomalous condition and report the anomaly to SCA 502 via an AnomalyNotification( ) message 702, [0093] SCA 502 may receive a threat intelligence feed 704 from threat service cloud 602. In some embodiments, SCA 502 may request threat intelligence feed 704 based on AnomalyNotification( ) message 702. For example, SCA 502 may perform a lookup of one or more of the addresses indicated in message 702. In other embodiments, the corresponding service(s) in threat service cloud 602 may push threat intelligence feed 704 to SCA 502 at specific times, [0094] SCA 502 may match the information regarding the detected anomaly to the threat intelligence feed data, [0095-0099] the device may receive the anomaly detection data from another node in the network (e.g., a DLA, etc.) that executes a machine learning-based anomaly detection mechanism… he device may match the anomaly data to threat intelligence feed data from one or more threat intelligence services, [0103-0104]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Rogers to include a concept of mapping content to entities of the target schema comprises performing automated Large Language Model (LLM) invocations to assist in entity-specific and field-specific mapping based on pre-existing mappings of similar data sources as taught by Vasseur for the purpose of executing a machine learning-based anomaly detection mechanism and matching the anomaly data to threat intelligence feed data from one or more threat intelligence services [Vasseur:0103-0104].
Regarding claim 16, Claim 16 recites commensurate subject matter as claim 6, Therefore, it is rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20240291869 A1: “relates to the field of cybersecurity, and more particularly to the fields of cyber insurance and data collection”
US 20230362200 A1: “relates to the field of computer management, and more particularly to the field of cybersecurity and threat detection and analytics”
US 20210294901 A1: “relate generally to threat modeling processes and systems”
US 20180131715 A1: “relates generally to systems and methods for monitoring and managing the security health of a computer environment, relates to detecting and managing vulnerabilities in a computer environment”
US 20150295751 A1: “relates to systems and methods for optimizing computer network operations in cyber warfare. In particular, virtual environments are deployed to securely contain disparate capabilities used in computer network operations to minimize interruptions otherwise caused by maintaining, managing and monitoring these capabilities”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at (571)272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.N.P./ Examiner, Art Unit 2436
/MOEEN KHAN/ Primary Examiner, Art Unit 2436
Prosecution Insights