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
Claim objections for claims 1, 19, and 37 has been overcome due to applicant’s amendments
USC 112(b) rejection for claims 3, 15, 17, 21, 33, and 35 has been overcome due to applicant’s amendments.
Claims 1, 3, 10, 15-17, 19, 21, 28, 33, 34, 35, and 37 have been amended
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.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 12/23/2025. 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 12/23/2025 have been fully considered.
With respect to claim objections for claims 1, 19, and 37. The objection has been overcome due to applicant’s amendments
With respect to USC 112(b) rejection for claims 3, 15, 17, 21, 33, and 35. The rejection has been overcome due to applicant’s amendments.
With respect to the USC 101 abstract rejection for claims 1-17 and 19-35, and 37. The rejection has been overcome due to applicant’s amendments and incorporation of the limitation “triggering a mitigation action for application-layer transactions determined to deviate from the baselines”.
With respect to the double patenting rejection each of the corresponding claims recite similar/same limitation of the same subject matter. 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 independent claim 1. Applicant has stated that MEDVEDOVSKY fails to teach of “validating the at least one computed baseline using the measured rate-invariant attribute and rate-based attribute”. Examiner respectfully disagrees. MEDVEDOVSKY teaches ([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. 0070] “each baseline is continuously updated.”) ([MEDVEDOVSKY, para. 0073] “For the given false probability rate, the maxDev(t) is considered as the maximal “legitimate” deviation from the momentary baselines; it is also updated with each new sample.”) ([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.”). As can be seen from these citations MEDVEDOVSKY teaches that baselines are computed and then continuously updated based on new traffic. Updating baselines as new traffic is received is making sure the baselines are valid and correctly represent normal behavior. MEDVEDOVSKY further teaches ([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.”) ([MEDVEDOVSKY, para. 0065] “at least one baseline is continuously computed based on samples of the traffic features to determine normal activity of rate-base and rate-invariant features of the inspected traffic.”). As can be seen from this citation the baselines are continuously validated based on traffic to determine normal activity of rate-base and rate-invariant features. Updating baselines is making sure that the baseline is valid and correctly determines normal activity of rate-base and rate-invariant features of the inspected traffic. Furthermore, the specification of the current application states in para. 0139 “the baseline validation continues as a background process. The validation conditions are checked at predefined time intervals, each 24 hours.”. This is analogous to MEDVEDOVSKY teaching the baselines are continuously determined at peace-time and during predefined learning periods. Therefore, MEDVEDOVSKY teaches this limitation and the rejection is maintained.
With respect to the newly amended limitation of “and triggering a mitigation action for application-layer transactions determined to deviate from the baselines.” MEDVEDOVSKY teaches this limitation ([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.”).
Additional arguments are moot in view of new grounds of rejection necessitated by the
claim amendments.
Claim Objections
Claims 16 and 34 are objected to because of the following informalities: claims 16 and 34 recite of the acronym HTTPs without spelling it out in the first occurrence. Also note that the letter s should be capitalized. For the purpose of examination examiner is interpreting this as Hypertext Transfer Protocol Secure (HTTPS). Appropriate correction is required.
Claim 19 is objected to because it contains a period before the end of the claim, after the new limitation. 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 3, 13, 15, 17, 21, 31, 33, and 35 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 21 recites the limitation "the window paraphrase buffers WPBFs". There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination examiner is interpreting this as “window paraphrase buffers (WPBFs)”. Appropriate correction is required.
Claims 13 and 31 recites the limitation “the baseline". There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination examiner is interpreting this as “the at least one baseline”. Appropriate correction is required.
Claims 1, 19, and 37 recites the limitation “deviate from the baselines". There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination examiner is interpreting this as “deviate from the set of baselines”. Appropriate correction is required.
Claims 2-18, 20-26 depend on claims 1 and 19. Therefore, they also inherit the rejection.
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 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.
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, 6, 19, 24, 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 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.
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.
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.
1.) …. 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.
Claims 19, 24, 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 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.
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, 3, 14, 19, 21, 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 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.
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.
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.
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.
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; 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.
Claims 19, 21, 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 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.
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 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.
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 § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, 4, 5, 14-20, 22, 23, and 32-37 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by MEDVEDOVSKY (US-20210194903-A1).
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 at least one baseline using application-layer transactions determined to represent the normal behavior; ([MEDVEDOVSKY, para. 0012] “computing a short-term baseline and a 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”) ([MEDVEDOVSKY, para. 0037] “Any deviation that persists for some time from the normal baseline is detected as an abnormal event. The normal behavior may be represented by normal access patterns of the legitimate user using the client device 120 to access the victim server 130.”) validating the at least one computed baseline using the measured rate-invariant attribute and rate-based attribute; 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). Once baselines are determined, the defense system 110 is configured to inspect all traffic directed to the victim server 130”) ([MEDVEDOVSKY, para. 0070] “each baseline is continuously updated.”) ([MEDVEDOVSKY, para. 0073] “For the given false probability rate, the maxDev(t) is considered as the maximal “legitimate” deviation from the momentary baselines; it is also updated with each new sample.”) ([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.”) ([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.”) ([MEDVEDOVSKY, para. 0065] “at least one baseline is continuously computed based on samples of the traffic features to determine normal activity of rate-base and rate-invariant features of the inspected traffic.”) building a set of baselines based on the at least one validated baseline, wherein the set of baselines are utilized for characterization of distributed denial of service (DDoS) attacks; ([MEDVEDOVSKY, para. 0050] “According to the disclosed embodiments, the defense system 110 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). Once baselines are determined, the defense system 110 is configured to inspect all traffic directed to the victim server 130”) ([MEDVEDOVSKY, para. 0092] “an HTTPS flood DDoS attack is detected responsive to a short-term baseline, a long-term baseline, or both.”) and triggering a mitigation action for application-layer transactions determined to deviate from the 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.”).
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 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 teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “generating, using at least one computed 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 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 14 and 32, MEDVEDOVSKY teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “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.” ([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 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 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, 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 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 teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “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.” ([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.”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over MEDVEDOVSKY in view of JOHNSON (US-20050265233-A1), hereinafter MEDVEDOVSKY-JOHNSON.
Regarding claims 3 and 21, MEDVEDOVSKY 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 the 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. 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 in view of CHEN (US-20190245875-A1), hereinafter MEDVEDOVSKY-CHEN.
Regarding claims 6 and 24, MEDVEDOVSKY 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. 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-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-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-CHEN teaches all limitations of claims 7 and 25. MEDVEDOVSKY further teaches “pausing baseline learning when a received measured rate-based 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-CHEN teaches all limitations of claims 9 and 27. MEDVEDOVSKY further teaches “re-initiating the learning when a received measured rate-based 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.”).
Claims 11 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over MEDVEDOVSKY in view of VASSEUR (US-20180109495-A1), hereinafter MEDVEDOVSKY-VASSEUR.
Regarding claims 11 and 29, MEDVEDOVSKY teaches all limitations of claims 1 and 19. MEDVEDOVSKY further teaches “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” ([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”).
In analogous teaching VASSEUR teaches “determining if a quality learning condition has been met.” ([VASSEUR, para. 0077] “the trained model may then be uploaded at the edge of the local area network. For example, referencing FIG. 4B, server/service 380 may send the computed model to networking device(s) 440 in LAN 320. Although the function of learning is preferably continuous, server/service 380, in this embodiment, specifies a set of criteria (e.g., metrics for model quality) allowing for determining the accuracy of model 495. Metrics such as the rate of false positive (FP), recall, the area under the curve (AUC), etc. may be used to determine model quality. Such metrics can be used in order to determine when a model is accurate enough to be used by local networking device(s) at the edge (e.g., networking device(s) 440) without being updated dynamically”).
Thus, given the teaching of VASSEUR, 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 quality learning condition by VASSEUR 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 VASSEUR recognizes the need for improved network security ([VASSEUR, para. 0080] “the communication traffic may be redirected to server/service 380 from networking device(s) 440 in order to perform continuous learning and update models. This may result in new models being computed and subsequently uploaded to networking device(s) 440, thereby improving accuracy and recall of the model”) ([VASSEUR, para. 0047] “embodiment of the present disclosure in which an isolation network is formed in order to provide improved security”).
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 double patenting, USC 101, and 112(b) rejections are overcome.
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
KHALIMONENKO (US-20190020680-A1): This prior art teaches of methods for detecting distributed denial-of-service (DDoS) attack. An exemplary method includes receiving one or more requests from a first user for a service executing on a server, and generating a first vector associated with the first user comprised of a plurality of characteristics indicative of the first user accessing the service; calculating a comparison between the first vector and a reference vector, wherein the reference vector comprises an averaged distribution of characteristics for a plurality of users accessing the service, and determining that the service is under a denial-of-service attack based on the comparison between the first vector and the reference vector.
JAIN (US-10009373-B2): This prior art teaches of methods for software defined behavioral DDoS attack mitigation are provided. According to one embodiment, a method is provided for mitigating DDoS attacks. A DDoS attack mitigation appliance of multiple mitigation appliances controlled by a DDoS attack mitigation central controller receives DDoS attack mitigation policies through a network connecting the controller and the mitigation appliance. A DDoS attack is mitigated by the mitigation appliance based on the received mitigation policies. The mitigation policies are generated by the controller based on granular behavioral packet rate thresholds estimated based on granular traffic rate information collected from one or more of the multiple mitigation appliances controlled by the controller.
Conclusion
58. 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.
59. 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, Kambiz Zand can be reached on (571)272-3811. 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./
01/23/2026
/AFAQ ALI/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434