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 .
Continued Examination Under 37 CFR 1.114
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/24/2026 has been entered.
Response to Amendment
3. Acknowledgement is made of amendment filed on August 24, 2026, in which claims 1, 10 and 17 are amended, and claims 1-20 are still pending.
Response to Arguments
4. Applicant's arguments, filed on August 24, 2026, with respect to Claims 1-20 have been fully considered and they are not persuasive.
5. With regards to arguments for independent claims 1, 10 and 17, applicants argue that Labbe et al. (US 2019/0371042 A1), Goel et al. (US 2014/0098117 A1) and Gierach et al. (US 2015/0015575 A1) fail to disclose each respective said instance including the respective said primitives that correspond to a single respective one of the polygons; and the first instance, the second instance, and the third instance being consecutive instances of the plurality of instances. The examiner respectfully agrees and moots in view of the new grounds of rejections regarding claims 1, 10 and 17, since in White et al. (US 2019/0325639 A1) teaches (“Within each scene 12 and/or image of application 10, there may be a plurality of instances 14 (up to n, where n is an integer) representing various objects in the scene 12. Each instance 14 may be a logical mesh made up of a plurality of primitives 16 (up to m, where m is an integer) that depict the object in the scene 12 and/or image. Primitives may include, but are not limited to, triangles, quads, polygons, lines, points, a patch in a curved surface scheme, and/or bounding volumes, which might in turn include further primitives.” [0025] “a significant reduction in the memory and bandwidth requirement for both primitive pre-culling and hardware instancing may occur by using a single bit to identify the visibility states of the instances and/or primitives. In addition, all atomic memory operations may be removed, thus, simplifying the complexity of primitive culling. Moreover, copying transforms and obtaining a final count may not be necessary since the GPU may only load transform data for instances which instance visibility bit 28 indicates are visible. As such, the per-instance data compaction step in hardware instance implementations may be removed, also the count of the total number of visible instances this frame.” [0058]) White teaches each instance may be a logical mesh made up of a plurality of primitives that primitives include polygons, which means each individual graphics primitive corresponds to one specific polygon in the logical structure of the model. White also teaches the hardware instancing which processes instances sequentially. Therefore, White teaches the arguments of the limitations for claims 1, 10 and 17 as it is recited.
Claim Rejections - 35 USC § 103
6. 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.
7. 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.
8. 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.
9. Claim(s) 1, 2, 5, 6, 8-10 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goel et al. (US 2014/0098117 A1) in view of Gierach et al. (US 2015/0015575 A1) and White et al. (US 2019/0325639 A1).
10. With reference to claim 1, Goel teaches A method comprising: forming, by a processing device, polygons by tessellating a digital object; defining, by the processing device, a plurality of primitives for each of the polygons; (“This disclosure describes graphics processing unit (GPU)-based techniques for rendering a plurality of primitives that includes at least two different types of primitives during the execution of a single draw call command. This disclosure also describes techniques for rendering a plurality of primitives using tessellation domains of different tessellation domain types during the execution of a single draw call command. As used herein, a primitive may refer to a group of one or more vertices and/or one or more control points that are grouped together and/or connected to define a geometric entity (e.g., point, line, polygon, surface, object, patch, etc.) for rendering by a GPU. A primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering.” [0023] “GPU 12 may, in some instances, be built with a highly-parallel structure that provides more efficient processing of vector operations than CPU 6. For example, GPU 12 may include a plurality of processing elements that are configured to operate on multiple vertices, control points, pixels and/or other data in a parallel manner. The highly parallel nature of GPU 12 may, in some instances, allow GPU 12 to render graphics images (e.g., GUIs and two-dimensional (2D) and/or three-dimensional (3D) graphics scenes) onto display 18 more quickly than rendering the images using CPU 6. In addition, the highly parallel nature of GPU 12 may allow GPU 12 to process certain types of vector and matrix operations for general-purposed computing applications more quickly than CPU 6.” [0062]) Goel also teaches determining, by the processing device, a processing order for a plurality of instances, invoking, by the processing device, the plurality of instances arranged according to the processing order to cause rendering the plurality of primitives in a web browser by a graphics processing unit (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “In examples where indexed-based vertex retrieval is not used, input assembler 54 may retrieve vertices and/or control points from a vertex buffer in the order in which the vertices are indexed. For example, if the vertex buffer includes an ordered sequence of vertex slots, input assembler 54 may retrieve a first vertex from a first vertex slot in the ordered sequence of vertex slots followed by a second vertex from a second vertex slot in the ordered sequence of vertex slots, etc.” [0106] “A primitive type may refer to a type of primitive that is capable of being received and processed by the graphics processing pipeline. For example, the vertices retrieved by input assembler 54 may be grouped into groups of one or more vertices, and each of these groups of vertices may correspond to a primitive. The primitive type data may indicate the type of primitive associated with each of the groups of vertices and/or associated with the individual vertices within the groups of vertices. For example, the primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering. As another example, the primitive type may specify how many control points are to be used to define a respective one of the primitives to be rendered.” [0110]).
PNG
media_image1.png
761
534
media_image1.png
Greyscale
Goel does not explicitly teach the forming including grouping respective said primitives that correspond to respective said polygons together in respective said instances, each respective said instance including the respective said primitives that correspond to a single respective one of the polygons; and a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a Z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order, the first instance, the second instance, and the third instance being consecutive instances of the plurality of instances. This is what Gierach teaches. Gierach teaches a first polygon, a second polygon and a third polygon of the polygons are rendered in a Z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order, (“Various embodiments are generally directed to an apparatus, system and method for spatially sorting a plurality of polygons for a scene for rendering by a graphics processing unit (GPU). As previously discussed, polygons are used to create 3-D objects for displaying on a 2-D surface. Triangles are the most common polygon used to create 3-D meshes of the objects, however, the polygon can also be rectangles, hexagons, or other shapes.” [0013] “Various embodiments are not limited to these examples and the 2-D screen space may be divided into any number of sections and the polygons may be added or appended in any order to ensure that overlapping polygons are not consecutively processed.” [0040] “FIG. 3B illustrates another scene with overlapping polygons. More specifically, polygon B overlaps polygon A. … Now all of the polygons are in the sorted list of polygons and they may be processed by the GPU. Various embodiments, are not limited to above example illustrating overlapping polygons, and any number of polygons may overlap any number of other polygons. FIG. 4 illustrates an exemplary embodiment of a top down view of polygons in scene 405 from a viewpoint 407. As shown in depth sorted list 409, the polygons are ordered A, B, C, D and E from back to front to render polygons with transparency correctly. … the polygons may be sorted from front to back to avoid overdraw when rendering an opaque. As shown depth sorted list 413, the polygons are sorted in the order of E, D, C, B and A for front to back order from the viewpoint 407. However, as similarly discussed above with the back to front order, polygon E overlaps polygon D and polygon B overlaps polygon A. To avoid processing the overlapping polygons consecutively and to maintain the relative order of front to back, the polygons may be processed as shown in spatially sorted list 415. More specifically, the polygons may be processed in the following order, E, B, D, A and C to maintain a front to back order and avoid rendering stalls by processing overlapping polygons consecutively.” [0059-0063]) Gierach teaches that any number of polygons may overlap any number of other polygons, the polygons may be added or appended in any order. Because the disclosed technique is not limited to a particular number or identity of polygons, polygons A-E can be consider any of first, second and third polygon to process. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gierach into Goel, in order to avoid rendering stalls and performance penalties.
The combination of Goel and Gierach does not explicitly teach the forming including grouping respective said primitives that correspond to respective said polygons together in respective said instances, each respective said instance including the respective said primitives that correspond to a single respective one of the polygons; the polygons are rendered consecutively, the first instance, the second instance, and the third instance being consecutive instances of the plurality of instances. This is what White teaches (“Within each scene 12 and/or image of application 10, there may be a plurality of instances 14 (up to n, where n is an integer) representing various objects in the scene 12. Each instance 14 may be a logical mesh made up of a plurality of primitives 16 (up to m, where m is an integer) that depict the object in the scene 12 and/or image. Primitives may include, but are not limited to, triangles, quads, polygons, lines, points, a patch in a curved surface scheme, and/or bounding volumes, which might in turn include further primitives.” [0025] “The rendered primitives 42 may be transmitted for presentation on display 38. Display 38 may present the scene 12 of application 10 with the rendered primitives 42 depicting the visible instances 40 in the scene 12.” [0054] “a significant reduction in the memory and bandwidth requirement for both primitive pre-culling and hardware instancing may occur by using a single bit to identify the visibility states of the instances and/or primitives. In addition, all atomic memory operations may be removed, thus, simplifying the complexity of primitive culling. Moreover, copying transforms and obtaining a final count may not be necessary since the GPU may only load transform data for instances which instance visibility bit 28 indicates are visible. As such, the per-instance data compaction step in hardware instance implementations may be removed, also the count of the total number of visible instances this frame.” [0058]) White teaches each instance may be a logical mesh made up of a plurality of primitives that primitives include polygons, which means each individual graphics primitive corresponds to one specific polygon being group together in the logical structure of the model. White also teaches the hardware instancing which processes instances sequentially. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of White into The combination of Goel and Gierach, in order to maximize hardware rendering efficiency and optimization in the graphics pipeline.
10. With reference to claim 2, Goel teaches the rendering of the plurality of primitives in the web browser is part of rendering the digital object as a vector object. (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “GPU 12 may be configured to perform graphics operations to render one or more graphics primitives to display 18. … GPU 12 may, in some instances, be built with a highly-parallel structure that provides more efficient processing of vector operations than CPU 6. For example, GPU 12 may include a plurality of processing elements that are configured to operate on multiple vertices, control points, pixels and/or other data in a parallel manner. The highly parallel nature of GPU 12 may, in some instances, allow GPU 12 to render graphics images (e.g., GUIs and two-dimensional (2D) and/or three-dimensional (3D) graphics scenes) onto display 18 more quickly than rendering the images using CPU 6. In addition, the highly parallel nature of GPU 12 may allow GPU 12 to process certain types of vector and matrix operations for general-purposed computing applications more quickly than CPU 6.” [0061-0062])
11. With reference to claim 5, Goel teaches the digital object is a Bezier curve or a vector object. (“a primitive may refer to a group of one or more vertices and/or one or more control points that are grouped together and/or connected to define a geometric entity (e.g., point, line, polygon, surface, object, patch, etc.) for rendering by a GPU.” [0023] “GPU 12 may, in some instances, be built with a highly-parallel structure that provides more efficient processing of vector operations than CPU 6. For example, GPU 12 may include a plurality of processing elements that are configured to operate on multiple vertices, control points, pixels and/or other data in a parallel manner. The highly parallel nature of GPU 12 may, in some instances, allow GPU 12 to render graphics images (e.g., GUIs and two-dimensional (2D) and/or three-dimensional (3D) graphics scenes) onto display 18 more quickly than rendering the images using CPU 6. In addition, the highly parallel nature of GPU 12 may allow GPU 12 to process certain types of vector and matrix operations for general-purposed computing applications more quickly than CPU 6.” [0062])
12. With reference to claim 6, Goel teaches the defining defines the plurality of primitives (“This disclosure describes graphics processing unit (GPU)-based techniques for rendering a plurality of primitives that includes at least two different types of primitives during the execution of a single draw call command. This disclosure also describes techniques for rendering a plurality of primitives using tessellation domains of different tessellation domain types during the execution of a single draw call command. As used herein, a primitive may refer to a group of one or more vertices and/or one or more control points that are grouped together and/or connected to define a geometric entity (e.g., point, line, polygon, surface, object, patch, etc.) for rendering by a GPU. A primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering.” [0023]) Goel also teaches using coordinate positions and respective colors in a vertex buffer (“Commands 40 may include one or more state commands and/or one or more draw call commands. A state command may instruct GPU 12 to change one or more of the state variables in GPU 12, such as, e.g., the draw color. A draw call command may instruct GPU 12 to render the geometry defined by a group of one or more vertices 36 (e.g., defined in a vertex buffer) stored in memory 10. The geometry defined by the group of one or more vertices 36 may, in some examples, correspond to a plurality of primitives to be rendered.” [0090] “Input assembler 54 is configured to retrieve a plurality vertices from one or more vertex buffers, and to output the vertices to vertex shader 56 for further processing. The one or more vertex buffers may be stored in a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertices and/or control points may correspond to one or more primitives to be rendered. Each of vertices may include one or more attributes, such as, e.g., positional coordinates, normal coordinates, texture coordinates, etc.” [0103]) Goel further teaches the vertex buffer is accessible to the graphics processing unit. (“the API may allow a user to specify different primitive types for different vertices to be rendered. In some examples, the API may also include instructions and/or data structures that allow a user application to place data indicative of the primitive type for each of the vertices to be processed during a draw call instruction into one or more buffers (e.g., vertex buffers) that are accessible by the GPU. In additional examples, the API may include a state command that instructs the GPU to execute a draw call command based on the data indicative of the primitive type for each of the vertices to be processed.” [0043])
13. With reference to claim 8, Goel teaches the invoking is performed as a batch that includes the plurality of instances using a single draw call. (“input assembler 54 may retrieve a first vertex index corresponding to a first vertex to be retrieved from a vertex buffer, and may retrieve the first vertex from a first location (e.g., a first vertex slot) in the vertex buffer that is identified by the first vertex index. After retrieving the first vertex in this example, input assembler 54 may retrieve a second vertex index corresponding to a second vertex to be retrieved from a vertex buffer, and may retrieve the second vertex from a second location (e.g., a second vertex slot) in the vertex buffer that is identified by the second vertex index. Using indexed rendering may allow out-of-order access to vertices in a vertex buffer (i.e., vertices to be retrieved in a different order than the order in which such vertices were indexed). Using indexed-based vertex retrieval may allow the vertices in a vertex buffer to be accessed in an out-of-order fashion, which may reduce the complexity of vertex buffer generation by a graphics application. In addition, using indexed-based vertex retrieval may allow the same vertex to be retrieved multiple times from a vertex buffer during a single draw call, which may reduce memory footprint requirements for a particular draw call.” [0105] “rasterizer 66 may be configured to select a rasterization technique from a plurality of rasterization techniques based on a rasterization primitive type received from a different processing stage in graphics pipeline 50. For example, rasterizer may 66 select a first rasterization technique from the plurality of rasterization techniques if the rasterization primitive type is a first rasterization primitive type, and select a second rasterization technique from the plurality rasterization techniques if the rasterization primitive type is a second rasterization primitive type. The first rasterization primitive type may be different than the second rasterization primitive type. The first rasterization technique may be the same as or different than the second rasterization technique. Allowing rasterizer 66 to rasterize rasterization primitives of different rasterization primitive types during a single draw call may enable the graphics pipeline to render input primitives that map to different rasterization primitive types during a single draw call.” [0144])
14. With reference to claim 9, Goel teaches the rendering is performed by the graphics processing unit to a frame buffer. (“CPU 6 and/or GPU 12 may store rendered image data in a frame buffer that is allocated within system memory 10. Display interface 16 may retrieve the data from the frame buffer and configure display 18 to display the image represented by the rendered image data. In some examples, display interface 16 may include a digital-to-analog converter (DAC) that is configured to convert the digital values retrieved from the frame buffer into an analog signal consumable by display 18.” [0065] “for each pixel received from rasterizer 66, pixel shader 68 may execute an instance of a pixel shader program on a shader unit of GPU 12. … Output merger 70 may place pixel data received from pixel shader 68 into a render target (e.g., a frame buffer).” [0147-0149])
15. Claim 10 is similar in scope to claim 1, and thus is rejected under similar rationale. Goel additionally teaches A system comprising: a central processing unit configured to perform operations, a graphics processing unit (“This disclosure relates to graphics processing systems, and more particularly, to the rendering of graphics primitives in a graphics processing system.” [0002] “CPU 6 may comprise a general-purpose or a special-purpose processor that controls operation of computing device 2. A user may provide input to computing device 2 to cause CPU 6 to execute one or more software applications. The software applications that execute on CPU 6 may include, for example, an operating system, a word processor application, an email application, a spread sheet application, a media player application, a video game application, a graphical user interface application or another program. … The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18.” [0057-0058]) Goel also teaches a single draw call, and a frame buffer, and a web browser configured to render (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “Allowing rasterizer 66 to rasterize rasterization primitives of different rasterization primitive types during a single draw call may enable the graphics pipeline to render input primitives that map to different rasterization primitive types during a single draw call.” [0144] “for each pixel received from rasterizer 66, pixel shader 68 may execute an instance of a pixel shader program on a shader unit of GPU 12. … Output merger 70 may place pixel data received from pixel shader 68 into a render target (e.g., a frame buffer).” [0147-0149]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
Goel does not explicitly teach the polygons, including the first polygon, the second polygon, and the third polygon in the z order, in a display device. This is what Gierach teaches (“Various embodiments are generally directed to an apparatus, system and method for spatially sorting a plurality of polygons for a scene for rendering by a graphics processing unit (GPU). As previously discussed, polygons are used to create 3-D objects for displaying on a 2-D surface. Triangles are the most common polygon used to create 3-D meshes of the objects, however, the polygon can also be rectangles, hexagons, or other shapes.” [0013] “Various embodiments are not limited to these examples and the 2-D screen space may be divided into any number of sections and the polygons may be added or appended in any order to ensure that overlapping polygons are not consecutively processed.” [0040] “FIG. 3B illustrates another scene with overlapping polygons. More specifically, polygon B overlaps polygon A. … Now all of the polygons are in the sorted list of polygons and they may be processed by the GPU. Various embodiments, are not limited to above example illustrating overlapping polygons, and any number of polygons may overlap any number of other polygons. FIG. 4 illustrates an exemplary embodiment of a top down view of polygons in scene 405 from a viewpoint 407. As shown in depth sorted list 409, the polygons are ordered A, B, C, D and E from back to front to render polygons with transparency correctly. … the polygons may be sorted from front to back to avoid overdraw when rendering an opaque. As shown depth sorted list 413, the polygons are sorted in the order of E, D, C, B and A for front to back order from the viewpoint 407. However, as similarly discussed above with the back to front order, polygon E overlaps polygon D and polygon B overlaps polygon A. To avoid processing the overlapping polygons consecutively and to maintain the relative order of front to back, the polygons may be processed as shown in spatially sorted list 415. More specifically, the polygons may be processed in the following order, E, B, D, A and C to maintain a front to back order and avoid rendering stalls by processing overlapping polygons consecutively.” [0059-0063]) Gierach teaches any number of polygons may overlap any number of other polygons, the polygons may be added or appended in any order, and the polygons A-E can be consider any of first, second and third polygon to process and render. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gierach into Goel, in order to avoid rendering stalls and performance penalties.
16. With reference to claim 16, Goel teaches the determining and the invoking are performed as part of executing a browser by the central processing unit. (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “for each pixel received from rasterizer 66, pixel shader 68 may execute an instance of a pixel shader program on a shader unit of GPU 12. … Output merger 70 may place pixel data received from pixel shader 68 into a render target (e.g., a frame buffer).” [0147-0149]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
17. Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goel et al. (US 2014/0098117 A1), Gierach et al. (US 2015/0015575 A1) and White et al. (US 2019/0325639 A1), as applied to claim 1 above, and further in view of Movshovich et al. (US 2003/0193506 A1).
18. With reference to claim 3, Goel teaches the defining forms for the polygons of the digital object. (“This disclosure describes graphics processing unit (GPU)-based techniques for rendering a plurality of primitives that includes at least two different types of primitives during the execution of a single draw call command. This disclosure also describes techniques for rendering a plurality of primitives using tessellation domains of different tessellation domain types during the execution of a single draw call command. As used herein, a primitive may refer to a group of one or more vertices and/or one or more control points that are grouped together and/or connected to define a geometric entity (e.g., point, line, polygon, surface, object, patch, etc.) for rendering by a GPU. A primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering.” [0023])
The combination of Goel, Gierach and White does not explicitly teach an antialiasing spread. This is what Movshovich teaches (“At the start of the line, new primitives for the line are loaded into the processors 24, via step 62. The primitives are loaded from the internal memory 22 to the processors 24. Thus, primitives which commenced at a previous line and which will contribute to the current line remain in the processors 24. The line is then processed, via step 64. Step 64 may include performing interpolation, texture processing, antialiasing or other operations used in rendering the scene.” [0023]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Movshovich into the combination of Goel, Gierach and White, in order to more efficiently utilize the processors of a computer graphics system.
19. Claim(s) 4 and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goel et al. (US 2014/0098117 A1), Gierach et al. (US 2015/0015575 A1) and White et al. (US 2019/0325639 A1), as applied to claim 1 above, and further in view of Beri et al. (US 2018/0033168 A1).
20. With reference to claim 4, the combination of Goel, Gierach and White does not explicitly teach the defining includes expanding each of the polygons formed as triangles into the plurality of primitives formed as triangles through geometry amplification. This is what Beri teaches (“an expansion module expands the control tiles based on the control tile descriptors. Interior control tiles are forwarded along the graphics pipeline to bypass the anti-aliasing procedure. Each of the curves corresponding to exterior control tiles are anti-aliased, but individual exterior control tiles are treated differently depending on the type of curve. Triangle-shaped control tiles are used below to describe an example of the fourth stage of the anti-aliasing pipeline. The expansion module includes a transformation module and an enlargement module. The transformation module transforms each exterior control triangle into an expanded control polygon that spreads out the pixel coverage for anti-aliasing. In some embodiments, the expanded control polygon is implemented as a rectangle with 90-degree angles to facilitate computation within the GPU.” [0040]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Beri into the combination of Goel, Gierach and White, in order to reduce the jagged appearance.
21. With reference to claim 7, the combination of Goel, Gierach and White does not explicitly teach detecting whether the polygons formed from tessellating the digital object are interior triangles or control triangles of the digital object and wherein the forming is performed for the polygons that are control triangles and not for the polygons that are interior triangles. This is what Beri teaches (“Within the GPU 204, the interior control tiles are forwarded along the graphics rendering pipeline 206 to bypass the anti-aliasing procedure (e.g., interior control tiles can be passed through the geometry shader 214 unchanged). In the fourth stage 310, an expansion module 326 expands the exterior control tiles based on the control tile descriptors. The fourth stage 310 can be implemented in conjunction with (e.g., along with or as part of) the tessellation shader 212 or the geometry shader 214 of the graphics rendering pipeline 206. A triangular control tile is used herein as an example shape for the control tiles to describe operation of the expansion module 326;” [0075] “The example filled Bezier path is substantially a circle. With the circle 402 on the left, the fill has been omitted to reveal an example tessellation of the circle into numerous control triangles. Any of many known tessellation algorithms may be employed to tessellate a filled Bezier path. For example, Vatti's algorithm may be used to realize a tessellation engine that produces two kinds of triangles—those that are located in the interior of the Bezier path and those that are located along the exterior. As shown, the interior control triangles are white, and the exterior control triangles are shaded light grey.” [0080]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Beri into the combination of Goel, Gierach and White, in order to reduce the jagged appearance.
22. Claim(s) 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goel et al. (US 2014/0098117 A1) n view of Movshovich et al. (US 2003/0193506 A1), Gierach et al. (US 2015/0015575 A1) and White et al. (US 2019/0325639 A1).
23. With reference to claim 17, Goel teaches One or more computer-readable storage media storing instructions that, responsive to execution by a processing device, causes the processing device to perform operations (“The techniques described in this disclosure may also be stored, embodied or encoded in a computer-readable medium, such as a computer-readable storage medium that stores instructions. Instructions embedded or encoded in a computer-readable medium may cause one or more processors to perform the techniques described herein, e.g., when the instructions are executed by the one or more processors.” [0224]) Goel also teaches forming polygons by tessellating a vector object for rendering the vector object in a web browser; defining a plurality of primitives for each of the polygons; (“This disclosure describes graphics processing unit (GPU)-based techniques for rendering a plurality of primitives that includes at least two different types of primitives during the execution of a single draw call command. This disclosure also describes techniques for rendering a plurality of primitives using tessellation domains of different tessellation domain types during the execution of a single draw call command. As used herein, a primitive may refer to a group of one or more vertices and/or one or more control points that are grouped together and/or connected to define a geometric entity (e.g., point, line, polygon, surface, object, patch, etc.) for rendering by a GPU. A primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering.” [0023] “The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “GPU 12 may, in some instances, be built with a highly-parallel structure that provides more efficient processing of vector operations than CPU 6. For example, GPU 12 may include a plurality of processing elements that are configured to operate on multiple vertices, control points, pixels and/or other data in a parallel manner. The highly parallel nature of GPU 12 may, in some instances, allow GPU 12 to render graphics images (e.g., GUIs and two-dimensional (2D) and/or three-dimensional (3D) graphics scenes) onto display 18 more quickly than rendering the images using CPU 6. In addition, the highly parallel nature of GPU 12 may allow GPU 12 to process certain types of vector and matrix operations for general-purposed computing applications more quickly than CPU 6.” [0062]) Goel also teaches determining a processing order of a plurality of instances; and invoking a single draw call to a graphics processing unit to render the vector object, the single draw call including the plurality of instances arranged according to the processing order, (“GPU 12 may, in some instances, be built with a highly-parallel structure that provides more efficient processing of vector operations than CPU 6. For example, GPU 12 may include a plurality of processing elements that are configured to operate on multiple vertices, control points, pixels and/or other data in a parallel manner. The highly parallel nature of GPU 12 may, in some instances, allow GPU 12 to render graphics images (e.g., GUIs and two-dimensional (2D) and/or three-dimensional (3D) graphics scenes) onto display 18 more quickly than rendering the images using CPU 6. In addition, the highly parallel nature of GPU 12 may allow GPU 12 to process certain types of vector and matrix operations for general-purposed computing applications more quickly than CPU 6.” [0062] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “In examples where indexed-based vertex retrieval is not used, input assembler 54 may retrieve vertices and/or control points from a vertex buffer in the order in which the vertices are indexed. For example, if the vertex buffer includes an ordered sequence of vertex slots, input assembler 54 may retrieve a first vertex from a first vertex slot in the ordered sequence of vertex slots followed by a second vertex from a second vertex slot in the ordered sequence of vertex slots, etc.” [0106] “A primitive type may refer to a type of primitive that is capable of being received and processed by the graphics processing pipeline. For example, the vertices retrieved by input assembler 54 may be grouped into groups of one or more vertices, and each of these groups of vertices may correspond to a primitive. The primitive type data may indicate the type of primitive associated with each of the groups of vertices and/or associated with the individual vertices within the groups of vertices. For example, the primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering. As another example, the primitive type may specify how many control points are to be used to define a respective one of the primitives to be rendered.” [0110] “Allowing rasterizer 66 to rasterize rasterization primitives of different rasterization primitive types during a single draw call may enable the graphics pipeline to render input primitives that map to different rasterization primitive types during a single draw call.” [0144] “for each pixel received from rasterizer 66, pixel shader 68 may execute an instance of a pixel shader program on a shader unit of GPU 12. … Output merger 70 may place pixel data received from pixel shader 68 into a render target (e.g., a frame buffer).” [0147-0149])
PNG
media_image1.png
761
534
media_image1.png
Greyscale
Goel does not explicitly teach generating an antialiasing spread; grouping said primitives together in respective instances; each respective said instance including the respective said primitives that correspond to a single respective one of the polygons; a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order, the first instance, the second instance, and the third instance being consecutive instances of the plurality of instances. This is what Movshovich teaches. Movshovich teaches generating an antialiasing spread; (“At the start of the line, new primitives for the line are loaded into the processors 24, via step 62. The primitives are loaded from the internal memory 22 to the processors 24. Thus, primitives which commenced at a previous line and which will contribute to the current line remain in the processors 24. The line is then processed, via step 64. Step 64 may include performing interpolation, texture processing, antialiasing or other operations used in rendering the scene.” [0023]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Movshovich into the combination of Labbe and Goel, in order to more efficiently utilize the processors of a computer graphics system.
The combination of Goel and Movshovich does not explicitly teach grouping said primitives together in respective instances; each respective said instance including the respective said primitives that correspond to a single respective one of the polygons; a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order, the first instance, the second instance, and the third instance being consecutive instances of the plurality of instances. This is what Gierach teaches. Gierach teaches a first polygon, a second polygon and a third polygon of the polygons are rendered in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order, (“Various embodiments are generally directed to an apparatus, system and method for spatially sorting a plurality of polygons for a scene for rendering by a graphics processing unit (GPU). As previously discussed, polygons are used to create 3-D objects for displaying on a 2-D surface. Triangles are the most common polygon used to create 3-D meshes of the objects, however, the polygon can also be rectangles, hexagons, or other shapes.” [0013] “Various embodiments are not limited to these examples and the 2-D screen space may be divided into any number of sections and the polygons may be added or appended in any order to ensure that overlapping polygons are not consecutively processed.” [0040] “FIG. 3B illustrates another scene with overlapping polygons. More specifically, polygon B overlaps polygon A. … Now all of the polygons are in the sorted list of polygons and they may be processed by the GPU. Various embodiments, are not limited to above example illustrating overlapping polygons, and any number of polygons may overlap any number of other polygons. FIG. 4 illustrates an exemplary embodiment of a top down view of polygons in scene 405 from a viewpoint 407. As shown in depth sorted list 409, the polygons are ordered A, B, C, D and E from back to front to render polygons with transparency correctly. … the polygons may be sorted from front to back to avoid overdraw when rendering an opaque. As shown depth sorted list 413, the polygons are sorted in the order of E, D, C, B and A for front to back order from the viewpoint 407. However, as similarly discussed above with the back to front order, polygon E overlaps polygon D and polygon B overlaps polygon A. To avoid processing the overlapping polygons consecutively and to maintain the relative order of front to back, the polygons may be processed as shown in spatially sorted list 415. More specifically, the polygons may be processed in the following order, E, B, D, A and C to maintain a front to back order and avoid rendering stalls by processing overlapping polygons consecutively.” [0059-0063]) Gierach teaches that any number of polygons may overlap any number of other polygons, the polygons may be added or appended in any order. Because the disclosed technique is not limited to a particular number or identity of polygons, polygons A-E can be consider any of first, second and third polygon to process. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gierach into the combination of Goel and Movshovich, in order to avoid rendering stalls and performance penalties.
The combination of Goel, Movshovich and Gierach does not explicitly teach grouping said primitives together in respective instances; each respective said instance including the respective said primitives that correspond to a single respective one of the polygons; the polygons are rendered consecutively, the first instance, the second instance, and the third instance being consecutive instances of the plurality of instances. This is what White teaches (“Within each scene 12 and/or image of application 10, there may be a plurality of instances 14 (up to n, where n is an integer) representing various objects in the scene 12. Each instance 14 may be a logical mesh made up of a plurality of primitives 16 (up to m, where m is an integer) that depict the object in the scene 12 and/or image. Primitives may include, but are not limited to, triangles, quads, polygons, lines, points, a patch in a curved surface scheme, and/or bounding volumes, which might in turn include further primitives.” [0025] “The rendered primitives 42 may be transmitted for presentation on display 38. Display 38 may present the scene 12 of application 10 with the rendered primitives 42 depicting the visible instances 40 in the scene 12.” [0054] “a significant reduction in the memory and bandwidth requirement for both primitive pre-culling and hardware instancing may occur by using a single bit to identify the visibility states of the instances and/or primitives. In addition, all atomic memory operations may be removed, thus, simplifying the complexity of primitive culling. Moreover, copying transforms and obtaining a final count may not be necessary since the GPU may only load transform data for instances which instance visibility bit 28 indicates are visible. As such, the per-instance data compaction step in hardware instance implementations may be removed, also the count of the total number of visible instances this frame.” [0058]) White teaches each instance may be a logical mesh made up of a plurality of primitives that primitives include polygons, which means each individual graphics primitive corresponds to one specific polygon being group together in the logical structure of the model. White also teaches the hardware instancing which processes instances sequentially. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of White into The combination of Goel, Movshovich and Gierach, in order to maximize hardware rendering efficiency and optimization in the graphics pipeline.
24. With reference to claim 18, Goel teaches the determining and the invoking are performed as part of executing a browser by the central processing unit. (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “for each pixel received from rasterizer 66, pixel shader 68 may execute an instance of a pixel shader program on a shader unit of GPU 12. … Output merger 70 may place pixel data received from pixel shader 68 into a render target (e.g., a frame buffer).” [0147-0149])
25. With reference to claim 19, Goel teaches the central processing unit is further configured to perform operations including forming the respective polygons by tessellating a digital object and defining the primitives for each of the respective polygons. (“This disclosure describes graphics processing unit (GPU)-based techniques for rendering a plurality of primitives that includes at least two different types of primitives during the execution of a single draw call command. This disclosure also describes techniques for rendering a plurality of primitives using tessellation domains of different tessellation domain types during the execution of a single draw call command. As used herein, a primitive may refer to a group of one or more vertices and/or one or more control points that are grouped together and/or connected to define a geometric entity (e.g., point, line, polygon, surface, object, patch, etc.) for rendering by a GPU. A primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering.” [0023] “The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18.” [0058])
26. With reference to claim 20, Goel teaches the defining forms for the respective polygons of the digital object. (“This disclosure describes graphics processing unit (GPU)-based techniques for rendering a plurality of primitives that includes at least two different types of primitives during the execution of a single draw call command. This disclosure also describes techniques for rendering a plurality of primitives using tessellation domains of different tessellation domain types during the execution of a single draw call command. As used herein, a primitive may refer to a group of one or more vertices and/or one or more control points that are grouped together and/or connected to define a geometric entity (e.g., point, line, polygon, surface, object, patch, etc.) for rendering by a GPU. A primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering.” [0023])
Goel does not explicitly teach an antialiasing spread. This is what Movshovich teaches (“At the start of the line, new primitives for the line are loaded into the processors 24, via step 62. The primitives are loaded from the internal memory 22 to the processors 24. Thus, primitives which commenced at a previous line and which will contribute to the current line remain in the processors 24. The line is then processed, via step 64. Step 64 may include performing interpolation, texture processing, antialiasing or other operations used in rendering the scene.” [0023]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Movshovich into Goel, in order to more efficiently utilize the processors of a computer graphics system.
Conclusion
27. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Michelle Chin whose telephone number is (571)270-3697. The examiner can normally be reached on Monday-Friday 8:00 AM-4:30 PM.
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:/Awww.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Kent Chang can be reached on (571)272-7667. 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:/Awww.uspto.gov/patents/apply/patent- center for more information about Patent Center and https:/Awww.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.
/MICHELLE CHIN/
Primary Examiner, Art Unit 2614
Prosecution Insights