Prosecution Insights
Last updated: April 19, 2026
Application No. 18/713,514

TERMINAL FIRMWARE STARTUP METHOD AND APPARATUS, ELECTRONIC DEVICE, AND STORAGE MEDIUM

Non-Final OA §103
Filed
May 24, 2024
Examiner
RAHMAN, FAHMIDA
Art Unit
2175
Tech Center
2100 — Computer Architecture & Software
Assignee
BEIJING BYTEDANCE NETWORK TECHNOLOGY CO., LTD.
OA Round
1 (Non-Final)
82%
Grant Probability
Favorable
1-2
OA Rounds
3y 4m
To Grant
99%
With Interview

Examiner Intelligence

Grants 82% — above average
82%
Career Allow Rate
460 granted / 560 resolved
+27.1% vs TC avg
Strong +52% interview lift
Without
With
+51.9%
Interview Lift
resolved cases with interview
Typical timeline
3y 4m
Avg Prosecution
24 currently pending
Career history
584
Total Applications
across all art units

Statute-Specific Performance

§101
7.1%
-32.9% vs TC avg
§103
50.8%
+10.8% vs TC avg
§102
22.5%
-17.5% vs TC avg
§112
8.8%
-31.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 560 resolved cases

Office Action

§103
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 . Claims 1-7, 9-21 are pending. This is in response to communications filed on 5/24/24. 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. Claim(s) 1-2, 4, 6-7, 9-11, 13, 15-17, 19, 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US Patent Application Publication 20210286692), and further in view of Siluvainathan et al (US Patent Application Publication 2017/0039053). For claim 1, Chien teaches the following limitations: A terminal firmware startup method (Fig 1 -Fig 9), comprising: setting a target loader to obtain target firmware (260 in Fig 2 is the target OS boot loader; the target firmware is obtained that includes multiple POST routines [0005]; the firmware 120 in Fig 1 is the target firmware that includes OS boot loader 260 of Fig 2); loading hardware code in the target firmware that is used for initializing core hardware to complete hardware initialization (Fig 2 shows the execution of the firmware, which is a sequential process [0035]; security (SEC), PEI and DXE comprises the core hardware initialization, [0003][0005[ [0007][0025]– BIOS to initialize the hardware of the server, pre-EFI initialization phase to initialize hardware components; Fig 6 shows hardware initialization in step 616, step 622, step 624, step 626, step 628); and generating a hardware initialization complete instruction (step 734 of Fig 7; step 628 of Fig 6; [0055] – initializing all hardware; [0035] – boot path procedures must be sequentially processed; therefore, the hardware initialization must be completed before the next sequence, which includes instruction for the next step); loading the target loader according to the hardware initialization complete instruction to complete platform initialization (260 in Fig 2 is the target loader; [0055] mentions the platform initialization phase including step 630 and step 632 of Fig 6; [0028][0050]), and generating an operating system startup signal ([0029] – OS handoff 262 in Fig 2; [0055] mentions seeking partition from hard disk; which requires startup signal) and starting an operating system based on the operating system startup signal ([0029] – OS boots up and starts). Chien does not mention replacing a target program in initial firmware with a target loader to obtain target firmware. Therefore, Chien does not explicitly mention the following limitations: replacing a target feature program in initial firmware with setting a target loader to obtain target firmware Siluvainathan et al teach the following limitations: replacing a target feature program in initial firmware with a target loader to obtain target firmware (Fig 1 shows the initial firmware 155 and 160, where 160 is replaced with a target boot loader [0023] – replacing boot loader 160 with boot loader image 320; Fig 4 – Fig 6) It would have been obvious for one ordinary skill in the art before the effective filing date to combine the teachings of Chien and Siluvainathan et al to replace a target program in initial firmware with a target loader so that device can work properly with the updated loader. Siluvainathan et al mention that replacing boot loader is necessary to keep the device operating ([0004]). Chien’s BIOS 120 in Fig 1 can be updated with the teachings of Siluvainathan et al so as to replace the target program with the target loader. The replaced/updated loader can provide the desired functionality in the system. For claim 2, Chien teaches wherein the loading the target loader according to the hardware initialization complete instruction to complete platform initialization, and generating an operating system startup signal comprises: obtaining a target boot loader from the target firmware (step 216 in Fig 2; scan boot loader and boot dispatcher [0029][0055] – including the target boot loader) according to the hardware initialization complete instruction ([0055] – creates a bootable device path; therefore, the hardware initialization complete instruction provides the bootable path for the loader); obtaining the target loader based on the target boot loader (260 in Fig 2 is based on 250); and loading the target loader to complete the platform initialization, and generating the operating system startup signal (260 is loaded to complete the platform initialization and OS handoff in Fig 2; [0029][0055]). For claim 4, Chien teaches the following limitations: further comprising: obtaining a failure signal of the operating system (Fig 3 300 mentions error log; [0045][0046] mentions how safety boot can successfully initializes the OS; thus the failure signals of the OS is stored in the error log); obtaining, based on the failure signal, a running log corresponding to the target loader ([0034] mentions that the error log corresponds to entries determined by BIOS; [0060]); and obtaining, based on the running log, a failure location and a failure attribute that correspond to the failure signal ([0048][0060] mention failure/error detection/analysis of the component). For claim 6, Siluvainathan et al teach wherein before the replacing a target feature program in initial firmware with a target loader to obtain target firmware, the method further comprises: obtaining a function mode corresponding to the initial firmware; and obtaining the target loader based on the function mode (Fig 4 shows that the boot loader version is updated to version 1.4; thus, with initial firmware, the function mode ( i.e., version 1.4) correspond to initial firmware is obtained and then obtain the firmware version (i.e., target loader)). For claim 7, Siluvainathan et al teach wherein the replacing a target feature program in initial firmware with a target loader to obtain target firmware comprises: selecting a storage space of a preset size from a specified region of the initial firmware ([0023] mentions that 160 of Fig 1 is replaced; [0034] mentions copy the image and [0035] mentions storing in different address; therefore, the preset size is selected to store the loader in the firmware); and replacing a target feature program in the storage space ([0023] copy to replace 160) with Linux binary, and using the Linux binary as the target loader (Chien teaches Linux loader as mentioned in [0029]; thus the combined teachings provide the Linux binary as the target loader). For claim 9, Chien teaches the following limitations A non-transitory computer-readable medium having a computer program stored thereon ([0053]), wherein when the program is executed by a processing apparatus (Fig 1; [0053]), a terminal firmware startup method is implemented, and the terminal firmware startup method (Fig 1 -Fig 9), comprising: setting a target loader to obtain target firmware (260 in Fig 2 is the target OS boot loader; the target firmware is obtained that includes multiple POST routines [0005]; the firmware 120 in Fig 1 is the target firmware that includes OS boot loader 260 of Fig 2); loading hardware code in the target firmware that is used for initializing core hardware to complete hardware initialization (Fig 2 shows the execution of the firmware, which is a sequential process [0035]; security (SEC), PEI and DXE comprises the core hardware initialization, [0003][0005[ [0007][0025]– BIOS to initialize the hardware of the server, pre-EFI initialization phase to initialize hardware components; Fig 6 shows hardware initialization in step 616, step 622, step 624, step 626, step 628); and generating a hardware initialization complete instruction (step 734 of Fig 7; step 628 of Fig 6; [0055] – initializing all hardware; [0035] – boot path procedures must be sequentially processed; therefore, the hardware initialization must be completed before the next sequence, which includes instruction for the next step); loading the target loader according to the hardware initialization complete instruction to complete platform initialization (260 in Fig 2 is the target loader; [0055] mentions the platform initialization phase including step 630 and step 632 of Fig 6; [0028][0050]), and generating an operating system startup signal ([0029] – OS handoff 262 in Fig 2; [0055] mentions seeking partition from hard disk; which requires startup signal) and starting an operating system based on the operating system startup signal ([0029] – OS boots up and starts). Chien does not mention replacing a target program in initial firmware with a target loader to obtain target firmware. Therefore, Chien does not explicitly mention the following limitations: replacing a target feature program in initial firmware with setting a target loader to obtain target firmware Siluvainathan et al teach the following limitations: replacing a target feature program in initial firmware with a target loader to obtain target firmware (Fig 1 shows the initial firmware 155 and 160, where 160 is replaced with a target boot loader [0023] – replacing boot loader 160 with boot loader image 320; Fig 4 – Fig 6) It would have been obvious for one ordinary skill in the art before the effective filing date to combine the teachings of Chien and Siluvainathan et al to replace a target program in initial firmware with a target loader so that device can work properly with the updated loader. Siluvainathan et al mention that replacing boot loader is necessary to keep the device operating ([0004]). Chien’s BIOS 120 in Fig 1 can be updated with the teachings of Siluvainathan et al so as to replace the target program with the target loader. The replaced/updated loader can provide the desired functionality in the system. For claim 10, Chien teaches the following limitations: An electronic device (Fig 1), comprising: a storage apparatus having one or more computer programs stored thereon ([0053]); and one or more processing apparatuses configured to execute the one or more computer programs in the storage apparatus (Fig 1; [0053]) to implement a terminal firmware startup method (Fig 1 -Fig 9), comprising: setting a target loader to obtain target firmware (260 in Fig 2 is the target OS boot loader; the target firmware is obtained that includes multiple POST routines [0005]; the firmware 120 in Fig 1 is the target firmware that includes OS boot loader 260 of Fig 2); loading hardware code in the target firmware that is used for initializing core hardware to complete hardware initialization (Fig 2 shows the execution of the firmware, which is a sequential process [0035]; security (SEC), PEI and DXE comprises the core hardware initialization, [0003][0005[ [0007][0025]– BIOS to initialize the hardware of the server, pre-EFI initialization phase to initialize hardware components; Fig 6 shows hardware initialization in step 616, step 622, step 624, step 626, step 628); and generating a hardware initialization complete instruction (step 734 of Fig 7; step 628 of Fig 6; [0055] – initializing all hardware; [0035] – boot path procedures must be sequentially processed; therefore, the hardware initialization must be completed before the next sequence, which includes instruction for the next step); loading the target loader according to the hardware initialization complete instruction to complete platform initialization (260 in Fig 2 is the target loader; [0055] mentions the platform initialization phase including step 630 and step 632 of Fig 6; [0028][0050]), and generating an operating system startup signal ([0029] – OS handoff 262 in Fig 2; [0055] mentions seeking partition from hard disk; which requires startup signal) and starting an operating system based on the operating system startup signal ([0029] – OS boots up and starts). Chien does not mention replacing a target program in initial firmware with a target loader to obtain target firmware. Therefore, Chien does not explicitly mention the following limitations: replacing a target feature program in initial firmware with setting a target loader to obtain target firmware Siluvainathan et al teach the following limitations: replacing a target feature program in initial firmware with a target loader to obtain target firmware (Fig 1 shows the initial firmware 155 and 160, where 160 is replaced with a target boot loader [0023] – replacing boot loader 160 with boot loader image 320; Fig 4 – Fig 6) It would have been obvious for one ordinary skill in the art before the effective filing date to combine the teachings of Chien and Siluvainathan et al to replace a target program in initial firmware with a target loader so that device can work properly with the updated loader. Siluvainathan et al mention that replacing boot loader is necessary to keep the device operating ([0004]). Chien’s BIOS 120 in Fig 1 can be updated with the teachings of Siluvainathan et al so as to replace the target program with the target loader. The replaced/updated loader can provide the desired functionality in the system. For claim 11 and claim 17, Chien teaches wherein the loading the target loader according to the hardware initialization complete instruction to complete platform initialization, and generating an operating system startup signal comprises: obtaining a target boot loader from the target firmware (step 216 in Fig 2; scan boot loader and boot dispatcher [0029][0055] – including the target boot loader) according to the hardware initialization complete instruction ([0055] – creates a bootable device path; therefore, the hardware initialization complete instruction provides the bootable path for the loader); obtaining the target loader based on the target boot loader (260 in Fig 2 is based on 250); and loading the target loader to complete the platform initialization, and generating the operating system startup signal (260 is loaded to complete the platform initialization and OS handoff in Fig 2; [0029][0055]). For claim 13 and claim 19, Chien teaches the following limitations: further comprising: obtaining a failure signal of the operating system (Fig 3 300 mentions error log; [0045][0046] mentions how safety boot can successfully initializes the OS; thus the failure signals of the OS is stored in the error log); obtaining, based on the failure signal, a running log corresponding to the target loader ([0034] mentions that the error log corresponds to entries determined by BIOS; [0060]); and obtaining, based on the running log, a failure location and a failure attribute that correspond to the failure signal ([0048][0060] mention failure/error detection/analysis of the component). For claims 15 and 21, Siluvainathan et al teach wherein before the replacing a target feature program in initial firmware with a target loader to obtain target firmware, the method further comprises: obtaining a function mode corresponding to the initial firmware; and obtaining the target loader based on the function mode (Fig 4 shows that the boot loader version is updated to version 1.4; thus, with initial firmware, the function mode ( i.e., version 1.4) correspond to initial firmware is obtained and then obtain the firmware version (i.e., target loader)). For claim 16, Siluvainathan et al teach wherein the replacing a target feature program in initial firmware with a target loader to obtain target firmware comprises: selecting a storage space of a preset size from a specified region of the initial firmware ([0023] mentions that 160 of Fig 1 is replaced; [0034] mentions copy the image and [0035] mentions storing in different address; therefore, the preset size is selected to store the loader in the firmware); and replacing a target feature program in the storage space ([0023] copy to replace 160) with Linux binary, and using the Linux binary as the target loader (Chien teaches Linux loader as mentioned in [0029]; thus the combined teachings provide the Linux binary as the target loader). Claim(s) 3, 12 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US Patent Application Publication 20210286692), and further in view of Siluvainathan et al (US Patent Application Publication 2017/0039053), further in view of Dailey (US Patent 10282190). For claims 3, 12 and 18, Chien in view of Siluvainathan et al do not explicitly mention about codebase. Dailey et al mention wherein before the replacing a target feature program in initial firmware with a target loader to obtain target firmware (Fig 3 shows obtaining the UEFI image 234 from initial image 230; this operation can be performed before loader replacement), the method further comprises: obtaining an initial codebase (230 has C1-C2, D1-D4 in Fig 3A, which are the codebase); obtaining, based on the initial codebase, a target codebase corresponding to a platform (Fig 3B shows the updating target update with respect to the current image for the platform); and generating the initial firmware based on information about a customization requirement of the platform and the target codebase (234 in Fig 3D is generated, which can be taken as the initial firmware; the customization requirement is considered by considering the size/address; lines 45-65 of col 8). It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to combine the teachings of Chien, Siluvainathan et al and Dailey so that the initial firmware can be generated based on initial codebase, target codebase and customization requirement of the platform. As Chien provides multiple POST routines for the platform, the generation of the customized BIOS will provide the faster and optimized operation for the system. When the initial firmware is updated with new features, it can be smaller with preferred functionality. Claim(s) 5, 14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chien (US Patent Application Publication 20210286692), and further in view of Siluvainathan et al (US Patent Application Publication 2017/0039053), further in view of Das et al (US Patent Application Publication 20160004542). For claims 5, 14 and 20, Chien teaches searching for at least one payload in the target loader It would have been obvious for one ordinary skill in the art before the effective filing date of the invention to use parallel execution for the loader payloads in the system since parallel execution is faster for the system. Chien allows multiple processors ([0024]) and therefore, the parallel execution can be realized with the system. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to FAHMIDA RAHMAN whose telephone number is (571)272-8159. The examiner can normally be reached Monday - Friday 10 AM - 7 PM. 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 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. /FAHMIDA RAHMAN/Primary Examiner, Art Unit 2175
Read full office action

Prosecution Timeline

May 24, 2024
Application Filed
Jan 09, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602073
REGISTER CLOCK DRIVER, OPERATING METHOD OF REGISTER CLOCK DRIVER, AND MEMORY MODULE INCLUDING REGISTER CLOCK DRIVER AND PLURALITY OF MEMORY DEVICES
2y 5m to grant Granted Apr 14, 2026
Patent 12602232
METHODS AND SYSTEMS FOR CONTEXTUAL APPLICATION ACTION(S) BASED ON PREVIOUS CONTEXT OF ANOTHER APPLICATION
2y 5m to grant Granted Apr 14, 2026
Patent 12602097
HYBRID APPARATUSES FOR MINING CRYPTOCURRENCY AND METHODS OF OPERATING THE SAME
2y 5m to grant Granted Apr 14, 2026
Patent 12591266
FEEDBACK-BASED CLOCK FREQUENCY ADJUSTMENT FOR DYNAMIC CLOCK VOLTAGE SCALING
2y 5m to grant Granted Mar 31, 2026
Patent 12578973
SYSTEMS AND METHODS FOR REDUCING BOOT TIME IN A COMPUTER SYSTEM
2y 5m to grant Granted Mar 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
82%
Grant Probability
99%
With Interview (+51.9%)
3y 4m
Median Time to Grant
Low
PTA Risk
Based on 560 resolved cases by this examiner. Grant probability derived from career allow 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