Invented by Joss Scholten, Kent Dickson, Garett Madole, Yonomi Inc
The Yonomi Inc invention works as followsA virtual gateway application can be configured to receive command instructions from a user or remote server via the Internet, a wireless LAN, or a protocol for short-range communications. The application can relay the immediate commands to one or more connected devices using the wireless LAN protocol or short-range communication protocol, while the device that the application resides on is in the building. It can store the delayed commands for local devices that come from both the user and the remote server via the Internet. Then, it can relay the delayed instructions to the connected devices using the wireless LAN protocol or short-range communication protocol.
Background for Virtual Gateway for a Connected Device
Historically, the remote control of devices that communicate wirelessly or with wires in a building (or other environment) has been enabled through a physical controller. This controller contains memory, storage, logic, and multiple wireless radios. It also has a connection to your home router. This controller was typically a local device, which enabled communication between local devices and the hub. This controller hub was used to connect some devices with other services enabled by the internet. This connection allows the remote Head End Controller Service to send commands and gather data to devices that are connected to the controller hub at the local premises.
Currently, devices like Bluetooth speakers and fitness bands can communicate directly via local protocols, such as Bluetooth Low Energy or Bluetooth. These devices are relatively small, making it difficult to communicate with them via a fixed hub that could be anywhere in the home or environment.
Furthermore it may be desirable to give a person (such as a resident of a home) the ability to intelligently control multiple devices locally in a convenient way.
An aspect” of the present disclosure is a virtual gateway application that runs on a mobile device, and which can be configured to control functions for a plurality connected devices local to a building environment. The virtual gateway application may include a graphic user interface, and is configured to receive command instructions from a user via the graphical interface of the mobile device or a remote server via the Internet via wireless LAN. Virtual gateway software applications may also be configured to relay immediate command instructions received by the mobile device via wireless LAN, short-range protocol or cellular data connection to one or more connected devices while the mobile device is in the building environment. It can store the delayed command instructions from the remote server via the WAN/cellular data connection or the graphical interface of the mobile device for one or more connected devices. Virtual gateway software may also be configured to relay delayed command commands from the mobile device to the connected devices using the wireless LAN protocol or short-range communication protocol, at a time determined by the one of more delayed command instruction while the mobile device is in the building environment.
The present disclosure also provides a virtual gate software application that is executed on a device to display television content from the Internet and to control the functions of multiple connected devices located in a building. Virtual gateway software applications may include a graphical interface. They may also be configured to receive command instructions from a user via the graphical interface of the hardware device that displays television content from internet, and from a remote server via a WAN connection or satellite via a wireless network or short-range protocol. Virtual gateway software applications may also be configured to relay immediate command instructions received by the hardware for displaying internet television content to one or more connected devices via wireless LAN, or short-range communication protocols while the hardware for displaying internet television content is located within the building. It can store the delayed command instructions from both the user via the graphical interface of the hardware device displaying the television content from internet, and from the remote server via the WAN/cellular data connection. Virtual gateway software applications may also be configured to relay delayed command commands from the hardware for displaying TV content from internet to one of more connected devices via wireless LAN, or short-range communication protocol. This can occur at a specified time while the hardware for displaying TV content from internet is in the building environment.
Another aspect of the disclosure is a virtual gateway application that can be executed on a tablet and configured to control functions for a plurality connected devices local to a building environment. The virtual gateway application may include a graphical interface, and is configured to receive command instructions from a user via the graphical interface on the desktop PC; and from a remote server via a WAN over a wireless LAN protocol or short-range communication protocol. Virtual gateway software applications may also be configured to transmit the immediate commands received by the tablet to one or more connected devices using the wireless LAN protocol or short-range communication protocol, while the tablet is still within the building. It can store the delayed command instructions from the user via the graphical interface of the tablet computer, and the remote server via the WAN for one or more connected devices. Virtual gateway software may also be configured to relay delayed command commands from the tablet to one or multiple connected devices using the wireless LAN protocol or short-range communication protocol, at a time determined by the delayed command instruction.
Smart devices are becoming more common in the home and workplace. Devices that are connected to one another and the Internet. These devices are sometimes called ‘connected devices. These devices are also known as ‘connected devices? IoT is another name for the Internet of Things. The IoT is being used to connect many everyday household items and make them more convenient for users. In response to the proliferation of IoT devices, several competing platforms, radios, and protocols have been introduced to allow these devices to be connected to the Internet, and controlled remotely by services or users. These devices often come with physical hubs that are required to control them. The connected devices can also be controlled via proprietary head-end controllers that are available over the Internet. The majority, if they do not include all devices, come with an application that can be downloaded to a mobile device for remote control. The challenge with having multiple devices by multiple manufacturers is to streamline the user experience. It’s not convenient to use separate mobile apps for each device you want to control. The convenience of IoT devices is defeated if it becomes difficult for the user to control the various connected devices at home. Physical control hubs are a common solution for this problem. They are designed to consolidate all the device controls and protocols in one central user interface.
The rate of innovation of IoT devices leads to a rapid obsolescence rate for physical controller hubs. As mentioned previously, different IoT devices use different wireless radios and different transmission protocols for short- and long-range communication. There are many competing communication platforms. Even if an industry segment coalesces behind a specific protocol, it will eventually be replaced by a faster, better platform. A physical controller hub would ideally have radios that communicate via Wi-Fi and Bluetooth, Bluetooth Low Energy (BLE), Zigbee (4G, LTE, NFC) and other technologies. In two years, some of the radios listed could be outdated; and it’s possible that most IoT devices may use another type radio not listed. Physical hubs can cost between $200 and $500. Consumers will be unhappy if they have to keep upgrading these devices to get their IoT devices to work.
However consumers are used upgrading certain devices fairly often; namely personal communication devices like smartphones, wearables tablets and laptops. In this disclosure the term “personal communication device” is used. The term “personal communication device” will be used for a computing system that is used primarily and equipped with multiple modes of interpersonal communications. Personal communications devices include, for example, smartphones used primarily for texting, social media and calling, smartwatches used primarily to track activity, receive notifications and personal information, tablets used primarily for web browsing, smart TVs used primarily for watching media and desktop computers used primarily for creating documents, sending emails and playing games. Personal communications devices can be mobile but are not restricted to mobile devices. Personal communication devices can be distinguished from physical controllers hubs by the fact that controller hubs serve primarily to facilitate communications between IoT device and that interactions between a user with a hub are typically primarily for setting up and programming connected devices. IoT devices or connected devices can be distinguished from personal communication devices for the purposes of this publication because they have a single or limited purpose and are relatively static in a work or home environment. In this disclosure, IoT and connected devices refer to devices which are generally located in a single local environment such as a home or office.
A virtual gateway is an aspect of the disclosure. It consists of a remote head end controller service (HECS), which may use the hardware of a mobile device to relay signals to one or multiple IoT devices, enabling the mobile device to replace a dedicated physical device as the hub. Virtual gateways can use the hardware on a personal communication device by downloading an application or service onto the device. The disclosure has the benefit that the remote head end controller service can be centrally updated (either via software, hardware or firmware) and the application can also be upgraded by the HECS to meet the requirements of new IoT device communication platforms. However, the hardware of the consumers does not have to be upgraded. If many new IoT device adopt a standard of communication that requires a different kind of radio or transceiver, it is anticipated that many personal communications devices will be equipped with that same radio or transceiver. IoT users are likely to upgrade personal communications devices often, and they may use their personal communication devices as a virtual controller hub rather than buying a new physical controller.
Referring to the drawings wherein like or similar elements have been designated with the same reference numbers throughout the various views, and in particular, FIG. In FIG. 1, a home IoT system according to prior art is shown, where a physical hub 100 creates local connections with connected devices 102-106. The physical hub is linked to the internet by a router or an access point 107. This in turn connects one or more remote controller services 109 through a fixed internet provider 108.
Now turn to FIG. In FIG. 2, a system according to an embodiment of the disclosure is shown. The system 200 comprises a personal communications device 201, mobile data connection (HECS) service 203, internet service provider (ISP) 204, access point 205 and a plurality local devices 206a-206e. In some embodiments, the system may include a proprietary HECS of a third-party and/or network bridge 208. Virtual gateways are some aspects of the invention. They may include a software application which can be downloaded to one or more communication devices, such as mobile phones or tablets or wearable devices like smartwatches. In certain embodiments, the software can be stored on a remote application network. This may include a computer 600 (shown in Figure). 6) or an HECS 203 that can be used by the personal communications device 201. In certain embodiments, HECS 203 can be implemented on remote servers, whether public or private, such as those that are commonly referred to as “cloud” servers. servers.
As described in this disclosure, when reference is made to personal communication devices that function as virtual gateways, it can be assumed that the personal communications devices are enabled with some implementation of a virtual gate, even though an application, service or logic may not always be specifically mentioned. When referring to personal communication device that act as virtual gateways in this disclosure, one can assume that these devices are equipped with a virtual portal, even though the application, service or logic may not be specifically described.
Still referring to FIG. The system 200 can include local connected devices. These may include, for example, but are not limited to, a washing system 206a, an outlet 206b, a sound-system 206c, an environmental control/sensor (206d), and a lighting system 206e. Herein, any IoT devices within an environment that is to be monitored or controlled are referred to as local connected devices. The figures show a static residential setting, but any type of environment can be considered local for this disclosure, even if it is a static commercial or dynamic environment. Local environment can be defined as a grouping of devices that have been historically controlled or connected via a local area networks (LAN), WiFi, Bluetooth, Zigbee or other local connections.
The personal communication device (201) is in intermittent or constant communication with the mobile data connection (202), which could be a cellular provider. The personal communication device (PCD) 201 communicates intermittently with the head-end controller services (HECS) through the mobile data connection or internet service provider. The personal communication device 201, for example, may be configured so that it requests and/or receives signals from the HECS 203 on a periodic basis.
The internet service provider 204 can provide internet services to local users through an access point 205, which could include a wireless network router. The local TCP/IP is formed by the access point 205. Local connected devices 206a-206d and 208 can join this network to communicate locally and with the internet.
In some embodiments, the local device 206e can be configured to receive signals from a network bridge 208 rather than from an access point 205 or a personal communications device 201. Many IoT devices are equipped with physical network interfaces, which allow them to communicate with a local access point or a proprietary head-end controller. Some IoT devices require network bridges to function properly. They need constant communication, even when there isn’t a central hub. A network bridge is almost always required by an alarm system, for example. This is because the purchaser expects the system to work even without an additional physical controller hub. Other devices, however, are sold with connectivity as an optional feature rather than the primary feature. The consumer can connect these devices to an existing hub, or another way of connecting it. However, the device could be designed to work as a stand-alone. A single Bluetooth speaker, for example, may be able to connect to the entire network via Wi-Fi, Bluetooth or both, but it does not have to. Bluetooth can be used to connect to a single media player, even if the whole LAN is not connected. Also, speakers, TVs, washers and dryers are unlikely to be used often if nobody is at home. Therefore, they will not be equipped with an internet connection via a physical hub.
There are also other IoT devices that can only receive instructions from a proprietary HECS 207. The local device 206 d can be permanently restricted from receiving instructions from controllers other than the proprietary HECS 207 of the third party associated with the local device 206 d. This is because certain IoT thermostat systems may need proprietary HECS 207 to function as they must constantly receive information and input from the internet. To solve this problem, HECS 203 and/or personal communication devices 201 can be configured to send instructions to a network bridge of a third-party or to a proprietary HECS 207 that, in turn, controls the local device 206 d.
Now turn to FIG. The third embodiment of the system 300 is shown. The components shown in FIG. The system 300 can include a plurality personal communication devices 201 301 302 As shown, the plurality 201 of personal communications devices may be arranged so that the majority of them are located within the local area, and only one is outside.
In the system, the HECS 203 can be configured to evaluate the state information and environmental information associated with any or all of the personal communications devices 201, 301, 302. State information can include battery information, connectivity information, how long the device was idle, and what applications were being used. These state information can be sent to the HECS 203 via subscriptions offered by mobile service providers or device operating system APIs. Environmental information can include geolocation and sensory information such as accelerometers, gyroscopes or light sensors. It may also include local weather information, time, calendar, etc. Many types of environmental data are well-known in the industry, and can be made available to the HECS 203 via subscription services. State information and/or environment information can be used in many ways to implement aspects described herein. A combination of connectivity and location information can be used to determine the best personal communication device to use in relaying a signal from a local connected device. A user might want to turn on a certain device, such as a soundsystem 206 c. HECS 203 can determine that a personal communication 201 is located in the same local area, but does not have a good signal connection. However, a personal communication 301 has a better connection because it’s close. The HECS 203 is configured, after making this determination to have the second personal communications device 301 relay instructions to operate the sound system 206 c. In the following disclosure, embodiments and examples for determining a “best path” will be described in more detail.
In some embodiments, a downloadable software application is used to configure a personal communications device to be able relay control signals to devices local in a specific environment. In some embodiments, the user can gain authorization to control certain devices within a specific environment. This authorization can be established by a network administrator, or homeowner who has the local Wi-Fi password and SSID, and may have configured all devices connected to an environment. The network administrator, or homeowner, can then grant different permission levels to other users and allow them to control the local devices within an environment. A parent, for example, may be able to control all household devices via an app on their personal communication device. Meanwhile, a child could have full control except the door locks and television.Click here to view the patent on Google Patents.