DETAILED ACTION
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 30 June 2025 has been considered by the examiner.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 8 and 18 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 8 and 18 recite the limitation "the OPA plugin”" in Line 2. There is insufficient antecedent basis for this limitation in the claim, as an OPA plugin is not recited and any of claims 1, 5, or 6 or earlier in claim 8 or claims 10, 15, or 16 or earlier in claim 18. Claims 7 and 17 would provide antecedent basis for claims 8 and 18 and claims 8 and 18 are being treated as if they depend from claims 7 and 17 for the purpose of examination.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 5-6, 10-12 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2017/0310709 by Foxhoven et al. in view of U.S. Patent No. 11,811730 to Kandasamy et al.
As to claims 1 and 10, Foxhoven discloses a secure web gateway for a cloud computing environment/method, comprising:
a data plane component, comprising:
a front-end domain name service (DNS) configured to receive an inbound DNS request and map an IP address of the DNS request to a policy identification value corresponding to a customer policy (Foxhoven: Page 4, Sec 34; “The network 200 illustrates the DNS augmented security where DNS information is used as follows. First, at step 210, the user device 204 requests a DNS lookup of a site, e.g. “what is the IP address of site.com?” from the anycast DNS server 206. The anycast DNS server 206 accesses the policy data 208 to determine the policy associated with the site at step 212. The anycast DNS server 206 returns the IP address of the site based on the appropriate policy at step 214. The policy data 208 determines if the site either goes direct (step 216) to the Internet, is inspected by the inline proxy (step 218), or is blocked per policy (step 220). Here, the anycast DNS server 206 returns the IP address with additional information if the site is inspected or blocked. For example, if the anycast DNS server 206 determines the access is direct, the anycast DNS server 206 simply returns the IP address of the site. If the anycast DNS server 206 determines the site is blocked or inspected, the anycast DNS server 206 returns the IP address to the inline proxy 209 with additional information. The inline proxy 209 can block the site or provide fully inline proxied traffic to the site (step 222) after performing monitoring for security.”); and
a control plane component that provides the customer policy to the front-end DNS and configures the IP address to permit access to a DNS service according to the customer policy (Foxhoven: Page 4, Sec 34; “The network 200 illustrates the DNS augmented security where DNS information is used as follows. First, at step 210, the user device 204 requests a DNS lookup of a site, e.g. “what is the IP address of site.com?” from the anycast DNS server 206. The anycast DNS server 206 accesses the policy data 208 to determine the policy associated with the site at step 212. The anycast DNS server 206 returns the IP address of the site based on the appropriate policy at step 214. The policy data 208 determines if the site either goes direct (step 216) to the Internet, is inspected by the inline proxy (step 218), or is blocked per policy (step 220). Here, the anycast DNS server 206 returns the IP address with additional information if the site is inspected or blocked. For example, if the anycast DNS server 206 determines the access is direct, the anycast DNS server 206 simply returns the IP address of the site. If the anycast DNS server 206 determines the site is blocked or inspected, the anycast DNS server 206 returns the IP address to the inline proxy 209 with additional information. The inline proxy 209 can block the site or provide fully inline proxied traffic to the site (step 222) after performing monitoring for security.”).
Foxhoven does not expressly disclose a plurality of plugin modules utilized by the front-end DNS to process the DNS request according to the mapping of the IP address from which the DNS request originates to the policy identification value.
Kandasamy discloses a plurality of plugin modules utilized by the front-end DNS to process the DNS request according to the mapping of the IP address from which the DNS request originates to the policy identification value (Kandasamy: Col 14, Lines 35-47, Col 15, Lines 35-64; Col 17, Lines 38-64 and Col 21, Lines 53-62; CoreDNS system with a plurality of plugins including rule based forwarding).
Foxhoven and Kandasamy are analogous art because they are from the common area of DNS.
It would have been obvious to one of ordinary skill in the art to use the CoreDNS of Kandasamy in the system of Foxhaven. The rationale would have been to provide DNS with the ability to add on features (Kandasamy: Col 14, Lines 35-47).
As to claims 2 and 12, The modified Foxhaven/Kandasamy reference further discloses wherein the control plane component controls access to the DNS service according to the customer policy (Foxhoven: Page 4, Sec 34; “The network 200 illustrates the DNS augmented security where DNS information is used as follows. First, at step 210, the user device 204 requests a DNS lookup of a site, e.g. “what is the IP address of site.com?” from the anycast DNS server 206. The anycast DNS server 206 accesses the policy data 208 to determine the policy associated with the site at step 212. The anycast DNS server 206 returns the IP address of the site based on the appropriate policy at step 214. The policy data 208 determines if the site either goes direct (step 216) to the Internet, is inspected by the inline proxy (step 218), or is blocked per policy (step 220). Here, the anycast DNS server 206 returns the IP address with additional information if the site is inspected or blocked. For example, if the anycast DNS server 206 determines the access is direct, the anycast DNS server 206 simply returns the IP address of the site. If the anycast DNS server 206 determines the site is blocked or inspected, the anycast DNS server 206 returns the IP address to the inline proxy 209 with additional information. The inline proxy 209 can block the site or provide fully inline proxied traffic to the site (step 222) after performing monitoring for security.”).
As to claims 5 and 15, The modified Foxhaven/Kandasamy reference further discloses wherein the plurality of plugin modules includes a source IP plugin that compares the IP address of the incoming DNS request and a set of known IP addresses to determine whether the IP address has a valid policy associated with the IP address and to provide the policy identification value for the front-end DNS to evaluate the policy and decide whether to allow or block the request (Kandasamy: Col 14, Lines 35-47, Col 15, Lines 35-64; Col 17, Lines 38-64 and Col 21, Lines 53-62; CoreDNS system with a plurality of plugins including rule based forwarding by IP address).
As to claims 6 and 16, The modified Foxhaven/Kandasamy reference further discloses wherein the plurality of plugin modules includes a firewall plugin that applies a final decision whether to allow or block the inbound DNS request (Foxhaven: Page 8 Sec 59; firewall filtering to enforce policy and Kandasamy: Col 14, Lines 35-47, Col 15, Lines 35-64; Col 17, Lines 38-64 and Col 21, Lines 53-62).
As to claim 11, The modified Foxhaven/Kandasamy reference further discloses wherein the front-end domain name service and the control plane component are cloud-based and connected to customer system, wherein the inbound DNS request originates from the customer system (Foxhaven: Page 1, Sec 8; “In an exemplary embodiment, a cloud-based security method using Domain Name System (DNS) includes receiving a request from a user device at a DNS server; performing a security check on the request based on a policy look up associated with the user device; responsive to the policy look up, performing a DNS security check on the request; and, responsive to the DNS security check, performing one of allowing the request to the Internet; blocking the request based on the policy; and providing the request to inline inspection based on the policy, wherein the request is one of allowed to the Internet or blocked based on the inline inspection.”).
Claims 3, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2017/0310709 by Foxhoven et al. in view of U.S. Patent No. 11,811730 to Kandasamy et al. further in view of U.S. Patent Application Publication No. 2023/0412563 by Barnett.
As to claims 3 and 13, the modified Foxhaven/Kandasamy reference discloses all recited elements of claims 1 and 10 from which claims 3 and 13 depend.
The modified reference does not expressly disclose wherein the control plane component comprises a DNS Protection resolver at a domain of a customer environment for providing access to the domain according to the customer policy.
Barnett discloses wherein the control plane component comprises a DNS Protection resolver at a domain of a customer environment for providing access to the domain according to the customer policy. (Barnett: Page 3, Sec 36; DNS protection agent that filters traffic)
The modified reference and Barnett are analogous art because they are from the common area of DNS.
It would have been obvious to one of ordinary skill in the art to use the DNS protection agent of Barnett in the system of he modified reference. The rationale would have been to increase the security and privacy of DNS (Barnett: Page 3, Sec 36).
As to claim 20, the modified Foxhaven/Kandasamy/Barnett reference further discloses a method for performing DNS resolution comprising:
receiving, by a front-end domain name service (DNS) of a data plane component, an inbound DNS request (Foxhoven: Page 4, Sec 34; “The network 200 illustrates the DNS augmented security where DNS information is used as follows. First, at step 210, the user device 204 requests a DNS lookup of a site, e.g. “what is the IP address of site.com?” from the anycast DNS server 206);
mapping, by the front-end DNS, an IP address of the inbound DNS request to a policy identification value corresponding to a customer policy (Foxhoven: Page 4, Sec 34; The anycast DNS server 206 accesses the policy data 208 to determine the policy associated with the site at step 212. The anycast DNS server 206 returns the IP address of the site based on the appropriate policy at step 214. The policy data 208 determines if the site either goes direct (step 216) to the Internet, is inspected by the inline proxy (step 218), or is blocked per policy (step 220));
utilizing, by the front end DNS, a plurality of plugin modules to process the DNS request according to the mapping of the IP address from which the DNS originates to the policy identification value (Kandasamy: Col 14, Lines 35-47, Col 15, Lines 35-64; Col 17, Lines 38-64 and Col 21, Lines 53-62; CoreDNS system with a plurality of plugins including rule based forwarding);
configuring, by a control plane component connected to the front-end DNS service, the IP address to permit access to the front-end DNS service according to the customer policy (Foxhoven: Page 4, Sec 34; The network 200 illustrates the DNS augmented security where DNS information is used as follows. First, at step 210, the user device 204 requests a DNS lookup of a site, e.g. “what is the IP address of site.com?” from the anycast DNS server 206. The anycast DNS server 206 accesses the policy data 208 to determine the policy associated with the site at step 212. The anycast DNS server 206 returns the IP address of the site based on the appropriate policy at step 214);
providing, by the control plane component, the customer policy to the front-end DNS (Foxhoven: Page 4, Sec 34; The network 200 illustrates the DNS augmented security where DNS information is used as follows. First, at step 210, the user device 204 requests a DNS lookup of a site, e.g. “what is the IP address of site.com?” from the anycast DNS server 206. The anycast DNS server 206 accesses the policy data 208 to determine the policy associated with the site at step 212. The anycast DNS server 206 returns the IP address of the site based on the appropriate policy at step 214);
controlling, by the control plane component, access to the front-end DNS service according to the customer policy (Foxhoven: Page 4, Sec 34; “The network 200 illustrates the DNS augmented security where DNS information is used as follows. First, at step 210, the user device 204 requests a DNS lookup of a site, e.g. “what is the IP address of site.com?” from the anycast DNS server 206. The anycast DNS server 206 accesses the policy data 208 to determine the policy associated with the site at step 212. The anycast DNS server 206 returns the IP address of the site based on the appropriate policy at step 214. The policy data 208 determines if the site either goes direct (step 216) to the Internet, is inspected by the inline proxy (step 218), or is blocked per policy (step 220). Here, the anycast DNS server 206 returns the IP address with additional information if the site is inspected or blocked. For example, if the anycast DNS server 206 determines the access is direct, the anycast DNS server 206 simply returns the IP address of the site. If the anycast DNS server 206 determines the site is blocked or inspected, the anycast DNS server 206 returns the IP address to the inline proxy 209 with additional information. The inline proxy 209 can block the site or provide fully inline proxied traffic to the site (step 222) after performing monitoring for security.”); and
providing access, by a DNS Protection resolver of the control plane controller located at a domain of a customer environment (, to the domain according to the customer policy (Barnett: Page 3, Sec 36; DNS protection agent that filters traffic), wherein the front-end domain name service and the control plane component are cloud-based and connected to customer system, wherein the inbound DNS request originates from the customer system (Foxhaven: Page 1, Sec 8; “In an exemplary embodiment, a cloud-based security method using Domain Name System (DNS) includes receiving a request from a user device at a DNS server; performing a security check on the request based on a policy look up associated with the user device; responsive to the policy look up, performing a DNS security check on the request; and, responsive to the DNS security check, performing one of allowing the request to the Internet; blocking the request based on the policy; and providing the request to inline inspection based on the policy, wherein the request is one of allowed to the Internet or blocked based on the inline inspection.”).
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2017/0310709 by Foxhoven et al. in view of U.S. Patent No. 11,811730 to Kandasamy et al. further in view of U.S. Patent Application Publication No. 2022/0353235 by Zhang et al.
As to claims 4 and 14, the modified Foxhaven/Kandasamy reference discloses all recited elements of claims 1 and 10 from which claims 4 and 14 depend.
The modified reference does not expressly disclose wherein the data plane further comprises a dynamic DNS (DDNS) poller that automatically updates DNS records when the IP address changes.
Zhang discloses wherein the data plane further comprises a dynamic DNS (DDNS) poller that automatically updates DNS records when the IP address changes (Zhang: Page 3, Sec 31; “When processor 152 receives a local DNS-IP mapping from an AP in first VLAN 102 along with AP's geographical information, it may create a record in the global DNS-IP mapping database 170 for the AR At a later point in time, processor 152 may receive an update related to the local DNS-IP mapping from the same AP. Upon receiving the update, processor 152 may update the record related to the AP in the global DNS-IP mapping database 170. In an example, the global DNS-IP mapping database 170 may be in a tabular form (e.g., a spreadsheet)”).
The modified reference and Zhang are analogous art because they are from the common area of DNS.
It would have been obvious to one of ordinary skill in the art to use the DNS mapping of Zhang in the system of the modified reference. The rationale would have been to keep the mapping database up to date(Zhang: Page 3, Sec 31).
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication No. 2017/0310709 by Foxhoven et al. in view of U.S. Patent No. 11,811730 to Kandasamy et al. further in view of U.S. Patent Application Publication No. 2023/0055046 by Whited.
As to claims 9 and 19, the modified Foxhaven/Kandasamy reference discloses all recited elements of claims 1 and 10 from which claims 4 and 14 depend.
The modified reference does not expressly disclose further comprising a global accelerator that routes traffic to a point of presences (PoP) based on the IP address of the DNS request.
Whited discloses further comprising a global accelerator that routes traffic to a point of presences (PoP) based on the IP address of the DNS request (Whited: Page 10, Sec 163; data routed to PoP ).
The modified reference and Whited are analogous art because they are from the common area of DNS.
It would have been obvious to one of ordinary skill in the art to use the DNS Pop routing of Whited in the system of the modified reference. The rationale would have been to account for changing network topography (Whited: Page 1, Sec 5).
Allowable Subject Matter
Claims 7 and 17 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.
Claims 8 and 18 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL S MCNALLY whose telephone number is (571)270-1599. The examiner can normally be reached Monday-Friday, 8:30 AM - 5: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, Jeffrey L Nickerson can be reached at (469)295-9235. 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.
MICHAEL S. MCNALLY
Primary Examiner
Art Unit 2432
/Michael S McNally/Primary Examiner, Art Unit 2432