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 .
DETAILED ACTION
Response to Amendment
The amendment filed on April 14, 2026 has been received and entered.
Applicant’s Amendments to the Claims have been received and acknowledged.
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 applicant regards as his invention.
Claims 1-15 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.
In claim 1, line 7, it is not clear which input/output commands are being received. Similar problems exist in claims 8 and 15.
In claim 15, line 6, “the remote computing apparatus” lacks proper antecedent basis since it was not mentioned previously.
In claim 15, line 7, it is not clear what is meant by “for performance of input/output commands”.
In claim 15, line 7, “input/output commands of the first FPGA board” lack proper antecedent basis since it was not mentioned previously.
Appropriate correction is required.
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) 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over Ben-Yehuda et al. (U.S. Patent No. 11,256,431 A1), hereafter referred to as Ben-Yehuda’431 in view of Applicant’s Admitted Prior Art, hereafter referred to as AAPA.
Referring to claim 1, Ben-Yehuda’431 as claimed, a remote computing apparatus that communicates with a local computing apparatus (see Figs. 3, 4, 12, 18), comprising: a communication interface (network interface and/or storage interface, see Col. 9, line 55, Col. 10, lines 25, 67, Col. 41, line 60 to Col. 42, line 18 and Figs. 1-4); a storage device (storages such as SSD units 15, see Figs. 2-4); a memory in which a driver of the storage device is executed (The accelerator device driver runs in the Linux kernel and is the entity responsible for initializing and driving the accelerator, see Col. 23, lines 46-52); and a processor that stores data and metadata (metadata, see Col. 21, lines 4-49, Col. 22, lines 7-36, and Fig. 9) associated with the data in the storage device (processors such as storage processor, user processor, etc. that perform storage management tasks and/or random logic, see Col. 36, lines 26-49), wherein the driver is configured to receive input/output commands for the storage device from the local computing apparatus through the communication interface (the driver acts as a pipe between the Global FTL and then accelerator. It runs the in the context of the Global FTL and takes commands from the readers/writers, see Col. 23, lines 46-62), the processor is configured to process the received input/output commands for the storage device using a plurality of queues (submission/completion queues, see Col. 15, line 60 to Col. 16, line 32, Figs. 2 and 3; also note Col. 41, lines 46-51), and the driver is further configured to provide a result of processing the input/output commands to the local computing apparatus through the communication interface (data is transferred by the driver to/from the accelerator and processed by the accelerator in the form of accelerator objects…Each accelerator object is processed (e.g. compressed/decompressed, encrypted/decrypted) independently, see Col. 24, lines 5-13; The Global FTL polls the completions from the driver, see Col. 24, line 51 to Col. 25, line 2, Col. 52, lines 41-44).
However, Ben-Yehuda’431 does not explicitly teach storing the data and metadata in advance of receiving input/output commands, wherein the processor is configured to use the metadata to perform input/output commands.
AAPA discloses storing the data and metadata in advance of receiving input/output commands, wherein the processor is configured to use the metadata to perform input/output commands (reading/writing data after the metadata including the memory address is transmitted, see para. [0004]).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to modify Ben-Yehuda’431’s invention to comprise storing the data and metadata in advance of receiving input/output commands, wherein the processor is configured to use the metadata to perform input/output commands, as taught by AAPA, in order to perform a read/write operation on a remote storage device (see para. [0004]).
As to claim 2, Ben-Yehuda’431 also discloses the driver is further configured to: receive a write command for writing data of a specific size to a specific address of the storage device from the local computing apparatus (the front-ends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network., see Col. 15, lines 11-20) through the communication interface and add the write command to a submission queue (submit a command on the submission queue to a backend reader core asking to read some data from the SSDs, see Col. 15, line 61 to Col. 16, line 16), and while waiting for an execution response of the processor for the write command, receive at least a portion of the data of the specific size (specific addresses of the blocks that are being written, see Col. 41, lines 17-30, Col. 46, line 65 to Col. 57, and Col. 19, lines 26-44) from the local computing apparatus through the communication interface and store it in a buffer (Data is copied into the system once when it arrives from the network and from that point, it remains in system memory (non volatile) or transferred to the accelerator memory…customer writes are always written to NVRAM first, to maintain persistence in the presence of unexpected software bugs or power loss, see Col. 14, line 61 to Col. 15, line 3).
As to claim 3, Ben-Yehuda’431 also discloses the driver is further configured to sequentially transmit data received in the buffer to the storage device when receiving an execution response of the processor for the write command, and the processor is further configured to store the sequentially transmitted data and associated metadata (metadata, see Col. 21, lines 4-49, Col. 22, lines 7-36, and Fig. 9) at a specific address of the storage device (write data to SSDs sequentially, see Col. 15, lines 35-41, Col. 20, lines 5-14).
As to claim 4, Ben-Yehuda’431 also discloses the processor is further configured to share result information corresponding to the write command with the driver using a completion queue (completion queues, see Fig. 3 and Col. 15, line 61 to Col. 16, line 15), and the driver is further configured to transmit the result information corresponding to the write command to the local computing apparatus through the communication interface (data is transferred by the driver to/from the accelerator and processed by the accelerator in the form of accelerator objects…Each accelerator object is processed (e.g. compressed/decompressed, encrypted/decrypted) independently, see Col. 24, lines 5-13; The Global FTL polls the completions from the driver, see Col. 24, line 51 to Col. 25, line 2, Col. 52, lines 41-44).
As to claim 5, Ben-Yehuda’431 also discloses the driver is further configured to: receive a read command for reading data of a specific size at a specific address of the storage device from the local computing apparatus (the front-ends receive customer read/write requests via a block access protocol such as NVMeoF or object get/set requests via a key/value access protocol over the network., see Col. 15, lines 11-20) through the communication interface, add the read command to a submission queue (submit a command on the submission queue to a backend reader core asking to read some data from the SSDs, see Col. 15, line 61 to Col. 16, line 16), and provide metadata for the read command to the processor (metadata, see Col. 25, lines 3-7, 50-57; also note: acknowledging back to the client, see Col. 17, lines 4-20, readers/writers process after receiving read/write request, see Col. 19, lines 39 to Col. 20, line 66).
As to claim 6, Ben-Yehuda’431 also discloses the processor is further configured to share result information corresponding to the read command with the driver using a completion queue (completion queues, see Fig. 3 and Col. 15, line 61 to Col. 16, line 15), and the driver is further configured to transmit data corresponding to the read command to the local computing apparatus through the communication interface (data is transferred by the driver to/from the accelerator and processed by the accelerator in the form of accelerator objects…Each accelerator object is processed (e.g. compressed/decompressed, encrypted/decrypted) independently, see Col. 24, lines 5-13; The Global FTL polls the completions from the driver, see Col. 24, line 51 to Col. 25, line 2, Col. 52, lines 41-44).
As to claim 7, Ben-Yehuda’431 also discloses the driver is further configured to provide a transmission completion signal to the local computing apparatus through the communication interface when data transmission corresponding to the read command is completed (posts a completion to the driver which is polled by the Global FTL., see Col. 24, line 67 to Col. 25, line 3, Col. 25, lines 50-54; also note: send completions, see Col. 27, lines 7-63 and as soon as a request has been written, it can be acknowledged by to the client, see Col. 17, lines 5-8).
Note claims 8 recites similar limitations of claim 1. Therefore it is rejected based on the same reason accordingly.
Note claims 9 recites the corresponding limitations of claim 2. Therefore it is rejected based on the same reason accordingly.
Note claims 10 recites the corresponding limitations of claim 3. Therefore it is rejected based on the same reason accordingly.
Note claims 11 recites the corresponding limitations of claim 4. Therefore it is rejected based on the same reason accordingly.
Note claims 12 recites the corresponding limitations of claim 5. Therefore it is rejected based on the same reason accordingly.
Note claims 13 recites the corresponding limitations of claim 6. Therefore it is rejected based on the same reason accordingly.
Note claims 14 recites the corresponding limitations of claim 7. Therefore it is rejected based on the same reason accordingly.
Referring to claim 15, Ben-Yehuda’431 as claimed, a data storage system (see Figs. 3, 4, 12, 18), comprising: a first field programmable gate array (FPGA) board (remote clients, see Col. 15, lines 55-63; FPGA, see Col. 4, lines 3-66); and a second FPGA board (FPGA, see Col. 4, lines 3-66) including a communication interface (network interface and/or storage interface, see Col. 9, line 55, Col. 10, lines 25, 67, Col. 41, line 60 to Col. 42, line 18 and Figs. 1-4), a data buffer (FE write-buffer receives incoming write requests and write them to non-volatile memory, see Col. 17, lines 3-25 and Col. 46, lines 22-59; also note: data is copied into the system once (or few times) when it arrives from the network and from that point on, it remains in the system memory (non volatile memory) or transferred to the accelerator memory such as accelerator’s FPGA’s internal DDR; NVRAM, DRAM, see Col. 14, line 59 to Col. 15, line 3), a storage device (storages such as SSD units 15, see Figs. 2-4), and a driver for controlling the storage device (The accelerator device driver runs in the Linux kernel and is the entity responsible for initializing and driving the accelerator, see Col. 23, lines 46-52), wherein the data buffer stores data received through the communication interface, and the driver is further configured to manage input/output commands for the storage device (the driver acts as a pipe between the Global FTL and then accelerator. It runs the in the context of the Global FTL and takes commands from the readers/writers, see Col. 23, lines 46-62; also note: storage management tasks and/or random logic, see Col. 36, lines 26-49) using a plurality of queues (submission/completion queues, see Col. 15, line 60 to Col. 16, line 32, Figs. 2 and 3; also note Col. 41, lines 46-51), and provide information on a result of executing the input/output commands to the first FPGA board through the interface (data is transferred by the driver to/from the accelerator and processed by the accelerator in the form of accelerator objects…Each accelerator object is processed (e.g. compressed/decompressed, encrypted/decrypted) independently, see Col. 24, lines 5-13; The Global FTL polls the completions from the driver, see Col. 24, line 51 to Col. 25, line 2, Col. 52, lines 41-44).
However, Ben-Yehuda’431 does not explicitly teach storing the data and metadata in advance of receiving input/output commands, wherein the processor is configured to use the metadata to perform input/output commands.
AAPA discloses storing the data and metadata in advance of receiving input/output commands, wherein the processor is configured to use the metadata to perform input/output commands (reading/writing data after the metadata including the memory address is transmitted, see para. [0004]).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to modify Ben-Yehuda’431’s invention to comprise storing the data and metadata in advance of receiving input/output commands, wherein the processor is configured to use the metadata to perform input/output commands, as taught by AAPA, in order to perform a read/write operation on a remote storage device (see para. [0004]).
Response to Arguments
Applicant's arguments filed 4/14/2026 have been fully considered but they are moot due to new grounds of rejection.
Applicant is suggested to clarify the location of the components such as the communication interface, storage device, memory, processor since there are multiple apparatuses. In addition, “local computing apparatus” and “remote computing apparatus” is suggested to be further differentiated since whether a device is considered local or remote is determined from the perspective of the entity performing the communication. A remote read or write is implemented using the same fundamental memory access mechanisms as a local read or write; the difference is the location of the requesting entity relative to the servicing device. Accordingly, the characterization of an operation as “local” or “remote” is perspective-based, not indicative of a different operation.
In summary, Ben-Yehuda’431 and AAPA disclose the claimed limitations as set forth.
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TITUS WONG whose telephone number is (571)270-1627. The examiner can normally be reached Monday-Friday, 10am-6pm.
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, Idriss Alrobaye can be reached on (571) 270-1023. 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.
/TITUS WONG/Primary Examiner, Art Unit 2181
Prosecution Insights