DETAILED ACTION
This Action is responsive to the Application filed on 09/12/2025.
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-20 are presented. Claims 1-20 are pending and have been examined.
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-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 address from the command” in the final line, the scope of which cannot be determined due to numerous reasonable interpretations. Specifically, examiner cannot determine whether the aforementioned address corresponds to:
a) “an address to transfer accumulated data to” recited in Claim 1, 5-6th lines;
b) “a first address” recited in Claim 1, 6th line; or
c) “a second address” recited in Claim 1, 7th line
Therefore, the scope of Claim 1 is indefinite, and the claim is rejected under 35 U.S.C. 112(b). For the purposes of prior art, examiner will interpret Claim 1 according to interpretation a) provided above. If applicant intends to claim such an embodiment, examiner recommends applicant amend Claim 1 to preclude “the address from the command” from reading on either the first address or the second address. See discussion of Claim 17 below.
Claim 12, final line recites substantially similar language as compared to Claim 1 as is rejected under 35 U.S.C. 112(b) according to the same rationale. Claims 2-11 and 13-16 are similarly rejected according to their respective dependencies.
In addition, Claims 6, 11, and 16 each recite instances of “the address” and are accordingly indefinite for the same reasoning provided above with respect to Claim 1. Therefore, Claims 6, 11, and 16 are each rejected under 35 U.S.C. 112(b) according to this rationale.
In addition, Claim 1 recites “the command” in the final line, the scope of which cannot be determined due to numerous reasonable interpretations. Specifically, examiner cannot determined whether the aforementioned command corresponds to:
a) “a command from a requester” recited in Claim 1, 3rd line;
b) “a first read command” recited in Claim 1, 10th line; or
c) “a second read command” recited in Claim 1, 12th line.
Therefore, the scope of Claim 1 is indefinite, and the claim is rejected under 35 U.S.C. 112(b). For the purposes of prior art, examiner will interpret Claim 1 according to interpretation a) provided above. If applicant intends to claim such an embodiment, examiner recommends applicant amend Claim 1 instead to read “the command from the requester” in the final line in order to overcome this rejection.
Claim 12, final line recites substantially similar language as compared to Claim 1 and is therefore rejected under 35 U.S.C. 112(b) according to the same rationale provided above. Claims 2-11 and 13-17 are similarly rejected under 35 U.S.C. 112(b).
In addition, Claims 2-8, 14, and 16 each recite instances of “the command” and are accordingly indefinite for the same reasoning provided above with respect to Claim 1. Therefore, Claims 2-8, 14, and 16 are each rejected under 35 U.S.C. 112(b) according to this rationale.
Regarding Claim 17,
Claim 17 recites “the address” in the final line, the scope of which cannot be determined due to numerous reasonable interpretations. Specifically, examiner cannot determine whether the aforementioned address corresponds to:
a) “an address in host memory” recited in Claim 17, 11th line;
b) “a first address” recited in Claim 17, 8th line; or
c) “a second address” recited in Claim 17, 9th line
Therefore, the scope of Claim 17 is indefinite, and the claim is rejected under 35 U.S.C. 112(b). For the purposes of prior art, examiner will interpret Claim 1 according to interpretation a) provided above. If applicant intends to claim such an embodiment, examiner recommends applicant amend Claim 17, final line instead to read “the address in host memory” in order to overcome this rejection.
Claims 18-20 are similarly rejected under 35 U.S.C. 112(b) according to their respective dependencies.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 4, 6, 8, 10, and 12 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Malwankar et al. (US 20160127468 A1)(hereafter referred to as Malwankar).
Regarding Claim 1,
Malwankar anticipates the following limitations:
A method implemented by a storage accelerator (Storage Controller 108A, Fig. 1 // Storage Controller 250, Fig. 2B // ¶0054) to enable handling of read requests for data having a size smaller than a block (“memory pages” [0059] // ¶0033) – Examiner considers a controller 108 (e.g., 108A) depicted in Fig. 1 as “a storage accelerator”--
the method comprising:
receiving (¶0059), by the storage accelerator(Fig. 2B), a command from a requester (Host Computing Device 104A, Fig. 1 // ¶0028) (“I/O manager 255 is responsible for communicating with host computing devices and satisfying input/output (I/O) commands such as read commands” [0055] // “Responsive to receipt of a read command, the I/O manager 255 invokes read module 257” [0059] // Figs. 1 + 2B) – An I/O manager 255 included within a storage controller 108 invokes a read module 257 in response to receiving a read command from a host computing device (e.g., Host Computing Device 104A of Fig. 1A)--, wherein:
the command identifies multiple addresses to read from (“the command payload of the read command identifies specific logical block addresses of a virtual drive (e.g., a virtual NVMe drive) from which data is to be read” [0059]) – The payload of a read command includes specific logical block addresses of the virtual drives containing data to be read-- and
an address(“a source MAC address” [0056]) to transfer accumulated data to (“Storage controller 250 receives messages 285 from host computing devices. The messages may be, for example, Ethernet packets … The Ethernet packet may include a transport header identifying … a source address (e.g., a source MAC address)” [0055-56] // ¶0048) – The transport header of the received read command includes a source MAC address identifying the MAC address of the requesting host (see also ¶0048)--, and
the multiple addresses include a first address (“first memory pages” [0060]) of a first storage device (SSD 150A, Fig. 1) coupled with the storage accelerator and a second address (“second memory pages” [0060]) of a second storage device (SSD 150B, Fig. 1) coupled with the storage accelerator (“Read module 257 may use a virtual drive map 220 for the virtual drive to determine what locations (e.g., what memory pages) on the physical storage devices (e.g., physical NVMe drives) correspond to the logical block addresses of the virtual drive. Read module 257 may then generate NVMe read commands 275 for each of the storage devices storing data to be read. For example, … read module 257 may determine first memory pages on a first NVMe drive storing requested information, second memory pages on a second NVMe drive storing requested information and third memory pages on a third NVMe drive storing requested information” [0059-60]) – Logical addresses are mapped to corresponding pages in corresponding physical drives. The specific logical block addresses identified by the read command payload correspond to plural memory pages located on plural NVMe drives including a first page on a first drive and a second page on a second drive.--; and
in response to the command: sending (¶0060), to the first storage device, a first read command (“a first NVMe read command” [0060]) to read first data stored at the first address, sending (¶0060), to the second storage device, a second read command (“a second NVMe read command” [0060]) to read second data stored at the second address, (“Read module 257 may then generate a first NVMe command directed to the first memory pages of the first NVMe drive, a second NVMe read command directed to second memory pages of the second NVMe drive, and a third NVMe read command directed to the third memory pages of the third NVMe drive.” [0060]) – The read module generates separate NVMe read commands directed towards the identified pages on the physical drives.--
receiving (¶0061) the first data from the first storage device and the second data from the second storage device, storing (¶0061) the accumulated data in a memory (Data Receive Buffer 222, Fig. 2B) of the storage accelerator, wherein the accumulated data includes the first data and the second data, (“The NVMe drives receive the NVMe read commands and return data stored at indicated memory locations. The returned data is added to a data send buffer 221 by read module 257 until …. all requested data has been received” [0061]) – NVMe drives return requested data to read module 257. Returned data is accumulated in Data Send Buffer 221 until all requested data has been received from the NVMe drives-- and
causing the accumulated data to be transferred to a memory location indicated by the address from the command. (“Once the data send buffer fills, read module 257 may generate a response message 290 (e.g., a new Ethernet packet having the above identified format). Read module may then encapsulate the data from the data send buffer 221 into the response message 290. For example, read module 257 may generate an Ethernet packet with a transport header indicating the MAC address of the requesting storage device … Read module 257 may then send the response message 290 to the host.” [0061]) – The requested data is encapsulated into a response message which is sent to the host using the host MAC address (i.e., “to a memory location indicated by the address from the command”).
Regarding Claim 4,
Malwankar anticipates the following limitations:
The method of claim 1, wherein: the command includes the multiple addresses and drive identifiers (“an identifier (ID) of a virtual drive” [0056]) corresponding to the multiple addresses. (“each of the messages 285 is an Ethernet packet having a particular format and encapsulating an I/O command … a payload of the Ethernet packet may include a protocol header for the I/O command and a particular command payload and/or data payload. The protocol header includes an identifier (ID) of a virtual drive” [0056] // “the command payload of the read command identifies specific logical block addresses of a virtual drive (e.g., a virtual NVMe drive) from which data is to be read” [0059] // ¶0060) – Messages 285 received from the host are formatted according to an Ethernet packet format. The Ethernet packet includes both a protocol header and a command payload. A virtual drive ID is included within the protocol header, whereas LBAs of the virtual drive are included within the command payload.
Regarding Claim 6,
Malwankar anticipates the following limitations:
The method of claim 1, wherein: the command includes the address to transfer the data to. (“Storage controller 250 receives messages 285 from host computing devices. The messages may be, for example, Ethernet packets … The Ethernet packet may include a transport header identifying … a source address (e.g., a source MAC address)” [0055-56] // “read module 257 may generate an Ethernet packet with a transport header indicating the MAC address of the requesting storage device … Read module 257 may then send the response message 290 to the host.” [0061) – As previously discussed, the transport header of the command includes a source MAC address corresponding to the host. The MAC address is used to send the response containing the read data back to the host.
Regarding Claim 8,
Malwankar anticipates the following limitations:
The method of claim 1, wherein: the command identifies: a namespace identifier (“a virtual local area network (VLAN) tag” [0060]), and a drive identifier (“an identifier (ID) of a virtual drive” [0056]) corresponding to each of the multiple addresses. (“each of the messages 285 is an Ethernet packet having a particular format and encapsulating an I/O command. The Ethernet packet may include a transport header identifying … a virtual local area network (VLAN) tag … a payload of the Ethernet packet may include a protocol header for the I/O command and a particular command payload and/or data payload. The protocol header includes an identifier (ID) of a virtual drive” [0056] // “the command payload of the read command identifies specific logical block addresses of a virtual drive (e.g., a virtual NVMe drive) from which data is to be read” [0059] // ¶0060) – Messages 285 received from the host are formatted according to an Ethernet packet format. The Ethernet packet includes a transport header, a protocol header, and a command payload. A transport header of the packet includes a VLAN tag, which examiner considers as reading on the claimed concept of “a namespace identifier.” A virtual drive ID is included within the protocol header, whereas LBAs of the virtual drive are included within the command payload.
Regarding Claim 10,
Malwankar anticipates the following limitations:
The method of claim 1, wherein: the accumulated data has a first size of the block, and the first data has a second size that is smaller than or equal to half the block. (“The returned data is added to a data send buffer 221 by read module 257 until …. all requested data has been received” [0061] // “Memory pages are grouped into blocks … Typical SSDs have blocks that include 256 memory pages” [0033]) – As previously discussed (see Claim 1 limitation mappings above), data read from first – third memory pages are accumulated from first-third SSDs into a send buffer prior to transmission back to the host. As taught in ¶0033, typical SSDs include 256 memory pages per block. Thus, in an embodiments whereby a single page is read from each of three SSDs, “the accumulated data” would have a size of 3 pages = 3/256th of a block (i.e., “a first size of the block”). Additionally, the data read from a first memory page of a first SSD (i.e., “the first data”) would have a size of 1 page = 1/256th of a block (i.e., “a second size that is smaller than” “half the block”).
Regarding Claim 12,
Malwankar anticipates the following limitations:
A non-volatile memory express (NVMe) accelerator (Storage Controller 108A, Fig. 1 // Storage Controller 250, Fig. 2B // ¶0054) comprising:
first input/output (I/O) circuitry (I/O Manager 255, Fig. 2B) to couple with a host (Host Computing Device 104A, Fig. 1)(“I/O manager 255 is responsible for communicating with host computing devices and satisfying input/output (I/O) commands such as read commands” [0055]) An I/O manager 255 included within a storage controller 108 invokes a read module 257 in response to receiving a read command from a host computing device (e.g., Host Computing Device 104A of Fig. 1A)--;
second I/O circuitry (Read Module 257, Fig. 2B) to couple with a plurality of storage devices, the plurality of storage devices including a first storage device (SSD 150A, Fig. 1) and a second storage device (SSD 150B, Fig. 1)(“Read module 257 may then generate NVMe read commands 275 for each of the storage devices … Once an NVMe read command reaches the front of an I/O submission queue 280, read module 257 may then send the generated NVMe read command to the appropriate NVMe drive” [0060]) – A read module 257 sends generated read commands to respective drives (e.g., including SSD 150A and SSD 150B; see Fig. 1);
logic (Storage Controller 250, Fig. 2B) to:
receive (¶0059) a command from the host(“I/O manager 255 is responsible for communicating with host computing devices and satisfying input/output (I/O) commands such as read commands” [0055] // “Responsive to receipt of a read command, the I/O manager 255 invokes read module 257” [0059] // Figs. 1 + 2B) – Storage Controller 250 receives a read command from a host--,
wherein:
the command identifies multiple addresses to read data from (“the command payload of the read command identifies specific logical block addresses of a virtual drive (e.g., a virtual NVMe drive) from which data is to be read” [0059]) – The payload of a read command includes specific logical block addresses of the virtual drives containing data to be read-- and
an address(“a source MAC address” [0056]) to transfer the data to (“Storage controller 250 receives messages 285 from host computing devices. The messages may be, for example, Ethernet packets … The Ethernet packet may include a transport header identifying … a source address (e.g., a source MAC address)” [0055-56] // ¶0048) – The transport header of the received read command includes a source MAC address identifying the MAC address of the requesting host (see also ¶0048)—
and wherein the multiple addresses include a first address (“first memory pages” [0060]) of the first storage device (SSD 150A, Fig. 1) and a second address (“second memory pages” [0060]) of the second storage device (SSD 150B, Fig. 1)(“Read module 257 may use a virtual drive map 220 for the virtual drive to determine what locations (e.g., what memory pages) on the physical storage devices (e.g., physical NVMe drives) correspond to the logical block addresses of the virtual drive. Read module 257 may then generate NVMe read commands 275 for each of the storage devices storing data to be read. For example, … read module 257 may determine first memory pages on a first NVMe drive storing requested information, second memory pages on a second NVMe drive storing requested information and third memory pages on a third NVMe drive storing requested information” [0059-60]) – Logical addresses are mapped to corresponding pages in corresponding physical drives. The specific logical block addresses identified by the read command payload correspond to plural memory pages located on plural NVMe drives including a first page on a first drive and a second page on a second drive.--; and
in response to receipt of the command, provide (¶0060) read commands to two or more of the plurality of storage devices based on the command (“Read module 257 may then generate NVMe read commands 275 for each of the storage devices storing data to be read.” [0060]) --- Plural NVMe read commands are generated based on the received read command from the host directed towards drives storing requested data--,
including a first read command (“a first NVMe read command” [0060]) to the first storage device to read first data stored at the first address and a second read command (“a second NVMe read command” [0060]) to the second storage device to read second data stored at the second address (“Read module 257 may then generate a first NVMe command directed to the first memory pages of the first NVMe drive, a second NVMe read command directed to second memory pages of the second NVMe drive, and a third NVMe read command directed to the third memory pages of the third NVMe drive.” [0060]) – The read module generates separate NVMe read commands directed towards the identified pages on the physical drives.--; and
a memory (Data Receive Buffer 222, Fig. 2B) to store accumulated data based on the command, wherein: the accumulated data includes the first data and the second data (“The NVMe drives receive the NVMe read commands and return data stored at indicated memory locations. The returned data is added to a data send buffer 221 by read module 257 until …. all requested data has been received” [0061]) – NVMe drives return requested data to read module 257. Returned data is accumulated in Data Send Buffer 221 until all requested data has been received from the NVMe drives--, and
the logic is to cause the accumulated data to be transferred from the memory to a host memory location indicated by the address from the command. (“Once the data send buffer fills, read module 257 may generate a response message 290 (e.g., a new Ethernet packet having the above identified format). Read module may then encapsulate the data from the data send buffer 221 into the response message 290. For example, read module 257 may generate an Ethernet packet with a transport header indicating the MAC address of the requesting storage device … Read module 257 may then send the response message 290 to the host.” [0061]) – The requested data is encapsulated into a response message which is sent to the host using the host MAC address (i.e., “to a host memory location indicated by the address from the command”).
Claims 2, 9, 13, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Malwankar further in view of Cosby et al. (US 20180335975 A1)(hereafter referred to as Cosby).
Regarding Claim 2,
Malwankar discloses the following limitations:
The method of claim 1, further comprising:
in response to the command: …
sending a single completion to the requester. (“The NVMe drives receive the NVMe read commands and return data stored at indicated memory locations … Once the data send buffer 221 fills, read module 257 may generate a response message 290 … Read module 257 may then encapsulate the data form the data send buffer 221 into the response message 290 … Read module 257 may then send the response message 290 to the host.” [0061]) – Data returned from the NVMe drives is accumulated into send buffer 221, after which the data is coalesced into a response message 290 (i.e., into “a single completion”) which is sent back to the host.
Malwankar does not explicitly disclose the following limitations:
receiving a first completion from the first storage device to indicate the first read command is complete;
receiving a second completion from the second storage device to indicate the second read command is complete; and
in response to receipt of both the first completion and the second completion, sending a single completion to the requester
However, Cosby discloses the following limitations:
receiving a first completion (“an abstraction response” [0029]) from the first storage device to indicate the first read command is complete;
receiving a second completion from the second storage device to indicate the second read command is complete (¶0029); and
in response to receipt of both the first completion and the second completion, sending a single completion to the requester (Fig. 1A // “a single host data storage command … may result in the generation of one or more disk data storage commands” [0026] // “Each disk that receives a disk data storage command may generate an abstraction response that may then be coalesced into a single host response that is responsive to the original host data storage command … For each disk read command, each disk response may include the requested data and the disk memory pointer range identifying the location in host memory where the requested data should be stored” [0029]) -- Examiner considers the storage environment depicted in Cosby Fig. 1A as analogous to the storage environment depicted in Malwankar Fig. 1. As taught in Cosby, each NVMe drive which receives a disk read command (i.e., at least “the first storage device” and “the second storage device”) returns a respective “abstraction response” (i.e., “a first completion” and “a second completion”) which includes the read data. The abstraction responses are coalesced into a “single host response” (i.e., “a single completion”)
Malwankar and Cosby are considered analogous to the claimed invention because they all relate to the same field of translating host storage commands into memory access commands in storage environments whereby a host volume is striped across multiple physical NVMe drives. 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 Malwankar with the teachings of Cosby and realize a method whereby a storage accelerator combines read responses received from plural NVMe drives into a single read response to a requesting host. Doing so enables multiple disk data storage commands to be generated from a single host command, thereby relieving a host computer of the complexity of managing discrete NVMe drives and thus enabling the benefits achieved by abstraction such as the ability of grow or shrink the size of a drive, as disclosed in Cosby ¶¶0026-27: “As discussed above, a single host data storage command (i.e., “host queue entry” or “host IO”) may result in the generation of one or more disk data storage commands (i.e., “disk queue entries” or “disk IOs”) … Embodiments may relieve the host computer from the complexity of separately managing each discrete physical NVMe drive. Rather, disclosed embodiments may divide the disk capacity into multiple disk namespaces, assign certain disk namespaces to a given host namespace, and achieve abstraction of the physical disks to enable various advanced storage services, such as the ability to grow or shrink the size of a drive” [0026-27]
Regarding Claim 9,
Malwankar discloses the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), wherein:
the multiple addresses include … logical block addresses, and each of the … logical block addresses maps to a different storage device coupled with the storage accelerator. (“if a virtual NVMe drive maps to three physical NVMe drives, read module 257 may determine first memory pages on a first NVMe drive … second memory pages on a second NVMe drive … and third memory pages on a third NVMe drive” [0060]) – As previously discussed, the specific logical block addresses included within the command payload correspond to at least three pages located across three separate.
Although Malwankar Fig. 1 shows that a host computing device has access to N (i.e., at least four) different SSDs, the example embodiment disclosed in Malwankar ¶0060 describes a host virtual drive which maps to three different SSDs. Malwankar accordingly does not anticipate the following limitations:
four logical block addresses, and
each of the four logical block addresses maps to a different storage device coupled with the storage accelerator.
However, Cosby clarifies that a host volume can be mapped to four different physical disks. Specifically, Cosby discloses the following limitations:
four logical block addresses (“Host LBAs” [0032]), and each of the four logical block addresses maps to a different storage device coupled with the storage accelerator. (Fig. 1A // “The host namespace (or host volume) in a host command may be used as an index into a lookup table that identifies one or more host namespaces” [0022] // “a single host data storage command … may result in the generation of one or more disk data storage commands … the disclosed embodiments may further implement striping by allocating, for a given host namespace, disk namespaces that are on separate physical disks” [0026-27] // “The following example, distributes Host LBAs across several disks with each disk having several slices … This Example assumes the following: Number of Disks = 4 Disks” [0032-33]) – Examiner considers the storage environment depicted in Cosby Fig. 1A as analogous to the storage environment depicted in Malwankar Fig. 1. As taught in Cosby, a host volume is comprised of Host LBAs which are distributed across different physical disks. In an example embodiment, a host namespace is distributed across four disks.
Malwankar and Cosby are considered analogous to the claimed invention because they all relate to the same field of translating host storage commands into memory access commands in storage environments whereby a host volume is striped across multiple physical NVMe drives. 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 Malwankar with the teachings of Cosby and realize a method whereby a storage accelerator receives a command from a requestor which includes at least four LBAs which are directed to different physical NVMe drives. Doing so enables multiple disk data storage commands to be generated from a single host command, thereby relieving a host computer of the complexity of managing discrete NVMe drives and thus enabling the benefits achieved by abstraction such as the ability of grow or shrink the size of a drive, as disclosed in Cosby ¶¶0026-27: “As discussed above, a single host data storage command (i.e., “host queue entry” or “host IO”) may result in the generation of one or more disk data storage commands (i.e., “disk queue entries” or “disk IOs”) … Embodiments may relieve the host computer from the complexity of separately managing each discrete physical NVMe drive. Rather, disclosed embodiments may divide the disk capacity into multiple disk namespaces, assign certain disk namespaces to a given host namespace, and achieve abstraction of the physical disks to enable various advanced storage services, such as the ability to grow or shrink the size of a drive” [0026-27]
Regarding Claim 13,
Malwankar discloses the following limitations:
The NVMe accelerator of claim 12 (see Claim 12 limitation mappings above), wherein:
the logic is to further, in response to the command: … sending a single completion to the host. (“The NVMe drives receive the NVMe read commands and return data stored at indicated memory locations … Once the data send buffer 221 fills, read module 257 may generate a response message 290 … Read module 257 may then encapsulate the data form the data send buffer 221 into the response message 290 … Read module 257 may then send the response message 290 to the host.” [0061]) – Data returned from the NVMe drives is accumulated into send buffer 221, after which the data is coalesced into a response message 290 (i.e., into “a single completion”) which is sent back to the host.
Malwankar does not explicitly disclose the following limitations:
accumulate completions from the first storage device and the second storage device that indicate completion of the first read command and the second read command, and in response to receipt of the completions sending a single completion to the host
However, Cosby discloses the following limitations:
accumulate completions (“an abstraction response” [0029]) from the first storage device and the second storage device that indicate completion of the first read command and the second read command, and in response to receipt of the completions sending a single completion to the host (Fig. 1A // “a single host data storage command … may result in the generation of one or more disk data storage commands” [0026] // “Each disk that receives a disk data storage command may generate an abstraction response that may then be coalesced into a single host response that is responsive to the original host data storage command … For each disk read command, each disk response may include the requested data and the disk memory pointer range identifying the location in host memory where the requested data should be stored” [0029]) -- Examiner considers the storage environment depicted in Cosby Fig. 1A as analogous to the storage environment depicted in Malwankar Fig. 1. As taught in Cosby, each NVMe drive which receives a disk read command (i.e., at least “the first storage device” and “the second storage device”) returns a respective “abstraction response” (i.e., “a first completion” and “a second completion”) which includes the read data. The abstraction responses are coalesced into a “single host response” (i.e., “a single completion”)
Malwankar and Cosby are considered analogous to the claimed invention because they all relate to the same field of translating host storage commands into memory access commands in storage environments whereby a host volume is striped across multiple physical NVMe drives. 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 Malwankar with the teachings of Cosby and realize a method whereby a storage accelerator combines read responses received from plural NVMe drives into a single read response to a requesting host. Doing so enables multiple disk data storage commands to be generated from a single host command, thereby relieving a host computer of the complexity of managing discrete NVMe drives and thus enabling the benefits achieved by abstraction such as the ability of grow or shrink the size of a drive, as disclosed in Cosby ¶¶0026-27: “As discussed above, a single host data storage command (i.e., “host queue entry” or “host IO”) may result in the generation of one or more disk data storage commands (i.e., “disk queue entries” or “disk IOs”) … Embodiments may relieve the host computer from the complexity of separately managing each discrete physical NVMe drive. Rather, disclosed embodiments may divide the disk capacity into multiple disk namespaces, assign certain disk namespaces to a given host namespace, and achieve abstraction of the physical disks to enable various advanced storage services, such as the ability to grow or shrink the size of a drive” [0026-27]
Regarding Claim 15,
Malwankar discloses the following limitations:
The NVMe accelerator of claim 12 (see Claim 12 limitation mappings above), wherein:
the multiple addresses include … logical block addresses, and each of the … logical block addresses maps to a different storage device to be coupled with the NVMe accelerator. (“if a virtual NVMe drive maps to three physical NVMe drives, read module 257 may determine first memory pages on a first NVMe drive … second memory pages on a second NVMe drive … and third memory pages on a third NVMe drive” [0060]) – As previously discussed, the specific logical block addresses included within the command payload correspond to at least three pages located across three separate drives.
Although Malwankar Fig. 1 shows that a host computing device has access to N (i.e., at least four) different SSDs, the example embodiment disclosed in Malwankar ¶0060 describes a host virtual drive which maps to three different SSDs. Malwankar accordingly does not anticipate the following limitations:
four logical block addresses, and
each of the four logical block addresses maps to a different storage device to be coupled with the NVMe accelerator.
However, Cosby clarifies that a host volume can be mapped to four different physical disks. Specifically, Cosby discloses the following limitations:
four logical block addresses (“Host LBAs” [0032]), and each of the four logical block addresses maps to a different storage device to be coupled with the NVMe accelerator. (Fig. 1A // “The host namespace (or host volume) in a host command may be used as an index into a lookup table that identifies one or more host namespaces” [0022] // “a single host data storage command … may result in the generation of one or more disk data storage commands … the disclosed embodiments may further implement striping by allocating, for a given host namespace, disk namespaces that are on separate physical disks” [0026-27] // “The following example, distributes Host LBAs across several disks with each disk having several slices … This Example assumes the following: Number of Disks = 4 Disks” [0032-33]) – Examiner considers the storage environment depicted in Cosby Fig. 1A as analogous to the storage environment depicted in Malwankar Fig. 1. As taught in Cosby, a host volume is comprised of Host LBAs which are distributed across different physical disks. In an example embodiment, a host namespace is distributed across four disks.
Malwankar and Cosby are considered analogous to the claimed invention because they all relate to the same field of translating host storage commands into memory access commands in storage environments whereby a host volume is striped across multiple physical NVMe drives. 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 Malwankar with the teachings of Cosby and realize a method whereby a storage accelerator receives a command from a requestor which includes at least four LBAs which are directed to different physical NVMe drives. Doing so enables multiple disk data storage commands to be generated from a single host command, thereby relieving a host computer of the complexity of managing discrete NVMe drives and thus enabling the benefits achieved by abstraction such as the ability of grow or shrink the size of a drive, as disclosed in Cosby ¶¶0026-27: “As discussed above, a single host data storage command (i.e., “host queue entry” or “host IO”) may result in the generation of one or more disk data storage commands (i.e., “disk queue entries” or “disk IOs”) … Embodiments may relieve the host computer from the complexity of separately managing each discrete physical NVMe drive. Rather, disclosed embodiments may divide the disk capacity into multiple disk namespaces, assign certain disk namespaces to a given host namespace, and achieve abstraction of the physical disks to enable various advanced storage services, such as the ability to grow or shrink the size of a drive” [0026-27]
Claims 3, 7, 14, 17-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Malwankar further in view of Suri et al. (US 20200050558 A1)(hereafter referred to as Suri).
Regarding Claim 3,
Malwankar discloses the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
Malwankar does not explicitly disclose the following limitations:
wherein: the command is a vendor specific command.
However, Suri discloses the following limitations:
the command (“an NVMe command” [0017]) is a vendor specific command. (“This disclosure relates to providing storage services to two or more hosts … namely modifying physical region pages (PRP) data pointers and list pointers associated with the Non-Volatile Memory Express (NVMe) standard” [0002] // “Each command may … include a Physical Region Pages (PRP) entry with a PRP address to identify as a pointer where data or a list is located in a memory domain of the host” [0017] // ¶0021) -- As taught in Suri, NVMe commands generated by a host include a modified PRP entry. Examiner considers a command which includes a modified entry as “a vendor specific command”)—
Malwankar and Suri are considered analogous to the claimed invention because they all relate to the same field of translating host storage commands into memory access commands in storage environments whereby a host volume is striped across multiple physical NVMe drives. 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 Malwankar with the teachings of Suri and realize a method whereby a command received from a requestor includes a pointer to a memory location storing a destination address for a read command. Doing so is a feature of a modified NVMe command structure which facilitates routing of PCIe memory requests in environments including plural hosts, as disclosed in Suri ¶¶0003-04: “When a single host is associated with the SSDs, routing the PCIe memory read request is straightforward. The PCIe memory read request is sent to the single host. When two or more hosts such as physical and/or virtual hosts are associated with the SSDs, routing the PCIe memory read request becomes more complex. The PRP entry provides no indication of which host of the two or more hosts is associated with PRP entry which would otherwise facilitate routing to that host … The host ID or VF ID facilitates routing of Peripheral Component Interconnect Express (PCIe) memory requests with the modified PRP data pointer or list pointer to one of the two or more hosts associated with the NVMe command” [0003-04]
Regarding Claim 7,
Malwankar discloses the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), wherein the memory location is a first memory location (Data Receive Buffer 322, Fig. 3)(“When a response message 345 is received .. message expander 315 may add the data to a data receive buffer” [0076] // ¶0069 // Figs. 1 + 3) – As shown in Fig. 3, data received in response to a read request is placed into a data receive buffer 322 (i.e., “a first memory location”) located within an NVMe Driver at the host.--,
Malwankar is silent regarding the following limitations:
wherein: the command includes a pointer to a second memory location where the address to transfer the data to is stored.
However, Suri discloses the following limitations:
wherein: the command (“an NVMe command” [0017]) includes a pointer (“a Physical Region Pages (PRP) entry” [0017]) to a second memory location where the address to transfer the data to is stored. (Figs. 1A + 1B // “a host may generate an NVMe command to fetch data stored in the SSD … Each command may … include a Physical Region Pages (PRP) entry with a PRP address to identify as a pointer where data or a list is located in a memory domain of the host … If the PRP2 entry is a list pointer, then the PRP2 entry points to a list of pointers stored in the host. The list pointer may have a PCIe address of the host memory where data pointers 2 through n are stored” [0017-18] // ¶0003) – Examiner considers the storage environment depicted in Suri Figs. 1A and 1B as analogous to the storage environment depicted in Malwankar Fig. 1. As taught in Suri, host-generated NVMe commands include a PRP address (i.e., “a pointer”) which points to a list of pointers in host memory which indicate routing of data after the command is processed by an SSD (i.e., “a second memory location where the address to transfer the data is stored”).
Malwankar and Suri are considered analogous to the claimed invention because they all relate to the same field of translating host storage commands into memory access commands in storage environments whereby a host volume is striped across multiple physical NVMe drives. 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 Malwankar with the teachings of Suri and realize a method whereby a command received from a requestor includes a pointer to a memory location storing a destination address for a read command. Doing so is a feature of a modified NVMe command structure which facilitates routing of PCIe memory requests in environments including plural hosts, as disclosed in Suri ¶¶0003-04: “When a single host is associated with the SSDs, routing the PCIe memory read request is straightforward. The PCIe memory read request is sent to the single host. When two or more hosts such as physical and/or virtual hosts are associated with the SSDs, routing the PCIe memory read request becomes more complex. The PRP entry provides no indication of which host of the two or more hosts is associated with PRP entry which would otherwise facilitate routing to that host … The host ID or VF ID facilitates routing of Peripheral Component Interconnect Express (PCIe) memory requests with the modified PRP data pointer or list pointer to one of the two or more hosts associated with the NVMe command” [0003-04]
Regarding Claim 14,
Malwankar discloses the following limitations:
The NVMe accelerator of claim 12 (see Claim 12 limitation mappings above), wherein: … the command identifies: a namespace identifier (“a virtual local area network (VLAN) tag”[0056]) , and a drive identifier (“an identifier (ID) of a virtual drive” [0056]) corresponding to each of the multiple addresses. (“each of the messages 285 is an Ethernet packet having a particular format and encapsulating an I/O command. The Ethernet packet may include a transport header identifying … a virtual local area network (VLAN) tag … a payload of the Ethernet packet may include a protocol header for the I/O command and a particular command payload and/or data payload. The protocol header includes an identifier (ID) of a virtual drive” [0056] // “the command payload of the read command identifies specific logical block addresses of a virtual drive (e.g., a virtual NVMe drive) from which data is to be read” [0059] // ¶0060) – Messages 285 received from the host are formatted according to an Ethernet packet format. The Ethernet packet includes a transport header, a protocol header, and a command payload. A transport header of the packet includes a VLAN tag, which examiner considers as reading on the claimed concept of “a namespace identifier.” A virtual drive ID is included within the protocol header, whereas LBAs of the virtual drive are included within the command payload.
Malwankar does not explicitly disclose the following limitations:
the command is a vendor specific command.
However, Suri discloses the following limitations:
the command (“an NVMe command” [0017]) is a vendor specific command. (“This disclosure relates to providing storage services to two or more hosts … namely modifying physical region pages (PRP) data pointers and list pointers associated with the Non-Volatile Memory Express (NVMe) standard” [0002] // “Each command may … include a Physical Region Pages (PRP) entry with a PRP address to identify as a pointer where data or a list is located in a memory domain of the host” [0017] // ¶0021) -- As taught in Suri, NVMe commands generated by a host include a modified PRP entry. Examiner considers a command which includes a modified entry as “a vendor specific command”)—
Malwankar and Suri are considered analogous to the claimed invention because they all relate to the same field of translating host storage commands into memory access commands in storage environments whereby a host volume is striped across multiple physical NVMe drives. 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 Malwankar with the teachings of Suri and realize a method whereby a command received from a requestor includes a pointer to a memory location storing a destination address for a read command. Doing so is a feature of a modified NVMe command structure which facilitates routing of PCIe memory requests in environments including plural hosts, as disclosed in Suri ¶¶0003-04: “When a single host is associated with the SSDs, routing the PCIe memory read request is straightforward. The PCIe memory read request is sent to the single host. When two or more hosts such as physical and/or virtual hosts are associated with the SSDs, routing the PCIe memory read request becomes more complex. The PRP entry provides no indication of which host of the two or more hosts is associated with PRP entry which would otherwise facilitate routing to that host … The host ID or VF ID facilitates routing of Peripheral Component Interconnect Express (PCIe) memory requests with the modified PRP data pointer or list pointer to one of the two or more hosts associated with the NVMe command” [0003-04]
Regarding Claim 17,
Malwankar anticipates the following limitations:
One or more non-transitory computer-readable media storing instructions (Fig. 11 // ¶0133) that, when executed by one or more processors (¶¶0130; 0133), cause the one or more processors to perform a method to enable handling of read requests (¶0059) for data having a size smaller than a block (“memory pages” [0059] // ¶0033), the method comprising:
receive (¶0059) the read requests for the data having the size smaller than the block (“I/O manager 255 is responsible for communicating with host computing devices and satisfying input/output (I/O) commands such as read commands” [0055] // “Responsive to receipt of a read command, the I/O manager 255 invokes read module 257” [0059] // Figs. 1 + 2B // ¶0063) – An I/O manager 255 included within a storage controller 108 invokes a read module 257 in response to receiving a read command from a host computing device (e.g., Host Computing Device 104A of Fig. 1A). The command targets data in multiples of memory pages (see ¶0063)--;
accumulate two or more of the read requests that target solid-state drives (SSDs) (SSDs 150A-150N, Fig. 1) coupled with a storage accelerator (Storage Controller 108A, Fig. 1 // Storage Controller 250, Fig. 2B // ¶0054)(“Storage controller 250 receives messages 285 from host computing devices … The received messages 285 may contain I/O commands encapsulated in the messages … The command payload includes specific command instructions, such as specific read or write instructions” [0054-57] // Fig. 2B) -- Examiner considers a controller 108 (e.g., 108A) depicted in Fig. 1 as “a storage accelerator”. Controller 108 receives (i.e., “accumulate[s]”) messages containing I/O commands for read instructions from the host--,
wherein the two or more read requests include a first request to read first data (“first memory pages” [0060]) stored at a first address on a first SSD and a second request to read second data stored at a second address (“second memory pages” [0060]) of a second SSD (“The command payload of the read command identifies specific logical block addresses of a virtual drive … from which data is to be read … Read module 257 may use a virtual drive map 220 for the virtual drive to determine what locations (e.g., what memory pages) on the physical storage devices (e.g., physical NVMe drives) correspond to the logical block addresses of the virtual drive. Read module 257 may then generate NVMe read commands 275 for each of the storage devices storing data to be read. For example, … read module 257 may determine first memory pages on a first NVMe drive storing requested information, second memory pages on a second NVMe drive storing requested information and third memory pages on a third NVMe drive storing requested information” [0059-60]) – Logical addresses are mapped to corresponding pages in corresponding physical drives. The specific logical block addresses identified by the read command payload correspond to plural memory pages located on plural NVMe drives including a first page on a first drive and a second page on a second drive.--;
provide a command (Messages 285, Fig. 2B) to the storage accelerator (Fig. 2B // “Storage controller 250 receives messages 285 from the host computing devices. The received messages may be, for example, Ethernet packets” [0055]) – As previously discussed, host computing devices transmit read commands to a storage controller by sending Messages 285--,
wherein the command identifies the first address, the second address, and an address (“a source MAC address” [0056]) … to transfer accumulated data to (“the command payload of the read command identifies specific logical block addresses of a virtual drive (e.g., a virtual NVMe drive) from which data is to be read” [0059] // “The Ethernet packet may include a transport header identifying … a source address (e.g., a source MAC address)” [0056] // ¶0048) – The command payload of the received messages specifies LBAs targeted by the message. The transport header of the received message includes a source MAC address identifying the MAC address of the requesting host (see also ¶0048)—,
wherein the accumulated data is to include the first data and the second data (“Read module 257 may then generate a first NVMe command directed to the first memory pages of the first NVMe drive, a second NVMe read command directed to second memory pages of the second NVMe drive, and a third NVMe read command directed to the third memory pages of the third NVMe drive … The NVMe drives receive the NVMe read commands and return data stored at indicated memory locations. The returned data is added to a data send buffer 221 by read module 257 until …. all requested data has been received” [0060-61]) – NVMe drives return requested data to read module 257. Returned data is accumulated in Data Send Buffer 221 until all requested data has been received from the NVMe drives--);
receive an indication that the command is complete (“Once the data send buffer 221 fills, read module 257 may generate a response message 290 … Read module 257 may then encapsulate the data form the data send buffer 221 into the response message 290 … Read module 257 may then send the response message 290 to the host.” [0061]) – Data returned from the NVMe drives is accumulated into send buffer 221, after which the data is coalesced into a response message 290 (i.e., into “a single completion”) which is sent back to the host.
; and
in response to the indication that the command is complete, access the accumulated data for the two or more read requests at the address. (Fig. 4 // “The protocol layer 408 then sends the NVMe read commands to the device layer 410 … The device layer provides the requested data 432 to the protocol layer … The transport layer 406 then sends 438 the Ethernet packet to the host … For each received Ethernet packet, the transport layer 405 extracts data from the Ethernet packet and adds the data to a request buffer 446. Once the status completion command is received, the transport layer 405 sends the data 448 to the protocol layer 404” [0084-86]) – As shown in Fig. 4 and clarified in ¶0086, after receiving the requested data and the completion response, the host extracts the accumulated data from a request buffer at the host and sends the data to the application layer. (i.e., at least “access[es] the accumulated data” “at the address”).
Malwankar does not explicitly describe an address within host memory included within messages 285 sent from the host to the storage controller. Accordingly, Malwankar does not explicitly disclose the following limitations:
the command identifies … an address in host memory to transfer accumulated data to
However, Suri discloses the following limitations:
the command (“an NVMe command” [0017]) identifies … an address in host memory (“a Physical Region Pages (PRP) entry” [0017]) to transfer accumulated data to (Figs. 1A + 1B // “a host may generate an NVMe command to fetch data stored in the SSD … Each command may … include a Physical Region Pages (PRP) entry with a PRP address to identify as a pointer where data or a list is located in a memory domain of the host … If the PRP2 entry is a list pointer, then the PRP2 entry points to a list of pointers stored in the host. The list pointer may have a PCIe address of the host memory where data pointers 2 through n are stored” [0017-18] // ¶0003) – Examiner considers the storage environment depicted in Suri Figs. 1A and 1B as analogous to the storage environment depicted in Malwankar Fig. 1. As taught in Suri, host-generated NVMe commands include a PRP address which identifies pointers in host memory which indicate routing of data after the command is processed by an SSD.
Malwankar and Suri are considered analogous to the claimed invention because they all relate to the same field of translating host storage commands into memory access commands in storage environments whereby a host volume is striped across multiple physical NVMe drives. 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 Malwankar with the teachings of Suri and realize a method whereby a command received from a requestor identifies a memory location in a host to be used as a destination for requested data. Doing so is a feature of a modified NVMe command structure which facilitates routing of PCIe memory requests in environments including plural hosts, as disclosed in Suri ¶¶0003-04: “When a single host is associated with the SSDs, routing the PCIe memory read request is straightforward. The PCIe memory read request is sent to the single host. When two or more hosts such as physical and/or virtual hosts are associated with the SSDs, routing the PCIe memory read request becomes more complex. The PRP entry provides no indication of which host of the two or more hosts is associated with PRP entry which would otherwise facilitate routing to that host … The host ID or VF ID facilitates routing of Peripheral Component Interconnect Express (PCIe) memory requests with the modified PRP data pointer or list pointer to one of the two or more hosts associated with the NVMe command” [0003-04]
Regarding Claim 18,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 18. The combined teachings of Malwankar and Suri disclose the following limitations:
The one or more non-transitory computer-readable media of claim 17, wherein:
the command is a vendor specific command (Suri, “This disclosure relates to providing storage services to two or more hosts … namely modifying physical region pages (PRP) data pointers and list pointers associated with the Non-Volatile Memory Express (NVMe) standard” [0002] // “Each command may … include a Physical Region Pages (PRP) entry with a PRP address to identify as a pointer where data or a list is located in a memory domain of the host” [0017] // ¶0021) – As taught in Suri, commands generated by a host include a modified PRP entry. Examiner considers a command which includes a modified entry as “a vendor specific command”)--, and
the command identifies: a namespace identifier (Malwankar, “a virtual local area network (VLAN) tag” [0056]), and a drive identifier (Malwankar, “an identifier (ID) of a virtual drive” [0056]) corresponding to each of the first address and the second address. (“each of the messages 285 is an Ethernet packet having a particular format and encapsulating an I/O command. The Ethernet packet may include a transport header identifying … a virtual local area network (VLAN) tag … a payload of the Ethernet packet may include a protocol header for the I/O command and a particular command payload and/or data payload. The protocol header includes an identifier (ID) of a virtual drive” [0056] // “the command payload of the read command identifies specific logical block addresses of a virtual drive (e.g., a virtual NVMe drive) from which data is to be read” [0059] // ¶0060) – Messages 285 received from the host are formatted according to an Ethernet packet format. The Ethernet packet includes a transport header, a protocol header, and a command payload. A transport header of the packet includes a VLAN tag, which examiner considers as reading on the claimed concept of “a namespace identifier.” A virtual drive ID is included within the protocol header, whereas LBAs of the virtual drive are included within the command payload.
Regarding Claim 20,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 20. The combined teachings of Malwankar and Suri disclose the following limitations:
The one or more non-transitory computer-readable media of claim 17, wherein: the accumulated data has a first size of the block, and the first data has a second size that is smaller than or equal to half the block. (Malwankar, “The returned data is added to a data send buffer 221 by read module 257 until …. all requested data has been received” [0061] // “Memory pages are grouped into blocks … Typical SSDs have blocks that include 256 memory pages” [0033]) – As previously discussed (see Claim 17 limitation mappings above), data read from first – third memory pages are accumulated from first-third SSDs into a send buffer prior to transmission back to the host. As taught in Malwankar ¶0033, typical SSDs include 256 memory pages per block. Thus, in an embodiments whereby a single page is read from each of three SSDs, “the accumulated data” would have a size of 3 pages = 3/256th of a block (i.e., “a first size of the block”). Additionally, the data read from a first memory page of a first SSD (i.e., “the first data”) would have a size of 1 page = 1/256th of a block (i.e., “a second size that is smaller than” “half the block”).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Malwankar further in view of Brief (US 8286188 B1)(hereafter referred to as Brief).
Regarding Claim 5,
Malwankar discloses the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), wherein the memory location is a first memory location, (Data Receive Buffer 322, Fig. 3)(“When a response message 345 is received .. message expander 315 may add the data to a data receive buffer” [0076] // ¶0069 // Figs. 1 + 3) – As shown in Fig. 3, data received in response to a read request is placed into a data receive buffer 322 (i.e., “a first memory location”) located within an NVMe Driver at the host.—
Malwankar is silent regarding the following limitations:
wherein: the command includes a pointer to a second memory location where the multiple addresses are stored.
However, Brief discloses the following limitations:
the command includes a pointer (“an initial physical buffer pointer” [Col. 10]) to a second memory location (“virtual buffer” [Col. 10]) where the multiple addresses are stored. (Fig. 15 // “upon receipt of a read/write/update request from address translation unit 106 containing, for example, an initial physical buffer pointer and range, memory access unit 506 may access the virtual buffer stacks maintained by memory allocation unit 504 to formulate and submit to the physical memory controller appropriate read, write, update and free commands” [Col. 9, 60th line – Col. 10, 10th line] // “a virtual buffer 1102 may be represented as a stack of a predetermined number of pointers … Each pointer may store the location of a physical buffer within shared physical memory.” [Col. 12, 50-60th lines] // “In step S1504, address translation unit 106 may receive one of a read or write request … in step S1506, address translation unit 106 determines that the request includes virtual buffer addresses … In step S1508, address translation unit 106 may submit the read/write request to memory interface unit 108 … In step S1520, memory access unit 506 may retrieve the contents of physical buffers of the virtual buffer identified by the read request” [Col. 14, 50th line – Col. 15, 25th line] // Fig. 8) -- Examiner considers the storage environment depicted in Brief Fig. 8 as analogous to the storage environment depicted in Malwankar Fig. 1. As taught in Brief, a virtual buffer pointer included within a received read request identifies a stack of physical buffer pointers which include data targeted by the read request (see Fig. 15).
Malwankar and Brief are considered analogous to the claimed invention because they all relate to the same field of routing host read requests in storage environments which abstract underlying physical addresses from the host using virtual addressing. 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 Malwankar with the teachings of Brief and realize a method whereby a read command identifies addresses containing requested read data using a pointer to a memory location. Doing so enables host processes to access larger memory pools, as disclosed in Brief Col. 12: “Each pointer may store the location a physical buffer within shared physical memory. In this manner, the interprocess memory controller may allow processes to allocate pools of memory larger than could otherwise be allocated by the respective process.” [Col. 12, 55-60th lines].
Claims 11 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Malwankar further in view of Schmeilin et al. (US 12093571 B1)(hereafter referred to as Schmeilin).
Regarding Claim 11,
Malwankar discloses the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above),
Malwankar is silent regarding storing data read from an SSD at a particular offset, and thus is silent regarding the following limitations:
wherein: storing the accumulated data in the memory of the storage accelerator comprises storing the first data at a first offset from the address and storing the second data at a second offset from the address based on the command.
However, Schmeilin discloses the following limitations:
wherein: storing the accumulated data in the memory of the storage accelerator (Server Network Device 206, Fig. 2) comprises storing the first data at a first offset from the address and storing the second data at a second offset from the address based on the command. (Fig. 2 // “a client 202 can initiate object transfers with a remote server 208 … to retrieve object data from memory associated with server 208 … The client 202 can then send a request to perform the object transfer using a get bulk data message 212 … The server 208 may respond to the message 216 by sending a write bulk data message 218 … The server 208 may send multiple write bulk data messages based on the total size of the object data requested in the get bulk data message 212, and each write bulk data message may include a corresponding buffer offset for placing that portion of that object data into the client buffer 122.” [Col. 5 – Col. 6, 20th lines]) – Examiner considers Client 202, Server Network Device 206, and Server 208 depicted in Schmeilin Fig. 2 as analogous to Host Computing Device 104A, Storage Controller 108A, and SSD 150A, respectively, depicted in Malwankar Fig. 1. As taught in Schmeilin, when returning requested data to a client, a server sends portions of the requested data (i.e., “the first data” and “the second data”) to the server network device for subsequent transmission to the client. Each portion is placed at “a corresponding buffer offset” for the portion (i.e., at “a first offset” and “a second offset” “from the address”).
Malwankar and Schmeilin are considered analogous to the claimed invention because they all relate to the same field of performing read requests and routing data to clients in distributed NVMe storage environments. 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 Malwankar with the teachings of Schmeilin and realize a method whereby data requested as part of a read command is written into a particular offset from a base address. Doing so is a feature of a zero-copy RDMA operation employed in distributed storage systems to offload a processing burden on a host, as disclosed in Schmeilin Cols. 2-3 and 6: “each write bulk data message may include a corresponding buffer offset for placing that portion of that object data into the client buffer 122.” [Col. 6] // “The embodiments can allow a client to submit object transfer commands … The bulk object can be transmitted via remote direct memory access (RDMA) to allow zero-copy operation bypassing network stack and avoiding host kernel to user copy.” [Cols. 2+3]
Regarding Claim 16,
Malwankar discloses the following limitations:
The NVMe accelerator of claim 12 (see Claim 12 limitation mappings above),
Malwankar is silent regarding storing data read from an SSD at a particular offset, and thus is silent regarding the following limitations:
wherein: to store the accumulated data in the memory, the logic is to: store the first data at a first offset from the address and store the second data at a second offset from the address based on the command.
However, Schmeilin discloses the following limitations:
wherein: to store the accumulated data in the memory, the logic is to: store the first data at a first offset from the address and store the second data at a second offset from the address based on the command. (Fig. 2 // “a client 202 can initiate object transfers with a remote server 208 … to retrieve object data from memory associated with server 208 … The client 202 can then send a request to perform the object transfer using a get bulk data message 212 … The server 208 may respond to the message 216 by sending a write bulk data message 218 … The server 208 may send multiple write bulk data messages based on the total size of the object data requested in the get bulk data message 212, and each write bulk data message may include a corresponding buffer offset for placing that portion of that object data into the client buffer 122.” [Col. 5 – Col. 6, 20th lines]) – Examiner considers Client 202, Server Network Device 206, and Server 208 depicted in Schmeilin Fig. 2 as analogous to Host Computing Device 104A, Storage Controller 108A, and SSD 150A, respectively, depicted in Malwankar Fig. 1. As taught in Schmeilin, when returning requested data to a client, a server sends portions of the requested data (i.e., “the first data” and “the second data”) to the server network device for subsequent transmission to the client. Each portion is placed at “a corresponding buffer offset” for the portion (i.e., at “a first offset” and “a second offset” “from the address”).
Malwankar and Schmeilin are considered analogous to the claimed invention because they all relate to the same field of performing read requests and routing data to clients in distributed NVMe storage environments. 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 Malwankar with the teachings of Schmeilin and realize a method whereby data requested as part of a read command is written into a particular offset from a base address. Doing so is a feature of a zero-copy RDMA operation employed in distributed storage systems to offload a processing burden on a host, as disclosed in Schmeilin Cols. 2-3 and 6: “each write bulk data message may include a corresponding buffer offset for placing that portion of that object data into the client buffer 122.” [Col. 6] // “The embodiments can allow a client to submit object transfer commands … The bulk object can be transmitted via remote direct memory access (RDMA) to allow zero-copy operation bypassing network stack and avoiding host kernel to user copy.” [Cols. 2+3]
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Malwankar further in view of Suri and Cosby.
Regarding Claim 19,
The same motivation to combine provided in Claim 17 is equally applicable to Claim 19. The combined teachings of Malwankar and Suri disclose the following limitations:
The one or more non-transitory computer-readable media of claim 17 (see Claim 17 limitation mappings above), wherein: the command identifies … logical block addresses including the first address and the second address, and each of the … logical block addresses maps to a different SSD coupled with the storage accelerator. (“if a virtual NVMe drive maps to three physical NVMe drives, read module 257 may determine first memory pages on a first NVMe drive … second memory pages on a second NVMe drive … and third memory pages on a third NVMe drive” [0060]) – As previously discussed, the specific logical block addresses included within the command payload correspond to at least three pages located across three separate drives.
Although Malwankar Fig. 1 shows that a host computing device has access to N (i.e., at least four) different SSDs, the example embodiment disclosed in Malwankar ¶0060 describes a host virtual drive which maps to three different SSDs. Malwankar accordingly does not anticipate the following limitations:
four logical block addresses …
each of the four logical block addresses maps to a different SSD coupled with the storage accelerator.
However, Cosby clarifies that a host volume can be mapped to four different physical disks. Specifically, Cosby discloses the following limitations:
four logical block addresses (“Host LBAs” [0032]) … each of the four logical block addresses maps to a different SSD coupled with the storage accelerator. (Fig. 1A // “The host namespace (or host volume) in a host command may be used as an index into a lookup table that identifies one or more host namespaces” [0022] // “a single host data storage command … may result in the generation of one or more disk data storage commands … the disclosed embodiments may further implement striping by allocating, for a given host namespace, disk namespaces that are on separate physical disks” [0026-27] // “The following example, distributes Host LBAs across several disks with each disk having several slices … This Example assumes the following: Number of Disks = 4 Disks” [0032-33]) – Examiner considers the storage environment depicted in Cosby Fig. 1A as analogous to the storage environment depicted in Malwankar Fig. 1. As taught in Cosby, a host volume is comprised of Host LBAs which are distributed across different physical disks. In an example embodiment, a host namespace is distributed across four disks.
Malwankar, Suri, and Cosby are considered analogous to the claimed invention because they all relate to the same field of translating host storage commands into memory access commands in storage environments whereby a host volume is striped across multiple physical NVMe drives. 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 Malwankar and Suri with the teachings of Cosby and realize a method whereby a storage accelerator receives a command from a requestor which includes at least four LBAs which are directed to different physical NVMe drives. Doing so enables multiple disk data storage commands to be generated from a single host command, thereby relieving a host computer of the complexity of managing discrete NVMe drives and thus enabling the benefits achieved by abstraction such as the ability of grow or shrink the size of a drive, as disclosed in Cosby ¶¶0026-27: “As discussed above, a single host data storage command (i.e., “host queue entry” or “host IO”) may result in the generation of one or more disk data storage commands (i.e., “disk queue entries” or “disk IOs”) … Embodiments may relieve the host computer from the complexity of separately managing each discrete physical NVMe drive. Rather, disclosed embodiments may divide the disk capacity into multiple disk namespaces, assign certain disk namespaces to a given host namespace, and achieve abstraction of the physical disks to enable various advanced storage services, such as the ability to grow or shrink the size of a drive” [0026-27]
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Joshua (US 20200401551 A1) – Discloses an NVMeOF NIC comprising an aggregator (see Fig. 2) and a method of performing read requests using the NVMeOF NIC (see Figs. 5 + 6)
Furey (US 20200050402 A1) – Discloses a method of generating storage access commands directed to four distinct SSDs in response to a storage access command received from a host (see Fig. 2 // ¶0023)
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 at 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
/SEAN D ROSSITER/Primary Examiner, Art Unit 2133
Prosecution Insights