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 .
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because the abstract should avoid phrases which can be implied such as “…(SASE) Interconnect Platform are disclosed”. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because “a computer program product” can be a signal per se. The specification does not provide a closed definition for a computer program product that prevent the computer program product and the tangible readable storage medium from being a signal per se. Furthermore, the specification does not defined the tangible computer readable storage medium to prevent the tangible readable storage medium from being a signal per se.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Verma et al US 20200128399 (hereinafter Verma), in view of Andreasen et al US 20250274489 (hereinafter Andreasen), and in further view of Beck US 20190372886 (hereinafter Beck).
As to claim 1, Verma teaches a system, comprising:
a processor configured to (Paragraph 25 discloses the invention is implemented via a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor):
receive ingress Service Provider (SP) data plane traffic for a tenant from an SP backbone (Paragraph 189 discloses network processor monitor/receives packets from mobile device and provide the packet to data plane for processing (Note: for mobile networks, data plane traffic refers to user data that flows between mobile device and the service provider’s network). The packets/traffic are identified as being part of a new session and a new session flow is created. Paragraph 194 discloses monitoring received network traffic on a service provider backbone/network at a security platform (see also paragraphs 199, 204, and 209). The security platform monitors GTP-U and HTTP/2 traffic on the mobile core network. Paragraph 54 reveals the techniques allow operators to provide network sliced based security to/for any customer/tenants);
extract contextual information associated with the SP data plane traffic to determine io a security policy to apply to the SP data plane traffic (Paragraphs 195-196 disclose extracting contextual information such as network slice information for user traffic associated with the new session at the security platform of the service provider network. The security platform can parse HTTP/2 messages to extract the network slice information, in which the network slice is identified by Single Network Slice Selection Assistance Information (S-NSSAI), using DPI-based firewall techniques. Paragraph 196 discloses determining a security policy to apply to the security platform to the new session based on the network sliced information. See also paragraphs 200-201, 205-206, and 210-211);
enforce the security policy on the SP data plane traffic to provide secured SP data plane traffic using a Security Processing Node (SPN) (Paragraph 197 discloses enforcing the security policy on the new session using the security platform such as various enforcement actions (e.g., allow/pass, block/drop, alert, tag, monitor, log, throttle, restrict access, and/or other enforcement actions). Action such as restrict access provides secure data plan traffic using the security processing node/security platform. Recall, paragraph 189 which discloses the packets/traffic are identified as being part of a new session. Paragraph 178 discloses techniques for providing enhanced security for 5G mobile/service provider networks using a security platform for security policy enforcement and paragraph 179 discloses using a security platform for security policy enforcement (e.g., using inspection and security capabilities. Paragraph 189 discloses policy enforcement (e.g., policies can include one or more rules, which can be specified using domain and/or host/server names, and rules can apply one or more signatures or other matching criteria or heuristics, such as for security policy enforcement for subscriber/IP flows on service provider networks based on various extracted parameters/information from monitored HTTP/2 messages and/or DPI of monitored GTP-U traffic as disclosed herein) is applied as described herein with respect to various embodiments based on the monitored, decrypted, identified, and decoded session traffic flows); and
egress the secured SP data plane traffic (Paragraph 197 discloses enforcing the security policy on the new session using the security platform such as various enforcement actions (e.g., allow/pass, block/drop, alert, tag, monitor, log, throttle, restrict access, and/or other enforcement actions). Therefore, passing/allowing/ restricting access to the traffic involves egress the secured SP data traffic); and
a memory coupled to the processor and configured to provide the processor with instructions (paragraph 25 discloses the invention is implemented via a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor).
Verma does not teach receive ingress data plane traffic from an SP backbone to a Secure Access Service Edge (SASE) cloud network for security processing via an Interconnect that is configured for a compute region and an IP block and an Autonomous System Number (ASN) to advertise the IP block in Border Gateway Protocol (BGP); egress the secured SP data plane traffic back to the SP backbone or to an external network.
Andreasen teaches receive ingress data plane traffic from an SP backbone to a Secure Access Service Edge (SASE) cloud network for security processing via an Interconnect (paragraph 58 discloses receiving at a network device, a packet sent from a user device. Paragraph 57 reveals the user device is associated with a network, thus is part of SP backbone/network). (Note: for mobile networks, data plane traffic refers to user data that flows between mobile device and the service provider’s network). Paragraph 22 reveals network devices may be considered part of a software defined wide area network SD-WAN (service provider network/interconnect). SD-WAN may present a virtual network through which a data traffic flow may pass from a user device at a particular branch, through one or more network devices to a particular data center. Paragraph 45 reveals traffic is traverses through the distributed SASE fabric and paragraph 46 reveals once packet leaves the SD-WAN (leaves the distributed SASE fabric, the exit SD-WAN router (e.g., network device ) can check the Security Service Header (e.g., header ) to verify that all required security functions have in fact been performed); enforce a security policy (Paragraphs 60-61 reveal performing security function/policy on the packet/data plan traffic) and egress the secured SP data plane traffic back to the SP backbone or to an external network (Paragraph 63 discloses forwarding the packet to the destination. Paragraph 24 reveals the intended destination for the data traffic packet may be a data center. Paragraph 59 reveals the destination of the packet may involve passing the packet out of the SD-WAN of an organization (thus passing to an external network). See also paragraph 46 and 51).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching of receiving ingress service provider data plane traffic for a tenant from an SP back with Andreasen’s teachings of a SASE receiving the data plane traffic to perform security policy-based routing between a network and the cloud, thereby improving performance of the network (Paragraph 1 of Andreasen).
The combination of Verma in view of Andreasen does not teach, but Beck teaches an Interconnect that is configured for a compute region and an IP block and an Autonomous System Number (ASN) to advertise the IP block in Border Gateway Protocol (BGP) (Paragraph 24 reveals a router (interconnect) may be any computing device that may be configured to forward data, such as Internet Protocol (IP) packets, from one computing device to another computing device. Paragraph 25 discloses an Autonomous Systems (AS), such as an Internet Service Provider (ISP), that is assigned a range(compute region) of Internet Protocol (IP) addresses/IP block, i.e., a netblock, may advertise or announce that the netblock is reachable by announcing a route to the AS with a route prefix for the netblock in a BGP update. A route prefix may indicate a netblock's IP address prefix and a length of the IP address prefix as a number of bits. Paragraph 26 discloses the number of ASs through which a packet must travel along a path to reach the AS the packet is addressed to may be that path's path length. The path length may refer to a number of hops through which the packet may travel to reach the AS to which the packet is addressed, with each hop representing a unique AS number (ASN) the packet is routed through along the path. BGP path lengths may be determined in BGP by counting the number of unique ASNs in a BGP update advertising a path. As BGP messages that advertise paths are received by routers, the paths and their attributes may be stored in routing tables for use in routing packets along those paths).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching of receiving ingress service provider data plane traffic for a tenant from an SP back in view of Andreasen’s teachings of SASE/interconnect receiving the data plane traffic with Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP to provide transparency as to the local security measures implemented along an AS path while enabling routing along secure paths and reducing the impact of BGP attacks (Paragraph 2 of Beck).
As to claim 3, the combination of Verma in view of Andreasen and Beck teaches wherein the Interconnect is configured via a portal for the compute region and the IP block and the ASN to advertise the IP block in the BGP (Beck: Paragraph 24 reveals a router (interconnect) may be any computing device (portal) that may be configured to forward data, such as Internet Protocol (IP) packets, from one computing device to another computing device. Paragraph 25 discloses an Autonomous Systems (AS), such as an Internet Service Provider (ISP), that is assigned a range(compute region) of Internet Protocol (IP) addresses/IP block, i.e., a netblock, may advertise or announce that the netblock is reachable by announcing a route to the AS with a route prefix for the netblock in a BGP update. A route prefix may indicate a netblock's IP address prefix and a length of the IP address prefix as a number of bits. Paragraph 26 discloses the number of ASs through which a packet must travel along a path to reach the AS the packet is addressed to may be that path's path length. The path length may refer to a number of hops through which the packet may travel to reach the AS to which the packet is addressed, with each hop representing a unique AS number (ASN) the packet is routed through along the path. BGP path lengths may be determined in BGP by counting the number of unique ASNs in a BGP update advertising a path. As BGP messages that advertise paths are received by routers, the paths and their attributes may be stored in routing tables for use in routing packets along those paths). Motivation similar to the motivation presented in claim 1.
As to claim 4, the combination of Verma in view of Andreasen and Beck teaches wherein the external network includes a tenant Data Center (DC) and/or an Internet (Andreasen: Paragraph 22 reveals the data traffic flow from the user device through one or more network devices to a data center. Paragraph 24 reveals the intended destination for the data traffic packet may be a data center, see also paragraphs 26-27). Motivation similar to the motivation presented in claim 1.
As to claim 5, the combination of Verma in view of Andreasen and Beck teaches wherein the contextual information is extracted using a Packet Forwarding Control Protocol (PFCP), a Radius protocol, a Diameter protocol, a Syslog 25 message, an Application Programming Interface (API), and/or a Geneve protocol (Verma: Paragraph 190 discloses an interface (I/F) communicator is also provided for security platform manager communications (e.g., via (REST) APIs, messages, or network protocol communications or other communication mechanisms). In some cases, network communications of other network elements on the service provider network are monitored using network device and data plane supports decoding of such communications. I/F communicator can be used to implement the disclosed techniques for security policy enforcement on mobile/service provider network environments as described).
As to claim 6, the combination of Verma in view of Andreasen and Beck teaches wherein the SPN 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 (MSISDN), and/or another external identifier (Verma: Paragraph 59 discloses enhanced security platforms/SPN (e.g., a firewall (FW)/Next Generation Firewall (NGFW), a network sensor acting on behalf of the firewall, or another device/component that can implement security policies using the disclosed techniques) within service provider network environments. Various system architectures for implementing and various processes for providing security platforms within service provider network environments for service-based security that can be applied using a security platform by parsing HTTP/2 messages to extract the contextual data such as Subscription Permanent Identifier (SUPI) (external identifier) information in mobile networks for service providers. Paragraph 62 reveals the SUPI includes IMSI information. See also paragraph 196).
As to claim 7, the combination of Verma in view of Andreasen and Beck teaches wherein the SP data plane traffic is secured from and to 4G, 5G, and/or 6G UE devices (Verma: Claim 5 discloses wherein the security platform monitors wireless interfaces including a plurality of interfaces for a control protocol and user data traffic in a mobile core network for a 4G and/or 5G network).
As to claim 8, the combination of Verma in view of Andreasen and Beck teaches wherein Internet access is secured from and to 4G, 5G, and/or 6G UE devices (Verma: Claim 5 discloses wherein the security platform monitors wireless interfaces including a plurality of interfaces for a control protocol and user data traffic in a mobile core network for a 4G and/or 5G network. Paragraph 118 further discloses the 5G network can also include Fixed/Wired access, Non-3GPP access such as Wi-Fi Access, 5G Radio Access Network (RAN) access, 4G RAN access, and/or other networks (not shown in FIG. 1A) to facilitate data communications for subscribers (e.g., using User Equipment (UE), such as smart phones, laptops, computers (which may be in a fixed location), and/or other cellular enabled computing devices/equipment, such as CIoT devices, or other network communication enabled devices) including over a Local Data Network (e.g., enterprise network) and a Data Network (e.g., the Internet) to access various applications, web services, content hosts, etc. and/or other networks. Each of the 5G network access mechanisms are in communication with 5G User Plane Functions which pass through Security Platform and 5G User Plane Functions are in communication with 5G User Plane Functions. 4G RAN and 5G RAN are in communication with 5G Core Control/Signaling Functions, which is in communication with 5G User Plane Functions).
As to claim 9, the combination of Verma in view of Andreasen and Beck teaches wherein enterprise data center access is secured from and to 4G, 5G, and/or 6G UE devices (Verma: Claim 5 discloses wherein the security platform monitors wireless interfaces including a plurality of interfaces for a control protocol and user data traffic in a mobile core network for a 4G and/or 5G network. Paragraph 34 discloses next generation firewalls enable enterprises(data centers) and service providers to identify and control applications, users, and content—not just ports, IP addresses, and packets—using various identification technologies. Paragraph 118 further discloses the 5G network can also include Fixed/Wired access, Non-3GPP access such as Wi-Fi Access, 5G Radio Access Network (RAN) access, 4G RAN access, and/or other networks (not shown in FIG. 1A) to facilitate data communications for subscribers (e.g., using User Equipment (UE), such as smart phones, laptops, computers (which may be in a fixed location), and/or other cellular enabled computing devices/equipment, such as CIoT devices, or other network communication enabled devices) including over a Local Data Network (e.g., enterprise network) and a Data Network (e.g., the Internet) to access various applications, web services, content hosts, etc. and/or other networks. Each of the 5G network access mechanisms are in communication with 5G User Plane Functions which pass through Security Platform and 5G User Plane Functions are in communication with 5G User Plane Functions. 4G RAN and 5G RAN are in communication with 5G Core Control/Signaling Functions, which is in communication with 5G User Plane Functions).
As to claim 10, the combination of Verma in view of Andreasen and Beck teaches wherein selection and the enforcement of the security policy is based on the contextual information associated with a UE and the data plane traffic correlated with the UE based on a UE Internet Protocol (IP) address (Verma: Paragraph 29 discloses security devices (e.g., security appliances, security gateways, security services, and/or other security devices) can include various security functions (e.g., firewall, anti-malware, intrusion prevention/detection, proxy, and/or other security functions), networking functions (e.g., routing, Quality of Service (QoS), workload balancing of network related resources, and/or other networking functions), and/or other functions. For example, routing functions can be based on source information (e.g., source IP address and port), destination information (e.g., destination IP address and port), and protocol information. Source information (e.g., source IP address and port), destination information (e.g., destination IP address and port), and protocol information are contextual information associated with a UE and the data plane traffic correlated with the UE based on IP address).
As to claim 11, the combination of Verma in view of Andreasen and Beck teaches wherein the SPN includes a firewall as a service (FWaaS) associated with the SASE cloud network that is configured to perform Uniform Resource Link (URL) filtering for the data plane traffic (Verma: Paragraph 55 discloses enhanced security services for mobile networks (e.g., for converged mobile network operators/service providers) that can be provided using the disclosed techniques include one or more of the following: Network Slice-based URL filtering service and URL Filtering in NGFW could be done per SST in 5G networks. Andreasen: Paragraph 33 discloses network devices may have standing instructions to apply a firewall type function to any data traffic related to the application, then further instructions to forward the data traffic to the SSE for further security functions. Alternatively, the network devices may have standing instructions to simply forward any data traffic related to the application to the SSE for security services. Paragraph 45 reveals traffic is traverses through the distributed SASE fabric).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching firewall security services for mobile network in view of Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP with Andreasen’s teachings of SASE/interconnect receiving the data plane traffic with Andreasen’s teachings of a firewall as a service/function associated with the SASE cloud network because security services available in the network may be leveraged to improve overall latency and reduce cost in network operations (Paragraph 13 of Andreasen).
As to claim 12, the combination of Verma in view of Andreasen and Beck teaches wherein the SPN includes a firewall as a service (FWaaS) associated with the SASE cloud network that is configured to perform application Denial of Service (DoS) detection for the data plane traffic (Verma: Paragraph 55 discloses enhanced security services for mobile networks (e.g., for converged mobile network operators/service providers) that can be provided using the disclosed techniques include Network Slice-based application DoS detection service and Network Slice-based application DoS prevention service. Andreasen: Paragraph 33 discloses network devices may have standing instructions to apply a firewall type function to any data traffic related to the application, then further instructions to forward the data traffic to the SSE for further security functions. Alternatively, the network devices may have standing instructions to simply forward any data traffic related to the application to the SSE for security services. Paragraph 45 reveals traffic is traverses through the distributed SASE fabric).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching firewall security services for mobile network in view of Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP with Andreasen’s teachings of SASE/interconnect receiving the data plane traffic with Andreasen’s teachings of a firewall as a service/function associated with the SASE cloud network because security services available in the network may be leveraged to improve overall latency and reduce cost in network operations (Paragraph 13 of Andreasen).
As to claim 13, the combination of Verma in view of Andreasen and Beck teaches wherein the SPN includes a firewall as a service (FWaaS) associated with the SASE cloud network that is configured to perform threat prevention, advanced threat prevention, and/or advanced Uniform Resource Link (URL) filtering for the SP data plane traffic (Verma: Paragraph 55 discloses enhanced security services for mobile networks (e.g., for converged mobile network operators/service providers) that can be provided using the disclosed techniques include one or more of the following: Network Slice-based URL filtering service and URL Filtering in NGFW could be done per SST in 5G networks). Andreasen: paragraph 33 discloses network devices may have standing instructions to apply a firewall type function to any data traffic related to the application, then further instructions to forward the data traffic to the SSE for further security functions. Alternatively, the network devices may have standing instructions to simply forward any data traffic related to the application to the SSE for security services. Paragraph 45 reveals traffic is traverses through the distributed SASE fabric).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching firewall security services for mobile network in view of Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP with Andreasen’s teachings of SASE/interconnect receiving the data plane traffic with Andreasen’s teachings of a firewall as a service/function associated with the SASE cloud network because security services available in the network may be leveraged to improve overall latency and reduce cost in network operations (Paragraph 13 of Andreasen).
As to claim 14, the combination of Verma in view of Andreasen and Beck teaches wherein each of a plurality of security policies is distinctly selected and enforced for each mobile service provider (MSP) enterprise tenant at the SASE cloud network, wherein per tenant security policy configuration and enforcement are provided by the SASE cloud network (Verma: Paragraph 65 discloses a system/process/computer program product for providing service-based security per Subscription Permanent Identifier (SUPI) in mobile networks includes providing security for mobile subscribers and subscriber's devices and is performed using a security policy that can be applied using a security platform by parsing HTTP/2 messages to extract SUPI information in 5G networks. Paragraph 66 discloses new and enhanced security services for mobile networks (e.g., for converged mobile network operators/service providers) that can be provided using the disclosed techniques include one or more of the following: (1) security policies that can be applied per SUPI information for a SUPI-based firewall service; (2) SUPI-based threat detection service for known threats; (3) SUPI-based advanced threat detection service for unknown threats; (4) SUPI-based basic threat prevention service for known threats; (5) SUPI-based advanced threat prevention service for unknown threats; (6) SUPI-based URL filtering service; (7) SUPI-based application DoS detection service; and (8) SUPI-based application DoS prevention service. Andreasen: Paragraph 33 discloses network devices may have standing instructions to apply a firewall type function to any data traffic related to the application, then further instructions to forward the data traffic to the SSE for further security functions. Alternatively, the network devices may have standing instructions to simply forward any data traffic related to the application to the SSE for security services. Paragraph 45 reveals traffic is traverses through the distributed SASE fabric).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching firewall security services for mobile network in view of Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP with Andreasen’s teachings of SASE/interconnect receiving the data plane traffic with Andreasen’s teachings of a firewall as a service/function associated with the SASE cloud network because security services available in the network may be leveraged to improve overall latency and reduce cost in network operations (Paragraph 13 of Andreasen).
As to claim 15, the combination of Verma in view of Andreasen and Beck teaches wherein the data plane traffic is encapsulated with meta information, including a subscriber identity and/or a unique device identifier (Verma: Paragraph 89 discloses the security platform parse HTTP/2 messages to extract the Subscription Permanent Identifier (SUPI) information in mobile networks. Therefore, the data traffic includes subscription identifier information).
As to claim 16, the combination of Verma in view of Andreasen and Beck teaches wherein the processor is further configured to (Verma: Paragraph 25 discloses the invention is implemented via a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor): determine the security policy to apply at the SASE cloud network to the SP data plane traffic based on a subscriber identity and/or a unique device identifier (Verma: Paragraphs 49-50 disclose providing network slice-based security in mobile networks includes providing threat prevention for a customer with multiple subscribers, mobile subscribers and subscriber's devices is performed using a security policy implemented by a security platform that can be applied per S-NSSAI in 5G networks. Providing network slice-based security in mobile networks includes using a Network Slice Identifier (S-NSSAI) to apply Uniform Resource Locator (URL) filtering for a customer with multiple subscribers, mobile subscribers and subscriber's devices is performed using a security policy implemented by a security platform that can be applied per S-NSSAI in 5G networks. Paragraph 65 discloses providing service-based security per Subscription Permanent Identifier (SUPI) in mobile networks includes providing security for mobile subscribers and subscriber's devices and is performed using a security policy that can be applied using a security platform by parsing HTTP/2 messages to extract SUPI information in 5G networks. Paragraph 74 discloses providing service-based security per Permanent Equipment Identifier (PEI) in mobile networks includes providing security for mobile subscribers and subscriber's devices and is performed using a security policy that can be applied using a security platform by parsing HTTP/2 messages to extract PEI information in 5G networks. Andreasen: Paragraph 33 discloses network devices may have standing instructions to apply a firewall type function to any data traffic related to the application, then further instructions to forward the data traffic to the SSE for further security functions. Alternatively, the network devices may have standing instructions to simply forward any data traffic related to the application to the SSE for security services. Paragraph 45 reveals traffic is traverses through the distributed SASE fabric).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching firewall security services for mobile network in view of Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP with Andreasen’s teachings of SASE/interconnect receiving the data plane traffic with Andreasen’s teachings of a firewall as a service/function associated with the SASE cloud network because security services available in the network may be leveraged to improve overall latency and reduce cost in network operations (Paragraph 13 of Andreasen).
As to claim 17, the combination of Verma in view of Andreasen and Beck teaches wherein the processor is further configured to (Verma: Paragraph 25 discloses the invention is implemented via a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor): receive a message over a network protocol from a mobile core 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 (Verma: Paragraph 190 discloses an interface (I/F) communicator is also provided for security platform manager communications (e.g., via (REST) APIs, messages, or network protocol communications or other communication mechanisms). In some cases, network communications of other network elements on the service provider network are monitored using network device and data plane supports decoding of such communications. I/F communicator can be used to implement the disclosed techniques for security policy enforcement on mobile/service provider network environments as described. Andreasen: paragraph reveals traffic is traverses through the distributed SASE fabric).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching firewall security services for mobile network in view of Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP with Andreasen’s teachings of SASE/interconnect receiving the data plane traffic with Andreasen’s teachings of a firewall as a service/function associated with the SASE cloud network because security services available in the network may be leveraged to improve overall latency and reduce cost in network operations (Paragraph 13 of Andreasen).
As to claim 18, the combination of Verma in view of Andreasen and Beck teaches wherein the processor is further configured to (Verma: Paragraph 25 discloses the invention is implemented via a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor): receive an accounting message from a mobile core network at the SASE cloud network, wherein contextual information associated with the accounting message is communicated using a DIAMETER protocol, a Radius protocol, and/or via an Application Programming Interface (API) (Verma: Paragraph 190 discloses an interface (I/F) communicator is also provided for security platform manager communications (e.g., via (REST) APIs, messages (which may include accounting message), or network protocol communications or other communication mechanisms). In some cases, network communications of other network elements on the service provider network are monitored using network device and data plane supports decoding of such communications. I/F communicator can be used to implement the disclosed techniques for security policy enforcement on mobile/service provider network environments as described. Andreasen: paragraph reveals traffic is traverses through the distributed SASE fabric).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching firewall security services for mobile network in view of Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP with Andreasen’s teachings of SASE/interconnect receiving the data plane traffic with Andreasen’s teachings of a firewall as a service/function associated with the SASE cloud network because security services available in the network may be leveraged to improve overall latency and reduce cost in network operations (Paragraph 13 of Andreasen).
As to claim 19, Verma teaches receiving ingress Service Provider (SP) data plane traffic for a tenant from an SP backbone (Paragraph 189 discloses network processor monitor/receives packets from mobile device and provide the packet to data plane for processing (Note: for mobile networks, data plane traffic refers to user data that flows between mobile device and the service provider’s network). The packets/traffic are identified as being part of a new session and a new session flow is created. Paragraph 194 discloses monitoring received network traffic on a service provider backbone/network at a security platform (see also paragraphs 199, 204, and 209). The security platform monitors GTP-U and HTTP/2 traffic on the mobile core network. Paragraph 54 reveals the techniques allow operators to provide network sliced based security to/for any customer/tenants);
extracting contextual information associated with the SP data plane traffic to determine io a security policy to apply to the SP data plane traffic (Paragraphs 195-196 disclose extracting contextual information such as network slice information for user traffic associated with the new session at the security platform of the service provider network. The security platform can parse HTTP/2 messages to extract the network slice information, in which the network slice is identified by Single Network Slice Selection Assistance Information (S-NSSAI), using DPI-based firewall techniques. Paragraph 196 discloses determining a security policy to apply to the security platform to the new session based on the network sliced information. See also paragraphs 200-201, 205-206, and 210-211);
enforcing the security policy on the SP data plane traffic to provide secured SP data plane traffic using a Security Processing Node (SPN) (Paragraph 197 discloses enforcing the security policy on the new session using the security platform such as various enforcement actions (e.g., allow/pass, block/drop, alert, tag, monitor, log, throttle, restrict access, and/or other enforcement actions). Action such as restrict access provides secure data plan traffic using the security processing node/security platform. Recall, paragraph 189 which discloses the packets/traffic are identified as being part of a new session. Paragraph 178 discloses techniques for providing enhanced security for 5G mobile/service provider networks using a security platform for security policy enforcement and paragraph 179 discloses using a security platform for security policy enforcement (e.g., using inspection and security capabilities. Paragraph 189 discloses policy enforcement (e.g., policies can include one or more rules, which can be specified using domain and/or host/server names, and rules can apply one or more signatures or other matching criteria or heuristics, such as for security policy enforcement for subscriber/IP flows on service provider networks based on various extracted parameters/information from monitored HTTP/2 messages and/or DPI of monitored GTP-U traffic as disclosed herein) is applied as described herein with respect to various embodiments based on the monitored, decrypted, identified, and decoded session traffic flows); and
egressing the secured SP data plane traffic (Paragraph 197 discloses enforcing the security policy on the new session using the security platform such as various enforcement actions (e.g., allow/pass, block/drop, alert, tag, monitor, log, throttle, restrict access, and/or other enforcement actions). Therefore, passing/allowing/ restricting access to the traffic involves egress the secured SP data traffic); and
Verma does not teach receiving ingress data plane traffic from an SP backbone to a Secure Access Service Edge (SASE) cloud network for security processing via an Interconnect that is configured for a compute region and an IP block and an Autonomous System Number (ASN) to advertise the IP block in Border Gateway Protocol (BGP); egressing the secured SP data plane traffic back to the SP backbone or to an external network.
Andreasen teaches receiving ingress data plane traffic from an SP backbone to a Secure Access Service Edge (SASE) cloud network for security processing via an Interconnect (Paragraph 58 discloses receiving at a network device, a packet sent from a user device. Paragraph 57 reveals the user device is associated with a network, thus is part of SP backbone/network). (Note: for mobile networks, data plane traffic refers to user data that flows between mobile device and the service provider’s network). Paragraph 22 reveals network devices may be considered part of a software defined wide area network SD-WAN (service provider network/interconnect). SD-WAN may present a virtual network through which a data traffic flow may pass from a user device at a particular branch, through one or more network devices to a particular data center. Paragraph 45 reveals traffic is traverses through the distributed SASE fabric and paragraph 46 reveals once packet leaves the SD-WAN (leaves the distributed SASE fabric, the exit SD-WAN router (e.g., network device ) can check the Security Service Header (e.g., header ) to verify that all required security functions have in fact been performed); enforce a security policy (Paragraphs 60-61 reveal performing security function/policy on the packet/data plan traffic) and egressing the secured SP data plane traffic back to the SP backbone or to an external network (Paragraph 63 discloses forwarding the packet to the destination. Paragraph 24 reveals the intended destination for the data traffic packet may be a data center. Paragraph 59 reveals the destination of the packet may involve passing the packet out of the SD-WAN of an organization (thus passing to an external network). See also paragraph 46 and 51).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching of receiving ingress service provider data plane traffic for a tenant from an SP back with Andreasen’s teachings of SASE receiving the data plane traffic to perform security policy-based routing between a network and the cloud, thereby improving performance of the network (Paragraph 1 of Andreasen).
The combination of Verma in view of Andreasen does not teach, but Beck teaches an Interconnect that is configured for a compute region and an IP block and an Autonomous System Number (ASN) to advertise the IP block in Border Gateway Protocol (BGP) (Paragraph 24 reveals a router (interconnect) may be any computing device that may be configured to forward data, such as Internet Protocol (IP) packets, from one computing device to another computing device. Paragraph 25 discloses an Autonomous Systems (AS), such as an Internet Service Provider (ISP), that is assigned a range(compute region) of Internet Protocol (IP) addresses/IP block, i.e., a netblock, may advertise or announce that the netblock is reachable by announcing a route to the AS with a route prefix for the netblock in a BGP update. A route prefix may indicate a netblock's IP address prefix and a length of the IP address prefix as a number of bits. Paragraph 26 discloses the number of ASs through which a packet must travel along a path to reach the AS the packet is addressed to may be that path's path length. The path length may refer to a number of hops through which the packet may travel to reach the AS to which the packet is addressed, with each hop representing a unique AS number (ASN) the packet is routed through along the path. BGP path lengths may be determined in BGP by counting the number of unique ASNs in a BGP update advertising a path. As BGP messages that advertise paths are received by routers, the paths and their attributes may be stored in routing tables for use in routing packets along those paths).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching of receiving ingress service provider data plane traffic for a tenant from an SP back in view of Andreasen’s teachings of SASE/interconnect receiving the data plane traffic with Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP to provide transparency as to the local security measures implemented along an AS path while enabling routing along secure paths and reducing the impact of BGP attacks (Paragraph 2 of Beck).
As to claim 20, Verma teaches a computer program product, the computer program product being embodied in a tangible computer readable storage medium (Paragraph 25 discloses the invention is implemented via a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor) and comprising computer instructions for (Paragraph 25):
receiving ingress Service Provider (SP) data plane traffic for a tenant from an SP backbone (Paragraph 189 discloses network processor monitor/receives packets from mobile device and provide the packet to data plane for processing (Note: for mobile networks, data plane traffic refers to user data that flows between mobile device and the service provider’s network). The packets/traffic are identified as being part of a new session and a new session flow is created. Paragraph 194 discloses monitoring received network traffic on a service provider backbone/network at a security platform (see also paragraphs 199, 204, and 209). The security platform monitors GTP-U and HTTP/2 traffic on the mobile core network. Paragraph 54 reveals the techniques allow operators to provide network sliced based security to/for any customer/tenants);
extracting contextual information associated with the SP data plane traffic to determine io a security policy to apply to the SP data plane traffic (Paragraphs 195-196 disclose extracting contextual information such as network slice information for user traffic associated with the new session at the security platform of the service provider network. The security platform can parse HTTP/2 messages to extract the network slice information, in which the network slice is identified by Single Network Slice Selection Assistance Information (S-NSSAI), using DPI-based firewall techniques. Paragraph 196 discloses determining a security policy to apply to the security platform to the new session based on the network sliced information. See also paragraphs 200-201, 205-206, and 210-211);
enforcing the security policy on the SP data plane traffic to provide secured SP data plane traffic using a Security Processing Node (SPN) (Paragraph 197 discloses enforcing the security policy on the new session using the security platform such as various enforcement actions (e.g., allow/pass, block/drop, alert, tag, monitor, log, throttle, restrict access, and/or other enforcement actions). Action such as restrict access provides secure data plan traffic using the security processing node/security platform. Recall, paragraph 189 which discloses the packets/traffic are identified as being part of a new session. Paragraph 178 discloses techniques for providing enhanced security for 5G mobile/service provider networks using a security platform for security policy enforcement and paragraph 179 discloses using a security platform for security policy enforcement (e.g., using inspection and security capabilities. Paragraph 189 discloses policy enforcement (e.g., policies can include one or more rules, which can be specified using domain and/or host/server names, and rules can apply one or more signatures or other matching criteria or heuristics, such as for security policy enforcement for subscriber/IP flows on service provider networks based on various extracted parameters/information from monitored HTTP/2 messages and/or DPI of monitored GTP-U traffic as disclosed herein) is applied as described herein with respect to various embodiments based on the monitored, decrypted, identified, and decoded session traffic flows); and
egressing the secured SP data plane traffic (Paragraph 197 discloses enforcing the security policy on the new session using the security platform such as various enforcement actions (e.g., allow/pass, block/drop, alert, tag, monitor, log, throttle, restrict access, and/or other enforcement actions). Therefore, passing/allowing/ restricting access to the traffic involves egress the secured SP data traffic); and
Verma does not teach receiving ingress data plane traffic from an SP backbone to a Secure Access Service Edge (SASE) cloud network for security processing via an Interconnect that is configured for a compute region and an IP block and an Autonomous System Number (ASN) to advertise the IP block in Border Gateway Protocol (BGP); egressing the secured SP data plane traffic back to the SP backbone or to an external network.
Andreasen teaches receiving ingress data plane traffic from an SP backbone to a Secure Access Service Edge (SASE) cloud network for security processing via an Interconnect (Paragraph 58 discloses receiving at a network device, a packet sent from a user device. Paragraph 57 reveals the user device is associated with a network, thus is part of SP backbone/network). (Note: for mobile networks, data plane traffic refers to user data that flows between mobile device and the service provider’s network). Paragraph 22 reveals network devices may be considered part of a software defined wide area network SD-WAN (service provider network/interconnect). SD-WAN may present a virtual network through which a data traffic flow may pass from a user device at a particular branch, through one or more network devices to a particular data center. Paragraph 45 reveals traffic is traverses through the distributed SASE fabric and paragraph 46 reveals once packet leaves the SD-WAN (leaves the distributed SASE fabric, the exit SD-WAN router (e.g., network device ) can check the Security Service Header (e.g., header ) to verify that all required security functions have in fact been performed); enforce a security policy (Paragraphs 60-61 reveal performing security function/policy on the packet/data plan traffic) and egressing the secured SP data plane traffic back to the SP backbone or to an external network (Paragraph 63 discloses forwarding the packet to the destination. Paragraph 24 reveals the intended destination for the data traffic packet may be a data center. Paragraph 59 reveals the destination of the packet may involve passing the packet out of the SD-WAN of an organization (thus passing to an external network). See also paragraph 46 and 51).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching of receiving ingress service provider data plane traffic for a tenant from an SP back with Andreasen’s teachings of SASE receiving the data plane traffic to perform security policy-based routing between a network and the cloud, thereby improving performance of the network (Paragraph 1 of Andreasen).
The combination of Verma in view of Andreasen does not teach, but Beck teaches an Interconnect that is configured for a compute region and an IP block and an Autonomous System Number (ASN) to advertise the IP block in Border Gateway Protocol (BGP) (Paragraph 24 reveals a router (interconnect) may be any computing device that may be configured to forward data, such as Internet Protocol (IP) packets, from one computing device to another computing device. Paragraph 25 discloses an Autonomous Systems (AS), such as an Internet Service Provider (ISP), that is assigned a range(compute region) of Internet Protocol (IP) addresses/IP block, i.e., a netblock, may advertise or announce that the netblock is reachable by announcing a route to the AS with a route prefix for the netblock in a BGP update. A route prefix may indicate a netblock's IP address prefix and a length of the IP address prefix as a number of bits. Paragraph 26 discloses the number of ASs through which a packet must travel along a path to reach the AS the packet is addressed to may be that path's path length. The path length may refer to a number of hops through which the packet may travel to reach the AS to which the packet is addressed, with each hop representing a unique AS number (ASN) the packet is routed through along the path. BGP path lengths may be determined in BGP by counting the number of unique ASNs in a BGP update advertising a path. As BGP messages that advertise paths are received by routers, the paths and their attributes may be stored in routing tables for use in routing packets along those paths).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching of receiving ingress service provider data plane traffic for a tenant from an SP back in view of Andreasen’s teachings of SASE/interconnect receiving the data plane traffic with Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP to provide transparency as to the local security measures implemented along an AS path while enabling routing along secure paths and reducing the impact of BGP attacks (Paragraph 2 of Beck).
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Verma et al US 20200128399 (hereinafter Verma), in view of Andreasen et al US 20250274489 (hereinafter Andreasen), in further view of Beck US 20190372886 (hereinafter Beck), and in further view of Yadav et al US 20230100395 (hereinafter Yadav).
As to claim 2, the combination of Verma in view of Andreasen and Beck teaches all the limitations presented in claim 1 above. The combination of Verma in view of Andreasen and Beck does not teach, but Yadav teaches wherein SP data plane traffic includes IPsec and non-IPsec traffic that is processed and secured using the SPN in the SASE cloud network (Yadav: Paragraph 13 discloses the SASE APN carriers traffic for multiple different tenants from the MNO to the SASE gateway in at least one of a GRE tunnel (non-IPsec), an IPsec tunnel, and a Software Defined-WAN (SD-WAN). See also paragraph 50).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Verma’s teaching of receiving ingress service provider data plane traffic for a tenant from an SP back in view of Andreasen’s teachings of SASE/interconnect receiving the data plane traffic and Beck’s teachings of the interconnect configured for a compute region and an IP block and an ASN to advertise the IP block in BGP with Yadav’s teachings of SP data plane traffic to provide improve control of access to wireless networks that can be used as a proxy of trust for gaining access to network resources that are secured by a SASE (Paragraph 45 of Yadav).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Rolando et al US 20230026865 (hereinafter Rolando).
Rolando teaches receive ingress data plane traffic (Paragraph 48 discloses the cloud gateway receives a packet from a tenant segment); determine a security policy to apply to the data plane traffic (Paragraph 52 discloses an orchestrator identifies a first set of security policies for the first segment); enforce the security policy on the data plane traffic (Paragraph 53 discloses the orchestrator then configures a managed service node to implement a first set of T1-SRs (tenant-level service routers) to apply the first set of policies on packet traffic from the first tenant segment) as disclosed in claims 1, and 19-20.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FELICIA FARROW whose telephone number is (571)272-1856. The examiner can normally be reached M - F 7:30am-4:00pm (EST).
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 at (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.
/F.F/ Examiner, Art Unit 2437
/BENJAMIN E LANIER/ Primary Examiner, Art Unit 2437
Prosecution Insights