HK1247744B - System and method for automatic wireless network authentication - Google Patents

Description

System and method for automatic wireless network authentication

Technical Field

The present invention relates generally to the field of computer systems and, more particularly, to systems and methods for automatic wireless network authentication.

Background Art

The "Internet of Things" refers to the interconnection of uniquely identifiable embedded devices within the Internet infrastructure. Ultimately, the IoT is expected to lead to a wide range of new applications in which virtually any type of physical object can provide information about itself or its surroundings and/or be remotely controlled by a client device over the Internet.

When a user acquires a new WiFi-enabled device, such as a WiFi-enabled IoT device, a registration process must be performed between the new device and the user's home network. This process can be painful if the user doesn't remember their WiFi credentials or if the device is outside of WiFi coverage. Furthermore, registration will fail if the device is within the coverage edge of a WiFi network, as low coverage conditions will affect the registration process, causing the access point to deny the new device's registration. The problem is further compounded for users who have multiple WiFi networks within their home or workplace. In this case, each network requires its own registration process.

Finally, users cannot register new devices outside of their home or workplace, which hosts a private network. Consequently, original equipment manufacturers (OEMs) cannot ship devices to users that are already connected to a ready-to-use WiFi network.

Summary of the Invention

Embodiments of the present invention simplify the sharing of network credentials between devices. According to one embodiment of the present invention, a first Internet of Things (IoT) device sends a WiFi network key associated with a user's WiFi network to an IoT cloud service via a first secure communication channel. A second IoT device establishes a second secure communication channel with the IoT cloud service, the second secure communication channel comprising a first communication connection between the second IoT device and the first IoT device and a second communication connection between the first IoT device and the IoT cloud service. The second IoT device sends a request for the WiFi network key to the IoT cloud service via the second secure communication channel and receives the WiFi network key in response to the request. The second IoT device automatically uses the WiFi network key to establish a secure connection with the user's WiFi network.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood from the following detailed description in conjunction with the following drawings, in which:

Figures 1A and 1B illustrate different implementations of IoT system architectures;

FIG2 shows an IoT device according to an embodiment of the present invention;

FIG3 shows an IoT hub according to one embodiment of the present invention;

4A-4B illustrate an embodiment of the present invention for controlling and collecting data from IoT devices and generating notifications;

FIG5 illustrates an embodiment of the present invention for collecting data from IoT devices and generating notifications from an IoT hub and/or IoT service;

FIG6 illustrates an embodiment of the present invention implementing improved security techniques such as encryption and digital signatures;

FIG7 illustrates one embodiment of an architecture in which keys are stored on an IoT device using a Subscriber Identity Module (SIM);

FIG8A shows one embodiment of registering an IoT device using a barcode or QR code;

FIG8B shows an embodiment of pairing using a barcode or QR code;

FIG9 illustrates one embodiment of a method for programming a SIM using an IoT hub;

FIG10 illustrates one embodiment of a method for registering an IoT device using an IoT hub and an IoT service;

FIG11 illustrates one embodiment of a method for encrypting data to be transmitted to an IoT device;

FIG12 illustrates one embodiment of an architecture for collecting and storing network credentials;

FIG13 illustrates one embodiment of an architecture for registering a wireless access point with a user;

FIG14 illustrates one embodiment of a method for collecting and storing network credentials; and

FIG15 illustrates one embodiment of a method for registering a new device using stored credentials.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerous specific details are set forth herein to provide a thorough understanding of the embodiments of the present invention described below. However, those skilled in the art will readily appreciate 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 to avoid obscuring the underlying principles of the embodiments of the present invention.

One embodiment of the present invention includes an Internet of Things (IoT) platform that developers can use to design and build new IoT devices and applications. Specifically, one embodiment includes a basic hardware/software platform for IoT devices, which includes a predefined network protocol stack and an IoT hub through which the IoT devices connect to the Internet. In addition, one embodiment includes an IoT service through which the IoT hub and connected IoT devices can be accessed and managed as described below. In addition, one embodiment of the IoT platform includes an IoT application or web application (e.g., executed on a client device) for accessing and configuring the IoT service, hub, and connected devices. Existing online retailers and other website operators can use the IoT platform described herein to easily provide unique IoT functionality to their existing user base.

FIG1A illustrates an overview of an architectural platform upon which embodiments of the present invention may be implemented. Specifically, the illustrated embodiment includes a plurality of IoT devices 101-105 communicatively coupled to a central IoT hub 110 via local communication channels 130, which is itself communicatively coupled to an IoT service 120 via the Internet 220. Each of the IoT devices 101-105 may initially be paired with the IoT hub 110 (e.g., using the 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 each user's IoT device. For example, if the IoT devices include sensors (e.g., temperature sensors, accelerometers, thermal sensors, motion detectors, etc.), the database 122 may be continuously updated to store data collected by the IoT devices 101-105. The data stored in the database 122 may then be made accessible to end users and web clients (e.g., such as a website 130 subscribing to the IoT service 120) via an IoT application or browser installed on the user device 135 (or via a desktop or other client computer system).

IoT devices 101-105 can be equipped with various types of sensors to collect information about themselves and their surroundings, and provide this collected information to IoT services 120, user devices 135, and/or external websites 130 via IoT hub 110. Some of IoT devices 101-105 can perform designated functions in response to control commands sent through IoT hub 110. Various specific examples of information collected by IoT devices 101-105 and control commands are provided below. In one embodiment described below, IoT device 101 is a user input device designed to record user selections and transmit them to IoT services 120 and/or websites.

In one embodiment, the IoT hub 110 includes a cellular radio to establish a connection to the Internet 220 via a cellular service 115, such as a 4G (e.g., mobile WiMAX, LTE) or 5G cellular data service. Alternatively, or in addition, the IoT hub 110 can include a WiFi radio to establish a WiFi connection via a WiFi access point or router 116 that connects the IoT hub 110 to the Internet (e.g., via an Internet service provider that provides Internet service to end users). Of course, it should be noted that the underlying principles of the present invention are not limited to any particular type of communication channel or protocol.

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

As described above, in one embodiment, the IoT platform includes an IoT application or web application that executes on a user device 135 to allow a user to access and configure connected IoT devices 101 to 105, IoT hub 110, and/or IoT service 120. In one embodiment, the application or web application can be designed by the operator of the website 130 to provide IoT functionality to its user base. As shown, the website can maintain a user database 131 containing account records associated with each user.

FIG1B illustrates additional connectivity options for multiple IoT hubs 110 to 111, 190. In this embodiment, a single user can have multiple hubs 110 to 111 installed on-site at a single user premises 180 (e.g., the user's home or workplace). This can be done, for example, to extend the wireless range required to connect all IoT devices 101 to 105. As shown, if a user has multiple hubs 110, 111, they can be connected via local communication channels (e.g., Wi-Fi, Ethernet, powerline network, etc.). In one embodiment, each of the hubs 110 to 111 can establish a direct connection to the IoT service 120 via a cellular connection 115 or a WiFi connection 116 (not explicitly shown in FIG1B). Alternatively, or in addition, one of the IoT hubs, such as IoT hub 110, can act as a "master" hub, providing connectivity and/or local services to all other IoT hubs, such as IoT hub 111, at the user premises 180 (as indicated by the dashed line connecting IoT hub 110 and IoT hub 111). For example, the master IoT hub 110 can be the only IoT hub that establishes a direct connection with the IoT service 120. In one embodiment, only the "master" IoT hub 110 is equipped with a cellular communication interface to establish a connection with the IoT service 120. As such, all communications between the IoT service 120 and other IoT hubs 111 will flow through the master IoT hub 110. In this role, the master IoT hub 110 can have additional program code to perform filtering operations on the data exchanged between the other IoT hubs 111 and the IoT service 120 (e.g., to locally service some data requests when possible).

Regardless of how the IoT hubs 110-111 are connected, in one embodiment, the IoT service 120 will logically associate the hub with the user and combine all attached IoT devices 101-105 under a single comprehensive user interface (and/or browser-based interface) that can be accessed via a user device 135 that has the application installed.

In this embodiment, the master IoT hub 110 and one or more slave IoT hubs 111 can be connected via a local network, which can be a WiFi network 116, Ethernet, and/or a network using power line communication (PLC) (e.g., where all or part of the network runs through the user's power lines). In addition, each of the IoT devices 101 to 105 can interconnect with the IoT hubs 110 to 111 using any type of local network channel such as WiFi, Ethernet, PLC, or Bluetooth LE.

FIG1B also shows an IoT hub 190 installed at a second user premises 181. An almost unlimited number of such IoT hubs 190 can be installed and configured to collect data from IoT devices 191 to 192 at user premises around the world. In one embodiment, two user premises 180 to 181 can be configured for the same user. For example, one user premises 180 can be the user's primary residence, while the other user premises 181 can be the user's vacation home. In this case, the IoT service 120 logically associates the IoT hubs 110 to 111, 190 with the user and combines all attached IoT devices 101 to 105, 191 to 192 under a single comprehensive user interface (and/or browser-based interface) that can be accessed via the user device 135 with the application installed.

As shown in Figure 2, an exemplary embodiment of the IoT device 101 includes a memory 210 for storing program code and data 201 to 203, and a low-power microcontroller 200 for executing the program code and processing data. The memory 210 can be a volatile memory such as a dynamic random access memory (DRAM), or it can be a non-volatile memory such as a flash memory. In one embodiment, the non-volatile memory can be used for permanent storage, while the volatile memory can be used for executing the program code and data at runtime. In addition, the memory 210 can be integrated into the low-power microcontroller 200, or can be connected to the low-power microcontroller 200 via a bus or communication structure. The basic principles of the present invention are not limited to any specific implementation of the memory 210.

As shown, the program code may include application code 203, which defines a set of application-specific functions to be performed by IoT device 201, and library code 202, which includes a set of predefined building blocks that can be utilized by application developers of IoT device 101. In one embodiment, library code 202 includes a set of basic functions required to implement an IoT device, such as a communication protocol stack 201 for enabling communication between each of IoT devices 101 and IoT hub 110. As mentioned above, in one embodiment, communication protocol stack 201 includes a Bluetooth LE protocol stack. In this embodiment, the Bluetooth LE radio and antenna 207 may be integrated within low-power microcontroller 200. However, the underlying principles of the present invention are not limited to any particular communication protocol.

2 also includes a plurality of input devices or sensors 210 for receiving user input and providing the user input to the low-power microcontroller, which processes the user input according to the application code 203 and the library code 202. In one embodiment, each of the input devices includes an LED 209 for providing feedback to the end user.

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

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

In one embodiment, one or more additional/alternative I/O devices or sensors 250 may be included on the IoT device 101 based on the specific application for which the IoT device 101 is designed. For example, environmental sensors may be included to measure temperature, pressure, humidity, etc. If 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 underlying principles of the present invention are not limited to any particular type of IoT device. In fact, given the highly programmable nature of the low-power microcontroller 200 equipped with library code 202, application developers can easily develop new application code 203 and new I/O devices 250 to interact with the low-power microcontroller for virtually any type of IoT application.

In one embodiment, the low power microcontroller 200 also includes a secure keystore for storing cryptographic keys used to encrypt communications and/or generate signatures. Alternatively, the keys may be protected in a Subscriber Identity Module (SIM).

In one embodiment, a wake-up receiver 207 is included to wake the IoT device from an ultra-low-power state that consumes virtually 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, as shown in FIG3 , configured on the IoT hub 110. Specifically, in one embodiment, the transmitter 307 and the receiver 207 together form an electric resonant transformer circuit, such as a Tesla coil. In operation, when the hub 110 needs to wake the IoT device 101 from an extremely low-power state, energy is transferred from the transmitter 307 to the receiver 207 via a radio frequency signal. Due to this energy transfer, the IoT device 101 can be configured to consume virtually no power while in a low-power state, as it does not need to continuously "listen" for a signal from the hub (as is the case with network protocols that allow devices to be woken by network signals). More specifically, the microcontroller 200 of the IoT device 101 can be configured to wake up after being effectively powered down by using the energy electrically transferred from the transmitter 307 to the receiver 207.

As shown in Figure 3, IoT hub 110 also includes a memory 317 for storing program code and data 305, and a hardware logic part 301 such as a microcontroller for executing program code and processing data. Wide area network (WAN) interface 302 and antenna 310 connect IoT hub 110 to cellular service 115. Alternatively, as described above, IoT hub 110 may also include a local network interface (not shown), such as a WiFi interface (and WiFi antenna) or an Ethernet interface, for establishing a local area network communication channel. In one embodiment, hardware logic part 301 also includes a security key library for storing encryption keys for encrypted communication and generation/verification signatures. Alternatively, the key can be protected in a subscriber identity module (SIM).

Local communication interface 303 and antenna 311 establish a local communication channel with each of IoT devices 101 to 105. As described above, in one embodiment, local communication interface 303/antenna 311 implements the Bluetooth LE standard. However, the underlying principles of the present invention are not limited to any specific protocol for establishing local communication channels with IoT devices 101 to 105. Although shown as separate units in FIG3 , WAN interface 302 and/or local communication interface 303 can be embedded within the same chip as hardware logic 301.

In one embodiment, the program code and data include a communication protocol stack 308, which may include separate stacks for communicating over the local communication interface 303 and the WAN interface 302. In addition, device pairing program code and data 306 may be stored in memory to allow the IoT hub to pair with new IoT devices. In one embodiment, each new IoT device 101 to 105 is assigned a unique code that is transmitted to the IoT hub 110 during the pairing process. For example, the unique code may be embedded in a barcode on the IoT device and may be read by a barcode reader 106, or may be transmitted over a local communication channel 130. In an alternative embodiment, the unique ID code is magnetically embedded on 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.

In one embodiment, once the unique ID has been transmitted, the IoT hub 110 can verify the unique ID 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 to verify the ID code. In one embodiment, once verified, the IoT hub 110 pairs with the IoT device 101 and stores the pairing data in the memory 317 (which, as described above, may include non-volatile memory). Once pairing is complete, the IoT hub 110 can connect with the IoT device 101 to perform the various IoT functions described herein.

In one embodiment, the organization running the IoT service 120 can provide the IoT hub 110 and the basic hardware/software platform to allow developers to easily design new IoT services. Specifically, in addition to the IoT hub 110, a software development kit (SDK) can be provided for developers to update the program code and data 305 executed within the hub 110. Furthermore, for IoT devices 101, the SDK can include an extensive set of library code 202 designed for the underlying IoT hardware (e.g., the low-power microcontroller 200 and other components shown in FIG. 2 ) to facilitate the design of a variety of different types of applications 101. In one embodiment, the SDK includes a graphical design interface where developers only need to specify the inputs and outputs for the IoT device. All networking code is already prepared for the developer, including the communication stack 201 that allows the IoT device 101 to connect to the hub 110 and services 120. Furthermore, in one embodiment, the SDK also includes a library code base to facilitate the design of applications for mobile devices (e.g., iPhones and Android devices).

In one embodiment, the IoT hub 110 manages a continuous, bidirectional data flow between the IoT devices 101-105 and the IoT service 120. In situations where real-time updates to/from the IoT devices 101-105 are needed (e.g., where a user needs to view the current status of a security device or environmental reading), the IoT hub can maintain an open TCP socket to provide periodic updates to the user device 135 and/or the external website 130. The specific networking protocol used to provide updates can be tailored to the needs of the underlying application. For example, in some cases, where a continuous, bidirectional flow might not be meaningful, a simple request/response protocol can be used to collect information when needed.

In one embodiment, both the IoT hub 110 and the IoT devices 101-105 can be automatically upgraded over the network. Specifically, when a new update is available for the IoT hub 110, it can automatically download and install the update from the IoT service 120. It can first copy the updated code to local storage, run and verify the update, and then replace the older program code. Similarly, when an update is available for each of the IoT devices 101-105, the update can initially be downloaded by the IoT hub 110 and pushed to each of the IoT devices 101-105. Each IoT device 101-105 can then apply the update in a manner similar to that described above for the IoT hub and report the results of the update back to the IoT hub 110. If the update is successful, the IoT hub 110 can delete the update from its storage and record the latest code version installed on each IoT device (e.g., so that it can continue to check each IoT device for new updates).

In one embodiment, the IoT hub 110 is powered by an AC power source. Specifically, the IoT hub 110 may include a power supply unit 390 having a transformer, wherein the transformer is used to convert an AC voltage provided by an AC power line into a lower DC voltage.

FIG4A illustrates one embodiment of the present invention for performing universal remote control operations using an IoT system. Specifically, in this embodiment, a group of IoT devices 101 to 103 are each equipped with infrared (IR) and/or radio frequency (RF) transmitters 401 to 403 for transmitting remote control codes to control a variety of different types of electronic devices, including an air conditioner/heater 430, a lighting system 431, and audio-visual equipment 432, to name a few. In the embodiment shown in FIG4A , IoT devices 101 to 103 are also each equipped with sensors 404 to 406 for detecting the operation of the devices they control, as described below.

For example, the sensor 404 in the IoT device 101 may be a temperature and/or humidity sensor for sensing the current temperature/humidity, and responsively controlling 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 (typically a remote controller with an embedded temperature sensor). In one embodiment, a user provides the desired temperature to the IoT hub 110 via an application or browser installed on the user device 135. The control logic 412 executing on the IoT hub 110 receives the current temperature/humidity data from the sensor 404 and responsively transmits a command to the IoT device 101 to control the IR/RF transmitter 401 based on the desired temperature/humidity. For example, if the temperature is below the desired temperature, the control logic 412 may transmit a command to the air conditioner/heater via the IR/RF transmitter 401 to increase the temperature (e.g., by turning off the air conditioner or turning on the heater). This command may include the necessary remote control code stored in the database 413 on the IoT hub 110. Alternatively or additionally, the IoT service 421 may implement control logic 421 to control the electronic devices 430 - 432 based on specified user preferences and stored control codes 422 .

The IoT device 102 in the illustrated example is used to control lighting 431. Specifically, the sensor 405 in the IoT device 102 may be a photosensor or photodetector configured to detect the current brightness of light emitted by the lamp 431 (or other lighting device). A user may specify a desired lighting level (including an instruction to turn it on or off) to the IoT hub 110 via the user device 135. In response, the control logic 412 transmits a command to the IR/RF transmitter 402 to control the current brightness level of the lamp 431 (e.g., increase the lighting if the current brightness is too low, decrease the lighting if the current brightness is too high, or simply turn the lamp on or off).

The IoT device 103 in the illustrated example is configured to control an audio-visual device 432 (e.g., a television, an A/V receiver, a cable/satellite receiver, an AppleTV ^™ , etc.). The sensor 406 in the IoT device 103 can be an audio sensor (e.g., a microphone and associated logic) for detecting the current ambient volume level and/or can be a photosensor that detects whether the television is on or off based on the light generated by the television (e.g., by measuring light within a specific spectrum). Alternatively, the sensor 406 can include a temperature sensor connected to the audio-visual device to detect 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 can transmit commands to the audio-visual device via the infrared transmitter 403 of the IoT device 103.

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

In an embodiment where the IoT devices 101 to 103 are connected to the IoT hub 110 via a Bluetooth LE connection, sensor data and commands are sent via the Bluetooth LE channel. However, the underlying principles of the present invention are not limited to Bluetooth LE or any other communication standard.

In one embodiment, the control code required to control each electronic device is stored in a database 413 on the IoT hub 110 and/or a database 422 on the IoT service 120. As shown in Figure 4B, the control code can be provided to the IoT hub 110 from a master database 422 of control codes for different devices maintained on the IoT service 120. The end user can specify the type of electronic (or other) device to be controlled through an application or browser executed on the user device 135, and in response, the remote control code learning module 491 on the IoT hub can retrieve the required IR/RF code from the remote control code database 492 on the IoT service 120 (e.g., which identifies each electronic device with a unique ID).

In addition, in one embodiment, the IoT hub 110 is equipped with an IR/RF interface 490 to allow the remote control code learning module 491 to "learn" new remote control codes directly from the original remote control 495 provided with the electronic device. For example, if the remote control database does not include the control codes for the original remote control provided with the air conditioner 430, the user can interact with the IoT hub 110 via an application/browser on the user device 135 to teach the IoT hub 110 various control codes generated by the original remote control (e.g., increase temperature, decrease temperature, etc.). Once the remote control codes are learned, they can be stored in the control code database 413 on the IoT hub 110 and/or sent back to the IoT service 120 to be included in the central remote control code database 492 (and subsequently used by other users with the same air conditioner unit 430).

In one embodiment, each of the IoT devices 101 to 103 has a very small form factor and can be attached to or near its respective electronic device 430 to 432 using double-sided tape, small nails, magnetic attachments, etc. To control a device such as an air conditioner 430, it is desirable to place the IoT device 101 far enough away so that the sensor 404 can accurately measure the ambient temperature of the home (e.g., placing the IoT device directly on the air conditioner will result in a temperature measurement that is too low when the air conditioner is running and too high when the heater is running). Conversely, the IoT device 102 for controlling lighting can be placed on or near the lighting fixture 431 so that the current lighting level can be detected by the sensor 405.

In addition to providing the general control functionality described, one embodiment of the IoT hub 110 and/or IoT service 120 transmits notifications to the end user regarding the current status of each electronic device. These notifications can then be displayed on the display of the user's mobile device 135 and can be text messages and/or application-specific notifications. For example, if the user's air conditioner has been on for a period of time but the temperature has not changed, the IoT hub 110 and/or IoT service 120 can send a notification to the user that the air conditioner is not working properly. If the user is not at home (this can be detected by a motion sensor or based on the user's current location detected), and the sensor 406 indicates that the audio-visual device 430 is on, or the sensor 405 indicator light is on, a notification can be sent to the user asking whether the user wants to turn off the audio-visual device 432 and/or the light 431. The same type of notification can be sent to any device type.

Once the user receives the notification, he/she can 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 touchscreen device, and the application or browser displays a graphic remote control with user-selectable buttons for controlling the devices 430-432. Upon receiving the notification, the user can open the graphical remote control and turn off or adjust various devices. If connected via the IoT service 120, the user's selections can be forwarded from the IoT service 120 to the IoT hub 110, which will then control the devices via the control logic 412. Alternatively, user input can be sent directly from the user device 135 to the IoT hub 110.

In one embodiment, a user can program the control logic 412 on the IoT hub 110 to perform various automatic control functions with respect to the electronic devices 430 to 432. In addition to maintaining a desired temperature, light level, and volume level as described above, the control logic 412 can automatically shut down the electronic devices if certain conditions are detected. For example, if the control logic 412 detects that the user is not home and the air conditioner is not functioning, it can automatically shut down the air conditioner. Similarly, if the user is not home and the sensor 406 indicates that the audio-visual device 430 is on, or the sensor 405 indicates that the indicator light is on, the control logic 412 can automatically transmit commands via the IR/RF transmitters 403 and 402 to shut down the audio-visual device and the lights, respectively.

FIG5 illustrates an additional embodiment of IoT devices 104-105 equipped with sensors 503-504 for monitoring electronic devices 530-531. Specifically, the IoT device 104 of this embodiment includes a temperature sensor 503, which can be placed on or near a stove 530 to detect when the stove is turned on and left idle. In one embodiment, the IoT device 104 transmits the current temperature measured by the temperature sensor 503 to the IoT hub 110 and/or the IoT service 120. If the stove is detected to be on for more than a threshold period of time (e.g., based on the measured temperature), the control logic 512 can transmit a notification to the end user's device 135 informing the user that the stove 530 is on. Furthermore, in one embodiment, the IoT device 104 can include a control module 501 to shut off the stove in response to a command from the user or automatically (if the control logic 512 is programmed by the user to do so). In one embodiment, the control logic 501 includes a switch for shutting off the electricity or gas to the stove 530. However, in other embodiments, the control logic 501 may be integrated into the fire itself.

FIG5 also shows an IoT device 105 having a motion sensor 504 for detecting motion of certain types of electronic devices such as washing machines and/or dryers. Another sensor that can be used is an audio sensor (e.g., a microphone and logic) for detecting ambient volume levels. As with the other embodiments described above, this embodiment can transmit a notification to the end user if certain conditions are met (e.g., if motion is detected for a long time, indicating that the washer/dryer is not turned off). Although not shown in FIG5 , the IoT device 105 can also be equipped with a control module to automatically and/or in response to user input (e.g., by turning off electricity/gas) turn off the washer/dryer 531.

In one embodiment, a first IoT device having control logic and a switch may be configured to turn off all electricity in a user's home, and a second IoT device having control logic and a switch may be configured to turn off all gas in a user's home. The IoT devices having sensors may then be positioned on or near electronic or gas-operated equipment in the user's home. If a user is notified that a particular device has been left on and idle (e.g., a furnace 530), the user can send a command to turn off all electricity or gas in the home to prevent damage. Alternatively, the control logic 512 in the IoT hub 110 and/or IoT service 120 may be configured to automatically turn off electricity or gas in such circumstances.

In one embodiment, the IoT hub 110 and the IoT service 120 communicate at periodic intervals. If the IoT service 120 detects that it has lost connectivity with the IoT hub 110 (e.g., by failing to receive a request or response from the IoT hub within a specified duration), it communicates this information to the end user's device 135 (e.g., by sending a text message or application-specific notification).

Improved security implementation scheme

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 secure key storage for storing encryption keys used by the embodiments described below (see, e.g., Figures 6-11 and associated text). Alternatively, the keys can be protected in a subscriber identity module (SIM) as described below.

6 illustrates a high-level architecture for encrypting communications between the IoT service 120 , the IoT hub 110 , and the IoT devices 101 - 102 using public key infrastructure (PKI) techniques and/or symmetric key exchange/encryption techniques.

First, an embodiment using a public/private key pair will be described, followed by an embodiment using symmetric key exchange/encryption technology. Specifically, in an embodiment using PKI, a unique public/private key pair is associated with each IoT device 101 to 102, each IoT hub 110, and IoT service 120. In one embodiment, when a new IoT hub 110 is established, its public key is provided to the IoT service 120, and when a new IoT device 101 is established, 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 are described below. In one embodiment, all public keys are signed by a master key (i.e., in the form of a certificate) known to all receiving devices, so that any receiving device can verify the validity of the public key by verifying the signature. Therefore, these certificates will be exchanged, rather than just exchanging the original public keys.

As shown, in one embodiment, each IoT device 101, 102 includes a secure key storage device 601, 603, respectively, for securely storing each device's private key. Security logic 602, 1304 then utilizes the securely stored private keys to perform the encryption/decryption operations described herein. Similarly, the IoT hub 110 includes a secure storage device 611 for storing the IoT hub's private key and the public keys of the IoT devices 101-102 and IoT service 120; as well as security logic 612 for performing encryption/decryption operations using the keys. Finally, the IoT service 120 may include a secure storage device 621 for securely storing its own private key, the public keys of various IoT devices, and the IoT hub; and security logic 613 for using the keys to encrypt/decrypt communications with the IoT hub and devices. In one embodiment, when the IoT hub 110 receives a public key certificate from an IoT device, it can verify the certificate (e.g., by verifying the signature using the master key as described above), then extract the public key from it and store it in its secure key storage device 611.

For example, in one embodiment, when the IoT service 120 needs to transmit a command or data to the IoT device 101 (e.g., a command to unlock a door, a request to read a sensor, data to be processed/displayed by the IoT device, etc.), the security logic 613 encrypts the data/command using the public key of the IoT device 101 to generate an encrypted IoT device packet. In one embodiment, it then encrypts the IoT device packet using the public key of the IoT hub 110 to generate an IoT hub packet and transmits 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 master key mentioned above, allowing the device 101 to verify that it is receiving the unaltered message from a trusted source. The device 101 can then verify the signature using the public key corresponding to the private key and/or master key. As described above, symmetric key exchange/encryption techniques can be used instead of public/private key encryption. In these embodiments, rather than privately storing one key and providing the corresponding public key to other devices, each device can be provided with a copy of the same symmetric key used to encrypt and verify the signature. One example of a symmetric key algorithm is the Advanced Encryption Standard (AES), but the underlying principles of the invention are not limited to any type of specific symmetric key.

In a specific implementation using symmetric keys, each device 101 enters into 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 (e.g., see Request for Comments (RFC) 6063). However, the underlying principles of the present invention are not limited to any particular key provisioning protocol.

Once the symmetric 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 periodically exchanged between the device 101 and the hub 110, and between the hub 110 and the IoT service 120. In one embodiment, new symmetric keys are exchanged with each new communication session between the device 101, the hub 110, and the service 120 (e.g., new keys are generated and securely exchanged for each communication session). In one embodiment, if the IoT hub's security module 612 is trusted, the service 120 can negotiate a session key with the hub security module 1312, which will then negotiate a session key with each device 120. Messages from the service 120 are then decrypted and verified in the hub security module 612 before being re-encrypted for transmission to the device 101.

In one embodiment, to prevent compromise of the hub security module 612, a one-time (permanent) installation key can be negotiated between the device 101 and the service 120 at installation time. When sending a message to the device 101, the service 120 can first encrypt/MAC it with the device installation key, and then encrypt/MAC it with the hub's session key. The hub 110 will then verify and extract the encrypted device blob and send it to the device.

In one embodiment of the present invention, a counting mechanism is implemented to prevent replay attacks. For example, a continuously increasing counter value can be assigned to each successive communication from device 101 to device 110 (or vice versa). Both the center 110 and the device 101 will track this value and verify whether the value is correct in each successive communication between the devices. The same technology can be implemented between the center 110 and the service 120. Using a counter in this way will make it more difficult to spoof the communication between each device (because the counter value will be incorrect). However, even if this is not the case, the shared installation key between the service and the device will prevent a network (center)-wide attack on all devices.

In one embodiment, when public/private key encryption is used, the IoT hub 110 uses its private key to decrypt the IoT hub packet and generate an encrypted IoT device packet, which is transmitted to the associated IoT device 101. The IoT device 101 then uses its private key to decrypt the IoT device packet to generate the command/data originating from the IoT service 120. It can then process the data and/or execute the command. By using symmetric encryption, each device will encrypt and decrypt using a shared symmetric key. In either case, each transmitting device can also sign the message using its private key so that the receiving device can verify its authenticity.

Different sets of keys can be used to encrypt communications from the IoT device 101 to the IoT hub 110 and the IoT service 120. For example, in one embodiment, using a public/private key arrangement, the security logic 602 on the IoT device 101 encrypts data packets sent to the IoT hub 110 using the public key of the IoT hub 110. The security logic 612 on the IoT hub 110 can then decrypt the data packets using the private key of the IoT hub. Similarly, the security logic 602 on the IoT device 101 and/or the security logic 612 on the IoT hub 110 can encrypt data packets sent to the IoT service 120 using the public key of the IoT service 120 (which can then be decrypted by the security logic 613 on the IoT service 120 using the private key of the service). By using symmetric keys, the device 101 and the hub 110 can share a symmetric key, while the hub and the service 120 can share different symmetric keys.

While certain specific details have been set forth in the description above, it should be noted that the basic principles of the present invention can be implemented using a variety of different encryption techniques. For example, while some of the embodiments discussed above use asymmetric public/private key pairs, alternative embodiments may use symmetric keys securely exchanged between the various IoT devices 101 to 102, the IoT hub 110, and the IoT service 120. Furthermore, 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). The recipient can then use its key to verify the signature.

As shown in Figure 7, in one embodiment, secure key storage on each IoT device 101 is implemented using a programmable subscriber identity module (SIM) 701. In this embodiment, the IoT device 101 can initially be provided to the end user using an unprogrammed SIM card 701 positioned within the SIM interface 700 on the IoT device 101. To program the SIM card with a set of one or more cryptographic keys, the user removes the programmable SIM card 701 from the SIM interface 500 and inserts it into the SIM programming interface 702 on the IoT hub 110. The programming logic 725 on the IoT hub then securely programs the SIM card 701 to register/pair the IoT device 101 with the IoT hub 110 and the IoT service 120. In one embodiment, a public/private key pair can be randomly generated by the programming logic 725, and the public key of the key pair can then be stored in the IoT hub's secure storage 411, while the private key can be stored in the programmable SIM 701. In addition, the programming logic 525 can store the public keys of the IoT hub 110, IoT service 120, and/or any other IoT device 101 on the SIM card 601 (for use by the security logic 1302 on the IoT device 101 to encrypt outgoing data). Once the SIM 701 is programmed, a new IoT device 101 can be configured by the IoT service 120 using the SIM as a security identifier (e.g., using existing techniques to register devices using the SIM). After provisioning, the IoT hub 110 and IoT service 120 will securely store a copy of the IoT device's public key for use when encrypting communications with the IoT device 101.

The technology described above in conjunction with FIG. 7 provides tremendous flexibility when providing new IoT devices to end users. Rather than requiring users to register each SIM card directly with a specific service provider at the time of sale/purchase (as is currently done), the SIM card can be programmed directly by the end user through the IoT hub 110, and the programming results can be securely transmitted to the IoT service 120. Thus, a new IoT device 101 can be sold to an end user by an online or local retailer and then securely pre-configured with the IoT service 120.

While the registration and encryption techniques are described in the specific context of a SIM (Subscriber Identity Module), the underlying principles of the present invention are not limited to "SIM" devices. Rather, the underlying principles of the present invention can be implemented using any type of device that has a secure storage device for storing a set of encryption keys. Furthermore, while the above embodiments include a removable SIM device, in one embodiment, the SIM device is not removable, and the IoT device itself can be plugged into the programming interface 702 of the IoT hub 110.

In one embodiment, rather than requiring the user to program the SIM (or other device) prior to distribution to an end user, the SIM is pre-programmed into the IoT device 101. In this embodiment, when the user sets up the IoT device 101, encryption keys can be securely exchanged between the IoT hub 110/IoT service 120 and the new IoT device 101 using the various techniques described herein.

For example, as shown in FIG8A , each IoT device 101 or SIM 401 can be encapsulated with a barcode or QR code 701 that uniquely identifies the IoT device 101 and/or SIM 701. In one embodiment, the barcode or QR code 801 includes an encoded representation of the public key for the IoT device 101 or SIM 1001. Alternatively, the barcode or QR code 801 can be used by the IoT hub 110 and/or IoT service 120 to identify or generate a public key (e.g., as a pointer to a public key already stored in secure memory). The barcode or QR code 601 can be printed on a separate card (as shown in FIG8A ) or printed directly on the IoT device itself. Regardless of where the barcode is printed, in one embodiment, the IoT hub 110 is equipped with a barcode reader 206 for reading the barcode and providing the resulting data to the secure logic 1012 on the IoT hub 110 and/or the secure logic 1013 on the IoT service 120. The secure logic 1012 on the IoT hub 110 may then store the IoT device's public key in its secure key storage 1011 , and the secure logic 1013 on the IoT service 120 may store the public key in its secure storage 1021 (for subsequent encrypted communications).

In one embodiment, the data contained in the barcode or QR code 801 can also be captured by a user device 135 (e.g., such as an iPhone or Android device) through an installed IoT application or a browser-based applet designed by an IoT service provider. Once captured, the barcode data can be securely transmitted to the IoT service 120 via a secure connection (e.g., such as a Secure Sockets Layer (SSL) connection). The barcode data can also be provided from the client device 135 to the IoT hub 110 via a secure local connection (e.g., via a local WiFi or Bluetooth LE connection).

The security logic 1002 on the IoT device 101 and the security logic 1012 on the IoT hub 110 can be implemented using hardware, software, firmware, or any combination thereof. For example, in one embodiment, the security logic 1002, 1012 is implemented within a chip used to establish a local communication channel 130 between the IoT device 101 and the IoT hub 110 (e.g., a Bluetooth LE chip if the local channel 130 is Bluetooth LE). Regardless of the specific location of the security logic 1002, 1012, in one embodiment, the security logic 1002, 1012 is designed to establish a secure execution environment for executing certain types of program code. This can be achieved, for example, using TrustZone technology (available on some ARM processors) and/or trusted execution technology (designed by Intel). Of course, the underlying principles of the present invention are not limited to any particular type of secure execution technology.

In one embodiment, the barcode or QR code 701 can be used to pair each IoT device 101 with the IoT hub 110. For example, the pairing code embedded within the barcode or QR code 701 can be provided to the IoT hub 110 to pair the IoT hub with the corresponding IoT device, rather than using the standard wireless pairing method currently used to pair Bluetooth LE devices.

Figure 8B illustrates an embodiment in which the barcode reader 206 on the IoT hub 110 captures a barcode/QR code 801 associated with the IoT device 101. As described above, the barcode/QR code 801 can be printed directly on the IoT device 101 or printed on a separate card provided with the IoT device 101. In either case, the barcode reader 206 reads a pairing code from the barcode/QR code 801 and provides it to the local communication module 880. In one embodiment, the local communication module 880 is a Bluetooth LE chip and associated software, but the underlying principles of the present invention are not limited to any particular protocol standard. Once the pairing code is received, it is stored in a secure storage device containing pairing data 885, and the IoT device 101 and IoT hub 110 are automatically paired. Each time the IoT hub pairs with a new IoT device in this manner, the pairing data for that pairing is stored in the secure storage device 685. In one embodiment, once the local communication module 880 of the IoT hub 110 receives the pairing code, it may use the code as a key to encrypt communications with the IoT device 101 over the local wireless channel.

Similarly, on the IoT device 101 side, the local communication module 890 stores pairing data indicating pairing with the IoT hub in the local secure storage device 895. The pairing data 895 may include a pre-programmed pairing code identified in the barcode/QR code 801. The pairing data 895 may also include pairing data required to establish a secure local communication channel (e.g., additional keys for encrypting communications with the IoT hub 110) received from the local communication module 880 on the IoT hub 110.

Thus, the barcode/QR code 801 can be used to perform local pairing in a much more secure manner than current wireless pairing protocols because the pairing code is not transmitted wirelessly. Furthermore, in one embodiment, the same barcode/QR code 801 used for pairing can be used to identify encryption keys to establish secure connections from the IoT device 101 to the IoT hub 110 and from the IoT hub 110 to the IoT service 120.

Figure 9 shows a method for programming a SIM card according to an embodiment of the present invention. The method can be implemented within the above system architecture, but is not limited to any specific system architecture.

At 901, a user receives a new IoT device with a blank SIM card, and at 802, the user inserts the blank SIM card into the IoT hub. At 903, the user programs the blank SIM card with a set of one or more encryption keys. For example, as described above, in one embodiment, the IoT hub can randomly generate a public/private key pair and store the private key on the SIM card and the public key in its local secure storage. In addition, at 904, at least the public key is transmitted 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 can be used to perform the same functions as the SIM card in the method shown in Figure 9.

Figure 10 shows a method for integrating a new IoT device into a network. This method can be implemented within the above system architecture, but is not limited to any particular system architecture.

At 1001, a user receives a new IoT device with a pre-assigned encryption key. At 1002, the 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 can be read directly by the IoT hub or captured via a mobile device through an app or browser. In alternative embodiments, a secure communication channel, such as a Bluetooth LE channel, a Near Field Communication (NFC) channel, or a secure WiFi channel, can be established between the IoT device and the IoT hub to exchange the key. Regardless of how the key is transmitted, once received, it will be stored in the IoT hub device's secure keystore. As described above, various secure execution technologies can be used on the IoT hub to store and protect the key, such as Secure Enclaves, Trusted Execution Technology (TXT), and/or Trustzone. Furthermore, at 1003, the key is securely transmitted to the IoT service, which stores the key in its own secure keystore. This key can then be used to encrypt communications with the IoT device. Again, this exchange can be achieved using certificates/signature keys. Within the center 110, it is particularly important to prevent modification/addition/deletion of stored keys.

Figure 11 shows a method for securely transmitting commands/data to IoT devices using public/private keys. This method can be implemented within the above system architecture, but is not limited to any specific system architecture.

At 1101, the IoT service encrypts the data/command using the IoT device public key to create an IoT device group. It then encrypts the IoT device group using the IoT hub's public key to create an IoT hub group (e.g., creating an IoT hub wrapper around the IoT device group). At 1102, the IoT service transmits the IoT hub group to the IoT hub. At 1103, the IoT hub decrypts the IoT hub group using the IoT hub's private key to generate an IoT device group. Then, at 1104, it transmits the IoT device group to the IoT device, which decrypts the IoT device group using the IoT device private key at 1105 to generate the data/command. At 1106, the IoT device processes the data/command.

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

Implementation Plan for Automatic Wireless Network Authentication

In order to connect the IoT hub to a local wireless network, such as a WiFi network, the user must provide network credentials, such as a network security key or password. Other layers of authentication may also be required, such as a user ID/password combination. In one embodiment, once the IoT hub successfully connects to the local wireless network using the network credentials provided by the user, it securely transmits the network credentials to a secure storage location, such as the IoT service 120. When the user subsequently receives a new IoT device, the IoT device may be configured to transmit a network credential request to the IoT hub. In response, the IoT hub may forward the request to the IoT service 120, which may perform a lookup in a credential database using, for example, the identity of the IoT device, the user, and/or the access point to which the connection is required to identify the relevant network credentials. If the network credentials can be identified, they are transmitted back to the IoT device, which then seamlessly connects to the local wireless network using the network credentials.

FIG12 illustrates an exemplary system architecture in which a credential management module 1210 on an IoT hub 1202 implements the credential handling techniques described herein. As shown, a user can provide network credentials, such as a network security key or password, to the IoT hub 1202 via a user device 135 (which can be a mobile smartphone device, a wearable data processing device, a laptop computer, or a desktop computer). The user device 135 initially connects to the IoT hub 1202 via a wired connection or a short-range wireless connection such as BTLE, and the user provides the credentials via an application or browser configured to connect to the IoT hub 1202.

In one embodiment, the network credentials include a security key, such as Wi-Fi Protected Access (WPA) or Wi-Fi Protected Access II (WPA2). In this embodiment, the network credentials may be in the form of a pre-shared key (PSK) for a WPA-Personal implementation, or may rely on more advanced authentication techniques, such as those used by WPA-Enterprise (which may utilize a RADIUS authentication server and various forms of the Extensible Authentication Protocol (EAP)).

Regardless of the specific authentication/encryption technology used, once the user provides the necessary network credentials, the IoT hub 1202 uses the credentials to establish a secure wireless connection with the WiFi access point/router 1200, which then provides a connection to the cloud service 1220 via the Internet 1222. In one embodiment, the credential management module 1210 on the IoT hub 1210 establishes a connection with the credential management module 1215 on the cloud service 1220 (e.g., which can be the IoT service 120 described above or the external website 130).

In one embodiment, one or more of the key-based techniques described above can be employed to ensure that the connection between the credential management module 1210 on the IoT hub 1202 and the credential management module 1215 on the cloud service 1220 is secure (e.g., encrypting all network traffic using symmetric or asymmetric keys). Once a secure connection is established, the credential management module 1210 on the IoT hub 1202 transmits a copy of the network credentials to the credential management module 1215 on the cloud service, which stores the copy of the credentials in a secure credential database 1230. The credential database 1230 can include data that uniquely identifies the IoT hub 1202, data that uniquely identifies a user account associated with the IoT hub 1202, and/or data that uniquely identifies the WiFi access point/router 1200 (to ensure that the network credentials are associated with the correct user and WiFi access point/router).

As shown in FIG13 , after the network credentials are stored in the credentials database 1230 , when a user purchases a new IoT device 1300, the IoT device will enable its local wireless interface (e.g., BTLE) and search for any enabled devices within range (e.g., the IoT hub 1202 , other IoT devices, or the user's mobile device). In the specific embodiment shown in FIG13 , the IoT device 1300 has been detected and connected to the IoT hub 1202 . In one embodiment, once the connection is established, the network registration module 1310 transmits a network credential request to the credential management module 1210 on the IoT hub 1202 . The credential request may include data identifying the Wi-Fi access point/router 1200 to which the IoT device 1300 will connect (e.g., an SSID, MAC address, or other data uniquely identifying the Wi-Fi access point/router 1200 ) as well as data uniquely identifying the IoT device 1300 .

The credential management module 1210 then securely transmits the credential management request to the credential management module 1215 on the cloud service 1220. The credential management module on the cloud service uses data uniquely identifying the user, the IoT device 1300, and/or the WiFi access point/router 1200 to perform a lookup in the credential database 1230. Again, any key-based security technique can be used to ensure the connection between the IoT hub and the cloud service is secure. If the credentials are found based on the data provided in the request, the credential management module 1215 securely transmits the network credentials back to the credential management module 1210 on the IoT hub 1202, which then provides the network credentials to the network registration module 1310 of the IoT device 1300. The IoT device 1300 then automatically establishes a secure connection with the WiFi access point/router 1200 using the network credentials. The end result is that the user does not need to manually configure a new IoT device 1300 to connect to the WiFi access point/router 1200. Instead, because the network credentials are already associated with the user's account on the cloud service 1220, they are automatically provided to the IoT device 1300, which then seamlessly connects to the network.

As described above, although FIG13 shows the IoT device 1300 connected via the IoT hub 1202, if the IoT hub 1202 is not in range, the IoT device 1300 can connect to another IoT device. The other IoT device (which is connected to the IoT hub) can then connect the new IoT device to the credential management module 1210 on the IoT hub 1202. Similarly, if neither the IoT hub nor the other IoT is available (e.g., out of range), the IoT device 1300 can be configured to connect to the user's mobile device 135, which may include a browser/application for connecting to the credential management module 1215 on the cloud service (either directly or through the IoT hub 1202).

In one embodiment, the network registration module 1310 on the IoT hub 1300 is configured to first search for the IoT hub 1202, then search for another IoT device, and then search for the user's mobile device. It will then connect to the first of these devices to provide a connection. This connection can be established using any type of local communication protocol, including but not limited to BTLE.

In one embodiment, the network credentials can be stored locally in a secure storage device accessible to or contained within the IoT hub 1202 (in addition to or instead of storing the network credentials remotely on the cloud service 1220). Therefore, in this embodiment, the network credentials can be provided without requiring a remote query to the cloud service 1220.

The terms "cloud service" and "IoT cloud service" can refer to any service on the Internet that can store and provide network credentials for IoT devices as described herein (e.g., the IoT services and external services referenced above). In one embodiment, cloud service 1220 is owned and operated by the same entity that provides the IoT hub and IoT devices to end users. In another embodiment, at least some IoT devices can be designed and sold by OEMs that coordinate with the cloud service (e.g., through an agreed-upon business arrangement) to ensure that the techniques described herein can be implemented using cloud service 1220.

Figure 14 shows a method for collecting and storing network credentials according to one embodiment of the present invention. The method can be implemented within the context of the above system architecture, but is not limited to any particular architecture.

At 1401, a user provides network credentials to the IoT hub. The credentials can be provided, for example, through a network setup wizard executed within a browser or application installed on the user's data processing device, which can connect to the IoT hub via a wired or local wireless connection (e.g., BTLE). Once the network credentials are provided, at 1402, the IoT hub establishes a secure connection with the IoT cloud service over the Internet and, at 1403, securely transmits the network credentials to the IoT cloud service. At 1404, the IoT cloud service stores the network credentials in its database, associating the credentials with the user's account on the IoT cloud service and/or with the specific WiFi access point/router at which the network credentials are being used.

Figure 15 shows a method for seamlessly updating new IoT devices using stored network credentials according to one embodiment of the present invention. The method can be implemented within the context of the above system architecture, but is not limited to any particular architecture.

At 1501, a user receives a new IoT device. The IoT device may have been ordered from an IoT cloud service and/or from an OEM associated with the IoT cloud service. In either case, the new IoT device is associated with the account of the user who received the new IoT device.

At 1502, when a new IoT device is turned on, it initially searches for a local IoT hub. As described above, the search can be performed using a local wireless protocol such as BTLE. If the IoT hub cannot be found (e.g., because it is out of range), another IoT device and/or the end user's mobile device (on which an application or browser is installed to enable connection to the IoT cloud service) can be searched.

At 1503, it is determined whether the new IoT device has detected the presence of an IoT hub, another IoT device, or the user's mobile device. If an IoT hub is detected, then at 1504, the new IoT device connects to the IoT hub, and at 1505, the IoT hub retrieves network credentials for the new IoT device from the cloud service and provides the credentials to the new IoT device. At 1510, the new IoT device registers with the wireless network using the network credentials.

If the new IoT device detects another IoT device, it connects to the other IoT device at 1506, and at 1507, the IoT device retrieves the network credentials from the IoT cloud service and provides the credentials to the new IoT device. In one embodiment, this can be achieved through the IoT hub (i.e., if the other device is connected to the IoT hub). Again, at 1510, the new IoT device registers with the wireless network using the network credentials.

If the new IoT device detects the user's mobile device, it connects to the mobile device at 1508. In one embodiment, the connection is managed by an application on the user's mobile device, such as a connection wizard or browser executable code. At 1509, the IoT device retrieves the network credentials from the IoT cloud service and provides them to the new IoT device. In one embodiment, this can be accomplished through an IoT hub (i.e., if another device is connected to the IoT hub). At 1510, the new IoT device registers with the wireless network using the network credentials.

As described above, in one embodiment, the network registration module 1310 executed on the new mobile device utilizes a connection priority scheme to determine the order in which devices should be searched when turned on. In one embodiment, the IoT hub will be searched initially, and if one cannot be found, other IoT devices will be searched. If no device is available, an attempt will be made to connect to the user's mobile device. Alternatively, the new IoT device may only connect to the first device it is located at and/or may connect to the device with the highest signal strength (i.e., RSSI value) it finds. Various other connection techniques may be programmed into the network registration module 1310 while still complying with the basic principles of the invention.

Embodiments of the present invention may include the various steps described above. These steps may be embodied as machine-executable instructions that can be used to cause a general-purpose processor or a special-purpose processor to perform these steps. Alternatively, these steps may be performed by specific hardware components that contain hard-wired logic for performing these steps, or by any combination of programmed computer components and custom hardware components.

As described herein, instructions may refer to a specific hardware configuration, such as an application-specific integrated circuit (ASIC), that is configured to perform certain specific operations or have predetermined functions or software instructions stored in a memory embodied in a non-transitory computer-readable medium. Thus, the techniques shown in the accompanying figures can 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-readable media to store and transmit (internally and/or with other electronic devices on a network) code and data, such as non-transitory computer-readable storage media (e.g., magnetic disks; optical disks; random access memory; read-only memory; flash memory storage devices; phase-change memory) and transient computer-readable communication media (e.g., electrical, optical, acoustic, or other forms of propagated signals - such as carrier waves, infrared signals, digital signals, etc.). In addition, such electronic devices typically include a collection of one or more processors connected 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., keyboards, touch screens, and/or displays), and network connections. The connection between the processor set and other components is typically carried out through one or more buses and bridges (also referred to as bus controllers). The storage device and the signal carrying network traffic represent one or more machine-readable storage media and machine-readable communication media, respectively. Therefore, the storage device of a given electronic device typically stores the code and/or data for execution on the set of one or more processors of the electronic device. Of course, different combinations of software, firmware and/or hardware can be used to implement one or more parts of the embodiments of the present invention.

Throughout this detailed description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the present invention. However, those skilled in the art will readily appreciate that the present invention can be practiced without some of these specific details. In some instances, well-known structures and functions have not been described in detail to avoid obscuring the subject matter of the present invention. Accordingly, the scope and spirit of the present invention should be determined in accordance with the appended claims.

Claims (31)

1. A method for sharing network credentials between devices, comprising: Maintaining secure connections between IoT cloud services and multiple IoT devices and IoT applications installed on end users’ mobile devices; establishing a first secure communication channel between the IoT cloud service and a first IoT device of a first user or an IoT application installed on a mobile device of the first user; securely transmitting a first WiFi network key associated with the first user's WiFi network from the first IoT device or the IoT application installed on the mobile device to the IoT cloud service; establishing a second secure communication channel between a second IoT device and the IoT cloud service via the IoT application installed on the mobile device or via the first IoT device, the second secure communication channel comprising a first communication connection between the second IoT device and the first IoT device or the mobile device, the first communication connection utilizing a first wireless communication protocol different from a second wireless communication protocol used by the WiFi network, the first IoT device or the mobile device establishing the first communication connection with the second IoT device using the first wireless communication protocol and simultaneously establishing a second communication connection with the WiFi network using the second wireless communication protocol, the second IoT device establishing the second secure communication channel with the IoT cloud service using the first communication connection and the second communication connection; and sending a request for the first WiFi network key available on the WiFi network of the first user, the IoT cloud service associating the second IoT device with the account of the first user and sending the first WiFi network key to the second IoT device via the IoT application installed on the mobile device of the first user or via the first IoT device, the first WiFi network key being transferred via the first communication connection and the second communication connection; and The second IoT device establishes a secure connection on the first user's WiFi network using the first WiFi network key. 2. The method according to claim 1, further comprising: Securely storing WiFi network keys of different users' WiFi networks including the first WiFi network key in a secure database maintained at the IoT cloud service, wherein the WiFi network keys are received from the IoT device, an IoT application installed on the user's mobile device, or an IoT hub. 3. The method of claim 2 , wherein the IoT cloud service receives a request for the first WiFi network key from the first user's IoT hub, the first IoT device, and/or the IoT application installed on the first user's mobile device, and responsively performs a lookup in the secure database using the first user's identity, the second IoT device's identity, and/or the access point or router's identity associated with the first WiFi network key, the IoT cloud service provides the first WiFi network key to the first user's IoT hub, the first IoT device, and/or the IoT application installed on the first user's mobile device, and the first user's IoT hub, the first IoT device, and/or the IoT application installed on the first user's mobile device provide the first WiFi network key to the second IoT device. 4. The method according to claim 2, further comprising: The credential management module on the IoT center of the first user establishes a secure connection to the credential management module on the cloud service to provide the first WiFi network key to the cloud service. 5. The method according to claim 4, further comprising: The network registration module on the second IoT device connects to the credential management module on the IoT center of the first user to send a request for the first WiFi network key, and receives the first WiFi network key from the IoT center of the first user. 6. The method according to claim 4, further comprising: Attempts are made to connect to the IoT hub of the first user, the first IoT device, and the IoT application installed on the mobile device of the first user in order of priority. 7. The method of claim 6, wherein the priority order comprises first attempting to connect to the IoT hub of the first user, and if a reliable connection is not available, attempting to connect to the first IoT device and/or the IoT application installed on the mobile device of the first user. 8 . The method of claim 1 , wherein the request for the first WiFi network key includes identification data that uniquely identifies a wireless access point or router. 9. The method of claim 8, wherein the identification data comprises a MAC address and/or SSID of the wireless access point or router. 10. The method of claim 1, wherein the first communication connection comprises a Bluetooth Low Energy (BTLE) connection. 11. A system for sharing network credentials between devices, comprising: Internet of Things (IoT) cloud services that maintain secure connections with multiple IoT devices and IoT applications installed on end users' mobile devices; a first IoT device of a first user or an IoT application installed on a mobile device of the first user, which establishes a first secure communication channel with the IoT cloud service and securely transmits a first WiFi network key associated with the WiFi network of the first user to the IoT cloud service; a second IoT device establishing a second secure communication channel with the IoT cloud service via the IoT application installed on the mobile device or via the first IoT device, the second secure communication channel comprising a first communication connection between the second IoT device and the first IoT device or the mobile device, the first communication connection utilizing a first wireless communication protocol different from a second wireless communication protocol used by the WiFi network, the first IoT device or the mobile device establishing the first communication connection with the second IoT device using the first wireless communication protocol and simultaneously establishing a second communication connection with the WiFi network using the second wireless communication protocol, the second IoT device establishing the second secure communication channel with the IoT cloud service using the first communication connection and the second communication connection; and a second IoT device sending a request for the first WiFi network key available on the first user's WiFi network, the IoT cloud service associating the second IoT device with the first user's account and sending the first WiFi network key to the second IoT device via the IoT application installed on the mobile device of the first user or via the first IoT device, the first WiFi network key being transferred via the first communication connection and the second communication connection; and The second IoT device automatically establishes a secure connection on the first user's WiFi network using the first WiFi network key. 12. The system of claim 11, further comprising: A secure database is maintained on the IoT cloud service, which securely stores WiFi network keys of different users' WiFi networks including the first WiFi network key. The IoT cloud service receives the WiFi network keys from the IoT device, an IoT application installed on the user's mobile device, or an IoT hub, and the IoT cloud service securely stores the WiFi network keys in the secure database. 13. The system of claim 12 , wherein the IoT cloud service is configured to receive a request for the first WiFi network key from the first user's IoT hub, the first IoT device, and/or the IoT application installed on the first user's mobile device, and responsively perform a lookup in the secure database using the first user's identity, the second IoT device's identity, and/or the access point or router's identity associated with the first WiFi network key, the IoT cloud service providing the first WiFi network key to the first user's IoT hub, the first IoT device, and/or the IoT application installed on the first user's mobile device, and the first user's IoT hub, the first IoT device, and/or the IoT application installed on the first user's mobile device providing the first WiFi network key to the second IoT device. 14. The system of claim 12, further comprising: The credential management module on the IoT center of the first user establishes a secure connection to the credential management module on the IoT cloud service to provide the first WiFi network key to the IoT cloud service. 15. The system of claim 14, further comprising: The network registration module on the second IoT device connects to the credential management module on the IoT center of the first user to send a request for the first WiFi network key, and receives the first WiFi network key from the IoT center of the first user. 16. The system of claim 14, further comprising: The network registration module on the second IoT device attempts to connect to the IoT center of the first user, the first IoT device, and the IoT application installed on the mobile device of the first user in order of priority. 17. The system of claim 16, wherein the priority order comprises first attempting to connect to the IoT hub of the first user, and if a reliable connection is not available, attempting to connect to the first IoT device and/or the IoT application installed on the mobile device of the first user. 18. The system of claim 12, wherein the second secure communication channel utilizes at least a portion of the first secure communication channel. 19. The system of claim 11, wherein the request for the first WiFi network key includes identification data that uniquely identifies a wireless access point or router. 20. The system of claim 19, wherein the identification data comprises a MAC address and/or SSID of the wireless access point or router. 21. The system of claim 11, wherein the first communication connection comprises a Bluetooth Low Energy (BTLE) connection. 22. A non-transitory machine-readable medium having program code stored thereon, the program code, when executed by one or more machines, causing the machines to: Maintaining secure connections between IoT cloud services and multiple IoT devices and IoT applications installed on end users’ mobile devices; establishing a first secure communication channel between the IoT cloud service and a first IoT device of a first user or an IoT application installed on a mobile device of the first user; securely transmitting a first WiFi network key associated with the first user's WiFi network from the first IoT device or the IoT application installed on the mobile device to the IoT cloud service; establishing a second secure communication channel between a second IoT device and the IoT cloud service via the IoT application installed on the mobile device or via the first IoT device, the second secure communication channel comprising a first communication connection between the second IoT device and the first IoT device or the mobile device, the first communication connection utilizing a first wireless communication protocol different from a second wireless communication protocol used by the WiFi network, the first IoT device or the mobile device establishing the first communication connection with the second IoT device using the first wireless communication protocol and simultaneously establishing a second communication connection with the WiFi network using the second wireless communication protocol, the second IoT device establishing the second secure communication channel with the IoT cloud service using the first communication connection and the second communication connection; and sending a request for the first WiFi network key available on the WiFi network of the first user, the IoT cloud service associating the second IoT device with the account of the first user and sending the first WiFi network key to the second IoT device via the IoT application installed on the mobile device of the first user or via the first IoT device, the first WiFi network key being transferred via the first communication connection and the second communication connection; and The second IoT device establishes a secure connection on the first user's WiFi network using the first WiFi network key. 23. The non-transitory machine-readable medium of claim 22, wherein the operations further comprise: Securely storing WiFi network keys of different users' WiFi networks including the first WiFi network key in a secure database maintained on the IoT cloud service, wherein the WiFi network keys are received from the IoT device, an IoT application installed on the user's mobile device, or an IoT hub. 24. The non-transitory machine-readable medium of claim 23, wherein the IoT cloud service receives a request for the first WiFi network key from the first user's IoT hub, the first IoT device, and/or the IoT application installed on the first user's mobile device, and responsively performs a lookup in the secure database using the first user's identity, the second IoT device's identity, and/or the access point or router's identity associated with the first WiFi network key, the IoT cloud service provides the first WiFi network key to the first user's IoT hub, the first IoT device, and/or the IoT application installed on the first user's mobile device, and the first user's IoT hub, the first IoT device, and/or the IoT application installed on the first user's mobile device provides the first WiFi network key to the second IoT device. 25. The non-transitory machine-readable medium of claim 23, further comprising program code that causes the one or more machines to: The credential management module on the IoT hub of the first user establishes a secure connection to the credential management module on the IoT cloud service to provide the first WiFi network key to the IoT cloud service. 26. The non-transitory machine-readable medium of claim 25, further comprising program code that causes the one or more machines to: The network registration module on the second IoT device connects to the credential management module located on the IoT center of the first user to send a request for the first WiFi network key and receives the first WiFi network key from the IoT center of the first user. 27. The non-transitory machine-readable medium of claim 25, further comprising program code that causes the one or more machines to: Attempts are made to connect to the IoT hub of the first user, the first IoT device, and the IoT application installed on the mobile device of the first user in order of priority. 28. The non-transitory machine-readable medium of claim 27, wherein the priority order comprises first attempting to connect to the IoT hub of the first user, and if a reliable connection is not available, attempting to connect to the first IoT device and/or the IoT application installed on the mobile device of the first user. 29. The non-transitory machine-readable medium of claim 22, wherein the request for the first WiFi network key includes identification data that uniquely identifies a wireless access point or router. 30. The non-transitory machine-readable medium of claim 29, wherein the identification data comprises a MAC address and/or SSID of the wireless access point or router. 31. The non-transitory machine-readable medium of claim 22, wherein the first communication connection comprises a Bluetooth Low Energy (BTLE) connection.