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 08/20/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 5 and 15, the claims are objected to because of the following informalities: Claims 5 and 15 recite “an impacted rules or scripts” should read “impacted rules or scripts” or “an impacted rule or script”. Appropriate correction is required.
Regarding claim 7 and 17, the claims are objected to because of the following informalities: Claims 7 and 17 recite the phrase “to adjust mapping schema” lacks an appropriate article or other modifier before “mapping schema”. Applicant is required to clarify the language, for example by reciting “to adjust the mapping schema” or “to adjust a mapping schema of the data fabric” as appropriate. Appropriate correction is required.
Regarding claim 1 and 11, the claims are objected to because of the following informalities: The comma preceding “and generating alerts” is unnecessary and disrupts the grammatical construction of the recited method steps. 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 6, 7, 8, 16, 17, and 18 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.
Claims 6 and 16 recite the limitation “the alerts include suggestions for remediations derived from analyzing dependency profiles and patterns in the detected changes including updating field references, modifying threshold logic, or implementing validation scripts to pre-process malformed data.” It is unclear what the phrase beginning with “including” modifies. In particular, the claim may be interpreted as reciting that the detected changes include “updating field references, modifying threshold logic, or implementing validation scripts” or alternatively that the suggested remediations include those operations. Those interpretations materially differ because updating field references, modifying threshold logic, and implementing validation scripts, may constitute corrective actions rather than detected changes in incoming data. Accordingly, the scope of the claimed “suggestions for remediations” and their relationship to the recited “detected changes” cannot be determined with reasonable certainty. Examiner suggest amendment as “wherein the suggested remediations include updating field references, modifying threshold logic, or implementing validation scripts to pre-process malformed data”. Appropriate correction is required.
Claims 7 and 17 recite the limitation “the suggested remediations are automatically integrated into the data fabric mapping to adjust mapping schema, aligning mapped entities with altered data structures to prevent operational disruptions”. It is unclear what constitutes the recited “data fabric mapping” and “mapping schema”, and what specifically is adjusted by the suggested remediation. The parent claim recites an act of “mapping content within the input to entities of a target schema”, but does not expressly establish a particular “data fabric mapping” or mapping schema” as a distinct element. Further, the phrase “aligning mapped entities with altered data structures” is grammatically ambiguous as to whether the alignment is performed by the suggested remediation, by adjustment of the mapping schema, or merely describes a result of the integration. Examiner suggest amendment as “wherein the suggested remediations are automatically applied to a mapping schema of the data fabric to modify mappings between the mapped entities and the altered data structures”. Appropriate correction is required.
Claims 8 and 18 recite the limitation “breakpoints in logical dependencies caused by third party schema updates including renamed fields, missing fields, or altered data hierarchies that disrupt operation of mapped entities”. It is unclear whether the phrase “that disrupt operation of mapped entities” modifies only the immediately preceding recitation of “altered data hierarchies” or whether the phrase applies collectively to the recited “renamed fields, missing fields, or altered data hierarchies.” Under former interpretation, only altered data hierarchies are required to disrupt operation of mapped entities. Under the latter interpretation, each identified type of schema update is associated with such disruption. Because these interpretations result in different claim scope, the claim fails to particularly point out and distinctly claim the invention. Examiner suggest amendment as “wherein the monitoring identifies breakpoints in logical dependencies that disrupt operation of mapped entities, the breakpoints is caused by third-party schema updates including renamed fields, missing fields, or altered data hierarchies”. Appropriate correction is required.
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 1, 2, 4, 7, 8, 11, 12, 14, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Esman(US 20210191909 A1) in view of Gopal (US 20080071844 A1).
Regarding claim 1, Esman teaches a method for detecting and preventing data misconfigurations within a security- focused data fabric platform, the method 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 (Esman, System 108 includes one or more forwarders 204 that receive data from a variety of input data sources 202, and one or more indexers 206 that process and store the data in one or more data stores 208. These forwarders and indexers can comprise separate computer systems, or may alternatively comprise separate processes executing on one or more computer systems, [0089] Examples of a data source 202 include, without limitation, data files, directories of files, data sent over a network, event logs, registries, etc., [0090] At block 302, a forwarder receives data from an input source, such as a data source 202 shown in FIG. 2. A forwarder initially may receive the data as a raw data stream generated by the input source. For example, a forwarder may receive a data stream from a log file generated by an application server, from a stream of network data from a network device, or from any other source of data, [0094] Security-related information can also include malware infection data and system configuration information, as well as access control information, such as login/logout information and access failure notifications. The security-related information can originate from various sources within a data center, such as hosts, virtual machines, storage devices, and sensors. The security-related information can also originate from various sources in a network, such as routers, switches, email servers, proxy servers, gateways, firewalls, and intrusion-detection systems, [0154]) [Examiner interprets that system receiving data from intrusion detection systems, firewalls , security systems, access control sources, logs, and related security infrastructure as limitation above];
mapping content within the input to entities of a target schema associated with a data fabric, (Esman, a common field name may be used to reference two or more fields containing equivalent data items, even though the fields may be associated with different types of events that possibly have different data formats and different extraction rules. By enabling a common field name to be used to identify equivalent fields from different types of events generated by disparate data sources, the system facilitates use of a “common information model” (CIM) across the disparate data sources (further discussed with respect to FIG. 5), [0069] A data model is a hierarchically structured search-time mapping of semantic knowledge about one or more datasets. A data model is composed of one or more “objects” (or “data model objects”) that define or otherwise correspond to a specific set of data., Objects in data models can be arranged hierarchically in parent/child relationships. Each child object represents a subset of the dataset covered by its parent object. The top-level objects in data models are collectively referred to as “root objects.” Child objects have inheritance. Data model objects are defined by characteristics that mostly break down into constraints and attributes. Child objects inherit constraints and attributes from their parent objects and have additional constraints and attributes of their own.. Examples of data models can include electronic mail, authentication, databases, intrusion detection, malware, application state, alerts, compute inventory, network sessions, network traffic, performance, audits, updates, vulnerabilities, etc., A data model object may be defined by (1) a set of search constraints, and (2) a set of fields., A late-binding schema of field extraction rules is associated with each object or subset in the data model. [0121-0127] Data definitions in associated schemas can be taken from the common information model (CIM) or can be devised for a particular schema and optionally added to the CIM. Child objects inherit fields from parents and can include fields not present in parents. A model developer can select fewer extraction rules than are available for the sources returned by the query that defines events belonging to a model. Selecting a limited set of extraction rules can be a tool for simplifying and focusing the data model, while allowing a user flexibility to explore the data subset, [0128] one or more field extraction rules of a field extraction schema assume that data ingested from a data source and associated with a data source type conforms to a known source data schema, [0215]) [Examiner interprets that system taking heterogenous source data and semantically mapping it into normalized fields/data model objects defined according to a common information model or particular schema as limitation above];
monitoring incoming data flows from the data source in real time to detect changes in structure, format, or content of data, the changes comprising one or more of field renaming, removal of essential fields, data type transformations, introduction of unexpected or malformed data, or schema updates impacting mapped entities (Esman, system is the leading platform for providing real-time operational intelligence that enables organizations to collect, index, and search machine-generated data from various websites, applications, servers, networks, and mobile devices that power their businesses., [0061] a data intake and query system obtains data from a data source (or, more generally, from any number of separate data sources) associated with a plurality of points in time (for example, the data may be obtained continuously or periodically from the data sources over time), [0206] The data may be received continuously or periodically depending on the nature of the data source(s) generating the data and other settings for ingesting the data, [0213] if field identifiers change, merge, or split (for example, a field named “last name” changes to “last name”, or two separate fields named “first name” and “last name” merge into a single field named “full name”, or vice versa), the resulting event data may not include one or more expected fields and unexpected application results can occur. In some embodiments, a data intake and query system can also automatically detect the presence of one or more fields in input data by analyzing the data for common field data syntax such as, for example, “fieldname=value” or “fieldname: value,” which may be added or removed over time if an associated data schema changes., [0215] a schema consistency monitor analyzes the event data generated at block 1806 for changes to one or more associated data schemas. As indicated above, the schema associated with one or more ingested data sources may change over time because of updates to the application or system generating the input data or in response to any other events. A change to a schema associated with a data source and/or data source type may be temporary and may revert back after a period of time, or in some cases the schema may change permanently, [0217] the schema consistency monitor analyzes the event data generated based on the ingested data sources and data source types to determine whether a first portion of the data from which the event data was generated, where the first portion of the data is associated a first point in time, conforms to a first data schema, and that a second portion of the data associated with a second point in time conforms to a second data schema that is different from the first data schema, [0218] a table 2100 includes a separate row for each separate schema change identified… A field count column 2110 indicates how many fields in the data were added, lost, and gained, [0225]) [Examiner interprets that system continuously operating data ingestion system whose schema monitor analyzes the incoming event data for any changes such as renamed/modified/removed fields as limitation above] ; and
identifying potential operational failures, and generating alerts and suggested remediations for misconfigurations to ensure compatibility with updated data (Esman, the schema consistency monitor may generate and cause display of one or more graphical user interfaces (GUIs) that provide additional information about detected schema changes for data originating from one or more monitored data sources. In other embodiments, a schema consistency monitor can generate alerts, automatically update one or more event generation rules, or perform other automated actions in response to identifying data schema changes, [0207] if a schema associated with the underlying source data changes at some point in time (for example, because of a software update or other change to the application generating the source data), the data intake and query system may not be able to include these expected fields in the generated event data, [0209] if the schema associated with a data source changes unexpectedly, one or more dashboards or visualizations built upon the resulting event data may begin to show usual results or not be able to produce any results at all. A user noticing such abnormal application behavior might then be prompted to manually inspect the corresponding raw machine data to determine whether any unexpected schema changes are causing the unexpected application behavior, [0210] unanticipated changes to a data schema associated with such data can cause unexpected results in dashboards and other processes that are based on the event data because some or all of the corresponding field extraction rules may not be able to extract field data as desired…... the resulting event data may not include one or more expected fields and unexpected application results can occur. In some embodiments, a data intake and query system can also automatically detect the presence of one or more fields in input data by analyzing the data for common field data syntax such as, for example, “fieldname=value” or “fieldname: value,” which may be added or removed over time if an associated data schema changes, [0215] to determine which data sources or data source types experienced schema changes and what the change entailed, thereby enabling those users to readily update applications or take other actions as needed to accommodate the schema changes., [0224] a schema consistency monitor can perform various types of automated actions in response to identifying one or more schema changes. For example, a schema consistency monitor can generate one or more alerts (for example, email alerts, dashboard alerts, and so forth) in response to determining that a schema change has occurred…. The alert can be used to notify a user of the identified schema change and can thus prompt the user to take corrective action, if desired…. identification of a schema change can cause a data intake and query system application to automatically update one or more event generation rules, for example, to modify one or more field extraction rules if a detected field name change is detected, or to add or remove one or more field extraction rules if particular fields in the source data is added or removed, [0227])[Examiner interprets that system recognizing the operational consequences of schema changes, expected fields disappear, downstream dashboards/processes malfunction, generating alerts for corrective actions as limitation above]
Although Esman teaches relationships among schemas, fields, formats, data model objects, and extraction rules, Esman does not appear to explicitly teach:
the mapping defining dependencies between data fields, structures, formats, and associated rules and scripts; identifying potential operational failures, and generating suggested remediations suggested remediations for misconfigurations to ensure compatibility with updated data
However, Gopal teaches:
the mapping defining dependencies between data fields, structures, formats, and associated rules and scripts (Gopal, This CDM service uses shredded or modularized metadata that granularly describes an end-to-end information flow and associated underlying dependencies between source information, mappings, target information and business applications, [0006] Transformation information includes, for example, column-column mappings, table/view join expressions and other queries, and XSLTs,..References to information include explicit references in shredded metadata to represent all related information wherever possible, including other objects in shredded metadata, instead of using a human-readable-name. Thus, if a piece of information changes, the CDM service can examine all the related pieces of information by following the references, and if needed, recursively examine and retrieve the references from these related pieces of information as well to build a list of all the affected pieces of information. The references are guaranteed to be unique, and are tractable in the system, as opposed to human-readable-names that may not be unique and are not tractable, [0019] The metadata stored in the metadata repository 108 describes an end to end information flow and underlying dependencies between the source information, mappings, the targets and the source-independent business applications 105. Change handlers for each business object that has changed or pair of related or dependent business objects are represented by metadata and pluggably-registered. For example, transformations are related to the data sources 102 and destinations of the transformations, BDI business application models are related to the consumable target information, source information depends on the data source 102 it comes from, and target information depends on the target system in which the target information will be produced. Metadata objects are also versioned when changes are made to them, [0021] where the integration server 104 stores declarative descriptions of an end-to-end information flow and underlying dependencies between the source information, mappings, the targets and the source-independent business applications 105 as modularized metadata in the metadata repository 108, [0032]) [Examiner interprets that system using modularized metadata containing explicit references among source information, mappings, transformations, targets, consuming applications as limitation above].
identifying potential operational failures (Gopal, Source systems, as described above, are outside the influence of business applications that are source independent. Hence, source information can change without a business application being changed simultaneously, These changes are of numerous kinds, for example a table's schema could change, an API signature could change, or even, new data could be added to a table that is not yet mapped to any business application content or behavior, [0002] they cannot help determine how to modify the consuming business application's behavior, [0003] track how and when they change, and display what has changed in an intuitive way by organizing the changes according to the objects that are affected, [0014] a What-If Analysis process 204 can be used optionally to figure out the scope of the change with respect to the rest of the metadata repository if a certain change is accepted, This gives the user a first glance at what he or she might have to do going forward based on how the change affects other metadata, business objects that are impacted by the change are retrieved, [0024] the CDM service 207 analyzes which objects would be impacted by the changes, [0033] The groupings of impacted objects may include groups of heterogeneous objects whereby a change to an impacted object at one end of the end-to-end information flow can trigger a change to a heterogeneous object at the other end of the end-to-end information flow, [0035]), and
generating suggested remediations suggested remediations for misconfigurations to ensure compatibility with updated data (Gopal, The approach also tracks the business area in which the objects exist, derives possible user actions that are needed to manage the change based on registration of such actions, and possibly updates the affected objects or relationships automatically when the changes are simple or non-severe enough to be merged or applied without any human or user intervention, [0014] corrective actions that need to be taken can be displayed based on registered actions for a certain type of change associated with a certain object. Thus, the CDM service 207 identifies actions that can be taken for a given type of change to a business object, guides the business user through the changes, and invokes a handler for the object, The CDM service 207 also identifies all actions that can be taken for each pair of affected objects and changes for which the business user wants to process changes, guides the business user through the changes, and invokes the handler for the pair of objects, [0026] The guidance link section 405 illustrates the possible actions that can be taken to correctly handle the change selected in the source of impact box 402. This is typically one of two things: (i) Change a structure definition, or (ii) Change a mapping definition The buttons on the bottom of the UI 400 allow the user to commit changes via button 407, notify another user through an email (or other means of communication) that their attention is required to handle a change, refresh the change-list, or automatically use the system-suggested way of handling the change, [0040])
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Esman to include a concept of the mapping defining dependencies between data fields, structures, formats, and associated rules and scripts; identifying potential operational failures, and generating suggested remediations suggested remediations for misconfigurations to ensure compatibility with updated data as taught by Gopal for the purpose of detecting changes in a BDI solution, classifying each of the changes based on change severity, analyzing what objects would be impacted by the changes, determining whether the objects impacted by the changes can be change handled without user intervention, and change handling without user intervention all the objects impacted by changes that are not severe [Gopal:Abstract].
Regarding claim 2, Esman teaches the method of claim 1, wherein the steps include detecting changes on rules, scripts, or expressions within the target schema to identify potential operational failures (Esman, The generation of event data used by this example dashboard and other interfaces typically assumes the presence of defined field data in the underlying raw data ingested by the application.. if a schema associated with the underlying source data changes at some point in time (for example, because of a software update or other change to the application generating the source data), the data intake and query system may not be able to include these expected fields in the generated event data, [0209] unanticipated changes to a data schema associated with such data can cause unexpected results in dashboards and other processes that are based on the event data because some or all of the corresponding field extraction rules may not be able to extract field data as desired, [0215])
Esman does not appear to explicitly teach:
simulating an impact of detected changes on rules, scripts, or expressions within the target schema to identify potential operational failures
However, Gopal teaches:
simulating an impact of detected changes on rules, scripts, or expressions within the target schema to identify potential operational failures (Gopal, business objects represented by the metadata include connection information, transformation information, BDI business application models, and references to information. Connection information includes ways to connect to the data source or target system to obtain a given piece of source or target information. Transformation information includes, for example, column-column mappings, table/view join expressions and other queries, and XSLTs, [0019] a What-If Analysis process 204 can be used optionally to figure out the scope of the change with respect to the rest of the metadata repository if a certain change is accepted, This gives the user a first glance at what he or she might have to do going forward based on how the change affects other metadata, business objects that are impacted by the change are retrieved, [0024] the CDM service 207 analyzes which objects would be impacted by the changes, [0033]) Same motivation applies as claim 1.
Regarding claim 4, Esman teaches the method of claim 1, wherein the received input comprises log entries, event records, alerts, or vulnerability scan reports, and wherein the monitoring includes detecting schema modifications or data errors caused by third-party updates (Esman, machine data is generated by various components in the information technology (IT) environments such as servers, sensors, routers, mobile devices, Internet of Things (IoT) devices, etc. Machine-generated data can include system logs, network packet data, sensor data, application program data, error logs, stack traces, system performance data, etc. In general, machine-generated data can also include performance data, diagnostic information, and many other types of data that can be analyzed to diagnose performance problems, monitor user interactions, and to derive other insights, [0057] machine-generated data are collected and stored as “events.”, [0062] if a schema associated with the underlying source data changes at some point in time (for example, because of a software update or other change to the application generating the source data), the data intake and query system may not be able to include these expected fields in the generated event data, [0209] , the data sources can include various types of machine data produced by one or more applications external to the data intake and query system such as, for example, by various practice management systems, EMR systems, and so forth, and the data source types can include various types of application logs, system logs, network data, or other type of data generated by one or more of the data sources, [0212] the schema associated with one or more ingested data sources may change over time because of updates to the application or system generating the input data or in response to any other events. A change to a schema associated with a data source and/or data source type may be temporary and may revert back after a period of time, or in some cases the schema may change permanently, [0217]) [Examiner interprets that system detecting resulting schema changes].
Regarding claim 7, Esman teaches the method of claim 1, wherein the suggested remediations are automatically integrated into the data fabric mapping to adjust mapping schema, aligning mapped entities with altered data structures to prevent operational disruptions (Esman, the extraction rules for a field can include one or more instructions that specify how to extract a value for the field from the event data, [0067] a common field name may be used to reference two or more fields containing equivalent data items, even though the fields may be associated with different types of events that possibly have different data formats and different extraction rules. By enabling a common field name to be used to identify equivalent fields from different types of events generated by disparate data sources, the system facilitates use of a “common information model” (CIM) across the disparate data sources (further discussed with respect to FIG. 5), [0069] the identification of a schema change can cause a data intake and query system application to automatically update one or more event generation rules, for example, to modify one or more field extraction rules if a detected field name change is detected, or to add or remove one or more field extraction rules if particular fields in the source data is added or removed, [0227]) [Examiner interprets that system automatically modifying an extraction rule to change the mapping between the incoming source structure and the schema field if a filed is renamed or removed as limitation above].
Regarding claim 8, Esman teaches the method of claim 1, wherein the monitoring identifies breakpoints in logical dependencies caused by third-party schema updates including renamed fields, missing fields, or altered data hierarchies that disrupt operation of mapped entities (Esman, The generation of event data used by this example dashboard and other interfaces typically assumes the presence of defined field data in the underlying raw data ingested by the application…. if a schema associated with the underlying source data changes at some point in time (for example, because of a software update or other change to the application generating the source data), the data intake and query system may not be able to include these expected fields in the generated event data, [0209] if the schema associated with a data source changes unexpectedly, one or more dashboards or visualizations built upon the resulting event data may begin to show usual results or not be able to produce any results at all. A user noticing such abnormal application behavior might then be prompted to manually inspect the corresponding raw machine data to determine whether any unexpected schema changes are causing the unexpected application behavior, [0210] one or more field extraction rules of a field extraction schema assume that data ingested from a data source and associated with a data source type conforms to a known source data schema. Thus, unanticipated changes to a data schema associated with such data can cause unexpected results in dashboards and other processes that are based on the event data because some or all of the corresponding field extraction rules may not be able to extract field data as desired. For example, if a data source initially generates machine data that is formatted in one way (for example, as separate log lines including fields specifying a patient first name, patient last name, and doctor identifier), but then later changes to use different fields in a different order (for example, as separate log lines including fields specifying a doctor identifier, a patient identifier, and only a patient's last name), or if field identifiers change, merge, or split (for example, a field named “last name” changes to “last name”, or two separate fields named “first name” and “last name” merge into a single field named “full name”, or vice versa), the resulting event data may not include one or more expected fields and unexpected application results can occur, [0215] The fields lost and fields gained columns 2114 specifies the names of the fields that were added, removed, or modified as part of the identified schema change, [0225])
Regarding claim 11, Claim 11 recite commensurate subject matter as claim 1. Therefore, it is rejected for the same reasons. Except the additional parts.
Esman further teaches:
A non-transitory computer-readable medium comprising instructions that, when executed, cause one or more processors to perform steps (Esman, one or more hardware processors configured to execute the instructions stored in the one or more memories, [0071]) of:
Regarding claims 12, 14, 17 and 18, Claim 12,14,17 and 18 recite commensurate subject matter as claims 2,4,7 and 8 respectively. Therefore, they are rejected for the same reasons.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Esman(US 20210191909 A1) in view of Gopal (US 20080071844 A1) in further view of Gould (US 20190095390 A1).
Regarding claim 3, Esman and Gopal teaches the method of claim 2, wherein identifying mismatches between expected and actual data formats resulting in invalid comparisons within rules (Esman, one or more field extraction rules of a field extraction schema assume that data ingested from a data source and associated with a data source type conforms to a known source data schema….if a data source initially generates machine data that is formatted in one way (for example, as separate log lines including fields specifying a patient first name, patient last name, and doctor identifier), but then later changes to use different fields in a different order (for example, as separate log lines including fields specifying a doctor identifier, a patient identifier, and only a patient's last name), or if field identifiers change, merge, or split (for example, a field named “last name” changes to “last name”, or two separate fields named “first name” and “last name” merge into a single field named “full name”, or vice versa), the resulting event data may not include one or more expected fields and unexpected application results can occur, [0215].
Esman and Gopal do not appear to explicitly teach:
simulating the impact of detected changes includes identifying mismatches between expected and actual data formats resulting in invalid comparisons within rules
However, Gould teaches:
simulating the impact of detected changes includes identifying mismatches between expected and actual data formats resulting in invalid comparisons within rules (Gould, information about logical datasets may include field names, data types, record formats, constraints, and other features, [0022] A change made to a logical dataset or data element can affect many different rule sets and data elements. These changes can include, among other changes, a change to a schema or record format and changes to valid values for different data elements. For example, if a record schema of a data element is changed (for example, the record schema can change from a number to a string field) the change can affect each rule set that utilizes that data element and each rule set that utilizes a data element that depends on the changed data element, [0026] In order to determine the impact of a change to one of the input or output fields, a system can perform an analysis of the rule set as described below…, [0036-0037] For example, the human-readable rule set 300 can result in the generation of annotated code, such as TABLE-US-00001 /* Default Risk Rules */ /*@ Reported Metrics…, [0038] a direct impact describes the number of times that the data element identified by the rule set field is directly referenced or set within the rule set. Examples of measures of direct impact include, but are not limited to, locations in a rule set where a changed input parameter is accessed.[0039] The logical dataset information can identify, for each logical dataset, an identifier for at least one field in that logical dataset, and format information about that field… The transformation may include information about the rules to be applied to data from the first logical dataset. Analyzing the potential impact of the one or more proposed changes c further based on the one or more rules…. the proposed change identifies the field in a logical dataset or the transformation that is to be altered without specifying the nature of the change. For example, the proposed change can specify that field ‘X’ is to be changed without indicating that the change is from a decimal record format to a string record format. The proposed change is analyzed (708)… The metric can measure the impact of the change. The metric can include a measure of direct impact and/or a measure of indirect impact. Examples of measures of direct impact include, but are not limited to, locations in a rule set where a changed input parameter is accessed…, [0051-0055]) [Examiner interprets that system evaluating how mismatch between the format expected by the rule and the changed data format would cause an invalid or incompatible comparison within the rule as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Esman and Gopal to include a concept of simulating the impact of detected changes includes identifying mismatches between expected and actual data formats resulting in invalid comparisons within rules as taught by Gould for the purpose of using impact analysis by identifying for each logical dataset, an identifier for at least one field in that logical dataset, and format information about that field and analyzing the potential impact of the one or more proposed changes c further based on the one or more rules [Gould: [0050-0055].
Regarding claims 13, Claim 13 recite commensurate subject matter as claim 3. Therefore, it is rejected for the same reasons.
Claims 5, 6, 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Esman(US 20210191909 A1) in view of Gopal (US 20080071844 A1) in further view of Livny (US 20200320845 A1).
Regarding claim 5, Esman and Gopal teaches the method of claim 1, further comprising generating automated alerts when misconfigurations are detected, wherein the alerts include information specifying a nature of detected changes (Esman, A schema change dashboard can include a table or other interface element(s) that display information about any detected schema changes, for example, including information indicating that a schema change occurred, a data source or data source type associated with the schema change, a time at which the schema changed, how many events were included in a time period during which the schema changed, what fields were added, removed, or modified, how much a schema changed, among other possible information., [0024] The fields lost and fields gained columns 2114 specifies the names of the fields that were added, removed, or modified as part of the identified schema change, [0025] a schema consistency monitor can perform various types of automated actions in response to identifying one or more schema changes. For example, a schema consistency monitor can generate one or more alerts (for example, email alerts, dashboard alerts, and so forth) in response to determining that a schema change has occurred, [0227])
Esman does not appear to explicitly teach:
the alerts include an impacted rules or scripts, and potential security repercussions.
However, Gopal teaches:
the alerts include an impacted rules or scripts and potential security repercussions (Gopal, Transformation information includes, for example, column-column mappings, table/view join expressions and other queries, and XSLTs, [0019] the CDM service 207 identifies via the user interface (FIG. 4) actions that can be taken for each grouping of impacted objects. The groupings of impacted objects may include groups of heterogeneous objects whereby a change to an impacted object at one end of the end-to-end information flow can trigger a change to a heterogeneous object at the other end of the end-to-end information flow. The groups of heterogeneous objects include packets, tables, mappings, files, views, stored procedures, web services, target information, connection information, transformation information, and/or references to information, [0035] An impacted items box 410 shows the items impacted by the selected source in box 402 in this case, SA_SAP_VENDOR is impacted., [0039] notify another user through an email (or other means of communication) that their attention is required to handle a change, refresh the change-list, or automatically use the system-suggested way of handling the change, [0040]) [Examine interprets that impacted mappings, expressions, queries, and transformation artifacts as impacted rules/scripts]. Same motivation applies as claim 1.
Esman and Gopal does not explicitly teach:
the alerts include potential security repercussions
However, Livny teaches:
the alerts include potential security repercussions (Livny, Severity determiner 306 of adaptive severity system 300 is configured to receive at least one security alert 312. Security alert 312 may be any alert generated by a security system, ..may be a single alert, an informational alert, or a fusion alert that is an aggregation of several alerts that have been correlated to a single event or related events. Security alert 312 may be associated with any entity or resource within a system, [0053] Severity determiner 306 may be configured to determine the default severity based on factors such as T/F confidence, other alerts, resource importance, etc. The default severity may include different levels, such as high, medium or low or a numerical range (e.g., 0-4). For example, a high severity may indicate a high probability that a resource is compromised and that there is high confidence in malicious intent and in the data used to issue the alert. As another example, a medium severity may correspond to a suspicious activity that indicates that a resource is compromised and that there is medium confidence in malicious intent and in the findings or analytics used to issue the alert. As yet another example, a low severity may be indicative of a benign or blocked attack, that there is low confidence in malicious intent, or the detected activity may be innocent, [0054] Alert manager 310 is further configured to manage security alert 312 by assembling and/or generating a notification 322 that may include at least security alert 312 and its updated severity level. ..include contextual information or explanatory information relating to the change from the default severity level to the modified severity level of security alert 312, [0068]) [Examiner interprets that severity information indicating the likelihood that a computing resource has been compromised, suspicious activity, malicious intent, or blocked/benign attack as information as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Esman and Gopal to include a concept of the alerts include potential security repercussions as taught by Livny for the purpose of providing a user with information indicating severity and potential impact associated with detected condition for enabling the user to prioritize alerts and determine an appropriate corrective actions [Livny:0039].
Regarding claim 6, Esman, Gopal, and teaches the method of claim 5, wherein the alerts further include suggestions for remediations derived from analyzing dependency profiles and patterns in the detected changes including updating field references, modifying threshold logic, or implementing validation scripts to pre-process malformed data (Gopal, This CDM service uses shredded or modularized metadata that granularly describes an end-to-end information flow and associated underlying dependencies between source information, mappings, target information and business applications, [0006] derives possible user actions that are needed to manage the change based on registration of such actions, and possibly updates the affected objects or relationships automatically when the changes are simple or non-severe enough to be merged or applied without any human or user intervention, [0014] References to information include explicit references in shredded metadata to represent all related information wherever possible, including other objects in shredded metadata, instead of using a human-readable-name. Thus, if a piece of information changes, the CDM service can examine all the related pieces of information by following the references, and if needed, recursively examine and retrieve the references from these related pieces of information as well to build a list of all the affected pieces of information., [0019] The metadata stored in the metadata repository 108 describes an end to end information flow and underlying dependencies between the source information, mappings, the targets and the source-independent business applications 105, [0021] corrective actions that need to be taken can be displayed based on registered actions for a certain type of change associated with a certain object, [0026] the possible actions that can be taken to correctly handle the change selected in the source of impact box 402. This is typically one of two things: (i) Change a structure definition, or (ii) Change a mapping definition. The buttons on the bottom of the UI 400 allow the user to commit changes via button 407, notify another user through an email (or other means of communication) that their attention is required to handle a change, refresh the change-list, or automatically use the system-suggested way of handling the change, [0040]) [Examiner interprets that system recursively follows and manages those references when source information changes and changing a mapping/reference responsive to a renamed source item as limitation above].
Regarding claims 15 and 16, Claim 15and 16 recite commensurate subject matter as claims 5 and 6 respectively. Therefore, they are rejected for the same reasons.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Esman(US 20210191909 A1) in view of Gopal (US 20080071844 A1) in further view of Tang (US 20210194909 A1).
Regarding claim 9, Esman and Gopal teaches the method of claim 1, further comprising
Esman and Gopal do not appear to explicitly teach:
automatically detecting and resolving malformed or corrupted data entries within incoming data flows that disrupt rule processing and result in security vulnerabilities
However, Tang teaches:
automatically detecting and resolving malformed or corrupted data entries within incoming data flows that disrupt rule processing and result in security vulnerabilities (Tang, The data processing device 402 also performs data preparation on the original data. Data preparation is often used for processing confusing, inconsistent or non-standard data, attempting to combine data from multiple sources and process data obtained from unstructured sources. For the original data (especially unstructured data) collected from the OT environment, the data processing device needs to perform data preparation in terms of data aggregation, data cleanse, data transformation, and feature selection and reduction, so as to make OT data available for enrichment, correlation and security analysis, [0331] The data processing device 402 can perform real-time anomaly detection on the data after data preparation and the data after post-processing according to a preset machine learning algorithm, such as identifying an abnormal security event or behavior, [0333] After receiving the security logs from different OT fields and the Internet, the data flow processing 83 may perform data preparation processing 83a on original logs based on a streaming engine (such as Flink and Storm),[0359] data cleanse, that is, checking, adding, amending and deleting (if necessary) the original logs from different OT fields and the Internet, and specific operations include: correcting or deleting malformed logs, adding or deleting missing log fields, and so on, [0361] data transformation, due to the fact that logs from different data sources (Windows logs, firewalls/WAF, routers/switches) have different formats and there are cases where similar fields have different field names, even the contents of the fields are different, similar fields need to be mapped into the same field name, and the field names of different fields needs to be standardized in a unified manner, [0362] For the security logs after the data preparation processing 83a and the security event or behavior sequence data after the data fusion and correlation operation 83d, the data flow processing 83 also supports the use of different machine learning algorithms 83e (such as unsupervised learning, reinforcement learning and grammatical inference) on the streaming engine to process the security logs and the security event or behavior sequence data, and identify abnormal security events or behaviors therefrom, [0378]) [Examiner interprets that system teaching an automated streaming security data processing system that identifies problematic/malformed incoming security data and resolves such data by correcting, deleting, supplementing, and /or standardizing the affected entries so that the data can be properly processed for downstream security analysis as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Esman and Gopal to include a concept of automatically detecting and resolving malformed or corrupted data entries within incoming data flows that disrupt rule processing and result in security vulnerabilities as taught by Tang for the purpose of performing real-time anomaly detection on the data after data preparation and the data after post-processing, such as identifying an abnormal security event or behavior, [Tang:0333].
Regarding claim 19, Claim 19 recite commensurate subject matter as claim 9. Therefore, it is rejected for the same reasons.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Esman(US 20210191909 A1) in view of Gopal (US 20080071844 A1) in further view of Zhang (US 20170187750 A1).
Regarding claim 10, Esman and Gopal teaches the method of claim 1 wherein the mapping includes
Esman and Gopal do not appear to explicitly teach:
automatically translating and adapting security scripts, rules, and alerts between different scripting languages.
However, Zhang teaches:
automatically translating and adapting security scripts, rules, and alerts between different scripting languages (Zhang, configuration converter 120 may receive an input configuration file 110 in which security policies are expressed in a first language and convert input configuration file 110 to an output configuration file 130 in which the security policies are expressed in a second language. Input configuration file 110 can be parsed and executed by a first network security appliance from a first vendor and output configuration file 130 can be parsed and executed by a second network security appliance from a second vendor. Both the first language and the second language can be used for defining network security policies that control network traffic going through a network. A language of a configuration file may be a scripting language. Commands of the scripting language can be interpreted at runtime and executed by a network security appliance through a command line interface (CLI). An example of a configuration file written in a scripting language is shown below…, [0031] when optimizing module 124 meets similar policy fragments, the optimizing rule may be applied automatically and repeated security policies, conflicting security policies, encompassing security policies and mergeable security policies may be processed to avoid policy fragments, [0062] the converter parses the network policies in the first language into intermediate representations. A compiler or interpreter of the first language may translate the network security policies from the first language into intermediate representations that are generic data structures that are not tied to a particular machine to represent network security policies, The intermediate representation may include a syntax tree representation of a network security policy. No matter what language is used by input configuration file, a corresponding language compiler or interpreter may convert the source code of input configuration file into intermediate representations, [0075] the intermediate representation may be optimized by resolving policy fragments automatically. The converter may select one security policy of a set of repeated policies and delete others from the intermediate representation and merge the mergeable policies into one security policy. For encompassing policies and conflicting policies, the most secure policy of these security policies may be retained within the intermediate representation, [0085]) [Examiner interprets that system using network security configuration converter for translating security policies/rules/scripts into language independent intermediate representation, automatically optimizing the policies, and translating the resulting policies into second language as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Esman and Gopal to include a concept of automatically translating and adapting security scripts, rules, and alerts between different scripting languages as taught by Zhang for the purpose of translating first language and converting input configuration file 110 to an output configuration file 130 in which the security policies are expressed in a second language [Zhang:0031].
Regarding claim 20, Claim 20 recite commensurate subject matter as claim 10. 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 20210273970 A1: “relates to a system, method and computer readable medium for identifying missing organizational security detection system rules”
US 20150161193 A1: “relates to industrial process control systems, and more specifically, to data validation in industrial process control systems”
US 20220094714 A1: “embraces a system for mapping information security configurations across technology platforms”
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 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
