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 page(s) 8, filed 4/30/2026, with respect to the rejection of claim(s) 1, 9, and 18 under 35 USC 112(a) have been fully considered.
Regarding claim 1:
The amendments have sufficiently addressed the rejection. This rejection is withdrawn.
Regarding claims 9 and 18:
The amendments have not addressed this rejection. These rejections are maintained.
Applicant's arguments, see pages 8-11, filed 9/19/2025, with respect to the rejection of claims 1-20 under 35 USC 103 have been fully considered but they are not persuasive.
Applicant arguments are directed to amended independent claims 1, 9, and 18. Examiner notes that the relevant amended limitation of Claim 1 (and similarly claims 9 and 18) represents new matter, and is the subject of a rejection under 35 U.S.C. 112(a) in this Office Action. Based on the supported portion of the claim limitations in question, this rejection is maintained. However, due to the change in scope created by other amendments, new grounds for rejection is provided under MIZRACHI et al (Doc ID US 20160255012 A1) and APOSTOLOPOULOS et al (Doc ID US 20200044927 A1).
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 (emphasis added), “… wherein each device type of the plurality of device types comprises one or more devices assigned to the device type by an administrator …”. Claims 9 and 18 recite similar language. This limitation as amended is not supported by the specification, and constitutes new matter. Applicant offers ¶¶ 0011, 0013, and 0019 as support for this amended limitation. The relevant portions of these paragraphs are as follows:
[0011] “… Each of computing device groups 120-121 can include any number of computing devices, wherein the computing devices can include physical computers (e.g., user devices, servers, and the like) or virtualized endpoints (e.g., virtual machines, containers, and the like).”
Examiner notes that it follows to interpret “user devices, servers, virtual machines, containers, and the like” as device types, where a device group is made up of any number of devices of any type.
[0013] “… In some examples, each computing device group of computing device groups 120-121 can be assigned by an administrator of computing environment 100. For example, an administrator may define computing device group 120 that corresponds to a first division of an organization, while computing device group 121 can comprise a second division of the organization.
Examiner notes that the specification explicitly teaches that an administrator assigns devices to device groups; this paragraph is silent regarding an administrator assigning a device type.
[0019] “. In some examples, computing devices in a computing environment can be assigned to different device groups, which represent different types of devices. For example, devices providing a first operation can be assigned to a first group, while devices providing a second operation can be assigned to a second group.”
Examiner notes that this excerpt is somewhat ambiguous. It is not certain whether this excerpt is defining a “group” as a collection of devices of a single “type”; or whether it is defining groups as each representing “different types of devices.” However, for the former interpretation to be true, then it follows that an “operation” (defined as first, second, etc.) of a device is what defines its “type.”
[0019] “… The different types of devices or device groups can be defined by an administrator …”
Examiner notes that “defining” a group or type of device is not the same as “assigning” a device to said group or type. In the art, “defining” refers constructing a data type, or more relevantly, enumerating elements to which things will later be assigned. For example, one of ordinary skill in the art would expect defining types of devices to be a list such as, [server, laptop, smartphone, network monitor, etc.]. Whereas one of ordinary skill in the art would interpret assigning device types as indicating which of the defined device types are assigned to a given device.
[0043] “… A user can indicate a type associated with each device, such DNS requests for similar devices can be grouped together.”
This portion of the specification is most closely aligned with the amended limitation, but teaches a user who assigns a device its type, and not an administrator. One of ordinary skill in the art would be much more likely to equate “indicating” with “assigning” than they would to equate “defining” with “assigning.”
Claim 1 further recites, “… generating, in response to receiving an approval, an approved DNS request configuration …”. Claims 9 and 18 recite similar language. This limitation is not supported by the specification, and constitutes new matter. The specification teaches generation of an “approved DNS request configuration,” but only in response to receiving DNS request information (¶ 0034 and Fig. 5).
Regarding claims 9, and 18:
Claim 9 recites, “… identify a DNS request from the computing device requesting an address of a destination device …”. Claim 18 recites 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 10-17, 19, and 20:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection can 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 MIZRACHI et al (Doc ID US 20160255012 A1), and further in view of SIVARAMAN et al (Doc ID US 20220086071 A1), APOSTOLOPOULOS et al (Doc ID US 20200044927 A1), and MANADHATA et al (Doc ID US 20180176241 A1).
Regarding claim 1:
MIZRACHI teaches:
identifying a DNS request from the computing device requesting an address of a destination domain ([0061] "… In block 420, the module 270 determines if the packet is a DNS request …"); and
when the additional DNS request information indicates a deviation from the approved DNS request configuration, preventing the computing device from exchanging communications with the destination domain at the address ([0062] "If the destination IP address does not appear in the whitelist, then the DNS server cannot be confirmed as legitimate .... If the policy indicates that packets destined to a DNS server whose legitimacy cannot confirmed are supposed to be blocked, then in block 470, the packet is discarded.").
SIVARAMAN teaches the following limitation(s) not taught by MIZRACHI:
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 assigned to the device type … and 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 …");
generating, in response to receiving an approval, an approved DNS request configuration based on the one or more trends ([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 …");
Examiner notes that “behaviors” of the prior art is mapped to “trends” of the claims, and the “normal behavior” generated by the prior art maps to the “approved DNS configuration” of the claims.
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 MIZRACHI. Further, obtaining DNS request information from a distinct group of devices with assigned device types, identifying trends (behaviors) in the data associated with the DNS requests, and identifying a normal or approved trend 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 MIZRACHI 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.
APOSTOLOPOULOS teaches the following limitations not taught by the combination of MIZRACHI and SIVARAMAN:
wherein each device type of the plurality of device types comprises one or more devices assigned to the device type by an administrator ([0001] "… Generally, to group devices, a network administrator manually groups devices based on a static attribute (e.g., role of person using device or type of device) of the device.") …
Examiner notes that even were the amended portion of this claim not subject to the included rejection under 35 U.S.C. 112(a), that an administrator may have assigned devices their type is considered insignificant extra-solution activity (as well as organization of human activity, which is ineligible subject matter), as the origin of the relevant data has no functional impact on the method of the invention. This portion of the limitation need not receive patentable weight. Prior art is provided here in the interest of compact prosecution.
An administrator assigning devices to device types is a known technique in the art, as demonstrated by APOSTOLOPOULOS. 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 MIZRACHI and SIVARAMAN with the device type assigning administrator of APOSTOLOPOULOS with the motivation to use manual entry for determining device types in the event that automatic classification is not desired or appropriate.
MANADHATA teaches the following limitations not taught by the combination of MIZRACHI, SIVARAMAN, and APOSTOLOPOULOS:
monitoring additional DNS request information associated with a computing device of the first type ([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 MIZRACHI, SIVARAMAN, and APOSTOLOPOULOS 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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 (MIZRACHI [0062] "If the destination IP address does not appear in the whitelist, then the DNS server cannot be confirmed as legitimate .... If the policy indicates that packets destined to a DNS server whose legitimacy cannot confirmed are supposed to be blocked, then in block 470, the packet is discarded.").
Regarding claim 6:
The combination of MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 (MIZRACHI [0062] "If the destination IP address does not appear in the whitelist, then the DNS server cannot be confirmed as legitimate .... If the policy indicates that packets destined to a DNS server whose legitimacy cannot confirmed are supposed to be blocked, then in block 470, the packet is discarded.").
Regarding claim 9:
MIZRACHI 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 ([0071] "… embodiments ... are performed by a data processor ... for executing a plurality of instructions. ... and/or a non-volatile storage, for example, non-transitory storage media … for storing instructions …"):
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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 MIZRACHI et al (Doc ID US 20160255012 A1), SIVARAMAN et al (Doc ID US 20220086071 A1), APOSTOLOPOULOS et al (Doc ID US 20200044927 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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, and MANADHATA ‘6241 teaches:
The method of claim 1,
MANADHATA ‘4581 teaches the following limitation(s) not taught by the combination of MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, and MANADHATA ‘6241:
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 ([0046] "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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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 MIZRACHI et al (Doc ID US 20160255012 A1), SIVARAMAN et al (Doc ID US 20220086071 A1), APOSTOLOPOULOS et al (Doc ID US 20200044927 A1), MANADHATA et al (Doc ID US 20180176241 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 MIZRACHI, SIVARAMAN, MANADHATA ‘6241, and MANADHATA ‘4581 teaches:
The method of claim 7,
SATISH teaches the following limitation(s) not taught by the combination of MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, MANADHATA ‘6241, and MANADHATA ‘4581:
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 MIZRACHI, SIVARAMAN, APOSTOLOPOULOS, 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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 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
/MENG LI/Primary Examiner, Art Unit 2437
Prosecution Insights