DETAILED ACTION
Claims 1-4, 11-12, 15, 20 are amended. Claims 1-20 are pending.
Priority: June 23, 2022
Assignee: Seagate
Claim objections
1.Amended Claim 1 is objected for reciting a limitation that is inconsistent with the spec.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Claim 1 recites, ‘the bridge device coupled to a plurality of downstream target devices….’, ‘….allocating at least a portion of the target device NVM of each authenticated target device….’. The spec does not recite this limitation.
Though the spec is silent on the device ‘selection’ process, Para-0065 recites, ‘the bridge device can make intelligent decisions to select the number of devices, the amount of space to be allocated from each device….’.
But the claim does not recite selection of devices. It recites allocating a random portion of memory from all devices.
Spec:Para-0064 recites, ‘a request from the client for a selected capacity of memory, which….is configured by the bridge device through the allocation of associated memory in the applicable target devices’. Here the recitation of ‘applicable target devices’ further confirms the ‘selection’ of downstream target devices, based on client requirement.
Though claim 1 later recites ‘monitoring system performance’, it is valid to conclude that the monitoring results as unreliable because all target devices are used for capacity management, whether they are needed or not, thereby wasting capacity. Hence claim 1 is inconsistent with the spec. Claim 20 has a similar issue.
2.Amended Claim 1 is objected for reciting a limitation that is inconsistent with the spec.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Claim 1 recites, ‘monitoring by bridge device controller system performance during the data transfer operations with the individual namespaces’. The spec does not recite this limitation.
System performance measured at the bridge (Para-0066) depends upon data transfer operations involving the client, the bridge and the NVM devices. NVM monitoring is a time-based function. But the spec does not provide adequate written description on how ‘monitoring’ is done at the bridge to measure system performance.
It is well known in the prior art that, in NVMe, an individual namespace is a group of LBAs that abstracts a NVM device, each with its own configuration, e.g., NSID, total size of namespace in logical blocks, capacity (maximum number of allocatable logical blocks), utilization (currently allocated logical blocks), and other metadata, none of which is recited in the spec to explain monitoring and measuring dynamic system performance. The amendment attempts to stretch the spec and is a potential 112(a).
3.Amended Claim 11 is objected for reciting limitations that are inconsistent with the spec.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Claim 11 recites, ‘a plurality of data storage devices….’, ‘authenticating at least a selected number of the data storage devices’.
Further claim 11 recites, ‘monitor data transfer….allocate at least a portion of the storage device NVM of an additional data storage device from the plurality of storage devices’. The spec does not recite this limitation. As per claim 11 and spec:Figs. 8-9, the already created consolidated namespace is associated with selected, authenticated devices. But the ‘additional’ device is not authenticated. The spec is unclear about the authentication of the ‘additional device’ for a later requirement.
Though spec:Para-0067 recites adding additional devices, the spec does not recite how it is done. There is no written description of dynamic capacity usage tracking to determine if additional storage is needed, how much is needed and if an additional device is needed.
The spec does not use the nested association ‘first overall storage capacity’, in the limitation, ‘wherein the unitary namespace presented by the bridge device to the client device has a first overall storage capacity corresponding to the selected capacity of memory requested by the client device’.
4.Amended Claim 15 is objected for reciting a limitation that is inconsistent with the spec.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Claim 15 recites, ‘wherein the bridge device…., wherein the NVM of each of the bridge device….’ Here, spec:Fig. 6 shows a bridge device 252 with a device NVM 260. And as per spec:Fig. 12, bridge 502 is connected to a plurality of downstream target NVM devices 504,506.
In other words, the spec does not recite, ‘the NVM of each of the bridge device’. The bridge NVM is merely used by the bridge controller to store the consolidated namespace.
Furthermore, the spec does not recite, ‘wherein the NVM of each of the bridge device and the plurality of data storage devices has an overall storage capacity’. As per spec:Paras-0046,0047, ‘overall storage capacity’ is associated with the downstream NVM devices only.
The spec does not recite, ‘wherein the selected capacity requested by the client is greater than the overall storage capacity of each NVM’, because spec:Figs. 8-9 do not back the limitation and there is no capacity tracking. Also ‘overall storage capacity of each NVM’, is undefined in the spec.
5.Amended Claim 20 is objected for reciting a limitation that is inconsistent with the spec.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Claim 20 recites, ‘the controller……allocating individual namespaces among the plurality of additional SSDs and the NVM of the SSD, and by consolidating the individual namespaces into a consolidated namespace’.
The spec does not recite this limitation.
As per the spec, ‘the plurality of additional SSDs’, must be a selected number of devices based on the client request, and must be authenticated.
The consolidated namespace is associated with the individual namespaces of the downstream target devices.
The spec does not recite creating an ‘individual namespace’ for any NVM component in Fig. 6, bridge 200. In other words, the spec does not recite creating an ‘individual namespace’ for ‘the NVM of the SSD’.
Spec:Para-0002 recites, ‘The controller further communicates with a plurality of downstream target devices to allocate individual namespaces within main memory stores of each of the target devices to form a consolidated namespace.’
The bridge controller is a (consolidated) namespace manager. Though the spec does not explicitly recite where the consolidated namespace is stored, spec:Fig. 2 suggests that it may be stored in memory 204 of bridge device 200. That said, the claim 20 amendment is inconsistent with the spec.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 2, 12 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
1.Amended Claim 2 is rejected for reciting a limitation that is unsupported by the spec.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Claim 2 recites, ‘wherein at least a portion of the bridge memory is incorporated into the consolidated namespace as an additional individual namespace, ……of the bridge memory’.
Nowhere does the spec recite this limitation.
W.r.t. Fig. 4, Para-0036 of the spec recites, ‘The bridge device 200 is characterized as a data processing device having a bridge controller 202 and a bridge memory 204.’ And Para-0038 recites, ‘the memory 204 provides storage of a number of different data and programming structures, including firmware (FW) 206, cache 208…., a protocol table 210…., and….RAID control structures 212.’
Spec:Para-0040 recites the management of the consolidated namespace associated with the downstream NVM target devices.
There is no recitation of creation/allocation and storage of ‘an additional individual namespace’ for any NVM device at the bridge. Only the consolidated namespace, created for the downstream NVM devices, is stored and managed at the bridge. Also see Spec:Para-0002.
Therefore, whether any portion of the bridge memory 204 is included into the consolidated namespace as an additional individual namespace that can participate with individual namespaces of the downstream NVM target devices for dynamic capacity allocation and adjustment, to present the unitary namespace to the client, in response to the client request, is unproven. The limitation is beyond the spec.
Claim 2 is unsupported by the spec. It stretches the spec. Claim 12 has a similar issue.
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.
Claim(s) 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.
1.Amended Claim 1 is rejected for reciting a limitation that is unclear, vague and indefinite.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
Claim 1 recites, ‘the bridge device coupled to a plurality of downstream target devices….’,‘performing….operation comprising authenticating the target devices’. Here it is unclear why all the downstream devices are authenticated.
Spec:Fig. 8 shows the authentication of the device(s), for the client.
To further clarify the client-based authentication, spec:Para-0060 recites, ‘A bridge device 304 may initiate the authentication process such as by requesting an encrypted challenge string from a selected target device 306’. Though the spec is silent on the selection method, spec:Para-0065 recites, ‘the bridge device can make intelligent decisions to select the number of devices….’.
Therefore, in the spec, only a selected number of devices are authenticated based on the client capacity request.
Since the amendment authenticates all devices, it is unclear how the client capacity request is fulfilled, thereby leading to uncertainty about how the client, bridge controller and downstream devices interact to maintain the claimed ‘performance’. Hence claim 1 is rejected for reciting a limitation that is unclear, vague and indefinite. Claim 20 has the same issue. Also note that claim 1 differs from claim 11 with respect to ‘selected’ devices, and the spec discloses only one recitation.
2.Amended Claim 1 is rejected for reciting a limitation that is unclear, vague and indefinite.
Claim 1 recites, ‘adaptively adjusting ……to maintain a selected level of performance while continuing to present the unitary namespace….to the client device’.
As recited and in light of the spec, it is unclear what ‘maintain a selected level of performance’ means.
The spec does not define ‘a selected level of performance’ and how it is determined. NVM monitoring is a time-based function and as mentioned in the claim 1 objection, the spec does not provide any information about how ‘monitoring’ is performed to measure system performance.
Spec:Para-0066 recites, ‘Block 334 shows that during operation, the system performance will be monitored at the bridge device level, and adaptive adjustments to the system are carried out as required’.
It is well-known in the prior art that adaptive adjustment involves dynamic monitoring and feedback where the system observes NVM performance and workload, analyzes them, and then makes informed decisions to adjust NVM namespace capacities, device capacities or read/write operations.
It is also well-known in the prior art that to achieve ‘a selected level of performance’ or a specific performance target for a NVM system, key performance metrics like latency, IOPS, bandwidth, endurance etc. must be considered. But neither the claim nor the spec provide any relevant information on ‘adaptive adjustment’ to ‘maintain a selected level of performance’.
Hence claim 1 is rejected for reciting a limitation that is unclear, vague and indefinite. Claims 2-10 are rejected for failing to cure the deficiency from their respective parent claim by dependency.
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.
Claims 1-6, 8, 10-12, 14-19 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Furey et al (20200050402) in view of NVMe-Work Group (‘NVMe Base Specification-2.0a’, 2021, Pgs. 1-454, hereinafter NVMe-WG), Frolikov (20190227921), Sharon et al (20200409559) and Secatch et al (20200004450).
As per Claim 1, Furey discloses a method (Furey, [0004 - Fig. 1 relates to a NVMe switch which is arranged to provide various storage services to a host/client while reducing a need for the host to directly interact and manage storage in the form of solid state devices/SSDs/JBOF]) comprising:
establishing a secure connection between an upstream client device (Furey, [0041 – In Fig. 5, at step 504, the NVMe switch determines whether the host has access to the namespace based on the reservation table. At step 506, if the host has access to the namespace, it sends the storage access command to the SSD]; [0017 – In Fig. 1, the storage system includes host/client 102]) and a bridge device across (Furey, [0017 – A Non-Volatile Memory Express/NVMe switch 106]) a first interface (Furey, [0018 – In Fig. 1, PCIe cluster 110 is a PCIe endpoint cluster which facilitates communication between the NVMe switch 106 and two or more hosts/clients 102-104]; [0043 - Fig. 6: PCIe EP cluster]), the bridge device coupled to a plurality of downstream target devices across a second interface (Furey, [0018 – In Fig. 1, PCIe cluster 108 is a PCIe root complex cluster which facilitates communication between the NVMe switch 106 and SSDs 104]; [0018 - PCIe cluster 108]; [0043 - Fig. 6: PCIe RC cluster]; [0032 - In RAID 0 or JBOF, data is written or read in parallel from multiple SSDs increasing bandwidth of the storage operation, thereby implying a second interface; The spec also recites the parallel interaction as the ‘second interface’]),
the bridge device comprising a bridge device controller and a bridge memory (Furey, [0018 – In Fig. 1, NVMe switch 106 includes a PCIe cluster 110, a management processor 112, a command processor 114, a data processor 116]; [0042 – In Fig. 6, NVMe switch 106 includes memory 604/bridge memory]),
each of the target devices (Furey, [0017 – In Fig. 1, a storage comprising SSDs 104]) comprising a target device controller and a target device non-volatile memory (NVM) (Furey, [0030 - The storage performance and fault tolerance includes operation of the SSDs as just a bunch of flash/JBOF or a redundant array of independent disks/RAID, thereby implying that each target device has a target controller and a target device NVM; Also each flash device has NVM chips and a separate controller]);
receiving, by the bridge device (Furey, [0017 – A Non-Volatile Memory Express/NVMe switch 106]), a request from the client device (Furey, [0022 – In Fig. 2, at step 202, a first storage access command such as an NVMe store command is received from the host/client]) for a first selected capacity of memory (Furey, [0027 - The management processor allows associating a capacity to the VD or maximum available storage. The NVMe switch performs storage operations requested by the host, but if the storage operation exceeds the capacity of the VD, the management processor indicates an error to the host, thereby implying that the received allocation request from the client has a first selected capacity corresponding to the unitary namespace as required by Para-0082 of the spec]);
using the bridge device controller to present a unitary namespace to the client device having the first selected capacity of memory (Furey, [0027 - The NVMe switch advertises the virtual namespaces to the host/client with namespace IDs/NSIDs. The host uses the NSID to obtain access to the namespace]; [0027 - Management processor 112 of the NVMe switch has an offset table which associates virtual namespaces with different memory offsets in the single namespace]) by:
performing an initial processing operation comprising authenticating the target devices (Furey, [0023 – In Fig. 2, step 204, in response to the first host access command, the NVMe switch sends a respective second storage access command to two or more SSDs associated with the VD, thereby authenticating the selected target devices; This interpretation is similar to Para-0060 of the spec]),
and allocating at least a portion of the target device NVM of each authenticated target device to provide a corresponding individual namespace in each authenticated target device (Furey, [Fig. 5 authenticates client and device; Same as spec:Fig. 8]; [0024 – In Fig. 2, step 206, the NVMe switch receives a respective completion from each of the two or more SSDs indicating completion of the respective second storage access command sent to them, thereby implying that a portion of the target device NVM of each authenticated target device has been allocated to provide an individual namespace]);
consolidating the corresponding individual namespaces (Furey, [0027 - Defining logical blocks of storage which are assigned a namespace]) from the authenticated target devices to form a consolidated namespace (Furey, [0027 - A single/individual namespace is associated with a single SSD. The management processor allows for partitioning/allocating the single namespace into a plurality of virtual namespaces associated with single SSD]; [0018 - Management processor 112, a controller component, manages partitions of the SSDs 104, reservation access, and namespaces associated with SSDs 104, thereby implying forming a consolidated namespace presented by target devices/SSDs 104]) having a second selected capacity equal to or greater than the first selected capacity (Furey, [0027 - The management processor allows for associating a capacity to the VD or maximum available storage/first capacity. The NVMe switch performs storage operations requested by the host, but if the storage operation exceeds the capacity/second capacity of the VD, the management processor indicates an error to the host, thereby implying that the second capacity is greater than the first capacity]; [0021-0024 - Fig. 2 is associated with the client-based first capacity]);
transferring data between the client device and the authenticated target devices (Furey, [Fig. 5]) by using the bridge device controller (Furey, [0017 - The NVMe switch 106 processes NVMe commands to control PCIe based point-to-point switch connections between hosts 102 and SSDs 104]; [0004 - The NVMe switch coordinates exchange of storage access commands and completions between the host and SSDs to provide storage services]) to receive commands issued from the client device associated with the unitary namespace (Furey, [0027 – In Fig. 1, each virtual namespace is associated with a plurality of logical blocks/LBAs in the namespace. The NVMe switch advertises these virtual namespaces to the host with namespace IDs/NSIDs and the host reserves a virtual namespace using NVMe namespace commands]) into direct corresponding commands (Furey, [0018 - The command processor 114 processes NVMe commands from host 102]) to each of the respective authenticated target devices (Furey, [0027 - The host/client uses the NSID to obtain access to the namespace. The management processor in the NVMe switch has an offset table which associates virtual namespaces with different memory offsets in the single namespace]; [0019 - The device queue manager 150 provides queue pairs to facilitate communication of NVMe commands between the NVMe switch 106 and SSDs 104]);
monitoring, by the bridge device controller, system performance during the data transfer operations ([See objection]) with the individual namespaces (Furey, [0029 - The NVMe switch facilitate controlling storage performance, such as bandwidth of read/write access/data transfer operations to the storage/SSDs 104/devices]);
wherein the unitary namespace and the individual namespaces (Furey, [0027 - A single namespace is associated with a single SSD or VD. The management processor has an offset table which associates virtual namespaces with different memory offsets in the single namespace]) are each characterized as NVMe (Non-Volatile Memory Express) namespaces (Furey, [0027 – In Fig. 1, each virtual namespace is associated with a plurality of logical blocks/LBAs in the namespace. The NVMe switch advertises these virtual namespaces to the host with namespace IDs/NSIDs and the host reserves a virtual namespace using NVMe namespace commands. Then, the host uses the NSID to obtain access to the namespace, thereby implying that the unitary namespace and the individual namespace are each characterized as NVMe namespaces]),
wherein the bridge device controller operates as an NVMe controller (Furey, [0007 – In Fig. 1, the NVMe switch comprises: a command queue, a completion queue, instructions stored in memory of the NVMe switch which when executed by processors of the NVMe switch, cause it to receive a first storage access command from a host via a PCIe interface to access storage, wherein the first storage access command conforms to NVMe and the storage comprises of SSDs, thereby implying that the NVMe switch operates as a NVMe controller]) that interfaces with the client to support the unitary namespace (Furey, [0018 – In Fig. 1, PCIe cluster 110 is a PCIe endpoint cluster which facilitates communication between the NVMe switch 106 and hosts/clients 102-104]; [0027 - The host uses the NSID to obtain access to its NVMe unitary namespace]),
the bridge device operative as a virtual client device (Furey, [0020 - The NVMe switch facilitates virtualizing the SSDs as a virtual disk. The NVMe switch also supports creation of virtual namespaces associated with hosts]; [0027 - The NVMe switch advertises the virtual namespaces to the host with NSIDs and the host reserves a virtual namespace using NVMe namespace commands. Then, the host uses the NSID to obtain access to the namespace]).
NVMe-WG clarifies the communication between client, bridge and target devices as follows,
establishing a secure connection between an upstream client device and a bridge device across a first interface (NVMe-WG, [Pg. 372 – Fig. 432 shows the TLS secure channel establishment]; [Pg. 374, Sec. 8.13.4.1 - The AUTH_Negotiate message is sent from the host/client to the controller/bridge to indicate the authentication protocol and secure channel protocol the host is able to use in the authentication transaction]; [Pg. 1, Para-1 - The NVMe interface allows the host to communicate with a NVM subsystem. The interface is optimized for PCIe, Ethernet, InfiniBandTM, and Fibre Channel]),
each of the target devices comprising a target device controller and a target device non-volatile memory (NVM) (NVMe-WG, [Pg. 24 – Fig. 13 shows a Single-Namespace NVM Subsystem. The NVM subsystem consists of a single port and a single domain. The domain contains a controller/target device controller and storage media/target device NVM. All of the storage media are contained in one Endurance Group. All of the storage media in that Endurance Group are organized into one NVM Set containing a single namespace]);
performing an initial processing operation comprising authenticating the target devices (NVMe-WG, [Pg. 21, Sec. 2.2.5:Authentication - A controller associated with an NVM subsystem that requires a fabric secure channel shall not accept any commands on an NVMe Transport until a secure channel is established. Following a Connect command, a controller that requires NVMe in-band authentication shall not accept any commands on the queue created by that Connect command other than authentication commands until NVMe in-band authentication has completed. Refer to Pg. 271:section 8.13]),
using the target device controllers to process the corresponding commands (NVMe-WG, [Pg. 23, Sec. 2.3.2 - I/O commands perform operations on namespaces, and each namespace is associated with one I/O command set]) issued by the bridge device controller (NVMe-WG, [Figs. 6-7]) to carry out data transfer operations (NVMe-WG, [Pg. 18, Para-1 - A Submission Queue/SQ is a circular buffer with a fixed slot size that the host uses to submit commands for execution by the controller]; [Pg. 15, Para-5 - The message/memory-based transport model uses a combination of messages and memory read and write operations to transfer command capsules, response capsules and data between fabric nodes]) with the individual namespaces (NVMe-WG, [Pg. 173, Fig. 195 - NS Specific: If set to ‘1’, then the Feature Identifier is namespace specific and settings are applied to individual namespaces]) in the target device NVMs (NVMe-WG, [Pg. 26, Para-1 – Fig. 15: An NVM subsystem may have multiple domains, multiple namespaces, multiple controllers, and multiple ports]; [Pg. 28 – Fig. 18 shows NVM Subsystem with Two Controllers and Two Ports]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the NVMe interface of NVMe-WG into the NVMe switch of Furey for the benefit of using the NVMe specification to define a set of properties and commands that comprise the interface required for communication with a controller in an NVM subsystem. These properties are implemented by a controller using a NVMe Transport (NVMe-WG, Pg. 3, Para-1).
Frolikov clarifies the authentication and namespace creation of target devices as follows,
receiving, by the bridge device, a request from the client device for a first selected capacity of memory (Frolikov, [Fig. 12: step 201, receive a request to allocate storage for a namespace having a requested size; This is conforms to Para-0082 of spec]);
performing an initial processing operation comprising authenticating [(See 112(b)] the target devices (Frolikov, [0221 - Fig. 21 shows a crypto structure of a storage device/target]; [Fig. 22: step 453]; [0224 - Each allocated namespace on the storage device has a different crypto key stored in the corresponding register in the key bank]; [0228 - After performing authentication, the crypto engine 421 decrypts the copy in the crypto engine 421 to process data accesses made using the namespace maps 441,….,443 and the corresponding crypto keys]),
and allocating at least a portion of the target device NVM (Frolikov, [Fig. 1: NVM media 109]) of each authenticated target device (Frolikov, [Fig. 1: storage device 103]) to provide a corresponding individual namespace in each authenticated target device (Frolikov, [0130 - Fig. 12 shows a method to allocate a namespace on a storage device]; [0132 – In Fig. 12, at step 201 receiving a request to allocate a portion of the NVM media 109 of the storage device 103 for a namespace 111 having a requested namespace size 131; This citation is according to Fig. 9, Para-0064 of the spec]; [0140 - The request to allocate the namespace 111 is made using a protocol that is in accordance with Non-Volatile Memory Host Controller Interface Specification/NVMHCI or NVMe]);
adaptively adjusting (Frolikov, [0018 - Figs. 13-16 show examples of adjusting sizes of namespaces through namespace mapping]) the second selected capacity of the consolidated namespace (Frolikov, [0196 - Fig. 20 shows a method to adjust a namespace via adjusting a namespace map/consolidated namespace]; [Abstract,0076 - The storage device/administrative manager/controller stores a namespace map that defines the mapping between the logical addresses in a namespace identified by the namespace identifier and the logical addresses, in a capacity of the storage device, that correspond to the portion of the non-volatile storage media allocated to and accessible to the client account]) by at least a selected one of releasing (Frolikov, [0200 – In Fig. 20, in response to a determination to reduce the allocation of namespace 221 on NVM 109, the method includes removing from the namespace map identifiers of blocks of the logical address capacity that are no longer mapped/allocated to the namespace 221]) a first individual namespace from a first target device or adding (Frolikov, [0201 - In Fig. 20, in response to a determination to expand the allocation of namespace 221 on NVM 109, the method further includes adding to the namespace map identifiers of additional blocks of the logical address capacity]) a second individual namespace from a second target device (Frolikov, [Fig. 20: step 405, Expand/add or Reduce/release ?]) to maintain a selected level of performance while continuing to present the unitary namespace with the first selected capacity to the client device (Frolikov, [Fig. 25]; [0267 - The identification of an account, e.g., 531 uniquely identifies a namespace, e.g., 522, in which user/client data in the account, e.g., 531 is stored]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the authentication of Frolikov into the NVMe switch of Furey for the benefit of separation of storage resources used by different accounts/clients according to namespace thereby allowing client data in different accounts to be separately encrypted and thus protected cryptographically, using different encryption keys registered with the namespaces in storage devices, (Frolikov, 0258).
Sharon discloses,
a consolidated namespace (Sharon, [0083 – In Fig. 6, each namespace of a plurality of namespaces represented in the logical address space 134 comprises a set of logical block addresses/LBAs]) having a second selected storage capacity equal to or greater than the first selected storage capacity (Sharon, [0149 - In Fig. 15, if there are no open blocks using the new arrived write data NSID, at step 1510 the storage device determines whether the number of currently open blocks has reached the limit for the maximum number of open blocks. If not, the storage device opens a new block in step 1512, writes the data and updates correlation table 908 with the arrived NSID. If it is impossible to open a new block, at step 1514 the data is sent to one of the already open blocks while updating the correlation table 908 accordingly in step 1516; Here the new write data NSID is associated with the host request. And Fig. 15 shows that when a new write data NSID is received, data corresponding to it is always saved, thereby implying that memory is made available on the SSD-side, if needed. This implies that the consolidated namespace has a second selected storage capacity/SSD-side equal to or greater than the first selected storage capacity/client-side]);
wherein the target controller (Sharon, [Fig. 10: NVMe controller 1002]) of each of the target devices (Sharon, [0039 – In Fig. 1, the NVM devices 118 comprise a respective storage controller 126/target NVMe controller and NVM media 120/target device NVM]) operates as an embedded NVMe controller (Sharon, [0033 - The NVM devices 118 are integrated with, and/or mounted on, a motherboard of the computing device 104, thereby implying that each target controller operates as an embedded NVMe controller]) for the associated individual namespace to interface with the bridge device (Sharon, [0131 – In Fig. 10, the NVMe controller supports two namespaces, namespace A 1008/NS A and namespace B 1010/NS B. Associated with each controller namespace is a namespace ID, respectively labeled as NSID 1 and NSID 2]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the memory management of Sharon into the NVMe switch of Furey, NVMe-WG, Frolikov for the benefit of having a NVM storage device to determine a relationship between namespaces and utilize the relationship when selecting an open memory block for the storage of data in order to increase operational performance and reduce wear-leveling operations on non-volatile memory (Sharon, 0005).
Secatch clarifies monitoring the system performance as follows,
monitoring (Secatch, [0060 - Fig. 7 shows sequence 200 in which map data 190 from Fig. 6 is updated to flash memory 142 over time. Each journal update provides a listing of the changes and updates that have occurred since the most recent snapshot]), by the bridge device controller (Secatch, [Fig. 2: controller 112]; [0024 - The controller partitions the map metadata/namespace into separate and distinct map data sets, with each map data set describing a different die set/NVM set]; [0064 – In Fig. 9, the map manager 220 forms a portion of controller 112]), system performance (Secatch, [0048 – In Fig. 4, first set 162 uses a single die 144 from each of the different channels 146. This arrangement provides fast performance during the servicing of data transfer commands for the set since all eight channels 146 are used to transfer the associated data to service a host/client access command]; [0049 – In Fig. 4, a second set 164 uses dies 144 from less than all of the available channels 146. This arrangement provides relatively slower overall performance during data transfers as compared to set 162, since for a given size of data transfer, the data will be transferred using fewer channels]) during the data transfer operations with the individual namespaces (Secatch, [0061 - Controller 112 continuously carries out multiple functions to service users of the various NVM sets, such as hot data transfers, cold data transfers and map data transfers]; [0025 - The sets are configurable so that different numbers and sizes of die/NVM sets can be used over time to accommodate different user requirements]; [0033 - The SSD operates in accordance with the NVMe Standard, which enables different users to allocate NVM sets/die sets for use to store data. Each NVM set forms a portion of an NVMe namespace/map that may span multiple SSDs or be contained within a single SSD]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the map manager of Secatch into the NVMe switch of Furey, NVMe-WG, Frolikov, Sharon for the benefit of using the map manager at selected times to reconfigure the system mapping to accommodate new NVM/die sets. The map manager circuit establishes or updates an array of map pointers that are subsequently used to associate the various portions of the map metadata to the new NVM sets (Secatch, 0065).
As per Claim 2, the rejection of claim 1 is incorporated and Furey discloses,
wherein at least a portion of the bridge memory (Furey, [0042 – In Fig. 6, NVMe switch 106 includes memory 604/bridge memory]) is incorporated into the consolidated namespace (Furey, [0044 – In Fig. 6, processor 602 and memory 604 implement and facilitate implementing the functionalities of management processor 610, data processor 612, and command processor 614, which are components of the NVMe switch]; [0018 - Management processor 112 manages partitions of the SSDs 104, reservation access, and namespaces associated with SSDs 104/consolidated namespace]; [0027 - Management processor has an offset table which associates virtual namespaces with different memory offsets in the single namespace]; [0027 – In Fig. 1, each virtual namespace is associated with a unique plurality of logical blocks/LBAs in the namespace. The NVMe switch advertises these virtual namespaces to the host with namespace IDs/NSIDs, thereby implying that a portion of the bridge memory is incorporated into the consolidated namespace, thereby implying that the consolidated namespace may be stored in the bridge memory]) as an additional individual namespace, and wherein the transferring step further comprises storing in each of the individual namespaces of the target devices and the additional individual namespace of the bridge memory ([See 112(a)]; (Furey, [Figs. 1, 6]).
As per Claim 3, the rejection of claim 1 is incorporated and Furey, NVMe-WG, Frolikov, Sharon disclose,
wherein the first selected capacity, is less than the second selected capacity (Sharon, [0149 - In Fig. 15, if there are no open blocks using the new arrived write data NSID, at decision step 1510 the storage device determines whether the number of currently open blocks has reached the limit for the maximum number of open blocks. If not, the storage device opens a new block in step 1512, writes the data and updates correlation table 908 with the arrived NSID. If it is impossible to open a new block, at step 1514 the data is sent to one of the already open blocks while updating the correlation table 908 accordingly in step 1516; Here Fig. 15 shows that when a new write data NSID is received, data corresponding to it is always saved, thereby implying that memory is made available if needed on the SSD-side. This implies that the first selected capacity is less than the second selected capacity]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the memory management of Sharon into the NVMe switch handling of NVMe storage access commands of Furey, NVMe-WG, Frolikov for the benefit of having a NVM storage device to determine a relationship between namespaces and utilize the relationship when selecting an open memory block for the storage of data in order to increase operational performance and reduce wear-leveling operations on non-volatile memory (Sharon, 0005).
Furey discloses,
wherein the bridge device controller distributes data received from the client device (Furey, [0031 – In Fig. 3, step 302, a first storage access command such as a NVMe store or fetch command is received from the host/client]; [0023 – In Fig. 2, step 204, the NVMe switch sends a respective second storage access command to two or more SSDs associated with the VD. For example, if the VD is associated with four physical SSDs and the storage access command from the host requires access to these four physical SSDs, the command processor sends a second storage access command to each of the four SSDs associated with the VD, thereby implying distributing the data received from the client/host]) across the individual target devices using at least one RAID-level type of processing (Furey, [0032 – In Fig. 3, step 304, the NVMe switch/controller sends a respective second storage access command to two or more SSDs to achieve a certain level of performance and/or fault tolerance of a storage operation associated with the first storage access command received from the host. In RAID 0 or JBOF, data is written or read in parallel from multiple SSDs increasing bandwidth of the storage operation. The NVMe switch inserts a second storage access command into a respective submission queue of the two or more SSD to send/distribute the second storage access command to each of the SSDs to read data in parallel from the two or more SSDs and/or write the data in parallel to the two or more SSDs. In RAID 1 to RAID 10, data associated with the storage operation is duplicated by mirroring or striping data on multiple SSDs to improve fault tolerance, thereby implying that the controller distributes data received from the client across the individual target devices using at least one RAID-level type of processing]).
As per Claim 4, the rejection of claim 1 is incorporated and Furey, NVMe-WG, Frolikov, Sharon disclose,
wherein the bridge device controller is further configured to allocate (Sharon, [0107 – In Fig. 8, workload analyzer 800 includes a monitor 802, a comparator 804, a tracker 806, a set of workload attributes 808, and a namespace relationship table 810]) at least one additional individual namespace from a selected one of the target devices to increase the second selected capacity of the consolidated namespace (Sharon, [Fig. 6]) without adjusting the first selected capacity of the unitary namespace presented by the bridge device to the client device (Sharon, [0149 - In Fig. 15, if there are no open blocks using the new arrived write data NSID and LBA, at decision step 1510 the storage device determines whether the number of currently open blocks has reached the limit for the maximum number of open blocks. If not, the storage device opens a new block in step 1512, thereby increasing second selected capacity of the consolidated space because a new block was opened which further implies adjusting/increasing the capacity of the consolidated namespace without adjusting first selected capacity of the unitary namespace]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the memory management of Sharon into the NVMe switch handling of NVMe storage access commands of Furey, NVMe-WG, Frolikov for the benefit of having a NVM storage device to determine a relationship between namespaces and utilize the relationship when selecting an open memory block for the storage of data in order to increase operational performance and reduce wear-leveling operations on non-volatile memory (Sharon, 0005).
As per Claim 5, the rejection of claim 1 is incorporated and Furey discloses,
wherein the bridge device (Furey, [Fig. 1: NVMe switch 106]; [0018 - The NVMe switch 106 includes a PCIe cluster 110, a management processor 112, a command processor 114, a data processor 116, and a PCIe cluster 108]) is a storage device nominally identical to each of the target devices (Furey, [0030 - Fig. 1: solid state drives/SSDs/JBOF 104 are the target devices; Since they are functionally different, it implies that the bridge device is a storage device nominally identical to the target devices. Since the claim does not define ‘nominally identical’, the citation is a valid interpretation]).
As per Claim 6, the rejection of claim 1 is incorporated and Furey, NVMe-WG, Frolikov, Sharon disclose,
wherein the bridge device and target devices are each characterized as a solid-state drive (SSD) (Sharon, [Fig. 1: Non-volatile memory system 102]; [0033 – NVM devices 118 may be integrated with, and/or mounted on a motherboard of computing device 104]),
wherein at least two of the independent namespaces are allocated from the same NVM of a selected one of the SSDs (Sharon, [0135 – In Fig. 11, NVM set B 1108 contains NS B1 1118, NS B2 1120, and unallocated space]; [Fig. 9: OEB0]; [0128 - In Fig. 9, in OEB0, the allocation constraint is the shared namespace flag; As per Para-0065 of the spec, namespaces can be shared/partial]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the memory management of Sharon into the NVMe switch handling of NVMe storage access commands of Furey, NVMe-WG, Frolikov for the benefit of having a NVM storage device to determine a relationship between namespaces and utilize the relationship when selecting an open memory block for the storage of data in order to increase operational performance and reduce wear-leveling operations on non-volatile memory (Sharon, 0005).
As per Claim 8, the rejection of claim 1 is incorporated and Furey, NVMe-WG, Frolikov, Sharon disclose,
wherein the bridge device and each of the target devices are solid-state drives (SSDs) (Sharon, [Fig. 1: Non-volatile memory system 102]; [0033 – NVM devices 118 may be integrated with, and/or mounted on a motherboard of computing device 104]),
and the NVM of each of the target devices comprises flash memory (Sharon, [0045 – In Fig. 1, non-volatile memory devices 118 comprise non-volatile memory elements 122/main memory store of non-volatile memory media 120, which include NAND flash memory, e.g., 2D NAND flash memory, 3D NAND flash memory, NOR flash memory, etc.]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the memory management of Sharon into the NVMe switch handling of NVMe storage access commands of Furey, NVMe-WG, Frolikov for the benefit of having a NVM storage device to determine a relationship between namespaces and utilize the relationship when selecting an open memory block for the storage of data in order to increase operational performance and reduce wear-leveling operations on non-volatile memory (Sharon, 0005).
As per Claim 10, the rejection of claim 1 is incorporated and Furey, NVMe-WG, Frolikov, Sharon disclose,
performing a prior step of establishing a trust boundary via an authentication operation that includes the client device, the bridge device and the target devices (NVMe-WG, [Pg. 372 – Fig. 432 shows the TLS secure channel establishment]; [Pg. 377 - Fig. 443 shows the DH-HMAC-CHAP authentication transaction]; [Pg. 374, Sec. 8.13.4.1 - The AUTH_Negotiate message is sent from the host to the controller/bridge to indicate the authentication protocol and secure channel protocol the host is able to use in the authentication transaction]; [Pg. 385, Sec. 8.13.5.7:DH-HMAC-CHAP Security Requirements - In order to authenticate with the DH-HMAC-CHAP protocol, each host or controller uses a DH-HMACCHAP key that is associated with the entity’s NQN. Each host and NVM subsystem support: transforming the provided secret into a key applying the HMAC function and using the provided secret as a key. See further details in the above cited section of the NVMe spec]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the fabrics authentication of NVMe-WG into the NVMe switch of Furey, Frolikov, Sharon for the benefit of Fabrics Command Set commands which are used for operations specific to NVMe over Fabrics including establishing a connection, NVMe in-band authentication, and to get or set a property (NVMe-WG, Pg. 17, Para-3).
As per Claim 11, Furey discloses an apparatus (Furey, [0030]; [0042 - Fig. 6 shows an NVMe switch 106 for providing various storage services to a host/client while reducing a need for the host to manage solid state devices/SSDs/JBOF/Just a bunch of flash; Here each flash device includes NVM chips and a separate controller]) comprising:
the bridge controller configured to, responsive to a request from the client device (Furey, [0022 – In Fig. 2, at step 202, a first storage access command such as an NVMe store command is received from the host/client]) for a selected capacity memory (Furey, [0027 - The management processor allows associating a capacity to the VD or maximum available storage. The NVMe switch performs storage operations requested by the host, but if the storage operation exceeds the capacity of the VD, the management processor indicates an error to the host, thereby implying that the received allocation request from the client has a first selected capacity corresponding to the unitary namespace as required by Para-0082 of the spec]), present a unitary namespace to the client device as an available memory store for the client device (Furey, [0027 - The NVMe switch advertises the virtual namespaces to the host/client with namespace IDs/NSIDs. The host uses the NSID to obtain access to the namespace]; [0027 - Management processor 112 of the NVMe switch has an offset table which associates virtual namespaces with different memory offsets in the single namespace]) by performing an initial processing operation comprising authenticating at least a selected number of the data storage