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 9/19/2025 has been entered.
Response to Arguments
Applicant’s arguments, see pages 7 and 8, filed 9/19/2025, with respect to the rejection of claims 5 and 13 under 35 USC 112(a) have been fully considered and are persuasive. This rejection has been withdrawn.
Applicant's arguments, see pages 8 and 9, filed 9/19/2025, with respect to the rejection of claims 1-20 under 35 USC 103 have been fully considered.
Regarding the argument:
“The rejection of claim 1 asserts Manadhata '581 discloses, when the additional DNS request information associated with the computing device satisfies the one or more criteria, preventing the computing device from exchanging communications with a destination device associated with a DNS request. Manadhata '581 fails to disclose the above-quoted limitations now recited by claim 1.”
Examiner notes that this argument is persuasive. Additionally, the scope of the claims is changed in light of the amendments. For these reasons, this rejection is withdrawn.
Regarding the argument:
“Manadhata '581 discloses, "in response to the attack alert, the DNS-based attack defense engine 120 can trigger the remediation engine 122 to take a countermeasure action to address the DDoS attack from malware infected electronic devices of the first enterprise on the name server 118 of the second enterprise" (see 0046). The countermeasure action may include "blocking of the DNS queries or data communication" from the infected device (see 0048). In summary, Manadhata '581 discloses a mechanism to stop a device that is performing a DDoS. Manadhata '581 does not disclose that data communication is blocked in response to a deviation of additional DNS information from one or more trends, as captured by claim 1.”
This argument is persuasive; however, upon further consideration, a new ground(s) of rejection is made in view of ESTEP et al (Doc ID US 11843624 B1).
Regarding the argument:
“Moreover, it does not make sense to combine the teachings of Manadhata '581 with Sivaraman to disclose the above recited limitations of claim 1. The rejection of claim 1 asserts Sivaraman discloses "each model learns the normal behavior of one device type." Even if the models are considered trends, there is no teaching or suggestion in Sivaraman that a deviation from the model would trigger preventing the computing device from exchanging communications with the destination device, as recited by claim 1. Likewise, Manadhata '581 does not teach that deviation from a device-type model like that taught by Sivaraman would trigger a DDoS countermeasure action since such a deviation would not be indicative of a DDoS attack. Thus, the combination of Manadhata '581 with Sivaraman is improper.
Examiner respectfully disagrees. It is the “normal behavior” of SIVARAMAN which is mapped to the claimed “trends.” While the change in scope of the claims has necessitates withdrawal of the rejection and a new grounds of rejection, the motivation to combine is similar, and examiner further notes that where the claimed trends [normal behavior] is supplied by SIVARAMAN, it is modified by other prior art which recognizes deviation in a set of data and takes mitigation actions which include blocking of communication.
Regarding the argument:
“Dependent claim 3 recites identifying domains associated with DNS requests from the one or more computing devices of the first type and identifying frequencies of requests associated with the domains.
“The rejection of claim 3 asserts Manadhata '241 discloses "the prediction engine 108 may extract ... a number of DNS queries by the enterprise entity..." A mere number is not a frequency, much less frequencies associated with domains, as recited by claim 3.”
Examiner respectfully disagrees. One skilled in the art would recognize that any analysis of DNS requests would reveal domains associated with the request. Further, it is unclear by what definition the “number of DNS queries” of MANADHATA ‘241 is not equivocal to the “frequencies of requests” of claim 3. Even given an unnecessarily strict definition of a “frequency” of occurrences over a given time, the prior art maps to this given a “number of DNS queries” over any given collection period, and easily maps to the broadest reasonable interpretation of the claimed “frequencies of requests.” This portion of the rejection is maintained.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, at the time the application was filed, had possession of the claimed invention.
Regarding claims 1, 9, and 18:
Claim 1 recites, “identifying a DNS request from the computing device requesting an address of a destination device”. Claims 9 and 18 recite similar language. These limitations are not supported by the specification, and constitute new matter. The specification, in numerous locations, teaches obtaining destination domain information from DNS request data; however, the disclosure does not support obtaining information about a destination device from DNS request information. Further, examiner notes that given only DNS request information, identification of a destination device is not possible, and even if it were to be taught in the specification, would not be enabled without additional guidance explaining how a specific device would be identified given the available data in a DNS query and/or response. For the purposes of this examination and in the interest of compact prosecution, this limitation will be interpreted with the assumption of a forthcoming amendment and as reciting identifying a DNS request requesting the address of a destination domain.
These rejections can be overcome by amending the claims such the limitations are supported by the specification.
Regarding claims 2-8, 10-17, 19, and 20:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
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.
Claims 1-6, 9-14, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over ESTEP et al (Doc ID US 11843624 B1), and further in view of SIVARAMAN et al (Doc ID US 20220086071 A1) and MANADHATA et al (Doc ID US 20180176241 A1).
Regarding claim 1:
ESTEP teaches:
identifying a DNS request from the computing device requesting an address of a destination device (Col 21 lines 8-11 "Cloud C2 Traffic Analyzer 112 in NSS 110 investigates whether a hostname access pattern is anomalous 112g in DNS queries by causing NSS 110 extract features such as the URLs included in the queries."); and
Examiner notes that this limitation is addressed in a rejection under 35 USC 112(a), and being given an interpretation consistent with the specification (i.e. requesting an address of a destination domain). Examiner further notes that the inherent purpose of a DNS query is to request an address for a destination domain.
when the additional DNS request information indicates a deviation from the one or more trends, preventing the computing device from exchanging communications with the destination device at the address (Col 15 lines 56-64 "… when a resource is determined to be likely malicious, NSS 110 blocks incoming request 202 from transmission 236 and ... preventing access to the cloud resource as a whole …").
ESTEP does NOT teach:
A method comprising: obtaining domain name system (DNS) request information associated with one or more computing devices of a first type of a plurality of device types,
wherein each device type of the plurality of device types comprises one or more devices performing an operation different from operations performed by devices of other device types;
identifying one or more trends associated with the DNS request information and applicable to devices of the first type with other trends being applicable to other device types of the plurality of device types;
monitoring additional DNS request information associated with a computing device of the first type;
SIVARAMAN teaches:
A method comprising: obtaining domain name system (DNS) request information associated with one or more computing devices of a first type of a plurality of device types ([0058] "… the network traffic behaviours of each of the networked devices include packet and byte counts of network flows … the network flows being: [0059] (i) upstream and downstream DNS flows …"),
wherein each device type of the plurality of device types comprises one or more devices performing an operation different from operations performed by devices of other device types ([0066] "processing the device behaviour data to classify a plurality of the networked devices as IoT devices, and others of the networked devices as non-IoT devices;");
identifying one or more trends associated with the DNS request information and applicable to devices of the first type with other trends being applicable to other device types of the plurality of device types ([0217] "Although each model learns the normal behavior of one device type, different devices can display somewhat similar traffic behaviour (e.g., DNS, NTP or SSDP) for a short period of time …");
Identifying DNS requests for domain addresses and determining when those requests deviate from known behavior, resulting in preventing communication with the suspect domain, are known techniques in the art, as demonstrated by ESTEP. Further, obtaining DNS request information from a distinct group of devices and identifying trends in the data associated with the DNS requests are known techniques in the art, as demonstrated by SIVARAMAN. It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to modify the DNS request anomaly detection of ESTEP with the DNS request collection and trend calculation of SIVARAMAN with the motivation to detect when given data deviates from an established trend of normal data in DNS requests for a group of devices. It would have been obvious to seek a method to identify trends in data obtained from a group of devices instead of a single device.
The combination of ESTEP and SIVARAMAN does NOT teach:
monitoring additional DNS request information associated with a computing device of the first type;
MANADHATA teaches this limitation:
[0054] "... the detection engine 110 may access actual feature values of the enterprise entity for the particular time period …"
Continuing to collect DNS data from a known device is a known technique in the art, as demonstrated by MANADHATA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the DNS request trend deviation detection of ESTEP and SIVARAMAN with the additional DNS data collection of MANADHATA with the motivation to accumulate “new” data which may be compared in order to determine a deviation in a previous trend in the data.
Regarding claim 2:
The combination of ESTEP, SIVARAMAN, and MANADHATA teaches:
The method of claim 1, wherein the computing device comprises a physical computing device or a virtual machine (MANADHATA [0060] "… The processor(s) may include ... any hardware device suitable for executing instructions stored on a ... physical storage device that stores executable instructions ...").
Utilizing physical or virtual machines for DNS analysis is a known technique in the art, as demonstrated by MANADHATA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the DNS request trend deviation detection of ESTEP, SIVARAMAN, and MANADHATA with the physical and virtual machines of MANADHATA with the motivation to provide flexibility to the system by accommodating both physical and virtual machines, as the DNS data collected from each would be similar to each other to the degree that it is obvious to support the use of either.
Regarding claim 3:
The combination of ESTEP, SIVARAMAN, and MANADHATA teaches:
The method of claim 1, wherein identifying the one or more trends associated with the DNS request information comprises identifying domains associated with DNS requests from the one or more computing devices of the first type and identifying frequencies of requests associated with the domains (MANADHATA [0024] "the prediction engine 108 may extract … a number of DNS queries by the enterprise entity ...").
Collecting domain information from DNS queries as part of DNS information analysis is a known technique in the art, as demonstrated by MANADHATA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the DNS request trend deviation detection of ESTEP, SIVARAMAN, and MANADHATA with the domain data collection of MANADHATA with the motivation to collect the most typical data available in a DNS query and/or response. It is obvious to collect domain information as domain information is the primary purpose of DNS requests.
Regarding claim 4:
The combination of ESTEP, SIVARAMAN, and MANADHATA teaches:
The method of claim 1, wherein identifying the one or more trends associated with the DNS request information comprises identifying the one or more trends associated with the DNS request information during a trial period (MANADHATA [0023] "From the enterprise log data 240, the prediction engine 108 may extract time-series data.").
Identifying DNS trend data over a particular time period is a known technique in the art, as demonstrated by MANADHATA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the DNS request trend deviation detection of ESTEP, SIVARAMAN, and MANADHATA with the time-series data of MANADHATA with the motivation to limit collection to a period of time. It is obvious to examiner particular windows of time in the data so as not to overwhelm the system.
Regarding claim 5:
The combination of ESTEP, SIVARAMAN, and MANADHATA teaches:
The method of claim 1, wherein preventing the computing device from exchanging communications with the destination device comprises blocking the DNS request from the computing device (ESTEP Col 15 lines 56-64 "… when a resource is determined to be likely malicious, NSS 110 blocks incoming request 202 from transmission 236 and ... preventing access to the cloud resource as a whole …").
Regarding claim 6:
The combination of ESTEP, SIVARAMAN, and MANADHATA teaches:
The method of claim 1, wherein preventing the computing device from exchanging communications with the destination device comprises blocking connections to the address (ESTEP Col 15 lines 56-64 "… when a resource is determined to be likely malicious, NSS 110 blocks incoming request 202 from transmission 236 and ... preventing access to the cloud resource as a whole …").
Regarding claim 9:
ESTEP teaches:
A computing apparatus comprising: a storage system; a processing system operatively coupled to the storage system; and program instructions stored on the storage system that, when executed by the processing system, direct the computing apparatus to (Col 26 lines 24-27 "Storage subsystem 1110 stores programming and data constructs that provide the functionality ... described herein. These software modules are generally executed by processors 1178."):
The remainder of the claim is rejected with the same justification, mutatis mutandis, as its counterpart claim 1 above.
Regarding claim 17:
The combination of ESTEP, SIVARAMAN, and MANADHATA teaches:
The computing apparatus of claim 9, wherein the DNS request information further comprises location information for one or more DNS servers for DNS requests from the one or more computing devices and records associated with the one or more DNS servers (MANADHATA [0024] "the prediction engine 108 may extract … a number of DNS queries by the enterprise entity ...".).
Examiner notes that DNS server location is universally contained in the IP header of every DNS query sent by a device. It is implicit that in collecting DNS query information, information about the location of one or more DNS servers would be collected as well.
Collecting location information as part of DNS request information collection is a known technique in the art, as demonstrated by MANADHATA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the DNS request trend deviation detection of ESTEP, SIVARAMAN, and MANADHATA with the location data collection of MANADHATA with the motivation to utilize general locations of queries to filter and classify DNS data. It is obvious to collect data about locations of DNS requests as this information is already available in the general data being collected.
Regarding claims 10-14, and 18-20:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 1-6 above.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over ESTEP et al (Doc ID US 11843624 B1), SIVARAMAN et al (Doc ID US 20220086071 A1), and MANADHATA et al (Doc ID US 20180176241 A1) as applied to claims 1 and 9 above, and further in view of MANADHATA et al (Doc ID US 20200204581 A1).
Regarding claim 7:
The combination of ESTEP, SIVARAMAN, and MANADHATA ‘6241 teaches:
The method of claim 1,
The combination of ESTEP, SIVARAMAN, and MANADHATA ‘6241 does NOT teach:
comprising: generating a notification for an administrator, wherein the notification indicates at least one domain associated with the deviation and/or a frequency of DNS requests associated with the deviation.
MANADHATA ‘4581 teaches this limitation:
"The countermeasure action can include … inform the second enterprise's network administrator(s) …"
Notifying a system administrator as a response action is a known technique in the art, as demonstrated by MANADHATA ‘4581. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the DNS monitoring and trend identification method of ESTEP, SIVARAMAN, and MANADHATA ‘6241 with the administrator notification of MANADHATA ‘4581 with the motivation to make administrators aware of potentially harmful behavior present on a system. It is obvious to notify administrators so that actions may be taken which the system is unauthorized to take without administrator permission.
Regarding claim 15:
This claim is rejected with the same justification, mutatis mutandis, as its counterpart claim 7 above.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over MANADHATA et al (Doc ID US 20180176241 A1), SIVARAMAN et al (Doc ID US 20220086071 A1), and MANADHATA et al (Doc ID US 20200204581 A1) as applied to claims 7 and 15 above, and further in view of SATISH et al (Doc ID US 20160164919 A1).
Regarding claim 8:
The combination of ESTEP, SIVARAMAN, MANADHATA ‘6241, and MANADHATA ‘4581 teaches:
The method of claim 7,
The combination of ESTEP, SIVARAMAN, MANADHATA ‘6241, and MANADHATA ‘4581 does NOT teach:
wherein the notification further comprises a suggested action for mitigating the deviation and wherein the method further comprises: identify a request to implement the suggested action; and
in response to the request, initiate the suggested action, wherein the suggested action limits one or more connections by the computing device.
SATISH teaches:
wherein the notification further comprises a suggested action for mitigating the deviation and wherein the method further comprises: identify a request to implement the suggested action ([0021] "... advisement system 130 notifies administrator 160 of the security incident (202)." and [0022] "Once the information is provided ... obtain an action request from administrator …"); and
in response to the request, initiate the suggested action, wherein the suggested action limits one or more connections by the computing device ([0021] "… These action recommendations may include ... blocking one or more IP addresses related to a threat …").
Suggesting a mitigation action of limiting connections, identifying a response to the suggestion, and implementing the suggestion based on the response are known techniques in the art, as demonstrated by SATISH. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the DNS monitoring method of ESTEP, SIVARAMAN, MANADHATA ‘6241, and MANADHATA ‘4581 with the mitigation action suggestion and implementation method of SATISH with the motivation to streamline the response process by providing administrators with their best and/or most likely courses of action. It is obvious to provide these suggestions so that administrators do not have to formulate responses from scratch when responding to a potential security incident.
Regarding claim 16:
This claim is rejected with the same justification, mutatis mutandis, as its counterpart claim 8 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
BAGNALL (Doc ID US 20200106791 A1) recites a similar method for monitoring DNS activity for trends, but lacks the reactions and mitigation methods of the instant application.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON BINCZAK whose telephone number is (703)756-4528. The examiner can normally be reached M-F 0800-1700.
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, Alexander Lagor can be reached on (571) 270-5143. 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.
/BB/Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437