DETAILED ACTION
Claims 1, 4-5, 8, 11-12, 15, 18-19 are amended. Claims 6-7, 13-14, 20-21 are canceled. Claims 1-5, 8-12, 15-19 are pending.
Priority: 3/18/2022
Assignee: Intel
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/5/2026 has been entered.
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.
Claim(s) 1, 4-5, 8, 11-12, 15, 18-19 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.
1.Amended Claims 1,8,15 are rejected for reciting limitations that are unclear, inconsistent and indefinite.
Amended claim 1 recites, ‘the hardware logic to perform a plurality of texel fetch operations based on the plurality of pseudo-random memory addresses to obtain the plurality of texels’.
The spec does not recite this limitation. Furthermore it is well-known in the prior art that a texel fetch operation fetches a texel. Therefore the redundant recitation, ‘….a plurality of texel fetch operations…. ….to obtain the plurality of texels’, provides no new technical information. Since the claim does not recite from where the texels are fetched, or an advantage of the fetch operation supported by the spec, such redundant language only adds verbosity without adding meaning, rendering the claim indefinite.
Hence claim 1 is rejected. Claims 8,15 have the same issue.
2.Amended Claims 1,8,15 are rejected for reciting limitations that are unclear, inconsistent, vague and indefinite.
Claim 1 recites, ‘and to interpolate the plurality of fetched texels to produce to a final texture sample value’. Nowhere does the spec recite this limitation.
Claim 7, submitted as part of the original disclosure recites, ‘wherein at least at least one hash-based fetch operation is to be performed to arrive at a final value that interpolates texels pseudo-randomly’. And spec, Para-1068 recites, ‘the texture lookup…hardware logic 9800 arrives at a final value that interpolates the texels pseudo-randomly associated to the respective texel coordinates via hashing’.
Claim 7 has been canceled and re-introduced into claim 1. But neither amended claim 1 nor the spec describe how the undisclosed, ‘a final texture sample value’ is associated with pseudo-randomly interpolated texels. Hence it is unclear how the original claim 7 limitation is similar to the present limitation.
Since the spec fails to provide any clear definition or support for the present limitation and interpretation, claim 1 is rejected. Claims 8,15 have the same issue.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 1-5, 8-12, 15-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
1.Amended Claim 1 is rejected for reciting a limitation that is unsupported by the spec.
Amended Claim 1 recites, ‘hardware logic to determine a plurality of pseudo-random memory addresses for a plurality of texels based on received texel coordinates,’
Nowhere does the spec recite this broad limitation.
First of all, the spec does not recite ‘hardware logic’. Spec, Para-1072 recites, ‘texture lookup and interpolation hardware logic….’. Since claim 1, recites texture lookup and interpolation, the recited phrase is unsupported by the spec.
Spec, Para-1072 also recites, ‘to determine a pseudo-random memory address for each texel within a memory block….’. The limitation omits reciting, ‘within a memory block’, which is unsupported by the spec.
It is well-known in the art that if a specific memory block is not found during the hash calculation, the system typically treats this as a lookup miss or an invalid access. In some graphics APIs, e.g. CUDA, a failure to resolve a hash to a valid memory location may lead to an out-of-memory error or produce undefined/garbage values. In some cases, a default value may be returned.
However, the spec does not disclose the behavior of the texture lookup and interpolation hardware logic if a ‘memory block’ is not found during the hash or pseudo-random memory address calculation. Hence the recitation constitutes new matter, and claim 1 is rejected for reciting a limitation unsupported by the spec.
2.Amended Claims 1,8,15 are rejected for reciting a limitation that is unsupported by the spec.
Claims 1,8,15 recite, ‘hardware logic’. The phrase, ‘hardware logic’, is broad and claims the entire graphics technology and non-graphics technology.
But spec, Para-1072 recites, ‘texture lookup and interpolation hardware logic….’. Since claims 1,8,15 recite texture lookup and interpolation activity, the recited broad scope is unsupported by the spec. Hence the recitation constitutes new matter and claims 1,8,15 are rejected for the same reason.
Note: In the previous O/A, this issue was indefinite. Because applicant has failed to clarify or amend the claim to define the metes and bounds, the present amendment is considered to recite a scope that is beyond the scope of the disclosure. Hence the rejection has been elevated to a 112(a).
3.Amended Claims 1,8,15 are rejected for reciting a limitation that is unsupported by the spec.
Amended Claim 1 recites, ‘each pseudo-random memory address within the plurality of pseudo-random memory addresses being generated individually through a hash-based lookup process’. The spec does not recite this limitation.
The spec does not recite, ‘within the plurality of….addresses’. However, reciting ‘within the plurality….of… addresses’ suggests a boundary. But the boundary is undefined. Spec, Para-1072 recites, ‘texture lookup….hardware logic to determine a pseudo-random memory address for each texel within a memory block’. So as per the spec, the boundary is defined by the memory block, not by the plurality of P-R memory addresses.
Further, spec, Para-1064 recites, ‘on a texel fetch, a special texture addressing mode allows integer texel coordinates to be hashed…., to arrive at a pseudo-random memory address for each texel within the memory block’.
But the amendment omits reciting the hash input or texel coordinates, an essential element. The amendment recites that each address is generated through the hash-based lookup process, without reciting the hash input/texel. As shown, the amendment is unsupported by spec, Para-1064.
Claim 1 also recites, ‘….through a hash-based lookup process’. But the spec, Para-1068 recites ‘hash-based lookup process’ only once. The spec does not define the lookup process or what it does (no steps). Thus, the broad, solo recitation, ‘hash-based lookup process’ lacks sufficient written description support in the spec.
Claim 1 submitted as part of the original disclosure recites, ‘….use a hash-based addressing mode to determine a plurality of pseudo-random memory address for texels….’. But amended claim 1 recites, ‘each pseudo-random memory address……generated through a hash-based lookup process’. The spec does not recite that an addressing mode (deterministic and direct) is the same as a lookup process (lookup needs search). Para-1068 recites ‘a hash-based lookup process’ w.r.t. interpolation. Taking elements from separate embodiments and combining them in a new way constitutes new matter.
Hence claim 1 is rejected for reciting a limitation unsupported by the spec. Claims 8,15 have the same issue.
4.Amended Claims 1,8,15 are rejected for reciting a limitation that is unsupported by the spec.
Claim 1 recites, ‘….to interpolate the plurality of fetched texels to produce to a final texture sample value’. The spec does not recite this limitation or producing ‘a final texture sample value’.
Though spec, Para-1068 recites, ‘the ….hardware logic 9800 arrives at a final value that interpolates the texels pseudo-randomly associated to the respective texel coordinates via hashing’, the spec does not explicitly recite the final value is a ‘final texture sample value’.
In addition, ‘arrives at a final value’ (focus is on result) is not the same as ‘to produce to a final….value’ (focus is on the steps, which are missing in the spec).
Furthermore, ‘a final texture sample value’ can be a hashed color sample or a stochastic texture sample. Though both involve hashing and pseudo-random number generation, the steps of each are undisclosed.
That said, the limitation recites a broader scope than what is unsupported in the spec. Hence claim 1 is rejected. Claims 8,15 have the same issue.
5.Claims 2,4 are rejected for reciting limitations that recite a memory addressing scheme that is unsupported in the spec.
Claim 2 recites, ‘wherein the texture lookup and interpolation hardware logic comprises a hash unit to perform a hash function over the received texel coordinates to generate the pseudo-random memory address’. And claim 4 recites, ‘wherein the hash unit is to determine the pseudo-random memory address using coefficients of linear congruential generator (LCG)-based functions as input per texture dimension’.
The spec does not provide any written description about the ‘hash function’, ‘pseudo-random memory address’, ‘LCG-based functions’, ‘coefficients of LCG-based functions’ or ‘texture dimension’, as they apply to the disclosure. Though LCG is well-known in the art, there is no disclosure how the LCG-based functions are used to determine the pseudo-random memory address by the hash unit in the claimed ‘apparatus’. There is no disclosure how the hash function interacts with the LCG-based functions (e.g. modular arithmetic) and LCG coefficients.
More importantly, the spec does not recite how the coefficients of the LCG-based functions are determined as input per texture dimension by the hash unit, so that the hash function (spatial hash function ?) can convert the texel coordinates into the PR-memory address and map it to the valid range of memory addresses for the specific texture.
Texture dimension, a non-trivial feature, is the dimensionality used to map image data onto a 3D model. W.r.t. to determining the PR-memory address, the spec does not disclose how the PRNG uses the spatial coordinates (pixels/texels) of the texture dimension as part of its seed or input to ensure that (pseudo) random addresses are generated.
In summary, the spec discloses the result (generating/determining a P-R memory address) but not the specific steps, or parameters (LCG coefficients, hash algorithm etc.) required to achieve it. The spec is merely a generic ‘wish list’ of high-level terminology, rather than a description of the concrete technology used to implement the pseudo-random address generation. The spec does not demonstrate possession of the invention. The spec fails to provide clear structural or functional details such as algorithms, working examples, or configurations to show the applicant was in possession of the claimed invention at the time of filing.
Hence claims 2,4 are rejected because they recite limitations that lack specific written description support in the spec. Accordingly, the spec fails to provide adequate written description support for the limitation, ‘determine a plurality of pseudo-random memory addresses for a plurality of texels….', as recited in amended claim 1.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 8-12, 15-19 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Wei (9264265) in view of Tzeng et al (‘Parallel White Noise Generation on a GPU via Cryptographic Hash’, 2007, Microsoft Research, Pgs. 1-9) and Shi et al (‘A Digital Rights Enabled Graphics Processing System’, 2006, Graphics Hardware, Pgs. 1-10).
As per Claim 1, Wei discloses an apparatus (Wei, [Col. 6, lines 55-60 - In Fig. 6A, the computing device includes processor 605, system memory controller 610, system memory 615, host interface 620, graphics processor 625, graphics memory controller 630, graphics memory 635, display controller 640 and display 645]; [Col. 2, lines 63-66 – As per Fig. 1, the graphics processor includes geometry setup and raster modules, a shader module, a texture module, a parallel hashing module and a pixel write module]) comprising:
a graphics processor (Wei, [Fig. 1: graphics processor 100]; [Fig. 6A: graphics processor 625]) comprising execution resources to execute graphics instructions (Wei, [Col. 6, lines 64-67 - The graphics processor 625 is coupled to graphics memory 635 via the graphics memory controller 630. The graphics memory controller 630 also couples display controller 640 to graphics memory 635]; [Col. 7, lines 29-32 – In Fig. 6A, the primitive parameters, draw commands and instructions are transferred from processor 605 to graphics processor 625 under control of host interface 620]);
hardware logic (Wei, [Figs. 1, 6A-6B]; [See 112(a)]) to determine a plurality of pseudo-random memory addresses for a plurality of texels (Wei, [Col. 3, lines 36-38 - The cryptographic hash function converts an arbitrary bit stream, into a unique fixed-length bit stream of random numbers, e.g., white noise]; [Col. 3, lines 39-40 - A plurality of texture/texel coordinates are hashed to produce corresponding white noise samples]) based on received texel coordinates (Wei, [Col. 5, lines 39-42 - The white noise samples, generated in Fig. 2A, is output as procedural texturing, e.g., mathematically generated texel values, for use by the shader module]; [Col. 3, lines 39-41 - A plurality of texture coordinates are hashed to produce corresponding white noise samples that are returned as texel data to shader module 120; Here white noise, being a random signal with a constant power spectral density across all frequencies, can be processed to create a series of numbers that, when mapped to texel coordinates, will appear as if they were drawn from a pseudo-random distribution, thereby implying that the white noise samples generate the pseudo-random address(es)/locations for texels based on the received texel coordinates. Since the claim does not define ‘pseudo-random address(es)’ and how they are determined, the citation is a valid interpretation]),
each pseudo-random memory address within the plurality of pseudo-random memory addresses ([See 112(a)]) being generated individually through a hash-based lookup process (Wei, [Col. 5, lines 16-29 – In Fig. 2A, step 210, hash inputs are received. Each hash input may be primitive coordinates, one or more texel addresses, base image, a device identifier, user password, etc. At step 220, the hash inputs are evaluated using a cryptographic hash function. Each sample of the hash inputs is evaluated independently and in parallel. The cryptographic hash function generates random numbers having a high degree of entropy in a very short sequence; Since the claim does not define ‘hash-based lookup process’, the citation is a valid interpretation]),
the hardware logic to perform a plurality of texel fetch operations based on the plurality of pseudo-random memory addresses to obtain the plurality of texels (Wei, [Col. 5, lines 39-42 - The white noise samples, generated in Fig. 2A, are output as procedural texturing, e.g., mathematically generated texel values, for use by the shader module; It is well-known that the shader module is associated with fetching texels]),
and to interpolate the plurality of fetched texels (Wei, [Col. 3, lines 43-47 - The white noise samples may then be utilized to produce other types of noise, e.g., pink noise, fractal noise, etc., which involve interpolation. The pink noise and fractal noise are then used as texel data by shader module 120; Interpolated fractal noise is used by the shader module as a dynamic data source of texel data]) to produce to a final texture ([See 112(a)]) sample value (Wei, [Col. 6, lines 24-25 – In Fig. 4, step 440, the generated white noise is bit-wise combined with the received rendered image; The combination of white noise and the rendered image involves linear interpolation and a final texture sample value to achieve procedural texturing effects]).
Tzeng clarifies the texel fetch operations based on the pseudo-random memory addresses as follows,
the hardware logic (Tzeng, [Pg. 4, Col. 2, Sec. 3.3:Usage - GPU noise generator]) to perform a plurality of texel fetch operations (Tzeng, [Pg. 2, Col. 1, Para-1 - The system computes random numbers in parallel just like ordinary texture fetches: given a texture coordinate per pixel, instead of returning a texel as in ordinary texture fetch, the pixel program computes a random noise value based on this given texture coordinate]) based on the plurality of pseudo-random memory addresses to obtain the plurality of texels (Tzeng, [Pg. 2, Col. 1, Para-2 - Allows parallel and completely independent random noise generation per pixel with constant time complexity]; [Pg. 3, Col. 2, Para-1 - Tile location/address hashing can be computed on the fly]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the parallel white noise generator of Tzeng into the texture processing of Wei, for the benefit of using a reliable source of random numbers as a random variable with uniform distribution. The uniform distribution is often called ‘white noise’ since signals drawn from such a distribution contain a roughly equal amount of energy across all frequency bands (Tzeng, Pg. 1, Col. 1, Para-3).
Shi clarifies the texel fetch and interpolation as follows,
the hardware logic to perform a plurality of texel fetch operations (Shi, [Fig. 1, Pg. 2, Col. 2, Para-2 - For each fragment, there is a set of corresponding texels. The fragment stage computes texture access addresses based on the texel coordinates and fetch the associated texture values from the textures stored in the GPU’s memory]) based on the plurality of pseudo-random memory addresses to obtain the plurality of texels (Shi, [Fig. 7, Pg. 8, Col. 2, Para-2 - The underlying block cipher is a pseudo-random function family and a new unique counter value is used for each chunk of encrypted data. For graphics data, texel coordinates or vertex indices are all valid choices as counters]; [Fig. 7, Pg. 8, Col. 2, Para-3 - The pseudo-random bits can be computed using standard ciphers such as AES by taking texture tile coordinate or depth buffer tile coordinate as input. This will generate unique pseudo-random bits for each texture tile or depth buffer tile]),
and to interpolate the plurality of fetched texels (Shi, [Fig. 7: texture fetch unit]; [Pg. 6, Col. 1, Para-2 - Fig. 6 shows how to declare an encrypted texture using extended OpenGL texture API, thereby implying use of texelFetch API]; [Pg. 6, Col. 1, Para-2 - Using tile is compatible with how GPU fetches texture data from memory into its texture cache]) to produce to a final texture sample value (Shi, [Fig. 1, Pg. 2, Col. 2, Para-2 - The fragment stage combines the fetched texture color with the interpolated lighting color to generate the fragment’s final color; Here the combination of the fetched texture color and the interpolated lighting color involves additional interpolation called texture filtering or texture interpolation, to generate the final color; ‘A final texture sample value’ is the particular color derived from a texture image for a particular pixel on a 3D model, by combining neighboring texels based on UV coordinates, interpolation, and wrapping modes; Since neither the claim nor spec define it, the citation is a valid interpretation]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the pseudo-random bits of Shi into the texture processing of Wei, Tzeng for the benefit of reducing the decryption latency overhead, wherein the pseudo-random bit strings or pads used for decryption can be pre-computed in parallel with memory fetch when the texture tile coordinate or depth buffer tile is ready (Shi, Pg. 8, Col. 2, Para-3).
As per Claim 2, the rejection of claim 1 is incorporated, and Wei discloses,
wherein the hardware logic (Wei, [Fig. 1]) comprises a hash unit (Wei, [Fig. 1: parallel hashing module 140]) to perform a hash function over the received texel coordinates to generate a pseudo-random memory address (Wei, [Col. 3, lines 34-41 - The parallel hashing module 140 evaluates the one or more hash inputs utilizing a cryptographic hash function. The cryptographic hash function converts an arbitrary bit stream, into a unique fixed-length bit stream of random numbers, e.g., white noise. A plurality of texture coordinates are hashed to produce corresponding white noise samples that are returned as texel data to shader module 120; Here white noise, being a random signal with a constant power spectral density across all frequencies, can be processed to create a series of numbers that, when mapped to texel coordinates, will appear as if they were drawn from a pseudo-random distribution, thereby implying that the white noise samples generate the pseudo-random address(es)/locations. Hence the citation implies performing a hash function over the received texel coordinates to generate the pseudo-random memory address(es)]).
As per Claim 3, the rejection of claim 2 is incorporated, and Wei discloses,
wherein the hash unit is configurable for application-specific hashing modes (Wei, [Col. 4, lines 5-11 - The hash input to the parallel hashing module 140 may be a device identifier, e.g., graphics processor device identifier, user password etc. Accordingly, by combining a rendered image with white noise generated by hashing a device identifier it is possible to uniquely determine the specific device/computer or the individual/user that generated the image]; [Col. 3, lines 27-29 - The shader 120 utilizes the parallel hashing module 140 for texturing functions]).
As per Claim 4, the rejection of claim 3 is incorporated, and Wei, Tzeng, Shi disclose,
wherein the hash unit is to determine the pseudo-random memory address (Tzeng, [Pg. 1, Col. 1, Para-4 - Produce pseudo-random numbers via mathematical methods such as linear congruential regression]; [Pg. 2, Col. 1, Para-1 - Given a texture coordinate per pixel, the pixel program computes a random noise value based on this given texture coordinate]) using coefficients of linear congruential generator (LCG)-based functions as input per texture dimension (Tzeng, [Pg. 2, Col. 2, Sec. 3.1 - Popular PRNGs/pseudo-random number generators, such as linear congruential generators/LCG, have an internal state that is updated with each iteration of the generator. Thus, these PRNGs are order dependent as the time to retrieve the (i+n)th output given the ith output is linear with n; Since the claim does not define LCG, ‘coefficients of LCG based functions’ and how they are used to determine the ‘pseudo-random memory address’, the citation is a valid interpretation]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the LCG of Tzeng into the texture processing of Wei, Shi for the benefit of guaranteeing order invariance in the output (Tzeng, Pg. 2, Col. 2, Para-4).
As per Claim 5, the rejection of claim 3 is incorporated, and Wei, Tzeng, Shi disclose,
wherein the hash unit (Tzeng, [Pg. 3, Sec. 3.3 - MD5GPU]) is to determine the pseudo-random memory address (Tzeng, [Pg. 5. Sec. 5.1, Para-2 - Due to the random accessibility of the noise generator, any location/address on the terrain can be queried/determined in constant time and the height is always invariant]) in accordance with a user-specified block size that limits hashing to only some bits of texel coordinates (Tzeng, [Pg. 3, Col. 2, Sec. 3.3, Para-4 - Although the input into MD5 is specified as 512-bits, the user does not specify all 512-bits of the input. He uses only 2D texture coordinates, specified from (1….width) and (1….height), thereby implying limiting hashing to only some bits of the texel coordinates]; [Pg. 7, Col. 2, Para-1 - Fig. 3 shows an image of the fractal terrain demo using MD5GPU and this demo renders a terrain using 70×70 vertices running at 60 frames per second. The size of the terrain is limited by floating point precision; Also see Pg. 7, Sec. 5.2 – Texture Tiling]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the cryptographic hash unit, MD5GPU of Tzeng into the texture processing of Wei, Shi for the benefit of using the random accessibility of the noise generator to query any location on the terrain in constant time and the height will always be invariant (Tzeng, Pg. 7, Sec. 5.1, Para-2).
As per Claim 8, Wei discloses a method (Wei, [Col. 6, lines 55-60 - In Fig. 6A, the computing device includes processor 605, system memory controller 610, system memory 615, host interface 620, graphics processor 625, graphics memory controller 630, graphics memory 635, display controller 640 and display 645]; [Col. 1, lines 53-54 – A method of generating white noise for use in graphic and image processing]) comprising:
executing graphics instructions on execution resources of a graphics processor (Wei, [Fig. 1: graphics processor 100]; [Fig. 6A: graphics processor 625]; [Col. 7, lines 29-32 – In Fig. 6A, the primitive parameters, draw commands and instructions are transferred from processor 605 to graphics processor 625 under control of host interface 620]), one or more of the graphics instructions to read and/or write texels within a memory block (Wei, [Col. 3, lines 19-21 - The pixel write module 150 stores the pixel data as a rendered image in a memory, such as a frame buffer; In graphics, a texel is a single pixel within a texture, while a pixel is a single point of a display/image on the screen. A texel represents a discrete unit within a texture map, which is then mapped onto the surface of a 3D object]);
The remaining limitations are similar to claim 1 and therefore the same rejections are incorporated.
As per Claim 9, it is similar to claim 2 and therefore the same rejections are incorporated.
As per Claim 10, it is similar to claim 3 and therefore the same rejections are incorporated.
As per Claim 11, it is similar to claim 4 and therefore the same rejections are incorporated.
As per Claim 12, it is similar to claim 5 and therefore the same rejections are incorporated.
As per Claim 15, it is similar to claims 1,8 and therefore the same rejections are incorporated.
As per Claim 16, it is similar to claim 2 and therefore the same rejections are incorporated.
As per Claim 17, it is similar to claim 3 and therefore the same rejections are incorporated.
As per Claim 18, it is similar to claim 4 and therefore the same rejections are incorporated.
As per Claim 19, it is similar to claim 5 and therefore the same rejections are incorporated.
Response to arguments
The Applicant's arguments filed on February 05, 2026 have been fully considered, but they are not persuasive.
Applicant argues: ‘The Applicant amends claim 1 ….recited "hardware logic" in amended claim 1 corresponding to the disclosed structure in the section entitled "Apparatus and Method for Hardware Accelerated Texture Lookup and Interpolation,"….title of the application’. (Rem, Pg. 7)
Response: As mentioned in the present O/A, the issue has been elevated to a 112(a) because the 112(b) in the previous O/A has not been resolved. ‘Hardware logic’ recited in claim 1, is broad compared to ‘texture lookup and interpolation hardware logic’ recited in the spec.
‘Texture lookup and interpolation hardware logic’ is a subset of ‘hardware logic’. The scope of ‘hardware logic’ is unsupported by the spec.
‘Hardware logic’, in addition to texture lookup and interpolation logic, also includes CPUs, DSPs, FPGAs, ALUs, vertex processors, embedded microcontrollers, tessellation units, memory controllers etc., that do not perform texture mapping and interpolation. ‘Hardware logic’ is not limited to graphics.
Applicant further argues: ‘The amendment is supported by Specification, e.g., paragraphs [00897] to [00898] and Figure 98’. (Rem, Pg. 7)
Response: For examination the PGPUB has been used because the PGPUB is a formal, official document published by the USPTO. The arguments refer to paragraph numbers in the initial submission which are inconsistent with the PGPUB. Compared to the initial submission, the PGPUB contains the necessary corrections, amendments, or formatting required for publication.
For the present application, PGPUB paragraphs [1064-1075] correspond to paragraphs [00896-00908] of the initial submission.
Applicant further argues: ‘In one use case, the coordinates of a texel to be interpolated are provided, based on which the adjacent texels may be identified, and each of the adjacent texels is then fetched, and the fetch of such texels "individually undergoes [a] hash-based lookup process." Specification paragraph [00900]’. (Rem, Pg. 8)
Response: This argument is incorrect.
Nowhere does the spec define ‘hash-based lookup process’ or the steps in the lookup process. The spec recites ‘hash-based lookup process’ fleetingly, only once, in Para-1068 as, ‘….each texel fetch performed by the texel access unit 9811 that is required to compute the interpolated value individually undergoes the hash-based lookup process via access to the hash functions of the hash unit 9810’.
The spec does not disclose what comprises ‘hash functions of the hash unit 9810’. In other words, there is no disclosure of how the hash functions are utilized.
Spec, Para-1068 also recites, ‘On texture sampling using interpolation modes such as,…., linear, bilinear, triliniar and quadrilinear interpolation….’, without explicitly reciting which of these modes is most applicable to the disclosure. Neither does the spec provide a working example of the texel fetch using at least one of these interpolation modes. Neither does the spec provide any concrete evidence to show that all the interpolation modes are applicable to the disclosure.
The spec does not clearly recite how texels are identified for interpolation. That said, the applicant does not mention if the above mentioned, undisclosed ‘use case’ utilizes any (or all) of the four interpolation modes or some other vague mode.
The spec is a high-level overview of graphics processing. It lacks details. And because the spec lacks details, the applicant is attempting to redefine the hash-based lookup process and texture interpolation, after filing.
Applicant further argues: ‘The amended claim 1 further includes "hardware logic…to interpolate…to a final texture sample value," which may be viewed as similar to the previously presented claim 7,…now canceled. The Office Action cites Shi for…claim 7, and the ….Shi does not teach…amended claim element in claim 1’. (Rem, Pg. 8)
Response: This argument is incorrect. Please see the 112(b) and 112(a).
Nowhere does the spec recite, ‘to interpolate the plurality of fetched texels to produce to a final texture sample value’. Nowhere does the spec provide any written description support to show that the claim 1 limitation can be considered similar to original claim 7.
Neither amended claim 1 nor the spec describe how in texture mapping, a final texture sample value is associated with pseudo-randomly interpolated texels.
The spec does not provide any indication to support the applicant’s narrow interpretation. Hence the limitation is improper. Relying on an improper limitation to mischaracterize prior art invalidates the limitation and the argument.
Applicant further argues: ‘In Shi, the lighting color has been interpolated already before it is combined with the fetched texture’. (Rem, Pg. 8)
Response: This argument is incorrect.
In Fig. 1, Pg. 2, Para-2, Shi discloses that the fragment stage of the rasterizer combines the fetched texture color with the interpolated lighting color to generate the fragment’s final color. The combination of the fetched texture color and the interpolated lighting color involves additional interpolation called texture filtering (or texture interpolation), to generate the final color. It is well known in the art that texture filtering uses linear interpolation between multiple texels.
Therefore it is valid to interpret ‘a final texture sample value’ as the particular color derived from a texture image for a particular pixel on a 3D model, by combining neighboring texels based on UV coordinates, interpolation (linear/bilinear/trilinear), and wrapping modes.
P.S. A good textbook for the present application is ‘Texture Mapping (V) in 3D Computer Graphics’ by Samuel R. Buss.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARVIND TALUKDAR whose telephone number is (303)297-4475. The examiner can normally be reached M-F, 10 am-6pm EST.
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, Hosain Alam can be reached at 571-272-3978. 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.
Arvind Talukdar
Primary Examiner
Art Unit 2132
/ARVIND TALUKDAR/Primary Examiner, Art Unit 2132