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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 17, 2025 has been entered.
Status of Claims
No claims have been amended.
Claims 1 – 22, 25, 30 – 36, 38 have been cancelled.
Claims 39 – 42 are new.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 23, 24, 26 – 29, 37, 39 – 42 are rejected under 35 U.S.C. 103 as being unpatentable over Sinha et al. (US PGPub 2017/0284691 A1) in view of arcserve (4 Areas Where Multi-core Processing Really Matters) in view of Rochford (WO 2018/128475 A1) in further view of Home Assistant ([Component] Control4 Integration).
In regards to claim 23, Sinha discloses a method for managing building subsystems comprising the steps of:
transmitting from more than one sub-system data related to elements of the sub-systems to more than one servers, wherein a first element from a first sub-system is a thermostat, wherein a second element from a second sub-system is lighting, wherein the first sub-system and the second sub-system are part of a building (¶ 2, 3, 22, 23, 25, 46, 28, 85, 86, 87, 126, 137 wherein the BMS is configured to manage and communicate with a plurality of IoT devices, i.e. a plurality of elements, within a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices and wherein each building has its own BMS to control the respective building, thereby resulting each building and its respective BMS having one or more systems and sub-systems that can be monitored and managed.
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.
With regards to the first element being a thermostat, see the additional analysis provided below);
receiving at a first server data from the first sub-subsystem (¶ 50, 51, 92 wherein the network includes, at least, any number of: gateway, network switches, routers, servers, devices (such as, but not limited to those discussed above);
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.);
processing by the first server the data received from the first sub-system by running a plurality of diagnostics session and analytics session on the data received from the first sub-system, wherein a number of diagnostic sessions and analytic sessions is variably determined based on cores on the first server, wherein the number of diagnostic sessions and analytic sessions are evenly spread over the cores of the first server (¶ 49, 53, 63, 79, 80, 81 wherein diagnostic information is provided for each respective element; ¶ 47, 53, 54, 57, 63 wherein analytics information for each respective element is provided; ¶ 50, 51, 92 wherein the network includes, at least, any number of: gateway, network switches, routers, servers, devices (such as, but not limited to those discussed above);
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.;
In light of the specification (¶ 60, 65, 66, 68), the Examiner asserts that the invention is simply capable of being performed using one or more servers that may be hardware, software, or a combination thereof. With that said, Sinha at ¶ 51 which discloses that “Network 404 may include any number of computing devices (e.g., computers, servers, routers, network switches, etc.) configured to transmit, receive, or relay data. Network 404 may further include any number of hardwired and/or wireless connections. For example, smart connected HVAC equipment 408 may communicate wirelessly (e.g., using a Wi-Fi_33 or cellular radio, etc.) with a transceiver that is hardwired (e.g., via a fiber optic cable, a CAT5 cable, etc.) to a computing device of network 404.”; ¶ 90 also discloses “…the gateway 1128 includes a number of field gateway aspects that primarily interface with devices and cloud-based servers.”; see also ¶ 92;
Additionally, with regards to “wherein a number of diagnostic sessions and analytic sessions is variably determined based on cores on the first server, wherein the number of diagnostic sessions and analytic sessions are evenly spread over the cores of the first server”, see ¶ 93 “IoT platform 1140 of ecosystem 1100 may include a network of physical objects or "things" embedded with electronics, software, sensors, and/or network connectivity that enable such objects to collect and exchange data. The loT platform 1140 may facilitate linking the physical and digital world by allowing remote sensing and control of devices across new and/or previously existing communication infrastructure. The IoT platform 1140 represents components and technologies that may enable delivering an end-to-end solution for IoT enabled products and services. The IoT platform 1140 also can include various processes and applications, which may further be utilized in creating and maintaining an IoT ecosystem 1100.”; ¶ 105 “Analytics technology concept 114 may include a massively parallel analytics module 1158. The massively parallel data analytics module 1158 may include multiple processors configured to run analytical processing. The massively parallel data analytics module 1158 may divide large data sets into smaller segments that are analyzed (e.g., operated on, etc.) by specifically assigned processors (e.g., with their own operating system and memory, etc.). Messaging interfaces may aggregate the results following the analysis by each processor. Such a system may allow for improvements in processing and flexible scalability.”; See also ¶ 53, 82, 83, 85, 89, 91, 92; In the event that the applicant disagrees with this analysis, the Examiner has provided an additional analysis in view of arcserve to more explicitly teach this aspect of the claimed invention.
As a result, although Sinha does not disclose the limitation word for word (e.g., “sub-system”, previously recited “PI” server (previously amended to now recite “server), “session”, and “driver”) in light of the applicant’s specification, the Examiner asserts that Sinha does, indeed, disclose the specific combination of elements of the claimed limitation as supported by the broad recitation of possibilities disclosed in the specification(e.g., the broad concept of what is involved in the “diagnostics session” and “analytics session”). In other words, Sinha discloses the claimed invention in the manner that it has been described and supported in the specification.);
In regards to:
transmitting the processed data received from the first sub-system to a hub operably connected to more than on servers;
receiving at the hub the processed data received from the first sub-system, wherein the processed data from the first subsystem has undergone multiple diagnostic sessions in multiple streams to diagnose instances and multiple analytic sessions in multiple streams to analyze instances
(¶ 94, 119, 147, 165 wherein information is communicating from a smart device to a network device, e.g., NAT, firewall, router, etc., and hub;
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.
¶ 58, 59, 60, 68, 79, 84, 106 wherein the system is continuously collecting and analyzing in real-time over time for each of the plurality of elements that it is monitoring, diagnosing, and analyzing, i.e. the diagnostics and analytics is comprised of running multiple session in multiple streams to diagnose and analyze instances; ¶ 2, 3, 22, 23, 25, 46, 28, 85, 86, 87, 126, 137 wherein the BMS is configured to manage and communicate with a plurality of IoT devices, i.e. a plurality of elements, within a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices and wherein each building has its own BMS to control the respective building, thereby resulting each building and its respective BMS having one or more systems and sub-systems that can be monitored and managed.; Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.
Additionally, with regards to “receiving at the hub the processed data received from the first sub-system, wherein the processed data from the first subsystem has undergone multiple diagnostic sessions in multiple streams to diagnose instances and multiple analytic sessions in multiple streams to analyze instances ”, see ¶ 93 “IoT platform 1140 of ecosystem 1100 may include a network of physical objects or "things" embedded with electronics, software, sensors, and/or network connectivity that enable such objects to collect and exchange data. The loT platform 1140 may facilitate linking the physical and digital world by allowing remote sensing and control of devices across new and/or previously existing communication infrastructure. The IoT platform 1140 represents components and technologies that may enable delivering an end-to-end solution for IoT enabled products and services. The IoT platform 1140 also can include various processes and applications, which may further be utilized in creating and maintaining an IoT ecosystem 1100.”; ¶ 105 “Analytics technology concept 114 may include a massively parallel analytics module 1158. The massively parallel data analytics module 1158 may include multiple processors configured to run analytical processing. The massively parallel data analytics module 1158 may divide large data sets into smaller segments that are analyzed (e.g., operated on, etc.) by specifically assigned processors (e.g., with their own operating system and memory, etc.). Messaging interfaces may aggregate the results following the analysis by each processor. Such a system may allow for improvements in processing and flexible scalability.”; See also ¶ 53, 82, 83, 85, 89, 91, 92; In the event that the applicant disagrees with this analysis, the Examiner has provided an additional analysis in view of arcserve to more explicitly teach this aspect of the claimed invention.);
transmitting a command from a control user interface to the hub based on the processed data received from the first sub-system, wherein the command is selected from a group comprising heating and cooling setpoints, mode of operations and fan speed (¶ 94, 119, 147, 165 wherein information is communicating from a smart device to a network device, e.g., NAT, firewall, router, etc., and hub;
¶ 2, 3, 22, 23, 25, 46, 28, 85, 86, 87, 126, 137 wherein the BMS is configured to manage and communicate with a plurality of IoT devices, i.e. a plurality of elements, within a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices and wherein each building has its own BMS to control the respective building, thereby resulting each building and its respective BMS having one or more systems and sub-systems that can be monitored and managed;
¶ 47, 49, 53, 54, 57, 63, 79, 80, 81, 98, 108 wherein the system allows for monitoring and searching of individual building systems elements to help identify, diagnose, troubleshoot and solve building system failures;
¶ 90 “The field gateway aspects can enable gateway 1128 to perform high scale telemetry ingestion, device identification, device management, and cloud-to-device commanding (e.g., when allowed).”; ¶ 94 “In some embodiments, the cloud-based server 1210 is used to send updated and/or commands to the special purpose devices 1202 and/or smart devices 1204.”; see also ¶ 29, 41, 45, 87, 95, 120, 148; Table 4 wherein commands can be sent to the remote devices from the central system to update or control the devices remotely, such as, but not limited to, flow rate, temperature, heating/cooling, setpoint conditions, and so forth
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein Sinha discloses equivalent servers as they are monitoring, diagnose, troubleshoot, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems;
¶ 26, 46, 63, 120 regarding remote user access and access rights to manage the building and remote devices, as well as provide a visually clean and intuited view of the building operations and the ability to resolve issues in real-time via a monitoring and control interface);
In regards to:
transmitting the command to a driver platform to parse the command into a usable format to control the thermostat, […];
parsing the command into the usable format to control the thermostat;
sending the command parsed into the usable format to control the thermostat to the thermostat; and
changing the thermostat based on the command parsed into the usable format to control the thermostat from the driver platform
(¶ 50 “Gateway 406 may use various Internet-based protocols (e.g., CoAP, XMPP, AMQP, MQTT, etc.) and web-based common data exchange (e.g., HTTP RESTful APIs) to translate communications from a building automation system protocol to an Internet Protocol”; “¶ 87 “For example, the gateway 1128 may provide protocol conversions that make legacy non-IP enabled devices able to be accessed through modern web/IP protocols (e.g., converting BACnet Serial to CoAP, MQTT, or AMQP).”; 89 “In a further embodiment, the gateway 1128 is configured to provide protocol conversion services, network address conversion services, containers for messages, applications to understand different protocols such as Bluetooth, Zigbee, Z-wave, BACNet, etc., and/or any other user installed application.”; ¶ 91 “The protocol handlers 1134 may facilitate the translation of data received over the multiple communication protocols into a uniform, understandable, and/or useable format.”;
¶ 26, 46, 60, 63, 120 regarding remote user access and access rights to manage the building and remote devices, as well as provide a visually clean and intuited view of the building operations and the ability to resolve issues in real-time via a monitoring and control interface
¶ 25, 83, 85, 86 regarding the use of a wide range of Internet of Things (IoT) devices and IoT framework for integration and control of smart devices with the BMS, wherein each IoT device is designed to perform specific tasks and provide specific information, e.g., temperature sensor, dampers, chillers, heaters, RTU, AHU, fans, and so forth.
With regards to the first and second elements being a thermostat and lighting, respectively, see the additional analysis provided below.
The system allows for all of these devices, which can have their own respective communication protocol and computer code, to communicate with the system to monitor the state of the building and view the state in an interface to allow the system and a user to determine, for example, the temperature and air flow at a particular location (i.e. computer code is being translated from the IoT code to the BMS code and user understandable language (for example, English), issue a command to the remote device which involves translating/converting the command into code understandable by the specific device. Sinha discloses a wide range of devices (as discussed above) that each have their own corresponding function, e.g., increase fan speed, activate chiller, engage damper, and etc., which would require a command issued by the central system to lower the temperature to result in the command to be translated/converted in a manner to be understandable by each respective device, e.g., the command to lower the temperature or activate the cooling system would require the command to be translated for the fan to turn on, dampers to open or close, the chiller and its components to turn on, and valves to open or close. Each of these devices must have the command translated so that it is understandable by the device, e.g., if zoning is required a command to fully close, certain dampers to fully open, and certain dampers to be somewhere in between (which would require more than simply open or close an electrical switch to allow or stop the flow of electricity. The command needs to be translated to provide the specific instructions so that each damper can operate in the specific manner to coincide with the change) which would not be understandable by a fan that simply needs to allow the flow of electricity to turn on or, if it is a variable speed fan, the command needs to be translated in a manner for the fan to understand at what RPM it needs to operate.
The Examiner asserts that this is done by drivers and although not explicitly recited in Sinha, the Examiner asserts that this is inherently included. The Examiner also invites the applicant to review the provided NPL’s that explain that a driver is what allows one system to communicate with connected devices by serving as a translator, thereby further establishing that the system of Sinha would require the use of a driver to be able to communicate and control the wide range of smart devices, smart connected devices, and non-smart connected things, and etc.
However, in the interest of compact prosecution, the Examiner has provided Home Assistant to more explicitly teach that it would have been obvious to one of ordinary skill in the art that drivers need to be installed in a remote-control device and automation system, such as the one of Sinha, to integrate and control the remote devices.).
Sinha discloses a system and method for monitoring, managing, and controlling a plurality of devices in a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices. As stated above, although one of ordinary skill in the art of computing, e.g., multi-core and multi-thread computer processing, looking upon Sinha would have found that Sinha does, indeed, disclose the emphasized portions of the limitations below, the Examiner has provided an additional analysis in view of arcserve to more explicitly teach this aspect of the invention, i.e. that it is well-known and obvious to one of ordinary skill in the art, based on the available technology, to utilize a multi-core server to process multiple streams of information.
To be more specific, Sinha fails to explicitly disclose:
processing by the first server the data received from the first sub-system by running a plurality of diagnostics session and analytics session on the data received from the first sub-system, wherein a number of diagnostic sessions and analytic sessions is variably determined based on cores on the first server, wherein the number of diagnostic sessions and analytic sessions are evenly spread over the cores of the first server
receiving at the hub the processed data received from the first sub-system, wherein the processed data from the first subsystem has undergone multiple diagnostic sessions in multiple streams to diagnose instances and multiple analytic sessions in multiple streams to analyze instances
However, arcserve teaches
“… Around 2004, something odd happened: while the number of transistors on the CPU continued to increase, processor clock speeds began to flatten. Performance continued to improve, but what was driving the interest in cores over clock speed? Enter the Multi-Core CPU The race between Intel and AMD continued, but the game had changed from clock speeds to multi-core chips. Around this time I traded in my single core Intel Pentium III for dual-core AMD chips running at a slower clock speed. Overall stability of my system increased along with performance, but few programs existed that could take advantage of more than a single core. While some games and a number of post-production tools such as Adobe Premiere are able to take advantage of today’s newest consumer-grade quad and hexa-core CPUs, I wanted to find out under which scenarios multi-core servers make sense to deploy today. Virtualization Memory management is critical when managing VMs, and is usually the first resource to become constrained. Using multi-core CPUs provides an increase in memory channels, allowing for large blocks of data to be processed and analyzed. Allowing the processor to access this data from memory instead of the hard drive results in much better performance. Multi-core servers also allow you to dedicate individual cores to each VM for better performance. Combine the additional memory channels with more cores and you have an environment that can handle the most demanding applications in a VM. High-Performance Computing High-performance computing (HPC) refers the practice of taking complex computations and breaking them into smaller pieces. Using software, each piece of the computation can then be solved by CPU cores. It’s almost like taking a supercomputer and breaking it down into smaller, more manageable building blocks that can then be used to solve complex scientific problems. HPC can also be very computational and memory intensive. … Multi-core processors also allow multiple databases to be consolidated onto a single server. Again, the increased memory bandwidth is the primary reason this is possible. … Cloud environments are also transaction heavy, and multi-core processors allow a company to quickly scale up the number of cores during peak computing times. Energy efficiency is also important to cloud environments. Cores can be turned off or on as needed to optimize workloads and reduce energy.”
…
“…Clock speed still plays a role when selecting a processor. Cores are important but they are still only one feature of a modern processor. Determining the number of cores your application supports is critical to matching it to the best processor for your money. …”
(For support see: Pages 2, 3)
One of ordinary skill in the art would have found it obvious and beneficial to take advantage of the advancements made in processor and server technology, such as, but not limited to, multi-core technology, as this provides the benefits of more processing power, increased efficiency, better performance, processing more information in less time, and so forth.
Further, one of ordinary skill in the art of computing would have found it obvious to update the data processing technique of Sinha using modern processing techniques, as taught in arcserve, in order to gain the commonly understood benefits of such adaptation, such as more processing power, increased efficiency, better performance, processing more information in less time, and so forth.
Accommodating the prior arts more antiquated process of simply focusing on making a processor faster with modern processing techniques, in this case, providing additional cores to process more information simultaneously (especially since Sinha already discloses this technique), would have been obvious. As stated in Leapfrog, “applying modern electronics to older mechanical devices has been commonplace in recent years.”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate into the server-based building management and control system that is in charge of remotely monitoring and controlling a plurality of remote devices of Sinha with the ability to utilize a multi-core server, as taught by arcserve as this would increase the processing power of the server by allowing it to control a plurality of remote devices and implement solutions more effectively, efficiently, and quickly in order to increase the overall management and control of the building.
The combination of Sinha and arcserve discloses a system and method for monitoring, managing, and controlling a plurality of devices in a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices. Although one of ordinary skill in the art would have understood that a “temperature sensor” is equivalent to a thermostat as temperature readings are taken and transmitted to the central system in order to control/manage the temperature of the building, the combination of Sinha and arcserve fails to explicitly disclose the more conservative interpretation of a thermostat.
To be more specific, the combination of Sinha and arcserve fails to explicitly disclose:
transmitting from more than one sub-system data related to elements of the sub-systems, wherein a first element from a first sub-system is a thermostat, wherein a second element from a second sub-system is lighting, wherein the first sub-system and the second sub-system are part of a building;
transmitting the command to a driver platform to parse the command into a usable format to control the thermostat, wherein the driver platform is also adapted to parse commands into a usable format to control the lighting
parsing the command into the usable format to control the thermostat;
sending the command parsed into the usable format to control the thermostat to the thermostat; and
changing the thermostat based on the command parsed into the usable format to control the thermostat from the driver platform
However, Rochford, which is also directed to controlling devices using a remote device, further teaches that there is a plurality of IoT devices that exist in the art, such as, but not limited to, a thermostat, keypad, window shade, lights, and etc. Rochford teaches that an IoT environment provides intelligent Internet technology services that create value by collecting and analyzing data among connected things. IoT may be applied to a variety of fields including smart homes and smart buildings. One of ordinary skill in the art would have found it obvious that the devices of Rochford can be substituted for those of the combination of Sinha and arcserve while still achieving the same predictable result, i.e. monitoring, communicating, and providing commands to and from remote devices to manage a home or building.
(For support see: Pages 1 – 2 ¶ 1 – 7; Page 7 ¶ 36; Page 12 ¶ 62; Page 14 ¶ 72)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention that since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself-that is in the substitution of a thermostat, keypad, shade, lights, and etc., as taught by Rochford, for any of the number of devices disclosed by the combination of Sinha and arcserve.
Thus, the simply substitution of one known element for another producing a predictable result renders the claim obvious.
As an additional note, the Examiner asserts that “wherein the driver platform is also adapted to parse commands into a usable format to control the lighting” is directed to describing an intended result rather than positively claiming that the lighting is being controlled. Although the Examiner has provided citations to address this limitation as if it were being positively claimed, this has only been done for the purposes of compact prosecution and was not required. Further, since the claimed invention is not concerned with controlling a lighting, but only controlling a thermostat, the Examiner asserts that the keypad is nothing more than some type of generic device that is intended to exist in the building. In other words, the manner in which the claimed invention has recited “lighting” has resulted in nothing more than simply claiming that a lighting is just there—simply existing in a building somewhere with no purpose, explanation of use, or explanation of what is controlling. As a result, one of ordinary skill in the art would have found that the prior art simply needs to disclose whether it is well-known in the art for a building to be capable of having other types of devices, such as, but not limited to, a lighting or, alternatively, whether it would have been obvious for a keypad to exist in a building and capable of receiving a command. As demonstrated by Rochford, it is, indeed, well-known and obvious to one of ordinary skill in the art to include other device types, such as, but not limited to, a lighting in a building for the intended purpose of having it be controlled remotely, over a network, or controlled in a manner similar to other IoT device types. Consequently, although the explanation provided above already demonstrates that it would have been obvious to include thermostats and lighting, the Examiner provides this additional analysis to specifically address thermostats, keypad, lighting, and many other devices.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include to incorporate into the building automation system of the combination of Sinha and arcserve which other devices, such as, but not limited to, a keypad, as taught by Rochford since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
The combination of Sinha, arceserve, and Rochford discloses a system and method for managing a plurality of remote devices using a central system by, at least, transmitting commands from the central system to control the plurality of remote devices. As discussed above, one of ordinary skill in the art would have known that the communication and commands would need to be parsed into a usable format by way of a driver, however, in the interest of compact prosecution, the Examiner has provided Home Assistant to more explicitly teach this aspect of the claimed invention, i.e. drivers to translate/convert/parse communications between a computing system and remote devices.
To be more specific, the combination of Sinha, arceserve, and Rochford fails to explicitly disclose:
transmitting the command to a driver platform to parse the command into a usable format to control the thermostat, wherein the driver platform is also adapted to parse commands into a usable format to control the lighting;
parsing the command into the usable format to control the thermostat;
sending the command parsed into the usable format to control the thermostat to the thermostat; and
changing the thermostat based on the command parsed into the usable format to control the thermostat from the driver platform
However, Home Assistant, which is also directed to a smart automation system comprising a plurality of remote devices and remote system that are in communication with one another, teaches that in order to control a plurality of remote devices or remote smart devices, such as, but not limited to, a thermostat and security system, the central system requires the installation of drivers. Home Assistant teaches that drivers need to be installed so that the plurality of remote devices can be integrated into the building automation system and transmit commands to the remote devices to control the remote devices. Similar to what is disclosed in the provided NPL’s, Home Assistant teaches that drivers are used so that remote devices can be integrated into a building automation system so that a computing system can communicate and remotely control the remote devices.
(See Page 1)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate into the building automation system of the combination of Sinha, arceserve, and Rochford that is comprised of a plurality of remote devices, such as, smart connected devices, and non-smart connected things, and etc., communicating with and controllable by a central system, with drivers, as taught by Home Assistant (as well as supported by the provided NPL’s), as drivers are what allow a remote computing device to be able to communicate and control a wide range of remote devices, such as, but not limited to, smart connected devices, and non-smart connected things, and etc., e.g., thermostat, security system, and so forth.
In regards to claim 24, the combination of Sinha, arcserve, Rochford, and Home Assistant discloses the method of claim 23, further comprising receiving at a second server data from the second sub-system;
processing by the second server the data received from the second sub-system by running another plurality of diagnostic session and analytic session on the data received from the second sub-system, wherein a second number of diagnostic sessions and analytic sessions is variably determined based on cores on the second server, wherein the second number of diagnostic sessions and analytic sessions are evenly spread over the cores on the second server;
transmitting the processed data received from the second sub-system to the hub operably connected to more than one server, wherein the processed data from the second sub-system has undergone multiple diagnostic sessions in multiple streams to diagnose instances, and multiple analytic sessions in multiple streams to analyze instances;
receiving at the hub the processed data received from the second sub-system;
transmitting another command from the control user interface to the hub based on the processed data received from the second sub-system, wherein the another command is selected from a group comprising individual load of lights and lighting zones of light;
transmitting another command to the driver platform to parse the command into a usable format to control the lighting;
parsing the another command into the usable format to control the lighting;
sending the another command parsed into the usable format to control the lighting; and
controlling the lighting based on the another command parsed into the usable format to control the lighting
(The Examiner asserts that the instant claim is simply repeating what was already claimed in claim 23, but simply for another sub-system. In other words, the instant claim is simply stating that the system is communicating and controlling another sub-system that is connected to its respective server. With that said,
Sinha – ¶ 58, 59, 60, 68, 79, 84, 106 wherein the system is continuously collecting and analyzing in real-time over time for each of the plurality of elements that it is monitoring, diagnosing, and analyzing, i.e. the diagnostics and analytics is comprised of running multiple session in multiple streams to diagnose and analyze instances;
Sinha – ¶ 2, 3, 22, 23, 25, 46, 28, 85, 86, 87, 126, 137 wherein the BMS is configured to manage and communicate with a plurality of IoT devices, i.e. a plurality of elements, within a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices and wherein each building has its own BMS to control the respective building, thereby resulting each building and its respective BMS having one or more systems and sub-systems that can be monitored and managed.
Sinha – Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein Sinha discloses equivalent servers as they are monitoring, diagnose, troubleshoot, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.
Sinha – ¶ 50, 51, 92 wherein the network includes, at least, any number of: gateway, network switches, routers, servers, devices (such as, but not limited to those discussed above);
Sinha – ¶ 49, 53, 63, 79, 80, 81 wherein diagnostic information is provided for each respective element; ¶ 47, 53, 54, 57, 63 wherein analytics information for each respective element is provided; ¶ 50, 51, 92 wherein the network includes, at least, any number of: gateway, network switches, routers, servers, devices (such as, but not limited to those discussed above);
In light of the specification (¶ 60, 65, 66, 68), the Examiner asserts that the invention is simply capable of being performed using one or more servers that may be hardware, software, or a combination thereof. With that said, Sinha at ¶ 51 which discloses that “Network 404 may include any number of computing devices (e.g., computers, servers, routers, network switches, etc.) configured to transmit, receive, or relay data. Network 404 may further include any number of hardwired and/or wireless connections. For example, smart connected HVAC equipment 408 may communicate wirelessly (e.g., using a Wi-Fi_33 or cellular radio, etc.) with a transceiver that is hardwired (e.g., via a fiber optic cable, a CAT5 cable, etc.) to a computing device of network 404.”; ¶ 90 also discloses “…the gateway 1128 includes a number of field gateway aspects that primarily interface with devices and cloud-based servers.”; see also ¶ 92
As a result, although Sinha does not disclose the limitation word for word (e.g., “sub-system”, previously recited “PI” server (now amended to recite “server), “session”, and “driver”) in light of the applicant’s specification, the Examiner asserts that Sinha does, indeed, disclose the specific combination of elements of the claimed limitation as supported by the broad recitation of possibilities disclosed in the specification(e.g., the broad concept of what is involved in the “diagnostics session” and “analytics session”). In other words, Sinha discloses the claimed invention in the manner that it has been described and supported in the specification;
Sinha – ¶ 94, 119, 147, 165 wherein information is communicating from a smart device to a network device, e.g., NAT, firewall, router, etc., and hub;
Sinha – ¶ 47, 49, 53, 54, 57, 63, 79, 80, 81, 98, 108 wherein the system allows for monitoring and searching of individual building systems elements to help identify, diagnose, troubleshoot and solve building system failures;
Sinha – ¶ 90 “The field gateway aspects can enable gateway 1128 to perform high scale telemetry ingestion, device identification, device management, and cloud-to-device commanding (e.g., when allowed).”; ¶ 94 “In some embodiments, the cloud-based server 1210 is used to send updated and/or commands to the special purpose devices 1202 and/or smart devices 1204.”; see also see also ¶ 29, 41, 45, 87, 95, 120, 148; Table 4 wherein commands can be sent to the remote devices from the central system to update or control the devices remotely, such as, but not limited to, flow rate, temperature, heating/cooling, setpoint conditions, and so forth;
Sinha – ¶ 26, 46, 60, 63, 120 regarding remote user access and access rights to manage the building and remote devices, as well as provide a visually clean and intuited view of the building operations and the ability to resolve issues in real-time via a monitoring and control interface;
Sinha – ¶ 50 “Gateway 406 may use various Internet-based protocols (e.g., CoAP, XMPP, AMQP, MQTT, etc.) and we-based common data exchange (e.g., HTPPT RESTful APIs) to translate communications from a building automation system protocol to an Internet Protocol”; “¶ 87 “For example, the gateway 1128 may provide protocol conversions that make legacy non-IP enabled devices able to be accessed through modern web/IP protocols (e.g., converting BACnet Serial to CoAP, MQTT, or AMQP).”; 89 “In a further embodiment, the gateway 1128 is configured to provide protocol conversion services, network address conversion services, containers for messages, applications to understand different protocols such as Bluetooth, Zigbee, Z-wave, BACNet, etc., and/or any other user installed application.”; ¶ 91 “The protocol handlers 1134 may facilitate the translation of data received over the multiple communication protocols into a uniform, understandable, and/or useable format.”;
Sinha – ¶ 26, 46, 60, 63, 120 regarding remote user access and access rights to manage the building and remote devices, as well as provide a visually clean and intuited view of the building operations and the ability to resolve issues in real-time via a monitoring and control interface
Sinha – ¶ 25, 83, 85, 86 regarding the use of a wide range of Internet of Things (IoT) devices and IoT framework for integration and control of smart devices with the BMS, wherein each IoT device is designed to perform specific tasks and provide specific information, e.g., temperature sensor, dampers, chillers, heaters, RTU, AHU, fans, and so forth.
The system allows for all of these devices, which can have their own respective communication protocol and computer code, to communicate with the system to monitor the state of the building and view the state in an interface to allow the system and a user to determine, for example, the temperature and air flow at a particular location (i.e. computer code is being translated from the IoT code to the BMS code and user understandable language (for example, English), issue a command to the remote device which involves translating/converting the command into code understandable by the specific device. Sinha discloses a wide range of devices (as discussed above) that each have their own corresponding function, e.g., increase fan speed, activate chiller, engage damper, and etc., which would require a command issued by the central system to lower the temperature to result in the command to be translated/converted in a manner to be understandable by each respective device, e.g., the command to lower the temperature or activate the cooling system would require the command to be translated for the fan to turn on, dampers to open or close, the chiller and its components to turn on, and valves to open or close. Each of these devices must have the command translated so that it is understandable by the device, e.g., if zoning is required a command to fully close, certain dampers to fully open, and certain dampers to be somewhere in between (which would require more than simply open or close an electrical switch to allow or stop the flow of electricity. The command needs to be translated to provide the specific instructions so that each damper can operate in the specific manner to coincide with the change) which would not be understandable by a fan that simply needs to allow the flow of electricity to turn on or, if it is a variable speed fan, the command needs to be translated in a manner for the fan to understand at what RPM it needs to operate.
arcserve – Pages 2, 3 regarding multi-core servers processing multiple streams of data
Rochford – Pages 1 – 2 ¶ 1 – 7; Page 7 ¶ 36; Page 12 ¶ 62; Page 14 ¶ 72 regarding the devices being a thermostat and keypad and controlling these devices;
Home Assistant – Page 1 regarding drivers to translate/parse the communications between the remote devices and central system).
In regards to claims 26, 27, the combination of Sinha, arcserve, Rochford, and Home Assistant discloses
(Claim 26) the method of claim 24, updating charts on the user interface of the hub using the processed data received from the first sub-system to the hub;
(Claim 27) the method of claim 24, further comprising creating a chart from analytics data
(Sinha – ¶ 54, 68, 70, 73 wherein the processed data received from the plurality of remote devices is transmitted to the servers and received by the central system so that the data can be used in models, charts, and reports to determine the current state of equipment and the building and determine what actions to take, such as, but not limited to, diagnostics, troubleshooting, control, and so forth (as was discussed above)).
In regards to claims 28, 29, the combination of Sinha, arcserve, Rochford, and Home Assistant discloses
(Claim 28) the method of claim 24, further comprising a third element from the first sub-system, wherein the third element is a shade;
(Claim 29) the method of claim 24, further comprising a fourth element from the second sub-system, wherein the fourth element is a keypad.
Sinha discloses at ¶ 2, 3, 22, 23, 25, 46, 28, 85, 86, 87, 126, 137 wherein the BMS is configured to manage and communicate with a plurality of IoT devices, i.e. a plurality of elements, within a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices and wherein each building has its own BMS to control the respective building, thereby resulting each building and its respective BMS having one or more systems and sub-systems that can be monitored and managed. See also Rochford at Pages 1 – 2 ¶ 1 – 7; Page 7 ¶ 36; Page 12 ¶ 62; Page 14 ¶ 72, regarding the devices being a thermostat, keypad, shade, lighting, and/or etc.
In regards to claim 37, the combination of Sinha, arcserve, Rochford, and Home Assistant discloses the system of claim 34, wherein processed data received from the first sub-system and the second sub-system is used to generate a building health chart over a predetermined period of time (Sinha – ¶ 54, 68, 70, 73 wherein the processed data received from the plurality of remote devices is transmitted to the servers and received by the central system so that the data can be used in models, charts, and reports to determine the current state of equipment and the building and determine what actions to take, such as, but not limited to, diagnostics, troubleshooting, control, and so forth (as was discussed above); ¶ 58, 59, 60, 68, 79, 84, 106 wherein the system is continuously collecting and analyzing in real-time over time for each of the plurality of elements that it is monitoring, diagnosing, and analyzing, i.e. the diagnostics and analytics is comprised of running multiple session in multiple streams to diagnose and analyze instances).
In regards to claim 39, Sinha discloses a method for managing building subsystems comprising the steps of:
transmitting from more than one sub-system data related to elements of the sub-systems to more than one servers, wherein a first element from a first sub-system is a thermostat, wherein a second element from a second sub-system is lighting, wherein the first sub-system and the second sub-system are part of a building (¶ 2, 3, 22, 23, 25, 46, 28, 85, 86, 87, 126, 137 wherein the BMS is configured to manage and communicate with a plurality of IoT devices, i.e. a plurality of elements, within a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices and wherein each building has its own BMS to control the respective building, thereby resulting each building and its respective BMS having one or more systems and sub-systems that can be monitored and managed.
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.
With regards to the first element being a thermostat, see the additional analysis provided below);
receiving at a first server data from the first sub-subsystem (¶ 50, 51, 92 wherein the network includes, at least, any number of: gateway, network switches, routers, servers, devices (such as, but not limited to those discussed above);
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.);
processing by the first server the data received from the first sub-system by running a plurality of diagnostics session and analytics session on the data received from the first sub-system, wherein a number of diagnostic sessions and analytic sessions is variably determined based on cores on the first server, wherein the number of diagnostic sessions and analytic sessions are evenly spread over the cores of the first server (¶ 49, 53, 63, 79, 80, 81 wherein diagnostic information is provided for each respective element; ¶ 47, 53, 54, 57, 63 wherein analytics information for each respective element is provided; ¶ 50, 51, 92 wherein the network includes, at least, any number of: gateway, network switches, routers, servers, devices (such as, but not limited to those discussed above);
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.;
In light of the specification (¶ 60, 65, 66, 68), the Examiner asserts that the invention is simply capable of being performed using one or more servers that may be hardware, software, or a combination thereof. With that said, Sinha at ¶ 51 which discloses that “Network 404 may include any number of computing devices (e.g., computers, servers, routers, network switches, etc.) configured to transmit, receive, or relay data. Network 404 may further include any number of hardwired and/or wireless connections. For example, smart connected HVAC equipment 408 may communicate wirelessly (e.g., using a Wi-Fi_33 or cellular radio, etc.) with a transceiver that is hardwired (e.g., via a fiber optic cable, a CAT5 cable, etc.) to a computing device of network 404.”; ¶ 90 also discloses “…the gateway 1128 includes a number of field gateway aspects that primarily interface with devices and cloud-based servers.”; see also ¶ 92;
Additionally, with regards to “wherein a number of diagnostic sessions and analytic sessions is variably determined based on cores on the first server, wherein the number of diagnostic sessions and analytic sessions are evenly spread over the cores of the first server”, see ¶ 93 “IoT platform 1140 of ecosystem 1100 may include a network of physical objects or "things" embedded with electronics, software, sensors, and/or network connectivity that enable such objects to collect and exchange data. The loT platform 1140 may facilitate linking the physical and digital world by allowing remote sensing and control of devices across new and/or previously existing communication infrastructure. The IoT platform 1140 represents components and technologies that may enable delivering an end-to-end solution for IoT enabled products and services. The IoT platform 1140 also can include various processes and applications, which may further be utilized in creating and maintaining an IoT ecosystem 1100.”; ¶ 105 “Analytics technology concept 114 may include a massively parallel analytics module 1158. The massively parallel data analytics module 1158 may include multiple processors configured to run analytical processing. The massively parallel data analytics module 1158 may divide large data sets into smaller segments that are analyzed (e.g., operated on, etc.) by specifically assigned processors (e.g., with their own operating system and memory, etc.). Messaging interfaces may aggregate the results following the analysis by each processor. Such a system may allow for improvements in processing and flexible scalability.”; See also ¶ 53, 82, 83, 85, 89, 91, 92; In the event that the applicant disagrees with this analysis, the Examiner has provided an additional analysis in view of arcserve to more explicitly teach this aspect of the claimed invention.
As a result, although Sinha does not disclose the limitation word for word (e.g., “sub-system”, previously recited “PI” server (previously amended to now recite “server), “session”, and “driver”) in light of the applicant’s specification, the Examiner asserts that Sinha does, indeed, disclose the specific combination of elements of the claimed limitation as supported by the broad recitation of possibilities disclosed in the specification(e.g., the broad concept of what is involved in the “diagnostics session” and “analytics session”). In other words, Sinha discloses the claimed invention in the manner that it has been described and supported in the specification.);
In regards to:
transmitting the processed data received from the first sub-system to a hub operably connected to more than on servers;
receiving at the hub the processed data received from the first sub-system, wherein the processed data from the first subsystem has undergone multiple diagnostic sessions in multiple streams to diagnose instances and multiple analytic sessions in multiple streams to analyze instances
(¶ 94, 119, 147, 165 wherein information is communicating from a smart device to a network device, e.g., NAT, firewall, router, etc., and hub;
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.
¶ 58, 59, 60, 68, 79, 84, 106 wherein the system is continuously collecting and analyzing in real-time over time for each of the plurality of elements that it is monitoring, diagnosing, and analyzing, i.e. the diagnostics and analytics is comprised of running multiple session in multiple streams to diagnose and analyze instances; ¶ 2, 3, 22, 23, 25, 46, 28, 85, 86, 87, 126, 137 wherein the BMS is configured to manage and communicate with a plurality of IoT devices, i.e. a plurality of elements, within a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices and wherein each building has its own BMS to control the respective building, thereby resulting each building and its respective BMS having one or more systems and sub-systems that can be monitored and managed.; Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.
Additionally, with regards to “receiving at the hub the processed data received from the first sub-system, wherein the processed data from the first subsystem has undergone multiple diagnostic sessions in multiple streams to diagnose instances and multiple analytic sessions in multiple streams to analyze instances ”, see ¶ 93 “IoT platform 1140 of ecosystem 1100 may include a network of physical objects or "things" embedded with electronics, software, sensors, and/or network connectivity that enable such objects to collect and exchange data. The loT platform 1140 may facilitate linking the physical and digital world by allowing remote sensing and control of devices across new and/or previously existing communication infrastructure. The IoT platform 1140 represents components and technologies that may enable delivering an end-to-end solution for IoT enabled products and services. The IoT platform 1140 also can include various processes and applications, which may further be utilized in creating and maintaining an IoT ecosystem 1100.”; ¶ 105 “Analytics technology concept 114 may include a massively parallel analytics module 1158. The massively parallel data analytics module 1158 may include multiple processors configured to run analytical processing. The massively parallel data analytics module 1158 may divide large data sets into smaller segments that are analyzed (e.g., operated on, etc.) by specifically assigned processors (e.g., with their own operating system and memory, etc.). Messaging interfaces may aggregate the results following the analysis by each processor. Such a system may allow for improvements in processing and flexible scalability.”; See also ¶ 53, 82, 83, 85, 89, 91, 92; In the event that the applicant disagrees with this analysis, the Examiner has provided an additional analysis in view of arcserve to more explicitly teach this aspect of the claimed invention.);
transmitting a command from a control user interface to the hub based on the processed data received from the first sub-system, wherein the command is selected from a group comprising heating and cooling setpoints, mode of operations and fan speed (¶ 94, 119, 147, 165 wherein information is communicating from a smart device to a network device, e.g., NAT, firewall, router, etc., and hub;
¶ 2, 3, 22, 23, 25, 46, 28, 85, 86, 87, 126, 137 wherein the BMS is configured to manage and communicate with a plurality of IoT devices, i.e. a plurality of elements, within a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices and wherein each building has its own BMS to control the respective building, thereby resulting each building and its respective BMS having one or more systems and sub-systems that can be monitored and managed;
¶ 47, 49, 53, 54, 57, 63, 79, 80, 81, 98, 108 wherein the system allows for monitoring and searching of individual building systems elements to help identify, diagnose, troubleshoot and solve building system failures;
¶ 90 “The field gateway aspects can enable gateway 1128 to perform high scale telemetry ingestion, device identification, device management, and cloud-to-device commanding (e.g., when allowed).”; ¶ 94 “In some embodiments, the cloud-based server 1210 is used to send updated and/or commands to the special purpose devices 1202 and/or smart devices 1204.”; see also ¶ 29, 41, 45, 87, 95, 120, 148; Table 4 wherein commands can be sent to the remote devices from the central system to update or control the devices remotely, such as, but not limited to, flow rate, temperature, heating/cooling, setpoint conditions, and so forth
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein Sinha discloses equivalent servers as they are monitoring, diagnose, troubleshoot, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems;
¶ 26, 46, 63, 120 regarding remote user access and access rights to manage the building and remote devices, as well as provide a visually clean and intuited view of the building operations and the ability to resolve issues in real-time via a monitoring and control interface);
In regards to:
transmitting the command to a driver platform to parse the command into a usable format to control the thermostat, […];
parsing the command into the usable format to control the thermostat;
sending the command parsed into the usable format to control the thermostat to the thermostat; and
changing the thermostat based on the command parsed into the usable format to control the thermostat from the driver platform
(¶ 50 “Gateway 406 may use various Internet-based protocols (e.g., CoAP, XMPP, AMQP, MQTT, etc.) and web-based common data exchange (e.g., HTTP RESTful APIs) to translate communications from a building automation system protocol to an Internet Protocol”; “¶ 87 “For example, the gateway 1128 may provide protocol conversions that make legacy non-IP enabled devices able to be accessed through modern web/IP protocols (e.g., converting BACnet Serial to CoAP, MQTT, or AMQP).”; 89 “In a further embodiment, the gateway 1128 is configured to provide protocol conversion services, network address conversion services, containers for messages, applications to understand different protocols such as Bluetooth, Zigbee, Z-wave, BACNet, etc., and/or any other user installed application.”; ¶ 91 “The protocol handlers 1134 may facilitate the translation of data received over the multiple communication protocols into a uniform, understandable, and/or useable format.”;
¶ 26, 46, 60, 63, 120 regarding remote user access and access rights to manage the building and remote devices, as well as provide a visually clean and intuited view of the building operations and the ability to resolve issues in real-time via a monitoring and control interface
¶ 25, 83, 85, 86 regarding the use of a wide range of Internet of Things (IoT) devices and IoT framework for integration and control of smart devices with the BMS, wherein each IoT device is designed to perform specific tasks and provide specific information, e.g., temperature sensor, dampers, chillers, heaters, RTU, AHU, fans, and so forth.
With regards to the first and second elements being a thermostat and lighting, respectively, see the additional analysis provided below.
The system allows for all of these devices, which can have their own respective communication protocol and computer code, to communicate with the system to monitor the state of the building and view the state in an interface to allow the system and a user to determine, for example, the temperature and air flow at a particular location (i.e. computer code is being translated from the IoT code to the BMS code and user understandable language (for example, English), issue a command to the remote device which involves translating/converting the command into code understandable by the specific device. Sinha discloses a wide range of devices (as discussed above) that each have their own corresponding function, e.g., increase fan speed, activate chiller, engage damper, and etc., which would require a command issued by the central system to lower the temperature to result in the command to be translated/converted in a manner to be understandable by each respective device, e.g., the command to lower the temperature or activate the cooling system would require the command to be translated for the fan to turn on, dampers to open or close, the chiller and its components to turn on, and valves to open or close. Each of these devices must have the command translated so that it is understandable by the device, e.g., if zoning is required a command to fully close, certain dampers to fully open, and certain dampers to be somewhere in between (which would require more than simply open or close an electrical switch to allow or stop the flow of electricity. The command needs to be translated to provide the specific instructions so that each damper can operate in the specific manner to coincide with the change) which would not be understandable by a fan that simply needs to allow the flow of electricity to turn on or, if it is a variable speed fan, the command needs to be translated in a manner for the fan to understand at what RPM it needs to operate.
The Examiner asserts that this is done by drivers and although not explicitly recited in Sinha, the Examiner asserts that this is inherently included. The Examiner also invites the applicant to review the provided NPL’s that explain that a driver is what allows one system to communicate with connected devices by serving as a translator, thereby further establishing that the system of Sinha would require the use of a driver to be able to communicate and control the wide range of smart devices, smart connected devices, and non-smart connected things, and etc.
However, in the interest of compact prosecution, the Examiner has provided Home Assistant to more explicitly teach that it would have been obvious to one of ordinary skill in the art that drivers need to be installed in a remote-control device and automation system, such as the one of Sinha, to integrate and control the remote devices.); and
wherein each of the first element and second element is searchable by a user via a graphical user interface (Fig. 17; ¶ 57, 60, 63, 69, 98, 112, 113, 114, 116, 144, 153, 154, 155, 157, 158,159, 165 wherein the building communicates its current/real-time status to a monitoring system that provides a user with a dashboard to, at least, search for connected and monitored building devices (elements) to monitor performance, receive alerts, ability to resolve issues, and search for devices to read information from the device or determine if they currently exist so as to add/register a device).
Sinha discloses a system and method for monitoring, managing, and controlling a plurality of devices in a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices. As stated above, although one of ordinary skill in the art of computing, e.g., multi-core and multi-thread computer processing, looking upon Sinha would have found that Sinha does, indeed, disclose the emphasized portions of the limitations below, the Examiner has provided an additional analysis in view of arcserve to more explicitly teach this aspect of the invention, i.e. that it is well-known and obvious to one of ordinary skill in the art, based on the available technology, to utilize a multi-core server to process multiple streams of information.
To be more specific, Sinha fails to explicitly disclose:
processing by the first server the data received from the first sub-system by running a plurality of diagnostics session and analytics session on the data received from the first sub-system, wherein a number of diagnostic sessions and analytic sessions is variably determined based on cores on the first server, wherein the number of diagnostic sessions and analytic sessions are evenly spread over the cores of the first server
receiving at the hub the processed data received from the first sub-system, wherein the processed data from the first subsystem has undergone multiple diagnostic sessions in multiple streams to diagnose instances and multiple analytic sessions in multiple streams to analyze instances
However, arcserve teaches
“… Around 2004, something odd happened: while the number of transistors on the CPU continued to increase, processor clock speeds began to flatten. Performance continued to improve, but what was driving the interest in cores over clock speed? Enter the Multi-Core CPU The race between Intel and AMD continued, but the game had changed from clock speeds to multi-core chips. Around this time I traded in my single core Intel Pentium III for dual-core AMD chips running at a slower clock speed. Overall stability of my system increased along with performance, but few programs existed that could take advantage of more than a single core. While some games and a number of post-production tools such as Adobe Premiere are able to take advantage of today’s newest consumer-grade quad and hexa-core CPUs, I wanted to find out under which scenarios multi-core servers make sense to deploy today. Virtualization Memory management is critical when managing VMs, and is usually the first resource to become constrained. Using multi-core CPUs provides an increase in memory channels, allowing for large blocks of data to be processed and analyzed. Allowing the processor to access this data from memory instead of the hard drive results in much better performance. Multi-core servers also allow you to dedicate individual cores to each VM for better performance. Combine the additional memory channels with more cores and you have an environment that can handle the most demanding applications in a VM. High-Performance Computing High-performance computing (HPC) refers the practice of taking complex computations and breaking them into smaller pieces. Using software, each piece of the computation can then be solved by CPU cores. It’s almost like taking a supercomputer and breaking it down into smaller, more manageable building blocks that can then be used to solve complex scientific problems. HPC can also be very computational and memory intensive. … Multi-core processors also allow multiple databases to be consolidated onto a single server. Again, the increased memory bandwidth is the primary reason this is possible. … Cloud environments are also transaction heavy, and multi-core processors allow a company to quickly scale up the number of cores during peak computing times. Energy efficiency is also important to cloud environments. Cores can be turned off or on as needed to optimize workloads and reduce energy.”
…
“…Clock speed still plays a role when selecting a processor. Cores are important but they are still only one feature of a modern processor. Determining the number of cores your application supports is critical to matching it to the best processor for your money. …”
(For support see: Pages 2, 3)
One of ordinary skill in the art would have found it obvious and beneficial to take advantage of the advancements made in processor and server technology, such as, but not limited to, multi-core technology, as this provides the benefits of more processing power, increased efficiency, better performance, processing more information in less time, and so forth.
Further, one of ordinary skill in the art of computing would have found it obvious to update the data processing technique of Sinha using modern processing techniques, as taught in arcserve, in order to gain the commonly understood benefits of such adaptation, such as more processing power, increased efficiency, better performance, processing more information in less time, and so forth.
Accommodating the prior arts more antiquated process of simply focusing on making a processor faster with modern processing techniques, in this case, providing additional cores to process more information simultaneously (especially since Sinha already discloses this technique), would have been obvious. As stated in Leapfrog, “applying modern electronics to older mechanical devices has been commonplace in recent years.”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate into the server-based building management and control system that is in charge of remotely monitoring and controlling a plurality of remote devices of Sinha with the ability to utilize a multi-core server, as taught by arcserve as this would increase the processing power of the server by allowing it to control a plurality of remote devices and implement solutions more effectively, efficiently, and quickly in order to increase the overall management and control of the building.
The combination of Sinha and arcserve discloses a system and method for monitoring, managing, and controlling a plurality of devices in a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices. Although one of ordinary skill in the art would have understood that a “temperature sensor” is equivalent to a thermostat as temperature readings are taken and transmitted to the central system in order to control/manage the temperature of the building, the combination of Sinha and arcserve fails to explicitly disclose the more conservative interpretation of a thermostat.
To be more specific, the combination of Sinha and arcserve fails to explicitly disclose:
transmitting from more than one sub-system data related to elements of the sub-systems, wherein a first element from a first sub-system is a thermostat, wherein a second element from a second sub-system is lighting, wherein the first sub-system and the second sub-system are part of a building;
transmitting the command to a driver platform to parse the command into a usable format to control the thermostat, wherein the driver platform is also adapted to parse commands into a usable format to control the lighting
parsing the command into the usable format to control the thermostat;
sending the command parsed into the usable format to control the thermostat to the thermostat; and
changing the thermostat based on the command parsed into the usable format to control the thermostat from the driver platform
However, Rochford, which is also directed to controlling devices using a remote device, further teaches that there is a plurality of IoT devices that exist in the art, such as, but not limited to, a thermostat, keypad, window shade, lights, and etc. Rochford teaches that an IoT environment provides intelligent Internet technology services that create value by collecting and analyzing data among connected things. IoT may be applied to a variety of fields including smart homes and smart buildings. One of ordinary skill in the art would have found it obvious that the devices of Rochford can be substituted for those of the combination of Sinha and arcserve while still achieving the same predictable result, i.e. monitoring, communicating, and providing commands to and from remote devices to manage a home or building.
(For support see: Pages 1 – 2 ¶ 1 – 7; Page 7 ¶ 36; Page 12 ¶ 62; Page 14 ¶ 72)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention that since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of a thermostat, keypad, shade, lights, and etc., as taught by Rochford, for any of the number of devices disclosed by the combination of Sinha and arcserve.
Thus, the simply substitution of one known element for another producing a predictable result renders the claim obvious.
As an additional note, the Examiner asserts that “wherein the driver platform is also adapted to parse commands into a usable format to control the lighting” is directed to describing an intended result rather than positively claiming that the lighting is being controlled. Although the Examiner has provided citations to address this limitation as if it were being positively claimed, this has only been done for the purposes of compact prosecution and was not required. Further, since the claimed invention is not concerned with controlling a lighting, but only controlling a thermostat, the Examiner asserts that the keypad is nothing more than some type of generic device that is intended to exist in the building. In other words, the manner in which the claimed invention has recited “lighting” has resulted in nothing more than simply claiming that a lighting is just there—simply existing in a building somewhere with no purpose, explanation of use, or explanation of what is controlling. As a result, one of ordinary skill in the art would have found that the prior art simply needs to disclose whether it is well-known in the art for a building to be capable of having other types of devices, such as, but not limited to, a lighting or, alternatively, whether it would have been obvious for a keypad to exist in a building and capable of receiving a command. As demonstrated by Rochford, it is, indeed, well-known and obvious to one of ordinary skill in the art to include other device types, such as, but not limited to, a lighting in a building for the intended purpose of having it be controlled remotely, over a network, or controlled in a manner similar to other IoT device types. Consequently, although the explanation provided above already demonstrates that it would have been obvious to include thermostats and lighting, the Examiner provides this additional analysis to specifically address thermostats, keypad, lighting, and many other devices.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include to incorporate into the building automation system of the combination of Sinha and arcserve which other devices, such as, but not limited to, a keypad, as taught by Rochford since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
The combination of Sinha, arceserve, and Rochford discloses a system and method for managing a plurality of remote devices using a central system by, at least, transmitting commands from the central system to control the plurality of remote devices. As discussed above, one of ordinary skill in the art would have known that the communication and commands would need to be parsed into a usable format by way of a driver, however, in the interest of compact prosecution, the Examiner has provided Home Assistant to more explicitly teach this aspect of the claimed invention, i.e. drivers to translate/convert/parse communications between a computing system and remote devices.
To be more specific, the combination of Sinha, arceserve, and Rochford fails to explicitly disclose:
transmitting the command to a driver platform to parse the command into a usable format to control the thermostat, wherein the driver platform is also adapted to parse commands into a usable format to control the lighting;
parsing the command into the usable format to control the thermostat;
sending the command parsed into the usable format to control the thermostat to the thermostat; and
changing the thermostat based on the command parsed into the usable format to control the thermostat from the driver platform
However, Home Assistant, which is also directed to a smart automation system comprising a plurality of remote devices and remote system that are in communication with one another, teaches that in order to control a plurality of remote devices or remote smart devices, such as, but not limited to, a thermostat and security system, the central system requires the installation of drivers. Home Assistant teaches that drivers need to be installed so that the plurality of remote devices can be integrated into the building automation system and transmit commands to the remote devices to control the remote devices. Similar to what is disclosed in the provided NPL’s, Home Assistant teaches that drivers are used so that remote devices can be integrated into a building automation system so that a computing system can communicate and remotely control the remote devices.
(See Page 1)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate into the building automation system of the combination of Sinha, arceserve, and Rochford that is comprised of a plurality of remote devices, such as, smart connected devices, and non-smart connected things, and etc., communicating with and controllable by a central system, with drivers, as taught by Home Assistant (as well as supported by the provided NPL’s), as drivers are what allow a remote computing device to be able to communicate and control a wide range of remote devices, such as, but not limited to, smart connected devices, and non-smart connected things, and etc., e.g., thermostat, security system, and so forth.
In regards to claim 40, the combination of Sinha, arceserve, Rochford, and Home Assistant discloses the method of claim 39, wherein each of the first and second element are searchable via element type, location, age, and whether there is an active live connection to another system element (Sinha – Fig. 17; ¶ 57, 60, 63, 69, 98, 112, 113, 114, 116, 144, 153, 154, 155, 157, 158,159, 165 wherein the building communicates its current/real-time status to a monitoring system that provides a user with a dashboard to, at least, search for connected and monitored building devices (elements) to monitor performance, receive alerts, ability to resolve issues, and search for devices to read information from the device or determine if they currently exist so as to add/register a device; ¶ 27, 53, 74, 96 wherein the system provides location information of devices that can be located across many different buildings, i.e. the system allows a user to interact with a particular building and the particular devices located at the particular building; ¶ 74 wherein the devices and buildings can be organized by type, age, size, and other factors; Page 16 – 17, Table 5; ¶ 61, 97 wherein the system lifecycle information of the device to determine when it will require maintenance or replacement).
In regards to claim 41, the combination of Sinha, arceserve, Rochford, and Home Assistant discloses the method of claim 39, wherein each of the first and second element are searchable via a searchable criteria selected from the group consisting of element type, location, age, and whether there is an active live connection to another system element (Sinha – Fig. 17; ¶ 57, 60, 63, 69, 98, 112, 113, 114, 116, 144, 153, 154, 155, 157, 158,159, 165 wherein the building communicates its current/real-time status to a monitoring system that provides a user with a dashboard to, at least, search for connected and monitored building devices (elements) to monitor performance, receive alerts, ability to resolve issues, and search for devices to read information from the device or determine if they currently exist so as to add/register a device; ¶ 27, 53, 74, 96 wherein the system provides location information of devices that can be located across many different buildings, i.e. the system allows a user to interact with a particular building and the particular devices located at the particular building; ¶ 74 wherein the devices and buildings can be organized by type, age, size, and other factors; Page 16 – 17, Table 5; ¶ 61, 97 wherein the system lifecycle information of the device to determine when it will require maintenance or replacement).
In regards to claim 42, the combination of Sinha, arceserve, Rochford, and Home Assistant discloses the method of claim 40, further comprising receiving at a second server data from the second sub-system;
processing by the second server the data received from the second sub-system by running another plurality of diagnostic session and analytic session on the data received from the second sub-system, wherein a second number of diagnostic sessions and analytic sessions is variably determined based on cores on the second server, wherein the second number of diagnostic sessions and analytic sessions are evenly spread over the cores on the second server (First, The Examiner asserts that the instant claim is simply repeating what was already claimed in claim 23, but simply for another sub-system. In other words, the instant claim is simply stating that the system is communicating and controlling another sub-system that is connected to its respective server. With that said:
¶ 49, 53, 63, 79, 80, 81 wherein diagnostic information is provided for each respective element; ¶ 47, 53, 54, 57, 63 wherein analytics information for each respective element is provided; ¶ 50, 51, 92 wherein the network includes, at least, any number of: gateway, network switches, routers, servers, devices (such as, but not limited to those discussed above);
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.;
In light of the specification (¶ 60, 65, 66, 68), the Examiner asserts that the invention is simply capable of being performed using one or more servers that may be hardware, software, or a combination thereof. With that said, Sinha at ¶ 51 which discloses that “Network 404 may include any number of computing devices (e.g., computers, servers, routers, network switches, etc.) configured to transmit, receive, or relay data. Network 404 may further include any number of hardwired and/or wireless connections. For example, smart connected HVAC equipment 408 may communicate wirelessly (e.g., using a Wi-Fi_33 or cellular radio, etc.) with a transceiver that is hardwired (e.g., via a fiber optic cable, a CAT5 cable, etc.) to a computing device of network 404.”; ¶ 90 also discloses “…the gateway 1128 includes a number of field gateway aspects that primarily interface with devices and cloud-based servers.”; see also ¶ 92;
Additionally, with regards to “wherein a number of diagnostic sessions and analytic sessions is variably determined based on cores on the first server, wherein the number of diagnostic sessions and analytic sessions are evenly spread over the cores of the first server”, see ¶ 93 “IoT platform 1140 of ecosystem 1100 may include a network of physical objects or "things" embedded with electronics, software, sensors, and/or network connectivity that enable such objects to collect and exchange data. The loT platform 1140 may facilitate linking the physical and digital world by allowing remote sensing and control of devices across new and/or previously existing communication infrastructure. The IoT platform 1140 represents components and technologies that may enable delivering an end-to-end solution for IoT enabled products and services. The IoT platform 1140 also can include various processes and applications, which may further be utilized in creating and maintaining an IoT ecosystem 1100.”; ¶ 105 “Analytics technology concept 114 may include a massively parallel analytics module 1158. The massively parallel data analytics module 1158 may include multiple processors configured to run analytical processing. The massively parallel data analytics module 1158 may divide large data sets into smaller segments that are analyzed (e.g., operated on, etc.) by specifically assigned processors (e.g., with their own operating system and memory, etc.). Messaging interfaces may aggregate the results following the analysis by each processor. Such a system may allow for improvements in processing and flexible scalability.”; See also ¶ 53, 82, 83, 85, 89, 91, 92; In the event that the applicant disagrees with this analysis, the Examiner has provided an additional analysis in view of arcserve to more explicitly teach this aspect of the claimed invention.
As a result, although Sinha does not disclose the limitation word for word (e.g., “sub-system”, previously recited “PI” server (previously amended to now recite “server), “session”, and “driver”) in light of the applicant’s specification, the Examiner asserts that Sinha does, indeed, disclose the specific combination of elements of the claimed limitation as supported by the broad recitation of possibilities disclosed in the specification(e.g., the broad concept of what is involved in the “diagnostics session” and “analytics session”). In other words, Sinha discloses the claimed invention in the manner that it has been described and supported in the specification);
In regards to:
transmitting the processed data received from the second sub-system to the hub operably connected to more than one server, wherein the processed data from the second sub-system has undergone multiple diagnostic sessions in multiple streams to diagnose instances, and multiple analytic sessions in multiple streams to analyze instances
receiving at the hub the processed data received from the second sub-system
(¶ 94, 119, 147, 165 wherein information is communicating from a smart device to a network device, e.g., NAT, firewall, router, etc., and hub;
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.
¶ 58, 59, 60, 68, 79, 84, 106 wherein the system is continuously collecting and analyzing in real-time over time for each of the plurality of elements that it is monitoring, diagnosing, and analyzing, i.e. the diagnostics and analytics is comprised of running multiple session in multiple streams to diagnose and analyze instances; ¶ 2, 3, 22, 23, 25, 46, 28, 85, 86, 87, 126, 137 wherein the BMS is configured to manage and communicate with a plurality of IoT devices, i.e. a plurality of elements, within a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices and wherein each building has its own BMS to control the respective building, thereby resulting each building and its respective BMS having one or more systems and sub-systems that can be monitored and managed.; Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein servers are monitoring, diagnosing, troubleshooting, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems.
Additionally, with regards to “receiving at the hub the processed data received from the first sub-system, wherein the processed data from the first subsystem has undergone multiple diagnostic sessions in multiple streams to diagnose instances and multiple analytic sessions in multiple streams to analyze instances ”, see ¶ 93 “IoT platform 1140 of ecosystem 1100 may include a network of physical objects or "things" embedded with electronics, software, sensors, and/or network connectivity that enable such objects to collect and exchange data. The loT platform 1140 may facilitate linking the physical and digital world by allowing remote sensing and control of devices across new and/or previously existing communication infrastructure. The IoT platform 1140 represents components and technologies that may enable delivering an end-to-end solution for IoT enabled products and services. The IoT platform 1140 also can include various processes and applications, which may further be utilized in creating and maintaining an IoT ecosystem 1100.”; ¶ 105 “Analytics technology concept 114 may include a massively parallel analytics module 1158. The massively parallel data analytics module 1158 may include multiple processors configured to run analytical processing. The massively parallel data analytics module 1158 may divide large data sets into smaller segments that are analyzed (e.g., operated on, etc.) by specifically assigned processors (e.g., with their own operating system and memory, etc.). Messaging interfaces may aggregate the results following the analysis by each processor. Such a system may allow for improvements in processing and flexible scalability.”; See also ¶ 53, 82, 83, 85, 89, 91, 92; In the event that the applicant disagrees with this analysis, the Examiner has provided an additional analysis in view of arcserve to more explicitly teach this aspect of the claimed invention);
transmitting another command from the control user interface to the hub based on the processed data received from the second sub-system, wherein the another command is selected from a group comprising individual load of lights and lighting zones of light (¶ 94, 119, 147, 165 wherein information is communicating from a smart device to a network device, e.g., NAT, firewall, router, etc., and hub;
¶ 2, 3, 22, 23, 25, 46, 28, 85, 86, 87, 126, 137 wherein the BMS is configured to manage and communicate with a plurality of IoT devices, i.e. a plurality of elements, within a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices and wherein each building has its own BMS to control the respective building, thereby resulting each building and its respective BMS having one or more systems and sub-systems that can be monitored and managed;
¶ 47, 49, 53, 54, 57, 63, 79, 80, 81, 98, 108 wherein the system allows for monitoring and searching of individual building systems elements to help identify, diagnose, troubleshoot and solve building system failures;
¶ 90 “The field gateway aspects can enable gateway 1128 to perform high scale telemetry ingestion, device identification, device management, and cloud-to-device commanding (e.g., when allowed).”; ¶ 94 “In some embodiments, the cloud-based server 1210 is used to send updated and/or commands to the special purpose devices 1202 and/or smart devices 1204.”; see also ¶ 29, 41, 45, 87, 95, 120, 148; Table 4 wherein commands can be sent to the remote devices from the central system to update or control the devices remotely, such as, but not limited to, flow rate, temperature, heating/cooling, setpoint conditions, and so forth
Fig. 4 – 7, 10, 12, 13, 14, 15, 17; ¶ 28, 44, 45, 47, 49, 50, 51, 53, 54, 56, 83, 85, 86, 87, 88, 90, 92, 155 wherein Sinha discloses equivalent servers as they are monitoring, diagnose, troubleshoot, servicing, and storing information pertaining to the state of the building and remotely connected devices and assist with their management, as well as control of the remote devices, such as smart connected devices, located throughout the building(s) to manage the state of the building(s),e.g., temperature, in addition to a plurality of corresponding sub-plants, i.e. sub-systems;
¶ 26, 46, 63, 120 regarding remote user access and access rights to manage the building and remote devices, as well as provide a visually clean and intuited view of the building operations and the ability to resolve issues in real-time via a monitoring and control interface);
In regards to:
transmitting another command to the driver platform to parse the command into a usable format to control the lighting
parsing the another command into the usable format to control the lighting;
sending the another command parsed into the usable format to control the lighting;
controlling the lighting based on the another command parsed into the usable format to control the lighting
(¶ 50 “Gateway 406 may use various Internet-based protocols (e.g., CoAP, XMPP, AMQP, MQTT, etc.) and web-based common data exchange (e.g., HTTP RESTful APIs) to translate communications from a building automation system protocol to an Internet Protocol”; “¶ 87 “For example, the gateway 1128 may provide protocol conversions that make legacy non-IP enabled devices able to be accessed through modern web/IP protocols (e.g., converting BACnet Serial to CoAP, MQTT, or AMQP).”; 89 “In a further embodiment, the gateway 1128 is configured to provide protocol conversion services, network address conversion services, containers for messages, applications to understand different protocols such as Bluetooth, Zigbee, Z-wave, BACNet, etc., and/or any other user installed application.”; ¶ 91 “The protocol handlers 1134 may facilitate the translation of data received over the multiple communication protocols into a uniform, understandable, and/or useable format.”;
¶ 26, 46, 60, 63, 120 regarding remote user access and access rights to manage the building and remote devices, as well as provide a visually clean and intuited view of the building operations and the ability to resolve issues in real-time via a monitoring and control interface
¶ 25, 83, 85, 86 regarding the use of a wide range of Internet of Things (IoT) devices and IoT framework for integration and control of smart devices with the BMS, wherein each IoT device is designed to perform specific tasks and provide specific information, e.g., temperature sensor, dampers, chillers, heaters, RTU, AHU, fans, and so forth.
With regards to the first and second elements being lighting, respectively, see the additional analysis provided below.
The system allows for all of these devices, which can have their own respective communication protocol and computer code, to communicate with the system to monitor the state of the building and view the state in an interface to allow the system and a user to determine, for example, the temperature and air flow at a particular location (i.e. computer code is being translated from the IoT code to the BMS code and user understandable language (for example, English), issue a command to the remote device which involves translating/converting the command into code understandable by the specific device. Sinha discloses a wide range of devices (as discussed above) that each have their own corresponding function, e.g., increase fan speed, activate chiller, engage damper, and etc., which would require a command issued by the central system to lower the temperature to result in the command to be translated/converted in a manner to be understandable by each respective device, e.g., the command to lower the temperature or activate the cooling system would require the command to be translated for the fan to turn on, dampers to open or close, the chiller and its components to turn on, and valves to open or close. Each of these devices must have the command translated so that it is understandable by the device, e.g., if zoning is required a command to fully close, certain dampers to fully open, and certain dampers to be somewhere in between (which would require more than simply open or close an electrical switch to allow or stop the flow of electricity. The command needs to be translated to provide the specific instructions so that each damper can operate in the specific manner to coincide with the change) which would not be understandable by a fan that simply needs to allow the flow of electricity to turn on or, if it is a variable speed fan, the command needs to be translated in a manner for the fan to understand at what RPM it needs to operate.
The Examiner asserts that this is done by drivers and although not explicitly recited in Sinha, the Examiner asserts that this is inherently included. The Examiner also invites the applicant to review the provided NPL’s that explain that a driver is what allows one system to communicate with connected devices by serving as a translator, thereby further establishing that the system of Sinha would require the use of a driver to be able to communicate and control the wide range of smart devices, smart connected devices, and non-smart connected things, and etc.
However, in the interest of compact prosecution, the Examiner has provided Home Assistant to more explicitly teach that it would have been obvious to one of ordinary skill in the art that drivers need to be installed in a remote-control device and automation system, such as the one of Sinha, to integrate and control the remote devices).
Sinha discloses a system and method for monitoring, managing, and controlling a plurality of devices in a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices. As stated above, although one of ordinary skill in the art of computing, e.g., multi-core and multi-thread computer processing, looking upon Sinha would have found that Sinha does, indeed, disclose the emphasized portions of the limitations below, the Examiner has provided an additional analysis in view of arcserve to more explicitly teach this aspect of the invention, i.e. that it is well-known and obvious to one of ordinary skill in the art, based on the available technology, to utilize a multi-core server to process multiple streams of information.
To be more specific, Sinha fails to explicitly disclose:
processing by the second server the data received from the second sub-system by running another plurality of diagnostic session and analytic session on the data received from the second sub-system, wherein a second number of diagnostic sessions and analytic sessions is variably determined based on cores on the second server, wherein the second number of diagnostic sessions and analytic sessions are evenly spread over the cores on the second server
transmitting the processed data received from the second sub-system to the hub operably connected to more than one server, wherein the processed data from the second sub-system has undergone multiple diagnostic sessions in multiple streams to diagnose instances, and multiple analytic sessions in multiple streams to analyze instances;
However, arcserve teaches
“… Around 2004, something odd happened: while the number of transistors on the CPU continued to increase, processor clock speeds began to flatten. Performance continued to improve, but what was driving the interest in cores over clock speed? Enter the Multi-Core CPU The race between Intel and AMD continued, but the game had changed from clock speeds to multi-core chips. Around this time I traded in my single core Intel Pentium III for dual-core AMD chips running at a slower clock speed. Overall stability of my system increased along with performance, but few programs existed that could take advantage of more than a single core. While some games and a number of post-production tools such as Adobe Premiere are able to take advantage of today’s newest consumer-grade quad and hexa-core CPUs, I wanted to find out under which scenarios multi-core servers make sense to deploy today. Virtualization Memory management is critical when managing VMs, and is usually the first resource to become constrained. Using multi-core CPUs provides an increase in memory channels, allowing for large blocks of data to be processed and analyzed. Allowing the processor to access this data from memory instead of the hard drive results in much better performance. Multi-core servers also allow you to dedicate individual cores to each VM for better performance. Combine the additional memory channels with more cores and you have an environment that can handle the most demanding applications in a VM. High-Performance Computing High-performance computing (HPC) refers the practice of taking complex computations and breaking them into smaller pieces. Using software, each piece of the computation can then be solved by CPU cores. It’s almost like taking a supercomputer and breaking it down into smaller, more manageable building blocks that can then be used to solve complex scientific problems. HPC can also be very computational and memory intensive. … Multi-core processors also allow multiple databases to be consolidated onto a single server. Again, the increased memory bandwidth is the primary reason this is possible. … Cloud environments are also transaction heavy, and multi-core processors allow a company to quickly scale up the number of cores during peak computing times. Energy efficiency is also important to cloud environments. Cores can be turned off or on as needed to optimize workloads and reduce energy.”
…
“…Clock speed still plays a role when selecting a processor. Cores are important but they are still only one feature of a modern processor. Determining the number of cores your application supports is critical to matching it to the best processor for your money. …”
(For support see: Pages 2, 3)
One of ordinary skill in the art would have found it obvious and beneficial to take advantage of the advancements made in processor and server technology, such as, but not limited to, multi-core technology, as this provides the benefits of more processing power, increased efficiency, better performance, processing more information in less time, and so forth.
Further, one of ordinary skill in the art of computing would have found it obvious to update the data processing technique of Sinha using modern processing techniques, as taught in arcserve, in order to gain the commonly understood benefits of such adaptation, such as more processing power, increased efficiency, better performance, processing more information in less time, and so forth.
Accommodating the prior arts more antiquated process of simply focusing on making a processor faster with modern processing techniques, in this case, providing additional cores to process more information simultaneously (especially since Sinha already discloses this technique), would have been obvious. As stated in Leapfrog, “applying modern electronics to older mechanical devices has been commonplace in recent years.”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate into the server-based building management and control system that is in charge of remotely monitoring and controlling a plurality of remote devices of Sinha with the ability to utilize a multi-core server, as taught by arcserve as this would increase the processing power of the server by allowing it to control a plurality of remote devices and implement solutions more effectively, efficiently, and quickly in order to increase the overall management and control of the building.
The combination of Sinha and arcserve discloses a system and method for monitoring, managing, and controlling a plurality of devices in a building, such as, but not limited to, temperature sensors, pressure sensors, etc., configured to measure the temperature of a building and allow for the determination of whether the temperature should be adjusted as well as HVAC equipment, actuators, robots, health monitoring devices, water leakage sensors, lights, and other smart/non-smart devices and IoT devices. Although one of ordinary skill in the art would have understood that a “temperature sensor” is equivalent to a thermostat as temperature readings are taken and transmitted to the central system in order to control/manage the temperature of the building, the combination of Sinha and arcserve fails to explicitly disclose the more conservative interpretation of a thermostat.
To be more specific, the combination of Sinha and arcserve fails to explicitly disclose:
transmitting another command to the driver platform to parse the command into a usable format to control the lighting
parsing the another command into the usable format to control the lighting;
sending the another command parsed into the usable format to control the lighting
controlling the lighting based on the another command parsed into the usable format to control the lighting
However, Rochford, which is also directed to controlling devices using a remote device, further teaches that there is a plurality of IoT devices that exist in the art, such as, but not limited to, a thermostat, keypad, window shade, lights, and etc. Rochford teaches that an IoT environment provides intelligent Internet technology services that create value by collecting and analyzing data among connected things. IoT may be applied to a variety of fields including smart homes and smart buildings. One of ordinary skill in the art would have found it obvious that the devices of Rochford can be substituted for those of the combination of Sinha and arcserve while still achieving the same predictable result, i.e. monitoring, communicating, and providing commands to and from remote devices to manage a home or building.
(For support see: Pages 1 – 2 ¶ 1 – 7; Page 7 ¶ 36; Page 12 ¶ 62; Page 14 ¶ 72)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention that since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself-that is in the substitution of a thermostat, keypad, shade, lights, and etc., as taught by Rochford, for any of the number of devices disclosed by the combination of Sinha and arcserve.
Thus, the simply substitution of one known element for another producing a predictable result renders the claim obvious.
The combination of Sinha, arceserve, and Rochford discloses a system and method for managing a plurality of remote devices using a central system by, at least, transmitting commands from the central system to control the plurality of remote devices. As discussed above, one of ordinary skill in the art would have known that the communication and commands would need to be parsed into a usable format by way of a driver, however, in the interest of compact prosecution, the Examiner has provided Home Assistant to more explicitly teach this aspect of the claimed invention, i.e. drivers to translate/convert/parse communications between a computing system and remote devices.
To be more specific, the combination of Sinha, arceserve, and Rochford fails to explicitly disclose:
transmitting another command to the driver platform to parse the command into a usable format to control the lighting
parsing the another command into the usable format to control the lighting;
sending the another command parsed into the usable format to control the lighting
controlling the lighting based on the another command parsed into the usable format to control the lighting
However, Home Assistant, which is also directed to a smart automation system comprising a plurality of remote devices and remote system that are in communication with one another, teaches that in order to control a plurality of remote devices or remote smart devices, such as, but not limited to, a thermostat and security system, the central system requires the installation of drivers. Home Assistant teaches that drivers need to be installed so that the plurality of remote devices can be integrated into the building automation system and transmit commands to the remote devices to control the remote devices. Similar to what is disclosed in the provided NPL’s, Home Assistant teaches that drivers are used so that remote devices can be integrated into a building automation system so that a computing system can communicate and remotely control the remote devices.
(See Page 1)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate into the building automation system of the combination of Sinha, arceserve, and Rochford that is comprised of a plurality of remote devices, such as, smart connected devices, and non-smart connected things, and etc., communicating with and controllable by a central system, with drivers, as taught by Home Assistant (as well as supported by the provided NPL’s), as drivers are what allow a remote computing device to be able to communicate and control a wide range of remote devices, such as, but not limited to, smart connected devices, and non-smart connected things, and etc., e.g., thermostat, security system, and so forth.
Response to Arguments
Applicant's arguments filed 12/17/2025 have been fully considered but they are not persuasive.
Rejections under 35 USC 103
The applicant argues that the prior art of record fails to disclose, teach, or render obvious:
“processing by the first server the data received from the first sub-system by running a plurality of diagnostics session and analytics session on the data received from the first sub-system, wherein a number of diagnostic sessions and analytic sessions is variably determined based on cores on the first server, wherein the number of diagnostic sessions and analytic sessions are evenly spread over the cores of the first server”
(emphasis added)
However, the Examiner respectfully disagrees.
First, the Examiner asserts that one of ordinary skill in the art of multi-core, multi-thread, and parallel processing would have understood that Sinha does, indeed, disclose the emphasized elements above because Sinha discloses a multi-processing core and parallel processing infrastructure. However, for the purposes of compact prosecution, the Examiner provided an additional analysis in view of arcserve to more explicitly teach this aspect of the claimed invention. arcserve provides the technical description of what it is that the applicant is claiming and although it is not taught using the same terminology recited in the claimed invention, the Examiner asserts that one of ordinary skill in the art of multi-core, multi-thread, and parallel processing would agree that arcserve does, indeed, disclose these elements of the claimed invention. arcserve teaches how the technology functions, i.e. spreading processing across multiple cores, which, one of ordinary skill in the art would have known to be performed dynamically as data is constantly being processed and the system determines how to process the incoming data over the available cores and that this process covers scenarios where loads are unevenly distributed due to the performance or capability of each of the cores and data needing processing or evenly distributed due to the performance or capability of each of the cores and data needing processing. This is how the technology works and the applicant’s particular scenario falls under or is obvious within the teachings of arcserve and what one of ordinary skill in the art of multi-core, multi-thread, and parallel processing would have known in view of the teachings of arcserve. Further still, as was discussed in the rejection, both Sinha and arcserve disclose assigning tasks to a respective processor, thereby establishing that diagnostic session processing can be assigned to a first processor and analytic sessions can be assigned to a second processor, thereby evenly spreading the processing, i.e. each respective session, by assigning each session to a respective processor. Additionally, in view of arcserve, one of ordinary skill in the art would have found it obvious to evenly spread the processing load based on the number of available processors, especially if the clocks of each of the processors are the same.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure found in the PTO-892 Notice of References Cited:
Turney et al. (US Patent 12,379,718 B2); Frei et al. (US PGPub 2016/0043926 A1); Hamza (Understand the Basic concept of BMS system); Smart Buildings Academy (The Ultimate Guide to Building Automation Systems) – which are directed towards building management systems and controlling of devices within a building
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GERARDO ARAQUE JR whose telephone number is (571)272-3747. The examiner can normally be reached Monday - Friday 8-4:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah Monfeldt can be reached at 571-270-1833. 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.
GERARDO ARAQUE JR
Primary Examiner
Art Unit 3629
/GERARDO ARAQUE JR/Primary Examiner, Art Unit 3629 1/28/2026