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 .
This office action is in response to remarks filed 12/23/2025.
Claims 1-20 are pending and presented for examination. Claims 1 and 13 are amended. Claim 21 has been cancelled. No claims have been added.
Response to Amendment
35 U.S.C. § 101 rejection for claims 1-12 and 21 are withdrawn.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1 is rejected under 35 U.S.C. 103 as being unpatentable over Sarva et al. (US 20200204492 A1, hereinafter “Sarva”), in view of Michael et al. (US 20220006726 A1, hereinafter, “Michael”).
RE Claim 1: Sarva discloses:
A system, comprising:
a controller deployed within a cloud computing platform and maintained within a non- transitory storage medium (Fig. 1 #24, Fig. 3 #324, #325, #326; ¶12 system comprises a network controller for a virtualized computing infrastructure, wherein the network controller is configured to receive a request for a service chain);a plurality of nodes operating as a Kubernetes cluster (Fig. 1 #10, #16; ¶26 Servers 12, 16 are computing devices and may also be referred to herein as “hosts” or “host devices,” compute nodes, or computing devices. Data center 10 may host many hundreds or even thousands or servers interconnected via the switch fabric) (¶54 VM orchestration permits VM coordination and refers to the deployment, management, scaling, and configuration, e.g., of containers to host servers by a container orchestration platform. Example instances of orchestration platforms include Kubernetes, Docker swarm, Mesos/Marathon, OpenShift, OpenStack, VMware, and Amazon ECS.; ¶55 For example, the Kubernetes platform uses the terms “cluster master” and “minion nodes,”),
the plurality of nodes including:
a master node including one or more logical devices and communicatively coupled to the controller, (Fig. 1, #23, #24; ¶55 Virtual execution elements may be deployed to a virtualization environment using a cluster-based framework in which a cluster master node of a cluster manages the deployment and operation of containers to one or more cluster minion nodes of the cluster;) (Fig. 1, #23, #24; ¶56 Orchestrator 23 and network controller 24 together implement an overall controller for the computing infrastructure 8)
and an ingress node including one or more logical devices to execute applications, (Fig. 1, #14; ¶65 Packet flow 31A and reverse packet flow 31B are received by gateway 14 for ingress into data center 10) (¶8 The one or more VNF instances for a single service may be hosted by separate computing devices, e.g., compute nodes or servers.)
Sarva does not explicitly disclose:
the ingress node comprising at least one container operating as an ingress gateway, the ingress gateway comprising a classification identifier assignment logic that operates in combination with an attributes-to-network policy data store, a gateway properties data store, and a network policy-to-ClassID data store,
wherein the classification identifier assignment logic is configured to i) determine a network policy applicable to a received data flow based upon accessing static attributes from the gateway properties data store and dynamic attributes from the content of the data flow, and ii) access the Network Policy-to-ClassID data store to determine the classification identifier associated with the data flow.
However, Michael discloses:
the ingress node comprising at least one container operating as an ingress gateway (Orca configured as a gateway controller and Dolfin configured as routing controller. ¶0157; Tenant traffic routing functionality comprises an Orca and Dolfin pair for ingress gateway functions. ¶¶0162-0163, Fig. 5; Multiple components corresponding to each tenant are deployed at each POP, including Dolfins, Orcas, and Watchdogs. Each component is deployed in a container (e.g., Docker container). ¶0233; While Orca is configured to control ingress/egress of traffic into/from the core network, Dolfin controls traffic routing and flow through the core network such that when each Dolfin receives data traffic, it controls the routing of the traffic via the underlay network to another Dolfin in the core network. ¶0241), the ingress gateway comprising a classification identifier assignment logic that operates in combination with an attributes-to-network policy data store (Incoming traffic from a tenant is received at the Orca, and then classified by the corresponding Dolfin. ¶0157; The Dolfin traffic class subsystem is configured to determine the traffic class of received traffic, and to generate the OVS tables and flow rules to ensure that the different flows are routed as specified by their corresponding traffic class. ¶0308; Dolfins are configured to provide multiple policy-based routing algorithms for use in routing data. For example, a particular user can specify policy-based routing based on latency, so that routes having the lowest latency are used to route the corresponding data. ¶0337; WEB-APP ingests control plane metrics and saves to the data store and pushes the metrics out to the live connections. ¶0190; Upon receipt by the Dolfin of the link metrics data and, additionally receipt of link state information from other Dolfins in the MCN, the routing engine is configured to determine “best paths” for routing data based on policy or objective functions. ¶0173), a gateway properties data store (Traffic routing to find least-cost paths in network such as jitter, throughput, and utilization. ¶0338; Link metrics to determine best link such as jitter, dynamic, or maximum traffic capacity, static. ¶¶0340-0341; WEB-APP ingests control plane metrics and saves to the data store and pushes the metrics out to the live connections. ¶0190; Upon receipt by the Dolfin of the link metrics data and, additionally receipt of link state information from other Dolfins in the MCN, the routing engine is configured to determine “best paths” for routing data based on policy or objective functions. ¶0173), and a network policy-to-ClassID data store (Dolfins are configured to provide multiple policy-based routing algorithms for use in routing data. For example, a particular user can specify policy-based routing based on latency, so that routes having the lowest latency are used to route the corresponding data. ¶0337; WEB-APP ingests control plane metrics and saves to the data store and pushes the metrics out to the live connections. ¶0190; Upon receipt by the Dolfin of the link metrics data and, additionally receipt of link state information from other Dolfins in the MCN, the routing engine is configured to determine “best paths” for routing data based on policy or objective functions. ¶0173),
wherein the classification identifier assignment logic (Incoming traffic from a tenant is received at the Orca, and then classified by the corresponding Dolfin. ¶0157; The Dolfin traffic class subsystem is configured to determine the traffic class of received traffic, and to generate the OVS tables and flow rules to ensure that the different flows are routed as specified by their corresponding traffic class. ¶0308;) is configured to i) determine a network policy applicable to a received data flow based upon accessing static attributes from the gateway properties data store and dynamic attributes from the content of the data flow (Traffic routing to find least-cost paths in network such as jitter, throughput, and utilization. ¶0338; Link metrics to determine best link such as jitter, dynamic, or maximum traffic capacity, static. ¶¶0340-0341; WEB-APP ingests control plane metrics and saves to the data store and pushes the metrics out to the live connections. ¶0190; Upon receipt by the Dolfin of the link metrics data and, additionally receipt of link state information from other Dolfins in the MCN, the routing engine is configured to determine “best paths” for routing data based on policy or objective functions. ¶0173), and ii) access the Network Policy-to-ClassID data store to determine the classification identifier associated with the data flow (Incoming traffic from a tenant is received at the Orca, and then classified by the corresponding Dolfin. ¶0157; The Dolfin traffic class subsystem is configured to determine the traffic class of received traffic, and to generate the OVS tables and flow rules to ensure that the different flows are routed as specified by their corresponding traffic class. ¶0308; Dolfins are configured to provide multiple policy-based routing algorithms for use in routing data. For example, a particular user can specify policy-based routing based on latency, so that routes having the lowest latency are used to route the corresponding data. ¶0337; WEB-APP ingests control plane metrics and saves to the data store and pushes the metrics out to the live connections. ¶0190; Upon receipt by the Dolfin of the link metrics data and, additionally receipt of link state information from other Dolfins in the MCN, the routing engine is configured to determine “best paths” for routing data based on policy or objective functions. ¶0173).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Sarva with the teachings of Michael. Sarva discloses a Kubernetes cluster with multiple nodes in a network node. Michael discloses an ingress node in a container environment that identifies traffic flows and assigns routing based on classification and policy.
The combination would enable identifying and classifying packets in a Kubernetes cloud network and applying routing decisions based on traffic classification and policies for efficient data flows, i.e. the combining prior art elements according to known methods to yield predictable results. (Sarva: Fig. 1, #10, #16, ¶0026, 0032, 0054, 0055; Michael: Abstract: ¶¶0017, 0141-0146, 0548-0549, Fig. 5).
Claims 2-8, and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Sarva, in view of Michael, in view of Sharma et al. (US 20100165985 A1, hereinafter, “Sharma”).
RE Claim 2: Sarva discloses:
The system, wherein the master node (Fig. 1, #23, #24; ¶55 Virtual execution elements may be deployed to a virtualization environment using a cluster-based framework in which a cluster master node of a cluster manages the deployment and operation of containers to one or more cluster minion nodes of the cluster;) includes (a) controller logic configured to establish a communication coupling with the controller (Fig. 1 #24, Fig. 3 #324, #325, #326; ¶12 system comprises a network controller for a virtualized computing infrastructure, wherein the network controller is configured to receive a request for a service chain) and (b) an Application Programming Interface (API) (Fig. 1, #24; Fig. 3, #320; ¶59 Network controller 24 may include an application programming interface (API) ) server that exposes a Representational State Transfer (RESTful) API interface (Fig. 3, #320; ¶108 API server 320 may implement a Representational State Transfer (REST) interface to process REST operations) to the ingress node (Fig. 1, #24, #27, #14; ¶70 Network controller 24 also sends configuration messages 27 to gateway 14 to program the first virtual network address as a next hop address for packet flows mapped to service chain 34, e.g., forward packet flow 31A, and to program the second virtual network address as a next hop for packet flows mapped to service chain 34 in the reverse direction).
RE Claim 3: Sarva discloses:
The system, wherein the controller logic is configured to access local storage (Fig. 1, #10, #16, #12; ¶26 data center 10 includes storage and/or compute servers 12 and servers 16A-16M (“servers 16”) interconnected via a switch fabric) of the controller that includes a mapping between network addresses and attributes corresponding to each of the network addresses. (¶0032 A single flow of packets may be identified by the 5-tuple: <source network address, destination network address, source port, destination port, protocol>; Fig. 1, #24, #27, #14, #31, #34; ¶70 Network controller 24 also sends configuration messages 27 to gateway 14 to program the first virtual network address as a next hop address for packet flows mapped to service chain 34, e.g., forward packet flow 31A, and to program the second virtual network address as a next hop for packet flows)
RE Claim 4: Sarva discloses:
The system, wherein the network address is an Internet Protocol (IP) address. (Fig.2 #106A, #120; ¶86 In one example, virtual routers implement each virtual network using an overlay network, which provides the capability to decouple an endpoint's virtual address from a physical address (e.g., IP address) of the server on which the endpoint is executing.)
RE Claim 5: Sarva discloses:
The system, wherein the ingress node is configured to determine the one or more network policies applicable to the data flow based on the first attribute obtained from the controller via the master node and one or more attributes obtained from the data flow. (¶0032 A single flow of packets may be identified by the 5-tuple: <source network address, destination network address, source port, destination port, protocol>, for example; ¶0031 Gateway 14 operating as an anchor steers packet flows entering data center 10, via one or communication links with gateway 14, to the appropriate service chain based on, e.g., a route, and/or a policy for a subscriber and/or application; Fig. 1, #24, #27, #14; ¶70 Network controller 24 also sends configuration messages 27 to gateway 14 to program the first virtual network address as a next hop address for packet flows mapped to service chain 34, e.g., forward packet flow 31A, and to program the second virtual network address as a next hop for packet flows mapped to service chain 34 in the reverse direction; ¶0094 Virtual router agent 104 exchanges control information with a network controller, such as network controller 24 of FIG. 1. Control information may include, virtual network routes, low-level configuration state such as routing instances and forwarding policy for installation to configuration data 134, VRFs 136, and policies 138. Virtual router agent 104 may also report analytics state, install forwarding state to FIBs 124 of virtual router forwarding plane 128, discover VMs 110 and attributes thereof.)
RE Claim 6: Sarva does not disclose:
The system, wherein the ingress node of the plurality of nodes is configured to encapsulate the classification identifier into one or more messages including content from the data flow.
However, Sharma discloses:
The system, wherein the ingress node of the plurality of nodes is configured to encapsulate the classification identifier into one or more messages including content from the data flow. (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets; ¶0018 In Redirection, each SIA physical device, at the data plane level, may redirect the tagged packets to the next-hop physical device in the service path. The redirection may be done using the available transport mechanisms of the underlying network. SIA does not assume a particular redirection transport mechanism. For example, the transport mechanism could be a generic routing encapsulation ("GRE") tunnel in an internet protocol ("IP") network,)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sarva with the teachings of Sharma. Sarva does not disclose a classification identifier encapsulated into messages. Sharma discloses classifying traffic and placing the classification into a shared context and tagging the packet. The combined packet is then encapsulated into messages, i.e. the combining prior art elements according to known methods to yield predictable results. (Sarva: ¶0051; Sharma: Fig. 1, 6; ¶0002, 0017, 0018).
RE Claim 7: Sarva discloses:
The system, wherein the one or more public cloud networks include a first public cloud network and a second public cloud network. (Fig. 1, #15, #11, #7, #14; Fig. 4, #320A, #320B; ¶0022 Data center 10 may, for example, host infrastructure equipment, such as networking and storage systems, redundant power supplies, and environmental controls. Service provider network 7 is coupled to public network 15, which may represent one or more networks administered by other providers, and may thus form part of a large-scale public network infrastructure, e.g., the Internet. Public network 15 may represent, for instance, a local area network (LAN), a wide area network (WAN), the Internet, a virtual LAN (VLAN), an enterprise LAN, a layer 3 virtual private network (VPN), an Internet Protocol (IP) intranet operated by the service provider that operates service provider network 7, an enterprise IP network, or some combination thereof; ¶125 Service instances 310, 312 are configured with corresponding virtual network interfaces for virtual networks connecting gateway 14 to the corresponding routing instances configured on server 16A. All forwarding by servers 16, 12 is performed by virtual routers 21; ¶126 Gateway 14 receives forwarding packet flow 320, Gateway 14 forwards packet flow 320A to server 16A hosting service instance 310 for the ingress of service chain 330 and the virtual network interface, The virtual router 21 for server 16A forwards the packet flow 320A to gateway 14 to exit the virtualized computing infrastructure.)
RE Claim 11: Sarva discloses:
The system, wherein a first message of the one or more messages includes an Internet Protocol (IP) packet (Fig.2 #106A, #120; ¶86 In one example, virtual routers implement each virtual network using an overlay network, which provides the capability to decouple an endpoint's virtual address from a physical address (e.g., IP address) of the server on which the endpoint is executing.)
Sarva does not explicitly disclose:
and a Generic Routing Encapsulation (GRE) header including a field to contain the classification identifier
However, Sharma discloses:
a Generic Routing Encapsulation (GRE) header including a field to contain the classification identifier (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets; ¶0018 In Redirection, each SIA physical device, at the data plane level, may redirect the tagged packets to the next-hop physical device in the service path. The redirection may be done using the available transport mechanisms of the underlying network. SIA does not assume a particular redirection transport mechanism. For example, the transport mechanism could be a generic routing encapsulation ("GRE") tunnel in an internet protocol ("IP") network,)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Sarva with the teachings of Sharma. Sarva discloses messages that include IP packets. Sharma discloses classifying traffic and placing the classification into a shared context and tagging the packet. The combined IP packet is then encapsulated per GRE for tunneling, i.e. the combining prior art elements according to known methods to yield predictable results. (Sarva: Fig. 2 #106A, #120; ¶0086; Sharma: Fig. 1, 6; ¶0002, 0017, 0018).
RE Claim 8: Sarva does not explicitly disclose:
The system, wherein the classification identifier being used in management of data flows
However, Sharma discloses:
The system, wherein the classification identifier being used in management of data flows (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification. After service application, it derives the next hop in the service path associated with the shared context in the packet and then sends the traffic to the next service node.; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets;
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sarva with the teachings of Sharma. Sarva does not disclose a classification identifier for management of data flows. Sharma discloses classifying traffic and placing the classification into a shared context and tagging the packet for management of data flows. The combination would associate a classification identifier with mapping to transfer packets to appropriate destinations, i.e. the combining prior art elements according to known methods to yield predictable results. (Sarva: Abstract, ¶0002; Sharma: Fig. 1, 6; ¶0002, 0017, 0018).
Sarva and Sharma do not explicitly disclose:
Wherein the management of data flow is between virtual private cloud networks deployed in one or more public cloud networks
However, Michael discloses:
Wherein the management of data flow is between virtual private cloud networks deployed in one or more public cloud networks (Fig. 2B, 3, 4, 40, 68; ¶0143 Embodiments of the MCN described herein include systems and methods for global control and optimization of data traffic through or in networks including software-defined networks. The MCN comprises numerous nodes placed in data centers across the world and interconnected using private leased lines to form an overlay network that overlays another network (e.g., public network, private network in the form of private leased lines, etc.), referred to herein as an “underlay network”., ¶0159 block diagram of an example multi-cloud configuration including components of the MCN (Mode Core Network overlay), under an embodiment. While the MCN of this example embodiment includes components distributed among multiple independent cloud environments, embodiments are not so limited.; ¶0443 The MCN includes a logical division of workspaces or “environments” each operating its own MCN; The environments are maintained in logically separate or isolated regions of a cloud service of the web services cloud in a given geographical region (e.g., Europe North 1, US West 3, etc.), and but are not so limited. ¶0495 Components of the MCN are configured to track the public IP addresses allocated to the MCN by a cloud service provider (e.g., Azure, Ericsson, etc.), and to map the IP addresses to specific routes.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Michael into the teachings of Sarva and Sharma. Sarva and Sharma does not disclose virtual private and public clouds. Michael discloses a multi-cloud independent environments and connections to public IP addresses. The combination results in the packets classified for transfer across private and public cloud networks, i.e. the combining prior art elements according to known methods to yield predictable results. (Sarva: Abstract, ¶0002; Sharma: Fig. 1, 6; ¶0002, 0017, 0018; Michael: Abstract, Fig. 2B, 3, 4, 40, 68).
RE Claim 12: Sarva discloses:
The system, wherein a first message of the one or more messages includes an Internet Protocol (IP) packet, (Fig.2 #106A, #120; ¶86 In one example, virtual routers implement each virtual network using an overlay network, which provides the capability to decouple an endpoint's virtual address from a physical address (e.g., IP address) of the server on which the endpoint is executing.),
Sarva and Sharma do not explicitly disclose:
a Virtual Extensible Local Area Network (VXLAN) header and the classification identifier
However, Michael discloses:
a Virtual Extensible Local Area Network (VXLAN) header and the classification identifier (¶0155 the MCN is configured as a multi-tenant network and therefore includes multiple independent tunnels (e.g., Virtual Extensible Local Area Network (VXLAN)) to separate the traffic between different entities.; ¶0322 The routing process for incoming traffic involves Dolfin determining a class of the traffic using one of user-defined classification parameters, Differentiated Services Code Point (DSCP)-based parameters, or automatic classification. When a tenant has opted to provide traffic classification parameters, Dolfin is configured to identify traffic classes by applying the user-defined traffic classification parameters. The user-defined parameters include, for example, IP range (e.g., source IP, destination IP), port range, and protocol identifying information, but are not so limited. ¶0332 Traffic classification using the differentiated services (DSCP) field mapping comprises use of the 6-bit value present in the corresponding packet IP header. Embodiments include a default mapping from DSCP values to traffic classes and, optionally, include a reconfigurable mapping (front-end). ¶0334 Default traffic classification is used when a match is not found for a packet in any configured mapping. The default traffic classification comprises routing the flow through the Best Effort class, but is not so limited.)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings Sarva with the teachings of Michael. Sarva discloses an IP packet for message format. Michael discloses a classification identifier and VxLAN to provide tunneling of packets. The combination of an IP packet with a classification identifier encapsulated with VXLAN for tunneling of packets across a network, i.e. the combining of prior art elements according to known methods to yield predictable results. (Sarva: Fig 2, ¶86; Michael: ¶155, 322, 332)
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Sarva, in view of Michael in view of Sharma, and further in view of Hampel et al. (US 20140153572 A1, hereinafter, “Hampel”).
RE Claim 9: Sarva discloses:
The system, wherein a first message of the one or more messages includes an Internet Protocol (IP) packet (Fig.2 #106A, #120; ¶86 In one example, virtual routers implement each virtual network using an overlay network, which provides the capability to decouple an endpoint's virtual address from a physical address (e.g., IP address) of the server on which the endpoint is executing.)
Sarva does not explicitly disclose:
wherein a first message of the one more messages includes a tunneling header including an Encapsulating Security Protocol (ESP) header
However, Hample discloses:
wherein a first message of the one more messages includes a tunneling header including an Encapsulating Security Protocol (ESP) header (¶20 In at least some embodiments, an overlay network is a type of network that utilizes tunneling in order to support enhanced features which may not be able to be provided (or easily provided) by the underlying network infrastructure on which the overlay network is provided. For example, an overlay network may be used to support service differentiation (e.g., different quality-of-service handling of different traffic flows or different types of traffic flows, application of different policy or charging functions for different traffic flows or different types of traffic flows, or the like, as well as various combinations thereof); Fig. 1, #160; Fig. 4, #450; ¶45 The FE 160 may be configured to apply the one or more tunneling actions to the packet of the data flow based on processing of the one or more tunneling actions identified from the data flow record associated with the data flow.; ¶51 For example, a UDP-based encapsulation action that is communicated from the CE 150 to the FE 160 may include information indicative that UDP-based encapsulation is to be performed and one or more UDP header field values (e.g., one or more of a length value, a source port number, a destination port number, or other UDP header fields) to be used in the UDP header that is added to the packet of the data flow.; ¶122 The security gateway FE 360.sub.2 identifies IP packets of the data flow, encapsulates the IP packets using UDP to form UDP packets (UDP tunnel), further encapsulates the UDP packets using ESP to form ESP packets;)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Sarva with the teachings of Hampel. Sarva discloses a method of an IP packet. Hampel discloses a method to encapsulate the classification information and IP packet with an Encapsulating Security Protocol (ESP). The combination of an IP packet encapsulated with an ESP header for tunneling of packets across a network, i.e. the use of known techniques to improve similar devices (methods and products) in the same way. (Sarva: Fig.1; ¶39, ¶51 ; Hampel: Abstract, Fig. 4, ¶122).
Sarva and Hample do not explicitly disclose:
wherein a first message of the one more messages includes the classification identifier
However, Sharma discloses:
wherein a first message of the one more messages includes the classification identifier (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets; ¶0018 In Redirection, each SIA physical device, at the data plane level, may redirect the tagged packets to the next-hop physical device in the service path. The redirection may be done using the available transport mechanisms of the underlying network. SIA does not assume a particular redirection transport mechanism. For example, the transport mechanism could be a generic routing encapsulation ("GRE") tunnel in an internet protocol ("IP") network,)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Sharma into the teachings of Sarva and Hampel. Sarva and Hampel disclose use of an IP packet, tunnel header, and ESP encapsulation. Sharma discloses messages that include IP packets. Sharma discloses classifying traffic and placing the classification into a shared context and tagging the packet before encapsulation. The combination of an IP packet with a classification identifier encapsulated for tunneling of packets across a network. i.e. the combining prior art elements according to known methods to yield predictable results. (Sharma: Fig. 1, 6; ¶0002, 0017, 0034).
Claims 13-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sarva, in view of Sharma, in view of Raleigh et al. (WO 2011149532 A1, hereinafter, “Raleigh”), in view of Serghi et al. (US 20060233180 A1, hereinafter “Serghi”).
RE Claim 13: Sarva discloses:
A system, comprising:
A controller including an attribute-policy mapping, the controller being deployed within a cloud computing platform and maintained within a non-transitory storage medium; (Fig. 1, #23, #24, ¶; ¶62 For example, network controller 24 may support an interface for specifying connections between virtual networks, subject to policy constraints. A policy rule may, for instance, allow packets mapped to a service chain to flow from a source virtual network to a destination virtual network while forcing the traffic through the list of service instances; )
A plurality of nodes including a first node including one or more logical devices to execute at least a first application, and (Fig. 1 #10, #16; ¶26 Servers 12, 16 are computing devices and may also be referred to herein as “hosts” or “host devices,” compute nodes, or computing devices. Data center 10 may host many hundreds or even thousands or servers interconnected via the switch fabric) Fig. 1; ¶8 The one or more VNF instances for a single service may be hosted by separate computing devices, e.g., compute nodes or servers.; ¶22 In general, data center 10 provides an operating environment for applications and services; ¶35 Any server of servers 12, 16 may be configured with virtual execution elements by virtualizing resources of the server to provide an isolation among one or more processes (applications) executing on the server)
Sarva does not explicitly disclose:
a second node coupled to the first node via a secure communication link, the second node operates as an ingress gateway and is configured to receive a Transport Layer Security (TLS) certificate from the first node, the TLS certificate includes one or more attributes for the first application providing a data flow to the second node,
However, Raleigh discloses:
the TLS certificate includes one or more attributes for the first application providing a data flow to the second node (Fig. 12, 27; ¶37 Many network performance measures can be advantageously maintained or improved as network loading increases if capacity management and/or network resource management is employed. For example, these performance measures include network availability; the ability to deliver connections to all devices, users and/or applications seeking connections and enabled for service on the network; network access attempt success rate; the transmission speed experienced by one or more devices, users or applications; the average transmission speed experienced by all devices, users and/or applications; ¶199 In other embodiments, as described herein, in the downstream case, the solution is generally more sophisticated when a traffic parameter that is needed to classify the manner in which the traffic flow is to be controlled or throttled is not readily available at the lower levels of the stack, such as association with an aspect of an application, type of content, something contained within TLS, IPSEC or other secure format, or other information associated with the traffic.;¶242 In some embodiments, the layer 7 proxy server traffic accounting and reporting techniques used for processing HTTPS, TLS, and SSL traffic, as discussed above, are also used in the service processor itself to allow a detailed accounting of encrypted layer 7 traffic by the device.,
Sarva and Raleigh do not explicitly disclose:
a second node coupled to the first node via a secure communication link, the second node operates as an ingress gateway and is configured to receive a Transport Layer Security (TLS) certificate from the first node
However, Serghi discloses:
a second node coupled to the first node via a secure communication link, the second node operates as an ingress gateway and is configured to receive a Transport Layer Security (TLS) certificate from the first node (Services network includes a network controller for the network including a security module to provide secure communication. ¶0020-0022, Fig. 1; Client gateway is an edge device into the services network provider infrastructure. ¶0054; Communications through the client gateway and services network are secured using Transport Layer Security, TLS, used to provide secure communications while existent enterprise ingress and egress certificates. ¶0080)
Sarva, Raleigh, and Serghi do not explicitly disclose:
wherein the second node is configured to i) access first attributes associated with a source application of the first node and second attributes associated with the data flow to determine a network policy that comports with the data flow based on an attribute-policy mapping provided by the controller, ii) determine a ClassID for the data flow based upon a mapping between the network policy and the ClassID, and iii) encapsulate the ClassID into the data flow.
However, Sharma discloses:
wherein the second node is configured to i) access first attributes associated with a source application of the first node and second attributes associated with the data flow to determine a network policy that comports with the data flow based on an attribute-policy mapping provided by the controller (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification; ¶0034 Another advantage of the disclosed approach is virtualized service support. The concept of "shared context" enables the deployment of virtual service instances since the context is independent from the forwarding topology. For example, a first context can indicate email for a first customer; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets; ¶17 The id may be used to virtualize services in the network, which means that, irrespective of the service device location, the packet tagged with the same classification id will always undergo the same set of services in the SIA domain.), ii) determine a ClassID for the data flow based upon a mapping between the network policy and the ClassID (¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets;), and iii) encapsulate the ClassID into the data flow (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets; ¶0018 In Redirection, each SIA physical device, at the data plane level, may redirect the tagged packets to the next-hop physical device in the service path. The redirection may be done using the available transport mechanisms of the underlying network. SIA does not assume a particular redirection transport mechanism. For example, the transport mechanism could be a generic routing encapsulation ("GRE") tunnel in an internet protocol ("IP") network,).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Sarva into the teachings of Raleigh, Serghi, and Sharma. Raleigh discloses determining an attribute of an application providing a data flow for a TLS certification. Sharma discloses classifying traffic, tagging packet, and classification identifier based on network policies with the classification context. Serghi discloses an ingress gateway utilizing TLS certificates for encrypted communication in a network.
The combination of using data flow classification, application information, and security information attributes in coordination with traffic classification with their associated policies results in determining improved routing for efficient data flows, i.e. the combining prior art elements applied to a virtual network system according to known methods to yield predictable results. (Sarva: Abstract, Fig. 4, ¶10, ¶62; Raleigh: Abstract, Fig. 3, Fig. 27, ¶37, ¶199, ¶242; Serghi: Abstract, ¶¶0011-0013, 0024-0025, 0033-0035; Sharma: Fig. 1, 6; ¶0002, 0017, 0034;).
RE Claim 14: Sarva discloses:
The system, wherein the plurality of nodes comprises a master node configured to control a state of the plurality of nodes operating as a Kubernetes cluster (Fig. 1, #23, #24; ¶55 Virtual execution elements may be deployed to a virtualization environment using a cluster-based framework in which a cluster master node of a cluster manages the deployment and operation of containers to one or more cluster minion nodes of the cluster; ¶54 VM orchestration permits VM coordination and refers to the deployment, management, scaling, and configuration, e.g., of containers to host servers by a container orchestration platform. Example instances of orchestration platforms include Kubernetes, Docker swarm, Mesos/Marathon, OpenShift, OpenStack, VMware, and Amazon ECS.; ¶55 For example, the Kubernetes platform uses the terms “cluster master” and “minion nodes,”).
Re Claim 15: Sarva discloses:
The system, wherein the first node includes the one or more logical devices corresponding to a cloud instance running the source application. (Fig. 1; ¶8 The one or more VNF instances for a single service may be hosted by separate computing devices, e.g., compute nodes or servers.; ¶22 In general, data center 10 provides an operating environment for applications and services; ¶35 Any server of servers 12, 16 may be configured with virtual execution elements by virtualizing resources of the server to provide an isolation among one or more processes (applications) executing on the server.)
RE Claim 16: Sarva discloses:
The system, wherein the cloud instance corresponds to a cluster of virtual network devices that overlays a cluster of physical network devices. (Fig. 1, #10; ¶38 For example, each virtual network could be implemented as a Virtual Local Area Network (VLAN), Virtual Private Networks (VPN), etc. A virtual network can also be implemented using two networks—the physical underlay network made up of the data center 10 switching fabric (and in some cases extending outside of data center 10 and a virtual overlay network).
RE Claim 17: Sarva and Raleigh do not explicitly disclose:
The system, wherein the second node determines the classification identifier based on accessing the classification identifier from a mapping including the one or more network policies attribute corresponding to the classification identifier.
However, Sharma discloses:
The system, wherein the second node determines the classification identifier based on accessing the classification identifier from a mapping including the one or more network policies attribute corresponding to the classification identifier. (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification. After service application, it derives the next hop in the service path associated with the shared context in the packet and then sends the traffic to the next service node.; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets; ¶17 The id may be used to virtualize services in the network, which means that, irrespective of the service device location, the packet tagged with the same classification id will always undergo the same set of services in the SIA domain.)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Sarva with the teachings of Sharma. Sarva does not disclose a classification identifier. Sharma discloses classifying traffic and placing the classification into a shared context and tagging the packet. The shared context is used to derive the next hop in the path. The combination would associate a classification identifier with mapping to transfer packets to appropriate destinations, i.e. the combining prior art elements according to known methods to yield predictable results. (Sarva: Fig. 2 #106A, #120; ¶0086; Sharma: Fig. 1, 6; ¶0002, 0017, 0018).
RE Claim 18: Sarva and Raleigh do not explicitly disclose:
The system, wherein the second node is further configured to encapsulate the classification identifier into one or more messages including content from the data flow.
However, Sharma discloses:
The system, wherein the second code is further configured to encapsulate the classification identifier into one or more messages including content from the data flow. (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets; ¶0018 In Redirection, each SIA physical device, at the data plane level, may redirect the tagged packets to the next-hop physical device in the service path. The redirection may be done using the available transport mechanisms of the underlying network. SIA does not assume a particular redirection transport mechanism. For example, the transport mechanism could be a generic routing encapsulation ("GRE") tunnel in an internet protocol ("IP") network,)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Sarva with the teachings of Sharma. Sarva does not disclose a classification identifier encapsulated into messages. Sharma discloses classifying traffic and placing the classification into a shared context and tagging the packet. The combined packet is then encapsulated for tunneling, i.e. the combining prior art elements according to known methods to yield predictable results. (Sarva: ¶0051; Sharma: Fig. 1, 6; ¶0002, 0017, 0018).
RE Claim 20: Sarva discloses:
The system, wherein a first message of the one or more messages includes an Internet Protocol (IP) packet (Fig.2 #106A, #120; ¶86 In one example, virtual routers implement each virtual network using an overlay network, which provides the capability to decouple an endpoint's virtual address from a physical address (e.g., IP address) of the server on which the endpoint is executing.)
Sarva does not explicitly disclose:
wherein a first message of the one or more messages includes a Generic Routing Encapsulation (GRE) header including a field to contain the classification identifier.
However, Sharma discloses:
wherein a first message of the one or more messages includes a Generic Routing Encapsulation (GRE) header including a field to contain the classification identifier. (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets; ¶0018 In Redirection, each SIA physical device, at the data plane level, may redirect the tagged packets to the next-hop physical device in the service path. The redirection may be done using the available transport mechanisms of the underlying network. SIA does not assume a particular redirection transport mechanism. For example, the transport mechanism could be a generic routing encapsulation ("GRE") tunnel in an internet protocol ("IP") network,)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Sarva with the teachings of Sharma. Sarva discloses messages that include IP packets. Sharma discloses classifying traffic and placing the classification into a shared context and tagging the packet. The combined IP packet is then encapsulated per GRE for tunneling, i.e. the combining prior art elements according to known methods to yield predictable results. (Sarva: Fig. 2 #106A, #120; ¶0086; Sharma: Fig. 1, 6; ¶0002, 0017, 0018).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Sarva, in view of Michael, in view of Sharma, and further in view of Augusto, et al. (US 20220286392 A1, hereinafter, “Augusto”).
RE Claim 10: Sarva discloses:
the system wherein a first message of the one or more messages includes an Internet Protocol (IP) packet (Fig.2 #106A, #120; ¶86 In one example, virtual routers implement each virtual network using an overlay network, which provides the capability to decouple an endpoint's virtual address from a physical address (e.g., IP address) of the server on which the endpoint is executing.)
Sarva and Sharma do not explicitly teach:
wherein a first message of the one or more messages includes a tunneling header including a WireGuard header
However, Augusto discloses:
wherein a first message of the one or more messages includes and a tunneling header including a WireGuard header (Fig. 1, Fig. 4, ¶56 At 416, the classification and forwarding node 110 may add metadata to the packet. The metadata may include, among other things the virtual network identifier (VNI), a datacenter point of origin (e.g., ingress datacenter), and an ingress security policy. In some examples, the metadata may be added to the packet using extension fields of the GUE packet header. At 418, the classification and forwarding node 110 may send the packet to the service 114. The packet may be encapsulated according to the GENEVE protocol, as shown; ¶57 At 420, the service 114 may operate on the packet. In examples, the service 114 may comprise a firewall, a NAT service, proxy service, IDS service, IPS service, IPsec service, SSL service, WireGuard service, and/or any network service. Additionally, at 422, the service 114 may send the packet and/or return traffic back to the classification and forwarding node 110. The return packet may be encapsulated according to the GENEVE protocol.)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Sarva with the teachings of Augusto. Sarva discloses a method adding a header containing classification information to an IP packet. Augusto discloses a method to encapsulate the classification information and IP packet with a WireGuard security protocol. The combination of an IP packet with a header encapsulated for tunneling of packets across a network, i.e. the use of known techniques to improve similar devices (methods and products) in the same way. (Sarva: Fig.1; ¶39, ¶51 ; Augusto: Abstract, Fig. 1, Fig. 4, ¶56-57).
Sarva and Augusto do not explicitly disclose:
wherein a first message of the one or more messages includes the classification identifier
However, Sharma discloses:
wherein a first message of the one or more messages includes the classification identifier (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification. After service application, it derives the next hop in the service path associated with the shared context in the packet and then sends the traffic to the next service node.; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets;)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Sharma into the teachings of Sarva and Augusto. Sarva and Augusto together disclose an IP packet with WireGuard encapsulation. Sharma discloses classifying traffic, tagging packet, and classification identifier based on network policies with the classification context. The combination of an IP packet with a classification identifier encapsulated for tunneling of packets across a network, i.e. the combining prior art elements according to known methods to yield predictable results. (Sarva: Fig.1; ¶39, ¶51 ; Augusto: Abstract, Fig. 1, Fig. 4, ¶56-57; Sharma: Fig. 1, 6; ¶0002, 0017, 0034).
Claims 19 is rejected under 35 U.S.C. 103 as being unpatentable over Sarva, in view of Sharma, view of Raleigh, in view of Serghi as applied to claim 18 above, and further in view of Hampel and Augusto.
RE Claim 19: Sarva discloses:
The system, wherein a first message of the one or more messages includes an Internet Protocol (IP) packet (Fig.2 #106A, #120; ¶86 In one example, virtual routers implement each virtual network using an overlay network, which provides the capability to decouple an endpoint's virtual address from a physical address (e.g., IP address) of the server on which the endpoint is executing.)
or (c) a Virtual Extensible Local Area Network (VXLAN) header (¶90 example tunneling protocols that may be used include IP over Generic Route Encapsulation (GRE), VxLAN, Multiprotocol Label Switching (MPLS) over GRE, MPLS over User Datagram Protocol (UDP), etc.
Sarva does not explicitly disclose:
wherein a first message of the one or more messages includes a tunneling header including the classification identifier
However, Sharma discloses:
wherein a first message of the one or more messages includes a tunneling header including the classification identifier (Fig. 1 element 108, Fig. 6; ¶0002 The devices at the edge of the SIA domain classify the interested traffic, placing the classification result inside of a shared SIA context, and then redirecting the tagged packet to the next hop service in the SIA service path. Each service hop in the path receives the packet, uses the shared context to identify the traffic classification, and applies the appropriate service policy associated with the SIA classification. After service application, it derives the next hop in the service path associated with the shared context in the packet and then sends the traffic to the next service node.; ¶17 In Classification and SIA Shared Context Tagging, the classifier may intercept the interested traffic 110 and add a unique id--the "traffic classification id"--to the packets that enter into the service path. This id conveys the traffic classification, i.e., the result of classification by the SCL, to the service nodes 106 in the chain. The service nodes 106 may use this id to apply service-specific polices to the packets; ¶18 may redirect the tagged packets to the next-hop physical device in the service path. The redirection may be done using the available transport mechanisms of the underlying network. SIA does not assume a particular redirection transport mechanism. For example, the transport mechanism could be a generic routing encapsulation ("GRE") tunnel in an internet protocol ("IP") network,)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Sarva with the teachings of Sharma. Sarva discloses messages that include IP packets and encapsulation via VxLAN. Sharma discloses classifying traffic and placing the classification into a shared context and tagging the packet. The combination adding classification identifier to the header encapsulated per tunneling, i.e. the combining prior art elements according to known methods to yield predictable results. (Sarva: Fig. 2 #106A, #120; ¶0086; Sharma: Fig. 1, 6; ¶0002, 0017, 0018).
Sarva and Sharma do not explicitly disclose:
wherein a first message of the one or more messages includes either (a) an Encapsulating Security Protocol (ESP) header, (b) a WireGuard header
However, Hampel discloses:
wherein a first message of the one or more messages includes (a) an Encapsulating Security Protocol (ESP) header (¶20 In at least some embodiments, an overlay network is a type of network that utilizes tunneling in order to support enhanced features which may not be able to be provided (or easily provided) by the underlying network infrastructure on which the overlay network is provided. For example, an overlay network may be used to support service differentiation (e.g., different quality-of-service handling of different traffic flows or different types of traffic flows, application of different policy or charging functions for different traffic flows or different types of traffic flows, or the like, as well as various combinations thereof); Fig. 1, #160; Fig. 4, #450; ¶45 The FE 160 may be configured to apply the one or more tunneling actions to the packet of the data flow based on processing of the one or more tunneling actions identified from the data flow record associated with the data flow.; ¶51 For example, a UDP-based encapsulation action that is communicated from the CE 150 to the FE 160 may include information indicative that UDP-based encapsulation is to be performed and one or more UDP header field values (e.g., one or more of a length value, a source port number, a destination port number, or other UDP header fields) to be used in the UDP header that is added to the packet of the data flow.; ¶122 The security gateway FE 360.sub.2 identifies IP packets of the data flow, encapsulates the IP packets using UDP to form UDP packets (UDP tunnel), further encapsulates the UDP packets using ESP to form ESP packets;)
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the method of Sarva with the teachings of Hampel. Sarva discloses a method adding a header containing classification information to an IP packet. Hampel discloses a method to encapsulate the classification information and IP packet with an Encapsulating Security Protocol (ESP). The combination of an IP packet encapsulated with an ESP header for tunneling of packets across a network, i.e. the use of known techniques to improve similar devices (methods and products) in the same way. (Sarva: Fig.1; ¶39, ¶51 ; Sharma: Fig. 1, 6; ¶0002, 0017, 0018; Hampel: Abstract, Fig. 4, ¶122).
Sarva, Sharma, and Hampel do not explicitly disclose:
wherein a first message of the one or more messages includes (b) a WireGuard header
However, Augusto discloses: wherein a first message of the one or more messages includes (b) a WireGuard header (Fig. 1, Fig. 4, ¶56 At 416, the classification and forwarding node 110 may add metadata to the packet. The metadata may include, among other things the virtual network identifier (VNI), a datacenter point of origin (e.g., ingress datacenter), and an ingress security policy. In some examples, the metadata may be added to the packet using extension fields of the GUE packet header. At 418, the classification and forwarding node 110 may send the packet to the service 114. The packet may be encapsulated according to the GENEVE protocol, as shown.; ¶57 At 420, the service 114 may operate on the packet. In examples, the service 114 may comprise a firewall, a NAT service, proxy service, IDS service, IPS service, IPsec service, SSL service, WireGuard service, and/or any network service. Additionally, at 422, the service 114 may send the packet and/or return traffic back to the classification and forwarding node 110. The return packet may be encapsulated according to the GENEVE protocol.)
It would have been further obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Augusto into the teachings of Sarva, Sharma, and Hampel. Sarva discloses an IP packet Sharma discloses a method adding a header containing classification information to an IP packet. Hampel discloses a method to encapsulate the classification information and IP packet. Augusto discloses encapsulating the packet in a WireGuard tunnel header. The combination of an IP packet with a classification identifier and with a header encapsulated for tunneling of packets across a network, i.e. the use of known techniques to improve similar devices (methods and products) in the same way. (Sarva: Fig.1; ¶39, ¶51 ; Sharma: Fig. 1, 6; ¶0002, 0017, 0018; Hampel: Abstract, Fig. 4, ¶122; Augusto: Abstract, Fig. 1, Fig. 4, ¶56-57).
Response to Arguments
Applicant’s 35 U.S.C. §103 rejection arguments with respect to amended claim(s) 1 and 13 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
US-6591299-B2 Riddle et al.
US-7292531-B1 Hill
US-6412000-B1 Riddle et al.
US-6457051-B1 Riddle et al.
US 20220191168 A1 Snehashis et al.
US 20220124150 A1 Alagna et al.
The above references disclose various aspects of classifying traffic to improve performance efficiency.
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 PAUL A. LANGER whose telephone number is (703)756-1780. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm, Eastern.
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, Nishant B. Divecha can be reached at 1 (571) 270-3125. 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.
/PAUL A. LANGER/Examiner, Art Unit 2419
/JACKIE ZUNIGA ABAD/Primary Examiner, Art Unit 2469
Prosecution Insights