DETAILED ACTION
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 .
In view of the Appeal Brief filed on 5/27/2026, PROSECUTION IS HEREBY REOPENED. New grounds of rejection are Li et al. U.S. Pub. No. 2016/0042550 in view of Wioka et al. U.S. Patent No. 7,468,726 set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
/DEVONA E FAULK/ Supervisory Patent Examiner, Art Unit 2618
Claim Rejections - 35 USC § 103
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.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 9, 16; 2, 3, 4, 5, 10, 11, 12, 13, 17, 18, 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. U.S. Pub. No. 2016/0042550 in view of Wioka et al. U.S. Patent No. 7,468,726
Re: claims 1, 9 and 16 (which are rejected under the same rationale), Li teaches
1. (Currently Amended) A method comprising: receiving, by a shader engine, a set of primitives for rendering at least a portion of a scene; (“GPU 12 may be configured to perform graphics operations to render one or more graphics primitives to display 18... The highly parallel nature of GPU 12 may, in some instances, allow GPU 12 to draw graphics images (e.g., GUIs and two-dimensional (2D) and/or three-dimensional (3D) graphics scenes) onto display 18 more quickly than drawing the scenes directly to display 18 using CPU 6.”; Li, [0042])
The GPU is configured to render graphics primitives of a 3D graphic scene.
(“GPU 12 may include graphics processing pipeline 30 that includes a plurality of graphics processing stages that operate together to execute graphics processing commands... As shown in FIG. 2, graphics processing pipeline 30 may include command engine 32, geometry processing stage 34, rasterization stage 36, and pixel processing pipeline 38. Pixel processing pipeline 38 may include texture engine 39. Each of the components in graphics processing pipeline 30 may be implemented as fixed-function components, programmable components (e.g., as part of a shader program executing on a programmable shader unit), or as a combination of fixed-function and programmable components.”; Li, [0047], Fig. 2)
Fig. 2 illustrates a GPU that includes a graphics processing pipeline (shader engine) for rendering graphics primitives of a 3D graphic scene. Each of the components in the graphics processing pipeline (shader engine) are implemented as shader programs executing on a programmable shader unit).
(“In some instances, the primitive definitions may be provided to GPU 12 in the form of a list of drawing primitives, e.g., triangles, rectangles, triangle fans, triangle strips, etc... Based on the instructions issued by software application 24 to GPU driver 7, GPU driver 7 may formulate one or more commands that specify one or more operations for GPU 12 to perform in order to render the primitive”; Li, [0050])
Primitive definitions are provided to the GPU, which includes the graphics pipeline (receiving, by a shader engine), where the primitive definitions include triangles, triangle fans and triangle strips (a set of primitives for rendering at least a portion of a scene).
culling the set of primitives by the shader engine, wherein culling the set of primitives comprises identifying a subset of the primitives that are potentially visible in the scene; (“Geometry processing stage 34 may also perform other operations including, e.g., normal transformations, normal normalization operations, view volume clipping, homogenous division and/or backface culling operations.”; Li, [0054])
Fig. 2 illustrates the geometry processing stage of the graphics processing pipeline (shader engine) that performs operations including culling operations. Li is silent regarding culling the set of primitives comprises identifying a subset of the primitives that are potentially visible in the scene; generating, by the shader engine, attribute data values for the identified subset of primitives, however, Wioka teaches these limitations.
(“Graphics processing subsystem 112 includes a graphics processing unit (GPU) 122 and a graphics memory 124...”; Wioka, col. 5, lines 1-6, Fig. 1)
Fig. 1 illustrate that the graphics processing subsystem includes a GPU.
(“FIG. 2 is a block diagram of a rendering pipeline 200 of a graphics processing subsystem according to an embodiment of the invention. Pipeline 200 may be implemented in GPU 112 of FIG. 1 or any other graphics processor. Pipeline 200 includes a vertex processing unit 205, a viewport and culling (VPC) unit 210, a setup unit 215, a rasterizer unit 220, a color assembly unit 225, and a fragment processing unit 230.”; Wioka, col. 6, lines 14-20, Fig. 2)
Fig. 2 illustrates a rendering pipeline 200 (shader engine) that is implemented in a GPU.
(“... the geometry programs executed by geometry shader 209 include a culling program that applies a visibility test (or multiple visibility tests) to the primitives... Primitives that satisfy the visibility test (or tests) are referred to herein as "potentially visible" while primitives that fail the test are referred to herein as "invisible."”; Wioka, col. 7, lines 49-59)
The geometry programs executed by the geometry shader of the rendering pipeline (shader engine), include a culling program that applies a visibility test to primitives, where the primitives that satisfy the visibility test are considered “potentially visible” (culling the set of primitives comprises identifying a subset of the primitives that are potentially visible in the scene).
(“Invisible primitives are advantageously discarded (culled) as early as possible in the rendering pipeline so that minimal time is consumed in processing data that has no effect on the final rendered image.”; Wioka, col. 7, lines 60-63)
Invisible primitives are culled as early as possible in the rendering pipeline (culling the set of primitives by the shader engine).
generating, by the shader engine, attribute data values for the identified subset of primitives; (“As described below, the vertex processing path in some embodiments includes a first pass of the vertices through the vertex shader, during which clip space coordinates are computed; a first pass of the primitives through the geometry shader, during which culling is performed; and a second pass of the vertices that survive culling (i.e., any vertex that is in at least one visible primitive) through the vertex shader, during which other vertex attributes are computed.”; Wioka, col. 8, lines 7-15)
In the rendering pipeline (shader engine), the vertex processing path includes a first pass of primitives through the geometry shader, where culling is performed and a second pass, through the geometry shader, of the vertices that survive culling (identified subset of primitives), where vertex attributes (attribute data values) are computed (generating, by the shader engine, attribute data values for the identified subset of primitives).
and rasterizing the identified subset of primitives, by the shader engine, for rendering based on the generated attribute data values. (“Setup unit 215 uses the vertices of each primitive it receives to compute three edge equations for use by rasterizer unit 220 and also creates an ordered list of vertices to be used in defining a plane equation of the primitive. Rasterizer unit 220 converts each primitive into one or more fragments, where each fragment defines a set of one or more sample points for the rendered image.”; Wioka, col. 8, lines 48-54)
Fig. 2 illustrates that the rendering pipeline (shader engine) includes a setup unit that uses the vertices of each primitive it receives (primitives that survived culling / (identified subset of primitives)) to create edge equations for each primitive and plane equations for each primitive, which are then sent to the rasterizer. The rasterizer unit converts each primitive into one or more fragments.
(“Color assembly unit 225 associates the primitives and coverage information received from rasterizer unit 220 with the attributes (e.g., color components, texture coordinates, surface normals) received from VPC unit 210 and generates plane equations... for some or all of the attributes in screen coordinates... These attribute equations are provided to a fragment processing unit 230. Fragment processing unit 230 uses the attribute equations (and other data as appropriate) to compute a fragment color.”; Wioka, col. 8, lines 60-col. 9, line 3)
The color assembly unit associates the primitives (identified subsets of primitives) and coverage information received from the rasterizer unit with the attributes (generated attribute data values) received from the VPC unit. The color assembly unit also generates plane equations for the attributes (generated attribute data values). These attribute plane equations are provided to the fragments processing unit, which uses the attribute plane equations to compute fragment color.
(“The colored fragments are then output to the raster operations unit 235.”; Wioka, col. 9, lines 19-20)
The colored fragments are then output to the raster operations unit (rasterizing the identified subset of primitives, by the shader engine, for rendering based on the generated attribute data values). Wioka is combined with Li such that the functions of the pipeline Wioka are included in the pipeline of Li. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of culling the set of primitives by the shader engine, wherein culling the set of primitives comprises identifying a subset of the primitives that are potentially visible in the scene; generating, by the shader engine, attribute data values for the identified subset of primitives and rasterizing the identified subset of primitives, by the shader engine, for rendering based on the generated attribute data values, in order to discard invisible primitives as early as possible in the rendering pipeline so that minimal time is consumed in processing date that has no effect on the final rendered image, as taught by Wioka (col. 7, lines 60-63).
Claim 9 is an acceleration unit analogous to the method of claim 1, is similar in scope and is rejected under the same rationale. Claim 1 has additional limitations. Re: claim 9, Li teaches
9. (Currently Amended) An acceleration unit comprising: one or more caches; and a shader engine coupled to the one or more caches, the a shader engine configured to: (“In one example, this disclosure proposes implementing HOF by modifying the texture engine of a GPU (e.g., texture engine 39 of GPU 12) and utilizing already existing texture engine hardware (e.g., local cache with addressing and multiply sample fetch control unit).”; Li, [0062], Fig. 2)
Fig. 2 illustrates a GPU (acceleration unit) which comprises a graphics pipeline (shader engine coupled to) and a texture engine, which includes a local cache (the one or more caches).
Claim 16 is a medium analogous to the method of claim 1, is similar in scope and is rejected under the same rationale. Claim 16 has additional limitations. Re: claim 16, Li teaches
16. (Original) A non-transitory computer readable medium embodying a set of executable instructions, the set of executable instructions to manipulate at least one processor to: (“In one or more examples, the functions described above may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on an article of manufacture comprising a non-transitory computer-readable medium. Computer-readable media may include computer data storage media... The code may be executed by one or more processors, such as one or more DSPs, general purpose microprocessors, ASICs, FPGAs, or other equivalent integrated or discrete logic circuitry.”; Li, [0114], [0115])
When the functions are implemented in software, the instructions are stored on a non-transitory computer-readable medium and executed by one or more processors.
Re: claims 2 and 17 (which are rejected under the same rationale), Li and Wioka teach
2. (Currently Amended) The method of claim 1, further comprising generating, by the shader engine, intermediate data for the identified subset of primitives, and wherein the method is performed without providing, external to a plurality of shader engines that includes the shader engine, the intermediate data or the attribute data values. (“The primitives (or vertices) that survive culling pass from vertex processing unit 205 to viewport and culling (VPC) unit 210. VPC unit 210 may further transform the primitives from clip space coordinates to screen space coordinates.”; Wioka, col. 8, lines 16-19)
In the rendering pipeline (shader engine), the primitives that survive culling (identified subset of primitives) pass to the VPC, where the primitives are transformed from clip space coordinates to screen space coordinates (generating, by the shader engine, intermediate data for the identified subset of primitives). Fig. 2 illustrates that the transformation from clip space coordinates to screen space coordinates (generating intermediate data) is performed in the VPC (the method is performed without providing, external to the one or more shader engines, the intermediate data or the attribute data values). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of generating, by the shader engine, intermediate data for the identified subset of primitives, and wherein the method is performed without providing, external to a plurality of shader engines that includes the shader engine, the intermediate data or the attribute data values, in order to discard invisible primitives as early as possible in the rendering pipeline so that minimal time is consumed in processing date that has no effect on the final rendered image, as taught by Wioka (col. 7, lines 60-63).
Re: claims 3 and 18 (which are rejected under the same rationale), Li and Wioka teach
3. The method of claim 2, wherein: generating the intermediate data for the identified subset of primitives comprises generating intermediate geometry data for the identified subset; (“The primitives (or vertices) that survive culling pass from vertex processing unit 205 to viewport and culling (VPC) unit 210. VPC unit 210 may further transform the primitives from clip space coordinates to screen space coordinates.”; Wioka, col. 8, lines 16-19)
In the rendering pipeline (shader engine), the primitives that survive culling (identified subset of primitives) pass to the VPC, where the primitives (or vertices) are transformed from primitives with clip space coordinates to primitives (or vertices) with screen space coordinates (generating the intermediate geometry data for the identified subset, by the shader engine, intermediate data for the identified subset of primitives).
and rasterizing the identified subset of primitives comprises rasterizing the identified subset based on the intermediate geometry data. (“Setup unit 215 uses the vertices of each primitive it receives to compute three edge equations for use by rasterizer unit 220 and also creates an ordered list of vertices to be used in defining a plane equation of the primitive. Rasterizer unit 220 converts each primitive into one or more fragments, where each fragment defines a set of one or more sample points for the rendered image.”; Wioka, col. 8, lines 48-54)
Fig. 2 illustrates that the setup unit uses vertices of each primitive it receives from the VPC (intermediate geometry data for the identified subset) to compute three edge equations for use by the rasterizer, where the primitives received from the VPC have been converted into screen space coordinates (rasterizing the identified subset based on the intermediate geometry data). The rasterizer converts each primitive received from the setup unit (rasterizing the identified subset of primitives) into one or more fragments. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of - generating the intermediate data for the identified subset of primitives comprises generating intermediate geometry data for the identified subset; and rasterizing the identified subset of primitives comprises rasterizing the identified subset based on the intermediate geometry data, in order to discard invisible primitives as early as possible in the rendering pipeline so that minimal time is consumed in processing date that has no effect on the final rendered image, as taught by Wioka (col. 7, lines 60-63).
Re: claims 4 and 19 (which are rejected under the same rationale), Li and Wioka teach
4. The method of claim 2, wherein: generating the intermediate data for the identified subset of primitives comprises generating assembled primitive data for the identified subset of primitives; (“Setup unit 215 uses the vertices of each primitive it receives to compute three edge equations for use by rasterizer unit 220 and also creates an ordered list of vertices to be used in defining a plane equation of the primitive. Rasterizer unit 220 converts each primitive into one or more fragments, where each fragment defines a set of one or more sample points for the rendered image.”; Wioka, col. 8, lines 48-54)
Fig. 2 illustrates that the setup unit uses vertices of each primitive it receives from the VPC (intermediate data for the identified subset of primitives) to compute three edge equations for use by the rasterizer, where the primitives received from the VPC have been converted into screen space coordinates (intermediate data). The three edge equations are used by the rasterizer to assemble the primitives (generating assembled primitive data for the identified subset of primitives).
and generating the attribute data values comprises generating the attribute data values based on the assembled primitive data. (“Color assembly unit 225 associates the primitives and coverage information received from rasterizer unit 220 with the attributes (e.g., color components, texture coordinates, surface normals) received from VPC unit 210 and generates plane equations (or other suitable equations) for some or all of the attributes in screen coordinates. These attribute equations are usable to interpolate a value for the attribute at any location within the primitive.”; Wioka, col. 8, lines 60-67 )
Fig. 2 illustrates a color assembly unit, which associates primitives (assembled primitive data) and coverage information received from the rasterizer unit with the attributes (such as color components) received from the VPC unit and generates plane equations for attributes in screen coordinates. These attribute equations are used to interpolate a value for the attribute at any location within the primitive (generating the attribute data values based on the assembled primitive data). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of : generating the intermediate data for the identified subset of primitives comprises generating assembled primitive data for the identified subset of primitives; and generating the attribute data values comprises generating the attribute data values based on the assembled primitive data, in order to discard invisible primitives as early as possible in the rendering pipeline so that minimal time is consumed in processing date that has no effect on the final rendered image, as taught by Wioka (col. 7, lines 60-63).
Re: claims 5 and 20 (which are rejected under the same rationale), Li and Wioka teach
5. (Original) The method of claim 1, wherein rasterizing the identified subset of primitives comprises generating a rasterized subset of primitives, and wherein the method further comprises rendering the scene by generating pixel data based on the rasterized subset of primitives. (“Color assembly unit 225 associates the primitives and coverage information received from rasterizer unit 220 with the attributes (e.g., color components, texture coordinates, surface normals) received from VPC unit 210 and generates plane equations (or other suitable equations) for some or all of the attributes in screen coordinates. These attribute equations are usable to interpolate a value for the attribute at any location within the primitive. These attribute equations are provided to a fragment processing unit 230. Fragment processing unit 230 uses the attribute equations (and other data as appropriate) to compute a fragment color.”; Wioka, col. 8, line 60-col. 9, line 3)
Fig. 2 illustrates a fragment processing unit that receives attribute equations from the color assembly unit. The fragment processing unit uses the attribute equations to compute a fragment color.
(“The colored fragments are then output to the raster operations unit 235. The raster operations unit 235 integrates the fragments output from the fragment processing unit 230 with the rendered image. Fragments can be blended or masked with fragments previously written to the rendered image... The appropriate combination of each incoming fragment and any previously stored fragment value is written to a frame buffer, which can be located, e.g., in graphics memory 124 of FIG. 1, as part of the rendered image. The frame buffer can then be scanned out to a display device and/or subjected to further processing.”; Wioka, col. 9, lines 19-31)
Fig. 2 illustrates a raster operations unit that receives colored fragments from the fragment processing unit. The raster operations unit integrates fragments output from the fragment processing unit with the rendered image (generating a rasterized subset of primitives). A combination of incoming fragments and previously stored fragments are written to a frame buffer (rendering the scene by generating pixel data based on the rasterized subset of primitives). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of rasterizing the identified subset of primitives comprises generating a rasterized subset of primitives, and wherein the method further comprises rendering the scene by generating pixel data based on the rasterized subset of primitives, in order to discard invisible primitives as early as possible in the rendering pipeline so that minimal time is consumed in processing date that has no effect on the final rendered image, as taught by Wioka (col. 7, lines 60-63).
Re: claim 10, Li and Wioka teach
10. (Currently Amended) The acceleration unit of claim 9, wherein the shader engine is further configured to generate intermediate data for the identified subset of primitives, and to generate the attribute data values and rasterize the identified subset of primitives without providing, external to a plurality of shader engines that includes the shader engine, the intermediate data or the attribute data values. (“The primitives (or vertices) that survive culling pass from vertex processing unit 205 to viewport and culling (VPC) unit 210. VPC unit 210 may further transform the primitives from clip space coordinates to screen space coordinates.”; Wioka, col. 8, lines 16-19)
In the rendering pipeline (shader engine), the primitives that survive culling (identified subset of primitives) pass to the VPC, where the primitives are transformed from clip space coordinates to screen space coordinates (generate intermediate data for the identified subset of primitives). Fig. 2 illustrates that the transform from clip space coordinates to screen space coordinates (generate intermediate data values) and the raster function (rasterize the identified subset of primitives) is performed in the VPC and the raster unit, respectively (without providing, external to the one or more shader engines that include the shader engine, the intermediate data or the attribute data values). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of the shader engine is further configured to generate intermediate data for the identified subset of primitives, and to generate the attribute data values and rasterize the identified subset of primitives without providing, external to a plurality of shader engines that includes the shader engine, the intermediate data or the attribute data values, in order to discard invisible primitives as early as possible in the rendering pipeline so that minimal time is consumed in processing date that has no effect on the final rendered image, as taught by Wioka (col. 7, lines 60-63).
Re: claim 11, Li and Wioka teach
11. (Currently Amended) The acceleration unit of claim 10, wherein: the intermediate data for the identified subset of primitives includes intermediate geometry data for the identified subset; (“The primitives (or vertices) that survive culling pass from vertex processing unit 205 to viewport and culling (VPC) unit 210. VPC unit 210 may further transform the primitives from clip space coordinates to screen space coordinates.”; Wioka, col. 8, lines 16-19)
In the rendering pipeline (shader engine), the primitives that survive culling (identified subset of primitives) pass to the VPC, where the primitives (or vertices) are transformed from primitives with clip space coordinates to primitives (or vertices) with screen space coordinates (the intermediate data for the identified subset of primitives includes intermediate geometry data for the identified subset, by the shader engine, intermediate data for the identified subset of primitives).
and the shader engine is configured to rasterize the identified subset of primitives based on the intermediate geometry data. (“Setup unit 215 uses the vertices of each primitive it receives to compute three edge equations for use by rasterizer unit 220 and also creates an ordered list of vertices to be used in defining a plane equation of the primitive. Rasterizer unit 220 converts each primitive into one or more fragments, where each fragment defines a set of one or more sample points for the rendered image.”; Wioka, col. 8, lines 48-54)
Fig. 2 illustrates that the setup unit, of the rendering pipeline (shader engine), uses vertices of each primitive it receives from the VPC (intermediate geometry data for the identified subset) to compute three edge equations for use by the rasterizer, where the primitives received from the VPC have been converted into screen space coordinates (rasterize the identified subset of primitives based on the intermediate geometry data). The rasterizer converts each primitive received from the setup unit (rasterizing the identified subset of primitives) into one or more fragments. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of - the intermediate data for the identified subset of primitives includes intermediate geometry data for the identified subset; and the shader engine is configured to rasterize the identified subset of primitives based on the intermediate geometry data, in order to discard invisible primitives as early as possible in the rendering pipeline so that minimal time is consumed in processing date that has no effect on the final rendered image, as taught by Wioka (col. 7, lines 60-63).
Re: claim 12, Li and Wioka teach
12. (Currently Amended) The acceleration unit of claim 10, wherein: the intermediate data for the identified subset of primitives comprises assembled primitive data for the identified subset of primitives; (“Setup unit 215 uses the vertices of each primitive it receives to compute three edge equations for use by rasterizer unit 220 and also creates an ordered list of vertices to be used in defining a plane equation of the primitive. Rasterizer unit 220 converts each primitive into one or more fragments, where each fragment defines a set of one or more sample points for the rendered image.”; Wioka, col. 8, lines 48-54)
Fig. 2 illustrates that the setup unit uses vertices of each primitive it receives from the VPC (intermediate data for the identified subset of primitives) to compute three edge equations for use by the rasterizer, where the primitives received from the VPC have been converted into screen space coordinates (intermediate data). The three edge equations are used by the rasterizer to assemble the primitives (The intermediate data for the identified subset of primitives comprises assembled primitive data for the identified subset of primitives).
and the shader engine is configured to generate the attribute data values based on the assembled primitive data. (“Color assembly unit 225 associates the primitives and coverage information received from rasterizer unit 220 with the attributes (e.g., color components, texture coordinates, surface normals) received from VPC unit 210 and generates plane equations (or other suitable equations) for some or all of the attributes in screen coordinates. These attribute equations are usable to interpolate a value for the attribute at any location within the primitive.”; Wioka, col. 8, lines 60-67 )
Fig. 2 illustrates a color assembly unit, of the rendering pipeline (shader engine), which associates primitives (assembled primitive data) and coverage information received from the rasterizer unit with the attributes (such as color components) received from the VPC unit and generates plane equations for attributes in screen coordinates. These attribute equations are used to interpolate a value for the attribute at any location within the primitive (shader engine is configured to generate the attribute data values based on the assembled primitive data). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of the intermediate data for the identified subset of primitives comprises assembled primitive data for the identified subset of primitives; and the shader engine is configured to generate the attribute data values based on the assembled primitive data, in order to discard invisible primitives as early as possible in the rendering pipeline so that minimal time is consumed in processing date that has no effect on the final rendered image, as taught by Wioka (col. 7, lines 60-63).
Re: claim 13, Li and Wioka teach
13. (Currently Amended) The acceleration unit of claim 9, wherein to rasterize the identified subset of primitives comprises generating a rasterized subset of primitives, and wherein the shader engine is configured to render the scene by generating pixel data based on the rasterized subset of primitives. (“Color assembly unit 225 associates the primitives and coverage information received from rasterizer unit 220 with the attributes (e.g., color components, texture coordinates, surface normals) received from VPC unit 210 and generates plane equations (or other suitable equations) for some or all of the attributes in screen coordinates. These attribute equations are usable to interpolate a value for the attribute at any location within the primitive. These attribute equations are provided to a fragment processing unit 230. Fragment processing unit 230 uses the attribute equations (and other data as appropriate) to compute a fragment color.”; Wioka, col. 8, line 60-col. 9, line 3 )
Fig. 2 illustrates a fragment processing unit, of the rendering pipeline (shader engine), that receives attribute equations from the color assembly unit. The fragment processing unit uses the attribute equations to compute a fragment color.
(“The colored fragments are then output to the raster operations unit 235. The raster operations unit 235 integrates the fragments output from the fragment processing unit 230 with the rendered image. Fragments can be blended or masked with fragments previously written to the rendered image... The appropriate combination of each incoming fragment and any previously stored fragment value is written to a frame buffer, which can be located, e.g., in graphics memory 124 of FIG. 1, as part of the rendered image. The frame buffer can then be scanned out to a display device and/or subjected to further processing.”; Wioka, col. 9, lines 19-31)
Fig. 2 illustrates a raster operations unit, of the rendering pipeline (shader engine) that receives colored fragments from the fragment processing unit. The raster operations unit integrates fragments output from the fragment processing unit with the rendered image (generating a rasterized subset of primitives). A combination of incoming fragments and previously stored fragments are written to a frame buffer (render the scene by generating pixel data based on the rasterized subset of primitives). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of to rasterize the identified subset of primitives comprises generating a rasterized subset of primitives, and wherein the shader engine is configured to render the scene by generating pixel data based on the rasterized subset of primitives, in order to discard invisible primitives as early as possible in the rendering pipeline so that minimal time is consumed in processing date that has no effect on the final rendered image, as taught by Wioka (col. 7, lines 60-63).
Claim(s) 6 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li in view of Wioka as applied to claims 1 and 9 above, and further in view of Chung et al. U.S. Pub. No. 2016/0148424.
Re: claim 6, Li and Wioka are silent regarding splitting the scene into a plurality of tiles, wherein the set of primitives corresponds to all primitives associated with one tile of the plurality of tiles and wherein the method further comprises rendering the frame for display, however, Chung teaches
6. (Currently Amended) The method of claim 1, further comprising splitting a frame representing the scene into a plurality of tiles, wherein the set of primitives corresponds to all primitives associated with one tile of the plurality of tiles. (“In one example, the GPU 10 may perform a tile-based graphics pipeline or a tile-based rendering (TBR). In this context, the term “tile-based” means that each frame of a moving image is divided or partitioned into a plurality of tiles, and the rendering is performed per tile.”; Chung, [0100], [0106], Fig. 6)
The GPU performs a tile-based graphics pipeline that divides or partitions each frame into a plurality of tiles.
(“In one example, the object 220 may be a 3D object, such as a car object 220 which is presented in one frame 200 of a moving image. The GPU 10 partitions the frame 200 including the 3D car object 220 into NxM tiles 210, wherein N and M are each natural numbers.”; Chung, [0106], Fig. 2)
Fig. 2 illustrates that the GPU partitions frame 200 into a plurality of tiles (splitting the scene into a plurality of tiles).
(“The binner 135 performs binning or tiling using output primitives from the domain shader 125 or the geometry shader 130. In other words, the binner 135 generates (bins) a tile list indicating information about each of tiles to which the output primitives belong, by performing a depth test (or a tile Z test).”; Chung, [0121], Fig. 6)
Fig. 6 illustrates a GPU, which includes a graphics pipeline (shader engine). Fig. 6 illustrates that graphics pipeline (shader engine) includes a binner that generates a tile list indicating which primitives belong to each (one tile) tile (wherein the set of primitives corresponds to all primitives associated with one tile of the plurality of tiles). Chung is combined with Li and Wioka such that the primitives that belong to each tile of Chung are the visible primitives of Li and Wioka.
and wherein the method further comprises rendering the frame for display. (“In this example, the binning pipeline 101 partitions the frame including the car object 220 into the tiles 210 and determines which tiles 210 include the car object 220. The GPU 10 renders the car object 220 per tile to convert the car object 220 to pixel expressions.”; Chung, [0106])
Fig. 2 illustrates the rendered frame. The GPU renders the frame (rendering the frame for display), that includes the car, on a per tile basis. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of splitting the scene into a plurality of tiles, wherein the set of primitives corresponds to all primitives associated with one tile of the plurality of tiles and wherein the method further comprises rendering the frame for display, in order to increase graphics processing performance or efficiency by reducing the amount of rendering, as taught by Chung ([0129]-[0130]).
Re: claim 14, Li and Wioka are silent regarding the shader engine is further configured to divide a frame that represents the scene into a plurality of tiles, and wherein the set of primitives corresponds to all primitives associated with one tile of the plurality of tiles, however, Chung teaches
14 (Currently Amended) The acceleration unit of claim 9, wherein the shader engine is further configured to divide a frame that represents the scene into a plurality of tiles, and wherein the set of primitives corresponds to all primitives associated with one tile of the plurality of tiles. (“In one example, the GPU 10 may perform a tile-based graphics pipeline or a tile-based rendering (TBR). In this context, the term “tile-based” means that each frame of a moving image is divided or partitioned into a plurality of tiles, and the rendering is performed per tile.”; Chung, [0100], [0106])
The GPU (acceleration unit) performs a tile-based graphics pipeline (shader engine) that divides or partitions each frame into a plurality of tiles (divide a frame that represents the scene into a plurality of tiles).
(“In one example, the object 220 may be a 3D object, such as a car object 220 which is presented in one frame 200 of a moving image. The GPU 10 partitions the frame 200 including the 3D car object 220 into NxM tiles 210, wherein N and M are each natural numbers.”; Chung, [0106], Fig. 2)
Fig. 2 illustrates that the GPU partitions frame 200 into a plurality of tiles (divide a frame that represents the scene into a plurality of tiles).
(“The binner 135 performs binning or tiling using output primitives from the domain shader 125 or the geometry shader 130. In other words, the binner 135 generates (bins) a tile list indicating information about each of tiles to which the output primitives belong, by performing a depth test (or a tile Z test).”; Chung, [0121], Fig. 6)
Fig. 6 illustrates a GPU (acceleration unit), which includes a graphics pipeline (shader engine). Fig. 6 illustrates that graphics pipeline includes a binner that generates a tile list indicating which primitives belong to each (one tile) tile (the set of primitives corresponds to all primitives associated with one tile of the plurality of tiles). Chung is combined with Li and Wioka such that the primitives that belong to each tile of Chung are the visible primitives of Li and Wioka. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of the shader engine is further configured to divide a frame that represents the scene into a plurality of tiles, and wherein the set of primitives corresponds to all primitives associated with one tile of the plurality of tiles, in order to increase graphics processing performance or efficiency by reducing the amount of rendering, as taught by Chung ([0129]-[0130]).
Claim(s) 7, 8 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Li in view of Wioka as applied to claims 1 and 9 above, and further in view of Favela et al. U.S. Pub. No. 2020/0193703.
Re: claims 7 and 15 (which are rejected under the same rationale), Li and Wioka teach
7. (Original) The method of claim 1, wherein receiving the set of primitives comprises receiving one or more of a group that includes geometry data associated with the set of primitives, geometry state data associated with the scene, or pixel state data. (“In some instances, the primitive definitions may be provided to GPU 12 in the form of a list of drawing primitives, e.g., triangles, rectangles, triangle fans, triangle strips, etc... Based on the instructions issued by software application 24 to GPU driver 7, GPU driver 7 may formulate one or more commands that specify one or more operations for GPU 12 to perform in order to render the primitive”; Li, [0050])
Primitive definitions are provided to the GPU, which includes the graphics pipeline (shader engine), where the primitive definitions include triangles, triangle fans and triangle strips (a geometry data associated with the set of primitives, geometry state data associated with the scene, or pixel state data). Li and Wioka are silent regarding receiving geometry state data associated with the scene, however, Favela teaches this limitation.
(“Figs. 1-4 disclose systems and techniques to improve the efficiency of graphics processing pipelines... a method of deferred vertex attributes shading includes computing, at a graphics processing pipeline of a graphics processing unit (GPU), a plurality of vertex attributes for vertices of each primitive... of a set of primitives. Geometry data includes graphics data items which describe geometry to be rendered. For example, the graphics data items represent geometric shapes, which describe surfaces of structures in the scene and which are referred to as “primitives”... Scenes typically contain many objects, with objects are composed of one or more such primitives (e.g., objects can be composed of many thousands, or even millions of such primitives.”; Favela, [0008])
The graphics processing pipeline (shader engine) receives vertices of each primitive of the set of primitives (geometry data associated with the set of primitives). The primitives include graphics data which describe the geometry (geometry data associated with the set of primitives) to be rendered such as, for example, surfaces of structures in a scene (geometry state data associated with the scene) (receiving one or more of a group that includes geometry data associated with the set of primitives, geometry state data associated with the scene, or pixel state data). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of the method is performed by a processor core comprising the shader engine, in order to reduce unnecessary graphics processing operations and improve efficiency of the graphics processing pipeline, as taught by Favela ([0008]).
Re: claim 8, Li and Wioka are silent regarding the method is performed by a processor core comprising the shader engine, however, Favela teaches
8. (Currently Amended) The method of claim 1, wherein the method is performed by a processor core comprising the shader engine. (“Some embodiments of the APD 104 are used to implement a GPU and, in that case, the processing cores 122 are referred to as shader cores or streaming multi-processors (SMX).”; Favela, [0018])
Fig. 1 illustrates that the accelerated processing device (APD) 104 includes processing cores 122, which are shader cores (shader engine). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Li by adding the feature of the method is performed by a processor core comprising the shader engine, in order to perform some graphics pipeline operations, such as pixel processing, in parallel, as taught by Favela ([0022]).
Response to Arguments
Appellant’s arguments filed 7/09/2026 have been fully considered but they are not persuasive. Appellant argues:
“Favela itself clearly does not consider its stages 302 to be "a shader engine." Rather, Favela describes stages 302 as "a plurality of deferred attribute shading stages" that "includes a vertex execution mask stage 304, a vertex fetch stage 306, a position calculation stage 308, a non-deferred parameter calculations stage 310, a primitive execution mask stage 312, a geometry shader operations stage 314, a culling stage 316, and a deferred parameter calculations stage 318." (Favela at [0042].) Favela further states that these distinct stages "are implemented partially or fully as shader programs that execute at the processing cores 122 of Fig. I." (Id at [0041].) It is the "processing cores 122" - not stages 302 - that Favela identifies as "shader cores or streaming multi-processors (SMX)." (Id at [0018].) Moreover, rasterization is not among the enumerated stages of Favela's deferred attribute shading stages 302, and Favela does not describe stages 302 as performing rasterization. Rather, Favela describes stages 302 as ending at deferred parameter calculations stage 318, after which computed attribute values are stored to a parameter cache buffer for downstream retrieval. (Favela at [0053].) The Office's attempt to now recharacterize stages 302 as "a shader engine" that rasterizes the identified subset of primitives is contrary to Favela's own description and to the Office's previous acknowledgements of Favela's deficiencies.”
Examiner has considered Appellant’s arguments and new grounds of rejection have been set forth. Li and Wioka teach the limitations of claim 1. Li and Wioka teach “a shader engine.” Li illustrates in Fig. 2, that a GPU that includes a graphics processing pipeline (shader engine) for rendering graphics primitives of a 3D graphic scene. (Li, [0047], Fig. 2). Wioka illustrates in Fig. 2, a rendering pipeline 200 (shader engine) that is implemented in a GPU. (Wioka, col. 6, lines 14-20, Fig. 2). Both Li and Wioka each teach rasterization, which is illustrated in Fig. 2 of both references.
Appellant’s arguments filed 7/09/2026 have been fully considered but they are not persuasive. Appellant argues:
“Zhu fails to remedy the deficiencies of Favela. The Office has cited Zhu as describing a raster/shading engine that processes visible primitives. (Final Office Action at 9-10, citing Zhu at column/lines 15/32-37 and 15/43-50.) But Zhu's raster/shading engine is a hardware unit separate and distinct from the unit that performs the visibility determination. (See Zhu at, e.g., Fig. 4 and column/lines 4/50-55.) Zhu describes a dedicated "scan/z engine" (403) that performs the preliminary visibility determination and a distinct "raster" engine ( 405) that performs the rasterization of the resulting visible fragments. (Id.) Such separation is fundamental to the operations described by Zhu, which states that "the double-z scheme ... decouples the scan conversion/depth-buffer processing [scan/z engine J from the more general rasterization and shading processing [raster engine}." (See, e.g., Zhu at column/lines 3/67-4/10, 12/60-65, and 13/10-25.) Zhu therefore does not disclose rasterization by the same engine that performs culling; instead, it describes a contrary architecture in which visibility determination and rasterization are performed by distinct, disparate engines. The Advisory Action's assertion that "the raster/shading engine of Zhu is included in the deferred attribute shading stages of Favela" (Advisory Action at 2) does not resolve this deficiency - merely importing Zhu's raster/shading engine into Favela does not consolidate culling and rasterization onto a single shader engine, at least because Zhu explicitly indicates that its raster/shading engine is a separate component from its scan/z engine that performs culling.”
Examiner has considered Appellant’s arguments and new grounds of rejection have been set forth. Li and Wioka teach the limitations of claim 1. For example, Li illustrates in Fig. 2, the geometry processing stage of the graphics processing pipeline (shader engine) that performs operations including culling operations. (Li, [0054]). Wioka teaches that the geometry programs executed by the geometry shader of the rendering pipeline (shader engine), include a culling program that applies a visibility test to primitives, where the primitives that satisfy the visibility test are considered “potentially visible” (culling the set of primitives comprises identifying a subset of the primitives that are potentially visible in the scene). (Wioka, col. 7, lines 49-59). Fig. 2 illustrates that the rendering pipeline (shader engine) includes a setup unit that uses the vertices of each primitive it receives (primitives that survived culling / (identified subset of primitives)) to create edge equations for each primitive and plane equations for each primitive, which are then sent to the rasterizer. The rasterizer unit converts each primitive into one or more fragments. (Wioka, col. 8, lines 48-54).
Appellant’s arguments filed 7/09/2026 have been fully considered but they are not persuasive. Appellant argues:
“Nordlund fails to remedy the deficiencies of Favela and Zhu, and actively teaches away from the purposes for which the Office relies upon it. The Office has cited Nordlund as describing "a small primitive processing unit that is considered to be combined with the fragment shader to perform culling, generate attribute values and rasterization." (Final Office Action at 11, citing Nordlund at [0083]-[0084] and Fig. 5.) But Nordlund expressly separates small primitive processing unit 56 from fragment shader 52 and describes them as distinct hardware units performing distinct functions. Nordlund states that "small primitive processing unit 56 may include fixed function hardware to perform clipping or scissoring of the polygon against the pixel boundaries, to perform back face culling ... Small primitive processing unit 56 may also include functionality to perform primitive setup operations to calculate differentials, edge functions, plane equations and/or other data that is used by fragment shader 52 for rasterization of the primitive." (Nordlund at [0083]-[0084].) Nordlund provides the purpose of this separation: "Performing one or more rasterization operations in the dedicated hardware of small primitive processing unit 5 6 may free up resources in fragment shader 5 2 for performing operations that would otherwise be a performance bottleneck for fragment shader 52." (Id at [0084].) That is, the stated purpose of the Office-cited portions of Nordlund is to distribute rasterization-related operations across separate hardware - offloading them from the fragment shader onto a dedicated processing unit - precisely to avoid the resource contention that would occur if a single unit performed all such operations. Nordlund therefore does not disclose a single shader engine that performs culling, attribute generation, and rasterization on the same identified subset of primitives; it teaches distributing those operations across at least two distinct hardware units. For all of these reasons, the proposed Favela, Zhu, and Nordlund combination fails to teach or suggest consolidating primitive culling, attribute generation, and rasterization onto a single shader engine as recited by claim 1. Favela describes deferred attribute shading stages 302 that end before rasterization; Zhu describes an architecture in which the scan/z engine performs culling and a distinct raster engine performs rasterization; and Nordlund describes that rasterization-related operations are offloaded from a fragment shader to a distinct small primitive processing unit. Even if the cited references were combined in the manner suggested by the Office, the resulting system would still teach to distribute the recited operations across disparate hardware units rather than performing them by the same shader engine, as generally recited by independent claim 1.”
Examiner has considered Appellant’s arguments and new grounds of rejection have been set forth. As discussed above, Li and Wioka teach the limitations of claim 1.
Appellant’s arguments filed 7/09/2026 have been fully considered but they are not persuasive. Appellant argues:
“The Office has additionally failed to establish adequate motivation for the proposed modification of Favela. The Office has asserted that one would modify Favela in view of Zhu and Nordlund "in order to provide efficient use of processing capabilities and memory bandwidth through the intelligent management of primitive rendering and memory usage while retaining coherence, as taught by Zhu (col. 5, lines 12-16) and in order to free up resources in the fragment shader to avoid performance bottlenecks, as taught by Nordlund ([0084])." (Final Office Action at 11.) Respectfully, these stated rationales facially motivate a design that distributes work across separate hardware units - not one that consolidates work onto a single shader engine, as generally recited by independent claim 1. The Nordlund rationale is expressly directed to offloading rasterization from the fragment shader to separate hardware (Nordlund at [0084]), and the Zhu rationale is directed to load balancing among the pipeline stages of Zhu's decoupled architecture (Zhu at column/lines 5/12-16). Neither cited rationale would lead one of ordinary skill to consolidate culling, attribute generation, and rasterization onto a single shader engine; both cited rationales would lead one of ordinary skill in the opposite direction. The Office has therefore failed to provide support for its assertion that the proposed modification would have been obvious to one of ordinary skill in the art.
For all of these reasons, Favela, Zhu, and Nordlund do not disclose or render obvious the features of independent claim 1, whether considered individually or in combination. Reversal of the §103 rejection of claim 1 is respectfully requested.”
Examiner has considered Appellant’s arguments and new grounds of rejection have been set forth. Li and Wioka teach the limitations of claim 1.
Appellant’s arguments filed 7/09/2026 have been fully considered but they are not persuasive. Appellant argues:
“Although the language and scope of independent claims 9 and 16 are not identical to those of claim 1, the allowability of those additional independent claims will be readily apparent in view of the discussion above, mutatis mutandis. Claim 9 recites an acceleration unit including "a shader engine coupled to the one or more caches, the shader engine configured to" cull the set of primitives, generate attribute data values for the identified subset, and rasterize the identified subset. Claim 16 recites a non-transitory computer-readable medium embodying instructions to manipulate at least one processor to identify, generate, and rasterize "by the shader engine." Thus, for the reasons set forth above, Favela, Zhu, and Nordlund do not disclose or render obvious the features of independent claims 9 and 16, whether considered individually or in combination. Reversal of the obviousness rejection of those independent claims 9 and 16 is respectfully requested accordingly.”
Examiner has considered Appellant’s arguments and new grounds of rejection have been set forth. Li and Wioka teach the limitations of claims 1, 9 and 16. Please see the corresponding rejections.
Appellant’s arguments filed 7/09/2026 have been fully considered but they are not persuasive. Appellant argues:
“Each of claims 2, 5, 7, 8, 10, 13, 15, 17, and 20 respectively depends from one of independent claims 1, 9, and 16. As explained above, Favela, Zhu, and Nordlund fail to disclose or render obvious the features of those independent claims, whether considered individually or in combination. Accordingly, the cited references, individually and in combination, fail to disclose or render obvious the features of dependent claims 2, 5, 7, 8, 10, 13, 15, 17, and 20 at least by virtue of their respective dependence from claims 1, 9, and 16. In addition, these dependent claims recite additional novel and non-obvious features. Reversal of the§ 103 rejection of claims 2, 5, 7, 8, 10, 13, 15, 17, and 20 is respectfully requested accordingly.”
Examiner has considered Appellant’s arguments and new grounds of rejection have been set forth. Claims 1, 9, 16 and claims 2, 5, 7, 8, 10, 13, 15, 17, and 20 have been rejected. Please see the corresponding rejections.
Appellant’s arguments filed 7/09/2026 have been fully considered but they are not persuasive. Appellant argues:
“Each of claims 3, 4, 11, 12, 18, and 19 respectively depends from one of independent claims 1, 9, and 16. As explained above, Favela, Zhu, and Nordlund fail to disclose or render obvious the features of those independent claims, whether considered individually or in combination. Further, Park does not remedy the discussed deficiencies of Favela, Zhu, and Nordlund, and the Office does not appear to allege that it does so. Accordingly, the cited references, individually and in combination, fail to disclose or render obvious the features of dependent claims 3, 4, 11, 12, 18, and 19 at least by virtue of their respective dependence from claims 1, 9, and 16. In addition, these dependent claims recite additional novel and non-obvious features. Reversal of the§ 103 rejection of claims 3, 4, 11, 12, 18, and 19 is respectfully requested accordingly.”
Examiner has considered Appellant’s arguments and new grounds of rejection have been set forth. Claims 1, 9, 16 and claims 3, 4, 11, 12, 18, and 19 have been rejected. Please see the corresponding rejections.
Appellant’s arguments filed 7/09/2026 have been fully considered but they are not persuasive. Appellant argues:
“Each of claims 6 and 14 respectively depends from one of independent claims 1 and 9. As explained above, Favela, Zhu, and Nordlund fail to disclose or render obvious the features of those independent claims, whether considered individually or in combination. Further, Chung does not remedy the discussed deficiencies of Favela, Zhu, and Nordlund, and the Office does not appear to allege that it does so. Accordingly, the cited references, individually and in combination, fail to disclose or render obvious the features of dependent claims 6 and 14 at least by virtue of their respective dependence from claims 1 and 9. In addition, these dependent claims recite additional novel and non-obvious features. Reversal of the§ 103 rejection of claims 6 and 14 is respectfully requested accordingly.”
Examiner has considered Appellant’s arguments and new grounds of rejection have been set forth. Claims 1, 9 and claims 6 and 14 have been rejected. Please see the corresponding rejections.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONNA J RICKS whose telephone number is (571)270-7532. The examiner can normally be reached on M-F 7:30am-5pm EST (alternate Fridays off).
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, Devona Faulk can be reached on 571-272-7776. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Donna J. Ricks/Examiner, Art Unit 2612
/DEVONA E FAULK/Supervisory Patent Examiner, Art Unit 2618
