DETAILED ACTION
This action is in response to communication filed on 3/14/2025.
Claims 1-18 are pending.
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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3/14/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 of this title, 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 1-2 and 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Akella et al. (US 2015/0127809) in view of Chivukula et al. (US 2018/0054477).
Regarding claim 1, Akella discloses a traffic distribution method for load-balancing inbound traffic incoming into a plurality of servers, the traffic distribution method being performed by a computing system, wherein the traffic distribution method comprises:
acquiring traffic data on a quantity of inbound traffic to each of the plurality of servers (Akella discloses acquirement quantitative load/traffic data for each of a plurality of parallel resources; [0020] “At step 205, the forwarding engine of the switch retrieves a percentage utilization for each physical link connected to the port-channel. The percentage utilization may be obtained, for example, by polling a port ASIC of each channel member”);
calculating one or more coefficients of variation of the traffic data for a first unit time duration (Akella discloses calculating the coefficient of variation of the traffic/utilization qualities across the parallel resources for a given observation window (the “first unit time duration”); [0022-0026] “At step 220, the switch calculates a mean, variance, and coefficient of variation. As is known, the coefficient of variation is a normalized measure of dispersion of a frequency distribution. To calculate these values...when the percentage utilization of each channel member is equal, the variance, standard of deviation, and coefficient of variation values equal 0. If the coefficient of variation is greater than 0.15, then the measured variance for a given algorithm is high”);
performing a real-time calculation on the coefficient of variation of the traffic data for the first unit time duration to calculate a real-time coefficient of variation (Akella discloses calculating the CV on the current utilization data for each evaluated algorithm. The calculation is performed on the live traffic flows while a current hashing algorithm is in use; [0020] “At step 220, the switch calculates a mean, variance, and coefficient of variation”, [0027] “At step 305, the forwarding engine compares results calculated using each hashing algorithm”); and
performing traffic distribution across the plurality of servers, based on the determination result of whether the traffic distribution imbalance state across the plurality of servers occurs (Akella performs the redistribution of traffic/load once the statistical imbalance determination is made; [0028] “he forwarding engine selects a preferred algorithm by comparing the calculated measures between each hashing algorithm to determine an algorithm that results in a more optimally balanced utilization”).
However, the prior art does not explicitly disclose the following:
an interval average of coefficients of variation for a second unit time duration, and
an interval standard deviation of the coefficients of variation for the second unit time duration, wherein the second unit time duration includes the plurality of first unit time durations;
determining whether a traffic distribution imbalance state across the plurality of servers occurs, based on a result of comparing the real-time coefficient of variation with the interval average and the interval standard deviation.
Chivukula in the field of the same endeavor discloses techniques for statical resource balancing that calculates the mean, variance, and stand deviation of load metrics across cluster nodes. In particular, Chivukula discloses the following:
an interval average of coefficients of variation for a second unit time duration (Chivukula ; [0027] “the load calculation module 212 monitors load metrics and other operating parameters associated with the nodes 220 (e.g., as reported by the nodes 220) to calculate information such as mean, variance, and standard deviation of the expected distribution of loads across the nodes 220 using principles of the Central Limit Theorem”), and
an interval standard deviation of the coefficients of variation for the second unit time duration, wherein the second unit time duration includes the plurality of first unit time durations (Chivukula discloses receiving successive load reports over successive time intervals and computing running/interval mean and standard deviation of those load metrics; [0031] “The load calculation module 212 may calculate the mean and variance for each load metric based on load reports received from the nodes 220”, [0039-0040] “The load calculation module 212 calculates the average or mean consumption of a given load metric”, [0041] “the calculated values may correspond to a running, or moving, average”);
determining whether a traffic distribution imbalance state across the plurality of servers occurs, based on a result of comparing the real-time coefficient of variation with the interval average and the interval standard deviation (Chivukula compares a current/average load metric against an interval derived mean standard deviation threshold to decide whether an imbalance/rebalancing condition exists; [0027] “The calculated standard deviation for a given load metric of a node can then be used to determine a likelihood that the load metric will exceed an associated load capacity. For example, the determination may correspond to a relationship between (i) a difference between an average consumption of a load metric and an associated load capacity and (ii) the standard deviation for the load metric”, [0046] “the load balancing module 216 may trigger a load rebalancing in response to the average load on any load metric of a node being within the number of standard deviations of the load capacity as indicated by the selected policy tolerance value (i.e., in response to the average load exceeding a value 1 standard deviation from the load capacity, 2 standard deviations from the load capacity, etc.)”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior with Chivukula. One would have been motivated because both references address the same problem of statistically detecting and correcting load imbalances across parallel resources, making it obvious to apply Chivukula’s mean-and-standard-deviation thresholding and rebalancing trigger to the coefficient of variation metric.
Regarding claim 2, Akella-Chivukula discloses the traffic distribution method of claim 1, wherein the coefficient of variation for the first unit time duration is a value obtained by dividing a standard deviation of the inbound traffic incoming into the plurality of servers for the first unit time duration by an average of the inbound traffic incoming into the plurality of servers for the first unit time duration,
wherein the determining of whether the traffic distribution imbalance state across the plurality of servers occurs includes:
calculating a first threshold based on a following Equation 1 (Akella [0025] “the coefficient of variation (CV) may be expressed as: ( CV ) = .sigma. .mu.”); and
determining whether the real-time coefficient of variation exceeds the first threshold: First threshold=(the interval average)+{n*(the interval standard deviation)}, where n is a non-negative integer (Chivukula calculates a threshold of the mathematical form “average + n x standard deviation” (n-1, 2, 3…) and comparing a current/real-time statical metric against that threshold to decide whether an imbalances exist and rebalancing should occur; [0027] “The calculated standard deviation for a given load metric of a node can then be used to determine a likelihood that the load metric will exceed an associated load capacity. For example, the determination may correspond to a relationship between (i) a difference between an average consumption of a load metric and an associated load capacity and (ii) the standard deviation for the load metric”, [0046] “the load balancing module 216 may trigger a load rebalancing in response to the average load on any load metric of a node being within the number of standard deviations of the load capacity as indicated by the selected policy tolerance value (i.e., in response to the average load exceeding a value 1 standard deviation from the load capacity, 2 standard deviations from the load capacity, etc.)”).
Therefore, it would have been obvious to a person of ordinary skill to substitute Akella’s coefficient of variation for the raw load metric in Chivukula’s threshold formula, thereby obtaining first threshold comparison. Motivation to combine is same as claim 1.
Regarding claim(s) 10-11, do(es) not teach or further define over the limitation in claim(s) 1-2 respectively. Therefore claim(s) 10-11 is/are rejected for the same rationale of rejection as set forth in claim(s) 1-2 respectively.
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Akella et al. (US 2015/0127809) in view of Chivukula et al. (US 2018/0054477) in view of Bivens et al. (US 2008/0263206).
Regarding claim 7, Akella-Chivukula discloses the traffic distribution method of claim 1, wherein the performing of the traffic distribution across the plurality of servers includes:
determining a third server to which first inbound traffic received by the computing system is to be transmitted, using a predetermined path selection algorithm (Akella [0028] “At step 315, the forwarding engine selects a preferred algorithm by comparing the calculated measures between each hashing algorithm to determine an algorithm that results in a more optimally balanced utilization”).
However the prior art does not explicitly disclose the following:
determining whether to perform traffic distribution to the third server, with reference to a server weight table,
wherein the server weight table includes information about a server-specific weight of each of the plurality of servers and an average of quantities of the inbound traffic for the first unit time duration of the plurality of servers.
Bivens in the field of the same endeavor discloses techniques to determine the magnitude of weight changes in dynamic load balancing environments based on the workload magnitude and server farm capacity. In particular, Biven teaches the following:
determining whether to perform traffic distribution to the third server, with reference to a server weight table (Bivens [0011] “determine the magnitude of weight changes in dynamic load balancing environments based on the workload magnitude and server farm capacity. That is, the factor by which the actual weights will be changed is based on a "relative workload" metric indicating the ability of the entire server farm to handle the incoming work. This method depends on the development of new multi-system characteristics such as a relative workload metric to characterize the workload of the system relative to the collective capacity of all of the systems of the server farm to handle the workload”),
wherein the server weight table includes information about a server-specific weight of each of the plurality of servers and an average of quantities of the inbound traffic for the first unit time duration of the plurality of servers (Bivens discloses a maintained set of server specific numerical weights (functioning as a server weight table) that the load balancer consults to distribute incoming traffic. The weights are derived from and therefore include information reflecting, the average/volume of the workload (inbound traffic quantities) across the servers. This discloses a server weight table containing both a server specific weight for each server and information based on the average qualities of inbound traffic; [0050] “The relative_workload metric is a representation of the relationship between the current workload and the system's capacity to handle this workload. This metric can be expressed at a high level by the following formula: relative_workload = workload_volume / serverfarm_capacity”, [0064] “To make the actual change relative to the workload and its relationship to the server farm capacity, we will only change the weight by a factor of the weightchange_bound and the relative_workload (740): final_weight.sub.i=old_weight.sub.i+(relative_workload*C)*weightchange_b- ound.sub.i”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with the teaching of Bivens. One would have been motivated because Biven’s dynamic server weight table ( in which higher weights receive a large share of new connections) into the path selection and imbalance detection framework so that overloaded servers can be overridden in favor of the highest weight server.
Regarding claim(s) 16, do(es) not teach or further define over the limitation in claim(s) 7 respectively. Therefore claim(s) 16 is/are rejected for the same rationale of rejection as set forth in claim(s) 7 respectively.
Allowable Subject Matter
Claims 3-6, 8-9, 12-15 and 17-18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
For the reason above, claims 1-18 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
Prosecution Insights