CTNF 18/914,582 CTNF 81768 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-20-aia AIA 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. 07-21-aia AIA Claim s 1-19 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al. (U.S. Patent Application Publication Number 2023/0120680), Mikkonen et al. (U.S. Patent Number 6,501,741), Vokaliga et al. (U.S. Patent Application Publication Number 2022/0067549) . Regarding Claim 1 , Yu discloses a storage device to manage a transient state during which input/output (IO) operations in a namespace is impacted and to mitigate impacts to a quality-of-service requirement on the storage device during the transient state, the storage device comprises: a memory to store a logical-to-physical (L2P) table (paragraph 0033; i.e., a flash memory); a volatile memory to cache the L2P table (paragraph 0033; i.e., a cache memory is a type of volatile memory [see paragraph 0088]); and a controller (Figure 9, paragraph 0072) to set an IO impacted (IOI) bit (paragraph 0035; i.e., the dirty bit is considered equivalent to the claimed “IO impacted bit” because when it is set to indicate dirty pages [see paragraph 0041], latency is increased for reading data from the cache) during initialization of the storage device to cause the storage device to enter a transient state (paragraph 0051; i.e., the dirty bit is set to 00 at storage device initialization, which indicates that the pages are not dirty; this only happens temporarily [“transient state”] because the dirty bit is later set to 01, 10, or 11), and reset the IOI bit after initialization of the storage device (paragraph 0062; i.e., eventually [“after initialization of the storage device”], the dirty bit is reset to 00 to indicate that the pages are no longer dirty [even though they may have become dirty in between]). Yu does not expressly disclose provide a first indication to a host to notify the host to transmit host IO requests to be processed without a performance guarantee, prioritize loading a first category of L2P entries in the volatile memory, and send a second indication to the host to notify the host to transmit the host IO requests to be processed according to the performance guarantee. In the same field of endeavor (e.g., techniques for minimizing latency of data flow between a host and device), Mikkonen teaches provide a first indication to a host to notify the host to transmit host IO requests to be processed without a performance guarantee (Column 11, line 65 - Column 12, line 5) and send a second indication to the host to notify the host to transmit the host IO requests to be processed according to the performance guarantee (Column 5, lines 44-60 and Column 10, lines 52-66; i.e., the host is notified when a best effort quality of service has to be used [“requests to be processed without a performance guarantee”] and can also be notified when the desired quality of service can be used). Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Mikkonen’s teachings of techniques for minimizing latency of data flow between a host and device with the teachings of Yu, for the purpose of allowing the data flow to continue even when the desired quality of service is not available, thereby increasing the overall data throughput of the system. Also in the same field of endeavor (e.g., techniques for minimizing latency of data flow between a host and device), Vokaliga teaches prioritize loading a first category of entries in the volatile memory (paragraph 0055; i.e., pre-loading entries into the cache that are likely to be requested in the future). Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Vokaliga’s teachings of techniques for minimizing latency of data flow between a host and device with the teachings of Yu, for the purpose of decreasing the latency of reading data from the storage device (see Vokaliga, paragraph 0055). Regarding Claim 2 , Vokaliga teaches a learning module to identify a priority loading policy to load a L2P table in the volatile memory during the transient state (paragraph 0055). Regarding Claim 3 , Vokaliga teaches wherein the learning module learns the priority policy from an initialization IO operation and modifies the priority based on a last used range (paragraphs 0055 and 0058; i.e., the machine learning model keeps data in the cache that is likely to be requested again). Regarding Claim 4 , Vokaliga teaches wherein the controller loads a second category of L2P entries after loading the first category of L2P entries (paragraph 0055; i.e., the machine learning model is constantly updated so that a new set of data [the “second category”] is moved into the cache based on the algorithms). Regarding Claim 5 , Vokaliga teaches wherein the first category of L2P entries includes L2P entries for pages that are likely to be in host read requests received during the transient state (paragraph 0055). Regarding Claim 6 , Yu discloses wherein the first category of L2P entries includes at least one of dirty L2P entries and L2P entries associated with at least one of dirty pages and recently used pages (paragraph 0051; i.e., the L2P entries in the cache can become dirty). Regarding Claim 7 , Vokaliga teaches a biasing module to track pages being processed on the storage device prior to initialization of the storage device (paragraph 0055; i.e., data that is expected to be used is pre-loaded in the cache [“prior to initialization of the storage device”]). Regarding Claim 8 , Vokaliga teaches wherein the biasing module tracks at least one of dirty pages and recently used pages on the storage device (paragraph 0055). Regarding Claim 9 , Vokaliga teaches wherein the controller caches the L2P entries for pages tracked by a biasing module during a first period and caches other L2P entries during one or more subsequent periods after the first period (paragraph 0055; i.e., the machine learning model constantly updates its predictions so that the cache has the data that is most likely to be requested by the host). Regarding Claim 10 , Yu discloses wherein the controller receives a host write request in the transient state, creates a transient delta segment in the volatile memory, and stores a L2P entry for the host write request in the transient delta segment (paragraph 0051; i.e., a second write command can be received which causes the dirty bit to be set to 11 [the “transient delta segment”]). Regarding Claim 11 , Yu discloses wherein after loading an entire L2P table in the volatile memory, the controller consolidates L2P entries in the transient delta segment with the other L2P entries in the volatile memory and discards the L2P entries in the transient delta segment (paragraph 0063; i.e., the dirty data in the cache can be flushed [“discarded”]). Regarding Claim 12 , Mikkonen teaches a latency tracking module to track latency triggered by a latency condition (Column 11, line 65 - Column 12, line 5). Regarding Claim 13 , Yu and Mikkonen teach wherein when the controller identifies that a latency condition has occurred, the controller sets the IOI bit (Yu, paragraph 0051), sends the first indication to the host, corrects the latency condition (Mikkonen, Column 14, lines 32-44), and sends a second notification to the host (Mikkonen, Column 11, line 65 - Column 12, line 5). Regarding Claim 14 , Mikkonen teaches wherein when the controller receives a host IO request in the transient state, the storage device processes the host IO request with the performance guarantee (Column 14, lines 32-44). Regarding Claim 15 , Yu discloses a method in a storage device for mitigating impacts to a quality-of-service requirement on the storage device during a transient state during which input/output (IO) operations in a namespace is impacted, the storage device comprises a controller (Figure 9, paragraph 0072) to execute the method comprising: beginning initialization of the storage device (paragraph 0033); setting an IO impacted (IOI) bit (paragraph 0035; i.e., the dirty bit is considered equivalent to the claimed “IO impacted bit” because when it is set to indicate dirty pages [see paragraph 0041], latency is increased for reading data from the cache) during initialization of the storage device to cause the storage device to enter a transient state (paragraph 0051; i.e., the dirty bit is set to 00 at storage device initialization, which indicates that the pages are not dirty; this only happens temporarily [“transient state”] because the dirty bit is later set to 01, 10, or 11); resetting the IOI bit after initialization of the storage device (paragraph 0062; i.e., eventually [“after initialization of the storage device”], the dirty bit is reset to 00 to indicate that the pages are no longer dirty [even though they may have become dirty in between]). Yu does not expressly disclose providing a first indication to a host to notify the host to transmit host IO requests to be processed without a performance guarantee; prioritizing loading a first category of L2P entries in a volatile memory; sending a second indication to the host to notify the host to transmit the host IO requests to be processed according to the performance guarantee. In the same field of endeavor, Mikkonen teaches providing a first indication to a host to notify the host to transmit host IO requests to be processed without a performance guarantee (Column 11, line 65 - Column 12, line 5); sending a second indication to the host to notify the host to transmit the host IO requests to be processed according to the performance guarantee (Column 10, lines 52-66; i.e., the host is notified when a best effort quality of service has to be used [“requests to be processed without a performance guarantee”] and can also be notified when the desired quality of service can be used). Also in the same field of endeavor (e.g., techniques for minimizing latency of data flow between a host and device), Vokaliga teaches prioritizing loading a first category of entries in the volatile memory (paragraph 0055; i.e., pre-loading entries into the cache that are likely to be requested in the future; a cache memory is a type of volatile memory [see Yu at paragraph 0088]). The motivation discussed above with regards to Claim 1 applies equally as well to Claim 15. Regarding Claim 16 , Vokaliga teaches loading a second category of L2P entries after loading the first category of L2P entries (paragraph 0055; i.e., the machine learning model is constantly updated so that a new set of data [the “second category”] is moved into the cache based on the algorithms). Regarding Claim 17 , Yu discloses assigning at least one of dirty L2P entries and L2P entries at least one of associated with dirty pages and recently used pages to the first category (paragraph 0051; i.e., the L2P entries in the cache can become dirty). Regarding Claim 18 , Yu discloses receiving a host write request in the transient state, creating a transient delta segment in the volatile memory, storing a L2P entry for the host write request in the transient delta segment (paragraph 0051; i.e., a second write command can be received which causes the dirty bit to be set to 11 [the “transient delta segment”]), loading an entire L2P table in the volatile memory, consolidating L2P entries in the transient delta segment with the other L2P entries in the volatile memory, and discarding the L2P entries in the transient delta segment (paragraph 0063; i.e., the dirty data in the cache can be flushed [“discarded”]). Regarding Claim 19 , Yu and Mikkonen teach tracking latency triggered by a latency condition (Mikkonen, Column 11, line 65 - Column 12, line 5), and when the latency condition has occurred, setting the IOI bit (Yu, paragraph 0051), sending the first indication to the host, correcting the latency condition (Mikkonen, Column 14, lines 32-44), and sending a second notification to the host (Mikkonen, Column 11, line 65 - Column 12, line 5) . 07-21-aia AIA Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Yu and Mikkonen . Regarding Claim 20 , Yu discloses a method in a storage device for mitigating impacts to a quality-of-service requirement on the storage device, the storage device comprises a controller (Figure 9, paragraph 0072) to execute the method comprising: determining that a latency condition has occurred on the storage device (paragraph 0035; i.e., when there are dirty pages [see paragraph 0041], latency is increased for reading data from the cache [the claimed “latency condition”]); setting an IO impacted (IOI) bit to cause the storage device to enter a transient state (paragraph 0035; i.e., the dirty bit is considered equivalent to the claimed “IO impacted bit” because when it is set to indicate dirty pages [see paragraph 0041], latency is increased for reading data from the cache); correcting a latency condition (paragraph 0051; i.e., the dirty pages in the cache can be flushed and replaced with data that is not dirty, thereby correcting the “latency condition”); resetting the IOI bit (paragraph 0062; i.e., eventually, the dirty bit is reset to 00 to indicate that the pages are no longer dirty [even though they may have become dirty in between]). Yu does not expressly disclose providing a first indication to a host to notify the host to transmit host IO requests to be processed without a performance guarantee; sending a second indication to the host to notify the host to transmit the host IO requests to be processed according to the performance guarantee. In the same field of endeavor (e.g., techniques for minimizing latency of data flow between a host and device), Mikkonen teaches providing a first indication to a host to notify the host to transmit host IO requests to be processed without a performance guarantee (Column 11, line 65 - Column 12, line 5); sending a second indication to the host to notify the host to transmit the host IO requests to be processed according to the performance guarantee (Column 5, lines 44-60 and Column 10, lines 52-66; i.e., the host is notified when a best effort quality of service has to be used [“requests to be processed without a performance guarantee”] and can also be notified when the desired quality of service can be used). Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Mikkonen’s teachings of techniques for minimizing latency of data flow between a host and device with the teachings of Yu, for the purpose of allowing the data flow to continue even when the desired quality of service is not available, thereby increasing the overall data throughput of the system . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure because each reference discloses storage devices that include mechanisms to mitigate quality of service issues . Any inquiry concerning this communication or earlier communications from the examiner should be directed to FAISAL M ZAMAN whose telephone number is (571)272-6495. The examiner can normally be reached Monday - Friday, 8 am - 5 pm, alternate Fridays. 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, Andrew J. Jung can be reached at 571-270-3779. 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. /FAISAL M ZAMAN/ Primary Examiner, Art Unit 2175 Application/Control Number: 18/914,582 Page 2 Art Unit: 2175 Application/Control Number: 18/914,582 Page 3 Art Unit: 2175 Application/Control Number: 18/914,582 Page 4 Art Unit: 2175 Application/Control Number: 18/914,582 Page 5 Art Unit: 2175 Application/Control Number: 18/914,582 Page 6 Art Unit: 2175 Application/Control Number: 18/914,582 Page 7 Art Unit: 2175 Application/Control Number: 18/914,582 Page 8 Art Unit: 2175 Application/Control Number: 18/914,582 Page 9 Art Unit: 2175 Application/Control Number: 18/914,582 Page 10 Art Unit: 2175
Prosecution Insights