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 February 05, 2026 has been entered.
Claim Rejection(s) under 35 U.S.C. 103
Applicant argues that:
“Applicant respectfully submits that Valient and Raghunathan, individually or in combination, do not teach such subject matter as recited in claim 1. Specifically, none of the cited references, whether taken alone or in combination, can be relied upon to teach or suggest, let alone describe the now claimed "circuitry to, in response to receiving an application programming interface (API) call comprising a data identifier as an API input parameter, as a single operation: cause a location of data in a memory connected to a graphics processing unit ("GPU") corresponding to the data identifier to be indicated; and cause the data corresponding to the data identifier to be retrieved from the indicated location connected to the GPU and an indication to be returned that the data is not available if the data corresponding to the data identifier is not stored in the indicated location connected to the GPU." That is, the Office has not shown, and in fact, the references do not describe an API that, as a single operation, both indicates whether information is stored in physical memory, such as connected to a processing unit such as a GPU, and, if the information is stored, then causes the information to be retrieved.
Applicant’s arguments with respect to the pending claims have been considered but are moot because the arguments do not apply to the references Grossman et al. (US 2012/0038657 and Valient et al (US 2020/0380734) being used in the current rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-37 are rejected under 35 U.S.C. 103 as being unpatentable over Grossman et al. (US 2012/0038657, Grossman hereinafter) in view of Valient et al. (US 2020/0380734, Valient hereinafter).
As to claim 1, Grossman teaches one or more processors (e.g., see FIG. 1) comprising:
Circuitry (e.g., para 22, “ FIG. 1 may be implemented in a graphical processing unit (GPU) 108 that is in communication with the CPU 101. ) to, in response to receiving an application programming interface (API) call (e.g., para 30, “The request may include LODthresh and one or more (s, t) space addresses. “.
Thus, it is to be noted that: The request may include LODthresh include the API call ) comprising a data identifier as an API input parameter ( e.g., “(s, t) addresses”) , as a single operation (e.g., see FIG. 2, para 29, “an LODthresh value is generated. In some embodiments, the host 151 generates LODthresh. When the host 151 generates LODthresh it may be a single LODthresh for the entire texture”, “, different (s, t) address ranges may have different values for LODthresh”, “specify (s, t) addresses that the texture unit 158 converts to tile addresses”) :
cause a location of data in a memory connected to a graphics processing unit ("GPU") (e.g., “GPU 108”, FIG. 1, para 20, “The texture unit 158 may send an address (e.g., actual memory address) to the texture memory 112 and receive color values from the texture memory 112”) corresponding to the data identifier to be indicated (e.g., para 30, “LODthresh that is provided to the texture unit 158 may actually specify an (s, t) space address (or some other address), as opposed to a specific tile.”) ; and
cause the data corresponding to the data identifier to be retrieved from the indicated location connected to the GPU (e.g., para 26, “send an address (e.g., actual memory address) to the texture memory 112 and receive color values from the texture memory 112.”, [0031] In step 210, the texture unit 158 supplies texels for the tiles based on the LOD availability in the texture memory 112 and LODthresh for the tiles. In some embodiments, the texture unit 158 sends feedback to the shader 154 based on its ability to supply the requested LOD for each tile) .
However, Grossman does not teach an indication to be returned that the data is not available if the data corresponding to the data identifier is not stored in the indicated location connected to the GPU.
Valient teaches an indication to be returned (e.g., “indicator as to the mapped status “) that the data is not available if the data corresponding to the data identifier is not stored in the indicated location connected to the GPU (e.g., para 35, 45 “ textures or portions of textures (e.g., tiles) that have been accessed the most frequently will receive a higher priority in terms of being allocated memory backing than tiles that have not recently been loaded”, “portions of the various textures in the scene are either loaded or not loaded into memory” and “[0044] According to some embodiments, all tiles may be unmapped by default. According to such embodiments, a read from an unmapped region 510 may result in all zero values 512 being returned”, “ where one or more textures are blended with each other, the return of all zero values for an unmapped region in one of the textures may not present any undesired visual artifacts “ “ an unmapped region in memory or a mapped region in memory that simply happens to have all zero values”, for “the graphics processor management system may also provide an affirmative ACK/NACK, i.e., acknowledgement, indicator as to the mapped status of a given region”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Grossman by adopting the teachings of Valient to “ prevent application programs or other processes within a user space from interfering with the “kernel,” the code for the “kernel” is typically loaded into a separate and protected area of memory” (see , Valient para 20).
As to claim 2, Grossman teaches, wherein the memory comprises backing memory of the GPU (e.g., see FIG. 1 , “memory 112”, para 26, “The tile map 160 responds by indicating whether there is valid data for the requested tiles at that LOD. The texture unit 112 may access the texture memory 112 and generate texels to respond to requests from the shader 154. The texture unit 158 may send an address (e.g., actual memory address) to the texture memory 112 and receive color values from the texture memory 112.”) .
As to claim 3, Grossman teaches the location of the data is indicated by an array reference (e.g., para 33, “ Virtual tile array 302 represents the entire texture, which may be divided into different regions referred to as tiles.”, “virtual tile array, with each tile being 256.times.256 bytes. Therefore, the entire texture might be 5120 bytes.times.5120 bytes. Also, as noted before, the resident tile array 304 could represent parts of more than one texture” and “an index in the virtual array 302 and then to an index in the resident tile array 304. Referring to the example of the 20.times.20 virtual tile array, the texture unit 158 might first identify which virtual tile corresponds to the (s, t) address. Next, the texture unit 158 may determine an index in the resident tile array 304 that corresponds to the virtual tile array index. In some embodiments, the texture unit 158 determines a physical address in the texture memory 112 based on the resident tile array index” in para 42. Thus, the location of the data is indicated by an array reference ).
As to claim 4, Grossman teaches wherein: the location of the data is indicated by an array reference stored in the GPU, wherein the memory comprises backing memory of the GPU (para 0042] In step 502 of process 500, the texture unit 158 accesses the tile map 160 to determine what LOD is available in the tile memory 112 for the requested tile. For example, the texture unit 158 converts an (s, t) address that was received from the shader 154 to an index in the virtual array 302 and then to an index in the resident tile array 304. Referring to the example of the 20.times.20 virtual tile array, the texture unit 158 might first identify which virtual tile corresponds to the (s, t) address. Next, the texture unit 158 may determine an index in the resident tile array 304 that corresponds to the virtual tile array index. In some embodiments, the texture unit 158 determines a physical address in the texture memory 112 based on the resident tile array index).
As to claim 5, Grossman teaches wherein: the GPU comprises a parallel processing unit ("PPU") (e.g., “ para [0063] The CPU 101, GPU 108, memory controller 110, and various other components within the multimedia console 100 are interconnected via one or more buses, including serial and parallel buses”, [0069] After the multimedia console 100 boots and system resources are reserved, concurrent system applications execute to provide system functionalities. The system functionalities are encapsulated in a set of system applications that execute within the reserved system resources described above. The operating system kernel identifies threads that are system application threads versus gaming application threads. The system applications may be scheduled to run on the CPU 101 at predetermined times and intervals in order to provide a consistent system resource view to the application. The scheduling is to minimize cache disruption for the gaming application running on the console.” for“ shared by gaming applications and system applications. “ in para 71) ; and the location of the data is indicated by an array reference stored in the memory of the PPU (e.g., para 42, “an index in the virtual array 302 and then to an index in the resident tile array 304. Referring to the example of the 20.times.20 virtual tile array, the texture unit 158 might first identify which virtual tile corresponds to the (s, t) address. Next, the texture unit 158 may determine an index in the resident tile array 304 that corresponds to the virtual tile array index. In some embodiments, the texture unit 158 determines a physical address in the texture memory 112 based on the resident tile array index”).
As to claim 6, Grossman teaches wherein the circuitry, in response to receiving the APIcall, causes execution of a second API that causes the data to be mapped to memory connected to the GPU, based at least in part on the location of the data (para [0039] FIG. 4 is a flowchart of one embodiment of a process 400 of storing mipmaps in the texture memory 112. Process 400 is one embodiment of step 202 of process 200. In step 402, a clamp LOD is accessed for tiles in the resident tile array 304. The tiles represent a subset that is less than an entire texture. As one example, the entire texture may be represented by 20.times.20 virtual tile array, with each tile being 256.times.256 bytes. Therefore, the entire texture might be 5120 bytes.times.5120 bytes. Also, as noted before, the resident tile array 304 could represent parts of more than one texture. Process 400 will be discussed with reference to a single texture, for convenience of discussion.
[0040] In step 404, mipmap stacks for each tile in the subset are stored in the texture memory 112. In step 406, a mipmap stack for the entire texture is stored in the texture memory 112. For example, mipmap stacks such as those depicted in FIG. 3A or 3B are stored in the texture memory 112. A shown in FIG. 3A, for example, there is a mipmap stack for each of the resident tiles in 6.times.6 tile region 304 and a mip tail array stack 311 for the entire texture).
As to claim 7, Grossman teaches wherein the data is sparse array data (e.g., para 21, “Techniques provide for both texture streaming (e.g., dynamically loading a manageable amount of needed texture data in a given period of time), as well as sparse textures (e.g., allowing statically determined levels of detail for texture by region). “ [0040] In step 404, mipmap stacks for each tile in the subset are stored in the texture memory 112. In step 406, a mipmap stack for the entire texture is stored in the texture memory 112. For example, mipmap stacks such as those depicted in FIG. 3A or 3B are stored in the texture memory 112. A shown in FIG. 3A, for example, there is a mipmap stack for each of the resident tiles in 6.times.6 tile region 304 and a mip tail array stack 311 for the entire texture).
) .
As to claim 8., Grossman teaches wherein the data is mip-mapped array data ([0040] In step 404, mipmap stacks for each tile in the subset are stored in the texture memory 112. In step 406, a mipmap stack for the entire texture is stored in the texture memory 112. For example, mipmap stacks such as those depicted in FIG. 3A or 3B are stored in the texture memory 112. A shown in FIG. 3A, for example, there is a mipmap stack for each of the resident tiles in 6.times.6 tile region 304 and a mip tail array stack 311 for the entire texture).)..
As to claim 9, Grossman teaches wherein the data is texture data( e.g., para [0040] In step 404, mipmap stacks for each tile in the subset are stored in the texture memory 112. In step 406, a mipmap stack for the entire texture is stored in the texture memory 112. For example, mipmap stacks such as those depicted in FIG. 3A or 3B are stored in the texture memory 112. A shown in FIG. 3A, for example, there is a mipmap stack for each of the resident tiles in 6.times.6 tile region 304 and a mip tail array stack 311 for the entire texture).
As to claim 10, see rejection of claim 1 above.
As to claims 11-12, see rejection of claims 3 and 6 above
As to claim 13, Grossman does not teach unmapping the data from the memory connected to the GPU based at least in part on a location of the data, using a second API. However, Valient teaches unmapping the data from the memory connected to the GPU based at least in part on a location (e.g., “regions”) of the data (e.g., see FIG. 5, para 34, “ a read from an unmapped region 510 may result in all zero values 512 being returned. “), using a second API (e.g., para 34” number of general compute tasks (e.g., such as the mapping and unmapping of textures or portions of textures to regions in on-chip memory and/or the ordering between different thread groups) in a parallelized fashion on the graphic processor hardware.”). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Grossman by adopting the teachings of Valient to “ prevent application programs or other processes within a user space from interfering with the “kernel,” the code for the “kernel” is typically loaded into a separate and protected area of memory” (see , Valient para 20).
As to claim 14, see rejection of claim 2 above.
As to claim 15-16, see rejection of claims 9 and 6 above.
As to claim 17, see rejection of claims 3-4 above.
As to claim 18, see rejection of claims 5 above.
As to claim 19, see rejection of claim 1 above . Grossman teaches further a computer system comprising one or more processors and memory storing executable instructions that, as a result of being executed by the one or more processors, cause the computer system ( see FIG. 1)
As to claim 20-24, see rejection of claim 2-6 above
As to claim 25, As to claim 19, see rejection of claim 1 above. Grossman teaches further a non-transitory machine-readable medium having stored thereon a set of instructions, which if performed by one or more processors, cause the one or more processors to at least: ( see FIG. 1)
As to claims 26-27, see rejection of claims 3, 25 above.
As to claim 28-29 , Grossman teaches further a central processing unit ("CPU"), a graphics processing unit )”GPU”) ( see FIG. 1.).
As to claim 30-31 see rejection of claims 2 and 5 above.
As to claim 32, Grossman does not teach wherein the data retrieved includes an array containing all zeroes if the API indicates the data is not mapped to memory connected to the processing unit. However, Valient teaches wherein the data retrieved includes an array containing all zeroes if the API indicates the data is not mapped to memory connected to a processor of the one or more processors the processing unit (e.g., [0044] According to some embodiments, all tiles may be unmapped by default. According to such embodiments, a read from an unmapped region 510 may result in all zero values 512 being returned. An attempted write to an unmapped region may simply be discarded. In instances where one or more textures are blended with each other, the return of all zero values for an unmapped region in one of the textures may not present any undesired visual artifacts and may, instead, simply result in a less intense value or version of the mapped value in the blending operation. In some embodiments, the graphics processor management system may also provide an affirmative ACK/NACK, i.e., acknowledgement, indicator as to the mapped status of a given region, such that a developer would know if the sample is coming from an unmapped region in memory or a mapped region in memory that simply happens to have all zero values.). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Grossman by adopting the teachings of Valient to “ prevent application programs or other processes within a user space from interfering with the “kernel,” the code for the “kernel” is typically loaded into a separate and protected area of memory” (see , Valient para 20).
As to claim 33, Grossman teaches the API receives a first parameter that includes one or more memory information structures, wherein a memory information structure of the one or more memory information structures indicates information about at least a portion of the data (e.g., para 42, “an index in the virtual array 302 and then to an index in the resident tile array 304. Referring to the example of the 20.times.20 virtual tile array, the texture unit 158 might first identify which virtual tile corresponds to the (s, t) address. Next, the texture unit 158 may determine an index in the resident tile array 304 that corresponds to the virtual tile array index. In some embodiments, the texture unit 158 determines a physical address in the texture memory 112 based on the resident tile array index.”) ; the API receives a second parameter that indicates a count of the one or more memory information structures (e.g., para 29, “different (s, t) address ranges may have different values for LODthresh”) ; the API receives a third parameter that indicates an execution environment (e.g., para 42, “an index in the virtual array 302 and then to an index in the resident tile array 304. Referring to the example of the 20.times.20 virtual tile array, the texture unit 158 might first identify which virtual tile corresponds to the (s, t) address. Next, the texture unit 158 may determine an index in the resident tile array 304 that corresponds to the virtual tile array index. In some embodiments, the texture unit 158 determines a physical address in the texture memory 112 based on the resident tile array index.) , the API returns an error status indicator (e.g., para 47, “ if the LODmax for the tile is not within one level of the requested LODthresh (step 512 is no), then the texture unit 158 sends feedback of "Fail", “ FIG. 6B also has the label "Fail" at LOD 2 for Tile 2 to indicate that LOD 2 is not detailed enough to use for texel generation, in this example.”).
As to claims 34-35, see rejection of claims 7-8 above.
As to claim 36, Valient teaches , wherein the API returns a flag indicating that the data represents a single mip-tail of a mip-mapped texture ( para 38, “the texture memory 112 may store a mip tail array stack 311 for each virtual tile array 302. For example, FIGS. 3A and 3B show mip tail array stack 311 starting at LOD 5 for the virtual tile array 302. The texture memory 112 could store more than one mip tail array stack 311, each corresponding to a different texture (or virtual tile array 302”. Thus, herein the API returns a flag indicating that the data represents a single mip-tail of a mip-mapped texture).
As to claim 37, Valient teaches wherein the API receives parameters including a memory handle, a map offset, and a set of map extents in a memory information parameter structure ( e.g., para 45, “In step 516, the texture unit 158 send a feedback of "warning" to the shader 154 to indicate that the texture memory 112 does not currently have the LOD requested for the tile, but that the LOD is close.” for “an index in the virtual array 302 and then to an index in the resident tile array 304”, “ the texture unit 158 determines a physical address in the texture memory 112 based on the resident tile array index” in para 42. Thus, wherein the API receives parameters including a memory handle, a map offset, and a set of map extents in a memory information parameter structure).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Seiler (US 2017/0084000) discloses Memory resources that are stored in GPU-specific formats may be accessed as linear arrays by CPU applications. Shared virtual memory (SVM) support enables closer CPU/GPU interaction. This creates a need to efficiently access graphics data using SVM. CPU page mapping and memory management hardware may perform the address/data swizzling and tiled rendering translations required for GPU memory formats. As a result, CPU applications can access GPU resources as if they are stored in a linear array, while also using shared virtual memory.
Sharp et al. (US 2014/0075060) discloses techniques for demand paging for an IO device (e.g., a GPU) that utilize pre-fetch and pre-back notification event signaling to reduce latency associated with demand paging. Page faults are limited by performing the demand paging operations prior to the IO device actually requesting unbacked memory.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDOU K SEYE whose telephone number is (571)270-1062. The examiner can normally be reached M-F 9-5:30.
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, Pierre Vital can be reached at 5712724215. 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.
/ABDOU K SEYE/Examiner, Art Unit 2198
/TUAN C DAO/Primary Examiner, Art Unit 2198
Prosecution Insights