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
The present application having Application No. 18/316,125 filed on 05/11/2023 presents claims 1-18 for examination.
The information disclosure statement (IDSs) submitted on 02/20/2025 and 09/24/2025 have been considered by the examiner
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.
Drawings
The applicant’s drawings submitted are acceptable for examination purposes.
Claim Objections
Claim 1-14 are objected to as being of improper form because the claim is drafted as a method claim, but begins by reciting system components in a manner that creates ambiguity as to whether certain limitations are intended to be method limitations or structural limitations subject to interpretation under 35 U.S.C. 112(f). In particular, in claim 1, the phrase “A method of operating a data processor unit to generate processing tasks the data processor unit comprising:…” awkwardly blends a method claim format with an apparatus-style “comprising” recitation and may obscure the metes and bounds of the claim. Applicant is required to clarify the claim format.
Dependent claims 2-14 are objected for the reasons discussed above based on virtue of their dependency to claim 1.
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 Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 15-18 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As per claim 15, the limitations “an iterator unit to process/generate…”, and “one or more execution units to perform…” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim 15 fails to comply with the written description requirement because the specification does not provide adequate corresponding structure for the claims 112(f) limitations. For a computer-implemented 112(f) limitations, the specification must disclose an algorithm for performing the claimed function, in addition to a general-purpose processor or generic hardware reference. Applicant’s specification describes the “iterator unit” (paragraphs [0004-0005] [0030] [0039] [0042] [0049-0054] [0058-0059], etc.) primarily in terms of desired results and high-level functionality, e.g., processing a job request, dividing or partitioning the iteration space into tasks, taking account of system information, allocating tasks to execution units, and outputting the task for distribution. Similarly, the specification describes “execution units” (paragraphs [0004-0005] [0053] [0058] [0083] [0085-0086]) performs claimed functionality, where the execution units can be graphics core or neural engines. However, the specification does not disclose a sufficiently definite algorithm/structure corresponding to the full claimed functions of the “iterator unit” and “execution units” as recited in claim 15, particularly for generating the workload “based on or in response to system information in storage such that at least one characteristic of the workload is dependent on the system information” and outputting the tasks for distribution to execution units. Accordingly, a POSITA would not reasonably conclude that applicant had possession of the full scope of the claimed computer-implemented 112(f) limitations at the time of filing.
The dependent claims 16-17 are also rejected based on virtue of their dependency to independent claim 15.
Claim 18 is also rejected under 112(a) as failing to comply with written description requirement because the claim incorporates the same functional language as claim 15 in medium form, including the “iteration unit” and “execution units” limitations that are interpreted under 112(f), yet the specification fails to provide adequate corresponding structure and algorithm for those limitations. Although claim 18 is drafted as a non-transitory medium claim, the underlying computer-implemented functional limitations still require sufficient structural and algorithmic support in the specification when interpreted under 112(f).
Claim 18 is rejected for the same reasons set forth above with respect to claim 15.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 15-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim limitations “an iterator unit to process/generate…”, and “one or more execution units to perform…” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, algorithm, workflow, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The broadest reasonable interpretation of 35 U.S.C. 112(f) limitation is limited to the corresponding structure, material, or acts described in the specification. When no such adequate corresponding structure is disclosed, the claim is indefinite. As discussed above, the specification fails to disclose sufficient corresponding structure, including a sufficiently definite algorithm, for the “iteration unit to process/generate…” and “execution units to perform…” beyond generic references to cores or engines performing tasks, without clearly linking definite corresponding structure to the full scope of the claimed function as interpreted under 35 U.S.C. 112(f). Therefore, claim 15 fails to particularly point out and distinctly claim the subject matter which applicant regards as the invention. The claim fails to inform POSITA of metes and bounds with reasonable certainty such that the claim will cover all ways of performing a functions, known and unknown. Such an unbounded limitations render the claim indefinite. Therefore, the claims are indefinite and are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
The dependent claims 16-17 are also rejected based on virtue of their dependency to independent claim 15.
Claim 18 is rejected for the same reasons set forth above with respect to claim 15.
Claims 10-12 are rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 10 and 12 recite the limitation "the target processor unit" in lines 2 and 3, respectively. There is insufficient antecedent basis for this limitation in the claims.
Claim 11 is rejected based on virtue of its dependency to claim 10.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 15 and 18 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 15 and 18 of Co-pending U.S. Patent No. 18/355,282 in view of Underwood et al. (US 2020/0050478 A1) and Robatmili et al. (US 2016/0292012 A1).
This is a provisional nonstatutory obvious type double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1, 15 and 18 are compared to claims 1, 15 and 18 of the reference application in the following table:
Current US Application No :
18/316,125
Co-pending US Application No : 18/355,282
Claim 1. A method of operating a data processor unit to generate processing tasks: the data processor unit comprising:
a control circuit to receive, from a host processor unit, a request for the data processor unit to perform a processing job;
an iterator unit to process the request and generate a workload comprising one or more tasks for the requested job;
one or more execution units to perform the one or more tasks;
the method comprising: receiving, at the control circuit, a first request to perform a first processing job;
processing, at the iterator unit, the first request and generating a workload comprising one or more tasks for the first processing job…
storage to store system information indicative of a status of at least one component of the data processor unit;
generating a workload…based on or in response to the system information in storage, wherein at least one characteristic of the workload is dependent on the system information.
Claim 18. A method of operating a data processing resource to perform data processing tasks for a host processor, the data processing resource comprising: control circuitry to receive, from the host processor, a request for the data processing resource to perform a requested processing job;
an iterator unit to process the request and generate a workload comprising one or more tasks for the requested processing job; and
one or more execution units to perform the one or more tasks, wherein the iterator unit is configured to allocate the one or more tasks to the one or more execution units
control circuitry to receive, from the host processor, a request for the data processing resource to perform a requested processing job;
an iterator unit to process the request and generate a workload comprising one or more tasks for the requested processing job;
The co-pending application does not expressly disclose but the combination of Underwood et al. (US 2020/0050478 A1) and Robatmili et al. (US 2016/0292012 A1) discloses storage to store system information indicative of a status of at least one component of the data processor unit (e.g. Underwood: [Fig. 2, element (22)] [0146] See paragraphs [0067, 0083, 0097-0104, 0113-0118, 0146, 0149, 0151 and 0154]); and generating a workload…based on or in response to the system information in storage, wherein at least one characteristic of the workload is dependent on the system information (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). Also see [0076] [0150]. Robatmili: discloses an iterator space splitter in which information about the iteration space for a repetitive process is stored in a descriptor table and status information for all partitions of a process is stored in a status table. See [Abstract] [0004-0011, 0034-0037, and 0050-0056]. Thus Robatmili teaches storage maintaining system information and status information indicative of the status of components, including processor cores and task/partition execution state. [0064] the controller may compare the iteration space size against the minimum split size stored in the descriptor table and may generate multiple tasks and partitions having number of iterations. For example, the number of tasks may be equal to the number of partitions, or to the number of available processors or processor cores. More specifically, Robatmili teaches that the number of tasks is dependent on available number of processor cores. Paragraph [0006] states that the iteration of the process may be partitioned “by a number of partitions equivalent to a number of available processors or processor cores.” Paragraph [0035] similarly states that the number of tasks may be equal to the number of available processors or processor cores. [0053] Robatmili also teaches that the central controller may determine the size of various partitions and which processor or processor core to assign each partition based on various criteria, including the type, performance characteristics, and/or availability of the processor or processor core, and the resource requirements, or latency tolerance of the execution of the processes. Therefore, Robatmili expressly teaches generating a workload whose characteristics, such as number of tasks and partition size, are dependent on system information stored in tables and indicative of available resources and core status.)
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the co-pending application with teachings of Underwood and Robatmili as discussed above because it would have predictably improved task distribution and load balancing across available execution resources, thereby improving throughput, utilization, and responsiveness of the co-pending application.
Also see detailed mappings for these limitations below under 103 rejection
Claim 15
Claim 1 Or Claim 15 in view of Underwood et al. (US 2020/0050478 A1) and Robatmili et al. (US 2016/0292012 A1); See mapping above.
Claim 18
Claim 18 in view of Underwood et al. (US 2020/0050478 A1) and Robatmili et al. (US 2016/0292012 A1); See mapping above.
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-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 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]. 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 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.); 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 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.); 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 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 storage of status/state information and teaches that an iterator splits a processing job into tasks, but does not expressly disclose that the iterator’s workload generation characteristics, such as the number of tasks, partition size, or other workload characteristics, are determined based on stored system information indicative of component status. Specifically, Underwood does not expressly disclose generating a workload…based on or in response to the system information in storage, wherein at least one characteristic of the workload is dependent on the system information.
However, Robatmili teaches the above missing feature (Robatmili: discloses an iterator space splitter in which information about the iteration space for a repetitive process is stored in a descriptor table and status information for all partitions of a process is stored in a status table. Each processor core may have an associated local table that tracks iteration execution of each task and is synchronized with the status table. See [Abstract] [0004-0011, 0034-0037, and 0050-0056]. Thus Robatmili teaches storage maintaining system information and status information indicative of the status of components, including processor cores and task/partition execution state. [0064] the controller may compare the iteration space size against the minimum split size stored in the descriptor table and may generate multiple tasks and partitions having number of iterations. For example, the number of tasks may be equal to the number of partitions, or to the number of available processors or processor cores. More specifically, Robatmili teaches that the number of tasks is dependent on available number of processor cores. Paragraph [0006] states that the iteration of the process may be partitioned “by a number of partitions equivalent to a number of available processors or processor cores.” Paragraph [0035] similarly states that the number of tasks may be equal to the number of available processors or processor cores. [0053] Robatmili also teaches that the central controller may determine the size of various partitions and which processor or processor core to assign each partition based on various criteria, including the type, performance characteristics, and/or availability of the processor or processor core, and the resource requirements, or latency tolerance of the execution of the processes. Therefore, Robatmili expressly teaches generating a workload whose characteristics, such as number of tasks and partition size, are dependent on system information stored in tables and indicative of available resources and core status.).
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 generate workload based on stored system information, as taught by Robatmili, such as information indicating available processor cores, partition status, and processor/core characteristics. Doing so would have predictably improved task distribution and load balancing across available execution resources, thereby improving throughput, utilization, and responsiveness of Underwood’s acceleration system. Robatmili expressly teaches that dynamic partitioning based on available cores and stored status information enables load balancing and efficient scheduling without interrupting execution (See [0053-0054]), and a POSITA would have recognized these same benefits as applicable to Underwood’s iterator-based accelerator architecture.
A POSITA would have had reason to incorporate Robatmili’s known status-table driven partitioning technique into Underwood’s known iterator based job-to-tasks architecture because both references are directed to parallel task generation and assignment in multi-core multi-unit processing environment, and the proposed modification would merely use a known technique to improve a similar device by making task generation more adaptive to available execution resources.
As per claim 2, the combination of Underwood and Robatmili discloses The method of claim 1 [See rejection to claim 1 above], where the system information comprises real-time or current system information (e.g. Underwood: discloses dynamic storage of current system status information that is updated during operation, such as command stream progress counts that are automatically incremented when command are executed (paragraph 0083), firmware and hardware state vectors saved to suspended buffers during mode switches (paragraphs 0097, 0113), scoreboard block that independently tracks current processing job completion for each command stream interface (paragraph 0149), and MCU firmware state and hardware state that are saved and restored based on current operation (paragraphs 0115-0116). These are real-time or current system information because they are updated during execution and processing jobs, reflecting the current status of components such as command streams, hardware units, and processing jobs. Robatmili: also discloses real-time status information maintained in the status table and local tables, which are updated as partitions complete and cores become available (Abstract, paragraphs 0004-0011, 0034-0037, 0050-0056, 0065). Thus, Robatmili’s tables store current system information indicative of partition/tasks status and core availability.).
As per claim 3, the combination of Underwood and Robatmili discloses The method of claim 1 [See rejection to claim 1 above], where generating the workload comprises dividing an iteration space for a job into one or more tasks, where the number of tasks generated is dependent on the system information and/or where the size of each task generated is dependent on the system information (e.g. Robatmili: further 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 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 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 The method of claim 1 [See rejection to claim 1 above], where the data processing unit comprises a plurality of execution units and the first 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 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 The method of claim 1 [See rejection to claim 1 above], further comprising: updating the 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 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 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 The method of claim 6 [See rejection to claim 6 above], further comprising: amending, at the iterator unit, one or more of the previously generated tasks based on or in response to the updated system information, wherein at least one characteristic of the one or more amended tasks is dependent on the updated 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 subparitions are assigned to different cores (paragraphs 0035, 0053, 0058, 0065).).
As per claim 10, the combination of Underwood and Robatmili discloses The method of claim 1 [See rejection to claim 1 above], wherein the system information is indicative of a current status of at least one component at the target 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 The system of claim 10 [See rejection to claim 10 above], where 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 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 target 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 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, where the job information comprises pre-defined parameters which specify the characteristics of the first 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 17, the combination of Underwood and Robatmili discloses The data processor unit of claim 15 [See rejection to claim 15 above], where the iterator unit is configured to dynamically update a characteristic of the workload based on or in response the system information (e.g. Robatmili: discloses that the iteration space splitter controller is configured to dynamically update workload characteristics based on system information. Specifically, when a task completes, the local controller updates the local table and status table to reflect core availability, and the central controller then dynamically subdivides remaining divisible partitions (updates partition size/number) of ongoing workloads and reassigns subpartitions (updated allocation) to available cores based on the updated status table information (paragraphs 0006, 0050-0056). Robatmili teaches that partition granularity/size is dynamically adjusted based on minimum split size, available cores, and real-time status updates without interrupting execution (paragraphs 0035, 0053, 0056). Thus, Robatmili teaches the iterator dynamically updating workload characteristics (e.g., partition size, number, allocation) based on system information.).
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].).
Conclusion
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).
April 29, 2026
/HIREN P PATEL/Primary Examiner, Art Unit 2196
Prosecution Insights