DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This Office Action is in response to Applicant’s amendment filed 07/17/2026 which has been entered and made of record. Claims 1, 4-5, 8, 11, 13-14, 17 and 19 have been amended. No
claim has been cancelled or newly added. Claims 1-20 are pending in the application.
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 (due to applicant’s arguments directed to newly amend limitation(s) which is addressed by new prior art presented in this Office Action).
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, Johns et al. (U.S. Patent Application Publication No. 20200183854), hereinafter referenced as Johns and Ying et al. (U.S. Patent Application Publication No. 2019/0220384), hereinafter referenced as Ying.
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.
However, the combination of Wilt and Mappouras fails to teach one or more software objects associated with one or more threads; data movement operations…have been performed by the one or more threads; number of threads used to perform the one or more asynchronous memory transactions.
However, Johns teaches one or more software objects associated with one or more threads (Johns, paragraph 4 teaches “array objects are distributed across threads and are identified by table entries used to map locations such as Universal Parallel C (UPC) array objects” and paragraph 160 teaches “a set of shared memory regions that may represent an object or a set of variables. The method establishes a version of the shared memory associated with an object at a given point in time (or snapshot of memory). Modifications to a shared memory outside of the snapshot shared memory regions are made visible after the time of the modification (eventual consistency) while modifications to shared memory inside of the snapshot are only locally visible to the thread or process performing the modifications (snapshot consistency)”); array/software objects distributed across threads shows software objects associated with thread(s) and shared memory representing object which is visible by thread once modifications are made shows software objects associated with thread(s) as well; data movement operations…have been performed by the one or more threads (Johns, paragraph 172 teaches “At Begin ∥, Parallel Thread 4062 spawns Parallel Thread 4072 and Main Thread 4064 spawns Parallel Thread 4078” and paragraph 173 teaches “Handling the Coordination (Begin ∥) point sets the state of each shared memory as copy-on-write [steps 4130 and 4131] in preparation for modifications to shared memory [steps 4130, 4131, 4150, and 4151]. At step 4130 and 4131, a local modified copy of shared memory “x” 4140 and “y” 4141 is created”); this shows data movement operation performed by the thread(s) since threads here create local modified copy of shared memory (thread performs data movement operation of copying data into local copy[copy requires data read and written from shared memory to local memory]); number of threads used to perform the one or more asynchronous memory transactions (Johns, paragraph 175 teaches “tracks the state of shared memory, when entering a transaction processing state, corresponding to one or more global virtual addresses accessed by a plurality of processing threads executing a plurality of transactions. Transactions executed by one of the plurality of threads allows a selected one of the plurality of transactions to complete”); this shows a number of threads executing plurality of memory transactions. Johns is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor of threads being used for memory transactions. 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 thread for memory transactions techniques of Johns to ensure the system achieves an efficient memory-to-memory coupling of applications within a workflow by locating data in storage local (Johns, paragraph 187). This would be due to local copy of data and ensures reduced latency due to local access being faster.
However, the combination of Wilt, Mappouras and Johns fails to teach wherein one or more input parameters to the API indicate a number of threads used.
However, Ying teaches wherein one or more input parameters to the API indicate a number of threads used (Ying, paragraph 29 teaches “dedicated processing resource may be a GPU, and the parameters for executing the tasks may include API parameters for the GPU, such as memory size, kernel function name, thread count, block number, and the like. In one example, the API may be a compute unified device architecture (CUDA) API.”); this shows input parameters to API indicate a number of threads used (thread count). Ying is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor of API parameters indicating thread count. 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 Johns with the parameters as thread count techniques of Ying to improve performance (Ying, paragraph 31). This would be due to tuned/specific thread count being a parameter to optimize usage of threads.
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. In addition, one of ordinary skill in the art would understand that an API call is received. 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, Mappouras, Johns, and Ying 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, Mappouras, Johns, and Ying fails to teach wherein information of the one or more software objects is to be accessible via one or more other APIs. However, Gardner teaches wherein information of the one or more software objects 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, Mappouras, Johns, and Ying 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, Mappouras, Johns, and Ying 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, Mappouras, Johns, and Ying fails to teach wherein the one or more software objects are to be used to perform manual transaction accounting of the one or more asynchronous memory transactions. However, Seideman teaches wherein the one or more software objects are 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, Mappouras, Johns, and Ying 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, Mappouras, Johns, and Ying 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, Mappouras, Johns, and Ying teaches wherein the API is (Wilt, col. 1, lines 32-34). However, the combination of Wilt, Mappouras, Johns, and Ying 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 the combination of Wilt, Mappouras, Johns, and Ying 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, Mappouras, Johns, and Ying teaches wherein the API is (Wilt, col. 1, lines 32-34). However, the combination of Wilt, Mappouras, Johns, and Ying 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, Mappouras, Johns, and Ying teaches wherein the API is (Wilt, col. 1, lines 32-34). However, the combination of Wilt, Mappouras, Johns, and Ying 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, Johns, Ying 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, Mappouras, Johns, and Ying 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, Mappouras, Johns, and Ying 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, Johns, Ying 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, Johns, Ying 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, Mappouras, Johns, and Ying 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, Mappouras, Johns, and Ying 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, Johns, Ying 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, Johns, Ying 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, Mappouras, Johns, and Ying as applied to claim 8 above, and further in view of Seideman, Stark and Gardner.
Regarding claim 13, the combination of Wilt, Mappouras, Johns, and Ying 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 one or more software objects 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, Johns, Ying 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, Johns, Ying, Seideman and Stark fails to teach and information of the one or more software objects is to be accessible via one or more other APIs
However, Gardner teaches and information of the one or more software objects 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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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.
/KEE M TUNG/Supervisory Patent Examiner, Art Unit 2611
/N.U.A./Examiner, Art Unit 2611
Prosecution Insights