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 Rejections - 35 USC § 103
2. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
3. 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.
4. Claims 1-6, 9-16, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Allen et al. (US 9030480 B2), hereinafter Allen, in view of Oreifej et al. (US 20180108166 A1), hereinafter Oreifej.
Regarding claim 1, Allen teaches a graphics processor comprising: a memory interface; and a graphics processing cluster coupled with the memory interface (Fig. 1, Col. 3 lines 26-64, wherein parallel processing subsystem consisting of a plurality of parallel processing units is coupled to a memory bridge, which is interpreted as a graphics processing cluster coupled with a memory interface), the graphics processing cluster including a plurality of processing resources (Fig. 2, Col. 4 line 66 – Col. 5 line 19, wherein parallel processing subsystem consists of a plurality of parallel processing units for processing graphics, which is interpreted as the graphics processing cluster including a plurality of processing resources), each of the plurality of processing resources including: functional units to execute instructions associated with a render workload and a compute workload (Fig. 4, Col. 11 lines 9-21, wherein a graphics processor pipeline can be implemented by the PPUs; Col. 11 lines 21-36, Col. 12 lines 11-21, wherein the graphics processor pipeline includes processing vertex data and outputting processed graphics data, which is interpreted as the PPU having functional units to execute instructions associated with a render workload and a compute workload); and performance monitoring circuitry configured to generate a stream of events associated with the functional units, the stream of events related to execution of instructions associated with the render workload and the compute workload (Fig. 7, Col. 13 line 39 – Col. 14 line 15, wherein graphics processing pipeline units can be coupled to performance monitors which generate performance events with related data to processing primitives and raster operations, which is interpreted as performance monitoring circuitry configured to generate a stream of events associated with the functional units related to execution of instructions associated with the render workload and compute workload).
Allen does not teach the performance monitoring circuitry including: first circuitry including a first event filter to filter the stream of events according to a first event filter configuration and pass a first set of filtered events; and second circuitry including a second event filter to filter the first set of filtered events according to a second event filter configuration and pass a second set of filtered events; and third circuitry to output performance monitoring data based on the second set of filtered events.
Oreifej teaches the performance monitoring circuitry including: first circuitry including a first event filter to filter the stream of events according to a first event filter configuration and pass a first set of filtered events (Fig. 2, paragraph 25-26, wherein the short shader filter can determine whether the performance monitor should collect performance data on shaders based on programmable thresholds, wherein the graphics workload executed by the shaders is interpreted as a stream of events being monitored, which is interpreted as a first event filter to filter a stream of events according to a first event filter configuration, and wherein determining to collect performance data on the workload executed by the shaders is interpreted as passing the first set of filtered events); and second circuitry including a second event filter to filter the first set of filtered events according to a second event filter configuration and pass a second set of filtered events (Fig. 3, paragraph 27, 29-30, wherein the shader polling module can determine whether the performance monitor should collect performance data based on whether a plurality of shaders meets a dedicated processing criterion for processing a given graphics workload, wherein the graphics workload executed by the shaders are interpreted as a stream of events being monitored, which is interpreted as an event filter to filter a stream of events according to an event filter configuration, and wherein determining to collect performance data on the workload executed by the shaders is interpreted as passing the set of filtered events; Fig. 5, paragraph 31, 36, wherein the step 518 of the shader polling module determining whether the performance monitor should collect performance data happens after the step 516 of the short shader filter determining whether the performance monitor should collect performance data, which is interpreted as this step being a second event filter for passing a second set of filtered events); and third circuitry to output performance monitoring data based on the second set of filtered events (Fig. 4, paragraph 31-32, wherein the performance monitor aggregates performance data measuring performance statistics and outputs that performance data for graphics workloads that meet specified criteria, which is interpreted as outputting performance monitoring data based on the second set of filtered events).
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Allen with the teachings of Oreifej for performance monitoring in a graphics processor. Both Allen and Oreifej discuss performance monitoring the execution of graphics processing instructions within GPUs. Allen discusses ways to utilize performance monitoring for nonconventional graphics processing pipelines, in order to make debugging and analyzing graphics processing pipelines easier for a wider variety of pipelines. Similarly, Oreifej discusses performance monitoring a specific graphics workload throughout a GPU, in order to more accurately isolate and profile the processing demands of a specific graphics workload in order to more efficiently analyze and process graphics workloads. Additionally, both references discuss monitoring the performance of executing shader programs for graphics processing. As both references discuss analogous art for performance monitoring GPUs, it would be obvious to combine them.
Regarding claim 2, Allen in view of Oreifej discloses the graphics processor of claim 1. Additionally, Oreifej teaches the graphics processor of claim 1, the first event filter configuration including an identifier of a type of shader program and the first set of filtered events including events associated with execution of the type of shader program (Fig. 2, paragraph 25-26, wherein the short shader filter filters shaders based on the shader's resource consumption and time elapsed to execute operations, and generates a profile on the resource use of those shaders for a given graphics workload, which suggests the short shader filter identifies the types of shader programs that meet a specified resource consumption criteria, which is interpreted as the first event filter configuration including an identifier of a type of shader program and filters events associated with execution of the type of shader program).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 3, Allen in view of Oreifej discloses the graphics processor of claim 2. Additionally, Oreifej teaches the graphics processor of claim 2, the second event filter configuration including an identifier of a processing resource and the second set of filtered events including events associated with execution of the type of shader program at the processing resource (Fig. 3, paragraph 27, wherein the shader polling module monitors whether shaders are processing a specific graphics workload or not to determine whether to generate a profile on the resource use of those shaders, which suggests identifying processing resources and whether events of a specific type are being executed at the processing resource, wherein the shaders are interpreted as processing resources, and the graphics workload is interpreted as a set of filtered events).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 4, Allen in view of Oreifej discloses the graphics processor of claim 2. Additionally, Oreifej discusses the graphics processor of claim 2, the second event filter configuration including an identifier of a plurality of processing resources and the second set of filtered events including events associated with execution of the type of shader program at the plurality of processing resources (Fig. 3, paragraph 27, wherein the shader polling module monitors whether shaders are processing a specific graphics workload or not to determine whether to generate a profile on the resource use of those shaders, which suggests identifying processing resources and whether events of a specific type are being executed at the processing resource, wherein the shaders are interpreted as a plurality of processing resources, and the graphics workload is interpreted as a set of filtered events).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 5, Allen in view of Oreifej discloses the graphics processor of claim 2. Additionally, Oreifej teaches the graphics processor of claim 2, the first event filter configuration including identifiers of a plurality of types of shader programs and the first set of filtered events including events associated with execution of the plurality of types of shader programs (Fig. 2, paragraph 25-26, wherein the short shader filter filters shaders based on a plurality of shader's resource consumption and time elapsed to execute operations and generates a profile on the resource use of those shaders for a given graphics workload, which suggests the short shader filter identifies the plurality of types of shader programs that meet that resource consumption criteria, which is interpreted as the first event filter configuration including an identifier of a plurality of types of shader program and filters events associated with execution of the type of shader program).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 6, Allen in view of Oreifej discloses the graphics processor of claim 1. Additionally, Oreifej teaches the graphics processor of claim 1, the first event filter configuration including an identifier for a set of processing resources of the plurality of processing resources (Fig. 2, paragraph 25-26, wherein the short shader filter filtering shaders based on the shader's resource consumption and time elapsed to execute operations and generating a profile on the resource use of those shaders for a given graphics workload suggests the short shader filter identifies the shaders that meet that resource consumption criteria, wherein those shaders are interpreted as processing resources, which is interpreted as the first event filter configuration including an identifier for a set of processing resources of the plurality of processing resources), the second event filter configuration including a type of instruction, and the second set of filtered events including events associated with execution of an indicated type of instruction by the set of processing resources (Fig. 3, paragraph 27, wherein the shader polling module monitors whether shaders are processing a specific graphics workload or not to determine whether to generate a profile on the resource use of those shaders, which suggests identifying processing resources and whether events of a specific type are being executed at those processing resources, wherein the shaders are interpreted as processing resources, and the graphics workload is interpreted as a set of filtered events).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 9, Allen in view of Oreifej discloses the graphics processor of claim 1. Additionally, Allen teaches the performance monitoring data including first performance monitoring data associated with the render workload and second performance monitoring data associated with the compute workload (Fig. 7, Col. 13 line 39 – Col. 14 line 15, wherein graphics processing pipeline units can be coupled to performance monitors which generate performance events, wherein separate performance monitors are coupled to the tiler unit that processes primitives, and to the downstream units which outputs processed graphics data, which is interpreted as the performance monitoring data having a first performance monitoring data associated with the render workload, and a second performance monitoring data associated with the compute workload).
Regarding claim 10, Allen in view of Oreifej discloses the graphics processor of claim 9. Additionally, Allen teaches the third circuitry configured to output the first performance monitoring data to a first memory address and the second performance monitoring data to a second memory address (Fig. 7, Col. 14 line 9-15, Col. 15 lines 5-11, wherein the separate performance monitors send their data to memory, which suggests that the performance monitoring data can be sent to a separate first and second memory address).
Regarding claim 11, Allen teaches a graphics processing system comprising: a memory device; and a graphics processor including a memory interface coupled with the memory device and a graphics processing cluster coupled with the memory interface (Fig. 1, Col. 3 lines 26-64, wherein parallel processing subsystem consisting of a plurality of parallel processing units is coupled to a memory bridge, which is interpreted as a graphics processing cluster coupled with a memory interface), the graphics processing cluster including a plurality of processing resources (Fig. 2, Col. 4 line 66 – Col. 5 line 19, wherein parallel processing subsystem consists of a plurality of parallel processing units for processing graphics, which is interpreted as the graphics processing cluster including a plurality of processing resources), each of the plurality of processing resources including: functional units to execute instructions associated with a render workload and a compute workload (Fig. 4, Col. 11 lines 9-21, wherein a graphics processor pipeline can be implemented by the PPUs; Col. 11 lines 21-36, Col. 12 lines 11-21, wherein the graphics processor pipeline includes processing vertex data and outputting processed graphics data, which is interpreted as the PPU having functional units to execute instructions associated with a render workload and a compute workload); and performance monitoring circuitry configured to generate a stream of events associated with the functional units, the stream of events related to execution of instructions associated with the render workload and the compute workload (Fig. 7, Col. 13 line 39 – Col. 14 line 15, wherein graphics processing pipeline units can be coupled to performance monitors which generate performance events with related data to processing primitives and raster operations, which is interpreted as performance monitoring circuitry configured to generate a stream of events associated with the functional units related to execution of instructions associated with the render workload and compute workload).
Allen does not teach the performance monitoring circuitry including: first circuitry including a first event filter to filter the stream of events according to a first event filter configuration and pass a first set of filtered events; and second circuitry including a second event filter to filter the first set of filtered events according to a second event filter configuration and pass a second set of filtered events; and third circuitry to output performance monitoring data based on the second set of filtered events.
Oreifej teaches the performance monitoring circuitry including: first circuitry including a first event filter to filter the stream of events according to a first event filter configuration and pass a first set of filtered events (Fig. 2, paragraph 25-26, wherein the short shader filter can determine whether the performance monitor should collect performance data on shaders based on programmable thresholds, wherein the graphics workload executed by the shaders is interpreted as a stream of events being monitored, which is interpreted as a first event filter to filter a stream of events according to a first event filter configuration, and wherein determining to collect performance data on the workload executed by the shaders is interpreted as passing the first set of filtered events); and second circuitry including a second event filter to filter the first set of filtered events according to a second event filter configuration and pass a second set of filtered events (Fig. 3, paragraph 27, 29-30, wherein the shader polling module can determine whether the performance monitor should collect performance data based on whether a plurality of shaders meets a dedicated processing criterion for processing a given graphics workload, wherein the graphics workload executed by the shaders are interpreted as a stream of events being monitored, which is interpreted as an event filter to filter a stream of events according to an event filter configuration, and wherein determining to collect performance data on the workload executed by the shaders is interpreted as passing the set of filtered events; Fig. 5, paragraph 31, 36, wherein the step 518 of the shader polling module determining whether the performance monitor should collect performance data happens after the step 516 of the short shader filter determining whether the performance monitor should collect performance data, which is interpreted as this step being a second event filter for passing a second set of filtered events); and third circuitry to output performance monitoring data based on the second set of filtered events (Fig. 4, paragraph 31-32, wherein the performance monitor aggregates performance data measuring performance statistics and outputs that performance data for graphics workloads that meet specified criteria, which is interpreted as outputting performance monitoring data based on the second set of filtered events).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 12, Allen in view of Oreifej discloses the system of claim 11. Additionally, Oreifej teaches the system of claim 11, the first event filter configuration including an identifier of a type of shader program and the first set of filtered events including events associated with execution of the type of shader program (Fig. 2, paragraph 25-26, wherein the short shader filter filters shaders based on the shader's resource consumption and time elapsed to execute operations, and generates a profile on the resource use of those shaders for a given graphics workload, which suggests the short shader filter identifies the types of shader programs that meet a specified resource consumption criteria, which is interpreted as the first event filter configuration including an identifier of a type of shader program and filters events associated with execution of the type of shader program).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 13, Allen in view of Oreifej discloses system of claim 12. Additionally, Oreifej teaches the system of claim 12, the second event filter configuration including an identifier of a processing resource and the second set of filtered events including events associated with execution of the type of shader program at the processing resource (Fig. 3, paragraph 27, wherein the shader polling module monitors whether shaders are processing a specific graphics workload or not to determine whether to generate a profile on the resource use of those shaders, which suggests identifying processing resources and whether events of a specific type are being executed at the processing resource, wherein the shaders are interpreted as processing resources, and the graphics workload is interpreted as a set of filtered events).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 14, Allen in view of Oreifej discloses the system of claim 12. Additionally, Oreifej discusses the system of claim 12, the second event filter configuration including an identifier of a plurality of processing resources and the second set of filtered events including events associated with execution of the type of shader program at the plurality of processing resources (Fig. 3, paragraph 27, wherein the shader polling module monitors whether shaders are processing a specific graphics workload or not to determine whether to generate a profile on the resource use of those shaders, which suggests identifying processing resources and whether events of a specific type are being executed at the processing resource, wherein the shaders are interpreted as a plurality of processing resources, and the graphics workload is interpreted as a set of filtered events).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 15, Allen in view of Oreifej discloses the system of claim 12. Additionally, Oreifej teaches the system of claim 12, the first event filter configuration including identifiers of a plurality of types of shader programs and the first set of filtered events including events associated with execution of the plurality of types of shader programs (Fig. 2, paragraph 25-26, wherein the short shader filter filters shaders based on a plurality of shader's resource consumption and time elapsed to execute operations and generates a profile on the resource use of those shaders for a given graphics workload, which suggests the short shader filter identifies the plurality of types of shader programs that meet that resource consumption criteria, which is interpreted as the first event filter configuration including an identifier of a plurality of types of shader program and filters events associated with execution of the type of shader program).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 16, Allen in view of Oreifej discloses the system of claim 11. Additionally, Oreifej teaches the system of claim 11, the first event filter configuration including an identifier for a set of processing resources of the plurality of processing resources (Fig. 2, paragraph 25-26, wherein the short shader filter filtering shaders based on the shader's resource consumption and time elapsed to execute operations and generating a profile on the resource use of those shaders for a given graphics workload suggests the short shader filter identifies the shaders that meet that resource consumption criteria, wherein those shaders are interpreted as processing resources, which is interpreted as the first event filter configuration including an identifier for a set of processing resources of the plurality of processing resources), the second event filter configuration including a type of instruction, and the second set of filtered events including events associated with execution of an indicated type of instruction by the set of processing resources (Fig. 3, paragraph 27, wherein the shader polling module monitors whether shaders are processing a specific graphics workload or not to determine whether to generate a profile on the resource use of those shaders, which suggests identifying processing resources and whether events of a specific type are being executed at those processing resources, wherein the shaders are interpreted as processing resources, and the graphics workload is interpreted as a set of filtered events).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 19, Allen teaches a method comprising: configuring performance monitoring circuitry of a graphics processor to select a set of events to monitor for a concurrently executed render workload and an asynchronous compute workload to be executed by the graphics processor (Fig. 2, Col. 4 line 66 – Col. 5 line 19, wherein the graphics processor has parallel processing units that have rendering pipelines, and has parallel processing units execute commands asynchronously, which suggests that a render workload can be executed concurrently in parallel processes, and that a compute workload can be executed asynchronously; Fig. 7, Col. 13 line 39 – Col. 14 line 15, wherein graphics processing pipeline units can be coupled to performance monitors which generate performance events with related data to processing primitives and raster operations, wherein separate performance monitors are coupled to the tiler unit that processes primitives, and to the downstream units which outputs processed graphics data, which is interpreted as the performance monitoring data having first performance monitoring data associated with the render workload, and a second performance monitoring data associated with the compute workload); and during execution of the render workload and the asynchronous compute workload, read first data for events related to the render workload from a first memory location that is specified to store performance monitoring data for the render workload and concurrently read second data for events related to the compute workload from a second memory location that is specified to store performance monitoring data for the compute workload (Fig. 7, Col. 13 line 39 – Col. 14 line 15, wherein separate performance monitors are coupled to the tiler unit that processes primitives, and to the downstream units which outputs processed graphics data, which is interpreted as the performance monitoring data having first performance monitoring data associated with the render workload, and a second performance monitoring data associated with the compute workload; Fig. 7, Col. 14 line 9-15, Col. 15 lines 5-11, wherein the separate performance monitors send their data to memory, which suggests that the performance monitoring data can be sent to and read from a separate first and second memory address specified to store performance monitoring data for both a render workload and a compute workload).
Allen does not teach configuring a first set of event filters to pass events related to the render workload; and configuring a second set of event filters to pass events related to the asynchronous workload.
Oreifej teaches configuring a first set of event filters to pass events related to the render workload (Fig. 2, paragraph 25-26, wherein the short shader filter can determine whether the performance monitor should collect performance data on shaders based on programmable thresholds, wherein the graphics workload executed by the shaders are interpreted as including events related to a render workload, which is interpreted as a first set of event filters to pass events related to a render workload); and configuring a second set of event filters to pass events related to the asynchronous workload (Fig. 3, paragraph 27, 29-30, wherein the shader polling module can determine whether the performance monitor should collect performance data based on whether a plurality of shaders meets a dedicated processing criterion for processing a given graphics workload, wherein the graphics workload executed by the shaders is interpreted as a set of events which can include events related to an asynchronous workload, and wherein determining to collect performance data on the workload executed by the shaders is interpreted as passing the set of filtered events; Fig. 5, paragraph 31, 36, wherein the step 518 of the shader polling module determining whether the performance monitor should collect performance data happens after the step 516 of the short shader filter determining whether the performance monitor should collect performance data, which is interpreted as this step being a second set of event filters for passing a second set of filtered events).
The motivation to combine would be the same as that set forth for claim 1.
Regarding claim 20, Allen in view of Oreifej discloses the method of claim 19. Additionally, Allen teaches the method of claim 19, further comprising: displaying first performance monitoring data for the render workload; and displaying second performance monitoring data for the compute workload, the first performance data differentiated from the second performance data (Fig. 8A, Col. 15 line 12-43, wherein performance data associated with a first performance monitor and a second performance monitor are displayed, wherein each set of performance data is related to separate instances, which is interpreted as displaying a first and second different performance monitoring data).
5. Claims 7-8, 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Allen in view of Oreifej as applied to claims 1, 11 above, and further in view of Baliga et al. (US 20240311163 A1), hereinafter Baliga.
Regarding claim 7, Allen in view of Oreifej discloses the graphics processor of claim 6. Additionally, Baliga teaches the identifier for the set of processing resources including a row identifier for the set of processing resources (paragraph 13-15, wherein rows of a state transition data structure are indexed, wherein the data structure consists of branch identifiers for threads of a processor, which is interpreted as the identifier for a set of processing resources include a row identifier for the set of processing resources).
It would be obvious to one of ordinary skill before the effective filing date of the claimed invention to have modified Allen in view of Oreifej to incorporate the teachings of Baliga for this graphic processor consisting of performance monitoring. All three references discuss performance monitoring the execution of graphics processing instructions within GPUs. Allen discusses ways to utilize performance monitoring for nonconventional graphics processing pipelines, in order to make debugging and analyzing graphics processing pipelines easier for a wider variety of pipelines. Similarly, Oreifej discusses performance monitoring a specific graphics workload throughout a GPU, in order to more accurately isolate and profile the processing demands of a specific graphics workload in order to more efficiently analyze and process graphics workloads. Additionally, Baliga discusses performance monitors for streaming multiprocessors, in order to keep track of the states of components, and to filter event signals based on specific flags. Both Oreifej and Baliga discuss filtering events with performance monitors, with Oreifej setting certain performance and processing criteria as filters, and Baliga setting specific filter flags to filter events. Additionally, all three references discuss using their processors to execute shader programs. As all three references discuss analogous art for performance monitoring GPUs, it would be obvious to combine them.
Regarding claim 8, Allen in view of Oreifej and Baliga discloses the graphics processor of claim 7. Additionally, Allen teaches the graphics processor of claim 7, the type of instruction including a three operand instruction, a two operand instruction, a move instruction, or a send message instruction (Fig. 2-3, Col. 7 line 62 – Col. 8 line 18, wherein the streaming multiprocessor that executes graphics processing instructions receives instructions which can include arithmetic operations, comparison operations, Boolean operations, and bit shifting operations, which is interpreted as including two and three operand instructions, and move instructions.).
Regarding claim 17, Allen in view of Oreifej discloses the system of claim 16. Additionally, Baliga teaches the identifier for the set of processing resources including a row identifier for the set of processing resources (paragraph 13-15, wherein rows of a state transition data structure are indexed, wherein the data structure consists of branch identifiers for threads of a processor, which is interpreted as the identifier for a set of processing resources include a row identifier for the set of processing resources).
The motivation to combine would be the same as that set forth for claim 7.
Regarding claim 18, Allen in view of Oreifej and Baliga discloses the system of claim 17. Additionally, Allen teaches the system of claim 17, the type of instruction including a three operand instruction, a two operand instruction, a move instruction, or a send message instruction (Fig. 2-3, Col. 7 line 62 – Col. 8 line 18, wherein the streaming multiprocessor that executes graphics processing instructions receives instructions which can include arithmetic operations, comparison operations, Boolean operations, and bit shifting operations, which is interpreted as including two and three operand instructions, and move instructions.).
Conclusion
6. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORDAN W YICK whose telephone number is (571)272-4063. The examiner can normally be reached M-F 8-5.
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, Said Broome can be reached at (571) 272-2931. 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.
/JORDAN WAN YICK/Examiner, Art Unit 2612
/Said Broome/Supervisory Patent Examiner, Art Unit 2612
Prosecution Insights