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 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, 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, 2, 6, 7, 9 - 11, 16, 17 and 21 - 23 are rejected under 35 U.S.C. 103 as being unpatentable over Kulchytskyy et al. (US Pat. No. 10416988), hereinafter referred to as Kulchytskyy in view of Vakulenko et al. (US Pub. No. 20200044868), hereinafter referred to as Vakulenko.
As to claim 1, Kulchytskyy discloses a method for managing a data processing system (data processing system, Fig. 1), the method comprising:
making a first determination (firmware driver 122 obtains management data and converts it into JSON for evaluation of device state, Fig. 2A, steps 204–208), by a management controller of the data processing system (BMC 106 acting as the management controller, Fig. 1), that a peripheral device connected to the data processing system is in a flashless state (where the management client 110 determines whether the current firmware hash value 1606 and the reference firmware hash value 1612 are the same. If the current firmware hash value 1606 and the reference firmware hash value 1612 are the same at operation 1718, this indicates that the integrity of the firmware 104 has not been compromised, col. 29, lines 20 - 26); and
instantiate (remedial action can be initiated such as, but not limited to, updating the firmware 104 of the managed computing system 102 in the manner described above. The routine 1700 then proceeds from operation 1722 to operation 1720, where it ends, col. 29, lines 34 - 39), by the management controller and in response to the first determination, one or more recovery actions to recover the peripheral device from the flashless state (the firmware driver retrieves the firmware image from the location of the firmware image identified by the data provided by the BMC. The firmware driver then updates the firmware of the computing system using the firmware image, col. 3, lines 54 - 58).
Vakulenko discloses, what Kulchytskyy lacks, wherein the management controller is a microcontroller installed within the data processing system that operates independently of a central processing unit (CPU) (a central processing unit 235, Fig. 2) of the data processing system (baseboard management controller BMC 120 implemented as a dedicated management controller separate from host processor 102 within computing system 100, Fig. 1; para. [0028]–[0032]), the management controller manages the peripheral device (BMC 120 monitors and manages peripheral components 140 of computing system 100, Fig. 1; para. [0034]), and the management controller makes the first determination by at least: identifying one or more pieces of information indicating that the peripheral device is physically connected to the data processing system (hardware inventory information including presence data collected from peripheral components via management interfaces, para. [0035]–[0038]), making a second determination, that the management controller is unable to discover the peripheral device despite the peripheral device being physically connected to the data processing system (management logic compares expected device inventory with detected devices and determines absence or non-discovery condition, para. [0040]–[0043]), and tagging the peripheral device as being in the flashless state based on the second determination (device status or health state updated to indicate fault or degraded condition when non-discovery or integrity failure is detected, para. [0044]–[0047]).
Kulchytskyy and Vakulenko are analogous art because they are from the same field of endeavor, namely management and control of electronic or computing devices using a management controller separate from a host processor to control device functionality and operational state.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Kulchytskyy and Vakulenko before him or her, to modify the management controller–based peripheral state management and recovery architecture of Kulchytskyy to include the independent controller-based selective activation and secure state modification mechanisms of Vakulenko.
The suggestion/motivation for doing so would have been to enhance reliability, security, and controllable activation/deactivation of managed hardware components within a computing system.
Therefore, it would have been obvious to combine Vakulenko with Kulchytskyy to obtain the invention as specified in the instant claim.
As to claim 2, Kulchytskyy discloses the method of claim 1, wherein the management controller is a microcontroller installed within the data processing system that operates independently of a central processing unit (CPU) of the data processing system (the Baseboard Management Controller (BMC) 106, implemented as a dedicated microcontroller within the managed computing system 102, is physically present alongside the host CPU but executes its own firmware stack and management routines without relying on host CPU resources. As shown in Fig. 1, the BMC 106 communicates with firmware 104 and management client 110 through the REST-over-IPMI interface 102, while the host CPU is not part of this communication path. The specification expressly describes the BMC as a specialized service processor that monitors and manages system state “independently of a host system’s processor, firmware, and operating system” (col. 1, lines 26 - 27), confirming that the BMC operates separately from the CPU to carry out management and recovery functions), the peripheral device is a data processing unit (DPU) (PCIe peripheral device updated via firmware update module 608, Fig. 8), and the management controller manages operations of the DPU (BMC 106 provides firmware image location to firmware update module 608, directing recovery of PCIe device, Figs. 8–9).
As to claim 6, Kulchytskyy discloses the method of claim 2, wherein the one or more recovery actions comprise:
waiting for a host of the data processing system to be booted up (firmware waits until reboot before applying new firmware configuration or update, Figs. 7 and 9), the host being an operating system (OS) of the data processing system (firmware update applied during host reboot, OS loaded afterward, Fig. 7);
once the host is booted up, making a second determination that the host comprises a driver issue with regard to the peripheral device in the flashless state (system inventory comparison against expected drivers, integrity monitoring detects mismatch, Fig. 16); and
generating, in response to the second determination, a notification to a user of the data processing system indicating the driver issue (management client 110 receives reporting from management server 108 with integrity status, Fig. 16).
As to claim 7, Kulchytskyy discloses the method of claim 6, wherein the driver issue comprises the host missing a driver for the peripheral device in the flashless state or the host comprising an incorrect one for the driver of the peripheral device in the flashless state (described in context of configuration mismatch and missing/incompatible firmware/driver reporting, column 7 lines 47 – 57 and column 8 lines 19 - 27).
As to claim 11, Kulchytskyy discloses a non-transitory machine-readable medium having instructions stored therein, which when executed by a processor (the BMC 106 includes its own dedicated processor for executing management operations, shown in the managed computing system 102, Fig.), cause the processor to perform operations for managing peripheral device of a data processing system (data processing system, Fig. 1), the operations comprising:
making a first determination, by a management controller of the data processing system, that a peripheral device connected to the data processing system is in a flashless state (where the management client 110 determines whether the current firmware hash value 1606 and the reference firmware hash value 1612 are the same. If the current firmware hash value 1606 and the reference firmware hash value 1612 are the same at operation 1718, this indicates that the integrity of the firmware 104 has not been compromised, Figs. 16–17; col. 29, lines 20 – 26); and
instantiate, by the management controller and in response to the first determination, one or more recovery actions to recover the peripheral device from the flashless state (remedial action can be initiated such as, but not limited to, updating the firmware 104 of the managed computing system 102 in the manner described above. The routine 1700 then proceeds from operation 1722 to operation 1720, where it ends, col. 29, lines 34 – 39. The firmware driver retrieves the firmware image from the location of the firmware image identified by the data provided by the BMC. The firmware driver then updates the firmware of the computing system using the firmware image, col. 3, lines 54 – 58).
As to claim 9, Vakulenko discloses the method of claim 6, wherein the one or more recovery actions comprise: causing the peripheral device in the flashless state to enter a low power mode (disabled/de-activated hardware component 212 and activated feature-constrained hardware component 213 representing reduced operational states of a hardware component, Fig. 2; para. [0017]–[0019]), the low power mode being automatically stopped by the peripheral device in the flashless state once the flashless state is resolved (electronic device 210 validating ACE OAuth token 251 and modifying configuration parameters 273 in secure storage 271 to activate or upgrade hardware component to fully-activated/fully-operational hardware component 211, Fig. 2; para. [0017]).
As to claim 10, Vakulenko discloses the method of claim 9, wherein the one or more recovery actions further comprise: after causing the peripheral device in the flashless state to enter the low power mode (hardware component 212 in disabled/de-activated state, Fig. 2; para. [0017]), updating a peripheral device list hosted by the management controller to indicate that the peripheral device has a degraded health status (cloud-based platform 120 and device management platform 140 managing device state and configuration parameters 273 associated with hardware components, Fig. 1; Fig. 2; para. [0017]–[0019]).
As to claim 16, Kulchytskyy discloses a management controller of a data processing system (data processing system, Fig. 1), the management controller comprising: a processor (the BMC 106 includes its own dedicated processor for executing management operations, shown in the managed computing system 102, Fig. 1); and a memory (the BMC 106 includes memory storing instructions and management data used for system monitoring and recovery, Fig. 1) coupled to the processor, the memory storing instructions that, when executed by the processor, causes the management controller to perform operations for managing a peripheral device of the data processing system (the BMC 106, implemented as a service processor with its own memory and firmware, operating independently of the host CPU in the managed computing system 102, Fig. 1), the operations comprising:
making a first determination, by a management controller of the data processing system, that a peripheral device connected to the data processing system is in a flashless state (where the management client 110 determines whether the current firmware hash value 1606 and the reference firmware hash value 1612 are the same. If the current firmware hash value 1606 and the reference firmware hash value 1612 are the same at operation 1718, this indicates that the integrity of the firmware 104 has not been compromised, Figs. 16–17; col. 29, lines 20 – 26); and
instantiate, by the management controller and in response to the first determination, one or more recovery actions to recover the peripheral device from the flashless state (remedial action can be initiated such as, but not limited to, updating the firmware 104 of the managed computing system 102 in the manner described above. The routine 1700 then proceeds from operation 1722 to operation 1720, where it ends, col. 29, lines 34 – 39. The firmware driver retrieves the firmware image from the location of the firmware image identified by the data provided by the BMC. The firmware driver then updates the firmware of the computing system using the firmware image, col. 3, lines 54 – 58).
Claim 12 recites the corresponding limitation of claim 2. Therefore, they are rejected accordingly.
Claim 17 recites the corresponding limitation of claim 2. Therefore, they are rejected accordingly.
As to claim 21, Vakulenko discloses the management controller of claim 17 (electronic device 110 including feature activation/configuration unit 217 and secure storage 271, Fig. 2; para. [0017]–[0019]), wherein the one or more recovery actions comprise:
waiting for a host of the data processing system to be booted up (electronic device 110 completing initialization prior to validating ACE OAuth token 251 and modifying configuration parameters 273, Fig. 2; para. [0017]), the host being an operating system (OS) of the data processing system (electronic device 110 executing system software and interacting with cloud-based platform 120 and device management platform 140 after device initialization, Fig. 1; para. [0017]–[0019]);
once the host is booted up (after device initialization and system software execution enabling feature activation processing, Fig. 1; para. [0017]–[0019]), making a second determination that the host comprises a driver issue (determining that hardware component 212 remains disabled or feature-constrained based on configuration parameters 273 prior to successful activation, Fig. 2; para. [0017]) with regard to the peripheral device in the flashless state (feature activation/configuration unit 217 determining operational state of hardware components 211–213 based on stored configuration parameters 273 and token validation, Fig. 2; para. [0017]);
and generating (delivery of ACE OAuth token 251 and associated activation response through cloud-based platform 120 and device management platform 140, Fig. 1; para. [0017]–[0019]), in response to the second determination (determination that hardware component remains disabled prior to valid activation, Fig. 2; para. [0017]), a notification (interaction between cloud-based platform 120 and end-user via portal access interface 219 for feature activation management, Fig. 1; Fig. 2; para. [0017]–[0019]) to a user of the data processing system indicating the driver issue (cloud-based platform 120 and device management platform 140 interacting with end-user to manage device state and feature activation, Fig. 1; para. [0017]–[0019]).
As to claim 22, Vakulenko discloses the management controller of claim 21, wherein the driver issue comprises the data processing system missing a driver (hardware component 212 remaining disabled/de-activated prior to activation due to unmodified configuration parameters 273, Fig. 2; para. [0017]) for the peripheral device in the flashless state or the host comprising an incorrect one (hardware component 213 being feature-constrained until correct configuration parameters 273 are applied, Fig. 2; para. [0017]) for the driver of the peripheral device in the flashless state (hardware component 212 being disabled/de-activated or feature-constrained until proper configuration parameters 273 are modified upon validation of ACE OAuth token 251, Fig. 2; para. [0017]).
As to claim 23, Vakulenko discloses the management controller of claim 21, wherein the one or more recovery actions comprise:
causing the peripheral device in the flashless state (hardware component 212 in disabled/de-activated state prior to activation, Fig. 2; para. [0017]) to enter a low power mode (disabled/de-activated hardware component 212 representing reduced operational state, Fig. 2; para. [0017]–[0019]),
the low power mode being automatically stopped (hardware component transitioning from disabled/de-activated state 212 to fully-activated/fully-operational hardware component 211 upon successful token validation and configuration update, Fig. 2; para. [0017]) by the peripheral device in the flashless state once the flashless state is resolved (fully-activated/fully-operational hardware component 211 after validation of ACE OAuth token 251 and modification of configuration parameters 273, Fig. 2; para. [0017]).
Allowable Subject Matter
Claims 4, 5, 8, 12, 14, 15, 19 and 20 are 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.
Response to Arguments
Applicant’s arguments with respect to claims above have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUANITO C BORROMEO whose telephone number is (571)270-1720. The examiner can normally be reached on Monday - Friday 9 - 5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Henry Tsai can be reached on 5712724176. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.C.B/ Assistant Examiner, Art Unit 2184
/HENRY TSAI/Supervisory Patent Examiner, Art Unit 2184