DETAILED ACTION
Response to Amendment
Claims 1-20 are pending.
Response to Arguments
Applicant’s arguments filed 03/16/2026 have been fully considered.
In view of the amendment and after further search and consideration, Claims 1-9, 11-13 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Prashanth et al. (US11956145B1) in view of Beliveau et al. (US20130163426A1). Claims 10 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Prashanth in view of Beliveau, further in view of Keane et al. (US20220210005A1). Claims 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Prashanth.
As to any argument not specifically addressed, they are the same as those discussed above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-9, 11-13 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Prashanth et al. (US11956145B1) in view of Beliveau et al. (US20130163426A1).
Regarding claim 1, Prashanth discloses a system comprising ([col 1 lines 35-40] shows a hub may be a gateway router between the client and a remote hub to a destination client; [col 20 lines 36-43] shows a software-defined wide area network (SD-WAN) facilitating a secure tunnel between the first hub and the second hub):
a packet processing pipeline circuit configured to implement a data plane ([Abstract] shows a secure tunnel receiving a sequence of packets, facilitating a first secure tunnel between a first hub and a second hub, assigning a first flow identifier to the sequence of packets, encapsulating a first start packet, the wrapper including the first flow identifier, sending the encapsulated first start packet to the second hub through the first secure tunnel); and
a processor [first hub] configured to implement a control plane ([col 13 lines 62-63] shows information relating to the services may be sent to a controller; [col 20 lines 36-43] shows the first hub), wherein
the control plane and the data plane are configured to ([col 13 lines 22] shows controllers; [col 12 lines 60-63] shows the first hub 834 creating a session for packets from Client 5 to Server 7):
send, to a remote tunnel endpoint [second hub 836], a first encapsulating packet that includes a forward flow packet of a forward flow [from Client to Server] and a forward flow value [flow identifier] associated with the forward flow ([col 12 lines 60-63] shows the first hub 834 creating a session for packets from Client 5 to Server 7. The session establishes a secure tunnel between the two hubs so that data may be sent securely through an SD-WAN; [col 13 lines 1-3] shows the first sequence of operations 802 includes assigning a local flow identifier, 51, for use with all packets in this session; [col 15 lines 50-55] shows the first hub 834 sends the packet as part of an encapsulated reduced packet 811 to the second hub 836),
the forward flow packet including a plurality of static [immutable] header fields of the forward flow packet and a plurality of dynamic [mutable] fields of the forward flow packet ([col 9 lines 62-67; col 10 lines 10-15] shows an Internet Protocol version 4 (IPv4) header 300 is divided into mutable and immutable fields. The source address, destination address, protocol fields, version, Header Length, Length fields do not change. After the first packet with the IPv4 header, the values for these fields do not need to be sent again and the fields can be removed. By contrast, the values of the Type of Service (TOS), Identifier, Flag, Offset, and Time to Live (TTL) fields may change with each packet and are included in each packet. These values may be combined, compressed, and otherwise reduced in size. The reduced number of fields may be sent as is or converted into a metadata portion of an encapsulated packet); and
receive a bandwidth saving allowed indication from the remote tunnel endpoint in response to the remote tunnel endpoint determining that the forward flow value is true ([col 23 lines 18-48] shows establishing the secure tunnel includes establishing a session and the process includes encapsulating a start packet of the sequence of packets in a wrapper that includes the flow identifier and the header of the encapsulated start packet. Sending the encapsulated start packet from the first hub to the second hub through the secure tunnel is performed. After the start packet is successfully received by the second hub, then receiving an acknowledgement of the flow identifier from the second hub and updating a state of the session with the acknowledgement is performed; [col 18 lines 24-42] shows the second host encapsulates and sends 916 the encapsulated reply start packet from the second host with a wrapper that includes an indication that it has learned the remote flow identifier, the flow identifier assigned by the first hub 904. When the reply start packet arrives at the first hub, the first hub is able to update its session object with the flow learnt status as true. When a second packet is sent 918 from the first host to the second host 908, the first hub 904 is able to use the established session and flow identifier to send 919 reduced packets through the SD-WAN. Otherwise the first hub receives an error message from the second hub including the flow identifier. The first hub facilitates a second secure tunnel between the first hub and the second hub in response to receiving the error message, assigns a second flow identifier to the sequence of packets); and
send, in response to receiving the bandwidth saving allowed indication, a second encapsulating packet, the second encapsulating packet including the forward flow value and a plurality of dynamic fields of a second forward flow packet of the forward flow, wherein a plurality of static header fields of the second forward flow packet is omitted [immutable fields removed] from the second encapsulating packet ([col 9 lines 15-38] shows the second packet of the subsequent packets 206 from the client 110 may be another packet that all share the same source IP address and the same destination IP address. The encapsulated packet 218 may include the flow identifier 220 to identify the second packet of the subsequent packets 206 as being a part of the sequence of packets. The immutable fields may be removed. The same approach may also be used for packets from the remote server 112 to the client 110 in which a flow identifier 220 is associated with the sequence of packets and subsequent packets from the second branch node 104 to the first branch node 102 are sent with reduced overhead. By recovering all of the fields to the IP header of the second packet 208 to the remote server 112, the remote server 112 is able to communicate without any change in its operation and without any adjustment for the secure tunnel 122 or the flow identifiers 220.)
Prashanth discloses the forward flow value is true ([col 18 lines 24-35]) but fails to teach the forward flow value is unique.
However, Beliveau discloses the forward flow value is unique (para [0111] shows packets utilizing tunneling and encapsulation; para [0062] shows the flow table includes a Flow ID column 141, which assigns a unique identifier to each flow entry for ease of communication between the forwarding element 120A and the controller 110. For example, when a controller 110 desires to modify one or more actions 146A-146N in a flow table 140A, it may easily transmit a Flow ID 141 value to quickly identify which entry is to be modified.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the system of Prashanth with the teaching of Beliveau for ease of communication between the tunnel endpoints (Beliveau; para [0062]).
Regarding claim 2, Prashanth-Beliveau as applied to claim 1 discloses the plurality of static header fields includes a destination address field, a source address field, a destination port field, and a source port field (Prashanth; [col 1 lines 50-56] shows a typical 5-tuple is a packet header that includes a source internet protocol (IP) address (src-ip or SIP), a destination internet protocol address (dst-ip or DIP), a protocol (proto), a source port (src-port) and a destination port (dst-port) and may be designated using the notation <src-ip, dst-ip, proto, src-port, dst-port>; [col 9 lines 62-67; col 10 lines 10-15] shows an Internet Protocol version 4 (IPv4) header 300 is divided into mutable and immutable fields. The source address, destination address, protocol fields, version, Header Length, Length fields do not change. For the duration of the 5-tuple, the source port and destination port do not change.)
Regarding claim 3, Prashanth-Beliveau as applied to claim 1 discloses the control plane and the data plane are configured to:
store a reverse flow [from server to client] value [flow identifier] corresponding to a plurality of static header field values of the forward flow packet; receive a third encapsulating packet that includes the reverse flow value and a plurality of dynamic header field values of a reverse flow packet; and use the dynamic header field values of the reverse flow packet and the reverse flow value to recover the reverse flow packet, wherein the plurality of static header fields of the reverse flow packet is omitted from the third encapsulating packet (Prashanth; [col 7 lines 15-38] shows the second packet of the subsequent packets 206 from the client 110 may be another packet that all share the same source IP address and the same destination IP address. The encapsulated packet 218 may include the flow identifier 220 to identify the second packet of the subsequent packets 206 as being a part of the sequence of packets. The immutable fields may be removed. The same approach may also be used for packets from the remote server 112 to the client 110 in which a flow identifier 220 is associated with the sequence of packets and subsequent packets from the second branch node 104 to the first branch node 102 are sent with reduced overhead. By recovering all of the fields to the IP header of the second packet 208 to the remote server 112, the remote server 112 is able to communicate without any change in its operation and without any adjustment for the secure tunnel 122 or the flow identifiers 220; [col 11 lines 7-15] shows the reduced packet 704 provides an example of how immutable fields may be removed from a packet header to form a reduced packet. The mutable fields are preserved but may be compressed and also encrypted. The removed fields are immutable for a particulaur flow, identified with a flow identifier, but will have different immutable values for other flows. Accordingly, the flow identifier of the SD-WAN header may be used to recover the values for the immutable fields from a different packet within the flow.)
Regarding claim 4, Prashanth-Beliveau as applied to claim 3 discloses recovering the reverse flow [from server to client] packet includes: using the reverse flow value [flow identifier] to obtain the plurality of static header field values from a flow table; and using the plurality of static header field values to assemble a header of the reverse flow packet in response to obtaining the plurality of static header field values from the flow table (Prashanth; [col 7 lines 15-38] shows the second packet of the subsequent packets 206 from the client 110 may be another packet that all share the same source IP address and the same destination IP address. The encapsulated packet 218 may include the flow identifier 220 to identify the second packet of the subsequent packets 206 as being a part of the sequence of packets. The immutable fields may be removed. The same approach may also be used for packets from the remote server 112 to the client 110 in which a flow identifier 220 is associated with the sequence of packets and subsequent packets from the second branch node 104 to the first branch node 102 are sent with reduced overhead. By recovering all of the fields to the IP header of the second packet 208 to the remote server 112, the remote server 112 is able to communicate without any change in its operation and without any adjustment for the secure tunnel 122 or the flow identifiers 220; [col 11 lines 7-15] shows the reduced packet 704 provides an example of how immutable fields may be removed from a packet header to form a reduced packet. The mutable fields are preserved but may be compressed and also encrypted. The removed fields are immutable for a particular flow, identified with a flow identifier, but will have different immutable values for other flows. Accordingly, the flow identifier of the SD-WAN header may be used to recover the values for the immutable fields from a different packet within the flow.)
Regarding claim 5, Prashanth-Beliveau as applied to claim 3 discloses: a memory configured to store a flow table that includes a flow table entry for the forward flow and that includes a flow table entry for a reverse flow that includes the reverse flow packet, wherein (Prashanth; [col 20 line 15] shows a database in a memory; [col 24 lines 53-54] shows the session tables may include session object states, flow identifiers, immutable field values, and other values; [col 8 line 36; col 9 lines 15-38] shows the flow identifier 220 to identify packets from the client 110 to the remote server 112 and packets from the remote server 112 to the client 110):
the data plane is configured to produce the reverse flow packet by using the reverse flow value that is in the third encapsulating packet to locate the flow table entry for the reverse flow and to read the plurality of static header field values of the reverse flow packet from the flow table entry for the reverse flow; and the data plane is configured to use forward flow value to locate the flow table entry for the forward flow in response to receiving a packet of the forward flow (Prashanth; [col 9 lines 15-38] shows the second packet of the subsequent packets 206 from the client 110 may be another packet that all share the same source IP address and the same destination IP address. The encapsulated packet 218 may include the flow identifier 220 to identify the second packet of the subsequent packets 206 as being a part of the sequence of packets. The immutable fields may be removed. The same approach may also be used for packets from the remote server 112 to the client 110 in which a flow identifier 220 is associated with the sequence of packets and subsequent packets from the second branch node 104 to the first branch node 102 are sent with reduced overhead. By recovering all of the fields to the IP header of the second packet 208 to the remote server 112, the remote server 112 is able to communicate without any change in its operation and without any adjustment for the secure tunnel 122 or the flow identifiers 220; [col 11 lines 7-15] shows the reduced packet 704 provides an example of how immutable fields may be removed from a packet header to form a reduced packet. The mutable fields are preserved but may be compressed and also encrypted. The removed fields are immutable for a particular flow, identified with a flow identifier, but will have different immutable values for other flows. Accordingly, the flow identifier of the SD-WAN header may be used to recover the values for the immutable fields from a different packet within the flow.)
Regarding claim 6, Prashanth-Beliveau as applied to claim 5 discloses the control plane is configured to store the flow table entry for the forward flow and the flow table entry for the reverse flow in the flow table in response to receiving the forward flow packet (Prashanth; [col 20 line 15] shows a database in a memory; [col 24 lines 53-54] shows the session tables may include session object states, flow identifiers, immutable field values, and other values; [col 8 line 36; col 9 lines 15-38] shows the flow identifier 220 to identify packets from the client 110 to the remote server 112 and packets from the remote server 112 to the client 110).
Regarding claim 7, Prashanth-Beliveau as applied to claim 5 discloses the control plane is configured to: use a plurality of networking rules to produce forward flow processing directives and to store the forward flow processing directives in the flow table entry for the forward flow; and use the plurality of networking rules to produce reverse flow processing directives and to store the reverse flow processing directives in the flow table entry for the reverse flow (Prashanth; [col 3 lines 35-55] shows the operations include receiving a sequence of packets from a first client at a first hub, the sequence of packets each having a same flow, facilitating a secure tunnel between the first hub and a second hub, assigning a first flow identifier to the sequence of packets having the flow, encapsulating a start packet of the sequence of packets in a wrapper, the wrapper including the first flow identifier, sending the encapsulated start packet of the sequence of packets from the first hub to the second hub through the secure tunnel, receiving an error message from the second hub, the error message including the first flow identifier and an error code, facilitating a second secure tunnel between the first hub and the second hub in response to receiving the error message, assigning a second flow identifier to the sequence of packets, encapsulating a second packet of the sequence of packets in a wrapper, the wrapper including the second flow identifier, and sending the encapsulated reduced packet of the sequence of packets from the first hub to the second hub through the second secure tunnel.)
Regarding claim 8, Prashanth-Beliveau as applied to claim 5 discloses hashing a 5-tuple of the reverse flow packet produces the reverse flow value (Prashanth; [col 9 lines 65-67] shows the immutable fields are immutable for the duration of the 5-tuple and are hashed.)
Regarding claim 9, Prashanth-Beliveau as applied to claim 3 discloses: the plurality of static header field values of the forward flow packet includes a forward flow destination address value, a forward flow source address value, a forward flow destination port value, and a forward flow source port value; and the plurality of static header field values of the reverse flow packet includes a reverse flow destination address value that equals the forward flow source address value, a reverse flow source address value that equals the forward flow destination address value, a reverse flow destination port value that equals the forward flow source port value, and a reverse flow source port value that equals the forward flow destination port value (Prashanth; [col 1 lines 50-56] shows a typical 5-tuple is a packet header that includes a source internet protocol (IP) address (src-ip or SIP), a destination internet protocol address (dst-ip or DIP), a protocol (proto), a source port (src-port) and a destination port (dst-port) and may be designated using the notation <src-ip, dst-ip, proto, src-port, dst-port>; [col 9 lines 62-67; col 10 lines 10-15] shows an Internet Protocol version 4 (IPv4) header 300 is divided into mutable and immutable fields. The source address, destination address, protocol fields, version, Header Length, Length fields do not change; [col 10 lines 1-5] shows for the duration of the 5-tuple, the source port and destination port do not change; [col 14 lines 30-35] shows the remote server 838 generates a packet to send to the client 832. The packets may have a same or similar form as those from the client 832.)
Regarding claim 11, Prashanth-Beliveau as applied to claim 1 discloses the system further including:
the remote tunnel endpoint, the remote tunnel endpoint configured to (Prashanth; [col 1 lines 35-40] shows a hub may be a gateway router between the client and a remote hub to a destination client; [col 20 lines 36-43] shows a software-defined wide area network (SD-WAN) facilitating a secure tunnel between the first hub and the second hub):
store a plurality of static [immutable] header field values of the forward flow packet corresponding to the forward flow value [flow identifier] in response to receiving the first encapsulating packet; use the forward flow value in the second encapsulated packet to obtain the plurality of static header field values of the forward flow packet in response to receiving the second encapsulating packet; and recover the second forward flow packet by combining the plurality of static header field values obtained using the forward flow value with the dynamic fields of the second forward flow packet that are in the second encapsulating packet (Prashanth; [col 9 lines 62-67; col 10 lines 10-15] shows an Internet Protocol version 4 (IPv4) header 300 is divided into mutable and immutable fields. The source address, destination address, protocol fields, version, Header Length, Length fields do not change. After the first packet with the IPv4 header, the values for these fields do not need to be sent again and the fields can be removed. By contrast, the values of the Type of Service (TOS), Identifier, Flag, Offset, and Time to Live (TTL) fields may change with each packet and are included in each packet. These values may be combined, compressed, and otherwise reduced in size. The reduced number of fields may be sent as is or converted into a metadata portion of an encapsulated packet; [col 7 lines 15-38] shows the second packet of the subsequent packets 206 from the client 110 may be another packet that all share the same source IP address and the same destination IP address. The encapsulated packet 218 may include the flow identifier 220 to identify the second packet of the subsequent packets 206 as being a part of the sequence of packets. The immutable fields may be removed. The same approach may also be used for packets from the remote server 112 to the client 110 in which a flow identifier 220 is associated with the sequence of packets and subsequent packets from the second branch node 104 to the first branch node 102 are sent with reduced overhead. By recovering all of the fields to the IP header of the second packet 208 to the remote server 112, the remote server 112 is able to communicate without any change in its operation and without any adjustment for the secure tunnel 122 or the flow identifiers 220.)
Regarding claim 12, Prashanth-Beliveau as applied to claim 1 discloses the forward flow value is unique when the remote tunnel endpoint is not configured to process a different flow having a flow value equaling the forward flow value (Beliveau; para [0062] shows the flow table includes a Flow ID column 141, which assigns a unique identifier to each flow entry for ease of communication between the forwarding element 120A and the controller 110. For example, when a controller 110 desires to modify one or more actions 146A-146N in a flow table 140A, it may easily transmit a Flow ID 141 value to quickly identify which entry is to be modified.)
Regarding claim 13, Prashanth-Beliveau as applied to claim 1 discloses the control plane is configured to store a forward flow table [from client to server] entry and a reverse flow [from server to client] table entry in response to receiving the forward flow packet, the reverse flow table entry including a reverse flow value for recovering static header fields of a reverse flow packet received from the remote tunnel endpoint (Prashanth; [col 20 line 15] shows a database in a memory; [col 24 lines 53-54] shows the session tables may include session object states, flow identifiers, immutable field values, and other values; [col 8 line 36; col 9 lines 15-38] shows the flow identifier 220 to identify packets from the client 110 to the remote server 112 and packets from the remote server 112 to the client 110).
Regarding claim 15, Prashanth-Beliveau as applied to claim 1 discloses omitting the plurality of static header fields from encapsulating packets includes: storing, in a flow table, a first value corresponding to a plurality of static header field values of a first packet in response to receiving a third encapsulating packet that includes the first value and the first packet; receiving a fourth encapsulating packet that includes the first value and a plurality of dynamic field values of a second packet; using the first value in the fourth encapsulated packet to obtain the plurality of static header field values of the first packet from the flow table; and recovering the second packet by combining the plurality of static header field values obtained using the first value with the plurality of dynamic field values of the second packet included in the fourth encapsulating packet (Prashanth; [col 7 lines 15-38] shows the second packet of the subsequent packets 206 from the client 110 may be another packet that all share the same source IP address and the same destination IP address. The encapsulated packet 218 may include the flow identifier 220 to identify the second packet of the subsequent packets 206 as being a part of the sequence of packets. The immutable fields may be removed. The same approach may also be used for packets from the remote server 112 to the client 110 in which a flow identifier 220 is associated with the sequence of packets and subsequent packets from the second branch node 104 to the first branch node 102 are sent with reduced overhead. By recovering all of the fields to the IP header of the second packet 208 to the remote server 112, the remote server 112 is able to communicate without any change in its operation and without any adjustment for the secure tunnel 122 or the flow identifiers 220.)
Regarding claim 16, Prashanth discloses a system comprising ([col 1 lines 35-40] shows a hub may be a gateway router between the client and a remote hub to a destination client; [col 20 lines 36-43] shows a software-defined wide area network (SD-WAN) facilitating a secure tunnel between the first hub and the second hub):
a packet processing pipeline circuit configured to implement a data plane ([Abstract] shows a secure tunnel receiving a sequence of packets, facilitating a first secure tunnel between a first hub and a second hub, assigning a first flow identifier to the sequence of packets, encapsulating a first start packet, the wrapper including the first flow identifier, sending the encapsulated first start packet to the second hub through the first secure tunnel); and
a processor [second hub] configured to implement a control plane ([col 13 lines 62-63] shows information relating to the services may be sent to a controller; [col 20 lines 36-43] shows the second hub),
wherein the control plane and the data plane are configured to omit a plurality of static header fields from a plurality of encapsulating packets by ([col 9 lines 62-67; col 10 lines 10-15] shows an Internet Protocol version 4 (IPv4) header 300 is divided into mutable and immutable fields. The source address, destination address, protocol fields, version, Header Length, Length fields do not change. After the first packet with the IPv4 header, the values for these fields do not need to be sent again and the fields can be removed. By contrast, the values of the Type of Service (TOS), Identifier, Flag, Offset, and Time to Live (TTL) fields may change with each packet and are included in each packet. These values may be combined, compressed, and otherwise reduced in size. The reduced number of fields may be sent as is or converted into a metadata portion of an encapsulated packet):
storing a plurality of static header field values of a forward flow [from Client to Server] packet corresponding to a forward flow value [flow identifier] in response to receiving, from a remote tunnel endpoint [first hub], a first encapsulating packet that includes the forward flow value and the forward flow packet ([col 12 lines 62-63] shows a session for packets from Client 5 to Server 7. The session establishes a secure tunnel between the two hubs so that data may be sent securely through an SD-WAN; [col 13 lines 1-3] shows the first sequence of operations 802 includes assigning a local flow identifier, 51, for use with all packets in this session; [col 15 lines 50-55] shows the first hub 834 sends the packet as part of an encapsulated reduced packet 811 to the second hub 836; [col 24 lines 53-54] shows the session tables may include session object states, flow identifiers, immutable field values, and other values; [col 18 lines 43-44] shows the encapsulated reduced packet is received at the second hub and then forwarded 920 to the second host);
sending a bandwidth saving allowed indication to the remote tunnel endpoint in response to determining that the forward flow value is true ([col 14 lines 50-60] shows in receiving the packet 806 from the remote server 838, the second hub 836 informs the first hub 834 that it has learned the flow identifier, 51, that the first hub 834 has allocated for this flow; [col 18 lines 24-42] shows when the reply start packet arrives at the first hub, the first hub is able to update its session object with the flow learnt status as true); and
recovering a second forward flow packet by combining the plurality of static header field values stored corresponding to the forward flow value with a plurality of dynamic field values of the second forward flow packet in response to receiving a second encapsulating packet that includes the forward flow value and the plurality of dynamic field values of the second forward flow packet, wherein the plurality of static header fields of the second forward flow packet is omitted from the second encapsulating packet ([col 7 lines 15-38] shows the second packet of the subsequent packets 206 from the client 110 may be another packet that all share the same source IP address and the same destination IP address. The encapsulated packet 218 may include the flow identifier 220 to identify the second packet of the subsequent packets 206 as being a part of the sequence of packets. The immutable fields may be removed. The same approach may also be used for packets from the remote server 112 to the client 110 in which a flow identifier 220 is associated with the sequence of packets and subsequent packets from the second branch node 104 to the first branch node 102 are sent with reduced overhead. By recovering all of the fields to the IP header of the second packet 208 to the remote server 112, the remote server 112 is able to communicate without any change in its operation and without any adjustment for the secure tunnel 122 or the flow identifiers 220.)
Prashanth discloses the forward flow value is true ([col 18 lines 24-35]) but fails to teach the forward flow value is unique.
However, Beliveau discloses the forward flow value is unique (para [0111] shows packets utilizing tunneling and encapsulation; para [0062] shows the flow table includes a Flow ID column 141, which assigns a unique identifier to each flow entry for ease of communication between the forwarding element 120A and the controller 110. For example, when a controller 110 desires to modify one or more actions 146A-146N in a flow table 140A, it may easily transmit a Flow ID 141 value to quickly identify which entry is to be modified.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the system of Prashanth with the teaching of Beliveau for ease of communication between the tunnel endpoints (Beliveau; para [0062]).
Regarding claim 17, Prashanth-Beliveau as applied to claim 16 discloses omitting the plurality of static header fields from the plurality of encapsulating packets includes (Prashanth; [col 9 lines 62-67; col 10 lines 10-15] shows an Internet Protocol version 4 (IPv4) header 300 is divided into mutable and immutable fields. The source address, destination address, protocol fields, version, Header Length, Length fields do not change. After the first packet with the IPv4 header, the values for these fields do not need to be sent again and the fields can be removed. By contrast, the values of the Type of Service (TOS), Identifier, Flag, Offset, and Time to Live (TTL) fields may change with each packet and are included in each packet. These values may be combined, compressed, and otherwise reduced in size. The reduced number of fields may be sent as is or converted into a metadata portion of an encapsulated packet):
storing a flow table entry for a reverse flow [from server 112 to client] corresponding to a reverse flow value in response to receiving the first encapsulating packet ([col 24 lines 53-54] shows the session tables may include session object states, flow identifiers, immutable field values, and other values; [col 7 lines 15-38] shows the flow identifier 220 to identify packets from the client 110 to the remote server 112 and packets from the remote server 112 to the client 110);
calculating a flow table key for a reverse flow [from server 112 to client] packet that is in the reverse flow in response to receiving the reverse flow packet, the flow table key equaling the reverse flow value (col 7 lines 15-38] shows the flow identifier 220 to identify packets from the client 110 to the remote server 112 and packets from the remote server 112 to the client 110);
determining that the reverse flow omits the plurality of static header fields by using the flow table key to access the flow table entry for the reverse flow; and producing a third encapsulating packet that includes the reverse flow value and a plurality of dynamic fields of the reverse flow packet in response to determining that the reverse flow omits the plurality of static header fields, wherein the third encapsulating packet omits the plurality of static header fields ([col 7 lines 15-38] shows removing the associated fields from a header of a third packet of the sequence of packets to form a reduced third packet, and encapsulating the reduced third packet in a wrapper that includes the second flow identifier; and sending the encapsulated reduced third packet of the sequence of packets from the first hub to the second hub through the secure tunnel.)
Regarding claim 18, Prashanth-Beliveau as applied to claim 17 discloses:
a memory configured to store a flow table that includes a flow table entry for a forward flow that includes the forward flow packet and that includes the flow table entry for the reverse flow (Prashanth; [col 20 line 15] shows a database in a memory; [col 24 lines 53-54] shows the session tables may include session object states, flow identifiers, immutable field values, and other values; [col 7 lines 15-38] shows the flow identifier 220 to identify packets from the client 110 to the remote server 112 and packets from the remote server 112 to the client 110),
wherein:
the data plane is configured to recover the second forward flow packet by using the forward flow value that is in the second encapsulating packet to locate the flow table entry for the forward flow and to read the plurality of static header field values of the forward flow packet from the flow table entry for the forward flow; and the data plane is configured to use the reverse flow value to locate the flow table entry for the reverse flow in response to receiving a packet of the reverse flow (Prashanth; [col 7 lines 15-38] shows the second packet of the subsequent packets 206 from the client 110 may be another packet that all share the same source IP address and the same destination IP address. The encapsulated packet 218 may include the flow identifier 220 to identify the second packet of the subsequent packets 206 as being a part of the sequence of packets. The immutable fields may be removed. The same approach may also be used for packets from the remote server 112 to the client 110 in which a flow identifier 220 is associated with the sequence of packets and subsequent packets from the second branch node 104 to the first branch node 102 are sent with reduced overhead. By recovering all of the fields to the IP header of the second packet 208 to the remote server 112, the remote server 112 is able to communicate without any change in its operation and without any adjustment for the secure tunnel 122 or the flow identifiers 220; [col 11 lines 7-15] shows the reduced packet 704 provides an example of how immutable fields may be removed from a packet header to form a reduced packet. The mutable fields are preserved but may be compressed and also encrypted. The removed fields are immutable for a particular flow, identified with a flow identifier, but will have different immutable values for other flows. Accordingly, the flow identifier of the SD-WAN header may be used to recover the values for the immutable fields from a different packet within the flow.)
Claims 10 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Prashanth in view of Beliveau, further in view of Keane et al. (US20220210005A1).
Regarding claim 10, Prashanth-Beliveau as applied to claim 1 discloses the immutable fields of the 5-tuple and are hashed ([col 9 lines 65-67]) but fails to teach hashing a 5-tuple of the forward flow packet produces the forward flow value.
However, Keane discloses hashing a 5-tuple of the forward flow packet produces the forward flow value (para [0045] shows customer traffic is encapsulated to facilitate routing in the virtual network; para [0154] shows the hashing of the header of the packet may identify the tuple fields (e.g., packet identifier, a source IP address, a source port, a destination IP address, a destination port, and a layer 4 protocol).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Prashanth with the teaching of Keane in order to determine any change in state information for the communication channel (Keane; para [0153]).
Regarding claim 14, Prashanth-Beliveau as applied to claim 1 fails to teach the first encapsulating packet is a GENEVE packet.
However, Keane discloses the first encapsulating packet is a GENEVE packet (Customer traffic is encapsulated to facilitate routing in the virtual network; para [0040] shows GENEVE).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Prashanth with the teaching of Keane in order to create layers of network abstraction that can be run on top of the physical network (Keane; para [0040]).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Prashanth.
Regarding claim 19, Prashanth discloses a method comprising ([col 1 lines 35-40] shows a hub may be a gateway router between the client and a remote hub to a destination client; [col 20 lines 36-43] shows a software-defined wide area network (SD-WAN) facilitating a secure tunnel between the first hub and the second hub):
receiving a first forward flow packet in a forward flow, the first forward flow packet including a plurality of static header field values in a plurality of static header fields ([col 2 lines 35-43] shows a first flow identifier is assigned to the sequence of packets of the flow. A first start packet of the sequence of packets is encapsulated in a wrapper. The wrapper includes the first flow identifier. The encapsulated first start packet of the sequence of packets is sent from the first hub to the second hub through the secure tunnel; [col 9 lines 62-67; col 10 lines 10-15] shows an Internet Protocol version 4 (IPv4) header 300 is divided into mutable and immutable fields. The source address, destination address, protocol fields, version, Header Length, Length fields do not change);
storing, in a flow table, a forward flow table entry and a reverse flow table entry in response to receiving the first forward flow packet ([Fig 8 and [col 13 lines 5-10; col 14 lines 62-64] show the flow identifier 51 is for use with packets from the first hub 834 to the second hub 836 (e.g., forward flow). For packets in the opposite direction (e.g., reverse flow), a second flow identifier 22 will be used; [col 24 lines 53-55] shows the session tables may be updated in response to flow identifiers from other hubs),
the forward flow table entry corresponding to a forward flow value and for the forward flow including the plurality of static header field values, the reverse flow table entry corresponding to a reverse flow value and including the plurality of static header fields ([col 10 lines 10-15] shows an Internet Protocol version 4 (IPv4) header 300 is divided into mutable and immutable fields. The source address, destination address, protocol fields, version, Header Length, Length fields do not change); and
sending, to a remote tunnel endpoint, a first encapsulating packet that includes the forward flow value and the first forward flow packet ([col 2 lines 35-43] shows a first flow identifier is assigned to the sequence of packets of the flow. A first start packet of the sequence of packets is encapsulated in a wrapper. The wrapper includes the first flow identifier. The encapsulated first start packet of the sequence of packets is sent from the first hub to the second hub through the secure tunnel; Fig 8 and [col 13 lines 5-10] show the flow identifier 51 is for use with packets from the first hub 834 to the second hub 836); and
using the reverse flow table entry to recover a reverse flow packet in response to receiving, from the remote tunnel endpoint, a second encapsulating packet that includes the reverse flow value, wherein the static header fields of the reverse flow packet are omitted from the second encapsulating packet ([col 9 lines 62-67; col 10 lines 10-15] shows an Internet Protocol version 4 (IPv4) header 300 is divided into mutable and immutable fields. The source address, destination address, protocol fields, version, Header Length, Length fields do not change. After the first packet with the IPv4 header, the values for these fields do not need to be sent again and the fields can be removed. By contrast, the values of the Type of Service (TOS), Identifier, Flag, Offset, and Time to Live (TTL) fields may change with each packet and are included in each packet. These values may be combined, compressed, and otherwise reduced in size. The reduced number of fields may be sent as is or converted into a metadata portion of an encapsulated packet; [Fig 8 and [col 13 lines 5-10; col 14 lines 62-64] show for packets in the opposite direction (e.g., reverse flow), a second flow identifier 22 will be used).
Regarding claim 20, Prashanth as applied to claim 19 discloses:
sending, in response to receiving a bandwidth saving allowed indication from the remote tunnel endpoint, a third encapsulating packet, ([col 23 lines 18-27] shows establishing the secure tunnel includes establishing a session and the process includes encapsulating a start packet of the sequence of packets in a wrapper that includes the flow identifier and the header of the encapsulated start packet. Sending the encapsulated start packet from the first hub to the second hub through the secure tunnel is performed. After the start packet is successfully received by the second hub, then receiving an acknowledgement of the flow identifier from the second hub and updating a state of the session with the acknowledgement is performed; [col 18 lines 24-42] shows the second host encapsulates and sends 916 the encapsulated reply start packet from the second host with a wrapper that includes an indication that it has learned the remote flow identifier, the flow identifier assigned by the first hub 904. When the reply start packet arrives at the first hub, the first hub is able to update its session object with the flow learnt status as true. When a second packet is sent 918 from the first host to the second host 908, the first hub 904 is able to use the established session and flow identifier to send 919 reduced packets through the SD-WAN),
the third encapsulating packet including the forward flow value and a plurality of dynamic fields of a second forward flow packet of the forward flow, wherein the static header fields of the second forward flow packet are omitted [immutable fields removed] from the third encapsulating packet ([col 9 lines 15-38] shows the second packet of the subsequent packets 206 from the client 110 may be another packet that all share the same source IP address and the same destination IP address. The encapsulated packet 218 may include the flow identifier 220 to identify the second packet of the subsequent packets 206 as being a part of the sequence of packets. The immutable fields may be removed. The same approach may also be used for packets from the remote server 112 to the client 110 in which a flow identifier 220 is associated with the sequence of packets and subsequent packets from the second branch node 104 to the first branch node 102 are sent with reduced overhead. By recovering all of the fields to the IP header of the second packet 208 to the remote server 112, the remote server 112 is able to communicate without any change in its operation and without any adjustment for the secure tunnel 122 or the flow identifiers 220.)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAN DOAN whose telephone number is (571)270-0162. The examiner can normally be reached Monday - Friday 8am - 5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Oscar Louie, can be reached at (571) 270-1684. 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.
/TAN DOAN/Primary Examiner, Art Unit 2445
Prosecution Insights