DETAILED ACTION
This is the initial Office action based on the application filed on January 12, 2024.
Claims 1-20 are pending.
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 .
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because reference character “185” has been used to designate both “Storage(s)” and “Storage device.” The specification only mentions reference character “185” in regard to “Storage device.” The drawings also include the following reference character not mentioned in the specification: “189” in Figure 1. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
Paragraph 0066, line 4, recites “or a deployment cloud, For example, when.” It should read -- or a deployment cloud. For example, when --.
Paragraph 0068, line 8, recites “and other system.” It should read -- and other systems --.
Paragraph 0080, line 2, recites “such ass FSP.” It should read -- such as FSP --.
Paragraph 0097, line 2, recites “allows the the BMC.” It should read -- allows the BMC --.
Appropriate correction is required.
Claim Objections
Claims 1, 5, 18, and 20 are objected to because of the following informalities:
Claims 1, 18, and 20 recite in lines 6-7, lines 8-9, and lines 7-8 respectively “the identified hardware change.” It should read -- an identified hardware change --.
Claim 5 recites in line 2, “the components.” It should read -- the selected firmware components --.
Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-3, 7-9, 11, and 15 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over Claims 1, 6, 9-11, 14, and 16 of co-pending Application No. 18/626,474 (hereinafter “reference application”) in view of US 2024/0385866 (hereinafter “Peterson”) and US 2017/0300690 (hereinafter “Ladnai”).
It is noted that the instant application is an earlier filed co-pending application and the reference application is a later filed co-pending application. It is also noted that both the reference application and the instant application were filed by the same applicant. Claims 1, 6, 9-11, 14, and 16 of the reference application recite some of the limitations of Claims 1-3, 7-9, 11, and 15 of the instant application. Although the conflicting claims are not identical, they are not patentably distinct from each other because Claims 1-3, 7-9, 11, and 15 of the instant application define an obvious variation of the invention claimed in the reference application. For illustrative purposes, a detailed analysis for Claim 1 of the instant application is provided.
The “constructing” step recited within Claim 9 of the reference application is an obvious variant of the “selecting” and “assembling” steps within Claim 1 of the instant application. Constructing a consolidated firmware image containing firmware modules, which are not patentably distinct from the firmware components in Claim 1 of the instant application, reasonably includes the build orchestrator selecting and assembling the firmware modules into the firmware image for the identified hardware change in order to construct it. However, Claim 1 of the instant application recites further limitations of “initializing a build orchestrator configured to monitor system events from different server systems” and “receiving, at the build orchestrator, an event indicating a hardware change in a modular hardware system.”
As per Claim 1 of the instant application, Peterson discloses:
initializing a build orchestrator configured to monitor system events from different server systems (paragraph [0062], “An “Orchestrator” is intended to refer to a service or system that initiates tasks involved in bootstrapping one or more services during a region build […] An orchestrator may track relevant events (e.g., indicated through capabilities and/or skills as described herein) for each service of the region build and takes actions in response to those events […] (emphasis added).”; paragraph [0059], “A “capability” identifies is a resource used during region build that signals that another resource, service, or feature is available [system event], or that an event has occurred. By way of example, a capability can be published indicating that a resource is available for authorization/authentication processing (e.g., a subset of the functionality to be provided by a service) (emphasis added).”; paragraph [0041], “Embodiments of the present disclosure relate to techniques for performing an automated region build (e.g., bootstrapping (e.g., provisioning and/or deploying) resources (e.g., infrastructure component [server system], artifacts, etc.) for any suitable number of services within a region (e.g., a geographical location associated with one or more data centers)) (emphasis added).”) [Examiner’s Remarks: Note that Peterson discloses that resources include infrastructure components (server systems) and that an automated region build includes bootstrapping resources for multiple services (different server systems) within a region. Peterson also discloses a (build) orchestrator that initiates bootstrapping tasks during a region build and tracking relevant events indicated through capabilities for each service where the capabilities signal whether a resource is available. One of ordinary skill in the art would readily comprehend that the capabilities may represent system events regarding resource availability and that the build orchestrator must be initialized and configured to monitor these system events in order to track relevant events of each service (different server systems) of the region build.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the reference application to incorporate the teaching of Peterson into the reference application to include “initializing a build orchestrator configured to monitor system events from different server systems.” The modification would be obvious because one of ordinary skill in the art would be motivated to drive orchestration using a build orchestrator that utilizes Puffin (a skills service that may be used to generate a “blueprint for build-time and run-time dependencies”) to “remove operational overhead, improve information accuracy, surface critical data including the ability to present interconnected service skills dependencies in a visual graph” (Peterson, paragraphs [0043 & 0045]).
The combination of the reference application and Peterson discloses “receiving, at the build orchestrator (Peterson, paragraph [0080], “In some embodiments, Orchestrator 106 may be configured to monitor (or be otherwise notified of) changes to the region data managed by Real-time Regional Data Distributor 104. In some embodiments, receiving an indication that region data has been changed may cause a region build to be triggered by Orchestrator 106 (emphasis added).”)” and “a modular system (Claim 9 of the reference application),” but does not explicitly disclose:
receiving, at the build orchestrator, an event indicating a hardware change in a modular hardware system.
However, Ladnai discloses:
receiving […] an event indicating a hardware change in a hardware system (paragraph [0007], “Detecting the security event may include detecting a hardware change (emphasis added).”; paragraph [0095], “A security product 332 may execute on the endpoint 310 to detect a security event on the endpoint 310, which may act as the beacon or trigger event for the system 300.”) [Examiner’s Remarks: Note that Ladnai discloses a security product detecting a security event and that detecting a security event can include detecting a hardware change. One of ordinary skill in the art would readily comprehend that detecting a security event (hardware change) requires the security product to receive the event and that a hardware change is a change made within a hardware system.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the reference application to incorporate the teaching of Ladnai into the combined teaching of the reference application and Peterson to include “receiving, at the build orchestrator, an event indicating a hardware change in a modular hardware system.” The modification would be obvious because one of ordinary skill in the art would be motivated to receive/detect events indicating hardware changes and other security events used to generate an event graph representing the sequence of events/computer objects associated with the detected security event to “obtain a useful snapshot of events optimized for root cause analytics” (Ladnai, paragraphs [0121 & 0122]).
A claim chart follows with the corresponding limitations between Claim 9 of the reference application and Claim 1 of the instant application in bold.
Co-Pending Application No. 18/626,474
Instant Application No. 18/411,450
9. A method of updating firmware by a build orchestrator, comprising: detecting, by the build orchestrator, a change in a hardware component of a data center secure control module (DC-SCM) in a modular hardware system; constructing, by the build orchestrator, a consolidated firmware update image containing one or more firmware modules or one or more components of the DC-SCM based on the detected change; and deploying, by the build orchestrator, the consolidated firmware update image to a baseboard management controller (BMC) of the DC-SCM.
1. A method of building a customized firmware image, comprising: initializing a build orchestrator configured to monitor system events from different server systems; receiving, at the build orchestrator, an event indicating a hardware change in a modular hardware system; selecting, by the build orchestrator, appropriate firmware components for the identified hardware change; and assembling the selected firmware components into the customized firmware image tailored to the identified hardware change.
A claim chart follows with the corresponding limitations between Claims 2, 3, 7-9, 11, and 15 of the instant application and Claims 1, 6, 9-11, 14, and 16 of the reference application in bold. A detailed analysis is not shown for the purpose of brevity.
Co-Pending Application No. 18/626,474
Instant Application No. 18/411,450
10. The method of claim 9, wherein the one or more firmware modules include at least one of a basic input/output system (BIOS) firmware module, a BMC firmware module, and a hardware root of trust (HROT) firmware module.
2. The method of claim 1, wherein the customized firmware image is a baseboard management controller (BMC) firmware image or a boot firmware image.
11. The method of claim 9, wherein the constructing the consolidated firmware update image comprises: determining a set of hardware components to be updated based on the detected change; retrieving, for each of the set of hardware components, a corresponding firmware module; and packaging the retrieved firmware modules into the consolidated firmware update image, wherein each firmware module is associated with a header containing information about the firmware module.
3. The method of claim 1, wherein selecting appropriate firmware components comprises: identifying a target platform based on the hardware change; determining a system-on-a-chip (SOC) module associated with the modular hardware system; and selecting modular firmware components corresponding to the identified target platform and SOC module.
9. A method of updating firmware by a build orchestrator, comprising: detecting, by the build orchestrator, a change in a hardware component of a data center secure control module (DC-SCM) in a modular hardware system; constructing, by the build orchestrator, a consolidated firmware update image containing one or more firmware modules for one or more components of the DC-SCM based on the detected change; and deploying, by the build orchestrator, the consolidated firmware update image to a baseboard management controller (BMC) of the DC-SCM.
7. The method of claim 1, further comprising: transmitting the customized firmware image to the modular hardware system.
1. A method of updating firmware by a baseboard management controller (BMC), comprising: receiving, by the BMC, a consolidated firmware update image containing one or more firmware modules for one or more components of a data center secure control module (DC-SCM); parsing, by the BMC, the consolidated firmware update image to identify the one or more firmware modules; selecting, by the BMC, a set of hardware components to be updated based on the parsing of the consolidated firmware update image; and updating, by the BMC, firmware of the selected set of hardware components using the corresponding firmware modules from the consolidated firmware update image.
8. The method of claim 7, further comprising: updating a pre-existing firmware image in the modular hardware system using the customized firmware image.
14. The method of claim 9, wherein the change in the hardware component comprises at least one of: a change in a host processor module (HPM) of the modular hardware system, wherein the change in the HPM is detected based on a notification from the BMC; and a change in the BMC of the DC-SCM, wherein the change in the BMC is detected based on a mismatch between an identifier of the BMC and a stored identifier of the BMC in a hardware inventory database.
9. The method of claim 1, wherein the hardware change pertains to one or more of: a host processor module (HPM), a baseboard management controller (BMC), a device configuration.
16. The method of claim 9, wherein the constructing the consolidated firmware update image comprises: retrieving a platform configuration for the modular hardware system from a configuration database; and constructing the consolidated firmware update image based on the retrieved platform configuration.
11. The method of claim 1, further comprising dynamically fetching platform-specific configuration files during the assembly of the customized firmware image.
6. The method of claim 1, wherein the consolidated firmware update image is received from a build orchestrator in response to the build orchestrator detecting a change in a hardware component of the DC-SCM.
15. The method of claim 1, further comprising triggering the build orchestrator to initiate the assembly of the customized firmware image in response to changes detected in device configurations within the modular hardware system.
Thus, Claims 1-3, 7-9, 11, and 15 of the instant application are obvious over Claims 1, 6, 9-11, 14, and 16 of the reference application.
This is a provisional nonstatutory double patenting rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 14 and 17 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim 14 recites in lines 2-3 the limitation “the system-on-chip (SOC).” There is insufficient antecedent basis for this limitation in the claims. In the interest of compact prosecution, the Examiner subsequently interprets this limitation as -- a system-on-chip (SOC) -- in Claim 14.
Claim 17 recites in lines 2-3 the limitations “the reconfiguration of the firmware” and “the updated hardware specifications.” There is insufficient antecedent basis for these limitations in the claims. In the interest of compact prosecution, the Examiner subsequently interprets these limitations as -- reconfiguration of the firmware -- and -- updated hardware specifications -- in Claim 17.
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.
Claim 20 is rejected under 35 U.S.C 101 because the claimed invention is directed to non-statutory subject matter.
Claim 20 is directed to a computer-readable medium storing computer executable code. It is noted that the specification does not provide an explicit definition for a computer-readable medium. It is also noted that the specification includes exemplary language for a computer-readable medium that covers signals per se by stating that computer-readable media includes “any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.” The broadest reasonable interpretation of a claim drawn to a computer-readable medium covers forms of non-transitory tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of a computer-readable medium, particularly when the specification is silent. See MPEP § 2111.01. When the broadest reasonable interpretation of a claim covers a signal per se, the claim must be rejected under 35 US.C. § 101 as covering non-statutory subject matter. See In re Nuijten, 500 F.3d 1346, 1356-57 (Fed. Cir. 2007) (transitory embodiments are not directed to statutory subject matter) and Interim Examination Instructions for Evaluating Subject Matter Eligibility Under 35 U.S.C. § 101, Aug. 24, 2009; p. 2. Therefore, the claimed computer-readable medium is ineligible subject matter under § 101. Applicant is advised to amend the claim to recite “a non-transitory computer-readable medium” in order to overcome the 35 U.S.C. § 101 rejection.
Claims 1-7, 9-16, and 18-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim Interpretation: Under the broadest reasonable interpretation (BRI), the limitations of Claim 1 are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP § 2111.
Step 1: Claim 1 is directed to a method, which is a process (a series of steps or acts), and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 1 recites the limitations:
monitor system events from different server systems;
selecting appropriate firmware components for the identified hardware change.
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
initializing a build orchestrator configured to;
a build orchestrator.
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human observing system events from different server systems using observation, evaluation, judgment, and opinion to monitor the system events. Similarly, the limitation (b) in the context of the claim encompasses a human observing and evaluating appropriate firmware components for the identified hardware change using observation, evaluation, judgment, and opinion to mentally select the appropriate firmware components. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
initializing a build orchestrator configured to;
a build orchestrator.
The additional elements (1) and (2) are recited at a high-level of generality such that they amount to no more than mere instructions to apply the judicial exception using generic computer components. The build orchestrator is used as a tool to perform the monitoring, receiving, and selecting steps of the claim. See MPEP § 2106.05(f).
Also, the claim recites the additional element:
receiving an event indicating a hardware change in a modular hardware system.
The additional element (3) is mere data gathering recited at a high level of generality, and thus is insignificant extra-solution activity. See MPEP § 2106.05(g). Furthermore, all uses of the recited judicial exception require such data gathering, and, as such, the additional element does not impose any meaningful limits on the claim. The additional element amounts to necessary data gathering. See MPEP § 2106.05.
Also, the claim recites the additional element:
assembling the selected firmware components into the customized firmware image tailored to the identified hardware change.
The additional element (4) fails to meaningfully limit the claim because it does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. See MPEP § 2106.05(f). The additional element recites only the idea of assembling the selected firmware components into the customized firmware image without details on how this is accomplished. The claim omits any details as to how the assembling of the selected firmware components solves a technical problem, and instead recites only the idea of a solution or outcome. Therefore, the additional element attempts to cover any solution to the identified problem of assembling the selected firmware components into the customized firmware image with no restriction on how the assembling is accomplished and no description of the mechanism for accomplishing the assembling, and does not integrate a judicial exception into a practical application because this type of recitation is equivalent to the words “apply it.”
Accordingly, even when viewed in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
initializing a build orchestrator configured to;
a build orchestrator.
The additional elements (1) and (2) amount to no more than mere instructions to apply the judicial exception using generic computer components. Mere instructions to apply a judicial exception using generic computer components cannot provide an inventive concept.
Also, the claim recites the additional element:
receiving an event indicating a hardware change in a modular hardware system.
The additional element (3) simply appends well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of receiving or transmitting data over a network, e.g., using the Internet to gather data as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activities. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to receive an event indicating a hardware change in a modular hardware system. Therefore, the limitation remains insignificant extra-solution activity even upon reconsideration and does not amount to significantly more.
Also, the claim recites the additional element:
assembling the selected firmware components into the customized firmware image tailored to the identified hardware change.
The additional element (4) does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. The analysis under Step 2A, Prong Two is carried through to Step 2B. Therefore, the additional element attempts to cover any solution to the identified problem of assembling the selected firmware components into the customized firmware image with no restriction on how the assembling is accomplished and no description of the mechanism for accomplishing the assembling, and does not provide significantly more because this type of recitation is equivalent to the words “apply it.”
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components, insignificant extra-solution activities, and only the idea of a solution or outcome, and therefore do not provide an inventive concept. The claim is not patent eligible.
Claims 2-7 and 9-16 are rejected under 35 U.S.C. 101 as directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more for at least the reasons stated above.
Claim 2 recites the limitation:
wherein the customized firmware image is a baseboard management controller (BMC) firmware image or a boot firmware image.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 3 recites the limitations:
wherein selecting appropriate firmware components comprises:
identifying a target platform based on the hardware change;
determining a system-on-a-chip (SOC) module associated with the modular hardware system; and
selecting modular firmware components corresponding to the identified target platform and SOC module.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 4 recites the limitation:
wherein the modular firmware components are selected from a group comprising Linux kernel, U-Boot bootloader, root filesystem, and platform configuration capsules.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 5 recites the limitations:
wherein assembling the selected firmware components comprises configuring the components;
using a build orchestration system implementing an open source build framework.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 6 recites the limitation:
wherein the open source build framework includes a build orchestrator, a build engine, and a package manager to facilitate construction of the customized firmware image.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 7 recites the limitation:
transmitting the customized firmware image to the modular hardware system.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 9 recites the limitation:
wherein the hardware change pertains to one or more of: a host processor module (HPM), a baseboard management controller (BMC), a device configuration.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 10 recites the limitations:
validating the customized firmware image prior to deploying to the modular hardware system;
on one or more test platforms.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 11 recites the limitation:
dynamically fetching platform-specific configuration files during the assembly of the customized firmware image.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 12 recites the limitation:
wherein the platform-specific configuration files include one or more of Sensor Data Record (SDR) information, platform event filter configurations, entity manager configurations, static tables for platform components, and power and thermal management algorithms.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 13 recites the limitations:
using a configuration file to instruct the build orchestrator on the selection and assembly of firmware components for the customized firmware image based on the identified hardware change.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 14 recites the limitation:
wherein the configuration file specifies general platform information, platform-specific repository metadata, metadata for the system- on-chip (SOC) specific to a baseboard management controller, and listings for compiling the firmware components.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 15 recites the limitation:
triggering the build orchestrator to initiate the assembly of the customized firmware image in response to changes detected in device configurations within the modular hardware system.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim 16 recites the limitation:
wherein the build orchestrator is configured to build the customized firmware image by injecting appropriate meta-layers into a build process according to the identified hardware change.
These claims are dependent on Claim 1, but do not add any feature or subject matter that would solve the judicial exception deficiencies of Claim 1.
Claims 3, 4, 10, and 13 recite further mental steps which can be practically performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper and thus, fail to make the claim any less abstract (see MPEP § 2106.04(a)(2)(III)).
Claims 2, 5-7 and 9-16 recite further additional elements that do not integrate the judicial exception into a practical application of the judicial exception and thus, are not significantly more than the abstract idea. Specifically, the additional element (b) recited in Claim 5, the additional element (b) recited in Claim 10, and the additional element (a) recited in Claim 13 fail to meaningfully limit the claim because they amount to no more than mere instructions to apply the judicial exception using generic computer components. See MPEP § 2106.05(f). The additional element (a) recited in Claim 2, the additional element (a) recited in Claim 5, the additional element (a) recited in Claim 6, the additional element (a) recited in Claim 15, and the additional element (a) recited in Claim 16 fail to meaningfully limit the claim because it does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. See MPEP § 2106.05(f). The additional element (a) recited in Claim 7 and the additional element (a) recited in Claim 11 fail to meaningfully limit the claim because it is mere data gathering/outputting recited at a high level of generality, and thus are insignificant extra-solution activities (simply appends well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept). See MPEP § 2106.05(g). The additional element (a) recited in Claim 9, the additional element (a) recited in Claim 12, and the additional element (a) recited in Claim 14 fail to meaningfully limit the claim because they amount to merely indicating a field of use or technological environment in which to apply a judicial exception which does not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application. See MPEP § 2106.05(h). Therefore, Claims 2-7 and 9-16 do not add any steps or additional elements, when considered both individually and as a combination, that would convert Claim 1 into patent-eligible subject matter.
Claims 1-7 and 9-16 are therefore not drawn to patent-eligible subject matter as they are directed to an abstract idea without significantly more.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim Interpretation: Under the broadest reasonable interpretation (BRI), the limitations of Claim 18 are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP § 2111.
Step 1: Claim 18 is directed to a system, which is a machine and/or manufacture, and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 18 recites the limitations:
monitor system events from different server systems;
select appropriate firmware components for the identified hardware change.
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
a memory;
at least one processor coupled to the memory and configured to;
initialize a build orchestrator configured to;
a build orchestrator.
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human observing system events from different server systems using observation, evaluation, judgment, and opinion to monitor the system events. Similarly, the limitation (b) in the context of the claim encompasses a human observing and evaluating appropriate firmware components for the identified hardware change using observation, evaluation, judgment, and opinion to mentally select the appropriate firmware components. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
a memory;
at least one processor coupled to the memory and configured to;
initialize a build orchestrator configured to;
a build orchestrator.
The additional elements (1) to (4) are recited at a high-level of generality such that they amount to no more than mere instructions to apply the judicial exception using generic computer components. The memory, processor, and build orchestrator are used as tools to perform the monitoring, receiving, selecting, and assembling steps of the claim. See MPEP § 2106.05(f).
Also, the claim recites the additional element:
receive an event indicating a hardware change in a modular hardware system.
The additional element (5) is mere data gathering recited at a high level of generality, and thus is insignificant extra-solution activity. See MPEP § 2106.05(g). Furthermore, all uses of the recited judicial exception require such data gathering, and, as such, the additional element does not impose any meaningful limits on the claim. The additional element amounts to necessary data gathering. See MPEP § 2106.05.
Also, the claim recites the additional element:
assemble the selected firmware components into the customized firmware image tailored to the identified hardware change.
The additional element (6) fails to meaningfully limit the claim because it does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. See MPEP § 2106.05(f). The additional element recites only the idea of assembling the selected firmware components into the customized firmware image without details on how this is accomplished. The claim omits any details as to how the assembling of the selected firmware components solves a technical problem, and instead recites only the idea of a solution or outcome. Therefore, the additional element attempts to cover any solution to the identified problem of assembling the selected firmware components into the customized firmware image with no restriction on how the assembling is accomplished and no description of the mechanism for accomplishing the assembling, and does not integrate a judicial exception into a practical application because this type of recitation is equivalent to the words “apply it.”
Accordingly, even when viewed in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
a memory;
at least one processor coupled to the memory and configured to;
initialize a build orchestrator configured to;
a build orchestrator.
The additional elements (1) to (4) amount to no more than mere instructions to apply the judicial exception using generic computer components. Mere instructions to apply a judicial exception using generic computer components cannot provide an inventive concept.
Also, the claim recites the additional element:
receive an event indicating a hardware change in a modular hardware system.
The additional element (5) simply appends well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of receiving or transmitting data over a network, e.g., using the Internet to gather data as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activities. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to receive an event indicating a hardware change in a modular hardware system. Therefore, the limitation remains insignificant extra-solution activity even upon reconsideration and does not amount to significantly more.
Also, the claim recites the additional element:
assemble the selected firmware components into the customized firmware image tailored to the identified hardware change.
The additional element (6) does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. The analysis under Step 2A, Prong Two is carried through to Step 2B. Therefore, the additional element attempts to cover any solution to the identified problem of assembling the selected firmware components into the customized firmware image with no restriction on how the assembling is accomplished and no description of the mechanism for accomplishing the assembling, and does not provide significantly more because this type of recitation is equivalent to the words “apply it.”
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components, insignificant extra-solution activities, and only the idea of a solution or outcome, and therefore do not provide an inventive concept. The claim is not patent eligible.
Claim 19 is rejected under 35 U.S.C. 101 as directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more for at least the reasons stated above.
Claim 19 recites the limitation:
wherein the customized firmware image is a baseboard management controller (BMC) firmware image or a boot firmware image.
This claim is dependent on Claim 18, but does not add any feature or subject matter that would solve the judicial exception deficiencies of Claim 18.
Claim 19 recites further additional elements that do not integrate the judicial exception into a practical application of the judicial exception and thus, are not significantly more than the abstract idea. Specifically, the additional element (a) recited in Claim 19 fails to meaningfully limit the claim because it does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. See MPEP § 2106.05(f). Therefore, Claim 19 does not add any steps or additional elements, when considered both individually and as a combination, that would convert Claim 18 into patent-eligible subject matter.
Claims 18 and 19 are therefore not drawn to patent-eligible subject matter as they are directed to an abstract idea without significantly more.
<<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>> + <<>>
Claim Interpretation: Under the broadest reasonable interpretation (BRI), the limitations of Claim 20 are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. See MPEP § 2111.
Step 1: Claim 20 is directed to a computer-readable medium, which is an article of manufacture, and falls within one of the statutory categories of invention.
Step 2A, Prong One: Claim 20 recites the limitations:
monitor system events from different server systems;
select appropriate firmware components for the identified hardware change.
These recited steps, under the broadest reasonable interpretation (BRI), cover performance of the steps in the human mind alone or with the aid of pen and paper. That is, other than reciting:
initialize a build orchestrator configured to;
a build orchestrator.
Nothing in the claim precludes the steps from practically being performed in the human mind alone using observation, evaluation, judgment, and opinion or with the aid of pen and paper. For example, the limitation (a) in the context of the claim encompasses a human observing system events from different server systems using observation, evaluation, judgment, and opinion to monitor the system events. Similarly, the limitation (b) in the context of the claim encompasses a human observing and evaluating appropriate firmware components for the identified hardware change using observation, evaluation, judgment, and opinion to mentally select the appropriate firmware components. See MPEP § 2106.04(a)(2)(III).
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the human mind alone or with the aid of pen and paper but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A, Prong Two: This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements:
initialize a build orchestrator configured to;
a build orchestrator.
The additional elements (1) and (2) are recited at a high-level of generality such that they amount to no more than mere instructions to apply the judicial exception using generic computer components. The build orchestrator is used as a tool to perform the monitoring, receiving, and selecting steps of the claim. See MPEP § 2106.05(f).
Also, the claim recites the additional element:
receive an event indicating a hardware change in a modular hardware system.
The additional element (3) is mere data gathering recited at a high level of generality, and thus is insignificant extra-solution activity. See MPEP § 2106.05(g). Furthermore, all uses of the recited judicial exception require such data gathering, and, as such, the additional element does not impose any meaningful limits on the claim. The additional element amounts to necessary data gathering. See MPEP § 2106.05.
Also, the claim recites the additional element:
assemble the selected firmware components into the customized firmware image tailored to the identified hardware change.
The additional element (4) fails to meaningfully limit the claim because it does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. See MPEP § 2106.05(f). The additional element recites only the idea of assembling the selected firmware components into the customized firmware image without details on how this is accomplished. The claim omits any details as to how the assembling of the selected firmware components solves a technical problem, and instead recites only the idea of a solution or outcome. Therefore, the additional element attempts to cover any solution to the identified problem of assembling the selected firmware components into the customized firmware image with no restriction on how the assembling is accomplished and no description of the mechanism for accomplishing the assembling, and does not integrate a judicial exception into a practical application because this type of recitation is equivalent to the words “apply it.”
Accordingly, even when viewed in combination, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as a combination do not amount to significantly more than the abstract idea. As discussed above with respect to integration of the abstract idea into a practical application, the claim recites the additional elements:
initialize a build orchestrator configured to;
a build orchestrator.
The additional elements (1) and (2) amount to no more than mere instructions to apply the judicial exception using generic computer components. Mere instructions to apply a judicial exception using generic computer components cannot provide an inventive concept.
Also, the claim recites the additional element:
receive an event indicating a hardware change in a modular hardware system.
The additional element (3) simply appends well-understood, routine, and conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception is not indicative of an inventive concept. MPEP § 2106.05(d)(II) expressly states that the courts have recognized the computer function of receiving or transmitting data over a network, e.g., using the Internet to gather data as a well‐understood, routine, and conventional computer function when it is claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activities. Thus, a person of ordinary skill in the art would readily comprehend that it is well-understood, routine, and conventional in the computing art to receive an event indicating a hardware change in a modular hardware system. Therefore, the limitation remains insignificant extra-solution activity even upon reconsideration and does not amount to significantly more.
Also, the claim recites the additional element:
assemble the selected firmware components into the customized firmware image tailored to the identified hardware change.
The additional element (4) does not require any particular application of the judicial exception and is, at best, the equivalent of merely adding the words “apply it” (or an equivalent) to the judicial exception. The analysis under Step 2A, Prong Two is carried through to Step 2B. Therefore, the additional element attempts to cover any solution to the identified problem of assembling the selected firmware components into the customized firmware image with no restriction on how the assembling is accomplished and no description of the mechanism for accomplishing the assembling, and does not provide significantly more because this type of recitation is equivalent to the words “apply it.”
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements as a combination adds nothing that is not already present when looking at the additional elements taken individually. Even when considered in combination, the additional elements represent mere instructions to apply a judicial exception using generic computer components, insignificant extra-solution activities, and only the idea of a solution or outcome, and therefore do not provide an inventive concept. The claim is not patent eligible.
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.
Claims 1, 9, 15, 17, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 7,590,835 (hereinafter “Nallagatla”) in view of US 2024/0385866 (hereinafter “Peterson”) and US 2017/0300690 (hereinafter “Ladnai”).
As per Claim 1, Nallagatla discloses:
A method of building a customized firmware image (abstract, “Methods, systems, apparatus, and computer-readable media for customizing a computer system firmware image utilizing a firmware configuration data structure (emphasis added).”), comprising:
a modular hardware system (col. 1 lines 34-40, “The OEM may add, remove, or interchange hardware components to and from the reference board according to desired hardware configurations. As various hardware components are added or removed from a computer system motherboard, the firmware image must be updated to reflect the configuration change in order for the modified chipset configuration to properly function (emphasis added).”) [Examiner’s Remarks: Note that Nallagatla discloses updating firmware in response to configuration changes such as hardware components on a reference board or motherboard being added, removed, or interchanged (modular hardware components). One of ordinary skill in the art would readily comprehend that these hardware changes are within a modular hardware system.];
selecting […] appropriate firmware components for the identified hardware change (col. 8 lines 66-67 to col. 9 lines 1-6, “It should be appreciated that the data structure is targeted [selected] according to the desired firmware modifications. If a party changes a component on the reference board [identified hardware change], then corresponding changes must be made to the computer system firmware image 144. The party may manually select the firmware configuration data structures [firmware components] 208A-208C to modify, or the applicable data structures may be selected by an application 142 programmed with this information (emphasis added).”); and
assembling the selected firmware components into the customized firmware image tailored to the identified hardware change (col. 7 lines 7-8, “These firmware configuration data structures [selected firmware components] 208A-208C may be built [assembled] into separate sections of firmware image 144 […] (emphasis added).”; col. 8 lines 66-67 to col. 9 lines 1-3, “It should be appreciated that the [firmware configuration] data structure is targeted according to the desired firmware modifications. If a party changes a component on the reference board [identified hardware change], then corresponding changes must be made to the computer system firmware image 144 (emphasis added).”; abstract, “Methods, systems, apparatus, and computer-readable media for customizing a computer system firmware image utilizing a firmware configuration data structure (emphasis added).”).
Nallagatla discloses “selecting […] appropriate firmware components for the identified hardware change,” but does not explicitly disclose:
initializing a build orchestrator configured to monitor system events from different server systems;
selecting, by the build orchestrator.
However, Peterson discloses:
initializing a build orchestrator configured to monitor system events from different server systems (paragraph [0062], “An “Orchestrator” is intended to refer to a service or system that initiates tasks involved in bootstrapping one or more services during a region build […] An orchestrator may track relevant events (e.g., indicated through capabilities and/or skills as described herein) for each service of the region build and takes actions in response to those events […] (emphasis added).”; paragraph [0059], “A “capability” identifies is a resource used during region build that signals that another resource, service, or feature is available [system event], or that an event has occurred. By way of example, a capability can be published indicating that a resource is available for authorization/authentication processing (e.g., a subset of the functionality to be provided by a service) (emphasis added).”; paragraph [0041], “Embodiments of the present disclosure relate to techniques for performing an automated region build (e.g., bootstrapping (e.g., provisioning and/or deploying) resources (e.g., infrastructure component [server system], artifacts, etc.) for any suitable number of services within a region (e.g., a geographical location associated with one or more data centers)) (emphasis added).”) [Examiner’s Remarks: Note that Peterson discloses that resources include infrastructure components (server systems) and that an automated region build includes bootstrapping resources for multiple services (different server systems) within a region. Peterson also discloses a (build) orchestrator that initiates bootstrapping tasks during a region build and tracking relevant events indicated through capabilities for each service where the capabilities signal whether a resource is available. One of ordinary skill in the art would readily comprehend that the capabilities may represent system events regarding resource availability and that the build orchestrator must be initialized and configured to monitor these system events in order to track relevant events of each service (different server systems) of the region build.];
selecting, by the build orchestrator (paragraph [0044], “These features, provided by Puffin, enable the orchestrator to use [select] any suitable combination of skills and/or capabilities to drive orchestration during a region build (e.g., during a process for building a data center) (emphasis added).”).
Nallagatla is within the same field of endeavor as the claimed invention regarding the customization of firmware images. Peterson is also within the same field of endeavor as the claimed invention regarding the use of a build orchestrator to drive orchestration.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Peterson into the teaching of Nallagatla to include “initializing a build orchestrator configured to monitor system events from different server systems; selecting, by the build orchestrator.” The modification would be obvious because one of ordinary skill in the art would be motivated to drive orchestration using a build orchestrator that utilizes Puffin (a skills service that may be used to generate a “blueprint for build-time and run-time dependencies”) to “remove operational overhead, improve information accuracy, surface critical data including the ability to present interconnected service skills dependencies in a visual graph” (Peterson, paragraphs [0043 & 0045]).
The combination of Nallagatla and Peterson discloses “receiving, at the build orchestrator (Peterson, paragraph [0080], “In some embodiments, Orchestrator 106 may be configured to monitor (or be otherwise notified of) changes to the region data managed by Real-time Regional Data Distributor 104. In some embodiments, receiving an indication that region data has been changed may cause a region build to be triggered by Orchestrator 106 (emphasis added).”)” and “a modular system,” but does not explicitly disclose:
receiving, at the build orchestrator, an event indicating a hardware change in a modular hardware system.
However, Ladnai discloses:
receiving […] an event indicating a hardware change in a hardware system (paragraph [0007], “Detecting the security event may include detecting a hardware change (emphasis added).”; paragraph [0095], “A security product 332 may execute on the endpoint 310 to detect a security event on the endpoint 310, which may act as the beacon or trigger event for the system 300.”) [Examiner’s Remarks: Note that Ladnai discloses a security product detecting a security event and that detecting a security event can include detecting a hardware change. One of ordinary skill in the art would readily comprehend that detecting a security event (hardware change) requires the security product to receive the event and that a hardware change is a change made within a hardware system.].
Ladnai is within the same field of endeavor as the claimed invention regarding the detection of a hardware change event.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ladnai into the combined teachings of Nallagatla and Peterson to include “receiving, at the build orchestrator, an event indicating a hardware change in a modular hardware system.” The modification would be obvious because one of ordinary skill in the art would be motivated to receive/detect events indicating hardware changes and other security events used to generate an event graph representing the sequence of events/computer objects associated with the detected security event to “obtain a useful snapshot of events optimized for root cause analytics” (Ladnai, paragraphs [0121 & 0122]).
As per Claim 9, the rejection of Claim 1 is incorporated; and Nallagatla further discloses:
wherein the hardware change pertains to one or more of: a host processor module (HPM), a baseboard management controller (BMC), a device configuration (col. 1 lines 36-40, “As various hardware components are added or removed [hardware change] from a computer system motherboard [device], the firmware image must be updated to reflect the configuration change [device configuration change] in order for the modified chipset configuration to properly function (emphasis added).”).
As per Claim 15, the rejection of Claim 1 is incorporated; and Nallagatla discloses “the assembly of the customized firmware image in response to changes detected in device configurations within the modular hardware system (abstract, “Methods, systems, apparatus, and computer-readable media for customizing a computer system firmware image utilizing a firmware configuration data structure (emphasis added).”; col. 8 lines 66-67 to col. 9 lines 1-5, “It should be appreciated that the data structure is targeted according to the desired firmware modifications. If a party changes a component on the reference board [device configuration change], then corresponding changes must be made to the computer system firmware image 144. The party may manually select the firmware configuration data structures 208A-208C to modify […] (emphasis added).”; col. 7 lines 7-8, “These firmware configuration data structures [firmware components] 208A-208C may be built [assembled] into separate sections of firmware image 144 […] (emphasis added).”; col. 1 lines 34-36, “The OEM may add, remove, or interchange hardware components to and from the reference board according to desired hardware configurations [device configuration change within modular hardware system] (emphasis added).”),” but the combination of Nallagatla and Ladnai does not explicitly disclose:
triggering the build orchestrator to initiate the assembly of the customized firmware image in response to changes detected in device configurations within the modular hardware system.
However, Peterson discloses:
triggering the build orchestrator to initiate a region build (paragraph [0080], “In some embodiments, receiving an indication that region data has been changed may cause a region build to be triggered [initiated] by Orchestrator 106 (emphasis added).”; paragraph [0113], “At step 6, detecting the change in region data may trigger Orchestrator 310 to obtain a version set […] identifying a particular version for each flock config and a particular version for each artifact to be used to build the region (emphasis added).”; paragraph [0068], ““[…] an Orchestrator (e.g., a multi-flock orchestrator, also described in further detail below) configured to initiate/manage region builds […] (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Peterson into the combined teachings of Nallagatla and Ladnai to include “triggering the build orchestrator to initiate the assembly of the customized firmware image in response to changes detected in device configurations within the modular hardware system.” The modification would be obvious because one of ordinary skill in the art would be motivated to drive orchestration using a build orchestrator that utilizes Puffin (a skills service that may be used to generate a “blueprint for build-time and run-time dependencies”) to “remove operational overhead, improve information accuracy, surface critical data including the ability to present interconnected service skills dependencies in a visual graph” (Peterson, paragraphs [0043 & 0045]).
As per Claim 17, the rejection of Claim 1 is incorporated; and Nallagatla further discloses:
wherein the hardware change includes a swap or upgrade of a compute unit within the modular hardware system, necessitating the reconfiguration of the firmware to accommodate the updated hardware specifications (col. 1 lines 34-40, “The OEM may add, remove, or interchange [swap] hardware components to and from the reference board according to desired hardware configurations. As various hardware components are added or removed from a computer system motherboard, the firmware image must be updated to reflect the configuration change [updated hardware specification] in order for the modified chipset configuration to properly function (emphasis added).”; col. 4 lines 13-17 to lines 19-21, “In order to provide the functionality described herein, the computer 100 includes a baseboard, or "motherboard", which is a printed circuit board to which a multitude of components or devices may be connected by way of a system bus or other electrical communication path […] The CPU 102 is a standard central processor that performs arithmetic and logical operations necessary for the operation of the computer (emphasis added).”; col. 9 lines 1-6, “If a party changes a component on the reference board, then corresponding changes [reconfiguration] must be made to the computer system firmware image 144. The party may manually select the firmware configuration data structures 208A-208C to modify, or the applicable data structures may be selected by an application 142 programmed with this information (emphasis added).”) [Examiner’s Remarks: Note that Nallagatla discloses that the firmware must be updated when a hardware change occurs to ensure the chipset configuration properly functions which means the firmware must be reconfigured to accommodate the hardware change/modified chipset configuration (updated hardware specifications). Nallagatla also discloses interchanging (swapping) hardware components on a reference board and that a CPU (compute unit) is within the computer. One of ordinary skill in the art would readily comprehend that a CPU can be a component within the reference board or motherboard that may be swapped within the modular hardware system ultimately requiring reconfiguration of the firmware to accommodate the updated hardware specification.].
Claim 18 is an apparatus claim corresponding to method Claim 1 and is rejected for the same reasons as given in the rejection of that claim.
Claim 20 is a computer-readable medium claim corresponding to method Claim 1 and is rejected for the same reasons as given in the rejection of that claim.
Claims 2, 7, 8, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Nallagatla in view of Peterson and Ladnai as applied to Claims 1 and 18 above, and further in view of US 10,346,187 (hereinafter “Trier”).
As per Claim 2, the rejection of Claim 1 is incorporated; and Nallagatla discloses “the customized firmware image,” but the combination of Nallagatla, Peterson, and Ladnai does not explicitly disclose:
wherein the customized firmware image is a baseboard management controller (BMC) firmware image or a boot firmware image.
However, Trier discloses:
wherein the new firmware image is a baseboard management controller (BMC) firmware image or a boot firmware image (col. 11 lines 59-62, “When power is supplied to the BMC 600, the BMC 600 can access a storage location of the BMC firmware image storing boot instructions for the first BMC firmware 612 (emphasis added).”; col. 8 lines 65-67 to col. 9 line 1, “In at least one embodiment, the update can comprise a new firmware image that comprises an updated version of the first virtualized BMC firmware and a current version of a second virtualized BMC firmware (emphasis added).”).
Trier is within the same field of endeavor as the claimed invention regarding updating BMC firmware.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Trier into the combined teachings of Nallagatla, Peterson, and Ladnai to include “wherein the customized firmware image is a baseboard management controller (BMC) firmware image or a boot firmware image.” The modification would be obvious because one of ordinary skill in the art would be motivated to enable “multiple virtualized BMC firmware instances to be executed in a single BMC” to solve the problems associated with deploying updated firmware images by overwriting the previous firmware image such as difficulty testing new features and significantly increased development time when replacing a small number of BMC features (Trier, col. 1 line 66 to col. 2 lines 1-11 & col. 2 lines 13-16).
As per Claim 7, the rejection of Claim 1 is incorporated; and Nallagatla discloses “the customized firmware image” and “the modular hardware system,” but the combination of Nallagatla, Peterson, and Ladnai does not explicitly disclose:
transmitting the customized firmware image to the modular hardware system.
However, Trier discloses:
transmitting the firmware image to memory and/or storage that can be accessed by a BMC (col. 12 lines 17-23, “A firmware image comprising instructions for running an operating system kernel, both the BMC firmware instances, and the virtualization controller 626 can be deployed to the memory and/or storage that can be accessed by the BMC. In at least one embodiment, the deployed firmware image overwrites the previous image of the first BMC firmware 612 (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Trier into the combined teachings of Nallagatla, Peterson, and Ladnai to include “transmitting the customized firmware image to the modular hardware system.” The modification would be obvious because one of ordinary skill in the art would be motivated to enable “multiple virtualized BMC firmware instances to be executed in a single BMC” to solve the problems associated with deploying updated firmware images by overwriting the previous firmware image such as difficulty testing new features and significantly increased development time when replacing a small number of BMC features (Trier, col. 1 line 66 to col. 2 lines 1-11 & col. 2 lines 13-16).
As per Claim 8, the rejection of Claim 7 is incorporated; and Nallagatla discloses “the customized firmware image” and “the modular hardware system,” but the combination of Nallagatla, Peterson, and Ladnai does not explicitly disclose:
updating a pre-existing firmware image in the modular hardware system using the customized firmware image.
However, Trier discloses:
updating a pre-existing firmware image in the virtualized BMC firmware using the new firmware image (col. 9 lines 14-22, “At 404, the update is applied to the first virtualized BMC firmware. In an embodiment where the update comprises a new firmware image that comprises an updated version of the first virtualized BMC firmware and a current version of the second virtualized BMC firmware, the update can be applied by overwriting a current firmware image for the BMC with the new firmware image contained within the update, and rebooting the BMC to load the new firmware image (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Trier into the combined teachings of Nallagatla, Peterson, and Ladnai to include “updating a pre-existing firmware image in the modular hardware system using the customized firmware image.” The modification would be obvious because one of ordinary skill in the art would be motivated to enable “multiple virtualized BMC firmware instances to be executed in a single BMC” to solve the problems associated with deploying updated firmware images by overwriting the previous firmware image such as difficulty testing new features and significantly increased development time when replacing a small number of BMC features (Trier, col. 1 line 66 to col. 2 lines 1-11 & col. 2 lines 13-16).
Claim 19 is an apparatus claim corresponding to method Claim 2 and is rejected for the same reasons as given in the rejection of that claim.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Nallagatla in view of Peterson and Ladnai as applied to Claim 1 above, and further in view of US 2013/0346800 (hereinafter “Gulati”).
As per Claim 3, the rejection of Claim 1 is incorporated; and the combination of Nallagatla, Peterson, and Ladnai discloses “the modular hardware system” and “modular firmware components (Nallagatla, col. 8 lines 66-67 to col. 9 lines 1-6, “It should be appreciated that the data structure is targeted according to the desired firmware modifications. If a party changes a component on the reference board, then corresponding changes must be made to the computer system firmware image 144. The party may manually select the firmware configuration data structures [modular firmware components] 208A-208C to modify, or the applicable data structures may be selected by an application 142 programmed with this information (emphasis added).”; col. 7 lines 7-8, “These firmware configuration data structures [modular firmware components] 208A-208C may be built into separate sections of firmware image 144 […] (emphasis added).”)” and “identifying a target platform based on the hardware change (Ladnai, paragraph [0007], “Detecting the security event may include detecting a hardware change (emphasis added).”; paragraph [0127], “As shown in step 412, the method 400 may include, in response to detecting the security event [hardware change], traversing the event graph based on the sequence of events in a reverse order from the one of the computing objects associated with the security event to one or more preceding ones of the computing objects. […] [T]he reverse order will follow this flow or causal link from the receiving computing object backward toward the source computing object [target platform] (emphasis added).”; paragraph [0128], “For example, the method 400 may include applying a cause identification rule to the preceding ones of the computing objects and the causal relationships while traversing the event graph in order to identify one of the computing objects [target platform] as a cause of the security event [hardware change] (emphasis added).”; paragraph [0146], “The computing objects may in general be any hardware or software computing object such as a data file, a database record, a database, a directory, a file system, a file system path, a process, an application, an operating system, […] and so forth (emphasis added).”),” but does not explicitly disclose:
determining a system-on-a-chip (SOC) module associated with the modular hardware system; and
selecting modular firmware components corresponding to the identified target platform and SOC module.
However, Gulati discloses:
determining a system-on-a-chip (SOC) module associated with the hardware system (abstract, “The SOC also includes an SOC debug control unit [SOC module], which is coupled to receive detected debug events from the components (emphasis added).”; paragraph [0018], “FIG. 10 is a block diagram of one embodiment of a system [hardware system] including the SOC shown in FIG. 1 (emphasis added).”; paragraph [0059], “In other embodiments, the system 150 may be any type of computing system (e.g. desktop personal computer, laptop, workstation, net top etc.) (emphasis added).”); and
selecting components corresponding to the identified events and SOC module (paragraph [0006], “The local debug control units may be programmable to enable events to be detected, and may transmit the detected events to the SOC debug control unit. The SOC debug control unit [SOC module] may be programmable to detect one or more events from one or more components, and may halt the components of the SOC responsive to detecting the selected events (emphasis added).”) [Examiner’s Remarks: Note that Gulati discloses halting the components of the SOC responsive to detecting the selected events (identified events). One of ordinary skill in the art would readily comprehend that halting the components includes selecting the components to be halted corresponding to the identified events and SOC module (SOC debug control unit)].
Gulati is within the same field of endeavor as the claimed invention regarding the use of system-on-a-chip (SOC) modules.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Gulati into the combined teachings of Nallagatla, Peterson, and Ladnai to include “determining a system-on-a-chip (SOC) module associated with the modular hardware system; and selecting modular firmware components corresponding to the identified target platform and SOC module.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize an SOC module to detect events and halt certain SOC components to have “enhanced visibility and control of the system” when debugging the SOC (Gulati, paragraph [0006]).
Claims 5, 6, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Nallagatla in view of Peterson, and Ladnai as applied to Claim 1 above, and further in view of Mastering Embedded Linux Programming (hereinafter “Vasquez”).
As per Claim 5, the rejection of Claim 1 is incorporated; and the combination of Nallagatla, Peterson, and Ladnai discloses “wherein assembling the selected firmware components comprises configuring the components (Nallagatla, col. 7 lines 7-8, “These firmware configuration data structures [firmware components] 208A-208C may be built [assembled] into separate sections of firmware image 144 […] (emphasis added).”; col. 8 lines 66-67 to col. 9 lines 1-6, “It should be appreciated that the data structure is targeted [selected] according to the desired firmware modifications. If a party changes a component on the reference board, then corresponding changes must be made to the computer system firmware image 144. The party may manually select the firmware configuration data structures [firmware components] 208A-208C to modify, or the applicable data structures may be selected by an application 142 programmed with this information (emphasis added).”; col. 9 lines 46-49, “If a modification was received, then the routine 400 continues to operation 418, where the modification is saved in the firmware configuration data structure 208, replacing the original entry (emphasis added).”) using a build orchestration system (Peterson, paragraph [0056], “A “Cloud Infrastructure Orchestration Service” (CIOS) may refer to a system configured to manage provisioning and deployment operations for any suitable number of services as part of a region build (emphasis added).”; paragraph [0069], “The high-level responsibilities of CIOS include, but are not limited to, coordinating region builds in an automated fashion with minimal human intervention […] (emphasis added).”),” but does not explicitly disclose:
implementing an open source build framework.
However, Vasquez discloses:
implementing an open source build framework (Chapter 6 page 149 lines 15-16, “Now, let's learn how to install the Yocto Project [open source build framework] (emphasis added).”; Preface page 16 lines 3-11, “Developing with Yocto, demonstrates how to build system images on top of an existing BSP layer, develop onboard software packages with Yocto's extensible SDK, and roll your own embedded Linux distribution complete with runtime package management (emphasis added).”).
Vasquez is within the same field of endeavor as the claimed invention regarding the utilization of an open source build framework.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Vasquez into the combined teachings of Nallagatla, Peterson, and Ladnai to include “implementing an open source build framework.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize the Yocto framework to take advantage of “complex built-in peripherals” by building on top of existing Board Support Package layers (which specifies the bootloader and kernel necessary for the hardware to operate) and avoid the “painstaking process” of bringing up Linux on unsupported hardware (Vasquez, Chapter 7 page 184 lines 4-8 to lines 13-17 & Chapter 8 page 277 lines 32-34 to page 278 line 1).
As per Claim 6, the rejection of Claim 5 is incorporated; and Nallagatla discloses “to facilitate construction of the customized firmware image (abstract, “Methods, systems, apparatus, and computer-readable media for customizing a computer system firmware image utilizing a firmware configuration data structure (emphasis added).”; col. 7 lines 7-8, “These firmware configuration data structures 208A-208C may be built into separate sections of [customized] firmware image 144 […] (emphasis added).”; col. 8 lines 66-67 to col. 9 lines 1-6, “It should be appreciated that the data structure is targeted according to the desired firmware modifications. If a party changes a component on the reference board, then corresponding changes must be made to the computer system firmware image 144. The party may manually select the firmware configuration data structures 208A-208C to modify, or the applicable data structures may be selected by an application 142 programmed with this information (emphasis added).”),” but the combination of Nallagatla, Peterson, and Ladnai does not explicitly disclose:
wherein the open source build framework includes a build orchestrator, a build engine, and a package manager.
However, Vasquez discloses:
wherein the open source build framework includes a build orchestrator, a build engine, and a package manager (Chapter 6 page 143 lines 5-9, “The Yocto Project includes a task scheduler [build orchestrator] called BitBake that produces whatever you have configured, from the recipes (emphasis added).”; Chapter 6 page 164 lines 14-18, “You use BitBake to execute these tasks. The default task is do_build, which performs all the subtasks required to build the recipe (emphasis added).”; Chapter 6 page 152 lines 14-17, “To actually perform the build, you need to run BitBake [build engine], telling it which root filesystem image you want to create (emphasis added).”; Chapter 7 page 248 lines 9-12, “Yocto has support for different package formats (rpm and ipk) and different package managers (dnf and opkg) (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Vasquez into the combined teachings of Nallagatla, Peterson, and Ladnai to include “wherein the open source build framework includes a build orchestrator, a build engine, and a package manager.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize the Yocto framework to take advantage of “complex built-in peripherals” by building on top of existing Board Support Package layers (which specifies the bootloader and kernel necessary for the hardware to operate) and avoid the “painstaking process” of bringing up Linux on unsupported hardware (Vasquez, Chapter 7 page 184 lines 4-8 to lines 13-17 & Chapter 8 page 277 lines 32-34 to page 278 line 1).
As per Claim 16, the rejection of Claim 1 is incorporated; and the combination of Nallagatla, Peterson, and Ladnai discloses “wherein the build orchestrator is configured to (Peterson, paragraph [0062], “An “Orchestrator” is intended to refer to a service or system that initiates tasks involved in bootstrapping one or more services during a region build […] An orchestrator may track relevant events […] (emphasis added).”) build the customized firmware image […] according to the identified hardware change (Nallagatla, abstract, “Methods, systems, apparatus, and computer-readable media for customizing a computer system firmware image utilizing a firmware configuration data structure (emphasis added).”; col. 7 lines 7-8, “These firmware configuration data structures 208A-208C may be built into separate sections of [customized] firmware image 144 […] (emphasis added).”; col. 8 lines 66-67 to col. 9 lines 1-6, “It should be appreciated that the data structure is targeted according to the desired firmware modifications. If a party changes a component on the reference board [identified hardware change], then corresponding changes must be made to the computer system firmware image 144. The party may manually select the firmware configuration data structures 208A-208C to modify, or the applicable data structures may be selected by an application 142 programmed with this information (emphasis added).”),” but does not explicitly disclose:
by injecting appropriate meta-layers into a build process.
However, Vasquez discloses:
by injecting appropriate meta-layers into a build process (Chapter 6 page 156 lines 10-14, “The metadata for the Yocto Project is structured into layers [meta-layers]. By convention, each layer has a name beginning with meta (emphasis added).”; Chapter 6 page 157 lines 6-10 to lines 28-31, “By structuring the recipes and other configuration data in this way, it is very easy to extend the Yocto Project by adding [injecting] new layers […] Adding a layer is as simple as copying the meta directory to a suitable location [injecting an appropriate meta-layer] and adding it to bblayers.conf [build configuration file] (emphasis added).”; Chapter 6 page 164 lines 1-6, “Configuration: Files ending in .conf. They define various configuration variables that govern the project's build process (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Vasquez into the combined teachings of Nallagatla, Peterson, and Ladnai to include “by injecting appropriate meta-layers into a build process.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize the Yocto framework to take advantage of “complex built-in peripherals” by building on top of existing Board Support Package layers (which specifies the bootloader and kernel necessary for the hardware to operate) and avoid the “painstaking process” of bringing up Linux on unsupported hardware (Vasquez, Chapter 7 page 184 lines 4-8 to lines 13-17 & Chapter 8 page 277 lines 32-34 to page 278 line 1).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Nallagatla in view of Peterson, Ladnai, and Gulati as applied to Claim 3 above, and further in view of Vasquez and US 2007/0152058 (hereinafter “Yeakley”).
As per Claim 4, the rejection of Claim 3 is incorporated; and Nallagatla discloses “wherein the modular firmware components are selected from a group (col. 8 lines 66-67 to col. 9 lines 1-6, “It should be appreciated that the data structure is targeted according to the desired firmware modifications. If a party changes a component on the reference board, then corresponding changes must be made to the computer system firmware image 144. The party may manually select the firmware configuration data structures [selecting modular firmware components from a group of firmware data structures] 208A-208C to modify, or the applicable data structures may be selected by an application 142 programmed with this information (emphasis added).”),” but the combination of Nallagatla, Peterson, Ladnai, and Gulati does not explicitly disclose:
a group comprising Linux kernel, U-Boot bootloader, root filesystem, and platform configuration capsules.
However, Vasquez discloses:
a group comprising Linux kernel, U-Boot bootloader, and root filesystem (Chapter 10 page 328 lines 13-20, “Embedded Linux devices are very diverse in their design and implementation. However, they all have these basic components: [Bootloader, Kernel, Root filesystem] […] (emphasis added).”; Chapter 10 page 330 lines 1-4, “The Linux kernel is a critical component that will certainly need updating from time to time (emphasis added).”; Chapter 3 page 27 lines 22-25, “I will look at the popular open source bootloader known as U-Boot and show you how to use it to boot a target device […] (emphasis added).”; Chapter 6 page 142 lines 21-26, “The Yocto Project is a more complex beast than Buildroot. Not only can it build toolchains, bootloaders, kernels, and root filesystems as Buildroot can […] (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Vasquez into the combined teachings of Nallagatla, Peterson, Ladnai, and Gulati to include “a group comprising Linux kernel, U-Boot bootloader, and root filesystem.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize the Yocto framework to take advantage of “complex built-in peripherals” by building on top of existing Board Support Package layers (which specifies the bootloader and kernel necessary for the hardware to operate) and avoid the “painstaking process” of bringing up Linux on unsupported hardware (Vasquez, Chapter 7 page 184 lines 4-8 to lines 13-17 & Chapter 8 page 277 lines 32-34 to page 278 line 1).
However, Yeakley discloses:
platform configuration capsules (paragraph [0062], “Packaging module 5008 can package data from e.g., configuration files [platform configuration capsules] 5082, selected commands 5084 and files 5086 (emphasis added).”; paragraph [0134], “Referring to FIG. 8e […] When file DEVICECONFIG.EXM [platform configuration capsule] is selected, package status window 7030 indicates that file DEVICECONFIG.EXM is part of the package (emphasis added).”; paragraph [0058], “In utilizing a configuration file to reconfigure a subsystem of data collection terminal 10 data collection terminal 10 can utilize the configuration file to reconfigure a device of data collection terminal 10 such as a bar code reader device 14 or a radio transceiver device 62 or another device (emphasis added).”) [Examiner’s Remarks: Note that Yeakley discloses packaging data from configuration files and that the configuration file can be used to reconfigure a device. One of ordinary skill in the art would readily comprehend that the device is a platform and the configuration files/packaged data that include device configuration data are platform configuration capsules.].
Yeakley is within the same field of endeavor as the claimed invention regarding the utilization of platform configuration files for device configuration.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Yeakley into the combined teachings of Nallagatla, Peterson, Ladnai, Gulati, and Vasquez to include “platform configuration capsules.” The modification would be obvious because one of ordinary skill in the art would be motivated to utilize platform configuration files in an XML file format that “provides significant advantages in the process of reconfiguring devices” through its multi-tiered hierarchy, well-adapted use for updating parameter settings of a Registry, and using a different file extension (EXM instead of XML) to process files differently (Yeakley, paragraph [0075 & 0110]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Nallagatla in view of Peterson, and Ladnai as applied to Claim 1 above, and further in view of US 2015/0052596 (hereinafter “Ayanam”).
As per Claim 10, the rejection of Claim 1 is incorporated; and Nallagatla discloses “the modular hardware system,” but the combination of Nallagatla, Peterson, and Ladnai does not explicitly disclose:
validating the customized firmware image on one or more test platforms prior to deploying to the modular hardware system.
However, Ayanam discloses:
validating the customized firmware image on one or more test platforms prior to deploying to the hardware system (Figure 9: 923, 924, 928, 929; paragraph [0011], “In certain embodiments, the configuration instruction is configured to instruct the firmware generator to at least one of: […] (d) build a firmware image by compiling and debugging module codes of selected features from a module code library, (e) test a customized firmware including manual and automatic testing, […] and (g) deploy the firmware image to a destination computer (emphasis added).”; paragraph [0257], “Once the Firmware1 is downloaded and installed on the destination computer 108, the first user can test the Firmware1 [customized firmware image] manually at the operations 922, or automatically at the operation 923 […] The test results are reported back to the web browser 1 109-1 at the operation 924 (emphasis added).”; paragraph [0258], “If the test uncovers any problems [validating the firmware image], the process 900 goes back at the operation 925 to modify the Firmware1 to operation 907. Otherwise, if there is no problem with the build, the first user can finalized the Firmware1 at the operation 926 […] (emphasis added).”; paragraph [0259], “Once the Firmware1 build is finalized, and built, the […] Firmware1 can also be deployed to the destination computer 108 at the operation 929 (emphasis added).”).
Ayanam is within the same field of endeavor as the claimed invention regarding the construction and testing of customized firmware.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ayanam into the combined teachings of Nallagatla, Peterson, and Ladnai to include “validating the customized firmware image on one or more test platforms prior to deploying to the modular hardware system.” The modification would be obvious because one of ordinary skill in the art would be motivated to test the firmware images to “uncover any problems,” and modify the firmware if any are found, to ensure only validated and error-free firmware is deployed (Ayanam, paragraph [0258]).
Claims 11 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Nallagatla in view of Peterson, and Ladnai as applied to Claim 1 above, and further in view of US 2020/0044928 (hereinafter “Devireddy”).
As per Claim 11, the rejection of Claim 1 is incorporated; and Nallagatla discloses “the assembly of the customized firmware image,” but the combination of Nallagatla, Peterson, and Ladnai does not explicitly disclose:
dynamically fetching platform-specific configuration files during the assembly of the customized firmware image.
However, Devireddy discloses:
dynamically fetching platform-specific configuration files during the configuration of a gateway (abstract, “Provided is a method for configuring a gateway (emphasis added).”; paragraph [0020], “The current version data may be associated with a current version of a configuration file for a gateway [platform-specific configuration file] (emphasis added).”; paragraph [0084], “For example, non-limiting embodiments or aspects of the disclosed subject matter provide configuring a gateway with a configuration service to retrieve current configuration files in response to determining current version data stored on a remote server has been modified. Such embodiments or aspects provide techniques and systems for dynamic updating/retrieval of the configuration file(s) without the need to build and/or deploy the entire application package to (each node of) the gateway (emphasis added).”).
Devireddy is within the same field of endeavor as the claimed invention regarding the dynamic retrieval of configuration files.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Devireddy into the combined teachings of Nallagatla, Peterson, and Ladnai to include “dynamically fetching platform-specific configuration files during the assembly of the customized firmware image.” The modification would be obvious because one of ordinary skill in the art would be motivated to dynamically retrieve configuration files including “simultaneous and/or parallel” retrieval, so the gateway may identify and retrieve the file “using less computing resources and with less delay (e.g., compared to uploading the entire application package to each node of the gateway individually)” (Devireddy, paragraph [0084]).
As per Claim 13, the rejection of Claim 1 is incorporated; and the combination of Nallagatla, Peterson, and Ladnai discloses the “the build orchestrator” and “the selection and assembly of firmware components for the customized firmware image based on the identified hardware change,” but does not explicitly disclose:
using a configuration file to instruct the build orchestrator on the selection and assembly of firmware components for the customized firmware image based on the identified hardware change.
However, Devireddy discloses:
using a configuration file to instruct a gateway node on applying validation rules to a transaction (paragraph [0117], “Additionally or alternatively, applying the configuration file may include the gateway node applying the validation rules, transformation rules, error code mapping, or any combination thereof, respectively, to a transaction received by the gateway node (emphasis added).”) [Examiner’s Remarks: Note that Devireddy discloses that applying a configuration file may include a gateway node applying validation rules to a transaction. One of ordinary skill in the art would readily comprehend that a configuration file is instructing the gateway node on applying validation rules to a transaction since the gateway node is applying the validation rules as a result of applying the configuration file.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Devireddy into the combined teachings of Nallagatla, Peterson, and Ladnai to include “using a configuration file to instruct the build orchestrator on the selection and assembly of firmware components for the customized firmware image based on the identified hardware change.” The modification would be obvious because one of ordinary skill in the art would be motivated to dynamically retrieve configuration files including “simultaneous and/or parallel” retrieval, so the gateway may identify and retrieve the file “using less computing resources and with less delay (e.g., compared to uploading the entire application package to each node of the gateway individually)” (Devireddy, paragraph [0084]).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Nallagatla in view of Peterson, Ladnai, and Devireddy as applied to Claim 11 above, and further in view of Ayanam.
As per Claim 12, the rejection of Claim 11 is incorporated; and the combination of Nallagatla, Peterson, Ladnai, and Devireddy discloses “platform-specific configuration files,” but does not explicitly disclose:
wherein the platform-specific configuration files include one or more of Sensor Data Record (SDR) information, platform event filter configurations, entity manager configurations, static tables for platform components, and power and thermal management algorithms.
However, Ayanam discloses:
wherein the IPMI functions include one or more of Sensor Data Record (SDR) information, platform event filter configurations, entity manager configurations, static tables for platform components, and power and thermal management algorithms (paragraphs [0066 & 0069], “In certain embodiments, the IPMI functions of the BMC firmware can include one or more of: […] System Interface, Event Log(SEL), Sensor Support, Detailed System Information such as SDR Repository, and FRU Information (emphasis added).”; paragraph [0079], “Automatic SDR records creation with no need of user manual input (emphasis added).”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ayanam into the combined teachings of Nallagatla, Peterson, Ladnai and Devireddy to include “wherein the platform-specific configuration files include one or more of Sensor Data Record (SDR) information, platform event filter configurations, entity manager configurations, static tables for platform components, and power and thermal management algorithms.” The modification would be obvious because one of ordinary skill in the art would be motivated to store and track sensor-related information by manually incorporating “a software routine containing information identifying the sensors and devices that are specified for [a] particular configuration” into BMC firmware as an improvement to OEMs unable to standardize BMC firmware during design and manufacturing processes due to different configuration preferences among customers (Ayanam, paragraphs [0004 & 0005]).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Nallagatla in view of Peterson, Ladnai, and Devireddy as applied to Claim 13 above, and further in view of Ayanam and US 2022/0066890 (hereinafter “Drury”).
As per Claim 14, the rejection of Claim 13 is incorporated; and the combination of Nallagatla, Peterson, Ladnai, and Devireddy does not explicitly disclose:
wherein the configuration file specifies general platform information, platform-specific repository metadata, metadata for the system-on-chip (SOC) specific to a baseboard management controller, and listings for compiling the firmware components.
However, Ayanam discloses:
wherein the configuration file specifies platform-specific repository metadata and listings for compiling the firmware components (Figure 6: 606; paragraph [0209], “The configuration execution module 114 retrieves the selected DDFs from the firmware configuration library 116 and compiles the selected DDFs 604 in a configuration file 606 that will ultimately be loaded into the firmware 608 of the BMC [listings for compiling the firmware components] 501 (emphasis added).”; paragraphs [0066 & 0069], “In certain embodiments, the IPMI functions of the BMC firmware can include one or more of: […] System Interface, Event Log(SEL), Sensor Support, Detailed System Information such as SDR Repository, and FRU Information [platform-specific repository metadata] (emphasis added).”; paragraph [0079], “Automatic SDR records creation with no need of user manual input (emphasis added).”; paragraph [0042], “For example, the BMC can connect to a component directly or by way of a management bus. In one embodiment, these components include sensor devices for measuring various operating and performance-related parameters within the computer system (emphasis added).”) [Examiner’s Remarks: Note that Ayanam discloses a configuration file that contains an IPMI file in Figure 6. Ayanam further discloses automatic SDR records creation, the BMC connecting to sensor devices configured to measure certain parameters within a computing system, and that IPMI functions of the BMC firmware can include SDR Repository and FRU information. As a result, the SDR repository information can be considered platform-specific to the BMC and computer system. One of ordinary skill in the art would readily comprehend that the automatic SDR records creation likely includes metadata such as timestamps and that the IPMI file within the configuration file may contain platform-specific repository information including metadata.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Ayanam into the combined teachings of Nallagatla, Peterson, Ladnai and Devireddy to include “wherein the configuration file specifies platform-specific repository metadata and listings for compiling the firmware components.” The modification would be obvious because one of ordinary skill in the art would be motivated to store and track sensor-related information by manually incorporating “a software routine containing information identifying the sensors and devices that are specified for [a] particular configuration” into BMC firmware as an improvement to OEMs unable to standardize BMC firmware during design and manufacturing processes due to different configuration preferences among customers (Ayanam, paragraphs [0004 & 0005]).
However, Drury discloses:
general platform information and metadata for the system-on-chip (SOC) specific to a baseboard management controller (paragraph [0036], “Operating environment 120 may include its own processor. The processor may be implemented as a System on a Chip (SoC) […] (emphasis added).”; paragraph [0034], “BMC 102 may include its own processor 114. Processor 114 may be implemented in any suitable manner, such as by a microprocessor, microcontroller, field-programmable gate array, or application-specific interface circuit (emphasis added).”; paragraph [0065], “Management server 132 may utilize status monitor 122 to maintain current configuration and performance information for a respective server 104 that is an active node […] The information may include data on SoC 126 hardware [SOC metadata], such as a number of cores, device identification, or clock speed […] The information may include operating software configuration such as application and operating system parameters [general platform information] (emphasis added).”) [Examiner’s Remarks: Note that Drury discloses a status monitor maintaining information that may include SOC metadata. Drury also discloses that the operating environment may include a processor implemented as a SOC as well as a BMC that may include its own processor implemented in any suitable manner. One of ordinary skill in the art would readily comprehend that the BMC may include a SOC as a processor and that the SOC metadata maintained by the status monitor may be specific to a BMC.].
Drury is within the same field of endeavor as the claimed invention regarding the use of system-on-a-chip (SOC) and BMCs.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Drury into the combined teachings of Nallagatla, Peterson, Ladnai, Devireddy, and Ayanam to include “general platform information and metadata for the system-on-chip (SOC) specific to a baseboard management controller.” The modification would be obvious because one of ordinary skill in the art would be motivated to collect general platform information and SOC metadata to define the “configuration of a given server” in order to identify a server as being in a “pre-failure state,” so that a management server can be utilized to take actions to mitigate the potential failure by selecting an appropriate node that would be able to support the needed configuration to replace the server (Drury, paragraphs [0066 & 0067]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
“A Study on the Packaging for Fast Boot-up Time in the Embedded Linux” (hereinafter “Chung”) discloses a group comprising Linux kernel, U-Boot bootloader, and root filesystem.
“Using Capsules for Firmware Configuration Update” (hereinafter “Bobroff”) discloses UEFI capsules for passing data between OS and firmware, the exchange of configuration data between OS and firmware through UEFI, and the abstraction of platform configuration data.
US 2021/0026711 (hereinafter “Ovadia”) discloses the Yocto framework (open-source build framework) and BitBake.
US 2022/0405092 (hereinafter “Miedema”) discloses a build system including Yocto and build orchestration tools.
US 10,114,637 (hereinafter “Willson”) discloses build configuration files instructing a project build module.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Feven Huruy whose telephone number is 571-272-3826. The examiner can normally be reached Mon-Fri. 7:30am-3:45pm.
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 Mui can be reached at 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.
/F.H.H./Examiner, Art Unit 2191
/WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191