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 .
first inventor to file provisions of the AIA .
Response to Amendment
This Office Action is responsive to the amendment filed 23 December 2025. Since this Office Action includes a new ground of rejection not necessitated by Applicant’s amendments to the claims, this action is made Non-Final.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 3 and 5-6 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by De (US 2017/0147516).
As per claim 1, De teaches a system (figure 1) including:
a host processor (“host CPU” 80, figure 1);
a host memory connected to the host processor (“system memory” 82, figure 1, connected via the bus between host CPU 80 and system memory 82);
a storage device connected to the host processor (“data storage unit” 100, figure 1)…including a storage medium (“non volatile memory array” 150 and buffers 152, 154, 156 in figure 2) and a controller to access data on the storage medium (“controller” 110, figure 2 and paragraphs [0031], [0032]);
an accelerator communicating with the host processor (“GPU” 84, figure 1, connected to host CPU 80 through data bus 60 and having a communication represented by line 68 in figure 1), the accelerator configured to produce an output based on processing of an input data by the accelerator responsive to a request from the host processor (see paragraph [0014], lines 8-11, which describes the CPU 80 offloading operations [“request from the host processor”]; see also paragraph [0046] where the CPU sends a programming command [also a “request from the processor”] to the GPU for the GPU to used direct communication with the storage device. In paragraph [0058] De sets forth that the GPU 84 may perform one or more functions using data received from the storage device [responsive to the CPU command], including computations on the data), the accelerator including a local memory (“GPU memory” 86 in figure 1), the local memory including a first region (“buffer 88”, figure 1) and a second region (the remainder of the GPU memory 86 not including the buffer 88);
wherein the host processor and host memory are external to the storage device (figures 1 and 2, showing the storage device is external to the CPU and system memory);
wherein the output is different from the input data (see paragraph [0058] which describes the GPU performing complex computations on behalf of the CPU, determining results, and writing the results to buffer 88 for eventual storage in data storage 100; performing the complex computations inherently involves an output that is different than the input);
wherein the accelerator is configured to store the output of the accelerator in a destination, the destination including…the storage device (see paragraph [0058], lines 12-14) via the buffer 88 (“first region”).
Wherein the buffer 88 (“first region of the local memory”) is dedicated to storing communications data (“a first bias mode”). See paragraph [0022]. The remainder of the GPU memory (less the buffer 88) is used for other purposes then (“a second bias mode”).
As per claim 3, De teaches that the local memory (“system memory” 82) includes DRAM. See paragraph [0016].
As per claim 5, De teaches writing data to the storage device (see paragraph [0058], lines 12-14) via the buffer 88 (“first region”). Data output from the GPU is stored in the buffer 88 (“first region”) and in the non-volatile memory array 150 (see paragraph [0042], lines 10-17). The function (code and/or hardware) to perform the copying of data from buffer 88 to storage device 100 represents the claimed “data mover”.
As per claim 6, data output from the GPU is stored in the buffer 88 (“first region”) and in the non-volatile memory array 150 (see paragraph [0042], lines 10-17). The function (code and/or hardware) of the CPU to determine whether to perform the copying of data from buffer 88 to storage device 100 or not (see paragraph [0026] of De) represents the claimed “data mover”.
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.
Claim(s) 9, 12-13, 15 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over De in view of Bobley et al. (US 11,087,409).
As per claim 9, De teaches:
a host processor (“host CPU” 80, figure 1) and an accelerator (“GPU” 84, figure 1, connected to host CPU 80 through data bus 60 and having a communication represented by line 68 in figure 1), the accelerator configured to produce an output based on processing of an input data by the accelerator responsive to a request from the host processor (see paragraph [0014], lines 8-11, which describes the CPU 80 offloading operations [“request from the host processor”]; see also paragraph [0046] where the CPU sends a programming command [also a “request from the processor”] to the GPU for the GPU to used direct communication with the storage device. In paragraph [0058] De sets forth that the GPU 84 may perform one or more functions using data received from the storage device [responsive to the CPU command], including computations on the data), the accelerator including a local memory (“GPU memory” 86 in figure 1), the local memory including a second region (“buffer 88”, figure 1) and a first region (the remainder of the GPU memory 86 not including the buffer 88);
wherein the output of the accelerator is produced by the accelerator based on processing of the data by the accelerator based on the request from the processor (see paragraph [0014], lines 8-11, which describes the CPU 80 offloading operations [“request from the host processor”]; see also paragraph [0046] where the CPU sends a programming command [also a “request from the processor”] to the GPU for the GPU to used direct communication with the storage device. In paragraph [0058] De sets forth that the GPU 84 may perform one or more functions using data received from the storage device [responsive to the CPU command], including computations on the data);
wherein the output is different from the input data (see paragraph [0058] which describes the GPU performing complex computations on behalf of the CPU, determining results, and writing the results to buffer 88 for eventual storage in data storage 100; performing the complex computations inherently involves an output that is different than the input);
wherein the destination is one of…a storage device (see paragraph [0058]);
wherein the host processor and host memory are external to the storage device (figures 1 and 2, showing the storage device is external to the CPU 80 and system memory 82 [“host memory”]);
a storage device connected to the host processor (“data storage unit” 100, figure 1)…including a storage medium (“non-volatile memory array” 150 and buffers 152, 154, 156 in figure 2) and a controller to access data on the storage medium (“controller” 110, figure 2 and paragraphs [0031], [0032]).
De does not particularly teach copying an output of the accelerator from the first region of the local memory of the accelerator by the host processor to a destination and the destination is the system memory (the claimed “host memory”) (De’s teachings generally address the interaction of the CPU and GPU with the data storage unit and doesn’t discuss details of when the CPU offloads tasks to the GPU that returns data to the CPU and CPU memory directly). Bobley et al. teaches a process whereby a thread on a host copies data to be processed from a host memory to a GPU memory (i.e. accelerator local memory), invokes GPU threads to process the data, and then the host thread will copy the results from the GPU memory to the host memory. See column 19, lines 26-33.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have incorporated the teachings of Bobley et al. regarding a host copying data processed by a GPU back to a host memory, as this would provide for faster access by the host to important processing data than if the data was sent to another location first.
As per claim 12, the combination of De and Bobley et al. would teach accessing the data processed by the GPU from the non-buffer region of the GPU (where the buffer 88 is used for transfers with the data storage unit 100 in De) and transferring/writing the data to the system memory as outlined in Bobley et al. at column 19, lines 26-33.
As per claim 13, De teaches the ability by the CPU to select whether to store data in the data storage directly from the GPU using the buffer 88 (“second region”). See paragraphs [0026-0027]. This teaching would also suggest that the CPU doesn’t have to provide information that would cause the GPU to use buffer 88 and therefore would select another destination. Based on the combination of De and Bobley, the destination is the system memory (“host memory”).
As per claim 15, the function (code and/or hardware) to perform the copying of data from GPU memory to the system memory as set forth in the combination of De and Bobley et al. represents the claimed “data mover”.
As per claim 18, the claim is rejected for the same reasons as claims 9 and 13, further noting the limitation of “sending a destination for an output” is taught by the rationale for claim 13, above.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over De in view of Zaltsman et al. (2014/0059270) or Meir et al. (2014/0059271).
As per claim 2, while De teaches a “write buffer” 152 associated with the data storage unit, De does not explicitly teach that the write buffer is a volatile write buffer. Zaltsman et al. teaches a memory device including a plurality of non-volatile memories (see paragraph [0030]) and an associated volatile write buffer (see paragraph [0040]) within a memory controller (element 32 of figure 1, which is within the memory device 22). Meir et al. teaches an SSD including a SSD controller including a volatile write buffer (see figure 2 and paragraph [0024]). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have incorporated the teachings of Zaltsman et al. or Meir et al. to utilize a volatile write buffer as this type of buffering increases write performance (Zaltsman et al. paragraph [0040]). It is also noted that volatile memory is less expensive to implement than non-volatile memory.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over De in view of Archer et al. (US 2010/0198997).
As per claim 4, De does not specifically teach an “interface command” to identify the destination. Archer teaches at paragraph [0060] an application programming interface (API) used by a host program to specify a destination (e.g. a particular accelerator) for data to be transferred. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have incorporated the teachings of Archer et al. regarding using an API to specify a transfer destination, as this would combine prior art elements according to known methods to yield the predictable result of efficiently transferring data between locations.
The examiner finds that prior art includes each element claimed as outlined above in the discussion(s) of De and Archer et al. One of ordinary skill in the art could have combined the teachings of using an API to transfer data between locations using known techniques and that in the combination the API would perform the function of facilitating transferring data between locations. One of ordinary skill in the art would have recognized that the results of combining the teachings of De and the API of Archer et al. were predicable. See MPEP 2143(I)(A).
Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over De in view of Bobley et al. in further view of Zaltsman et al. (2014/0059270) or Meir et al. (2014/0059271).
As per claims 10 and 19, while De teaches a “write buffer” 152 associated with the data storage unit, De does not explicitly teach that the write buffer is a volatile write buffer. Zaltsman et al. teaches a memory device including a plurality of non-volatile memories (see paragraph [0030]) and an associated volatile write buffer (see paragraph [0040]) within a memory controller (element 32 of figure 1, which is within the memory device 22). Meir et al. teaches an SSD including a SSD controller including a volatile write buffer (see figure 2 and paragraph [0024]). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have incorporated the teachings of Zaltsman et al. or Meir et al. to utilize a volatile write buffer as this type of buffering increases write performance (Zaltsman et al. paragraph [0040]). It is also noted that volatile memory is less expensive to implement than non-volatile memory.
Claim(s) 14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over De in view of Bobley et al. in further view of Archer et al. (US 2010/0198997).
As per claims 14 and 20, the combination of De and Bobley et al. does not specifically teach an “interface command” output from the host to the accelerator to identify the destination. Archer teaches at paragraph [0060] an application programming interface (API) used by a host program to specify a destination (e.g. a particular accelerator) for data to be transferred. It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have incorporated the teachings of Archer et al. regarding using an API to specify a transfer destination, as this would combine prior art elements according to known methods to yield the predictable result of efficiently transferring data between locations.
The examiner finds that prior art includes each element claimed as outlined above in the discussion(s) of De, Bobley et al. and Archer et al. One of ordinary skill in the art could have combined the teachings of using an API to transfer data between locations using known techniques and that in the combination the API would perform the function of facilitating transferring data between locations. One of ordinary skill in the art would have recognized that the results of combining the teachings of De, Bobley et al. and the API of Archer et al. were predicable. See MPEP 2143(I)(A).
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over De in view of Bobley et al. in further view of van Rooyen (US 2018/0240032).
As per claim 11, the combination of De and Bobley et al. does not teach using a cache coherent interconnect protocol between the host CPU and GPU (i.e. over data bus 60). De teaches, at paragraph [0012], that the data bus 60 could be a PCIe, PCI, PCI-eXtended, AGP, or other types of data bus, but does not specifically identify a cache coherent interconnect protocol. The van Rooyen reference teaches at paragraph [0666] using a cache coherent interconnect protocol between an accelerator and CPU (and other devices).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have incorporated the teachings of van Rooyen regarding using a cache coherent interconnect protocol to connect the host CPU and GPU because van Rooyen teaches that cache coherent interconnect protocol provides high bandwidth, low latency access which will expedite data transmissions (see van Rooyen, paragraph [0666]).
Allowable Subject Matter
Claims 7-8, 16-17, and 21 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.
Response to Arguments
Applicant's arguments filed 23 December 2025 have been fully considered but they are not persuasive.
With regards to Applicant’s argument on page 10 of the response filed 23 Dec 2025 regarding De teaching “offloading instructions”, Applicant argues that De does not appear to teach output data is generated from input data. Applicant points to paragraph 14 of De to support this argument noting paragraph 14 is describing “write and read commands to data storage unit”, which don’t involve an output data generated from input data (where the output is different from the input data). This is not persuasive as the argument does not address the rejection where paragraphs 46 and 58 of De are applied to teach these features. It is noted that the claim language is “an output based on processing of an input data by the accelerator responsive to a request from the host processor” (claim 1, lines 7-8), which does not set forth “output data” but merely an “output” based on processed “input data”. Furthermore, the language “responsive to a host request” does not require that any “input data” be included with the “host request”.
With regards to the Applicant’s argument at the bottom of page 10 of the response regarding De’s teaching of the “first region” and “second region” of the local memory, the argument is not persuasive. The Applicant characterizes the teachings of De as an arbitrary division of the GPU memory in De, and then argues that the regions of the present invention have an intentional division as supported by teaching in the instant specification where the regions have different uses. However, this would be an improper importing of claim limitations from the specification (MPEP 2111.01(II)). It is further noted that De’s buffer in the GPU is for a different use from the remainder of the GPU memory (De, paragraph 22).
With regards to Applicant’s argument on page 11 regarding former claim 21 (the limitations of which are now incorporated into amended claim 1), the Applicant argues that the “bias mode” is not a purpose of the region, but how the data in the region should be treated when the data may also be stored in a cache of the host processor. However this interpretation of “bias mode” is not reflected in the claim language of claim 1 and the specification does not provide an explicit definition of the terms (page 7, lines 10-25, use the language “may” when describing the various bias modes), so the BRI of the term is met by the De reference.
With regards to Applicant’s argument on page 12 of the response regarding claim 2, the Examiner concurs with Applicant’s assessment that De does not explicitly teach that the write buffer is volatile (or non-volatile). However Zaltsman et al. and Meir et al. explicitly teach using a volatile write buffer in an SSD/non-volatile memory controller. As this is a new grounds of rejection not necessitated by an amendment to claim 2 this action is made non-final.
With regards to Applicant’s argument on pages 12-13 of the response regarding claim 7, the Examiner finds these arguments persuasive and withdraws the rejection of claim 7. The rejection of claim 8 is also withdrawn based on claim 8’s dependence upon claim 7.
With regards to Applicant’s argument on page 14 of the response regarding claim 4, this is not persuasive. The Archer reference is relied upon to teach a “interface command” used to communicate the information. De already teaches the CPU provides an instruction to the GPU about using “direct communication” which specifically indicates that a buffer within the GPU memory should be used.
With regards to the Applicant’s arguments on pages 14-15 of the response regarding claims 9 and 18, these arguments are similar to the arguments presented for claim 1 and the Examiner refers Applicant’s to the response to arguments for claim 1, above.
Furthermore, With regards to Applicant’s arguments on page 17 regarding De teaching away from Bobley, the argument is not persuasive as the argument takes the view that De is modifying Bobley and that De teaches away from Bobley. However De is the primary reference in this instance being modified by Bobley and is therefore does not teach away from Bobley (as Bobley is added to address that De does not teach copying by the host).
With regards to Applicant’s arguments on page 16 regarding claims 10 and 19, these are similar to the arguments presented for claim 2. A new grounds of rejection has been provided to address these limitations.
With regards to Applicant’s arguments on pages 16-17 regarding claim 12, the argument is not persuasive as the argument takes the view that De is modifying Bobley and that De teaches away from Bobley. However De is the primary reference in this instance being modified by Bobley and is therefore does not teach away from Bobley (as Bobley is added to address that De does not teach copying by the host).
With regards to Applicant’s argument on pages 17-18 of the response regarding claim 16, the Examiner finds these arguments persuasive and withdraws the rejection of claim 16. The rejection of claim 17 is also withdrawn based on claim 17’s dependence upon claim 16.
With regards to Applicant’s arguments on page 19 regarding claim 11, these are not persuasive. The van Rooyen reference teaches a cache coherent interconnect protocol in paragraph [0666], lines 26-27, and therefore meets the breadth of the claim limitation.
With regards to Applicant’s arguments on page 20 of the response regarding claims 14 and 20, this is not persuasive. The Archer reference is relied upon to teach a “interface command” used to communicate the information. De already teaches the CPU provides an instruction to the GPU about using “direct communication” which specifically indicates that a buffer within the GPU memory should be used.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Reginald G. Bragdon whose telephone number is (571)272-4204. The examiner can normally be reached M-Th 6:30am-4pm.
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.
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.
/REGINALD G BRAGDON/Supervisory Patent Examiner, Art Unit 2139
Prosecution Insights