DETAILED ACTION
This Office Actions is in response to communication (Amendment) filed on 03/05/2026.
Claims 1-20 are pending. Claims 1, 8, and 15 are in independent form. Claims 1-5, 7-13 and 15-20 are amended. This action is Final.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This Office Action is in response to the applicant’s remarks and arguments filed on 03/05/2026.
a. Claims 1-5, 7-13 and 15-20 were amended. Claims 1-20 remain pending in the application, and are being considered on the merits.
b. The amendment filed on 03/05/2026 is objected to under 35 U.S.C. 132(a) because it introduces new matter into the disclosure. 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. The added material which is not supported by the original disclosure is as follows:
The independent claims recite the limitation recite the limitation “obtain data comprising hardware performance metrics generated by hardware performance monitoring circuitry of the first core” and the limitation “responsive to the given thread satisfying a hardware-event- based migration condition”. The examiner cannot find the support for the above underline limitation/term, “hardware performance monitoring circuitry” and “a hardware-event- based migration condition”, from the Specification filed on 06/22/2022, because the above underline limitation/term was not used in any paragraphs of the Specification.
Regarding claims 6, 13, and 20, the claims recite the limitation “the hardware performance metrics comprise one or more of: cache misses; pipeline flushes; input/output (I/O) activity; memory access latency; or vector unit utilization.” The examiner cannot find the support for the above underline limitation, “cache misses; pipeline flushes; input/output (I/O) activity; memory access latency; or vector unit utilization” that relates to the “hardware performance metrics” from the Specification filed on 06/22/2022.
Regarding claim 16, the claims recite the limitation/term “the hardware-event- based migration condition”. The examiner cannot find the support for the above underline limitation from the Specification filed on 06/22/2022.
For further details, please see 35 U.S.C § 112(a) rejections below. If the applicant believes the above limitation is supported by the Specification filed on 06/22/2022, the applicant can clearly point out which paragraphs or Figures contain the above limitation in the reply to this Office Action. The examiner suggests to amend the claims using consistent words with the Specification to overcome the 35 U.S.C § 112 rejections
Applicant is required to cancel the new matter in the reply to this Office Action.
d. The previous rejection of claims 1-20 under 35 U.S.C. §103 has been fully considered but they are not persuasive. For further details, please see Response to Arguments under 35 U.S.C § 103 Rejection Remarks below.
Response to Arguments
The applicant’s remarks and/or arguments, filed on 03/05/2026 have been fully considered with the following result(s).
The examiner is entitled to give claim limitations their broadest reasonable interpretation in light of the specification. See MPEP 2111 [R-1] Interpretation of Claims-Broadest Reasonable Interpretation. The applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Prater, 162 USPQ 541,550-51 (CCPA 1969).
Response to 35 U.S.C § 112(a) Remarks
Applicant’s argument filed on 03/05/2026 regarding the 35 U.S.C § 112(a) rejections of claims 1, 2, 8, 9, 15, and 16 have been fully considered and they are persuasive. The previous rejection under 35 U.S.C. § 112(a) has been withdrawn.
Regarding the 35 U.S.C § 112(a) rejections of claims 6, 13, and 20, the examiner finds these arguments unpersuasive and maintains that the rejection under 35 U.S.C. § 112 is proper.
However, upon further consideration, a new ground(s) 35 U.S.C. § 112(a) of claims 1, 8, and 15, is made due to the amendment filed on 03/05/2026. For further details, please see below claims rejections under 35 U.S.C § 112(a).
Response to 103 Remarks
Applicant’s argument filed on 03/05/2026 regarding the 35 U.S.C § 103 rejections have been fully considered but they are not persuasive.
Regarding the remark that “However, Lee's scheduling and migration decisions are based on context similarity, thread grouping, average load calculation, and cluster management policies. Lee does not disclose hardware performance monitoring circuitry generating hardware execution-event metrics while a thread executes on a given core, nor determining satisfaction of a migration condition based at least in part on such hardware execution-event metrics. Instead, Lee's migration decisions are governed by workload distribution and context-based policies, not by hardware execution-event metrics generated by monitoring circuitry of the executing core.”
The examiner fully considered, and disagreed that Lee does not disclose “hardware performance monitoring circuitry” that perform the functions mentioned in the applicant argument. However, the “hardware performance monitoring circuitry” and all of its functions are taught by Moyes, as explain in the 35 U.S.C § 103 rejections below.
Regarding the remark that “Moyes does not disclose a heterogeneous computing environment comprising core types defined by differing performance capability and power consumption. Nor does Moyes disclose migration between such core types based on a hardware-event-based migration condition tied to performance/power differentiation. Accordingly, while Moyes teaches hardware metric-based reassignment, it does not teach or suggest applying such metric-based criteria to selection between heterogeneous core types having distinct performance and power characteristics.”
The examiner fully considered, and disagreed that Lee does not disclose “disclose a heterogeneous computing environment comprising core types defined by differing performance capability and power consumption”, or the structure that perform the functions disclose in the claim invention. However, the limitation “heterogeneous computing environment comprising core types” is taught by Lee, as explain in the 35 U.S.C § 103 rejections below.
Regarding the remark that “Further, claim 1 is believed patentable over a combination of the cited references. The amended claim requires more than the mere presence of hardware monitoring and heterogeneous cores in isolation. The claim requires that hardware execution-event metrics generated by the first core while executing the thread form at least part of the basis for satisfying a hardware-event-based migration condition governing migration specifically between heterogeneous core types defined by differing performance and power characteristics. Lee does not base heterogeneous core-type selection on hardware execution-event metrics. Moyes does not contemplate heterogeneous core- type selection at all. The cited references therefore do not teach or suggest integrating hardware execution-event metrics into a migration condition that governs selection between performance/power-differentiated core types. Adopting Moyes' monitoring mechanism into Lee's architecture would require redefining the role of hardware execution-event metrics-from managing shared-resource contention to governing heterogeneous core-type selection based on performance and power characteristics. The cited art provides no teaching or suggestion of such an integration.”
The examiner fully considered, and respectfully disagreed, and would like to point out that the current claims languages are still too broad and generic, and does not clearly indicate that all of the features claiming in the claim invention that can exclusively perform by the system comprises heterogeneous cores. The feature “hardware execution-event metrics generated by the first core while executing the thread form at least part of the basis for satisfying a hardware-event-based migration condition governing migration specifically between heterogeneous core types” is taught by Moyes, for example, at FIG. 3, 4, 5, and corresponding paragraphs. The “heterogeneous core” is taught Lee, for example at FIG. 3. However, the underline feature of “heterogeneous core types defined by differing performance and power characteristics” does not clearly reflecting in the current independent claims. Also, it is unclear for the examiner that why “The cited references therefore do not teach or suggest integrating hardware execution-event metrics into a migration condition that governs selection between performance/power-differentiated core types......... The cited art provides no teaching or suggestion of such an integration”
In addition, the examiner would like to point out that, both references Lee and Moyes disclose the concept of migrating/reassigning threads that are executing on one core to the appropriate core, and FIG. 3 from Moyes discloses the structure that is very similar to the FIG. 3 of the application, and the different in the component “Hardware computing system 302” is reasonable taught by Lee at FIG. 3. Therefore, it would be reasonable to combine the two references to come up with the claim’s invention.
Thus, based on all of the above explanation, the examiner finds these arguments
unpersuasive and maintains that the rejection under 35 U.S.C. § 103 is proper.
Claim Objections
Claims 1, 8, and 15 are objected to because of the following informalities: “responsive to the given thread satisfying a hardware-event- based migration condition, wherein satisfaction of the condition is determined based at least in part on the metrics”. It should be “hardware performance metrics”.
Appropriate correction is required
Claim 6 is objected to because of the following informalities: the claims status (Currently Amended) is incorrect, as there is no change made to the claims. The claims status should be (Previously Presented).
Appropriate correction is required.
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.
Claims 1 – 20 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.
Regarding claims 1, 8, and 15, the claims recite the limitation “obtain data comprising hardware performance metrics generated by hardware performance monitoring circuitry of the first core”. The examiner cannot find the support for the above underline limitation/term, “hardware performance monitoring circuitry”, from the Specification filed on 06/22/2022, because the above underline limitation/term was not used in any paragraphs of the Specification. The closest support that the examiner could find is the paragraph [0024]: “As described earlier, hardware, such as circuitry, of a particular core of the multiple cores executes instructions of an operating system scheduler at a current point in time, and this particular scheduling core assigns a thread to the high-performance core 112 .......... In various implementations, the high-performance core 112 includes hardware performance counters that monitor hardware events that occur in the high-performance core 112 while the first core executes the assigned thread.”
In addition, the claims recite the limitation “responsive to the given thread satisfying a hardware-event- based migration condition”. The examiner cannot find the support for the above underline limitation/term, “a hardware-event- based migration condition”, from the Specification filed on 06/22/2022, because the above underline limitation/term was not used in any paragraphs of the Specification. The closest support that the examiner could find is the paragraph [0047]: “Based on this classification indicating the dynamic behavior of the SW Thread 310m as reported by the low-power core 314r, the scheduling core removes SW Thread 310m from low-power core 314r and reassigns SW Thread 310m to high-performance core 314g. To aid thread migration, user data allocated by one thread is used only by that thread and data sharing among threads occurs via read-only global variables and fast local message passing via the scheduling core that executes the thread scheduler 316. The scheduling core also handles any changes to stack pointers, if any.”
If the applicant believes the above limitation is supported by the Specification filed on 06/22/2022, the applicant can clearly point out which paragraphs or Figures contain the above limitation in the reply to this Office Action. The examiner suggests to amend the claims using consistent words with the Specification to overcome the 35 U.S.C § 112 rejections.
Claims 2 – 7, 9 – 14, and 16 – 20 are also rejected due to the rejection of the independent claims 1, 8, and 15.
Regarding claims 6, 13, and 20, the claims recite the limitation “the hardware performance metrics comprise one or more of: cache misses; pipeline flushes; input/output (I/O) activity; memory access latency; or vector unit utilization.” The examiner cannot find the support for the above underline limitation, “cache misses; pipeline flushes; input/output (I/O) activity; memory access latency; or vector unit utilization” that relates to the “hardware performance metrics” from the Specification filed on 06/22/2022. The term “hardware performance metrics” is mentioned at paragraphs [0015], [0024], and [0051], but nowhere in the paragraphs [0015], [0024], and [0051] mention the underline limitation, especially the terms “input/output (I/O) activity; memory access latency; or vector unit utilization”.
The term “cache misses” and “pipeline flushes” mentioned at paragraph [0025]: “Alternatively, the counters count the number of clock cycles that the high-performance core 112 spent performing predetermined events. Examples of events include pipeline flushes, data cache snoops and snoop hits, cache and translation lookaside buffer (TLB) misses, read and write operations, data cache lines written back, branch operations, taken branch operations, the number of instructions in an integer or floating-point pipeline, and bus utilization.”, but there is no indication that the “hardware performance metrics” comprises “cache misses” and “pipeline flushes” in paragraph [0025].
If the applicant believes the above limitation is supported by the Specification filed on 06/22/2022, the applicant can clearly point out which paragraphs or Figures contain the above limitation in the reply to this Office Action. The examiner suggests to amend the claims using consistent words with the Specification to overcome the 35 U.S.C § 112 rejections.
Regarding claim 16, the claims recite the limitation/term “the hardware-event- based migration condition”. The examiner cannot find the support for the above underline limitation/term, “the hardware-event- based migration condition”, from the Specification filed on 06/22/2022, as explained in the rejection of claims 1, 8, and 15 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, 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, 2, 6 – 9, 13 – 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable by LEE et al. Pub. No. US 20160062798 A1 (hereafter LEE), in further view of Moyes et al. Pub. No. US 20110055838 A1 (hereafter Moyes)
Regarding claim 1, LEE teaches the invention substantially as claimed: An apparatus comprising: a scheduler comprising circuitry configured to (e.g. FIG. 3 and [0053]: “The scheduler 135 assigns a thread provided to the application program 132 to each core of the multi-core processor 110.”)
cause execution of a given thread by circuitry of a first core of a plurality of cores (e.g. FIG. 6, [0077]: “At a time point t0, a scheduling even occurs and the third thread TH3 is generated according to a scheduling scheme. The generated third thread TH3 may be assigned to the LITTLE core LCore1 to be executed therein.”) The citation discloses at [0077] thread TH3 is generated and assigned to LCore1
in a heterogeneous computing environment, (e.g. [0027]: “The multi-core processor 110 may be provided as a homogeneous multi-core processor or a heterogeneous multi-core processor.”)
the plurality of cores including at least a first type of core and a second type of core different from the first type of core, the second type of core having higher performance capability and higher power consumption than the first type of core; (e.g. FIG. 2, [0042]: “The second cluster 114 includes LCore_1, LCore_2, LCore_3, and LCore_4 that provide relatively lower processing speed but have high power efficiency”), and [0040]: “The first cluster 112 includes cores BCore_1, BCore_2, BCore_3, and BCore_4 that provide relatively higher processing speed but have great power consumption”) The citation discloses the cluster 114 includes cores have high power efficiency/first type of cores, and cluster 112 includes cores have higher processing speed and greater power consumption/second type of cores.
the first core being of the first type and the second core being of the second type. (e.g. FIG. 2, [0042]: “The second cluster 114 includes LCore_1, LCore_2, LCore_3, and LCore_4 that provide relatively lower processing speed but have high power efficiency”), and [0040]: “The first cluster 112 includes cores BCore_1, BCore_2, BCore_3, and BCore_4 that provide relatively higher processing speed but have great power consumption”) The citation discloses the cluster 114 includes cores have high power efficiency/first type of cores, and cluster 112 includes cores have higher processing speed and greater power consumption/second type of cores.
LEE fails to teach obtain data comprising hardware performance metrics generated by hardware performance monitoring circuitry of the first core, the hardware performance metrics corresponding to one or more hardware execution events occurring during execution of the given thread; and cause execution of the given thread to be changed from the first core to a second core, responsive to the given thread satisfying a hardware-event- based migration condition, wherein satisfaction of the condition is determined based at least in part on the metrics.
However, Moyes teaches obtain data comprising hardware performance metrics; (e.g. FIG. 5 and [0061]: “In block 504, the dynamic behavior of the executing threads may be monitored. The hardware of performance monitor 224 may be utilized for this purpose.” and [0062]: “In block 506, the recorded data in performance monitor 224 may be reported to a scheduler 316 within kernel 312.” and [0064] - [0067]) The citation discloses at FIG. 5, block 504 that a behavior of threads, which is currently executing in a core, is monitored by the hardware performance monitor, and the recorded data is sent to the scheduler for analyzed. At [0064] – [0067] discloses an example when the system assigns threads to a core and the hardware in performance monitor the resource contention while the threads are executing in the core, and the scheduler receives measured data values from the hardware in performance monitor.
generated by hardware performance monitoring circuitry of the first core, the hardware performance metrics corresponding to one or more hardware execution events occurring during execution of the given thread (e.g. [0037]: “Performance monitor 224 may include dedicated measurement hardware for recording and reporting performance metrics corresponding to the design and operation of processor core 200...... Alternatively, portions of the performance monitor 224 may reside both within and without core 200. All such combinations are contemplated.” and [0061]: “In block 504, the dynamic behavior of the executing threads may be monitored. The hardware of performance monitor 224 may be utilized for this purpose.” and [0062]: “In block 506, the recorded data in performance monitor 224 may be reported to a scheduler 316 within kernel 312....... The recorded data values may be compared to predetermined thresholds by the scheduler 316. Some examples of predetermined thresholds may include a number of floating-point operations, a number of graphics processing operations, a number of cache accesses, a number of cache misses, a power consumption estimate, a number of branch operations, a number of pipeline stalls due to write buffer overflow, or other. The recorded data may be derived from hardware performance counters,”) The citation discloses at [0037] the performance monitor/hardware performance monitoring, that measures hardware for recording and reporting for performance metric, and the performance monitor reside within core 200/circuitry. At [0061] discloses the performance monitor is utilized for monitoring the dynamic behavior of the executing threads. At [0062] discloses the recorded data of the hardware performance counters may include cache accesses or cache misses/ hardware execution events.
and cause execution of the given thread to be changed from the first core to a second core of the plurality of core, .........., responsive to the given thread satisfying a hardware-event- based migration condition, wherein satisfaction of the condition is determined based at least in part on the metrics. (e.g. [0047]: “In one embodiment, only one process can execute at any time per processor core, CPU thread, or Hardware Thread. In FIG. 3, Hardware Threads 314a-314g and 314h-314r comprise hardware that can handle the execution of the one or more threads 310 within one of the processes 308. This hardware may be a core, such as core 200, or a subset of circuitry within a core 200 configured to execute multiple threads, and FIG. 5 and [0066]: “The scheduler 316 may receive measured data values from the hardware in performance monitor 224. In one embodiment, such values may be received at a predetermined time--such as at the end of a time slice or an interrupt generated within a core upon reaching a predetermined event measured by performance monitor 224...... The scheduler 316 may analyze the received measured data and determine utilization of the FPU in the first core exceeds a predetermined threshold” and [0067] - [0068].) The citation discloses at [0047] the Hardware Thread of FIG. 3 could be considered as a core. At [0066] discloses the measured data collected by the hardware in performance monitor is analyze by the scheduler and the scheduler determined that the data exceed a predetermined threshold/making the determination satisfaction of the condition is determined based on data/metric. At FIG. 5 and [0067] - [0068] disclose when the scheduler, reassign one thread the different core bases on the utilization of the resource in the first core.
The teaching of Moyes does not clearly indicate that there are two different types of cores in the system. However, LEE teaches the system has two different types of cores (e.g. FIG. 2, [0042] and [0044]), and LEE also teach the assigning/reassigning threads to different cores (e.g. [0077] and [0078]). Therefore, by combining the teaching of LEE about the system has two different types of cores and the system can assign/reassign threads to different cores, with the teaching of Moyes about assign/reassign threads to different core because of the behavior of the threads relates to the resource contention, one with ordinary skill in the art would be able to come up with the claim invention.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add the obtain data comprising hardware performance metrics generated by hardware performance monitoring circuitry of the first core, the hardware performance metrics corresponding to one or more hardware execution events occurring during execution of the given thread; and cause execution of the given thread to be changed from the first core to a second core, responsive to the given thread satisfying a hardware-event- based migration condition, wherein satisfaction of the condition is determined based at least in part on the metrics., as taught in Moyes’s invention into LEE’s invention because the additional features about receiving hardware data related to the behavior of the threads would provide flexible way to balance energy efficiency and computing speed by matching the right type of cores to the needed threads. As a results, the system can save power when execute simple tasks and boosts performance when execute high-performance tasks, ensuring faster and more efficient execution.
Regarding claim 2, LEE, in view of Moyes, discloses the apparatus as recited in claim 1, and LEE further teaches wherein the second core is selected for execution of the given thread, (e.g. FIG. 6, [0077]: “According to a result of the determination, the scheduler 135 may reassign the core to execute the third thread TH3 to the high-speed big core BCore1.” and [0078]: “From a time point t1, the third thread TH3 may be executed in the big core BCore1 together with the first thread TH1. That is, the third thread TH3 up-migrates to the high-speed big core BCore1 from the low-speed LITTLE core LCore1. Since the first thread TH1 and the third thread TH3 having the same context are executed in the same core, a waiting situation of the big core BCore1 resulting from response delay of the third thread TH3 may be prevented.”) The citation discloses the TH3 is executed in the BCore1 at time t1, after being assigned from LCore1.
Moyes further teaches bases at least in part on stored data associating the second type of core with the hardware performance metrics. (e.g. [0055]: “Turning now to FIG. 4, one embodiment of stored hardware measurement data 400 used in an operating system is shown. In one embodiment, operating system 318 may comprise a metrics table 410 for storing data collected from performance monitors 224 in a computing system. This data may be used by the scheduler 316 within the kernel 312 for assigning and reassigning software threads 310 to hardware threads 314” and [0056] and [0057]: “An event index 426 may indicate a type of hardware-related event being measured, such as a number of cache hits/misses, a number of pipeline flushes, or other. These events may be particular to an interior design of a computation unit, such as a processor core.” and [0059]: “Similarly, the arrangement of metrics table 410, a table of programmable thresholds, and decision logic within scheduler 316 for thread assignment/reassignment may use other placements for better design trade-offs.” and FIG. 5 and [0066]: “The scheduler 316 may receive measured data values from the hardware in performance monitor 224. In one embodiment, such values may be received at a predetermined time--such as at the end of a time slice or an interrupt generated within a core upon reaching a predetermined event measured by performance monitor 224...... The scheduler 316 may analyze the received measured data and determine utilization of the FPU in the first core exceeds a predetermined threshold” and [0067] - [0068]) The citation discloses the metrics table/stored data, that storing data collected by performance monitors, and used to assigning/reassigning thread to hardware threads/cores. At FIG. 5 and [0067] - [0068] disclose when the scheduler, reassign one thread the different core bases on the utilization of the resource in the first core.
Regarding claim 6, LEE, in view of Moyes, discloses the apparatus as recited in claim 1, and Moyes further teaches wherein the hardware performance metrics comprise one or more of: cache misses; (e.g. [0066]: “The scheduler 316 may receive measured data values from the hardware in performance monitor 224. In one embodiment, such values may be received at a predetermined time--such as at the end of a time slice or an interrupt generated within a core upon reaching a predetermined event measured by performance monitor 224. Such an event may include the occurrence of a number of cache misses, a number of pipeline stalls, a number of branch operations, or other, exceeding a predetermined threshold.”)
pipeline flushes; input/output (I/O) activity; memory access latency; or vector unit utilization
Regarding claim 7, LEE, in view of Moyes, discloses the apparatus as recited in claim 1, and Moyes further teach wherein the hardware performance monitoring circuitry comprises hardware performance counters configured to increment in response to occurrence of the hardware execution events during execution of the given thread ([0037]: “The hardware of monitor 224 may be integrated throughout the floorplan of core 200 …... The hardware of monitor 224 may collect data as fine-grained as required to assist tuning and understanding the behavior of software applications and hardware resource utilization.” and [0038]: “In one embodiment, monitor 224 may include one or more multi-bit registers which may be used as hardware performance counters capable of counting a plurality of predetermined events, or hardware-related activities.”) The citations disclose the hardware of monitor 224 includes the hardware performance counters. The hardware of monitor 224 responsible for collecting data related to the behavior of software applications and hardware resource utilization. The hardware performance counters capable of counting a plurality of predetermined events/ increment in response to occurrence of the hardware execution events.
Regarding claim 8, the claim is a method claim that having similar limitations cited in claim 1. Thus, claim 8 is also rejected under the same rational as cited in the rejection of rejected claim 1.
Regarding claim 9, the claim is a method claim that having similar limitations cited in claim 2. Thus, claim 9 is also rejected under the same rational as cited in the rejection of rejected claim 2.
Regarding claim 13, claim 13 is a method claim that having similar limitations cited in claim 6. Thus, claim 13 is also rejected under the same rational as cited in the rejection of rejected claim 6.
Regarding claim 14, claim 14 is a method claim that having similar limitations cited in claim 7. Thus, claim 14 is also rejected under the same rational as cited in the rejection of rejected claim 7.
Regarding claim 15, the claim is a computing system claim that having similar limitations cited in claim 8. Thus, claim 15 is also rejected under the same rational as cited in the rejection of rejected claim 8.
Regarding claim 16, LEE, in view of Moyes, discloses the apparatus as recited in claim 1, and LEE further teaches wherein the second core is selected by the given core from among the plurality of cores (e.g. FIG. 6, [0077]: “According to a result of the determination, the scheduler 135 may reassign the core to execute the third thread TH3 to the high-speed big core BCore1.” and [0078]: “From a time point t1, the third thread TH3 may be executed in the big core BCore1 together with the first thread TH1. That is, the third thread TH3 up-migrates to the high-speed big core BCore1 from the low-speed LITTLE core LCore1. Since the first thread TH1 and the third thread TH3 having the same context are executed in the same core, a waiting situation of the big core BCore1 resulting from response delay of the third thread TH3 may be prevented.”) The citation discloses the TH3 is executed in the BCore1 at time t1, after being assigned from LCore1.
Moyes further teaches based on stored data that associates satisfaction of the hardware-event-based migration condition with the second type of core. (e.g. [0055]: “Turning now to FIG. 4, one embodiment of stored hardware measurement data 400 used in an operating system is shown. In one embodiment, operating system 318 may comprise a metrics table 410 for storing data collected from performance monitors 224 in a computing system. This data may be used by the scheduler 316 within the kernel 312 for assigning and reassigning software threads 310 to hardware threads 314” and [0056] and [0057]: “An event index 426 may indicate a type of hardware-related event being measured, such as a number of cache hits/misses, a number of pipeline flushes, or other. These events may be particular to an interior design of a computation unit, such as a processor core.” and [0059]: “Similarly, the arrangement of metrics table 410, a table of programmable thresholds, and decision logic within scheduler 316 for thread assignment/reassignment may use other placements for better design trade-offs.” and FIG. 5 and [0066]: “The scheduler 316 may receive measured data values from the hardware in performance monitor 224. In one embodiment, such values may be received at a predetermined time--such as at the end of a time slice or an interrupt generated within a core upon reaching a predetermined event measured by performance monitor 224...... The scheduler 316 may analyze the received measured data and determine utilization of the FPU in the first core exceeds a predetermined threshold” and [0067] - [0068]) The citation discloses the metrics table/stored data, that storing data collected by performance monitors, and used to assigning/reassigning thread to hardware threads/cores. At FIG. 5 and [0067] - [0068] disclose when the scheduler, reassign one thread the different core bases on the utilization of the resource in the first core.
Regarding claim 20, claim 20 is a computing system claim that having similar limitations cited in claim 6. Thus, claim 20 is also rejected under the same rational as cited in the rejection of rejected claim 6.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over LEE, and Moyes, in further view of Cai et al. Pub. No. US 20190034239 A1 (hereafter Cai)
Regarding claim 3, LEE, in view of Moyes, discloses the apparatus as recited in claim 2, but fails to teach wherein the stored data associates each core type with a respective thread behavior category defined by one or more threshold comparisons of hardware performance metrics.
However, Cai teaches: wherein the stored data associates each core type with a respective thread behavior category. (e.g. FIG. 5A, 5B and [0035]: “FIGS. 5A and 5B are example tables 500 (after tracking before mapping and migration) and 550 (after mapping and migration) of hardware threads T1 216 and T2 218 for each core C1 202, C2 204, C3 206, and C4 208 (for an example 4 core/8 thread SMT CPU with DRAM for first memory and FAM for second memory) mapped to the cores by classification” and [0043]: “Referring back to FIGS. 5A and 5B, assuming that FIG. 5A represents the thread classification after the operation of FIG. 7, then the ordering created in block 802 is represented by the threads represented in FIG. 5B. where the DRAM_ONLY classified threads D1 and D2 are assigned to core C1 and hardware threads T1 and T2 respectively, and DRAM_ONLY classified threads D3 and D4 are assigned to core C2 hardware threads T1 and T2, respectively. The MIXED classified threads M1 and M2 are assigned to core C3 and hardware threads T1 and T2, respectively. The FAM_ONLY classified threads F1 and F2 are assigned to core C4 hardware threads T1 and T2, respectively.”). The citation discloses the table/stored data that indicate the classified threads are assigned to the corresponding cores.
defined by one or more threshold comparisons of hardware performance metrics. (e.g. [0032]: “When using software pinning by an OS, it is very difficult to pin a thread having such dynamic memory behaviors but it can be readily achieved by the technique disclosed herein due to the hardware monitoring and tracking. Accordingly, the flow in flowchart 300 allows for continually tracking the various threads for different types of memory accesses and dynamically classifying, reassigning (or mapping) and migrating the assigned threads to appropriate cores with like type threads. In addition, enabling DVFS allows for increasing program performance and reduced power consumption of CPU 200.” and [0046]: “the use of hardware counters/registers at run-time allows for software threads to be classified based on their memory accesses to different types of memory without software involvement.”) The citation discloses the use of hardware monitoring/observing, to classify the thread and assigning or reassigning the thread to the appropriate core
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add the wherein the wherein the stored data associates each core type with a respective thread behavior category defined by one or more threshold comparisons of hardware performance metrics, as taught in Cai’s invention into LEE, Moyes, and Alameldeen’s invention because by storing data that links each core to a specific thread class, the scheduler can quickly match threads to the best suitable cores, and avoid unnecessary analysis, which leads to faster and more efficient scheduling decisions, and would help to improve the overall system performance.
Regarding claim 10, claim 10 is a method claim that having similar limitations cited in claim 3. Thus, claim 10 is also rejected under the same rational as cited in the rejection of rejected claim 3.
Regarding claim 17, claim 17 is a computing system claim that having similar limitations cited in claim 3. Thus, claim 17 is also rejected under the same rational as cited in the rejection of rejected claim 3.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over LEE, and Moyes, in further view of Shanbhogue et al. Pub. No. US 20190042280 A1 (hereafter Shanbhogue)
Regarding claim 4, LEE, in view of Moyes, discloses the apparatus as recited in claim 2, but fails to teach wherein the scheduler is further configured to update the stored data based on hardware performance metrics collected during execution of threads on the second core and to apply the updated data to subsequent migration decisions.
However, Shanbhogue teaches wherein the scheduler is further configured to update the stored data based on hardware performance metrics collected during execution of threads on the second core and to apply the updated data to subsequent migration decisions (e.g. [0028]: “an operating system (OS) or other system software may provide hardware with a pointer to a table in memory where the processor hardware can produce feedback to be provided to the OS scheduler about the performance and energy efficiency capabilities of each core of the processor. In another embodiment, this table may be located in a bank of registers that is mapped into the OS address space. The OS scheduler can be notified when this information changes.”) and [0127]: “In embodiments herein, better scheduling decisions may occur to appropriately schedule threads to achieve higher performance and/or improved power consumption, based on the hardware feedback information. As such, it is possible based upon this hardware feedback information to schedule a thread to a smaller core, where it may achieve greater performance than if it were to be scheduled on a larger core, in some situations. And similarly, it is possible to schedule a thread to a large core and increase energy efficiency, instead of scheduling the thread on a smaller core, in some situations.” and [0134]: “Once hardware feedback is enabled, a power controller generates hardware feedback information updates based on system workload and power and thermal constraints. In one embodiment, a microcode technique may be used to write the updates to memory, which may be in a compressed form as described herein. When new hardware feedback information is available, the power controller may use a mailbox interface to request microcode to update the HFI memory region with the latest hardware scheduling information.” and [0149]: “In any event, the OS that reads this updated hardware feedback information may update one or more OS internal data structures. More specifically, such data structures may be used by the OS scheduler to schedule threads for execution within the processor.”) The citations disclose at [0028] the OS scheduler is notified/receive a notification about a change in the table/data about the performance and energy efficiency of each core, at [0127] discloses the hardware feedback information/data, is used for better scheduling threads to cores. At [0134] discloses hardware feedback information is updated based on system workload and power and thermal constraints/updated data, and at [0149] discloses the updated hardware feedback information is used by the OS scheduler for better scheduling threads for execution within the processor.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add the wherein the scheduler is further configured to update the stored data based on hardware performance metrics collected during execution of threads on the second core and to apply the updated data to subsequent migration decisions, as taught in Shanbhogue’s invention into LEE and Moyes’s invention because the stored updated data that indicate a match between a thread and cores would help to provide the most efficient way to assign a specific thread to the most suitable cores, which lead to improve the overall performance of the computing system, and balance workloads across the available cores.
Regarding claim 11, claim 11 is a method claim that having similar limitations cited in claim 4. Thus, claim 11 is also rejected under the same rational as cited in the rejection of rejected claim 4.
Regarding claim 18, claim 18 is a method claim that having similar limitations cited in claim 4. Thus, claim 18 is also rejected under the same rational as cited in the rejection of rejected claim 4.
Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over LEE and Moyes, in further view of Craik et al. Pub. No. US 20120227051 A1 (hereafter Craik)
Regarding claim 5, LEE, in view of Moyes, discloses the apparatus as recited in claim 1, but fails to teach wherein satisfaction of the migration condition corresponds to the given thread exceeding a threshold for at least one of a non-scalable thread, an input/output (I/O) or memory bound thread, and a vector thread
However, Craik teaches: wherein satisfaction of the migration condition corresponds to the given thread exceeding a threshold for at least one of a non-scalable thread,
an input/output (I/O) or memory bound thread, ([0026]: “In one aspect of the illustrative embodiments, the task scheduler divides threads into groups of compute tasks and memory tasks. Compute tasks are groups of instructions that perform computational functions, such as arithmetic functions. Memory tasks generally are groups of instructions that perform input/output functions or, more particularly, load/store operations.”) The citation discloses threads are divided into compute tasks and memory tasks, where memory task includes I/O functions.
and a vector thread.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add the wherein satisfaction of the migration condition corresponds to the given thread exceeding a threshold for at least one of ...... an input/output (I/O) or memory bound thread, as taught in Craik’s invention into LEE and Moyes’s invention because it would help to improve the task scheduling algorithms and task completion time, and improving the overall system performance and efficiency, since the scheduler can logically assign the specific threads to cores that can handle specific tasks more effectively, based on the classification information of the threads, such as thread that only handle I/O tasks.
Regarding claim 12, claim 12 is a method claim that having similar limitations cited in claim 5. Thus, claim 12 is also rejected under the same rational as cited in the rejection of rejected claim 5.
Regarding claim 19, claim 19 is a computing system claim that having similar limitations cited in claim 5. Thus, claim 19 is also rejected under the same rational as cited in the rejection of rejected claim 5.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure
US 20160092274 A1 teaches the Heterogeneous thread scheduling techniques in which a processing workload is distributed to heterogeneous processing cores of a processing system
US 20140359633 A1 teaches a system that dynamically assigns computing threads to different processing nodes based on real-time and performance estimates, optimizing resource allocation in multicore processors to enhance efficiency.
US 20180246767 A1: A system for scheduling a software thread for execution on a CPU in a multiprocessor system, a scheduler uses both software and hardware utilization information. For a thread, resource demands (including software and hardware resource demands) are determined based on measuring resource usage while the thread executes on the multiprocessor system without being isolated from any other threads that may run concurrently. The software thread is assigned to a strand in the processor core with optimum available resources given the thread's resource demands.
US 20150234687 A1: Methods related to migrating a thread across cores in a multi-core processor are described. Some example methods may include executing a thread on a first processing core of the multi-core processor and migrating execution of the thread from the first processing core to a second processing core of the multi-core processor. Selective state data required for execution of the thread on the second processing core may be identified and the identified state data may be dynamically acquired from the first processing core.
US 20210182180 A1: A method includes receiving one or more parameters associated with assignment of threads of a first program to one or more of a plurality of processor cores having a first hardware configuration; during execution of the first program, executing a second program associated with virtualization of a second hardware configuration that is different from the first hardware configuration. Execution of the second program includes assigning, by a scheduler of the second program, threads of the first program to the plurality of processor cores based on the one or more parameters.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to 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.
When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c).
When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TUAN M NGUYEN whose telephone number is (703)756-1599. The examiner can normally be reached Monday-Friday: 9:30am - 5:30PM ET
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, Pierre Vital can be reached on (571) 272-4215. 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.
/Tuan M Nguyen/
Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights