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 .
Status of Claims
The present application is being examined under the claims filed 08/22/2025. Claims 2-4 have been incorporated into claim 1, claims 9-11 have been incorporated into claim 8, and claims 16-17 have been incorporated into claim 15. Amendments have been made to claims 1, 8, and 15. Claims 2-4, 9-11, and 16-17 have been canceled.
Claims 1, 5-8, 12-15, and 18-20 are pending. Claims 1, 5-8, 12-15, and 18-20 are rejected.
Response to Arguments
Applicant’s arguments with respect to claims 1, 5-8, 12-15 have been considered but are moot because the new ground of rejection does not rely on Ademir and Pillilli, applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Examiner notes that the scope of claim 1 (as well as claim 8 and 15) was changed by adding the limitation “the target command being input by a user” and the scope of claim 8 was further changed by clarifying the order of operations in response to the 112(b) raised in the previous office action.
Examiner notes Peterson is still relied upon, now as the base reference due to new ground of rejection necessitated by the amendments. Applicant argued that “naming components as "Miniboot / U-Boot" does not equate to teaching the specific interaction logic required by the present invention” and that “Peterson only demonstrates U-Boot as an SSBL and does not teach receiving and parsing an external command during U-Boot execution to trigger loading and execution of external code.” However, the new combination of Peterson, U-Boot Project, and Galos does teach all the limitations regarding the specific interaction logic required by the present invention, and Peterson is not relied upon for teaching the interaction.
Furthermore, examiner notes that according to applicant admitted prior art (AAPA), as written in the background second of the specification and response dated 08/22/2025, applicant states "ROM boot, Miniboot, U-boot, and Kernel are well known to people having ordinary skill in the art" (Instant app. par. 2 and FIG. 1) and "Miniboot and U-Boot are known boot loaders in the art" (8/22/2025 Remarks pg. 9), therefore the behaviors and structures of Miniboot and U-Boot would be known to someone of ordinary skill in the art.
Claim Rejections - 35 USC § 103
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.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 5-8, 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Peterson et. al. (US 9230112 B1) [previously cited] in view of Das U-Boot Project "u-boot/u-boot: Commit edca8cf" [NPL, henceforth referred to as U-Boot Project] and Mihai Galos "mihaigalos/miniboot: Commit 2586ab0" [NPL, henceforth referred to as Galos].
Regarding Claim 1, Peterson discloses an electronic device (Peterson FIG. 2, field programmable system-on-chip “FPSoC" system 200 [Note: FPSoC systems 200 of FIGS. 2 and 3 are used interchangeably, see Col. 8 Lines 31, 32]), wherein the electronic device is coupled to an external storage device (Peterson FIG. 2 and Col 6 Lines 1-7, FPSoC 220 is coupled to an external memory 210 "NVM 210"), and the external storage device stores a boot code of the electronic device (Peterson FIG. 2 and Col 6 Lines 10-12, memory (“NVM”) 210 may be used to store boot image), the electronic device comprising:
a memory (Peterson FIG. 2, on-chip random access memory "OCM" 227; or Peterson FIG. 3, RAM 304);
a storage control circuit configured to read a first segment of the boot code from the external storage device (Peterson Col. 10 Lines 5-7, CPU 306 executes ROM boot code 229 to load a first stage boot loader "FSBL" 21 [i.e., first segment of boot code]; also see FIG. 2, I/O MUX 221 [i.e., storage control circuit] responsible for reading the external memory), and write the first segment of the boot code into a memory block of the memory (Peterson Col. 8 Lines 35-40, FSBL 211 is written into memory OCM 227), wherein […] the boot code comprises a target code (Peterson Col. 11 Lines 11, boot image contains application partition 427 [i.e., target code]); and
a computing circuit configured to execute the target code in the memory block […] (Peterson Col. 10 Lines 15-18, FSBL 211 loads subsequent images from the boot image [which are executable by the CPU [i.e., computing circuit], see Col. 2 Lines 7-9, a CPU controls execution of secure boot]; and Col. 11 Lines 45-49, boot loaders [e.g., ROM boot loaders] to move partitions of a boot image from NVM to executable locations, for example, software partitions may be moved to DDR RAM);
wherein the boot code further comprises a second segment (Peterson Col. 10 Lines 13-15, a secondary stage bootloader (“SSBL") [i.e., second boot code segment] is loaded by FSBL), and […];
a [command] being input by a user (Peterson Col. 21 Lines, 43-45, secure boot flow 1000 may be controlled by a user);
[…], the [boot] being [controlled] by a user (Peterson Col. 21 Lines, 43-45, secure boot flow 1000 may be controlled by a user);
wherein the first segment of the boot code comprises a [first stage bootloader] code of a Linux system (Peterson Col. 10 Lines 5-9, executes such boot code 229 at 401 to load a FSBL 211 [i.e., first stage bootloader code]; and Peterson Col. 10 Lines 13-16, Linux Operating System "OS" is loaded for the system), and the second segment of the boot code comprises a U-boot code of the Linux system (Peterson Col. 10 Lines 13-16, SSBL is a U-Boot for a Linux Operating System "OS")[also see FIG. 5-3, showing exemplary boot image format with FSBL, U-Boot, and Linux partitions].
Peterson does not explicitly teach:
wherein the first segment of the boot code comprises a target code;
a computing circuit configured to execute the target code in the memory block in response to an interrupt;
the interrupt is generated while the computing circuit is executing the second segment of the boot code;
wherein the computing circuit detects whether a target command triggering the interrupt is received while executing the second segment of the boot code, the target command being input by a user;
wherein the first segment of the boot code comprises a Miniboot code of a Linux system;
In the analogous art of secure loading of an operating system, U-Boot Project teaches:
a [process] configured to execute the target code in the memory block in response to an interrupt (U-Boot Project pg. 90 Lines 3317-3319, U-Boot can dynamically load and "standalone" applications [also see e.g., at Lines 3326-3353, “standalone” program hello_world.c [i.e., target program] configured to run at an address 0x00040004 in response to a target command [e.g., “=> loads => examples/hello_world.srec” or “=> go 40004”], which interrupts running of U-Boot to run program; and pg. 7 Lines 20-25, U-Boot allows adding commands]);
the interrupt is generated while the [computing process] is executing the second segment of the boot code (U-Boot Project pg. 90 Lines 3317-3319, U-Boot [i.e., second segment of the boot code] can dynamically load and "standalone" applications [also see e.g., at Lines 3326-3353, “standalone” program hello_world.c [i.e., target program], [i.e., U-Boot is being run and the interrupt is generated within U-Boot command line interface]]);
wherein the [process] detects whether a target command triggering the interrupt is received while executing the second segment of the boot code (U-Boot Project pg. 90-91 Lines 3326-3353, a “standalone” program hello_world.c [i.e., target program] is run in response to a target command [e.g., “=> loads => examples/hello_world.srec” or “=> go 40004”] being entered into the U-Boot [i.e., second segment of boot code] command line interface), the target command being input by a user (U-Boot Project pg. 7 Lines 9-13, U-Boot used to initialize and test the hardware or to download and run application code; and Lines 20-25, referencing monitor commands [i.e., commands output to monitor] for use of U-Boot [e.g., at Lines 3326-3353 “=> loads => examples/hello_world.srec” or “=> go 40004”]);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Peterson and U-Boot Project before him, before the effective filing date of the claimed invention, to modify the second stage boot loader of Peterson to use the user-triggered target code execution disclosed by U-Boot Project. A person having ordinary skill in the art would recognize that Peterson was ready for improvement by using the known technique of using U-Boot commands to have a user execute an application located at a specific address as taught by U-Boot Project, which would provide the predictable result of allowing the user to control the boot process as described by Peterson (Peterson Col. 21 Lines, 43-45, secure boot flow 1000 may be controlled by a user).
Peterson in view of U-Boot Project does not explicitly teach:
wherein the first segment of the boot code comprises a target code;
wherein the first segment of the boot code comprises a Miniboot code of a Linux system;
In the analogous art of providing bootloaders for a device, Galos teaches:
wherein the first segment of the boot code comprises a target code (Galos pg. 3 Lines 51- 63, miniboot code [i.e., first segment of boot code] comprises a payload application [i.e., target code]);
wherein the first segment of the boot code comprises a Miniboot code of a […] system (Galos pg. 1 Lines 1 and 6, Miniboot is a bootloader for Arduino systems). Furthermore, examiner notes that according to applicant admitted prior art (AAPA), as written in the background section of the specification and response dated 08/22/2025, applicant states "ROM boot, Miniboot, U-boot, and Kernel are well known to people having ordinary skill in the art" (Instant app. par. 2 and FIG. 1, showing order of implementing ROM boot, Miniboot, U-boot, and Kernel) and "Miniboot and U-Boot are known boot loaders in the art" (8/22/2025 Remarks pg. 9);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Peterson, U-Boot Project, and Galos before him, before the effective filing date of the claimed invention, to modify the first stage boot loader of Peterson in view of U-Boot Project to use the first stage bootloader (Miniboot) containing a payload application as disclosed by Galos. A person having ordinary skill in the art would recognize that Peterson in view of U-Boot Project was ready for improvement by using the known technique of a known first-stage bootloader which can implement the disclosed target code as disclosed by Galos, which would provide the predictable result of providing a first-stage bootloader for use in Peterson with a means of storing a target application as disclosed by U-Boot Project.
Regarding Claim 5, Peterson in view of U-Boot Project and Galos discloses the electronic device of claim 1. Modified Peterson further discloses:
wherein the memory block is a first memory block (Peterson FIG. 5-4, FSBL partition 503 is stored in a first memory block),
the memory further comprises a second memory block (Peterson FIG- 5-4, additional partitions [e.g., one storing a second stage boot loader] are stored as additional memory blocks), and the target code and the U-boot code exchange data through the second memory block when executed (U-Boot Project pg. 91-92 Lines 3355-3399, e.g., timer.c [i.e., target program] detects interrupts sent to the U-Boot bootloader [i.e., the target code and the U-boot code are able to exchange data when executed])
Regarding Claim 6, Peterson in view of U-Boot Project, further in view of Galos and AAPA discloses the electronic device of claim 1. Modified Peterson further discloses:
wherein the electronic device further comprises a read-only memory (ROM) (Peterson FIG. 3 and Col. 8 Lines 9-19, PL 350 may include an array of electrically one-time programmable (“OTP”) [i.e., ROM] or other nonvolatile memory elements (e.g., “eFuses”) 354 ), and the target code is associated with a burning process of the ROM (Peterson Col. 8 Lines 9-23, PL 350 may include an array of electrically one-time programmable (“OTP”) or other nonvolatile memory elements (e.g., “eFuses”) [i.e., fuses are memory associated with a burning process] having programmed therein a public key; and Col. 8 Lines 33-41, key is used to authenticate boot images [which includes the boot image with the target code]).
Regarding Claim 7, Peterson in view of U-Boot Project and Galos discloses the electronic device of claim 1. Modified Peterson further discloses:
the Miniboot code comprises a branch command and a plain text, and the target code is stored between the branch command and the plain text in the memory (Galos pg. 3 Lines 52-63, miniboot code segment showing last free byte pointer [i.e., branch command] points to first byte after the application, followed by application [i.e., target code]; and Galos pg. 4 Lines 70-74, miniboot contains macro BOOTLOADER_START_ADDRESS pointing to the bootloader code [i.e., plaintext]; also see Peterson Col 18, Lines 23-24, FSBL 211 may be stored as plaintext and Peterson FIG. 5-3, 5-5, and Col. 12 lines 64-67, boot header 501 contains reserved space for interrupts [i.e., the branch command] and it is stored before any other information).
Regarding Claim 8, Peterson discloses the operating method of an electronic device (Peterson FIG. 2, field programmable system-on-chip “FPSoC" system 200 [Note: FPSoC systems 200 of FIGS. 2 and 3 are used interchangeably, see Col. 8 Lines 31, 32]; and Peterson Col. 1 Lines 60-61, disclosure relates to a method of booting an SoC). Peterson further discloses:
(A) writing a first segment of the boot code (Peterson Col. 8 Lines 35-40, FSBL 211 [i.e., first segment of boot code] is written into memory OCM 227) into a memory block of the memory (Peterson FIG. 5-4, FSBL partition 503 is stored in a first memory block);
(B) executing a part of the first segment of the boot code (Peterson FIG. 4, executing FSBL [i.e., first segment of boot code] at step 402; also see Col. 10 Lines 1-18, booting steps, including running and transferring control to FSBL 211);
(C) executing a second segment of the boot code after step (B) (Peterson FIG. 4, executing SSBL [i.e., second segment of boot] in step 403, after step 402; also see Col. 10 Lines 27-38, booting steps, including operations executed by SSBL);
The remaining limitations in Claim 8 are similar in scope to claim 1, and thus rejected under the same rationale.
Regarding Claim 12, the claim is similar in scope to claim 5 as addressed above and is thus rejected under the same rationale.
Regarding Claim 13, the claim is similar in scope to claim 6 as addressed above and is thus rejected under the same rationale.
Regarding Claim 14, the claim is similar in scope to claim 7 as addressed above and is thus rejected under the same rationale.
Regarding Claim 15, Peterson discloses an electronic device (Peterson FIG. 2, field programmable system-on-chip “FPSoC" system 200 [Note: FPSoC systems 200 of FIGS. 2 and 3 are used interchangeably, see Col. 8 Lines 31, 32]), wherein the electronic device is coupled to an external storage device (Peterson FIG. 2 and Col 6 Lines 1-7, FPSoC 220 is coupled to an external memory 210 "NVM 210"), and the external storage device stores a boot code of the electronic device (Peterson FIG. 2 and Col 6 Lines 10-12, memory (“NVM”) 210 may be used to store boot image), the electronic device comprising:
a memory (Peterson FIG. 2, on-chip random access memory "OCM" 227; or Peterson FIG. 3, RAM 304);
a storage control circuit configured to read a first segment of the boot code from the external storage device (Peterson Col. 10 Lines 5-7, CPU 306 executes ROM boot code 229 to load a first stage boot loader "FSBL" 21 [i.e., first segment of boot code]; also see FIG. 2, I/O MUX 221 [i.e., storage control circuit] responsible for reading the external memory) and write the first segment of the boot code into a memory block of the memory (Peterson Col. 8 Lines 35-40, FSBL 211 is written into memory OCM 227; and Peterson FIG. 5-4, FSBL partition 503 is stored in a first memory block); and
a computing circuit configured to execute a second segment of the boot code (Peterson Col. 10 Lines 15-18, FSBL 211 loads subsequent images from the boot image [which are executable by the CPU [i.e., computing circuit]; and Peterson FIG. 4, executing SSBL [i.e., second segment of boot] in step 403; also see Col. 10 Lines 27-38, booting steps, including operations executed by SSBL) and detect whether a[n input] by a user is received while executing the second segment of the boot code (Peterson Col. 21 Lines, 43-45, secure boot flow 1000 may be controlled by a user);
wherein the [input] controls the computing circuit to execute a target code in the memory block (Peterson Col. 11 Lines 11, boot image contains application partition 427 [i.e., target code]; Peterson Col. 21 Lines, 43-45, secure boot flow 1000 may be controlled by a user);
wherein the first segment of the boot code comprises a [first stage bootloader] code of a Linux system (Peterson Col. 10 Lines 5-9, executes such boot code 229 at 401 to load a FSBL 211 [i.e., first stage bootloader code]; and Peterson Col. 10 Lines 13-16, Linux Operating System "OS" is loaded for the system), and the second segment of the boot code comprises a U-boot code of the Linux system (Peterson Col. 10 Lines 13-16, SSBL is a U-Boot for a Linux Operating System "OS")[also see FIG. 5-3, showing exemplary boot image format with FSBL, U-Boot, and Linux partitions].
wherein the computing circuit executes [the first stage bootloader code] before finishing executing the U-boot code (Peterson FIG. 4, executing FSBL at step 402 before SSBL at step 403).
Peterson does not explicitly teach:
to detect whether a target command input by a user is received while executing the second segment of the boot code;
wherein the target command controls the computing circuit to execute a target code in the memory block;
wherein the first segment of the boot code comprises a Miniboot code of a Linux system, and the second segment of the boot code comprises a U-boot code of the Linux system;
wherein the computing circuit executes the target code before finishing executing the U-boot code.
In the analogous art of secure loading of an operating system, U-Boot Project teaches:
to detect whether a target command input by a user is received while executing the second segment of the boot code (U-Boot Project pg. 90 Lines 3317-3319, U-Boot [i.e., second segment of boot code] can dynamically load and "standalone" applications [also see e.g., at Lines 3326-3353, “standalone” program hello_world.c [i.e., target program] configured to run at an address 0x00040004 in response to a target command [e.g., “=> loads => examples/hello_world.srec” or “=> go 40004”], which interrupts running of U-Boot to run program; and pg. 7 Lines 20-25, U-Boot allows adding commands]);
wherein the target command controls the computing circuit to execute a target code in the memory […] (U-Boot Project pg. 90 Lines 3317-3319, U-Boot [i.e., second segment of boot code] can dynamically load and "standalone" applications [also see e.g., at Lines 3326-3353, “standalone” program hello_world.c [i.e., target program] configured to run at an address 0x00040004 [i.e., in the memory] in response to a target command [e.g., “=> loads => examples/hello_world.srec” or “=> go 40004”], which interrupts running of U-Boot to run program; and pg. 7 Lines 20-25, U-Boot allows adding commands]);
wherein the computing circuit executes the target code before finishing executing the U-boot code (U-Boot Project pg. 90-91 Lines 3331-3399, e.g., U-Boot “standalone” programs running via the U-boot command line, then terminating/quitting within u-boot).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Peterson and U-Boot Project before him, before the effective filing date of the claimed invention, to modify the second stage boot loader of Peterson to use the user-triggered target code execution disclosed by U-Boot Project. A person having ordinary skill in the art would recognize that Peterson was ready for improvement by using the known technique of using U-Boot commands to have a user execute an application located at a specific address as taught by U-Boot Project, which would provide the predictable result of allowing the user to control the boot process as described by Peterson (Peterson Col. 21 Lines, 43-45, secure boot flow 1000 may be controlled by a user).
The remaining limitations in Claim 15 are similar in scope to claim 1, and thus rejected under the same rationale.
Regarding Claim 18, the claim is similar in scope to claim 5 as addressed above and is thus rejected under the same rationale.
Regarding Claim 19, the claim is similar in scope to claim 6 as addressed above and is thus rejected under the same rationale.
Regarding Claim 20, the claim is similar in scope to claim 7 as addressed above and is thus rejected under the same rationale.
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 COLE JIAWEI WENTZEL whose telephone number is (703) 756-4762. The examiner can normally be reached 9:30am-5:30pm ET (Mon-Fri).
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 Jung can be reached on (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.
/C.J.W./Examiner, Art Unit 2175
/ANDREW J JUNG/Supervisory Patent Examiner, Art Unit 2175