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 .
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 7/21/26 has been entered.
1. REJECTIONS BASED ON PRIOR ART
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 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.
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-6, 8-11, 13, 14-17, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tamir (US 20190042419) in view of Arbib (US 20240338401).
With respect to claim 1, the Tamir reference teaches one or more processors, (see fig. 1, processor(s) 108) comprising:
circuity to cause information stored using a first memory path comprising a first cache location (e.g. fig. 1, a first core of cores 110 and its core-local cache) to be stored in a memory location (e.g. shared cache 116) accessible from both the first cache location and a second memory path comprising a second cache location (e.g. fig. 1, a second core of cores 110 and its core-local cache). (paragraph 67, where a cache line demotion operation to demote the data from the one or more core-local cache lines to one or more shared cache lines of a shared cache of the compute device [i.e. each core and its corresponding cache can access the shared cache 116])
However, the Tamir reference does not explicitly teach circuity to have in response to an application programming interface (API) call, perform the steps noted above; and wherein a first identifier of the first memory path and a second identifier of the second memory path are provided as parameters to the API. (emphasis added)
The Arbib reference teaches it is conventional to have in response to an application programming interface (API) call, perform the steps noted above; and wherein a first identifier of the first memory path and a second identifier of the second memory path are provided as parameters to the API. (paragraph 5, where certain portions of API calls may be divided into segments, each of which might include parameters defining paths; and paragraph 21, where portions of computing interface calls may be broken into segments, and each of these segments may include information related to paths (i.e., location-based data), information to be used by the API being called (e.g., parameters such as identifiers of specific users, information about specific data being requested, or authentication information used to authenticate users))
It would have been obvious to a person of ordinary skill in the art before the claimed invention was effectively filed to modify the Tamir reference to have in response to an application programming interface (API) call, perform the steps noted above; and wherein a first identifier of the first memory path and a second identifier of the second memory path are provided as parameters to the API, as taught by the Arbib reference.
The suggestion/motivation for doing so would have been to provide techniques for securing call flows for computing interfaces such as application programming interfaces (APIs) using clustering. (Arbib, paragraph 17)
Therefore it would have been obvious to combine the Tamir and Arbib references for the benefits shown above to obtain the invention as specified in the claim.
With respect to claim 2, the combination of the Tamir and Arbib references teaches the one or more processors of claim 1, wherein the API is to prevent information from being read based, at least in part, on causing a memory update operation followed by a memory ordering operation to be performed. (Tamir, paragraph 41, where there is the promotion of data from the shared cache 116 to the applicable core-local cache 114 [which would not allow data to be read from another core]; and paragraph 13, where a processor core 112 requests access to data which may have been previously stored or moved into shared cache memory, typically on-processor or near-processor cache. The network compute device 106 is configured to move the requested data to a core-local cache (e.g., the core-local cache 114) for quicker access to the requested data by the requesting processor core 112)
With respect to claim 3, the combination of the Tamir and Arbib references teaches the one or more processors of claim 1, wherein the API is to prevent information from being read from the second cache location based, at least in part, on causing a release fence to be performed based, at least in part on a memory update operation. (Tamir, paragraph 41, where there is the promotion of data from the shared cache 116 to the applicable core-local cache 114 [which would not allow data to be read from another core]; and paragraph 13, where a processor core 112 requests access to data which may have been previously stored or moved into shared cache memory, typically on-processor or near-processor cache. The network compute device 106 is configured to move the requested data to a core-local cache (e.g., the core-local cache 114) for quicker access to the requested data by the requesting processor core 112)
With respect to claim 4, the combination of the Tamir and Arbib references teaches the one or more processors of claim 1, wherein the information being stored in the first cache location corresponds to a single memory update operation and the API is to prevent the information from being read from the second cache location based, at least in part, on a first indication of a first path to update memory and a second indication of a second path to read from updated memory. (Tamir, paragraph 41, where there is the promotion of data from the shared cache 116 to the applicable core-local cache 114 [which would not allow data to be read from another core]; and paragraph 13, where a processor core 112 requests access to data which may have been previously stored or moved into shared cache memory, typically on-processor or near-processor cache. The network compute device 106 is configured to move the requested data to a core-local cache (e.g., the core-local cache 114) for quicker access to the requested data by the requesting processor core 112)
With respect to claim 5, the combination of the Tamir and Arbib references teaches the one or more processors of claim 1, wherein the API is to cause an order of memory operations that use the second cache location to be performed based, at least in part, on one or more memory update operations of the first cache location. (Tamir, paragraph 41, where there is the promotion of data from the shared cache 116 to the applicable core-local cache 114 [which would not allow data to be read from another core]; and paragraph 13, where a processor core 112 requests access to data which may have been previously stored or moved into shared cache memory, typically on-processor or near-processor cache. The network compute device 106 is configured to move the requested data to a core-local cache (e.g., the core-local cache 114) for quicker access to the requested data by the requesting processor core 112)
With respect to claim 6, the combination of the Tamir and Arbib references teaches the one or more processors of claim 1, wherein the API is to generate an indication that the information is stored in the first cache location. (Tamir, paragraph 41, where there is the promotion of data from the shared cache 116 to the applicable core-local cache 114 [which would not allow data to be read from another core]; and paragraph 13, where a processor core 112 requests access to data which may have been previously stored or moved into shared cache memory, typically on-processor or near-processor cache. The network compute device 106 is configured to move the requested data to a core-local cache (e.g., the core-local cache 114) for quicker access to the requested data by the requesting processor core 112)
Claims 8-11 and 13 are the system implementation of claims 1-6 noted above, and rejected under a similar rationale.
Claims 14-17 are the method implementation of claims 1-6 noted above, and rejected under a similar rationale. The Examiners further notes Tamir (paragraph 49, where upon completion of the processing operation, the processor core 110 is further configured to provide some indication that one or more cache lines are to be demoted from the core-local cache 114 to the shared cache 116) teaches the limitations of “generating an indication that the information has been stored”.
Claim 20 is the non-transitory computer-readable medium implementation of claims 1-6 noted above, and rejected under a similar rationale.
Claims 7, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tamir (US 20190042419) in view of Arbib (US 20240338401) as shown in the rejections above, and further view of Chao (US 20200065250).
With respect to claim 7, the combination of the Tamir and Arbib references does teaches the one or more processors of claim 1, wherein the information being stored in the first cache location includes data, the first cache location is in a second level cache, and the second cache location is in a first level cache, not included in a path to store the data in the first cache location. (Tamir, paragraph 41, where there is the promotion of data from the shared cache 116 to the applicable core-local cache 114 [which would not allow data to be read from another core]; and paragraph 13, where a processor core 112 requests access to data which may have been previously stored or moved into shared cache memory, typically on-processor or near-processor cache. The network compute device 106 is configured to move the requested data to a core-local cache (e.g., the core-local cache 114) for quicker access to the requested data by the requesting processor core 112)
However, the combination of the Tamir and Arbib references does not explicitly teach that the data includes a tensor map.
The Chao reference teaches it is conventional to have the data be a tensor map. (abstract, where there is a feature map caching method of a convolutional neural network includes a connection analyzing step and a plurality of layer operation steps. The connection analyzing step is for analyzing a network to establish a convolutional neural network connection list. The convolutional neural network connection list includes a plurality of tensors and a plurality of layer operation coefficients)
It would have been obvious to a person of ordinary skill in the art before the claimed invention was effectively filed to modify the combination of the Tamir and Arbib references to have the data be a tensor map, as taught by the Chao reference.
The suggestion/motivation for doing so would have been to optimize the DRAM access times so as to reduce the DRAM bandwidth power consumption because the DRAM access times will consume most of the DRAM bandwidth power consumption in the system. (Chao, paragraph 15)
Therefore it would have been obvious to combine the Tamir, Arbib, and Chao references for the benefits shown above to obtain the invention as specified in the claim.
Claim 12 is the system implementation of claim 7 noted above, and rejected under a similar rationale.
Claim 19 is the method implementation of claim 7 noted above, and rejected under a similar rationale.
Claim 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tamir (US 20190042419) in view of Arbib (US 20240338401) as shown in the rejections above, and further view of FEEHRER (US 20210133123).
With respect to claim 18, the combination of the Tamir and Arbib references does not explicitly teach the method of claim 14, wherein a memory address in shared memory of a graphics processing unit (GPU) and a memory address in global memory of the GPU are provided as input to the API.
The FEEHRER reference teaches it is conventional to have wherein a memory address in shared memory of a graphics processing unit (GPU) and a memory address in global memory of the GPU are provided as input to the API. (paragraph 166, where multiple compute applications are simultaneously executed by the GPU 102 and the GPU 102 provides isolation, quality of service (QoS), and independent address spaces for the multiple compute applications. An application may generate instructions (e.g., API calls) that cause the driver kernel to generate one or more tasks for execution by the GPU 102. The driver kernel outputs tasks to one or more streams being processed by the GPU 102. Each task may comprise one or more groups of related threads, referred to herein as a warp. In an embodiment, a warp comprises plural (e.g., 32) related threads that may be executed in parallel. Cooperating threads may refer to a plurality of threads including instructions to perform the task and that may exchange data through shared memory)
It would have been obvious to a person of ordinary skill in the art before the claimed invention was effectively filed to modify the combination Tamir and Arbib references to have wherein a memory address in shared memory of a graphics processing unit (GPU) and a memory address in global memory of the GPU are provided as input to the API, as taught by the FEEHRER reference.
The suggestion/motivation for doing so would have been to provide techniques and mechanisms for automatically handling address mapping and request routing between source GPU-generated physical addresses and fabric attached memory address locations so that the capacity of fabric attached memory can be fully utilized even though the source GPU may generate physical addresses that define address spaces much larger than those of any particular fabric attached memory device and even though the source GPU may send such physical addresses over entropy-selected interconnect links, while efficiently and flexibly supporting data striping across an array of such fabric attached memory devices. (FEEHRER, paragraph 16)
Therefore it would have been obvious to combine the Tamir, Arbib, and FEEHRER references for the benefits shown above to obtain the invention as specified in the claim.
2. ARGUMENTS CONCERNING PRIOR ART REJECTIONS
Rejections - USC 102/103
Applicant's arguments (see pages 6-9 of the remarks) and amendments with respect to claims 1-20 have been considered, and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Arbib reference to teach the newly added claim language as shown in the rejections above.
3. CLOSING COMMENTS
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PRASITH THAMMAVONG whose telephone number is (571) 270-1040. The examiner can normally be reached Monday - Friday 12-8 PM 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, Arpan Savla can be reached on (571) 272-1077. 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.
/PRASITH THAMMAVONG/
Primary Examiner, Art Unit 2137
Prosecution Insights