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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on September 23, 2024 and December 31, 2024 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 18 and 40 are objected to because of the following informalities:
Claim 18, “Var-DCT” should be defined before it is used in the claim
Similar issue in claim 40
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2, 9, 13, 24, 31 and 35 ( and claims 6-8, 10-12, 14, 28-30, 32-34 and 36 are further rejected for inheriting the rejection and failing to cure the rejection of the respective base claim) are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Antecedent Basis:
Claim 2 recites the limitation "the decompressed image" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 9 recites the limitation "the game asset" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 13 recites the limitation "the game asset" in line 3. There is insufficient antecedent basis for this limitation in the claim.
Claim 24 recites the limitation "the decompressed image" in line 3. There is insufficient antecedent basis for this limitation in the claim.
Claim 31 recites the limitation "the game asset" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 35 recites the limitation "the game asset" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claims 6-8, 10-12, 14, 28-30, 32-34 and 36 are further rejected for inheriting the rejection and failing to cure the rejection of the respective base claim.
Claim Rejections - 35 USC § 102
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 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 –
(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.
Claim(s) 1, 3, 20-23, 25 and 42-44 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Publication No. 2006/0204119 to Feng et al. (hereinafter Feng).
Regarding independent claim 1, Feng discloses A computer-implemented method of performing hybrid decompression of images compressed using compression based on a frequency-domain transform (paragraph 0072, “ In accordance with aspects of the invention, the CPU only needs to partially decode the image (e.g., entropy decoding and inverse quantization) and send the intermediate data to the GPU. The GPU may perform the IDCT and color space conversion and display the image.;” paragraph 0078, “FIG. 12 illustrates an example of a suitable computing system environment 800 in which the invention may be implemented;” paragraph 0089, “The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.”), the method being implemented on a computer system comprising at least a central processing unit (CPU) (paragraph 0030, “FIG. 4 is a block diagram of an exemplary system that may be used in accordance with the present invention in which the DCT is mapped to the GPU 320 instead of the CPU 300. A system bus 310 with system RAM 330 resides between the CPU 300 and the GPU 320. The system bus 310 may be implemented or embedded in a set of chips, for example;” Figure 4, element 300, “CPU”) and a graphics processing unit (GPU) (Figure 4, element 320, “GPU”), the method comprising:
decompressing, by the CPU, a compressed image using at least one entropy decoding method (paragraph 0011, “The decoder 200 of FIG. 3 performs the opposite functions of those of the encoder 100 of FIG. 2. The compressed image data is provided to an entropy decoder 205, which provides its output to a dequantizer 210 and then to an inverse DCT (IDCT) processor 215;” paragraph 0072, “ In accordance with aspects of the invention, the CPU only needs to partially decode the image (e.g., entropy decoding and inverse quantization) and send the intermediate data to the GPU. ”); and
applying, by the GPU, inverse frequency-domain transform to coefficients obtained during decompression of the compressed image (paragraph 0072, “ In accordance with aspects of the invention, the CPU only needs to partially decode the image (e.g., entropy decoding and inverse quantization) and send the intermediate data to the GPU” … “The GPU may perform the IDCT and color space conversion and display the image.”).
Regarding dependent claim 3, the rejection of claim 1 is incorporated herein. Additionally, Feng further discloses wherein the at least one entropy decoding method comprises Huffman decoding (paragraph 0006, “The most commonly used entropy encoders are the Huffman encoder and the arithmetic encoder;” paragraph 0011, “The decoder 200 of FIG. 3 performs the opposite functions of those of the encoder 100 of FIG. 2. The compressed image data is provided to an entropy decoder 205, which provides its output to a dequantizer 210 and then to an inverse DCT (IDCT) processor 215. A quantizer table 220 and a Huffman table 225 are also used in the reconstruction of the image 299.”).
Regarding dependent claim 20, the rejection of claim 1 is incorporated herein. Additionally, Feng further discloses wherein the frequency-domain transform comprises discrete cosine transform (DCT), and wherein the inverse frequency-domain transform comprises inverse DCT (abstract, “Implementations of transforms, such as a discrete cosine transform (DCT) and inverse DCT on a graphics processing unit (GPU), use direct matrix multiplication.”).
Regarding dependent claim 21, the rejection of claim 1 is incorporated herein. Additionally, Feng further discloses wherein the frequency-domain transform comprises Fast Fourier Transform (FFT), and wherein the inverse frequency-domain transform comprises inverse FFT (paragraph 0007, “Thus DCT can be computed with a Fast Fourier Transform (FFT) like algorithm in O(n log n) operations”).
Regarding dependent claim 22, the rejection of claim 1 is incorporated herein. Additionally, Feng further discloses wherein the frequency-domain transform comprises Walsh–Hadamard Transform (WHT), and wherein the inverse frequency-domain transform comprises inverse WHT (paragraph 0004, “For the source encoder 10, a variety of linear transforms have been developed which include the Discrete Fourier Transform (DFT), Discrete Cosine Transform (DCT), and Discrete Wavelet Transform (DWT), for example;” these are read as exemplary linear transforms; a walsh-hadamard encoder is also linear).
Regarding independent claim 23, the rejection of claim 1 applies directly. Additionally, Feng further discloses A system (paragraph 0021, “FIG. 4 is a block diagram of an exemplary CPU/GPU system in accordance with the present invention;” paragraph 0089, “The various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.”) for performing hybrid decompression of images compressed using compression based on a frequency-domain transform (abstract, “Implementations of transforms, such as a discrete cosine transform (DCT) and inverse DCT on a graphics processing unit (GPU), use direct matrix multiplication;” paragraph 0005, “The quantizer 20 reduces the number of bits needed to store the transformed coefficients by reducing the precision of those values. Because this is a many-to-one mapping, it is a lossy process and is the main source of compression in an encoder.”), the system comprising:
a central processing unit (CPU) (Figure 4, element 300) configured by computer readable instructions to decompress a compressed image using at least one entropy decoding method (paragraph 0072, “the CPU has to fully decode the compressed image (entropy decoding, inverse quantization, IDCT, and color space conversion) and send the bitmap data to the GPU for display. In accordance with aspects of the invention, the CPU only needs to partially decode the image (e.g., entropy decoding and inverse quantization) and send the intermediate data to the GPU.”); and
a graphics processing unit (GPU) (Figure 4, element 320) configured by computer readable instructions to apply inverse frequency-domain transform to coefficients obtained during decompression of the compressed image (paragraph 0032, “The examples described herein are directed to the DCT and its inverse (IDCT), though the invention is not limited thereto;” paragraph 0072, “The GPU may perform the IDCT and color space conversion and display the image.”).
Regarding dependent claim 25, the rejection of claim 23 is incorporated herein. Additionally, Feng further discloses wherein the at least one entropy decoding method comprises Huffman decoding (paragraph 0006, “The most commonly used entropy encoders are the Huffman encoder and the arithmetic encoder;” paragraph 0011, “The decoder 200 of FIG. 3 performs the opposite functions of those of the encoder 100 of FIG. 2. The compressed image data is provided to an entropy decoder 205, which provides its output to a dequantizer 210 and then to an inverse DCT (IDCT) processor 215. A quantizer table 220 and a Huffman table 225 are also used in the reconstruction of the image 299.”).
Regarding dependent claim 42, the rejection of claim 23 is incorporated herein. Additionally, Feng further discloses wherein the frequency-domain transform comprises discrete cosine transform (DCT), and wherein the inverse frequency-domain transform comprises inverse DCT (abstract, “Implementations of transforms, such as a discrete cosine transform (DCT) and inverse DCT on a graphics processing unit (GPU), use direct matrix multiplication.”).
Regarding dependent claim 43, the rejection of claim 23 is incorporated herein. Additionally, Feng further discloses wherein the frequency-domain transform comprises Fast Fourier Transform (FFT), and wherein the inverse frequency-domain transform comprises inverse FFT (paragraph 0007, “Thus DCT can be computed with a Fast Fourier Transform (FFT) like algorithm in O(n log n) operations”).
Regarding dependent claim 44, the rejection of claim 23 is incorporated herein. Additionally, Feng further discloses wherein the frequency-domain transform comprises Walsh–Hadamard Transform (WHT), and wherein the inverse frequency-domain transform comprises inverse WHT (paragraph 0004, “For the source encoder 10, a variety of linear transforms have been developed which include the Discrete Fourier Transform (DFT), Discrete Cosine Transform (DCT), and Discrete Wavelet Transform (DWT), for example;” these are read as exemplary linear transforms; a walsh-hadamard encoder is also linear and read as an alternative to the exemplary list).
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.
Claim(s) 2, 6-10, 15-16, 19, 24, 28-32, 37-38 are 41 are rejected under 35 U.S.C. 103 as being unpatentable over Feng as applied to claims 1 and 23 respectively above, and further in view of Hristova, Hristina, et al. "3CPS: a novel supercompression for the delivery of 3D object textures." Proceedings of the 11th ACM Multimedia Systems Conference. 2020. (hereinafter Hristova).
Regarding dependent claim 2, the rejection of claim 1 is incorporated herein. Additionally, Feng fails to explicitly disclose the method further comprising:
recompressing, by the GPU, the decompressed image; and
writing, by the GPU, the recompressed image directly to a texture memory of the GPU.
However, Hristova discloses the method further comprising:
recompressing, by the GPU, the decompressed image (page 69, right column, “3.2 Algorithm for Re-Compression At the client side, the re-compression (step 3 in Figure 3) needs to be time-efficient.”); and
writing, by the GPU, the recompressed image directly to a texture memory of the GPU (page 66, left column, “third, at the client side, the received image is re-compressed by a texture image technique for better GPU processing;” in order for the image to be further processed, it must be saved to the memory).
Feng is directed toward “this invention relates to the use of a graphics processing unit to accelerate graphics and non-graphics operations (paragraph 0001).” Hristova is directed toward “We propose 3CPS, a novel solution for the compression and delivery of texture images (abstract).” As can be easily seen by one of ordinary skill in the art Feng and Hristova are directed toward similar methods of endeavor of image processing. Further, Feng and Hristova both allow for conveying of texture features (Feng: “The working flow of a rendering pass can be divided into two stages. In the first stage, a number of source textures, the associated vertex streams, the render targets, the vertex shader (VS), and the pixel shader (PS) are specified. The source textures hold the input data. The vertex streams comprise vertices that contain the target position and the associated texture address information. The render targets are textures that hold the resulting IDCT results (paragraph 0042);” Hristova: “We propose 3CPS, a novel solution for the compression and delivery of texture images (abstract)”). Hristova additionally allows for re-compression, for better GPU processing (abstract). Further, being that optimal processing is often a goal of computer processing methods, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova to further allow for improved processing using recompression techniques.
Regarding dependent claim 6, the rejection of claim 2 is incorporated herein. Additionally, Hristova in the combination further discloses wherein the decompressed image is recompressed into a DXT1 or DXT5 format (page 68, left column, “then the client re-compresses it into a traditional texture format (such as DXT1).”).
One of ordinary skill in the art before the effective filing date of the claimed invention would be aware DXT1 is well known as the desktop texture storage method, while ECT1/2 are the standard for Android and mobile texture storage methodologies. It would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova in order to ensure the format appropriately corresponds to the endpoint device.
Regarding dependent claim 7, the rejection of claim 2 is incorporated herein. Additionally, Feng and Hristova in the combination fail to explicitly disclose wherein the decompressed image is recompressed into a ETC1 or ETC2 format.
However, Hristova discloses at page 68, left column, “then the client re-compresses it into a traditional texture format (such as DXT1).” One of ordinary skill in the art before the effective filing date of the claimed invention would be aware DXT1 is well known as the desktop texture storage method, while ECT1/2 are the standard for Android and mobile texture storage methodologies. Thus, based on the end point use case of the texture data, it would have been obvious to a person having ordinary skill in the art before the effective filing date to modify the teaching of Feng and Hristova to ensure the accurate texture storage method is used, corresponding to the endpoint device.
Regarding dependent claim 8, the rejection of claim 2 is incorporated herein. Additionally, Hristova further discloses wherein writing the recompressed image directly to the texture memory of the GPU comprises writing the recompressed image to the texture memory of the GPU without providing the recompressed image to the CPU (page 66, left column, “third, at the client side, the received image is re-compressed by a texture image technique for better GPU processing;” in order for the image to be further processed, it must be saved to the memory; never stated that this is provided to the CPU) .
Regarding dependent claim 9, the rejection of claim 2 is incorporated herein. Additionally, Hristova further discloses the method further comprising:
rendering, by the GPU, the game asset using the recompressed image written to the texture memory of the GPU (page 67, “In 3D graphics, a texture represents the material that applies to the geometrical surfaces of the mesh, and defines the external appearance of the 3D model. As shown in Figure 1, a texture consists of a set of images, each image encoding a given characteristic of the material. These characteristics are processed by the 3D renderer (a.k.a. game engine [12]) to create the visual aspect of the scene, in particular how the light rays behave when reaching the 3D object [2].”… “On the GPU side, the renderer software extracts and processes some specific small areas of the texture image when it computes light effects on an object [2]”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova to further allow for improved processing using recompression techniques and rendering the optimal image for viewing.
Regarding dependent claim 10, the rejection of claim 9 is incorporated herein. Additionally, Feng in the combination further discloses wherein the compressed image comprises a first texture of a game asset (paragraph 0042, “a number of source textures”), the method further comprising:
decompressing, by the CPU, a second texture of the game asset using at least one entropy decoding method (paragraph 0011, “The compressed image data is provided to an entropy decoder 205;” paragraph 0072, “In accordance with aspects of the invention, the CPU only needs to partially decode the image (e.g., entropy decoding and inverse quantization) and send the intermediate data to the GPU”).
Hristova in the combination further discloses
recompressing, by the CPU, the decompressed second texture (abstract, “the received image is re-compressed by a texture image technique for better GPU processing.”); and
writing, by the CPU, the recompressed second texture to the texture memory of the GPU (page 68, right column, “. The famous DXT1 defines fixed-size texels of 4x4 pixels, where each endpoint color is stored in 16 bits with an 5:6:5 RGB encoding, and the palette comprises four colors, which are represented by 2 bits. To sum up, in a DXT1 texel, 32 bits are required to store the two endpoints, and 32 bits are required to represent the colors of the 16 pixels in the palette. Overall, a DXT1 image has thus a fixed 4 bpp storage requirement;” DCT1 is read as the method of storing texture).
Hristova additionally allows for re-compression, for better GPU processing (abstract). Further, being that optimal processing is often a goal of computer processing methods and that per a data set there would be multiple different texture data sets, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova to further allow for improved processing using recompression techniques.
Regarding dependent claim 15, the rejection of claim 1 is incorporated herein. Additionally, Feng fails to explicitly disclose the method further comprising:
obtaining, by the CPU, the compressed image, wherein the compressed image is obtained in a decompression-friendly format.
However, Hristova discloses the method further comprising:
obtaining, by the CPU, the compressed image, wherein the compressed image is obtained in a decompression-friendly format (abstract, “We propose 3CPS, a novel solution for the compression and delivery of texture images. In 3CPS, the texture image is compressed three times: first, at the authoring side, by a traditional texture compression technique; second, still at the authoring side, by a stateof-the-art image compression technique for better network delivery; third, at the client side, the received image is re-compressed by a texture image technique for better GPU processing. Our original idea leverages the fact that the image at the client side has already been converted into a format that can be easily transformed by the client for GPU processing;” page 67, right column, “the renderer can extract and decompress the image texel per texel, so the image format enables the random-access feature;” see also Table 1; page 69, “The main idea is that the endpoints are computed at the authoring tool, and then encoded using traditional image compression techniques, together with a dictionary to keep trace of the respective texels;” progressive encoding is not utilized; NOTE: applicant’s specification definition of “decompression friendly” in PGPub paragraph 0006 states, “ in order to compress an image in a decompression-friendly format, the image may be compressed without using progressive encoding, using XYB as a color space, using Chroma-from-Luma prediction, and/or using Var-DCT mode only.”).
Feng is directed toward “this invention relates to the use of a graphics processing unit to accelerate graphics and non-graphics operations (paragraph 0001).” Hristova is directed toward “We propose 3CPS, a novel solution for the compression and delivery of texture images (abstract).” As can be easily seen by one of ordinary skill in the art Feng and Hristova are directed toward similar methods of endeavor of image processing. Further, Feng and Hristova both allow for conveying of texture features (Feng: “The working flow of a rendering pass can be divided into two stages. In the first stage, a number of source textures, the associated vertex streams, the render targets, the vertex shader (VS), and the pixel shader (PS) are specified. The source textures hold the input data. The vertex streams comprise vertices that contain the target position and the associated texture address information. The render targets are textures that hold the resulting IDCT results (paragraph 0042);” Hristova: “We propose 3CPS, a novel solution for the compression and delivery of texture images (abstract)”). Further, compressed data is often used to transfer data, which is then decompressed for analysis; thus sending compressed data in a manner that can be decompressed allows for further processing to occur that can only be done on decompressed data. It would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova to further allow for further processing of compressed data into decompressed data.
Regarding dependent claim 16, the rejection of claim 15 is incorporated herein. Additionally, Hristova further discloses wherein the image is compressed without using progressive encoding (page 69, “The main idea is that the endpoints are computed at the authoring tool, and then encoded using traditional image compression techniques, together with a dictionary to keep trace of the respective texels;” progressive encoding is not utilized).
It would have been obvious to a person having ordinary skill in the art before the effective filing date to ensure not to use progressive encoding similar to Hristova in that the goal of the system is to increase efficiency and speed, and utilizing progressive encoding would use higher CPU and memory usage; thus making a less efficient system.
Regarding dependent claim 19, the rejection of claim 15 is incorporated herein. Additionally, Hristova further discloses wherein the compressed image is obtained as a part of a downloadable resource providing a game asset (page 67, left column, “A specific challenge of texture delivery is that two bottlenecks should be regarded: (𝑖) the network and (𝑖𝑖) the graphics processing unit (GPU). With regards to the average mobile downloading speed in United States in 2019,1 the Rock09 texture alone would take more than 1 min to be received”), wherein the downloadable resource comprises interleaved streams for each of glTF JSON data, a mesh, and a texture of the game asset (page 67, left column, “In 3D graphics, a texture represents the material that applies to the geometrical surfaces of the mesh, and defines the external appearance of the 3D model. As shown in Figure 1, a texture consists of a set of images, each image encoding a given characteristic of the material. These characteristics are processed by the 3D renderer (a.k.a. game engine [12]) to create the visual aspect of the scene, in particular how the light rays behave when reaching the 3D object [2];” page 69, left column, “A significant recent improvement is related to the release of the Basis format, derived from the project crunch. 8 The release of Basis was concomitant with the creation of a specific working group at glTF, named Compression Texture Transmission Format (CTTF).”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova to ensure the efficiency and speed increases can be applicable to multiple different types of data, including gaming data.
Regarding dependent claim 24, the rejection of claim 23 is incorporated herein. Additionally, Feng fails to explicitly disclose wherein the GPU is further configured by computer readable instructions to:
recompress the decompressed image; and
write the recompressed image directly to a texture memory of the GPU.
However, Hristova discloses wherein the GPU is further configured by computer readable instructions to:
recompress the decompressed image (page 69, right column, “3.2 Algorithm for Re-Compression At the client side, the re-compression (step 3 in Figure 3) needs to be time-efficient.”); and
write the recompressed image directly to a texture memory of the GPU (page 66, left column, “third, at the client side, the received image is re-compressed by a texture image technique for better GPU processing;” in order for the image to be further processed, it must be saved to the memory).
Feng is directed toward “this invention relates to the use of a graphics processing unit to accelerate graphics and non-graphics operations (paragraph 0001).” Hristova is directed toward “We propose 3CPS, a novel solution for the compression and delivery of texture images (abstract).” As can be easily seen by one of ordinary skill in the art Feng and Hristova are directed toward similar methods of endeavor of image processing. Further, Feng and Hristova both allow for conveying of texture features (Feng: “The working flow of a rendering pass can be divided into two stages. In the first stage, a number of source textures, the associated vertex streams, the render targets, the vertex shader (VS), and the pixel shader (PS) are specified. The source textures hold the input data. The vertex streams comprise vertices that contain the target position and the associated texture address information. The render targets are textures that hold the resulting IDCT results (paragraph 0042);” Hristova: “We propose 3CPS, a novel solution for the compression and delivery of texture images (abstract)”). Hristova additionally allows for re-compression, for better GPU processing (abstract). Further, being that optimal processing is often a goal of computer processing methods, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova to further allow for improved processing using recompression techniques.
Regarding dependent claim 28, the rejection of claim 24 is incorporated herein. Additionally, Hristova in the combination further discloses wherein the decompressed image is recompressed into a DXT1 or DXT5 format (page 68, left column, “then the client re-compresses it into a traditional texture format (such as DXT1).”).
One of ordinary skill in the art before the effective filing date of the claimed invention would be aware DXT1 is well known as the desktop texture storage method, while ECT1/2 are the standard for Android and mobile texture storage methodologies. It would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova in order to ensure the format appropriately corresponds to the endpoint device.
Regarding dependent claim 29 the rejection of claim 24 is incorporated herein. Additionally, Feng and Hristova in the combination fail to explicitly disclose wherein the decompressed image is recompressed into a ETC1 or ETC2 format.
However, Hristova discloses at page 68, left column, “then the client re-compresses it into a traditional texture format (such as DXT1).” One of ordinary skill in the art before the effective filing date of the claimed invention would be aware DXT1 is well known as the desktop texture storage method, while ECT1/2 are the standard for Android and mobile texture storage methodologies. Thus, based on the end point use case of the texture data, it would have been obvious to a person having ordinary skill in the art before the effective filing date to modify the teaching of Feng and Hristova to ensure the accurate texture storage method is used, corresponding to the endpoint device.
Regarding dependent claim 30, the rejection of claim 24 is incorporated herein. Additionally, Hristova further discloses wherein to write the recompressed image directly to the texture memory of the GPU, the GPU is further configured by computer readable instructions to write the recompressed image to the texture memory of the GPU without providing the recompressed image to the CPU (page 66, left column, “third, at the client side, the received image is re-compressed by a texture image technique for better GPU processing;” in order for the image to be further processed, it must be saved to the memory; never stated that this is provided to the CPU) .
Regarding dependent claim 31, the rejection of claim 24 is incorporated herein. Additionally, Hristova further discloses wherein the GPU is further configured by computer readable instructions to render the game asset using the recompressed image written to the texture memory of the GPU (page 67, “In 3D graphics, a texture represents the material that applies to the geometrical surfaces of the mesh, and defines the external appearance of the 3D model. As shown in Figure 1, a texture consists of a set of images, each image encoding a given characteristic of the material. These characteristics are processed by the 3D renderer (a.k.a. game engine [12]) to create the visual aspect of the scene, in particular how the light rays behave when reaching the 3D object [2].”… “On the GPU side, the renderer software extracts and processes some specific small areas of the texture image when it computes light effects on an object [2]”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova to further allow for improved processing using recompression techniques and rendering the optimal image for viewing.
Regarding dependent claim 32, the rejection of claim 31 is incorporated herein. Additionally, Feng in the combination further discloses wherein the compressed image comprises a first texture of a game asset (paragraph 0042, “a number of source textures”), wherein the CPU is further configured by computer readable instructions to:
decompress a second texture of the game asset using at least one entropy decoding method (paragraph 0011, “The compressed image data is provided to an entropy decoder 205;” paragraph 0072, “In accordance with aspects of the invention, the CPU only needs to partially decode the image (e.g., entropy decoding and inverse quantization) and send the intermediate data to the GPU”).
Hristova in the combination further discloses
recompress the decompressed second texture (abstract, “the received image is re-compressed by a texture image technique for better GPU processing.”); and
write the recompressed second texture to the texture memory of the GPU (page 68, right column, “. The famous DXT1 defines fixed-size texels of 4x4 pixels, where each endpoint color is stored in 16 bits with an 5:6:5 RGB encoding, and the palette comprises four colors, which are represented by 2 bits. To sum up, in a DXT1 texel, 32 bits are required to store the two endpoints, and 32 bits are required to represent the colors of the 16 pixels in the palette. Overall, a DXT1 image has thus a fixed 4 bpp storage requirement;” DCT1 is read as the method of storing texture).
Hristova additionally allows for re-compression, for better GPU processing (abstract). Further, being that optimal processing is often a goal of computer processing methods and that per a data set there would be multiple different texture data sets, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova to further allow for improved processing using recompression techniques.
Regarding dependent claim 37, the rejection of claim 23 is incorporated herein. Additionally, Feng fails to explicitly wherein the CPU is further configured by computer readable instructions to obtain the compressed image, wherein the compressed image is obtained in a decompression-friendly format.
However, Hristova discloses wherein the CPU is further configured by computer readable 37. instructions to obtain the compressed image, wherein the compressed image is obtained in a decompression-friendly format (abstract, “We propose 3CPS, a novel solution for the compression and delivery of texture images. In 3CPS, the texture image is compressed three times: first, at the authoring side, by a traditional texture compression technique; second, still at the authoring side, by a stateof-the-art image compression technique for better network delivery; third, at the client side, the received image is re-compressed by a texture image technique for better GPU processing. Our original idea leverages the fact that the image at the client side has already been converted into a format that can be easily transformed by the client for GPU processing;” page 67, right column, “the renderer can extract and decompress the image texel per texel, so the image format enables the random-access feature;” see also Table 1; page 69, “The main idea is that the endpoints are computed at the authoring tool, and then encoded using traditional image compression techniques, together with a dictionary to keep trace of the respective texels;” progressive encoding is not utilized; NOTE: applicant’s specification definition of “decompression friendly” in PGPub paragraph 0006 states, “ in order to compress an image in a decompression-friendly format, the image may be compressed without using progressive encoding, using XYB as a color space, using Chroma-from-Luma prediction, and/or using Var-DCT mode only.”).
Feng is directed toward “this invention relates to the use of a graphics processing unit to accelerate graphics and non-graphics operations (paragraph 0001).” Hristova is directed toward “We propose 3CPS, a novel solution for the compression and delivery of texture images (abstract).” As can be easily seen by one of ordinary skill in the art Feng and Hristova are directed toward similar methods of endeavor of image processing. Further, Feng and Hristova both allow for conveying of texture features (Feng: “The working flow of a rendering pass can be divided into two stages. In the first stage, a number of source textures, the associated vertex streams, the render targets, the vertex shader (VS), and the pixel shader (PS) are specified. The source textures hold the input data. The vertex streams comprise vertices that contain the target position and the associated texture address information. The render targets are textures that hold the resulting IDCT results (paragraph 0042);” Hristova: “We propose 3CPS, a novel solution for the compression and delivery of texture images (abstract)”). Further, compressed data is often used to transfer data, which is then decompressed for analysis; thus sending compressed data in a manner that can be decompressed allows for further processing to occur that can only be done on decompressed data. It would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova to further allow for further processing of compressed data into decompressed data.
Regarding dependent claim 38, the rejection of claim 37 is incorporated herein. Additionally, Hristova further discloses wherein the image is compressed without using progressive encoding (page 69, “The main idea is that the endpoints are computed at the authoring tool, and then encoded using traditional image compression techniques, together with a dictionary to keep trace of the respective texels;” progressive encoding is not utilized).
It would have been obvious to a person having ordinary skill in the art before the effective filing date to ensure not to use progressive encoding similar to Hristova in that the goal of the system is to increase efficiency and speed, and utilizing progressive encoding would use higher CPU and memory usage; thus making a less efficient system.
Regarding dependent claim 41, the rejection of claim 37 is incorporated herein. Additionally, Hristova further discloses wherein the compressed image is obtained as a part of a downloadable resource providing a game asset (page 67, left column, “A specific challenge of texture delivery is that two bottlenecks should be regarded: (𝑖) the network and (𝑖𝑖) the graphics processing unit (GPU). With regards to the average mobile downloading speed in United States in 2019,1 the Rock09 texture alone would take more than 1 min to be received”), wherein the downloadable resource comprises interleaved streams for each of glTF JSON data, a mesh, and a texture of the game asset (page 67, left column, “In 3D graphics, a texture represents the material that applies to the geometrical surfaces of the mesh, and defines the external appearance of the 3D model. As shown in Figure 1, a texture consists of a set of images, each image encoding a given characteristic of the material. These characteristics are processed by the 3D renderer (a.k.a. game engine [12]) to create the visual aspect of the scene, in particular how the light rays behave when reaching the 3D object [2];” page 69, left column, “A significant recent improvement is related to the release of the Basis format, derived from the project crunch. 8 The release of Basis was concomitant with the creation of a specific working group at glTF, named Compression Texture Transmission Format (CTTF).”).
It would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Hristova to ensure the efficiency and speed increases can be applicable to multiple different types of data, including gaming data.
Claim(s) 4-5 and 26-27 are rejected under 35 U.S.C. 103 as being unpatentable over Feng as applied to claims 1 and 23 respectively above, and further in view of Krajcevski, Pavel, Srihari Pratapa, and Dinesh Manocha. "GST: GPU-decodable supercompressed textures." ACM Transactions on Graphics (TOG) 35.6 (2016): 1-10. (hereinafter Krajcevski).
Regarding dependent claim 4, the rejection of claim 1 is incorporated herein. Additionally, Feng fails to explicitly disclose wherein the at least one entropy decoding method comprises an asymmetrical numeral systems (ANS) decoding method.
However, Krajcevki discloses wherein the at least one entropy decoding method comprises an asymmetrical numeral systems (ANS) decoding method (section, “ANS Entropy Encoding,” “Asymmetric Numeral Systems (ANS), first introduced by Duda [2013];” section, “3.3.2 Asymmetric Numeral Systems,” “ANS provides an encoder C and a decoder D such that”).
Feng is directed toward “GPU features such as parallel graphics pipelines, multi-channel capability, and multiple render targets are used to obtain significantly faster processing speeds than on a conventional central processing unit (CPU) (abstract).” Krajcevki is directed toward “Modern GPUs supporting compressed textures allow interactive application developers to save scarce GPU resources such as VRAM and bandwidth. Compressed textures use fixed compression ratios whose lossy representations are significantly poorer quality than traditional image compression formats such as JPEG. We present a new method in the class of supercompressed textures that provides an additional layer of compression to already compressed textures. Our texture representation is designed for endpoint compressed formats such as DXT and PVRTC and decoding on commodity GPUs. We apply our algorithm to commonly used formats by separating their representation into two parts that are processed independently and then entropy encoded. Our method preserves the CPU-GPU bandwidth during the decoding phase and exploits the parallelism of GPUs to provide up to 3X faster decode compared to prior texture supercompression algorithms. Along with the gains in decoding speed, our method maintains both the compression size and quality of current state of the art texture representations (abstract).” As can be easily seen by one of ordinary skill in the art Feng and Krajcevki are directed toward similar methods of endeavor of increasing operation speed of GPU and CPU systems. Further, Krajcevki allows for enhanced speed while also preserving bandwidth between the CPU and GPU. Optimal processing speed is of utmost importance especially when processing texture data as related to gaming so that interaction is seamless; thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Krajcevki in order to maintain high compression efficiency and high processing speed through the utilization of ANS systems.
Regarding dependent claim 5, the rejection of claim 4 is incorporated herein. Additionally, Krajcevki in the combination further discloses wherein the asymmetrical numeral systems (ANS) decoding method comprises range asymmetric numeral systems (rANS) decoding (section 3 Compression Pipeline, “each using the range variant of ANS before storing to disk [Duda 2013].”) or tabled asymmetrical numeral systems (tANS) and finite state entropy (FSE) decoding.
Regarding dependent claim 26, the rejection of claim 23 is incorporated herein. Additionally, Feng fails to explicitly disclose wherein the at least one entropy decoding method comprises an asymmetrical numeral systems (ANS) decoding method.
However, Krajcevki discloses wherein the at least one entropy decoding method comprises an asymmetrical numeral systems (ANS) decoding method (section, “ANS Entropy Encoding,” “Asymmetric Numeral Systems (ANS), first introduced by Duda [2013];” section, “3.3.2 Asymmetric Numeral Systems,” “ANS provides an encoder C and a decoder D such that”).
Feng is directed toward “GPU features such as parallel graphics pipelines, multi-channel capability, and multiple render targets are used to obtain significantly faster processing speeds than on a conventional central processing unit (CPU) (abstract).” Krajcevki is directed toward “Modern GPUs supporting compressed textures allow interactive application developers to save scarce GPU resources such as VRAM and bandwidth. Compressed textures use fixed compression ratios whose lossy representations are significantly poorer quality than traditional image compression formats such as JPEG. We present a new method in the class of supercompressed textures that provides an additional layer of compression to already compressed textures. Our texture representation is designed for endpoint compressed formats such as DXT and PVRTC and decoding on commodity GPUs. We apply our algorithm to commonly used formats by separating their representation into two parts that are processed independently and then entropy encoded. Our method preserves the CPU-GPU bandwidth during the decoding phase and exploits the parallelism of GPUs to provide up to 3X faster decode compared to prior texture supercompression algorithms. Along with the gains in decoding speed, our method maintains both the compression size and quality of current state of the art texture representations (abstract).” As can be easily seen by one of ordinary skill in the art Feng and Krajcevki are directed toward similar methods of endeavor of increasing operation speed of GPU and CPU systems. Further, Krajcevki allows for enhanced speed while also preserving bandwidth between the CPU and GPU. Optimal processing speed is of utmost importance especially when processing texture data as related to gaming so that interaction is seamless; thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Krajcevki in order to maintain high compression efficiency and high processing speed through the utilization of ANS systems.
Regarding dependent claim 27, the rejection of claim 26 is incorporated herein. Additionally, Krajcevki in the combination further discloses wherein the asymmetrical numeral systems (ANS) decoding method comprises range asymmetric numeral systems (rANS) decoding (section 3 Compression Pipeline, “each using the range variant of ANS before storing to disk [Duda 2013].”) or tabled asymmetrical numeral systems (tANS) and finite state entropy (FSE) decoding.
Claim(s) 11-12 and 33-34 are rejected under 35 U.S.C. 103 as being unpatentable over Feng further in view of Hristova as applied to claims 10 and 32 respectively above, and further in view of Joselli, Mark, et al. "An architecture with automatic load balancing for real-time simulation and visualization systems." JCIS-Journal of Computational Interdisciplinary Sciences 1.3 (2010): 207-224. (hereinafter Joselli).
Regarding dependent claim 11, the rejection of claim 10 is incorporated herein. Additionally, Feng and Hristova fails to explicitly disclose the method further comprising:
measuring, by the CPU, characteristics of a loading queue associated with the game asset; and
determining, by the CPU, whether to recompress the decompressed second texture on the CPU or the GPU based on the measured characteristics of the loading queue.
However, Joselli discloses the method further comprising:
measuring, by the CPU, characteristics of a loading queue associated with the game asset (page 208, left column, “This work utilizes some of these concepts, like task distribution and load balancing, adapting them to the loop architectures of real-time simulations;” page 213, right column, “Redistribution of tasks between the processors when a processor (CPU or GPU) is overloaded with work;” overloaded processors are readas characteristics of the queue); and
determining, by the CPU, whether to recompress the decompressed second texture on the CPU or the GPU based on the measured characteristics of the loading queue (page 213, right column, “Redistribution of tasks between the processors when a processor (CPU or GPU) is overloaded with work;” the recompression is read as a task to which the GPU/CPU determine if there is overload, they will pass the task to a different entity (i.e. whether or not to perform the task)).
Feng and Hristova are directed toward methods of increasing system performance for image processing tasks. Joselli is directed toward “This paper presents a survey on loop models for games and real-time systems. Also it discusses the usage of simple loops with single-thread architecture and multithread loop architectures in scientific simulations and visualization systems. Furthermore, this paper presents a new architecture for real-time loops that can detect and analyze the user hardware in order to adapt itself to a specific loop model, achieving the best performance for a specific hardware and application.” As can be easily seen by one of ordinary skill in the art before the effective filing date of the claimed invention, Feng, Hristova and Joselli are directed toward similar methods of endeavor of efficiency in computer processing. Further, Joselli allows for readjustment of loads applied to processors in order to have optimal processing. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Joselli in order to sure processors do not become overloaded with decompression or compression tasks, thus creating an overall more efficient system.
Regarding dependent claim 12, the rejection of claim 11 is incorporated herein. Additionally, Joselli further discloses wherein the loading queue comprises a queue of outstanding requests associated with the game asset (page 208, left column, “This work utilizes some of these concepts, like task distribution and load balancing, adapting them to the loop architectures of real-time simulations;” page 213, right column, “Redistribution of tasks between the processors when a processor (CPU or GPU) is overloaded with work;” tasks that are redistributed are read as outstanding requests).
Regarding dependent claim 33, the rejection of claim 32 is incorporated herein. Additionally, Feng and Hristova fails to explicitly disclose wherein the CPU is further configured by computer readable instructions to:
measure characteristics of a loading queue associated with the game asset; and
determine whether to recompress the decompressed second texture on the CPU or the GPU based on the measured characteristics of the loading queue.
However, Joselli discloses wherein the CPU is further configured by computer readable instructions to:
measure characteristics of a loading queue associated with the game asset (page 208, left column, “This work utilizes some of these concepts, like task distribution and load balancing, adapting them to the loop architectures of real-time simulations;” page 213, right column, “Redistribution of tasks between the processors when a processor (CPU or GPU) is overloaded with work;” overloaded processors are readas characteristics of the queue); and
determine whether to recompress the decompressed second texture on the CPU or the GPU based on the measured characteristics of the loading queue (page 213, right column, “Redistribution of tasks between the processors when a processor (CPU or GPU) is overloaded with work;” the recompression is read as a task to which the GPU/CPU determine if there is overload, they will pass the task to a different entity (i.e. whether or not to perform the task)).
Feng and Hristova are directed toward methods of increasing system performance for image processing tasks. Joselli is directed toward “This paper presents a survey on loop models for games and real-time systems. Also it discusses the usage of simple loops with single-thread architecture and multithread loop architectures in scientific simulations and visualization systems. Furthermore, this paper presents a new architecture for real-time loops that can detect and analyze the user hardware in order to adapt itself to a specific loop model, achieving the best performance for a specific hardware and application.” As can be easily seen by one of ordinary skill in the art before the effective filing date of the claimed invention, Feng, Hristova and Joselli are directed toward similar methods of endeavor of efficiency in computer processing. Further, Joselli allows for readjustment of loads applied to processors in order to have optimal processing. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Joselli in order to sure processors do not become overloaded with decompression or compression tasks, thus creating an overall more efficient system.
Regarding dependent claim 34, the rejection of claim 12 is incorporated herein. Additionally, Joselli further discloses wherein the loading queue comprises a queue of outstanding requests associated with the game asset (page 208, left column, “This work utilizes some of these concepts, like task distribution and load balancing, adapting them to the loop architectures of real-time simulations;” page 213, right column, “Redistribution of tasks between the processors when a processor (CPU or GPU) is overloaded with work;” tasks that are redistributed are read as outstanding requests).
Claim(s) 13-14 and 35-36 are rejected under 35 U.S.C. 103 as being unpatentable over Feng further in view of Hristova as applied to claims 2 and 24 respectively above, and further in view of U.S. Publication No. 2018/0247387 to Riguer (hereinafter Riguer).
Regarding dependent claim 13, the rejection of claim 2 is incorporated herein. Additionally, Feng and Hristova in the combination as a whole fails to explicitly disclose wherein the computer system comprises at least a second graphics processing unit (GPU), the method further comprising:
rendering, by the second GPU, the game asset using the recompressed image written to the texture memory of the GPU.
However, Riguer discloses wherein the computer system comprises at least a second graphics processing unit (GPU) (paragraph 0013, “ In a processing system having multiple GPUs, a GPU may transfer a compressed stream of graphics data to another GPU via a bus.”), the method further comprising:
rendering, by the second GPU, the game asset using the recompressed image written to the texture memory of the GPU (paragraph 0021-0022, “The ports 140 and 160 receive the compacted compressed graphics streams and send them to the decompacting engines 130 and 180, respectively. The decompacting engines 130 and 180 are configured to parse the metadata from the compacted compressed graphics streams, reinsert padding as needed for data alignment (i.e., decompact the compacted compressed graphics streams), and decompress the compressed graphics streams according to the decompression method(s) indicated by the metadata. Each of the shaders 112-118 and 162-168 is a processing element configured to perform specialized calculations and execute certain instructions for rendering computer graphics. For example, shaders 112-118 and 162-168 may compute color and other attributes for each fragment, or pixel, of a screen.”).
As noted above, Feng and Hristova are directed toward methods of image compression and decompression while maintaining speed and efficiency. Riguer is directed toward “a processing system including a plurality of graphics processing units (GPUs), the GPUs transfer compressed graphics streams composed of blocks of graphics data to one another (abstract).” As can be easily seen by one of ordinary skill in the art before the effective filing date Feng, Hristova and Riguer are all directed toward similar methods of endeavor of image compression. Further, Riguer allows for transferring compressed data across multiple GPUs. One of ordinary skill in the art before the effective filing date would be aware that often systems can contain multiple GPUs, and thus there may be a need to transfer data across GPUs based on what specific processing the GPUs are doing (i.e. one GPU may perform a different task than another). Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Riguer in order to ensure smooth and efficient processing of data between GPUs for the method to be carried out on systems including multiple GPUs as opposed to a single GPU.
Regarding dependent claim 14, the rejection of claim 13 is incorporated herein. Additionally, Feng in the combination further discloses wherein rendering the game asset by the second GPU comprises:
providing, by the GPU, a decompressed third texture of a game asset from the GPU to the CPU (paragraph 0030, “The GPU 320 has associated texture and video memory 340. The processing involving the DCT, set forth below, takes place within the GPU 320.;” Figure 4, CPU and GPU are connected by a system bus);
writing, by the CPU, the decompressed third texture of the game asset to the texture memory of the second GPU (Figure 4, the texture and video memory are attached to the GPU and CPU with s system bus between; paragraph 0030, “The GPU 320 has associated texture and video memory 340. The processing involving the DCT, set forth below, takes place within the GPU 320.”); and
rendering, by the second GPU, the game asset using the decompressed third texture written to the texture memory of the second GPU (paragraph 0042, “The computation on a GPU is desirably performed using one or more rendering passes. The working flow of a rendering pass can be divided into two stages. In the first stage, a number of source textures, the associated vertex streams, the render targets, the vertex shader (VS), and the pixel shader (PS) are specified. The source textures hold the input data. The vertex streams comprise vertices that contain the target position and the associated texture address information. The render targets are textures that hold the resulting IDCT results.”).
As noted above, Riguer allows for processing to be carried out on multiple GPUs. Further, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Riguer to ensure multiple textures can be analyzed, as not all images or objects will have the same textures.
Regarding dependent claim 35, the rejection of claim 24 is incorporated herein. Additionally, Feng and Hristova in the combination as a whole fails to explicitly disclose the system further comprising at least a second graphics processing unit (GPU), configured by computer readable instructions to render the game asset using the recompressed image written to the texture memory of the GPU.
However, Riguer discloses the system further comprising at least a second graphics processing unit (GPU) (paragraph 0013, “ In a processing system having multiple GPUs, a GPU may transfer a compressed stream of graphics data to another GPU via a bus.”), configured by computer readable instructions to render the game asset using the recompressed image written to the texture memory of the GPU (paragraph 0021-0022, “The ports 140 and 160 receive the compacted compressed graphics streams and send them to the decompacting engines 130 and 180, respectively. The decompacting engines 130 and 180 are configured to parse the metadata from the compacted compressed graphics streams, reinsert padding as needed for data alignment (i.e., decompact the compacted compressed graphics streams), and decompress the compressed graphics streams according to the decompression method(s) indicated by the metadata. Each of the shaders 112-118 and 162-168 is a processing element configured to perform specialized calculations and execute certain instructions for rendering computer graphics. For example, shaders 112-118 and 162-168 may compute color and other attributes for each fragment, or pixel, of a screen.”).
As noted above, Feng and Hristova are directed toward methods of image compression and decompression while maintaining speed and efficiency. Riguer is directed toward “a processing system including a plurality of graphics processing units (GPUs), the GPUs transfer compressed graphics streams composed of blocks of graphics data to one another (abstract).” As can be easily seen by one of ordinary skill in the art before the effective filing date Feng, Hristova and Riguer are all directed toward similar methods of endeavor of image compression. Further, Riguer allows for transferring compressed data across multiple GPUs. One of ordinary skill in the art before the effective filing date would be aware that often systems can contain multiple GPUs, and thus there may be a need to transfer data across GPUs based on what specific processing the GPUs are doing (i.e. one GPU may perform a different task than another). Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Riguer in order to ensure smooth and efficient processing of data between GPUs for the method to be carried out on systems including multiple GPUs as opposed to a single GPU.
Regarding dependent claim 36, the rejection of claim 35 is incorporated herein. Additionally, Feng in the combination further discloses wherein to render the game asset by the second GPU,
the GPU is configured by computer readable instructions to provide a decompressed third texture of a game asset from the to the CPU (paragraph 0030, “The GPU 320 has associated texture and video memory 340. The processing involving the DCT, set forth below, takes place within the GPU 320.;” Figure 4, CPU and GPU are connected by a system bus);
the CPU is configured by computer readable instructions to write the decompressed third texture of the game asset to the texture memory of the second GPU (Figure 4, the texture and video memory are attached to the GPU and CPU with s system bus between; paragraph 0030, “The GPU 320 has associated texture and video memory 340. The processing involving the DCT, set forth below, takes place within the GPU 320.”); and
and the second GPU is configured by computer readable instructions to render the game asset using the decompressed third texture written to the texture memory of the second GPU (paragraph 0042, “The computation on a GPU is desirably performed using one or more rendering passes. The working flow of a rendering pass can be divided into two stages. In the first stage, a number of source textures, the associated vertex streams, the render targets, the vertex shader (VS), and the pixel shader (PS) are specified. The source textures hold the input data. The vertex streams comprise vertices that contain the target position and the associated texture address information. The render targets are textures that hold the resulting IDCT results.”).
As noted above, Riguer allows for processing to be carried out on multiple GPUs. Further, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Riguer to ensure multiple textures can be analyzed, as not all images or objects will have the same textures.
Claim(s) 17-18 and 39-40 are rejected under 35 U.S.C. 103 as being unpatentable over Feng further in view of Hristova as applied to claims 15 and 37 respectively above, and further in view of Alakuijala, Jyrki, et al. "JPEG XL next-generation image compression architecture and coding tools." Applications of digital image processing XLII. Vol. 11137. SPIE, 2019. (hereinafter Alakuijala).
Regarding dependent claim 17, the rejection of claim 15 is incorporated herein. Additionally, Feng and Hristova in the combination as a whole fails to explicitly disclose wherein the image is compressed using XYB as a color space and/or using Chroma-from-Luma prediction.
However, Alakuijala discloses wherein the image is compressed using XYB as a color space and/or using Chroma-from-Luma prediction (page 6, “We call this colorspace XYB, where Y is the sum of L and M signaling after reception and X is the difference. B represents the signaling of the S receptors. In JPEG XL we model the compression through storing the cubic root of the value over the receptor’s spectral efficiency.;” page 9, “From the definition of the XYB colorspace, it follows that a fully gray pixel will be represented as a multiple of (0, 1, 0.935669). Keeping this representation as-is is undesirable, as it transmits the luma information on two channels at the same time. Thus, JPEG XL applies a linear transformation to pixel values immediately after dequantization, adding a multiple of the Y channel to the X and B channels.”).
As noted above, Feng and Hristova are directed toward methods of image compression and decompression while maintaining speed and efficiency. Alakuijala is further directed toward, “An update on the JPEG XL standardization effort: JPEG XL is a practical approach focused on scalable web distribution and efficient compression of high-quality images (abstract).” As can be easily seen by one of ordinary skill in the art, Feng, Hristova and Alakuijala are directed toward similar methods of endeavor of image compression and further processing. Additionally, Alakuijala allows for compression of JPEG XL images, as opposed to only traditional JPEG images. Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Alakuijala in order to allow more image types to be compressed as needed.
Regarding dependent claim 18, the rejection of claim 15 is incorporated herein. Additionally, Feng and Hristova in the combination as a whole fails to explicitly disclose wherein the image is compressed using Var-DCT mode only.
However, Alakuijala discloses wherein the image is compressed using Var-DCT mode only (page 6, “JPEG1 is fundamentally based on the 8 × 8 DCT-II algorithm by Arai, Agui and Nakajima.10 Variable-DCT mode of JPEG XL is still based on fundamental 8 × 8 block units, but extends this approach, and allows the use of any bidimensional DCT-II transform whose sides are one of 8, 16, or 32†;” page 12, “This paper introduces the coding tools used in JPEG XL: a new approach for responsive images, and a variable size DCT designed from the ground up for economical storage of high-quality images.”).
As noted above, Feng and Hristova are directed toward methods of image compression and decompression while maintaining speed and efficiency. Alakuijala is further directed toward, “An update on the JPEG XL standardization effort: JPEG XL is a practical approach focused on scalable web distribution and efficient compression of high-quality images (abstract).” As can be easily seen by one of ordinary skill in the art, Feng, Hristova and Alakuijala are directed toward similar methods of endeavor of image compression and further processing. Additionally, Alakuijala allows for more optimal storage of high-quality images. Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Alakuijala in order to conserve storage space to allow processing of an increased number of images.
Regarding dependent claim 39, the rejection of claim 37 is incorporated herein. Additionally, Feng and Hristova in the combination as a whole fails to explicitly disclose wherein the image is compressed using XYB as a color space and/or using Chroma-from-Luma prediction.
However, Alakuijala discloses wherein the image is compressed using XYB as a color space and/or using Chroma-from-Luma prediction (page 6, “We call this colorspace XYB, where Y is the sum of L and M signaling after reception and X is the difference. B represents the signaling of the S receptors. In JPEG XL we model the compression through storing the cubic root of the value over the receptor’s spectral efficiency.;” page 9, “From the definition of the XYB colorspace, it follows that a fully gray pixel will be represented as a multiple of (0, 1, 0.935669). Keeping this representation as-is is undesirable, as it transmits the luma information on two channels at the same time. Thus, JPEG XL applies a linear transformation to pixel values immediately after dequantization, adding a multiple of the Y channel to the X and B channels.”).
As noted above, Feng and Hristova are directed toward methods of image compression and decompression while maintaining speed and efficiency. Alakuijala is further directed toward, “An update on the JPEG XL standardization effort: JPEG XL is a practical approach focused on scalable web distribution and efficient compression of high-quality images (abstract).” As can be easily seen by one of ordinary skill in the art, Feng, Hristova and Alakuijala are directed toward similar methods of endeavor of image compression and further processing. Additionally, Alakuijala allows for compression of JPEG XL images, as opposed to only traditional JPEG images. Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Alakuijala in order to allow more image types to be compressed as needed.
Regarding dependent claim 40, the rejection of claim 37 is incorporated herein. Additionally, Feng and Hristova in the combination as a whole fails to explicitly disclose wherein the image is compressed using Var-DCT mode only.
However, Alakuijala discloses wherein the image is compressed using Var-DCT mode only (page 6, “JPEG1 is fundamentally based on the 8 × 8 DCT-II algorithm by Arai, Agui and Nakajima.10 Variable-DCT mode of JPEG XL is still based on fundamental 8 × 8 block units, but extends this approach, and allows the use of any bidimensional DCT-II transform whose sides are one of 8, 16, or 32†;” page 12, “This paper introduces the coding tools used in JPEG XL: a new approach for responsive images, and a variable size DCT designed from the ground up for economical storage of high-quality images.”).
As noted above, Feng and Hristova are directed toward methods of image compression and decompression while maintaining speed and efficiency. Alakuijala is further directed toward, “An update on the JPEG XL standardization effort: JPEG XL is a practical approach focused on scalable web distribution and efficient compression of high-quality images (abstract).” As can be easily seen by one of ordinary skill in the art, Feng, Hristova and Alakuijala are directed toward similar methods of endeavor of image compression and further processing. Additionally, Alakuijala allows for more optimal storage of high-quality images. Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date to incorporate the teaching of Alakuijala in order to conserve storage space to allow processing of an increased number of images.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
U.S. Patent No. 10,930,020 to Wihlidal discloses, “A computer-implemented method comprises receiving a texture map, segmenting the texture map into a plurality of pixel regions, and for each of the plurality of pixel regions, inputting a vector representation of the pixel region to a compression parameter neural network (abstract).”
U.S. Patent No. 9,679,348 to Smithers et al. discloses, “a method for creating hardware texture content for display on a display of a computing device (abstract).”
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Courtney J. Nelson whose telephone number is (571)272-3956. The examiner can normally be reached Monday - Friday 8:00 - 4:00.
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, John Villecco can be reached at 571-272-7319. 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.
/COURTNEY JOAN NELSON/Primary Examiner, Art Unit 2661