DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/23/2025 has been entered. Claims 1-18 remain pending in this application.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6, 12, and 18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 6, 12, and 18, they recite a limitation of “wherein the management controller is configured to communicate with the information handling system via an out-of-band management network.” The claims from which claims 6, 12, and 18 depend detail steps for executing a proxy in order for the management controller to process the request relating to the information handling system. Additionally, Fig. 3 depicts two different management embodiments, in-band and out-of-band. As shown in Fig. 3 the in-band management clearly executes the proxy steps that are outlined in the independent claims. However, the out-of-band management embodiment bypasses any proxy steps which allows for direct communication with the management controller which is the embodiment described in claims 6, 12, and 18. Thus, claims 6, 12, and 18 contradict the claim from which they depend in the sense that out-of-band management avoids the need for executing a proxy and allows for direct communication with the management controller.
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, 3, 5-7, 9, 11-13, 15, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Sahu et al. (US Patent No. 10,997,092 B2 hereinafter Sahu) in view of Gore et al. (Us Pub. No. 2019/0379656 A1 hereinafter Gore).
As per claim 1, Sahu teaches a system to receive, from a management server, a request for hardware management functionality relating to a node (Col. 1 & 2, lines 64-67 & 1-17, “The present disclosure relates to large-scale server systems, e.g., storage servers. In currently evolving rack-scale, server-based designs, scalability is achieved through a large quantity of servers laid out horizontally. The servers can be managed using in-band communications, which are communications between server components within a single enclosure (e.g., a host of the server communicating to management controller of the server over keyboard controller style or KCS, interface)…Out-of-band communications relate to the sending of management data outside of the enclosure, e.g., via a network, via a management controller that operates independently of the host. The management controller allows a remote management terminal to monitor and control aspects of the host's operations whether the host is operating or not. The out-of-band communications between the remote management terminal and the management controller may occur over the same network used by the host, or by a different network.” Col. 4, lines 25-47, “In FIG. 2, a sequence diagram depicts a flow from the host to the BMC to retrieve Redfish related data according to an example embodiment. A central node management server 200 is responsible for collating data from various individual servers over the Redfish REST API. The server 200 sends out a Redfish API request 210 to the host 102.”), wherein the functionality is implemented at a management controller of the node (Col. 2, lines 39-53, “The server 100 also includes a BMC 106 that monitors the state of the server 100 independently of the host 102. The BMC 106 may include one or more microcontrollers 110 embedded on a baseboard/motherboard 101 of the server enclosure and manages the communications between system-management software and platform hardware.” Col. 4, lines 17-24, “In this embodiment, the Redfish REST API request is first received by the host 102 via port 120. The request is handled via a Redfish proxy 123 that is coupled to the in-band channel 116. The request gets forwarded to the BMC 106 using in-band channel 116…”), the management controller being configured to communicate with the processor via a data network, wherein the management controller and the data network are isolated from the host network (Col. 3 & 4, lines 58-67 & 1-24, “A peripheral communications channel that exists between the host 102 and the BMC 106 is used as an in-band communications channel for passing Redfish API requests that are received on the host to the BMC. Thus, without any major change in the Redfish Agent monitoring sensors on the BMC 106, Redfish data can be obtained over an in-band communication channel 116, which is also referred to herein as a peripheral communications channel… In this embodiment, the Redfish REST API request is first received by the host 102 via port 120. The request is handled via a Redfish proxy 123 that is coupled to the in-band channel 116. The request gets forwarded to the BMC 106 using in-band channel 116.” See also Fig. 1.) such that the management client cannot communicate directly with the management controller (Col. 3 & 4, lines 58-67 & 1-24, “In this case, Redfish API requests are received via network port 120 on the host when the management Ethernet port 114 is disabled, as indicated by the ‘x’ through the port 114. A peripheral communications channel that exists between the host 102 and the BMC 106 is used as an in-band communications channel for passing Redfish API requests that are received on the host to the BMC.” Col. 4, lines 25-47, “A central node management server 200 is responsible for collating data from various individual servers over the Redfish REST API. The server 200 sends out a Redfish API request 210 to the host 102. A proxy server 208 is running within the host 102 and is responsible for decoding the Redfish HTTP headers and query. The proxy server 208 creating a vendor unique iSCSI OEM packet 212 which can be sent across the USB transport, and decoded accordingly by the BMC stack. The Redfish Agent 118 is a module which waits on the custom-defined Redfish related iSCSI messages, and is responsible for decoding and passing the received request to the Redfish server 118 running on the BMC 106, and sharing the retrieved data back to the host 102 in iSCSI packet format.” See also Fig. 1 which depicts an ‘x’ over the network connecting to the BMC indicating outside devices/servers are unable to directly communicate with the BMC.); and execute a proxy configured to: transmit the request to the management controller, wherein the management controller is configured to execute the request; receive a response from the management controller (Col. 4, lines 17-24, “The request is handled via a Redfish proxy 123 that is coupled to the in-band channel 116. The request gets forwarded to the BMC 106 using in-band channel 116. The BMC 106 processes the request, and returns the result to the Redfish proxy 123 via the in-band channel 116.” Col. 4 & 5, lines 59-67 & 1-10, “As seen in FIG. 3, a Redfish query 300 from a management node is received at the host 102. The request is decoded 301, the decoded data being indicated in block 302. The Redfish request is encapsulated 303 into an OEM-specific SCSI command and sent 304 to the BMC…In FIG. 4, the BMC 106 receives 400 the OEM-specific SCSI command using the USB driver…If the command is a predefined, OEM-specific command, then the command is parsed 404 to extract the Redfish request data, which is decoded 406 to determine the Redfish query data 406. The query data is passed to the Redfish server 118.”); and transmit the response to the management node (Col. 5, lines 11-20, “In FIG. 5, the Redfish response data 500 is received from the Redfish server 118 within the BMC 106. The response data 500 is clubbed/packed 501 into a data packet for USB transport, the packed data being encapsulated into an OEM-specific response packet 502. This data packet is then sent 503 via the USB drivers to the host 102, as seen in FIG. 6. In FIG. 6, the host 102 receives 600 the OEM-specific SCSI response packet via USB and decodes 601 the packet to get the Redfish response data 602. The response data 602 is sent 603 as a response to the management node 604.”).
Sahu fails to explicitly teach the aforementioned handling of a request for hardware management functionality taking place within an information handling system.
However, Gore teaches an information handling system (¶ [0020], “FIG. 1 illustrates a block diagram representation of an example information handling system (IHS) 100, within which one or more of the described features of the various embodiments of the disclosure can be implemented.” See also Fig. 1.) comprising: at least one processor (¶ [0021], “IHS 100 includes one or more processor(s) 102. In various embodiments, IHS 100 may be a single-processor system including one processor 102, or a multi-processor system including two or more processor(s) 102 (e.g., two, four, eight, or any other suitable number).”); a memory (¶ [0022], “Processor(s) 102 are coupled to platform controller hub (PCH) or chipset 108 via front-side bus 106. PCH 108 may be configured to coordinate I/O traffic between processor(s) 102 and other components…PCH 108 is also coupled to system memory 114 via memory bus 116. System memory 114 may be configured to store program instructions and/or data accessible by processor(s) 102.”); and wherein the client system is coupled to the information handling system via a cluster management network (¶ [0031], “IHS 100 further includes one or more user or client computer systems 195 that are communicatively coupled to IHS 100 via network 170. Client computer system 195 can request access to resources, services, data and information of IHS 100.”).
Sahu and Gore are considered to be analogous to the claimed invention because they are in the same field of management of computing systems and communications that facilitate such management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the method of handling requests for hardware management functionality as taught by Sahu into the information handling system environment of Gore to arrive at the claimed invention. This substitution would have been reasonable under MPEP § 2143 as both references involve accessing data regarding hardware of a system that is stored in management controllers of said system.
As per claim 3, Sahu and Gore teach the information handling system of claim 1. Sahu also teaches wherein the request is transmitted to the management controller via a universal serial bus (USB) network interface controller (NIC) (Col. 3 & 4, lines 58-67 & 1-9, “A peripheral communications channel that exists between the host 102 and the BMC 106 is used as an in-band communications channel for passing Redfish API requests that are received on the host to the BMC. Thus, without any major change in the Redfish Agent monitoring sensors on the BMC 106, Redfish data can be obtained over an in-band communication channel 116, which is also referred to herein as a peripheral communications channel. The BMC 106 may be configured such that the in-band communication channel emulates a network interface, e.g., a USB-coupled network interface.”).
As per claim 5, Sahu and Gore teach the information handling system of claim 1. Sahu also teaches wherein the data network is an in-band data network (Col. 3 & 4, lines 58-67 & 1-24, “A peripheral communications channel that exists between the host 102 and the BMC 106 is used as an in-band communications channel for passing Redfish API requests that are received on the host to the BMC. Thus, without any major change in the Redfish Agent monitoring sensors on the BMC 106, Redfish data can be obtained over an in-band communication channel 116, which is also referred to herein as a peripheral communications channel… In this embodiment, the Redfish REST API request is first received by the host 102 via port 120. The request is handled via a Redfish proxy 123 that is coupled to the in-band channel 116. The request gets forwarded to the BMC 106 using in-band channel 116.” See also Fig. 1.).
As per claim 6, Sahu and Gore teach the information handling system of claim 1. Sahu also teaches wherein the management controller is configured to communicate with the information handling system via an out-of-band management network (Col. 3, lines 26-44, “On conventional systems, the out-of-band network access is achieved by enabling a network interface coupled to the BMC 106, e.g., a management Ethernet port 114 within the TOM that utilizes OOB IPMI over a local area network (LAN).”).
As per claim 7, it is a method claim comprising similar limitations to claim 1, so it is rejected for similar reasons.
As per claim 9, it is a method claim comprising similar limitations to claim 3, so it is rejected for similar reasons.
As per claim 11, it is a method claim comprising similar limitations to claim 5, so it is rejected for similar reasons.
As per claim 12, it is a method claim comprising similar limitations to claim 6, so it is rejected for similar reasons.
As per claim 13, it is an article of manufacture claim comprising similar limitations to claim 1, so it is rejected for similar reasons. Sahu also teaches a non-transitory, computer-readable medium having computer-executable instructions thereon (Col. 7 & 8, lines 57-67 & 1-3, “For example, the flowcharts and control diagrams illustrated herein may be used to create computer-readable instructions/code for execution by a processor. Such instructions may be stored on a non-transitory computer-readable medium and transferred to the processor for execution as is known in the art.”).
As per claim 15, it is an article of manufacture claim comprising similar limitations to claim 3, so it is rejected for similar reasons.
As per claim 17, it is an article of manufacture claim comprising similar limitations to claim 5, so it is rejected for similar reasons.
As per claim 18, it is an article of manufacture claim comprising similar limitations to claim 6, so it is rejected for similar reasons.
Claim(s) 2, 8, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Sahu and Gore as applied to claims 1, 7, and 13 above, and further in view of Ali et al. (US Patent No. 10,620,941 B2 hereinafter Ali).
As per claim 2, Sahu and Gore teach the information handling system of claim 1. Sahu teaches the cluster management client (Col. 4, lines 25-47, “A central node management server 200 is responsible for collating data from various individual servers over the Redfish REST API. The server 200 sends out a Redfish API request 210 to the host 102.”).
Sahu and Gore fail to teach the cluster management client being a part of a hyper-converged infrastructure.
However, Ali teaches a hyper-converged infrastructure (HCI) (Col. 5, lines 34-50, “Although FIG. 1 illustrates a solution infrastructure 100 with three information handling resources 102, it will be readily appreciated that, whether implemented as a converged infrastructure system, a hyper-converged system, or another type of system, solution infrastructure 100 may include multiple instances of information handling resources 102-1, 102-2, and/or 102-3, as well as additional types of information handling resources not depicted in FIG. 1…the infrastructure of solution infrastructure 100 may include, in addition to the physical hardware components, any and all software and/or firmware components, including BIOS firmware, operating system software, hypervisor software, and/or containerization software, as well as any management resources on any one or more of the information handling resources 102.” Therefore, the cluster management client of Sahu can be one of the management resources on the information handling system in the hyper-converged infrastructure of Ali.).
Sahu and Gore are all considered to be analogous to the claimed invention because they are all in the same field of management of computing systems and communications that facilitate such management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sahu and Gore with the teachings of Ali to show a cluster management client that operates within a hyper-converged infrastructure.
As per claim 8, it is a method claim comprising similar limitations to claim 2, so it is rejected for similar reasons.
As per claim 14, it is an article of manufacture claim comprising similar limitations to claim 2, so it is rejected for similar reasons.
Claim(s) 4, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Sahu and Gore as applied to claims 1, 7, and 13 above, and further in view of Fries et al. (US Patent No. 9,191,454 B2 hereinafter Fries).
As per claim 4, Sahu and Gore teach the information handling system of claim 1.
Although Sahu and Gore teach executing a proxy, Sahu and Gore fail to teach the proxy being executed by a hypervisor.
However, Fries teaches wherein the proxy is executed by a hypervisor (Col. 4, lines 57-67, “A proxy agent 222 on the hypervisor host 198 bridges the client host 188 with the VM 186.” Col. 5, lines 1-18, “When the packet 223 is received, the proxy agent 222 determines that the packet 223 is meant to be received by the VM 186 and causes the virtualization layer (hypervisor) to pass the packet through a private or local communication channel 224 to the VM 186.” The proxy agent, which resides on the hypervisor as shown in Fig. 6, is responsible for servicing the proxy sent from the management application.)
Sahu, Gore, and Fries are all considered to be analogous to the claimed invention because they are all in the same field of management of computing systems and communications that facilitate such management. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the information handling system of Sahu and Gore with the proxy functionality of Fries. This modification would have been reasonable under MPEP § 2143 as all references handle requests for information regarding hardware/software executing within a system.
As per claim 10, it is a method claim comprising similar limitations to claim 4, so it is rejected for similar reasons.
As per claim 16, it is an article of manufacture claim comprising similar limitations to claim 4, so it is rejected for similar reasons.
Response to Arguments
Applicant's arguments filed 12/23/2025 have been fully considered but they are not persuasive. Applicant first argues that Sahu and Gore fail to describe any functionality relating to a cluster. Examiner disagree with this argument and directs Applicant to Col. 1 & 2, lines 64-67 & 1-17 of Sahu which talk about the embodiments of the disclosure relating large-scale server systems wherein the servers are connected via various networks. One of ordinary skill in the art would recognize that a cluster is simply multiple compute devices connected together to form a large-scale, cohesive system. Thus, Sahu and Gore describe a cluster environment. Additionally, Applicant argues that Sahu and Gore fail to teach the amendment to the independent claims of “such that the cluster management client cannot communicate directly with the management controller.” However, Examiner disagrees with this argument for reasons indicated in the claim rejections above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 ET.
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, Lewis Bullock can be reached at (571)272-3759. 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.
/J.D.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199