Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/31/2026 has been entered.
Claims 1, 3-6, 8-11, 13-16, and 18-24 are pending and ready for examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The Examiner has reviewed the Applicant’s arguments submitted on 3/31/2026 (Pages 7 -11) in their entirety. The arguments are not persuasive.
The Examiner notes that the present rejection is made under 35 U.S.C. 103, not under 35 U.S.C. 102, Accordingly, the issue is not whether a single reference expressly discloses every claimed limitation arranged exactly as claimed. Rather the issue is whether the claimed subject matter as a whole would have been obvious to one of ordinary skill in the art in view of the applied teachings, the differences identified by the Examiner, and the articulated rationale for the proposed combination/modification. Applicant’s arguments appear to characterize the applied references as if each reference must individually anticipate the claim, or as if one of ordinary skill in the at would be incapable of applying express teachings of the references to solve the problem addressed by the claim. Such an approach does not properly address the obviousness rejection, which is based on what the combined teachings would have reasonably suggested to one of ordinary skill in the art, including the ordinary inferences and implementation choices that such a person would have made.
The Applicant states (Page 9)
PNG
media_image1.png
409
792
media_image1.png
Greyscale
Applicant states that Radley teaches only a “binary skip-or-don’t skip mechanism” based on whether a PR’s dynamic credits are exhausted. Examiner respectfully disagrees, because Applicant mischaracterizes the operation of Radley and separates the skip decision from the very capacity-based credit mechanism that causes the skip decision.
Radley’s mechanism is capacity based. Radley expressly teaches that total credits value of zero indicates that the PR “has insufficient capacity” and is not seeking to receive further new flows. Thus, the credit value is not an arbitrary binary flag unrelated to capacity. The credit value represents whether the PR has available processing capacity to receive additional work, and the load balancer uses that capacity-indicating value to determine whether new flows/work packages should be assigned to that PR. When the PR has exhausted residual credits, the PR is passed over; when the PR has available credits, the PR remains eligible to receive new work. Operationally, that is exactly a load balancing function that directs fewer new flows/traffic to a PR having less availability capacity than other PRs.
Applicant’s arguments is also not commensurate with the scope of the claim. For example, Applicant argues that Radley does not compare or rank the “inherent capacities” of endpoints. However, the claim do not recite comparing inherent capacities, ranking endpoints by inherent capacity, or requiring a particular comparison algorithm. The claim recites directing fewer received packets to endpoints having smaller capacity than other endpoints. Radley teaches that result by using capacity-indicating credit values/spare processing capacity in its load balancing allocation, such that a PR with reduced or exhausted capacity-indicating credits receives fewer new flows/traffic than other PRs that remain eligible to receive new flows/traffic.
Features not recited not recited in the claim cannot be relied upon to distinguish the claim from the prior art. See MPEP 2145 (VI); In re Van Geuns, 998 F.2d 1181 (Fed. Cir. 1993)
Moreover, Sorenson (US 40056146) provides for one of ordinary skill in the art to contemplate Applicant’s newly amended claim. Sorenson states ([0048]):
[0048] As indicated at 20, the load balancer node layer randomly selects a destination node and forwards the connection request to the selected destination node. The destination node may, for example, be one of a plurality of server nodes 130 fronted by the load balancer. In at least some embodiments, a load balancer node 110 in the load balancer layer may randomly select a server node 130 to receive a connection request from among all known server nodes 130. However, other methods than purely random selection from among all known server nodes 130 may be used in some embodiments to select server nodes 130 to receive the connection requests. For example, in some embodiments, information about the server nodes 130 may be used by the load balancer nodes 110 to weight the random selection of server nodes 130. As an example, if the load balancer nodes 110 know that different server nodes 130 are different types of devices or are configured with different CPUs and thus have different capabilities or capacities, the information may be used to bias the random selection towards (or away from) particular type(s) or configuration(s) of server node 130.
Paragraph [0048] supports asymmetric load balancing because the load-balancing selection is not equal across endpoints; it can be biased based on endpoint capability or capacity, so a smaller capacity endpoint receives fewer selected connections/flows/traffic than higher-capacity endpoints.
The applied references (Radley and Sorenson) teach using endpoint capacity or available processing capacity in a load balancing function to bias or reduce assignment of new requests/flows/traffic to endpoints having smaller capacity than other endpoints, thereby directing fewer packets/traffic to the smaller-capacity endpoints.
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, 6, 11, and 16 are rejected under 35 USC 102(a)(2) as being unpatentable over Coddington (US 11,416,432) in view of Radley (US 2018/0091589)
Regarding claim 1, Coddington discloses a method for allocating a traffic load through a network, the method implemented by a network traffic management system comprising one or more network traffic apparatuses, client devices, or server devices, the method comprising:
extracting headers from received packets of a traffic flow (Coddington; Coddington packets of a traffic flow are inherently extracted to support the subsequent application of a hashing function of headers of the packet;
see e.g. Column 6, Lines 63 – 66 “... A network flow is identified by the endpoints which are communicated via the network flow. However the number of specific details and the size of the of the specific details that identify the endpoints depend on the protocol the endpoints are using to communicate.
see e.g. Column 7, Lines 7 – 18 “... a hash is formed over the characterizing identifiers, referred to as a flow hash 1005, The flowhash is a pseudo-random number generated in response to the fields (e.g., a source IP address 1110, a destination IP address 1112, a source port number 1114, a destination port number 1116, in an Ethernet packet 1102, an IP packet 1104, and a TCP packet 1106 ..”),
executing a hashing function on at least one of the headers to generate an index for a corresponding one of the received packets (Coddington;
see e.g. Column 7, Lines 7 – 18 “... a hash is formed over the characterizing identifiers, referred to as a flow hash 1005, The flowhash is a pseudo-random number generated in response to the fields (e.g., a source IP address 1110, a destination IP address 1112, a source port number 1114, a destination port number 1116, in an Ethernet packet 1102, an IP packet 1104, and a TCP packet 1106 ..”
see e.g. Column 33, Line 14 – 17 “... flow hash indexes ... “),
applying a load balancing function to select a corresponding one of a plurality of endpoints to send at least one of received packets based on a size of capacity of at least one of the plurality of endpoints (Coddington; Coddington teaches load balancing based upon endpoint characteristics comprising capacity;
see e.g. Column 24, Line 43 – Column 25, Line 7 “ ... the system uses the per-node byte rate counter 1120 and the node status and discovery 1152 via the node status messages 1150 ... node storage capacity .. how full the node’s receive buffer is ... If a node is full, or almost full , the load balancer 900 reassigns the buffer for that node to another encapsulation buffer 1016 ...”
see e.g. Claim 1 “... load balancing on the capture stream of packet records ... receiving a node status message from at least one destination node, wherein the node status message includes dynamic information including a level of fullness of a buffer for the at least one destination node, wherein the relevant data window represents a usable storage capacity of the at least one downstream node .. selecting a destination node for each packet record based on the flow hash and the node status message ...”)
mapping the index for at least one of the received packets to the cat least one of the g endpoint (Coddington;
see e.g. Column 18, Lines 1 – 8 “A flow hash is computed based on a specific “tuple” of network identifier depending on the protocol of the flow ...The intention is that a one-to-one mapping exists between flow and the flow-hash “
see e.g. Column 27, Lines 48-53 “Fig. 13. Illustrates the process of cold node assignment by the cold node assignment lookup table 1156 ... The flow has 1005 of the incoming record is passed through a mapping function f(n) that maps the packets of the flowhash consistently to a smaller number of bins ...”); and
sending at least one of the corresponding ones of the received packets to the corresponding endpoint based on the mapping (Coddington;
see e.g. Column 25, Lines 16 “... the record flow has is looked up in the cold node assignment lookup table .. The flow hash 1005 is passed through a function (such as modulus) which uniformly maps the space of the flow hash to a smaller set of bins, each bin being associated with a node number. The number of bins is at least as many as the number of active destination nodes ...”
see e.g. Column 33, Line 44 – 45 “During the packet storage process, the nodes has stored the packets using index based on timestamp and flow hash key ...”)
Although Coddington teaches load balancing associated with capacity of endpoints, Coddington does not address every single type of load balancing technique (“The description need only describe in detail that which is new or not conventional. See Hybritech v. Monoclonal Antibodies, 802 F.2d at 1384, 231 USPQ at 94. This is equally true whether the claimed invention is directed to a product or a process”) and does not address asymmetrical load balancing in association with capacities and therefore does not expressly disclose:
direct fewer of the received packets to ones of the plurality of endpoints having a smaller capacity than other ones of the plurality of endpoints.
However in analogous art Radley discloses:
direct fewer of the received packets to ones of the plurality of endpoints having a smaller capacity than other ones of the plurality of endpoints (Radley teaches a load balancing function that uses credit values corresponding to available processing capacity to determine whether a particular node should receive additional work. When a node has exhausted residual credits, or when its total credits are set to zero to indicate insufficient spare processing capacity, the load balancer skip that node and assigns then new flow/work package to another node. Thus, the load balancer directs fewer, including zero, new flows/traffic to a node based on the capacity of that node.
Radley’s capacity based distribution of traffic would have led one of ordinary skill in the art to recognize that nodes necessarily possess differing available capacities, thereby meeting the claimed condition of endpoints have smaller capacity than other ones.
Fig. 2 and [0031] of Radley explicitly show a plurality of processing resources (PRs) each having independently tracked residual credits. At a given time, different PRs have different residual credit values (e.g., PR = 0, PR=4, PR=3), where residual credits represent available processing capacity. Radley further disclose skipping PR1 due to zero residual credits while assigning work to PR2. Thus Radley explicitly teaches endpoints having smaller available capacity than other endpoints and directing fewer packets there to.
see e.g. [0031] “In the example of FIG. 2, the next-PR identifier 240 points to PR2 to which the new unit of work should be assigned. Thus, a row 250 for PR1 has been passed over because its residual credits 256 have already been exhausted. The new subscriber 200 will therefore be assigned to PR2. Once the next-PR identifier 240 reaches the end of the list 236, it loops back to the beginning. The ability to skip a PR is useful when the load balancer wants to avoid assignment of further units of work to a particular PR. For example, a total credits value of zero would indicate that the PR is fully loaded (has insufficient spare processing capacity) and is not seeking to receive further new flows (work packages), although it would continue to service flows already assigned to it. In another example, a value of zero could be used by a PR that has been instructed to gracefully spin down once all the current session flows it is handling expire. In the interim, the value of zero would inhibit the PR from being sent any new flows. This ensures that the PRs having a total credits value of zero will be freed up when the workload requirements of the overall system reduce, thereby facilitating true elastic scalability in a VM cloud or server farm. Accordingly, when a PR is to be taken out of service, the load balancer may simply modify the weighted round-robin list 236 to indicate that the particular PR has no spare processing capacity irrespective of its reported processing capacity. In one embodiment, the load balancer changes the value of total or residual credits of the particular PR (e.g., sets it to zero) so as to suppress new-work assignment to the particular PR. In another embodiment, a flag or token is set to indicate the PR should not be assigned new units of work. In yet another embodiment, PRs are instructed to report they seek no new units of work (e.g., report zero total credits)”
Under the broadest reasonable interpretation, “capacity” encompasses metrics indicative of an endpoints ability to handle additional work, including processing capability, bandwidth, memory, or available resources. Measures such as load or utilization reflect the remaining or available capacity of an endpoint and are therefore reasonably considered capacity based metrics.
Examiner notes that said feature represents a matter of routing design optimization of result effective variable, including optimization of ranges, amounts or proportions consistent with KSR and the legal precedent recognized in MPEP 2144.04 and 2144.05))
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate to incorporate Radley’s load balancing scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of load balancing.
Regarding claim 6, claim 6 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 11, claim 11 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 16, claim 16 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 3 – 5, 8-10, 13 -15, and 18 – 20 are rejected under 35 USC 103 as being unpatentable over Coddington in view of Radley and in further view of Venkataraman (US 2020/0304477)
Regarding claim 3, Coddington in view of Radley discloses the method as set forth in claim 1, Coddington does not expressly disclose wherein the load balancing function further comprises:
selecting an intermediate module based on intermediate characteristics of a plurality of intermediate modules: and
determining a route to the corresponding endpoint for the corresponding one of the received packets through the selected intermediate module.
However in analogous art Venkataraman discloses:
selecting an intermediate module based on intermediate characteristics of a plurality of intermediate modules (Venkataraman; Venkataraman teaches within the context of load balancing selecting an intermediated node based on loading characteristics of intermediate node (i.e. intermediate module);
see e.g. [0021] “ ... optimal load balancing ... optimum network capacity utilization...” )
see e.g. [0027] “ ... load balancing algorithm ... each of the said intermediary nodes could be theoretically used – based on the on the load determined to be incumbent thereon – to establish a first hop for the said data packet from the source endpoint device in the direction of the destination endpoint device”) : and
determining a route to the corresponding endpoint for the corresponding one of the received packets through the selected intermediate module (Venkataraman; The selection of the particular intermediate node inherently determines how the network traffic is routed via various hops;
see e.g. [0027] “ ... load balancing algorithm ... each of the said intermediary nodes could be theoretically used – based on the on the load determined to be incumbent thereon – to establish a first hop for the said data packet from the source endpoint device in the direction of the destination endpoint device;
see .e.g [0086] “... a Routing Information Base (RIB) or a routing table ... intermediate node ...”
see e.g. Abstract “The next hop keys are used to encrypt the inner header during the hip to hop communication from one intermediary node to another along the incrementally constructing path connecting the source endpoint device with the destination device ...”
see e.g. [0020] “... determines a data path to be used for transmitting a (particular) data packet ...”
see e.g. [0029] “... traverses at least one intermediary node situated therebetween, with the intermediary node either directly forwarding the data packet to the destination endpoint device or at least in the direction of the endpoint device via a combination of other intermediary n does identified as constituting a data path to the destination ...”
The Examiner notes the technique presented above is readily available to applied to a plurality of technological environments (MPEP 2141.01(a)) comprising packet processors with corresponding ingress and egress ports which have characteristics consisting of load, capacity, and utilization)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Venkataraman’s scheme. The motivation being the combined solution provides for optimizing network traffic efficiencies via intermediate nodes, servers, modules, and packet processor, units and/or modules implanted via conventional silicon technology.
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate to incorporate Radley’s load balancing scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of load balancing.
Regarding claim 4, Coddington in view of Radley and in further view of Venkataraman disclose the method as set forth in claim 3, wherein the load balancing function is applied to select the intermediate module (The combined solution per Venkataraman provides for selecting the intermediate module via a load balancing algorithm;
see e.g. [0027] “ ... load balancing algorithm ... each of the said intermediary nodes could be theoretically used – based on the on the load determined to be incumbent thereon – to establish a first hop for the said data packet from the source endpoint device in the direction of the destination endpoint device”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Venkataraman’s scheme. The motivation being the combined solution provides for optimizing network traffic efficiencies via intermediate nodes, servers, modules, and packet processor, units and/or modules implanted via conventional silicon technology
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate to incorporate Radley’s load balancing scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of load balancing.
Regarding claim 5, Coddington in view of Radley and in further view of Venkataraman disclose the method as set forth in claim 3, wherein the load balancing function does not evenly divide the received packets among the plurality of intermediate modules (The combined solution per Venkataraman provides for random approach to load balance the packets resulting in not evenly dividing the received packets among the plurality of intermediate module;
see e.g. [0021] “... optimal load balancing principles whiles randomizing the data paths traversed by data packets ...”
see e.g. [0028] “ ... the intermediate node ... is selected, at random, albeit form the group of intermediate nodes ...”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Venkataraman’s scheme. The motivation being the combined solution provides for optimizing network traffic efficiencies via intermediate nodes, servers, modules, and packet processor, units and/or modules implanted via conventional silicon technology
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate to incorporate Radley’s load balancing scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of load balancing.
Regarding claim 8, claim 8 comprises the same and/or similar subject matter as claim 3 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 9, claim 9 comprises the same and/or similar subject matter as claim 4 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 10, claim 10 comprises the same and/or similar subject matter as claim 5 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 13, claim 13 comprises the same and/or similar subject matter as claim 3 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 14, claim 14 comprises the same and/or similar subject matter as claim 4 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 15, claim 15 comprises the same and/or similar subject matter as claim 5 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 18, claim 18 comprises the same and/or similar subject matter as claim 3 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 19, claim 19 comprises the same and/or similar subject matter as claim 4 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 20, claim 20 comprises the same and/or similar subject matter as claim 5 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 21 -24 are rejected under 35 USC 103 as being unpatentable over Coddington in view of Radley and in further view of Venkataraman and in further view of Chowdhury (US 8,428,610)
Regarding claim 21, Coddington in view of Radley and in further view of Venkataraman disclose the method as set forth in claim 3, wherein the intermediate module is selected base on sizes of capacity of the plurality of the intermediate modules (The combined solution per Venkataraman provides for selection criteria based on load which may be equivalent and/or extrapolated to a generic capacity and/or utilization within the technological environment (i.e. network capacity, storage capacity, memory capacity, bandwidth utilization, etc..) ;
see e.g. [0027] “ ... load balancing algorithm ... each of the said intermediary nodes could be theoretically used – based on the on the load determined to be incumbent thereon – to establish a first hop for the said data packet from the source endpoint device in the direction of the destination endpoint device”
see e.g. [0021] “... load balancing principles ... ensures optimum network security as well as optimum network capacity utilization” )
As evidence of the above rationale, Chowdhury disclose:
capacity (Chowdhury within the capacity of network traffic teaches the relationship between load and capacity in technological environment comprising computing resources;
see e.g. Claim 1 “... determine a load capacity value based on the load conditions, the load conditions including information regarding at least one of processing unit, memory usage ....”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective fling date of the claimed invention to incorporate Chowdhury’s determination scheme. The motivation being the combined solution provides for one of ordinary skill in the art to synthesize load data as needed resulting in increased efficiencies of optimizing network traffic.
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Venkataraman’s scheme. The motivation being the combined solution provides for optimizing network traffic efficiencies via intermediate nodes, servers, modules, and packet processor, units and/or modules implanted via conventional silicon technology
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate to incorporate Radley’s load balancing scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of load balancing.
Regarding claim 22, claim 22 comprises the same and/or similar subject matter as claim 21 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 23, claim 23 comprises the same and/or similar subject matter as claim 21 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 24, claim 24 comprises the same and/or similar subject matter as claim 21 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 1, 11, and 16 are rejected under 35 USC 102(a)(2) as being unpatentable over Coddington (US 11,416,432) in view of Sorenson (US 20140310390)
Regarding claim 1, Coddington discloses a method for allocating a traffic load through a network, the method implemented by a network traffic management system comprising one or more network traffic apparatuses, client devices, or server devices, the method comprising:
extracting headers from received packets of a traffic flow (Coddington; Coddington packets of a traffic flow are inherently extracted to support the subsequent application of a hashing function of headers of the packet;
see e.g. Column 6, Lines 63 – 66 “... A network flow is identified by the endpoints which are communicated via the network flow. However the number of specific details and the size of the of the specific details that identify the endpoints depend on the protocol the endpoints are using to communicate.
see e.g. Column 7, Lines 7 – 18 “... a hash is formed over the characterizing identifiers, referred to as a flow hash 1005, The flowhash is a pseudo-random number generated in response to the fields (e.g., a source IP address 1110, a destination IP address 1112, a source port number 1114, a destination port number 1116, in an Ethernet packet 1102, an IP packet 1104, and a TCP packet 1106 ..”),
executing a hashing function on at least one of the headers to generate an index for a corresponding one of the received packets (Coddington;
see e.g. Column 7, Lines 7 – 18 “... a hash is formed over the characterizing identifiers, referred to as a flow hash 1005, The flowhash is a pseudo-random number generated in response to the fields (e.g., a source IP address 1110, a destination IP address 1112, a source port number 1114, a destination port number 1116, in an Ethernet packet 1102, an IP packet 1104, and a TCP packet 1106 ..”
see e.g. Column 33, Line 14 – 17 “... flow hash indexes ... “),
applying a load balancing function to select a corresponding one of a plurality of endpoints to send at least one of received packets based on a size of capacity of at least one of the plurality of endpoints (Coddington; Coddington teaches load balancing based upon endpoint characteristics comprising capacity;
see e.g. Column 24, Line 43 – Column 25, Line 7 “ ... the system uses the per-node byte rate counter 1120 and the node status and discovery 1152 via the node status messages 1150 ... node storage capacity .. how full the node’s receive buffer is ... If a node is full, or almost full , the load balancer 900 reassigns the buffer for that node to another encapsulation buffer 1016 ...”
see e.g. Claim 1 “... load balancing on the capture stream of packet records ... receiving a node status message from at least one destination node, wherein the node status message includes dynamic information including a level of fullness of a buffer for the at least one destination node, wherein the relevant data window represents a usable storage capacity of the at least one downstream node .. selecting a destination node for each packet record based on the flow hash and the node status message ...”)
mapping the index for at least one of the received packets to the cat least one of the g endpoint (Coddington;
see e.g. Column 18, Lines 1 – 8 “A flow hash is computed based on a specific “tuple” of network identifier depending on the protocol of the flow ...The intention is that a one-to-one mapping exists between flow and the flow-hash “
see e.g. Column 27, Lines 48-53 “Fig. 13. Illustrates the process of cold node assignment by the cold node assignment lookup table 1156 ... The flow has 1005 of the incoming record is passed through a mapping function f(n) that maps the packets of the flowhash consistently to a smaller number of bins ...”); and
sending at least one of the corresponding onse of the received packets to the corresponding endpoint based on the mapping (Coddington;
see e.g. Column 25, Lines 16 “... the record flow has is looked up in the cold node assignment lookup table .. The flow hash 1005 is passed through a function (such as modulus) which uniformly maps the space of the flow hash to a smaller set of bins, each bin being associated with a node number. The number of bins is at least as many as the number of active destination nodes ...”
see e.g. Column 33, Line 44 – 45 “During the packet storage process, the nodes has stored the packets using index based on timestamp and flow hash key ...”)
Although Coddington teaches load balancing associated with capacity of endpoints, Coddington does not address every single type of load balancing technique (“The description need only describe in detail that which is new or not conventional. See Hybritech v. Monoclonal Antibodies, 802 F.2d at 1384, 231 USPQ at 94. This is equally true whether the claimed invention is directed to a product or a process”) and does not address asymmetrical load balancing in association with capacities and therefore does not expressly disclose:
direct fewer of the received packets to ones of the plurality of endpoints having a smaller capacity than other ones of the plurality of endpoints.
However in analogous art Sorenson discloses:
direct fewer of the received packets to ones of the plurality of endpoints having a smaller capacity than other ones of the plurality of endpoints.(Sorenson; Sorenson teaches
asymmetric load balancing because the load-balancing selection is not equal across endpoints; it can be biased based on endpoint capability or capacity, so a smaller capacity endpoint receives fewer selected connections/flows/traffic than higher-capacity endpoints. Operationally , Sorenson’s capacity based biasing is the mechanism that causes fewer received packets/traffic to be directed to the smaller-capacity endpoint. Sorenson does merely disclose a generic preference or abstract weighting Sorenson teaches using endpoint /server-node capability or capacity information in the load-balancing selection itself. Therefore when one endpoint has smaller capacity than other endpoints, one of ordinary sill int eh art is readily able to execute a biased load balancing selection to reduce selection of that smaller capacity endpoint relative to higher capacity endpoints. Because the selected endpoint is the endpoint to which the corresponding received traffic is directed, selecting the smaller capacity endpoint fewer times results in fewer of the received packets/traffic being directed to that endpoint. Thus, Sorenson teaches directing fewer of the received packets to ones of the plurality of endpoints having a smaller capacity the other ones of the plurality of endpoints
see e.g. [0048] As indicated at 20, the load balancer node layer randomly selects a destination node and forwards the connection request to the selected destination node. The destination node may, for example, be one of a plurality of server nodes 130 fronted by the load balancer. In at least some embodiments, a load balancer node 110 in the load balancer layer may randomly select a server node 130 to receive a connection request from among all known server nodes 130. However, other methods than purely random selection from among all known server nodes 130 may be used in some embodiments to select server nodes 130 to receive the connection requests. For example, in some embodiments, information about the server nodes 130 may be used by the load balancer nodes 110 to weight the random selection of server nodes 130. As an example, if the load balancer nodes 110 know that different server nodes 130 are different types of devices or are configured with different CPUs and thus have different capabilities or capacities, the information may be used to bias the random selection towards (or away from) particular type(s) or configuration(s) of server node 130.
Under the broadest reasonable interpretation, “capacity” encompasses metrics indicative of an endpoints ability to handle additional work, including processing capability, bandwidth, memory, or available resources. Measures such as load or utilization reflect the remaining or available capacity of an endpoint and are therefore reasonably considered capacity based metrics
Examiner notes that said feature represents a matter of routing design optimization of result effective variable, including optimization of ranges, amounts or proportions consistent with KSR and the legal precedent recognized in MPEP 2144.04 and 2144.05))”
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate to incorporate Sorenson’s load balancing scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of load balancing. Moreover, Sorenson supplies both the condition and the rule: the condition is endpoints having different capabilities or capacities, and the rule is biasing load balancing selection based on those capabilities or capacities. When that rule is applied to endpoints of unequal capacity, the smaller capacity endpoint, is selected less often relative to the higher-capacity endpoints, which operationally directs fewer of the received packets/traffic to the smaller-capacity endpoint. The particular amount of reduced selection is merely routine optimization of the capacity based load balancing variable under KSR and MPEP 2144.04 and 2144.05.
Regarding claim 11, claim 11 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale.
Regarding claim 16, claim 16 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to TODD L. BARKER whose telephone number is (571) 270 0257. The Examiner can normally be reached on Monday through Friday, 7:30am to 5:00pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's supervisor Vivek Srivastava can be reached on (571) 272 7304.
/TODD L BARKER/Primary Examiner, Art Unit 2449