Patent Description:
IoT devices are physical or virtualized objects that may communicate on a network, and may include sensors, actuators, and other input/output components, such as to collect data or perform actions from a real-world environment. For example, IoT devices may include low-powered devices that are embedded or attached to everyday things, such as buildings, vehicles, packages, etc., to provide an additional level of artificial sensory perception of those things. Recently, IoT devices have become more popular and thus applications using these devices have proliferated.

Various standards have been proposed to more effectively interconnect and operate IoT devices and to enable new types of IoT network use cases. These include the specialization of communication standards distributed by groups such as Institute of Electrical and Electronics Engineers (IEEE) or Zigbee, and the specialization of application interaction architecture and configuration standards distributed by groups such as the Open Connectivity Foundation (OCF). In addition to these standards, a variety of services and applications are being actively developed and deployed in cloud service platforms and other remote computing systems, for managing data and commands exchanged with IoT devices. Document <CIT> relates to interconnected device networks, and to techniques for establishing connections and implementing functionality among Internet of things (IoT) devices and device networks. Document <CIT> relates to interconnected device networks, and in particular, to techniques for establishing connections and implementing functionality among internet of things (IoT) devices and device networks.

In the following description, methods, configurations, and related apparatuses are disclosed for implementing access and authorization for IoT device services in a multiple cloud service scenario. Specifically, the techniques enable the accessibility of various data services, functions, and APIs provided by cloud services operating in different operational domains, such as different domains hosted by different service providers or companies (e.g., between Cloud <NUM> hosted for/by Company A and providing device service APIs for use by a first set of IoT devices manufactured or serviced by Company A, and Cloud <NUM> hosted for/by Company B and providing device service APIs for use by a second set of IoT devices manufactured or serviced by Company B); or for different groups or domains of IoT established for a user, organization, or entity (e.g., a user who has sets of trusted versus guest/untrusted devices; an organization which has different groups of users; etc.).

With the present techniques and system configurations, information relevant to cloud service connectivity can be shared and validated over the local network with minimal or no user involvement. Such capabilities enable closed-loop validation of user identity, device identity and cloud service account identity to be initiated via the local network, as the loop is closed via the appropriate cloud-to-cloud connectivity established between services. Also, with the present techniques and system configurations, the necessary credentials and configurations for device-to-device and cloud-to-cloud communications and communication pathways can be automatically set up and used, without the need for a user to configure or authenticate to individual services.

The disclosed approaches provide a far easier (and, more secure) result for linking accounts and device services than conventional approaches. The disclosed approaches also enable the deployment of automated data exchanges and services, or enhanced user commands to discover or link accounts. These enhanced user commands may occur based on user prompts asking a user, "do you wish to link devices. ?", based on a user-selected "connect all available cloud services" option, or based on other forms of rules or client inputs. The disclosed approaches are also scalable to many types and forms of client devices, cloud services, and ecosystem entities.

Many developing IoT standards, such as those proposed by OCF, envision that devices from multiple different manufacturers will be discoverable and controllable via local network connectivity once the devices are provisioned with appropriate security information. After provisioning on a local network, such devices will also become connected to their manufacturer's or service provider's cloud services, either via proprietary protocols or cloud versions of network protocols (e.g., OCF protocols); the ability for these devices' cloud services to easily interact with each other and exchange data is also expected to be an important use case.

The following techniques provide a modification to the behavior and operation of current device-to-device and device-to-cloud communication sequences, which enables cloud-to-cloud integration among different manufacturer or service provider services. This enables different types and manufacturers of devices or service providers to have accounts and services easily linked and integrated with one another. As a result, an enhanced user experience for onboarding and provisioning devices to services, which enables cloud-to-cloud integration among a variety of different services and service types-and without the use of open authorization services (e.g., which exchange OAuth tokens) or complicated sign-in procedures-may be provided.

<FIG> illustrates an example domain topology for respective IoT networks coupled through links to respective gateways. The IoT supports deployments in which a large number of computing devices are interconnected to each other and to the Internet to provide functionality and data acquisition at very low levels. Thus, as used herein, an IoT device may include a semiautonomous device performing a function, such as sensing or control, among others, in communication with other IoT devices and a wider network, such as the Internet.

Often, IoT devices are limited in memory, size, or functionality, allowing larger numbers to be deployed for a similar cost to smaller numbers of larger devices. However, an IoT device may be a smart phone, laptop, tablet, or PC, or other larger device. Further, an IoT device may be a virtual device, such as an application on a smart phone or other computing device. IoT devices may include IoT gateways, used to couple IoT devices to other IoT devices and to cloud applications, for data storage, process control, and the like.

Networks of IoT devices may include commercial and home automation devices, such as water distribution systems, electric power distribution systems, pipeline control systems, plant control systems, light switches, thermostats, locks, cameras, alarms, motion sensors, and the like. The IoT devices may be accessible through remote computers, servers, and other systems, for example, to control systems or access data.

The future growth of the Internet and like networks may involve very large numbers of IoT devices. Accordingly, in the context of the techniques discussed herein, a number of innovations for such future networking will address the need for all these layers to grow unhindered, to discover and make accessible connected resources, and to support the ability to hide and compartmentalize connected resources. Any number of network protocols and communications standards may be used, as each protocol and standard is designed to address specific objectives. Further, the protocols are part of the fabric supporting human accessible services that operate regardless of location, time or space. The innovations include service delivery and associated infrastructure, such as hardware and software; security enhancements; and the provision of services based on Quality of Service (QoS) terms specified in service level and service delivery agreements. As will be understood, the use of IoT devices and networks, such as those introduced in <FIG> and <FIG>, present a number of new challenges in a heterogeneous network of connectivity comprising a combination of wired and wireless technologies.

<FIG> specifically provides a simplified drawing of a domain topology that may be used for a number of IoT networks comprising IoT devices <NUM>, with the IoT networks <NUM>, <NUM>, <NUM>, <NUM>, coupled through backbone links <NUM> to respective gateways <NUM>. For example, a number of IoT devices <NUM> may communicate with a gateway <NUM>, and with each other through the gateway <NUM>. To simplify the drawing, not every IoT device <NUM>, or communications link (e.g., link <NUM>, <NUM>, <NUM>, or <NUM>) is labeled. The backbone links <NUM> may include any number of wired or wireless technologies, including optical networks, and may be part of a local area network (LAN), a wide area network (WAN), or the Internet. Additionally, such communication links facilitate optical signal paths among both IoT devices <NUM> and gateways <NUM>, including the use of MUXing/deMUXing components that facilitate interconnection of the various devices.

The network topology may include any number of types of IoT networks, such as a mesh network provided with the network <NUM> using Bluetooth low energy (BLE) links <NUM>. Other types of IoT networks that may be present include a wireless local area network (WLAN) network <NUM> used to communicate with IoT devices <NUM> through IEEE <NUM> (Wi-Fi®) links <NUM>, a cellular network <NUM> used to communicate with IoT devices <NUM> through an LTE/LTE-A (<NUM>) or <NUM> cellular network, and a low-power wide area (LPWA) network <NUM>, for example, a LPWA network compatible with the LoRaWan specification promulgated by the LoRa alliance, or a IPv6 over Low Power Wide-Area Networks (LPWAN) network compatible with a specification promulgated by the Internet Engineering Task Force (IETF). Further, the respective IoT networks may communicate with an outside network provider (e.g., a tier <NUM> or tier <NUM> provider) using any number of communications links, such as an LTE cellular link, an LPWA link, or a link based on the IEEE <NUM>. <NUM> standard, such as Zigbee®. The respective IoT networks may also operate with use of a variety of network and internet application protocols such as Constrained Application Protocol (CoAP). The respective IoT networks may also be integrated with coordinator devices that provide a chain of links that forms cluster tree of linked devices and networks.

Each of these IoT networks may provide opportunities for new technical features, such as those as described herein. The improved technologies and networks may enable the exponential growth of devices and networks, including the use of IoT networks integrated into "fog" or "edge cloud" devices or systems. As the use of such improved technologies grows, the IoT networks may be developed for self-management, functional evolution, and collaboration, without needing direct human intervention. The improved technologies may even enable IoT networks to function without centralized controlled systems. Accordingly, the improved technologies described herein may be used to automate and enhance network management and operation functions far beyond current implementations.

In an example, communications between IoT devices <NUM>, such as over the backbone links <NUM>, may be protected by a decentralized system for authentication, authorization, and accounting (AAA). In a decentralized AAA system, distributed payment, credit, audit, authorization, and authentication systems may be implemented across interconnected heterogeneous network infrastructure. This enables systems and networks to move towards autonomous operations. In these types of autonomous operations, machines may even contract for human resources and negotiate partnerships with other machine networks. This may enable the achievement of mutual objectives and balanced service delivery against outlined, planned service level agreements as well as achieve solutions that provide metering, measurements, traceability and trackability. The creation of new supply chain structures and methods may enable a multitude of services to be created, mined for value, and collapsed without any human involvement.

Such IoT networks may be further enhanced by the integration of sensing technologies, such as sound, light, electronic traffic, facial and pattern recognition, smell, or vibration, into the autonomous organizations among the IoT devices. The integration of sensory systems may enable systematic and autonomous communication and coordination of service delivery against contractual service objectives, orchestration and QoS-based swarming and fusion of resources. Individual examples of network-based resource processing include the following.

The mesh network <NUM>, for instance, may be enhanced by systems that perform inline data-to-information transforms. For example, self-forming chains of processing resources comprising a multi-link network may distribute the transformation of raw data to information in an efficient manner, and the ability to differentiate between assets and resources and the associated management of each. Furthermore, the proper components of infrastructure and resource based trust and service indices may be inserted to improve the data integrity, quality, assurance and deliver a metric of data confidence.

The WLAN network <NUM>, for instance, may use systems that perform standards conversion to provide multi-standard connectivity, enabling IoT devices <NUM> using different protocols to communicate. Further systems may provide seamless interconnectivity across a multi-standard infrastructure comprising visible Internet resources and hidden Internet resources.

Communications in the cellular network <NUM>, for instance, may be enhanced by systems that offload data, extend communications to more remote devices, or both. The LPWA network <NUM> may include systems that perform non-Internet protocol (IP) to IP interconnections, addressing, and routing. Further, each of the IoT devices <NUM> may include the appropriate transceiver for wide area communications with that device. Further, each IoT device <NUM> may include other transceivers for communications using additional protocols and frequencies. This is discussed further with respect to the communication environment and hardware of an IoT processing device depicted in <FIG> and <FIG>.

Finally, clusters of IoT devices may be equipped to communicate with other IoT devices as well as with a cloud network. This may enable the IoT devices to form an ad-hoc network between the devices, enabling them to function as a single device, which may be termed a fog device, fog platform, or fog network. This configuration is discussed further with respect to <FIG> below.

<FIG> illustrates a cloud computing network in communication with a mesh network of IoT devices (devices <NUM>) operating as a fog system in a networked scenario. The mesh network of IoT devices may be termed a fog network <NUM>, or edge cloud, established from a network of devices at the edge of the network. To simplify the diagram, not every IoT device <NUM> is labeled.

The fog network <NUM> may be considered to be a massively interconnected network wherein a number of IoT devices <NUM> are in communications with each other, for example, by radio links <NUM>. The fog network <NUM> may establish a horizontal, physical, or virtual resource platform that can be considered to reside between IoT edge devices and cloud or data centers. A fog network, in some examples, may support vertically-isolated, latency-sensitive applications through layered, federated, or distributed computing, storage, and network connectivity operations. However, a fog network may also be used to distribute resources and services at and among the edge and the cloud. Thus, references in the present document to the "edge", "fog", and "cloud" are not necessarily discrete or exclusive of one another.

As an example, the fog network <NUM> may be facilitated using an interconnect specification released by the Open Connectivity Foundation™ (OCF). This standard enables devices to discover each other and establish communications for interconnects. Other interconnection protocols may also be used, including, for example, the optimized link state routing (OLSR) Protocol, the better approach to mobile ad-hoc networking (B. ) routing protocol, or the OMA Lightweight M2M (LWM2M) protocol, among others.

Three types of IoT devices <NUM> are shown in this example, gateways <NUM>, data aggregators <NUM>, and sensors <NUM>, although any combinations of IoT devices <NUM> and functionality may be used. The gateways <NUM> may be edge devices that provide communications between the cloud <NUM> and the fog network <NUM>, and may also provide the backend process function for data obtained from sensors <NUM>, such as motion data, flow data, temperature data, and the like. The data aggregators <NUM> may collect data from any number of the sensors <NUM>, and perform the back end processing function for the analysis. The results, raw data, or both may be passed along to the cloud <NUM> through the gateways <NUM>. The sensors <NUM> may be full IoT devices <NUM>, for example, capable of both collecting data and processing the data. In some cases, the sensors <NUM> may be more limited in functionality, for example, collecting the data and enabling the data aggregators <NUM> or gateways <NUM> to process the data.

Communications from any IoT device <NUM> may be passed along a convenient path (e.g., a most convenient path) between any of the IoT devices <NUM> to reach the gateways <NUM>. In these networks, the number of interconnections provide substantial redundancy, enabling communications to be maintained, even with the loss of a number of IoT devices <NUM>. Further, the use of a mesh network may enable IoT devices <NUM> that are very low power or located at a distance from infrastructure to be used, as the range to connect to another IoT device <NUM> may be much less than the range to connect to the gateways <NUM>.

The fog network <NUM> provided from these IoT devices <NUM> may be presented to devices in the cloud <NUM>, such as a server <NUM>, as a single device located at the edge of the cloud <NUM>, e.g., a fog network operating as a device or platform. In this example, the alerts coming from the fog device may be sent without being identified as coming from a specific IoT device <NUM> within the fog network <NUM>. In this fashion, the fog network <NUM> may be considered a distributed platform that provides computing and storage resources to perform processing or data-intensive tasks such as data analytics, data aggregation, and machine-learning, among others.

In some examples, the IoT devices <NUM> may be configured using an imperative programming style, e.g., with each IoT device <NUM> having a specific function and communication partners. However, the IoT devices <NUM> forming the fog device may be configured in a declarative programming style, enabling the IoT devices <NUM> to reconfigure their operations and communications, such as to determine needed resources in response to conditions, queries, and device failures. As an example, a query from a user located at a server <NUM> about the operations of a subset of equipment monitored by the IoT devices <NUM> may result in the fog network <NUM> device selecting the IoT devices <NUM>, such as particular sensors <NUM>, needed to answer the query. The data from these sensors <NUM> may then be aggregated and analyzed by any combination of the sensors <NUM>, data aggregators <NUM>, or gateways <NUM>, before being sent on by the fog network <NUM> device to the server <NUM> to answer the query. In this example, IoT devices <NUM> in the fog network <NUM> may select the sensors <NUM> used based on the query, such as adding data from flow sensors or temperature sensors. Further, if some of the IoT devices <NUM> are not operational, other IoT devices <NUM> in the fog network <NUM> device may provide analogous data, if available.

Existing approaches for enabling interoperability between different cloud services and service providers (or different vendors of IoT products) often involve a poor or challenging user experience. For example, configuring a smart lock provided by Manufacturer/Ecosystem A to work with a smart speaker provided by Manufacturer/Ecosystem B requires manually selecting the smart lock component (e.g., a skill provided by the Manufacturer/Ecosystem A) in the smart speaker application, and then manually logging in to the user's account with Manufacturer/Ecosystem A, often via an OAuth log-in webpage.

With current approaches, multiple manual steps and menu selections, and the provision of another set of user credentials, must be coordinated by a human user. This type of account linking cannot be automated, and while it may work for limited home environments with sophisticated users, it is not scalable to mass populations or for use with large IoT deployments. While the total overhead needed for manual account linking of a small number of accounts is not significant, such manual approaches do not enable broadly shared data between services, and do not support a true web of connection that is intended by many IoT use cases.

The following examples discuss certain ways in which devices can be added into, or managed as, a larger set or family of devices, including with techniques that authenticate and establish device connections automatically and in a far simplified manner. In these examples, information regarding the composition of the set of devices may be established and exchanged with one or more tokens, which provides necessary information to perform a traversal of the IoT device network. These tokens can be passed around internally to inform the other nodes, in the foreign domain, to set up a device-to-device pathway via clouds and cloud services.

In various examples, discussion is made with reference to two devices and two domains. However, by extension, these approaches may also be applied to three or more domains, three or more devices, integration with existing domains and devices, and other variations. Thus, it will be understood that the following examples are provided with reference to two domains, but may apply to n number of domains.

<FIG> provides an overview of an enhanced use case for automatic cloud-to-cloud device access provisioning. As shown, within a local device environment (e.g., an OCF device environment), a first device <NUM> (e.g., a smartphone app, such as a remote control application) associated with a first company or ecosystem (Company A) discovers a new second device <NUM> (e.g., a light bulb) that is already associated with a second company or ecosystem (Company B). This discovery (data flow (<NUM>)) includes the identification of information associated with the new device, such as device information, cloud information, security information (e.g., mutual authentication of permissions and link security), and the like.

Although cloud domains from different "companies" are illustrated in <FIG>, it will be understood that the same principles are also applicable to differing cloud domains of any type. The different cloud domains may be established for different groups of devices associated with the same user, company, organization, or entity. Accordingly, it will be understood that the clouds and service groups discussed herein may be provided as part of a service cloud, private cloud, on-premise cloud, or other configurations. These and other configurations may involve different domains that would normally be isolated, but use the following approaches to share credentials, data, and commands.

The first device <NUM> then communicates with its associated cloud service <NUM> (Company A Cloud) (data flow (<NUM>)), with an instruction to contact a second cloud service <NUM> associated with the new second device <NUM> (Company B Cloud), and to commence validation between these cloud services (between clouds <NUM> and <NUM>). This is followed by Cloud-to-Cloud communications to initiate validation (data flow (<NUM>)), and the communication of validation information (data flow (<NUM>)) which is provided back to the new second device <NUM>.

The second device <NUM> then may obtain this validation information, and pass it back to the first device (via the local network connection already established in data flow (<NUM>)), which the first device <NUM> may then pass back to its associated cloud service (Company A Cloud) (completing data flow (<NUM>)). With the validation information having been exchanged between both clouds <NUM>, <NUM>, the first cloud service <NUM> is able to control or otherwise interact with services provided by the second cloud service <NUM>, such as using the first device <NUM> to control the second device <NUM> via cloud-to-cloud communications (data flow (<NUM>)).

In this fashion, the procedure detailed from <FIG> has resulted in device-to-device (D2D) control or communications in a manner of a device-to-cloud-to-cloud-to-device (D2C2C2D). It will be apparent that other commands and data may be exchanged between devices <NUM> and <NUM> via the clouds <NUM> and <NUM>, including from device <NUM> to device <NUM>, after the validation information has been fully exchanged.

<FIG> illustrates a flowchart of a method <NUM> for discovering and establishing cloud-to-cloud device connections, such as in an implementation of the scenario described above for <FIG>.

At operation <NUM>, device-to-device discovery is performed on the local network. This may include the use of existing network protocols, discovery communications, or network provisioning (e.g., in an OCF network). This may be based on the data flow (<NUM>) depicted in <FIG>.

At operation <NUM>, a connection is initiated between a first cloud service and a second cloud service, such as based on instructions or information provided to the first cloud service. This may be based on the data flows (<NUM>), (<NUM>) depicted in <FIG>.

At operation <NUM>, validation information is communicated from the second cloud service, back to connected local devices (e.g., devices associated with the second cloud service). This may be based on the data flow (<NUM>) depicted in <FIG>.

At operation <NUM>, the validation information, obtained from the second cloud service, is communicated to the first cloud service, via connected local devices. This may be based on the data flow (<NUM>) depicted in <FIG>.

At operation <NUM>, the validation information is used within linked interfaces and services, to enable the first cloud service to communicate and control various authorized aspects, or access data, within the second cloud service. This may be based on the data flow (<NUM>) depicted in <FIG>. In the same manner, the second cloud service may communicate and control authorized aspects, or access data, within the first cloud service.

<FIG> provides a more detailed overview of communications exchanged between a first domain (including Device/User Equipment A and Cloud A) and a second domain (including Device/User Equipment B). In this scenario, each of the users (User A, User B) is a human (e.g., the same human or different humans) authorized to manage and control an IoT network within a domain context. The User Equipment (UE) is a user platform (which itself may be an IoT device) from which the user controls and manages device, networking, and domain operations. Additionally, in the example of <FIG>, further detail is provided regarding ways in which the authentication information may be generated and exchanged, including through the use of various tokens and authorization credentials.

In the environment of <FIG>, the Primary IoT Network (represented by house widget "A") is a local IoT network (e.g., network of connected devices that is connected via an OCF communication specification). In this example, the Primary IoT Network includes several devices within a domain (e.g. A. D3), operating according to an IoT specification (e.g., the OCF specification).

The Shadow IoT Network (represented by dashed house widget inside a respective cloud network) provides a software representation of physical devices contained in the IoT Network for a particular domain. Each cloud (e.g., clouds <NUM>, <NUM>) provides a set of domain-specific resources, functions, and services hosted by a cloud service provider, edge computing infrastructure. The domain context may be isolated using cloud tenant isolation technology such as virtualization, secure execution environment (e.g., ARM TrustZone, Intel SGX, etc.), containers, and physical partitioning.

The environment of <FIG> also includes various features for device discovery and authentication. This is depicted to include: a Cloud Resource Directory (CRD) <NUM>, <NUM> for each domain, which is a resource directory service hosted in a cloud environment that publishes and synchronizes shadow devices visible by peer domains and hosts visible shadow devices from peer domains; and an Authorization Server (AS) <NUM>, <NUM> for each domain, which is a local or cloud service that implements authorization token granting capability (e.g., using OAuth2, or any number of other authorization approaches). The tokens generated by the authorization server and communicated among the various devices may be provided in a JSON web token format, as further detailed below.

The flow of information within the environment of <FIG> is depicted with respective data flows as follows. The cloud environments <NUM>, <NUM> described above with reference to <FIG> are segmented into respective domains that correspond to the company or vendor associated with each cloud (e.g., domains that correspond to devices for Company A and Company B).

In data flow (<NUM>): The user equipment controlled by User A (UEA <NUM>) obtains authorizations to manage cloud-to-cloud provisioning and inter-operation. Authorization rights are contained within authorization tokens (e.g., tokens T1 - T11) obtained from the authorization server associated with the Domain A, ASA <NUM>. These authorizations may be initiated or controlled by the User A, by rules established by or on behalf of User A, or by software or other processes controlled or affected by the User A. The authorization tokens are utilized in the subsequent data flows.

In data flow (<NUM>): The UEA <NUM> instructs the IoT Network in Domain A to shadow some or all of its devices (in this example, to shadow devices A. D2, but not A. D3) in a shadow server <NUM>. This establishes a first set of shadowed, logical devices in the cloud environment <NUM> corresponding to Vendor A.

In data flow (<NUM>): The physical devices (A. D2) on the IoT Network-A (e.g., accessible to, onboarded in, or provisioned to Domain A) request a device shadowing from the Domain-A shadow service <NUM>. The tokens T1 and T2, obtained from the earlier data flow (<NUM>), authorize this operation.

In data flow (<NUM>): The UEA <NUM> instructs the shadow service A <NUM> to publish shadowed devices to a directory. This is followed by data flow (<NUM>): Shadow service A publishes shadowed devices using a cloud resource directory (or other device information directory), such as CRDA <NUM>. Token T3 is used to authorize this action.

In data flow (<NUM>): CRDA <NUM> publishes the information for shadowed device A. S1 for consumption by a peer domain (e.g., Domain B). For example, this may involve creating an entry in another cloud resource directory, such as CRDB <NUM>. (This entry is illustrated in <FIG> with the information indicated in the box next to CRDB <NUM>).

In data flow (<NUM>): User B is notified regarding availability of devices in a peer domain, and uses the user equipment controlled by User B (UEB <NUM>) to enable interaction between Domain A and Domain B devices (or a subset of these devices). The UEB <NUM> obtains authorizations to perform cloud-to-cloud interactions by obtaining authorization tokens from the authorization server associated with the Domain B, ASB <NUM>.

In data flow (<NUM>): The UEB <NUM> indicates which devices associated with Domain B may be shadowed (e.g., devices B. This is followed by data flow (<NUM>): where devices B. D2 are shadowed to a shadow service B <NUM> using authorization tokens T5 and T6.

In data flow (<NUM>): UEB <NUM> instructs the shadow service B <NUM> to discover new devices in the resource directory, CRDB <NUM>. Data flow (<NUM>): shadow service B <NUM> discovers Domain A devices using Token T7 authorizations.

In data flow (<NUM>): UEB <NUM> determines it is appropriate for a Domain B device to interact with a Domain A device, and the UEB <NUM> obtains authorizations from the authorization server associated with the Domain B, ASB <NUM>.

In data flow (<NUM>): The authorization server ASB <NUM> contacts the authorization server ASA <NUM> to obtain authorization, from the Domain-A, for Device A. D1 (proxied by shadow device A. S1) to interact with B. D1 (proxied by shadow device B. The token T8 is used to authorize this interaction.

In data flow (<NUM>): The authorization server ASA <NUM> delivers the token T10 to a UE which authorizes cloud-to-cloud interaction to occur between device A.

In data flow (<NUM>): UEA provisions credentials for B. D1 secure interactions. For example, Token T10 may contain a Domain B trust anchor which is associated with A. D1 credential resource. In data flow (<NUM>): UEB <NUM> likewise provisions credentials for A. D1 to conduct secure interactions, using Token T9.

In data flow (<NUM>): UEB instructs device B. D1 to interact with device A. In data flow (<NUM>): Device B. D1 establishes an end-to-end or hop-by-hop connection with Device A. D1, using the shadow device B. S1 as a cloud proxy.

In data flow (<NUM>): Shadow Device A. S1 completes an end-to-end or hop-by-hop connection with Device A. D1 as its cloud proxy. In data flow (<NUM>): Device B. D1 securely interacts with Device A. D1 over the secure channel (e.g., a secure channel established via TLS, OSCORE).

Although the examples of <FIG> and <FIG> refer to separate "companies" or ecosystem management entities, some domain use cases may be attributed to different service providers, vendors, IT organizations, or persons. Also, the use of a service or server in the depicted "cloud" does not necessarily require the use of a cloud data center or a globally accessible network. Rather, the use of a service or server may occur as part of a fog or edge computing system, such as in an edge cloud setting that hosts and isolates tenant-specific services for different users, groups of users, and other entities or entity groups.

Further, when reaching data flow (<NUM>), where direct control or data is exchanged between devices (after the underlying authentication has been set up), latency may become an issue. In particular, in IoT settings there may be latency requirements involved, which may be fulfilled with the use of a cloud edge device that is on-premises (e.g., in a cloudlet) or with a first tier edge environment using radio access network technology that has low latency properties. In other settings, latency may not be critical, or additional checks may be performed to ensure that the device-to-device connection via the clouds or via direct connections can be performed.

In an example, all authorization tokens as exchanged in the data flows of <FIG> or otherwise may contain user and domain context. For example, this user and domain context may be used to indicate authorization for a user login involving the UE and AS for its respective domain. An example token format may include data such as:.

In an example, token-specific fields may include:.

Thus, in the various examples of <FIG>, the token is signed and includes authorization data issued by an authorization server in a JSON web token format. In other examples, other forms of encodings may be used to communicate and exchange data provided by this token (e.g., in XML encoding). Also, a digital security certificate or similar security data object may be utilized to communicate the authorization data, including in scenarios where the digital certificate includes a signature from a signing entity tied to a certificate authority (CA). Other variations, including the use of CBOR web tokens, x. <NUM> tokens embedded in a certificate, the use of asymmetric keys, and sign-on approaches such as OAuth, OAuth2, and Kerberos may be used as part of the authorization communication schemes discussed above.

As indicated above, the various devices and communications may occur according to an OCF specification, which defines various access resources, resource commands, and communication formats among devices and with cloud services. To accomplish the configuration of devices within an OCF setting, the resources utilized by an OCF implementation may include resources similar to the following:.

<FIG> illustrates a flowchart <NUM> of a method for establishing and exchanging cloud-to-cloud validation information, such as in an implementation of the scenario described above for <FIG>.

At operation <NUM>, device shadowing is established in the first network and the second network. This operation may implement or may be based on the data flows (<NUM>), (<NUM>), (<NUM>), (<NUM>), depicted in <FIG>.

At operation <NUM>, shadowed devices are published using a cloud resource directory. This operation may implement or may be based on the data flows (<NUM>), (<NUM>), (<NUM>) depicted in <FIG>.

At operation <NUM>, user authorization and instruction is obtained (e.g., via a UE user input, via user pre-defined rules, commands, or data, etc.) to connect devices in the first network and the second network. This operation may implement or may be based on the data flows (<NUM>), (<NUM>), (<NUM>), (<NUM>), (<NUM>) depicted in <FIG>.

At operation <NUM>, authentication credentials are exchanged to connect the devices within the first network and the second network. This operation may implement or may be based on the data flows (<NUM>), (<NUM>), (<NUM>), (<NUM>), (<NUM>) depicted in <FIG>.

At operation <NUM>, the method concludes with the use of linked services and interfaces, using the connection established between the first network and the second network. This operation may implement or may be based on the data flows (<NUM>), (<NUM>), (<NUM>) depicted in <FIG>.

Accordingly, the data flow and operational sequences illustrated among <FIG>, discussed above, provides a Device-to-Cloud-to-Cloud-to-Device (D2C2C2D) access model. The security model allows for both hop-by-hop and end-to-end message protection capability which logically is device-to-device. Even though some D2D physical connections are possible and the domains may be physically co-located, the D2C2C2D approach is followed for security because the interaction semantics remain as defined by Domains A and B.

It will also be understood that edge computing infrastructure is being designed to overcome latency issues common to cloud services. Even with the use of edge computing infrastructure, the presently described D2C2C2D approach is still feasible even when networks are physically co-located; the latency inherent with remote cloud services may be replaced with reduced latency from edge cloud services.

Finally, it will be understood that many of the cloud-to-local interactions discussed above are inferred, such as when all cloud services are represented as OCF resources. This suggests many of the local-to-cloud interactions may be supported using traditional OCF discovery and interaction protocols.

In further examples, the domains established above may be applicable to settings involving Industrial IoT networks. Such networks often have multi-tier networking, so a respective "domain" discussed above may relate to one of these tiers. Likewise, in examples involving network or device tiers, the domains may be established within a respective tier, where at each tier there is potentially a policy that is appropriate for the tier, as the policy control or device properties applied are additive.

In further examples, the implementations discussed here may be applied in smart cities, including the use of smart cities involving multiple tiers. In these and other settings, the implementations discussed herein may also apply to edge cloud / edge computing deployments, in variety of edge computing environments, and the use of multi-access edge computing (MEC) arrangements for wired and wirelessly connected devices.

<FIG> illustrates a diagram of device and apparatus configurations for implementing automatic cloud-to-cloud registration and validation techniques. In this diagram, selected structural components (processors, memory, etc.) are used to implement the various operations detailed above, as part of establishing connectivity between a first IoT device <NUM> (associated with a first remote service <NUM>) and a second IoT device <NUM> (associated with a second remote service <NUM>). However, it will be understood that far more devices, systems, components, and communications may be provided within an IoT device deployment.

The first IoT device <NUM> is depicted as including communications circuitry <NUM> (e.g., a network interface card), processor circuitry <NUM> (e.g., one or more processors or processor cores), and a memory or storage device <NUM> (e.g., a volatile or non-volatile memory array), as the device <NUM> is adapted to perform device-to-device communications via the remote service based on the configurations and operations discussed herein. In an example, the communications circuitry <NUM> is configured to perform communications with the second IoT device <NUM>, directly or via a communications gateway <NUM>; and to perform communications with the first remote service <NUM>, directly or via the communications gateway <NUM>.

In an example, the memory or storage device <NUM> includes instructions embodied thereon, and the instructions, when executed by the processing circuitry, configure the processing circuitry to perform operations for configuring and establishing the device-to-device communications pathway via the remote services. Further details on these operations is detailed in the operations of <FIG>, discussed below; or other data flows detailed in <FIG>. It will be understood that these operations include the exchange of discovery and validation information between the devices <NUM> and <NUM>, and the exchange of service communication information between the service <NUM> and the device <NUM>.

The second IoT device <NUM> is depicted as including communications circuitry <NUM>, processor circuitry <NUM>, and a memory or storage device <NUM>, as the device <NUM> is also adapted to perform the corresponding operations to interact and communicate with the first IoT device <NUM> and the second remote service <NUM>. Further details on the operations is also detailed in the operations of <FIG>, discussed below; or other data flows detailed in <FIG>. It will be understood that these operations include the exchange of discovery and validation information between the devices <NUM> and <NUM>, and service validation information between the service <NUM> and the device <NUM>.

The first remote service <NUM> is depicted as including a server <NUM> with processor circuitry <NUM> and memory or storage <NUM>; the second remote service <NUM> is depicted as including a server <NUM> with processor circuitry <NUM> and memory/storage <NUM>. The respective processor circuitry and memory or storage may operate within each server to facilitate the communications and authentication information, as detailed in the operations of <FIG>, discussed below; or other data flows detailed in <FIG>. Specifically, a data connection between the services <NUM>, <NUM> may be used to exchange validation information to set up an authenticated service-to-service connection, and later to provide or communicate data commands or data values in a cloud-to-cloud manner.

The communications gateway <NUM> may be located within a local area network that includes the devices <NUM>, <NUM>, as a bridge between the local area network and a wide area network, or in a wide area network, between the devices <NUM>, <NUM> and the services <NUM>, <NUM>. In an example, the communications gateway <NUM> includes communication circuitry <NUM> to conduct communications (e.g., wired or wireless communications) and processor circuitry <NUM> to execute instructions for performing communication or compute operations. Other components (such as memory or storage, not shown) may be used to filter or enhance communications between the devices <NUM>, <NUM> and the services <NUM>, <NUM>. The communications gateway <NUM> may perform or assist the operations detailed in <FIG>, discussed below, or the data flows detailed in <FIG>.

<FIG> illustrates a flowchart <NUM> of operations for implementing automatic cloud-to-cloud registration and validation techniques, according to an example. These operations are described from the perspective of a first device, although it will be understood that other perspectives may be implemented.

The flowchart <NUM> begins with an operation to obtain, from a second device, various information used to communicate with a second, remote service associated with the second device (operation <NUM>). This information may be obtained in response to discovery of the second device on a local area network. For instance, the information obtained from the second device may include information to mutually authenticate permissions and establish communication link security between the devices, between cloud services, or otherwise.

The flowchart <NUM> continues with an operation to communicate information to a first remote service associated with the first device (operation <NUM>). In an example, the first remote service is hosted in a first cloud network associated with a first entity, and the second remote service is hosted in a second cloud network associated with a second entity. In this configuration, the first device is associated with the first entity, and the second device is associated with the second entity. For example, the first device may be manufactured by or serviced on behalf of the first entity, and the second device may be manufactured by or serviced on behalf of the second entity. Also in an example, the communications performed with the first remote service are performed via a wide area network. These communications may include at least one token, or the token information discussed above, such as where the token includes data that provides authentication information obtained from an authorization server.

The flowchart <NUM> continues with an operation to obtain service validation information from the second device (operation <NUM>). Earlier, this service validation information is provided from a second remote service, such as in a scenario where the second remote service provides the service validation information to the second device in response to the first remote service initiating the validation procedure with the second remote service. Thus, the service validation information may be provided as a result of a first phase of service-to-service authentication. In an example, this service-to-service authentication may involve use of a directory, such as where the first remote service maintains a first directory of devices accessible to the second remote service, and the second remote service maintains a second directory of devices accessible to the first remote service. In these examples, which may involve use of the shadow devices discussed above, the first directory of devices may provide data associated with the first device, and the second directory of devices may provide data associated with the second device; the service validation information is then provided based on one or both of the first and second directory of devices.

The flowchart <NUM> then continues with an operation to communicate the service validation information from the first device to the first remote service (operation <NUM>). In further examples, this and the other communications from the first device to the first remote service include at least one token, with the token including data to provides authentication information obtained from an authorization server (e.g., as depicted in detail in <FIG>). Based on this information, a validated service-to-service connection (and, device-to-cloud service-to-cloud service-to-device connection) may be established.

The flowchart <NUM> concludes with an operation to communicate one or more commands or data, using the validated service-to-service connection (operation <NUM>). For instance, in response to communicating the command, the command is further communicated from the first remote service to the second remote service and from the second remote service to the second device, using the validated connection between the first remote service and the second remote service. Also for instance, in response to a request for the data value, the request is further communicated from the first remote service to the second remote service and from the second remote service to the second device, and is returned from the second device to the second remote service and to the first remote service, using the validated connection between the first remote service and the second remote service.

In an example, the first remote service provides various authentication information that accompanies data or commands to the second remote service, and the validated connection between the first remote service and the second remote service is established based on use of the authentication information. This authentication information may be provided as discussed in <FIG> and <FIG>, above. Also in further examples, various forms of user input may be received at the respective IoT devices, or at user equipment which manages a respective IoT device. Thus, various flows may occur where the service validation information is provided to the first device in response to user input at the second device. Other automated discover and connection setup may also occur.

In various examples, the present subject matter and features discussed above may be embodied by various methods, devices, and system embodiments. As a first example, an embodiment may include a method, device, system, or network, which enables interaction with or manages data in a cloud-to-cloud resource directory (e.g., directories <NUM>, <NUM>), using the techniques discussed with reference to <FIG>. Such directories may be updated or managed using the data flows and authorization information exchanged as discussed above.

As a second example, an embodiment may include a method, device, system, or network, which enables cloud-to-local resource directory interaction, including processing features for when a device is cloud-capable (or, cloud-resource-directory capable), using the techniques discussed with reference to <FIG>.

As a third example, an embodiment may include a method, device, system, or network, which enables OAuth authorization of Cloud-to-Cloud interaction, based on the use of OAuth or OAuth tokens in combination with the techniques discussed with reference to <FIG>.

As a fourth example, an embodiment may include a method, device, system, or network, which enables discovering, over a Local Network, the availability for Cloud-to-Cloud Interaction (for a device already configured for Cloud-to-Local Interaction), using the techniques discussed with reference to <FIG>.

As a fifth example, an embodiment may include a method, device, system, or network, which enables setup and execution of an application, service, or data structure for any of the Cloud-to-Cloud resource directory, Cloud-to-Cloud interaction, or Cloud-to-Local interaction approaches, provided from the techniques discussed with reference to <FIG>.

As a sixth example, an embodiment may include a method, device, system, or network, which enables automatic, user-assisted, or user-configured provisioning of authorized and secure cross-cloud interaction (D2D or D2C2C2D) scenarios. These scenarios may leverage already secure D2D configurations, using the techniques discussed with reference to <FIG>, thus avoiding the need for user-involved OAuth or like authorization approaches.

<FIG> illustrates a drawing of a cloud computing network, or cloud <NUM>, in communication with a number of Internet of Things (IoT) devices. The cloud <NUM> may represent the Internet, or may be a local area network (LAN), or a wide area network (WAN), such as a proprietary network for a company. The IoT devices may include any number of different types of devices, grouped in various combinations. For example, a traffic control group <NUM> may include IoT devices along streets in a city. These IoT devices may include stoplights, traffic flow monitors, cameras, weather sensors, and the like. The traffic control group <NUM>, or other subgroups, may be in communication with the cloud <NUM> through wired or wireless links <NUM>, such as LPWA links, optical links, and the like. Further, a wired or wireless sub-network <NUM> may allow the IoT devices to communicate with each other, such as through a local area network, a wireless local area network, and the like. The IoT devices may use another device, such as a gateway <NUM> or <NUM> to communicate with remote locations such as the cloud <NUM>; the IoT devices may also use one or more servers <NUM> to facilitate communication with the cloud <NUM> or with the gateway <NUM>. For example, the one or more servers <NUM> may operate as an intermediate network node to support a local edge cloud or fog implementation among a local area network. Further, the gateway <NUM> that is depicted may operate in a cloud-to-gateway-to-many edge devices configuration, such as with the various IoT devices <NUM>, <NUM>, <NUM> being constrained or dynamic to an assignment and use of resources in the cloud <NUM>.

Other example groups of IoT devices may include remote weather stations <NUM>, local information terminals <NUM>, alarm systems <NUM>, automated teller machines <NUM>, alarm panels <NUM>, or moving vehicles, such as emergency vehicles <NUM> or other vehicles <NUM>, among many others. Each of these IoT devices may be in communication with other IoT devices, with servers <NUM>, with another IoT fog platform or system (not shown), or a combination therein. The groups of IoT devices may be deployed in various residential, commercial, and industrial settings (including in both private or public environments).

As may be seen from <FIG>, a large number of IoT devices may be communicating through the cloud <NUM>. This may allow different IoT devices to request or provide information to other devices autonomously. For example, a group of IoT devices (e.g., the traffic control group <NUM>) may request a current weather forecast from a group of remote weather stations <NUM>, which may provide the forecast without human intervention. Further, an emergency vehicle <NUM> may be alerted by an automated teller machine <NUM> that a burglary is in progress. As the emergency vehicle <NUM> proceeds towards the automated teller machine <NUM>, it may access the traffic control group <NUM> to request clearance to the location, for example, by lights turning red to block cross traffic at an intersection in sufficient time for the emergency vehicle <NUM> to have unimpeded access to the intersection.

Clusters of IoT devices, such as the remote weather stations <NUM> or the traffic control group <NUM>, may be equipped to communicate with other IoT devices as well as with the cloud <NUM>. This may allow the IoT devices to form an ad-hoc network between the devices, allowing them to function as a single device, which may be termed a fog platform or system.

<FIG> is a block diagram of an example of components that may be present in an IoT device <NUM> for implementing the techniques described herein. The IoT device <NUM> may include any combinations of the components shown in the example or referenced in the disclosure above. The components may be implemented as ICs, portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof adapted in the IoT device <NUM>, or as components otherwise incorporated within a chassis of a larger system. Additionally, the block diagram of <FIG> is intended to depict a high-level view of components of the IoT device <NUM>. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

The IoT device <NUM> may include processing circuitry in the form of a processor <NUM>, which may be a microprocessor, a multi-core processor, a multithreaded processor, an ultra-low voltage processor, an embedded processor, or other known processing elements. The processor <NUM> may be a part of a system on a chip (SoC) in which the processor <NUM> and other components are formed into a single integrated circuit, or a single package, such as the Edison™ or Galileo™ SoC boards from Intel. As an example, the processor <NUM> may include an Intel® Architecture Core™ based processor, such as a Quark™, an Atom™, a Xeon™, an i3, an i5, an i7, an i9, or an MCU-class processor, or another such processor available from Intel® Corporation, Santa Clara, California. However, any number other processors may be used, such as available from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, California, a MIPS-based design from MIPS Technologies, Inc. of Sunnyvale, California, an ARM-based design licensed from ARM Holdings, Ltd. or customer thereof, or their licensees or adopters. The processors may include units such as an A5-A12 processor from Apple® Inc. , a Snapdragon™ processor from Qualcomm® Technologies, Inc. , or an OMAP™ processor from Texas Instruments, Inc. Accordingly, in various examples, applicable means for processing may be embodied by such processing circuitry.

The processor <NUM> may communicate with a system memory <NUM> over an interconnect <NUM> (e.g., a bus). Any number of memory devices may be used to provide for a given amount of system memory. As examples, the memory may be random access memory (RAM) in accordance with a Joint Electron Devices Engineering Council (JEDEC) design such as the DDR or mobile DDR standards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In various implementations the individual memory devices may be of any number of different package types such as single die package (SDP), dual die package (DDP) or quad die package (Q17P). These devices, in some examples, may be directly soldered onto a motherboard to provide a lower profile solution, while in other examples the devices are configured as one or more memory modules that in turn couple to the motherboard by a given connector. Any number of other memory implementations may be used, such as other types of memory modules, e.g., dual inline memory modules (DIMMs) of different varieties including but not limited to microDIMMs or MiniDIMMs.

To provide for persistent storage of information such as data, applications, operating systems and so forth, a storage <NUM> may also couple to the processor <NUM> via the interconnect <NUM>. In an example the storage <NUM> may be implemented via a solid state disk drive (SSDD). Other devices that may be used for the storage <NUM> include flash memory cards, such as SD cards, microSD cards, xD picture cards, and the like, and USB flash drives. In low power implementations, the storage <NUM> may be on-die memory or registers associated with the processor <NUM>. However, in some examples, the storage <NUM> may be implemented using a micro hard disk drive (HDD). Further, any number of new technologies may be used for the storage <NUM> in addition to, or instead of, the technologies described, such resistance change memories, phase change memories, holographic memories, or chemical memories, among others. Accordingly, in various examples, applicable means for storage may be embodied by such storage media.

The components may communicate over the interconnect <NUM>. The interconnect <NUM> may include any number of technologies, including industry standard architecture (ISA), extended ISA (EISA), peripheral component interconnect (PCI), peripheral component interconnect extended (PCIx), PCI express (PCIe), or any number of other technologies. The interconnect <NUM> may be a proprietary bus, for example, used in a SoC based system. Other bus systems may be included, such as an I2C interface, an SPI interface, point to point interfaces, and a power bus, among others.

The interconnect <NUM> may couple the processor <NUM> to a mesh transceiver <NUM>, for communications with other mesh devices <NUM>. The mesh transceiver <NUM> may use any number of frequencies and protocols, such as <NUM> Gigahertz (GHz) transmissions under the IEEE <NUM>. <NUM> standard, using the Bluetooth® low energy (BLE) standard, as defined by the Bluetooth® Special Interest Group, or the ZigBee® standard, among others. Any number of radios, configured for a particular wireless communication protocol, may be used for the connections to the mesh devices <NUM>. For example, a WLAN unit may be used to implement Wi-Fi™ communications in accordance with the Institute of Electrical and Electronics Engineers (IEEE) <NUM> standard. In addition, wireless wide area communications, e.g., according to a cellular or other wireless wide area protocol, may occur via a WWAN unit.

The mesh transceiver <NUM> may communicate using multiple standards or radios for communications at different range. For example, the IoT device <NUM> may communicate with close devices, e.g., within about <NUM> meters, using a local transceiver based on BLE, or another low power radio, to save power. More distant mesh devices <NUM>, e.g., within about <NUM> meters, may be reached over ZigBee or other intermediate power radios. Both communications techniques may take place over a single radio at different power levels, or may take place over separate transceivers, for example, a local transceiver using BLE and a separate mesh transceiver using ZigBee.

A wireless network transceiver <NUM> may be included to communicate with devices or services in the cloud <NUM> via local or wide area network protocols. The wireless network transceiver <NUM> may be a LPWA transceiver that follows the IEEE <NUM>. <NUM>, or IEEE <NUM>. <NUM> standards, among others. The IoT device <NUM> may communicate over a wide area using LoRaWAN™ (Long Range Wide Area Network) developed by Semtech and the LoRa Alliance. The techniques described herein are not limited to these technologies, but may be used with any number of other cloud transceivers that implement long range, low bandwidth communications, such as Sigfox, and other technologies. Further, other communications techniques, such as time-slotted channel hopping, described in the IEEE <NUM>. 4e specification may be used.

Any number of other radio communications and protocols may be used in addition to the systems mentioned for the mesh transceiver <NUM> and wireless network transceiver <NUM>, as described herein. For example, the radio transceivers <NUM> and <NUM> may include an LTE or other cellular transceiver that uses spread spectrum (SPA/SAS) communications for implementing high speed communications. Further, any number of other protocols may be used, such as Wi-Fi® networks for medium speed communications and provision of network communications.

The radio transceivers <NUM> and <NUM> may include radios that are compatible with any number of 3GPP (Third Generation Partnership Project) specifications, notably Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), and Long Term Evolution-Advanced Pro (LTE-A Pro). It may be noted that radios compatible with any number of other fixed, mobile, or satellite communication technologies and standards may be selected. These may include, for example, any Cellular Wide Area radio communication technology, which may include e.g. a 5th Generation (<NUM>) communication systems, a Global System for Mobile Communications (GSM) radio communication technology, a General Packet Radio Service (GPRS) radio communication technology, or an Enhanced Data Rates for GSM Evolution (EDGE) radio communication technology, a UMTS (Universal Mobile Telecommunications System) communication technology, In addition to the standards listed above, any number of satellite uplink technologies may be used for the wireless network transceiver <NUM>, including, for example, radios compliant with standards issued by the ITU (International Telecommunication Union), or the ETSI (European Telecommunications Standards Institute), among others. The examples provided herein are thus understood as being applicable to various other communication technologies, both existing and not yet formulated.

A network interface controller (NIC) <NUM> may be included to provide a wired communication to the cloud <NUM> or to other devices, such as the mesh devices <NUM>. The wired communication may provide an Ethernet connection, or may be based on other types of networks, such as Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS, or PROFINET, among many others. An additional NIC <NUM> may be included to allow connect to a second network, for example, a NIC <NUM> providing communications to the cloud over Ethernet, and a second NIC <NUM> providing communications to other devices over another type of network.

Given the variety of types of applicable communications from the device to another component or network, applicable communications circuitry used by the device may include or be embodied by any one or more of components <NUM>, <NUM>, <NUM>, or <NUM>. Accordingly, in various examples, applicable means for communicating (e.g., receiving, transmitting, etc.) may be embodied by such communications circuitry.

The interconnect <NUM> may couple the processor <NUM> to an external interface <NUM> that is used to connect external devices or subsystems. The external devices may include sensors <NUM>, such as accelerometers, level sensors, flow sensors, optical light sensors, camera sensors, temperature sensors, a global positioning system (GPS) sensors, pressure sensors, barometric pressure sensors, and the like. The external interface <NUM> further may be used to connect the IoT device <NUM> to actuators <NUM>, such as power switches, valve actuators, an audible sound generator, a visual warning device, and the like.

In some optional examples, various input/output (I/O) devices may be present within, or connected to, the IoT device <NUM>. For example, a display or other output device <NUM> may be included to show information, such as sensor readings or actuator position. An input device <NUM>, such as a touch screen or keypad may be included to accept input. An output device <NUM> may include any number of forms of audio or visual display, including simple visual outputs such as binary status indicators (e.g., LEDs) and multi-character visual outputs, or more complex outputs such as display screens (e.g., LCD screens), with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the IoT device <NUM>.

A battery <NUM> may power the IoT device <NUM>, although in examples in which the IoT device <NUM> is mounted in a fixed location, it may have a power supply coupled to an electrical grid. The battery <NUM> may be a lithium ion battery, or a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like.

A battery monitor / charger <NUM> may be included in the IoT device <NUM> to track the state of charge (SoCh) of the battery <NUM>. The battery monitor / charger <NUM> may be used to monitor other parameters of the battery <NUM> to provide failure predictions, such as the state of health (SoH) and the state of function (SoF) of the battery <NUM>. The battery monitor / charger <NUM> may include a battery monitoring integrated circuit, such as an LTC4020 or an LTC2990 from Linear Technologies, an ADT7488A from ON Semiconductor of Phoenix Arizona, or an IC from the UCD90xxx family from Texas Instruments of Dallas, TX. The battery monitor / charger <NUM> may communicate the information on the battery <NUM> to the processor <NUM> over the interconnect <NUM>. The battery monitor / charger <NUM> may also include an analog-to-digital (ADC) convertor that allows the processor <NUM> to directly monitor the voltage of the battery <NUM> or the current flow from the battery <NUM>. The battery parameters may be used to determine actions that the IoT device <NUM> may perform, such as transmission frequency, mesh network operation, sensing frequency, and the like.

A power block <NUM>, or other power supply coupled to a grid, may be coupled with the battery monitor / charger <NUM> to charge the battery <NUM>. In some examples, the power block <NUM> may be replaced with a wireless power receiver to obtain the power wirelessly, for example, through a loop antenna in the IoT device <NUM>. A wireless battery charging circuit, such as an LTC4020 chip from Linear Technologies of Milpitas, California, among others, may be included in the battery monitor / charger <NUM>. The specific charging circuits chosen depend on the size of the battery <NUM>, and thus, the current required. The charging may be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, or the Rezence charging standard, promulgated by the Alliance for Wireless Power, among others.

The storage <NUM> may include instructions <NUM> in the form of software, firmware, or hardware commands to implement the techniques described herein. Although such instructions <NUM> are shown as code blocks included in the memory <NUM> and the storage <NUM>, it may be understood that any of the code blocks may be replaced with hardwired circuits, for example, built into an application specific integrated circuit (ASIC).

In an example, the instructions <NUM> provided via the memory <NUM>, the storage <NUM>, or the processor <NUM> may be embodied as a non-transitory, machine readable medium <NUM> including code to direct the processor <NUM> to perform electronic operations in the IoT device <NUM>. The processor <NUM> may access the non-transitory, machine readable medium <NUM> over the interconnect <NUM>. For instance, the non-transitory, machine readable medium <NUM> may be embodied by devices described for the storage <NUM> of <FIG> or may include specific storage units such as optical disks, flash drives, or any number of other hardware devices. The non-transitory, machine readable medium <NUM> may include instructions to direct the processor <NUM> to perform a specific sequence or flow of actions, for example, as described with respect to the flowchart(s) and block diagram(s) of operations and functionality depicted above.

In still a specific example, the instructions <NUM> on the processor <NUM> (separately, or in combination with the instructions <NUM> of the machine readable medium <NUM>) may configure execution or operation of a trusted execution environment (TEE) <NUM>. In an example, the TEE <NUM> operates as a protected area accessible to the processor <NUM> for secure execution of instructions and secure access to data. Various implementations of the TEE <NUM>, and an accompanying secure area in the processor <NUM> or the memory <NUM> may be provided, for instance, through use of Intel® Software Guard Extensions (SGX) or ARM® TrustZone® hardware security extensions, Intel® Management Engine (ME), or Intel® Converged Security Manageability Engine (CSME). Other aspects of security hardening, hardware roots-of-trust, and trusted or protected operations may be implemented in the device <NUM> through the TEE <NUM> and the processor <NUM>.

In further examples, a machine-readable medium also includes any tangible medium that is capable of storing, encoding or carrying instructions for execution by a machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. A "machine-readable medium" thus may include, but is not limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including but not limited to, by way of example, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The instructions embodied by a machine-readable medium may further be transmitted or received over a communications network using a transmission medium via a network interface device utilizing any one of a number of transfer protocols (e.g., HTTP).

It should be understood that the functional units or capabilities described in this specification may have been referred to or labeled as components or modules, in order to more particularly emphasize their implementation independence. Such components may be embodied by any number of software or hardware forms. For example, a component or module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component or module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. Components or modules may also be implemented in software for execution by various types of processors. An identified component or module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified component or module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the component or module and achieve the stated purpose for the component or module.

Claim 1:
A method for establishing communications in an Internet of Things, IoT, device deployment, comprising operations performed by processing circuitry (<NUM>) of a first loT device (<NUM>, <NUM>), wherein the first remote service (<NUM>) and the first IoT device (<NUM>, <NUM>) operate in a first service domain, the operations including:
obtaining security information to mutually authenticate permissions and establish link security, from a second IoT device (<NUM>, <NUM>), to communicate with a second remote service (<NUM>) associated with the second IoT device (<NUM>, <NUM>), the second remote service (<NUM>) and the second loT device (<NUM>, <NUM>) operating in a second service domain,
wherein the operations to obtain the information from the second IoT device (<NUM>, <NUM>) to communicate with the second remote service (<NUM>), are performed in response to discovery of the second loT device (<NUM>, <NUM>) on the local area network, wherein the information obtained from the second IoT device (<NUM>, <NUM>) includes information to mutually authenticate permissions and establish communication link security;
providing the information to a first remote service (<NUM>), wherein in response to the information the first remote service (<NUM>) initiates a validation procedure with the second remote service (<NUM>);
obtaining service validation information from the second IoT device (<NUM>, <NUM>), wherein the service validation information is provided from the second remote service (<NUM>) to the second IoT device (<NUM>, <NUM>) in response to the validation procedure; and
providing the service validation information to the first remote service (<NUM>), to enable a validated connection between the first remote service (<NUM>) and the second remote service (<NUM>) to communicate data or commands between the first IoT device (<NUM>, <NUM>) and second IoT device (<NUM>, <NUM>) via the first remote service (<NUM>) and the second remote service (<NUM>),
wherein the first remote service (<NUM>) further provides authentication information that accompanies data or commands to the second remote service (<NUM>), wherein the validated connection between the first remote service (<NUM>) and the second remote service (<NUM>) is established based on use of the authentication information.