DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the Request for Continued Examination filed May 20, 2026
Claims 1-20 are pending.
Response to Arguments
Applicant’s arguments, see Remarks, filed May 20, 2026 with respect to the rejection(s) of claim(s) 1-20 under §103 have been fully considered but they are not persuasive. Specifically, Regarding Applicant’s Remarks concerning the claims the examiner respectfully disagrees. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Bhimanandhuni teaches the use of a flag in indicating the boot process to be used in applying a firmware update. While Bhimanandhuni may not contemplate the exact same system as applicant’s claims, it is not applied as a §102 reference. Instead, the Examiner maintains that the claims as a whole would be obvious in view of the combination of references set forth in the rejection. As such the argument is unpersuasive and the rejection is maintained.
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-3,6,8-10,13,15-17 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Knichel” (US PG Pub 2014/0380340) in view of “Nachimuthu” (US PG Pub 2019/0243637) and further in view of “Bhimanandhuni” (US PG Pub 2018/0032349).
Regarding Claim 1, Knichel teaches:
1.A method, comprising:
determining, by an information handling system, a dependency of a software on a firmware update; (See e.g. 208, Fig. 2, 404, Fig. 4, ¶¶16-17, 25-29, 36-38 Knichel teaches a system with update packages for software, driver and firmware updates wherein the package includes the update image and dependency data, e.g. including dependencies that need to be satisfied before the update is applied)
based on determining the dependency: …the update package comprising a firmware update and dependency metadata; (See e.g. 208, Fig. 2, 404, Fig. 4, ¶¶16-17, 25-29, 36-38 Knichel described above, the dependency data includes for example firmware 210(2), ¶29 indicating firmware packages which must be installed prior to application of update in a first configuration package among the configuration packages 120, fig 1)
and installing, by the information handling system, the software after receiving the completion indicator, wherein the software installation is performed based on the dependency being satisfied. (See e.g. 208, Fig. 2, 404, Fig. 4, ¶¶16-17, 25-29, 36-38 Knichel described above, and see further e.g. 414-416 and 406 fig. 4, ¶38, as well as 308-312 fig. 3, ¶32 describing installing software from a configuration package once it is determined that the dependency is satisfied).
Knichel does not explicitly teach, but Nachimuthu teaches: providing, by a processor of the information handling system, availability of an update package to a BIOS, (See BIOS of Nachimuthu in ¶¶41-43 describing updating an ACPI table entry to indicate activation of a firmware update.)
receiving, by the processor of the information handling system, a completion indicator created during execution of the BIOS indicative of a completion of the firmware update; (See BIOS of Nachimuthu in ¶¶41-43 describing updating an ACPI table entry to indicate activation of a firmware update.)
In addition it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Knichel and Nachimuthu as each is directed to firmware update activation systems and Nachimuthu recognized “ To address the challenge of upgrading firmware in memory devices without jeopardizing a cloud service provider's ability to meet their service level agreements and other end user applications relying on persistent memory, a runtime firmware activation (RFA) interface enables new firmware for a memory device to be activated without requiring an operating system reboot.” (¶18).
Knichel does not teach, but Bhimanadhuni teaches:
executing, by the processor of the information handling system, the BIOS during a boot cycle, the executing including applying the firmware update based flag set indicating that the processor retrieve the update package (Bhimanadhuni e.g. ¶53 describes a flag or variable indicating the firmware is to be updated and indicating that the firmware update reboot process should be carried out). In addition it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Knichel and Bhimanadhuni as each is directed to firmware update activation systems and Bhimanadhuni recognized “Typically, BIOS or UEFI updates require a system reboot that results in downtime for users” (¶2) and provides a system for managing this issue.
Regarding Claim 2, Nachimuthu teaches:
2. The method of claim 1, wherein the completion indicator comprises an entry in a ACPI table.
PNG
media_image1.png
13
11
media_image1.png
Greyscale
(See BIOS of Nachimuthu in ¶¶41-43 describing updating an ACPI table entry to indicate activation of a firmware update.) In addition it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Knichel and Nachimuthu as each is directed to firmware update activation systems and Nachimuthu recognized “ To address the challenge of upgrading firmware in memory devices without jeopardizing a cloud service provider's ability to meet their service level agreements and other end user applications relying on persistent memory, a runtime firmware activation (RFA) interface enables new firmware for a memory device to be activated without requiring an operating system reboot.” (¶18).
Regarding Claim 3, Nachimuthu teaches:
3. The method of claim 1, wherein the completion indicator comprises metadata stored in in an EFI system partition. (See Nachimuthu in Fig. 9, ¶¶27,28,52 describe use of variables in UEFI system memory for tracking and indicating firmware activation) In addition it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Knichel and Nachimuthu as each is directed to firmware update activation systems and Nachimuthu recognized “ To address the challenge of upgrading firmware in memory devices without jeopardizing a cloud service provider's ability to meet their service level agreements and other end user applications relying on persistent memory, a runtime firmware activation (RFA) interface enables new firmware for a memory device to be activated without requiring an operating system reboot.” (¶18).
Regarding Claim 6, Knichel teaches: 6. The method of claim 1, wherein the software installation comprises installing a new software on the information handling system based, at least in part, on the dependency being satisfied. (See e.g. 208, Fig. 2, 404, Fig. 4, ¶¶16-17, 25-29, 36-38 Knichel described above, and see further e.g. 414-416 and 406 fig. 4, ¶38, as well as 308-312 fig. 3, ¶32 describing installing software from a configuration package once it is determined that the dependency is satisfied).
Claims 8-10 and 13 are rejected on the same basis as claims 1-3 and 6 respectively above.
Claims 15-17 and 19 are rejected on the same basis as claims 1-3 and 6 respectively above.
Claim(s) 4,5,11,12, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Knichel” (US PG Pub 2014/0380340) in view of “Nachimuthu” (US PG Pub 2019/0243637) and further in view of “Bhimanandhuni” (US PG Pub 2018/0032349). as applied above and further in view of “Naranjo-Hernandez” (Naranjo-Hernandez, David, et al. "Personalization and adaptation to the medium and context in a fall detection system." IEEE transactions on information technology in biomedicine 16.2 (2012): 264-271.)
Regarding Claim 4, Knichel et al teaches the limitations of claim 1 above, but do not further teach, while Naranjo-Hernandez teaches: 4. The method of claim 1, wherein the software comprises a listening feature for a free fall sensor and the firmware update comprises updating an integrated sensor hub. (See Naranjo-Hernandez “sensor” (SoM) and :”integrated hub” (DAD) which are provided software and firmware updates to personalize the free-fall detection and analysis of the combination of devices as pictured in Fig. 1, and described in sections II through V). In addition it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Knichel and Naranjo-Hernandez as each is directed to firmware update methods and Naranjo-Hernandez recognized the utility to fall detection systems of a “a distributed processing architecture that provides capabilities for remote firmware update of the smart sensors.” (Abstract).
Regarding Claim 5, Knichel et al teaches the limitations of claim 1 above, but do not further teach, while Naranjo-Hernandez teaches 5. The method of claim 4, wherein the integrated sensor hub comprises a free fall sensor algorithm. (See Naranjo-Hernandez Section II describing ADM and OM modules on DAD analyzing fall data from sensors SoM and finding optimum operating parameters. The DAD may receive software/firmware updates of these modules as described in section V). In addition it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Knichel and Naranjo-Hernandez as each is directed to firmware update methods and Naranjo-Hernandez recognized the utility to fall detection systems of a “a distributed processing architecture that provides capabilities for remote firmware update of the smart sensors.” (Abstract).
Claims 11 and 18 are rejected on the same basis as claim 4 above.
Claim 12 is rejected on the same basis as claim 5 above.
Claim(s) 7, 14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Knichel” (US PG Pub 2014/0380340) in view of “Nachimuthu” (US PG Pub 2019/0243637) and further in view of “Bhimanandhuni” (US PG Pub 2018/0032349) as applied above and further in view of “Nay” (US Patent 9,092,296).
Regarding Claim 7, Knichel et al teaches the limitations of claim 1 above, but do not further teach, while Nay teaches:
7. The method of claim 1, wherein the software to be installed on the information handling system comprises code for collecting telemetry data and providing the telemetry data to a backend server.(See Nay telemetry controller 136-144 fig. 1, reporting to 104 Fig. 1, Col. 12, Ln 9-25 describing installing code updates for the telemetry controllers for the collection of telemetry data).
In addition it would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Knichel and Nay as each is directed to firmware updating systems as Nay recognized “obtaining the telemetry information from the equipment being monitored is laborious when there are numerous pieces of equipment involved… To address these and other problems, this disclosure provides for an apparatus for managing telemetry sensor controllers.” (Col. 1, Ln 35-55).
Claims 14 and 20 are rejected on the same basis as claim 4 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The prior art cited in the previous PTO-892 form includes prior art relevant to applicant’s disclosures related to firmware and software upgrade methods.
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 MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4: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, Wei Zhen can be reached on 571-272-3708. 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.
MJB
8/26/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191
Prosecution Insights