Prosecution Insights
Last updated: August 16, 2026
Application No. 19/002,635

GENERATING A LOGICAL TO PHYSICAL DATA STRUCTURE STORED BY A HOST DEVICE

Final Rejection §103
Filed
Dec 26, 2024
Priority
Aug 01, 2024 — provisional 63/678,058
Examiner
LOONAN, ERIC T
Art Unit
2137
Tech Center
2100 — Computer Architecture & Software
Assignee
Microchip Technology Incorporated
OA Round
2 (Final)
65%
Grant Probability
Moderate
3-4
OA Rounds
2y 1m
Est. Remaining
91%
With Interview

Examiner Intelligence

Grants 65% of resolved cases
65%
Career Allowance Rate
282 granted / 435 resolved
+9.8% vs TC avg
Strong +27% interview lift
Without
With
+26.6%
Interview Lift
resolved cases with interview
Typical timeline
3y 9m
Avg Prosecution
17 currently pending
Career history
460
Total Applications
across all art units

Statute-Specific Performance

§101
7.7%
-32.3% vs TC avg
§103
45.1%
+5.1% vs TC avg
§102
23.4%
-16.6% vs TC avg
§112
20.5%
-19.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 435 resolved cases

Office Action

§103
DETAILED ACTION This Office Action, based on application 19/002,635, filed in response to applicant’s amendment and remarks filed 6 April 2026. Claims 1-20 are currently pending and have been fully considered below. 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 6 April 2026 in response to the Office Action filed 6 January 2026, have been fully considered below. Claim Objections The Office withdraws the previously issued objections in view of applicant’s amendment and remarks. 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 at fails to disclose “wherein a copy of the L2P data structure [generated by the host device] is stored in a second memory of a controller of the SSD”. To support applicant’s allegation, the applicant alleges “GOLE does not disclose or suggest that the on-disk ZNS mapping table 128 was generated by any of the host computing devices 102(1) and 102(2)”; the Office respectfully disagrees. First, the Office notes that while Claim 1 recites “storing, by the hosting device, the L2P entry in an L2P data structure that is stored in a first memory of a host device”, Claim 1 is not limited to any host device (or any other particular entity) generating the L2P data structure. As such, applicant’s arguments are rendered moot since while the claim is interpreted in light of the specification, limitations from the specification are not read into the claim. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The Office asserts GOLE at least teaches the host devices may update the in-core ZNS tables (as noted in the grounds of rejection). As such, the Office maintains GOLE teaches the ‘storing’ limitation as presented. 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). With respect to Claim 1, GOLE discloses a method comprising: determining, by a host device, a storage structure of a storage medium of a solid state drive (SSD) (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’}”); determining, by the host device, a physical block address 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 a 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 providing, , by the host device and to the controller, the physical block address and the logical block address. However, GARG discloses providing, 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. With respect to Claim 8, GOLE discloses a system comprising: a host device to: determine a storage structure of a storage medium of a storage device (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’}”); determine a physical block address 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 memory of a 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); 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 provide, to a controller of the storage device, the physical block address and the logical block address. However, GARG discloses provide, to a controller of the storage device, 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. 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 a storage medium of a solid state drive (SSD) (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’}”); determine a physical block address 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 a 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 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. With respect to Claim 2, the combination of GOLE and GARG 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 and GARGE 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 (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 and GARG 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 operation initiated by the SSD (¶[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 and GARG 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 and GARG 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 and GARG disclose the system of claim 8. GARG further discloses the controller (Fig 1, Device Controller 116). GOLE further discloses wherein the controller is to store a copy of the L2P data structure in a memory of a controller of the storage device (Fig 1 illustrates SSD 110 comprises On-Disk ZNS Mapping Table 128). With respect to Claim 10, the combination of GOLE and GARG 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 and GARG 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 operation initiated by the storage device (¶[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 and GARG 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 and GARG 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 and GARG disclose the non-transitory computer-readable medium of claim 15. GOLE further discloses wherein the one or more instructions, that cause the host device to determine the storage structure, cause the host device to: determine a physical block arrangement of blocks of the storage medium (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 and GARG disclose the non-transitory computer-readable medium of claim 15. GARG further discloses one or more instructions 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, and wherein the copy of the L2P data structure is updated based on the operation initiated by the SSD (¶[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 and GARG disclose the non-transitory computer-readable medium of claim 15. GOLE further discloses one or more instructions 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 and GARG disclose the non-transitory computer-readable medium of claim 15. GOLE further discloses one or more instructions 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 and MUSIN et al (US PGPub 2021/0248076). With respect to Claim 5, the combination of GOLE and GARG 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 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, 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, and MUSIN before him or her, to modify the On-Disk ZNS Mapping Table of the combination of GOLE and GARG 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, and MUSIN to obtain the invention as specified in the instant claims. With respect to Claim 12, the combination of GOLE and GARG 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 and GARG 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, 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, and MUSIN before him or her, to modify the On-Disk ZNS Mapping Table of the combination of GOLE and GARG 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, and MUSIN to obtain the invention as specified in the instant claims. With respect to Claim 18, the combination of GOLE and GARG 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 operation, 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. 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, 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, and MUSIN before him or her, to modify the On-Disk ZNS Mapping Table of the combination of GOLE and GARG 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, and MUSIN to obtain the invention as specified in the instant claims. Conclusion THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. 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/Examiner, Art Unit 2137
Read full office action

Prosecution Timeline

Dec 26, 2024
Application Filed
Jan 06, 2026
Non-Final Rejection mailed — §103
Mar 23, 2026
Applicant Interview (Telephonic)
Mar 27, 2026
Examiner Interview Summary
Apr 06, 2026
Response Filed
Jun 29, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12693806
PERSISTENT XSPI STT-MRAM WITH OPTIONAL ERASE OPERATION
1y 11m to grant Granted Jul 28, 2026
Patent 12681648
NONVOLATILE MEMORY ACCESS VIA MEMORY INTERCONNECT SYSTEMS
3y 10m to grant Granted Jul 14, 2026
Patent 12663934
TAPE DEVICE TO REPLICATE DATA TO A PLURALITY OF REMOTE STORAGE DEVICES
3y 10m to grant Granted Jun 23, 2026
Patent 12632184
PREDICTING LIFESPAN OF FLASH MEMORY BASED ON ACTUAL USAGE PROFILE
4y 4m to grant Granted May 19, 2026
Patent 12632186
STORAGE DEVICE DETERMINING WHETHER DATA IS ALL ONE OR ALL ZERO BASED ON STATE VALUE AND OPERATING METHOD OF THE STORAGE DEVICE
2y 7m to grant Granted May 19, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
65%
Grant Probability
91%
With Interview (+26.6%)
3y 9m (~2y 1m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 435 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month