JP2022519805A - モノのインターネット（ＩｏＴ）デバイス用クラウドツークラウドアクセスの確立 - Google Patents

Abstract

関連付けられたクラウドサービスを介したモノのインターネット（ＩｏＴ）セッティングにおけるデバイスツーデバイス通信のためのシステムおよび方法が説明される。例において、第１ドメインまたはエコシステムに関連付けられた第１ＩｏＴデバイスによって、第２ドメインまたはエコシステムに関連付けられた第２ＩｏＴデバイスと通信するために実行される手順は、第２デバイスに関連付けられた第２サービスと通信するために通信情報を取得する手順と、第１デバイスに関連付けられた第１サービスに通信情報を提供する手順と、第１サービスが第２サービスとの検証手順を開始したことに応答して、サービス検証情報を取得する手順と、サービス検証情報を第１サービスに提供する手順とを含む。このサービス検証情報は、第１サービスと第２サービスとの間の検証済み接続を実現し、次に、第１および第２リモートサービスを介して、第１デバイスと第２デバイスとの間でデータまたはコマンドを通信するために用いられる。

Description

［優先権の主張］
本願は、２０１９年２月１４日に出願された米国仮出願第６２／８０５，６９４号に対する優先権の利益を主張し、これはその全体が参照によって本明細書に組み込まれる。

本明細書において説明される実施形態は、概して、データ通信および相互接続されたデバイスネットワークに関し、特に、モノのインターネット（ＩｏＴ）デバイスおよびサービスによる接続性の確立、デバイスプロビジョニングの実行、ならびにデータおよびコマンド交換の容易化に関する。

ＩｏＴデバイスは、ネットワーク上で通信可能な物理的なまたは仮想化されたオブジェクトであり、センサ、アクチュエータ、および他の入力／出力コンポーネントを含んでよく、現実世界の環境からデータ収集または動作の実行等を行う。例えば、ＩｏＴデバイスは、建物、車両、パッケージ等のような日常的な物に埋め込まれまたは取り付けられる低電力デバイスを含んでよく、これらの物のさらなるレベルの人工的感覚認知を提供する。近年、ＩｏＴデバイスはよりポピュラーになり、このため、これらのデバイスを用いたアプリケーションが急増している。

ＩｏＴデバイスをより効果的に相互接続し、動作させ、新たなタイプのＩｏＴネットワークのユースケースを可能にするために、様々な規格が提案されている。これらは、米電気電子技術者協会（ＩＥＥＥ）のようなグループによって配布された通信規格を特殊化したものまたはＺｉｇｂｅｅ（登録商標）、およびＯｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ（ＯＣＦ）のようなグループによって配布されたアプリケーションインタラクションアーキテクチャおよび構成の規格を特殊化したものを含む。これらの規格に加え、ＩｏＴデバイスにより交換されるデータおよびコマンドを管理するために、様々なサービスおよびアプリケーションが積極的に開発され、クラウドサービスプラットフォームおよび他のリモートコンピューティングシステムにおいて展開されている。

図面は必ずしも縮尺通りに描かれておらず、ここで、同様の番号は、異なる図において同様のコンポーネントを記述し得る。異なる添え字を有する同様の番号は、同様のコンポーネントの異なる例を表し得る。いくつかの実施形態は、添付図面の図において、例として示されるものであって、限定するものではない。

例に係る、それぞれのゲートウェイへのリンクを介して結合されたそれぞれのモノのインターネット（ＩｏＴ）ネットワークのためのドメイントポロジを示す。

例に係る、クラウドコンピューティングネットワークのエッジにおいてフォグシステムとして動作するＩｏＴデバイスのメッシュネットワークと通信するクラウドコンピューティングネットワークを示す。

例に係る、自動クラウドツークラウドデバイスのアクセスプロビジョニングに関するユースケースの概要を示す。

例に係る、クラウドツークラウドデバイスの接続を発見および確立するためのオペレーションのフローチャートを示す。

例に係る、クラウドツークラウドデバイスのアクセスプロビジョニングに関して、第１ドメインと第２ドメインとの間で交換される通信の詳細な概要を示す。

例に係る、クラウドツークラウド検証情報を確立および交換するためのオペレーションのフローチャートを示す。

例に係る自動クラウドツークラウド登録および検証技術を実装するためのデバイスおよび装置構成の図を示す。

例に係る自動クラウドツークラウド登録および検証技術を実装するためのオペレーションのフローチャートを示す。

例に係る、多数のＩｏＴデバイスの中での通信を示すネットワークのブロック図を示す。

例に係る、本明細書において説明される技術（例えば、オペレーション、処理、方法、および方法論）のいずれか１つまたは複数が実行され得る例示的なＩｏＴ処理システムアーキテクチャのブロック図を示す。

以下の説明において、複数のクラウドサービスシナリオにおいて、ＩｏＴデバイスサービスのアクセスおよび承認を実装するための方法、構成、および関連装置が開示される。具体的には、この技術は、異なるサービスプロバイダまたは企業によって（例えば、Ａ社のために／によってホストされ、Ａ社によって製造またはサービスされるＩｏＴデバイスの第１のセットによる使用のためのデバイスサービスＡＰＩを提供するクラウド１と、Ｂ社のために／によってホストされ、Ｂ社によって製造またはサービスされるＩｏＴデバイスの第２のセットによる使用のためのデバイスサービスＡＰＩを提供するクラウド２との間で）ホストされる異なるドメインのような異なるオペレーショナルドメインで動作する、またはユーザ、組織、またはエンティティ（例えば、信頼できるデバイス対ゲスト／信頼できないデバイスのセットを有するユーザ、異なるユーザグループを有する組織等）ＩｏＴの異なるグループまたはドメインのために確立されたクラウドサービスによって提供される様々なデータサービス、機能、およびＡＰＩのアクセシビリティを可能にする。

現在の技術およびシステム構成により、クラウドサービスの接続性に関する情報は、ユーザの最小限の関与で、または関与なしで、ローカルネットワークを介して共有および検証可能である。このような機能は、サービス間で確立された適切なクラウドツークラウド接続性を介してループが閉じているので、ローカルネットワークを介して開始されようとするユーザアイデンティティ、デバイスアイデンティティおよびクラウドサービスアカウントアイデンティティのクローズドループ検証を可能にする。また、現在の技術およびシステム構成により、デバイスツーデバイスおよびクラウドツークラウドの通信および通信経路に必要な資格情報および構成は、ユーザが個々のサービスを構成または認証する必要なく、自動的にセットアップおよび使用可能である。

開示されるアプローチは、アカウントおよびデバイスサービスを、従来のアプローチよりもはるかに容易に（かつ、よりセキュアに）リンクさせる結果を提供する。開示されるアプローチは、自動化されたデータ交換およびサービス、またはアカウントを発見またはリンクする拡張されたユーザコマンドの展開をも可能にする。これらの拡張されたユーザコマンドは、「あなたはデバイスをリンクしたいですか」とユーザに質問するユーザプロンプトに基づいて、ユーザが選択した「全ての利用可能なクラウドサービスを接続する」オプションに基づいて、または他の形の規則またはクライアント入力に基づいて行われてよい。開示されるアプローチは、多くのタイプおよび形式のクライアントデバイス、クラウドサービス、およびエコシステムエンティティにも拡張可能である。

ＯＣＦによって提案されているもののような多くの開発中のＩｏＴ規格は、複数の異なる製造者からのデバイスが適切なセキュリティ情報をプロビジョニングされれば、当該デバイスがローカルネットワークの接続性を介して発見可能かつ制御可能になることを想定している。ローカルネットワーク上でのプロビジョニング後、このようなデバイスは、プロプライエタリなプロトコルまたはネットワークプロトコルのクラウド版（例えば、ＯＣＦプロトコル）を介して、これらの製造者またはサービスプロバイダのクラウドサービスにも接続されることになる。これらのデバイスのクラウドサービスが容易に互いにインタラクションし、データ交換する能力は、重要なユースケースになることも期待される。

以下の技術は、現在のデバイスツーデバイスおよびデバイスツークラウド通信のシーケンスのふるまいおよびオペレーションに対する変形を提供し、異なる製造者またはサービスプロバイダのサービスの中でのクラウドツークラウドインテグレーションを可能にする。これは、異なるタイプおよび製造者のデバイスまたはサービスプロバイダが、容易に互いにリンクおよび統合されるアカウントおよびサービスを有することを可能にする。結果として、デバイスからサービスへオンボーディングおよびプロビジョニングし、様々な異なるサービスおよびサービスタイプの中で、かつ、（例えば、ＯＡｕｔｈトークンを交換する）オープンな承認サービスまたは複雑なサインイン手順の使用なしで、クラウドツークラウドインテグレーションを可能にする、向上したユーザエクスペリエンスが提供可能となる。

図１は、それぞれのゲートウェイへのリンクを介して結合されたそれぞれのＩｏＴネットワークの例示的なドメイントポロジを示す。ＩｏＴは、多数のコンピューティングデバイスが、互いにかつインターネットに相互接続され、非常に低いレベルでの機能およびデータの獲得を提供する展開をサポートする。このため、本明細書で用いられるように、ＩｏＴデバイスは、他のＩｏＴデバイスおよびインターネットのようなより広域のネットワークと通信し、とりわけセンシングまたは制御のような機能を実行する半自律的デバイスを含んでよい。

多くの場合、ＩｏＴデバイスは、メモリ、サイズ、または機能が限定されているので、より少数のより大型のデバイスと同様のコストで、より多数を展開可能である。ただし、ＩｏＴデバイスは、スマートフォン、ラップトップ、タブレット、またはＰＣ、または他のより大きなデバイスであってよい。さらに、ＩｏＴデバイスは、スマートフォンまたは他のコンピューティングデバイス上のアプリケーションのような仮想デバイスであってよい。ＩｏＴデバイスは、ＩｏＴデバイスを他のＩｏＴデバイスおよびクラウドアプリケーションに結合すべく、データストレージおよび処理制御等のために使用されるＩｏＴゲートウェイを含んでよい。

ＩｏＴデバイスのネットワークは、配水システム、配電システム、パイプライン制御システム、プラント制御システム、ライトスイッチ、サーモスタット、ロック、カメラ、アラーム、モーションセンサ等のような商用およびホームオートメーションデバイスを含んでよい。ＩｏＴデバイスは、リモートコンピュータ、サーバ、および他のシステムを通じて、例えば、制御システムまたはアクセスデータにアクセス可能であってよい。

インターネットおよび同様のネットワークの将来的な成長には、非常に多数のＩｏＴデバイスが関与しよう。従って、本明細書において説明される技術の文脈において、このような将来のネットワーキングのための多数のイノベーションが、これらの層の全てが妨げられることなく成長し、アクセス可能な接続されたリソースを発見および生成し、接続されたリソースを非表示にして区分化する能力をサポートする必要性に対処することになろう。各プロトコルおよび規格は、特定の目的に対処するように設計されるので、任意の数のネットワークプロトコルおよび通信規格が使用されてよい。さらに、プロトコルは、位置、時間または空間にかかわらず動作する、人間がアクセス可能なサービスをサポートする仕組みの一部である。イノベーションは、サービス供給ならびにハードウェアおよびソフトウェアのような関連付けられたインフラストラクチャと、セキュリティ強化と、サービスレベルおよびサービス供給契約において提供されるサービス品質（ＱｏＳ）条件に基づくサービスのプロビジョニングとを含む。図１および２において紹介するもののようなＩｏＴデバイスおよびネットワークの使用は、有線および無線技術の組み合わせを含む接続性の異種ネットワークにおいて、多数の新たな課題をもたらすことが理解されよう。

図１は、具体的には、ＩｏＴデバイス１０４を備える多数のＩｏＴネットワークに用いられ得るドメイントポロジを単純化した図面を提供する。ＩｏＴネットワーク１５６、１５８、１６０、１６２は、バックボーンリンク１０２を通じてそれぞれのゲートウェイ１５４に結合される。例えば、多数のＩｏＴデバイス１０４が、ゲートウェイ１５４と通信してよく、ゲートウェイ１５４を通じて互いに通信してよい。図面を簡略化するために、全てのＩｏＴデバイス１０４または通信リンク（例えば、リンク１１６、１２２、１２８または１３２）には符号が付されていない。バックボーンリンク１０２は、光ネットワークを含む任意の数の有線または無線技術を含んでよく、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、またはインターネットの一部であってよい。さらに、このような通信リンクにより、様々なデバイスの相互接続を容易にする多重化／多重分離コンポーネントの使用を含む、ＩｏＴデバイス１０４およびゲートウェイ１５４の両方の間の光信号経路が容易になる。

ネットワークトポロジは、Ｂｌｕｅｔｏｏｔｈ（登録商標）Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）リンク１２２を用いるネットワーク１５６を備えるメッシュネットワークのようなタイプのＩｏＴネットワークを任意の数含んでよい。存在し得る他のタイプのＩｏＴネットワークは、ＩＥＥＥ８０２．１１（Ｗｉ－Ｆｉ（登録商標））リンク１２８を通じてＩｏＴデバイス１０４と通信するために用いられる無線ローカルエリアネットワーク（ＷＬＡＮ）ネットワーク１５８、ＬＴＥ／ＬＴＥ－Ａ（４Ｇ）または５Ｇセルラネットワークを通じてＩｏＴデバイス１０４と通信するために用いられるセルラネットワーク１６０、例えば、ＬｏＲａ Ａｌｌｉａｎｃｅにより公表されるＬｏＲａＷＡＮ仕様と互換性があるＬＰＷＡネットワークなどの低電力ワイドエリア（ＬＰＷＡ）ネットワーク１６２、または、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）により公表される仕様と互換性があるＩＰｖ６ ｏｖｅｒ Ｌｏｗ Ｐｏｗｅｒ Ｗｉｄｅ－Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＰＷＡＮ）ネットワークを含む。さらに、それぞれのＩｏＴネットワークは、例えば、ＬＴＥセルラリンク、ＬＰＷＡリンク、またはＺｉｇｂｅｅ（登録商標）のようなＩＥＥＥ８０２．１５．４規格に基づくリンクなど、任意の数の通信リンクを用いて、外部ネットワークプロバイダ（例えば、ティア２プロバイダまたはティア３プロバイダ）と通信してよい。それぞれのＩｏＴネットワークは、制約付きアプリケーションプロトコル（ＣｏＡＰ）のような様々なネットワークプロトコルおよびインターネットアプリケーションプロトコルを用いて動作してもよい。それぞれのＩｏＴネットワークは、リンクされたデバイスおよびネットワークのクラスタツリーを形成するリンクのチェーンを提供するコーディネータデバイスと統合されてもよい。

これらのＩｏＴネットワークの各々は、本明細書において説明するもののような新たな技術的特徴の機会を提供し得る。改良された技術およびネットワークにより、「フォグ」または「エッジクラウド」デバイスまたはシステムに統合されたＩｏＴネットワークの使用を含め、デバイスおよびネットワークの指数的な成長が可能となろう。このような改良された技術の使用が成長するにつれて、ＩｏＴネットワークは、人間が直接介入する必要なく、自己管理、機能進化およびコラボレーションのために開発されるようになろう。改良された技術は、ＩｏＴネットワークが集中制御システムなしで機能することさえ可能にし得る。従って、本明細書において説明する改良された技術は、現在の実装をはるかに越えてネットワーク管理およびオペレーション機能を自動化および強化するために用いられてよい。

例において、例えばバックボーンリンク１０２を介したＩｏＴデバイス１０４間の通信は、認証、承認および課金（ＡＡＡ）のための分散化システムにより保護されてよい。分散化ＡＡＡシステムでは、分散型の決済、クレジット、監査、承認および認証システムが、相互接続された異種ネットワークインフラストラクチャにわたって実装されてよい。これにより、システムおよびネットワークを自律型運用へ移行させることが可能になる。これらのタイプの自律型運用では、機械が人的リソースの契約を締結し、他の機械ネットワークとのパートナシップを交渉することさえ行われてよい。これにより、相互の目的と、概説され計画されたサービスレベル契約に対してバランスの取れたサービス供給とが実現可能になるだけでなく、計量、測定、トレーサビリティおよび追跡可能性を提供するソリューションが実現されてよい。新たなサプライチェーンの構造および方法を形成することにより、人間が何ら関与することなく、多数のサービスの創出、価値発掘および崩壊が可能になり得る。

このようなＩｏＴネットワークは、音、光、電子トラフィック、顔およびパターン認識、匂いまたは振動のようなセンシング技術をＩｏＴデバイス間の自律組織へ統合することにより、さらに強化されてよい。感知システムの統合により、契約上のサービス目的に対する体系的かつ自律的な通信およびサービス供給調整、オーケストレーション、ならびにリソースのＱｏＳに基づくスウォーミングおよび融合が可能になり得る。ネットワークベースのリソース処理の個々の例は、以下のものを含む。

例えば、メッシュネットワーク１５６は、インラインデータから情報への変換を実行するシステムにより強化されてよい。例えば、マルチリンクネットワークを含むリソース処理の自己形成チェーンは、効率的な方式での生データから情報への変換ならびに資産とリソースとを区別する能力および各々の関連付けられた管理を分散させてよい。さらに、インフラストラクチャならびにリソースに基づく信頼インデックスおよびサービスインデックスの適切なコンポーネントを挿入することで、データのインテグリティ、品質、確実性を向上させ、データの信頼性の測定基準を供給してよい。

例えば、ＷＬＡＮネットワーク１５８は、規格の変換を実行するシステムを用いてマルチスタンダードの接続性を提供することにより、異なるプロトコルを用いるＩｏＴデバイス１０４が通信することを可能にしてよい。さらなるシステムが、可視インターネットリソースと非表示インターネットリソースとを含むマルチスタンダードのインフラストラクチャにわたってシームレスな相互接続性を提供してよい。

例えば、セルラネットワーク１６０内の通信は、データをオフロードするか、通信をより多くのリモートデバイスへ拡張するか、またはその両方を行うシステムにより強化されてよい。ＬＰＷＡネットワーク１６２は、非インターネットプロトコル（ＩＰ）からＩＰへの相互接続と、アドレス指定と、ルーティングとを実行するシステムを含んでよい。さらに、ＩｏＴデバイス１０４の各々は、そのデバイスとのワイドエリア通信のための適切なトランシーバを含んでよい。さらに、各ＩｏＴデバイス１０４は、さらなるプロトコルおよび周波数を用いる通信のための他のトランシーバを含んでよい。これについては、図９および１０に示されるＩｏＴ処理デバイスの通信環境およびハードウェアに関してさらに説明される。

最終的に、ＩｏＴデバイスのクラスタは、他のＩｏＴデバイスとだけでなく、クラウドネットワークとも通信するように備えられてよい。これにより、ＩｏＴデバイスがデバイス間にアドホックネットワークを形成することが可能になり、これらが、フォグデバイス、フォグプラットフォーム、またはフォグネットワークと称され得る単一デバイスとして機能することが可能となってよい。この構成は、図２に関してさらに説明される。

図２は、ネットワークのシナリオにおいてフォグシステムとして動作するＩｏＴデバイス（デバイス２０２）のメッシュネットワークと通信しているクラウドコンピューティングネットワークを示す。ＩｏＴデバイスのメッシュネットワークは、ネットワークのエッジにおいてデバイスのネットワークから確立されたフォグネットワーク２２０またはエッジクラウドと称されてよい。図を簡略化するために、全てのＩｏＴデバイス２０２には符号が付されていない。

フォグネットワーク２２０は、多数のＩｏＴデバイス２０２が、例えば、無線リンク２２２により互いに通信している、大規模に相互接続されたネットワークであるとみなされてよい。フォグネットワーク２２０は、ＩｏＴエッジデバイスとクラウドまたはデータセンタとの間に位置するものとみなされ得る、水平な物理的または仮想的リソースプラットフォームを確立してよい。フォグネットワークは、いくつかの例において、レイヤ型、フェデレーション型、または分散型のコンピューティング、ストレージ、およびネットワーク接続性オペレーションを通して、垂直方向に分離された、レイテンシに敏感なアプリケーションをサポートしてよい。ただし、フォグネットワークは、エッジおよびクラウドにおいて、およびその中で、リソースおよびサービスを分散させるために用いられてもよい。このため、本明細書における「エッジ」、「フォグ」、および「クラウド」という用語は、必ずしも互いに別個のものではなく、または互いを除外するものでもない。

例として、フォグネットワーク２２０は、Ｏｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ（商標）（ＯＣＦ）によりリリースされる相互接続仕様を用いて容易化されてよい。この規格により、デバイスが、互いを発見し、相互接続のための通信を確立することが可能になる。例えば、最適化されたリンク状態ルーティング（ＯＬＳＲ）プロトコル、モバイルアドホックネットワーキングへのより良いアプローチ（Ｂ．Ａ．Ｔ．Ｍ．Ａ．Ｎ．）であるルーティングプロトコルまたはＯＭＡ軽量Ｍ２Ｍ（ＬＷＭ２Ｍ）プロトコルをとりわけ含む他の相互接続プロトコルも用いられてよい。

この例では、ゲートウェイ２０４、データアグリゲータ２２６およびセンサ２２８という３タイプのＩｏＴデバイス２０２が示されているが、ＩｏＴデバイス２０２と機能との任意の組み合わせが用いられてよい。ゲートウェイ２０４は、クラウド２００とフォグネットワーク２２０との間の通信を提供するエッジデバイスであってよく、また、例えば、動きデータ、フローデータおよび温度データ等のような、センサ２２８から取得されるデータのためのバックエンド処理機能をも提供してよい。データアグリゲータ２２６は、任意の数のセンサ２２８からデータを収集し、解析のためのバックエンド処理機能を実行してよい。解析結果、生データ、またはその両方は、ゲートウェイ２０４を通じてクラウド２００に渡されてよい。センサ２２８は、例えば、データの収集およびデータの処理の両方を実行可能なフルＩｏＴデバイス２０２であってよい。いくつかの場合において、センサ２２８は、例えば、データを収集し、データアグリゲータ２２６またはゲートウェイ２０４によるデータの処理を可能にすることなど、機能性においてより限定的であってよい。

任意のＩｏＴデバイス２０２からの通信は、ＩｏＴデバイス２０２のいずれかの間の簡便な経路（例えば、最も簡便な経路）に沿って渡され、ゲートウェイ２０４に到達してよい。これらのネットワークでは、相互接続の数によりかなりの冗長性が提供されるので、多数のＩｏＴデバイス２０２が失われた場合でさえ通信を維持することが可能になる。さらに、メッシュネットワークの使用は、非常に低電力であるか、またはインフラストラクチャから離れた所に位置するＩｏＴデバイス２０２を用いることが可能としてよい。なぜなら、別のＩｏＴデバイス２０２に接続する範囲が、ゲートウェイ２０４に接続する範囲よりもはるかに小さいことがあるからである。

これらのＩｏＴデバイス２０２から提供されるフォグネットワーク２２０は、クラウド２００のエッジに位置する単一デバイス、例えば、デバイスまたはプラットフォームとして動作するフォグネットワークとして、サーバ２０６のようなクラウド２００内のデバイスに提供されてよい。この例では、フォグデバイスから入ってくるアラートは、フォグネットワーク２２０内の特定のＩｏＴデバイス２０２から来たものと特定されることなく送信されてよい。このように、フォグネットワーク２２０は、とりわけ、データ解析、データ集約および機械学習のような処理またはデータ集中型タスクを実行するためのコンピューティングおよびストレージリソースを提供する分散プラットフォームとみなされてよい。

いくつかの例では、ＩｏＴデバイス２０２は、命令型プログラミングスタイルを用いて構成されてよく、例えば、各ＩｏＴデバイス２０２は、特定の機能および通信パートナを有する。ただし、フォグデバイスを形成するＩｏＴデバイス２０２は、宣言型プログラミングスタイルで構成されるので、ＩｏＴデバイス２０２が、例えば、条件、クエリおよびデバイス故障に応答して必要なリソースを決定するような、これらのオペレーションおよび通信を再構成することが可能となってよい。例として、ＩｏＴデバイス２０２により監視される機器のサブセットのオペレーションについてのサーバ２０６に位置するユーザからのクエリの結果として、フォグネットワーク２２０デバイスは、クエリに応答するために必要な特定のセンサ２２８のようなＩｏＴデバイス２０２を選択してよい。次に、これらのセンサ２２８からのデータは、クエリに応答するためにフォグネットワーク２２０デバイスによりサーバ２０６へ送信される前に、センサ２２８、データアグリゲータ２２６またはゲートウェイ２０４の任意の組み合わせにより集約および解析されてよい。この例では、フォグネットワーク２２０内のＩｏＴデバイス２０２は、例えば、流量センサまたは温度センサからのデータを追加するなど、クエリに基づいて用いられるセンサ２２８を選択してよい。さらに、ＩｏＴデバイス２０２のうちのいくつかが動作可能でない場合において、フォグネットワーク２２０デバイス内の他のＩｏＴデバイス２０２が、利用可能であるときは類似データを提供してよい。

異なるクラウドサービスとサービスプロバイダ（または異なるＩｏＴ製品ベンダ）との間でインターオペラビリティを可能にするための既存のアプローチは、多くの場合、低いまたは課題の多いユーザエクスペリエンスを伴う。例えば、製造者／エコシステムＡによって提供されたスマートロックを、製造者／エコシステムＢによって提供されたスマートスピーカと共に動作するように構成することは、（例えば、製造者／エコシステムＡによって提供されるスキル）スマートロックのコンポーネントをスマートスピーカのアプリケーションにおいて手動で選択し、次に、多くの場合ＯＡｕｔｈログインウェブページを介して、製造者／エコシステムＡによるユーザアカウントに手動でログインする必要がある。

現在のアプローチでは、複数の手動ステップおよびメニュー選択、ならびにユーザの資格情報の別のセットのプロビジョニングは、人間であるユーザによって調整されなければならない。このタイプのアカウントのリンクは自動化が不可能であり、知的なユーザがいる限定的な家庭環境で動作することはあっても、大規模な人口または大規模なＩｏＴ展開での使用に拡張可能ではない。少数のアカウントの手動アカウントリンクに必要とされるトータルのオーバヘッドは甚大ではないが、このような手動のアプローチでは、データをサービス間で広く共有することは不可能であり、多くのＩｏＴユースケースによって意図される接続の実際のウェブのサポートにはならない。

以下の例は、デバイス接続を自動的かつ遥かに単純な方式で認証および確立する技術によるものを含め、デバイスがデバイスのより大きいセットまたはファミリに追加可能な、またはそれとして管理可能な特定の手段を説明する。これらの例では、デバイスのセットの構成に関する情報は、ＩｏＴデバイスネットワークのトラバーサルを実行するために必要な情報を提供する１つまたは複数のトークンにより確立および交換されてよい。これらのトークンは、外部ドメインで他のノードに通知するために内部で順に回されてよく、クラウドおよびクラウドサービスを介してデバイスツーデバイス経路をセットアップする。

様々な例において、２つのデバイスおよび２つのドメインを参照して説明がなされる。ただし、拡張により、これらのアプローチは、３つまたはそれより多くのドメイン、３つまたはそれより多くのデバイス、既存のドメインおよびデバイスとのインテグレーション、および他のバリエーションにも適用されてよい。したがって、以下の例は２つのドメインを参照して提供されるが、ｎ個のドメインに適用されてよいことが理解されよう。

図３は、自動クラウドツークラウドデバイスアクセスプロビジョニングのための拡張されたユースケースの概要を提供する。図示されるように、ローカルデバイス環境（例えばＯＣＦデバイス環境）内において、第１企業またはエコシステム（Ａ社）に関連付けられた第１デバイス３１４（例えば、リモート制御アプリケーションのようなスマートフォンアプリ）が、既に第２企業またはエコシステム（Ｂ社）に関連付けられている新たな第２デバイス３２４（例えば電球）を発見する。この発見（データフロー（１））は、デバイス情報、クラウド情報、セキュリティ情報（例えば許可およびリンクセキュリティの相互認証）等のような、新たなデバイスに関連付けられた情報の特定を含む。

異なる「企業」からのクラウドドメインが図３に示されているが、同じ原理があらゆるタイプの異なるクラウドドメインにも適用可能であることが理解されよう。異なるクラウドドメインが、同じユーザ、企業、組織、またはエンティティに関連付けられた異なるデバイスグループのために確立されてよい。従って、本明細書において説明されるクラウドおよびサービスグループは、サービスクラウド、プライベートクラウド、オンプレミスクラウド、または他の構成の一部として提供されてよいことが理解されよう。これらおよび他の構成は、通常は分離されているであろう異なるドメインを含んでよいが、資格情報、データ、およびコマンドを共有する以下のアプローチを用いてよい。

第１デバイス３１４は、次に、その関連付けられたクラウドサービス３１２（Ａ社クラウド）と通信し、クラウドサービス３１２に、新たな第２デバイス３２４に関連付けられた第２クラウドサービス３２２（Ｂ社クラウド）とコンタクトし、これらのクラウドサービス間（クラウド３１２および３２２の間）で検証を開始するよう命令する（データフロー（２））。これに続いて、クラウドツークラウド通信が行われて検証を開始し（データフロー（３））、新たな第２デバイス３２４に戻される検証情報の通信が行われる（データフロー（４））。

第２デバイス３２４は、次に、この検証情報を取得し、これを（データフロー（１）で既に確立されていたローカルネットワーク接続を介して）第１デバイス３１４に戻し、第１デバイスは、次に、その関連付けられたクラウドサービス（Ａ社クラウド）に戻してよい（データフロー（５）を完了）。両方のクラウド３１２、３２２間で交換されている検証情報により、第１クラウドサービス３１２は、例えば、第１デバイス３１４を用いて、クラウドツークラウド通信を介して第２デバイス３２４を制御する（データフロー（６））など、第２クラウドサービス３２２によって提供されるサービスを制御する、または別の方法でこれとインタラクションすることが可能である。

このように、図３から詳細に説明される手順の結果、デバイスツーデバイス（Ｄ２Ｄ）制御または通信が、デバイスツークラウドツークラウドツーデバイス（Ｄ２Ｃ２Ｃ２Ｄ）方式で行われる。検証情報が完全に交換された後、他のコマンドおよびデータが、クラウド３１２および３２２を介して、デバイス３１４および３２４の間で（デバイス３２４からデバイス３１４への方向を含む）交換されてよいことが明らかであろう。

図４は、図３について上述したシナリオの実装のようなクラウドツークラウドデバイス接続を発見および確立するための方法４００のフローチャートを示す。

オペレーション４０５において、デバイスツーデバイス発見がローカルネットワーク上で実行される。これは、（例えば、ＯＣＦネットワークにおいて）既存のネットワークプロトコル、通信の発見、またはネットワークプロビジョニングの使用を含んでよい。これは、図３に示すデータフロー（１）に基づいていてよい。

オペレーション４１０において、例えば、第１クラウドサービスに提供された命令または情報に基づいて、第１クラウドサービスと第２クラウドサービスとの間で接続が開始される。これは、図３に示すデータフロー（２）、（３）に基づいていてよい。

オペレーション４１５において、検証情報が、第２クラウドサービスから通信され、接続されたローカルデバイス（例えば、第２クラウドサービスに関連付けられたデバイス）に戻される。これは、図３に示すデータフロー（４）に基づいていてよい。

オペレーション４２０において、第２クラウドサービスから取得された検証情報が、接続されたローカルデバイスを介して第１クラウドサービスに通信される。これは、図３に示すデータフロー（５）に基づいていてよい。

オペレーション４２５において、検証情報がリンクされたインタフェースおよびサービス内で用いられ、第１クラウドサービスが、第２クラウドサービス内で様々な承認された態様を通信および制御する、またはデータにアクセスすることが可能となる。これは、図３に示すデータフロー（６）に基づいていてよい。同じ方式で、第２クラウドサービスは、第１クラウドサービス内で、承認された態様で通信および制御を行ってよい、またはデータにアクセスしてよい。

図５は、（デバイス／ユーザ機器ＡおよびクラウドＡを含む）第１ドメインと（デバイス／ユーザ機器Ｂを含む）第２ドメインとの間で交換される通信のより詳細な概要を提供する。このシナリオでは、ユーザ（ユーザＡ，ユーザＢ）の各々は、ドメインコンテキスト内でＩｏＴネットワークを管理および制御することを承認された人（例えば、同じ人または異なる人）である。ユーザ機器（ＵＥ）は、ユーザプラットフォーム（これ自体がＩｏＴデバイスであってよい）であり、このユーザプラットフォームから、ユーザはデバイス、ネットワーキング、およびドメインオペレーションを制御および管理する。さらに、図５の例では、様々なトークンおよび承認資格情報の使用によるものを含め、認証情報が生成および交換され得る手段に関するさらなる詳細が提示される。

図５の環境では、プライマリＩｏＴネットワーク（家のウィジェット「Ａ」で表される）はローカルＩｏＴネットワーク（例えばＯＣＦ通信仕様を介して接続された接続済みデバイスのネットワーク）である。この例において、プライマリＩｏＴネットワークは、ＩｏＴ仕様（例えばＯＣＦ仕様）に従って動作するいくつかのデバイスをドメイン（例えばＡ．Ｄ１，Ａ．Ｄ２，Ａ．Ｄ３）内に含む。

シャドウイングＩｏＴネットワーク（それぞれのクラウドネットワーク内の破線の家のウィジェットで表される）は、特定のドメインのためのＩｏＴネットワークに含まれる物理デバイスのソフトウェア表現を提供する。各クラウド（例えば、クラウド３１２、３２２）は、クラウドサービスプロバイダ、エッジコンピューティングインフラストラクチャによってホストされるドメイン固有のリソース、機能、およびサービスのセットを提供する。ドメインコンテキストは、仮想化、セキュアな実行環境（例えば、ＡＲＭ、ＴｒｕｓｔＺｏｎｅ、Ｉｎｔｅｌ（登録商標）ＳＧＸ等）、コンテナ、および物理的パーティショニングのようなクラウドテナント分離技術を用いて分離されてよい。

図５の環境は、デバイスの発見および認証のための様々な機能をも含む。これは、各ドメインへのクラウドリソースディレクトリ（ＣＲＤ）５１０，５２０と、各ドメインへの承認サーバ（ＡＳ）５１２，５２２とを含むものとして示されている。ＣＲＤ５１０，５２０は、ピアドメインによって可視のシャドウイングデバイスを発行および同期し、ピアドメインから可視のシャドウイングデバイスをホストするクラウド環境においてホストされるリソースディレクトリサービスである。ＡＳ５１２，５２２は、（例えば、ＯＡｕｔｈ２または任意の数の他の承認アプローチを用いた）承認トークン許可機能を実装するローカルまたはクラウドサービスである。承認サーバによって生成され、様々なデバイス間で通信されるトークンは、さらに詳細に後述されるように、ＪＳＯＮウェブトークンフォーマットで提供されてよい。

図５の環境内の情報のフローは、それぞれのデータフローによって以下のように示される。図３を参照して上述されたクラウド環境３１２、３２２は、各クラウド（例えば、Ａ社およびＢ社用のデバイスに対応するドメイン）に関連付けられた、企業またはベンダに対応するそれぞれのドメインにセグメント化される。

データフロー（１）において、ユーザＡによって制御されるユーザ機器（ＵＥ_Ａ５１４）は、クラウドツークラウドプロビジョニングおよびインターオペレーションを管理するための承認を取得する。承認権は、ドメインＡに関連付けられた承認サーバＡＳ_Ａ５１２から取得された承認トークン（例えば、トークンＴ１－Ｔ１１）内に含まれる。これらの承認は、ユーザＡによって、ユーザＡによってもしくはこれを代理して確立された規則によって、またはユーザＡによって制御もしくは影響されているソフトウェアもしくは他の処理によって、開始または制御されてよい。承認トークンは、後続のデータフローにおいて利用される。

データフロー（２）において、ＵＥ_Ａ５１４は、ドメインＡにおけるＩｏＴネットワークに、シャドウイングサービス５１６において、そのデバイスのいくつかまたは全てをシャドウイングする（この例では、デバイスＡ．Ｄ１，Ａ．Ｄ２をシャドウイングするが、Ａ．Ｄ３はしない）ように命令する。これは、ベンダＡに対応するクラウド環境３１２において、シャドウイングされたロジカルデバイスの第１のセットを確立する。

データフロー（３）において、（例えば、ドメインＡにアクセス可能な、オンボードされた、またはプロビジョニングされた）ＩｏＴネットワーク－Ａ上の物理デバイス（Ａ．Ｄ１、Ａ．Ｄ２）は、ドメイン－Ａのシャドウイングサービス５１６からデバイスのシャドウイングを要求する。先述のデータフロー（１）から取得されたトークンＴ１およびＴ２は、このオペレーションを承認する。

データフロー（４）において、ＵＥ_Ａ５１４は、シャドウイングサービスＡ５１６に、シャドウイングされたデバイスをディレクトリに発行するように命令する。これに続いて、データフロー（５）では、シャドウイングサービスＡは、ＣＲＤ_Ａ５１０のようなクラウドリソースディレクトリ（または他のデバイス情報ディレクトリ）を用いて、シャドウイングされたデバイスを発行する。トークンＴ３は、この動作を承認するために用いられる。

データフロー（６）において、ＣＲＤ_Ａ５１０は、ピアドメイン（例えば、ドメインＢ）による消費のために、シャドウイングされたデバイスＡ．Ｓ１についての情報を発行する。例えば、これは、ＣＲＤ_Ｂ５２０のような別のクラウドリソースディレクトリにエントリを形成することを含んでよい。（このエントリは、図５において、ＣＲＤ_Ｂ５２０の隣のボックスに示される情報によって示される。）

データフロー（７）において、ユーザＢは、ピアドメインにおけるデバイスの可用性について通知され、ユーザＢによって制御されるユーザ機器（ＵＥ_Ｂ５２４）を用いて、ドメインＡおよびドメインＢのデバイス（またはこれらのデバイスのサブセット）間でインタラクションを可能にする。ＵＥ_Ｂ５２４は、ドメインＢに関連付けられた承認サーバＡＳ_Ｂ５２２から承認トークンを取得することによって、クラウドツークラウドインタラクションを実行するための承認を取得する。

データフロー（８）において、ＵＥ_Ｂ５２４は、ドメインＢに関連付けられたどのデバイスがシャドウイングされ得るかを示す（例えば、デバイスＢ．Ｄ１、Ｂ．Ｄ２）。これに続いて、データフロー（９）では、デバイスＢ．Ｄ１、Ｂ．Ｄ２が、承認トークンＴ５およびＴ６を用いて、シャドウイングサービスＢ５２６にシャドウイングされる。

データフロー（１０）において、ＵＥ_Ｂ５２４は、シャドウイングサービスＢ５２６に、リソースディレクトリＣＲＤ_Ｂ５２０において新たなデバイスを発見するように命令する。データフロー（１１）において、シャドウイングサービスＢ５２６は、トークンＴ７の承認を用いて、ドメインＡデバイスを発見する。

データフロー（１２）において、ＵＥ_Ｂ５２４は、ドメインＢデバイスがドメインＡデバイスとインタラクションすることが適切であると決定し、ＵＥ_Ｂ５２４は、ドメインＢに関連付けられた承認サーバＡＳ_Ｂ５２２から承認を取得する。

データフロー（１３）において、承認サーバＡＳ_Ｂ５２２は、（シャドウイングデバイスＡ．Ｓ１によってプロキシされる）デバイスＡ．Ｄ１が（シャドウイングデバイスＢ．Ｓ１によってプロキシされる）Ｂ．Ｄ１とインタラクションするための承認をドメイン－Ａから取得するために、承認サーバＡＳ_Ａ５１２にコンタクトする。トークンＴ８は、このインタラクションを承認するために用いられる。

データフロー（１４）において、承認サーバＡＳ_Ａ５１２は、クラウドツークラウドインタラクションがデバイスＡ．Ｄ１およびＢ．Ｄ１間で行われることを承認するトークンＴ１０をＵＥに供給する。

データフロー（１５）において、ＵＥ_Ａは、Ｂ．Ｄ１のセキュアなインタラクションのために資格情報をプロビジョニングする。例えば、トークンＴ１０は、Ａ．Ｄ１の資格情報リソースに関連付けられたドメインＢの信頼アンカーを含んでよい。データフロー（１６）において、ＵＥ_Ｂ５２４は同様に、トークンＴ９を用いて、Ａ．Ｄ１がセキュアなインタラクションを実行するための資格情報をプロビジョニングする。

データフロー（１７）において、ＵＥ_Ｂは、デバイスＢ．Ｄ１に、デバイスＡ．Ｄ１とインタラクションするように命令する。データフロー（１８）において、デバイスＢ．Ｄ１は、シャドウイングデバイスＢ．Ｓ１をクラウドプロキシとして用いて、デバイスＡ．Ｄ１とのエンドツーエンドまたはホップバイホップ接続を確立する。

データフロー（１９）において、シャドウイングデバイスＡ．Ｓ１は、デバイスＡ．Ｄ１のクラウドプロキシとして、そのエンドツーエンドまたはホップバイホップ接続を完了させる。データフロー（２０）において、デバイスＢ．Ｄ１はセキュアなチャネル（例えば、ＴＬＳ，ＯＳＣＯＲＥを介して確立されたセキュアなチャネル）を介して、デバイスＡ．Ｄ１とセキュアにインタラクションする。

図３および５の例は別個の「企業」またはエコシステム管理エンティティに言及しているが、いくつかのドメインのユースケースは、異なるサービスプロバイダ、ベンダ、ＩＴ組織、または人に起因していてよい。また、図示された「クラウド」におけるサービスまたはサーバの使用は、クラウドデータセンタまたはグローバルにアクセス可能なネットワークの使用を必ずしも必要としない。むしろ、サービスまたはサーバの使用は、例えば、異なるユーザ、ユーザグループ、および他のエンティティまたはエンティティグループのためのテナント固有のサービスをホストおよび分離するエッジクラウドセッティングにおいて、フォグまたはエッジコンピューティングシステムの一部として行われてよい。

さらに、（基盤の認証がセットアップされた後で）直接制御またはデータがデバイス間で交換されるデータフロー（２０）に到達したとき、レイテンシが課題になることがある。特に、ＩｏＴセッティングにおいてレイテンシ要件を伴うことがあり、これは、（例えば、ｃｌｏｕｄｌｅｔにおいて）オンプレミスなクラウドエッジデバイスの使用により、または、低レイテンシ特性を有する無線アクセスネットワーク技術を用いた第１ティアエッジ環境により、満たされ得る。他のセッティングでは、レイテンシはクリティカルではないことがある、または、クラウドを介したもしくは直接接続を介したデバイスツーデバイス接続が実行可能とであることを保証するように、さらなるチェックが実行されることがある。

例において、図５のデータフローまたは別の方法で交換される全ての承認トークンは、ユーザおよびドメインコンテキストを含んでよい。例えば、このユーザおよびドメインコンテキストは、そのそれぞれのドメインに対して、ＵＥおよびＡＳを伴うユーザログインの承認を示すために用いられてよい。例示的なトークンのフォーマットは、以下のようなデータを含んでよい。
［表１］
｛
"ＴｏｋｅｎＢｏｄｙ" ＝ ｛
"ＴｏｋｅｎＳｅｒｉａｌＮｕｍｂｅｒ" ＝ ＜ｇｌｏｂａｌｌｙ ｕｎｉｑｕｅ ＩＤ＞；
"ＤｏｍａｉｎＩＤ" ＝ "Ｄｏｍａｉｎ Ｘ"；
"ＵｓｅｒＮａｍｅ" ＝ "Ｕｓｅｒ Ｘ"；
…
｝
"Ｉｓｓｕｅｒ" ＝ "ＡＳＸ"；
"ＩｓｓｕｅｒＳｉｇｎａｔｕｒｅ" ＝ ｛…｝；
｝

例において、トークン固有のフィールドは以下を含んでよい。
［表２］
１． Ｔｏｋｅｎ Ｔ１： ｛ "Ｄｅｖｉｃｅ" ＝ "Ａ．Ｄ１"； "Ｒｉｇｈｔｓ" ＝ "ＤＯ＿ＳＨＡＤＯＷ"； ｝
２． Ｔｏｋｅｎ Ｔ２： ｛ "Ｄｅｖｉｃｅ" ＝ "Ａ．Ｄ２"； "Ｒｉｇｈｔｓ" ＝ "ＤＯ＿ＳＨＡＤＯＷ"； ｝
３． Ｔｏｋｅｎ Ｔ３： ｛ "Ｄｅｖｉｃｅ" ＝ "Ａ．Ｓ１"； "Ｒｉｇｈｔｓ" ＝ "ＤＯ＿ＣＬＯＵＤ＿ＰＵＢＬＩＳＨ"； ｝
４． Ｔｏｋｅｎ Ｔ４： ｛ "Ｄｅｖｉｃｅ" ＝ "Ａ．Ｓ１"； "ＴｏＤｏｍａｉｎ" ＝ "Ｂ"； "Ｒｉｇｈｔｓ" ＝ "ＤＯ＿ＣＬＯＵＤ＿ＰＵＢＬＩＳＨ"；
５． Ｔｏｋｅｎ Ｔ５： ｛ "Ｄｅｖｉｃｅ" ＝ "Ｂ．Ｄ１"； "Ｒｉｇｈｔｓ" ＝ "ＤＯ＿ＳＨＡＤＯＷ"； ｝
６． Ｔｏｋｅｎ Ｔ６： ｛ "Ｄｅｖｉｃｅ" ＝ "Ｂ．Ｄ２"； "Ｒｉｇｈｔｓ" ＝ "ＤＯ＿ＳＨＡＤＯＷ"； ｝
７． Ｔｏｋｅｎ Ｔ７： ｛ "Ｄｅｖｉｃｅ" ＝ "Ｂ．Ｓ１"； "Ｒｉｇｈｔｓ" ＝ "ＤＯ＿ＣＬＯＵＤ＿ＤＩＳＣＯＶＥＲ"； ｝
８． Ｔｏｋｅｎ Ｔ８： ｛ "ＦｍＤｏｍａｉｎ" ＝ "Ｂ"； "ＦｍＤｅｖｉｃｅ" ＝ "Ｂ．Ｄ１"； "ＴｏＤｏｍａｉｎ" ＝ "Ａ"； "ＴｏＤｅｖｉｃｅ" ＝ "Ａ．Ｄ１"； "Ｒｉｇｈｔｓ" ＝ "ＤＯ＿ＣＬＯＵＤ＿ＣＯＮＴＲＯＬ"； "ＥｍｂｅｄｄｅｄＴｏｋｅｎ" ＝ ＜Ｔｏｋｅｎ．Ｔ９＞ ｝
９． Ｔｏｋｅｎ Ｔ９： ｛ "ＦｍＤｏｍａｉｎ" ＝ "Ｂ"； "ＦｍＤｅｖｉｃｅ" ＝ "Ｂ．Ｄ１"； "ＴｏＤｏｍａｉｎ" ＝ "Ａ"； "ＴｏＤｅｖｉｃｅ" ＝ "Ａ．Ｄ１"； "Ｒｉｇｈｔｓ" ＝ "ＤＯ＿ＯＳＣＯＲＥ＿ＳＥＳＳＩＯＮ" ｝
１０． Ｔｏｋｅｎ Ｔ１０： ｛ "Ｄｅｖｉｃｅ" ＝ "Ａ．Ｄ１"； "ＴｏＤｏｍａｉｎ" ＝ "Ｂ"； "ＴｏＤｅｖｉｃｅ" ＝ "Ｂ．Ｄ１"； "Ｒｉｇｈｔｓ" ＝ "ＡＬＬＯＷ＿ＣＬＯＵＤ＿ＣＯＮＴＲＯＬ" ｝

したがって、図５の様々な例において、トークンは署名され、承認サーバによって発行されたＪＳＯＮウェブトークンフォーマットの承認データを含む。他の例では、他の符号化の形が、このトークンによって提供されるデータを通信および交換するために用いられてよい（例えば、ＸＭＬ符号化）。また、デジタル証明書が認証局（ＣＡ）に紐づけられた署名エンティティからの署名を含むシナリオを含め、デジタルセキュリティ証明書または同様のセキュリティデータオブジェクトが、承認データを通信するために利用されてよい。ＣＢＯＲウェブトークンの使用、証明書に埋め込まれたｘ．５０９トークン、非対称鍵の使用、およびＯＡｕｔｈ、ＯＡｕｔｈ２、およびケルベロスのようなサインオンアプローチを含む他のバリエーションは、上述した承認通信スキームの一部として用いられてよい。

上述されたように、様々なデバイスおよび通信は、ＯＣＦ仕様に従って行われてよく、これは、デバイス間およびクラウドサービスとの様々なアクセスリソース、リソースコマンド、および通信フォーマットを定義する。ＯＣＦセッティング内でデバイスの構成を実現するために、ＯＣＦの実装によって利用されるリソースは、以下と同様のリソースを含んでよい。
・／ＣＲＤ－発見可能なピアドメインおよびこれらの共有シャドウイングデバイスを含む。ピアＣＲＤサーバは、共有リソースでエントリを更新または同期してよい。
・／Ｓｈａｄｏｗ－ローカルドメインの物理デバイスに対応するシャドウイングリソースを含む。
・／ＡＳ－発行された承認トークンおよびこれらのステータスのリソース表現を含む。
・／ＲＤ－クラウドリソース（／Ｓｈａｄｏｗ、／ＣＲＤ、／ＡＳ）への参照を含む。

図６は、例えば、図５について上述したシナリオの実装で、クラウドツークラウド検証情報を確立および交換するための方法のフローチャート６００を示す。

オペレーション６０５において、デバイスシャドウイングが、第１のネットワークおよび第２のネットワークにおいて確立される。このオペレーションは、図５に示すデータフロー（１）、（２）、（３）、（９）を実装してよく、またはこれらに基づいていてよい。

オペレーション６１０において、シャドウイングされたデバイスは、クラウドリソースディレクトリを用いて発行される。このオペレーションは、図５に示すデータフロー（４）、（５）、（６）を実装してよく、またはこれらに基づいていてよい。

オペレーション６１５において、第１のネットワークおよび第２のネットワークにおいてデバイスを接続するユーザ承認および命令が（例えば、ＵＥのユーザ入力を介して、ユーザの予め定義された規則、コマンド、またはデータを介して、等）取得される。このオペレーションは、図５に示すデータフロー（７）、（８）、（１０）、（１１）、（１２）を実装してよく、またはこれらに基づいていてよい。

オペレーション６２０において、第１のネットワークおよび第２のネットワーク内のデバイスと接続するために、認証資格情報が交換される。このオペレーションは、図５に示すデータフロー（１２）、（１３）、（１４）、（１５）、（１６）を実装してよく、またはこれらに基づいていてよい。

オペレーション６２５において、方法は、第１のネットワークと第２のネットワークとの間で確立された接続を用いて、リンクされたサービスおよびインタフェースの使用を行い、完了する。このオペレーションは、図５に示すデータフロー（１７）、（１８）、（１９）を実装してよく、またはこれらに基づいていてよい。

従って、上述された図３から６の中で示されたデータフローおよびオペレーショナルシーケンスは、デバイスツークラウドツークラウドツーデバイス（Ｄ２Ｃ２Ｃ２Ｄ）アクセスモデルを提供していることが理解されよう。セキュリティモデルは、論理的にはデバイスツーデバイスであるホップバイホップおよびエンドツーエンドメッセージ保護機能の両方を可能にする。いくつかのＤ２Ｄ物理的接続が可能で、ドメインが物理的に同じ位置であってよい場合でさえ、インタラクションセマンティクスが、ドメインＡおよびＢによって定義されたように残るので、Ｄ２Ｃ２Ｃ２Ｄアプローチがセキュリティのために続けられる。

エッジコンピューティングインフラストラクチャは、クラウドサービスに共通するレイテンシの課題を克服するために設計されていることも理解されよう。エッジコンピューティングインフラストラクチャの使用によってでさえ、ここで説明されているＤ２Ｃ２Ｃ２Ｄアプローチは、ネットワークが物理的に同じ位置にあるときでさえ、依然として実行可能であり、リモートクラウドサービス特有のレイテンシは、エッジクラウドサービスから、低減されたレイテンシに置換され得る。

最終的に、上述されたクラウドツーローカルインタラクションの多くは、例えば全てのクラウドサービスがＯＣＦリソースとして表されるときに推定されることが理解されよう。これは、ローカルツークラウドインタラクションの多くが、従来のＯＣＦ発見およびインタラクションプロトコルを用いてサポートされてよいことを示唆している。

さらなる例では、上述の確立されたドメインは、産業用ＩｏＴネットワークを含むセッティングに適用可能であってよい。このようなネットワークは、多くの場合、マルチティアネットワーキングを有し、上述したそれぞれの「ドメイン」は、これらのティアの１つに関するものであってよい。同様に、ネットワークまたはデバイスのティアを含む例において、ドメインは、それぞれのティア内で確立されてよく、ここで、各ティアにおいて、適用されるポリシ制御またはデバイス特性は付加的なので、そのティアにとって適切なポリシが潜在的に存在する。

さらなる例において、ここで説明される実装は、複数のティアを含むスマートシティの使用を含め、スマートシティに適用されてよい。これらおよび他のセッティングにおいて、本明細書において説明される実装は、様々なエッジコンピューティング環境におけるエッジクラウド／エッジコンピューティング展開、ならびに有線および無線接続されたデバイスのためのマルチアクセスエッジコンピューティング（ＭＥＣ）配置の使用にも適用してよい。

図７は、自動クラウドツークラウド登録および検証技術を実装するためのデバイスおよび装置構成の図を示す。この図では、選択された構造的コンポーネント（プロセッサ、メモリ等）が、（第１リモートサービス７１０に関連付けられた）第１ＩｏＴデバイス７４０と（第２リモートサービス７２０に関連付けられた）第２ＩｏＴデバイス７５０との間で接続性を確立することの一部として、詳細に上述された様々なオペレーションを実装するために用いられる。ただし、さらにより多くのデバイス、システム、コンポーネント、および通信が、ＩｏＴデバイスの展開内で提供されてよいことが理解されよう。

第１ＩｏＴデバイス７４０は、本明細書において説明される構成およびオペレーションに基づいて、リモートサービスを介してデバイスツーデバイス通信を実行するように適合されるので、デバイス７４０は、通信回路７４２（例えば、ネットワークインタフェースカード）、プロセッサ回路７４４（例えば、１つまたは複数のプロセッサまたはプロセッサコア）、およびメモリもしくはストレージデバイス７４６（例えば、揮発性または不揮発性メモリアレイ）を含むものとして示されている。例において、通信回路７４２は、直接または通信ゲートウェイ７３０を介して第２ＩｏＴデバイス７５０との通信を実行し、直接または通信ゲートウェイ７３０を介して第１リモートサービス７１０との通信を実行するように構成される。

例において、メモリまたはストレージデバイス７４６は、そこで具現化される命令を含み、命令は、処理回路によって実行されたときに、リモートサービスを介してデバイスツーデバイス通信経路を構成および確立するためのオペレーションを実行するように処理回路を構成する。これらのオペレーションについてのさらなる詳細は、後述する図８のオペレーションで、または図３から６で詳細に示された他のデータフローで詳細に説明されている。これらのオペレーションは、デバイス７４０および７５０の間における発見および検証情報の交換と、サービス７１０とデバイス７４０との間におけるサービス通信情報の交換とを含むことが理解されよう。

第２ＩｏＴデバイス７５０は、第１ＩｏＴデバイス７４０および第２リモートサービス７２０とのインタラクションおよび通信に対応するオペレーションを実行するように適合されるので、デバイス７５０も、通信回路７５２、プロセッサ回路７５４、およびメモリまたはストレージデバイス７４６を含むものとして示されている。そのオペレーションについてのさらなる詳細も、後述する図８のオペレーションで、または図３から６で詳細に示された他のデータフローで詳細に説明されている。これらのオペレーションは、デバイス７４０および７５０の間における発見および検証情報、およびサービス７２０とデバイス７５０との間におけるサービス検証情報の交換を含むことが理解されよう。

第１リモートサービス７１０は、プロセッサ回路７１４およびメモリまたはストレージ７１６を有するサーバ７１２を含むものとして示され、第２リモートサービス７２０は、プロセッサ回路７２４およびメモリ／ストレージ７２６を有するサーバ７２２を含むものとして示されている。それぞれのプロセッサ回路およびメモリまたはストレージは、後述する図８のオペレーションで、または図３から６で詳細に示された他のデータフローで詳細に説明されるように、通信および認証情報を容易にするように各サーバ内で動作してよい。具体的には、サービス７１０、７２０間のデータ接続は、認証されたサービスツーサービス接続をセットアップし、その後データコマンドまたはデータ値をクラウドツークラウド方式で提供または通信するために、検証情報を交換するために用いられてよい。

通信ゲートウェイ７３０は、ローカルエリアネットワークとワイドエリアネットワークとの間のブリッジとして、デバイス７４０、７５０を含むローカルエリアネットワーク内に位置してよく、または、ワイドエリアネットワークにおいて、デバイス７４０、７５０とサービス７１０、７２０との間に位置してよい。例において、通信ゲートウェイ７３０は、通信（例えば、有線または無線通信）を実行する通信回路７３２と、通信または演算オペレーションを実行するための命令を実行するプロセッサ回路７３４とを含む。（図示されないメモリまたはストレージのような）他のコンポーネントが、デバイス７４０、７５０とサービス７１０、７２０との間の通信をフィルタリングまたは強化するために用いられてよい。通信ゲートウェイ７３０は、図８で詳細に後述するオペレーション、または図３から６で詳細に説明されたデータフローを実行またはアシストしてよい。

図８は、例に係る自動クラウドツークラウド登録および検証技術を実装するためのオペレーションのフローチャート８００を示す。これらのオペレーションは、第１デバイスの観点から説明されるが、他の観点が実装されてよいことが理解されよう。

フローチャート８００は、第２デバイスに関連付けられた第２リモートサービスと通信するために用いられる様々な情報を第２デバイスから取得するオペレーションで開始する（オペレーション８０５）。この情報は、ローカルエリアネットワーク上での第２デバイスの発見に応答して取得されてよい。例えば、第２デバイスから取得される情報は、デバイス間、クラウドサービス間、またはそれ以外の間で、相互に許可の認証および通信リンクセキュリティの確立を行うための情報を含んでよい。

フローチャート８００は、第１デバイスに関連付けられた第１リモートサービスに情報を通信するオペレーションに続く（オペレーション８１０）。例において、第１リモートサービスは、第１エンティティに関連付けられた第１クラウドネットワークにおいてホストされ、第２リモートサービスは、第２エンティティに関連付けられた第２クラウドネットワークにおいてホストされる。この構成では、第１デバイスは第１エンティティに関連付けられ、第２デバイスは第２エンティティに関連付けられている。例えば、第１デバイスは、第１エンティティによって製造され、またはその代理としてサービスされてよく、第２デバイスは、第２エンティティによって製造され、またはその代理としてサービスされてよい。また、例において、第１リモートサービスと共に実行される通信は、ワイドエリアネットワークを介して実行される。これらの通信は、少なくとも１つのトークン、または上述されたトークン情報を含んでよく、例えば、ここで、トークンは、承認サーバから取得された認証情報を提供するデータを含む。

フローチャート８００は、第２デバイスからサービス検証情報を取得するオペレーションに続く（オペレーション８１５）。この前に、例えば、第１リモートサービスが第２リモートサービスによる検証手順を開始したことに応答して、第２リモートサービスがサービス検証情報を第２デバイスに提供するシナリオにおいて、サービス検証情報は、第２リモートサービスから提供されている。したがって、サービス検証情報は、サービスツーサービス認証の第１フェーズの結果として提供されてよい。例において、このサービスツーサービス認証は、ディレクトリの使用を含んでよく、例えば、ここで、第１リモートサービスは、第２リモートサービスにアクセス可能なデバイスの第１ディレクトリを維持し、第２リモートサービスは、第１リモートサービスにアクセス可能なデバイスの第２ディレクトリを維持する。上述したシャドウイングデバイスの使用を含み得るこれらの例では、デバイスの第１ディレクトリは、第１デバイスに関連付けられたデータを提供してよく、デバイスの第２ディレクトリは、第２デバイスに関連付けられたデータを提供してよく、サービス検証情報は、次に、デバイスの第１および第２ディレクトリの一方または両方に基づいて提供される。

フローチャート８００は、次に、第１デバイスから第１リモートサービスにサービス検証情報を通信するオペレーションに続く（オペレーション８２０）。さらなる例において、この通信および第１デバイスから第１リモートサービスへの他の通信は少なくとも１つのトークンを含み、（例えば、図５で詳細に示されるように）このトークンは、承認サーバから取得された認証情報を提供するためのデータを含む。この情報に基づいて、検証済みサービスツーサービス接続（およびデバイスツークラウドサービスツークラウドサービスツーデバイス接続）が確立されてよい。

フローチャート８００は、検証済みサービスツーサービス接続を用いて、１つまたは複数のコマンドまたはデータを通信するオペレーションをもって終了する（オペレーション８２５）。例えば、コマンドの通信に応答して、コマンドは、第１リモートサービスと第２リモートサービスとの間の検証済み接続を用いて、第１リモートサービスから第２リモートサービスへ、第２リモートサービスから第２デバイスへ、さらに通信される。また、例えば、データ値の要求に応答して、要求は、第１リモートサービスから第２リモートサービスへ、第２リモートサービスから第２デバイスへさらに通信され、第１リモートサービスと第２リモートサービスとの間の検証済み接続を用いて、第２デバイスから第２リモートサービスに、かつ第１リモートサービスに戻される。

例において、第１リモートサービスは、データまたはコマンドを伴う様々な認証情報を第２リモートサービスに提供し、第１リモートサービスと第２リモートサービスとの間の検証済み接続は、認証情報の使用に基づいて確立される。この認証情報は、上述した図３および５で説明されたように提供されてよい。また、さらなる例において、様々な形のユーザ入力が、それぞれのＩｏＴデバイスで、またはそれぞれのＩｏＴデバイスを管理するユーザ機器で受信されてよい。したがって、第２デバイスでのユーザ入力に応答してサービス検証情報が第１デバイスに提供される様々なフローが行われてよい。他の自動化された発見および接続セットアップが行われてもよい。

様々な例において、上述された本発明の主題および特徴は、様々な方法、デバイス、およびシステムの実施形態によって具現化されてよい。第１の例として、実施形態は、図３から８を参照して説明された技術を用いて、クラウドツークラウドリソースディレクトリ（例えば、ディレクトリ５１０、５２０）においてインタラクションを実現またはデータを管理する方法、デバイス、システム、またはネットワークを含んでよい。このようなディレクトリは、データフローおよび上述したように交換される承認情報を用いて更新または管理されてよい。

第２の例として、実施形態は、図３から８を参照して説明された技術を用いてデバイスがクラウド対応（またはクラウド－リソース－ディレクトリ対応）のときのための処理機能を含むクラウドツーローカルリソースディレクトリインタラクションを実現する方法、デバイス、システム、またはネットワークを含んでよい。

第３の例として、実施形態は、図３から８を参照して説明された技術と組み合わせたＯＡｕｔｈまたはＯＡｕｔｈトークンの使用に基づいて、クラウドツークラウドインタラクションのＯＡｕｔｈ承認を実現する方法、デバイス、システム、またはネットワークを含んでよい。

第４の例として、実施形態は、図３から８を参照して説明された技術を用いて、（クラウドツーローカルインタラクションのために既に構成されたデバイスのための）ローカルネットワークを介してクラウドツークラウドインタラクションの可用性発見を実現する方法、デバイス、システム、またはネットワークを含んでよい。

第５の例として、実施形態は、図３から８を参照して説明された技術から提供されるクラウドツークラウドリソースディレクトリ、クラウドツークラウドインタラクション、またはクラウドツーローカルインタラクションアプローチのいずれかのアプリケーション、サービス、またはデータ構造のセットアップを実現し、これらを実行する方法、デバイス、システム、またはネットワークを含んでよい。

第６の例として、実施形態は、承認されたセキュアなクロスクラウドインタラクション（Ｄ２ＤまたはＤ２Ｃ２Ｃ２Ｄ）シナリオの、自動的な、ユーザにアシストされる、またはユーザによって構成されるプロビジョニングを実現する方法、デバイス、システム、またはネットワークを含んでよい。これらのシナリオは、図３から８を参照して説明された技術を用いて、既にセキュアなＤ２Ｄ構成を活用し、したがって、ユーザが関与するＯＡｕｔｈまたは同様の承認アプローチの必要性を回避する。

図９は、多数のモノのインターネット（ＩｏＴ）デバイスと通信しているクラウドコンピューティングネットワークまたはクラウド９００の図面を示す。クラウド９００は、インターネットを表してもよく、または企業のプロプライエタリネットワークのようなローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）であってもよい。ＩｏＴデバイスは、様々な組み合わせでグループ化された任意の数の異なるタイプのデバイスを含んでよい。例えば、交通制御グループ９０６は、都市の街路に沿ったＩｏＴデバイスを含んでよい。これらのＩｏＴデバイスは、停止信号、交通フローモニタ、カメラおよび気象センサ等を含んでよい。交通制御グループ９０６または他のサブグループは、例えばＬＰＷＡリンクおよび光リンク等の有線または無線のリンク９０８を通じてクラウド９００と通信していてよい。さらに、有線または無線のサブネットワーク９１２により、ＩｏＴデバイスが、例えば、ローカルエリアネットワークおよび無線ローカルエリアネットワーク等を通じて互いに通信することが可能であってよい。ＩｏＴデバイスは、ゲートウェイ９１０または９２８のような別のデバイスを用いて、クラウド９００のようなリモート位置と通信してよい。また、ＩｏＴデバイスは、１つまたは複数のサーバ９３０を用いて、クラウド９００またはゲートウェイ９１０との通信を容易にしてよい。例えば、１つまたは複数のサーバ９３０は、ローカルエリアネットワーク間のローカルエッジクラウドまたはフォグの実装をサポートするための中間ネットワークノードとして動作してよい。さらに、図示されているゲートウェイ９２８は、クラウドツーゲートウェイツーゲートウェイツー多くのエッジデバイスへという構成において、例えば、様々なＩｏＴデバイス９１４、９２０、９２４がクラウド９００内のリソースの割り当ておよび使用に対して制約されているかまたは動的である状態で、動作してよい。

ＩｏＴデバイスの他の例示的なグループは、幾多の中でもとりわけ、遠隔気象台９１４、ローカル情報端末９１６、アラームシステム９１８、現金自動預け払い機９２０、アラームパネル９２２、または緊急車両９２４もしくは他の車両９２６のような移動車両を含んでよい。これらのＩｏＴデバイスの各々は、他のＩｏＴデバイス、サーバ９０４、別のＩｏＴフォグプラットフォームもしくはシステム（不図示）、またはそれらの組み合わせと通信していてよい。ＩｏＴデバイスのグループは、様々な住宅、商業および産業用セッティング（プライベートな環境またはパブリックな環境の両方を含む）に展開されてよい。

図９から分かるように、多数のＩｏＴデバイスがクラウド９００を通じて通信していてよい。これにより、異なるＩｏＴデバイスが他のデバイスに対して自律的に情報を要求または提供することが可能になってよい。例えば、ＩｏＴデバイスのグループ（例えば、交通制御グループ９０６）は、人間が介入することなく予報を提供し得る遠隔気象台９１４のグループからの現在の天気予報を要求し得る。さらに、緊急車両９２４は、強盗が発生していると、現金自動預け払い機９２０によってアラートが出されてよい。緊急車両９２４は、現金自動預け払い機９２０へ向かっているとき、交通制御グループ９０６にアクセスして、その位置までのクリアランスを要求し得る。このクリアランスは、例えば、緊急車両９２４が妨げられずに交差点にアクセスするのに十分間に合う時間に交差点での交差交通を阻止するために、信号灯を赤に変えることによって行われる。

遠隔気象台９１４または交通制御グループ９０６のようなＩｏＴデバイスのクラスタは、他のＩｏＴデバイスとだけでなく、クラウド９００とも通信するように備えられてよい。これにより、ＩｏＴデバイスがデバイス間にアドホックネットワークを形成することが可能になり、これらが、フォグプラットフォームまたはシステムと称され得る単一デバイスとして機能することが可能になり得る。

図１０は、本明細書において説明する技術を実装するためにＩｏＴデバイス１０５０内に存在し得るコンポーネントの例のブロック図である。ＩｏＴデバイス１０５０は、この例に示されているか、または上記の開示において言及されているコンポーネントの任意の組み合わせを含んでよい。コンポーネントは、ＩＣ、その一部、ディスクリート電子デバイス、もしくは他のモジュール、ロジック、ハードウェア、ソフトウェア、ファームウェア、またはＩｏＴデバイス１０５０内で適合させられたそれらの組み合わせとして、または、より大きいシステムのシャーシ内に別の方法で組み込まれるコンポーネントとして実装されてよい。さらに、図１０のブロック図は、ＩｏＴデバイス１０５０のコンポーネントの高レベル図を示すよう意図されている。ただし、他の実装では、示されているコンポーネントのうちのいくつかが省略されてよく、さらなるコンポーネントが存在してよく、示されているコンポーネントの異なる配置が行われてよい。

ＩｏＴデバイス１０５０は、プロセッサ１０５２の形で処理回路を含んでよい。プロセッサ１０５２は、マイクロプロセッサ、マルチコアプロセッサ、マルチスレッドプロセッサ、超低電圧プロセッサ、埋め込みプロセッサまたは他の公知の処理要素であってよい。プロセッサ１０５２は、プロセッサ１０５２および他のコンポーネントが、単一の集積回路内に、またはＩｎｔｅｌ（登録商標）からのＥｄｉｓｏｎ（商標）またはＧａｌｉｌｅｏ（商標）ＳｏＣ基板のような単一のパッケージ内に形成されるシステムオンチップ（ＳｏＣ）の一部であってよい。例として、プロセッサ１０５２は、Ｉｎｔｅｌ（登録商標）Ａｒｃｈｉｔｅｃｔｕｒｅ Ｃｏｒｅ（商標）ベースのプロセッサ、例えば、Ｑｕａｒｋ（商標）、Ａｔｏｍ（商標）、Ｘｅｏｎ（商標）、ｉ３、ｉ５、ｉ７、ｉ９、もしくはＭＣＵクラスのプロセッサ、または、カリフォルニア州サンタクララのＩｎｔｅｌ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎから入手可能な別のこのようなプロセッサを含んでよい。ただし、カリフォルニア州サニーベールのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ， Ｉｎｃ．（ＡＭＤ）から入手可能なもの、カリフォルニア州サニーベールのＭＩＰＳ Ｔｅｃｈｎｏｌｏｇｉｅｓ， Ｉｎｃ．からのＭＩＰＳベースの設計、ＡＲＭ Ｈｏｌｄｉｎｇｓ， Ｌｔｄ．またはその顧客、またはこれらの被ライセンス者または採用者からライセンスされたＡＲＭベースの設計のような、任意の数の他のプロセッサが用いられてよい。これらのプロセッサは、Ａｐｐｌｅ（登録商標）Ｉｎｃ．からのＡ５－Ａ１２プロセッサ、Ｑｕａｌｃｏｍｍ（登録商標）Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．からのＳｎａｐｄｒａｇｏｎ（商標）プロセッサ、またはＴｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ， Ｉｎｃ．からのＯＭＡＰ（商標）プロセッサのようなユニットを含んでよい。従って、様々な例において、適用可能な処理手段が、このような処理回路によって具現化されてよい。

プロセッサ１０５２は、相互接続１０５６（例えば、バス）を介してシステムメモリ１０５４と通信してよい。任意の数のメモリデバイスが、所与の量のシステムメモリを提供するために用いられてよい。例として、メモリは、ＤＤＲまたはモバイルＤＤＲ規格（例えば、ＬＰＤＤＲ、ＬＰＤＤＲ２、ＬＰＤＤＲ３またはＬＰＤＤＲ４）のような電子機器技術評議会（ＪＥＤＥＣ）の設計に従ったランダムアクセスメモリ（ＲＡＭ）であってよい。様々な実装において、個々のメモリデバイスは、シングルダイパッケージ（ＳＤＰ）、デュアルダイパッケージ（ＤＤＰ）またはクワッドダイパッケージ（Ｑ１７Ｐ）のような、任意の数の異なるパッケージタイプのものであってよい。いくつかの例では、これらのデバイスをマザーボード上へ直接はんだ付けしてより低いプロファイルの解決手段を提供し得るが、他の例では、デバイスは、結果として所与のコネクタによりマザーボードに結合する１つまたは複数のメモリモジュールとして構成される。他のタイプのメモリモジュール、例えば、限定されないが、ｍｉｃｒｏＤＩＭＭまたはＭｉｎｉＤＩＭＭを含む、異なる種類のデュアルインラインメモリモジュール（ＤＩＭＭ）のような、任意の数の他のメモリ実装が用いられてよい。

データ、アプリケーションおよびオペレーティングシステム等のような、情報の永続的なストレージを提供するために、ストレージ１０５８は、相互接続１０５６を介してプロセッサ１０５２に結合してもよい。例において、ストレージ１０５８は、ソリッドステートディスクドライブ（ＳＳＤＤ）を介して実装されてよい。ストレージ１０５８のために用いられ得る他のデバイスは、ＳＤカード、ｍｉｃｒｏＳＤカードおよびｘＤピクチャカード等のようなフラッシュメモリカードと、ＵＳＢフラッシュドライブとを含む。低電力の実装では、ストレージ１０５８は、プロセッサ１０５２に関連付けられたオンダイメモリまたはレジスタであってよい。ただし、いくつかの例では、ストレージ１０５８は、マイクロハードディスクドライブ（ＨＤＤ）を用いて実装されてよい。さらに、とりわけ、抵抗変化メモリ、相変化メモリ、ホログラフィックメモリまたは化学メモリのような説明する技術に加えて、またはそれらの代わりに、任意の数の新たな技術がストレージ１０５８に用いられてよい。従って、様々な例において、適用可能なストレージのための手段が、このような記憶媒体によって具現化されてよい。

これらのコンポーネントは、相互接続１０５６を介して通信してよい。相互接続１０５６は、業界標準アーキテクチャ（ＩＳＡ）、拡張ＩＳＡ（ＥＩＳＡ）、周辺コンポーネント相互接続（ＰＣＩ）、周辺コンポーネント相互接続拡張（ＰＣＩｘ）、ＰＣＩエクスプレス（ＰＣＩｅ）を含む任意の数の他の技術、または任意の数の技術を含んでよい。相互接続１０５６は、例えば、ＳｏＣベースのシステムにおいて用いられるプロプライエタリバスであってよい。とりわけ、Ｉ２Ｃインタフェース、ＳＰＩインタフェース、ポイントツーポイントインタフェースおよび電力バスのような他のバスシステムが含まれてよい。

相互接続１０５６は、他のメッシュデバイス１０６４との通信のために、プロセッサ１０５２をメッシュトランシーバ１０６２に結合させてよい。メッシュトランシーバ１０６２は、とりわけ、Ｂｌｕｅｔｏｏｔｈ（登録商標）Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐにより定義されているＢｌｕｅｔｏｏｔｈ（登録商標）Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）規格またはＺｉｇｂｅｅ（登録商標）規格を用いた、ＩＥＥＥ８０２．１５．４規格に基づく２．４ギガヘルツ（ＧＨｚ）伝送のような、任意の数の周波数およびプロトコルを用いてよい。特定の無線通信プロトコル用に構成された任意の数の無線機が、メッシュデバイス１０６４への接続のために用いられてよい。例えば、ＷＬＡＮユニットが、米国電気電子技術者協会（ＩＥＥＥ）８０２．１１規格に従ってＷｉ－Ｆｉ（登録商標）通信を実装するために用いられてよい。さらに、例えば、セルラまたは他の無線ワイドエリアプロトコルによる無線ワイドエリア通信が、ＷＷＡＮユニットを介して行われてよい。

メッシュトランシーバ１０６２は、異なる範囲での通信のために、複数の規格または無線を用いて通信してよい。例えば、ＩｏＴデバイス１０５０は、ＢＬＥまたは別の低電力無線に基づいてローカルトランシーバを用いて、例えば、約１０メートル以内の近接デバイスと通信することで、電力を節約してよい。例えば、約５０メートル以内の、より遠いメッシュデバイス１０６４が、Ｚｉｇｂｅｅまたは他の中間電力無線機を介して到達されてよい。両方の通信技術は、異なる電力レベルで単一の無線を介して行われてもよく、または、例えば、ＢＬＥを用いるローカルトランシーバなどの別個のトランシーバと、Ｚｉｇｂｅｅを用いる別個のメッシュトランシーバとを介して行われてもよい。

ローカルエリアネットワークプロトコルまたはワイドエリアネットワークプロトコルを介してクラウド１０００内のデバイスまたはサービスと通信するために、無線ネットワークトランシーバ１０６６が含まれてよい。無線ネットワークトランシーバ１０６６は、とりわけ、ＩＥＥＥ８０２．１５．４規格またはＩＥＥＥ８０２．１５．４ｇ規格に従ったＬＰＷＡトランシーバであってよい。ＩｏＴデバイス１０５０は、ＳｅｍｔｅｃｈおよびＬｏＲａ Ａｌｌｉａｎｃｅにより開発されたＬｏＲａＷＡＮ（商標）（長距離ワイドエリアネットワーク）を用いて、広域にわたって通信してよい。本明細書において説明する技術は、これらの技術に限定されないが、Ｓｉｇｆｏｘのような長距離低帯域幅通信を実装する任意の数の他のクラウドトランシーバ、および他の技術と共に用いられてよい。さらに、ＩＥＥＥ８０２．１５．４ｅ仕様において説明されるタイムスロットチャネルホッピングのような他の通信技術が用いられてよい。

本明細書において説明するように、メッシュトランシーバ１０６２および無線ネットワークトランシーバ１０６６について言及されたシステムに加え、任意の数の他の無線通信およびプロトコルが用いられてよい。例えば、無線トランシーバ１０６２および１０６６は、高速通信を実装するためにスペクトル拡散（ＳＰＡ／ＳＡＳ）通信を用いるＬＴＥまたは他のセルラトランシーバを含んでよい。さらに、ネットワーク通信のプロビジョニングおよび中速通信のためのＷｉ－Ｆｉ（登録商標）ネットワークのような、任意の数の他のプロトコルが用いられてよい。

無線トランシーバ１０６２および１０６６は、任意の数の３ＧＰＰ（第３世代パートナシッププロジェクト）仕様、特に、ロングタームエボリューション（ＬＴＥ）、ロングタームエボリューションアドバンスト（ＬＴＥ－Ａ）およびロングタームエボリューションアドバンストプロ（ＬＴＥ－Ａ Ｐｒｏ）と互換性がある無線機を含んでよい。なお、任意の数の他の固定通信、モバイル通信または衛星通信の技術および規格と互換性がある無線機が選択されてよい。これらは、例えば、任意のセルラ広域無線通信技術を含み得る。セルラ広域無線通信技術は、例えば、第５世代（５Ｇ）通信システム、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ（登録商標））無線通信技術、汎用パケット無線サービス（ＧＰＲＳ）無線通信技術、またはＧＳＭ進化型高速データレート（ＥＤＧＥ）無線通信技術、ＵＭＴＳ（ユニバーサル移動体通信システム）通信技術を含み得る。上に列挙した規格に加え、例えば、とりわけ、ＩＴＵ（国際電気通信連合）またはＥＴＳＩ（欧州電気通信標準化機構）により発行される規格に準拠する無線機を含む無線ネットワークトランシーバ１０６６のために、任意の数の衛星アップリンク技術が用いられてよい。したがって、本明細書において提供される例は、既存のものおよびまだ定式化されていないものの両方を含む、様々な他の通信技術に適用可能であると理解される。

クラウド１０００、またはメッシュデバイス１０６４のような他のデバイスに有線通信を提供するために、ネットワークインタフェースコントローラ（ＮＩＣ）１０６８が含まれてよい。有線通信は、Ｅｔｈｅｒｎｅｔ（登録商標）接続を提供してもよく、または、幾多の中でもとりわけ、コントローラエリアネットワーク（ＣＡＮ）、ローカル相互接続ネットワーク（ＬＩＮ）、ＤｅｖｉｃｅＮｅｔ、ＣｏｎｔｒｏｌＮｅｔ、Ｄａｔａ Ｈｉｇｈｗａｙ＋、ＰＲＯＦＩＢＵＳまたはＰＲＯＦＩＮＥＴのような他のタイプのネットワークに基づいていてもよい。第２のネットワーク、例えば、Ｅｔｈｅｒｎｅｔを介してクラウドに通信を提供するＮＩＣ１０６８、および別のタイプのネットワークを介して他のデバイスに通信を提供する第２のＮＩＣ１０６８への接続を可能にするために、さらなるＮＩＣ１０６８が含まれてよい。

デバイスから別のコンポーネントまたはネットワークへ、様々なタイプの適用可能な通信があるとすると、デバイスによって用いられる適用可能な通信回路は、コンポーネント１０６２、１０６６、１０６８または１０７０のいずれか１つまたは複数を含んでよく、またはこれらによって具現化されてよい。従って、様々な例において、適用可能な通信（例えば、受信、伝送等）のための手段は、このような通信回路によって具現化されてよい。

相互接続１０５６は、外部デバイスまたはサブシステムに接続するために用いられる外部インタフェース１０７０にプロセッサ１０５２を結合してよい。外部デバイスは、加速度計、レベルセンサ、流量センサ、光学光センサ、カメラセンサ、温度センサ、全地球測位システム（ＧＰＳ）センサ、圧力センサおよび気圧センサ等のようなセンサ１０７２を含んでよい。外部インタフェース１０７０はさらに、電力スイッチ、バルブアクチュエータ、可聴音生成器、視覚警告デバイス等のようなアクチュエータ１０７４にＩｏＴデバイス１０５０を接続するために用いられてよい。

いくつかのオプションの例では、様々な入力／出力（Ｉ／Ｏ）デバイスが、ＩｏＴデバイス１０５０内に存在してよい、または接続されてよい。例えば、センサの読み取り値またはアクチュエータの位置のような情報を示すために、ディスプレイまたは他の出力デバイス１０８４が含まれてよい。入力を受け付けるために、タッチスクリーンまたはキーパッドのような入力デバイス１０８６が含まれてよい。出力デバイス１０８４は、任意の数の形態のオーディオまたはビジュアルディスプレイを含み得る。これらのディスプレイは、バイナリステータスインジケータ（例えば、ＬＥＤ）およびマルチ文字ビジュアル出力のような単純なビジュアル出力、またはディスプレイ画面（例えば、ＬＣＤ画面）のようなより複雑な出力を含み、文字、グラフィックス、マルチメディアオブジェクト等の出力は、ＩｏＴデバイス１０５０のオペレーションから生成されるか、または生じる。

バッテリ１０７６は、ＩｏＴデバイス１０５０に電力を供給し得るが、ＩｏＴデバイス１０５０が固定位置に装着されている例では、電力系統に結合された電源を有してよい。バッテリ１０７６は、リチウムイオンバッテリ、または、例えば、亜鉛－空気バッテリ、アルミニウム－空気バッテリおよびリチウム－空気バッテリ等の金属－空気バッテリであってよい。

ＩｏＴデバイス１０５０には、バッテリ１０７６の充電状態（ＳｏＣｈ）を追跡するために、バッテリモニタ／充電器１０７８が含まれてよい。バッテリモニタ／充電器１０７８は、バッテリ１０７６の健全度（ＳｏＨ）および機能状態（ＳｏＦ）のようなバッテリ１０７６の他のパラメータを監視して、故障予測を提供するために用いられてよい。バッテリモニタ／充電器１０７８は、Ｌｉｎｅａｒ ＴｅｃｈｎｏｌｏｇｉｅｓからのＬＴＣ４０２０もしくはＬＴＣ２９９０、アリゾナ州フェニックスからのＯＮ ＳｅｍｉｃｏｎｄｕｃｔｏｒからのＡＤＴ７４８８Ａまたはテキサス州ダラスのＴｅｘａｓ ＩｎｓｔｒｕｍｅｎｔｓからのＵＣＤ９０ｘｘｘファミリのＩＣのようなバッテリ監視集積回路を含んでよい。バッテリモニタ／充電器１０７８は、相互接続１０５６を介して、バッテリ１０７６に関する情報をプロセッサ１０５２に通信してよい。バッテリモニタ／充電器１０７８は、プロセッサ１０５２がバッテリ１０７６の電圧またはバッテリ１０７６からの電流を直接監視することを可能にするアナログ－デジタル（ＡＤＣ）コンバータも含んでよい。バッテリのパラメータは、伝送周波数、メッシュネットワークオペレーションおよびセンシング周波数等のような、ＩｏＴデバイス１０５０が実行し得る動作を決定するために用いられてよい。

バッテリ１０７６を充電するために、電力ブロック１０８０、または電力系統に結合された他の電源が、バッテリモニタ／充電器１０７８と結合されてよい。いくつかの例では、電力ブロック１０８０を無線電力レシーバに置換することで、無線で、例えば、ＩｏＴデバイス１０５０内のループアンテナを通じて、電力を取得してよい。バッテリモニタ／充電器１０７８には、とりわけ、カリフォルニア州ミルピタスのＬｉｎｅａｒ ＴｅｃｈｎｏｌｏｇｉｅｓからのＬＴＣ４０２０チップ例えば無線バッテリ充電回路が含まれてよい。選ばれる特定の充電回路は、バッテリ１０７６のサイズ、およびしたがって、必要とされる電流に依存する。充電は、とりわけ、Ａｉｒｆｕｅｌ Ａｌｌｉａｎｃｅにより公表されるＡｉｒｆｕｅｌ規格、ワイヤレスパワーコンソーシアムにより公表されるＱｉ無線充電規格またはＡｌｌｉａｎｃｅ ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｐｏｗｅｒにより公表されるＲｅｚｅｎｃｅ充電規格を用いて実行されてよい。

ストレージ１０５８は、本明細書において説明する技術を実装するためのソフトウェア、ファームウェアまたはハードウェアコマンドの形で命令１０８２を含んでよい。このような命令１０８２がメモリ１０５４およびストレージ１０５８に含まれるコードブロックとして示されているが、コードブロックのいずれも、例えば、特定用途向け集積回路（ＡＳＩＣ）に組み込まれたハードワイヤード回路に置換され得ることが理解されよう。

例において、メモリ１０５４、ストレージ１０５８またはプロセッサ１０５２を介して提供される命令１０８２は、ＩｏＴデバイス１０５０内の電子的オペレーションを実行するようプロセッサ１０５２に指示するためのコードを含む非一時的機械可読媒体１０６０として具現化されてよい。プロセッサ１０５２は、相互接続１０５６を介して非一時的機械可読媒体１０６０にアクセスしてよい。例えば、非一時的機械可読媒体１０６０は、図１０のストレージ１０５８について説明されているデバイスにより具現化されてよく、または、光ディスク、フラッシュドライブまたは任意の数の他のハードウェアデバイスのような特定のストレージユニットを含んでもよい。非一時的機械可読媒体１０６０は、例えば、上で示されたオペレーションおよび機能のフローチャートおよびブロック図に関して説明したとおり、動作の特定のシーケンスまたはフローを実行するようプロセッサ１０５２に指示するための命令を含んでよい。

さらなる具体例において、プロセッサ１０５２上の命令１０８８は、（別個に、または機械可読媒体１０６０の命令１０８８との組み合わせで）信頼された実行環境（ＴＥＥ）１０９０の実行またはオペレーションを構成してよい。例において、ＴＥＥ１０９０は、命令のセキュアな実行およびデータへのセキュアなアクセスのために、プロセッサ１０５２にアクセス可能な保護エリアとして動作する。ＴＥＥ１０９０の様々な実装、およびプロセッサ１０５２またはメモリ１０５４における付随するセキュアなエリアは、例えば、Ｉｎｔｅｌ（登録商標） Ｓｏｆｔｗａｒｅ Ｇｕａｒｄ Ｅｘｔｅｎｓｉｏｎｓ（ＳＧＸ）またはＡＲＭ（登録商標）、ＴｒｕｓｔＺｏｎｅ（登録商標）ハードウェアセキュリティ拡張、Ｉｎｔｅｌ（登録商標）Ｍａｎａｇｅｍｅｎｔ Ｅｎｇｉｎｅ（ＭＥ）、またはＩｎｔｅｌ（登録商標）Ｃｏｎｖｅｒｇｅｄ Ｓｅｃｕｒｉｔｙ Ｍａｎａｇｅａｂｉｌｉｔｙ Ｅｎｇｉｎｅ （ＣＳＭＥ）の使用を通じて提供されてよい。セキュリティ強化、ハードウェアの信頼の基点、信頼または保護されたオペレーションの他の態様が、ＴＥＥ１０９０およびプロセッサ１０５２によりデバイス１０５０において実装されてよい。

さらなる例において、機械可読媒体は、機械により実行される命令を格納、符号化または保持可能で、本開示の方法論のうちのいずれか１つまたは複数を機械に実行させ、または、このような命令に利用されるかまたは関連付けられるデータ構造を格納、符号化または保持可能な任意の有形の媒体をも含む。したがって、「機械可読媒体」は、限定されないが、ソリッドステートメモリならびに光および磁気メディアを含んでよい。機械可読媒体の具体例は、限定されないが、半導体メモリデバイス（例えば、電気的プログラマブルリードオンリメモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ））およびフラッシュメモリデバイスを含む不揮発性メモリと、内蔵ハードディスクおよびリムーバブルディスクのような磁気ディスクと、光磁気ディスクと、ＣＤ－ＲＯＭディスクおよびＤＶＤ－ＲＯＭディスクとを例として含む。機械可読媒体により具現化される命令は、多数の転送プロトコル（例えば、ＨＴＴＰ）のうちのいずれか１つを利用するネットワークインタフェースデバイスを介した伝送媒体を用いて、通信ネットワークを介してさらに伝送または受信されてよい。

本明細書において説明する機能ユニットまたは機能は、それらの実装の独立性をより具体的に強調すべく、コンポーネントまたはモジュールと称されているか、またはそのように符号が付されている可能性があることを理解されたい。このようなコンポーネントは、任意の数のソフトウェアまたはハードウェアの形により具現化されてよい。例えば、コンポーネントまたはモジュールは、カスタムの超大規模集積（ＶＬＳＩ）回路もしくはゲートアレイ、ロジックチップのような既製の半導体トランジスタまたは他のディスクリートコンポーネントを備えるハードウェア回路として実装されてよい。コンポーネントまたはモジュールは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジックまたはプログラマブルロジックデバイス等のようなプログラマブルハードウェアデバイスに実装されてもよい。コンポーネントまたはモジュールは、様々なタイプのプロセッサによる実行のために、ソフトウェアで実装されてもよい。実行可能コードの識別されたコンポーネントまたはモジュールは、例えば、コンピュータ命令の１つまたは複数の物理的またはロジカルブロックを含んでよく、これは、例えば、オブジェクト、手順、または機能として体系化されてよい。それにもかかわらず、識別されたコンポーネントまたはモジュールの実行ファイルは、物理的に一緒に位置している必要はないが、論理的に一緒に連結されているときは、コンポーネントまたはモジュールを含み、かつ、コンポーネントまたはモジュールの記述された目的を実現する、異なる位置に格納された全く異なる命令を含んでよい。

実際には、実行可能コードのコンポーネントまたはモジュールは、単一の命令または多くの命令であってよく、さらには、いくつかの異なるコードセグメントを介して、異なるプログラムの間で、かつ、いくつかのメモリデバイスまたは処理システムにわたって分散されていてよい。特に、（コードのリライトおよびコードの解析のような）説明されている処理のいくつかの態様は、コードが展開されている処理システム（例えば、センサまたはロボットに埋め込まれたコンピュータ）とは異なる処理システムで（例えば、データセンタ内のコンピュータ内で）行われてよい。同様に、処理データは、本明細書ではコンポーネントまたはモジュール内で特定および図示されてよく、任意の適切な形態で具現化され、任意の適切なタイプのデータ構造内で体系化されてよい。処理データは、単一のデータセットとして収集されてよく、または、異なるストレージデバイスにわたっていることを含め、異なる位置にわたって分散されてよく、少なくとも部分的に、単にシステムまたはネットワーク上の電子信号として存在してよい。コンポーネントまたはモジュールは、所望の機能を実行するように動作可能なエージェントを含み、受動的または能動的であってよい。

ここで説明する方法、システムおよびデバイスの実施形態のさらなる例は、以下の非限定的な構成を含む。以下の非限定的な例の各々は、独立したものであってもよく、または、以下にまたは本開示の全体を通じて提供される他の例ののうちのいずれか１つまたは複数と任意の並べ替えまたは組み合わせで組み合わせられてもよい。

例１は、処理回路と、第２デバイスとの通信を実行し、デバイスに関連付けられた第１リモートサービスとの通信を実行するように構成される通信回路と、そこで具現化される命令を含むメモリデバイスとを備えるデバイスであって、命令は、処理回路によって実行されたときに、第２デバイスに関連付けられた第２リモートサービスと通信するために、第２デバイスから情報を取得するオペレーションと、デバイスから第１リモートサービスに情報を提供するオペレーションであって、情報に応答して、第１リモートサービスが第２リモートサービスとの検証手順を開始する、オペレーションと、第２デバイスからサービス検証情報を取得するオペレーションであって、サービス検証情報は、第１リモートサービスが第２リモートサービスとの検証手順を開始したことに応答して、第２リモートサービスから第２デバイスに提供される、オペレーションと、デバイスから第１リモートサービスにサービス検証情報を提供するオペレーションであって、サービス検証情報は、第１リモートサービスによって、第１リモートサービスと第２リモートサービスとの間の検証済み接続を実現するために用いられ、検証済み接続は、第１および第２リモートサービスを介してデバイスと第２デバイスとの間でデータまたはコマンドを通信するために確立される、オペレーションとを実行するように処理回路を構成するデバイスである。

例２において、例１の主題は、任意選択的に、デバイスから第１リモートサービスにコマンドを通信することによって、第１リモートサービスおよび第２リモートサービスを介して、デバイスから第２デバイスにコマンドを提供するオペレーションであって、コマンドを通信することに応答して、第１リモートサービスと第２リモートサービスとの間の検証済み接続を用いて、コマンドは、第１リモートサービスから第２リモートサービスへ、第２リモートサービスから第２デバイスへ、さらに通信される、オペレーションを実行するように処理回路をさらに構成する命令を含む。

例３において、例１－２のいずれか１つまたは複数の主題は、任意選択的に、ＩｏＴデバイスから第１リモートサービスへのデータ値の要求を通信することによって、第１リモートサービスおよび第２リモートサービスを介して、第２デバイスからデータ値を取得するオペレーションであって、データ値の要求に応答して、要求は、第１リモートサービスと第２リモートサービスとの間の検証済み接続を用いて、第１リモートサービスから第２リモートサービスに、および第２リモートサービスから第２デバイスにさらに通信され、第２デバイスから第２リモートサービスおよび第１リモートサービスに戻される、オペレーションを含む。

例４において、例１－３のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスは、第１エンティティに関連付けられた第１クラウドネットワークでホストされ、第２リモートサービスは、第２エンティティに関連付けられた第２クラウドネットワークでホストされ、デバイスは、第１エンティティに関連付けられており、第２デバイスは、第２エンティティに関連付けられている主題を含む。

例５において、例４の主題は、任意選択的に、デバイスは、第１エンティティによって製造され、またはその代理としてサービスされており、第２デバイスは、第２エンティティによって製造され、またはその代理としてサービスされている主題を含む。

例６において、例１－５のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスは、第２リモートサービスへのデータまたはコマンドを伴う認証情報をさらに提供し、第１リモートサービスと第２リモートサービスとの間の検証済み接続は、認証情報の使用に基づいて確立される主題を含む。

例７において、例１－６のいずれか１つまたは複数の主題は、任意選択的に、情報は、デバイスで受信されたユーザ入力に応答して第１リモートサービスに提供され、サービス検証情報は、第２デバイスでのユーザ入力に応答してデバイスに提供される主題を含む。

例８において、例１－７のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスは、第２リモートサービスにアクセス可能なデバイスの第１ディレクトリを維持し、デバイスの第１ディレクトリは、デバイスに関連付けられたデータを含み、第２リモートサービスは、第１リモートサービスにアクセス可能なデバイスの第２ディレクトリを維持し、デバイスの第２ディレクトリは、第２デバイスに関連付けられたデータを含み、サービス検証情報は、デバイスの第１および第２ディレクトリの少なくとも１つに基づいて提供される主題を含む。

例９において、例１－８のいずれか１つまたは複数の主題は、任意選択的に、デバイスから第１リモートサービスへの通信は少なくとも１つのトークンを含み、少なくとも１つのトークンは、承認サーバから取得された認証情報を提供するデータを含む主題を含む。

例１０において、例１－９のいずれか１つまたは複数の主題は、任意選択的に、第２デバイスと共に実行される通信はローカルエリアネットワークを介して実行され、第１リモートサービスと共に実行される通信は、ワイドエリアネットワークを介して実行される主題を含む。

例１１において、例１０の主題は、任意選択的に、第２リモートサービスと通信するために、第２デバイスから情報を取得するためのオペレーションは、ローカルエリアネットワーク上での第２デバイスの発見に応答して実行され、第２デバイスから取得される情報は、許可を相互に認証し、通信リンクのセキュリティを確立するための情報を含む主題を含む。

例１２において、例１－１１のいずれか１つまたは複数の主題は、任意選択的に、デバイスおよび第２デバイスは、Ｏｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ（ＯＣＦ）仕様に従って定義される規格に従って通信し、オペレーションによって実行される通信は、それぞれのデバイスおよびサービス間の非同期メッセージに従って行われる主題を含む。

例１３は、モノのインターネット（ＩｏＴ）デバイス展開において通信を確立するための方法であって、ＩｏＴデバイスの処理回路によって実行されるオペレーションを備え、オペレーションは、第２ＩｏＴデバイスに関連付けられた第２リモートサービスと通信するために、第２ＩｏＴデバイスから情報を取得することと、情報を第１リモートサービスに提供することであって、情報に応答して、第１リモートサービスは第２リモートサービスと検証手順を開始する、提供することと、第２ＩｏＴデバイスからサービス検証情報を取得することであって、サービス検証情報は、検証手順に応答して、第２リモートサービスから第２ＩｏＴデバイスに提供される、取得することと、ＩｏＴデバイスと第２ＩｏＴデバイスとの間で、第１および第２リモートサービスを介してデータまたはコマンドを通信するために、第１リモートサービスと第２リモートサービスとの間の検証済み接続を可能にするために、サービス検証情報を第１リモートサービスに提供することとを含む方法である。

例１４において、例１３の主題は、任意選択的に、ＩｏＴデバイスから第１リモートサービスにコマンドを通信することによって、Ｉ第１リモートサービスおよび第２リモートサービスを介して、ＩｏＴデバイスから第２ＩｏＴデバイスにコマンドを提供することであって、コマンドの通信に応答して、コマンドは、第１リモートサービスと第２リモートサービスとの間の検証済み接続を用いて、第１リモートサービスから第２リモートサービスに、および第２リモートサービスから第２ＩｏＴデバイスにさらに通信される、提供することを含む。

例１５において、例１３－１４のいずれか１つまたは複数の主題は、任意選択的に、ＩｏＴデバイスから第１リモートサービスへのデータ値の要求を通信することによって、第１リモートサービスおよび第２リモートサービスを介して、第２ＩｏＴデバイスからデータ値を取得することであって、データ値の要求に応答して、要求は、第１リモートサービスと第２リモートサービスとの間の検証済み接続を用いて、第１リモートサービスから第２リモートサービスに、および第２リモートサービスから第２ＩｏＴデバイスにさらに通信され、第２ＩｏＴデバイスから第２リモートサービスおよび第１リモートサービスに戻される、取得することを含む。

例１６において、例１３－１５のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスは、第１エンティティに関連付けられた第１クラウドネットワークでホストされ、第２リモートサービスは、第２エンティティに関連付けられた第２クラウドネットワークでホストされ、ＩｏＴデバイスは、第１エンティティに関連付けられており、第２ＩｏＴデバイスは、第２エンティティに関連付けられている主題を含む。

例１７において、例１６の主題は、任意選択的に、ＩｏＴデバイスは、第１エンティティによって製造され、またはその代理としてサービスされており、第２ＩｏＴデバイスは、第２エンティティによって製造され、またはその代理としてサービスされている主題を含む。

例１８において、例１３－１７のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスは、第２リモートサービスへのデータまたはコマンドを伴う認証情報をさらに提供し、第１リモートサービスと第２リモートサービスとの間の検証済み接続は、認証情報の使用に基づいて確立される主題を含む。

例１９において、例１３－１８のいずれか１つまたは複数の主題は、任意選択的に、情報は、ＩｏＴデバイスで受信されたユーザ入力に応答して第１リモートサービスに提供され、サービス検証情報は、第２ＩｏＴデバイスでのユーザ入力に応答してＩｏＴデバイスに提供される主題を含む。

例２０において、例１３－１９のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスは、第２リモートサービスにアクセス可能なデバイスの第１ディレクトリを維持し、デバイスの第１ディレクトリは、ＩｏＴデバイスに関連付けられたデータを含み、第２リモートサービスは、第１リモートサービスにアクセス可能なデバイスの第２ディレクトリを維持し、デバイスの第２ディレクトリは、第２ＩｏＴデバイスに関連付けられたデータを含み、サービス検証情報は、デバイスの第１および第２ディレクトリの少なくとも１つに基づいて提供される主題を含む。

例２１において、例１３－２０のいずれか１つまたは複数の主題は、任意選択的に、ＩｏＴデバイスから第１リモートサービスへの通信は少なくとも１つのトークンを含み、少なくとも１つのトークンは、承認サーバから取得された認証情報を提供するデータを含む主題を含む。

例２２において、例１３－２１のいずれか１つまたは複数の主題は、任意選択的に、第２ＩｏＴデバイスと共に実行される通信はローカルエリアネットワークを介して実行され、第１リモートサービスと共に実行される通信は、ワイドエリアネットワークを介して実行される主題を含む。

例２３において、例２２の主題は、任意選択的に、第２リモートサービスと通信するために、第２ＩｏＴデバイスから情報を取得するためのオペレーションは、ローカルエリアネットワーク上での第２ＩｏＴデバイスの発見に応答して実行され、第２ＩｏＴデバイスから取得される情報は、許可を相互に認証し、通信リンクのセキュリティを確立するための情報を含む主題を含む。

例２４において、例１３－２３のいずれか１つまたは複数の主題は、任意選択的に、ＩｏＴデバイスおよび第２ＩｏＴデバイスは、Ｏｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ（ＯＣＦ）仕様に従って定義される規格に従って通信し、オペレーションによって実行される通信は、それぞれのデバイスおよびサービス間の非同期メッセージに従って行われる主題を含む。

例２５は、格納された命令を備える少なくとも１つの機械可読ストレージデバイスであって、命令は、装置の処理回路によって実行されたときに、例１３から２４に記載のオペレーションのいずれかを処理回路に実行させる、機械可読ストレージデバイス。

例２６は、システムであって、処理回路と、通信回路と、少なくとも１つのメモリデバイスとを含む第１モノのインターネット（ＩｏＴ）デバイスを備え、処理回路は、第２ＩｏＴデバイスに関連付けられた第２リモートサービスと通信するために、第２ＩｏＴデバイスから情報を受信することと、第１ＩｏＴデバイスから第１リモートサービスに情報を伝送することであって、第１リモートサービスは、情報に応答して、検証手順を開始するために第２リモートサービスにコンタクトする、伝送することと、第２ＩｏＴデバイスからサービス検証情報を受信することであって、サービス検証情報は、第１リモートサービスが検証手順を開始するために第２リモートサービスにコンタクトしたことに応答して、第２リモートサービスから第２ＩｏＴデバイスに提供される、受信することと、サービス検証情報を第１ＩｏＴデバイスから第１リモートサービスに伝送することであって、サービス検証情報は、第１リモートサービスと第２リモートサービスとの間の検証済み接続を実現するために第１リモートサービスによって用いられ、検証済み接続は、第１および第２リモートサービスを介して、第１ＩｏＴデバイスと第２ＩｏＴデバイスとの間でデータまたはコマンドを通信するために確立される、伝送することと、を第１ＩｏＴデバイスに実行させるように構成される、システムである。

例２７において、例２６の主題は、任意選択的に、第１ＩｏＴデバイスと通信する承認サーバを含み、承認サーバは、検証手順を確立し、検証済み接続を確立するために用いられる少なくとも１つの認証トークンを提供する。

例２８において、例２６－２７のいずれか１つまたは複数の主題は、任意選択的に、通信回路およびプロセッサ回路を含むＩｏＴゲートウェイを含み、ＩｏＴゲートウェイは、第１ＩｏＴデバイスおよび第２ＩｏＴデバイスと通信し、ローカルエリアネットワークを介してデバイス発見およびデバイスツーデバイス通信を実現するように構成される。

例２９において、例２６－２８のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスを動作させるリモートサーバを含み、リモートサーバは、プロセッサ回路および少なくとも１つのメモリデバイスを含み、第１リモートサービスは、第１リモートサービスおよび第１ＩｏＴデバイスが第１サービスドメインで動作し、第２リモートサービスおよび第２ＩｏＴデバイスが第２サービスドメインで動作するようにオペレーションを実行するように構成される。

例３０において、例２６－２９のいずれか１つまたは複数の主題は、任意選択的に、例１３から２４のいずれかのオペレーションをように実行するように構成されるそれぞれのプロセッサ回路を含む。

例３１は、装置であって、ＩｏＴデバイスとの通信を実行し、装置に関連付けられた第１リモートサービスとの通信を実行するための手段と、第１リモートサービスを介して、ＩｏＴデバイスに関連付けられた第２リモートサービスとの通信を実現するために、ＩｏＴデバイスから情報を取得するための手段と、第１リモートサービスに情報を提供するための手段であって、情報は、第１リモートサービスが、第２リモートサービスとの検証手順を開始することを可能にする、手段と、ＩｏＴデバイスからサービス検証情報を取得するための手段であって、サービス検証情報は、検証手順に応答して、第２リモートサービスからＩｏＴデバイスに提供される、手段と、第１リモートサービスと第２リモートサービスとの間の検証済み接続を実現し、第１および第２リモートサービスを介して、装置とＩｏＴデバイスとの間でデータまたはコマンドを通信するために、サービス検証情報を第１リモートサービスに提供するための手段と、を備える装置である。

例３２において、例３１の主題は、任意選択的に、第１リモートサービスにコマンドを通信することによって、第１リモートサービスおよび第２リモートサービスを介して、ＩｏＴデバイスにコマンドを提供するための手段であって、コマンドの通信に応答して、コマンドは、第１リモートサービスと第２リモートサービスとの間の検証済み接続を用いて、第１リモートサービスから第２リモートサービスに、および第２リモートサービスからＩｏＴデバイスにさらに通信される、手段を提供することを含む。

例３３において、例３１－３２のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスに提供されたデータ値の要求によって、第１リモートサービスおよび第２リモートサービスを介して、ＩｏＴデバイスからデータ値を取得するための手段であって、データ値の要求に応答して、要求は、第１リモートサービスと第２リモートサービスとの間の検証済み接続を用いて、第１リモートサービスから第２リモートサービスに、および第２リモートサービスからＩｏＴデバイスにさらに通信され、ＩｏＴデバイスから第２リモートサービスおよび第１リモートサービスに戻される、手段を含む。

例３４において、例３１－３３のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスは、第１エンティティに関連付けられた第１クラウドネットワークでホストされ、第２リモートサービスは、第２エンティティに関連付けられた第２クラウドネットワークでホストされ、装置は、第１エンティティに関連付けられており、ＩｏＴデバイスは、第２エンティティに関連付けられている主題を含む。

例３５において、例３４の主題は、任意選択的に、装置は、第１エンティティによって製造され、またはその代理としてサービスされており、ＩｏＴデバイスは、第２エンティティによって製造され、またはその代理としてサービスされている主題を含む。

例３６において、例３１－３５のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスは、第２リモートサービスへのデータまたはコマンドを伴う認証情報をさらに提供し、第１リモートサービスと第２リモートサービスとの間の検証済み接続は、認証情報の使用に基づいて確立される主題を含む。

例３７において、例３１－３６のいずれか１つまたは複数の主題は、任意選択的に、ユーザ入力に応答して情報を受信または確認するための手段であって、サービス検証情報は、ユーザ入力に応答して、ＩｏＴデバイスで取得される、手段を含む。

例３８において、例３１－３７のいずれか１つまたは複数の主題は、任意選択的に、第１リモートサービスは、第２リモートサービスにアクセス可能なデバイスの第１ディレクトリを維持し、デバイスの第１ディレクトリは、装置に関連付けられたデータを含み、第２リモートサービスは、第１リモートサービスにアクセス可能なデバイスの第２ディレクトリを維持し、デバイスの第２ディレクトリは、ＩｏＴデバイスに関連付けられたデータを含み、サービス検証情報は、デバイスの第１および第２ディレクトリの少なくとも１つに基づいて提供される主題を含む。

例３９において、例３１－３８のいずれか１つまたは複数の主題は、任意選択的に、少なくとも１つのトークンを含むように、第１リモートサービスへの通信を生成するための手段であって、少なくとも１つのトークンは、承認サーバから取得された認証情報を提供するデータを含む、手段を含む。

例４０において、例３１－３９のいずれか１つまたは複数の主題は、任意選択的に、ＩｏＴデバイスと共に実行される通信はローカルエリアネットワークを介して実行され、第１リモートサービスと共に実行される通信は、ワイドエリアネットワークを介して実行される主題を含む。

例４１において、例４０の主題は、任意選択的に、ローカルエリアネットワーク上でのＩｏＴデバイスの発見に応答して、第２リモートサービスと通信するためにＩｏＴデバイスから情報が取得され、ＩｏＴデバイスから取得される情報は、許可を相互に認証し、通信リンクのセキュリティを確立するための情報を含む主題を含む。

例４２において、例３１－４１のいずれか１つまたは複数の主題は、任意選択的に、Ｏｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ（ＯＣＦ）仕様に従って定義された規格に従って、ＩｏＴデバイスと通信するための手段を含む。

例４３は、命令または命令に構成され得る格納されたデータを備える少なくとも１つの非一時的機械可読記憶媒体であって、命令は、コンピューティングデバイスの処理回路によって構成および実行されたときに、例１から４２のオペレーションのいずれを処理回路に実行させる。

例４４は、データを備える１つまたは複数のコンピュータ可読記憶媒体であり、データは、電子デバイスの１つまたは複数のプロセッサまたは電子回路によるデータのロード、実行、構成、またはプロビジョニングの際に、例１から４２のいずれかで説明される、もしくはこれらに関連する方法、または本明細書で説明されるいずれかの他の方法もしくは処理の１つまたは複数の要素を、電子デバイスに実行させる。

例４５は、例１から４２のいずれかで説明される、もしくはこれらに関連する方法、または本明細書で説明されるいずれかの他の方法もしくは処理の１つまたは複数の要素を実行するロジック、モジュール、または回路を備える装置である。

例４６は、例１から４２、またはその一部もしくは部分のいずれかにおいて説明され、またはこれらに関連するような方法、技術、または処理である。

例４７は、１つまたは複数のプロセッサと、命令を含む１つまたは複数のコンピュータ可読媒体とを備える装置であって、命令は、１つまたは複数のプロセッサによって実行されたときに、例１から４２、またはその部分のいずれかにおいて説明され、またはこれらに関連するような方法、技術、または処理を、１つまたは複数のプロセッサに実行させる。

例４８は、例１から４２、またはその一部もしくは部分のいずれかにおいて説明され、またはこれらに関連するような信号である。

例４９は、例１から４２のいずれかにおいて説明され、もしくはこれらに関連するような、または本明細書において別の方法で図示および説明される、無線ネットワークにおける信号である。

例５０は、例１から４２のいずれかにおいて説明され、もしくはこれらに関連するような、または本明細書において別の方法で図示および説明される、無線ネットワークにおいて通信を調整する方法である。

例５１は、例１から４２のいずれかにおいて説明され、もしくはこれらに関連するような、または本明細書において別の方法で図示および説明される、通信を処理するためのデバイスである。

例５２は、例１から４２のオペレーション、または本明細書において別の方法で図示および説明されるようなオペレーションのいずれかを実行するためのそれぞれのデバイスおよびデバイス通信メディアを備えるネットワークである。

例５３は、回路を備え、例１から４２のオペレーション、または本明細書において別の方法で図示および説明されるようなオペレーションのいずれかを実行するためのそれぞれのロジックおよび機能を実装するネットワークインタフェースカードである。

例５４は、例１から４２のオペレーション、または本明細書において別の方法で図示および説明されるようなオペレーションのいずれかを実行するように適合される、処理ノードおよびコンピューティングユニットを備えるデバイスフォグ実装である。

例５５は、例１から４２のオペレーション、または本明細書において別の方法で図示および説明されるようなオペレーションのいずれかを実行するように適合される、処理ノードおよびコンピューティングユニットを備えるクラウドサービスサーバである。

例５６は、例１から４２のオペレーション、または本明細書において別の方法で図示および説明されるようなオペレーションのいずれかを実行するために、それぞれの通信リンク、通信回路、または処理回路を備えるモノのインターネット（ＩｏＴ）ネットワーク構成である。

例５７は、例１から４２のオペレーション、または本明細書において別の方法で図示および説明されるようなオペレーションのいずれかを実行するように適合される、処理ノードおよびコンピューティングユニットを備えるエッジコンピューティングシステム実装である。

例５８は、例１から２５のオペレーション、または本明細書において別の方法で図示および説明されるようなオペレーションのいずれかを実行するように適合される、処理ノードおよびコンピューティングユニットを備えるエッジクラウドコンピューティングデバイス実装である。

例５９は、例１から５８のいずれかの実装のための手段を備える装置である。

例６０は、例１から５８のいずれかを実装するシステムである。

例６１は、例１から５８のいずれかを実装する方法である。

上述の詳細な説明において、様々な特徴が一緒にグループ化され、本開示のストリームラインとなってよい。ただし、実施形態は、上述の特徴のサブセットを含み得るので、特許請求の範囲は、本明細書で開示された全ての特徴を記載していないことがある。さらに、実施形態は、具体例において開示されたものより少ない特徴を含んでよい。したがって、以下の特許請求の範囲は、ここに、詳細な説明に組み込まれており、請求項は、別個の実施形態として独立したものである。
［他の可能な態様］
［項目１］
処理回路と、
第２デバイスとの通信を実行し、上記デバイスに関連付けられた第１リモートサービスとの通信を実行するように構成される通信回路と、
そこで具現化される命令を含むメモリデバイスと
を備えるデバイスであって、
上記命令は、上記処理回路によって実行されたときに、
上記第２デバイスに関連付けられた第２リモートサービスと通信するために、上記第２デバイスから情報を取得するオペレーションと、
上記デバイスから上記第１リモートサービスに上記情報を提供するオペレーションであって、上記情報に応答して、上記第１リモートサービスが上記第２リモートサービスとの検証手順を開始する、オペレーションと、
上記第２デバイスからサービス検証情報を取得するオペレーションであって、上記サービス検証情報は、上記第１リモートサービスが上記第２リモートサービスとの上記検証手順を開始したことに応答して、上記第２リモートサービスから上記第２デバイスに提供される、オペレーションと、
上記デバイスから上記第１リモートサービスに上記サービス検証情報を提供するオペレーションであって、上記サービス検証情報は、上記第１リモートサービスによって、上記第１リモートサービスと上記第２リモートサービスとの間の検証済み接続を実現するために用いられ、上記検証済み接続は、上記第１および第２リモートサービスを介して上記デバイスと上記第２デバイスとの間でデータまたはコマンドを通信するために確立される、オペレーションと、
を実行するように上記処理回路を構成する
デバイス。
［項目２］
上記命令は、
上記デバイスから上記第１リモートサービスにコマンドを通信することによって、上記第１リモートサービスおよび上記第２リモートサービスを介して、上記デバイスから上記第２デバイスに上記コマンドを提供するオペレーションであって、上記コマンドを通信することに応答して、上記第１リモートサービスと上記第２リモートサービスとの間の上記検証済み接続を用いて、上記コマンドは、上記第１リモートサービスから上記第２リモートサービスへ、上記第２リモートサービスから上記第２デバイスへ、さらに通信される、オペレーション
を実行するように上記処理回路をさらに構成する
項目１に記載のデバイス。
［項目３］
上記命令は、
上記デバイスから上記第１リモートサービスへのデータ値の要求を通信することによって、上記第１リモートサービスおよび上記第２リモートサービスを介して、上記第２デバイスから上記データ値を取得するオペレーションであって、上記データ値の上記要求に応答して、上記要求は、上記第１リモートサービスと上記第２リモートサービスとの間の上記検証済み接続を用いて、上記第１リモートサービスから上記第２リモートサービスに、および上記第２リモートサービスから上記第２デバイスにさらに通信され、上記第２デバイスから上記第２リモートサービスおよび上記第１リモートサービスに戻される、オペレーション
を実行するように上記処理回路をさらに構成する
項目１に記載のデバイス。
［項目４］
上記第１リモートサービスは、第１エンティティに関連付けられた第１クラウドネットワークでホストされ、上記第２リモートサービスは、第２エンティティに関連付けられた第２クラウドネットワークでホストされ、上記デバイスは、上記第１エンティティに関連付けられており、上記第２デバイスは、上記第２エンティティに関連付けられている
項目１に記載のデバイス。
［項目５］
上記デバイスは、上記第１エンティティによって製造され、またはその代理としてサービスされており、上記第２デバイスは、上記第２エンティティによって製造され、またはその代理としてサービスされている
項目４に記載のデバイス。
［項目６］
上記第１リモートサービスは、上記第２リモートサービスへのデータまたはコマンドを伴う認証情報をさらに提供し、上記第１リモートサービスと上記第２リモートサービスとの間の上記検証済み接続は、上記認証情報の使用に基づいて確立される
項目１に記載のデバイス。
［項目７］
上記情報は、上記デバイスで受信されたユーザ入力に応答して上記第１リモートサービスに提供され、上記サービス検証情報は、上記第２デバイスでのユーザ入力に応答して上記デバイスに提供される
項目１に記載のデバイス。
［項目８］
上記第１リモートサービスは、上記第２リモートサービスにアクセス可能なデバイスの第１ディレクトリを維持し、デバイスの上記第１ディレクトリは、上記デバイスに関連付けられたデータを含み、
上記第２リモートサービスは、上記第１リモートサービスにアクセス可能なデバイスの第２ディレクトリを維持し、デバイスの上記第２ディレクトリは、上記第２デバイスに関連付けられたデータを含み、
上記サービス検証情報は、デバイスの上記第１および第２ディレクトリの少なくとも１つに基づいて提供される
項目１に記載のデバイス。
［項目９］
上記デバイスから上記第１リモートサービスへの通信は少なくとも１つのトークンを含み、上記少なくとも１つのトークンは、承認サーバから取得された認証情報を提供するデータを含む
項目１に記載のデバイス。
［項目１０］
上記第２デバイスと共に実行される上記通信はローカルエリアネットワークを介して実行され、上記第１リモートサービスと共に実行される上記通信は、ワイドエリアネットワークを介して実行される
項目１に記載のデバイス。
［項目１１］
上記第２リモートサービスと通信するために、上記第２デバイスから上記情報を取得するための上記オペレーションは、上記ローカルエリアネットワーク上での上記第２デバイスの発見に応答して実行され、上記第２デバイスから取得される上記情報は、許可を相互に認証し、通信リンクのセキュリティを確立するための情報を含む
項目１０に記載のデバイス。
［項目１２］
上記デバイスおよび上記第２デバイスは、Ｏｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ（ＯＣＦ）仕様に従って定義される規格に従って通信し、上記オペレーションによって実行される上記通信は、それぞれのデバイスおよびサービス間の非同期メッセージに従って行われる
項目１から１１のいずれかに記載のデバイス。
［項目１３］
モノのインターネット（ＩｏＴ）デバイス展開において通信を確立するための方法であって、ＩｏＴデバイスの処理回路によって実行されるオペレーションを備え、上記オペレーションは、
上記第２ＩｏＴデバイスに関連付けられた第２リモートサービスと通信するために、第２ＩｏＴデバイスから情報を取得することと、
上記情報を第１リモートサービスに提供することであって、上記情報に応答して、上記第１リモートサービスは上記第２リモートサービスと検証手順を開始する、提供することと、
上記第２ＩｏＴデバイスからサービス検証情報を取得することであって、上記サービス検証情報は、上記検証手順に応答して、上記第２リモートサービスから上記第２ＩｏＴデバイスに提供される、取得することと、
上記ＩｏＴデバイスと上記第２ＩｏＴデバイスとの間で、上記第１および第２リモートサービスを介してデータまたはコマンドを通信するために、上記第１リモートサービスと上記第２リモートサービスとの間の検証済み接続を可能にするために、上記サービス検証情報を上記第１リモートサービスに提供することと
を含む方法。
［項目１４］
上記オペレーションは、
上記ＩｏＴデバイスから上記第１リモートサービスにコマンドを通信することによって、上記ＩｏＴデバイスから上記第２ＩｏＴデバイスに、上記第１リモートサービスおよび上記第２リモートサービスを介して上記コマンドを提供することであって、上記コマンドの通信に応答して、上記コマンドは、上記第１リモートサービスと上記第２リモートサービスとの間の上記検証済み接続を用いて、上記第１リモートサービスから上記第２リモートサービスに、および上記第２リモートサービスから上記第２ＩｏＴデバイスにさらに通信される、提供すること
をさらに含む
項目１３に記載の方法。
［項目１５］
上記オペレーションは、
上記ＩｏＴデバイスから上記第１リモートサービスへのデータ値の要求を通信することによって、上記第１リモートサービスおよび上記第２リモートサービスを介して、上記第２ＩｏＴデバイスから上記データ値を取得することであって、上記データ値の上記要求に応答して、上記要求は、上記第１リモートサービスと上記第２リモートサービスとの間の上記検証済み接続を用いて、上記第１リモートサービスから上記第２リモートサービスに、および上記第２リモートサービスから上記第２ＩｏＴデバイスにさらに通信され、上記第２ＩｏＴデバイスから上記第２リモートサービスおよび上記第１リモートサービスに戻される、取得すること
をさらに含む
項目１３に記載の方法。
［項目１６］
上記第１リモートサービスは、第１エンティティに関連付けられた第１クラウドネットワークでホストされ、上記第２リモートサービスは、第２エンティティに関連付けられた第２クラウドネットワークでホストされ、上記ＩｏＴデバイスは、上記第１エンティティに関連付けられており、上記第２ＩｏＴデバイスは、上記第２エンティティに関連付けられている
項目１３に記載の方法。
［項目１７］
上記ＩｏＴデバイスは、上記第１エンティティによって製造され、またはその代理としてサービスされており、上記第２ＩｏＴデバイスは、上記第２エンティティによって製造され、またはその代理としてサービスされている
項目１６に記載の方法。
［項目１８］
上記第１リモートサービスは、上記第２リモートサービスへのデータまたはコマンドを伴う認証情報をさらに提供し、上記第１リモートサービスと上記第２リモートサービスとの間の上記検証済み接続は、上記認証情報の使用に基づいて確立される
項目１３に記載の方法。
［項目１９］
上記情報は、上記ＩｏＴデバイスで受信されたユーザ入力に応答して上記第１リモートサービスに提供され、上記サービス検証情報は、上記第２ＩｏＴデバイスでのユーザ入力に応答して上記ＩｏＴデバイスに提供される
項目１３に記載の方法。
［項目２０］
上記第１リモートサービスは、上記第２リモートサービスにアクセス可能なデバイスの第１ディレクトリを維持し、デバイスの上記第１ディレクトリは、上記ＩｏＴデバイスに関連付けられたデータを含み、
上記第２リモートサービスは、上記第１リモートサービスにアクセス可能なデバイスの第２ディレクトリを維持し、デバイスの上記第２ディレクトリは、上記第２ＩｏＴデバイスに関連付けられたデータを含み、
上記サービス検証情報は、デバイスの上記第１および第２ディレクトリの少なくとも１つに基づいて提供される
項目１３に記載の方法。
［項目２１］
上記ＩｏＴデバイスから上記第１リモートサービスへの通信は少なくとも１つのトークンを含み、上記少なくとも１つのトークンは、承認サーバから取得された認証情報を提供するデータを含む
項目１３に記載の方法。
［項目２２］
上記第２ＩｏＴデバイスと共に実行される上記通信はローカルエリアネットワークを介して実行され、上記第１リモートサービスと共に実行される上記通信は、ワイドエリアネットワークを介して実行される
項目１３に記載の方法。
［項目２３］
上記第２リモートサービスと通信するために、上記第２ＩｏＴデバイスから上記情報を取得するための上記オペレーションは、上記ローカルエリアネットワーク上での上記第２ＩｏＴデバイスの発見に応答して実行され、上記第２ＩｏＴデバイスから取得される上記情報は、許可を相互に認証し、通信リンクのセキュリティを確立するための情報を含む
項目２２に記載の方法。
［項目２４］
上記ＩｏＴデバイスおよび上記第２ＩｏＴデバイスは、Ｏｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ（ＯＣＦ）仕様に従って定義される規格に従って通信し、上記オペレーションによって実行される上記通信は、それぞれのデバイスおよびサービス間の非同期メッセージに従って行われる
項目１３から２３のいずれか記載の方法。
［項目２５］
格納された命令を備える少なくとも１つの機械可読ストレージデバイスであって、上記命令は、装置の処理回路によって実行されたときに、項目１３から２４に記載のオペレーションのいずれかを上記処理回路に実行させる、機械可読ストレージデバイス。

Claims (26)

1. 処理回路と、
   第２デバイスとの通信を実行し、前記デバイスに関連付けられた第１リモートサービスとの通信を実行するように構成される通信回路と、
   そこで具現化される命令を含むメモリデバイスと
   を備えるデバイスであって、
   前記命令は、前記処理回路によって実行されたときに、
   前記第２デバイスに関連付けられた第２リモートサービスと通信するために、前記第２デバイスから情報を取得するオペレーションと、
   前記デバイスから前記第１リモートサービスに前記情報を提供するオペレーションであって、前記情報に応答して、前記第１リモートサービスが前記第２リモートサービスとの検証手順を開始する、オペレーションと、
   前記第２デバイスからサービス検証情報を取得するオペレーションであって、前記サービス検証情報は、前記第１リモートサービスが前記第２リモートサービスとの前記検証手順を開始したことに応答して、前記第２リモートサービスから前記第２デバイスに提供される、オペレーションと、
   前記デバイスから前記第１リモートサービスに前記サービス検証情報を提供するオペレーションであって、前記サービス検証情報は、前記第１リモートサービスによって、前記第１リモートサービスと前記第２リモートサービスとの間の検証済み接続を実現するために用いられ、前記検証済み接続は、前記第１および第２リモートサービスを介して前記デバイスと前記第２デバイスとの間でデータまたはコマンドを通信するために確立される、オペレーションと、
   を実行するように前記処理回路を構成する
   デバイス。
2. 前記命令は、
   前記デバイスから前記第１リモートサービスにコマンドを通信することによって、前記第１リモートサービスおよび前記第２リモートサービスを介して、前記デバイスから前記第２デバイスに前記コマンドを提供するオペレーションであって、前記コマンドを通信することに応答して、前記第１リモートサービスと前記第２リモートサービスとの間の前記検証済み接続を用いて、前記コマンドは、前記第１リモートサービスから前記第２リモートサービスへ、前記第２リモートサービスから前記第２デバイスへ、さらに通信される、オペレーション
   を実行するように前記処理回路をさらに構成する
   請求項１に記載のデバイス。
3. 前記命令は、
   前記デバイスから前記第１リモートサービスにデータ値の要求を通信することによって、前記第１リモートサービスおよび前記第２リモートサービスを介して、前記第２デバイスから前記データ値を取得するオペレーションであって、前記データ値の前記要求に応答して、前記要求は、前記第１リモートサービスと前記第２リモートサービスとの間の前記検証済み接続を用いて、前記第１リモートサービスから前記第２リモートサービスへ、前記第２リモートサービスから前記第２デバイスへさらに通信され、前記第２デバイスから前記第２リモートサービスに、かつ前記第１リモートサービスに戻される、オペレーション
   を実行するように前記処理回路をさらに構成する
   請求項１に記載のデバイス。
4. 前記第１リモートサービスは、第１エンティティに関連付けられた第１クラウドネットワークでホストされ、前記第２リモートサービスは、第２エンティティに関連付けられた第２クラウドネットワークでホストされ、前記デバイスは、前記第１エンティティに関連付けられており、前記第２デバイスは、前記第２エンティティに関連付けられている
   請求項１に記載のデバイス。
5. 前記デバイスは、前記第１エンティティによって製造され、またはその代理としてサービスされており、前記第２デバイスは、前記第２エンティティによって製造され、またはその代理としてサービスされている
   請求項４に記載のデバイス。
6. 前記第１リモートサービスは、前記第２リモートサービスへのデータまたはコマンドを伴う認証情報をさらに提供し、前記第１リモートサービスと前記第２リモートサービスとの間の前記検証済み接続は、前記認証情報の使用に基づいて確立される
   請求項１に記載のデバイス。
7. 前記情報は、前記デバイスで受信されたユーザ入力に応答して前記第１リモートサービスに提供され、前記サービス検証情報は、前記第２デバイスでのユーザ入力に応答して前記デバイスに提供される
   請求項１に記載のデバイス。
8. 前記第１リモートサービスは、前記第２リモートサービスにアクセス可能なデバイスの第１ディレクトリを維持し、デバイスの前記第１ディレクトリは、前記デバイスに関連付けられたデータを含み、
   前記第２リモートサービスは、前記第１リモートサービスにアクセス可能なデバイスの第２ディレクトリを維持し、デバイスの前記第２ディレクトリは、前記第２デバイスに関連付けられたデータを含み、
   前記サービス検証情報は、デバイスの前記第１および第２ディレクトリの少なくとも１つに基づいて提供される
   請求項１に記載のデバイス。
9. 前記デバイスから前記第１リモートサービスへの通信は少なくとも１つのトークンを含み、前記少なくとも１つのトークンは、承認サーバから取得された認証情報を提供するデータを含む
   請求項１に記載のデバイス。
10. 前記第２デバイスと共に実行される前記通信はローカルエリアネットワークを介して実行され、前記第１リモートサービスと共に実行される前記通信は、ワイドエリアネットワークを介して実行される
    請求項１に記載のデバイス。
11. 前記第２リモートサービスと通信するために、前記第２デバイスから前記情報を取得するための前記オペレーションは、前記ローカルエリアネットワーク上での前記第２デバイスの発見に応答して実行され、前記第２デバイスから取得される前記情報は、許可を相互に認証し、通信リンクのセキュリティを確立するための情報を含む
    請求項１０に記載のデバイス。
12. 前記デバイスおよび前記第２デバイスは、Ｏｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ（ＯＣＦ）仕様に従って定義される規格に従って通信し、前記オペレーションによって実行される前記通信は、それぞれのデバイスおよびサービス間の非同期メッセージに従って行われる
    請求項１から１１のいずれか一項に記載のデバイス。
13. モノのインターネット（ＩｏＴ）デバイス展開において通信を確立するための方法であって、ＩｏＴデバイスの処理回路によって実行されるオペレーションを備え、前記オペレーションは、
    前記第２ＩｏＴデバイスに関連付けられた第２リモートサービスと通信するために、第２ＩｏＴデバイスから情報を取得することと、
    前記情報を第１リモートサービスに提供することであって、前記情報に応答して、前記第１リモートサービスは前記第２リモートサービスと検証手順を開始する、提供することと、
    前記第２ＩｏＴデバイスからサービス検証情報を取得することであって、前記サービス検証情報は、前記検証手順に応答して、前記第２リモートサービスから前記第２ＩｏＴデバイスに提供される、取得することと、
    前記ＩｏＴデバイスと前記第２ＩｏＴデバイスとの間で、前記第１および第２リモートサービスを介してデータまたはコマンドを通信するために、前記第１リモートサービスと前記第２リモートサービスとの間の検証済み接続を可能にするために、前記サービス検証情報を前記第１リモートサービスに提供することと
    を含む方法。
14. 前記オペレーションは、
    前記ＩｏＴデバイスから前記第１リモートサービスにコマンドを通信することによって、前記ＩｏＴデバイスから前記第２ＩｏＴデバイスに、前記第１リモートサービスおよび前記第２リモートサービスを介して前記コマンドを提供することであって、前記コマンドの通信に応答して、前記コマンドは、前記第１リモートサービスと前記第２リモートサービスとの間の前記検証済み接続を用いて、前記第１リモートサービスから前記第２リモートサービスに、および前記第２リモートサービスから前記第２ＩｏＴデバイスにさらに通信される、提供すること
    をさらに含む
    請求項１３に記載の方法。
15. 前記オペレーションは、
    前記ＩｏＴデバイスから前記第１リモートサービスへのデータ値の要求を通信することによって、前記第１リモートサービスおよび前記第２リモートサービスを介して、前記第２ＩｏＴデバイスから前記データ値を取得することであって、前記データ値の前記要求に応答して、前記要求は、前記第１リモートサービスと前記第２リモートサービスとの間の前記検証済み接続を用いて、前記第１リモートサービスから前記第２リモートサービスに、および前記第２リモートサービスから前記第２ＩｏＴデバイスにさらに通信され、前記第２ＩｏＴデバイスから前記第２リモートサービスおよび前記第１リモートサービスに戻される、取得すること
    をさらに含む
    請求項１３に記載の方法。
16. 前記第１リモートサービスは、第１エンティティに関連付けられた第１クラウドネットワークでホストされ、前記第２リモートサービスは、第２エンティティに関連付けられた第２クラウドネットワークでホストされ、前記ＩｏＴデバイスは、前記第１エンティティに関連付けられており、前記第２ＩｏＴデバイスは、前記第２エンティティに関連付けられている
    請求項１３に記載の方法。
17. 前記ＩｏＴデバイスは、前記第１エンティティによって製造され、またはその代理としてサービスされており、前記第２ＩｏＴデバイスは、前記第２エンティティによって製造され、またはその代理としてサービスされている
    請求項１６に記載の方法。
18. 前記第１リモートサービスは、前記第２リモートサービスへのデータまたはコマンドを伴う認証情報をさらに提供し、前記第１リモートサービスと前記第２リモートサービスとの間の前記検証済み接続は、前記認証情報の使用に基づいて確立される
    請求項１３に記載の方法。
19. 前記情報は、前記ＩｏＴデバイスで受信されたユーザ入力に応答して前記第１リモートサービスに提供され、前記サービス検証情報は、前記第２ＩｏＴデバイスでのユーザ入力に応答して前記ＩｏＴデバイスに提供される
    請求項１３に記載の方法。
20. 前記第１リモートサービスは、前記第２リモートサービスにアクセス可能なデバイスの第１ディレクトリを維持し、デバイスの前記第１ディレクトリは、前記ＩｏＴデバイスに関連付けられたデータを含み、
    前記第２リモートサービスは、前記第１リモートサービスにアクセス可能なデバイスの第２ディレクトリを維持し、デバイスの前記第２ディレクトリは、前記第２ＩｏＴデバイスに関連付けられたデータを含み、
    前記サービス検証情報は、デバイスの前記第１および第２ディレクトリの少なくとも１つに基づいて提供される
    請求項１３に記載の方法。
21. 前記ＩｏＴデバイスから前記第１リモートサービスへの通信は少なくとも１つのトークンを含み、前記少なくとも１つのトークンは、承認サーバから取得された認証情報を提供するデータを含む
    請求項１３に記載の方法。
22. 前記第２ＩｏＴデバイスと共に実行される前記通信はローカルエリアネットワークを介して実行され、前記第１リモートサービスと共に実行される前記通信は、ワイドエリアネットワークを介して実行される
    請求項１３に記載の方法。
23. 前記第２リモートサービスと通信するために、前記第２ＩｏＴデバイスから前記情報を取得するための前記オペレーションは、前記ローカルエリアネットワーク上での前記第２ＩｏＴデバイスの発見に応答して実行され、前記第２ＩｏＴデバイスから取得される前記情報は、許可を相互に認証し、通信リンクのセキュリティを確立するための情報を含む
    請求項２２に記載の方法。
24. 前記ＩｏＴデバイスおよび前記第２ＩｏＴデバイスは、Ｏｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ（ＯＣＦ）仕様に従って定義される規格に従って通信し、前記通信は、それぞれのデバイスおよびサービス間の非同期メッセージに従って行われる
    請求項１３から２３のいずれか一項に記載の方法。
25. 請求項１３から２４のいずれか一項に記載の方法を前記処理回路に実行させるプログラム。
26. 請求項２５に記載のプログラムを格納するコンピュータ可読記憶媒体。

Images