DETAILED ACTION
This Office action is in response to the claim amendment and remarks filed on June 29, 2026.
Claims 1, 5, 8, 15 and 18 are amended. Claims 1-20 are pending in this application.
In view of claim amendments made, prior claim objections and rejection under 35 USC 112(b) are withdrawn.
Claim Rejections - 35 USC § 103
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as anticipated by Lambert et al. (USPN: 2022/0390517), hereinafter Lambert.
As per claims 1, Lambert teaches a target Information Handling System (IHS) (100 in Fig. 1), comprising: a Baseboard Management Controller (BMC) (132 in Figs. 1-2) that manages the operation of the IHS, the BMC comprising one or more processors (202 and 204 in Fig. 2) and one or more memory units (212 in Fig. 2) including instructions that, upon execution by the processors, cause the BMC to when a standard firmware stack (i.e. standard firmware set/developed by the vendor) is executed on the BMC, apply the standard/pre-set speed of the fans (i.e. in the standard firmware stack set by the factory/vendor, the fan speed is preset without any adjustment by any offset; see at least [0013]-[0014]).
Lambert further teaches applying a power loading offset value to adjust a speed of one or more fans when an openBMC-based firmware stack is executed (i.e. the custom BMC, such as openBMC firmware stack 220 is created by a user of the IHS 100 for out-of-band monitoring of the IHS (such as, (i) monitoring internal ambient temperatures and/or voltages in the IHS 100, and (ii) monitoring CPU, memory, and network usage levels), and management of the IHS (such as, (i) installation of software including the base operating system, (ii) controlling fan speed of one or more fans in the IHS of the various IHS components including, and (iii) turning certain resources of the IHS 100 on or off)). See [0034]. Note that running one or more fans at different speeds in the custom BMC firmware stack is considered here as applying power loading offset since fans need to run at speed different than standard speed pre-set by the factory/vendor as in standard BMC firmware stack.
As per claim 2, Lambert further teaches about applying one of a plurality of the power loading offset values based upon a current power load of the target HIS (i.e. a remote BMC test method that enables remote test procedures to be performed on BMCs that may execute error prone custom BMC firmware stacks; see [0014]).
As per claims 5 and 6, Lambert teaches the claimed target IHS as described above and furthermore, Lambert teaches that the power load offset value stored in a fan table is saved in a secure memory of the target IHS (i.e. the BMC memory 212 stores the custom BMC firmware stack 220. The custom BMC firmware stack controls the fan speed of one or more fans in the IHS 100; see [0014]).
As per claims 3-4 and 7, as described above, the combination of Lambert and Das teaches a target IHS, where under standard BMC firmware stack, the standard/pre-set fan speed applied; while under custom/openBMC based firmware stack, the fan speed is customized as the user sets it. As indicated above, the custom/various fan speeds set by user(s) are considered here as applying power loading offset since fans need to run at speed different than standard speed pre-set by the factory/vendor as in standard BMC firmware stack.
Examiner finds that setting those power loading offsets (i.e. custom fan speeds by user(s) in custom/openBMC based firmware stack) based on various ways (i.e. using a Standard Performance Evaluation Corporation (SPEC) standard minimum efficiency ratio, by averaging a power loading of a plurality of different IHS configurations, and by empirically measuring a test IHS at different load levels) is simply a matter of “design choice” for different way to test and prevent the damage to the HIS and the BMC hardware.
Claims 8-14 are method claims and substantially like claims 1-7, except are drawn to method claims. Claims 8-14 are also rejected for the same reasons as for claims 1-7.
Claims 15-20 are directed to a Baseboard Management Controller (BMC) and substantially like claims 1-2 and 4-7, respectively, except are drawn to BMC claims. Claims 15-20 are also rejected for the same reasons as for claims 1-2 and 4-7, respectively.
Response to Arguments
Applicant alleges that the mere act of “controlling” something by a BMC should not construed to mean that the BMC possesses the logic (i.e. intelligence) to selectively apply an offset value based upon whether an openBMC-based firmware stack or a standard firmware stack is being executed. Specifically, the Office Action asserts that running one or more fans at different speeds in the custom BMC firmware stack is considered here as applying power loading offset since fans need to run at speed different than standard speed pre-set by the factory/vendor as in standard BMC firmware stack. (Id). Applicant respectfully submits, however, that such an assertion is conclusory in that it is presumed that the fans need to run at different speeds when no such basis for actually doing so by Lambert has been expressly cited or implied by the Office Action. As such, Lambert cannot be construed to teach or suggest the emphasized features of amended claim 1 shown above. Pages 6-7 of Remarks.
Examiner disagrees with Applicant and maintains that a power loading offset value has to be applied in Lambert, when the custom/openBMC-based firmware stack is executed, to adjust the speed of fan(s). In order to run fan(s) at different speed, different power needs to be applied. If applicant believes different power is not required to run a fan at different speed, Examiner would like to request to Applicant to provide evidence(s) of such.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hetul Patel whose telephone number is (571)272-4184. The examiner can normally be reached M-F 9am-5pm.
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.
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.
/Hetul Patel/
Supervisory Patent Examiner
Art Unit 3992
Prosecution Insights