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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 30, 2026 has been entered.
Response to Amendment
The amendment filed on March 30, 2026 has been entered.
Claims 1 and 14-15 have been amended.
Claims 11-12 and 22-23 have been canceled.
Claims 25-31 have been added.
Response to Arguments
Applicant's arguments filed on March 30, 2026, have been fully considered, but they are moot in view of the new grounds of rejections.
Claim Objections
Claims 1 and 14-15 are objected to because of the following informalities:
In claim 1, “"A" query” and “"A" records” should read “DNS "A" query” and DNS "A" records”. Same applies to claims 14-15.
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 and 14-15 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.
Claim 1 is rejected under 35 U.S.C. 112(b), claim 1 recites the limitations “to ensure that no "A" records are included …” It is unclear where the (A) records are included. Therefore, the examiner is unable to determine the metes and bounds of the claim language.
Same applies to claims 14-15.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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, 3-4, 7-8, 13-17, 20-21, 24-26, and 29-31 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang et al. (Pub. No. US 2018/0041521), hereinafter Zhang; in view Yehuda et al. (NXNSAttack: Recursive DNS Inefficiencies and Vulnerabilities, 12-14-2020, usenix), hereinafter Yehuda; in further view of Manadhata et al. (Pub. No. US 2020/0204581), hereinafter Manadhata.
Claim 1. Zhang discloses a system, comprising:
a processor (See Parag. [0019]) configured to:
identify a candidate attack domain potentially participating as an attacker in an attack based at least in part on an analysis of passive Domain Name System (DNS) data (See Parag. [0047]; passive DNS (pDNS) information is collected, in which DNS responses are collected passively (e.g., by listening to DNS traffic) from distributed sources (e.g., using passive DNS sensors). For example, the passive DNS information can be analyzed and correlated with other information, such as a malware association graph, to identify malicious entities, such as malware domains. See Parag. [0049]; techniques for malware domain detection using passive Domain Name Service (DNS)), including by:
determining that a nameserver (NS) count in the passive DNS data associated with the candidate attack domain exceeds a threshold (See Parag. [0049]; determining whether the first domain is a malware domain based on the reputation score for the first domain. The reputation score is based at least in part on a determination that the first domain resolves to a first Internet Protocol (IP) address associated with a first cluster of the malware association graph, and the first domain is determined to be a malware domain if the reputation score for the first domain exceeds a threshold value, See Parag. [0050]; malware domain detection using passive DNS further includes determining that a bad IP address (e.g., an IP address determined to be associated with malware) resolves to one or more additional domain addresses using passive DNS information. See Parag. [0096]; passive DNS information can facilitate identification of bad DNS name servers. For example, bad name servers or malicious name servers can refer to name servers that are determined to resolve malware domains to malware IPs); and
confirm the candidate attack domain as a confirmed attack domain based at least
in part on a validation that includes probing the candidate attack domain (See Parag. [0048]; if a DNS reputation score exceeds a threshold, then the domain can be identified as a malware domain (e.g., and malware samples from that domain can be identified as malware. See Parag. [0058]; malware domain detection using passive DNS further includes providing a framework that monitors different entities in DNS and evaluates the reputations of such entities. For example, the framework can improve the detection accuracy of malicious domains, and the framework can also monitor the malicious activities based on passive DNS information (e.g., passive DNS data)); and
a memory coupled to the processor and configured to provide the processor with
instructions (See Parag. [0019]; a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor).
Zhang doesn’t explicitly disclose the attack is a NoneXistent NameServer (NXNS) attack, and the nameserver (NS) count is a domain-to-Out- of-Bailiwick nameserver (NS) count; and confirm the candidate attack domain as a confirmed attack domain based at least in part on a validation that includes probing the candidate attack domain, including by obtaining authoritative nameservers for the domain and issuing an "A" query to ensure
that no "A" records are included and also by determining a packet amplification factor.
However, Yehuda discloses a NoneXistent NameServer (NXNS) attack (See Page 631, Col. 2, lines 9-16; analyze the DNS recursive resolver behavior and the interaction between its algorithms and components using the popular BIND server implementation; expose a new vulnerability in recursive resolver algorithms and demonstrate a new attack, called NXNSAttack, which exploits this vulnerability).
a domain-to-Out- of-Bailiwick nameserver (NS) count (See Page 645 col. 2 lines 4-10; rather inspected the NS referral responses received from the authoritative hierarchy in order to measure: (i) how many name servers are returned for each domain, (ii) how many name servers are not provided with their corresponding IP addresses, and (iii) which name servers are out-of-bailiwick. Counting the number of out-of-bailiwick name server).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Zhang, to include an NXNS attack and a domain-to-Out- of-Bailiwick nameserver (NS) count, as taught by Yehuda. This would be convenient to mitigate and reduce the NXNS Attack effect (Yehuda, Page 641, Col. 2, lines 3-4).
Manadhata discloses:
confirm the candidate attack domain as a confirmed attack domain based at least
in part on a validation that includes probing the candidate attack domain, including by
obtaining authoritative nameservers for the domain and issuing an "A" query to ensure
that no "A" records are included and also by determining a packet amplification factor (See Parag. [0031]; DNS engine 140 performs DNS functionality, which includes performing a lookup of a mapping information 144 stored in a storage medium 142 in response to a received DNS query containing a domain name. The mapping information 144 maps domain names to corresponding network addresses (e.g., IP addresses). See Parag. [0061-0062]; DNS-based attack defense engine 120 is able to detect a DNS amplification attack by checking if a DNS query received from an electronic device within the first enterprise's network is included in a packet containing a source address that purports to be from the second enterprise's network. The DNS-based attack defense engine 120 is able to detect that a packet containing a DNS query includes a source address that does not belong to the first enterprise's network. The DNS-based attack defense engine 120 is able to access network address information 132 in the storage medium 126, where the network address information 132 can indicate an address range of network addresses within the first enterprise's network. The DNS-based attack defense engine 120 can compare the source network address in a packet containing a DNS query with respect to the network address information 132 to determine whether the source network address does not belong to the first enterprise's network. The DNS-based attack defense engine 120 drops such a DNS query and does not provide a DNS response to this DNS query. In other words, the DNS-based attack defense engine 120 can prevent such a DNS query from reaching the DNS engine 140, or can notify the DNS engine 140 not to respond to the DNS query. Alternatively, the DNS-based attack defense engine 120 can rate limit processing of DNS queries.
See also Parag. [0082]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Zhang in view of Yehuda, to include confirm the candidate attack domain as a confirmed attack domain including by
obtaining authoritative nameservers for the domain and issuing an "A" query to ensure
that no "A" records are included and also by determining a packet amplification factor, as taught by Yehuda. This would be convenient to defend against a DNS-based attack (where defending against a DNS-based attack can include preventing the DNS-based attack or restricting the ability of an attacker to exploit DNS for an unauthorized purpose) (Manadhata, Parag. [0014])).
Claim 3. Zhang in view of Yehuda and Manadhata discloses the system of claim 1,
Zhang further discloses wherein the analysis includes extracting a dataset of hosts that (1) are nameservers and (2) resolve to an IP address from the passive DNS records (See Parag. [0050]; malware domain detection using passive DNS further includes determining that a bad IP address (e.g., an IP address determined to be associated with malware) resolves to one or more additional domain addresses using passive DNS information. See Parag. [0055]; malware domain detection using passive DNS further includes determining whether a DNS name server is malicious (e.g., based on a reputation score generated using passive DNS information). See also Parag. [0057]).
Claim 4. Zhang in view of Yehuda and Manadhata discloses the system of claim 1,
Zhang further discloses wherein the analysis includes extracting a dataset that pairs a domain to a nameserver (See Parag. [0079]; the pDNS database 910 stores various passive DNS and public DNS information received from various sources, including passive DNS (pDNS) collectors 902 and 904 and external information crawler 906. In particular, the pDNS database 910 includes DNS resource records that include domain to IP mapping information 912, Whois information 914, geographical IP information 916 (e.g., geo-based locations of IP addresses), and various other passive DNS and public DNS information 918 (e.g., DNS name servers and/or other DNS related information). See also Parag. [0086-0087]).
Claim 7. Zhang in view of Yehuda and Manadhata discloses the system of claim 1,
Yehuda further discloses wherein the analysis includes determining a count that indicates a number of nameserver (NS) records a domain points to (See Page 645, Col 2, lines 20-24; counting the number of name servers for each domain; see Figure 14. While most of the domains have two name servers, 33% have three or more. Results show that the top million domains have an average of 2.52 name servers per domain).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the analysis, taught by Zhang, to include a determining a count that indicates a number of nameserver records a domain points to, as taught by Yehuda. This would be convenient to measure: (i) how many name servers are returned for each domain, (ii) how many name servers are not provided with their corresponding IP addresses (missing glue records), and (iii) which name servers are out-of-bailiwick. (Yehuda, Page 645, Col. 2, lines 5-9).
Claim 8. Zhang in view of Yehuda and Manadhata discloses the system of claim 1,
Yehuda further discloses wherein the analysis includes determining a count of NXNS domains (See Page 645, Col 2, lines 20-24; counting the number of name servers for each domain; see Figure 14. While most of the domains have two name servers, 33% have three or more. Results show that the top million domains have an average of 2.52 name servers per domain).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the analysis, taught by Zhang, to include a determining a count of NXNS records, as taught by Yehuda. This would be convenient to measure: (i) how many name servers are returned for each domain, (ii) how many name servers are not provided with their corresponding IP addresses (missing glue records), and (iii) which name servers are out-of-bailiwick. (Yehuda, Page 645, Col. 2, lines 5-9).
Claim 13. Zhang in view of Yehuda and Manadhata discloses the system of claim 1,
Zhang further discloses wherein the processor is further configured to provide the confirmed attack domain to a data appliance for policy enforcement (See Parag. [0067]; At 704, generating a first cluster of source information associated with a first malware sample is performed (e.g., generating a cluster in a graph, such as a directed graph, using various techniques described herein), in which the first malware sample was determined to be malware, and the first malware sample was determined to be downloaded from a first source. At 706, determining that a second source is associated with malware based on the first cluster is performed. At 708, a responsive action is performed (e.g., a new signature can be generated for new malware, and/or an alert and/or notification to a security vendor, IT/security admin, user, and/or other person or entity associated with the submitted potential malware sample can be generated if new malware was detected, a new malware source was identified, and/or a new malware visited entity was identified, and/or other relationships or new malware related information was identified)).
Claim 14. Zhang discloses a method, comprising:
identifying a candidate attack domain potentially participating as an attacker in an attack based at least in part on an analysis of passive Domain Name System (DNS) data (See Parag. [0047]; passive DNS (pDNS) information is collected, in which DNS responses are collected passively (e.g., by listening to DNS traffic) from distributed sources (e.g., using passive DNS sensors). For example, the passive DNS information can be analyzed and correlated with other information, such as a malware association graph, to identify malicious entities, such as malware domains. See Parag. [0049]; techniques for malware domain detection using passive Domain Name Service (DNS)), including by:
determining that nameserver (NS) count in the passive DNS data associated with the candidate attack domain exceeds a threshold (See Parag. [0049]; determining whether the first domain is a malware domain based on the reputation score for the first domain. In some embodiments, the reputation score is based at least in part on a determination that the first domain resolves to a first Internet Protocol (IP) address associated with a first cluster of the malware association graph, and the first domain is determined to be a malware domain if the reputation score for the first domain exceeds a threshold value, See Parag. [0050]; malware domain detection using passive DNS further includes determining that a bad IP address (e.g., an IP address determined to be associated with malware) resolves to one or more additional domain addresses using passive DNS information. See Parag. [0096]; passive DNS information can facilitate identification of bad DNS name servers. For example, bad name servers or malicious name servers can refer to name servers that are determined to resolve malware domains to malware IPs); and
confirming the candidate attack domain as a confirmed attack domain based at least in part on a validation that includes probing the candidate attack domain (See Parag. [0048]; if a DNS reputation score exceeds a threshold, then the domain can be identified as a malware domain (e.g., and malware samples from that domain can be identified as malware. See Parag. [0058]; malware domain detection using passive DNS further includes providing a framework that monitors different entities in DNS and evaluates the reputations of such entities. For example, the framework can improve the detection accuracy of malicious domains, and the framework can also monitor the malicious activities based on passive DNS information (e.g., passive DNS data)).
Zhang doesn’t explicitly disclose the attack is a NoneXistent NameServer (NXNS) attack, and the nameserver (NS) count is a domain-to-Out- of-Bailiwick nameserver (NS) count; and confirming the candidate attack domain as a confirmed attack domain based at least in part on a validation that includes probing the candidate attack domain, including by obtaining authoritative nameservers for the domain and issuing an "A" query to ensure
that no "A" records are included and also by determining a packet amplification factor.
However, Yehuda discloses a NoneXistent NameServer (NXNS) attack (See Page 631, Col. 2, lines 9-16; analyze the DNS recursive resolver behavior and the interaction between its algorithms and components using the popular BIND server implementation; expose a new vulnerability in recursive resolver algorithms and demonstrate a new attack, called NXNSAttack, which exploits this vulnerability).
a domain-to-Out- of-Bailiwick nameserver (NS) count (See Page 645 col. 2 lines 4-10; rather inspected the NS referral responses received from the authoritative hierarchy in order to measure: (i) how many name servers are returned for each domain, (ii) how many name servers are not provided with their corresponding IP addresses, and (iii) which name servers are out-of-bailiwick. Counting the number of out-of-bailiwick name server).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Zhang, to include an NXNS attack and a domain-to-Out- of-Bailiwick nameserver (NS) count, as taught by Yehuda. This would be convenient to mitigate and reduce the NXNS Attack effect (Yehuda, Page 641, Col. 2, lines 3-4).
Manadhata discloses:
confirming the candidate attack domain as a confirmed attack domain based at least
in part on a validation that includes probing the candidate attack domain, including by
obtaining authoritative nameservers for the domain and issuing an "A" query to ensure
that no "A" records are included and also by determining a packet amplification factor (See Parag. [0031]; DNS engine 140 performs DNS functionality, which includes performing a lookup of a mapping information 144 stored in a storage medium 142 in response to a received DNS query containing a domain name. The mapping information 144 maps domain names to corresponding network addresses (e.g., IP addresses). See Parag. [0061-0062]; DNS-based attack defense engine 120 is able to detect a DNS amplification attack by checking if a DNS query received from an electronic device within the first enterprise's network is included in a packet containing a source address that purports to be from the second enterprise's network. The DNS-based attack defense engine 120 is able to detect that a packet containing a DNS query includes a source address that does not belong to the first enterprise's network. The DNS-based attack defense engine 120 is able to access network address information 132 in the storage medium 126, where the network address information 132 can indicate an address range of network addresses within the first enterprise's network. The DNS-based attack defense engine 120 can compare the source network address in a packet containing a DNS query with respect to the network address information 132 to determine whether the source network address does not belong to the first enterprise's network. The DNS-based attack defense engine 120 drops such a DNS query and does not provide a DNS response to this DNS query. In other words, the DNS-based attack defense engine 120 can prevent such a DNS query from reaching the DNS engine 140, or can notify the DNS engine 140 not to respond to the DNS query. Alternatively, the DNS-based attack defense engine 120 can rate limit processing of DNS queries.
See also Parag. [0082]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Zhang in view of Yehuda, to include confirm the candidate attack domain as a confirmed attack domain including by
obtaining authoritative nameservers for the domain and issuing an "A" query to ensure
that no "A" records are included and also by determining a packet amplification factor, as taught by Yehuda. This would be convenient to defend against a DNS-based attack (where defending against a DNS-based attack can include preventing the DNS-based attack or restricting the ability of an attacker to exploit DNS for an unauthorized purpose) (Manadhata, Parag. [0014])).
Claim 15. Zhang discloses a computer program product embodied in a non-transitory computer readable medium and comprising computer instructions (See Parag. [0019]) for:
identifying a candidate attack domain potentially participating as an attacker in an attack based at least in part on an analysis of passive Domain Name System (DNS) data (See Parag. [0047]; passive DNS (pDNS) information is collected, in which DNS responses are collected passively (e.g., by listening to DNS traffic) from distributed sources (e.g., using passive DNS sensors). For example, the passive DNS information can be analyzed and correlated with other information, such as a malware association graph, to identify malicious entities, such as malware domains. See Parag. [0049]; techniques for malware domain detection using passive Domain Name Service (DNS)), including by:
determining that a nameserver (NS) count in the passive DNS data associated with the candidate attack domain exceeds a threshold (See Parag. [0049]; determining whether the first domain is a malware domain based on the reputation score for the first domain. In some embodiments, the reputation score is based at least in part on a determination that the first domain resolves to a first Internet Protocol (IP) address associated with a first cluster of the malware association graph, and the first domain is determined to be a malware domain if the reputation score for the first domain exceeds a threshold value, See Parag. [0050]; malware domain detection using passive DNS further includes determining that a bad IP address (e.g., an IP address determined to be associated with malware) resolves to one or more additional domain addresses using passive DNS information. See Parag. [0096]; passive DNS information can facilitate identification of bad DNS name servers. For example, bad name servers or malicious name servers can refer to name servers that are determined to resolve malware domains to malware IPs); and
confirming the candidate attack domain as a confirmed attack domain based at least in part on a validation that includes probing the candidate attack domain (See Parag. [0048]; if a DNS reputation score exceeds a threshold, then the domain can be identified as a malware domain (e.g., and malware samples from that domain can be identified as malware. See Parag. [0058]; malware domain detection using passive DNS further includes providing a framework that monitors different entities in DNS and evaluates the reputations of such entities. For example, the framework can improve the detection accuracy of malicious domains, and the framework can also monitor the malicious activities based on passive DNS information (e.g., passive DNS data)).
Zhang doesn’t explicitly disclose the attack is a NoneXistent NameServer (NXNS) attack, and the nameserver (NS) count is a domain-to-Out- of-Bailiwick nameserver (NS) count; and confirming the candidate attack domain as a confirmed attack domain based at least in part on a validation that includes probing the candidate attack domain, including by obtaining authoritative nameservers for the domain and issuing an "A" query to ensure
that no "A" records are included and also by determining a packet amplification factor.
However, Yehuda discloses a NoneXistent NameServer (NXNS) attack (See Page 631, Col. 2, lines 9-16; analyze the DNS recursive resolver behavior and the interaction between its algorithms and components using the popular BIND server implementation; expose a new vulnerability in recursive resolver algorithms and demonstrate a new attack, called NXNSAttack, which exploits this vulnerability).
a domain-to-Out- of-Bailiwick nameserver (NS) count (See Page 645 col. 2 lines 4-10; rather inspected the NS referral responses received from the authoritative hierarchy in order to measure: (i) how many name servers are returned for each domain, (ii) how many name servers are not provided with their corresponding IP addresses, and (iii) which name servers are out-of-bailiwick. Counting the number of out-of-bailiwick name server).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Zhang, to include an NXNS attack and a domain-to-Out- of-Bailiwick nameserver (NS) count, as taught by Yehuda. This would be convenient to mitigate and reduce the NXNS Attack effect (Yehuda, Page 641, Col. 2, lines 3-4).
Manadhata discloses:
confirming the candidate attack domain as a confirmed attack domain based at least
in part on a validation that includes probing the candidate attack domain, including by
obtaining authoritative nameservers for the domain and issuing an "A" query to ensure
that no "A" records are included and also by determining a packet amplification factor (See Parag. [0031]; DNS engine 140 performs DNS functionality, which includes performing a lookup of a mapping information 144 stored in a storage medium 142 in response to a received DNS query containing a domain name. The mapping information 144 maps domain names to corresponding network addresses (e.g., IP addresses). See Parag. [0061-0062]; DNS-based attack defense engine 120 is able to detect a DNS amplification attack by checking if a DNS query received from an electronic device within the first enterprise's network is included in a packet containing a source address that purports to be from the second enterprise's network. The DNS-based attack defense engine 120 is able to detect that a packet containing a DNS query includes a source address that does not belong to the first enterprise's network. The DNS-based attack defense engine 120 is able to access network address information 132 in the storage medium 126, where the network address information 132 can indicate an address range of network addresses within the first enterprise's network. The DNS-based attack defense engine 120 can compare the source network address in a packet containing a DNS query with respect to the network address information 132 to determine whether the source network address does not belong to the first enterprise's network. The DNS-based attack defense engine 120 drops such a DNS query and does not provide a DNS response to this DNS query. In other words, the DNS-based attack defense engine 120 can prevent such a DNS query from reaching the DNS engine 140, or can notify the DNS engine 140 not to respond to the DNS query. Alternatively, the DNS-based attack defense engine 120 can rate limit processing of DNS queries.
See also Parag. [0082]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the teaching, taught by Zhang in view of Yehuda, to include confirm the candidate attack domain as a confirmed attack domain including by
obtaining authoritative nameservers for the domain and issuing an "A" query to ensure
that no "A" records are included and also by determining a packet amplification factor, as taught by Yehuda. This would be convenient to defend against a DNS-based attack (where defending against a DNS-based attack can include preventing the DNS-based attack or restricting the ability of an attacker to exploit DNS for an unauthorized purpose) (Manadhata, Parag. [0014])).
Claim 16. The applicant is directed to the rejections to claim 3 set forth above, as they are rejected based on the same rationale.
Claim 17. The applicant is directed to the rejections to claim 4 set forth above, as they are rejected based on the same rationale.
Claim 20. The applicant is directed to the rejections to claim 7 set forth above, as they are rejected based on the same rationale.
Claim 21. The applicant is directed to the rejections to claim 8 set forth above, as they are rejected based on the same rationale.
Claim 24. The applicant is directed to the rejections to claim 13 set forth above, as they are rejected based on the same rationale.
Claim 25. The applicant is directed to the rejections to claim 3 set forth above, as they are rejected based on the same rationale.
Claim 26. The applicant is directed to the rejections to claim 4 set forth above, as they are rejected based on the same rationale.
Claim 29. The applicant is directed to the rejections to claim 7 set forth above, as they are rejected based on the same rationale.
Claim 30. The applicant is directed to the rejections to claim 8 set forth above, as they are rejected based on the same rationale.
Claim 31. The applicant is directed to the rejections to claim 13 set forth above, as they are rejected based on the same rationale.
Claims 5-6, 11-12, 18-19, 22-23, and 27-28 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang et al. (Pub. No. US 2018/0041521), hereinafter Zhang; in view Yehuda et al. (NXNSAttack: Recursive DNS Inefficiencies and Vulnerabilities, 12-14-2020, usenix), hereinafter Yehuda; in view of Manadhata et al. (Pub. No. US 2020/0204581), hereinafter Manadhata; and in further view of Mahjoub et al. (Pub. No. US 2017/0041333), hereinafter Mahjoub as applied to claim 1 above.
Claim 5. Zhang in view of Yehuda and Manadhata discloses the system of claim 4,
Zhang in view of Yehuda doesn’t explicitly disclose wherein the domain is paired at a second-level domain (SLD) level.
However, Mahjoub discloses wherein the domain is paired at a second-level domain (SLD) level (See Parag. [0055]; the CDD system extracts hostname and SLD information, including, the hostname and hostname IP address, the SLD and SLD IP address, the ASN of the hostname, and the ASN of the SLD).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the DNS data, taught by Zhang in view of Yehuda, to include wherein the domain is paired at a second-level domain (SLD) level, as taught by Mahjoub. This would be convenient to trace the evolution of domain to IP address mappings, and the evolution of domain to name server mappings over time. This information is leveraged to provide protective security and reactive incident response (Mahjoub, Parag. [0042]).
Claim 6. Zhang in view of Yehuda and Manadhata discloses the system of claim 1,
Zhang in view of Yehuda doesn’t explicitly disclose wherein the analysis includes joining and aggregating (1) a dataset of hosts that (a) are nameservers and (b) resolve to an IP address with (2) a dataset that pairs a domain to a nameserver.
However, Mahjoub discloses wherein the analysis includes joining and aggregating (1) a dataset of hosts that (a) are nameservers and (b) resolve to an IP address with (2) a dataset that pairs a domain to a nameserver (See Parag. [0042]; The passive DNS logs may also include domain name to IP address mappings and/or other DNS or IP-related information; the passive DNS logs can include information recorded over time based on traffic between one or more recursive resolvers or name servers and the various authoritative name servers spread out across the Internet. The passive DNS logs may be used to generate historical records that represents domain name to IP address mappings over time).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the DNS data, taught by Zhang in view of Yehuda, to include wherein the analysis includes joining and aggregating (1) a dataset of hosts that (a) are nameservers and (b) resolve to an IP address with (2) a dataset that pairs a domain to a nameserver, as taught by Mahjoub. This would be convenient to trace the evolution of domain to IP address mappings, and the evolution of domain to name server mappings over time. This information is leveraged to provide protective security and reactive incident response (Mahjoub, Parag. [0042]).
Claim 18. The applicant is directed to the rejections to claim 5 set forth above, as they are rejected based on the same rationale.
Claim 19. The applicant is directed to the rejections to claim 6 set forth above, as they are rejected based on the same rationale.
Claim 22. The applicant is directed to the rejections to claim 11 set forth above, as they are rejected based on the same rationale.
Claim 23. The applicant is directed to the rejections to claim 12 set forth above, as they are rejected based on the same rationale.
Claim 27. The applicant is directed to the rejections to claim 5 set forth above, as they are rejected based on the same rationale.
Claim 28. The applicant is directed to the rejections to claim 6 set forth above, as they are rejected based on the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO-form 892).
The following Patents and Papers are cited to further show the state of the art at the time of Applicant’s invention with respect to identifying and blocking domains used for NXNS-based DDOS attack.
Martini (Patent No. US 11,489,858); “Malware Detection for Proxy Server Networks;”
Teaches methods and systems for applying network policies to devices based on their current access network. One example method includes identifying a proxy connection request sent from a particular client device to a proxy server over a network, the proxy connection request including a hostname and configured to direct the proxy server to establish communication with the computer identified by the hostname on behalf of the client device; determining an identity of the client device based on the proxy connection request; identifying a domain name system (DNS) response to a DNS request including the hostname from the proxy connection request; and updating DNS usage information for the particular client based on the identified DNS response including the hostname from the proxy connection request. (See Abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GHIZLANE MAAZOUZ whose telephone number is (571)272-8118. The examiner can normally be reached Telework M-F 7:30-5 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, Philip J Chea can be reached on 571-272-3951. 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.
/GHIZLANE MAAZOUZ/Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights