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 .
DETAILED ACTION
The instant application having Application No. 18/616,644 is presented for examination by the examiner. Claims 1-7, 10-12 and 14-17 are amended. Claims 1-20 have been examined.
Response to Arguments
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.
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-7, and 11-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over O'Hara (US 2021/0360023 A1), in view of Xaypanya (US 20140215621 A1) and further in view of Kruegel (N.P.L Anomaly Detection of Web-based Attacks).
Regarding Claim 1
O'Hara discloses:
A method comprising:
receiving packets in a data center that are in transit to an application programming interface (API) endpoint of an application (O'Hara ¶21–24, 26, 30: Teaches receiving HTTP packets by a network monitoring device deployed inline at the edge of a protected enterprise network (200), which functions as a data center. These packets originate from external host devices attempting to connect to protected internal devices via (APIs). Specifically, trusted client devices are described as sending large API requests, and the network monitor receives and evaluates these connection requests for potential DoS activity.);
dropping at least one packet based on identification of the malicious content in the content (O'Hara ¶33, 37: describes detecting malicious content within HTTP connection requests and then dropping the packet as a mitigation action.).
O'Hara teaches detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. However, O'Hara does not disclose that the HTTP request content analysis is performed by a hardware accelerator at line rate. Xaypanya teaches a packet inspection architecture implemented on high performance hardware including FPGA and ASIC based NIC cards integrated with GPU/ASIX processing blades for deep packet inspection (DPI) of incoming packets (¶167-172 and ¶184-185). Xaypanya discloses line-rate packet capture and inspection using FPGA NICs, enabling real-time malicious packet detection without network delay (¶172 and ¶184-185). Xaypanya further teaches analyzing packet content for malware characteristic using hardware accelerated processing in a data center HPC environment.
It would have been obvious to one of ordinary skill in the art to implement O’Hara’s HTTP layer 7 malicious request analysis using Xaypanya’s hardware accelerated line rate packed inspection architecture in order to reduce latency and enable high-speed detection and mitigation of malicious HTTP requests in a data center environment. Such modification would merely invoke applying O’Hara’s HTTP evaluation logic within Xaypanya’s known hardware accelerated DPI platform to achieve predictable results of improved performance and scalability for application layer attack detection.
O'Hara teaches detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. Xaypanya further teaches implementing packet inspection using hardware accelerators capable of DPI at line rate in a data center environment. However, O’Hara and Xaypanya do not disclose that the hardware accelerator compare content characteristics of the packet against a disparity model comprising a length model and a character model. Kruegel teaches comparing content characteristics of HTTP requests against a disparity model comprising a length model and a character model. Kruegel discloses an anomaly detection system that models normal behavior of HTTP request parameters and detects deviations indicative of malicious activity. In particular, Kruegel teaches an attribute length model that learns a statistical distribution of parameter lengths during a training phase and assigns a probability to observed parameter lengths during detection based on deviation from the learned distribution (Section 4.1 Attribute Length). Kruegel further teaches an attribute character distribution model that captures a learned character frequency distribution of request parameter values and compares observed character distributions against an idealized character distribution using statistical goodness-of-fit testing (Section 4.2). Thus, Kruegel teaches comparing content characteristics of HTTP request payloads against a disparity model that explicitly comprises both a length model and a character model, where anomalous deviations from learned distributions indicate malicious requests.
It would have been obvious to incorporate Kruegel’s known statistical length and character disparity models into the combined O’Hara and Tommy system in order to improve the accuracy of malicious application-layer traffic detection. O’Hara teaches analyzing HTTP request content and performing mitigation actions such as dropping malicious requests, while Tommy teaches performing deep packet inspection using hardware accelerated FPGA/ASIC architectures capable of line-rate processing in a data-center environment. A person of ordinary skill in the art would have been motivated to implement Kruegel’s proven statistical disparity models within Tommy’s hardware-accelerated packet inspection architecture to achieve the predictable result of high-speed, line-rate comparison of HTTP content characteristics against learned length and character distributions without introducing processing bottlenecks.
Regarding Claim 2
O'Hara teaches detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. Kruegel teaches comparing content characteristics of HTTP request payloads against a disparity model that explicitly comprises both a length model and a character model, where anomalous deviations from learned distributions indicate malicious requests. However, O'Hara and Kruegel do not disclose wherein a hardware accelerator of a cloud data center analyzes the content in each packet and filters the at least one packet at line rate node. Xaypanya teaches a packet inspection architecture implemented on high-performance hardware including FPGA and ASIC based NIC cards integrated with GPU/ASIX processing blades for deep packet inspection (DPI) of incoming packets (¶167-172 and ¶184-185). Xaypanya discloses line-rate packet capture and inspection using FPGA NICs, enabling real-time malicious packet detection without network delay (¶172 and ¶184-185). Xaypanya further teaches analyzing packet content for malware characteristic using hardware accelerated processing in a data center HPC environment.
It would have been obvious to one of ordinary skill in the art to implement O’Hara’s HTTP layer 7 malicious request analysis and Kruegel’s HTTP content modeling using Xaypanya’s hardware accelerated line rate packed inspection architecture in order to reduce latency and enable high-speed detection and mitigation of malicious HTTP requests in a data center environment. Such modification would merely invoke applying O’Hara’s HTTP evaluation logic and Kruegel’s HTTP content modeling within Xaypanya’s known hardware accelerated DPI platform to achieve predictable results of improved performance and scalability for application layer attack detection.
Regarding Claim 3
O'Hara teaches detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. Xaypanya further teaches implementing packet inspection using hardware accelerators capable of DPI at line rate in a data center environment. However, O’Hara and Xaypanya 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 (Sections 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.
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 O’Hara and Tommy (hardware accelerated line rate packed inspection architecture) system, in order to improve the accuracy of malicious HTTP request detection while maintaining line-rate performance in a data center environment. A person of ordinary skill in the art would have been motivated to incorporate Kruegel’s well known query parameter HTTP analysis techniques into O’Hara’s application layer detection framework implemented using Tommy’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
O'Hara teaches detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. Xaypanya further teaches implementing packet inspection using hardware accelerators capable of DPI at line rate in a data center environment. However, O’Hara and Xaypanya 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, Sections 4). Kruegel further teaches deriving an anomaly score from the probability value that reflects a confidence of maliciousness.
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 system of O’Hara and Tommy (hardware accelerated line rate packed 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 4
O'Hara teaches detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. Xaypanya further teaches implementing packet inspection using hardware accelerators capable of DPI at line rate in a data center environment. However, O’Hara and Xaypanya do not disclose the following limitation “wherein the analyzing the content comprises: comparing, by the-a hardware accelerator in the data center, a length of the content to the 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, Sections 4). Kruegel further teaches deriving an anomaly score from the probability value that reflects a confidence of maliciousness.
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 system of O’Hara and Tommy (hardware accelerated line rate packed 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
O'Hara teaches detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. Xaypanya further teaches implementing packet inspection using hardware accelerators capable of DPI at line rate in a data center environment. However, O’Hara and Xaypanya do not disclose the following limitation “wherein the analyzing the content comprises: comparing, 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 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 (Sections 4).
It would have been obvious to one of ordinary skill in the art to implement Kruegel’s value-based disparity modeling techniques within O’Hara’s application-layer HTTP request analysis system as implemented using Tommy’s hardware-accelerated data-center architecture, in order to quantify confidence of malicious in HTTP requests.
Regarding Claim 6
O'Hara teaches detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. Xaypanya further teaches implementing packet inspection using hardware accelerators capable of DPI at line rate in a data center environment. However, O’Hara and Xaypanya 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, Section 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.
It would have been obvious to one of ordinary skill in the art to implement Kruegel’s character distribution based malicious content identification within O’Hara’s application layer HTTP analysis system as implemented using Tommy’s hardware accelerated data center 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
O'Hara teaches detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. Xaypanya further teaches implementing packet inspection using hardware accelerators capable of DPI at line rate in a data center environment. However, O’Hara and Xaypanya 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 (Sections 4). Kruegel further teaches that significant deviations in parameter length from the learned distribution indicate malicious input.
It would have been obvious to one of ordinary skill in the art to implement Kruegel’s length distribution based malicious content identification within O’Hara’s application layer HTTP request analysis system as implemented using Tommy’s hardware accelerated data center architecture, in order to identify malicious HTTP content based on abnormal value lengths while maintaining high throughput line-rate processing. 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 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.
Claims 8 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over O'Hara (US 2021/0360023 A1), in view of Xaypanya (US 20140215621 A1), in view of Kruegel (N.P.L Anomaly Detection of Web-based Attacks) as applied to claim 5 above, and in further view of Ben-Itzhak (US 2008/0276320 A1).
Regarding Claim 8
O'Hara, Xaypanya and Kruegel teach detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. However, they do not disclose the following limitation “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”
However, in an analogous art, Ben-Itzhak discloses a numeric distribution system/method that includes:
The method of claim 5, further comprising:
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 (Ben-Itzhak ¶ 16-17, 20, 30, 42: teaches converting file content, including characters, into numeric byte values (0–255) and generating a histogram (numeric distribution) of their frequencies for analysis. This histogram is then used to detect deviations from expected distributions, effectively identifying potentially malicious content based on the statistical distribution of numeric values derived from characters.).
Given the teachings of Ben-Itzhak, 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 O'Hara, Xaypanya (hardware accelerator in the data center) and Kruegel by converting characters of values into numeric byte values and generating a numeric distribution associated with those values to identify potentially malicious content. Ben-Itzhak teaches converting file content into byte values (0–255) and generating a histogram (i.e., a numeric distribution) that captures the frequency of each byte in the file, with the intent of distinguishing malicious from legitimate content based on deviations in byte frequency patterns. It would have been obvious to integrate a byte-distribution modeling technique to improve detection accuracy, since histogram-based analysis of byte values is a well-known technique for identifying obfuscated or malformed content (Ben-Itzhak ¶ 16-17, 20, 30, 42).
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.
Claims 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over by O'Hara (US 2021/0360023 A1), in view of Xaypanya (US 20140215621 A1), in view of Kruegel (N.P.L Anomaly Detection of Web-based Attacks) as applied to claim 5 above, and in further view of Garyani (US20230107335A1).
Regarding Claim 9
O'Hara, Xaypanya and Kruegel teach detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. 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 O'Hara, Xaypanya (hardware accelerator in the data center) 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.
Claims 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over by O'Hara (US 2021/0360023 A1), in view of Xaypanya (US 20140215621 A1), in view of Kruegel (N.P.L Anomaly Detection of Web-based Attacks) as applied to claim 1 above, and in further view of Kittur (US 2021/0243169 A1).
Regarding Claim 10
O'Hara, Xaypanya and Kruegel teach detecting and mitigating malicious HTTP API requests by analyzing incoming packets at a data center edge device and dropping those identified as malicious. However, O’Hara, Xaypanya and Kruegel do not disclose the following limitation “decrypting, by a hardware accelerator in the data center, each packet based on a transportation layer security (TLS) protocol”
However, in an analogous art, Kittur discloses a hardware accelerator system/method that includes:
The method of claim 1, further comprising:
decrypting, by a hardware accelerator in the data center, each packet based on a transportation layer security (TLS) protocol (Kittur ¶9-10 and 14-15: describes offloading the entire TLS datapath into hardware within a programmable IO subsystem (SmartNIC), which is deployed in cloud data center servers. The system decrypts packets at wire speed via a cryptographic offload subsystem. TLS handshakes and session establishment are handled entirely in hardware, and decrypted packets are provided in plaintext to the host system.).
Given the teachings of the Kittur, 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 O’Hara, Xaypanya (hardware accelerator in the data center) and Kruegel to include functionality for decrypting packets using a TLS protocol in hardware. Kittur describes a programmable IO device (e.g., SmartNIC) that offloads TLS session establishment and record decryption to a cryptographic subsystem integrated into the data path. This allows packets encrypted via TLS to be decrypted inline at wire speed before further processing. Thus, it would have been obvious to incorporate TLS-based decryption into the data center’s hardware accelerator to enable efficient, secure processing of encrypted traffic without burdening the host CPU (Kittur ¶9, ¶10, ¶15).
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.
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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 8:30am - 5:00pm, 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
/SARAH SU/Primary Examiner, Art Unit 2431