DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 13, 19, 20, 25, 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stengel et al. (US 20220138988).
Regarding claim 13, Stengel discloses A computer-implemented method for generating graphics video data for a computer game (“[0022] As shown in operation 102, a scene to be rendered is identified at a remote device. In one embodiment, the scene may include a still image, a frame within a video, a frame within a video game, etc. [0037] Also, in one embodiment, the computed global illumination may be used to render the scene at the client device. [0114] Now referring to FIG. 6, FIG. 6 is an example system diagram for a game streaming system 600, in accordance with some embodiments of the present disclosure”), the method comprising:
receiving, from a remote device, first data including image data corresponding to a plurality of pixels of at least one frame of video data of the computer game (fig.8, “[0024] the ray tracing may include tracing a path of light as pixels within an image plane and simulating the effects of its encounters with objects within the scene. [0140] As shown in operation 802, a scene to be rendered is identified. In one embodiment, the scene may include a still image, a frame within a video, a frame within a video game, etc. [0141] Additionally, as shown in operation 804, a light field is computed for the scene utilizing ray tracing. [0143] Further still, as shown in operation 806, the light field is compressed utilizing lossy compression to create compressed light field data for the scene. [0148] as shown in operation 808, the compressed light field data is sent to a client device. In one embodiment, the compressed light field may be sent from the remote device to the client device via one or more wired and/or wireless communication networks (e.g., a wireless internet connection, a cellular communications network, etc.).”).
On the other hand, the above embodiment of Stengel fails to explicitly disclose but another embodiment of Stengel discloses generating, at a user device, second data including color data for a plurality of the pixels; and generating, at the user device, the at least one frame of the video data of the computer game based on the first data and the second data (fig. 9, “[0150] FIG. 9 illustrates a flowchart of a method 900 for receiving and decompressing a light field compressed utilizing a color conversion. [0153] Additionally, as shown in operation 904, the compressed light field data is decompressed, and a color conversion of the decompressed light field data is performed to obtain the light field for the scene. [0154] Further, in one embodiment, the light field may have been previously converted from RGB pixels into YUV pixels. In another embodiment, the decompressed light field may therefore be in a YUV format. In yet another embodiment, the decompressed light field may be converted from the YUV pixels back into RGB pixels. [0155] Further still, as shown in operation 906, global illumination may be performed for the scene, using the light field for the scene. In yet another embodiment, the computed global illumination may be used to render the scene at the client device. [0162] The client device may then render the scene utilizing the computed global illumination values for the scene”. Note that the global illumination is generated based on the light field for the scene, and the light field for the scene is based on the compressed light field).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the above two embodiments of Stengel, to include all limitations of claim 1. That is, combining the steps of the second embodiment to the end of the first embodiment. The motivation/ suggestion would have been to improve a realism of the scene as displayed by the client device and improve a performance of the client device while rendering the scene, and may result in a high-quality, dynamic rendered image with low bandwidth usage (Stengel, [0156]).
Regarding claim(s) 26, it is interpreted and rejected for the same reasons set forth in claim(s) 1.
Regarding claim 20, Stengel discloses A computer-implemented method of generating data for use in generating graphics video data for a computer game (“[0022] As shown in operation 102, a scene to be rendered is identified at a remote device. In one embodiment, the scene may include a still image, a frame within a video, a frame within a video game, etc. [0037] Also, in one embodiment, the computed global illumination may be used to render the scene at the client device. [0114] Now referring to FIG. 6, FIG. 6 is an example system diagram for a game streaming system 600, in accordance with some embodiments of the present disclosure”), the method comprising:
generating, at a server device, first data including image data corresponding to a plurality of pixels of at least one frame of video data of the computer game (fig.6, fig.8, “[0024] the ray tracing may include tracing a path of light as pixels within an image plane and simulating the effects of its encounters with objects within the scene. [0140] As shown in operation 802, a scene to be rendered is identified. In one embodiment, the scene may include a still image, a frame within a video, a frame within a video game, etc. [0141] Additionally, as shown in operation 804, a light field is computed for the scene utilizing ray tracing. [0143] Further still, as shown in operation 806, the light field is compressed utilizing lossy compression to create compressed light field data for the scene. [0148] as shown in operation 808, the compressed light field data is sent to a client device. In one embodiment, the compressed light field may be sent from the remote device to the client device via one or more wired and/or wireless communication networks (e.g., a wireless internet connection, a cellular communications network, etc.).”);
On the other hand, the above embodiment of Stengel fails to explicitly disclose but another embodiment of Stengel discloses wherein the first data is configured to be combined, at a user device, with second data generated at the user device to generate at least one frame of the video data of the computer game, and wherein the second data includes color data for the plurality of pixels (fig. 9, “[0150] FIG. 9 illustrates a flowchart of a method 900 for receiving and decompressing a light field compressed utilizing a color conversion. [0153] Additionally, as shown in operation 904, the compressed light field data is decompressed, and a color conversion of the decompressed light field data is performed to obtain the light field for the scene. [0154] Further, in one embodiment, the light field may have been previously converted from RGB pixels into YUV pixels. In another embodiment, the decompressed light field may therefore be in a YUV format. In yet another embodiment, the decompressed light field may be converted from the YUV pixels back into RGB pixels. [0155] Further still, as shown in operation 906, global illumination may be performed for the scene, using the light field for the scene. In yet another embodiment, the computed global illumination may be used to render the scene at the client device. [0162] The client device may then render the scene utilizing the computed global illumination values for the scene”. Note that the global illumination is generated based on the light field for the scene, and the light field for the scene is based on the compressed light field).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the above two embodiments of Stengel, to include all limitations of claim 1. That is, combining the steps of the second embodiment to the end of the first embodiment. The motivation/ suggestion would have been to improve a realism of the scene as displayed by the client device and improve a performance of the client device while rendering the scene, and may result in a high-quality, dynamic rendered image with low bandwidth usage (Stengel, [0156]).
Regarding claim 19, Stengel discloses The method of claim 13.
Stengel further discloses wherein the second data includes shading data (“[0101] As shown in FIG. 5, the graphics processing pipeline 500 comprises a pipeline architecture that includes a number of stages. The stages include, but are not limited to, a data assembly stage 510, a vertex shading stage 520, a primitive assembly stage 530, a geometry shading stage 540, a viewport scale, cull, and clip (VSCC) stage 550, a rasterization stage 560, a fragment shading stage 570, and a raster operations stage 580. [0102] The data assembly stage 510 receives the input data 501 that specifies vertex data for high-order surfaces, primitives, or the like. The vertex data is then transmitted to the vertex shading stage 520 for processing”).
Regarding claim(s) 25, it is interpreted and rejected for the same reasons set forth in claim(s) 19.
Claim(s) 14, 15, 21, 22, 27, 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stengel et al. (US 20220138988) in view of Varadarajan et al. (US 20220301233 A1).
Regarding claim 14, Stengel discloses The method of claim 13.
On the other hand, Stengel fails to explicitly disclose but Varadarajan discloses wherein the image data represents a ray of light travelling from a feature of a scene represented by the at least one frame of the video data of the computer game to a viewer of the scene (“[0047] Such raster based techniques may be suitable for modern GPUs, and may allow for the real-time or near real-time rendering desired in any interactive application, for example, such as games and the like. [0052] a direct pass through only the identified objects' pixels in the RTM may be performed. Thus, only the identified pixels in the RTM may generate reflection (or transmission) rays (e.g., secondary rays), and the number of secondary rays generated may be further limited by the particular VRS-style parameters in effect for the identified objects' pixels in the RTM. Note that reflectivity may be determined based on an altered reflectivity metric (e.g., a coefficient that is multiplied to a number determined as part of a reflectivity-determining process) for an amount of reflection, as an overall amount of bounces, a ray would experience when it interacts with the object. For example, a relatively higher altered reflectivity metric may cause a relatively higher number of bounces to be determined, whereas a relatively lower altered reflectivity metric may cause a relatively lower number of bounces to be determined.”), and
wherein the first data includes third data representing a number of interactions of the ray with features of the scene prior to travelling to the viewer (“[0023] In an embodiment, the one or more material properties of the at least one object may correspond to a number of bounces a ray would perform when it interacted with the object. [0052] Note that reflectivity may be determined based on an altered reflectivity metric (e.g., a coefficient that is multiplied to a number determined as part of a reflectivity-determining process) for an amount of reflection, as an overall amount of bounces, a ray would experience when it interacts with the object. For example, a relatively higher altered reflectivity metric may cause a relatively higher number of bounces to be determined, whereas a relatively lower altered reflectivity metric may cause a relatively lower number of bounces to be determined.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Varadarajan and Stengel, to include all limitations of claim 14. That is, applying the RTM method of Varadarajan to ray tracing of Stengel. The motivation/ suggestion would have been improved hybrid ray-tracing systems and methods may be provided in which processing power may be reduced and/or a rendering time may be reduced (Varadarajan, [0119]).
Regarding claim 15, Stengel in view of Varadarajan discloses The method of claim 14.
On the other hand, Stengel fails to explicitly disclose but Varadarajan discloses wherein the first data is determined based on a predetermined number of the interactions (“[0012] In an embodiment, a relatively higher maximum number of bounces may be set when the VRS screenspace image data indicates that the subset of pixels is of relatively higher importance, or a relatively lower maximum number of bounces may be set when the VRS screenspace image data indicates that the subset of pixels is of relatively lower importance. [0097] The intersection shader 806, the any-hit shader 808, the miss shader 810, the closest-hit shader 812, the material shader(s) 814, and the ray bounce shader 816 may be invoked to determine a final color/luminance value of the pixel being evaluated.”). The same motivation of claim 14 applies here.
Regarding claim(s) 21, 22, they are interpreted and rejected for the same reasons set forth in claim(s) 14, 15, respectively.
Regarding claim(s) 27, 28, they are interpreted and rejected for the same reasons set forth in claim(s) 14, 15, respectively.
Claim(s) 16-18, 23, 24, 29-31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stengel et al. (US 20220138988) in view of Varadarajan et al. (US 20220301233 A1), and further in view of McCombe et al. (US 20090128562).
Regarding claim 16, Stengel in view of Varadarajan discloses The method of claim 14.
On the other hand, Stengel in view of Varadarajan fails to explicitly disclose but McCombe discloses wherein the first data includes fourth data representing a weighting factor of a respective interaction of the number of interactions (“[0202] The existence of such a situation is determined by a shader for primitive 1815, which, in these exemplary aspects, generates child rays for each indicated situation (e.g., reflection and refraction) and also records a strength or importance of each such situation as a weight in the respective child rays”. Especially, each child ray indicates a respective interaction, thus the weight of each child ray corresponds to a weight of the respective interaction).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined McCombe into the combination of Varadarajan and Stengel, to include all limitations of claim 16. That is, applying the weight based on importance for each child ray of McCombe to respective interaction of Varadarajan and Stengel. The motivation/ suggestion would have been intelligent real-time adaptation of ray tracing can be implemented using the weights (McCombe, [0202]).
Regarding claim 17, Stengel in view of Varadarajan and McCombe discloses The method of claim 16.
On the other hand, Stengel in view of Varadarajan fails to explicitly disclose but McCombe discloses wherein the weighting factor represents an importance of the respective interaction (“[0202] The existence of such a situation is determined by a shader for primitive 1815, which, in these exemplary aspects, generates child rays for each indicated situation (e.g., reflection and refraction) and also records a strength or importance of each such situation as a weight in the respective child rays”. Especially, each child ray indicates a respective interaction, thus the weight of each child ray corresponds to a weight of the respective interaction). The motivation of claim 16 applies here.
Regarding claim 18, Stengel in view of Varadarajan and McCombe discloses The method of claim 16.
On the other hand, Stengel in view of Varadarajan fails to explicitly disclose but McCombe discloses determining that the weighting factor exceeds a threshold value, and in response to a determination that the weighting factor exceeds a threshold value, storing at least some of the first data at the user device (“[0018] the systems and methods include ways to accelerate intersection testing, more efficiently represent quantities of rays for transmission and storage, as well as aspects of adapting ray tracing to meet rendering goals. [0026] The intersection testing resource also is configured for accepting the outputted rays, and managing a memory resource storing the accepted rays. [0208] the weight associated with each ray is used in determining whether that ray should be tested for intersection. For example, a rendering system according to described aspects may allow selection of goal priorities, such as scene quality, or rendering speed, such as a desired frame rate, for example. A weight threshold value for ray/primitive intersection processing can be set and periodically revised in furtherance of the prioritized goal. The threshold value may be used to determine whether a given child ray should be intersection tested or not.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined McCombe into the combination of Varadarajan and Stengel, to include all limitations of claim 18. That is, applying the storing ray information based on weights exceeding a threshold of McCombe to respective interaction of Varadarajan and Stengel. The motivation/ suggestion would have been intelligent real-time adaptation of ray tracing can be implemented using the weights (McCombe, [0202]).
Regarding claim(s) 23-24, they are interpreted and rejected for the same reasons set forth in claim(s) 16, 18, respectively.
Regarding claim(s) 29-31, they are interpreted and rejected for the same reasons set forth in claim(s) 16-18, respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GRACE Q LI whose telephone number is (571)270-0497. The examiner can normally be reached Monday - Friday, 8:00 am-5:00 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://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, DEVONA FAULK can be reached at 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 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.
/GRACE Q LI/Primary Examiner, Art Unit 2618 7/25/2026
Prosecution Insights