DETAILED ACTION
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 .
Claim Status
Claims 1-20 are pending
Claims 1-3, 5-10, 12-16 and 18-20 are rejected under 35 USC § 103
Claims 4, 11 and 17 are objected to
Information Disclosure Statement
No IDS was submitted with this amendment and hence nothing new was considered.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-10, 12-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over ISAO K et al. (WO 2021200926 A1)[Isao]
Regarding claim 1 Isao discloses:
A method comprising: in response to receiving power, transferring a bootloader from a memory subsystem to a host system coupled to the memory subsystem (Isao: Abstract: The storage system (100) has a controller (111) to control writing/read-out of a data with respect to a non-volatile memory (112). A bootloader read from the nonvolatile memory is transferred to a host device (150).);
receiving an indication that a host memory buffer (HMB) has been allocated within the host system (Isao: as per attached pdf: [0092-0095], Fig. 9: teaches after canceling the reset that is executed after the power is turned on (power ON), etc., the internal ROM program for booting is executed. The built-in ROM program for booting executes the setting process (terminal setting, register setting) for accessing the SD interface. In this process, the CMD820 of the SD interfaces 1240 and (115 in Fig. 1) is driven to "L", whereby the SD interfaces 1240 and 115 enter the boot operation mode. So, setting CMD820 to low ('L') is similar to indication of host memory buffer (HMB) being allocated to the host that triggers transferring boot data); and
in response to the indication, transferring boot data from the memory subsystem to the HMB, wherein the memory subsystem uses a data structure to select the boot data for transfer and wherein the memory subsystem stores the data structure prior to transferring the bootloader (Isao: as per attached pdf:[0095-0107], Fig. 9: teaches - once the CMD820 of the SD interfaces 1240 and 115 is driven to "L", the SD interfaces 1240 and 115 enter the boot operation mode. The checksum (512 bytes) for the boot loader stored in the non-volatile memory of the storage system is transferred to the main memory via the SD interfaces 1240 and 115. (Boot operation 1203) (4) Transfer the boot loader stored in the non-volatile memory of the storage system to the main memory via the SD interfaces 1240 and 115. (Boot operation 1204).
Spec [0043] discloses '...The data structure indicates, for each different boot data to be transferred, a source location (representing an area of the memory subsystem l l0's non-volatile memory where the boot data is stored) and a target location representing an area of the host system 120 memory where the boot data is to be transferred. The data structure may be received from the host system 120.
Configuring host for loading boot data fast and triggering the boot load at startup implies what to load, from/to where to load also indicates the spec defined data structure is known/stored to the memory/host system prior to starting the load.).
Regarding claim 8 A system comprising: a memory component (Isao: Fig. 6, Main Memory 980); and a processing device (Isao: Fig. 6, CPU 965), coupled to the memory component (Isao: Fig. 6, link 981), configured to: in response to receiving power, transfer a bootloader to a host system (Isao: Abstract: The storage system (100) has a controller (111) to control writing/read-out of a data with respect to a non-volatile memory (112). A bootloader read from the nonvolatile memory is transferred to a host device (150).),
receive an indication that a host memory buffer (HMB) has been allocated within the host system (Isao: as per attached pdf: [0092-0095], Fig. 9: teaches after canceling the reset that is executed after the power is turned on (power ON), etc., the internal ROM program for booting is executed. The built-in ROM program for booting executes the setting process (terminal setting, register setting) for accessing the SD interface. In this process, the CMD820 of the SD interfaces 1240 and (115 in Fig. 1) is driven to "L", whereby the SD interfaces 1240 and 115 enter the boot operation mode. So, setting CMD820 to low ('L') is similar to indication of host memory buffer (HMB) being allocated to the host that triggers transferring boot data),
in response to the indication, transfer boot data from the memory component to the HMB, wherein the processing device uses a data structure stored in the memory component to select the boot data for transfer (Isao: as per attached pdf:[0095-0107], Fig. 9: teaches - once the CMD820 of the SD interfaces 1240 and 115 is driven to "L", the SD interfaces 1240 and 115 enter the boot operation mode. The checksum (512 bytes) for the boot loader stored in the non-volatile memory of the storage system is transferred to the main memory via the SD interfaces 1240 and 115. (Boot operation 1203) (4) Transfer the boot loader stored in the non-volatile memory of the storage system to the main memory via the SD interfaces 1240 and 115. (Boot operation 1204).
Spec [0043] discloses '...The data structure indicates, for each different boot data to be transferred, a source location (representing an area of the memory subsystem l l0's non-volatile memory where the boot data is stored) and a target location representing an area of the host system 120 memory where the boot data is to be transferred. The data structure may be received from the host system 120.
Configuring host for loading boot data fast and triggering the boot load at startup implies what to load, from/to where to load also indicates the spec defined data structure is known/stored to the memory/host system prior to starting the load), and
set a buffer flag to indicate the boot data was transferred, the buffer flag associated with a buffer in the HMB where the boot data was transferred (Isao: [0109]: teaches the timing 1012 is a timing at which the boot loader transfer from the storage system 100 to the host device 150 is completed, the CMD line 820 of the SD interface 115 is set to “H”, and the boot operation is terminated. So transitioning the CMD line 820 from low to high is similar to the flag that indicates if boot loader transfer is complete.
Spec [0014] discloses, '... Once data is transferred, a flag is updated indicating that the data is in the host's memory. The host checks the flag(s) before issuing requests for data. If the flag is present, the host accesses the data from its own memory instead of requesting it from the memory subsystem, thereby speeding up the boot process and reducing memory subsystem idle time.' Spec [0035] discloses, 'In some cases, after memory subsystem 110 transfers one of boot data Data-1-N to the host system 120 memory, the memory subsystem 110 sets a respective flag (e.g. a "ready" flag) associated with a host system 120 memory buffer to indicate that the boot data has been transferred to the associated memory buffer. The flag may be set at a target buffer at the end of the buffer (e.g., portion of the HMB) to which the data was transferred. The host system 120 checks the flag to see if the requested data was transferred using a predefined read. If the flag is not set (e.g. the host system 120 memory doesn't support direct memory writes using HMB, the predefined read failed, etc.), the host system 120 issues a read command for the requested data.' So, the flag is a physical bit that can be set/reset and read/use later to make decision.
In Isao Fig. 8 SD interface CMD (command line) 820 and (Fig. 9 SD interface CMD (command line) 920 is a physical line between host side and storage device side SD interface block and its high/low (H/L) status can be read/use later to make decisions.).
Regarding claim 14, this is a computer-readable storage medium (CRSM) claim corresponding to the method claim 1 and is rejected for the same reasons mutatis mutandis.
Regarding claim 2 Isao discloses: The method of claim 1, wherein the data structure indicates, for each of a plurality of boot data to be transferred, a source location and a target location, wherein the source location represents an area of non-volatile memory of the memory subsystem where the boot data is stored, and wherein the target location represents an area of the HMB where the boot data is to be transferred (Isao:as per attached pdf:[0086-0106], Fig. 9: discloses non-volatile memory 1260 containing an area (source location) for bootloader and SoC Main Memory (DRAM) 1230 containing an area (target location) for bootloader. Isao:[0096-0097], Fig. 9: teaches the checksum (512 bytes) for the boot loader stored in the non-volatile memory of the storage system is transferred to the main memory via the SD interfaces 1240. Also, transfers the boot loader stored in the non-volatile memory of the storage system to the main memory via the SD interfaces 1240 as shown by the arrow in the Fig. 9 indicating source and target locations.).
Regarding claim 9, this is a system claim corresponding to the method claim 2 and is rejected for the same reasons mutatis mutandis.
Regarding claim 15, this is a computer-readable storage medium (CRSM) claim corresponding to the method claim 2 and is rejected for the same reasons mutatis mutandis.
Regarding claim 3 Isao discloses: The method of claim 2, wherein the data structure indicates, for each of the plurality of boot data, an amount of data to transfer (Isao: as per attached pdf: [0098], Fig. 9: discloses Calculating the checksum value from the boot loader data transferred to the main memory, and comparing it with the boot loader checksum value transferred from the non-volatile memory of the storage system to the main memory.
Transferring boot data and calculating checksum on boot data and the dedicated area for boot loader in non-volatile memory and host memory (HMB) implies a set/fixed amount of data being transferred and hence the amount of data is part of the data structure along with source and target location).
Regarding claim 10, this is a system claim corresponding to the method claim 3 and is rejected for the same reasons mutatis mutandis.
Regarding claim 16, this is a computer-readable storage medium (CRSM) claim corresponding to the method claim 3 and is rejected for the same reasons mutatis mutandis.
Regarding claim 5 Isao discloses: The method of claim 1, further comprising: setting a buffer flag in the HMB to indicate the boot data was transferred, the buffer flag associated with a buffer in the HMB where the boot data was transferred (Isao: [0109]: teaches the timing 1012 is a timing at which the boot loader transfer from the storage system 100 to the host device 150 is completed, the CMD line 820 of the SD interface 115 is set to “H”, and the boot operation is terminated. So transitioning the CMD line 820 from low to high is similar to the flag that indicates if boot loader transfer is complete.
Spec [0014] discloses, '... Once data is transferred, a flag is updated indicating that the data is in the host's memory. The host checks the flag(s) before issuing requests for data. If the flag is present, the host accesses the data from its own memory instead of requesting it from the memory subsystem, thereby speeding up the boot process and reducing memory subsystem idle time.' Spec [0035] discloses, 'In some cases, after memory subsystem 110 transfers one of boot data Data-1-N to the host system 120 memory, the memory subsystem 110 sets a respective flag (e.g. a "ready" flag) associated with a host system 120 memory buffer to indicate that the boot data has been transferred to the associated memory buffer. The flag may be set at a target buffer at the end of the buffer (e.g., portion of the HMB) to which the data was transferred. The host system 120 checks the flag to see if the requested data was transferred using a predefined read. If the flag is not set (e.g. the host system 120 memory doesn't support direct memory writes using HMB, the predefined read failed, etc.), the host system 120 issues a read command for the requested data.' So, the flag is a physical bit that can be set/reset and read/use later to make decision.
In Isao Fig. 8 SD interface CMD (command line) 820 and (Fig. 9 SD interface CMD (command line) 920 is a physical line between host side and storage device side SD interface block and its high/low (H/L) status can be read/use later to make decisions.).
Regarding claim 18, this is a computer-readable storage medium (CRSM) claim corresponding to the method claim 5 and is rejected for the same reasons mutatis mutandis.
Regarding claim 6 Isao discloses: The method of claim 1, further comprising: receiving the data structure from the host system (Isao: as per attached pdf:[0095-0107], Fig. 9: teaches host system initiating and completing transfer of boot data. This implies host providing data structure to the storage which, as per spec [0043] includes boot data source and target location. Since host executes boot data transfer and executes booting operation - it implies host deciding boot data source and target location and providing it to the storage.).
Regarding claim 13, this is a system claim corresponding to the method claim 6 and is rejected for the same reasons mutatis mutandis.
Regarding claim 19, this is a computer-readable storage medium (CRSM) claim corresponding to the method claim 6 and is rejected for the same reasons mutatis mutandis.
Regarding claim 7 Isao discloses: The method of claim 1, wherein the memory subsystem includes a management interface for managing the data structure (Isao:Fig. 1, Fig. 9, [0038]-[0061]: teaches PCIe interface 114/116 and SD interface 115/117. These interfaces are used to manage (load/store/transfer) boot data and is similar to management interface managing data structure.).
Regarding claim 12, this is a system claim corresponding to the method claim 7 and is rejected for the same reasons mutatis mutandis.
Regarding claim 20, this is a computer-readable storage medium (CRSM) claim corresponding to the method claim 7 and is rejected for the same reasons mutatis mutandis.
Allowable Subject Matter
Claims 4, 11 and 17 are being objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim 4 recites, ‘The method of claim 1, wherein the data structure is a table in which each row of the table corresponds to a different boot data.’
Prior art Ke; Kuan-Yu et al. (US 11366596 B2)[Ke] Col4/ln66-col5/ln41, (13)-(14), Fig. 2: teaches host 200 transmits a write command CMD for writing several boot data BD1˜BD4 to the data storage device 100. The boot data BD1˜BD4 is a system file so that the initialization operation could be performed for booting by the host 200. The host 200 transmits the write command CMD to the data storage device 100. The write command CMD includes the size of data to be transmitted and information about the logical address and the logical partition (such as the logical unit number, LUN) of the data storage device 100 to be written to. When the data storage device 100 receives the write command CMD, the data storage device 100 transmits a response message RT1 to the host 200 to indicate that the host 200 could start transmitting the boot data BD1. After the host 200 receives the response message RT1, it transmits the boot data BD1 to the data storage device 100. After the data storage device 100 receives the boot data BD1, the data storage device 100 transmits the response message RT2 to the host 200 to indicate that the host 200 could start transmitting the boot data BD2. Similarly, the host 200 continuously transmits the boot data BD2 and BD3 to the data storage device 100. The data storage device 100 receives the boot data BD2 and BD3, and transmits the response messages RT3 and RT4 to the host 200 respectively. When the host 200 transmits the last boot data BD4, the data storage device 100 transmits a confirm message RUPIU to the host 200 to indicate the host 200 that the boot data BD1˜BD4 have been stored in the data storage device 100. While Ke teaches multiple boot data, Ke does not teach different boot data rather BD1-BD4 is a system file which is transferred into multiple chunks BD1-BD4. Also, there is no teaching of a table.
Prior art SASAKI KATSUHIKO et al. (JP 2004234151 A)[Sasaki] [0076]: teaches controller 6 determining whether the boot area is set to the forced update setting for executing the update of the different version program. If the forced update setting is set, the controller 6 advances the process to step S106. In the case of the setting not to execute, the controller 6 removes from the update execution data table from the update execution data table, the update program data table in which the version of the boot area of the received program data is different from the version of the current ROM boot area. The update execution data table corresponding to the update target program table is generated. While Sasaki teaches different version of boot data, it is not similar to what instant claim is teaching.
No, known prior art taken alone or in combination teach data structure as a table in which each row of the table corresponds to a different boot data.
Regarding claim 11, this is a system claim corresponding to the method claim 4 and is allowable for the same reasons mutatis mutandis.
Regarding claim 17, this is a computer-readable storage medium (CRSM) claim corresponding to the method claim 4 and is allowable for the same reasons mutatis mutandis.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is recorded in pe2e_search_note.pdf and is attached as OA.APPENDIX.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD S HASAN whose telephone number is (571)270-1737 and email address is mohammad.hasan@uspto.gov. The examiner can normally be reached on Mon-Fri 8-5.
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, Tim Vo can be reached on 571-272-3642. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/M.S.H/Examiner, Art Unit 2138
/SHAWN X GU/
Primary Examiner, AU2138
Prosecution Insights