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 October 24, 2025, entering the claims and remarks submitted September 19, 2025.
Claims 1-20 are pending.
Response to Arguments
Applicant’s arguments, see Remarks, filed September 19, 2025, 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 In response to applicant's arguments regarding the objections to the Specification, on page 6 of the September 19, 2025 Remarks, the Examiner respectfully disagrees. Specifically, MPEP §608.01(o) states "... sometimes in amending the claims or in adding new claims, new terms are introduced that do not appear in the specification. The use of a confusing variety of terms for the same thing should not be permitted. New claims, including claims first presented after the application filing date where no claims were submitted on filing, and amendments to the claims already in the application should be scrutinized not only for new matter but also for new terminology. " MPEP §608.01(o). As such the specification is objected to because the term "set availability indicator" amended into the claims, does not appear in the specification.
Moreover, Applicant's arguments regarding the rejection under §112, on pages 6-7 of the September 19, 2025 Remarks, is similarly unpersuasive. Applicant may amend to reflect the language within the specification, but has declined to do so here. While §112 does not require verbatim recitation of the amended claim term in the specification, it does require the specification reasonably convey possession of the claimed subject matter as of the filing date. Here, as the amended term "set availability indicator" is not recited, one of ordinary skill would not have been able to determine applicant was in possession of that specific amended claimed invention. Here, the 'set availability indicator for application of the firmware update is not reasonably conveyed to be in possession by the cited ¶25 of the specification which describes a flag set to indicator to the processor to retrieve the update package. Again, applicant has the ability to amend these claims to more closely claim the subject matter of claim 25 should they so choose.
Finally, Applicant's arguments regarding claim rejection under §103, on pages 7-9 of the September 19, 2025 Remarks, are similarly unpersuasive. The cited portion of Bhimanadhuni teaches a flag set to indicate the initiation of a firmware update process, i.e. application of an update. While Bhimanadhuni teaches the triggered process results in skipping memory initialization for unrelated reasons (maintaining execution context) the flag indicates for the application of an update " a firmware update reboot may be indicated, for example, by a flag set in CMOS or a variable set in memory" (¶53), and thus teaches or suggests the amended indicator to one of ordinary skill in the art. This argument, therefore, is unpersuasive and the rejection is maintained.
Specification
The specification is objected to as failing to provide proper antecedent basis for the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the following is required: the amended claim recites “availability indicator.” This term is not recited in the original specification
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims, 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The claim recites the amended limitation “executing, by the processor of the information handling system, the BIOS during a boot cycle, the executing including applying the firmware update based on a set availability indicator;”, while applicant cites paragraph ¶25 of the specification, neither this portion of the specification, nor the rest of the specification reasonably convey to one skilled in the relevant art that the inventors had possession of the claimed invention as of the original filing date.
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 on a set availability indicator; (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 device 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.
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
2/20/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191