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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 5, 12, and 19 rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 5 recites "one or more instructions have been scheduled to be performed using one or more indications of one or more processor settings". This is meaningfully indistinct from the independent claim it depends on, which states that the instructions are "to be performed based, at least in part, on one or more processor setting inputs to the API". Claims 12 and 19 recite substantially the same limitations, applied to claim 8 and claim 15 respectively, and are rejected for the same reasons presented with respect to claim 5. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1,2, 5-9, 12, 14-16, and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Wysocki et. al. ("CPU Performance Scaling", 2019), hereinafter Wysocki.
Regarding Claim 1, Wysocki recites:
A processor comprising: one or more circuits to perform an application programming interface (API) to cause one or more instructions to be performed based, at least in part, on one more processor setting inputs to the API. (see e.g., page [02], paragraphs [01-03], “The Linux kernel supports CPU performance scaling by means of the CPUFreq (CPU Frequency scaling) subsystem that consists of three layers of code: the core, scaling governors and scaling drivers. The CPUFreq core provides the common code infrastructure and user space interfaces for all platforms that support CPU performance scaling. It defines the basic framework in which the other components operate. Scaling governors implement algorithms to estimate the required CPU capacity. As a rule, each governor implements one, possibly parametrized, scaling algorithm.”) The processor setting inputs to the API can be considered the scaling algorithm (parameterized).
Regarding Claim 2, Wysocki recites:
The processor of claim 1, wherein an indication of the one or more instructions and an indication of one or more processor settings have been stored in a queue of a scheduler. (see e.g., page [08], paragraph [04], “This governor uses CPU utilization data available from the CPU scheduler. It generally is regarded as a part of the CPU scheduler, so it can access the scheduler’s internal data structures directly.”)
Regarding Claim 5, Wysocki recites:
The processor of claim 1, wherein the one or more instructions have been scheduled to be performed using one or more indications of one or more processor settings. (see e.g., page [02], paragraphs [01-03], “The Linux kernel supports CPU performance scaling by means of the CPUFreq (CPU Frequency scaling) subsystem that consists of three layers of code: the core, scaling governors and scaling drivers. The CPUFreq core provides the common code infrastructure and user space interfaces for all platforms that support CPU performance scaling. It defines the basic framework in which the other components operate. Scaling governors implement algorithms to estimate the required CPU capacity. As a rule, each governor implements one, possibly parametrized, scaling algorithm.”) The processor setting inputs to the API can be considered the scaling algorithm (parameterized).
Regarding Claim 6, Wysocki recites:
The processor of claim 1, wherein the API causes a processor management application to identify whether one or more processor settings based, at least in part, on the one or more processor setting inputs, have been set on one or more processors to be used to perform the one or more instructions. (see e.g., page [03], paragraph [06], “Once invoked, the CPUFreq core checks if the policy pointer is already set for the given CPU and if so, it skips the policy object creation. Otherwise, a new policy object is created and initialized, which involves […]”)
Regarding Claim 7, Wysocki recites:
The processor of claim 1, wherein the API causes a processor management application to modify one or more processor settings based, at least in part, on the one or more processor setting inputs, prior to performance of the one or more instructions. (see e.g., page [03], paragraphs [04-06], “The scaling driver may be registered before or after CPU registration. If CPUs are registered earlier, the driver core invokes the CPUFreq core to take a note of all of the already registered CPUs during the registration of the scaling driver. In turn, if any CPUs are registered after the registration of the scaling driver, the CPUFreq core will be invoked to take note of them at their registration time.
In any case, the CPUFreq core is invoked to take note of any logical CPU it has not seen so far as soon as it is ready to handle that CPU. [Note that the logical CPU may be a physical single-core processor, or a single core in a multicore processor, or a hardware thread in a physical processor or processor core. In what follows “CPU” always means “logical CPU” unless explicitly stated otherwise and the word “processor” is used to refer to the physical part possibly including multiple logical CPUs.]
Once invoked, the CPUFreq core checks if the policy pointer is already set for the given CPU and if so, it skips the policy object creation. Otherwise, a new policy object is created and initialized, which involves the creation of a new policy directory in sysfs, and the policy pointer corresponding to the given CPU is set to the new policy object’s address in memory.”)
Claim 8 recites: A system, comprising: one or more processors to perform the same steps as performed by the processor of claim 1. Therefore, it is rejected as being anticipated by Wysocki for the same reasons presented with respect to claim 1.
Regarding claim 9, Wysocki recites:
The system of claim 8, wherein one or more jobs comprising the one or more instructions have been scheduled to be performed by a job scheduler. (see e.g., page [04], paragraph [02], “The utilization update callbacks will be invoked by the CPU scheduler on important events, like task enqueue and dequeue, on every iteration of the scheduler tick or generally whenever the CPU utilization may change (from the scheduler’s perspective).”)
Claim 12 recites substantially the same limitations as claim 5, applied to the apparatus of claim 8. As such, claim 12 is rejected as being anticipated by Wysocki for the same reasons presented with respect to claim 5.
Claim 14 recites substantially the same limitations as claim 7, applied to the apparatus of claim 8. As such, claim 14 is rejected as being anticipated by Wysocki for the same reasons presented with respect to claim 7.
Claim 15 recites: A method, comprising: performing the same steps as performed by the processor of claim 1. Therefore, it is rejected as being anticipated by Wysocki for the same reasons presented with respect to claim 1.
Claim 16 recites substantially the same limitations as those listed in claim 9, applied to the method of claim 15. Therefore, it is rejected as being anticipated by Wysocki for the same reasons presented with respect to claim 9.
Claim 19 recites substantially the same limitations as claim 5, applied to the method of claim 15. Therefore, it is rejected as being anticipated by Wysocki for the same reasons presented with respect to claim 5.
Claims 13 and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by LACT README (Release 0.4.2, March 2021), henceforth Lact.
Regarding Claim 8, Lact recites:
A system, comprising: one or more processors to perform an application programming interface (API) to cause one or more instructions to be performed based, at least in part, on one more processor setting inputs to the API. (see e.g., page [01], paragraphs [01-10], “Current features: • Viewing information about the GPU • Power/thermals monitoring • Fan curve control • Basic overclocking”) (see also e.g., page [01], paragraphs [17-21], “Usage Enable and start the service (otherwise you won’t be able to change any settings):”) The examiner, for clarification, would explain that setting up overclocking on a GPU would count as “instructions based on processor setting inputs”, and that the service described is an API, as it runs in the background so that an application (i.e., the GUI control app) may interface with it.
Regarding Claim 13, Lact recites:
The system of claim 8, wherein the API causes a processor management application to identify whether one or more processor settings based, at least in part, on the one or more processor setting inputs, have been set on one or more graphics processing units (GPUs) to be used to perform the one or more instructions. (see e.g., page [01], figure [02] (screenshot included), shows current settings and a slider bar to change said settings. Also shows a “performance level” dropdown, which is set to “automatic” if the user has never changed that setting.
Claim 20 recites substantially the same limitations as claim 13, applied to the method of claim 15 (which contains substantially the same limitations as claim 8 – just as a method instead of a system). Therefore, it is rejected as being anticipated by Lact for the same reasons presented with respect to claim 13.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Wysocki.
Regarding Claim 3, Wysocki teaches:
The processor of claim 1, wherein the one or more instructions are to be performed by one or more processors
Wysocki fails to explicitly teach:
of a data center.
However, it would be obvious to one of ordinary skill in the art to apply the kernel configuration and API to manage processor settings as taught by Wysocki to data centers. This would allow for the processors of a data center to dynamically change p-states as needed to prevent thermal or power supply problems (see e.g., Wysocki, page [01], paragraph [02], “In some other cases, however, it may not be necessary to execute instructions so quickly and maintaining the highest available CPU capacity for a relatively long time without utilizing it entirely may be regarded as wasteful. It also may not be physically possible to maintain maximum CPU capacity for too long for thermal or power supply capacity reasons or similar. To cover those cases, there are hardware interfaces allowing CPUs to be switched between different frequency/voltage configurations or (in the ACPI terminology) to be put into different P-states.”)
Claims 4, 10, 11, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Wysocki as applied to claims above, and further in view of Srinivasan et al (US Pub. no. 2019/0384348), hereinafter Srinivasan.
Regarding Claim 4, Wysocki teaches:
The processor of claim 1
Wysocki fails to teach wherein the one or more processor setting inputs comprise one or more indications of priority of the one or more instructions.
However, Srinivasan teaches:
wherein the one or more processor setting inputs comprise one or more indications of priority of the one or more instructions. (see e.g., page [019], paragraph [040], “Each one of the software objects may run at a target service level which can be provided by processing cores running at different base clock frequency values.”) The service level is being considered a kind of “indication of priority”.
Regarding claim 10, Srinivasan recites:
The system of claim 8, wherein the one or more instructions are to be performed by one or more graphics processing units (GPUs) of a GPU cluster. (see e.g., page [020], paragraphs [0055-0056], “The execution cluster(s) 560 includes a set of one or more execution units 562 and a set of one or more memory access units 564. The execution units 562 may perform various operations (e.g., shifts, addition, subtraction, multiplication) and operate on various types of data ( e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). [0056] While some embodiments may include a number of execution units dedicated to specific functions or sets of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions.”)
Claim 11 recites substantially the same limitations as claim 4, applied to the system of claim 8. Therefore, it is rejected as being anticipated by Wysocki in view of Srinivasan for the same reasons presented with respect to claim 4.
Claim 17 recites substantially the same limitations as claim 10, applied to the method of claim 15. Therefore, it is rejected as being anticipated by Wysocki in view of Srinivasan for the same reasons presented with respect to claim 10.
Claim 18 recites substantially the same limitations as claim 4, applied to the method of claim 15. Therefore, it is rejected as being anticipated by Wysocki in view of Srinivasan for the same reasons presented with respect to claim 4.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Connor Imiola Blackburn whose telephone number is (571)272-6547. The examiner can normally be reached M-Th 7-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached at (571) 270 - 3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.I.B./Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights