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 .
Remarks
This Office Action is in response to amendment and remarks filed on 08/05/2026.
Claims 1, 3-8, 10-13, 15 and 18 are currently amended via Applicant’s amendment.
Claims 2 and 17 have been canceled via Applicant’s amendment.
Claims 1, 3-16 and 18 are pending.
Claims 1, 15 and 18 are independent claims.
This Office Action is made final.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “an iterator unit to process…”, “one or more execution units to perform…” in claims 15-18.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
Claim 11 is objected to because of the following informalities: There is a drafting error in line 2, “the least one component” should read “the at least one component.” Appropriate correction is required.
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 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.
Claims 1, 3-16 and 18 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Underwood et al. (US 2020/0050478 A1) (hereinafter Underwood) in view of Robatmili et al. (US 2016/0292012 A1) (hereinafter Robatmili).
As per claim 1, Underwood discloses A method of operating a data processor unit to generate processing tasks (e.g. Underwood: [0021] [0135] disclose a method of processing data using data processing system. [0076] discloses an iterator takes processing job and splits it up into a number of processing tasks. [0020] [0030] discloses method/system for operating an accelerator, such as a GPU, in response to host processor requests, where the accelerator executes command streams and generates tasks for processing job. Thus, Underwood teaches a method of operating a data processor unit to generate processing tasks. Also see [Claims 1 and 13].): the data processor unit (e.g. Underwood: [Fig. 1, GPU 5]) comprising: a control circuit (e.g. Underwood: [Fig. 2, MCU subsystem (25)]) to receive, from a host processor unit (e.g. Underwood: [Fig. 1, Host (2)]), a request for the data processor unit to perform a requested processing job (e.g. Underwood: discloses that the host processor communicates with the accelerator and, in response to a request for processing from an application being executed by the host processor, generates one or more command streams to cause the accelerator to perform processing tasks. Underwood further explains that the accelerator includes a command stream frontend and supervising controller (MCU) that receives the requests. See paragraphs [0051, 0058, 0070, 0145, 0151-0152]. [0051] discloses that command-stream generating circuitry prepares command streams in response to application requests for accelerator processing; [0056-0058] discloses providing/making command streams available to accelerator. In particular, paragraph [0151] explain that when an application running on the host processor makes a call for processing by the GPU, the host processor communicates with the MCU of the GPU via shared memory, and paragraph [0152] explains the MCU (25) receives a request from the host processor (2) to execute a command stream, the MCU then assigns a command stream interface for the command stream. [0020] discloses “in response to a request for processing to be performed by the accelerator from an application being executed on the host processor, one or more command streams for causing the accelerator to perform processing tasks for the application. Thus, Underwood teaches a control circuit, that receives, from a host processor unit, a request for the data processing unit to perform a job.); an iterator unit (e.g. Underwood: [Fig. 2, element (26)]) to process the request and generate a workload comprising one or more tasks for the requested processing job (e.g. Underwood: [0156] discloses a processing job is sent to the iterator (26), the iterator then breaks the processing job into smaller processing tasks which are then issued to the shader cores (27). [0076] when work is sent to the accelerator, the processing job may be sent to an iterator. The iterator takes the processing job and splits it up into a number of processing tasks which can be issued to the processing cores. [0150] discloses the iterator acts to break down the processing job into a set of processing tasks which can then be distributed between processing cores for processing. Accordingly, Underwood expressly discloses an iterator unit that processes a requested job and generates workload comprising one or more tasks for the requested job. Also see [0074] [0154] [0156].); one or more execution units (e.g. Underwood: [Fig. 2, element (27)]) to perform the one or more tasks (e.g. Underwood: discloses that the accelerator hardware includes one or more processing cores, such as shader cores, that execute the processing tasks generated by the iterator. [0076, 0150, 0156] state that the iterator breaks the processing job into smaller processing tasks which are then issued to the processing cores, and each shader core may comprise an endpoint able to task and issue it to thread groups withing the shader core. Thus, Underwood teaches one or more execution units to perform the tasks.); storage to store current system information indicative of a status of at least one component of the data processor unit (e.g. Underwood: [Fig. 2, element (22)] [0146] discloses each command stream interface has an associated command buffer containing a set of active instructions to be processed, as well as registry and local memory for storing the internal state (parameters) for the processing. The command buffer is contained in system memory. Underwood discloses command buffers, local memory, registry information, firmware state vectors, hardware state vectors, suspend buffers, and shared/interface memory used by the MCU and command stream frontend. See paragraphs [0067, 0083, 0097-0104, 0113-0118, 0146, 0149, 0151 and 0154]. For example, Underwood explains that the command stream frontend tracks progress of processing jobs, the scoreboard block tracks completion for each command stream interface, and state for hardware and firmware is stored in buffers and vectors. [0067] [0146] disclose command stream interface having local memory and registry for storing processing state values/parameters, as well as command buffer holding active instructions. [0083] discloses maintaining current command stream position/progress count in a register accessible to the accelerator. [0103] [0122] [0159] Additionally, Underwood discloses storing a current hardware and firmware state in a buffer.); the method comprising: receiving, at the control circuit, a first request to perform a first processing job (e.g. Underwood: [0020, 0051, 0151, 0152] as discussed above, Underwood discloses that host processor sends processing requests and command streams to the accelerator, and the MCU receives the requests to execute the command streams. Therefore, Underwood teaches receiving a first request to perform a first processing job at the control circuit.); processing, at the iterator unit, the first request and generating a workload comprising one or more tasks for the first processing job based on or in response to the current system information in storage, wherein at least one characteristic of the workload is dependent on the system information (e.g. Underwood: [0076] as noted above, paragraph 0076 expressly states that when processing work is send to the accelerator hardware, the processing job may be sent to an iterator, and the iterator splits the job into a number of processing tasks. [0156] likewise states a processing job is sent to the iterator along with the state vector, and iterator breaks the processing job into smaller processing tasks which are then issued to the shader cores. Thus, underwood teaches processing at the iterator unit and generating a workload comprising one or more tasks for the first processing job. [0146] Underwood further implies that the processing tasks are based on system information in storage, for example, the internal state (parameters) for processing, and a number of instructions to be processed [workload characteristics].).
Although Underwood teaches storing current system status/state information and an iterator splitting a processing job/workload into multiple tasks, but does not expressly disclose that the iterator’s workload generation in response to current system information in storage, that indicates a size and/or a number of one or more tasks in the workload based on the current system information. Specifically, Underwood does not expressly disclose the status relating to at least one of availability of the one or more execution units or an amount of available storage; and generating a workload…based on or in response to the system information in storage, wherein a size and/or a number of the one or more tasks in the workload is dependent on the current system information.
However, Robatmili teaches storage to store current system information indicative of a status of at least one component of the data processor unit (e.g., Robatmili: [Fig. 4] [0049-0052] discloses a multi-core data processor system implementing a hardware iteration-space splitter. The iteration-space splitter includes central controller, iteration-space descriptor table, iteration-space status table, and local tables associated with respective processor cores. These tables are storage structures. [0050] [0052] [0054-0058] [Figs. 5A-5C] disclose these tables are storage structures and are implemented in memory, and that the local tables correspond to the respective processor cores and hold information regarding progress of individual iterations of partitions/tasks. Robatmili’s stored information is “current system information”: [0036] [0057] [0068] [0070] discloses that local tables maintain pointers identifying current or previously executed iteration for tasks assigned to respective processor cores. The task pointers are repeatedly updated during execution to identify execution progress of the respective tasks. [0010-0011] further teaches that updated local-table information is passed to the status table at predetermined intervals or in response to an event, and that the status table and local tables may be updated without interrupting task execution. [0065-0066] [0070] [0082-0088] further disclose updating execution information as tasks are completed, as cores become available, and as remaining iterations are divided/reassigned. Thus, the table information is not merely static information; it is dynamically maintained information reflecting the current state of the multi-core data processor system. [0005] discloses updating the status table to indicate that a task has finished and the respective processor/core is available. [0035] discloses that the number of tasks may equal the number of available processors or cores. [0057-0058] [0065] disclose that, when a core has completed a task and becomes available, the central controller can create/subdivide work and assign a partition/subpartition to the available core. This teaches stored current system information relates to availability of execution units. [0004-0007] [0035-0037] [0054-0058] further teach that the local tables are associated with respective processor cores, while status table maintains task/partition assignment and execution information. Therefore, the stored current system information is indicative of a status of components of the data processor unit, including processor-core execution units and their assigned tasks/partitions.), the status relating to at least one of availability of the one or more execution units or an amount of available storage (e.g., Robatmili [0005] teaches that, upon completion of a task, the local table associated with the respective processor/core is updated to indicate that the task has finished and central controller updates the status table to indicate that the processor/core is available. [0037] [0058] [0065] further teach that, when processor cores become available, the central controller can subdivide an existing partition and provide subpartition to the available processor/core. Also see [0076]. Thus, Robatmili teaches current stored status information relating to availability of processor-core execution units.); and processing, at the iteration unit, the first request and generating a workload comprising one or more tasks for the first processing job based on or in response to the current system information in storage, wherein a size and/or a number of the one or more tasks in the workload is dependent on the current system information (e.g., Robatmili: teaches that the number and/or size of the generated tasks/partitions is based on current stored system information. Robatmili [0006] expressly teaches partitioning an iterator space “by a number of partitions equivalent to a number of available processors or processor cores.” [0035] teaches that a number of tasks may equal the number of available processors or processor cores. [0064] states that a central controller may generate multiple tasks by partitioning iterator space of a process into multiple tasks based on stored system information. Robatmili discloses iterator-space splitter divides the workload into multiple tasks across multiple processor cores. Specifically, Robatmili states that “the number of tasks may be equal to the number of available processors or processor cores”. For example, with four available processors or processor cores, four tasks may be created/initialized. [0053] expressly discloses controller may determine the size of partitions and to which processor or processor core to assign each partition based on various criteria. For example, the controller may size and allocate partitions based on the availability of the processor or processor cores. [0078-0079] further teach that the number of tasks and number of partitions may be determined based on available processors/processor cores. Also see [0087-0089]. Therefore, Robatmili teaches processing a job/iteration space and generating a workload comprising one or more tasks where a number of tasks is dependent on current stored system information such number of available processors/processor cores.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Underwood’s iterator-based task generation system to determine task number and/or task size in view of current execution resource availability and stored resource status information, as taught by Robatmili. Underwood teaches a multi-core GPU arrangement in which iterator receives a processing job and state vector, divides the job into tasks, and issues the tasks to shader cores (Underwood: [0074, 0076, 150, 154, 156, and Figs. 2-3]). Robatmili teaches a known technique for dynamically selecting task/partition number, size and allocation based on available number of processor/processor cores.
A POSITA would have been motivated to use Robatmili’s resource-aware partitioning criteria in Underwood’s iterator-driven job-to-tasks mechanism because both references concern allocation of divisible processing work among multiple processing cores. Applying Robatmili’s known technique to Underwood’s GPU task generation would have predictably improved task distribution, load balancing, utilization of available shader/processing cores, throughput, and responsiveness by matching task granularity to currently available execution resources (See Robatmili: [0053-0054]). The modification does not require replacing Underwood’s host-command-stream interface, MCU, iterator, or shader cores with Robatmili’s entire architecture. Rather, Underwood’s iterator retains its disclosed role of dividing a received processing job into tasks, while number/size of tasks is selected using the known resource-aware criteria taught by Robatmili.
As per claim 3, the combination of Underwood and Robatmili discloses (Currently Amended) The method of claim 1 [See rejection to claim 1 above], where generating the workload comprises dividing an iteration space for the first processing job into one or more tasks (e.g. Underwood: [0156] discloses a processing job is sent to the iterator (26), the iterator then breaks the processing job into smaller processing tasks which are then issued to the shader cores (27). [0076] when work is sent to the accelerator, the processing job may be sent to an iterator. The iterator takes the processing job and splits it up into a number of processing tasks which can be issued to the processing cores. [0150] discloses the iterator acts to break down the processing job into a set of processing tasks which can then be distributed between processing cores for processing. Robatmili: also discloses generating a workload by partitioning iteration space of a process into tasks, where the number and size of tasks/partitions depend on system information. Specifically, Robatmili states that “the number of tasks may be equal to the number of available processors or processor cores” (paragraphs 0035, 0064), and that the controller may determine the size of various partitions and to which processor or core to assign each task/partition based on various criteria, including the type, the performance characteristics, and/or the availability of the processor or processor core, and the type, the resource requirements, and/or latency tolerance of the execution of processes (paragraph 0053). Robatmili also discloses that the iteration space is stored in a descriptor table and partition status in a status table, and that partitions are dynamically subdivided based on available cores and minimum partition size (Abstract, paragraphs 0004-0011, 0050-0056).).
As per claim 4, the combination of Underwood and Robatmili discloses (Currently Amended) The method of claim 1 [See rejection to claim 1 above], further comprising: allocating the tasks to one or more execution units, where the number of tasks allocated to a particular execution unit is dependent, at least in part, on the current system information (e.g. Underwood: discloses iterator distributes processing tasks to processing cores, such as by breaking down jobs and issues tasks to shader cores (paragraphs 0076, 0150, 0156). Robatmili: further discloses allocating tasks to processor cores where the allocation depends on system information, including number of available cores and status information. Specifically, Robatmili teaches that the controller may determine the size of various partitions and to which processor or processor core to assign each partition/task based on various criteria, including the type, the performance characteristics, and/or the availability of the processor core (paragraph 0053). Robatmili further teaches that the number of tasks is set equal to the number available processors or processor cores (paragraphs 0035, 0064), and that when a core becomes available, remaining divisible partitions are subpartitioned and allocated to the now-available core (paragraphs 0006, 0050-0056). The status table and local tables store system information about partition status and core availability to enable this dynamic allocation.).
As per claim 5, the combination of Underwood and Robatmili discloses (Currently Amended) The method of claim 1 [See rejection to claim 1 above], where the data processor unit comprises a plurality of execution units and the first processing job comprises a plurality of tasks (e.g. Underwood: discloses a data processing unit with a plurality of execution units (Fig. 2, element 27, cores) and allocation of tasks to those units. Underwood discloses that iterator acts to break down the processing job into a set of processing tasks which can then be distributed between the processing cores for processing (paragraph [0076, 0150, 0156]). ), the method comprising: determining, using the current system information, an availability status of each execution unit of the plurality of execution units (e.g. Robatmili: discloses a data processing system with multiple processor cores [execution units] and determining availability status using system information and allocating tasks to available cores. Specifically, Robatmili further teaches that when a task completes on a processor core, the controller updates the local table and status to indicate the core is available (paragraphs 0006, 0050-0056) and controller then subdivides remaining divisible partitions and allocates subpartitions to the now-available core. The status table and local table store system information about partition execution status and core availability (Abstract, paragraphs 0004-0011, 0050-0057). Robatmili also teaches that the number of tasks is set equal to the number of available cores, and dynamic reallocation occurs based on this status information (paragraphs 0035,0053, 0064-0065). Also see [0078-0079]; allocating tasks of the plurality of tasks between execution units that are available to process tasks allocated thereto (e.g. Underwood: discloses a data processing unit with a plurality of execution units (Fig. 2, element 27, cores) and allocation of tasks to those units. Underwood discloses that iterator acts to break down the processing job into a set of processing tasks which can then be distributed between the processing cores for processing (paragraph [0076, 0150, 0156]). Also see Robatmili: [0035, 0050-0057, 0087-0089]. ).
As per claim 6, the combination of Underwood and Robatmili discloses (Currently Amended) The method of claim 1 [See rejection to claim 1 above], further comprising: updating the current system information at the data processor unit in response to a change in the status of the at least one component (e.g. Underwood: discloses updating system status information in response to status changes, such as automatically incrementing command stream progress counts when command are executed (paragraph 0083), saving and updating firmware/hardware state vectors and suspend buffers when switching modes (paragraphs 0097, 0113, 0115-0116), and the scoreboard block independently tracking and updating processing job completion status for command stream interfaces (paragraph 0149). These updates occurs dynamically in response to changes in component status, such as command progress or hardware/firmware state during operation. Robatmili: also discloses updating system information in response to status changes. Specifically, Robatmili teaches that when a task completes execution, the controller associated with the core updates the local table to indicate completion, and updates the status table to reflect that the task has finished and the core is available (paragraphs 0006, 0050-0056). Robatmili further teaches that controllers update local tables and synchronize with the status table at predetermined interval or in response to events, such as task completion or pointer update for iteration progress, without interrupting execution (paragraphs 007-0011, 0056). These updates occur in response to changes in component status, such as partition/task completion or core availability.).
As per claim 7, the combination of Underwood and Robatmili discloses (Currently Amended) The method of claim 6 [See rejection to claim 6 above], further comprising: receiving, at the control circuit, a further request to perform a further processing job; processing, at the iterator unit, the further request and generating a further workload comprising one or more tasks for the further processing job based on or in response to the updated current system information in storage, wherein at least one characteristic of the further workload is dependent on the updated system information (e.g. Underwood: teaches receiving multiple sequential requests and processing them using updated system information. Underwood discloses that the host processor can generate multiple command streams for the accelerator, with the supervising controller (MCU) receiving and scheduling new command streams (paragraphs 0051, 0057, 0066, 0151-0152). Underwood further teaches that system information is updated during operation, such as progress counts incremented during command execution (paragraph 0083), firmware/hardware state updated in suspend buffers (paragraphs 0097,0113), and scoreboard block tracking completion status updated in real-time (paragraph 0149). When a new command stream is made available, the command stream interface executes it using the current state from local memory/registry (paragraphs 0064-0066, 0073-0074), and iterator process new RUN commands to generate tsks from the updated state (paragraph 0076, 0156). Thus, Underwood teaches receiving a further request, processing it at the iterator unit to generate a further workload based on updated system information. Robatmili: teaches sequential processing of multiple repetitive processes (jobs) using updated system information. Robatmili discloses multiple iteration spaces can be initialized and tracked in the descriptor table and status table, with new iteration spaces added while others execute (Abstract, paragraphs 0050-0056). As tasks complete and cores become available, status tables are updated, and the controller processes new iteration spaces by partitioning them into tasks based on the updated availability and status information (paragraphs 0006, 0035, 0053).).
As per claim 8, the combination of Underwood and Robatmili discloses (Currently Amended) The method of claim 6 [See rejection to claim 6 above], further comprising: amending, at the iterator unit, one or more previously generated tasks based on or in response to the updated current system information, wherein at least one characteristic of the amended one or more previously generated tasks is dependent on the updated current system information (e.g. Robatmili: further teaches amending previously generated tasks/partitions based on updated system information. Specifically, when a task completes on a processor core, the status table is updated to reflect core availability, and the controller then divides remaining divisible partition of ongoing tasks into subpartitions and amends the task allocations by reassigning subpartitions to the available core (Abstract, paragraphs 0006, 0037, 0050-0052, 0058, 0065-0066, 0068, 0071, 0074, 0087-0089).).
As per claim 9, the combination of Underwood and Robatmili discloses The method of claim 8 [See rejection to claim 8 above], wherein amending the one or more previously generated tasks comprises one or more of: resizing at least one of the tasks or reallocating at least one of the tasks to a different execution unit (e.g. Robatmili: discloses amending previously generated tasks by resizing (subpartitioning/subdividing) and reallocating them to different execution units. Specifically, when a task completes and a core becomes available, the controller divides remaining divisible partitions of ongoing tasks into subpartitions [resizing], and reallocates/reassigns those subpartitions to the available core (paragraphs 0006, 0050-0056). Robatmili explains that partition size is adjusted based on minimum split size and availability, and subpartitions are assigned to different cores (paragraphs 0035, 0053, 0058, 0065).).
As per claim 10, the combination of Underwood and Robatmili discloses (Currently Amended) The method of claim 1 [See rejection to claim 1 above], wherein the current system information is indicative of a current status of at least one component at the data processor unit (e.g. Robatmili: discloses system information indicative of current status of components at the data processor unit. Specifically, Robatmili teaches status tables and local tables that store current partition execution status, pointer values indicating iteration progress, core availability, and task completion status, updated in real-time as tasks execute or complete (Abstract, paragraphs 0004-0011, 0050-0056). For example, local tables track current iteration execution via pointers updated with each iteration, and status tables reflect current core availability when tasks finish (paragraphs 0006-0007, 0056). These tables indicate current status of components such as processor core (availability), partitions (execution progress), and tasks (completion status). Underwood: also discloses system information indicative of current status of components, such as command stream progress counts automatically incremented during execution (paragraph 0083), scoreboard block tracking current processing job completion for command stream interfaces (par. 0149), firmware/hardware state vectors reflecting current state saved during operation (paragraphs 0097, 0113), and suspend buffers storing current hardware/firmware status (paragraphs 0115-0116). These indicate current status of components like command streams, hardware units, and processing jobs.) .
As per claim 11, the combination of Underwood and Robatmili discloses (Currently Amended) The method of claim 10 [See rejection to claim 10 above], wherein the status of the least one component comprises: a storage unit; an execution unit; a processing job; a processing task (e.g. Underwood: discloses status information of execution units (shader cores), processing jobs (command streams), and processing tasks. Specifically, the scoreboard block tracks current completion status of processing jobs/tasks for command stream interfaces (par. 0149), progress count track current status of command stream processing jobs (par. 0083), and state vectors/suspend buffers track hardware unit status (shader cores) and firmware state for processing jobs (paragraphs 0097,0113). Robatmili: also discloses system information indicative of current status of components including execution units (processor cores), processing jobs (iteration spaces/repetitive processes), and processing tasks (partitions). Specifically, the status table and local tables track current status of processor cores (availability), and partitions/tasks execution progress or completion via pointers (Abstract, paragraphs. 0004-0011, 0050-0056) The status table reflects core availability and partition/task completion.).
As per claim 12, the combination of Underwood and Robatmili discloses (Currently Amended) The method of claim 1 [See rejection to claim 1 above], further comprising: generating the workload based on or in response to policy information in storage at the data processor unit (e.g. Underwood: discloses generating workload using policy information stored at the accelerator. Specifically, Underwood teaches that command stream interfaces have associated local memory and registry storing state parameters for processing jobs (par. 0067), and that commands set parameters for processing job in this local storage before RUN commands send the state vector (parameters) to iterator for task generation (paragraphs 0072-0074). Underwood further discloses that command stream interface configuration includes setting priority of the command stream interface (par. 0063), and that the supervising controller (MCU) schedules command streams based on priority and other parameters (paragraphs 0070, 0111). These stored priorities and state parameters constitute policy information used to generate and schedule workloads/tasks.).
As per claim 13, the combination of Underwood and Robatmili discloses (Currently Amended) The method of claim 1 [See rejection to claim 1 above], further comprising: generating the workload based on or in response to job information in the first request from the host processor unit, wherein the job information comprises pre-defined parameters which specify the characteristics of the first processing job (e.g. Underwood: teaches that command streams contain commands to set parameters for processing jobs, such as MOVE commands that load parameter values into local memory/registry to initialize or modify the state vector before a RUN command sends the state vector (job parameters) to the iterator for task generation (paragraphs 0072-0074). Underwood explains that a typical sequence includes initial commands for setting parameters for the processing job, followed by a command to execute the job using those parameters (paragraph 0072), and then RUN commands send the state vector (parameters) to iterator (paragraph 0156). Paragraph 0067 further discloses that each command stream interface has associated local memory/registry storing state parameters for processing jobs. These pre-defined parameters in the host request specify characteristics of the job, such as processing parameters used by the iterator to generate tasks.).
As per claim 14, the combination of Underwood and Robatmili discloses The method of claim 1 [See rejection to claim 1 above], further comprising outputting the one or more tasks for distribution to the one or more execution units to perform the respective tasks allocated thereto, where the one or more execution units comprise graphics cores or neural engines (e.g. Underwood: discloses outputting tasks for distribution on execution units, specifically shader cores (graphics cores). Underwood teaches that iterators output processing tasks to shader cores for execution, as the iterator breaks the processing job into tasks which are then issued to the processing core (shader cores), and each shader core comprises an endpoint that takes a task and issues it to thread groups (paragraphs 0076,0150, 0156). Fig. 2 illustrates shader cores as execution units receiving tasks from iterators (See Figs. 1, 2 and related description). Thus, Underwood teaches outputting tasks for distribution to execution units comprising graphics cores.).
As per claim 15, this is a data processor unit (system) claim having similar limitations as cited in method claims 1 and 14. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of rejected claims 1 and 14.
As per claim 16, this is a data processor unit (system) claim having similar limitations as cited in method claim 14. Thus, claim 16 is also rejected under the same rationale as cited in the rejection of rejected claim 14.
As per claim 18, this is a medium claim having similar limitations as cited in method claim 1. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of rejected claim 1. Furthermore, Underwood and Robatmili disclose A non-transitory computer readable storage medium comprising code which when implemented on a processor causes the processor to perform method of claim 1 (e.g. Underwood: [0136] [0138] [Claim 20]. Robatmili: [0015] [0104] [Claim 20].).
Response to Arguments
Applicant’s argument with respect to 35 U.S.C. § 112 (a) and 112(b) are persuasive. The rejections under to 35 U.S.C. § 112 (a) and 112(b) are withdrawn.
Applicant’s arguments with respect to 35 U.S.C. § 103, on pages 11-15 of the remarks, have been fully considered but they are not persuasive.
Applicant argues (page 13) that Underwood “shows a host processor running an operating system and driver that prepares static command streams in advance to control an accelerator” and that these command streams “are not capable of monitoring or adapting to real-time hardware status changes at the accelerator level during execution.” Thus, Underwood does not disclose or suggest “generating a workload comprising one or more tasks…wherein a size and/or a number of one or more tasks in the workload is dependent on the current system information.”
Response: This argument is not persuasive because the rejection is based on the combination of Underwood and Robatmili, not Underwood alone. Underwood is relied upon for the claimed host/GPU architecture, including host-generated processing requests/command streams, MCU-controlled job submission, iterator-based processing-job division, and shader-core execution of tasks (Underwood [0051-0058, 0070, 0074-0076, 0145-0156, Figs. 1-3]). Robatmili is relied upon for the express teaching of current status/availability information used in selecting task/partition number and/or task/partition size (Robatmili: [0005-0011, 0035, 0037, 0053, 0057-0058, 0064-0065, 0078-0089]). The claims require that the iterator generate a workload based on current system information. The proposed modification applies Robatmili’s known current resource-aware partitioning criteria when Underwood’s iterator generates tasks after receiving the processing job.
Applicant argues that Robatmili “shows a loop-splitting scheme that partitions the iteration space of a repetitive process and distributes sub-partitions to available processor cores…using a shared status table,” but characterizes Robatmili as “a software-managed, software-driven dynamic runtime system that relies on global synchronization.” Applicant further asserts that this approach causes “cache pollution and bus-clogging coherence traffic.” Therefore, Robatmili does not teach or suggest an on-chip, localized hardware control circuit and iterator unit that can lead local registers to partition tasks without generating bus-clogging traffic.
Response: These arguments are not persuasive. First, Examiner respectfully points out that the asserted distinctions are not commensurate with the scope of amended independent claims 1, 15 and 18. The claims do not expressly recite an iterator localized at a particular on-chip location, a control circuit limited to a localized hardware-only implementation, system information stored in local registers, iterator access to local registers, exclusion of a shared status/local tables, exclusion of synchronization between execution resources, an architecture that avoids global coordination of status information, or a requirement that task/workload generation be performed without firmware, software, or a combination of. Rather, the amended claims broadly recite storage holding current system information indicative of component status relating to execution unit availability and/or available storage, and generation of a workload in which task size and/or task numbers depends on that current system information. Further, the Applicant’s own specification ([0046, 0062-0063]) states that system information storage may comprise volatile/nonvolatile memory, may be integrated as part of the GPU, or may be part of respective core or engines. The system information may be updated or maintained by firmware running at the GPU and may be accessible by the iterator unit. Thus, the specification does not limit the claimed system storage to local registers only, nor does it exclude data structure, firmware updates, coordination among cores, synchronization, cache-based storage, or interconnect communication.
Moreover, these arguments are not persuasive because Applicant’s characterization of Robatmili as exclusively “software-managed” and dependent on global synchronization causing cache pollution and bus-coherency traffic is contrary to the express teaching of Robatmili. Robatmili first identifies that software-based dynamic partitioning schemes using shared-memory iteration-space storage may lead to cache pollution and coherence traffic due to processor-core inspection and synchronization. Robatmili then teaches its own hardware-based approach to address the problem. Robatmili teaches a hardware-based solutions: implementing the dynamic iteration space splitting scheme in hardware with descriptor table 404, status table 406, and multiple local tables in cache memory (Robatmili: [0050-0053] [Fig. 4]).
Robatmili also teaches core-associated local tables. A local controller is associated with each processor/core to track task iterations assigned to that core and relay status information to the descriptor table and status table. The local tables maintain core-associated task progress information. Thus, Robatmili is not limited to a central shared status table without local status structures; it expressly discloses both central status structure and core-associated local structures in a hardware iteration-space splitter ([0005, 0050, 0057-0058, 0068, Fig. 5C]).
Accordingly, Applicant’s characterization of Robatmili is not supported by the reference. More importantly, Applicant has not identified a limitation in the pending claims requiring asserted localized/no-shared-status and no-synch/no-coherency-traffic architecture. The arguments therefore do not establish a patentable distinction over Underwood in view of Robatmili.
Applicant argues that Robatmili “does not disclose or suggest generating a workload comprising one or more tasks…wherein a size and/or a number of the one or more tasks in the workload is dependent on the current system information” and therefore does not cure Underwood’s alleged deficiency.
Response: This argument is not persuasive. Robatmili expressly teaches partitioning a repetitive process by a number of partitions equivalent to a number of available processors or processor cores (Robatmili [0006]). Robatmili [0035] further teaches that the number of tasks may equal the number of available processors or processor cores. Robatmili explains that the central controller may generate tasks/partitions based on available processor cores, and that the number of tasks/partitions may be based on available processors/cores ([0064, 0078-0079]. Robatmili also teaches selecting partition size based on core type, performance characteristics, availability, resource requirements, latency tolerance, processor/core characteristics, temperature, and power availability ([0053, 0078-0081, 0087-0089]). Thus, Robatmili explicit teaching that task/partition number corresponds to available processors/cores count satisfies the execution-unit-availability and task-number.
Applicant argues that there is an “architectural mismatch” between Underwood and Robatmili and that there would be no reasonable expectation of success because Underwood uses a command-stream frontend where and MCU sends a state vector to a hardware iterator, whereas Robatmili uses a central controller and tables synchronized with local tables. And “incorporating the table-driven central controller and continuous synchronization scheme” of Robatmili into Underwood would alter the intended operation of Underwood and require a fundamental redesign of Underwood’s job-submission and management architecture.
Response: These arguments are not persuasive. The rejection does not propose replacing Underwood’s entire command-stream frontend or its iterator architecture with Robatmili’s entire iteration-space-splitter architecture. Underwood remains operative for host-to-GPU command submission, MCU control, state-vector delivery, iterator-based task generation, and shader-core execution (e.g., Underwood: [0070-0076, 0145-0156]). The modification is limited to incorporating Robatmili’s known resource-aware task-generation criteria—current execution-resource availability and system information—when Underwood’s iterator determines task number and/or task size.
The references concern closely related technical problems. Underwood teaches a multi-core GPU task-distribution architecture in which an iterator divides a processing job into tasks and distributes the tasks to shader cores (e.g., Underwood [0076, 0150, 0156]). Robatmili teaches hardware-based generation, partitioning, and assignment of work among multiple processor cores, and expressly identifies a GPU as a possible multi-core hardware environment (Robatmili: [0033, 0045-0049, 0050-0053]). A POSITA would have recognized that use of known resource availability-aware task partitioning criteria in Underwood’s iterator state would predictably improve load balancing, available core utilization, task distribution, and throughput. The proposed modification therefore would have had a reasonable expectation of success.
Furthermore, Underwood itself is not limited to an architecture excluding shared state, controller/firmware involvement, or synchronization. Underwood teaches that MCU 25 schedules command streams and communicates with the host processor through shared interface memory (Underwood: [0070, 0151]). Underwood teaches a shared scoreboard block that independently tracks command-stream job completion and task progress (Underwood [0149]). Underwood further teaches that some command operations are implemented in hardware and others are emulated in MCU software/firmware, including synchronization commands (Underwood [0071, 0147-0148, 0153-0155]). Accordingly, Applicant’s characterization of Underwood as an architecture that is incompatible with shared cache, status tracking, controller involvement, synchronization, or interconnect communication is not supported.
Again, the proposed modification does not require replacement of Underwood’s architecture. The modification merely configures Underwood’s iterator-driven task generation to use current stored execution-resource information, as taught by Robatmili, in determining task number and/or size. This is an incremental and predictable modification, not a fundamental redesign.
In view of above discussion and detailed office action above, the rejection of claims 1, 3-16 and 18 under 35 U.S.C. 103 over Underwood in view of Robatmili is maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Cheng et al. (US 2020/0342292 A1) is relevant because it teaches tracking a number of computing units having current running state idle; and dividing the convolution task into convolution subtasks with a number equivalent to the number of idle units (see [0007]).
Chamieh et al. (US 2008/0134207 A1) discloses monitoring the computing environment and keeping track (metrics) for number of processors or engines available on a remote grid used in multiprocessing; and dividing the job speedup with the number of processors available and dedicated to the execution of the job (see [0301 and 0521]).
Santos et al. (US 2016/0217410 A1) discloses maintaining/updating system information in a stored worker list, including remaining availability of workers. A processor automatically divides tasks into a number of subtasks and assigns the workers based on the availability of selected workers (see [0007 and 0036]).
Barham et al. (US 2012/0159506 A1) discloses the system divides the job into one or more tasks wherein each task is suitable for performing on one of the available computing resources… Many types of computing problems can be divided into independent tasks that can be performed and then combined to produce a result. The system may divide the job based on a quantity of available computing resources, based on demands associated with each task, or other criteria that relate to how efficiently each task will execute on the available computing resources. (See [0044, 0022]). The system dynamically identifies available set of machines (processors, memory and storage). A central global job scheduler accepts jobs and identifies efficient way to partition computations given the current set of available resource, current set of jobs, and their associated QoS parameters ( see [0012, 0014]). Also see [0019-0020, 0028-0029, 0038-0039].
Montesinos Ortego et al. (US 2015/0268993 A1) discloses iteration of the repetitive process may be divided into partitions for execution as part of the initialized tasks in parallel, wherein the number of partitions may be determined by the number of available processors or processor cores. The make up of each partition may be determined by various factors including characteristics of processor or processor cores, characteristics of the program and/or states of the computing device (See [0057, 0073]).
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 Hiren Patel whose telephone number is (571) 270-3366. The examiner can normally be reached on Monday-Friday 9:30 AM to 6:00 PM.
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, April Y. Blair, can be reached at the following telephone number: (571) 270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions on access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
September 23, 2026
/HIREN P PATEL/Primary Examiner, Art Unit 2196
