Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 7-9, 14-17, 22, 23 are rejected under 35 U.S.C. 103 as being unpatentable over “Deferred shading on mobile: An API overview” by Hans-Kristian Arntzen (hereinafter Arntzen) in view of “Deferred Shading Tutorial” by Fabio Policarpo, et al. (hereinafter Policarpo) in view of “Rendering Techniques in Call of Juarez: Bound in Blood” by Pawel Rohleder, et al. (hereinafter Rohleder).
Regarding claim 1, the limitations “A method for rendering a virtual scene performed by a graphics processing unit (GPU) in a computer device, the method comprising: … performing geometry rendering on the virtual scene including a virtual object at a geometry rendering stage, to obtain a geometry rendering result; … reading the geometry rendering result … at an illumination rendering stage … performing illumination rendering based on light source information and the geometry rendering result, to obtain an illumination rendering result” are taught by Arntzen (Arntzen, e.g. pages 1-24, describes techniques for deferred shading, including a traditional desktop implementation using g-buffers, e.g. pages 2-8, and three techniques for mobile device GPUs having improved memory bandwidth usage by using on-chip storage, e.g. pages 9-23. Arntzen, e.g. pages 2-6, 12-13, 17, 21, teaches that each of the techniques include a geometry rendering stage producing albedo, normal, and metallic roughness results stored in the g-buffer, followed by an illumination stage, e.g. pages 2, 6-8, 13-15. 17-19, 21-23, wherein an illuminated rendered image is resolved based on lighting results determined for each light source using the g-buffer contents. That is, as claimed, the geometry rendering stage performs geometry rendering on the virtual scene to obtain a geometry rendering result, i.e. generating the g-buffers, followed by reading the geometry rendering result an illumination rendering stage, performing illumination rendering based on the light source information and the geometry rendering results, to obtain an illumination rendering result, i.e. using the g-buffers and light source parameters to accumulate the lighting contribution from each light source for each pixel of the output image.)
The limitations “performing geometry rendering on the virtual scene including a virtual object at a geometry rendering stage, to obtain a geometry rendering result … writing the geometry rendering result into the on-chip memory in the GPU … reading the geometry rendering result from the on-chip memory based on an expansion characteristic in which the GPU reads data from the on-chip memory at an illumination rendering stage … performing illumination rendering based on light source information and the geometry rendering result, to obtain an illumination rendering result; and writing the illumination rendering result into … the on-chip memory” are taught by Arntzen (As noted above, Arntzen teaches three techniques for mobile device GPUs having improved memory bandwidth usage by using on-chip storage, e.g. pages 9-23, where each technique relies on a distinct expansion characteristic, e.g. the pixel local storage technique relies on the extension GL_EXT_shader_pixel_local_storage, page 12, and the framebuffer fetch technique relies on the extension GL_EXT_shader_framebuffer_fetch, page 17, where Applicant’s disclosure, e.g. paragraph 130, indicates that one exemplary expansion characteristic is GL_EXT_shader_framebuffer_fetch. Further, Arntzen, e.g. pages 9-10, teaches that one of the advantages of the mobile device GPU techniques is improved memory bandwidth usage by keeping the g-buffer in on-chip memory until the final output framebuffer values are determined, i.e. the geometry stage writes results to the g-buffers stored in on-chip memory, and the illumination stage reads from the g-buffers stored in on-chip memory to perform the illumination processing, where Arntzen, e.g. page 10, teaches that the resulting output framebuffer values are stored on-chip prior to being flushed to main memory, i.e. the illumination/resolve stage outputs are stored on-chip prior to being output for display. Finally, as noted above, each technique relies on a different expansion characteristic controlling how the g-buffer and illumination data are written to/read from the on-chip memory, e.g. the pixel local storage technique provides access to raw tile memory, pages 12-13, whereas the framebuffer fetch technique uses a more traditional rendering setup defining multiple render targets, pages 16-17. Therefore, as claimed, Arntzen’s geometry rendering stage writes the geometry rendering results into an on-chip memory in the GPU, Arntzen’s illumination stage reads the results from the on-chip memory based on the expansion characteristic for the technique being used, and writes the illumination rendering result to the on-chip memory. It is additionally noted with respect to claims 9 and 17, one of ordinary skill the art would recognize that Arntzen’s mobile device GPU techniques are implemented using a computer having a CPU and memory storing instructions executed by the CPU to perform the claimed method.)
The limitations “creating first, second, third and fourth render textures in a geometry buffer of an on-chip memory in the GPU; performing geometry rendering on the virtual scene including a virtual object at a geometry rendering stage, to obtain a geometry rendering result, wherein the geometry rendering result includes a first rendering result and … the first rendering result comprises other rendering information of the virtual object; writing the geometry rendering result into the on-chip memory in the GPU, further including: writing the first result into the first render texture, the second render texture and the third render texture, respectively, wherein the first render texture stores color … information of the virtual object, the second render texture stores normal information of the virtual object, and the third render texture stores … highlight information of the virtual object … reading the geometry rendering result from the on-chip memory based on an expansion characteristic in which the GPU reads data from the on-chip memory at an illumination rendering stage, further including: reading, based on a first expansion characteristic of the GPU, the first rendering result from the first render texture, the second render texture, and the third render texture, respectively; … and writing the illumination rendering result into the fourth render texture in the on-chip memory” are taught by Arntzen (As discussed above, Arntzen, e.g. pages 9-10, teaches that one of the advantages of the mobile device GPU techniques is improved memory bandwidth usage by keeping the g-buffer in on-chip memory until the final output framebuffer values are determined, i.e. the geometry stage writes results to the g-buffers stored in on-chip memory, and the illumination stage reads from the g-buffers stored in on-chip memory to perform the illumination processing, where Arntzen, e.g. page 10, teaches that the resulting output framebuffer values are stored on-chip prior to being flushed to main memory, i.e. the illumination/resolve stage outputs are stored on-chip prior to being output for display. Further, Arntzen’s framebuffer fetch technique, e.g. pages 16-19, stores the g-buffer and illumination rendering results using a plurality of render textures, i.e. the geometry stage rendering results are written to respective render textures for albedo, normal, and metallic roughness, where said render textures making up the g-buffer are read as input to the illumination stage, and the illumination stage writes the resulting illumination values to either the albedo render texture or the framebuffer render texture depending on whether on-chip tone-mapping is performed. It is noted that one of ordinary skill in the art would understand that metallic roughness indicates the amount of scattering of specular light for the virtual object surface, i.e. the claimed highlight information. That is, as claimed, based on the first expansion characteristic indicating the framebuffer fetch technique is being used, Arntzen’s technique creates the geometry buffer (g-buffer) in the on-chip memory by creating first, second, and third render textures for storing the geometry rendering results for color information, i.e. albedo, normal information, and highlight information, i.e. metallic roughness, respectively, Arntzen’s illumination stage reads, based on the GL_EXT_shader_framebuffer_fetch expansion characteristic as discussed above, the data from the first, second, and third render textures in the geometry buffer to determine illumination rendering results, and the illumination rendering results are written to a fourth render texture in the on-chip memory prior to output/display. Arntzen, e.g. page 18, teaches depending on when performing on-tile tone-mapping is not desired, the light render target does not require further resolving, i.e. the light render target which was used to accumulate the illumination rendering result is the fourth render texture distinct from the first three render textures, and would correspond to the resulting framebuffer render target flushed to main memory, analogous to the discussion of the framebuffer on page 10.)
The limitations “wherein the geometry rendering result includes a first rendering result and a second rendering result, and the second rendering result comprises depth information of the virtual object and the first rendering result comprises other rendering information of the virtual object; writing the geometry rendering result into the on-chip memory in the GPU, further including: … writing the second rendering result into a predefined region other than the render textures created in the geometry buffer of the on-chip memory; reading the geometry rendering result from the on-chip memory based on an expansion characteristic in which the GPU reads data from the on-chip memory at an illumination rendering stage, further including: reading, based on a first expansion characteristic of the GPU, the first rendering result from the first render texture, the second render texture, and the third render texture, respectively; and reading, based on a second expansion characteristic of the GPU, the second rendering result from the predefined region other than the multiple render textures in the geometry buffer of the on-chip memory” are taught by Arntzen (Arntzen, e.g. pages 6-8, teaches that the traditional lighting pass uses depth buffer data generated during the g-buffer pass to reconstruct a world position used in computing the lighting contribution, wherein Arntzen, e.g. pages 14-15, 17-18, teaches that the mobile device GPU technique lighting passes also recover depth information generated during the geometry buffer pass, using a depth buffer fetch extension, i.e. GL_ARM_shader_framebuffer_fetch_depth_stencil, and depth buffer fetch function, i.e. depth = gl_LastFragDepthARM. That is, Arntzen’s geometry stage writes the first rendering results, albedo, normal, and metallic roughness, corresponding to the first rendering result comprising rendering information other than depth information, into the g-buffer render targets, and writes the second rendering results, depth information, into a region other than the render texture in the on-chip memory, i.e. the depth buffer, and Arntzen’s illumination stage reads the first rendering results from the g-buffer render targets and reads the second rendering result from the depth buffer using the depth buffer fetch function. Analogous to the above discussion regarding the first expansion characteristic controlling how the render textures are read, the GL_ARM_shader_framebuffer_fetch_depth_stencil corresponds to the claimed second expansion characteristic of the GPU controlling how the depth data is read from the depth buffer.)
The limitation “the third render texture stores spontaneous light and highlight information of the virtual object” is partially taught by Arntzen (As noted above, Arntzen’s framebuffer fetch technique, e.g. pages 16-19, stores the g-buffer and illumination rendering results using a plurality of render textures, i.e. the geometry stage rendering results are written to respective render textures for albedo, normal, and metallic roughness, where one of ordinary skill in the art would understand that metallic roughness indicates the amount of scattering of specular light for the virtual object surface, i.e. the claimed highlight information. Arntzen, e.g. pages 4, 13, teaches that the conventional and pixel local storage techniques include an additional g-buffer/render texture for emissive, where one of ordinary skill in the art would understand that emissive refers to emissive light from the virtual object surface, i.e. light emitted from the virtual object surface in contrast to light reflected off the virtual object surface, corresponding to the claimed spontaneous light information. While one of ordinary skill in the art would understand that Arntzen’s mobile deferred shading system could use the framebuffer fetch technique to implement a deferred shading application having g-buffers/render textures for both spontaneous light, i.e. emissive, information and highlight, i.e. metallic roughness, information, Arntzen does not explicitly address using a single g-buffer/render texture to store two types of g-buffer rendering data, i.e. the claimed third render texture.) However, this limitation is taught by Policarpo (Policarpo, e.g. sections 1-4, describes a deferred shading implementation analogous to Arntzen’s system, i.e. comprising a geometry rendering pass producing g-buffer data for use in subsequent illumination stage rendering passes. Policarpo, e.g. section 3, describes deferred shading, and in particular the geometry stage, section 3.3, which includes generating the depth buffer, e.g. listing 7, line 20, and a material pass filling the g-buffer with lighting attributes and materials, e.g. listing 7, lines 21-22. Further, Policarpo, e.g. section 3.3.2, explains that part of implementing a deferred shading system is selecting a configuration of rendering information that can be represented using a limited number of render textures/targets having a limited set of values, which may include combining two information types into a single render texture/target, i.e. Policarpo’s exemplary configuration, as shown in figure 3, stores two types of light information, 3 channels of specular and 1 channel of shininess, analogous to the metallic roughness parameter in Arntzen’s disclosure. That is, one of ordinary skill in the art would have understood, as taught by Policarpo, that a deferred shading system may be implemented by combining two information types into a single render texture/target, i.e. a design choice depending on the number of render textures/targets supported and the number of different types of information required for a particular deferred shading technique.)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Arntzen’s mobile deferred shading system using Policarpo’s render textures/targets combining two information types because one of ordinary skill in the art would have understood, as taught by Policarpo, that a deferred shading system may be implemented by combining two information types into a single render texture/target, i.e. a design choice depending on the number of render textures/targets supported and the number of different types of information required for a particular deferred shading technique. As noted above, one of ordinary skill in the art would understand that Arntzen’s mobile deferred shading system could use the framebuffer fetch technique to implement a deferred shading application having g-buffers/render textures for both spontaneous light, i.e. emissive, information and highlight, i.e. metallic roughness, information, where one of ordinary skill in the art would have understood, as taught by Policarpo, that the spontaneous light and highlight information could be combined into a single render texture in order to include the required number of different information types into the number of render textures/targets supported, corresponding to the claimed third render texture including both types of information.
The limitation “wherein the first render texture stores color and ambient occlusion information of the virtual object” is partially taught by Arntzen in view of Policarpo (As noted above, Arntzen’s framebuffer fetch technique, e.g. pages 16-19, stores the g-buffer and illumination rendering results using a plurality of render textures, i.e. the geometry stage rendering results are written to respective render textures for albedo, normal, and metallic roughness, where the albedo render texture corresponds to the first render texture storing color information. Further, as discussed above, one of ordinary skill in the art would have understood, as taught by Policarpo, that a deferred shading system may be implemented by combining two information types into a single render texture/target, i.e. a design choice depending on the number of render textures/targets supported and the number of different types of information required for a particular deferred shading technique. While it would have been obvious to combine the albedo/color information in the first texture with an additional information type, i.e. as shown in Policarpo, figure 3, the render texture storing diffuse RGB values, i.e. albedo, has an empty information channel where another information type could be stored, neither Arntzen or Policarpo address including ambient occlusion information in a g-buffer/render texture of a deferred shading system.) However, this limitation is taught by Rohleder (Rohleder, e.g. sections 2.1-2.5, describes implementation of a deferred shading system which includes screen space ambient occlusion (SSAO) effects. Rohleder, e.g. section 2.3 describes the deferred shading operations performed by the system, including generating depth, color, shininess, and normal values analogous to Arntzen and Policarpo, e.g. section 2.3, paragraph 3, followed by calculating an SSAO factor which can be stored in a single channel of an RGBA render texture/target storing other information types in the other channels, i.e. the claimed ambient occlusion information stored in a render texture. Further, one of ordinary skill in the art would understand that SSAO effects improve the quality of rendered images, e.g. Rohleder, section 2.2, paragraph 3, figure 2.2, i.e. one of ordinary skill in the art would be motivated to include Rohleder’s deferred shading compatible SSAO effect to improve the quality of images rendered by Arntzen’s system.)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Arntzen’s mobile deferred shading system, using Policarpo’s render textures/targets combining two information types, to include Rohleder’s deferred shading compatible SSAO effect to improve the quality of images rendered by Arntzen’s system. As noted above with respect to Arntzen’s system implemented in view of Policarpo, it would have been obvious to combine the albedo/color information in the first texture with an additional information type, i.e. as shown in Policarpo, figure 3, the render texture storing diffuse RGB values, i.e. albedo, has an empty information channel where another information type could be stored, such that one of the possible obvious configurations would be combining/storing Rohleder’s single channel SSAO factor in the 4th/empty channel of the render texture storing color/albedo information, corresponding to the claimed first render texture storing color and ambient occlusion information of the virtual object.
Regarding claim 7, the limitation “writing the illumination rendering result stored in the on-chip memory into the main memory” is taught by Arntzen (Arntzen, e.g. page 10, section Eliminate memory requirements, page 12, section Commonalities, pages 18-19, section Resolve pass?, indicates that tile-based GPUs hold their framebuffers on-chip and choose whether the result needs to be flushed to main memory, i.e. the function glInvalidateFramebuffer is used to indicate which render targets should not be flushed to main memory, wherein in the example of pages 18-19, the flushed render target is the light render target when on-tile tone-mapping is not performed, and the flushed render target is the albedo render target when on-tile tone-mapping is performed.)
Regarding claim 8, the limitation “wherein the GPU is a mobile platform GPU, and the on-chip memory is a tile memory” is taught by Arntzen (Arntzen, e.g. pages 1-2, 9-23, teaches the three techniques for mobile device GPUs having improved memory bandwidth usage by using on-chip storage, wherein Arntzen indicates that the GPUs are tile-based architectures, i.e. Arntzen’s GPU is a mobile platform GPU, and the on-chip memory is a tile memory.)
Regarding claim 9, the limitations are similar to those treated in the above rejection(s) and are met by the references as discussed in claim 1 above.
Regarding claim 15, the limitations are similar to those treated in the above rejection(s) and are met by the references as discussed in claim 7 above.
Regarding claim 16, the limitations are similar to those treated in the above rejection(s) and are met by the references as discussed in claim 8 above.
Regarding claim 17, the limitations are similar to those treated in the above rejection(s) and are met by the references as discussed in claim 1 above, except for the limitation requiring that the program code is stored on a non-transitory computer-readable storage medium. It is noted that one of ordinary skill in the art would likely recognize this to be an inherent feature of Arntzen’s system, i.e. Arntzen’s mobile device architecture would require storing the program code on-device for execution by the device CPU/GPU, but in the interest of compact prosecution, it is additionally noted that one of ordinary skill in the art would have found this to be an obvious design/implementation choice, i.e. it is conventional to store program code on a local non-transitory media for execution by a CPU/GPU. Therefore, if it was shown that one of ordinary skill in the art would not recognize that Arntzen’s system inherently relies on program code stored on non-transitory media, it would also have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Arntzen’s system using program code stored on non-transitory media because this a conventional design/implementation choice for mobile device architectures.
Regarding claim 22, the limitations are similar to those treated in the above rejection(s) and are met by the references as discussed in claim 7 above.
Regarding claim 23, the limitations are similar to those treated in the above rejection(s) and are met by the references as discussed in claim 8 above.
Claims 6, 14 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over “Deferred shading on mobile: An API overview” by Hans-Kristian Arntzen (hereinafter Arntzen) in view of “Deferred Shading Tutorial” by Fabio Policarpo, et al. (hereinafter Policarpo) in view of “Rendering Techniques in Call of Juarez: Bound in Blood” by Pawel Rohleder, et al. (hereinafter Rohleder) as applied to claims 1, 9 and 17 above, and further in view of “Clustered Shading: Assigning Lights Using Conservative Rasterization in DirectX 12” by Kevin Ortegren, et al, (hereinafter Ortegren).
Regarding claim 6, the limitations “wherein the performing the geometry rendering on the virtual scene, to obtain a geometry rendering result comprises: performing vertex rendering on the virtual scene by using a first vertex shader, to obtain a first vertex rendering result; and performing fragment rendering by using a first fragment shader based on the first vertex rendering result, to obtain the geometry rendering result, wherein the first fragment shader defines an output variable by using an inout keyword” are partially taught by Arntzen as modified in view of Policarpo in the claim 1 rejection (Arntzen, e.g. pages 4, 12, 13, 17, teaches performing the g-buffer pass, i.e. the geometry rendering on the virtual scene, where the g-buffer output variables correspond to lighting stage input/output variables using the same name, i.e. the output variables of the g-buffer pass are defined using the claimed inout keyword in Arntzen’s framebuffer fetch technique on page 17, specifically the albedo, normal, and metallic roughness are identified using inout keywords. While one of ordinary skill in the art would know, as discussed below in view of Policarpo, that the g-buffer/geometry rendering pass is performed by using a vertex shader producing vertex rendering results processed by a fragment shader outputting the g-buffer data, i.e. one of ordinary skill in the art would know conventional GPU architecture design performs rendering using geometry by providing input geometry/vertex data to a vertex shader stage which outputs transformed vertices used to rasterize the geometry into fragments processed by fragment shaders during a fragment shader stage, Arntzen does not describe these details, and the modification(s) to Arntzen’s system in view of Policarpo in the claim 1 rejection did not address/include these details, and therefore in the interest of compact prosecution, Policarpo is cited for describing these details.) However, this limitation is taught by Policarpo (Policarpo, e.g. section 3, describes deferred shading, and in particular the geometry stage, section 3.3, which includes generating the depth buffer, e.g. listing 7, line 20, and a material pass filling the g-buffer with lighting attributes and materials, e.g. listing 7, lines 21-22, where the material pass is performed using a vertex shader, e.g. section 3.3.2, listing 9, lines 5-19, listing 10, lines 21-40, i.e. as claimed, a first vertex shader is used to perform vertex rendering on the scene to obtain a first vertex rendering result. Further, Policarpo, e.g. section 3.3.2, listings 12, 13, figure 4, teaches that the fragment shader is the function which actually stores the information into the g-buffers, i.e. as claimed, performing fragment rendering using a first fragment shader based on the first vertex rendering result to obtain the geometry rendering result.)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Arntzen’s mobile deferred shading system, using Policarpo’s render textures/targets combining two information types, including Rohleder’s deferred shading compatible SSAO effect, to perform the geometry pass using vertex and fragment shaders as taught by Policarpo because, as noted above, one of ordinary skill in the art would know that the g-buffer/geometry rendering pass is performed by using a vertex shader producing vertex rendering results processed by a fragment shader outputting the g-buffer data, and further because Policarpo teaches implementation details of the geometry rendering pass of the deferred shading technique which are not described by Arntzen, such that one of ordinary skill in the art would be motivated to adapt Policarpo’s geometry rendering pass architecture for implementing Arntzen’s system. In the modified system, as claimed, the geometry rendering pass would comprise performing vertex rendering on the scene using a vertex shader, and processing/writing the results into the g-buffer using a fragment shader operating on the output of the vertex shader. Further, as noted above, Arntzen, e.g. page 17, indicates that the fragment shader uses the same inout keywords, i.e. the albedo, normal, and metallic roughness keywords, as used by the illumination rendering pass.
The limitations “the performing illumination rendering based on light source information and the geometry rendering result, to obtain an illumination rendering result comprises: … performing illumination rendering by using a second fragment shader based on … the geometry rendering result, to obtain the illumination rendering result, wherein the second fragment shader defines an input variable by using the inout keyword” are taught by Arntzen in view of Policarpo (Arntzen, e.g. pages 6-8, 13, 14, 17, 18, teaches that the illumination pass uses the g-buffer/geometry rendering results to perform illumination rendering to obtain the illumination rendering results, as discussed in the claim 1 rejection above. Further, Arntzen, e.g. pages 14, 17, teaches that the lighting pass uses the same inout keywords as the geometry rendering pass, i.e. the albedo, normal, and metallic roughness keywords, i.e. the input variable(s) are defined using the inout keyword(s). Finally, while not explicitly stated by Arntzen, Policarpo, e.g. sections 3.4, 3.4.3, listing 20, teaches that the illumination pass is performed using a fragment shader, i.e. one of ordinary skill in the art would recognize that Arntzen’s system would implement the illumination pass processing of pages 14, 17, using fragment shader(s), i.e. the claimed second fragment shader performing illumination rendering.)
The limitation “the performing illumination rendering based on light source information and the geometry rendering result, to obtain an illumination rendering result comprises: performing, by using a second vertex shader, vertex rendering on a light source bounding volume represented by the light source information, to obtain a second vertex rendering result; performing illumination rendering by using a second fragment shader based on the second vertex rendering result and the geometry rendering result, to obtain the illumination rendering result” is not explicitly taught by Arntzen (Arntzen teaches that the illumination stage evaluates the lighting contribution from a plurality of light sources, e.g. pages 6-8, 14, 17-18, but does not describe details of evaluating light source bounding volumes, using vertex shaders or otherwise. Policarpo, e.g. section 3.4, teaches that dynamic lights and dynamic geometry may require more elaborate representations for texting light volumes having different shapes such as sphere, bounding box, or frustums, but Policarpo opts to rely on a light scissors optimization processed by the CPU rather than the GPU vertex shader, e.g. section 3.4.2, and does not indicate or suggest the use of the GPU vertex shader for evaluating light source bounding volumes.) However, this limitation is taught by Ortegren (Ortegren, e.g. sections 21.1 – 21.5, describes a system for assigning lights to tiles of a tiled shading system using rasterization. Ortegren, e.g. sections 21.2-21.4, describes implementation of the system, which processes light bounding volumes using shell passes, e.g. figure 21.2, performed using vertex shaders and fragment shaders, e.g. figure 21.3, to generate the light linked list mapping cells/clusters to light sources determined to be within each cell/cluster, e.g. figures 21.8, 21.9. Ortegren, e.g. section 21.4, teaches that the shading, i.e. illumination processing, is performed using a pixel shader, i.e. a synonym for fragment shader, by identifying the corresponding cluster having the same x, y, and z position, which in the case of deferred shading would be sampled from the depth buffer, analogous to Arntzen’s illumination passes calculating an illumination contribution from a light source using a sampled depth buffer value, e.g. pages 8, 14, 18, or Policarpo’s illumination pass fragment shader, e.g. listing 20, lines 11-15.)
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Arntzen’s mobile deferred shading system’s geometry pass, using Policarpo’s render textures/targets combining two information types, including Rohleder’s deferred shading compatible SSAO effect, using vertex and fragment shaders as taught by Policarpo, to use Ortegren’s rasterized light tiling in order to support dynamic and complex light sources in Arntzen’s illumination pass, i.e. Policarpo, e.g. section 3.4, indicates that their implemented light scissors technique processed by the CPU cannot handle dynamic and complex lights, which would require a more elaborate organization to operate in real time, and Ortegren, e.g. section 2.5.1, figures 21.12, 21.13, indicates that the system evaluates the lighting and performs shading in less than 1 millisecond in most instances, i.e. operates in real time, thereby motivating one of ordinary skill in the art to include Ortegren’s technique in Arntzen’s system. As noted above, Ortegren, e.g. section 21.4, teaches that the shading, i.e. illumination processing, is performed using a pixel shader, i.e. a synonym for fragment shader, by identifying the corresponding cluster having the same x, y, and z position, which in the case of deferred shading would be sampled from the depth buffer, analogous to Arntzen’s illumination passes calculating an illumination contribution from a light source using a sampled depth buffer value, e.g. pages 8, 14, 18, or Policarpo’s illumination pass fragment shader, e.g. listing 20, lines 11-15, such that the only modification required to include Ortegren’s technique in Arntzen’s system would be to perform the shell and fill passes for each light source using the vertex shader(s) and modify the illumination pass fragment shaders to use the depth buffer sample to identify the corresponding cell/cluster in the light linked list as in Ortegren section 21.4. That is, in Arntzen’s modified system including Ortegren’s technique, during the illumination pass, a second vertex shader would perform vertex rendering on light source bounding volume(s), i.e. Ortegren’s shells, represented by the light source information to obtain second vertex rendering results, i.e. the light linked list, and second fragment shader(s) would perform illumination rendering based on the second vertex rendering results and the geometry rendering results, i.e. the light linked list and g-buffers respectively, corresponding to the claimed second vertex and fragment shader limitations.
Regarding claims 14 and 21, the limitations are similar to those treated in the above rejection(s) and are met by the references as discussed in claim 6 above.
Response to Arguments
Applicant’s arguments, see pages 9-12, filed 4/2/26, with respect to the rejection(s) of claim(s) 1, 6-9, 14-17 under 35 U.S.C. 112(b) and 102(a)(1) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Arntzen, Policarpo, Rohleder, and Ortegren.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT BADER whose telephone number is (571)270-3335. The examiner can normally be reached 11-7 m-f.
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, Tammy Goddard can be reached at 571-272-7773. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ROBERT BADER/Primary Examiner, Art Unit 2611
Prosecution Insights