DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This office action is in response to communication filed on 9/10/2026.
The instant application having application No. 18/770,715 filed on July 12, 2024, presents claims 1-20 for examination, has no priority data.
Status of the Claims
Claims 1, 5, 7, 11, 13, and 17 have been amended, claims 1-20 are currently pending in the application.
Response to Amendment
(A). Regarding Objection to spec: Applicant's amendment to spec appropriately addressed the objection, the objection is withdrawn.
(B). Regarding Objection to claims: Applicant's amendment to claims appropriately addressed the objection, the objection is withdrawn.
(C). Regarding art rejection: In regard to pending claims Applicant’s arguments are not persuasive; further, Applicant's amendments necessitated new grounds of rejections presented in the following art rejection.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Objections
Claims 1-20 are objected to because of the following informalities:
Claim 1, last two lines, “…optimizing power efficiency operating system during a kernel mode of a runtime phase of operation.”, suggestion: -…optimizing power efficiency at operating system during a kernel mode of a runtime phase of operation.-.
Claims 7 and 13 have the same issue, and are objected to for the same reason.
Dependent claims 2-6, 8-12, and 14-20 are objected to for the same reason because they depend on their respective independent claim 1, 7, or 13.
Appropriate correction is required.
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 of this title, 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-3, 7-9, and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Opferman et al. (US 20190042258 A1, hereinafter “Opferman”) in view of Kumar et al. (US 20030005200 A1, hereinafter “Kumar”), Varma et al. (US 20160252943 A1, hereinafter “Varma”) and ASBE et al. (US 20250053659 A1, hereinafter “ASBE”).
With respect to claim 1 (Currently Amended), Opferman discloses A computer-implementable method for performing a firmware management operation, comprising:
identifying a processor environment installed on an information handling system from a plurality of processor environments, the processor environment comprising processor architecture, the processor architecture comprising a plurality of processor core types (e.g. Fig. 5, para [0059], “FIG. 5 is a block diagram of a processor 500 that may have more than one core, may have an integrated memory controller, and may have integrated graphics according to embodiments of the invention. The solid lined boxes in FIG. 5 illustrate a processor 500 with a single core 502A, a system agent 510, a set of one or more bus controller units 516, while the optional addition of the dashed lined boxes illustrates an alternative processor 500 with multiple cores 502A-N, …” also see para [0060-0063]); and,
Opferman does not appear to explicitly disclose
providing an information handling system with a distributed BIOS;
performing a core type transition management operation, the core type transition management operation dynamically managing transitions between a processor core type and another processor core type, the core type transition management operation initializing processor components to enable dynamic transition between core type during a pre-boot phase of operation, the core type transition management operation optimizing power efficiency operating system during a kernel mode of a runtime phase of operation.
However, in analogous art, Kumar discloses
providing an information handling system with a distributed BIOS (e.g. para [0016], “… The constituent components are initialized to a known state through a distributed
BIOS mechanism before the OS is made aware of their presence. …”);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Opferman with the invention of Kumar because it provides techniques for supporting and representing a hot-plugged node and its constituent components as a collective unit to its operating system (OS). A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for supporting and representing a hot-plugged node and its constituent components as a collective unit to its operating system (OS) as suggested by Kumar (see para [0016]).
Opferman as modified by Kumar does not appear to explicitly disclose
performing a core type transition management operation, the core type transition management operation dynamically managing transitions between a processor core type and another processor core type, the core type transition management operation initializing processor components to enable dynamic transition between core type during a pre-boot phase of operation, the core type transition management operation optimizing power efficiency operating system during a kernel mode of a runtime phase of operation.
However, in analogous art, Varma discloses
performing a core type transition management operation, the core type transition management operation dynamically managing transitions between a processor core type and another processor core type, [the core type transition management operation initializing processor components to enable dynamic transition between core type during a pre-boot phase of operation], the core type transition management operation optimizing power efficiency operating system during a kernel mode of a runtime phase of operation (e.g. para [0129], “… In the case of heterogeneous cores, workload may be used, e.g., by the PCU, to determine that the work may be better suited for a different type of core (when there are heterogeneous cores). Note also that cores may appear the same to software but have different performance/power characteristics that are over and above manufacturing differences (e.g., smaller lower performance but power efficient cores versus bigger higher performance and less power efficient cores)”. This paragraph suggests that the core type transition management operation optimizing power efficiency. Figs. 17 and 18, and corresponding text in para [0124-0134].)
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 invention of Varma because it provides techniques for migration of workloads between cores so that various power, performance, thermal and reliability opportunities can be exploited. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for migration of workloads between cores so that various power, performance, thermal and reliability opportunities can be exploited as suggested by Varma (see para [0022]).
Opferman ad modified by Kumar and Varma does not appear to explicitly disclose
(performing a core type transition management operation, the core type transition management operation dynamically managing transitions between a processor core type and another processor core type), the core type transition management operation initializing processor components to enable dynamic transition between core type during a pre-boot phase of operation, (the core type transition management operation optimizing power efficiency operating system during a kernel mode of a runtime phase of operation).
However, this is taught in analogous art, ASBE (e.g. para [0041], “… For example, a boot manager application (e.g., OS loader) may be executed in the pre-boot environment that loads the OS. Other applications may also be run in the pre-boot environment, such as applications that test and verify the functionality of CPU cores, memory, applications that program (e.g., at the factory) firmware images to the SoC (e.g., via fastboot), etc.” also see para [0039-0040]).
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 invention of ASBE because it provides techniques for Platform initialization including pre-boot environment that tests and verifies the functionality of CPU cores, memory, … etc. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for Platform initialization including pre-boot environment that tests and verifies the functionality of CPU cores, memory as suggested by ASBE (see para [0041]).
With respect to claim 2, Opferman as modified by Kumar, Varma and ASBE discloses The method of claim 1, Opferman further discloses wherein:
the processor environment comprises an advanced reduced instruction set computer (RISC) machine (ARM) type processor environment (e.g. para [0051], “… The core 490 may be a reduced instruction set computing (RISC) core, …” para [0056], “The core 490 may support one or more instructions sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set of MIPS Technologies of Sunnyvale, Calif.; the ARM instruction set (with optional additional extensions such as NEON) of ARM Holdings of Sunnyvale, Calif.), …”);
Varma further discloses
the processor core type comprises a big core specialized core type (e.g. para [0129], “… Note also that cores may appear the same to software but have different performance/power characteristics that are over and above manufacturing differences (e.g., smaller lower performance but power efficient cores versus bigger higher performance and less power efficient cores).” For motivation to combine, please refer to office action regarding claim 1 above); and
the another processor core type comprises a little core specialized core type (e.g. para [0129], “… Note also that cores may appear the same to software but have different performance/power characteristics that are over and above manufacturing differences (e.g., smaller lower performance but power efficient cores versus bigger higher performance and less power efficient cores).” For motivation to combine, please refer to office action regarding claim 1 above).
With respect to claim 3, Opferman as modified by Kumar, Varma and ASBE discloses The method of claim 1, Opferman further discloses wherein:
the processor environment comprises an x86 type processor environment (e.g. para [0051], “… The core 490 may be a reduced instruction set computing (RISC) core, …” para [0056], “The core 490 may support one or more instructions sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set of MIPS Technologies of Sunnyvale, Calif.; the ARM instruction set (with optional additional extensions such as NEON) of ARM Holdings of Sunnyvale, Calif.), …”);
Varma further discloses
the processor core type comprises a performance core specialized core type (e.g. para [0129], “… Note also that cores may appear the same to software but have different performance/power characteristics that are over and above manufacturing differences (e.g., smaller lower performance but power efficient cores versus bigger higher performance and less power efficient cores).” For motivation to combine, please refer to office action regarding claim 1 above); and
the another processor core type comprises an efficiency core specialized core type (e.g. para [0129], “… Note also that cores may appear the same to software but have different performance/power characteristics that are over and above manufacturing differences (e.g., smaller lower performance but power efficient cores versus bigger higher performance and less power efficient cores).” For motivation to combine, please refer to office action regarding claim 1 above).
With respect to claim 7 (Currently Amended), it is directed to a system to implement the method disclosed in claim 1, please see the rejections directed to claim 1 above which also cover the limitations recited in claim 7. Note that, Opferman teaches A system comprising:
a processor;
a data bus coupled to the processor; and
a non-transitory, computer-readable storage medium embodying computer program code, the non-transitory, computer-readable storage medium being coupled to the data bus, the computer program code interacting with a plurality of computer operations and comprising instructions executable by the processor and configured for: (e.g. Fig. 9):
With respect to claim 8, it recites same features as claim 2, and is rejected for the same reason.
With respect to claim 9, it recites same features as claim 3, and is rejected for the same reason.
With respect to claim 13, it is directed to a non-transitory, computer-readable storage medium to implement the method disclosed in claim 1, please see the rejections directed to claim 1 above which also cover the limitations recited in claim 13. Note that, Opferman teaches A non-transitory, computer-readable storage medium embodying computer program code, the computer program code comprising computer executable instructions configured for: (e.g. Fig. 9, SRAM UNIT 930):
With respect to claim 14, it recites same features as claim 2, and is rejected for the same reason.
With respect to claim 15, it recites same features as claim 3, and is rejected for the same reason.
Claims 4, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Opferman in view of Kumar, Varma and ASBE as applied to claims 1, 7, and 13 respectively, in further view of Hasenplaugh et al. (US 20140189413 A1, hereinafter “Hasenplaugh”).
With respect to claim 4, Opferman as modified by Kumar, Varma and ASBE discloses The method of claim 1, but does not appear to explicitly disclose wherein:
the core type transition management operation accesses a core voltage vector protocol when performing the core type management operation, the core voltage vector protocol comprising a protocol for communicating with a plurality of processor components regarding core voltage information. however, this is taught in analogous art, Hasenplaugh (e.g. para [0013], “… Some embodiments, rather than trying to manage the long latencies and plethora of messages that result when each core communicates with all other cores, maintain a communication framework in which each core communicates nearest neighbor cores only. From its nearest neighbors, each cores is able to estimate the processor's cumulative power consumption. …” wherein the communication framework reads on a core voltage vector protocol. Para [0053], “Method 400 may begin by receiving (operation 402), at a first core, power consumption information from a subset of an array of cores, excluding the first core. …”).
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 invention of Hasenplaugh because it provides techniques for promoting efficient power management operation in multicore processor systems. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for promoting efficient power management operation in multicore processor systems as suggested by Hasenplaugh (see para [0009]).
With respect to claim 10, it recites same features as claim 4, and is rejected for the same reason.
With respect to claim 16, it recites same features as claim 4, and is rejected for the same reason.
Claims 5-6, 11-12, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Opferman in view of Kumar, Varma and ASBE as applied to claims 1, 7, and 13 respectively, in further view of Gupta et al. (US 20210064426 A1, hereinafter “Gupta”).
With respect to claim 5 (Currently Amended), Opferman as modified by Kumar, Varma and ASBE discloses The method of claim 1, but does not appear to explicitly disclose wherein:
the core voltage vector protocol comprises a per-core abstraction table pointer, pointer comprising an entry for accessing a core voltage vector table. However, this is taught in analogous art, Gupta (e.g. para [0156], “Still with reference to FIG. 21, control passes to block 2150, where a power-to-performance table may be accessed based on the scaled core domain power
budget for each of the different cores/core types to determine an operating point for each of the different cores/core types. …” wherein the scaled core domain power budget reads on the per-core abstraction table pointer.)
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 invention of Gupta because it provides techniques for determining an optimal operating point for the heterogeneous processor. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for determining an optimal operating point for the heterogeneous processor as suggested by Gupta (see para [0034]).
With respect to claim 6, Opferman as modified by Kumar, Varma and ASBE discloses The method of claim 1, but does not appear to explicitly disclose wherein:
the core type transition management operation accesses a processor core object value protocol when performing the core type management operation, the processor core object value protocol comprising a protocol for communicating with a plurality of processor components regarding processor core operational information. However, this is taught in analogous art, Gupta (e.g. para [0178], “… method 2800 begins by receiving operating points for different cores and/or core types (block 2810). …” wherein receiving operating points for different cores suggests a protocol for communicating with a plurality of processor components regarding processor core operational information. Also see para [0179]. For motivation to combine, please refer to office action regarding claim 5 above.)
With respect to claim 11 (Currently Amended), it recites same features as claim 5, and is rejected for the same reason.
With respect to claim 12, it recites same features as claim 6, and is rejected for the same reason.
With respect to claim 17 (Currently Amended), it recites same features as claim 5, and is rejected for the same reason.
With respect to claim 18, it recites same features as claim 6, and is rejected for the same reason.
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Opferman in view of Kumar, Varma and ASBE as applied to claim 13, in further view of Kuo et al. (US 11151022 B1, hereinafter “Kuo”).
With respect to claim 19, Opferman as modified by Kumar, Varma and ASBE discloses The method of claim 13, but does not appear to explicitly disclose wherein: the computer executable instructions are deployable to a client system from a server system at a remote location. However, this is taught in analogous art, Kuo (e.g. col 8, lines 1-25, “… The service provider environment 120 may provide the client devices 102 with one or more user interfaces, … for interacting with the service provider environment 120, such as to submit a configuration for a coordinator 114, and control deployment of that configuration, to submit code corresponding to a task to be executed on the coordinator 114, …” wherein code corresponding to a task to be executed reads on executable instructions.)
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 invention of Kuo because it provides techniques for enabling management of coordinated devices without requiring communications external to the local environment, thereby allowing a reduction in privacy risks and an increase in communication speed over the use of external or public communication networks. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, for the purpose of providing techniques for enabling management of coordinated devices without requiring communications external to the local environment, thereby allowing a reduction in privacy risks and an increase in communication speed over the use of external or public communication networks as suggested by Kuo (see col 2, lines 45-65).
With respect to claim 20, Opferman as modified by Kumar, Varma and ASBE discloses The method of claim 13, but does not appear to explicitly disclose wherein: the computer executable instructions are provided by a service provider to a user on an on-demand basis. however, this is taught in analogous art, Kuo (e.g. col 3, lines 11-20, “Generally described, the typical deployment cycle for tasks, or other on-demand executable code intended for a coordinated device, includes the generation of the executable code, transmission of the executable code to the coordinator, processing of the received code by the coordinator, deployment of the processed code (e.g., tasks) to a selected coordinated device for execution. …” wherein the coordinated device reads on the user. Also refer to col 8, lines 1-25 as cited above for claim 19. For motivation to combine, please refer to office action regarding claim 19.)
Response to Arguments
Applicant's arguments with respect to art rejections filed on 9/10/2026 have been fully considered and are moot upon new ground of rejections made in the office action above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Zengpu Wei whose telephone number is 571-270-1302. The examiner can normally be reached on Monday to Friday from 8:00AM to 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets, can be reached on 571-272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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.
/ZENGPU WEI/
Examiner, Art Unit 2197
