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 .
Detailed Action
Office Action is in response to the reply filed by Applicant on 8/11/2026. Claim 7 has been cancelled. Claims 1-6 and 8-20 are pending. This Office Action is Final.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 6/9/2026, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
A) Applicant’s arguments with respect to claim(s) 1, 17 and 19 have been considered but are moot because the new ground of rejection does not rely on the exact combination of references applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 9, 16, 17 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mestery et al. (US 2023/0269228) in view of Shkedy et al. (US 2023/0224318) and Israel et al. (US 2025/0220049).
As per claim 1, Mestery teaches a system, comprising: a processor configured to: receive traffic associated with a User Equipment (UE) from a mobile network at a Secure Access Service Edge (SASE) cloud network, wherein the UE is an unmanaged device (Mestery, Paragraph 0016 recites “Systems, methods, and computer-readable media are disclosed for managing network traffic (transmission of data packets) in a cloud-based service that remotely connects endpoints using a Secure Access Service Edge (SASE) architecture. In some aspects, network traffic management in a SASE architecture includes a determination at the cloud-based SASE controller (e.g., a datacenter) that certain network traffic from certain remotely connected user devices should be dropped followed by a pre-emptive dropping of such traffic at the corresponding remotely connected user device before the traffic reaches a headend component at a cloud-based SASE controller.”);
extract contextual information associated with the traffic to determine a security policy to apply to the traffic (Mestery, Paragraphs 0060-0061 recites “Referring back to S500, if controller 302 does not determine user device 304 to be a new or returning device, then at S506, controller 302 receives network traffic from user device 304. This network traffic may be received after user device 304 successfully establishes a VPN connection to controller 304 according to any known or to be developed VPN connection mechanism/protocol (e.g., PPTP, IPSec, L2TP, SSL, IKEv2, etc.). At S508, controller 302 sends the network traffic received at S506, to one or more cloud-delivered firewall devices (e.g., CDFWs 408) for analysis. CDFW 408 may analyze the network traffic and apply appropriate network policies and rules to determine if the network traffic should be dropped.”) and
a memory coupled to the processor and configured to provide the processor with instructions (Mestery, Paragraph 0069 recites “Exemplary system 600 includes a processing unit (CPU or processor) 610 and a system connection 605 that couples various system components including the system memory 615, such as read only memory (ROM) 620 and random access memory (RAM) 625, to the processor 610.”).
But fails to teach wherein the extracting of the contextual information
comprises to: performing one or more of the following: extracting the contextual information from a Packet Forwarding Control Protocol (PFCP) including PFCP session establishment requests and/or PFCP session establishment responses; extracting the contextual information from a Radius protocol including Accounting-Request (START) messages, Accounting-Response (START) messages, Accounting-Request (interim-update) messages and/or Accounting- Response (interim-update) messages;
extracting the contextual information from a Diameter protocol including
Accounting-Request (START) messages, Accounting-Response (START)
messages, Accounting-Request (Interim) messages, and/or Accounting-Response
(Interim) messages; extracting the contextual information from a Syslog message including information relating to creation events and/or deletion events;
extracting the contextual information from an Application Programming
Interface (API) relating to a push mechanism and/or a pull mechanism; and/or
extracting the contextual information from a Geneve protocol over a
Geneve tunnel.
However, in an analogous art Shkedy teaches wherein the extracting of the contextual information comprises to: performing one or more of the following: extracting the contextual information from a Packet Forwarding Control Protocol (PFCP) including PFCP session establishment requests and/or PFCP session establishment responses; extracting the contextual information from a Radius protocol including Accounting-Request (START) messages, Accounting-Response (START) messages, Accounting-Request (interim-update) messages and/or Accounting- Response (interim-update) messages; extracting the contextual information from a Diameter protocol including
Accounting-Request (START) messages, Accounting-Response (START)
messages, Accounting-Request (Interim) messages, and/or Accounting-Response
(Interim) messages; extracting the contextual information from a Syslog message including information relating to creation events and/or deletion events;
extracting the contextual information from an Application Programming
Interface (API) relating to a push mechanism and/or a pull mechanism; and/or
extracting the contextual information from a Geneve protocol over a
Geneve tunnel (Shkedy, Paragraph 0030 recites “FIG. 4 is a method that automatically performs application security testing. First, agents are installed in a customer system to intercept live traffic at step 410. Live URL traffic consisting of API requests and responses can be intercepted between computing devices and servers by the agent (or, in some instances, browser extensions) at step 320. The agents may intercept the traffic, aggregate the intercepted traffic data, and send the data from the agent to an application periodically, in response to a push or pull event, or based on some other event. The intercepted data can be used to determine the metric, identify traffic to be duplicated, identify user session identification, and other data, and used otherwise as discussed herein.” While there are multiple methods to extract data, only one method needs to be met to read on this limitation. Examiner is relying on Shkedy to read on the API method.).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Shkedy’s Application security testing based on live traffic with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of an improvement in testing for application security.
But fails to teach enforce the security policy on data plane traffic associated with the UE based on the contextual information associated with the UE to provide secured data plane traffic.
However, in an analogous art Israel enforce the security policy on data plane traffic associated with the UE based on the contextual information associated with the UE to provide secured data plane traffic (Israel, Paragraph 0014 recites “According to a general embodiment shown in FIG. 1, a system 10 is provided for automatically generating and applying a network security policy 11 based on network traffic. The system 10 includes a computer device 12 and networking hardware 14. Generally, the computer device 12 analyzes the network traffic to generate the network security policy 11 and sends the network security policy 11 to the networking hardware 14. The networking hardware 14 routes the network traffic and implements the network security policy 11.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Israel’s Autonomous network policy generator with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having efficient configuration and maintenance of security policies with digital assets of companies and organizations.
As per claim 9, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, Israel further teaches wherein selection and the enforcement of the security policy is based on the contextual information associated with the UE and the data plane traffic correlated with the UE based on a UE Internet Protocol (IP) address (Israel, Paragraph 0031 recites “As an example, if one of the nodes 32 in a cluster included a network connection 20 with an IP address for a DNS server on port 53, then the network security rules 74 would permit all of the nodes 32 in the cluster to communicate over port 53 with the DNS server at the IP address. Similarly, if one of the nodes 32 in a cluster included a network connection 20 with a URL for a server, then the network security rules may permit all of the nodes 32 in the cluster to communicate with the URL.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Israel’s Autonomous network policy generator with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having efficient configuration and maintenance of security policies with digital assets of companies and organizations.
As per claim 16, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, Shkedy further teaches wherein the processor is further configured to: receive a message over a network protocol from the mobile network at the SASE cloud network, wherein contextual information associated with the message is communicated using a Packet Forwarding Control Protocol (PFCP), a Radius protocol, a Diameter protocol, Syslog messages, an Application Programming Interface (API), and/or a Geneve protocol.
(Shkedy, Paragraph 0030 recites “FIG. 4 is a method that automatically performs application security testing. First, agents are installed in a customer system to intercept live traffic at step 410. Live URL traffic consisting of API requests and responses can be intercepted between computing devices and servers by the agent (or, in some instances, browser extensions) at step 320. The agents may intercept the traffic, aggregate the intercepted traffic data, and send the data from the agent to an application periodically, in response to a push or pull event, or based on some other event. The intercepted data can be used to determine the metric, identify traffic to be duplicated, identify user session identification, and other data, and used otherwise as discussed herein.” While there are multiple methods to extract data, only one method needs to be met to read on this limitation. Examiner is relying on Shkedy to read on the API method.).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Shkedy’s Application security testing based on live traffic with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of an improvement in testing for application security.
Regarding claims 17 and 19, claims 17 and 19 are directed to a method and a computer program product associated with the system of claim 1. Claims 17 and 19 are of similar scope to claim 1, and are therefore rejected under similar rationale.
Claim(s) 2-6, 15, 18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mestery et al. (US 2023/0269228), Shkedy et al. (US 2023/0224318) and Israel et al. (US 2025/0220049) and in further view of Haddad et al. (US 2025/0203367).
As per claim 2, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein the unmanaged device includes a Subscriber Identity Module (SIM) card.
However, in an analogous art Haddad teaches wherein the unmanaged device includes a Subscriber Identity Module (SIM) card (Haddad, Paragraph 0097 recites “In some embodiments, the end user device 701 may have 4G/5G eSIM (embedded SIM) profile installed. However, it is not mandatory for the end user device 701 to be connected to a 4G/5G network according to some embodiments of the present disclosure.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Haddad’s enabling cellular based zero trust network access with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having improved visibility into user devices' activities.
As per claim 3, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein a certificate for the UE is received at a certificate manager for the SASE cloud network from a mobile network operator, and wherein the certificate is used for traffic decryption to facilitate zero trust network access (ZTNA) using a security service of the SASE cloud network.
However, in an analogous art Haddad teaches wherein a certificate for the UE is received at a certificate manager for the SASE cloud network from a mobile network operator, and wherein the certificate is used for traffic decryption to facilitate zero trust network access (ZTNA) using a security service of the SASE cloud network (Haddad, Paragraph 0116 recites “In addition to enabling embedded VPN, the embodiments of the present disclosure integrate SASE features (crypto-tables, artificial intelligence (AI), firewall, proxy, etc.) in the enhanced UPF and allow pushing such node closer to the IT services running on premise and/or in public cloud. In addition, VPN encryption granularity can be coordinated by the SASE on a per application, per user device, and/or per user basis. Devices and applications do not need any additional key, as is the case of traditional VPN certificate. They just need the 4G/5G (or any future cellular generations) keys, such as eSIM profile keys. Any communication from or to the devices that support the embodiments of the present disclosure go through a SASE firewall (FW). Embodiments of the present disclosure allow provisioning SASE entity 903 to decide whether it needs to snoop at packets whenever needed, taking into consideration initiator identity, status, time, location, type of application, etc., between the end user device (e.g., UE) and the targeted app(s) or allows a full end-to-end secure communication between the two entities”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Haddad’s enabling cellular based zero trust network access with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having improved visibility into user devices' activities.
As per claim 4, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein the mobile network includes a service provider's 4G mobile network, a service provider's 5G mobile network, and/or a service provider's 6G mobile network.
However, in an analogous art Haddad teaches wherein the mobile network includes a service provider's 4G mobile network, a service provider's 5G mobile network, and/or a service provider's 6G mobile network (Haddad, Paragraph 0031 recites “The present disclosure generally relates to an apparatus and method for establishing a secured connection with an application entity in an enterprise network. While the example embodiments described below are primarily described with respect to 4G and/or 5G communication networks, the disclosure is also applicable to existing technologies such as GSM, 3G, and other future technologies, such as 6G networks and beyond.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Haddad’s enabling cellular based zero trust network access with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having improved visibility into user devices' activities.
As per claim 5, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein the mobile network includes a private 4G mobile network, a private 5G mobile network, and/or a private 6G mobile network.
However, in an analogous art Haddad teaches wherein the mobile network includes a private 4G mobile network, a private 5G mobile network, and/or a private 6G mobile network (Haddad, Paragraph 0031 recites “The present disclosure generally relates to an apparatus and method for establishing a secured connection with an application entity in an enterprise network. While the example embodiments described below are primarily described with respect to 4G and/or 5G communication networks, the disclosure is also applicable to existing technologies such as GSM, 3G, and other future technologies, such as 6G networks and beyond.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Haddad’s enabling cellular based zero trust network access with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having improved visibility into user devices' activities.
As per claim 6, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein the mobile network includes an enterprise Wi-Fi network, a public Wi-Fi network, and/or a residential Wi-Fi network.
However, in an analogous art Haddad teaches wherein the mobile network includes an enterprise Wi-Fi network, a public Wi-Fi network, and/or a residential Wi-Fi network (Haddad, Paragraph 0052 recites “In the illustrated embodiment, communication functions of the communication interface 212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and/or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol/internet protocol (TCP/IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.” And Paragraph 0031 recites “The present disclosure generally relates to an apparatus and method for establishing a secured connection with an application entity in an enterprise network.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Haddad’s enabling cellular based zero trust network access with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having improved visibility into user devices' activities.
As per claim 15, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein the processor is further configured to: determine the security policy to apply at the SASE cloud network to the data plane traffic based on a subscriber identity and/or a unique device identifier.
However, in an analogous art Haddad teaches wherein the processor is further configured to: determine the security policy to apply at the SASE cloud network to the data plane traffic based on a subscriber identity and/or a unique device identifier (Haddad, Paragraph 0097 recites “In some embodiments, the end user device 701 may have 4G/5G eSIM (embedded SIM) profile installed. However, it is not mandatory for the end user device 701 to be connected to a 4G/5G network according to some embodiments of the present disclosure.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Haddad’s enabling cellular based zero trust network access with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having improved visibility into user devices' activities.
Regarding claims 18 and 20, claims 18 and 20 are directed to a method and a computer program product associated with the system of claim 2. Claims 18 and 20 are of similar scope to claim 2, and are therefore rejected under similar rationale.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mestery et al. (US 2023/0269228), Shkedy et al. (US 2023/0224318) and Israel et al. (US 2025/0220049) and in further view of Yadav et al. (US 2025/0310864).
As per claim 8, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein the SASE cloud network includes a firewall as a service that is configured with a plurality of security policies based on a subscriber identity, a unique device identifier, a subscriber number, and an application identifier, wherein the subscriber identity includes an International Mobile Subscriber Identity (IMSI), wherein the unique device identifier includes an International Mobile Equipment Identifier (IMEI), and wherein the subscriber number includes a General Public Subscription Identifier (GPSI), a Mobile Station International Subscriber Director Number (NSISDN), and/or another external identifier.
However, in an analogous art Yadav teaches wherein the SASE cloud network includes a firewall as a service that is configured with a plurality of security policies based on a subscriber identity, a unique device identifier, a subscriber number, and an application identifier, wherein the subscriber identity includes an International Mobile Subscriber Identity (IMSI), wherein the unique device identifier includes an International Mobile Equipment Identifier (IMEI), and wherein the subscriber number includes a General Public Subscription Identifier (GPSI), a Mobile Station International Subscriber Director Number (NSISDN), and/or another external identifier (Yadav, Paragraphs 0066-0067 recites “FIG. 2A is a high-level representation of functionality implemented within a SASE domain to ensure that devices in an MNO domain are authorized to access a tenant-specific network. In the example, a SASE controller within the SASE domain receives access ID-to-tenant mappings that map access IDs used by the MNO to particular tenants that are supported by the SASE domain. Access ID-to-tenant mappings can be established by an administrator of a tenant via, for example, a portal or Application Programming Interfaces (APIs). In an embodiment, an access ID-to-tenant mapping may map an International Mobile Subscriber Identity (IMSI) of a mobile subscriber and/or an International Mobile Equipment Identity (IMEI) of the mobile subscriber to a particular tenant. The access ID-to-tenant mappings do not change on a per-session basis and can be deemed to be session independent. In an embodiment, an access ID refers to information that is used to gain authenticated and/or authorized access to a network that is controlled by an MNO. An access ID may include SIM-based information such as IMSI, Mobile Station Integrated Services Digital Network (MSISDN), IMEI, 5G Subscription Concealed Identity (SUCI), IMSI-based Subscription Permanent Identifier (SUPI) and non-SIM-based information such as a certificate installed on the device, a USB-based authentication module (e.g., an RSA module), a YUBIKEY, or a biometric-based (e.g., fingerprint, face recognition, iris scan) authentication.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Yadav’s methods and systems for providing network connectivity to a secure access service edge (sase) domain with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of efficient client-based access control.
Claim(s) 10-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mestery et al. (US 2023/0269228), Shkedy et al. (US 2023/0224318) and Israel et al. (US 2025/0220049) and in further view of Galloway et al. (US 2022/0103594).
As per claim 10, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein a firewall as a service (FWaaS) associated with the SASE cloud network is configured to perform Uniform Resource Link (URL) filtering for the data plane traffic.
However, in an analogous art Galloway teaches wherein a firewall as a service (FWaaS) associated with the SASE cloud network is configured to perform Uniform Resource Link (URL) filtering for the data plane traffic (Galloway, Paragraph 0032 recites “As used herein, a “network security appliance” or a “network security device” generally refers to a device or appliance in virtual or physical form that is operable to perform one or more security functions. Some network security devices may be implemented as general-purpose computers or servers with appropriate software operable to perform one or more security functions. Other network security devices may also include custom hardware (e.g., one or more custom Application-Specific Integrated Circuits (ASICs)). A network security device is typically associated with a particular network (e.g., a private enterprise network) on behalf of which it provides the one or more security functions. The network security device may reside within the particular network that it is protecting, or network security may be provided as a service with the network security device residing in the cloud. Non-limiting examples of security functions include authentication, next-generation firewall protection, antivirus scanning, content filtering, data privacy protection, web filtering, network traffic inspection (e.g., secure sockets layer (SSL) or Transport Layer Security (TLS) inspection), intrusion prevention, intrusion detection, denial of service attack (DoS) detection and mitigation, encryption (e.g., Internet Protocol Secure (IPSec), TLS, SSL), application control, Voice over Internet Protocol (VoIP) support, Virtual Private Networking (VPN), data leak prevention (DLP), antispam, antispyware, logging, reputation-based protections, event correlation, network access control, vulnerability management, and the like.” And Paragraph 0090 recites “For example, in addition to or as an alternative to adjusting security function behavior based on being inside/outside a trusted network, the endpoint security engine may also adjust behavior based on country, geolocation, or other network properties (e.g., adjusting logging when the endpoint device is located in a country regulated by General Data Protection Regulation (GDPR), increasing security posture when the endpoint device is located in a high risk country (Russia, China, etc.), adjusting web/URL filtering policy based on whether the endpoint device is inside/outside of trusted network, and/or disabling quarantine when the endpoint device leaves a trusted network so that endpoint device is able to connect to a public network and get remediated).”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Galloway’s adjusting behavior of an endpoint security agent based on network location with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having a thorough firewall systems.
As per claim 11, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein a firewall as a service (FWaaS) associated with the SASE cloud network is configured to perform application Denial of Service (DoS) detection for the data plane traffic.
However, in an analogous art Galloway teaches wherein a firewall as a service (FWaaS) associated with the SASE cloud network is configured to perform application Denial of Service (DoS) detection for the data plane traffic (Galloway, Paragraph 0032 recites “As used herein, a “network security appliance” or a “network security device” generally refers to a device or appliance in virtual or physical form that is operable to perform one or more security functions. Some network security devices may be implemented as general-purpose computers or servers with appropriate software operable to perform one or more security functions. Other network security devices may also include custom hardware (e.g., one or more custom Application-Specific Integrated Circuits (ASICs)). A network security device is typically associated with a particular network (e.g., a private enterprise network) on behalf of which it provides the one or more security functions. The network security device may reside within the particular network that it is protecting, or network security may be provided as a service with the network security device residing in the cloud. Non-limiting examples of security functions include authentication, next-generation firewall protection, antivirus scanning, content filtering, data privacy protection, web filtering, network traffic inspection (e.g., secure sockets layer (SSL) or Transport Layer Security (TLS) inspection), intrusion prevention, intrusion detection, denial of service attack (DoS) detection and mitigation, encryption (e.g., Internet Protocol Secure (IPSec), TLS, SSL), application control, Voice over Internet Protocol (VoIP) support, Virtual Private Networking (VPN), data leak prevention (DLP), antispam, antispyware, logging, reputation-based protections, event correlation, network access control, vulnerability management, and the like.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Galloway’s adjusting behavior of an endpoint security agent based on network location with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having a thorough firewall systems.
As per claim 12, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein a firewall as a service (FWaaS) associated with the SASE cloud network is configured to perform threat prevention for the data plane traffic.
However, in an analogous art Galloway teaches wherein a firewall as a service (FWaaS) associated with the SASE cloud network is configured to perform threat prevention for the data plane traffic (Galloway, Paragraph 0032 recites “As used herein, a “network security appliance” or a “network security device” generally refers to a device or appliance in virtual or physical form that is operable to perform one or more security functions. Some network security devices may be implemented as general-purpose computers or servers with appropriate software operable to perform one or more security functions. Other network security devices may also include custom hardware (e.g., one or more custom Application-Specific Integrated Circuits (ASICs)). A network security device is typically associated with a particular network (e.g., a private enterprise network) on behalf of which it provides the one or more security functions. The network security device may reside within the particular network that it is protecting, or network security may be provided as a service with the network security device residing in the cloud. Non-limiting examples of security functions include authentication, next-generation firewall protection, antivirus scanning, content filtering, data privacy protection, web filtering, network traffic inspection (e.g., secure sockets layer (SSL) or Transport Layer Security (TLS) inspection), intrusion prevention, intrusion detection, denial of service attack (DoS) detection and mitigation, encryption (e.g., Internet Protocol Secure (IPSec), TLS, SSL), application control, Voice over Internet Protocol (VoIP) support, Virtual Private Networking (VPN), data leak prevention (DLP), antispam, antispyware, logging, reputation-based protections, event correlation, network access control, vulnerability management, and the like.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Galloway’s adjusting behavior of an endpoint security agent based on network location with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having a thorough firewall systems.
As per claim 13, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein a firewall as a service (FWaaS) associated with the SASE cloud network is configured to perform advanced threat prevention for the data plane traffic.
However, in an analogous art Galloway teaches wherein a firewall as a service (FWaaS) associated with the SASE cloud network is configured to perform advanced threat prevention for the data plane traffic (Galloway, Paragraph 0032 recites “As used herein, a “network security appliance” or a “network security device” generally refers to a device or appliance in virtual or physical form that is operable to perform one or more security functions. Some network security devices may be implemented as general-purpose computers or servers with appropriate software operable to perform one or more security functions. Other network security devices may also include custom hardware (e.g., one or more custom Application-Specific Integrated Circuits (ASICs)). A network security device is typically associated with a particular network (e.g., a private enterprise network) on behalf of which it provides the one or more security functions. The network security device may reside within the particular network that it is protecting, or network security may be provided as a service with the network security device residing in the cloud. Non-limiting examples of security functions include authentication, next-generation firewall protection, antivirus scanning, content filtering, data privacy protection, web filtering, network traffic inspection (e.g., secure sockets layer (SSL) or Transport Layer Security (TLS) inspection), intrusion prevention, intrusion detection, denial of service attack (DoS) detection and mitigation, encryption (e.g., Internet Protocol Secure (IPSec), TLS, SSL), application control, Voice over Internet Protocol (VoIP) support, Virtual Private Networking (VPN), data leak prevention (DLP), antispam, antispyware, logging, reputation-based protections, event correlation, network access control, vulnerability management, and the like.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Galloway’s adjusting behavior of an endpoint security agent based on network location with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having a thorough firewall systems.
As per claim 14, Mestery in combination with Israel and Shkedy teaches the system recited in claim 1, but fails to teach wherein a firewall as a service (FWaaS) associated with the SASE cloud network is configured to perform advanced Uniform Resource Link (URL) filtering for the data plane traffic.
However, in an analogous art Galloway teaches wherein a firewall as a service (FWaaS) associated with the SASE cloud network is configured to perform advanced Uniform Resource Link (URL) filtering for the data plane traffic (Galloway, Paragraph 0032 recites “As used herein, a “network security appliance” or a “network security device” generally refers to a device or appliance in virtual or physical form that is operable to perform one or more security functions. Some network security devices may be implemented as general-purpose computers or servers with appropriate software operable to perform one or more security functions. Other network security devices may also include custom hardware (e.g., one or more custom Application-Specific Integrated Circuits (ASICs)). A network security device is typically associated with a particular network (e.g., a private enterprise network) on behalf of which it provides the one or more security functions. The network security device may reside within the particular network that it is protecting, or network security may be provided as a service with the network security device residing in the cloud. Non-limiting examples of security functions include authentication, next-generation firewall protection, antivirus scanning, content filtering, data privacy protection, web filtering, network traffic inspection (e.g., secure sockets layer (SSL) or Transport Layer Security (TLS) inspection), intrusion prevention, intrusion detection, denial of service attack (DoS) detection and mitigation, encryption (e.g., Internet Protocol Secure (IPSec), TLS, SSL), application control, Voice over Internet Protocol (VoIP) support, Virtual Private Networking (VPN), data leak prevention (DLP), antispam, antispyware, logging, reputation-based protections, event correlation, network access control, vulnerability management, and the like.”).
It would have been obvious to a person of ordinary skill in the art, before the earliest effective filing date, to use Galloway’s adjusting behavior of an endpoint security agent based on network location with Mestery’s pre-emptive flow dropping in a cloud-based secure access service because it offers the advantage of having a thorough firewall systems.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODERICK TOLENTINO whose telephone number is (571)272-2661. The examiner can normally be reached Mon- Fri 8am-4pm.
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, Luu Pham can be reached at 571-270-5002. 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.
RODERICK . TOLENTINO
Examiner
Art Unit 2439
/RODERICK TOLENTINO/Primary Examiner, Art Unit 2439
Prosecution Insights