System and Method for Identifying and Initializing IoT Devices Using Bluetooth Advertising Channels

Abstract

A system and method for identifying an IoT device model from a key broadcast in an advertising channel are described. For example, one embodiment of the system includes a target IoT device for transmitting a key via a Bluetooth (BT) advertising channel, the key being associated with the model of the target Internet of Things (IoT) device, a mobile application program code that, when installed on a mobile device, causes the mobile device to listen to the BT advertising channel to extract the key, and a key dictionary installed on the mobile device, the key dictionary mapping each of a plurality of keys to an IoT device model and associated data, the mobile application program code performing a lookup using the key extracted from the BT advertising channel to identify the target IoT device model and / or associated data and using the target IoT device model and / or associated data for onboarding the target IoT device, the key dictionary.

Description

Technical Field

[0001] The present invention generally relates to the field of computer systems. More particularly, the present invention relates to a machine learning-based IoT device provisioning system and method.

Background Art

[0002] The "Internet of Things" refers to the interconnection of devices uniquely and identifiable incorporated within the Internet infrastructure. Ultimately, the IoT is expected to bring about a wide range of new types of applications where virtually any type of physical object can provide information about itself or its surroundings and / or be remotely controlled via a client device across the Internet.

[0003] A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings.

Brief Description of the Drawings

[0004]

Figure 1A

Figure 1B

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9A

Figure 9B

Figure 10

Figure 11

Figure 12A

Figure 12B

Figure 13

Figure 14

Figure 15

Figure 16A

Figure 16B

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23A

Figure 23B

Figure 23C

Figure 24

Figure 25

Figure 26A

Figure 26B

Figure 26C

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36A

Figure 36B

Figure 37A

Figure 37B

Figure 38A

Figure 38B

Figure 39

Figure 40

Figure 41

Figure 42

Figure 43

Figure 44

[0005] 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 present invention described below. However, it will be apparent to one of ordinary skill 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 fundamental principles of the embodiments of the present invention.

[0006] One embodiment of the present invention includes an Internet of Things (IoT) platform that can be utilized by developers to design and build new IoT devices and applications. Specifically, one embodiment includes an IoT device that includes a given networking protocol stack, and a basic hardware / software platform for an IoT hub to which the IoT device is connected to the Internet. Additionally, one embodiment includes IoT services through which the IoT hub and connected IoT devices can be accessed and managed as described below. Additionally, one embodiment of the IoT platform includes an IoT application or web application (e.g., executed on a client device) that accesses and configures the IoT services, hub, and connected devices. Existing online retailers and other website operators can utilize the IoT platform described herein to easily provide unique IoT capabilities to their existing user bases.

[0007] FIG. 1A illustrates an overview of an architecture platform on which embodiments of the present invention can be implemented. Specifically, the illustrated embodiment includes a plurality of IoT devices 101-105 communicably coupled via a local communication channel 130 to a central IoT hub 110 communicably coupled to an IoT service 120 via the Internet 220 itself. Each of the IoT devices 101-105 can be initially paired with the IoT hub 110 (e.g., using pairing techniques described below) to enable each of the local communication channels 130. In one embodiment, the IoT service 120 includes an end-user database 122 for maintaining user account information and data collected from the IoT devices of each user. For example, if the IoT device includes a sensor (e.g., a temperature sensor, an accelerometer, a thermal sensor, a motion detector, etc.), the database 122 can be continuously updated to store the data collected by the IoT devices 101-105. The data stored in the database 122 can then be made accessible to an end-user via an IoT application or browser installed on the user device 135 (or via a desktop or other client computer system) and to a web client (e.g., a website 130 subscribed to the IoT service 120, etc.).

[0008] The IoT devices 101-105 may be equipped with various types of sensors for collecting information about themselves and their surroundings and providing the collected information to the IoT service 120, the user device 135, and / or the external website 130 via the IoT hub 110. Some of the IoT devices 101-105 can execute a specified function in response to a control command transmitted via the IoT hub 110. Various specific examples of information collected by the IoT devices 101-105 and control commands are provided below. In one embodiment described below, the IoT device 101 is a user input device designed to record user selections and transmit the user selections to the IoT service 120 and / or the website.

[0009] In one embodiment, the IoT hub 110 includes 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 in addition, the IoT hub 110 can include Wi-Fi radio for establishing a Wi-Fi connection via a Wi-Fi access point or router 116, which connects the IoT hub 110 to the Internet (e.g., via an Internet service provider that provides Internet services to end users). Of course, it should be noted that the basic principles of the present invention are not limited to a specific type of communication channel or protocol.

[0010] In one embodiment, the IoT devices 101-105 are ultra-low power devices that can operate on battery power for an extended period (e.g., several years). To conserve power, the local communication channel 130 can be implemented using a low power wireless communication technology such as Bluetooth Low Energy (LE). In this embodiment, each of the IoT devices 101-105 and the IoT hub 110 is equipped with a Bluetooth LE radio and protocol stack.

[0011] As described above, in one embodiment, the IoT platform includes an IoT application or web application that runs on a user device 135 and enables a user to access and configure the connected IoT devices 101-105, IoT hub 110, and / or IoT service 120. In one embodiment, the application or web application may be designed by the operator of the website 130 to provide IoT capabilities to its user base. As illustrated, the website can maintain a user database 131 that includes account records associated with each user.

[0012] Figure 1B illustrates additional connection options for multiple IoT hubs 110-111, 190. In this embodiment, a single user can have multiple hubs 110-111 installed on-site within a single user premise 180 (e.g., a user's home or business). This can be done, for example, to extend the wireless range necessary to connect all of the IoT devices 101-105. As described above, if a user has multiple hubs 110, 111, they may be connected via a local communication channel (e.g., Wifi, Ethernet, powerline networking, etc.). In one embodiment, each of the hubs 110-111 can establish a direct connection to the IoT service 120 via a cellular 115 or WiFi 116 connection (not explicitly shown in Figure 1B). Alternatively, or in addition, one of the IoT hubs, such as IoT hub 110, can function as a "master" hub, which provides connectivity and / or local services to all other IoT hubs on the user premise 180, such as IoT hub 111 (as shown by the dashed line connecting IoT hub 110 and IoT hub 111). For example, the master IoT hub 110 may be the only IoT hub that establishes a direct connection to the IoT service 120. In one embodiment, only the "master" IoT hub 110 is equipped with a cellular communication interface for establishing a connection to the IoT service 120. Thus, all communication between the IoT service 120 and the other IoT hubs 111 flows through the master IoT hub 110. In this role, the master IoT hub 110 can be provided with additional program code for performing a filtering operation on the data exchanged between the other IoT hubs 111 and the IoT service 120 (e.g., locally servicing some data requests, if possible).

[0013] Regardless of how the IoT hubs 110 - 111 are connected, in one embodiment, the IoT service 120 logically associates the hubs with the user and couples all of the attached IoT devices 101 - 105 under a single comprehensive user interface that is accessible via a user device having the installed application 135 (and / or a browser - based interface).

[0014] In this embodiment, the master IoT hub 110 and one or more slave IoT hubs 111 may be connected via a local network that can be a WiFi network 116, an Ethernet network, and / or power - line communications (PLC) networking (e.g., all or part of the network is run over the user's power lines). Additionally, for each of the IoT devices 101 - 105 with respect to the IoT hubs 110 - 111, any type of local network channel such as WiFi, Ethernet, PLC, or Bluetooth LE may be used to interconnect with the IoT hubs 110 - 111.

[0015] FIG. 1B also shows an IoT hub 190 installed in a second user premise 181. A virtually unlimited number of such IoT hubs 190 can be installed and configured to collect data from IoT devices 191 - 192 in user premises around the world. In one embodiment, the two user premises 180 - 181 may be configured for the same user. For example, one user premise 180 may be the user's primary home and the other user premise 181 may be the user's vacation home. In such a case, the IoT service 120 logically associates the IoT hubs 110 - 111, 190 with the user and couples all of the attached IoT devices 101 - 105, 191 - 192 under a single comprehensive user interface and makes them accessible via a user device having the installed application 135 (and / or a browser - based interface).

[0016] As illustrated in FIG. 2, an exemplary embodiment of the IoT device 101 includes a memory 210 that stores program code and data 201-203, and a low-power microcontroller 200 that executes the program code and processes the data. The memory 210 may be a volatile memory such as a dynamic random access memory (DRAM), or a non-volatile memory such as a flash memory. In one embodiment, the non-volatile memory can be used for permanent storage, and the volatile memory can be used for execution of the program code and data. Further, the memory 210 may be integrated within the low-power microcontroller 200, or may be coupled to the low-power microcontroller 200 via a bus or communication fabric. The fundamental principles of the present invention are not limited to any particular implementation of the memory 210.

[0017] As illustrated, the program code can include application program code 203 that defines a set of application-specific functions to be executed by the IoT device 201 and library code 202, including a set of predefined building blocks that can be utilized by application developers of the IoT device 101. In one embodiment, the library code 202 includes a set of basic functions required to implement an IoT device, such as a communication protocol stack 201 to enable communication between each IoT device 101 and the IoT hub 110. As described above, 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 within the low-power microcontroller 200. However, the fundamental principles of the present invention are not limited to any particular communication protocol.

[0018] The specific embodiment shown in FIG. 2 also includes a plurality of input devices or sensors 210 that receive user input and provide the user input to a low-power microcontroller, and the low-power microcontroller processes the user input according to application code 203 and library code 202. In one embodiment, each of the input devices includes an LED 209 that provides feedback to the end user.

[0019] In addition, the illustrated embodiment includes a battery 208 for powering the low-power microcontroller. In one embodiment, a non-rechargeable coin-type battery is used. However, in another embodiment, an integrated rechargeable battery can be used (e.g., rechargeable by connecting the IoT device to an AC power source (not shown)).

[0020] A speaker 205 for generating audio is also provided. In one embodiment, the low-power microcontroller 299 includes audio decoding logic for decoding a compressed audio stream (e.g., an MPEG-4 / Advanced Audio Coding (AAC) stream) for generating audio on the speaker 205. Alternatively, the low-power microcontroller 200 and / or the application code / data 203 can include digitally sampled audio snippets for providing verbal feedback to the end user when the user enters a selection via the input device 210.

[0021] In one embodiment, based on the specific use for which the IoT device 101 is designed, one or more other / alternative I / O devices or sensors 250 may be included in the IoT device 101. For example, environmental sensors can be included to measure temperature, pressure, humidity, etc. When the IoT device is used as a security device, security sensors and / or door lock openers may be included. Of course, these examples are provided for illustrative purposes only. The basic principles of the present invention are not limited to any particular type of IoT device. In fact, considering the highly programmable nature of the low-power microcontroller 200 with library code 202, application developers can easily develop new application code 203 and new I / O devices 250 to interface with the low-power microcontroller for substantially any type of IoT application.

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

[0023] In one embodiment, a wake-up receiver 207 is included to wake up the IoT device from an ultra-low power state in which it is substantially consuming no power. In one embodiment, the wake-up receiver 207 is configured to cause the IoT device 101 to exit this low power state in response to a wake-up signal received from a wake-up transmitter 307 configured on the IoT hub 110, as shown in FIG. 3. Specifically, in one embodiment, both the transmitter 307 and the receiver 207 form an electrical resonance transformer circuit such as a Tesla coil. During operation, when the hub 110 needs to resume the IoT device 101 from a very low power state, energy is transmitted via a radio frequency signal from the transmitter 307 to the receiver 207. For reasons of energy transfer, the IoT device 101 can be configured to substantially consume no power because it does not need to continuously "listen" for signals from the hub while it is in the low power state (similar to the case of network protocols where a device can be woken up via a network signal). Rather, the microcontroller 200 of the IoT device 101 can be configured to wake up after being effectively powered down by using the energy electrically transmitted from the transmitter 307 to the receiver 207.

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

[0025] A local communication interface 303 and an antenna 311 establish a local communication channel with each of the IoT devices 101-105. As described above, in one embodiment, the local communication interface 303 / antenna 311 implements the Bluetooth LE standard. However, the underlying principles of the present invention are not limited to any particular protocol for establishing a local communication channel with the IoT devices 101-105. Although shown as separate units in FIG. 3, the WAN interface 302 and / or the local communication interface 303 may be incorporated within the same chip as the hardware logic 301.

[0026] In one embodiment, the program code and data can include a communication protocol stack 308 that includes separate stacks for communicating via the local communication interface 303 and the WAN interface 302. Additionally, the device pairing program code and data 306 can be stored in memory so that the IoT hub can pair with a new IoT device. In one embodiment, each new IoT device 101-105 is assigned a unique code that is communicated to the IoT hub 110 during the pairing process. For example, the unique code may be incorporated into a barcode on the IoT device and read by a barcode reader 106, or communicated via the local communication channel 130. In another embodiment, a unique ID code is magnetically incorporated into the IoT device, and the IoT hub has a magnetic sensor such as a radio frequency ID (RFID) or near field communication (NFC) sensor to detect the code when the IoT device 101 moves within a few inches of the IoT hub 110.

[0027] In one embodiment, when a unique ID is communicated, the IoT hub 110 can verify the unique ID and confirm the validity of the ID code by querying a local database (not shown), performing a hash to verify that the code is acceptable, and / or communicating with the IoT service 120, the user device 135, and / or the website 130. Once the validity is confirmed, in one embodiment, the IoT hub 110 pairs the IoT device 101 and stores the pairing data in the memory 317, which can include non-volatile memory as described above. Once the pairing is complete, the IoT hub 110 can connect to the IoT device 101 to perform the various IoT functions described herein.

[0028] In one embodiment, an organization that executes IoT service 120 can provide an IoT hub 110 and a basic hardware / software platform so that developers can easily design new IoT services. Specifically, in addition to the IoT hub 110, a software development kit (SDK) for updating the program code and data 305 executed within the hub 110 may be provided to the developers. In addition, for the IoT device 101, the SDK may include a set of extensive library codes 202 designed for the base IoT hardware (e.g., low-power microcontroller 200 and other components shown in FIG. 2) to facilitate the design of various different types of applications 101. In one embodiment, the SDK includes a graphical design interface that allows developers to simply specify the inputs and outputs of the IoT device. All the networking codes including the communication stack 201 that enables the IoT device 101 to connect to the hub 110 and the service 120 are already arranged for the developers. In addition, in one embodiment, the SDK also includes a library code base that facilitates the design of applications for mobile devices (e.g., iPhone (registered trademark) and Android (registered trademark) devices).

[0029] 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., situations where a user needs to view the current state of a security device or environmental measurements), the IoT hub can maintain an open TCP socket to provide periodic updates to the user device 135 and / or an external website 130. The specific networking protocol used to provide the updates may be adjusted based on the needs of the basic usage. For example, if it may not be reasonable to have a continuous bi-directional stream, a simple request / response protocol can be used to collect information when needed.

[0030] In one embodiment, both the IoT hub 110 and the IoT devices 101-105 are automatically updatable via a network. Specifically, when a new update is available for the IoT hub 110, the update can be automatically downloaded and installed from the IoT service 120. It can copy the updated code to the local memory and execute it to verify the update before replacing the old program code. Similarly, when an update is available for each of the IoT devices 101-105, the update may first be downloaded by the IoT hub 110 and pushed out to each of the IoT devices 101-105. Each of the IoT devices 101-105 can apply the update in a manner similar to that described above for the IoT hub and report the result of the update to the IoT hub 110. If the update is successful, the IoT hub 110 can delete the update from its memory and record the latest version of the code installed on each IoT device (e.g., so that it can continue to check for new updates for each IoT device).

[0031] In one embodiment, the IoT hub 110 is powered via A / C power. Specifically, the IoT hub 110 can include a power supply unit 390 having a transformer for converting the A / C voltage supplied via an A / C power cord to a lower DC voltage.

[0032] Figure 4A illustrates an embodiment of the present invention for performing universal remote control operations using an IoT system. Specifically, in this embodiment, the set of IoT devices 101-103 are each provided with infrared (IR) and / or radio frequency (RF) blasters 401-403 for transmitting remote control codes for controlling various different types of electronic devices, including (by way of example only) air conditioner / heater 430, lighting system 431, and audiovisual equipment 432. In the embodiment shown in Figure 4A, the IoT devices 101-103 are also each provided with sensors 404-406 for detecting the operation of the devices they control, as described below.

[0033] For example, the sensor 404 in the IoT device 101 may be a temperature and / or humidity sensor that detects the current temperature / humidity and accordingly controls the air conditioner / heater 430 based on the current desired temperature. In this embodiment, the air conditioner / heater 430 is designed to be controlled via a remote control device (typically, a remote control device that itself incorporates a temperature sensor therein). In one embodiment, the user provides the desired temperature to the IoT hub 110 via an application installed on the user device 135 or a browser. The control logic 412 executed on the IoT hub 110 receives the current temperature / humidity data from the sensor 404 and accordingly sends a command to the IoT device 101 to control the IR / RF blaster 401 in accordance with the desired temperature / humidity. For example, if the temperature is below the desired temperature, the control logic 412 may send a command to the air conditioner / heater via the IR / RF blaster 401 to raise the temperature (e.g., either by turning off the air conditioner or turning on the heater). The command may include the necessary remote control code stored in the database 413 on the IoT hub 110. Alternatively, or in addition, the IoT service 421 may implement control logic 421 to control the electronic devices 430-432 based on the specified user preferences and the stored control code 422.

[0034] The IoT device 102 in the illustrated embodiment is used to control lighting 431. Specifically, the sensor 405 of the IoT device 102 may be a light sensor or a photodetector configured to detect the current luminance of the light provided by the lighting fixture 431 (or other lighting devices). The user may specify a desired lighting level (including on or off indication) to the IoT hub 110 via the user device 135. In response, the control logic 412 sends a command to the IR / RF blaster 402 to control the current luminance level of the lighting 431 (e.g., brighten the lighting if the current luminance is too low, or dim the lighting if the current luminance is too high, or simply turn the lighting on or off).

[0035] The IoT device 103 in the illustrated embodiment is configured to control audiovisual devices 432 (e.g., televisions, A / V receivers, cable / satellite receivers, Apple TV (trademark), etc.). The sensor 406 of the IoT device 103 may be an audio sensor (e.g., a microphone and associated logic) for detecting the current ambient volume level, and / or a light sensor for detecting whether the television is on or off based on the light generated by the television (e.g., by measuring the light within a specified spectrum). Alternatively, the sensor 406 may include a temperature sensor connected to the audiovisual device for detecting whether the audio device is on or off based on the detected temperature. Again, in response to user input via the user device 135, the control logic 412 may send a command to the audiovisual device via the IR blaster 403 of the IoT device 103.

[0036] It should be noted that the above are merely exemplary examples of one embodiment of the present invention. The basic principles of the present invention are not limited to any specific type of sensor or device controlled by the IoT device.

[0037] In one embodiment where IoT devices 101 - 103 are coupled to the IoT hub 110 via Bluetooth LE connections, sensor data and commands are transmitted via the Bluetooth LE channel. However, the basic principles of the present invention are not limited to Bluetooth LE or any other communication standard.

[0038] In one embodiment, the control codes required to control each of the electronic devices 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, the control codes may be provided from the master database of the control codes 422 on the IoT service 120 to the IoT hub 110 for different devices maintained on the IoT service 120. The end user may specify the type of electronic (or other) device to be controlled via an application or browser executed on the user device 135, and in response, the remote control code learning module 491 on the IoT hub may obtain the required IR / RF code from the remote control code database 492 on the IoT service 120 (e.g., to identify each electronic device having a unique ID).

[0039] In addition, in one embodiment, the IoT hub 110 is provided with an IR / RF interface 490 that enables a remote control code learning module 491 to "learn" a new remote control code directly from the original remote control device 495 provided with the electronic device. For example, if the control code of the original remote control device provided with the air conditioner 430 is not included in the remote control database, the user may interact with the IoT hub 110 via the application / browser on the user device 135 to teach the IoT hub 110 various control codes generated by the original remote control device (e.g., raising the temperature, lowering the temperature, etc.). Once the remote control codes are learned, they may be stored in the control code database 413 on the IoT hub 110 and / or sent back to the IoT service 120 so as to be included in the central remote control code database 492 (subsequently, it may be used by other users having the same air conditioner unit 430).

[0040] In one embodiment, each of the IoT devices 101-103 has an extremely small form factor and may be attached on or near their corresponding electronic devices 430-432 using double-sided tape, small nails, magnetic attachments, etc. To control one device such as the air conditioner 430, it is desirable to place the IoT device 101 sufficiently far away so that the sensor 404 can accurately measure the ambient temperature inside the home (e.g., if the IoT device is placed directly on the air conditioner, the temperature measurement will be too low when the air conditioner is operating and too high when the heater is operating). In contrast, the IoT device 102 used to control lighting may be placed on or near the lighting fixture 431 so that the sensor 405 can detect the current lighting level.

[0041] In addition to providing the general control functions described, one embodiment of the IoT hub 110 and / or the IoT service 120 sends notifications related to the current state of each electronic device to the end user. The notifications may be text messages and / or application-specific notifications, and then the notifications may be displayed on the display of the user's mobile device 135. For example, if the user's air conditioner has been on for a long time but the temperature has not changed, the IoT hub 110 and / or the IoT service 120 may send a notification to the user that the air conditioner is not functioning properly. If the user is not at home (which may be detected via motion sensors or based on the user's currently detected location), and the sensor 406 indicates that the audiovisual device 430 is on, or the sensor 405 indicates that the lighting is on, a notification may be sent to the user asking if the user wishes to turn off the audiovisual device 432 and / or the lighting 431. The same type of notification may be sent for any type of device.

[0042] When the user receives the notification, he / she may remotely control the electronic devices 430-432 via an application or browser on the user device 135. In one embodiment, the user device 135 is a touch screen device, and the application or browser displays an image of a remote control device that includes user-selectable buttons for controlling the devices 430-432. After receiving the notification, the user may open the graphical remote control device and turn off or adjust various different devices. If connected via the IoT service 120, the user's selection may be transferred from the IoT service 120 to the IoT hub 110, and the IoT hub 110 will then control the device via the control logic 412. Alternatively, the user input may be sent directly from the user device 135 to the IoT hub 110.

[0043] 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 devices 430-432. In addition to maintaining the desired temperature, brightness level, and volume level described above, the control logic 412 may automatically turn off the electronic device when a certain 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, the control logic 412 may automatically turn off the air conditioner. Similarly, if the user is not at home and the sensor 406 indicates that the audiovisual device 430 is on, or the sensor 405 indicates that the lighting is on, the control logic 412 may automatically send commands via the IR / RF blasters 403 and 402 to turn off the audiovisual device and the lighting, respectively.

[0044] FIG. 5 illustrates an additional embodiment of the IoT devices 104 and 105 with sensors 503 and 504 for monitoring the electronic devices 530 and 531. Specifically, the IoT device 104 of this embodiment may include a temperature sensor 503 disposed on or near the conro 530 to detect when the conro 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 it is detected that the conro has been on for a threshold period (e.g., based on the measured temperature), the control logic 512 may send a notification to the end-user device 135 notifying the user that the conro 530 is on. In addition, in one embodiment, the IoT device 104 may include a control module 501 for turning off the conro in response to receiving a command from the user or automatically (when programmed by the user such that the control logic 512 does so). In one embodiment, the control logic 501 includes a switch for shutting off the electricity or gas to the conro 530. However, in other embodiments, the control logic 501 may be integrated within the conro itself.

[0045] FIG. 5 also illustrates an IoT device 105 having an operation sensor 504 for detecting the operation of a particular type of electronic device, such as a washing machine and / or a dryer. Another sensor that can be used is an audio sensor (e.g., a microphone and logic) for detecting the ambient volume level. Like the other embodiments described above, this embodiment may send a notification to the end user if a particular specified condition is met (e.g., if an operation is detected for a long period of time, indicating that the washing machine / dryer is not turned off). Although not shown in FIG. 5, the IoT device 105 may also be provided with a control module for turning off the washing machine / dryer 531 automatically and / or in response to user input (e.g., by switching off the electricity / gas).

[0046] In one embodiment, a first IoT device having control logic and a switch may be configured to turn off all the electricity in the user's home, and a second IoT device having control logic and a switch may be configured to turn off all the gas in the user's home. Then, the IoT device having sensors may be positioned on or near the electrical or gas-driven devices in the user's home. If the user is notified that a particular device is still on (e.g., the stove 530), the user may send a command to turn off all the electricity or gas in the home to prevent damage. Alternatively, the control logic 512 of the IoT hub 110 and / or the IoT service 120 may be configured to automatically turn off the electricity or gas in such a situation.

[0047] In one embodiment, the IoT hub 110 and the IoT service 120 communicate at periodic intervals. If the IoT service 120 detects that the connection to the IoT hub 110 is lost (e.g., by not receiving a request or response from the IoT hub for a specified duration), the IoT service 120 will communicate this information to the end user's device 135 (e.g., by sending a text message or an application-specific notification).

[0048] Apparatus and method for communication Data through an intermediate device As described above, since the wireless technologies used to interconnect IoT devices such as Bluetooth LE are generally short-range technologies, if the hub for IoT implementation is outside the range of the IoT devices, the IoT devices cannot send data to the IoT hub (and vice versa).

[0049] To address this drawback, one embodiment of the present invention provides a mechanism for IoT devices that are outside the wireless range of an IoT hub to periodically connect with one or more mobile devices when the mobile devices are within range. Once connected, the IoT device can send any data that needs to be provided to the IoT hub to the mobile device, and then the mobile device transfers the data to the IoT hub.

[0050] As illustrated in FIG. 6, one embodiment includes an IoT hub 110, an IoT device 601 outside the range of the IoT hub 110, and a mobile device 611. The out-of-range IoT device 601 may include any form of IoT device capable of collecting and communicating data. For example, the IoT device 601 may include a data collection device configured within a refrigerator to monitor available food items, users consuming the food items, and the current temperature. Of course, the basic principles of the present invention are not limited to any particular type of IoT device. The techniques described herein may be implemented using any type of IoT device, including, by way of example only, devices used to collect and transmit data regarding smart meters, stoves, washing machines, dryers, lighting systems, HVAC systems, and audiovisual equipment.

[0051] Furthermore, the IoT device 611 illustrated in FIG. 6, which is a mobile device in operation, may be any form of mobile device capable of communicating and storing data. For example, in one embodiment, the mobile device 611 is a smartphone on which an application is installed to facilitate the techniques described herein. In another embodiment, the mobile device 611 includes wearable devices such as a communication token attached to a necklace or bracelet, a smartwatch, or a fitness device. The wearable token may be particularly useful for elderly users or other users who do not own a smartphone device.

[0052] During operation, the out-of-range IoT device 601 may periodically or continuously check for connectivity with the mobile device 611. After establishing a connection (e.g., as a result of the user moving near the refrigerator), any collected data 605 on the IoT device 601 is automatically transmitted to a temporary data repository 615 on the mobile device 611. In one embodiment, the IoT device 601 and the mobile device 611 use a low-power wireless standard such as BTLE to establish a local wireless communication channel. In such a case, the mobile device 611 may first be paired with the IoT device 601 using known pairing techniques.

[0053] Once the data is transmitted to the temporary data repository, the mobile device 611 transmits the data when communication with the IoT hub 110 is established (e.g., when the user walks within the range of the IoT hub 110). The IoT hub may then store the data in the central data repository 413 and / or transmit the data over the Internet to one or more services and / or other user devices. In one embodiment, the mobile device 611 may provide the data to the IoT hub 110 using different types of communication channels (potentially, a higher-power communication channel such as WiFi).

[0054] IoT devices 601 outside the scope, mobile devices 611, and IoT hubs may all be configured by program code and / or logic for implementing the technologies described herein. As illustrated in FIG. 7, for example, for the purpose of executing the operations described herein, the IoT device 601 may be configured by intermediate connection logic and / or an application, the mobile device 611 may be configured by intermediate connection logic / application, and the IoT hub 110 may be configured by intermediate connection logic / application 721. The intermediate connection logic / application on each device may be implemented in hardware, software, or any combination thereof. In one embodiment, the intermediate connection logic / application 701 of the IoT device 601 searches for and establishes a connection with the intermediate connection logic / application 711 (which may be implemented as a device application) on the mobile device, and transmits data to the temporary data repository 615. Then, the intermediate connection logic / application 701 on the mobile device 611 transfers the data to the intermediate connection logic / application on the IoT hub that stores the data in the central data repository 413.

[0055] As illustrated in FIG. 7, the intermediate connection logics / applications 701, 711, 721 on each device may be configured based on the local application. For example, with respect to a refrigerator, the connection logic / application 701 may only need to send a small number of packets on a periodic basis. For other applications (e.g., temperature sensors), the connection logic / application 701 may need to send more frequent updates.

[0056] Rather than the mobile device 611, in one embodiment, the IoT device 601 may be configured to establish a wireless connection with one or more intermediate IoT devices located within the range of the IoT hub 110. In this embodiment, any IoT device 601 outside the range of the IoT hub may be linked to the hub by forming a "chain" using other IoT devices.

[0057] In addition, for the sake of brevity, only a single mobile device 611 is illustrated in FIGS. 6-7, but in one embodiment, a plurality of such mobile devices of different users may be configured to communicate with the IoT device 601. Further, the same technology may be implemented for a plurality of other IoT devices, thereby forming an intermediate device data collection system throughout the home.

[0058] Furthermore, in one embodiment, the techniques described herein may be used to collect various different types of related data. For example, in one embodiment, each time the mobile device 611 connects to the IoT device 601, user identification may be included along with the collected data 605. In this way, the IoT system may be used to track the behavior of different users within the home. For example, when used within a refrigerator, the collected data 605 may include identification of each user passing by the refrigerator, each user opening the refrigerator, and the specific food items consumed by each user. Different types of data may be collected from other types of IoT devices. Using this data, the system can, for example, determine which users wash their clothes, which users watch television on a given day, the times at which each user goes to bed and wakes up, and so on. Then, all of this cloud-sourced data may be compiled within the data repository 413 of the IoT hub and / or transferred to an external service or user.

[0059] Another beneficial use of the technology described in this specification is for monitoring elderly users who may require assistance. For this application, the mobile device 611 may be a very small token worn by the elderly user to collect information about different indoor areas of the user's home. Each time the user opens the refrigerator, for example, this data is included with the collected data 605 and transmitted via the token to the IoT hub 110. The IoT hub may then provide the data to one or more external users (e.g., a child or other individual caring for the elderly user). If no data has been collected for a specified period (e.g., 12 hours), this may mean that the elderly user is not moving around the home and / or not opening the refrigerator. The IoT hub 110 or an external service connected to the IoT hub may then send an alert notification to these other individuals, notifying them that they should check on the elderly user. Additionally, the collected data 605 may include other relevant information such as the food consumed by the user, whether it is necessary to go to the grocery store, whether the elderly user is watching TV and how frequently, and how often the elderly user washes their clothes.

[0060] In another implementation, if there is a problem with an electronic device such as a washing machine, refrigerator, HVAC system, etc., the collected data may include instructions for the parts that need to be replaced. In such cases, the notification may be sent to a technician along with a request to resolve the problem. The technician may then arrive at the home with the required replacement parts.

[0061] A method according to an embodiment of the present invention is shown in FIG. 8. The method may be implemented in connection with the above architecture but is not limited to any particular architecture.

[0062] At 801, IoT devices outside the range of the IoT hub periodically collect data (e.g., opening of the refrigerator door, food items used, etc.). At 802, the IoT device periodically or continuously checks for connectivity with a mobile device (e.g., using standard local wireless technologies for establishing a connection, such as those specified by the BTLE standard). At 802, when it is determined that a connection to the mobile device has been established, at 803, the collected data is transmitted to the mobile device at 803. At 804, the mobile device transmits the data to the IoT hub, an external service, and / or the user. As described, the mobile device can transmit data immediately if it is already connected (e.g., via a WiFi link).

[0063] In addition to collecting data from IoT devices, in one embodiment, the techniques described herein may be used to update data or otherwise provide data to IoT devices. An example is shown in FIG. 9A, which depicts an IoT hub 110 having a program code update 901 that needs to be installed on an IoT device 601 (or a group of such IoT devices). The program code update may include system updates, patches, configuration data, and any other data required for the IoT device to operate as desired by the user. In one embodiment, the user may specify configuration options for the IoT device 601 via a mobile device or computer, which are then stored on the IoT hub 110 and provided to the IoT device using the techniques described herein. Specifically, in one embodiment, intermediate connection logic / application 721 on the IoT hub 110 communicates with intermediate connection logic / application 711 on the mobile device 611 to store the program code update in the temporary storage device 615. When the mobile device 611 enters the range of the IoT device 601, the intermediate connection logic / application 711 on the mobile device 611 connects to the intermediate / connection logic / application 701 on the IoT device 601 to provide the device with the program code update. In one embodiment, the IoT device 601 may then enter an automatic update process to install the new program code update and / or data.

[0064] A method for updating an IoT device is shown in FIG. 9B. The method may be implemented in connection with the system architecture described above, but is not limited to any particular system architecture.

[0065] At 900, new program code or data updates become available on the IoT hub and / or an external service (e.g., connected to a mobile device on the Internet). At 901, the mobile device receives and stores the program code or data update instead of the IoT device. The IoT device and / or the mobile device periodically checks at 902 to determine whether a connection is established. If it is determined at 903 that a connection is established, then at 904, the update is transmitted to and installed on the IoT device.

[0066] 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 include a secure key store for storing the cryptographic keys used by the embodiments described below (see, e.g., FIGS. 10 - 15 and the related text). Alternatively, the keys may be secured within a subscriber identity module (SIM) as described later.

[0067] FIG. 10 illustrates a high-level architecture that uses public key infrastructure (PKI) technology and / or symmetric key exchange / encryption technology to encrypt communications between the IoT service 120, the IoT hub 110, and the IoT devices 101 and 102.

[0068] Embodiments using a public / private key pair will be described first, followed by embodiments using symmetric key exchange / encryption techniques. Specifically, in one embodiment using PKI, a unique public / private key pair is associated with each IoT device 101-102, each IoT hub 110, and the IoT service 120. In one embodiment, when a new IoT hub 110 is set up, its public key is provided to the IoT service 120, and when a new IoT device 101 is set up, its public key is provided to both the IoT hub 110 and the IoT service 120. Various techniques for securely exchanging public keys between devices will be described below. In one embodiment, all public keys are signed by a parent key (i.e., a type of certificate) that is known to all receiving devices so that any receiving device can verify the validity of the public key by verifying the validity of the signature. Thus, rather than simply exchanging raw public keys, these certificates will be exchanged instead.

[0069] As illustrated, in one embodiment, each IoT device 101, 102 includes a secure key storage device 1001, 1003, respectively, for security reasons to store the secret key of each device. Then, security logics 1002, 1304 execute the encryption / decryption operations described herein using the securely stored secret keys. Similarly, the IoT hub 110 includes a secure storage device 1011 for storing the IoT hub secret key and the public keys of the IoT devices 101-102 and the IoT service 120, and a security logic 1012 for executing encryption / decryption operations using the keys. Finally, the IoT service 120 may include a secure storage device 1021 for security reasons to store its own secret key and the public keys of various IoT devices and IoT hubs, and a security logic 1013 for encrypting / decrypting communications with the IoT hub and devices using the keys. In one embodiment, when the IoT hub 110 receives a public key certificate from an IoT device, the IoT hub 110 verifies it (e.g., by checking the validity of the signature using the above-mentioned parent key), then extracts the public key therefrom, and can store the public key in its secure key store 1011.

[0070] As an example, in one embodiment, when the IoT service 120 needs to send a command or data (e.g., a command to unlock a door, a request to read a sensor, data to be processed / displayed by the IoT device, etc.) to the IoT device 101, the security logic 1013 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 1013 then uses the public key of the IoT hub 110 to encrypt the IoT device packet 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 using its private key or the above-described parent key so that the device 101 can verify that it has received a message that has not been changed from a trusted source. The device 101 may then confirm the validity of the signature using the public key corresponding to the private key and / or the parent key. As described above, symmetric key exchange / encryption techniques may be used instead of public / private key encryption. In these embodiments, instead of storing one key privately and providing the corresponding public key to other devices, each device may be provided with a copy of the same symmetric key that is used for encryption and for verifying the validity of signatures. An example of a symmetric key algorithm is the Advanced Encryption Standard (AES), but the basic principles of the present invention are not limited to any particular type of symmetric key.

[0071] 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 a secure communication channel (see, e.g., Request for Comments (RFC) 6063). However, the basic principles of the present invention are not limited to any particular key provisioning protocol.

[0072] Once the symmetric keys are exchanged, they can be used by each device 101 and the IoT hub 110 to encrypt communications. Similarly, the IoT hub 110 and the IoT service 120 can perform a secure symmetric key exchange and then use the exchanged symmetric keys to encrypt communications. In one embodiment, new symmetric keys are exchanged periodically 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 for each new communication session between the device 101, the hub 110, and the service 120 (e.g., a new key is generated and securely exchanged for each communication session). In one embodiment, if the security module 1012 within the IoT hub is trusted, the service 120 can negotiate a session key with the hub security module 1312, and then the security module 1012 will negotiate a session key with each device 120. Messages from the service 120 are then decrypted and verified by the hub security module 1012 and then re-encrypted for transmission to the device 101.

[0073] In one embodiment, to prevent security breaches at the hub security module 1012, a one-time (permanent) installation key may be negotiated between the device 101 and the service 120 during installation. When sending a message to the device 101, the service 120 may first encrypt / MAC it using this device installation key and then encrypt / MAC it using the hub session key. The hub 110 will then verify and extract the encrypted device blob and send it to the device.

[0074] In one embodiment of the present invention, a counter mechanism is implemented to prevent replay attacks. For example, a continuously increasing counter value may be assigned to each successive communication from the device 101 to the hub 110 (or vice versa). Both the hub 110 and the device 101 track this value and verify that it is correct in each successive communication between the devices. The same technique may be implemented between the hub 110 and the service 120. Using a counter in this way will make it more difficult to spoof communications between each device (since the counter value will be incorrect). However, even without using this, the installation key shared between the service and the device will prevent network (hub)-scale attacks against all devices.

[0075] In one embodiment, when using public / private key encryption, the IoT hub 110 uses its private key to decrypt the IoT hub packet, generates an encrypted IoT device packet, and sends it to the associated IoT device 101. The IoT device 101 then uses its private key to decrypt the IoT device packet to generate commands / data originating from the IoT service 120. The IoT device 101 may then process the data and / or execute the commands. When using symmetric encryption, each device encrypts and decrypts using the shared symmetric key. In either case, each sending device may also sign the message using its private key so that the receiving device can verify the message's authenticity.

[0076] Different sets of keys may be used to encrypt communications from IoT device 101 to IoT hub 110 and to IoT service 120. For example, using a certain public / private key configuration, in one embodiment, security logic 1002 on IoT device 101 uses the public key of IoT hub 110 to encrypt data packets sent to IoT hub 110. Then, security logic 1012 on IoT hub 110 may decrypt the data packets using the private key of the hub. Similarly, security logic 1002 on IoT device 101 and / or security logic 1012 on IoT hub 110 may encrypt data packets sent to IoT service 120 using the public key of IoT service 120 (which may then be decrypted by security logic 1013 on IoT service 120 using the private key of the service). Using symmetric keys, device 101 and hub 110 may share a certain symmetric key, while the hub and service 120 may share a different symmetric key.

[0077] In the above description, certain specific details are set forth, but it should be noted that the basic principles of the present invention may be implemented using a variety of different encryption techniques. For example, some of the embodiments described above use an asymmetric public / private key pair, while other embodiments may use symmetric keys that are securely exchanged between various IoT devices 101 - 102, IoT hubs 110, and IoT services 120. Further, in some embodiments, the data / command itself is not encrypted, but a key is used to generate a signature on the data / command (or other data structure). Then, the recipient may use the key to verify the validity of the signature.

[0078] As illustrated in FIG. 11, in one embodiment, the secure key storage on each IoT device 101 is implemented using a programmable subscriber identity module (SIM) 1101. In this embodiment, the IoT device 101 may be initially provided to the end user along with an unprogrammed SIM card 1101 installed within a SIM interface 1100 on the IoT device 101. To program the SIM using a set of one or more cryptographic keys, the user removes the programmable SIM card 1101 from the SIM interface 500 and inserts it into a SIM programming interface 1102 on the IoT hub 110. Next, the programming logic 1125 on the IoT hub securely programs the SIM card 1101 to register / pair the IoT device 101 with the IoT hub 110 and the IoT service 120. In one embodiment, the public / private key pair may be randomly generated by the programming logic 1125, and then the public key of this pair may be stored in a secure storage device 411 of the IoT hub, while the private key may be stored in the programmable SIM 1101. Additionally, the programming logic 525 may store the public keys of the IoT hub 110, the IoT service 120, and / or any other IoT device 101 on the SIM card 1401 (for use in encrypting outgoing data by the security logic 1302 on the IoT device 101). Once the SIM 1101 is programmed, the IoT service 120 may be provisioned to the new IoT device 101 using the SIM as a secure identifier (e.g., using existing techniques for registering a device using the SIM). After provisioning, both the IoT hub 110 and the IoT service 120 securely store a copy of the public key of the IoT device for use in encrypting communication with the IoT device 101.

[0079] The technology described above with respect to FIG. 11 provides a great deal of flexibility when providing new IoT devices to end users. Instead of requiring the user to directly register each SIM with a specific service provider at the time of sale / purchase (as is currently done), the SIM may be directly programmed by the end user via the IoT hub 110, and the results of the programming may be securely communicated to the IoT service 120. Therefore, a new IoT device 101 can be sold to an end user from an online or local retailer, and later the IoT service 120 can be securely provisioned.

[0080] Although registration and encryption techniques have been described above in the context of a specific SIM (Subscriber Identity Module), the basic principles of the present invention are not limited to "SIM" devices. Rather, the basic principles of the present invention may be implemented using any type of device having a secure storage device for storing a set of encryption keys. Further, while the above embodiments include removable SIM devices, in one embodiment, the SIM device is not removable, but the IoT device itself may be inserted into the programming interface 1102 of the IoT hub 110.

[0081] In one embodiment, instead of requiring the user to program the SIM (or other device), the SIM is pre-programmed into the IoT device 101 prior to distribution to the end user. In this embodiment, when the user sets up the IoT device 101, the various techniques described herein may be used to securely exchange encryption keys between the IoT hub 110 / IoT service 120 and the new IoT device 101.

[0082] For example, as illustrated in FIG. 12A, each IoT device 101 or SIM 401 may be packaged with a barcode or QR code (registered trademark) 1501 that uniquely identifies the IoT device 101 and / or SIM 1001. In one embodiment, the barcode or QR code (registered trademark) 1201 includes an encoded representation of the public key of the IoT device 101 or SIM 1001. Alternatively, the barcode or QR code (registered trademark) 1201 may be used by the IoT hub 110 and / or IoT service 120 to identify or generate the public key (e.g., used as a pointer to a public key already stored in a secure storage device). The barcode or QR code (registered trademark) 601 may be printed on a separate card (as shown in FIG. 12A) or directly on the IoT device itself. Regardless of where the barcode is printed, in one embodiment, the IoT hub 110 is provided with a barcode reader 206 for reading the barcode and providing the obtained data to the security logic 1012 on the IoT hub 110 and / or the security logic 1013 on the IoT service 120. The security logic 1012 on the IoT hub 110 may then store the public key of the IoT device in its secure key storage device 1011, and the security logic 1013 on the IoT service 120 may store the public key (for use in subsequent encrypted communications) in its secure storage device 1021.

[0083] In one embodiment, the data included within barcode or QR code (registered trademark) 1201 may also be captured by user device 135 (e.g., iPhone (registered trademark) or Android device, etc.) using a browser-based applet designed by an installed IoT application or IoT service provider. Once captured, the barcode data may be securely communicated to IoT service 120 via a secure connection (e.g., secure sockets layer (SSL) connection, etc.). The barcode data may also be provided from client device 135 to IoT hub 110 via a secure local connection (e.g., via local WiFi or Bluetooth LE connection).

[0084] 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 logics 1002, 1012 are implemented within a chip (e.g., a Bluetooth LE chip if local channel 130 is Bluetooth LE) used to establish local communication channel 130 between IoT device 101 and IoT hub 110. Regardless of the specific location of security logics 1002, 1012, in one embodiment, security logics 1002, 1012 are designed to establish a secure execution environment for executing a certain type of program code. This may be implemented, for example, by using TrustZone technology (available in some ARM processors) and / or trusted execution technology (designed by Intel). Of course, the basic principles of the present invention are not limited to any specific type of secure execution technology.

[0085] In one embodiment, the barcode or QR code (registered trademark) 1501 can be used to pair each IoT device 101 with the IoT hub 110. For example, instead of using the standard wireless pairing process currently used to pair Bluetooth LE devices, a pairing code incorporated within the barcode or QR code (registered trademark) 1501 can be provided to the IoT hub 110 to pair the IoT hub with the corresponding IoT device.

[0086] FIG. 12B illustrates one embodiment in which the barcode reader 206 on the IoT hub 110 captures the barcode / QR code (registered trademark) 1201 associated with the IoT device 101. As described above, the barcode / QR code (registered trademark) 1201 may be printed directly on the IoT device 101 or on a separate card provided with the IoT device 101. In either case, the barcode reader 206 reads the pairing code from the barcode / QR code (registered trademark) 1201 and provides this pairing code to the local communication module 1280. In one embodiment, the local communication module 1280 is a Bluetooth LE chip and associated software, but the basic principles of the present invention are not limited to any particular protocol standard. When the pairing code is received, it is stored in a secure storage device containing pairing data 1285, and the IoT device 101 and the IoT hub 110 are automatically paired. Each time an IoT hub is paired with a new IoT device in this way, the pairing data regarding that pairing is stored in the secure storage device 685. In one embodiment, when the local communication module 1280 of the IoT hub 110 receives the pairing code, it can use this code as a key to encrypt communication with the IoT device 101 over the local wireless channel.

[0087] Similarly, on the IoT device 101 side, the local communication module 1590 stores pairing data indicating pairing with the IoT hub in the local secure storage device 1595. The pairing data 1295 may include a pre-programmed pairing code identified by the barcode / QR code (registered trademark) 1201. The pairing data 1295 may also include pairing data received from the local communication module 1280 on the IoT hub 110 (e.g., an additional key for encrypting communication with the IoT hub 110) required to establish a secure local communication channel.

[0088] Therefore, the barcode / QR code (registered trademark) 1201 can be used to perform local pairing in a much more secure way than current wireless pairing protocols because the pairing code is not transmitted wirelessly. Additionally, in one embodiment, the same barcode / QR code (registered trademark) 1201 used for pairing can be used to identify an encryption key and 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.

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

[0090] At 1301, the user receives a new IoT device with an empty SIM card, and at 1602, the user inserts the empty SIM card into the IoT hub. At 1303, the user programs the empty SIM card using one or more sets of cryptographic 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 within its local secure storage. Additionally, at 1304, at least the public key is sent to the IoT service so that it 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 a "SIM" card may be used to perform the same functions as the SIM card in the manner shown in FIG. 13.

[0091] A method for integrating a new IoT device into a network is illustrated in FIG. 14. This method may be implemented within the system architecture described above, but is not limited to any particular system architecture.

[0092] At 1401, the user receives a new IoT device with a pre - assigned cryptographic key. At 1402, this key is securely provided to the IoT hub. As described above, in one embodiment, this involves reading a barcode associated with the IoT device to identify the public key of the public / private key pair assigned to the device. The barcode may be read directly by the IoT hub or captured by a mobile device via an application or browser. In another 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 for key exchange. Regardless of the method of key transmission, once received, the key is stored within the secure key store of the IoT hub device. As described above, various secure execution technologies such as secure enclaves, Trusted Execution Technology (TXT), and / or Trustzone may be used in the IoT hub for key storage and protection. Additionally, at 803, the key is securely sent to the IoT service, and the IoT service stores this key within its own secure key store. The IoT service may then use this key to encrypt communication with the IoT device. Again, this exchange may be performed using a certificate / signed key. Within the hub 110, it is particularly important to prevent modification / addition / removal of the stored keys.

[0093] A method for securely communicating commands / data to an IoT device using public / private keys is illustrated in FIG. 15. This method may be implemented within the system architecture described above, but is not limited to any particular system architecture.

[0094] In 1501, the IoT service encrypts data / commands using the IoT device public key to create an IoT device packet. Next, the IoT service uses the public key of the IoT hub to encrypt this IoT device packet to create an IoT hub packet (e.g., create an IoT hub wrapper around the IoT device packet). In 1502, the IoT service sends the IoT hub packet to the IoT hub. In 1503, the IoT hub decrypts the IoT hub packet using the private key of the IoT hub to generate an IoT device packet. Then, in 1504, the IoT hub sends the IoT device packet to the IoT device, and in 1505, the IoT device decrypts the IoT device packet using the IoT device private key to generate data / commands. In 1506, the IoT device processes the data / commands.

[0095] In one embodiment using symmetric keys, the symmetric key exchange can be negotiated between each pair of devices (e.g., between each device and the hub, and between the hub and the service). Once the key exchange is complete, each sending device encrypts and / or signs each transmission using the symmetric key and then sends the data to the receiving device.

[0096] Apparatus and method for establishing a secure communication channel in an Internet of Things (IoT) system In one embodiment of the present invention, regardless of the intermediate device (e.g., the user's mobile device 611 and / or the IoT hub 110, etc.) used to support the communication channel, the encryption and decryption of data are performed between the IoT service 120 and each IoT device 101. One embodiment of communicating via the IoT hub 110 is illustrated in FIG. 16A, and another embodiment that does not require an IoT hub is illustrated in FIG. 16B.

[0097] First, with reference to FIG. 16A, to encrypt / decrypt communications between the IoT device 101 and the IoT service 120, the IoT service 120 includes an encryption engine 1660 that manages a set of "service session keys" 1650, and each IoT device 101 includes an encryption engine 1661 that manages a set of "device session keys" 1651. The encryption engine can rely on different hardware modules including, among other things, hardware security modules 1630 - 1631 to prevent access to the session secret key of the session public / secret key pair when executing the security / encryption techniques described herein, and key stream generation modules 1640 - 1641 to generate a key stream using the derived secrets. In one embodiment, the service session key 1650 and the device session key 1651 include the associated public / secret key pair. For example, in one embodiment, the device session key 1651 on the IoT device 101 includes the public key of the IoT service 120 and the secret key of the IoT device 101. As will be described in detail below, in one embodiment, to establish a secure communication session, the session public / secret key pairs 1650 and 1651 are used by their respective encryption engines, 1660 and 1661 respectively, to generate the same secret, which is then used by the SKGMs 1640 - 1641 to generate a key stream to encrypt and decrypt communications between the IoT service 120 and the IoT device 101. Additional details associated with the generation and use of secrets according to one embodiment of the present invention are provided below.

[0098] In FIG. 16A, when a secret is generated using keys 1650-1651, the client will always send a message to IoT device 101 via IoT service 120 as indicated by clear transaction 1611. As used herein, "clear" means that the underlying message is not encrypted using the encryption techniques described herein. However, as illustrated, in one embodiment, a Secure Sockets Layer (SSL) channel or other secure channel (e.g., an Internet Protocol Security (IPSEC) channel) is established between client device 611 and IoT service 120 to protect the communication. Encryption engine 1660 on IoT service 120 then uses the generated secret to encrypt the message and sends the encrypted message to IoT hub 110 at 1602. Instead of using the secret to directly encrypt the message, in one embodiment, the secret and a counter value are used to generate a key stream, and this key stream is used to encrypt each message packet. Details of this embodiment are described below with respect to FIG. 17.

[0099] As illustrated, an SSL connection or other secure channel can be established between IoT service 120 and IoT hub 110. IoT hub 110 (which in one embodiment does not have the ability to decrypt messages) sends the encrypted message to the IoT device at 1603 (e.g., via a Bluetooth Low Energy (BTLE) communication channel). Encryption engine 1661 on IoT device 101 can then use the secret to decrypt the message and process the message content. In one embodiment where the secret is used to generate a key stream, encryption engine 1661 can use the secret and a counter value to generate a key stream and then use the key stream for decrypting the message packets.

[0100] The message itself can include any form of communication between the IoT service 120 and the IoT device 101. For example, the message can include a command packet that instructs the IoT device 101 to perform a specific function such as making a measurement and returning the result by notifying the client device 611, or can include configuration data that configures the operation of the IoT device 101.

[0101] When a response is required, the encryption engine 1661 on the IoT device 101 encrypts the response using a secret or derived key stream, and transmits the encrypted response to the IoT hub 110 at 1604. The IoT hub 110 then forwards the response to the IoT service 120 at 1605. The encryption engine 1660 on the IoT service 120 then decrypts the response using a secret or derived key stream, and transmits the decrypted response (e.g., via SSL or other secure communication channels) to the client device 611 at 1606.

[0102] FIG. 16B illustrates an embodiment that does not require an IoT hub. Rather, in this embodiment, communication between the IoT device 101 and the IoT service 120 is performed via the client device 611 (e.g., as in the embodiments described above with respect to FIGS. 6-9B). In this embodiment, to send a message to the IoT device 101, the client device 611 sends an unencrypted version of the message to the IoT service 120 at 1611. The encryption engine 1660 encrypts the message using a secret or derived key stream and returns the encrypted message to the client device 611 at 1612. The client device 611 then transfers the encrypted message to the IoT device 101 at 1613, and the encryption engine 1661 decrypts the message using a secret or derived key stream. The IoT device 101 can then process the message as described herein. If a response is required, the encryption engine 1661 encrypts the response using the secret, sends the encrypted response to the client device 611 at 1614, and the client device 611 transfers the encrypted response to the IoT service 120 at 1615. The encryption engine 1660 then decrypts the response and sends the decrypted response to the client device 611 at 1616.

[0103] FIG. 17 illustrates key exchange and key stream generation that can be initially performed between the IoT service 120 and the IoT device 101. In one embodiment, this key exchange can be performed each time the IoT service 120 and the IoT device 101 establish a new communication session. Alternatively, the key exchange can be performed and the exchanged session key can be used for a specified period (e.g., one day, one week, etc.). Although intermediate devices are not shown in FIG. 17 for simplicity, the communication can be performed via the IoT hub 110 and / or the client device 611.

[0104] In one embodiment, the encryption engine 1660 of the IoT service 120 sends commands to the HSM 1630 (which can be, for example, CloudHSM provided by Amazon (registered trademark)) to generate a session public / secret key pair. The HSM 1630 can then prevent access to the session secret key of this pair. Similarly, the encryption engine on the IoT device 101 can send commands to an HSM 1631 (such as the Atecc508 HSM by Atmel Corporation (registered trademark)) that generates a session public / secret key pair and prevents access to the session secret key of this pair. Of course, the basic principles of the present invention are not limited to any specific type of encryption engine or manufacturer.

[0105] In one embodiment, the IoT service 120 sends, at 1701, its session public key generated using the HSM 1630 to the IoT device 101. The IoT device uses its HSM 1631 to generate its own session public / secret key pair and sends, at 1702, the public key of this pair to the IoT service 120. In one embodiment, the encryption engines 1660-1661 use the Elliptic curve Diffie-Hellman (ECDH) protocol, which is an anonymous key agreement where two parties having elliptic curve public-secret key pairs can establish a shared secret. In one embodiment, using these techniques, at 1703, the encryption engine 1660 of the IoT service 120 generates a secret using the IoT device session public key and its own session secret key. Similarly, at 1704, the encryption engine 1661 of the IoT device 101 independently generates the same secret using the session public key of the IoT service 120 and its own session secret key. More specifically, in one embodiment, the encryption engine 1660 on the IoT service 120 generates a secret according to the formula secret = IoT device session public key * IoT service session secret key, where (* ) means that the IoT device session public key is dot - multiplied by the IoT service session private key. The encryption engine 1661 on the IoT device 101 has Secret = IoT service session public key * Generate a secret according to the formula of the IoT device session private key, and the IoT service session public key is dot - multiplied by the IoT device session private key. Eventually, both the IoT service 120 and the IoT device 101 generate the same secret used to encrypt communication as described below. In one embodiment, the encryption engines 1660 - 1661 rely on hardware modules such as KSGM 1640 - 1641 that perform the above - mentioned operations to generate the secret.

[0106] Once the secret is determined, the secret can be used by encryption engines 1660 and 1661 to directly encrypt and decrypt data. Alternatively, in one embodiment, encryption engines 1660 - 1661 send commands to KSGMs 1640 - 1641 to generate a new key stream using the secret to encrypt / decrypt each data packet (i.e., a new key stream data structure is generated for each packet). Specifically, one embodiment of key stream generation modules 1640 - 1641 implements Galois / Counter Mode (GCM) where a counter value is incremented for each data packet and used in combination with the secret to generate the key stream. Thus, to send a data packet to IoT service 120, encryption engine 1661 of IoT device 101 uses the secret and the current counter value to have KSGMs 1640 - 1641 generate a new key stream and increments the counter value to generate the next key stream. Next, the newly generated key stream is used to encrypt the data packet, which is then sent to IoT service 120. In one embodiment, the key stream is XORed with the data to generate the encrypted data packet. In one embodiment, IoT device 101 sends the counter value to IoT service 120 along with the encrypted data packet. The encryption engine 1660 on the IoT service then communicates with KSGM 1640, and KSGM 1640 uses the received counter value and the secret to generate a key stream (which must be the same key stream since the same secret and counter value are used) and uses the generated key stream to decrypt the data packet.

[0107] In one embodiment, the data packets transmitted from the IoT service 120 to the IoT device 101 are encrypted in the same way. Specifically, a counter is incremented for each data packet and used together with a secret to generate a new key stream. The key stream is then used to encrypt the data (e.g., by performing an XOR of the data and the key stream), and the encrypted data packet is transmitted to the IoT device 101 together with the counter value. The encryption engine 1661 on the IoT device 101 then communicates with the KSGM 1641, and the KSGM 1641 uses the counter value and the secret to generate the same key stream that is used to decrypt the data packet. Thus, in this embodiment, the encryption engines 1660 - 1661 use their own counter values to generate the key stream for encrypting the data and the counter value received together with the encrypted data packet to generate the key stream for decrypting the data.

[0108] In one embodiment, each of the encryption engines 1660 - 1661 includes sequencing logic that tracks the last counter value it received from the other party and detects whether the counter value was received out of sequence or whether the same counter value was received more than once. If the counter value is received out of sequence or the same counter value is received more than once, this may indicate that a replay attack is being attempted. In response, the encryption engines 1660 - 1661 can disconnect from the communication channel and / or generate a security alert.

[0109] FIG. 18 illustrates an exemplary encrypted data packet used in one embodiment of the present invention, including a 4 - byte counter value 1800, a variable - size encrypted data field 1801, and a 6 - byte tag 1802. In one embodiment, the tag 1802 includes a checksum value that verifies the validity of the decrypted data (if and when it is decrypted).

[0110] As described above, in one embodiment, the session public / secret key pairs 1650 - 1651 exchanged between the IoT service 120 and the IoT device 101 can be generated periodically and / or in response to the start of each new communication session.

[0111] One embodiment of the present invention implements additional techniques for authenticating sessions between the IoT service 120 and the IoT device 101. Specifically, in one embodiment, a hierarchy of public / secret key pairs is used, including a parent key pair, a set of factory key pairs, and a set of IoT service key pairs and a set of IoT device key pairs. In one embodiment, the parent key pair includes the root of trust for all other key pairs and is maintained in a single highly secure location (e.g., under the control of the organization implementing the IoT system described herein). A master secret key can be used to generate (and thereby authenticate) signatures over various other key pairs, such as factory key pairs. The signatures can then be verified using the master public key. In one embodiment, each factory that manufactures IoT devices is assigned its own factory key pair, and the factory key pair can then be used to authenticate IoT service keys and IoT device keys. For example, in one embodiment, the factory secret key is used to generate signatures over the IoT service public key and the IoT device public key. These signatures can then be verified using the corresponding factory public key. Note that these IoT service / device public keys are not the same as the "session" public / secret keys described above with respect to FIGS. 16A - 16B. The session public / secret keys described above are temporary (i.e., generated for a service / device session), while the IoT service / device key pairs are permanent (i.e., generated at the factory).

[0112] With the above relationships between the parent, factory, and service / device keys in mind, one embodiment of the present invention performs the following operations to provide an additional layer of authentication and security between the IoT service 120 and the IoT device 101. A. In one embodiment, the IoT service 120 first generates a message that includes the following. 1. Unique ID of the IoT service: · Serial number of the IoT service, · Timestamp, · ID of the factory key used to sign this unique ID, · Class of the unique ID (i.e., the service), · Public key of the IoT service, · Signature over the unique ID. 2. Factory certificate that includes the following: · Timestamp, · ID of the private key used to sign the certificate, · Factory public key, · Signature of the factory certificate 3. IoT service session public key (as described above with respect to FIGS. 16A - B) 4. IoT service session public key signature (e.g., signed with the private key of the IoT service). B. In one embodiment, the message is sent to the IoT device over a negotiation channel (described below). The IoT device analyzes the message to: 1. Verify the signature of the factory certificate (only if present in the message payload). 2. Verify the signature of the unique ID using the key identified by the unique ID. 3. Verify the IoT service session public key signature using the public key of the IoT service from the unique ID. 4. Save the public key of the IoT service and the session public key of the IoT service. 5. Generate an IoT device session key pair. C. The IoT device then generates a message that includes the following: 1. Unique ID of the IoT device, · Serial number of the IoT device, · Timestamp, · ID of the factory key used to sign this unique ID, · Class of unique ID (i.e., IoT device), · Public key of the IoT device, · Signature of the unique ID. 2. Session public key of the IoT device. 3. Signature of (IoT device session public key + IoT service session public key) signed with the IoT device's key. D. This message is sent back to the IoT service. The IoT service analyzes the message to: 1. Verify the signature of the unique ID using the factory public key. 2. Verify the signature of the session public key using the IoT device's public key. 3. Save the IoT device's session public key. E. The IoT service then generates a message containing the signature of (IoT device session public key + IoT service session public key) signed with the IoT service's key. F. The IoT device analyzes the message to: 1. Verify the signature of the session public key using the IoT service's public key. 2. Generate a key stream from the IoT device session private key and the IoT service's session public key. 3. The IoT device then sends a "Messaging available" message. G. The IoT service then performs the following: 1. Generate a key stream from the IoT service session private key and the IoT device's session public key. 2. Create a new message on the messaging channel including: · Generate and store a random 2-byte value. · Set an attribute message with the boomerang attribute Id (described below) and the random value. H. The IoT device receives the message and: 1. Attempts to decrypt the message. 2. Sends an update with the same value as shown on the indicated attribute Id. I. The IoT service recognizes that the message payload includes boomerang attribute updates: 1. Truly set its pairing state. 2. Send a pairing completion message on the negotiation channel. J. The IoT device receives the message and truly sets the pairing state of the IoT device.

[0113] Although the above technology has been described with respect to "IoT services" and "IoT devices", the basic principle of the present invention can be implemented to establish a secure communication channel between any two devices, including a user's client device, a server, and an Internet service.

[0114] The above technology is highly secure because the secret key is not shared wirelessly (in contrast to current Bluetooth pairing technology where the secret is sent from one party to the other). An attacker listening to the entire conversation would only have the public key, which is insufficient to generate the shared secret. These technologies also prevent man-in-the-middle attacks by exchanging signed public keys. Additionally, since GCM and a separate counter are used on each device, any kind of "replay attack" (where an intermediary captures the data and resends it) is prevented. Some embodiments also prevent replay attacks by using an asymmetric counter.

[0115] Techniques for exchanging data and commands without formally pairing the devices GATT is an acronym for Generic Attribute Profile, which defines how two Bluetooth Low Energy (BTLE) devices exchange and transmit data. It utilizes a general data protocol called the Attribute Protocol (ATT), which is used to store services, characteristics, and related data in a simple lookup table using 16-bit characteristic IDs for each entry into the table. Note that on the other hand, "characteristics" are sometimes also called "attributes".

[0116] On a Bluetooth device, the most commonly used characteristic is the device's "name" (which has a characteristic ID of 10752 (0x2A00)). For example, a Bluetooth device can identify other Bluetooth devices within its vicinity by reading the "name" characteristic issued by these other Bluetooth devices using GATT. Thus, Bluetooth devices have the unique ability to exchange data without formally pairing / bonding the devices (note that "pairing" and "bonding" are sometimes used interchangeably. The remainder of this discussion will use the term "pairing").

[0117] One embodiment of the present invention utilizes this ability to communicate with BTLE-enabled IoT devices without formally pairing with these devices. Pairing with each individual IoT device would be highly inefficient due to the time required to pair and the fact that only one paired connection can be established at a time.

[0118] Figure 19 illustrates a particular embodiment in which a Bluetooth (BT) device 1910 establishes a network socket abstraction with a BT communication module 1901 of an IoT device 101 without formally establishing a paired BT connection. The BT device 1910 can be included within an IoT hub 110 and / or a client device 611 as shown in FIG. 16A. As illustrated, the BT communication module 1901 maintains a data structure that includes characteristic IDs, names associated with those characteristic IDs, and a list of values for those characteristic IDs. The value for each characteristic can be stored in a 20-byte buffer identified by the characteristic ID in accordance with current BT standards. However, the basic principles of the present invention are not limited to any particular buffer size.

[0119] In the example of FIG. 19, the "name" characteristic is a BT-defined characteristic to which a specific value of "IoT Device 14" has been assigned. One embodiment of the present invention designates a first set of additional characteristics used to negotiate a secure communication channel with the BT device 1910 and a second set of additional characteristics used for encrypted communication with the BT device 1910. Specifically, in the illustrated example, the "Negotiation Write" characteristic identified by characteristic ID <65532>can be used to send an outgoing negotiation message, and the "Negotiation Read" characteristic identified by characteristic ID <65533>can be used to receive an incoming negotiation message. A "negotiation message" can include messages used by the BT device 1910 and the BT communication module 1901 to establish a secure communication channel as described herein. By way of example, in FIG. 17, the IoT device 101 can receive an IoT service session public key 1701 via the "Negotiation Read" characteristic <65533>. The key 1701 can be sent from the IoT service 120 to a BTLE-compatible IoT hub 110 or client device 611, which can then use GATT to the characteristic ID <65533>The key 1701 can be written to the negotiated read value buffer identified thereby. The application logic 1902 of the IoT device can then read the key 1701 from the value buffer identified by the characteristic ID<65533>and process it as described above (e.g., use it to generate a secret and use the secret to generate a key stream, etc.).

[0120] If the key 1701 is larger than 20 bytes (the maximum buffer size in some current implementations), the key can be written to the 20-byte portion. For example, the first 20 bytes can be written by the BT communication module 1903 to the characteristic ID<65533>and read by the IoT device application logic 1902, and the IoT device application logic 1902 can then write a confirmation response message to the negotiated write value buffer identified by the characteristic ID<65532>. Using GATT, the BT communication module 1903 can read this confirmation response from the characteristic ID<65532>and, in response, write the next 20 bytes of the key 1701 to the negotiated read value buffer identified by the characteristic ID<65533>. In this way, the network socket abstraction defined by the characteristic IDs<65532>and<65533>is established to exchange the negotiation messages used to establish a secure communication channel.

[0121] In one embodiment, when a secure communication channel is established, a second network socket abstraction is established using the characteristic ID<65534>(for transmitting encrypted data packets from the IoT device 101) and the characteristic ID<65533>(for receiving encrypted data packets by the IoT device). That is, when the BT communication module 1903 has an encrypted data packet to transmit (e.g., the encrypted message 1603 in FIG. 16A, etc.), the BT communication module 1903 uses the characteristic ID<65533>Begin writing encrypted data packets in 20 - byte chunks at a time using the message read value buffer identified thereby. The IoT device application logic 1902 will then read encrypted data packets in 20 - byte chunks at a time from the read value buffer and, if necessary, send a confirmation response message to the BT communication module 1903 via the write value buffer identified by the characteristic ID<65532>Thereby.

[0122] In one embodiment, data and commands are exchanged between the two BT communication modules 1901 and 1903 using the GET, SET, and UPDATE commands described later. For example, the BT communication module 1903 can send a packet containing the SET command identifying the characteristic ID<65533>To write to the value field / buffer identified by the characteristic ID<65533>Which can then be read by the IoT device application logic 1902. To obtain data from the IoT device 101, the BT communication module 1903 can send a GET command directed at the value field / buffer identified by the characteristic ID<65534>In response to the GET command, the BT communication module 1901 can send an UPDATE packet containing data from the value field / buffer identified by the characteristic ID<65534>To the BT communication module 1903. Additionally, the UPDATE packet can be sent automatically in response to a change in a specific attribute on the IoT device 101. For example, if the IoT device is associated with a lighting system and the user turns the light on, an UPDATE packet can be sent to reflect this change in the on / off attribute associated with the lighting application.

[0123] FIG. 20 illustrates an exemplary packet format used for GET, SET, and UPDATE according to one embodiment of the present invention. In one embodiment, these packets, after negotiation, have message writing<65534>And message reading<65533>It is transmitted via the channel. In the GET packet 2001, the first 1-byte field contains a value (0X10) that identifies the packet as a GET packet. The second 1-byte field contains a request ID that uniquely identifies the current GET command (i.e., identifies the current transaction associated with the GET command). For example, a different request ID can be assigned to each instance of a GET command sent from a service or device. This can be done, for example, by incrementing a counter and using the counter value as the request ID. However, the basic principle of the present invention is not limited to any particular method for setting the request ID.

[0124] The 2-byte attribute ID identifies an application-specific attribute that the packet is directed to. For example, if the GET command is sent to the IoT device 101 illustrated in FIG. 19, the attribute ID can be used to identify the specific application-specific value being requested. Returning to the above-described example, the GET command can be directed to an application-specific attribute ID such as the power state of the lighting system, and this attribute ID includes a value (e.g., 1 = on, 0 = off) that identifies whether the lighting is on or off. If the IoT device 101 is a security device associated with a door, the value field can identify the current state of the door (e.g., 1 = open, 0 = closed). In response to the GET command, a response can be sent that includes the current value identified by the attribute ID.

[0125] The SET packet 2002 and UPDATE packet 2003 illustrated in FIG. 20 also include a first 1-byte field identifying the packet type (i.e., SET and UPDATE), a second 1-byte field including the request ID, and a 2-byte attribute ID field identifying attributes defined by the application. Additionally, the SET packet includes a 2-byte length value identifying the length of the data included in the n-byte value data field. The value data field can include commands executed on the IoT device and / or configuration data that configures the operation of the IoT device in some way (e.g., setting desired parameters, turning off the power of the IoT device). For example, when the IoT device 101 controls the speed of a fan, the value field can reflect the current speed of the fan.

[0126] The UPDATE packet 2003 can be sent to provide an update of the result of the SET command. The UPDATE packet 2003 includes a 2-byte length value field identifying the length of the n-byte value data field that can include data related to the result of the SET command. Additionally, a 1-byte update status field can identify the current state of the variable being updated. For example, if the SET command attempts to turn off the lighting controlled by the IoT device, the update status field can indicate whether the lighting has been successfully turned off.

[0127] Figure 21 illustrates an exemplary sequence of transactions between the IoT service 120 with SET and UPDATE commands and the IoT device 101. Intermediate devices such as the IoT hub and the user's mobile device are not shown to avoid obscuring the basic principles of the present invention. At 2101, the SET command 2101 is sent from the IoT service to the IoT device 101 and received by the BT communication module 1901, which in response updates the GATT value buffer identified by the characteristic ID at 2102. The SET command is read from the value buffer at 2103 by the low power microcontroller (MCU) 200 (or by program code running on a low power MCU such as the IoT device application logic 1902 shown in FIG. 19). At 2104, the MCU 200 or the program code executes an operation in response to the SET command. For example, the SET command can include an attribute ID specifying a new configuration parameter such as a new temperature, or can include a state value such as on / off (for putting the IoT device into the "on" or low power state). Thus, at 2104, a new value is set in the IoT device, an UPDATE command is returned at 2105, and the actual value of the GATT value field is updated at 2106. In some cases, the actual value will be equal to the desired value. In other cases, the updated value may be different (i.e., because the IoT device 101 may take time to update a particular type of value). Finally, at 2107, an UPDATE command containing the actual value from the GATT value field is sent back to the IoT service 120.

[0128] Figure 22 illustrates a method for implementing a secure communication channel between an IoT service and an IoT device according to an embodiment of the present invention. The method can be implemented in connection with the network architecture described above, but is not limited to any particular architecture.

[0129] At 2201, the IoT service creates an encrypted channel for communicating with the IoT hub using an Elliptic Curve Digital Signature Algorithm (ECDSA) certificate. At 2202, the IoT service encrypts the data / commands within the IoT device packet using the session secret to create an encrypted device packet. As described above, the session secret can be uniquely generated by the IoT device and the IoT service. At 2203, the IoT service sends the encrypted device packet to the IoT hub via the encrypted channel. At 2204, without decrypting, the IoT hub passes the encrypted device packet to the IoT device. At 22 - 5, the IoT device decrypts the encrypted device packet using the session secret. As described above, in one embodiment, this can be achieved by using the secret and the counter value (provided with the encrypted device packet) to generate a key stream and then using the key stream to decrypt the packet. At 2206, the IoT device then extracts and processes the data and / or commands contained in the device packet.

[0130] Thus, using the above - mentioned techniques, a two - way secure network socket abstraction can be established between two BT - compatible devices without formally pairing the BT devices using standard pairing techniques. Although these techniques have been described with respect to the IoT device 101 communicating with the IoT service 120, the basic principles of the present invention can be implemented to negotiate and establish a secure communication channel between any two BT - compatible devices.

[0131] Figures 23A - C illustrate a detailed method for pairing devices according to an embodiment of the present invention. This method can be implemented in relation to the above - described system architecture, but is not limited to any particular system architecture.

[0132] At 2301, the IoT service creates a packet containing the serial number and public key of the IoT service. At 2302, the IoT service signs the packet using the factory private key. At 2303, the IoT service sends the packet to the IoT hub via an encrypted channel, and at 2304, the IoT hub forwards the packet to the IoT device via an unencrypted channel. At 2305, the IoT device verifies the signature of the packet, and at 2306, the IoT device generates a packet containing the serial number and public key of the IoT device. At 2307, the IoT device signs the packet using the factory private key, and at 2308, the IoT device sends the packet to the IoT hub via an unencrypted channel.

[0133] At 2309, the IoT hub forwards the packet to the IoT service via an encrypted channel, and at 2310, the IoT service verifies the signature of the packet. At 2311, the IoT service generates a session key pair, and at 2312, the IoT service generates a packet containing the session public key. Next, at 2313, the IoT service signs the packet with the IoT service private key, and at 2314, the IoT service sends the packet to the IoT hub via an encrypted channel.

[0134] Moving on to Figure 23B, at 2315, the IoT hub forwards the packet to the IoT device via an unencrypted channel, and at 2316, the IoT device verifies the signature of the packet. At 2317, the IoT device generates a session key pair (e.g., using the technology described above), and at 2318, an IoT device packet containing the IoT device session public key is generated. At 2319, the IoT device signs the IoT device packet with the IoT device private key. At 2320, the IoT device sends the packet to the IoT hub via an unencrypted channel, and at 2321, the IoT hub forwards the packet to the IoT service via an encrypted channel.

[0135] At 2322, the IoT service verifies the signature of the packet (e.g., using the IoT device public key), and at 2323, the IoT service generates a session secret using the IoT service private key and the IoT device public key (as detailed previously). At 2324, the IoT device generates a session secret using the IoT device private key and the IoT service public key (also as described above), and at 2325, the IoT device generates a random number and encrypts the random number using the session secret. At 2326, the IoT service sends the encrypted packet to the IoT hub via an encrypted channel. At 2327, the IoT hub transfers the encrypted packet to the IoT device via an unencrypted channel. At 2328, the IoT device decrypts the packet using the session secret.

[0136] Moving on to Figure 23C, at 2329, the IoT device re-encrypts the packet using the session secret, and at 2330, the IoT device sends the encrypted packet to the IoT hub via an unencrypted channel. At 2331, the IoT hub transfers the encrypted packet to the IoT service via an encrypted channel. At 2332, the IoT service decrypts the packet using the session secret. At 2333, the IoT service verifies that the random number matches the random number sent by the IoT service. The IoT service then, at 2334, sends a packet indicating that the pairing is complete, and at 2335, all subsequent messages are encrypted using the session secret.

[0137] Device and method for modifying packet interval Timing for specifying data transfer conditions Bluetooth Low Energy (BTLE) devices send advertising packets separated by an "advertising interval" to establish connections between devices. BTLE peripheral devices use the advertising interval to broadcast advertising packets to all devices in their vicinity. The receiving BTLE device can then act on this information or connect to receive more information.

[0138] The 2.4 GHz spectrum for BTLE extends from 2402 MHz to 2480 MHz and uses 40 1-MHz-wide channels numbered 0 to 39. Each channel is separated by only 2 MHz. Channels 37, 38, and 39 are used only for sending advertising packets. The rest are used for data exchange during a connection. During BTLE advertising, the BTLE peripheral device sends packets one after another on three advertising channels. The central device scanning for devices or beacons listens on those channels for advertising packets, helping it discover nearby devices. Channels 37, 38, and 39 are deliberately spread across the 2.4 GHz spectrum (i.e., channels 37 and 39 are the first and last channels in the band, and channel 38 is in the middle). If any one of the advertising channels is blocked, the other channels are likely to be free since they are separated by several MHz of bandwidth.

[0139] When an IoT device has data to transmit, it typically includes a flag as part of its advertisement packet to indicate that the data is ready to be sent. In one embodiment of the present invention, instead of using this flag, the IoT device adjusts the advertising interval to indicate that it has queued data. For example, if T is the time between advertisement packets when there is no queued data, different advertising intervals such as 0.75T, 0.5T, or 1.25T can be selected to indicate that data is queued. In one embodiment, two different intervals are programmable based on the specific requirements of the application, making it more difficult to determine which interval means which state.

[0140] Figure 24 shows an embodiment of an IoT device 101, in which the BTLE communication interface 2410 includes advertising interval selection logic 2411 that adjusts the advertising interval when the data is ready to be transmitted. In addition, the BTLE communication interface 2420 of the IoT hub 110 includes advertising interval detection logic 2421 to detect changes in the advertising interval, give an acknowledgment response, and receive data.

[0141] In particular, in the illustrated embodiment, the application 2401 of the IoT device 101 indicates what data is to be sent. Accordingly, the advertising interval selection logic 2411 notifies the IoT hub 110 that data is to be sent (e.g., by modifying the advertising interval, such as changing the interval to.75T or some other value) by modifying the advertising interval. When the advertising interval detection logic 2421 detects a change, the BTLE communication interface 2420 connects to the BTLE communication interface 2410 of the IoT device 101 to indicate that it is ready to receive data. The BTLE communication interface 2410 of the IoT device 101 then sends the data to the BTLE communication interface 2420 of the IoT hub. The IoT hub may then pass the data through itself to the IoT service 120 and / or to the user's client device (not shown). After the data has been sent, the advertising interval selection logic 2411 may then return to the normal advertising interval (e.g., AI = T).

[0142] In one embodiment of the present invention, a secure communication channel is established between the IoT device 101 and the IoT service 120 using one or more of the security / encryption techniques described above (see, e.g., FIGS. 16A - 23C and the related text). For example, in one embodiment, the IoT service 120 performs a key exchange with the IoT device 101 as described above to encrypt all communication between the IoT device 101 and the IoT service 120.

[0143] A method according to one embodiment of the present invention is shown in FIG. 25. The method may be implemented in connection with the system architecture described above, but is not limited to any particular system architecture.

[0144] At 2500, when generating advertising packets (e.g., separated by time T), the IoT device uses a standard advertising interval. The IoT device maintains the standard advertising interval at 2502 until it is determined at 2501 that it has data to send. Then, at 2503, the IoT device indicates that it has data to send by switching the advertising interval. At 2504, the IoT hub or other network device enables the IoT device to send its data by establishing a connection with the IoT device. Finally, at 2505, the IoT device sends its queued data to the IoT hub.

[0145] Note that although the advertising interval technique is described herein in relation to the BTLE protocol, the underlying principles of the present invention are not limited to BTLE. In fact, the underlying principles of the present invention may be implemented in any system for selecting an advertising interval to establish wireless communication between devices.

[0146] In addition, although a dedicated IoT hub 110 is shown in many of the above embodiments, a dedicated IoT hub hardware platform is not necessary for the underlying principles of the present invention. For example, the various IoT hubs described above may be implemented as software running within various other networking devices such as iPhone (registered trademark) and Android (registered trademark) devices. In fact, the IoT hubs described above may be implemented on any device that can communicate with IoT devices (e.g., using BTLE or other local wireless protocols) and can establish a connection via the Internet to an IoT service (e.g., using a WiFi or cellular data connection).

[0147] System and Method for Reducing Wireless Traffic When Connecting an IoT Hub to an IoT Device When multiple IoT hubs are configured at a particular location, a single IoT device may have the ability to connect to each IoT hub within range. As described above, the IoT device can use an advertising channel to notify any IoT hub within range that it is "connectable" so that the IoT hub can connect to it to send commands and / or data. When multiple IoT hubs are within range of the IoT device, the IoT service may attempt to send addressed commands / data to the IoT device through each of these IoT hubs, thereby wasting wireless bandwidth and degrading performance (e.g., due to interference resulting from multiple transmissions).

[0148] To address this problem, one embodiment of the present invention implements a technique to ensure that when a particular IoT hub successfully connects to an IoT device, other IoT hubs are notified to stop attempting to send commands / data. This embodiment is described with respect to FIGS. 26A - 26C showing an exemplary set of IoT hubs 110 - 112 all within range of IoT device 101. As a result, the secure wireless communication module 2610 of IoT device 101 can see and connect to the secure wireless communication modules 2650 - 2652 of each of IoT hubs 110 - 112. In one embodiment, the secure wireless communication module includes the secure BTLE module described above. However, the basic principles of the present invention are not limited to any particular wireless standard.

[0149] As shown in FIG. 26A, in one embodiment, the secure wireless communication module 2610 of the IoT device 101 includes advertising control logic 2610 for periodically transmitting an advertising beacon to nearby wireless communication devices indicating that it is "connectable" (i.e., can be connected by any device within range). Any IoT hubs 110 - 112 that receive the advertising beacon then recognize the IoT device 101, and the secure wireless communication modules 2650 - 2652 can connect to the secure wireless communication module 2610 of the IoT device 101 when commands / data are addressed to the IoT device 101 by the IoT service.

[0150] As shown in FIG. 26B, in one embodiment, when the IoT service has data / commands for the IoT device 101, the IoT service may send the data / commands to all of the IoT hubs 110 - 112 within a specific location (e.g., all IoT hubs associated with the user's account and / or within range of the IoT device 101). As shown, each of the IoT hubs 110 - 112 may then attempt to connect to the IoT device 101 to provide the command / data.

[0151] As shown in FIG. 26C, in one embodiment, only a single IoT hub 111 successfully connects to the IoT device 101 and provides commands / data for processing by the IoT device 101. In some wireless communication protocols such as BTLE, when a connection is made, the secure wireless communication module 2610 stops transmitting the advertising beacon. Thus, the other IoT hubs 110, 112 have no way of knowing that the IoT device 101 has successfully received data from the IoT hub 111 and continue to attempt to send commands / data, thereby consuming wireless bandwidth and causing interference.

[0152] To address this limitation, one embodiment of the secure wireless communication module 2610 includes a connection manager 2611 that, upon detecting a successful connection with the secure wireless communication module 2651 of the IoT hub 111, causes the advertising control module 2612 to continue transmitting the advertising beacon. However, instead of indicating that the IoT device 101 is "connectable," the new advertising beacon indicates that the IoT device 101 is "not connectable." In one embodiment, in response to the "not connectable" indication, the secure wireless communication modules 2650, 2652 of the IoT hubs 110, 112 stop attempting to send commands / data to the IoT device, thereby reducing unnecessary wireless traffic.

[0153] The above technique uses technologies that can be easily implemented on top of existing wireless protocols to provide an elegant solution to unwanted wireless traffic. For example, in one embodiment, the "connectable" and "not connectable" indications are implemented within the context of the BTLE standard. However, as described above, the basic principles of the present invention can be implemented using a variety of different wireless network protocols.

[0154] A method according to an embodiment of the present invention is shown in FIG. 27. The method can be implemented in connection with the above-described system architecture but is not limited to any particular system architecture.

[0155] At 2701, commands and / or data are transmitted from the IoT service through two or more IoT hubs. For example, a user may be attempting to control an IoT device via an app on the user's mobile device connected to the IoT service. At 2702, the IoT hubs attempt to connect to the IoT device, and one of the IoT hubs successfully connects and provides the command / data to the IoT device. As described above, the IoT hub can recognize the IoT device as a result of the IoT device sending a "connectable" indication in the advertising beacon.

[0156] At 2703, in response to a successful connection, the IoT device starts transmitting a "connection impossible" advertising beacon, thereby notifying any IoT hub within range that the IoT device is no longer connectable. At 2704, upon receiving the "connection impossible" beacon, other IoT hubs stop attempting to send commands / data to the IoT device.

[0157] System and method for secure Internet of Things (IoT) device provisioning As described above, in one embodiment, when a device advertises to an IoT hub, the device uses an 8-byte "device ID" that the hub and IoT services use to uniquely identify the IoT device. The device ID can be included within a unique barcode or QR code (registered trademark) printed on the IoT device, and the device ID is read and sent to the IoT service to provision / register the IoT device within the system. Once provisioned / registered, the device ID is used to address the IoT device within the system.

[0158] One security concern with this implementation is that since barcode / QR code (registered trademark) data can be transmitted without encryption, it may be possible to eavesdrop on the wireless transmission of the device ID and put the system at risk, thereby enabling another user to associate the device ID with their account.

[0159] In one embodiment, to address this issue, an "association ID" is associated with each device ID and is used during the provisioning process to ensure that the device ID is not sent in plain text. As illustrated in FIG. 28, in this embodiment, the association ID 2812 is included in a barcode / QR code (registered trademark) printed on the IoT device 101, while the device ID 2811 is securely maintained within a secure wireless communication module 2810 that implements the above-described technology to ensure secure communication with the IoT service 120. In one embodiment, the association ID 2812 is an 8-byte ID, similar to the device ID, and is unique for each IoT device. When a new IoT device 101 is provisioned into the system, the user scans the barcode / QR code (registered trademark) containing the association ID 2812 using a user device 135 on which the IoT app or application is installed. Alternatively, or additionally, the IoT hub 110 may be used to capture the barcode / QR code (registered trademark) containing the association ID.

[0160] In either case, the association ID is sent to a device provisioning module 2850 on the IoT service 120 that performs a lookup within a device database 2851 that includes the association between each association ID and each device ID. The device provisioning module 2850 uses the association ID 2812 to identify the device ID 2811 and then provisions the new IoT device 101 within the system using the device ID. In particular, when the device ID is determined from the device database 2851, the device provisioning module 2850 sends a command to the IoT hub 110 (which may include the user device 135) that permits the IoT hub 110 to communicate with the IoT device 101 using the device ID 2811.

[0161] In one embodiment, the association ID 2812 is generated at the factory when the IoT device 101 is manufactured (i.e., when the secure wireless communication module 2810 is provisioned). Then, both the device ID 2811 and the association ID 2812 can be provided to the IoT service and stored in the device database 2851. As shown, the device database 2851 can include an indication specifying whether each device has been provisioned. By way of example, this can be a binary value having a first value (e.g., 1) indicating that the IoT device 101 has been provisioned and a second value (e.g., 0) indicating that the IoT device has not been provisioned. When the system provisions / registers the IoT device 101, the device ID can be used since the communication between the IoT service 120 and the IoT device 101 is protected using the security techniques described above.

[0162] In one embodiment, when a user sells an IoT device, the user can log in to the IoT service 120 and release the device ID by releasing the IoT device from the user's account. The new user can then provision the IoT device and associate the IoT device with their account using the device provisioning techniques described herein.

[0163] A method according to an embodiment of the present invention is shown in FIG. 29. The method can be implemented in connection with the system architecture described above, but is not limited to any particular system architecture.

[0164] At 2901, an association is generated between the device ID of an IoT device and an associated ID (e.g., in a factory where IoT devices are manufactured). The associated ID can be embedded within a barcode / QR code (registered trademark) stamped on the IoT device. At 2902, the association between the device ID and the associated ID is stored on the IoT service. At 2903, a user purchases a new IoT device and scans a barcode / QR code (registered trademark) containing the associated ID (e.g., via a user's mobile device on which an app or application is installed, or via an IoT hub having a barcode reader).

[0165] At 2904, the associated ID is sent to the IoT service. At 2905, the associated ID is used to identify the device ID. At 2906, the IoT device is provisioned using the device ID. For example, the IoT device database may be updated to indicate that this particular device ID has been provisioned, and the IoT service may communicate the device ID to an IoT hub and instruct the IoT hub to communicate with the new IoT device.

[0166] System and method for performing flow control in an Internet of Things (IoT) system Local wireless network traffic increases based on the number of IoT devices within a given location. Further, in some cases, IoT devices may be sending more data than is reasonable considering the functions being performed by the IoT devices. For example, the software / hardware on an IoT device may malfunction, or the IoT device may be hacked, causing the IoT device to continuously send unwanted data to the IoT service.

[0167] One embodiment of the present invention addresses these problems by performing flow control in an IoT hub and effectively ignoring data traffic when a data threshold specified by a particular IoT device is reached. In one embodiment, each IoT device is configured with a specified set of flow control parameters that indicate the amount of data that the IoT device is permitted to transmit over a period of time. The flow control parameters can be based on the type of IoT device. For example, some IoT devices, such as door locks and thermostats, typically should only transmit short packets of data periodically, while other IoT devices, such as video cameras, may potentially transmit significantly large amounts of data aperiodically. Thus, the flow control parameters can be set to provide a sufficient amount of bandwidth based on the expected behavior of the IoT device in question. In one embodiment, each IoT device is assigned to a particular flow control "class" based on the data requirements of that IoT device.

[0168] Such an embodiment is shown in FIG. 30, which depicts a plurality of IoT devices 101-103 having secure wireless communication modules 2810, 3030, 3040, respectively, configured with different sets of flow control parameters 3015, 3031, 3041. In one embodiment, the flow control parameters specify the frequency and / or amount of data that each IoT device is expected to transmit over a specified period of time (e.g.,.25 megabytes per hour, 50 megabytes per hour, 100 megabytes per day, 10 communication attempts per day, etc.). In one embodiment, the flow control parameters 3015, 3031, 3041 can be specified by an IoT service 120 that includes a device management module 3021 for managing a per-device set of flow control parameters 3020 within an IoT device database 2851, as shown. For example, when the data transmission requirements for each IoT device are determined, the per-flow control parameters 3020 can be updated to reflect these requirements.

[0169] As described above, in one embodiment, the device database 2851 includes data transmission requirements for a plurality of different flow control "classes" (e.g., audiovisual devices, temperature devices, control devices, security devices, etc.). When a new IoT device is introduced into the system, it is then associated with a specific flow control class based on the requirements of the IoT device and / or the type of the IoT device.

[0170] The per-device flow control parameter 3020 can be distributed to the IoT hub 110 including flow control management logic 2811 for storing a copy of the per-device flow control parameter 3010 in a local database. In one embodiment, the flow control management 2811 can monitor the amount of data traffic received and / or transmitted between each IoT device 101-103. When the amount of data traffic reaches a specified threshold (as indicated by the per-device flow control parameter 3010), the IoT hub 110 can instruct the IoT device to stop transmitting for a period of time and / or can simply block traffic from the IoT device.

[0171] If a particular IoT device is transmitting / receiving at a level above the specified threshold, this may indicate that the IoT device is malfunctioning. Thus, in one embodiment, the IoT service 120 can send a command to reset the IoT device. If the device is still communicating at a level above the threshold, the IoT service 120 may send a software update, such as a patch, to the IoT device. When the updated software is installed, the IoT device is reset and initialized with the new software. Additionally, a notification can be sent from the IoT service to the user device to inform the user that the IoT device is malfunctioning.

[0172] In one embodiment, the IoT hub 110 can permit a specific type of data traffic despite the fact that the data communication threshold has been reached. For example, in one embodiment, the IoT hub 110 permits a specific type of "high-priority" notification even when an IoT device has reached its threshold. As an example, if the IoT device is a door lock or door entry detector, under certain conditions (e.g., when the home is being monitored), the IoT hub 110 can pass data indicating that someone has opened the door where the IoT device is used. Similarly, if the IoT device is a heat and / or smoke detector, the IoT hub 110 can pass data indicating an alarm condition (e.g., because the temperature has reached a threshold). Various other types of "high-priority" notifications (e.g., those representing potentially dangerous conditions, etc.) can be passed by the IoT hub 110 regardless of the current flow control state. In one embodiment, these "high-priority" notifications are identified using different attributes as described below.

[0173] A method according to an embodiment of the present invention is shown in FIG. 31. The method can be implemented in connection with the system architecture described above, but is not limited to any particular system architecture.

[0174] In 3101, flow control parameters are specified for each IoT device. In one embodiment, an IoT device can be assigned to a specific IoT device "class" having a specified set of flow control parameters associated therewith. In 3102, the flow control parameters are stored on an IoT hub within the IoT system. In one embodiment, each hub can store all subsets of IoT device parameters (e.g., only the parameters for locally provisioned IoT devices).

[0175] If, at 3103, the IoT hub determines that it has detected a particular IoT device operating outside of specified flow control parameters, then at AT 3104, the IoT hub temporarily refrains from further communication with the IoT device (e.g., blocks communication between the IoT device and the IoT service). Additionally, as mentioned, the IoT service and / or the IoT hub can take measures to correct the problem by rebooting the IoT device and / or installing a software update on the IoT device.

[0176] Systems and methods for managing Internet of Things (IoT) devices and traffic using attribute classes Different IoT devices can be used to perform different functions at a given location. For example, one IoT device may be used to collect data such as temperature and status (e.g., on / off status) and report this data back to an IoT service, and the IoT device may be accessed by an end user and / or used to generate various types of alert conditions. To enable this implementation, one embodiment of the present invention uses different types of attribute classes to manage the data collected, system data, and other forms of data.

[0177] FIG. 32 shows an embodiment of an IoT device that includes a secure wireless communication module 3218 that communicates with a microcontroller unit (MCU) 3215 via a serial interface 3216 such as a serial peripheral interface (SPI) bus. The secure wireless communication module 3218 manages secure communication with the IoT service 120 using the techniques described above, and the MCU 3215 executes program code to perform application-specific functions of the IoT device 101.

[0178] In one embodiment, various different classes of attributes are used to manage the data collected by IoT devices and the system configuration related to the IoT devices. In particular, in the example shown in FIG. 32, the attributes include application attributes 3210, system attributes 3211, and priority notification attributes 3212. In one embodiment, the application attributes 3210 include attributes related to the application-specific functions executed by the IoT device 101. For example, if the IoT device includes a security sensor, the application attributes 3210 may include a binary value indicating whether a door or window is open. If the IoT device includes a temperature sensor, the application attributes 3210 may include a value indicating the current temperature. A substantially unlimited number of other application-specific attributes can be defined. In one embodiment, the MCU 3215 executes application-specific program code and is provided access only to the application-specific attributes 3210. For example, an application developer may purchase an IoT device 101 having a secure wireless communication module 3218 and design the application program code executed by the MCU 3215. As a result, the application developer needs to access the application attributes but not the other types of attributes described below.

[0179] In one embodiment, the system attributes 3211 are used to define the operating and configuration attributes of the IoT device 101 and the IoT system. For example, the system attributes may include network configuration settings (e.g., flow control parameters as described above), device ID, software version, advertising interval selection, security implementation form characteristics (as described above), and various other low-level variables required to enable the IoT device 101 to communicate securely with the IoT service.

[0180] In one embodiment, the set of priority notification attributes 3212 is defined based on the level of importance or severity associated with those attributes. For example, if a particular attribute is associated with a dangerous condition such as a temperature value reaching a threshold (e.g., when the user has accidentally left the stove on or when the user's home heat sensor has been triggered), this attribute may be assigned to the priority notification attribute class. As described above, the priority notification attributes may be treated differently from other attributes. For example, when a particular priority notification attribute reaches a threshold, the IoT hub may pass the value of the attribute to the IoT service regardless of the current flow control mechanism implemented by the IoT hub. In one embodiment, the priority notification attributes may also trigger the IoT service to generate a notification to the user and / or an alarm condition within the user's home or company (e.g., warning the user of a potentially dangerous condition).

[0181] As shown in FIG. 32, in one embodiment, the current states of the application attribute 3210, the system attribute 3211, and the priority notification attribute 3212 are replicated / mirrored within the device database 2851 on the IoT service 120. For example, when a change to one of the attributes is updated on the IoT device 101, the secure wireless communication module 3218 communicates that change to the device management logic 3021 on the IoT service 120, and in response, updates the value of the attribute in the device database 2851. Additionally, when a user updates one of the attributes on the IoT service (e.g., adjusts the current state or condition such as a desired temperature), the attribute change is sent from the device management logic 3021 to the secure wireless communication module 3218, and then the secure wireless communication module 3218 updates its local copy of the attribute. In this way, the attributes are maintained in a consistent manner between the IoT device 101 and the IoT service 120. The attributes may also be accessed from the IoT service 120 via the IoT app or the user device on which the application is installed and / or by one or more external services 3270. As described above, the IoT service 120 may expose an application programming interface (API) to provide access to various different classes of attributes.

[0182] Furthermore, in one embodiment, the priority notification processing logic 3022 can execute rule-based operations in response to receiving a notification related to the priority notification attribute 3212. For example, if the priority notification attribute indicates a dangerous condition (e.g., an iron or a stove is left on by the user), the priority notification processing logic 3022 may implement a set of rules to attempt to turn off the dangerous device (e.g., send an "off" command to the device if possible). In one embodiment, the priority notification processing logic 3022 can utilize other relevant data such as the user's current location to determine whether to turn off the dangerous device (e.g., if it is detected that the user has left the house while the dangerous device is in the "on" state). Additionally, the priority notification processing logic 3022 can send alert conditions to the user's client device to notify the user of the conditions. Various other types of rule sets can be implemented by the priority notification processing logic 3022 to attempt to handle potentially dangerous or otherwise undesirable conditions.

[0183] FIG. 32 also shows a set of BTLE attributes 3205 and an attribute address decoder 3207. In one embodiment, the BTLE attributes 3205 can be used to establish read and write ports as described above with respect to FIGS. 19-20. The attribute address decoder 3207 reads the unique ID code associated with each attribute to determine which attribute is being received / transmitted and processes the attribute accordingly (e.g., identifies the location within the secure wireless communication module 3218 where the attribute is stored).

[0184] Apparatus and Method for Transferring and Renting Anonymous IoT Device Accounts and IoT Devices User account creation is an important barrier to acquiring new subscribers for an IoT system. For example, potential subscribers may choose to delay or refrain from signing up for an online IoT service if a significant amount of personal and / or financial information (e.g., phone number, credit card data, Paypal account information, etc.) is required.

[0185] One embodiment of the present invention addresses this limitation by automating account creation. In particular, one embodiment implements an architecture and process in which an anonymous user account is created when an IoT device is first provisioned with an IoT service. The anonymous user account can be automatically created when the user first scans a QR code (registered trademark) associated with the IoT device. The IoT service may then request additional information from the user in order to non-invasively establish a non-anonymous user account after the user has had an opportunity to try out the IoT implementation.

[0186] Accordingly, in one embodiment, automated account creation enables the user to test the IoT device within seconds of scanning the QR code (registered trademark) without any information associated with the user. The IoT device is decoupled from the authenticated secure session created by the IoT service for the account (e.g., using the security / encryption techniques described above). In one embodiment, the account becomes isolated if the user closes the IoT app on the client device or if the session expires before any link to the user is made. The IoT device associated with the isolated account can be linked to a new account when the IoT device is re-associated through the IoT app on the client device. Transfer of the IoT device to a new user can clear any changes in order to provide a new device experience for each new user.

[0187] FIG. 33 illustrates an architecture in which embodiments of the present invention can be implemented. During operation, a user of mobile device 135 opens an IoT app (or browser-executable code) that provides a camera interface for using the camera of mobile device 135 to capture the association IDs 2812A - B of one or more IoT devices 101 - 102. As described above, the association IDs 2812A - B can be encoded as QR codes (registered trademarks), barcodes, or any other form of optical coding displayed on IoT devices 101 - 102. Alternatively, in one embodiment, the association ID may be communicated via a wireless protocol such as near-field communication (NFC) or BTLE. As previously explained with respect to FIG. 28, the association ID 2812 can be sent to a device provisioning module 2850 on IoT service 120 that performs a lookup within a device database 2851 that includes a link between each association ID and a device ID. The device provisioning module 2850 uses the association ID 2812 to identify the device ID 2811 and then uses the device ID to provision a new IoT device 101 within the system and establish a secure connection with IoT service 120. For more details, refer to the descriptions of FIGS. 28 - 29 above.

[0188] Returning to FIG. 33, one embodiment of the present invention includes an account management module 3350 for managing user accounts and a device management module 3315 for managing IoT devices. In the illustrated embodiment, the account management module 3350 includes anonymous account generation logic 3311 for generating anonymous accounts and associating those accounts with one or more IoT devices, as described herein. When the anonymous account generation logic 3311 generates an anonymous account, the user of that account can control and receive data from IoT devices in the same manner as other users with non-anonymous accounts (although, as described below, certain restrictions may be imposed on anonymous accounts).

[0189] At some point later (e.g., after the user is provided with an opportunity to test the IoT device), the IoT app on the user device 135 can present the user with the option to open an account by providing a limited amount of personal information (e.g., email address, phone number, etc.). When the user enters this information, the account conversion logic 3312 converts the database to a non-anonymous account and adds the user data to the database. For example, in FIG. 33, the database 3351 includes four entries corresponding to four different IoT devices that were initially associated with an anonymous account.

[0190] When the user enters any specified amount of personal information, the account conversion logic 3312 converts these entries to non-anonymous account entries and stores the user data associated with the account within the database 3351, as shown in FIG. 34. The database 3351 is shown as a table for simplicity of explanation, but the actual database structure can include multiple interrelated tables and / or can use other types of data storage structures. The basic principles of the present invention are not limited to the configuration of any particular database or data storage device.

[0191] After the user account is made non-anonymous, the IoT service / IoT app can prompt the user for additional information as needed. For example, if the user selects to access a service or transaction that requires payment, the IoT app may prompt the user to enter financial account information (e.g., credit card, paypal account, etc.), and then the IoT app may securely store it in the database 3351.

[0192] One embodiment of the present invention is particularly adapted to enable a first user to configure a plurality of IoT devices for a second user and then transfer those IoT devices to an anonymous or non - anonymous account of the second user on the IoT service 120. For example, the first user may be a professional installer who uses a first mobile device (their own device) with an IoT app to configure a plurality of IoT devices for the second user (e.g., by capturing an associated ID as described). Once all of the IoT devices are provisioned on the IoT service 120 and associated with the first user's account, the first user may cause code to be generated via the IoT application, and this code can then be used to transfer the IoT devices to the second user's account. In one embodiment, a QR code (registered trademark) is generated and / or provided by the IoT service 120 in response to a request from the first user submitted via the IoT application (e.g., navigating to a menu item for device transfer within the IoT application). Other mechanisms can also be used to provide the code to the second user, such as sending the code to the second user via email or text.

[0193] Regardless of how the code is generated or transmitted, in one embodiment, the code is associated in the IoT service 120 with a plurality of new IoT devices configured by the first user on behalf of the second user. In one embodiment, upon completion of the configuration of the IoT devices, the first user displays a QR code (registered trademark) on the screen of the first mobile device. The second user then opens the IoT app and scans the QR code (registered trademark) (which may be generated by the IoT service 120 or the first mobile device as described and transmitted to the IoT service 120).

[0194] In one embodiment, after verifying the code, the account conversion module 3312 on the IoT service 120 transfers the IoT device from the account of the first user to the account of the second user. In a particular implementation, the account of the first user is anonymous, and the account of the second user is (initially) anonymous or non-anonymous, but the basic principle of the present invention is not limited to this implementation. For example, both the account of the first user and the account of the second user may be anonymous accounts, non-anonymous accounts, or a combination, depending on a particular implementation.

[0195] An embodiment of a method and user interface for an exemplary IoT app is described with respect to FIG. 35. In this example, assume that the user has a new IoT device designed to securely connect to an IoT service (e.g., as described above) and has not yet established an account on the IoT service.

[0196] At 3501, the user launches an IoT application on a mobile device that displays an instruction to scan a QR code (registered trademark) from an IoT device. If the user has not installed an IoT hub, when the IoT application is executed, it performs the functions of the IoT hub (for example, securely connecting the IoT device to the IoT service as described above). At 3502, the mobile device OS prompts the user to allow the IoT application to use the camera. At 3503, the user captures an image of the QR code (registered trademark) on the IoT device. To assist the user in focusing on the QR code (registered trademark), the outline of a square capture area is drawn within the GUI. At 3504, the user is provided with a set of graphical controls (for example, on / off in this example) for controlling the IoT device, and data collected by the IoT device (depending on the type and implementation form of the IoT device) and securely transmitted via the IoT service may also be provided. Thus, in this example, the user obtains secure two-way access to the IoT device before establishing an account on the IoT service and entering any personal information. In one embodiment, this is achieved by the anonymous account generation module 3311 generating an anonymous account when the user scans the QR code (registered trademark) and associating the IoT device ID / associated ID with the anonymous account.

[0197] When the "+" icon is selected at 3504, the user is presented with a menu containing various options as shown at 3505, some of which may require the user to submit personal information at 3506. For example, the user can enter an email address or a phone number. In response, the account conversion logic 3312 can convert the anonymous account to a non-anonymous account as described above with respect to FIG. 34.

[0198] A method for a first user to configure an IoT device on behalf of a second user and an exemplary user interface are described with respect to FIGS. 36A-36B. Referring first to FIG. 36A, at 3601, the first user scans a first IoT device, resulting in the control graphics shown at 3602. The first user opens a menu at 3603 and selects to add another IoT device at 3604. When a second device is scanned, two sets of control graphics are shown at 3605 (one for each device). As indicated by the arrows, the first user can return to the menu and continue adding devices. As each device is added, the IoT service 120 is updated as described above. For example, if the first user has a non-anonymous account, data for each of the IoT devices is stored in the database 3351 and associated with the first user's account. If an anonymous account is being used, the first user can convert to a non-anonymous account by entering personal information (e.g., an email address or phone number).

[0199] Referring to FIG. 36B, once all IoT devices are configured, the first user may, at 3606, select the "Transfer" option from the menu and transfer the IoT devices to the account of the second user. As shown, different options may be available for the transfer. In one embodiment (Option 1), as described above, a QR code (registered trademark) is displayed on the first user's mobile device. The code may be generated by the account conversion logic 3312 on the IoT service in response to the first user selecting the "Transfer" menu item. Once generated, it may be associated in the database 3351 with the set of IoT devices configured by the first user. At 3608, the first user can use the IoT application to scan the QR code (registered trademark), and then the IoT application sends the code to the IoT service. Upon verifying the code, the account conversion logic 3312 then transfers the code and the IoT devices associated with the first user's account to the second user's account, resulting in the control graphics shown at 3609 (in this example, two sets of control graphics for two IoT devices).

[0200] Alternatively, or additionally, at 3610, the first user may enter identification information associated with the second user, such as the second user's email address or account number, or may manually send the second user a QR code (registered trademark) (e.g., via email or text). Upon accessing the IoT service via the IoT application and providing the necessary information, the second user is presented, at 3611, with the same set of control graphics as when the IoT devices are transferred to the second user's account.

[0201] Figures 37A - 37B are transaction diagrams showing different embodiments of the present invention in which two users, User A 3701 and User B 3702, implement IoT device management operations through communication with an account management module 3350 and a device management module 3315. Each user is assumed to have an IoT application installed on a computing device that executes the illustrated transactions.

[0202] In the example of Figures 37A - 37B, User A 3701 adds, configures, and persists the configuration for the device on behalf of User B 3702. In this example, User A performs its operations using an anonymous user account, yet still has the ability to configure and persist multiple devices. As used herein, persisting a configuration means that the device's configuration can withstand device transfer. For example, an IoT thermostat can be installed by a professional installer (User A) and configured using Wifi credentials and a schedule without sharing the account username and password of the end - user's device account (User B). The end - user only needs to associate the device to be initiated with the pre - configured IoT device. In another embodiment, User A can perform its operation of configuring the IoT devices within a non - anonymous user account and then transfer the configuration to User B.

[0203] In FIG. 37A, user A 3701 first uses the IoT app to add a new IoT device (e.g., by capturing a QR code (registered trademark) as described above). The "Add Device" command is received by the account management module 3350, which creates an anonymous account for user A and sends the command to "Add Device" to the device management module 3315. The device management module 3315 adds the new IoT device to the database and notifies the account management module 3350. As described above, in one embodiment, this is accomplished by using an association ID to identify the device ID and securely sending the device ID to the account management module 3350 and / or user A 3701.

[0204] Next, user A executes the configuration of the IoT device, and the device management module 3315 sets the configuration data and provides a notification to user A 3701. When the configuration is complete, user A generates a persist command (e.g., via the IoT application user interface) to the device management module 3315 to persist the configuration of each of the configured IoT devices. The isolated anonymous account of user A may then be deleted, but the IoT device configuration is persisted by the device management module 3315.

[0205] As described above, these IoT device configurations can be associated with the code in the database that transfers the configured IoT devices to user B when input / captured by user B's IoT app. For an individual IoT device, the code can be the device ID / associated ID. Thus, as shown in FIG. 37B, user B 3702 generates a "device addition" command via the IoT app that is sent to the account management module 3350. The command identifies the IoT device, and in response, the account management module 3350 creates an anonymous account for user B 3702. When the device management module 3315 receives the command, it transfers the persisted device configuration to user B's account and sends a notification to the account management module 3350 and user B's IoT app.

[0206] In one embodiment, when an account is linked to an email or phone number (i.e., becomes a non-anonymous account), further transfer of devices associated with that account is not permitted without the user's consent. Thus, when user B 3702 uses the phone number to send a notification, the account management module 3350 converts the account to a non-anonymous account and sends a notification to the device management module 3315 to protect the IoT devices associated with the account. The device management module 3315 locks the devices and notifies the account management module 3350.

[0207] Figures 38A to 38B show an example where user A 3701 adds an IoT device to be added to an anonymous account (for example, scans the QR code (registered trademark) of the IoT device). Subsequently, user B 3702 adds the same IoT device. Since the IoT device is associated with the anonymous account, the device management module 3315 transfers the device to a new account created for user B. Next, user B 3702 associates an email address with the anonymous account. The account management module 3350 notifies user B that a non - anonymous account has been created and, in response, converts the account to a non - anonymous account. The account management module 3350 sends a message to the device management module 3315 to protect the IoT device. The device management module 3315 locks the IoT device and notifies the account management module. The account management module 3350 then deletes the isolated account of user A. As shown in Figure 38B, when the device management module 3315 locks the device instead of user B's account, subsequent attempts by user A to add the device will fail.

[0208] In one embodiment, to provide additional IoT device / service benefits to the user, the IoT app on the client can prompt the user to change their anonymous account to a non - anonymous linked account. By linking the account to an email or phone number, the user is provided with the ability to recover the account even after the client session has expired. Adding a phone or email to the account can also enable benefits such as notifications, sharing with other users, sending payment receipts, and / or creating device rules.

[0209] In one embodiment, the above-described architecture enables public IoT devices that can be temporarily associated with a user who installs an IoT app. By way of non-limiting example, public IoT devices can include parking meters, vending machines, and / or self-driving vehicles. As described above, one embodiment of the present invention provides for the immediate use of IoT devices through the creation of an anonymous account and also provides an account link for sending receipts to a phone number or email address. This implementation helps drive account adoption and data analytics.

[0210] In one embodiment, when a device is linked to a phone number or email, the user can "share" the device with another account. For example, the GUI menu at 3505 in FIG. 35 includes a "Share" option. A first user can select this option and enter the identification information (e.g., email address, phone number) of a second user to share one or more IoT devices with the second user. When sharing, the IoT device can be controlled by both users.

[0211] In contrast, in one embodiment, the "transfer" option (see, e.g., 3606 in FIG. 36B), in combination with automatic account creation as described above (i.e., creating an anonymous account if the user has it in response to receiving user data), allows the owner to transfer direct control of the device to another user account, but the account management logic 3350 maintains the owner of the IoT device (and thus can disable the lent IoT device). One embodiment implements different forms of "transfer". For example, a permanent transfer can permanently transfer the IoT device from the account of a first user to the account of a second user. Once transferred, the first user will not regain control of the IoT device unless the second user transfers it back to the first user. In contrast, the embodiments described below implement a temporary transfer (i.e., device lending), where the first user transfers control of the IoT device to the second user for a specified period. In one embodiment, the first user is prevented from accessing the IoT device when the IoT device is lent to the second user.

[0212] Specifically, FIG. 39 shows a series of transactions in which a first user (User A) lends one or more IoT devices to a second user (User B). In this example, User A, who is the owner of the IoT device(s), sends a "device lending" command to the account management logic 3350 that permits the device transfer operation. As described above, "lending" can be defined as a temporary device transfer. The device management logic 3315 then unlocks the IoT device and enables the IoT device(s) to be associated with another account (anonymous or non-anonymous).

[0213] User B then adds one or more of the IoT device(s) (e.g., by capturing a QR code (registered trademark)). In response, the account management logic 3350 permits the action and creates an account for User B (an anonymous account if User B does not already have an account). Upon receiving permission from the account management logic, the device management logic 3315 adds the device to User B's account and generates a confirmation. User B can then view and control any of the transferred IoT devices. In contrast, User A is temporarily prevented from viewing or controlling the IoT devices.

[0214] Thus, using device lending as described above, the device configuration can be persistent, but the current user with access to the IoT device is guaranteed to be the only user who can control the IoT device at any given time. This embodiment can be particularly useful in situations where privacy is a concern. For example, when a home equipped with IoT devices is rented out (e.g., using Airbnb or a similar service), the tenant may need temporary access to the IoT devices (e.g., thermostat, security device, video camera, etc.). If the asset owner retains access to the IoT devices while the tenant is present, the tenant may be concerned. Using the techniques described herein, the asset owner can assure the tenant that all IoT devices, including security devices and video cameras, have been temporarily transferred to the tenant, thereby preventing access by the asset owner during the rental period.

[0215] Device lending can be achieved by lending to a specific user account or to someone (i.e., an anonymous user account). The above-described embodiment simplifies the device transfer process. The asset owner can simply enable lending to any tenant without exchanging account information. The tenant can then control the IoT device without further instruction.

[0216] Due to the anonymous nature of the anonymous accounts described in this specification, the need for a password is essentially eliminated. If the device cannot access the email or phone number, the need to log in to multiple devices simultaneously may still exist. To add this functionality, the user can even set a password and enter a username other than an email.

[0217] Systems and methods for machine learning (ML)-based IoT device provisioning To install a new IoT device, the user typically installs and runs an IoT device app that guides the user through the installation process, typically based on a script. At a particular stage of the installation process, the IoT device app prompts the user to capture a QR code (registered trademark) or other optical code from the surface or display of the IoT device. Once the optical code is captured, this identification information enables the IoT device app and / or the IoT service to uniquely identify the IoT device, communicate securely with the IoT device (as described above for various embodiments), and / or register the IoT device with the IoT service.

[0218] However, current implementations provide inadequate solutions when the user cannot find the optical code. In some implementations, for example, the IoT device app asks the user to select the IoT device model via a series of drop-down selection fields or by entering a known portion of the model number. This can be a challenge considering the potentially large number of IoT device models manufactured by the same company, some of which may have similar appearances and / or similar functions.

[0219] To address these limitations, embodiments of the present invention identify the IoT device model using object recognition technology. In particular, at this stage of the setup process, the IoT device app requests the user to capture at least one image of the IoT device. The IoT device app transfers the image(s) to the IoT service, and the IoT service performs image recognition using a pre-trained ML-based image recognition engine. The IoT service then sends information indicating the IoT device model number to the IoT device app, and the IoT device app uses that information to complete the setup process.

[0220] By way of example and not limitation, FIG. 40 shows examples of three different IoT devices, namely, wall switch 102, video camera 102, and door lock 103. When an optical code is not available when setting up one of these devices, the IoT device app running on user device 135 prompts the user to capture one or more images of this particular IoT device 101, 102, or 103.

[0221] The IoT device app sends the image data 4010A via a secure connection to the device provisioning logic 4000 on the IoT service 120. In one embodiment, the device provisioning logic 4000 operates as an interface between the IoT devices 101-103 and the IoT service 120 during the setup process. Image preprocessing 4015 may be performed to normalize image data received from different types of user devices. For example, the input image may be scaled to a particular resolution and / or the image file may be converted to a new format with particular characteristics (e.g., a particular bit depth, color space, etc.) for processing by the ML-based object recognition engine 4050.

[0222] The normalized image data 4010B is provided to an ML-based object recognition engine 4050 trained using images of IoT devices sold by the entity operating the IoT service 120 (e.g., as described below with respect to FIG. 41). The device model 4040 identified by the ML-based object recognition engine 4050 is communicated to the device provisioning logic 4000, and in response, communicates the device model and / or additional setup instructions 4041 to the IoT app on the user device. For example, when an IoT device is identified, the user may be requested to perform a series of button presses (via the IoT device app) or turn the IoT device on and off a specific number of times to enter the IoT device into a special setup mode (if the IoT device is not already in this mode).

[0223] FIG. 41 shows an example of a training sequence. In particular, the training logic 4070 uses training data 4075 that includes images and associated metadata to train the ML-based object recognition engine 4050. The training logic 4070 can provide each image and associated metadata that identifies the IoT device within each image, and the ML-based object recognition engine 4050 uses these to "learn" the object characteristics of each IoT device. In some embodiments, when a certain amount of learning is achieved, the ML-based object recognition engine 4050 can provide results (e.g., the identified IoT device or candidates) to a training module 4070 that can provide feedback to the ML-based object recognition engine 4050 for use in additional learning (e.g., indicating whether the correct IoT device was identified).

[0224] The ML-based object recognition engine 4050 can continue to learn once it becomes operational because new dynamically acquired training data 4077 is collected from the field and new training data 4075 is provided by IoT device manufacturers. For example, every time a user captures an image of an IoT device from a user device 4090 and the IoT device is identified, this information can be used by the training logic 4070 to further instruct the ML-based object recognition engine 4050. Additionally, when new IoT device products become available, the training data 4075 associated with these products can be directly provided to the training logic 4070 so that the ML-based object recognition engine 4050 can learn the object characteristics associated with the new IoT devices.

[0225] In this way, the ML-based object recognition engine 4050 learns how to distinguish between different IoT devices based on the object characteristics in different images. The accumulated learning is stored as ML data 4055 on the IoT service 120. In one implementation, the training data 4075 includes images of each IoT device model in both the installed and uninstalled states (e.g., the same wall switch taken out of the package but not yet installed versus the wall switch installed inside the wall box) so that the IoT device can be identified at different stages of installation.

[0226] Figures 40-41 illustrate an implementation form where the ML-based object recognition engine 4050 is on the IoT service 120. However, in some embodiments, the ML-based object recognition components can also be included on individual user devices 4090 (e.g., within the IoT device app). For example, the ML data 4055 generated by the ML-based object recognition engine 4050 can be included in the IoT device app and can be continuously updated. The object recognition engine within the IoT device app can then use the ML data 4055 to locally recognize the IoT device without communicating with the IoT service 120. These embodiments can be useful, for example, when the network connection to the IoT service 120 is unavailable. In some embodiments, part of the image recognition is performed on the user device 4090 (e.g., when recognition can be performed relatively easily), and another part is performed by the ML-based object recognition engine 4050 on the IoT service 120 (e.g., when more intensive operations are required).

[0227] In accordance with the basic principles of the present invention, various forms of ML-based object recognition can be performed. For example, the machine learning technique can be based on artificial neural networks involving representation learning. This can include, without limitation, convolutional neural networks and other forms of deep learning architectures. Furthermore, the machine learning engine can be trained using supervised learning, semi-supervised learning, unsupervised learning, or any combination thereof (e.g., using different types of machine learning at different training stages).

[0228] The method according to various embodiments of the present invention is shown in FIG. 42. The method can be implemented in connection with the architectures described herein, but is not limited to any particular IoT service or machine learning architecture.

[0229] At 4201, the user starts the process for setting up a new IoT device (or a previously owned IoT device) by running the IoT device app on the user's mobile device. At 4202, the IoT device app reaches the stage of the setup process where the user is asked to scan a machine-readable optical label such as a barcode or a QR code (registered trademark). If the optical label is available, the user scans the optical label and the setup process continues as described for the various embodiments above (e.g., establishing a secure communication channel between the IoT device and the IoT service and registering the IoT device).

[0230] At 4203, the user indicates via the IoT application that the optical label is not available, and at 4204, the IoT device application prompts the user to capture a photo of the IoT device. In one embodiment, the IoT app includes an integrated photo capture component that instructs the user to hover the camera at a specific distance from the IoT device to capture an image when the OS provides access to the mobile device camera.

[0231] At 4205, the photo data (or a selected portion of the photo data) is sent to the IoT service, and at 4206, the IoT service performs ML-based object recognition to identify the IoT device model. As described above, the user may be instructed to take additional photos as needed to ensure that the likelihood of a correct detection result exceeds a specified threshold (e.g., 80%, 75%, etc.).

[0232] Once identified, at 4207, the IoT service transmits additional information such as instructions for the IoT device model and / or a process to set the IoT device to a specified setup mode (however, the latter information is stored on the IoT device and can be accessed when the IoT device model is identified). Finally, at 4208, the IoT device app continues to execute the setup process based on the IoT device model.

[0233] System and method for IoT device identification and initialization using a Bluetooth advertising channel As described above, low-power Bluetooth devices such as Bluetooth Low Energy (BTLE) or BT5 (hereinafter "BT") devices send advertising packets to broadcast connection information and establish connections with other BT devices. Embodiments of the present invention implement a system for the interaction between an IoT device and a mobile app using BT advertising packets to provide the mobile app with "recognition" of a particular type of nearby device. This recognition allows the mobile app to provide the user with IoT device-specific images, videos, audio, and / or instructions during the device onboarding process.

[0234] For various reasons, an end user may be required to physically interact with an IoT device during the onboarding process. The situations can include, but are not limited to, the loss of the user manual and / or other documents, the purchase of a previously owned and returned device (RMA) that may still be associated with a previous owner's account, or the purchase of an IoT device that needs to be placed in a "setup mode" (usually to ensure physical access to the device) prior to onboarding. In practice, this typically involves pressing multiple buttons together, holding a single button down for several seconds, powering the device on and off several times, or taking some other series of interaction forms that trigger the underlying firmware of the IoT device to enter the setup process.

[0235] However, since various types of IoT devices can take the form of a virtually infinite array of physical hardware, there is no standardized way to inform an end user exactly how any single IoT device will interact. Documentation can be placed in the original package, but this is often lost or not available during the onboarding process. Additionally, creating, validating, printing, and including custom diagrams for every possible hardware configuration in either a write-in or online experience is typically not feasible.

[0236] Other solutions include asking the end user to select an IoT device from a long list of possibilities. In the case of large-scale deployments with many devices, this results in an unpleasant user experience. Many IoT device types look similar to each other, the potential for user error is high, and onboarding frustration leads to a higher return rate.

[0237] Referring to FIG. 43, one embodiment of the present invention addresses these limitations using a BT advertising channel 4360 to provide "recognition" of nearby devices of a particular type, such as IoT device 101, to a mobile application 1902 operating on a user's mobile device 135. In particular, an application 4307 including onboarding logic 4301 may be loaded from firmware and executed on IoT device 101 (e.g., executed on a microcontroller or other processor of IoT device 101).

[0238] In one embodiment, the IoT device 101 includes a Bluetooth module 4380 that implements a low-power Bluetooth protocol such as BT5. As described above, when in the BT advertising mode, the BT module 4380 periodically transmits packets having an advertising payload that can be up to 31 bytes in length. In one embodiment of the present invention, during the BT advertising sequence, the Bluetooth module 4380 transmits a "key" 4350 that uniquely identifies the model of the IoT device 101 over the BT advertising channel 4360. The key 4350 is sized to fit within the BT advertising data space (e.g., up to 31 bytes in length) and can be a numerical value programmed into the BT module 4380 during manufacturing. Alternatively, the key 4350 can be programmed in the IoT device firmware (or other non-volatile storage device) and provided to the BT module 4380 via the onboarding logic 4301.

[0239] Regardless of how the key is formatted, the key is received via the BT module 4381 of the mobile device 135 in response to the mobile app 4308. As shown, the mobile app 4308 can securely connect to the device onboarding logic 4321 operating on the IoT service 120 during the onboarding process. In one implementation, the mobile app 4308 downloads and / or pre-installs a key dictionary 4310 that associates various Bluetooth advertising "keys" with IoT device documents including images, text, video, and / or audio assets and provides the user with instructions 4388 related to the onboarding of the IoT device 101. For example, when the IoT device model is identified using the key, the instructions 4388 can identify a series of button presses or other IoT device inputs to put the IoT device 101 into the setup mode, in which the IoT device 101 can be successfully configured and associated with the user's account on the IoT service 120.

[0240] In a particular implementation, the key dictionary 4310 is a dictionary in JSON format, but the basic principle of the present invention is not limited to any particular data format. When a new IoT device is released, new dictionary data and associated keys can be added to the dictionary database 4320 on the IoT service 120 and provided to the mobile app 4308 as needed.

[0241] In one embodiment, when hardware interaction between the end user and the IoT device 101 is required, the mobile app 4308 scans the area via the BT module 4381 to find Bluetooth devices advertising these special keys. If the IoT device is not found, the user can be shown general information prompting them to move closer to the IoT device and ensure that its power is turned on. If only one IoT device 101 is found (i.e., detected based on the specific key 4350 received), the mobile app 4308 displays a custom command 4388 based on the key of that IoT device, as specified by the key dictionary 4310.

[0242] In one embodiment, the key dictionary 4310 can include a hyperlink or other address for each key that refers to device-specific onboarding instructions 4388, including video, audio, images, and / or text, to guide the user through the IoT device onboarding process. The key dictionary 4310 can also include or link to text or other content stored locally on the mobile device 135.

[0243] When keys from multiple IoT devices are detected by the mobile device 135, one embodiment of the mobile app 4308 displays a custom command 4388. For example, a prioritized list of IoT devices may be provided based on Bluetooth signal strength (e.g., the IoT device with the strongest Bluetooth signal is at the top of the list). The user may also be presented with additional options via the user interface of the mobile application 4308 if the initially presented IoT device is not the target IoT device 101. In one implementation, any IoT devices already associated with the user's account are filtered from the list of available IoT devices.

[0244] When the target IoT device 101 is identified, the mobile application 4308 uses the key 4350 to access the key dictionary 4310 to identify the IoT device model and generate an onboarding command 4388. As described above, the onboarding command 4388 may include rendering images, videos, audio, and / or text to guide the user through the setup flow.

[0245] A method according to an embodiment of the present invention is shown in FIG. 44. The method can be executed on the various devices and system architectures described above, but is not limited to any particular architecture.

[0246] At 4401, the user runs an IoT device app on a mobile device and indicates onboarding of a new IoT device (e.g., via a user-selectable menu option). If the IoT device can be identified, as determined at 4402, a standard onboarding process may be used, and at 4410, the IoT device app communicates with the IoT device and IoT service to configure the IoT device and associate it with the user's account on the IoT service.

[0247] If the IoT device cannot be identified via the standard technology, in response to the IoT device app, the mobile device listens for the BT advertising channel at 4403. If multiple keys are identified as determined at 4404, at 4411, the list of keys / IoT devices is prioritized and / or filtered as described above. For example, the key / IoT device with the maximum signal strength value may be placed at the top of the priority list, and / or any IoT device already associated with the user's account may be filtered out of the list.

[0248] When the target IoT device is identified, the IoT device app performs a lookup in the key dictionary to identify the target IoT device model and / or related data. For example, the key dictionary may include links to various forms of instruction content related to the IoT device model, including video, audio, text, and / or images provided via the mobile device at 4406. After the configuration process is completed at 4407, the target IoT device is fully onboarded and associated with the user's account on the IoT service.

[0249] Embodiments of the present invention may include the various processes described above. These processes can be embodied in machine-executable instructions that can be used to cause a general-purpose or special-purpose processor to execute the processes. Alternatively, these processes can be executed by specific hardware components that include hardwired logic for executing the processes, or by any combination of programmed computer components and custom hardware components.

[0250] As described herein, a command, when referring to a particular configuration of hardware such as an application specific integrated circuit (ASIC), can be configured to perform a particular operation or stored in memory in which a given function or software instructions are embodied in a non-transitory computer-readable medium. Thus, the techniques shown in the drawings may be implemented using code and data stored and executed on one or more electronic devices (e.g., an end station, a network element, etc.). Such electronic devices use computer machine-readable storage media such as non-transitory computer machine-readable storage media (e.g., magnetic disks, optical disks, random access memories, read only memories, flash memory devices, phase change memories), as well as transitory computer machine-readable communication media (e.g., electrical, optical, acoustic, or other forms of propagated signals such as carrier waves, infrared signals, digital signals, etc.) to store and communicate code and data (internally and / or with other electronic devices via a network).

[0251] In addition, such electronic devices typically include a set of one or more processors coupled to one or more other components such as one or more storage devices (non-transitory machine-readable storage media), user input / output devices (e.g., a keyboard, a touch screen, and / or a display), and a network connection.

[0252] The coupling of the set of processors to the other components is typically done through one or more buses and bridges (also called bus controllers). Each of the storage device and the signals carrying network traffic represents one or more machine-readable storage media and machine-readable communication media. Thus, the storage device of a given electronic device typically stores code and / or data for execution on the set of one or more processors of that electronic device. Of course, one or more portions of one embodiment of the invention may be implemented using different combinations of software, firmware, and / or hardware.

[0253] Throughout this detailed description, for purposes of explanation, numerous specific details have been set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one 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 so as not to obscure the subject matter of the present invention. Accordingly, the scope and spirit of the present invention should be determined from the perspective of the following claims.

Claims

1. It is a system, A key transmitted via a Bluetooth® (BT) advertising channel, the key being associated with a model of the target Internet of Things (IoT) device, the target IoT device for transmitting the key, When installed on a mobile device, the mobile application program code causes the mobile device to listen to the BT advertising channel in order to extract the key, A system comprising: a key dictionary installed on the mobile device, wherein the key dictionary maps each of a plurality of keys to an IoT device model and associated data; the mobile application program code performs a lookup using the keys extracted from the BT advertising channel to identify the target IoT device model and / or associated data; the associated data is used for onboarding the target IoT device; and the associated data includes a hyperlink or other address pointing to a device-specific onboarding instruction for registering the IoT device with a corresponding user account on an IoT service.

2. The system according to claim 1, wherein the related data is available to the mobile application program code to configure the target IoT device and provide the user with instructions to add the IoT device to the user's account on the IoT service.

3. The system according to claim 2, wherein the related data includes audio and / or video assets, text, and one or more network links that identify video, audio, text, and / or images in order to provide the user with the command.

4. The system according to claim 3, wherein the key dictionary is stored in JSON data format.

5. The system according to claim 2, wherein, when multiple keys are extracted from multiple BT advertising channels, the mobile application program code prioritizes and / or filters out certain keys in order to identify the keys for the target IoT device.

6. The system according to claim 5, wherein the mobile application program code is for filtering out keys for IoT devices already associated with the user's account on the IoT service.

7. The system according to claim 6, wherein the mobile application program code prioritizes the keys based on the measured signal strength of each of the BT advertising channels.

8. The system according to claim 1, wherein the mobile application program code causes the mobile device to listen to the BT advertising channel to extract the key only if the initial onboarding process is unavailable or unsuccessful.

9. It is a method, The target Internet of Things (IoT) device transmits a key via a Bluetooth (BT) advertising channel, the key being associated with the model of the target IoT device. In response to the mobile application program code, the mobile device listens to the BT advertising channel and extracts the key. A key dictionary is provided using the keys extracted from the BT advertising channel, the key dictionary is installed on the mobile device, and a lookup is performed within the key dictionary, mapping each of the multiple keys to an IoT device model and associated data. Identifying the target IoT device model and / or related data from the aforementioned key dictionary, Using the aforementioned related data for onboarding the target IoT device, wherein the related data includes a hyperlink or other address pointing to a device-specific onboarding instruction for registering the IoT device with a corresponding user account on the IoT service. Methods that include...

10. The method according to claim 9, wherein the related data is available to the mobile application program code to configure the target IoT device and provide the user with instructions to add the IoT device to the user's account on the IoT service.

11. The method according to claim 10, wherein the related data includes audio and / or video assets, text, and one or more network links that identify video, audio, text, and / or images in order to provide the user with the command.

12. The method according to claim 11, wherein the key dictionary is stored in JSON data format.

13. The method according to claim 10, wherein, when multiple keys are extracted from multiple BT advertising channels, the mobile application program code prioritizes and / or filters out certain keys in order to identify the keys for the target IoT device.

14. The method according to claim 13, wherein the mobile application program code is for filtering out keys for IoT devices already associated with the user's account on the IoT service.

15. The method according to claim 14, wherein the mobile application program code prioritizes the keys based on the measured signal strength of each of the BT advertising channels.

16. The method according to claim 9, wherein the mobile application program code causes the mobile device to listen to the BT advertising channel to extract the key only if the initial onboarding process is unavailable or unsuccessful.

17. It is a system, A key transmitted via a Bluetooth (BT) advertising channel, the key being associated with a model of the target Internet of Things (IoT) device, the target IoT device for transmitting the key, When installed on a mobile device, the mobile application program code causes the mobile device to listen to the BT advertising channel in order to extract the key, The system includes an IoT service that installs and / or updates a key dictionary on the mobile device, which is connected to the aforementioned mobile application program code and maps each of a plurality of keys to an IoT device model and associated data, The mobile application program code is a system that performs a lookup using the key extracted from the BT advertising channel to identify the target IoT device model and associated data, and uses the associated data, including a hyperlink or other address pointing to a device-specific onboarding instruction for registering the IoT device with a corresponding user account on the IoT service, for onboarding the target IoT device.

18. The system according to claim 17, wherein the related data is available to the mobile application program code to configure the target IoT device and to provide the user with instructions to add the IoT device to the user's account on the IoT service.

19. The system according to claim 18, wherein the related data comprises audio and / or video assets, text, and one or more network links for identifying video, audio, text, and / or images on the IoT service, to be provided to the user as the command.

20. The system according to claim 19, wherein the key dictionary is stored in JSON data format.

21. The system according to claim 18, wherein, when multiple keys are extracted from multiple BT advertising channels, the mobile application program code prioritizes and / or filters out certain keys in order to identify the keys for the target IoT device.

22. The system according to claim 21, wherein the mobile application program code is for filtering out keys for IoT devices already associated with the user's account on the IoT service.

23. The system according to claim 22, wherein the mobile application program code prioritizes the keys based on the measured signal strength of each of the BT advertising channels.

24. The system according to claim 17, wherein the mobile application program code causes the mobile device to listen to the BT advertising channel to extract the key only if the initial onboarding process is unavailable or unsuccessful.

Images