DETAILED ACTION
This Office Action, based on application 19/002,635, filed in response to applicant’s amendment and remarks filed 29 September 2026. Claims 1-20 are currently pending and have been fully considered below.
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 29 September 2026 has been entered.
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 .
Response to Arguments
Applicant’s remarks, filed 29 September 2026 in response to the Office Action filed 29 June 2026, have been fully considered below.
Claim Rejections under 35 U.S.C. § 103
The applicant traverses the prior art rejection to the claims alleging cited prior art fails to disclose the features of Claim 1. Specifically, the applicant alleges cited prior art fails to disclose the storage structure discovery request as amended. To support applicant’s allegation, the applicant discusses the teachings of GOLE relied upon for teaching the limitation “determining, by a host device, a storage structure of a storage medium of a solid state drive (SSD)” noting the teachings at ¶[0054] describes the host obtaining a location of an on-disk ZNS mapping table; the applicant asserts the location of a mapping table is not the physical organization of a storage medium. In response, the Office asserts the host knowing the location of the mapping table ‘determines’ the mapping table meeting the limitation. The Office further notes GOLE further teaches maintaining the table by the host (e.g. ¶[0055]) providing further evidence GOLE teaches ‘determining’ the table or storage structure. The applicant does not further argue whether GOLE’s on-disk ZNS mapping table is equivalent to applicant’s claimed storage structure; instead, the applicant alleges GOLE does not describe or fairly suggest receiving storage structure information (e.g. identifier of the storage medium) as now recited in the claim. In response to applicant’s amendment and remarks, the Office presents new grounds of rejection in further view of GOODGOLD. While applicant’s amendment includes defining ‘storage structure information’ to include various types of metadata, the Office asserts the claims do not further rely on any particular metadata collected by the host. As such, the Office asserts the additional limitations merely constitute a data gathering step; the Office suggests limiting the claims to include some form of applied use of the gathered metadata as a possible avenue for overcoming the instant obviousness rejection below.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1-4, 6-11, 13-17, 19, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over GOLE et al (US PGPub 2021/0406174) in further view of GARG et al (US PGPub 2025/0021478) and GOODGOLD (US Patent 6,418,512).
With respect to Claim 1, GOLE discloses a method comprising:
determining, by the host device, a storage structure of the storage medium based on the storage structure information (Fig 1, Solid-State Disk (SSD) 110; Fig 3, Step 300; ¶[0054] – “In step 300 in this example, the host FTL 216 of the host computing device 102(1) obtains from the SSD 110 the location of the on-disk ZNS mapping table 128 {‘a storage structure of a storage medium’}”; the location of the on-disk ZNS mapping table meets both “an identifier of the storage medium” and “a physical block address associated with the storage medium” under the broadest reasonable interpretation of those terms; thus, the storage structure is ‘determined’ based on the location or ‘storage structure information’);
determining, by the host device, a physical block address of the physical block addresses to be used by a logical block address based on determining the storage structure (Fig 3, Step 312; ¶[0077] – “In step 312, the host FTL 216 of the host computing device 102(1) identifies an entry in the in-core ZNS mapping table 220 based on a logical address extracted from the write request”; Fig 6 illustrates in-core ZNS mapping table 220(1) mapping logical zones to physical zones; ¶[0084] – “At time T1, the in-core ZNS mapping tables 220(1) and 220(2) have respective entries 608(1) and 608(2) that reflect the mapping or translation of a logical zone number or logical address of ‘101’ to the physical zone number ‘1420’ associated with zone 600”);
generating, by the host device, a logical to physical (L2P) entry that maps the logical block address to the physical block address (Fig 3, Step 310; ¶[0075] – “In step 310, the host FTL 216 of the host computing device 102(1) services the zone open request by selecting a free zone”; ¶[0076] – “The host computing device 102(1) then opens the selected zone for writing and inserts an entry into the in-core ZNS mapping table 220 and the on-disk ZNS mapping table 128”);
storing, by the host device, the L2P entry in an L2P data structure that is stored in a first memory of the host device (Fig 3, Step 310; ¶[0076] – “The host computing device 102(1) then opens the selected zone for writing and inserts an entry into the in-core ZNS mapping table 220 and the on-disk ZNS mapping table 128”; Fig 2 illustrates Memory 202 comprises In-Core ZNS Mapping Table 220),
wherein a copy of the L2P data structure is stored in a second memory of a controller of the SSD (Fig 1 illustrates SSD 110 comprises On-Disk ZNS Mapping Table 128); and
wherein the physical block address and the logical block address are provided to perform a write operation or a read operation at a physical location of the storage medium identified by the physical block address (¶[0045] – “the storage driver 218 is used to communicate device commands and read/write requests to … SSD 110”; ¶[0078] – “The host computing device 102(1) services the write request by writing the data and context metadata associated with the write request to the physical location in the ZNS 124 that corresponds to the identified current zone and the determined offset”).
GOLE may not explicitly disclose transmitting, by a host device, a storage structure discovery request to a solid state drive (SSD), the SSD including a storage medium; receiving, by the host device, storage structure information from the SSD, the storage structure information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium; and providing, by the host device, the physical block address and the logical block address to the controller.
However, GARG discloses providing, by the host device, the physical block address and the logical block address to the controller (¶[0078] – “the memory controller may process a memory request from the host device based on one or more addresses affected by the one or more address mapping changes. In other words, after the synchronization, the memory controller may use the physical addresses from the L2P table of the host controller that have been updated and verified”).
GOLE and GARG are analogous art because they are from the same field of endeavor of address translation mapping table management. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of GOLE and GARG before him or her, to modify the SSD of GOLE to include a device controller as taught by GARG. A motivation for doing so would have been to enable redundant or multiple storage modes depending on host or device controller availability increasing storage device throughput (¶[0019]). Therefore, it would have been obvious to combine GOLE and GARG to obtain the invention as specified in the instant claims.
GOLE and GARG may not explicitly disclose transmitting, by a host device, a storage structure discovery request to a solid state drive (SSD), the SSD including a storage medium; receiving, by the host device, storage structure information from the SSD, the storage structure information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium.
However, GOODGOLD discloses transmitting, by a host device, a storage structure discovery request to a storage medium (Fig 4, Step 402/404 – Expert sends request to specialist for parameters relevant to disk characteristics; Col 3, Lines 5-16 – “the expert 214 sends a request to the specialist 212 for the disk characteristics”; Fig 2 illustrates Open System Host 204 comprising Expert 214 and Disk Subsystem 202 comprising Specialist 212); receiving, by the host device, storage structure information from the storage medium (Fig 4, Step 408 – Specialist transfers parameters to expert; Col 3, Lines 27-29).
GOLE, GARG, and GOODGOLD are analogous art because they are from the same field of endeavor of storage system management. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of GOLE, GARG, and GOODGOLD before him or her, to modify the system of the combination of GOLE and GARG to include sharing of disk characteristics as taught by GOODGOLD. A motivation for doing so would have been to obtain useful characteristics for determining performance of the storage system (Abstract) to understand the behavior of the storage system and enable strategies to address any bottlenecks. Therefore, it would have been obvious to combine GOLE, GARG, and GOODGOLD to obtain the invention as specified in the instant claims.
GOLE, GARG, and GOODGOLD may not explicitly disclose the storage structure information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium.
However, GOODGOLD explicitly states the following at Col 19-24: “One of the functions of the processor 110 is to provide statistics and other characteristics of the disk array 106 to the host 104. Examples of disk characteristics of interest to the host 104 include a table of ownership, the amount of space used on the disks 106, and performance characteristics. An important performance characteristic is disk utilization, which tells the host 104 how busy are each disk in the array 106. In a mainframe environment, as illustrated in FIG. 1, obtaining the disk utilization characteristic is well known in the art”; thus, GOODGOLD at least suggests the storage system may transmit any known characteristics or information about the storage system including, for example, a number of blocks per plane included in the storage system.
As such, with the suggestions asserted by GOODGOLD, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to have taken into consideration GOLE, GARG, and GOODGOLD’s explicit teachings and suggestions to have been able to modify GOLE, GARG, and GOODGOLD’s explicit teachings such that the characteristics or information provided by a processor or controller of the storage system to a host may include information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium with a reasonable expectation of success. A motivation for doing so would have been to obtain useful characteristics for determining performance of the storage system (Abstract) to understand the behavior of the storage system and enable strategies to address any bottlenecks.
With respect to Claim 8, GOLE discloses a system comprising:
a storage device including a storage medium and a controller (Fig 1, SSD 110; Fig 9, Storage Device 902 comprises Processors 904 and Flash Media 912);
a host device including a first memory (Fig 1, Host Computing Device 102(x); Fig 2, Host Computing Device 102(1) comprises Memory 202), the host device to:
determine a storage structure of the storage medium based on the storage structure information (Fig 1, Solid-State Disk (SSD) 110; Fig 3, Step 300; ¶[0054] – “In step 300 in this example, the host FTL 216 of the host computing device 102(1) obtains from the SSD 110 the location of the on-disk ZNS mapping table 128 {‘a storage structure of a storage medium’}”; the location of the on-disk ZNS mapping table meets both “an identifier of the storage medium” and “a physical block address associated with the storage medium” under the broadest reasonable interpretation of those terms; thus, the storage structure is ‘determined’ based on the location or ‘storage structure information’);
determine a physical block address of the physical block addresses to be used by a logical block address based on determining the storage structure (Fig 3, Step 312; ¶[0077] – “In step 312, the host FTL 216 of the host computing device 102(1) identifies an entry in the in-core ZNS mapping table 220 based on a logical address extracted from the write request”; Fig 6 illustrates in-core ZNS mapping table 220(1) mapping logical zones to physical zones; ¶[0084] – “At time T1, the in-core ZNS mapping tables 220(1) and 220(2) have respective entries 608(1) and 608(2) that reflect the mapping or translation of a logical zone number or logical address of ‘101’ to the physical zone number ‘1420’ associated with zone 600”);
generate a logical to physical (L2P) entry that maps the logical block address to the physical block address (Fig 3, Step 310; ¶[0075] – “In step 310, the host FTL 216 of the host computing device 102(1) services the zone open request by selecting a free zone”; ¶[0076] – “The host computing device 102(1) then opens the selected zone for writing and inserts an entry into the in-core ZNS mapping table 220 and the on-disk ZNS mapping table 128”);
store the L2P entry in an L2P data structure that is stored in the first memory (Fig 3, Step 310; ¶[0076] – “The host computing device 102(1) then opens the selected zone for writing and inserts an entry into the in-core ZNS mapping table 220 and the on-disk ZNS mapping table 128”; Fig 2 illustrates Memory 202 comprises In-Core ZNS Mapping Table 220); and
wherein the physical block address and the logical block address are provided to access a physical location of the storage medium identified by the physical block address (¶[0045] – “the storage driver 218 is used to communicate device commands and read/write requests to … SSD 110”; ¶[0078] – “The host computing device 102(1) services the write request by writing the data and context metadata associated with the write request to the physical location in the ZNS 124 that corresponds to the identified current zone and the determined offset”).
GOLE may not explicitly disclose transmit a storage structure discovery request to the storage device; receive storage structure information from the storage device, the storage structure information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium; and provide, to the controller, the physical block address and the logical block address.
However, GARG discloses provide, to the controller, the physical block address and the logical block address (¶[0078] – “the memory controller may process a memory request from the host device based on one or more addresses affected by the one or more address mapping changes. In other words, after the synchronization, the memory controller may use the physical addresses from the L2P table of the host controller that have been updated and verified”).
GOLE and GARG are analogous art because they are from the same field of endeavor of address translation mapping table management. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of GOLE and GARG before him or her, to modify the SSD of GOLE to include a device controller as taught by GARG. A motivation for doing so would have been to enable redundant or multiple storage modes depending on host or device controller availability increasing storage device throughput (¶[0019]). Therefore, it would have been obvious to combine GOLE and GARG to obtain the invention as specified in the instant claims.
GOLE and GARG may not explicitly disclose transmit a storage structure discovery request to the storage device; receive storage structure information from the storage device, the storage structure information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium.
However, GOODGOLD discloses transmit a storage structure discovery request to the storage device (Fig 4, Step 402/404 – Expert sends request to specialist for parameters relevant to disk characteristics; Col 3, Lines 5-16 – “the expert 214 sends a request to the specialist 212 for the disk characteristics”; Fig 2 illustrates Open System Host 204 comprising Expert 214 and Disk Subsystem 202 comprising Specialist 212); receive storage structure information from the storage device (Fig 4, Step 408 – Specialist transfers parameters to expert; Col 3, Lines 27-29).
GOLE, GARG, and GOODGOLD are analogous art because they are from the same field of endeavor of storage system management. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of GOLE, GARG, and GOODGOLD before him or her, to modify the system of the combination of GOLE and GARG to include sharing of disk characteristics as taught by GOODGOLD. A motivation for doing so would have been to obtain useful characteristics for determining performance of the storage system (Abstract) to understand the behavior of the storage system and enable strategies to address any bottlenecks. Therefore, it would have been obvious to combine GOLE, GARG, and GOODGOLD to obtain the invention as specified in the instant claims.
GOLE, GARG, and GOODGOLD may not explicitly disclose the storage structure information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium.
However, GOODGOLD explicitly states the following at Col 19-24: “One of the functions of the processor 110 is to provide statistics and other characteristics of the disk array 106 to the host 104. Examples of disk characteristics of interest to the host 104 include a table of ownership, the amount of space used on the disks 106, and performance characteristics. An important performance characteristic is disk utilization, which tells the host 104 how busy are each disk in the array 106. In a mainframe environment, as illustrated in FIG. 1, obtaining the disk utilization characteristic is well known in the art”; thus, GOODGOLD at least suggests the storage system may transmit any known characteristics or information about the storage system including, for example, a number of blocks per plane included in the storage system.
As such, with the suggestions asserted by GOODGOLD, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to have taken into consideration GOLE, GARG, and GOODGOLD’s explicit teachings and suggestions to have been able to modify GOLE, GARG, and GOODGOLD’s explicit teachings such that the characteristics or information provided by a processor or controller of the storage system to a host may include information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium with a reasonable expectation of success. A motivation for doing so would have been to obtain useful characteristics for determining performance of the storage system (Abstract) to understand the behavior of the storage system and enable strategies to address any bottlenecks.
With respect to Claim 15, GOLE discloses a non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: one or more instructions that, when executed by one or more processors of a host device, cause the host device to:
determine a storage structure of the storage medium based on the storage structure information (Fig 1, Solid-State Disk (SSD) 110; Fig 3, Step 300; ¶[0054] – “In step 300 in this example, the host FTL 216 of the host computing device 102(1) obtains from the SSD 110 the location of the on-disk ZNS mapping table 128 {‘a storage structure of a storage medium’}”; the location of the on-disk ZNS mapping table meets both “an identifier of the storage medium” and “a physical block address associated with the storage medium” under the broadest reasonable interpretation of those terms; thus, the storage structure is ‘determined’ based on the location or ‘storage structure information’);
determine a physical block address of the physical block addresses to be used by a logical block address based on determining the storage structure (Fig 3, Step 312; ¶[0077] – “In step 312, the host FTL 216 of the host computing device 102(1) identifies an entry in the in-core ZNS mapping table 220 based on a logical address extracted from the write request”; Fig 6 illustrates in-core ZNS mapping table 220(1) mapping logical zones to physical zones; ¶[0084] – “At time T1, the in-core ZNS mapping tables 220(1) and 220(2) have respective entries 608(1) and 608(2) that reflect the mapping or translation of a logical zone number or logical address of ‘101’ to the physical zone number ‘1420’ associated with zone 600”);
generate a logical to physical (L2P) entry that maps the logical block address to the physical block address (Fig 3, Step 310; ¶[0075] – “In step 310, the host FTL 216 of the host computing device 102(1) services the zone open request by selecting a free zone”; ¶[0076] – “The host computing device 102(1) then opens the selected zone for writing and inserts an entry into the in-core ZNS mapping table 220 and the on-disk ZNS mapping table 128”);
store the L2P entry in an L2P data structure that is stored in a first memory of the host device (Fig 3, Step 310; ¶[0076] – “The host computing device 102(1) then opens the selected zone for writing and inserts an entry into the in-core ZNS mapping table 220 and the on-disk ZNS mapping table 128”; Fig 2 illustrates Memory 202 comprises In-Core ZNS Mapping Table 220),
wherein a copy of the L2P data structure is stored in a second memory of a controller of the SSD (Fig 1 illustrates SSD 110 comprises On-Disk ZNS Mapping Table 128); and
wherein the physical block address and the logical block address are provided to perform a write operation or a read operation at a physical location of the storage medium identified by the physical block address (¶[0045] – “the storage driver 218 is used to communicate device commands and read/write requests to … SSD 110”; ¶[0078] – “The host computing device 102(1) services the write request by writing the data and context metadata associated with the write request to the physical location in the ZNS 124 that corresponds to the identified current zone and the determined offset”).
GOLE may not explicitly disclose transmit a storage structure discovery request to a solid state drive (SSD), the SSD including a storage medium; receive storage structure information from the SSD, the storage structure information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium; and provide, to the controller, the physical block address and the logical block address.
However, GARG discloses provide, to the controller, the physical block address and the logical block address (¶[0078] – “the memory controller may process a memory request from the host device based on one or more addresses affected by the one or more address mapping changes. In other words, after the synchronization, the memory controller may use the physical addresses from the L2P table of the host controller that have been updated and verified”).
GOLE and GARG are analogous art because they are from the same field of endeavor of address translation mapping table management. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of GOLE and GARG before him or her, to modify the SSD of GOLE to include a device controller as taught by GARG. A motivation for doing so would have been to enable redundant or multiple storage modes depending on host or device controller availability increasing storage device throughput (¶[0019]). Therefore, it would have been obvious to combine GOLE and GARG to obtain the invention as specified in the instant claims.
GOLE and GARG may not explicitly disclose transmit a storage structure discovery request to a solid state drive (SSD), the SSD including a storage medium; receive storage structure information from the SSD, the storage structure information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium.
However, GOODGOLD discloses transmit a storage structure discovery request to a storage medium (Fig 4, Step 402/404 – Expert sends request to specialist for parameters relevant to disk characteristics; Col 3, Lines 5-16 – “the expert 214 sends a request to the specialist 212 for the disk characteristics”; Fig 2 illustrates Open System Host 204 comprising Expert 214 and Disk Subsystem 202 comprising Specialist 212); receive storage structure information from the storage medium (Fig 4, Step 408 – Specialist transfers parameters to expert; Col 3, Lines 27-29).
GOLE, GARG, and GOODGOLD are analogous art because they are from the same field of endeavor of storage system management. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of GOLE, GARG, and GOODGOLD before him or her, to modify the system of the combination of GOLE and GARG to include sharing of disk characteristics as taught by GOODGOLD. A motivation for doing so would have been to obtain useful characteristics for determining performance of the storage system (Abstract) to understand the behavior of the storage system and enable strategies to address any bottlenecks. Therefore, it would have been obvious to combine GOLE, GARG, and GOODGOLD to obtain the invention as specified in the instant claims.
GOLE, GARG, and GOODGOLD may not explicitly disclose the storage structure information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium.
However, GOODGOLD explicitly states the following at Col 19-24: “One of the functions of the processor 110 is to provide statistics and other characteristics of the disk array 106 to the host 104. Examples of disk characteristics of interest to the host 104 include a table of ownership, the amount of space used on the disks 106, and performance characteristics. An important performance characteristic is disk utilization, which tells the host 104 how busy are each disk in the array 106. In a mainframe environment, as illustrated in FIG. 1, obtaining the disk utilization characteristic is well known in the art”; thus, GOODGOLD at least suggests the storage system may transmit any known characteristics or information about the storage system including, for example, a number of blocks per plane included in the storage system.
As such, with the suggestions asserted by GOODGOLD, it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to have taken into consideration GOLE, GARG, and GOODGOLD’s explicit teachings and suggestions to have been able to modify GOLE, GARG, and GOODGOLD’s explicit teachings such that the characteristics or information provided by a processor or controller of the storage system to a host may include information including an identifier of the storage medium, physical block addresses associated with the storage medium, a number of dies per chip enable included in the storage medium, a number of planes per die included in the storage medium, and a number of blocks per plane included in the storage medium with a reasonable expectation of success. A motivation for doing so would have been to obtain useful characteristics for determining performance of the storage system (Abstract) to understand the behavior of the storage system and enable strategies to address any bottlenecks.
With respect to Claim 2, the combination of GOLE, GARG, and GOODGOLD disclose the method of claim 1.
GOLE further discloses wherein the first memory includes a first read-only memory or random-access memory (Fig 2, Memory 202; ¶[0052] – Memory 202 may be ‘one or more non-transitory computer readable media’), and wherein the second memory includes a second read-only memory or random-access memory (Fig 1, SSD 110 comprises on-disk mapping table 128).
With respect to Claim 3, the combination of GOLE, GARG, and GOODGOLD disclose the method of claim 2.
GOLE further discloses wherein determining the storage structure comprises: determining a physical block arrangement of blocks of the storage medium based on the storage structure information (Fig 1, Solid-State Disk (SSD) 110; Fig 3, Step 300; ¶[0054] – “In step 300 in this example, the host FTL 216 of the host computing device 102(1) obtains from the SSD 110 the location of the on-disk ZNS mapping table 128 {‘a storage structure of a storage medium’}”; ¶[0055] – “The in-core ZNS mapping table 220 … store logical-to-physical (L2P) mappings or translations between logical zones and physical zones that correspond with storage locations in the ZNS 124 and on the SSD 110”).
With respect to Claim 4, the combination of GOLE, GARG, and GOODGOLD disclose the method of claim 1.
GARG further discloses receiving a notification that an operation has been initiated on the SSD, wherein the operation includes a garbage collection operation or a read scrub operation, and wherein the copy of the L2P data structure is updated based on the garbage collection operation or the read scrub (¶[0053] – “the operating state notification module 330 may determine if an L2P table on the host controller and/or the memory device controller requires updating or is out-of-sync. After the synchronization, the sync verify module 336 may be configured on the memory device controller to reset one or more indicators corresponding to memory mapping entries that have been synchronized”; ¶[0054] – “The updated mapping module 338 may coordinate with the sync verify module 336 and may monitor/control one or more memory operations (e.g. garbage collection) while synchronization is in progress”).
With respect to Claim 6, the combination of GOLE, GARG, and GOODGOLD disclose the method of claim 1.
GOLE further discloses synchronizing L2P entries of the L2P data structure and L2P entries of the copy of the L2P data structure during a power cycle of the SSD, wherein the L2P entries of the copy of the L2P data structure are stored in a non-volatile memory device of the SSD during the power cycle (¶[0031] – “The on-disk ZNS mapping table 128 can be … exchanged by the host computing devices 102(1) and 102(2) during an initialization process”).
With respect to Claim 7, the combination of GOLE, GARG, and GOODGOLD disclose the method of claim 1.
GOLE further discloses synchronizing L2P entries of the L2P data structure and L2P entries of the copy of the L2P data structure using a coherency protocol (¶[0031] – “The on-disk ZNS mapping table 128 can be … exchanged by the host computing devices 102(1) and 102(2) during an initialization process”).
With respect to Claim 9, the combination of GOLE, GARG, and GOODGOLD disclose the system of claim 8.
GARG further discloses the controller including a second memory (Fig 1, Device Controller 116).
GOLE further discloses wherein the controller is to store a copy of the L2P data structure in the second memory (Fig 1 illustrates SSD 110 comprises On-Disk ZNS Mapping Table 128).
With respect to Claim 10, the combination of GOLE, GARG, and GOODGOLD disclose the system of claim 9.
GARG further discloses wherein the controller is to: initiate an operation on the storage device; wherein the operation is not initiated by the host device; and provide, to the host device, a notification that the operation has been initiated on the storage device, wherein the operation includes a garbage collection operation or a read scrub operation (¶[0053] – “the operating state notification module 330 may determine if an L2P table on the host controller and/or the memory device controller requires updating or is out-of-sync. After the synchronization, the sync verify module 336 may be configured on the memory device controller to reset one or more indicators corresponding to memory mapping entries that have been synchronized”; ¶[0054] – “The updated mapping module 338 may coordinate with the sync verify module 336 and may monitor/control one or more memory operations (e.g. garbage collection) while synchronization is in progress”).
With respect to Claim 11, the combination of GOLE, GARG, and GOODGOLD disclose the system of claim 10.
GARG further discloses wherein the controller is to: update the copy of the L2P data structure based on the garbage collection operation or the read scrub (¶[0053] – “the operating state notification module 330 may determine if an L2P table on the host controller and/or the memory device controller requires updating or is out-of-sync. After the synchronization, the sync verify module 336 may be configured on the memory device controller to reset one or more indicators corresponding to memory mapping entries that have been synchronized”; ¶[0054] – “The updated mapping module 338 may coordinate with the sync verify module 336 and may monitor/control one or more memory operations (e.g. garbage collection) while synchronization is in progress”).
With respect to Claim 13, the combination of GOLE, GARG, and GOODGOLD disclose the system of claim 9.
GOLE further discloses wherein the host device is to: synchronize L2P entries of the L2P data structure and L2P entries of the copy of the L2P data structure during a power cycle of the storage device, wherein the L2P entries of the copy of the L2P data structure are stored in a non-volatile memory device of the storage device during the power cycle (¶[0031] – “The on-disk ZNS mapping table 128 can be … exchanged by the host computing devices 102(1) and 102(2) during an initialization process”).
With respect to Claim 14, the combination of GOLE, GARG, and GOODGOLD disclose the system of claim 13.
GOLE further discloses wherein the controller is to: store the L2P entries of the copy of the L2P data structure in the non-volatile memory device of the storage device during the power cycle (¶[0031] – “The on-disk ZNS mapping table 128 can be … exchanged by the host computing devices 102(1) and 102(2) during an initialization process”).
With respect to Claim 16, the combination of GOLE, GARG, and GOODGOLD disclose the non-transitory computer-readable medium of claim 15.
GOLE further discloses wherein the one or more instructions cause the host device to: determine a physical block arrangement of blocks of the storage medium based on the storage structure information (Fig 1, Solid-State Disk (SSD) 110; Fig 3, Step 300; ¶[0054] – “In step 300 in this example, the host FTL 216 of the host computing device 102(1) obtains from the SSD 110 the location of the on-disk ZNS mapping table 128 {‘a storage structure of a storage medium’}”; ¶[0055] – “The in-core ZNS mapping table 220 … store logical-to-physical (L2P) mappings or translations between logical zones and physical zones that correspond with storage locations in the ZNS 124 and on the SSD 110”).
With respect to Claim 17, the combination of GOLE, GARG, and GOODGOLD disclose the non-transitory computer-readable medium of claim 15.
GARG further discloses wherein the one or more instructions cause the host device to: receive a notification that an operation has been initiated on the SSD, wherein the operation includes a garbage collection operation or a read scrub operation, wherein the copy of the L2P data structure is updated based on the garbage collection operation or the read scrub (¶[0053] – “the operating state notification module 330 may determine if an L2P table on the host controller and/or the memory device controller requires updating or is out-of-sync. After the synchronization, the sync verify module 336 may be configured on the memory device controller to reset one or more indicators corresponding to memory mapping entries that have been synchronized”; ¶[0054] – “The updated mapping module 338 may coordinate with the sync verify module 336 and may monitor/control one or more memory operations (e.g. garbage collection) while synchronization is in progress”).
With respect to Claim 19, the combination of GOLE, GARG, and GOODGOLD disclose the non-transitory computer-readable medium of claim 15.
GOLE further discloses wherein the one or more instructions cause the host device to: synchronize L2P entries of the L2P data structure and L2P entries of the copy of the L2P data structure during a power cycle of the SSD, wherein the L2P entries of the copy of the L2P data structure are stored in a non-volatile memory device of the SSD during the power cycle (¶[0031] – “The on-disk ZNS mapping table 128 can be … exchanged by the host computing devices 102(1) and 102(2) during an initialization process”).
With respect to Claim 20, the combination of GOLE, GARG, and GOODGOLD disclose the non-transitory computer-readable medium of claim 15.
GOLE further discloses wherein the one or more instructions cause the host device to: synchronize L2P entries of the L2P data structure and L2P entries of the copy of the L2P data structure using a coherency protocol (¶[0031] – “The on-disk ZNS mapping table 128 can be … exchanged by the host computing devices 102(1) and 102(2) during an initialization process”).
Claim(s) 5, 12, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over GOLE in further view of GARG, GOODGOLD, and MUSIN et al (US PGPub 2021/0248076).
With respect to Claim 5, the combination of GOLE, GARG, and GOODGOLD disclose the method of claim 4.
GARG further discloses wherein the copy of the L2P data structure is updated by setting a flag for at least one L2P entry associated with the operation, wherein the flag indicates an address of data associated with the at least one L2P entry has been updated (Fig 5, Step 518 – “Modify an indicator in a first memory table on the storage device in response to a change in memory mapping”), and wherein the method comprises: synchronizing L2P entries of the L2P data structure and L2P entries of the copy of the L2P data structure after the copy of the L2P data structure has been updated (Fig 5, Step 520 – “Notify the host device that the first memory table has been modified” -=> Step 524 – “Transmit to the host device at least a portion of the first memory table including the one or more address mapping changes”).
GOLE, GARG, and GOODGOLD may not explicitly disclose wherein the copy of the L2P data structure is updated by setting a timestamp.
However, MUSIN discloses wherein the copy of the L2P data structure is updated by setting a timestamp (Abstract – “The second data includes the logical address and a timestamp value indicating a version of map data mapping between the logical address and the physical address; ¶[0101] – “The timestamp value is stored on the storage device 10”).
GOLE, GARG, GOODGOLD, and MUSIN are analogous art because they are from the same field of endeavor of storage system management. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of GOLE, GARG, GOODGOLD, and MUSIN before him or her, to modify the On-Disk ZNS Mapping Table of the combination of GOLE, GARG, and GOODGOLD to include a timestamp as taught by MUSIN. A motivation for doing so would have been to enable version tracking of L2P data (¶[0101]). Therefore, it would have been obvious to combine GOLE, GARG, GOODGOLD, and MUSIN to obtain the invention as specified in the instant claims.
With respect to Claim 12, the combination of GOLE, GARG, and GOODGOLD disclose the system of claim 11.
GARG further discloses wherein the controller is to: set a flag for at least one L2P entry associated with the operation to update the copy of the L2P data structure (Fig 5, Step 518 – “Modify an indicator in a first memory table on the storage device in response to a change in memory mapping”); and synchronize L2P entries of the L2P data structure and L2P entries of the copy of the L2P data structure after the copy of the L2P data structure has been updated (Fig 5, Step 520 – “Notify the host device that the first memory table has been modified” -=> Step 524 – “Transmit to the host device at least a portion of the first memory table including the one or more address mapping changes”).
GOLE, GARG, and GOODGOLD may not explicitly disclose wherein the controller is to: set a timestamp … for at least one L2P entry … to update the copy of the L2P data structure.
However, MUSIN discloses wherein the controller is to: set a timestamp … for at least one L2P entry … to update the copy of the L2P data structure (Abstract – “The second data includes the logical address and a timestamp value indicating a version of map data mapping between the logical address and the physical address; ¶[0101] – “The timestamp value is stored on the storage device 10”).
GOLE, GARG, GOODGOLD, and MUSIN are analogous art because they are from the same field of endeavor of storage system management. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of GOLE, GARG, GOODGOLD, and MUSIN before him or her, to modify the On-Disk ZNS Mapping Table of the combination of GOLE, GARG, and GOODGOLD to include a timestamp as taught by MUSIN. A motivation for doing so would have been to enable version tracking of L2P data (¶[0101]). Therefore, it would have been obvious to combine GOLE, GARG, GOODGOLD, and MUSIN to obtain the invention as specified in the instant claims.
With respect to Claim 18, the combination of GOLE, GARG, and GOODGOLD disclose the non-transitory computer-readable medium of claim 15.
GARG further discloses wherein the copy of the L2P data structure is updated by setting a flag for at least one L2P entry associated with the garbage collection operation or the read scrub operation (Fig 5, Step 518 – “Modify an indicator in a first memory table on the storage device in response to a change in memory mapping”), wherein the one or more instructions further cause the host device to: synchronize L2P entries of the L2P data structure and L2P entries of the copy of the L2P data structure after the copy of the L2P data structure has been updated (Fig 5, Step 520 – “Notify the host device that the first memory table has been modified” -=> Step 524 – “Transmit to the host device at least a portion of the first memory table including the one or more address mapping changes”).
GOLE and GARG may not explicitly disclose wherein the copy of the L2P data structure is updated by setting a timestamp.
However, MUSIN discloses wherein the copy of the L2P data structure is updated by setting a timestamp (Abstract – “The second data includes the logical address and a timestamp value indicating a version of map data mapping between the logical address and the physical address; ¶[0101] – “The timestamp value is stored on the storage device 10”).
GOLE, GARG, GOODGOLD, and MUSIN are analogous art because they are from the same field of endeavor of address translation mapping table management. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of GOLE, GARG, GOODGOLD, and MUSIN before him or her, to modify the On-Disk ZNS Mapping Table of the combination of GOLE, GARG, and GOODGOLD to include a timestamp as taught by MUSIN. A motivation for doing so would have been to enable version tracking of L2P data (¶[0101]). Therefore, it would have been obvious to combine GOLE, GARG, GOODGOLD, and MUSIN to obtain the invention as specified in the instant claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC T LOONAN whose telephone number is (571)272-6994. The examiner can normally be reached M-F 8am-5pm.
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, Arpan Savla can be reached at 571-272-1077. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ERIC T LOONAN/Primary Examiner, Art Unit 2137
