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 .
Claims 1, 3, 5-8, 10, 12-15, 17, and 19-26 are pending. Claims 1, 8, and 15 are independent. Claims 1, 8, and 15 are amended. Claims 2, 4, 9, 11, 16, and 18 are cancelled. Claims 1, 3, 5-8, 10, 12-15, 17, and 19-26 are rejected.
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 7/16/2026 has been entered.
Response to Arguments
Applicant’s arguments, see pages 11-25, filed 3/16/2026, with respect to the rejection of claims 1, 3, 5-8, 10, 12-15, 17, and 19-26 under 35 U.S.C. 103 have been fully considered.
Regarding claims 1, 6, 8, 13, 15, and 19:
Due to the change in scope created by the amendments to these claims, the previous prior art rejection is withdrawn. However, the following addresses arguments directed to individual references. A new grounds of rejection is made in view of BREGMAN et al (Doc ID US 20170270131 A1).
Regarding claims the prior art of Teal:
Examiner notes that the majority of the arguments against Teal are directed to claim limitations which are not mapped to Teal in the previous office action. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Regarding the argument that Teal “does not disclose any computed risk value being used by the personal firewall to allow or block communications”, Examiner respectfully disagrees. It is unclear to precisely what aspect of the claims or the prior art Applicant is referring vis a vie “a device side runtime computation and application of an overall risk value at the endpoint”. The limitation in question requires an “overall risk” be used by the firewall to enforce policies. The prior art explicitly recites a firewall which allows or blocks communications based on a policy, and recites a risk assessment as an example. Nothing in the claimed limitation precludes the prior art from producing identical and predictable output based on the given combination of references.
Regarding the prior art of Akella:
Examiner notes that the arguments against Akella are directed to claim limitations which are not mapped to Akella in the previous office action. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Regarding the prior art of BANSAL:
Regarding the argument that Bansal does not teach determining that a source application is unsanctioned, Examiner respectfully disagrees. Bansal consults a repository to determine if an application is listed as “safe” or “unsafe,” where unsafe applications are blocked. Minus any more detailed definition of “unsanctioned” in the original disclosure, this teaching reads on the amended limitation of determining if an application is “unsanctioned.” Examiner further notes that the determination is “tied to” the device posture, in that the specification defines “device posture” through examples, one of which is whether the device contains any unsanctioned applications. The disclosure is silent regarding any criteria used for determining that an application is unsanctioned, and there is no functional limitation provided in the original disclosure which is incompatible with the determination taught by Bansal. This portion of the rejection is maintained.
Regarding the new limitation directed to user groups and SSH access, these arguments are persuasive. This portion of the rejection is withdrawn.
Regarding the arguments directed to blocking applications regardless of destination IP address, Examiner respectfully disagrees, and notes that this is a results-based limitation, with no particular function associated with it. The specification at ¶ [0065] makes it clear that this limitation is a result of blocking the source application, as opposed to managing IP addresses. Even given the full context of the specification, the provided mapping to the prior art reads on this limitation, as Bansal also teaches blocking a specific application. This portion of the rejection is maintained.
Regarding claims 7, 14, and 20:
Regarding the arguments directed to the prior art of Neystadt, Examiner respectfully disagrees. The limitation in question recites, “consulting via the agent on the mobile device a cloud security system to derive the risk associated with the parameters.” The nature of the claimed “consulting” is not recited, and the broadest reasonable interpretation of this limitation encompasses contacting a remote service to obtain the parameters used to perform a risk assessment. Examiner further notes that the parent claims recite the “agent” as deriving the risk based on the parameters. Where Applicant argues the performance of the derivation by the contacted cloud service, Examiner notes that this interpretation would be incompatible with the parent claim, and would require a rejection under 35 U.S.C. 112(b). This portion of the rejections is maintained
Regarding claim 22:
Examiner first notes that the portion of the claim reciting, “for deception purposes” constitutes intended use and thus receives decreased patentable weight. Minus a limitation positively claiming a deception taking place, prior art which performs an equivalent function reads on the claims, regardless of whether the prior art performs the function with a different intended use. As to “agent-side deception logic,” Examiner notes that these arguments recite a feature which is not claimed, nor is it described in the original disclosure. This portion of the rejections is maintained
Regarding claim 23:
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The prior art of Capellman is relied upon merely to provide evidence that it is known in the art to update a risk assessment after a change in network connectivity. This function is compatible both with the previous draft of the claims and with the claims as amended. This portion of the rejections is maintained.
Regarding claim 24:
Examiner notes that these arguments are persuasive. The previous rejection is withdrawn; however, upon further review, Examiner notes that the missing elements are present in the prior art of Bansal, and the current rejection has been updated to reflect the various captured elements.
Regarding claim 25:
Regarding the arguments directed to dependency on claim 1, Examiner respectfully disagrees and notes that these arguments essentially assert that a rejection under 35 U.S.C. 103 cannot exist where every prior art reference does not teach every preceding limitation of the claims. No such restriction exists. The prior art of Basavapatna is provided as evidence that using data associated with “Wi-Fi security information” as part of a risk assessment is known in the art. As to “enrich[ing] hotspot risk data”, Examiner notes that this constitutes intended use. The specification seems to define “enrich” merely as the notion of a pool of data having more data added to it. This is at least inherent, if not explicitly taught by the prior art. This portion of the rejections is maintained.
Regarding claim 26:
Regarding the argument directed to the prior art of Zamir, Examiner respectfully disagrees. The prior art teaches the limitation of providing network data to a security information and event management (SIEM) system. Other claim elements are already provided for in the combination of references, and are compatible with the prior art as simply transmitting network data is trivial and no structure or function in the prior art indicates that the result of the combination would not be predictable and identical to the claims.
Examiner notes that additional arguments are directed to the alleged allowability of claims based on their dependency to already-argued claims, and will not be addressed.
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.
Claim(s) 1, 3, 5-8, 10, 12-15, 17, and 19-26 is/are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contain(s) 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 claim(s) 1, 8, and 15:
Claim 1 recites, “… a compliance level associated with the mobile device indicates the source application is vulnerable …”. Claim(s) 8 and 15 recite(s) similar language. This limitation lacks sufficient written description in the original disclosure, and thus constitutes new matter. The term “compliance level” appears only once in the original disclosure, in ¶ [0059], which recites, “Further, existing firewalls don't consider risk attributes like … device posture (i.e., presence of unsanctioned and vulnerable applications, compliance levels, etc.).” The specification describes compliance levels only in the context of prior art, and does not disclose compliance levels as an element considered by the claimed invention. Further, this paragraph describes compliance levels as one of several potential risk attributes, alongside vulnerable applications, and not as an indication that an application is vulnerable. This rejection can be overcome by amending the claim(s) such that they recite only that subject matter which is explicitly supported by the original disclosure.
Regarding claims 3, 5-7, 10, 12-14, 17, and 19-26:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 6, 8, 13, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over TEAL (Doc ID US 20190081983 A1), and further in view of AKELLA et al (Doc ID US 11349863 B2), BANSAL et al (Doc ID US 20210234860 A1), and BREGMAN et al (Doc ID US 20170270131 A1).
Regarding claim 1:
TEAL teaches:
intercepting all network traffic to and from the mobile device via an agent being installed on the mobile device configured to deploy a firewall on the mobile device ([0106] "... Other features that may be provided by a personal firewall may include … monitoring and regulation of incoming and outgoing network traffic …");
allowing or blocking, via the firewall deployed on the mobile device, all of the network traffic, or a portion of the network traffic based on the computed overall risk ([0106] "… The personal firewall may permit or deny communications based on a security policy. Personal firewalls may be designed for … protection for only the computer on which it's installed.") and
wherein the agent installed locally on the mobile device applies the computed overall risk to enforce the firewall deployed on the mobile device ([0106] "The personal firewall may permit or deny communications based on a security policy." and [0108] "... The administration facility 134 may configure policy rules that determine interactions, such as developing ... rules for determining access ..., including authentication, ... risk assessment ..."),
whereby only the network traffic, or the portion thereof, permitted by the firewall is transmitted from or received at the mobile device ([0106] "The personal firewall may permit or deny communications based on a security policy.").
AKELLA teaches the following limitations not taught by TEAL:
A non-transitory computer-readable medium storing computer-executable instructions, and in response to execution of an application on a mobile device, the computer-executable instructions cause the mobile device to perform the steps of (Col 4 lines 8-11 "These computer program instructions may also be stored in a computer-readable medium that can direct a computer ... to function in a particular manner …", col 5 lines7-11 "… computer system 114 ... can include ... mobile devices …", and Col 11 lines 42-45 "… computing system 114 includes communication manager 402, memory 404, … processor 410 …"):
deriving a static risk profile of the mobile device based on one or more parameters (Col 6 lines 12-17 "Computing system 114 computes a first static risk score corresponding to ... computing device 102). A static risk score ... can be a measure corresponding to one or more static risk factors ...")
determining a dynamic risk of the mobile device based on dynamic network flow attributes monitored locally on the mobile device by the agent (Col 6 lines 58-61 "Dynamic influences ... provide a basis for computing dynamic risk scores and dynamic risk factors from analyzed network communication.");
computing, on the mobile device, an overall risk for the network traffic based on the static risk profile and the dynamic risk (Col 6 lines 61-63 "An overall risk associated with a computing device can be computed from a combination of an associated static risk and dynamic risk."); and
Intercepting network traffic on a device with a locally installed agent and using a local firewall to allow or block network traffic based on received policies are known techniques in the art, as demonstrated by TEAL.
Further, calculating static and dynamic risk to the device associated with network traffic and determining overall risk based on the static and dynamic risk are known techniques in the art, as demonstrated by AKELLA. 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 local traffic interception and firewall of TEAL with the network traffic risk calculation of AKELLA with the motivation to offload the need to maintain an up-to-date repository of risk parameters to a third party service such as a cloud or remote server. It is obvious to seek a third-party security service which has more concentrated expertise in maintaining risk parameters for risk calculations.
BANSAL ‘860 teaches the following limitations not taught by the above combination:
determining, by the agent, whether the source application is vulnerable or whether a user of the mobile device is not authorized to use the source application ([0168] "… looking up received source application information in the malware repository 1224 to determine if the source application is safe or unsafe …");
determining, by the agent, whether the source application is vulnerable, wherein determining that the source application is vulnerable comprises determining, from device posture included in the static risk profile, that the source application is unsanctioned or that a compliance level associated with the mobile device indicates the source application is vulnerable ([0076] "… the application 350 can detect trusted networks, allowed applications, etc." and [0168] "… looking up received source application information in the malware repository 1224 to determine if the source application is safe or unsafe …");
determining, by the agent, whether at least one traffic pattern of the network traffic matches predefined block rules configured by an Information Technology (IT) administrator ([0167] "Upon receiving the tuple that includes the source application information ... the secure cloud gateway 1220 is configured to perform a static lookup of the source application and related traffic patterns to identify any potential malware or policy violations ..."); and
based on at least one of the determination that the source application is vulnerable, the determination that the user is not authorized to use the source application, or the determination that the at least one traffic pattern matches the predefined block rules ([0176] "... The results will be used by the mobile user device to determine the next actions to take. ... The first result (or condition) is ALLOW; the second is DENY; and the third, CAUTION."),
whereby network traffic originating from or destined to the source application is blocked regardless of changes in a destination Internet Protocol address used by the source application ([0076] "The application 350 is configured to auto-route traffic for a seamless user experience. This can be protocol as well as application-specific" and [0170] "… if another mobile user device sends similar network traffic from the same source application, the cloud server 1204 can immediately detect the malware and issue a DENY response."),
Identifying a malicious source application and blocking communication to that source application in response to it being malicious are known techniques in the art, as demonstrated by BANSAL ‘860. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL and AKELLA with the source application assessment and blocking of BANSAL ‘860 with the motivation to enable the system to block any communication from an application rather than individual network packets each time they are received. This is a known technique which has been used to improve similar devices.
BREGMAN teaches the following limitations not taught by the above combination:
determining, by the agent, whether a user of the mobile device is not authorized to use the source application, wherein determining that the user of the mobile device is not authorized to use the source application comprises applying access rules that vary based on a user group associated with the user, the access rules including a rule controlling Secure Shell (SSH) access to a remote machine ([0022] "... specific applications for which ... management is provided by a master host directory system … can include SSH access management .... In SSH access management applications, implementations ... can be part of standards-based SSH access to cloud servers and virtual machines, providing ... authorization of SSH login (... login system determines if an authenticated user should be granted access ... based on role). ... a user ... thereafter being allowed access to a target host with an appropriate level of privileges based on group membership and/or other role-based criteria).");
Determining application access based on a group or role assigned to a user, which dictates their authorization for SSH access to a remote machine, is a known technique in the art, as demonstrated by BREGMAN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the local firewall of TEAL, AKELLA, and BANSAL ‘860 with the policy and role based access control for SSH access of BREGMAN with the motivation to expand the coverage of the firewall to include user-based access control, instead of device-based only. This is a known technique which has been used to improve similar devices.
Regarding claim 6:
The combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN teaches:
The non-transitory computer-readable medium of claim 1, wherein prior to the intercepting, the steps comprise: authenticating a user of the mobile device (BANSAL ‘860 [0179] "… In the embodiment shown in FIG. 23, ... waiting for a ... authenticated mobile user device) to request that a tunnel be opened …");
downloading configuration, policy, and traffic forwarding rules associated with the user (BANSAL ‘860 [0180] "... the process 1300 further includes … downloading configuration information, … policies, and traffic rules/policies …"); and
allowing or blocking all of the network traffic, or a portion of the network traffic based on the configuration, policy, and traffic forwarding rules (BANSAL ‘860 [0181] "… The process 1300 further includes allowing the cloud server to ... identify potential ... policy violations, as indicated in block 1312." and [0182] "... if ... the analysis reveals ... network packets ... do not violate any network or enterprise rules/policies, the process 1300 include following the ALLOW path ....").
Authenticating a user prior to network access, acquiring configuration, policy, and traffic management data, and filtering traffic based on the user and data are known techniques in the art, as demonstrated by BANSAL ‘860. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL, AKELLA, BANSAL ‘860, and BREGMAN with the user authentication and configuration method of BANSAL ‘860 with the motivation to not solely rely on risk analysis to determine network access. It is obvious to screen unauthorized users prior to allowing access, and likewise obvious to acquire configuration and policy data so that prohibited network traffic, even if otherwise benign, may also be blocked.
Regarding claims 8, 13, 15, and 19:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 1 and 6 above.
Claims 3, 5, 10, 12, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over TEAL (Doc ID US 20190081983 A1), AKELLA et al (Doc ID US 11349863 B2), BANSAL et al (Doc ID US 20210234860 A1), and BREGMAN et al (Doc ID US 20170270131 A1) as applied to claims 1, 8, and 15 above, and further in view of BANSAL et al (Doc ID US 10225740 B2).
Regarding claim 3:
The combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN teaches:
The non-transitory computer-readable medium of claim 1,
BANSAL ‘740 teaches the following limitation not taught by the combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN:
wherein the parameters include geolocation (Col 3 lines 13-26 “... environment risk can include risk assessed by the cloud based security system based on geolocation ..."), network type, device posture (Col 2 lines 60-61 "... risk profiling thereof includes receiving posture data from the mobile device ..."), source application, and user risk profile (col 3 lines 13-26 "risk analysis can include ... application risk, ... user risk, and environment risk.”).
Considering a variety of factors in a risk calculation is a known technique in the art, as demonstrated by BANSAL ‘740. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL, AKELLA, BANSAL ‘860, and BREGMAN with the risk calculation parameters of BANSAL ‘740 with the motivation to sample a broad spectrum of factors when determining risk. It is obvious to consider such elements as location, device posture, and user risk in this calculation.
Regarding claim 5:
The combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN teaches:
The non-transitory computer-readable medium of claim 1,
BANSAL ‘740 teaches the following limitation not taught by the combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN:
wherein the dynamic network flow attributes are logged for reporting purposes (Col 7 line 67 to col 8 line 2 "Each of the logging nodes 140 may store data related to … network traffic processed by the processing nodes 110 for each external system.").
Logging network traffic data for reporting is a known technique in the art, as demonstrated by BANSAL ‘740. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL, AKELLA, BANSAL ‘860, and BREGMAN with the network data logs of BANSAL ‘740 with the motivation to retain network logs for later reports. It is obvious to maintain these logs so that administrators can examine it at a later time to troubleshoot problems or to conduct root cause analysis.
Regarding claims 10, 12, and 17:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 3 and 5 above.
Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over TEAL (Doc ID US 20190081983 A1), AKELLA et al (Doc ID US 11349863 B2), BANSAL et al (Doc ID US 20210234860 A1), and BREGMAN et al (Doc ID US 20170270131 A1) as applied to claims 1, 8, and 15 above, and further in view of NEYSTADT et al (Doc ID US 20080244748 A1).
Regarding claim 7:
The combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN teaches:
The non-transitory computer-readable medium of claim 1,
NEYSTADT teaches the following limitation not taught by the combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN:
wherein the steps further comprise: consulting via the agent on the mobile device a cloud security system to derive the risk associated with the parameters ([0036] "… Security assessment criteria 220 may be received from ... a third party (for example, a local or remote service).").
Interacting with a remote third party for the purposes of risk calculation is a known technique in the art, as demonstrated by NEYSTADT. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL, AKELLA, BANSAL ‘860, and BREGMAN with the remote security service of NEYSTADT with the motivation to offload the need to maintain an up-to-date repository of risk parameters to a third-party service such as a cloud or remote server. It is obvious to seek a third-party security service which has more concentrated expertise in maintaining risk parameters for risk calculations.
Regarding claims 14 and 20:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claim 7 above.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over TEAL (Doc ID US 20190081983 A1), AKELLA et al (Doc ID US 11349863 B2), BANSAL et al (Doc ID US 20210234860 A1), and BREGMAN et al (Doc ID US 20170270131 A1) as applied to claim 1 above, and further in view of KUPPANNAN et al (Doc ID US 20200366648 A1).
Regarding claim 21:
The combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN teaches:
The non-transitory computer-readable medium of claim 1,
KUPPANNAN teaches the following limitations not taught by the combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN:
wherein, for each Domain Name System (DNS) query generated by the mobile device, the agent: records a mapping between the queried domain name and an Internet Protocol (IP) address returned in response to the DNS query ([0029] "The HNACS ... determines based on the intercepted DNS response, a mapping between the ... intercepted DNS query and an IP address corresponding to the hostname .... HNACS converts the hostnames into IP addresses."); and
applies rules of the firewall to the network traffic addressed to the IP address based on the mapped domain name ([0029] "… ... thereby allowing the host-based firewall to implement the hostname based firewall policy …").
Mapping IP addresses to DNS queries and applying firewall rules to traffic involving the addresses are known techniques in the art, as demonstrated by KUPPANNAN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL, AKELLA, BANSAL ‘860, and BREGMAN with the DNS filtering of KUPPANNAN with the motivation to expand the use-cases of the system from IP addresses to DNS queries. It is obvious to include DNS queries as many connection attempts will begin with a user-entered host-name. It is obvious to include the DNS queries in a risk assessment of network traffic.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over TEAL (Doc ID US 20190081983 A1), AKELLA et al (Doc ID US 11349863 B2), BANSAL et al (Doc ID US 20210234860 A1), and BREGMAN et al (Doc ID US 20170270131 A1) as applied to claim 1 above, and further in view of BEN-SHALOM et al (Doc ID US 20080159152 A1).
Regarding claim 22:
The combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN teaches:
The non-transitory computer-readable medium of claim 1,
BEN-SHALOM teaches the following limitations not taught by the combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN:
wherein the steps further comprise conditionally allowing, by the agent, a network flow of the intercepted network traffic for deception purposes while continuing to monitor the network flow and send a risk profile of the network flow to the cloud security system ([0014] "… intrusion prevention system 112 ... designed to analyze, detect and report on security related events …" and [0015] "… IPS 112 may be connected to a router 114 …. Router 114 may be configured to deliver both expected data packets as well as any suspicious and/or infected data packets that are allowed to pass through IPS 112.").
Sometimes allowing certain network flows and providing reports on the traffic are known techniques in the art, as demonstrated by BEN-SHALOM. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL, AKELLA, BANSAL ‘860, and BREGMAN with the conditionally allowed network flow and reporting of BEN-SHALOM with the motivation to assess suspicious flow further by monitoring its behavior once beyond the firewall. It is obvious to sometimes allow suspicious traffic and to report its presence when attempting to assess risk of network traffic.
Claim 23 is rejected under 35 U.S.C. 103 as being unpatentable over TEAL (Doc ID US 20190081983 A1), AKELLA et al (Doc ID US 11349863 B2), BANSAL et al (Doc ID US 20210234860 A1), and BREGMAN et al (Doc ID US 20170270131 A1) as applied to claim 1 above, and further in view of CAPELLMAN (Doc ID US 20230281314 A1).
Regarding claim 23:
The combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN teaches:
The non-transitory computer-readable medium of claim 1,
CAPELLMAN teaches the following limitations not taught by the combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN:
wherein the agent installed on the mobile device is to re-evaluate the static risk profile and recompute the overall risk each time the mobile device experiences a change in network connectivity or after a periodic interval ([0011] "… The device data can include ... internet protocol (IP) addresses accessed at the client device, implemented security settings at the client device ..."" and [0040] ""... the risk score 142 can be periodically updated (e.g., recomputed) or can be updated based on certain types of events, such as a new network connection ...".).
Examiner notes that the prior art does not explicitly categorize the evaluated factors into static and dynamic factors which are combined. Rather, factors identified in the specification of the instant application as being representative of static and dynamic factors are represented among the plurality of evaluated factors in the prior art.
Occasionally reassessing risk after time has passed or there has been a network change is a known technique in the art, as demonstrated by CAPELLMAN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL, AKELLA, BANSAL ‘860, and BREGMAN with the risk profile reassessment of CAPELLMAN with the motivation to ensure that calculated risk profiles do not become “stale” over time so that they no longer are an accurate representation of the actual risk. It is obvious to periodically reassess risk present in an environment as dynamic as an online network environment.
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over TEAL (Doc ID US 20190081983 A1), AKELLA et al (Doc ID US 11349863 B2), BANSAL et al (Doc ID US 20210234860 A1), and BREGMAN et al (Doc ID US 20170270131 A1) as applied to claim 1 above, and further in view of CRISLER et al (Doc ID US 20160359900 A1).
Regarding claim 24:
The combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN teaches:
The non-transitory computer-readable medium of claim 1,
CRISLER teaches the following limitations not taught by the combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN:
wherein, for each network flow, the agent records a tuple comprising a client-application identifier, a source Internet Protocol (IP) address, a source port, a destination IP address, a destination port, a destination domain name, and a protocol, and wherein determining the dynamic risk comprises using the recorded tuple as the dynamic network flow attributes ([0033] "The network analyzer may then collect ... data attributes associated with the ... traffic so intercepted or log files so received′. The data attributes may include, for example, sources and destinations of the traffic (e.g., an Internet Protocol (IP) address or domain name), network port and network protocol identifiers associated with the traffic, ... and other suitable metadata ..." and [0035] "The network analyzer 102 may be configured to initiate a block or redirection of the intercepted traffic based on threats scores associated with the values of the data attributes.").
Recording source and destination information for IP addresses and ports, domain information, and protocol information as part of collecting network flow information is a well-known technique in the art, as demonstrated by CRISLER. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL, AKELLA, BANSAL ‘860, and BREGMAN with the network flow attributes of CRISLER with the motivation to use the most commonly used attributes of network data to determine a risk profile.
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over TEAL (Doc ID US 20190081983 A1), AKELLA et al (Doc ID US 11349863 B2), BANSAL et al (Doc ID US 20210234860 A1), and BREGMAN et al (Doc ID US 20170270131 A1) as applied to claim 1 above, and further in view of BASAVAPATNA et al (Doc ID US 20130097711 A1).
Regarding claim 25:
The combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN teaches:
The non-transitory computer-readable medium of claim 1,
BASAVAPATNA teaches the following limitations not taught by the combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN:
wherein the agent determines Wi-Fi security information for a wireless access network used by the mobile device and transmits the Wi-Fi security information to the cloud security system to enrich hotspot risk data ([0015] "... Pre-existing risk assessment data for the identified particular wireless access point can be generated in connection with at least one previous encounter ... by an endpoint device. The previous encounter with the particular wireless access point may have been made, for example, by an endpoint device other than the particular endpoint device."), and
wherein the agent derives the static risk profile based at least in part on hotspot risk data obtained from the cloud security system ([0013] "The wireless access point risk assessor ... can receive a query from a particular endpoint device identifying a particular wireless access point ... and send query result data ... characterizing pre-assessed risk associated with the particular wireless access point. ... the system can ... calculate a risk profile for the particular endpoint device based on a set of device attributes including risk associated with wireless access points accessed by the particular endpoint device.").
Utilizing Wi-Fi “hotspot” (access point) information to inform a central repository and to formulate risk profiles is a well-known technique in the art, as demonstrated by BASAVAPATNA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL, AKELLA, BANSAL ‘860, and BREGMAN with the Wi-Fi access point security information of BASAVAPATNA with the motivation to include the point from which a device is accessing the network as a consideration in the static (and by extension, overall) risk profile of the device.
Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over TEAL (Doc ID US 20190081983 A1), AKELLA et al (Doc ID US 11349863 B2), BANSAL et al (Doc ID US 20210234860 A1), and BREGMAN et al (Doc ID US 20170270131 A1) as applied to claim 1 above, and further in view of ZAMIR et al (Doc ID US 20240143737 A1).
Regarding claim 26:
The combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN teaches:
The non-transitory computer-readable medium of claim 1,
ZAMIR teaches the following limitations not taught by the combination of TEAL, AKELLA, BANSAL ‘860, and BREGMAN:
wherein the steps further comprise logging, by the agent, network flows of the intercepted network traffic and transmitting the logged network flows from the mobile device to a preconfigured Security Information and Event Management cloud system for reporting purposes ([0022] "In addition to providing the network data 124 to the analytics 108, … the collector 114 also provides the network data 124 to a security information and event management (SIEM) …").
Sending captured network traffic data as log data to a Security Information and Event Management (SIEM) system is a known technique in the art, as demonstrated by ZAMIR. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the network traffic risk calculation of TEAL, AKELLA, BANSAL ‘860, and BREGMAN with the SIEM log upload of ZAMIR with the motivation maintain a log of the analyzed network data for future manual analysis by security or IT professionals, or to diagnose the system.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
NELLEN (Doc ID US 20190141015 A1) teaches a decentralized, zero-trust firewall similar to that in the instant application. However, it is based around protecting an individual user device, and not for protecting a networked system against other user devices.
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.
/BRANDON BINCZAK/Examiner, Art Unit 2437
Prosecution Insights