DETAILED ACTION
Claims 1-20 are pending in this application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The disclosure is objected to because of the following informalities:
On paragraph 0001 of the specification includes a claim of priority.
An update or revision of the specification maybe required in the event that it is applicable.
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.
Step 1:
Claims 1-7, 8-14 and 15-20 are directed to a machine, and process or method and are therefore directed to statutory subject matter.
Step 2A:
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Applying Mayo/Alice Step 2A:
Claims 1, 8 and 15 are directed to an abstract idea. The claims recite “…perform(ing) 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”.
This limitation simply describe the concept of “…perform(ing) 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.” which could be performed in the human mind. Under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, it falls within the “Mental Processes” grouping of abstract ideas. The claims are abstract ideas that require no more than a generic computer element “one or more circuits”. In mental processes, a person could do this function mentally or with pen and paper. Accordingly, the claims recites an abstract idea as such the description of claims 1-20 are abstract idea.
Applying Mayo/Alice STEP 2B:
The claims 1-14 do not include additional or combination of elements that are sufficient to amount to significantly more than the judicial exception because the additional elements. The claims 1-14 recites the additional elements (“one or more circuits”) which are recited at a high level of generality and recited as performing generic computer functions routinely used in computer applications. Viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself.
A citation to one or more of the court decisions discussed in MPEP 2106.05(d)(ll) as noting the well-understood, routine, conventional nature of the additional elements.
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, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TU Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buy SAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245,1258, 113 USPQ2d 1097,1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result--a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); and
iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93.”
The use of generic computer functions for “perform(ing)” does not impose any meaningful limitation to the abstract idea because the recited computer is mere instructions to apply an exception (MEPEP 2106.05(f). Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of data analysis or computer networking or any other technology.
Noting that claim to a system and a non-transitory computer readable storage device are held ineligible for the same reason, e.g., the generically-recited computers add nothing of substance to the underlying abstract idea. Therefore, the independents 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter. See Alice Corporation Pty. Ltd. v. CLS Bank International, et al.
Dependent claims 2-7, 9-14, and 16-20 merely add further details of the abstract steps/elements recited in claims 1, 8, and 15 without including an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Therefore, they are also non-statutory subject matter.
For a detailed discussion of the eligibility analysis required to determine whether a claim is directed to patent-eligible subject matter, see MPEP § 2106 and the 2014 Interim Guidance on Patent Subject Matter Eligibility, 79 Fed. Reg. 74618 (December 16, 2014) and related materials available at:
https://www.federalregister.gov/documents/2024/07/17/2024-15377/2024-guidance-update-on-patent-subject-matter-eligibility-including-on-artificial-intelligence
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, 3. 8, 10 and 15 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3, 10 and 15 of copending Application No. 18/752,694 to Soman et al. Although the claims at issue are not identical, they are not patentably distinct from each other because all claim limitations of the instant application are present in the 18/752,694 application.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application No. 18/752,690
Claim 1:
A processor comprising:
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.
U.S. Application No. 18/752,694 Soman et al.
Claim 1:
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.
Claim 3:
The processor of claim 1, wherein an input to the API indicates a thread identification of the one or more software threads.
Claim 3:
The processor of claim 1, wherein 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.
Claim 8:
A system comprising: 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.
Claim 8:
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.
Claim 10 The system of claim 8, wherein an input to the API indicates a thread identification of the one or more software threads.
Claim 10:
The system of clauses 8 and/or 9, wherein an input to the API indicates a thread identification of the one or more software threads.
Claim 15:
A method comprising: performing 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.
Claim 15:
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.
Claims 1, 6. 8, 13 and 15 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 5, 8, 12 and 15 of copending Application No. 18/752,685 to Soman et al. Although the claims at issue are not identical, they are not patentably distinct from each other because all claim limitations of the instant application are present in the 18/752,694 application.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application No. 18/752,690
U.S. Application No. 18/752,685
Claim 1:
A processor comprising:
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.
Claim 1:
A processor comprising: 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.
Claim 6:
The processor of claim 1, wherein performing the API is to cause the one or more software threads to be performed by one or more other processors.
Claim 5:
The processor of claim 1, wherein performing the API is to cause the one or more software threads to be performed by one or more other processors.
Claim 8:
A system comprising: 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.
Claim 13:
The system of claim 8, wherein performing the API is to cause the one or more software threads to be performed by one or more other processors.
Claim 8:
A system comprising: one or more processors 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.
Claim 12:
The system of claim 8, wherein performing the API is to cause the one or more software threads to be performed by one or more other processors.
Claim 15:
A method comprising: performing 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.
Claim 15:
A computer-implemented method comprising: one or more processors 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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-8, 10-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S Pat. No. 10,127,076 B1 issued to Barroso et al. in view of U.S. Pat. No. 10,540,194 B2 issued to Koblents et al.
As to claim 1, Barroso teaches a processor comprising:
one or more circuits to perform a request (park request) to cause one or more processors to indicate whether one or more software threads have been prevented from being performed (“…The processor 102 receives a park request from the thread including a resume condition (304). In some implementations, the resume condition may include a resumption register that, when updated, will cause the thread to be resumed. The resumption condition may also include a conditional statement or instructions that, when true, will cause the thread to be resumed. In such a case, the processor 102 may periodically check for the occurrence of the resume condition…” Col. 8 Ln. 11-19).
Barroso is silent with reference to one or more circuits to perform an application programming interface (API) to call a processor for a software thread.
Koblents teaches one or more circuits to perform an application programming interface (API) to call a processor for a software thread (both CUDA and OpenCL can be utilized in embodiments of the present invention in order to place start and stop events in the kernel (222)) (“…The one or more programs launch the GPU kernel (220), in a manner that does not block a host by placing certain elements in the GPU kernel. The one or more programs place start and stop events in the kernel (222) and the one or more programs add a callback, to be called on the host after the kernel execution has completed (224)…Aspects of various existing computing platforms and frameworks can be utilized to implement certain aspects of embodiments of the present invention. As a non-limiting example, aspects of both CUDA and OpenCL can be utilized in embodiments of the present invention in order to place start and stop events in the kernel (222) and to add a callback (224)…In some embodiments of the present invention, the start and stop events may be CUDA and/or OpenCL start and stop events. The CUDA/OpenCL event API includes calls to create and destroy events, record events, and compute the elapsed time in milliseconds between two recorded events. The one or more programs of the runtime system utilize CUDA/OpenCL events in the aforementioned CUDA/OpenCL stream (i.e., a sequence of operations that are performed in order on a device) the one or more programs utilize to launch the GPU kernel to monitor the GPU performance. The one or more programs place the start and stop events immediately before and after the kernel launch in the CUDA/OpenCL stream…” Col. 5 Ln. 32-58).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Barroso with the teaching of Koblents because the teaching of Koblents would improve the system of Barroso by providing application programming interface (API) that allows software to use certain types of graphics processing units (GPUs) for accelerated general-purpose processing, significantly broadening their utility in scientific and high-performance computing.
As to claim 3, Koblents teaches the processor of claim 1, wherein an input to the API indicates a thread identification of the one or more software threads (enqueue kernel ID) (“…Executing a callback in the stream serves to enqueue kernel ID and the start/stop events into the GPU timing queue, from which the one or more programs can obtain the GPU elapsed time. Thus, inserting a callback ultimately enables the one or more programs to store the execution time and performance data, from executing the relevant version in profile mode in the GPU, as historical data in a storage (244; e.g., FIG. 1, 140). In an embodiment of the present invention, the one or more programs add the callback to the stream (224) using a cudaStreamAddCallback( ) instruction. The CUDA API does not enable callbacks to make CUDA API calls. However, the cudaStreamAddCallback( ) instruction enables the callback to enqueue execution time and performance data (e.g., kernel ID and the start/stop events), into the GPU timing queue, so a main program thread can obtain the GPU elapsed time using a cudaEventElapsedTime( ) command. In an embodiment of the present invention that utilizes aspects of OpenCL, the one or more programs add the callback to the stream (224) using a clSetEventCallback( ) instruction…Returning to FIG. 2, the one or more programs call the callback and the callback enqueues kernel ID, and the start and stop events to the GPU time queue (230). To minimize the profiling overhead the one or more programs of the runtime system do not communicate GPU results to the CPU…” Col. 5 Ln. 64-67, Col. 6 Ln. 1-22).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Barroso with the teaching of Koblents because the teaching of Koblents would improve the system of Barroso by providing application programming interface (API) that allows software to use certain types of graphics processing units (GPUs) for accelerated general-purpose processing, significantly broadening their utility in scientific and high-performance computing.
As to claim 4, Koblents teaches the processor of claim 1, wherein an input to the API indicates one or more memory locations in which to store an indication of whether the one or more software threads have been prevented from being performed (the cudaStreamAddCallback( ) instruction enables the callback to enqueue execution time and performance data (e.g., kernel ID and the start/stop events), into the GPU timing queue) (“…Executing a callback in the stream serves to enqueue kernel ID and the start/stop events into the GPU timing queue, from which the one or more programs can obtain the GPU elapsed time. Thus, inserting a callback ultimately enables the one or more programs to store the execution time and performance data, from executing the relevant version in profile mode in the GPU, as historical data in a storage (244; e.g., FIG. 1, 140). In an embodiment of the present invention, the one or more programs add the callback to the stream (224) using a cudaStreamAddCallback( ) instruction. The CUDA API does not enable callbacks to make CUDA API calls. However, the cudaStreamAddCallback( ) instruction enables the callback to enqueue execution time and performance data (e.g., kernel ID and the start/stop events), into the GPU timing queue, so a main program thread can obtain the GPU elapsed time using a cudaEventElapsedTime( ) command. In an embodiment of the present invention that utilizes aspects of OpenCL, the one or more programs add the callback to the stream (224) using a clSetEventCallback( ) instruction…Returning to FIG. 2, the one or more programs call the callback and the callback enqueues kernel ID, and the start and stop events to the GPU time queue (230). To minimize the profiling overhead the one or more programs of the runtime system do not communicate GPU results to the CPU…” Col. 5 Ln. 64-67, Col. 6 Ln. 1-22).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Barroso with the teaching of Koblents because the teaching of Koblents would improve the system of Barroso by providing application programming interface (API) that allows software to use certain types of graphics processing units (GPUs) for accelerated general-purpose processing, significantly broadening their utility in scientific and high-performance computing.
As to claim 5, Koblents teaches the processor of claim 1, wherein the one or more software threads have been scheduled to be performed using the one or more processors (“…One the one or more programs have selected a device, based on kernel, time, and size, the one or more programs schedule 440 execution of the operation…” Col. 7 Ln. 62-64).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Barroso with the teaching of Koblents because the teaching of Koblents would improve the system of Barroso by providing application programming interface (API) that allows software to use certain types of graphics processing units (GPUs) for accelerated general-purpose processing, significantly broadening their utility in scientific and high-performance computing.
As to claim 6, Koblents teaches the processor of claim 1, wherein performing the API is to cause the one or more software threads to be performed by one or more other processors (CUDA API) (“…Executing a callback in the stream serves to enqueue kernel ID and the start/stop events into the GPU timing queue, from which the one or more programs can obtain the GPU elapsed time. Thus, inserting a callback ultimately enables the one or more programs to store the execution time and performance data, from executing the relevant version in profile mode in the GPU, as historical data in a storage (244; e.g., FIG. 1, 140). In an embodiment of the present invention, the one or more programs add the callback to the stream (224) using a cudaStreamAddCallback( ) instruction. The CUDA API does not enable callbacks to make CUDA API calls. However, the cudaStreamAddCallback( ) instruction enables the callback to enqueue execution time and performance data (e.g., kernel ID and the start/stop events), into the GPU timing queue, so a main program thread can obtain the GPU elapsed time using a cudaEventElapsedTime( ) command. In an embodiment of the present invention that utilizes aspects of OpenCL, the one or more programs add the callback to the stream (224) using a clSetEventCallback( ) instruction…Returning to FIG. 2, the one or more programs call the callback and the callback enqueues kernel ID, and the start and stop events to the GPU time queue (230). To minimize the profiling overhead the one or more programs of the runtime system do not communicate GPU results to the CPU…” Col. 5 Ln. 64-67, Col. 6 Ln. 1-22).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Barroso with the teaching of Koblents because the teaching of Koblents would improve the system of Barroso by providing application programming interface (API) that allows software to use certain types of graphics processing units (GPUs) for accelerated general-purpose processing, significantly broadening their utility in scientific and high-performance computing.
As to claim 7, Koblents teaches the processor of claim 1, wherein performing the API is to cause an identifier of the one or more software threads to be indicated (enqueue kernel ID) (“…Executing a callback in the stream serves to enqueue kernel ID and the start/stop events into the GPU timing queue, from which the one or more programs can obtain the GPU elapsed time. Thus, inserting a callback ultimately enables the one or more programs to store the execution time and performance data, from executing the relevant version in profile mode in the GPU, as historical data in a storage (244; e.g., FIG. 1, 140). In an embodiment of the present invention, the one or more programs add the callback to the stream (224) using a cudaStreamAddCallback( ) instruction. The CUDA API does not enable callbacks to make CUDA API calls. However, the cudaStreamAddCallback( ) instruction enables the callback to enqueue execution time and performance data (e.g., kernel ID and the start/stop events), into the GPU timing queue, so a main program thread can obtain the GPU elapsed time using a cudaEventElapsedTime( ) command. In an embodiment of the present invention that utilizes aspects of OpenCL, the one or more programs add the callback to the stream (224) using a clSetEventCallback( ) instruction…Returning to FIG. 2, the one or more programs call the callback and the callback enqueues kernel ID, and the start and stop events to the GPU time queue (230). To minimize the profiling overhead the one or more programs of the runtime system do not communicate GPU results to the CPU…” Col. 5 Ln. 64-67, Col. 6 Ln. 1-22).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Barroso with the teaching of Koblents because the teaching of Koblents would improve the system of Barroso by providing application programming interface (API) that allows software to use certain types of graphics processing units (GPUs) for accelerated general-purpose processing, significantly broadening their utility in scientific and high-performance computing.
As to claims 8 and 15, see the rejection of claim 1 above.
As to claims 10 and 17, see the rejection of claim 3 above.
As to claims 11 and 18, see the rejection of claim 4 above.
As to claims 12 and 19, see the rejection of claim 5 above.
As to claims 13 and 20, see the rejection of claim 6 above.
As to claim 14, see the rejection of claim 7 above.
Claims 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over U.S Pat. No. 10,127,076 B1 issued to Barroso et al. in view of U.S. Pat. No. 10,540,194 B2 issued to Koblents et al. as applied to claims 1, 8 and 15 above, and further in view of U.S. Pub. No. 2020/0089528 A1 Gutierrez et al.
As to claim 2, Barroso as modified by Koblents teaches the processor of claim 1, however it is silent with reference to wherein the software threads identified by the API have not been indicated to be performed by one or more other processors.
Gutierrez teaches wherein the software threads identified by the API (CUDA dynamic parallelism or device enqueue on OpenCL or ROCm) have not been indicated to be performed by one or more other processors (Kernels are queued) (“…Kernels are queued for execution on a GPU from within a GPU kernel using techniques such as CUDA dynamic parallelism or device enqueue on OpenCL or ROCm. The tasks that are launched using these device-side techniques are represented as full kernels and therefore require the full kernel launch procedure that is performed by the CPU, as discussed herein. The performance of these device-side enqueue techniques is also limited by the requirement that information must be written to memory to initiate enqueueing of the task, which increases latency due to the logical and physical separation of the memory and the GPU…” paragraph 0013).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Barroso and Koblents with the teaching of Gutierrez because the teaching of Gutierrez would improve the system of Barroso and Koblents by providing dynamic parallelism enqueuing of tasks for execution on graphics processing unit.
As to claims 9 and 16, see the rejection of claim 2 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Pub. No. 2022/0334898 A1 to Vishnuswaroop and directed to application programming interface to identify memory.
U.S. Pub. No. 2018/0308209 A1 to Ramadoss et al. and directed to techniques enabling a compute unit to continue processing operations when all dispatched threads are blocked.
U.S. Pub. No. 2017/0329729 A1 to Chew and directed to a mechanism for facilitating callback interrupt handling for multi-threaded applications in computing environments.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
Prosecution Insights