DETAILED ACTION
This Action is responsive to the RCE filed 01/05/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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/05/2026 has been entered.
Claim Status
Claims 1-2, 4-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 Objections
Claim 13 is objected to because of the following informalities:
Claim 13 distinguishes the concept of a “received storage access command” (line 5) from a “modified storage access command” (line 18). In order to improve the clarity of the claim by maintaining consistent nomenclature throughout the claim set, examiner recommends applicant amend instances of “the storage access command” recited in Claim 13 (e.g., lines 17-20) instead to read “the received storage access command”.
Appropriate correction is required.
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-2, 4, 6-14, 16, and 18-20 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.
Regarding Claim 1,
Claim 1 recites “the modified storage access command” in the 16th line without providing proper antecedent basis. Therefore, the scope of Claim 1 is indefinite, and the claim is rejected under 35 U.S.C. 112(b). Examiner recommends applicant amend Claim 1 instead to read “a modified storage access command” in order to overcome this rejection.
Claim 13 recites substantially similar language as Claim 1 and is therefore similarly rejected under 35 U.S.C. 112(b) according to the same rationale.
Claims 2, 4, 6-12, 14, 16, and 18-20 are similarly rejected due to their respective dependencies.
Regarding Claim 7,
Claim 7 recites “the command’s” in the 3rd line, the scope of which cannot be determined due to numerous reasonable interpretations. In particular, examiner cannot determine whether the aforementioned “the command’s” refers to “the storage access command” or “the modified storage access command” recited in Claims 6 and 1. Therefore, the claim is indefinite and Claim 7 is rejected under 35 U.S.C. 112(b). For the purposes of prior art, examiner will interpret “the command’s” as recited in Claim 7 as referencing “the storage access command” of Claim 6.
Claim 19 recites substantially similar language as Claim 7 and is therefore similarly rejected under 35 U.S.C. 112(b) according to the same rationale.
Regarding Claims 16 and 18-20,
Claims 16 and 18-20 each recite instances of “the storage access command”, the scope of which cannot be determined due to numerous reasonable interpretations. In particular, examiner cannot determine whether claimed “the storage access command” corresponds to “the received storage access command” recited in Claim 13, line 5; or to “the modified storage access command” recited in Claim 13, line 18. Therefore, the claims are indefinite and Claims 16 and 18-20 are rejected under 35 U.S.C. 112(b). For the purposes of prior art, examiner will interpret instances of “the storage access command” recited in Claims 16 and 18-20 as referencing “the received storage access command” recited in Claim 13.
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, 4, 6-14, 16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kakaiya et al. (US 20180321985 A1)(cited by examiner in previous action)(hereafter referred to as Kakaiya) further in view of Li et al. (US 20200136996 A1)(hereafter referred to as Li)
Regarding Claim 1,
Kakaiya discloses the following limitations:
An apparatus (Fig. 4) comprising:
a network interface device (Electronic Device 275, Fig. 4) comprising:
a host interface (VMM 212A, Fig. 4 // ¶0077) – As shown in Fig. 4 and described in ¶0077, a VMM 212A enables a host of Electronic Device 275 to intercept certain operations originating from a guest. Examiner accordingly considers VMM 212A as “a host interface”--;
a network interface (Fig. 4 // an “Assignable Interface” (or “AI”) [0056] // ¶0121) – As shown in Fig. 4, electronic device 275 includes several “Assignable Interface(s)” (“AI”) which enable communication between electronic device 275 and backend resources. Examiner accordingly considers an Assignable Interface, as shown in Fig. 4, as reading on the claimed concept of “a network interface”);
direct memory access (DMA) circuitry (“DMA Remapping hardware” [0108]); and
circuitry (“one or more processors” [0137]) to;
receive (Fig. 7, step 715) a storage access command – (Fig. 4 // ¶¶0075-77 // “Flow 700 also includes … intercepting a request from the guest pertaining to the virtual device” [0130]) -- As shown in Fig. 4 and described in ¶¶0075-77, a guest accesses backend storage resources either directly via a “fast-path” operation 230; or indirectly (e.g., via a hypervisor VMM 212) via a “slow-path” operation 232. As shown in Fig. 7, during step 715, an access request from a guest is intercepted. --
and
process the storage access command (Fig. 7, step 720)(“at decision block 720, determining whether the request from the guest is a fast-path 750 operation … to be passed directly to one or more AI instances of the I/O device, or a slow-path 755 operation .. to be at least partially serviced via software executed by the electronic device” [0130] // “the Scalable IOV architecture 150 partitions its MMIO registers into two categories – (1) MMIO registers accessed frequently and utilized for fast-path operations (e.g., work submission, work completion), and (2) MMIO registers accessed infrequently for slow control and configuration/administrative path operations. This hybrid approach … allows the system software to dynamically categorize which MMIO register regions belong to fast-path, and which ones belong to slow-path … system software backs (i.e., creates second level address translation for) fast-path registers, which allow a direct communication 230 from the guest to hardware without an involvement of a VMM … Slow-path registers, in some embodiments, are not mapped in the second level address translation, thereby allowing trap and emulation by the host 202 software, e.g., slow path host-intercepted operations 232” [0075-77]) – As shown in Fig. 7, during step 720, electronic device 275 determines whether the intercepted command should be processed according to a “fast-path” or according to a “slow-path”. Examiner accordingly considers a determination of whether an intercepted request from a guest is fast-path or slow-path as reading on the claimed concept of “process[ing] the storage access command”--
based on a type of the storage access command (“the type of access” [0077] // “Depending on the type of access and resources accessed, the VDCM may virtualize these accesses entirely in software or proxy them to the host driver 206. In some embodiments, if there are VDEV 220 registers that are read frequently by a guest driver 210 (and have no read side-effects) yet require VDCM 208 intercept on write accesses, such registers may be mapped by the VMM 212 as read only … This can enable the VDEV 220 … to support high-performance read accesses to such virtual registers (e.g., via direct memory access by guest 204), and yet, properly virtualize … guest 204 write accesses to them” [0077-78]) – As disclosed in ¶¶0077-78, whether an intercepted request is a read request or a write request impacts whether the request is processed via “direct memory access by guest 204” (i.e., using the fast-path) or indirectly via a VMM (i.e., using the slow-path)--,
… wherein:
based on a first configuration (“slow-path” [0077]) that is based on the type of storage access command (¶¶0077-78 // Fig. 7) – As previously discussed (see above), an intercepted request can be processed according to either a “fast-path” or a “slow-path” manner of processing based on command type. In this context, examiner considers a “slow-path” manner of processing as “a first configuration” for processing storage access commands--, …
the circuitry is to modify the storage access command (“forcing a VM Exit … The VMM 212 can emulate the guest 204 instruction access that caused a VM Exit, and can forward information of such guest 204 accesses (which can include the VDEV register address accessed, an indicator of whether the access is a read or write, the width of access…) to the VDCM 208.” [0077]) – As detailed in ¶0077, slow-path operations cause a VM Exit whereby a VMM 212 emulates the slow-path instruction and forwards the emulated information (e.g., including the register address accessed by the slow-path operation) to a VDCM 208. Examiner considers emulating an instruction which causes a VM Exit as at least “modify[ing] the storage access command”--
and provide (Fig. 7, step 725) the modified command and associated data for submission to a target storage (Scalable IOV Device 150, Fig. 4 // “storage command queues” [0053]) associated with the storage access command (“the VDCM 208 may virtualize these accesses entirely in software, or proxy them to the host driver 206” [0077] // Fig. 4 // Fig. 2) – As detailed in ¶0077 and shown in Figs. 2 + 4, emulated slow-path operations are submitted to MMIO registers on Device 150 via a host driver 206.—
Kakaiya does not provide specific detail regarding how parameters including connection queue pair, NSID, LBA start, and number of logical blocks inform by which configuration a storage access command should be processed and therefore does not explicitly disclose the following limitations:
process the storage access command based on a type of the storage access command a connection queue pair, namespace identifier (NSID) based on Non- Volatile Memory Express (NVMe), logical block address (LBA) start, and number of logical blocks, …
a first configuration that is based on the type of storage access command, connection queue pair, NSID, LBA start, and number of logical blocks,
However, Li clarifies within the context of processing NVMe storage commands that each of storage access command parameters including NSID, queue pair (QP), and Start/End LBA are used to generate hints which inform how a command should be processed. Specifically, Li discloses the following limitations:
process (Fig. 20, steps 2012-2016) the storage access command based on a type of the storage access command (“Read/Write” [0127]), a connection queue pair (“QP identifier” [0144]), namespace identifier (NSID) based on Non- Volatile Memory Express (NVMe) (“NSID” [0144]), logical block address (LBA) start (“Start LBA” [0127]), and number of logical blocks (“Length” [0127])(“at 2010, an application … issues an NVMe command (CMD) to a network interface. At 2012, an NVMe-oF initiator processes the CMD. The CMD specifies the namespace ID (NSID) and an LBA. 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 the NSID … After a QP number is identified … the NIC can send an NVMe-oF command to a device associated with an identified RDMA QP number” [0144] // “A simple hint is used for a small namespace an a small number of QPs. A simple hint includes fields [Start LBA, Length, Read/Write, Target Extent List]” [0127]) – As shown in Li Figs. 19B + 20, a NIC 1950 directs storage access commands to a target using either a default or a particular queue pair identifier based on a hint derived from the storage access command, similar to how electronic device 275 of Kakaiya Fig. 4 directs storage access commands to a target using either a slow path or a fast path method of processing. Examiner accordingly considers NIC 1950 of Li Fig. 19B as analogous to the claimed network interface device. As taught in Li, after receiving an NVMe storage access command from a host (Fig. 20, step 2010), NIC 1950 performs a lookup (Fig. 20, step 2014) using the “NSID” of the received command in order to derive a hint for processing the command. A “simple” type of hint includes parameters including “Start LBA, Length, Read/Write” (i.e., “logical block address (LBA) start”, “number of logical blocks”, and “type of the storage access command”, respectively). The hint lookup results in an “RDMA QP number” (i.e., “a connection queue pair” identifier) which is used by the NIC to send the received command to the appropriate target (Fig. 20, step 2022).--
a first configuration (Fig. 20, step 2018) that is based on the type of storage access command, connection queue pair, NSID, LBA start, and number of logical blocks (“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.” [0144]) – As shown in Fig. 20, certain hint lookups result in a hit, whereby an RMDA number received from a lookup entry (as opposed to a default QP number; see step 2020) is used to direct the command to the target. In the context of Li Fig. 20, examiner considers the storage access command processing method whereby a looked-up RDMA QP number is used forward the command to a target as “a first configuration” of processing storage access commands.--
Kakaiya and Li are considered analogous to the claimed invention because they all relate to the same field of processing and forwarding host storage access commands to appropriate storage targets in a NVMe environment using RDMA. 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 Kakaiya with the teachings of Li and realize a network interface device which uses each of type of storage access command, connection queue pair, NSID, LBA start, and a number of LBAs associated with a received storage access command to inform how to process the received storage access command. Using such parameters as hints for storage access command processing allows for flexible mapping of LBAs to one or more storage nodes connected to a host through a fabric, improving a NIC’s ability to support NVMe-oF storage services, as disclosed in Li ¶0114: “The hints allow flexible mapping of logical block address (LB A) to one or more storage nodes connected to host 1800 through a connection such as a fabric, network, interconnect or bus. For example, simple hints, striping hints, or hashing hints (described herein) can be supported. Hints can enable a NIC to support NVMe-oF storage services ranging from pair-wise High Availability (HA) to massive scale-out.” [0114]
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Kakaiya and Li 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 (Kakaiya “read accesses” [0078]) or write command (Kakaiya, “write accesses” [0078]) – As detailed in ¶0078, certain read accesses to virtual registers are fast-path whereas write accesses to the same virtual registers are slow-path. See also Li ¶0127 as discussed above with respect to Claim 1.
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Kakaiya and Li disclose the following limitations:
The apparatus of claim 1 (see Claim 1 limitation mappings above), wherein
based on a second configuration (Kakaiya, “fast-path” [0076]) that is based on the type of storage access command, connection queue pair, NSID, LBA start, and number of logical blocks (Li, Fig. 20 // ¶¶0127; 0144) – As previously discussed and as taught in Kakaiya, received storage access commands can be processed according to a “fast-path” (i.e., “a second configuration”) distinct from the “slow-path” method of processing. As previously discussed and as taught in Li, parameters including type of command, queue pair, NSID, LBA start, and number of LBAs inform how received commands are processed--,
the circuitry is to provide an unmodified version of the storage access command and associated data for submission to a target storage (Kakaiya Scalable IOV Device 150, Fig. 4 // “storage command queues” [0053]) associated with the command (Kakaiya Fig. 7, block 730 // “Optionally, responsive to determining that the request is a fast-path 750 operation, at block 730 the flow 700 includes servicing by passing the request to the I/O device directly from the guest instead of servicing the request at least partially via the software executed by the electronic device” [0132] // ¶0079) – As clarified in Kakaiya ¶0132, fast-path requests are passed “directly” to I/O devices “instead of” slow-path requests which are first processed via “software executed by the electronic device”. Accordingly, examiner considers passing a request “directly” to an I/O device using a “fast-path”, as disclosed in Kakaiya, as “provid[ing] an unmodified version of the storage access command”, along with associated data, to “a target storage” which is “associated with” (e.g., via the determination made during Kakaiya Fig. 7, step 720; see also Claim 1 limitation mappings above) the command.
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Kakaiya and Li 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 (Kakaiya, “MMIO registers in hardware” [0079]) to the target storage (Kakaiya, Scalable IOV Device 150, Fig. 4 // “storage command queues” [0053]) associated with the command (Kakaiya, “the VDCM 208 may virtualize these accesses entirely in software, or proxy them to the host driver 206” [0077] // Fig. 4 // Fig. 2) – As detailed in Kakaiya ¶0077 and shown in Figs. 2 + 4, emulated slow-path operations are submitted to MMIO registers on Device 150 via a host driver 206.--
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 Kakaiya and Li disclose the following limitations:
The apparatus of claim 6, wherein the modify the storage access command comprises one or more of (see MPEP 2143.03):
modify a received storage device identifier,
modify a queue pair identifier (Li, Fig. 20, step 2018 // “If a lookup hint 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 hint is not found, at 2020, a default QP number is used” [0144]) – As taught in Li, a looked up QP identifier is used (instead of a default QP identifier) to forward the storage access command to the target--,
modify a namespace identifier,
convert the command's logical block addresses (LBAs) from virtual to physical LBAs (Kakaiya, “The VMM 212 can emulate the guest 204 instruction access that caused such a VM Exit, and can forward information … which can include the VDEV register address accessed … to the VDCM 208 … the VDCM 208 may virtualize these accesses entirely in software” [0077] // “Virtualization software … can be setup with appropriate second-level translation (e.g., GPA-to-HPA)” [0108]) – As previously discussed (see Claim 6 limitation mappings above), slow-path operations are intercepted by a VMM 212 and are forwarded to a VDCM for “second-level translation” of a GPA to an HPA. Examiner considers conversion of a GPA to an HPA as part of software virtualization of a slow-path command as reading on the claimed concept of “convert[ing]” an address “from virtual to physical LBAs”--
and/or modify end-to-end protection information.
Regarding Claim 8,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 8. The combined teachings of Kakaiya and Li 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,
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 (Kakaiya, “forcing a VM Exit … on a guest driver 210 access to such registers. The VMM 212 can emulate the guest 204 instruction that caused such a VM Exit, and forward information of such guest 204 access … to the VDCM 208. Depending on the type of access and resource accessed, the VDCM 208 may virtualize these accesses entirely in software, or proxy them to the host driver 206” [0077] // Fig. 4) – As clarified in ¶0077, slow-path instructions force a VM Exit and are forwarded to a host driver (see also Fig. 4). Examiner considers aforementioned slow-path processing as effectively “redirect[ing] the command” (e.g., from a guest driver to a host driver; i.e., to a different “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 Kakaiya and Li disclose the following limitations:
The apparatus of claim 1, wherein the target storage (Kakaiya, Scalable IOV Device 150, Fig. 4 // “storage command queues” [0053]) associated with the storage access command is connected to the network interface device through a device interface (Kakaiya, “MMIO registers in hardware” [0079] // Fig. 4)
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 Kakaiya and Li 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 (Kakaiya, VMM 212A, Fig. 4 // “The VMM 212 can emulate the guest 204 instruction access that caused such a VM Exit, and can forward information of such guest 204 accesses … to the VDCM 208” [0077]) – As shown in Fig. 4 and detailed in ¶0077, slow-path instructions are intercepted and forwarded to a host driver by VMM 212A. Examiner accordingly considers VMM 212A as a “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 Kakaiya and Li 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 Kakaiya and Li 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,
Kakaiya discloses the following limitations:
At least one non-transitory computer readable medium comprising instructions stored thereon (¶0137), that if executed by one or more processors (¶0137), cause the one or more processors to:
execute an operating system (OS) (“system software” [0071]) to enable or disable a network interface device (Electronic Device 275, Fig. 4) to select (Fig. 7, step 720) a manner of processing a received storage access command (Fig. 7, step 715) (Fig. 4 // ¶¶0075-77 // “Flow 700 also includes … intercepting a request from the guest pertaining to the virtual device” [0130]) -- As shown in Fig. 4 and described in ¶¶0075-77, a guest accesses backend storage resources either directly via a “fast-path” operation 230; or indirectly (e.g., via a hypervisor VMM 212) via a “slow-path” operation 232. As shown in Fig. 7, during step 715, an access request from a guest is intercepted., 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. 4),
the network interface device is to select (Fig. 7, step 720) processing of the received storage access command (“at decision block 720, determining whether the request from the guest is a fast-path 750 operation … to be passed directly to one or more AI instances of the I/O device, or a slow-path 755 operation .. to be at least partially serviced via software executed by the electronic device” [0130] // “the Scalable IOV architecture 150 partitions its MMIO registers into two categories – (1) MMIO registers accessed frequently and utilized for fast-path operations (e.g., work submission, work completion), and (2) MMIO registers accessed infrequently for slow control and configuration/administrative path operations. This hybrid approach … allows the system software to dynamically categorize which MMIO register regions belong to fast-path, and which ones belong to slow-path … system software backs (i.e., creates second level address translation for) fast-path registers, which allow a direct communication 230 from the guest to hardware without an involvement of a VMM … Slow-path registers, in some embodiments, are not mapped in the second level address translation, thereby allowing trap and emulation by the host 202 software, e.g., slow path host-intercepted operations 232” [0075-77]) – As shown in Fig. 7, during step 720, electronic device 275 determines whether the intercepted command should be processed according to a “fast-path” or according to a “slow-path”. Examiner accordingly considers a determination of whether an intercepted request from a guest is fast-path or slow-path as reading on the claimed concept of “select[ing] processing of the received the storage access command”--
based at least on command type (“the type of access” [0077] // “Depending on the type of access and resources accessed, the VDCM may virtualize these accesses entirely in software or proxy them to the host driver 206. In some embodiments, if there are VDEV 220 registers that are read frequently by a guest driver 210 (and have no read side-effects) yet require VDCM 208 intercept on write accesses, such registers may be mapped by the VMM 212 as read only … This can enable the VDEV 220 … to support high-performance read accesses to such virtual registers (e.g., via direct memory access by guest 204), and yet, properly virtualize … guest 204 write accesses to them” [0077-78]) – As disclosed in ¶¶0077-78, whether an intercepted request is a read request or a write request impacts whether the request is processed via “direct memory access by guest 204” (i.e., using the fast-path) or indirectly via a VMM (i.e., using the slow-path)--,
…
based on a first configuration (“slow-path” [0077]) that is based on the command type (¶¶0077-78 // Fig. 7) – As previously discussed (see above), an intercepted request can be processed according to either a “fast-path” or a “slow-path” manner of processing based on command type. In this context, examiner considers a “slow-path” manner of processing as “a first configuration” for processing storage access commands--, …
the network interface processes the storage access command by modifying the storage access command (“forcing a VM Exit … The VMM 212 can emulate the guest 204 instruction access that caused a VM Exit, and can forward information of such guest 204 accesses (which can include the VDEV register address accessed, an indicator of whether the access is a read or write, the width of access…) to the VDCM 208.” [0077]) – As detailed in ¶0077, slow-path operations cause a VM Exit whereby a VMM 212 emulates the slow-path instruction and forwards the emulated information (e.g., including the register address accessed by the slow-path operation) to a VDCM 208. Examiner considers emulating an instruction which causes a VM Exit as at least “modify[ing] the storage access command”--
and providing (Fig. 7, step 725) the modified command and associated data for submission to a target storage (Scalable IOV Device 150, Fig. 4 // “storage command queues” [0053]) associated with the storage access command (“the VDCM 208 may virtualize these accesses entirely in software, or proxy them to the host driver 206” [0077] // Fig. 4 // Fig. 2) – As detailed in ¶0077 and shown in Figs. 2 + 4, emulated slow-path operations are submitted to MMIO registers on Device 150 via a host driver 206.
Kakaiya does not provide specific detail regarding how parameters including connection queue pair, NSID, LBA start, and number of logical blocks inform by which configuration a storage access command should be processed and therefore does not explicitly disclose the following limitations:
select processing of the received storage access command based at least on command type, a connection queue pair, namespace identifier (NSID) based on Non-Volatile Memory Express (NVMe), logical block address (LBA) start, and number of logical blocks, …
a first configuration based on the command type, connection queue pair, NSID, LBA start, and number of logical blocks
However, Li clarifies within the context of processing NVMe storage commands that each of storage access command parameters including NSID, queue pair (QP), and Start/End LBA are used to generate hints which inform how a command should be processed. Specifically, Li discloses the following limitations:
select processing (Fig. 20, steps 2012-2016) of the received storage access command based on command type (“Read/Write” [0127]), a connection queue pair (“QP identifier” [0144]), namespace identifier (NSID) based on Non- Volatile Memory Express (NVMe) (“NSID” [0144]), logical block address (LBA) start (“Start LBA” [0127]), and number of logical blocks (“Length” [0127])(“at 2010, an application … issues an NVMe command (CMD) to a network interface. At 2012, an NVMe-oF initiator processes the CMD. The CMD specifies the namespace ID (NSID) and an LBA. 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 the NSID … After a QP number is identified … the NIC can send an NVMe-oF command to a device associated with an identified RDMA QP number” [0144] // “A simple hint is used for a small namespace and a small number of QPs. A simple hint includes fields [Start LBA, Length, Read/Write, Target Extent List]” [0127]) – As shown in Li Figs. 19B + 20, a NIC 1950 directs storage access commands to a target using either a default or a particular queue pair identifier based on a hint derived from the storage access command, similar to how electronic device 275 of Kakaiya Fig. 4 directs storage access commands to a target using either a slow path or a fast path method of processing. Examiner accordingly considers NIC 1950 of Li Fig. 19B as analogous to the claimed network interface device. As taught in Li, after receiving an NVMe storage access command from a host (Fig. 20, step 2010), NIC 1950 performs a lookup (Fig. 20, step 2014) using the “NSID” of the received command in order to derive a hint for processing the command. A “simple” type of hint includes parameters including “Start LBA, Length, Read/Write” (i.e., “logical block address (LBA) start”, “number of logical blocks”, and “type of the storage access command”, respectively). The hint lookup results in an “RDMA QP number” (i.e., “a connection queue pair” identifier) which is used by the NIC to send the received command to the appropriate target (Fig. 20, step 2022).--
a first configuration (Fig. 20, step 2018) based on command type, connection queue pair, NSID, LBA start, and number of logical blocks (“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.” [0144]) – As shown in Fig. 20, certain hint lookups result in a hit, whereby an RMDA number received from a lookup entry (as opposed to a default QP number; see step 2020) is used to direct the command to the target. In the context of Li Fig. 20, examiner considers the storage access command processing method whereby a looked-up RDMA QP number is used forward the command to a target as “a first configuration” of processing storage access commands.--
Kakaiya and Li are considered analogous to the claimed invention because they all relate to the same field of processing and forwarding host storage access commands to appropriate storage targets in a NVMe environment using RDMA. 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 Kakaiya with the teachings of Li and realize a network interface device which uses each of type of storage access command, connection queue pair, NSID, LBA start, and a number of LBAs associated with a received storage access command to inform how to process the received storage access command. Using such parameters as hints for storage access command processing allows for flexible mapping of LBAs to one or more storage nodes connected to a host through a fabric, improving a NIC’s ability to support NVMe-oF storage services, as disclosed in Li ¶0114: “The hints allow flexible mapping of logical block address (LB A) to one or more storage nodes connected to host 1800 through a connection such as a fabric, network, interconnect or bus. For example, simple hints, striping hints, or hashing hints (described herein) can be supported. Hints can enable a NIC to support NVMe-oF storage services ranging from pair-wise High Availability (HA) to massive scale-out.” [0114]
Regarding Claim 14,
The same motivation to combine provided in Claim 13 is equally applicable to Claim 14. The combined teachings of Kakaiya and Li disclose the following limitations:
The computer readable medium of claim 13 (see Claim 13 limitation mappings above), wherein the command type comprises a read (“read accesses” [0078]) or write command (“write accesses” [0078]) – As detailed in ¶0078, certain read accesses to virtual registers are fast-path whereas write accesses to the same virtual registers are slow-path. See also Li ¶0127 as discussed above with respect to Claim 13.
Regarding Claim 16,
The same motivation to combine provided in Claim 13 is equally applicable to Claim 16. The combined teachings of Kakaiya and Li disclose the following limitations:
The computer readable medium of claim 13, wherein
based on a second configuration (Kakaiya, “fast-path” [0076]) that is based on the type of storage access command, connection queue pair, NSID, LBA start, and number of logical blocks (Li, Fig. 20 // ¶¶0127; 0144) – As previously discussed and as taught in Kakaiya, received storage access commands can be processed according to a “fast-path” (i.e., “a second configuration”) distinct from the “slow-path” method of processing. As previously discussed and as taught in Li, parameters including type of command, queue pair, NSID, LBA start, and number of LBAs inform how received commands are processed--,
the network interface device is to provide an unmodified version of the storage access command and associated data for submission to a target storage (Kakaiya, Scalable IOV Device 150, Fig. 4 // “storage command queues” [0053]) associated with the command (Kakaiya Fig. 7, block 730 // “Optionally, responsive to determining that the request is a fast-path 750 operation, at block 730 the flow 700 includes servicing by passing the request to the I/O device directly from the guest instead of servicing the request at least partially via the software executed by the electronic device” [0132] // ¶0079) – As clarified in Kakaiya ¶0132, fast-path requests are passed “directly” to I/O devices “instead of” slow-path requests which are first processed via “software executed by the electronic device”. Accordingly, examiner considers passing a request “directly” to an I/O device using a “fast-path”, as disclosed in Kakaiya, as “provid[ing] an unmodified version of the storage access command”, along with associated data, to “a target storage” which is “associated with” (e.g., via the determination made during Kakaiya Fig. 7, step 720; see also Claim 13 limitation mappings above) the command.
Regarding Claim 18,
The same motivation to combine provided in Claim 13 is equally applicable to Claim 18. The combined teachings of Kakaiya and Li 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 (Kakaiya, “MMIO registers in hardware” [0079]) to the target storage (Kakaiya, Scalable IOV Device 150, Fig. 4 // “storage command queues” [0053]) associated with the command (Kakaiya, “the VDCM 208 may virtualize these accesses entirely in software, or proxy them to the host driver 206” [0077] // Fig. 4 // Fig. 2) – As detailed in Kakaiya ¶0077 and shown in Figs. 2 + 4, emulated slow-path operations are submitted to MMIO registers on Device 150 via a host driver 206.--
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 Kakaiya and Li disclose the following limitations:
The computer readable medium of claim 18, wherein the modify the storage access command comprises one or more of (see MPEP 2143.03):
modify a received storage device identifier,
modify a queue pair identifier (Li, Fig. 20, step 2018 // “If a lookup hint 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 hint is not found, at 2020, a default QP number is used” [0144]) – As taught in Li, a looked up QP identifier is used (instead of a default QP identifier) to forward the storage access command to the target--,
modify a namespace identifier,
convert the command's logical block addresses (LBAs) from virtual to physical LBAs (Kakaiya, “The VMM 212 can emulate the guest 204 instruction access that caused such a VM Exit, and can forward information … which can include the VDEV register address accessed … to the VDCM 208 … the VDCM 208 may virtualize these accesses entirely in software” [0077] // “Virtualization software … can be setup with appropriate second-level translation (e.g., GPA-to-HPA)” [0108]) – As previously discussed (see Claim 18 limitation mappings above), slow-path operations are intercepted by a VMM 212 and are forwarded to a VDCM for “second-level translation” of a GPA to an HPA. Examiner considers conversion of a GPA to an HPA as part of software virtualization of a slow-path command as reading on the claimed concept of “convert[ing]” an address “from virtual to physical LBAs”--
and/or modify end-to-end protection information.
Regarding Claim 20,
The same motivation to combine provided in Claim 13 is equally applicable to Claim 19. The combined teachings of Kakaiya and Li disclose the following limitations:
The computer readable medium of claim 13, 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,
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 (Kakaiya, “forcing a VM Exit … on a guest driver 210 access to such registers. The VMM 212 can emulate the guest 204 instruction that caused such a VM Exit, and forward information of such guest 204 access … to the VDCM 208. Depending on the type of access and resource accessed, the VDCM 208 may virtualize these accesses entirely in software, or proxy them to the host driver 206” [0077] // Fig. 4) – As clarified in ¶0077, slow-path instructions force a VM Exit and are forwarded to a host driver (see also Fig. 4). Examiner considers aforementioned slow-path processing as effectively “redirect[ing] the command” (e.g., from a guest driver to a host driver; i.e., to a different “target storage device”)--,
or
correct data stored in a target storage device based on erasure coding.
Response to Arguments
The previous Objection to Claim 1 is withdrawn. However, examiner notes that the instant amendments introduce new Claim Objections. See above for additional details.
With respect to applicant’s arguments located within the final paragraph of the 1st page of Remarks (numbered as page 7) continuing to the 2nd page of remarks (numbered as page 8), which recites:
“The Office Action indicates that Kakaiya discloses a logical block address (LBA) start. (Final Office Action, pages 5-6.) However, Kakaiya fails to disclose a network interface device circuitry modifying a storage access command based on a first configuration that is based on the type of storage access command, connection queue pair, NSID, LBA start, and number of logical blocks. Withdrawal of the rejection of claim 1 is requested for at least this reason. …
Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Kakaiya further in view of Veluswamy et al. (US 20220391333).
Veluswamy fails to cure the deficiency of teachings of Kakaiya with respect to base claim
1. Withdrawal of the rejection of claim 11 and 12 is requested for at least this reason.”
Applicant's arguments filed 01/05/2026 with respect to the prior art rejections of Claims 1-2, 4, 6-14, 16, and 18-20 have been fully considered but are moot in view of the newly-applied Li 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
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