Patent Description:
In order to participate in the Internet of Things, an individual IoT device often needs to be properly connected to a back-end system in a process referred to as onboarding. If onboarding is successful, then the back-end system may receive data from the IoT device and send updates back to the device. Existing workflows for onboarding vary widely, e.g., according to the type of device, the manufacturer of the device, and so on. For example, different devices may identify themselves using different types of identity information, and different types of identity information may be verified using a variety of techniques. The variety of onboarding workflows creates additional complexity for installation of IoT devices.

<CIT> relates to a method for establishing trust in a device when provisioning the device. <CIT> relates to an apparatus for establishing a trusted relationship with a peripheral device. <CIT> relates to a system for gateway enrollment for IoT device management.

The invention is defined by the independent claims, with various optional features being set out in the dependent claims.

While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word "may" is used in a permissive sense (i.e., meaning "having the potential to"), rather than the mandatory sense (i.e., meaning "must"). Similarly, the words "include," "including," and "includes" mean "including, but not limited to.

Various embodiments of methods, systems, and computer-readable media for template-based onboarding of Internet-connectible devices (ICDs) are described. ICDs may represent or be embedded in a variety of products, such as home automation devices, home appliances, manufacturing devices, automobiles, thermostats and other sensors, smart traffic lights, and so on. ICDs may include Internet of Things (IoT) devices in some embodiments, although the techniques described herein are not limited to any particular device categories or types. An ICD may also be referred to as a client device in terms of its relationship to a remote system. Many ICDs may make use of a connection (potentially a long-lived one) with a server of a remote service provider in order to stream data from the client device to the server and from the server to the client device whenever data needs to be transmitted. The term "onboarding" may refer to the process of creating such a connection. Using prior approaches, individual devices or individual device manufacturers had differing workflows and applications for onboarding their devices. For example, a smart thermostat from one vendor might require a different application or set of steps than a smart thermostat from another vendor to establish the identity of the device, give the device access to a local network, and configure the device so that it performs as expected in its particular context. The installation of such devices may be complicated by device-to-device or vendor-to-vendor onboarding differences.

Using techniques described herein, Internet-connectable devices (ICDs) may be onboarded to a remote system (e.g., one or more applications, servers, or services hosted in the cloud) using a template or other structured document. A particular template may be associated with a particular account with the remote system. A template may represent a set of directives and/or a set of conditions for performing onboarding tasks for devices associated with a particular account. A template may be defined (at least in part) by an owner of that account or by an administrator authorized by an account owner. Using the directives and/or conditions in a relevant template, a device onboarding service or other cloud-based system may associate a device with a system group such as a user account, verify the identity of the device, generate a configuration for the device (including access credentials for the remote system), and/or perform other tasks to facilitate interaction between the cloud (e.g., an application in the cloud) and the device. For example, two smart thermostats from different vendors may use different onboarding templates but the same installation application installed on the mobile device of an installer of the devices. The use of onboarding templates as described herein may enable the creation of connections between various types of client devices and remote systems and the configuration of client devices in a simplified and/or standardized manner.

As one skilled in the art will appreciate in light of this disclosure, embodiments may be capable of achieving certain technical advantages, including some or all of the following: (<NUM>) reducing the latency and complexity of onboarding ICDs to a remote system by using standardized templates and a single onboarding application to simplify the onboarding process; (<NUM>) enhancing the security of onboarding ICDs to a remote system by using standardized templates that are usable to perform verification of device identities and contexts; (<NUM>) improving the performance of IoT/ICD devices and applications by using standardized templates that are usable to configure the devices and applications; and so on.

<FIG> and <FIG> illustrate an example system environment for template-based onboarding of Internet-connectible devices, according to some embodiments. A device onboarding service <NUM> may allow or deny onboarding of devices based on pre-defined rules, policies, conditions, and/or other criteria. Onboarding may result in a connection between a device (such as Internet-connectible device <NUM>) and one or more cloud-based or remote applications or systems (such as Internet of Things application <NUM>). The device onboarding service <NUM> and IoT application <NUM> may be implemented in the cloud, e.g., in one or more cloud computing environments <NUM> that may be geographically remote from the ICD <NUM>. The connection between an ICD <NUM> and an IoT application <NUM> may be long-lasting such that the device and the remote application may send data to each other over relatively long durations (e.g., months, years, etc.) without necessarily needing to repeat the onboarding process. For example, a smart thermostat, once onboarded, may automatically send temperature updates to a remote system hosted in the cloud over a period of months or years. The rules, policies, conditions, and/or criteria may be determined or defined (at least in part) by customers. Customers may include vendors of ICDs and other entities that take responsibility for the interaction between ICDs and remote applications. The responsibility taken by a customer may include financial responsibility, such that a cloud-based entity may assess fees to the customer for interactions between the ICD and the cloud and/or for cloud resources used by such interactions. Customers may typically include individuals or organizations that manage IoT applications (such as application <NUM>) and not necessarily end users of ICDs or individual installers (technicians) of ICDs (such as user <NUM>).

In some embodiments, the rules, policies, conditions, and/or criteria may be represented in onboarding templates <NUM>. Onboarding templates <NUM> may represent structured documents that express directives for onboarding of ICDs. A particular onboarding template such as template 125A may describe the conditions by which an ICD (such as ICD <NUM>) can identify itself to a system (e.g., the service <NUM>), associate itself with a system group such as a user account, and receive the configuration necessary to interact with a local network (e.g., using WiFi credentials) as well as a component in the cloud computing environment <NUM> (e.g., the IoT application <NUM>) and potentially with other devices. In one embodiment, a template may include information related to (e.g., defining) one or more of the following elements: proof and context of identity, account policy, and credentials/configuration. An onboarding template for a given account may be determined, generated, or otherwise provided to the service <NUM> by an owner of the account or by an administrator authorized by an account owner.

Proof and context of identity (PCI) may relate to a claim of identity that a device can make. PCI may sometimes include hardware-based information (e.g., using hardware-backed cryptography). PCI may be based on the proximity of the device to another nearby device, e.g., an attestor <NUM> such as an onboarding device, mobile device, or local hub. The context may relate to the specific location of a device, e.g., at a particular address, in a particular room, and so on. The context may include the MAC address of the device, the Bluetooth ID of the device, a GPS location of the device or attestor, and so on. Elements of the PCI may often be provided by an installer or technician (e.g., user <NUM>) or by the attestor device <NUM>. The form of the PCI for a given device may vary from device to device, from vendor to vendor, and so on. For example, some devices may supply hardware-based proof of identity, while other devices may rely on information provided by an installer or attestor device. Using the onboarding templates <NUM> and device onboarding service <NUM>, different forms of PCI may be used to verify the identity of ICDs and permit or deny onboarding requests for those devices with the same general onboarding workflow and/or the same onboarding application. In some embodiments, the onboarding process from the perspective of an installer (e.g., user <NUM>) may be similar for different devices.

As shown in <FIG>, the PCI <NUM> may be located on the device <NUM> itself, e.g., as encoded in the device's hardware and/or entered into the device by a user <NUM>. To initiate onboarding, the device <NUM> may send an onboarding request <NUM> to the device onboarding service <NUM> in the cloud <NUM>. The request <NUM> may be sent over one or more network(s) <NUM> connecting the two components, e.g., to an address known to the device <NUM>. As shown in <FIG>, the device <NUM> may already have access to the network(s) <NUM>, e.g., via WiFi credentials entered by the user <NUM>. The PCI <NUM> may be included in the onboarding request <NUM> or may be provided in a subsequent bundle of information sent by the device <NUM>. An identifier of the specific onboarding template to use for the ICD <NUM> may be included in the onboarding request <NUM> or may be provided in a subsequent bundle of information sent by the device <NUM>. The template may be selected by the user <NUM> or may instead be included in initial settings for the device <NUM>.

As shown in <FIG>, the PCI <NUM> may be bundled up and signed by an attestor device <NUM>. The attestor <NUM> may represent an intermediate device (e.g., a mobile device operated by an installer) that has access to the network(s) <NUM> and can attest for the proof of identity of the device <NUM>. In one embodiment, the attestor <NUM> may obtain one portion of the PCI <NUM> from the device <NUM> itself and may determine another portion of the PCI on its own (or with input from the user <NUM>). To initiate onboarding, the attestor device <NUM> may send an onboarding request <NUM> to the device onboarding service <NUM> in the cloud <NUM>. The request <NUM> may be sent over one or more network(s) <NUM> connecting the two components, e.g., to an address known to the attestor device <NUM>. As shown in <FIG>, the ICD <NUM> may not have access to the network(s) <NUM> prior to onboarding but may communicate with the attestor <NUM>, e.g., over a Bluetooth connection or other local channel. The PCI <NUM> may be included in the onboarding request <NUM> or may be provided in a subsequent bundle of information sent by the attestor device <NUM>. An identifier of the specific onboarding template to use for the ICD <NUM> may be included in the onboarding request <NUM> or may be provided in a subsequent bundle of information sent by the device <NUM>. The template may be selected by the user <NUM>, e.g., using an onboarding application installed on the attestor device <NUM>.

The service <NUM> may receive the onboarding request and begin the process of using an appropriate onboarding template to attempt onboarding of the device <NUM>. The service <NUM> may include a component <NUM> for device-to-account linking that identifies a user account with which the device <NUM> should be associated. The service <NUM> may include or have access to information describing a set of accounts <NUM> with the cloud computing environment <NUM> or with an individual component (e.g., the application <NUM>). For example, the accounts <NUM> may include account 115A through account 115N. The selected account (e.g., account 115A) may be determined deterministically, e.g., based (at least in part) on the onboarding template ID, PCI, and/or other information received with the onboarding request. As discussed above, the user account may be associated with a particular customer, such as a vendor of ICDs or another entity that takes responsibility for the interaction between ICDs and a remote application <NUM>. The service <NUM> may determine the account based (at least in part) on information (provided by the ICD or by the attestor) that is usable to identify the account, e.g., an account identifier or information that can map the device to an account identifier. In some embodiments, the service <NUM> may determine the account based (at least in part) on information received from the device <NUM> or attestor <NUM>, such as a template ID linked to an account ID or an account ID itself. In some embodiments, the service <NUM> may determine the account without receiving an account ID from the device <NUM> or attestor <NUM>, e.g., based (at least in part) on the PCI and/or the template ID.

The selected user account may have one or more account policies that are reflected in one or more onboarding templates. The service <NUM> may include a component <NUM> for onboarding template retrieval that identifies an onboarding template (e.g., template 125A) with which the device <NUM> should be associated, e.g., based on the template ID received with the onboarding request. The service <NUM> may include or have access to a set of templates <NUM>. For example, the templates <NUM> may include template 125A through template 125N. Templates <NUM> may be identified by template IDs as well as customer-defined names. Templates <NUM> may be versioned such that each edit may create a new version. Templates <NUM> may be created or defined (at least in part) by account owners (customers) or designated administrators, and individual templates <NUM> may be specific to particular customer accounts <NUM>. The selected template 125A may include an account policy that describes the types or forms of PCI that can be used for onboarding of devices. The account policy may also describe the criteria or conditions under which devices may be onboarded.

In some embodiments, the service <NUM> may use the appropriate template 125A to verify the identity of the device <NUM>. The service <NUM> may include a component <NUM> for PCI verification. The PCI verification <NUM> may determine whether the provided PCI <NUM> meets the expected form(s) of PCI defined in the template 125A. The PCI verification <NUM> may also verify the identity of the device <NUM> using the PCI. In verifying the device identity, the PCI verification <NUM> may use techniques that are specific to the form of the PCI. For example, if the PCI includes hardware-based identity information expressed according to the standards of a particular hardware vendor, then that vendor's verification technique may be used for identity verification. The templates <NUM> may be flexible enough to encompass a wide variety of industry standards for identity verification. If the form of the PCI fails to satisfy the directives of the template 125A (e.g., the account policy), then the onboarding request may be rejected. If the identity verification itself fails, then the onboarding request may be rejected. A failed onboarding attempt may be logged, e.g., with a description of the failure, an identifier of the account, information identifying the device (e.g., the provided PCI), a timestamp, and/or other information usable to perform a security review. Otherwise, the onboarding process may continue.

In some embodiments, the service <NUM> may use the appropriate template 125A to configure the device <NUM>. The service <NUM> may include a component <NUM> for device configuring. The device configuring component <NUM> may determine or generate a device configuration that the device <NUM> can use to connect to the IoT application <NUM>. The device configuration information may include access credentials for accessing a WiFi network or other local network in the vicinity of the device <NUM>. The device configuration information may include access credentials for accessing elements of the cloud <NUM>, e.g., the IoT application <NUM>. The device configuration information may include an endpoint at which the device can access the application <NUM>, e.g., a uniform resource locator (URL) or other address. The device configuration information may be sent by the service <NUM> to the device <NUM> if the device is already connected to the network(s) <NUM> or otherwise to the attestor <NUM>, which may in turn provide the device configuration information to the device <NUM> via Bluetooth or another local channel.

In some embodiments, the various functions performed by the service <NUM> may be repeated across multiple rounds, e.g., to bootstrap the local network access (e.g., by supplying WiFi credentials) and then create a connection between the device <NUM> and the application <NUM>. In some embodiments, the device <NUM> may validate the account policy to ensure that it matches the device's expectations. For example, a smart home device may check that it is only accepting instructions from an account associated with its vendor by verifying the server certification.

<FIG> illustrates further aspects of the example system environment for template-based onboarding of Internet-connectible devices, including a connection between an Internet-connectible device and an Internet of Things application, according to some embodiments. As discussed above, the device configuration information <NUM> may include access credentials <NUM> as well as an endpoint <NUM> at which the device can access the application <NUM>. The device configuration information <NUM> may include an arbitrary map of customer-defined key-value pairs. Using this configuration information <NUM>, the ICD <NUM> and the cloud-based IoT application <NUM> may use a long-standing connection to exchange information. For example, the ICD <NUM> may supply regular measurements over time, and the application <NUM> may supply occasional updates to affect the functionality of the device. If the attestor <NUM> was used to initiate onboarding, then the attestor may be bypassed by this long-standing connection between the device <NUM> and the application <NUM>.

The device configuration <NUM> may influence the behavior of the device <NUM>, such that the device may perform one or more actions according to information specified or indicated in the device configuration. The behavior of the device may include the device attempting to connect to a particular endpoint in the cloud according to an address specified in the device configuration. The behavior of the device may include the device supplying access credentials to an endpoint in the cloud according to credentials specified in the device configuration. The behavior of the device may include the device collecting data according to the device configuration, e.g., according to a frequency or schedule indicated in the device configuration, in a format indicated in the device configuration, or after receiving speech input representing a "wake word" specified in the device configuration for a voice-enabled device that is configured to stream speech input to the cloud. The behavior of the device may include the device sending information (e.g., data collected by a sensor associated with the device) to an endpoint in the cloud according to the device configuration, e.g., to an address specified in the device configuration and with a frequency indicated in the device configuration. The behavior of the device may include the device receiving information (e.g., modifications to the configuration information) from an endpoint in the cloud and verifying the source of the information according to the device configuration.

The device onboarding service <NUM> may include one or more computing devices, any of which may be implemented by the example computing device <NUM> illustrated in <FIG>. In various embodiments, the functionality of the different services, components, and/or modules of the device onboarding service <NUM> may be provided by the same computing device or by different computing devices. If any of the various components are implemented using different computing devices, then the respective computing devices may be communicatively coupled, e.g., via a network. Each of the components of the device onboarding service <NUM> may represent any combination of software and hardware usable to perform their respective functions, as discussed as follows. Functions implemented by the device onboarding service <NUM> may be performed automatically, e.g., without a need for user initiation or user intervention after an initial configuration stage, and programmatically, e.g., by execution of program instructions on at least one computing device. In one embodiment, aspects of the device onboarding service <NUM> may be performed repeatedly over time. The device onboarding service <NUM> may include additional components not shown, fewer components than shown, or different combinations, configurations, or quantities of the components shown. In various embodiments, the functionality described herein for the device onboarding service <NUM> may be implemented as a service that collaborates with other services in a service-oriented architecture or instead as another type of system or back-end component. The service <NUM> may be implemented using one or more service instances, each of which may include the functionality described with respect to <FIG> and <FIG>.

In at least some embodiments, an Internet-connectable device (ICD) such as ICD <NUM> may comprise one or more processors and a memory. The memory may store executable instructions that when executed on the one or more processors cause the one or more processors to perform operations such as connecting to a local network, communicating with a network endpoint (e.g., an application hosted in the cloud), and so on. In some embodiments, a set of additional executable instructions for the ICD (e.g., comprising firmware or software) may be obtained or downloaded from a network endpoint. As a result of the execution of the additional instructions, the ICD may in various embodiments attain a desired device state in which one or more operations associated with an application may be performed by the ICD. Note that the resource capabilities of ICDs may vary in different embodiments: some ICDs may have very limited processing power and very limited memory, while others may be equipped with high-end CPUs (central processing units) or processing cores and much larger memories.

The device onboarding service <NUM> may communicate with other components (e.g., ICDs and attestors) via one or more networks <NUM>. In various embodiments, the network(s) <NUM> may encompass any suitable combination of networking hardware and protocols necessary to establish network-based communications between two components. For example, the network(s) <NUM> may generally encompass the various telecommunications networks and service providers that collectively implement the Internet. The network(s) <NUM> may also include private networks such as local area networks (LANs) or wide area networks (WANs) as well as public or private wireless networks. For example, two services may be respectively provisioned within enterprises having their own internal networks. In such an embodiment, the network(s) <NUM> may include the hardware (e.g., modems, routers, switches, load balancers, proxy servers, etc.) and software (e.g., protocol stacks, accounting software, firewall/security software, etc.) necessary to establish a networking link between a first component and the Internet as well as between the Internet and a second component. In some embodiments, components may communicate with one another using a private network rather than the public Internet.

In one embodiment, aspects of the device onboarding service <NUM> and/or application <NUM> may be implemented using resources of a provider network or other cloud computing environment. A provider network may represent a network set up by an entity such as a business or a public-sector organization to provide one or more services (such as various types of network-accessible computing or storage) accessible via the Internet and/or other networks to a distributed set of clients. A provider network may include numerous data centers hosting various resource pools, such as collections of physical and/or virtualized computer servers, storage devices, networking equipment and the like, that are used to implement and distribute the infrastructure and services offered by the provider. The compute resources may, in some embodiments, be offered to clients in units called "instances," such as virtual or physical compute instances. A virtual compute instance may, for example, comprise one or more servers with a specified computational capacity (which may be specified by indicating the type and number of CPUs, the main memory size, and so on) and a specified software stack (e.g., a particular version of an operating system, which may in turn run on top of a hypervisor). A number of different types of computing devices may be used singly or in combination to implement the resources of the provider network in different embodiments, including general purpose or special purpose computer servers, storage devices, network devices, and the like. Because resources of the provider network may be under the control of multiple clients (or tenants) simultaneously, the provider network may be said to offer multi-tenancy and may be termed a multi-tenant provider network. In some embodiments, an operator of the provider network may implement a flexible set of resource reservation, control, and access interfaces for their clients. For example, a resource manager may implement a programmatic resource reservation interface (e.g., via a web site or a set of web pages) that allows clients (potentially including other components within the provider network) to learn about, select, purchase access to, and/or reserve compute instances offered by the provider network. Such an interface may include capabilities to allow browsing of a resource catalog and provide details and specifications of the different types or sizes of resources supported, the different reservation types or modes supported, pricing models, and so on.

In at least some embodiments, applications involving the use of ICDs such as smart appliances, smart sensors, and the like may be implemented using the resources of one or more network-accessible services of a provider network or other cloud computing environment <NUM>. One or more computing services of the provider network, such as a virtualized computing service may, for example, be used to host the back-end application logic, while storage services of the provider network may be used to store data generated or collected at the ICDs. In at least one embodiment, a provider network may comprise an IoT application management service, including for example message brokers that enable efficient communication among potentially large numbers of ICDs of an application and/or between the ICDs and back-end application servers.

<FIG> illustrates further aspects of the example system environment for template-based onboarding of Internet-connectible devices, including the use of a compute service to perform tasks for verification and generating a device configuration, according to some embodiments. In some embodiments, the PCI verification <NUM> and/or device configuring <NUM> may be implemented using external entities that perform tasks. For example, a serverless compute service <NUM> may perform functions indicated by the device onboarding service <NUM>. In one embodiment, the PCI verification <NUM> may be performed by executing a verification task <NUM> using the serverless compute service <NUM>. In one embodiment, the device configuring may be performed by executing a configuration generation task <NUM> using the serverless compute service <NUM>. The tasks <NUM> and <NUM> may represent executable program code or high-level programming instructions that can be implemented by the compute service <NUM> using computing resources managed by the compute service and not provisioned by the device onboarding service <NUM>. The tasks <NUM> and/or <NUM> may be indicated in the appropriate template 125A. The tasks <NUM> and/or <NUM> may be owned and/or operated by a third party that is distinct from the entity that manages the cloud computing environment <NUM>. For example, the verification task <NUM> may be developed and managed by a vendor of a hardware element of the ICD that is usable to verify the ICD in a secure manner. By utilizing the external service <NUM> or other third-party compute environment to perform tasks, the template-based device onboarding may be extensible to a variety of verification and/or configuration techniques.

<FIG> is a flowchart illustrating a method for template-based onboarding of Internet-connectible devices, according to some embodiments. As shown in <NUM>, an onboarding request may be received, e.g., by a device onboarding service from an Internet-connectible device (ICD) or an attestor device (e.g., a smartphone, tablet, a dedicated onboarding device, and so on). The request may include or be associated with proof and context of identity (PCI) information. The PCI may relate to a claim of identity that a device can make as well as contextual information (e.g., about the location of the device). Elements of the PCI may often be provided by an installer or technician or by an attestor device.

As shown in <NUM>, the method may determine an onboarding template for the ICD. The onboarding template may be determined based (at least in part) on a template ID supplied with the onboarding request. In one embodiment, an account may be determined deterministically for the ICD, e.g., based (at least in part) on the template ID or other information received with the onboarding request. The account may be associated with a particular customer, such as a vendor of ICDs or another entity that takes responsibility for the interaction between ICDs and a remote application. The onboarding template may represent a structured document that expresses directives for onboarding of ICDs. A template may describe the conditions by which the ICD can identify itself to a system (e.g., the device onboarding service), associate itself with a system group such as a user account, and receive the configuration necessary to interact with a local network (e.g., using WiFi credentials) as well as an IoT application or other cloud-based component. In one embodiment, a template may include information related to (e.g., defining) one or more of the following elements: proof and context of identity, account policy, and credentials/configuration.

As shown in <NUM>, the method may determine whether the PCI has been verified against any criteria indicated in the onboarding template. The verification may include checking that the form of the supplied PCI meets the expected form of PCI as expressed in the template (or account policy). The verification may also include checking that the content of the supplied PCI is verified, e.g., using a verification technique expressed in the template (or account policy). As shown in <NUM>, if the form or content of the PCI cannot be verified, then the onboarding request may be rejected.

As shown in <NUM>, if both the form and content of the PCI are verified, then the method may proceed to determine a device configuration for the ICD using the onboarding template. The device configuration may include access credentials for a network and/or an Internet of Things (IoT) application hosted in the cloud. The access credentials and endpoint for the IoT application may be indicated in the onboarding template. As shown in <NUM>, the device configuration may be sent to the device itself. The configuration may be sent directly to the device if the device is already on the local network (e.g., using WiFi credentials entered by a user or supplied during a prior round of onboarding) or indirectly via an attestor device.

As shown in <NUM>, a connection may be established between the device and the IoT application. The device may use the provided configuration (including the credentials) to contact the IoT application and establish the connection. The connection between an ICD and an IoT application may be long-lasting such that the device and the remote application may send data to each other over relatively long durations (e.g., months, years, etc.) without necessarily needing to repeat the onboarding process. For example, a smart thermostat, once onboarded, may automatically send temperature updates to a remote system hosted in the cloud over a period of months or years. The device configuration may influence the behavior of the device such that the device may perform one or more actions according to information specified or indicated in the device configuration. For example, the behavior of the device may include the device attempting to connect to a particular endpoint in the cloud according to an address specified in the device configuration, the device supplying access credentials to an endpoint in the cloud according to credentials specified in the device configuration, the device collecting data according to the device configuration, the device sending information (e.g., data collected by a sensor associated with the device) to an endpoint in the cloud according to the device configuration, and/or the device receiving information (e.g., modifications to the configuration information) from an endpoint in the cloud and verifying the source of the information according to the device configuration.

<FIG> is a sequence diagram representing a technique for pre-onboarding of Internet-connectible devices, according to some embodiments. The device onboarding service <NUM> may include components such as a template manager <NUM> and a trust manager <NUM>. The template manager <NUM> may maintain the templates <NUM>. The trust manager <NUM> may be responsible for authenticating and authorizing incoming requests from ICDs. The trust manager <NUM> may allow or deny onboarding of devices based on pre-defined rules, policies, conditions, and/or other criteria defined by customers. Such rules, policies, conditions, and/or criteria may be represented in an onboarding template. Additionally, the cloud computing environment <NUM> may include a role manager <NUM> that manages access credentials for users and user groups to various components of the cloud computing environment.

Prior to onboarding any devices, a cloud administrator <NUM> may create an onboarding template as shown in <NUM>. The cloud administrator <NUM> may represent a vendor of ICDs or another entity responsible for the use of ICDs with cloud-based resources. The template may be created and/or provided to the template manager <NUM> using one or more APIs offered by the template manager. For example, the template manager <NUM> may offer APIs for listing templates, creating templates, describing templates, updating templates, deleting templates, listing template versions, and describing template versions. As shown in <NUM>, the administrator <NUM> may upload pre-provisioned access credentials to the template. As shown in <NUM>, the administrator <NUM> may grant onboarding access to a particular role for a technician <NUM> who will be installing ICDs. As shown in <NUM>, the administrator <NUM> may inform the technician <NUM> which template to use for a particular installation or type of device.

<FIG>, <FIG>, and <FIG> are sequence diagrams representing a technique for template-based onboarding of Internet-connectible devices, according to some embodiments. The device onboarding service <NUM> may include components such as an orchestrator <NUM>. The orchestrator <NUM> may be responsible for processing device events and onboarding devices into an account. The account may be referred to as a customer account and may be associated with an account owner. The orchestrator <NUM> may represent a REST-based service that exposes application programming interfaces (APIs) for a device connector and an onboarding application <NUM>. In one embodiment, when a device connects for onboarding, execution of a function by the serverless compute service <NUM> may be triggered. A device connector may be responsible for receiving onboarding requests from devices and sending configurations back to devices. The trust manager <NUM> may be responsible for vending onboarding tokens and performing authorization tasks. To begin onboarding to a target platform, execution of a function referred to as a cloud connector may be triggered for the serverless compute service <NUM>. This function may interact with the template manager <NUM> for fetching the cloud configuration in the template and interact with an audit service to supply audit details regarding the onboarding.

The sequence diagram beginning in <FIG> may be used when the technician <NUM> seeks to install an ICD using an onboarding application <NUM> (e.g., an app on a mobile device operated by the technician) and not necessarily having preprovisioned credentials as in <FIG>. As shown in <NUM>, the technician <NUM> may log in and select, via the onboarding application <NUM>, the appropriate template for installation of a particular device <NUM>. As shown in <NUM>, the technician <NUM> may instruct the application <NUM> to scan for new devices. As shown in <NUM>, the application <NUM> may scan for new devices continuously and connect automatically to devices on discovery, e.g., via Bluetooth or another locally accessible channel. As shown in <NUM>, the technician <NUM> may power on the device <NUM> for onboarding. As shown in <NUM>, the device <NUM> may advertise itself for onboarding via WiFi or Bluetooth. As shown in <NUM>, the onboarding application <NUM> may connect to the device <NUM>. As shown in <NUM>, the device <NUM> may request onboarding to the application <NUM> with optionally pre-provisioned credentials (e.g., for accessing WiFi or another local network).

The sequence diagram may continue in <FIG>. As shown in <NUM>, the application <NUM> may request, to the trust manager <NUM>, a temporary onboarding ticket for a given credential group. As shown in <NUM>, the trust manager <NUM> may provide device credentials to the application <NUM>. As shown in <NUM>, the application <NUM> may push the credentials (potentially including WiFi credentials) to the device <NUM>. As shown in <NUM>, the device <NUM> may use the onboarding ticket to request onboarding from an onboarding orchestrator <NUM> of the device onboarding service <NUM>. As shown in <NUM>, the orchestrator <NUM> may query the trust manager <NUM> for the ticket's credential group. As shown in <NUM>, the trust manager <NUM> may return the group ID if found or else an error.

The sequence diagram may continue in <FIG>. As shown in <NUM>, the orchestrator <NUM> may request evaluation of the onboarding template by passing the parameters and the template ID to the template manager <NUM>. As shown in <NUM>, the template manager <NUM> may return the evaluated template body with a cloud resource configuration and a device local configuration. As shown in <NUM>, the orchestrator may create cloud resources for the customer associated with the ICD. The cloud resources may be associated with an application <NUM> to which the ICD seeks to connect. As shown in <NUM>, the orchestrator <NUM> may send the local configuration to the device <NUM>. As shown in <NUM>, the device <NUM> may connect to the application <NUM> in the cloud using the provided credentials and configuration.

As discussed above, onboarding templates may include structured documents. In one embodiment, a template may include a section for indicating a device-provided context, such as:
"DeviceProvidedContext": {
"RoomNumber": {
"Type": "String"
},
"Building": {
"Type": "String",
},
"City": {
"Type": "String",
"Default": "DefaultCityName"
}
}.

In one embodiment, a template may include a section for indicating a user-provided context (e.g., using the onboarding application), such as:
"UserProvidedContext": {
"SerialNumber": {
"Type": "String"
},
"AccountId": {
"Type": "String"
}
}.

In one embodiment, a template may include a section for mappings to get key-value lookups based on provided context, such as:
"Mappings": {
"CityMapping": {
"CityName1": {
"FallbackEndpoint": "URL1"
},
"CityName2": {
"FallbackEndpoint": "Url2"
}
}
}.

In one embodiment, a template may include a section describing cloud resources to be created for the customer's account, such as:
"Resources": {
"thing" : {
"Type" : "CloudEnvironment::IoT::Thing",
"Properties" : {
"ThingName" : {"Ref" : "SerialNumber"},
"AttributePayload" : { "version" : "v1", "accountId" : {"Ref" :
"AccountId"}},
"ThingTypeName" : "lightBulb-versionA",
"ThingGroups" : ["v1-lightbulbs", {"Ref" : "City"}]
},
"OverrideSettings" : {
"AttributePayload" : "MERGE",
"ThingTypeName" : "REPLACE",
"ThingGroups" : "DO_NOTHING"
}
},
"certificate" : {
"Type" : " CloudEnvironment::IoT::Certificate",
"Properties" : {
"CertificatePem": {"Fn::GenerateCredential": ["X. <NUM>"]},
"Status" : "ACTIVE"
},
"OverrideSettings" : {
"Status" : "DO_NOTHING"
}
},
"policy" : {
"Type" : " CloudEnvironment::IoT::Policy",
"Properties" : {
"PolicyDocument" : "{ \"Version\": \"<NUM>-<NUM>-<NUM>\", \"Statement\":
[{ \"Effect\": \"Allow\", \"Action\":
[\"iot:Publish\"], \"Resource\": [\"ResourceIdentifier"] }]
}"
}
}
}.

In one embodiment, a template may include a pre-onboarding configuration section that is created by the customer account and provided to the installer, such as:
"PreOnboardingConfiguration": {
"WifiSsid": "wpa2",
"WifiPassword": "password123",
}.

In one embodiment, a template may include a section indicating any configuration that should be sent to the device to finalize the onboarding process, such as:
"DeviceConfiguration": {
"UserAccountId": {"Ref": "AccountId"},
"AdminAccountId": "<NUM>",
"IoTEndpoint": "URL1",
"FallbackEndpoint": {"Fn::FindInMap": ["CityMapping", {"Ref": "City"},
"FallbackEndpoint"]},
}.

In one embodiment, a template may include a section specifying a deployment target in another region or account, such as:
"DeploymentTarget": {
"OnboardingRole": "ResourceIdentifier",
"Region": "RegionName"
}.

In one embodiment, a template may include an attachments section for documents stored in the cloud that can be delivered to the device when onboarding is complete, such as:
"Attachments": {
"wifi-cert": "DocumentLocation",
"boot-image": "data:image/png;base64,.

In at least some embodiments, a computer system that implements a portion or all of one or more of the technologies described herein may include a computer system that includes or is configured to access one or more computer-readable media. <FIG> illustrates such a computing device <NUM> according to one embodiment. In the illustrated embodiment, computing device <NUM> includes one or more processors 3010A-3010N coupled to a system memory <NUM> via an input/output (I/O) interface <NUM>. In one embodiment, computing device <NUM> further includes a network interface <NUM> coupled to I/O interface <NUM>.

In various embodiments, computing device <NUM> may be a uniprocessor system including one processor or a multiprocessor system including several processors 3010A-3010N (e.g., two, four, eight, or another suitable number). In one embodiment, processors 3010A-3010N may include any suitable processors capable of executing instructions. For example, in various embodiments, processors 3010A-3010N may be processors implementing any of a variety of instruction set architectures (ISAs), such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In one embodiment, in multiprocessor systems, each of processors 3010A-3010N may commonly, but not necessarily, implement the same ISA.

In one embodiment, system memory <NUM> may be configured to store program instructions and data accessible by processor(s) 3010A-3010N. In various embodiments, system memory <NUM> may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above, are shown stored within system memory <NUM> as code (i.e., program instructions) <NUM> and data <NUM>.

In one embodiment, I/O interface <NUM> may be configured to coordinate I/O traffic between processors 3010A-3010N, system memory <NUM>, and any peripheral devices in the device, including network interface <NUM> or other peripheral interfaces. In some embodiments, I/O interface <NUM> may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory <NUM>) into a format suitable for use by another component (e.g., processors 3010A-3010N). In some embodiments, I/O interface <NUM> may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example. In some embodiments, the function of I/O interface <NUM> may be split into two or more separate components, such as a north bridge and a south bridge, for example. In some embodiments, some or all of the functionality of I/O interface <NUM>, such as an interface to system memory <NUM>, may be incorporated directly into processors 3010A-3010N.

In one embodiment, network interface <NUM> may be configured to allow data to be exchanged between computing device <NUM> and other devices <NUM> attached to a network or networks <NUM>. In various embodiments, network interface <NUM> may support communication via any suitable wired or wireless general data networks, such as types of Ethernet network, for example. Additionally, in some embodiments, network interface <NUM> may support communication via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fibre Channel SANs, or via any other suitable type of network and/or protocol.

In some embodiments, system memory <NUM> may be one embodiment of a computer-readable (i.e., computer-accessible) medium configured to store program instructions and data as described above for implementing embodiments of the corresponding methods and apparatus. In some embodiments, program instructions and/or data may be received, sent or stored upon different types of computer-readable media. In some embodiments, a computer-readable medium may include non-transitory storage media or memory media such as magnetic or optical media, e.g., disk or DVD/CD coupled to computing device <NUM> via I/O interface <NUM>. In one embodiment, a non-transitory computer-readable storage medium may also include any volatile or non-volatile media such as RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., that may be included in some embodiments of computing device <NUM> as system memory <NUM> or another type of memory. In one embodiment, a computer-readable medium may include transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network and/or a wireless link, such as may be implemented via network interface <NUM>. The described functionality may be implemented using one or more non-transitory computer-readable storage media storing program instructions that are executed on or across one or more processors. Portions or all of multiple computing devices such as that illustrated in <FIG> may be used to implement the described functionality in various embodiments; for example, software components running on a variety of different devices and servers may collaborate to provide the functionality in one embodiment. In some embodiments, portions of the described functionality may be implemented using storage devices, network devices, or various types of computer systems. In various embodiments, the term "computing device," as used herein, refers to at least all these types of devices, and is not limited to these types of devices.

The various methods as illustrated in the Figures and described herein represent examples of embodiments of methods. In various embodiments, the methods may be implemented in software, hardware, or a combination thereof. In various embodiments, in various ones of the methods, the order of the steps may be changed, and various elements may be added, reordered, combined, omitted, modified, etc. In various embodiments, various ones of the steps may be performed automatically (e.g., without being directly prompted by user input) and/or programmatically (e.g., according to program instructions).

The terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the description of the invention and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "includes," "including," "comprises," and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used herein, the term "if" may be construed to mean "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [a stated condition or event] is detected" may be construed to mean "upon determining" or "in response to determining" or "upon detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]," depending on the context.

It will also be understood that, although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, without departing from the scope of the present invention. The first contact and the second contact are both contacts, but they are not the same contact.

Claim 1:
A system, comprising:
a plurality of computing devices configured to implement a device onboarding service hosted in a cloud computing environment, wherein the device onboarding service is configured to:
receive, via a network, a proof and context of identity, PCI, of an Internet-connectible device, ICD;
determine an onboarding template, wherein the onboarding template is associated with a user account with the cloud computing environment, and wherein the onboarding template is determined at least in part by an owner of the user account;
verify the identity of the ICD using the onboarding template by verifying that the PCI meets one or more criteria of the onboarding template, wherein verifying the identity of the ICD comprises verifying the PCI using an identity verification technique indicated in the onboarding template;
determine a device configuration based at least in part on the onboarding template, wherein the device configuration comprises access credentials and an endpoint usable by the ICD; and
send the device configuration to the ICD, wherein a behavior of the ICD is determined based at least in part on the device configuration, and wherein the ICD uses the access credentials to communicate with an application in the cloud computing environment via the network, and accesses the application at the endpoint.