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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 05/27/2026 has been entered.
Claims 1 and 11 are independent claims. The applicant has amended claims 1 and 11. Claims 1-20 have been examined and are pending. This Action is made Non-FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 05/27/2026, with respect to limitations listed below, have been fully considered but they are not persuasive. Applicant’s arguments with respect to claim(s) 1 and 11 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The Examiner respectfully suggests that the claim be further amended; details in the specification be incorporated, to distinguish the claimed invention over prior art of record. Should the Applicant desire an interview to further clarify the claim interpretation/rejections, please contact the Examiner at (571) 272-1531 to schedule an interview.
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.
Claims 1-8 and 10-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Vaidheeswarra (EP 1,494,426 B1), in view of Guo (US 2021/0306373 A1), and further in view of Kruegel (N.P.L. Anomaly Detection of Web-based Attacks).
Regarding Claim 1
Vaidheeswarra discloses:
A method comprising:
receiving packets in a data center that are in transit to an application programming interface (API) endpoint of an application (Vaidheeswarran ¶0207: a client session's virtual service is a mapping of the virtual IP destination, protocol and port number; ¶0017: the network communication unit can be operatively connected to the Internet and to at least one HTTP server via a private network path.);
parsing, by a hardware accelerator in the data center at line rate, an HTTP request from the packets to identify keys or values in content of the HTTP request (Vaidheeswarran ¶0017: the programmable parser can include dedicated, function-specific parsing hardware and can include an HTTP parser; ¶0202: the DLE performs parsing of key fields from streams; ¶0206: within selected HTTP headers, the DLE parses nested list elements and name-value pairs in search of programmed names, the parser extracts (delineates and validates) values of interest; ¶0209: the DLE parses the byte-range at full speed; ¶0238: each of two parsing subsystems scans headers and recognizes keywords at one byte per two cycles);
selecting, by the hardware accelerator, a disparity model associated with the API endpoint (Vaidheeswarran ¶0207: symbol tables for field extraction and the policy rules and patterns are loaded from off-chip tables per virtual service; ¶0214: each of a subscriber's parsing entity handles can select different off-chip tables to drive the parsing and policy evaluation stages; ¶0203: a policy evaluation index points to a series of pointers used to control the parsing and lookup engines);
dropping at least one packet based on identification of the malicious content in the content (Vaidheeswarran ¶0082: an object rule is a set of one or more text expressions that compare object data and configuration data to determine a match and a resulting action; ¶0083: the result of the comparison is either true (matches) or false (does not match); ¶0084: if the switch cannot determine a match, or if there are no remaining rules, the switch drops the request; ¶0088: if a service group has no object rule associated, a reset is sent back to the client).
Vaidheeswarran teaches hardware parsing of HTTP content to identify keys and values, hardware selection of a per-endpoint analysis configuration, and a hardware mechanism for dropping a request that fails to satisfy a configured policy predicate. However, Vaidheeswarran does not disclose comparing content characteristics of the packets against a disparity model comprising a length model and a character model, nor computing a length score and a character-distribution score for identified keys or values. Guo discloses a hardware acceleration sub-system implemented within a NIC in a data center, wherein hardware accelerator devices offload computationally intense processing tasks from a general purpose processor to perform certain functions faster and more efficiently and to decrease latency and increase throughput (Guo ¶0018), and wherein detection and mitigation may be performed on behalf of a host within the data center without using resources of a CPU (Guo ¶0032, 0041). Guo further discloses that when a threshold associated with a request is exceeded, a mitigation action is triggered rather than allowing the request to pass through unmitigated (Guo ¶0054). It would have been obvious to one of ordinary skill in the art to implement Vaidheeswarran's hardware HTTP parsing and per-endpoint policy selection within Guo's datacenter hardware acceleration subsystem in order to offload the compute intensive HTTP processing workload from the host CPU while operating at the line rate of the network, a predictable result of combining a known parsing/selection architecture with a known hardware acceleration deployment context taught for that same purpose.
Kruegel teaches comparing content characteristics of HTTP request parameters against a disparity model comprising a length model and a character model. Kruegel discloses an attribute length model that learns a statistical distribution of parameter lengths during a training phase and, during detection, computes a probability value p(l) for an observed length l via the Chebyshev inequality, p(l) = σ²/(l−μ)² (Kruegel §4.1, §4.1.2). Kruegel further teaches an attribute character distribution model that learns a character frequency distribution during training and, during detection, computes a probability value via a χ² goodness-of-fit test between the observed character distribution and the idealized character distribution (Kruegel §4.2, §4.2.2). Kruegel teaches that the query string of an HTTP request consists of an ordered list of parameters (or attributes) with their corresponding values, and that both models are applied to these query attributes (Kruegel §3). Kruegel further teaches that a query attribute is marked as an attack when its computed anomaly score exceeds a detection threshold established during training (Kruegel §4, Equation 1 discussion). It would have been obvious to incorporate Kruegel's length model and character model into the combined Vaidheeswarran/Guo hardware architecture to compute a length score and character distribution score for the keys or values identified by Vaidheeswarran's hardware parser and to configure Vaidheeswarran's predicate drop mechanism with Kruegel's computed score exceeding a threshold as the triggering condition. The claim is obvious because a POSITA can combine known methods to produce predictable results: substituting Kruegel's scoring technique for Vaidheeswarran's grammar validation predicate, within Guo's hardware accelerated datacenter architecture, yields the predictable result of hardware per endpoint malicious content detection and dropping.
Regarding Claim 2
Vaidheeswarran, Guo, and Kruegel teach the method of claim 1. Vaidheeswarran further discloses the hardware accelerator analyzes the content in each packet and filters the at least one packet at line rate node (Vaidheeswarran ¶0209: the DLE parses the byte-range at full speed to locate and validate selected fields; ¶0238: each of two parsing subsystems scans headers and recognizes keywords at one byte per two cycles; ¶0084: if the switch cannot determine a match, or if there are no remaining rules, the switch drops the request). Guo further discloses hardware acceleration to decrease latency and increase throughput at line rate (Guo ¶0018). Kruegel further discloses that an anomaly score is calculated for each query and its attributes, and when the score exceeds the detection threshold, the whole query is marked as anomalous (Kruegel §4).
The claim is obvious because a POSITA can combine known methods to produce predictable results: Vaidheeswarran's hardware accelerated parsing and filtering, Guo's hardware accelerated line-rate throughput, and Kruegel's threshold malicious determination are each known techniques that, combined per claim 1's rationale, yield the predictable result of the hardware accelerator analyzing and filtering packets at line-rate.
Regarding Claim 3
Vaidheeswarran teaches parsing HTTP content by a hardware accelerator to identify keys or values, and Guo teaches hardware accelerated line-rate processing in a data center environment. However, Vaidheeswarran and Guo do not disclose the following limitation: "wherein the content comprises query parameters of the HTTP request or structured content of the HTTP request." Kruegel teaches that the analyzed HTTP request content comprises query parameters of the HTTP request. Specifically, Kruegel discloses analyzing HTTP GET requests that include a query string, wherein the query string "consists of an ordered list of n pairs of parameters (or attributes) with their corresponding values," and that anomaly detection models operate on these query parameters and their values (Kruegel §3-4). Kruegel further teaches analyzing query attributes using multiple models, including an attribute length model and an attribute character distribution model, thereby treating query parameters as structured content of the HTTP request (Kruegel §4.1-4.2). Vaidheeswarran further teaches that structured content of the HTTP request may be analyzed, disclosing that the DLE may extract the XML DOCTYPE and certain attribute values from XML elements within a message body identified by the HTTP headers (Vaidheeswarran ¶0208).
It would have been obvious to one of ordinary skill in the art to analyze query parameters and structured content of HTTP requests, as taught by Kruegel, within the combined Vaidheeswarran and Guo hardware accelerated line-rate packet inspection architecture in order to improve the accuracy of malicious HTTP request detection while maintaining line-rate performance in a data center environment. A POSITA would have been motivated to incorporate Kruegel's well known query parameter HTTP analysis techniques into Vaidheeswarran's hardware parsing framework implemented within Guo's hardware accelerated packet inspection architecture, yielding the predictable result of efficiently detecting malicious behavior in structured HTTP request content, including query parameters.
Regarding Claim 4
Vaidheeswarran teaches parsing HTTP content by a hardware accelerator to identify keys or values, and Guo teaches hardware-accelerated line-rate processing in a data center environment. However, Vaidheeswarran and Guo do not disclose the following limitation: "comparing, by a hardware accelerator in the data center, a length of the content to a disparity model that corresponds to a confidence of malicious HTTP request." Kruegel teaches comparing a length of HTTP request content to a learned model of normal behavior to determine whether the request is malicious. Specifically, Kruegel discloses an attribute length model that computes statistical parameters of normal query parameter lengths during training and, during detection, compares an observed parameter length against the model to calculate a probability value, where low probability values indicate anomalous or malicious requests (Kruegel §4, §4.1.2). Kruegel further teaches deriving an anomaly score from the probability value that reflects a confidence of maliciousness (Kruegel §4, Equation 1 discussion).
It would have been obvious to one of ordinary skill in the art to implement Kruegel's length based disparity modeling technique within the combined Vaidheeswarran and Guo hardware accelerated, line-rate packet inspection architecture, in order to quantify confidence of malicious HTTP requests while maintaining line-rate processing. The combination yields the predictable result of efficiently detecting malicious HTTP requests based on statistically significant length deviations.
Regarding Claim 5
Vaidheeswarran teaches parsing HTTP content by a hardware accelerator to identify keys or values, and Guo teaches hardware accelerated line-rate processing in a data center environment. However, Vaidheeswarran and Guo do not disclose the following limitation: "wherein the analyzing the content comprises: comparing, by the hardware accelerator in the data center, values in the content to a disparity model that corresponds to a confidence of malicious HTTP request." Kruegel teaches comparing values in HTTP request content to a disparity model that yields a confidence of maliciousness. Specifically, Kruegel discloses analyzing HTTP query parameters comprising parameter value pairs and applying multiple anomaly detection models that compare observed values against learned profiles of normal behavior (Kruegel §3-4). Kruegel further teaches assigning probability values to query attributes based on deviations from learned models, and determining maliciousness when the probability indicates anomalous behavior, thereby providing a confidence of malicious HTTP request (Kruegel §4).
It would have been obvious to one of ordinary skill in the art to implement Kruegel's value disparity modeling techniques within the combined Vaidheeswarran and Guo hardware accelerated line-rate datacenter architecture, in order to quantify confidence of malicious HTTP requests while maintaining line-rate processing.
Regarding Claim 6
Vaidheeswarran teaches parsing HTTP content by a hardware accelerator to identify keys or values, and Guo teaches hardware-accelerated line-rate processing in a data center environment. However, Vaidheeswarran and Guo do not disclose the following limitation: "wherein the character model identifies the malicious content based on a distribution of characters in the values." Kruegel teaches a character model that identifies malicious content based on a distribution of characters in values of HTTP request content. Specifically, Kruegel discloses an attribute character distribution model that analyzes the distribution of characters within query parameter values, compares the observed character frequency distribution against an idealized character distribution learned during training, and assigns a probability indicating whether the value is anomalous or malicious (Kruegel §4.2). Kruegel further teaches that deviations in the character distribution of parameter values indicate malicious input, and that such deviations are used to identify malicious HTTP requests (Kruegel §4.2.2).
It would have been obvious to one of ordinary skill in the art to implement Kruegel's character distribution malicious content identification within the combined Vaidheeswarran and Guo hardware accelerated line-rate datacenter architecture, in order to improve detection accuracy of malicious HTTP requests while maintaining line-rate performance. The combination yields the predictable result of identifying malicious content based on character distribution using a hardware accelerator in a data center.
Regarding Claim 7
Vaidheeswarran teaches parsing HTTP content by a hardware accelerator to identify keys or values, and Guo teaches hardware-accelerated line-rate processing in a data center environment. However, Vaidheeswarran and Guo do not disclose the following limitation: "wherein the length model identifies the malicious content based on a length of a value and a distribution of the length of the value." Kruegel teaches a length model that identifies malicious content based on both a length of a value and a distribution of the length of the value. Specifically, Kruegel discloses an attribute length model that learns a statistical distribution of normal query parameter lengths by calculating a mean and variance during training, and during detection compares an observed parameter length against the learned distribution to determine whether the value is anomalous or malicious (Kruegel §4.1, §4.1.1, §4.1.2). Kruegel further teaches that significant deviations in parameter length from the learned distribution indicate malicious input (Kruegel §4.1.2).
It would have been obvious to one of ordinary skill in the art to implement Kruegel's length distribution malicious content identification within the combined Vaidheeswarran and Guo hardware accelerated line-rate datacenter architecture in order to identify malicious HTTP content based on abnormal value lengths while maintaining high throughput. The combination yields the predictable result of efficiently detecting malicious HTTP requests by comparing value lengths against a learned length distribution using a hardware accelerator in a data center.
Regarding Claim 8
Vaidheeswarran, Guo, and Kruegel teach parsing HTTP content by a hardware accelerator, hardware-accelerated line-rate processing in a data center, and comparing content characteristics against a disparity model comprising a length model and a character model. Kruegel further discloses "converting, by the hardware accelerator in the data center, characters of keys or values into numeric values and generating a numeric distribution associated with the characters." Specifically, Kruegel discloses converting the characters of a query attribute value into their corresponding ASCII (numeric) values, and generating a character distribution representing the sorted, relative frequencies of those numeric values (Kruegel §4.2, e.g., the parameter string "passwd" is converted to ASCII values "112 97 115 115 119 100," from which an absolute and then relative frequency distribution is derived). Kruegel further teaches that this numeric distribution is compared against an idealized character distribution learned during training to identify malicious content (Kruegel §4.2.1-4.2.2).
It would have been obvious to one of ordinary skill in the art to implement Kruegel's character to numeric value conversion and numeric distribution generation within the combined Vaidheeswarran and Guo hardware accelerated line-rate data-center architecture in order to detect malicious content based on statistical deviations in the numeric character distribution while maintaining line-rate performance.
Regarding Claim 10
Vaidheeswarra discoloses:
The method of claim 1, further comprising: decrypting, by the hardware accelerator in the data center, each packet based on a transportation layer security (TLS) protocol (Vaidheeswarran ¶0260: the SSL Record Processor (SRP) provides SSL acceleration functionality that allows OAS implementations to operate on SSL encrypted data at rates that are comparable to those for unencrypted implementations; ¶0263: the SRP acts as an interface between elements of the complex and a bulk cryptographic engine that handles the encryption and decryption of SSL records; ¶0269: the Receive Decrypted Data Stream is used for application data that is decrypted by the cryptographic engine; ¶0049: the SRP is integrated into one of a series of individual chips in a chip complex that can be implemented as a FPGA or an ASIC).
Regarding Claim 11
Claim 11 is directed to an apparatus corresponding to the computer-implemented method in claim 1. Claim 11 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 12
Claim 12 is directed to an apparatus corresponding to the computer-implemented method in claim 2. Claim 12 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 13
Claim 13 is directed to an apparatus corresponding to the computer-implemented method in claim 3. Claim 13 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 14
Claim 14 is directed to an apparatus corresponding to the computer-implemented method in claim 4. Claim 14 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding Claim 15
Claim 15 is directed to an apparatus corresponding to the computer-implemented method in claim 5. Claim 15 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding Claim 16
Claim 16 is directed to an apparatus corresponding to the computer-implemented method in claim 6. Claim 16 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding Claim 17
Claim 17 is directed to an apparatus corresponding to the computer-implemented method in claim 7. Claim 17 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 18
Claim 18 is directed to an apparatus corresponding to the computer-implemented method in claim 8. Claim 18 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Regarding Claim 20
Claim 20 is directed to an apparatus corresponding to the computer-implemented method in claim 10. Claim 20 is similar in scope to claim 10 and is therefore rejected under similar rationale.
Claims 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over by Vaidheeswarra (EP 1,494,426 B1), in view of Guo (US 2021/0306373 A1), in view of Kruegel (N.P.L. Anomaly Detection of Web-based Attacks) as applied to claims 5 and 15 above, and in further view of Garyani (US 20230107335 A1).
Regarding Claim 9
Vaidheeswarran, Guo, and Kruegel together teach a hardware accelerator that parses HTTP content at line rate to identify or values, selects a per-endpoint disparity model, computes length and character distribution scores against that model and drops packets identified as malicious based on those scores. However, they do not disclose the following limitation “determining the disparity model associated with the API endpoint at a destination address based on anonymized data, wherein the anonymized data comprises information for a plurality of cloud providers”
However, in an analogous art, Garyani discloses a cloud computing system/method that includes:
The method of claim 5, further comprising:
determining the disparity model associated with the API endpoint at a destination address based on anonymized data, wherein the anonymized data comprises information for a plurality of cloud providers (Garyani ¶108-113, 142, 347: teach determining a disparity model based on shared activity data across cloud tenants and other service provider customers. The shared activity data is anonymized using hashing mechanisms and is collected from multiple tenants and multiple cloud providers. The detection system identifies campaign-level attacks across distinct customer environments, including across service providers, and operates on structured activity data suitable for API-level modeling. This teaches determining a disparity model at a cloud-based API endpoint using anonymized data collected across multiple cloud providers.).
Given the teachings of Garyani, a person having ordinary skill in the art before the effective filing date of the claimed invention would have found it obvious to modify the teachings of Vaidheeswarran, Guo, and Kruegel by determining a disparity model associated with an API endpoint based on anonymized data collected from multiple cloud providers. Garyani teaches detecting cyberattack campaigns by analyzing shared activity across multiple cloud tenants and other service provider customers, where anomalousness is computed using statistical models such as hypergeometric probability and deterministic frequency rules. Garyani further teaches maintaining tenant privacy through data hashing and contractual agreements that govern the inclusion of specific data types, thereby enabling privacy preserving anomaly detection across organizational boundaries. As such, it would have been obvious to apply Garyani cross-tenant shared activity analysis in order to build a disparity model at a destination API endpoint, using anonymized data from multiple cloud providers to identify suspicious deviations from normal behavior (Garyani ¶108-113, 142, 347).
Regarding Claim 19
Claim 19 is directed to an apparatus corresponding to the computer-implemented method in claim 9. Claim 19 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 9:30am - 5:30pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. 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.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights