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 is in response to communications filed on 1/14/26.
Claims 1-20 are pending.
Claim Interpretation
The broadest reasonable interpretation of a method (or process) claim having contingent
limitations require only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent is not met. If the condition for performing a contingent step is not satisfied, the performance recited by
the step need not be carried out in order for the claimed method to be performed. See Ex Parte Schulhauser. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may
be practiced without either the first or second condition happening, then neither step A or
B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both
steps A and B (MPEP 2111.04).
Claims 1-8 are method claims reciting various limitations throughout the claims – “in response to that the boot status is that boot fails in the first boot mode” (claim 1), “in response to that the boot count value is a preset value”, “in response to that the boot count value reaches a preset threshold” (claim 4), “in response to at least one of the ... preset information” (claim 6). The BRI does not include associated functions based on the conditions when method can be practiced without conditions being met. BRI does not include reading backup boot information in a first partition of a target memory because boot status may indicate a success (claim 6 mentioned the boot success condition; the failure and success are two exclusive conditions) where first boot information may not be read ([0040] applicant’s specification first information is read when boot status is boot failure. For boot success, no reading is necessary). Thus, reading based on the boot status and booting in a second boot mode is not a mandatory step for the claim 1 to occur. The other conditional limitations are not positively recited also. For compact prosecution, Examiner addressed the conditional limitations and the corresponding steps as described below.
The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. The system claim interpretation differs from a method claim interpretation because the claimed structure must be present in the system regardless of whether the condition is met and the function is actually performed. Thus, claims 9-20, the product and system claims, require the conditions and the corresponding functions as part of BRI.
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-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nicholson et al (US Patent 7340638), in view of Lo et al (US Patent Application Publication 2016/0364297).
For claim 1, Nicholson et al teach the following limitations: A memory-partition-based device-startup method (Fig 3 – Fig 7 Fig 10 mention the memory partition based startup method), including: determining a boot status of an electronic device (Fig 1 and Fig 2 show the electronic device) in a first boot mode (normal boot is the first boot mode which uses primary operating system; lines 53-55 of col 1 mention that during normal operation computer system accesses primary operating system; lines 55-58 of col 1 mention that sensing error in primary OS; lines 55-59 of col 4; step 150-158 in Fig 4 shows that whether boot is successful is determined in 156; successful boot is the boot status) at a preset occasion (attempt boot at step 154; externally triggered boot mentioned in lines 22-23 of col 5); in response to that the boot status is that boot fails in the first boot mode, reading (boot status is stored in counter as shown in 158 and 160 of Fig 4 and lines 1-18 of col 5 – set a location in NVM and checked by BIOS; SBF boot flag lines 1-25 of col 10), backup boot information (alternate OS is the first boot information as shown in Fig 3 and Fig 4 and recovery OS shown in Fig 10) in a first partition of a target memory (Fig 3; Fig 4 shows that count reaches n in step 160 and alternate OS is accessed; Fig 10 shows recovery OS, which is an alternate OS to boot when primary OS fails as shown in Fig 11 – step 305 shows unsuccessful boot, step 320 shows boot to recovery OS; thus recovery OS is read when primary OS fails); booting the electronic device in a second boot mode by running the backup boot information (step 162 in Fig 4; recovery mode mentioned in line 29 col 10; line 62, col 9 through line 35 of col 10 mention booting into recovery mode based on the recovery OS; lines 45-52 of col 9), and acquiring system update information for the electronic device from a system update device (lines 30-34 of col 9; an alert is added in an error log, alerting remote user interface; thus the system update information for the electronic device is acquired from a remote interface by the user; system update information is the failure notice to the user); updating, with the system update information (user is provided the options as mentioned in lines 45-50 of col 9; this is based on the previous alert/failure notice sent to user), second boot information (lines 35-52 of col 9; lines 3-8 of col 4; lines 61-65 of col 10 mention that primary OS from main partition is repaired and booted; primary OS is the second boot information ) in a second partition of the target memory (Fig 3; Fig 5; Fig 10); and booting the electronic device in the first boot mode based on the updated second boot information (lines 35-52 of col 9; lines 3-8 of col 4; lines 61-65 of col 10; Fig 11 step 329; lines 34-35 of col 10 – operating system completed boot procedure; repairing the primary OS, repair image on the main partition and system will boot from correct partition).
Nicholson does not explicitly mention the following limitations:
after booting the electronic device in the second boot mode, transmitting a system update request to a system update server
acquiring system update information for the electronic device form the system update server
after receiving the system update request, the system update server transmits the system update information to the electronic device
Lo et al teach the following limitations:
after booting the electronic device in the second boot mode (step 506 in Fig 5, step 606 in Fig 6; boot service OS; thus, service/recovery mode is the second mode), transmitting a system update request ([0020] [0025] – firmware is configured to establish communication with remediation server; service OS can download additional test/program from remediation server 210; thus firmware/OS transmits an update request including requesting additional test programs/diagnostic programs) to a system update server (remote remediation server 210 shown in Fig 2)
acquiring system update information for the electronic device from the system update server ([0020] [0025] – additional test and diagnostic program from 210 to 100; Fig 2 [0017]),
wherein after receiving the system update request, the system update server transmits the system update information to the electronic device ([0017] [0020] [0025] Fig 2 and Fig 6– the service downloads diagnostics programs from server 210; this requires communicating and requesting the programs from the server by the I HS 100)
updating, with the system update information, boot information and booting the electronic device in the first boot mode (step 607 and 608 of Fig 6; [0025] – repair tools have been run and [0027] [0031] – after repair operation primary OS is booted)
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 Nicholson and Lo to transmit system update information after receiving a system update request as taught in Lo. Both Nicholson and Lo teach recovery of the primary OS; however, Nicholson does not explicitly mention any system update server for system update information. Nicholson mention that the alert will be sent to local/remote user interface; email and phone message. Therefore, with the teachings of Lo, the system in Nicholson can include the system update server to provide the system update information to the I HS to repair the primary OS. Since Nicholson teaches the computer is within a network with various servers (Fig 1; lines 39-60 of col 2), the inclusion of remediation server is within the scope of the ordinary skill in the art. Such operation provides quick recovery of the system ([0032] of Lo).
For claim 2, Nicholson teaches wherein the determining a boot status of an electronic device in a first boot mode at a preset occasion includes: acquiring a preset boot loading program (BIOS program in Fig 4), and running the boot loading program (BIOS in Fig 4 is run to load OS); acquiring, based on the boot loading program, boot identification information indicating whether the electronic device is successfully booted (Fig 4 step 156 and 158); and determining the boot status of the electronic device in the first boot mode , as indicated by the boot identification information (failure status is detected from count value as shown in step 160; Fig 11 boot flag BOOTING value shows the success/failure; lines 1-35 of col 10) at the preset occasion (step 154 of Fig 4).
For claim 3, Nicholson teaches wherein the acquiring a preset boot loading program includes: reading the boot loading program from a boot memory; or reading the boot loading program from the first partition (BIOS stored in boot memory; Fig 2).
For claim 4, Nicholson teaches the following limitations: wherein the acquiring boot identification information indicating whether the electronic device is successfully booted includes: acquiring a boot count value from a preset counter (Fig 4 step 160; BIOS boot performs the boot count in a counter), in response to that the boot count is a preset value (step 160 in Fig 4; boot count less that n) generating the boot identification information indicating successful boot (step 156 in Fig 4; this step occurs in response to boot count less than n; Fig 11 boot flag BOOTING value shows the success/failure; lines 1-35 of col 10), in response to that the boot count value reaches a present threshold generating boot identification information indicating a boot failure (step 160, boot count is n; boot failure occurred to boot alternate OS)
,For claim 5, Nicholson et al teach the following limitations: wherein the acquiring, based on the boot loading program, boot identification information indicating whether the electronic device is successfully booted includes: receiving, based on the boot loading program, external monitoring information transmitted by a preset external monitoring device (watchdog timer provides the monitoring Fig 4; watchdog timer is external with respect to processor, memory and BIOS; lines 59-67 of col 4), to generate the external monitoring information indicating whether the electronic device is successfully booted in the first boot mode (watchdog timer expires, then boot is failure and then processor is reset; lines 59-67 of col 4; thus watchdog timer monitors the boot status and provides the reset signal when boot status fails) and generating corresponding boot identification information indicating whether the electronic device is successfully booted (Fig 11 boot flag BOOTING value shows the success/failure; lines 1-35 of col 10).
For claim 6, Nicholson teaches, wherein the determining, the boot status of the electronic device in the first boot mode at the preset occasion as indicated by the boot identification information includes: determining that the electronic device is successfully booted in the first boot mode, in response to that at least one of the following conditions is met: the boot count value reaching a preset value (the successful boot in Fig 4 shows as step 156 step 168, which is in response to boot count < n; boot count less than n as shown in Fig 4, which further sets booting = 0 in Fig 11 when boot is successful; thus booting = 0 represents successful boot; lines 1-18 of col 10; the count value is set to 0 for boot success)
For claim 7, Nicholson teaches the following wherein the reading backup boot information from a first partition of a target memory includes: determining an address of the backup boot information in the first partition of the target memory by running the boot loading program; and reading the backup boot information from the first partition from the address (lines 35-60 of col 10 mentions how recovery OS is accessed; the partition indication is set and then the recovery OS is read).
For claim 8, Nicholson teaches the following - after the determining a boot status of an electronic device in a first boot mode at a preset occasion, the method further includes: reading the boot information from the second partition (Fig 4 step 156 shows the success when primary OS is operational, lines 1-27 of col 5); and booting the electronic device in the first boot mode by running the second boot information in the second partition (the primary OS is loaded when first attempt is successful; lines 1-27 of col 5).
For claim 9, Nicholson teaches medium, processor and memory (lines 1-35 of col 3)
For claim 10, Nicholson teaches wherein the determining a boot status of an electronic device in a first boot mode at a preset occasion includes: acquiring a preset boot loading program (BIOS program in Fig 4), and running the boot loading program (BIOS in Fig 4 is run to load OS); acquiring, based on the boot loading program, boot identification information indicating whether the electronic device is successfully booted (Fig 4 step 156 and 158); and determining, based on the boot identification information, the boot status of the electronic device in the first boot mode (failure status is detected from count value as shown in step 160; Fig 11 boot flag BOOTING value shows the success/failure; lines 1-35 of col 10) at the preset occasion (step 154 of Fig 4).
For claim 11, Nicholson teaches wherein the acquiring a preset boot loading program includes: reading the boot loading program from a boot memory; or reading the boot loading program from the first partition (BIOS stored in boot memory; Fig 2).
For claim 12, Nicholson teaches the following limitations: wherein the acquiring, based on the boot loading program, boot identification information indicating whether the electronic device is successfully booted includes: acquiring a boot count value from a preset counter based on the boot loading program (Fig 4 step 160; BIOS boot performs the boot count in a counter), and generating the boot identification information based on the boot count value, wherein the boot count value is a preset value when the electronic device is successfully booted in the first boot mode (boot count is less than n for successful boot in the first boot mode).
,For claim 13, Nicholson et al teach the following limitations: wherein the acquiring, based on the boot loading program, boot identification information indicating whether the electronic device is successfully booted includes: receiving, based on the boot loading program, external monitoring information transmitted by a preset external monitoring device (watchdog timer provides the monitoring Fig 4; watchdog timer is external with respect to processor, memory and BIOS; lines 59-67 of col 4), and generating the boot identification information based on the external monitoring information (step 160 in Fig 4 is based on watchdog timer expiration), wherein the external monitoring device is configured to monitor the boot status of the electronic device in the first boot mode in a real-time manner (watchdog counter provides real-time monitoring lines 59-67 of col 4), and to generate the external monitoring information indicating whether the electronic device is successfully booted in the first boot mode (watchdog timer expires, then boot is failure and then processor is reset; lines 59-67 of col 4; thus watchdog timer monitors the boot status and provides the reset signal when boot status fails) .
For claim 14, Nicholson teaches the following - after the determining a boot status of an electronic device in a first boot mode at a preset occasion, the method further includes: reading the second boot information from the second partition in response to the determining that the boot status of the electronic device in the first boot mode at the preset occasion is the boot success (Fig 4 step 156 shows the success when primary OS is operational, lines 1-27 of col 5); and booting the electronic device in the first boot mode based on the second boot information (the primary OS is loaded when first attempt is successful; lines 1-27 of col 5).
For claim 15, Nicholson teaches medium, processor and memory (lines 1-35 of col 3)
For claim 16, Nicholson teaches wherein the determining a boot status of an electronic device in a first boot mode at a preset occasion includes: acquiring a preset boot loading program (BIOS program in Fig 4), and running the boot loading program (BIOS in Fig 4 is run to load OS); acquiring, based on the boot loading program, boot identification information indicating whether the electronic device is successfully booted (Fig 4 step 156 and 158); and determining, based on the boot identification information, the boot status of the electronic device in the first boot mode (failure status is detected from count value as shown in step 160; Fig 11 boot flag BOOTING value shows the success/failure; lines 1-35 of col 10) at the preset occasion (step 154 of Fig 4).
For claim 17, Nicholson teaches wherein the acquiring a preset boot loading program includes: reading the boot loading program from a boot memory; or reading the boot loading program from the first partition (BIOS stored in boot memory; Fig 2).
For claim 18, Nicholson teaches the following limitations: wherein the acquiring, based on the boot loading program, boot identification information indicating whether the electronic device is successfully booted includes: acquiring a boot count value from a preset counter based on the boot loading program (Fig 4 step 160; BIOS boot performs the boot count in a counter), and generating the boot identification information based on the boot count value, wherein the boot count value is a preset value when the electronic device is successfully booted in the first boot mode (boot count is less than n for successful boot in the first boot mode).
,For claim 19, Nicholson et al teach the following limitations: wherein the acquiring, based on the boot loading program, boot identification information indicating whether the electronic device is successfully booted includes: receiving, based on the boot loading program, external monitoring information transmitted by a preset external monitoring device (watchdog timer provides the monitoring Fig 4; watchdog timer is external with respect to processor, memory and BIOS; lines 59-67 of col 4), and generating the boot identification information based on the external monitoring information (step 160 in Fig 4 is based on watchdog timer expiration), wherein the external monitoring device is configured to monitor the boot status of the electronic device in the first boot mode in a real-time manner (watchdog counter provides real-time monitoring lines 59-67 of col 4), and to generate the external monitoring information indicating whether the electronic device is successfully booted in the first boot mode (watchdog timer expires, then boot is failure and then processor is reset; lines 59-67 of col 4; thus watchdog timer monitors the boot status and provides the reset signal when boot status fails) .
For claim 20, Nicholson teaches the following - after the determining a boot status of an electronic device in a first boot mode at a preset occasion, the method further includes: reading the second boot information from the second partition in response to the determining that the boot status of the electronic device in the first boot mode at the preset occasion is the boot success (Fig 4 step 156 shows the success when primary OS is operational, lines 1-27 of col 5); and booting the electronic device in the first boot mode based on the second boot information (the primary OS is loaded when first attempt is successful; lines 1-27 of col 5).
Response to Arguments
Applicant’s arguments have been considered by the Examiner, but they are not persuasive and/or moot in view of new ground of rejection.
Regarding claim interpretation, applicant argues that claims 1-8 have been amended to remove the contingent limitations.
Examiner disagrees. Claims 1-8, particularly claim 1, claim 4 and claim 6 recite the contingent limitations, which affects the BRI of the claims. The contingent limitations “in response to that the boot status is that boot fails in the first boot mode” (claim 1), “in response to that the boot count value is a preset value”, “in response to that the boot count value reaches a preset threshold” (claim 4), “in response to at least one of the ... preset information” (claim 6) are not recited positively in the claims. BRI does not include reading backup boot information in a first partition of a target memory because boot status may indicate a success (claim 6 mentioned the boot success condition; the failure and success are two exclusive conditions) where first boot information may not be read ([0040] applicant’s specification first information is read when boot status is boot failure. For boot success, no reading is necessary). Thus, reading based on the boot status and booting in a second boot mode is not a mandatory step for the claim 1 to occur.
Regarding the 35 USC 103 rejection, applicant argues that Nicholson fails to disclose that the electronic device actively obtains the system update information from the server, automatically updates the boot information based on the system update information to achieve automatic repair of a boot fault. According to applicant, one ordinary skill would not be motivated to improve Nicholson because the partition in Nicholson is hidden and thus, it is unnecessary to obtain information from server to repair the local boot information.
Examiner disagrees. Although Nicholson does not explicitly mention about any system update server for system update information, the newly cited secondary reference Lo sufficiently teaches the electronic device actively obtains the system update information from the server, automatically updates the boot information based on the system update information to achieve automatic repair of a boot fault as explained above. The Nicholson’s use of hidden partition is for alternative embodiment (lines 45-60 of col 10) only. The other embodiments are not limited to any hidden partitions. Further, Nicholson does not mention that the hidden partition is against any communication with the server. Instead, Nicholson communicates with various servers (Fig 1). Thus, the arguments are not relevant. Nicholson provides the recovery operation of the primary OS by diagnostic program, repairing (lines 45-60 of column 9), which can further be assisted with obtaining the system update information from the server as taught in Lo ([0020][0025]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 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
Prosecution Insights