DETAILED ACTION
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 .
Response to Amendment
The amendment filed 01 October 2025 has been entered. Applicant amended claims 1 and 10-11, and cancelled claim 20. Accordingly, claims 1-19 remain pending.
Response to Arguments
Applicant's arguments filed 01 October 2025 have been fully considered but they are not persuasive.
Applicant’s remarks 1:
Based on the Examiner's "Response to Arguments" there is a claim construction issue that must be addressed. In this regard, the Examiner has determined that "Traffic- related configuration parameter encompass[es] broader application than traffic configuration parameter." Her position in this regard is based on the (unattributed) predicate that "It is understood that configuration refers to an arrangement of functional units according to the nature, number, and chief characteristics, and pertains to hardware, software, firmware, and documentation, as well as the specific selection of operational parameters, and or parameter settings, capacity, capability etc." (See, Examiner's Response at page 3). Respectfully, the Examiner's positions here are incorrect.
Applicant’s support:
Claim construction must always precede the question of whether the claim, as
properly construed, is patentable. Medichem, S.A. v. Rolabo, S.L., 353 F.3d 928, 933 (Fed. Cir. 2003). …The construction that stays true to the claim language and most naturally aligns with the patent's description of the invention will be, in the end, the correct construction." Phillips, 415 F.3d at 1316 (quoting Renishaw PLC v. Marposs Societa' perAzioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998)). Here, the Applicant has defined what it means to be a "traffic-related configuration parameter" by the very words in the claim element itself. In particular, a "traffic-related configuration parameter" is "determined by applying one or more traffic-related configuration parameter rules that define traffic-related configuration parameters with respect to one or more values in configurations of the computing interface that are known
to contain traffic-related configuration data." In other words, here Applicant is acting as a lexicographer, and this claim definition is also set forth and supported by the Specification, namely, paragraph [0036], which includes virtually identical language. Given this explicit lexicon, the Examiner errs in interpreting the "traffic-related configuration parameter" phrase in an unconstrained manner, especially as her definition is itself based on a predicate list where the Examiner basically concludes that a "configuration" can refer to
the "nature, number, and chief characteristics" and "operational parameters, and or parameter setting, capacity, capability etc." of computing elements or documentation, a list
that basically has no real bounds. Moreover, the notion of "broadest reasonable interpretation" does not apply here given the explicit lexicon in the claim element itself. MPEP §2111 - which defines the "broadest reasonable interpretation" (BRI) claim construction standard that applies - sets forth this relevant guidance: "The broadest reasonable interpretation does not mean the broadest possible interpretation. Rather, the meaning given to a claim term must be consistent with the ordinary and customary meaning of the term (unless the term has been given a special definition in the specification), and must be consistent with the use of the claim term in the specification and drawings." (emphasis supplied). Here, paragraph
[0036] in Applicant's Specification provides the "special definition," and this definition is literally carried forth in the actual claim language. As the above case law notes: "In construing claims, the analytical focus must begin and remain centered on the language of the claims themselves, ..." (emphasis supplied)…. Thus, the proper definition of the phrases "traffic-related configuration parameter" and "contextual misconfiguration rule" are not some unconstrained BRI, but rather as they are specified explicitly in the claim element itself.
Examiner’s remarks:
Paragraph 36 of Applicant’s specification provides an example that configuration parameter may be identified values of certain predetermined fields of configurations known to contain traffic related configuration data. An example does not provide a special definition of a claim terms that differs from the plain and ordinary meaning. To act as their own lexicographer, the applicant must clearly set forth a special definition of a claim term in the specification that differs from the plain and ordinary meaning it would otherwise possess. CCS Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1366, 62 USPQ2d 1658, 1662 (Fed. Cir. 2002). The specification may also include an intentional disclaimer, or disavowal, of claim scope. The specification nor the claims provide no further teachings on traffic related configuration data or configuration parameter. Therefore, the examiner maintains that the generality of the claims does not prevent the prior art of record. The prior art teaches the limitations as disclosed in the office action and the examiner maintains the rejection.
Applicant argument 2:
Regarding the nature of the "configuration parameter," in Subbarayan (which the Examiner again relies upon), the "data parameters are selected based on their relevance to identifying indicators of compromise corresponding to one or more APIs." … Subbarayan does not go further, e.g., to describe the particular nature of the "configurations ... and information." As noted above, the particular definition that should be applied to the "traffic-related configuration parameter" is not some generic information associated with a "configuration" at the Examiner states in her "Response to Arguments," but rather it is the particular parameter that is positively defined in the claim element itself. While Subbarayan's solution does involve extracting data from raw data logs or from data packets corresponding to real-time API traffic, that data is not the "traffic-related configuration parameter" specified because it does not satisfy the following Specification- and claim-specific definition: "wherein ... a traffic-related configuration parameter [is] determined by applying one or more traffic-related configuration parameter rules that define traffic-related configuration parameters with respect to one or more values in configurations of the computing interface that are known to contain traffic-related configuration data." In Subbarayan, the only data referenced and that is relevant to traffic is the actual "traffic data" itself; at most, this relates to the second element of the claim, but not the first element in which the "traffic-related configuration parameter" is actually defined.
Examiner’s remarks:
An example does not provide a special definition of a claim terms that differs from the plain and ordinary meaning. To act as their own lexicographer, the applicant must clearly set forth a special definition of a claim term in the specification that differs from the plain and ordinary meaning it would otherwise possess. The specification may also include an intentional disclaimer, or disavowal, of claim scope. The examiner does not find an intentional disclaimer nor a special definition clearly set forth in the specification. The specification nor the claims provide further teachings on traffic related configuration parameter, one or more values, and configuration parameter. In addition, traffic-related is a subjective term that can encompass a broad-range of data. Therefore, the examiner maintains that the generality of the claims does not prevent the prior art of record. The prior art teaches the limitations as disclosed in the office action and the examiner maintains the rejection.
Applicant’s claims disclose that the configuration parameter is based on configuration data related to a computing interface. Therefore, the computing interface is the API as taught in the prior art of Subbarayan. Paragraphs 45-46 of Subbarayan disclose the selection (identification) of the data parameter (configuration parameter) for extraction in connection with the API (computer interface) is dependent upon data from raw data logs or from data packets corresponding to real-time API traffic that is being received (therefore, the data parameter is traffic-related because it is dependent upon data packets and data logs from API traffice). The selection of data parameters for extraction in connection with an API may be dependent on rules such as API configurations and information corresponding to said API configurations—which API configurations and information that is available on the security gateway or on any hosting system(s). API configurations and information corresponding to said API configurations—which API configurations and information that is available on the security gateway or on any hosting system(s) are “traffic-related” configuration parameters with respect to one or more values in configurations of the Application programming interface (API) that contain traffic related configuration data. Traffic-related is a subjective term that can encompass a broad-range of data. Therefore, the examiner maintains that the generality of the claims does not prevent the prior art of record. The prior art teaches the limitations as disclosed in the office action and the examiner maintains the rejection.
Applicant argument 3:
Because Subbarayan does not disclose or suggests the "traffic-related configuration parameter ... determined by applying one or more traffic- related configuration parameter rules that define traffic-related configuration parameters with respect to one or more values in configurations of the computing interface that are known to contain traffic-related configuration data," it follows that the recited use of the "traffic-related configured parameter" as being a component of the "combination of at least one traffic-related configuration parameter and at least one determined traffic behavior" for "detecting misconfiguration of the computing interface" is also neither disclosed nor suggested by the Subbarayan teaching.
Examiner’s remarks: see examiner’s remarks above.
In addition, paragraphs 45 and 47 of Subbarayan disclose data packets that corresponds to real-time API traffic is used to develop one or more anomaly detection models, thus API traffic behavior analysis/behavior.
Applicant argument 4:
Brendel does not provide for the following particular subject matter either: "detecting at least one misconfiguration of the computing interface by applying a one or more contextual misconfiguration rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior, wherein at least one contextual misconfiguration rule defines a respective misconfiguration of the computing interface as a combination of the at least one traffic-related configuration parameter and the at least one determined traffic behavior."
Applicant’s support:
In this regard, and as the Claim Construction section notes, the that the "contextual misconfiguration rule" has a specific definition that should be applied; with due respect, the Examiner has not done so.
The two parameters are not being combined into some "rule" - let alone a rule defining a respective misconfiguration of the computing interface - that is then evaluated. … At most, any combination of the Subbarayan-Kapoor-Brendel teaches monitoring traffic to detect some traffic behavior, as well as separate notion of identifying incorrect or improper values of a configuration based on configuration data, possibly associated with an API. The combined teachings would not disclose or suggest any notion of applying a "contextual misconfiguration rule" where the "context" is further specified, namely, as a "combination of the at least one traffic-related configuration parameter and the at least one determined traffic behavior."
Examiner’s remarks:
To act as their own lexicographer, the applicant must clearly set forth a special definition of a claim term in the specification that differs from the plain and ordinary meaning it would otherwise possess. The specification may also include an intentional disclaimer, or disavowal, of claim scope. The examiner does not find an intentional disclaimer nor special definition clearly set forth in the specification. The examiner recommends for Applicant to pinpoint in the specification the special definition (an example is not a special definition).
Subbarayan’s discloses detecting at least one deviation/anomaly by applying one contextual deviation rules to the identified traffic related configuration parameter and the determined at least one traffic behavior as disclosed in the office action. Brendel resolved the deficiency of Subbarayan by disclosing detecting a misconfiguration by applying contextual misconfiguration rules to the identified traffic related configuration parameter and the determined at least one traffic behavior. The misconfiguration/abnormality is defined as the deviation between the normal traffic profile parameter (traffic related configuration parameter), the current traffic profile parameter (traffic behavior) and a threshold.
Examiner’s further remarks:
As indicated in the examiner’s remarks above and in the current office action, the argued limitations in the independent claims do not overcome the prior art applied in the 35 USC 103 rejection. Thus, the independent claims are not allowable over the prior art of record and their dependent claims are not allowed based on their dependencies.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1-5 and 9-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Subbarayan et al US 20200304470 (hereinafter Subbarayan) in view of Kapoor et al US 11153339 (hereinafter Kapoor) in further view of Brendel US 20050125195 (hereinafter Brendel).
As to claim 1, Subbarayan teaches a method for traffic-based [deviations-anomaly] detection (abstract disclose methods/systems for API traffic analysis and network security to detect deviations/anomaly from normal traffic parameter baselines), comprising:
identifying at least one configuration parameter based on configuration data related to a computing interface (paragraph 4 discloses “identifying and mapping characteristics of normal traffic for each API; paragraph 12 also disclose identify one or more API parameters corresponding to API. Paragraph 45 discloses extracting data corresponding to a selected set of data parameters which data parameters are selected based on their relevance to identifying indicators of compromise corresponding to one or more APIs. Paragraph 46 discloses parameters are based on API configuration information), wherein the at least one configuration parameter is a traffic-related configuration parameter determined by applying one or more traffic-related configuration parameters rules that define traffic-related configuration parameters with respect to one or more values in configurations of the computing interface that are known to contain traffic related configuration data (paragraphs 45-46 discloses the selection of data parameters for extraction in connection with an API is dependent on API configuration and information corresponding to said API configurations [thus the parameter rules for selection] such as which API configurations and information that are available on the security gateway/ from data packets corresponding to real-time traffic that is being received);
determining at least one traffic behavior based on traffic data of traffic to and from the computing interface, the traffic data being distinct from the traffic related configuration data (paragraphs 45 and 47 disclose the data corresponding to data parameters that has been extracted from data packets corresponding to real-time API traffic is used to develop one or more anomaly detection models/ API traffic analysis. The models may be implemented to process application layer traffic information and identify/determine deviations from normal or baseline traffic pattern, see also paragraph 77. The API configuration data/traffic related configuration data is distinct from the traffic data/monitored real time API traffic ); and
detecting at least one [deviation] of the computing interface by applying one or more contextual [deviation] rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior (paragraph 8 discloses identifying one or more deviations between data extracted from traffic data corresponding to the selected API and one or more traffic parameter baseline values defined by the anomaly detection model corresponding to the selected API; paragraph 53 also discloses identifying one or more deviations between extracted parameter data corresponding to the selected API and one or more predefined traffic parameter baseline values. Thus parameter data and predefined traffic parameter baseline values correspond to the contextual [deviation] rules. The deviation is detected by applying the parameters/rules to the identified/extract traffic behavior model and the data parameters that has been extracted from data packets that corresponding to the real time API traffic. Paragraph 46 discloses parameters are based on API configuration information. Paragraph 87 further disclose contextual analysis of API traffic and paragraph 96 further disclose context models), wherein at least one contextual [deviation] rule defines a respective [deviation] of the computing interface of the at least one traffic-related configuration parameter (paragraph 53 also disclose identifying one or more deviations based on the extracted parameter data corresponding to the selected API and one or more predefined traffic parameter baseline values; paragraph 46 discloses parameters are based on API configuration information).
Subbarayan does not teach the deviations are misconfigurations and detecting at least one misconfiguration by applying one or more contextual misconfiguration rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior; wherein at least one contextual misconfiguration rule defines a respective misconfiguration as a combination of at least one predetermined configuration parameter and at the least one determined traffic behavior.
Kapoor teaches the deviations are misconfigurations (column 13, lines 45-50 disclose deviations may be due to misconfiguration. Abstract disclose monitoring activities within a network. Column 6, lines 52+ to column 7, lines 1-5 disclose these activities involves collecting/monitoring information by agent, by monitoring nodes for network activity, by using a network packet capture tool. As packets are received the agent obtains and maintains connection information with the network activity such as DNS query, response, TCP, UDP, and IP information. The agent use a kernel network diagnostic API to obtain inode process information and obtain information relating to socket state, whether a socket is connected, listening, etc..,).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Subbarayan’s traffic based deviation detection to incorporate Kapoor’s teachings of software agent detecting deviations such as misconfigurations from network diagnostic API to automatically detect and report information in varying amount of details and/or with variable frequency (column 4, lines 37-39 of Kapoor).
The combination of Subbarayan in view of Kapoor does not teach detecting at least one misconfiguration by applying one or more contextual misconfiguration rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior; wherein at least one contextual misconfiguration rule defines a respective misconfiguration as a combination of at least one predetermined configuration parameter and at the least one determined traffic behavior.
Brendel teaches detecting at least one misconfiguration by applying one or more contextual misconfiguration rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior (paragraphs 9 and 38-39 disclose monitoring network traffic for a traffic profile/behavior abnormality. The data extracted for the determination/evaluation include historical traffic data gathering means to provide at least one selected normal traffic parameter, observing means for observing the current traffic data relating to the selected parameter to provide at least one current traffic parameter, and evaluating means to evaluate a deviation between the normal traffic profile parameter and the current traffic profile parameter against a threshold to determine whether a traffic abnormality exists. The rule for detecting misconfiguration/abnormality is defined as the deviation between the normal traffic profile parameter and the current traffic profile parameter against a threshold. Paragraph 126 reveals each observation may have its own rules for classifying data); wherein at least one contextual misconfiguration rule defines a respective misconfiguration as a combination of at least one traffic-related configuration parameter and at the least one determined traffic behavior (paragraphs 38-39 disclose the rule for detecting misconfiguration/abnormality is defined as the deviation between the normal traffic profile parameter (traffic-related configuration parameter ) and the current traffic profile parameter (the determined traffic profile/behavior) against a threshold. Paragraph 126 reveals each observation may have its own rules for classifying data).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Subbarayan’s traffic based deviation detection to incorporate Kapoor’s teachings of software agent detecting deviations such as misconfigurations from network diagnostic API in view of Brendel’ misconfiguration rules to overcome or alleviate problems in network security by providing a means to detect flood-style denial of service attacks and provide a product for network communication security that allows for the implementation of a scalable platform for the deployment of security services (paragraphs 13-14 of Brendel).
As to claim 2, the combination of Subbarayan in view of Kapoor and Brendel teaches further comprising: performing at least one mitigation action with respect to the computing interface based on the detected misconfiguration (Subbarayan: paragraph 54 discloses responsive to identification of deviations, the system categorizes the identified deviation within an appropriate category. Paragraph 108 discloses the controller may discard or reject transmission of communication/messages/traffic events that have been determined to be representative of an anomaly. Brendel: paragraphs 61 and 124-125 disclose when there is an abnormality triggering an alarm for further actions such as active filtering). Motivation similar to the motivation presented in claim 1.
As to claim 3, the combination of Subbarayan in view of Kapoor and Brendel teaches wherein each contextual misconfiguration rule is associated with at least one predetermined mitigation action ( Brendel: paragraphs 61 and 124-125 disclose when there is an abnormality triggering an alarm for further actions such as active filtering). Motivation similar to the motivation presented in claim 1.
As to claim 4, the combination of Subbarayan in view of Kapoor and Brendel teaches wherein the computing interface is a first computing interface (Subbarayan: paragraph 5 discloses first API), further comprising: managing a cybersecurity posture of an environment in which the first computing interface is deployed (Subbarayan: paragraph 5 discloses generating a first anomaly detection model/posture based on parameter data extracted from traffic data corresponding to the first API) by creating an inventory of second computing interfaces used for communications in the environment based on the identified at least one configuration parameter and the determined at least one traffic behavior (Subbarayan: paragraph 106 disclose model is based on one or more data logs, API configurations extracted from API configuration database, and model dictionary database. Data log historian may comprise a database configured to store data logs relating to data messages and communication to and from APIs or API servers. API configuration databases may be configured for one or more APIs and additionally to store an association between each API configuration and a corresponding API. Paragraph 96 disclose for the model, the model include IP address/cookie/token/API key specific features (used to identify the source of the traffic) for each API. Paragraph 75 further describe model dictionary and the anomaly models are stored in the model dictionary), wherein the at least one misconfiguration is detected based further on the inventory (Subbarayan: paragraph 63 discloses the model or traffic parameter baselines corresponding to the anomaly detection model is used to identify deviation/misconfigurations. Paragraph 106 disclose model is based on one or more data logs, API configurations extracted from API configuration database, and model dictionary database. Data log historian may comprise a database configured to store data logs relating to data messages and communication to and from APIs or API servers. API configuration databases may be configured for one or more APIs and additionally to store an association between each API configuration and a corresponding API. Paragraph 96 disclose for the model, the model include IP address/cookie/token/API key specific features (used to identify the source of the traffic) for each API. Paragraph 75 further describe model dictionary).
As to claim 5, the combination of Subbarayan in view of Kapoor and Brendel teaches wherein the inventory indicates, for each of the first and second computing interfaces, at least one of: data types handled by the computing interface, whether the computing interface is Internet-facing, whether the computing interface enforces authentication, and whether the computing interface requires authentication (Subbarayan: paragraph 75 discloses the anomaly models are stored in the model dictionary and which is associated with the API type, API class or category or one or more API characteristics).
As to claim 9, the combination of Subbarayan in view of Kapoor and Brendel teaches wherein at least a portion of the configuration data related to the computing interface is determined based on at least one computing component to which the computing interface is exposed (Subbarayan: paragraph 96 discloses the model data can be based upon IP address/cookie/token/API key specific features which are information that can be used to identify the source of the traffic. Brendel: paragraph 23 discloses traffic evaluation device that includes a data interface to receive network traffic and data indicative of characteristic of network traffic and evaluating the network traffic and data received by the data interface). Motivation similar to the motivation presented in claim 1.
As to claim 10, Subbarayan teaches a non-transitory readable medium having stored thereon instructions for causing a processing circuitry to execute a process (paragraph 23 discloses non-transitory computer readable medium having a computer readable program code comprising instructions for implementing methods), the process comprising:
identifying at least one configuration parameter based on configuration data related to a computing interface (paragraph 4 discloses “identifying and mapping characteristics of normal traffic for each API; paragraph 12 also discloses identify one or more API parameters corresponding to API. Paragraph 45 discloses extracting data corresponding to a selected set of data parameters which data parameters are selected based on their relevance to identifying indicators of compromise corresponding to one or more APIs. Paragraph 46 discloses parameters are based on API configuration information), wherein the at least one configuration parameter is a traffic-related configuration parameter determined by applying one or more traffic-related configuration parameters rules that define traffic-related configuration parameters with respect to one or more values in configurations of the computing interface that are known to contain traffic related configuration data (paragraphs 45-46 discloses the selection of data parameters for extraction in connection with an API is dependent on API configuration and information corresponding to said API configurations [thus the parameter rules for selection] such as which API configurations and information that are available on the security gateway/ from data packets corresponding to real-time traffic that is being received
determining at least one traffic behavior based on traffic data of traffic to and from the computing interface, the traffic data being distinct from the traffic related configuration data (paragraphs 45 and 47 disclose the data corresponding to data parameters that has been extracted from data packets corresponding to real-time API traffic is used to develop one or more anomaly detection models/ API traffic analysis. The models may be implemented to process application layer traffic information and identify/determine deviations from normal or baseline traffic pattern, see also paragraph 77. The API configuration data/traffic related configuration data is distinct from the traffic data/monitored real time API traffic ); and
detecting at least one [deviation] of the computing interface by applying one or more contextual [deviation] rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior (paragraph 8 discloses identifying one or more deviations between data extracted from traffic data corresponding to the selected API and one or more traffic parameter baseline values defined by the anomaly detection model corresponding to the selected API; paragraph 53 also discloses identifying one or more deviations between extracted parameter data corresponding to the selected API and one or more predefined traffic parameter baseline values. Thus parameter data and predefined traffic parameter baseline values correspond to the contextual misconfiguration rules. The deviation is detected by applying the parameters/rules to the identified/extract traffic behavior model and the data parameters that has been extracted from data packets that corresponding to the real time API traffic. Paragraph 46 discloses parameters are based on API configuration information. Paragraph 87 further discloses contextual analysis of API traffic and paragraph 96 further discloses context models), wherein each contextual [deviation] rule defines a respective [deviation] as a combination of at least one predetermined configuration parameter and at least one predetermined traffic behavior (paragraph 53 also discloses identifying one or more deviations based on the extracted parameter data corresponding to the selected API and one or more predefined traffic parameter baseline values; paragraph 46 discloses parameters are based on API configuration information).
Subbarayan does not teach the deviations are misconfigurations and detecting at least one misconfiguration by applying a plurality of contextual misconfiguration rules to the identified at least one configuration parameter and the determined at least one traffic behavior; wherein each contextual misconfiguration rule defines a respective misconfiguration as a combination of at least one predetermined configuration parameter and at least one predetermined traffic behavior.
Kapoor teaches the deviations are misconfigurations( column 13, lines 45-50 disclose deviations may be due to misconfiguration. Abstract disclose monitoring activities within a network. Column 6, lines 52+ to column 7, lines 1-5These activities involves collecting/monitoring information by agent, by monitoring nodes for network activity, by using a network packet capture tool. As packets are received the agent obtains and maintains connection information with the network activity such as DNS query, response, TCP, UDP, and IP information. The agent use a kernel network diagnostic API to obtain inode process information and obtain information relating to socket state, whether a socket is connected, listening, etc..,).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Subbarayan’s traffic based deviation detection to incorporate Kapoor’s teachings of software agent detecting deviations such as misconfigurations from network diagnostic API to automatically detect and report information in varying amount of details and/or with variable frequency (column 4, lines 37-39 of Kapoor).
The combination of Subbarayan in view of Kapoor does not teach detecting at least one misconfiguration by one or more contextual misconfiguration rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior; wherein at least one contextual misconfiguration rule defines a respective misconfiguration as a combination of at least one predetermined configuration parameter and at the least one determined traffic behavior.
Brendel teaches detecting at least one misconfiguration by one or more contextual misconfiguration rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior (paragraphs 38-39 disclose monitoring network traffic for a traffic profile/behavior abnormality. The data extracted for the determination/evaluation include historical traffic data gathering means to provide at least one selected normal traffic parameter, observing means for observing the current traffic data relating to the selected parameter to provide at least one current traffic parameter, and evaluating means to evaluate a deviation between the normal traffic profile parameter and the current traffic profile parameter against a threshold to determine whether a traffic abnormality exists. The rule for detecting misconfiguration/abnormality is defined as the deviation between the normal traffic profile parameter and the current traffic profile parameter against a threshold. Paragraph 126 reveals each observation may have its own rules for classifying data ); wherein at least one contextual misconfiguration rule defines a respective misconfiguration as a combination of at least one traffic-related configuration parameter and at the least one determined traffic behavior (paragraphs 38-39 disclose the rule for detecting misconfiguration/abnormality is defined as the deviation between the normal traffic profile parameter (traffic-related configuration parameter ) and the current traffic profile parameter (the determined traffic profile/behavior) against a threshold. Paragraph 126 reveals each observation may have its own rules for classifying data).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Subbarayan’s traffic based deviation detection to incorporate Kapoor’s teachings of software agent detecting deviations such as misconfigurations from network diagnostic API in view of Brendel’ misconfiguration rules to overcome or alleviate problems in network security by providing a means to detect flood-style denial of service attacks and provide a product for network communication security that allows for the implementation of a scalable platform for the deployment of security services (paragraphs 13-14 of Brendel).
As to claim 11, Subbarayan teaches a system contextual [deviations-anomaly] detection (abstract discloses methods/systems for API traffic analysis and network security to detect deviations/anomaly from normal traffic parameter baselines), comprising:
a processing circuitry (paragraph 110 discloses one or more processors);
a memory, the memory containing instructions that when executed by the processing circuitry (paragraphs 23 and 101 disclose non-transitory computer readable medium/memory having a computer readable program code comprising instructions for implementing methods. The processor is configured to execute the program instructions), configure the system to:
identify at least one configuration parameter based on configuration data related to a computing interface (paragraph 4 discloses “identifying and mapping characteristics of normal traffic for each API; paragraph 12 also disclose identify one or more API parameters corresponding to API. Paragraph 45 disclose extracting data corresponding to a selected set of data parameters which data parameters are selected based on their relevance to identifying indicators of compromise corresponding to one or more APIs. Paragraph 46 discloses parameters are based on API configuration information), wherein the at least one configuration parameter is a traffic-related configuration parameter determined by applying one or more traffic-related configuration parameters rules that define traffic-related configuration parameters with respect to one or more values in configurations of the computing interface that are known to contain traffic related configuration data (paragraphs 45-46 discloses the selection of data parameters for extraction in connection with an API is dependent on API configuration and information corresponding to said API configurations [thus the parameter rules for selection] such as which API configurations and information that are available on the security gateway/ from data packets corresponding to real-time traffic that is being received);
determining at least one traffic behavior based on traffic data of traffic to and from the computing interface, the traffic data being distinct from the traffic related configuration data (paragraphs 45 and 47 disclose the data corresponding to data parameters that has been extracted from data packets corresponding to real-time API traffic is used to develop one or more anomaly detection models/ API traffic analysis. The models may be implemented to process application layer traffic information and identify/determine deviations from normal or baseline traffic pattern, see also paragraph 77. The API configuration data/traffic related configuration data is distinct from the traffic data/monitored real time API traffic ); and
detect at least one [deviation] of the computing interface by applying one or more contextual [deviation] rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior (paragraph 8 discloses identifying one or more deviations between data extracted from traffic data corresponding to the selected API and one or more traffic parameter baseline values defined by the anomaly detection model corresponding to the selected API; paragraph 53 also discloses identifying one or more deviations between extracted parameter data corresponding to the selected API and one or more predefined traffic parameter baseline values. Thus parameter data and predefined traffic parameter baseline values correspond to the contextual [deviation] rules. The deviation is detected by applying the parameters/rules to the identified/extract traffic behavior model and the data parameters that has been extracted from data packets that corresponding to the real time API traffic. Paragraph 46 discloses parameters are based on API configuration information. Paragraph 87 further disclose contextual analysis of API traffic and paragraph 96 further disclose context models), wherein at least one contextual [deviation] rule defines a respective [deviation] of the computing interface of the at least one traffic-related configuration parameter (paragraph 53 also disclose identifying one or more deviations based on the extracted parameter data corresponding to the selected API and one or more predefined traffic parameter baseline values; paragraph 46 discloses parameters are based on API configuration information).
Subbarayan does not teach the deviations are misconfigurations and detecting at least one misconfiguration by applying one or more contextual misconfiguration rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior; wherein at least one contextual misconfiguration rule defines a respective misconfiguration as a combination of at least one predetermined configuration parameter and at the least one determined traffic behavior.
Kapoor teaches the deviations are misconfigurations (column 13, lines 45-50 disclose deviations may be due to misconfiguration. Abstract disclose monitoring activities within a network. Column 6, lines 52+ to column 7, lines 1-5 disclose these activities involves collecting/monitoring information by agent, by monitoring nodes for network activity, by using a network packet capture tool. As packets are received the agent obtains and maintains connection information with the network activity such as DNS query, response, TCP, UDP, and IP information. The agent use a kernel network diagnostic API to obtain inode process information and obtain information relating to socket state, whether a socket is connected, listening, etc..,).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Subbarayan’s traffic based deviation detection to incorporate Kapoor’s teachings of software agent detecting deviations such as misconfigurations from network diagnostic API to automatically detect and report information in varying amount of details and/or with variable frequency (column 4, lines 37-39 of Kapoor).
The combination of Subbarayan in view of Kapoor does not teach detecting at least one misconfiguration by one or more contextual misconfiguration rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior; wherein at least one contextual misconfiguration rule defines a respective misconfiguration as a combination of at least one predetermined configuration parameter and at the least one determined traffic behavior.
Brendel teaches detecting at least one misconfiguration by one or more contextual misconfiguration rules to the identified traffic-related configuration parameter and the determined at least one traffic behavior (paragraphs 38-39 disclose monitoring network traffic for a traffic profile/behavior abnormality. The data extracted for the determination/evaluation include historical traffic data gathering means to provide at least one selected normal traffic parameter, observing means for observing the current traffic data relating to the selected parameter to provide at least one current traffic parameter, and evaluating means to evaluate a deviation between the normal traffic profile parameter and the current traffic profile parameter against a threshold to determine whether a traffic abnormality exists. The rule for detecting misconfiguration/abnormality is defined as the deviation between the normal traffic profile parameter and the current traffic profile parameter against a threshold. Paragraph 126 reveals each observation may have its own rules for classifying data ); wherein at least one contextual misconfiguration rule defines a respective misconfiguration as a combination of at least one traffic-related configuration parameter and at the least one determined traffic behavior (paragraphs 38-39 disclose the rule for detecting misconfiguration/abnormality is defined as the deviation between the normal traffic profile parameter (traffic-related configuration parameter ) and the current traffic profile parameter (the determined traffic profile/behavior) against a threshold. Paragraph 126 reveals each observation may have its own rules for classifying data).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Subbarayan’s traffic based deviation detection to incorporate Kapoor’s teachings of software agent detecting deviations such as misconfigurations from network diagnostic API in view of Brendel’ misconfiguration rules to overcome or alleviate problems in network security by providing a means to detect flood-style denial of service attacks and provide a product for network communication security that allows for the implementation of a scalable platform for the deployment of security services (paragraphs 13-14 of Brendel).
As to claim 12, the combination of Subbarayan in view of Kapoor and Brendel teaches wherein the system is further configured to: perform at least one mitigation action with respect to the computing interface based on the detected misconfiguration (Subbarayan: paragraph 54 discloses responsive to identification of deviations, the system categorizes the identified deviation within an appropriate category. Paragraph 108 discloses the controller may discard or reject transmission of communication/messages/traffic events that have been determined to be representative of an anomaly. Brendel: paragraphs 61 and 124-125 disclose when there is an abnormality triggering an alarm for further actions such as active filtering). Motivation similar to the motivation presented in claim 11.
As to claim 13, the combination of Subbarayan in view of Kapoor and Brendel teaches wherein each contextual misconfiguration rule is associated with at least one predetermined mitigation action (( Brendel: paragraphs 61 and 124-125 disclose when there is an abnormality triggering an alarm for further actions such as active filtering). Motivation similar to the motivation presented in claim 11.
As to claim 14, the combination of Subbarayan in view of Kapoor and Brendel teaches wherein the computing interface is a first computing interface (Subbarayan: paragraph 5 discloses first API), wherein the system is further configured to: manage a cybersecurity posture of an environment in which the first computing interface is deployed (paragraph 5 discloses generating a first anomaly detection model/posture based on parameter data extracted from traffic data corresponding to the first API) by creating an inventory of second computing interfaces used for communications in the environment based on the identified at least one configuration parameter and the determined at least one traffic behavior (Subbarayan: paragraph 106 discloses model is based on one or more data logs, API configurations extracted from API configuration database, and model dictionary database. Data log historian may comprise a database configured to store data logs relating to data messages and communication to and from APIs or API servers. API configuration databases may be configured for one or more APIs and additionally to store an association between each API configuration and a corresponding API. Paragraph 96 disclose for the model, the model include IP address/cookie/token/API key specific features (used to identify the source of the traffic) for each API. Paragraph 75 further describe model dictionary and the anomaly models are stored in the model dictionary), wherein the at least one misconfiguration is detected based further on the inventory (Subbarayan: paragraph 63 discloses the model or traffic parameter baselines corresponding to the anomaly detection model is used to identify deviation/misconfigurations. Paragraph 106 discloses model is based on one or more data logs, API configurations extracted from API configuration database, and model dictionary database. Data log historian may comprise a database configured to store data logs relating to data messages and communication to and from APIs or API servers. API configuration databases may be configured for one or more APIs and additionally to store an association between each API configuration and a corresponding API. Paragraph 96 disclose for the model, the model include IP address/cookie/token/API key specific features (used to identify the source of the traffic) for each API. Paragraph 75 further describe model dictionary).
As to claim 15, the combination of Subbarayan in view of Kapoor and Brendel teaches wherein the inventory indicates, for each of the first and second computing interfaces, at least one of: data types handled by the computing interface, whether the computing interface is Internet-facing, whether the computing interface enforces authentication, and whether the computing interface requires authentication (Subbarayan: paragraph 75 discloses the anomaly models are stored in the model dictionary and which is associated with the API type, API class or category or one or more API characteristics).
Claim(s)