Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
Claims 1-4, 7-17, and 20-25 are amended
Claims 1-25 are pending
Priority
This application is a continuation in part of U.S. patent application Ser. No. 18/176,667, filed on Mar. 1, 2023. The 18/176,667 Application claims the benefit of U.S. Provisional Application No. 63/477,522 filed on Dec. 28, 2022. Therefore, the effective filing date of this application is 12/28/2022.
Response to Arguments
Applicant’s arguments filed on 04/23/2026 have been fully considered.
With respect to the claim objections for claims 3, 4, 16, 17, and 24. The objection has been overcome due to Applicant’s filed amendments.
With respect to the USC 112(b) rejection for claims 1-25. All rejections have been overcome except for claims 2-6, 8, 12, 15-19, 21, and 25. The rejection for these claims can be seen below. Examiner suggests overcoming all 112(b) issues.
With respect to the double patenting rejection for claims 1, 2, 13, 14, and 15. A terminal disclaimer has not been filed. Therefore, the rejection is being maintained.
With respect to the USC 101 abstract rejection for claims 1-25. The rejection has been overcome due to Applicant amending the independent claims to recite of “and performing mitigation of an ongoing application-layer attack …”.
With respect to the USC 103 rejection Applicant has argued that ZAVESKY-CHESLA fail to teach of the newly amended limitation of “wherein the application-layer signature is based on a paraphrase that characterizes the structure of a layer-7 transaction”. CHESLA teaches ([CHESLA, para. 0133] “determine as many signatures, i.e., characteristic parameters, of the anomalous traffic, as is possible. The trapping module uses a number of different signature types”) ([CHESLA, para. 0195] “signatures in a logical OR relationship: “source port OR source IP address.”). However, ZAVESKY-CHESLA does not explicitly teach of the application-layer signature is based on a paraphrase that characterizes the structure of a layer-7 transaction. For this reason Examiner is now relying on a new third reference HORELU to better teach this limitation. HORELU teaches ([HORELU, col. 2 Lines 38-49] “Here, application layer refers to the level(s) of communication over which applications communicate over a network. As described in the open systems interconnection (“OSI”) model, the application layer is built upon other levels, and is distinct from, other layers, such as the transport, network, data link, and physical layers. Communication at the application layer typically uses one or more application layer protocols, such as hypertext transfer protocol (“HTTP”), as a means of communicating between applications. These protocols are also built upon lower level protocols, touch as transport control protocol (“TCP”) and Internet Protocol (“IP”).”) ([HORELU, col. 3 Lines 10-16] “The signature generator 114 analyzes properties of application layer network traffic, identifies properties of such traffic that is associated with the DDoS attack, and generates a signature combining one or more of the identified properties. The signature generator 114 selects properties to include in the signature by identifying a combination of properties”) ([HORELU, col. 5 Lines 41-44] “An application layer property, which might also be referred to as a property or attribute, is information related to application layer network traffic or an application to which such traffic is directed.”) ([HORELU, col. 5 Lines 66-67, col. 6 lines 1-2] “These may be useful when analyzing application layer properties. For example, properties such as user-agent, origin, client-peer, client IP, location, and so may be examined in HTTP requests and analyzed to identify attack signatures.”) ([HORELU, col. 6 Lines 66-67, col. 7 lines 1-3] “At 608, the auto-mitigation service generates a signature of traffic that is associated with the DDoS attack. The signature comprises the values of one or more application layer properties identified, at 606, as exhibiting changes in entropy or distribution since the onset of the attack.”). As can be seen from these citations HORELU teaches of paraphrases (application layer properties) that characterize the structure of a layer-7 transaction (HTTP requests). HORELU further clearly shows that the signatures are of application-layer of the open systems interconnection (“OSI”) model. Application layer is layer 7 of the OSI model. Therefore, the combination of ZAVESKY-CHESLA-HORELU teaches all limitations of claim 1. The same arguments apply for parallel independent claims 13 and 14.
As for the amended limitation of “and performing mitigation of an ongoing application-layer attack by filtering incoming application-layer transactions based on the finetuned application-layer signature.” HORELU further teaches ([HORELU, col 1 lines 58-64] “The signature rule can include the signature and one or more actions to take when traffic conforming to the signature is encountered by a web application firewall. The mitigation rule can then be used to configure the web application firewall to block or otherwise manage traffic believed to be associated with the DDoS attack, thereby mitigating the impact of the attack.”) ([HORELU, col 7 lines 4-11] “In at least one embodiment, the system generates a number of candidate signatures, representing different combinations of properties, and evaluates the various candidate signatures. The evaluation comprises determining whether the signature encompasses a sufficient proportion of traffic associated with the period subsequent to the onset of the DDoS attack, and whether the signature excludes a sufficient proportion of traffic associated with the pre-onset period.”) ([HORELU, col 7 lines 17-22] “The mitigation rule may identify, by the signature, traffic that is suspected to be associated with the DDoS attack, in that it is believed to be originated by the entity behind the attack. Traffic is said to match or conform to a signature when the property values specified by the signature are equal to those found in the network traffic.”) ([HORELU, col 7 lines 25-28] “At 612, the mitigation rule is applied to the web application firewall. An auto-mitigation rule, when applied by the web application firewall, can cause the web application firewall to block traffic that conforms to the signature.”). As can be seen from these citations, HORELU teaches of performing mitigating of an ongoing application-layer attack by filtering incoming application-layer transactions based on signatures. Furthermore, HORELU also teaches the signatures are finetuned as seen col 7 lines 4-11 of HORELU where signatures are evaluated. Therefore, HORELU teaches of this newly amended limitation.
With respect to the argument that there is no motivation to combine ZAVESKY-CHESLA. Examiner respectfully disagrees. Both references relate to anomaly signatures and CHESLA recognizes the need to protect networks from attacks ([CHESLA, para. 0002] “Computer networks often face malicious attacks originating from public networks. Such attacks currently include pre-attack probes, worm propagation, network flooding attacks such as denial of service (DoS) and distributed DoS (DDoS) attacks”) ([CHESLA, para. 0016] “In embodiments of the present invention, a dynamic network security system detects and filters malicious traffic entering a protected network”). Therefore, the combination of ZAVESKY-CHESLA is proper.
Additional arguments are moot in view of new grounds of rejection necessitated by the claim amendments.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/12/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement has been considered by the examiner.
Claim Objections
Claims 10 and 23 recite “an set of paraphrase values”. Examiner suggests amending this to “a set of paraphrase values”. 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-25 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, 13, and 14 recites the limitation " the structure of a layer-7 transaction". There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination examiner is interpreting this as “a structure of a layer-7 transaction”. Appropriate correction is required.
Claims 2-12 and 15-25 depend on claims 1 and 14. Therefore, they also inherit the rejection.
Claims 2 and 15 recites the limitation "the past samples". There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination examiner is interpreting this as “the past samples[n]”. Appropriate correction is required.
Claims 3-6 and 15-19 depend on claims 2 and 15. Therefore, they also inherit the rejection.
Claims 8 and 21 recites the limitation " the pre-defined threshold". There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination examiner is interpreting this as “the pre-defined egress threshold”. Appropriate correction is required.
Claims 12 and 25 recites the limitation “the list of legitimate transactions". There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination examiner is interpreting this as “a list of legitimate transactions”. 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, 13, 14, and 15 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 20 and 21 of copending Application No. 18/794,606 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Current application 18/794,620
copending Application No. 18/794,606
1.) A method for finetuning application-layer signatures, comprising:
operating a false negative (FN) feedback process to finetune application-layer signature; and
operating a false positive (FP) feedback process on the application-layer signature finetuned by the FN feedback process to generate a finetuned application-layer signature to reduce a false negative rate, wherein the finetune feedback process is performed while reducing estimated egress traffic below a predefined threshold and an imposed FP rate below a pre-defined FP rate threshold.
20.) The method of claim 1, further comprising:
finetuning application-layer signatures to reduce a false negative rate, while reducing an estimated egress traffic below a RPS attack threshold and an imposed FP rate below a pre-defined FP rate threshold.
21.) The method of claim 20, wherein finetuning the application-layer signatures further comprises:
retrieving a predefined number of attack time samples of past transactions (samples[n]);
generating an initial signature (Sig0[n]) from the past samples;
operating a false negative (FN) feedback process to finetune the Sig0[n] to generate a first finetuned signature Sig1 [n];
operating a false positive (FP) feedback process to finetune the Sig1 [n] to generate a second finetuned signature Sig2[n]; and
iteratively updating the initial signature to values of the Sig2[n] to generate a finetuned application-layer signature used for attack mitigation.
2.) The method of claim 1, further comprising:
retrieving a predefined number of attack time samples of past transactions (samples[n]);
generating an initial signature (Sig0[n]) from the past samples;
operating a false negative (FN) feedback process to finetune the Sig0[n] to generate a first finetuned signature Sig1[n];
operating a false positive (FP) feedback process to finetune the Sig1[n] to generate a second finetuned signature Sig2[n]; and
iteratively updating the initial signature to values of the Sig2[n] to generate a finetuned application-layer signature used for attack mitigation.
21.) The method of claim 20, wherein finetuning the application-layer signatures further comprises:
retrieving a predefined number of attack time samples of past transactions (samples[n]);
generating an initial signature (Sig0[n]) from the past samples;
operating a false negative (FN) feedback process to finetune the Sig0[n] to generate a first finetuned signature Sig1 [n];
operating a false positive (FP) feedback process to finetune the Sig1 [n] to generate a second finetuned signature Sig2[n]; and
iteratively updating the initial signature to values of the Sig2[n] to generate a finetuned application-layer signature used for attack mitigation.
Claims 13-15 are parallel claims to claims 1 and 2. Therefore, they are rejected in a similar manner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 7-14, and 20-25 are rejected under 35 U.S.C. 103 as being unpatentable over ZAVESKY (US-20190354629-A1) in view of CHESLA (US-20040250124-A1), and further in view of HORELU (US-12170688-B1), hereinafter ZAVESKY-CHESLA-HORELU.
Regarding claim 1, ZAVESKY teaches “A method for finetuning … signatures, comprising: ([ZAVESKY, para. 0037] “As just one example, the operations described above with respect to event detection station 150 may alternatively or additionally be performed by a device … a second device may correlate the anomalies to events identified in one or more external data feeds, a third device may create and update anomaly signatures based upon feedback”) operating a false negative (FN) feedback process to finetune … signature; … and ([ZAVESKY, para. 0016] “For instance, the features of the second anomaly may be used as a positive training example for the anomaly signature when the feedback is a positive feedback. Conversely, the features of the second anomaly may be used as a negative training example for the anomaly signature when the feedback is a negative feedback.”) operating a false positive (FP) feedback process on the … signature finetuned by the FN feedback process to generate a finetuned … signature …, ([ZAVESKY, para. 0057] “For example, the features of the second anomaly may comprise a positive training example for the first anomaly signature when the feedback is a positive feedback, and may comprise a negative training example for the first anomaly signature when the feedback is a negative feedback.”)
However, ZAVESKY does not teach of “application-layer signature, wherein the application-layer signature is based on a paraphrase that characterizes the structure of a layer-7 transaction… application-layer signature to reduce a false negative wherein the finetune feedback process is performed while reducing estimated egress traffic below a predefined threshold and an imposed FP rate below a pre-defined FP rate threshold; and performing mitigation of an ongoing application-layer attack by filtering incoming application-layer transactions based on the finetuned application-layer signature”.
In analogous teaching CHESLA teaches “ …. application-layer signature to reduce a false negative ([CHESLA, para. 0133] “determine as many signatures, i.e., characteristic parameters, of the anomalous traffic, as is possible. The trapping module uses a number of different signature types”) ([CHESLA, para. 0195] “signatures in a logical OR relationship: “source port OR source IP address.”) ([CHESLA, para. 0173] “For example, if the narrower combination of signature types A and 1 results in an increase in the degree of attack (D3) above the threshold value, the controller cancels signature type 1 and instead tries the combination of signature types A and 2 (TTL).”) wherein the finetune feedback process is performed while reducing estimated egress traffic below a predefined threshold and an imposed FP rate below a pre-defined FP rate threshold. ([CHESLA, para. 0196] “As a result of the stable positive feedback, at a refine filter step 262, the controller transitions to sub-hierarchy state 166, in which the controller directs filtering module 70 to apply a signature”) ([CHESLA, para. 0197] “The controller remains in sub-hierarchy state 166, and again determines whether the new filter is successful. In this example, the filter is successful, and the system again achieves stable positive feedback, at a positive feedback step 263. The controller therefore attempts to further refine the signature”) ([CHESLA, para. 0172] “At a second level 364 of tree 360, the controller checks whether a degree of attack D2, calculated by FIS module 62 based on the filtered traffic, is less than a threshold value, e.g., 8. A value of D2 less than the threshold value indicates that application of signature A is successfully filtering the attack.”) ([CHESLA, para. 0173] “Alternatively, if the degree of attack remains below the threshold value despite the narrower combination A+1, the controller tries the still narrower combination of signature types A, 1 and 2. This process continues until the narrowest combination of signature type A with types 1, 2 and 3 is found that still gives a satisfactory degree of attack.”).
Thus, given the teaching of CHESLA, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of finetuning and reducing FP and FN based on a threshold by CHESLA into a method for finetuning signatures by ZAVESKY. One of ordinary skill in the art would have been motivated to do so because CHESLA recognizes the need to protect networks from attacks ([CHESLA, para. 0002] “Computer networks often face malicious attacks originating from public networks. Such attacks currently include pre-attack probes, worm propagation, network flooding attacks such as denial of service (DoS) and distributed DoS (DDoS) attacks”) ([CHESLA, para. 0016] “In embodiments of the present invention, a dynamic network security system detects and filters malicious traffic entering a protected network”).
However, ZAVESKY-CHESLA does not teach “wherein the application-layer signature is based on a paraphrase that characterizes the structure of a layer-7 transaction … and performing mitigation of an ongoing application-layer attack by filtering incoming application-layer transactions based on the finetuned application-layer signature”
In analogous teaching HORELU teaches “… wherein the application-layer signature is based on a paraphrase that characterizes the structure of a layer-7 transaction …” ([HORELU, col. 2 Lines 38-49] “Here, application layer refers to the level(s) of communication over which applications communicate over a network. As described in the open systems interconnection (“OSI”) model, the application layer is built upon other levels, and is distinct from, other layers, such as the transport, network, data link, and physical layers. Communication at the application layer typically uses one or more application layer protocols, such as hypertext transfer protocol (“HTTP”), as a means of communicating between applications. These protocols are also built upon lower level protocols, touch as transport control protocol (“TCP”) and Internet Protocol (“IP”).”) ([HORELU, col. 3 Lines 10-16] “The signature generator 114 analyzes properties of application layer network traffic, identifies properties of such traffic that is associated with the DDoS attack, and generates a signature combining one or more of the identified properties. The signature generator 114 selects properties to include in the signature by identifying a combination of properties”) ([HORELU, col. 5 Lines 41-44] “An application layer property, which might also be referred to as a property or attribute, is information related to application layer network traffic or an application to which such traffic is directed.”) ([HORELU, col. 5 Lines 66-67, col. 6 lines 1-2] “These may be useful when analyzing application layer properties. For example, properties such as user-agent, origin, client-peer, client IP, location, and so may be examined in HTTP requests and analyzed to identify attack signatures.”) ([HORELU, col. 6 Lines 66-67, col. 7 lines 1-3] “At 608, the auto-mitigation service generates a signature of traffic that is associated with the DDoS attack. The signature comprises the values of one or more application layer properties identified, at 606, as exhibiting changes in entropy or distribution since the onset of the attack.”) … and performing mitigation of an ongoing application-layer attack by filtering incoming application-layer transactions based on the finetuned application-layer signature.” ([HORELU, col 1 lines 58-64] “The signature rule can include the signature and one or more actions to take when traffic conforming to the signature is encountered by a web application firewall. The mitigation rule can then be used to configure the web application firewall to block or otherwise manage traffic believed to be associated with the DDoS attack, thereby mitigating the impact of the attack.”) ([HORELU, col 7 lines 4-11] “In at least one embodiment, the system generates a number of candidate signatures, representing different combinations of properties, and evaluates the various candidate signatures. The evaluation comprises determining whether the signature encompasses a sufficient proportion of traffic associated with the period subsequent to the onset of the DDoS attack, and whether the signature excludes a sufficient proportion of traffic associated with the pre-onset period.”) ([HORELU, col 7 lines 17-22] “The mitigation rule may identify, by the signature, traffic that is suspected to be associated with the DDoS attack, in that it is believed to be originated by the entity behind the attack. Traffic is said to match or conform to a signature when the property values specified by the signature are equal to those found in the network traffic.”) ([HORELU, col 7 lines 25-28] “At 612, the mitigation rule is applied to the web application firewall. An auto-mitigation rule, when applied by the web application firewall, can cause the web application firewall to block traffic that conforms to the signature.”).
Thus, given the teaching of HORELU, 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 layer-7 signature by HORELU into a method for finetuning signatures by ZAVESKY-CHESLA. One of ordinary skill in the art would have been motivated to do so because HORELU recognizes the need to improve attack detections and mitigation ([HORELU, col. 1 Lines 10-13] “These attacks can be difficult to detect and mitigate because they mimic legitimate network traffic. Accordingly, techniques for detecting and mitigating DDoS attacks can be improved.”) ([HORELU, col. 1 Lines 42-64] “In an example, a technique for responding to a DDoS attack comprises identifying changes to the distribution of properties associated with a web application that is under attack. The changes are analyzed relative to the estimated onset time of the DDoS attack. … The mitigation rule can then be used to configure the web application firewall to block or otherwise manage traffic believed to be associated with the DDoS attack, thereby mitigating the impact of the attack.”)
Regarding claim 13, 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 13 is rejected in a similar manner as in the rejection of claim 1.
Regarding claim 14, this claim recites of a device comprising a processor which executes the steps of method claim 1. Therefore, claim 14 is rejected in a similar manner as in the rejection of claim 1.
Regarding claims 7 and 20, ZAVESKY-CHESLA-HORELU teach all limitations of claims 1 and 14. CHESLA further teaches “wherein the false negative feedback process further comprises: iteratively applying a current signature on past samples, wherein the current signature is a state of a signature being tuned at a current iteration; ([CHESLA, para. 0168] “controller checks whether the non-attack counter has reached a predetermined constant, such as 3 seconds, at a feedback check step 164. If the counter equals the constant, indicating that stable positive (non-attack) feedback has been achieved, the controller transitions to a sub-hierarchy state 166, for refining (i.e., narrowing) of the filtering conditions.”) ([CHESLA, 0169] “In sub-hierarchy state 166, the controller directs filtering module 70 to reduce the restrictiveness of the filtering by additionally applying one or more sub-hierarchy signatures. These sub-hierarchy signatures were determined by trapping module”) ([CHESLA, para. 0196] “at a refine filter step 262, the controller transitions to sub-hierarchy state 166, in which the controller directs filtering module 70 to apply a signature from the sub-hierarchy group, which signature was already identified by trapping module 68”) generating a list of paraphrase vectors representing past samples that have not been blocked by the current signature; ([CHESLA, para. 0196] “the new filter additionally includes a sub-signature for the source IP address signature, resulting in the refined filter: “source port OR (source IP address AND packet size).””) generating a list of missed paraphrase values, wherein missed paraphrase values eliminate blocking of the past samples by the current signature; ([CHESLA, para. 0197] “The controller remains in sub-hierarchy state 166, and again determines whether the new filter is successful. In this example, the filter is successful, and the system again achieves stable positive feedback, at a positive feedback step 263. The controller therefore attempts to further refine the signature (source IP address) already refined with a sub-signature (packet size). At a refine filter step 264, the controller successfully adds a second sub-signature previously determined by trapping module 68, resulting in the further refined filter: “source port OR (source IP address AND packet size AND TTL).””) from the list of missed paraphrase values, iteratively augmenting a current signature with paraphrase values that reduce estimated egress traffic to a value lower than a pre-defined egress threshold and keep an imposed FP rate at a value lower than an FP pre-defined threshold, wherein the false negative feedback process terminates upon meeting a termination condition. ([CHESLA, para. 0197] “At a refine filter step 264, the controller successfully adds a second sub-signature previously determined by trapping module 68, resulting in the further refined filter: “source port OR (source IP address AND packet size AND TTL).””) ([CHESLA, para. 0172] “At a second level 364 of tree 360, the controller checks whether a degree of attack D2, calculated by FIS module 62 based on the filtered traffic, is less than a threshold value, e.g., 8. A value of D2 less than the threshold value indicates that application of signature A is successfully filtering the attack.”) ([CHESLA, para. 0173] “Alternatively, if the degree of attack remains below the threshold value despite the narrower combination A+1, the controller tries the still narrower combination of signature types A, 1 and 2. This process continues until the narrowest combination of signature type A with types 1, 2 and 3 is found that still gives a satisfactory degree of attack.”).
The same motivation to modify ZAVESKY with CHESLA as in the rejection of claim 1 applies.
Regarding claims 8 and 21, ZAVESKY-CHESLA-HORELU teach all limitations of claims 7 and 20. CHESLA further teaches “wherein the termination condition includes at least when the estimated egress traffic decreases below the pre-defined threshold and an imposed FP rate decreases below a pre-defined FP rate threshold. ([CHESLA, para. 0197] “The controller remains in sub-hierarchy state 166, and again determines whether the new filter is successful. In this example, the filter is successful, and the system again achieves stable positive feedback, at a positive feedback step 263. The controller therefore attempts to further refine the signature”) ([CHESLA, para. 0172] “At a second level 364 of tree 360, the controller checks whether a degree of attack D2, calculated by FIS module 62 based on the filtered traffic, is less than a threshold value, e.g., 8. A value of D2 less than the threshold value indicates that application of signature A is successfully filtering the attack.”) ([CHESLA, para. 0173] “Alternatively, if the degree of attack remains below the threshold value despite the narrower combination A+1, the controller tries the still narrower combination of signature types A, 1 and 2. This process continues until the narrowest combination of signature type A with types 1, 2 and 3 is found that still gives a satisfactory degree of attack.”).
The same motivation to modify ZAVESKY with CHESLA as in the rejection of claim 1 applies.
Regarding claims 9 and 22, ZAVESKY-CHESLA-HORELU teach all limitations of claims 7 and 20. CHESLA further teaches “wherein a first finetuned signature Sig1[n] is set to the current signature when the false negative feedback process is terminated. ([CHESLA, para. 0198] “the controller transitions to convergence state 168, at a convergence transition step 266. In the convergence state, the controller directs filtering module 70 to filter using the most recent successful filter, i.e., “source port OR (source IP address AND packet size),” at a convergence state step 267. The controller continues filtering in the convergence state until stable attack stop feedback is achieved, as indicated by the consistency counter.”)
The same motivation to modify ZAVESKY with CHESLA as in the rejection of claim 1 applies.
Regarding claims 10 and 23, ZAVESKY-CHESLA-HORELU teach all limitations of claims 9 and 22. CHESLA further teaches “further comprising: identifying an set of paraphrase values from the Sig1[n] to be included in a second finetuned signature Sig2[n], while keeping the imposed FP rate below a pre-defined FP rate threshold. ([CHESLA, para. 0172] “At a second level 364 of tree 360, the controller checks whether a degree of attack D2, calculated by FIS module 62 based on the filtered traffic, is less than a threshold value, e.g., 8. A value of D2 less than the threshold value indicates that application of signature A is successfully filtering the attack.”) ([CHESLA, para. 0173] “Alternatively, if the degree of attack remains below the threshold value despite the narrower combination A+1, the controller tries the still narrower combination of signature types A, 1 and 2. This process continues until the narrowest combination of signature type A with types 1, 2 and 3 is found that still gives a satisfactory degree of attack.”).
The same motivation to modify ZAVESKY with CHESLA as in the rejection of claim 1 applies.
Regarding claims 11 and 24, ZAVESKY-CHESLA-HORELU teach all limitations of claims 1 and 14. CHESLA further teaches “wherein the false positive feedback process further comprises: generating a set of legitimate groups from a predetermined set of legitimate transactions; ([CHESLA, para. 0135] “When the counter is at its initial, lowest level, the filtering module uses a relatively narrow set of signatures, in order to minimize the likelihood of blocking legitimate traffic (i.e., false positives). As the counter is incremented, as described hereinbelow with reference to step 116, the intensity of filtering provided by the signatures is gradually increased.”) ([CHESLA, para. 0266] “The more specific a signature type is (i.e., the lower the probability of repetition), the more likely the signature type is to block only packets participating in the attack, thereby avoiding false positives.”) ([CHESLA, para. 0267] “Upon entering trap buffers state 152, controller 60 directs trapping module 68 to attempt to determine as many signature types from the hierarchy group as possible. The hierarchy group typically includes the following signature types in the following order, from most specific to least specific:”) identifying a maximum number of non-binary paraphrase values that causes a minimal blocking of legitimate transactions from the set of legitimate groups; ([CHESLA, para. 0280] “Each of these signature types can be used as a stand-alone criterion for filtering attack packets, i.e., independently of any other signature types in the hierarchy group or any other group. Therefore, as filtering module 70 adds more signature types to the filtering in order to increase the level of filtering”) identifying a minimum number of binary paraphrase values that causes a minimal blocking of legitimate transactions from the set of legitimate groups; and ([CHESLA, para. 0281] “A second group of signatures types is the “dependent group,” which includes conditional signature types. … Signatures of types in the dependent group are filtered only in conjunction with their parent signatures in the hierarchy group, i.e., using an “AND” relationship between the parent signature and the dependent signature.”) aggregating the identified non-binary paraphrase values and binary paraphrase values to set final signature Sig2[n]. ([CHESLA, para. 0290] “A third group of signatures types is the “sub-hierarchy group,” which includes signature types that are used in conjunction with signatures of the hierarchy group, in an “AND” relationship.”) ([CHESLA, para. 0197] “The controller remains in sub-hierarchy state 166, and again determines whether the new filter is successful. In this example, the filter is successful, and the system again achieves stable positive feedback, at a positive feedback step 263. The controller therefore attempts to further refine the signature (source IP address) already refined with a sub-signature (packet size). At a refine filter step 264, the controller successfully adds a second sub-signature previously determined by trapping module 68, resulting in the further refined filter “source port OR (source IP address AND packet size AND TTL).””)
The same motivation to modify ZAVESKY with CHESLA as in the rejection of claim 1 applies.
Regarding claims 12 and 25, ZAVESKY-CHESLA-HORELU teach all limitations of claims 11 and 24. CHESLA further teaches “wherein legitimate groups include a set of paraphrase vectors generated from the list of legitimate transactions. ([CHESLA, para. 0135] “The controller directs the filtering module to select the number of signature types to use based on the value of the hierarchy counter. When the counter is at its initial, lowest level, the filtering module uses a relatively narrow set of signatures, in order to minimize the likelihood of blocking legitimate traffic (i.e., false positives). As the counter is incremented, as described hereinbelow with reference to”) ([CHESLA, para. 0199] “Ignoring certain signatures may be desirable, for example, for signature values that are common values for legitimate traffic.”) ([CHESLA, para. 0200] “Packet size. Network flood module 50 is configurable to exclude signatures of the packet size signature type having certain common values. For example, common TCP packet sizes typically include 60 bytes (SYN), 62 bytes (ACK), 66 bytes (SACK), and 74 bytes (SACK).”).
The same motivation to modify ZAVESKY with CHESLA as in the rejection of claim 1 applies.
Allowable Subject Matter
Claims 2-6 and 15-19 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 they overcome any other rejection and objection.
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
ZHAO (US-9912678-B2): This prior art teaches of method for mitigating a denial of service attack includes determining, for a client, a number of requests being transmitted to a server and determining, for the client, that the number of requests for a time period is greater than a top talker threshold. The method includes classifying the client as a top talker based on the number of requests being greater than the top talker threshold and identifying, for the client, additional requests being transmitted to the server. The method also includes determining whether a number of the additional requests matches one or more attack patterns and preventing one or more of the additional requests from being transmitted to the server if the number of additional requests that matches one or more attack patterns is greater than a first threshold.
MARCK (US-20130291107-A1): This prior art teaches of method of mitigating an application distributed denial of service (DDoS) attack on a network includes receiving at an application DDoS mitigation appliance application layer logs, parsing the application layer logs into an application layer forensic file, comparing an entry of the application layer forensic file with a human behavior profile to determine a malicious qualifier associated with an application DDoS attack on the network, parsing the application layer log into a per-source forensic file, comparing an entry of the per-source forensic files with the malicious qualifier to determine a malicious Internet protocol (IP) addresses associated with the application DDoS attack, and providing the malicious IP address to a network device, wherein the network device drops network traffic associated with the application DDoS attack based upon the malicious IP address.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AFAQ ALI whose telephone number is (571)272-1571. The examiner can normally be reached Mon - Fri 7:30am - 5:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, ALI SHAYANFAR can be reached at (571) 270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.A./
08/21/2026
/AFAQ ALI/Examiner, Art Unit 2434
/ALI SHAYANFAR/Supervisory Patent Examiner, Art Unit 2434
Prosecution Insights