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 . This is in reply to papers filed on 2/4/2025. Claims 1-20 are pending. Claims 1, 18, and 20 are independent.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 1/29/2025 and 2/4/2025 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 is/are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-16 of U.S. Patent No. 11,580,034. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-16 of U.S. U.S. Patent No. 11,580,034 anticipates the claims of the present application.
Claims 1-20 is/are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 3-20 of U.S. Patent Application No. 18/168350. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1 and 3-20 of U.S. Patent Application No. 18/168350 anticipates the claims of the present application.
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 2-10 is/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 pre-AIA the applicant regards as the invention.
Claim 2 recites “each storing a crypto key” However, it is unclear whether a crypto key is referring to the crypto key previously introduced in Claim 1 or introducing a new crypto key. Examiner suggests amending to recite each storing a respective crypto key.
Claim 3 recites “the registers”. However, there is no antecedent basis for the registers. There appears to be a typographical error in claim 3 in that claim 3 appears to incorrectly depend from claim 1, and for compact prosecution claim 3 is interpreted to depend from claim 2 based on required antecedent basis for the registers.
Claim 10 recites ”the key pair”. However, there is no antecedent basis for the key pair.
The dependent claims inherit the limitations of their respective independent claims and are rejected for the same reasons as their respective independent claim.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 11-15 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hashimoto et al. U.S. Publication 20160110295 (hereinafter “Hashimoto”) in view of Dewitt et al. U.S. Publication 20170351431 (hereinafter “Dewitt”).
As per claim 1, Hashimoto discloses
A computer storage device, comprising: [storage system 120, figure 2, 3:41]
a host interface; [communication interface 122, 4:34-35, I/F 122 figure 2] a controller; [controller 130, figure 2; 5:36; 4:34 ] non-volatile storage media; [storage media 125, figure 2; 4:36]
limit a crypto key [access key appended to I/O commands para. 21;] to be used in data access requests [accesses the namespace using an access key for the namespace , para. 21; the access key included in the access request, para. 28; ] made in a first namespace allocated on the non-volatile storage media of the computer storage device;
store data[writing data to the indicated physical block addresses, para. 28; encrypting data to be written, para. 28] in the first namespace [converting virtual block addresses (received with the write command) to physical block addresses using mapping of namespace identification code to write to the target namespace, para. 28] in an encrypted form corresponding [uses the hashed access key as an encryption key for encrypting data to be written, para. 28] to the crypto key;
Hashimoto [0021] According to some embodiments, a host computer issuing an IO to a particular namespace accesses the namespace using an access key for the namespace1, which is created when the host computer is initially given access to the namespace by storage system 120. The host computer may temporarily retain this access key in memory or may request users to enter the access key each time the access key is needed. The host computer appends the access key to an IO issued to storage system 120 that targets the namespace corresponding to the access key. It should be recognized that a host computer may be given access to more than one namespace. Thus, hosts 101, 102, and 103 may each include one or more access keys for one or more of namespaces NS1-NS4. For example, key 1 provides host 101 with read-write access to namespace NS1; key 2 provides host 101 with read-write access to namespace NS3; key 3 provides a host with read-write access to namespace NS1; and key 4 provides a host with read-only access to namespace NS4.
Hashimoto [0028] In operation, namespace controller 132 is configured to receive a request from one of hosts 101, 102, or 103 for access to one of namespaces NS1, NS2, NS3, or NS4. For example, the request may be a read command or a write command, and in some embodiments includes a namespace identification code that corresponds to the targeted namespace, an access key to get an authentication to access the namespace (e.g., key 1, key 2, etc.) and one or more virtual block addresses, such as an LBA range. Namespace controller 132 is further configured to convert the one or more virtual block addresses to physical block addresses of storage media 125 using a mapping associated with the namespace identification code. For example, in some embodiments namespace controller 132 is configured to consult one of mappings 201-204 for the namespace that corresponds to the namespace identification code and the access key included in the access request. The consulted mapping indicates which physical block addresses of storage media 125 correspond to the one or more virtual block addresses or LBAs included in the access request. Namespace controller 132 then accesses the physical block addresses indicated by the appropriate mapping 201-204 by either reading data from the indicated physical block addresses or writing data to the indicated physical block addresses. In embodiments in which encrypted data are stored, namespace controller 132 uses the hashed access key as an encryption key for encrypting data to be written to and decrypting data read from storage media 125. In addition data to be encrypted and data to be decrypted are temporarily stored in data buffer 134
para. 30 controller 130 creates an encryption key using the access key extracted in step 302
[0042] When access request 603 is a write 10, storage system 420 buffers the data to be written in data buffer 134 for namespace NS2, hashes access key 602 to create an encryption key, and encrypts the data to be written with encrypt/decrypt engine 124 using the encryption key. The encrypted data are then written to the appropriate PBAs in namespace NS2.
Hashimoto also discloses dynamically adjusting the size of the namespace
para. 24 one or more of namespaces NS1, NS2, NS3, and NS4 can be dynamically sized, and therefore are not fixed in size.
However, Hashimoto does not expressly disclose
firmware containing instructions which, when executed by the controller, instruct the controller to at least:
free a portion of the non-volatile storage media from the first namespace, the portion storing the data; and
make the portion of the non-volatile storage media available in a second namespace.
Dewitt discloses
firmware [firmware, para. 53, 54; instructions, para. 5] containing instructions which, when executed by the controller, instruct the controller [controller 12, para. 17] to at least:
[techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof; para. 53
functionality associated with one or more modules or units may be performed by separate hardware, firmware, or software components, para. 54]
[0005] In another example, a non-transitory computer-readable storage medium encoded with instructions that, when executed, cause one or more processors of a storage device to receive, from a host device, a command to resize a first namespace of a plurality of namespaces stored in a non-volatile memory device of the storage device.
[0017] Storage device 6 may provide host device 4 with access to data stored in namespaces 34. Storage device 6 may include controller 12, first cache 16, second cache 18, and non-volatile memory device 14. Controller 12 may represent one of or a combination of one or more of a microprocessor,
[Also See Para. 16, processing unit configured by way of software instructions, microcode, firmware, or the like.]
Dewitt also discloses reassigning storage space from a first namespace to another namespace without losing data by dynamically adjusting the sizes of the namespaces
[0033] In response to relocating the physical block address, namespace module 20 may update a mapping in namespace table 32. For example, in response to namespace module 20 adding a quantity of index values to namespace 34A in virtual to physical table 30, namespace module 20 may update namespace table 32 to point to a new initial index value of namespace 34B. For instance, in response to namespace module 20 adding a quantity of 5 index values to namespace 34A in virtual to physical table 30, namespace module 20 may map, in namespace table 32, namespace 34B to an updated initial index value (e.g., 25) that is 5 index values higher than an initial index value (e.g., 20).
Dewitt [0034] Similarly, in response to namespace module 20 reducing namespace 34A by a quantity of index values in virtual to physical table 30, namespace module 20 may update namespace table 32 to point to a new initial index value of namespace 34B. For instance, in response to namespace module 20 reducing a quantity of index values to namespace 34A in virtual to physical table 30 by 5 index values, namespace module 20 may map, in namespace table 32, namespace 34B to an updated initial index value (e.g., 15) that is 5 index values lower than an initial index value (e.g., 20). In this manner, namespace module 20 may update a mapping of namespace table 32 to permit resizing a namespace without data loss.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Hashimoto with the technique for reassigning storage space from a first namespace to another namespace without losing data by dynamically adjusting the sizes of the namespaces of Dewitt to include
firmware containing instructions which, when executed by the controller, instruct the controller to at least:
free a portion of the non-volatile storage media from the first namespace, the portion storing the data; and
make the portion of the non-volatile storage media available in a second namespace.
One of ordinary skill in the art would have made this modification to improve the ability of the system to dynamically reassign storage space between namespaces and modify the size of the namespaces without losing data. The system of the primary reference can be modified to allow dynamically reassigning a storage space to another namespace without deleting the data that is stored at the storage space.
As per claim 11, the rejection of claim 1 is incorporated herein.
Hashimoto discloses wherein the instructions are further configured to instruct the controller to:
store a namespace map [virtual to physical table 30, para. 32; Mappings 201-204 , para. 24; multiple mappings, para. 27; mapping data structure, para. 30] mapping [namespace is defined by a set of logical block addresses that map to physical block addresses of storage locations , para. 17]blocks of logical addresses defined in the first namespace to blocks of logical addresses [physical block addresses of storage locations , para. 17]defined, independent of namespace, on a capacity of the non-volatile storage media;
wherein the crypto key is limited [selects one of mappings 201-204 associated with the access key , para. 27] authenticates the association between the namespace identification code and the access key (e.g., mapping 201), para. 30; limited to be used with the namespace map in accessing the non-volatile storage media is disclosed because only with the properly authenticated access key can the mapping data structure lookup be performed, para. 30] to be used with the namespace map in accessing the non-volatile storage media.
Hashimoto [0017] Each namespace is defined by a set of logical block addresses that map to physical block addresses of storage locations in the shared storage resource, where each physical block address in the shared storage resource is allocated to no more than a single namespace. To access a particular physical block address in the shared storage resource, a host issues a command to the data storage device that includes a namespace identification code that corresponds to a targeted namespace and an access key for authentication to access the namespace. The access key indicates the host has been previously granted access to the namespace to which the particular physical data block address is allocated. Without the access key for a namespace, a host that has not been granted access to the namespace cannot access any physical block addresses allocated to that namespace.
Para. 24 Mappings 201-204 each map logical block addresses of namespaces NS1-NS-4 to PBAs of storage locations within storage media 125, respectively.
[0027] Controller 130 includes a hashing module 131, a namespace controller 132, multiple mappings 201-204 (one for each of namespaces NS1-N … Namespace controller 132 examines the access key appended to an IO and selects one of mappings 201-204 associated with the access key
[0030] As shown, a method 300 begins at step 301, where controller 130 of storage system 120 receives an IO from a host computer, (e.g., host 101). In step 302, controller 130 extracts a namespace identification code and an access key from the 10. In step 303, controller 130 retrieves a mapping data structure associated with the namespace identification code when the controller 130 authenticates the association between the namespace identification code and the access key (e.g., mapping 201). In step 304, controller 130 performs LBA to PBA translation using the mapping retrieved in step 303
As per claim 12, the rejection of claim 1 is incorporated herein.
However, Hashimoto does not expressly disclose wherein the portion of the non-volatile storage media storing the data is freed from the first namespace in response to a command to reduce a size of the first namespace.
Dewitt discloses wherein the portion of the non-volatile storage media storing the data is freed [reduce a quantity of physical block addresses of a set of contiguous index values for namespace 34A by shifting down namespace, para. 32; index values subtracted (e.g. 5) from namespace 34A, para. 32] from the first namespace in response to a command to reduce [receive a command from host device 4 instructing namespace module 20 to reduce a quantity of physical block addresses of a first set of contiguous index values for namespace 34A., para. 32] a size of the first namespace.
Dewitt [0032] Similarly, namespace module 20 may receive a command from host device 4 instructing namespace module 20 to reduce a quantity of physical block addresses of a first set of contiguous index values for namespace 34A. For instance, namespace module 20 may reduce a quantity of physical block addresses of a set of contiguous index values for namespace 34A by shifting down namespace 34B in virtual to physical table 30. More specifically, namespace module 20 may move the set of index values for namespace 34B toward the set of index values for namespace 34A in virtual to physical table 30 by the number of index values subtracted from namespace 34A of virtual to physical table 30. For instance, namespace module 20 may shift the set of index values (e.g., 20 to 49) for namespace 34B down (e.g., migrating each physical block address downward in virtual to physical table 30 to correspond with a lower index value) to a second set of index values (e.g., 15 to 44) in virtual to physical table 30 by the number of index values subtracted (e.g. 5) from namespace 34A.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Hashimoto with the technique for reducing the size of a namespace responsive to a command of Dewitt to include wherein the portion of the non-volatile storage media storing the data is freed from the first namespace in response to a command to reduce a size of the first namespace.
One of ordinary skill in the art would have made this modification to improve the ability of the system to dynamically adjust the size of a namespace such as by reducing the size of namespace, and to allow a party to request the reduction of the namespace size. The system of the primary reference can be modified to reduce mappings to physical block addresses for a namespace that has been reduced in size according to a command received.
As per claim 13, the rejection of claim 1 is incorporated herein.
However, Hashimoto does not expressly disclose wherein the portion of the non-volatile storage media storing the data is freed in response to an adjustment in the namespace map.
Dewitt discloses wherein the portion of the non-volatile storage media storing the data is freed [reduce a quantity of physical block addresses of a set of contiguous index values for namespace 34A by shifting down namespace, para. 32; index values subtracted (e.g. 5) from namespace 34A, para. 32; in Dewitt when physical addresses/index values are removed from a namespace then the storage space corresponding to those physical addresses/index values are freed from that namespace] in response to an adjustment[move the set of index values for namespace 34B toward the set of index values for namespace 34A in virtual to physical table 30 by the number of index values subtracted from namespace 34A of virtual to physical table 30, para. 32] in the namespace map.[ virtual to physical table 30, para. 32]
Dewitt [0032] Similarly, namespace module 20 may receive a command from host device 4 instructing namespace module 20 to reduce a quantity of physical block addresses of a first set of contiguous index values for namespace 34A. For instance, namespace module 20 may reduce a quantity of physical block addresses of a set of contiguous index values for namespace 34A by shifting down namespace 34B in virtual to physical table 30. More specifically, namespace module 20 may move the set of index values for namespace 34B toward the set of index values for namespace 34A in virtual to physical table 30 by the number of index values subtracted from namespace 34A of virtual to physical table 30. For instance, namespace module 20 may shift the set of index values (e.g., 20 to 49) for namespace 34B down (e.g., migrating each physical block address downward in virtual to physical table 30 to correspond with a lower index value) to a second set of index values (e.g., 15 to 44) in virtual to physical table 30 by the number of index values subtracted (e.g. 5) from namespace 34A.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Hashimoto with the technique for reducing the size of a namespace responsive to a command of Dewitt to include
wherein the portion of the non-volatile storage media storing the data is freed in response to an adjustment in the namespace map.
One of ordinary skill in the art would have made this modification to improve the ability of the system to dynamically adjust the size of a namespace such as by reducing the size of namespace, and to allow a party to request the reduction of the namespace size, thereby freeing the storage space corresponding to the physical addresses that are no longer mapped to the namespace. The system of the primary reference can be modified to reduce mappings to physical block addresses for a namespace that has been reduced in size according to a command received, thereby freeing up the storage space corresponding to the physical block addresses
.
As per claim 14, the rejection of claim 13 is incorporated herein.
Hashimoto discloses
wherein before the adjustment: the portion of the non-volatile storage media [this is referring to the freed portion from claim 13] is identified by a first subset of the logical addresses defined, independent of namespace,[ Each namespace is defined by a set of logical block addresses that map to physical block addresses of storage locations in the shared storage resource, para. 17; first subset of the logical addresses defined, independent of namespace can be disclosed by a subset of the Hashimoto physical block addresses that is removed from a namespace] on the capacity of the non-volatile storage media; and
the namespace map[virtual to physical table 30, para. 32; Mappings 201-204 , para. 24; multiple mappings, para. 27; mapping data structure, para. 30; the purpose of any of these Hashimoto mappings is to provide mapping from addresses within the namespace to the physical block addresses] maps a subset of the logical addresses defined in the first namespace to the first subset of the logical addresses defined on the capacity of the non-volatile storage media.[ Para. 24 provides one example of namespace address to physical block address mapping: “Mappings 201-204 each map logical block addresses of namespaces NS1-NS-4 to PBAs of storage locations within storage media 125, respectively.”; in Hashimoto, addresses for the first namespace would be mapped to the physical block addresses of storage locations thereby disclosing maps a subset of the logical addresses defined in the first namespace to the first subset…]
Hashimoto [0017] Each namespace is defined by a set of logical block addresses that map to physical block addresses of storage locations in the shared storage resource, where each physical block address in the shared storage resource is allocated to no more than a single namespace. To access a particular physical block address in the shared storage resource, a host issues a command to the data storage device that includes a namespace identification code that corresponds to a targeted namespace and an access key for authentication to access the namespace. The access key indicates the host has been previously granted access to the namespace to which the particular physical data block address is allocated. Without the access key for a namespace, a host that has not been granted access to the namespace cannot access any physical block addresses allocated to that namespace.
[0027] Controller 130 includes a hashing module 131, a namespace controller 132, multiple mappings 201-204 (one for each of namespaces NS1-N … Namespace controller 132 examines the access key appended to an IO and selects one of mappings 201-204 associated with the access key
[0030] As shown, a method 300 begins at step 301, where controller 130 of storage system 120 receives an IO from a host computer, (e.g., host 101). In step 302, controller 130 extracts a namespace identification code and an access key from the 10. In step 303, controller 130 retrieves a mapping data structure associated with the namespace identification code when the controller 130 authenticates the association between the namespace identification code and the access key (e.g., mapping 201). In step 304, controller 130 performs LBA to PBA translation using the mapping retrieved in step 303
As per claim 15, the rejection of claim 14 is incorporated herein.
However, Hashimoto does not expressly disclose wherein after the adjustment, the subset of the logical addresses previously defined in the first namespace is no longer defined in the first namespace.
Dewitt discloses wherein after the adjustment, the subset of the logical addresses previously defined in the first namespace is no longer defined in the first namespace. [reduce a quantity of physical block addresses of a set of contiguous index values for namespace 34A by shifting down namespace, para. 32; index values subtracted (e.g. 5) from namespace 34A, para. 32]
Dewitt [0032] Similarly, namespace module 20 may receive a command from host device 4 instructing namespace module 20 to reduce a quantity of physical block addresses of a first set of contiguous index values for namespace 34A. For instance, namespace module 20 may reduce a quantity of physical block addresses of a set of contiguous index values for namespace 34A by shifting down namespace 34B in virtual to physical table 30. More specifically, namespace module 20 may move the set of index values for namespace 34B toward the set of index values for namespace 34A in virtual to physical table 30 by the number of index values subtracted from namespace 34A of virtual to physical table 30. For instance, namespace module 20 may shift the set of index values (e.g., 20 to 49) for namespace 34B down (e.g., migrating each physical block address downward in virtual to physical table 30 to correspond with a lower index value) to a second set of index values (e.g., 15 to 44) in virtual to physical table 30 by the number of index values subtracted (e.g. 5) from namespace 34A.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Hashimoto with the technique for reducing the size of a namespace responsive to a command of Dewitt to include wherein after the adjustment, the subset of the logical addresses previously defined in the first namespace is no longer defined in the first namespace.
One of ordinary skill in the art would have made this modification to improve the ability of the system to dynamically adjust the size of a namespace such as by reducing the size of namespace, and to allow a party to request the reduction of the namespace size. The system of the primary reference can be modified to reduce mappings to physical block addresses for a namespace that has been reduced in size according to a command received. After the mapping reduction, the addresses that were previously defined for a namespace are no longer defined for the namespace.
As per claim 18, the claim(s) is/are directed to a method with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 1.
Claim 18 also recites A method [Figure 3, the depicted method; para. 17, 29] implemented in a computer storage device [storage system, para. 12; element 120, figure 2, the method comprising:
[0017] Embodiments provide systems and methods for robust security when sharing storage resources in a distributed computing system.
As per claim 19, the rejection of claim 18 is incorporated herein.
However, Hashimoto does not expressly disclose wherein the freeing is in response to a command to reducing a size of the first namespace.
Dewitt discloses wherein the freeing d [reduce a quantity of physical block addresses of a set of contiguous index values for namespace 34A by shifting down namespace, para. 32; index values subtracted (e.g. 5) from namespace 34A, para. 32] is in response to a command to reducing a size of the first namespace [receive a command from host device 4 instructing namespace module 20 to reduce a quantity of physical block addresses of a first set of contiguous index values for namespace 34A., para. 32].
Dewitt [0032] Similarly, namespace module 20 may receive a command from host device 4 instructing namespace module 20 to reduce a quantity of physical block addresses of a first set of contiguous index values for namespace 34A. For instance, namespace module 20 may reduce a quantity of physical block addresses of a set of contiguous index values for namespace 34A by shifting down namespace 34B in virtual to physical table 30. More specifically, namespace module 20 may move the set of index values for namespace 34B toward the set of index values for namespace 34A in virtual to physical table 30 by the number of index values subtracted from namespace 34A of virtual to physical table 30. For instance, namespace module 20 may shift the set of index values (e.g., 20 to 49) for namespace 34B down (e.g., migrating each physical block address downward in virtual to physical table 30 to correspond with a lower index value) to a second set of index values (e.g., 15 to 44) in virtual to physical table 30 by the number of index values subtracted (e.g. 5) from namespace 34A.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Hashimoto with the technique for reducing the size of a namespace responsive to a command of Dewitt to include wherein the freeing is in response to a command to reducing a size of the first namespace
One of ordinary skill in the art would have made this modification to improve the ability of the system to dynamically adjust the size of a namespace such as by reducing the size of namespace, and to allow a party to request the reduction of the namespace size. The system of the primary reference can be modified to reduce mappings to physical block addresses for a namespace that has been reduced in size according to a command received.
As per claim 20, the claim(s) is/are directed to a computer storage medium with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 1.
Claim 20 also recites A non-transitory computer storage medium storing instructions which, when executed by a controller of a computer storage device, cause the controller to perform a method, the method comprising:
Hashimoto discloses to perform a method, [Figure 3, the depicted method; para. 17, 29] the method comprising:
[0017] Embodiments provide systems and methods for robust security when sharing storage resources in a distributed computing system.
However, Hashimoto does not expressly disclose
A non-transitory computer storage medium storing instructions which, when executed by a controller of a computer storage device, cause the controller to perform a method, the method comprising:
Dewitt discloses
A non-transitory computer storage medium storing instructions [a non-transitory computer-readable storage medium encoded with instructions, para 5] which, when executed by a controller of a computer storage device [storage device 6, figure 1], cause the controller [controller 12, para. 17]
[techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof; para. 53
functionality associated with one or more modules or units may be performed by separate hardware, firmware, or software components, para. 54]
[0005] In another example, a non-transitory computer-readable storage medium encoded with instructions that, when executed, cause one or more processors of a storage device to receive, from a host device, a command to resize a first namespace of a plurality of namespaces stored in a non-volatile memory device of the storage device.
[Also See Para. 16, processing unit configured by way of software instructions, microcode, firmware, or the like.]
Dewitt [0017] Storage device 6 may provide host device 4 with access to data stored in namespaces 34. Storage device 6 may include controller 12, first cache 16, second cache 18, and non-volatile memory device 14. Controller 12 may represent one of or a combination of one or more of a microprocessor,
Claim 2-4 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hashimoto in view of Dewitt, further in view of Nachenberg et al. U.S. Publication 20180165470 (hereinafter “Nachenberg”).
As per claim 2, the rejection of claim 1 is incorporated herein.
Hashimoto discloses storing a crypto key and configured to be limited with data access in only one namespace.
Hashimoto [0004] the security of data stored in an LBA range of the data storage device is limited to how securely the access key for that LBA range is stored
[0036] In operation, hypervisor 451 receives a key request from one of virtual machines VM1-VM4 for access to one of namespaces NS1-NS4 in storage system 420, authenticates the virtual machine and provides the appropriate access key to the virtual machine.
[0035] Hypervisor 451 uses key management module 452 to generate the namespace identification code included in completion notification 504 and to maintain the access keys in association with the namespace identification codes for the namespaces. In this way, a virtual machine in computing system 400 can only access a namespace in storage system 420 if the virtual machine knows the namespace identification code of the namespace and is authenticated by the hypervisor 451 to access the access key.
However, the combination of Hashimoto and Dewitt does not expressly disclose a plurality of registers each storing a crypto key and configured to be limited with data access in only one namespace.
[plurality of registers is interpreted as any collection of storage locations for storing keys. This is supported by the specification at para. 216 “[0216]… a storage device can be configured with a register file that has the capacity to hold a predetermined number of crypto keys”]
Nachenberg discloses a key store storing multiple individually accessible keys.
[the storage locations of the individual keys in the key store discloses plurality of registers each storing]
[0005] The secure hardware unit may include a key store that stores multiple encryption keys including the first encryption key;
[0042] The decryption unit 166 further retrieves the system encryption key K2 from the key store 172 based on the identifier UIDK2 provided by the database management system 140. A
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hashimoto and Dewitt with the technique for a key store storing multiple individually accessible keys of Nachenberg to include
a plurality of registers each storing a crypto key and configured to be limited with data access in only one namespace.
One of ordinary skill in the art would have made this modification to improve the ability of the system to store multiple keys and to access each individual key. The system of the primary reference can be modified to include a key store accessible to the Hashimoto key management module.
As per claim 3, the rejection of claim 2 is incorporated herein.
[There appears to be a typographical error in claim 3 (“of claim 1”), and for compact prosecution claim 3 is interpreted to depend from claim 2 based on required antecedent basis for the registers ]
Hashimoto discloses a crypto engine [Encrypt/decrypt engine 124 and key management module 452 combined, para. 25, para. 34] to perform decryption using [the decryption key is generated based on the access key ] the crypto key for data access made in the first name space.[Receiving request to read from a target namespace, para. 28]
[0025] Encrypt/decrypt engine 124 is configured to encrypt data stored in storage media 125 and decrypt data retrieved from storage media 125. The encrypt/decrypt engine 124 encrypts data using encryption key which corresponds to an access key and decrypts data using decryption key which corresponds to an access key. In some embodiments, encrypt/decrypt engine 124 is configured to receive an access key from controller 130 (described below), hashes the access key, and uses the hashed access key as an encryption key (a media encryption key, MEK) for performing encryption and decryption. …. For read operations, media controller 125A reads encrypted data from storage media 125 and transmits the encrypted data to encrypt/decrypt engine 124 for decryption.
[0028] In operation, namespace controller 132 is configured to receive a request from one of hosts 101, 102, or 103 for access to one of namespaces NS1, NS2, NS3, or NS4. For example, the request may be a read command or a write command, and in some embodiments includes a namespace identification code that corresponds to the targeted namespace, an access key to get an authentication to access the namespace (e.g., key 1, key 2, etc.) …Namespace controller 132 then accesses the physical block addresses indicated by the appropriate mapping 201-204 by either reading data from the indicated physical block addresses or writing data to the indicated physical block addresses. In embodiments in which encrypted data are stored, namespace controller 132 uses the hashed access key as an encryption key for encrypting data to be written to and decrypting data read from storage media 125. In addition data to be encrypted and data to be decrypted are temporarily stored in data buffer 134
However, the combination of Hashimoto and Dewitt does not expressly disclose a crypto engine coupled to the registers to perform decryption using the crypto key for data access made in the first name space.
[the registers is interpreted as any collection of storage locations for storing keys. This is supported by the specification at para. 216 “[0216]… a storage device can be configured with a register file that has the capacity to hold a predetermined number of crypto keys”]
Nachenberg discloses a key store storing multiple individually accessible keys.
[the storage locations of the individual keys in the key store discloses the registers]
[0005] The secure hardware unit may include a key store that stores multiple encryption keys including the first encryption key;
[0042] The decryption unit 166 further retrieves the system encryption key K2 from the key store 172 based on the identifier UIDK2 provided by the database management system 140. A
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hashimoto and Dewitt with the technique for a key store storing multiple individually accessible keys of Nachenberg to include
a crypto engine coupled to the registers to perform decryption using the crypto key for data access made in the first name space.
One of ordinary skill in the art would have made this modification to improve the ability of the system to store multiple keys and to access each individual key. The system of the primary reference can be modified to include a key store accessible to the Hashimoto key management module.
As per claim 4, the rejection of claim 3 is incorporated herein.
Hashimoto discloses wherein the crypto key is generated [key management module 452 generates an access key for the namespace being created and includes the access key in namespace creation command 502, para. 34] by the crypto engine [Encrypt/decrypt engine 124 and key management module 452 combined, para. 25, para. 34] in response[when the Hashimoto hypervisor sends the namespace creation command, the Hashimoto key management module generates the access key, para. 34] to a command to allocate [sends a namespace creation command 502 to storage system 420, para. 34] the first namespace on the non-volatile storage media.
[0034] hypervisor 451 sends a namespace creation command 502 to storage system 420. In some embodiments, key management module 452 generates an access key for the namespace being created and includes the access key in namespace creation command 502.
[0044]…, storage system 420 may be directly connected to the host computer(s) and may serve as a dedicated storage device for the host computer(s).
As per claim 6, the rejection of claim 3 is incorporated herein.
Hashimoto discloses wherein the crypto key is received [“key management module 452 generates an access key for the namespace being created and includes the access key in namespace creation command 502”, para. 34; storage system 420 receives access key in Hashimoto, para. 34] for the first namespace in connection with a command to allocate [sends a namespace creation command 502 to storage system 420, para. 34] the first namespace on the non-volatile storage media.
[0034] FIG. 5 … hypervisor 451 sends a namespace creation command 502 to storage system 420. In some embodiments, key management module 452 generates an access key for the namespace being created and includes the access key in namespace creation command 502.
[0044]…, storage system 420 may be directly connected to the host computer(s) and may serve as a dedicated storage device for the host computer(s).
Claim 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hashimoto in view of Dewitt, in view of Nachenberg, further in view of Lockhart et al. Canadian Publication CA 2684229 A1 (hereinafter “Lockhart”).
As per claim 5, the rejection of claim 4 is incorporated herein.
Hashimoto discloses to perform a cryptographic erasure of data stored in the first namespace in response to a command to delete the namespace.
[0034] FIG. 5 is a … A procedure similar to that illustrated in sequence diagram 500 may be used to delete namespace NS2 from storage system 420 when requested by virtual machine VM1.
However, the combination of Hashimoto, Dewitt, and Nachenberg does not expressly disclose wherein the crypto key is deleted from the computer storage device to perform a cryptographic erasure of data stored in the first namespace in response to a command to delete the namespace.
Lockhart discloses deleting a key that is no longer required
[0240] Key Zeroed (state 7): The Zeroed state denotes a key that is up for removal from the system.
[0241 ] Key Zeroed Compromised (state 8): This state denotes keys that were compromised then destroyed or destroyed and then discovered to be compromised.
[0242] Key Purged (state 9): When the key record (metadata) is no longer required it may be purged by the system to release the SO_GUID and Record ID for reuse. Only the zeroed key and the associated metadata are deleted. All logged information about the key must still be maintained.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hashimoto, Dewitt, and Nachenberg with the technique for deleting a key that is no longer required of Lockhart to include wherein the crypto key is deleted from the computer storage device to perform a cryptographic erasure of data stored in the first namespace in response to a command to delete the namespace.
One of ordinary skill in the art would have made this modification to improve the ability of the system to release system resources when a key is no longer required. The system of the primary reference can be modified to delete a key that is no longer required.
Claim 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hashimoto in view of Dewitt, in view of Nachenberg, further in view of Singhai et al. U.S. Publication 20180025046 (hereinafter “Singhai”).
As per claim 7, the rejection of claim 3 is incorporated herein.
Hashimoto discloses generating a key for encrypting and/or decrypting from the access key (para. 25, 28, 43) but does not clearly explicitly describe symmetric encryption using the access key.
However, the combination of Hashimoto, Dewitt, and Nachenberg does not expressly disclose wherein the crypto engine implements symmetric encryption using the crypto key.
Singhai discloses wherein the crypto engine[encryption unit 204] implements symmetric encryption using the crypto key.
[0021] FIG. 9 is a flow chart of an example method for constructing a namespace reference set.
[0056] The encryption unit 204, in one implementation, encrypts data blocks associated with a data stream and/or compressed data stream responsive to instructions received from the command queue unit 202. For instance, if a user elects for encrypting data associated with user financials, while opting out from encrypting data associated with general data files (e.g. documents available to public, such as, magazines, newspaper articles, pictures, etc.), the command queue unit 202 receives instructions as to which file to encrypt and provides them to the encryption unit 204. In further implementations, the encryption unit 204 encrypts a data stream and/or compressed data stream based on encryption algorithms. An encryption algorithm can be user defined and/or known-encryption algorithms such as, but not limited to, hashing algorithms, symmetric key encryption algorithms, and/or public key encryption algorithms. In other implementations, the encryption unit 204 may transmit the encrypted data stream to data reduction unit 206 to perform its acts and/or functionalities thereon.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hashimoto, Dewitt, and Nachenberg with the technique for implementing symmetric key encryption of Singhai to include wherein the crypto engine implements symmetric encryption using the crypto key.
One of ordinary skill in the art would have made this modification to improve the efficiency of encrypting data, since symmetric encryption is simpler than asymmetry encryption, and thus has lower computational overhead and faster encryption and decryption. The system of the primary reference can be modified to utilize symmetric encryption to protect data stored under a namespace.
Claims 8-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hashimoto in view of Dewitt, in view of Nachenberg, further in view of Mityagin et al. U.S. Publication 20150249647 (hereinafter “Mityagin”).
As per claim 8, the rejection of claim 3 is incorporated herein.
Hashimoto discloses wherein the crypto key[access key 602 , para. 42] is received[access request 603 is a read IO or write IO that includes access key 602 , para. 39] from a host for encryption [hashing access key to get encryption key and encrypt using encryption key, para. 42]of data stored in the first namespace.
[0042] When access request 603 is a write 10, storage system 420 buffers the data to be written in data buffer 134 for namespace NS2, hashes access key 602 to create an encryption key, and encrypts the data to be written with encrypt/decrypt engine 124 using the encryption key. The encrypted data are then written to the appropriate PBAs in namespace NS2.
[0038] At time t2, hypervisor 451 consults key management module 452 (shown in FIG. 4) to retrieve the appropriate access key and sends said access key 602 to virtual machine VM1.
[0039] At time t3 virtual machine VM1 sends an access request 603 to storage system 420. In some embodiments, access request 603 is a read IO or write IO that includes access key 602
However, the combination of Hashimoto, Dewitt, and Nachenberg does not expressly disclose wherein the crypto key is a public key for non-symmetric encryption and is received from a host for encryption of data stored in the first namespace.
Mityagin discloses a public key for non-symmetric encryption
[0068] when client device 102.sub.1 is given the privilege to access contents of a shared folder with a namespace identifier 0x07, then content management system may generate a corresponding namespace key (e.g., 0xCE) for the shared folder and distribute the namespace key to client device 102.sub.1 in a secure manner. The next time client device 102.sub.1 sends a synchronization request to content management system 106, content management system 106 can authenticate client device's 102.sub.1 access privilege by verifying the namespace key value that is provided by client device 102.sub.1. On the other hand, client device 102.sub.3, which may lack the namespace key for the shared folder, cannot access or synchronize the shared folder because it .
[0069] Alternatively, namespace keys 304 may contain more sophisticated security instruments such as a public-private key pair (e.g., RSA) or a client certificate (e.g., X.509 public key infrastructure). In such scenarios, the contents of the shared folders can be encrypted with a public key certified by a public key certificate. In order to access any contents in the shared folder, each client device 102.sub.i may have to use the private key embedded in the given namespace key to decode any encrypted messages. Such namespace keys 304 can also be used for authentication purposes. For instance, content management system 106 or client devices 102 can verify another client device's access privilege to a certain shared folder by examining the value of the namespace key corresponding to the folder's namespace identifier.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hashimoto, Dewitt, and Nachenberg with the technique for utilizing public key to encrypt data in the namespace of Mityagin to include wherein the crypto key is a public key for non-symmetric encryption and is received from a host for encryption of data stored in the first namespace.
One of ordinary skill in the art would have made this modification to improve the ability of the system to allow a party requesting access to the data to have more control over their own data because they can provide their own public key, rather than having the public key being controlled by storage. This may be more preferable in some scenarios where the party requesting access requires control over the public key pair. The system of the primary reference can be modified so that the party requesting access to encrypt the data provides the public key.
As per claim 9, the rejection of claim 3 is incorporated herein.
Hashimoto discloses generating a key for encrypting and/or decrypting from the access key (para. 25, 28, 43) but does not describe the access key itself as a non-symmetric encryption key.
However, the combination of Hashimoto, Dewitt, and Nachenberg does not expressly disclose wherein the crypto key is a first key of a key pair for non-symmetric encryption of data stored in the first namespace; and a second key of the key pair of is provided for decryption of data retrieved from the first namespace.
Mityagin discloses wherein the crypto key [public key, para. 69]is a first key of a key pair for non-symmetric encryption of data stored in the first namespace; and a second key [private key, para. 69] of the key pair of is provided for decryption of data retrieved from the first namespace.
[0068] when client device 102.sub.1 is given the privilege to access contents of a shared folder with a namespace identifier 0x07, then content management system may generate a corresponding namespace key (e.g., 0xCE) for the shared folder and distribute the namespace key to client device 102.sub.1 in a secure manner. The next time client device 102.sub.1 sends a synchronization request to content management system 106, content management system 106 can authenticate client device's 102.sub.1 access privilege by verifying the namespace key value that is provided by client device 102.sub.1. On the other hand, client device 102.sub.3, which may lack the namespace key for the shared folder, cannot access or synchronize the shared folder because it .
[0069] Alternatively, namespace keys 304 may contain more sophisticated security instruments such as a public-private key pair (e.g., RSA) or a client certificate (e.g., X.509 public key infrastructure). In such scenarios, the contents of the shared folders can be encrypted with a public key certified by a public key certificate. In order to access any contents in the shared folder, each client device 102.sub.i may have to use the private key embedded in the given namespace key to decode any encrypted messages. Such namespace keys 304 can also be used for authentication purposes. For instance, content management system 106 or client devices 102 can verify another client device's access privilege to a certain shared folder by examining the value of the namespace key corresponding to the folder's namespace identifier.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hashimoto, Dewitt, and Nachenberg with the technique for utilizing public key to encrypt data in the namespace of Mityagin to include wherein the crypto key is a first key of a key pair for non-symmetric encryption of data stored in the first namespace; and a second key of the key pair of is provided for decryption of data retrieved from the first namespace.
One of ordinary skill in the art would have made this modification to improve the ability of the system to allow a party requesting access to the data to have more control over their own data because they can provide their own public key pair to encrypt and decrypt data for the namespace. This may be more preferable in some scenarios where the party requesting access requires control over the public key pair. The system of the primary reference can be modified so that the party requesting access to encrypt the data provides the public key and/or private key for encryption and decryption, respectively.
As per claim 10, the rejection of claim 3 is incorporated herein.
Hashimoto, Dewitt, and Nachenberg discloses wherein the crypto engine generates the key in response to creation of the first namespace on the non-volatile storage media.
[0034] hypervisor 451 sends a namespace creation command 502 to storage system 420. In some embodiments, key management module 452 generates an access key for the namespace being created and includes the access key in namespace creation command 502.
[0044]…, storage system 420 may be directly connected to the host computer(s) and may serve as a dedicated storage device for the host computer(s).
However, the combination of Hashimoto, Dewitt, and Nachenberg does not expressly disclose wherein the crypto engine generates the key pair in response to creation of the first namespace on the non-volatile storage media.
Mityagin discloses generating an encryption key pair when generating a namespace
[0011] For each shared folder on a content management system, the content management system may generate a namespace identifier (ns_id) and name space key (ns_key) pair associated with the shared folder. The content management system may then distribute (ns_id, ns_key) pairs to those client devices that are authorized to access the corresponding shared folders.
[0050] Authenticator module 126 may generate and issue namespace keys to content items and/or shared folders. The namespace keys, also known as shared secret keys, may function as a shared secret for the respective namespace. Accordingly, the namespace keys may be required to access those content items or shared folders. For example, a namespace key may consist of a Rivest-Shamir-Adleman ("RSA") key pair and/or a corresponding client certificate such as a self-signed X.509 certificate. Alternatively, a namespace key may simply be a secret string rather than an RSA key pair.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hashimoto, Dewitt, and Nachenberg with the technique for generating an encryption key pair when generating a namespace of Mityagin to include wherein the crypto engine generates the key pair in response to creation of the first namespace on the non-volatile storage media.
One of ordinary skill in the art would have made this modification to improve the ability of the system to generate a key pair to facilitate asymmetric key encryption using public and private keys, thereby utilizing the advantages of public-key encryption. The system of the primary reference can be modified to generate a key pair for asymmetric encryption when the namespace is created.
Claim 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hashimoto in view of Dewitt, further in view of Nellans et al. U.S. Publication 20120210095 (hereinafter “Nellans”).
As per claim 16, the rejection of claim 14 is incorporated herein.
However, the combination of Hashimoto and Dewitt does not expressly disclose
wherein after the adjustment, the namespace map maps the subset of the logical addresses defined in the first namespace to a second subset of the logical addresses defined, independent of namespace, on the capacity of the non-volatile storage media.
Nellans discloses remapping a logical address within a namespace to another physical storage address
[claim 16 is interpreted as reusing the subset of the logical addresses defined in the first namespace that has been freed (claim 13) from the namespace, by remapping the subset of the logical addresses defined in the first namespace to other storage addresses of the non-volatile storage media.]
Nellans [0091] Typically the solid-state storage controller(s) 104 communicate data to the solid-state storage media 110 over a storage I/O bus 210. In a typical embodiment where the solid-state storage is arranged in banks 214 and each bank 214 includes multiple storage elements 216a, 216b, 216m accessed in parallel, the storage I/O bus 210 is an array of busses, one for each column of storage elements 216, 218, 220 spanning the banks 214. As used herein, the term "storage I/O bus" may refer to one storage I/O bus 210 or an array of data independent busses 204. In one embodiment, each storage I/O bus 210 accessing a column of storage elements (e.g. 216a, 218a, 220a) may include a logical-to-physical mapping for storage divisions (e.g. erase blocks) accessed in a column of storage elements 216a, 218a, 220a. This mapping (or bad block remapping) allows a logical address mapped to a physical address of a storage division to be remapped to a different storage division if the first storage division fails, partially fails, is inaccessible, or has some other problem.
[0204] In one embodiment, the logical-to-physical translation layer 512 includes a map or index, a "forward map," that maps logical block addresses to physical block addresses. Often logical addresses used to identify stored data represent a very small number of logical addresses that are possible within a name space or range of possible logical addresses. Searching this sparsely populated space may be cumbersome. For this reason, the forward map is typically a data structure that facilitates quickly traversing the forward map to find a physical address based on a logical address. For example, the forward map may include a B-tree, a content addressable memory ("CAM"), a binary tree, a hash table, or other data structure that facilitates quickly searching a sparsely populated space or range. By using a forward map that quickly searches a sparsely populated logical namespace or address space, the logical-to-physical translation layer 512 provides an efficient way to determine one or more physical addresses from a logical address.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hashimoto and Dewitt with the technique for remapping a logical address within a namespace to another physical storage address of Nellans to include
wherein after the adjustment, the namespace map maps the subset of the logical addresses defined in the first namespace to a second subset of the logical addresses defined, independent of namespace, on the capacity of the non-volatile storage media.
One of ordinary skill in the art would have made this modification to improve the ability of the system to reuse a limited resource such as the set of namespace addresses. The system of the primary reference can be modified to remap a namespace address that has been freed from mapping to a previous physical address, so that the remapping maps to a different physical address of storage.
As per claim 17, the rejection of claim 16 is incorporated herein.
However, the combination of Hashimoto and Dewitt does not expressly disclose wherein a portion of the non-volatile storage media identified by the second subset of the logical addresses defined on the capacity of the non-volatile storage media is different from the portion of the non-volatile storage media identified by the first subset of the logical addresses defined on the capacity of the non-volatile storage media.
Nellans discloses remapping a logical address within a namespace to another physical storage address
[
when the Nellans remapping is performed, the remapping will point to a new physical address that is different from the previous physical address that was previously mapped to, because that is the very definition of remapping. Remapping to the same previous physical address is no longer a valid option due to the freeing (or unavailability) of the space storage corresponding to the previous physical address]
Nellans [0091] Typically the solid-state storage controller(s) 104 communicate data to the solid-state storage media 110 over a storage I/O bus 210. In a typical embodiment where the solid-state storage is arranged in banks 214 and each bank 214 includes multiple storage elements 216a, 216b, 216m accessed in parallel, the storage I/O bus 210 is an array of busses, one for each column of storage elements 216, 218, 220 spanning the banks 214. As used herein, the term "storage I/O bus" may refer to one storage I/O bus 210 or an array of data independent busses 204. In one embodiment, each storage I/O bus 210 accessing a column of storage elements (e.g. 216a, 218a, 220a) may include a logical-to-physical mapping for storage divisions (e.g. erase blocks) accessed in a column of storage elements 216a, 218a, 220a. This mapping (or bad block remapping) allows a logical address mapped to a physical address of a storage division to be remapped to a different storage division if the first storage division fails, partially fails, is inaccessible, or has some other problem.
Nellans [0204] In one embodiment, the logical-to-physical translation layer 512 includes a map or index, a "forward map," that maps logical block addresses to physical block addresses. Often logical addresses used to identify stored data represent a very small number of logical addresses that are possible within a name space or range of possible logical addresses. Searching this sparsely populated space may be cumbersome. For this reason, the forward map is typically a data structure that facilitates quickly traversing the forward map to find a physical address based on a logical address. For example, the forward map may include a B-tree, a content addressable memory ("CAM"), a binary tree, a hash table, or other data structure that facilitates quickly searching a sparsely populated space or range. By using a forward map that quickly searches a sparsely populated logical namespace or address space, the logical-to-physical translation layer 512 provides an efficient way to determine one or more physical addresses from a logical address.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Hashimoto and Dewitt with the technique for remapping a logical address within a namespace to another physical storage address of Nellans to include
wherein a portion of the non-volatile storage media identified by the second subset of the logical addresses defined on the capacity of the non-volatile storage media is different from the portion of the non-volatile storage media identified by the first subset of the logical addresses defined on the capacity of the non-volatile storage media.
One of ordinary skill in the art would have made this modification to improve the ability of the system to reuse a limited resource such as the set of namespace addresses. The system of the primary reference can be modified to remap a namespace address that has been freed from mapping to a previous physical address, so that the remapping maps to a different physical address of storage.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOWARD H LOUIE whose telephone number is 571-272-0036. The examiner can normally be reached on Monday-Friday 9 AM-5 PM 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, Jung W. Kim can be reached on 571-272-3804. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HOWARD H. LOUIE/Examiner, Art Unit 2494
/THEODORE C PARSONS/Primary Examiner, Art Unit 2494
1 Emphasis is additional throughout.
Prosecution Insights