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. This Office Action is responsive to the application filed 21 October 2022. Claims 1-20 are pending and have been presented for examination. Specification The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification. 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 appl icant regards as his invention. Claims 8-14 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. Claim 8 recites the limitation "the graphics processor" in line 7. There is insufficient antecedent basis for this limitation in the claim. Claim 8 recites “a graphics processor” in line 2 and recites “a graphics processor” in line 3. It is not clear if the claim is introducing two graphics processors, or if the graphics processor in line 3 is the same graphics processor in line 2. The result is indefiniteness with respect to “the graphics processor" as it is not clear if this is a reference to “a graphics processor” in line 2 or line 3. For purposes of examination, the Examiner will interpret “a graphics processor” in line 3 as reading “the graphics processor”. This is consistent with the other independent claims and would resolve the 112 issue. Claims 9-14 are also rejected based on their dependency to claim 8. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis ( i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claim (s) 1, 8 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over NORDQUIST ( U.S. Patent #7,593,971 ) in view of NI ( U.S. Patent Application Publication #2012/0254497 ) and TATE ( U.S. Patent Application Publication #2002/0042869 ) . 1. NORDQUIST discloses A graphics processor (see column 6, lines 53-65: GPU and multithreaded core array) comprising: a graphics core configured to perform parallel processing operations, the graphics core including a plurality of hardware threads (see column 10, lines 55-60: each core is implemented as a multithreaded execution core capable of supporting a large number of concurrent execution threads, concurrent is a synonym of parallel) ; and memory access circuitry configured to facilitate access to memory by functional units of the graphics core (see column 10, line 65 through column 11, line 5: texture core fetches data from memory for the core) , the memory access circuitry configured to: receive a message to access an element of state data associated with a render pipeline (see column 13, lines 52-61: texture request to access texture data, the texture data would be the state data; column 11, lines 1-55: the texture pipeline is part of the render process) , the message to include an element offset (see column 13, lines 62-67: the request includes a TID that is bound to a pool index, PID; column 12, lines 50-55: the PID is an offset relative to a base pointer for a pool) and an identifier of a register file that includes a base address (see column 12, lines 46-55: pool comprises a contiguous block of entries in memory, the pool is located with a base address, the location that stores this base address would be the register file) ; add the base address and the element offset to determine a 64-bit virtual address for the element of state data (see NI and TATE below) ; and submit a memory access request to the memory to access the element of state data (see column 14, lines 13-23: the texture request is processed and a result is returned, the result would be the element fetched from memory) . NI discloses the following limitations that are not disclosed by NORDQUIST : add the base address and the element offset to determine a 64-bit virtual address for the element of state data (see [0025]: offset is added to a base address to form an address for surface entries, the virtual address can contain 32 or 64 bits) . NORDQUIST already discloses forming a virtual address to retrieve texture data (see column 12, lines 38-40) . This address is formed using a base address and an offset (see column 12, lines 50-55) . However, NORDQUIST does not disclose the offset is added to the base or the address is 64 bits. NI does disclose both these features. The use of a 64-bit virtual address is a matter of design choice, and the use of 64-bits is a well-known and commonly used address size. The decision to add the offset to the base to form an address is one, o f a limited number of well-known options for generating an address using a base address and an offset. This technique of addressing is known as indirect addressing. NORDQUIST discloses the two inputs for forming the address (base and offset) but does not disclose how the address is formed. The use of base and offset would lead one of ordinary skill in the art to implement an indirect addressing scheme where the offset is added to the base, since this type of addressing is well-known in the art, as evidenced by TATE (see [0005]-[0006]) . NI discloses that this type of addressing is also used in graphics systems to retrieve state data. It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify NORDQUIST to add the offset to the base for a 64-bit address, as disclosed by NI . One of ordinary skill in the art would have been motivated to make such a modification as a matter of design choice, as taught by NI and TATE . NORDQUIST , NI and TATE are analogous/in the same field of endeavor as both references are directed to forming an address using base and offset values. 8. NORDQUIST discloses A method comprising: receiving, at memory access circuitry (see column 10, line 65 through column 11, line 5: texture core fetches data from memory for the core) of a graphics processor (see column 6, lines 53-65: GPU and multithreaded core array) , a message to access an element of state data associated with a render pipeline of a graphics processor (see column 13, lines 52-61: texture request to access texture data, the texture data would be the state data; column 11, lines 1-55: the texture pipeline is part of the render process) , the message including an element offset (see column 13, lines 62-67: the request includes a TID that is bound to a pool index, PID; column 12, lines 50-55: the PID is an offset relative to a base pointer for a pool) and an identifier of a register file that includes a base address (see column 12, lines 46-55: pool comprises a contiguous block of entries in memory, the pool is located with a base address, the location that stores this base address would be the register file) ; adding the base address and the element offset to determine a 64-bit virtual address for the element of state data; and submitting a memory access request to memory of the graphics processor to access the element of state data (see column 14, lines 13-23: the texture request is processed and a result is returned, the result would be the element fetched from memory) . NI discloses the following limitations that are not disclosed by NORDQUIST : add the base address and the element offset to determine a 64-bit virtual address for the element of state data (see [0025]: offset is added to a base address to form an address for surface entries, the virtual address can contain 32 or 64 bits) . NORDQUIST already discloses forming a virtual address to retrieve texture data (see column 12, lines 38-40) . This address is formed using a base address and an offset (see column 12, lines 50-55) . However, NORDQUIST does not disclose the offset is added to the base or the address is 64 bits. NI does disclose both these features. The use of a 64-bit virtual address is a matter of design choice, and the use of 64-bits is a well-known and commonly used address size. The decision to add the offset to the base to form an address is one, o f a limited number of well-known options for generating an address using a base address and an offset. This technique of addressing is known as indirect addressing. NORDQUIST discloses the two inputs for forming the address (base and offset) but does not disclose how the address is formed. The use of base and offset would lead one of ordinary skill in the art to implement an indirect addressing scheme where the offset is added to the base, since this type of addressing is well-known in the art, as evidenced by TATE (see [0005]-[0006]) . NI discloses that this type of addressing is also used in graphics systems to retrieve state data. It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify NORDQUIST to add the offset to the base for a 64-bit address, as disclosed by NI . One of ordinary skill in the art would have been motivated to make such a modification as a matter of design choice, as taught by NI and TATE . NORDQUIST , NI and TATE are analogous/in the same field of endeavor as both references are directed to forming an address using base and offset values. 15. NORDQUIST discloses A data processing system comprising: a memory device (see column 6, lines 28-38: local memory, system memory) ; and a graphics processor coupled with the memory device (see column 6, lines 53-65: GPU and multithreaded core array) , the graphics processor comprising a graphics core configured to perform parallel processing operations (see column 10, lines 55-60: each core is implemented as a multithreaded execution core capable of supporting a large number of concurrent execution threads, concurrent is a synonym of parallel) , and memory access circuitry configured to facilitate access to the memory device by functional units of the graphics core (see column 10, line 65 through column 11, line 5: texture core fetches data from memory for the core) , the memory access circuitry configured to: receive a message to access an element of state data associated with a render pipeline (see column 13, lines 52-61: texture request to access texture data, the texture data would be the state data; column 11, lines 1-55: the texture pipeline is part of the render process) , the message to include an element offset (see column 13, lines 62-67: the request includes a TID that is bound to a pool index, PID; column 12, lines 50-55: the PID is an offset relative to a base pointer for a pool) and an identifier of a register file that includes a base address (see column 12, lines 46-55: pool comprises a contiguous block of entries in memory, the pool is located with a base address, the location that stores this base address would be the register file) ; add the base address and the element offset to determine a 64-bit virtual address for the element of state data (see NI and TATE below) ; and submit a memory access request to the memory device to access the element of state data (see column 14, lines 13-23: the texture request is processed and a result is returned, the result would be the element fetched from memory) . NI discloses the following limitations that are not disclosed by NORDQUIST : add the base address and the element offset to determine a 64-bit virtual address for the element of state data (see [0025]: offset is added to a base address to form an address for surface entries, the virtual address can contain 32 or 64 bits) . NORDQUIST already discloses forming a virtual address to retrieve texture data (see column 12, lines 38-40) . This address is formed using a base address and an offset (see column 12, lines 50-55) . However, NORDQUIST does not disclose the offset is added to the base or the address is 64 bits. NI does disclose both these features. The use of a 64-bit virtual address is a matter of design choice, and the use of 64-bits is a well-known and commonly used address size. The decision to add the offset to the base to form an address is one, o f a limited number of well-known options for generating an address using a base address and an offset. This technique of addressing is known as indirect addressing. NORDQUIST discloses the two inputs for forming the address (base and offset) but does not disclose how the address is formed. The use of base and offset would lead one of ordinary skill in the art to implement an indirect addressing scheme where the offset is added to the base, since this type of addressing is well-known in the art, as evidenced by TATE (see [0005]-[0006]) . NI discloses that this type of addressing is also used in graphics systems to retrieve state data. It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify NORDQUIST to add the offset to the base for a 64-bit address, as disclosed by NI . One of ordinary skill in the art would have been motivated to make such a modification as a matter of design choice, as taught by NI and TATE . NORDQUIST , NI and TATE are analogous/in the same field of endeavor as both references are directed to forming an address using base and offset values. Claim(s) 2, 3, 9, 10, 16 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over NORDQUIST ( U.S. Patent #7,593,971 ), NI ( U.S. Patent Application Publication #2012/0254497 ) and TATE ( U.S. Patent Application Publication #2002/0042869 ) as applied to claim s 1, 8 and 15 above, and further in view of FOWLER ( U.S. Patent Application Publication #2021/0013624 ) . 2. The graphics processor of claim 1 (see NORDQUIST above) , the memory access circuitry configured to: scale the element offset according to a size of the element of state data to generate a scaled offset (see FOWLER below) ; and add the base address and the scaled (see FOWLER below) offset to determine the 64-bit virtual address for the element of state data (see NI [0025]: offset added to base address to form a 64-bit virtual address) . FOWLER discloses the following limitations that are not disclosed by NORDQUIST : scale the element offset according to a size of the element of state data to generate a scaled offset (see [0031]: surface data for a GPU is retrieved from memory using a base address, offset and stride multiplied by variable p) . This is interpreted as a scaled offset due to the use of a variable. The use of a variable allows for scaling the offset that is used with the base address. Using a base address and stride reduces the amount of memory required for a memory map (see [0031]) . NI already discloses adding an offset to the base, a combination with FOWLER would result in adding the scaled offset to the base. It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify NORDQUIST to use a scaled offset, as disclosed by FOWLER . One of ordinary skill in the art would have been motivated to make such a modification to reduce the size of the memory map, as taught by FOWLER . NORDQUIST and FOWLER are analogous/in the same field of endeavor as both references are directed to retrieving state data from a memory for the GPU. 3. The graphics processor of claim 2, wherein the element of state data includes a surface state entry (see NORDQUIST , column 11, lines 1-55: the texture data is used during the pipeline processing for generating pixels, the texture is a property of the surface) . 9. The method of claim 8 (see NORDQUIST above) , further comprising: scaling the element offset via the memory access circuitry according to a size of the element of state data to generate a scaled offset (see FOWLER below) ; and adding the base address and the scaled (see FOWLER below) offset to determine the 64-bit virtual address for the element of state data (see NI [0025]: offset added to base address to form a 64-bit virtual address) . FOWLER discloses the following limitations that are not disclosed by NORDQUIST : scale the element offset according to a size of the element of state data to generate a scaled offset (see [0031]: surface data for a GPU is retrieved from memory using a base address, offset and stride multiplied by variable p) . This is interpreted as a scaled offset due to the use of a variable. The use of a variable allows for scaling the offset that is used with the base address. Using a base address and stride reduces the amount of memory required for a memory map (see [0031]) . NI already discloses adding an offset to the base, a combination with FOWLER would result in adding the scaled offset to the base. It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify NORDQUIST to use a scaled offset, as disclosed by FOWLER . One of ordinary skill in the art would have been motivated to make such a modification to reduce the size of the memory map, as taught by FOWLER . NORDQUIST and FOWLER are analogous/in the same field of endeavor as both references are directed to retrieving state data from a memory for the GPU. 10. The method of claim 9, wherein the element of state data includes a surface state entry (see NORDQUIST , column 11, lines 1-55: the texture data is used during the pipeline processing for generating pixels, the texture is a property of the surface) . 16. The data processing system of claim 15 (see NORDQUIST above) , the memory access circuitry configured to: scale the element offset according to a size of the element of state data to generate a scaled offset (see FOWLER below) ; and add the base address and the scaled (see FOWLER below) offset to determine the 64-bit virtual address for the element of state data (see NI [0025]: offset added to base address to form a 64-bit virtual address) . FOWLER discloses the following limitations that are not disclosed by NORDQUIST : scale the element offset according to a size of the element of state data to generate a scaled offset (see [0031]: surface data for a GPU is retrieved from memory using a base address, offset and stride multiplied by variable p) . This is interpreted as a scaled offset due to the use of a variable. The use of a variable allows for scaling the offset that is used with the base address. Using a base address and stride reduces the amount of memory required for a memory map (see [0031]) . NI already discloses adding an offset to the base, a combination with FOWLER would result in adding the scaled offset to the base. It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify NORDQUIST to use a scaled offset, as disclosed by FOWLER . One of ordinary skill in the art would have been motivated to make such a modification to reduce the size of the memory map, as taught by FOWLER . NORDQUIST and FOWLER are analogous/in the same field of endeavor as both references are directed to retrieving state data from a memory for the GPU. 17. The data processing system of claim 16, wherein the element of state data includes a surface state entry (see NORDQUIST , column 11, lines 1-55: the texture data is used during the pipeline processing for generating pixels, the texture is a property of the surface) . Claim(s) 4, 11 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over NORDQUIST ( U.S. Patent #7,593,971 ), NI ( U.S. Patent Application Publication #2012/0254497 ), TATE ( U.S. Patent Application Publication #2002/0042869 ) and FOWLER ( U.S. Patent Application Publication #2021/0013624 ) as applied to claim s 1-3, 8-10 and 15-17 above, and further in view of PALTASHEV ( U.S. Patent Application Publication #2018/0114290 ) . 4. The graphics processor of claim 2 (see NORDQUIST above) , wherein the element of state data includes a sampler state entry (see PALTASHEV below). PALTASHEV discloses the following limitations that are not disclosed by NORDQUIST : the element of state data includes a sampler state entry (see [0039]: state object that includes an array of shader resources and sampler object descriptors) . NORDQUIST disclose the use of a shader in the pipeline (see column 9, lines 38-40: pixel shader) . PALTASHEV discloses a static memory that contains state data for a shader to configure the shader (see [0039]) . Allowing NORDQUIST to fetch a sampler state entry would be useful for configuration of the shader used in NORDQUIST . It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify NORDQUIST to include a sampler state entry in the state data, as disclosed by PALTASHEV . One of ordinary skill in the art would have been motivated to make such a modification to allow for configuration of a shader, as taught by PALTASHEV . NORDQUIST and PALTASHEV are analogous/in the same field of endeavor as both references are directed to retrieving state data for a graphics pipeline. 11. The method of claim 9 (see NORDQUIST above , wherein the element of state data includes a sampler state entry (see PALTASHEV below). PALTASHEV discloses the following limitations that are not disclosed by NORDQUIST : the element of state data includes a sampler state entry (see [0039]: state object that includes an array of shader resources and sampler object descriptors) . NORDQUIST disclose the use of a shader in the pipeline (see column 9, lines 38-40: pixel shader) . PALTASHEV discloses a static memory that contains state data for a shader to configure the shader (see [0039]) . Allowing NORDQUIST to fetch a sampler state entry would be useful for configuration of the shader used in NORDQUIST . It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify NORDQUIST to include a sampler state entry in the state data, as disclosed by PALTASHEV . One of ordinary skill in the art would have been motivated to make such a modification to allow for configuration of a shader, as taught by PALTASHEV . NORDQUIST and PALTASHEV are analogous/in the same field of endeavor as both references are directed to retrieving state data for a graphics pipeline. 18. The data processing system of claim 16 (see NORDQUIST above) , wherein the element of state data includes a sampler state entry (see PALTASHEV below) . PALTASHEV discloses the following limitations that are not disclosed by NORDQUIST : the element of state data includes a sampler state entry (see [0039]: state object that includes an array of shader resources and sampler object descriptors) . NORDQUIST disclose the use of a shader in the pipeline (see column 9, lines 38-40: pixel shader) . PALTASHEV discloses a static memory that contains state data for a shader to configure the shader (see [0039]) . Allowing NORDQUIST to fetch a sampler state entry would be useful for configuration of the shader used in NORDQUIST . It would have been obvious, before the effective filing date of the claimed invention, to a person having ordinary skill in the art to which said subject matter pertains to modify NORDQUIST to include a sampler state entry in the state data, as disclosed by PALTASHEV . One of ordinary skill in the art would have been motivated to make such a modification to allow for configuration of a shader, as taught by PALTASHEV . NORDQUIST and PALTASHEV are analogous/in the same field of endeavor as both references are directed to retrieving state data for a graphics pipeline. Allowable Subject Matter Claims 5-7, 1 9 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claims 12-14 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims. The following is a statement of reasons for the indication of allowable subject matter: The state of the art generally discloses a graphics core accessing state data using an address formed from a base address and an offset. This is shown using the cited references in the rejection above. The state of the art fails to anticipate, or render obvious, “… compose the message to access the element of state data; provide the base address to the memory access circuitry via a first sideband channel of a sideband input/output ( I/O ) bus; and provide the element offset to the memory access circuitry via a second sideband channel of a sideband input/output ( I/O ) bus ” as recited in claims 5, 12 and 19. Claims 6-7, 13-14 and 20 contain allowable subject matter based on their dependency to claims 5, 12 and 19 respectively. WHITE – 2019/0303334 – discloses communicating messages in a graphics circuit using a sideband bus. See [0045]-[0059] GOKHALE – 2017/0242590 – discloses messages sent on a sideband, where the message can include a base address and element size registers. See [0073] While WHITE and GOKHALE disclose the use of a sideband bus and transmission of messages over the bus in a GPU environment, the references fail to disclose the particular elements required by claims 5, 9 and 12. Specifically, the references fail to disclose “… provide the base address to the memory access circuitry via a first sideband channel of a sideband input/output ( I/O ) bus; and provide the element offset to the memory access circuitry via a second sideband channel of a sideband input/output ( I/O ) bus …” The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. ROBERTS – 10,366,012 – discloses accessing memory using a GPU with a base address and offset where the offset is added to the base address. See column 8 KIM – 2015/0091918 – discloses loading graphics data to a register using a base address. See abstract FUJII – 2009/0128574 – discloses the use of an effective address for a GPU that is accessed using a base address and an offset. See [0036] STEFANIDIS – 2007/0132770 – discloses paging surface data into and out of memory and a command packet that includes surface description information such as memory offset data. See abstract and [0045] Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to FILLIN "Examiner name" \* MERGEFORMAT EDWARD J DUDEK JR whose telephone number is FILLIN "Phone number" \* MERGEFORMAT (571)270-1030 . The examiner can normally be reached FILLIN "Work Schedule?" \* MERGEFORMAT Monday - Friday, 8:00A-4:00P . 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, FILLIN "SPE Name?" \* MERGEFORMAT Kenneth Lo can be reached at FILLIN "SPE Phone?" \* MERGEFORMAT 571-272-9774 . 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. /EDWARD J DUDEK JR/ Primary Examiner, Art Unit 2136