Invented by Jim KITCHEN, David Proft, Weiping Guo, Kyle McKenzie, Thomas LEA, John Elderton, Nathan YANG, IControl Networks Inc

The market for cloud-based systems for building automation has been rapidly growing in recent years. As technology continues to advance, businesses and organizations are looking for ways to streamline their operations and improve efficiency. Cloud-based systems offer a solution that allows for centralized control and management of various building automation systems, such as lighting, HVAC, security, and energy management. One of the key advantages of cloud-based systems is the ability to access and control building automation systems remotely. This means that facility managers and building owners can monitor and adjust settings from anywhere, using any device with an internet connection. This level of flexibility and convenience is particularly beneficial for businesses with multiple locations or for those who have staff members working remotely. Another advantage of cloud-based systems is the scalability they offer. As businesses grow and expand, their building automation needs may change. With cloud-based systems, it is relatively easy to add or remove devices and sensors as required. This scalability ensures that the system can adapt to the changing needs of the business without requiring significant investments in new hardware or infrastructure. Cloud-based systems also provide businesses with valuable data and analytics. By collecting and analyzing data from various building automation systems, businesses can gain insights into energy usage patterns, identify areas for improvement, and optimize energy efficiency. This data-driven approach allows businesses to make informed decisions and implement strategies to reduce energy consumption and lower operating costs. Security is a critical concern for any business, especially when it comes to building automation systems. Cloud-based systems often offer robust security measures, including encryption, authentication, and regular system updates. These security features help protect sensitive data and ensure that only authorized personnel can access and control the building automation systems. The market for cloud-based systems for building automation is expected to continue growing in the coming years. As businesses become more aware of the benefits and cost savings associated with these systems, the demand is likely to increase. Additionally, advancements in technology, such as the Internet of Things (IoT) and artificial intelligence, will further enhance the capabilities of cloud-based systems, making them even more attractive to businesses. In conclusion, the market for cloud-based systems for building automation is expanding rapidly. Businesses and organizations are recognizing the benefits of centralized control, remote access, scalability, data analytics, and enhanced security that these systems offer. As technology continues to evolve, cloud-based systems will play a crucial role in optimizing building operations, reducing energy consumption, and improving overall efficiency.

The IControl Networks Inc invention works as follows

A system comprises premises equipment including premises devices located at a premises. The system contains a device configured to run a different protocol than the equipment. The system contains a server that is configured to interact with premises devices. The system server interacts with the partner devices via a proxy that corresponds to the device. The system is equipped with automation rules that are coupled to the server. Automation rules can include triggers and actions for controlling interactions with at least one partner device or premises device. The system includes an interface that is coupled to the server system and configured to communicate with both the premises devices as well as the partner device.

Background for Cloud-based system for building automation

There is a requirement for systems and methods to integrate cloud services with internet-connected devices, as well as other components and features of a system provider. This integration would allow third-party and/or connected devices (e.g. smart doorbells, doorlocks, garage door operators. cameras. thermostats. lighting systems. lighting devices. etc.) to control or trigger automations in the service provider system using components and functions of the service provider system. Third party devices and services can control or trigger automations within the service provider’s system by using the components and functions provided by the service provider. This would enable end-users to integrate and use their previously-standalone internet-connected devices with each other as well as with their service provider-based service.

INCORPORATION BY RESEARCH

Each Patent, Patent Application, and/or Publication mentioned in this Specification is herein incorporated in its entirety by reference to the same extent that if each patent, application, or publication were specifically and individually stated to be incorporated in reference.

Systems and Methods comprise premises equipment, including premises devices at a location. A partner device located in the premises is configured to use a different protocol than the protocol of the premises devices. A system server interacts with both the premises devices as well as the partner device. The system server is connected to a user interface that interacts with the premises devices. The user interface has a partner interface that corresponds to the device. The partner interface is configured to allow the user interface and the partner device to interact. The user interface controls interactions between premises devices and partner devices.

Embodiments” also include systems and method that comprise premises equipment, including devices at a location. The system contains a device that is located in the premises, and which uses a different protocol than the equipment. The system contains a server that is configured to interact with premises devices. The system server interacts with the partner devices via a proxy that corresponds to the device. The system is equipped with automation rules that are coupled to the server. Automation rules can include triggers and actions for controlling interactions with at least one partner device or premises device. The system includes an interface that is coupled to the server system and configured to communicate with both the premises devices as well as the partner device.

FIG. The block diagram 1 shows the integrated cloud platform or system, according to an embodiment. The integrated cloud system of an embodiment is composed of cloud-based components, including a Cloud Integration Service/Server. (CIS), which is coupled to a System Server (e.g.?Icontrol?, also referred herein as the Service Provider server) via an event bus. The CIS and system server are implemented in the data centers of service providers’ customers. However, this is not limited.

The system server is connected to the customer-premises (CPE) in the subscriber premises. The CPE may include one or more security panels, security systems and gateways. It can also include touchscreens and Wi-Fi accesspoints. The CPE is detailed in the Related Applications, which are incorporated herein by reference.

The CIS has been coupled with a production server of a partner (?partner server?) via a Cloud Integration Adapter (CIA). The partner server is responsible for interacting with the products/services their users want to integrate into their ICS platforms. Cloud Integration Adapter is a REST-based endpoint that the CIS and system server can use to check the adapter’s health, associate with adapter cloud devices and process events from the CIS. The Cloud Integration Adapter also sends events to the CIS to acknowledge incoming system events and to report Adapter-managed cloud device events into the system servers.

The ICS of a service provider system integrates cloud services and internet connected devices with the Rules Engine, user interface and other components and features of the service provider’s system. This integration allows third-party and/or connected devices to be used (e.g. smart doorbells, such as Doorbot etc. ), door locks, garage door operators (e.g., Chamberlain, etc. ), cameras (e.g., Dropcam, etc. Nest thermostats, for example, are a good choice. ), lighting systems (e.g., Philips Hue, etc. Lighting devices, lawn irrigation system (e.g. Rachio), etc. Plant sensors, pet feeders and weather stations with rain sensors. Pool controls, air quality sensors. Music systems, remote control, internet user interfaces. Connected systems. The third-party services include weather forecasting applications and services, such as Accuweather. Family networking applications and services, third-party services or partner services, Accuweather as well as digital assets from MSOs such voicemail are all examples of these. The user interface, Rules Engine, and other components of the system can be used to trigger or control automations within the service provider’s system. This enables end-users to integrate and use their previously-standalone internet-connected devices with each other as well as with their service provider-based service.

The ICS as described herein in detail includes one or more of the components of the ‘integrated security system’. The Related Applications are described in detail and incorporated herein by reference. A ‘integrated security system’ is an example. iControl Networks, Inc., Redwood City, Calif., offers a variety of systems and platforms. The ICS in an embodiment combines one or more components from the ‘integrated security system’. The ICS of an implementation is coupled with one or more components from the “integrated security system”. The ICS of an implementation integrates with one of more components in the “integrated security system”.

The system server hosts or includes a partner proxy as well as an integration REST API (application programming interface). The integration REST application programming interface (API) is coupled with the CIS. The partner proxy is connected to a corresponding server and also to a Card UI. The partner proxy can be configured to proxy API requests from the Partner Card UI (REST Client) to the Partner Server, and to append the appropriate OAuth Token to a user. All client UIs can be enabled once a single pairing of OAuth is complete (i.e. if a user authorizes Partner?s product, then all users on the same account have it automatically enabled and populated). It also increases security because the credentials of the user are not stored on the Partner server. “The Card UI is a HTML5-based interface card that was developed by the Partner or service provider and is embedded in the user interface of the service provider (e.g. mobile app, web page).

The ICS of an embodiment includes Cloud Actions and Triggers (CAT), which enable third party connected devices and services to trigger automations in the service provider system, thereby enabling end-users to integrate and use their previously-standalone internet connected devices with their service provider-based service.

Cloud objects are devices and services hosted outside the automation platform. When integrated into an embodiment, they can be used in a variety of ways. “The description below includes details on aspects of the system, including but not restricted to the server infrastructure required to support cloud objects externally, data formats definitions for triggers and actions across the event bus and the process of onboarding cloud objects.

The CAT of an embodiment integrates services from partners into the ICS platform, including support for CPE rules and partner-specific interfaces based upon the Card UI. A system embodiment has a web-based API for the CIS, for which partners create Integration Adapters. The translation of events and operations from the service provider into proprietary partner calls is done by Integration Adapters (also referred to as?adapters?) The Card SDK allows partners to create Cards with branded user interfaces. In one embodiment, the partners host their Integration Adapters within their own environments. However, in another embodiment, the ICS is used to hose the adapters.

The embodiments are not limited to the CPE running the rules engine. In an alternative embodiment, the rules engine can be included and run on a component or system server of the ICS platform.

In another alternative embodiment, the rules engine can be distributed between the CPE platform and the ICS platform. This means that a certain set of rules will run on the CPE platform while another set is running on ICS. CPE includes and runs rules that control actions and triggers for local devices within the premises and do not use any data or information from outside the premises. “Similarly, rules controlling triggers and actions involving devices in the premises and also involving service(s), device(s), or device(s), outside the premises are included and run on the CPE.

The CAT does not limit itself to the use cases of Service Association, Cloud Object Creation and Disassociation, Cloud Object Synchronizations, Card UI Interactions or Rule Authoring. The use cases are described in depth here.

At startup, Partner’s Cloud Integration Adapter uses the username, password, and partnerKey to authenticate against the CIS. The service provider provides the username, password and PartnerKey. As part of the initial partner onboarding, the Event Callback URL for Partner and Health Check URL is defined. The CIS provides the partner with two URLs that can be updated at runtime.

The Register Event Callback URI enables partners to update the Event Callback URL during runtime.

Endpoint /cloudIntegration/[partnerName]/eventCallback/\nregisterEventCallback?partner Url=[partnerUrl]\nDescription Update the eventCallback URL for a partner\nMethod POST\nHeader x-login – username of the integration user\nx-password – password of the integration user\nx-partnerKey – unique key issued by Service provider to\nthe partner\nURL partnerName: The unique name of the partner provided\nparameters by Service provider partnerUrl: The updated\nEvent Callback URL\nResult HTTP response 200 if successful

An example of a payload may include, but is not restricted to:

Click here to view the patent on Google Patents.