DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to the communication filed 6/29/2023.
Claims 1-20 are presented for examination.
Examiner Notes
Examiner cites particular columns, paragraphs, figures 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 entirely 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.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/29/2023. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 11-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Regarding to Claim 11, Claim 11 recites “A least one computer readable medium comprising instructions”. According to the specification (particularly, [0094]-[0095]), such claimed “computer readable medium” under BRI includes signals (note: [0057] from the specification does mention “one or more non-transitory machine-readable storage media”, however, such claimed “A least one computer readable medium comprising instructions” according to current claim language of claim 11 is not necessary to be interpreted as such “one or more non-transitory machine-readable storage media”). Signals are directed to a non-statutory subject matter. Thus, Claim 11 is rejected under 35 U.S.C. 101 for directing to a non-statutory subject matter. Applicant is suggested to amend such claimed computer readable medium as: A least one non-transitory computer readable medium.
Claims 12-17 are rejected for failing to cure the deficiency from their respective parent claim by dependency.
Claim Rejections - 35 USC § 102
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.
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-3 are rejected under 35 U.S.C. 102 (a) (1) as being anticipated by Gupta et al. (US 20220066788 A1, hereafter Gupta).
Regarding to claim 1, Gupta discloses: A processor (see Fig. 8, [0002], [0056]; “which processor cores (e.g., processing units) in a multi-core architecture”, “a plurality of heterogeneous processing units 82”) comprising:
at least one first core to execute instructions; at least one second core to execute instructions, the at least one second core heterogenous from the at least one first core (see Fig. 8, [0057]-[0058]; “determine a runtime performance of the heterogeneous processing units 82 based on system-level thread characteristics”. It is understood that the heterogeneous processing units are required to execute certain instructions to produce or result in runtime performance); and
a control circuit coupled to the at least one first core and the at least one second core (see [0057]-[0058]; “at least one processing unit such as, for example, … a power and/or performance controller (not shown, e.g., on the SoC 83 or on a separate chip), etc., cause the computing system 80 and/or the at least one processing unit to perform one or more aspects of the method 20 … cause the computing system 80 and/or the at least one processing unit to determine a runtime performance of the heterogeneous processing units 82”. To allow the power and/or performance controller to determine runtime performance of heterogenous processing units, it is required that such controller circuit coupled to the heterogenous processing units), wherein the control circuit is to:
receive workload telemetry information regarding a workload for execution on the processor (see [0020]-[0021]; “system-level thread characteristics (e.g., power constraints, thermal constraints, quality of service/QoS, utilization, concurrency, thresholds, shared queue state, die location, etc.), which may be obtained from hardware (e.g., hardware counters via pcode) and/or software”);
determine a quality of service (QOS) distribution based at least in part on the workload telemetry information (see [0020]-[0021]; “determining a runtime performance of a plurality of heterogeneous processing units based on system-level thread characteristics” and “determines a runtime energy efficiency of the plurality of heterogeneous processing units based on the system-level thread characteristics”. Either one of runtime performance from [0020] or runtime energy efficiency from [0021] can be considered as claimed QOS distribution);
receive a predicted workload type, the predicted workload type based at least in part on the QoS distribution (see [0034]-[0042]; “Utilization<Threshold … Use case #1—low utilization running higher scaling threads … Utilization>Threshold … Use case #3—sustained workload … LowQoS Utilization … Use case #5—low QoS running higher scaling threads”); and
cause at least one of the at least one first core or the at least one second core to be parked based on the predicted workload type and the QoS distribution (see [0002], [0015], [0017], [0024]; “decide the core count and which cores to park/unpark based on utilization or concurrency”, “Type B processing unit is placed and/or maintained in the parked state during the high utilization and concurrency condition”, “the parking hints are not limited to performance and energy efficiency capabilities … maintains a second subset of processing units in the first performance class in the parked state based on the parking hint(s)”. Also see [0021] and [0033]; “selectively unpark one or more of the plurality of heterogeneous processing units based on the runtime performance and the runtime energy efficiency” and “lesser performant or lesser efficient processing units are parked by the core parking logic 54”).
Regarding to Claim 2, the rejection of Claim 1 is incorporated and further Gupta discloses: wherein the control circuit is to receive the workload telemetry information comprising at least one energy performance preference (EPP) value associated with a first core of the at least one first core (see [0020]-[0021]; “system-level thread characteristics (e.g., power constraints, thermal constraints, quality of service/QoS, utilization, concurrency, thresholds, shared queue state, die location, etc.), which may be obtained from hardware (e.g., hardware counters via pcode) and/or software”).
Regarding to Claim 3, the rejection of Claim 2 is incorporated and further Gupta discloses: wherein the control circuit is to group a plurality of cores comprising the at least one first core and the at least one second core into a plurality of core groups based at least in part on the EPP value (see [0020]-[0021]; “determines a runtime energy efficiency of the plurality of heterogeneous processing units based on the system-level thread characteristics, wherein the runtime energy efficiency is determined on a per efficiency class basis. For example, the heterogeneous processing units may also be grouped in real-time into efficiency classes (e.g., Efficiency Class 0, Efficiency Class 1, etc.)”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20220066788 A1, hereafter Gupta) in view of Tong et al. (WO 2020244300 A1, hereafter Tong, publication date: 12/10/2020, English translation provided by Google Patents).
Regarding to Claim 4, the rejection of Claim 3 is incorporated and further Gupta discloses: determine the QoS distribution based on the plurality of core groups (see [0020]-[0021]; “determines a runtime energy efficiency of the plurality of heterogeneous processing units based on the system-level thread characteristics, wherein the runtime energy efficiency is determined on a per efficiency class basis. For example, the heterogeneous processing units may also be grouped in real-time into efficiency classes (e.g., Efficiency Class 0, Efficiency Class 1, etc.)”; identify a group of the plurality of core groups (see [0024]; “maintains a second subset of processing units in the first efficiency class in the parked state based on the parking hint(s)”).
Gupta does not disclose: the identified group has a largest number of cores.
However, Tong disclose: identify a group of plurality of resource groups having a largest number of resource (see lines 21-24 of page 3 and lines 3-4 of page 5; “Determine the number of remaining resources and the resource pool to which each host … Migrate all virtual machines on the host with the largest number of remaining resources … Hibernate or power off the host that does not host the virtual machine” and “the computing resources include the number of CPU cores, memory capacity”. Note: it is reasonable to consider a host as a resource group; in addition, the hosts, i.e., resource groups, at Tong include CPU cores resource, and thus hibernating or power off the identified host is reasonable to be considered as hibernating or parking at least one CPU core of the host, i.e., resource/core group).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify parking cores of one identified core group from plurality of core groups from Gupta by hibernating a given host or given resource/core group via migrating the workloads of the given resource group to other resource groups from Tong, and thus the combination of Gupta and Tong would disclose the missing limitations from Gupta, since it would provide a mechanism of “reducing the power consumption” of computing environment “that effectively manages and balances user needs and performance” (see lines 3-9 of page 2 and 8th paragraph of page 3, “the embodiment of the present application provides a method for reducing the power consumption of a virtual machine cluster” and “The technical solutions provided by the embodiments of the present application can effectively manage and balance user needs and performance”).
Regarding to Claim 5, the rejection of Claim 4 is incorporated and further the combination of Gupta and Tong discloses: wherein the control circuit is to select at least one core to be parked based on the identity of the group of the plurality of core groups having the largest number of cores (see [0002], [0024] from Gupta; “decide the core count and which cores to park/unpark based on utilization or concurrency”, “the parking hints are not limited to performance and energy efficiency capabilities … maintains a second subset of processing units in the first performance class in the parked state based on the parking hint(s)”. Also see lines 21-24 of page 3 from Tong; “Determine the number of remaining resources and the resource pool to which each host … Migrate all virtual machines on the host with the largest number of remaining resources … Hibernate or power off the host that does not host the virtual machine”. No matter the core groups from Gupta, i.e., the performance classes having cores, or core groups from Tong, i.e., hosts having CPU cores, there are multiple core groups, performance classes or hosts, and thus it is understood and inherency to utilize certain identity information to distinguish different core groups, performance classes or hosts, otherwise the system is not able to identify or recognize correct group/class/host to be selected/identified).
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20220066788 A1, hereafter Gupta) in view of Tong et al. (WO 2020244300 A1, hereafter Tong, publication date: 12/10/2020, English translation provided by Google Patents) and further in view of Marshall et al. (US 20090249094 A1, hereafter Marshall).
Regarding to Claim 6, the rejection of Claim 5 is incorporated, the combination of Gupta and Tong does not disclose: wherein the control circuit is to set a parked core mask to identify the at least one core to be parked.
However, Marshall discloses: wherein the control circuit is to set a parked core mask to identify the at least one core to be parked (see Figs 1-2, [0027]; “For example, the kernel power manager 114 may create the core parking mask at 202 … As shown in FIG. 2 … The bit mask 204 includes a bit value in each cell, where “1” represents a parked core and “0” represents an unparked core … The bit mask 204 includes four parked cores, numbered (right to left, zero to seven): 3, 5, 6, and 7. It follows that cores 0, 1, 2, and 4 are unparked cores”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify parking management on processor cores from the combination of Gupta and Tong by including core parking mask managed by a scheduler from Marshall, and thus the combination of Gupta, Tong and Marshall would disclose the missing limitations from the combination of Gupta and Tong, since it provides a binary value that is the most basic value at computing field to indicate parking status of cores (see Fig. 2, [0026]-[0027] from Marshall).
Regarding to Claim 7, the rejection of Claim 6 is incorporated and further the combination of Gupta, Tong and Marshall disclose: wherein the control circuit is to communicate the parked core mask to a scheduler to prevent scheduling of tasks to the at least one core to be parked (see Figs. 1-2, [0026]-[0028], [0033] and [0061] from Marshall; “creating a core parking mask and implementing the mask with the thread scheduler to enable allocation of work to processors”, “An illustrative core parking mask (“bit mask” or simply “mask”) 204 … the bit mask 204 may be inverted at 206 to create the inverted bit mask 208”, “If cores have been parked at 524, the kernel power manager 114 may notify the kernel scheduler 116 at 526 to terminate scheduling of threads to the newly parked cores”).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20220066788 A1, hereafter Gupta) in view of Schiocchet et al. (US 20240064106 A1, hereafter Schiocchet).
Regarding to Claim 8, the rejection of Claim 1 is incorporated and further Gupta does not disclose: wherein the control circuit is to receive the predicted workload type from a machine learning engine.
However, Schiocchet discloses: wherein the method further comprises receiving the workload type from a machine learning engine (see [0087]; “The one or more ML models 524(1)-(n) may include at least one inference ML model 524(1) configured to categorize the application data traffic based on the observation features 534(1)-(n) determined for the different plurality of observation window size and burst threshold pairs during an inference phase”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the processes of categorizing a workload based on threshold from Gupta by including categorizing a workload based on threshold via machine learning model from Schiocchet, and thus the combination of Gupta and Schiocchet would disclose the missing limitations from Gupta, since it is well-known and understood to utilize machine learning technology to make certain automatic determinations on data or information nowadays.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20220066788 A1, hereafter Gupta) in view of Abrishami et al. (US 8869152 B1, hereafter Abrishami).
Regarding to Claim 9, the rejection of Claim 1 is incorporated and further Gupta discloses: cause a first number of cores to be parked when the workload type is greater than a threshold workload type; and cause a second number of cores to be parked when the workload type is less than the threshold workload type (see [0020]-[0024]; “the runtime performance of each performance class may be determined based on system-level thread characteristics (e.g., … thresholds” and “unparking a first subset of processing units in the first performance class based on one or more parking hints. As will be discussed in greater detail, the parking hints are not limited to performance and energy efficiency capabilities … maintains a second subset of processing units in the first performance class in the parked state based on the parking hint(s)”. Also see [0035]; “Utilization<Threshold … Utilization>Threshold”).
Gupta does not disclose: the second number of cores less than the first number of cores.
However, Abrishami discloses: cause a first number of processor resources to be parked when the workload type is greater than a threshold workload type; and cause a second number of processor resources to be parked when the workload type is less than the threshold workload type, the second number of cores less than the first number of cores (see lines 1-17 of col. 6 and claim 10, “The lower operating frequency can reduce power consumption in the system … The threshold for raising or lowering the operating frequency may be the same” and “increasing the desired frequency in response to the amount of idle time of the processor being less than a first threshold value, decreasing the desired frequency in response to the amount of idle time of the processor being greater than a second threshold value”. Decreasing processor’s operating frequency would cause more processor resources/partitions are placed in low-power mode).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the processes of parking different number of CPU cores in lower-power mode or parked state based on threshold value from Gupta by including modifying processor operating frequence based on idle time threshold value from Abrishami, and thus the combination of Gupta and Abrishami would disclose the missing limitations from Gupta, since it is understood to dynamic allocating processor resources based on idleness type of threshold in addition to usage type of threshold (see lines 44-17 of cols. 5-6 from Abrishami).
Claims 10-12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20220066788 A1, hereafter Gupta) in view of Torr et al. (US 20120210326 A1, hereafter Torr).
Regarding to Claim 10, the rejection of Claim 1 is incorporated and further Gupta discloses: wherein after the at least one of the at least one first core or the at least one second core is parked, the processor is to perform execution of a plurality of threads on an unparked one of the at least one first core or the at least one second core ([0024]; “selectively unparking a first subset of processing units in the first performance class based on one or more parking hints … maintains a second subset of processing units in the first performance class in the parked state based on the parking hint(s)”. Also see Fig. 1A, [0015], [0033]; “processor utilization is relatively high (e.g., 100% over an extended period of time)” and “if the workload is moved to other available processing units, assuming lesser performant or lesser efficient processing units are parked by the core parking logic 54”. Based on Fig. 1A, [0015], [0033], it is understood there is at least one reasonable embodiment that, the system would utilize the unparked first subset of processing units from [0024] to execute certain threads).
Gupta does not disclose: to serialize execution of a plurality of background threads on an unparked one.
However, Torr discloses: to serialize execution of a plurality of background workloads on an unparked one of the at least one first core or the at least one second core (see [0027], [0030] and [0046]; “Types of processes include system processes, foreground processes and background agent processes”, “If multiple background processing workloads are scheduled to execute at the same time, it is acceptable to serialize their execution”. Also see [0104]; “Aspects of the subject matter described herein are operational … multiprocessor systems”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the workloads or processes from Gupta by including at least foreground type of workloads/processes and background type of workloads/processes from Torr, and thus the combination of Gupta and Torr would disclose the missing limitations from Gupta, since it would provide an execution environment that “that protects foreground experiences from background application execution, while still enabling background applications to make execution progress” (see [0022] from Torr).
Regarding to claim 11, Gupta discloses: At least one computer readable medium comprising instructions that, when executed by a processor, cause the processor to perform a method (see [0018]-[0019] and [0057]-[0058]; “The system memory 84 and/or mass storage 92 include a set of executable program instructions 94, which when executed by at least one processing unit such as, for example, one of the plurality of heterogeneous processing units 82”) comprising:
determining that a workload type for a workload to be executed on the processor exceeds a threshold level (see [0020], [0034]-[0042]; “determining a runtime performance of a plurality of heterogeneous processing units based on system-level thread characteristics … the runtime performance of each performance class may be determined based on system-level thread characteristics (e.g., power constraints, thermal constraints, quality of service/QoS, utilization, concurrency, thresholds, shared queue state, die location, etc.)”, “Utilization<Threshold … Use case #1—low utilization running higher scaling threads … Utilization>Threshold … Use case #3—sustained workload”);
receiving concurrency information regarding a number of cores of the processor in concurrent execution (see [0020]; “determining a runtime performance of a plurality of heterogeneous processing units based on system-level thread characteristics … the runtime performance of each performance class may be determined based on system-level thread characteristics (e.g., power constraints, thermal constraints, quality of service/QoS, utilization, concurrency, thresholds, shared queue state, die location, etc.)”. Also see [0015]; “The thread concurrency (e.g., parallel processing demand)”);
increasing a number of parked cores of the processor based at least in part on the concurrency information (see [0002], [0015], [0017], [0024]; “decide the core count and which cores to park/unpark based on utilization or concurrency”, “Type B processing unit is placed and/or maintained in the parked state during the high utilization and concurrency condition”, “the parking hints are not limited to performance and energy efficiency capabilities … maintains a second subset of processing units in the first performance class in the parked state based on the parking hint(s)”. Also see [0021]; “selectively unpark one or more of the plurality of heterogeneous processing units based on the runtime performance and the runtime energy efficiency”).
Gupta does not disclose:
causing a plurality of background tasks to be executed serially on at least one core of the processor.
However, Torr discloses: causing a plurality of background tasks to be executed serially on at least one core of the processor (see [0027], [0030] and [0046]; “Types of processes include system processes, foreground processes and background agent processes”, “If multiple background processing workloads are scheduled to execute at the same time, it is acceptable to serialize their execution”. Also see [0104]; “Aspects of the subject matter described herein are operational … multiprocessor systems”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the workloads or processes from Gupta by including at least foreground type of workloads/processes and background type of workloads/processes from Torr, and thus the combination of Gupta and Torr would disclose the missing limitations from Gupta, since it would provide an execution environment that “that protects foreground experiences from background application execution, while still enabling background applications to make execution progress” (see [0022] from Torr).
Regarding to Claim 12, the rejection of Claim 11 is incorporated and further the combination of Gupta and Torr discloses: wherein the method further comprises determining that the workload type exceeds the threshold level when the workload type comprises a bursty workload or a sustained workload (see [0034]-[0042] from Gupta; “Utilization<Threshold … Use case #1—low utilization running higher scaling threads … Utilization>Threshold … Use case #3—sustained workload”).
Regarding to Claim 15, the rejection of Claim 14 is incorporated and further the combination of Gupta and Torr discloses: wherein the method further comprises communicating updated energy performance preference information with a hardware feedback interface based at least in part on the increased number of parked cores, the hardware feedback interface accessible to the operating system (see [0031]-[0033] and [0036] from Marshall; “at 214 the program module affinity masks 212 are combined, one at a time, with the inverted bit mask 208 using an “AND” operator 216 to determine the set of eligible processors on for an available processor set 218”, “the available processor set 218 for scheduling threads”, “The kernel scheduler 116 may choose to override the inverted bit mask to accommodate the second affinity mask 212(2), which is represented in the second available processor set 218(2) where core 3 includes a core value of “1,”” and “The core 4 in the core usage 222 may or may not indicated as used depending on whether work is scheduled to core 4 in the available processor set 218(P)”. Note: current claim 15 does not specify or limit objects “energy performance information” and “hardware feedback interface”, and thus information on the core usage 222 is reasonable to be considered as claimed updated energy performance information and the core usage 222 is reasonable to be considered as claimed hardware feedback interface since it indicates the hardware core parking status/feedback).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20220066788 A1, hereafter Gupta) in view of Torr et al. (US 20120210326 A1, hereafter Torr) and further in view of Schiocchet et al. (US 20240064106 A1, hereafter Schiocchet).
Regarding to Claim 13, the rejection of Claim 11 is incorporated, the combination of Gupta and Torr does not disclose: wherein the method further comprises receiving the workload type from a machine learning engine.
However, Schiocchet discloses: wherein the method further comprises receiving the workload type from a machine learning engine (see [0087]; “The one or more ML models 524(1)-(n) may include at least one inference ML model 524(1) configured to categorize the application data traffic based on the observation features 534(1)-(n) determined for the different plurality of observation window size and burst threshold pairs during an inference phase”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the processes of categorizing a workload based on threshold from the combination of Gupta and Torr by including categorizing a workload based on threshold via machine learning model from Schiocchet, and thus the combination of Gupta, Torr and Schiocchet would disclose the missing limitations from the combination of Gupta and Torr, since it is well-known and understood to utilize machine learning technology to make certain automatic determinations on data or information nowadays.
Claims 14 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20220066788 A1, hereafter Gupta) in view of Torr et al. (US 20120210326 A1, hereafter Torr) and further in view of Marshall et al. (US 20090249094 A1, hereafter Marshall).
Regarding to Claim 14, the rejection of Claim 11 is incorporated, the combination of Gupta and Torr does not disclose: wherein the method further comprises communicating an indication of the increased number of parked cores to be accessible by an operating system.
However, Marshall discloses: wherein the method further comprises communicating an indication of the increased number of parked cores to be accessible by an operating system (see Figs. 1-2, [0020], [0026]-[0028], [0033]; “The operating system 108 may provide modules for … which may be represented as a collection of modules collectively referred to as a kernel thread scheduler 116”, “ creating a core parking mask and implementing the mask with the thread scheduler to enable allocation of work to processors”, “An illustrative core parking mask (“bit mask” or simply “mask”) 204 … the bit mask 204 may be inverted at 206 to create the inverted bit mask 208”, “while the inverted bit mask 208 indicates core 3 is parked. The kernel scheduler 116 may choose to override the inverted bit mask”. The kernel or thread scheduler is located at operating system and such scheduler is able to override information of the bit mask indicating increased number of parked cores, and thus the operating system is able to access the bit mask that communicated).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify parking management on processor cores from the combination of Gupta and Torr by including core parking mask managed by a scheduler from Marshall, and thus the combination of Gupta, Torr and Marshall would disclose the missing limitations from the combination of Gupta and Torr, since it provides a binary value that is the most basic value at computing field to indicate parking status of cores (see Fig. 2, [0026]-[0027] from Marshall).
Regarding to Claim 17, the rejection of Claim 11 is incorporated, the combination of Gupta and Torr does not disclose: wherein the method further comprises updating a core parking mask to increase the number of parked cores of the processor.
However, Marshall discloses: wherein the method further comprises updating a core parking mask to increase the number of parked cores of the processor (see Figs. 1-2, [0020], [0026]-[0028], [0033]; “creating a core parking mask and implementing the mask with the thread scheduler to enable allocation of work to processors”, “An illustrative core parking mask (“bit mask” or simply “mask”) 204 may provide a cell representing a corresponding core. As shown in FIG. 2, the illustrative system includes eight cores, however more or fewer cores may be used. The bit mask 204 includes a bit value in each cell, where “1” represents a parked core and “0” represents an unparked core … the bit mask 204 may be inverted at 206 to create the inverted bit mask 208”, “while the inverted bit mask 208 indicates core 3 is parked. The kernel scheduler 116 may choose to override the inverted bit mask”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify parking management on processor cores from the combination of Gupta and Torr by including core parking mask managed by a scheduler from Marshall, and thus the combination of Gupta, Torr and Marshall would disclose the missing limitations from the combination of Gupta and Torr, since it provides a binary value that is the most basic value at computing field to indicate parking status of cores (see Fig. 2, [0026]-[0027] from Marshall).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20220066788 A1, hereafter Gupta) in view of Torr et al. (US 20120210326 A1, hereafter Torr) and further in view of Yuan et al. (US 20240256022 A1, hereafter Yuan) and Tuck et al. (US 20140281392 A1, hereafter Tuck).
Regarding to Claim 16, the rejection of Claim 11 is incorporated, the combination of Gupta and Torr does not disclose: wherein the method further comprises causing one or more foreground tasks to be executed at a turbo mode frequency on at least one other core of the processor.
However, Yuan discloses: causing one or more foreground tasks to be executed at a turbo mode frequency on at least one [other] core of the processor (see Table 2, [0003], [0082]-[0085], [0089]-[0091]; “The Turbo Mode shown in Table 2 will be triggered when the adjustment information determined based on the CPU occupancy rate and the response information of the foreground application requires increasing the power control parameter of the CPU” and “adjust the power control parameter of the CPU to the power control parameter corresponding to Turbo Mode shown in Table 2”. Based on the description on “the response information of the foreground application requires increasing the power control parameter of the CPU” from [0084], it is understood that the foreground application/task would be operated at turbo mode/frequence of the core/processor after the adjusting to turbo mode).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify execution of foreground processes from the combination of Gupta and Torr by including executing foreground processes at a turbo mode from Yuan, since it provides a mechanism “to improve the control intelligence of the electronic device” (see [0003]-[0004] and [0082]-[0085] from Yuan).
In addition, Tuck discloses: causing one or more foreground tasks to be executed on at least one [other] core of the processor (see [0028] and claim 4; “implement summarization activity into separate foreground and background processing threads. As used herein, foreground processing refers to operations responsible for making architectural forward progress on the non-native ISA instructions being emulated. Background threads, in contrast, may perform operations that are not directly relating to moving forward architecturally, and those threads may run on other cores” and “to run the background summarizer thread on a different processor core than the foreground summarizer thread”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify executions of foreground and background processes from the combination of Gupta, Torr and Yuan by including executing foreground and background processes on different processor cores from Tuck, and thus the combination of Gupta, Torr, Yuan and Tuck would disclose the missing limitations from the combination of Gupta and Torr, since it provides a mechanism executing different type of processes on different cores based on the requirements of the different processes (see [0028] from Tuck; “foreground processing refers to operations responsible for making architectural forward progress on the non-native ISA instructions …. Background threads, in contrast, may perform operations that are not directly relating to moving forward architecturally, and those threads may run on other cores”).
Claims 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20220066788 A1, hereafter Gupta) in view of Marshall et al. (US 20090249094 A1, hereafter Marshall) and Tong et al. (WO 2020244300 A1, hereafter Tong, publication date: 12/10/2020, English translation provided by Google Patents).
Regarding to claim 18, Gupta discloses: A system (see Fig. 8, [0056]) comprising:
a processor comprising: a plurality of cores to execute instructions (see Fig. 8, [0057]-[0058]; “determine a runtime performance of the heterogeneous processing units 82 based on system-level thread characteristics”. It is understood that the heterogeneous processing units are required to execute certain instructions to produce or result in runtime performance);
storage coupled to the plurality of cores (see Fig. 8, [0057]-[0058]; “The system memory 84 and/or mass storage 92 include a set of executable program instructions 94, which when executed by at least one processing unit”), the storage to store a core parking prefer state to identify one or more of the plurality of cores to be in a parked state (see [0024]; “maintains a second subset of processing units in the first performance class in the parked state based on the parking hint(s)”); and
a control circuit coupled to the plurality of cores (see Fig. 8, [0057]-[0058]; “at least one processing unit such as, for example … a power and/or performance controller (not shown, e.g., on the SoC 83 or on a separate chip), etc., cause the computing system 80 and/or the at least one processing unit to perform one or more aspects of the method 20 … cause the computing system 80 and/or the at least one processing unit to determine a runtime performance of the heterogeneous processing units 82”. To allow the power and/or performance controller to determine runtime performance of heterogenous processing units, it is required that such controller circuit coupled to the heterogenous processing units), wherein the control circuit is to:
receive energy performance preference (EPP) information for the plurality of cores (see [0020]-[0021]; “determines a runtime energy efficiency of the plurality of heterogeneous processing units based on the system-level thread characteristics … system-level thread characteristics (e.g., power constraints, thermal constraints, QoS, utilization, concurrency, thresholds, shared queue state, etc.), which may be obtained from hardware (e.g., hardware counters via pcode) and/or software”);
determine a quality of service (QOS) distribution based at least in part on the EPP information, the QoS distribution comprising a plurality of core groups, each of the plurality of core groups associated with an EPP level (see [0021]; “determines a runtime energy efficiency of the plurality of heterogeneous processing units based on the system-level thread characteristics, wherein the runtime energy efficiency is determined on a per efficiency class basis. For example, the heterogeneous processing units may also be grouped in real-time into efficiency classes (e.g., Efficiency Class 0, Efficiency Class 1, etc.)”); and
when a workload type is one of a predetermined set of workload types and core group [having a highest number of cores is] associated with an EPP level that indicates a performance preference, identify at least one core to park and update the core parking prefer state based on the identification of the at least one core to park (see [0002], [0015], [0017], [0020]-[0021], [0024] and [0034]-[0055]; “decide the core count and which cores to park/unpark based on utilization or concurrency”, “the runtime performance of each performance class may be determined based on system-level thread characteristics (e.g … thresholds, shared queue state, die location, etc.)”, “the parking hints are not limited to performance and energy efficiency capabilities … maintains a second subset of processing units in the first performance class in the parked state based on the parking hint(s)”, “Utilization<Threshold … Utilization>Threshold” and “LP0—Unparked LP1—Parked LP2—Parked LP3—Parked”); and
a memory coupled to the processor (see Fig. 8, [0056]-[0057]; “The system memory 84 and/or mass storage 92 include a set of executable program instructions 94, which when executed by at least one processing unit such as”), the memory to store a hardware feedback interface (see Fig. 6, [0025]-[0026]; “maintaining an HGS data structure 52”, “ following setting MSR bit 0, a legacy HGS table is built”. Note: it is understood that the HGS data structure as shown on Fig. 6 should be stored at certain memory component).
Gupta does not disclose: the core parking prefer state is a core parking mask;
the core group to identify the at least one core to part is a core group having a highest number of core.
However, Marshall discloses: the storage to store a core parking mask to identify one or more of the plurality of cores to be in a parked state; update the core parking mask based on the identification of the at least one core to park (see Figs 1-2, [0027]; “For example, the kernel power manager 114 may create the core parking mask at 202 … As shown in FIG. 2 … The bit mask 204 includes a bit value in each cell, where “1” represents a parked core and “0” represents an unparked core … The bit mask 204 includes four parked cores, numbered (right to left, zero to seven): 3, 5, 6, and 7. It follows that cores 0, 1, 2, and 4 are unparked cores”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify parking management on processor cores from Gupta by including core parking mask managed by a scheduler from Marshall, since it provides a binary value that is the most basic value at computing field to indicate parking status of cores (see Fig. 2, [0026]-[0027] from Marshall).
In addition, Tong disclose: identify a group of plurality of resource groups having a largest number of resource (see lines 21-24 of page 3 and lines 3-4 of page 5; “Determine the number of remaining resources and the resource pool to which each host … Migrate all virtual machines on the host with the largest number of remaining resources … Hibernate or power off the host that does not host the virtual machine” and “the computing resources include the number of CPU cores, memory capacity”. Note: it is reasonable to consider a host as a resource group; in addition, the hosts, i.e., resource groups, at Tong include CPU cores resource, and thus hibernating or power off the identified host is reasonable to be considered as hibernating or parking at least one CPU core of the host, i.e., resource/core group).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify parking cores of one identified core group from plurality of core groups from the combination of Gupta and Marshall by hibernating a given host or given resource/core group via migrating the workloads of the given resource group to other resource groups from Tong, and thus the combination of Gupta, Marshall and Tong would disclose the missing limitations from the combination of Gupta and Marshall, since it would provide a mechanism of “reducing the power consumption” of computing environment “that effectively manages and balances user needs and performance” (see lines 3-9 of page 2 and 8th paragraph of page 3, “the embodiment of the present application provides a method for reducing the power consumption of a virtual machine cluster” and “The technical solutions provided by the embodiments of the present application can effectively manage and balance user needs and performance”).
Regarding to Claim 19, the rejection of Claim 18 is incorporated and further the combination of Gupta, Marshall and Tong discloses: wherein the control circuit is to obtain the EPP information from the hardware feedback interface, and update at least some of the EPP information in the hardware feedback interface based on the identification of the at least one core to park (see Fig. 6, [0028] from Gupta; “tracks the system-level thread characteristics in the HGS data structure 52. In one example, block 64 provides for updating the HGS data structure 52 in response to one or more changes in the system-level characteristics. Once notified, block 64 may update the performance and energy efficiency classes to use when automatically deciding which cores to unpark”).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20220066788 A1, hereafter Gupta) in view of Marshall et al. (US 20090249094 A1, hereafter Marshall) and Tong et al. (WO 2020244300 A1, hereafter Tong, publication date: 12/10/2020, English translation provided by Google Patents) and further in view of Yuan et al. (US 20240256022 A1, hereafter Yuan), Torr et al. (US 20120210326 A1, hereafter Torr) and Tuck et al. (US 20140281392 A1, hereafter Tuck).
Regarding to Claim 20, the rejection of Claim 18 is incorporated and further the combination of Gupta, Marshall and Tong discloses: wherein when the workload type is a bursty workload or a sustained workload (see [0035]-[0042] from Gputa; “Use case #3—sustained workload”), the control circuit is to: identify a plurality of cores to park (see [0002], [0015], [0017], [0020]-[0021], [0024] and [0034]-[0055]; “decide the core count and which cores to park/unpark based on utilization or concurrency”, “the parking hints are not limited to performance and energy efficiency capabilities … maintains a second subset of processing units in the first performance class in the parked state based on the parking hint(s)”).
The combination of Gupta, Marshall and Tong does not disclsoe:
cause one or more foreground tasks to execute at a turbo mode frequency on one or more cores of the processor; and
cause a plurality of background tasks to execute serially on another core of the processor.
However, Yuan discloses: cause one or more foreground tasks to execute at a turbo mode frequency on one or more cores of the processor (see Table 2, [0003], [0082]-[0085], [0089]-[0091]; “The Turbo Mode shown in Table 2 will be triggered when the adjustment information determined based on the CPU occupancy rate and the response information of the foreground application requires increasing the power control parameter of the CPU” and “adjust the power control parameter of the CPU to the power control parameter corresponding to Turbo Mode shown in Table 2”. Based on the description on “the response information of the foreground application requires increasing the power control parameter of the CPU” from [0084], it is understood that the foreground application/task would be operated at turbo mode/frequence of the core/processor after the adjusting to turbo mode).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify execution of foreground processes from the combination of Gupta, Marshall and Tong by including executing foreground processes at a turbo mode from Yuan, since it provide a mechanism “to improve the control intelligence of the electronic device” (see [0003]-[0004] and [0082]-[0085] from Yuan).
In addition, Torr discloses: cause a plurality of background tasks to execute serially on [another] core of the processor (see [0027], [0030] and [0046]; “Types of processes include system processes, foreground processes and background agent processes”, “If multiple background processing workloads are scheduled to execute at the same time, it is acceptable to serialize their execution, or if resources allow it, to execute them in parallel (e.g., which consumes less battery)”. Also see [0104]; “Aspects of the subject matter described herein are operational … multiprocessor systems”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the execution of background threads/workloads from the combination of Gupta, Marshall, Tong and Yuan by including executing background threads/workloads in serially or in parallel based on the resource amount from Torr, since it would provide a mechanism to provide flexible execution on background workloads via either one of serial or parallel execution (see [0046] from Torr).
In addition, Tuck discloses: causing one or more foreground tasks to be executed on at least one [other] core of the processor (see [0028] and claim 4; “implement summarization activity into separate foreground and background processing threads. As used herein, foreground processing refers to operations responsible for making architectural forward progress on the non-native ISA instructions being emulated. Background threads, in contrast, may perform operations that are not directly relating to moving forward architecturally, and those threads may run on other cores” and “to run the background summarizer thread on a different processor core than the foreground summarizer thread”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify executions of foreground and background processes from the combination of Gupta, Marshall, Tong, Yuan and Torr by including executing foreground and background processes on different processor cores from Tuck, and thus the combination of Gupta, Marshall, Tong, Yuan, Torr and Tuck would disclose the missing limitations from the combination of Gupta, Marshall and Tong, since it provide a mechanism executing different type of processes on different cores based on the requirements of the different processes (see [0028] from Tuck; “foreground processing refers to operations responsible for making architectural forward progress on the non-native ISA instructions …. Background threads, in contrast, may perform operations that are not directly relating to moving forward architecturally, and those threads may run on other cores”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ge et al. (US 20110093429 A1) discloses: the search core reports the idle state to the scheduler (the idle state is written to the idle flag in the scheduler) (see [0138], [0195], [0200]).
Garg et al. (US 20180063670 A1) discloses: causing a plurality of background tasks to be executed serially (see [0048]).
Kaikumaa et al. (US 20090273686 A1) discloses: foreground and background processes can be executed at either different processors or within same processor (see [0060]).
Carmean et al. (US 6370625 B1) discloses: foreground and background processes can be executed at either different processors (see lines 20-31 of col. 1).
Murakami (US 20150033240 A1) discloses: increasing number of CPU cores to be parked when detecting a workload level is greater than corresponding threshold (see [0069]-[0070]; “in the case where it has been determined that the condition continuation time is greater than the continuation time threshold (Yes in step S023), that is, in the case where it has been determined that the condition continuation time is longer than 300 milliseconds, the CPU core control determination unit 202 suspends operation of the “core 1” 1012 of the CPU 101, that is, decreases the number of operating cores of the CPU 101”).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 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 and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights