KR20170132263A - System and method for accurately detecting user location in IoT system - Google Patents

Abstract

A system and method for accurately detecting the location of a wireless device is described. For example, one embodiment of a method includes collecting signal strength data indicative of signal strength between a wireless device and a plurality of IoT devices and / or IoT hubs in a user's home; Associating the signal strength data with locations within a user's home and storing the association in a location database; And determining the current location of the wireless device by comparing signal strength data within the database with current signal strength data representative of the current signal strength between the wireless device and the plurality of IoT devices and / or the IoT hub.

Description

System and method for accurately detecting user location in IoT system

The present invention relates generally to the field of computer systems. More particularly, the present invention relates to a system and method for accurately detecting a user's location in an IoT system.

The "Internet of Things" refers to the interconnection of uniquely identifiable embedded devices within the Internet infrastructure. Ultimately, IoT is a new broad type of application that can provide virtually any type of physical object itself or information about its surroundings and / or can be remotely controlled via a client device via the Internet It is expected to generate.

IoT development and adoption was slow due to issues related to lack of connectivity, power, and standardization. For example, one obstacle to IoT development and adoption is that there is no standard platform for allowing developers to design and deliver new IoT devices and services. To enter the IoT market, developers must design the entire IoT platform from start to finish, including the network protocols and infrastructure, hardware, software and services required to support the desired IoT implementation. As a result, each provider of IoT devices uses proprietary techniques for designing and connecting IoT devices, making the adoption of multiple types of IoT devices burden the end user. Another hurdle to adopting IOT is the difficulty associated with connecting and powering IoT devices. For example, connecting a device such as a refrigerator, a garage door opener, an environmental sensor, a house security sensor / controller, etc. requires an electrical source to power each connected IoT device, Not located.

Another problem that exists is that the wireless technologies used to interconnect IoT devices such as Bluetooth LE are typically short-range technologies. Thus, if the data collection hub for an IoT implementation is outside the scope of an IoT device, the IoT device will not be able to transmit data to the IoT hub (and vice versa). As a result, there is a need for techniques that enable the IoT device to provide data to an IoT hub (or other IoT device) that is out of range.

BRIEF DESCRIPTION OF THE DRAWINGS A better understanding of the present invention can be obtained from the following detailed description taken in conjunction with the following drawings.
Figures 1a and 1b illustrate different embodiments of the IoT system architecture.
2 illustrates an IoT device according to an embodiment of the present invention.
3 illustrates an IoT hub according to an embodiment of the present invention.
Figures 4A and 4B illustrate embodiments of the present invention for controlling and collecting data from IoT devices and generating notifications.
Figure 5 illustrates embodiments of the present invention for collecting data from IoT devices and generating notifications from an IoT hub and / or IoT service.
Figure 6 illustrates problems associated with identifying a user in current wireless lock systems.
Figure 7 illustrates a system in which IoT devices and / or IoT hubs are used to accurately detect the location of a user of a wireless lock system.
Figure 8 illustrates another embodiment in which IoT devices and / or IoT hubs are used to accurately detect the location of a user of a wireless lock system.
9 illustrates an embodiment for calibrating a position detection system and detecting a position of a user based on signal strength values.
10 illustrates a method for implementing a wireless lock system using IoT devices and / or IoT hubs.
Figure 11 illustrates one embodiment of a method for calibrating a wireless lock system.
Figure 12 illustrates one embodiment of the present invention for determining the position of a user with signal strength values.
Figure 13 illustrates another embodiment for calibrating a position detection system and detecting the position of a user based on signal strength values.
Figure 14 illustrates embodiments of the present invention that implement improved security technologies such as encryption and digital signatures.
Figure 15 illustrates one embodiment of an architecture in which a subscriber identity module (SIM) is used to store a key on an IoT device.
16A illustrates an embodiment in which an IoT device is registered using a bar code or QR code.
16B illustrates an embodiment in which pairing is performed using a bar code or QR code.
Figure 17 illustrates one embodiment of a method of programming a SIM using an IoT hub.
18 illustrates an embodiment of a method for registering an IoT device with an IoT hub and an IoT service.
19 illustrates an embodiment of a method of encrypting data to be transmitted to an IoT device.

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention described below. However, it will be apparent to those skilled in the art that the embodiments of the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the underlying principles of an embodiment of the invention.

One embodiment of the present invention includes a Internet of Things (IoT) platform that can be used by developers to design and build new IoT devices and applications. In particular, one embodiment includes a predefined networking protocol stack through which IoT devices are coupled to the Internet and a base hardware / software platform for IoT devices including IoT hubs. Additionally, one embodiment includes an IoT service in which IoT hubs and connected IoT devices can be accessed and managed as described below through it. Additionally, one embodiment of the IoT platform includes an IoT service or a web application for accessing and configuring IoT services, hubs, and connected devices (e.g., running on a client device). Existing online retailers and other web site operators can leverage the IoT platform described herein to easily provide native IoT functionality to an existing user base.

Figure 1A illustrates an overview of an architectural platform in which embodiments of the present invention may be implemented. In particular, the illustrated embodiment includes a plurality of IoTs 120 communicatively coupled to a central IoT hub 110 communicatively coupled to the IoT service 120 via the local communication channel 130, Devices 101-105. Each of the IoT devices 101-105 may be initially paired to the IoT hub 110 to enable each of the local communication channels 130 (e.g., using the pairing scheme described below). In one embodiment, IoT service 120 includes an end user database 122 for maintaining user account information and data collected from each user's IoT device. For example, if the IoT device includes sensors (e.g., temperature sensors, accelerometers, thermal sensors, motion detectors, etc.), the database 122 continues to store the data collected by the IoT devices 101-105 Can be updated. The data stored in the database 122 may then be accessed by the end user (e.g., via the IOT service 120 (e.g., via a desktop or other client computer system) via an IoT app or browser installed on the user's device 135 (E. G., A web site 130 subscribed to a web site).

The IoT devices 101 to 105 collect information about themselves and their surroundings and send the collected information to the IoT service 120, the user device 135 and / or the external website 130 via the IoT hub 110 Various types of sensors may be provided for providing. Some of the IoT devices 101-105 may perform designated functions in response to control commands transmitted via the IoT hub 110. [ Various specific examples of information and control commands collected by IoT devices 101-105 are provided below. In one embodiment described below, IoT device 101 is a user input device designed to record user selections and to send user selections to IoT service 120 and / or a website.

In one embodiment, the IoT hub 110 may include a cellular radio for establishing a connection to the Internet 220 via a cellular service 115, such as 4G (e.g., Mobile WiMAX, LTE) or 5G cellular data service . Alternatively or additionally, the IoT hub 110 may be coupled to a WiFi access point or router 116 (e.g., via an Internet service provider that provides Internet service to end users) that couples the IoT hub 110 to the Internet Gt; WiFi < / RTI > Of course, it should be noted that the underlying principles of the present invention are not limited to any particular type of communication channel or protocol.

In one embodiment, IoT devices 101-105 are ultra low power devices that can operate for extended periods of time (e. G., Several years) with battery power. To conserve power, the local communication channel 130 may be implemented using a low power wireless communication technology such as Bluetooth low energy (LE). In this embodiment, each of the IoT devices 101 to 105 and the IOT hub 110 is equipped with a Bluetooth LE radio and a protocol stack.

As mentioned, in one embodiment, the IoT platform is configured to allow the user to access and configure the IoT devices 101-105, the IoT hub 110, and / or the IoT service 120, Lt; RTI ID = 0.0 > 135 < / RTI > In one embodiment, the app or web application may be designed by an operator of the website 130 to provide IoT functionality to its user base. As illustrated, the web site may maintain a user database 131 containing account records associated with each user.

Figure IB illustrates additional connection options for a plurality of IoT hubs (110, 111, 190). In this embodiment, a single user may have multiple hubs 110, 111 installed on-site in a single user premises 180 (e.g., a user's home or business). This can be done, for example, to extend the radio range needed to connect all of the IoT devices 101-105. As indicated, when a user has multiple hubs 110 and 111, they may be connected via a local communication channel (e.g., Wifi, Ethernet, power line networking, etc.). In one embodiment, each of the hubs 110 and 111 may establish a direct connection to the IoT service 120 via a cellular 115 or WiFi 116 connection (not explicitly shown in FIG. 1B). Alternatively, or additionally, one of the IoT hubs, such as the IoT hub 110, may be coupled to the IoT hub 111 (as indicated by the dashed line connecting the IoT hub 110 and the IoT hub 111) Master hub " that provides connectivity and / or local services to all of the other < RTI ID = 0.0 > IoT hubs on user premises 180. < / RTI > For example, the master IoT hub 110 may be the only IoT hub for establishing a direct connection to the IoT service 120. In one embodiment, only a "master" IoT hub 110 is equipped with a cellular communication interface for establishing a connection to the IoT service 120. Therefore, all communication between the IoT service 120 and the other IoT hub 111 will flow through the master IoT hub 110. In this role, the master IoT hub 110 performs a filtering operation on data exchanged between the other IoT hub 111 and the IoT service 120 (e.g., where possible, servicing some data requests locally) Additional program codes may be provided for execution.

Regardless of how the IoT hub 110, 111 is connected, the IoT service 120, in one embodiment, is a single, comprehensive user interface (and / or browser- Based interface), the hub will logically associate with the user and combine both attached IoT devices 101-105.

In this embodiment, the master IoT hub 110 and the one or more slave IoT hubs 111 are connected via a local network, which may be a WiFi network 116, an Ethernet network, and / or a power-line communications (PLC) (E. G., Where all or part of the network is driven through the user ' s power line). Additionally, for the IoT hubs 110 and 111, each of the IoT devices 101-105 may communicate with the IoT devices 101-105 using any type of local network channel, such as WiFi, Ethernet, PLC or Bluetooth LE, And may be interconnected with the hubs 110 and 111.

Figure lb also shows the IoT hub 190 installed in the second user premises 181. [ An essentially unlimited number of such IoT hubs 190 may be installed and configured to collect data from IoT devices 191, 192 in user premises worldwide. In one embodiment, two user premises 180, 181 may be configured for the same user. For example, one user premises 180 may be the user's primary home, while the other user premises 181 may be the user's home. In such a case, the IoT service 120 may provide the IoT hub 110 (110, 111, 190) with a single user interface (and / or browser-based interface) Will logically associate and combine all of the attached IoT devices (101-105, 191, 192).

2, an exemplary embodiment of IoT device 101 includes a memory 210 for storing program code and data 201-203, and a low power microcontroller < RTI ID = 0.0 > (200). The memory 210 may be a volatile memory such as a dynamic random access memory (DRAM), or may be a non-volatile memory such as a flash memory. In one embodiment, non-volatile memory may be used for persistent storage, and volatile memory may be used for execution of program code and data at runtime. The memory 210 may also be integrated into the low power microcontroller 200 or coupled to the low power microcontroller 200 via a bus or a communication fabric. The underlying principles of the present invention are not limited to any particular implementation of memory 210.

As illustrated, the program code includes application program code 203 that defines an application-specific set of functions to be performed by IoT device 201, and a predefined definition that can be used by the application developer of IoT device 101 And a library code 202 comprising a set of building blocks. In one embodiment, the library code 202 is stored in a storage medium such as a storage medium, such as a communication protocol stack 201 for enabling communication between each IoT device 101 and the IoT hub 110, And a set of functions. As noted, in one embodiment, the communication protocol stack 201 includes a Bluetooth LE protocol stack. In this embodiment, the Bluetooth LE radio and antenna 207 may be integrated into the low power microcontroller 200. However, the underlying principles of the present invention are not limited to any particular communication protocol.

2 also includes a plurality of input devices or sensors 210 for receiving user inputs and providing user inputs to a low power microcontroller, which low power microcontroller includes application code 203 and library code Lt; RTI ID = 0.0 > 202 < / RTI > In one embodiment, each of the input devices includes an LED 209 for providing feedback to the end user.

Additionally, the illustrated embodiment includes a battery 208 for powering the low power microcontroller. In one embodiment, a non-rechargeable coin cell battery is used. However, in an alternative embodiment, an integrated rechargeable battery may be used (e.g., rechargeable by connecting the IoT device to an AC power supply (not shown)).

A speaker 205 for generating audio is also provided. In one embodiment, the low power microcontroller 299 includes audio for decoding a compressed audio stream (e.g., an MPEG-4 / Advanced Audio Coding (AAC) stream) Decoding logic. Alternatively, the low power microcontroller 200 and / or the application code / data 203 may comprise a digital sampled piece of audio to provide language feedback to the end user as the user enters a selection through the input device 210 a snippet may be included.

In one embodiment, one or more other / alternative I / O devices or sensors 250 may be included on the IoT device 101 based on the particular application for which the IoT device 101 is designed for. For example, an environmental sensor may be included to measure temperature, pressure, humidity, and the like. A security sensor and / or a door lock opener may be included when the IoT device is used as a secure device. Of course, these examples are provided for illustrative purposes only. The underlying principles of the present invention are not limited to any particular type of IoT device. In fact, in view of the highly programmable nature of the low power microcontroller 200 with the library code 202 installed, the application developer can use the new application code 203 to interface with a low power microcontroller for virtually any type of IoT application ) And a new I / O device 250 can be easily developed.

In one embodiment, the low power microcontroller 200 also includes a security key store for storing encryption keys for encrypting communications and / or generating signatures. Alternatively, the key may be secured in the subscriber identity module (SIM).

In one embodiment, a wake-up receiver 207 is included to wake up the IoT device from an ultra-low power state where the IoT device is not actually consuming any power. In one embodiment, the wake-up receiver 207 responds to the wake-up signal received from the wake-up transmitter 307 configured on the IoT hub 110, as shown in Fig. 3, And is configured to exit the low power state. In particular, in one embodiment, the transmitter 307 and the receiver 207 together form an electrically resonant transformer circuit such as a Tesla coil. In operation, energy is transmitted from the transmitter 307 to the receiver 207 via a radio frequency signal when the hub 110 needs to wake the IoT device 101 from a very low power state. Because of the energy transfer, the IoT device 101 can be configured to not actually consume any power when it is in its low power state, since (such as in a network protocol that allows the device to be awake through a network signal) Because it does not have to "hear" the signal from the hub. Rather, the microcontroller 200 of the IoT device 101 may be configured to wake up after virtually power-off by using energy electrically transmitted from the transmitter 307 to the receiver 207. [

3, the IoT hub 110 also includes a memory 317 for storing the program code and data 305, and hardware logic 301 (such as a microcontroller for executing the program code and processing data) ). A wide area network (WAN) interface 302 and an antenna 310 couple the IoT hub 110 to the cellular service 115. Alternatively, as noted above, IoT hub 110 may also include a local network interface (not shown), such as a WiFi interface (and a WiFi antenna) or an Ethernet interface, for establishing a local area network communication channel . In one embodiment, hardware logic 301 also includes a secure key store for storing encryption keys for encrypting communications and generating / verifying signatures. Alternatively, the key may be secured in the subscriber identity module (SIM).

The local communication interface 303 and the antenna 311 establish a local communication channel with each of the IoT devices 101 to 105. As mentioned above, in one embodiment, the local communication interface 303 / antenna 311 implements the Bluetooth LE standard. However, the basic principles of the present invention are not limited to any particular protocol for establishing a local communication channel with IoT devices 101-105. 3, the WAN interface 302 and / or the local communication interface 303 may be embedded within the same chip as the hardware logic 301. [

In one embodiment, the program code and data includes a communication protocol stack 308 that may include a separate stack for communicating via the local communication interface 303 and the WAN interface 302. [ Additionally, the device pairing program code and data 306 may be stored in memory to allow the IoT hub to pair with the new IoT device. In one embodiment, each new IoT device 101-105 is assigned a unique code communicated to the IoT hub 110 during the pairing process. For example, the unique code may be embedded in a bar code on the IoT device, read by the bar code reader 106, or communicated over the local communication channel 130. [ In an alternative embodiment, the unique ID code is magnetically embedded on the IoT device, and the IoT hub includes a radio frequency ID (" ID ") for detecting the code when the IoT device 101 is moved within a few inches from the IoT hub 110 RFID) or a near field communication (NFC) sensor.

In one embodiment, once the unique ID is communicated, the IoT hub 110 queries the local database (not shown) and / or performs a hash to verify that the code is acceptable and / The unique ID can be verified by communicating with the IoT service 120, the user device 135 and / or the website 130 to verify the code. Once identified, in one embodiment, IoT hub 110 pairs the IoT device 101 and stores the pairing data in memory 317 (which may include non-volatile memory, as noted) . Once the pairing is complete, the IoT hub 110 may contact the IoT device 101 to perform the various IoT functions described herein.

In one embodiment, the organization that drives the IoT service 120 may provide an IoT hub 110 and a basic hardware / software platform to allow the developer to easily design a new IoT service. In particular, in addition to the IoT hub 110, a developer may be provided with a software development kit (SDK) for updating the program code and data 305 executed in the hub 110. Additionally, for the IoT device 101, the SDK may be configured to support the base IoT hardware (e. G., The low power microcontroller 200 shown in FIG. 2 and another Component) designed for a particular application. In one embodiment, the SDK includes a graphical design interface in which the developer only needs to specify input and output to the IoT device. All of the networking code, including the communication stack 201, which allows the IoT device 101 to connect to the hub 110 and the service 120 is already in place for the developer. Additionally, in one embodiment, the SDK also includes a library code base for facilitating the design of the app for mobile devices (e.g., iPhone and Android devices).

In one embodiment, the IoT hub 110 manages a continuous bi-directional stream of data between the IoT devices 101-105 and the IoT service 120. [ In situations where updates to / from the IoT devices 101-105 are required in real time (e.g., where the user needs to view the current state of the secure device or environment measurements), the IoT hub sends periodic updates to the user device 135 < / RTI > and / or to external web sites 130. < RTI ID = 0.0 > The particular networking protocol used to provide the update may be fine-tuned based on the needs of the underlying application. For example, in some cases where it may not be feasible to have a continuous bidirectional stream, a simple request / response protocol can be used to gather information when needed.

In one embodiment, both the IoT hub 110 and the IoT devices 101-105 are automatically upgradeable over the network. In particular, if a new update is available to the IoT hub 110, it can automatically download and install updates from the IoT service 120. It can first copy the updated code to local memory, run it, and verify the update before replacing the old program code. Similarly, if an update is available for each of the IoT devices 101-105, the update may be initially downloaded by the IoT hub 110 and pushed out to each of the IoT devices 101-105. Each IoT device 101-105 may then apply the update in a manner similar to that described above for the IoT hub and report the result of the update back to the IoT hub 110. [ If the update is successful, the IoT hub 110 deletes the updates from its memory (e.g., so that it can keep checking for new updates for each IoT device) and updates the latest You can record the version.

In one embodiment, IoT hub 110 is powered through A / C power. In particular, IoT hub 110 may include a power unit 390 having a transformer for transforming the A / C voltage supplied via the A / C power cord to a lower DC voltage.

4A illustrates an embodiment of the present invention for performing a universal remote control operation using an IoT system. In particular, in this embodiment, the set of IoT devices 101-103 includes a variety of different types of electronic equipment (including but not limited to air conditioning / heater 430, lighting system 431 and audiovisual equipment 432) Infrared (IR) and / or radio frequency (RF) blasters 401 to 403 for transmitting a remote control code to control the radio frequency (RF) In the embodiment shown in Fig. 4A, IoT devices 101-103 are also each equipped with sensors 404-406 for detecting the operation of the devices they control as described below.

For example, the sensor 404 in the IoT device 101 senses the current temperature / humidity and, in response thereto, a temperature and / or humidity sensor for controlling the air conditioner / heater 430 based on the current desired temperature Lt; / RTI > In this embodiment, the air conditioner / heater 430 is designed to be controlled via a remote control device (typically a remote control, which itself incorporates a temperature sensor). In one embodiment, the user provides the desired temperature to the IoT hub 110 via an app or browser installed on the user device 135. [ The control logic 412 running on the IoT hub 110 receives the current temperature / humidity data from the sensor 404 and responds to it to control the IR / RF blaster 401 in accordance with the desired temperature / (101). For example, if the temperature is below a desired temperature, the control logic 412 sends a command to the air conditioner / heater via the IR / RF blaster 401 (e.g., by turning off the air conditioner or turning on the heater) The temperature can be increased. The command may include the necessary remote control code stored in the database 413 on the IoT hub 110. Alternatively or additionally, IoT service 421 may implement control logic 421 for controlling electronic equipment 430 to 432 based on a designated user preference and stored control code 422.

The illustrated example IoT device 102 is used to control the illumination 431. In particular, the sensor 405 in the IoT device 102 may be an optical sensor or photodetector configured to detect the current brightness of the light generated by the lighting fixture 431 (or other lighting device). The user may specify the desired illumination level (including an indication of on or off) to the IoT hub 110 via the user device 135. [ In response, the control logic 412 will send a command to the IR / RF blaster 402 to control the current brightness level of the illuminant 431 (e.g., if the current brightness is too low, If the current brightness is too high, lower the light; or simply turn the illuminant on or off).

The illustrated example IoT device 103 is configured to control the audiovisual equipment 432 (e.g., a television, an A / V receiver, a cable / satellite receiver, an Apple TV ™, etc.). The sensor 406 in the IoT device 103 may be configured to detect a current ambient volume level based on an audio sensor (e.g., a microphone and associated logic) and / or light generated by a television (e.g., (E.g., by measuring light in the spectrum) to detect whether the television is on or off. Alternatively, the sensor 406 may include a temperature sensor connected to the audiovisual equipment to detect whether the audio equipment is on or off based on the detected temperature. Once again, in response to user input via the user device 135, the control logic 412 may send commands to the audiovisual equipment through the IR blaster 403 of the IoT device 103.

It should be noted that the foregoing is merely illustrative of one embodiment of the present invention. The basic principles of the present invention are not limited to any particular type of sensor or device to be controlled by the IoT device.

In embodiments in which the IoT devices 101-103 are coupled to the IoT hub 110 via a Bluetooth LE connection, the sensor data and commands are transmitted over the Bluetooth LE channel. However, the underlying principles of the present invention are not limited to Bluetooth LE or any other communication standard.

In one embodiment, the control codes necessary to control each electronic device are stored in the database 413 on the IoT hub 110 and / or the database 422 on the IoT service 120. As illustrated in FIG. 4B, control codes may be provided to the IoT hub 110 from the master database of control codes 422 for the different devices that are maintained on the IoT service 120. The end user may specify the type of electronic (or other) equipment to be controlled via an app or browser running on the user device 135, and in response, the remote control code learning module 491 on the IoT hub receives the IoT service 120 (E.g., identifying each electronic device with a unique ID) in a remote control code database 492 on the remote control code database 492. [

In addition, in one embodiment, the IoT hub 110 is also provided with a remote control code learning module 491, which allows the IR control module 491 to "learn" a new remote control code directly from the original remote control 495, / RF interface 490 is mounted. For example, if the control code for the original remote control provided with the air conditioner 430 is not included in the remote control database, then the user interacts with the IoT hub 110 via the app / browser on the user device 135 (For example, temperature increase, temperature decrease, etc.) generated by the original remote control to the IoT hub 110. [0054] Once the remote control codes are learned, they can be stored in the control code database 413 on the IoT hub 110 and / or sent back to the IoT service 120 and included in the central remote control code database 492 And is used by other users having the same air conditioning unit 430).

In one embodiment, each of the IoT devices 101-103 has an extremely small form factor and is mounted on or near their respective electronic equipment 430-432 using double-sided tape, small nails, . For control of equipment, such as the air conditioner 430, it may be desirable to place the IoT device 101 far enough away so that the sensor 404 can accurately measure the ambient temperature in the house (e.g., Placing the IoT device will result in a temperature reading that is either too low when the air conditioner is active or too high when the heater is operating). In contrast, the IoT device 102 used to control the illumination can be placed on or near the lighting fixture 431 for the sensor 405 to detect the current illumination level.

In addition to providing general control functions as described, one embodiment of IoT hub 110 and / or IoT service 120 sends a notification to the end user associated with the current status of each electronic device. A notification, which may be a text message and / or an application-specific notification, may then be displayed on the display of the user's mobile device 135. For example, if the user's air conditioner is on for a long period of time but the temperature has not changed, the IoT hub 110 and / or IoT service 120 may send a notification to the user that the air conditioner is not functioning properly. If the sensor 406 indicates that the audiovisual equipment 430 is on, or if the sensor 405 detects that the audiovisual equipment 430 is on, or if the user is not at home (which may be detected via a motion sensor or based on the user's current detected location) A notification may be sent to the user asking if the user wishes to turn off the audiovisual equipment 432 and / or the illuminant 431. The same type of notification can be sent for any type of equipment.

When the user receives the notification, he / she can remotely control the electronic equipment 430 to 432 via an app or browser on the user device 135. In one embodiment, the user device 135 is a touch screen device and the app or browser displays an image of the remote control with buttons that the user can select to control the equipment 430-432. Upon receiving the notification, the user can open the graphic remote control and turn off or adjust a variety of different equipment. When connected through the IoT service 120, the user's choice may be transferred from the IoT service 120 to the IoT hub 110, which in turn controls the equipment through the control logic 412 will be. Alternatively, the user input may be transmitted directly from the user device 135 to the IoT hub 110.

In one embodiment, the user may program the control logic 412 on the IoT hub 110 to perform various automatic control functions on the electronic equipment 430-432. In addition to maintaining the desired temperature, brightness level, and volume level as described above, the control logic 412 may automatically turn off the electronic equipment once a predetermined condition is detected. For example, if the control logic 412 detects that the user is not at home and the air conditioner is not functioning, it may automatically turn off the air conditioner. Similarly, if the user is not at home and the sensor 406 indicates that the audiovisual equipment 430 is on, or if the sensor 405 indicates that the illuminant is on, the control logic 412 controls the IR / RF blasters 403, 402 to turn off the audiovisual equipment and the illuminant, respectively.

5 illustrates a further embodiment of an IoT device 104, 105 on which sensors 503, 504 for monitoring electronic equipment 530, 531 are mounted. In particular, the IoT device 104 of this embodiment includes a temperature sensor 503 that may be disposed on or near the stove 530 to detect when the stove remains on. In one embodiment, the IoT device 104 transmits the current temperature measured by the temperature sensor 503 to the IoT hub 110 and / or the IoT service 120. If the stove is detected to be on beyond a critical period (e.g., based on the measured temperature), the control logic 512 informs the user that the stove 530 is on, ). Further, in one embodiment, the IoT device 104 may be controlled in response to receiving an instruction from a user or automatically (if the control logic 512 is programmed to do so by the user) Module 501 as shown in FIG. In one embodiment, the control logic 501 includes a switch for shutting off electricity or gas to the stove 530. However, in other embodiments, the control logic 501 may be integrated within the stove itself.

Figure 5 also illustrates an IoT device 105 having a motion sensor 504 for detecting motion of certain types of electronic equipment, such as a washer and / or dryer. Other sensors that may be used are audio sensors (e. G., Microphone and logic) for detecting ambient volume levels. As with the other embodiments described above, this embodiment provides a notification to the end user when certain specified conditions are met (e.g., motion is detected for a long period of time and the washer / dryer is not turned off) Lt; / RTI > Although not shown in FIG. 5, the IoT device 105 is also provided with a control module that turns off the washer / dryer 531 automatically and / or in response to user input (e.g., by switching off the electricity / gas) Lt; / RTI >

In one embodiment, the first IoT device with the control logic and the switch can be configured to turn off all power in the user's home, and the second IoT device with the control logic and the switch will turn on all the gas in the user's home Off. The IoT device with the sensor can then be placed on or near the electronic or gas driven equipment in the user's home. When the user is notified that a particular piece of equipment (e.g., stove 530) is left on, the user may send a command to turn off all the electricity or gas in the house to prevent damage. Alternatively, control logic 512 within IoT hub 110 and / or IoT service 120 may be configured to automatically turn off electricity or gas in such situations.

In one embodiment, IoT hub 110 and IoT service 120 communicate at periodic intervals. If the IoT service 120 detects that a connection to the IoT hub 110 has been lost (e.g., by not receiving a request or response from the IoT hub for a specified duration), then (e.g., (By sending an app-specific notification) to the end-user's device 135.

Apparatus and method for accurately detecting user location in IoT systems

Current wireless "smart" locks and garage door openers enable an end user to control a lock and / or a garage door via a mobile device. To operate these systems, the user must open the app on the mobile device and select the open / unlock or closure / lock option. In response, the radio signal is transmitted to a receiver that is on, or coupled to, a radio lock or a garage door that implements the desired operation. Although the discussion below focuses on wireless "locks ", the term" lock " is used herein to refer to standard door locks, wireless garage door openers, and any other device for restricting access to a building or other location Widely used.

Some wireless locks determine when the user is outside the door and attempt to trigger the open / unlock function in response. 6 illustrates an example in which a wireless lock 602 is triggered in response to a user with wireless device 603 accessing from door 601 based on the signal strength of the signal from wireless device 603 For example. For example, the radio lock 602 may measure the received signal strength indicator (RSSI) from the wireless device 603 and may unlock the door 601 when it reaches a threshold (e.g., -60 dbm) will be.

One obvious problem with these techniques is that the RSSI measurement is non-oriented. For example, a user may move around the house with the wireless device 603 and pass by the radio lock 602 or the garage door opener to cause it to be triggered. For this reason, the use of wireless locks operating based on user proximity detection has been limited.

Figure 7 illustrates one embodiment of the present invention in which the IoT hub and / or IoT device 710 is used to determine the user's position with greater precision. In particular, this embodiment of the invention measures the signal strength between the wireless device 703 and the IoT lock device 702 and also measures the signal strength between the wireless device 703 and the at least one IoT device / hub 710 Thereby distinguishing the case where the user is outside the home and the case inside the home. For example, if the user is within a certain distance from the IoT lock 702 in or out of the house, the signal strength 761 from the location in the house and the signal strength 760 outside the house can be approximately the same. In conventional systems such as the one illustrated in FIG. 6, there was no way to distinguish between these two cases. However, in the embodiment shown in FIG. 7, signal strength measurements 750, 751 (i. E., Measured between the IoT hub / device 710 and the wireless device 703, respectively, ) Are used to determine the location of the user. For example, when the wireless device 703 is in an external position, the signal strength 750 may be noticeably different from the signal strength 751 when the wireless device 703 is in the internal position. In most cases, the signal strength (751) in the house should be stronger, but there may be cases where the signal strength (751) is actually weaker. The important point is that signal strength can be used to distinguish between two positions.

The signal strength values 760, 761, 750, 751 may be evaluated at IoT hub / device 710 or at IoT lock 702 (if it has intelligence to perform such an evaluation). The remainder of this discussion is based on the assumption that a signal strength assessment is performed by the IoT hub 710 and then the IoT hub 710 sends a lock or unlock command 710 via the wireless communication channel 770 (e.g., BTLE) To the IoT lock 702 (or may not transmit a command if it is already locked / unlocked). However, if the IoT lock 702 is configured to have logic to perform the evaluation (e.g., signal strength values are provided in the IoT lock 702), the same basic evaluation and results may be obtained by the IoT lock 702 It should be noted that it can be performed directly.

8 illustrates another embodiment that can provide greater precision because it utilizes the signal strength values from the two IoT hubs / devices 710, 711. In this embodiment, the signal strength 805 includes (1) the wireless device 703 and (1) the IoT hub / device 711; (2) IoT hub / device 710; And (3) the IoT lock 702. The wireless device is shown in a single location for simplicity in FIG.

In one embodiment, all of the collected signal strength values are provided to one of the IoT hub devices 710, 711, which then evaluates the values to determine the user's location (e.g., inside or outside). If it is determined that the user is external, the IoT hub / device 710 may send the command to the IoT lock 702 to unlock the door. Alternatively, if the IoT lock 702 has logic to perform the evaluation, the IoT hubs / devices 710, 711 may transmit signal strength values to the IoT lock 702, And determines the location of the user.

9, calibration module 910 on IoT hub 710 communicates with an app or browser based code on wireless device 703 to calibrate the signal strength measurements, in one embodiment. During calibration, the system calibration module 910 and / or the calibration app may provide the user with a predetermined location outside the door and at a predetermined location in the door (e.g., within 6 feet of the door 1, within 6 feet of the door 1, Feet, etc.). The user may indicate that he / she is in the desired location by selecting a graphic on the user interface. The system calibration app and / or system calibration module 910 will then associate the collected signal strength values 900 with respective locations in the location database 901 on the IoT hub / device 710.

Once the signal strength values for the user's different known locations are collected and stored in the database 901, the signal strength analysis module 911 uses these values to lock / unlock the door based on the detected signal strength values To transmit IoT lock commands 950 for locking. In the embodiment shown in FIG. 9, four exemplary locations for two different doors: door 1 exterior, interior door 1, exterior door 2 and interior door 2 are shown. The RSSI1 value is associated with the radio lock and is set to a threshold of -60 dbm. Thus, in one embodiment, the signal strength analysis module 911 will not perform its evaluation to determine the location of the user unless the RSSI1 value is at least -60 dbm. The RSSI2 and RSSI3 values are the signal strength values measured between the user's wireless device and two different IoT hubs / devices.

Assuming the RSSI1 threshold is reached, the signal strength analysis module 911 compares the current signal strength values 900 measured between the IoT hubs / devices and the user's wireless device to the RSSI2 / Compare with RSSI3 values. If the current RSSI values are within a specified range of values specified in the database for RSSI2 (e.g., for IoT hub / device 710) and RSSI3 (e.g., for IoT hub / device 711) , The wireless device is determined to be at or near its associated location. For example, if the currently measured signal strength for RSSI2 is -93 dbm to -87 dbm, since the RSSI2 value associated with the "door 1 exterior" position (e.g., based on measurements made during calibration) is -90 dbm , The RSSI2 comparison can be verified (assuming a specified range of ± 3 dbm). Similarly, since the RSSI3 value associated with the "door 1 external" position is -85 dbm (e.g., based on measurements made during calibration), the currently measured signal strength for RSSI3 is between -88 dbm and -82 dbm The RSSI3 comparison can be verified. Thus, if the user is within the -60 dbm value for IoT lock and within the ranges specified above for RSSI2 and RSSI3, the signal strength analysis module 911 will send a command 950 to open the lock. By comparing the different RSSI values in this way, the system avoids undesirable "unlock" events when the user passes within -60 dbm of the IoT lock from the home, since RSSI measurements for RSSI2 and RSSI3 are internal and Because it is used to distinguish external cases.

In one embodiment, the signal strength analysis module 911 relies on RSSI values that provide the greatest amount of distinction between internal cases and external cases. For example, there may be some instances where RSSI values for internal and external cases are equal or very similar (e.g., RSSI3 values of -96 dBm and -97 dbm for door 2 and door 2 respectively, respectively) have. In such cases, the signal strength analysis module will use two different RSSI values to distinguish between the two cases. In addition, in one embodiment, the signal strength analysis module 911 can dynamically adjust the RSSI ranges used for comparison when the recorded RSSI values are similar (e.g., when the measured RSSI values are more similar Lt; / RTI > Thus, although ± 3 dbm is used as a comparison range for the above example, a variety of different ranges can be set for comparison based on how similar the RSSI measurements are.

In one embodiment, the system calibration module 910 system continues to train the system by measuring dbm values each time the user enters through the door. For example, in response to a user successfully entering the home after an initial calibration, the system calibration module 910 may store additional RSSI values for RSSI2 and RSSI3. In this manner, various RSSI values may be stored in the location / signal strength database 901 for each case to further distinguish between internal and external cases. The end result is a much more precise wireless lock system than is currently available.

A method according to one embodiment of the present invention is illustrated in FIG. The methodology may be implemented within the context of the system architecture described above, but is not limited to any particular system architecture.

At 1001, the radio signal strength between the user device and the IoT lock is measured. At 1002, the radio signal strength between the user device and the at least one IoT hub / device is measured at 1002 if the signal strength exceeds a specified threshold (i.e., the user is near the door). At 1003, the collected radio signal strength values are compared to previously collected and stored signal strength values to determine the location of the user. For example, if the RSSI values are within a specified range of RSSI values when the user was previously outside the door, the user can be determined to be outside the current door. At 1004, a determination is made based on the assessment whether the user is outside the door. If so, at 1005, the door is automatically unlocked using the IoT lock.

A method for calibrating the IoT lock system is illustrated in FIG. At 1101, the user is requested to stand outside the door, and at 1102, wireless signal strength data is collected between the user device and one or more IoT devices / hubs. As noted, a request may be sent to the user via a user app installed on the user's wireless device. At 1103, the user is requested to stand in the door and, at 1104, wireless signal strength data is collected between the user device and the IoT devices / hubs. At 1105, the signal strength data is stored in the database, and thus it can be used to compare the signal strength values as described herein to determine the user's current location.

Note that although the user's home is used herein as an exemplary embodiment, the embodiments of the present invention are not limited to consumer applications. For example, these same techniques can be used to provide access to businesses or other types of buildings.

In one embodiment, techniques similar to those described above are used to track the user across the user's home. For example, by tracking RSSI measurements between the user's wireless device and various IoT devices / hubs in the user's home, a "map " of different user locations can be aggregated. This map can then be used to provide services to the end user such as directing the audio to the speakers in the room where the user is currently located.

Figure 12 shows that the measured RSSI values between the wireless device 703 and the plurality of IoT devices 1101-1105 and IoT hub 1110 determine whether the user is in room A, room B, Lt; RTI ID = 0.0 > system. ≪ / RTI > In particular, based on measured RSSI values 1121-1123 between the wireless device 703 and the IoT hub 1110, the IoT device 1103 and the IoT device 1102, the IoT hub 1110, as illustrated, It can be determined that the user is currently in room B. Similarly, when the user moves into room C, RSSI measurements between wireless device 703 and IoT devices 1104, 1105 and IoT hub 1110 may then be used to determine that the user is in room C . Although only three RSSI measurements 1121-1123 are shown in FIG. 12, RSSI measurements may be made between any IoT devices or IoT hubs within range of wireless device 703 to provide greater precision.

In one embodiment, IoT hub 1110 can triangulate a user's location using triangulation techniques based on RSSI values between itself and various IoT devices 1101-1105 and wireless device 703 have. For example, using RSSI triangles formed between IoT device 1102, IoT hub 1110, and wireless device 703, the current location of wireless device 703 based on RSSI values for each side of the triangle Can be determined.

In one embodiment, calibration techniques similar to those described above may be used to collect signal strength values within each room. 13 illustrates a system calibration module 910 that communicates with an app or browser based code on wireless device 703 to calibrate signal strength measurements, as in the embodiments described above. During calibration, system calibration module 910 and / or calibration apps may instruct the user to stand in different rooms and at certain locations in each room, depending on the applications in which the IoT system is being used. As described above, the user can indicate that he / she is in the required position by selecting a graphic on the user interface. The system calibration app and / or system calibration module 910 will then associate the collected signal strength values 900 with each location in the location database 1301 on the IoT hub / device 710.

Once the signal strength values for the user's different known locations are collected and stored in the database 1301, the signal strength analysis module 911 uses these values to determine the various IoT devices 1101-1105 around the user's home, . For example, if the IoT devices 1101-1105 comprise speakers or amplifiers for a home audio system, then the signal strength analysis module 911 may determine that the IoT device commands (e.g., 1302) (e.g., the speakers in the room where the user is present are turned on and the speakers in the other rooms are turned off). Similarly, if the IoT devices 1101 through 1105 include lighting control units, the signal strength analysis module 911 may determine that the IoT device command < RTI ID = 0.0 > 1302 < / RTI > Of course, the underlying principles of the present invention are not limited to any particular end-user application.

As noted, one embodiment of the system calibration module 910 will collect RSSI data for different points in the room based on the application. In FIG. 13, RSSI ranges for each room are collected by instructing the user to stand at different locations in the room. For example, in the case of a user's living room, RSSI ranges of -99 dbm to -93 dbm, -111 dbm to -90 dbm, and -115 dbm to -85 dbm are collected for RSSI1, RSSI2 and RSSI3, respectively (I.e., collected from three different IoT devices / hubs). When the current location of the wireless device 703 belongs to each of these ranges, the signal strength analysis module 911 determines that the user is in the living room and potentially sends IoT device commands 1302 to determine (E.g., turn on the light emitters, turn on the audio, etc.). In addition, for certain points in the room, certain RSSI values may be collected. For example, in Figure 13, values of -88 dbm, -99 dbm, and -101 dbm were collected when the user sat on the sofa in the living room. As in the previous embodiments, the signal strength analysis module 911 determines that the user is above the couch when the RSSI values are within a specified range of stored RSSI values (e.g., within +/- 3 dbm) . In addition, as in the previous embodiments, the system calibration module 910 may continue to collect data for the different positions to ensure that the RSSI values are kept current. For example, if the user rearranges the living room, the position of the couch may be changed. In this case, the system calibration module 910 asks the user if the user is currently sitting in the couch (for example, given the similarity of the RSSI values from those stored in the database), and sends the signal strength database 1301 to the new values Can be updated.

In one embodiment, the user's interaction with various types of IoT devices can be used to determine the location of the user. For example, if your refrigerator has an IoT device, the system can take RSSI measurements when it detects that the user has opened the refrigerator door. Similarly, when the lighting system includes an IoT system, the system can automatically take RSSI measurements when the user adjusts the illuminants in different rooms of the house or business. As another example, when a user interacts with a variety of devices (e.g., a washer, dryer, dish dryer), audiovisual equipment (e.g., television, audio equipment, etc.) or HVAC systems (e.g., thermostat control) 0.0 > RSSI < / RTI > measurements and associate measurements with these locations.

Although a single user is described in the foregoing embodiments, embodiments of the present invention may be implemented for multiple users. For example, the system calibration module 910 may collect signal strength values for both user A and user B to be stored in the signal strength database 1301. The signal strength analysis module 911 then identifies the current location of user A and user B based on comparisons of the signal strength measurements and transmits IoT commands 1302 to determine the IoT device < RTI ID = 0.0 > (E.g., keeping the illuminants / speakers in the rooms where user A and user B are present in the on state).

The wireless device 703 used in the embodiments of the present invention described herein may be a smartphone, tablet, wearable device (e.g., token on a smart watch, necklace or bracelet), or any Lt; RTI ID = 0.0 > 703 < / RTI > In one embodiment, the wireless device 703 communicates with the IoT devices 1101-1105 and the IoT hub 1110 via a short-range, low-power wireless communication protocol such as Bluetooth LE (BTLE). In addition, in one embodiment, the wireless device 703 communicates with the IoT hub 1110 over a long distance wireless protocol, such as Wifi. Thus, in this embodiment, the RSSI values may be collected by the wireless device 703 and communicated back to the IoT hub 1110 using a long distance protocol. In addition, each of the individual IoT devices 1101-1105 may collect RSSI values and communicate these values back to the IoT hub 1110 via a short-range wireless protocol. The underlying principles of the present invention are not limited to any particular protocol or technique used to collect RSSI values.

One embodiment of the present invention utilizes the techniques described herein to locate an ideal location for the wireless extender to extend the range of the IoT hub 1110 using short-range wireless protocols. For example, in one embodiment, when purchasing a new expander, the system calibration module 910 may determine that the user has a wireless expander device (e.g., by sending an indication to an application on the wireless device 703) And send an instruction to move the user into each of the rooms. A connection wizard may also be executed on the wireless device 703 to allow the user to pass the process. After the instruction is sent by the system calibration module 910 or from the wizard, the user will walk into each room and press a button on the wireless device 703. [ The IoT hub 1110 will then measure the signal strength between itself and the expander, and also the signal strength between the expander and all other IoT devices in the system. The system calibration module 910 or the wireless device wizard may then provide the user with a prioritized list of the best locations to deploy the wireless extender (i.e., between the wireless extender and the IoT hub 1110 and / And those positions with the highest signal strength between IoT devices 1101-1105).

The embodiments of the present invention described above provide fine-tuned position recognition within the IoT system that is not found in current IoT systems. In addition, to improve positional accuracy, in one embodiment, the GPS system on the wireless device 703 may provide GPS data, as well as a precise GPS (not shown), which will be used to provide a precise map of the user's home that will contain the RSSI data for each location Data can be communicated.

Embodiments for improved security

In one embodiment, the low-power microcontroller 200 of each IoT device 101 and the low-power logic / microcontroller 301 of the IoT hub 110 provide a security for storing encryption keys used by the embodiments described below. Key stores (see, e.g., Figures 14-19 and related text). Alternatively, the key may be secured in the subscriber identity module (SIM) as discussed below.

Figure 14 illustrates a high level architecture using a public key infrastructure (PKI) technology and / or a symmetric key exchange / encryption technique to encrypt communications between the IoT service 120, the IoT hub 110 and the IoT devices 101, .

An embodiment using a public / private key pair will be described first, and then an embodiment using a symmetric key exchange / encryption technique will be described. In particular, in an embodiment using a PKI, a unique public / private key pair is associated with each IoT device 101, 102, each IoT hub 110, and IoT service 120. In one embodiment, when the new IoT hub 110 is set up, its public key is provided to the IoT service 120, and when the new IoT device 101 is set up, its public key is sent to the IoT hub 110 ) And the IoT service 120 are both provided. Various techniques for securely exchanging public keys between devices are described below. In one embodiment, all public keys are signed by a master key (i.e., in the form of a certificate) known to all receiving devices so that any receiving device can validate the public key by verifying the signature. Thus, rather than exchanging only the raw public key, these certificates will be exchanged.

As illustrated, in one embodiment, each IoT device 101, 102 includes a secure key store 1401, 1403 for secure storage of the private key of each device. The security logic 1402,1304 then performs the encryption / decryption operations described herein using the securely stored private key. Similarly, the IoT hub 110 may include a secure storage 1411 for storing the public key of the IoT hub private key and the IoT devices 101, 102 and the IoT service 120, as well as the encryption / And the security logic 1412 for performing the < / RTI > Finally, the IoT service 120 uses a secure store 1421 to securely store its own private key, various IoT devices, and the public key of the IoT hub, and uses the key to encrypt / decrypt communications with the IoT hub and device. And may include security logic 1413 for decrypting. In one embodiment, when the IoT hub 110 receives a public key certificate from the IoT device, the IoT hub may verify it (e.g., by verifying the signature using the master key, as described above) And then extract the public key from within it and store the public key in its secure key store 1411.

For example, in one embodiment, the IoT service 120 may communicate commands or data (e.g., a command to open a door, a request to read a sensor, data to be processed / displayed by the IoT device, etc.) 101, the security logic 1413 encrypts the data / command using the public key of the IoT device 101 to generate an encrypted IoT device packet. In one embodiment, the security logic then encrypts the IoT device packet using the public key of the IoT hub 110 to generate an IoT hub packet and sends the IoT hub packet to the IoT hub 110. [ In one embodiment, the service 120 signs the encrypted message with its private key or the master key referred to above, so that the device 101 can verify that it is receiving unchanged messages from the trust source . The device 101 can then verify the signature using the private key and / or the public key corresponding to the master key. As described above, a symmetric key exchange / encryption technique may be used instead of public / private key encryption. In these embodiments, rather than privately storing one key and providing the corresponding public key to the other device, each of the devices may be provided with a copy of the same symmetric key, each of which is used for encryption and used to verify the signature. While an example of a symmetric key algorithm is the Advanced Encryption Standard (AES), the underlying principles of the present invention are not limited to any particular type of symmetric key.

Using a symmetric key implementation, each device 101 enters a secure key exchange protocol to exchange symmetric keys with the IoT hub 110. A secure key provisioning protocol, such as the Dynamic Symmetric Key Provisioning Protocol (DSKPP), can be used to exchange keys over secure communication channels (see, for example, Request for Comments (RFC) 6063). However, the underlying principles of the present invention are not limited to any particular key provisioning protocol.

Once the symmetric key is exchanged, the symmetric key may be used by each device 101 and the IoT hub 110 to encrypt communications. Similarly, IoT hub 110 and IoT service 120 may perform a secure symmetric key exchange and then encrypt the communication using the exchanged symmetric key. In one embodiment, a new symmetric key is periodically exchanged between the device 101 and the hub 110 and between the hub 110 and the IoT service 120. In one embodiment, a new symmetric key is exchanged between each new communication session between the device 101, the hub 110 and the service 120 (e.g., It is safely exchanged). In one embodiment, if the security module 1412 in the IoT hub is trusted, the service 120 may negotiate a session key with the hub security module 1312, and then the security module 1412 may communicate with each device 120 ) And the session key. The message from the service 120 will then be decrypted and verified in the hub security module 1412 before being re-encrypted for transmission to the device 101.

In one embodiment, a one-time (permanent) installation key may be negotiated between the device 101 and the service 120 at installation time to prevent compromise on the hub security module 1412. When sending a message to the device 101, the service 120 may first encrypt / MAC with the device setup key and then encrypt / MAC with the session key of the hub. The hub 110 then verifies and extracts the encrypted device blob and sends it to the device.

In one embodiment of the invention, a counter mechanism is implemented to prevent replay attacks. For example, each successive communication from the device 101 to the hub 110 (or vice versa) may be assigned an ever increasing counter value. Both hub 110 and device 101 will track this value and verify that this value is correct in each successive communication between the devices. The same technology may be implemented between the hub 110 and the service 120. Using a counter in this manner would make it more difficult to spoof communication between each of the devices (because the counter value would be incorrect). Without this, however, a shared installation key between the service and the device will prevent a network (hub) overall attack on all devices.

In one embodiment, when using public / private key encryption, the IoT hub 110 decrypts the IoT Hub packet using its private key, generates an encrypted IoT device packet and sends it to the associated IoT device 101 send. The IoT device 101 then decrypts the IoT device packet using its private key and generates the command / data starting from the IoT service 120. [ The IoT device can then process data and / or execute commands. Using symmetric encryption, each device will encrypt and decrypt using a shared symmetric key. In either case, each transmitting device can also sign the message with its private key, so that the receiving device can verify its authenticity.

A different set of keys may be used to encrypt communication from the IoT device 101 to the IoT hub 110 and to the IoT service 120. For example, using a public / private key arrangement, in one embodiment, the security logic 1402 on the IoT device 101 is transmitted to the IoT hub 110 using the public key of the IoT hub 110 Encrypt the data packet. The security logic 1412 on the IoT hub 110 may then decrypt the data packet using the private key of the IoT hub. Similarly, the security logic 1402 on the IoT device 101 and / or the security logic 1412 on the IoT hub 110 may use the public key of the IoT service 120 to transmit data packets < RTI ID = 0.0 > (The data packet can then be decrypted using the service's private key by the security logic 1413 on the IoT service 120). When using a symmetric key, the device 101 and the hub 110 may share a single symmetric key, while the hub and service 120 may share a different symmetric key.

While certain specific details are set forth in the foregoing description, it is to be understood that the underlying principles of the invention may be implemented using a variety of different encryption techniques. For example, while some embodiments discussed above use asymmetric public / private key pairs, alternative embodiments may be used to securely secure between various IoT devices 101, 102, IoT hub 110 and IoT service 120 A symmetric key to be exchanged can be used. Moreover, in some embodiments, the data / command itself is not encrypted, but the key is used to generate a signature for the data / command (or other data structure). The recipient can then verify the signature using its key.

As illustrated in FIG. 15, in one embodiment, a secure key store on each IoT device 101 is implemented using a programmable subscriber identity module (SIM) 1501. In this embodiment, the IoT device 101 may initially be provided to the end user with an unprogrammed SIM card 1501 that is seated in the SIM interface 1500 on the IoT device 101. The user takes the programmable SIM card 1501 from the SIM interface 500 and inserts it into the SIM programming interface 1502 on the IoT hub 110 to program the SIM to have a set of one or more encryption keys. The programming logic 1525 on the IoT hub then programs the SIM card 1501 securely to register and pair the IoT device 101 to the IoT hub 110 and the IoT service 120. [ In one embodiment, a public / private key pair may be randomly generated by the programming logic 1525, and then the pair's public key may be stored in the secure storage device 411 of the IoT hub, while the private key May be stored in the programmable SIM 1501. In addition, the programming logic 525 may provide the public key of the IoT hub 110, the IoT service 120, and / or any other IoT device 101 (by the security logic 1302 on the IoT device 101) May be stored on the SIM card 1401 to be used for encrypting the SIM card 1401. Once the SIM 1501 is programmed, the new IoT device 101 uses the SIM as a security identifier (e.g., using existing technology to register the device using the SIM) to provision to the IoT service 120 . After provisioning, both the IoT hub 110 and the IoT service 120 will securely store a copy of the public key of the IoT device to be used when encrypting communications with the IoT device 101.

The techniques described above with respect to FIG. 15 provide tremendous flexibility when providing new IoT devices to end users. Rather than requiring the user to register each SIM directly with a particular service provider at the time of sale / purchase (as is currently done), the SIM can be programmed directly by the end user via the IoT hub 110, The results can be communicated securely to the IoT service 120. As a result, the new IoT device 101 can be sold to an end user from an online or local retail store, and can later be safely provisioned to the IoT service 120.

Although registration and encryption techniques are described in the specific context of a SIM (Subscriber Identity Module), the basic principles of the invention are not limited to a "SIM" device. Rather, the underlying principles of the present invention may be implemented using any type of device having a secure repository for storing a set of encryption keys. Also, while the above embodiment includes a mobile SIM device, in one embodiment, the SIM device is not mobile, but the IoT device itself may be inserted into the programming interface 1502 on the IoT hub 110. [

In one embodiment, rather than requiring the user to program the SIM (or other device), the SIM is pre-programmed in the IoT device 101 before being distributed to the end user. In this embodiment, when the user configures the IoT device 101, various techniques described herein may safely exchange the encryption key between the IoT hub 110 / IoT service 120 and the new IoT device 101 Can be used.

For example, as illustrated in FIG. 16A, each IoT device 101 or SIM 401 may include a barcode or QR code 1501 that uniquely identifies the IoT device 101 and / or the SIM 1501, Can be packaged together. In one embodiment, the bar code or QR code 1601 comprises an encoded representation of the public key for the IOT device 101 or the SIM 1001. Alternatively, the barcode or QR code 1601 may be used by the IoT hub 110 and / or the IoT service 120 to identify or generate a public key (e.g., a public key already stored in the secure store) Can be used as a pointer to < / RTI > The barcode or QR code 601 may be printed on a separate card (as shown in Figure 16A) or printed directly on the IOT device itself. Regardless of where the bar code is printed, in one embodiment, the IoT hub 110 reads the bar code and sends the resulting data to the security logic 1012 on the IoT hub 110 and / or the security logic 1012 on the IoT service 120 The barcode reader 206 is provided for providing the barcode reader 1013 with a bar code reader. The security logic 1012 on the IoT hub 110 may then store the public key for the IoT device in its secure key store 1011 and the security logic 1013 on the IoT service 120 May be stored in its secure repository 1021 (to be used for subsequent encrypted communications).

In one embodiment, the data contained in the barcode or QR code 1601 may also include a user device 135 (e.g., an iPhone or Android device) with an IoT app or a browser-based applet designed by the IoT service provider ≪ / RTI > Once captured, the barcode data may be securely communicated to the IoT service 120 over a secure connection (e.g., a secure socket layer (SSL) connection). Barcode data may also be provided from the client device 135 to the IoT hub 110 via a secure local connection (e.g., via a local WiFi or Bluetooth LE connection).

Security logic 1002 on IoT device 101 and security logic 1012 on IoT hub 110 may be implemented using hardware, software, firmware or any combination thereof. For example, in one embodiment, security logic 1002,1012 may be implemented on a chip (e. G., A local channel < / RTI > used to set up local communication channel 130 between IoT device 101 and IoT hub 110) (Bluetooth LE chip when the Bluetooth LE 130 is a Bluetooth LE). Regardless of the particular location of the security logic 1002,1012, in one embodiment, the security logic 1002,1012 is designed to set up a secure execution environment for executing certain types of program code. This may be implemented using, for example, TrustZone technology (available on some ARM processors) and / or Trusted Execution Technology (designed by Intel). Of course, the underlying principles of the invention are not limited to any particular type of security implementation technology.

In one embodiment, a bar code or QR code 1501 may be used to pair each IoT device 101 with the IoT hub 110. [ For example, rather than using the standard wireless pairing process currently used to pair a Bluetooth LE device, the pairing code embedded within the bar code or QR code 1501 is used by the IoT hub to pair the IoT hub with the corresponding IoT device 110).

16B illustrates an embodiment in which the bar code reader 206 on the IOT hub 110 captures the bar code / QR code 1601 associated with the IoT device 101. [ As mentioned, the bar code / QR code 1601 may be printed directly on the IOT device 101, or may be printed on a separate card provided with the IoT device 101. In either case, the bar code reader 206 reads the pairing code from the bar code / QR code 1601 and provides the pairing code to the local communication module 1680. In one embodiment, the local communication module 1680 is a Bluetooth LE chip and associated software, but the underlying principles of the invention are not limited to any particular protocol standard. Once the pairing code is received, it is stored in a secure store containing the pairing data 1685, and the IoT device 101 and the IoT hub 110 are automatically paired. Whenever the IoT hub is paired with a new IoT device in this manner, the pairing data for such pairing is stored in the secure repository 685. In one embodiment, once the local communication module 1680 of the IoT hub 110 receives the pairing code, it may use the code as a key for encrypting communications over the local wireless channel with the IoT device 101. [

Similarly, on the IoT device 101 side, the local communication module 1590 stores the pairing data indicating the pairing with the IoT hub in the local secure storage device 1595. The pairing data 1695 may include a pre-programmed pairing code identified in the bar code / QR code 1601. [ The pairing data 1695 also includes pairing data 1610 that is required to establish a secure local communication channel and that includes the pairing data received from the local communication module 1680 on the IoT hub 110 (e.g., to encrypt communication with the IoT hub 110) Additional keys).

Thus, the bar code / QR code 1601 can be used to perform local pairing in a way that is much more secure than the current wireless pairing protocol because the pairing code is not transmitted wirelessly. In addition, in one embodiment, the same bar code / QR code 1601 used for pairing is used to establish a secure connection from the IoT device 101 to the IoT hub 110 and from the IoT hub 110 to the IoT service 120 Lt; / RTI > may be used to identify the encryption key for the user.

A method of programming a SIM card according to an embodiment of the present invention is illustrated in FIG. The methodology may be implemented within the system architecture described above, but is not limited to any particular system architecture.

At 1701 the user receives a new IoT device with a blank SIM card and at 1602 the user inserts the blank SIM card into the IoT hub. At 1703, the user programs the blank SIM card to have a set of one or more encryption keys. For example, as described above, in one embodiment, the IoT hub may randomly generate a public / private key pair, store the private key on the SIM card and store the public key in its local secure store. Also at 1704, at least the public key is transmitted to the IoT service, which can be used to identify the IoT device and establish encrypted communication with the IoT device. As described above, in one embodiment, a programmable device other than the "SIM" card can be used to perform the same function as the SIM card in the method shown in FIG.

A method of incorporating a new IoT device into a network is illustrated in FIG. The methodology may be implemented within the system architecture described above, but is not limited to any particular system architecture.

At 1801, the user receives a new IoT device pre-assigned with an encryption key. At 1802, the key is securely provided to the IoT hub. As discussed above, in one embodiment, this involves reading the barcode associated with the IoT device to identify the public key of the public / private key pair assigned to the device. Barcodes can be read directly by the IoT hub or captured via an app or browser via a mobile device. In an alternative embodiment, a secure communication channel such as a Bluetooth LE channel, a Near Field Communication (NFC) channel, or a secure WiFi channel may be established between the IoT device and the IoT hub to exchange keys. Regardless of how the key is transmitted, once received, it is stored in the secure key store of the IoT hub device. As described above, various security enforcement techniques, such as Secure Enclave, Trusted Execution Technology (TXT), and / or Trust Zone, may be used on the IoT hub to store and protect keys. Also, at 1803, the key is securely transmitted to the IoT service, which stores the key in its own secure key store. The IoT service can then use the key to encrypt communication with the IoT device. Once again, the exchange may be implemented using a certificate / signed key. Within hub 110, it is particularly important to prevent modification / addition / removal of stored keys.

A method of securely communicating commands / data to an IoT device using a public / private key is illustrated in FIG. The methodology may be implemented within the system architecture described above, but is not limited to any particular system architecture.

At 1901, the IoT service encrypts the data / command using the IoT device public key to generate the IoT device packet. It then encrypts the IoT device packet using the public key of the IoT hub to create an IoT hub packet (e.g., creating an IoT hub wrapper around the IoT device packet). At 1902, the IoT service sends the IoT hub packet to the IoT hub. At 1903, the IoT hub decrypts the IoT hub packet using the private key of the IoT hub to generate the IoT device packet. At 1904, it then sends the IoT device packet to the IoT device, which at 1905 decodes the IoT device packet using the IoT device private key to generate the data / command. At 1906, the IoT device processes data / commands.

In embodiments using a symmetric key, the symmetric key exchange may be negotiated between each of the devices (e.g., between each device and the hub and between the hub and the service). Once the key exchange is complete, each transmitting device encrypts and / or signs each transmission using a symmetric key before transmitting the data to the receiving device.

Embodiments of the present invention may include the various steps described above. Steps may be implemented with machine-executable instructions that may be used to cause a general purpose or special-purpose processor to perform the steps. Alternatively, these steps may be performed by specific hardware components including hardwired logic for performing the steps, or by any combination of programmed computer components and customized hardware components.

As described herein, an instruction may be implemented in hardware such as an application specific integrated circuit (ASIC) having software instructions or predetermined functionality stored in a memory configured to perform a predetermined operation or contained in a non-volatile computer readable medium Can refer to a specific configuration. Thus, the techniques shown in the figures may be implemented using code and data stored on and executed on one or more electronic devices (e.g., end stations, network elements, etc.). Such electronic devices include non-volatile computer-readable storage media (e.g., magnetic disks, optical disks, random access memories, read only memories, flash memory devices, phase change memories) For example, a computer-readable medium, such as an electrical, optical, acoustical or other form of propagated signal (e.g., carrier wave, infrared signal, digital signal, etc.) To other electronic devices). Additionally, such electronic devices typically include one or more storage devices (non-volatile machine readable storage media), user input / output devices (e.g., keyboard, touch screen, and / or display) And a set of one or more processors coupled to one or more other components. The combination of a set of processors and other components typically takes place via one or more buses and bridges (also referred to as bus controllers). The storage device and the signal carrying the network traffic each represent one or more machine-readable storage media and machine-readable communication media. Thus, a storage device of a given electronic device typically stores code and / or data for execution on a set of one or more processors of the electronic device. Of course, one or more portions of an embodiment of the invention may be implemented using different combinations of software, firmware, and / or hardware.

Throughout this Detailed Description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without some of these specific details. In some instances, well-known structures and functions have not been described in detail in order to avoid obscuring the subject matter of the present invention. Accordingly, the scope and spirit of the present invention should be determined in light of the following claims.

Claims (52)

As a system,
A system calibration module for collecting signal strength data indicative of the signal strength between a wireless device and a plurality of object Internet (IoT) devices and / or IoT hubs in a user's home or business, said system calibration module comprising: With locations within the user's home or business and storing the association in a location database; And
Comparing the signal strength data in the location database with current signal strength data representative of a current signal strength between the wireless device and one or more of the plurality of IoT devices and / or IoT hubs to determine a current location of the wireless device Signal strength analysis module for determining
. ≪ / RTI > The method according to claim 1,
Wherein the calibrating app communicates with the system calibrating module when collecting the signal strength data and the calibrating app communicates to the user a different room in the user's home or business And / or to different locations within each room, and to provide an indication when the user reaches each of the different rooms and / or different locations within each room. 3. The system of claim 2, wherein the calibrating app transmits current signal strength data between the wireless device and each of the plurality of IoT devices and / or IoT hubs when providing the indication. The method according to claim 1,
Wherein the system calibration module and the signal strength analysis module are implemented. 2. The system of claim 1, wherein the location database comprises a plurality of signal strength values associated with respective locations and respective locations. 6. The system of claim 5, wherein the plurality of signal strength values comprises received signal strength indicator (RSSI) values measured between the wireless device and the plurality of IoT devices and / or IoT hubs at each location. . 7. The system of claim 6, wherein the signal strength analysis module receives a current set of signal strength values and compares these values with the signal strength data in the location database to determine the current location of the wireless device. 8. The system of claim 7, wherein the signal strength analysis module determines that the wireless device is in a particular location if the current signal strength values are within a specified range of the signal strength values specified in the location database. 9. The system of claim 8, wherein the signal strength analysis module transmits one or more IoT device commands to control IoT devices in response to the determination that the wireless device is in a particular location. 10. The system of claim 9, wherein, when determining that the wireless device is within a particular room, the signal strength analysis module turns on the audio speakers in the room and / or turns on the illuminants in the room in response thereto. 11. The system of claim 10, wherein, when determining that the wireless device is within a particular room, the signal strength analysis module responsively turns off audio speakers in the other room and / or turns off the illuminants in the other room. 2. The system of claim 1, wherein the signal strength analysis module performs triangulation techniques to determine a current location of the wireless device. 13. The system of claim 12, wherein the triangulation techniques comprise measuring the signal strength values between the wireless device and the IoT hub, between the wireless device and the IoT device, and between the IoT device and the IoT hub. . 2. The system of claim 1, wherein the signal strength measurements are collected by the wireless device and transmitted to the IoT hub. 15. The method of claim 14 wherein the signal strength values are collected for wireless communication channels using a short range wireless communication standard and the signal strength values are transmitted from the wireless device to the IoT hub using a different wireless communication standard. system. 16. The system of claim 15, wherein the short range wireless communication standard comprises Bluetooth low energy (BTLE) and the different wireless communication standard comprises a Wifi standard. As a method,
Collecting signal strength data indicative of signal strength between a wireless device and a plurality of IoT devices and / or IoT hubs in a user's home or business;
Associating the signal strength data with locations within the user's home or business and storing the association in a location database; And
Comparing the signal strength data in the database with current signal strength data representative of a current signal strength between the wireless device and the plurality of IoT devices and / or IoT hubs to determine a current location of the wireless device within the home or business ≪ / RTI >
/ RTI > 18. The method of claim 17, wherein collecting signal strength data further comprises communicating with a calibration app on the wireless device to the IoT hub, wherein the calibration app sends the user a different room in the user's home or business And / or moving to different locations within each room, and directing the user to provide an indication when arriving at each of the different rooms and / or different locations within each room. 19. The method of claim 18, wherein the calibrating app transmits current signal strength data between the wireless device and each of the plurality of IoT devices and / or IoT hubs when providing the indication. 18. The method of claim 17, wherein the location database comprises a plurality of signal strength values associated with respective locations and respective locations. 21. The method of claim 20, wherein the plurality of signal strength values comprises received signal strength indicator (RSSI) values measured between the wireless device and the plurality of IoT devices and / or IoT hubs at each location . 22. The method of claim 21, wherein determining the current position further comprises receiving a current set of signal strength values and comparing the values to the signal strength data in the location database to determine the current location of the wireless device / RTI > 24. The method of claim 22, wherein determining the current location further comprises determining that the wireless device is in a particular location if the current signal strength values are within a specified range of the signal strength values specified in the location database How to. 24. The method of claim 23, further comprising transmitting one or more IoT device commands to control IoT devices in response to the determination that the wireless device is in a particular location. 26. The method of claim 24, wherein when the wireless device is determined to be in a particular room, in response to turning on audio speakers in the room and / or turning on the illuminants in the room. 26. The method of claim 25, responsive to determining that the wireless device is within a particular room, turning off audio speakers in the other room and / or turning off the illuminants in the other room. A wireless lock system,
An IoT lock configured to unlock the door in response to a wireless signal;
Collects signal strength data between the wireless device and the IoT lock and signal strength data indicative of the signal strength between the wireless device and one or more Internet (IoT) devices and / or IoT hubs when the user is known to be outside the door A system calibration module for associating the signal strength data with a user location outside the door in a location database; And
Comparing the signal strength data in the location database with current signal strength data representing signal strength between the wireless device and the IoT lock and the one or more of the plurality of IoT devices and / or IoT hubs, A signal strength analysis module for determining whether the door is outside the door
/ RTI >
Wherein the IoT lock is unlocked in response to a determination that the user is located outside the door. 28. The method of claim 27,
Wherein the calibration app communicates with the system calibration module when collecting the signal strength data and the calibration app communicates to the user when collecting the signal strength data, Instructs the user to move to a location outside the door, and further instructs the user to provide an indication when the user is outside the door. 29. The system of claim 28, wherein the system calibration module is further configured to determine a signal strength between the wireless device and the IoT lock when the user is known to be in the door and to determine the signal strength between the wireless device and one or more object Internet (IoT) devices and / Further collecting signal strength data indicative of signal strength between the hubs, the system calibration module relating the signal strength data to a user location in the door in the location database. 29. The system of claim 28, wherein the calibrating app transmits current signal strength data between the wireless device and the IoT lock and each of the plurality of IoT devices and / or IoT hubs when providing the indication. 28. The method of claim 27,
Wherein the system calibration module and the signal strength analysis module are implemented. 30. The system of claim 29, wherein the location database comprises a plurality of signal strength values associated with respective locations and identities of respective locations within and outside the door. 33. The apparatus of claim 32, wherein the plurality of signal strength values comprises a received signal strength indicator measured between the wireless device and the IoT lock at each location and between the wireless device and the at least one IoT devices and / (RSSI) values. 34. The system of claim 33, wherein the signal strength analysis module receives a current set of signal strength values and compares these values with the signal strength data in the location database to determine whether the user is in or out of the door. . 35. The system of claim 34, wherein the signal strength analysis module is further configured to determine that the current signal strength values are outside the door if the user is within a specified range of the signal strength values designated in the location database for being outside the door . 36. The system of claim 35, wherein the signal strength analysis module sends an unlock command to cause the IoT lock to unlock the door in response to the determination that the wireless device is outside the door. 37. The system of claim 36, wherein the signal strength analysis module performs triangulation techniques to determine whether the wireless device is in the door or outside the door. 39. The method of claim 37, wherein the triangulation techniques are adapted to measure signal strength values between the wireless device and the IoT lock, the wireless device and the IoT device or hub, and the signal strength between the IoT device or hub and the IoT lock ≪ / RTI > 28. The system of claim 27, wherein the signal strength measurement is collected by the wireless device and transmitted to the IoT hub. 40. The method of claim 39 wherein the signal strength values are collected for wireless communication channels using a short range wireless communication standard and the signal strength values are transmitted from the wireless device to the IoT hub using a different wireless communication standard. system. 41. The system of claim 40, wherein the short range wireless communication standard comprises Bluetooth low energy (BTLE), and the different wireless communication standard comprises a Wifi standard. A method for implementing a wireless IoT lock,
Collecting signal strength data between the wireless device and the IoT lock and signal strength data indicative of the signal strength between the wireless device and one or more Internet (IoT) devices and / or IoT hubs when the user is known to be outside the door step;
Associating the signal strength data with a user location outside the door in a location database; And
Comparing the signal strength data in the location database with current signal strength data representing signal strength between the wireless device and the IoT lock and the one or more of the plurality of IoT devices and / or IoT hubs, Determining whether the door is outside the door
/ RTI >
Wherein the IoT lock is unlocked in response to a determination that the user is located outside the door. 43. The method of claim 42, wherein collecting the signal strength data comprises:
Further comprising the step of establishing communication with a calibration application installed on the wireless device, the calibration application instructing the user to move to a location outside the door when collecting the signal strength data, Further indicating to provide an indication when outside the door. 44. The method of claim 43, wherein collecting the signal strength data
Signal intensity data indicating signal strength between the wireless device and the IoT lock when the user is known to be in the door and signal strength between the wireless device and one or more Internet (IoT) devices and / or IoT hubs Wherein the associating further comprises associating the signal strength data with a user location in the door in the location database. 45. The method of claim 44, wherein the calibrating app transmits current signal strength data between the wireless device and the IoT lock and each of the plurality of IoT devices and / or IoT hubs when providing the indication. 43. The method of claim 42, wherein the location database comprises a plurality of signal strength values associated with respective locations and identities of respective locations within and outside the door. 47. The method of claim 46, wherein the plurality of signal strength values are associated with the wireless device and the IoT lock at each location, and a received signal strength indicator measured between the wireless device and the at least one IoT devices and / 0.0 > (RSSI) < / RTI > values. 48. The method of claim 47, wherein determining comprises:
Receiving a set of current signal strength values and comparing the values with the signal strength data in the location database to determine if the user is in or out of the door. 49. The method of claim 48,
Further comprising determining that the wireless device is outside the door if the current signal strength values are within a specified range of the signal strength values designated in the location database for the user being outside the door. 50. The method of claim 49,
Further comprising transmitting an unlock command to cause the IoT lock to unlock the door in response to the determination that the wireless device is outside the door. 51. The method of claim 50,
Performing triangulation techniques to determine whether the wireless device is in the door or outside the door. 52. The method of claim 51, wherein the triangulation techniques are adapted to measure signal strength values between the wireless device and the IoT lock, the wireless device and the IoT device or hub, and the signal strength between the IoT device or hub and the IoT lock ≪ / RTI >

Images