DETAILED ACTION
Claims 1-2, 8-9, 15-16 are amended. Claims 6-7, 13-14, 20-21 were previously 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 .
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.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Claim(s) 1-5, 8-12, 15-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 a limitation that is unclear, inconsistent and indefinite.
Claim 1 recites, ‘hardware logic….to determine a plurality of pseudo-random memory addresses for a plurality of texels based on received texel coordinates, wherein the hash unit is configured to determine a pseudo-random memory address for a respective texel within a memory block allocated to a texture’.
The claim is inconsistent with the spec. Para-1072 of the spec recites, ‘….hardware logic to determine a pseudo-random memory address for each texel within a memory block allocated to back a sampled texture’.
The limitation recites that the hardware logic is configured to determine ‘a plurality of pseudo-random memory addresses for a plurality of texels….’ and that the hash unit determines an address for ‘a respective texel within a memory block…’. Conversely, the spec states that the hardware logic determines a pseudo-random memory address for ‘each texel within a memory block allocated to back a sampled texture’.
It is unclear whether the hardware logic must calculate addresses for all (‘each’) texels within the allocated memory block as described in the spec, or merely for a subset (‘a respective texel’) of texels as recited in the claim.
Furthermore, the ‘wherein’ limitation introduces ‘a texture’ without a clear relationship to the previously recited ‘plurality of texels’ or the spec's ‘sampled texture’. Because of these discrepancies, the scope of the claim is indefinite. Hence claim 1 is rejected. Claims 8, 15 also have the same issue and are rejected.
2.Amended Claims 1, 8, 15 are rejected for reciting limitations that are unclear, inconsistent and indefinite.
Claim 1 recites 'the texel access unit to perform a plurality of texel fetch operations based on the plurality of pseudo-random memory addresses determined by the hash unit, wherein for an interpolation operation involving the plurality of fetched texels, the hash unit determines a respective pseudo-random memory address for each texel used in the interpolation operation'. As recited, the claim contradicts the spec.
In Para-1068, the spec recites 'each texel fetch performed by the texel access unit 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. Thus the hardware logic arrives at a final value that interpolates the texels pseudo-randomly associated to the respective texel coordinates via hashing'.
The claim implies that the hash unit determines memory addresses for a plurality/group of texels used in an interpolation operation, enabling the texel access unit to fetch them. However, this conflicts with the explicit sequence disclosed in the spec.
In Para-1068, the spec discloses a sequential pipeline where each individual texel fetch undergoes its own hash-based lookup process sequentially during its individual fetch operation. But the claim introduces an ambiguous scope by claiming a ‘plurality of texel fetch operations’ and a ‘plurality of pseudo-random memory addresses’ configured for an ‘interpolation operation involving the plurality of fetched texels’.
It is unclear how the claimed parallel calculation of the addresses is related to the individual, sequential lookup pipeline disclosed in the spec.
Because the claim uses broad terms that contradicts the specific language of the spec (‘each…. individually undergoes’), the scope of the relationship between the hash unit and the texel access unit is unclear, rendering the claim indefinite.
Furthermore, the use of the generic phrase ‘an interpolation operation’ also renders the scope of the claim unclear because it does not clearly recite how the specific interpolation operation involves the claimed hash unit and the texel access unit. Hence claim 1 is rejected. Claims 8, 15 also 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.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
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 Claims 1, 8, 15 are rejected for reciting a limitation that is unsupported by the spec.
Claim 1 recites ‘hardware logic comprising a hash unit and a texel access unit’. The spec does not state this limitation.
In Para-1065, the spec recites, ‘….texture lookup and interpolation hardware logic 9800, including a hash unit 9810 and a texel access unit 9811’. The spec describes a specific use case, ‘texture lookup and interpolation hardware logic’ and limits the hardware to this specific function.
The claim drops the phrase ‘texture lookup and interpolation’. It claims generic ‘hardware logic’ with a hash unit and a texel access unit.
By canceling ‘texture lookup and interpolation’, the claim covers hardware logic used for any purpose, such as the entire graphics technology, network routing, cryptography and other non-graphics technology, even if the spec never mentions or enables those other uses.
Because the spec does not provide descriptive details for the broader, generic version of ‘hardware logic’, the claim recites a scope unsupported by the spec and is rejected. Claims 8, 15 have the same issue and are rejected.
Note: Based on amendments and arguments, the rejection is maintained.
2.Amended Claims 1, 8, 15 are rejected for reciting a limitation that is unsupported by the spec.
Claim 1 recites, ‘hardware logic comprising a hash unit and a texel access unit to determine a plurality of pseudo-random memory addresses for a plurality of texels ???? based on received texel coordinates, wherein the hash unit is configured to determine a pseudo-random memory address for a respective texel within a memory block allocated to a texture’.
Nowhere does the spec recite these limitations.
Claims 1-2 submitted as part of the original disclosure recite, ‘….hardware logic to use a hash-based addressing mode to determine a plurality of pseudo-random memory address for texels within a memory block based on received texel coordinates, wherein the ….hardware logic comprises a hash unit to perform a hash function over the received texel coordinates to generate the pseudo-random memory address’.
‘hash unit’ is a hardware module and ‘hash-based addressing mode’ is a software configuration state. The spec does not teach that they are the equivalent (see spec, Para-1067).
The spec only describes a specific method where the hardware logic uses ‘a hash-based addressing mode’ and the hash unit specifically to ‘perform a hash function over the received texel coordinates to generate the pseudo-random memory address’. That is, the spec supports a hash unit that generates an address by actively executing a hash function over the incoming coordinates. However, the claim is so broad that it covers a hash unit that determines these addresses by any mechanism (e.g., using a pre-computed table, utilizing a different mathematical sequence, or retrieving a cached address, etc.), so long as the final address is pseudo-random and the unit is generically called a ‘hash unit’.
Because the limitation claims a broad functional result (determining a PR address) while the spec only discloses one specific method (performing a hash function over received texel coordinates using a hash-based addressing mode), the spec fails to support the broad limitation. The spec fails to show that the inventor was in possession of the broad claim at the time of filing. In addition, the newly amended language recites a different concept absent from both the original spec and the original claims.
While the spec mentions a hash unit, it provides no details, algorithmic steps etc., explaining how the hash unit determines a pseudo-random memory address for a respective texel….. Merely reciting the function in the spec and claim (‘determines a pseudo-random….’) does not establish that the applicant was in possession of a specific method for performing that function at the time of filing.
Consequently claim 1 is rejected. Claims 8, 15 have the same issue and are rejected.
3.Amended Claims 1, 8, 15 are rejected for reciting a limitation that is unsupported by the spec.
Claim 1 recites, ‘wherein for an interpolation operation involving the plurality of fetched texels, the hash unit determines a respective pseudo-random memory address for each texel used in the interpolation operation’.
The limitation is entirely functional and complex. The spec fails to provide any details, algorithmic steps, or technical guidance on how a hash function is applied to achieve independent pseudo-randomized memory addresses on a per-texel basis during interpolation. While the spec superficially mentions a hash unit, a texel access unit, texturing, and fetching texels, it is completely silent on this specific pseudo-random addressing mechanism mapped dynamically to individual texels during an interpolation operation.
Merely reciting this specialized result in the claims without a corresponding description how the mechanism is achieved in the spec, fails to demonstrate that the applicant actually possessed how the hash unit calculates, maps, or ‘determines a respective pseudo-random memory address for each texel used in the interpolation operation’, at the time of filing.
Hence claim 1 is rejected for failing to comply with the written description requirement. Claims 8, 15 have the same issue and are also rejected.
4.Claims 2, 4, 9, 11, 16, 18 are rejected for reciting limitations that recite a memory addressing scheme that is unsupported in the spec.
Claim 2 recites, ‘wherein the 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 fails to teach 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 pseudo-random 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 pseudo-random 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. Claims 2, 4 are 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 fails to provide clear details such as algorithms, working examples, or configurations to show the applicant was in possession of 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’, at the time of filing.
Hence claims 2, 4 are rejected because they recite limitations that lack specific written description support in the spec. Claims 9, 11, 16, 18 have the same issue and are also rejected.
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) (as evidenced by Green, ‘https://developer.nvidia.com/gpugems/gpugems2/part-iii-high-quality-rendering/chapter-26-implementing-improved-perlin-noise’, 2005, and Shi et al ‘A Digital Rights Enabled Graphics Processing System’, 2006, Graphics Hardware, Pgs. 1-10) in view of Tzeng et al (‘Parallel White Noise Generation on a GPU via Cryptographic Hash’, 2008, ACM, Pgs. 79-87) and in further view of Perlin (8111261) (as evidenced by Shi et al ‘A Digital Rights Enabled Graphics Processing System’, 2006, Graphics Hardware, Pgs. 1-10), hereinafter ‘Wei,Tzeng,Perlin’.
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 comprising a hash unit (Wei, [Fig. 1: parallel hashing module 140]) and a texel access unit (Wei, [Fig. 1: texture module 130]) 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, thereby implying that the output bitstream is the memory address destination]; [Col. 3, lines 39-40 - A plurality of texture/texel coordinates are hashed to produce corresponding white noise samples]; [Col. 3, lines 27-29 - shader 120 may utilize the parallel hashing module 140 for texturing functions; Since downstream modules apply mathematical bounding e.g. bit-masking to map the random bitstream into a specific table range, the hash output is bounded to match an array configuration, and acts as an address index]), based on received texel coordinates (Wei, [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 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 determine the pseudo-random address(es) for texels based on the received texel coordinates. Furthermore the noise values serve as destination address indices for pixel write operations via pixel write module 150, thereby implying that the destination address indices are pseudo-random addresses. Since neither the spec nor the claim define ‘pseudo-random address(es)’ and how they are generated, the citation is a valid interpretation]),
wherein the hash unit (Wei, [Fig. 1: parallel hashing module 140]) is configured to determine a pseudo-random memory address for a respective texel (Wei, [Claim 1 - Each sample of the hash input is evaluated independent and in parallel to generate one or more white noise samples; This implies that when the hash module outputs a deterministic, scattered value based on an input position, that value can function directly as a memory pointer, index, or offset,.i.e. Target coordinate = Base Coordinate + pseudorandom value];) within a memory block allocated to a texture (Wei, [Col. 3, lines 17-21 - The pixel write module 150 outputs pixel data produced by the shader module 120. The pixel write module 150 stores the pixel data as a rendered image in memory, such as a frame buffer, thereby implying a memory block/bounds allocated to a texture dictated by the hash module]; [The claim elements are evidenced by: Green, GPU Gems 2, Chapter 26, Sec. 26.3, 26.3.1 where - ‘hash unit’: A texture fetching unit for a lookup, ‘pseudo-random memory address for a respective texel’:A computed texture coordinate (u,v) pointing to an index in a permutation array, ‘memory block allocated to a texture’:A 1D/2D texture buffer (permTexture)]; [Sec. 26.3 shows how a precalculated permutation table/array is stored in a 1D texture (permTexture) to function as a pseudorandom memory lookup table. Therefore a small, repeating permutation table (a hash) stored as a tiny texture dynamically calculates pseudorandom coordinates/addresses. Green provides evidence that implementing procedural texturing inherently configures a graphic processor’s texture sampling hardware (‘hash unit’) to look up pseudo-random indices/addresses within an allocated texture buffer]),
the texel access unit to perform a plurality of texel fetch operations (Wei, [Col. 3, lines 22-26 - The shader module 120 utilizes the texture module 130 to provide texture mapping, e.g., texel address. The texture module 130 receives one or more texture coordinates from the shader module 120 and returns the corresponding texel data from one or more appropriate textures stored in memory; Since the module takes an input spatial parameter, directly calculates the exact physical pixel offset in memory, and returns the data, it implies performing texel fetch operations]; [The claimed ‘texel fetch operations’ is evidenced by: Shi, Fig. 7 - Texel Fetch Unit/Texture cache]; [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 implying texel fetch operations]) based on the plurality of pseudo-random memory addresses determined by the hash unit (Wei, [Col. 3, lines 27-20 - shader 120 utilizes the parallel hashing module 140 for texturing functions]; [Col. 3, lines 48-50 - parallel hashing module 140 is utilized to generate white noise for encrypting images; As shown in Figs. 3A-3D,5A-5B, hash module 140 hashes the inputs to generate pseudo-random outputs. Downstream in the graphics pipeline, these outputs act as array indices or address offsets for writing to memory/pixel write 150 and image processing operations by mapping memory dynamically, thereby implying fetching texels based on the pseudo-random memory addresses determined by the hash unit]),
wherein, for an interpolation operation involving the plurality of fetched texels (Wei, [Col. 3, lines 43-47 – The white noise samples are 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 which involves texel fetch operations as explained above]; [The claimed ‘interpolation operation involving fetched texels’ is evidenced by: Green, Sec. 26.3 which shows the interpolation roadmap as, deterministic coordinates -> parallel hashing -> pseudo-random address selection(texture fetch) -> interpolation operation]),
the hash unit determines a respective pseudo-random memory address for each texel used in the interpolation operation (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 texturing effects]; [Texels are fetched to perform texture lookup. And performing texture lookup with hashing is evidenced by: Green, Sec. 26.3.1 - The texture lookup architecture uses a 256x256-pixel RGBA 2D texture containing permutation tables. To determine pseudo-random memory addresses the shader takes an object's spatial coordinates, uses them to compute a hash vector, and executes a single 2D dependent texture lookup. The randomized values stored at that generated address provide the pseudo-random offsets/addresses]; [Sec. 26.3, Para-3 – ‘The final value is obtained by interpolating between the noise values for each of the neighboring eight points in space’. This suggests that after identifying the grid vertex coordinates via pseudo-random values, the final values are interpolated. So the eight corners of a 3D unit cube are smoothed into a continuous value by the Perlin algorithm. So Green provides evidence that the limitation merely recites the functional steps of implementing Perlin noise on standard graphics hardware]).
Wei recites receiving hash inputs like texel coordinates and evaluating them via a hash function to produce pseudorandom values used as texel data. Sections 26.3 and 26.3.1 of Green provides evidence to show how this is done. Green shows how ‘hashing an input coordinate’ is performed by routing a texture coordinate into a permutation table (permTexture) using shader code (tex1D or packed tex2D).
Wei recites generating pseudo-random values but inherently suggests using a hash unit to determine a pseudo-random memory address for a texel because Sections 26.3 and 26.3.1 of Green provides evidence showing that whenever a hash-based noise or permutation scheme is executed, it relies on the texture mapping hardware calculating pseudo-random indexing positions/addresses inside an allocated 2D texture. This indicates that Wei discloses ‘determining a pseudo-random memory address for a texel….to a texture’.
Tzeng clarifies that the hash unit uses the PRNG to generate pseudo-random memory addresses as follows,
wherein the hash unit (Tzeng, [Pg. 80, Col. 1, Sec. 3.1 - PRNGs, such as linear congruential generators]) is configured to determine a pseudo-random memory address (Tzeng, [Pg. 80, Col. 1, Para-1 - Given a texture coordinate per pixel, the pixel program computes a random noise value/white noise/pseudo-random address based on this given texture coordinate]; [Pg. 83, Col. 2, Sec. 4. 2, Para-2 - hashes were fed 2D texture coordinates and PRNGs used the current time for its seed]) within a memory block allocated to a texture (Tzeng, [Pg. 81, Col. 2, Sec. 3.3 - uvec4 digest = whiteNoise (texCoord, key); The function whiteNoise takes inputs (texCoord, key) and feeds them into the cryptographic hash function, MD5. Therefore, sequentially adjacent pixel coordinates (texCoord) map to pseudo-random bit patterns; It is well-known that pseudo-random bit patterns map directly to a pseudo-random address because the bit pattern is a numeric value that points to a specific location in a memory space]),
Shi provides evidence for texel fetch operations and Green provides evidence for determining pseudo-random memory addresses using hash-based texture lookups.
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 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).
Wei, Tzeng disclose static white noise. Perlin uses interpolation to transform the chaotic, static white noise into a smooth Perlin noise texture as follows,
wherein, for an interpolation operation involving the plurality of fetched texels (Perlin, [Col. 6, lines 36-49 - The entire mechanism consists of three successive pipelined stages: hashing, gradient and interpolation. The first hashing stage computes a pseudo-random hash value at each vertex of the unit cube C surrounding the point. The second gradient stage uses these hash values, together with the offset of the point from each of the cube vertices, to compute the contribution from that vertex. The third interpolation stage combines these eight intermediate results into a single interpolated final result; It is known in the art that a vertex corresponds to a texel by translating 3D spatial coordinates into 2D texture coordinates]; [The claimed ‘fetched texels’ is evidenced by: Shi, Fig. 7 - Texel Fetch Unit/Texture cache]; [Pg. 8, Col. 1, Sec. 5.1.2 - SHA-256 hashing algorithm]),
the hash unit determines a respective pseudo-random memory address for each texel used in the interpolation operation (Perlin, [Col. 6, lines 50-52 – The hashing stage consists of six ‘+’/adder modules and seven L/LUT modules; So the pseudo-random address for each texel is computed via a pipeline of six adder modules and seven look-up table modules that mix coordinate bits]; [Col. 6, lines 59-63 – The pseudo-random table of stored values are pseudo-random addresses]; [Col. 4, lines 54-64 - Inputting a point (x,y,z) in 3-D space. Computing a pseudo-random hash value at each vertex of a unit cube C surrounding the point. The next step computes a contribution from each vertex using the hash-value. The last step combines the contribution from each vertex into a single interpolated result; Since the spec does not disclose how the ‘interpolation operation’ is performed, the citation is a valid interpretation]).
Shi provides evidence for a 3D graphics pipeline with texel fetch operations and passing texture tile coordinates and padding to calculate the pseudo-random bit strings or pseudo-random addresses for the texels. By executing operations like texture fetching and interpolation within a cryptographically isolated boundary, the Shi’s system decodes texels and prevents data exposure.
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the interpolation of Perlin into the texture processing of Wei, Tzeng for the benefit of three successive pipelined stages of hashing, gradient and interpolation to compute pseudo-random hash values at each vertex of a unit cube surrounding an evaluation point using the pipeline of adders/+ and look-up table/L modules. It then maps the resulting bits to gradient vectors and combines their contributions via interpolation to produce smooth noise textures (Perlin, Col. 4, lines 35-51).
As per Claim 2, the rejection of claim 1 is incorporated, and Wei discloses,
wherein the hash unit (Wei, [Fig. 1: parallel hashing module 140]) is 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 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, Perlin 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, Perlin 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, Perlin 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, Perlin 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 July 17, 2026 have been fully considered, but they are not persuasive.
Applicant argues:‘Instead, claim 1 now recites that the hardware logic comprises…., that the hash unit determines pseudo-random memory addresses based on received texel coordinates, and….pseudo-random memory addresses determined by the hash unit’. (Rem, Pg. 6)
Response: Amended Claim 1 has multiple issues. None of the limitations align with the spec. The limitations are unsupported extrapolation of the specific paragraphs (Paras:1064-1075) disclosed in the spec.
The applicant cherry-picks and mixes mutually exclusive limitations from different paragraphs. Just because feature X is disclosed in Para-1, and feature Y is disclosed in Para-2, it does not mean the inventor has shown they possessed the combination of X+Y at the time of filing.
Since the spec relies purely on functional results without disclosing ‘how-to’, any limitation attempting to add/fill-in the missing technical details violate 35 U.S.C. 132 (new matter).
The amended claims fail to resolve the previous issues because the new limitations introduce new non-compliance with the statutes, thereby maintaining the structural deficiencies of the claims. Consequently, the deficiencies are not cured but compounded. Please see the new 112(a)’s and 112(b)’s.
Applicant further argues:‘The Office previously objected to the breadth of the phrase "hardware logic," asserting that it encompassed…….Applicant has amended the claim to recite that the hardware logic …..including hash unit 9810 and texel access unit 9811’. (Rem, Pg. 7)
Response: This argument is incorrect. In the previous O/A, the Office issued a 112(a) rejection of the claim, not an objection.
The present amendment is inadequate. It does not resolve the issue.
Para-1065 of the spec explicitly recites, ‘….texture lookup and interpolation hardware logic 9800, including a hash unit 9810 and a texel access unit 9811’. The spec describes a specific use case, ‘texture lookup and interpolation hardware logic’ and limits the hardware to this specific function.
The claim omits the phrase ‘texture lookup and interpolation’ and broadly claims generic ‘hardware logic’ with a hash unit and a texel access unit, thereby reciting a scope beyond the spec. Hence the rejection is maintained.
Applicant further argues:‘The Office also asserted that the Specification did not adequately support generation of pseudo-random memory addresses. However, the Specification expressly discloses that a special texture addressing mode allows integer texel coordinates….within a memory block allocated to a sampled texture’. (Rem, Pg. 7)
Response: While the spec mentions a hash unit, it provides no written description to achieve the claimed pseudo-random address determination. It fails to provide any details, algorithm(s), roadmap etc., explaining how the hash unit ‘determines a pseudo-random memory address for a respective texel within a memory block allocated to a texture’, as claimed.
Merely reciting the function (‘determine a pseudo-random….address….’) in the spec and claim without details does not establish that the inventor was in possession of a specific method for performing that function at the time of filing.
The reference to ‘special texture addressing mode’ is from Para-1068 of the spec. It is a non-trivial topic. The 2-3 casual lines in the spec do not fulfill the written description requirement of how interpolation requires every individual texel fetch to independently undergo a hash-based texture lookup process. Neither does the spec disclose the details of resolving the hash function for each separate neighbor required for the interpolated calculation. Therefore the spec does not disclose determining how hash-based addressing maps texel coordinates to pseudo-random memory addresses.
As an aside, the spec (in its entirety) focusses on shaders in ray tracing that require texture filtering via bilinear or trilinear interpolation. There is a high-level discussion of hardware built into the GPU to calculate sequential texture memory addresses required for fetching sampled pixel blocks to improve cache hit rates. The hardware relies on mipmap levels to map UV coordinates. Hence, there is no disclosure of determining pseudo-random memory addresses.
More importantly in the section titled ‘Apparatus and method for hardware-accelerated texture lookup and interpolation’, which pertains to the instant application, and attempts to disclose hardware accelerated texture filtering, high-level phrases like ‘hashing modes’, ‘LCG-based hash functions’, ‘hash-based texture addressing modes’, ‘determining pseudo-random memory address(es)….sampled texture’, ‘texture interpolation’, etc., are recited as mere concepts for a research plan without disclosing a practical implementation.
Applicant further argues:‘Wei does not disclose a hash unit configured to determine pseudo-random memory addresses for texels within a memory block allocated to a texture’. (Rem, Pg. 10)
Response: This argument is not relevant.
Merely reciting ‘hash unit’ is too broad. The spec teaches a specific hash unit that uses a PRNG algorithm. Accordingly, the limitation is unsupported by the spec. Please see the 112(a) and 112(b).
Relying on improper amendments to mischaracterize prior art invalidates the argument.
Applicant further argues:‘The amendment now expressly defines the role of the hash unit as determining pseudo-random memory addresses that are subsequently used by a texel access unit to perform texel fetch operations. ….Wei does not disclose….generated addresses’. (Rem, Pg. 11)
Response: As mentioned above, the limitations do not align with the spec. Please see the 112(a)’s, 112(b)’s and the O/A.
Applicant further argues: ‘Wei generates procedural values, not memory addresses for stored texels’. (Rem. Pg. 11)
Response: This argument is incorrect.
The applicant makes a general statement ‘Wei generates procedural values’, without explaining in detail what the procedural values are and why they are ‘not memory addresses for texels’. Such statements without detailed comparison of the spec and the prior art, invalidate the argument.
That being said, the primary downstream modules in the graphics pipeline that ingest or interface with the generated procedural white noise values include the Shader Module 120/Execution Core, the Texture Module 130/Texture Sampler, and Pixel Write Module 150. Additional downstream components include image processing blocks utilized in spatial filtering or image enhancement applications.
Therefore as shown in Wei, Figs. 3A-3D, Figs. 5A-5B, the generated procedural white noise values function as address offsets or indices because the downstream modules apply mathematical bounding operations like modulo scaling to map the bitstream to a specific array range. Additionally, these noise values serve as destination address indices for pixel write operations via pixel write module 150, thereby implying that the destination address indices are pseudo-random addresses. Hence the combination of Wei,Tzeng,Shi disclose generating pseudo-random memory addresses for texels.
Since the spec only relies on functional statements like ‘determine pseudo-random address(ses)….’, without providing any details of how they are determined/calculated, the cited prior art disclose the requirement. Please see O/A.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights