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
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after a Notice of Allowance. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/18/2026 has been entered.
Claims 1, 3, 4, 9-14, 16, 18, 19, 21, 22, 27-32, 34, 36, and 37 are amended
Objections to claims 16, 19, and 34 have been overcome due to applicant’s amendments.
USC 112(b) rejections for claims 3, 13, 15, 17, 21, 31, 33, and 35 have been overcome due to Applicant’s amendments.
Claims 1-37 are pending
Priority
The present application is a continuation in part of U.S. patent application Ser. No. 18/176,667, filed on Mar. 1, 2023, which 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.
Response to Arguments
Applicant’s arguments filed on 05/18/2026 have been fully considered.
With respect to claim objections for claims 16, 19, and 34. The objection has been overcome due to applicant’s amendments
With respect to USC 112(b) rejection for claims 3, 13, 15, 17, 21, 31, 33, and 35. The rejection has been overcome due to applicant’s amendments.
With respect to the double patenting rejection each of the corresponding claims recite similar/same limitation of the same subject matter as seen in the comparison below. Therefore, the rejection is being maintained. Examiner suggests filing an E-terminal disclaimer to overcome the rejection.
With respect to the USC 102 rejection for claim 1. Applicant has argued that MEDVEDOVSKY fails to teach “computing, during a learning period, at least one baseline using application-layer transactions determined to represent the normal behavior, wherein only application- layer transactions determined to represent normal behavior are used in the computation of the at least one baseline whereby application-layer transactions not determined to represent normal behavior do not contribute to the at least one baseline”. Examiner respectfully disagrees. MEDVEDOVSKY teaches ([MEDVEDOVSKY, para. 0064] “At S220, it is checked if the learning period has elapsed. If so, execution continues with S240; otherwise, at S230, at least one feature baseline is computed for each traffic feature. Then, execution returns to S210 to compute the baselines during the learning period. The learning period may be set to a predefined time window or until enough data is gathered and collected. A baseline is established during peace-time or data is gathered at peace-time, i.e., when no attack traffic is detected.”) ([MEDVEDOVSKY, para. 0060] “At S210, traffic telemetries are estimated. In an embodiment, S210 includes measuring (or sampling) of ingress (from the client to server) traffic and/or egress traffic (from the server to the client) at predefined time intervals (e.g., 1 second). Then, 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. 0027] “over an application-layer cryptographic protocol, such as HTTPS”). As can be seen from these citations MEDVEDOVSKY teaches of computing baselines during a learning period, wherein only application layer transaction representing normal behavior are used to compute the baseline.
With respect to the limitation of “validating the at least one baseline using each of the measured rate- invariant attribute and rate-based attribute, wherein validating is performed upon conclusion of learning period and comprises checking that each of the measured rate- based attribute and the measured rate-invariant attribute meets a respective prescribed condition;” Examiner is now relying on a new reference ANDRIANI to teach this limitation. ANDRIANI teaches ([ANDRIANI, para. 0135] “The production network is protected by a distributed denial of service (DDoS) mitigation module. A baseline is generated of the production network's normal operation.”) ([ANDRIANI, para. 0208] “For example, if a HTTP GET request to the web service 124A normally gets and HTTP response within 200 ms (according to the current baseline), and currently the HTTP response time is 230 ms this may be considered healthy.”) ([ANDRIANI, para. 0325] “Simulator controller 206 launches DDoS attack traffic via simulators 206 against the coordination device 220 on the internal network 120. The coordination device 220 is validated against that particular attack (for example SYN Flood).”) ([ANDRIANI, para. 0328] “During the time the production server (in this example web server 126A) is being tested by the simulators 206 all traffic is monitored by the coordination device 220.”) ([ANDRIANI, para. 0195] “A combination of the following can be varied during testing: Packets per second (PPS). Connections per second (CPS). Kilobits or Megabits per second (Mbps/Kbps) Time of the simulated attack (seconds)”) ([ANDRIANI, para. 0253] “What parameters were set during the test with regards to type of DDoS attack and attack parameters (for example 100 PPS for 10 seconds of SYN flood traffic to port 80)”) ([ANDRIANI, para. 0329] “If the production service (for example web service 124A) or any other server (other than web server 126A, based on monitor controller 200 settings) are deemed to be in an unhealthy status i.e. response time slowed down on the monitor controller 200 baselines (i.e. the response time is now at an unhealthy threshold), or coordination agent 222A (which updated coordination device 220, which updated the monitor controller 200) baselines, have deviated to unhealthy, the attack may be stopped”) ([ANDRIANI, para. 0338] “In step 308, the current baseline is evaluated to understand if the current baseline is healthy or unhealthy. In step 310, regardless of the health status of the target being monitored, the current health status is reported to the monitor controller 200 and the simulator controller 204.”) ([ANDRIANI, para. 0249] “The traffic statistics and other required information is stored (on the coordination device 220 or the production servers 126 (by the coordination agents 222), as appropriate), and then sent back to the monitor controller 200 for evaluation via the coordination device 220 of that particular test.”) ([ANDRIANI, para. 0256] “An overview of how many tests were run (for example SYN flood run 3 times with x, y and z parameters. HTTP Flood run 3 times with x, y and z parameters)”) ([ANDRIANI, para. 0257] “How many tests passed or failed (i.e. if the target service 124E or mail service 124C are vulnerable to DDoS attacks or not) as what the results are, the decision making process of why that was concluded (For example during and HTTP flood”). As can be seen from these citations, ANDRIANI teaches of validating baselines using attributes. The baselines are tested to determine if the current baseline is healthy or unhealthy. Examiner is interpreting testing the baselines based on Kilobits or Megabits per second (Mbps/Kbps) as rate-invariant attribute and testing using Packets per second (PPS) as rate based attribute. Furthermore, Examiner is interpreting the prescribed condition as a determination if the test passed or failed.
Additional arguments are moot in view of new grounds of rejection necessitated by the
claim amendments.
Claim Objections
Claim 28 is objected to because of the following informalities: claim 28 recites the limitation “rate-based represents” Examiner suggests amending this to “rate-based attribute represents”. Appropriate correction is required.
Claims 4 and 22 recite the acronym DDoS without spelling it out in the first instance. Examiner suggests amending this to distributed denial of service (DDoS). Appropriate correction is required.
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 1-37 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 1, 5, 19, 23, and 37 recite the limitation “the measured rate-based attribute”. However, the claim previously recites “measuring values of a rate-based attribute”. Examiner suggests amending this limitation to recite “the measured rate-based attribute values”. Appropriate correction is required.
Claims 2-18, 20-36 depend on claims 1 and 19. Therefore, they also inherit the rejection.
Claims 1, 19, and 37 recite the limitation “the measured rate-invariant attribute”. However, the claim previously recites “measuring values of … a rate-invariant attribute”. Examiner suggests amending this to “the measured rate-invariant attribute values”. Appropriate correction is required.
Claims 2-18, 20-36 depend on claims 1 and 19. Therefore, they also inherit the rejection.
Claims 1, 19, and 37 recite the limitation “measuring values of a rate-based attribute and a rate-invariant attribute”. It is unclear if the plurality of values are referring to both values of rate-based attribute and values of a rate-invariant attribute or only to values of a rate-based attribute. Examiner suggests amending this limitation to “measuring values of a rate-based attribute and values of a rate-invariant attribute”. Appropriate correction is required.
Claims 2-18, 20-36 depend on claims 1 and 19. Therefore, they also inherit the rejection.
Claims 1, 5-7, 10, 19, 23-25, 28, and 37 recite the limitation “represent normal behavior” and “represents a normal behavior”. However, claim 1 already recites of “received application-layer transactions represent a normal behavior”. Examiner suggests amending this limitation to recite “represent the normal behavior” to refer to the same normal behavior throughout the claims. Appropriate correction is required.
Claims 2-18, 20-36 depend on claims 1 and 19. Therefore, they also inherit the rejection.
Claims 1, 11, 19, 29, and 37 recite the limitation “wherein validating”. Examiner suggests amending this to recite “wherein the validating”. Appropriate correction is required.
Claims 2-18, 20-36 depend on claims 1 and 19. Therefore, they also inherit the rejection.
Claims 1, 19, and 37 recite the limitation “upon conclusion of learning period”. Examiner suggests amending this to recite “upon conclusion of the learning period”. Appropriate correction is required.
Claims 2-18, 20-36 depend on claims 1 and 19. Therefore, they also inherit the rejection.
Claims 6 and 24 recite the limitation “comparing the measured rate-based attribute to a first threshold” and “wherein a measured rate-based attribute above the first threshold”. Examiner suggests amending this to recite “comparing the measured rate-based attribute values to a first threshold” and “wherein a measured rate-based attribute value above the first threshold”. To clearly indicate it is the values being compared and if a single value is above the threshold, it represents an abnormal behavior. Appropriate correction is required.
Claims 7-10 and 25-28 depend on claims 6 and 24. Therefore, they also inherit the rejection.
Claims 7 and 25 recite the limitation “if the measured rate-based attribute has changed” and “wherein a measured rate-based attribute that has not changed”. Examiner suggests amending this to “if a measured rate-based attribute value of the measured rate-based attribute values has changed” and “wherein a measured rate-based attribute value that has not changed”. Appropriate correction is required.
Claims 8-10 and 26-28 depend on claims 7 and 25. Therefore, they also inherit the rejection.
Claims 8 and 26 recite the limitation “determining if the measured rate-based attribute has changed”. Examiner suggests amending this to “determining if a measured rate-based attribute value of the measured rate-based attribute values has changed”. Appropriate correction is required.
Claims 9-13 and 27-31 recite the limitation “a/the measured rate-based attribute” and “the measured rate-invariant attribute”. Examiner suggests amending the limitation of rate-based attribute to “a measured rate-based attribute value of the measured rate-based attribute values” and the limitation of rate-invariant to “a measured rate-invariant attribute value of the measured rate-invariant attribute values”. The claims currently recite of checking if measured rate-based attribute represents normal or abnormal behavior. However, measured rate-based attribute refers to multiple values. To check if there is abnormality only a single value needs to be checked. For example as seen in figure 11 of the drawings a single RPS value at T1 is used to determine that learning should be paused. Appropriate correction is required.
Claims 8 and 26 recite the limitation “an anomaly factor”. However, claims 7 and 25 already recite of an anomaly factor. Examiner suggests amending this claim to recite “the anomaly factor”. Appropriate correction is required.
Claim 10 recites “re-initiating the learning when”. However, claim 9 recites “pausing baseline computing”. Examiner suggests amending this limitation to recite “re-initiating the baseline computing when”. Appropriate correction is required.
Claims 12 and 30 recite the limitation “a measured rate-invariant attribute”. However, claim 1 already recites of measuring a rate-invariant attribute. Examiner suggests amending this limitation to “the measured rate-invariant attribute”. Appropriate correction is required.
Claims 13 and 31 depend on claims 12 and 30. Therefore, they also inherit the rejection.
Claim 13 and 31 recite the limitation “at least one of the prescribed conditions”. However, claim 1 only recites of a single prescribed condition. Examiner suggests amending this to just “the prescribed condition”. Appropriate correction is required.
Claims 15 and 33 recite the limitation “wherein a paraphrase value”. However, the claim already recites “the paraphrase includes at least one paraphrase value”. Examiner suggests amending this limitation to recite “wherein the paraphrase value”. 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, 2, 5-13, 16-20, 23-31, and 34-37 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-10 and 14-17of copending Application No. 18/398997 (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/398,985
copending Application No. 18/398997
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, during a learning period, at least one baseline using application-layer transactions determined to represent the normal behavior, wherein only application- layer transactions determined to represent normal behavior are used in the computation of the at least one baseline whereby application-layer transactions not determined to represent normal behavior do not contribute to the at least one baseline; validating the at least one baseline using each of the measured rate- invariant attribute and rate-based attribute, wherein validating is performed upon conclusion of learning period and comprises checking that each of the measured rate- based attribute and the measured rate-invariant attribute meets a respective prescribed condition; and triggering a mitigation action for application-layer transactions determined to deviate from the at least one baseline.
1.) A method for learning attack-safe baseline, 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; and validating the at least one computed baseline using the measured rate-invariant attribute and rate-based attribute.
17.) The method of claim 1, wherein the attack-safe baselines are utilized for detecting application-layer flood denial-of-service (DDOS) attacks carried by attackers utilizing advanced application layer flood attack tools.
2.) The method of claim 1, wherein computing the at least one baseline is performed during time windows.
14.) The method of claim 1, wherein further comprising: computing the at least one baseline during time windows.
5.) The method of claim 1, wherein determining if the received application-layer transactions represent a normal behavior, further comprises: providing an initial assessment of the measured rate-based attribute.
2.) The method of claim 1, wherein determining if the received application-layer transactions represent a normal behavior, further comprises: providing an initial assessment of the measured rate-based attribute.
6.) The method of claim 5, wherein determining if the received application-layer transactions represent a normal behavior, further comprises: comparing the measured rate-based attribute to a first threshold and a second threshold, wherein the first threshold represents a maximum value for the rate-based attribute and the second threshold represents a minimum value for the rate-based attribute, wherein a measured rate-based attribute above the first threshold represents an abnormal behavior.
3.) The method of claim 2, wherein determining if the received application-layer transactions represent a normal behavior, further comprises: comparing the measured rate-based attribute to a first threshold and a second threshold, wherein the first threshold represents a maximum value for the rate-based attribute and the second threshold represents a minimum value for the rate-based attribute, wherein a measured rate-based attribute above the first threshold represents an abnormal behavior.
7.) The method of claim 6, further comprising: determining if the measured rate-based attribute has changed by an anomaly factor, wherein a measured rate-based attribute that has not changed by the anomaly factor represents a normal behavior.
4.) The method of claim 2, further comprising: determining if the measured rate-based attribute has changed by an anomaly factor, wherein a measured rate-based attribute that has not changed by the anomaly factor represents a normal behavior.
8.) The method of claim 7, wherein determining if the measured rate-based attribute has changed by an anomaly factor, further comprises: checking if a current measured value of the rate-based attribute changes from its average measured value by the anomaly factor.
5.) The method of claim 4, wherein determining if the measured rate-based attribute has changed by an anomaly factor, further comprises: checking if a current measured value of the rate-based attribute changes from its respective average value by the anomaly factor.
9.) The method of claim 7, further comprising: pausing baseline learning when a received measured rate-based represents an abnormal behavior.
6.) The method of claim 4, further comprising: pausing the baseline learning when a received measured rate-based represents an abnormal behavior.
10.) The method of claim 7, further comprising: re-initiating the learning process when a received measured rate-based represents a normal behavior.
7.) The method of claim 4, further comprising: re-initiating the baseline learning when a received measured rate-based represents a normal behavior.
11.) The method of claim 1, wherein validating the computed rate-based baseline further comprises: determining if a preconfigured active learning period has been completed, wherein the preconfigured active learning period includes durations or a number of transactions received during which application-layer transactions determined to represent the normal behavior utilized to compute the at least one baseline; and determining if a quality learning condition has been met.
8.) The method of claim 1, wherein validating the computed rate-based baseline further comprises: determining if a preconfigured active learning period has been completed, wherein the preconfigured active learning period includes durations or a number of transactions received during which application-layer transactions determined to represent the normal behavior utilized to compute the at least one baseline; and determining if a quality learning condition has been met.
12.) The method of claim 11, wherein the determining if a quality learning condition includes checking if a measured rate-invariant attribute is higher than a rate-invariant quality threshold and a measured rate-based attribute is higher than a rate-based quality threshold.
9.) The method of claim 8, wherein the determining if a quality learning condition includes checking if a measured rate-invariant attribute is higher than a rate-invariant quality threshold and a measured rate-based attribute is higher than a rate-based quality threshold.
13.) The method of claim 12, further comprising: determining that the baseline cannot be established for the protected entity when the at least one computed baseline learned has not met at least one quality learning condition.
10.) The method of claim 9, further comprising: determining that the baseline cannot be established for the protected entity when the at least one computed baseline learned has not met at least one quality learning condition.
16.) The method of claim 1, wherein application-layer transactions include any one of: HTTP requests, HTTP responses, HTTPs requests, and HTTPs responses.
15.) The method of claim 1, wherein application-layer transactions include any one of: HTTP requests, HTTP responses, HTTPs requests, and HTTPs responses.
17.) The method of claim 16, wherein application-layer transactions include samples of the actual HTTP requests, their corresponding HTTP responses, wherein a sampling rate of the actual HTTP requests differs as a function of the protected entity incoming traffic volumes.
16.) The method of claim 15, wherein application-layer transactions include samples of the actual HTTP requests, their corresponding HTTP responses, wherein a sampling rate of the actual HTTP requests differs as a function of the protected entity incoming traffic volumes.
18.) The method of claim 1, wherein the attack-safe baselines are utilized for the characterization and mitigation of application layer flood denial-of-service (DDoS) attacks carried by attackers utilizing advanced application layer flood attack tools.
17.) The method of claim 1, wherein the attack-safe baselines are utilized for detecting application-layer flood denial-of-service (DDOS) attacks carried by attackers utilizing advanced application layer flood attack tools.
Claims 19, 20, 23-31, and 34-37 are parallel claims therefore the double patenting rejection for claims 19, 20, 23-31, and 34-37 is similar to the rejection of claims 1, 2, 5-13, 16-18.
Claims 1, 19, and 37 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 6 of copending Application No. 18/400391 (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/398,985
Copending Application No. 18/400391
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, during a learning period, at least one baseline using application-layer transactions determined to represent the normal behavior, wherein only application- layer transactions determined to represent normal behavior are used in the computation of the at least one baseline whereby application-layer transactions not determined to represent normal behavior do not contribute to the at least one baseline; validating the at least one baseline using each of the measured rate- invariant attribute and rate-based attribute, wherein validating is performed upon conclusion of learning period and comprises checking that each of the measured rate- based attribute and the measured rate-invariant attribute meets a respective prescribed condition; and triggering a mitigation action for application-layer transactions determined to deviate from the at least one baseline.
1.) A method for detecting encrypted distributed denial of service (DDOS) attacks comprising: monitoring encrypted transactions related traffic; deriving from the encrypted transactions rate-based parameters and rate-invariant parameters, wherein the rate-based parameters and rate-invariant parameters are associated with transport layer security (TLS) fingerprints; comparing values of the rate-based parameters and the rate-invariant parameters respectively to at least one rate-based anomaly threshold and at least one rate-invariant anomaly threshold; and declaring a detected encrypted DDOS attack when both the rate-based anomaly threshold and the rate-invariant anomaly threshold are exceeded.
6. The method of claim 1, further comprising: establishing normal baselines for the rate-based parameters and the rate-invariant parameters based on transactions'-related traffic monitored during peacetime.
Claims 19, and 37 are parallel claims therefore the double patenting rejection for claims 19, 24, and 27 is similar to the rejection of claims 1 and 6.
Claims 1, 14, 16, 17, 32, 34, 35, and 37 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3, 18, and 19 of copending Application No. 18/058482 (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/398,985
copending Application No. 18/058482
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, during a learning period, at least one baseline using application-layer transactions determined to represent the normal behavior, wherein only application- layer transactions determined to represent normal behavior are used in the computation of the at least one baseline whereby application-layer transactions not determined to represent normal behavior do not contribute to the at least one baseline; validating the at least one baseline using each of the measured rate- invariant attribute and rate-based attribute, wherein validating is performed upon conclusion of learning period and comprises checking that each of the measured rate- based attribute and the measured rate-invariant attribute meets a respective prescribed condition; and triggering a mitigation action for application-layer transactions determined to deviate from the at least one baseline.
1.) A method for detecting application layer flood denial-of-service (DDoS) attacks carried by attackers utilizing advanced application layer flood attack tools, comprising: processing application-layer transactions received during a current time window to detect a rate-based anomaly in a traffic directed to a protected entity; processing the received application-layer transactions to determine rate-invariant anomaly based on a plurality of Application Attributes (AppAttributes) observed in the application-layer transactions received during the current time window, wherein the rate-invariant anomaly is determined based on a continuously updated baseline of AppAttributes, wherein AppAttributes represent the applicative behavior of the protected entity modeled based on the application-layer transactions; determining based on a detected rate-based anomaly and a detected rate-invariant anomaly if an application layer flood DDoS is present in the current time window; and causing a mitigation action when the application layer flood DDoS is present.
2.) … computing a current rate-based parameter for the current time window as a number of incoming transactions per second received during the time window; computing at least one rate-base baseline, each of the one rate-base baseline is computed using an alpha filter configured to a specific time period;
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.
3.) The method of claim 1, further comprising: buffering, in window buffers, AppAttributes derived from application-layer transactions received during the current time window.
16.) The method of claim 1, wherein application-layer transactions include any one of: HTTP requests, HTTP responses, HTTPs requests, and HTTPs responses.
18.) The method of claim 1, wherein application-layer transactions include any one of: HTTP requests, HTTP responses, HTTPs requests, and HTTPs responses.
17.) The method of claim 16, wherein application-layer transactions include samples of the actual HTTP requests, their corresponding HTTP responses, wherein a sampling rate of the actual HTTP requests differs as a function of the protected entity incoming traffic volumes.
19.) The method of claim 18, wherein application-layer transactions include samples of the actual HTTP requests, their corresponding HTTP responses and HTTPs requests, and their corresponding HTTPs responses, wherein the sampling rate can be different for peace time and attack time scenarios.
Claims 19, 32, 34, 35, and 37 are parallel claims therefore the double patenting rejection for claims 19, 32, 34, 35, and 37 is similar to the rejection of claims 1, 14, 16, and 17.
Claims 1, 14, 19, 32, and 37 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 4 and 8 of copending Application No. 18/176667 (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/398,985
copending Application No. 18/176667
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, during a learning period, at least one baseline using application-layer transactions determined to represent the normal behavior, wherein only application- layer transactions determined to represent normal behavior are used in the computation of the at least one baseline whereby application-layer transactions not determined to represent normal behavior do not contribute to the at least one baseline; validating the at least one baseline using each of the measured rate- invariant attribute and rate-based attribute, wherein validating is performed upon conclusion of learning period and comprises checking that each of the measured rate- based attribute and the measured rate-invariant attribute meets a respective prescribed condition; and triggering a mitigation action for application-layer transactions determined to deviate from the at least one baseline.
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; and performing mitigation of the ongoing application-layer attack based on the generated application-layer signature.
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.
4.) The method of claim 2, further comprising: sampling transactions received during a time window; and 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 normal behavior.
Claims 19, 32, and 37 are parallel claims therefore the double patenting rejection for claims 19, 21, 32, and 37 is similar to the rejection of claims 1, 3, and 14.
Claims 1, 19, and 37 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. US 11503052. 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/398,985
U.S. Patent No. US 11503052
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, during a learning period, at least one baseline using application-layer transactions determined to represent the normal behavior, wherein only application- layer transactions determined to represent normal behavior are used in the computation of the at least one baseline whereby application-layer transactions not determined to represent normal behavior do not contribute to the at least one baseline; validating the at least one baseline using each of the measured rate- invariant attribute and rate-based attribute, wherein validating is performed upon conclusion of learning period and comprises checking that each of the measured rate- based attribute and the measured rate-invariant attribute meets a respective prescribed condition; and triggering a mitigation action for application-layer transactions determined to deviate from the at least one baseline.
1.) A method for detecting anomalous hypertext transfer protocol secure (HTTPS) traffic, comprising: receiving samples of at least rate-based features, wherein the rate-based features demonstrate a normal behavior of at least HTTPS traffic directed to a protected entity; setting a first Infinite impulse response (IIR) low pass filter (LPF) to compute the short-term baseline; setting a second IIR LPF to compute the long-term baseline; computing the short-term baseline and the long-term baseline based on the received samples, wherein the short-term baseline is adapted to relatively rapid changes in the HTTPS traffic and the long-term baseline is adapted to relatively slow changes in the HTTPS traffic; computing at least one short-term threshold based on the short-term baseline and at least one long-term threshold based on the long-term baseline; evaluating each of the at least one threshold against real-time samples of HTTPS traffic to determine whether behavior of the HTTPS traffic is anomalous; and generating an alarm when anomaly is detected.
Claims 19, and 37 are parallel claims therefore the double patenting rejection for claims 19, and 37 is similar to the rejection of claim 1.
Claims 1, 19, and 37 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. US 11563772 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/398,985
U.S. Patent No. US 11563772 B2
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, during a learning period, at least one baseline using application-layer transactions determined to represent the normal behavior, wherein only application- layer transactions determined to represent normal behavior are used in the computation of the at least one baseline whereby application-layer transactions not determined to represent normal behavior do not contribute to the at least one baseline; validating the at least one baseline using each of the measured rate- invariant attribute and rate-based attribute, wherein validating is performed upon conclusion of learning period and comprises checking that each of the measured rate- based attribute and the measured rate-invariant attribute meets a respective prescribed condition; and triggering a mitigation action for application-layer transactions determined to deviate from the at least one baseline.
1.) A method for protecting against quick user datagram protocol (UDP) Internet connection (QUIC) based denial-of-service (DoS) attacks, comprising: extracting traffic features from QUIC traffic directed to a protected entity, wherein the traffic features indicate behavior specifically of the QUIC traffic directed to the protected entity, wherein the extracted traffic features include at least one rate-based feature for the QUIC traffic and at least one rate-invariant feature for the QUIC traffic, and wherein the QUIC traffic is comprised of QUIC packets; computing at least one baseline for each respective one of the at least one rate-based feature for the QUIC traffic and the at least one rate-invariant feature for the QUIC traffic; and analyzing real-time samples of traffic directed to the protected entity subsequent to computing the at least one baseline for each respective one of the at least one rate-based feature and the at least one rate-invariant feature to detect a deviation from each respective one of the at least one computed baseline, wherein the deviation is indicative of a detected QUIC DoS attack; and causing execution of at least one mitigation action when an indication of the detected QUIC DoS attack is determined.
Claims 19, and 37 are parallel claims therefore the double patenting rejection for claims 19, and 37 is similar to the rejection of claim 1.
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, 2, 4, 5, 11, 14-20, 22, 23, 29, and 32-37 are rejected under 35 U.S.C. 103 as being unpatentable over MEDVEDOVSKY (US-20210194903-A1) in view of ANDRIANI (US-20180046811-A1), hereinafter MEDVEDOVSKY-ANDRIANI.
Regarding claim 1, MEDVEDOVSKY teaches “A method for learning attack-safe baselines, comprising: ([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”) receiving application-layer transactions directed to a protected entity; ([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”) measuring values of a rate-based attribute and a rate-invariant attribute from the received application-layer transactions; ([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 measured rate-based attribute, if the received application-layer transactions represent a normal behavior; ([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 to”) computing, during a learning period, at least one baseline using application-layer transactions determined to represent the normal behavior, wherein only application- layer transactions determined to represent normal behavior are used in the computation of the at least one baseline whereby application-layer transactions not determined to represent normal behavior do not contribute to the at least one baseline; ([MEDVEDOVSKY, para. 0064] “At S220, it is checked if the learning period has elapsed. If so, execution continues with S240; otherwise, at S230, at least one feature baseline is computed for each traffic feature. Then, execution returns to S210 to compute the baselines during the learning period. The learning period may be set to a predefined time window or until enough data is gathered and collected. A baseline is established during peace-time or data is gathered at peace-time, i.e., when no attack traffic is detected.”) ([MEDVEDOVSKY, para. 0060] “At S210, traffic telemetries are estimated. In an embodiment, S210 includes measuring (or sampling) of ingress (from the client to server) traffic and/or egress traffic (from the server to the client) at predefined time intervals (e.g., 1 second). Then, 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. 0027] “over an application-layer cryptographic protocol, such as HTTPS”) … and triggering a mitigation action for application-layer transactions determined to deviate from the at least one baselines.” ([MEDVEDOVSKY, para. 0072] “At S240, after baselining of the various rate-base and rate-invariant traffic features, various deviations from these baselines are to be detected as traffic anomalies.”) ([MEDVEDOVSKY, para. 0077] “An anomaly is detected as a deviation from one of the short-term or long-term baselines. When using the maxDev as a baseline threshold, each sample is compared with baseline threshold U(t). An alert is generated, when samples exceed the threshold several times in a row, triggering an alarm.”) ([MEDVEDOVSKY, para. 0091] “At S270 at least one mitigation action is executed on each client device determined to be an attack tool. The mitigation action may include generating alerts”) ([MEDVEDOVSKY, para. 0092] “As noted above, an HTTPS flood DDoS attack is detected responsive to a short-term baseline, a long-term baseline, or both.”).
However, MEDVEDOVSKY does not teach “validating the at least one baseline using each of the measured rate- invariant attribute and rate-based attribute, wherein validating is performed upon conclusion of learning period and comprises checking that each of the measured rate- based attribute and the measured rate-invariant attribute meets a respective prescribed condition;”.
In analogous teaching ANDRIANI teaches “validating the at least one baseline using each of the measured rate- invariant attribute and rate-based attribute, wherein validating is performed upon conclusion of learning period and comprises checking that each of the measured rate- based attribute and the measured rate-invariant attribute meets a respective prescribed condition;”. ([ANDRIANI, para. 0135] “The production network is protected by a distributed denial of service (DDoS) mitigation module. A baseline is generated of the production network's normal operation.”) ([ANDRIANI, para. 0208] “For example, if a HTTP GET request to the web service 124A normally gets and HTTP response within 200 ms (according to the current baseline), and currently the HTTP response time is 230 ms this may be considered healthy.”) ([ANDRIANI, para. 0325] “Simulator controller 206 launches DDoS attack traffic via simulators 206 against the coordination device 220 on the internal network 120. The coordination device 220 is validated against that particular attack (for example SYN Flood).”) ([ANDRIANI, para. 0328] “During the time the production server (in this example web server 126A) is being tested by the simulators 206 all traffic is monitored by the coordination device 220.”) ([ANDRIANI, para. 0195] “A combination of the following can be varied during testing: Packets per second (PPS). Connections per second (CPS). Kilobits or Megabits per second (Mbps/Kbps) Time of the simulated attack (seconds)”) ([ANDRIANI, para. 0253] “What parameters were set during the test with regards to type of DDoS attack and attack parameters (for example 100 PPS for 10 seconds of SYN flood traffic to port 80)”) ([ANDRIANI, para. 0329] “If the production service (for example web service 124A) or any other server (other than web server 126A, based on monitor controller 200 settings) are deemed to be in an unhealthy status i.e. response time slowed down on the monitor controller 200 baselines (i.e. the response time is now at an unhealthy threshold), or coordination agent 222A (which updated coordination device 220, which updated the monitor controller 200) baselines, have deviated to unhealthy, the attack may be stopped”) ([ANDRIANI, para. 0338] “In step 308, the current baseline is evaluated to understand if the current baseline is healthy or unhealthy. In step 310, regardless of the health status of the target being monitored, the current health status is reported to the monitor controller 200 and the simulator controller 204.”) ([ANDRIANI, para. 0249] “The traffic statistics and other required information is stored (on the coordination device 220 or the production servers 126 (by the coordination agents 222), as appropriate), and then sent back to the monitor controller 200 for evaluation via the coordination device 220 of that particular test.”) ([ANDRIANI, para. 0256] “An overview of how many tests were run (for example SYN flood run 3 times with x, y and z parameters. HTTP Flood run 3 times with x, y and z parameters)”) ([ANDRIANI, para. 0257] “How many tests passed or failed (i.e. if the target service 124E or mail service 124C are vulnerable to DDoS attacks or not) as what the results are, the decision making process of why that was concluded (For example during and HTTP flood”)
Thus, given the teaching of ANDRIANI, 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 validating baselines by ANDRIANI into a method for learning attack-safe baselines by MEDVEDOVSKY. One of ordinary skill in the art would have been motivated to do so because ANDRIANI recognizes the need to improve DDoS testing ([ANDRIANI, para. 0010] “With DDoS attacks becoming a more and more common cyber security attack vector, organizations want to make sure that services (CPE/Scrubbing) and strategies deployed are able to withstand an actual DDoS attack.”) ([ANDRIANI, para. 0011] “the present embodiment there is provided a method for testing including the steps of: configuring a coordination device on a production network, the coordination device emulating at least one network service and the production network protected by a distributed denial of service (DDoS) mitigation module”)
Regarding claim 19, this claim recites of a system claim that implements steps of method claim 1. Therefore, claim 19 is rejected in a similar manner as in the rejection of claim 1. MEDVEDOVSKY further teaches of a system ([MEDVEDOVSKY, para. 0013] “Some embodiments disclosed herein include a system for detecting anomalous hypertext transfer protocol secure (HTTPS) traffic.”).
Regarding claim 37, this claim recites of a non-transitory computer-readable medium storing a set of instructions which once executed by a processor performs the steps of method claim 1. Therefore, claim 37 is rejected in a similar manner as in the rejection of claim 1. MEDVEDOVSKY further teaches of a non-transitory computer-readable medium storing a set of instructions ([MEDVEDOVSKY, para. 0128] “The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. … a non-transitory computer readable medium is any computer readable medium”).
Regarding claims 2 and 20, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “wherein computing the at least one baseline is performed during time windows.” ([MEDVEDOVSKY, para. 0064] “execution returns to S210 to compute the baselines during the learning period. The learning period may be set to a predefined time window or until enough data is gathered and collected.”).
Regarding claims 4 and 22, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “generating, using at least one baseline, an application-layer signature designating applicative attributes utilized for characterization of DDoS attacks.” ([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. 0084] “For this feature, a short-term baseline and appropriate MaxDev are computed to determine a normal peace time deviation and cases of anomalies, in a similar means as for other traffic features. This attribute is assumed to be relatively large under attacks, reflecting unproportionally, compared to peace time”)
Regarding claims 5 and 23, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “wherein determining if the received application-layer transactions represent a normal behavior, further comprises: providing an initial assessment of the measured rate-based attribute.” ([MEDVEDOVSKY, para. 0050] “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). Once baselines are determined, the defense system 110 is configured to inspect all 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 to a protected entity”) ([MEDVEDOVSKY, para. 0038] “a deviation from the normal baselines is defined uniquely for the rate-base and rate-invariant features. Such deviation is detected as an abnormal event.”).
Regarding claims 11 and 29, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “wherein validating the at least one baseline further comprises: determining that the learning period has been completed, wherein the learning period includes durations or a number of transactions received during which application-layer transactions determined to represent the normal behavior are utilized to compute the at least one baseline; and” ([MEDVEDOVSKY, para. 0050] “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).”) ([MEDVEDOVSKY, para. 0064] “The learning period may be set to a predefined time window or until enough data is gathered and collected. A baseline is established during peace-time or data is gathered at peace-time, i.e., when no attack traffic is detected”).
ANDRIANI teaches “and determining that the prescribed condition for the measured rate-based attribute has been met.” ([ANDRIANI, para. 0249] “The traffic statistics and other required information is stored (on the coordination device 220 or the production servers 126 (by the coordination agents 222), as appropriate), and then sent back to the monitor controller 200 for evaluation via the coordination device 220 of that particular test.”) ([ANDRIANI, para. 0256] “An overview of how many tests were run (for example SYN flood run 3 times with x, y and z parameters. HTTP Flood run 3 times with x, y and z parameters)”) ([ANDRIANI, para. 0257] “How many tests passed or failed (i.e. if the target service 124E or mail service 124C are vulnerable to DDoS attacks or not) as what the results are, the decision making process of why that was concluded (For example during and HTTP flood”)
The same motivation to modify MEDVEDOVSKY with ANDRIANI as in the rejection of claim 1 applies.
Regarding claims 14 and 32, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “wherein building the at least one baseline further comprises: building a set of baseline paraphrase buffers (BPBFs) from the at least one validated baseline, wherein each BPBF represents a normal behavior of a paraphrase.” ([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. 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.”) ([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.”).
Regarding claims 15 and 33, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 14 and 32. MEDVEDOVSKY further teaches “wherein the paraphrase includes at least one paraphrase value, wherein a paraphrase value represents an applicative attribute in an application-layer 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.”).
Regarding claims 16 and 34, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “wherein application-layer transactions include any one of: hypertext transfer protocol (HTTP) requests, HTTP responses, hypertext transfer protocol secure (HTTPs) requests, and HTTPs responses.” ([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”).
Regarding claims 17 and 35, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “wherein application-layer transactions include samples of actual hypertext transfer protocol (HTTP) requests, and their corresponding HTTP responses and, wherein a sampling rate of the actual HTTP requests differs as a function of the protected entity incoming traffic volumes.” ([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, lists of all requests and their sizes and the source IP generating each request, and lists of all responses and their sizes and the source IP target of each response”) ([MEDVEDOVSKY, para. 0060] “traffic telemetries are estimated. In an embodiment, S210 includes measuring (or sampling) of ingress (from the client to server) traffic and/or egress traffic (from the server to the client) at predefined time intervals”) ([MEDVEDOVSKY, para. 0031] “According to some embodiments, additional traffic features include: 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)”).
Regarding claims 18 and 36, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “wherein the attack-safe baselines are utilized for characterization and mitigation of application layer flood denial-of-service (DDoS) attacks carried by attackers utilizing advanced application layer flood attack tools.” ([MEDVEDOVSKY, para. 0126] “The processing circuitry 510 is configured to detect and cause mitigation of HTTPS flood attacks, and any encrypted DDoS attacks, as described herein.”) ([MEDVEDOVSKY, para. 0092] “an HTTPS flood DDoS attack is detected responsive to a short-term baseline, a long-term baseline, or both.”) ([MEDVEDOVSKY, para. 0091] “At S270 at least one mitigation action is executed on each client device determined to be an attack tool. The mitigation action may include generating alerts, causing the client to perform a challenge, redirecting traffic from the client to a scrubbing center, blocking client traffic, and so on, or a combination thereof.”).
Claims 3 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over MEDVEDOVSKY-ANDRIANI in view of JOHNSON (US-20050265233-A1)
Regarding claims 3 and 21, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 2 and 20. MEDVEDOVSKY further teaches “computing paraphrase values mean occurrences for the baseline paraphrase buffers (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 window paraphrase buffers (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”).
In analogous teaching JOHNSON teaches “… and using 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 MEDVEDOVSKY-ANDRIANI. 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 6-10 and 24-28 are rejected under 35 U.S.C. 103 as being unpatentable over MEDVEDOVSKY-ANDRIANI in view of CHEN (US-20190245875-A1), hereinafter MEDVEDOVSKY-ANDRIANI-CHEN.
Regarding claims 6 and 24, MEDVEDOVSKY-ANDRIANI teaches all limitations of claims 5 and 23. MEDVEDOVSKY further teaches “wherein determining if the received application-layer transactions represent a normal behavior, further comprises: comparing the measured rate-based attribute to a first threshold and a …, wherein the first threshold represents a maximum value for the rate-based attribute … wherein a measured rate-based attribute above the first threshold represents an abnormal behavior.” ([MEDVEDOVSKY, para. 0072] “after baselining of the various rate-base and rate-invariant traffic features, various deviations from these baselines are to be detected as traffic anomalies. In an embodiment, the anomaly detection is performed by dynamic learning, during-peace time, of the typical maximal deviation of traffic from its momentary-computed baseline. States where real time samples of each traffic feature exceed the threshold in amount equal or greater to/from the maximal deviation continuously for some time are considered anomalous.”).
In analogous teaching CHEN teaches “second threshold … the second threshold represents a minimum value for the rate-based attribute” ([CHEN, para. 0107] “a domain name whose quantity of request times is less than a minimum threshold is marked by using an unblocking identifier, a domain name whose quantity of request times is greater than a maximum threshold is marked by using a blocking identifier”).
Thus, given the teaching of CHEN, 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 second threshold by CHEN into a method for learning attack-safe baselines by MEDVEDOVSKY-ANDRIANI. One of ordinary skill in the art would have been motivated to do so because CHEN recognizes the need to improve attack detection ([CHEN, para. 0065] “the accuracy of identifying a DNS attack may be increased, and because the unblocking time may be preset and may be adjusted based on the determining result for the quantity of request times, the efficiency of determining a DNS attack may be increased.”).
Regarding claims 7 and 25, MEDVEDOVSKY-ANDRIANI-CHEN teaches all limitations of claims 6 and 24. MEDVEDOVSKY further teaches “determining if the measured rate-based attribute has changed by an anomaly factor, wherein a measured rate-based attribute that has not changed by the anomaly factor represents a normal behavior.” ([MEDVEDOVSKY, para. 0074] “The maxDev is continuously computed during the learning period and during peace time, as a measurement for the actual legitimate deviation from the momentary baseline of the various traffic features. The maxDev allows for anomaly detection, as it compares the legitimate deviation in traffic (due to legitimate traffic statistics behavior), to deviations caused by malicious activities”) ([MEDVEDOVSKY, para. 0085] “A short-term baseline and appropriate MaxDevthreshold are computed to determine a normal peace-time deviation and cases of anomalies”).
Regarding claims 8 and 26, MEDVEDOVSKY-ANDRIANI-CHEN teaches all limitations of claims 7 and 25. MEDVEDOVSKY further teaches “wherein determining if the measured rate-based attribute has changed by an anomaly factor, further comprises: checking if a current measured value of the rate-based attribute changes from its average measured value by the anomaly factor.” ([MEDVEDOVSKY, para. 0074] “The maxDev allows for anomaly detection, as it compares the legitimate deviation in traffic (due to legitimate traffic statistics behavior), to deviations caused by malicious activities”) ([MEDVEDOVSKY, para. 0077] “An anomaly is detected as a deviation from one of the short-term or long-term baselines. When using the maxDev as a baseline threshold, each sample is compared with baseline threshold U(t). An alert is generated, when samples exceed the threshold several times in a row, triggering an alarm”).
Regarding claims 9 and 27, MEDVEDOVSKY-ANDRIANI-CHEN teaches all limitations of claims 7 and 25. MEDVEDOVSKY further teaches “pausing baseline computing when a measured rate-based attribute represents an abnormal behavior.” ([MEDVEDOVSKY, para. 0102] “At S410, samples of inspected HTTPS traffic are received. The samples of HTTPS traffic may include rate-based and rate-invariant features of HTTPS responses and requests.”) ([MEDVEDOVSKY, para. 0103] “At S420, it is checked if an attack alarm is on. That is, if there is an ongoing attack. If not, the short-term and long-term baselines are computed (or otherwise updated) during peacetime. If there is an on-going attack, execution continues with S480.”).
Regarding claims 10 and 28, MEDVEDOVSKY-ANDRIANI-CHEN teaches all limitations of claims 9 and 27. MEDVEDOVSKY further teaches “re-initiating the learning when a measured rate-based attribute represents a normal behavior.” ([MEDVEDOVSKY, para. 0117] “At S480, a check is made if the current sample ‘X’ is lower than the threshold matrix computed at S470. If so, the attack alarm is set to go off. That is, the attack has terminated.”) ([MEDVEDOVSKY, para. 0103] “At S420, it is checked if an attack alarm is on. That is, if there is an ongoing attack. If not, the short-term and long-term baselines are computed (or otherwise updated) during peacetime. If there is an on-going attack, execution continues with S480.”).
Allowable Subject Matter
Claims 12, 13, 30, and 31 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 other rejections are overcome.
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
MARCK (US-10560466-B2): This prior art teaches of embodiments are provided to allow institutions and individuals the ability to subscribe to notifications regarding DDoS attacks on certain types of institutions, e.g., institutions that fall into certain market verticals or categories. Subscriber data can be integrated with an attack monitoring platform (AMP), which can push out certain information to a system, which tabulates and analyzes the information regarding attacks. If an attack is detected based on predefined thresholds and conditions, a database lookup is performed and a notification that contains certain attack attributes can be sent out to the appropriate subscribers. Subscribers can also be provided with a mechanism to modify their level of DDoS attack notification threshold.
JAIN (US-20190289032-A1): This prior art teaches of systems and methods for mitigating DDoS attacks utilizing NTP are provided. According to one embodiment, a tracking table is maintained by a network security device protecting a private network. The tracking table contains information regarding NTP requests originated by clients of the private network and observed by the network security device. An NTP request sent from a client to an NTP server external to the private network is intercepted by the network security device. An NTP request flooding attack on the NTP server by the first client is mitigated by the network security device by: (i) determining based on the tracking table whether a prior NTP request directed to the NTP server and for which an NTP response has yet to be received was sent by the client within a predetermined or configurable time period of the NTP request; and (ii) when said determining is affirmative, dropping the NTP request.
Conclusion
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./
06/04/2026
/AFAQ ALI/
Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights