DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed 06/24/2024.
Claims 1-20 are pending.
Claim Rejections - 35 USC § 112
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.
Claims 1-20 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.
Claims 1, 8 and 15 recite: “perform/performing an application programming interface (API)” which is unclear as an “API” consists of calls that that may be performed however an API itself cannot be performed.
For the purposed of compact prosecution, Examiner will interpret “perform/performing an application programming interface (API)” to mean “perform/performing an application programming interface (API) call”.
Claims 4, 11 and 18 recites the limitation "the thread identification”. There is insufficient antecedent basis for this limitation in the claim.
For the purposes of compact prosecution, Examiner will interpret “the thread identification” in Claims 4, 11 and 18 as referring to “a thread identification” declared in Claims 3, 10 and 17 in each respective Claim set.
Claims 6, 13 and 19 recites the limitation "the one or more threads”. There is insufficient antecedent basis for this limitation in the claim.
For the purposes of compact prosecution, Examiner will interpret “the one or more threads” in Claims 6, 13 and 19 as referring to “one or more software threads” declared in independent Claims 1, 7 and 15.
Claims 2-3, 5, 7, 9-10, 12, 14, 16-17, and 20 are further rejected based on their dependency to the aforementioned rejected claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 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-14 are directed to a system and falls within the statutory category of machines; Claims 15-20 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:
Claims 1, 8 and 15: The limitations of “indicate one or more software threads that have been prevented from being performed by one or more processors”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, but for the recitation of generic computing components being used as a tool to perform the functionality, a person can observe when a task is being prevented.
Therefore, yes, Claims 1, 8 and 15 recite 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, 8 and 15: The judicial exceptions are not integrated into practical applications. In particular, the claims recite the following additional elements – “[one or more circuits] to perform an application programming interface (API)” is a recitation of generic computing components and functions merely being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)).
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, 8 and 15 not only recite a judicial exception but that the claims are directed to a judicial exception as a judicial exception has not been integrated into a practical application.
Step 2B:
Claims 1, 8 and 15: 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.
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, 8 and 15 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 2, 9 and 16: “the one or more software threads were previously scheduled to be performed by the one or more processors”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, but for the recitation of generic computing components being used as a tool to perform the functionality, a person can mentally determine a schedule for a plurality of tasks. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 2, 9 and 16 fail both prongs of Step 2A, 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 2, 9 and 16 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 3, 10, and 17: “an input to the API indicates a thread identification of the one or more software threads that have been prevented from being performed by the one or more processors”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, but for the recitation of generic computing components being used as a tool to perform the functionality, a person can observe when a task is being prevented. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 3, 10, and 17 fail both prongs of Step 2A, 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, 10, and 17 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 4, 11 and 18: “the thread identification for the one or more software threads indicated to be prevented from being performed indicate one or more coordinates of a portion of the one or more software threads” , as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, but for the recitation of generic computing components being used as a tool to perform the functionality, a person can observe which portions of a task is being prevented. With regard to integration into practical application and whether additional elements amount to significantly more, Claims 4, 11 and 18 fail both prongs of Step 2A, 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, 11 and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 5 and 12: “performing the API is to indicate one or more thread identifiers of threads indicated to have been prevented from being performed by the one or more processors”, is a recitation of generic computing components and functions merely being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)). With regard to integration into practical application and whether additional elements amount to significantly more, Claims 4, 11 and 18 fail both prongs of Step 2A, 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 12 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 6, 13 and 19: “performing the API is to cause a thread identifier of the one or more threads prevented from being performed by one or more processors to be indicated”, is a recitation of generic computing components and functions merely being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)). With regard to integration into practical application and whether additional elements amount to significantly more, Claims 6, 13 and 19 fail both prongs of Step 2A, 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, 13 and 19 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Claims 7, 14 and 20: “the one or more software threads prevented from being performed by the one or more processors are to be performed by indicated one or more other processors”, is a recitation of generic computing components and functions merely being used as a tool to apply the abstract idea (see MPEP § 2106.05(f)). With regard to integration into practical application and whether additional elements amount to significantly more, Claims 7, 14 and 20 fail both prongs of Step 2A, 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, 14 and 20 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 5, 6, 7, 8, 12, 13, 14, 15, 19 and 20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1, 6, 6, 5, 8, 13, 13, 12, 15, 17, and 12 of copending Application No. 18/752,685 (reference application) (hereinafter ‘685). Although the claims at issue are not identical, they are not patentably distinct from each other, further details below.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims in 18/752,694
Instant Application 18/752,694
Claims in 18/752,685
Copending Application 18/752,685
1,8, 15
one or more circuits to perform an application programming interface (API) to indicate one or more software threads that have been prevented from being performed by one or more processors.
1,8, 15
one or more circuits to perform an application programming interface (API) to cause one or more software threads identified by the API to be prevented from being performed by one or more processors.
5, 6, 12, 13, 19
performing the API is to indicate one or more thread identifiers of threads indicated to have been prevented from being performed by the one or more processors
[…]
performing the API is to cause a thread identifier of the one or more threads prevented from being performed by one or more processors to be indicated.
6, 13, 17
performance of the API is to cause generation of an identifier of threads indicated to be prevented from being performed by the one or more processors if the one or more threads indicated to be prevented from being performed exist.
7, 14, 20
the one or more software threads prevented from being performed by the one or more processors are to be performed by indicated one or more other processors.
5, 12
the API is to cause the one or more software threads to be performed by one or more other processors.
Regarding Claims 1, 8 and 15, the Claims 1, 8 and 15 recited in ‘685 are functionally equivalent to those in the instant application performing the same function of identifying prevented threads. They differ only in the time in which the identification occurs where in the instant application, threads are identified after prevention whereas in ‘685 they are identified before the actual act of prevention. Nevertheless, the function of identifying prevented threads are performed by both claims sets and therefore Claims 1, 8 and 15 of instant application 18/752,694 are not patentably distinct from Claims 1, 8 and 15 in ‘685.
Regarding Claims 5, 6, 12, 13 and 19, the Claims 6, 13 and 17 recited in ‘685 are functionally equivalent to those in the instant application performing the same function of identifying prevented threads. They differ only in the time in which the identification occurs where in the instant application, threads are identified after prevention whereas in ‘685 they are identified before the actual act of prevention. Nevertheless, the function of identifying prevented threads are performed by both claims sets and therefore Claims 5, 6, 12, 13 and 19 of instant application 18/752,694 are not patentably distinct Claims 6, 13 and 17 in ‘685.
Regarding Claims 7, 14 and 20 the Claims 5 and 12 recited in ‘685 are functionally equivalent to those in the instant application performing the same function of processing threads on other processors. They differ only in the which threads are being processed where in the instant application, prevented threads are being processed on other processors whereas in ‘685 threads are being processed on other processors. Nevertheless, the function of processing threads on other processors are performed by both claims sets and therefore Claims 7, 14 and 20 of instant application 18/752,694 are not patentably distinct Claims 5 and 12 in ‘685.
Claim 1, 2, 3, 7, 8, 9, 10, 14, 15, 16, 17 and 20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1, 5, 3, 6, 8, 12, 10, 13, 15, 19, 17 and 20 of copending Application No. 18/752,690 (reference application) (hereinafter ‘690). Although the claims at issue are not identical, they are not patentably distinct from each other, further details below.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims in 18/752,694
Instant Application 18/752,694
Claims in 18/752,690
Copending Application 18/752,690
1,8, 15
one or more circuits to perform an application programming interface (API) to indicate one or more software threads that have been prevented from being performed by one or more processors.
1,8, 15
one or more circuits to perform an application programming interface (API) to cause one or more processors to indicate whether one or more software threads have been prevented from being performed.
2, 9, 16
the one or more software threads were previously scheduled to be performed by the one or more processors.
5, 12, 19
the one or more software threads have been scheduled to be performed using the one or more processors.
3, 10, 17
an input to the API indicates a thread identification of the one or more software threads that have been prevented from being performed by the one or more processors.
3, 10, 17
input to the API indicates a thread identification of the one or more software threads.
7, 14, 20
the one or more software threads prevented from being performed by the one or more processors are to be performed by indicated one or more other processors.
6, 13, 20
performing the API is to cause the one or more software threads to be performed by one or more other processors.
Regarding Claims 1, 8 and 15, the Claims 1, 8 and 15 recited in ‘690 are functionally equivalent to those in the instant application performing the same function of identifying prevented threads. They differ only in what is doing the indication where in the instant application, threads are identified by the API whereas in ‘690 they are identified by the processors. Nevertheless, the function of identifying prevented threads are performed by both claims sets and therefore Claims 1, 8 and 15 of instant application 18/752,694 are not patentably distinct Claims 1, 8 and 15 in ‘690.
Regarding Claims 2, 9 and 16, the Claims 5, 12 and 19 recited in ‘690 are functionally equivalent to those in the instant application performing the same function of threads that have been scheduled. The function of scheduled threads are performed by both claims sets and therefore Claims 2, 9 and 16 of instant application 18/752,694 are not patentably distinct Claims 5, 12 and 19 in ‘690.
Regarding Claims 3, 10 and 17, the Claims 3, 10 and 17 recited in ‘690 are functionally equivalent to those in the instant application performing the same function of indicating thread identifications. They differ only in what kind of threads are being indicated where in the instant application, prevented threads identifications are indicated whereas in ‘690 threads identifications are indicated. Nevertheless, the function of indicating thread identifications are performed by both claims sets and therefore Claims 3, 10 and 17 of instant application 18/752,694 are not patentably distinct Claims 3, 10 and 17 in ‘690.
Regarding Claims 7, 14 and 20 the Claims 6, 13 and 20 recited in ‘690 are functionally equivalent to those in the instant application performing the same function of processing threads on other processors. They differ only in the which threads are being processed where in the instant application, prevented threads are being processed on other processors whereas in ‘690 threads are being processed on other processors. Nevertheless, the function of processing threads on other processors are performed by both claims sets and therefore Claims 7, 14 and 20 of instant application 18/752,694 are not patentably distinct Claims 6, 13 and 2 in ‘690.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 5-6, 8-10, 12-13, 15-17 and 19 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable over Sander et al. (US 20120179851 A1) (hereinafter Sander).
Regarding Claim 1, Sander teaches:
A processor comprising: one or more circuits to perform an application programming interface (API) to indicate one or more software threads that have been prevented from being performed by one or more processors.
“KMD 110 implements an application program interface (API) through which CPU 102, or applications executing on CPU 102 or other logic, can invoke APD 104 functionality”, (Sander: ¶65), “FIG. 2 is an illustrative flowchart of an initialization process of a CPU thread capable of processing a user-level interrupts ("ULI")”, (Sander: ¶19, Fig 2), “APD 104 can also include preemption and context switch logic 120 for preempting a process currently running within shader core 122”, (sander: ¶51), “APD 104 continues to process those tasks, APD 104 can issue a ULI when CPU 102 de-scheduled the CPU thread”, (Sander: ¶92), “FIG. 3, when CPU 102 determines that a ULI was issued for a de-scheduled CPU thread, CPU 102 proceeds to operation 316.”, (Sander: ¶94). Examiner notes: de-scheduling a thread is being interpreted as preventing the thread.
Regarding Claim 2, Sander teaches:
the one or more software threads were previously scheduled to be performed by the one or more processors.
“At operation 204, the CPU thread schedules tasks for APD 104. At operation 206, APD 104 begins to execute tasks scheduled in operation 204”, (Sander: ¶82), “the CPU thread executing at operation 208 may be periodically de-scheduled and rescheduled by CPU 102”, (Sander: ¶83), “For example, CPU 102 can schedule and de-schedule CPU threads depending on their priority, number of CPU cores, etc.”, (Sander: ¶91), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread”, (Sander: ¶95).
Regarding Claim 3, Sander teaches:
an input to the API indicates a thread identification of the one or more software threads that have been prevented from being performed by the one or more processors.
“Some graphics pipeline operations, such as pixel processing, and other parallel computation operations, can require that the same command stream or compute kernel be performed on streams or collections of input data elements”, (Sander: ¶37), “CPU 102 inputs commands based on applications 111 into appropriate command buffers 125. As referred to herein, an application is the combination of the program parts that will execute on the compute units within the CPU and APD”, (Sander: ¶44), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread. In an embodiment, the process identifier ("process ID") that spawned the CPU thread and CPU thread identifier ("thread ID") are also routed to KMD 110 with the ULI.”, (Sander: ¶95), “KMD 110 may cause CPU 102 to reinstate CPU thread more quickly when it receives a ULI for the particular CPU thread. For example, KMD 110 may increase the priority of the CPU thread, thus causing the CPU 102 to reinstate the CPU thread prior to other de-scheduled CPUThreads”, (Sander: ¶97).
Regarding Claim 5, Sander teaches:
performing the API is to indicate one or more thread identifiers of threads indicated to have been prevented from being performed by the one or more processors.
“Some graphics pipeline operations, such as pixel processing, and other parallel computation operations, can require that the same command stream or compute kernel be performed on streams or collections of input data elements”, (Sander: ¶37), “CPU 102 inputs commands based on applications 111 into appropriate command buffers 125. As referred to herein, an application is the combination of the program parts that will execute on the compute units within the CPU and APD”, (Sander: ¶44), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread. In an embodiment, the process identifier ("process ID") that spawned the CPU thread and CPU thread identifier ("thread ID") are also routed to KMD 110 with the ULI.”, (Sander: ¶95), “KMD 110 may cause CPU 102 to reinstate CPU thread more quickly when it receives a ULI for the particular CPU thread. For example, KMD 110 may increase the priority of the CPU thread, thus causing the CPU 102 to reinstate the CPU thread prior to other de-scheduled CPUThreads”, (Sander: ¶97).
Regarding Claim 6, Sander teaches:
performing the API is to cause a thread identifier of the one or more threads prevented from being performed by one or more processors to be indicated.
“Some graphics pipeline operations, such as pixel processing, and other parallel computation operations, can require that the same command stream or compute kernel be performed on streams or collections of input data elements”, (Sander: ¶37), “CPU 102 inputs commands based on applications 111 into appropriate command buffers 125. As referred to herein, an application is the combination of the program parts that will execute on the compute units within the CPU and APD”, (Sander: ¶44), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread. In an embodiment, the process identifier ("process ID") that spawned the CPU thread and CPU thread identifier ("thread ID") are also routed to KMD 110 with the ULI.”, (Sander: ¶95), “KMD 110 may cause CPU 102 to reinstate CPU thread more quickly when it receives a ULI for the particular CPU thread. For example, KMD 110 may increase the priority of the CPU thread, thus causing the CPU 102 to reinstate the CPU thread prior to other de-scheduled CPUThreads”, (Sander: ¶97).
Regarding Claim 8, Sander teaches:
A system comprising: one or more circuits to perform an application programming interface (API) to indicate one or more software threads that have been prevented from being performed by one or more processors.
“KMD 110 implements an application program interface (API) through which CPU 102, or applications executing on CPU 102 or other logic, can invoke APD 104 functionality”, (Sander: ¶65), “FIG. 2 is an illustrative flowchart of an initialization process of a CPU thread capable of processing a user-level interrupts ("ULI")”, (Sander: ¶19, Fig 2), “APD 104 can also include preemption and context switch logic 120 for preempting a process currently running within shader core 122”, (sander: ¶51), “APD 104 continues to process those tasks, APD 104 can issue a ULI when CPU 102 de-scheduled the CPU thread”, (Sander: ¶92), “FIG. 3, when CPU 102 determines that a ULI was issued for a de-scheduled CPU thread, CPU 102 proceeds to operation 316.”, (Sander: ¶94). Examiner notes: de-scheduling a thread is being interpreted as preventing the thread.
Regarding Claim 9, Sander teaches:
the one or more software threads were previously scheduled to be performed by the one or more processors.
“At operation 204, the CPU thread schedules tasks for APD 104. At operation 206, APD 104 begins to execute tasks scheduled in operation 204”, (Sander: ¶82), “the CPU thread executing at operation 208 may be periodically de-scheduled and rescheduled by CPU 102”, (Sander: ¶83), “For example, CPU 102 can schedule and de-schedule CPU threads depending on their priority, number of CPU cores, etc.”, (Sander: ¶91), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread”, (Sander: ¶95).
Regarding Claim 10, Sander teaches:
an input to the API indicates a thread identification of the one or more software threads that have been prevented from being performed by the one or more processors.
“Some graphics pipeline operations, such as pixel processing, and other parallel computation operations, can require that the same command stream or compute kernel be performed on streams or collections of input data elements”, (Sander: ¶37), “CPU 102 inputs commands based on applications 111 into appropriate command buffers 125. As referred to herein, an application is the combination of the program parts that will execute on the compute units within the CPU and APD”, (Sander: ¶44), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread. In an embodiment, the process identifier ("process ID") that spawned the CPU thread and CPU thread identifier ("thread ID") are also routed to KMD 110 with the ULI.”, (Sander: ¶95), “KMD 110 may cause CPU 102 to reinstate CPU thread more quickly when it receives a ULI for the particular CPU thread. For example, KMD 110 may increase the priority of the CPU thread, thus causing the CPU 102 to reinstate the CPU thread prior to other de-scheduled CPUThreads”, (Sander: ¶97).
Regarding Claim 12, Sander teaches:
performing the API is to indicate one or more thread identifiers of threads indicated to have been prevented from being performed by the one or more processors.
“Some graphics pipeline operations, such as pixel processing, and other parallel computation operations, can require that the same command stream or compute kernel be performed on streams or collections of input data elements”, (Sander: ¶37), “CPU 102 inputs commands based on applications 111 into appropriate command buffers 125. As referred to herein, an application is the combination of the program parts that will execute on the compute units within the CPU and APD”, (Sander: ¶44), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread. In an embodiment, the process identifier ("process ID") that spawned the CPU thread and CPU thread identifier ("thread ID") are also routed to KMD 110 with the ULI.”, (Sander: ¶95), “KMD 110 may cause CPU 102 to reinstate CPU thread more quickly when it receives a ULI for the particular CPU thread. For example, KMD 110 may increase the priority of the CPU thread, thus causing the CPU 102 to reinstate the CPU thread prior to other de-scheduled CPUThreads”, (Sander: ¶97).
Regarding Claim 13, Sander teaches:
performing the API is to cause a thread identifier of the one or more threads prevented from being performed by one or more processors to be indicated.
“Some graphics pipeline operations, such as pixel processing, and other parallel computation operations, can require that the same command stream or compute kernel be performed on streams or collections of input data elements”, (Sander: ¶37), “CPU 102 inputs commands based on applications 111 into appropriate command buffers 125. As referred to herein, an application is the combination of the program parts that will execute on the compute units within the CPU and APD”, (Sander: ¶44), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread. In an embodiment, the process identifier ("process ID") that spawned the CPU thread and CPU thread identifier ("thread ID") are also routed to KMD 110 with the ULI.”, (Sander: ¶95), “KMD 110 may cause CPU 102 to reinstate CPU thread more quickly when it receives a ULI for the particular CPU thread. For example, KMD 110 may increase the priority of the CPU thread, thus causing the CPU 102 to reinstate the CPU thread prior to other de-scheduled CPUThreads”, (Sander: ¶97).
Regarding Claim 15, Sander teaches:
A method comprising: performing an application programming interface (API) to indicate one or more software threads that have been prevented from being performed by one or more processors.
“KMD 110 implements an application program interface (API) through which CPU 102, or applications executing on CPU 102 or other logic, can invoke APD 104 functionality”, (Sander: ¶65), “FIG. 2 is an illustrative flowchart of an initialization process of a CPU thread capable of processing a user-level interrupts ("ULI")”, (Sander: ¶19, Fig 2), “APD 104 can also include preemption and context switch logic 120 for preempting a process currently running within shader core 122”, (sander: ¶51), “APD 104 continues to process those tasks, APD 104 can issue a ULI when CPU 102 de-scheduled the CPU thread”, (Sander: ¶92), “FIG. 3, when CPU 102 determines that a ULI was issued for a de-scheduled CPU thread, CPU 102 proceeds to operation 316.”, (Sander: ¶94). Examiner notes: de-scheduling a thread is being interpreted as preventing the thread.
Regarding Claim 16, Sander teaches:
the one or more software threads were previously scheduled to be performed by the one or more processors.
“At operation 204, the CPU thread schedules tasks for APD 104. At operation 206, APD 104 begins to execute tasks scheduled in operation 204”, (Sander: ¶82), “the CPU thread executing at operation 208 may be periodically de-scheduled and rescheduled by CPU 102”, (Sander: ¶83), “For example, CPU 102 can schedule and de-schedule CPU threads depending on their priority, number of CPU cores, etc.”, (Sander: ¶91), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread”, (Sander: ¶95).
Regarding Claim 17, Sander teaches:
an input to the API indicates a thread identification of the one or more software threads that have been prevented from being performed by the one or more processors.
“Some graphics pipeline operations, such as pixel processing, and other parallel computation operations, can require that the same command stream or compute kernel be performed on streams or collections of input data elements”, (Sander: ¶37), “CPU 102 inputs commands based on applications 111 into appropriate command buffers 125. As referred to herein, an application is the combination of the program parts that will execute on the compute units within the CPU and APD”, (Sander: ¶44), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread. In an embodiment, the process identifier ("process ID") that spawned the CPU thread and CPU thread identifier ("thread ID") are also routed to KMD 110 with the ULI.”, (Sander: ¶95), “KMD 110 may cause CPU 102 to reinstate CPU thread more quickly when it receives a ULI for the particular CPU thread. For example, KMD 110 may increase the priority of the CPU thread, thus causing the CPU 102 to reinstate the CPU thread prior to other de-scheduled CPUThreads”, (Sander: ¶97).
Regarding Claim 19, Sander teaches:
performing the API is to cause a thread identifier of the one or more threads prevented from being performed by one or more processors to be indicated.
“Some graphics pipeline operations, such as pixel processing, and other parallel computation operations, can require that the same command stream or compute kernel be performed on streams or collections of input data elements”, (Sander: ¶37), “CPU 102 inputs commands based on applications 111 into appropriate command buffers 125. As referred to herein, an application is the combination of the program parts that will execute on the compute units within the CPU and APD”, (Sander: ¶44), “the ULI is routed to KMD 110 until the CPU 102 reschedules the corresponding CPU thread. In an embodiment, the process identifier ("process ID") that spawned the CPU thread and CPU thread identifier ("thread ID") are also routed to KMD 110 with the ULI.”, (Sander: ¶95), “KMD 110 may cause CPU 102 to reinstate CPU thread more quickly when it receives a ULI for the particular CPU thread. For example, KMD 110 may increase the priority of the CPU thread, thus causing the CPU 102 to reinstate the CPU thread prior to other de-scheduled CPUThreads”, (Sander: ¶97).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over Sander in view of Shah et al. (US 20130124838 A1) (hereinafter Shah).
Regarding Claim 4, Sander fails to teach:
the thread identification for the one or more software threads indicated to be prevented from being performed indicate one or more coordinates of a portion of the one or more software threads.
However, Shah teaches: “Each thread in the thread array is assigned a unique thread identifier ("thread ID") that is accessible to the thread during its execution. The thread ID, which can be defined as a one-dimensional or multi-dimensional numerical value controls various aspects of the thread's processing behavior. For instance, a thread ID may be used to determine which portion of the input data set a thread is to process and/or to determine which portion of an output data set a thread is to produce or write”, (Shah: ¶48), “The work distribution unit 340 associates each CTA with a specific grid or queue for concurrent execution of one or more tasks. CTAs that belong to a grid have implicit x,y,z parameters indicating the position of the respective CTA within the grid”, (Shah : ¶60), “Once the context is stopped (and any interrupts or faults are cleared), phase 2 saves the current context's state in memory. Phase 3 resets the engine before phase 4 loads a new context's state onto the machine. Phase 5 restarts the processing of any work that was preempted in a previous Phase 1”, (Shah: ¶54), “The SMs 310 indicate to the pipeline manager 305 whether each thread group exited or was preempted”, (Shah: ¶78), “Pipeline managers 305 restart all the CTAs that were preempted by sending the CTAs to the respective SM 310 which each CTA was executing on, in the order that the CTAs were reported preempted.”, (Shah: ¶72).
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 thread identification for the one or more software threads indicated to be prevented from being performed indicate one or more coordinates of a portion of the one or more software threads of Shah with the methods and systems of Sander resulting in a system being able to process threads starting at the point which where they were prevented. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Waiting for the graphics processing pipeline to idle significantly reduces the storage needed to capture the context state”, (Shah: ¶54), “the amount of context state is reduced when CTA level preemption is performed compared with instruction level preemption because instruction level preemption does not require draining the downstream processing units”, (Shah: ¶59).
Regarding Claim 11, Sander fails to teach:
the thread identification for the one or more software threads indicated to be prevented from being performed indicate one or more coordinates of a portion of the one or more software threads.
However, Shah teaches: “Each thread in the thread array is assigned a unique thread identifier ("thread ID") that is accessible to the thread during its execution. The thread ID, which can be defined as a one-dimensional or multi-dimensional numerical value controls various aspects of the thread's processing behavior. For instance, a thread ID may be used to determine which portion of the input data set a thread is to process and/or to determine which portion of an output data set a thread is to produce or write”, (Shah: ¶48), “The work distribution unit 340 associates each CTA with a specific grid or queue for concurrent execution of one or more tasks. CTAs that belong to a grid have implicit x,y,z parameters indicating the position of the respective CTA within the grid”, (Shah : ¶60), “Once the context is stopped (and any interrupts or faults are cleared), phase 2 saves the current context's state in memory. Phase 3 resets the engine before phase 4 loads a new context's state onto the machine. Phase 5 restarts the processing of any work that was preempted in a previous Phase 1”, (Shah: ¶54), “The SMs 310 indicate to the pipeline manager 305 whether each thread group exited or was preempted”, (Shah: ¶78), “Pipeline managers 305 restart all the CTAs that were preempted by sending the CTAs to the respective SM 310 which each CTA was executing on, in the order that the CTAs were reported preempted.”, (Shah: ¶72).
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 thread identification for the one or more software threads indicated to be prevented from being performed indicate one or more coordinates of a portion of the one or more software threads of Shah with the methods and systems of Sander resulting in a system being able to process threads starting at the point which where they were prevented. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Waiting for the graphics processing pipeline to idle significantly reduces the storage needed to capture the context state”, (Shah: ¶54), “the amount of context state is reduced when CTA level preemption is performed compared with instruction level preemption because instruction level preemption does not require draining the downstream processing units”, (Shah: ¶59).
Regarding Claim 18, Sander fails to teach:
the thread identification for the one or more software threads indicated to be prevented from being performed indicate one or more coordinates of a portion of the one or more software threads.
However, Shah teaches: “Each thread in the thread array is assigned a unique thread identifier ("thread ID") that is accessible to the thread during its execution. The thread ID, which can be defined as a one-dimensional or multi-dimensional numerical value controls various aspects of the thread's processing behavior. For instance, a thread ID may be used to determine which portion of the input data set a thread is to process and/or to determine which portion of an output data set a thread is to produce or write”, (Shah: ¶48), “The work distribution unit 340 associates each CTA with a specific grid or queue for concurrent execution of one or more tasks. CTAs that belong to a grid have implicit x,y,z parameters indicating the position of the respective CTA within the grid”, (Shah : ¶60), “Once the context is stopped (and any interrupts or faults are cleared), phase 2 saves the current context's state in memory. Phase 3 resets the engine before phase 4 loads a new context's state onto the machine. Phase 5 restarts the processing of any work that was preempted in a previous Phase 1”, (Shah: ¶54), “The SMs 310 indicate to the pipeline manager 305 whether each thread group exited or was preempted”, (Shah: ¶78), “Pipeline managers 305 restart all the CTAs that were preempted by sending the CTAs to the respective SM 310 which each CTA was executing on, in the order that the CTAs were reported preempted.”, (Shah: ¶72).
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 thread identification for the one or more software threads indicated to be prevented from being performed indicate one or more coordinates of a portion of the one or more software threads of Shah with the methods and systems of Sander resulting in a system being able to process threads starting at the point which where they were prevented. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Waiting for the graphics processing pipeline to idle significantly reduces the storage needed to capture the context state”, (Shah: ¶54), “the amount of context state is reduced when CTA level preemption is performed compared with instruction level preemption because instruction level preemption does not require draining the downstream processing units”, (Shah: ¶59).
Claims 7, 14 and 20 are rejected under 35 U.S.C. 103(a) as being unpatentable over Sander in view of Ahmad et al. (US 20140059548 A1) (hereinafter Ahmad).
Regarding Claim 7, Sander fails to teach:
the one or more software threads prevented from being performed by the one or more processors are to be performed by indicated one or more other processors.
However, Ahmad teaches: “The method begins with various processes (e.g., threads) executing on one or more cores of the multi-core cluster, at 305”, (Ahmad: ¶20), “execution of the saved context from the given core of the multi-core cluster is restarted on the core of the single-core cluster after re-mapping the one or more shared resources of the given core to the core of the single-core cluster”, (Ahmad: ¶22), “The workload may be migrated from any core (f-CPU0/1/2/3) of the multi-core cluster (f-cluster) to the core of the single core (s-cluster), without first having to transfer the processes to a predetermined core (f-CNA) of the multi-core cluster and then idling the other cores (f-CPU1/2/3). Furthermore the workload may be migrated from any core (f-CPU0/1/2/3) of the multi-core cluster (f-cluster) to the single core (s-cluster), without software virtualization (hypervisor) support which is characterized by substantial processing overhead”, (Ahmad: ¶18).
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 one or more software threads prevented from being performed by the one or more processors are to be performed by indicated one or more other processors of Ahmad with the methods and systems of Sander resulting in a system being able to migrate prevented threads. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Techniques, therefore, advantageously provide for migrating execution of processes (e.g., threads) that are execution on any single core of the multi-core cluster to the core of the single-core cluster and back again. The techniques advantageously do not utilize software virtualization to implement the migrations between the cores of the multi-core cluster and the core of the single-core cluster”, (Ahmad: ¶29).
Regarding Claim 14, Sander fails to teach:
the one or more software threads prevented from being performed by the one or more processors are to be performed by indicated one or more other processors.
However, Ahmad teaches: “The method begins with various processes (e.g., threads) executing on one or more cores of the multi-core cluster, at 305”, (Ahmad: ¶20), “execution of the saved context from the given core of the multi-core cluster is restarted on the core of the single-core cluster after re-mapping the one or more shared resources of the given core to the core of the single-core cluster”, (Ahmad: ¶22), “The workload may be migrated from any core (f-CPU0/1/2/3) of the multi-core cluster (f-cluster) to the core of the single core (s-cluster), without first having to transfer the processes to a predetermined core (f-CNA) of the multi-core cluster and then idling the other cores (f-CPU1/2/3). Furthermore the workload may be migrated from any core (f-CPU0/1/2/3) of the multi-core cluster (f-cluster) to the single core (s-cluster), without software virtualization (hypervisor) support which is characterized by substantial processing overhead”, (Ahmad: ¶18).
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 one or more software threads prevented from being performed by the one or more processors are to be performed by indicated one or more other processors of Ahmad with the methods and systems of Sander resulting in a system being able to migrate prevented threads. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Techniques, therefore, advantageously provide for migrating execution of processes (e.g., threads) that are execution on any single core of the multi-core cluster to the core of the single-core cluster and back again. The techniques advantageously do not utilize software virtualization to implement the migrations between the cores of the multi-core cluster and the core of the single-core cluster”, (Ahmad: ¶29).
Regarding Claim 20, Sander fails to teach:
the one or more software threads prevented from being performed by the one or more processors are to be performed by indicated one or more other processors.
However, Ahmad teaches: “The method begins with various processes (e.g., threads) executing on one or more cores of the multi-core cluster, at 305”, (Ahmad: ¶20), “execution of the saved context from the given core of the multi-core cluster is restarted on the core of the single-core cluster after re-mapping the one or more shared resources of the given core to the core of the single-core cluster”, (Ahmad: ¶22), “The workload may be migrated from any core (f-CPU0/1/2/3) of the multi-core cluster (f-cluster) to the core of the single core (s-cluster), without first having to transfer the processes to a predetermined core (f-CNA) of the multi-core cluster and then idling the other cores (f-CPU1/2/3). Furthermore the workload may be migrated from any core (f-CPU0/1/2/3) of the multi-core cluster (f-cluster) to the single core (s-cluster), without software virtualization (hypervisor) support which is characterized by substantial processing overhead”, (Ahmad: ¶18).
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 one or more software threads prevented from being performed by the one or more processors are to be performed by indicated one or more other processors of Ahmad with the methods and systems of Sander resulting in a system being able to migrate prevented threads. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of “Techniques, therefore, advantageously provide for migrating execution of processes (e.g., threads) that are execution on any single core of the multi-core cluster to the core of the single-core cluster and back again. The techniques advantageously do not utilize software virtualization to implement the migrations between the cores of the multi-core cluster and the core of the single-core cluster”, (Ahmad: ¶29).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIHAB ALAM whose telephone number is (571)272-8705. The examiner can normally be reached Mon - Fri 7:30am-5pm.
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.A./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights