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 .
The following is a Final Office action in response to applicant's amendment and response received 01/14/2026, responding to the 09/11/2025 non-final office action provided in rejection of claims 1-20.
Claims 1, 5-6, 8 and 15 have been amended. Claims 1-20 are pending and are addressed in this office action.
Examiner notes
(A). Examiner interpreted “FW payload” as “FW binary file” per paragraph 0028.
(B). Limitations have been provided with the Bold fonts in order to distinguish from the cited part of the reference (Italic).
(C). Examiner has cited particular columns, line numbers, references, or figures in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses to fully consider the reference in entirety, as potentially teaching all or part of the claimed invention. See MPEP §§ 2141.02 and 2123.
The examiner requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111 (c).
Response to Amendments and Arguments
In light amendment of the claims the Previous Action's objections of those claims under are hereby withdrawn.
With respect to the rejections under 35 USC 101, Applicant argues that Under Step 2A Prong One of the 2019 PEG, this is not an abstract idea such as fundamental economic practices, methods of organizing human activity, mathematical relationships/formulas, or mental processes. MPEP § 2106.04(a)–(d). The claimed dependency validation cannot at all be performed as a mental process because it requires interacting with firmware payloads and firmware versions of installed components in server hardware, collecting runtime telemetry (“server information”), and controlling a non-generic “execution engine” … The Examiner has not identified any portion of the claim that can reasonably be performed entirely in the human mind or on paper. The purported justifications given on Step 2A Prong One are at best unsupported and conclusory. (Remarks, page 2)
Examiner respectfully disagrees. Indeed examiner properly identified all portions of claim and provided analysis based on the 2019 PEG. Examiner outlined which portions of limitation under the Under Step 2A Prong One and Under Step 2A Prong Two. Applicant points out validation cannot at all be performed as a mental process because it requires interacting with firmware payloads and firmware versions of installed components in server hardware, collecting runtime telemetry (“server information”). The hardware portions are not included under Step 2A Prong One but Step 2A Prong Two. The additional elements merely recite insignificant extra solution activity such as communicating, installing, updating and executing by the processor which does not integrate the judicial exception into a practical application under Prong 2. See MPEP 2106.05(g). Under Step 2B, the courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception. See MPEP 2106.05(d). Applicant’s arguments have been considered but not persuasive.
With respect to the rejections under 35 USC 101, Applicant argues that Under Step 2A Prong Two, even if an abstract concept were somehow identified, which they have not been, the claims are “integrated into a practical application.” MPEP § 2106.04(d). The specification explains that, unlike traditional monolithic, offline firmware update mechanisms where dependencies are handled by human-read release notes, the claimed system … The claimed operations are not mere data “observation” or “display,” but are used to control whether and when the execution engine updates firmware on a live server based on dependency validation results. The purported justifications given on Step 2A Prong One are at best unsupported and conclusory. … Examiner’s Office Action does not address these integration-into-a-practical-application aspects or explain how the claims are akin to any ineligible example. (Remarks, page 2-3)
Examiner respectfully disagrees. The additional elements are merely applying the judicial exception or abstract idea. Therefore, this additional elements do not integrate the judicial exception into a practical application under Prong 2, or amount to significantly more than the judicial exception under Step 2B. See MPEP 2106.05(f). Examiner request applicant to review Sample Rejection of Example 37 - Claim 3 - under the 2019 Revised Patent Subject Matter Eligibility Guidance (“2019 PEG”) and find out why the judicial exception is not integrated into a practical application. Applicant arguments have been considered but not persuasive.
With respect to the rejections claim 1, under 35 USC 103, Applicant argues that Limoncello, Shepard and/or Moran do not show claimed features of claim 1: Even assuming arguendo that the references could be combined as suggested by the Examiner, the resulting system still would not meet the express limitations of claim 1. Claim 1 requires accessing firmware update metadata that indicates dependencies of a firmware update. Limonciello does not disclose dependency metadata at all, and Shepard’s metadata describes relationships between updates, not compatibility dependencies between firmware components installed on the same server. Moran likewise does not encode firmware dependency semantics; its manifests describe procedural flow and execution ordering, not compatibility constraints. Claim 1 further requires performing a validation of the dependencies against corresponding server information. None of the cited references discloses collecting server firmware information (e.g., versions, configuration settings, or runtime state) and comparing that information against dependency rules. Limonciello’s verification compares a payload hash against an expected value and does not reference server information. Shepard’s applicability rules are evaluated without reference to collected server firmware inventory. Moran does not perform validation against server information at all, and does not disclose any mechanism by which execution is permitted or denied based on such validation. (Remarks, page 6)
Examiner respectfully disagrees. This argument is ineffective because the combination of Limonciello, Shepard and Moran is cited to teach the above limitations, as discussed in this and the prior Rejection under 35 USC 103(a). 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).
Applicant further argues that Limonciello’s verification compares a payload hash against an expected value and does not reference server information. Applicant overlooked the teaching of Limonciello where describe (par. 0006) “an instruction to verify a firmware payload for the first component [i.e. FW component] stored in a second memory of a second component … .” The component resides in the server and component is part of server. Applicant further added the Shepard’s metadata describes relationships between updates, not compatibility dependencies between firmware components installed on the same server. Applicant again overlooked Shepard’s teaching of update on distribution system 100 and service node 200/300 (see figs. 1-3). Further, par. 0013, “… update metadata from an update service node to a child update service node or a client computer is presented. The tag-based structure includes: an identifier tag including a software update identifier that uniquely identifies the software update; zero or more relationship tags that identify dependency relationships the current software update, … .“ while an update service node 200 may be viewed as a server computer on a network, in an actual implementation, an update service node may be implemented on any number of types of computing devices. For example, each update service node 200 may be implemented and/or installed on a single stand-alone computer system or, alternatively, on a distributed computing system comprising multiple computing devices, see par. 0044, 0049. Thus, compatibility and dependency is not excluded server / system. Applicant’s again states that Moran does not perform validation against server information at all, and does not disclose any mechanism by which execution is permitted or denied based on such validation. As cited in this and previous office action that Moran discloses System Validation Behavior. A system [i.e. server] validation behavior process may be used, at least in part, to ensure that all required or appropriate dependencies are present, for example, and that all required or appropriate images are present, see par. 0045, and par. 0128 discloses (pars. 0128, a behavioral description is more precise, and a machine definition upon which it relies is simpler, it may, for example, be augmented with proof that effects of an update fall within a specified policy, such as similarly to a Proof Carrying Code. By combining this capability with formal verification of a document processor, it may, for example, be possible to prove a result of a firmware update, such as prior to application, either on a device or on an intermediate system [i.e. server] … ). Applicant’s argument have been considered but not persuasive.
With respect to the rejections claim 1, under 35 USC 103, Applicant further argues that Finally, claim 1 requires that, only upon successful validation, a communication is made to an execution engine to cause execution of the firmware update on the server. The cited art does not disclose this conditional gating. In Limonciello, verification and execution are co-located within the same component. Shepard does not control execution engines and does not gate execution based on dependency validation. Moran’s manifests describe execution behavior
but do not disclose a separate manager authorizing execution based on validated firmware dependencies. The claimed separation between dependency validation and execution control is absent. (Remarks, page 6-7)
Examiner respectfully disagrees. Moran is relied on to teach successful validation, at least par. 0081 discloses “function invoke(Document) Load $Document[Common Data] into parameters foreach (sequence in [Common, System Validation, Image Loading, Image Invocation]} rc = do_commands($sequence, $Document[$sequence]); if (rc is not SUCCESS) Abort endif end for end function … .” The condition of successful validation rc is success. As cited in this and previous office action that Moran further, discloses at par. 0128, … By combining this capability with formal verification of a document processor, it may, for example, be possible to prove a result of a firmware update, such as prior to application, either on a device or on an intermediate system … . Note: example methods, apparatuses, and/or articles of manufacture are disclosed that may be implemented, in whole or in part, using one or more computing devices to facilitate and/or support one or more operations and/or techniques for securing and/or managing IoT-type devices, see abstract. Further, at par. 0017, … IoT-type devices may comprise, for example, resource constrained embedded devices that utilize hardware and/or software solutions lacking computing or processing power to run a sufficient security software, implement secure firmware update, … . Thus, capability with formal verification perform by the execution engine / system. Applicant’s argument have been considered but not persuasive.
With respect to the rejections claim 1, under 35 USC 103, Applicant further contends that Accordingly, even if combined, Limonciello, Shepard, and Moran do not disclose or suggest an architecture in which firmware dependency metadata is evaluated against corresponding server information by a manager and execution is conditionally authorized only upon successful validation. At least because the cited references neither recognize nor address this technical problem, independent claim 1 is not rendered obvious. (Remarks, page 7)
Examiner respectfully disagrees. Examiner responded this argument in the above where combination of Limonciello, Shepard, and Moran disclose the above limitations, see item number 8. Applicant arguments have been considered but not persuasive.
With respect to the rejections claim 1, under 35 USC 103, Applicant further contends that no Motivation to Combine References to Begin With: There is no motivation to combine Limonciello and Shepard. Applicant further added that A person of ordinary skill, starting from Limonciello, would be focused on a specific hardware-centric problem: staging a firmware payload in a separate component and then securely overwriting accessory firmware once that staged payload has been verified for integrity. Limonciello’s design is expressly local and self-contained. The accessory locks the staging memory, verifies the staged payload using a cryptographic hash, and, if the hash matches, overwrites its own firmware without retaining a backup image, all to reduce memory footprint while preserving security. Such a flow does not look outside the accessory for applicability criteria, scheduling input, or enterprise-level policy; once integrity is confirmed, the decision to install is complete under Limonciello. (Remarks, page 7)
Examiner respectfully disagrees. Limonciello, Shepard, and Moran are analogous art. Where Limonciello teaches a firmware update procedure for an accessory component may use a process that stages the firmware update in a separate component from the target accessory component being updated to reduce the memory requirements in the accessory component, see abstract. Shepard teaches a tag-based structure for communicating software update metadata information to client computers and to update service nodes is presented. An update metadata file includes: an identifier tag including a software update identifier that uniquely identifies the software update; zero or more general properties tags that carry general property information relating the software update, see abstract. Moran discloses this condition may, for example, be used, at least in part, in a document to ensure that a required firmware image is present in a specified component or location. This condition may include the use of one or more cryptographic checksums, such as to validate contents of an image contained in a component, for example, see par. 0058. The question of whether a reference is analogous art is not relevant to whether that reference anticipates. A reference may be directed to an entirely different problem than the one addressed by the inventor, or may be from an entirely different field of endeavor than that of the claimed invention, yet the reference is still anticipatory if it explicitly or inherently discloses every limitation recited in the claims.). Thus, the argument is unpersuasive and the rejection maintained.
With respect to the rejections claim 1, under 35 USC 103, Applicant further contends that Shepard, by contrast, is directed to an update service that manages which software updates should be distributed to which client systems across an enterprise, using XML metadata describing update identity, relationships, and applicability rules. Shepard’s metadata operate at a distribution and applicability layer, not at the hardware installation layer, and are evaluated by an update service rather than by a device performing its own secure overwrite. Incorporating
Shepard’s enterprise metadata into Limonciello would require re-purposing Shepard’s tags so that they somehow control the accessory’s local overwrite decision, even though Limonciello already bases that decision solely on payload integrity. That change would not be a natural extension of either reference: it would complicate Limonciello’s secure, minimal update flow without addressing its memory and staging concerns, and it would push Shepard’s metadata into a role controlling low-level firmware overwrite that it never contemplates. (Remarks, page 7-8)
Examiner respectfully disagrees. It would have been obvious to one of ordinary in the art before the effective filing date of the claimed invention to modify Limonciello with Shepard. Limonciello teaches a method … receiving, by a first component having a first memory storing an original firmware, an instruction to verify a firmware payload for the first component [i.e. FW component] stored in a second memory of a second component and Shepard teaches a technique first access, only elements of the update metadata to are necessary to determine whether a software update is applicable and/or desirable is first downloaded, such as applicability rules and dependencies upon other software updates. Then, after it is determined that an update is applicable and/or desirable, the remainder of the update metadata may be obtained. In response, at event 446 the parent update service node 402 returns the update metadata for the software update child update service node 404, which in turn stores the update metadata into the update information store 216. One of ordinary skill in the art would have recognized that applying the known technique of Shepard to seek improvement of Limonciello would have yielded well-known predictable results and result in an improved of updating of firmware dependency component, as Limonciello discloses that the firmware update procedure for accessory components may be improved by using a process that stages the firmware update in a separate component from the target accessory component being updated. This reduces the memory requirements in the accessory component. Staging the update in a separate component can pose security risks, such as by allowing the staged firmware update from being maliciously modified prior to updating the accessory from the staged memory. Techniques. See M.P.E.P. 2143(I)(D).
With respect to the rejections claim 1, under 35 USC 103, Applicant further argues that Moran introduces a third, conceptually distinct technology: a behavioral manifest language that scripts sequences of operations for IoT-type devices, including ordering, conditional execution, and parallelism once a set of actions has already been selected. Moran explicitly assumes that the behavior being described is appropriate for the device; it focuses on how to carry out that behavior at runtime, not on how to choose, authorize, or validate firmware updates, and not on how to stage or verify payloads. That assumption is incompatible with Limonciello’s model, where the central concern is verifying a staged firmware payload and overwriting accessory firmware based on that verification, using a fixed, minimal set of steps designed to preserve security and reduce memory usage. (Remarks, page 8)
Examiner respectfully disagrees. Examiner stated in the above that Limonciello and Shepard with Moran are analogous art. It would have been obvious to one of ordinary in the art before the effective filing date of the claimed invention to modify Limonciello and Shepard with Moran. Limonciello teaches a method for the firmware payload is verified; and when the firmware payload is verified, updating the first memory with the firmware payload stored in the second memory by overwriting the original firmware and Shepard teaches a technique software updates for popular software products, such as Microsoft Corporation's Windows.RTM. family of operating systems and related productivity products. Such bottlenecks exist even when software updates are made available on multiple download locations distributed throughout the Interne. Further Moran teaches IoT-type devices may comprise, for example, resource constrained embedded devices that utilize hardware and/or software solutions lacking computing or processing power to run a sufficient security software, implement secure firmware update. One of ordinary skill in the art would have recognized that applying the known technique of Moran to seek improvement of Limonciello and Shepard would have yielded well-known predictable results and result in an improved firmware offset update system, as Limonciello discloses that firmware update procedure may include receiving, by a first component having a first memory storing an original firmware, an instruction to verify a firmware payload. See M.P.E.P. 2143(I)(D).
With respect to the rejections claim 1, under 35 USC 103, Applicant further argues that Introducing a behavioral scripting layer such as Moran’s into Limonciello’s flow would add orchestration complexity precisely where Limonciello aims for a simple, predictable path from integrity verification to overwrite, thereby undermining the design objective of a small and robust accessory-side updater. In addition, Shepard provides no bridge between these two worlds. Its XML metadata govern enterprise-level update applicability and distribution; they do
not script runtime device behavior and do not suggest that execution order, conditional branching, or parallelism should be encoded as part of the update metadata. Moran, in turn, does not propose importing an enterprise update schema or a hardware staging mechanism into its manifest language; it operates only once actions have been chosen. (Remarks, page 8-9)
Examiner respectfully disagrees. Applicant’s arguments are ineffective. Applicant argues regarding claim 1 limitations which are not part of claim 1. Further, in response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Limonciello, Shepard, and Moran are analogous art, teach firmware / software update procedure.
Applicant offers no other arguments beyond arguing allowability for the reasons cited for the independent claim(s) or dependence upon said claims. These arguments are considered met.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Step 1: Claims 1-7 directed to apparatus, claims claim 8-14 are directed to a medium, claim 15-18 are directed to computer implemented methods, claims 19-20 are directed to system and fall within the statutory categories. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes. With Step 1 being directed to a statutory category, the 2019 Interim Eligibility Guidance flowchart is directed to Step 2.
Under Step 2A, Prong 1, the claim 15 recites multiple limitations that recite an abstract idea. The limitations “accessing first information corresponding to a firmware (FW) payload, the FW payload to identify a FW component of a server (a server FW component);” , “accessing second information corresponding to FW update metadata, the FW update metadata to indicate one or more dependencies of a FW update of the server FW component; and “performing a validation of the one or more dependencies against corresponding server information;” and “in response to a determination of a success of the validation;” recites a mental process since accessing, determining and validating are concept that can be reasonably performed in the human mind (with the aid of pen and paper), which include observation, evaluation, judgement and/or opinion.
Under Step 2A, Prong 2, the additional elements “communicating with an execution engine to cause execution of the FW update on the server.” is not indicative of integration into a practical application. The limitations merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea.
Further, the additional elements merely recite insignificant extra solution activity such as communicating and updating firmware which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
Under step 2B, the additional elements do not amount to significantly more than the abstract idea. As stated above, the claimed invention merely recites generic computer system for carrying out or applying the abstract idea. Furthermore, the courts have recognized that mere data gathering, such as those defined in the claim, are well-understood, routine, and convention computer functions which cannot serve as an inventive concept according to MPEP 21.06.05(d).
For the above reasons, the claims of this application are not patentable under 35 USC 101.
Independent Claim 1: Under Step 2A, Prong 1, the claim recites multiple limitations that recite an abstract idea. The limitations “the FW payload to identify a server FW component;” , “access second information corresponding to FW update metadata, the FW update metadata to indicate one or more dependencies of a FW update of the server FW component;” , “perform a validation of the one or more dependencies against corresponding server information;” and “in response to a determination of a success of the validation;” recites a mental process since identifying, accessing, validating and determining are concept that can be reasonably performed in the human mind (with the aid of pen and paper), which include observation, evaluation, judgement and/or opinion.
Under Step 2A, Prong 2, the additional elements function of “one or more processors coupled to the communication interface, the one or more processors to:” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea.
Further, the additional elements “communicate with an execution engine to cause execution of the FW update on the server.” merely recite insignificant extra solution activity such as communicating and updating firmware which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
Under step 2B, the additional elements do not amount to significantly more than the abstract idea. As stated above, the claimed invention merely recites generic computer system for carrying out or applying the abstract idea. Furthermore, the courts have recognized that mere data gathering, such as those defined in the claim, are well-understood, routine, and convention computer functions which cannot serve as an inventive concept according to MPEP 21.06.05(d).
For the above reasons, the claims of this application are not patentable under 35 USC 101.
Independent claim 8 is not patent eligible for the same reasons given for claim 8, wherein the “A non-transitory computer-readable storage medium comprising instructions stored thereon that, when executed by one or more processors of a data center, cause the one or more processors to perform operations including: accessing first information corresponding to a firmware (FW) payload, the FW payload to identify a FW component of a server (a server FW component); … communicating with an execution engine to cause execution of the FW update on the server.
Independent claim 19 is not patent eligible for the same reasons given for claim 8, wherein the “A computing system of a data center, the computing system including: a server including a plurality of computing units and a plurality of memory circuitries coupled to the computing units; … communicate with an execution engine to cause execution of the FW update on the server.
Dependent claims 2-5, 7 and 9-10 are not patent eligible for the same reasons given for claim 1, wherein the “… determination of a failure of the validation, … communicate with the server to cause execution of the FW update … the execution engine is to be implemented on the server … server information includes information on at least one of existing versions … server information by way of an out-of-band communication” are merely a generic computer component for applying the abstract idea, thus fails to integrate the judicial exception into a practical application, nor an inventive concept.
Further dependent claims 6, 13-14 and 17 expand on the abstract idea whether a configuration of the server FW component is enabled or disabled, , activation of server, reset requirement of server and actions to be taken in response to an error scenario based on the FW update that do not integrate the invention into a practical application of the abstract idea or amount to significantly more.
Further dependent claims 11-12, 16, 18 and 20 expand on the abstract idea in its telemetry information, update metadata, and decoded by the server to at least one of authenticate that do not integrate the element into a practical application of the abstract idea or amount to significantly more. In addition the recited limitation is WURC as indicated in the prior art reference applied in the art rejection.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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, 4, 8, 15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Limonciello et al. (US 20200143057 A1 hereinafter Limonciello ) in view of Shepard et al. (US 20050228798 A1, hereafter Shepard) and Moran et al. (US 20200401700 A1, hereinafter Moran).
As to claim 1, Limonciello discloses An apparatus including:
a communication interface to couple the apparatus to one or more computing units (par. 0021, … information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems [i.e. computing units], data storage systems, and networking systems); and
one or more processors coupled to the communication interface, the one or more processors to (par. 0035, … a communication apparatus may include a transceiver having signals indicative of instructions and data. The instructions and data are configured to cause one or more processors to implement):
access first information corresponding to a firmware (FW) payload, the FW payload to identify a FW component of a server (a server FW component) (par. 0006, … receiving, by a first component having a first memory storing an original firmware, an instruction to verify a firmware payload for the first component [i.e. FW component] stored in a second memory of a second component … );
Limonciello does not explicitly disclose the following limitation but,
Shepard discloses access second information corresponding to FW update metadata, the FW update metadata to indicate one or more dependencies of a FW update of the server FW component (par. 0067, … in a first access, only elements of the update metadata to are necessary to determine whether a software update is applicable and/or desirable is first downloaded, such as applicability rules and dependencies upon other software updates. Then, after it is determined that an update is applicable and/or desirable, the remainder of the update metadata may be obtained. In response, at event 446 the parent update service node 402 returns the update metadata for the software update child update service node 404, which in turn stores the update metadata into the update information store 216);
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include access second information corresponding to FW update metadata, the FW update metadata to indicate one or more dependencies of a FW update of the server FW component, as disclosed by Shepard, for the purpose to identify dependency relationships the current software update (see abstract).
Moran discloses perform a validation of the one or more dependencies against corresponding server information (par. 0045, System Validation Behavior. A system [i.e. server] validation behavior process may be used, at least in part, to ensure that all required or appropriate dependencies are present, for example, and that all required or appropriate images are present); and
in response to a determination of a success of the validation (par. 0081 and 0083-0088, … [0081] function invoke(Document) Load $Document[Common Data] into parameters foreach (sequence in [Common, System Validation, Image Loading, Image Invocation]} rc = do_commands($sequence, $Document[$sequence]); if (rc is not SUCCESS) Abort endif end for end function … [0083] received or accessed a behavioral manifest, an IoT-type device may implement the following workflow, such as in the context of a firmware update, for example: [0084] Verify a signature of a manifest. [0085] Verify applicability of a manifest. [0086] Resolve dependencies. [0087] Fetch one or more payloads. Here, “payload” refers to electronic content to be delivered to or accessed by an electronic device (e.g., a firmware, etc.). [0088] Install one or more payloads), communicate with an execution engine to cause execution of the FW update on the server (pars. 0128, a behavioral description is more precise, and a machine definition upon which it relies is simpler, it may, for example, be augmented with proof that effects of an update fall within a specified policy, such as similarly to a Proof Carrying Code. By combining this capability with formal verification of a document processor, it may, for example, be possible to prove a result of a firmware update, such as prior to application, either on a device or on an intermediate system … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include perform a validation of the one or more dependencies against corresponding server information and in response to a determination of a success of the validation, communicate with an execution engine to cause execution of the FW update on the server, as disclosed by Moran, for the purpose to ensure that all required or appropriate electronic documents have been collected, such as prior to attempting to acquire any firmware image (see paragraph 42).
As to claim 4, Limonciello discloses the apparatus wherein the execution engine is to be implemented on the server (par. 0020, FIG. 7 is a flow chart illustrating a firmware update procedure executed by an information handling system).
As to claim 8, Limonciello-Mahajan teaches a non-transitory computer-readable medium on which is encoded program code (Limonciello at 0034), the program code comprising:
For remaining limitations see remarks regarding claim 1.
As to claim 15, (a method claim) recites substantially similar limitations to claim 1 (a system claim) and is therefore rejected using the same art and rationale set forth above.
At claim 19, Limonciello-Mahajan disclose a computing system of a data center, the computing system including:
a server including a plurality of computing units and a plurality of memory circuitries coupled to the computing units (Limonciello par. 0008, an apparatus may include an information handling system; a first component coupled to the accessory component, the first component having a first memory; and/or a second component coupled to the first component, the second component having a second memory. … );
For remaining limitations see remarks regarding claim 1.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Limonciello et al. , Shepard et al. and Moran et al. as applied to claim 1 above and in view of Polar Seminario (US 20170220404 A1, hereinafter Seminario).
As to claim 2, Limonciello as modified by Shepard and Moran does not discloses the following but,
Seminario discloses the apparatus wherein the one or more processors are to (abstract, … The at least one processor determines if there is an error associated with the first firmware.), in response to a determination of a failure of the validation (par. 0014, … a newer version of a firmware. Furthermore, the IED is configured to revert to previous versions of the firmware after a newer version of the firmware is installed on the IED if the IED determines there is an error associated with the newest version of the firmware, i.e., after a validation or sanity check. … ), discontinue communication regarding the FW update (par. 0347, … If, the updater program 2152 determines that the package name that was requested to be installed on the IED is not on the remote server's package list 2108 in step 2206, the updater program 2152 will discontinue communication with the remote server and provide the user with an error message … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include the apparatus wherein the one or more processors are to (), in response to a determination of a failure of the validation, discontinue communication regarding the FW update, as disclosed by Seminario, for the purpose to communicate with at least one remote computing device, wherein if the at least one processor determines there is an error associated with the second firmware (see paragraph 0025).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Limonciello et al. , Shepard et al. and Moran et al. as applied to claim 8 above and in view of Shiner et al. (US 20220131846 A1, hereinafter Shiner).
As to claim 10, Limonciello as modified by Shepard and Moran and disclose does not discloses the following but,
Shiner discloses the storage medium the operations including accessing the corresponding server information in a memory of the data center (pars. 0548-0549, … When the activity associated with the identity data 113 satisfies the condition, the validation response 174 can be configured to cause a client server to decline a request 171 for a service for the endpoint 150 as identified by the identity data 113 … The condition can be evaluated for the activity based on activity information 177 embedded by the memory device 130 in the identity data 113 and/or access attributes 449 provided by a client server 141 in the validation request 173. … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include the storage medium the operations including accessing the corresponding server information in a memory of the data center, as disclosed by Shiner, for the purpose of performing a security operation associated with the condition in providing a validation response in responding to the validation request. (see paragraph 0546).
Claims 12, 14 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Limonciello et al. , Shepard et al. and Moran et al. as applied to claims 8 and 15 above and in view of Bandakka et al. (US 20130125107 A1, hereinafter Bandakka).
As to claim 12, Limonciello as modified by Shepard and Moran does not discloses the following but,
Bandakka discloses the storage medium wherein the FW update metadata includes a FW update formula, the FW update formula including information to be used for communicating with the execution engine to cause execution of the FW update (par. 0106, … In operation 601, the firmware update application running on client device 102 generates and sends a handshake request to the remote management server, so as to perform server authentication. The handshake request may take the form of an HTTP post, and may be used to determine whether the firmware update application is able to communicate with the remote management server. If the firmware update application does not receive a response from the remote management server, or if the firmware update application receives an error response [i.e. update formula pre-update action], the firmware update application can terminate the firmware update process. However, if the handshake request successfully reaches the remote management server, the remote management server generates and send a handshake acknowledgement to the firmware update application in operation 603. … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include the storage medium wherein the FW update metadata includes a FW update formula, the FW update formula including information to be used for communicating with the execution engine to cause execution of the FW update, as disclosed by Bandakka, for the purpose of checking prior to beginning the installation of the package on the client device. In order to verify the integrity of an image package (see paragraph 21).
As to claim 14, Bandakka discloses the storage medium wherein the FW update formula further includes pre-update information regarding a pre-update phase of the FW update, the pre-update information including information on at least one of:
instructions on actions to be taken in response to an error scenario based on the FW update (par. 0106, if the firmware update application receives an error response, the firmware update application can terminate the firmware update process … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include instructions on actions to be taken in response to an error scenario based on the FW update, as disclosed by Bandakka, for the purpose the purpose of checking prior to beginning the installation of the package on the client device. In order to verify the integrity of an image package (see paragraph 21).
As to claim 16, Bandakka discloses s wherein the method wherein the FW update metadata includes a FW update formula (par. 0021 … a target client device can be checked prior to [i.e. FW update formula – pre-update] beginning the installation of the package on the client device. In order to verify the integrity of an image package, a computer administrator may make sure that all imaging components are present on the target client device …), the FW update formula including information to be used for communicating with the execution engine to cause execution of the FW update, the FW update formula further including pre-update information regarding a pre-update phase of the FW update, the pre- update information indicating pre-update actions including on at least one of (par. 0109, … . If the remote management server determines [i.e. pre- update information indicating pre-update actions]the package verification to be a failure (e.g., if all packages identified in the configuration file are not stored in the repository, and/or if all stored packages do not have the identified package size), the remote management server updates a record to indicate that no firmware updates are available):
verifying that an initial state of the server for executing the FW update is met (par. 0111, … the firmware update application proceeds to retrieve from the firmware update configuration file the list of packages (or files) and corresponding package sizes identified in the configuration file. The firmware update application then sends a package verification request to the repository server in operation 615, the package verification request including identification for each of the packages and corresponding package sizes. The repository server provides a verification response message in operation 617 including information about packages stored by the repository server, including package size information. In response to receiving the verification response, the firmware update module determines if all packages identified in the firmware update configuration file are stored in the repository server and have the corresponding package sizes, based on the verification response message. If all packages identified in the firmware update configuration file are stored on the repository server and have the correct sizes, the verification is a success [i.e. met]. …);
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include verifying that an initial state of the server for executing the FW update is met, as disclosed by Bandakka, for the purpose of the purpose of checking prior to beginning the installation of the package on the client device. In order to verify the integrity of an image package (see paragraph 21)
As to claim 17, Bandakka discloses wherein the method wherein the FW update formula further includes post-update information regarding a post-update phase of the FW update (par. 0106), the post-update information including information on at least one of:
(par. 0106, if the firmware update application receives an error response, the firmware update application can terminate the firmware update process … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include instructions on actions to be taken in response to an error scenario based on the FW update, as disclosed by Bandakka, for the purpose the purpose of checking prior to beginning the installation of the package on the client device. In order to verify the integrity of an image package (see paragraph 21).
Claims 3 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Limonciello et al. , Shepard et al. and Moran et al. as applied to claims 1 and 8 above and in view of Liedtke et al. (US 20200257518 A1, hereinafter Liedtke).
As to claim 3, Limonciello as modified by Shepard and Moran does not explicitly disclose the following limitation but,
Liedtke discloses the apparatus wherein the one or more processors are to communicate with the server to cause execution of the FW update during runtime at the server (par 0068, … update purposes between PRoT 702 and Platform Firmware Configuration Service 710 occurs. During runtime, a firmware update or other software can be sent by Platform Firmware Configuration Service 710 to PRoT 702 or other devices in platform 700 ... ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include the apparatus wherein the execution engine is to be implemented on the server, as disclosed by Liedtke, for the purpose of making specialized firmware update process (see paragraph 01).
As to claim 11, Liedtke discloses the storage medium the operations including collecting telemetry information on the server, the corresponding server information corresponding to the telemetry information (par. 0034, … Firmware updates applied to a network interface can cause the network interface to be disabled during the firmware update and some solutions drop link on a manageability port during a firmware update. Manageability network ports provide heartbeat packets, probe messages, telemetry collection).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include the storage medium of claim 8, the operations including collecting telemetry information on the server, the corresponding server information corresponding to the telemetry information, as disclosed by Liedtke for the purpose of implementing of High Availability (HA), fault tolerance, and manageability (see par. 0034).
Claims 5-7, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Limonciello et al. , Shepard et al. and Moran et al. as applied to claims 1, 15 and 19 above and in view of Thurston et al. (US 20030217193 A1, hereinafter Thurston).
As to claim 5, Limonciello as modified by Shepard and Moran does not explicitly disclose the following limitation but,
Thurston discloses the apparatus wherein the second information includes information on at least one of a version of the server FW component or expected versions of other FW components of the server (par. 0052, the device independent firmware update utility 302 requests the device dependent plug-in module 306 to confirm that system wide constraints are being satisfied before proceeding with the firmware installation. The system wide constraints may be distributed within the firmware update application 200 or the firmware package 108a, and may include constraints such as the version [i.e. second information] of the operating system, the amount of available storage, etc., that may need to be satisfied before installing the binary firmware image 404. The device dependent plug-in module 306 receives (at block 706) the request to verify the system wide constraints. … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include the apparatus wherein the second information on one or more dependencies includes information on at least one of a version of the server FW component or expected versions of other FW components of the server, as disclosed by Thurston, for the purpose of identifying the version number is read by the firmware update application (see par. 0009).
As to claim 6, Thurston discloses the apparatus wherein the second information further includes information on at least one of:
(par. 0010, The implementations provide a firmware image, metadata on the firmware image and a firmware update application for updating firmware on different types of hardware devices. The firmware update application interprets the metadata on a data processing system and based on the interpretation, installs the firmware image on a hardware device. The firmware update application separates device independent firmware update functions from device dependent firmware update functions …);
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include a hardware of the server, as disclosed by Thurston, for the purpose of identifying the version number is read by the firmware update application (see par. 0009).
As to claim 7, Thurston discloses the apparatus wherein the corresponding server information includes information on at least one of existing versions of the other FW components (par. 0043, … The minimum version on device for upgrade may be "1.3" (reference numeral 424) implying that unless the device has a firmware version of 1.3 or greater the firmware update application 200 should not install the binary firmware image 404 on the hardware device 310, 311. The firmware update application version may be "1.4.02" (reference numeral 426) indicating a version of the firmware update … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include the apparatus wherein the corresponding server information includes information on at least one of existing versions of the other FW components, as disclosed by Thurston, for the purpose of identifying the version number is read by the firmware update application (see par. 0009). (see page 6, last par).
As to claim 18, Limonciello discloses the method further including receiving a FW update capsule including the FW payload (Fig. 3, par 0030, A method performed by the accessory component receiving a firmware payload as part of the staged firmware update process … );
Thurston discloses the FW update metadata (Fig. 6, par. 0049, … he process starts at block 600, where the device independent firmware update utility 302 after receiving the firmware update package 108a extracts the metadata … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include receiving FW update metadata, as disclosed by Thurston, for the purpose of implementing in the device independent firmware update utility (see paragraph 49).
As to claim 20, Limonciello discloses the system wherein the one or more processors are to receive a FW update capsule including the FW payload (Fig. 3, par 0030, A method performed by the accessory component receiving a firmware payload as part of the staged firmware update process … );
Thurston discloses the FW update metadata (Fig. 6, par. 0049, … he process starts at block 600, where the device independent firmware update utility 302 after receiving the firmware update package 108a extracts the metadata … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include receiving FW update metadata, as disclosed by Thurston, for the purpose of implementing in the device independent firmware update utility (see paragraph 49).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Limonciello et al. , Shepard et al. and Moran et al. as applied to claim 8 above and in view of Ladkani et al. (US 20220129258 A1, hereinafter, Ladkani)
As to claim 9, Limonciello as modified by Shepard and Moran does not explicitly disclose the following limitation but,
Ladkani discloses the storage medium the operations including receiving the corresponding server information by way of an out-of-band communication from the server (par. 0011, The firmware update patch may be received from the management entity via an out-of-band communication path. The management entity may communicate with a management agent on the host computing device via a primary communication path. The out-of-band communication path may be independent of the primary communication path).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include the storage medium the operations including receiving the corresponding server information by way of an out-of-band communication from the server, as disclosed by Ladkani for the purpose of making independent of the primary communication path. (see par. 0011).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Limonciello et al. , Shepard et al., Moran et al. and Bandakka as applied to claims 12 above and in view of Ali et al. (US 20180293066 A1, hereinafter Ali).
As to claim 13, Limonciello as modified by Shepard, Moran and Samuel does not explicitly disclose the following limitation but,
Ali discloses the storage medium wherein the FW update formula further includes information to cause activation of the server FW component on the server based on execution of the FW update (Fig. 7, pars. 0034 and 0060, ] … the infrastructure of solution infrastructure 100 may include, in addition to the physical hardware components, any and all software and/or firmware components, including BIOS firmware … The update engine 331 may then start (operation 536) update of the next module in the UPDATE SEQUENCE LIST. Once all updates have successfully completed [i.e. executed FW update], update engine 331 may inform (operation 538) validation engine 143 to exit maintenance mode [i.e. activation] … ).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the system disclosed by Limonciello to include the storage medium wherein the FW update formula further includes information to cause activation of the server FW component on the server based on execution of the FW update, as disclosed by Ali, for the purpose of making sure that all components is performed, the update engine and ensure operation (see paragraph 62).
Conclusion
THIS ACTION IS MADE FINAL REJECTION: Applicant's arguments have been fully considered but they are not persuasive because of above reason. The examiner respectfully traverses applicant’s arguments and made this action 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 extension fee 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 Mohammad Kabir whose telephone number is (571)270-13411. The examiner can normally be reached on M-F, 8:00 am - 5:00 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sam Sough can be reached on (571) 272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Mohammad Kabir/
Examiner, Art Unit 2192
/S. SOUGH/spe, art unit 2192