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 RCE amendment filed 12/11/2025 which has been entered and made of record. Claims 1-8, 10-14, and 16-19 have been amended. No
claim has been cancelled or newly added. Claims 1-20 are pending in the application.
Applicant’s amendments to the claims have overcome each and
every objection previously set forth in the Final Office Action mailed June 20th, 2025.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The arguments regarding dependent claims for the virtue of their dependency are moot
because the independent claims are not allowable.
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, 8, 14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wilt et al. (U.S. Patent No. 8,539,516), hereinafter referenced as Wilt in view of Mappouraset al. (U.S. Patent Application Publication No. 2020/0042859), hereinafter referenced as Mappouras.
Regarding claim 1, Wilt teaches one or more processors, comprising, circuitry to, (col. 3, lines 6-8 teach a processor and col. 1 line 19 teaches parallel execution threads) in response to an application programming interface (API) call cause one or more software objects to indicate whether one or more asynchronous memory transactions that include data movement operations have been performed (col. 14, lines 8-28 teaches an API configured to cause semaphore buffer to be modified to indicate if access to memory has been completed). A processor with parallel execution threads would require circuits to perform such, the semaphore buffer is an object since it contains data and behavior to interact with the data, and the access to memory corresponds to memory transaction(s).
However, Wilt fails to teach indicate whether one or more asynchronous memory transactions that include data movement operations between a first type of memory of a graphics processing unit (GPU) and a second type of memory of the GPU have been performed.
However, Mappouras teaches indicate whether one or more asynchronous memory transactions that include data movement operations between a first type of memory of a graphics processing unit (GPU) and a second type of memory of the GPU have been performed (Mappouras, paragraph 40 teaches “HM 205 includes low-capacity, high-bandwidth memory 210 and high-capacity, low-bandwidth memory 215…HM 205 includes other numbers and/or types of memory. In one implementation, GPU hardware 220 includes a memory controller for each memory device of HM 205 and a data transfer engine 230 to transfer data between the memory devices of HM 205.”, paragraph 45 teaches “ GPU hardware 220 includes data transfer engine 230 that allows RENT 265 to initiate data transfers between the HBM 210 and NVM 215…data transfer engine 230 receives commands from RENT 265 to transfer buffers between HBM 210 and NVM 215”, paragraph 51 teaches “RENT selects Buffer 1 to start transferring from the HBM to the NVM asynchronously and in parallel with Layer 1's execution.”, and paragraph 52 teaches “an entry for buffer 1 has been added to the push table and entries for buffers 1 and 2 have been added to the pop table. The entry for buffer 1 in the push table has the C-bit equal to 0 to indicate that the transfer of data from the HBM pool to the NVM has not yet completed. The arrow pointing to buffer 1 in the push table indicates that the run-time manager has identified this buffer as a candidate for transfer.”); HM and NVM act as two types of GPU memory, the data transfer asynchronously occurs between these two and indication of completion is given by the bit using entry for buffer in the push table. Mappouras is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor of indicating whether asynchronous memory transactions between two types of GPU memory have been completed. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Wilt's invention with the indication techniques of Mappouras to reduce memory access latency (Mappouras, abstract). This would be done by the indication and managing memory usage accordingly to add efficiency.
Regarding claim 8, a system recites similar limitations as product/processor claim 1, and
thus is rejected under similar rationale
Method claim 14 recites similar limitations as product/processor claim 1, and thus is
rejected under similar rationale. Regarding claim 20, a non-transitory computer-readable medium recites similar
limitations as product/processor claim 1, and thus is rejected under similar rationale.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Wilt and Mappouras as applied to claim 1 above, and further in view of Gardner et al. (U.S. Patent Application Publication No. 2021/0124610), hereinafter referenced as Gardner.
Regarding claim 5, the combination of Wilt and Mappouras fails to teach wherein information of the software object is to be accessible via one or more other APIs. However, Gardner teaches wherein information of the software object is to be accessible via one or more other APIs (Gardner, paragraph 7 teaches using multiple APIs and paragraph 180 teaches one or more APIs incorporated within the generated workflow to access data objects). Gardner is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor of using APIs to interact with software objects. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Wilt and Mappouras to incorporate the teachings of Gardner to provide an interface that allows computing workflows to be defined in flexible and dynamic ways (Gardner, paragraph 3). This would make the invention more adaptable.
Claim(s) 4, 11 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Wilt and Mappouras as applied to claims 1, 8 and 14 above, and further in view of Seideman et al. (U.S. Patent No. 11,544,229), hereinafter referenced as Seideman.
Regarding claim 4, the combination of Wilt and Mappouras fails to teach wherein the software object is to be used to perform manual transaction accounting of the one or more asynchronous memory transactions. However, Seideman teaches wherein the software object is to be used to perform manual transaction accounting of the one or more asynchronous memory transactions (Seideman, col. 6, lines 1-5 teach user can track flow of data); this shows the transaction tracking can be done manually. Seideman is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor of memory transactions alongside API(s) and tracking data. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Wilt and Mappouras with the data tracking techniques of Seideman to provide an auditable and tamper-resistant record of the transaction (Seideman, col. 1, lines 54-57). This ensures security and trust for data within an application and/or system.
Regarding claim 11, the system claim is similar to product/processor claim 4, and thus is rejected under similar rationale.
Method claim 17 is similar to product/processor claim 4, and thus is rejected under similar rationale.
Claim(s) 6, 7, 12 and 18is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Wilt and Mappouras as applied to claim 1, 8 and 14 above, and further in view of Ostby et al. (U.S. Patent Application Publication No. 2019/0294439), hereinafter referenced as Ostby.
Regarding claim 6, the combination of Wilt and Mappouras teaches wherein the API is (Wilt, col. 1, lines 32-34). However, the combination of Wilt and Mappouras fails to teach to receive an identifier of a group of threads to perform the one or more asynchronous memory transactions as an input. However, Ostby teaches to receive an identifier of a group of threads to perform the one or more asynchronous memory transactions as an input (Ostby, paragraph 87 teaches storing an identifier of a thread group, paragraph 150 teaches thread groups associated with an execution lane and paragraph 152 teaches memory devices storing data). For data to be stored in memory device, the memory must first be accessed which shows the memory transaction. Ostby is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor of data processing using threads. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify combination of Wilt and Mappouras to incorporate the teachings of Ostby so that execution efficiency may be improved by grouping execution threads (Ostby, paragraph 7).
Regarding claim 7, the combination of Wilt and Mappouras teaches wherein the API is (Wilt, col. 1, lines 32-34). However, the combination of Wilt and Mappouras fails to teach to receive an indication of a state of a group of threads as an input. However, Ostby teaches to receive an indication of a state of a group of threads as an input (Ostby, paragraphs 82 and 83 teach indicating for each thread or threads of the group, whether the thread(s) are active or not). The API is able to receive input. The same motivation used in claim 6 for Ostby applies here for claim 7.
Regarding claim 12, the combination of Wilt and Mappouras teaches wherein the API is (Wilt, col. 1, lines 32-34). However, the combination of Wilt and Mappouras fails to teach to receive an identifier of a group of threads to perform the one or more asynchronous memory transactions and a pointer to a state of the group of threads as inputs. However, Ostby teaches to receive an identifier of a group of threads to perform the one or more asynchronous memory transactions (Ostby, paragraph 87 teaches storing an identifier of a thread group, paragraph 150 teaches thread groups associated with an execution lane and paragraph 152 teaches memory devices storing data; for data to be stored in memory device, the memory must first be accessed which shows the memory transaction) and a pointer to a state of the group of threads as inputs (Ostby, paragraph 79 teaches the next instructions in program to be executed by the thread group comprise pointer(s), and paragraphs 82 and 83 teach indicating for each thread or threads of the group, whether the thread(s) are active or not).
The same motivation used in claim 6 for Ostby applies here for claim 12.
Regarding claim 18, the combination of Wilt, Mappouras and Ostby teaches wherein the API is (Wilt, col. 1, lines 32-34) to receive an identifier of a group of threads to perform the one or more asynchronous memory transactions (Ostby, paragraph 87 teaches storing an identifier of a thread group, paragraph 150 teaches thread groups associated with an execution lane and paragraph 152 teaches memory devices storing data; for data to be stored in memory device, the memory must first be accessed which shows the memory transaction), a pointer to a state of the group of threads, (Ostby, paragraph 79 teaches the next instructions in program to be executed by the thread group comprise pointer(s), and paragraphs 82 and 83 teach indicating for each thread or threads of the group, whether the thread(s) are active or not) and a number of threads in the group that are involved in performing an asynchronous data movement operation as inputs (Ostby, paragraph 82 teaches a bitmap corresponding to the number of threads and paragraph 85 teaches data that thread will be fetching and Mappouras, paragraph 51 teaches “transferring from the HBM to the NVM asynchronously”); this shows an asynchronous data movement operation.
The same motivation used in claim 6 for Ostby applies here for claim 18.
Claim(s) 2, 9 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Wilt and Mappouras as applied to claim 1, 8 and 14 above, and further in view of Seideman and Stark et al. (U.S. Patent Application Publication No. 2016/0371139), hereinafter referenced as Stark.
Regarding claim 2, the combination of Wilt and Mappouras fails to teach wherein the one or more software objects include a thread synchronization object to be used to perform manual transaction accounting. However, Seideman teaches to perform manual transaction accounting (Seideman, col. 6, lines 1-5 teach user can track flow of data); this shows the transaction tracking can be done manually. The same motivation used in claim 4 for Seideman applies here for claim 2.
However, the combination of Wilt, Mappouras and Seideman fails to teach wherein the one or more software objects include a thread synchronization object to be used. However, Stark teaches wherein the one or more software objects include a thread synchronization object to be used (Stark, paragraph 40 and fig. 5 teach that the method 500 itself can be implemented asynchronously and includes memory transaction(s) such as steps 530 and 550, and paragraph 40 also teaches the processing threads implementing method 500 may be synchronized using semaphores). The memory is being accessed asynchronously to perform the steps meaning it is an asynchronous memory transaction and semaphores are a thread synchronization object. Stark is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor of thread synchronization. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Wilt, Mappouras and Seideman to incorporate the teachings of Stark to prevent a user from accidently or maliciously overwriting the metadata but still allowing the user to read the metadata (Stark, paragraph 37). Regarding claim 9, the system claim is similar to product/processor claim 2, and thus is rejected under similar rationale.
Method claim 15 is similar to product/processor claim 2, and thus is rejected under similar rationale.
Claim(s) 3, 10 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Wilt and Mappouras as applied to claims 1, 8 and 14 above, and further in view of Seideman and Kerr et al. (U.S. Patent Application Publication No. 2021/0124582), hereinafter referenced as Kerr.
Regarding claim 3, the combination of Wilt and Mappouras fails to teach the one or more software objects include a pipeline object to be used to perform manual transaction accounting. However, Seideman teaches to perform manual transaction accounting (Seideman, col. 6, lines 1-5 teach user can track flow of data); this shows the transaction tracking can be done manually. The same motivation used in claim 4 for Seideman applies here for claim 3. However, the combination of Wilt, Mappouras and Seideman fails to teach the one or more software objects include a pipeline object to be used. However, Kerr teaches the one or more software objects include a pipeline object to be used (Kerr, paragraph 87 teaches tag pipeline allocating a tag). The tag allocated from the tag pipeline is a pipeline object. Kerr is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor of accessing and manipulating data using various memories of the GPU. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Wilt, Mappouras and Seideman to incorporate the teachings of Kerr to reduce latency and provide higher bandwidth (Kerr, paragraph 56). This would mean improved computational efficiency as well as faster data access. Regarding claim 10, the system claim is similar to product/processor claim 3, and thus is rejected under similar rationale.
Method claim 16 is similar to product/processor claim 3, and thus is rejected under similar rationale.
Claim(s) 13 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Wilt and Mappouras in view of Seideman, Stark and Gardner.
Regarding claim 13, Wilt fails to teach wherein the one or more software objects include a thread synchronization object to be used to perform manual transaction accounting, and information of the software object is to be accessible via one or more other APIs. However, Seideman teaches to perform manual transaction accounting (Seideman, col. 6, lines 1-5 teach user can track flow of data); this shows the transaction tracking can be done manually. The same motivation used in claim 4 for Seideman applies here for claim 13.
However, the combination of Wilt, Mappouras and Seideman fails to teach wherein the one or more software objects include a thread synchronization object to be used. However, Stark teaches wherein the one or more software objects include a thread synchronization object to be used (Stark, paragraph 40 and fig. 5 teach that the method 500 itself can be implemented asynchronously and includes memory transaction(s) such as steps 530 and 550, and paragraph 40 also teaches the processing threads implementing method 500 may be synchronized using semaphores). The memory is being accessed asynchronously to perform the steps meaning it is an asynchronous memory transaction and semaphores are a thread synchronization object. The same motivation used in claim 2 for Stark applies here for claim 13.
However, the combination of Wilt, Mappouras, Seideman and Stark fails to teach and information of the software object is to be accessible via one or more other APIs
However, Gardner teaches and information of the software object is to be accessible via one or more other APIs (Gardner, paragraph 7 teaches using multiple APIs and paragraph 180 teaches one or more APIs incorporated within the generated workflow to access data objects).
The same motivation used in claim 5 for Gardner applies here for claim 13.
Method claim 19 is similar to system claim 13, and thus is rejected under similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Brennan (US 2020/0174697), paragraph 16 teaches “data transfer or transferring data between the compute units in the GPU 105… GPU 105 or the CPU 130 can perform other operations concurrently with the data transfers being performed by the DMA logic 155, which may provide an interrupt to the GPU 105 or the CPU 130 to indicate that the transfer is complete”.
Evans et al. (U.S. Patent Application Publication No. 2021/0294707) paragraph 332 teaches “enable asynchronous memory transfers between GPU 3692 and other GPUs 3692.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NAUMAN U AHMAD whose telephone number is (703)756-5306. The examiner can normally be reached Monday - Friday 9:00am - 5:00pm.
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.
/N.U.A./Examiner, Art Unit 2611