DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 05/27/2026.
Claims 1, 4, 9, 11-15, 17, and 19 have been amended.
Claims 1-3, 5-11, 13-19 and 21-23 are currently pending and have been examined.
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 .
Response to Arguments
Applicant’s arguments filed 05/27/2026 with respect to the rejections under 35 USC § 103 have been considered but are not persuasive.
On pg. 15-16 of the Remarks, Applicant essentially argues:
" Claim 1 requires that the cross-node degree is based on a quantity of operated jobs, cross-node tasks, or network transmission connections…Office Action equates Wang's "bandwidth requirement of zero" to the claimed cross-node degree…Wang's Fig. 4 discloses expected peak traffic rates. However, Wang's Fig. 4 does not disclose a cross-node degree, much less a cross-node degree that is based on a quantity of operated jobs, cross-node tasks, or network transmission connections. Thus, Wang fails to disclose that the cross-node degree is based on a quantity of operated jobs, cross-node tasks, or network transmission connections.."
Examiner respectfully disagrees. Wang specifically discloses their allocation algorithm “seeks to minimize both the nominally allocated network bandwidth and the number of servers in which VMs are placed” (pg. 103, § V, emphasis added). As described on pg. 104, Wang’s greatest preference is for a placement on a candidate server where the entire VM ensemble (n tasks) can be placed on a single server and thus where the ensemble has zero cross-node tasks (and similarly, zero network transmission connections therebetween).
Examiner additionally notes included with action are a number of references (see Conclusion cited but not relied upon) which employ number of connections as a network load metric for nodes with relation to previous discussions regarding the cross-node quantity recited in the claims.
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, 3, 5-9, 11, 13-17, 19, and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over Jayaram et al. (“FfDL: A Flexible Multi-tenant Deep Learning Platform”, ver.: arXiv:1909.06526v1, 09/2019) in view of Wang et al. (“Network-aware Placement of Virtual Machine Ensembles using Effective Bandwidth Estimation”, 2014).
Claims 1, 9, and 17:
Jayaram discloses the limitations as shown in the rejections below:
job scheduling apparatus (FfDL (Fabric for Deep Learning) platform) comprising: a communication interface (API service, REST and/or gRPC endpoint thereof) configured to receive a target job comprising n tasks (pods) (see at least pg. 1, Abstract; pg. 4, Fig. 1; pg. 4-5, § 3.1 - 3.2; pg. 9, § 5).
a processor (executing scheduler/lifecycle manager (LCM)) coupled to the receiver and configured to: perform node filtering in a node cluster based on the n tasks to obtain n candidate node sets, (pg. 6, § 3.5, para. 2-3).
select, from an mth candidate node set corresponding to an mth task in the n tasks, a candidate node with a network transmission performance score (NTPS) that is the highest (highest rank) as a target node of the mth task, wherein the target node is for processing the mth task, wherein the NTPS is based on…a node leisure degree (maximize free resources/pack utilization) (pg. 5-6, § 3.4; pg. 6, § 3.5, para. 2-3). Exemplary quotation:
“we made a decision to use the Pack placement policy, where pods from a DL job are packed (“crammed”) into as few physical machines as possible. We implemented an extension to the K8S scheduler to support Pack. In the scenario outlined above, Pack would place all four jobs on the same machine, leaving three machines free with 4 GPUs/machine (pg. 5, § 3.4, para. 2)…scheduler matches the requested resource demands of all the pods in a DL job (e.g. CPU, memory, GPU, and storage) with the available resources on the nodes…scheduler assigns a node to the pod by (1) filtering the nodes that satisfy the pod resource requirements and other predicate constraints, (2) ranking the candidate nodes based on priority functions, and (3) selecting the node with the highest rank…Since in a DL platform, GPU is typically a scarce resource, the objective is to pack GPU resources. The default filtering and ranking steps are mapped onto node preferences (or biases) for placement of the pods” (pg. 6, § 3.5, para. 2-3).
Jayaram discloses (pg. 5, § 3.4; pg. 11) packing/cramming the tasks into as few nodes as possible when placing (when the n tasks can all be placed in the candidate node) considering CPU, memory, and primarily GPU resources when scoring nodes for task placement but does not describe considering task communication requirements and/or network load as it relates to the nodes (cross-node quantity) or the set of tasks (cross-node degree/) and accordingly does not specifically disclose the remaining limitations.
Wang, however, discloses (pg. 100, Abstract, § I, para. 2-4) an analogous placement scheme “MAPLE” for placing VMs (tasks) of ensembles (jobs) that “seeks to minimize both the nominally allocated network bandwidth and the number of servers in which VMs are placed” (pg. 103, § V); In MAPLE “VM placement decisions are then made taking into account the estimated available residual bandwidth at each server” (pg. 103, Fig. 3) (select the candidate node by determining a cross-node quantity of a candidate node (server/”subtree”) in the mth candidate node set when the candidate node processes another job (VM ensemble) in an operating state (consuming bandwidth)). Wang further elaborates (pg. 103-104) that first “MAPLE attempts to allocate the entire VM ensemble placement request into a same server”, so the VMs of the ensemble have a bandwidth requirement, and a quantity of inter-server network transmission connections (and cross-node tasks), equal zero (cross-node degree of the n tasks) (pg. 103, Fig. 4), and the candidate node/server preferentially selected (larger…NTPS) is the one with the relatively highest bandwidth utilization/smallest “residual bandwidth” (larger cross-node quantity). When the VMs of the ensemble cannot all be placed on the same server and need to be spread out candidate servers with lower network utilization are preferred in proportion to the aggregate bandwidth needed for communication between the subgroups/individual tasks/VMs of the ensemble (smaller cross-node quantity indicates the larger NTPS) (Wang pg. 104, col. 1, para. 4 – pg. 105, col.1, para. 1) . (“When the algorithm cannot find any subtree that can host the entire VM ensemble, it attempts to allocate the requested VMs into different subtrees…whenever a VM request cannot be entirely placed into one subtree (case III), the requesting VMs will be divided into two groups. The aggregate bandwidths needed by each group is determined as the minimum aggregated bandwidths between the two groups”).
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Jayaram’s placement policy with Wang’s network bandwidth aware placement scheme in order to “allocate computing and network resources in a manner that balances efficiency of resource utilization with performance predictability” and increase task throughput (Wang pg. 107, § VII; pg. 100, Abstract).
Claims 3, 11, and 19:
The combination of Jayaram/Wang discloses the limitations as shown in the rejections above. Wang further discloses higher affinity between the n tasks indicates a higher NTPS (pg. 103, col. 2). Jayaram further discloses (pg. 4, § 3.1, para. 2; pg. 6, § 3.5, para. 2; pg. 14, § 6, para. 4) support for jobs which utilize parameter server (PS) architecture comprising parameter server and learner (worker) type tasks (“DL training job typically consists of a set of learning processes (“learners”)…A distributed job may also include one or more parameter servers”), and further discloses selecting the candidate node further comprises: determining a type (e.g. parameter server, learner, helper) of the mth task; and performing first steps…comprise: determining, when the type is a worker node task, whether another one of the n tasks (of the same Job) needs to be placed in a candidate node in the mth candidate node set; increasing, when the worker node task or a parameter node task needs to be placed in the candidate node (can be packed into), the NTPS in at least Jayaram pg. 5-6, § 3.4 – 3.6 disclosing the scheduler identifies all learner pods/tasks of the job that need to be placed and schedules them holistically as group/gang such that they are placed into as few nodes as possible. Exemplary quotation:
“all components of a DL job are scheduled as a gang. In general, a DL job comprises a collection of Kubernetes sets (e.g. stateful sets), where each set is a collection of homogeneous pods where tasks, such as learners and parameter servers, run. In addition to pods, the DL job deployment…We will refer to a scheduler whose function is to place all pods that belong to a DL job onto nodes in the cluster holistically, as a gang scheduler.” (pg. 6, § 3.5).
Claims 5, 13, and 21:
The combination of Jayaram/Wang discloses the limitations as shown in the rejections above. Jayaram further discloses wherein a lower node leisure degree (idleness) indicates a higher NTPS, and wherein the processor is further configured to: determine whether hardware resources that are of a candidate node in the mth candidate node set and that are used for job training are used; and increase, when the hardware resources are used, a NTPS of the candidate node in at least pg. 5-6, § 3.4; pg. 6, § 3.5, para. 3; pg. 9, § 5.2; disclosing that when selecting a node for a pod/task their scheduler employs a “Pack placement policy, where pods from a DL job are packed (“crammed”) into as few physical machines as possible”; and thus prefers (assigns a higher rank/NTPS to) nodes whose hardware resources are used relative to nodes whose resources are idle with a strongest preference for the node with the highest utilization that can still accommodate the pod (a higher allocation rate indicates a larger increasing amplitude for the NTPS).
Claims 6, 14, and 22:
The combination of Jayaram/Wang discloses the limitations as shown in the rejections above. Jayaram further discloses select the candidate node by: determining an allocation rate (utilization) of the hardware resources; and increase the NTPS based on the allocation rate, wherein a higher allocation rate indicates a larger increasing amplitude for the NTPS and a lower allocation rate indicates a smaller increasing amplitude for the NTPS in at least pg. 5-6, § 3.4; pg. 6, § 3.5, para. 3; pg. 9, § 5.2; disclosing that when selecting a node for a pod/task their scheduler employs a “Pack placement policy, where pods from a DL job are packed (“crammed”) into as few physical machines as possible”; and thus has a strongest preference for the node with the highest utilization that can still accommodate the pod (a higher allocation rate indicates a larger increasing amplitude for the NTPS).
Claims 7, 15, and 23:
The combination of Jayaram/Wang discloses the limitations as shown in the rejections above. Jayaram further discloses wherein the n tasks carry hardware resource requirements, wherein the method further comprises further performing the node filtering based on the hardware resource requirement, and wherein hardware resources of the n candidate node sets match the hardware resource requirements (pg. 6, § 3.5, para. 2-3): “scheduler matches the requested resource demands of all the pods in a DL job (e.g. CPU, memory, GPU, and storage) with the available resources on the nodes, finding a set of nodes on to which pods are placed…scheduler assigns a node to the pod by (1) filtering the nodes that satisfy the pod resource requirements and other predicate constraints.”
Claims 8 and 16:
The combination of Jayaram/Wang discloses the limitations as shown in the rejections above. Jayaram further discloses wherein the target job comprises a training job of an artificial intelligence (AI) (Deep Learning (DL)) model (pg. 1, Abstract).
Claims 2, 10, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Jayaram in view of Wang in further view of Gao et al. (“GAI: A Centralized Tree-Based Scheduler for Machine Learning Workload in Large Shared Clusters”, 2018).
Claims 2, 10, and 18:
The combination of Jayaram/Wang discloses the limitations as shown in the rejections above. The combination of Jayaram/Wang does not specifically disclose wherein a higher aggregation degree of the n tasks on the same rack indicates a higher NTPS, and wherein the processor is further configured to further select the candidate node by: determining whether the n tasks can all be placed on a rack on which a candidate node in the mth candidate node set is located.
Gao, however, discloses “Gatekeeper for AI (GAI), a centralized scheduler for ML workload on large shared clusters” (pg. 612, para. 4) analogous to the schedulers of the claims and Jayaram. Gao further discloses (pg. 617-619, § 4 – 4.1) GAI employs rack-aware scheduling which prefers (indicates a higher NTPS) to schedule all the tasks of the same ML to the same machine/server (node) or to the same rack thus discloses determining whether the n tasks can all be placed on a rack on which a candidate node in the mth candidate node set is located; increasing, when the n tasks can all be placed on the rack, a NTPS (preferring placements of the candidate node. Exemplary quotation:
“GAI uses a centralized rack-aware tree scheduling method and maintains a resource tree in memory to place all tasks of the ML training jobs in one machine or in the machines belong to the same rack as far as possible” (pg. 617, last para.)
For clarity, Examiner notes that preferring placement (increasing NTPS) on nodes that belong to the same rack as much as possible inherently teaches avoiding placement (decreasing NTPS) on nodes that belong to a rack that cannot accommodate all the tasks of the job as much as possible.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify Jayaram/Wang to increase the placement rank/score of nodes that allow all the tasks of a ML job to be scheduled to the same rack (and implicitly decrease the rank of those that do not) as taught by Gao to decrease network communication overhead costs when running the ML job (Cao, pg. 616).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Each of US 20090300407 A1; US 20090248865 A1; US 200802257 A1 disclose embodiments which employ connection counts as a load metric.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
08/19/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights