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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Amendment
The Amendment filed 2/25/2026 has been entered. Claims 1-20 remain pending in the present Office Action.
The Amendments to the Claims and Specification have been fully considered and overcome all Objections set forth in the previous Office Action.
The Amendments to the Claims have been fully considered and overcome all Rejections under 35 U.S.C. 112(b) set forth in the previous Office Action. Accordingly, the rejections presented under 35 U.S.C. 112(b) set forth in the previous Office Action have been withdrawn.
Claim Objections
Claims 1-2, 7-8, and 14-15 are objected to because of the following informalities:
In claim 1, line 21, “the controls” should be amended to recite “the set of controls” to maintain consistency with the previous recitation of a set of controls in line 6.
In claim 2, line 6, “the information” should be amended to recite “the set of information” to maintain consistency with the previous recitation of a set of information in line 5.
In claim 7, line 2, “one or more of the controls” should be amended to recite “one or more of the controls in the set of controls” to maintain consistency with the previous recitation of a set of controls in claim 1.
In claim 8, line 21, “the controls” should be amended to recite “the set of controls” to maintain consistency with the previous recitation of a set of controls in line 6.
In claim 8, lines 28-29 – “a set of available service from a set of available services” should be amended to recite any of “a set of available services [[from a set of available services]]”, “a subset of available services from a set of available services” or “a set of available services from a [[set]]plurality of available services”.
In claim 8, line 31, “installing” should be corrected to recite “install”.
In claim 8, line 33, “receiving” should be corrected to recite “receive”.
In claim 14, line 2, “one or more of the controls” should be amended to recite “one or more of the controls in the set of controls” to maintain consistency with the previous recitation of a set of controls in claim 8.
In claim 15, line 19, “the controls” should be amended to recite “the set of controls” to maintain consistency with the previous recitation of a set of controls in line 4.
In claim 15, line 26, “executing the the plurality of available services” should be amended to remove the repeated “the”.
Appropriate correction is required.
Claim 17 is objected to for reciting the acronym “PCS” in line 4 without previously indicating the full meaning of the term. Applicant is reminded an acronym should be written in full the first time it is used to particularly point out and distinctly claim the invention. For clarity of the record, the Examiner has interpreted “PCS” to mean “private cloud server”.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 8, and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 6, 13, and 20, respectively, of U.S. Patent No. 12,657,077 in view of Lawson et al. (U.S. Pub. No. 2013/0212420), hereinafter Lawson.
The claims of the instant application and the claims of the reference patent are compared in Table 1 below, which differences between the claims in bold.
For clarity of the record, some of the operations performed by the PCS server in claims 1 and 8 of the instant application are not patentably distinct from the operations performed by the PCS server of the reference claims 6 and 13. Specifically, communicating with an external cloud server to “identify” a set of available services, and the PCS server subsequently “installing” the one or more services of the set of available services as recited in reference claims would necessarily require the PCS server “retrieve” the one or more services of the set of available services as recited by the instant claims in order for them to be installed. Further, it would have been obvious to one of ordinary skill in the art that the PCS server “determining a location for executing” the one or more services of the set of available services and subsequently installing the one or more services at the location, e.g. the PCS as recited in reference claims 6 and 13 and more specifically “in the memory of” the PCS as would be required to install a service (i.e., software), would result in the execution of the one or more installed services of the set of available services.
Claims 6, 13, and 20 of the reference patent teach all the limitations of claims 1, 8 and 15 of the reference application except that the available services comprise “a telemetry service”, “receiving data from a set of servers of the plurality of servers; and in response to receiving the data, executing the installed services including executing the telemetry service at the PCS to aggregate portions of the data and remove redundant portions from the data.”
However, Lawson teaches a telemetry service installed in a private cloud server ([0009] – “devices can then time-stamp collected or generated data and provide the time-stamped data to the cloud platform for storage and/or analysis by the cloud-based service or application.”; [0041] – “industrial devices 108 and 110 can be coupled to a cloud platform to leverage cloud-based applications. That is, the industrial device 108 and 110 can be configured to discover and interact with cloud-based computing services 112 hosted by cloud platform 102 […] cloud 102 can be a private cloud operated internally by the enterprise. An exemplary private cloud can comprise a set of servers hosting the cloud services 112 and residing on a corporate network”; [0043] – “cloud-based diagnostic applications can monitor the health of respective automation systems or their associated industrial devices across an entire plant, or across multiple industrial facilities that make up an enterprise”; [0051]-[0053] – “industrial controller 302 generates or collects (near) real-time data relating to controlled industrial processes 304.sub.1-304.sub.N, such as part counts, temperatures, pressures, motor speeds or loads, vibration data, weights, quality test results, alarms, machine states, operator feedback, or other such information. Some of this data is read by the industrial controller 302 directly from field devices (e.g., telemetry devices) associated with the processes themselves, while other data can be generated by control program 310 based on measured process values (e.g., alarms, derived or calculated values, etc.). […] Industrial controller 302 is configured to be cloud-capable, allowing it to connect to a web-based or private cloud platform and utilize cloud-based services hosted thereon (e.g., data storage, analysis, processing, etc.). […] To facilitate time-based analysis of the industrial data on the cloud platform, industrial controller 302 can include a time stamp component 312 configured to associate time stamps to the raw data 306 prior to pushing the data to the cloud platform.” The time stamped telemetry data is collected and provided to the cloud platform for analysis by the cloud-based services/applications.); receiving data from a set of servers of the plurality of servers ([0057] – “some configurations may utilize a cloud proxy device that collects industrial data from multiple devices, time-stamps the data, and sends the time-stamped data to the cloud platform. Such a cloud proxy can be a dedicated data collection device, such as a server […] For industrial controllers such as PLCs or other automation controllers, this can include collecting data from telemetry devices connected to the controller's I/O”; [0075] – “Time-stamped industrial data is received from industrial devices 1004 at device interface component 1014, which can store the received data on cloud storage 1012”); and in response to receiving the data, executing services including executing the telemetry service to aggregate portions of the data and remove redundant portions from the data ([0075] – “the received data may be filtered by a filter component 1016 prior to being moved to cloud storage 1012. Similar to local filter components described above (e.g., filter component 708 of FIG. 7), filter component 1016 can be configured to remove redundant data items or data not needed by the cloud-based data analysis system 1002 in accordance with any specified filtering criterion. […] Filter component 1016 can also be configured to identify redundant data items received from two different devices. […] filter component 1016 can be configured to identify the duplicated data items (e.g., by virtue of a common data tag name or other identification methodology) and discard one of the duplicated values.”; [0076]-[0077] – the received data may be analyzed and grouped into subsets by the cloud-based data analysis system 1002).
It would have been obvious to one of ordinary skill in the art to have modified the available services installed in the private cloud servers taught by the reference claims to include a telemetry service which receives data from the server(s), and in response, aggregates portions of the data and removes redundant portions from the data as taught by Lawson. Incorporating the private cloud based telemetry service of Lawson would enable aggregation of data from a plurality of sources/locations, e.g., a plurality of different devices, for analysis to determine events occurring at a plurality of devices and their interdependencies or impacts at other locations and would provide easily scalable storage (e.g., cloud-based storage) of the large amounts of data generated by an enterprise (see Lawson: [0006], [0009], and [0043]). Further, removal of redundant portions of data before storage as described by Lawson (see Lawson: [0075]), would provide for more efficient storage of data and reduce the storage resources required.
Table 1: Claim comparison of the instant application with reference patent 12,657,077
Claim
18/354,936 (instant application)
U.S. Patent No. 12,657,077
1
A system on a server comprising a plurality of devices, the system comprising:
A system in a server comprising a plurality of devices, a data processing unit (DPU) executing a DPU operating system (OS) and a memory storing one or more of a server OS and a unified extensible firmware interface (UEFI), the system comprising:
a remote access controller (RAC) comprising:
a remote access controller (RAC) comprising:
a RAC processor; and
a RAC processor; and
a memory storing:
a memory storing:
a set of controls, the set of controls comprising a power control for monitoring power supplied to the server and a thermal control for monitoring a temperature of the server;
a set of controls, the set of controls comprising a power control for monitoring power supplied to the server and a thermal control for monitoring a temperature of the server;
a hardware abstraction layer (HAL) for communicating with the plurality of devices;
a hardware abstraction layer (HAL) for communicating with the plurality of devices;
a Desktop Bus (D-Bus) communications bus interface for communicating with the HAL and facilitating communications between a set of applications executing on the server;
a Desktop Bus (D-Bus) communications bus interface for communicating with the HAL and facilitate communications between a set of applications executing on the server;
a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format;
a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format;
a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format;
a D-Bus to Representational State Transfer (REST) mapper for translating communications from the one or more devices of the plurality of devices into a REST Application Programming Interface (API) format;
a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the server; and
a Remote Procedure Call (RPC) queue to facilitate communication between
two or more applications of the set of applications executing on the server; and
a set of instructions executable by the RAC processor to execute the controls stored in the memory in the RAC;
a set of instructions executable by the RAC processor to execute the set of controls
stored in the memory in the RAC;
a private cloud server (PCS) communicatively coupled to the server and an external cloud server, the private cloud server comprising:
a private cloud server (PCS) communicatively coupled to the server and an external cloud server, the private cloud server comprising:
a PCS processor; and
a PCS processor; and
a memory storing a set of instructions executable by the PCS processor to:
a memory storing a set of instructions executable by the PCS processor for:
communicate with the external cloud server to retrieve a set of available services from a plurality of available services;
installing a telemetry service from the set of available services in the memory of the PCS;
receiving data from the server; and
in response to receiving the data, execute the set of available services at the PCS, including executing the telemetry service at the PCS to aggregate portions of the data and remove redundant portions from the data.
communicating with the external cloud server to identify a set of available
services from a plurality of available services;
determining a location for executing one or more available services of the set of available services for processing information on the server; and installing the one or more available services of the set of available services at the location.
See claim 6: The system of claim 1, wherein the set of PCS instructions are executable by the PCS processor for:
determining the PCS as a location for executing one or more available services of the set of available services for processing information; and
installing the one or more available services of the set of available services in the PCS.
8
A data center comprising:
A data center comprising:
a plurality of servers, wherein each respective server comprises:
a plurality of servers, wherein each server comprises:
a remote access controller (RAC) comprising:
a remote access controller (RAC) comprising
a RAC processor; and
a RAC processor; and
a memory storing:
a memory storing:
a set of controls, the set of controls comprising a power control for monitoring power supplied to the respective server and a thermal control for monitoring a temperature of the respective server;
a set of controls, the set of controls comprising a power control for monitoring power supplied to the server and a thermal control for monitoring a temperature of the server;
a hardware abstraction layer (HAL) for communicating with the plurality of devices;
a hardware abstraction layer (HAL) for communicating with the plurality of servers;
a Desktop Bus (D-Bus) communications bus for communicating with the HAL and facilitating communications between a set of applications executing on the server;
a Desktop Bus (D-Bus) communications bus interface for communicating with the HAL and facilitate communications between a set of applications executing on the server;
a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format;
a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of servers into an RPC format;
a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format;
a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of servers into a REST Application Programming Interface (API) format;
a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the respective server; and
a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the server; and
a set of instructions executable by the RAC processor to execute the controls stored in the memory in the RAC;
a set of instructions executable by the RAC processor to execute the set of controls stored in the memory in the RAC;
wherein at least one server of the plurality of servers comprises a private cloud server (PCS) communicatively coupled to the plurality of servers and an external cloud server, the private cloud server comprising:
wherein at least one server of the plurality of servers comprises a private cloud server (PCS) communicatively coupled to the plurality of servers and an external cloud server, the private cloud server comprising:
a PCS processor; and
a PCS processor; and
a memory storing a set of instructions executable by the PCS processor to:
a memory storing a set of instructions executable by the PCS processor for:
communicate with the external cloud server to retrieve a set of available service from a set of available services;
installing a telemetry service from the set of available services in the memory of the PCS;
receiving data from a set of servers of the plurality of servers; and
in response to receiving the data, execute the set of available services, including executing the telemetry service at the PCS to aggregate portions of the data and remove redundant portions from the data.
communicating with the external cloud server to identify a set of available
services from a plurality of available services;
determining a location for executing one or more available services of the
set of available services for processing information on the server; and
installing the one or more available services of the set of available services
at the location.
See claim 13: The data center of claim 8, wherein the set of PCS instructions are executable by the PCS processor for:
determining the PCS as a location for executing one or more available services of the set of available services for processing information; and
installing the one or more available services of the set of available services in the PCS.
15
A method of operating a data center comprising a plurality of servers, the method comprising:
A method of operating a data center comprising a plurality of servers, the method comprising:
storing, on each respective server of the plurality of servers:
storing, on each server of the plurality of servers:
a set of controls, the set of controls comprising a power control for monitoring power supplied to the respective server and a thermal control for monitoring a temperature of the respective server;
a set of controls, the set of controls comprising a power control for monitoring power supplied to a server and a thermal control for monitoring a temperature of the server;
a hardware abstraction layer (HAL) for communicating with a plurality of devices;
a hardware abstraction layer (HAL) for communicating with a plurality of devices;
a Desktop Bus (D-Bus) communications bus for communicating with the HAL and facilitating communications between a set of applications executing on the server;
a Desktop Bus (D-Bus) communications bus interface for communicating with the HAL and facilitate communications between a set of applications executing on the server;
a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format;
a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format;
a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format;
a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format;
a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the respective server; and
a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the server; and
a set of instructions executable by a remote access controller (RAC) processor to execute the controls stored in memory in the RAC;
a set of instructions executable by the RAC processor to execute the set of controls stored in the memory in the RAC;
retrieving, by a private cloud server from an external cloud server over a network, a plurality of available services;
installing, by the private cloud server, a telemetry service from the plurality of available services in memory of the private cloud server;
receiving, by the private cloud server, data from a set of servers of the plurality of servers; and
in response to receiving the data, executing the the plurality of available services at the private cloud server, including executing the telemetry service at the private cloud server to aggregate portions of the data and remove redundant portions from the data.
identifying, by a private cloud server, a set of available services from a plurality of available services; determining a location for executing one or more available services of the set of available services, the location comprising one of a memory in the server, a memory in the RAC or a memory in the private cloud server; and
retrieving the one or more available services of the set of available services from an external cloud server over a network;
installing the one or more available services at the location; and
executing the set of available services for processing information on a set of servers of the plurality of servers.
See claim 20: The method of claim 15, wherein the set of PCS instructions are executable by the PCS processor for:
determining the PCS as a location for executing one or more available services of the set of available services for processing information; and installing the one or more available services of the set of available services in the PCS
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 8-11 and 16-20 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.
Claim 8 recites the limitation “the plurality of devices” in lines 9-10. There is insufficient antecedent basis for this limitation in the claim.
The Examiner has interpreted this to be reciting “a plurality of devices”.
Claim 9 recites the limitation "the information" in line 4. There is insufficient antecedent basis for this limitation in the claim.
The Examiner has interpreted this to be reciting “information”.
Claim 16 recites “the set of available services” in lines 2-3. There is insufficient antecedent basis for this limitation in the claim.
The Examiner has interpreted this to be referring to “the plurality of available services” as recited in amended claim 15. If claim 16 is amended to recite “the plurality of available services”, Claim 17 should be similarly amended in lines 2 and 4.
Claim 16 recites the limitation "the information" in line 4. There is insufficient antecedent basis for this limitation in the claim.
The Examiner has interpreted this to be reciting “information”.
Claims 9-14 depend from claim 8, and therefore are also rejected as they inherit the deficiencies of claim 8. Claims 10-11 depend from claim 9, and therefore are also rejected as they inherit the deficiencies of claim 9. Claims 17-20 depend from claim 16, and therefore are also rejected as they inherit the deficiencies of claim 16.
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.
Claims 1, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Pogrebinsky et al. (U.S. Pub. No. 2022/0374271), hereinafter Pogrebinsky, in view of Gupta et al. (U.S. Pub. No. 2022/0114066), hereinafter Gupta, Bays (U.S. Pub. No. 2016/0173371), Juster (U.S. Patent No. 6,202,089), and Lawson et al. (U.S. Pub. No. 2013/0212420), hereinafter Lawson.
Regarding claim 1, Pogrebinsky teaches A system on a server comprising a plurality of devices ([0036] – “the nodes 105 can individually include a processor, a physical server, or several physical servers”; [0023] – “a cloud computing system can include […] multiple servers in a cloud computing datacenter”; [0068] – “one or more servers or nodes 105 (FIG. 2A) in the private cloud 106”; [0079]-[0084] – “the computing device 300 can be suitable for the nodes 105”, computing device 300 includes devices such as processors 304, memory 306, storage devices 332/336/338, output devices 342, communication devices 346, etc.), the system comprising: […]
a private cloud server (PCS) communicatively coupled to the server ([0055] – “the private cloud 106 can include a resource manager 122', a deployment resource provider (shown as "DRP 134")”; [0002] – ““cloud" computing typically utilizes a collection of remote servers to provide computing, data storage, electronic communications, or other cloud services.”; [0004] – “dedicated servers, datacenters, or other computing facilities configured to deploy cloud services for internal use only. Such cloud computing systems are often referred to as a private clouds.”; [0023] – “the term "cloud computing system" or "cloud" generally refers to a computer system configured to provide various cloud computing services via a computer network. A cloud computing system can include multiple network devices interconnecting a large number of remote servers or nodes to one another and/or to external networks (e.g., the Internet). In one example, a cloud computing system can include multiple containers, racks, or other suitable enclosures each holding multiple servers in a cloud computing datacenter (or portions thereof).”; [0026] – “the term "resource provider" generally refers to a cloud service that is configured to provide or make available one or more cloud services or resources of a public or private cloud”; [0068] – “one or more servers or nodes 105 (FIG. 2A) in the private cloud 106”. DRP 134 is a cloud service implemented in the private cloud 106, i.e., on a server of the private cloud as evidenced by [0002], [0004], and [0023] which teach servers are used in cloud computing environments to provide cloud services, is interconnected with other servers of the private cloud, e.g., “the server”.) and an external cloud server (Figs. 3C-3D, the DRP 134 in the private cloud 106 communicates with authentication service 124 and publication service 126 of the public cloud 108, which are implemented on servers of the public cloud as evidenced by previously cited portions of [0002] and [0023]), the private cloud server comprising:
a PCS processor; and a memory storing a set of instructions executable by the PCS processor (processor 131 or 304 and memory 133 or 306; [0036] – “the nodes 105 can individually include a processor, a physical server, or several physical servers”; [0039] – “first node 105a and the second node 105b can each include a processor 131, a memory 133 […] The memory 133 can include volatile and/or nonvolatile media (e.g., ROM; RAM, magnetic disk storage media; optical storage media; flash memory devices, and/or other suitable storage media) and/or other types of computer-readable storage media configured to store data received from, as well as instructions for, the processor 131 (e.g., instructions for performing the methods discussed below with reference to FIGS. 6A-6D).”; [0079] – “the computing device 300 can be suitable for the nodes 105 […] computing device 300 can include one or more processors 304 and a system memory 306.”; Claim 10 – “A computing device in a cloud computing system having multiple servers, the computing device comprising: a processor; and a memory operatively coupled to the processor, the memory containing instructions executable by the processor to provide a deployment service”) to:
communicate with the external cloud server to retrieve a set of available services ([0054] – “the publishing service 126 can also publish artifacts of certain applications 112 to the private cloud 106. For example, in one embodiment, when an ISV submits an application 112, the ISV can elect to have the application 112 also be published to the private cloud 106. In response to receiving the submitted application 112, the publication service 126 can then inform, for example, via an application notice 150, publish, or otherwise make the private cloud 106 aware of the submitted application 112. […] certain categories, classes, groups, or types of applications 112 can be automatically published to the private cloud 106 by default”; [0057] – “The DRP 134 can be configured to streamline secure deployment of cloud services in the private cloud 106 […] activate the DRP 134 for performing a deployment process of the application 112 in the private cloud 106”; [0063] – “the DRP 134 is configured to retrieve the application manifest 151 from the public cloud 108 […] the public cloud 108 provides the application manifest 151 to the DRP 134. In other examples, the application manifest 151 can be provided to the private cloud 106 along with the application notice 150”; [0067] – “the DRP 134 can be configured to transmit one or more component request 157 to the public cloud 108 requesting the one or more components of the application 112. In response, the publication service 126 (or other suitable types of service in the public cloud 108) can be configured to retrieve a copy of the components of the application 112' and provide the retrieved copy to the DRP 134 at the private cloud 106.”) from a plurality of available services ([0052] – “The publication service 126 can be configured to receive applications 112 from, for example, independent software vendors (ISVs) or other suitable sources and provide access of the applications 112 to the users 101 (FIG. 1) of the public cloud 108. In certain embodiments, ISVs can develop SaaS applications and submit the developed SaaS applications to the publication service 126.”; [0053] – “The publication service 126 can then be configured to store one or more copies of various components and artifacts of the applications 112 in, for example, a repository 111 or other suitable network storage (not shown) in the public cloud 108. Components of an application 112 can include executables, libraries, databases, and/or other suitable software modules”);
installing a […] service from the set of available services in the memory of the PCS ([0057] – “activate the DRP 134 for performing a deployment process of the application 112 in the private cloud 106.”; [0067] – “Upon receiving the application manifest 151, the DRP 134 can be configured to install components of the application 112 guided by the application manifest 151”; [0068] – “Upon receiving the one or more components of the application 112', the DRP 134 can be configured to utilize the instantiate computing resources to install the one or more components in one or more servers or nodes 105 (FIG. 2A) in the private cloud 106.”); […]; and
[…] execute the set of available services at the PCS, including executing the […] service at the PCS ([0057] – “The DRP 134 can be configured to streamline secure deployment of cloud services in the private cloud 106 […] activate the DRP 134 for performing a deployment process of the application 112 in the private cloud 106”; [0068] – “Upon receiving the one or more components of the application 112', the DRP 134 can be configured to utilize the instantiate computing resources to install the one or more components in one or more servers or nodes 105 (FIG. 2A) in the private cloud 106. […] The one or more nodes 105 can then execute the installed one or more components of the application 112 to provide the corresponding cloud service to the users 101”).
Pogrebinsky fails to expressly teach a remote access controller (RAC) comprising: a RAC processor; and a memory storing: a set of controls, the set of controls comprising a power control for monitoring power supplied to the server and a thermal control for monitoring a temperature of the server; a hardware abstraction layer (HAL) for communicating with the plurality of devices; a Desktop Bus (D-Bus) communications bus interface for communicating with the HAL and facilitating communications between a set of applications executing on the server; a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format; a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format; a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the server; and a set of instructions executable by the RAC processor to execute the controls stored in the memory in the RAC; a telemetry service installed in the PCS; receiving data from the server; and in response to receiving the data, executing the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Gupta teaches a server comprising a remote access controller (RAC) (FIG. 1, IHS 100 comprising BMC 132; [0022] – “BMC 132 may include or may be part of a Remote Access Controller”; [0012] – “an IHS may be a […] server (e.g., blade server or rack server)”) comprising: a RAC processor; and a memory ([0021] – “BMC 132 may include a processor, memory”) storing: a set of controls, the set of controls comprising a power control for monitoring power supplied to the server and a thermal control for monitoring a temperature of the server ([0003] – “Different types of sensors built into the IHS report to the BMC on parameters such as temperature, cooling fan speeds, power status, operating system (O/S) status, and the like. The BMC monitors the sensors.”; [0013] – “a baseboard management controller (BMC) configured on the IHS to obtain power profile data as well as thermal profile data for the hardware devices configured in the IHS, and, based on this data, optimally control the power and thermal system of the IHS”; [0026] – “The BMC 132 includes a BMC management operating system (O/S) 202 that stores and executes a RESTful server 204 and a power/thermal management application 206. The BMC management O/S may be stored on a memory of BMC 132”; [0030] – “The power/thermal management application 206 includes a data validator 222, an iterative thermal optimization tool 224, and a hardware device controller 226.”; [0032] – “Hardware device controller 226 uses the power/thermal data table entries 216 to derive an overall power profile and/or thermal profile for IHS 100, and controls the operation of certain hardware devices of IHS 100 according to the derived overall power profile and/or thermal profile. For example, hardware device controller 226, upon determining that the overall power profile of IHS 100 is at a specified amount (e.g., 175.0 Watts), controls PSUs 130 to generate that specified amount of electrical power. Additionally, upon determining that the overall thermal profile of IHS 100 is at a specified amount (e.g., 35 British Thermal Units (BTUs)), hardware device controller 226 may control fans 136 to generate that specified amount of cooling optimal for IHS 100. In one embodiment, hardware device controller 226 may be coupled to and receive thermal data from one or more temperature sensors 146 configured in IHS 100, and adjust a level of cooling provided to IHS 100 according to the received thermal data.”); […] and a set of instructions executable by the RAC processor to execute the controls stored in the memory in the RAC ([0026] – “BMC 132 includes a BMC management operating system (O/S) 202 that stores and executes a RESTful server 204 and a power/thermal management application 206. The BMC management O/S may be stored on a memory of BMC 132 […] BMC 132 may include one or more processors (not shown), which is separate and distinct from system memory 104 of IHS 100, to execute the instructions of the BMC management O/S 200, RESTful server 204, and power/thermal management application 206.”).
Pogrebinsky is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor in configuring and installing services at a server in a private cloud. Gupta is also considered to be analogous art to the claimed invention because it is in the same field of configuring a remote access controller implemented in a server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the servers of Pogrebinsky to incorporate the teachings of Gupta. Doing so would enable remote monitoring and management of the servers to ensure sensed parameters, such as temperature and power, stay within pre-set limits, resulting in savings on the total cost of ownership of the servers (see Gupta: [0003]).
The combination of Pogrebinsky in view of Gupta fails to expressly teach a hardware abstraction layer (HAL) for communicating with the plurality of devices; a Desktop Bus (D-Bus) communications bus interface for communicating with the HAL and facilitating communications between a set of applications executing on the server; a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format; a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format; a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the server; a telemetry service installed in the PCS; receiving data from the server; and in response to receiving the data, executing the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Bays teaches a hardware abstraction layer (HAL) for communicating with the plurality of devices ([0062] – “A Hardware Abstraction Layer (HAL) is thus provided for each forwarding hardware, where the HAL is configured to translate messages received via the control channel to forwarding hardware vendor-specific APIs.”; [0063] – “HAL 202 acts as an interface between control channel 112 and forwarding hardware 204 that is used to implement the hardware data plane subsystem.” ; [0009]-[0010] – controller, control plane subsystems, software and hardware data plane subsystems may be dispersed logically and/or physically on different devices); a Desktop Bus (D-Bus) communications bus interface for communicating with the HAL and facilitating communications between a set of applications executing on the server ([0014] – “The control plane subsystem may communicate with the first and second data plane subsystems using a control channel. The same control channel may be used irrespective of whether the target data plane subsystem is a software data plane subsystem or a hardware data plane subsystem.”; [0039] – “A control plane subsystem can communicate with multiple data plane subsystems in parallel or concurrently using a control channel 112.”; [0042]-[0044] – control channel 112 may use a ZeroMQ transport mechanism, such as a bus, which provides inter-process transport for messages, making it analogous to the “D-bus”; [0062] – “A Hardware Abstraction Layer (HAL) is thus provided for each forwarding hardware, where the HAL is configured to translate messages received via the control channel to forwarding hardware vendor-specific APIs.”; [0102] – the controller and different subsystems (“set of applications”) can execute on computing system 600, analogous to a server.
For clarity of the record, the Examiner would like to point to paragraph [0039] of the Specification, which recites “A D-Bus 18 or other inter-process communications mechanism may enable local communication between processes”. Accordingly, a D-Bus as recited in the claims is interpreted to be an inter-process communications mechanism.); a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format ([0063] – the HAL translates in both directions between the control channel 112 and the vendor-specific APIs of the forwarding hardware; [0064] – “HAL 202 may be configured to provide translations between various different messaging formats and various vendor-specific APIs. For example, HAL 202 may support interfaces based on various messaging or bus protocols such as REST, YANG, ZeroMQ and/or JSON, and others.”; [0034] – “using Network Configuration Protocol (NETCONF), which is a network management protocol developed and standardized by IETF. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple remote procedure call (RPC) layer.”; [0037] – “NETCONF remote procedure calls”; [0075] – NETCONF protocol, i.e., an RPC-based protocol, may be used in communications between the controller and the forwarding hardware through the control plane subsystems, communication channel 112 (analogous to the D-Bus), and HAL which translates between message protocols.); a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format ([0063] – the HAL translates in both directions between the control channel 112 and the vendor specific APIs of the forwarding hardware; [0064] – “HAL 202 may be configured to provide translations between various different messaging formats and various vendor-specific APIs. For example, HAL 202 may support interfaces based on various messaging or bus protocols such as REST, YANG, ZeroMQ and/or JSON, and others.”).
Bays is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of enabling communication between various processes executing on the server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta to incorporate the teachings of Bays. Using a hardware abstraction layer capable of translating between an inter-process communications mechanism and specific formats, such as REST APIs and RPCs, provides a standardized interface regardless of the type of hardware being used, which increases flexibility and interoperability (see Bays: [0064]-[0065]).
The combination of Pogrebinsky in view of Gupta and Bays fails to expressly teach a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the server; a telemetry service installed in the PCS; receiving data from the server; and in response to receiving the data, executing the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Juster teaches a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the server (Col. 2, lines 3-13 – “an automated method is provided for assigning a plurality of remote procedure call (RPC) endpoints at runtime to a single server process, […]a single server process establishes a plurality of non-statically defined endpoints at runtime corresponding to various RPC services provided by the server process. Thus, the server process will have a plurality of RPC endpoints which do not conflict with other RPC applications.”; Col. 5, lines 10-29 – “MSMQ implements asynchronous communications by enabling applications to send messages to, and receive messages from, other applications. These applications may be running on the same machine or on separate machines connected by a network. MSMQ messages can contain data in any format that is understood by both the sender and the receiver. […] MSMQ keeps messages in holding areas called queues, hence the name message queuing. MSMQ queues protect messages from being lost in transit and provide a place for receivers to look for messages when they are ready. Applications make requests by sending messages to queues associated with the intended receiver. If senders expect responses in return, they must include the name of a response queue (that the sender must create in advance) in all requests that they make to the receiver.”).
Juster is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of enabling communication between various processes executing on the server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta and Bays to incorporate the teachings of Juster. Using an RPC queue as taught by Juster protects messages from being lost in transit and allows receiving processes to find messages when they are ready (see Juster: Col. 5, lines 22-24).
The combination of Pogrebinsky in view of Gupta, Bays, and Juster fails to expressly teach a telemetry service installed in the PCS; receiving data from the server; and in response to receiving the data, executing the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Lawson teaches a telemetry service installed in a PCS ([0009] – “devices can then time-stamp collected or generated data and provide the time-stamped data to the cloud platform for storage and/or analysis by the cloud-based service or application.”; [0041] – “industrial devices 108 and 110 can be coupled to a cloud platform to leverage cloud-based applications. That is, the industrial device 108 and 110 can be configured to discover and interact with cloud-based computing services 112 hosted by cloud platform 102 […] cloud 102 can be a private cloud operated internally by the enterprise. An exemplary private cloud can comprise a set of servers hosting the cloud services 112 and residing on a corporate network”; [0043] – “cloud-based diagnostic applications can monitor the health of respective automation systems or their associated industrial devices across an entire plant, or across multiple industrial facilities that make up an enterprise”; [0051]-[0053] – “industrial controller 302 generates or collects (near) real-time data relating to controlled industrial processes 304.sub.1-304.sub.N, such as part counts, temperatures, pressures, motor speeds or loads, vibration data, weights, quality test results, alarms, machine states, operator feedback, or other such information. Some of this data is read by the industrial controller 302 directly from field devices (e.g., telemetry devices) associated with the processes themselves, while other data can be generated by control program 310 based on measured process values (e.g., alarms, derived or calculated values, etc.). […] Industrial controller 302 is configured to be cloud-capable, allowing it to connect to a web-based or private cloud platform and utilize cloud-based services hosted thereon (e.g., data storage, analysis, processing, etc.). […] To facilitate time-based analysis of the industrial data on the cloud platform, industrial controller 302 can include a time stamp component 312 configured to associate time stamps to the raw data 306 prior to pushing the data to the cloud platform.” The time stamped telemetry data is collected and provided to the cloud platform for analysis by the cloud-based services/applications.); receiving data from the server ([0057] – “some configurations may utilize a cloud proxy device that collects industrial data from multiple devices, time-stamps the data, and sends the time-stamped data to the cloud platform. Such a cloud proxy can be a dedicated data collection device, such as a server […] For industrial controllers such as PLCs or other automation controllers, this can include collecting data from telemetry devices connected to the controller's I/O”; [0075] – “Time-stamped industrial data is received from industrial devices 1004 at device interface component 1014, which can store the received data on cloud storage 1012”); and in response to receiving the data, executing the telemetry service to aggregate portions of the data and remove redundant portions from the data ([0075] – “the received data may be filtered by a filter component 1016 prior to being moved to cloud storage 1012. Similar to local filter components described above (e.g., filter component 708 of FIG. 7), filter component 1016 can be configured to remove redundant data items or data not needed by the cloud-based data analysis system 1002 in accordance with any specified filtering criterion. […] Filter component 1016 can also be configured to identify redundant data items received from two different devices. […] filter component 1016 can be configured to identify the duplicated data items (e.g., by virtue of a common data tag name or other identification methodology) and discard one of the duplicated values.”; [0076]-[0077] – the received data may be analyzed and grouped into subsets by the cloud-based data analysis system 1002).
Lawson is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of remotely monitoring and managing a plurality of computing devices, e.g., through collection of telemetry data at a private cloud server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the services installed in the private cloud servers of Pogrebinsky to include a telemetry service which receives data from the server, and in response, aggregates portions of the data and removes redundant portions from the data as taught by Lawson. Incorporating the private cloud based telemetry service of Lawson would enable aggregation of data from a plurality of sources/locations, e.g., a plurality of different devices, for analysis to determine events occurring at a plurality of devices and their interdependencies or impacts at other locations and would provide easily scalable storage (e.g., cloud-based storage) of the large amounts of data generated by an enterprise (see Lawson: [0006], [0009], and [0043]). Further, removal of redundant portions of data before storage as described by Lawson (see Lawson: [0075]), would provide for more efficient storage of data and reduce the storage resources required.
Regarding claim 8, Pogrebinsky teaches A data center ([0023] – “a cloud computing datacenter”; [0004] – “dedicated servers, datacenters, or other computing facilities configured to deploy cloud services for internal use only. Such cloud computing systems are often referred to as a private clouds.”) comprising:
a plurality of servers ([0023] – “a cloud computing system can include […] multiple servers in a cloud computing datacenter”; [0036] – “the nodes 105 can individually include a processor, a physical server, or several physical servers”; [0068] – “one or more servers or nodes 105 (FIG. 2A) in the private cloud 106”), […]
wherein at least one server of the plurality of servers comprises a private cloud server (PCS) communicatively coupled to the plurality of servers ([0055] – “the private cloud 106 can include a resource manager 122', a deployment resource provider (shown as "DRP 134")”; [0002] – ““cloud" computing typically utilizes a collection of remote servers to provide computing, data storage, electronic communications, or other cloud services.”; [0004] – “dedicated servers, datacenters, or other computing facilities configured to deploy cloud services for internal use only. Such cloud computing systems are often referred to as a private clouds.”; [0023] – “the term "cloud computing system" or "cloud" generally refers to a computer system configured to provide various cloud computing services via a computer network. A cloud computing system can include multiple network devices interconnecting a large number of remote servers or nodes to one another and/or to external networks (e.g., the Internet). In one example, a cloud computing system can include multiple containers, racks, or other suitable enclosures each holding multiple servers in a cloud computing datacenter (or portions thereof).”; [0026] – “the term "resource provider" generally refers to a cloud service that is configured to provide or make available one or more cloud services or resources of a public or private cloud”; [0068] – “one or more servers or nodes 105 (FIG. 2A) in the private cloud 106”. DRP 134 is a cloud service implemented in the private cloud 106, i.e., on a server of the private cloud as evidenced by [0002], [0004], and [0023] which teach servers are used in cloud computing environments to provide cloud services, is interconnected with other servers of the private cloud, e.g., “the plurality of servers”.) and an external cloud server (Figs. 3C-3D, the DRP 134 in the private cloud 106 communicates with authentication service 124 and publication service 126 of the public cloud 108, which are implemented on servers of the public cloud as evidenced by previously cited portions of [0002] and [0023]), the private cloud server comprising:
a PCS processor; and a memory storing a set of instructions executable by the PCS processor (processor 131 or 304 and memory 133 or 306; [0036] – “the nodes 105 can individually include a processor, a physical server, or several physical servers”; [0039] – “first node 105a and the second node 105b can each include a processor 131, a memory 133 […] The memory 133 can include volatile and/or nonvolatile media (e.g., ROM; RAM, magnetic disk storage media; optical storage media; flash memory devices, and/or other suitable storage media) and/or other types of computer-readable storage media configured to store data received from, as well as instructions for, the processor 131 (e.g., instructions for performing the methods discussed below with reference to FIGS. 6A-6D).”; [0079] – “the computing device 300 can be suitable for the nodes 105 […] computing device 300 can include one or more processors 304 and a system memory 306.”; Claim 10 – “A computing device in a cloud computing system having multiple servers, the computing device comprising: a processor; and a memory operatively coupled to the processor, the memory containing instructions executable by the processor to provide a deployment service”) to:
communicate with the external cloud server to retrieve a set of available service from a set of available services ([0054] – “the publishing service 126 can also publish artifacts of certain applications 112 to the private cloud 106. For example, in one embodiment, when an ISV submits an application 112, the ISV can elect to have the application 112 also be published to the private cloud 106. In response to receiving the submitted application 112, the publication service 126 can then inform, for example, via an application notice 150, publish, or otherwise make the private cloud 106 aware of the submitted application 112. […] certain categories, classes, groups, or types of applications 112 can be automatically published to the private cloud 106 by default”; [0057] – “The DRP 134 can be configured to streamline secure deployment of cloud services in the private cloud 106 […] activate the DRP 134 for performing a deployment process of the application 112 in the private cloud 106”; [0063] – “the DRP 134 is configured to retrieve the application manifest 151 from the public cloud 108 […] the public cloud 108 provides the application manifest 151 to the DRP 134. In other examples, the application manifest 151 can be provided to the private cloud 106 along with the application notice 150”; [0067] – “the DRP 134 can be configured to transmit one or more component request 157 to the public cloud 108 requesting the one or more components of the application 112. In response, the publication service 126 (or other suitable types of service in the public cloud 108) can be configured to retrieve a copy of the components of the application 112' and provide the retrieved copy to the DRP 134 at the private cloud 106.”) from a plurality of available services ([0052] – “The publication service 126 can be configured to receive applications 112 from, for example, independent software vendors (ISVs) or other suitable sources and provide access of the applications 112 to the users 101 (FIG. 1) of the public cloud 108. In certain embodiments, ISVs can develop SaaS applications and submit the developed SaaS applications to the publication service 126.”; [0053] – “The publication service 126 can then be configured to store one or more copies of various components and artifacts of the applications 112 in, for example, a repository 111 or other suitable network storage (not shown) in the public cloud 108. Components of an application 112 can include executables, libraries, databases, and/or other suitable software modules”);
installing a […] service from the set of available services in the memory of the PCS ([0057] – “activate the DRP 134 for performing a deployment process of the application 112 in the private cloud 106.”; [0067] – “Upon receiving the application manifest 151, the DRP 134 can be configured to install components of the application 112 guided by the application manifest 151”; [0068] – “Upon receiving the one or more components of the application 112', the DRP 134 can be configured to utilize the instantiate computing resources to install the one or more components in one or more servers or nodes 105 (FIG. 2A) in the private cloud 106.”); […]; and
[…] execute the set of available services including executing the […] service at the PCS ([0057] – “The DRP 134 can be configured to streamline secure deployment of cloud services in the private cloud 106 […] activate the DRP 134 for performing a deployment process of the application 112 in the private cloud 106”; [0068] – “Upon receiving the one or more components of the application 112', the DRP 134 can be configured to utilize the instantiate computing resources to install the one or more components in one or more servers or nodes 105 (FIG. 2A) in the private cloud 106. […] The one or more nodes 105 can then execute the installed one or more components of the application 112 to provide the corresponding cloud service to the users 101”).
Pogrebinsky fails to expressly teach wherein each respective server comprises: a remote access controller (RAC) comprising: a RAC processor; and a memory storing: a set of controls, the set of controls comprising a power control for monitoring power supplied to the respective server and a thermal control for monitoring a temperature of the respective server; a hardware abstraction layer (HAL) for communicating with the plurality of devices; a Desktop Bus (D-Bus) communications bus for communicating with the HAL and facilitating communications between a set of applications executing on the respective server; a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format; a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format; a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the respective server; and a set of instructions executable by the RAC processor to execute the controls stored in the memory in the RAC; a telemetry service installed in the PCS; receiving data from a set of servers of the plurality of servers; and in response to receiving the data, execute the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Gupta teaches wherein each respective server comprises: a remote access controller (RAC) (FIG. 1, IHS 100 comprising BMC 132; [0022] – “BMC 132 may include or may be part of a Remote Access Controller”; [0012] – “an IHS may be a […] server (e.g., blade server or rack server)”) comprising: a RAC processor; and a memory ([0021] – “BMC 132 may include a processor, memory”) storing: a set of controls, the set of controls comprising a power control for monitoring power supplied to the respective server and a thermal control for monitoring a temperature of the respective server ([0003] – “Different types of sensors built into the IHS report to the BMC on parameters such as temperature, cooling fan speeds, power status, operating system (O/S) status, and the like. The BMC monitors the sensors.”; [0013] – “a baseboard management controller (BMC) configured on the IHS to obtain power profile data as well as thermal profile data for the hardware devices configured in the IHS, and, based on this data, optimally control the power and thermal system of the IHS”; [0026] – “The BMC 132 includes a BMC management operating system (O/S) 202 that stores and executes a RESTful server 204 and a power/thermal management application 206. The BMC management O/S may be stored on a memory of BMC 132”; [0030] – “The power/thermal management application 206 includes a data validator 222, an iterative thermal optimization tool 224, and a hardware device controller 226.”; [0032] – “Hardware device controller 226 uses the power/thermal data table entries 216 to derive an overall power profile and/or thermal profile for IHS 100, and controls the operation of certain hardware devices of IHS 100 according to the derived overall power profile and/or thermal profile. For example, hardware device controller 226, upon determining that the overall power profile of IHS 100 is at a specified amount (e.g., 175.0 Watts), controls PSUs 130 to generate that specified amount of electrical power. Additionally, upon determining that the overall thermal profile of IHS 100 is at a specified amount (e.g., 35 British Thermal Units (BTUs)), hardware device controller 226 may control fans 136 to generate that specified amount of cooling optimal for IHS 100. In one embodiment, hardware device controller 226 may be coupled to and receive thermal data from one or more temperature sensors 146 configured in IHS 100, and adjust a level of cooling provided to IHS 100 according to the received thermal data.”); […] and a set of instructions executable by the RAC processor to execute the controls stored in the memory in the RAC ([0026] – “BMC 132 includes a BMC management operating system (O/S) 202 that stores and executes a RESTful server 204 and a power/thermal management application 206. The BMC management O/S may be stored on a memory of BMC 132 […] BMC 132 may include one or more processors (not shown), which is separate and distinct from system memory 104 of IHS 100, to execute the instructions of the BMC management O/S 200, RESTful server 204, and power/thermal management application 206.”).
Pogrebinsky is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor in configuring and installing services at a server in a private cloud. Gupta is also considered to be analogous art to the claimed invention because it is in the same field of configuring a remote access controller implemented in a server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the servers of Pogrebinsky to incorporate the teachings of Gupta. Doing so would enable remote monitoring and management of the servers to ensure sensed parameters, such as temperature and power, stay within pre-set limits, resulting in savings on the total cost of ownership of the servers (see Gupta: [0003]).
The combination of Pogrebinsky in view of Gupta fails to expressly teach a hardware abstraction layer (HAL) for communicating with the plurality of devices; a Desktop Bus (D-Bus) communications bus for communicating with the HAL and facilitating communications between a set of applications executing on the respective server; a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format; a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format; a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the respective server; a telemetry service installed in the PCS; receiving data from a set of servers of the plurality of servers; and in response to receiving the data, execute the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Bays teaches a hardware abstraction layer (HAL) for communicating with the plurality of devices ([0062] – “A Hardware Abstraction Layer (HAL) is thus provided for each forwarding hardware, where the HAL is configured to translate messages received via the control channel to forwarding hardware vendor-specific APIs.”; [0063] – “HAL 202 acts as an interface between control channel 112 and forwarding hardware 204 that is used to implement the hardware data plane subsystem.” ; [0009]-[0010] – controller, control plane subsystems, software and hardware data plane subsystems may be dispersed logically and/or physically on different devices); a Desktop Bus (D-Bus) communications bus for communicating with the HAL and facilitate communications between a set of applications executing on the respective server ([0014] – “The control plane subsystem may communicate with the first and second data plane subsystems using a control channel. The same control channel may be used irrespective of whether the target data plane subsystem is a software data plane subsystem or a hardware data plane subsystem.”; [0039] – “A control plane subsystem can communicate with multiple data plane subsystems in parallel or concurrently using a control channel 112.”; [0042]-[0044] – control channel 112 may use a ZeroMQ transport mechanism, such as a bus, which provides inter-process transport for messages, making it analogous to the “D-bus”; [0062] – “A Hardware Abstraction Layer (HAL) is thus provided for each forwarding hardware, where the HAL is configured to translate messages received via the control channel to forwarding hardware vendor-specific APIs.”; [0102] – the controller and different subsystems (“set of applications”) can execute on computing system 600, analogous to a server.
For clarity of the record, the Examiner would like to point to paragraph [0039] of the Specification, which recites “A D-Bus 18 or other inter-process communications mechanism may enable local communication between processes”. Accordingly, a D-Bus as recited in the claims is interpreted to be an inter-process communications mechanism.); a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format ([0063] – the HAL translates in both directions between the control channel 112 and the vendor-specific APIs of the forwarding hardware; [0064] – “HAL 202 may be configured to provide translations between various different messaging formats and various vendor-specific APIs. For example, HAL 202 may support interfaces based on various messaging or bus protocols such as REST, YANG, ZeroMQ and/or JSON, and others.”; [0034] – “using Network Configuration Protocol (NETCONF), which is a network management protocol developed and standardized by IETF. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple remote procedure call (RPC) layer.”; [0037] – “NETCONF remote procedure calls”; [0075] – NETCONF protocol, i.e., an RPC-based protocol, may be used in communications between the controller and the forwarding hardware through the control plane subsystems, communication channel 112 (analogous to the D-Bus), and HAL which translates between message protocols.); a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format ([0063] – the HAL translates in both directions between the control channel 112 and the vendor specific APIs of the forwarding hardware; [0064] – “HAL 202 may be configured to provide translations between various different messaging formats and various vendor-specific APIs. For example, HAL 202 may support interfaces based on various messaging or bus protocols such as REST, YANG, ZeroMQ and/or JSON, and others.”).
Bays is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of enabling communication between various processes executing on the server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta to incorporate the teachings of Bays. Using a hardware abstraction layer capable of translating between an inter-process communications mechanism and specific formats, such as REST APIs and RPCs, provides a standardized interface regardless of the type of hardware being used, which increases flexibility and interoperability (see Bays: [0064]-[0065]).
The combination of Pogrebinsky in view of Gupta and Bays fails to expressly teach a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the respective server; a telemetry service installed in the PCS; receiving data from a set of servers of the plurality of servers; and in response to receiving the data, execute the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Juster teaches a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the respective server (Col. 2, lines 3-13 – “an automated method is provided for assigning a plurality of remote procedure call (RPC) endpoints at runtime to a single server process, […]a single server process establishes a plurality of non-statically defined endpoints at runtime corresponding to various RPC services provided by the server process. Thus, the server process will have a plurality of RPC endpoints which do not conflict with other RPC applications.”; Col. 5, lines 10-29 – “MSMQ implements asynchronous communications by enabling applications to send messages to, and receive messages from, other applications. These applications may be running on the same machine or on separate machines connected by a network. MSMQ messages can contain data in any format that is understood by both the sender and the receiver. […] MSMQ keeps messages in holding areas called queues, hence the name message queuing. MSMQ queues protect messages from being lost in transit and provide a place for receivers to look for messages when they are ready. Applications make requests by sending messages to queues associated with the intended receiver. If senders expect responses in return, they must include the name of a response queue (that the sender must create in advance) in all requests that they make to the receiver.”).
Juster is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of enabling communication between various processes executing on the server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta and Bays to incorporate the teachings of Juster. Using an RPC queue as taught by Juster protects messages from being lost in transit and allows receiving processes to find messages when they are ready (see Juster: Col. 5, lines 22-24).
The combination of Pogrebinsky in view of Gupta, Bays, and Juster fails to expressly teach a telemetry service installed in the PCS; receiving data from a set of servers of the plurality of servers; and in response to receiving the data, execute the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Lawson teaches a telemetry service installed in a PCS ([0009] – “devices can then time-stamp collected or generated data and provide the time-stamped data to the cloud platform for storage and/or analysis by the cloud-based service or application.”; [0041] – “industrial devices 108 and 110 can be coupled to a cloud platform to leverage cloud-based applications. That is, the industrial device 108 and 110 can be configured to discover and interact with cloud-based computing services 112 hosted by cloud platform 102 […] cloud 102 can be a private cloud operated internally by the enterprise. An exemplary private cloud can comprise a set of servers hosting the cloud services 112 and residing on a corporate network”; [0043] – “cloud-based diagnostic applications can monitor the health of respective automation systems or their associated industrial devices across an entire plant, or across multiple industrial facilities that make up an enterprise”; [0051]-[0053] – “industrial controller 302 generates or collects (near) real-time data relating to controlled industrial processes 304.sub.1-304.sub.N, such as part counts, temperatures, pressures, motor speeds or loads, vibration data, weights, quality test results, alarms, machine states, operator feedback, or other such information. Some of this data is read by the industrial controller 302 directly from field devices (e.g., telemetry devices) associated with the processes themselves, while other data can be generated by control program 310 based on measured process values (e.g., alarms, derived or calculated values, etc.). […] Industrial controller 302 is configured to be cloud-capable, allowing it to connect to a web-based or private cloud platform and utilize cloud-based services hosted thereon (e.g., data storage, analysis, processing, etc.). […] To facilitate time-based analysis of the industrial data on the cloud platform, industrial controller 302 can include a time stamp component 312 configured to associate time stamps to the raw data 306 prior to pushing the data to the cloud platform.” The time stamped telemetry data is collected and provided to the cloud platform for analysis by the cloud-based services/applications.); receiving data from a set of servers of the plurality of servers ([0057] – “some configurations may utilize a cloud proxy device that collects industrial data from multiple devices, time-stamps the data, and sends the time-stamped data to the cloud platform. Such a cloud proxy can be a dedicated data collection device, such as a server […] For industrial controllers such as PLCs or other automation controllers, this can include collecting data from telemetry devices connected to the controller's I/O”; [0072] – “industrial devices 1004 can comprise cloud proxy devices”; [0075] – “Time-stamped industrial data is received from industrial devices 1004 at device interface component 1014, which can store the received data on cloud storage 1012”); and in response to receiving the data, execute the telemetry service to aggregate portions of the data and remove redundant portions from the data ([0075] – “the received data may be filtered by a filter component 1016 prior to being moved to cloud storage 1012. Similar to local filter components described above (e.g., filter component 708 of FIG. 7), filter component 1016 can be configured to remove redundant data items or data not needed by the cloud-based data analysis system 1002 in accordance with any specified filtering criterion. […] Filter component 1016 can also be configured to identify redundant data items received from two different devices. […] filter component 1016 can be configured to identify the duplicated data items (e.g., by virtue of a common data tag name or other identification methodology) and discard one of the duplicated values.”; [0076]-[0077] – the received data may be analyzed and grouped into subsets by the cloud-based data analysis system 1002).
Lawson is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of remotely monitoring and managing a plurality of computing devices, e.g., through collection of telemetry data at a private cloud server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the services installed in the private cloud servers of Pogrebinsky to include a telemetry service which receives data from the server(s), and in response, aggregates portions of the data and removes redundant portions from the data as taught by Lawson. Incorporating the private cloud based telemetry service of Lawson would enable aggregation of data from a plurality of sources/locations, e.g., a plurality of different devices, for analysis to determine events occurring at a plurality of devices and their interdependencies or impacts at other locations and would provide easily scalable storage (e.g., cloud-based storage) of the large amounts of data generated by an enterprise (see Lawson: [0006], [0009], and [0043]). Further, removal of redundant portions of data before storage as described by Lawson (see Lawson: [0075]), would provide for more efficient storage of data and reduce the storage resources required.
Regarding claim 15, Pogrebinsky teaches A method of operating a data center comprising a plurality of servers ([0023] – “a cloud computing system can include […] multiple servers in a cloud computing datacenter”; [0004] – “dedicated servers, datacenters, or other computing facilities configured to deploy cloud services for internal use only. Such cloud computing systems are often referred to as a private clouds.”; [0036] – “the nodes 105 can individually include a processor, a physical server, or several physical servers”; [0068] – “one or more servers or nodes 105 (FIG. 2A) in the private cloud 106”), the method comprising: […]
retrieving, by a private cloud server from an external cloud server over a network ([0055] – “the private cloud 106 can include a resource manager 122', a deployment resource provider (shown as "DRP 134")”; [0002] – ““cloud" computing typically utilizes a collection of remote servers to provide computing, data storage, electronic communications, or other cloud services.”; [0004] – “dedicated servers, datacenters, or other computing facilities configured to deploy cloud services for internal use only. Such cloud computing systems are often referred to as a private clouds.”; [0023] – “the term "cloud computing system" or "cloud" generally refers to a computer system configured to provide various cloud computing services via a computer network. A cloud computing system can include multiple network devices interconnecting a large number of remote servers or nodes to one another and/or to external networks (e.g., the Internet). In one example, a cloud computing system can include multiple containers, racks, or other suitable enclosures each holding multiple servers in a cloud computing datacenter (or portions thereof).”; [0026] – “the term "resource provider" generally refers to a cloud service that is configured to provide or make available one or more cloud services or resources of a public or private cloud”; [0068] – “one or more servers or nodes 105 (FIG. 2A) in the private cloud 106”. DRP 134 is a cloud service implemented in the private cloud 106, i.e., on a server of the private cloud as evidenced by [0002], [0004], and [0023] which teach servers are used in cloud computing environments to provide cloud services. Figs. 3C-3D – the DRP 134 in the private cloud 106 communicates with authentication service 124 and publication service 126 of the public cloud 108, which are implemented on servers of the public cloud as evidenced by previously cited portions of [0002] and [0023]. FIG 1 – network 104 connects the private cloud 106 with public cloud 108), a plurality of available services ([0052] – “The publication service 126 can be configured to receive applications 112 from, for example, independent software vendors (ISVs) or other suitable sources and provide access of the applications 112 to the users 101 (FIG. 1) of the public cloud 108. In certain embodiments, ISVs can develop SaaS applications and submit the developed SaaS applications to the publication service 126.”; [0053] – “The publication service 126 can then be configured to store one or more copies of various components and artifacts of the applications 112 in, for example, a repository 111 or other suitable network storage (not shown) in the public cloud 108. Components of an application 112 can include executables, libraries, databases, and/or other suitable software modules”; [0054] – “the publishing service 126 can also publish artifacts of certain applications 112 to the private cloud 106. For example, in one embodiment, when an ISV submits an application 112, the ISV can elect to have the application 112 also be published to the private cloud 106. In response to receiving the submitted application 112, the publication service 126 can then inform, for example, via an application notice 150, publish, or otherwise make the private cloud 106 aware of the submitted application 112. […] certain categories, classes, groups, or types of applications 112 can be automatically published to the private cloud 106 by default”; [0057] – “The DRP 134 can be configured to streamline secure deployment of cloud services in the private cloud 106 […] activate the DRP 134 for performing a deployment process of the application 112 in the private cloud 106”; [0063] – “the DRP 134 is configured to retrieve the application manifest 151 from the public cloud 108 […] the public cloud 108 provides the application manifest 151 to the DRP 134.”; [0067] – “the DRP 134 can be configured to transmit one or more component request 157 to the public cloud 108 requesting the one or more components of the application 112. In response, the publication service 126 (or other suitable types of service in the public cloud 108) can be configured to retrieve a copy of the components of the application 112' and provide the retrieved copy to the DRP 134 at the private cloud 106.”);
installing, by the private cloud server, a […] service from the plurality of available services in memory of the private cloud server ([0057] – “activate the DRP 134 for performing a deployment process of the application 112 in the private cloud 106.”; [0067] – “Upon receiving the application manifest 151, the DRP 134 can be configured to install components of the application 112 guided by the application manifest 151”; [0068] – “Upon receiving the one or more components of the application 112', the DRP 134 can be configured to utilize the instantiate computing resources to install the one or more components in one or more servers or nodes 105 (FIG. 2A) in the private cloud 106.”); […] and
[…] executing the the plurality of available services at the private cloud server, including executing the […] service at the private cloud server ([0057] – “The DRP 134 can be configured to streamline secure deployment of cloud services in the private cloud 106 […] activate the DRP 134 for performing a deployment process of the application 112 in the private cloud 106”; [0068] – “Upon receiving the one or more components of the application 112', the DRP 134 can be configured to utilize the instantiate computing resources to install the one or more components in one or more servers or nodes 105 (FIG. 2A) in the private cloud 106. […] The one or more nodes 105 can then execute the installed one or more components of the application 112 to provide the corresponding cloud service to the users 101”).
Pogrebinsky fails to expressly teach storing, on each respective server of the plurality of servers: a set of controls, the set of controls comprising a power control for monitoring power supplied to the respective server and a thermal control for monitoring a temperature of the respective server; a hardware abstraction layer (HAL) for communicating with a plurality of devices; a Desktop Bus (D-Bus) communications bus for communicating with the HAL and facilitating communications between a set of applications executing on the respective server; a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format; a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format; a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the respective server; and a set of instructions executable by a remote access controller (RAC) processor to execute the controls stored in memory in the RAC; and a telemetry service installed in the private cloud server; receiving, by the private cloud server, data from a set of servers of the plurality of servers; and in response to receiving the data, executing the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Gupta teaches storing, on each respective server of the plurality of servers ([0012] – “an IHS may be a […] server (e.g., blade server or rack server)”): a set of controls, the set of controls comprising a power control for monitoring power supplied to the respective server and a thermal control for monitoring a temperature of the respective server (FIG. 1, IHS 100 comprising BMC 132; [0021] – “BMC 132 may include a processor, memory”; [0022] – “BMC 132 may include or may be part of a Remote Access Controller”; [0003] – “Different types of sensors built into the IHS report to the BMC on parameters such as temperature, cooling fan speeds, power status, operating system (O/S) status, and the like. The BMC monitors the sensors.”; [0013] – “a baseboard management controller (BMC) configured on the IHS to obtain power profile data as well as thermal profile data for the hardware devices configured in the IHS, and, based on this data, optimally control the power and thermal system of the IHS”; [0026] – “The BMC 132 includes a BMC management operating system (O/S) 202 that stores and executes a RESTful server 204 and a power/thermal management application 206. The BMC management O/S may be stored on a memory of BMC 132”; [0030] – “The power/thermal management application 206 includes a data validator 222, an iterative thermal optimization tool 224, and a hardware device controller 226.”; [0032] – “Hardware device controller 226 uses the power/thermal data table entries 216 to derive an overall power profile and/or thermal profile for IHS 100, and controls the operation of certain hardware devices of IHS 100 according to the derived overall power profile and/or thermal profile. For example, hardware device controller 226, upon determining that the overall power profile of IHS 100 is at a specified amount (e.g., 175.0 Watts), controls PSUs 130 to generate that specified amount of electrical power. Additionally, upon determining that the overall thermal profile of IHS 100 is at a specified amount (e.g., 35 British Thermal Units (BTUs)), hardware device controller 226 may control fans 136 to generate that specified amount of cooling optimal for IHS 100. In one embodiment, hardware device controller 226 may be coupled to and receive thermal data from one or more temperature sensors 146 configured in IHS 100, and adjust a level of cooling provided to IHS 100 according to the received thermal data.”); […] and a set of instructions executable by a remote access control (RAC) processor to execute the controls stored in memory in the RAC ([0026] – “BMC 132 includes a BMC management operating system (O/S) 202 that stores and executes a RESTful server 204 and a power/thermal management application 206. The BMC management O/S may be stored on a memory of BMC 132 […] BMC 132 may include one or more processors (not shown), which is separate and distinct from system memory 104 of IHS 100, to execute the instructions of the BMC management O/S 200, RESTful server 204, and power/thermal management application 206.”).
Pogrebinsky is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor in configuring and installing services at a server in a private cloud. Gupta is also considered to be analogous art to the claimed invention because it is in the same field of configuring a remote access controller implemented in a server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the servers of Pogrebinsky to incorporate the teachings of Gupta. Doing so would enable remote monitoring and management of the servers to ensure sensed parameters, such as temperature and power, stay within pre-set limits, resulting in savings on the total cost of ownership of the servers (see Gupta: [0003]).
The combination of Pogrebinsky in view of Gupta fails to expressly teach a hardware abstraction layer (HAL) for communicating with a plurality of devices; a Desktop Bus (D-Bus) communications bus for communicating with the HAL and facilitating communications between a set of applications executing on the respective server; a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format; a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format; a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the respective server; and a telemetry service installed in the private cloud server; receiving, by the private cloud server, data from a set of servers of the plurality of servers; and in response to receiving the data, executing the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Bays teaches a hardware abstraction layer (HAL) for communicating with a plurality of devices ([0062] – “A Hardware Abstraction Layer (HAL) is thus provided for each forwarding hardware, where the HAL is configured to translate messages received via the control channel to forwarding hardware vendor-specific APIs.”; [0063] – “HAL 202 acts as an interface between control channel 112 and forwarding hardware 204 that is used to implement the hardware data plane subsystem.” ; [0009]-[0010] – controller, control plane subsystems, software and hardware data plane subsystems may be dispersed logically and/or physically on different devices); a Desktop Bus (D-Bus) communications bus for communicating with the HAL and facilitating communications between a set of applications executing on the respective server ([0014] – “The control plane subsystem may communicate with the first and second data plane subsystems using a control channel. The same control channel may be used irrespective of whether the target data plane subsystem is a software data plane subsystem or a hardware data plane subsystem.”; [0039] – “A control plane subsystem can communicate with multiple data plane subsystems in parallel or concurrently using a control channel 112.”; [0042]-[0044] – control channel 112 may use a ZeroMQ transport mechanism, such as a bus, which provides inter-process transport for messages, making it analogous to the “D-bus”; [0062] – “A Hardware Abstraction Layer (HAL) is thus provided for each forwarding hardware, where the HAL is configured to translate messages received via the control channel to forwarding hardware vendor-specific APIs.”; [0102] – the controller and different subsystems (“set of applications”) can execute on computing system 600, analogous to a server.
For clarity of the record, the Examiner would like to point to paragraph [0039] of the Specification, which recites “A D-Bus 18 or other inter-process communications mechanism may enable local communication between processes”. Accordingly, a D-Bus as recited in the claims is interpreted to be an inter-process communications mechanism.); a D-Bus to Remote Procedure Call (RPC) mapper for translating communications from one or more devices of the plurality of devices into an RPC format ([0063] – the HAL translates in both directions between the control channel 112 and the vendor-specific APIs of the forwarding hardware; [0064] – “HAL 202 may be configured to provide translations between various different messaging formats and various vendor-specific APIs. For example, HAL 202 may support interfaces based on various messaging or bus protocols such as REST, YANG, ZeroMQ and/or JSON, and others.”; [0034] – “using Network Configuration Protocol (NETCONF), which is a network management protocol developed and standardized by IETF. NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple remote procedure call (RPC) layer.”; [0037] – “NETCONF remote procedure calls”; [0075] – NETCONF protocol, i.e., an RPC-based protocol, may be used in communications between the controller and the forwarding hardware through the control plane subsystems, communication channel 112 (analogous to the D-Bus), and HAL which translates between message protocols.); a D-Bus to Representational State Transfer (REST) mapper for translating communications from one or more devices of the plurality of devices into a REST Application Programming Interface (API) format ([0063] – the HAL translates in both directions between the control channel 112 and the vendor specific APIs of the forwarding hardware; [0064] – “HAL 202 may be configured to provide translations between various different messaging formats and various vendor-specific APIs. For example, HAL 202 may support interfaces based on various messaging or bus protocols such as REST, YANG, ZeroMQ and/or JSON, and others.”).
Bays is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of enabling communication between various processes executing on the server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta to incorporate the teachings of Bays. Using a hardware abstraction layer capable of translating between an inter-process communications mechanism and specific formats, such as REST APIs and RPCs, provides a standardized interface regardless of the type of hardware being used, which increases flexibility and interoperability (see Bays: [0064]-[0065]).
The combination of Pogrebinsky in view of Gupta and Bays fails to expressly teach a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the respective server; and a telemetry service installed in the private cloud server; receiving, by the private cloud server, data from a set of servers of the plurality of servers; and in response to receiving the data, executing the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Juster teaches a Remote Procedure Call (RPC) queue to facilitate communication between two or more applications of the set of applications executing on the respective server (Col. 2, lines 3-13 – “an automated method is provided for assigning a plurality of remote procedure call (RPC) endpoints at runtime to a single server process, […]a single server process establishes a plurality of non-statically defined endpoints at runtime corresponding to various RPC services provided by the server process. Thus, the server process will have a plurality of RPC endpoints which do not conflict with other RPC applications.”; Col. 5, lines 10-29 – “MSMQ implements asynchronous communications by enabling applications to send messages to, and receive messages from, other applications. These applications may be running on the same machine or on separate machines connected by a network. MSMQ messages can contain data in any format that is understood by both the sender and the receiver. […] MSMQ keeps messages in holding areas called queues, hence the name message queuing. MSMQ queues protect messages from being lost in transit and provide a place for receivers to look for messages when they are ready. Applications make requests by sending messages to queues associated with the intended receiver. If senders expect responses in return, they must include the name of a response queue (that the sender must create in advance) in all requests that they make to the receiver.”).
Juster is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of enabling communication between various processes executing on the server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta and Bays to incorporate the teachings of Juster. Using an RPC queue as taught by Juster protects messages from being lost in transit and allows receiving processes to find messages when they are ready (see Juster: Col. 5, lines 22-24).
The combination of Pogrebinsky in view of Gupta, Bays, and Juster fails to expressly teach a telemetry service installed in the private cloud server; receiving, by the private cloud server, data from a set of servers of the plurality of servers; and in response to receiving the data, executing the telemetry service to aggregate portions of the data and remove redundant portions from the data.
However, Lawson teaches a telemetry service installed in the private cloud server ([0009] – “devices can then time-stamp collected or generated data and provide the time-stamped data to the cloud platform for storage and/or analysis by the cloud-based service or application.”; [0041] – “industrial devices 108 and 110 can be coupled to a cloud platform to leverage cloud-based applications. That is, the industrial device 108 and 110 can be configured to discover and interact with cloud-based computing services 112 hosted by cloud platform 102 […] cloud 102 can be a private cloud operated internally by the enterprise. An exemplary private cloud can comprise a set of servers hosting the cloud services 112 and residing on a corporate network”; [0043] – “cloud-based diagnostic applications can monitor the health of respective automation systems or their associated industrial devices across an entire plant, or across multiple industrial facilities that make up an enterprise”; [0051]-[0053] – “industrial controller 302 generates or collects (near) real-time data relating to controlled industrial processes 304.sub.1-304.sub.N, such as part counts, temperatures, pressures, motor speeds or loads, vibration data, weights, quality test results, alarms, machine states, operator feedback, or other such information. Some of this data is read by the industrial controller 302 directly from field devices (e.g., telemetry devices) associated with the processes themselves, while other data can be generated by control program 310 based on measured process values (e.g., alarms, derived or calculated values, etc.). […] Industrial controller 302 is configured to be cloud-capable, allowing it to connect to a web-based or private cloud platform and utilize cloud-based services hosted thereon (e.g., data storage, analysis, processing, etc.). […] To facilitate time-based analysis of the industrial data on the cloud platform, industrial controller 302 can include a time stamp component 312 configured to associate time stamps to the raw data 306 prior to pushing the data to the cloud platform.” The time stamped telemetry data is collected and provided to the cloud platform for analysis by the cloud-based services/applications.); receiving, by the private cloud server, data from a set of servers of the plurality of servers ([0057] – “some configurations may utilize a cloud proxy device that collects industrial data from multiple devices, time-stamps the data, and sends the time-stamped data to the cloud platform. Such a cloud proxy can be a dedicated data collection device, such as a server […] For industrial controllers such as PLCs or other automation controllers, this can include collecting data from telemetry devices connected to the controller's I/O”; [0072] – “industrial devices 1004 can comprise cloud proxy devices”; [0075] – “Time-stamped industrial data is received from industrial devices 1004 at device interface component 1014, which can store the received data on cloud storage 1012”); and in response to receiving the data, executing the telemetry service to aggregate portions of the data and remove redundant portions from the data ([0075] – “the received data may be filtered by a filter component 1016 prior to being moved to cloud storage 1012. Similar to local filter components described above (e.g., filter component 708 of FIG. 7), filter component 1016 can be configured to remove redundant data items or data not needed by the cloud-based data analysis system 1002 in accordance with any specified filtering criterion. […] Filter component 1016 can also be configured to identify redundant data items received from two different devices. […] filter component 1016 can be configured to identify the duplicated data items (e.g., by virtue of a common data tag name or other identification methodology) and discard one of the duplicated values.”; [0076]-[0077] – the received data may be analyzed and grouped into subsets by the cloud-based data analysis system 1002).
Lawson is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of remotely monitoring and managing a plurality of computing devices, e.g., through collection of telemetry data at a private cloud server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the services installed in the private cloud servers of Pogrebinsky to include a telemetry service which receives data from the server(s), and in response, aggregates portions of the data and removes redundant portions from the data as taught by Lawson. Incorporating the private cloud based telemetry service of Lawson would enable aggregation of data from a plurality of sources/locations, e.g., a plurality of different devices, for analysis to determine events occurring at a plurality of devices and their interdependencies or impacts at other locations and would provide easily scalable storage (e.g., cloud-based storage) of the large amounts of data generated by an enterprise (see Lawson: [0006], [0009], and [0043]). Further, removal of redundant portions of data before storage as described by Lawson (see Lawson: [0075]), would provide for more efficient storage of data and reduce the storage resources required.
Claims 2-3, 9-10, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Pogrebinsky in view of Gupta, Bays, Juster, and Lawson as applied to claims 1, 8 and 15 above, and further in view of Drury et al. (U.S. Pub. No. 2022/0276876), hereinafter Drury, and MATSUURA et al. (U.S. Pub. No. 2020/0034209), hereinafter MATSUURA.
Regarding claim 2, the combination of Pogrebinsky in view of Gupta, Bays, Juster, and Lawson teaches the system of claim 1. Pogrebinsky further teaches wherein: the set of PCS instructions are executable by the PCS processor to:
[manage an available service] of the set of available services stored in the memory in the PCS ([0069] – “The DRP 134 can also store a copy of the one or more components of the application 112' in the repository 111' for deploying additional instances of the application 112'”; [0057] – “the administrator 103 of the private cloud 106 can elect to deploy a cloud service corresponding to the application 122 in the private cloud 106. As shown in FIG. 3A, the administrator 103 can provide a deployment instruction 152 to the resource manager 122' to activate the DRP 134 for performing a deployment process of the application 112 in the private cloud 106.”) […]; install the available service [in the server] ([0068]-[0069] – “the DRP 134 can be configured to utilize the instantiate computing resources to install the one or more components in one or more servers or nodes 105 (FIG. 2A) in the private cloud 106. […] The one or more nodes 105 can then execute the installed one or more components of the application 112 to provide the corresponding cloud service to the users 101 (FIG. 1). The DRP 134 can also store a copy of the one or more components of the application 112' in the repository 111' for deploying additional instances of the application 112'”).
The combination of Pogrebinsky, Gupta, Bays, Juster, and Lawson fails to expressly teach the PCS server to determine an available service […] is needed by the server to process a set of information; install the determined service in a set of services in the memory in the RAC; determine when the available service has processed the information; and uninstall the available service from the set of services in the memory in the RAC.
However, Drury teaches determine an available service […] is needed by the server to process a set of information and installing the determined service in a set of services in the memory in the RAC ([0014] – “The BMCs may include their own processors, memories, and interfaces to remote servers, each other, and to servers attached or connected thereto. […] The motherboards may be connected to BMCs, subassemblies or subsystems for any suitable auxiliary functions, caddies for storage, or front panels for user interface operations”; [0017] – “The superset of device drivers may include device drivers for hardware not present on the respective first or second BMC. The first BMC may include circuitry further configured to determine newly added hardware in the respective first or second BMC, and update the device drivers on the respective first or second BMC from the locally stored superset of device drivers for the respective first or second BMC to accommodate the newly added hardware.”; [0034] – “BMC 102 may provide a variety of services for the baseboard or larger system or server where it is installed, such as server 114. […] One challenge for BMC 102 is the component makeup of the operating environment of the baseboard or server 114. In addition to the main processing core, additional hardware modules can be added to server 114. BMC 102 may need to be able to identify these subsystems and adapt its function to manage them. These plug-in modules need not have been explicitly defined at the creation of BMC 102, as new ones can be added to the baseboard or server 114 as they are developed and a later time. BMC 102 may be extensible such that it can accommodate the new modules.”; [0035] – “BMC 102 can use the single software installation to align the driver set to match the current device tree. This may include adding new drivers for any new hardware devices that are added to the device tree once it is rebuilt. single software image for BMC 102 that can access any suitable tree of devices may offer the advantage of simpler manufacturing”; [0036] – “BMC 102 may provide standard functions, such as monitoring physical parameters of operation of server 114 against prescribed levels. However, by adding access for BMC 102 to other programmable devices and configurable devices, BMC 102 may have increased capabilities in embodiments of the present disclosure.”; [0057] – “ BMC 102 may contain a universal library of device drivers that provide support for all hardware available in the server configuration. When a server component is changed, BMC 102 can detect the new hardware configuration and install the required hardware driver from the universal library directly into motherboard firmware and UEFI 306. […] Drivers can then be loaded without powering any additional server components. The new drivers may be available when server 114 powers up and boots into normal operation”; [0059] – “BMC 102 and SoC 302 share common memory elements including motherboard shared memory 304 and motherboard firmware and UEFI 306.” A server with a first BMC may be configured to determine new hardware and device drivers (software/firmware to be executed on the server allowing the BMC to provide additional functions, i.e., “services” as described in Drury [0034]-[0036]) for managing the new hardware are needed in a second server with a second BMC.).
Drury is considered to be analogous art to the claimed invention because it is in the same field of configuring a remote access controller implemented in a server. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta, Bays, Juster, and Lawson to incorporate the teachings of Drury. The methods for implementing the extensible baseboard management controller (analogous to a remote access controller) taught by Drury offer advantages of simpler manufacturing while also allowing the BMC to have increased capabilities beyond its standard functions (see Drury: [0034]-[0036]).
The combination of Pogrebinsky in view of Gupta, Bays, Juster, Lawson and Drury fails to expressly teach the PCS server to determine when the available service has processed the information; and uninstall the available service from the set of services in the memory in the RAC.
However, MATSUURA teaches determine when the available service has processed the information ([0077] – “In a case where the execution request is received, the processing server 130 returns OK to the resource management server 120 (S514), and executes the application (S517).”; [0078] – “the resource management server 120 […] and monitors an execution situation of the application of the processing server 130.”; [0102] – “FIG. 8 is a sequence diagram illustrating a flow of processing that is performed in each of the servers of the information processing system when the execution of the application of the processing server 130 is ended.”); and uninstall the available service from the [server] ([0103] – “the resource management server 120 executes the cluster deletion unit 125. The cluster deletion unit 125 specifies the processing server 130 in the cluster and the application name with reference to the data table 300 that is managed by the resource allocation information storage unit 121 (S802). Next, an application deletion request (S803) is transmitted to each of the specified processing servers 130.”; [0104] – “Each of the processing servers 130 receiving the application deletion request uninstalls the application (S804), and returns a completion notification (S805) to the resource management server 120”).
MATSUURA is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of implementing a plurality of services in cloud servers. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, and Drury such that after installing the service in memory of the RAC as taught by Drury, execution of (i.e., processing performed by) the service is monitored to determine when it is done executing and subsequently uninstalling the service as taught by MATSUURA. Doing so ensures complete processing of a service even in a resource depleted environment such that quality of service is maintained (see MATSUURA: [0008] and [0013]).
Regarding claim 3, the combination of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury and MATSUURA teaches the system of claim 2. Drury, as applied to the teachings of Pogrebinsky specifically with respect to the PCS server, further teaches wherein the set of PCS instructions are executable by the PCS processor to determine the available service of the set of available services stored in the memory in the PCS increases the scope of operation of the server to process the set of information (Drury: [0034]-[0036] – “BMC 102 may provide a variety of services for the baseboard or larger system or server where it is installed, such as server 114. […] One challenge for BMC 102 is the component makeup of the operating environment of the baseboard or server 114. In addition to the main processing core, additional hardware modules can be added to server 114. BMC 102 may need to be able to identify these subsystems and adapt its function to manage them. These plug-in modules need not have been explicitly defined at the creation of BMC 102, as new ones can be added to the baseboard or server 114 as they are developed and a later time. BMC 102 may be extensible such that it can accommodate the new modules […] BMC 102 can use the single software installation to align the driver set to match the current device tree. This may include adding new drivers for any new hardware devices that are added to the device tree once it is rebuilt […] BMC 102 may provide standard functions, such as monitoring physical parameters of operation of server 114 against prescribed levels. However, by adding access for BMC 102 to other programmable devices and configurable devices, BMC 102 may have increased capabilities in embodiments of the present disclosure.”).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta, Bays, Juster, and Lawson to incorporate the teachings of Drury. The methods for implementing the extensible baseboard management controller (analogous to a remote access controller) taught by Drury offer advantages of simpler manufacturing while also allowing the BMC to have increased capabilities, such as controlling/managing newly added hardware, beyond its standard functions (see Drury: [0017] and [0034]-[0036]).
Claim 9-10 recite substantially the same additional limitations as claims 2-3, applied to the data center of claim 8. Accordingly, claims 9-10 are rejected as being unpatentable over Pogrebinsky in view of Gupta, Bays, Juster and Lawson as applied to claim 8, and further in view of Drury and MATSUURA for the same reasons presented with respect to claims 2-3.
Claim 16-17 recite substantially the same additional limitations as claims 2-3, applied to the method of claim 15. Accordingly, claims 16-17 are rejected as being unpatentable over Pogrebinsky in view of Gupta, Bays, Juster, and Lawson as applied to claim 15, and further in view of Drury and MATSUURA for the same reasons presented with respect to claims 2-3.
Claim 4-6, 11, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury and MATSUURA as applied to claims 2 and 3 above, and further in view of NARAYAN et al. (U.S. Pub. No. 2018/0129503), hereinafter NARAYAN.
Regarding claim 4, the combination of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury and MATSUURA teaches the system of claim 3, but fails to teach wherein the available service comprises one of a credentialing service, a telemetry service, an advanced power service or an advanced thermal service.
However, NARAYAN teaches wherein the available service comprises one of a credentialing service, a telemetry service, an advanced power service or an advanced thermal service ([0021] – “distributed computing environments may include a hyperscale computing environment, a cloud computing environment, data centers, and/or the like. In some embodiments, event digests may be used to monitor, perform scheduling, and support error handling in a distributed computing environment.”; [0035] – “each compute node 210 may be embodied as […] a server”; [0042] – “compute nodes 210 may include event digest application 280 as firmware and/or operate (for instance, via execution by one or more of processors 220a-n) a client version of event digest application. In various embodiments, event digest application 280 operating on compute nodes 210 may include a monitoring agent to monitor and obtain values from event digests.”; [0050] – “an event digest may not be available to a host OS and, for example, may be published using a platform sideband or out-of-band communication channel […] a telemetry consumer may access the out-of-band channel and collect or receive metrics in various states of the system”; [0052] – “A remote telemetry consumer may collect these values using an out-of-band channel with IPMI, for example, over Remote Management Control Protocol (RMCP) by using a baseboard management controller (BMC)”; [0078] – “Hosts 910a-n may include an ME 915a-n and a BMC 920a-n. In various embodiments, MBC 920a-n may be connected to one or more network controllers (such as network interface controllers (NICs)) to provide out-of-band communications and manageability. In some embodiments, orchestrator 905 may generate a query 940 to obtain information from or about hosts 910a-n. For instance, query 940 may include an out-of-band query operative to obtain event digest information generated”; [0087] – “Logic flow 1100 may obtain the event digest at block 1110. For example, a monitoring agent of compute nodes 210 (for instance, event digest application 280) may obtain an event digest value from the event digest. […] At block 1112, the event digest may be published. For example, the monitoring agent of compute hosts 260 may publish or otherwise provide the event digest and/or event digest values to cloud controller 260 or compute hosts of cloud 81 may provide the event digest and/or event digest values to cloud orchestrator 820. […] telemetry consumer (for instance, cloud controller 260) may access the out-of-band channel and collect or receive metrics in various states of the system.” Event digest information (i.e., telemetry information), generated by event digest firmware/software (a “telemetry service”) executing on one or more servers is provided to telemetry consumers by the BMCs. Thus, the BMC of a compute node 210 is configured to provide a telemetry service.
For clarity of the record, the above claim recites limitations in the alternative. Accordingly, only one of the alternatives is required by the claims. The alternative which the Examiner has interpreted to be taught by NARAYAN is “a telemetry service”.).
NARAYAN is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of managing servers in a data center. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury and MATSUURA to incorporate the teachings of NARAYAN. Using firmware implementing out-of-band monitoring, aggregation, and analysis of telemetry data (i.e., providing “a telemetry service”) of servers in a data center reduces overhead and latency while minimizing impact to the host when compared to in-band methods of telemetry collection (see NARAYAN: [0025] and [0028]). Further, the event digest processes of NARAYAN address scalability of a monitoring solution to environments such as data centers or cloud computing environments (see [0021]-[0023]). Lastly, it would have been obvious to one of ordinary skill in the art that one of available services could be the telemetry service as taught by NARAYAN, as Gupta suggests the remote access controller is responsible for monitoring and managing the physical state of the server using executable firmware to provide the monitoring capabilities (see Gupta: [0003] and [0026]).
Regarding claim 5, the combination of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury and MATSUURA teaches the system of claim 2, but fails to teach wherein the set of services comprises a time-critical service.
However, NARAYAN teaches wherein the set of services comprises a time-critical service ([0003] – “Data centers employing hyperscale platforms require vast amounts of telemetry data and face substantive scalability issues. The telemetry processes in such environments require fast responsiveness and high polling rates”; [0022] – “Hyperscale data centers require a vast amount of telemetry data and face material scalability issues. Nonlimiting examples of telemetry usage within a hyperscale data center may include […], power management, thermal management, and/or the like. Some telemetry usages, such as fault detection and thermal management, require fast responsiveness and high polling rates”; [0028] – “the out-of-band telemetry with an event digest process configured according to some embodiments”; [0035] – “each compute node 210 may be embodied as […] a server”; [0042] – “compute nodes 210 may include event digest application 280 as firmware and/or operate (for instance, via execution by one or more of processors 220a-n) a client version of event digest application. In various embodiments, event digest application 280 operating on compute nodes 210 may include a monitoring agent to monitor and obtain values from event digests.”; [0052] – “A remote telemetry consumer may collect these values using an out-of-band channel with IPMI, for example, over Remote Management Control Protocol (RMCP) by using a baseboard management controller (BMC)”; [0078] – “Hosts 910a-n may include an ME 915a-n and a BMC 920a-n. In various embodiments, MBC 920a-n may be connected to one or more network controllers (such as network interface controllers (NICs)) to provide out-of-band communications and manageability. In some embodiments, orchestrator 905 may generate a query 940 to obtain information from or about hosts 910a-n. For instance, query 940 may include an out-of-band query operative to obtain event digest information generated”; [0087] – “Logic flow 1100 may obtain the event digest at block 1110. For example, a monitoring agent of compute nodes 210 (for instance, event digest application 280) may obtain an event digest value from the event digest. Monitoring agent may obtain the event digest values at a specified monitoring interval, such as every 1 ms, every 10 ms, every 100 ms, every 1 s, every 5 s, and/or any value or range between any two of these values (including endpoints). […] At block 1112, the event digest may be published. For example, the monitoring agent of compute hosts 260 may publish or otherwise provide the event digest and/or event digest values to cloud controller 260 or compute hosts of cloud 81 may provide the event digest and/or event digest values to cloud orchestrator 820. […] telemetry consumer (for instance, cloud controller 260) may access the out-of-band channel and collect or receive metrics in various states of the system.” The firmware implementing the event digest application/monitoring agent, when executed, perform operations to obtain and provide telemetry data (i.e., act as a “telemetry service”) for usages which are time-critical as explained in NARAYAN paragraphs [0003] and [0022]. Thus, the telemetry service itself is a time-critical service as the telemetry data obtained and provided may be time-critical.).
NARAYAN is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of managing servers in a data center. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury and MATSUURA to incorporate the teachings of NARAYAN. Using firmware implementing out-of-band monitoring, aggregation, and analysis, and usage of telemetry data (i.e., providing “a telemetry service”, which may be time-critical as disclosed NARAYAN [0003] and [0022]) of servers in a data center reduces overhead and latency while minimizing impact to the host when compared to in-band methods of telemetry collection (see NARAYAN: [0025] and [0028]). Further, the event digest processes of NARAYAN address scalability of a monitoring solution to environments such as data centers or cloud computing environments (see [0021]-[0023]). Lastly, it would have been obvious to one of ordinary skill in the art that one of available services could be the telemetry service, used for time-critical applications such as thermal management, as taught by NARAYAN, as Gupta suggests the remote access controller is responsible for monitoring and managing the physical state, such as the temperature, of the server using executable firmware to provide the monitoring capabilities (see Gupta: [0003], [0026], and [0032]).
Regarding claim 6, the combination of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury, MATSUURA, and NARAYAN teaches the system of claim 5. NARAYAN further teaches wherein the time-critical service comprises one or more of an advanced power service, a thermal service or a telemetry service ([0021] – “distributed computing environments may include a hyperscale computing environment, a cloud computing environment, data centers, and/or the like. In some embodiments, event digests may be used to monitor, perform scheduling, and support error handling in a distributed computing environment.”; [0035] – “each compute node 210 may be embodied as […] a server”; [0042] – “compute nodes 210 may include event digest application 280 as firmware and/or operate (for instance, via execution by one or more of processors 220a-n) a client version of event digest application. In various embodiments, event digest application 280 operating on compute nodes 210 may include a monitoring agent to monitor and obtain values from event digests.”; [0050] – “an event digest may not be available to a host OS and, for example, may be published using a platform sideband or out-of-band communication channel […] a telemetry consumer may access the out-of-band channel and collect or receive metrics in various states of the system”; [0052] – “A remote telemetry consumer may collect these values using an out-of-band channel with IPMI, for example, over Remote Management Control Protocol (RMCP) by using a baseboard management controller (BMC)”; [0078] – “Hosts 910a-n may include an ME 915a-n and a BMC 920a-n. In various embodiments, MBC 920a-n may be connected to one or more network controllers (such as network interface controllers (NICs)) to provide out-of-band communications and manageability. In some embodiments, orchestrator 905 may generate a query 940 to obtain information from or about hosts 910a-n. For instance, query 940 may include an out-of-band query operative to obtain event digest information generated”; [0087] – “Logic flow 1100 may obtain the event digest at block 1110. For example, a monitoring agent of compute nodes 210 (for instance, event digest application 280) may obtain an event digest value from the event digest. […] At block 1112, the event digest may be published. For example, the monitoring agent of compute hosts 260 may publish or otherwise provide the event digest and/or event digest values to cloud controller 260 or compute hosts of cloud 81 may provide the event digest and/or event digest values to cloud orchestrator 820. […] telemetry consumer (for instance, cloud controller 260) may access the out-of-band channel and collect or receive metrics in various states of the system.” Event digest information (i.e., telemetry information), generated by event digest firmware/software (a “telemetry service”) executing on one or more servers is provided to telemetry consumers by the BMCs. Thus, the BMC of a compute node 210 is configured to provide a telemetry service.
For clarity of the record, the above claim recites limitations in the alternative. Accordingly, only one of the alternatives is required by the claims. The alternative which the Examiner has interpreted to be taught by NARAYAN is “a telemetry service”.).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury and MATSUURA to incorporate the teachings of NARAYAN. Using firmware implementing out-of-band monitoring, aggregation, and analysis of telemetry data (i.e., providing “a telemetry service”) of servers in a data center reduces overhead and latency while minimizing impact to the host when compared to in-band methods of telemetry collection (see NARAYAN: [0025] and [0028]). As taught by NARAYAN, collection and usage of telemetry data, e.g., for thermal management, may be time-critical (see NARAYAN: [0003] and [0022]). Further, the event digest processes of NARAYAN address scalability of a monitoring solution to environments such as data centers or cloud computing environments (see [0021]-[0023]). Lastly, it would have been obvious to one of ordinary skill in the art that one of available services could be the telemetry service, used for time-critical applications such as thermal management, as taught by NARAYAN, as Gupta suggests the remote access controller is responsible for monitoring and managing the physical state, such as the temperature, of the server using executable firmware to provide the monitoring capabilities (see Gupta: [0003], [0026], and [0032]).
Claim 11 recites substantially the same additional limitations as claim 4, applied to the data center of claim 10. Accordingly, claim 11 is rejected as being unpatentable over Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury, and MATSUURA and further in view of NARAYAN for the same reasons presented with respect to claim 4 above.
Claims 18-20 recite substantially the same additional limitations as claims 4-6, applied to the method of claim 17. Accordingly, claims 18-20 are rejected as being unpatentable over Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury, and MATSUURA and further in view of NARAYAN for the same reasons presented with respect to claims 4-6 above.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury and MATSUURA as applied to claim 2 above, and further in view of Herzberg et al. (U.S. Pub. No. 2023/0259349), hereinafter Herzberg.
Regarding claim 7, the combination of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury and MATSUURA teaches the system of claim 2. Pogrebinsky further teaches wherein the memory in the PCS stores: a unified database storing information for […] and one or more of the available services in the set of available services ([0049] – “repository 111 containing records of applications 112 individually corresponding to a cloud service. The repository 111 can include a database”; [0052]-[0053] – “The publication service 126 can be configured to receive applications 112 from, for example, independent software vendors (ISVs) or other suitable sources […] The publication service 126 can then be configured to store one or more copies of various components and artifacts of the applications 112 in, for example, a repository 111 or other suitable network storage (not shown) in the public cloud 108. Components of an application 112 can include executables, libraries, databases, and/or other suitable software modules,”; [0055] – “repository 111' can be generally similar to those of the public cloud 108 […] The repository 111' can be configured to store records of applications 112' published in the private cloud 106”; [0069] – “The DRP 134 can also store a copy of the one or more components of the application 112' in the repository 111'”).
Drury further teaches a database storing information for one or more controls for the BMC ([0017] – “the first BMC may include circuitry further configured to locally store a superset of device drivers for the first or second BMC. The superset of device drivers may include device drivers for hardware not present on the respective first or second BMC. The first BMC may include circuitry further configured to determine newly added hardware in the respective first or second BMC, and update the device drivers on the respective first or second BMC from the locally stored superset of device drivers for the respective first or second BMC to accommodate the newly added hardware.”; [0034] – “BMC 102 may provide a variety of services for the baseboard or larger system or server where it is installed, such as server 114.”; [0035] – “appropriate drivers for manipulating and instrumenting any attached devices.”; [0057] – “BMC 102 may contain a universal library of device drivers that provide support for all hardware available in the server configuration. When a server component is changed, BMC 102 can detect the new hardware configuration and install the required hardware driver from the universal library directly into motherboard firmware and UEFI 306. Using OOB channel 128, management server 116 can communicate with BMC 102 and maintain the universal library through updates.” Drivers (software/firmware to be executed on the server allowing the BMC to provide additional functions, i.e., “services” as described in Drury [0034]-[0036]) are used to manipulating/control new hardware.).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta, Bays, Lawson, and Juster to incorporate the teachings of Drury. The methods for implementing the extensible baseboard management controller (analogous to a remote access controller) taught by Drury offer advantages of simpler manufacturing while also allowing the BMC to provide increased services to the server in which it is installed, such as controlling/managing newly added hardware, beyond its standard functions (see Drury: [0017] and [0034]-[0036]).
The combination of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury and MATSUURA fails to expressly teach a management service orchestrator (MSO) for resolving conflicts between two or more of the available services in the set of available services executing on the PCS.
However, Herzberg teaches a management service orchestrator (MSO) for resolving conflicts between two or more of the available services in the set of available services executing on the PCS ([0036]-[0037] – “the first application data may indicate that a first file is stored when the first application is installed, and the first application policy may indicate that the first file is allowed to execute. Similarly, the computing system(s) 100 may, using the second application data, generate a second application policy to control access of the second application. Using the first and second application policies, the computing system(s) 100 may generate an optimized set of application policies 108. In generating the optimized set of application policies 108, the computing system(s) 100 may eliminate duplicate policies and may resolve conflicts between policies. For example, execution of the first and second applications may involve use of the same file/data, which may result in the first and second application policies including duplicative rules. To reduce the number of rules in the application policies 108, the computing system(s) 100 may delete one or more of the rules, which reduces the amount of processing that the client/user device 202 has to perform in enforcing application control. In another example, if the first application is authorized and the second application is unauthorized, and execution of the first and second applications involve use of the same file/data, then the first and second application policies may be in conflict. Keeping both of the first and second application policies may result in blocking/disabling of the authorized first application, or may result in allowing/enabling of the unauthorized second application. To avoid this outcome, the computing system(s) 100 may resolve the conflict between the first and second application policies, so that the authorized first application is enabled and the unauthorized second application is disabled.”; [0041] – “a client 202 may have the capacity to function as both a client node seeking access to resources provided by a server 204 and as a server 204 providing access to hosted resources for other clients 202.”; [0056] – “the cloud computing environment 400 may provide a private cloud serving a single organization (e.g., enterprise cloud)”; [0111] – “The policy generator 630 may also be configured to handle conflicts between policies for authorized applications and unauthorized applications. […] Keeping the individual policies may result in blocking/disabling of the authorized first application, or may result in allowing/enabling of the unauthorized second application. To avoid this outcome, the policy generator 630 may resolve the conflict between the individual policies, so that the authorized first application is enabled and the unauthorized second application is disabled.”).
Herzberg is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor in configuring and installing services at a server in a private cloud. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Pogrebinsky in view of Gupta, Bays, Juster, Lawson, Drury, and MATSUURA to incorporate the teachings of Herzberg. Doing so improves security by avoiding conflicts during execution of multiple applications that use the same data (see Herzberg: [0015]-[0016] and [0037]).
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Pogrebinsky in view of Gupta, Bays, Juster, and Lawson as applied to claim 8 above, and further in view of NARAYAN.
Claims 12-23 recite substantially the same additional limitations as claims 5-6, applied to the data center of claim 8. Accordingly, claims 12-13 are rejected as being unpatentable over Pogrebinsky in view of Gupta, Bays, Juster, and Lawson, and further in view of NARAYAN for the same reasons presented with respect to claims 5-6 above.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Pogrebinsky in view of Gupta, Bays, Juster, and Lawson as applied to claim 8 above, and further in view of Drury and Herzberg.
Claim 14 recites substantially the same additional limitations as claim 7, applied to the data center of claim 8. Accordingly, claim 14 is rejected as being unpatentable over Pogrebinsky in view of Gupta, Bays, Juster, and Lawson as applied to claim 8, and further in view of Drury and Herzberg for the same reasons presented with respect to claim 7.
Response to Arguments
Applicant's arguments filed 2/25/2026 with respect to the double patenting rejections have been fully considered but they are not persuasive.
The Applicant must file a terminal disclaimer as a complete and proper response to a double patenting rejection. Applicant's request to hold the non-statutory double patenting rejection in abeyance is not a complete response. "A complete response to a nonstatutory double patenting (NSDP) rejection is either a reply by applicant showing that the claims subject to the rejection are patentably distinct from the reference claims, or the filing of a terminal disclaimer in accordance with 37 CFR 1.321 in the pending application(s) with a reply to the Office action (see MPEP § 1490 for a discussion of terminal disclaimers). Such a response is required even when the nonstatutory double patenting rejection is provisional. As filing a terminal disclaimer, or filing a showing that the claims subject to the rejection are patentably distinct from the reference patent's claims, is necessary for further consideration of the rejection of the claims, such a filing should not be held in abeyance. Only compliance with objections or requirements as to form not necessary for further consideration of the claims may be held in abeyance until allowable subject matter is indicated." See MPEP 804(1)(8)(1). Additionally see MPEP 1490 for a discussion of terminal disclaimers.
Applicant’s arguments, see pages 11-12 of the Remarks, filed 2/25/2026, with respect to the rejection(s) of the claims under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of new reference Lawson et al. (U.S. Pub. No. 2013/0212420).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
NARNAKAJE VENUGOPALA et al. (U.S. Pub. No. 2019/0379576) teaches a software-defined data center manager service collecting information of events in an SDDC, comprising a plurality of hardware servers in a private cloud environment, removing duplicate events, and combining related events into a single telemetry element (see [0028], [0044]).
Picou et al. (U.S. Pub. No. 2023/0344810) teaches a plurality of secondary workstations in a private network of an enterprise sending telemetry data to a primary workstation, where the primary workstation removes redundant entries and provides the consolidated data to a remote server (see [0020], [0031], and [0035]).
Friel et al. (U.S. Pub. No. 2018/0027309) teaches a telemetry server, e.g., in a private cloud, receiving a plurality of telemetry data streams from a plurality of data sources, identifying redundancies in the data streams, and adjusting collection of telemetry data in the data streams to reduce redundant data (see [0012] and [0022]-[0023]).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 8:00 am - 4:00 pm.
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, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights