DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation
2. The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
3. The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “scheduler” in claims 1-10 and 20.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. A review of the disclosure, as originally filed, finds no support for the structure of these limitations. Examiner notes that for computer-implemented technologies, structural support may be derived from a "computer" + "algorithm", see MPEP § 2181, however, Examiner does not find support for a specific structure nor a general computer that is specially programmed by an algorithm in the specification corresponding to the limitations above which invoke 35 U.S.C. § 112(f). For the purpose of compact prosecution and applying art, Examiner will interpret the limitations as a generic computer/processor for performing instructions for carrying out the claimed functionality.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
4. 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.
5. Claims 1-10 and 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. Claim limitation “scheduler” invokes 35 U.S.C 112(f) or pre-AIA 35 U.S.C 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts to the function. A review of the specification finds no support for the structure of these limitations. Examiner notes that for computer-implemented technologies, structural support may be derived from a "computer" + "algorithm", see MPEP § 2181, however, Examiner does not find support for a specific structure nor a general computer that is specially programmed by an algorithm in the specification corresponding to the limitations above which invoke 35 U.S.C. § 112(f). See MPEP § 2181(II)(B) "When a claim containing a computer-implemented 35 U.S.C. 112(f) claim limitation is found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, it will also lack written description under 35 U.S.C. 112(a)". For the purpose of compact prosecution and applying art, Examiner will interpret the limitations as a generic computer/processor for performing instructions for carrying out the claimed functionality. See claim interpretation under 35 U.S.C. § 112(f) above and rejection under 35 U.S.C. § 112(b) below. Therefore, 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.
6. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
7. Claims 1-10 and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim limitation “scheduler” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. A review of the specification finds no support for the structure of these limitations. Examiner notes that for computer-implemented technologies, structural support may be derived from a "computer" + "algorithm", see MPEP § 2181, however, Examiner does not find support for a specific structure nor a general computer that is specially programmed by an algorithm in the specification corresponding to the limitations above which invoke 35 U.S.C. § 112(f). Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
8. For the purpose of compact prosecution and applying art, Examiner will interpret the limitations as a generic computer/processor for performing instructions for carrying out the claimed functionality. See claim interpretation under 35 U.S.C. § 112(f) above and rejection under 35 U.S.C. § 112(a) above.
Claim Rejections - 35 USC § 101
9. 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.
10. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-10, and 20 are directed to systems and fall within the statutory category of machines and claims 11-19 are directed to methods and fall within the statutory category of processes. Therefore, "Are the claims to a process, machine, manufacture or composition of matter?" Yes.
In order to evaluate the Step 2A inquiry "Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?" we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claim 1: The limitations of “a scheduler configured to schedule threads on the first cores and the second cores based on the first affinity information”, “the scheduler is further configured to determine that the first thread is to be scheduled on the second cores based on the first affinity information”, “to schedule the first thread on the first cores based on the first indication”, as drafted, are processes that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, evaluating hardware provided information and scheduler-facing instructions/hints (affinity information and indications), making a determination on thread allocation based off that information, and selecting a scheduling destination can all be practically done in the human mind by observing, thinking, and making judgement.
Claim 11: The limitations of “providing, on the information handling system, a scheduler configured to schedule threads on the first cores and the second cores based on the first affinity information”, “determining, by the scheduler, that first thread is to be scheduled on the second cores based on the first affinity information”, and “scheduling, by the scheduler, the first thread on the first cores based on the first indication”, as drafted, are processes that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, evaluating hardware provided information and scheduler-facing instructions/hints (affinity information and indications), making a determination on allocation based off that information, and selecting a scheduling destination can all be practically done in the human mind by observing, thinking, and making judgement.
Claim 20: The limitations of “a scheduler configured to schedule threads on the performance cores and the efficiency cores based on the affinity information”, “the scheduler is further configured to determine that the thread is to be scheduled on the efficiency cores based on the affinity information”, and “to schedule the thread on the performance cores based on the indication”, as drafted, are processes that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, evaluating hardware provided information and scheduler-facing instructions/hints (affinity information and indications), making a determination on allocation based off that information, and selecting a scheduling destination can all be practically done in the human mind by observing, thinking, and making judgement.
Therefore, Yes, claim 1 recites judicial exceptions.
The claims have been identified to recite judicial exceptions, Step 2A Prong 2 will evaluate whether the claims are directed to the judicial exception.
Step 2A Prong 2:
Claims 1 and 11: The judicial exception is not integrated into a practical application. In particular, the claim recites the following additional elements – “a processor” and “a scheduler” are merely recitations of generic computing components and functions being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)) which do not integrate a judicial exception into practical application. They also recite “first cores and second cores” which is merely a recitation of field of use/technological environment (see MPEP § 2106.05(h)) without imposing meaningful limitation and does not integrate a judicial exception into practical application. Moreover, the following additional elements – “the processor configured to provide first affinity information associated with the first cores and the second cores”, “the information handling system is configured to provide a first indication to the scheduler to schedule a first thread on the first cores” (Claim 1), and “providing a first indication to the scheduler to schedule a first thread on the first cores” (Claim 11) are merely recitations of insignificant extra-solution data transmission activity (see MPEP § 2106.05(g)) which do not integrate a judicial exception into practical application. The insignificant extra-solution activity is further addressed below under step 2B as also being Well-Understood, Routine, and Conventional (WURC).
Claim 20: The judicial exception is not integrated into a practical application. In particular, the claim recites the following additional elements – “a processor” and “a scheduler” are merely recitations of generic computing components and functions being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)) which do not integrate a judicial exception into practical application. They also recite “a plurality of performance cores” and “a plurality of efficiency cores” which are merely recitations of field of use/technological environment (see MPEP § 2106.05(h)) without imposing meaningful limitation which do not integrate a judicial exception into practical application. Moreover, the following additional elements – “the processor configured to provide first affinity information associated with the first cores and the second cores” and “the information handling system is configured to provide a first indication to the scheduler to schedule a first thread on the first cores” are merely recitations of insignificant extra-solution data transmission activity (see MPEP § 2106.05(g)) which do not integrate a judicial exception into practical application. The insignificant extra-solution activity is further addressed below under step 2B as also being Well-Understood, Routine, and Conventional (WURC).
Therefore, "Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluating the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that the claims 1, 11, and 20 not only recite a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claims 1, 11, and 20: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components being used as a tool to apply the abstract idea, field of use/technological environment, and insignificant extra-solution activity which do not amount to significantly more than the abstract idea. Further, with regard to the insignificant extra-solution data gathering and transmission activity, it is also Well-Understood, Routine and Conventional as evidenced in at least MPEP § 2106.05(d)(II) "The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data” wherein transmitting data is Well-Understood, Routine and Conventional, therefore, the instant providing of information, too, is WURC.
Therefore, "Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claims 1, 11, and 20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 2 and 12, they recite additional elements of “performance cores” and “efficiency cores” which are merely recitations of generic computing components used in a field of use/technological environment (see MPEP § 2106.05(h)) and do not integrate a judicial exception into practical application. Further, claims 2 and 12 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 2 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 2 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 3 and 13, they recite additional abstract idea recitations of “the scheduler determines that the first thread is to be scheduled on the second cores when the information handling system is in an efficiency mode of operation”(claim 3) and “determining that the first thread is to be scheduled on the second cores when the information handling system is in an efficiency mode of operation”(claim 13) as drafted, are processes that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about and observe, judge and evaluate a mode of operation and make a determination to schedule tasks. Further, claims 3 and 13 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 3 and 13 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 3 and 13 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 4 and 14, they recite “the information handling system provides the first indication in response to a user input to the information handling system” (claim 4), ”providing the first indication is in response to a user input to the information handling system” (claim 14), and “the user input selecting the first thread” (claims 4 and 14) as drafted, are merely recitations of insignificant extra-solution data gathering/transmission activity (see MPEP § 2106.05(g)) and do not integrate a judicial exception into practical application. The insignificant extra-solution data gathering/transmission is also WURC, see at least MPEP § 2106.05(d)(II) "The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra- solution activity. i. Receiving or transmitting data over a network” wherein transmitting data is Well-Understood, Routine and Conventional, therefore, the instant providing of information, too, is WURC. Moreover, claims 4 and 14 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 4 and 14 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 4 and 14 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 5 and 15, they recite additional abstract idea recitations of “the scheduler is further configured to determine that second thread is to be scheduled on the first cores based on the first affinity information” (claim 5), “to schedule the second thread on the second cores based on the second indication” (claim 5), “determining that second thread is to be scheduled on the first cores based on the first affinity information” (claim 15), and “scheduling the second thread on the second cores based on the second indication” (claim 15) as drafted, are processes that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, evaluating hardware provided information and scheduler-facing instructions/hints (affinity information and indications), making a determination on allocation based off that information, and selecting a scheduling destination can all be practically done in the human mind by observing, thinking, and making judgement. Moreover, they recite “the information handling system is further configured to provide a second indication to the scheduler to schedule a second thread on the second cores” (claim 5) and “providing a second indication to the scheduler to schedule a second thread on the second cores” (claim 15) which are merely recitations of insignificant extra-solution data transmission activity (see MPEP § 2106.05(g)) and do not integrate a judicial exception into practical application. The insignificant extra-solution data transmission is also WURC, see at least MPEP § 2106.05(d)(II) "The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra- solution activity. i. Receiving or transmitting data over a network” wherein transmitting data is Well-Understood, Routine and Conventional, therefore, the instant providing of information, too, is WURC. Claims 5 and 15 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 5 and 15 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 5 and 15 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 6 and 16, they recite additional abstract idea recitations of “the scheduler determines that the second thread is to be scheduled on the first cores when the information handling system is in a performance mode of operation” (claim 6) and “determining that the second thread is to be scheduled on the first cores when the information handling system is in a performance mode of operation” (claim 16) as drafted, are processes that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can think about and observe, judge and evaluate a mode of operation and make a determination to schedule tasks. Further, claims 6 and 16 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 6 and 16 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 6 and 16 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 7 and 17, they recite “the information handling system provides the second indication in response to a user input to the information handling system” (claim 7), ” providing the second indication is in response to a user input to the information handling system” (claim 17), and “the user input selecting the second thread” (claims 7 and 17) as drafted, are merely recitations of insignificant extra-solution data gathering/transmission activity (see MPEP § 2106.05(g)) and does not integrate a judicial exception into practical application. The insignificant extra-solution data gathering and transmission is also WURC, see at least MPEP § 2106.05(d)(II) "The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra- solution activity. i. Receiving or transmitting data over a network” wherein transmitting data is Well-Understood, Routine and Conventional, therefore, the instant providing of information, too, is WURC. Moreover, claims 7 and 17 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 7 and 17 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 7 and 17 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 8 and 18, they recite “comprising a memory device” (claim 8), “comprising providing a memory device” (claim 18) which are merely recitations of generic computing components and functions being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)) and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more. They also recite “the processor is further configured to store the affinity information to the memory device” (claims 8 and 18) as drafted, are merely recitations of insignificant extra-solution data gathering activity (see MPEP § 2106.05(g)) and do not integrate a judicial exception into practical application. The insignificant extra-solution data gathering is also WURC, see at least MPEP § 2106.05(d)(II) "The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra- solution activity. iv. Storing and retrieving information in memory” wherein data storage in memory is Well-Understood, Routine and Conventional. Moreover, claims 8 and 18 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 8 and 18 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claims 8 and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 9 and 19, they recite additional abstract idea recitations of “the scheduler is further configured to schedule threads on the accelerator based on the second affinity information” claims (9 and 19), “the scheduler is further configured to determine that the second thread is to be scheduled on the processor based on the first and second affinity information” (claim 9), and “to schedule the second thread on the accelerator based on the second indication” (claim 9), “determining, by the scheduler, that the second thread is to be scheduled on the processor based on the first and second affinity information” (claim 19), and “scheduling, by the scheduler, the second thread on the accelerator based on the second indication” (claim 19), as drafted, are processes that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, evaluating hardware provided information and scheduler-facing instructions/hints (affinity information and indications), making a determination on allocation based off that information, and selecting a scheduling destination can all be practically done in the human mind by observing, thinking, and making judgement. Further, claims 9 and 19 recite “an accelerator” which are merely recitations of generic computing components and functions being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)) and do not integrate a judicial exception into practical application. Moreover, they recite “an accelerator configured to provide second affinity information associated with accelerator” (claims 9 and 19), “the information handling system is configured to provide a second indication to the scheduler to schedule a second thread on the accelerator” (claim 9), and “providing a second indication to the scheduler to schedule a second thread on the accelerator” (claim 19) which are merely recitations of insignificant extra-solution data transmission activity (see MPEP § 2106.05(g)) and do not integrate a judicial exception into practical application. The insignificant extra-solution data transmission is also WURC, see at least MPEP § 2106.05(d)(II) "The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra- solution activity. i. Receiving or transmitting data over a network” wherein transmitting data is Well-Understood, Routine and Conventional, therefore, the instant providing of information, too, is WURC. Claims 9 and 19 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 9 and 19 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 9 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 10, they recite additional abstract idea recitations of “the processor is configured to implement an Intel Enhanced Hardware Guided Scheduling” as drafted, is merely a recitation of insignificant extra-solution data transmission activity (see MPEP § 2106.05(g)). The insignificant extra-solution data transmission is also WURC, see at least MPEP § 2106.05(d)(II) "The courts have recognized the following computer functions as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra- solution activity. i. Receiving or transmitting data over a network” wherein transmitting data is Well-Understood, Routine and Conventional, therefore, the instant providing of information, too, is WURC. Claim 10 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 10 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 10 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Therefore, Claims 1-20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 103
11. 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.
12. Claims 1-7 and 11-17 are rejected under 35 U.S.C. 103 as being unpatentable over by Singh et al. Pub. No. US 2016/0092274 A1 (hereafter Singh) in view of ZEDLEWSKI et al. Pub No. 2012/0227042 A1 (hereafter Zed).
13. With regard to claim 1, Singh teaches an information handling system, comprising: a processor having first cores of a first type and second cores of a second type (FIG. 2 depicts generally at 200 example details of a computing device 102 having heterogeneous cores in accordance with one or more implementations. By way of example and not limitation, the processing system 104 is depicted as having performance oriented cores 202 and power efficient cores 204. The performance oriented cores 202 are representative of cores designed for high performance and the power efficient cores 204 are representative of cores designed to consume low power in at least paragraph [0029]);
the processor configured to provide first affinity information associated with the first cores and the second cores (In one or more implementations, thread policies are used to generate compact representations that map permitted cores to threads, such as by using a bit map, data string, thread properties, mapping database, or other suitable data structure configured to indicate core affinities that may include indications of preferred cores, permitted cores, and/or restricted cores on a thread-by-thread basis in at least paragraph [0041]);
a scheduler configured to schedule threads on the first cores and the second cores based on the first affinity information (For example, a thread scheduler module 128 may operate to establish, maintain, and assign thread policies to threads as part of high frequency (e.g., thread-by-thread) placement decisions described throughout this document. The thread policies 210 may be configured in various ways to specify combinations of heterogeneous cores, one or more different types of cores, and/or particular individual cores on which a corresponding thread is permitted to run. In one or more implementations, thread policies are used to generate compact representations that map permitted cores to threads, such as by using a bit map, data string, thread properties, mapping database, or other suitable data structure configured to indicate core affinities that may include indications of preferred cores, permitted cores, and/or restricted cores on a thread-by-thread basis in at least paragraph [0041]);
the scheduler is further configured to determine that the first thread is to be scheduled on the second cores based on the first affinity information (Threads are allocated on a thread-by-thread basis among the subset of the heterogeneous cores and in accordance with the thread policies assigned to the individual threads (block 406). For example, the thread scheduler module 128 may perform scheduling using the thread policies associated with different threads under the constraints imposed by application of the power management policy. In particular, the thread scheduler module 128 is restricted to scheduling using the subset of the heterogeneous cores ascertained per block 404. The scheduling may therefore involve reconciling the core state data that indicates available cores with the thread policies which indicates core affinities for each thread to derive usable cores for each scheduling event. The set of usable cores reflects the intersection between availability indicated by the core state data and core affinities reflected by the thread policies. Thus, the thread policy assigned to a particular thread may be used to determine core affinities for the particular thread and the thread may be placed with one of the heterogeneous cores in accordance with the core affinities that are determined in at least paragraph [0049]);
Singh teaches processors configured with first and second types, and a scheduling based on affinity information provided by the processor. While they also teach a power management policy which may be configurable by developers and/or users to shift the balance more towards performance or more towards efficient power usage as an alternative (See paragraph [0033] and [0038]), they don’t explicitly teach dynamic re-scheduling via indications for thread allocations by replacing the already available scheduling based on the core affinities.
However, in analogous art, Zed teaches the information handling system is configured to provide a first indication to the scheduler to schedule a first thread on the first cores (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
to schedule the first thread on the first cores based on the first indication (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the dynamically configurable rescheduling taught by Zed with the information handling system taught by Singh. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
14. With regard to claim 2, Singh and Zed teach the information handling system of claim 1 and Singh also teaches that the first cores include performance cores and the second cores include efficiency cores (By way of example and not limitation, the processing system 104 is depicted as having performance oriented cores 202 and power efficient cores 204 in at least paragraph [0029]).
15. With regard to claim 3, Singh and Zed teach the information handling system of claim 2 and Singh also teaches that the scheduler determines that the first thread is to be scheduled on the second cores when the information handling system is in an efficiency mode of operation (Cores states are set for at least some of the heterogeneous cores based on the operational context to control activation of the power efficient cores and performance oriented cores for thread scheduling (block 304). For instance, a processing system 104 that is the subject of analysis may include heterogeneous cores that may be selectively activated or deactivated based upon analysis of the operational context and a power management policy. The power management policy may be configured to define which cores of a heterogeneous system are parked and unparked in different operational contexts. For example, in a low battery state one or more performance oriented cores may be parked in an idle state to conserve power and/or one or more power efficient cores may be unparked into active states to service the workload in at least [0038] and thread scheduling for the heterogeneous cores may be performed under the influence of the power management policy and core state selections made based on the operational context. In particular, individual threads are scheduled in dependence upon the core states set based on the periodic analysis to allocate the individual threads between active cores of the heterogeneous cores on a per-thread basis (block 306). For example, an operating system 108 may include a thread scheduler module 128 or comparable functionality configured to make high frequency thread placement decisions in at least paragraph [0039]).
16. With regard to claim 4, Singh and Zed teach the method of claim 3 and while Singh teaches user input (Moreover, the power management policy may be configurable by developers and/or users to shift the balance more towards performance or more towards efficient power usage in at least paragraph [0038]), they do not explicitly teach that the method provides the second indication in response to the user input and that the user input selects the second thread.
However, in analogous art, Zed teaches that the providing the first indication is in response to a user input to the information handling system (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
the user input selecting the first thread (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the user input selecting the thread taught by Zed with the method taught by Singh and Zed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
17. With regard to claim 5, Singh and Zed teach the information handling system of claim 2. Singh also teaches that the scheduler is further configured to determine that second thread is to be scheduled on the first cores based on the first affinity information (Threads are allocated on a thread-by-thread basis among the subset of the heterogeneous cores and in accordance with the thread policies assigned to the individual threads (block 406). For example, the thread scheduler module 128 may perform scheduling using the thread policies associated with different threads under the constraints imposed by application of the power management policy. In particular, the thread scheduler module 128 is restricted to scheduling using the subset of the heterogeneous cores ascertained per block 404. The scheduling may therefore involve reconciling the core state data that indicates available cores with the thread policies which indicates core affinities for each thread to derive usable cores for each scheduling event. The set of usable cores reflects the intersection between availability indicated by the core state data and core affinities reflected by the thread policies. Thus, the thread policy assigned to a particular thread may be used to determine core affinities for the particular thread and the thread may be placed with one of the heterogeneous cores in accordance with the core affinities that are determined in at least paragraph [0049]);
Singh teaches scheduling based on affinity information provided by the processor and while they also teach a power management policy which may be configurable by developers and/or users to shift the balance more towards performance or more towards efficient power usage as an alternative (See paragraph [0033] and [0038]), they don’t explicitly teach dynamic re-scheduling via indications for thread allocations by replacing the already available scheduling based on the core affinities.
However, in analogous art, Zed teaches that the information handling system is further configured to provide a second indication to the scheduler to schedule a second thread on the second cores (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
to schedule the second thread on the second cores based on the second indication (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the dynamically configurable rescheduling taught by Zed with the information handling system taught by Singh and Zed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
18. With regard to claim 6, Singh and Zed teach the information handling system of claim 5 and Singh also teaches that the scheduler determines that the second thread is to be scheduled on the first cores when the information handling system is in a performance mode of operation (Cores states are set for at least some of the heterogeneous cores based on the operational context to control activation of the power efficient cores and performance oriented cores for thread scheduling (block 304). For instance, a processing system 104 that is the subject of analysis may include heterogeneous cores that may be selectively activated or deactivated based upon analysis of the operational context and a power management policy. The power management policy may be configured to define which cores of a heterogeneous system are parked and unparked in different operational contexts. For example, in a low battery state one or more performance oriented cores may be parked in an idle state to conserve power and/or one or more power efficient cores may be unparked into active states to service the workload in at least [0038] and thread scheduling for the heterogeneous cores may be performed under the influence of the power management policy and core state selections made based on the operational context. In particular, individual threads are scheduled in dependence upon the core states set based on the periodic analysis to allocate the individual threads between active cores of the heterogeneous cores on a per-thread basis (block 306). For example, an operating system 108 may include a thread scheduler module 128 or comparable functionality configured to make high frequency thread placement decisions in at least paragraph [0039]).
19. With regard to claim 7, Singh and Zed teach the method of claim 6 and while Singh teaches user input (Moreover, the power management policy may be configurable by developers and/or users to shift the balance more towards performance or more towards efficient power usage in at least paragraph [0038]), they do not explicitly teach that the method provides the second indication in response to the user input and that the user input selects the second thread.
However, in analogous art, Zed teaches that the providing the second indication is in response to a user input to the information handling system (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
the user input selecting the second thread (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the user input selecting the thread taught by Zed with the method taught by Singh and Zed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
20. With regard to claim 11, Singh teaches a method, comprising: providing, on an information handling system (A method implemented by a computing device comprising: assigning thread policies to individual threads, the thread policies specifying criteria for allocation of threads between heterogeneous cores of a processing system; ascertaining a subset of the heterogeneous cores selected as active for thread scheduling according to a periodically applied power management policy; and allocating threads on a thread-by-thread basis among the subset of the heterogeneous cores and in accordance with the thread policies assigned to the individual threads in at least paragraph [0086] and a method as described above, wherein the heterogeneous cores include at least performance oriented cores and power efficient cores, the performance oriented cores configured to reduce processing time for completion of particular tasks relative to the power efficient cores and the power efficient cores configured to consume less power for completion of particular tasks relative to the performance oriented cores in at least [0087]);
the processor configured to provide first affinity information associated with the first cores and the second cores (Thread policies are assigned to individual threads that specify criteria for allocation of threads between heterogeneous cores of a processing system (block 402). For example, a thread scheduler module 128 may operate to establish, maintain, and assign thread policies to threads as part of high frequency (e.g., thread-by-thread) placement decisions described throughout this document. The thread policies 210 may be configured in various ways to specify combinations of heterogeneous cores, one or more different types of cores, and/or particular individual cores on which a corresponding thread is permitted to run. In one or more implementations, thread policies are used to generate compact representations that map permitted cores to threads, such as by using a bit map, data string, thread properties, mapping database, or other suitable data structure configured to indicate core affinities that may include indications of preferred cores, permitted cores, and/or restricted cores on a thread-by-thread basis in at least paragraph [0041]);
providing, on the information handling system, a scheduler configured to schedule threads on the first cores and the second cores based on the first affinity information (For example, a thread scheduler module 128 may operate to establish, maintain, and assign thread policies to threads as part of high frequency (e.g., thread-by-thread) placement decisions described throughout this document. The thread policies 210 may be configured in various ways to specify combinations of heterogeneous cores, one or more different types of cores, and/or particular individual cores on which a corresponding thread is permitted to run in at least paragraph [0041], Examiner notes that in this context, the scheduler uses thread policies to schedule threads on the cores);
providing a first indication to the scheduler to schedule a first thread on the first cores (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the dynamically configurable rescheduling taught by Zed with the information handling system taught by Singh. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
determining, by the scheduler, that first thread is to be scheduled on the second cores based on the first affinity information (The thread policies 210 may be configured in various ways to specify combinations of heterogeneous cores, one or more different types of cores, and/or particular individual cores on which a corresponding thread is permitted to run. In one or more implementations, thread policies are used to generate compact representations that map permitted cores to threads, such as by using a bit map, data string, thread properties, mapping database, or other suitable data structure configured to indicate core affinities that may include indications of preferred cores, permitted cores, and/or restricted cores on a thread-by-thread basis in at least [0041] and for example, thread policies may be established to cause placement of low priority threads to power efficient cores whereas threads with time deadlines and high priority may be placed with performance oriented cores in at least [0043]);
scheduling, by the scheduler, the first thread on the first cores based on the first indication (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the dynamically configurable rescheduling taught by Zed with the information handling system taught by Singh. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
21. With regard to claim 12, Singh and Zed teach the method of claim 11 and Singh also teaches the first cores include performance cores and the second cores include efficiency cores (By way of example and not limitation, the processing system 104 is depicted as having performance oriented cores 202 and power efficient cores 204 in at least paragraph [0029]).
22. With regard to claim 13, Singh and Zed teach the method of claim 12 and Singh also teaches that the scheduler determines that the first thread is to be scheduled on the second cores when the information handling system is in an efficiency mode of operation (Cores states are set for at least some of the heterogeneous cores based on the operational context to control activation of the power efficient cores and performance oriented cores for thread scheduling (block 304). For instance, a processing system 104 that is the subject of analysis may include heterogeneous cores that may be selectively activated or deactivated based upon analysis of the operational context and a power management policy. The power management policy may be configured to define which cores of a heterogeneous system are parked and unparked in different operational contexts. For example, in a low battery state one or more performance oriented cores may be parked in an idle state to conserve power and/or one or more power efficient cores may be unparked into active states to service the workload in at least [0038] and thread scheduling for the heterogeneous cores may be performed under the influence of the power management policy and core state selections made based on the operational context. In particular, individual threads are scheduled in dependence upon the core states set based on the periodic analysis to allocate the individual threads between active cores of the heterogeneous cores on a per-thread basis (block 306). For example, an operating system 108 may include a thread scheduler module 128 or comparable functionality configured to make high frequency thread placement decisions in at least paragraph [0039]).
23. With regard to claim 14, Singh and Zed teach the method of claim 13 and while Singh teaches user input (Moreover, the power management policy may be configurable by developers and/or users to shift the balance more towards performance or more towards efficient power usage in at least paragraph [0038]), they do not explicitly teach that the method provides the second indication in response to the user input and that the user input selects the second thread.
However, in analogous art, Zed teaches that the providing the first indication is in response to a user input to the information handling system (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
the user input selecting the first thread (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the user input selecting the thread taught by Zed with the method taught by Singh and Zed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
24. With regard to claim 15, Singh and Zed teach the information handling system of claim 12. Singh also teaches that determining that second thread is to be scheduled on the first cores based on the first affinity information (Threads are allocated on a thread-by-thread basis among the subset of the heterogeneous cores and in accordance with the thread policies assigned to the individual threads (block 406). For example, the thread scheduler module 128 may perform scheduling using the thread policies associated with different threads under the constraints imposed by application of the power management policy. In particular, the thread scheduler module 128 is restricted to scheduling using the subset of the heterogeneous cores ascertained per block 404. The scheduling may therefore involve reconciling the core state data that indicates available cores with the thread policies which indicates core affinities for each thread to derive usable cores for each scheduling event. The set of usable cores reflects the intersection between availability indicated by the core state data and core affinities reflected by the thread policies. Thus, the thread policy assigned to a particular thread may be used to determine core affinities for the particular thread and the thread may be placed with one of the heterogeneous cores in accordance with the core affinities that are determined in at least paragraph [0049]);
Singh teaches scheduling based on affinity information provided by the processor and while they also teach a power management policy which may be configurable by developers and/or users to shift the balance more towards performance or more towards efficient power usage as an alternative (See paragraph [0033] and [0038]), they don’t explicitly teach dynamic re-scheduling via indications for thread allocations by replacing the already available scheduling based on the core affinities.
However, in analogous art, Zed teaches that providing a second indication to the scheduler to schedule a second thread on the second cores (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
scheduling the second thread on the second cores based on the second indication (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the dynamically configurable rescheduling taught by Zed with the information handling system taught by Singh and Zed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
25. With regard to claim 16, Singh and Zed teach the information handling system of claim 15 and Singh also teaches that the scheduler determines that the second thread is to be scheduled on the first cores when the information handling system is in a performance mode of operation (Cores states are set for at least some of the heterogeneous cores based on the operational context to control activation of the power efficient cores and performance oriented cores for thread scheduling (block 304). For instance, a processing system 104 that is the subject of analysis may include heterogeneous cores that may be selectively activated or deactivated based upon analysis of the operational context and a power management policy. The power management policy may be configured to define which cores of a heterogeneous system are parked and unparked in different operational contexts. For example, in a low battery state one or more performance oriented cores may be parked in an idle state to conserve power and/or one or more power efficient cores may be unparked into active states to service the workload in at least [0038] and thread scheduling for the heterogeneous cores may be performed under the influence of the power management policy and core state selections made based on the operational context. In particular, individual threads are scheduled in dependence upon the core states set based on the periodic analysis to allocate the individual threads between active cores of the heterogeneous cores on a per-thread basis (block 306). For example, an operating system 108 may include a thread scheduler module 128 or comparable functionality configured to make high frequency thread placement decisions in at least paragraph [0039]).
26. With regard to claim 17, Singh and Zed teach the method of claim 16 and while Singh teaches user input (Moreover, the power management policy may be configurable by developers and/or users to shift the balance more towards performance or more towards efficient power usage in at least paragraph [0038]), they do not explicitly teach that the method provides the second indication in response to the user input and that the user input selects the second thread.
However, in analogous art, Zed teaches that the providing the second indication is in response to a user input to the information handling system (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
the user input selecting the second thread (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the user input selecting the thread taught by Zed with the method taught by Singh and Zed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
27. Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over by Singh et al. Pub. No. US 2016/0092274 A1 (hereafter Singh) in view of ZEDLEWSKI et al. Pub No. 2012/0227042 A1 (hereafter Zed) as applied to claims 1-7 and 11-17 above, and further in view of Sarrazin-Boucher et al. Pub. No. US 2018/0131756 A1 (hereafter Sarrazin).
28. With regard to claim 8, while Singh and Zed teach the information handling system of claim 1 and a memory device (Any of the computing devices can be implemented with various components, such as one or more processors and memory devices, as well as with any combination of differing components. One example of a computing system that can represent various systems and/or devices including the computing device 102 is shown and described below in relation to FIG. 6 in at least paragraph [0019] of Singh), they do not explicitly teach that the affinity information is stored in the memory device.
However, in analogous art, Sarrazin teaches that the processor is further configured to store the affinity information to the memory device (The task manager 128 accesses the task affinities 126 in order to determine whether the current server (in the present example, server 106.sub.1) has an affinity to the task type. If the present server does not have an affinity to the task type, the task manager 128 determines whether another server 106 in the cluster has an affinity to the task type by accessing the shared memory 140 and determining from the node affinities 146 whether another node has acquired an affinity to the task type. If another server 106 has already acquired an affinity to the task type, the task manager 128 will release the task request on a named queue 132 such that the task is delivered directly to the server with an affinity to the task type. However, if based on the node affinities 146, no other server 106 has an affinity to the task type, the current server accesses the affinity limit 142 on the shared memory 140 in order to determine if the current server may accept any additional affinities. If no other server 106 has an affinity to the present task type and the current server is able to acquire additional affinities, the current server accepts the task request, updates the node affinities 146 in the shared memory 140 and proceeds to generate a task toward the device 110. In embodiments where a server 106 includes one or more VMs 112, a task may be sent from a first VM 112 to a second VM 112 on a same server 106 in at least paragraph [0022] and However, if at step 214, it is determined that the affinity limit has not been reached by the current server, then the current server acquires the affinity and records the affinity in the memory of the server as well as on the shared memory in at least paragraph [0031]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the affinity information storage in the memory device taught by Sarrazin with the information handling system taught by Singh and Zed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “there is a need for a method and apparatus for affinity load balancing” (See at least Sarrazin [0005] and if “no other server 106 has an affinity to the task type, the current server accesses the affinity limit 142 on the shared memory 140 in order to determine if the current server may accept any additional affinities” (See at least Sarrazin [0003]).
29. With regard to claim 18, while Singh and Zed teach the method of claim 11 and a memory device (Any of the computing devices can be implemented with various components, such as one or more processors and memory devices, as well as with any combination of differing components. One example of a computing system that can represent various systems and/or devices including the computing device 102 is shown and described below in relation to FIG. 6 in at least paragraph [0019] of Singh), they do not explicitly teach that the affinity information is stored in the memory device.
However, in analogous art, Sarrazin teaches that the processor is further configured to store the affinity information to the memory device (The task manager 128 accesses the task affinities 126 in order to determine whether the current server (in the present example, server 106.sub.1) has an affinity to the task type. If the present server does not have an affinity to the task type, the task manager 128 determines whether another server 106 in the cluster has an affinity to the task type by accessing the shared memory 140 and determining from the node affinities 146 whether another node has acquired an affinity to the task type. If another server 106 has already acquired an affinity to the task type, the task manager 128 will release the task request on a named queue 132 such that the task is delivered directly to the server with an affinity to the task type. However, if based on the node affinities 146, no other server 106 has an affinity to the task type, the current server accesses the affinity limit 142 on the shared memory 140 in order to determine if the current server may accept any additional affinities. If no other server 106 has an affinity to the present task type and the current server is able to acquire additional affinities, the current server accepts the task request, updates the node affinities 146 in the shared memory 140 and proceeds to generate a task toward the device 110. In embodiments where a server 106 includes one or more VMs 112, a task may be sent from a first VM 112 to a second VM 112 on a same server 106 in at least paragraph [0022] and However, if at step 214, it is determined that the affinity limit has not been reached by the current server, then the current server acquires the affinity and records the affinity in the memory of the server as well as on the shared memory in at least paragraph [0031]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the affinity information storage in the memory device taught by Sarrazin with the method taught by Singh and Zed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “there is a need for a method and apparatus for affinity load balancing” (See at least Sarrazin [0005] and if “no other server 106 has an affinity to the task type, the current server accesses the affinity limit 142 on the shared memory 140 in order to determine if the current server may accept any additional affinities” (See at least Sarrazin [0022]).
30. Claims 9, 10, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over by Singh et al. Pub. No. US 2016/0092274 A1 (hereafter Singh) in view of ZEDLEWSKI et al. Pub No. 2012/0227042 A1 (hereafter Zed) as applied to claims 1-7 and 11-17 above, and further in view of Rivas Toledano et al. Pub. No. US 2024/0152373 A1 (hereafter Rivas).
31. With regard to claim 9, Singh and Zed teach the information handling system of claim 1.
Singh teaches that the scheduler is further configured to determine that the second thread is to be scheduled on the processor based on the first and second affinity information (Threads are allocated on a thread-by-thread basis among the subset of the heterogeneous cores and in accordance with the thread policies assigned to the individual threads (block 406). For example, the thread scheduler module 128 may perform scheduling using the thread policies associated with different threads under the constraints imposed by application of the power management policy. In particular, the thread scheduler module 128 is restricted to scheduling using the subset of the heterogeneous cores ascertained per block 404. The scheduling may therefore involve reconciling the core state data that indicates available cores with the thread policies which indicates core affinities for each thread to derive usable cores for each scheduling event. The set of usable cores reflects the intersection between availability indicated by the core state data and core affinities reflected by the thread policies. Thus, the thread policy assigned to a particular thread may be used to determine core affinities for the particular thread and the thread may be placed with one of the heterogeneous cores in accordance with the core affinities that are determined in at least paragraph [0049]);
an accelerator configured to provide second affinity information associated with accelerator (In one or more implementations, thread policies are used to generate compact representations that map permitted cores to threads, such as by using a bit map, data string, thread properties, mapping database, or other suitable data structure configured to indicate core affinities that may include indications of preferred cores, permitted cores, and/or restricted cores on a thread-by-thread basis in at least paragraph [0041]);
the scheduler is further configured to schedule threads on the accelerator based on the second affinity information (Threads are allocated on a thread-by-thread basis among the subset of the heterogeneous cores and in accordance with the thread policies assigned to the individual threads (block 406). For example, the thread scheduler module 128 may perform scheduling using the thread policies associated with different threads under the constraints imposed by application of the power management policy. In particular, the thread scheduler module 128 is restricted to scheduling using the subset of the heterogeneous cores ascertained per block 404. The scheduling may therefore involve reconciling the core state data that indicates available cores with the thread policies which indicates core affinities for each thread to derive usable cores for each scheduling event. The set of usable cores reflects the intersection between availability indicated by the core state data and core affinities reflected by the thread policies. Thus, the thread policy assigned to a particular thread may be used to determine core affinities for the particular thread and the thread may be placed with one of the heterogeneous cores in accordance with the core affinities that are determined in at least paragraph [0049]);
Singh teaches processors configured with first and second types, and a scheduling based on affinity information provided by the processor. While they also teach a power management policy which may be configurable by developers and/or users to shift the balance more towards performance or more towards efficient power usage as an alternative (See paragraph [0033] and [0038]), Sing doesn’t explicitly teach dynamic re-scheduling via indications for thread allocations by replacing the already available scheduling based on the core affinities.
However, in analogous art, Zed teaches that the information handling system is configured to provide a second indication to the scheduler to schedule a second thread on the accelerator (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
to schedule the second thread on the accelerator based on the second indication (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the dynamically configurable rescheduling taught by Zed with the information handling system taught by Singh. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
Further, while Singh and Zed teach the information handling system that has a processor configured to provide affinity information and scheduling based on the provided affinity information and further indications for the purpose of customizable scheduling (See Singh and Zed’s teachings above) they affinitize to processor core (performance or efficiency) or indicate processors/processor groups. Neither Singh nor Zed affinitize/indicate an accelerator. Although Singh’s performance cores could be interpreted as an accelerated version of the efficiency cores, these are different cores of the same processor as opposed to a separate accelerator.
However, in analogous art, Rivas teaches an accelerator configured to provide second affinity information associated with accelerator (Understand while shown at this high level in the embodiment of FIG. 1, many variations and alternatives are possible, and other implementations of SoC 100 can equally incorporate embodiments. For example, depending on market segment, an SoC can include, instead of a hybrid product having heterogeneous core types, only cores of a single type. Further, more or different accelerator types may be present. For example, in addition to or instead of GPUs, an SoC may include a direct streaming accelerator (DSA), field programmable gate array (FPGA) or other accelerator in at least paragraph [0023] Method 500 begins by receiving hardware feedback information regarding the heterogenous cores (block 510). As discussed above, the VM scheduler may receive this information from a hardware feedback interface. Thereafter, control passes to block 520 where the VM scheduler receives QoS information regarding the threads of a given VM application. Note that the ordering shown in FIG. 5 is for purposes of discussion, and receipt of hardware feedback information and QoS information may occur in a different order and/or at different time instances. in at least paragraph [0045], Examiner notes that the system considers at least a combination of hardware capability information along with the QoS information indications of the threads to determine the affinity between the threads and the accelerator);
the scheduler is further configured to schedule threads on the accelerator based on the second affinity information (Understand while shown at this high level in the embodiment of FIG. 1, many variations and alternatives are possible, and other implementations of SoC 100 can equally incorporate embodiments. For example depending on market segment, an SoC can include, instead of a hybrid product having heterogeneous core types, only cores of a single type. Further, more or different accelerator types may be present. For example, in addition to or instead of GPUs, an SoC may include a direct streaming accelerator (DSA), field programmable gate array (FPGA) or other accelerator in at least paragraph [0023] and in any event, control passes next to block 530 where threads may be scheduled to virtual processors based at least in part on hardware feedback information and the QoS information. In this way, the VM scheduler that is aware of the heterogenous and dynamic capabilities of the cores may make appropriate scheduling decisions, such as to schedule high priority threads on the most performant cores. At block 540, the VM scheduler may send scheduling information regarding the virtual processors to a root partition, and more specifically to a root scheduler of the root partition. Note that this scheduling information may be in the form of identification of a given thread and a particular vCPU and vCPU type to which that thread is to be assigned. Although shown at this high level in the embodiment of FIG. 5, many variations and alternatives are possible in at least paragraph [0046]);
the information handling system is configured to provide a second indication to the scheduler to schedule a second thread on the accelerator (Understand while shown at this high level in the embodiment of FIG. 1, many variations and alternatives are possible, and other implementations of SoC 100 can equally incorporate embodiments. For example depending on market segment, an SoC can include, instead of a hybrid product having heterogeneous core types, only cores of a single type. Further, more or different accelerator types may be present. For example, in addition to or instead of GPUs, an SoC may include a direct streaming accelerator (DSA), field programmable gate array (FPGA) or other accelerator in at least paragraph [0023], as illustrated in FIG. 3, root kernel 310 includes a root scheduler 315. In various embodiments, root scheduler 315 may be an OS scheduler that is configured to schedule threads of a given application for execution on underlying hardware of a processor, e.g., particular cores, of heterogeneous types. Root scheduler 315 may receive QoS information 325 from root application 320 and schedule individual threads based at least in part on the QoS information. For example, root application 320 may identify within QoS information 325 priority associated with given threads (e.g., of a low, medium, or high priority, although more or fewer delineations are possible) in at least paragraph [0031], and in contrast without an embodiment, a virtual machine scheduler does not receive any hardware feedback information and schedules threads to a homogenous set of virtual CPUs. Because of this, the virtual machine scheduler experiences an open feedback loop, as it recognizes thread QoS, but does not have available to it information to make intelligent scheduling decisions. As such without an embodiment, the virtual machine scheduler can schedule threads of important QoS followed by threads of unimportant QoS on any given vCPU, in turn resulting in threads of important QoS being scheduled to non-performant cores and threads of unimportant QoS being scheduled to performant cores in at least paragraph [0038], Examiner notes that Rivas here teaches a system with an accelerator and a scheduler that can take indications (QoS information) and schedule threads on the accelerator based on the provided QoS information indications independent of and without considering the thread-hardware affinities as an alternative);
to schedule the second thread on the accelerator based on the second indication (Understand while shown at this high level in the embodiment of FIG. 1, many variations and alternatives are possible, and other implementations of SoC 100 can equally incorporate embodiments. For example depending on market segment, an SoC can include, instead of a hybrid product having heterogeneous core types, only cores of a single type. Further, more or different accelerator types may be present. For example, in addition to or instead of GPUs, an SoC may include a direct streaming accelerator (DSA), field programmable gate array (FPGA) or other accelerator in at least paragraph [0023], as illustrated in FIG. 3, root kernel 310 includes a root scheduler 315. In various embodiments, root scheduler 315 may be an OS scheduler that is configured to schedule threads of a given application for execution on underlying hardware of a processor, e.g., particular cores, of heterogeneous types. Root scheduler 315 may receive QoS information 325 from root application 320 and schedule individual threads based at least in part on the QoS information. For example, root application 320 may identify within QoS information 325 priority associated with given threads (e.g., of a low, medium, or high priority, although more or fewer delineations are possible) in at least paragraph [0031], and in contrast without an embodiment, a virtual machine scheduler does not receive any hardware feedback information and schedules threads to a homogenous set of virtual CPUs. Because of this, the virtual machine scheduler experiences an open feedback loop, as it recognizes thread QoS, but does not have available to it information to make intelligent scheduling decisions. As such without an embodiment, the virtual machine scheduler can schedule threads of important QoS followed by threads of unimportant QoS on any given vCPU, in turn resulting in threads of important QoS being scheduled to non-performant cores and threads of unimportant QoS being scheduled to performant cores in at least paragraph [0038]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the accelerator option in the processing hardware of the information handling system taught by Rivas as an additional option within the processing hardware that performs customizable affinity/indication based scheduling of the information handling system taught by Singh and Zed . A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, such that “the operating system can make efficient use of the hybrid architecture” (See at least Rivas [0002]).
32. With regard to claim 10, while Singh and Zed teach the information handling system of claim 1, they do not teach that the processor implements Intel Hardware Guided scheduling.
However, in analogous art, Rivas teaches providing the first affinity information, the processor is configured to implement an Intel Enhanced Hardware Guided Scheduling (Two technologies enable efficient use of this hybrid architecture. The first is a metric, Quality of Service (QoS) (handled by an operating system), that denotes the importance of any given thread. The second is Hardware Guided Scheduling (HGS), which allows the processor to provide hints to the operating system. These hints include the dynamic performance and energy efficiency capabilities of the P-cores and E-cores based on power/thermal limits and core parking and idling hints in at least paragraph [0002] and Root scheduler 315 further bases its scheduling decisions on hardware feedback information 354R. As illustrated, this hardware feedback information may be received from a hardware feedback interface (HFI) 350. In one embodiment, HFI 350 may be implemented as an Intel® Thread Director hardware resource, which maintains and provides hardware feedback information, e.g., in the form of performance and/or efficiency information of the various cores of the processor in at least paragraph [0032]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the implementation of the Intel Hardware Guided Scheduling taught by Rivas with the information handling system taught by Singh. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, such that “the operating system can make efficient use of the hybrid architecture” (See at least Rivas [0002]).
33. With regard to claim 19, Singh and Zed teach the method of claim 11. Singh teaches determining, by the scheduler, that the second thread is to be scheduled on the processor based on the first and second affinity information (Threads are allocated on a thread-by-thread basis among the subset of the heterogeneous cores and in accordance with the thread policies assigned to the individual threads (block 406). For example, the thread scheduler module 128 may perform scheduling using the thread policies associated with different threads under the constraints imposed by application of the power management policy. In particular, the thread scheduler module 128 is restricted to scheduling using the subset of the heterogeneous cores ascertained per block 404. The scheduling may therefore involve reconciling the core state data that indicates available cores with the thread policies which indicates core affinities for each thread to derive usable cores for each scheduling event. The set of usable cores reflects the intersection between availability indicated by the core state data and core affinities reflected by the thread policies. Thus, the thread policy assigned to a particular thread may be used to determine core affinities for the particular thread and the thread may be placed with one of the heterogeneous cores in accordance with the core affinities that are determined in at least paragraph [0049]);
an accelerator configured to provide second affinity information associated with accelerator (In one or more implementations, thread policies are used to generate compact representations that map permitted cores to threads, such as by using a bit map, data string, thread properties, mapping database, or other suitable data structure configured to indicate core affinities that may include indications of preferred cores, permitted cores, and/or restricted cores on a thread-by-thread basis in at least paragraph [0041]);
the scheduler is further configured to schedule threads on the accelerator based on the second affinity information (Threads are allocated on a thread-by-thread basis among the subset of the heterogeneous cores and in accordance with the thread policies assigned to the individual threads (block 406). For example, the thread scheduler module 128 may perform scheduling using the thread policies associated with different threads under the constraints imposed by application of the power management policy. In particular, the thread scheduler module 128 is restricted to scheduling using the subset of the heterogeneous cores ascertained per block 404. The scheduling may therefore involve reconciling the core state data that indicates available cores with the thread policies which indicates core affinities for each thread to derive usable cores for each scheduling event. The set of usable cores reflects the intersection between availability indicated by the core state data and core affinities reflected by the thread policies. Thus, the thread policy assigned to a particular thread may be used to determine core affinities for the particular thread and the thread may be placed with one of the heterogeneous cores in accordance with the core affinities that are determined in at least paragraph [0049]);
Singh teaches processors configured with first and second types, and a scheduling based on affinity information provided by the processor. While they also teach a power management policy which may be configurable by developers and/or users to shift the balance more towards performance or more towards efficient power usage as an alternative (See paragraph [0033] and [0038]), they don’t explicitly teach dynamic re-scheduling via indications for thread allocations by replacing the already available scheduling based on the core affinities.
However, in analogous art, Zed teaches that providing a second indication to the scheduler to schedule a second thread on the accelerator (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
scheduling, by the scheduler, the second thread on the accelerator based on the second indication (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the dynamically configurable rescheduling taught by Zed with the information handling system taught by Singh. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
Further, while Singh and Zed teach the information handling system that has a processor configured to provide affinity information and scheduling based on the provided affinity information and further indications for the purpose of customizable scheduling (See Singh and Zed’s teachings above) they affinitize to processor core (performance or efficiency) or indicate processors/processor groups. Neither Singh nor Zed affinitize/indicate an accelerator. Although Singh’s performance cores could be interpreted as an accelerated version of the efficiency cores, these are different cores of the same processor as opposed to a separate accelerator.
However, in analogous art, Rivas teaches an accelerator configured to provide second affinity information associated with accelerator (Understand while shown at this high level in the embodiment of FIG. 1, many variations and alternatives are possible, and other implementations of SoC 100 can equally incorporate embodiments. For example depending on market segment, an SoC can include, instead of a hybrid product having heterogeneous core types, only cores of a single type. Further, more or different accelerator types may be present. For example, in addition to or instead of GPUs, an SoC may include a direct streaming accelerator (DSA), field programmable gate array (FPGA) or other accelerator in at least paragraph [0023] Method 500 begins by receiving hardware feedback information regarding the heterogenous cores (block 510). As discussed above, the VM scheduler may receive this information from a hardware feedback interface. Thereafter, control passes to block 520 where the VM scheduler receives QoS information regarding the threads of a given VM application. Note that the ordering shown in FIG. 5 is for purposes of discussion, and receipt of hardware feedback information and QoS information may occur in a different order and/or at different time instances. in at least paragraph [0045], Examiner notes that the system considers at least a combination of hardware capability information along with the QoS information indications of the threads to determine the affinity between the threads and the accelerator);
the scheduler is further configured to schedule threads on the accelerator based on the second affinity information (Understand while shown at this high level in the embodiment of FIG. 1, many variations and alternatives are possible, and other implementations of SoC 100 can equally incorporate embodiments. For example depending on market segment, an SoC can include, instead of a hybrid product having heterogeneous core types, only cores of a single type. Further, more or different accelerator types may be present. For example, in addition to or instead of GPUs, an SoC may include a direct streaming accelerator (DSA), field programmable gate array (FPGA) or other accelerator in at least paragraph [0023] and in any event, control passes next to block 530 where threads may be scheduled to virtual processors based at least in part on hardware feedback information and the QoS information. In this way, the VM scheduler that is aware of the heterogenous and dynamic capabilities of the cores may make appropriate scheduling decisions, such as to schedule high priority threads on the most performant cores. At block 540, the VM scheduler may send scheduling information regarding the virtual processors to a root partition, and more specifically to a root scheduler of the root partition. Note that this scheduling information may be in the form of identification of a given thread and a particular vCPU and vCPU type to which that thread is to be assigned. Although shown at this high level in the embodiment of FIG. 5, many variations and alternatives are possible in at least paragraph [0046]);
providing a second indication to the scheduler to schedule a second thread on the accelerator (Understand while shown at this high level in the embodiment of FIG. 1, many variations and alternatives are possible, and other implementations of SoC 100 can equally incorporate embodiments. For example depending on market segment, an SoC can include, instead of a hybrid product having heterogeneous core types, only cores of a single type. Further, more or different accelerator types may be present. For example, in addition to or instead of GPUs, an SoC may include a direct streaming accelerator (DSA), field programmable gate array (FPGA) or other accelerator in at least paragraph [0023], as illustrated in FIG. 3, root kernel 310 includes a root scheduler 315. In various embodiments, root scheduler 315 may be an OS scheduler that is configured to schedule threads of a given application for execution on underlying hardware of a processor, e.g., particular cores, of heterogeneous types. Root scheduler 315 may receive QoS information 325 from root application 320 and schedule individual threads based at least in part on the QoS information. For example, root application 320 may identify within QoS information 325 priority associated with given threads (e.g., of a low, medium, or high priority, although more or fewer delineations are possible) in at least paragraph [0031], and in contrast without an embodiment, a virtual machine scheduler does not receive any hardware feedback information and schedules threads to a homogenous set of virtual CPUs. Because of this, the virtual machine scheduler experiences an open feedback loop, as it recognizes thread QoS, but does not have available to it information to make intelligent scheduling decisions. As such without an embodiment, the virtual machine scheduler can schedule threads of important QoS followed by threads of unimportant QoS on any given vCPU, in turn resulting in threads of important QoS being scheduled to non-performant cores and threads of unimportant QoS being scheduled to performant cores in at least paragraph [0038], Examiner notes that Rivas here teaches a system with an accelerator and a scheduler that can take indications and schedule threads on the accelerator based on the provided QoS information indications independent of and without considering the thread-hardware affinities);
scheduling, by the scheduler, the second thread on the accelerator based on the second indication (Understand while shown at this high level in the embodiment of FIG. 1, many variations and alternatives are possible, and other implementations of SoC 100 can equally incorporate embodiments. For example depending on market segment, an SoC can include, instead of a hybrid product having heterogeneous core types, only cores of a single type. Further, more or different accelerator types may be present. For example, in addition to or instead of GPUs, an SoC may include a direct streaming accelerator (DSA), field programmable gate array (FPGA) or other accelerator in at least paragraph [0023], as illustrated in FIG. 3, root kernel 310 includes a root scheduler 315. In various embodiments, root scheduler 315 may be an OS scheduler that is configured to schedule threads of a given application for execution on underlying hardware of a processor, e.g., particular cores, of heterogeneous types. Root scheduler 315 may receive QoS information 325 from root application 320 and schedule individual threads based at least in part on the QoS information. For example, root application 320 may identify within QoS information 325 priority associated with given threads (e.g., of a low, medium, or high priority, although more or fewer delineations are possible) in at least paragraph [0031], and in contrast without an embodiment, a virtual machine scheduler does not receive any hardware feedback information and schedules threads to a homogenous set of virtual CPUs. Because of this, the virtual machine scheduler experiences an open feedback loop, as it recognizes thread QoS, but does not have available to it information to make intelligent scheduling decisions. As such without an embodiment, the virtual machine scheduler can schedule threads of important QoS followed by threads of unimportant QoS on any given vCPU, in turn resulting in threads of important QoS being scheduled to non-performant cores and threads of unimportant QoS being scheduled to performant cores in at least paragraph [0038]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the accelerator option in the processing hardware of the information handling system taught by Rivas as an additional option within the processing hardware that performs customizable affinity/indication based scheduling of the information handling system taught by Singh and Zed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, such that “the operating system can make efficient use of the hybrid architecture” (See at least Rivas [0002]).
34. With regard to claim 20, Singh teaches an information handling system, comprising: a processor having a plurality of performance cores and a plurality of efficiency cores (FIG. 2 depicts generally at 200 example details of a computing device 102 having heterogeneous cores in accordance with one or more implementations. By way of example and not limitation, the processing system 104 is depicted as having performance oriented cores 202 and power efficient cores 204. The performance oriented cores 202 are representative of cores designed for high performance and the power efficient cores 204 are representative of cores designed to consume low power in at least paragraph [0029]);
the processor configured to provide first affinity information associated with the first cores and the second cores (In one or more implementations, thread policies are used to generate compact representations that map permitted cores to threads, such as by using a bit map, data string, thread properties, mapping database, or other suitable data structure configured to indicate core affinities that may include indications of preferred cores, permitted cores, and/or restricted cores on a thread-by-thread basis in at least paragraph [0041]);
a scheduler configured to schedule threads on the performance cores and the efficiency cores based on the affinity information (For example, a thread scheduler module 128 may operate to establish, maintain, and assign thread policies to threads as part of high frequency (e.g., thread-by-thread) placement decisions described throughout this document. The thread policies 210 may be configured in various ways to specify combinations of heterogeneous cores, one or more different types of cores, and/or particular individual cores on which a corresponding thread is permitted to run. In one or more implementations, thread policies are used to generate compact representations that map permitted cores to threads, such as by using a bit map, data string, thread properties, mapping database, or other suitable data structure configured to indicate core affinities that may include indications of preferred cores, permitted cores, and/or restricted cores on a thread-by-thread basis in at least paragraph [0041]);
the scheduler is further configured to determine that the thread is to be scheduled on the efficiency cores based on the affinity information (Threads are allocated on a thread-by-thread basis among the subset of the heterogeneous cores and in accordance with the thread policies assigned to the individual threads (block 406). For example, the thread scheduler module 128 may perform scheduling using the thread policies associated with different threads under the constraints imposed by application of the power management policy. In particular, the thread scheduler module 128 is restricted to scheduling using the subset of the heterogeneous cores ascertained per block 404. The scheduling may therefore involve reconciling the core state data that indicates available cores with the thread policies which indicates core affinities for each thread to derive usable cores for each scheduling event. The set of usable cores reflects the intersection between availability indicated by the core state data and core affinities reflected by the thread policies. Thus, the thread policy assigned to a particular thread may be used to determine core affinities for the particular thread and the thread may be placed with one of the heterogeneous cores in accordance with the core affinities that are determined in at least paragraph [0049]);
Singh teaches processors configured with performance and efficiency cores, and a scheduling based on affinity information provided by the processor. While they also teach a power management policy which may be configurable by developers and/or users to shift the balance more towards performance or more towards efficient power usage as an alternative (See paragraph [0033] and [0038]), they don’t explicitly teach dynamic re-scheduling via indications for thread allocations by replacing the already available scheduling based on the core affinities.
However, in analogous art, Zed teaches the information handling system is configured to provide an indication to the scheduler to schedule a thread on the performance cores (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]);
to schedule the thread on the performance cores based on the indication (Rescheduling may be triggered according to rules programmed into the schedule, according to user-input parameters, or both, or disabled altogether. For example, the scheduler may input at least one user-specified thread performance requirement and then estimating run-time thread execution performance relative to the performance requirement as a function of an observable condition (for example, performance counters). One measure of anti-cooperative execution behavior will then be violation of the user-specified thread performance requirement in at least paragraph [0033] and according to another optional aspect of the invention, the scheduler may input user designation of the first thread as being un-coschedulable with the second thread, in which such user designation is the rescheduling condition. Alternatively, it could input at least one user-provided execution guarantee for a designated one of the threads, in which the rescheduling condition is violation of the guarantee; upon violation of the guarantee, the scheduler then reschedules at least one of the coscheduled threads to ensure that the guarantee is met for the designated thread in at least paragraph [0034]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the dynamically configurable rescheduling taught by Zed with the information handling system taught by Singh. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, because “users often want to use more than one of these software applications, perhaps concurrently” (See at least Zed [0006]) and this combination enables them to do so.
While Singh and Zed teach the information handling system with performance and power efficient cores with its configurations, they do not teach using Intel Hardware Guided Scheduling.
However, in analogous art Rivas teaches the processor configured to provide affinity information associated with the performance cores and the efficiency cores based on an Intel Enhanced Hardware Guided Scheduling (Two technologies enable efficient use of this hybrid architecture. The first is a metric, Quality of Service (QoS) (handled by an operating system), that denotes the importance of any given thread. The second is Hardware Guided Scheduling (HGS), which allows the processor to provide hints to the operating system. These hints include the dynamic performance and energy efficiency capabilities of the P-cores and E-cores based on power/thermal limits and core parking and idling hints in at least paragraph [0002] and Root scheduler 315 further bases its scheduling decisions on hardware feedback information 354R. As illustrated, this hardware feedback information may be received from a hardware feedback interface (HFI) 350. In one embodiment, HFI 350 may be implemented as an Intel® Thread Director hardware resource, which maintains and provides hardware feedback information, e.g., in the form of performance and/or efficiency information of the various cores of the processor in at least paragraph [0032]).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the implementation of the Intel Hardware Guided Scheduling taught by Rivas with the information handling system taught by Singh and Zed. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, such that “the operating system can make efficient use of the hybrid architecture” (See at least Rivas [0002]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIDHARTH R EAGE whose telephone number is (571)272-9858. The examiner can normally be reached Monday-Friday 9:30am-6:30pm.
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, Bradley Teets can be reached at (571)272-3338. 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.
/S.E./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights