CTNF 18/911,166 CTNF 86157 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Rejections - 35 USC § 101 Claim(s) 20 is/are rejected under 35 U.S.C 101 because the claimed invention is directed to non-statutory subject matter as follows: Claim 20 recites, “computer-readable medium”. Although, the specification in [0028] discloses, “Computer-readable media includes computer storage media. Storage media may be any available media that may be accessed by a *computer. By way of example, and not limitation, such computer-readable media may comprise a random access memory (RAM), a read-only memory (ROM), an electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that may be used to store computer executable code in the form of instructions or data structures that may be accessed by a computer", the specification does not limit the claimed storage medium to a non-transitory tangible statutory medium storing the program. The broadest reasonable interpretation of a claim drawn to a computer readable medium or a storage medium, typically covers forms of non-transitory, tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of memory. A transitory, propagating signal is not a process, machine, manufacture, or composition of matter. Those four categories define the explicit scope and reach of subject matter patentable under 35 U.S.C. 101; thus, such a signal cannot be patentable subject matter. Because the full scope of the claim as properly read in light of the disclosure appears to encompass non-statutory subject matter the claim as a whole is non-statutory. Claim Rejections - 35 USC § 102 07-06 AIA 15-10-15 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. 07-07-aia AIA 07-07 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – 07-08-aia AIA (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. 07-12-aia AIA (a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention. 07-15-aia AIA Claim(s) 1, 19, 20; 5, 6, 7, 12, 15 and 18 is/are rejected under 35 U.S.C. 102 (a)(1) and 102(a)(2) as being anticipated by Gruber U.S. Pub. No. 2020/0098165 . Re: claims 1 and 19 (which are rejected under the same rationale), Gruber teaches 1. An apparatus for graphics processing, comprising: at least one memory; and at least one processor coupled to the at least one memory and, based at least in part on information stored in the at least one memory, the at least one processor, individually or in any combination, is configured to: ( ” In the example of FIG. 1A, the display processing pipeline 102 includes a first processing unit 104, a second processing unit 106, and a third processing unit 108... the first processing unit 104 may be a CPU, the second processing unit 106 may be a GPU, or a GPGPU, and the third processing unit 108 may be a display processing unit... ” ; Gruber, [0030], Fig. 1A) Fig. 1A illustrates second processing unit 106, which is a GPU. The GPU includes an internal memory 107 (at least one memory) coupled to a graphics processing pipeline 111 (at least one processor). ( ” In examples where the techniques described herein are implemented partially in software, the software (instructions, code, or the like) may be stored in a suitable, non-transitory computer-readable storage medium accessible by the processing unit. The processing unit may execute the software in hardware using one or more processors to perform the techniques of this disclosure. ” ; Gruber, [0063]) The computer readable storage medium (memory) stores instructions or code, which are executed by the processing unit. obtain an indication of a scene including a plurality of primitives, wherein each of the plurality of primitives includes a set of vertices; ( ”Tile-based rendering generally includes two passes: a binning pass and a rendering pass. During the binning pass, the second processing unit 106 may be configured to receive and process draw commands for a particular scene in preparation for rendering the scene into a frame. A draw command may include one or more primitives. A primitive may have one or more vertices.” ; Gruber, [0042], Fig. 1A) During the binning pass, the second processing unit (GPU) receives draw commands for a scene (obtain an indication of a scene). The draw commands for the scene include primitives (indication of a scene include a plurality of primitives), which each include one or more vertices (each of the plurality of primitives includes a set of vertices). determine position data for each vertex in the set of vertices for each of the plurality of primitives; ( ” The second processing unit 106 may be configured to generate position data (e.g., coordinate data, such as three-axis (X, Y, Z) coordinate data) in screen space for each vertex of each primitive in the draw commands for a particular scene. ” ; Gruber, [0042]) The second processing unit (GPU) generates position data (determines position data), such as coordinate data for each vertex of each primitive in the draw command (for each vertex in the set of vertices for each of the plurality of primitives). and store, or refrain from storing, the position data for each vertex in the set of vertices for each of the plurality of primitives based on an execution cycle associated with the position data. ( ” In this way, the second processing unit 106 may render the scene by dividing the scene into bins that can be individually rendered into the internal memory 107, store each rendered bin from internal memory 107 to a framebuffer (which may be located in the memory 110), and repeat the rendering and storing for each bin of the scene... Rendering a bin into the internal memory 107 may include executing commands to render the primitives in the associated bin into the internal memory 107. ” ; Gruber, [0039]) The second processing unit (GPU) renders the scene by dividing the scene into bins and individually rendering each bin into the internal memory 107. Rendering each bin into internal memory includes rendering the primitives in each bin into the internal memory. ( ” Tile-based rendering generally includes two passes: a binning pass and a rendering pass. During the binning pass, the second processing unit 106 may be configured to receive and process draw commands for a particular scene in preparation for rendering the scene into a frame. A draw command may include one or more primitives. A primitive may have one or more vertices. The second processing unit 106 may be configured to generate position data (e.g., coordinate data, such as three-axis (X, Y, Z) coordinate data) in screen space for each vertex of each primitive in the draw commands for a particular scene. During the binning pass, the second processing unit 106 may be configured to divide a buffer into which a frame is to be rendered into a plurality bins. In some examples, the second processing unit 106 may be configured to generate visibility information for each bin of the plurality of bins during the binning pass. In this regard, it is understood that the second processing unit 106 may be configured to generate visibility information on a per bin basis (e.g., visibility information is generated for each bin). ” ; Gruber, [0042 ]) During the binning pass (execution cycle), the second processing unit (GPU receives draw commands for a scene that include primitives having plural vertices, where position data is generated for each vertex of each primitive. During the binning pass, a buffer, into which a frame is to be rendered, is divided into a plurality of bins, where each of the bins include primitives the scene and where, the each primitives include vertex position data. During the binning pass, the GPU generates visibility information for each bin. ( ” After generating visibility information for each bin (e.g., during the binning pass), the second processing unit 106 may be configured to separately render each respective bin of the plurality of bins using the respective visibility information for each respective bin. In some examples, the second processing unit 106 may be configured to use the visibility stream generated during the binning pass to refrain from rendering primitives identified as invisible during the binning pass, which avoids overdraw. Accordingly, only the visible primitives and/or the possibly visible primitives are rendered into each bin. ” ; Gruber, [0043]) After generating the visibility information, the GPU separately renders each bin, to internal memory (store the position data for each vertex in the set of vertices for each of the plurality of primitives based on an execution cycle associated with the position data), using the respective visibility information for each bin. The visibility information is also used to refrain from rendering primitives, to the internal memory (refrain from storing the position data for each vertex in the set of vertices for each of the plurality of primitives based on an execution cycle associated with the position data), identified as invisible, during the binning process. When the bins are rendered, into the internal memory, each bin includes its corresponding primitives and the vertex position data (the position data for each vertex in the set of vertices for each of the plurality of primitives based on an execution cycle associated with the position data). In this case the execution cycle is the binning pass. ( ” As used herein, “visibility information” may, in some examples, refer to any information in any data structure that indicates whether one or more primitives is visible and/or may be visible (e.g., possibly visible) with respect to the bin for which the visibility information was generated. Whether a primitive is visible/possibly visible or not visible may, as described herein, respectively refer to whether the primitive will be rendered or not rendered with respect to the bin for which the visibility information was generated... In another example, a primitive that “may be visible” (e.g., a possibly visible primitive) may refer to a primitive that is not or will not be definitively visible in the rendered frame (i.e., in the respective rendered bin of the rendered frame) at a particular processing point in the graphics processing pipeline (e.g., during the binning pass before the rendering pass). ” ; Gruber, [0045]) Visibility information indicates whether one or more primitives is visible with respect to the bin for which the visibility information was generated. Whether the primitive is visible or not determines whether the primitive will be rendered (into the internal memory) or not rendered, with respect to the corresponding bin (store, or refrain from storing, the position data for each vertex in the set of vertices for each of the plurality of primitives based on an execution cycle associated with the position data . ). When it is determined that a primitive will not be visible in the rendered frame, during a particular processing point, such as the binning pass (execution cycle), it is not rendered (into the internal memory). Claim 20 is a medium analogous to the apparatus of claim 1, is similar in scope and is rejected under the same rationale. Claim 20 has an additional limitation. Re: claim 20, Gruber teaches 20. A computer-readable medium storing computer executable code for graphics processing, the code when executed by at least one processor causes the at least one processor to: ( ” In examples where the techniques described herein are implemented partially in software, the software (instructions, code, or the like) may be stored in a suitable, non-transitory computer-readable storage medium accessible by the processing unit. The processing unit may execute the software in hardware using one or more processors to perform the techniques of this disclosure. ” ; Gruber, [0063]) A non-transitory computer readable storage medium stores instructions or code, which is executed by the processing unit to cause the processing unit to perform techniques of the disclosure. Re: claim 5, Gruber teaches 5. The apparatus of claim 1, wherein to store the position data for each vertex in the set of vertices for each of the plurality of primitives, the at least one processor, individually or in any combination, is configured to: store, in a memory at a graphics processing unit (GPU), the position data for each vertex in the set of vertices for each of the plurality of primitives. ( ” In this way, the second processing unit 106 may render the scene by dividing the scene into bins that can be individually rendered into the internal memory 107, store each rendered bin from internal memory 107 to a framebuffer (which may be located in the memory 110), and repeat the rendering and storing for each bin of the scene... Rendering a bin into the internal memory 107 may include executing commands to render the primitives in the associated bin into the internal memory 107. ” ; Gruber, [0039]) The second processing unit (GPU) renders the scene by dividing the scene into bins and individually rendering each bin into the internal memory 107. Rendering each bin into internal memory includes rendering the primitives in each bin into the internal memory. Fig. 1A illustrates that second processing unit includes the internal memory 107 (store, in a memory at a graphics processing unit). ( ” After generating visibility information for each bin (e.g., during the binning pass), the second processing unit 106 may be configured to separately render each respective bin of the plurality of bins using the respective visibility information for each respective bin. In some examples, the second processing unit 106 may be configured to use the visibility stream generated during the binning pass to refrain from rendering primitives identified as invisible during the binning pass, which avoids overdraw. Accordingly, only the visible primitives and/or the possibly visible primitives are rendered into each bin. ” ; Gruber, [0043]) After generating the visibility information, the GPU separately renders each bin, to internal memory (store, in a memory at a graphics processing unit, the position data for each vertex in the set of vertices for each of the plurality of primitives based on an execution cycle associated with the position data), using the respective visibility information for each bin. When the bins are rendered, into the internal memory, each bin includes its corresponding primitives and the vertex position data (the position data for each vertex in the set of vertices for each of the plurality of primitives). Re: claim 6, Gruber teaches 6. The apparatus of claim 5, wherein to store, in the memory at the GPU, the position data for each vertex in the set of vertices for each of the plurality of primitives, the at least one processor, individually or in any combination, is configured to: store, at a graphics memory (GMEM) or a system memory at the GPU, the position data for each vertex in the set of vertices for each of the plurality of primitives. ( ” The second processing unit 106 may include an internal memory 107. In some examples, the internal memory 107 may be referred to as a GMEM. ” ; Gruber, [0031], Fig. 1A) Fig. 1A illustrates that the second processing unit includes an internal memory 107, where the internal memory is a GMEM. ( ” At block 218, the second processing unit 106 may be configured store the generated graphical content (e.g., in the internal memory 107 and/or the memory 110) as described herein. Therefore, block 218 generally represents that rendered graphical content may be stored in one or more memories during rendering. For example, the second processing unit 106 may be configured to use the internal memory 107 and/or the memory 110 to store rendered graphical content. ” ; Gruber, [0072]) The second processing unit (GPU) renders the graphical content to internal memory 107 (graphics memory (GMEM)) and/or the memory 110 (system memory). ( ” The second processing unit 106 may be configured to store (e.g., copy) a rendered bin stored in the internal memory 107 to a memory external to the second processing unit 106, such as memory 110. In some examples, once a bin is fully rendered into the internal memory 107, the second processing unit 106 may be configured to store the fully rendered bin to a memory external to the second processing unit 106. ” ; Gruber, [0044]) ( ” After generating visibility information for each bin (e.g., during the binning pass), the second processing unit 106 may be configured to separately render each respective bin of the plurality of bins using the respective visibility information for each respective bin. In some examples, the second processing unit 106 may be configured to use the visibility stream generated during the binning pass to refrain from rendering primitives identified as invisible during the binning pass, which avoids overdraw. Accordingly, only the visible primitives and/or the possibly visible primitives are rendered into each bin. ” ; Gruber, [0043]) After generating the visibility information, the GPU separately renders each bin, to internal memory (store, at a graphics memory (GMEM) or a system memory at the GPU, the position data for each vertex in the set of vertices for each of the plurality of primitives), using the respective visibility information for each bin. When the bins are rendered, into the internal memory, each bin includes its corresponding primitives and the vertex position data (the position data for each vertex in the set of vertices for each of the plurality of primitives based on an execution cycle associated with the position data). Re: claim 7, Gruber teaches 7. The apparatus of claim 5, wherein to store, in the memory at the GPU, the position data for each vertex in the set of vertices for each of the plurality of primitives, the at least one processor, individually or in any combination, is configured to: store, before or after a depth test at the GPU, the position data for each vertex in the set of vertices for each of the plurality of primitives. ( ” After generating visibility information for each bin (e.g., during the binning pass), the second processing unit 106 may be configured to separately render each respective bin of the plurality of bins using the respective visibility information for each respective bin. In some examples, the second processing unit 106 may be configured to use the visibility stream generated during the binning pass to refrain from rendering primitives identified as invisible during the binning pass, which avoids overdraw. Accordingly, only the visible primitives and/or the possibly visible primitives are rendered into each bin. ” ; Gruber, [0043]) After generating the visibility information (after depth test), the GPU separately renders each bin, to internal memory (store, before or after a depth test at the GPU, the position data for each vertex in the set of vertices for each of the plurality of primitives), using the respective visibility information for each bin. When the bins are rendered, into the internal memory, each bin includes its corresponding primitives and the vertex position data (the position data for each vertex in the set of vertices for each of the plurality of primitives). Re: claim 12, Gruber teaches 12. The apparatus of claim 1, wherein the at least one processor, individually or in any combination, is further configured to: obtain an indication to store, or refrain from storing, the position data for each vertex in the set of vertices for each of the plurality of primitives. ( ” After generating visibility information for each bin (e.g., during the binning pass), the second processing unit 106 may be configured to separately render each respective bin of the plurality of bins using the respective visibility information for each respective bin. In some examples, the second processing unit 106 may be configured to use the visibility stream generated during the binning pass to refrain from rendering primitives identified as invisible during the binning pass, which avoids overdraw. Accordingly, only the visible primitives and/or the possibly visible primitives are rendered into each bin. ” ; Gruber, [0043]) After generating the visibility information (obtain an indication to store, or refrain from storing), the GPU separately renders each bin, to internal memory (store the position data for each vertex in the set of vertices for each of the plurality of primitives), using the respective visibility information (indication) for each bin. The visibility information (indication) is also used to refrain from rendering primitives, to the internal memory (refrain from storing the position data for each vertex in the set of vertices for each of the plurality of primitives), identified as invisible, during the binning process. When the bins are rendered, into the internal memory, each bin includes its corresponding primitives and the vertex position data (the position data for each vertex in the set of vertices for each of the plurality of primitives). Re: claim 15, Gruber teaches 15. The apparatus of claim 1, wherein to determine the position data for each vertex in the set of vertices for each of the plurality of primitives, the at least one processor, individually or in any combination, is configured to: calculate the position data for each vertex in the set of vertices for each of the plurality of primitives. ( ” The second processing unit 106 may be configured to generate position data (e.g., coordinate data, such as three-axis (X, Y, Z) coordinate data) in screen space for each vertex of each primitive in the draw commands for a particular scene. ” ; Gruber, [0042]) The second processing unit (GPU) generates position data (calculate the position data), such as coordinate data for each vertex of each primitive in the draw command (for each vertex in the set of vertices for each of the plurality of primitives). Re: claim 18, Gruber teaches 18. The apparatus of claim 1, wherein the at least one processor, individually or in any combination, is further configured to: output an indication of storage, or refrainment from storage, of the position data for each vertex in the set of vertices for each of the plurality of primitives. ( ” After generating visibility information for each bin (e.g., during the binning pass), the second processing unit 106 may be configured to separately render each respective bin of the plurality of bins using the respective visibility information for each respective bin. In some examples, the second processing unit 106 may be configured to use the visibility stream generated during the binning pass to refrain from rendering primitives identified as invisible during the binning pass, which avoids overdraw. Accordingly, only the visible primitives and/or the possibly visible primitives are rendered into each bin. ” ; Gruber, [0043]) After generating the visibility information (output an indication of storage, or refrainment from storage), the GPU separately renders each bin, to internal memory (output an indication of storage of the position data for each vertex in the set of vertices for each of the plurality of primitives), using the respective visibility information (indication) for each bin. The visibility information (indication) is also used to refrain from rendering primitives, to the internal memory (output an indication of refrainment from storage of the position data for each vertex in the set of vertices for each of the plurality of primitives), identified as invisible, during the binning process. When the bins are rendered, into the internal memory, each bin includes its corresponding primitives and the vertex position data (the position data for each vertex in the set of vertices for each of the plurality of primitives) . Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-23-aia AIA 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. 07-21-aia AIA Claim (s) 2, 4 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gruber U.S. Pub. No. 2020/0098165 . Re: claim 2, Gruber teaches 2. The apparatus of claim 1, wherein to store, or refrain from storing, the position data for each vertex in the set of vertices for each of the plurality of primitives, the at least one processor, individually or in any combination, is configured to: store, based on the execution cycle associated with the position data being less than a threshold, the position data for each vertex in the set of vertices for each of the plurality of primitives. ( ” After generating visibility information for each bin (e.g., during the binning pass), the second processing unit 106 may be configured to separately render each respective bin of the plurality of bins using the respective visibility information for each respective bin. In some examples, the second processing unit 106 may be configured to use the visibility stream generated during the binning pass to refrain from rendering primitives identified as invisible during the binning pass, which avoids overdraw. Accordingly, only the visible primitives and/or the possibly visible primitives are rendered into each bin. ” ; Gruber, [0043] ) After generating the visibility information, the GPU separately renders each bin, to internal memory (store, bases on the execution cycle associated with the position data being less than a threshold, the position data for each vertex in the set of vertices for each of the plurality of primitives), using the respective visibility information for each bin. When the bins are rendered, into the internal memory, each bin includes its corresponding primitives and the vertex position data (the position data for each vertex in the set of vertices for each of the plurality of primitives). In this case the execution cycle is the binning pass. This embodiment is silent regarding the position data being less than a threshold, however, another embodiment Gruber teaches this limitation. ( ” FIG. 4 provides an example 400 rendering of an image. The image may include three triangles 402, 404, and 406. In some examples, the triangles may be drawn in a back to front order, with triangle 406 drawn first, then triangle 404 is drawn second, and then triangle 402 is drawn last. ” ; Gruber, [0079], Fig. 4) Fig. 4 illustrates three triangles drawn in a back to front order. ( ” where the triangles are drawn in the back to front order and the application performs a depth pre-pass, the non-visible portions of triangles 404 and 406 will be culled quickly in the pipeline processes, such that only triangle 402 is fully processed. The first pass of the depth pre-pass may be able to identify the non-visible portions of triangles 404 and 406, such that the non-visible portions may be skipped and are not rendered, which saves processing resources. The first pass may identify the visible portions of triangles 404 and 406... ” ; Gruber, [0080]) Fig. 4 illustrates that when the triangles are drawn in the back to front order and depth pre-pass is performed, the non-visible portions of the triangles 404 and 406 will be culled such that only triangle 402 is fully processed (rendered). The visible portions of the triangles, such as for example, triangle 402, is considered to have position data less than a threshold, which is then rendered to the internal memory of the GPU. 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 first embodiment of the method of Gruber by adding the feature of position data being less than a threshold, in order to save processing resources during the second pass or the color render pass because non-visible portions or triangles do not need to be colored, as taught by Gruber ([0080]). Re: claim 4, Gruber teaches 4. The apparatus of claim 1, wherein to store, or refrain from storing, the position data for each vertex in the set of vertices for each of the plurality of primitives, the at least one processor, individually or in any combination, is configured to: refrain from storing, based on the execution cycle associated with the position data being greater than a threshold, the position data for each vertex in the set of vertices for each of the plurality of primitives. ( ” After generating visibility information for each bin (e.g., during the binning pass), the second processing unit 106 may be configured to separately render each respective bin of the plurality of bins using the respective visibility information for each respective bin. In some examples, the second processing unit 106 may be configured to use the visibility stream generated during the binning pass to refrain from rendering primitives identified as invisible during the binning pass, which avoids overdraw. Accordingly, only the visible primitives and/or the possibly visible primitives are rendered into each bin. ” ; Gruber, [0043] ) After generating the visibility information, the GPU separately renders each bin, to internal memory, using the respective visibility information for each bin. The visibility information is also used to refrain from rendering primitives, to the internal memory (refrain from storing, based on the execution cycle associated with the position data being greater than a threshold, the position data for each vertex in the set of vertices for each of the plurality of primitives), identified as invisible, during the binning process (execution cycle). In this case the execution cycle is the binning pass. This embodiment is silent regarding the position data being greater than a threshold, however, another embodiment Gruber teaches this limitation. ( ” FIG. 4 provides an example 400 rendering of an image. The image may include three triangles 402, 404, and 406. In some examples, the triangles may be drawn in a back to front order, with triangle 406 drawn first, then triangle 404 is drawn second, and then triangle 402 is drawn last. ” ; Gruber, [0079], Fig. 4) Fig. 4 illustrates three triangles drawn in a back to front order. ( ” where the triangles are drawn in the back to front order and the application performs a depth pre-pass, the non-visible portions of triangles 404 and 406 will be culled quickly in the pipeline processes, such that only triangle 402 is fully processed. The first pass of the depth pre-pass may be able to identify the non-visible portions of triangles 404 and 406, such that the non-visible portions may be skipped and are not rendered, which saves processing resources. The first pass may identify the visible portions of triangles 404 and 406... ” ; Gruber, [0080]) Fig. 4 illustrates that when the triangles are drawn in the back to front order and depth pre-pass is performed, the non-visible portions of the triangles 404 and 406 will be culled such that only the visible triangle 402 is fully processed (rendered). The non-visible portions of the triangles, such as for example, triangle 404 and 406, are considered to have position data greater than a threshold, which are then culled (refrain from storing, based on the execution cycle associated with the position data being greater than a threshold, the position data for each vertex in the set of vertices for each of the plurality 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 first embodiment of the method of Gruber by adding the feature of the first embodiment of the method of Gruber, in order to save processing resources during the second pass or the color render pass because non-visible portions or triangles do not need to be colored, as taught by Gruber ([0080]) . 07-22-aia AIA Claim (s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gruber as applied to claim 15 above, and further in view of Oygard GB 2624425 A . Re: claim 16, Gruber teaches 16. The apparatus of claim 15, wherein to calculate the position data for each vertex in the set of vertices for each of the plurality of primitives, the at least one processor, individually or in any combination, is configured to: calculate, during a binning stage at a vertex shader of a graphics processing unit (GPU), the position data for each vertex in the set of vertices for each of the plurality of primitives. ( ” During the binning pass, the second processing unit 106 may be configured to receive and process draw commands for a particular scene in preparation for rendering the scene into a frame. A draw command may include one or more primitives. A primitive may have one or more vertices. The second processing unit 106 may be configured to generate position data (e.g., coordinate data, such as three-axis (X, Y, Z) coordinate data) in screen space for each vertex of each primitive in the draw commands for a particular scene . ” ; Gruber, [0042]) During the binning pass (during a binning stage... of a graphics processing unit (GPU)), the second processing unit (GPU) generates position data (calculate, during the binning stage... of a graphics processing unit (GPU), the position data), such as coordinate data for each vertex of each primitive in the draw command (for each vertex in the set of vertices for each of the plurality of primitives). Gruber is silent regarding calculate, during a binning stage at a vertex shader of a graphics processing unit, however, Oygard teaches this limitation. ( ” Thus, according to the present invention, the (e.g.) vertex positions are preferably obtained and processed as part of an initial filing operation that generates the primitive lists, and the results (i.e. the primitive lists but optionally also the vertex positions themselves) preferably remain available for use during the subsequent (pre-and main passes for the) rendering operations. For example, in some embodiments, vertex position shading is performed during the initial tiling operation, and the shaded vertices may remain available for use during the rendering operations. ” ; Oygard, p. 12, lines 30-37) The vertex positions are obtained and processed as part of an initial tiling operation (calculate, during a binning stage) where vertex position shading is also performed (calculate, during a binning stage at a vertex shader of the graphics processing unit (GPU). Oygard is combined with Gruber such that the generation of coordinate data of Gruber is performed at the vertex shader of Oygard. 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 Gruber by adding the feature of during a binning stage at a vertex shader of a graphics processing unit, in order to avoid generating respective primitive lists twice, as taught by Oygard (p. 12, lines 25-30) . Allowable Subject Matter 12-151-08 AIA 07-43 12-51-08 Claim s 3, 8-11, 13, 14 and 17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. 13-03-01 AIA The following is a statement of reasons for the indication of allowable subject matter: None of the prior art teaches or suggests: From claim 3 – “wherein the threshold is associated with at least one of a time or a power for a storage and a load of the execution cycle associated with the position data.” From claim 8 – “wherein the at least one processor, individually or in any combination, is further configured to: load, based on storage of the position data for each vertex, the position data for each vertex in the set of vertices for each of the plurality of primitives.” Claims 9-11 depend, directly or indirectly, from claim 8 and include all of the limitations of claim 8. from claim 13 – “wherein to obtain the indication to store, or refrain from storing, the position data for each vertex in the set of vertices for each of the plurality of primitives, the at least one processor, individually or in any combination, is configured to: obtain, from a compiler, code for the indication to store, or refrain from storing, the position data for each vertex in the set of vertices for each of the plurality of primitives.” From Re: claim 14 – “ wherein to obtain the indication to store the position data for each vertex in the set of vertices for each of the plurality of primitives, the at least one processor, individually or in any combination, is configured to: obtain an indication of a memory address for storing the position data for each vertex in the set of vertices for each of the plurality of primitives.” From claim 17 – “wherein to obtain the indication of the scene including the plurality of primitives, the at least one processor, individually or in any combination, is configured to: obtain, from a graphics driver, the indication of the scene including the plurality of primitives, wherein each draw call in the set of draw calls includes a draw call size.” 07-43-03 AIA As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a). 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-7515. 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 2618 /DEVONA E FAULK/Supervisory Patent Examiner, Art Unit 2618 Application/Control Number: 18/911,166 Page 2 Art Unit: 2618 Application/Control Number: 18/911,166 Page 3 Art Unit: 2618 Application/Control Number: 18/911,166 Page 4 Art Unit: 2618 Application/Control Number: 18/911,166 Page 5 Art Unit: 2618 Application/Control Number: 18/911,166 Page 6 Art Unit: 2618 Application/Control Number: 18/911,166 Page 7 Art Unit: 2618 Application/Control Number: 18/911,166 Page 8 Art Unit: 2618 Application/Control Number: 18/911,166 Page 9 Art Unit: 2618 Application/Control Number: 18/911,166 Page 10 Art Unit: 2618 Application/Control Number: 18/911,166 Page 11 Art Unit: 2618 Application/Control Number: 18/911,166 Page 12 Art Unit: 2618 Application/Control Number: 18/911,166 Page 13 Art Unit: 2618 Application/Control Number: 18/911,166 Page 14 Art Unit: 2618 Application/Control Number: 18/911,166 Page 15 Art Unit: 2618 Application/Control Number: 18/911,166 Page 16 Art Unit: 2618 Application/Control Number: 18/911,166 Page 17 Art Unit: 2618 Application/Control Number: 18/911,166 Page 18 Art Unit: 2618 Application/Control Number: 18/911,166 Page 19 Art Unit: 2618 Application/Control Number: 18/911,166 Page 20 Art Unit: 2618 Application/Control Number: 18/911,166 Page 21 Art Unit: 2618 Application/Control Number: 18/911,166 Page 22 Art Unit: 2618 Application/Control Number: 18/911,166 Page 23 Art Unit: 2618 Application/Control Number: 18/911,166 Page 24 Art Unit: 2618 Application/Control Number: 18/911,166 Page 25 Art Unit: 2618
Prosecution Insights