DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 07/24/2025.
In the instant Amendment, claims 1, 6, 8-11, 16, and 18-19 have been amended; and claims 1, 10, and 11 are independent claims. Claims 1-19 have been examined and are pending. This Action is made Final.
Response to Arguments
The non-statutory obviousness type double patenting rejection to claims 1-19 is maintained as the Applicant has held the rejection in abeyance.
The rejection of claims 1-2, 7, 10-12, and 17 under 35 U.S.C. § 102(a)(1) is withdrawn as the claims have been amended.
Applicants’ arguments with respect to claims 1, 10, and 11 have been considered but are moot in view of the new ground(s) of rejection, which were necessitated by amendment.
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.
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 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.
Claim(s) 1-2, 7, 10-12, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Subbarayan et al. (US 2020/0304470; Hereinafter “Subbarayan”) in view of Schiappa et al. (US 10,965,711; Hereinafter “Schiappa”).
Regarding claim 1, Subbarayan teaches a method for traffic-based misconfiguration detection, comprising:
analyzing a first set of computing interface traffic data to identify types of data included among traffic to and from a computing interface (Subbarayan: Para. [0045], The process flow is initiated by parsing data from raw data logs 204 or from data packets corresponding to real-time API traffic that is being received, corresponding to data requests and data messages that have been forwarded to or received from one or more API servers or a server back end. Parsing of raw data logs 204 or data packets corresponding to real-time API traffic that is being received, comprises extracting data corresponding to a selected set of data parameters 208—which data parameters 208 are selected based on their relevance to identifying indicators of compromise corresponding to one or more APIs within a server backend.);
creating at least one computing interface schema based on the analysis, wherein the computing interface schema defines a plurality of schema fields and a plurality of corresponding schema values, wherein each schema value indicates a normal behavior for the computing interface with respect to the corresponding schema field (Subbarayan: Para. [0047], The data corresponding to data parameters 206 that has been extracted from data logs 206 or from data packets corresponding to real-time API traffic that is being received, is used to develop one or more anomaly detection models 208, which anomaly detection models may be implemented to process application layer traffic information and identify deviations from normal or baseline traffic patterns as threats/anomalies/attacks and/or indicators of compromise. Para. [0048], Para. [0051], In an embodiment, the selection of parameter data for extraction from the data logs or from data packets corresponding to real-time API traffic that is being received, may be dependent on API configuration information corresponding to the selected APL In an embodiment of the invention, generation of the anomaly detection model may include identification of one or more predefined traffic parameter baseline values that are representative of normal, expected or baseline traffic patterns in connection with the selected API or that are representative of network traffic that is compliant with one or more defined network security policies. In certain embodiments, an anomaly detection model may be generated based on and corresponding to a plurality of APIs. In one such embodiment, the generated anomaly detection model may be based on (i) API configuration information corresponding to each of the plurality of APIs and (ii) parameter data corresponding to each of the plurality of APIs that is extracted from data logs or from data packets corresponding to real-time API traffic that is being received, corresponding to the selected APL); and
identifying a misconfiguration of the computing interface based on the at least one computing interface schema and a second set of computing interface traffic data (Subbarayan: Para. [0053], Step 308 comprises identifying one or more deviations between extracted parameter data corresponding to the selected API and one or more predefined traffic parameter baseline values defined within the generated anomaly model. Para. [0054]).
Subbarayan does not explicitly teach wherein the computing interface schema is created without requiring analysis or explicit information of a configuration of the computing interface or any component that manages communications to the computing interface.
In an analogous art, Schiappa teaches wherein the computing interface schema is created without requiring analysis or explicit information of a configuration of the computing interface or any component that manages communications to the computing interface (Schiappa: Claim 17, wherein monitoring the behavior includes monitoring an application programming interface for a file system on the endpoint that manages the file and reporting actions taken on the data in the file by the one or more trusted processes, to collect a plurality of collected behaviors of the data stored in the file based on the monitoring of the one or more trusted processes executing on the endpoint, thereby forming a plurality of collected behaviors, to generate a baseline of known behaviors caused by the one or more trusted processes having a cryptographically verifiable identifier of trusted status based on the plurality of collected behaviors, the baseline of known behaviors including a history of normal or expected actions taken on the data in the file by the one or more trusted processes executing on the endpoint, to observe a specific behavior of the data with the application programming interface after processing the plurality of collected behaviors, to apply a rule in response to the specific behavior to detect a reportable event based on an inconsistency between the specific behavior and a behavior included in the baseline of known behaviors caused by the one or more trusted processes, and to transmit information to the threat management facility about the reportable event, the information including a description of the reportable event and the specific behavior. [monitoring of interface traffic data such as data transmitted to and from an API, as described in para. [0028] of the Applicant’s instant Specification]).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Schiappa with the system and method of Subbarayan to include wherein the computing interface schema is created without requiring analysis or explicit information of a configuration of the computing interface or any component that manages communications to the computing interface because this functionality provides network security techniques for tracking and processing behavior of data on endpoints to detect possible threats (Schiappa: Col. 1, Lines 17-20).
Regarding claim 2, Subbarayan, in combination with Schiappa, teaches the method of claim 1, further comprising: performing at least one mitigation action with respect to the computing interface based on the identified misconfiguration (Subbarayan: Para. [0054], Responsive to identification of one or more deviations at step 308, step 310 comprises categorizing the identified deviations within an appropriate event category. Examples of event categories may include normal traffic, abnormal traffic, threat, attack or indicator of compromise.).
Regarding claim 7, Subbarayan, in combination with Schiappa, teaches the method of claim 1, wherein the misconfiguration is identified based further on at least one predetermined kind of protected data for which additional precautions are required (Subbarayan: Para. [0068], The predefined traffic parameter baseline(s) for each API may in an embodiment be made to change according to configuration—and for example, could be configured to change every fraction of a second, minutes, hours, day of the week, etc. Para. [0069], In an embodiment, the invention may also implement user adjustable traffic parameter baseline or reference models—wherein the traffic parameter baseline calculated or learned or injected during configuration could be adjusted up or down by the user (e.g. IT administrator or operator) in order to match the user's risk profile. A user that wants fewer false positive or false negative outcomes would be able to supply for each API or server, a number which could be, but is not limited to, a percentage, an integer, a fraction etc. which would automatically be used to adjust/calculate up or down the traffic parameter baseline used to analyze the traffic for that API or server. As the traffic parameter baseline changes based on the time of the day, the day, the week, a holiday etc., the correct automatically adjusted traffic parameter baseline may be used to analyze traffic. Para. [0065]).
Regarding claim 10, Claim 10 is rejected under the same rational as claim 1.
Regarding claims 11-12, Claims 11-12 are rejected under the same rational as claims 1-2, respectively.
Regarding claim 17, Claim 17 is rejected under the same rational as claim 7.
Claim(s) 3, 6, 8, 13, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Subbarayan et al. (US 2020/0304470; Hereinafter “Subbarayan”) in view of Schiappa et al. (US 10,965,711; Hereinafter “Schiappa”) in view of Djosic et al. (US 2021/0152555; Hereinafter “Djosic”).
Regarding claim 3, Subbarayan, in combination with Schiappa, teaches the method of claim 1. Subbarayan does not explicitly teach wherein the at least one computing interface schema includes at least one request schema and at least one response schema.
In an analogous art, Djosic teaches wherein the at least one computing interface schema includes at least one request schema and at least one response schema (Djosic: Para. [0030], In addition the system creates user profiles and deploy a decision engine based on supervised learning and can improve the profiles and engine over the time. The goal of the holistic procedure is to significantly reduce false-positive responses—the responses when real user are asked for additional verifications or even prevented from entering the system, and to fully eliminate false-negative identification—the responses when a fake/fraudulent user that knows security credentials is allowed to enter the system. Para. [0041], If the user shows an unusual behavior pattern, the risk score will increase, which may result in blocking 264 access to some or all resources, and/or refusing to return information via APIs response. To access those resources again the user should pass an additional verification. Para. [0094], Two request types, registration and log-in are recognized. The attributes collected during registration are stored into a database and used as main reference. Para. [0073], Within the range, API traffic may be considered to be questionable. In such circumstances, the API traffic (or user or user device associate with the API traffic) may be flagged to be further monitored. Alternatively, API traffic with a risk value within the range may be subject to additional user authentication credential requests (e.g., passwords, further information to prove identity, etc.).).
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Djosic with the system and method of Subbarayan and Schiappa to include wherein the at least one computing interface schema includes at least one request schema and at least one response schema because this functionality provides high levels of API security and reduction of false positive and false negative responses (Djosic: Para. [0030]).
Regarding claim 6, Subbarayan, in combination with Schiappa, teaches the method of claim 1. Subbarayan does not explicitly teach wherein the plurality of schema fields for each computing interface schema includes at least one field having a predetermined optional marker indicating that the respective schema field is optionally included in any given request or response of traffic to and from the computing interface.
In an analogous art, Djosic teaches wherein the plurality of schema fields for the computing interface schema includes at least one field having a predetermined optional marker indicating that the respective schema field is optionally included in any given request or response of traffic to and from the computing interface (Djosic: Para. [0052], A traditional DE receives a risk score, examines which security options are available, and decides what action to take. For example, as shown in FIG. 3A, three risk scores RS.sub.α, RS.sub.β, RS.sub.γ are provided to the DE, where RS.sub.β, RS.sub.γ may be optional. The optional value will be set to 0 if it is not passed in. The DE trains a voting system to learn the weights for the three risk scores and calculates the final risk score. Para. [0054], The threshold controls actions that a DE may take, i.e., making an optional authentication step mandatory or vice versa. At each level, the DE will make the decision based on the risk score for that level. By progressing to the next level, the risk associated to previous level is inherited, so even if the user passes the previous level gate to the next level, the risk from previous level is taken into consideration.)
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Djosic with the system and method of Subbarayan and Schiappa to include wherein the plurality of schema fields for each computing interface schema includes at least one field having a predetermined optional marker indicating that the respective schema field is optionally included in any given request or response of traffic to and from the computing interface because this functionality provides for faster discovery of potential threats without using computing resources to verify a user’s credentials (Djosic: Para. [0039]).
Regarding claim 8, Subbarayan, in combination with Schiappa, teaches the method of claim 1. Subbarayan does not explicitly teach wherein the at least one computing interface schema includes a first schema value for a corresponding first schema field representing authentication status, wherein the identified misconfiguration is based on a combination of the first schema value for the at least one computing interface schema indicating a lack of required authentication and a portion of the second set of computing interface traffic data including one of the at least one predetermined kind of protected data.
In an analogous art, Djosic teaches wherein each of the at least one computing interface schema includes a first schema value for a corresponding first schema field representing authentication status (Djosic: Para. [0034], In some embodiments, the protection service may include an integrated a learning-based authentication features. If the credentials are correct, additional user related information is processed and a confidence score is generated. The score represents the correlation to the normal behavior of the given user, as learned from the training data. Based on the resulting score the system has one of three outputs: access is granted, access is denied, or further information is requested. Para. [0037]-[0038]), wherein the identified misconfiguration is based on a combination of the first schema value for one of the at least one computing interface schema indicating a lack of required authentication and a portion of the second set of computing interface traffic data including one of the at least one predetermined kind of protected data (Djosic: Para. [0040], If the user's risk score at level alpha 220 is below the threshold in the decision engine (DE) 242 for this stage, the user is permitted to input their personal information such as ID and password. The system protection service calculates the risk at the level beta in an incremental way, that is, the system utilizes the user's credentials together with the user's behavioral pattern like mouse movements and keyboard stokes 228 if existed and risk information calculated in the alpha stage to calculate risk score. If the score is higher than some threshold, the access is denied, otherwise the access is granted or additional information required, depending on the level of granularity of the risk score threshold. Para. [0042]-[0056])
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Djosic with the system and method of Subbarayan and Schiappa to include wherein each of the at least one computing interface schema includes a first schema value for a corresponding first schema field representing authentication status, wherein the identified misconfiguration is based on a combination of the first schema value for one of the at least one computing interface schema indicating a lack of required authentication and a portion of the second set of computing interface traffic data including one of the at least one predetermined kind of protected data because this functionality provides for faster discovery of potential threats without using computing resources to verify a user’s credentials (Djosic: Para. [0039]).
Regarding claim 13, Claim 13 is rejected under the same rational as claim 3.
Regarding claim 16, Claim 16 is rejected under the same rational as claim 6.
Regarding claim 18, Claim 18 is rejected under the same rational as claim 8.
Claim(s) 4-5 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Subbarayan et al. (US 2020/0304470; Hereinafter “Subbarayan”) in view of Schiappa et al. (US 10,965,711; Hereinafter “Schiappa”) in view of Varsanyi et al. (US 2014/0201838; Hereinafter “Varsanyi”).
Regarding claim 4, Subbarayan, in combination with Schiappa, teaches the method of claim 1. Subbarayan does not explicitly teach wherein at least one of the first set of computing interface traffic data and the second set of computing interface traffic data includes duplicated traffic.
In an analogous art, Varsanyi teaches wherein at least one of the first set of computing interface traffic data and the second set of computing interface traffic data includes duplicated traffic (Varsanyi: Para. [0063], Both the request and the response may comprise one or more packets transmitted between the devices. The packet-level flow between the request and response may overlap temporally (from the perspective of either device or a network-mirroring device) and/or may be collected from multiple points within the network architecture. In an embodiment, multiple network sessions between communicating network agents may generate packets that interleave arbitrarily without affecting operation of the disclosed systems and methods. Para. [0082], A copy or mirror of the traffic sent between network agents 102 and 103, which comprises network packets, may be received from network switch 101 via interface 106 (e.g., 1000BASE-T link) by a network interface controller (NIC) 201.) .
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Varsanyi with the system and method of Subbarayan and Schiappa to include wherein at least one of the first set of computing interface traffic data and the second set of computing interface traffic data includes duplicated traffic because this functionality provides improved performance and mitigation against various attacks (Varsanyi: Para. [0065]).
Regarding claim 5, Subbarayan, in combination with Schiappa and Varsanyi, teaches the method of claim 4, wherein the duplicated traffic is created based on data extracted from a communications session by building at least one of a plurality of communication layers based on data extracted from other layers of the plurality of communication protocol layers (Varsanyi: Para. [0064], According to an embodiment, the systems and methods extract a model or description of semantic operations performed between two network agents from an imperfect copy of the network packet traffic exchanges between the network agents. This model may include, without limitation, raw performance data on each operation, descriptive metadata (e.g., query string, data types, data sizes, etc.), and/or actual data. When traffic is missing, out of order, or the exact specification of the traffic is unknown, a partial model of operations may still be generated and used at an application-layer level, and the framework of a session may be resynchronized based on a change in direction of data flow (e.g., between request and response messages). Para. [0063]).
Regarding claims 14-15, Claims 14-15 are rejected under the same rational as claims 4-5, respectively.
Claim(s) 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Subbarayan et al. (US 2020/0304470; Hereinafter “Subbarayan”) in view of Schiappa et al. (US 10,965,711; Hereinafter “Schiappa”) in view of Natarajan et al. (US 2013/0259037; Hereinafter “Natarajan”).
Regarding claim 9, Subbarayan, in combination with Schiappa, teaches the method of claim 1. Subbarayan does not explicitly teach further comprising: duplicating traffic to and from the computing interface, wherein duplicating the traffic includes extracting data from a plurality of communication protocol layers used for communications with the computing interface, wherein the first set of computing interface traffic data includes the duplicated traffic.
In an analogous art, Natarajan teaches duplicating traffic to and from the computing interface, wherein duplicating the traffic includes extracting data from a plurality of communication protocol layers used for communications with the computing interface, wherein the first set of computing interface traffic data includes the duplicated traffic (Natarajan: Para. [0035], Moreover, while network device 200, as shown, is a layer 2 device, it is understood that embodiments may be practiced on many different types of devices, e.g., a layer 2/3 device. Para. [0042], As depicted, network traffic 301 is passed through port 310 to port 320, for delivery to its intended destination. Meanwhile, port 310 creates duplicate network traffic 311, and passes duplicate network traffic 311 to port 330, e.g., for monitoring purposes.)
It would have been obvious to a person having ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teachings of Natarajan with the system and method of Subbarayan and Schiappa to include duplicating traffic to and from a computing interface, wherein duplicating the traffic includes extracting data from a plurality of communication protocol layers used for communications with the computing interface, wherein the first set of computing interface traffic data includes the duplicated traffic because this functionality provides for duplicating and monitoring traffic from a plurality of communication protocol layers (Natarajan: Para. [0002]).
Regarding claim 19, Claim 19 is rejected under the same rational as claim 9.
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Nelson Giddins whose telephone number is (571)272-7993. The examiner can normally be reached on Monday - Friday, 9:00 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Linglan Edwards can be reached at (571) 270-5440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NELSON S. GIDDINS/ Primary Examiner, Art Unit 2408