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 .
Claim Objections
Claim 7 is objected to because of the following informalities:
Clim 7 depends on claim 6 and discloses “the battery diagnostics operation” (emphasis added). Claim 6 disclose it as “a battery diagnostic operation” (singular). While usually understood, it is recommended to correct this to “the battery diagnostic operation” for antecedent basis.
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.
The following is a quotation of pre-AIA 35 U.S.C. 112, second paragraph::
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9, 15, and 20 are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 9 depends on claim 1 and discloses “abstain from sending the message to the EC.” (emphasis added). However, Claim 1 recites that the system receives “a message” from the host OS application, but sends “a request” to the EC. Because Claim 1 distinguishes between the “message” (received) and the “request” (sent), stating that the system abstains from sending “the message” to the EC in Claim 9 creates ambiguity regarding what is actually being withheld.
Claim 15 depends on claim 12 and recites “wherein the context information comprises …” However, “context information” is never disclosed in claim 12. It is disclosed in Claim 14. For the purpose of this examination, claim 15 has been interpreted as on claim 14.
Claim 20 depends on Claim 19, which in turn depends on Claim 18. Claim 18 is an apparatus claim directed to a “hardware memory device having program instructions stored thereon …” However, claim 20 recites “wherein the method comprises translating …” There is no “method” recited in claims 18 or 19, resulting in a lack of antecedent basis. Furthermore, reciting a method step inside a CRM/Apparatus claim without tying it to the execution of the instructions is an improper mixing of statutory classes. For the purpose of this examination, claim 20 has been interpreted as “The hardware memory device of claim 19, wherein the program instructions, upon execution, further cause the processor to translate the first API call into the second API call ….”.
Claim Rejections - 35 USC § 103
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.
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 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Vichare et al. (US 2024/0143054, hereinafter Vichare).
Regarding claim 1, Vichare discloses
An Information Handling System (IHS) (paragraph [0031]: an Information Handling System (IHS) may include any instrumentality), comprising:
a processor; and
a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause the IHS to (paragraph [0047]: IHS 200 includes host processor(s) 201… implementing any of a variety of Instruction Set Architectures (ISAs), such as an x86 or a Reduced Instruction Set Computer (RISC) ISA (e.g., POWERPC, ARM … ; paragraph [0053]: system memory 203; paragraph [0230]: Program instructions may also be loaded onto a computer… to cause a series of operations to be performed):
receive, by a kernel driver of a host Operating System (OS), a message from a host OS application (paragraphs [0103]-[0105]: host OS 400 includes kernel space 401 with kernel mode drivers 405/406, and user space 402 with applications 412-414; paragraph [0109]: applications 412-414 are configured to utilize services made available by the drivers, inherently requiring the kernel drivers to receive messages/requests from the host OS applications); and
… send a request to an Embedded Controller (EC), wherein the EC is configured to request battery data from a Battery Management Unit (BMU) (paragraph [0047]: IHS 200 includes host processor(s) 201… implementing any of a variety of Instruction Set Architectures (ISAs), such as an x86 or a Reduced Instruction Set Computer (RISC) ISA; paragraph [0059]: Embedded Controller (EC) … 209 handles various tasks… managing the battery charger and the battery; paragraphs [0065]-[0066]: battery management unit (BMU) 212… configured to collect and store information… battery usage data such as charging and discharging data; paragraph [0126]: in response to the detection of one or more of: … an identification or type of heterogenous computing platform 300; paragraph [0212]: aDSP 306 may execute a firmware service configured to: retrieve raw battery data from BMU 212 … orchestrator 501A may request aDSP 306 to communicate with EC 209, BMU 212 … to request a change to the selected settings).
Vichare does not explicitly disclose the exact phrase that at least in part in response to a determination that the processor comprises a Reduced Instruction Set Computer (RISC) processor, send a request to an Embedded Controller (EC).
However, Vichare explicitly teaches that the IHS can be equipped with either an x86 (CISC) processor or an ARM (RISC) processor (paragraph [0047]). Furthermore, Vichare teaches evaluating policies to issue commands conforming to APIs (paragraph [0125]) and that these actions are performed “in response to the detection of one or more of: … an identification or type of heterogenous computing platform 300” (Vichare, paragraph [0126]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure the kernel driver of Vichare to send the battery management request to the EC in response to a determination that the processor comprises a RISC processor. The motivation would have been to detect the specific type of underlying computing platform (e.g., RISC vs. CISC) to issue the correct API commands and routing paths for that specific architecture, thereby taking advantage of the new management and configuration opportunities provided by RISC (ARM) platforms, as explicitly taught by Vichare (paragraphs [0004]-[0005], [0047], [0125]-[0126]).
Regarding claim 2, Vichare discloses
wherein the EC is configured to use hardware-based security architecture registers accessible via a hardware-based security architecture driver (paragraph [0064]: BMC 209 may be installed as a Trusted Execution Environment (TEE) component; paragraph [0096]: Security device 312 includes any suitable security device, such as a dedicated security processor, a Trusted Platform Module (TPM), a TRUSTZONE device… serving as a hardware root-of-trust; paragraphs [0104]-[0106]: secure kernels and platform drivers used to interface with secure hardware; Note: While Vichare explicitly discloses the EC interacting with a hardware-based security architecture (e.g., TRUSTZONE, TPM) via secure platform drivers, it does not explicitly use the word “registers” to describe the interface. However, it is well-known in the art of computer engineering that hardware-based security devices (such as TPMs or ARM TrustZone architectures) inherently utilize hardware registers that are accessed by their corresponding drivers to read, write, and execute security commands).
Regarding claim 3, Vichare discloses
wherein the hardware-based security architecture driver comprises a TRUSTZONE driver (paragraph [0096]: Security device 312 includes any suitable security device, such as a dedicated security processor, a Trusted Platform Module (TPM), a TRUSTZONE device … ; paragraph [0104]: host OS 400 includes kernel space 401… kernel mode drivers 405… platform secure kernel 410; Note: While Vichare explicitly discloses utilizing a TRUSTZONE device as the hardware-based security architecture along with kernel drivers to interface with platform hardware, it does not explicitly use the exact phrase “TRUSTZONE driver.” However, it is well-known in the art that operating a specific hardware component (such as a TRUSTZONE device) within an operating system requires a corresponding hardware-specific driver (i.e., a TRUSTZONE driver)).
Regarding claim 9, Vichare discloses
a determination that the processor comprises a Complex Instruction Set Computer (CISC) processor (paragraph [0047]: “IHS 200 includes host processor(s) 201… implementing any of a variety of Instruction Set Architectures (ISAs), such as an x86 or a Reduced Instruction Set Computer (RISC) ISA; Note: x86 is universally known in the art as a CISC architecture).
Vichare does not explicitly disclose the exact phrase that wherein the program instructions, upon execution, further cause the IHS to, at least in part in response to a determination that the processor comprises a Complex Instruction Set Computer (CISC) processor, abstain from sending the message to the EC.
However, Vichare explicitly teaches that the IHS can be equipped with either an x86 (CISC) processor or an ARM (RISC) processor (paragraph [0047]). Furthermore, Vichare teaches evaluating policies to issue commands conforming to APIs (paragraph [0125]) and that these actions are performed “in response to the detection of one or more of: … an identification or type of heterogenous computing platform 300” (Vichare, paragraph [0126]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure the kernel driver of Vichare to send the battery management request to the EC in response to a determination that the processor comprises a RISC processor, and otherwise abstain from sending the battery management request to the EC in response to a determination that the processor comprises a CISC processor. The motivation would have been to detect the specific type of underlying computing platform (e.g., RISC vs. CISC) to issue the correct API commands and routing paths for that specific architecture, thereby taking advantage of the new management and configuration opportunities provided by RISC (ARM) platforms, as explicitly taught by Vichare (paragraphs [0004]-[0005], [0047], [0125]-[0126]).
Claims 4-8, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Vichare et al. (US 2024/0143054, hereinafter Vichare) in view of Sultenfuss et al. (US 2018/0373308, hereinafter Sultenfuss).
Regarding claim 4, Vichare discloses
a diagnostic test of a battery driver of the BMU (paragraphs [0065]-[0066]: battery management unit (BMU) 212… configured to collect and store information… battery usage data).
Vichare does not disclose wherein the message is received, at least in part, in response to a result of a diagnostic test of a battery driver of the BMU. Sultenfuss discloses a wherein the message is received, at least in part, in response to a result of a diagnostic test of a battery driver of the BMU (paragraph [0083]: PSA BMU 170-2 may check internal battery 171 periodically against the projected aging profile … If, on the other hand, PSA BMU 170-2 determines that internal battery 171 is aging at a rate faster than the rate in the projected aging profiles, then PSA BMU 170-2 may adjust certain battery data for internal battery 171, such as one or more of (a) the charging parameters, (b) the charging policies and (c) the operational settings; Note: BMU checking the battery periodically against a projected aging profile constitutes performing a diagnostic test, and the subsequent adjustment of battery data/policies based on the determination of the aging rate constitutes a message/instruction being received by the battery driver in response to the result of that diagnostic test). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare to include receiving the message in response to a result of a diagnostic test of the battery driver as taught by Sultenfuss. The motivation would have been to manage gradual changes in one or both of the termination voltage and the fast charge current in order for PSA battery 174 to exhibit or have a life span … that approaches the values provided by or in the projected aging profiles so that the actual life of the battery can continue to track as best as possible the projected life of the battery (Sultenfuss paragraphs [0082]-[0083]).
Regarding claim 5, Vichare discloses
a diagnostic test of a battery driver of the BMU (paragraphs [0065]-[0066]: battery management unit (BMU) 212… configured to collect and store information… battery usage data).
Vichare does not disclose wherein the battery data comprises at least one of: a C-rate, a charge rate, a capacity, a charge or level, an E-rate, a discharge rate, a state of charge, a depth of discharge. Sultenfuss discloses wherein the battery data comprises at least one of: a C-rate, a charge rate, a capacity, a charge or level, an E-rate, a discharge rate, a state of charge, a depth of discharge (paragraphs [0053], [0059]: “the terms ‘state of charge’, ‘SOC’, or ‘charge level’ refer to an actual charge level of a battery … parameters monitored by the BMU 170 may include … the SOC of the battery, the depth of discharge of the battery, the current flowing into the battery, the current flowing out of the battery). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare to include battery data comprising a capacity, charge level, state of charge, and depth of discharge as taught by Sultenfuss. The motivation would have been to accurately monitor the overall condition of the battery and prevent the battery from operating outside of safe operating conditions (Sultenfuss paragraphs [0052], [0059]).
Regarding claim 6, Vichare does not disclose wherein to provide the requested battery data, the EC is configured to trigger a battery diagnostic operation to be performed by the BMU. Sultenfuss discloses a wherein the message is received, at least in part, in response to a result of a diagnostic test of a battery driver of the BMU (paragraphs [0079], [0083]: EC 180 may control the executable code and battery data for PSA BMU 170-2 … To perform power management of internal battery 171, PSA BMU 170-2 may check internal battery 171 periodically against the projected aging profile). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare to configure the EC to trigger a battery diagnostic operation to be performed by the BMU as taught by Sultenfuss. The motivation would have been to allow the EC to utilize charging profiles and policies to control charging and ensure the actual rate of decreasing capacity mirrors projected aging profiles (Sultenfuss paragraph [0081]).
Regarding claim 7, Vichare does not disclose wherein the EC is configured to trigger the battery diagnostics operation without the IHS entering a System Management Mode (SMM). Sultenfuss discloses wherein the EC is configured to trigger the battery diagnostics operation without the IHS entering a System Management Mode (SMM) (paragraph [0043]: Embedded controller 180 may execute EC firmware 186 on EC processor 182 even when other components in information handling system 100 are inoperable or are powered down; Note: Because the EC operates independently and can execute firmware even when the main system components are inoperable or powered down, it triggers operations out-of-band without requiring the host processor to halt or enter a specific host-level execution state such as System Management Mode (SMM)). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare to configure the EC to trigger a battery diagnostic operation to be performed by the BMU without the IHS entering a System Management Mode as taught by Sultenfuss. The motivation would have been to use the charging profiles and the charging policies to control charging of internal battery 171… to ensure that the actual rate of decreasing capacity mirrors or approaches, as best as possible, the projected rates of decreasing charge capacity in the projected aging profiles (Sultenfuss paragraph [0081]), and to allow the embedded controller to “execute EC firmware 186 on EC processor 182 even when other components in information handling system 100 are inoperable or are powered down (Sultenfuss paragraph [0043]).
Regarding claim 8, Vichare discloses
wherein at least in part in response to the determination that the processor comprises the RISC processor, the program instructions, upon execution, further cause the EC to send the request (paragraph [0047]: IHS 200 includes host processor(s) 201… implementing any of a variety of Instruction Set Architectures (ISAs), such as an x86 or a Reduced Instruction Set Computer (RISC) ISA (e.g., POWERPC, ARM …); paragraphs [0125]-[0126]: orchestrator 501A may install, update, modify, enable or disable any of firmware services … in response to the detection of … type of heterogenous computing platform 300; Note: Detecting the type of computing platform constitutes determining if the processor is a RISC processor, and the orchestrator dynamically managing these services occurs at runtime).
Vichare does not disclose further cause the EC to send the request to the BMU at runtime, without reboot, and without reset. Sultenfuss discloses further cause the EC to send the request to the BMU at runtime, without reboot, and without reset (paragraphs [0082]-[0083]: PSA BMU 170-2 may check internal battery 171 periodically against the projected aging profile … PSA BMU 170-2 may adjust certain battery data for internal battery 171; Note: The EC and BMU periodically checking battery health and dynamically adjusting charging parameters occurs continuously during normal OS operation (at runtime), which inherently happens without requiring the system to reboot or reset).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare to configure the EC to send the request to the BMU at runtime, without reboot, and without reset, as taught by Sultenfuss. The motivation would have been to perform power management of internal battery 171 and to implement specific adjustments so that the actual life of the battery can continue to track as best as possible the projected life of the battery (Sultenfuss paragraph [0083]).
Regarding claim 18, Vichare discloses
A hardware memory device having program instructions stored thereon that, upon execution by a processor, cause the processor to (paragraph [0230]: Program instructions may also be loaded onto a computer… to cause a series of operations to be performed):
receive, by a kernel driver of a host Operating System (OS), a message from a host OS application to cause an Embedded Controller (EC) to trigger a battery operation (paragraphs [0103]-[0105]: host OS 400 includes kernel space 401 with kernel mode drivers 405/406, and user space 402 with applications 412-414; paragraph [0109]: applications 412-414 are configured to utilize services made available by the drivers; paragraph [0212]: orchestrator 501A may request aDSP 306 to communicate with EC 209, BMU 212 … to request a change to the selected settings);
… send a request to the EC (paragraph [0047]: IHS 200 includes host processor(s) 201… implementing any of a variety of Instruction Set Architectures (ISAs), such as an x86 or a Reduced Instruction Set Computer (RISC) ISA; paragraph [0059]: Embedded Controller (EC) … 209 handles various tasks… managing the battery charger and the battery; paragraphs [0065]-[0066]: battery management unit (BMU) 212… configured to collect and store information… battery usage data such as charging and discharging data; paragraph [0126]: in response to the detection of one or more of: … an identification or type of heterogenous computing platform 300; paragraph [0212]: aDSP 306 may execute a firmware service configured to: retrieve raw battery data from BMU 212 … orchestrator 501A may request aDSP 306 to communicate with EC 209, BMU 212 … to request a change to the selected settings).
Vichare does not explicitly disclose the exact phrase that at least in part in response to a determination that the processor comprises a Reduced Instruction Set Computer (RISC) processor, send a request to an Embedded Controller (EC).
However, Vichare explicitly teaches that the IHS can be equipped with either an x86 (CISC) processor or an ARM (RISC) processor (paragraph [0047]). Furthermore, Vichare teaches evaluating policies to issue commands conforming to APIs (paragraph [0125]) and that these actions are performed “in response to the detection of one or more of: … an identification or type of heterogenous computing platform 300” (Vichare, paragraph [0126]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure the kernel driver of Vichare to send the battery management request to the EC in response to a determination that the processor comprises a RISC processor. The motivation would have been to detect the specific type of underlying computing platform (e.g., RISC vs. CISC) to issue the correct API commands and routing paths for that specific architecture, thereby taking advantage of the new management and configuration opportunities provided by RISC (ARM) platforms, as explicitly taught by Vichare (paragraphs [0004]-[0005], [0047], [0125]-[0126]).
Vichare does not disclose a battery's Built-In Self-Test (BIST). Sultenfuss discloses a battery's Built-In Self-Test (BIST) (paragraph [0079]: EC 180 may control the executable code and battery data for PSA BMU 170-2; paragraph [0083]: To perform power management of internal battery 171, PSA BMU 170-2 may check internal battery 171 periodically against the projected aging profile). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Vichare to include the EC triggering a BMU diagnostic test as taught by Sultenfuss. The motivation would have been to ensure that the actual rate of decreasing capacity mirrors or approaches, as best as possible, the projected rates of decreasing charge capacity in the projected aging profiles (Sultenfuss paragraph [0081]).
Claims 11-15 are rejected under 35 U.S.C. 103 as being unpatentable over Vichare et al. (US 2024/0143054, hereinafter Vichare) in view of Sultenfuss et al. (US 2018/0373308, hereinafter Sultenfuss) as applied to claim 1, and further in view of Nystad (US 2006/0161704, hereinafter Nystad) and DeMoss (US 2023/0116025, hereafter DeMoss).
Regarding claim 11, Vichare discloses
wherein the message comprises a first Application Programming Interface (API) call, wherein the request comprises a second API call, and wherein the program instructions, upon execution, further cause the kernel driver to translate the first API call into the second API call based (paragraphs [0125]-[0126]: components and orchestrators managing firmware services, which inherently utilizes standard API calls and kernel drivers to translate higher-level OS requests into lower-level hardware/firmware requests).
Vichare in view of Sultenfuss does not wherein the message comprises a first Application Programming Interface (API) call, wherein the request comprises a second API call, and wherein the program instructions, upon execution, further cause the kernel driver to translate the first API call into the second API call based, at least in part, upon a Look-Up-Table (LUT). Nystad discloses wherein the message comprises a first Application Programming Interface (API) call, wherein the request comprises a second API call, and wherein the program instructions, upon execution, further cause the kernel driver to translate the first API call into the second API call (paragraph [0004]: a device driver that will recognise and respond to the standard API commands … and translate them into instructions tailored to the particular slave device (hardware); paragraph [0198]: It should therefore be able to handle interrupts but otherwise can be of any processing unit type (RISC, CISC, etc.); paragraph [0322]: translating … API calls to hardware-specific commands). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare and Sultenfuss to configure the kernel driver to translate a first higher-level API call into a second hardware-specific API call/command, as taught by Nystad. The motivation would have been to allow standard software applications to seamlessly communicate with specific, proprietary hardware resources without needing to know the exact hardware architecture, thereby increasing system flexibility and compatibility (Nystad paragraph [0005]).
DeMoss discloses mapping or translating data based, at least in part, upon a Look-Up-Table (LUT) (paragraph [0099]: Identifier to configuration map repository 232 may include information regarding associations between various identifiers …; paragraph [0103]: Entries 270, 278 may be implemented in a searchable format such as, for example, as look up table). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare in view of Sultenfuss and Nystad to base the kernel driver’s translation of the first API call into the second API call, at least in part, upon a Look-Up-Table (LUT) as taught by DeMoss. The motivation would have been to provide an efficient, searchable format (DeMoss paragraph [0103]) for the system to quickly and accurately map incoming OS-level API calls to their corresponding hardware-specific API calls, thereby optimizing memory access and processing speed during hardware management operations.
Regarding claim 12, Vichare discloses
wherein the kernel driver is configured to issue API call … based, at least in part, upon a policy (paragraph [0125]: the orchestrator/OS components evaluate policies to issue commands conforming to APIs).
Vichare in view of Sultenfuss does not wherein the kernel driver is configured to translate the first API call into the second API call. Nystad discloses wherein the kernel driver is configured to translate the first API call into the second API call (paragraph [0004]: a device driver that will recognise and respond to the standard API commands … and translate them into instructions tailored to the particular slave device (hardware); paragraph [0198]: It should therefore be able to handle interrupts but otherwise can be of any processing unit type (RISC, CISC, etc.); paragraph [0322]: translating… API calls to hardware-specific commands). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare and Sultenfuss to configure the kernel driver to translate a first higher-level API call into a second hardware-specific API call/command, as taught by Nystad. The motivation would have been to allow standard software applications to seamlessly communicate with specific, proprietary hardware resources without needing to know the exact hardware architecture, thereby increasing system flexibility and compatibility (Nystad paragraph [0005]).
Regarding claim 13, Vichare in view of Sultenfuss does not wherein the policy comprises one or more rules usable to translate the message based, at least in part, upon an entitlement verification. Nystad discloses wherein the policy comprises one or more rules usable to translate the message (paragraph [0004]: a device driver that will recognise and respond to the standard API commands … and translate them into instructions tailored to the particular slave device (hardware); paragraph [0198]: It should therefore be able to handle interrupts but otherwise can be of any processing unit type (RISC, CISC, etc.); paragraph [0322]: translating… API calls to hardware-specific commands) based, at least in part, upon an entitlement verification (paragraph [0316]: it would also, for example, be possible to add authentication and encryption across the interface to, for example, ensure that the master device accessing the 3D graphics processing platform has the credentials to do so and to secure any data that is transferred and stored). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the policies/rules of the combined system to base the translation of the message, at least in part, upon an entitlement verification (such as checking credentials or authentication), as taught by Nystad. The motivation would have been to ensure system security, prevent unauthorized access to low-level hardware resources, and guarantee that only applications or devices with the proper credentials are permitted to execute specific hardware-translated commands (Nystad paragraphs [0102], [0316]).
Regarding claim 14, Vichare discloses
wherein the policy comprises one or more rules usable to issue the message based, at least in part, upon context information (paragraph [0125]: the orchestrator/OS components evaluate policies to issue commands conforming to APIs; paragraph [0126]: based upon polic(ies) 602, orchestrator 501A may install, update, modify, enable or disable any of firmware services 601A-N in each of devices 501A-N in response to the detection of one or more of: an IHS location, an IHS posture (e.g., lid closed, etc.), an IHS identification (e.g., service tag, serial number, etc.), a type of IHS (e.g., manufacturer, model, etc.), an identification or type of heterogenous computing platform 300).
Vichare in view of Sultenfuss does not translate the message. Nystad discloses translate the message (paragraph [0004]: a device driver that will recognise and respond to the standard API commands … and translate them into instructions tailored to the particular slave device (hardware); paragraph [0198]: It should therefore be able to handle interrupts but otherwise can be of any processing unit type (RISC, CISC, etc.); paragraph [0322]: translating… API calls to hardware-specific commands). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the policies/rules of the combined system to base the translation of the message, at least in part, upon an entitlement verification (such as checking credentials or authentication), as taught by Nystad. The motivation would have been to ensure system security, prevent unauthorized access to low-level hardware resources, and guarantee that only applications or devices with the proper credentials are permitted to execute specific hardware-translated commands (Nystad paragraphs [0102], [0316]).
Regarding claim 15, Vichare
wherein the context information comprises at least one of: a location of the IHS, an identity of a user of the IHS, a host OS of the IHS, an identity of the host OS application, or a network connectivity of the HIS (paragraph [0126]: based upon polic(ies) 602, orchestrator 501A may install, update, modify, enable or disable any of firmware services 601A-N in each of devices 501A-N in response to the detection of one or more of: an IHS location, an IHS posture (e.g., lid closed, etc.), an IHS identification (e.g., service tag, serial number, etc.), a type of IHS (e.g., manufacturer, model, etc.), an identification or type of heterogenous computing platform 300, an IHS battery (dis)charge level or rate, an identity or type of connected or available IHS peripherals, a security posture of IHS 200 (e.g., connected to VPN, disposed in a trusted or secure location, etc.), an identity or type of applications 412-414 executed by host OS 400, an identity or type of one of applications 412-414 requesting firmware services 601A-N (e.g., via OEM driver 408), an identification of a user of the IHS, an identification of a user group or role).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Vichare et al. (US 2024/0143054, hereinafter Vichare) in view of Sultenfuss et al. (US 2018/0373308, hereinafter Sultenfuss) and Nystad (US 2006/0161704, hereinafter Nystad).
Regarding claim 16, Vichare discloses
In an Information Handling System (IHS) (paragraph [0031]: an Information Handling System (IHS) may include any instrumentality), a method comprising:
receiving, by an Embedded Controller (EC), a message from a kernel driver, wherein the message comprises a request originated by a host Operating System (OS) application executed by a processor (paragraph [0109]: applications 412-414 are configured to utilize services made available by the drivers; paragraph [0212]: orchestrator 501A may request aDSP 306 to communicate with EC 209, BMU 212 … to request a change to the selected settings); and
providing, by the kernel driver, a response from the EC to the host OS application (paragraph [0109]: applications 412-414 are configured to utilize services made available by the drivers, which inherently includes receiving responses/status).
Vichare does not disclose wherein the request causes the EC to trigger a Battery Management Unit (BMU) diagnostics test. Sultenfuss discloses wherein the request causes the EC to trigger a Battery Management Unit (BMU) diagnostics test (paragraph [0079]: EC 180 may control the executable code and battery data for PSA BMU 170-2; paragraph [0083]: To perform power management of internal battery 171, PSA BMU 170-2 may check internal battery 171 periodically against the projected aging profile). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Vichare to include the EC triggering a BMU diagnostic test as taught by Sultenfuss. The motivation would have been to ensure that the actual rate of decreasing capacity mirrors or approaches, as best as possible, the projected rates of decreasing charge capacity in the projected aging profiles (Sultenfuss paragraph [0081]).
Vichare in view of Sultenfuss does not wherein the kernel driver is configured to send a translated request to the EC. Nystad discloses wherein the kernel driver is configured to send a translated request to the EC (paragraph [0004]: The slave device driver on the master device will recognise and respond to the standard API commands that the application requiring the slave device’s resources produces and translate them into instructions tailored to the particular slave device (hardware) in question); paragraph [0198]: It should therefore be able to handle interrupts but otherwise can be of any processing unit type (RISC, CISC, etc.); paragraph [0322]: translating … API calls to hardware-specific commands). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the combined system of Vichare and Sultenfuss to configure the kernel driver to send a translated request as taught by Nystad. The motivation would have been to avoid software applications needing to be configured for specific hardware arrangements and to allow an application to send standardised commands to an appropriate slave device hardware driver, without the application needing to know the specific hardware of the slave device in the system (Nystad paragraph [0005]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Vichare et al. (US 2024/0143054, hereinafter Vichare) in view of Sultenfuss et al. (US 2018/0373308, hereinafter Sultenfuss) as applied to claim 16, and further in view of Nystad (US 2006/0161704, hereinafter Nystad) and DeMoss (US 2023/0116025, hereafter DeMoss).
Regarding claim 17, Vichare in view of Sultenfuss does not wherein the request comprises a first Application Programming Interface (API) call, wherein the translated request comprises a second API call, and wherein the method further comprises translating the first API call into the second API call based, at least in part, upon a Look-Up-Table (LUT). Nystad discloses wherein the request comprises a first Application Programming Interface (API) call, wherein the translated request comprises a second API call, and wherein the method further comprises translating the first API call into the second API call (paragraph [0004]: a device driver that will recognise and respond to the standard API commands … and translate them into instructions tailored to the particular slave device (hardware); paragraph [0198]: It should therefore be able to handle interrupts but otherwise can be of any processing unit type (RISC, CISC, etc.); paragraph [0322]: translating … API calls to hardware-specific commands). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare and Sultenfuss to configure the kernel driver to translate a first higher-level API call into a second hardware-specific API call/command, as taught by Nystad. The motivation would have been to allow standard software applications to seamlessly communicate with specific, proprietary hardware resources without needing to know the exact hardware architecture, thereby increasing system flexibility and compatibility (Nystad paragraph [0005]).
DeMoss discloses mapping or translating data based, at least in part, upon a Look-Up-Table (LUT) (paragraph [0099]: Identifier to configuration map repository 232 may include information regarding associations between various identifiers …; paragraph [0103]: Entries 270, 278 may be implemented in a searchable format such as, for example, as look up table). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare in view of Sultenfuss and Nystad to base the kernel driver’s translation of the first API call into the second API call, at least in part, upon a Look-Up-Table (LUT) as taught by DeMoss. The motivation would have been to provide an efficient, searchable format (DeMoss paragraph [0103]) for the system to quickly and accurately map incoming OS-level API calls to their corresponding hardware-specific API calls, thereby optimizing memory access and processing speed during hardware management operations.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Vichare et al. (US 2024/0143054, hereinafter Vichare) in view of Sultenfuss et al. (US 2018/0373308, hereinafter Sultenfuss) as applied to claim 18, and further in view of Nystad (US 2006/0161704, hereinafter Nystad).
Regarding claim 19, Vichare discloses
wherein the message comprises a first Application Programming Interface (API) call, wherein the request comprises a second API call, and wherein the program instructions, upon execution, further cause the kernel driver to translate the first API call into the second API call based (paragraphs [0125]-[0126]: components and orchestrators managing firmware services, which inherently utilizes standard API calls and kernel drivers to translate higher-level OS requests into lower-level hardware/firmware requests).
Vichare in view of Sultenfuss does not disclose wherein the message comprises a first Application Programming Interface (API) call, and wherein the request comprises a second API call. Nystad discloses wherein the message comprises a first Application Programming Interface (API) call, and wherein the request comprises a second API call (paragraph [0004]: a device driver that will recognise and respond to the standard API commands … and translate them into instructions tailored to the particular slave device (hardware); paragraph [0198]: It should therefore be able to handle interrupts but otherwise can be of any processing unit type (RISC, CISC, etc.); paragraph [0322]: translating … API calls to hardware-specific commands). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare and Sultenfuss to configure the kernel driver to translate a first higher-level API call into a second hardware-specific API call/command, as taught by Nystad. The motivation would have been to allow standard software applications to seamlessly communicate with specific, proprietary hardware resources without needing to know the exact hardware architecture, thereby increasing system flexibility and compatibility (Nystad paragraph [0005]).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Vichare et al. (US 2024/0143054, hereinafter Vichare) in view of Sultenfuss et al. (US 2018/0373308, hereinafter Sultenfuss) and Nystad (US 2006/0161704, hereinafter Nystad) as applied to claim 19, and further in view of DeMoss (US 2023/0116025, hereafter DeMoss).
Regarding claim 20, Vichare in view of Sultenfuss does not wherein the method comprises translating the first API call into the second API call based, at least in part, upon a Look-Up-Table (LUT). Nystad discloses wherein the method comprises translating the first API call into the second API call (paragraph [0004]: a device driver that will recognise and respond to the standard API commands … and translate them into instructions tailored to the particular slave device (hardware); paragraph [0198]: It should therefore be able to handle interrupts but otherwise can be of any processing unit type (RISC, CISC, etc.); paragraph [0322]: translating … API calls to hardware-specific commands). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare and Sultenfuss to configure the kernel driver to translate a first higher-level API call into a second hardware-specific API call/command, as taught by Nystad. The motivation would have been to allow standard software applications to seamlessly communicate with specific, proprietary hardware resources without needing to know the exact hardware architecture, thereby increasing system flexibility and compatibility (Nystad paragraph [0005]).
DeMoss discloses mapping or translating data based, at least in part, upon a Look-Up-Table (LUT) (paragraph [0099]: Identifier to configuration map repository 232 may include information regarding associations between various identifiers …; paragraph [0103]: Entries 270, 278 may be implemented in a searchable format such as, for example, as look up table). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vichare in view of Sultenfuss and Nystad to base the kernel driver’s translation of the first API call into the second API call, at least in part, upon a Look-Up-Table (LUT) as taught by DeMoss. The motivation would have been to provide an efficient, searchable format (DeMoss paragraph [0103]) for the system to quickly and accurately map incoming OS-level API calls to their corresponding hardware-specific API calls, thereby optimizing memory access and processing speed during hardware management operations.
Allowable Subject Matter
Claim 10 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Kondapi et al. (US 2024/0144925) discloses “an x86 or a Reduced Instruction Set Computer (RISC) ISA (e.g., POWERPC, ARM, SPARC, MIPS, etc.)” (paragraph [0048]), “Embedded Controller (EC) or Baseboard Management Controller (BMC) 209 is operational from the very start of each IHS power reset and handles various tasks not ordinarily handled by host processor(s) 201” (paragraph [0060]), and “battery data (e.g., to calculate a charge or discharge rate, current charge level, etc.). To that end, aDSP 306 may be coupled to BMU 212” (paragraph [0081]),
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y. Blair can be reached on (571)270-1014. 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.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 9/2/2026
Prosecution Insights