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 .
Response to Amendment
This Office Action is in response to Applicant’s amendment/response filed on 11 May 2026, which has been entered and made of record.
Double Patenting
The previous nonstatutory double patenting rejection is withdrawn in view of the approved Terminal Disclaimer.
Claim Rejections - 35 USC § 112
The previous rejections under 35 U.S.C. 112(b) are withdrawn in view of the claim amendments.
Response to Arguments
Applicant's arguments filed 11 May 2026 have been fully considered but they are not persuasive.
Applicant argues “Fernandez does not disclose the feature of: rendering the tiles in render logic using tile control lists identifying graphics data items present in a tile generated by a tiling unit and texture data stored in a cache … receiving geometry, state information, shader information, and texture addresses [of Fernandez] is not the same as the claimed feature because the tiling engine in Fernandez is not rendering logic” (Remarks, pg. 9). The Examiner respectfully disagrees. The Examiner does not allege that the tiling engine of Fernandez is rendering logic. As required by the claim language, Fernandez teaches rendering logic (e.g. Rasterizer 26 of Fig. 1) arranged to render the tiles (e.g. contained in Tile Cache 22 of Fig. 1), which can be seen by the line connecting Tile Cache 22 to Tile Fetcher 20 to Rasterizer 26, thereby transmitting the tiles for rendering to the rasterizer. Applicant additionally acknowledges “Fernandez discloses a tile fetcher 20 providing input tiles to the raster engine 12” (Remarks, pg. 10). The render logic us[es] tile control lists identifying graphics data items present in a tile (“a reference to a primitive is stored in a primitive list per tile … each tile can be rasterized,” para. 12). The tile is generated by a tiling unit (e.g. Tiling Engine 10 of Fig. 1). Finally, the rendering logic renders the tiles using texture data stored in a cache (“receives geometry, state information, shader information, and texture addresses ... This combined data is stored in the tile cache,” para. 22). As can be seen by this mapping, Fernandez teaches each part of the disputed limitation.
Applicant argues “Fernandez does not disclose the feature of: generating, for each tile, a per-tile hash value based on resources that are used when processing the tile in rendering logic … Fernandez requires all data for a tile to be included in the compact representation, which is different to specifically generating the per-tile hash value based on resources that are used when processing the tile” (Remarks, pg. 10). The Examiner respectfully disagrees. Fernandez discloses “a compact representation, such as a hash … may be based on all geometry, input data and the relevant states including all primitives, uniforms, textures, shaders, blending modes” (para. 14). The rasterizer of Fernandez uses relevant primitives, uniforms, textures, etc. to render an individual tile. Therefore, the “geometry, input data and the relevant states including all primitives, uniforms, textures, shaders, blending modes” of Fernandez teach the claimed resources that are used when processing the tile in the rendering logic. Since Fernandez specifically recites that the hash is based on those resources (see para. 14), the full limitation of generate, for each tile, a per-tile hash value based on resources that are used when processing the tile in the rendering logic is taught by Fernandez.
Applicant argues, in reference to para. 22 of Fernandez, “The necessity to combine the state information with the pipeline result shows that the state information is not taught as a resource used in processing the tile in the rasterization pipeline of Fernandez” (Remarks, pg. 11). The Examiner respectfully disagrees. As a first matter, this argument is not commensurate in scope with the claim language because the claim does not limit what is included or excluded by the hash, as long as the hash is based on at least some resources used in processing the tile in the rendering logic. As a second matter, there is no part of para. 22 of Fernandez that teaches that state information is not used by the rasterizer. On the contrary, one having ordinary skill in the art would understand that a graphics state is required to render graphics data. Additionally, Fig. 1 of Fernandez illustrates a line connecting Tile Cache 22 to Tile Fetcher 20 to Rasterizer 26, meaning any data stored in the tile cache, such as the state data, is sent to the raster pipeline.
Applicant argues “a crucial teaching of Fernandez, which is that the cited ‘combined data’ does not include the listed values such as texture addresses as implied” (Remarks, pg. 12). The Examiner respectfully disagrees. Fernandez specifically recites that the combined data includes texture addresses: “The tiling engine receives geometry, state information, shader information, and texture addresses in a hash or bloom filter computation unit 13. Any state information is provided to a tile list builder 14 that combines the pipeline result with any state information. This combined data is stored in the tile cache 22” (para. 22). Additionally, Fig. 1 of Fernandez illustrates “Geometry, State Info, Shader Info, Textures, Addresses… Any State” as an input to Tile List Builder 14 which is an input to Tile Cache 22. Therefore, Applicant’s argument that “the cache in Fernandez includes combined data … and not the texture data required by claim 1” (Remarks, pg. 12) is unpersuasive.
Applicant argues “Shim makes no explicit disclosure of a cache. The Office action maps memory 720 to the claimed cache merely because it is proximate to a processor/controller and stores data from a more distant memory such as graphics memory 122; however, the art-term ‘cache’ has a specific and well-recognized meaning as a constituent part of a processor that is not taught Shim, such as an L1 and L2 cache” (Remarks, pg. 13). The Examiner respectfully disagrees. There is no requirement in the claims that the cache is an L1 or L2 cache or that the cache resides on the same chip as the processor. The word cache, in the context of computer memory, is much broader than Applicant alleges. As understood in the technology area of computer graphics, a cache is a memory component that stores data closer to the processor than main memory, and which is faster to access than main memory, in order to improve efficiency for data that is frequently or recently accessed. Caches are not required to be on the same chip as a processor. The description of the memory 720 (and analogous memory 830) of Shim fits within a broadest reasonable interpretation of a cache memory as required by the claims.
Applicant argues “Shim does not disclose an eviction of cache data; instead, data in the memory 720 is changed from one texture to another” (Remarks, pg. 13). One having ordinary skill in the art would understand that a cache eviction is a procedure for removing data from a cache (e.g. data that has not been used recently and/or often) in order to store more pertinent data in the cache (e.g. data that is needed sooner and/or more frequently). Changing from one texture to another in the memory, as Applicant acknowledges is taught by Shim, means that the previous texture no longer resides in the memory, and therefore it is by definition “evicted” from the memory. As discussed earlier, the memory 720 of Shim is a cache memory, and therefore Shim teaches the claimed eviction of cache data.
Any remaining arguments are considered moot based on the foregoing.
Claim Rejections - 35 USC § 102
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.
Claims 1-3, 10, 13-17, and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Fernandez et al. (US 2016/0027144; hereinafter “Fernandez”).
Regarding claim 1, Fernandez discloses A graphics processing unit configured to process graphics data using a rendering space which is sub-divided into a plurality of tiles (“a graphics processor to sort primitives into tiles including a current tile of pixels for a current frame,” para. 51), the graphics processing unit comprising: rendering logic arranged to render the tiles (e.g. raster pipeline 12 of Fig. 1) using tile control lists identifying graphics data items present in a tile generated by a tiling unit (“all primitives, such as triangles that are to be rendered, are sorted into the tiles, so that a reference to a primitive is stored in a primitive list per tile for all tiles that the primitive overlaps. When all sorting is done, each tile can be rasterized,” para. 12) and texture data stored in a cache (“texture addresses … This combined data is stored in the tile cache,” para. 22; Fig. 1 of Fernandez illustrates “Geometry, State Info, Shader Info, Textures, Addresses… Any State” as an input to Tile List Builder 14 which is an input to Tile Cache 22); and per-tile hash generation logic arranged to generate, for each tile, a per-tile hash value based on resources that are used when processing the tile in the rendering logic (“a compact representation, such as a hash, is accumulated per tile when the primitive list per tile is created. The compact representation may be based on all geometry, input data, and the relevant states, including all primitives, uniforms, textures, shaders, blending modes, etc.,” para. 14; note that “primitives, uniforms, textures, shaders, blending modes, etc.” are considered to be “resources that are used when processing the tile”).
Regarding claim 2, Fernandez discloses wherein the per-tile hash value is generated based on a shader program used when processing the tile in the rendering logic (“a compact representation, such as a hash … may be based on all geometry, input data, and the relevant states, including all primitives, uniforms, textures, shaders, blending modes, etc.,” para. 14).
Regarding claim 3, Fernandez discloses wherein the rendering logic comprises scheduling logic and processing logic and wherein the scheduling logic is arranged to select a next tile to be scheduled for processing by the processing logic based on a comparison of two or more per-tile hash values (“the next tile identifier to fetch is obtained. For that tile, the current hash or filter is obtained and the ones from the previous frame are obtained in block 52 [of Fig. 2]. A check at 54 determines whether the current and previous hash or filters match. If so, at 56, tile fetching is skipped,” para. 27).
Regarding claim 10, Fernandez discloses wherein the rendering logic comprises a plurality of processing cores (“multi-core processor,” para. 35) and a cache for storing the texture data for use in rendering tiles (“The tiling engine 10 [of Fig. 1] receives geometry, state information, shader information, and texture addresses … This combined data is stored in the tile cache 22,” para. 22), wherein the cache is accessible to each of the plurality of processing cores (e.g. Fig. 1 illustrates the tile cache 22 and unified cache 24 accessible to the processors).
Regarding claim 13, Fernandez discloses wherein the comparison of two per-tile hash values comprises a bit-wise comparison to identify a number of matching bits in the two per-tile hash values (“When the triangle list is created, several hash functions are applied to the information to compare. The results of these hash functions are used to index both bloom filters. For the one related to the current frame, all bits indexed are set. On the other hand, for the bloom filter of the previous frame, the bits indexed are read and a check determines whether all of them are one,” para. 20).
Regarding claim 14, Fernandez discloses wherein each per tile hash value is a Bloom filter (“bloom filter algorithm,” para. 20).
Regarding claim 15, Fernandez discloses wherein the per-tile hash generation logic is arranged to generate, for each tile, a per-tile hash value by: for each texture that will be accessed when processing the tile in the rendering logic, identifying a bit position in the Bloom filter; and setting bits in the Bloom filter at each identified bit position to a default value (“A hash or some other compact representation of all the data used in a tile, including all triangles, uniforms, textures,” para. 10; “The bloom filter algorithm works like the one with hashes, in one embodiment. When the triangle list is created, several hash functions are applied to the information to compare. The results of these hash functions are used to index both bloom filters. For the one related to the current frame, all bits indexed are set,” para. 20).
Regarding claim 16, Fernandez discloses wherein the per-tile hash generation logic is arranged to generate, for each tile, a per-tile hash value by: for each texture that will be accessed when processing the tile in the rendering logic, using each of a plurality of hash functions to identify a bit position in the Bloom filter; and setting bits in the Bloom filter at each identified bit position to a default value (“A hash or some other compact representation of all the data used in a tile, including all triangles, uniforms, textures,” para. 10; “The bloom filter algorithm works like the one with hashes, in one embodiment. When the triangle list is created, several hash functions are applied to the information to compare. The results of these hash functions are used to index both bloom filters. For the one related to the current frame, all bits indexed are set,” para. 20).
Regarding claim 17, Fernandez discloses wherein the per-tile hash generation logic is included in a tiling unit (hash computation unit 13 of Fig. 1 is included in tiling engine 10).
Regarding claim 19, it is rejected using the same citations and rationales described in the rejection of claim 1, with the additional limitation of storing the per-tile hash value for a tile for use by the rendering logic (“A hash or some other compact representation of all the data used in a tile, including all triangles, uniforms, textures, shaders, etc. is computed and stored for each tile,” Fernandez, para. 10; “A check at 54 [of Fig. 2] determines whether the current and previous hash or filters match … If not, at 58, proceed with tile fetching and direct data to raster pipeline for processing,” Fernandez, para. 27; the hash value is used by the rendering logic because the rendering logic only proceeds if the hash values don’t match).
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 4-9, 11, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over a combination of Fernandez and Shim et al. (US 2016/0078667; hereinafter “Shim”).
Regarding claim 4, Fernandez does not disclose identify a candidate set of tiles and to select a next tile to be scheduled for processing by the processing logic based on a comparison of a per-tile hash value of a currently scheduled tile and the per-tile hash value of at least one of the tiles in the candidate set.
In the same art of tile-based rendering, Shim teaches identify a candidate set of tiles (“a plurality of second tiles that are rendered after the first tile,” para. 88) and to select a next tile to be scheduled for processing by the processing logic based on a comparison of a per-tile … value of a currently scheduled tile and the per-tile … value of at least one of the tiles in the candidate set (“determines a rendering order of the plurality of tiles according to a similarity of texture information by comparing texture information between the first tile and the second tiles … the rendering order may be determined so that a third tile that uses in rendering the same texture data as texture data of the first tile the most is rendered after the first tile,” paras. 90-91).
Before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Shim with the per-tile hash value comparisons of Fernandez. The motivation would have been to “more efficiently use resources” (Shim, abstract). Specifically, Fernandez compares per-tile hash values in order to determine a tile to render next (e.g. by skipping certain tiles), and Shim teaches comparing per-tile values in order to determine a tile to render next from a set of candidate tiles. When the teachings of Fernandez and Shim are combined, the combination renders obvious using the per-tile hash value comparisons of Fernandez to compare a current tile to a set of candidate tiles as in Shim in order to determine an efficient rendering order of tiles.
Regarding claim 5, the combination of Fernandez and Shim renders obvious wherein the currently scheduled tile is either: (i) a current tile being processed, or (ii) a most recently scheduled tile (“select at least one tile that is rendered after the first tile,” Shim, para. 22; see claim 4 for motivation to combine).
Regarding claim 6, the combination of Fernandez and Shim renders obvious identify a candidate set of tiles based, at least in part, on a spatial order scheme (“consider a rendering order of the plurality of tiles, to select the second tile. The controller may also select at least one second tile, from among tiles that are adjacent to the selected first tile in the rendering image,” Shim, para. 109; see claim 4 for motivation to combine).
Regarding claim 7, the combination of Fernandez and Shim renders obvious wherein the candidate set comprises a next N tiles according to the spatial order scheme, wherein N is an integer; or wherein the candidate set comprises a first tile from each of a next N groups of tiles according to the spatial order scheme, wherein N is an integer (“select only one second tile, or a plurality of second tiles, for example, 2 or 4 second tiles,” Shim, para. 61; see claim 4 for motivation to combine).
Regarding claim 8, the combination of Fernandez and Shim renders obvious wherein the candidate set comprises one or more tiles adjacent to the current tile being processed (“consider a rendering order of the plurality of tiles, to select the second tile. The controller may also select at least one second tile, from among tiles that are adjacent to the selected first tile in the rendering image,” Shim, para. 109; see claim 4 for motivation to combine).
Regarding claim 9, Fernandez discloses a cache controller configured to select an item of texture data to be evicted from a cache (“The tiling engine receives geometry, state information, shader information, and texture addresses … This combined data is stored in the tile cache,” para. 22; storage/eviction procedures are inherent in any computer memory).
Fernandez does not disclose evicting textures from a cache based on analysis of two or more per-tile hash values.
In the same art of tile-based rendering, Shim teaches a cache controller (“The memory 720 stores a plurality of pieces of texture data including texture data that is used to render the first tile. The memory 720 may obtain the plurality of pieces of texture data from the graphics memory 122,” para. 110; NOTE: while memory 720 of Fig. 7 is not explicitly labeled as “cache,” it is located proximate to a processor/controller and it stores data from a more distant memory such as graphics memory 122 of Fig. 1, therefore it fits the definition of a cache) configured to select an item of texture data to be evicted from a cache based on analysis of two or more per-tile … values (“the controller 710 may compare the texture information of the first tile with texture information of each of the second tiles … The data changer 730 selects at least one piece of texture data from among a plurality of pieces of texture data of the first tile that are previously stored in the memory 720 according to a frequency of use … The data changer 730 may determine at least one piece of texture data to be changed,” paras. 108-112).
Before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Shim with the per-tile hash value comparisons of Fernandez. The motivation would have been to “more efficiently use resources” (Shim, abstract). Specifically, Fernandez compares per-tile hash values, and Shim teaches comparing per-tile values in order to determine a texture to evict from a texture cache. When the teachings of Fernandez and Shim are combined, the combination renders obvious using the per-tile hash value comparisons of Fernandez to compare a current tile to a set of candidate tiles as in Shim in order to determine which textures to evict from a texture cache.
Regarding claim 11, the combination of Fernandez and Shim renders obvious identify one or more textures that are least likely to be used based on the analysis of two or more per-tile … values and to select an item of texture data to be evicted from the cache corresponding to a least likely to be used texture (“The data changer 730 [of Fig. 7] selects at least one piece of texture data from among a plurality of pieces of texture data of the first tile that are previously stored in the memory 720 according to a frequency of use for rendering of the second tile, according to a result of the comparison,” Shim, para. 111; see claim 9 for motivation to combine), wherein the per-tile values are per-tile hash values (“hash values per tiles are generated just for comparison purposes,” Fernandez, para. 17).
Regarding claim 12, the combination of Fernandez and Shim renders obvious wherein the cache controller is arranged to identify one or more least likely to be used textures based on the analysis of per-tile … values for at least one tile being processed by the rendering logic (“The data changer 730 [of Fig. 7] selects at least one piece of texture data from among a plurality of pieces of texture data of the first tile that are previously stored in the memory 720 according to a frequency of use for rendering of the second tile, according to a result of the comparison,” Shim, para. 111; see claim 9 for motivation to combine), wherein the per-tile values are per-tile hash values (“hash values per tiles are generated just for comparison purposes,” Fernandez, para. 17).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Fernandez in view of Kakarlapudi et al. (US 2017/0330372; hereinafter “Kakarlapudi”).
Regarding claim 18, Fernandez does not disclose wherein the graphics processing unit is arranged to store the per-tile hash value for a tile within a tile control list for the tile.
In the same art of tile-based rendering, Kakarlapudi teaches wherein the graphics processing unit is arranged to store the per-tile … value for a tile within a tile control list for the tile (“a primitive list reader configured to read a primitive list associated with a tile to be rendered … the primitive lists could include appropriate information, e.g. metadata,” para. 258).
Before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to apply the teachings of Kakarlapudi to the per-tile hash values of Fernandez. Fernandez teaches storing per-tile hash values, which can be considered a form of metadata related to a tile. Kakarlapudi teaches storing per-tile metadata, i.e. a value for a tile, within a control list for the tile. The combination would render obvious storing the per-tile hash value of Fernandez as metadata in the tile control list. The motivation would have been to increase efficiency by placing appropriate data together in memory.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Fernandez in view of Official Notice.
Regarding claim 20, Fernandez does not disclose An integrated circuit manufacturing system comprising: a non-transitory computer readable storage medium having stored thereon a computer readable dataset description of an integrated circuit that describes a graphics processing unit as set forth in claim 1; a layout processing system configured to process the integrated circuit description so as to generate a circuit layout description of an integrated circuit embodying the graphics processing unit; and an integrated circuit generation system configured to manufacture the graphics processing unit according to the circuit layout description.
The Examiner previously took Official Notice that both the concepts and the advantages of An integrated circuit manufacturing system comprising: a non-transitory computer readable storage medium having stored thereon a computer readable dataset description of an integrated circuit that describes a graphics processing unit … a layout processing system configured to process the integrated circuit description so as to generate a circuit layout description of an integrated circuit embodying the graphics processing unit; and an integrated circuit generation system configured to manufacture the graphics processing unit according to the circuit layout description were well known and expected in the art before the effective filing date of the claimed invention. Since Applicant did not traverse, this is now considered Applicant Admitted Prior Art. It would have been obvious before the effective filing date of the claimed invention to apply integrated circuit description, layout, and manufacturing in Fernandez in order to efficiently manufacture the circuit.
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 Ryan McCulley whose telephone number is (571)270-3754. The examiner can normally be reached Monday through Friday, 8:00am - 4:30pm.
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, Kee Tung can be reached at (571) 272-7794. 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.
/RYAN MCCULLEY/Primary Examiner, Art Unit 2611
Prosecution Insights