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 .
Response to Amendment
The amendment filed on October 8, 2025 has been entered.
Claims 1 and 14-15 have been amended.
Claim 2 has been canceled.
Claims 16-24 have been added.
Response to Arguments
Applicant's arguments filed on October 8, 2025, have been fully considered, but they are moot in view of the new grounds of rejections.
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, and 24 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.
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.
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).
Claim 3. Zhang in view of Yehuda 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 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 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 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 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.
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).
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.
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).
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.
Claims 5-6, 11-12, 18-19, and 22-23 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; 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 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 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 11. Zhang in view of Yehuda discloses the system of claim 1,
Zhang in view of Yehuda doesn’t explicitly disclose wherein confirming the candidate attack domain includes obtaining one or more authoritative nameservers for the candidate attack domain and issuing a DNS A query against the obtained nameservers.
However, Mahjoub discloses wherein confirming the candidate attack domain includes obtaining one or more authoritative nameservers for the candidate attack domain and issuing a DNS A query against the obtained nameservers (See Parag. [0053]; the CDD subsystem utilizes DNS traffic above a recursive DNS name server level to detect and classify malicious domains. The traffic is typically captured in authoritative logs that are returned from authoritative name servers in response to DNS queries from a recursive DNS nameserver or resolver. The authoritative logs include DNS information such as an IP address for a hostname submitted in a query).
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 confirming the candidate attack domain includes obtaining one or more authoritative nameservers for the candidate attack domain and issuing a DNS A query against the obtained nameservers, 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 12. Zhang in view of Yehuda discloses the system of claim 1,
Zhang in view of Yehuda doesn’t explicitly disclose wherein confirming the candidate attack domain includes checking DNS responses to determine a packet amplification factor.
However, Mahjoub discloses wherein confirming the candidate attack domain includes checking DNS responses to determine a packet amplification factor (See Parag. [0126] a spike in DNS traffic is caused by a DNS amplification attack. In an amplification attack, the attacker spoofs DNS requests to hide the source of an attack. Typically, the requests are received from servers that look valid and are embedded in traffic that looks valid. The techniques used herein can analyze the history of the domains (which is non-existent leading up to the spike), as well as other features of the queries included in the spike to detect this attack and flag the associated domains as malicious...).
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 confirming the candidate attack domain includes checking DNS responses to determine a packet amplification factor, 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.
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.
Khalil et al. (Pub. No. US 2018/0343272); “Method to Identify Malicious Domain Names Thanks to Their Dynamics;”
Teaches A technique of some embodiments discovers malicious domains by analyzing passive DNS data. Some embodiments take advantage of the dynamic nature of malicious domains to discover strong associations among them, which are further used to infer malicious domains from a set of existing known malicious ones. Some embodiments further utilize heuristics to handle complicated practical issues (such as web hosting) to improve both the effectiveness and efficiency of the technique. Experimental results show that some embodiments can achieve high true positive rates and low false positive rates with good expansion, i.e., discovering a significantly large set of potentially malicious domains with a small set of seeds (see Parag. [0139]).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. 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 extension fee 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 date of this final action.
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