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 responsive to a response filed on April 6th, 2026. In this office action:
Claims 21-40 are pending.
Claims 21-40 are rejected.
Response to Amendment
The amendments filed on April 6th, 2026 have been entered.
Claims 21, 23-29, 31-33, 35-38, and 40 have been amended.
The previously raised claim objections are withdrawn in light of the amendments.
Response to Arguments
Applicant’s arguments filed on April 6th, 2026 have been fully considered, but are moot in view of the new grounds of rejection, as presented in this Office Action.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 21-40 are rejected under 35 U.S.C. 103 as being unpatentable over Thubert et al. (Patent No. US 7,328,237), hereinafter Thubert; in view of Boutros et al. (Pub. No. US 2022/0021615), hereinafter Boutros.
Claim 21. Thubert discloses [a] method, applied to a network device (“load balancing device 106,” See Fig. 1. See also Col. 10 lines 26-50 and Fig. 6), the method comprising:
receiving a first packet sent by a client (See Col. 8 lines 1-11 and Fig. 4; a packet is received from a client), wherein the first packet comprises target identification information, wherein the target identification information identifies a target destination (See Col. 8 lines 12-26 and Fig. 4; Upon receiving the packet, the load balancer may identify source-side information which has been encoded or embedded into the destination IP address field of the received packet ... the load balancer identifies the cluster address portion of the destination IP address), wherein the target destination is selected for the client from N candidate destinations by the network device based on a traffic identifier received from the client, wherein the target identification information is obtained by the network device based on the selected target destination, and wherein N is an integer greater than 0 (See Col. 8 lines 25-59 and Fig. 4; A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server (target destination) which has been assigned to that particular flow may be identified using information in the Connection Key Table. See also Col. 5 lines 35-57. Examiner’s note: The server cluster includes one or more servers (N candidate destinations and N is an integer greater than 0)); and
determining a selected target destination based on the target identification information, and forwarding the first packet to the target destination, to trigger the target destination to process the first packet (See Col. 8 lines 25-59 and Fig. 4; the load balancer identifies the cluster address portion of the destination IP address. A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table. Thereafter, the received packet may be forwarded to the identified server for handling (to trigger the target destination to process the first packet)).
Thubert doesn’t explicitly disclose the traffic identifier received from the client in a second packet.
However, Boutros discloses a traffic identifier received from the client in a second packet (See Parag. [0058]; identifying the destination internal IPv4 address includes, for a first packet of a particular flow (the second packet), performing a load balancing operation to select a destination machine ... Once the destination machine is selected, the distributed LB instance, in some embodiments, creates a record in the middlebox service record storage to identify the destination IPv4 header values for subsequent packets (the first packet) of the particular flow).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the traffic identifier, taught by Thubert, to be received from the client in a second packet, as taught by Boutros. This would be convenient to solve the bottleneck and misdirection issues for providing middlebox services such as SNAT and stateful load balancing (Boutros, Parag. [0002]).
Claim 22. Thubert in view of Boutros discloses [t]he method according to claim 21,
Thubert further discloses wherein determining the target destination based on the target identification information, and forwarding the first packet to the target destination comprises:
determining, based on a destination information table (“Connection Key Table”) and the target identification information, target routing information corresponding to the target destination, wherein the destination information table comprises a mapping relationship between identification information of the N candidate destinations and corresponding routing information (See Col. 8 lines 25-52 and Fig. 4; the load balancer identifies the cluster address portion of the destination IP address. A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc ...); and
forwarding the first packet to the target destination based on the target routing information (See Col. 8 lines 25-59 and Fig. 4; if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table. Thereafter, the received packet may be forwarded to the identified server for handling).
Claim 23. Thubert in view of Boutros discloses [t]he method according to claim 22,
Thubert disclose the method further comprising: wherein the selecting one of the N candidate destinations comprises selecting one of the N candidate destinations for the client as the target destination based on the traffic identifier (See Col. 8 lines 12-59 and Fig. 4; the load balancer may also identify additional source-side information which has also been embedded in to other portions of the packet header such as, for example, the flow label field of the packet header ... A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server (target destination) which has been assigned to that particular flow may be identified using information in the Connection Key Table).
Thubert doesn’t explicitly disclose before receiving the first packet sent by the client, receiving the second packet sent by the client, wherein the second packet comprises the traffic identifier, and the traffic identifier comprises one or more of the following information: a triplet of the second packet, a quintuple of the second packet, a flow label of the second packet, or a service identifier of the second packet.
However, Boutros discloses before receiving the first packet sent by the client, receiving the second packet sent by the client, wherein the second packet comprises the traffic identifier, and the traffic identifier comprises one or more of the following information: a triplet of the second packet, a quintuple of the second packet, a flow label of the second packet, or a service identifier of the second packet (See Parag. [0058]; identifying the destination internal IPv4 address includes, for a first packet of a particular flow (the second packet), performing a load balancing operation to select a destination machine (either on the same host computer or on a different host computer) ... Once the destination machine is selected, the distributed LB instance, in some embodiments, creates a record in the middlebox service record storage to identify the destination IPv4 header values for subsequent packets (the first packet) of the particular flow. For subsequent packets in a flow destined to the LB VIP, the lookup in the middlebox service record storage is based on a set of at least one other IPv4 header values (e.g., source IP, source port, source IP/port, etc.). See Parag. [0052]; load balancing service for distributing requests received from clients ...).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the load balancer, taught by Thubert, to include before receiving the first packet sent by the client, receiving the second packet sent by the client, wherein the second packet comprises the traffic identifier, and the traffic identifier comprises one or more of the following information: a triplet of the second packet, a quintuple of the second packet, a flow label of the second packet, or a service identifier of the second packet, as taught by Boutros. This would be convenient to solve the bottleneck and misdirection issues for providing middlebox services such as SNAT and stateful load balancing (Boutros, Parag. [0002]).
Claim 24. Thubert in view of Boutros discloses [t]he method according to claim 23, further comprising:
Thubert doesn’t explicitly disclose based on the selected target destination, obtaining the target identification information, and adding the target identification information to the second packet; and sending the second packet that carries the target identification information to the target destination, wherein sending the second packet triggers the target destination to generate a response packet that carries the target identification information, wherein the response packet is a response packet for the second packet.
However, Boutros discloses:
based on the selected target destination, obtaining the target identification information, and adding the target identification information to the second packet; and sending the second packet that carries the target identification information to the target destination, to trigger the target destination to generate a response packet that carries the target identification information, wherein the response packet is a response packet for the second packet (See Parag. [0058-0059]; Once the internal IPv4 address and port have been identified, the distributed middlebox service replaces (at 550) the external IPv4 address and port with the identified internal IPv4 address and port. The packet is then forwarded (at 560) to the destination machine based on the internal IPv4 address and port. In some embodiments, the packet is forwarded (at 560) through a logical switch that connects the destination machine to the distributed middlebox service instance ...).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the load balancer, taught by Thubert, to include based on the selected target destination, obtaining the target identification information, and adding the target identification information to the second packet; and sending the second packet that carries the target identification information to the target destination, to trigger the target destination to generate a response packet that carries the target identification information, wherein the response packet is a response packet for the second packet, as taught by Boutros. This would be convenient to solve the bottleneck and misdirection issues for providing middlebox services such as SNAT and stateful load balancing (Boutros, Parag. [0002]).
Claim 25. Thubert in view of Boutros discloses [t]he method according to claim 23,
Thubert further discloses wherein selecting one of the N candidate destinations as the target destination based on the traffic identifier comprises:
searching a computing routing table corresponding to the N candidate destinations, and obtaining computing information of each of the N candidate destinations; and selecting one of the N candidate destinations as the target destination based on the computing information of each of the N candidate destinations (See Col. 8 lines 25-59 and Fig. 4; A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table), wherein the computing information of each respective candidate destination comprises one or more of current load status information or network quality information of the respective candidate destination (See also Col. 3 lines 30-35; Quality of Service (QoS) processing may also be performed on the first packet using the identified source-side information).
Claim 26. Thubert in view of Boutros discloses [t]he method according to claim 25,
Thubert discloses the method further comprising: receiving a computing route sent by each of the N candidate destinations, wherein each computing route comprises the computing information and the routing information of the respective candidate destination; and generating the computing routing table, wherein the computing routing table comprises the computing information and the routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc. Examiner’s interpretation: The Connection Key Table is generated to include the routing information).
Claim 27. Thubert in view of Boutros discloses [t]he method according to claim 26,
Thubert further discloses wherein each respective computing information further comprises identification information of the respective candidate destination, and the method further comprises: generating the destination information table based on the identification information and the respective routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc.).
Claim 28. Thubert in view of Boutros discloses [t]he method according to claim 26, further comprising:
Thubert further discloses generating identification information of each of the N candidate destinations according to a preset algorithm, and generating the destination information table based on the identification information and the respective routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc.).
Claim 29. Thubert in view of Boutros discloses [t]he method according to claim 23, further comprising:
Thubert further discloses establishing a temporary session table, wherein the temporary session table comprises a mapping relationship between the traffic identifier of the client and the respective target routing information (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc. Examiner’s note: The Examiner reasonably interprets the maintained local Connection Key Table by the load balancer as being temporary as the table is modified based on new data (See Col. 8 lines 60-67 and Col. 9 lines 1-15));
receiving a pseudo initial packet sent by the client, wherein the pseudo initial packet comprises the traffic identifier of the client (See Col. 5 lines 35-57; although some of the source-side information described above may be included in subsequent HTTP requests from the client, it may be advantageous to embed selected source-side information into the destination IP address of earlier packets in order to allow the load balancer to select the most appropriate server for responding to subsequent client requests);
determining, based on the traffic identifier in the pseudo initial packet and the temporary session table, the target routing information corresponding to the traffic identifier in the pseudo initial packet; and sending the pseudo initial packet to the target destination based on the target routing information, to trigger the target destination to process the pseudo initial packet (See Col. 8 lines 25-59 and Fig. 4; the load balancer identifies the cluster address portion of the destination IP address. A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table. Thereafter, the received packet may be forwarded to the identified server for handling).
Claim 30. Thubert in view of Boutros discloses [t]he method according to claim 21,
Thubert further discloses wherein the target destination comprises one or more of a multi-access edge computing (MEC) site, a data center, a server, or a service instance (See Col. 8 lines 25-59 and Fig. 4; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster), and the network device comprises one or more of a user-side network gateway or a user ingress router (See Col. 9 lines 29-33; the load balancer may function as a common router in forwarding the packets from the client to their final destination).
Claim 31. Thubert discloses [a] network device (“load balancing device 106,” See Fig. 1. See also Col. 8 lines 1-11) comprising:
one or more memories storing instructions; and one or more processors coupled to the one or more memories and configured to execute the instructions, wherein execution of the instructions causes the network device (See Fig. 6 and Col. 10 lines 26-50) to:
receive a first packet sent by a client (See Col. 8 lines 1-11 and Fig. 4; a packet is received from a client), wherein the first packet comprises target identification information, wherein the target identification information identifies a target destination (See Col. 8 lines 12-26 and Fig. 4; Upon receiving the packet, the load balancer may identify source-side information which has been encoded or embedded into the destination IP address field of the received packet ... the load balancer identifies the cluster address portion of the destination IP address), the target destination is selected for the client from N candidate destinations by the network device based on a traffic identifier received from the client, wherein the target identification information is obtained by the network device based on the selected target destination, and wherein N is an integer greater than 0 (See Col. 8 lines 25-59 and Fig. 4; A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server (target destination) which has been assigned to that particular flow may be identified using information in the Connection Key Table. See also Col. 5 lines 35-57. Examiner’s note: The server cluster includes one or more servers (N candidate destinations and N is an integer greater than 0)); and
determine a selected target destination based on the target identification information, and forwarding the first packet to the target destination, to trigger the target destination to process the first packet (See Col. 8 lines 25-59 and Fig. 4; the load balancer identifies the cluster address portion of the destination IP address. A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table. Thereafter, the received packet may be forwarded to the identified server for handling (to trigger the target destination to process the first packet)).
Thubert doesn’t explicitly disclose the traffic identifier received from the client in a second packet.
However, Boutros discloses a traffic identifier received from the client in a second packet (See Parag. [0058]; identifying the destination internal IPv4 address includes, for a first packet of a particular flow (the second packet), performing a load balancing operation to select a destination machine ... Once the destination machine is selected, the distributed LB instance, in some embodiments, creates a record in the middlebox service record storage to identify the destination IPv4 header values for subsequent packets (the first packet) of the particular flow).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the traffic identifier, taught by Thubert, to be received from the client in a second packet, as taught by Boutros. This would be convenient to solve the bottleneck and misdirection issues for providing middlebox services such as SNAT and stateful load balancing (Boutros, Parag. [0002]).
Claim 32 is taught by Thubert in view of Boutros as described for claim 22.
Claim 33. Thubert in view of Boutros discloses [t]he network device according to claim 32,
Thubert further discloses wherein executing the instructions further causes the network device to:
wherein the instructions that cause the network device to select one of the N candidate destinations comprises instructions that cause the network device to select one of the N candidate destinations as the target destination based on the traffic identifier (See Col. 5 lines 35-57; although some of the source-side information described above may be included in subsequent HTTP requests from the client, it may be advantageous to embed selected source-side information into the destination IP address of earlier packets in order to allow the load balancer to select the most appropriate server for responding to subsequent client requests (a second packet sent by the client)).
Boutros discloses receive the second packet sent by the client, wherein the second packet comprises the traffic identifier, and the traffic identifier comprises one or more of the following information: a triplet of the second packet, a quintuple of the second packet, a flow label of the second packet, or a service identifier of the second packet (See Parag. [0058]; identifying the destination internal IPv4 address includes, for a first packet of a particular flow (the second packet), performing a load balancing operation to select a destination machine (either on the same host computer or on a different host computer) ... Once the destination machine is selected, the distributed LB instance, in some embodiments, creates a record in the middlebox service record storage to identify the destination IPv4 header values for subsequent packets (the first packet) of the particular flow. For subsequent packets in a flow destined to the LB VIP, the lookup in the middlebox service record storage is based on a set of at least one other IPv4 header values (e.g., source IP, source port, source IP/port, etc.). See Parag. [0052]; load balancing service for distributing requests received from clients ...).
Claim 34. Thubert in view of Boutros discloses [t]he network device according to claim 33,
Boutros further discloses wherein executing the instructions further causes the network device to:
based on the selected target destination, obtain the target identification information, and add the target identification information to the second packet; and send the second packet that carries the target identification information to the target destination, to trigger the target destination to generate a response packet that carries the target identification information, wherein the response packet is a response packet for the second packet (See Parag. [0058-0059]; Once the internal IPv4 address and port have been identified, the distributed middlebox service replaces (at 550) the external IPv4 address and port with the identified internal IPv4 address and port. The packet is then forwarded (at 560) to the destination machine based on the internal IPv4 address and port. In some embodiments, the packet is forwarded (at 560) through a logical switch that connects the destination machine to the distributed middlebox service instance ...).
Claim 35. Thubert in view of Boutros discloses [t]he network device according to claim 33,
Thubert further discloses wherein executing the instructions further causes the network device to:
search a computing routing table corresponding to the N candidate destinations, and obtain computing information of each of the N candidate destinations; and select one of the N candidate destinations as the target destination based on the computing information of each of the N candidate destinations (See Col. 8 lines 25-59 and Fig. 4; A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server which has been assigned to that particular flow may be identified using information in the Connection Key Table), wherein the computing information comprises one or more of current load status information or network quality information of a respective candidate destination (See also Col. 3 lines 30-35; Quality of Service (QoS) processing may also be performed on the first packet using the identified source-side information).
Claim 36. Thubert in view of Boutros discloses [t]he network device according to claim 35,
Thubert further discloses wherein executing the instructions further causes the network device to: receive a computing route sent by each of the N candidate destinations, wherein each computing route comprises the computing information and the routing information of the respective candidate destination; and generate the computing routing table, wherein the computing routing table comprises the computing information and the routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc. See also Col. 3 lines 30-35; Quality of Service (QoS) processing may also be performed on the first packet using the identified source-side information. Examiner’s interpretation: The Connection Key Table is generated to include the routing information).
Claim 37. Thubert in view of Boutros discloses [t]he network device according to claim 36,
Thubert further discloses wherein executing the instructions further causes the network device to: generate the destination information table based on the identification information and the respective routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc. Examiner’s interpretation: The Connection Key Table is generated to include the routing information).
Claim 38. Thubert in view of Boutros discloses [t]he network device according to claim 36,
Thubert further discloses wherein executing the instructions further causes the network device to: generate identification information of each of the N candidate destinations according to a preset algorithm, and generate the destination information table based on the identification information and the respective routing information of each of the N candidate destinations (See Col. 8 lines 25-52; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster ... each entry 500 of the Connection Key Table may include information relating to a specific flow between a client and a server including, for example, source IP address information 502, destination IP address information 504, source TCP port information 506, destination TCP port information 508, server ID information 510, etc. Examiner’s interpretation: The Connection Key Table is generated to include the routing information).
Claim 39. Thubert in view of Boutros discloses [t]he network device according to claim 31,
Thubert further discloses wherein the target destination comprises one or more of a multi-access edge computing (MEC) site, a data center, a server, or a service instance (See Col. 8 lines 25-59 and Fig. 4; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster), and the network device comprises one or more of a user-side network gateway or a user ingress router (See Col. 9 lines 29-33; the load balancer may function as a common router in forwarding the packets from the client to their final destination).
Claim 40. Thubert discloses [a] client device comprising: one or more non-transitory memories storing instructions; and one or more processors coupled to the one or more memories and configured to execute the instructions (See Fig. 1 “Client 102”), wherein execution of the instructions causes the client device to:
send a first packet to a network device (“load balancing device 106,” See Fig. 1. See also Col. 8 lines 1-11), wherein the first packet comprises target identification information, the target identification information identifies a target destination (See Col. 8 lines 1-11 and Fig. 4; a packet is received from a client ... See Col. 8 lines 12-26 and Fig. 4; Upon receiving the packet, the load balancer may identify source-side information which has been encoded or embedded into the destination IP address field of the received packet ... the load balancer identifies the cluster address portion of the destination IP address), wherein a selected target destination is selected from N candidate destinations for the client by the network device based on a traffic identifier received from the client, wherein the target identification information is obtained by the network device based on the selected target destination, and wherein N is an integer greater than 0 (See Col. 8 lines 25-59 and Fig. 4; A determination is then made as to whether an entry exists in a local Connection Key Table for the flow associated with the received packet; the load balancer may maintain specific information in a local Connection Key Table which may be used, for example, for associating a specific flow with one or more specific servers in the server cluster (N candidate destinations) ... if it is determined that an entry does exist in the Connection Key Table for the flow associated with the received packet, the server (target destination) which has been assigned to that particular flow may be identified using information in the Connection Key Table. See also Col. 5 lines 35-57. Examiner’s note: The server cluster includes one or more servers (N candidate destinations and N is an integer greater than 0)); and
receive a first response packet sent by the target destination, wherein the first response packet is a response packet for the first packet (See Col. 8 lines 25-59 and Fig. 4; ... the received packet may be forwarded to the identified server for handling. See Col. 9 lines 55-59; servers within a server cluster to respond directly to the clients, if desired, without requiring that the responses be routed through the dispatcher or load balancer on the way back to the clients).
Thubert doessn’t explicitly disclose the traffic identifier received from the client in a second packet.
However, Boutros discloses a traffic identifier received from the client in a second packet (See Parag. [0058]; identifying the destination internal IPv4 address includes, for a first packet of a particular flow (the second packet), performing a load balancing operation to select a destination machine ... Once the destination machine is selected, the distributed LB instance, in some embodiments, creates a record in the middlebox service record storage to identify the destination IPv4 header values for subsequent packets (the first packet) of the particular flow).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the traffic identifier, taught by Thubert, to be received from the client in a second packet, as taught by Boutros. This would be convenient to solve the bottleneck and misdirection issues for providing middlebox services such as SNAT and stateful load balancing (Boutros, Parag. [0002]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Zhang et al. (Pub. No. US 2016/0308770) – Related art in the area of packet processing, (Abstract; A packet processing method, node, and system. An ingress delivery node receives a notification message that is returned by an egress delivery node after the egress delivery node receives a first packet, where the notification message includes modification information carried in the first packet, modifies, according to the modification information, a subsequently received second packet that belongs to a same service flow as the first packet, and sends the modified second packet to the egress delivery node. After modifying the subsequently received second packet that belongs to the same service flow as the first packet, the ingress delivery node directly sends the subsequently received second packet to the egress delivery node such that the second packet does not need to be processed by a service chain between the ingress delivery node and the egress delivery node).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELBASST TALIOUA whose telephone number is (571)272-4061. The examiner can normally be reached on Monday-Thursday 7:30 am - 5:30 pm.
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 on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Abdelbasst Talioua/Primary Examiner, Art Unit 2445
Prosecution Insights