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 Final Office Action is in response to the claim amendment/REMARKS correspondence submitted on 10/01/2025.
Claims 1-20 are pending and rejected.
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in CN on 07/15/2020. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55 on 08/04/2025.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/01/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
First, Applicant’s arguments, see Amendments/REMARKS, filed 10/01/2025, with respect to Claim Objection have been fully considered and are persuasive. The Claim Objection of claim 1 has been withdrawn.
Second, Applicant’s arguments, see Amendment/REMARKS, filed 10/01/2025, with respect to the rejection(s) of claims 1-20 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of amendment of claims requiring further search and inquiry.
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 (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 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 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-7, 9 & 14 are rejected under 35 U.S.C. 103 as being unpatentable by Funabashi et al (US20170005946) in view of Feng et al (USUS20170109204A1), in further view Zink et al (US7957948B2).
Regarding claim 1, Funabashi teaches a method comprising:
creating at least one scheduling task ([0006], [0031]-[0032], [0035]-[0036], receiving a request to perform a group of processes (an application) from a client; Process allocation server allocates the processes to appropriate nodes; The allocation is based on process grouping and bandwidth considerations; the arrangement server executes tasks on allocated nodes—copies of application map to plurality of processes and core nodes map to nodes 50-1 to 50-n); and
executing the scheduling task to allocate a corresponding core node from the code nodes for an application copy from the application copies of the application according to the copy scheduling information ([0006], [0031]-[0032], [0035]-[0036], receiving a request to perform a group of processes (an application) from a client; Process allocation server allocates the processes to appropriate nodes; The allocation is based on process grouping and bandwidth considerations; the arrangement server executes tasks on allocated nodes—copies of application map to plurality of processes and core nodes map to nodes 50-1 to 50-n).
But Funabashi fails to teach copy scheduling information of the application, the copy scheduling information including correspondences between application copies of the application and the core nodes, the core deployment information including a number of CPU cores, a number of the core nodes, and multiple CPU cores corresponding to each of the core nodes.
However, Feng teaches determining, according to a number of copies of an application and core deployment information of core nodes corresponding to a service node, copy scheduling information of the application ([0030]-[0032], [0046]-[0047], teaches multiple instances/copies of an application that a scheduler dispatches; showing the master node (service node) maintains core deployment information for all CPU cores in all cluster nodes; explicitly describes the master node determining per-instance scheduling for the application across nodes using instance history (“copies”) and per-core capability data (core deployment information),
the copy scheduling information including correspondences between application copies of the application and the core nodes ([0032], [0047], Fig 5 & subsequent text, direct teaching that application copies (instances) correspond to different nodes, selection = assignment of instance to specific node/core; migration further shows dynamic re-establish of correspondence between each instance copy and a specific core node),
the core deployment information including a number of CPU cores, a number of the core nodes, and multiple CPU cores corresponding to each of the core nodes ([0030-[0031], [0046], master node can obtain a CPU capability for each CPU core of the computer cluster; describing determining per-core capability for all core in all nodes, this inherently teaches a distributed cluster many nodes, each with multiple cores).
Zink provides for the gaps left by Feng with respect to explicit numeric structural core-deployment recited in “the core deployment information including a number of CPU cores, a number of the core nodes, and multiple CPU cores corresponding to each of the core nodes.” (col 11 lines 17-30, col 8 lines 40-60 & Fig 3, nchips = number of processor chips in system, ncpc = number of core per processor chip, ncores = nchips * ncpc = total number of cores in system; “chips, cores/chip, threads” core, provides explicit disclosure of number of core nodes (nchips), multiple CPU cores corresponding to each core node (ncpc), and total number of CPU cores (ncores).
Before the effective filing date of the claimed invention, a POSITA would have found it obvious to combine the teachings of Funabashi, Feng and Zink to arrive at the claimed subject matter. Funabashi discloses determining how to assign processes across distributed service nodes based on configuration and communication costs, thereby providing a foundation for copy-to-node scheduling. Feng already teaches a master-node (service node) scheduler that determines copy-level scheduling of an application across multiple nodes based on per-core capability information and on the number of previously executed application copies [0032], [0046]-[0047]. However, Feng describes core-deployment information functionally rather than structurally. Zink explicitly provides the well-known structural representation of “number of CPU cores”, “number of core nodes”, and “multiple CPU cores corresponding to each node” via its nchips, ncpc, and ncores model variables. Incorporating such explicit deployment-parameter modeling into the scheduling framework of Feng would have a predictable and routine enhancement, improving accuracy of workload distribution decision by supplying precise structural deployment data.
Regarding claim 2 (and apparatus claim 11, one or more memories claim 16), Funabashi teaches the method wherein the application copy is executed at the corresponding core node ([0036], states “…arranges each process includes in a series of processes in each node, and performs the process, based on the allocation result”; maps—each application copy (process) is executed at the node it’s assigned to).
Regarding claim 3 (and apparatus claim 12, one or more memories claim 17), Funabashi teaches the method wherein the application copy is not executed across different core nodes ([0006], [0031]-[0032], [0063], processes are grouped and allocated per node; Allocation ensures all processes in a group can run on a single node; also states: “the node determination unit 105 allocates a process that is not allocated, on a node in which a communication cost from the start node to the end node is minimized—each process is allocated to a node, and not executed across different nodes; each “application copy” (process group) is allocated to one node only).
Regarding claim 4, Funabashi teaches the method wherein the determining, according to the number of copies of an application and the core deployment information of the core nodes corresponding to the service nodes, the copy scheduling information of the application comprises:
receiving the number of the copies of the application, and acquiring the core deployment information of the core nodes corresponding to the service nodes ([0006], [0031]-[0035], the system receives and process request and configuration info from the client terminal; it obtains network configuration, communication costs, and deployment information; then determines process-node assignment);
determining, according to the number of the copies and the core deployment information, at least one application copy corresponding to each of the core nodes ([0006], [0031]-[0035], the system receives and process request and configuration info from the client terminal; it obtains network configuration, communication costs, and deployment information; then determines process-node assignment); and
generating, according to the correspondences between the core nodes and the application copies, the copy scheduling information of the application ([0006], [0031]-[0035], the system receives and process request and configuration info from the client terminal; it obtains network configuration, communication costs, and deployment information; then determines process-node assignment).
Regarding claim 5, Funabashi teaches the method wherein the creating the at least one scheduling task comprises: creating a scheduling task for each of the application copies of the application ([0036], [0043], states “the process arrangement performance unit receives an allocation result of each process on nodes from the process allocation server arranges each process…in each node—per process or per node task generation).
Regarding claim 6, Funabashi teaches the method wherein the creating the at least one scheduling task comprises: creating a scheduling task for each of the core nodes corresponding to the application ([0036], [0043], states “the process arrangement performance unit receives an allocation result of each process on nodes from the process allocation server arranges each process…in each node—per process or per node task generation).
Regarding claim 7 (and apparatus claim 13, one or more memories claim 18), Funabashi teaches the method according, wherein each of the application copies corresponds to one core node, and each of the core nodes correspond to one or more application copies ([0032], [0036], support flexible mapping of processes to nodes by stating: “determines a node on which each process…is allocated from a plurality of the nodes…”, showing one-to-many relationships).
Regarding claim 9 (and method claim 1), Funabashi teaches an apparatus comprising:
one or more processors ([0006] processor); and
one or more memories storing thereon computer-readable instructions that, when executed by the one or more processors ([0034], and claim 10 memory), cause the one or more processors to perform acts comprising:
receiving copy scheduling information of an application ([0032]-[0036], [0042]-[0047], [0050]-[0062], deployment of same processes = deployment of same application copy, description how a request for a series of processes is made, and nodes are assigned to execute them; each time a series is requested and deployed, a copy or instance of the application is being distributed; furthermore describes the client terminal requests execution of a series of processes from the process arrangement server, the server sends configuration info to allocate each process of the series on specific nodes, and the node allocation information table associates each process name (process 1, process 2) with the specific node it is assigned to);
creating a scheduling task for the application copy ([0006], [0031]-[0032], [0035]-[0036], receiving a request to perform a group of processes (an application) from a client; Process allocation server allocates the processes to appropriate nodes; The allocation is based on process grouping and bandwidth considerations; the arrangement server executes tasks on allocated nodes—copies of application map to plurality of processes and core nodes map to nodes 50-1 to 50-n); and
executing the scheduling task to allocate the core node for the application copy according to the copy scheduling information, wherein the application copy is not executed across different core nodes ([0006], [0031]-[0032], [0035]-[0036], receiving a request to perform a group of processes (an application) from a client; Process allocation server allocates the processes to appropriate nodes; The allocation is based on process grouping and bandwidth considerations; the arrangement server executes tasks on allocated nodes—copies of application map to plurality of processes and core nodes map to nodes 50-1 to 50-n).
But Funabashi fails to teach the copy scheduling information including a correspondence between an application copy of the application and a core node.
However, Feng teaches teach the copy scheduling information including a correspondence between an application copy of the application and a core node ([0032], [0047], Fig 5 & subsequent text, direct teaching that application copies (instances) correspond to different nodes, selection = assignment of instance to specific node/core; migration further shows dynamic re-establish of correspondence between each instance copy and a specific core node).
Before the effective filing date of the claimed invention, a POSITA would have found it obvious to combine the teachings of Funabashi, Feng and Zink to arrive at the claimed subject matter. Funabashi discloses determining how to assign processes across distributed service nodes based on configuration and communication costs, thereby providing a foundation for copy-to-node scheduling. Feng already teaches a master-node (service node) scheduler that determines copy-level scheduling of an application across multiple nodes based on per-core capability information and on the number of previously executed application copies [0032], [0046]-[0047]. However, Feng describes core-deployment information functionally rather than structurally. Zink explicitly provides the well-known structural representation of “number of CPU cores”, “number of core nodes”, and “multiple CPU cores corresponding to each node” via its nchips, ncpc, and ncores model variables. Incorporating such explicit deployment-parameter modeling into the scheduling framework of Feng would have a predictable and routine enhancement, improving accuracy of workload distribution decision by supplying precise structural deployment data.
Regarding claim 14, Funabashi teaches one or more memories storing thereon computer-readable instructions that, when executed by one or more processors ([0034], and claim 10 memory), cause the one or more processors to perform acts comprising:
determining, according to an application deployment instruction for a multi-process application, a service node corresponding to the multi-process application ([0006], [0031]-[0032], [0035]-[0036], receiving a request to perform a group of processes (an application) from a client; Process allocation server allocates the processes to appropriate nodes; The allocation is based on process grouping and bandwidth considerations; the arrangement server executes tasks on allocated nodes—copies of application map to plurality of processes and core nodes map to nodes 50-1 to 50-n);
creating at least one scheduling task ([0006], [0031]-[0032], [0035]-[0036], receiving a request to perform a group of processes (an application) from a client; Process allocation server allocates the processes to appropriate nodes; The allocation is based on process grouping and bandwidth considerations; the arrangement server executes tasks on allocated nodes—copies of application map to plurality of processes and core nodes map to nodes 50-1 to 50-n); and
executing at least one the scheduling task to allocate a corresponding core node for an application copy of the multi-process application according to the copy scheduling information ([0006], [0031]-[0032], [0035]-[0036], receiving a request to perform a group of processes (an application) from a client; Process allocation server allocates the processes to appropriate nodes; The allocation is based on process grouping and bandwidth considerations; the arrangement server executes tasks on allocated nodes—copies of application map to plurality of processes and core nodes map to nodes 50-1 to 50-n).
But Funabashi fails to teach determining, according to a number of copies of the multi-process application and core deployment information of core nodes corresponding to the service node, copy scheduling information of the multi-process application, the copy scheduling information correspondences between application copies of the multi-process application and the core nodes.
However, Feng teaches determining, according to a number of copies of an application and core deployment information of core nodes corresponding to a service node, copy scheduling information of the application ([0030]-[0032], [0046]-[0047], teaches multiple instances/copies of an application that a scheduler dispatches; showing the master node (service node) maintains core deployment information for all CPU cores in all cluster nodes; explicitly describes the master node determining per-instance scheduling for the application across nodes using instance history (“copies”) and per-core capability data (core deployment information),
the copy scheduling information including correspondences between application copies of the application and the core nodes ([0032], [0047], Fig 5 & subsequent text, direct teaching that application copies (instances) correspond to different nodes, selection = assignment of instance to specific node/core; migration further shows dynamic re-establish of correspondence between each instance copy and a specific core node),
the core deployment information including a number of CPU cores, a number of the core nodes, and multiple CPU cores corresponding to each of the core nodes ([0030-[0031], [0046], master node can obtain a CPU capability for each CPU core of the computer cluster; describing determining per-core capability for all core in all nodes, this inherently teaches a distributed cluster many nodes, each with multiple cores).
Zink provides for the gaps left by Feng with respect to explicit numeric structural core-deployment recited in “the core deployment information including a number of CPU cores, a number of the core nodes, and multiple CPU cores corresponding to each of the core nodes.” (col 11 lines 17-30, col 8 lines 40-60 & Fig 3, nchips = number of processor chips in system, ncpc = number of core per processor chip, ncores = nchips * ncpc = total number of cores in system; “chips, cores/chip, threads” core, provides explicit disclosure of number of core nodes (nchips), multiple CPU cores corresponding to each core node (ncpc), and total number of CPU cores (ncores).
Before the effective filing date of the claimed invention, a POSITA would have found it obvious to combine the teachings of Funabashi, Feng and Zink to arrive at the claimed subject matter. Funabashi discloses determining how to assign processes across distributed service nodes based on configuration and communication costs, thereby providing a foundation for copy-to-node scheduling. Feng already teaches a master-node (service node) scheduler that determines copy-level scheduling of an application across multiple nodes based on per-core capability information and on the number of previously executed application copies [0032], [0046]-[0047]. However, Feng describes core-deployment information functionally rather than structurally. Zink explicitly provides the well-known structural representation of “number of CPU cores”, “number of core nodes”, and “multiple CPU cores corresponding to each node” via its nchips, ncpc, and ncores model variables. Incorporating such explicit deployment-parameter modeling into the scheduling framework of Feng would have a predictable and routine enhancement, improving accuracy of workload distribution decision by supplying precise structural deployment data.
Claims 8, 10, 15, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Funabashi in view of Feng, in further view of Zink, in further view of Van Riel et al (US20160210049).
Regarding claim 8 (and one or more memories claim 19), Funabashi fails to teach the method wherein the core deployment information is deployment information of a multi-core CPU on the service node based on a non-uniform memory access (NUMA) architecture.
However Van Riel teaches the method wherein the core deployment information is deployment information of a multi-core CPU on the service node based on a non-uniform memory access (NUMA) architecture ([0024]-[0025], core deployment information is deployed information of a multi-core CPU on the service node based on NUMA architecture; NUMA architecture, multi-core CPUs, and core-node/memory layout; deployment information includes NUMA topology, latency tables (SRAT, SLIT) etc.).
Funabashi discloses process scheduling and allocation to nodes in a distributed system. Van Riel discloses a system architecture using multi-core CPUs and NUMA. Van Riel further discloses that memory and CPU cores are allocated based on memory access patterns (deployment information that is core-aware and NUMA-aware).
It would have been obvious to a person having ordinary skill in the art to use NUMA-based multi-core CPU deployment strategies from Van Riel in the distributed process allocation system of Funabashi, to optimize task placement based on memory locality and interconnect bandwidth. This combination enhances performance and reduces communication costs.
Both references address process/task scheduling across nodes to improve distributed system performance. Funabashi focuses on network and process orchestration in distributed systems. Van Riel focuses on intra-node core and memory aware task scheduling in NUMA environments. A POSITA would logically combine inter-node process allocation with intra-node NUMA-aware optimization to improve end-to-end application performance. This combination would result in a distributed system with enhanced take-to-node and task-to-core placement logic, using both communication cost and memory access locality.
Regarding claim 10, Funabashi fails to teach the apparatus wherein the executing the scheduling task to allocate the core nodes for the application copy according to the copy scheduling information comprises:
executing the scheduling task to determine the core node allocated for the application copy of the application according to the copy scheduling information; and
scheduling a worker process corresponding to the application copy to the core node.
However Van Riel teaches the apparatus wherein the executing the scheduling task to allocate the core nodes for the application copy according to the copy scheduling information comprises:
executing the scheduling task to determine the core node allocated for the application copy of the application according to the copy scheduling information ([0022]-[0030], task scheduling based on NUMA-locality including migration based on task memory access scores; scheduling a worker process…to the core node” is reflected in the NUMA aware task migration and placement logic); and
scheduling a worker process corresponding to the application copy to the core node ([0022]-[0030], task scheduling based on NUMA-locality including migration based on task memory access scores; scheduling a worker process…to the core node” is reflected in the NUMA aware task migration and placement logic).
Funabashi discloses process scheduling and allocation to nodes in a distributed system. Van Riel discloses a system architecture using multi-core CPUs and NUMA. Van Riel further discloses that memory and CPU cores are allocated based on memory access patterns (deployment information that is core-aware and NUMA-aware).
A POSITA would have found it obvious to modify Funabashi’s distributed process system to incorporate Van Riel’s NUMA-aware take/core-node scheduling mechanisms. Doing so would optimize task placement to core nodes based on memory access scores and topology, thereby improving performance.
Both references address process/task scheduling across nodes to improve distributed system performance. Funabashi focuses on network and process orchestration in distributed systems. Van Riel focuses on intra-node core and memory aware task scheduling in NUMA environments. A POSITA would logically combine inter-node process allocation with intra-node NUMA-aware optimization to improve end-to-end application performance. This combination would result in a distributed system with enhanced take-to-node and task-to-core placement logic, using both communication cost and memory access locality.
Regarding claim 15, Funabashi fails to teach the one or more memories wherein the service node comprises an elastic bare metal server node.
However, Van Riel teaches the one or more memories wherein the service node comprises an elastic bare metal server node ([0062], [0026], the hardware platform described includes various computing devices such as servers, capable of running on OS kernels and hypervisors, bare metal architecture shown by the task score module running directly on hardware).
Funabashi discloses process scheduling and allocation to nodes in a distributed system. Van Riel discloses a system architecture using multi-core CPUs and NUMA. Van Riel further discloses that memory and CPU cores are allocated based on memory access patterns (deployment information that is core-aware and NUMA-aware).
It would have been obvious to use bare metal elastic servers as service nodes in Funabashi’s distributed system to allow scalable, dynamic, and low-level control over resource scheduling, especially, when combined with Van Riel’s fine-grained NUMA-aware scheduling.
Both references address process/task scheduling across nodes to improve distributed system performance. Funabashi focuses on network and process orchestration in distributed systems. Van Riel focuses on intra-node core and memory aware task scheduling in NUMA environments. A POSITA would logically combine inter-node process allocation with intra-node NUMA-aware optimization to improve end-to-end application performance. This combination would result in a distributed system with enhanced take-to-node and task-to-core placement logic, using both communication cost and memory access locality.
Regarding claim 20, Funabashi fails to teach the one or more memories wherein the service node is a multi-core CPU that uses the NUMA architecture.
Van Riel teaches the one or more memories wherein the service node is a multi-core CPU that uses the NUMA architecture ([0024], [0030], describes NUMA systems with multi-core CPUs, memory-locality-aware scheduling, and memory score optimization).
Funabashi discloses process scheduling and allocation to nodes in a distributed system. Van Riel discloses a system architecture using multi-core CPUs and NUMA. Van Riel further discloses that memory and CPU cores are allocated based on memory access patterns (deployment information that is core-aware and NUMA-aware).
It would have been obvious to implement Funabashi’s node devices using multi-core-NUMA CPUs as disclosed in Van Riel to take advantage of NUMA-aware process placement for latency reduction and memory access efficiency.
Both references address process/task scheduling across nodes to improve distributed system performance. Funabashi focuses on network and process orchestration in distributed systems. Van Riel focuses on intra-node core and memory aware task scheduling in NUMA environments. A POSITA would logically combine inter-node process allocation with intra-node NUMA-aware optimization to improve end-to-end application performance. This combination would result in a distributed system with enhanced take-to-node and task-to-core placement logic, using both communication cost and memory access locality.
Conclusion
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 concerning this communication or earlier communications from the examiner should be directed to MICHAEL WILLIAM ABBATINE whose telephone number is (571)272-0192. The examiner can normally be reached Monday-Friday 0830-1700 EST.
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, Nishant Divecha can be reached at (571) 270-3125. 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.
/MICHAEL WILLIAM ABBATINE JR./Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights