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
This Office Action is in response to a Brief Pre-Appeal Conference Decision on 08/28/2026. In the conference, the panel decided to re-open prosecution.
For this Office Action, claims 1-8, 17, 20, and 23-29 have been received for consideration and have been examined. Claims 9-16, 18-19, and 21-22 remain cancelled.
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.
Claim(s) 1-2, 5-6, 8, 17, 20, 23, 26-27, and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Lubashev et al., (US20160315857A1) in view of Radlein et al., (US9742795B1).
Regarding claim 1, Lubashev discloses:
A method of mitigating volumetric attacks, comprising:
“providing two or more deployments of network infrastructure that receive network packets from client devices on a wide area network;” (Lubashev, [0022]: “a set of machines 102a-n distributed around the Internet”); (Lubashev, [0033]: “End user packets enter the CDN system via these anycast addresses”);
“providing a plurality of anycast IP prefixes;” (Lubashev, [0046]: “multiple anycast prefixes (IPv4/24s and IPv6/48s) are setup”);
“assign a customer an IP address from each of the plurality of anycast IP prefixes, the customer having a domain name;” (Lubashev, [0030]: “a content provider identifies a content provider domain or sub-domain”); (Lubashev, [0046]: “a CDN customer using this service is assign an IP address from each anycast cloud”);
Lubashev does not expressly state that the customer is assigned an IP address from each individual prefix, but teaches multiple prefixes within the anycast clouds, customer addresses across the clouds, and preferably an address for each customer in each Entrance.
“advertising all of the plurality of anycast IP prefixes as reachable from all of the two or more deployments of network infrastructure;” (Lubashev, [0031]: “the same IP prefix advertised from multiple geographically-diverse locations”); (Lubashev, [0046]: “each region in an anycast cloud announces addresses belonging to both of that cloud's entrances”);
“for DNS queries received to resolve the domain name of the customer, providing an answer by selecting an IP address from one of the assigned IP addresses, such that traffic load associated with the domain name is spread across the assigned IP addresses;” (Lubashev, [0030]: “the CDN name service returns one or more IP addresses”); (Lubashev, [0037]: “the end user will receive one or more of the anycast VIPs in return”); (Lubashev, [0052]: “anycast clouds may be load balanced”).
Lubashev further teaches changing which addresses are returned by the mapping mechanism (Lubashev, [0051]: “stop returning IP addresses of the region's anycast cloud to end users” and “return IP addresses belonging to other clouds”).
Lubashev does not expressly teach that such DNS selection is modified in response to a volumetric attack against the particular IP address.
Radlein teaches:
“responsive to detection of a volumetric attack directed to a particular one of the assigned IP addresses in one of the plurality of anycast IP prefixes ("attacked IP address"),” (Radlein, col. 5, ll. 20–25: “network addresses (e.g., those currently under attack)”);
“withdrawing the attacked IP address from consideration in said selection when providing answers to DNS queries for the domain name,” (Radlein, col. 5, ll. 20–25: “remove the initially submitted network addresses ... from DNS service responses”);
“such that traffic load associated with the domain name is directed to assigned IP addresses in the plurality of anycast IP prefixes other than the anycast IP prefix for the attacked IP address.” (Radlein, col. 5, ll. 25–29: “legitimate clients to attempt to connect to alternate network addresses”).
It would have been obvious to modify Lubashev's DNS-controlled anycast mapping in view of Radlein such that an IP address experiencing a volumetric attack is removed from DNS selection and legitimate clients are directed to alternate available addresses, because Radlein teaches this technique as a means of at least partially mitigating the attack.
Regarding claim 17, it is a system claim and recites similar subject matter as claim 1 and therefore rejected under similar ground of rejection.
Regarding claim 20, it is a non-transitory computer readable medium claim and recites similar subject matter as claim 1 and therefore rejected under similar ground of rejection.
Regarding claim 2, Lubashev discloses:
“The method of claim 1, further comprising, upon detection of an overload condition at a particular one of the two or more deployments of network infrastructure: withdrawing the advertisement of the anycast IP prefix for the attacked IP address as reachable from the particular one of the deployments of network infrastructure.” (Lubashev, [0047]: “anycast routes for this region must be withdrawn”); (Lubashev, [0048]: “the region being suspended will withdraw Entrance B CIDRs”);
Radlein further teaches attack-responsive routing withdrawal (Radlein, col. 8, ll. 45–60: “generate and transmit routing protocol data, such as Border Gateway Protocol (‘BGP’) packets”); and (Radlein, col. 9, ll. 7–12: “transmit ‘withdraw’ packets to connected network devices”).
Radlein explains that the withdraw packets indicate that the attacked network addresses are no longer accessible through the initial POP.
It would have been obvious to apply Radlein's attack-responsive BGP withdrawal to Lubashev's region-specific anycast route withdrawal so that traffic is moved away from an attacked or overloaded deployment while availability is maintained through other deployments.
Regarding claim 23, it is a system claim and recites similar subject matter as claim 2 and therefore rejected under similar ground of rejection.
Regarding claim 5, the combination of Lubashev and Radlein discloses:
“The method of claim 1, wherein each of the plurality of anycast IP prefixes comprises a /24 CIDR block.”
Lubashev teaches that an anycast prefix is advertised from multiple geographically diverse locations and expressly states that a /24 prefix is typically used. See Lubashev, ¶ [0031].
Lubashev further expressly teaches setting up multiple anycast prefixes comprising IPv4 /24s. See Lubashev, ¶ [0046].
Regarding claim 26, it is a system claim and recites similar subject matter as claim 5 and therefore rejected under similar ground of rejection.
Regarding claim 6, the combination of Lubashev and Radlein discloses:
“The method of claim 1, wherein the plurality of anycast IP prefixes comprises six or more anycast IP prefixes.” (Lubashev, [0046]: “Each anycast cloud may contain multiple anycast prefixes”).
Lubashev does not expressly disclose the claimed numerical threshold of “six or more anycast IP prefixes.”
However, Lubashev expressly contemplates multiple anycast prefixes within multiple anycast clouds and describes the architecture as scalable. It would have been obvious to employ six or more such prefixes as a matter of selecting the number of prefixes appropriate to the desired addressing capacity, redundancy, geographic coverage, and traffic distribution, with the number representing a predictable implementation parameter of Lubashev's disclosed multiple-prefix architecture.
Regarding claim 27, it is a system claim and recites similar subject matter as claim 6 and therefore rejected under similar ground of rejection.
Regarding claim 8, the combination of Lubashev and Radlein discloses:
“The method of claim 1, wherein the domain name is associated with a service provided by the customer and client devices attempting to reach the service are able to use any of the assigned IP addresses.” (Lubashev, [0030]: “a content provider identifies a content provider domain or sub-domain that it desires to have served by the CDN”); (Lubashev, [0030]: “the CDN name service returns one or more IP addresses”); (Lubashev, [0037]: “the end user will receive one or more of the anycast VIPs in return”).
Regarding claim 29, it is a system claim and recites similar subject matter as claim 8 and therefore rejected under similar ground of rejection.
Claim(s) 3-4, and 24-25 are rejected under 35 U.S.C. 103 as being unpatentable over Lubashev et al., (US20160315857A1) in view of Radlein et al., (US9742795B1) and further in view of Swildens et al., (US20090327489A1).
Regarding claim 3, the combination of Lubashev and Radlein fails to disclose:
“The method of claim 1, wherein providing an answer by selecting an IP address from one of the assigned IP addresses comprises: selecting each of the assigned IP addresses with the same frequency.”
However, Swildens discloses:
wherein providing an answer by selecting an IP address from one of the assigned IP addresses comprises: selecting each of the assigned IP addresses with the same frequency (FIG. 12A corresponding description: “client DNS 1210 picks IP addresses from list 1212 in a round-robin sequence; Swildens discloses four IP addresses associated with www.customer.com and successively selects 1.2.3.1, 1.2.3.2, 1.2.3.3, and 1.2.3.4 before returning to 1.2.3.1. Thus, each address is selected once during each round-robin cycle).
It would have been obvious to employ Swildens's known round-robin DNS selection in Lubashev's multiple-address DNS mapping to evenly distribute DNS selections among the available customer addresses.
Regarding claim 24, it is a system claim and recites similar subject matter as claim 3 and therefore rejected under similar ground of rejection.
Regarding claim 4, the combination of Lubashev and Radlein fails to disclose:
“The method of claim 1, wherein providing an answer by selecting an IP address from one of the plurality of assigned IP addresses comprises: selecting round robin amongst the assigned IP addresses.”
However, Swildens discloses:
wherein providing an answer by selecting an IP address from one of the plurality of assigned IP addresses comprises: selecting round robin amongst the assigned IP addresses (FIG. 12A corresponding description: “client DNS 1210 picks IP addresses from list 1212 in a round-robin sequence”).
It would have been obvious to use Swildens's round-robin DNS selection in Lubashev's DNS mapping system as a known technique for distributing requests among multiple available IP addresses.
Regarding claim 25, it is a system claim and recites similar subject matter as claim 4 and therefore rejected under similar ground of rejection.
Claim(s) 7 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Lubashev et al., (US20160315857A1) in view of Radlein et al., (US9742795B1) and further in view of Shapira et al., (US20170366577A1).
Regarding claim 7, the combination of Lubashev and Radlein fails to disclose:
“The method of claim 1, wherein the two or more deployments of network infrastructure comprise two or more scrubbing centers”.
However, Shapira discloses:
wherein the two or more deployments of network infrastructure comprise two or more scrubbing centers (Abstract: The traffic is routed via one of several scrubbing centers using the public IP address as anycast address, and the scrubbing center provides infrastructure protection by scanning and filtering the incoming traffic for illegitimate data. After filtering, the legitimate traffic is encapsulated, e.g., via including virtual GRE tunnel information that includes a secret IP address known only to the scrubbing center and the protected server that receives the network traffic. The protected server decapsulates the network packet and responds back to the end user via the scrubbing network).
Shapira teaches receiving traffic at distributed scrubbing centers and filtering malicious traffic before forwarding legitimate traffic toward the protected infrastructure.
It would have been obvious to implement Lubashev's distributed anycast deployments using Shapira's multiple scrubbing centers when providing Radlein's DDoS mitigation, thereby filtering attack traffic at distributed network locations while maintaining delivery of legitimate traffic.
Regarding claim 28, it is a system claim and recites similar subject matter as claim 7 and therefore rejected under similar ground of rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED M AHSAN whose telephone number is (571)272-5018. The examiner can normally be reached 8:30 AM - 6:00 PM.
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, William Korzuch can be reached at 571-272-7589. 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.
/SYED M AHSAN/Primary Examiner, Art Unit 2491
