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 01/16/2026 has been entered.
Response to Arguments
The Applicant’s Arguments, see Remarks filed on 01/16/2026, on the rejection of claims 1-2 and 5-6 and 8-18 under 35 USC § 103 have been fully considered, but are moot because of the current rejection of the claims based on newly found prior arts, Gorsica, US 2020/0344213.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
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-2,5-6 and 8-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "wherein the plurality of network parameters comprises one or more of: network type, network name, Wi-Fi BBSID, primary domain, search domain entry, current IPv4 DNS entry, current IPv6 DNS entry, and DNS override information," in lines 19-21. The claim contradicts the “plurality of” aspect of the network parameters via defining it as requiring only “one or more” of the network parameters, making the claim indefinite. The Examiner suggests to rewrite the limitation as "wherein the plurality of network parameters comprises: network type, network name, …,".
Claims 1-2,5-6 and 8-17 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, 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, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 recites the limitation "wherein the plurality of network parameters comprises one or more of: network type, network name, Wi-Fi BBSID, primary domain, search domain entry, current IPv4 DNS entry, current IPv6 DNS entry, and DNS override information," in lines 19-21. The Applicant included the “DNS override information” as being a part of the “plurality of network parameters”. However, on pages 9-11 of the Applicant’s Specification, the DNS Override Information appears to include the same type of network parameters that would be considered under the Safe Network set (e.g., primary domain, search prefixes, IPv4 and IPv6), so the previous claimed list of network parameters would still cover DNS Override Information, and wouldn’t be considered in addition to DNS Override Information, and hence the DNS Override Information is already included in the “plurality of network parameters” list, so it’s a redundant inclusion to the claim which is not fully supported by the written description. The Examiner suggests to remove the “DNS Override Information” from the list.
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-2, 6, 12 and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over US-PGPUB No. US 2003/0167405 A1 to Freund et al. (hereinafter “Freund”), USPAT No. 11985129 B2 to Raman et al. (hereinafter “Raman”), US-PGPUB No. 2020/0344213 A1 to Gorsica et al. (hereinafter “Gorsica”), US-PGPUB No. 2016/0262021 A1 to Lee et al. (hereinafter “Lee”), and further in view of CN 103269389 A to Jiang et al. (hereinafter “Jiang”)
Regarding claim 1:
Freund Discloses:
A method of initiating a roaming Domain Name System (DNS) firewall on a mobile computing device (¶49: “… a system including methodologies for automatically detecting when a computer or device is plugged into a new network (or subnet). … The system also automatically reconfigures a firewall to include or exclude the new network from the trusted zone.”, see Figs. 4A-4B), the method comprising:
detecting a network connection to a new network on a network interface of the mobile computing device (¶50: “… The system first detects a connection to a new network by receiving notice of changes to an existing network configuration and evaluating these changes.”, ¶95: “When a mobile computer or device (on which the system is installed) is connected to a different network, the engine, at step 402, uses the OS network information API and the associated operating system kernel facility to discover that an adapter has been added or removed or an adapter's network configuration has changed.”) using an endpoint agent executed on the mobile computing device (Freund, ¶40: “End point security involves a security agent that resides locally on each machine. This agent monitors and controls the interaction of the local machine with other machines and devices that are connected on a LAN or a larger wide area network (WAN) such as the Internet in order to provide securityy to the machine.”);
using the endpoint agent, characterizing a plurality of network parameters associated with the new network to determine whether the new network is safe (¶50: “the new network is profiled and an identity is generated for the new network. … This profiling process enables the system to generate a unique identifier for the network. Once a network has been identified, a user may elect whether or not that network is to be included as part of his or her trusted zone.”),
However, Freund does not explicitly teach the following limitation taught by Raman:
wherein determining whether the new network is safe comprises comparing the plurality of network parameters to at least one safe network profile […] (Raman, col 27, lines 47-53: “Evaluation of the network can be performed by the connector application 350 on the user device 300. The connection application can fetch of the DNS server list and search domains to compare with the trusted networks table, to figure out whether the network is one of the trusted networks or an untrusted network. The trusted networks table can be in the cloud-based system 100,”),
wherein the plurality of network parameters comprises one or more of:
network type, network name, Wi-Fi BBSID, primary domain, search domain entry (Raman, col 27, lines 38-46: “The network can be identified by trusted network criteria including a DNS server, DNS search domains, hostname and IP, and pre-defined trusted networks for selection. … network HQ San Jose is identified by a hostname and resolved IP, and a second example network America Center is identified by a DNS search domain.”), current IPv4 DNS entry, current IPv6 DNS entry, and DNS override information […]
wherein the new network is determined to be safe when the plurality of network parameters matches the at least one safe network profile (Raman, col 27, lines 48-52: “The connection application can fetch of the DNS server list and search domains to compare with the trusted networks table, to figure out whether the network is one of the trusted networks”) and
wherein the new network is determined to be unsafe when no match is found between the plurality of network parameters and the at least one safe network profile (Raman, col 27, lines 48-52: “The connection application can fetch of the DNS server list and search domains to compare with the trusted networks table, to figure out whether the network is … an untrusted network.”);
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 Freund to incorporate the functionality of the connection application to evaluate a network by implementing a trusted networks table from a cloud-based system to compare a DNS server to domains in the trusted networks table to determine whether the network is trusted or not, as disclosed by Raman, such modification would enable the system to enforce different levels of security based on a pre-defined list of trusted networks, offering a more efficient, and secure approach to network access control.
The combination of Freund and Raman does not explicitly teach the following limitation taught by Gorsica:
[…] and wherein the at least one safe network profile comprises a proper subset of the network parameters corresponding to a network that is known to be safe (Gorsica, ¶46: “… the engagement rules 116 include a safe networks list identifying networks that are deemed to be safe so the computing device 102 need not establish a VPN connection when connected to such networks. For example, the safe networks list can identify the name of a user's work network and the name of a user's home network”), wherein the proper subset comprises at least one of the plurality of the network parameters corresponding to the network that is known to be safe (Gorsica, ¶46: “If the computing device 102 is connected to either of these networks then a VPN connection need not be established because the user's work network and the user's home network are deemed to be safe (e.g., the user need not worry about someone intercepting information being communicated to and from the computing device 102 using the network).”).
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 Freund and Raman to incorporate the functionality of the engagement rules to identify networks that are deemed to be safe by the name of the network, as disclosed by Gorsica, such modification enables to prevent accidental connections to malicious or unsecured networks.
The combination of Freund, Raman and Gorsica does not explicitly teach the following limitation taught by Lee:
[…] [at least one safe network profile] received from a remote management server (Lee, ¶77: “the UE 102 may have been provided with information from the server 116 identifying some or all trusted networks, or networks that have entered into agreements to provide the sponsored connectivity on behalf of the application service provider hosted by the server 116.”)
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 Freund, Raman and Gorsica to incorporate the functionality of the server to provide trusted networks identifying information to a recipient (unknown user equipment), as disclosed by Lee, such modification enables the system to locally compare network parameters which eliminates the delay caused by sending data to and from a distant cloud server, and thus reduces latency.
The combination of Freund, Raman, Gorsica and Lee does not explicitly teach the following limitation taught by Jiang:
and modifying DNS identifiers associated with the network interface with DNS identifiers from the at least one safe network profile (Jiang, ¶37: “the DNS IP address of the network connection device has DHCP function modified to legal network connection device DNS IP address with DHCP function.”,),
wherein the DNS identifiers are modified when the plurality of network parameters are determined to be unsafe (Jiang, ¶37: “the modification unit is further adapted to the DNS IP address of the network connection apparatus having the DHCP function matched with the malicious DNS IP address list acquired in advance,”),
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 Freund, Raman, Gorsica and Lee to incorporate the functionality of the method to modify the DNS IP address of the client end to legitimate DNS IP address, as disclosed by Jiang, such modification ensures that all devices automatically receive the legitimate and correct DNS settings when they connect to the network.
Regarding claim 2:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses:
The method of claim 1, wherein […]
the roaming DNS firewall is provided by a security agent executing on the mobile computing device (Freund, ¶12: “One security measure that can be implemented by a mobile user is to install a personal firewall (or end point security) product on his or her mobile device …”, ¶40: “End point security involves a security agent that resides locally on each machine. This agent monitors and controls the interaction of the local machine with other machines and devices that are connected on a LAN or a larger wide area network (WAN) such as the Internet in order to provide security to the machine.”).
the at least one safe network profile identifies one or more trusted DNS identifiers (Jiang, ¶59: “… legal DNS IP address white list, wherein storing a valid IP address, legal DNS IP address may be, for example, the IP address 360DNS, IP address 114DNS, google DNS IP address or open DNS IP address and so on.”),
The same motivation which is applied to claim 1 with respect to Jiang applies to claim 2.
Regarding claim 6:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses:
The method of claim 1, further comprising sending a request to a remote server for the at least one safe network profile based upon the characterized plurality of network parameters (Jiang, ¶99: “… the preset legal DNS IP address white list … can be downloaded from a server (such as the cloud security server),”).
The same motivation which is applied to claim 1 with respect to Jiang applies to claim 6.
Regarding claim 12:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses:
The method of claim 1, wherein the DNS identifiers are associated with a trusted DNS (Jiang, ¶58: “… if the matching is successful, then the DNS IP address of client end modified to legitimate DNS IP address.”).
The same motivation which is applied to claim 1 with respect to Jiang applies to claim 12.
Regarding claim 14:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses:
The method of claim 1, wherein the plurality of network parameters are received in a Dynamic Host Configuration Protocol (DHCP) message (Jiang, ¶43: “The DHCP function with network connection equipment IP address and the DHCP function of the network connection type of device access DHCP configuration page has the DHCP function of the network connection device. from the page obtaining DNS IP address with the DHCP function of the network connection device.”).
The same motivation which is applied to claim 1 with respect to Jiang applies to claim 14.
Regarding claim 15:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses:
The method of claims 1, wherein modifying DNS identifiers associated with the network interface is defined in an associated registry key (Jiang, ¶99: “… if matching is successful, then the client terminal DNS IP address is malicious, the malicious DNS IP address modification is legal DNS IP address, such as by modifying the registry key value, When it point to legitimate DNS IP address, so as to modify the target key value in the registry;”).
The same motivation which is applied to claim 1 with respect to Jiang applies to claim 15.
Regarding claim 16:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses:
A mobile computing device for executing the roaming Domain Name System (DNS) firewall of claims 1 (Freund, ¶73: “The present invention includes a system providing methodologies for detecting and distinguishing between different networks to which a mobile computer or device is connected from time to time. The ability to detect and distinguish between networks enables different security settings to be applied by the user (or by an established security policy) depending on which network the device is connected to at that time. These security settings are then automatically applied to reconfigure the device's firewall.”).
Regarding claim 17:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses:
A non-transitory computer readable memory containing instructions which when executed by a processor perform the method of claim 1 (Freund, ¶61: “Random-access memory 102 serves as the working memory for the CPU 101.”).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Freund, Raman, Gorsica, Lee and Jiang, and further in view of US-PGPUB No. 2020/0073764 A1 to Neichev
Regarding claim 5:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses the method of claim 1, but does not explicitly disclose the following limitation taught by Neichev:
further comprising verifying that the DNS identifiers have been successfully modified (Neichev, ¶29: “… the disaster recovery engine 150 may verify that the CNAME record at the DNS service 170 has been modified …”).
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 Freund, Raman, Gorsica, Lee and Jiang to incorporate the functionality of the disaster recovery engine to verify a canonical name record at the DNS service has been modified, as disclosed by Neichev, such modification would enable the system to map the custom domain of the cloud-based application to the URL associated with the first instance of the cloud-based application instead of the URL.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Freund, Raman, Gorsica, Lee and Jiang, US-PGPUB No. 2017/0149783 A1 to Dayka et al. (hereinafter “Dayka”), US-PGPUB No. 2003/0061363 A1 to Bahl et al. (hereinafter “Bahl”), US-PGPUB No. 2013/0036311 A1 to Akyol et al. (hereinafter “Akyol”), US-PGPUB No. 2012/0252493 A1 to Siddeley et al. (hereinafter “Siddeley”), and further in view of US-PGPUB No. 2005/0086666 A1 to Nason et al. (hereinafter “Nason”)
Regarding claim 8:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses:
The method of claim 1, wherein modifying the DNS identifiers further comprises:
applying the DNS registry value for a network interface card (NIC) Universally Unique Identifier (UUID) (Jiang, ¶112: “wherein the priority read HKLM\SYSTEM, SYSTEM, CurrentControlSet/Services/Tcpip/minpir/Interfaces/{GUID}/NameServer the numerical data, if there is no numerical data, it reads HKLM\SYSTEM, SYSTEM, CurrentControlSet/Services/Tcpip/minpir/Interfaces/{(numerical data in iUIDhDhcp NameServer. wherein the modification means can be realized by modification type of registry key value.”);
The same motivation which is applied to claim 1 with respect to Jiang applies to claim 8.
The combination of Freund, Raman, Gorsica, Lee and Jiang does not explicitly disclose the following limitation taught by Dayka:
building DNS registry values from the at least one safe network profile (Dayka, ¶04: “In white-listing solutions, existing applications create registries of accepted domains (i.e. HTTP referrers) that are allowed for a given application …”);
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 Freund, Raman, Gorsica, Lee and Jiang to incorporate the functionality of the method to create registries of accepted domains, as disclosed by Dayka, such modification would enable the system to prevent cross-site request forgery, a type of an attack that tricks a victim into submitting a malicious request.
The combination of Freund, Raman, Gorsica, Lee, Jiang and Dayka fails to explicitly teach the following limitation taught by Bahl:
disconnecting from the new network (Bahl, ¶20: “… a client that connects to a public network at SEATAC airport in Seattle while waiting for a flight to Chicago may disconnect from the network, …”);
reconnecting the new network (Bahl, ¶20: “… catch the flight to Chicago, and reconnect to the same public network at O'Hare airport.”);
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 Freund, Raman, Gorsica, Lee, Jiang and Dayka to incorporate the functionality of the method to disconnect from a network, and reconnect to the same public network later, as disclosed by Bahl, such modification would enable the system to recognize that the client has a valid authorization key and allow the client to bypass the authentication process.
The combination of Freund, Raman, Gorsica, Lee, Jiang, Dayka and Bahl fails to explicitly teach the following limitation taught by Akyol:
shutting down a security agent (Akyol, ¶127: “the resource monitor module 530 is called by the agent packaging and instantiation module 522 (which can send messages to the resource monitor module 530 to determine if there are sufficient resources to satisfy an agent contract) and calls into the information exchange bus 524 to shutdown an agent consuming too many resources.”);
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 Freund, Raman, Gorsica, Lee, Jiang, Dayka and Bahl to incorporate the functionality of the agent packaging and instantiation module to send messages to the resource monitor module to determine if there are sufficient resources to satisfy an agent contract, and call into the information exchange bus to shutdown an agent, as disclosed by Akyol, such modification would enable the system to stop the execution of an agent that consumes too many resources.
The combination of Freund, Raman, Gorsica, Lee, Jiang, Dayka, Bahl and Akyol fails to explicitly teach the following limitation taught by Siddeley:
starting the endpoint agent (Siddeley, ¶83: “Where no secure user plane (SUPL) connection exists (for example, in the case where there is no client agent instantiated on the device-side), the routing function/selection process proceeds from step 236BU to step 240BU, where steps are taken to instantiate a client agent, and to establish a secure user plane (SUPL) connection between such client agent and a server agent.”); and
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 Freund, Raman, Gorsica, Lee, Jiang, Dayka, Bahl and Akyol to incorporate the functionality of the method to instantiate a client agent where there is no client agent instantiated on the device-side, as disclosed by Siddeley, such modification would enable the system to monitor network connections within the client device.
The combination of Freund, Raman, Gorsica, Lee, Jiang, Dayka, Bahl, Akyol and Siddeley fails to explicitly teach the following limitation taught by Nason:
verifying that the DNS registry values have been maintained (Nason, ¶114: “… The watchdog is invoked if the registry entries are modified and verifies that the entries are correct at that time; and, if they are not correct, determines the correct values and replaces them.”).
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 Freund, Raman, Gorsica, Lee, Jiang, Dayka, Bahl, Akyol and Siddeley to incorporate the functionality of the watchdog to verify that the entries are correct when it is invoked if the registry entries are modified, as disclosed by Nason, such modification would enable the system to replace the registry entries when they are not correct.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Freund, Raman, Gorsica, Lee, Jiang, Dayka, Bahl, Akyol, Siddeley, Nason, and further in view of USPAT No. 8566947 B1 to Sankruthi
Regarding claim 9:
The combination of Freund, Raman, Gorsica, Lee, Jiang, Dayka, Bahl, Akyol, Siddeley and Nason discloses the method of claim 8, but does not explicitly disclose the following limitation taught by Sankruthi:
wherein if the DNS registry values have been changed the method further comprises reporting a failure (Sankruthi, col 5, lines 39-54: “… the alert level 122 indicates one or more threats that are to be reported to the user computer 102 upon detection. … the alert level 122 may define a sensitivity level of the security software with respect to a particular suspicious activity or a group of suspicious activities. … if the sensitivity level for registry key modifications is increased, then the user is notified of each and every activity in which a registry key is modified.”).
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 Freund, Raman, Gorsica, Lee, Jiang, Dayka, Bahl, Akyol, Siddeley and Nason to incorporate the functionality of the alert level to indicate one or more threats that are to be reported upon detection, as disclosed by Sankruthi, such modification would enable the system to report to the user malicious behavior such as modifications to critical system data (e.g., registry settings, system files and/or the like) so that appropriate action could be taken.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Freund, Raman, Gorsica, Lee, Jiang, and further in view of US-PGPUB No. 2014/0082693 A1 to Wackerly et al. (hereinafter “Wackerly”)
Regarding claim 10:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses the method of claim 1, but does not explicitly disclose the following limitation taught by Wackerly:
further comprising polling the DNS identifiers periodically to determine that the DNS identifiers from the at least one safe network profile have been maintained (Wackerly, ¶42: “… entries in white list 61 of the security binding table (illustrated in FIG. 3B) are polled periodically to determine whether the lookup and match portions of the bindings are still valid.”).
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 Freund, Raman, Gorsica, Lee and Jiang to incorporate the functionality of the method to implement proactive polling in a security table, as disclosed by Wackerly, such modification would enable the system to determine whether the lookup and match portions of the bindings are still valid, and to dynamically adjust the parameters that have been established by the network administrator.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Freund, Raman, Gorsica, Lee, Jiang, USPAT No. 8615805 B1 to Obrecht et al. (hereinafter “Obrecht”), US-PGPUB No. 20110107430 A1 to Graham et al. (hereinafter “Graham”), and further in view of USPAT No. 8353038 B1 to Kennedy
Regarding claim 11:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses the method of claim 1, but does not explicitly disclose the following limitation taught by Obrecht:
further comprising:
monitoring a registry associated with the plurality of network parameters to identify a parameter change (Obrecht, col 13, lines 32-35: “1) monitoring at least one attribute associated with a registry; 2) determining that the at least one attribute has been modified; 3) identifying the process that modified the at least one attribute;”);
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 Freund, Raman, Gorsica, Lee and Jiang to incorporate the functionality of the method to monitor an attribute associated with a registry and determine the attribute has been modified, as disclosed by Obrecht, such modification would enable the system to identify the process that modified the attribute and classify the identified process based on evaluation of one or mere characteristics of the process.
However, the combination of Freund, Raman, Gorsica, Lee, Jiang and Obrecht does not explicitly disclose the following limitation taught by Graham:
receiving a kernel change notification or through polling for changes to specific registry data (Graham, ¶42: “… registering the system for registry change notification via the CmRegisterCallback( ) kernel application programming interface.”);
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 Freund, Raman, Gorsica, Lee, Jiang and Obrecht to incorporate the functionality of the method to register for registry change notification, as disclosed by Graham, such modification would enable the system to receive a notification when the registry is modified and identify the process that modified the registry as a trusted or untrusted process.
The combination of Freund, Raman, Gorsica, Lee, Jiang, Obrecht and Graham does not explicitly disclose the following limitation taught by Kennedy:
verifying if the kernel change notification is associated with the DNS identifiers (Kennedy, col 1, lines 20-21: “The Windows HOSTS file allows for Domain Name Service ("DNS") override of domains …”, col 2, lines 62- 67 to col 3, line 1: “… the configuration information manager 101 detects and manages attempts by processes 107 to write to some or all plain text files 105 … the monitored files 105 are … one or more files 105 that associate network addresses with domain names, such as the Windows HOSTS file 105.”);
and logging a DNS override when the kernel change is associated with the DNS identifiers (Kennedy, col 1, lines 20-51: “The Windows HOSTS file allows for Domain Name Service ("DNS") override of domains to Internet Protocol ("IP") addresses. … a configuration information manager makes a copy of the target file, and redirects the write operation to this copy. The configuration information manager then analyzes the process that did the writing, as well as the content that was written. If the process and/or the content is deemed to be suspicious, the changes will be logged …”).
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 Freund, Raman, Gorsica, Lee, Jiang, Obrecht and Graham to incorporate the functionality of the configuration information manager to make a copy of a target file, and redirect a write operation to this copy, and analyze the process that did the writing, as disclosed by Kennedy, such modification would enable the system to remove changes in a structured fashion should an application later be determined to be malicious, or should a user or system administrator wish to undo the changes.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Freund, Raman, Gorsica, Lee, Jiang, and further in view of US-PGPUB No. 2009/0199291 A1 to Hayasaka et al. (hereinafter “Hayasaka”)
Regarding claim 13:
The combination of Freund, Raman, Gorsica, Lee and Jiang discloses the method of claim 1, but does not explicitly disclose the following limitation taught by Hayasaka:
wherein the DNS roaming firewall is deactivated on a trusted network (Hayasaka, ¶05: “… in the IP address matching method, a network administrator … sets in advance a range of the IP address (network address) which defines the intranet to each of communication apparatuses to be used inside of the intranet. When starting communication, the communication apparatus compares the IP address which is assigned to an interface (communication port) and the network address which is set by the administrator in advance. If the assigned IP address is included in the network address, it judges that the communication apparatus is connected to the intranet and the firewall function is disabled in the communication apparatus. If the assigned IP address is not included in the network address, it judges that the communication apparatus is connected to the outside network of the intranet and the firewall function is enabled in the communication apparatus.”).
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 Freund, Raman, Gorsica, Lee and Jiang to incorporate the functionality of the communication apparatus to compare the IP address which is assigned to an interface and the network address which is set by the administrator in advance, and disable the firewall function if it determines that the communication apparatus is connected to the intranet, as disclosed by Hayasaka, such modification would enable the system to enable the firewall function when the device is connected an outside network, and disable the firewall function when the device is connected to the intranet to manage resource utilization.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over US-PGPUB No. 2008/0052383 A1 to O'Shaughnessy et al. (hereinafter “O'Shaughnessy”), US-PGPUB No. 2015/0365381 A1 to Durbin, US-PGPUB No. 2018/0302412 to Achtermann et al. (hereinafter “Achtermann”), Gorsica, and further in view of US-PGPUB No. 2010/0165879 A1 to Gupta et al. (hereinafter “Gupta”)
Regarding claim 18:
O'Shaughnessy discloses:
A method of providing a roaming DNS firewall management server, the method comprising:
Receiving, at the roaming DNS firewall management server, a plurality of network characterizations observed by a plurality of endpoint agents (¶26: “The device manager 120 may also generate and distribute … device data 136 received from a plurality of agents 140 …”), each of the plurality of endpoint agents being executed on separate mobile computing devices (¶26: “The device agent 140 of each mobile device 130 may receive any number of device queries 134 or instructions from the device manager 120. … the device manager 120 may query the agent 140 on one or more mobile devices 130 for a status 142 of the mobile device”);
However, O'Shaughnessy does not explicitly disclose the following limitation taught by Durbin:
Determining, at the roaming DNS firewall management server and from the plurality of network characterizations safe network parameters (Durbin, ¶28: “… the wireless access identifiers are determined as trusted identifiers based on attributes such as a location of the mobile devices 103 (e.g., in a home, office, coffee shop, etc.), available wireless networks, and the like.”), wherein the safe network parameters are parameters of a safe network (Durbin, ¶28: “… the wireless access identifiers are determined as trusted identifiers …”);
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 O'Shaughnessy to incorporate the functionality of the method to determine the wireless access identifiers as trusted identifiers based on attributes such as a location of the mobile devices, as disclosed by Durbin, such modification would enable the system to establish a secured wireless network connection with trusted public wireless networks.
The combination of O'Shaughnessy and Durbin does not explicitly disclose the following limitation taught by Achtermann:
Generating, at the roaming DNS firewall management, a safe network profile from the safe network parameters (Achtermann, ¶36: “Create a trusted profile based on one or more zone attributes. Each zone has a certain security attribute based on its functional scope in the IoT realm.”),
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 O'Shaughnessy and Durbin to incorporate the functionality of the method to create a trusted profile based on one or more attributes, as disclosed by Achtermann, such modification would enable the system to allow communication of devices that match the trusted profile, and deny communication of those devices whose profiles do not match the trusted profile.
The combination of O'Shaughnessy, Durbin and Achtermann does not explicitly disclose the following limitation taught by Gorsica:
the safe network profile comprising a proper subset of the safe network parameters (Gorsica, ¶46: “… the engagement rules 116 include a safe networks list identifying networks that are deemed to be safe so the computing device 102 need not establish a VPN connection when connected to such networks. For example, the safe networks list can identify the name of a user's work network and the name of a user's home network”), wherein the proper subset comprises at least one of the plurality of the network parameters corresponding to the network that is known to be safe (Gorsica, ¶46: “If the computing device 102 is connected to either of these networks then a VPN connection need not be established because the user's work network and the user's home network are deemed to be safe (e.g., the user need not worry about someone intercepting information being communicated to and from the computing device 102 using the network).”);
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 O'Shaughnessy, Durbin and Achtermann to incorporate the functionality of the engagement rules to identify networks that are deemed to be safe by the name of the network, as disclosed by Gorsica, such modification enables to prevent accidental connections to malicious or unsecured networks.
The combination of O'Shaughnessy, Durbin, Achtermann and Gorsica does not explicitly disclose the following limitation taught by Gupta:
and sending the safe network profile to a requesting mobile computing device (Gupta, ¶21: “The wireless device 130 … transmits a request for provisioning back to the computing device 120. … the computing device 120 may transmit the network profile for the network 100 to the wireless device 130.”).
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 O'Shaughnessy, Durbin, Achtermann and Gorsica to incorporate the functionality of the method to transmit a network profile to a requesting wireless device, as disclosed by Gupta, such modification would enable the requesting device to identify the network and perform functions such as authentication and encryption in a manner recognized by the network.
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