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 04/22/2026 has been entered.
Response to Arguments
Applicant’s argument, see Remarks, filed 07/28/2024, with respect to the rejection(s) of independent claims 64, 79 and 82 under 35 USC § 102 has been fully considered, but because of the new ground of rejection based on newly found prior art, Rupavatharam, US 11245668.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 64-67 and 79-83 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by USPAT No. 11245668 B1 to Rupavatharam et al. (hereinafter “Rupavatharam”).
Regarding claim 64:
Rupavatharam discloses:
One or more tangible, non-transitory computer-readable storage media having stored thereon executable instructions to provide (col 1, lines 54-60: “a non-transitory computer-readable medium may store instructions that include one or more instructions that, when executed by one or more processors, may cause the one or more processors to detect a request to configure a firewall with a rule and intercept the request before the firewall is configured with the rule.”) a security application (see Fig. 2, Intercept Library 240) on a compute host (see Fig. 2, Network Device 205), the security application to:
within a non-kernel space of the compute host (see Fig. 2, User Space, and User Space Application(s) 235), asynchronously monitor network activity of a network- enabled application (col 2, lines 53-57: “… a network device may monitor for and detect a request from an application of a user space of the network device to configure a firewall (e.g., a firewall provided by a kernel of the network device) with a rule.”);
based on the asynchronous monitoring (col 4, lines 13-15: “… the network device may monitor for and detect a request to configure the firewall of the network device with a rule.”), create one or more firewall rules for a kernel- mode firewall that operates within a kernel space of the compute host (col 8, lines 26-29: “Network device 205, using firewall process 225 (e.g., a daemon of network device 205), may configure the firewall objects stored in data structure 220 to firewall 230 in the kernel of the network device.”); and
cause the kernel-mode firewall to enforce the one more firewall rules (col 8, lines 34-41: “… an incoming packet entering the networking stack, and before any routing decision is made, may trigger a pre-routing hook (e.g., a pre-routing hook of the Netfilter framework). Continuing with the previous example, the packet may be evaluated against a chain of firewall rules associated with the pre-routing hook (e.g., a chain of firewall rules configured for firewall 230) by the kernel of network device 205.”).
Regarding claim 65:
Rupavatharam discloses:
The one or more tangible, non-transitory computer-readable media of claim 64, wherein the non-kernel space is userspace (see Fig. 2, User Space).
Regarding claim 66:
Rupavatharam discloses:
The one or more tangible, non-transitory computer-readable media of claim 64, wherein the kernel-mode firewall is an operating system native firewall (col 3, lines 27-28: “the firewall may be provided by a kernel (e.g., a Linux kernel) of the network device,”, note: the Linux kernel is the foundational core of the Linux operating system.) or third-party firewall.
Regarding claim 67:
Rupavatharam discloses:
The one or more tangible, non-transitory computer-readable media of claim 64, wherein the security application is not tightly integrated with the kernel-mode firewall (col 8, lines 49-54: “Intercept library 240, may direct the rule of the request to firewall process 225 to determine whether the rule modifies a particular functionality of firewall 230, and obtain an indication from firewall process 225 as to whether the rule modifies the particular functionality of firewall 230.”).
Regarding claims 79-80:
Claims 79-80 substantially recite the same limitations as claims 64-65, respectively, in the form of a method implementing the corresponding functionality. Therefore, they are rejected by the same rationale.
Regarding claim 81:
Rupavatharam discloses:
The computer-implemented software method of claim 79, wherein the one or more firewall rules are static firewall rules (col 3, lines 30-38: “The firewall may be configured with rules by an administrator of the network device or a network that includes the network device, a manufacturer of the network device, and/or a developer of the kernel (collectively referred to herein as an “administrator”). The rules may provide a particular functionality to the firewall (e.g., a critical functionality) that is to be maintained in order to provide a level of security to the network device and/or the network that includes the network device.”).
Regarding claim 82:
Rupavatharam discloses:
A computing device (see Fig. 2, Network Device 205), comprising:
a processor circuit and a memory (col 1, lines 38-41“a network device may include one or more memories and one or more processors to intercept a request to configure a firewall of the network device with a rule,”);
an operating system (col 3, lines 27-28: “… the firewall may be provided by a kernel (e.g., a Linux kernel) of the network device,”) comprising a kernel space (see Fig. 2, Kernel) and a non-kernel space (see Fig. 17, User Space 1704); and
instructions encoded within the memory to instruct the processor circuit to provide a security application (col 1, lines 54-60: “… a non-transitory computer-readable medium may store instructions that include one or more instructions that, when executed by one or more processors, may cause the one or more processors to detect a request to configure a firewall with a rule and intercept the request before the firewall is configured with the rule.”), the security application to:
In addition to the above limitations, claim 82 substantially recites the same limitations as claim 64 in the form of a device to realize the corresponding functionality. Therefore, it is rejected by the same rationale.
Regarding claim 83:
Claim 83 substantially recites the same limitations as claim 67 in the form of a device to realize the corresponding functionality. Therefore, it is rejected by the same rationale.
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.
Claim 68 is rejected under 35 U.S.C. 103 as being unpatentable over Rupavatharam, and further in view of US-PGPUB No. 2015/0281180 A1 to Raman et al. (hereinafter “Raman”)
Regarding claim 68:
Rupavatharam discloses the one or more tangible, non-transitory computer-readable media of claim 67, but does not explicitly teach the following limitation taught by Raman:
wherein the security application is sourced from a vendor different from a vendor that sourced the kernel-mode firewall (Raman, ¶10: “the firewall SVM is provided by one vendor (e.g., a firewall vendor), while the firewall rule engine is provided by another vendor.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Rupavatharam to incorporate the system architecture of implementing a firewall provided by one vendor, and a firewall rules engine provided by a different user, as disclosed by Raman, such modification would enable the system to enhance security by providing a more flexible security posture, and offers the potential benefit of diversifying security measures, preventing a single vendor's vulnerability from compromising the entire system.
Claim 69 is rejected under 35 U.S.C. 103 as being unpatentable over Rupavatharam, and further in view of US-PGPUB No. 2019/0014086 A1 to Meyer et al. (hereinafter “Meyer”)
Regarding claim 69:
Rupavatharam discloses the one or more tangible, non-transitory computer-readable media of claim 67, but does not explicitly teach the following limitation taught by Meyer:
wherein the security application communicates with the kernel-mode firewall only via a published interface definition (Meyer, ¶18: “… implementing the firewall policy on the host computing device includes the kernel-level security agent executing instructions to load a user-mode component in user mode of the computing device, and providing the firewall policy to the user-mode component. The user-mode component then invokes (or calls), from the user mode, an application programming interface (API) to implement the firewall policy, and the firewall policy is implemented in kernel mode of the computing device based at least in part on the API invoked from user mode.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Rupavatharam to incorporate the system architecture of implementing an API to implement a firewall policy, as disclosed by Meyer, such modification would enable the system to allow user-space applications to programmatically manage network traffic at the lowest possible level.
Claim 70 is rejected under 35 U.S.C. 103 as being unpatentable over Rupavatharam, and further in view of US-PGPUB No. 2018/0013775 A1 to Jee et al. (hereinafter “Jee”)
Regarding claim 70:
Rupavatharam discloses the one or more tangible, non-transitory computer-readable media of claim 64, but does not explicitly teach the following limitation taught by Jee:
wherein asynchronously monitoring behavior of the networked application comprises subscribing to domain name system (DNS) query events from a local operating system (Jee, ¶41: “The DNS Resolver Agent 332, subscribing to the events from user space, maps DNS queries and its corresponding answers and then reports to the backend server.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Rupavatharam to incorporate the functionality of the DNS Resolver Agent to subscribe to events from user space and mapping DNS queries to a backend server, as disclosed by Jee, such modification would provide real-time data flow without the performance hit of frequent polling.
Claims 71-72 is rejected under 35 U.S.C. 103 as being unpatentable over Rupavatharam, and further in view of US-PGPUB No. 2016/0134653 A1 to Vallone et al. (hereinafter “Vallone”)
Regarding claim 71:
Rupavatharam discloses the one or more tangible, non-transitory computer-readable media of claim 64, but does not explicitly teach the following limitation taught by Vallone:
wherein the security application is to determine, within less than approximately five seconds, a firewall action for the network-enabled application (Vallone, ¶18: “ensure that the expected characteristic is triggered and that any responses … occur within one or more predefined service levels (e.g., a firewall closing a TCP port after two seconds of detecting illicit activity).”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Rupavatharam to incorporate the functionality of the method to provide validation feedback associated with the progress and/or result of the instruction's execution to ensure that the expected characteristic is triggered and that any responses occur within one or more predefined service levels, as disclosed by Vallone, such modification would enable the system to minimize the damage that might be caused by any illicit activity.
Regarding claim 72:
The combination of Rupavatharam and Vallone discloses:
The one or more tangible, non-transitory computer-readable media of claim 71, wherein the security application is to create a firewall rule to block an ongoing network operation for the network-enabled application, upon determining that the network-enabled application performs a malicious activity (Vallone, ¶20-22: “if analysis indicates that the target is vulnerable to a cyberattack … is at or near a defined threshold (e.g., … service level three, indicating a critical vulnerability), the technology can automatically update the target network′ monitoring capabilities … [0022] … create … firewall rules fail the target network so that network traffic is routed to a safe, failover network;”).
The same motivation which is applied to claim 71 with respect to Vallone applies to claim 72.
Claim 73 is rejected under 35 U.S.C. 103 as being unpatentable over Rupavatharam, and further in view of US-PGPUB No. 2017/0237749 A1 to Wood
Regarding claim 73:
Rupavatharam discloses the one or more tangible, non-transitory computer-readable media of claim 64, but does not explicitly teach the following limitation taught by Wood:
further comprising instructions for a browser plugin to monitor browser activity (Wood, ¶24: “a web traffic analysis system to determine the identity of the open web address, the identity of the at least one connection of the open web address, or the identity of both. The web traffic analysis system includes a browser plugin,”, p-135: “The system [next] checks to see if the subdomain matches an open URL 402, i.e., a web address that is open within the browser app. A browser plugin can be used to transmit open and closed web addresses.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Rupavatharam to incorporate the functionality of the system to implement a browser plugin to transmit open and closed web addresses by a browser app, as disclosed by Wood, such modification would enable the system to gather information (opened links, websites, etc.) that can be used to trace activities.
Claim 74 is rejected under 35 U.S.C. 103 as being unpatentable over Rupavatharam, US-PGPUB No. 2020/0314061 A1 to Uchikawa, and further in view of Wood
Regarding claim 74:
Rupavatharam discloses the one or more tangible, non-transitory computer-readable media of claim 64, but does not explicitly teach the following limitation taught by Uchikawa:
wherein the instructions are further to determine that the network-enabled application does not use an operating system (OS)-provided domain name system (DNS) client […], and block network access for the network-enabled application (Uchikawa, ¶57-60: “In S501, the communication application 1010 requests the OS standard DNS client 1021 used for the network 1 (300) to perform DNS name resolution. … the communication application 1010 determines whether name resolution is successful on the basis of the result of DNS name resolution performed by the OS standard DNS client 1021 in response to the request. … If the name resolution has failed, the process proceeds to S504. … the communication application 1010 displays an error. For example, the communication application 1010 outputs a message indicating that communication has failed or outputs an error sound.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Rupavatharam to incorporate the functionality of the communication application to determine whether name resolution is successful on the basis of the result of DNS name resolution performed by an OS standard DNS client in response to a request to the OS standard DNS client, as disclosed by Uchikawa, such modification would enable the system to block non-OS standard DNS client requests that would compromise the security of the system.
The combination of Rupavatharam and Uchikawa does not explicitly disclose the following limitation taught by Wood:
[…] and is not a web browser (Wood, ¶40: “a firewall to block data packets transmitted between at least one application/destination pair, wherein the at least one application/destination pair includes one of the at least one non-browser applications communicating with one of the at least one remote host addresses that is the destination of the at least one application/destination pair.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Rupavatharam and Uchikawa to incorporate the functionality of the method determine a non-browser application is communicating with a remote host address, as disclosed by Wood, such modification would enable the system to filter browser applications that could potentially be malicious.
Claim 75 is rejected under 35 U.S.C. 103 as being unpatentable over Rupavatharam, and further in view of US-PGPUB No. 2024/0129275 A1 to Van Oort
Regarding claim 75:
Rupavatharam discloses the one or more tangible, non-transitory computer-readable media of claim 64, but does not explicitly teach the following limitation taught by Van Oort:
wherein the instructions are to create a firewall rule to block specific domains or internet protocol (IP) addresses for the network-enabled application (Van Oort, ¶219: “… create an inbound firewall rule (box 160) that blocks inbound traffic from either a CIDR block of IP addresses, or range of IP addresses, … a range of IP addresses can be specified as a range; 192.168.1.15-192.168.1.57.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Rupavatharam to incorporate the system configuration to create an inbound firewall rule that blocks inbound traffic from a range of IP addresses, as disclosed by Van Oort, such modification allows for the proactive defense against malicious activity by blocking entire networks or groups of IP addresses known to be associated with harmful activities.
Claims 76-78 are rejected under 35 U.S.C. 103 as being unpatentable over Rupavatharam, US-PGPUB No. 2018/0007088 A1 to Kuznetsov et al. (hereinafter “Kuznetsov”), and further in view of US-PGPUB No. 2024/0106861 A1 to Ahn et al. (hereinafter “Ahn”)
Regarding claim 76:
Rupavatharam discloses the one or more tangible, non-transitory computer-readable media of claim 64, but does not explicitly teach the following limitation taught by Kuznetsov:
wherein creating the one or more firewall rules comprises determining that multiple domain names resolve to a common internet protocol (IP) address (Kuznetsov, ¶06: “determining whether any two of the domain names … were resolved to a common IP address”),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of Rupavatharam to incorporate the functionality of the method to determine whether any two domain names resolve to a common IP address, as disclosed by Kuznetsov, such modification would enable the system to determine if a legitimate reason exists for the two domain names to resolve to the common IP address, which would be an indication of DNS hijacking if there is no legitimate reason for the two domain names to resolve to the common IP address.
The combination of Rupavatharam and Kuznetsov does not explicitly disclose the following limitation taught by Ahn:
and applying a first rule to a first domain of the IP address (Ahn, ¶108: “… the traffic routing and monitoring platform 102 may identify, based on the first traffic routing rules, that traffic should be allowed to access the IP address requested by the first identity embedded DNS query request.”), and a second rule to a second domain of the IP address (Ahn, ¶132: “… the traffic routing and monitoring platform 102 may identify, based on the second traffic routing rules, that traffic directed to the IP address requested by the second identity embedded DNS query request should be blocked …”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, to modify the teachings of the combination of Rupavatharam and Kuznetsov to incorporate the functionality of the traffic routing and monitoring platform to identify, based on traffic routing rules, an action to perform with regard to an identity embedded DNS query request, as disclosed by Ahn, such modification would enable the system to either block or allow network traffic to an IP address based on routing rules.
Regarding claim 77:
The combination of Rupavatharam, Kuznetsov and Ahn discloses:
The one or more tangible, non-transitory computer-readable media of claim 76, wherein the first rule is to block the IP address (Ahn, ¶108: “… traffic should be allowed to access the IP address requested by the first identity embedded DNS query request.”), and the second rule is to allow the IP address (Ahn, ¶132: “… traffic directed to the IP address requested by the second identity embedded DNS query request should be blocked …”).
The same motivation which is applied to claim 76 with respect to Ahn applies to claim 77.
Regarding claim 78:
The combination of Rupavatharam, Kuznetsov and Ahn discloses:
The one or more tangible, non-transitory computer-readable media of claim 77, wherein the instructions are to apply the first rule after determining that a most recent DNS query that resolved to the IP address was for the first domain (Ahn, ¶108: “… traffic should be allowed to access the IP address requested by the first identity embedded DNS query request.”), and apply the second rule after determining that the most recent DNS query that resolved to the IP address was for the second domain (Ahn, ¶132: “… traffic directed to the IP address requested by the second identity embedded DNS query request should be blocked …”).
The same motivation which is applied to claim 76 with respect to Ahn applies to claim 78.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHIAS HABTEGEORGIS whose telephone number is (571)272-1916. The examiner can normally be reached M-F 8am-5pm ET.
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, William R. Korzuch can be reached at (571)272-7589. 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.
/MATTHIAS HABTEGEORGIS/Examiner, Art Unit 2491
Prosecution Insights