DETAILED ACTION
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they do not include the following reference sign(s) mentioned in the description: “120B” (See specification; page 8, para 0024 and 0034).
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The abstract of the disclosure is objected to because the first occurrence of the acronyms “LCS”, “IHS”, “vBMC” and “SCP” should be spelled out.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
The specification is objected to as failing to provide proper antecedent basis for the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the following is required:
The examiner has carefully considered the applicant’s originally filed specification and respectfully notes that it fails to provide proper antecedent basis for the recitations added by claim 14. Furthermore, the applicant has not shown support for those features.
For example, the independent claim 14 essentially recite that “receiving a third notification, from the second SCP, specifying that the RIvBMC is ready to execute on a second microvisor of the second IHS”. Specification disclosed that the execution environment for the RIvVMC is the second SCP, not a microvisor (See specification; para 0021 and 0266 and see figures 2.1 and 3.3 – 3.4). The examiner points out that there is no disclosure of the vBMC is running on a microvisor within the specification nor is such shown within the applicant's drawings.
Thus, the specification fails to provide antecedent basis for the claim recitations. Furthermore, the applicant has not pointed out where the claim is supported, thus failing to enable a reasonable interpretation of the claims.
Claim Objections
Claims 1 – 20 are objected to because of the following informalities:
Regarding claims 1, 14 and 20, there appears to be a typographical error “an LCS” of -- a LCS -- in line 2 of claims 1, 14 and 20 and further, the limitation “the portion of the LCS” in line 17 lacks proper antecedent basis.
Claims 2 – 13 and 15 - 19 are dependent claims and thus also objected.
Regarding claims 2 and 15, the limitation “the determination” lacks proper antecedent basis because there are multiple determination steps cited earlier in the claims i.e., “a determination that the vBMC could not manage at least the portion of the LCS” in claims 1 and 14 and “a determination that the AMRDR is within a memory resource deployment policy limit” in claims 2 and 15.
Regarding claim 16, the limitation “the microvisor” lacks proper antecedent basis because there are multiple citations earlier in the claims i.e., a microvisor and a second microvisor.
Regarding claim 20, the limitation “the required amount of hardware resources” lack proper antecedent basis.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 14 - 19 are rejected under 35 U.S.C. 112, first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 14, the claim recites “receiving a third notification, from the second SCP, specifying that the RIvBMC is ready to execute on a second microvisor of the second IHS. However, the execution environment for the RIvVMC is the second SCP, not a microvisor (See specification; para 0021 and 0266 and see figures 2.1 and 3.3 – 3.4). The examiner points out that there is no disclosure of the vBMC is running on a microvisor within the specification nor is such shown within the applicant's drawings.
Therefore, the specification as originally filed does not provide support for the claim.
Claims 15 - 19 are dependent claims and thus also rejected.
For the purpose of the following rejection, the claim is being treated on its merit.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1 - 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by HUANG (US 2017/0206110 A1) (hereinafter “HUANG”).
HUANG disclose;
Regarding claim 1, a method for managing a logically composed system (LCS), comprising:
sending a request to a microvisor kernel (MK) of a microvisor [i.e., BMC Virtualization layer 10A (see figure 2A)] to provision an LCS [i.e., virtual machine VBMC 11 – 13 (see figure 2A), (page 3, para 0030) i.e., each of the first virtual machines VBMC 11 – VBMC 13 represents a virtual embodiment of the BMC system for one of the physical computer devices 130A – 130C (page 3, para 0030), (see figure 2A) Note; virtualized BMC instances on management devices] on a first information handling system (IHS) [i.e., first management device 110 (see figure 1), (page 2, para 0027), (page 3, para 0030)], wherein the request comprises a configuration template (CT) [i.e., the BMC module 10 will allocate hardware resources i.e., processing power, memory storage, and/or access to communication module to the virtual machines (page 3, para 0031), (see figure 2A)], wherein the microvisor executes on the first IHS to provision a plurality of LCSs comprising the LCS [i.e., BMC Virtualization layer 10A (see figure 2A) i.e., the VMC module 10 will create a corresponding virtual machine (ex. Virtual machine VBMC 11 – VBMC 13) (page 3, para 0031)];
initiating provisioning of the LCS based on the CT [i.e., the VMC module 10 will create a corresponding virtual machine (ex. Virtual machine VBMC 11 – VBMC 13) (page 3, para 0031)], wherein the provisioning of the LCS comprises an initiation of a guest basic input/output system (BIOS) of the LCS [i.e., provisioning VBMCs by creating virtual machine instances that emulate BMC hardware (page 3, para 0031), (see figure 2) Note; the provisioning must include BIOS-level initialization routines typical for virtualized management controller];
receiving a notification, from the MK, specifying that the LCS has been provisioned [i.e., after the VBMC services are created, they report their status back to the management system (page 4, para 0037 – 0038), (see figure 3B)];
after the notification has been received: sending a second request to a system control processor (SCP) of the first IHS to generate a virtual baseboard management controller (vBMC) on the first IHS, wherein the vBMC is configured to manage at least a portion of the LCS [i.e., the base BMC will create VBMC services for each active…physical computer devices (page 4, para 0037), (see figures 3A – 3B)];
receiving a second notification, from the SCP, specifying that the vBMC is generated on the SCP [i.e., after the VBMC services are created, they report their status back to the management system (page 4, para 0037 – 0038), (see figure 3B)];
after the second notification has been received: making a determination that the vBMC could not manage at least the portion of the LCS [i.e., cross-monitoring detects malfunctioning BMC units (page 2, para 0027) i.e., device inactive or “non-active…power off…(page 4, para 0038) i.e., failure of masters/slave management devices (page 4, para 0041)];
obtaining, based on the determination, first metadata (FM) associated with a second IHS and second metadata (SM) associated with a third IHS [i.e., retrieving status and resource information from multiple management nodes and their connected physical devices (page 4, para 0037 - 0038), (page 2, para 0027), (page 5, para 0043)];
analyzing the FM and the SM to extract relevant data, wherein the relevant data comprises first information in relation to a first hardware resource set (HRS) of the second IHS and second information in relation to a second HRS of the third IHS [i.e., master device check if other nodes are able to accommodate the processes…evaluate loading balance and hardware sufficiency (page 5, para 0043) i.e., determines whether another device can accommodate running the virtual machine (page 5, para 0044)];
inferring, based on the relevant data, that the second IHS has at least a required amount of hardware resources to execute a runtime instance of the vBMC (RIvBMC) [i.e., master device checks whether another management device is able to accommodate processes running on the failing node…if so, initiates migration of VBMC to that node (page 5, para 0043 – 0044), (see figures 5A – 5B)];
sending, in response to the inferring, a third request to a second SCP of the second IHS to execute the RIvBMC [i.e., the master device instruct the slave management device…to create a virtual machine X (page 5, para 0044), (see figures 5A – 5B)];
receiving a third notification, from the second SCP, specifying that the RIvBMC is ready to execute on the second SCP [i.e., the system proceeds with migration…the new VM is considered active and ready…the original VM is then deallocated and deleted (page 5, para 0044)];
upon receiving the third notification, generating a secure data transfer path between the vBMC and the RIvBMC, wherein the vBMC and the RIvBMC communicate over the secure data transfer path [i.e., forwarding communication between VBMC and remote nodes by master/slave forwarding modules (page 5, para 0044), (see figure 5B) i.e., forwarder (see figure 4) Note a secure forwarding path]; and
initiating a display notification of an administrator about the RIvBMC using a graphical user interface (GUI) [i.e., notifying administrators of failure (page 2, para 0027) i.e., providing GUI/Web UI monitoring dashboards (page 2, para 0025)].
Regarding claim 2, the method of claim 1, further comprising:
after receiving the third notification from the second SCP: receiving an additional memory resource deployment request (AMRDR) from the runtime instance of the vBMC [i.e., the BMC module 10 will allocate hardware resources i.e., processing power, memory storage, and/or access to communication module to the virtual machines (page 3, para 0031), (see figure 2A)], wherein the AMRDR has been received by the runtime instance of the vBMC, via the secure data transfer path, from the LCS [i.e., forwarding communication between VBMC and remote nodes by master/slave forwarding modules (page 5, para 0044), (see figure 5B)];
making a determination that the AMRDR is within a memory resource deployment policy limit [i.e., cross-monitoring detects malfunctioning BMC units (page 2, para 0027) i.e., device inactive or “non-active…power off…(page 4, para 0038) i.e., failure of masters/slave management devices (page 4, para 0041)];
sending, based on the determination, a confirmation in relation to the AMRDR to the runtime instance of the vBMC [i.e., retrieving status and resource information from multiple management nodes and their connected physical devices (page 4, para 0037 - 0038), (page 2, para 0027), (page 5, para 0043)]; and
deploying an additional memory resource to the LCS [i.e., the BMC module 10 will allocate hardware resources i.e., processing power, memory storage, and/or access to communication module to the virtual machines (page 3, para 0031), (see figure 2A) i.e., resource allocator (see figurer 4)].
Regarding claim 3, the method of claim 1, wherein the secure data transfer path utilizes a tunneling protocol [i.e., forwarding communication between VBMC and remote nodes by master/slave forwarding modules (page 5, para 0044), (see figure 5B) i.e., forwarder (see figure 4) Note a secure forwarding path].
Regarding claim 4, the method of claim 1, wherein, prior to sending the second notification, the SCP receives a cybersecurity attestation in relation to the vBMC from the microvisor, wherein the cybersecurity attestation specifies at least a security status of the vBMC [i.e., the base BMC will create VBMC services for each active…physical computer devices (page 4, para 0037), (see figures 3A – 3B)].
Regarding claim 5, the method of claim 1, wherein a physical BMC of the first IHS is not aware of the vBMC executing on the SCP of the first IHS and of the LCS, wherein the physical BMC of the first IHS is not aware of the microvisor and the runtime instance of the vBMC executing on the second SCP of the second IHS [i.e., master device checks whether another management device is able to accommodate processes running on the failing node…if so, initiates migration of VBMC to that node (page 5, para 0043 – 0044), (see figures 5A – 5B)], wherein the LCS is not aware of the physical BMC of the first IHS and of the runtime instance of the vBMC, and wherein the vBMC is logically separated from hardware and software resources of the LCS [i.e., device inactive or “non-active…power off…(page 4, para 0038) i.e., failure of masters/slave management devices (page 4, para 0041)].
Regarding claim 6, the method of claim 1, further comprising:
prior to sending the CT to the MK: sending a fourth request to a processor of the first IHS to initiate the microvisor, wherein, upon receiving the fourth request, the processor initiates the microvisor via a BIOS microvisor loader [i.e., the master device instruct the slave management device…to create a virtual machine X (page 5, para 0044), (see figures 5A – 5B)].
Regarding claim 7, the method of claim 6, further comprising:
prior to sending the fourth request: receiving a vendor key that is assigned to the first IHS from the processor to initiate a bi-directional trust establishment process [i.e., the base BMC will create VBMC services for each active…physical computer devices (page 4, para 0037), (see figures 3A – 3B)];
in response to receiving the vendor key, sending a second vendor key to the processor to complete bi-directional trust establishment process [i.e., BMC Virtualization layer 10A (see figure 2A) i.e., the VMC module 10 will create a corresponding virtual machine (ex. Virtual machine VBMC 11 – VBMC 13) (page 3, para 0031)]; and
notifying the administrator about the completed bi-directional trust establishment process, wherein the bi-directional trust establishment process is required in order to allow the processor of the first IHS to initiate the microvisor [i.e., the master device instruct the slave management device…to create a virtual machine X (page 5, para 0044), (see figures 5A – 5B)].
Regarding claim 8, the method of claim 1, wherein the CT specifies at least one HRS, wherein the at least one HRS comprises: a third HRS of a third IHS; a fourth HRS of a fourth IHS; and a fifth HRS of an external resource, wherein the first IHS, the third IHS, and the fourth IHS are distinct devices operably connected to each other and the external resource over a network [i.e., the physical devices 130A – 130F (see figure 1), (page 1, para 0022)].
Regarding claim 9, the method of claim 8, wherein the third HRS specifies at least one selected from a group consisting of an LCS hardware virtualization configuration [i.e., virtual machine VBMC 11 – 13 (see figure 2A), (page 3, para 0030) i.e., each of the first virtual machines VBMC 11 – VBMC 13 represents a virtual embodiment of the BMC system for one of the physical computer devices 130A – 130C (page 3, para 0030), (see figure 2A)].
Regarding claim 10, the method of claim 8, wherein the fourth HRS specifies at least one selected from a group consisting of a swap space configuration per-LCS [i.e., virtual machine VBMC 11 – 13 (see figure 2A), (page 3, para 0030) i.e., each of the first virtual machines VBMC 11 – VBMC 13 represents a virtual embodiment of the BMC system for one of the physical computer devices 130A – 130C (page 3, para 0030), (see figure 2A)].
Regarding claim 11, the method of claim 8, wherein the fifth HRS specifies at least one selected from a group consisting of a type of a GPU virtualization approach that needs to be implemented [i.e., virtual machine VBMC 11 – 13 (see figure 2A), (page 3, para 0030) i.e., each of the first virtual machines VBMC 11 – VBMC 13 represents a virtual embodiment of the BMC system for one of the physical computer devices 130A – 130C (page 3, para 0030), (see figure 2A)].
Regarding claim 12, the method of claim 8, wherein the third HRS comprises hardware resources that are distinct from hardware resources of the fourth hardware resource set [i.e., the BMC module 10 will allocate hardware resources i.e., processing power, memory storage, and/or access to communication module to the virtual machines (page 3, para 0031), (see figure 2A)].
Regarding claim 13, the method of claim 1, wherein the runtime instance of the vBMC is a proxy variant of the vBMC, wherein, when the LCS sends an inquiry to the vBMC, the runtime instance of the vBMC analyzes the inquiry and sends a response, via the secure data transfer path, to the LCS in relation to the inquiry on behalf of the vBMC, and wherein the vBMC is external to a physical BMC of the first HIS [i.e., master device checks whether another management device is able to accommodate processes running on the failing node…if so, initiates migration of VBMC to that node (page 5, para 0043 – 0044), (see figures 5A – 5B)].
Regarding claim 14, a method for managing a logically composed system (LCS), comprising:
sending a request to a microvisor kernel (MK) of a microvisor [i.e., BMC Virtualization layer 10A (see figure 2A)] to provision an LCS [i.e., virtual machine VBMC 11 – 13 (see figure 2A), (page 3, para 0030) i.e., each of the first virtual machines VBMC 11 – VBMC 13 represents a virtual embodiment of the BMC system for one of the physical computer devices 130A – 130C (page 3, para 0030), (see figure 2A) Note; virtualized BMC instances on management devices] on a first information handling system (IHS) [i.e., first management device 110 (see figure 1), (page 2, para 0027), (page 3, para 0030)], wherein the request comprises a configuration template (CT) [i.e., the BMC module 10 will allocate hardware resources i.e., processing power, memory storage, and/or access to communication module to the virtual machines (page 3, para 0031), (see figure 2A)], wherein the microvisor executes on the first IHS to provision a plurality of LCSs comprising the LCS [i.e., BMC Virtualization layer 10A (see figure 2A) i.e., the VMC module 10 will create a corresponding virtual machine (ex. Virtual machine VBMC 11 – VBMC 13) (page 3, para 0031)];
initiating provisioning of the LCS based on the CT [i.e., the VMC module 10 will create a corresponding virtual machine (ex. Virtual machine VBMC 11 – VBMC 13) (page 3, para 0031)], wherein the provisioning of the LCS comprises an initiation of a guest basic input/output system (BIOS) of the LCS [i.e., provisioning VBMCs by creating virtual machine instances that emulate BMC hardware (page 3, para 0031), (see figure 2) Note; the provisioning must include BIOS-level initialization routines typical for virtualized management controller];
receiving a notification, from the MK, specifying that the LCS has been provisioned [i.e., after the VBMC services are created, they report their status back to the management system (page 4, para 0037 – 0038), (see figure 3B)];
after the notification has been received: sending a second request to a system control processor (SCP) of the first IHS to generate a virtual baseboard management controller (vBMC) on the first IHS;
receiving a second notification, from the SCP, specifying that the vBMC is generated on the SCP [i.e., after the VBMC services are created, they report their status back to the management system (page 4, para 0037 – 0038), (see figure 3B)];
after the second notification has been received: making a determination that the vBMC could not manage at least the portion of the LCS [i.e., cross-monitoring detects malfunctioning BMC units (page 2, para 0027) i.e., device inactive or “non-active…power off…(page 4, para 0038) i.e., failure of masters/slave management devices (page 4, para 0041)];
obtaining, based on the determination, first metadata (FM) associated with a second IHS and second metadata (SM) associated with a third IHS [i.e., retrieving status and resource information from multiple management nodes and their connected physical devices (page 4, para 0037 - 0038), (page 2, para 0027), (page 5, para 0043)];
analyzing the FM and the SM to extract relevant data, wherein the relevant data comprises first information in relation to a first hardware resource set (HRS) of the second IHS and second information in relation to a second HRS of the third IHS [i.e., master device check if other nodes are able to accommodate the processes…evaluate loading balance and hardware sufficiency (page 5, para 0043) i.e., determines whether another device can accommodate running the virtual machine (page 5, para 0044)];
inferring, based on the relevant data, that the second IHS has at least a required amount of hardware resources to execute a runtime instance of the vBMC (RIvBMC) [i.e., master device checks whether another management device is able to accommodate processes running on the failing node…if so, initiates migration of VBMC to that node (page 5, para 0043 – 0044), (see figures 5A – 5B)];
sending, in response to the inferring, a third request to a second SCP of the second IHS to execute the RIvBMC [i.e., the master device instruct the slave management device…to create a virtual machine X (page 5, para 0044), (see figures 5A – 5B)];
receiving a third notification, from the second SCP, specifying that the RIvBMC is ready to execute on a second microvisor of the second IHS [i.e., the system proceeds with migration…the new VM is considered active and ready…the original VM is then deallocated and deleted (page 5, para 0044)];
upon receiving the third notification, generating a secure data transfer path between the vBMC and the RIvBMC, wherein the vBMC and the RIvBMC communicate over the secure data transfer path [i.e., forwarding communication between VBMC and remote nodes by master/slave forwarding modules (page 5, para 0044), (see figure 5B) i.e., forwarder (see figure 4) Note a secure forwarding path]; and
initiating a display notification of an administrator about the RIvBMC using a graphical user interface (GUI) [i.e., notifying administrators of failure (page 2, para 0027) i.e., providing GUI/Web UI monitoring dashboards (page 2, para 0025)].
Regarding claim 15, the method of claim 14, further comprising:
after receiving the third notification from the second SCP: receiving an additional memory resource deployment request (AMRDR) from the runtime instance of the vBMC [i.e., the BMC module 10 will allocate hardware resources i.e., processing power, memory storage, and/or access to communication module to the virtual machines (page 3, para 0031), (see figure 2A)], wherein the AMRDR has been received by the runtime instance of the vBMC, via the secure data transfer path, from the LCS [i.e., forwarding communication between VBMC and remote nodes by master/slave forwarding modules (page 5, para 0044), (see figure 5B)];
making a determination that the AMRDR is within a memory resource deployment policy limit [i.e., cross-monitoring detects malfunctioning BMC units (page 2, para 0027) i.e., device inactive or “non-active…power off…(page 4, para 0038) i.e., failure of masters/slave management devices (page 4, para 0041)];
sending, based on the determination, a confirmation in relation to the AMRDR to the runtime instance of the vBMC [i.e., retrieving status and resource information from multiple management nodes and their connected physical devices (page 4, para 0037 - 0038), (page 2, para 0027), (page 5, para 0043)]; and
deploying an additional memory resource to the LCS [i.e., the BMC module 10 will allocate hardware resources i.e., processing power, memory storage, and/or access to communication module to the virtual machines (page 3, para 0031), (see figure 2A) i.e., resource allocator (see figurer 4)].
Regarding claim 16, the method of claim 14, wherein a physical BMC of the first IHS is not aware of the vBMC executing on the microvisor and of the LCS, wherein the physical BMC of the first IHS is not aware of the microvisor and the runtime instance of the vBMC executing on the second SCP of the second IHS [i.e., master device checks whether another management device is able to accommodate processes running on the failing node…if so, initiates migration of VBMC to that node (page 5, para 0043 – 0044), (see figures 5A – 5B)], wherein the LCS is not aware of the physical BMC of the first IHS and of the runtime instance of the vBMC, and wherein the vBMC is logically separated from hardware and software resources of the LCS [i.e., device inactive or “non-active…power off…(page 4, para 0038) i.e., failure of masters/slave management devices (page 4, para 0041)].
Regarding claim 17, the method of claim 14, wherein the CT specifies at least one HRS, wherein the at least one HRS comprises: a third HRS of a third IHS; a fourth HRS of a fourth IHS; and a fifth HRS of an external resource, wherein the first IHS, the third IHS, and the fourth IHS are distinct devices operably connected to each other and the external resource over a network [i.e., the physical devices 130A – 130F (see figure 1), (page 1, para 0022)].
Regarding claim 18, the method of claim 17, wherein the third HRS specifies at least one selected from a group consisting of an LCS hardware virtualization configuration [i.e., virtual machine VBMC 11 – 13 (see figure 2A), (page 3, para 0030) i.e., each of the first virtual machines VBMC 11 – VBMC 13 represents a virtual embodiment of the BMC system for one of the physical computer devices 130A – 130C (page 3, para 0030), (see figure 2A)].
Regarding claim 19, the method of claim 17, wherein the fourth HRS specifies at least one selected from a group consisting of a swap space configuration per-LCS [i.e., virtual machine VBMC 11 – 13 (see figure 2A), (page 3, para 0030) i.e., each of the first virtual machines VBMC 11 – VBMC 13 represents a virtual embodiment of the BMC system for one of the physical computer devices 130A – 130C (page 3, para 0030), (see figure 2A)].
Regarding claim 20, a method for managing a logically composed system (LCS), comprising:
sending a request to a microvisor kernel (MK) of a microvisor [i.e., BMC Virtualization layer 10A (see figure 2A)] to provision an LCS [i.e., virtual machine VBMC 11 – 13 (see figure 2A), (page 3, para 0030) i.e., each of the first virtual machines VBMC 11 – VBMC 13 represents a virtual embodiment of the BMC system for one of the physical computer devices 130A – 130C (page 3, para 0030), (see figure 2A) Note; virtualized BMC instances on management devices] on a first information handling system (IHS) [i.e., first management device 110 (see figure 1), (page 2, para 0027), (page 3, para 0030)], wherein the request comprises a configuration template (CT) [i.e., the BMC module 10 will allocate hardware resources i.e., processing power, memory storage, and/or access to communication module to the virtual machines (page 3, para 0031), (see figure 2A)], wherein the microvisor executes on the first IHS to provision a plurality of LCSs comprising the LCS [i.e., BMC Virtualization layer 10A (see figure 2A) i.e., the VMC module 10 will create a corresponding virtual machine (ex. Virtual machine VBMC 11 – VBMC 13) (page 3, para 0031)];
initiating provisioning of the LCS based on the CT [i.e., the VMC module 10 will create a corresponding virtual machine (ex. Virtual machine VBMC 11 – VBMC 13) (page 3, para 0031)], wherein the provisioning of the LCS comprises an initiation of a guest basic input/output system (BIOS) of the LCS [i.e., provisioning VBMCs by creating virtual machine instances that emulate BMC hardware (page 3, para 0031), (see figure 2) Note; the provisioning must include BIOS-level initialization routines typical for virtualized management controller];
receiving a notification, from the MK, specifying that the LCS has been provisioned [i.e., after the VBMC services are created, they report their status back to the management system (page 4, para 0037 – 0038), (see figure 3B)];
after the notification has been received: obtaining first metadata associated with the first IHS and second metadata associated with a second IHS [i.e., retrieving status and resource information from multiple management nodes and their connected physical devices (page 4, para 0037 - 0038), (page 2, para 0027), (page 5, para 0043)];
analyzing the first metadata and the second metadata to extract relevant data, wherein the relevant data comprises at least first information in relation to a first hardware resource set of the first IHS and second information in relation to a second hardware resource set of the second IHS [i.e., master device check if other nodes are able to accommodate the processes…evaluate loading balance and hardware sufficiency (page 5, para 0043) i.e., determines whether another device can accommodate running the virtual machine (page 5, para 0044)];
inferring, based on the relevant data, that the first IHS has at least the required amount of hardware resources to execute a virtual baseboard management controller (vBMC) associated with the first IHS [i.e., master device checks whether another management device is able to accommodate processes running on the failing node…if so, initiates migration of VBMC to that node (page 5, para 0043 – 0044), (see figures 5A – 5B)];
sending, based on the inferring, a second request to a system control processor (SCP) of the first IHS to generate the vBMC on the first IHS [i.e., the master device instruct the slave management device…to create a virtual machine X (page 5, para 0044), (see figures 5A – 5B)];
receiving a second notification, from the SCP, specifying that the vBMC is generated on the SCP and is ready to interact with the LCS [i.e., the system proceeds with migration…the new VM is considered active and ready…the original VM is then deallocated and deleted (page 5, para 0044)]; and
upon receiving the second notification, initiating a display notification of an administrator about the vBMC using a graphical user interface (GUI) [i.e., notifying administrators of failure (page 2, para 0027) i.e., providing GUI/Web UI monitoring dashboards (page 2, para 0025)].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chawla (US 2022/0179718 A1) discloses obtaining, by a system control processor, a composition request for a composed information handling system; making a first determination that a first information handling system is not capable of servicing the composition request locally; and based on the first determination: allocating, an available resource on the first information handling system to the composed information handling system; sending a resource allocation request to a system control processor manager for access to an additional resource; obtain, in response to the allocation request, a notification for access to a second information handling system of the information handling systems that provides the available resource; setting up management services for available resource and the additional resource to obtain logical hardware resources; and presenting the logical hardware resources to at least one compute resource set as bare metal resources, wherein the first information handling system comprises the system control processor and the at least one compute resource set.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED A RONI whose telephone number is (571)270-7806. The examiner can normally be reached M-F 9:00-5:00 pm (EST).
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/SYED A RONI/Primary Examiner, Art Unit 2432