Patent ID: 12256024

DETAILED DESCRIPTIONS

Consumer devices are increasingly configured with sensors, electronics, and networking capabilities to provide enhanced user experiences. User intervention is generally required to setup such devices. (e.g., Internet of Things (IoT) devices, smart devices, or connected devices). For example, if a user wants to connect a smart scale to the user's health account in the cloud, the user can employ a smart phone application (or a desktop/web application) that connects to the device to enter the user's account information. Similarly, to connect a Wi-Fi enabled printer to a user's Wi-Fi channel, the user may employ a cumbersome user interface built into the printer to enter the user's Wi-Fi SSID and password. Providing user interfaces or connectable applications for different types of smart devices is expensive for manufacturers or is generally not user friendly. Furthermore, such implementations may not be secure against nefarious actors, such as hackers, who may be able to connect to the user's Wi-Fi, spoof a smart device, capture user data, etc.

The implementations described herein provides technology and methodology for secure and user friendly device configuration. Such configuration for such a device includes network setup (e.g., providing Wi-Fi SSID/password information), initializing user account information on the devices, installation of user applications, installation of firmware/software updates, etc. and is hereinafter referred to as “device provisioning.” A manufactured device is equipped with a public/private key pair, such as a public/private key pair utilized in public key infrastructure (PKI). The public/private key pair is generated in a secure location within the device, such as in a trusted execution environment (TEE) or a trusted platform module (TPM). The public key is utilized as a cryptographic, globally unique, public device identification (ID).

As the devices are manufactured and public/private key pairs are implemented for each device, the public keys are recorded by the manufacturer or one or more provisioning services. The record is subsequently utilized by different parties as an ownership record. For example, when a vendor purchases an arbitrary number of devices from the manufacturer, the public keys associated with the arbitrary number of devices are associated with the purchasing vendor within a device tracking database. In other words, a transaction is recorded in association with the public keys. Furthermore, the public keys may be printed on the physical package that contains the manufactured device. As such, upon delivery of the devices from the manufacturer to the vendor, the vendor scans the public keys on the printed package to confirm delivery of the devices. Thus, the public keys, along with shrink-wrap, are utilized to confirm secure delivery of the devices from the manufacturer to the vendor.

One or more provisioning services, which may be implemented by the manufacturer, vendor, or may be a stand-alone service that employs user information and the public keys associated with devices to provision the devices when the devices are purchased. For example, a vendor, such as an electronics store, implements or employs a provisioning service. The provisioning service manages or has access to customer account information. For example, a user has a customer account with the electronics store (e.g., via a rewards program). The user is able to connect other accounts and services to the customer account. Such other accounts may include, without limitation, service subscriptions (e.g., a health tracking service), social media accounts, etc. Furthermore, the user submits SSID/password information for the user's home LAN to the customer account. As such, when the user purchases a smart device at the vendor, the public device ID (public key) is associated to the user's account in an ownership record. In other words, a transaction involving the user and the device associated with the public key is recorded with the provisioning service.

The provisioning service prepares configuration payloads for the device based on the customer's account information. The configuration payloads may include the customer's SSID/password for the user's Wi-Fi, software/firmware updates, applications, user data, etc. The configuration payloads are encrypted using the purchased device's public key.

At the customer's residence, the customer has a router equipped with device provisioning technology. The router (or a connected device) provides wireless access to a constrained provisioning channel, which may be hidden. The device is equipped with provisioning channel information, such as the SSID for the constrained provisioning channel (e.g., a provisioning channel ID). When the device is powered on at the customer's residence (or place of employment), the device connects to the constrained provisioning channel using the provisioning channel SSID stored in the device. The constrained provisioning channel is configured to communicate with one or more provisioning services. The device communicates the device ID to the provisioning service via the provisioning channel. The provisioning service confirms ownership of the device using the public device ID and transmits the encrypted configuration payload to the device via the constrained provisioning channel. The device decrypts the configuration payload using the private key associated with the public device ID and configures the device based on configuration parameters within the payload. In some implementations, the initial configuration payload communicated via the provisioning channel includes Wi-Fi SSID/password information for the customer's LAN (also referred to as “Wi-Fi channel connection parameters”), the device adjusts one or more parameters on the device such that the device connects to customer's LAN channel. When the device is connected to the customer's LAN, it can download additional configuration payloads, user data, etc.

Accordingly, the public key associated with the device is utilized to track ownership of the device (via an ownership record accessible by the provisioning service) and to prepare configuration payloads for devices upon transfer of a device to a customer. Furthermore, the public device ID and provisioning service is utilized to deprovision and reprovision the device for another customer. Because the configuration payloads are encrypted using the public key associated with the device storing the private key, the devices are prevented from being spoofed. These and other implementations are described below with reference to the figures.

FIG.1illustrates an example functional block diagram100for provisioning a device. The block diagram100includes a manufacturer102, vendor106, a customer108and provisioning services110. The manufacturer102manufactures one or more smart device. Example smart devices include, without limitations, smart appliances (e.g., refrigerators, stoves, ovens, scales, washers, dryers, toasters, blenders, coffee makers, juicers), smart light bulbs, smart electrical plugs, entertainment systems, security systems, smart thermostats, etc. Such devices are configured to connect to one or more networks, such as an internet, intranet, local area network (LAN), wide area network (WAN), cellular network (e.g., 3G, 4G, LTE), one or more other devices, etc. for downloading software and firmware updates, downloading/uploading user data, customization, communications, etc. In the illustrated functional block diagram100, the manufacturer102manufactures smart weight scale devices, but it should be understood that the described implementations are extendable to a variety of smart assets. Furthermore, the process illustrated in the functional block diagram100is described with respect to the parties (the manufacturer102, the vendor106, the provisioning services110, and the customer108) performing different actions. However, it should be understood that the processes described may be automated.

The manufacturer102issues one or more digital certificates to a device that are signed by a certificate authority (CA), which may be the manufacturer102or a CA employed by the manufacturer102. The certificates are signed using the CA's root of trust, which is a public key portion of a public/private key pair associated with the CA. Because the certificates are signed by the CA's root of trust, the certificates can be trusted by other devices or services communicating with the device. The CA's root of trust may be stored in read only memory (ROM) or write once, read many memory (WORM) that is accessible by a trusted execution environment (TEE) of the device. The certificates can include one or more keys that may be utilized for different purposes, such as encryption/decryption, secure communication sessions (e.g., SSL, TLS), endorsement, attestation, and authentication. For at least one of the one or more issued certificates, a public/private key pair is generated and signed with the root of trust. The different types of keys (e.g., the public/private key pair) may be generated using the root of trust in the TEE. The public key of the public/private key pair is utilized as cryptographic, globally unique device identification (ID). The private key is stored in a trusted platform module (TPM) of the device. The manufacturer102documents each public key and associates the public key with the respective devices in an ownership record. The smart scale120may utilize other cryptographic algorithms and functionality. For example, the device may utilize hashing algorithms (e.g., SHA-3, MD5) for confirming integrity of received payloads.

Furthermore, the manufacturer102can print the public key on the package of each device. For example, a smart scale package104contains a smart scale120associated with a public key112(12345), which is printed on the smart scale package104. It should be understood that the public key112may be printed via bar code, QR code, etc. The smart scale120in the smart scale package104securely stores, within a TPM of the smart scale120, a private key associated with the public key.

As the manufacturer102builds the devices, the manufacturer102stores and documents all public keys of the public/private key pairs associated with each device. Such documentation may include associating the public key with an owner of the associated device in an ownership record. The ownership record may be a database, cloud server, distributed database (e.g., blockchain), etc. As such. the public key acts as a cryptographic, globally unique device identification that is used to track ownership of the device. At this point in the illustrated process, the manufacturer102is the owner of the scales. When a vendor (e.g., the vendor106) orders an arbitrary number of smart scales. The manufacturer associates the arbitrary number of public keys with the vendor106. Such association may include updating a database, recording a transaction, etc. in the ownership record. The manufacturer102delivers a shipment of the arbitrary number of smart scales to the vendor106. The shipment includes the smart scale package104(with the smart scale120storing a private key associated with the public key12345). The vendor106receives a listing of smart scales as a list of public keys associated with each smart scale. When the vendor106receives the shipment, the vendor106checks (e.g., scans) each public key to confirm that the ordered scales are delivered.

The vendor106is any type of merchant that sells smart devices to companies, individuals, etc. Example vendors include, without limitation, an online shopping services, an electronics store, etc. One or more provisioning services110are utilized by the vendor106and/or the manufacturer102to track ownership (e.g., via the public keys and the ownership record) of the devices and to provide provisioning services to users of the devices. Example provisioning services include, without limitation, initial device setup, firmware/software updates, application installation and updates, user data tracking and updates, etc. The provisioning services may be provided by the vendor106, the manufacturer102, or may be a stand-alone provisioning service employed by the manufacturer102, the vendor106and/or the customer108.

In the illustrated example, the customer108purchases the smart scale120identified by the public key112in the smart scale package104, At which point, ownership of the smart scale120is transferred to the customer108via associating the public key112with the customer108in an ownership record accessible by the provisioning services110. For example, if the customer108purchases the smart scale120at an electronics store, the cashier at the electronics store associates the public key112to the customer, who may have a customer account. The customer account may have been previously submitted or created for a rewards program, gift card, etc. As such, the cashier may ask for user information (e.g., a phone number) to load (at the cash register) the customer account associated with the customer108. The cashier scans the public key to associate the public key with the customer account of the customer108. In this example, ownership is thereby transferred to the customer108and recorded in the ownership record. The account information is stored/managed by one of the provisioning services110, which may be associated with/managed by the vendor106or the manufacturer102. In another example purchasing scenario, the user purchases the smart scale120at on online retailer. The customer108is logged into the customer account associated with the customer108when the purchase is made. The online retailer associates the public key112with the customer account of the customer108. In the above described example, the account information of the customer108is linked to one or more of the provisioning services, which may be managed by the vendor106and/or the manufacturer or may be a stand-alone service.

Because the customer108has account information linked to one or more of the provisioning services110and ownership of the smart scale120is tracked by the one or more of the provisioning services110in an ownership record, the provisioning services110configures the smart scale120for the customer108based on customer preferences, account information, etc. stored in association with the ownership record. Example configuring includes packaging software/firmware updates, configuration information, etc. for transmission to the smart scale120. For example, the customer108prepays for a software upgrade, such as body mass index (BMI) tracking. As such, the provisioning services110packages the BMI tracking software for loading to the smart scale120when the smart scale120connects to the provisioning service.

In some example implementations, the smart scale120is configured to receive initial configuration information from the provisioning services110via a constrained provisioning channel when the smart scale120is powered on for the first time. The smart scale120is preconfigured with connection parameters (e.g., SSID/password information) for the provisioning channel. When the smart scale120is powered on, the smart scale connects to the provisioning channel and communicates with the provisioning services110. The smart scale120communicates the public key112to the provisioning services110via the provisioning channel. The provisioning service confirms ownership of the smart scale120using the public device ID and1614sends an encrypted configuration payload that includes minimal connection information containing one or more device configuration parameters for connecting the device to a Wi-Fi channel of the customer108. The device connects to the Wi-Fi channel of the customer using the device configuration parameters. After the smart scale120connects to the Wi-Fi channel, the smart scale120may receive additional data and software (e.g., large software/firmware updates, user data, user applications) from the provisioning services110.

The packaged software/firmware updates and/or configuration information (collectively “payloads”) for the customer108and the smart scale120are encrypted using the public key112associated with the smart scale120. Accordingly, when the smart scale120is eventually connected to the network, the smart scale120communicates the public key112to one or more of the provisioning services110. In response, the provisioning services110pushes an encrypted payload to the smart scale120. The smart scale120decrypts the payload using the private key stored on the smart scale120installs the updates or stores the data specific for the customer and device.

The use of the public/private key pair in such devices provides a number of benefits. The public key is used to track ownership of the device from the manufacturer102to the vendor106to the customer108. In other words, each transaction for a device is recorded by re-associating the public key with the next party in the transaction chain. Furthermore, because the device includes a private key, correct ownership is established. For example, if a device is stolen or illegally sold (e.g., from a delivery truck), the “transaction” (e.g., an update to the public key) is not recorded. Accordingly, when the device is eventually connected to the network and attempts communication with one of the provisioning services110, the provisioning services110detects that ownership has not been transferred. In response, the provisioning service110may take secure action by locking (e.g. bricking) the device with an update such that the unauthorized party is unable to use the device.

Furthermore, utilization of the public/private key pair prevents a device from being “spoofed.” For example, if a party tries to utilize a public key on a device without the associated private key, the device will not be able to decrypt a payload sent to the device. In other words, the ability to decrypt a payload sent to a device directly confirms the device's authorization to use the software/firmware updated and/or configuration information sent to the device.

In some example implementations, the provisioning services110can share an ownership record database or data store for the devices. Accordingly, a user can selectively utilize any one or more of the provisioning services110for device tracking, user customization, etc. Accordingly, the provisioning services110have access privileges to the ownership record to update ownership information for public keys associated with devices. A user is also able to link different types of accounts to the provisioning services110. For example, the customer108links social media accounts one of the provisioning services110that is connected to the purchased smart scale120. Accordingly, the provisioning services110are able to post a social media update when a weight loss goal is reached. Similarly, health tracking accounts may be linked to provisioning services that manage one or more user devices. For example, a smart refrigerator, toaster, blender, and scale may be linked to provisioning services110that have access to a health account information for tracking/updating user action. In some example implementations, device functionality may be limited by the provisioning services110and/or the device based on the purchase. For example, if the smart device is a smart storage device (e.g., an external solid state storage drive), the device may include 5 terabytes of storage. However, the customer108purchases 3 TB of storage when the device is purchased. As such, a configuration payload for the device includes configuration information that allows the user to use 3 TB of the 5 TB total for the device. The customer108may “upgrade” at a later time, and the provisioning services110prepares a configuration payload to unlock the additional 2 TB of storage. Additional functionality limitations are contemplated.

FIG.2illustrates another example functional block diagram200for provisioning a device. InFIG.2, a customer206has purchased a smart scale208that is associated with public key (not shown). When the customer206purchased the smart scale208, the public key associated with the smart scale is associated with a customer profile of the customer206in an ownership record accessible by one or more provisioning services202. In effect, ownership of the smart scale208is transferred to the customer206when the public key associated with the smart scale is associated to the customer profile. Because one or more of the provisioning services202(hereinafter “the provisioning service202”) have knowledge of the ownership transfer to the customer206, the provisioning service202can pre-prepare a configuration payload for the smart scale tailored for the customer206. An initial configuration payload may include the Wi-Fi channel connection information for a residence204of the customer206. Subsequent configuration payloads may include user data, applications, software/firmware updates, etc.

The residence204of the customer206includes a local area network accessible via a router210, for example. The router210includes a Wi-Fi channel212and a provisioning channel214. The Wi-Fi channel is a channel configured by the customer206to provide access to the internet for devices of the user. For example, the customer206may connect to the Wi-Fi channel212using a laptop, desktop, tablet, mobile device, gaming device etc. It should be understood that other LAN/WAN configurations are contemplated.

When the smart scale208is powered on for the first time, the smart scale208is not configured to connect to the Wi-Fi channel212of the customer206because the Wi-Fi channel212is protected by a SSID/password combination. The smart scale208is preconfigured with a SSID or other channel identification for the provisioning channel214. As such, when the smart scale208is powered on for the first time, the smart scale searches for the preloaded SSID for the provisioning channel214. If the provisioning channel214is located by the smart scale208, the smart scale208connects to the provisioning channel214. The smart scale208then communicates the public key associated with the smart scale208to the provisioning service202via the provisioning channel214. Because the provisioning service202has pre-prepared a configuration payload for the customer206based on the public key associated with the smart scale208, the provisioning service202transmits the encrypted configuration payload to the smart scale208. The configuration payload includes configuration information (e.g., SSID and password) to connect to the Wi-Fi channel212, which is not constrained relative to the provisioning channel214. As such, the smart scale208decrypts that configuration payload, configures one or more device parameters based on the configuration payload (e.g., Wi-Fi channel212configuration information), connects to the Wi-Fi channel212, and then receives larger additional configuration payloads, which may include firmware updates, applications, user data, etc.

The provisioning channel214is a constrained wired or wireless channel that is configured for smart device provisioning. The provisioning channel214is provided by the router210, by a separate router (not shown), by a router plugin (e.g., a dongle), or another device. The provisioning channel214is constrained to be connected to one or more destinations (e.g., the provisioning services202) and may be constrained by bandwidth, frequency speed, rate, etc. Furthermore, the provisioning channel214may be a hidden channel that is accessible by devices that are preconfigured with information regarding the hidden channel.

In some example implementations, a customer can connect the smart scale208to the router210or a modem (not shown) using a mobile, desktop, or web application, a user interface built into the device, and/or directly connects the smart scale208using an Ethernet, USB, etc. connection. In such implementations, the smart scale208communicates the public key to the provisioning service202. The provisioning service202transmits the encrypted configuration payload to the smart scale208. The smart scale208decrypts the configuration payload with the private key associated with the public key and configures one or more device parameters based on the configuration payload.

FIG.3illustrates another example functional block diagram300for provisioning a device. The functional block diagram300includes provisioning services302(hereinafter “the provisioning service302”), a customer residence304with a customer306, a router310, and a smart scale308. The customer306has powered on the smart scale308, which connected to a provisioning channel314of the router310. The router further includes a Wi-Fi channel312, which the smart scale308is not yet provisioned for (e.g., the smart scale308is not configured with configuration parameters for the Wi-Fi channel312). The smart scale308communicated its public key (e.g., public device ID) to the provisioning service302via the provisioning channel314. The provisioning service302locates the pre-prepared configuration payload using the public key and encrypts the configuration payload (or the configuration payload may have been previously encrypted) using the public key. The provisioning service302communicates the encrypted configuration payload to the smart scale308via the provisioning channel314. The configuration payload includes parameters for connecting the smart scale308to the Wi-Fi channel312. Thus, the smart scale308can use the parameters to connect to the Wi-Fi channel312to receive subsequent configuration payloads including software/firmware updates, user data, user applications, etc.

FIG.4illustrates another example functional block diagram400for provisioning a device. The functional block diagram400includes provisioning services402(hereinafter “the provisioning service402”), a customer residence404with a customer406, a router410, and a smart scale408. The customer406has powered on the smart scale408, which connected to a provisioning channel414of the router410. The smart scale408communicated its public key (e.g., public device ID) to the provisioning service402via the provisioning channel414. The provisioning service402located the pre-prepared configuration payload using the public key, encrypted the configuration payload (or the configuration payload may have been previously encrypted) using the public key. The provisioning service402communicated the encrypted configuration payload to the smart scale408via the provisioning channel414.

The smart scale408decrypts the configuration payload received from the provisioning service402using the private key associated with the public key. In this example implementation, the configuration payload includes device configuration parameters for connecting to the Wi-Fi channel412of the router410. The smart scale uses the device configuration parameters to connect to the Wi-Fi channel412and communicate with the provisioning service402. The provisioning service402packages (or has already pre-packaged) additional configuration packages including software/firmware updates, configuration information, user data, applications, etc., encrypts the payload, and communicates the payload to the smart scale408. In implementations where the configuration information includes the Wi-Fi channel412information, it should be understood that the customer406has provided, to the provisioning service402, the Wi-Fi information via a user account that is managed or is accessible by the provisioning service402. As such, additional devices purchased by the customer406are similarly provided such information via the provisioning channel414.

FIG.5illustrates another example functional block diagram500for provisioning a device. The functional block diagram500includes provisioning services502(hereinafter “the provisioning service502”), a customer residence504with a customer506, a router510, and a smart scale508. The customer506has powered on the smart scale508, which connected to a provisioning channel514of the router510. The smart scale508communicated its public key (e.g., public device ID) to the provisioning service502. The provisioning service502located the pre-prepared configuration payload using the public key, encrypted the configuration payload (or the configuration payload may have been previously encrypted) using the public key. The provisioning service502communicated the encrypted configuration payload to the smart scale508via the provisioning channel514. The smart scale508decrypts the encrypted configuration payload using the private key stored on the smart scale508and uses the configuration information to connect to the Wi-Fi channel512and communicate with the provisioning service502.

InFIG.5, the provisioning service502communicates additional configuration payloads, which may include software/firmware updates, user data, etc. to the smart scale508. Such additional configuration payloads are sometimes specific to the customer506based on a customer profile associated with the customer506and stored in an ownership record accessible by the provisioning service502. Because the smart scale508is connected to the Wi-Fi channel512, the smart scale508intermittently uploads user data to the provisioning service502, downloads firmware updates from the provisioning service502, etc. The user data (such as weight measurements) uploaded to the provisioning service502may be connected to a health account information accessible by the provisioning service502and usable by other smart devices.

FIG.6illustrates a block diagram600for a provisioning device614and a smart device622. The block diagram includes a communication network602, which includes various network components including, but not limited to, internet service network (ISP) components (e.g., edge servers), mobile communication network components, etc. A router604is communicatively connected to the communication network602via a wide area network (WAN) connector608. The router604further includes a Wi-Fi channel606, one or more universal serial bus (USB) ports (e.g., a USB port610), one or more Ethernet ports (e.g., an Ethernet port612). User devices, such as a laptop, mobile phone, smart TV, gaming systems etc., connect to the communication network602via the Wi-Fi channel606or the Ethernet port.

Furthermore, smart devices, such as a smart device622and other appliances, may connect to the communication network602using the Ethernet port612and/or the Wi-Fi channel606. Such devices that connect to the Wi-Fi channel606are configured with the Wi-Fi channel606information (e.g., SSID and password) for connecting to the Wi-Fi channel606. To configure a device to connect to the Wi-Fi channel a customer generally uses a display/user interface on the device to enter the SSID/password information for the Wi-Fi channel606.

InFIG.6the router604also includes the provisioning device614. The provisioning device614may be a component of the router604or may be a separate device that is communicatively connected to the router604. For example, the provisioning device614may be a dongle that has a power supply616that connects to the USB port610of the router for power. Furthermore, the provisioning device614may also include an Ethernet port618that is communicatively connected (e.g., via an Ethernet cable) to the Ethernet port612of the router604. It implementations where the provisioning device614is a component of the router, the provisioning device614may not include the power supply616or the Ethernet port618and may utilize such functionality within the router604.

The provisioning device614includes a provisioning channel620. The provisioning channel620may be a hidden wireless network channel or wired channel that is accessible by devices that a configured with information for the provisioning channel620. For example, when devices, such as the smart device622, are manufactured, information about the provisioning channel620may be programmed/loaded into a memory within the device. Accordingly, the provisioning channel information may be the same throughout provisioning devices.

The provisioning channel620is utilized by smart devices, such as the smart device622, to initially connected to one or more provisioning services (not shown). As such, the provisioning channel620is constrained to one or more destinations (e.g., provisioning services). In other words, the provisioning channel620is preconfigured to connect to the provisioning service via the communication network602. The provisioning channel620may be constrained in other ways for security reasons. For example, the provisioning channel620may be configured to “ping” a provisioning service once per minute or hour, for example. The provisioning channel620may also be constrained in speed or bandwidth. Accordingly, any nefarious actors may be deterred from using the provisioning channel620to gain unauthorized access to a device, a provisioning service, a router, etc. For example, if a nefarious actor attempts to utilize the provisioning channel to connect to the provisioning service many times in a short period, the provisioning service may be alerted to such unusual and unauthorized activity. As such, the provisioning service may take corrective action with the device, such as wiping/bricking the device. Furthermore, because the provisioning channel620is constrained in bandwidth, any attempted utilization of the provisioning channel620for unauthorized actions may be deterred by the slow speed.

Identification and connection information (e.g., SSID and password information) for the provisioning channel620is preloaded in a memory (not shown) of the smart device622. When the smart device622is powered on for the first time at a customer's residence (or elsewhere), a configuration interface624of the smart device622utilizes the identification and connection information for the provisioning channel620to connect to the provisioning channel620. The configuration interface624communicates the public key associated with the smart device622to a provisioning service via the provisioning channel620and according to the implemented constraints (e.g., once in an hour). In response, the provisioning service returns an encrypted configuration payload to a payload manager632of the smart device622via the provisioning channel620. The configuration payload is encrypted using the public key associated with the smart device622. Accordingly, a decryption engine636of the smart device622utilizes the cryptographically associated private key to decrypt the received configuration payload. The configuration payload includes a LAN connection parameters (e.g., SSID and password) for the Wi-Fi channel606. Accordingly, a device configuration manager623of smart device622utilizes the LAN connection parameters to connect the smart device622the Wi-Fi channel606. The smart device622then communicates with the provisioning service through the Wi-Fi channel606to send/receive larger amounts of data (relative to data sent through the constrained provisioning channel620). Because the smart device622connects to the Wi-Fi channel606using the encrypted configuration payload, the smart device622implicitly confirms its identity (e.g., public/private key pair) to the provisioning service. The smart device622can then use the Wi-Fi channel606to download applications, software/firmware updates, send/receive customer data, etc. In some example implementations, the smart device622periodically reconnects to the provisioning channel620and the provisioning service to reconfirm the identity, download new configuration payloads, etc. Accordingly, the provisioning channel periodically confirms and document authorization and identity of a customer and/or devices.

The private key cryptographically associated with the public key is securely stored in a trusted platform module630executed in the trusted execution environment628of the device. A decryption engine636utilizes the private key stored in the trusted platform module630to decrypt the received configuration payload. The trusted execution environment628is embodied in processor-executable instructions stored in a read only memory (ROM) of the smart device622. Thus, the trusted execution environment628is securely shielded from unauthorized access/updates.

In some example implementations, the provisioning channel620may be utilized by the smart device622for receiving limited amounts and/or types data. For example, the provisioning channel620may be configured with a current time/clock information such that he smart device622is synced with other devices and networks. Furthermore, it is contemplated that the provisioning channel620may transmit stock ticker information to the smart device622(e.g., if the smart device is a smart mirror, the smart mirror can display the stock ticker information). Other limited data examples are contemplated. In such implementations, the provisioning device614may include a plurality of different provisioning channels, each limited to a particular server/destination (e.g., a clock server, a provisioning server, a stock ticker server).

FIG.7illustrates an example block diagram700for deprovisioning and reprovisioning a device. The block diagram700includes a user A702, who is selling a smart scale706to a user B704. To transfer ownership of the smart scale706to the user B704, the user A702utilizes a device710(e.g., a mobile device, laptop, desktop) to inform a provisioning service708to associate the public key of the smart scale706to the user B. The user A702may utilize a dedicated provisioning application, application for a manufacturer of the smart scale706, or a vendor application to transfer ownership. The user A702may input identifying information about the user B704(e.g., a phone number, email address) into the application to transfer the ownership. In some implementations, the user A702instructs the vendor (e.g., in person or online) to transfer ownership to the User B704. When the user A702informs the provisioning service708to re-associate the public key, the user A702is, in effect, deprovisioning and reprovisioning the device. The provisioning service708transfers ownership to the user B704by associating the public key of the smart scale706to the user B704(e.g., user B's account). In some implementations, the provisioning service708authorizes the user A702and/or the user B704before transferring ownership. Such authorization may include asking for username and/or password for the provisioning service, receiving a private key signed certificate from the smart scale706, etc.

It should be understood that similar implementations may be used to “deprovision” a smart device such that ownership of the device is not associated with a particular user or party. For example, the user A702may wish to sell the smart scale706in a yard sale, but the user A702has no knowledge of the potential buyer. Accordingly, the user A702can elect to “deprovision” the smart scale706using the device710. The provisioning service708disassociates the public key from the user A702and instructs the smart scale706to erase in data associated with the user A702. Accordingly, the smart scale706is in an unclaimed or owned state. Any subsequent user may provision the smart scale706for themselves.

FIG.8illustrates another example block diagram800for deprovisioning and reprovisioning a device. The block diagram800includes a user A802, who is selling a smart scale806to a user B804. To transfer ownership of the smart scale806to the user B804, the user A802utilizes a device (e.g., a mobile device, laptop, desktop) to inform a provisioning service808to associate the public key of the smart scale806to the user B804. In response, the provisioning service808instructs the smart scale806to wipe/delete any user data and configuration information associated with the user A802. The provisioning service808may further instruct the smart scale806to delete any software/firmware updates and applications downloaded to the smart scale806in association with the user A802. If the smart scale806has already been disconnected (e.g., not connected to a network), then the smart scale806receives such instructions when it is powered on. The provisioning service808pre-prepares a configuration payload tailored for the user B804. The configuration payload may be tailored based on a profile associated with the user B804that the provisioning service808manages or has access to. The profile may include the User B's SSID/password for a Wi-Fi channel in the user B's residence. As such, the configuration payload may include the SSID/password information for the user B804.

In some situations, different users may utilize different provisioning services for device provisioning. For example, the user A802utilizes a vendor A provisioning service, and user B804utilizes vendor B provisioning service. As such, each of the provisioning services may be configured to share a database of public keys to track ownership of devices. In some example implementations, the provisioning services share a blockchain (e.g., distributed database). When the user A802sells the smart scale to the user B804, the user A informs the user A provisioning service of the transfer to user B. The vendor A provisioning service records the transaction to the shared blockchain. The transaction may include identifying information for user B (e.g., a public key provisioned for the user B804, email, phone number, etc.). Because the vendor B provisioning service has access to the shared blockchain, the vendor B provisioning service is alerted to the transaction (e.g., because it includes information regarding the user B804, who is registered with the vendor B provisioning service). Thus, the vendor B provisioning service pre-pares a configuration payload for the user B804. Similarly, the users themselves may record the transaction to the blockchain, which may alert both provisioning services to the transaction. Similar processes may be utilized in a data store, database, etc. storing public key ownership information and linked or stored associated with customer accounts with configuration data.

FIG.9illustrates another example block diagram900for deprovisioning and reprovisioning a device. The block diagram900includes a user A902, who is selling a smart scale906to a user B904. To transfer ownership of the smart scale906to the user B904, the user A902utilizes a device (e.g., a mobile device, laptop, desktop) to inform a provisioning service708to associate the public key of the smart scale906to the user B904. The user B904powers on the smart scale906. In some example implementations, the smart scale906connects to a IoT provisioning channel. In some example implementations, the user B904configures the smart scale906to connect to a Wi-Fi channel. The smart scale906connects to the provisioning service908(e.g., via Wi-Fi or provisioning channel), a communicates the public key associated with the smart scale to the provisioning service908. In response, the provisioning service send encrypted configuration payload to the smart scale906. The encrypted configuration information may include SSID/password for a Wi-Fi channel of the user B904, software/firmware updates, applications, user data, etc. Because the smart scale906has access to the private key associated with the public key use to encrypt the configuration payload, the smart scale906decrypts and installs the configuration information. Furthermore, because the smart scale906is able to decrypt the configuration payload, the smart scale906implicitly confirms the identity of the smart scale906.

FIG.10illustrates example operations1000for manufacturing and initializing a device for provisioning. A manufacturing1002operation manufactures a device. An installing operation1004installs a public/private key pair in a trusted environment within the device. The trusted environment may be a trusted execution environment (TEE) or a trusted platform module (TPM). Such installation may include directing the device to generate/authenticate the public/private key pair based on a seed value, etc. The private key is stored in a secure location and may be further secured by one or more policies for a TPM. A storing operation1006stores the public key as a public device identification (ID) for the device. A communicating operation1008communicates the public device identification to a provisioning service. Such communication may include an indication to associate ownership of the device (e.g., via the public key) to the manufacturer. The communicating operation1008may occur after a vendor purchases a device, and as such, the communication may indicate to associate the public key to the vendor (e.g., record ownership transaction).

FIG.11illustrates example operations1100for provisioning a device. The device has been purchased by a user and includes a public/private key pair. The public key is utilized a public device identification (ID). The private key is stored in a trusted portion of the device, such as a trusted platform module (TPM). A receiving operation1102receives power at the device. A connecting operation1104connects to a provisioning channel based on provisioning channel information stored in the device. The provisioning channel information (e.g., ID) may be installed in the device when the device is manufactured. A communicating operation1106communicates the public device ID to a provisioning service using the provisioning channel. The provisioning service has previously associated the public device ID to the user of the device based on a recorded transaction involving the user (e.g., the user purchased the device from the vendor).

A receiving operation1108receives an encrypted configuration payload from the provisioning channel. The encrypted configuration payload is encrypted using the public device ID. The provisioning channel prepares the configuration payload according to user account information that is now associated with the public ID. The configuration payload is tailored for the user based on the profile information and may include Wi-Fi information for connecting the user's personal Wi-Fi channel. A decrypting operation1110decrypts the encrypted configuration payload using the private key associated with the public device ID. An adjusting operation1112adjusts one or more device parameters based on the configuration payload. In some implementations, the configuration payload includes information (e.g., SSID/password) information for connecting to the user's Wi-Fi channel. As such, device parameters may include a Wi-Fi connecting SSID and password for connecting to the Wi-Fi Channel In some example implementations, the user configures the device by inputting the Wi-Fi information into the device (e.g., via a connected computing device or user interface in the device). A connecting operation1114connects to the Wi-Fi channel based on the information received in the configuration payload. A receiving operation1116receives additional payloads from the provisioning service. Such additional payloads may be encrypted using the public device ID. A communicating operation1118communicates user data to the provisioning service. Such data may be encrypted and signed using the private key associated with device's public key. As such, the provisioning service can verify that the user data is received from the device.

FIG.12illustrates example operations1200for provisioning a device. Specifically,FIG.12illustrates device provisioning from the perspective of a provisioning service. A receiving operation1202receives a public key associated with a device from a manufacturer. The manufacturer has manufactured the device and installed a public/private key pair in the device and stored the public key as a public device identification (ID). A receiving operation1204receives transaction information indicating a transfer of the device to a vendor. The transaction includes the public key (public device ID) and the receiving party (e.g., the vendor). A recording operation1206records the transaction by associating the public key to the vendor. Another receiving operation1208receives transaction information indicating a transfer of the device to a user. Another recording operation1210records the transaction by associating the public key to the user. The user may have an associated customer profile managed by the provisioning service or accessible by the provisioning service. Accordingly, a preparing operation1212prepares a configured payload for the device specific to the user (e.g., customer) and the device. The configuration payload may include the user's Wi-Fi information (e.g., SSID/password) for connecting to the user's Wi-Fi. An encrypting operation1214encrypts the configuration payload using the public key associated with the device.

A receiving operation1216receives a communication from the device. The communication may include the devices public key (or may include data signed by the private key associated with the public key). The communication may be received via a constrained provisioning channel. The provisioning service determines that the received public key (e.g., the public device ID) matches a public device ID stored ownership record accessible by the provisioning service. Furthermore, one or more device configuration parameters may be stored in association with the ownership record (e.g., in connection with a user/customer account). The one or more device configuration parameters may be stored in the ownership record itself, stored in the user account in another location and linked to the ownership record, etc. A sending operation1218sends the encrypted configuration payload to the device. If the public device ID is not stored in the ownership record or is not confirmed to be associated with a user or customer, then the provisioning service does not send the encrypted configuration payload and may take corrective action because the device may be stolen. A receiving operation1220receives subsequent communication from the device. The receiving operation1220may be received over an un-constrained channel. The subsequent communications may be signed by the device's private key. A sending operation1222sends additional encrypted payloads to the device. The additional payloads may include software/firmware updates, applications, user data, etc.

FIG.13illustrates example operations1300for deprovisioning and reprovisioning a device. A receiving operation1302receives instruction from a first user to reprovisioning a device to a second user. The device has a public key (a public device identification (ID)) and a private key. An instructing operation1304instructs the device to delete information associated with the first user. Such information may include Wi-Fi information, applications, user data, software updates, etc. If the device is offline, the instruction will be sent when the device is online. A locating operation1306locates or receives information for the second user. The first user may utilize an application or website to send the second user's information (e.g., phone number, email, etc.) to the provisioning service. If the second user does not have an account with (or accessible by) the provisioning service, the second user may be instructed to register with the provisioning service.

An associating operation1308associates the public key with the second user. The associating operation1308effectively records the transaction between the first user and the second user and transfers ownership of the device from the first user to the second user. A preparing operation1310prepares a configuration payload for the deice tailored for the second user. The configuration payload may include the second user's Wi-Fi information that is associated with the second user's account. An encrypting operation1312encrypts the payload using the public key. A receiving operation1314receives a communication from the device. The communication includes the device's public key or includes data signed by the device's private key, effectively confirming the data is received from the device and that the device is connected to the network. A sending operation1316sends the encrypted payload to the device. A receiving operation1318receives subsequent communications from the device. The subsequent communications may include user data signed by the device's private key. A sending operation1320sends additional encrypted payloads to the device, which may include user data, applications, software/firmware updates, etc.

FIG.14illustrates an example system (labeled as a processing system1400) that may be useful in implementing the described technology. The processing system1400may be a client device, such as a laptop, mobile device, desktop, tablet, or a server/cloud device, such as a server for a provisioning service. The processing system1400includes one or more processor(s)1402, and a memory1404. The memory1404generally includes both volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). An operating system1410resides in the memory1404and is executed by the processor1402. The memory1404includes a read only memory (ROM)1414, which may be, in some implementations, write once, read many (WORM) memory.

One or more application programs1412modules or segments, such as a provisioning service1446(e.g., if the processing system1400is a server device), a provisioning application1444(e.g., if the processing system is a user devices, such as a mobile device), or a device application1448(e.g., a provisioning manager or user application) are loaded in the memory1404and/or storage1420and executed by the processor1402. A trusted execution environment1450is stored in the ROM1414and executed by the processor1402. Data, such as public keys (e.g., public device IDs), customer profiles, user data, encryption keys, private keys, user preferences, ownership records, etc. may be stored in the memory1404or storage1420and may be retrievable by the processor1402for use in the by the provisioning service1446, the provisioning application1444, or the device application1448, etc. The storage1420may be local to the processing system1400or may be remote and communicatively connected to the processing system1400and may include another server. The storage1420may store resources that are requestable by client devices (not shown).

The processing system1400includes a power supply1416, which is powered by one or more batteries or other power sources and which provides power to other components of the processing system1400. The power supply1416may also be connected to an external power source that overrides or recharges the built-in batteries or other power sources.

The processing system1400may include one or more communication transceivers1430which may be connected to one or more antenna(s)1432to provide network connectivity (e.g., mobile phone network, Wi-Fi®, Bluetooth®, etc.) to one or more other servers and/or client devices (e.g., mobile devices, desktop computers, or laptop computers). The processing system1400may further include a network adapter1436, which is a type of communication device. The processing system1400may use the network adapter1436and any other types of communication devices for establishing connections over a wide-area network (WAN) or local-area network (LAN). It should be appreciated that the network connections shown are exemplary and that other communications devices and means for establishing a communications link between the processing system1400and other devices may be used.

The processing system1400may include one or more input devices1434such that a user may enter commands and information (e.g., a keyboard or mouse). These and other input devices may be coupled to the server by one or more interfaces1438, such as a serial port interface, parallel port, universal serial bus (USB), etc. The processing system1400may further include a display1422, such as a touch screen display.

The processing system1400may include a variety of tangible processor-readable storage media and intangible processor-readable communication signals. Tangible processor-readable storage can be embodied by any available media that can be accessed by the processing system1400and includes both volatile and nonvolatile storage media, removable and non-removable storage media. Tangible processor-readable storage media excludes intangible communications signals and includes volatile and nonvolatile, removable and non-removable storage media implemented in any method or technology for storage of information, such as processor-readable instructions, data structures, program modules or other data. Tangible processor-readable storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible medium which can be used to store the desired information and which can be accessed by the processing system1400. In contrast to tangible processor-readable storage media, intangible processor-readable communication signals may embody computer-readable instructions, data structures, program modules or other data resident in a modulated data signal, such as a carrier wave or other signal transport mechanism. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, intangible communication signals include signals traveling through wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media.

In at least one implementation, an example device includes one or more processors, a configuration interface executable by the one or more processors, a payload manager executable by the one or more processors, a decryption engine executable by the one or more processors, and a device configuration manager executable by the one or more processors. The configuration interface is configured to communicate a public device ID to a provisioning service. The public device ID is cryptographically associated with a private key securely stored in the device. A user is identified as owner of the device based on an ownership record and the public device ID. One or more device configuration parameters specific to the user and the device are stored in association with the ownership record. The payload manager is configured to receive an encrypted configuration payload from the provisioning service, the configuration payload containing the one or more device configuration parameters specific to the user and the device. The encrypted configuration payload is encrypted using the public device ID cryptographically associated with the private key securely stored in the device. The decryption engine is configured to decrypt the encrypted configuration payload using the private key securely stored on the device and cryptographically associated with the public device ID communicated to the provisioning service. The device configuration manager is configured to configure the device according to the one or more device configuration parameters received in the configuration payload.

Another example device of any preceding device includes the public device ID being communicated to the provisioning service via a provisioning channel, and the encrypted configuration payload is received via the provisioning channel. The provisioning channel is configured to communicate with a predefined selection of destinations.

Another example device of any preceding device includes the configuration interface being further configured to, upon receiving power at the device, communicatively connect to a provisioning channel associated with a provisioning channel ID stored on the device prior to receiving the power at the device. The public device ID is communicated via the provisioning channel, and the encrypted configuration payload is received via the provisioning channel.

Another example device of any preceding device includes the encrypted configuration payload received via the provisioning channel includes local area network (LAN) connection parameters for connecting to a LAN. The configuration interface is further configured to communicatively connect to the LAN using the LAN parameters received in the encrypted configuration payload.

Another example device of any preceding device includes the encrypted configuration payload received via the provisioning channel includes local area network (LAN) connection parameters for connecting to a LAN. The configuration interface is further configured to communicatively connect to the LAN using the LAN parameters received in the encrypted configuration payload. The payload manager is further configured to receive an additional configuration payload from the provisioning service via the LAN, the additional configuration payload containing additional one or more device parameters specific to the user and the device stored in associated with in the ownership record.

Another example device of any preceding device includes the configuration manager being further configured to limit functionality of the device based on the encrypted configuration payload received from the provisioning service.

An example method includes communicating a public device ID to a provisioning service from the device. The public device ID is cryptographically associated with a private key securely stored in the device. A user is identified as owner of the device based on an ownership record and the public device ID. One or more device configuration parameters specific to the user and the device are stored in association with the ownership record. The method further includes receiving, at the device from the provisioning service, an encrypted configuration payload containing the one or more device configuration parameters. The encrypted configuration payload is encrypted using the public device ID cryptographically associated with the private key securely stored in the device. The method further includes decrypting, on the device, the encrypted configuration payload using the private key securely stored on the device and cryptographically associated with the public device ID communicated to the provisioning service. The method further includes configuring the device according to the one or more device configuration parameters received in the configuration payload.

Another example method of any preceding method includes the public device ID being communicated to the provisioning service via a provisioning channel, and the encrypted configuration payload being received via the provisioning channel. The provisioning channel is configured to communicate with a predefined selection of destinations.

Another example method of any preceding method includes receiving power at the device, a provisioning channel ID stored on the device prior to receiving the power at the device, and communicatively connecting to a provisioning channel associated with the provisioning channel ID. The public device ID is communicated via the provisioning channel, and the encrypted configuration payload is received via the provisioning channel.

Another example method of any preceding method includes the encrypted configuration payload received via the provisioning channel including local area network (LAN) connection parameters for connecting to a LAN. The method further includes communicatively connecting to the LAN using the LAN connection parameters received in the encrypted configuration payload and receiving an additional configuration payload from the provisioning service via the LAN. The additional configuration payload contains one or more additional device parameters specific to the user and the device stored in association with the ownership record.

Another example method of any preceding method includes functionality of the device being limited based on the encrypted configuration payload received from the provisioning service.

Another example method of any preceding method includes the public device ID being a public key cryptographically associated with the private key as a public/private key pair.

Another example method of any preceding method includes the provisioning service identifying the user as the owner of the device based on a determination of whether a public device ID stored in the ownership record matches the public device ID communicated by the device.

An example device includes means for communicating a public device ID to a provisioning service from the device. The means supporting the public device ID being cryptographically associated with a private key securely stored in the device. A user is identified as owner of the device based on an ownership record and the public device ID. One or more device configuration parameters specific to the user and the device are stored in association with the ownership record. The device further includes means for receiving, at the device from the provisioning service, an encrypted configuration payload containing the one or more device configuration parameters. The encrypted configuration payload is encrypted using the public device ID cryptographically associated with the private key securely stored in the device. The device further includes means for decrypting, on the device, the encrypted configuration payload using the private key securely stored on the device and cryptographically associated with the public device ID communicated to the provisioning service. The device further includes means for configuring the device according to the one or more device configuration parameters received in the configuration payload.

Another example device of any preceding device further includes means for the public device ID being communicated to the provisioning service via a provisioning channel, and the encrypted configuration payload being received via the provisioning channel. The provisioning channel is configured to communicate with a predefined selection of destinations.

Another example device of any preceding device further includes means for receiving power at the device, a provisioning channel ID stored on the device prior to receiving the power at the device, and means for communicatively connecting to a provisioning channel associated with the provisioning channel ID. The public device ID is communicated via the provisioning channel, and the encrypted configuration payload is received via the provisioning channel.

Another example device of any preceding device further includes means for the encrypted configuration payload received via the provisioning channel including local area network (LAN) connection parameters for connecting to a LAN. The device includes means for communicatively connecting to the LAN using the LAN connection parameters received in the encrypted configuration payload and means for receiving an additional configuration payload from the provisioning service via the LAN. The additional configuration payload contains one or more additional device parameters specific to the user and the device stored in association with the ownership record.

Another example device of any preceding device further includes means for functionality of the device being limited based on the encrypted configuration payload received from the provisioning service.

Another example device of any preceding device further includes means for the public device ID being a public key cryptographically associated with the private key as a public/private key pair.

Another example device of any preceding device further includes means for the provisioning service identifying the user as the owner of the device based on a determination of whether a public device ID stored in the ownership record matches the public device ID communicated by the device.

One or more tangible processor-readable storage media embodied with instructions for executing on one or more processors and circuits of a device a process comprising communicating a public device ID to a provisioning service from the device. the public device ID being cryptographically associated with a private key securely stored in the device, a user being identified as owner of the device based on an ownership record and the public device ID, one or more device configuration parameters specific to the user and the device being stored in association with the ownership record. The process further comprises receiving, at the device from the provisioning service, an encrypted configuration payload containing the one or more device configuration parameters specific to the user and the device, the encrypted configuration payload further being encrypted using the public device ID cryptographically associated with the private key securely stored in the device. The process further comprises decrypting, on the device, the encrypted configuration payload using the private key securely stored on the device and cryptographically associated with the public device ID communicated to the provisioning service. The computer further comprises configuring the device according to the one or more device configuration parameters received in the configuration payload.

Another example tangible processor-readable storage media embodied with instructions for executing on one or more processors and circuits of a device a process of any preceding process further includes the public device ID being communicated to the provisioning service via a provisioning channel and the encrypted configuration payload is received via the provisioning channel, the provisioning channel being configured to communicate with a predefined selection of destinations.

Another example tangible processor-readable storage media embodied with instructions for executing on one or more processors and circuits of a device a process of any preceding process further includes receiving power at the device, a provisioning channel ID stored on the device prior to receiving the power at the device, and communicatively connecting to a provisioning channel associated with the provisioning channel ID, the public device ID is communicated via a provisioning channel and the encrypted configuration payload is received via the provisioning channel.

Another example tangible processor-readable storage media embodied with instructions for executing on one or more processors and circuits of a device a process of any preceding process further includes the encrypted configuration payload being received via the provisioning channel includes local area network (LAN) connection parameters. The process further includes communicatively connecting to the LAN using the LAN connection parameters received in the encrypted configuration payload, and receiving an additional configuration payload from the provisioning service via the LAN, the additional configuration payload containing one or more additional device parameters specific to the user and the device stored in association with the ownership record.

Another example tangible processor-readable storage media embodied with instructions for executing on one or more processors and circuits of a device a process of any preceding process further includes the provisioning service identifying the user as the owner of the device based on a determination of whether a public device ID stored in the ownership record matches the public device ID communicated by the device.

Another example tangible processor-readable storage media embodied with instructions for executing on one or more processors and circuits of a device a process of any preceding process further includes the public device ID is a public key cryptographically associated with the private key as a public/private key pair.

Some embodiments may comprise an article of manufacture. An article of manufacture may comprise a tangible storage medium to store logic. Examples of a storage medium may include one or more types of processor-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of the logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, operation segments, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. In one embodiment, for example, an article of manufacture may store executable computer program instructions that, when executed by a computer, cause the computer to perform methods and/or operations in accordance with the described embodiments. The executable computer program instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The executable computer program instructions may be implemented according to a predefined computer language, manner or syntax, for instructing a computer to perform a certain operation segment. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.

The implementations described herein are implemented as logical steps in one or more computer systems. The logical operations may be implemented (1) as a sequence of processor-implemented steps executing in one or more computer systems and (2) as interconnected machine or circuit modules within one or more computer systems. The implementation is a matter of choice, dependent on the performance requirements of the computer system being utilized. Accordingly, the logical operations making up the implementations described herein are referred to variously as operations, steps, objects, or modules. Furthermore, it should be understood that logical operations may be performed in any order, unless explicitly claimed otherwise or a specific order is inherently necessitated by the claim language.