DETAILED ACTION
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 .
This office action is in response to applicant’s amendment filed on 12/16/2025.
Claims 1-20 are pending and examined.
Response to Arguments
Applicant's arguments filed 12/16/2025, with respect to 35 U.S.C. 103 have been fully considered but they are not persuasive. Applicant argued that the examiner’s interpretation of Merkin is self-conflicting due to citing Merkin to address the limitation of "in response to determining the dynamic sensor tables are updated in the current sensor monitor cycle, update the SDR and the sensor information of the at least one dynamic sensor to the IPMI stack based on the updated dynamic sensor tables, and start the subsequent sensor monitor cycle to monitor the updated sensors” while also acknowledging that “Merkin does not explicitly teach wherein the storage device stores an IPMI stack.” Examiner respectfully disagrees, see the 103 rejections below for a detailed analysis. Examiner interprets the limitation of “in response to determining the dynamic sensor tables are updated in the current sensor monitor cycle, update the SDR and the sensor information of the at least one dynamic sensor to the IPMI stack based on the updated dynamic sensor tables, and start the subsequent sensor monitor cycle to monitor the updated sensors” to be a different limitation of “wherein the storage device stores an IPMI stack,” as one limitation involves where the IPMI stack is stored and the other involves the contents of the IPMI stack. Therefore, it is not self-conflicting for Merkin to teach one of the limitations and not explicitly teach the other limitation. The applicant further argues that “Nowhere in Merkin teaches or suggest the limitation of "in response to detecting the entity presence sensor event, update the sensors to be monitored based on the entity presence sensor event by updating a sensor data repository (SDR) and sensor information of the at least one dynamic sensor according to the entity presence sensor event, and updating the dynamic sensor tables, without updating the SDR and the sensor information of the at least one dynamic sensor to the IPMI stack in a current sensor monitor cycle" as recited in amended claim 1.” Examiner interprets Merkin to teach the amended limitation as shown below. Checking that all the physical sensors are associated with virtual sensors and cycling through steps 52 to 62 of Merkin to make sure new physical sensors are not added to the system correlates to the current sensor monitor cycle being completed. The management controller, which is part of the system operating under the IPMI specification, further modifying the SDR after the cycle is complete therefore correlates to not updating the SDR and sensor information for at least one dynamic sensor to the IPMI stack in the current sensor monitor cycle as the cycle has already been completed.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
Claim(s) 1-6, 9-14, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable by Merkin et al. (U.S. Patent No. US 20040254767 A1), hereinafter “Merkin” in view of Rao et al. (U.S. Patent No. US 20160246754 A1), hereinafter “Rao” and Lambert et al. (U.S. Patent No. US 20240012779 A1), hereinafter “Lambert.”
With regards to Claim 1, Merkin teaches:
A system, comprising:
a baseboard management controller (BMC), comprising a processor and a storage device (Paragraphs 23-24, “information handling system 10 may further include respective software components and hardware components, such as processor 24 and memory 26. Management controller 12 is a micro-controller and may be the baseboard management controller ("BMC") when information handling system 10 is operating under the IPMI specification. Management controller 12 is awake at all times and therefore available in-band when an operating system is running and when the BIOS is booting and also available out-of-band.” The information handling system including a processor, memory, and baseboard management controller correlates to a system comprising a baseboard management controller comprising a processor and storage device),
wherein the storage device stores computer executable code, wherein the computer executable code is configured to, when executed at the processor (Paragraph 22, “an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price.” The information handling system being able to store and compute any form of information or data through a device containing a processor and memory correlates to the storage device storing computer executable code that can be executed by the processor):
initiate a plurality of dynamic sensor tables (Paragraphs 30 and 33, “Each physical sensor 28 also includes a sensor data record ("SDR"). The SDR is a data record that provides information regarding physical sensors 28 such as sensor type, sensor location, event generation, access information, sensor threshold support, and information on what types of readings the sensor provides… Each virtual sensor 32 within virtual sensor repository 30 is a memory or storage location that has been portioned out by management controller 12. Each virtual sensor 32, or memory location, is large enough to hold a sensor value from one of physical sensors 28. Virtual sensor repository 30 further includes event log 34, a non-volatile storage area, which stores non-current or historical sensor values for physical sensors 28 for later retrieval. Event log 34 provides historical performance information in the event of a malfunction or error with information handling system 10.” The SDR and virtual sensor repository for each physical or virtual sensor correlates to initiating a plurality of dynamic sensor tables);
in each of a plurality of sensor monitor cycles:
monitor a plurality of sensors to be monitored, in order to get sensor reading information from each of the sensors (Paragraphs 27 and 42, “Physical sensors 28 may be linear, non-linear, discrete, or threshold sensors… Once physical sensors 28 have been associated with virtual sensors 32, at step 64 management controller begins automatically and periodically obtaining sensor values from physical sensors 28 associated with virtual sensors 32.” The management controller automatically and periodically obtaining sensor values from physical sensors correlates to monitoring a plurality of sensors to get sensor reading information from each sensor);
and in response to detecting the entity presence sensor event, update the sensors to be monitored based on the entity presence sensor event by updating a sensor data repository (SDR) and sensor information of the at least one dynamic sensor according to the entity presence sensor event (Fig. 2, paragraphs 37-38, “When associating physical sensors 28 to virtual sensors 32, management controller 12 assigns a range of storage to virtual sensors 32 to hold the sensor values for the associated physical sensors 28. … Once physical sensor 28 has been associated virtual sensor 32 within virtual sensor repository 30, at step 60 management controller 12 modifies or updates the SDR for physical sensor 28 to include an indication that physical sensor 28 is associated with one or more virtual sensors 32.” The management controller assigning a range of storage to virtual sensors to hold sensor values for the physical sensors when associating physical sensors to virtual sensors correlates to updating the sensors to be monitored and sensor information of at least one dynamic sensor according to the entity presence sensor event. The management controller updating the SDR for the physical sensor to indicate it is associated with one or more virtual sensors correlates to updating the sensors to be monitored by updating the SDR of at least one dynamic sensor according to the entity presence sensor event), and updating the dynamic sensor tables, (Fig. 2, paragraphs 35 and 38, “When agent 16 requests use of one of virtual sensors 32 from management controller 12, management controller 12 at step 54 checks virtual sensor repository 30 to determine if there are any available virtual sensors 32 to associate with physical sensor 28e at step 54… Once physical sensor 28 has been associated virtual sensor 32 within virtual sensor repository 30.” The virtual sensor repository being updated after the physical sensor is associated with the virtual sensor correlates to updating the dynamic sensor tables) without updating the SDR and the sensor information of the at least one dynamic sensor to the IPMI stack in a current sensor monitor cycle (Paragraphs 24 and 39-40, “Management controller 12 is a micro-controller and may be the baseboard management controller ("BMC") when information handling system 10 is operating under the IPMI specification… Once all physical sensors 28 are associated with virtual sensors 32, step 52 through step 62 do not have to repeated unless a new physical sensor is added to information handling system 10 or if the association between physical sensors 28 and virtual sensors 32 changes for any reason… Management controller 12 further modifies the SDR for each of physical sensors 28a, 28b, and 28c to include the indicator that physical sensors 28a, 28b, and 28c are associated with virtual sensors 32a, 32b, and 32c, respectively… For physical sensors 28a, 28b, and 28c within the control of management controller 12, management controller 12 checks for available virtual sensors 32 and if there are available virtual sensors 32, associates physical sensors 28a, 28b, and 28c with virtual sensors 32a, 32b, and 32c, respectively in the same process as described above for physical sensors 28d and 28e.” Checking that all the physical sensors are associated with virtual sensors and cycling through steps 52 to 62 to make sure new physical sensors are not added to the system correlates to the current sensor monitor cycle being completed. The management controller, which is part of the system operating under the IPMI specification, further modifying the SDR after the cycle is complete for each physical sensor to indicate their association with virtual sensors correlates to not updating the SDR and sensor information for at least one dynamic sensor to the IPMI stack in the current sensor monitor cycle);
in response to determining that the current sensor monitor cycle of the sensor monitor cycles is completed, determine whether the dynamic sensor tables are updated in the current sensor monitor cycle (Paragraphs 39-40, “Once all physical sensors 28 are associated with virtual sensors 32, step 52 through step 62 do not have to repeated unless a new physical sensor is added to information handling system 10 or if the association between physical sensors 28 and virtual sensors 32 changes for any reason… For physical sensors 28a, 28b, and 28c within the control of management controller 12, management controller 12 checks for available virtual sensors 32 and if there are available virtual sensors 32, associates physical sensors 28a, 28b, and 28c with virtual sensors 32a, 32b, and 32c, respectively in the same process as described above for physical sensors 28d and 28e.” Checking that all the physical sensors are associated with virtual sensors and cycling through steps 52 to 62 to make sure new physical sensors are not added to the system correlates to determining the current sensor monitor cycle is completed. The management controller checking available virtual sensors that are not associated with physical sensors by checking the updated virtual sensor repository correlates to determining whether the dynamic sensor tables are updated in the current sensor monitor cycle);
in response to determining the dynamic sensor tables are not updated in the current sensor monitor cycle, start a subsequent sensor monitor cycle of the sensor monitor cycles immediately to monitor the sensors to be monitored (Fig. 2, paragraphs 38 and 47, “Once physical sensor 28 has been associated virtual sensor 32 within virtual sensor repository 30, at step 60 management controller 12 modifies or updates the SDR for physical sensor 28 to include an indication that physical sensor 28 is associated with one or more virtual sensors 32… When agent 16 issues the command, at step 72 agent 16 checks the SDR for physical sensor 28b to see if there is an indicator within the SDR that physical sensor 28b is associated with one of virtual sensors 32. If there is no indicator at step 74, then the process returns to step 52 so that the physical sensor that is not associated with any virtual sensors 32 may become associated with virtual sensors 32.” The SDR not having updated information on the sensors is related to the virtual sensor repository also not being updated and therefore correlates to the dynamic sensor tables not being updated. The agent checking the SDR for the association between physical and virtual sensors for an indicator and not finding the indicator before returning to step 52 correlates to starting a subsequent sensor monitor cycle immediately to monitor the sensors to be monitored)
and in response to determining the dynamic sensor tables are updated in the current sensor monitor cycle, update the SDR and the sensor information of the at least one dynamic sensor to the IPMI stack based on the updated dynamic sensor tables, and start the subsequent sensor monitor cycle to monitor the updated sensors (Fig. 3, paragraphs 39-40, “Once all physical sensors 28 are associated with virtual sensors 32, step 52 through step 62 do not have to repeated unless a new physical sensor is added to information handling system 10 or if the association between physical sensors 28 and virtual sensors 32 changes for any reason… Management controller 12 further modifies the SDR for each of physical sensors 28a, 28b, and 28c to include the indicator that physical sensors 28a, 28b, and 28c are associated with virtual sensors 32a, 32b, and 32c, respectively.” Checking the virtual sensor repository to make sure all physical sensors are associated with virtual sensors correlates to determining the dynamic sensor tables are updated in the current sensor monitor cycle. The management controller further modifying the SDR, which is a part of the IPMI stack, for each physical sensor to indicate their association with virtual sensors based on the updated virtual sensor repository correlates to updating the SDR and sensor information for at least one dynamic sensor to the IPMI stack based on the updated dynamic sensor tables. The association between physical and virtual sensors changing from the management controller modifying the virtual sensor repository results in steps 52-62 repeating and therefore correlates to starting the subsequent sensor monitor cycle to monitor the updated sensors).
Merkin does not explicitly teach:
wherein the storage device stores an Intelligent Platform Management Interface (IPMI) stack
However, Rao teaches:
wherein the storage device stores an Intelligent Platform Management Interface (IPMI) stack (Paragraph 59, “The systems and methods may also provide increase flexibility by putting the entire complex IPMI stack and all user interfaces in a consolidated tray/sled BMC or chassis level manager, which has plenty of RAM, FLASH, performance, and can leverage platform vendor implementations—all of which make the overall solution less complex.” The BMC’s RAM is a form of storage that stores the entire IPMI stack and all user interfaces correlates to the storage device storing an IPMI stack):
Merkin does not explicitly teach:
determine whether an entity presence sensor event is detected, wherein the entity presence sensor event is related to at least one dynamic sensor to be added to or removed from the sensors to be monitored;
However, Lambert teaches:
determine whether an entity presence sensor event is detected, wherein the entity presence sensor event is related to at least one dynamic sensor to be added to or removed from the sensors to be monitored (Paragraphs 36, 42-43, and 64, “a baseboard management controller (BMC) 510 is made aware/recognizes (110) that a new peripheral device has been being connected to the information handling system 500… the methodology may proceed as typical hot-plug methods to make the peripheral device operational to the host. Depending upon the type of peripheral device, additional actions may be performed as needed to make the peripheral device functionally available… Examples of peripherals may include one or more printers, scanners, input devices, output devices, sensors, and the like.” The BMC being made aware of a new peripheral device, which includes sensors, being connected to the system correlates to determining whether an entity presence sensor event is detected. Making the peripheral device operational to the host correlates to the entity presence sensor event being related to at least one dynamic sensor to be added to the sensors to be monitored);
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Merkin with wherein the storage device stores an Intelligent Platform Management Interface (IPMI) stack as taught by Rao because putting the IPMI stack and all user interfaces on the BMC allows for increased flexibility from leveraging platform vendor implementations, which additionally makes the overall solution less complex (Rao: paragraph 59).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Merkin with determine whether an entity presence sensor event is detected, wherein the entity presence sensor event is related to at least one dynamic sensor to be added to or removed from the sensors to be monitored as taught by Lambert because adding peripheral devices, which include sensors, to the BMC system can improve the customer experience through customizable enablement that does not compromise server uptime (Lambert: paragraphs 29-30).
With regards to Claims 9 and 17, the machine of Claim 1 performs the same steps as the method and manufacture of Claims 9 and 17 respectively, and Claims 9 and 17 are therefore rejected using the same rationale set forth above in the rejection of Claim 1.
With regards to Claim 2, Merkin in view of Rao and Lambert teaches the system of Claim 1 as referenced above.
Lambert further teaches:
The system of claim 1, wherein the at least one dynamic sensor is on a hot- pluggable device to be inserted into or removed from a host computing device communicatively connected to the BMC (Paragraphs 36, 41 and 64, “In one or more embodiments, a baseboard management controller (BMC) 510 is made aware/recognizes (110) that a new peripheral device has been being connected to the information handling system 500… responsive to the peripheral device being determined by the BMC 510 to be supported and hot-pluggable… Examples of peripherals may include one or more printers, scanners, input devices, output devices, sensors, and the like.” The peripheral device, which includes sensors, being hot-pluggable correlates to at least one dynamic sensor on a hot-pluggable device. The peripheral device being connected to the information handling system and alerting the BMC correlates to the hot-pluggable device inserted from the host computing device communicatively connected to the BMC).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Merkin with wherein the at least one dynamic sensor is on a hot- pluggable device to be inserted into or removed from a host computing device communicatively connected to the BMC as taught by Lambert because adding peripheral devices, which include sensors, to the BMC system can improve the customer experience through customizable enablement that does not compromise server uptime. Hot-pluggable devices also allow new peripheral devices to be connected and made available to an information handling system while they are running, where traditional non-hot-plugged peripherals would require a power cycle to begin operation (Lambert: paragraphs 29-30).
With regards to Claim 10, the machine of Claim 2 performs the same steps as the method of Claim 10, and Claim 10 is therefore rejected using the same rationale set forth above in the rejection of Claim 2.
With regards to Claim 3, Merkin in view of Rao and Lambert teaches the system of Claim 2 as referenced above.
Lambert further teaches:
The system of claim 2, wherein the computer executable code is further configured to, when executed at the processor:
detect an insertion event related to the hot-pluggable device to be inserted into the host computing device (Paragraphs 36 and 41, “a baseboard management controller (BMC) 510 is made aware/recognizes (110) that a new peripheral device has been being connected to the information handling system 500… responsive to the peripheral device being determined by the BMC 510 to be supported and hot-pluggable” The BMC recognizing a new hot-pluggable peripheral device is connected to the information handling system corresponds to detecting an insertion event related to the hot-pluggable device inserted into the host computing device); and
in response to detecting the insertion event, determine that the entity presence sensor event related to the at least one dynamic sensor to be added is detected (Fig. 2, paragraphs 41-43, “responsive to the peripheral device being determined by the BMC 510 to be supported and hot-pluggable, the BMC causes (205) the status of the peripheral device to be changed from hidden to unhidden… In one or more embodiments, as a result of the change of status to unhidden, the methodology may proceed as typical hot-plug methods to make the peripheral device operational to the host. Depending upon the type of peripheral device, additional actions may be performed as needed to make the peripheral device functionally available.” The BMC changing the status of the peripheral device from hidden to unhidden in response to the peripheral device being hot-plugged, which makes the peripheral device operational to the host, correlates to determining an entity presence sensor event related to the dynamic sensor to be added in response to detecting the insertion event).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Merkin with detect an insertion event related to the hot-pluggable device to be inserted into the host computing device; and in response to detecting the insertion event, determine that the entity presence sensor event related to the at least one dynamic sensor to be added is detected as taught by Lambert because adding peripheral devices, which include sensors, to the BMC system can improve the customer experience through customizable enablement that does not compromise server uptime. Hot-pluggable devices also allow new peripheral devices to be connected and made available to an information handling system while they are running, where traditional non-hot-plugged peripherals would require a power cycle to begin operation (Lambert: paragraphs 29-30).
With regards to Claim 11, the machine of Claim 3 performs the same steps as the method of Claim 11, and Claim 11 is therefore rejected using the same rationale set forth above in the rejection of Claim 3.
With regards to Claim 4, Merkin in view of Rao and Lambert teaches the system of Claim 2 as referenced above.
Lambert further teaches:
The system of claim 2, wherein the computer executable code is further configured to, when executed at the processor:
detect a removal event related to the hot-pluggable device to be removed from the host computing device (Fig. 4, paragraph 51, “in response to a peripheral device being disconnected from the information handling system that is operating, the intermediary component 515 changes (405) the peripheral device's status to indicate that it is unavailable/removed.” The peripheral device being disconnected from the information handling system and the intermediary component changing the status of the peripheral device to indicate that it is unavailable or removed corresponds to detecting a removal event related to the hot-pluggable device to be removed from the host computing device); and
in response to detecting the removal event, determine that the entity presence sensor event related to the at least one dynamic sensor to be removed is detected (Fig. 4, paragraphs 35 and 51, “It shall be noted that the term “hidden” may be used to mean, for a host operation system, “not present” and “unhidden” to mean “present”… in response to a peripheral device being disconnected from the information handling system that is operating, the intermediary component 515 changes (405) the peripheral device's status to indicate that it is unavailable/removed. In one or more embodiments, the intermediary component may change the status to hidden.” The intermediary component changing the peripheral device’s status to indicate it is removed or unavailable in response to the device being disconnected from the information handling system corresponds to determining the entity presence sensor event related to the dynamic sensor to be removed in response to detecting the removal event).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Merkin with detect a removal event related to the hot-pluggable device to be removed from the host computing device; and in response to detecting the removal event, determine that the entity presence sensor event related to the at least one dynamic sensor to be removed is detected as taught by Lambert because removing peripheral devices, which include sensors, from the BMC system can improve the customer experience through customizable enablement that does not compromise server uptime. The removal of hot-pluggable devices that were previously added to the system does not require restarts of the information handling system and makes the system easier and more convenient to manage for users (Lambert: paragraphs 4-5 and 29-30).
With regards to Claim 12, the machine of Claim 4 performs the same steps as the method of Claim 12, and Claim 12 is therefore rejected using the same rationale set forth above in the rejection of Claim 4.
With regards to Claim 5, Merkin in view of Rao and Lambert teaches the system of Claim 2 as referenced above.
Merkin in view of Rao and Lambert further teaches:
The system of claim 1, wherein the dynamic sensor tables comprise:
a dynamic sensor information table, configured to store the sensor information of the sensors to be monitored (Paragraph 33, “Each virtual sensor 32 within virtual sensor repository 30 is a memory or storage location that has been portioned out by management controller 12. Each virtual sensor 32, or memory location, is large enough to hold a sensor value from one of physical sensors 28. Virtual sensor repository 30 further includes event log 34, a non-volatile storage area, which stores non-current or historical sensor values for physical sensors 28 for later retrieval. Event log 34 provides historical performance information in the event of a malfunction or error with information handling system 10.” The virtual sensor repository which stores sensor information including an event log for historical values correlates to a dynamic sensor information table which stores sensor information of the sensors to be monitored);
a dynamic SDR table, configured to store the SDR of at least one first dynamic sensor to be added to the sensors to be monitored (Paragraph 30, “Each physical sensor 28 also includes a sensor data record ("SDR"). The SDR is a data record that provides information regarding physical sensors 28 such as sensor type, sensor location, event generation, access information, sensor threshold support, and information on what types of readings the sensor provides.” The sensor data record for all physical sensors correlates to a dynamic SDR table to store the SDR of at least one dynamic sensor to be added to the sensors to be monitored);
Merkin does not explicitly teach:
and a dynamic sensor remove table, configured to store a sensor number of at least one second dynamic sensor to be removed from the sensors to be monitored.
However, Lambert teaches:
and a dynamic sensor remove table, configured to store a sensor number of at least one second dynamic sensor to be removed from the sensors to be monitored (Paragraph 35, “It shall be noted that the term “hidden” may be used to mean, for a host operation system, “not present” and “unhidden” to mean “present.” In one or more embodiments, the existence of the peripheral device and its status may be stored in a register or other memory that is maintained or accessible by the intermediary component 515.” The existence of the peripheral device, which includes sensors, being stored in a register or other memory correlates to a dynamic sensor remove table. The status of the peripheral device, which includes if the device is hidden or not present, being stored in a register or other memory is associated with a particular device and therefore has a sensor number identification and correlates to storing a sensor number of at least one dynamic sensor to be removed from the sensors to be monitored).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Merkin with a dynamic sensor remove table, configured to store a sensor number of at least one second dynamic sensor to be removed from the sensors to be monitored as taught by Lambert because a register used to indicate the status of peripheral devices enables the BMC to be made aware of a change in status through an alert from the intermediary component or from the BMC polling for listings of peripheral devices. The alert may be made autonomously when the device is removed, which can minimize host notification latency to start the removal process (Lambert: paragraphs 36 and 60).
With regards to Claims 13 and 18, the machine of Claim 5 performs the same steps as the method and manufacture of Claims 13 and 18 respectively, and Claims 13 and 18 are therefore rejected using the same rationale set forth above in the rejection of Claim 5.
With regards to Claim 6, Merkin in view of Rao and Lambert teaches the system of Claim 5 as referenced above.
Lambert further teaches:
The system of claim 5, wherein the entity presence sensor event is a first entity presence sensor event related to the at least one first dynamic sensor to be added to the sensors to be monitored (Paragraphs 36, 42-43, and 64, “a baseboard management controller (BMC) 510 is made aware/recognizes (110) that a new peripheral device has been being connected to the information handling system 500… the methodology may proceed as typical hot-plug methods to make the peripheral device operational to the host. Depending upon the type of peripheral device, additional actions may be performed as needed to make the peripheral device functionally available… Examples of peripherals may include one or more printers, scanners, input devices, output devices, sensors, and the like.” The BMC being made aware of a new peripheral device, which includes sensors, being connected to the system correlates to the first entity presence sensor event. Making the peripheral device operational to the host correlates to the entity presence sensor event being related to at least one dynamic sensor to be added to the sensors to be monitored), and the computer executable code is configured to, when executed at the processor:
detect the first entity presence sensor event (Paragraphs 36, 42-43, and 64, “a baseboard management controller (BMC) 510 is made aware/recognizes (110) that a new peripheral device has been being connected to the information handling system 500… the methodology may proceed as typical hot-plug methods to make the peripheral device operational to the host. Depending upon the type of peripheral device, additional actions may be performed as needed to make the peripheral device functionally available… Examples of peripherals may include one or more printers, scanners, input devices, output devices, sensors, and the like.” The BMC being made aware of a new peripheral device, which includes sensors, being connected to the system correlates to detecting an entity presence sensor event);
Merkin further teaches:
create the SDR and the sensor information of the at least one first dynamic sensor according to the first entity presence sensor event (Fig. 2, paragraphs 37-38, “When associating physical sensors 28 to virtual sensors 32, management controller 12 assigns a range of storage to virtual sensors 32 to hold the sensor values for the associated physical sensors 28… Once physical sensor 28 has been associated virtual sensor 32 within virtual sensor repository 30, at step 60 management controller 12 modifies or updates the SDR for physical sensor 28 to include an indication that physical sensor 28 is associated with one or more virtual sensors 32.” The management controller assigning a range of storage to virtual sensors to hold sensor values for the physical sensors when associating physical sensors to virtual sensors correlates to updating sensor information of at least one dynamic sensor according to the first entity presence sensor event. The management controller modifying the SDR for the physical sensor to indicate it is associated with one or more virtual sensors correlates to creating the SDR of at least one dynamic sensor according to the entity presence sensor event);
update the dynamic sensor information table to add the sensor information of the at least one first dynamic sensor thereto (Fig. 2, paragraphs 35 and 38, “When agent 16 requests use of one of virtual sensors 32 from management controller 12, management controller 12 at step 54 checks virtual sensor repository 30 to determine if there are any available virtual sensors 32 to associate with physical sensor 28e at step 54… Once physical sensor 28 has been associated virtual sensor 32 within virtual sensor repository 30.” The virtual sensor repository being updated after the physical sensor is associated with the virtual sensor correlates to updating the dynamic sensor information table to add the sensor information of the first dynamic sensor); and
update the dynamic SDR table to add the SDR of the at least one first dynamic sensor thereto (Fig. 3, paragraph 40, “Management controller 12 further modifies the SDR for each of physical sensors 28a, 28b, and 28c to include the indicator that physical sensors 28a, 28b, and 28c are associated with virtual sensors 32a, 32b, and 32c, respectively.” The management controller further modifying the SDR for each physical sensor to indicate their association with virtual sensors correlates to updating the dynamic SDR table to add the SDR for at least one first dynamic sensor).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Merkin with wherein the entity presence sensor event is a first entity presence sensor event related to the at least one first dynamic sensor to be added to the sensors to be monitored, and the computer executable code is configured to, when executed at the processor: detect the first entity presence sensor event as taught by Lambert because adding peripheral devices, which include sensors, to the BMC system can improve the customer experience through customizable enablement that does not compromise server uptime (Lambert: paragraphs 29-30).
With regards to Claims 14 and 19, the machine of Claim 6 performs the same steps as the method and manufacture of Claims 14 and 19 respectively, and Claims 14 and 19 are therefore rejected using the same rationale set forth above in the rejection of Claim 6.
Claim(s) 7, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable by Merkin in view of Rao, Lambert, and Bhatia et al. (U.S. Patent No. US 20220058177 A1), hereinafter “Bhatia.”
With regards to Claim 7, Merkin in view of Rao and Lambert teaches the system of Claim 5 as referenced above.
Lambert further teaches:
The system of claim 5, wherein the entity presence sensor event is a second entity presence sensor event related to the at least one second dynamic sensor to be removed from the sensors to be monitored (Fig. 4, paragraphs 35 and 51, “It shall be noted that the term “hidden” may be used to mean, for a host operation system, “not present” and “unhidden” to mean “present”… in response to a peripheral device being disconnected from the information handling system that is operating, the intermediary component 515 changes (405) the peripheral device's status to indicate that it is unavailable/removed. In one or more embodiments, the intermediary component may change the status to hidden.” The intermediary component changing the peripheral device’s status to indicate it is removed or unavailable in response to the device being disconnected from the information handling system corresponds to the second entity presence sensor event related to the dynamic sensor to be removed from the sensors to be monitored), and the computer executable code is configured to, when executed at the processor:
detect the second entity presence sensor event (Fig. 4, paragraph 51, “in response to a peripheral device being disconnected from the information handling system that is operating, the intermediary component 515 changes (405) the peripheral device's status to indicate that it is unavailable/removed.” The peripheral device being disconnected from the information handling system and the intermediary component changing the status of the peripheral device to indicate that it is unavailable or removed corresponds to detecting a second entity presence sensor event);
and update the dynamic sensor remove table to add the sensor number of the at least one second dynamic sensor thereto (Paragraph 35, “It shall be noted that the term “hidden” may be used to mean, for a host operation system, “not present” and “unhidden” to mean “present.” In one or more embodiments, the existence of the peripheral device and its status may be stored in a register or other memory that is maintained or accessible by the intermediary component 515.” The existence of the peripheral device, which includes sensors, being stored in a register or other memory correlates to a dynamic sensor remove table. The status of the peripheral device, which includes if the device is hidden or not present, being stored and maintained in a register or other memory is associated with a particular device and therefore has a sensor number identification and correlates to updating the dynamic sensor remove table to add a sensor number of at least one dynamic sensor to be removed from the sensors to be monitored).
Bhatia further teaches:
remove the sensor information of the at least one second dynamic sensor according to the second entity presence sensor event (Paragraph 98, “If a sensor is removed from an indicator group, records for the relevant sensor can optionally be removed from the table having the schema 500.” The removal of records from the table for a sensor that is removed correlates to removing the sensor information of at least one second dynamic sensor according to the second entity presence sensor event);
update the dynamic sensor information table to remove the sensor information of the at least one second dynamic sensor therefrom (Paragraph 99, “If a sensor is removed, the relevant column can be dropped from the table having the table schema 550.” The relevant column of a removed sensor being dropped from the table corresponds to updating the dynamic sensor information table to remove the sensor information of the at least one dynamic second sensor);
Bhatia does not explicitly teach that the SDR of the at least one dynamic sensor is removed according to the second entity presence sensor event. However, SDR is a popular sensor information format and is widely utilized in the field of the art, as evidenced by Merkin above.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Merkin with wherein the entity presence sensor event is a second entity presence sensor event related to the at least one second dynamic sensor to be removed from the sensors to be monitored, and the computer executable code is configured to, when executed at the processor: detect the second entity presence sensor event and update the dynamic sensor remove table to add the sensor number of the at least one second dynamic sensor thereto as taught by Lambert because removing peripheral devices, which include sensors, from the BMC system can improve the customer experience through customizable enablement that does not compromise server uptime. The removal of hot-pluggable devices that were previously added to the system does not require restarts of the information handling system and makes the system easier and more convenient to manage for users (Lambert: paragraphs 4-5 and 29-30). Additionally, a register used to indicate the status of peripheral devices enables the BMC to be made aware of a change in status through an alert from the intermediary component or from the BMC polling for listings of peripheral devices. The alert may be made autonomously when the device is removed, which can minimize host notification latency to start the removal process (Lambert: paragraphs 36 and 60).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Merkin with remove the sensor information of the at least one second dynamic sensor according to the second entity presence sensor event and update the dynamic sensor information table to remove the sensor information of the at least one second dynamic sensor therefrom as taught by Bhatia because keeping data only for active sensors can reduce the data to be parsed for processing queries and make queries more efficient (Bhatia: paragraphs 98 and 132).
With regards to Claims 15 and 20, the machine of Claim 7 performs the same steps as the method and manufacture of Claims 15 and 20 respectively, and Claims 15 and 20 are therefore rejected using the same rationale set forth above in the rejection of Claim 7.
Claim(s) 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable by Merkin in view of Rao, Lambert, and Hawkins et al. (U.S. Patent No. US 20040228063 A1), hereinafter “Hawkins.”
With regards to Claim 8, Merkin in view of Rao and Lambert teaches the system of Claim 1 as referenced above.
Merkin in view of Rao and Lambert fails to disclose:
wherein the computer executable code is further configured to, when executed at the processor:
in response to updating the SDR and the sensor information of the at least one dynamic sensor, post an event message in a system event log (SEL).
However, Hawkins teaches:
wherein the computer executable code is further configured to, when executed at the processor:
in response to updating the SDR and the sensor information of the at least one dynamic sensor, post an event message in a system event log (SEL) (Fig. 4, paragraphs 22, 27 and 47, “Event messages encapsulate key event info like sensor type, event type, event transition, and event generator. Event messages are combined with the sensor data records information… The non-volatile storage system may include a central system event log (CSEL) 24, a central sensor data record (CSDR) repository 26… Event messages from sensor devices or management controllers are transmitted to the CSEL 24 for storage… A local event is detected 102 by the LBMC interface 70. For example, the event may be a reading from a sensor 50-53 along with an event type. The information is logged 104 into the LSEL 78 under command of the LBMC interface 70.” The local event being detected as a reading from a sensor along with an event type correlates to an update of the SDR and sensor information of at least one dynamic sensor. The event message encapsulating key event information such as sensor type, sensor data records information, and sensor readings to be sent to the local system event log in response to a local event detected correlates to posting an event message to the SEL in response to updating the SDR and sensor information).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Merkin with wherein the computer executable code is further configured to, when executed at the processor: in response to updating the SDR and the sensor information of the at least one dynamic sensor, post an event message in a system event log (SEL) as taught by Hawkins because event messages sent to the SEL combined with sensor data records information allows for in-depth event analysis and allows the application to identify the entity and field replaceable unit (FRU) that is associated with the event along with the sensor (Hawkins: paragraph 22).
With regards to Claim 16, the machine of Claim 8 performs the same steps as the method of Claim 16, and Claim 16 is therefore rejected using the same rationale set forth above in the rejection of Claim 8.
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Ayanam et al. (U.S. Patent No. US 20140280837 A1); teaching a system of a baseboard management controlled (BMC) managing a plurality of computer nodes through an IPMI configuration. The system comprises a plurality of virtual BMC stacks which communicate with sensors of the managed computer nodes to monitor operation, performance, and health-related aspects of the nodes. The BMC stack can control and collect information of sensors, sensor data record (SDR) devices, and field replaceable units (FRUs). The BMC stack can also provide management functions which include reading system event logs (SEL) remotely.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELINA HU whose telephone number is (571)272-5428. The examiner can normally be reached Monday-Friday 8:30-5:30.
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, Chat Do can be reached at (571) 272-3721. 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.
/SELINA ELISA HU/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193