DETAILED ACTION
This Action is responsive to the Amendments filed 06/18/2026.
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 .
Claim Status
Claims 1-2, 4, 6-14, and 16-20 are amended. Claims 3, 5, and 15, and 17 are cancelled. Claims 1-2, 4, 6-14, 16, and 18-20 are pending and have been examined.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 6-14, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (US 20200136996 A1)(cited by examiner in previous Action)(hereafter referred to as Li) further in view of Cosby et al. (US 20180335975 A1)(hereafter referred to as Cosby).
Regarding Claim 1,
Li discloses the following limitations:
An apparatus (Fig. 19B) comprising:
a network interface device (NIC 1950, Fig. 19B) comprising :
a host interface; (VF+PFs, Fig. 19B // ¶¶0117; 0124) – VFs and PFs exposed by NIC 1950 are accessed by host OS 1930. Examiner accordingly considers the VFs and PFs of NIC 1950 as “a host interface”--
a network interface; (“a network interface” [0144])) – A network interface of the NIC receives NVMe commands from the host (see Fig. 20, step 2010)--
direct memory access (DMA) circuitry; (Hash Engine 1954, Fig. 19 // “RDMA QP lookup can include use of hash engine 1954” [0138]) – Examiner considers circuitry involved in DMA operations, such as hash engine 1954 which performs RDMA QP lookup, as “direct memory access (DMA) circuitry”-- and
circuitry (NVMe-oF Initiator 1952, Fig. 19B // ¶0140) to:
receive (Fig. 20, step 2010) a storage access command and (“at 2010, an application executing on a host … issues an NVMe command (CMD) to a network interface” [0144]) – The NIC receives an NMVe command from a host application--
process (Fig. 20, steps 2012-2022) the storage access command (“At 2012, an NVMe-OF initiator processes the CMD … At 2022, the NIC can send an NVMe-oF command to a device associated with an identified RDMA QP number” [0144-145]) – The NIC processes the received command to identify a particular destination for the received command--
based on a type of the storage access command, (“Read/Write” [0127])
a connection queue pair, (“a QP identifier” [0144])
namespace identifier (NSID) based on Non-Volatile Memory Express (NVMe), (“the namespace ID (NSID)” [0144])
logical block address (LBA) start, (“an LBA” [0144]) and
number of logical blocks, (“Length” [0127]) (“The CMD specifies the namespace ID (NSID) and an LBA. The NSID and the LBA number are used 2014 for a lookup in the hint lookup table to find a QP identifier based on the NSID … At 2022, the NIC can send an NVMe-oF command to a device associated with an identified RDMA QP number.” [0144-145] // “A simple hint includes fields [Start LBA, Length, Read/Write, Target Extent List]” [0127]) – The NIC uses a hint derived using information from the received command to identify a QP identifier to use as the destination for the received command. The NSID and an LBA received with the command are used to perform a lookup in a hint lookup table to determine the QP identifier to use. The type of command (Read/Write) and the length of the command are fields of the hint.--
wherein: based on a first configuration (¶0144) that is based on the type of storage access command, connection queue pair, NSID, LBA start, and number of logical blocks, the circuitry is to modify … the storage access command (“an NVMe command” [0144]) and provide a modified storage access command (“an NVMe-oF command” [0145]) and associated data for submission to a target storage (“a device” [0145]) associated with the storage access command. (“an application … issues an NVMe command (CMD) to a network interface … At 2022, the NIC sends an NVMe-oF command to a device associated with an identified RDMA QP number” [0144-145] // Fig. 20) – As discussed above, each of access type, QP number, NSID, LBA, and length inform how the received NMVe command is processed by the NIC. Certain commands (i.e., “a first configuration” of commands) have an associated hint available in the hint lookup table (step 2018), whereas other commands have no such hint (step 2020). When a hint is available, the “NVMe command” issued by the host (see ¶0144) is subsequently sent, as an “NVMe-oF command” (i.e., “a modified storage access command”) to the target device identified by the QP number. Examiner accordingly considers steps 2010-2022 depicted in Fig. 20 as a method whereby a received “NVMe command” is “modified” into a resulting “NVMe-oF command”.
Li does not provide explicit detail regarding modifying an address within an NVMe command as part of conversion into an NVMe-oF command and accordingly does not disclose the following limitations:
modify an address in the storage access command
However, Cosby discloses the following limitations:
modify an address (“host LBA” [0032]) in the storage access command (Figs. 1A + 1B // “When the host server 14 generates an I/O (read or write) transaction (host command) for one of the host namespaces 22, 24, the abstraction service 30 translates the host command into one or more disk commands for one or more NVMe drive 12 … an LBA abstraction module 36 inspects the LBA field of the host PCIe frame (host command) 28. Collectively, the modules 32, 34, 36 that form the abstraction service 30 generate a disk command to one or more of the NVMe drives” [0089-90] // “The host LBA range in the host command may also be used to identify one or more specific LBA on the identified disk namespace” [0032]) – Examiner considers Host Server 14, Abstraction Service 30, and NVMe drives 12 depicted in Cosby Fig. 1A as analogous to the Host OS 1930, NIC 1950, and Storage Nodes 1972, respectively, depicted in Li Fig. 19B. Similar to NIC 1950 of Li, Abstraction Service 30 of Cosby receives a host command and translates the host command into a disk command submitted to NVMe drives. As shown in Fig. 1B and clarified in ¶0032, translating a host command into a disk command includes translating a host LBA (i.e., “modify[ing] an address”) included within the host command into a disk LBA which is included within the translated command.
Li and Cosby are considered analogous to the claimed invention because they all relate to the same field of translating host storage access commands into NVMe commands submitted to a storage drive. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Li with the teachings of Cosby and realize an apparatus whereby an address within a storage access command is modified to generate a modified storage access command. Using an external device such as an abstraction service to modify a host command address saves processing resources for the host by offloading management of discrete physical NMVe drives away from the host, as taught in Cosby ¶0027: “Embodiments may relieve the host computer from the complexity of separately managing each discrete physical NVMe drive.” [0027]
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Li and Cosby disclose the following limitations:
The apparatus of claim 1 (see Claim 1 limitation mappings above), wherein the type of storage access command comprises a read or write command (Li, “Read/Write” [0127])
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Li and Cosby disclose the following limitations:
The apparatus of claim 1, wherein the modify the storage access command comprises provide the modified storage access command and associated data for submission through a device interface (Li, NVMe-oF Initiator 1952, Fig. 19B) to the target storage associated with the command (Li, “the NIC can send an NVMe-oF command to a device associated with an identified RDMA QP number” [0145]) – As previously discussed and as shown in Li Fig. 19B, NVMe-oF initiator sends the NVMe-oF command to a device associated with the identified QP number.--
or (see MPEP 2143.03)
cause transmission of the modified command in one or more packets.
Regarding Claim 7,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teachings of Li and Cosby disclose the following limitations:
The apparatus of claim 6, wherein the modify the storage access command comprises two or more of (see MPEP 2143.03):
modify a received storage device identifier,
modify a queue pair identifier that is present in the storage access command,
modify a namespace identifier, (Cosby, “the host namespace in a host command may be uniquely associated with a specific set (sequence) of disk namespaces” [0022] // “A namespace abstraction module 32 inspects the namespace filed from the host PCIe frame” [0090]) – As taught in Cosby, a namespace abstraction module 32 translates the host namespace from the received command into a disk namespace included within the disk command.--
convert the storage access command's logical block addresses (LBAs) from virtual to physical LBAs (Cosby, “the host LBA range in the host command may also be used to identify one or more specific LBA on the identified disk namespace” [0023] // Fig. 1B) – As previously discussed (see Claim 1 limitation mappings above), an LBA abstraction module 36 translates a host LBA from the received host command into a disk LBA. Examiner considers the process of translating a host LBA into a disk LBA as “convert[ing]” an address “from virtual to physical LBAs”--
and/or modify data integrity protection information.
Regarding Claim 8,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 8. The combined teachings of Li and Cosby disclose the following limitations:
The apparatus of claim 1, wherein the modify the storage access command comprises one or more of: (see MPEP 2143.03)
perform erasure coding on the storage access command and/or associated data,
compute Secure Hash Algorithm (SHA) on data associated with the storage access command,
generate multiple storage access commands from the storage access command, (Cosby, Fig. 5 // “FIG. 5 s a diagram illustrating that a single host data storage command 70 may be translated into multiple disk data storage commands 72, 74, 76. The format of the command, such as a PCIe frame, remains the same for the host data storage command and the disk data storage commands, but the content of the namespace field, memory pointer field, and LBA range field will be modified specifically for each disk data storage command” [0097]) – As taught in Cosby, a host command can be translated into at least three distinct disk access commands.--
combine the storage access command with at least one other storage access command,
cause migration of data associated with the storage access command to another storage device,
redirect the storage access command to another target storage device,
or
correct data stored in a target storage device based on erasure coding.
Regarding Claim 9,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 9. The combined teachings of Li and Cosby disclose the following limitations:
The apparatus of claim 1, wherein the target storage associated with the storage access command is connected to the network interface device through a device interface (Li, Figs. 19B + 20 // “FIG. 20 depicts a process to perform hint processing and translate hints into an RDMA QP for a target node access. The process can be performed by a redirector and/or initiator.” [0140]) – As taught in Li ¶0140 and shown in Fig. 19B, NVMe-oF initiator 1952 performs the method of Fig. 20 including sending the NVMe-oF command to the corresponding device. Examiner accordingly considers the NVMe-oF initiator 1952 as “a device interface” through which the target storage is connected to the NIC 1950.
or (see MPEP 2143.03)
accessible to the network interface device through a server.
Regarding Claim 10,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 10. The combined teachings of Li and Cosby disclose the following limitations:
The apparatus of claim 1, wherein the network interface device comprises one or more of: (see MPEP 2143.03)
a network interface controller (NIC) (Li, NIC 1950, Fig. 19B),
a remote direct memory access (RDMA)- enabled NIC, SmartNIC, router, switch,
forwarding element, infrastructure processing unit (IPU), data processing unit (DPU), or network-attached appliance or smart end point.
Regarding Claim 11,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 11. The combined teachings of Li and Cosby disclose the following limitations:
The apparatus of claim 1, comprising a server (Li, ¶0035) coupled to the network interface device, wherein the server is to cause the network interface device to perform an offloaded operation to determine the processing for the storage command (Li, “Storage servers can benefit from a NIC offload technique” [0035]) – As clarified in Li ¶0035, servers offload the process of Fig. 20 to NIC 1950 to shield the servers from frequently forwarded IOs.
Regarding Claim 12,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 12. The combined teachings of Li and Cosby disclose the following limitations:
The apparatus of claim 11, comprising a data center (Li, ¶0140) comprising a second server (Li, Host OS 1930, Fig. 19B) to transmit at least one packet (Li, Fig. 23) that comprises the storage access command to the network interface device (Li, “an application executing on a host … issues an NVMe command (CMD) to a network interface” [0144] // Fig. 23 // ¶0164) – As taught in Li ¶0140 and 0144, storage access commands are received from a host operating within a data center (i.e., at least “a data center comprising a second server”). As clarified in Li Fig. 23 // ¶0164, data is exchanged between devices of the data center in the form of packets.
Regarding Claim 13,
Li discloses the following limitations:
At least one non-transitory computer readable medium comprising instructions stored thereon (¶0171), that if executed by one or more processors (¶0173), cause the one or more processors to:
execute an operating system (OS) (OS 2232, Fig. 22 // ¶0153) to enable or disable a network interface device (NIC 1950, Fig. 19B) to select a manner of processing a received storage access command (Fig. 20, steps 2016 - 2020)(“an application executing on the host … issues an NVMe command (CMD) to a network interface … The NSID and the LBA number are used in 2014 for a lookup in the hint lookup table to find a QP identifier based on NSID. At 2016, a determination is made if a lookup hit is found. If a lookup hit is found, then the process continues to 2018, where the looked-up RDMA QP number from a lookup entry is used to perform the CMD. If a lookup hit is not found, at 2020, a default QP number is used” [0144] // ¶0140) – As shown in Figs. 19B + 20, NVMe-oF initiator 1952 performs the method of Fig. 20 whereby, during steps 2016-2020, either a default or an identified QP number is used to process a received NVMe command CMD (i.e., “select a manner of processing” a received NVMe command using either a default or an identified QP number)--,
wherein: to process the received storage access command, the network interface device is to process the storage access command in the network interface device, (“FIG. 20 depicts a process to perform hint processing and translate hints into an RDMA QP for a target node access. The process can be performed by a redirector and/or initiator.” [0140]) – As taught in ¶0140, the method of Fig. 20 is performed by an NVMe-oF initiator 1952 located within the NIC 1950--
the network interface device is to select (Fig. 20, step 2016) processing of the received storage access command (“At 2016, a determination is made if a lookup hit is found” [0144])
based at least on command type,: (“Read/Write” [0127])
a connection queue pair, (“a QP identifier” [0144])
namespace identifier (NSID) based on Non-Volatile Memory Express (NVMe), (“the namespace ID (NSID)” [0144])
logical block address (LBA) start, (“an LBA” [0144]) and
number of logical blocks, (“Length” [0127]) (“The CMD specifies the namespace ID (NSID) and an LBA. The NSID and the LBA number are used 2014 for a lookup in the hint lookup table to find a QP identifier based on the NSID … At 2022, the NIC can send an NVMe-oF command to a device associated with an identified RDMA QP number.” [0144-145] // “A simple hint includes fields [Start LBA, Length, Read/Write, Target Extent List]” [0127]) – The NIC uses a hint derived using information from the received command to identify a QP identifier to use as the destination for the received command. The NSID and an LBA received with the command are used to perform a lookup in a hint lookup table to determine the QP identifier to use. The type of command (Read/Write) and the length of the command are fields of the hint.--
based on a first configuration (¶0144) based on the command type, connection queue pair, NSID, LBA start, and number of logical blocks, the network interface device processes the storage access command by modifying … the received storage access command (“an NVMe command” [0144]) and providing a modified storage access command (“an NVMe-oF command” [0145]) and associated data for submission to a target storage (“a device” [0145]) associated with the storage access command. (“an application … issues an NVMe command (CMD) to a network interface … At 2022, the NIC sends an NVMe-oF command to a device associated with an identified RDMA QP number” [0144-145] // Fig. 20) – As discussed above, each of access type, QP number, NSID, LBA, and length inform how the received NMVe command is processed by the NIC. Certain commands (i.e., “a first configuration” of commands) have an associated hint available in the hint lookup table (step 2018), whereas other commands have no such hint (step 2020). When a hint is available, the “NVMe command” issued by the host (see ¶0144) is subsequently sent, as an “NVMe-oF command” (i.e., “a modified storage access command”) to the target device identified by the QP number. Examiner accordingly considers steps 2010-2022 depicted in Fig. 20 as a method whereby a received “NVMe command” is “modified” into a resulting “NVMe-oF command”.
Li does not provide explicit detail regarding modifying an address within an NVMe command as part of conversion into an NVMe-oF command and accordingly does not disclose the following limitations:
modifying an address in the received storage access command
However, Cosby discloses the following limitations:
modifying an address (“host LBA” [0032]) in the received storage access command (Figs. 1A + 1B // “When the host server 14 generates an I/O (read or write) transaction (host command) for one of the host namespaces 22, 24, the abstraction service 30 translates the host command into one or more disk commands for one or more NVMe drive 12 … an LBA abstraction module 36 inspects the LBA field of the host PCIe frame (host command) 28. Collectively, the modules 32, 34, 36 that form the abstraction service 30 generate a disk command to one or more of the NVMe drives” [0089-90] // “The host LBA range in the host command may also be used to identify one or more specific LBA on the identified disk namespace” [0032]) – Examiner considers Host Server 14, Abstraction Service 30, and NVMe drives 12 depicted in Cosby Fig. 1A as analogous to the Host OS 1930, NIC 1950, and Storage Nodes 1972, respectively, depicted in Li Fig. 19B. Similar to NIC 1950 of Li, Abstraction Service 30 of Cosby receives a host command and translates the host command into a disk command submitted to NVMe drives. As shown in Fig. 1B and clarified in ¶0032, translating a host command into a disk command includes translating a host LBA (i.e., “modifying an address”) included within the host command into a disk LBA which is included within the translated command.
Li and Cosby are considered analogous to the claimed invention because they all relate to the same field of translating host storage access commands into NVMe commands submitted to a storage drive. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Li with the teachings of Cosby and realize an apparatus whereby an address within a storage access command is modified to generate a modified storage access command. Using an external device such as an abstraction service to modify a host command address saves processing resources for the host by offloading management of discrete physical NMVe drives away from the host, as taught in Cosby ¶0027: “Embodiments may relieve the host computer from the complexity of separately managing each discrete physical NVMe drive.” [0027]
Regarding Claim 14,
The same motivation to combine provided in Claim 13 is equally applicable to Claim 14. The combined teachings of Li and Cosby disclose the following limitations:
The computer readable medium of claim 13, wherein the command type comprises a read or write command (Li, “Read/Write” [0127])
Regarding Claim 18,
The same motivation to combine provided in Claim 13 is equally applicable to Claim 18. The combined teachings of Li and Cosby disclose the following limitations:
The computer readable medium of claim 18, wherein the modify the storage access command comprises provide the modified storage access command and associated data for submission through a device interface (Li, NVMe-oF Initiator 1952, Fig. 19B) to the target storage associated with the command (Li, “the NIC can send an NVMe-oF command to a device associated with an identified RDMA QP number” [0145]) – As previously discussed and as shown in Li Fig. 19B, NVMe-oF initiator sends the NVMe-oF command to a device associated with the identified QP number.--
or (see MPEP 2143.03)
cause transmission of the modified command in one or more packets.
Regarding Claim 19,
The same motivation to combine provided in Claim 13 is equally applicable to Claim 19. The combined teachings of Li and Cosby disclose the following limitations:
The computer readable medium of claim 18, wherein the modify the storage access command comprises two or more of (see MPEP 2143.03):
modify a received storage device identifier,
modify a queue pair identifier,
modify a namespace identifier, (Cosby, “the host namespace in a host command may be uniquely associated with a specific set (sequence) of disk namespaces” [0022] // “A namespace abstraction module 32 inspects the namespace filed from the host PCIe frame” [0090]) – As taught in Cosby, a namespace abstraction module 32 translates the host namespace from the received command into a disk namespace included within the disk command.--
convert the storage access command's logical block addresses (LBAs) from virtual to physical LBAs -- (Cosby, “the host LBA range in the host command may also be used to identify one or more specific LBA on the identified disk namespace” [0023] // Fig. 1B) – As previously discussed (see Claim 1 limitation mappings above), an LBA abstraction module 36 translates a host LBA from the received host command into a disk LBA. Examiner considers the process of translating a host LBA into a disk LBA as “convert[ing]” an address “from virtual to physical LBAs”--
and/or modify data integrity protection information.
Regarding Claim 20,
The same motivation to combine provided in Claim 13 is equally applicable to Claim 20. The combined teachings of Li and Cosby disclose the following limitations:
The computer readable medium of claim 13, wherein the modify the storage access command comprises three or more of: (see MPEP 2143.03)
perform erasure coding on the storage access command and/or associated data,
compute Secure Hash Algorithm (SHA) on data associated with the storage access command, (Li, “RDMA QP lookup can include the use of hash engine 1954 … Hash engine 1954 can receive an input … and generate a hash_value … The system can use a lookup table with input of hash_value % lookup_table_size and output of RDMA QP #” [0138]) – As taught in Li, during lookup of the hint lookup table, a hash is calculated in order to perform a lookup of the QP number which should be used to process the command--
generate multiple storage access commands from the storage access command, (Cosby, Fig. 5 // “FIG. 5 s a diagram illustrating that a single host data storage command 70 may be translated into multiple disk data storage commands 72, 74, 76. The format of the command, such as a PCIe frame, remains the same for the host data storage command and the disk data storage commands, but the content of the namespace field, memory pointer field, and LBA range field will be modified specifically for each disk data storage command” [0097]) – As taught in Cosby, a host command can be translated into at least three distinct disk access commands.--
combine the storage access command with at least one other storage access command,
cause migration of data associated with the storage access command to another storage device,
redirect the storage access command to another target storage device, (Li, Fig. 19B // “If there is no match, a default RDMA QP (e.g., a default storage node) is used to send the NVMe-oF command … If the LBA is not in the range of the target storage node 1972-1, the target storage node 1972-1 forwards the IO command to the next best target node” [0124]) – As taught in Li, when a default QP is used to process the command, the NVMe-oF command is redirected to a node which should process the command.--
or
correct data stored in a target storage device based on erasure coding.
Claims 4 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Li further in view of Cosby and Cheng et al. (US 20220253238 A1)(hereafter referred to as Cheng).
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Li and Cosby disclose the following limitations:
The apparatus of claim 1 (see Claim 1 limitation mappings above), wherein: based on a second configuration (Li, ¶0144) that is based on the type of storage access command, connection queue pair, NSID, LBA start, and number of logical blocks, (Li; see Claim 1 limitation mappings above) – As previously discussed (see Claim 1 limitation mappings above) and as taught in Li, certain commands have an associated hint available in the hint lookup table (step 2018), whereas other commands (i.e., “a second configuration”) have no such hint (step 2020). Each of command type, QP number, NSID, and an LBA inform how the command is processed by the NIC.
The combined teachings of Li and Cosby do not explicitly disclose the following limitations:
the circuitry is to provide an unmodified version of the storage access command and associated data for submission to the target storage associated with the storage access command.
However, Cheng discloses the following limitations:
the circuitry (NIC 13, Fig. 1) is to provide an unmodified version of the storage access command and associated data for submission to the target storage associated with the storage access command. (Fig. 2, steps S208-209 // “S208: The NIC receives a data read request sent by the client, where the data read request includes information about to-be-read data and an SSD read command, and the information about the to-be-read data includes a namespace (NS) in which to-be-read data is located, a logical block address (LBA), and a length of the to-be-read data. S209: The NIC writes a disk read command to the NVMe I/O queue of the SSD based on the queue information of the NVMe I/O queue, where the disk read command carries the SSD read command and the information about the to-be read data, and the NIC notifies the SSD of the to-be-processed disk read command in the NVMe I/O queue.” [0058-59]) – Examiner considers NIC 13 depicted in Cheng Fig. 1 as analogous to NIC 1950 depicted in Cosby Fig. 19B. As taught in Cheng, information about “to-be-read data”, including an LBA, which is received in a data read request is carried over into a disk read command. A disk read command which includes a carried-over LBA from a data read request contrasts from the embodiment depicted in Cosby Fig. 1B, whereby a host LBA is first translated into a disk LBA. Accordingly, a NIC which generates a disk read command including a carried-over LBA reads on the claimed concept of “an unmodified version of the storage access command”.
Li, Cosby, and Cheng are considered analogous to the claimed invention because they all relate to the same field of . Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Li and Cosby with the teachings of Cheng and realize an apparatus whereby a NIC passes an unmodified version of a storage command to target storage. Doing so is a feature of an improved NIC which reduces memory and bandwidth consumption by bypassing a CPU and corresponding memory for processing a data access request, as taught in Cheng ¶0012: “According to the method for accessing a solid state disk provided in this implementation, because the NIC writes the to-be-written data to the memory of the NIC … and finally, the SSD writes the to-be-written data to the SSD from the memory of the NIC, the data does not pass through a CPU and its memory, and data writing may be completed by using only one DMA. Therefore, memory consumption and memory bandwidth consumption are avoided” [0012]
Regarding Claim 16,
The same motivation to combine provided in Claim 13 is equally applicable to Claim 16. The combined teachings of Li and Cosby disclose the following limitations:
The computer readable medium of claim 13 (see Claim 13 limitation mappings above), wherein: based on a second configuration (Li, ¶0144) that is based on the type of the storage access command, connection queue pair, NSID, LBA start, and number of logical blocks, (Li; see Claim 13 limitation mappings above) – As previously discussed (see Claim 13 limitation mappings above) and as taught in Li, certain commands have an associated hint available in the hint lookup table (step 2018), whereas other commands (i.e., “a second configuration”) have no such hint (step 2020). Each of command type, QP number, NSID, and an LBA inform how the command is processed by the NIC.
The combined teachings of Li and Cosby do not explicitly disclose the following limitations:
the network interface device is to provide an unmodified version of the storage access command and associated data for submission to the target storage associated with the storage access command.
However, Cheng discloses the following limitations:
the network interface device (NIC 13, Fig. 1) is to provide an unmodified version of the storage access command and associated data for submission to the target storage associated with the storage access command. (Fig. 2, steps S208-209 // “S208: The NIC receives a data read request sent by the client, where the data read request includes information about to-be-read data and an SSD read command, and the information about the to-be-read data includes a namespace (NS) in which to-be-read data is located, a logical block address (LBA), and a length of the to-be-read data. S209: The NIC writes a disk read command to the NVMe I/O queue of the SSD based on the queue information of the NVMe I/O queue, where the disk read command carries the SSD read command and the information about the to-be read data, and the NIC notifies the SSD of the to-be-processed disk read command in the NVMe I/O queue.” [0058-59]) – Examiner considers NIC 13 depicted in Cheng Fig. 1 as analogous to NIC 1950 depicted in Cosby Fig. 19B. As taught in Cheng, information about “to-be-read data”, including an LBA, which is received in a data read request is carried over into a disk read command. A disk read command which includes a carried-over LBA from a data read request contrasts from the embodiment depicted in Cosby Fig. 1B, whereby a host LBA is first translated into a disk LBA. Accordingly, a NIC which generates a disk read command including a carried-over LBA reads on the claimed concept of “an unmodified version of the storage access command”.
Li, Cosby, and Cheng are considered analogous to the claimed invention because they all relate to the same field of . Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Li and Cosby with the teachings of Cheng and realize an apparatus whereby a NIC passes an unmodified version of a storage command to target storage. Doing so is a feature of an improved NIC which reduces memory and bandwidth consumption by bypassing a CPU and corresponding memory for processing a data access request, as taught in Cheng ¶0012: “According to the method for accessing a solid state disk provided in this implementation, because the NIC writes the to-be-written data to the memory of the NIC … and finally, the SSD writes the to-be-written data to the SSD from the memory of the NIC, the data does not pass through a CPU and its memory, and data writing may be completed by using only one DMA. Therefore, memory consumption and memory bandwidth consumption are avoided” [0012]
Response to Arguments
The previous Objection to Claim 13 is withdrawn.
The previous 35 U.S.C. 112(b) rejections of Claims 1-2, 4, 6-14, 16, and 18-20 are withdrawn in view of the instant amendments.
Applicant’s arguments with respect to claims 1-2, 4, 6-14, 16, and 18-20 have been considered but are moot in view of the newly-applied Li reference and the newly-identified Cheng reference 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.
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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Veal et al. (US 20190050341 A1)—Discloses a NIC device which translates a host address into an MMIO address while processing commands (see Fig. 9 // ¶0043)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rocío del Mar Pérez-Vélez can be reached on (571)270-5935. 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.
/J.S.M./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights