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
Claims 1, 3-6, 9-11, 14, 17, 20-24, 26, 27, 29, 32-34, 37, 38, 40, 41, and 43-45 are amended
Claims 1-45 are pending
Priority
This application claims the benefit of U.S. Provisional Application No. 63/477,522 filed on Dec. 28, 2022. Therefore, the effective filing date of this application is 12/28/2022.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 12/02/2025 and 05/12/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Response to Arguments
Applicant’s arguments filed on 03/03/2026 have been fully considered.
With respect to the claim objections. The objections have been overcome due to Applicant’s amendments.
With respect to Applicants arguments regarding USC 112(f) claim interpretation. Applicant has argued that the term “Alpha filter” is a known structural term. Examiner respectfully disagrees. An Alpha filter is not a known structural term in the art and can be implemented through software. Examiner suggests incorporating features of the processing circuitry of claim 24 implementing the Alpha filter to show a clear hardware structure that implements the Alpha filter to overcome the USC 112(f) claim interpretation.
With respect to the USC 112(b) rejection for claims 3, 6, 26, 29, 9-13, 17, 18, 32-36, 38-41. The rejection has been overcome for claims 6, 29, 9-13, 17, 18, 32-36, 38-41. However, the rejection has not been overcome for claims 3 and 26. Claim 3 recites of a “request uniform resource locator (URL) path” and recites “the request URL”. There is no antecedent basis for request URL. There is antecedent basis for request URL path. Examiner suggests amending claims 3 and 26 to recite “the request URL path” to overcome the USC 112(b) rejection.
With respect to the USC 101 abstract idea the rejection has been overcome due to applicant’s amendments.
With respect to the double patenting rejection. The rejection is being maintained due to no approved terminal disclaimer being filed.
With respect to the arguments for USC 103 Applicant has argued that the teaching of RADINSKY-MEDVEDOVSKY fail to teach the limitations of claim 1. In particular the limitation of “application-layer signatures”. Examiner respectfully disagrees. Applicant has argued that the “application layer” is the layer-7 of the OSI model. However, this is not recited in the claims. The claims broadly recite of application layer signatures. Which under broadest reasonable interpretation relate to any signature of an application. RADINSKY teaches of generating signatures for applications as seen in the following citation. ([RADINSKY, para. 0061] “the applications for which signatures may be generated may be identified. The application may be a desirable or undesirable application. An undesirable application may be a malicious application, such as a virus, worm, Trojan horse, spyware, scareware, crimeware, rootkits, or other type of application”). RADINSKY further teaches of the OSI model as seen in para. 0024 ([RADINSKY, para. 0024] “The applications signatures may use a parameter vector that includes many protocol or communication attributes. A parameter vector may include parameters relating to the transport or lower level layers in the Open Systems Interconnection model (OSI model) definitions”). Examiner suggests Applicant amend the claims by clarifying the limitations to specifically recite application layer is the layer-7 of the OSI model.
Claim Objections
Claims 1, 14, 23, 24, and 37 are objected to because of the following informalities: claims 1, 14, 23, 24, and 37 recite the limitation “ongoing” while also reciting “on-going”. Examiner suggests changing all instances of “ongoing” to “on-going”. Appropriate correction is required.
Claim 20 is objected to for reciting “the on-going application-layer application-layer attack”. Examiner suggests amending this to “the on-going application-layer attack”. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is:
“… the Alpha filter is configured to” in claim 33
Because this claim limitation(s) is being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it is being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
See specification para. [0075, 0078] for functional support
See specification para. [0114, 0115] for hardware support
If applicant does not intend to have this limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 3 and 26 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 3 and 26 recites the limitation "bytes of the request URL". There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination examiner is interpreting this limitation as “bytes of the request URL path”. Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 4, 8, 23, 24, 27, and 31 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3, 4, and 14 of copending Application No. 18/398,985 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Current application 18/176667
copending Application No. 18/398,985
1.) A method for generating application-layer signatures characterizing advanced application-layer attacks, comprising: determining applicative baseline distributions of attributes included in transactions directed to a protected entity during peacetime; determining attack distributions of applicative attributes included in transactions directed to a protected entity during an on-going application-layer attack; determining, based on the applicative baseline distributions and the attack distributions of applicative attributes, a probability of an attacker executing the on-going application-layer attack to generate an attack using at least one attribute; and generating an application-layer signature designating applicative attributes determined to be eligible based on their respective probabilities, wherein the application-layer signature characterizes behavior of the attacker executing the on-going application-layer attack.
1.) A method for learning attack-safe baselines, comprising: receiving application-layer transactions directed to a protected entity; measuring values of a rate-based attribute and a rate-invariant attribute from the received application-layer transactions; determining, based on the measured rate-based attribute, if the received application-layer transactions represent a normal behavior; computing at least one baseline using application-layer transactions determined to represent the normal behavior; validating the at least one computed baseline using the measured rate-invariant attribute and rate-based attribute; and building a set of baselines based on the at least one validated baseline, wherein the set of baselines are utilized for characterization of DDoS attacks.
4. The method of claim 1, further comprising: generating, using at least one computed baseline, an application-layer signature designating applicative attributes utilized for characterization of DDoS attacks.
8.) The method of claim 7, further comprises: computing paraphrase values mean occurrences for the BPBFs for a current time window based on an average of occurrences for paraphrase values in the BPBFs computed for a previous time window, a total of occurrences for paraphrase values in the WPBFs for a current time window, and an Alpha filter.
3.) The method of claim 2, further comprises: computing paraphrase values mean occurrences for the BPBFs for a current time window based on an average of occurrences for paraphrase values in the BPBFs computed for a previous time window, a total of occurrences for paraphrase values in the WPBFs for a current time window, and using an Alpha filter.
4.) The method of claim 2, further comprising: sampling transactions received during a time window; for each time window, building a set of window paraphrase buffers (WPBFs); building a set of baseline paraphrase buffers (BPBFs) from transactions directed to the protected entity during peacetime, wherein the BPBFs represent a paraphrase normal behavior.
14.) The method of claim 1, wherein building the set of baselines further comprises: building a set of baseline paraphrase buffers (BPBFs) from at least one validated baseline, wherein each BPBF represents a normal behavior of a paraphrase.
Claims 23, 24, 27, and 31 are parallel claims and therefore, are rejected in a similar manner.
Claims 1, 2, 4-9, 23-25, and 27-32 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 5-10, 12, and 19 of copending Application No. 18/794,606 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Current application 18/176667
copending Application No. 18/794,606
1. A method for generating application-layer signatures characterizing advanced application-layer attacks, comprising: determining applicative baseline distributions of attributes included in transactions directed to a protected entity during peacetime; determining attack distributions of applicative attributes included in transactions directed to a protected entity during an on-going application-layer attack; determining, based on the applicative baseline distributions and the attack distributions of applicative attributes, a probability of an attacker executing the on-going application-layer attack to generate an attack using at least one attribute; and generating an application-layer signature designating applicative attributes determined to be eligible based on their respective probabilities, wherein the application- layer signature characterizes behavior of the attacker executing the on-going application-layer attack.
1.(Original) A method for generating application-layer signatures characterizing advanced application-layer attacks, comprising: computing, based on applicative peacetime baseline distributions and attack distributions of applicative attributes included in application-layer transactions directed to a protected entity, an attacker probability of an attacker executing an ongoing application-layer attack; comparing the attacker probability computed for each of the applicative attributes to a dynamic attacker probability threshold; and including in an application-layer signature eligible applicative attributes having an attacker probability higher than the dynamic attacker threshold, wherein the application- layer signature includes an inclusive section and an exclusive section, and wherein the application-layer signature is indicative of an ongoing attack based on one of the exclusive section and the inclusive section.
4.) The method of claim 2, further comprising: sampling transactions received during a time window; for each time window, building a set of window paraphrase buffers (WPBFs); building a set of baseline paraphrase buffers (BPBFs) from transactions directed to the protected entity during peacetime, wherein the BPBFs represent a paraphrase normal behavior.
5.(Original) The method of claim 4, further comprising: sampling transactions received during a time window; for each time window, building a set of window paraphrase buffers (WPBFs); and building a set of baseline paraphrase buffers (BPBFs) from transactions directed to the protected entity during peacetime, wherein the BPBFs represent a paraphrase distribution of normal behavior.
5. The method of claim 4, further comprising: sampling transactions received during a time window; for each time window, building a set of window paraphrase buffers (WPBFs); building, for each time window, a set of attack paraphrase buffers (APBFs) from transactions received during the on-going application-layer attack, wherein the APBFs represent a paraphrase attack time behavior for a duration of the on-going application-layer attack.
6.(Original) The method of claim 5, further comprising: sampling transactions received during a time window; for each time window, building a set of per-second paraphrase buffers; and building, from each per-second paraphrase buffers, attack paraphrase distributions from transactions received during an on-going application-layer attack, wherein the attack paraphrase distributions represent paraphrases distributions for a duration of the on-going application-layer attack.
6.) The method of claim 5, wherein building the set of WPBFs further comprises: vectoring a set of paraphrases derived from the received transactions during a time window; and buffering the paraphrase vectors to provide the WPBFs.
7.(Original) The method of claim 6, wherein building the set of WPBFs and per-second paraphrase buffers further comprises: vectoring a set of paraphrases derived from the received transactions during a time window; and buffering the paraphrase vectors to provide the WPBFs and per-second paraphrase buffers.
7. The method of claim 4, wherein building the set of BPBFs further comprises: updating values from the WPBFs into the BPBFs.
8. (Original) The method of claim 7, wherein building the set of BPBFs further comprises: updating values from the WPBFs into the BPBFs.
8. The method of claim 7, further comprises: computing paraphrase values mean occurrences for the BPBFs for a current time window based on an average of occurrences for paraphrase values in the BPBFs computed for a previous time window, a total of occurrences for paraphrase values in the WPBFs for a current time window, and an Alpha filter.
9. (Original) The method of claim 8, further comprising: computing paraphrase values mean occurrences for the BPBFs for a current time window based on an average of distributions for paraphrase values in the BPBFs computed for a previous time window, a total of distributions for paraphrase values in the WPBFs for a current time window, and an R filter.
9. The method of claim 4, wherein building the APBFs further comprises: updating the values from the WPBFs into the APBFs; and updating paraphrase value occurrences based on transactions directed to the protected entity during the on-going application-layer attack.
10. (Original) The method of claim 9, wherein building the attack paraphrase distributions further comprises: updating the distributions from the per-second paraphrase buffer into the attack paraphrase mean histogram; and updating paraphrase value distributions based on transactions directed to the protected entity during an ongoing application-layer attack.
2. The method of claim 1, further comprising: maintaining attributes of transactions, directed to a protected entity, in a paraphrase, wherein each paraphrase includes at least one paraphrase value, wherein a paraphrase value represents an applicative attribute in a transaction.
12. (Original) The method of claim 3, further comprising: maintaining applicative attributes of transactions, directed to the protected entity, in a paraphrase, wherein each paraphrase includes at least one paraphrase value, wherein a paraphrase value represents an applicative attribute in a transaction.
20. The method of claim 21, wherein the on-going application-layer attack is a DDoS attack realized as a HTTP flood application-layer attack.
19. (Original) The method of claim 1, wherein the ongoing application-layer attack is a DDoS attack realized as an HTTP flood application-layer attack.
Claims 23-25, and 27-32 are parallel claims and therefore, are rejected in a similar manner.
Claims 1, 3, 15, 20, 22, 23, 24, 26, 38, 43, and 45 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 4, 7, 13, 15 of U.S. Patent No. US 11582259 B1. Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
Current application 18/176667
U.S. Patent No. US 11582259 B1
1.) A method for generating application-layer signatures characterizing advanced application-layer attacks, comprising: determining applicative baseline distributions of attributes included in transactions directed to a protected entity during peacetime; determining attack distributions of applicative attributes included in transactions directed to a protected entity during an on-going application-layer attack; determining, based on the applicative baseline distributions and the attack distributions of applicative attributes, a probability of an attacker executing the on-going application-layer attack to generate an attack using at least one attribute; and generating an application-layer signature designating applicative attributes determined to be eligible based on their respective probabilities, wherein the application-layer signature characterizes behavior of the attacker executing the on-going application-layer attack.
1.) A method for characterizing application layer flood denial-of-service (DDoS) attacks, comprising:
receiving an indication on an on-going DDoS attack directed to a protected entity;
generating a dynamic applicative signature by analyzing requests received during the on-going DDoS attack, wherein generating the dynamic applicative signature includes, at an end of a characterization window, determining a top of buffer values of each paraphrase in an array of paraphrase buffers, wherein the dynamic applicative signature is the top of buffer across all paraphrases in the array, wherein the dynamic applicative signature characterizes requests generated by an attack tool executing the on-going DDoS attack;
characterizing each incoming request based on the generated dynamic applicative signature, wherein the characterization provides an indication for each incoming request whether a request is generated by the attack tool;
and generating a multi-paraphrase signature characterizing the attack tool by clustering at least one value of a plurality of different attributes of the received requests.
3. The method of claim 2, wherein the paraphrase value is any one of: an HTTP VERB; a number of path elements in a request URL path; a number of query arguments in the request URL; a User Agent actual value, a number of key: values cookie elements in cookie; a length of User Agent header; a total length in bytes of the request; a total number of known HTTP headers; a total number of unknown headers; and existence, or non-existence, of a predefined set of HTTP headers, existence of a dynamically defined set of HTTP headers, a geographical information on an origin of the attacker.
4.) The method of claim 3, wherein the received requests are HTTP requests, and wherein updating the paraphrase vector further comprises:
parsing each of the received requests to identify HTTP headers;
extracting a value of a HTTP method field from the parsed request;
counting a number of path elements from a URL path designated in the parsed request;
identifying and counting known HTTP headers in the parsed request; and
identifying and counting unknown HTTP headers in the parsed request;
identifying and counting the number of cookie key values in cookie HTTP header;
identifying and counting the number of query arguments in the URL;
identifying the total length in bytes of the request;
identifying the length of User Agent HTTP header; and
populating a data structure of the paraphrase vector with the HTTP method's field, the number of path elements, the number of known HTTP headers;
the number of unknown HTTP headers, the number of key values in cookie header, the number of query argument in URL, the length of the request, and the length of User Agent header.
15. The method of claim 14, further comprising: converting an incoming transaction into a paraphrase vector; comparing the paraphrase vector to the eligible application-layer signature; determining the incoming transaction is a legitimate request when the paraphrase vector does not match the eligible application-layer signature; and determining the incoming transaction is generated by the attacker when the paraphrase vector matches the eligible application-layer signature.
7. The method of claim 1, wherein characterizing each incoming request based on the dynamic applicative signature further comprises:
converting the received incoming request into a paraphrase vector;
comparing the paraphrase vector to the dynamic applicative signature;
determining the received incoming request is a legitimate request when the paraphrase vector does not match the dynamic applicative signature; and
determining the received incoming request is generated by the attack tool when the paraphrase vector matches the dynamic applicative signature.
20. The method of claim 21, wherein the on-going application-layer attack is a DDoS attack realized as a HTTP flood application-layer attack.
13. The method of claim 1, wherein the DDoS attack is an HTTP Flood attack, and the attacker carries the attack using an HTTP Flood attack tool, wherein the HTTP Flood attack tool generates HTTP requests having legitimate structure and content.
22. The method of claim 1, wherein the method is performed by any one of: a DDoS mitigation device, a WAF device, a WEB server, a WEB cache (CDN), and a WEB proxy.
15. The method of claim 1, wherein the method is performed by any one of: a DDoS mitigation device, a Web Application Firewall (WAF) device, a web server, and a web proxy.
Claims 23, 24, 26, 38, 43, and 45 are parallel claims and therefore, are rejected in a similar manner.
Claims 1, 23, 24, 40 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 of U.S. Patent No. US 11888893 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
Current application 18/176667
U.S. Patent No. US 11888893 B2
1.) A method for generating application-layer signatures characterizing advanced application-layer attacks, comprising: determining applicative baseline distributions of attributes included in transactions directed to a protected entity during peacetime; determining attack distributions of applicative attributes included in transactions directed to a protected entity during an on-going application-layer attack; determining, based on the applicative baseline distributions and the attack distributions of applicative attributes, a probability of an attacker executing the on-going application-layer attack to generate an attack using at least one attribute; and generating an application-layer signature designating applicative attributes determined to be eligible based on their respective probabilities, wherein the application-layer signature characterizes behavior of the attacker executing the on-going application-layer attack.
17. The method of claim 14, further comprising: generating a policy to mitigate the attacker, based on the eligible application-layer signature; and providing the policy to a mitigation resource to perform at least one mitigation action on requests determined to be generated by the attack tool.
1.) A method for characterizing application layer denial-of-service (DDoS) attacks, comprising:
generating a plurality of dynamic applicative signatures by analyzing at the application layer application layer requests received during an on-going DDoS attack, wherein a dynamic applicative signature characterizes each received application layer request based on frequent applicative application layer attributes appearing in the received application layer requests;
characterizing each of the received application layer requests based on one of the generated dynamic applicative signatures, wherein the characterization provides an indication for each received application layer request whether a received application layer request is generated by an attack tool executing the on-going DDoS attributes; and
causing a mitigation action on the received application layer request generated by the attack tool based on the generated dynamic applicative signature.
Claims 23, 24, and 40 are parallel claims and therefore, are rejected in a similar manner.
Claims 1, 2, 17, 20, 22, 23, 24, 25, 40, 43, and, 45 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8, 11, 13 of U.S. Patent No. US 12184690 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
Current application 18/176667
U.S. Patent No. US 12184690 B2
1.) A method for generating application-layer signatures characterizing advanced application-layer attacks, comprising: determining applicative baseline distributions of attributes included in transactions directed to a protected entity during peacetime; determining attack distributions of applicative attributes included in transactions directed to a protected entity during an on-going application-layer attack; determining, based on the applicative baseline distributions and the attack distributions of applicative attributes, a probability of an attacker executing the on-going application-layer attack to generate an attack using at least one attribute; and generating an application-layer signature designating applicative attributes determined to be eligible based on their respective probabilities, wherein the application-layer signature characterizes behavior of the attacker executing the on-going application-layer attack.
2. The method of claim 1, further comprising: maintaining attributes of transactions, directed to a protected entity, in a paraphrase, wherein each paraphrase includes at least one paraphrase value, wherein a paraphrase value represents an applicative attribute in a transaction.
17. The method of claim 14, further comprising: generating a policy to mitigate the attacker, based on the eligible application-layer signature; and providing the policy to a mitigation resource to perform at least one mitigation action on requests determined to be generated by the attack tool.
1.) A method for characterizing application layer denial-of-service (DDoS) attacks, comprising:
generating a plurality of dynamic applicative signatures by analyzing at the application layer application layer requests received during an on-going DDOS attack, wherein a dynamic applicative signature characterizes each received application layer request based on frequent application layer attributes appearing in the received application layer requests, wherein the application layer requests are represented as a set of paraphrases, wherein each paraphrase represents a specific aspect of an application layer request's structure, and wherein the frequent application layer attributes are determined based on frequency of paraphrases in the set of paraphrases;
characterizing each of the received application layer requests based on one of the generated dynamic applicative signatures, wherein the characterization provides an indication for each received application layer request whether a received application layer request is generated by an attack tool executing the on-going DDOS attack; and
causing a mitigation action on the received application layer request generated by the attack tool based on the generated dynamic applicative signature.
17. The method of claim 14, further comprising: generating a policy to mitigate the attacker, based on the eligible application-layer signature; and providing the policy to a mitigation resource to perform at least one mitigation action on requests determined to be generated by the attack tool.
8. The method of claim 1, further comprising:
generating a policy to mitigate effects of the attack tool, based on the generated dynamic applicative signature; and
providing the policy to a mitigation resource to perform at least one mitigation action on application layer requests determined to be generated by the attack tool.
20. The method of claim 21, wherein the on-going application-layer attack is a DDoS attack realized as a HTTP flood application-layer attack.
11. The method of claim 1, wherein the DDOS attack is an HTTP Flood attack carried out using as the attack tool an HTTP Flood attack tool, wherein the HTTP Flood attack tool generates HTTP requests having legitimate structure and content.
22. The method of claim 1, wherein the method is performed by any one of: a DDoS mitigation device, a WAF device, a WEB server, a WEB cache (CDN), and a WEB proxy.
13. The method of claim 1, wherein the method is performed by any one of: a DDOS mitigation device, a WAF device, a WEB server, and a WEB proxy.
Claims 23, 24, 40, 43, and 45 are parallel claims and therefore, are rejected in a similar manner.
Claims 1, 2, 4, 22-25, 27, and 45 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 15 of U.S. Patent No. US 11552989 B1. Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
Current application 18/176667
U.S. Patent No. US 11552989 B1
1.) A method for generating application-layer signatures characterizing advanced application-layer attacks, comprising: determining applicative baseline distributions of attributes included in transactions directed to a protected entity during peacetime; determining attack distributions of applicative attributes included in transactions directed to a protected entity during an on-going application-layer attack; determining, based on the applicative baseline distributions and the attack distributions of applicative attributes, a probability of an attacker executing the on-going application-layer attack to generate an attack using at least one attribute; and generating an application-layer signature designating applicative attributes determined to be eligible based on their respective probabilities, wherein the application-layer signature characterizes behavior of the attacker executing the on-going application-layer attack.
2. The method of claim 1, further comprising: maintaining attributes of transactions, directed to a protected entity, in a paraphrase, wherein each paraphrase includes at least one paraphrase value, wherein a paraphrase value represents an applicative attribute in a transaction.
4. The method of claim 2, further comprising: sampling transactions received during a time window; for each time window, building a set of window paraphrase buffers (WPBFs); building a set of baseline paraphrase buffers (BPBFs) from transactions directed to the protected entity during peacetime, wherein the BPBFs represent a paraphrase normal behavior.
1.) A method for characterizing application layer flood denial-of-service (DDoS) attacks carried by advanced application layer flood attack tools, comprising:
receiving an indication on an on-going DDoS attack directed toward a protected entity;
analyzing requests received during the on-going DDoS attack to determine a plurality of different attributes of the received requests;
generating a dynamic applicative multi-paraphrase signature by clustering at least one value of the plurality of different attributes, wherein the multi-paraphrase signature characterizes requests with different attributes as generated by an advanced application layer flood attack tool executing the on-going DDoS attack;
generating the multi-paraphrase signature based on eligible top of buffer (ToB) values generated across all paraphrase buffers, wherein the eligible ToB values are determined based on paraphrase values in the ToB and rest of buffer (RoB) and a minimum attack factor (MAF); and
characterizing each incoming request based on the multi-paraphrase signature, wherein the characterization provides an indication for each incoming request whether a request is generated by the attack tool.
22. The method of claim 1, wherein the method is performed by any one of: a DDoS mitigation device, a WAF device, a WEB server, a WEB cache (CDN), and a WEB proxy.
15. The method of claim 1, wherein the method is performed by any one of: a DDoS mitigation device, a WAF device, a WEB server, and a WEB proxy.
Claims 23, 24, 25, 27, and 45 are parallel claims and therefore, are rejected in a similar manner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 7, 14-27, 30, and 37-45 are rejected under 35 U.S.C. 103 as being unpatentable over RADINSKY (US-20120317306-A1) in view of MEDVEDOVSKY (US-20210194903-A1), hereinafter RADINSKY-MEDVEDOVSKY.
Regarding claim 1, RADINSKY teaches “A method for generating application-layer signatures characterizing advanced application-layer attacks, comprising: ([RADINSKY, abstract] “A set of signatures may be created by training a machine learning system using network traffic with and without a specific application. The machine learning system may generate a signature for the specific application, and the signature may be analyzed using a monitoring system to identify the presence of the application's traffic on the network.”) ([RADINSKY, para. 0061] “the applications for which signatures may be generated may be identified. The application may be a desirable or undesirable application. An undesirable application may be a malicious application, such as a virus, worm, Trojan horse, spyware, scareware, crimeware, rootkits, or other type of application”) … generating an application-layer signature designating applicative attributes determined to be eligible based on their respective probabilities, wherein the application-layer signature characterizes behavior of the attacker executing the on-going application-layer attack. ([RADINSKY, para. 0059] “The signatures may be a decision tree with conditional probabilities. Such signatures may be able to detect a specific application and give a probability of a match for that application.”) ([RADINSKY, para. 0038] “embodiment may have a mechanism for determining a signature for a given application, and a separate monitoring application that may capture and analyze network traffic in real time. The mechanism for determining a signature for a given application may cause an application to execute, then monitor the network communications performed by the application. The data collected may be analyzed using a machine learning algorithm or other mechanism to create a signature. The signature may then be transmitted to the monitoring applications to identify the given application.”) ([RADINSKY, para. 0061] “the applications for which signatures may be generated may be identified. The application may be a desirable or undesirable application. An undesirable application may be a malicious application”).
However, RADINSKY does not teach “determining applicative baseline distributions of attributes included in transactions directed to a protected entity during peacetime; determining attack distributions of applicative attributes included in transactions directed to a protected entity during an on-going application-layer attack; determining, based on the applicative baseline distributions and the attack distributions of applicative attributes, a probability of an attacker executing the on-going application-layer attack to generate an attack using at least one attribute; and”.
In analogous teaching MEDVEDOVSKY teaches “determining applicative baseline distributions of attributes included in transactions directed to a protected entity during peacetime; ([MEDVEDOVSKY, abstract] “The method includes receiving samples of at least rate-base features, wherein the rate-base features demonstrate a normal behavior of at least HTTPS traffic directed to a protected entity; computing a short-term baseline and a long-term baseline based on the received samples”) determining attack distributions of applicative attributes included in transactions directed to a protected entity during an on-going application-layer attack; ([MEDVEDOVSKY, para. 0012] “The method comprising receiving samples of at least rate-base features, wherein the rate-base features demonstrate a normal behavior of at least HTTPS traffic directed to a protected entity”) ([MEDVEDOVSKY, para. 0030] “ingress traffic from the client device 120 to the victim server 130 is analyzed to determine a number of HTTPS requests per second”) ([MEDVEDOVSKY, para. 0029] “The inspected traffic is analyzed to determine abnormal activity based on rate-base and rate-invariant features of the inspected traffic. The rate-base traffic features and the rate-invariant traffic features demonstrate behavior of HTTPS traffic directed to the victim server 130.”) ([MEDVEDOVSKY, para. 0031] “an ingress traffic (from a client 120 and attacker 125 to the victim server 130) of HTTPS requests volumes in byte per second (a rate-base feature); ingress/egress ratio measured by the ratio between ingress HTTPS requests per second and egress HTTPS response volumes in byte per second (a rate-invariant feature)”) determining, based on the applicative baseline distributions and the attack distributions of applicative attributes, a probability of an attacker executing the on-going application-layer attack to generate an attack using at least one attribute; and ([MEDVEDOVSKY, para. 0029] “The inspected traffic is analyzed to determine abnormal activity based on rate-base and rate-invariant features of the inspected traffic. The rate-base traffic features and the rate-invariant traffic features demonstrate behavior of HTTPS traffic directed to the victim server 130.”) ([MEDVEDOVSKY, para. 0012] “The method comprising receiving samples of at least rate-base features, wherein the rate-base features demonstrate a normal behavior of at least HTTPS traffic directed”) ([MEDVEDOVSKY, para. 0030] “Further, egress traffic, from the victim server 130 to the client device 120 and the attack tool 125, is analyzed to determine the volume of HTTPS response sizes, as the responses' number of bytes per second (rate-base features) and the distribution (average) of HTTPS response sizes (rate-invariant feature).”) ([MEDVEDOVSKY, para. 0080] “a rate-invariant anomaly is detected based on an abnormal distribution of the size of HTTPS requests and responses. In an embodiment, an abnormal distribution is determined based on the probability that a request's size would fit a specific bin. A bin is defined as a single “bucket” in the distribution.”) ([MEDVEDOVSKY, para. 0081] “The distribution of each bin reflects the overall probability of an individual HTTPS request, or response, accordingly, to appear in a specific bin.”) … and performing mitigation of the ongoing application-layer attack based on the generated application-layer signature. ([MEDVEDOVSKY, para. 0025] “The defense system 110 includes a detector 111 and a mitigation resource 112”) ([MEDVEDOVSKY, para. 0026] “The mitigation resource 112 is configured to perform one or more mitigation actions, triggered by the detector 111, in order to mitigate a detected attack”) ([MEDVEDOVSKY, para. 0027] “The communication with the victim server 130 is over an application-layer cryptographic protocol, such as HTTPS, based on any version of an encryption protocol such as SSL, TLS, and the like”).
Thus, given the teaching of MEDVEDOVSKY, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of determining applicative baseline distributions by MEDVEDOVSKY into a method for generating application-layer signatures by RADINSKY. One of ordinary skill in the art would have been motivated to do so because MEDVEDOVSKY recognizes the need to efficiently detect HTTPS flood attacks ([MEDVEDOVSKY, para. 0010] “It would be, therefore, advantageous to provide an efficient security solution for detecting and mitigating HTTPS flood attacks.”).
Regarding claim 23, this claim recites of a non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process that performs the steps of method claim 1. Therefore, claim 23 is rejected in a similar manner as in the rejection of claim 1.
Regarding claim 24, this claim recites of a system which performs the steps of method claim 1. Therefore, claim 24 is rejected in a similar manner as in the rejection of claim 1.
Regarding claims 2 and 25, RADINSKY-MEDVEDOVSKY teach all limitations of claims 1 and 24. MEDVEDOVSKY further teaches “maintaining attributes of transactions, directed to a protected entity, in a paraphrase, wherein each paraphrase includes at least one paraphrase value, wherein a paraphrase value represents an applicative attribute in a transaction.” ([MEDVEDOVSKY, para. 0060] “each sample, traffic features are estimated. This includes estimating, for example, the total number of HTTPS requests, total volume (bytes) of HTTPS requests, total volume (bytes) of HTTPS responses, lists of all requests and their sizes and the source IP generating each request”) ([MEDVEDOVSKY, para. 0096] “In an embodiment, each buffer is a dedicated cyclic FIFO buffer for keeping several last samples of input/output. Initially, the buffers are filled with a padding value, which is the average value of several previous samples or the first valid sample.”)
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Regarding claims 3 and 26, RADINSKY-MEDVEDOVSKY teach all limitations of claims 2 and 25. MEDVEDOVSKY further teaches “wherein the paraphrase value is any one of: a Hypertext Transfer Protocol (HTTP) VERB; a number of path elements in a request uniform resource locator (URL) path; a number of query arguments in the request URL; a User Agent actual value, a number of key:values cookie elements in cookie; a length of User Agent header; a total length in bytes of the request URL; a total number of known HTTP headers; a total number of unknown headers; and existence, or non-existence, of a predefined set of HTTP headers, existence of a dynamically defined set of HTTP headers, a geographical information on an origin of the attacker.” ([MEDVEDOVSKY, para. 0060] “each sample, traffic features are estimated. This includes estimating, for example, the total number of HTTPS requests, total volume (bytes) of HTTPS requests, total volume (bytes) of HTTPS responses, lists of all requests and their sizes and the source IP generating each request”) ([MEDVEDOVSKY, para. 0061] “The information carried in a header of a TCP packet can be utilized to estimate the existence of HTTP requests and responses, and the size of the responses and requests. Specifically, the TCP SEQ number and the TCP ACK number designated in the TCP header can be utilized to estimate the size of the request and response, respectively.”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Regarding claims 4 and 27, RADINSKY-MEDVEDOVSKY teach all limitations of claims 2 and 25. MEDVEDOVSKY further teaches “sampling transactions received during a time window; and for each time window, building a set of window paraphrase buffers (WPBFs); ([MEDVEDOVSKY, para. 0096] “each buffer is a dedicated cyclic FIFO buffer for keeping several last samples of input/output. Initially, the buffers are filled with a padding value, which is the average value of several previous samples or the first valid sample.”) and building a set of baseline paraphrase buffers (BPBFs) from transactions directed to the protected entity during peacetime, wherein the BPBFs represent a paraphrase normal behavior. ([MEDVEDOVSKY, para. 0095] “The IIR LPF is utilized for both the short-term and long-term baselines, but is configured differently for each baseline type. … The IIR LPF is typically defined as follows: … The sample values ‘Y’ and ‘X’ are maintained in separate buffers having a size of the LPF.”) ([MEDVEDOVSKY, para. 0098] “During peacetime, a feeder 310 feeds all samples of the HTTPS request rate to a circular buffer 320 to feed an IIR LPF 330. The IIR LPF 330 continually produces the short-term baseline and the prediction of the next sample. The outputs of the IIR LPF 330 are fed to another circular buffer 340 to proceed with the IIR LPF recursive operation. The immediate output value is assigned to the short-term baseline Y(t).”) ([MEDVEDOVSKY, para. 0070] “each baseline is continuously updated.”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Regarding claims 7 and 30, RADINSKY-MEDVEDOVSKY teach all limitations of claims 4 and 27. MEDVEDOVSKY further teaches “wherein building the set of BPBFs further comprises: updating values from the WPBFs into the BPBFs.” ([MEDVEDOVSKY, para. 0098] “The outputs of the IIR LPF 330 are fed to another circular buffer 340 to proceed with the IIR LPF recursive operation. The immediate output value is assigned to the short-term baseline Y(t). The short-term baseline is defined as follows: Y(t)=LPF(X(t),Y(t))”) ([MEDVEDOVSKY, para. 0099] “To detect an anomaly, the predicted value, which is the last baseline value ‘Y’ is compared with the new sample ‘X’ and their difference, ‘Δ’ is analyzed.”) ([MEDVEDOVSKY, para. 0050] “is configured to determine, or to otherwise compute, normal baselines for each traffic feature. The baselines are continuously determined at peace-time and during predefined learning periods (e.g., a week, an hour, etc. that is used for learning the normal baseline) … The baselines, computed according to the disclosed embodiments, include a short baseline and a long baseline.”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Regarding claims 14 and 37, RADINSKY-MEDVEDOVSKY teach all limitations of claims 1 and 24. MEDVEDOVSKY further teaches “wherein performing mitigation of the ongoing application-layer attack based on the application-layer signature further comprises causing a mitigation resource to mitigate the on-going application-layer attack using an application-layer signature determined to be eligible.” ([MEDVEDOVSKY, para. 0025] “The defense system 110 includes a detector 111 and a mitigation resource 112”) ([MEDVEDOVSKY, para. 0026] “The mitigation resource 112 is configured to perform one or more mitigation actions, triggered by the detector 111, in order to mitigate a detected attack”) ([MEDVEDOVSKY, para. 0027] “The communication with the victim server 130 is over an application-layer cryptographic protocol, such as HTTPS, based on any version of an encryption protocol such as SSL, TLS, and the like”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Regarding claims 15 and 38, RADINSKY-MEDVEDOVSKY teach all limitations of claims 14 and 37. RADINSKY further teaches “further comprising: converting an incoming transaction into a paraphrase vector; ([RADINSKY, para. 0076] “In block 302, network streams may be monitored.”) ([RADINSKY, para. 0078] “For one of the network streams identified in block 304, a parameter vector may be generated in block 306. In some cases, the parameter vector may include statistics that may be measured or calculated from the network stream”) comparing the paraphrase vector to the eligible application-layer signature; ([RADINSKY, para. 0079] “For each signature in the database in block 308, the vector may be analyzed in block 310 and the match probability may be determined in block 312. In embodiments where a signature is a decision tree, the analysis of blocks 310 and 312 may be quickly performed with a minimum of computational expense”) determining the incoming transaction is a legitimate request when the paraphrase vector does not match the eligible application-layer signature; and ([RADINSKY, para. 0080] “If the probability of a match between the parameter vector and the currently analyzed signature does not exceed a predefined threshold in block 314, the process may return to block 308 to process another signature”) ([RADINSKY, para. 0081] “After processing the signatures in block 308, if there is no match found in block 318, the process may return to block 302 to gather and process another network stream.”) determining the incoming transaction is generated by the attacker when the paraphrase vector matches the eligible application-layer signature. ([RADINSKY, para. 0080] “If the probability of a match does exceed the predefined threshold in block 314, the signature may be determined as a match and the loop may be exited in block 316.”) ([RADINSKY, para. 0082] “If there is a match in block 318, action may be taken based on the match in block 320. … Examples of decreasing the performance may include lowering priority, lowering the transmission rates, throttling transmission, cutting off transmission completely, or other changes that limit or restrict network transmission”).
Regarding claims 16 and 39, RADINSKY-MEDVEDOVSKY teach all limitations of claims 15 and 38. RADINSKY further teaches “wherein the match is determined based on a number of predefined matching paraphrases between the paraphrase vector of the received incoming transaction and the eligible application-layer signature.” ([RADINSKY, para. 0078] “a parameter vector may be generated in block 306. In some cases, the parameter vector may include statistics that may be measured or calculated from the network stream.”) ([RADINSKY, para. 0044] “a network analyzer 122 may generate various parameters that make up a parameter vector for each application”) ([RADINSKY, para. 0079] “For each signature in the database in block 308, the vector may be analyzed in block 310 and the match probability may be determined in block 312. In embodiments where a signature is a decision tree, the analysis of blocks 310 and 312 may be quickly performed with a minimum of computational expense.”).
Regarding claims 17 and 40, RADINSKY-MEDVEDOVSKY teach all limitations of claims 14 and 37. RADINSKY further teaches “further comprising: generating a policy to mitigate the attacker, based on the eligible application-layer signature; and ([RADINSKY, para, 0022] “the monitoring system may have a signature database that includes signatures from many viruses, bots, or other malware. The monitoring system may track network sessions and compare those sessions to known malware. When malware is detected, the monitoring system may stop the network session, alert a user or administrator, slow down the network session, or perform other actions”).
MEDVEDOVSKY further teaches “providing the policy to a mitigation resource to perform at least one mitigation action on requests determined to be generated by the attacker.” ([MEDVEDOVSKY, para, 0026] “The mitigation resource 112 is configured to perform one or more mitigation actions, triggered by the detector 111, in order to mitigate a detected attack. Examples for a mitigation resource 112 may be, but are not limited to, a scrubbing center or a multi-tiered mitigation system.”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Regarding claims 18 and 41, RADINSKY-MEDVEDOVSKY teach all limitations of claims 17 and 40. MEDVEDOVSKY further teaches “wherein the at least one mitigation action includes blocking the attacker.” ([MEDVEDOVSKY, para. 0052] “The mitigation action may be, for example, blocking, or rate-limiting, traffic from the client 120 to the server, challenging the client causing any traffic anomaly (e.g., CAPTCHA), redirecting the traffic to a scrubbing center for cleaning malicious traffic, and so on”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Regarding claims 19 and 42, RADINSKY-MEDVEDOVSKY teach all limitations of claims 1 and 24. MEDVEDOVSKY further teaches “further comprising: determining the attack distributions of applicative attributes upon receiving an indication on the application-layer attack directed toward a protected entity.” ([MEDVEDOVSKY, para. 0030] “ingress traffic from the client device 120 to the victim server 130 is analyzed to determine a number of HTTPS requests per second: RPS, (as a rate-base feature) and the distribution (average) of HTTPS request size (as a rate-invariant feature). Further, egress traffic, from the victim server 130 to the client device 120 and the attack tool 125, is analyzed to determine the volume of HTTPS response sizes, as the responses' number of bytes per second (rate-base features) and the distribution (average) of HTTPS response sizes (rate-invariant feature).”) ([MEDVEDOVSKY, para. 0080] “a rate-invariant anomaly is detected based on an abnormal distribution of the size of HTTPS requests and responses”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Regarding claims 20 and 43, RADINSKY-MEDVEDOVSKY teach all limitations of claims 21 and 24. MEDVEDOVSKY further teaches “wherein the on-going application-layer attack is a Distributed Denial of Service (DDoS) attack realized as a Hypertext Transfer Protocol (HTTP) flood application-layer attack.” ([MEDVEDOVSKY, para. 0044] “in order to detect HTTPS flood attacks, the defense system 110 is configured to compare features of inspected traffic to the legitimate traffic patterns (or their normal baselines).”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Regarding claims 21 and 44, RADINSKY-MEDVEDOVSKY teach all limitations of claims 20 and 43. MEDVEDOVSKY further teaches “further comprises: sampling the transactions, wherein the transactions are Hypertext Transfer Protocol (HTTP) requests.” ([MEDVEDOVSKY, para. 0060] “for each sample, traffic features are estimated. This includes estimating, for example, the total number of HTTPS requests, total volume (bytes) of HTTPS requests, total volume (bytes) of HTTPS responses”) ([MEDVEDOVSKY, para. 0042] “Detection of an HTTPS POST attack may be based on the detection of anomalies at one or more of the following traffic features: a number of HTTPS requests and an ingress BW (measured as an HTTPS request size volume in bytes per second)”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Regarding claims 22 and 45, RADINSKY-MEDVEDOVSKY teach all limitations of claims 20 and 24. MEDVEDOVSKY further teaches “wherein the method is performed by any one of: a Distributed Denial of Service (DDoS) mitigation device, a web application firewall (WAF) device, a WEB server, a WEB cache, a content delivery network (CDN), and a WEB proxy.” ([MEDVEDOVSKY, para. 0044] “in order to detect HTTPS flood attacks, the defense system 110 is configured to compare features of inspected traffic to the legitimate traffic patterns (or their normal baselines).”) ([MEDVEDOVSKY, para. 0121] “FIG. 5 is an example block diagram of the defense system 110 implemented according to an embodiment. The defense system 110 includes a processing circuitry 510 coupled to a memory 515, a storage 520, and a network interface 540. In another embodiment, the components of the defense system 110 may be communicatively connected via a bus 550”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Claims 5, 6, 28, and 29 are rejected under 35 U.S.C. 103 as being unpatentable over RADINSKY-MEDVEDOVSKY in view of CHESLA (US-20080052774-A1), hereinafter RADINSKY-MEDVEDOVSKY-CHESLA.
Regarding claims 5 and 28, RADINSKY-MEDVEDOVSKY teach all limitations of claims 4 and 27. MEDVEDOVSKY further teaches “sampling transactions received during a time window; ([MEDVEDOVSKY, para. 0060] “for each sample, traffic features are estimated. This includes estimating, for example, the total number of HTTPS requests, total volume (bytes) of HTTPS requests, total volume (bytes) of HTTPS responses”) and for each time window, and building a set of window paraphrase buffers (WPBFs); ([MEDVEDOVSKY, para. 0096] “In an embodiment, each buffer is a dedicated cyclic FIFO buffer for keeping several last samples of input/output. Initially, the buffers are filled with a padding value, which is the average value of several previous samples or the first valid sample”) ([MEDVEDOVSKY, para. 0098] “During peacetime, a feeder 310 feeds all samples of the HTTPS request rate to a circular buffer 320 to feed an IIR LPF 330.).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
However, RADINSKY-MEDVEDOVSKY does not teach “building, for each time window, a set of attack paraphrase buffers (APBFs) from transactions received during the on-going application-layer attack, wherein the APBFs represent a paraphrase attack time behavior for a duration of the on-going application-layer attack.”.
In analogous teaching CHESLA teaches “building, for each time window, a set of attack paraphrase buffers (APBFs) from transactions received during the on-going application-layer attack, wherein the APBFs represent a paraphrase attack time behavior for a duration of the on-going application-layer attack.” ([CHESLA, para. 0318] “The default state of stateful connection controller 500 is a detection state 600. Each time the controller enters this state, the controller resets all of the counters and clears the sort buffer”) ([CHESLA, para. 0320] “Controller 500 maintains a sort buffer, which is a list of the most dangerous source addresses and their connection parameters (e.g., source port), for each protected service. For each source address in the sort buffer, the sort buffer maintains an intensity counter of the number of misused connections that the source address owns. …During an attack, the controller sorts the sort buffer once per timeframe (typically once per second) according to the intensity counter.”).
Thus, given the teaching of CHESLA, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of APBFs by CHESLA into a method for generating application-layer signatures by RADINSKY-MEDVEDOVSKY. One of ordinary skill in the art would have been motivated to do so because CHESLA recognizes the need to detect anomalous traffic in real time ([CHESLA, para. 0016] “a dynamic network security system detects and filters malicious traffic entering a protected network. The security system uses adaptive fuzzy logic algorithms to analyze traffic patterns in real-time, in order to detect anomalous traffic patterns indicative of an attack.”).
Regarding claims 6 and 29, RADINSKY-MEDVEDOVSKY-CHESLA teach all limitations of claims 5 and 27. MEDVEDOVSKY further teaches “wherein building the set of WPBFs further comprises: vectoring a set of paraphrases derived from the received transactions during a time window into paraphrase vectors; and buffering the paraphrase vectors to provide the WPBFs. ([MEDVEDOVSKY, para. 0098] “FIG. 3 shows an example diagram of an IIR LFR 300 for computing a short-term baseline. During peacetime, a feeder 310 feeds all samples of the HTTPS request rate to a circular buffer 320 to feed an IIR LPF 330. …The outputs of the IIR LPF 330 are fed to another circular buffer 340 to proceed with the IIR LPF recursive operation. The immediate output value is assigned to the short-term baseline Y(t).”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
Claims 8 and 31are rejected under 35 U.S.C. 103 as being unpatentable over RADINSKY-MEDVEDOVSKY in view of JOHNSON (US-20050265233-A1).
Regarding claims 8 and 31, RADINSKY-MEDVEDOVSKY teach all limitations of claims 7 and 30. MEDVEDOVSKY further teaches “further comprises: computing paraphrase values mean occurrences for the BPBFs for a current time window based on an average of occurrences for paraphrase values in the BPBFs computed for a previous time window, a total of occurrences for paraphrase values in the WPBFs for a current time window, ([MEDVEDOVSKY, para. 0060] “for each sample, traffic features are estimated. This includes estimating, for example, the total number of HTTPS requests, total volume (bytes) of HTTPS requests, total volume (bytes) of HTTPS responses”) ([MEDVEDOVSKY, para. 0096] “In an embodiment, each buffer is a dedicated cyclic FIFO buffer for keeping several last samples of input/output. Initially, the buffers are filled with a padding value, which is the average value of several previous samples or the first valid sample”) ([MEDVEDOVSKY, para. 0098] “During peacetime, a feeder 310 feeds all samples of the HTTPS request rate to a circular buffer 320 to feed an IIR LPF 330. The IIR LPF 330 continually produces the short-term baseline and the prediction of the next sample. The outputs of the IIR LPF 330 are fed to another circular buffer 340 to proceed with the IIR LPF recursive operation”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
However, RADINSKY-MEDVEDOVSKY does not teach “… and an Alpha filter.”.
In analogous teaching JOHNSON teaches “… an Alpha filter.” ([JOHNSON, para. 0036] “the adaptive filter may comprise a Kalman filter. In other embodiments, other adaptive filters may be used. A Kalman filter is a linear, model-based, stochastic, recursive, weighted least-squares estimator. A Kalman filter estimates the state of a system, or part of it, based on the system inputs and outputs. … Kalman filter is advantageously configurable so as to calculate threshold settings in a manner that takes into account natural network variance over time. The usage of a Kalman filter allows the threshold settings to be dynamically varied over time, while at the same time being able to detect abnormal behavior. Such abnormal behavior is detected due to a large variance from the expected connection behavior calculated by the filter.”).
Thus, given the teaching of JOHNSON, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of alpha filters by JOHNSON into a method for learning attack-safe baselines by RADINSKY-MEDVEDOVSKY. One of ordinary skill in the art would have been motivated to do so because JOHNSON recognizes the need to efficiently account for network variance ([JOHNSON, para. 0036] “Kalman filter is advantageously configurable so as to calculate threshold settings in a manner that takes into account natural network variance over time. The usage of a Kalman filter allows the threshold settings to be dynamically varied over time”)
Claims 9 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over RADINSKY-MEDVEDOVSKY-CHESLA in view of O'CONNELL (US-20180191773-A1).
Regarding claims 9 and 32, RADINSKY-MEDVEDOVSKY-CHESLA teach all limitations of claims 5 and 28. MEDVEDOVSKY further teaches “… updating paraphrase value occurrences based on transactions directed to the protected entity during the on-going application-layer attack.” ([MEDVEDOVSKY, para. 0071] “following baseline activities are taken in order to learn the normal behavior of various traffic features. For the rate-base traffic features, a number of HTTPS requests per second (RPS), HTTPS response sizes or volume, and a volume of HTTPS requests for both short-term and long-term baselines is continuously calculated.”) ([MEDVEDOVSKY, para. 0073] “the maxDev(t) is considered as the maximal “legitimate” deviation from the momentary baselines; it is also updated with each new sample.”).
The same motivation to combine RADINSKY with MEDVEDOVSKY as in the rejection of claim 1 applies.
However, RADINSKY-MEDVEDOVSKY-CHESLA does not teach “wherein building the APBFs further comprises: updating the values from the WPBFs into the APBFs; and”.
In analogous teaching O'CONNELL teaches “wherein building the APBFs further comprises: updating the values from the WPBFs into the APBFs; and” ([O'CONNELL, abstract] “classifying each data packet window of the plurality of consecutive data packet windows as a potential attack window if the number of occurrences of any one destination address signature within the data packet window exceeds a destination address signature threshold value”).
Thus, given the teaching of O'CONNELL, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of building APBFs by O'CONNELL into a method for learning attack-safe baselines by RADINSKY-MEDVEDOVSKY-CHESLA. One of ordinary skill in the art would have been motivated to do so because O'CONNELL recognizes the need for an improved system and method for mitigating Distributed Denial of Service (DDoS) attacks. ([O'CONNELL, para. 0005] “what is needed in the art is an improved system and method for mitigating Distributed Denial of Service (DDoS) attacks.”) ([O'CONNELL, para. 0006] “the present invention provides a system and method for mitigating a Distributed Denial of Service (DDoS) attack on a target, such as a network server or an internet website”).
Allowable Subject Matter
Claims 10-13 and 33-36 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, and if all double patenting rejections are overcome.
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
ZHAO (US-9912678-B2): This prior art teaches of method for mitigating a denial of service attack includes determining, for a client, a number of requests being transmitted to a server and determining, for the client, that the number of requests for a time period is greater than a top talker threshold. The method includes classifying the client as a top talker based on the number of requests being greater than the top talker threshold and identifying, for the client, additional requests being transmitted to the server. The method also includes determining whether a number of the additional requests matches one or more attack patterns and preventing one or more of the additional requests from being transmitted to the server if the number of additional requests that matches one or more attack patterns is greater than a first threshold.
JAIN (US-20170180415-A1): This prior art teaches of systems for a two-stage attribution of application layer DDoS attack are provided. In a first table just a hash index is maintained whereas the second stage table keeps the string parameter corresponding to the application layer attribute under attack. A linked list maintains a plurality of rows if there is hash collision in the first table. The second table is aged out and reported periodically with details of large strings.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 AFAQ ALI whose telephone number is (571)272-1571. The examiner can normally be reached Mon - Fri 7:30am - 5:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, ALI SHAYANFAR can be reached at (571) 270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.A./
05/26/2026
/AFAQ ALI/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights