Prosecution Insights
Last updated: October 22, 2026
Application No. 18/987,187

METHOD AND DEVICE FOR UPDATING BOOT SOFTWARE

Non-Final OA §103§112
Filed
Dec 19, 2024
Priority
Jan 12, 2024 — RE 10-2024-0005140
Examiner
NIGATU, BEZA DIRESSA
Art Unit
Tech Center
Assignee
Hyundai Autoever Corp.
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-60.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
12 currently pending
Career history
18
Total Applications
across all art units
This examiner has no resolved cases yet (career too new); statute-level performance unavailable. The Grant Probability card shows Tech Center averages instead.

Office Action

§103 §112
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 . This action is in response to the application filed on 12/19/2024. Priority Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Information Disclosure Statement The information disclosure statement (IDS) submitted on 12/19/2024 is in compliance with the provisions of 37 CFR 1.97 and is being considered by the examiner. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 5 and 13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor regards as the invention. In Claim 5, lines 3-4 and lines 6-7, it is unclear whether “the boot checksum” refers to “a boot checksum” in line 3 of claim 2 or in line 5 of claim 4. For the purposes of examination, “a boot checksum” in line 5 of claim 4 will be treated as --the boot checksum--. In Claim 13, lines 3-4 and lines 6-7, it is unclear whether “the boot checksum” refers to “a boot checksum” in line 4 of claim 10 or in line 6 of claim 12. For the purposes of examination, the examiner will interpret the claim limitation in claim 13 to refer to claim 12. 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-5, 7, 9-13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Duval (U.S. Publication No. 2021/ 0157563 A1, hereinafter Duval) in view of Lee et al. (U.S. Publication No. 2008/0040598 A1, hereinafter Lee). Regarding Claim 1, Duval discloses, “A method for updating boot software, the method being performed by a computing device, the method comprising” (In paragraph [0006], “FIG. 1 is a block diagram illustrating a computer system for managing software updates”. In paragraph [0015], “the software update may comprise a boot program”. In paragraph [0041], “The method (200) additionally modifies the booting preference of the secure storage device to boot off of the first portion that includes an updated software image”.). Duval does not disclose however Lee discloses, “storing a new boot to a buffer area” (In paragraph [0041], “initial boot loader 60 load further boot code into SRAM buffers”.); “in response to success of the storing the new boot, removing an existing boot of an update target host” (In paragraph [0063], “Once the running checksum is zero, writing was successful. Access to the old copy of the control program is disabled by erasing its entry block”. In paragraph [0029], “Blocks A, B, C can store blocks of boot or operating system (OS) code”. In paragraph [0043], “the control program run on the external host's CPU”.); “copying the new boot to a boot area of the update target host” (In paragraph [0063], “A copy of the entry block is made, and the entry address for the updated control program is written into the copy of the entry block, step 290. The new entry block then replaces the old entry block, and the upgrade is complete”. In paragraph [0029], “Additional boot code, control programs, and OS images are … loaded into SRAM buffers 154 for execution by the CPU … Once this CPU is booted and running its OS, more boot code for the external host may be read from MLC flash memory 152 and sent to the host, so that the host can be booted”.); “and deleting the new boot stored in the buffer area” (In paragraph [0062], “The newly-written control program is read and a running checksum is generated and compared to zero, step 286. When the running checksum is non-zero, the write may be repeated”. In paragraph [0067], “In FIG. 10B, copy B is upgraded. The block with copy B is erased, step 322, and the upgrade is programmed into the erased block”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 9, Duval discloses, “A computing system having a boot software update function, the computing system comprising” (In paragraph [0006], “FIG. 1 is a block diagram illustrating a computer system for managing software updates”. In paragraph [0015], “the software update may comprise a boot program”.); “a host including a boot area in which an existing boot is stored” (In paragraph [0031], “the method (200) simultaneously saves the existing content of the first portion into memory”. In paragraph [0015], “maintain a system state across boot sequences that allows the secure storage device to revert the system to its previous state”. In paragraph [0050], “the recovery block comprises a pointer to the boot code location stored in the first portion”.); “and a secure boot module including a random access memory (RAM), wherein the secure boot module is configured to: store a new boot for the host to a buffer area formed in the RAM” (In paragraph [0087], “the memory system (604) can comprise a secure storage device as described previously. In the illustrated embodiment, memory system (604) includes SRAM”. In paragraph [0032], “the method (200) configures a second portion of a secure storage device to operate in a write-protected mode. This first portion is also referred to as the “software update buffer space.””. In paragraph [0015], “the software update may comprise a boot program”.). Duval does not disclose however Lee discloses, “remove an existing boot of the host from the boot area of the host in response to success of the storing the new boot”; (In paragraph [0063], “Once the running checksum is zero, writing was successful. Access to the old copy of the control program is disabled by erasing its entry block”.); “copy the new boot stored in the buffer area to the boot area of the host” (In paragraph [0063], “A copy of the entry block is made, and the entry address for the updated control program is written into the copy of the entry block, step 290. The new entry block then replaces the old entry block, and the upgrade is complete”. In paragraph [0029], “Additional boot code, control programs, and OS images are … loaded into SRAM buffers 154 for execution by the CPU … Once this CPU is booted and running its OS, more boot code for the external host may be read from MLC flash memory 152 and sent to the host, so that the host can be booted”.); “and delete the new boot stored in the buffer area” (In paragraph [0062], “The newly-written control program is read and a running checksum is generated and compared to zero, step 286. When the running checksum is non-zero, the write may be repeated”. In paragraph [0067], “In FIG. 10B, copy B is upgraded. The block with copy B is erased, step 322, and the upgrade is programmed into the erased block”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 2, Duval does not disclose however Lee discloses, “generating a reference checksum using a boot of a boot checksum check target” (In paragraph [0064], “A pre-calculated checksum is received with the upgraded program, and this pre-calculated checksum is written to the end of the block, step 306. The pre-calculated checksum causes the final running checksum to be zero when no errors occur”. In paragraph [0065], “generating a running checksum that includes the pre-calculated checksum stored in flash”.); “and when a boot checksum stored in a non-volatile memory of a secure boot module is different from the reference checksum, stopping a booting using a boot of the update target host” (In paragraph [0050], “The last bytes of the copy of boot code 62 includes a stored checksum, which is included when generating the running checksum”. In paragraph [0056], “external-host control program 56 include a stored checksum”. In paragraph [0055], “external-host control program 56 are read from flash memory”. In paragraph [0005], “Flash memories use non-volatile memory cells”. In paragraph [0050], “The stored checksum is calculated so that the final running checksum should be 0 when no errors occurred … The third stage of booting can proceed”. In paragraph [0058], “When a copy was successfully loaded with a zero final running checksum, step 262, then microcontroller 168 generates a ready signal to the external host”. In paragraph [0057], “Should the final running checksum for copy-B be zero, then the next stage of booting can proceed, step 266. Otherwise, loading may be reattempted some number of times before device booting is abandoned”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 10, Duval does not disclose however Lee discloses, “wherein the secure boot module is further configured to: generate a reference checksum using a boot of a boot checksum check target” (In paragraph [0064], “A pre-calculated checksum is received with the upgraded program, and this pre-calculated checksum is written to the end of the block, step 306. The pre-calculated checksum causes the final running checksum to be zero when no errors occur”. In paragraph [0065], “generating a running checksum that includes the pre-calculated checksum stored in flash”.); “and stop a booting using a boot of an update target host when a boot checksum stored in a non-volatile memory of the secure boot module and the reference checksum are different from each other” (In paragraph [0050], “The last bytes of the copy of boot code 62 includes a stored checksum, which is included when generating the running checksum”. In paragraph [0056], “external-host control program 56 include a stored checksum”. In paragraph [0055], “external-host control program 56 are read from flash memory”. In paragraph [0005], “Flash memories use non-volatile memory cells”. In paragraph [0050], “The stored checksum is calculated so that the final running checksum should be 0 when no errors occurred … The third stage of booting can proceed”. In paragraph [0058], “When a copy was successfully loaded with a zero final running checksum, step 262, then microcontroller 168 generates a ready signal to the external host”. In paragraph [0057], “Should the final running checksum for copy-B be zero, then the next stage of booting can proceed, step 266. Otherwise, loading may be reattempted some number of times before device booting is abandoned”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 3, Duval does not disclose however Lee discloses, “wherein generating the reference checksum includes obtaining the boot checksum check target from secure boot module configuration data stored in the non-volatile memory of the secure boot module” (In paragraph [0065], “generating a running checksum that includes the pre-calculated checksum stored in flash”. In paragraph [0044], “Flash memory 50 also stores user data 54 and configuration data 52”. In paragraph [0045], “The flash configuration or flash ID is then read … using an X90 command generated by the boot-loader state machine”. In paragraph [0005], “Flash memories use non-volatile memory cells). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 11, Duval does not disclose however Lee discloses, “wherein, when generating the reference checksum, the secure boot module is configured to obtain the boot checksum check target from secure boot module configuration data stored in the non-volatile memory of the secure boot module” (In paragraph [0065], “generating a running checksum that includes the pre-calculated checksum stored in flash”. In paragraph [0044], “Flash memory 50 also stores user data 54 and configuration data 52”. In paragraph [0045], “The flash configuration or flash ID is then read … using an X90 command generated by the boot-loader state machine”. In paragraph [0005], “Flash memories use non-volatile memory cells). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 4, Duval does not disclose however Lee discloses, “wherein removing the existing boot of the update target host in response to the success of the storing the new boot includes: generating a boot checksum of the new boot using the new boot in response to the success of downloading” (In paragraph [0065], “The upgraded copy just written to flash is verified by reading the copy and generating a running checksum … When this final running checksum is zero … Upgrading can continue”. In paragraph [0050], “The last bytes of the copy of boot code 62 includes a stored checksum, which is included when generating the running checksum”. In paragraph [0064], “FIGS. 10A-B are flowcharts of upgrading both copies. Both copies of … boot code may be upgraded using this procedure … an upgrade command is received, first copy A is processed … The block with copy A is erased, step 302, and the upgrade is programmed into the erased block”.); “updating a boot checksum stored in the non-volatile memory of the secure boot module” (In paragraph [0065], “The upgraded copy just written to flash is verified by reading the copy and generating a running checksum that includes the pre-calculated checksum stored in flash”. In paragraph [0056], “A running checksum is updated for each byte read from flash, step 260. The last bytes of the copy of external-host control program 56 include a stored checksum, which is included when generating the running checksum”.); “setting the boot checksum check target to the buffer area” (In paragraph [0055], “Copy-A of OS image 58 and later copy-A of external-host control program 56 are read from flash memory and written to BLK C in SRAM buffer”.); “and after completion of the setting, removing the existing boot of the update target host” (In paragraph [0064], “The block with copy A is erased, step 302, and the upgrade is programmed into the erased block”. In paragraph [0065], “no errors are detected. Upgrading can continue with copy B”. In paragraph [0067], “In FIG. 10B, copy B is upgraded. The block with copy B is erased, step 322, and the upgrade is programmed into the erased block”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 12, Duval does not disclose however Lee discloses, “wherein, when removing the existing boot of the update target host in response to the success of the storing the new boot, the secure boot module is configured to: generate a boot checksum of the new boot using the new boot in response to the success of the storing the new boot” (In paragraph [0065], “The upgraded copy just written to flash is verified by reading the copy and generating a running checksum … When this final running checksum is zero … Upgrading can continue”. In paragraph [0050], “The last bytes of the copy of boot code 62 includes a stored checksum, which is included when generating the running checksum”. In paragraph [0064], “FIGS. 10A-B are flowcharts of upgrading both copies. Both copies of … boot code may be upgraded using this procedure … an upgrade command is received, first copy A is processed … The block with copy A is erased, step 302, and the upgrade is programmed into the erased block”.); “update a boot checksum stored in the non-volatile memory of the secure boot module” (In paragraph [0065], “The upgraded copy just written to flash is verified by reading the copy and generating a running checksum that includes the pre-calculated checksum stored in flash”. In paragraph [0056], “A running checksum is updated for each byte read from flash, step 260. The last bytes of the copy of external-host control program 56 include a stored checksum, which is included when generating the running checksum”.); “set the boot checksum check target to the buffer area” (In paragraph [0055], “Copy-A of OS image 58 and later copy-A of external-host control program 56 are read from flash memory and written to BLK C in SRAM buffer”.); “and remove the existing boot of the update target host after completion of the setting” (In paragraph [0064], “The block with copy A is erased, step 302, and the upgrade is programmed into the erased block”. In paragraph [0065], “no errors are detected. Upgrading can continue with copy B”. In paragraph [0067], “In FIG. 10B, copy B is upgraded. The block with copy B is erased, step 322, and the upgrade is programmed into the erased block”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 5, Duval does not disclose however Lee discloses, “wherein the new boot includes a predefined marker pattern in a pre-specified offset” (In paragraph [0050], “The last bytes of the copy of boot code 62 includes a stored checksum … The stored checksum is calculated”. In paragraph [0048], “Once the boot-loader state machine has loaded initial boot loader 60 into SRAM buffer … the reset of microcontroller 168 activates the routine of FIG. 6”. In paragraph [0049], “begins by reading the first address in BLK A of SRAM buffer ... These instructions set the address of flash interface 150 to read copy-A of boot code”. In paragraph [0030], “Once the host is booted, mappings from host (logical) addresses to flash (physical) addresses may be stored in mapping table 170 … that correspond to the logical addresses”.); “wherein stopping the booting using the boot of the update target host when the boot checksum stored in the non-volatile memory of the secure boot module is different from the reference checksum includes: performing a previous update success determination process when the boot checksum stored in the non-volatile memory of the secure boot module is identical with the reference checksum” (In paragraph [0056], “The stored checksum is calculated so that the final running checksum should be 0 when no errors occurred”. In paragraph [0057], “when the final running checksum was not zero, step 262, then an error was detected. The fetch address for flash interface 150 is changed to the initial address of Copy-B OS image 59 (FIG. 4), step 264, and fetching is repeated”. In paragraph [0058], “a copy was successfully loaded with a zero final running checksum”.); “wherein the previous update success determination process includes: identifying presence or absence of the predefined marker pattern in the pre-specified offset of the buffer area” (In paragraph [0056], “The last bytes of the copy of external-host control program 56 include a stored checksum … The stored checksum is calculated so that the final running checksum should be 0 when no errors occurred”.); “determining presence or absence of the new boot stored in the buffer area, based on an identifying result; and upon determination that the new boot stored in the buffer area is present, retrying an update process using the new boot stored in the buffer area” (In paragraph [0057], “Should the final running checksum for copy-B be zero, then the next stage of booting can proceed, step 266. Otherwise, loading may be reattempted some number of times before device booting is abandoned”. In paragraph [0051], “when the final running checksum was not zero, step 242, then an error was detected. The fetch address for flash interface 150 is changed to the initial address of Copy-B boot code … and fetching is repeated … loading may be reattempted some number of times before device booting is abandoned”. In paragraph [0058], “When a copy was successfully loaded with a zero final running checksum … The external host then reads and executes external-host control program 56 using OS image 58 that is read by the external host from BLK C of SRAM buffer”. In paragraph [0064], “FIGS. 10A-B are flowcharts of upgrading both copies … boot code may be upgraded using this procedure”. In paragraph [0065], “The upgraded copy just written to flash is verified by reading the copy”. In paragraph [0066], “upgrading fails and the user is notified, step 316. Otherwise, upgrading is re-attempted”. In paragraph [0067], “In FIG. 10B, copy B is upgraded … The pre-calculated checksum causes the final running checksum to be zero when no errors occur”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 13, Duval does not disclose however Lee discloses, “wherein the new boot includes a predefined marker pattern in a pre-specified offset” (In paragraph [0050], “The last bytes of the copy of boot code 62 includes a stored checksum … The stored checksum is calculated”. In paragraph [0048], “Once the boot-loader state machine has loaded initial boot loader 60 into SRAM buffer … the reset of microcontroller 168 activates the routine of FIG. 6”. In paragraph [0049], “begins by reading the first address in BLK A of SRAM buffer ... These instructions set the address of flash interface 150 to read copy-A of boot code”. In paragraph [0030], “Once the host is booted, mappings from host (logical) addresses to flash (physical) addresses may be stored in mapping table 170 … that correspond to the logical addresses”.); “wherein, when stopping the booting using the boot of the update target host when the boot checksum stored in the non-volatile memory of the secure boot module is different from the reference checksum, the secure boot module is configured to: perform a previous update success determination process when the boot checksum stored in the non-volatile memory of the secure boot module is identical with the reference checksum” (In paragraph [0056], “The stored checksum is calculated so that the final running checksum should be 0 when no errors occurred”. In paragraph [0057], “when the final running checksum was not zero, step 262, then an error was detected. The fetch address for flash interface 150 is changed to the initial address of Copy-B OS image 59 (FIG. 4), step 264, and fetching is repeated”. In paragraph [0058], “a copy was successfully loaded with a zero final running checksum”.); “wherein, when performing the previous update success determination process, the secure boot module is configured to: identify presence or absence of the predefined marker pattern in the pre-specified offset of the buffer area” (In paragraph [0056], “The last bytes of the copy of external-host control program 56 include a stored checksum … The stored checksum is calculated so that the final running checksum should be 0 when no errors occurred”.); “determine presence or absence of the new boot stored in the buffer area, based on an identifying result; and upon determination that the new boot stored in the buffer area is present, retry an update process using the new boot stored in the buffer area” (In paragraph [0057], “Should the final running checksum for copy-B be zero, then the next stage of booting can proceed, step 266. Otherwise, loading may be reattempted some number of times before device booting is abandoned”. In paragraph [0051], “when the final running checksum was not zero, step 242, then an error was detected. The fetch address for flash interface 150 is changed to the initial address of Copy-B boot code … and fetching is repeated … loading may be reattempted some number of times before device booting is abandoned”. In paragraph [0058], “When a copy was successfully loaded with a zero final running checksum … The external host then reads and executes external-host control program 56 using OS image 58 that is read by the external host from BLK C of SRAM buffer”. In paragraph [0064], “FIGS. 10A-B are flowcharts of upgrading both copies … boot code may be upgraded using this procedure”. In paragraph [0065], “The upgraded copy just written to flash is verified by reading the copy”. In paragraph [0066], “upgrading fails and the user is notified, step 316. Otherwise, upgrading is re-attempted”. In paragraph [0067], “In FIG. 10B, copy B is upgraded … The pre-calculated checksum causes the final running checksum to be zero when no errors occur”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 7, Duval does not disclose however Lee discloses, “after deleting the new boot stored in the buffer area, setting a boot checksum check target to the boot area of the update target host” (In paragraph [0067], “In FIG. 10B, copy B is upgraded. The block with copy B is erased, step 322, and the upgrade is programmed into the erased block, step 324. A pre-calculated checksum received with the upgraded program is written to the end of the block, step 326. The pre-calculated checksum causes the final running checksum to be zero when no errors occur”. In paragraph [0057], “Should the final running checksum for copy-B be zero, then the next stage of booting can proceed”. In paragraph [0060], “accepts the first-reset read address from the external host during a late stage of booting, and loads this host address into mapping table 170 in an entry”. In paragraph [0055], “set the address of flash interface 150 to read copy-A of OS image 58 and later to read copy-A of external-host control program 56 from MLC flash memory”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Regarding Claim 15, Duval does not disclose however Lee discloses, “wherein the secure boot module is further configured to set a boot checksum check target to the boot area of an update target host after deleting the new boot stored in the buffer area” (In paragraph [0067], “In FIG. 10B, copy B is upgraded. The block with copy B is erased, step 322, and the upgrade is programmed into the erased block, step 324. A pre-calculated checksum received with the upgraded program is written to the end of the block, step 326. The pre-calculated checksum causes the final running checksum to be zero when no errors occur”. In paragraph [0057], “Should the final running checksum for copy-B be zero, then the next stage of booting can proceed”. In paragraph [0060], “accepts the first-reset read address from the external host during a late stage of booting, and loads this host address into mapping table 170 in an entry”. In paragraph [0055], “set the address of flash interface 150 to read copy-A of OS image 58 and later to read copy-A of external-host control program 56 from MLC flash memory”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Claims 6, 8, 14, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Duval in view of Lee as applied to claims 1, 7, 9, and 15 above, and further in view of Chen (U.S. Publication No. 2007/0050612 A1, hereinafter Chen). Regarding Claim 6, Duval does not disclose however Lee discloses, “wherein copying the new boot to the boot area of the update target host includes” (In paragraph [0063], “A copy of the entry block is made, and the entry address for the updated control program is written into the copy of the entry block”. In paragraph [0052], “Both one copy of control program 66, 67, and one copy of boot code 62, 63 can be loaded into BLK B”. In paragraph [0054], “instructions in BLK B that are being executed in FIG. 7 are part of control program 66 (or control program 67)”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Duval as modified does not disclose however Chen discloses, “storing a boot update flag” (In paragraph [0008], “a boot program update and restoration method and system by checking the stored flag values to detect the status of the boot programs”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Duval by adopting the teachings of a flag to signify a boot update by Chen; motivated by the common goal to provide “a boot program update and restoration method and system” (Chen [0008]), “in order to best utilize the new hardware” and when “a computer-based platform becomes unworkable due to some unexpected factors resulting from the damage of the boot program” (Chen [0005]). Regarding Claim 14, Duval does not disclose however Lee discloses, “wherein, when copying the new boot to the boot area of an update target host, the secure boot module is configured to” (In paragraph [0063], “A copy of the entry block is made, and the entry address for the updated control program is written into the copy of the entry block”. In paragraph [0052], “Both one copy of control program 66, 67, and one copy of boot code 62, 63 can be loaded into BLK B”. In paragraph [0054], “instructions in BLK B that are being executed in FIG. 7 are part of control program 66 (or control program 67)”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Duval as modified does not disclose however Chen discloses, “store a boot update flag” (In paragraph [0008], “a boot program update and restoration method and system by checking the stored flag values to detect the status of the boot programs”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Duval by adopting the teachings of a flag to signify a boot update by Chen; motivated by the common goal to provide “a boot program update and restoration method and system” (Chen [0008]), “in order to best utilize the new hardware” and when “a computer-based platform becomes unworkable due to some unexpected factors resulting from the damage of the boot program” (Chen [0005]). Regarding Claim 8, Duval does not disclose however Lee discloses, “wherein setting the boot checksum check target to the boot area of the update target host further includes” (In paragraph [0067], “A pre-calculated checksum received with the upgraded program is written to the end of the block, step 326”. In paragraph [0068], “the pre-calculated checksum stored in flash”. In paragraph [0038], “boot code stored in a flash memory”. In paragraph [0025], “Flash device 140 is plugged into host”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Duval as modified does not disclose however Chen discloses, “deleting a boot update flag” (In paragraph [0015], “the update signal is also sent to the dynamic access memory unit 40 to reset the flag value. The flag value is set after the update of the boot program is completed”.). (Examiner’s Note: The examiner interprets the reset of the flag in Chen (paragraph [0015]) to disclose the claimed deletion of the flag. The examiner obtains the claim interpretation with support of the examined case specification’s paragraph [0060], “the secure boot module may perform a reset operation to delete the new boot”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Duval by adopting the teachings of a flag to signify a boot update by Chen; motivated by the common goal to provide “a boot program update and restoration method and system” (Chen [0008]), “in order to best utilize the new hardware” and when “a computer-based platform becomes unworkable due to some unexpected factors resulting from the damage of the boot program” (Chen [0005]). Regarding Claim 16, Duval does not disclose however Lee discloses, “wherein, when setting the boot checksum check target to the boot area of the update target host, the secure boot module is configured to” (In paragraph [0067], “A pre-calculated checksum received with the upgraded program is written to the end of the block, step 326”. In paragraph [0068], “the pre-calculated checksum stored in flash”. In paragraph [0038], “boot code stored in a flash memory”. In paragraph [0025], “Flash device 140 is plugged into host”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Duval by adopting the teachings of Lee; motivated by the common goal for “enhanced booting performance” (Lee [0012]), such as by providing a way to cope with an unexpected situation when an error occurs during an update of an electronic device (Lee [0069], [0079]) where, “The upgraded copy just written to flash is verified” (Lee [0068]). Duval as modified does not disclose however Chen discloses, “delete a boot update flag” (In paragraph [0015], “the update signal is also sent to the dynamic access memory unit 40 to reset the flag value. The flag value is set after the update of the boot program is completed”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Duval by adopting the teachings of a flag to signify a boot update by Chen; motivated by the common goal to provide “a boot program update and restoration method and system” (Chen [0008]), “in order to best utilize the new hardware” and when “a computer-based platform becomes unworkable due to some unexpected factors resulting from the damage of the boot program” (Chen [0005]). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Hildebrand (U.S Publication No. 2022/0326961 A1), relating to the use of boot updates on vehicles, specifically in Figure 4. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Beza D Nigatu whose telephone number is (571)272-9643. The examiner can normally be reached Monday - Friday 7:30am-3:30pm. 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, Hyung Sough can be reached at (571) 272-6799. 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. /BEZA D NIGATU/Examiner, Art Unit 2192 /S. Sough/SPE, Art Unit 2192
Read full office action

Prosecution Timeline

Dec 19, 2024
Application Filed
Oct 09, 2026
Non-Final Rejection mailed — §103, §112 (current)

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

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 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