DETAILED ACTION
This Office Action is in response to claims filed on 02/23/2026.
Claims 1-4 and 6-9 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 .
Response to Arguments
Applicant’s arguments, see page 6 of applicant's remarks, filed 02/23/2026, with respect to 35 U.S.C. 112(b) rejection have been fully considered and are persuasive. The rejection of 10/22/2025 has been withdrawn.
Response to Arguments
Applicant's arguments filed 02/23/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
Cadambi is further silent with respect to features of “monitoring, by the core monitor, a frontmost part of a core monitoring queue; determining a priority of usage information of a core having an allocated task based on estimated time arrival (ETA), and adding the usage information to the core monitoring queue, wherein, as the ETA is short, the priority is high; and when the task is completely allocated, causing a polling operation to be pending by using a sleep as much as ETA of a core at the frontmost part of the core monitoring queue, wherein the core at the front most part of the monitoring queue is a core having the smallest ETA, and wherein the plurality of cores are controlled through a single thread.” as also explicitly recited in amended independent claim 1.
Thus, Applicant submits that the amended independent claim1 distinguishes over Cadambi.
With respect to point (a), Examiner respectfully disagrees. In summary, Applicant has substantially amended independent claim 1 to incorporate the limitations of former dependent claim 6. Further, Applicant argues that Cadambi is silent to the newly incorporated limitations.
Examiner respectfully submits that the newly added limitations are taught by Cadambi. With respect to features set forth above, Cadambi reasonably teaches a
“monitor which collects data about the state of the coprocessors, and is the portion that measures execution times” (Col. 9, lines 8-9). Cadambi further discloses a task urgency function in which incorporates process priority, process age, and process wait time to inform the best task to schedule (see at least Col. 10, lines 25-39). With respect to the task urgency function, Cadambi discusses a bin mechanism which produces an “offload history table” used to inform estimation of future offload execution times in association with a bin which governs the duration in which scheduling decisions need to be made (see at least Col. 21). Cadambi’s identification of the smallest repeating offload pattern necessarily identifies an offload with the shortest estimated execution time. Applicant has not indicated any structural or functional distinction between the claimed features and the Cadambi reference that would overcome the cited reference. Thus, Examiner maintains the rejection as applied in the previous Office Action of 10/22/2025.
Argument has not been found to be persuasive.
Applicant’s arguments with respect to claims 1 and 6 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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-4 and 6-9 are rejected under 35 U.S.C. 103 as being unpatentable over Cadambi et al. Patent No. US 9,367,357 B2 (hereinafter Cadambi) in view of Bass et al. Pub. No. US 2013/0152099 A1 (hereinafter Bass).
With regard to claim 1, Cadambi teaches a hardware accelerator controlling method performed by a hardware accelerator controlling device including (Col. 1, A method for scheduling jobs to manycore nodes in a cluster includes selecting a job to run according to the job’s wait time and the job’s execution time; Col. 1, Referring now to FIG. 1A, a high-level view of a process manager 20 called the COSMIC system is shown) a hardware accelerator, which includes a plurality of cores (FIG. 1B, Host maintain Xeon Phi accelerators comprising of 56-70 cores; Col. 1, The present invention relates to multi-core processing and, more particularly, to scheduling manycore processors; Col. 2, In a server with multiple coprocessors 30, 32, and 34, such as the Intel Xeon Phi, each with different amounts of memory and cores) and is configured to program a time-critical task (Col. 1, Many suitable applications for the Xeon Phi can be expressed using a bag-of-tasks framework. Bag-of-tasks application are those whose tasks are completely independent. Although conceptually simple, this framework is typical of a large class of problems such as satellite imaging, Berkely Open Infrastructure for Network Computing (BOINC)-like computations, image processing, networking, and others. Tasks belonging to a bag-of-tasks applications typically have real-time constraints, which we refer to as the task deadline; Col. 12, A list of tasks, sorted by criticality or “urgency” is provided), and a software framework, which is connected to the hardware accelerator and including a core monitor (Fig. 2, COSMIC framework components connected to the hardware accelerator; Col. 7, COSMIC (Examiner notes: the software framework) is architected as three components implemented as separate processes; the client, the scheduler, and the monitor, the latter comprising a host portion and card-side portion, as depicted in FIG. 2), the method comprising:
instantiating, by the software framework, a task force configured [schedule jobs among available cores] (Col. 2, COSMIC manages offloads from several user processes 10, 12, and 14 to the manycore processors. Each user process contains several offload blocks that are executed sequentially. The process has a single memory requirement for all its offloads, while the offloads themselves have their own thread requirements. Thus, before execution, every process requests the process manager 20 for memory, and every offload requests the process manager 20 for threads. COSMIC arbitrates the requests by taking into consideration the different available coprocessors, the available cores within each device and the available memory. It then schedules and allocates resources for the offloads) to group, among the plurality of cores, multiple cores that perform a same type of task, wherein the task force is a task management unit provided by the software framework, through an application (Col. 7, The COSMIC client is responsible for intercepting COI calls and communicating with the COSMIC scheduler (Examiner notes: task force providing task management) to request access to a coprocessor. It accomplishes this using library interposition. Every user process links with the Intel COI shared library that contains definitions for all API function modules. COSMIC intercepts and redefines every COI API function);
configuring, by the application, metadata for controlling the hardware accelerator (Before execution, every process requests COSMIC for memory, and every offload requests COSMIC for threads. COSMIC arbitrates the requests by taking into consideration the different available coprocessors, the available cores within each device, and the available memory. It then schedules and allocates resources for the offloads in such a way that thread and memory oversubscription are avoided, and the devices as well as the cores within them are load balanced.) by using the instantiated task force (Col. 3, COSMIC has several parameters that may be set by the server administrator or user that can affect its policies and behavior. An administrator can configure the following parameters of COSMIC to affect its scheduling decision);
registering, by the application, the task force in the software framework (Fig. 3, COSMIC system intercepts requests such that they are routed to the COSMIC scheduler to be offloaded; Col. 7, With the redefined functions, COSMIC creates its own shared library that is preloaded to the application (using either LD_PRELOAD or redefining the LD_LIBRARY_PATH). The preloading ensures that COSMIC’s library is first used to resolve any COI API function).
monitoring, by the core monitor, a frontmost part of the core monitoring queue (Col. 9, To enable criticality-based scheduling, the monitor performs two additional functions: When the offloads complete, the monitor records the offload’s execution time in the scheduler’s history table. The monitor also measures the time between an offload completion and the arrival of a new offload, which is the time the task spent on the host and must be counted towards the overall task processing time);
determining a priority of usage information of a core having the allocated task based on estimated time arrival (ETA) and adding the usage information to the core monitoring queue, wherein, as the ETA is short, the priority is high (Col. 10, A Criticality (or “Urgency”) function, which determines the best process or offload to schedule based on: The process’ or offload’s priority; The process’ or offload’s age, which depends on how many times the scheduler examined the processor or offload; The amount of time the process or offload has been waiting to execute since it arrived; Col. 11, The basic scheduling method … picks the first element E with highest criticality whose resource request can be satisfied by a coprocessor); and
when the task is completely allocated, causing a polling operation to be pending by using a sleep as much as ETA of a core at the frontmost part of the core monitoring queue (Col. 21, Measured execution times for several past offloads in the Offload History Table 812. To discover patterns in the offload times, the history table 812 is transversed and every offload is “binned” as follows. An offload o.sub.ik; with execution time e.sub.ik is "binned" with an earlier offload o.sub.ij with execution time e.sub.ij if: (i) the difference between e.sub.ik and e.sub.ij is under 20% and (ii) among execution times for the offloads seen so far, e.sub.ij is closest to e.sub.ik. Otherwise o.sub.ik creates its own bin. The 20% is empirically derived using the observed offload patterns for our workloads across several data sizes. (Examiner notes: such that binning offload tasks according to their expected execution time minimizes the number of queries required to assess offload task completion and offload task selection),
wherein the core at the frontmost part of the monitoring queue is a core having the smallest ETA (Col. 21, Once bins are created, the smallest repeating offload pattern is found and used to estimate the execution time of the next offload: the new offload is assumed to continue the repeating offload pattern and fit into an existing bin. Its execution time is estimated to be the average of all the offloads in its bin. If the history table does not have sufficient offloads, or if a repeating offload pattern cannot be found, the estimated execution time of the new offload is the average of all the offloads seen thus far), and
wherein the at least one core is controlled through a single thread (Col. 3-4, COSMIC needs to know how user threads must be mapped to cores. A SCATTER mapping indicates 1 thread per core; Col. 21, Each processing core on the hardware layer on a compute node 800 is represented as a slot that can be claimed to run a job. Only one job can run on one slot at a time).
Cadambi does not explicitly the task force configured to group, among a plurality of cores, multiple cores that perform a same type of task.
Bass teach a task force configured to group ([0026], With reference to a first embodiment, FIG. 1 shows a Queue Controller 102 and a plurality of queues 104, 105 and 106 for enqueuing jobs received from Job Requestor 101 and dispatching the jobs from the heads of the queues; [0032], Queue Controller 102 decides whether to accept a job from the Job Requestor for a given queue. To do so, it examines the job type, i.e., which type of hardware acceleration engine it requires, to choose the correct queue from the plurality of queues), among the plurality of cores ([0004], Examples of hardware accelerators include the IBM Cell B.E. (broadband engine) processor, encryption units, compression/decompression engines and graphics processing units (GPUs). Hardware accelerators may be programmable to enable specialization of a particular task or function and may include a combination of software, hardware, and firmware. Hardware accelerators may be attached directly to the processor complex or nest, by PCIexpress (peripheral component interconnect) IO (input-output) slots or remotely via high-speed networks. (Examiner notes: Such that hardware accelerators comprise multi-core architectures and arrangements).), multiple cores that perform a same type of task ([0026], hardware acceleration engines 107, 108 and 109, which may include different methods of encryption (RSA, AES), compression/decompression, or data analytics. A person of skill in the art will appreciate that many types of hardware accelerator engines could be employed using embodiments of the present invention and are not limited to the type shown in FIG. 7. FIG. 1 shows one queue (Q1, Q2 . . . Qn) for each type of hardware acceleration engine 107, 108 and 109 (Examiner notes: Queue associated with multi-core hardware accelerators configured to perform a type of particular task).)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Bass with the teachings of Cadambi in order to provide a method that teaches a task force grouping cores to service repetitive tasks. The motivation for applying Bass teaching with Cadambi teaching is to provide a method that allows for fair allocation of jobs to accelerator resources designated by usage, job latency, and capacity such that enables efficient scheduling of analogous task across specialized hardware accelerators thereby improving throughput and resource fairness (Bass, [0010]-[0011]). Cadambi and Bass are analogous art directed towards task dispatching and allocation of resources. Therefore, it would have been obvious for one of ordinary skill in the art to combine Bass with Cadambi to teach the claimed invention in order to provide an accelerator allocation framework configured to schedule tasks in accordance with accelerators performing analogous tasks in order to improve resource fairness and utilization.
With regard to claim 2, Cadambi teaches wherein the software framework is configured to:
program the hardware accelerator based on an accelerator core setting included in the metadata of the task force requested to be registered (Col. 3, COSMIC also expects from the owner of each process the following directives: Memory Limit: the peak memory the process will use over its lifetime. COSMIC kills any process that exceeds its memory usage as described later in this section. Preferred thread affinity: to allocate Xeon Phi cores for an offload, COSMIC needs to know how user threads must be mapped to cores. A SCATTER mapping indicates 1 thread per core, a COMPACT mapping indicates 4 threads per core, and BALANCED indicates 3 threads per core. User specifies the maximum amount of memory per process, and use of host. The user sets environment variables COSMIC_PROCESS_MAX_MEMORY and COSMIC_MIC_ONLY (Examiner notes: wherein configurations made to the COSMIC scheduler is propagated to how scheduling will occur on the accelerator cores).
With regard to claim 3, Cadambi teaches making, by the application, a request for task processing to the software framework and the hardware accelerator through the instantiated task force registered in the software framework (Col. 4, FIGS. 1B-1D shows in more details the process manager of FIG. 1A. In FIG. 1B, a cluster scheduler 40 receives tasks with deadlines and quality of service (QoS) requests from users 1-3, for example. The cluster scheduler 40 communicates with one or more node schedulers 42, which control each host computer 404, each in turn having one or more multicore processor cards there. The cluster 40 and node scheduler 42 communicates work request and acceptance/rejection from the node scheduler 42 as well as the estimated deadline information);
managing a requested task by adding the requested task to a task queue (Col. 5, FIG. 1D shows in more details the node scheduler 42. Tasks dispatched from the cluster scheduler 40 enter a pending task list 60 which are distributed over a plurality of devices, numbered 1 to M; FIG. 1D shows the main components of the node level scheduler 32. The node level scheduler 42 includes: (i) a list of pending tasks 60); and
when a new task is added to the task queue, providing a notification of a signal indicating that the new task is added to the core monitor by the task force (Col. 5, The node scheduler 42 is event-based. A scheduling cycle is triggered by a new event that can be the arrival of a new task, the arrival of a new offload in an existing task, the dispatching of an offload to a Xeon Phi device, the completion of an offload or the completion of a task. It uses the concept of criticality, and selects at each scheduling cycle the most urgent task or offload from the list of pending tasks and offloads).
With regard to claim 4, Cadambi teaches monitoring, by the core monitor, the plurality of cores included in the hardware accelerator (Col. 9, The COSMIC monitor collects data about the state of the coprocessors, and is the portion that measures execution times … The coprocessor-side components monitor the load on each coprocessor, the number of threads request by each offload and the health (i.e., whether the COI process is alive or not) of each COI process);
when there is an additional task to be processed during the monitoring, determining whether there is an available core among the plurality of cores (Col. 11, Referring now to FIG. 5D, an exemplary process is shown to select the offload queue based on the number of allocated cores … Block 544 receives an offload queue for a particular device, D. Block 546 selects the top offload from the queue. The offload is tested as to whether it can run on the device in block 548 by determining whether the number of software threads used by the offload is smaller than the number of available hardware threads on the device. If there are sufficient hardware threads available, block 550 checks a list of physical cores and block 552 determines whether a sufficient number of cores are available); and
when the available core is found, removing the additional task from the task queue of the task force and allocating the additional task to the available core of the hardware accelerator (Col. 11, If so, block 554 allocates the core for the offload, removes the offload from the queue, and dispatches the task).
With regard to claim 6, Cadambi teaches A hardware accelerator controlling device, the device comprising (Col. 2, A system for scheduling jobs to manycore nodes in a cluster includes a scheduler comprising a processor configured to select a job to run according to the job’s wait time and the job’s expected execution time). Claim 6 is a device having similar limitations as claim 1. Thus, claim 6 is rejected for the same rationale as applied to claim 1.
With regard to claim 7, it is a device having similar limitations as claim 2. Thus, claim 7 is rejected for the same rationale as applied to claim 2.
With regard to claim 8, it is a device having similar limitations as claim 3. Thus, claim 8 is rejected for the same rationale as applied to claim 3.
With regard to claim 9, it is a device having similar limitations as claim 4. Thus, claim 9 is rejected for the same rationale as applied to claim 4.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM 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, Aimee Li can be reached at (571) 272-4169. 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.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights