DETAILED ACTION
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
The amendment filed on 4/29/2026 has been entered. Claims 1, 3-9, 11-17, and 19-20 remain pending in this application.
Claim Objections
Claims 1 and 9 objected to because of the following informalities: The claims recite the limitation "identifying a data processing unit based on use case associated with a thread." The claims should recite "identifying a data processing unit based on Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 5-6, 8-11, 13-14, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Saeidi.
As per claim 1, Saeidi teaches a method for processing scheduling (See Abstract), comprising: identifying a data processing unit based on use case associated with a thread (¶ [0019]-[0020], “In one embodiment, an SOC may include a variety of different processing units, such as a CPU, a GPU, a DSP, a modem, and the like. Each of the different processing units may include one or more temperature sensors that measure temperature and provide that temperature information to a control system of the chip. For example, the control system of the chip may include one or more algorithms as part of a kernel or even higher up in an operating system stack. One of those algorithms may include a core scheduler, which assigns threads to cores of the CPU. The core scheduler may use any of a multitude of criteria to prioritize cores to receive threads, such as core temperature, capabilities of the core, and the like. In one embodiment, the core scheduler takes into account a temperature reading at another processing unit, such as the GPU, and physical distance on the chip between the measured hot spot of the other processing unit and individual ones of the cores…Of course, other factors may come into account, such as temperature of an individual core itself. The core scheduler assigns threads to an individual core based at least in part on physical distance between that core and the detected hot spot.” ¶ [0033]-[0034], “During normal operation of the computing device 100 (FIG. 1), the user may interact with the computing device 100 to open or close one or more applications, to consume content such as video or audio streams, or other operations. In one example in which a user opens an application, such application may be associated with tens or hundreds of processing threads that would then be placed in various queues of the processing components 310, 320, 340, 350. Each of the cores Core 0-Core 3 includes its own processing queue, and any one of the cores Core 0-Core 3 may receive processing threads as well. The CPU scheduler is responsible for placing the processing threads in the various queues according to a variety of different criteria. One particular criterion may include capability of a core or processing unit. Another criterion includes temperature of a particular core or processing unit, where a core or processing unit having a lower temperature may be preferred over another core or processing unit having a higher temperature. Yet another criterion in this example includes physical distance from a detected hot spot. In one example operation, the CPU scheduler takes into account physical distance from a detected hot spot by consulting a table that includes fields that correlate the temperature sensor associated with the detected hot spot with respective physical distances to the various cores.”); selecting a first processing unit of a plurality of processing units to process the thread based on the use case associated with the thread and locations of the plurality of processing units within an electronic device (¶ [0029], “For example, the CPU 310 and the GPU 320 may both generate significant heat when a graphics-intensive application is executing. Where these components are placed close together, one may cause the performance of the other to suffer due to the heat it produces during operation. Thus, as shown in FIG. 3, the CPU 310 and the GPU 320 may be placed such that they are far enough from each other that the heat exposure of either component to the other may be reduced. Nevertheless, some processor cores (e.g., Core 2) may be positioned closer to the GPU 320, and thus more affected by heat generated by the GPU than processor cores located farther away (e.g., Core 0).” ¶ [0035], “Continuing with the operational example, the CPU scheduler is tasked with placing a particular processing thread with a CPU core. If the CPU scheduler detects a hot spot that corresponds to either one of the temperature sensors TJ1 or TJ2, the CPU scheduler may then access Table 400, parse the contents to identify the particular temperature sensor associated with the hot spot and determine relative physical placements of the cores with respect to the temperature sensor. The CPU scheduler may further rank the cores based on relative physical distance, ranking Core 0 the highest and Core 2 the lowest with respect to this particular criterion…However, assuming that no other criteria overrule the physical distance from the detected hot spot, the CPU scheduler then assigns the processing thread to Core 0. In some examples, applications are written to execute on two cores of a CPU, and in such an example the CPU scheduler may assign the first processing thread to Core 0 and then assign a processing thread of the same application to Core 3 because Core 3 is the second furthest CPU core.”), wherein the first processing unit is selected based on a proximity of each of the plurality of processing units to the data processing unit identified based on the use case (¶ [0046], “Continuing with the example, the CPU scheduler is determining which core(s) of the CPU should receive the processing thread, taking into account a hot spot detected at another processing unit, such as GPU 320. In such an instance, the CPU scheduler may assign the processing thread to a core based at least in part on the core's distance from the hot spot. As shown in the current example, at action 540, the load is assigned to the farthest core(s) from where the hottest temperature is sensed.” ¶ [0049], “Method 600 illuminates various aspects of scheduling processing threads, and as such, complements the description above of FIG. 5. Method 600 may be performed by a core scheduling algorithm at a processing unit, such as a CPU, GPU, DSP, or other processing unit that may have multiple cores. An example of a core scheduling algorithm is the CPU scheduler discussed above. Method 600 may be performed as part of a thread rebalancing operation or independently in response to new threads.” See also para. 0033-0034 and 0053-0054. Examiner Note: One of ordinary skill in the art would have recognized that a data processing unit could also be present in the SOC and that the thread scheduling algorithm described above could apply to a data processing unit.”); and allocating the thread to be processed on the first processing unit (¶ [0045]-[0047], “At action 530, the CPU scheduler determines whether the hot spot is inside or is outside the CPU. For instance, various embodiments may include a table or other data structure associating temperature sensors with processing units. Action 530 may include consulting such table to determine where the hotspot is located. If the hot spot is inside the CPU, then the CPU scheduler proceeds to action 550 by placing the processing thread in a queue of a core selected according to various criteria, such as quiescent current (Iddq), temperatures of respective cores (e.g., by placing a processing thread at a core having a lowest temperature among the various cores), location of core within the CPU itself, and/or the like…Continuing with the example, the CPU scheduler is determining which core(s) of the CPU should receive the processing thread, taking into account a hot spot detected at another processing unit, such as GPU 320. In such an instance, the CPU scheduler may assign the processing thread to a core based at least in part on the core's distance from the hot spot. As shown in the current example, at action 540, the load is assigned to the farthest core(s) from where the hottest temperature is sensed.”).
As per claim 3, Saeidi teaches the method of claim 1. Saeidi also teaches wherein the first processing unit is selected based on the first processing unit being further away from the data processing unit than at least a second processing unit of the plurality of processing units (¶ [0019], “In one embodiment, an SOC may include a variety of different processing units, such as a CPU, a GPU, a DSP, a modem, and the like. Each of the different processing units may include one or more temperature sensors that measure temperature and provide that temperature information to a control system of the chip. For example, the control system of the chip may include one or more algorithms as part of a kernel or even higher up in an operating system stack. One of those algorithms may include a core scheduler, which assigns threads to cores of the CPU.” ¶ [0046], “Continuing with the example, the CPU scheduler is determining which core(s) of the CPU should receive the processing thread, taking into account a hot spot detected at another processing unit, such as GPU 320. In such an instance, the CPU scheduler may assign the processing thread to a core based at least in part on the core's distance from the hot spot. As shown in the current example, at action 540, the load is assigned to the farthest core(s) from where the hottest temperature is sensed.” ¶ [0049], “Method 600 illuminates various aspects of scheduling processing threads, and as such, complements the description above of FIG. 5. Method 600 may be performed by a core scheduling algorithm at a processing unit, such as a CPU, GPU, DSP, or other processing unit that may have multiple cores. An example of a core scheduling algorithm is the CPU scheduler discussed above.” See also para. 0053-0054. Examiner Note: One of ordinary skill in the art would have recognized that a data processing unit could also be present in the SOC and that the thread scheduling algorithm described above could apply to a data processing unit.).
As per claim 5, Saeidi teaches the method of claim 1. Saeidi also teaches wherein the data processing unit comprises an image signal processor (ISP), and wherein the first processing unit is selected based on the use case being a video processing use case and based on the first processing unit being farther away the ISP than at least a second processing unit of the plurality of processing units (¶ [0019], “In one embodiment, an SOC may include a variety of different processing units, such as a CPU, a GPU, a DSP, a modem, and the like. Each of the different processing units may include one or more temperature sensors that measure temperature and provide that temperature information to a control system of the chip. For example, the control system of the chip may include one or more algorithms as part of a kernel or even higher up in an operating system stack. One of those algorithms may include a core scheduler, which assigns threads to cores of the CPU.” ¶ [0029], ““For example, the CPU 310 and the GPU 320 may both generate significant heat when a graphics-intensive application is executing. Where these components are placed close together, one may cause the performance of the other to suffer due to the heat it produces during operation. Thus, as shown in FIG. 3, the CPU 310 and the GPU 320 may be placed such that they are far enough from each other that the heat exposure of either component to the other may be reduced. Nevertheless, some processor cores (e.g., Core 2) may be positioned closer to the GPU 320, and thus more affected by heat generated by the GPU than processor cores located farther away (e.g., Core 0).” ¶ [0046], “Continuing with the example, the CPU scheduler is determining which core(s) of the CPU should receive the processing thread, taking into account a hot spot detected at another processing unit, such as GPU 320. In such an instance, the CPU scheduler may assign the processing thread to a core based at least in part on the core's distance from the hot spot. As shown in the current example, at action 540, the load is assigned to the farthest core(s) from where the hottest temperature is sensed.” ¶ [0049], “Method 600 illuminates various aspects of scheduling processing threads, and as such, complements the description above of FIG. 5. Method 600 may be performed by a core scheduling algorithm at a processing unit, such as a CPU, GPU, DSP, or other processing unit that may have multiple cores. An example of a core scheduling algorithm is the CPU scheduler discussed above.” See also para. 0033-0034 and 0053-0054. Examiner Note: One of ordinary skill in the art would have recognized that if a digital signal processor (DSP) is supported in the reference an image signal processor (ISP) could also be present in the SOC as an obvious variation and that the thread scheduling algorithm described above could apply to an ISP.).
As per claim 6, Saeidi teaches the method of claim 1. Saeidi also teaches wherein the plurality of processing units comprises a plurality of performance clusters (¶ [0020], “As an application is run in the system, the core scheduler determines cores of the CPU to handle individual ones of the threads. The core scheduler may use any of a multitude of criteria to prioritize cores to receive threads, such as core temperature, capabilities of the core, and the like. In one embodiment, the core scheduler takes into account a temperature reading at another processing unit, such as the GPU, and physical distance on the chip between the measured hot spot of the other processing unit and individual ones of the cores. It is generally assumed in this example that a larger physical distance between an individual core and a hot spot on the other processing unit would correlate with lower thermal effects at that particular core attributable to the hot spot. Of course, other factors may come into account, such as temperature of an individual core itself. The core scheduler assigns threads to an individual core based at least in part on physical distance between that core and the detected hot spot.” See also para. 0026. Examiner Note: Para. 0026 of the specification recites “…threads tend to run on one or more performance cores (e.g., performance clusters) as the central processing unit (CPU) scheduler schedules threads in this manner to reduce power consumption and performance.” Thus, cores and clusters are referring to the same thing. Prior art uses the term core rather than cluster as shown above.).
As per claim 8, Saeidi teaches the method of claim 1. Saeidi also teaches wherein the plurality of processing units are on a system-on-chip (SOC) (¶ [0019], “In one embodiment, an SOC may include a variety of different processing units, such as a CPU, a GPU, a DSP, a modem, and the like.”).
As per claim 9, it is an apparatus claim comprising similar limitations to claim 1, so it is rejected for similar reasons. Saeidi also teaches memory (¶ [0021], “Continuing with the example, the SOC includes a storage device (e.g., non-volatile memory, such as flash memory) to store a table that relates physical distance of individual cores to a particular hot spot.”) and one or more processors coupled to the memory (¶ [0026], “Of course, the scope of embodiments is not limited to any particular number of cores, as other embodiments may include two cores, eight cores, or any other appropriate number of cores in the CPU 310. SOC 300 further includes other system components, such as a first DSP 340, a second DSP 350, a modem 330, GPU 320…”).
As per claim 10, it is an apparatus claim comprising similar limitations to claim 2, so it is rejected for similar reasons.
As per claim 11, it is an apparatus claim comprising similar limitations to claim 3, so it is rejected for similar reason.
As per claim 13, it is an apparatus claim comprising similar limitations to claim 5, so it is rejected for similar reasons.
As per claim 14, it is an apparatus claim comprising similar limitations to claim 6, so it is rejected for similar reasons.
As per claim 16, it is an apparatus claim comprising similar limitations to claim 8, so it is rejected for similar reasons.
As per claim 17, it is a non-transitory computer-readable medium claim comprising similar limitations to claim 1, so it is rejected for similar reasons. Saeidi also teaches a non-transitory computer-readable medium having instructions stored thereon (See para. 0010.).
As per claim 18, it is a non-transitory computer-readable medium claim comprising similar limitations to claim 2, so it is rejected for similar reasons.
As per claim 19, it is a non-transitory computer-readable medium claim comprising similar limitations to claim 3, so it is rejected for similar reasons.
Claim(s) 4, 12, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Saeidi as applied to claims 1, 9, and 17 above, and further in view of Kumar et al. (US Patent No. 10,372,495 B2 hereinafter Kumar *cited in IDS*).
As per claim 4, Saeidi teaches the method of claim 1. Saeidi teaches wherein the data processing unit comprises a graphics processing unit (GPU), and wherein the first processing unit is selected based on the use case being a graphics intensive use case (¶ [0029], “For example, the CPU 310 and the GPU 320 may both generate significant heat when a graphics-intensive application is executing. Where these components are placed close together, one may cause the performance of the other to suffer due to the heat it produces during operation. Thus, as shown in FIG. 3, the CPU 310 and the GPU 320 may be placed such that they are far enough from each other that the heat exposure of either component to the other may be reduced. Nevertheless, some processor cores (e.g., Core 2) may be positioned closer to the GPU 320, and thus more affected by heat generated by the GPU than processor cores located farther away (e.g., Core 0).”) and based on the first processing unit being farther away the GPU than at least a second processing unit of the plurality of processing units (¶ [0020], “In one embodiment, the core scheduler takes into account a temperature reading at another processing unit, such as the GPU, and physical distance on the chip between the measured hot spot of the other processing unit and individual ones of the cores. It is generally assumed in this example that a larger physical distance between an individual core and a hot spot on the other processing unit would correlate with lower thermal effects at that particular core attributable to the hot spot.” ¶ [0046], “Continuing with the example, the CPU scheduler is determining which core(s) of the CPU should receive the processing thread, taking into account a hot spot detected at another processing unit, such as GPU 320. In such an instance, the CPU scheduler may assign the processing thread to a core based at least in part on the core's distance from the hot spot. As shown in the current example, at action 540, the load is assigned to the farthest core(s) from where the hottest temperature is sensed.”).
Saeidi does not explicitly teach a gaming use case as the reason for selecting a processing unit.
However, Kumar teaches wherein the first processing unit is selected based on the use case being a gaming use case (Col. 3, lines 34-49, “For example, a particular videogame application may be known by the SOC to have requirements for frequency of operation as well as be known for causing a certain amount of heat dissipation at the GPU and at the CPU cores—this is one example of historical use data. This information may be stored in a table or other memory structure by the SOC. Further, information regarding resource usage may be used to update the information stored in the memory structure. When a user opens the application, the SOC accesses the table from memory and determines an acceptable selection of processing cores within the CPU, and hardware threads within those cores to handle execution of the application.”).
Saeidi and Kumar are considered to be analogous to the claimed invention because they are in the same field of thread scheduling and thermal management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Saeidi with Kumar to arrive at the claimed invention. The motivation to modify Saeidi with the teachings of Kumar is that having knowledge that a gaming application is executing on the system allows the system to schedule threads on processing units farther away from the GPU that is executing the gaming application. This allows the threads to execute without being affected by the heat being produced at the GPU.
As per claim 12, it is an apparatus claim comprising similar limitations to claim 4, so it is rejected for similar reasons.
As per claim 20, it is a non-transitory computer-readable medium claim comprising similar limitations to claim 4, so it is rejected for similar reasons.
Claim(s) 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Saeidi as applied to claims 1 and 9 above, and further in view of Chow et al. (NPL Document - "GPUCalorie: Floorplan Estimation for GPU Thermal Evaluation" hereinafter Chow *cited in IDS*).
As per claim 7, Saeidi teaches the method of claim 1. Saeidi teaches identifying a configuration of the SOC, wherein the configuration indicates the locations of the plurality of processing units (¶ [0034]-[0035], “In one example operation, the CPU scheduler takes into account physical distance from a detected hot spot by consulting a table that includes fields that correlate the temperature sensor associated with the detected hot spot with respective physical distances to the various cores. An example is shown in FIG. 4. Table 400 includes two rows, where each row corresponds to one of the temperature sensors TJ1 and TJ2. Each of the columns correlates the respective temperature sensor with a relative physical distance to a particular one of the cores. For instance, with respect to temperature sensor TJ1, Core 0 is the furthest core, whereas Core 2 is the closest CPU core to that particular temperature sensor…Continuing with the operational example, the CPU scheduler is tasked with placing a particular processing thread with a CPU core. If the CPU scheduler detects a hot spot that corresponds to either one of the temperature sensors TJ1 or TJ2, the CPU scheduler may then access Table 400, parse the contents to identify the particular temperature sensor associated with the hot spot and determine relative physical placements of the cores with respect to the temperature sensor.”).
Saeidi fails to explicitly teach identifying a die type and configuration of the die/SOC based on the type.
However, Chow teaches identifying a die type including the plurality of processing units and identifying a configuration of the die based on the type, wherein the configuration indicates the locations of the plurality of processing units (Pg. 239, section II – “GPUCalorie Floorplan Identification”, “GPUCalorie also provides a floorplan estimator that derives a sub-SM component-level floorplan through microbenchmarking and empirical infrared thermography. Together, these two techniques provide modern thermal floorplans and component level energy estimates of GPU components, enabling thermal evaluation of modern GPUs… We transform the thermal map to identify spatial heat generation [9] (which we call a power map)…In other words, we can identify heat generation from thermal output at steady-state. In order to identify the power sources from the filtered heatmaps, we refer to the 2D steady-state thermal found in [9]. The peaks in the power maps are power sources and the troughs are power sinks (where power output is less than the cooling). Now we are able to derive locations of individual components within the SM.”).
Saeidi and Chow are considered to be analogous to the claimed invention because they are in the same field of thread scheduling and thermal management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Saeidi with the floorplan identification/configuration functionality of Chow to arrive at the claimed invention. The motivation to modify Saeidi with the teachings of Chow is that having knowledge of the configuration of a die allows for proper thermal management of the die because thread scheduling can consider the locations of intense heat-producing components.
As per claim 15, it is an apparatus claim comprising similar limitation to claim 7, so it is rejected for similar reasons.
Response to Arguments
Applicant’s arguments, filed 4/29/2026, with respect to the 35 U.S.C. § 101 rejection have been fully considered and are persuasive. The 35 U.S.C. § 101 rejection of claims 1-20 has been withdrawn. Applicant's arguments, filed 4/29/2026, with respect to the prior art rejections of claims 1-20 have been fully considered but they are not persuasive. Applicant argues that Saeidi fails to teach the limitations of the amended independent claims, 1, 9, and 17. Specifically, Applicant argues that Saeidi does not teach “identifying a data processing unit based on a use case associated with a thread” and “selecting the first processing unit to process the thread based on the proximity to that identified data processing unit.” Examiner disagrees with this argument. Saeidi teaches identifying a processing unit (e.g., CPU, GPU, or data processing unit) to execute a thread wherein the identifying step may take into account the capability of the processing unit to execute the thread (e.g., a use case) as well as take into account the proximity of the identified processing unit to other processing units that may impact the performance of the identified processing unit in executing the thread. Examiner also acknowledges the proactive vs. reactive argument that cites para. 0030 of the instant application’s specification which states “when scheduling a thread for the first time without prior knowledge of a performance cluster that will tend to overheat more than another performance cluster, the scheduling may not be efficient.” However, this argument reads the specification into the claims, and the current language of the claims under the broadest reasonable interpretation is taught by Saeidi.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 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, Lewis Bullock can be reached at (571)272-3759. 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.
/J.D.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights