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, 7, 9, 13, 14, and 18 have been amended.
Claims 3, 4, 6, 10, 12, 16, 17, and 20 are cancelled.
Claims 21-26 are added new.
Double patenting with respect to co-pending Application No. 18/989,305 has been overcome due to applicant filing an approved terminal disclaimer.
Double patenting with respect to co-pending Application No. 18/896,115 has not been overcome. Applicant is advised to resubmit the terminal disclaimer with a corrected filing date. The current rejected terminal disclaimer lists the filing date as 2024-12-20 however, application 18/896,115 was filed on 2024-09-25.
USC 112(b) rejection for claim 1-20 listed in the non-final mailed on 10/21/25 has been overcome due to applicants’ amendments.
Claims 1, 2, 5, 7-9, 11, 13-15, 18, 19, and 21-26 are pending.
Priority
This application claims no priority. Therefore, the effective filing date is 06/28/2024.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 01/15/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Response to Arguments
Applicant’s arguments filed on 01/20/2026 have been fully considered.
With respect to the Double patenting rejection. The double patenting rejection has been overcome with respect to application 18/989,305 but not with respect to application 18/896,115. Applicant is advised to resubmit a corrected terminal disclaimer.
With respect to the USC 112(b) rejection for claims 1-20 the rejection has been overcome due to applicant’s amendments
With respect to the USC 102 rejection of claim 1. Applicant has amended the claim to recite of features from now cancelled claims 4 and 12. Examiner is now rejecting the claims under USC 103.
Additional arguments are moot in view of new grounds of rejection necessitated by the claim amendments.
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, 14, and 18 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of copending Application No. 18/896,115 (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 No. 18/759,047
copending Application No. 18/896,115
1.) A computing services environment providing computing services to a plurality of recipients via the Internet, the computing services environment comprising: a plurality of web servers providing access to a plurality of domains on behalf of the plurality of recipients; a plurality of network ingress paths receiving a plurality of application-layer request messages, each of the plurality of application-layer request messages being received from a respective source of a plurality of sources via a respective ingress path of the plurality of network ingress paths and being directed to a respective domain of the plurality of domains; an orchestration engine including one or more processors configured to determine a plurality of mitigation policies corresponding with the plurality of network ingress paths based on a classification of a subset of the plurality of application-layer request messages as being sent from a subset of the sources associated with a distributed denial of service attack, the plurality of mitigation policies including one or more rules to prevent a subset of subsequent application-layer request messages from the subset of the sources from reaching one or more components of the computing services environment; and one or more network controllers configured to implement one or more instructions characterizing the plurality of mitigation policies received from the orchestration engine.
1.) A computing services environment providing computing services to a plurality of recipients via the Internet, the computing services environment comprising: a plurality of application gateways receiving a plurality of application-layer request messages from a plurality of sources; an orchestration engine including one or more processors configured to determine a plurality of mitigation policies corresponding with the plurality of application gateways based on a classification of a subset of the plurality of application-layer request messages as being sent from a subset of the sources associated with a distributed denial of service attack; and a plurality of application-layer web application firewalls corresponding to the plurality of application gateways, the plurality of application-layer web application firewalls being configured to transition from a deactivated state to an activated state upon receipt of an instruction from the orchestration engine, the plurality of application-layer web application firewalls in an activated state implementing the mitigation policies prevent a subset of subsequent application-layer request messages from the subset of the sources from reaching one or more components of the computing services environment.
Claims 14 and 18 recite similar limitations of claim 1. Therefore, claims 14 and 18 are rejected in a similar manner.
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-20 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, 14, and 18 recite the limitation " distributed denial of service attack for a domain ". However, the claim originally recites of “directed to a respective domain of the plurality of domains”. It is unclear if the domain recited in the amended limitation is the same respective domain recited in a previous limitation. For the purpose of examination examiner is interpreting this limitation as “distributed denial of service attack for the respective domain”. Examiner further suggests amending “traffic to the domain” to recite “traffic to the respective domain”. Appropriate correction is required.
Claims 2, 5, 7-9, 11, 13, 15, 19, and 21-26 depend on claims 1, 14, and 18. Therefore, they also inherit the rejection.
Claims 1, 14, and 18 recite the limitation “associated with a distributed denial of service attack”. However, the claim recites in a previous amended limitation “an application-layer distributed denial of service attack”. It is unclear if the associated distributed denial of service attack is the same as the application-layer distributed denial of service attack. Examiner suggests amending the claim limitation to recite “associated with the application-layer distributed denial of service attack”. Furthermore, because of the change necessitated to the independent claims 1, 14, and 18, examiner also suggests amending claims 2 and 15 to recite “associated with the application-layer distributed denial of service attack”. Appropriate correction is required.
Claims 2, 5, 7-9, 11, 13, 15, 19, and 21-26 depend on claims 1, 14, and 18. Therefore, they also inherit the rejection.
Claims 1, 5, 7, 11, 14, 18, 19, 22, and 25 recite the limitation “the plurality of mitigation policies”. However, the independent claims 1, 14, and 18 have been amended to recite “a plurality of domain-specific mitigation policies”. Examiner suggests amending all instances of “the plurality of mitigation policies” to “the plurality of domain-specific mitigation policies”. Appropriate correction is required.
Claims 2, 8-9, 13, 15, 21, 23, 24, and 26 depend on claims 1, 14, and 18. Therefore, they also inherit the rejection.
Claims 1, 14, and 18 recite the limitation “the subset of the sources”. However, claims 1, 14, and 18 have been amended to recite of “a subset of the plurality of sources”. Examiner suggests amending this limitation to recite “the subset of the plurality of sources”. Appropriate correction is required.
Claims 2, 5, 7-9, 11, 13, 15, 19, and 21-26 depend on claims 1, 14, and 18. Therefore, they also inherit the rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 5, 9, 11, 13-15, 18, and 21-26 are rejected under 35 U.S.C. 103 as being unpatentable over DORON (US-20180255094-A1) in view of KANG (US-20120151593-A1), and further in view of SMITH (US-20110035469-A1), hereinafter DORON-KANG-SMITH.
Regarding claim 1, DORON teaches “A computing services environment providing computing services to a plurality of recipients via the Internet, the computing services environment comprising: a plurality of web servers providing access to a plurality of domains on behalf of the plurality of recipients; ([DORON, para. 0032] “FIG. 1 is an example network diagram of a multi-cloud architecture 100 utilized to describe the various disclosed embodiments. The multi-cloud architecture 100 includes a plurality of cloud computing platforms 110-1 through 110-N”) ([DORON, para. 0033] “Each of the cloud computing platforms 110-1 through 110-N, and the datacenter 120 executes a protected application 160 which is the protected entity. As noted above, a protected application 160 may be a web application, a cloud hosted application, or any other software application or software resource executed by a server. Examples of a protected application 160 may include an … a content streaming service, a company Website, or any other service or application that can be accessed by a web browser (not shown).”) ([DORON, para. 0042] “The example network diagram 200 illustrates a plurality of end-user devices (EUDs) 210”) ([DORON, para. 0045] “The EUDs 210 are configured to access a protected application 160 … The access to the protected application 160 is through a network, such as the Internet, by means of a web browser or web application and the like installed on a EUD 210.”) ([DORON, para. 0060] “requested domain hosted in the cloud computing platform 110. For example, a request to a domain www.mysite.com”) a plurality of network ingress paths receiving a plurality of application-layer request messages, each of the plurality of application-layer request messages being received from a respective source of a plurality of sources via a respective ingress path of the plurality of network ingress paths and being directed to a respective domain of the plurality of domains; ([DORON, para. 0047] “the EUDs 210, the CDN 220, and the platforms 110 and 140 are all communicatively connected through the Internet, dedicated tunnels or any other communication network.”) ([DORON, para. 0011] “many small-size HTTP requests for a “common” web resources are sent. This is performed to attack the ingress processing path at a web server hosting such a resource.”) ([DORON, para. 0052] “the detector 260 is configured to operate as an application layer (layer-7) attack detector by analyzing telemetries related at least to incoming and outgoing traffic flows in order to detect flood HTTP and TCP DDoS attacks.”) ([DORON, para. 0042] “The example network diagram 200 illustrates a plurality of end-user devices (EUDs) 210”) ([DORON, para. 0045] “The EUDs 210 are configured to access a protected application 160 hosted in the cloud computing platform 110 and executed by the servers 165 (FIG. 1). The access to the protected application 160 is through a network, such as the Internet, by means of a web browser or web application and the like installed on a EUD 210.”) ([DORON, para. 0047] “should be noted that the EUDs 210, the CDN 220, and the platforms 110 and 140 are all communicatively connected through the Internet, dedicated tunnels or any other communication network.”) ([DORON, para. 0060] “For example, a request to a domain “www.mysite.com””) an orchestration engine including one or more processors configured to …. determine …spike in domain-specific network traffic corresponds to an application-layer distributed denial of service attack for a domain, … and upon determining that the … surpasses a designated threshold, determine a plurality of domain-specific mitigation policies corresponding with the plurality of network ingress paths based on a classification of a subset of the plurality of application-layer request messages as being sent from a subset of the plurality of sources and as being associated with a distributed denial of service attack, the plurality of mitigation policies including one or more rules to prevent a subset of subsequent application-layer request messages from the subset of the sources from reaching one or more components of the computing services environment; ([DORON, para. 0060] “the DNS traffic redirection (for diverting traffic originally directed to the cloud computing platform 110 to the defense platform 140) includes automatically modifying a DNS record entry to point to a virtual IP (VIP) address representing a resource in the defense platform 140 and not to an IP address of the requested domain hosted in the cloud computing platform 110. For example, a request to a domain “www.mysite.com” would be replaced with “po.mysite.clouddetectorner””) ([DORON, para. 0081] “The determined DoA is compared to a predefined threshold, where any DoA score exceeding this threshold would trigger an alert or a signal that a flood HTTP and/or TCP DDoS attack has been detected.”) ([DORON, para. 0099] “In an embodiment, S550 includes comparing the DoA score to a predefined threshold. If so, at S560, a detection signal is trigged to cause, for example, execution of at least one mitigation action”) ([DORON, para. 0043] “The defense platform 140 includes a mitigation resource 250, a detector 260, and a controller 280.”) ([DORON, para. 0052] “the detector 260 is configured to operate as an application layer (layer-7) attack detector by analyzing telemetries related at least to incoming and outgoing traffic flows in order to detect flood HTTP and TCP DDoS attacks. Such analysis is based on the detection of abnormalities in the traffic flows”) ([DORON, para. 0053] “The detection engine may be configured to monitor the received telemetries, determine a set of features, and to detect flood DDoS attacks using … a machine learning based classifier”) ([DORON, para. 0030] “Upon detection of a potential flood DDoS attack, the traffic associated with the attack is redirected to a mitigation resource”) ([DORON, para. 0047] “the EUDs 210, the CDN 220, and the platforms 110 and 140 are all communicatively connected through the Internet, dedicated tunnels”) ([DORON, para. 0057] “Upon detection of the potential attack, the controller 280 may be configured to cause a DNS diversion from a normal path of traffic from the EUDs 210 to the mitigation resources 250. That is, when the DNS diversion has occurred, instead of flowing the traffic to the protected cloud-hosted application 160, traffic from the EUDs 210 is diverted to the defense platform 140.”) ([DORON, para. 0058] “The mitigation resource 250 performs one or more mitigation actions on the traffic and forwards legitimate clean traffic back toward the protected application 160 through the ADC 270.”) ([DORON, para. 0101] “the mitigation resource cleans the traffic by removing malicious traffic”) and one or more network controllers configured to implement one or more instructions characterizing the plurality of mitigation policies received from the orchestration engine. ([DORON, para. 0057] “Upon detection of the potential attack, the controller 280 may be configured to cause a DNS diversion from a normal path of traffic from the EUDs 210 to the mitigation resources 250.”) ([DORON, para. 0058] “The mitigation resource 250 performs one or more mitigation actions on the traffic and forwards legitimate clean traffic back toward the protected application 160 through the ADC 270.”) ([DORON, para. 0059] “The controller 280 is configured to control the traffic diversion to and from the platforms 110 and 140 as well all the mitigation functionalities.”)
However, DORON does not teach “determine a probability that a spike in … network traffic corresponds to an application-layer distributed denial of service attack for a …, and upon determining that the probability surpasses a designated threshold … the plurality of domain-specific mitigation policies blocking traffic to the domain from a first source and throttling traffic to the domain from a second source;”.
In analogous teaching KANG teaches “determine a probability that a spike in … network traffic corresponds to an … distributed denial of service attack for a … , and upon determining that the probability surpasses a designated threshold determine … mitigation policies” ([KANG, para. 0026] “The information collecting unit 110 may collect DDoS detection information used to determine the probability of occurrence of the DDoS attack in terms of interface, for example, the information collecting unit 110 collects rate information about traffic change by use of packet count of packets input per a unit time,”) ([KANG, para. 0027] “The testing unit 120 sets the first probability to be higher if the rate information about traffic change is larger”) ([KANG, para. 0061] “the responding unit 530 determines that a DDoS attack occurs if the probability (P) of occurrence of DDoS attack is higher than 50%. The responding unit 530 responds to the DDoS attack in various countermeasures according to the probability (P) of occurrence of DDoS attack”).
Thus, given the teaching of KANG, 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 preventing a subsequent application-layer request message from the first source by KANG into the teaching of an computing services environment to prevent DDOS attacks by DORON. One of ordinary skill in the art would have been motivated to do so because KANG recognizes the need to efficiently detect DDOS attacks ([KANG, para. 0070] “delicately detect DDoS attack in cooperation with security equipment, thereby reducing the false positive of the DDoS detection. In addition, since the detection result is expressed as a probability of DDoS attack, the DDoS attack can be probabilistically prevented, thereby improving the efficiency of prevention against the DDoS attack”).
However, DORON-KANG does not teach “the plurality of domain-specific mitigation policies blocking traffic to the domain from a first source and throttling traffic to the domain from a second source”.
In analogous teaching SMITH teaches “the plurality of domain-specific mitigation policies blocking traffic to the domain from a first source and throttling traffic to the domain from a second source” ([SMITH, abstract] “A method of filtering a plurality of DNS queries, wherein each DNS query includes a query name and a resource record type, includes defining a filter rule including a domain name, a filter type, and a throttle percentage and forming a filter file including the filter rule. … and blocking a predetermined percentage (equal to the throttle percentage) of the subset of the plurality of DNS queries.”) ([SMITH, para. 0002] “example of such harm is a distributed denial of service (DDoS) attack, in which multiple compromised systems flood the bandwidth or resources of a targeted system”) ([SMITH, para. 0006] “The method further includes determining a match between the domain name and the query name and between the resource record type and the filter type for a subset of the plurality of DNS queries and blocking a predetermined percentage of the subset of the plurality of DNS queries. The predetermined percentage is equal to the throttle percentage.”) ([SMITH, para. 0057] “The second rule would block all queries for the name NO-SUCH-DOMAIN.COM with any type. Regardless of the type, the query would be dropped if the queried name were NO-SUCH-DOMAIN.COM.”) ([SMITH, para. 0059] “The IP rules include the IP address(es) to be blocked, represented in CIDR format, the mode, either real or test, the time limit for the filter (_ttl_), the throttle percentage (between 0 and 100%)”) ([SMITH, para. 0082] “The first domain name filter (domainRule0) filters the second level domain “example.” The type is TYPE —1, which is a host address. The filter is operated as a real filter, not in a test mode. The expiration time period for the filter is 1800 seconds (i.e., 30 minutes), the throttle percentage is 75%, and the timestamp is 1224086686.”) ([SMITH, para. 0069] “By modifying the throttle percentage to values between 0 and 100%, a predetermined percentage of the queries coming from the defined block of IP addresses will be blocked, enabling some traffic to pass through the processing engine for filters blocking more than 0%. In the example given above, the throttle percentage of 100% blocks all traffic from the defined network.”).
Thus, given the teaching of SMITH, 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 throttling and blocking by SMITH into the teaching of an computing services environment to prevent DDOS attacks by DORON-KANG. One of ordinary skill in the art would have been motivated to do so because SMITH recognizes the need to filter traffic ([SMITH, para. 0004] “there is a need in the art for improved methods and systems to filter network traffic.”) ([SMITH, para. 0005] “The present invention relates generally to data networks. More specifically, the present invention relates to methods and systems for filtering network traffic.”)
Regarding claim 14, this claim recites of a method that implements an orchestration engine that performs the steps of computing services environment of claim 1. Therefore, claim 14 is rejected in a similar manner as in the rejection of claim 1. DORON further teaches ([DORON, para. 0017] “Certain embodiments disclosed herein include a system and method for protecting cloud-hosted applications against hypertext transfer protocol (HTTP) flood distributed denial-of-service (DDoS) attacks.”)
Regarding claim 18, this claim recites of a non-transitory computer readable media having instructions stored thereon for performing a method that implements the of computing services environment of claim 1. Therefore, claim 18 is rejected in a similar manner as in the rejection of claim 1. DORON further teaches ([DORON, para. 0103] “FIG. 7 is an example block diagram of the detector 260 according to an embodiment. The detector 260 includes a processing circuitry 710 coupled to a memory 720”) ([DORON, para. 0106] “the instructions, when executed, cause the processing circuitry 710 to perform out-of-path detection and mitigation of cyber-attacks, including flood DDoS attacks, as discussed hereinabove. In a further embodiment, the memory 720 may further include a memory portion including the instructions.”)
Regarding claims 2 and 15, DORON-KANG-SMITH teaches all limitations of claims 1 and 14. DORON further teaches “where a first source of the subset of sources is identified as being associated with the distributed denial of service attack based on application layer activity, network layer activity, or transport layer activity.” ([DORON, para. 0052] “the detector 260 is configured to operate as an application layer (layer-7) attack detector by analyzing telemetries related at least to incoming and outgoing traffic flows in order to detect flood HTTP and TCP DDoS attacks.”) ([DORON, para. 0064] “the telemetric data used for detecting flood DDoS attacks may include, for example, a number of HTTP requests (POST and, GET requests, and/or other HTTP verbs) received or processed by the cloud platform (e.g., at an edge entity 231 or the server 165 hosting the protected application); … a total number of new TCP connections established between the EUDs 210 and the edge entity 231 or between the EUDs 210 and the server 165, a total number of bytes processed by the edge entity 231, the server 165, and so on.”).
Regarding claim 5, DORON-KANG-SMITH teaches all limitations of claim 1. DORON further teaches “wherein the plurality of mitigation policies are determined when a traffic level associated with a portion of the computing services environment exceeds a designated threshold.” ([DORON, para. 0055] “the normal baseline level is determined using the monitored telemetries and may represent an average or otherwise normal typical value for the telemetries and the thresholds may represent deviations from the baseline (e.g., based on a predetermined number of standard deviations from the baseline or as a percentage from the baseline).”) ([DORON, para. 0082] “behavioral changes showing an increase in the request rate (RPS) and a decrease, or an increase, in the average request size (ARS) would be indicative of a HTTP flood attack”) ([DORON, para. 0081] “The determined DoA is compared to a predefined threshold, where any DoA score exceeding this threshold would trigger an alert or a signal that a flood HTTP and/or TCP DDoS attack has been detected.”) ([DORON, para. 0058] “The mitigation resource 250 performs one or more mitigation actions on the traffic and forwards legitimate clean traffic back toward the protected application 160 through the ADC 270.”).
Regarding claims 9, 21, and 24, DORON-KANG-SMITH teaches all limitations of claims 1, 14, and 18. DORON further teaches “wherein the application-layer distributed denial of service attack is limited to a subset of the plurality of domains and a subset of the plurality of network ingress paths.” ([DORON, para. 0029] “The protection is performed in an out-of-path deployment, that is, traffic directed to the protected application”) ([DORON, para. 0038] “The cleaned traffic is redirected back to the destination server 165 hosting the protected application 160 that the traffic was originally directed to.”) ([DORON, para. 0032] “FIG. 1 is an example network diagram of a multi-cloud architecture 100 utilized to describe the various disclosed embodiments. The multi-cloud architecture 100 includes a plurality of cloud computing platforms 110-1 through 110-N”) ([DORON, para. 0033] “Each of the cloud computing platforms 110-1 through 110-N, and the datacenter 120 executes a protected application 160 which is the protected entity. As noted above, a protected application 160 may be a web application, a cloud hosted application, or any other software application or software resource executed by a server.”).
Regarding claims 11, 22, and 25, DORON-KANG-SMITH teaches all limitations of claims 1, 14, and 18. DORON further teaches “wherein a mitigation policy of the plurality of mitigation policies blocks or redirects traffic transmitted via an ingress path of the plurality of network ingress paths.” ([DORON, para. 0011] “attack the ingress processing path at a web server hosting such a resource.”) ([DORON, para. 0047] “the EUDs 210, the CDN 220, and the platforms 110 and 140 are all communicatively connected through the Internet, dedicated tunnels or any other communication network.”) ([DORON, para. 0101] “the mitigation resource cleans the traffic by removing malicious traffic and sends the clean traffic to at least one server hosting the protected application. In another embodiment, the mitigation action includes automatic configuration of ACLs in the cloud computing platform to prevent direct access to the protected application”) ([DORON, para. 0030] “Upon detection of a potential flood DDoS attack, the traffic associated with the attack is redirected to a mitigation resource such as, e.g., a scrubbing center”).
Regarding claims 13, 23, and 26, DORON-KANG-SMITH teaches all limitations of claims 1, 14, and 18. KANG further teaches “wherein the probability is determined based at least in part on historical network traffic data associated with one or more domains of the plurality of domains.” ([KANG, para. 0030] “The traffic change rate information collecting unit 210 collects information about the rate of traffic change by use packet count of packets input per a first unit time, … the traffic change rate information collecting unit 210 may collect information about packet count, flow count and byte count per a unit time, for example, per 10 seconds or 20 seconds.”) ([KANG, para. 0040] “flow PPS collecting unit 230 maintains the PPS for each target IP address and each protocol of source IP address and determines DDoS based on information about the PPS”).
The same motivation to modify DORON with KANG as in the rejection of claim 1 applies.
Claims 7, 8, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over DORON-KANG-SMITH in view of BELGI (US-20250260707-A1), hereinafter DORON-KANG-SMITH-BELGI.
Regarding claim 7, DORON-KANG-SMITH teaches all limitations of claim 1. DORON teaches of “application-layer request message “as can be seen in the rejection of claim 1. However, DORON-KANG-SMITH does not teach “the computing services environment further comprising a generative language model interface configured to generate a report characterizing the … distributed denial of service attack by generating novel text to complete a prompt, the prompt including one or more natural language instructions to generate the novel text, the prompt further including analysis information characterizing the application-layer distributed denial of service attack, the prompt further including mitigation information characterizing the plurality of mitigation policies.”.
In analogous teaching BELGI teaches “the computing services environment further comprising a generative language model interface configured to generate a report characterizing the … distributed denial of service attack by generating novel text to complete a prompt, the prompt including one or more natural language instructions to generate the novel text, the prompt further including analysis information characterizing the application-layer distributed denial of service attack, the prompt further including mitigation information characterizing the plurality of mitigation policies.” ([BELIG, abstract] “Automatically investigating security incidents and generating security incident reports using a Large Language Model (LLM). A computerized system receives an incoming Security Alert Message pertaining to a possible security-related incident.”) ([BELIG, para. 0014] “autonomously generate an Incident Report, written in a natural language (e.g., English) that the user or the administrator can read”) ([BELIG, para. 0051] “a first LLM in combination with prompt engineering techniques are utilizes to construct and to update such Incident Report Generator 106”) ([BELIG, para. 0054] “generates queries that the Applicative Layer Agent Unit 122 then executes on the one or more Vector Database(s) described above. The queries that are generated by the LLM 115C, and that are then utilized by the Applicative Layer Agent Unit 122 to query the database(s), can be, for example: (a) Which attack operations typically precede the attack (or problem, or vulnerability, or security issue) described in this Alert Under Investigation? …. (g) What are the mitigation/prevention operations that can or that should be performed, to mitigate or prevent or stop the attack (or problem, or vulnerability, or security issue) described in the Alert Under Investigation, or to minimize or reduce its damage? Other prompts or queries may be generated by the LLM 115C”) ([BELIG, para. 0034] “Each such Analyst Report may include, for example: (a) data indicating or identifying or describing the particular/current Alert that is being investigated or analyzed in this report “Alert Under Investigation”); … (f) identifiers or descriptors of corrective actions/mitigation actions/remedial actions that are mentioned within the Alert Under Investigation itself (e.g., if such actions were suggested by the entity/component that generated the Alert Under Investigation and/or that sent the Alert Under Investigation); … (h) indicators of the type and/or size of damage that may result from the attack … utilizing a device for D-DOS attacks, or the like; (i) recommendations/suggestions/proposals from the analyst on how to respond to the Alert Under Investigation, and/or which remedial/corrective/mitigation actions to perform or to initiate,”).
Thus, given the teaching of BELGI, 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 LLM reports by BELGI into the teaching of an computing services environment to prevent DDOS attacks by DORON-KANG-SMITH. One of ordinary skill in the art would have been motivated to do so because BELGI recognizes the benefits of LLM reports ([BELGI, para. 0024] “The Applicant has realized that given a newly generated alert, it becomes difficult and sometimes impossible for a human to answer-at all, or efficiently”) ([BELGI, para. 0025] “embodiments operate to turn an alert, or to group a plurality of discrete alerts, into an Incident, for which an Incident Investigation Report (IIR) is automatically generated”).
Regarding claim 8, DORON-KANG-SMITH-BELGI teach all limitations of claim 7. BELGI further teaches “wherein the orchestration engine is further configured to identify a recipient of the plurality of recipients that is likely affected by the application-layer distributed denial of service attack and to transmit the report to the identified recipient.” ([BELGI, para. 0034] “Analyst Report may include … indicators of the type and/or size of damage that may result from the attack … utilizing a device for D-DOS attacks, or the like”) ([BELGI, para. 0026] “the Incident Report 110 may be sent or transported or transferred or copied to one or more pre-defined recipients (e.g., a system administrator; an Information Technology (IT) department; an IT security department; a fraud department)”) ([BELGI, para. 0014] “automatically and autonomously generate an Incident Report, written in a natural language (e.g., English) that the user or the administrator can read and understand, providing the investigation results as well as one or more mitigation operations that may or can or should be performed. In some embodiments, such automatically-generated Incident Report may further be accompanied by a generated code or code-portion, or by a generated signal or message, that trigger or cause the automatic invocation of such mitigation operations”).
The same motivation to modify DORON-KANG-SMITH with BELGI as in the rejection of claim 7 applies.
Regarding claim 19, DORON-KANG-SMITH teaches all limitations of claim 18. Furthermore, this claim recites limitations from claims 1, 5, 7, and 8. Therefore, claim 19 is rejected in a similar manner as in the rejection of claims 1, 5, 7, and 8. The same motivation applies.
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s
disclosure.
GOULD (US-20120174198-A1): This prior art teaches of system and method for more efficiently establishing a chain of trust from a registrant to a registry. A registrant credential is associated with a Shared Registration command and is sent by a registrar to a registry. Upon successful validation, a token is generated and bound to a registrant identifier. The token is included along with the registrant identifier in subsequent discrete Shared Registration commands submitted to the registry on behalf of the registrant. The registrant thus needs to submit its credential only once for changes that require several discrete commands. Also, it is more efficient for the Shared Registration System to validate a token for a set of commands than to validate different registrant credential for each discrete command.
MEHTA (US-9787567-B1): This prior art teaches of packet forwarding network may include switches that forward network traffic between end hosts and network tap devices that forward copied network traffic to an analysis network formed from client switches that are controlled by a controller. Network analysis devices and network service devices may be coupled to the client switches at interfaces of the analysis network. The controller may receive one or more network policies from a network administrator. A network policy may identify ingress interfaces, egress interfaces, matching rules, packet manipulation services to be performed. The controller may control the client switches to generate network paths that forward network packets that match the matching rules from the ingress interfaces to the egress interfaces through service devices that perform the services of the list. The controller may generate network paths for network policies based on network topology information and/or current network conditions maintained at the controller.
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./
03/06/2026
/AFAQ ALI/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434