特許 7507826 住宅ネットワークの装置のための効率的通信

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-06-20

(45)【発行日】2024-06-28

(54)【発明の名称】住宅ネットワークの装置のための効率的通信

(51)【国際特許分類】

   H04L 69/165 20220101AFI20240621BHJP

   H04L 49/25 20220101ALI20240621BHJP

【ＦＩ】

H04L69/165

H04L49/25

【請求項の数】 19

(21)【出願番号】P 2022167520

(22)【出願日】2022-10-19

(62)【分割の表示】P 2021123111の分割

【原出願日】2014-06-23

(65)【公開番号】P2023017782

(43)【公開日】2023-02-07

【審査請求日】2022-10-28

(31)【優先権主張番号】13/926,335

(32)【優先日】2013-06-25

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

【氏名又は名称原語表記】Ｇｏｏｇｌｅ ＬＬＣ

【住所又は居所原語表記】１６００ Ａｍｐｈｉｔｈｅａｔｒｅ Ｐａｒｋｗａｙ ９４０４３ Ｍｏｕｎｔａｉｎ Ｖｉｅｗ， ＣＡ Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】エリクソン，グラント・エム

(72)【発明者】

【氏名】ローグ，ジェイ・ディ

(72)【発明者】

【氏名】ボロス，クリストファー・エイ

(72)【発明者】

【氏名】スミス，ザカリー・ビィ

(72)【発明者】

【氏名】ハーディソン，オスボーン・ビィ

(72)【発明者】

【氏名】シュルツ，リチャード・ジェイ

(72)【発明者】

【氏名】グジャール，サニー・ピィ

(72)【発明者】

【氏名】ニーリー，マシュー・ジィ

【審査官】羽岡 さやか

(56)【参考文献】

【文献】米国特許出願公開第２００９／００７３９８３（ＵＳ，Ａ１）

【文献】特表２００５－５３５２４７（ＪＰ，Ａ）

【文献】特開２０１３－０４２２４３（ＪＰ，Ａ）

【文献】特開２００５－１００２５１（ＪＰ，Ａ）

【文献】特表２０１４－５０４０４３（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１０／０２６２６５０（ＵＳ，Ａ１）

【文献】川島 英之 Hideyuki KAWASHIMA，サービス指向ルータ上の分散ストリーム処理エンジンにおけるノード間通信機構の検討 A Consideration of Communication Architecture on Distributed Stream Processing Engine for Service oriented Router，電子情報通信学会技術研究報告 Ｖｏｌ．１１０ Ｎｏ．４４８ IEICE Technical Report，日本，社団法人電子情報通信学会 The Institute of Electronics,Information and Communication Engineers，第110巻，P.427-432

【文献】別所 雄三 Yuzo Bessho，クラウドサービスを支える通信ゲートウェイ技術，三菱電機技報 第８７巻 第５号 ，三菱電機エンジニアリング株式会社，2013年05月25日，第87巻，P.13 (271)-18 (276)

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ １２／００－６９／４０

(57)【特許請求の範囲】

【請求項1】

電子装置であって、
ネットワークスタックを動作させる命令を記憶するメモリまたは記憶装置と；
前記ネットワークスタックを動作させる前記命令を実行するよう構成されるプロセッサと；
ネットワーク接続された装置のファブリックに加わり、前記ネットワークスタックを用いて、前記装置のファブリックの目標装置にメッセージを通信するよう構成されるネットワークインターフェイスとを含み、
前記ネットワークスタックは、
前記メッセージにおいて送信されるべきデータを含むアプリケーションペイロードを与えるよう構成されるアプリケーション層と；
前記アプリケーションペイロードを前記メッセージの一般的なメッセージフォーマットにおいてカプセル化するよう構成されるプラットフォーム層と；前記一般的なメッセージフォーマットは、タイプ－長さ－値（ＴＬＶ）フォーマットを含み、
ユーザ・データグラム・プロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）のいずれかを用いて、前記メッセージを選択可能に伝送するよう構成されたトランスポート層と；
前記メッセージを、インターネットプロトコルバージョン６（ＩＰｖ６）を用いて、
８０２．１１ワイヤレスネットワーク；
８０２．１５．４ワイヤレスネットワーク；
電力線網；
セルラーネットワーク；
イーサネット（登録商標）ネットワーク；または
それらの任意の組合せを介して通信するよう構成されるネットワーク層とを含み；
前記アプリケーション層、前記プラットフォーム層、前記トランスポート層、前記ネットワーク層またはそれらの任意の組合せは、前記目標装置への前記メッセージの通信の態様のプロパティを、
前記メッセージのタイプ；
前記メッセージが送信されることになるネットワーク；
前記メッセージが前記ファブリックを通って移動し得る距離；
前記電子装置の電力消費挙動；
前記目標装置の電力消費挙動；
前記電子装置と前記目標装置との間において前記メッセージを通信することになる、前記装置のファブリックの介在装置の電力消費挙動；
前記目標装置はサービスを含むかどうか；または
それらの任意の組合せに少なくとも部分的に基づいて判断するように構成され、前記通信の態様のプロパティは、前記メッセージの通信に用いられるプロトコルのタイプを含み、
前記電子装置は、前記メッセージを、判断した前記通信の態様のプロパティを用いて生成するよう構成され、
前記通信の態様の前記プロパティを変動させることは、前記電子装置、前記目標装置、もしくは前記介在装置、またはそれらの任意の組合に、変動されるプロパティによって異なる量の電力を消費させ、前記メッセージを、前記目標装置に、より信頼性高くまたはそれほど信頼性高くなく到達させるよう構成され、
前記プロセッサは、前記電子装置が前記電子装置の外部の電源によって電力供給されるかどうかに応じて、前記電子装置の節電がメッセージ通信の信頼性よりも所望されるかを判断し、前記節電が前記信頼性よりも所望されるとの判断に応じて、前記ユーザ・データグラム・プロトコル（ＵＤＰ）を用いて前記メッセージを伝送すると判断するよう構成される、電子装置。

【請求項2】

前記通信の態様の前記プロパティを判断することは、
前記メッセージを伝送するよう伝送制御プロトコル（ＴＣＰ）を選択する判断；
前記メッセージを伝送するようユーザ・データグラム・プロトコル（ＵＤＰ）を選択する判断；
より小電力のネットワークを用いて、前記メッセージを通信する判断；
より高電力のネットワークを用いて、前記メッセージを通信する判断；
前記目標装置の好ましいネットワークを、前記メッセージのＩＰｖ６パケットヘッダにおいてエンコードされた拡張固有ローカルアドレス（ＥＵＬＡ）において示される、より高電力のネットワークとして選択する判断；
前記目標装置の好ましいネットワークを、前記メッセージの前記ＩＰｖ６パケットヘッダにおいてエンコードされた前記拡張固有ローカルアドレス（ＥＵＬＡ）において示される、より小電力のネットワークとして選択する判断；または
それらの任意の組合せを含む、請求項１に記載の電子装置。

【請求項3】

前記アプリケーション層は、前記メッセージの緊急度によって伝送制御プロトコル（ＴＣＰ）またはユーザ・データグラム・プロトコル（ＵＤＰ）のどちらを用いて前記メッセージを伝送するべきであるかを判断するように構成される、請求項１または２に記載の電子装置。

【請求項4】

前記メッセージが装置警報を通信するとき、前記メッセージは緊急メッセージを含み、前記メッセージが装置警報なしに非危険な環境状態を示すものを通信するとき、前記メッセージは非緊急メッセージを含む、請求項３に記載の電子装置。

【請求項5】

前記メッセージは、緊急メッセージを含む場合、ＴＣＰを用いて伝送されるように構成され、前記メッセージは、非緊急メッセージを含む場合、ＵＤＰを用いて伝送されるように構成される、請求項４に記載の電子装置。

【請求項6】

前記アプリケーション層は、前記メッセージが送信されることになるネットワークに応じて、ＴＣＰまたはＵＤＰのどちらを用いて前記メッセージを伝送するかを判断するように構成される、請求項１～５のいずれか１項に記載の電子装置。

【請求項7】

前記メッセージは、前記メッセージが送信されることになるネットワークがＷｉＦｉ（登録商標）ネットワークを含む場合、ＴＣＰを用いて伝送されるように構成され、前記メッセージは、前記メッセージが送信されることになるネットワークが８０２．１５．４ワイヤレスネットワークを含む場合、ＵＤＰを用いて伝送されるように構成される、請求項６に記載の電子装置。

【請求項8】

前記アプリケーション層は、前記メッセージが前記ファブリックを通って移動し得る距離に応じて、ＴＣＰまたはＵＤＰのどちらを用いて前記メッセージを伝送するかを判断するように構成される、請求項１～５のいずれか１項に記載の電子装置。

【請求項9】

前記メッセージは、前記メッセージが前記ファブリックを通って移動し得る距離がしきい値よりも大きい場合、ＴＣＰを用いて伝送されるように構成され、前記メッセージは、前記メッセージが前記ファブリックを通って移動し得る距離がしきい値未満である場合、ＵＤＰを用いて伝送されるように構成される、請求項８に記載の電子装置。

【請求項10】

前記アプリケーション層は、前記電子装置が当該電子装置の外部の電源によって電力供給されることに応じて、ＴＣＰを用いて前記メッセージを伝送すると判断するように構成される、請求項１～５のいずれか１項に記載の電子装置。

【請求項11】

前記メッセージは、前記電子装置が当該電子装置の外部の電源によって電力供給されるとき、ＴＣＰを用いて伝送されるように構成され、前記メッセージは、前記電子装置が当該電子装置の内部の電源によって電力供給されるとき、ＵＤＰを用いて伝送されるように構成される、請求項１０に記載の電子装置。

【請求項12】

前記アプリケーション層は、前記電子装置が、サービスを含む前記目標装置に前記メッセージを送信しているか否かに応じて、ＴＣＰまたはＵＤＰのどちらを用いて前記メッセージを伝送するかを判断するように構成される、請求項１～５のいずれか１項に記載の電子装置。

【請求項13】

コンピュータが実行可能な命令を有するプログラムであって、前記命令は、
電子装置がネットワーク接続された装置のファブリックに加わり、前記装置のファブリックの目標装置にメッセージを通信するよう利用されるネットワークスタックを含み、前記ネットワークスタックは、
前記メッセージにおいて送信されるべきデータを含むアプリケーションペイロードを与えるよう構成されるアプリケーション層と；
前記アプリケーションペイロードを前記メッセージの一般的なメッセージフォーマットにおいてカプセル化するよう構成されるプラットフォーム層と；前記一般的なメッセージフォーマットは、タイプ－長さ－値（ＴＬＶ）フォーマットを含み、
ユーザ・データグラム・プロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）のいずれかを用いて、前記メッセージを選択可能に伝送するよう構成されたトランスポート層と；
前記メッセージを、インターネットプロトコルバージョン６（ＩＰｖ６）を用いて、
８０２．１１ワイヤレスネットワーク；
８０２．１５．４ワイヤレスネットワーク；
電力線網；
セルラーネットワーク；
イーサネットネットワーク；または
それらの任意の組合せを介して通信するよう構成されるネットワーク層とを含み；
前記アプリケーション層、前記プラットフォーム層、前記トランスポート層、前記ネットワーク層またはそれらの任意の組合せは、前記目標装置への前記メッセージの通信の態様のプロパティを、
前記メッセージのタイプ；
前記メッセージが送信されることになるネットワーク；
前記メッセージが前記ファブリックを通って移動し得る距離；
前記電子装置の電力消費挙動；
前記目標装置の電力消費挙動；
前記電子装置と前記目標装置との間において前記メッセージを通信することになる、前記装置のファブリックの介在装置の電力消費挙動；
前記目標装置はサービスを含むかどうか；または
それらの任意の組合せに少なくとも部分的に基づいて判断するように構成され、前記通信の態様のプロパティは、前記メッセージの通信に用いられるプロトコルのタイプを含み、
前記命令は、前記メッセージを、判断した前記通信の態様のプロパティを用いて生成するよう構成され、
前記通信の態様の前記プロパティを変動させることは、前記電子装置、前記目標装置、もしくは前記介在装置、またはそれらの任意の組合せに、変動されるプロパティによって異なる量の電力を消費させ、前記メッセージを、前記目標装置に、より信頼性高くまたはそれほど信頼性高くなく到達させるよう構成され、
前記命令は、前記電子装置が前記電子装置の外部の電源によって電力供給されるかどうかに応じて、前記電子装置の節電がメッセージ通信の信頼性よりも所望されるかを判断し、
前記節電が前記信頼性よりも所望されるとの判断に応じて、前記ユーザ・データグラム・プロトコル（ＵＤＰ）を用いて前記メッセージを伝送すると判断するよう構成される、プログラム。

【請求項14】

前記通信の態様の前記プロパティを判断することは、
前記メッセージを伝送するよう伝送制御プロトコル（ＴＣＰ）を選択する判断；
前記メッセージを伝送するようユーザ・データグラム・プロトコル（ＵＤＰ）を選択する判断；
より小電力のネットワークを用いて、前記メッセージを通信する判断；
より高電力のネットワークを用いて、前記メッセージを通信する判断；
前記目標装置の好ましいネットワークを、前記メッセージのＩＰｖ６パケットヘッダにおいてエンコードされた拡張固有ローカルアドレス（ＥＵＬＡ）において示される、より高電力のネットワークとして選択する判断；
前記目標装置の好ましいネットワークを、前記メッセージの前記ＩＰｖ６パケットヘッダにおいてエンコードされた前記拡張固有ローカルアドレス（ＥＵＬＡ）において示される、より小電力のネットワークとして選択する判断；または
それらの任意の組合せを含む、請求項１３に記載のプログラム。

【請求項15】

前記アプリケーション層は、前記メッセージの緊急度によって伝送制御プロトコル（ＴＣＰ）またはユーザ・データグラム・プロトコル（ＵＤＰ）のどちらを用いて前記メッセージを伝送するべきであるかを判断するように構成される、請求項１３または１４に記載のプログラム。

【請求項16】

前記メッセージが装置警報を通信するとき、前記メッセージは緊急メッセージを含み、前記メッセージが装置警報なしに非危険な環境状態を示すものを通信するとき、前記メッセージは非緊急メッセージを含む、請求項１５に記載のプログラム。

【請求項17】

方法であって、
電子装置のメモリまたは記憶装置において、ネットワークスタックを動作させる命令を記憶することと、
前記電子装置のプロセッサを介して、前記ネットワークスタックを動作させる前記命令を実行することと、
前記電子装置のネットワークインターフェイスを介して、ネットワーク接続された装置のファブリックに加わることと、
前記ネットワークインターフェイスを介して、前記ネットワークスタックを用いて、前記装置のファブリックの目標装置にメッセージを通信することとを含み、前記ネットワークスタックは、
前記メッセージにおいて送信されるべきデータを含むアプリケーションペイロードを与えるよう構成されるアプリケーション層と；
前記アプリケーションペイロードを前記メッセージの一般的なメッセージフォーマットにおいてカプセル化するよう構成されるプラットフォーム層と；前記一般的なメッセージフォーマットは、タイプ－長さ－値（ＴＬＶ）フォーマットを含み、
ユーザ・データグラム・プロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）のいずれかを用いて、前記メッセージを選択可能に伝送するよう構成されたトランスポート層と；
前記メッセージを、インターネットプロトコルバージョン６（ＩＰｖ６）を用いて、
８０２．１１ワイヤレスネットワーク；
８０２．１５．４ワイヤレスネットワーク；
電力線網；
セルラーネットワーク；
イーサネットネットワーク；または
それらの任意の組合せを介して通信するよう構成されるネットワーク層とを含み、前記方法はさらに、
前記アプリケーション層、前記プラットフォーム層、前記トランスポート層、前記ネットワーク層またはそれらの任意の組合せを介した、前記目標装置への前記メッセージの通信の態様のプロパティを、
前記メッセージのタイプ；
前記メッセージが送信されることになるネットワーク；
前記メッセージが前記ファブリックを通って移動し得る距離；
前記電子装置の電力消費挙動；
前記目標装置の電力消費挙動；
前記電子装置と前記目標装置との間において前記メッセージを通信することになる、前記装置のファブリックの介在装置の電力消費挙動；
前記目標装置はサービスを含むかどうか；または
それらの任意の組合せに少なくとも部分的に基づいて判断することを含み、前記通信の態様のプロパティは、前記メッセージの通信に用いられるプロトコルのタイプを含み、
前記方法はさらに、前記メッセージを、判断した前記通信の態様のプロパティを用いて生成することを含み、
前記通信の態様の前記プロパティを変動させることは、前記電子装置、前記目標装置、もしくは前記介在装置、またはそれらの任意の組合せに、変動されるプロパティよって異なる量の電力を消費させ、前記メッセージを、前記目標装置に、より信頼性高くまたはそれほど信頼性高くなく到達させるよう構成され、前記方法はさらに、
前記電子装置が前記電子装置の外部の電源によって電力供給されるかどうかに応じて、前記電子装置の節電がメッセージ通信の信頼性よりも所望されるかを判断すること、
前記節電が前記信頼性よりも所望されるとの判断に応じて、前記ユーザ・データグラム・プロトコル（ＵＤＰ）を用いて前記メッセージを伝送すると判断することを含む、方法。

【請求項18】

前記通信の態様の前記プロパティを判断することは、
前記メッセージを伝送するよう伝送制御プロトコル（ＴＣＰ）を選択する判断；
前記メッセージを伝送するようユーザ・データグラム・プロトコル（ＵＤＰ）を選択する判断；
より小電力のネットワークを用いて、前記メッセージを通信する判断；
より高電力のネットワークを用いて、前記メッセージを通信する判断；
前記目標装置の好ましいネットワークを、前記メッセージのＩＰｖ６パケットヘッダにおいてエンコードされた拡張固有ローカルアドレス（ＥＵＬＡ）において示される、より高電力のネットワークとして選択する判断；
前記目標装置の好ましいネットワークを、前記メッセージの前記ＩＰｖ６パケットヘッダにおいてエンコードされた前記拡張固有ローカルアドレス（ＥＵＬＡ）において示される、より小電力のネットワークとして選択する判断；または
それらの任意の組合せを含む、請求項１７に記載の方法。

【請求項19】

前記メッセージの緊急度に応じて伝送制御プロトコル（ＴＣＰ）またはユーザ・データグラム・プロトコル（ＵＤＰ）のどちらを用いて前記メッセージを伝送するべきであるかを判断することを含む、請求項１７または１８に記載の方法。

【発明の詳細な説明】

【背景技術】

【0001】

背景
本開示は、小電力またはスリーピー状態装置を含むさまざまな装置が住宅ネットワークまたは同様の環境において通信することを可能にする効率的通信に関する。

【0002】

このセクションは、この技術のさまざまな局面に関係づけられ得る技術のさまざまな局面に読み手を導くよう意図され、それらの技術を以下において記載し、および／または主張する。この議論は、本開示のさまざまな局面のよりよい理解を促すために読み手に対して背景情報を提供することにおいて役立つと考えられる。したがって、これらの述べられる内容はこの観点において読まれるべきであり、先行技術を認めるものとして読まれるべきではないことが理解されるべきである。

【0003】

ネットワーク接続された装置が住宅中に現れている。これらの装置のいくつかは、転送プロトコルを用いて、単一のネットワークタイプ（たとえばWiFi（登録商標）接続）を通してお互いと通信することが可能であることが多い。バッテリにより電力を供給されるかまたは低減された充電圧を受ける一部の装置では、より電力集中型でない接続プロトコルを用いることが望まれるかもしれない。しかしながら、一部のシナリオでは、より小電力のプロトコルに接続される装置は、より高電力のプロトコル（たとえばWiFi）に接続される装置と通信することはできないかもしれない。

【0004】

さらに、多数の電子装置が、現在、ワイヤレスネットワークに対する接続が可能である。たとえば、スマートメータ技術は、ワイヤレスネットワークを用いて、居住特性と関連付けられる電気エネルギ消費データを、モニタリング、課金情報、などのためにユーティリティ会社に通信し戻す。したがって、多数のワイヤレスネットワーキング規格が、現在、電子装置が互いと通信することを可能にするよう利用可能である。一部のスマートメータ実現例は、たとえば、インターネットプロトコルバージョン６（ＩＰｖ６）を小電力ワイヤレスパーソナルエリアネットワーク（６ＬｏＷＰＡＮ）にわたって用いて、電子装置がスマートメータと通信することを可能にする。しかしながら、６ＬｏＷＰＡＮのような現在利用可能なワイヤレスネットワーキング規格は、一般的には１つ以上の実際のシナリオに対して、居所または家中に分散される電子装置をサポートするように十分には備えられていないことが一般的かもしれない。つまり、現在利用可能なワイヤレスネットワーキング規格は、１つ以上の公知の実際の制約に鑑み、安全であるが単純な、消費者に優しい態様で、ネットワークのすべての電子装置を効率的に接続しないかもしれない。さらに、１つ以上の実際のシナリオでは、現在利用可能なワイヤレスネットワーキング規格は、新たな電子装置を既存のワイヤレスネットワークにアドホックな態様で追加する効率的な方法を提供しないかもしれない。

【0005】

加えて、住宅内または住宅の周りでの使用のために電子装置のためのワイヤレスネットワーク規格を提供する際には、異なる装置がネットワークへのアクセスを得る方法を学習するよう、開いたプロトコルを提供するワイヤレスネットワーク規格を用いることが有益であろう。さらに、住宅と関連づけられ得る電子装置の数が与えられるとして、ワイヤレスネットワーク規格はインターネットプロトコルバージョン６（ＩＰｖ６）通信をサポートすることができ、各装置は、独自のＩＰアドレスを有し、インターネット（登録商標）を介して、住宅環境におけるローカルネットワークを介してなどによりアクセスされることができてもよいことは有益であろう。さらに、ワイヤレスネットワーク規格は、最小の電力量を用いて、電子装置がワイヤレスネットワーク内で通信することを可能にすることは有用であろう。これらの特徴を考慮して、１つ以上の欠点が、オープンプロトコルを有
し、住宅内および住宅の周りで電子装置のために用いられ得る小電力のＩＰｖ６ベースのワイヤレスメッシュネットワーク規格を与えるコンテキストにおいて、各公知の現在利用可能なワイヤレスネットワーキング規格によって提示されると考えられる。たとえば、Bluetooth（登録商標）、Dust Networks（登録商標）、Z-wave（登録商標）、WiFi（登録商標）、およびZigBee（登録商標）、のようなワイヤレスネットワーク規格は、上で論じた所望の特徴の１つ以上を提供しない。

【0006】

Bluetoothは、たとえば、短い距離にわたって、短波無線伝送を介して通信するための
ワイヤレスネットワーク規格を提供する。したがって、Bluetoothのワイヤレスネットワ
ーク規格は、家中に配置される多数の電子装置の通信ネットワークをサポートしないかもしれない。さらに、Bluetoothのワイヤレスネットワーク規格はワイヤレスメッシュ通信
またはＩＰｖ６アドレスをサポートしないかもしれない。

【0007】

上に言及されたように、Dust Networksによって提供されるワイヤレスネットワーク規
格も、住宅に配置された電子装置が互いと効率的に通信することを可能にするであろう１つ以上の特徴に関して、１つ以上の欠点をもたらし得る。特に、Dust Networksのワイヤ
レスネットワーク規格は、Dust Networksのネットワーク上で動作する装置とインターフ
ェイスするよう他のものによって用いられ得るオープンプロトコルを提供しないかもしれない。その代わりに、Dust Networksは、アセンブリライン、化学工場などのような産業
環境にある装置間の通信を容易にするよう設計され得る。したがって、Dust Networksの
ワイヤレスネットワーク規格は、各装置が互いと通信し、他の装置からの命令を聞くようにしてもよい予め規定された時間窓（タイムウィンドウ）を有する信頼性のある通信ネットワークを提供することに向けられ得る。この態様では、Dust Networksのワイヤレスネ
ットワーク規格は、住宅内での使用に対して消費者電子装置で実現するのが経済的ではないかもしれない、洗練されかつ相対的に高価な無線送信機を必要とするかもしれない。

【0008】

Dust Networksのワイヤレスネットワーク規格のように、Z-waveと関連づけられるワイ
ヤレスネットワーク規格はオープンプロトコルではないかもしれない。その代わりに、Z-waveのワイヤレスネットワーク規格は特定の送受信機チップを自分の装置に埋込む認証された顧客に対してのみ利用可能であり得る。さらに、Z-waveのワイヤレスネットワーク規格はＩＰｖ６ベースの通信をサポートしないかもしれない。つまり、Z-waveのワイヤレスネットワーク規格は、Z-wave装置上において生成されたデータを、インターネットを介して送信され得るＩＰベースのデータに変換するようブリッジ装置を必要とするかもしれない。

【0009】

ここで、ZigBeeのワイヤレスネットワーク規格を参照して、ZigBeeは、一般に、ZigBee（登録商標）ProおよびZigBee（登録商標）IPとして公知の２つの規格を有する。さらに
、ZigBee（登録商標）Proは、ワイヤレスメッシュネットワーキングに対するサポートの
コンテキストにおいて１つ以上の欠点を有し得る。その代わりに、ZigBee（登録商標）Proは、ZigBee（登録商標）Proネットワークにおいて各装置間において通信を容易にする中央装置に少なくとも一部依存し得る。その中央装置に対する電力要件の増大に加えて、あるワイヤレストラフィックを処理または拒絶するままであり続ける装置は、それらのハウジング内においてさらなる熱を発生させ得、それは、装置によって得られる温度読取値のような一部のセンサ読取値を変えるかもしれない。そのようなセンサ読取値は、住宅内の各装置がどのように動作し得るかを判断する際に有用であり得るので、装置内において、センサ読取値を変え得る不必要な熱の生成を回避することは有益であり得る。加えて、ZigBee（登録商標）ProはＩＰｖ６通信をサポートしないかもしれない。

【0010】

ここでZigBee（登録商標）IPを参照して、ZigBee（登録商標）IPは、直接的な装置から装置への通信の文脈において１つ以上の欠点をもたらし得る。ZigBee（登録商標）IPは、
中央ルータまたは装置への装置データの中継による通信の促進に向けられる。したがって、中央ルータまたは装置は持続的な電力供給を必要とし得、したがって、装置間の通信のための小電力手段を表わさないかもしれない。さらに、ZigBee（登録商標）IPは、単一のネットワークにおいて用いられ得るノードの数において実際的な限度を有し得る（つまりネットワークにつき～２０個のノード）。さらに、ZigBee（登録商標）IPは、高帯域、処理およびメモリ要件を示し得る「リップル」ルーティングプロトコル（ＲＰＬ）を用い、それは、ZigBee（登録商標）IPに接続される装置ごとに追加の電力を伴うかもしれない。

【0011】

上で論じたZigBeeワイヤレスネットワーク規格のように、WiFiのワイヤレスネットワークは、小出力要件を有する装置間において通信を可能にすることにおいて１つ以上の欠点を呈し得る。たとえば、WiFiのワイヤレスネットワーク規格も、各ネットワーク接続された装置が常に電源オンされることを必要とし、さらには、中央ノードまたはハブの存在を必要とし得る。当該技術分野において公知のように、WiFiは、相対的に高帯域のデータ送信（たとえばビデオをストリーミングする、装置を同期させるなど）に対して理想的であり得る、相対的に一般的なワイヤレスネットワーク規格である。したがって、WiFi装置は、装置間のデータ送信の持続的なストリームをサポートするよう、継続的な電源または再充電可能なバッテリに典型的には結合される。さらに、WiFiのワイヤレスネットワークはワイヤレスメッシュネットワーキングをサポートしないかもしれない。それでも、ＷｉＦｉは時にいくつかのより小電力プロトコルよりもよい接続性を提示し得る。

【発明の概要】

【課題を解決するための手段】

【0012】

概要
ここに開示されるある実施の形態の概要を以下に述べる。これらの局面は単に、読み手に対して、これらのある実施の形態の簡単な概要を提供するために提示されること、およびこれらの局面は本開示の範囲を限定するようには意図されないことが理解されるべきである。それどころか、本開示は、以下に述べられないかもしれないさまざまな局面を包含し得る。

【0013】

システムおよび方法は、住宅環境または同様の環境における装置のファブリックネットワークを介しての効率的な通信に対して与えられる。たとえば、電子装置は、電力および信頼性の問題のバランスをとるように通信を効率的に制御し、拡張固有ローカルアドレス（ＥＵＬＡ）を用いるインターネットプロトコルバージョン６（ＩＰｖ６）パケットヘッダの解析によって、メッセージをある好ましいネットワークに効率的に通信し、ファブリックネットワークの全体にわたって、ソフトウェア更新およびステータス報告を効率的に通信し、および／または容易かつ効率的にファブリックネットワークに加わってもよい。

【0014】

たとえば、電子装置は、ネットワークスタックを動作させる命令を記憶するメモリまたは記憶装置と；命令を実行するプロセッサと；ネットワーク接続された装置のファブリックに加わり、ネットワークスタックを用いて、装置のファブリックの目標装置にメッセージを通信するネットワークインターフェイスとを含んでもよい。ネットワークスタックは、アプリケーションペイロードに、メッセージにおいて送信されるべきデータを与えるアプリケーション層と；アプリケーションペイロードをメッセージの一般的なメッセージフォーマットにおいてカプセル化するプラットフォーム層と；ユーザ・データグラム・プロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）のいずれかを用いて、メッセージを選択可能に伝送するトランスポート層と；メッセージを、インターネットプロトコルバージョン６（ＩＰｖ６）を用いて１つ以上のネットワークを介して通信するネットワーク層とを含んでもよい。これらのネットワークは、たとえば８０２．１１ワイヤレスネットワーク、８０２．１５．４ワイヤレスネットワーク、電力線網、セルラーネットワーク、および／またはイーサネット（登録商標）ネットワークを含んでもよい。さらに、アプリ
ケーション層、プラットフォーム層、トランスポート層、および／またはネットワーク層は、目標ノードへのメッセージの通信の態様のプロパティを、メッセージのタイプ、メッセージが送信されることになるネットワーク、メッセージがファブリックを通って移動し得る距離、電子装置の電力消費挙動、目標装置の電力消費挙動、および／または電子装置と目標装置との間においてメッセージを通信することになる、装置のファブリックの介在装置の電力消費挙動に少なくとも一部基いて判断してもよい。さらに、通信の態様のプロパティを変動させることは、電子装置、目標装置、および／または介在装置に、異なる量の電力を消費させ、メッセージを、目標ノードに、より信頼性高くまたはそれほど信頼性高くなく到達させてもよい。

【0015】

別の例では、有形の、非一時的なコンピュータ読取可能媒体は、住宅環境において装置のファブリックのうちの他の電子装置に通信可能に接続される第１の電子装置によって実行されるよう含んでもよい。これらの命令は、装置のファブリックの第１のネットワークをわたって第２の電子装置から第１の電子装置でインターネットプロトコルバージョン６（ＩＰｖ６）メッセージを受信する命令を含んでもよい。メッセージは目標電子装置に向けられてもよい。命令は、さらに、メッセージのＩＰｖ６ヘッダにおいてエンコードされる拡張固有ローカルアドレスを識別する命令を含んでもよい。ここで、拡張固有ローカルアドレスは、第２のネットワークが、目標電子装置に達するのに、より好まれることを示してもよい。命令は、さらに、拡張固有ローカルアドレスに少なくとも一部基いて、第２のネットワークを用いて、メッセージを装置のファブリックを介して目標電子装置に向かって通信する命令を含んでもよい。

【0016】

ファブリックネットワークをわたってソフトウェア更新を転送する方法は、ファブリックネットワークにおける第１の装置からファブリックネットワークにおける第２の装置またはローカルサーバもしくは遠隔サーバにイメージクエリメッセージを送信することを含んでもよい。イメージクエリメッセージは、第１の装置に記憶されるソフトウェアおよび第１の装置の転送能力に関する情報を含んでもよい。イメージクエリ応答は第２の装置またはローカルサーバもしくは遠隔サーバから第１の装置によって受信されてもよい。イメージクエリ応答は、ソフトウェア更新が利用可能であり、第１の装置がソフトウェア更新をダウンロードすることを可能にするよう統一的資源識別子（ＵＲＩ）を有するダウンロード情報を含むかどうかを示してもよい。イメージクエリメッセージは、送信側装置に記憶されるソフトウェアおよび送信側装置の転送能力に関する送信側情報と更新優先度とを含んでもよい。ＵＲＩを用いて、ソフトウェア更新を第１の装置において送信側装置からダウンロードしてもよい。ソフトウェアは、更新優先度およびファブリックネットワークにおけるネットワークトラフィックに少なくとも一部基いた時間にダウンロードされてもよく、ソフトウェアは、イメージクエリおよびイメージクエリ応答において示された共通の転送能力に少なくとも一部が基いた態様でダウンロードされてもよい。

【0017】

さらなる例では、有形の、非一時的なコンピュータ読取可能媒体はステータス報告フォーマットを記憶してもよい。ステータス報告フォーマットは、複数のステータス更新タイプのうちのあるステータス更新タイプを示すプロファイルフィールドと、報告されているステータスを示すステータスコード－ステータスコードは、ステータス更新タイプに少なくとも一部が基いた態様において解釈されてもよい－と、さらなるステータスが、ステータス報告フォーマットを用いて形成されたステータス報告に含まれているかどうかを示す、次のステータスフィールドとを含んでもよい。

【0018】

電子装置の別の例は、第１の電子装置が第２の電子装置を含むファブリックネットワークと対になることを可能にするよう命令を記憶するメモリと；命令を実行するプロセッサと；８０２．１１および８０２．１５．４論理ネットワークにアクセスするネットワークインターフェイスとを含む。命令は、第１の８０２．１５．４論理ネットワークを介して
第２の電子装置と通信を確立する命令を含んでもよい。第２の電子装置は、ファブリックネットワークと対にされてもよく、ファブリックネットワークにおいて他の論理ネットワークを介してサービスと通信してもよい。命令は、さらに、第１の電子装置が第１の８０２．１１論理ネットワークに加わることを可能にするために第２の電子装置を介してサービスからネットワーク構成情報を受信する命令と；第１の８０２．１１論理ネットワークをわたって通信を確立する命令と；第１の８０２．１１論理ネットワークを介してサービスに接続する命令と；サービスとの通信を介してファブリックネットワークと対になるよう登録する命令とを含んでもよい。

【0019】

上記の特徴のさまざまな改良が本開示のさまざまな局面との関係において用いられてもよい。さらなる特徴も、同様に、これらのさまざまな局面に組入れられ得る。これらの改良およびさらなる特徴は、個々に、または任意の組合せで用いられてもよい。たとえば、以下に論じられるさまざまな特徴は、提示される実施例のうちの１つ以上との関係において、本開示の上記の局面のうちの任意のもの内に、単独または任意の組合せで組入れられ得る。上に提示された簡潔な概要は、特許請求される主題に対する限定なしに、読み手を本開示の実施の形態のある局面および文脈に馴染ませるようにのみ意図されるものである。

【0020】

図面の簡単な説明
本開示のさまざまな局面は、以下の詳細な説明を読み、かつ図面を参照することにより、よりよく理解され得る。

【図面の簡単な説明】

【0021】

【図1】ある実施の形態に従って、効率的ネットワーク層プロトコルを用いて、住宅環境内に配置される他の装置と通信し得る一般的な装置のブロック図を示す。

【図2】ある実施の形態に従って、図１の一般的な装置が効率的ネットワーク層プロトコルを介して他の装置と通信し得る住宅環境のブロック図を示す。

【図3】ある実施の形態に従って、図２の住宅環境において示される装置と関連づけられる例示的なワイヤレスメッシュネットワークを示す。

【図4】ある実施の形態に従って、図２の住宅環境に対する通信システムを特徴づける開放型システム間相互接続（ＯＳＩ）モデルのブロック図である。

【図5】ある実施の形態に従って、図４のＯＳＩモデルにおける効率的ネットワーク層の詳細図を示す。

【図6】ある実施の形態に従って、ルーティング・インフォメーション・プロトコル－ネクスト・ジェネレーション（ＲＩＰｎｇ）ネットワークをルーティング機構として図５の効率的ネットワーク層において実現するための方法のフローチャートを示す。

【図7A】ある実施の形態に従って、図６の方法のＲＩＰｎｇネットワークがどのように実現され得るかの例を示す。

【図7B】ある実施の形態に従って、図６の方法のＲＩＰｎｇネットワークがどのように実現され得るかの例を示す。

【図7C】ある実施の形態に従って、図６の方法のＲＩＰｎｇネットワークがどのように実現され得るかの例を示す。

【図7D】ある実施の形態に従って、図６の方法のＲＩＰｎｇネットワークがどのように実現され得るかの例を示す。

【図8】ある実施の形態に従って、図１の一般的な装置内にセキュリティ証明書を埋込むことを含む製造プロセスのブロック図を示す。

【図9】ある実施の形態に従って、図５の効率的ネットワーク層においてデータグラム・トランスポート・レイヤー・セキュリティ（ＤＴＬＳ）プロトコルを用いて、図２の住宅環境における装置間における例示的なハンドシェイクプロトコルを示す。

【図10】実施の形態に従って、単一の論理ネットワークトポロジを有するファブリックネットワークを示す。

【図11】実施の形態に従って、星形ネットワークトポロジを有するファブリックネットワークを示す。

【図12】実施の形態に従って、重なったネットワークトポロジを有するファブリックネットワークを示す。

【図13】実施の形態に従って、１つ以上のファブリックネットワークと通信するサービスを示す。

【図14】実施の形態に従って、ファブリックネットワークにおいて通信可能な接続状態にある２つの装置を示す。

【図15】実施の形態に従って、ファブリックネットワークにおいて装置をアドレス指定するよう用いられてもよい固有ローカルアドレスフォーマット（ＵＬＡ）を示す。

【図16】実施の形態に従って、ハブネットワーク上で周辺装置をプロキシ化するプロセスを示す。

【図17】実施の形態に従って、ファブリックネットワークによりデータを送信するために用いられてもよいタグ‐長さ‐値（ＴＬＶ）パケットを示す。

【図18】実施の形態に従って、ファブリックネットワークにより図１７のＴＬＶパケットを含んでもよいデータを送信するために用いられてもよい一般的なメッセージプロトコル（ＧＭＰ）を示す。

【図19】実施の形態に従って、図１８のＧＭＰのメッセージヘッダフィールドを示す。

【図20】実施の形態に従って、図１８のＧＭＰのキー識別子フィールドを示す。

【図21】実施の形態に従って、図１８のＧＭＰのアプリケーションペイロードフィールドを示す。

【図22】実施の形態に従って、ファブリックネットワークにおいてステータス情報を更新するために用いられてもよいステータス報告スキーマを示す。

【図23】実施の形態に従って、図２２のステータス報告スキーマのプロファイルフィールドを示す。

【図24】実施の形態に従って、クライアントとサーバとの間においてソフトウェア更新を実行するために用いられてもよいプロトコルシーケンスを示す。

【図25】実施の形態に従って、図２４のプロトコルシーケンスにおいて用いられてもよいイメージクエリフレームを示す。

【図26】実施の形態に従って、図２５のイメージクエリフレームのフレーム制御フィールドを示す。

【図27】実施の形態に従って、図２５のイメージクエリフレームの製品仕様フィールドを示す。

【図28】実施の形態に従って、図２５のイメージクエリフレームのバージョン仕様フィールドを示す。

【図29】実施の形態に従って、図２５のイメージクエリフレームのロケール仕様フィールドを示す。

【図30】実施の形態に従って、図２５のイメージクエリフレームの被サポート完全性タイプフィールドを示す。

【図31】実施の形態に従って、図２５のイメージクエリフレームの被サポート更新スキームフィールドを示す。

【図32】実施の形態に従って、図２４のプロトコルシーケンスにおいて用いられてもよいイメージクエリ応答フレームを示す。

【図33】実施の形態に従って、図３２のイメージクエリ応答フレームの統一的リソース識別子（ＵＲＩ）フィールドを示す。

【図34】実施の形態に従って、図３２のイメージクエリ応答フレームの完全性仕様フィールドを示す。

【図35】実施の形態に従って、図３２のイメージクエリ応答フレームの更新スキームフィールドを示す。

【図36】実施の形態に従って、ファブリックネットワークにおいて装置間でデータを管理するようデータ管理プロトコルを用いるよう用いられるシーケンスを示す。

【図37】実施の形態に従って、図３６のシーケンスにおいて用いられてもよいスナップショット要求フレームを示す。

【図38】実施の形態に従って、図３７のスナップショット要求フレームを用いてアクセスされてもよい例示プロファイルスキーマを示す。

【図39】実施の形態に従って、プロファイルスキーマにおいてパスを示してもよいパスのバイナリフォーマットである。

【図40】実施の形態に従って、図３６のシーケンスにおいて用いられてもよい要求監視フレームを示す。

【図41】実施の形態に従って、図３６のシーケンスにおいて用いられてもよい周期的な更新要求フレームを示す。

【図42】実施の形態に従って、図３６のシーケンスにおいて用いられてもよいリフレッシュ要求フレームを示す。

【図43】実施の形態に従って、図３６のシーケンスにおいて用いられてもよいビュー取消要求を示す。

【図44】実施の形態に従って、図３６のシーケンスにおいて用いられてもよいビュー応答フレームを示す。

【図45】実施の形態に従って、図３６のシーケンスにおいて用いられてもよい明示的な更新要求フレームを示す。

【図46】実施の形態に従って、図３６のシーケンスにおいて用いられてもよいビュー更新要求フレームを示す。

【図47】実施の形態に従って、図３６のシーケンスを用いて更新されてもよい更新項目フレームを示す。

【図48】実施の形態に従って、図３６のシーケンスにおいて更新応答メッセージとして送信されてもよい更新応答フレームを示す。

【図49】実施の形態に従って、大容量データ転送において、送信側と受信側との間において、通信可能な接続を示す。

【図50】実施の形態に従って、図４９の送信側によって通信可能な接続を開始するために用いられてもよいSendInit（送信開始）メッセージを示す。

【図51】実施の形態に従って、図５０のSendInitメッセージの転送制御フィールドを示す。

【図52】実施の形態に従って、図５１のSendInitメッセージの範囲制御フィールドを示す。

【図53】実施の形態に従って、図５０の送信側によって送信される図５０のSendInitメッセージによって提案される通信可能な接続を受入れるために用いられてもよいSendAccept（送信受容）メッセージを示す。

【図54】実施の形態に従って、図５０の送信側によって送信される図５０のSendInitメッセージによって提案される通信可能な接続を拒絶するために用いられてもよいSendReject（送信拒絶）メッセージを示す。

【図55】実施の形態に従って、図５０の受信側によって提案される通信可能な接続を受入れるために用いられてもよいReceiveAccept（受信受容）メッセージを示す。

【図56】実施の形態に従って、拡張固有ローカルアドレス（ＥＵＬＡ）を用いるＩＰｖ６パケットヘッダの例のブロック図である。

【図57】実施の形態に従って、２つのネットワークを有するファブリックトポロジを介して図５６のＩＰｖ６パケットを有するＩＰｖ６パケットを通信する例のブロック図である。

【図58】実施の形態に従って、図５６のＩＰｖ６パケットヘッダを用いて、図５７のファブリックを介してＩＰｖ６パケットを効率的に通信するための方法のフローチャートである。

【図59】実施の形態に従って、１つ以上の信頼度因子に少なくとも一部基いて、メッセージを送信する効率的なトランスポートプロトコルを選択するための方法のフローチャートである。

【図60】実施の形態に従って、１つの装置が他の装置上で方法を呼び出す、装置のファブリックの使用例を示す図である。

【図61】実施の形態に従って、警報メッセージが多くの小電力のスリーピー状態装置を通して伝播される、装置のファブリックの使用例を示す図である。

【図62】実施の形態に従って、装置のファブリック内に新たな装置を導入する方法のフローチャートである。

【図63】実施の形態に従って、装置のファブリック内に新たな装置を導入する方法のフローチャートである。

【図64】実施の形態に従って、装置のファブリック内に新たな装置を導入する方法のフローチャートである。

【図65】実施の形態に従って、装置のファブリック内に新たな装置を導入する別の方法のフローチャートである。

【図66】実施の形態に従って、装置のファブリック内に新たな装置を導入する別の方法のフローチャートである。

【図67】実施の形態に従って、装置のファブリック内に新たな装置を導入する別の方法のフローチャートである。

【発明を実施するための形態】

【0022】

詳細な説明
本開示の１つ以上の具体的な実施の形態が以下に記載される。これらの記載される実施の形態はここに開示される技術の例示に過ぎない。加えて、これらの実施の形態の簡潔な記載を与える努力において、実際の実現例のすべての特徴は本明細書には記載されないかもしれない。任意のそのような実際の実現例の開発においては、任意のエンジニアリングまたは設計プロジェクトにあるように、１つの実現例から他の実現例に変動し得る、システム関連およびビジネス関連の制約とのコンプライアンスのような、開発者の特定のゴールを達成するように、多数の実現例に特定の判断がなされなければならないことが理解されるべきである。さらに、そのような開発努力は複雑で時間のかかるものであるかもしれないが、本開示の恩恵を有する当業者にとっては、日常的な設計、組立および製造作業であろう。

【0023】

本開示のさまざまな実施の形態の要素を紹介するにあたり、冠詞「ａ」「ａｎ」および「ｔｈｅ」はそのような要素が１つ以上あることを意味するよう意図される。「備える」、「含む」、および「有する」という表現は、包含的であり、挙げられた要素以外のさらなる要素が存在し得ることを意味するよう意図される。加えて、本開示の「一実施の形態」または「ある実施の形態」に対する参照は、記載される特徴を同じく組込むさらなる実施の形態の存在を排除するよう解釈されるよう意図されるものではないことが理解されるべきである。

【0024】

ここで用いられるように、「ＨＶＡＣ」という用語は、暖房および冷房の両方、暖房のみ、冷房のみを与えるシステム、ならびに加湿、除湿および換気などのような他の居住者快適さおよび／またはコンディショニング機能を与えるシステムを含む。

【0025】

ここで用いられるように、「電力収集」、「電力共有」および「盗電」という語は、住宅装置に言及するときには、電力変換器から、機器負荷を介して、電力変換器から直接的に直接または共通の配線源を用いて電力を引出すことを指す。

【0026】

ここで用いられるように、「サーモスタット」という語は、構内の少なくとも一部内において温度および／または湿度のようなパラメータを調整するための装置またはシステムを意味する。「サーモスタット」という語は、暖房および／もしくは冷房システムのための制御ユニット、またはヒータもしくは空気清浄器のコンポーネント部分を含んでもよい。ここで用いられるように、「サーモスタット」という語は、さらに、一般的に、洗練され、カスタマイズされ、省エネルギのＨＶＡＣ制御機能を与えながらも、同時に、視覚的に魅力的であり、威圧的でなく、外観が上品で、非常に楽しく容易に用いられるよう構成され適合された、汎用性のある感知および制御ユニット（ＶＳＣＵユニット）も指し得る。

【0027】

ここで用いられるように、「ハザード検出器」という語は、火事（たとえば煙、熱、一酸化炭素）および／または他の危険な状態（たとえば極端な温度、危険なガスの蓄積など）の形跡を検出し得る任意の住宅装置を指す。

【0028】

本開示は、住宅環境において互いと通信する装置によって用いられてもよい効率的通信に関する。本開示の効率的通信は、装置および／またはサービスのファブリックが住宅環境において通信することを可能にしてもよい。実際、家で生活する消費者は、彼らの家にあるさまざまな装置のすべてが効率よく動作されるように、それらの装置の動作を調整することは有用であることを見出し得る。たとえば、サーモスタット装置を用いて、家の温度を検出し、その検出された温度に基づいて他の装置（たとえば照明）の動作を調整してもよい。サーモスタット装置は家の外の温度が日中時間に対応することを示し得る温度を検出してもよい。サーモスタット装置は、次いで、家に利用可能な日光があり得ること、およびしたがって照明を切るべきであることを、照明装置に伝えてもよい。他の例では、スマートハザード検出器は、在宅を示す環境状態を検出することができてもよい。サーモスタット装置は、これらの環境状態に対してハザード検出器に問合せしてもよく、それに従ってその動作を変動させてもよい。効率性に加えて、消費者は、一般的に、最小限の量のセットアップまたは初期化を必要とするユーザに優しい装置を好み得る。換言すれば、消費者は、一般的に、少数の初期化ステップを実行した後完全に動作可能となる装置、特に年齢または技術的熟練に関係なくほとんどどのような個人によっても実行され得るもののような装置を好み得る。

【0029】

住宅環境内において互いとの間でデータを効果的かつ効率的に通信するために、装置は、装置間で通信を管理するよう１つ以上の論理ネットワークを含むファブリックネットワークを用いてもよい。換言すれば、効率的ファブリックネットワークは、住宅内における多数の装置が１つ以上の論理ネットワークを用いて互いと通信することができるようにしてもよい。ファブリックネットワークは、たとえば、通信を管理するために効率的ネットワーク層、効率的プラットフォーム層、および／または効率的アプリケーション層を伴う効率的通信スキームによってサポートされてもよい。ファブリックネットワークは、各接続された装置が固有のローカルアドレス（ＵＬＡ）を有するように、インターネットプロトコルバージョン（ＩＰｖ６）通信をサポートしてもよい。いくつかの例では、ＩＰｖ６通信は拡張固有ローカルアドレス（ＥＵＬＡ）を用いてもよい。さらにさらに、各装置が家と統合することを可能にするためには、各装置が低量の電力を用いてネットワーク内において通信することが有用であり得る。つまり、装置が低い電力を用いて通信することを可能にすることによって、それらの装置は、継続的な電源に接続される（たとえばバッテリにより電源を供給される）ことなく、家の任意の場所に配置され得る。

【0030】

通信プロトコルの相対的により下位の層（たとえばネットワーク層）の上において、ファブリック効率的ネットワーク層は、住宅内の多数の装置がワイヤレスメッシュネットワークを介して互いと通信し得る通信ネットワークを確立してもよい。通信ネットワークは、各接続された装置が一意のインターネットプロトコル（ＩＰ）アドレスを有するように
、インターネットプロトコルバージョン６（ＩＰｖ６）通信をサポートしてもよい。さらに、各装置が家と統合することを可能にするためには、各装置が低量の電力を用いてネットワーク内において通信することが有用であり得る。つまり、装置が低い電力を用いて通信することを可能にすることによって、それらの装置は、継続的な電源に接続されることなく、家の任意の場所に配置され得る。

【0031】

効率的ネットワーク層は、したがって、通信ネットワークの確立がほとんどユーザ入力を伴わず、装置間の通信がエネルギをほとんど伴わず、通信ネットワークそれ自体が安全であるように、データを２つ以上の装置間において転送し得る手順を確立してもよい。一実施の形態では、効率的ネットワーク層は、ルーティング・インフォメーション・プロトコル－ネクスト・ジェネレーション（ＲＩＰｎｇ）をそのルーティング機構として、およびデータグラム・トランスポート・レイヤー・セキュリティ（ＤＴＬＳ）プロトコルをそのセキュリティ機構として－用いるＩＰｖ６ベースの通信ネットワークであってもよい。したがって、効率的ネットワーク層は、接続された装置間において通信される情報を保護しながら、装置を家に追加するかまたは装置を家から除去するための単純な手段を提供し得る。

【0032】

通信プロトコルの相対的により上位の層（たとえばプラットフォーム層および／またはアプリケーション層）の上において、装置のファブリックを形成し維持してもよい。これらの層は、ファブリック中において、パラメトリックソフトウェア更新およびステータス報告を可能にしてもよい。これらの層は、さらに、「スリーピー状態」またはバッテリにより電力供給される装置の電力制約のような、あるネットワーク電力制約を認識し得る通信を提供してもよく、これらのファクタを考慮してメッセージを通信してもよい。

【0033】

したがって、本開示の実施の形態は、ファブリックに接続された装置が、装置にとって既知のプロトコルおよび／またはプロファイルのリストを用いて互いと通信することができるようにする１つ以上の論理ネットワークを含むファブリックネットワークのシステムおよび方法に関する。装置間の通信は、通信する装置がファブリック内においてどの論理ネットワークに接続されるかに関わらず装置が装置間における通信を理解することができる典型的なメッセージフォーマットに従ってもよい。このメッセージフォーマット内においては、受信側装置が記憶および／または処理するために、データのペイロードが含まれてもよい。フォーマットおよびペイロードのコンテンツは、（１つ以上のプロトコルを含む）プロファイルおよび／またはそのプロファイルに従って送信されているメッセージのタイプを示すペイロード内のヘッダに従って変動してもよい。

【0034】

ある実施の形態に従うと、ファブリック内における２つ以上の装置は、ステータス報告プロトコルまたはプロファイルを用いて通信してもよい。たとえば、ある実施の形態では、ステータス報告プロトコルまたはスキーマは、ファブリックに接続される装置に利用可能なコアプロファイルに含まれてもよい。ステータス報告プロトコルを用いて、装置はファブリックにおける他の装置にステータス情報を送信し、またはそれらの装置からステータス情報を要求してもよい。

【0035】

同様に、ある実施の形態では、ファブリックにおける２つ以上の装置は更新ソフトウェアプロトコルまたはプロファイルを用いて通信してもよい。いくつかの実施の形態では、更新ソフトウェアプロトコルまたはスキーマは、ファブリックに接続される装置に利用可能なコアプロファイルに含まれてもよい。更新ソフトウェアプロトコルを用いて、装置は、ファブリック内において更新の存在を要求、送信または通知してもよい。

【0036】

ある実施の形態では、ファブリックにおける２つ以上の装置はデータ管理プロトコルまたはプロファイルを用いて通信してもよい。いくつかの実施の形態では、データ管理プロ
トコルまたはスキーマは、ファブリックに接続される装置に利用可能なコアプロファイルに含まれてもよい。更新データ管理プロトコルを用いて、装置は、他の装置に記憶されるノード常駐情報を要求、閲覧または追跡してもよい。

【0037】

さらに、ある実施の形態では、ファブリックにおける２つ以上の装置は大容量データ転送プロトコルまたはプロファイルを用いてデータを転送してもよい。いくつかの実施の形態では、大容量データ転送プロトコルまたはスキーマは、ファブリックに接続される装置に利用可能なコアプロファイルに含まれてもよい。大容量データ転送プロトコルを用いて、装置は、ファブリックにおける任意の論理ネットワークを用いて大容量データを開始、送信または受信してもよい。ある実施の形態では、大容量データ転送プロトコルを用いる受信側または送信側装置は装置間で同期転送を「駆動」できてもよい。他の実施の形態では、大容量転送は非同期転送で実行されてもよい。

【0038】

ファブリック導入
導入として、図１は、住宅環境内における他の同様の装置と通信し得る一般的な装置１０の例を図示する。一実施の形態では、装置１０は、１つ以上のセンサ１２、ユーザインターフェイスコンポーネント１４、電源１６（たとえば電力接続および／またはバッテリを含む）、ネットワークインターフェイス１８、プロセッサ２０などを含み得る。特定のセンサ１２、ユーザインターフェイスコンポーネント１４および電源構成は、各装置１０で同じまたは類似してもよい。しかしながら、いくつかの実施の形態では、各装置１０は、装置タイプまたはモデルに基いて、特定のセンサ１２、ユーザインターフェイスコンポーネント１４および電源構成などを含んでもよいことが注目されるべきである。

【0039】

センサ１２は、ある実施の形態では、加速度、温度、湿度、水、供給電力、近接度、外部の動き、装置の動き、音声信号、超音波信号、光信号、炎、煙、一酸化炭素、全地球測位システム（ＧＰＳ）信号、無線周波数（ＲＦ）、他の電磁信号または電磁場等のようなさまざまな特性を検出してもよい。したがって、センサ１２は、温度センサ、湿度センサ、ハザード関連センサまたは他の環境的センサ、加速度計、マイクロフォン、光学センサを、カメラ（たとえば、電荷結合素子もしくはビデオカメラ）、能動的もしくは受動的輻射センサ、ＧＰＳレシーバまたは無線周波数識別検出器まで、およびそれらを含んで、含んでもよい。図１は単一のセンサを伴う実施の形態を示すが、多くの実施の形態は複数のセンサを含んでもよい。ある例では、装置１０は１つ以上の一次センサおよび１つ以上の二次センサを含んでもよい。ここで、一次センサは、装置のコア動作（たとえばサーモスタットにおいて温度を検知することまたは煙検出器において煙を検知することなど）に対して中心のデータを検知してもよく、一方、二次センサは、他のタイプのデータ（たとえば動き、光または音）を検知してもよく、それをエネルギ効率目的またはスマート動作目的のために用いることができる。

【0040】

装置１０における１つ以上のユーザインターフェイスコンポーネント１４はユーザから入力を受取ってもよく、および／またはユーザに対して情報を提示してもよい。受取られた入力を用いて設定を判断してもよい。ある実施の形態では、ユーザインターフェイスコンポーネントは、ユーザの動きに応答する機械的コンポーネントまたは仮想コンポーネントを含んでもよい。たとえば、ユーザは、摺動するコンポーネントを（たとえば垂直トラックまたは水平トラックに沿って）機械的に移動させるか、もしくは回転可能なリングを（円形のトラックに沿って）回転させることができ、またはタッチパッドに沿ったユーザの動きを検出してもよい。そのような動きは設定の調整に対応してもよく、それは、ユーザインターフェイスコンポーネント１０４の絶対的な位置またはユーザインターフェイスコンポーネント１０４の変位に基づいて判断することができる（たとえば回転可能リングコンポーネントの１０度の回転ごとに１°Ｆだけ設定点温度を調整することなど）。物理的な可動ユーザインターフェイスコンポーネントおよび仮想可動ユーザインターフェイス
コンポーネントは、ユーザが、明らかな連続体の一部に沿って設定することを可能にすることができる。したがって、ユーザは、（たとえばアップボタンおよびダウンボタンが用いられる場合にそうであるように）２つの別個のオプションの間で選択を行なうことに制限されなくてもよく、可能な設定値の範囲に沿って設定を迅速かつ直感的に規定することができる。たとえば、ユーザインターフェイスコンポーネントのある移動のある大きさはある設定調整のある大きさと関連づけられてもよく、ユーザは設定を大きな移動で劇的に変えたり、設定を小さな移動で微調整してもよい。

【0041】

ユーザインターフェイスコンポーネント１４は、さらに、１つ以上のボタン（たとえばアップボタンおよびダウンボタン）、キーパッド、数値パッド、スイッチ、マイクロホン、および／またはカメラ（例えば、身振りを検出するために）を含んでもよい。一実施の形態では、ユーザインターフェイスコンポーネント１４はクリックおよび回転環状リングコンポーネントを含んでもよく、ユーザは、（たとえば設定を調整するよう）リングを回転することによって、および／または（たとえば調整された設定を選択するかもしくはオプションを選択するよう）リングを内方向にクリックすることによって、そのコンポーネントと対話することを可能にしてもよい。別の実施の形態では、ユーザインターフェイスコンポーネント１４は、カメラを含んでもよく、（たとえば装置の出力またはアラーム状態が変更されることになる旨を示すべく）身振り（ジェスチャ）を検出してもよい。いくつかの例では、装置１０は１つの一次入力コンポーネントを有してもよく、それを用いて複数のタイプの設定を設定してもよい。ユーザインターフェイスコンポーネント１４は、さらに、情報を、ユーザに対して、たとえば視覚ディスプレイ（たとえば薄膜トランジスタディスプレイまたは有機発光ダイオードディスプレイ）および／または音声スピーカを介して提示するよう構成されてもよい。

【0042】

電源コンポーネント１６は、電力接続および／またはローカルバッテリを含んでもよい。たとえば、電力接続は、装置１０を、線間電圧源のような電源に接続してもよい。いくつかの例では、ＡＣ電源を用いて、（たとえば再充電可能な）ローカルバッテリを繰返し充電し得、バッテリは、後で、ＡＣ電源が利用可能でないときに装置１０に電力を供給するよう用いられてもよい。

【0043】

ネットワークインターフェイス１８は装置１０が装置間で通信することを可能にするコンポーネントを含んでもよい。一実施の形態では、ネットワークインターフェイス１８は、効率的ネットワーク層をその開放型システム間相互接続（ＯＳＩ）モデルの一部として用いて通信してもよい。一実施の形態では、効率的ネットワーク層は、以下において図５を参照して詳細に記載されるが、装置１０が、ＲＩＰｎｇルーティング機構およびＤＴＬＳセキュリティスキームを用いて、ＩＰｖ６タイプのデータまたはトラフィックをワイヤレスで通信することを可能にしてもよい。したがって、ネットワークインターフェイス１８はワイヤレスカードまたは何らかの他の送受信機接続を含んでもよい。

【0044】

プロセッサ２０は、さまざまな異なる装置機能のうちの１つ以上をサポートしてもよい。したがって、プロセッサ２０は、ここに記載される機能の１つ以上を実行および／または実行させられるよう構成ならびにプログラミングされる１つ以上のプロセッサを含んでもよい。一実施の形態では、プロセッサ２０は、ローカルメモリ（たとえばフラッシュメモリ、ハードドライブ、ランダムアクセスメモリ）に記憶されるコンピュータコードを実行する汎用プロセッサ、専用プロセッサもしくは特定用途向け集積回路、それらの組合せを含んでもよく、 および／または他のタイプのハードウェア／ファームウェア／ソフトウェア処理プラットフォームを用いてもよい。さらに、プロセッサ２０は、非同期Ｊａｖａｓｃｒｉｐｔ（登録商標）およびＸＭＬ（ＡＪＡＸ）または同様のプロトコルを用いて、クラウドサーバから与えられる命令を実行するＪａｖａ（登録商標）仮想マシン（ＪＶＭ）を動作させることなどによって、中央サーバまたはクラウドベースのシステムによっ
て遠隔で実行または司られるアルゴリズムのローカル化されたバージョンまたは対応物として実現されてもよい。例として、プロセッサ２０は、ある場所（たとえば家屋または部屋）がある特定の人物によって占有されるかもしくは（たとえば１つ以上のしきい値に関して）ある特定数の人々によって占有されるかどうかまで、ならびにそれを含んで、その場所がいつ占有されるかを検出してもよい。一実施の形態では、この検出は、たとえば、マイクロフォン信号を解析すること、（たとえば装置の前における）ユーザの移動を検出すること、扉もしくはガレージ扉の開閉を検出すること、ワイヤレス信号を検出すること、受信された信号のＩＰアドレスを検出すること、またはある時間窓内で１つ以上の装置の動作を検出することなどによって生じ得る。さらに、プロセッサ２０は、特定の居住者または物体を識別するよう、画像認識技術を含んでもよい。

【0045】

ある実施の形態では、プロセッサ２０は、さらに、高消費電力プロセッサおよび低消費電力プロセッサを含んでもよい。高消費電力プロセッサは、ユーザインターフェイスコンポーネント１４などを動作させるような、計算集中型動作を実行してもよい。低消費電力プロセッサは、逆に、センサ１２からの危険または温度を検出するなどのような、より複雑でないプロセスを管理してもよい。一実施の形態では、低消費電力プロセッサは、計算集中型プロセスのために高消費電力プロセッサを起動するかまたは初期化してもよい。

【0046】

いくつかの例では、プロセッサ２０は、望ましい設定を予測、および／またはそれらの設定を実現してもよい。たとえば、存在検出に基づいて、プロセッサ２０は、たとえば、家もしくはある特定の部屋に誰もいないときに電力を節約するよう、またはユーザの好み（たとえば一般的な住宅での好みもしくはユーザに特定の好み）に従って、装置設定を調整してもよい。別の例として、特定の人物、動物または物体（たとえば子供、ペットまたは紛失した物体）の検出に基づいて、プロセッサ２０は、その人物、動物または物体がどこにあるかの音声インジケータもしくは視覚インジケータを起動してもよく、または認識されない人物がある条件下（たとえば夜もしくは照明が消えているときに）検出される場合にアラームもしくはセキュリティ特徴を起動させてもよい。

【0047】

ある例では、装置は、第１の装置によって検出されるイベントが第２の装置の動作に影響を与えるように、互いと対話してもよい。たとえば、第１の装置は、（たとえばガレージにおいて動きを検出すること、ガレージにおいて照明における変化を検出すること、またはガレージ扉が開かれたことを検出することによって）ユーザがガレージに入ってきたことを検出し得る。第１の装置はこの情報を第２の装置に効率的ネットワーク層を介して送信し、第２の装置は、たとえば、家屋温度設定、照明設定、音楽設定、および／またはセキュリティアラーム設定を調整し得る。別の例として、第１の装置は（たとえば動きまたは突然の光パターンの変化を検出することによって）ユーザが玄関に接近するのを検出し得る。第１の装置は、（たとえばドアベルの音のような）一般的な音声もしくは視覚信号を出力させ、または（たとえば訪問者の存在を、ユーザが占有している部屋内において知らせるよう）場所に特化した音声もしくは視覚信号を出力させてもよい。

【0048】

例として、装置１０はNest（登録商標）学習サーモスタットのようなサーモスタットを含んでもよい。ここで、サーモスタットは、温度センサ、湿度センサなどのようなセンサ１２を含んでもよく、サーモスタットは、そのサーモスタットが配置される建物内における現在の環境状態を判断してもよい。サーモスタットのための電源コンポーネント１６は、サーモスタットが継続的な電源の近くに配置されることを考えることなく、建物内の任意の場所に配置され得るように、ローカルバッテリであってもよい。サーモスタットはローカルバッテリを用いて電力を供給され得るので、サーモスタットは、バッテリがめったに取替えられないように、そのエネルギ使用を最小限にし得る。

【0049】

一実施の形態では、サーモスタットは、回転可能なリングがその上にユーザインターフ
ェイスコンポーネント１４として配置される円形のトラックを含んでもよい。したがって、サーモスタットが暖房、換気、空調（ＨＶＡＣ）ユニットなどを制御することによって建物の温度を制御するように、ユーザは、回転可能なリングを用いて、サーモスタットと対話するかまたはサーモスタットをプログラミングしてもよい。ある例では、サーモスタットは、そのプログラミングに基づいて、建物に人がいないかもしれないときを判断してもよい。たとえば、ＨＶＡＣユニットを延長された時間期間の間電源オフにされるよう保持するようにサーモスタットがプログラミングされる場合には、サーモスタットは、建物にはその時間期間の間人がいないことになる、と判断してもよい。ここで、サーモスタットは、建物に人がいないと判断したときには照明スイッチまたは他の電子装置をオフにするようプログラミングされてもよい。したがって、サーモスタットはネットワークインターフェイス１８を用いて照明スイッチ装置と通信して、建物に人がいないと判断されたときに照明スイッチ装置に信号を送るようにしてもよい。この態様で、サーモスタットは、建物のエネルギ使用を効率的に管理し得る。

【0050】

前述のことを考慮して、図２は、図１の装置１０が効率的ネットワーク層を介して他の装置と通信してもよい住宅環境３０のブロック図を示す。示される住宅環境３０は、家屋、オフィスビルディング、ガレージ、移動住宅などの構造物３２を含んでもよい。アパート、コンドミニアムおよびオフィス空間などのような全体構造３２を含まない住宅環境にも装置を統合することができることが十分に理解される。さらに、住宅環境３０は、実際の構造物３２の外の装置を制御し、および／またはそれに接続されてもよい。実際、住宅環境３０におけるいくつかの装置は、物理的に構造物３２内にある必要が全くない。たとえば、プールヒータ３４または潅漑システム３６を制御する装置は、構造物３２の外部に位置してもよい。

【0051】

示される構造物３２は、互いから壁４０を介して少なくとも部分的に分離されるある数の部屋３８を含む。壁４０は内壁または外壁を含み得る。各部屋３８は、さらに、床４２および天井４４を含み得る。装置は、壁４０、床４２または天井４４上に取付けられるか、それ（ら）と統合されるか、および／またはそれ（ら）によって支持され得る。

【0052】

住宅環境３０は、さまざまな有用な住宅目的のうちの任意のものを与えるよう、互いと、および／またはクラウドベースのサーバシステムと途切れ目なく統合し得るインテリジェントな、マルチ検知の、ネットワーク接続された装置を含む、複数の装置を含んでもよい。住宅環境３０に示される装置の１つ、２つ以上、または各々は、１つ以上のセンサ１２、ユーザインターフェイス１４、電源１６、ネットワークインターフェイス１８、プロセッサ２０などを含んでもよい。

【0053】

例示的装置１０は、Nest Labs IncによるＮｅｓｔ（登録商標）学習サーモスタット－
第１世代Ｔ１００５７７またはＮｅｓｔ（登録商標）学習サーモスタット－第２世代Ｔ２００５７７のような、ネットワーク接続されたサーモスタット４６を含んでもよい。サーモスタット４６は、大気における環境特性（たとえば温度および／または湿度）を検出し、暖房、換気および空調（ＨＶＡＣ）システム４８を制御してもよい。他の例示的装置１０は、Ｎｅｓｔ（登録商標）によるハザード検出ユニットなどのようなハザード検出ユニット５０を含んでもよい。ハザード検出ユニット５０は、家屋環境３０における危険な物質および／または危険な状態（たとえば煙、炎または一酸化炭素）の存在を検出してもよい。加えて、エントリウェイインターフェイス装置５２は、「スマートドアベル」とも称され得、ある場所への人の接近もしくはある場所からの人の退去を検出し、可聴機能を制御し、音声手段もしくは視覚手段を介して人の接近もしくは退去を知らせ、またはセキュリティシステムにおける設定を制御して（たとえばセキュリティシステムを起動または停止させる）ことが可能である。

【0054】

ある実施の形態では、装置１０は、照明スイッチ５４を含んでもよく、それは、周囲の照明状態を検出し、部屋占有状態を検出し、ならびに１つ以上の照明の出力および／または薄暗い状態を制御してもよい。いくつかの例では、照明スイッチ５４は、天井ファンなどのファンの出力状態または速度を制御してもよい。

【0055】

加えて、壁プラグインターフェイス５６は、部屋または構内の占有を検出し、（たとえば家に誰もいない場合には電力がプラグに供給されないように）１つ以上の壁プラグに対する電力の供給を制御してもよい。住宅環境３０内の装置１０は、さらに、冷蔵庫、ストーブおよび／またはオーブン、テレビ、洗濯機、乾燥機、照明（構造物３２の内部および／または外部）、ステレオ、インターコムシステム、ガレージ扉開閉器、床ファン、天井ファン、全家屋ファン、壁空調装置、プールヒータ３４、潅漑システム３６、セキュリティシステムなどのような機器５８を含んでもよい。図２の説明は、特定の装置に関連付けられる特定のセンサおよび機能を識別し得るが、（本明細書を通して記載されるもののような）さまざまなセンサおよび機能のうちの任意のものを装置１０内に統合してもよいことが理解される。

【0056】

処理および検知能力を含むことに加えて、上記の例示的装置の各々は、任意の他の装置、および世界中の任意の場所でネットワーク接続される任意のクラウドサーバまたは任意の他の装置とのデータ通信および情報共有が可能であってもよい。１つの実施の形態では、装置１０は、図５を参照して以下に論じられる効率的ネットワーク層を介して通信を送受してもよい。１つの実施の形態では、効率的ネットワーク層は装置１０が互いとワイヤレスメッシュネットワークを介して通信できるようにしてもよい。したがって、ある装置はワイヤレスリピータとして働いてもよく、および／または住宅環境において互いに直接接続（つまり１つのホップ）されなくてもよい装置間においてブリッジとして機能してもよい。

【0057】

１つの実施の形態では、ワイヤレスルータ６０は、さらに、住宅環境３０においてワイヤレスメッシュネットワークを介して装置１０と通信してもよい。次いで、各装置１０がインターネット６２を介して中央サーバまたはクラウドコンピューティングシステム６４と通信するように、ワイヤレスルータ６０はインターネット６２と通信してもよい。中央サーバまたはクラウドコンピューティングシステム６４は、特定の装置１０と関連付けられる製造業者、サポートエンティティまたはサービスプロバイダと関連付けられてもよい。したがって、一実施の形態では、ユーザは、電話またはインターネット接続されたコンピュータなどのような何らかの他の通信手段を用いずに、装置それ自体を用いてカスタマーサポートと連絡をとってもよい。さらに、ソフトウエア更新を、中央サーバまたはクラウドコンピューティングシステム６４から装置に（例えば、利用可能なとき、購入されたとき、またはルーチン間隔で）自動的に送ることができる。

【0058】

ネットワーク接続性により、１つ以上の装置１０は、さらに、たとえユーザが装置の近くにいなくても、ユーザがその装置と対話することを可能してもよい。たとえば、ユーザは、コンピュータ（たとえばデスクトップコンピュータ、ラップトップコンピュータもしくはタブレット）または他の携帯電子装置（たとえばスマートフォン）６６を用いて装置と通信してもよい。ウェブページまたはアプリケーションはユーザから通信を受け、受信された通信に基いて装置１０を制御してもよい。さらに、ウェブページまたはアプリケーションは、装置の動作についての情報をユーザに呈示してもよい。たとえば、ユーザは、装置のための現在の設定点温度を見て、インターネット６２に接続され得るコンピュータを用いて、それを調整することができる。この例では、サーモスタット４６は効率的ネットワーク層を用いて形成されたワイヤレスメッシュネットワークを介して現在の設定点温度閲覧要求を受けてもよい。

【0059】

ある実施の形態では、住宅環境３０は、さらに、壁プラグインターフェイス５６によって、粗くではあるが（ＯＮ／ＯＦＦ）、制御され得る、古い従来の洗濯機／乾燥機、冷蔵庫などのような、さまざまな、通信を行なわない、旧来の機器６８を含んでもよい。住宅環境３０は、さらに、ハザード検出ユニット５０もしくは照明スイッチ５４によって与えられるＩＲ（赤外線）信号によって制御され得る、ＩＲ制御される壁空調機または他のＩＲ制御される装置のような、さまざまな、部分的に通信を行なう旧来の機器７０を含んでもよい。

【0060】

上で言及されたように、上記の例示的な装置１０の各々は、データが各装置１０に通信されるように、ワイヤレスメッシュネットワークを確立してもよい。図２の例示的な装置を考慮して、図３は、上に記載される例示的装置のいくつかの間において通信を容易にするよう用いられてもよい例示的なワイヤレスメッシュネットワーク８０を示す。図３に示されるように、サーモスタット４６は、プラグインターフェイス５６への直接的なワイヤレス接続を有してもよく、プラグインターフェイス５６は、ハザード検出ユニット５０および照明スイッチ５４にワイヤレスで接続されてもよい。同じ態様で、照明スイッチ５４は機器５８および携帯電子装置６６に無線で接続されてもよい。機器５８は単にプールヒータ３４に接続されてもよく、携帯電子装置６６は単に灌漑システム３６に接続されてもよい。灌漑システム３６はエントリウェイインターフェイス装置５２へのワイヤレス接続を有してもよい。図３のワイヤレスメッシュネットワーク８０における各装置は、ワイヤレスメッシュネットワーク８０内におけるノードに対応してもよい。一実施の形態では、効率的ネットワーク層は、データがノード間において最小数のホップを介して宛先ノードに安全に転送されるように、ＲＩＰｎｇプロトコルおよびＤＴＬＳプロトコルを用いて各ノードがデータを送信することを規定してもよい。

【0061】

一般的に、効率的ネットワーク層は、図４に示されるように開放型システム間相互接続（ＯＳＩ）モデル９０の一部であってもよい。ＯＳＩモデル９０は、抽象化層に関する通信システムの機能を示す。つまり、ＯＳＩモデルは、ネットワーキングフレームワーク、または装置間の通信がどのように実現され得るかを規定してもよい。一実施の形態では、ＯＳＩモデルは６つの層、つまり物理層９２、データリンク層９４、ネットワーク層９６、トランスポート層９８、プラットフォーム層１００、およびアプリケーション層１０２を含んでもよい。一般に、ＯＳＩモデル９０における各層は、その上の層に従ってもよく、その下の層に従われてもよい。少なくともいくつかの実施の形態では、より上位の層はより下位の層において用いられる技術に寛容であってもよい。たとえば、ある実施の形態では、プラットフォーム層１００はネットワーク層９６において用いられるネットワークタイプに寛容であってもよい。

【0062】

このことを考慮して、物理層９２は、互いと通信し得る装置のためのハードウェア仕様を与えてもよい。したがって、物理層９２は、どのように装置が互いと接続し、どのように通信リソースがそれらの装置間で共有され得るかを管理することをどのように支援するかなどを確立してもよい。

【0063】

データリンク層９４は、どのようにしてデータが装置間において転送され得るかを規定してもよい。一般に、データリンク層９４は、送信されているデータパケットが伝送プロトコルの一部としてビットにエンコードおよびデコードされ得る態様を与えてもよい。

【0064】

ネットワーク層９６は、宛先ノードに転送されているデータがどのようにルーティングされるかを規定してもよい。ネットワーク層９６は、さらに、転送されているデータの完全性を維持し得るセキュリティプロトコルを提供してもよい。

【0065】

トランスポート層９８は、ソースノードから宛先ノードへのデータのトランスペアレン
トな転送を規定してもよい。トランスポート層９８は、さらに、トランスペアレントなデータの転送がどのようにして信頼性のあるままであるかを制御してもよい。したがって、トランスポート層９８を用いて、宛先ノードに転送されるよう意図されるデータパケットが実際に宛先ノードに到達したことを検証してもよい。トランスポート層９８において用いられてもよい例示的なプロトコルは、伝送制御プロトコル（ＴＣＰ）およびユーザ・データグラム・プロトコル（ＵＤＰ）を含んでもよい。

【0066】

プラットフォーム層１００は、トランスポート層９８内において規定されるプロトコルに従って装置間の接続を確立してもよい。プラットフォーム層１００は、さらに、データパケットを、アプリケーション層１０２が用い得る形式に変換してもよい。アプリケーション層１０２は、ユーザと直接インターフェイスし得るソフトウェアアプリケーションをサポートしてもよい。したがって、アプリケーション層１０２は、ソフトウェアアプリケーションによって規定されるプロトコルを実現してもよい。たとえば、ソフトウェアアプリケーションは、ファイル転送、電子メールなどのサービスを与えてもよい。

【0067】

効率的ネットワーク層
ここで図５を参照して、一実施の形態では、ネットワーク層９６およびトランスポート層９８は、ある態様で構成されて、効率的な小電力ワイヤレスパーソナルネットワーク（ＥＬｏＷＰＡＮ）１１０を形成してもよい。一実施の形態では、ＥＬｏＷＰＡＮ１１０はＩＥＥＥ８０２．１５．４ネットワークに基づいてもよく、それは低速のワイヤレスパーソナルエリアネットワーク（ＬＲ－ＷＰＡＮ）と対応してもよい。ＥＬｏＷＰＡＮ１１０は、ネットワーク層９６が、インターネットプロトコルバージョン６（ＩＰｖ６）に基づいた通信プロトコルを用いて、住宅環境３０において装置１０間でデータをルーティングし得ることを規定してもよい。したがって、各装置１０は、それ自体を、インターネット、住宅環境３０の周りのローカルネットワークなどの上で識別するよう用いられる独自のアドレスを各装置１０に与え得る１２８ビットのＩＰｖ６アドレスを含んでもよい。

【0068】

一実施の形態では、ネットワーク層９６は、ルーティング・インフォメーション・プロトコル－ネクスト・ジェネレーション（ＲＩＰｎｇ）を用いて、装置間でデータをルーティングし得ることを規定してもよい。ＲＩＰｎｇは、ソースノードと宛先ノードとの間におけるホップ数に基づいてワイヤレスメッシュネットワークを介してデータをルーティングするルーティングプロトコルである。つまり、ＲＩＰｎｇは、データがどのようにルーティングされるかを判断する際に最小のホップ数を用いる、ソースノードから宛先ノードへのルートを判断してもよい。ワイヤレスメッシュネットワークを介するデータ転送をサポートすることに加えて、ＲＩＰｎｇは、ＩＰｖ６ネットワーキングトラフィックをサポートすることができる。したがって、各装置１０は、データをルーティングする際に、独自のＩＰｖ６アドレスを用いてそれ自体を識別し、独自のＩＰｖ６アドレスを用いて宛先ノードを識別してもよい。ＲＩＰｎｇがどのようにしてデータをノード間において送信するかに関するさらなる詳細は、以下において図６を参照して記載される。

【0069】

上で述べたように、ネットワーク層９６は、さらに、転送されているデータの完全性を管理し得るセキュリティプロトコルを提供してもよい。ここでは、効率的ネットワーク層は、データグラム・トランスポート・レイヤー・セキュリティ（ＤＴＬＳ）プロトコルを用いて、装置間で転送されるデータを保護してもよい。一般的に、トランスポートレイヤセキュリティ（ＴＬＳ）プロトコルは、一般的には、インターネットを介するデータ転送を保護するよう用いられる。しかしながら、ＴＬＳプロトコルが効果的であるためには、ＴＬＳプロトコルは、伝送制御プロトコル（ＴＣＰ）のような信頼性のあるトランスポートチャネルを用いてデータを伝送してもよい。ＤＴＬＳは、ユーザ・データグラム・プロトコル（ＵＤＰ）のようなより信頼性の低いトランスポートチャネルをサポートしながら、転送されるデータに対して同様のセキュリティレベルを与える。ＤＴＬＳプロトコルに
関するさらなる詳細は、以下において図８および図９を参照して記載される。

【0070】

図５に示されるネットワーク層９６は、ここにおいては、上記の効率的ネットワーク層として特徴づけられる。つまり、効率的ネットワーク層は、ＲＩＰｎｇを用いてＩＰｖ６データをルーティングし、ＤＴＬＳプロトコルを用いて、ルーティングされたデータを保護する。効率的ネットワーク層はＤＴＬＳプロトコルを用いて装置間のデータ転送を保護するので、トランスポート層９８は、データのためにＴＣＰおよびＵＤＰ転送スキームをサポートしてもよい。

【0071】

ここで図６を参照して、図６は、ＲＩＰｎｇを用いて図３のワイヤレスメッシュネットワーク８０において各装置１０ごとにルーティングテーブルを判断するために用いられてもよい方法１２０のフローチャートを示す。方法１２０は、ワイヤレスメッシュネットワーク８０における各ノードがどのようにしてお互いに接続され得るかを示すルーティングテーブルを各装置１０が生成するように、住宅環境３０内において各装置１０によって実行されてもよい。したがって、各装置１０は、データをどのようにして宛先ノードにルーティングするかを独立して判断してもよい。一実施の形態では、装置１０のプロセッサ２０は、ネットワークインターフェイス１８を用いて方法１２０を実行してもよい。したがって、装置１０は、センサ１２と関連づけられるかまたはプロセッサ１８によって判断されるデータを、住宅環境３０内において他の装置１０にネットワークインターフェイス１８を介して送ってもよい。

【0072】

方法１２０についての以下の議論は、方法１２０のさまざまなブロックを明確に示すよう、図７Ａ～図７Ｄを参照して記載される。このことを考慮して、ならびに図６および図７Ａの両方を参照して、ブロック１２２において、装置１０は、要求側装置１０に対して直接的（つまり０ホップ）であってもよい任意の他の装置に要求１３２を送ってもよい。要求１３２は、それぞれの装置１０からのルーティング情報のすべてに対する要求を含む。たとえば、図７Ａを参照して、ノード１の装置１０はノード２の装置１０に対して、ノード２のメモリに含まれるルートのすべて（つまりＮ２のルート）を送るよう要求１３２を送ってもよい。

【0073】

ブロック１２４で、要求側装置１０は、それぞれの装置１０から、それぞれの装置１０のそれぞれのメモリに含まれるルートのすべてを含み得るメッセージを受取ってもよい。ルートは、ワイヤレスメッシュネットワーク８０における各ノードがどのように互いに接続され得るかを規定してもよいルーティングテーブルに整理されてもよい。つまり、ルーティングテーブルは、データがソースノードから宛先ノードへのように、どの中間ノードにデータが転送されてもよいかを規定してもよい。上記の例および図７Ｂを再び参照して、Ｎ２のルートに対するノード１の要求に応答して、ブロック１２４において、ノード２は、ノード１に対して、ノード２のメモリまたはストレージに含まれるルートのすべて（Ｎ２のルート１４４）を送ってもよい。一実施の形態では、ワイヤレスメッシュネットワーク８０の各ノードは要求１３２をその近隣のノードに図７Ａに示されるように送ってもよい。応答して、各ノードは、次いで、そのルートをその近隣のノードに図７Ｂに示されるように送ってもよい。たとえば、図７Ｂは、Ｎ１のルート１４２、Ｎ２のルート１４４、Ｎ３のルート１４６、Ｎ４のルート１４８、Ｎ５のルート１５０、Ｎ６のルート１５２、Ｎ７のルート１５４、Ｎ８のルート１５６、およびＮ９のルート１５８で示されるように、どのようにして各ノードがそのルートデータを各近隣のノードに送るかを示す。

【0074】

まず、各ノードは、各ノードが直接的な接続（つまり０ホップ）を有し得るノードを知っていてもよい。たとえば、まず、ノード２は、単に、それはノード１、ノード３、およびノード４に直接接続されることを知っているだけでもよい。しかしながら、Ｎ１のルート１４２、Ｎ３のルート１４６、およびＮ４のルート１４８を受取った後、ノード２のプ
ロセッサ２０は、Ｎ１のルート１４２、Ｎ３のルート１４６、およびＮ４のルート１４８とともに含まれる情報のすべてを含むルーティングテーブルを構築してもよい。したがって、次にノード２がそのルートまたはルーティングテーブル（つまりＮ２のルート１４４）に対する要求を受取るときには、ノード２は、Ｎ１のルート１４２、Ｎ２のルート１４４、Ｎ３のルート１４６、およびＮ４のルート１４８を含むルーティングテーブルを送ってもよい。

【0075】

このことを考慮して、および図６を再び参照して、ブロック１２６では、要求側装置１０は、近隣の装置から受取られるルーティング情報を含むように、そのローカルのルーティングテーブルを更新してもよい。ある実施の形態では、ワイヤレスメッシュネットワーク８０における各ノードがどのように互いに接続され得るかを特徴づける更新されたルーティングテーブルを各装置１０が含むように、各装置１０は方法１２０を周期的に実行してもよい。上記されたように、方法２０が実行されるたびごとに、各装置１０は、近隣の装置１０がそのルーティングテーブルをその近隣の装置１０から受取られる情報で更新した場合には、その近隣の装置１０からさらなる情報を受取ってもよい。その結果、各装置１０は、ワイヤレスメッシュネットワーク８０における各ノードがどのように互いに接続され得るかを理解してもよい。

【0076】

図７Ｃは、たとえば、方法１２０を用いてノード１における装置１０によって判断されたかもしれないルーティングテーブル１７２を示す。この例では、ルーティングテーブル１７２は、宛先ノードとしてのワイヤレスメッシュネットワーク８０における各ノード、ノード１と各宛先ノードとの間における中間ノード、およびノード１と宛先ノードとの間におけるホップ数を規定してもよい。ホップ数は、宛先ノードに送られているデータが宛先ノードに達する前に中間ノードに転送され得る回数に対応する。データをある特定の宛先ノードに送る際、ＲＩＰｎｇルーティングスキームは、最小数のホップを伴うルートを選択してもよい。たとえば、ノード１がデータをノード９に送ろうとする場合には、ＲＩＰｎｇルーティングスキームは、５つのホップを含むノード２、４、６、７および８を介してデータを経路づけることとは対照的に、４つのホップを含むノード２、４、５および８を介してデータをルーティングするであろう。

【0077】

ＲＩＰｎｇルーティングスキームを用いることによって、各装置１０は、データがどのようにして宛先ノードにルーティングされるべきであるかを独立して判断してもよい。６ＬｏＷＰＡＮ装置において用いられる「リップル」ルーティングプロトコル（ＲＰＬ）のような従来のルーティングスキームは、逆に、データを中央ノードを介してルーティングし得るが、中央ノードは、ワイヤレスメッシュネットワークの構造を知る唯一のノードであり得る。より具体的には、ＲＰＬプロトコルはワイヤレスメッシュネットワークを有向非巡回グラフ（ＤＡＧ）に従って形成し得るが、それは階層として構造化され得る。この階層の一番上に位置されるのは、ボーダールータを含み得、それは要求を下位レベルノードに周期的に同報通信して、ノードの接続の各々ごとにランクを判断し得る。本質的には、データがソースノードから宛先ノードに転送されるときに、データはノードの階層を上って転送され、次いで、宛先ノードに下って戻り得る。この態様で、階層においてより上位に位置するノードは階層において下位に位置するノードよりも頻繁にデータをルーティングし得る。さらに、ＲＰＬシステムのボーダールータは、さらに、より頻繁に動作し得、なぜならば、それはデータが階層を介してどのようにルーティングされるかを制御するからである。従来のＲＰＬシステムでは、ここに教示されるＲＩＰｎｇシステムとは対照的に、いくつかのノードは、ソースノードおよび宛先ノードに対するその位置ゆえではなく、単に階層内におけるその位置ゆえに、より頻繁にデータをルーティングし得る。ＲＰＬシステムの下でより頻繁にデータをルーティングするこれらのノードは、より多くのエネルギを消費し得、したがって、小電力を用いて動作する住宅環境内３０における装置１０で実現するには好適ではないかもしれない。さらに、上記したように、ＲＰＬシステム
のボーダールータまたは任意の他の上位レベルノードがサーモスタット４６に対応する場合には、増大したデータルーティング動作は、サーモスタット４６内で生成される熱を増大させ得る。その結果、サーモスタット４６の温度読取値は住宅環境３０の温度を不正確に表わすかもしれない。他の装置１０はサーモスタット４６の温度読取値に基づいて実行するかもしれず、サーモスタット４６はその温度読取値に基づいてさまざまな装置１０にコマンドを送るかもしれないので、サーモスタット４６の温度読取値が正確であることを確実にすることは有益であり得る。

【0078】

どの装置１０も不相応な回数量でデータをルーティングしないことを確実にすることに加えて、ＲＩＰｎｇルーティングスキームを用いることにより、新たな装置１０が、ユーザの最小の努力で、ワイヤレスメッシュネットワークに追加されてもよい。たとえば、図７Ｄは、新たなノード１０がワイヤレスメッシュネットワーク８０に追加されるのを示す。ある実施の形態では、一旦ノード１０がワイヤレスメッシュネットワーク８０に（たとえばノード４を介して）接続を確立すると、ノード１０に対応する装置１０は、上記の方法１２０を実行して、データがどのようにしてワイヤレスメッシュネットワーク８０において各ノードにルーティングされてもよいかを判断してもよい。ワイヤレスメッシュネットワーク８０における各ノードが方法１２０を既に複数回実行している場合には、ノード１０の装置１０は、ノード４の装置１０からワイヤレスメッシュネットワーク８０の全ルーティング構造を受取ってもよい。同じ態様で、装置１０はワイヤレスメッシュネットワーク８０から取除かれてもよく、各ノードは方法１２０を再び実行することによって比較的容易にそのルーティングテーブルを更新してもよい。

【0079】

ＲＩＰｎｇルーティングスキームを用いてルーティングスキームを確立したのち、ＥＬｏＷＰＡＮ１１０はＤＴＬＳプロトコルを用いて、住宅環境３０において各装置１０間におけるデータ通信を保護してもよい。上記のように、ＤＴＬＳプロトコルをＴＬＳプロトコルの代りに用いることによって、ＥＬｏＷＰＡＮ１１０は、トランスポート層９８がＴＣＰおよびＵＤＰを介してデータを送信することを可能にしてもよい。ＵＤＰは、概して、ＴＣＰよりも信頼性が低いかもしれないが、ＵＤＰデータ転送は、専用の伝送チャネルまたはデータパスが使用前に設定されることなく、単純な通信スキームを用いる。したがって、ワイヤレスメッシュネットワーク８０に追加される新たな装置１０は、ＵＤＰデータ転送を用いて、ワイヤレスメッシュネットワークにおいて他の装置１０により迅速に効果的に通信してもよい。さらに、ＵＤＰデータ転送は、一般に、データを送るかまたは転送する装置１０によって用いられるエネルギがより少なく、なぜならば、配信の保証がないからである。したがって、装置１０は、ＵＤＰデータ転送を用いて重要でないデータ（たとえば部屋における人の存在）を送り、それによって、装置１０内においてエネルギを節約してもよい。しかしながら、重要なデータ（たとえば煙警報）はＴＣＰデータ転送を介して送ることにより、適切な関係者がそのデータを受取ることを保証してもよい。反復するために、ＤＴＬＳセキュリティスキームをＥＬｏＷＰＡＮ１１０と用いることは、ＵＤＰおよびＴＣＰデータ転送を促進するのを助け得る。

【0080】

前述のことを考慮して、ＥＬｏＷＰＡＮ１１０はＤＴＬＳプロトコルを用いて、装置１０間において通信されるデータを保護してもよい。一実施の形態では、ＤＴＬＳプロトコルは、ハンドシェイクプロトコルを用いてデータ転送を保護してもよい。一般に、ハンドシェイクプロトコルは、各装置１０によって与えられてもよいセキュリティ証明書を用いて、各通信している装置を認証してもよい。図８はセキュリティ証明書がどのようにして装置１０内に埋込まれ得るかを示す製造プロセス１９０の例を示す。

【0081】

図８を参照して、委託された装置１０の製造業者１９２は、製造業者が各製造される装置に対して用いてもよい多数のセキュリティ証明書を提供されてもよい。したがって、住宅環境３０において用いられワイヤレスメッシュネットワーク８０に接続されてもよい装
置１０を製造しながら、委託された製造業者１９２は証明書１９４を製造プロセス１９０の間に装置１０内に埋込んでもよい。つまり、証明書１９４は装置１０の製造中に装置１０のハードウェア内に埋込まれてもよい。証明書１９４は、パブリックキー、プライベートキー、またはワイヤレスメッシュネットワーク８０内において異なる通信する装置を認証するのに用いられてもよい他の暗号データを含んでもよい。その結果、一旦ユーザが装置１０を受取ると、ユーザは、装置１０を初期化したり、装置１０を中央のセキュリティノードなどに登録することなく、装置１０をワイヤレスメッシュネットワーク８０内に統合してもよい。

【0082】

６ＬｏＷＰＡＮ装置において用いられるProtocol for Carrying Authentication for Network Access (PANA)（ネットワークアクセスのために認証を担持するためのプロトコル）のような従来のデータ通信セキュリティプロトコルにおいては、各装置１０はそれ自体を特定のノード（つまり認証エージェント）で認証してもよい。したがって、データが任意の２つの装置間において転送される前に、各装置１０はそれ自体を認証エージェントノードで認証してもよい。認証エージェントノードは、次いで、認証の結果を、認証エージェントノードと同じ位置にあってもよいエンフォースメントポイントノードに伝えてもよい。エンフォースメントポイントノードは、次いで、認証が有効である場合には、２つの装置１０間にデータ通信リンクを確立してもよい。さらに、ＰＡＮＡでは、各装置１０は、互いと、エンフォースメントポイントノードを介して通信してもよく、エンフォースメントポイントノードは各装置１０に対する認証が有効である旨を検証してもよい。

【0083】

したがって、ＰＡＮＡではなく、ＤＴＬＳプロトコルを用いてノード間のデータ転送を保護することによって、効率的ネットワーク層は、認証エージェントノード、エンフォースメントポイントノード、またはその両方を過度に用いることを回避してもよい。つまり、効率的ネットワーク層を用いるどのノードも、ワイヤレスメッシュネットワークにおけるノード間における各データ転送ごとに認証データを処理していなくてもよい。その結果、効率的ネットワーク層を用いるノードは、ＰＡＮＡプロトコルシステムにおける認証エージェントノードまたはエンフォースメントポイントノードと比較して、より多くのエネルギを節約し得る。

【0084】

このことを考慮して、図９は、装置１０間において、互いの間でデータを転送する際に用いられてもよい、例示的なハンドシェイクプロトコル２００を示す。図９に示されるように、ノード１における装置１０はノード２における装置１０にメッセージ２０２を送ってもよい。メッセージ２０２は、暗号スーツ、ハッシュおよび圧縮アルゴリズム、ならびに乱数を含んでもよいハローメッセージであってもよい。ノード２における装置１０は、次いで、メッセージ２０４で応答してもよく、それは、ノード２における装置１０がノード１における装置１０からメッセージ２０２を受取ったことを検証してもよい。

【0085】

ノード１とノード２との間における接続を確立した後、ノード１における装置は、再び、メッセージ２０２をノード２における装置１０に送ってもよい。ノード２における装置１０は、次いで、メッセージ２０８で応答してもよく、それは、ノード２からのハローメッセージと、ノード２からの証明書１９４と、ノード２からのキー交換と、ノード１からの証明書要求とを含んでもよい。メッセージ２０８におけるハローメッセージは、暗号スーツと、ハッシュおよび圧縮アルゴリズムと、乱数とを含んでもよい。証明書１９４は、図８を参照して上で論じられたように、委託された製造業者１９２によって装置１０内に埋込まれるセキュリティ証明書であってもよい。キー交換は、パブリックキー、プライベートキー、または２つのノード間において通信チャネルを確立するために秘密キーを判断するよう用いられてもよい他の暗号情報を含んでもよい。一実施の形態では、キー交換は、それぞれのノードに位置する対応の装置１０の証明書１９４に記憶されてもよい。

【0086】

メッセージ２０８に応答して、ノード１における装置１０は、メッセージ２１０を送ってもよく、それは、ノード１からの証明書１９４と、ノード１からのキー交換と、ノード２の証明書検証と、ノード１からの変更暗号スペック（change Cipher spec）等を含んでもよい。一実施の形態では、ノード１における装置１０は、ノード２の証明書１９４とノード１からのキー交換とを用いてノード２の証明書１９４を検証してもよい。つまり、ノード１における装置１０は、ノード２の証明書１９４とノード１からのキー交換とに基づいて、ノード２から受取られる証明書１９４が有効である旨を検証してもよい。ノード２からの証明書１９４が有効である場合には、ノード１における装置１０は変更暗号スペックメッセージをノード２における装置１０に送って、２つのノード間における通信チャネルが安全である旨を告知してもよい。

【0087】

同様に、メッセージ２１０を受取ると、ノード２における装置１０はノード１の証明書１９４とノード２からのキー交換とを用いてノード１の証明書１９４を検証してもよい。つまり、ノード２における装置１０は、ノード１の証明書１９４とノード２からのキー交換とに基づいて、ノード１から受取られる証明書１９４が有効である旨を検証してもよい。ノード１からの証明書１９４が有効である場合には、ノード２における装置１０も、変更暗号スペックメッセージをノード１における装置１０に送って、２つのノード間の通信チャネルが安全である旨を告知してもよい。

【0088】

通信チャネルが安全である旨を確立した後、ノード１における装置１０はグループに関するネットワークキー２１４をノード２における装置１０に送ってもよい。グループに関するネットワークキー２１４はＥＬｏＷＰＡＮ１１０に関連づけられてもよい。この態様で、新たな装置がＥＬｏＷＰＡＮ１１０に加わると、ＥＬｏＷＰＡＮ１１０内で通信することを先に認証された装置は新たな装置にＥＬｏＷＰＡＮ１１０へのアクセスを与えてもよい。つまり、ＥＬｏＷＰＡＮ１１０内において通信するよう先に認証された装置はグループに関するネットワークキーを新たな装置に与え、それによって、新たな装置がＥＬｏＷＰＡＮ１１０において他の装置と通信することができるようにしてもよい。たとえば、グループに関するネットワークキー２１４を用いて、適切に認証されかつグループに関するネットワークキー２１４を先に与えられていた他の装置と通信してもよい。一実施の形態では、一旦変更暗号スペックメッセージがノード１における装置１０とノード２における装置１０との間で交換されると、モデル番号、装置能力などのような識別情報が装置間で通信されてもよい。しかしながら、ノード２における装置１０がグループに関するネットワークキー２１４を受取った後、装置１０上に配置されるセンサからのデータ、装置１０によって実行されるデータ解析などのようなさらなる情報が装置間で通信されてもよい。

【0089】

製造プロセス中に装置１０内にセキュリティ証明書を埋込むことによって、装置１０は、装置１０のためのセキュリティまたは認証プロセスを確立することにユーザを巻込まなくてもよい。さらに、装置１０は、中央認証エージェントノードとは対照的なハンドシェイクプロトコルに基づいてデータがノード間において安全に転送されることを確実にし得るので、ワイヤレスメッシュネットワーク８０におけるデータ転送の安全性は、安全性のために１つのノードに依存しなくてもよい。その代わりに、効率的ネットワーク層は、あるノードが利用可能でなくなったときであってもデータがノード間で安全に転送され得ることを確実にし得る。したがって、効率的ネットワーク層はセキュリティ問題に関してはるかにより脆弱でなく、なぜならば、それはデータメッセージを保護するために１つのノードに依存しないからである。

【0090】

効率的プラットフォーム層および／またはアプリケーション層
上記のＥＬｏｗＰＡＮ１１０および／または任意の他の好適なＩＰｖ６論理ネットワークを用いて、効率的プラットフォーム層および／またはアプリケーション層を用いて住宅
環境または同様の環境において装置のファブリックを生成してもよい。装置のファブリックは多数の概してローカルの装置が通信して、データおよび情報を共有し、互い上で方法を呼び出し、ソフトウェア更新をネットワークを通してパラメータを介して与え、概して、メッセージを効率的な電力意識的な態様において通信することを可能にしてもよい。

【0091】

ファブリック装置相互接続
上で論じられたように、ファブリックは、ＩＰｖ６プロトコルのような１つ以上の好適な通信プロトコルを用いて実現されてもよい。実際、ファブリックは、ファブリックを実現するよう用いられる基底の技術（たとえばネットワークタイプまたは通信プロトコル）に対して部分的または完全に寛容であってもよい。１つ以上の通信プロトコル内においては、ファブリックは、無線または有線接続を用いて電子装置を通信可能に接続するよう用いられる１つ以上のネットワークタイプを用いて実現されてもよい。たとえば、ファブリックのある実施の形態は、イーサネット、WiFi、802.15.4, ZigBee（登録商標）, ISA100.11a, WirelessHART, MiWi^TM,電力線網、および／または他の好適なネットワークタイプ
を含んでもよい。ファブリック内においては、装置（たとえばノード）は、情報のパケットをファブリックにおける他の装置（たとえばノード）と、直接、またはＩＰルータとして振舞う、インテリジェントサーモスタットのような、仲介ノードを介して交換することができる。これらのノードは、製造業者装置（たとえばサーモスタットおよび煙検出器）および／または消費者装置（たとえば電話、タブレット、コンピュータなど）を含んでもよい。加えて、いくつかの装置は、「常にオン」であり、電気的接続を用いて継続的に電力を供給されてもよい。他の装置は、サーモスタットまたはドアベル電力接続などのような、低減された／間欠的な電力接続を用いて、部分的に低減された電力使用形態（たとえば中程度のデューティサイクル）を有してもよい。最後に、いくつかの装置は、短いデューティサイクルを有し、バッテリ電力のみで動作してもよい。換言すれば、ある実施の形態では、ファブリックは、接続タイプおよび／または所望の電力使用形態に従って１つ以上のサブネットワークに接続されてもよいヘテロジニアスな装置を含んでもよい。図１０～図１２は、ファブリックにおいて１つ以上のサブネットワークを介して電子装置を接続するよう用いられてもよい３つの実施の形態を示す。

【0092】

Ａ．単一ネットワークトポロジ
図１０は、単一のネットワークトポロジを有するファブリック１０００の実施の形態を示す。示されるように、ファブリック１０００は単一の論理ネットワーク１００２を含む。ネットワーク１００２は、イーサネット、WiFi、802.15.4、電力線網、および／またはＩＰｖ６プロトコルにおける他の好適なネットワークタイプを含み得る。実際、ネットワーク１００２がWiFiまたはイーサネットネットワークを含むいくつかの実施の形態では、ネットワーク１００２は、リンク層において橋渡しされる複数のWiFiおよび／またはイーサネットセグメントにわたってもよい。

【0093】

ネットワーク１００２は、１つ以上のノード１００４、１００６、１００８、１０１０、１０１２、１０１４および１０１６を含み、それらは総称的に１００４～１０１６と称される。示されるネットワーク１００２は７つのノードを含むが、ネットワーク１００２のある実施の形態は、ネットワーク１００２を用いて相互接続される１つ以上のノードを含んでもよい。さらに、ネットワーク１００２がWiFiネットワークである場合には、ノード１００４～１０１６の各々は、ノード１０１６（たとえばWiFiルータ）を用いて相互接続されてもよく、および／またはWiFi Direct（つまりWiFi P2P）を用いて他のノードと
対にされてもよい。

【0094】

Ｂ．星形ネットワークトポロジ
図１１は、星形ネットワークトポロジを有するファブリック１０１８としての、ファブリック１０００の代替的実施の形態を示す。ファブリック１０１８は、２つの周辺ネット
ワーク１０２２と１０２４とを併せるハブネットワーク１０２０を含む。ハブネットワーク１０２０は、WiFi／イーサネットネットワークまたは電力線網などのような、住宅ネットワークを含んでもよい。周辺ネットワーク１０２２および１０２４は、ハブネットワーク１０２０とは異なるタイプの異なるさらなるネットワーク接続タイプであってもよい。たとえば、ある実施の形態では、ハブネットワーク１０２０はWiFi／イーサネットネットワークであってもよく、周辺ネットワーク１０２２は802.15.4ネットワークを含んでもよく、周辺ネットワーク１０２４は電力線網、ZigBeeRネットワーク, ISA100.11aネットワ
ーク, WirelessHARTネットワーク,またはMiWi^TMネットワークを含んでもよい。さらに、
ファブリック１０１８の示される実施の形態は３つのネットワークを含むが、ファブリック１０１８のある実施の形態は、２つ、３つ、４つ、５つまたはそれより多いネットワークなどのような任意の数のネットワークを含んでもよい。実際、ファブリック１０１８のある実施の形態は、同じタイプの複数の周辺ネットワークを含む。

【0095】

示されるファブリック１０１８は１４個のノードを含み、各々は個々に参照番号１０２４～１０５２によりそれぞれ示されるが、ファブリック１０１８は任意の数のノードを含んでもよいことが理解されるべきである。各ネットワーク１０２０、１０２２、または１０２４内における通信は、直接装置間において、および／またはWiFi／イーサネットネットワークにおけるノード１０４２のようなアクセスポイントを介して生じてもよい。周辺ネットワーク１０２２と１０２４との間の通信は、ネットワーク間ルーティングノードを用いて、ハブネットワーク１０２０を通過してもよい。たとえば、示される実施の形態では、ノード１０３４および１０３６は、第１のネットワーク接続タイプ（たとえば802.15.4）を用いて周辺ネットワーク１０２２に接続され、第２のネットワーク接続タイプ（たとえばWiFi）を用いてハブネットワーク１０２０に接続され、一方、ノード１０４４は、第２のネットワーク接続タイプを用いてハブネットワーク１０２０に接続され、第３のネットワーク接続タイプ（たとえば電力線）を用いて周辺ネットワーク１０２４に接続される。たとえば、ノード１０２６からノード１０５２に送信されるメッセージは、ノード１０５２への通過途中において、ノード１０２８、１０３０、１０３２、１０３６、１０４２、１０４４、１０４８および１０５０を通過してもよい。

【0096】

Ｃ．重なったネットワークトポロジ
図１２は、重なったネットワークトポロジを有するファブリック１０５４としての、ファブリック１０００の代替的実施の形態を示す。ファブリック１０５４はネットワーク１０５６および１０５８を含む。示されるように、ノード１０６２、１０６４、１０６６、１０６８、１０７０および１０７２の各々はネットワークの各々に接続されてもよい。他の実施の形態では、ノード１０７２は、エンドポイントではなく、イーサネット／WiFiネットワークに対するアクセスポイントを含んでもよく、どちらがイーサネット／WiFiネットワークでなくても、ネットワーク１０５６またはネットワーク１０５８のいずれか上になくてもよい。したがって、ノード１０６２からノード１０６８への通信は、ネットワーク１０５６、ネットワーク１０５８またはそれらの何らかの組合せを通過してもよい。示される実施の形態では、各ノードは、任意の所望のネットワークを用いて、任意のネットワークを介して任意の他のノードと通信することができる。したがって、図１１の星形ネットワークトポロジとは異なり、重なったネットワークトポロジは、ネットワーク間ルーティングを用いることなく、任意のネットワークを介して直接ノード間において通信してもよい。

【0097】

Ｄ．サービスに対するファブリックネットワーク接続
住宅内における装置間の通信に加えて、ファブリック（たとえばファブリック１０００）は、ファブリックにおける他の装置の物理的近くに、またはそのような装置から物理的に遠くに位置してもよいサービスを含んでもよい。ファブリックは、これらのサービスに、１つ以上のサービスエンドポイントを介して接続する。図１３は、ファブリック１０７
６、１０７８および１０８０と通信するサービス１０７４の実施の形態を示す。サービス１０７４は、ファブリック１０７６、１０７８、および／または１０８０内において装置によって用いられてもよいさまざまなサービスを含んでもよい。たとえば、ある実施の形態では、サービス１０７４は、装置に対して時刻を供給する時刻サービス、さまざまな気象データ（たとえば外部温度、日没、風情報、天気予報など）を提供する気象サービス、各装置をｐｉｎｇするエコーサービス、データ管理サービス、装置管理サービス、および／または他の好適なサービスであってもよい。示されるように、サービス１０７４は、関係のあるデータを記憶／にアクセスし、ファブリック１０７６のようなファブリックにおいてサービスエンドポイント１０８４を介して１つ以上のエンドポイント１０８６に情報を渡すサーバ１０８２（たとえばウェブサーバ）を含んでもよい。示される実施の形態は単一のサーバ１０８２を伴う３つのファブリックを含むに過ぎないが、サービス１０７４は、任意の数のファブリックに接続してもよく、サーバ１０８２に加えてサーバを含んでもよく、および／またはさらなるサービスに対する接続を含んでもよいことが理解されるべきである。

【0098】

ある実施の形態では、サービス１０７４は、さらに、電話、ケーブルおよび／またはコンピュータのような消費者装置１０８８に接続してもよい。消費者装置１０８８は、ファブリック１０７６のようなファブリック、インターネット接続、および／または何らかの他の好適な接続方法を介してサービス１０７４に接続するよう用いられてもよい。消費者装置１０８８は、ファブリックにおける１つ以上のエンドポイント（たとえば電子装置）から、直接そのファブリックを介してか、またはサービス１０７４を介してデータにアクセスするよう用いられてもよい。換言すれば、サービス１０７４を用いて、消費者装置１０８８は、ファブリックにおける装置に対して、そのファブリックから遠隔でアクセスするか、またはそのような装置を管理するよう用いられてもよい。

【0099】

Ｅ．ファブリックにおける装置間における通信
上で論じたように、各電子装置またはノードは、ファブリックトポロジおよびネットワーク接続タイプによって、ファブリック内の任意の他のノードと、直接的または間接的に通信してもよい。加えて、いくつかの装置（たとえば遠隔装置）は、サービスを介して通信して、ファブリックにおける他の装置と通信してもよい。図１４は、２つの装置１０９２と１０９４との間における通信１０９０の実施の形態を示す。通信１０９０は、上に記載されるように、１つ以上のネットワークに、直接的に、またはさらなる装置および／もしくはサービスを介して間接的にわたってもよい。加えて、通信１０９０は、１つ以上のトランスポートプロトコルを用いて、ＩＰｖ６のような適切な通信プロトコルを介して生じてもよい。たとえば、いくつかの実施の形態では、通信１０９０は、伝送制御プロトコル（ＴＣＰ）および／またはユーザ・データグラム・プロトコル（ＵＤＰ）を用いることを含んでもよい。ある実施の形態では、装置１０９２は、無接続プロトコル（たとえばＵＤＰ）を用いて、第１の信号１０９６を装置１０９４に送信してもよい。ある実施の形態では、装置１０９２は接続指向型プロトコル（たとえばＴＣＰ）を用いて装置１０９４と通信してもよい。示される通信１０９０は双方向通信として示されるが、いくつかの実施の形態では、通信１０９０は一方向同報通信であってもよい。

【0100】

ｉ．固有のローカルアドレス
上で論じられたように、ファブリック内において送信されノードによって受信されるデータは、その通信に関する所望の目標によって、そのノードを通して他のノードに方向変更されるかまたは渡されてもよい。いくつかの実施の形態では、データの送信はすべての装置に対して同報通信されるよう意図されてもよい。そのような実施の形態では、データは、データが先へと他のノードに渡されるべきであるかを判断するようさらなる処理なしに再送信されてもよい。しかしながら、いくつかのデータは具体的なエンドポイントに向けられてもよい。アドレス指定されたメッセージが所望のエンドポイントに送信されるこ
とを可能にするために、ノードは識別情報を割当てられてもよい。

【0101】

各ノードは、１つが各ネットワークインターフェイスに割当てられるリンクローカルアドレス（ＬＬＡ）の組を割当てられてもよい。これらのＬＬＡを用いて、同じネットワーク上の他の装置と通信してもよい。加えて、ＬＬＡは、ＩＰｖ６近隣探索プロトコルのようなさまざまな通信手順に対して用いられてもよい。ＬＬＡに加えて、各ノードは固有のローカルアドレス（ＵＬＡ）を割当てられてもよい。いくつかの実施の形態では、これは拡張固有ローカルアドレス（ＥＵＬＡ）と呼ばれ得、なぜならば、それはデバイスのファブリックに関する情報を、ファブリックを通してデバイスに到達する好ましいネットワークに関する情報と並んで含んでいるからである。

【0102】

図１５は、ファブリックにおける各ノードをアドレス指定するよう用いられてもよい固有のローカルアドレス（ＵＬＡ）１０９８の実施の形態を示す。ある実施の形態では、ＵＬＡ１０９８は、グローバルＩＤ１１００とサブネットＩＤ１１０２とインターフェイスＩＤ１１０４とに分割される１２８ビットを含むＩＰｖ６アドレスフォーマット（書式）としてフォーマット（書式設定）されてもよい。グローバルＩＤ１１００は４０ビットを含み、サブネットＩＤ１１０２は１６ビットを含む。グローバルＩＤ１１００およびサブネットＩＤ１１０２は、ともになって、ファブリックに対するファブリックＩＤ１１０３を形成する。

【0103】

ファブリックＩＤ１１０３は、ファブリックを識別するよう用いられる一意の６４ビットの識別子である。ファブリックＩＤ１１０３は、擬似乱数アルゴリズムを用いて、関連づけられるファブリックの形成で生成されてもよい。たとえば、擬似乱数アルゴリズムは、１）現在の時刻を６４ビットのＮＴＰフォーマットで得てもよく、２）装置に対するインターフェイスＩＤ１１０４を得てもよく、３）時刻をインターフェイスＩＤ１１０４と連結してキーを形成してもよく、４）ＳＨＡ－１ダイジェストをそのキーの上で計算して、結果として１６０ビットをもたらしてもよく、５）最下位の４０ビットをグローバルＩＤ１１００として用いてもよく、および６）ＵＬＡを連結し、最下位ビットを１にセットして、ファブリックＩＤ１１０３を形成してもよい。ある実施の形態では、一旦ファブリックＩＤ１１０３がファブリックとともに形成されると、ファブリックＩＤ１１０３はそのファブリックが解消されるまで残る。

【0104】

グローバルＩＤ１１００は、ノードが属するファブリックを識別する。サブネットＩＤ１１０２はファブリック内の論理ネットワークを識別する。サブネットＩＤＦ３は、ファブリックに対する各新たな論理ネットワークの追加で、１で単調に開始することを割当てられてもよい。たとえば、WiFiネットワークは0x01の１６進値で識別されてもよく、後で接続される802.15.4ネットワークは、0x02の１６進値で識別されてもよく、ファブリックに対する各新たなネットワークの接続で、増分的に継続し続けてもよい。

【0105】

最後に、ＵＬＡ１０９８は、６４ビットを含むインターフェイスＩＤ１１０４を含んでもよい。インターフェイスＩＤ１１０４は、ＩＥＥＥ ＥＵＩ－６４規格に従って、グローバルに一意の６４ビット識別子を用いて割当てられてもよい。たとえば、ＩＥＥＥ８０２ネットワークインターフェイスを伴う装置は、装置の「一次インターフェイス」のためにバーンド・インのＭＡＣアドレスを用いて、インターフェイスＩＤ１１０４を導出してもよい。いくつかの実施の形態では、どのインターフェイスが一次インターフェイスであるかの指定は任意に判断されてもよい。他の実施の形態では、あるインターフェイスタイプ（たとえばWiFi）が、存在する場合には、一次インターフェイスとしてみなされてもよい。装置の一次インターフェイスに対するＭＡＣアドレスが４８ビットであり、６４ビットでない場合には、４８ビットのＭＡＣアドレスは、カプセル化（たとえば組織的に一意の識別子カプセル化）を介して、ＥＵＩ－６４値に変換されてもよい。消費者装置（たと
えば電話またはコンピュータ）においては、インターフェイスＩＤ１１０４は消費者装置のローカルオペレーティングシステムによって割当てられてもよい。

【0106】

ｉｉ．論理ネットワーク間において送信をルーティングする
星形ネットワークトポロジに関して上で論じられたように、ネットワーク間ルーティングは、論理ネットワーク間を渡る２つの装置間における通信において生じてもよい。いくつかの実施の形態では、ネットワーク間ルーティングはサブネットＩＤ１１０２に基づく。各ネットワーク間接続ノード（たとえば図１１のノード１０３４）は、ハブネットワーク１０２０上のルーティングノードのリスト（たとえば図１１のノードＢ１４）、およびそれらのそれぞれの取付けられた周辺ネットワーク（たとえば図１１の周辺ネットワーク１０２４）を維持してもよい。ルーティングノードそれ自体以外のノードにアドレス指定されたパケットが到着すると、宛先アドレス（たとえば図１１のノード１０５２に対するアドレス）がネットワークプレフィックスのリストと比較され、所望のネットワーク（たとえば周辺ネットワーク１０２４）に取付けられるルーティングノード（たとえばノード１０４４）が選択される。パケットは、次いで、その選択されたルーティングノードに転送される。複数のノード（たとえば１０３４および１０３６）が同じ周辺ネットワークに取付けられる場合には、ルーティングノードは交互する態様で選択される。

【0107】

加えて、ネットワーク間ルーティングノードは、近隣探索プロトコル（ＮＤＰ）ルータ情報提供メッセージをハブネットワーク上において定期的に送信して、消費者装置に対してハブネットワークの存在についての注意を喚起し、消費者装置がサブネットプレフィックスを得ることができるようにしてもよい。ルータ情報提供は、ファブリックにおけるルーティング情報において支援するよう１つ以上のルート情報オプションを含んでもよい。たとえば、これらのルート情報オプションは、消費者装置に対して、周辺ネットワークの存在、およびどのようにしてパケットを周辺装置にルーティングするかを知らせてもよい。

【0108】

ルート情報オプションに加えて、またはそれらに代わって、ルーティングノードは、プロキシとして振舞って、図１６に示されるプロセス１１０５のように、消費者装置と周辺ネットワークにおける装置との間において通信を与えてもよい。示されるように、プロセス１１０５は、各周辺ネットワーク装置に対するハブネットワーク上の仮想アドレスの割当が、その周辺ネットワーク上における装置についてサブネットＩＤ１１０２をインターフェイスＩＤ１１０４と組合せることによって行なうことを含む（ブロック１１０６）。仮想アドレスを用いてプロキシ化するために、ルーティングノードは、ファブリックにおける、そのインターフェイスの１つを介して直接到達可能なすべての周辺ノードのリストを含む（ブロック１１０８）。ルーティングノードは、ハブネットワーク上において、周辺ノードのリンクアドレスを、その仮想アドレスを用いて要求する近隣請求メッセージに対するリスニングを行なう（ブロック１１１０）。そのようなメッセージを受信すると、ルーティングノードは、ある時間期間のあと、その仮想アドレスをそれのハブインターフェイスに割当てることを試みる（ブロック１１１２）。割当の一部として、ルーティングノードは、２つ以上のルーティングノードによる仮想アドレスのプロキシ化を阻止するように、二重アドレス検出を実行する。割当のあと、ルーティングノードは、近隣請求メッセージに応答し、パケットを受信する（ブロック１１１４）。パケットを受信すると、ルーティングノードは、宛先アドレスを周辺ノードの実アドレスに書換え（ブロック１１１６）、メッセージを適切なインターフェイスに転送する（ブロック１１１８）。

【0109】

ｉｉｉ．消費者装置のファブリックへの接続
ファブリックに加わるために、消費者装置は、その消費者装置が加わりたいファブリックに既にあるノードのアドレスを探索してもよい。加えて、消費者装置が、ある延長された時間期間の間、ファブリックから切断されている場合、ファブリックトポロジ／レイア
ウトが変更している場合には、ネットワーク上においてノードを再探索する必要があってもよい。探索／再探索において支援するために、ハブネットワーク上のファブリック装置は、ｍＤＮＳを介して、ファブリックの存在を情報提供しアドレスを消費者装置に与えるドメイン名システム－サービス探索（ＤＮＳ－ＳＤ）を公開してもよい。

【0110】

ファブリックにおいて送信されるデータ
ファブリックの形成およびノードに対するアドレス形成のあと、データがファブリックを通して送信されてもよい。ファブリックを通して渡されるデータは、すべてのメッセージに共通の、および／またはそのファブリックにおいて特定のタイプの会話に共通のフォーマットで構成されてもよい。いくつかの実施の形態では、メッセージフォーマットは、以下に論じられるＴＬＶ直列化フォーマットを用いて、JavaScriptオブジェクト表記法（ＪＳＯＮ）に対する１対１マッピングを可能にしてもよい。加えて、以下のデータフレームは特定のサイズを含むとして記載されるが、それらのデータフレームにおけるデータフィールドの長さは他の好適なビット長に変動されてもよい旨が注記されるべきである。

【0111】

Ａ．セキュリティ
転送されるよう意図されるデータとともに、ファブリックは、データを、暗号化、メッセージ完全性チェック、デジタル署名などのような、さらなるセキュリティ手段とともに転送してもよい。ある実施の形態では、装置に対してサポートされるセキュリティのレベルは、装置の物理的セキュリティおよび／または装置の能力に従って変動してもよい。ある実施の形態では、ファブリックにおいてノード間において送信されるメッセージは、カウンタモード（ＡＥＳ－ＣＴＲ）において１２８ビットのキーで動作する高度暗号化標準（ＡＥＳ）ブロック暗号を用いて暗号化されてもよい。以下に論じられるように、各メッセージは３２ビットのメッセージｉｄを含む。このメッセージｉｄは、送信側ノードｉｄと組合されて、ＡＥＳ－ＣＴＲアルゴリズムに対するノンスを形成してもよい。３２ビットカウンタは、４０億個のメッセージが暗号化され各ノードによって送信されたのちに、新たなキーが交渉されることを可能にする。

【0112】

いくつかの実施の形態では、ファブリックは、各暗号化されたメッセージに含まれてもよい、ＨＭＡＣ－ＳＨＡ－１のような、メッセージ認証コードを用いて、メッセージ完全性を保証してもよい。いくつかの実施の形態では、メッセージ認証コードは、暗号化キーと１対１で対にされる１６０ビットのメッセージ完全性キーを用いて生成されてもよい。加えて、各ノードは、入来メッセージのメッセージｉｄを、ノード単位で維持される最近受信されたｉｄのリストと照合して、メッセージの再生を阻止してもよい。

【0113】

Ｂ．タグ‐長さ‐値（ＴＬＶ）フォーマット化
電力消費を低減するためには、ファブリックにより送信されるデータの少なくとも一部をそのようにコンパクトに送信する一方で、データコンテナが、データの直列化内において理解されるデータの次の位置にスキップすることによって認識または理解されないデータをスキップすることに対応するデータを柔軟性を持って表わすことができることが望ましい。ある実施の形態では、タグ‐長さ‐値（ＴＬＶ）フォーマット化を用いて、データをコンパクトに、かつ柔軟性を持ってエンコード／デコードしてもよい。送信されるデータの少なくとも一部をＴＬＶで記憶することによって、データは、以下において表７を参照して論じられるように、低エンコード／デコードおよびメモリオーバヘッドで、コンパクトに、かつ柔軟性を持って記憶／送信されてもよい。ある実施の形態では、ＴＬＶは、あるデータに対しては、柔軟性のある、拡張可能なデータとして用いられてもよいが、拡張可能でないデータの他の部分は、理解される標準プロトコルデータ単位（ＰＤＵ）で記憶および送信されてもよい。

【0114】

ＴＬＶフォーマットでフォーマットされるデータは、プリミティブタイプおよびコンテ
ナタイプなどのような、さまざまなタイプのＴＬＶ要素としてエンコードされてもよい。プリミティブタイプは、整数または文字列のような、あるフォーマットにおけるデータ値を含む。たとえば、ＴＬＶフォーマットは、１、２、３、４または８バイトの符号有り／符号無し整数、ＵＴＦ－８文字列、バイト文字列、単精度／倍精度浮動数（たとえばＩＥＥＥ７５４－１９８５フォーマット）、ブーリアン、ヌル、および他の好適なデータフォーマットタイプをエンコードしてもよい。コンテナタイプは要素の集まりを含み、それらは、次いで、コンテナタイプまたはプリミティブタイプとして下位分類される。コンテナタイプは、ディクショナリ、アレイ、パス、またはメンバーとして既知の、ＴＬＶ要素をグループ化するための他の好適なタイプのような、さまざまなカテゴリに分類されてもよい。ディクショナリは、そのディクショナリ内において明確な定義および一意のタグを各々が有するメンバーの集まりである。アレイは、暗示される定義を伴うかまたは明確な定義を伴わない、順序づけられたメンバーの集まりである。パスは、ＴＬＶ要素のツリーをどのように横断するかを記載した、順序づけられたメンバーの集まりである。

【0115】

図１１に示されるように、ＴＬＶパケット１１２０の実施の形態は３つのデータフィールド：タグフィールド１１２２と長さフィールド１１２４と値フィールド１１２６とを含む。示されるフィールド１１２２、１１２４および１１２６はサイズがおおよそ等価として示されているが、各フィールドのサイズは可変であってもよく、互いに対してサイズが変動してもよい。他の実施の形態では、ＴＬＶパケット１１２０は、さらに、タグフィールド１１２２の前に制御バイトを含んでもよい。

【0116】

制御バイトを有する実施の形態では、制御バイトは要素タイプフィールドとタグ制御フィールドとに下位分割されてもよい。いくつかの実施の形態では、要素タイプフィールドは制御バイトの下位５ビットを含み、タグ制御フィールドは上位３ビットを占める。要素タイプフィールドは、ＴＬＶ要素のタイプと、どのように長さフィールド１１２４および値フィールド１１２６がエンコードされるかを示す。ある実施の形態では、要素タイプフィールドは、さらに、ＴＬＶについてブーリアン値および／またはヌル値をエンコードする。たとえば、要素タイプフィールドの列挙の実施例が以下において表１に与えられる。

【0117】

【表1】

【0118】

タグ制御フィールドは、（ゼロ長タグを含む）ＴＬＶ要素に割当てられるタグフィールド１１２２におけるタグのある形式を示す。タグ制御フィールド値の例が以下に表２において与えられる。

【0119】

【表2】

【0120】

換言すれば、制御バイトを有する実施の形態では、制御バイトはタグの長さを示してもよい。

【0121】

ある実施の形態では、タグフィールド１１２２は、８ビット、１６ビット、３２ビット、または６４ビットなどのような、０～８バイトを含んでもよい。いくつかの実施の形態では、タグフィールドのタグはプロファイル特定タグまたは文脈特定タグとして分類されてもよい。プロファイル特定タグは、以下に論じられるように、ベンダＩｄ、プロファイルＩｄ、および／またはタグ番号を用いて、要素をグローバルに識別する。文脈特定タグは、含むディクショナリ要素の文脈内でＴＬＶ要素を識別し、１バイトのタグ番号を含んでもよい。文脈特定タグはそれらのコンテナの文脈において定義されるので、１つの文脈特定タグは、異なるコンテナ内に含まれるときには、異なる解釈を有し得る。いくつかの実施の形態では、文脈は、さらに、ネスト化されたコンテナから導出されてもよい。

【0122】

制御バイトを有する実施の形態では、タグ長はタグ制御フィールドにおいてエンコードされ、タグフィールド１１２２は可能な３つのフィールド：ベンダＩｄフィールド、プロファイルＩｄフィールド、およびタグ番号フィールドを含む。十分に適格とされる形式では、エンコードされたタグフィールド１１２２はすべての３つのフィールドを含み、タグ番号フィールドは、タグ制御フィールドによって決められる１６ビットまたは３２ビットを含む。暗黙的形式では、タグはタグ番号のみを含み、ベンダＩｄおよびプロファイル番号はＴＬＶ要素のプロトコル文脈から推測される。コアプロファイル形式は、以下に論じられるように、プロファイル特定タグを含む。文脈特定タグは、タグ番号を搬送する１つのバイトとしてエンコードされる。匿名要素はゼロ長タグフィールド１１２２を有する。

【0123】

制御バイトを伴わないいくつかの実施の形態では、２つのビットがタグフィールド１１２２の長さを含んでもよく、２つのビットが長さフィールド１１２４の長さを含んでもよく、４つのビットが値フィールド１１２６に記憶される情報のタイプを示してもよい。タグフィールドに対する上位８ビットに対する考えられ得るエンコーディングの一例が以下に表３において示される。

【0124】

【表3】

【0125】

表３に示されるように、タグフィールド１１２２の上位８ビットを用いて、タグフィールド１１２２、長さフィールド１１２４および値フィールド１１２６についての情報をエンコードしてもよく、タグフィールド１１２２を用いてタグフィールド１１２２および長さフィールド１１２４に対して長さを判断してもよい。タグフィールド１１２２における残りのビットは、ユーザ配分および／またはユーザ割当てされるタグ値に対して利用可能にされてもよい。

【0126】

長さフィールド１１２４は、表３に示されるようにタグフィールド１１２２によって、または表２に示されるように要素フィールドによって示されるように、８ビット、１６ビ
ット、３２ビットまたは６４ビットを含んでもよい。さらに、長さフィールド１１２４は、値フィールド１１２６においてエンコードされるものの長さを表わす、符号無し整数を含んでもよい。ある実施の形態では、長さは、ＴＬＶ要素を送信する装置によって選択されてもよい。値フィールド１１２６は、デコードされるべきペイロードデータを含むが、値フィールド１１２６の解釈はタグ長フィールドおよび／または制御バイトに依存してもよい。たとえば、８ビットタグを含む制御バイトを伴わないＴＬＶパケットが、以下において説明のために表４に示される。

【0127】

【表4】

【0128】

表４に示されるように、１行目は、タグフィールド１１２２および長さフィールド１１２４が各々８ビットの長さを有することを示す。加えて、タグフィールド１１２２は、タグタイプが１行目に対するものであり、コンテナであることを示す（たとえばＴＬＶパケット）。第２行から第６行に対するタグフィールド１１２４は、ＴＬＶパケットにおける各エントリが、各々８ビットからなるタグフィールド１１２２と長さフィールド１１２４とを有することを示す。加えて、タグフィールド１１２４は、ＴＬＶパケットにおける各エントリが、３２ビットの浮動小数点を含む値フィールド１１２６を有することを示す。値フィールド１１２６における各エントリは、対応するタグフィールド１１２２および長さフィールド１１２４情報を用いてデコードされてもよい浮動数に対応する。この例に示されるように、値フィールド１１２６における各エントリは華氏における温度に対応する。理解できるように、上記のようにデータをＴＬＶパケットに格納することによって、データは、ファブリックにおいて異なる装置によって用いられ得るように、さまざまな長さおよび情報に対して柔軟性のあるままでコンパクトに転送され得る。さらに、ある実施の形態では、マルチバイト整数フィールドは、リトルエンディアン順序またはビッグエンディアン順序で送信されてもよい。

【0129】

送信側／受信側装置フォーマット（たとえばＪＳＯＮ）によって用いられてもよい順序プロトコル（たとえばリトルエンディアン）を用いてＴＬＶパケットを送信することによって、ノード間で転送されるデータは、ノードの少なくとも１つによって用いられる順序プロトコル（たとえばリトルエンディアン）で送信されてもよい。たとえば、１つ以上のノードがＡＲＭまたはｉｘ８６プロセッサを含む場合には、ノード間の伝送を、リトルエンディアンバイト順序づけを用いて伝送することにより、バイト再順序づけの使用を低減してもよい。バイト再順序づけを含むことを低減することによって、ＴＬＶフォーマットは、伝送の両端でバイト再順序づけを用いる伝送よりも少ない電力を用いて装置が通信することを可能にする。さらに、ＴＬＶフォーマット化は、ＪＳＯＮ＋拡張可能マークアップ言語（ＸＭＬ）のような、他のデータ格納技術間における１対１翻訳を与えるよう指定されてもよい。一例として、ＴＬＶフォーマットを用いて以下のＸＭＬプロパティリストを表現してもよい。

【0130】

【数1】

【0131】

一例として、上記のプロパティリストは、以下の表５に従って（制御バイトなしで）上記のＴＬＶフォーマットのタグにおいて表現されてもよい。

【0132】

【表5】

【0133】

同様に、表６は、例示のＸＭＬプロパティリストに対するリテラルタグ、長さ、および値
表現の一例を示す。

【0134】

【表6】

【0135】

ＴＬＶフォーマットは、さらにＸＭＬとも列挙されてもよいプロパティの参照を可能にするが、より小さい格納サイズとでも同様である。たとえば、表７は、ＸＭＬプロパティリスト、対応するバイナリプロパティリスト、およびＴＬＶフォーマットのデータサイズの比較を示す。

【0136】

【表7】

【0137】

データを転送するのに用いられるデータの量を低減することによって、ＴＬＶフォーマットは、ファブリック１０００が、限られた電力のために短いデューティサイクルを有する装置（たとえばバッテリ供給される装置）に対してデータを転送することおよび／またはそのような装置からデータを転送することを可能にする。換言すれば、ＴＬＶフォーマットは、送信されるべきデータのコンパクト性を増大させながら送信の柔軟性を可能にする。

【0138】

Ｃ．一般的なメッセージプロトコル
さまざまなサイズを有する特定のエントリを送信することに加えて、データは、ファブリック内において、ＴＬＶフォーマット化を組込んでもよい一般的なメッセージプロトコルを用いて送信されてもよい。一般的なメッセージプロトコル（ＧＭＰ）１１２８の実施の形態が図１８に示される。ある実施の形態では、一般的なメッセージプロトコル（ＧＭＰ）１１２８は、ファブリック内においてデータを送信するよう用いられてもよい。ＧＭＰ１１２８は、データを無接続プロトコル（たとえばＵＤＰ）および／または接続指向型プロトコル（たとえばＴＣＰ）を介してデータを送信するよう用いられてもよい。したがって、ＧＭＰ１１２８は、１つのプロトコルにおいて用いられる情報に柔軟に対応する一方で、他のプロトコルが用いられるときにはそのような情報を無視してもよい。さらに、ＧＭＰ１２２６は、ある特定の送信においては用いられないフィールドの省略を可能にしてもよい。１つ以上のＧＭＰ１２２６転送から省略されてもよいデータは、一般的には、データ単位の周辺の曖昧な境界を用いて示される。いくつかの実施の形態では、複数バイト整数フィールドをリトルエンディアン順序またはビッグエンディアン順序で送信してもよい。

【0139】

ｉ．パケット長
いくつかの実施の形態では、ＧＭＰ１１２８はパケット長フィールド１１３０を含んでもよい。いくつかの実施の形態では、パケット長フィールド１１３０は２バイトを含む。パケット長フィールド１１３０におけるある値は、パケット長フィールド１１３０それ自体を除く、メッセージの全体の長さをバイトで示す符号無し整数に対応する。パケット長フィールド１１３０は、ＧＭＰ１１２８がＴＣＰ接続を介して送信されるときに存在してもよいが、ＧＭＰ１１２８がＵＤＰ接続を介して送信されるときには、メッセージ長は、パケット長フィールド１１３０を除く基底のＵＤＰパケットのペイロード長と等しくても
よい。

【0140】

ｉｉ．メッセージヘッダ
ＧＭＰ１１２８は、さらに、ＧＭＰ１１２８がＴＣＰまたはＵＤＰ接続を用いて送信されるかどうかに関わらず、メッセージヘッダ１１３２を含んでもよい。いくつかの実施の形態では、メッセージヘッダ１１３２は、図１９に示されるフォーマットで配される２バイトのデータを含む。図１９に示されるように、メッセージヘッダ１１３２はバージョンフィールド１１５６を含む。バージョンフィールド１１５６は、メッセージをエンコードするよう用いられるＧＭＰ１１２８のバージョンに対応する。したがって、ＧＭＰ１１２８が更新されると、ＧＭＰ１１２８の新たなバージョンが形成されるが、ファブリックにおける各装置は、装置にとって既知のＧＭＰ１１２８の任意のバージョンでデータパケットを受信することができてもよい。バージョンフィールド１１５６に加えて、メッセージヘッダ１１３２はＳフラグフィールド１１５８とＤフラグ１１６０とを含んでもよい。Ｓフラグ１１５８は、（以下に論じられる）ソースノードＩｄフィールドが送信されるパケットに含まれるかどうかを示す単一のビットである。同様に、Ｄフラグ１１６０は、（以下に論じられる）宛先ノードＩｄフィールドが送信されるパケットに含まれるかどうかを示す単一のビットである。

【0141】

メッセージヘッダ１１３２は、さらに、暗号化タイプフィールド１１６２を含む。暗号化タイプフィールド１１６２は、存在する場合にはどのタイプの暗号化／完全性チェックがメッセージに適用されるかを指定する４つのビットを含む。たとえば、0x0はどのよう
な暗号化またはメッセージ完全性チェックも含まれないことを示してもよく、十進の0x1
はＨＭＡＣ－ＳＨＡ－１メッセージ完全性チェックを伴うＡＥＳ－１２８－ＣＴＲ暗号化が含まれることを示してもよい。

【0142】

最後に、メッセージヘッダ１１３２は、さらに、署名タイプフィールド１１６４を含む。署名タイプフィールド１１６４は、もしある場合には、どのタイプのデジタル署名がメッセージに適用されるかを指定する４つのビットを含む。たとえば、0x0はどのようなデ
ジタル署名もメッセージには含まれないことを示してもよく、0x1は、Prime256v1楕円曲
線パラメータを伴う楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）がメッセージに含まれることを示してもよい。

【0143】

ｉｉｉ．メッセージＩｄ
図１８に戻って、ＧＭＰ１１２８は、さらに、メッセージＩｄフィールド１１３４を含み、それは、送信されるメッセージがＴＣＰまたはＵＤＰを用いて送信されるかどうかに関わらず、メッセージに含まれてもよい。メッセージＩｄフィールド１１３４は、メッセージを送信側ノードの視点から一意に識別する符号無し整数値に対応する４つのバイトを含む。いくつかの実施の形態では、ノードは、それらが送信する各メッセージに対して、２³²個のメッセージに到達したあとは０に戻る、増大するメッセージＩｄ１１３４の値を割当てもよい。

【0144】

ｉｖ．ソースノードＩｄ
ある実施の形態では、ＧＭＰ１１２８は、さらに、８つのバイトを含むソースノードＩｄフィールド１１３６を含んでもよい。上で論じられたように、ソースノードＩｄフィールド１１３６は、メッセージヘッダ１１３２における単一ビットのＳフラグ１１５８が１にセットされるときにメッセージに存在してもよい。いくつかの実施の形態では、ソースノードＩｄフィールド１１３６は、ＵＬＡ１０９８のインターフェイスＩＤ１１０４または全ＵＬＡ１０９８を含んでもよい。いくつかの実施の形態では、ソースノードＩｄフィールド１１３６のバイトは、インデックス値昇順（たとえばEUI[0] 次いでEUI[1] 次いでEUI[2] 次いでEUI[3],など）で送信されてもよい。

【0145】

ｖ．宛先ノードＩｄ
ＧＭＰ１１２８は、８つのバイトを含む宛先ノードＩｄフィールド１１３８を含んでもよい。宛先ノードＩｄフィールド１１３８は、ソースノードＩｄフィールド１１３６と同様であるが、宛先ノードＩｄフィールド１１３８はメッセージに対する宛先ノードに対応する。宛先ノードＩｄフィールド１１３８は、メッセージヘッダ１１３２における単一ビットのＤフラグ１１６０が１にセットされるときにメッセージに存在してもよい。さらに、ソースノードＩｄフィールド１１３６と同様に、いくつかの実施の形態では、宛先ノードＩｄフィールド１１３８のバイトはインデックス値昇順（たとえばEUI[0] 次いでEUI[1] 次いでEUI[2] 次いでEUI[3],など）で送信されてもよい。

【0146】

ｖｉ．キーＩｄ
ある実施の形態では、ＧＭＰ１１２８はキーＩｄフィールド１１４０を含んでもよい。ある実施の形態では、キーＩｄフィールド１１４０は２つのバイトを含む。キーＩｄフィールド１１４０はメッセージを暗号化するのに用いられる暗号化／メッセージ完全性キーを識別する符号無し整数値を含む。キーＩｄフィールド１１４０の存在は、メッセージヘッダ１１３２の暗号化タイプフィールド１１６２の値によって判断されてもよい。たとえば、いくつかの実施の形態では、メッセージヘッダ１１３２の暗号化タイプフィールド１１６２に対する値が0x00であるときには、キーＩｄフィールド１１４０はメッセージから省略されてもよい。

【0147】

キーＩｄフィールド１１４０の実施の形態が図２０に提示される。示される実施の形態では、キーＩｄフィールド１１４０はキータイプフィールド１１６６とキー番号フィールド１１６８とを含む。いくつかの実施の形態では、キータイプフィールド１１６６は４つのビットを含む。キータイプフィールド１１６６は、メッセージを暗号化するのに用いられる暗号化／メッセージ完全性のタイプを識別する符号無し整数値に対応する。たとえば、いくつかの実施の形態では、キータイプフィールド１１６６が0x0である場合には、フ
ァブリックキーはファブリックにおけるノードのすべてまたはほとんどによって共有される。しかしながら、キータイプフィールド１１６６が0x1である場合には、ファブリック
キーはファブリックにおいてノードの対によって共有される。

【0148】

キーＩｄフィールド１１４０は、さらに、キー番号フィールド１１６８を含み、それは、共有されるキーであるかまたはファブリックキーの、利用可能なキーの組からメッセージを暗号化するのに用いられる特定のキーを識別する符号無し整数値に対応する１２個のビットを含む。

【0149】

ｖｉｉ．ペイロード長
いくつかの実施の形態では、ＧＭＰ１１２８はペイロード長フィールド１１４２を含んでもよい。ペイロード長フィールド１１４２は、存在するときには、２つのバイトを含んでもよい。ペイロード長フィールド１１４２は、アプリケーションペイロードフィールドのサイズをバイトで示す符号無し整数値に対応する。ペイロード長フィールド１１４２は、以下においてパディングフィールドとの関連において記載される、メッセージパディングを用いるアルゴリズムを用いてメッセージが暗号化されるときに存在してもよい。

【0150】

ｖｉｉｉ．初期化ベクトル
いくつかの実施の形態では、ＧＭＰ１１２８は、さらに、初期化ベクトル（ＩＶ）フィールド１１４４を含んでもよい。ＩＶフィールド１１４４は、存在するときには、可変数のバイトのデータを含む。ＩＶフィールド１１４４は、メッセージを暗号化するのに用いられる暗号のＩＶ値を含む。ＩＶフィールド１１４４は、ＩＶを用いるアルゴリズムでメッセージが暗号化されるときに用いられてもよい。ＩＶフィールド１１４４の長さは、メ
ッセージを暗号化するのに用いられる暗号化のタイプによって導出されてもよい。

【0151】

ｉｘ．アプリケーションペイロード
ＧＭＰ１１２８はアプリケーションペイロードフィールド１１４６を含む。アプリケーションペイロードフィールド１１４６は可変数のバイトを含む。アプリケーションペイロードフィールド１１４６はメッセージにおいて搬送されるアプリケーションデータを含む。アプリケーションペイロードフィールド１１４６の長さは、存在する場合にはペイロード長フィールド１１４２から判断されてもよい。ペイロード長フィールド１１４２が存在しない場合には、アプリケーションペイロードフィールド１１４６の長さは、すべての他のフィールドの長さをメッセージの全長から減算することによって、および／またはアプリケーションペイロード１１４６内に含まれるデータ値（たとえばＴＬＶ）から判断されてもよい。

【0152】

アプリケーションペイロードフィールド１１４６の実施の形態が図２１に示される。アプリケーションペイロードフィールド１１４６はＡＰバージョンフィールド１１７０を含む。いくつかの実施の形態では、ＡＰバージョンフィールド１１７０は、どのバージョンのファブリックソフトウェアが送信側装置によってサポートされるかを示す８つのビットを含む。アプリケーションペイロードフィールド１１４６は、さらに、メッセージタイプフィールド１１７２を含む。メッセージタイプフィールド１１７２は、プロファイル内において送信されているメッセージのタイプを示すメッセージオペレーションコードに対応する８つのビットを含んでもよい。たとえば、あるソフトウェア更新プロファイルにおいては、0x00は、送信されているメッセージがイメージ告知であることを示してもよい。アプリケーションペイロードフィールド１１４６は、さらに、トランザクションに対して送信側ノードに対して一意である交換識別子に対応する１６個のビットを含む交換Ｉｄフィールド１１７４を含む。

【0153】

加えて、アプリケーションペイロードフィールド１１４６はプロファイルＩｄフィールド１１７６を含む。プロファイルＩｄ１１７６は、どのようなタイプの通信がメッセージにおいて生ずるかを示すよう用いられる「ディスカッションのテーマ」を示す。プロファイルＩｄ１１７６は、装置が通信することができてもよい１つ以上のプロファイルに対応してもよい。たとえば、プロファイルＩｄ１１７６は、メッセージが、コアプロファイル、ソフトウェア更新プロファイル、ステータス更新プロファイル、データ管理プロファイル、環境および快適さプロファイル、セキュリティプロファイル、安全性プロファイル、および／または他の好適なプロファイルタイプに関係する旨を示してもよい。ファブリック上における各装置は、装置に関連性がありかつ装置が「ディスカッションに参加」できるプロファイルのリストを含んでもよい。たとえば、ファブリックにおける多くの装置は、コアプロファイル、ソフトウェア更新プロファイル、ステータス更新プロファイル、およびデータ管理プロファイルを含んでもよいが、いくつかの装置のみが環境および快適さプロファイルを含むであろう。ＡＰバージョンフィールド１１７０、メッセージタイプフィールド１１７２、交換Ｉｄフィールド、プロファイルＩｄフィールド１１７６、およびプロファイル特定ヘッダフィールド１１７６は、存在する場合には、組合せにおいて、「アプリケーションヘッダ」と称されてもよい。

【0154】

いくつかの実施の形態では、プロファイルＩｄフィールド１１７６を介するプロファイルＩｄの指示は、プロファイルに対して送信されるデータに対するスキーマを与えるよう十分な情報を提供してもよい。しかしながら、いくつかの実施の形態では、さらなる情報を用いて、アプリケーションペイロードフィールド１１４６をデコードするためのさらなるガイダンスを判断してもよい。そのような実施の形態では、アプリケーションペイロードフィールド１１４６はプロファイル特定ヘッダフィールド１１７８を含んでもよい。いくつかのプロファイルはプロファイル特定ヘッダフィールド１１７８を用いなくてもよく
、それによって、アプリケーションペイロードフィールド１１４６がプロファイル特定ヘッダフィールド１１７８を省略することを可能にしてもよい。プロファイルＩｄフィールド１１７６および／またはプロファイル特定ヘッダフィールド１１７８からのスキーマの判断で、データをアプリケーションペイロードサブフィールド１１８０においてエンコード／デコードしてもよい。アプリケーションペイロードサブフィールド１１８０は、装置間、および／または受信側装置／サービスによって記憶、再同報通信、および／または作用されるサービス間において送信されるべきコアアプリケーションデータを含む。

【0155】

ｘ．メッセージ完全性チェック
図１８に戻って、いくつかの実施の形態では、ＧＭＰ１１２８は、さらに、メッセージ完全性チェック（ＭＩＣ）フィールド１１４８を含んでもよい。ＭＩＣフィールド１１４８は、存在するときには、メッセージのためにＭＩＣを含む可変長のバイトのデータを含む。フィールドの長さおよびバイト順序は使用における完全性チェックアルゴリズムに依存する。たとえば、メッセージがＨＭＡＣ－ＳＨＡ－１を用いてメッセージ完全性についてチェックされる場合には、ＭＩＣフィールド１１４８は２０個のバイトをビッグエンディアン順序で含む。さらに、ＭＩＣフィールド１１４８の存在は、メッセージヘッダ１１３２の暗号化タイプフィールド１１６２が0x0以外の任意の値を含むかどうかによって判
断されてもよい。

【0156】

ｘｉ．パディング
ＧＭＰ１１２８は、さらに、パディングフィールド１１５０を含んでもよい。パディングフィールド１１５０は、存在するときには、暗号化されたメッセージの部分が暗号化ブロックサイズによって均等に割切れるようにするようメッセージに付加される暗号パディングを表わすバイトのシーケンスを含む。パディングフィールド１１５０の存在は、メッセージヘッダ１１３２における暗号化タイプフィールド１１６２によって示される暗号化アルゴリズムのタイプ（たとえば暗号ブロック連鎖モードにおけるブロック暗号）が暗号パディングを用いるかどうかによって判断されてもよい。

【0157】

ｘｉｉ．暗号化
アプリケーションペイロードフィールド１１４６、ＭＩＣフィールド１１４８、およびパディングフィールド１１５０は、ともになって、暗号化ブロック１１５２を形成する。暗号化ブロック１１５２は、メッセージヘッダ１１３２における暗号化タイプフィールド１１６２が0x0以外の任意の値であるときに暗号化されるメッセージの部分を含む。

【0158】

ｘｉｉｉ．メッセージ署名
ＧＭＰ１１２８は、さらに、メッセージ署名フィールド１１５４を含んでもよい。メッセージ署名フィールド１１５４は、存在するときには、メッセージの暗号署名を含む可変長のバイトのシーケンスを含む。メッセージ署名フィールドの長さおよびコンテンツは、使用における署名アルゴリズムのタイプに従って判断されてもよく、メッセージヘッダ１１３２の署名タイプフィールド１１６４によって示されてもよい。たとえば、Prime256v1楕円曲線パラメータを用いるＥＣＤＳＡが使用におけるアルゴリズムである場合には、メッセージ署名フィールド１１５４は、リトルエンディアン順序でエンコードされる２つの３２ビット整数を含んでもよい。

【0159】

ｉｖ．プロファイルおよびプロトコル
上で論じられたように、１つ以上の情報のスキーマが、メッセージに対する所望の一般的なディスカッションタイプで選択されてもよい。プロファイルは１つ以上のスキーマからなってもよい。たとえば、１つのプロファイルがアプリケーションペイロード１１４６のプロファイルＩｄフィールド１１７６に示されるときには、１組の情報のスキーマを用いてアプリケーションペイロードサブフィールド１１８０においてデータをエンコード／
デコードしてもよい。しかしながら、異なるプロファイルがアプリケーションペイロード１１４６のプロファイルＩｄフィールド１１７６に示されるときには、異なるスキーマの組を用いてアプリケーションペイロードサブフィールド１１８０におけるデータをエンコード／デコードしてもよい。

【0160】

加えて、ある実施の形態では、各装置は、プロファイルを処理するよう用いられる方法の組を含んでもよい。たとえば、コアプロファイルは以下のプロファイル：GetProfiles,
GetSchema, GetSchemas, GetProperty, GetProperties, SetProperty, SetProperties, RemoveProperty, RemoveProperties, RequestEcho, NotifyPropertyChanged, および／またはNotifyPropertiesChanged（プロファイル獲得、スキーマ獲得、複数のスキーマ獲得
、プロパティ獲得、複数のプロパティ獲得、プロパティ設定、複数のプロパティ設定、プロパティ除去、複数のプロパティ除去、エコー要求、プロパティ変更通知、および／または複数のプロパティ変更通知）を含んでもよい。GetProfiles方法は問合せされるノード
によってサポートされるプロファイルのアレイを返してもよい。GetSchemaおよびGetSchemas方法は、それぞれ、特定のプロファイルについて１つまたはすべてのスキーマを返し
てもよい。GetPropertyおよびGetPropertiesは、それぞれ、あるプロファイルスキーマに関してある値またはすべての値の対を返してもよい。SetPropertyおよびSetPropertiesは、それぞれ、あるプロファイルスキーマについて、単一の値または複数の値をセットしてもよい。RemovePropertyおよびRemovePropertiesは、それぞれ、あるプロファイルスキーマから単一の値または複数の値を除去するよう試みてもよい。RequestEchoは、ある指定
されるノードに対して、そのノードが修正されない状態で返す任意のデータペイロードを送信してもよい。NotifyPropertyChangedおよびNotifyPropertiesChangedは、それぞれ、単一／複数の値の対があるプロファイルスキーマに対して変更された場合に通知を発行してもよい。

【0161】

プロファイルおよびスキーマを理解することを助けるために、プロファイルおよびスキーマの非排他的リストを以下に説明の目的で与える。

【0162】

Ａ．ステータス報告
ステータス報告スキーマは、図２２においてステータス報告フレーム１１８２として提示される。ステータス報告スキーマは、別のプロファイルであってもよく、または１つ以上のプロファイルに含まれてもよい（たとえばコアプロファイル）。ある実施の形態では、ステータス報告フレーム１１８２は、プロファイルフィールド１１８４、ステータスコードフィールド１１８６、次のステータスフィールド１１８８を含み、追加のステータス情報フィールド１１９０を含んでもよい。

【0163】

ｉ．プロファイルフィールド
いくつかの実施の形態では、プロファイルフィールド１１８４は、現在のステータス報告における情報が解釈されることになるプロファイルを定義する４つのバイトのデータを含む。プロファイルフィールド１１８４の実施の形態が、図２３において、２つのサブフィールドで示される。示される実施の形態では、プロファイルフィールド１１８４はプロファイルＩｄサブフィールド１１９２を含み、それは、ステータスコードフィールド１１８６の値が定義されるプロファイルに対するベンダ特定識別子に対応する１６個のビットを含む。プロファイルフィールド１１８４は、さらに、ベンダＩｄサブフィールド１１９４を含み、それは、プロファイルＩｄサブフィールド１１９２において識別されるプロファイルを与えるベンダを識別する１６個のビットを含む。

【0164】

ｉｉ．ステータスコード
ある実施の形態では、ステータスコードフィールド１１８６は、報告されているステータスをエンコードする１６個のビットを含む。ステータスコードフィールド１１８６にお
ける値は、プロファイルフィールド１１８４において与えられるベンダＩｄサブフィールド１１９２およびプロファイルＩｄサブフィールド１１９４においてエンコードされる値との関係において解釈される。加えて、ある実施の形態では、ステータスコード空間を、以下において表８に示されるように４つのグループに分割してもよい。

【0165】

【表8】

【0166】

表８は、各特定のプロファイルＩｄごとに別々に割当てられ用いられる、用いられてもよい一般的なステータスコード範囲を識別するが、いくつかの実施の形態では、いくつかのステータスコードはプロファイルの各々に共通であってもよい。たとえば、これらのプロファイルは、0x00000000のような共通のプロファイル（たとえばコアプロファイル）識別子を用いて識別されてもよい。

【0167】

ｉｉｉ．次のステータス
いくつかの実施の形態では、次のステータスコードフィールド１１８８は８つのビットを含んでもよい。次のステータスコードフィールド１１８８は、現在報告されるステータスのあとに後続のステータス情報があるかどうかを示してもよい。後続のステータス情報が含まれることになる場合には、次のステータスコードフィールド１１８８は、どのようなタイプのステータス情報が含まれることになるかを示す。いくつかの実施の形態では、次のステータスコードフィールド１１８８は常に含まれ得、それによって、おそらくはメッセージのサイズを増大させ得る。しかしながら、ステータス情報をともに連鎖させる機会を与えることによって、送信されるデータの全体的な低減に対する可能性が低減され得る。次のステータスフィールド１１８６が0x00である場合には、どのような後続のステータス情報フィールド１１９０も含まれない。しかしながら、非ゼロの値は、データが含まれてもよいことを示してもよく、データが含まれる形式（たとえばＴＬＶパケットにおける）を示してもよい。

【0168】

ｉｖ．追加のステータス情報
次のステータスコードフィールド１１８８が非ゼロであるときには、追加のステータス情報フィールド１１９０がメッセージに含まれる。存在する場合には、ステータス項目フィールドは、先行するステータスタイプフィールドの値によって判断されてもよい形式（
たとえばＴＬＶフォーマット）でステータスを含んでもよい。

【0169】

Ｂ．ソフトウェア更新
ソフトウェア更新プロファイルまたはプロトコルは、スキーマの組、およびクライアントがダウンロードまたはインストールしてもよいソフトウェアの存在についての情報にクライアントが気づかされるかまたはそのような情報を求めることを可能にするクライアント／サーバプロトコルである。ソフトウェア更新プロトコルを用いて、ソフトウェアイメージを、プロファイルクライアントに対して、クライアントに既知のフォーマットで与えてもよい。あとのソフトウェアイメージの処理は、包括的、装置特定、またはベンダ特定であってもよく、ソフトウェア更新プロトコルおよび装置によって判断されてもよい。

【0170】

ｉ．アプリケーションペイロードに対する一般的なアプリケーションヘッダ
適切に認識および処理されるために、ソフトウェア更新プロファイルフレームは、ＧＭＰ１１２８のアプリケーションペイロードフィールド１１４６内において識別されてもよい。いくつかの実施の形態では、すべてのソフトウェア更新プロファイルフレームは、0x0000000Cのような共通のプロファイルＩｄ１１７６を用いてもよい。加えて、ソフトウェア更新プロファイルフレームは、追加の情報を示すメッセージタイプフィールド１１７２を含んでもよく、以下の表９および送信されるメッセージのタイプに従って選択されてもよい。

【0171】

【表9】

【0172】

加えて、以下に記載されるように、ソフトウェア更新シーケンスを、サーバが更新をイメージ告知として送信すること、またはクライアントが更新をイメージクエリとして受信することによって開始してもよい。いずれの実施の形態においても、開始イベントからの交換Ｉｄ１１７４を、ソフトウェア更新との関連において用いられるすべてのメッセージに対して用いる。

【0173】

ｉｉ．プロトコルシーケンス
図２４は、ソフトウェア更新クライアント１１９８とソフトウェア更新サーバ１２００との間におけるソフトウェア更新に対するプロトコルシーケンス１１９６の実施の形態を示す。ある実施の形態では、ファブリックにおける任意の装置はソフトウェア更新クライアント１１９８またはソフトウェア更新サーバ１２００であってもよい。プロトコルシーケンス１１９６のある実施の形態は、破線で示されるもののような、一部のソフトウェア更新送信においては省略されてもよいさらなるステップを含んでもよい。

【0174】

１．サービス探索
いくつかの実施の形態では、プロトコルシーケンス１１９６は、ソフトウェア更新プロ
ファイルサーバが更新の存在を告知することで始まる。しかしながら、示される実施の形態のような他の実施の形態では、プロトコルシーケンス１１９６は、上に論じられるように、サービス探索１２０２で始まってもよい。

【0175】

２．イメージ告知
いくつかの実施の形態では、イメージ告知メッセージ１２０４はソフトウェア更新サーバ１２００によってマルチキャストまたはユニキャストされてもよい。イメージ告知メッセージ１２０４は、ファブリックにおける装置に対して、サーバ１２００は提供すべきソフトウェア更新を有する旨を知らせる。更新がクライアント１１９８に適用可能である場合には、イメージ告知メッセージ１２０４の受信で、ソフトウェア更新クライアント１１９８はイメージクエリメッセージ１２０６で応答する。ある実施の形態では、イメージ告知メッセージ１２０４はプロトコルシーケンス１１９６に含まれなくてもよい。その代わりに、そのような実施の形態では、ソフトウェア更新クライアント１１９８は、ポーリングスケジュールを用いて、イメージクエリメッセージ１２０６をいつ送信すべきかを判断してもよい。

【0176】

３．イメージクエリ
ある実施の形態では、イメージクエリメッセージ１２０６は、上で論じられたように、ソフトウェア更新クライアント１１９８から、イメージ告知メッセージ１２０４に応答するか、またはポーリングスケジュールに従って、ユニキャストされてもよい。イメージクエリメッセージ１２０６は、クライアント１１９８からのそれ自体についての情報を含む。イメージクエリメッセージ１２０６のフレームの実施の形態が図２５に示される。図２５に示されるように、イメージクエリメッセージ１２０６のある実施の形態は、フレーム制御フィールド１２１８と、製品仕様フィールド１２２０と、ベンダ特定データフィールド１２２２と、バージョン仕様フィールド１２２４と、ロケール仕様フィールド１２２６と、被サポート完全性タイプフィールド１２２８と、被サポート更新スキームフィールド１２３０とを含んでもよい。

【0177】

ａ．フレーム制御
フレーム制御フィールド１２１８は、１バイトを含み、イメージクエリメッセージ１２０４についてのさまざまな情報を示す。フレーム制御フィールド１２１８の一例を図２６に示す。示されるように、フレーム制御フィールド１２１８は３つのサブフィールド：ベンダ特定フラグ１２３２とロケール仕様フラグ１２３４と予約済フィールドＳ３とを含んでもよい。ベンダ特定フラグ１２３２は、ベンダ特定データフィールド１２２２がメッセージイメージクエリメッセージに含まれるかどうかを示す。たとえば、ベンダ特定フラグ１２３２が０であるとき、いかなるベンダ特定データフィールド１２２２もイメージクエリメッセージには存在しなくてもよいが、ベンダ特定フラグ１２３２が１であるときには、ベンダ特定データフィールド１２２２はイメージクエリメッセージに存在してもよい。同様に、ロケール仕様フラグ１２３４における１値は、ロケール仕様フィールド１２２６がイメージクエリメッセージに存在することを示し、０値は、ロケール仕様フィールド１２２６がイメージクエリメッセージに存在しないことを示す。

【0178】

ｂ．製品仕様
製品仕様フィールド１２２０は６バイトフィールドである。製品仕様フィールド１２２０の実施の形態が図２７に示される。示されるように、製品仕様フィールド１２２０は、３つのサブフィールド：ベンダＩｄフィールド１２３６と製品Ｉｄフィールド１２３８と、製品リビジョンフィールド１２４０とを含んでもよい。ベンダＩｄフィールド１２３６は、ソフトウェア更新クライアント１１９８に対するベンダを示す１６個のビットを含む。製品Ｉｄフィールド１２３８は、イメージクエリメッセージ１２０６をソフトウェア更新クライアント１１９８として送信している装置製品を示す１６個のビットを含む。製品
リビジョンフィールド１２４０は、ソフトウェア更新クライアント１１９８のリビジョン属性を示す１６個のビットを含む。

【0179】

ｃ．ベンダ特定データ
ベンダ特定データフィールド１２２２は、イメージクエリメッセージ１２０６に存在するときには、可変数のバイトの長さを有する。ベンダ特定データフィールド１２２２の存在は、フレーム制御フィールド１２１８のベンダ特定フラグ１２３２から判断されてもよい。存在するときには、ベンダ特定データフィールド１２２２は、上に記載されたように、ソフトウェア更新クライアント１１９８についてのベンダ特定情報をＴＬＶフォーマットでエンコードする。

【0180】

ｄ．バージョン仕様
バージョン仕様フィールド１２２４の実施の形態を図２８に示す。バージョン仕様フィールド１２２４は、２つのサブフィールド：バージョン長フィールド１２４２とバージョン文字列フィールド１２４４とに下位分割される可変数のバイトを含む。バージョン長フィールド１２４２は、バージョン文字列フィールド１２４４の長さを示す８つのビットを含む。バージョン文字列フィールド１２４４は、長さが可変であり、バージョン長フィールド１２４２によって決められる。いくつかの実施の形態では、バージョン文字列フィールド１２４４は、長さにおいて２５５個のＵＴＦ－８文字を用いて上限を設けられてもよい。バージョン文字列フィールド１２４４においてエンコードされる値は、ソフトウェア更新クライアント１１９８に対するソフトウェアバージョン属性を示す。

【0181】

ｅ．ロケール仕様
ある実施の形態では、ロケール仕様フィールド１２２６は、フレーム制御１２１８のロケール仕様フラグ１２３４が１であるときにイメージクエリメッセージ１２０６に含まれてもよい。ロケール仕様フィールド１２２６の実施の形態を図２９に示す。ロケール仕様フィールド１２２６の示される実施の形態は、２つのサブフィールド：ロケール文字列長フィールド１２４６とロケール文字列フィールド１２４８とに分割される可変数のバイトを含む。ロケール文字列長フィールド１２４６は、ロケール文字列フィールド１２４８の長さを示す８つのビットを含む。ロケール仕様フィールド１２２６のロケール文字列フィールド１２４８は、長さが可変であってもよく、ポータブルオペレーティングシステムインターフェイス（ＰＯＳＩＸ（ポジックス））ロケールコードに基づいてローカル記述をエンコードするＵＴＦ－８文字の文字列を含んでもよい。ＰＯＳＩＸロケールコードに対する標準フォーマットは、［language[_territory][.codeset][@modifier]］である。た
とえば、オーストラリア英語に対するＰＯＳＩＸ表現はen_AU.UTF8である。

【0182】

ｆ．被サポート完全性タイプ
完全性タイプフィールド１２２８の実施の形態が図３０に示される。被サポート完全性タイプフィールド１２２８は、２つのサブフィールド：タイプリスト長フィールド１２５０と完全性タイプリストフィールド１２５２とに分割される２バイトから４バイトのデータを含む。タイプリスト長フィールド１２５０は、完全性タイプリストフィールド１２５２のバイトにおける長さを示す８つのビットを含む。完全性タイプリストフィールド１２５２は、ソフトウェア更新クライアント１１９８のソフトウェア更新完全性タイプ属性の値を示す。いくつかの実施の形態では、完全性タイプは以下の表１０から導出されてもよい。

【0183】

【表10】

【0184】

完全性タイプリストフィールド１２５２は、表１０からの少なくとも１つの要素または含まれない他のさらなる値を含んでもよい。

【0185】

ｇ．被サポート更新スキーム
被サポートスキームフィールド１２３０の実施の形態を図３１に示す。被サポートスキームフィールド１２３０は、２つのサブフィールド：スキームリスト長フィールド１２５４と更新スキームリストフィールド１２５６とに分割される可変数のバイトを含む。スキームリスト長フィールド１２５４は、更新スキームリストフィールドの長さをバイトで示す８つのビットを含む。被サポート更新スキームフィールド１２２２の更新スキームリストフィールド１２５６は、長さが可変であり、スキームリスト長フィールド１２５４によって決められる。更新スキームリストフィールド１２５６は、ソフトウェア更新クライアント１１９８のソフトウェア更新プロファイルの更新スキーム属性を表現する。例示の値の実施の形態が以下の表１１に示される。

【0186】

【表11】

【0187】

イメージクエリメッセージ１２０６を受信すると、ソフトウェア更新サーバ１２００は、送信された情報を用いて、ソフトウェア更新サーバ１２００がソフトウェア更新クライアント１１９８に対する更新を有するかどうか、およびその更新をどのようにしてソフトウェア更新クライアント１１９８に送達するのが一番よいかを判断する。

【0188】

４．イメージクエリ応答
図２４に戻って、ソフトウェア更新サーバ１２００がイメージクエリメッセージ１２０６をソフトウェア更新クライアント１１９８から受信したのち、ソフトウェア更新サーバ１２００はイメージクエリ応答１２０８で応答する。イメージクエリ応答１２０８は、更新イメージがなぜソフトウェア更新クライアント１１９８にとって利用可能でないかを詳
述する情報、またはソフトウェア更新クライアント１１９８が利用可能なイメージ更新をダウンロードおよびインストールすることができるようにその更新についての情報を含む。

【0189】

イメージクエリ応答１２０８のフレームの実施の形態を図３２に示す。示されるように、イメージクエリ応答１２０８は５つの可能なサブフィールド：クエリステータスフィールド１２５８と統一的リソース識別子（ＵＲＩ）フィールド１２６０と完全性仕様フィールド１２６２と更新スキームフィールド１２６４と更新オプションフィールド１２６６とを含む。

【0190】

ａ．クエリステータス
クエリステータスフィールド１２５８は、可変数のバイトを含み、上においてステータス報告に関して論じられたように、ステータス報告フォーマット化データを含む。たとえば、クエリステータスフィールド１２５８は、以下の表１２に示されるもののような、イメージクエリ応答ステータスコードを含んでもよい。

【0191】

【表12】

【0192】

ｂ．ＵＲＩ
ＵＲＩフィールド１２６０は可変数のバイトを含む。ＵＲＩフィールド１２６０の存在はクエリステータスフィールド１２５８によって判断されてもよい。クエリステータスフィールド１２５８によって、更新が利用可能である旨が示される場合には、ＵＲＩフィールド１２６０が含まれてもよい。ＵＲＩフィールド１２６０の実施の形態を図３３に示す。ＵＲＩフィールド１２６０は、２つのサブフィールド：ＵＲＩ長フィールド１２６８とＵＲＩ文字列フィールド１２７０とを含む。ＵＲＩ長フィールド１２６８は、ＵＲＩ文字列フィールド１２７０の長さをＵＴＦ－８文字で示す１６個のビットを含む。ＵＲＩ文字列フィールド１２７０は、ソフトウェア更新クライアント１１９８が、ソフトウェアイメージ更新が存在するときにはそれを見つけ出し、ダウンロードし、およびインストールできるように、提示されているソフトウェアイメージ更新のＵＲＩ属性を示す。

【0193】

ｃ．完全性仕様
完全性仕様フィールド１２６２は、長さが可変であってもよく、更新がソフトウェア更新サーバ１１９８からソフトウェア更新クライアント１１９８に利用可能である旨をクエリステータスフィールド１２５８が示すときに存在してもよい。完全性仕様フィールド１２６２の実施の形態を図３４に示す。示されるように、完全性仕様フィールド１２６２は
２つのサブフィールド：完全性タイプフィールド１２７２と完全性値フィールド１２７４とを含む。完全性タイプフィールド１２７２は、ソフトウェアイメージ更新に対する完全性タイプ属性を示す８つのビットを含み、上記の表１０に示されるものと同様のリストを用いて事前設定されてもよい。完全性値フィールド１２７４は、イメージ更新メッセージが送信中に完全性を維持したことを検証するよう用いられる完全性値を含む。

【0194】

ｄ．更新スキーム
更新スキームフィールド１２６４は、８つのビットを含み、更新がソフトウェア更新サーバ１１９８からソフトウェア更新クライアント１１９８に利用可能である旨をクエリステータスフィールド１２５８が示すときに存在する。存在する場合には、更新スキームフィールド１２６４は、ソフトウェア更新サーバ１１９８に提示されているソフトウェア更新イメージに対するスキーム属性を示す。

【0195】

ｅ．更新オプション
更新オプションフィールド１２６６は、８つのビットを含み、更新がソフトウェア更新サーバ１１９８からソフトウェア更新クライアント１１９８に利用可能である旨をクエリステータスフィールド１２５８が示すときに存在する。更新オプションフィールド１２６６は図３５に示されるように下位分割されてもよい。示されるように、更新オプションフィールド１２６６は４つのサブフィールド：更新優先度フィールド１２７６と更新条件フィールド１２７８と報告ステータスフラグ１２８０と予約済フィールド１２８２とを含む。いくつかの実施の形態では、更新優先度フィールド１２７６は２つのビットを含む。更新優先度フィールド１２７６は、更新の優先度属性を示し、以下の表１３に示されるもののような値を用いて判断されてもよい。

【0196】

【表13】

【0197】

更新条件フィールド１２７８は、いつ更新すべきか、または更新するかどうかを判断すべく、条件的ファクタを判断するのに用いられてもよい３つのビットを含む。たとえば、更新条件フィールド１２７８における値は以下の表１４を用いてデコードされてもよい。

【0198】

【表14】

【0199】

報告ステータスフラグ１２８０は、ソフトウェア更新クライアント１１９８がダウンロード通知メッセージ１２１０で応答すべきかどうかを示す１つのビットである。報告ステータスフラグ１２８０が１にセットされる場合には、ソフトウェア更新サーバ１１９８は、ソフトウェア更新がソフトウェア更新クライアント１２００によってダウンロードされたあとにダウンロード通知メッセージ１２１０が送信されることを要求している。

【0200】

イメージクエリ応答１２０８が、更新が利用可能であることを示す場合には、ソフトウェア更新クライアント１１９８は、イメージクエリ応答１２０８において示される時間に、イメージクエリ応答１２０８に含まれる情報を用いて、その更新をダウンロードする（１２１０）。

【0201】

５．ダウンロード通知
更新ダウンロード１２１０が成功裏に完了したかまたは失敗して報告ステータスフラグ１２８０が１になったあと、ソフトウェア更新クライアント１１９８はダウンロード通知メッセージ１２１２で応答してもよい。ダウンロード通知メッセージ１２１２は、上で論じられたステータス報告フォーマットに従ってフォーマットされてもよい。ダウンロード通知メッセージ１２１２において用いられるステータスコードの一例を以下の表１５に示す。

【0202】

【表15】

【0203】

上に記載されるステータス報告に加えて、ダウンロード通知メッセージ１２０８は、ダウンロードおよび／またはダウンロードの失敗に関連してもよいさらなるステータス情報を含んでもよい。

【0204】

６．通知応答
ソフトウェア更新サーバ１２００は、ダウンロード通知メッセージ１２１２または更新通知メッセージ１２１６に応答して通知応答メッセージ１２１４で応答してもよい。通知応答メッセージ１２１４は、上に記載されるように、ステータス報告フォーマットを含んでもよい。たとえば、通知応答メッセージ１２１４は以下の表１６に列挙されるステータスコードを含んでもよい。

【0205】

【表16】

【0206】

上記のステータス報告に加えて、通知応答メッセージ１２１４は、ソフトウェア更新をダウンロード、更新、および／またはダウンロード／更新の失敗に関係してもよいさらなるステータス情報を含んでもよい。

【0207】

７．更新通知
更新が成功裏に完了するかまたは失敗して報告ステータスフラグ１２８０値が１になったあと、ソフトウェア更新クライアント１１９８は更新通知メッセージ１２１６で応答してもよい。更新通知メッセージ１２１６は上に記載されるステータス報告フォーマットを用いてもよい。たとえば、更新通知メッセージ１２１６は、以下の表１７において列挙されるステータスコードを含んでもよい。

【0208】

【表17】

【0209】

上記のステータス報告に加えて、更新通知メッセージ１２１６は、更新および／または更新の失敗に関係してもよいさらなるステータス情報を含んでもよい。

【0210】

Ｃ．データ管理プロトコル
データ管理は、ファブリック内におけるさまざまな電子装置において用いられる共通のプロファイル（たとえばコアプロファイル）に含まれてもよく、または別個のプロファイルとして指定されてもよい。いずれの状況においても、装置管理プロトコル（ＤＭＰ）を用いて、ノードがノード常駐情報をブラウジング、共有および／または更新してもよい。ＤＭＰにおいて用いられるシーケンス１２８４が図３６に示される。シーケンス１２８４は、被閲覧側ノード１２８８の常駐データを閲覧および／または変更するよう要求する閲覧側ノード１２８６を示す。加えて、閲覧側ノード１２８６は、スナップショット要求、閲覧がある時間期間にわたって持続する旨の監視要求、または他の好適な閲覧タイプなどのような、いくつかの閲覧オプションのうちの１つを用いて、常駐データを閲覧することを要求してもよい。各メッセージは、図２１を参照して記載されるアプリケーションペイロード１１４６に対するフォーマットに従う。たとえば、各メッセージは、0x235A0000のような、データ管理プロファイルおよび／または関係のあるコアプロファイルに対応するプロファイルＩｄ１１７６を含む。各メッセージは、さらに、メッセージタイプ１１７２を含む。メッセージタイプ１１７２は、ビューに対する閲覧タイプのような、会話に関係するさまざまなファクタを判断するのに用いられてもよい。たとえば、いくつかの実施の形態では、メッセージタイプフィールド１１７２は以下の表１８に従ってエンコード／デコードされてもよい。

【0211】

【表18】

【0212】

ｉ．ビュー要求
ビュー要求メッセージ１２９０は、上で論じられたように、ノード常駐データを閲覧するよう要求するが、要求のタイプはメッセージタイプフィールド１１７２によって判断されてもよい。したがって、各要求タイプは異なるビュー要求フレームを含んでもよい。

【0213】

１．スナップショット要求
スナップショット要求は、閲覧側ノード１２８６が今後の更新を要求することなく被閲覧側ノード１２８８上のノード常駐データに対する即時ビューを所望するときに閲覧側ノード１２８６によって送信されてもよい。スナップショット要求フレーム１２９２の実施の形態を図３７に示す。

【0214】

図３７に示されるように、スナップショット要求フレーム１２９２は、長さが可変であってもよく、３つのフィールド：ビューハンドルフィールド１２９４とパス長リストフィールド１２９６とパスリストフィールド１２９８とを含んでもよい。ビューハンドルフィールド１２９４は、要求されたビューを識別するよう「ハンドル」を与える２つのビットを含んでもよい。いくつかの実施の形態では、ビューハンドルフィールド１２９４は、１６ビットの乱数または１６ビットのシーケンス番号を、要求が形成されるときに閲覧側ノード１２８６上で実行される一意性チェックとともに用いて、事前設定される。パスリスト長フィールド１２９６は、パスリストフィールド１２９８の長さを示す２つのバイトを含む。パスリストフィールド１２９８は、長さが可変であり、パスリスト長フィールド１２９６の値によって示される。パスリストフィールド１２９８の値はノードに対するスキーマパスを示す。

【0215】

スキーマパスは、ノードに常駐するスキーマの一部であるデータ項目またはコンテナに対する簡潔な記述である。たとえば、図３８は、プロファイルスキーマ１３００の一例を与える。示されるプロファイルスキーマ１３００においては、データ項目１３０２へのパスがバイナリフォーマットで“Foo:bicycle:mountain”（Foo：自転車：マウンテン）と
書かれてもよい。パスのバイナリフォーマットは、図３９に示されるように、プロファイルバイナリフォーマット１３０４として表現されてもよい。プロファイルバイナリフォーマット１３０４は、２つのサブフィールド：プロファイル識別子フィールド１３０６とＴＬＶデータフィールド１３０８とを含む。プロファイル識別子フィールド１３０６は、どのプロファイルが参照されているか（たとえばFooプロファイル）を識別する。ＴＬＶデ
ータフィールド１３０８パス情報。先に論じられたように、ＴＬＶデータは、同封されたデータについての情報を含むタグフィールドを含む。図３８のFooプロファイルを指すよ
う用いられるタグフィールド値は表１９にリスト化された値と同様であってもよい。

【0216】

【表19】

【0217】

表１９および図３８のFooプロファイルを用いて、パス“Foo:bicycle:mountain”を表わ
すＴＬＶフォーマットにおけるバイナリ文字列が、以下の表２０に示されるように表現されてもよい。

【表20】

【0218】

閲覧側ノード１２８６が、プロファイルスキーマ（たとえば図３９のFooプロファイルス
キーマ）に定義される全データを受信することを所望する場合には、ビュー要求メッセージ１２９０は、「ニル」項目（たとえば0x0D00 TLおよびコンテナを指す空の長さを要求
してもよい。

【0219】

２．監視要求
閲覧側ノード１２８６がスナップショット以上のものを所望する場合には、閲覧側ノード１２８６は監視要求を要求してもよい。監視要求は、被閲覧側ノード１２８８における当該のデータに変更がなされるときに被閲覧側ノード１２８８に対して更新を送信するよう求めて、閲覧側ノード１２８６がそのデータの同期されたリストを保持できるようにする。監視要求フレームは、図３７のスナップショット要求とは異なるフォーマットを有してもよい。監視要求フレーム１３１０の実施の形態が図４０に示される。監視要求フレーム１３１０は４つのフィールド：ビューハンドルフィールド１３１２とパスリスト長フィールド１３１４とパスリストフィールド１３１６と変更カウントフィールド１３１８とを含む。ビューハンドルフィールド１３１２、パスリスト長フィールド１３１４、およびパスリストフィールドは、それぞれ、図３７のスナップショット要求のビューハンドルフィールド１２９４、パスリスト長フィールド１２９６、およびパスリストフィールド１２９
８と同様にフォーマットされてもよい。さらなるフィールドの変更カウントフィールド１３１８は、更新が閲覧側ノード１２８６に送信される要求されたデータの変更数のしきい値を示す。いくつかの実施の形態では、変更カウントフィールド１３１８の値が０である場合には、被閲覧側ノード１２８８は、更新をいつ送信するべきかを被送信側ノード１２８８自身で判断してもよい。変更カウントフィールド１３１８の値が０でない場合には、変更の数がその値と等しくなった後、更新が閲覧側ノード１２８６に送信される。

【0220】

３．周期的更新要求
第３のタイプのビューが、さらに、閲覧側ノード１２８６によって要求されてもよい。この第３のタイプのビューは周期的更新と称される。周期的更新はスナップショットビューを周期的更新と並んで含む。理解され得るように、周期的更新要求はスナップショット要求と同様であってもよいが、さらなる情報が更新期間を決める。たとえば、周期的更新要求フレーム１３２０の実施の形態が図４１に示される。周期的更新要求フレーム１３２０は４つのフィールド：ビューハンドルフィールド１３２２とパスリスト長フィールド１３２４とパスリストフィールド１３２６と更新期間フィールド１３２８とを含む。ビューハンドルフィールド１３２２とパスリスト長フィールド１３２４とパスリストフィールド１３２６とはスナップショット要求フレーム１２９２におけるそれらの対応のフィールドと同様にフォーマットされてもよい。更新期間フィールド１３２８は、長さが４つのバイトであり、関連する時間単位（たとえば秒）で更新間において経過する時間期間に対応する値を含む。

【0221】

４．リフレッシュ要求
閲覧側ノード１２８６が更新されたスナップショットを受信することを所望する場合には、閲覧側ノード１２８６は、ビュー要求メッセージ１２９０を、図４２に示されるリフレッシュ要求フレーム１３３０の形式で送信してもよい。リフレッシュ要求フレーム１３３０は、本質的には、リフレッシュ要求フレーム１３３０におけるビューハンドル値を用いて、被閲覧側ノード１２２８が前の要求として認識することができる前のスナップショット要求から、スナップショットビューハンドルフィールド（たとえばビューハンドルフィールド１２９４）を再送信する。

【0222】

５．ビュー取消要求
閲覧側ノード１２８６が進行中のビュー（たとえば周期的更新または監視ビュー）を取消すよう所望するときには、閲覧側ノード１２８６は、ビュー要求メッセージ１２９０を、図４３に示されるようなビュー取消要求フレーム１３３２の形式で送信してもよい。ビュー取消要求フレーム１３３２は、本質的に、リフレッシュ要求フレーム１３３０におけるビューハンドル値を用いて、現在の周期的更新または監視ビューを取消すために、被閲覧側ノード１２８８が前の要求として認識できる前の要求からの前の周期的更新または監視ビュー（たとえばビューハンドルフィールド１３１０または１３２２）からビューハンドルフィールドを再送信する。

【0223】

ｉｉ．ビュー応答
図３６に戻って、被閲覧側ノード１２８８がビュー要求メッセージ１２９０を受信した後、被閲覧側ノード１２８８はビュー応答メッセージ１３３４で応答する。ビュー応答メッセージフレーム１３３６の一例が図４４に示される。ビュー応答メッセージフレーム１３３６は３つのフィールド：ビューハンドルフィールド１３３８とビュー要求ステータスフィールド１２４０とデータ項目リスト１２４２とを含む。ビューハンドルフィールド１３３８は、上において参照されるビューハンドルフィールド１３３８のうちの任意のものと同様にフォーマットされてもよい。加えて、ビューハンドルフィールド１３３８は、ビュー応答メッセージ１３３４が応答しているビュー要求メッセージ１２９０からのそれぞれのビューハンドルフィールドと一致する値を含む。ビュー要求ステータスフィールド１
３４０は、ビュー要求のステータスを示す可変長フィールドであり、上で論じられたステータス更新フォーマットに従ってフォーマットされてもよい。データ項目リストフィールド１３４２は、ビュー要求が成功した旨をビュー要求ステータスフィールド１３４０が示すときに存在する可変長フィールドである。存在する場合には、データ項目リストフィールド１３４２は、ビュー要求メッセージ１２９０のパスリストに対応する要求されるデータの順序づけられたリストを含む。さらに、データ項目リストフィールド１３４２におけるデータは、上で論じられるように、ＴＬＶフォーマットでエンコードされてもよい。

【0224】

ｉｉｉ．更新要求
上で論じられたように、いくつかの実施の形態では、被閲覧側ノード１２８８は閲覧側ノード１２８６に更新を送信してもよい。これらの更新は更新要求メッセージ１３４４として送信されてもよい。更新要求メッセージ１３４４は、更新要求のタイプによって、指定されたフォーマットを含んでもよい。たとえば、更新要求は、明示的な更新要求であるか、またはメッセージＩｄ１１７２によって識別されてもよいビュー更新要求フィールドであってもよい。

【0225】

１．明示的更新要求
明示的更新要求は、任意の時間において、ファブリック１０００における他のノードからの情報を所望する結果として送信されてもよい。明示的更新要求は、図４５に示される更新要求フレーム１３４６でフォーマットされてもよい。示される更新要求フレーム１３４６は４つのフィールド：更新ハンドルフィールド１３４８とパスリスト長フィールド１３５０とパスリストフィールド１３５２とデータ項目リストフィールド１３５４とを含む。

【0226】

更新ハンドルフィールド１３４８は、乱数または連続数、および更新要求またはその要求に対する応答を識別する一意性チェックで事前設定されてもよい。パスリスト長フィールド１３５０は、パスリストフィールド１３５２の長さを示す２つのバイトを含む。パスリストフィールド１３５２は、上記のように、パスのシーケンスを示す可変長フィールドである。データ項目リストフィールド１３５４はデータ項目リストフィールド１２４２と同様にフォーマットされてもよい。

【0227】

２．ビュー更新要求
ビュー更新要求メッセージは、以前に別のノードのスキーマに対するビューを要求したノード、またはそれ自身のデータに対するビューを別のノードに代わって確立したノードによって送信されてもよい。ビュー更新要求フレーム１３５６の実施の形態が図４６に示される。ビュー更新要求フレーム１３５６は４つのフィールド：更新ハンドルフィールド１３５８とビューハンドルフィールド１３６０と更新項目リスト長フィールド１３６２と更新項目リストフィールド１３６４とを含む。更新ハンドルフィールド１３５８は、更新ハンドルフィールド１３４８に関して上で論じられたフォーマットを用いて構成されてもよい。ビューハンドルフィールド１３６０は、同じビューハンドルを有する関係のあるビュー要求メッセージ１２９０によって形成されるビューを識別する２つのバイトを含む。更新項目リスト長フィールド１３６２は、２つのバイトを含み、更新項目リストフィールド１３６４に含まれる更新項目の数を示す。

【0228】

更新項目リストフィールド１３６４は、可変数のバイトを含み、更新された値を構成するデータ項目をリスト化する。各更新された項目リストは複数の更新項目を含んでもよい。個々の更新項目は、図４７に示される更新項目フレーム１３６６に従ってフォーマットされる。各更新項目フレーム１３６６は３つのサブフィールド：項目インデックスフィールド１３６８と項目タイムスタンプフィールド１３７０とデータ項目フィールド１３７２とを含む。項目インデックスフィールド１３６８は、更新が要求されているビューと、デ
ータ項目フィールド１３７２に対するそのビューのパスリストにおけるインデックスとを示す２つのバイトを含む。

【0229】

項目タイムスタンプフィールド１３７０は、４つのバイトを含み、変更から通信されている更新がなされるまでの経過時間を（たとえば秒で）示す。２つ以上の変更がデータ項目に対してなされた場合には、項目タイムスタンプフィールド１３７０は最も最近の変更または最も早い変更を示してもよい。データ項目フィールド１３７２は、更新された情報として受信されることになるＴＬＶフォーマットでエンコードされた可変長フィールドである。

【0230】

ｉｖ．更新応答
更新が受信された後、ノード（たとえば閲覧側ノード１２８６）は更新応答メッセージ１３７４を送信してもよい。更新応答メッセージ１３７４は、図４８に示される更新応答フレーム１３７６を用いてエンコードされてもよい。更新応答フレーム１３７６は２つのフィールド：更新ハンドルフィールド１３７８と更新要求ステータスフィールド１３８０とを含む。更新ハンドルフィールド１３７８は、更新応答メッセージ１３７４が応答している更新要求メッセージ１３４４の更新ハンドルフィールドの値に対応する。更新要求ステータスフィールド１３８０は、上で論じられたステータス報告フォーマットに従って更新のステータスを報告する。加えて、ＤＭＰを用いるプロファイル（たとえばコアプロファイルまたはデータ管理プロファイル）は、以下の表２１に列挙されるもののようなプロファイル特定コードを含んでもよい。

【0231】

【表21】

【0232】

Ｄ．大容量転送
いくつかの実施の形態では、大容量データファイル（たとえばセンサデータ、ログ、または更新イメージ）をファブリック１０００におけるノード／サービス間で転送することが望ましくあり得る。大容量データの転送を可能にするために、別のファイルまたはプロトコルを１つ以上のプロファイルに組込んで、ノード／ノードにおけるサービスに利用可能にされてもよい。大容量データ転送プロトコルは、データファイルを、データの集まりとして、メタデータアタッチメントとともにモデル化してもよい。ある実施の形態では、データは不透明であってもよいが、メタデータを用いて、要求されたファイル転送に進んでもよいかを判断してもよい。

【0233】

大容量転送に関与する装置は、一般的に、大容量転送通信およびイベント形成に従って分割されてもよい。図４９に示されるように、大容量転送における各通信１４００は、送信側１４０２を含み、それは、大容量データ１４０４を受信するノード／サービスである受信側１４０６に大容量データ１４０４を送信するノード／サービスである。いくつかの実施の形態では、受信側は、ステータス情報１４０８を送信側１４０２に送信して、大容量転送のステータスを示してもよい。加えて、大容量転送イベントは、送信側１４０２（たとえばアップロード）または受信側１４０６（たとえばダウンロード）のどちらかが開始側として開始されてもよい。開始側に応答するノード／サービスは、大容量データ転送
において応答側と称されてもよい。

【0234】

大容量データ転送は同期モードまたは非同期のいずれかを用いて生じてもよい。データが転送されるモードは、大容量データが送信される基底プロトコル（たとえばＵＤＰまたはＴＣＰ）などのようなさまざまなファクタを用いて判断されてもよい。無接続プロトコル（たとえばＵＤＰ）においては、大容量データは同期モードを用いて転送されてもよく、それは、ノード／サービスの１つ（「ドライバ」）が、転送が進行する速度を制御することを可能にする。ある実施の形態では、同期モード大容量データ転送における各メッセージの後、大容量データ転送において次のメッセージを送信する前に、肯定応答が送信されてもよい。ドライバは送信側１４０２または受信側１４０６であってもよい。いくつかの実施の形態では、ドライバは、オンライン状態とオフライン状態との間をトグルして、オンライン状態にあるときには転送を進めるようメッセージを送信してもよい。接続指向型プロトコル（たとえばＴＣＰ）を用いての大容量データ転送においては、大容量データは、連続するメッセージを送信する前の肯定応答または単一のドライバを用いない非同期モードを用いて転送されてもよい。

【0235】

大容量データ転送が同期モードまたは非同期モードを用いて実行されるかどうかに関わらず、メッセージのタイプは、アプリケーションペイロード１１４６におけるメッセージタイプ１１７２を用いて、アプリケーションペイロードにおけるプロファイルＩｄ１１７６に従って判断されてもよい。表２２は、プロファイルＩｄ１１７６における大容量データ転送プロファイル値と関連して用いられてもよいメッセージタイプの一例を含む。

【0236】

【表22】

【0237】

ｉ．SendInit（送信開始）
SendInit（送信開始）メッセージ１４２０の実施の形態を図５０に示す。SendInitメッセージ１４２０は７つのフィールド：転送制御フィールド１４２２と範囲制御フィールド１４２４とファイル指示子長フィールド１４２６と提案される最大ブロックサイズフィールド１４２８と開始オフセットフィールド１４３０と長さフィールド１４３２とファイル指示子フィールド１４３４とを含んでもよい。

【0238】

転送制御フィールド１４２２は、図５１に示されるバイトのデータを含む。転送制御フ
ィールドは少なくとも４つのフィールド：非同期フラグ１４５０とＲドライブフラグ１４５２とＳドライブフラグ１４５４とバージョンフィールド１４５６とを含む。非同期フラグ１４５０は、提案される転送が同期モードまたは非同期モードを用いて実行されてもよいかどうかを示す。Ｒドライブフラグ１４５２およびＳドライブフラグ１４５４は、各々、それぞれ、受信側１４０２または送信側１４０８が同期モード転送を駆動する状態で、受信側１４０６がデータを転送する能力があるかどうかを示す。

【0239】

範囲制御フィールド１４２４は、図５２に示される範囲制御フィールド１４２４のようなバイトのデータを含む。示される実施の形態では、範囲制御フィールド１４２４は少なくとも３つのフィールド：BigExtentフラグ１４７０と開始オフセットフラグ１４７２と
有限長フラグ１４７４とを含む。有限長フラグ１４７４は転送が有限長を有するかどうかを示す。有限長フラグ１４７４は、長さフィールド１４３２がSendInitメッセージ１４２０に存在するかどうかを示し、BigExtentフラグ１４７０は長さフィールド１４３２に対
するサイズを示す。たとえば、いくつかの実施の形態では、BigExtentフラグ１４７０に
おける１の値は長さフィールド１４３２が８バイトであることを示す。そうでない場合には、長さフィールド１４３２は、存在する場合には、４バイトである。転送が有限長を有する場合には、開始オフセットフラグ１４７２は、開始オフセットがあるかどうかを示す。開始オフセットがある場合には、BigExtentフラグ１４７０は開始オフセットフィール
ド１４３０に対する長さを示す。たとえば、いくつかの実施の形態では、BigExtentフラ
グ１４７０における１の値は、開始オフセットフィールド１４３０が８バイトであることを示す。そうでない場合には、開始オフセットフィールド１４３０は、存在する場合には４バイトである。

【0240】

図５０に戻って、ファイル指示子長フィールド１４２６は、ファイル指示子フィールド１４３４の長さを示す２つのバイトを含む。ファイル指示子フィールド１４３４は、ファイル指示子長フィールド１４２６に依存する可変長フィールドである。最大ブロックサイズフィールド１４２８は、単一の転送において転送されてもよいブロックの最大サイズを提案する。

【0241】

開始オフセットフィールド１４３０は、存在するときには、BigExtentフラグ１４７０
によって示される長さを有する。開始オフセットフィールド１４３０の値は、送信側１４０２が転送を開始してもよい転送されるべきファイル内の位置を示し、大きなファイル転送が複数の大容量転送セッションにセグメント化されることを本質的に可能にする。

【0242】

長さフィールド１４３２は、存在するときには、転送されるべきファイルが有限長を有する旨を有限長フィールド１４７４が示す場合には、そのファイルの長さを示す。いくつかの実施の形態では、その長さが達成される前に受信側１４０２が最終のブロックを受信する場合には、受信側は、以下に論じられるように、転送は失敗したと考え、エラーを報告してもよい。

【0243】

ファイル指示子フィールド１４３４は、送信されるべきデータを識別するよう送信側１４０２によって選択される可変長識別子である。いくつかの実施の形態では、送信側１４０２および受信側１４０６は、送信前にファイルに対する識別子を交渉してもよい。他の実施の形態では、受信側１４０６は、メタデータをファイル指示子フィールド１４３４とともに用いて、転送を受入れるべきかどうか、およびそのデータを処理すべきかどうかを判断してもよい。ファイル指示子フィールド１４３４の長さはファイル指示子長フィールド１４２６から判断されてもよい。いくつかの実施の形態では、SendInitメッセージ１４２０は、さらに、ＴＬＶフォーマットでエンコードされる可変長のメタデータフィールド１４８０を含んでもよい。メタデータフィールド１４８０は、開始側が、転送されるべきファイルについてのアプリケーション特定情報のようなさらなる情報を送信することを可
能にする。いくつかの実施の形態では、メタデータフィールド１４８０を用いて、大容量データ転送前にファイル指示子フィールド１４３４と交渉することを回避してもよい。

【0244】

ｉｉ．SendAccept（送信受入）
送信受入メッセージは、転送のために選択された転送モードを示すよう応答側から送信される。SendAcceptメッセージ１５００の実施の形態を図５３に示す。SendAcceptメッセージ１５００は、SendInitメッセージ１４２０の転送制御フィールド１４２２と同様の転送制御フィールド１５０２を含む。しかしながら、いくつかの実施の形態では、Ｒドライブフラグ１４５２またはＳドライブフラグ１４５４のみが転送制御フィールド１５０２において非ゼロの値を有して、送信側１４０２または受信側１４０６を同期モード転送のドライバとして識別してもよい。SendAcceptメッセージ１５００は、さらに、転送に対する最大ブロックサイズを示す最大ブロックサイズフィールド１５０４を含む。ブロックサイズフィールド１５０４はSendInitメッセージ１４２０の最大ブロックフィールド１４２８の値と等しくてもよいが、最大ブロックサイズフィールド１５０４の値は最大ブロックフィールド１４２８において提案される値より小さくてもよい。最後に、SendAcceptメッセージ１５００は、受信側１５０６が転送について送信側１４０２に渡してもよい情報を示すメタデータフィールド１５０６を含んでもよい。

【0245】

ｉｉｉ．SendReject（送信拒絶）
受信側１２０６がSendInitメッセージの後に転送を拒絶するときには、受信側１２０６はSendReject（送信拒絶）メッセージを送信して、１つ以上の問題が送信側１２０２と受信側１２０６との間における大容量データ転送に関して存在することを示してもよい。送信拒絶メッセージは、上に記載され図５４に示されるステータス報告フォーマットに従ってフォーマットされてもよい。送信拒絶フレーム１５２０は、転送を拒絶する理由を示す２つのバイトを含むステータスコードフィールド１５２２を含んでもよい。ステータスコードフィールド１５２２は、下の表２３に示されるように列挙されるものと同様の値を用いてデコードされてもよい。

【0246】

【表23】

【0247】

いくつかの実施の形態では、送信拒絶メッセージ１５２０は次のステータスフィールド１５２４を含んでもよい。次のステータスフィールド１５２４は、存在するときには、ステータス報告フレームの次のステータスフィールド１１８８に関して上で論じられたようにフォーマットされエンコードされてもよい。ある実施の形態では、送信拒絶メッセージ１
５２０はさらなる情報フィールド１５２６を含んでもよい。さらなる情報フィールド１５２６は、存在するときには、さらなるステータスについての情報を格納し、上で論じられたＴＬＶフォーマットを用いてエンコードされてもよい。

【0248】

ｉｖ．ReceiveInit（受信開始）
ReceiveInit（受信開始）メッセージは、開始側としての受信側１２０６によって送信
されてもよい。ReceiveInitメッセージは、図５０に示されるSendInitメッセージ１４８
０と同様にフォーマットおよびエンコードされてもよいが、BigExtentフィールド１４７
０は、受信側１２０６が処理することができる最大ファイルサイズを指定する最大長フィールドとして称されてもよい。

【0249】

ｖ．ReceiveAccept（受信受入）
送信側１２０２がReceiveInitメッセージを受信すると、送信側１２０２はReceiveAccept（受信受入）メッセージで応答してもよい。ReceiveAcceptメッセージは、図５５に示
されるReceiveAcceptメッセージ１５４０としてフォーマットおよびエンコードされても
よい。ReceiveAcceptメッセージ１５４０は４つのフィールド：転送制御フィールド１５
４２と範囲制御フィールド１５４４と最大ブロックサイズフィールド１５４６と、ときとして長さフィールド１５４８とを含んでもよい。ReceiveAcceptメッセージ１５４０は、
図５３のSendAcceptメッセージ１５０２と同様にフォーマットされてもよいが、第２のバイトは範囲制御フィールド１５４４を示す。さらに、範囲制御フィールド１５４４は、図５２の範囲制御フィールド１４２４に関して上で論じられた同じ方法を用いてフォーマットおよびエンコードされてもよい。

【0250】

ｖｉ．ReceiveReject（受信拒絶）
送信側１２０２が、受信側１２０６にファイルを転送することで問題に遭遇する場合には、送信側１２０２は、両方とも上で論じられた、ステータス報告フォーマットを用いてSendRejectメッセージ４８と同様にフォーマットおよびエンコードされるReceiveReject
（受信拒絶）メッセージを送信してもよい。しかしながら、ステータスコードフィールド１５２２は、以下に表２４に示されるように列挙されるものと同様の値を用いてエンコード／デコードされてもよい。

【0251】

【表24】

【0252】

ｖｉｉ．BlockQuery（ブロッククエリ）
BlockQueryメッセージは、次のブロックのデータを要求するよう駆動側受信側１２０２によって同期モード大容量データ転送において送信されてもよい。BlockQueryは、明示的
でない肯定応答が送信された場合には前のデータのブロックの受信を暗示的に肯定応答する。非同期転送を用いる実施の形態では、BlockQueryメッセージは伝送プロセスから省略されてもよい。

【0253】

ｖｉｉｉ．Block（ブロック）
大容量データ転送において送信されるデータのブロックは、０より大きく、かつ送信側１２０２および受信側１２０６によって同意された最大ブロックサイズ未満の、任意の長さを含んでもよい。

【0254】

ｉｘ．BlockEOF（ファイルの終わりブロック）
データ転送における最終のブロックはファイルの終わりブロック（BlockEOF）として提示されてもよい。BlockEOFは０と最大ブロックサイズとの間の長さを有してもよい。受信側１２０６が、予め交渉されたファイルサイズ（たとえば長さフィールド１４３２）と実際に転送されたデータの量との間に相違を見出す場合には、受信側１２０６は、以下に論じられるように、失敗を示すError（エラー）メッセージを送信してもよい。

【0255】

ｘ．Ack（肯定応答）
送信側１２０２が同期モード転送を駆動している場合には、送信側１２０２は、Block
の送信後と次のBlockの送信前との間に肯定応答（Ack）を受信するまで待機してもよい。受信側が同期モード転送を駆動している場合には、受信側１２０６は、明示的AckまたはBlockQueryのいずれかを送信して、前のブロックの受信を肯定応答してもよい。さらに、
非同期モード大容量転送においては、Ackメッセージは伝送プロセスから全く省略されて
もよい。

【0256】

ｘｉ．AckEOF（ファイルの終わりの肯定応答）
ファイルの終わりの肯定応答（AckEOF）は、同期モードまたは非同期モードにおいて送信される大容量転送において送信されてもよい。AckEOFを用いて、受信側１２０６は、転送におけるすべてのデータが受信されたことを示し、大容量データ転送セッションの終わりを信号送信する。

【0257】

ｘｉｉ．Error
通信におけるある問題の発生で、送信側１２０２または受信側１２０６は、エラーメッセージを送信して、大容量データ転送セッションを早く終わらせてもよい。エラーメッセージは、上で論じられたステータス報告フォーマットに従ってフォーマットおよびエンコードされてもよい。たとえば、エラーメッセージは、図５４のSendRejectフレーム１５２０と同様にフォーマットされてもよい。しかしながら、ステータスコードは、値が以下の表２５に列挙されるものを含む、および／またはそれらと同様である状態で、エンコード／デコードされてもよい。

【0258】

【表25】

【0259】

上に記載される具体的な実施の形態は例示によって示されたものであり、これらの実施の形態はさまざまな修正および代替形式が可能であり得ることが理解されるべきである。さらに、特許請求の範囲は開示される特定の形式に限定されるよう意図されるものではなく、本開示の精神および範囲内に入るすべての修正物、均等物および代替物を包含することが理解されるべきである。

【0260】

―効率的通信使用例および電力認識―
上で論じられた効率的ＩＰｖ６ ８０２．１５．４ネットワークプロトコルおよび／または効率的プラットフォームプロトコルは、住宅環境において電力効率的な動作を可能にしてもよい。以下に論じられるように、一例においては、そのような通信は、ある特定の好まれるネットワークを横断してＩＰｖ６パケットを通信することを含んでもよい。加えて、または代替的に、メッセージを伝送するのに用いられるタイプのトランスポートプロトコル－ＴＣＰまたはＵＤＰ－のような、通信の態様のプロパティも選択可能であってもよい。たとえば、節電量はより少ないが、より大きな信頼性を与えるためには、ＴＣＰが選択されてもよく、一方、信頼性はより低いが、より大きな節電量を与えるためには、ＵＤＰが選択されてもよい。

【0261】

―ＩＰｖ６パケットヘッダフィールドを用いるスマート通信―
上に示されるように、ＩＰｖ６パケットヘッダにおいて利用可能なフィールドは、本開示のシステムにおいては、メッセージを受信するよう目標化されるファブリック１０００の目標ノードに関する情報を搬送するよう用いられてもよい。たとえば、図５６に示されるように、ある特定のノードに目標を定められたＩＰｖ６パケットのパケットヘッダ１６００は、ＭＡＣフィールド１６０２とサブネットフィールド１６０４とファブリックＩＤフィールド１６０６とを含んでもよい。ＭＡＣフィールド１６０２は、拡張固有識別子を表現すると通常は理解される６４ビットの領域を満たしてもよい（ＥＵＩ－６４）。ＭＡＣフィールド１６０２は、目標ノードのＭＡＣアドレスを示すものを含んでもよい。サブネットフィールド１６０４およびファブリックＩＤフィールド１６０６は、まとめて、拡張固有ローカルアドレス（ＥＵＬＡ）を表現してもよい。これらのフィールドのＥＵＬＡでは、ファブリックＩＤフィールド１６０６は、ＩＰｖ６パケットが送信されることになる特定のファブリック１０００を示してもよく、一方、サブネットフィールド１６０４は、目標ノードが好ましくはメッセージを受信するファブリック１０００内における好まれるネットワークを識別してもよい。図５６の例では、サブネットフィールド１６０４は、目標ノードが好ましくはある特定のＷｉＦｉネットワークを介してメッセージを受信してもよいことを示す。ファブリックＩＤフィールド１６０６およびサブネットフィールド１６０４によって形成されるＥＵＬＡは、ＩＰｖ６パケットが全体的に１つ以上の接続されたファブリックおよび／またはそれらのファブリックに従うサービス内において送信されているときに用いられてもよいことが理解されるべきである。ＩＰｖ６パケットがファブリック１０００のノードから外部のＩＰｖ６インターネットアドレスに送信されることになるときには、異なる（たとえばより従来的な）ＩＰｖ６パケットヘッダ構造が用いられてもよい。

【0262】

サブネットフィールド１６０４およびファブリックＩＤフィールド１６０６のＥＵＬＡ情報を用いて、ＩＰｖ６パケットをファブリック１０００を介して目標ノードに向かって効率的に通信することができる。図５７に示される例では、メッセージが、図１１を参照して上に論じられたネットワークトポロジを介して送信される。ここでは、ノード１０２６が送信側ノードであり、ノード１０３６が目標ノードである。ノード１０２６は８０２．１５．４ネットワーク１０２２上で動作し、一方、目標ノード１０３６は８０２．１５．４ネットワーク１０２２およびＷｉＦｉネットワーク１０２０の両方上において動作する。目標ノード１０３６の好まれるネットワークは、図５７の例においては、ＷｉＦｉネ
ットワーク１０２０であるよう表現される。したがって、送信側ノード１０２６から目標ノード１０３６にメッセージを送信するよう用いられるＩＰｖ６パケットは、一般的には、図５６のＩＰｖ６パケット１６００に示される特性を有してもよい。

【0263】

さまざまなノード１０２６、１０２８、１０３０、１０３４および１０４２が、図５７において、メッセージを送信側ノード１０２６から目標ノード１０３６に通信するよう示される。メッセージが送信されるネットワークが１つだけあるときには、そのメッセージはそのネットワークを介して通信されてもよい。これは、図５７の例においてはノード１０２６、１０２８および１０３０の場合である。メッセージがノード１０３４のような２つ以上のネットワーク上において動作するノードに到達する場合には、そのノードは、サブネットフィールド１６０４を用いて、どのネットワークを用いるかを判断して、メッセージをさらに目標ノード１０３６に向かって通信してもよい。

【0264】

図５８のフローチャート１６５０は、パケットヘッダ１６００のサブネットフィールド１６０４を用いてＩＰｖ６パケットを目標ノードに向かって通信するための方法の一例を示す。この方法では、２つのネットワーク上で動作するノード（たとえばノード１０３４であり、それはＷｉＦｉネットワーク１０２０および８０２．１５．４ネットワーク１０２２の両方上で動作する）がＩＰｖ６パケットを受信してもよい（ブロック１６５２）。ノードは、ＩＰｖ６パケットヘッダ１６００のサブネットフィールド１６０４を解析して、どのネットワークがＩＰｖ６パケットを目標ノードに転送するのに用いるのに最も適切なネットワークであるかを判断してもよい。サブネットフィールド１６０４は、たとえば、メッセージが目標ノード（たとえばノード１０３６）によってＷｉＦｉネットワーク１０２０上において受信されることになる旨を示してもよい。受信側ノード（たとえばノード１０３４）は、次いで、ＩＰｖ６パケットを、目標ノード（たとえばノード１０３６）に向かって、サブネットフィールド１６０４によって示されるネットワーク（たとえばＷｉＦｉネットワーク１０２０）を渡って通信してもよい（ブロック１６５４）。

【0265】

いくつかの例では、ＩＰｖ６パケットが受信されたネットワークは、サブネットフィールド１６０４によって示されるネットワークと異なっていてもよい。図５７では、たとえば、ノード１０３４はメッセージを８０２．１５．４ネットワーク１０２２を介して受信する。しかしながら、サブネットフィールド１６０４が、ＷｉＦｉネットワーク１０２０がＩＰｖ６パケットを送信するのに用いられるのに好まれるネットワークである旨を示す場合には、ノード１０３４は、ＩＰｖ６パケットを代わりにＷｉＦｉネットワーク１０２０を介して通信してもよい。このようにして、サブネットフィールド１６０４は、目標ノードが、メッセージを受信する好まれるネットワークを有することを可能にしてもよい。図５７の例では、目標ノード１０３６は、８０２．１５．４ネットワーク１０２２よりもＷｉＦｉネットワーク１０２０を渡ってより速やかに、またはより信頼性をもって通信し得る常にオンの電子装置であってもよい。他の例では、目標ノード１０３６は、８０２．１５．４ネットワーク１０２２を介してメッセージを受信するのによりよく供されるであろう、バッテリにより電力を供給されるスリーピー状態の装置であってもよい。そのような例では、目標ノード１０３６はＷｉＦｉネットワーク１０２０を介してメッセージを受信し得るが、サブネットフィールド１６０４によって示され得るように８０２．１５．４ネットワーク１０２２を介してメッセージを受信することによって、目標ノード１０３６は電力を節約し得る。したがって、ＩＰｖ６パケットヘッダ１６００のＥＵＬＡ（たとえばファブリックＩＤフィールド１６０６およびサブネットフィールド１６０４）を用いてファブリックを介して効率的なメッセージ転送を促進してもよい。

【0266】

―所望されるメッセージの信頼度に基づく、トランスポートプロトコルまたは好まれる目標ネットワークの選択―
ＩＰｖ６パケットを送信するよう用いられるトランスポートプロトコル（たとえばＴＣ
ＰまたはＵＤＰ）および／または好まれる目標ノードネットワークの賢明な選択は、さらに、効率的なネットワークの使用にも至り得る。実際、ＴＣＰはＵＤＰよりも信頼性があるが、ＴＣＰの信頼性は、メッセージを送信する際のハンドシェイキングおよび肯定応答の使用から生じ、それらの多くはＵＤＰにはない。しかしながら、ＴＣＰのさらなる信頼性は、消費される電力に関して、メッセージを送信するコストを増大させ得る。実際、ＴＣＰのハンドシェイキングおよび肯定応答のため、電力におけるさらなるコストがある。加えて、ＴＣＰを用いることは、落ちたパケットが確認されるように受信されるまで再送信させられることになり、落ちたパケットを被るすべての装置においてさらなる電力を消費することになる。

【0267】

したがって、信頼性が電力効率性よりも好まれる理由がなければ、ＵＤＰによってメッセージを送信することが望ましいかもしれない。たとえば、図５９のフローチャート１６７０に示されるように、ファブリック１０００上における装置の１つがメッセージを生成してもよい（ブロック１６７２）。装置は、所望されるメッセージの信頼度に関する１つ以上の信頼度因子を考慮してもよい（ブロック１６７４）。このような１つ以上の信頼度因子の考慮は、装置上で動作するＯＳＩスタック９０のアプリケーション層１０２またはプラットフォーム層１００において生じてもよい。いずれの場合においても、装置が考慮してもよい信頼度因子は、（１）ブロック１６７２において生成されるメッセージのタイプ、（２）メッセージが送信されるネットワークのタイプ、（３）メッセージがファブリックを通って移動し得る距離、（４）目標ノードおよび／もしくは目標ノードにメッセージを通信するよう用いられる伝送ノードの電力感度、ならびに／または（５）目標ノード（たとえば装置であるかまたはサービスであるか）を含んでもよい。いくつかの実施の形態では、たった１つの因子が考慮されてもよい。さらに、ここで論じられる信頼度因子のリストは網羅的であるよう意図されるものではなく、メッセージを送信する際に信頼性または節電がより望ましくあり得るかどうかを判断するための例を与えるよう意図されるものである。

【0268】

トランスポートプロトコルの所望の信頼性に影響し得る第１の因子は、送信されることになるメッセージのタイプである。メッセージが、危険が検出された旨を示すメッセージのような警報メッセージであるときには、非常に高い信頼性が所望され得る。しかしながら、メッセージがセンサデータまたはある装置ステータスデータを表現するときには、高い信頼性は節電よりも価値が低いかもしれない。

【0269】

トランスポートプロトコルの所望の信頼性に影響を与え得る第２の因子は、メッセージが送信されることになるネットワークのタイプである。メッセージがたとえば主に８０２．１５．４ネットワークを横断することになる場合には、それは、節電が信頼性よりも恩恵があり得ることを暗示し得る。しかしながらメッセージが主に、または全体的にＷｉＦｉネットワークを横断することになる場合には、それは、節電はそれほど価値はなく、信頼性がより価値があり得ることを暗示し得る。

【0270】

トランスポートプロトコルの所望の信頼性に影響し得る第３の因子は、メッセージが目標ノードに到達するのにファブリック１０００を介して移動し得る距離である。この距離は、たとえば、目標ノードに到達する「ホップ」の数、目標ノードに到達するのに横断され得る異なるタイプのネットワークの数、および／またはネットワークを通る実際の距離を表現し得る。

【0271】

トランスポートプロトコルの所望の信頼性に影響し得る第４の因子は、メッセージを目標ノードに通信するのに用いられてもよい装置の電力感度である。そのような装置のすべてもしくは実質的にすべてが常にオンであるかまたは外部の電源から供給を受けるときには、より高い信頼性が節電よりも好ましくあり得る。これらの装置の１つまたは多くが、
小電力、スリーピー状態、および／またはバッテリにより電力を供給される装置である場合には、メッセージが特に緊急でない場合には、節電がより好まれ得る。

【0272】

トランスポートプロトコルの所望の信頼性に影響し得る第５の因子は、メッセージの目標エンドノードのタイプである。一例では、目標エンドノードがサービスであるときには、ローカルであれ遠隔であれ、より高い信頼性が所望され得る。したがって、この場合では、ＴＣＰがＵＤＰよりも好まれ得る。別の例では、より高い信頼性が好まれ得るのは、目標エンドノードが遠隔サービスであるときであるが、目標エンドノードがローカルサービスであるときには、より低い信頼性およびより大きな節電が求められてもよい。他の例では、サービスのタイプが考慮されてもよい。つまり、いくつかのサービスについては、信頼性のほうが節電よりも好まれ得、一方、他のサービスについては、節電が信頼性よりも好まれ得る。ほんの一例を挙げると、気象情報を与えるよう用いられるサービスと通信するためには、節電と比較して、比較的より低い信頼性が所望され得る。他方、ソフトウェア更新を提供するよう用いられるサービスと通信するためには、より高い信頼性が節電よりも好まれ得る。

【0273】

装置はこれらの因子の１つ以上を任意の好適な態様で考慮してもよい。一例では、これらの因子は重みを割当てられてもよく、信頼性判断はそれらの因子の総重みづけに基づいてもよい。他の例では、ある因子は他の因子よりも高い優先度を有してもよい。そのような例では、緊急メッセージは節電よりも大きな所望の信頼性を有するよう常に考慮されてもよく、一方、非緊急メッセージに対する信頼性の所望度は他の因子に依存してもよい。したがって、節電が信頼性よりも所望されるときには（判断ブロック１６７６）、装置はメッセージをＵＤＰを介して送信して（ブロック１６７８）、より低い信頼性にも関わらず電力を節約してもよい。より大きな信頼性が節電よりも所望される場合には（判断ブロック１６７６）、装置は、より大きな電力消費にも関わらず増大された信頼性を有するよう、ＴＣＰを介してメッセージを送信してもよい（ブロック１６８０）。

【0274】

上記の方法はＴＣＰまたはＵＤＰを用いてメッセージを送信することの選択に関して論じられたが、本通信システムは、通信態様の任意の数のプロパティを効率的に調整して、所望の信頼性を電力消費と均衡させてもよい。たとえば、いくつかの実施の形態では、より高い信頼性が所望されるときには、より高出力のネットワーク（たとえばＷｉＦｉ）が好まれてもよく、一方、より低い信頼性およびより大きな節電が所望される場合には、より小電力のネットワーク（たとえば８０２．１５．４）が好まれてもよい。送信側ノードは、たとえば、ＩＰｖ６パケットヘッダ１６００のサブネットフィールド１６０４に注記すべき異なる好まれるネットワークを選択し、それによって、可能であるときには、メッセージをその選択されたネットワークを通して通信させてもよい。

【0275】

―さらなる使用例―
上で論じられた接続された装置のファブリック１０００はさまざまな態様で用いられてもよい。一例は、１つの装置を用いて他の装置上で方法を呼出すことを伴ってもよい。別の例は、ハザード警報のようなメッセージをファブリックのさまざまな装置を渡って伝搬させることを伴ってもよい。これらの使用例は例示を与えるよう意図されるものであって、網羅的であるよう意図されるものではないことが理解されるべきである。

【0276】

１つの装置から他の装置上に方法を呼出す
１つの場合では、ファブリック１０００の１つの領域における装置が、別の、互換性のある装置上において特定の方法を呼出してもよい。一例が図６０のダイヤグラム１７００に表われる。ダイヤグラム１７００は、第１の装置１７０２と第２の装置１７０４との間における対話を、ディレクトリ装置（ＤＤＳ）１７０６によって仲介されるように示す。ディレクトリ装置（ＤＤＳ）１７０６は、第１の装置１７０２および第２の装置１７０４
を含むファブリック上のさまざまな装置に対してＤＤＳサービス同報通信１７０８を発してもよい。応答して、ディレクトリ装置（ＤＤＳ）１７０６は、ファブリック１０００のさまざまな装置がサポートするすべての方法および／またはプロファイルのリストを受信してもよい。

【0277】

第１の装置１７０２のような、ファブリックの装置のうちの１つが方法（図６０において方法ｎとして示される）を実行することを所望する場合には、第１の装置１７０２はディレクトリ装置（ＤＤＳ）１７０６に対して対応のクエリメッセージ１７１０で問合せしてもよい（たとえばGetProperty(supports-n)（プロパティ獲得（サポート－ｎ））。デ
ィレクトリ装置（ＤＤＳ）１７０６は、そのようなプロパティをサポートする装置で返答してもよく－ここでは、第２の装置１７０４が所望の方法をサポートする旨を示すメッセージ１７１２で返答する。ここで、この情報を所有して、第１の装置１７０２は、第２の装置１７０４へのメッセージ１７１４において方法を呼出してもよい。第２の装置１７０４は、次いで、適切な応答で返答１７１６を発してもよい。

【0278】

第１の装置１７０２によって第２の装置１７０４上で呼出される方法は、住宅ネットワークにとって有用であり得る多数の方法のうちの任意のものであってもよい。一例では、第１の装置１７０２は第２の装置１７０４からの環境的センサデータを要求してもよい。環境的センサデータは、動き、温度、湿度などを示してもよい。環境的センサデータは、第１の装置１７０２によって用いられて、たとえば、セキュリティに関して在宅を判断するか、または家の周りで現在見いだされるさまざまな温度を判断してもよい。別の例では、第１の装置１７０２は、第２の装置１７０４からのユーザインターフェイス入力情報を要求してもよい。たとえば、第１の装置１７０２は、在宅者の最近の所望の快適さ設定に関する情報を確認すべく、最近のサーモスタット温度設定点を示すものを要求してもよい。

【0279】

―ファブリックのさまざまな装置にメッセージを伝送する―
いくつかの状況では、メッセージをファブリックの複数の装置に伝搬することが望ましいかもしれない。たとえば、図６１のダイヤグラム１７２０に示されるように、いくつかの装置１７２２、１７２４、１７２６および１７２８を用いてハザード警報メッセージを伝搬してもよい。実際、ハザード警報メッセージは、さまざまな装置１７２２、１７２４、１７２６および１７２８の１つ以上が小電力の「スリーピー状態」の装置であっても、伝搬されてもよい。図６１の例では、装置１７２２はガレージにおけるハザード検出器（たとえば煙検出器）であり、装置１７２４はダイニングルームにおけるハザード検出器（たとえば煙検出器）であり、装置１７２６は玄関におけるスマートドアベルであり、装置１７２８は廊下におけるサーモスタットである。

【0280】

ダイヤグラム１７２０の動作はイベント１７３０（たとえば炎）がガレージ装置１７２２によって検出されると開始する。ガレージ装置１７２２はネットワーク起動メッセージ１７３２をダイニングルーム装置１７２４に伝搬し、それは、したがって返答１７３４を発してもよい。ダイニングルーム装置１７２４は、そのスリーピー状態から、起動状態の、常時オン状態に、一時的に起動してもよい。ダイニングルーム装置１７２４は、さらに、ネットワーク起動メッセージ１７３６を玄関装置１７２６に伝搬してもよく、それは、同様に、返答１７３８を行なう一方で、別のネットワーク起動メッセージ１７４０を玄関装置１７２８に伝搬してもよい。

【0281】

ファブリックの装置を起動させて、ガレージ装置１７２２は、イベント１７３０に関連づけられる警報１７４４を出力してもよく、警報通知メッセージ１７４６をダイニングルーム装置１７２４に発してもよい。警報通知メッセージ１７４６は、特に、イベントのタイプおよび発信装置（たとえばガレージで生じたイベント）を示してもよい。ダイニング
ルーム装置１７２４は、対応する警報１７４８を出力し、警報通知メッセージを玄関装置１７２６に転送してもよく、それはそれ自体で警報１７５２を出力し始めてもよい。玄関装置１７２６は警報通知メッセージを廊下装置１７２８に転送してもよい。

【0282】

廊下装置１７２８はインターフェイスメッセージ１７５６を表示して、ユーザが警報に応答できるようにしてもよい。一方で、メッセージはファブリックを渡って伝送され続けてもよい。これらは、さらなるネットワーク起動および返答メッセージ１７５８、１７６０、１７６２、１７６４および１７６６と、さらなる警報通知メッセージ１７６８、１７７０および１７７２とを含む。ユーザがユーザフィードバック１７７４を廊下装置１７２８において与えて、（たとえば警報が誤りであるかまたは危険でない状態によるものであるという理解のもとで）警報を消音するよう要求する場合には、廊下装置１７２８は、警報消音メッセージ１７７６を送信することによって応答してもよく、それはファブリック１０００を渡って装置のすべてに伝送されてもよい。警報消音メッセージ１７７６は玄関装置１７２６に達してもよく、それはその警報１７７８を消音して、さらなる警報消音メッセージ１７８０をダイニングルーム装置１７２４に発してもよい。応答して、ダイニングルーム装置１７２４はその警報１７８２を消音し、さらなる警報消音メッセージをガレージ装置１７２２に発してもよく、それは次いで、その警報１７８６を消音してもよい。

【0283】

装置１７２６、１７２４および１７２２にそれらの警報を消音させたのち、廊下装置１７２８は、装置１７２６、１７２４および１７２２を、再び、スリーピー状態の小電力状態に入らせてもよい。具体的には、廊下装置１７２８はネットワークスリープメッセージ１７９０を玄関装置１７２６に発し、それは、ネットワークスリープメッセージ１７９２をダイニングルーム装置１７２４に発した後にスリーピー状態に入ってもよい。ダイニングルーム装置１７２４は、対応して、ネットワークスリープメッセージ１７９４をガレージ装置１７２２に発した後にスリーピー状態に入ってもよい。ネットワークスリープメッセージ１７９４を受信すると、ガレージ装置１７２２は小電力のスリーピー状態に入ってもよい。

【0284】

―ファブリックに加わる（加入する）かまたはファブリックを形成する―
上で論じられたプロトコルを用いて、住宅ネットワークまたは同様の環境において装置のファブリック１０００に加わるかまたはそれを形成することができる。たとえば、図６２～図６４は、新たな装置が（たとえばインターネットを介して）サービスに接続される既存のファブリック１０００の別の装置を介してファブリック１０００に加わる第１の方法に関する。図６５～図６７は、いずれの装置が別のサービスに接続されるか否かに関わらず、新たな装置が、別の装置とのピア・ツー・ピア接続を介して既存のファブリック１０００に加わるかまたは新たなファブリック１０００を形成する第２の方法に関する。以下の例は、ネイティブディスプレイとのユーザインターフェイスを有さないかもしれず、したがって、第三者クライアント装置（たとえば携帯電話またはタブレットコンピュータ）からの支援を必要とし得る新たな装置でファブリック１０００に加わることに関する。新たな装置がネイティブディスプレイとのユーザインターフェイスを含むもののような、他の実施の形態では、以下において、第三者クライアント装置において実行されるとして記載されるアクティビティが、代わりに、その新たな装置上において生じてもよい。

【0285】

サービスに対するインターネット接続を用いてファブリックに加わるかまたはファブリックを形成する
まず図６２～図６４に示されるフローチャート１８００を参照して、ユーザは、装置が販売された箱を開封し（ブロック１８０２）、アプリケーションを第三者クライアント装置（たとえば携帯電話またはタブレットコンピュータ）にインストールする命令を得る（ブロック１８０４）ことによって、新たな装置をファブリック１０００に加わらせてもよい。アプリケーションはクライアント装置にインストールされてもよく（ブロック１８０
６）、ユーザは、ファブリック１０００に関係づけられるサービスアカウントにログインしてもよく、そこで、ユーザは、新たな装置が加わることになる特定のファブリック１０００を選択してもよい（ブロック１８０８）。たとえば、ユーザは、Nest（登録商標）アプリケーションをインストールしてもよく、Nest（登録商標）Weave^TMファブリックと関
連づけられるNest（登録商標）サービスアカウントにログインしてもよい。クライアント装置上のアプリケーションは、ファブリック１０００のサービス構成と関連づけられる情報を得てもよい（ブロック１８１０）。ファブリック１０００のサービス構成と関連づけられる情報は、たとえば以下を含んでもよい：
・サービスノード識別情報（たとえばＥＵＩ－６４またはＥＵＬＡ）；
・サービスに対するトラストアンカとして供されてもよい証明書の組（たとえばファブリック認証トークン）；
・ユーザのアカウントに関連づけられるグローバルに一意のアカウント識別情報；
・サービスに対するエントリポイントを識別するドメイン名システム（ＤＮＳ）ホスト名；および／または
・ユーザのアカウントと対になるよう新たな装置によって用いられてもよい不透明なアカウントペア形成トークン。

【0286】

ユーザは、さらに、クライアント装置上のアプリケーションを介して、新たな装置をファブリック１０００に追加することを選択してもよい（ブロック１８１２）。ユーザと関連づけられる既存のファブリック１０００が現在存在するかどうか、または任意の他の好適な基準に基づいて（判断ブロック１８１４）、アプリケーションは、新たなファブリック１０００を形成する（ブロック１８１６）か、または新たな装置を既存のファブリック１０００に追加する（ブロック１８１８）ことを選んでもよい。

【0287】

アプリケーションが、新たな装置を既存のファブリック１０００に追加することを選択する場合には（ブロック１８１８）、アプリケーションは、ネットワークの装置が起動状態にあって、スリーピー状態にはないかどうかを判断し（判断ブロック１８２０）、起動状態にない場合には装置を起動させてもよい（ブロック１８２２）。ユーザは、たとえば、ボタンを押すことによって、加入プロセスにおいて用いるようネットワークの特定の既存の装置を選択してもよい（ブロック１８２４）。既存の装置は、ファブリック加入情報を、クライアント装置上のアプリケーションに提供してもよい（ブロック１８２６）。たとえば、クライアント装置上のアプリケーションは、ファブリック１０００認証トークンを用いて、既存の装置と安全なセッションを確立してもよい。アプリケーションは要求（たとえばGetNetworkConfiguration（ネットワーク構成獲得）および／またはGetFabricConfiguration（ファブリック構成獲得））を用いて、既存の装置からネットワーク構成情
報および／またはファブリック１０００構成情報を得てもよい。アプリケーションはこの情報を後で用いるために保存してもよい。アプリケーションはこの情報を後で用いるために保存してもよい。

【0288】

アプリケーションは、さらに、ユーザに対して新たな装置を起動するよう命令してもよく（ブロック１８２８）、それは、たとえば、新たな装置上のボタンを押すことによってでもよい（ブロック１８３０）。方法は、さらに、ブロック（Ａ）１８３２に進み、それは図６３に続く。ここで、クライアント装置上のアプリケーションは既存の装置に対して新たな装置に接続するよう命令してもよい（ブロック１８３４）。たとえば、アプリケーションは、ファブリック認証トークンを用いて既存の装置への新たな安全なセッションを確立してもよく、この新たなセッションを介して要求（たとえばConnectOtherDevice（他の装置を接続））を既存の装置に送信してもよい。一方で、新たな装置は、既存の装置と加入する目的で特定の８０２．１５．４「加入ネットワーク」を設定していてもよい。したがって、ブロック１８３４の要求は、アプリケーションが既存の装置に対して新たな装置に８０２．１５．４ネットワーク接続（たとえば新たな装置によって形成される８０２
．１５．４加入ネットワーク）を介して接続することを望む旨を指定してもよい。既存の装置は、次いで、近くの８０２．１５．４ネットワークのスキャンを実行して、新たな装置によって形成されるネットワークを探してもよい。見つかると、既存の装置は既存のファブリックを出て、新たな８０２．１５．４加入ネットワークに加わり、ランデブーアドレス（既存の装置のソフトウェアもしくはファームウェアまたはクライアント装置のアプリケーションによって予め指定されていてもよい）に接続するよう試みることによって、８０２．１５．４加入ネットワークを探査してもよい。一旦新たな装置への接続が確立されると、既存の装置は、クライアント装置上のアプリケーションからの新たな装置への接続に対する要求（たとえばConnectOtherDevice）に対して、成功の返答で応答してもよい。この時点から先は、アプリケーションから新たな装置に与えられるメッセージは、プロキシによって、既存の装置を通して、８０２．１５．４加入ネットワークを介して、実行されてもよい。つまり、新たな装置は既存の装置に８０２．１５．４加入ネットワークを介して接続されてもよく、既存の装置はサービスノードにＷｉＦｉ（および／またはインターネット接続）を介して接続されてもよく、クライアント装置上のアプリケーションはサービスに接続されてもよい。このようにして、アプリケーションは新たな装置に既存のファブリックを通して接続してもよく、既存の装置は１つのＷｉＦｉ接続および１つの８０２．１５．４接続を用いるだけでもよい（それによって、既存の装置において、ネットワークタイプごとに複数の受信機および送信機を用いることを回避することを低減し、それは装置コストおよび電力消費を低減し得る）。

【0289】

代替的に、新たなファブリック１０００が形成されるときには、クライアント装置上のアプリケーションは、ＷｉＦｉ接続を用いて新たな装置に直接接続してもよい。したがって、クライアント装置上のアプリケーションはユーザに対してＷｉＦｉ接続に切換えるよう命令してもよい（ブロック１８３６）。ユーザは、ＷｉＦｉネットワークをそれらのクライアント装置上で切換えて、新たな装置とのピア・ツー・ピアＷｉＦｉ接続を確立してもよい（ブロック１８３８）。たとえば、新たな装置は、それを、その背部上の一意のＷｉＦｉＳＳＩＤ名と関連づけられてもよい。クライアント装置上のアプリケーションは、（たとえばサービスからの構成情報によってアプリケーションに与えられるか、またはアプリケーションにエンコードされる）予め定められたランデブーアドレスに接続することを繰返し試みることによって、新たな装置を探査してもよい。

【0290】

これらの接続のいずれかが確立された状態で、クライアント装置上のアプリケーションは、新たな装置を検出し、新たな装置によって与えられる連続番号を表示してもよい（ブロック１８４０）。このとき、アプリケーションは、さらに、新たな装置が、その上に、新たな装置を認証を介して妥当性を確認され、ファブリックに加わる適切な許可を有するとして識別する、あるセキュリティ特徴をインストールされたことの妥当性を確認してもよい。これらのセキュリティ特徴は、上に論じられたＤＴＬＳセキュリティ証明書と同じであってもよく、またはそれに加えてでもよい。

【0291】

いずれかの接続を用いて、ユーザは、クライアント装置上のアプリケーションが、ユーザに対して、新たな装置と関連づけられる（たとえば新たな装置上または新たな装置とともに提供されるカード上に印刷される）ＱＲコード（登録商標）または他のコードを走査するよう命令するときに、認証手順を容易にしてもよい（ブロック１８４２）。ユーザは、コードを走査またはタイプすることによって、コードをアプリケーションに入力してもよい（ブロック１８４４）。このコード情報は新たな装置に与えられてもよく、新たな装置はそのコードを用いて、アプリケーションが、その新たな装置を所有するユーザによって認証を介して用いられていることを確認してもよい。新たな装置は、たとえば、組込みチェックデジットを用いてコードの妥当性を確認してもよい。新たな装置は、コードが不正確に入力されたときを、対応の返答で示してもよい。アプリケーションは、Weave PASEプロトコルを含む任意の好適なプロトコルを用いての新たな装置との安全なセッションの
確立を、供給されるペア形成コードをパスワードとして用いながら行なってもよい（ブロック１８４８）。新たな装置に対する安全な接続を確立すると、クライアント装置上のアプリケーションは新たな装置上においてフェールセーフ体制を装備するよう要求を発行してもよい（たとえばArmConfigurationFailsafe（構成フェールセーフ装備））（ブロック１８５０）。フェールセーフ体制を装備することによって、加入プロセスが何らかのタイムアウト値までに完了しない場合には、新たな装置はある元の構成に戻ってもよい。アプリケーションは、さらに、新たな装置が別の既存のファブリック１０００に属するかどうかを好適な要求（たとえばGetFabricState（ファブリック状態獲得））を発行することによって判断してもよい（判断ブロック１８５２）。そうである場合には、アプリケーションは、別の要求（たとえばLeaveFabric（ファブリック退去））を発行することによって
、新たな装置に対して他の既存のファブリック１０００から退去するよう命令してもよい（ブロック１８５４）。

【0292】

新たな装置が既存の装置とともに新たなファブリック１０００を形成することになる場合では（判断ブロック１８５６）、アプリケーションは、新たな装置に対して、（たとえばEnumerateVisibleNetworks（可視のネットワークを列挙する）要求を介して）新たな装置に可視のＷｉＦｉネットワークのリストを列挙するよう命令してもよい（ブロック１８５８）。アプリケーションからの命令で（ブロック１８６０）、ユーザは、次いで、これらのネットワーク間から選択を行なってもよく、または新たな装置が加わることになるＷｉＦｉネットワークを入力してもよい（ブロック１８６２）。ユーザは、さらに、ＷｉＦｉネットワークに加わるよう適切なパスワードを入力してもよい（ブロック１８６４）。方法は、さらに、ブロック（Ｂ）１８６６に続き、それは図６４に続く。アプリケーションはＷｉＦｉネットワーク構成情報を新たな装置に（たとえばAddNetwork（ネットワーク追加）要求を介して）送信してもよく（ブロック１８６８）、アプリケーションは、インターネット上のサービスに到達しようと試みることによって（たとえばTestNetwork（ネ
ットワークテスト）要求を介して）接続をテストするよう新たな装置に命令してもよい（ブロック１８７０）。アプリケーションは、ネットワーク接続が確認中であることをユーザに示してもよく（ブロック１８７２）、新たな装置は、その後、アプリケーションに対するその接続を確認してもよい（ブロック１８７４）。

【0293】

新たな装置が今やインターネットにＷｉＦｉ接続を介して接続された状態で、新たなファブリック１０００が形成されつつある場合には（ブロック１８７６）、アプリケーションはユーザに対してファブリック１０００（たとえばユーザの住宅）ＷｉＦｉ接続に戻るよう命令してもよい（ブロック１８７８）。ユーザは、クライアント装置によって用いられているＷｉＦｉネットワークを、ファブリック１０００によって用いられるＷｉＦｉ接続に変更してもよい（ブロック１８８０）。

【0294】

新たなファブリック１０００を形成しようと、または既存のファブリックに加わろうと、アプリケーションは新たな装置に対しこの時点でそうするように命令してもよい（ブロック１８８２）。つまり、アプリケーションは新たな装置に対して新たなファブリック１０００を（たとえばCreateFabrick（ファブリック形成）要求を介して）形成するよう命
令してもよく、または新たな装置に対して既存のファブリック１０００に（たとえばJoinExistingFabric（既存のファブリックに加わる）要求を介して）加わるよう命令してもよい。既存のファブリックに加わる場合には、アプリケーションは新たな装置に既存の装置を（たとえば新たな装置へのRegisterNewFabricMember（新たなファブリックメンバーを
登録する）要求を介して）知らせてもよい。いずれの場合においても、アプリケーションは、サービス構成情報（たとえばWeave^TM Service Configuration（Weave^TMサービス構成）情報）を含む要求（たとえばRegisterService（サービス登録）要求）を送信すること
によってサービス（たとえばNest（登録商標）サービス）と通信するよう、新たな装置を構成してもよい。

【0295】

サービス構成情報を用いて、新たな装置はサービスに登録してもよい（ブロック１８８４）。たとえば、新たな装置は、サービス構成情報からのサービスノードＩＤおよびＤＮＳ名を用いてサービスに接続してもよい。新たな装置は、新たな装置にインストールされた証明書およびプライベートキーを用いてサービスに登録してもよい。新たな装置は、ファブリック１０００に関連づけられるサービスアカウント識別情報およびサービス構成情報から得られるアカウントペア形成トークンを含むメッセージ（たとえばPairDeviceToAccount（装置をアカウントと対にする）メッセージ）をサービスに送信してもよい。この
情報を用いて、サービスはアカウントペア形成トークンの妥当性を確認してもよく、新たな装置をファブリックと関連づけられるユーザのサービスアカウントと関連づけてもよい。この時点で、新たな装置は、サービスによって、ファブリック１０００の一部を形成するよう理解されてもよく、ユーザがサービスにログインするときには関連づけられる装置として現れてもよい。サービスは、新たな装置からのメッセージ（たとえばPairDeviceToAccountメッセージ）に応答してもよく、それのアカウントペア形成トークンのそれのコ
ピーを破壊してもよく、以前にアプリケーションに送信されたメッセージ（たとえばRegisterService要求）に応答してもよい。

【0296】

応答して、新たな装置が既存のファブリック１０００に加わることまたは新たなファブリックを最終決定するために、アプリケーションは、新たな装置に対応のメッセージ（たとえばDisarmConfigurationFailsafe（構成フェールセーフ装備解除）要求）を送信する
ことによって、フェールセーフ加入機構を取消してもよい（ブロック１８８６）。新たな装置は、その後、この要求を受信して、構成フェールセーフを装備解除してもよい（ブロック１８８８）。新たな装置と既存の装置とのペア形成は、新たなファブリック１０００においてであれ既存のファブリック１０００においてであれ、ここで完了状態と考えられてもよい。クライアント装置上のアプリケーションは、したがって、ユーザがその中から選択してもよいさらなるセットアップ設定に対するユーザ命令を提供してもよい（ブロック１８９０）（ブロック１８９２）。これらは、たとえば、さらなる装置を対にし続けることまたはセットアップを出ることを含んでもよい。

【0297】

インターネットでのＷｉＦｉ接続なしにファブリックに加わるかまたはそれを形成する
新たな装置は、サービスまたはインターネットへのＷｉＦｉ接続に対するアクセスを必ずしも有することなくファブリック１０００に加わるかまたはそれを形成してもよい。たとえば、図６５～図６７に示されるように、そのような接続は（たとえば単に８０２．１５．４ネットワーク接続を渡って）サービスによる促進なしに他のネットワーク接続を用いて形成されてもよい。このセクションは、新たな装置を装置対装置ファブリックにおいて加えるプロセス中に生じてもよい動作およびイベントを記載する。ここで用いられるとおりでは、「装置対装置ファブリック」は１つのネットワークインターフェイスを介して（たとえば８０２．１５．４インターフェイスのみを介して）接続される２つ以上のファブリック１０００装置のネットワークである。装置対装置ファブリック１０００における装置は必ずしもＷｉＦｉネットワークに接続されず、したがって、（図６２～図６４にあるように）クライアント装置上で動作しているアプリケーション（たとえばウェブまたはモバイル）またはインターネット上のサービス（たとえばNest（登録商標）サービス）に対して話しかけなくてもよい。

【0298】

いくつかの場合では、装置対装置ファブリックは、ユーザが短い時間期間の間に２つの装置上のボタンを押し得るという点においてのみユーザの関与を伴い、ＷｉＦｉファブリックよりも形成が容易であり得る。図６５～図６７に記載される装置対装置加入プロセスは、２つの独立した装置を用いる新たな装置対装置ファブリック１０００の形成、および新たな独立した装置が既存の装置対装置ファブリックに加わることの両方をサポートしてもよい。装置対装置加入は、さらに、装置を既存の装置対装置ファブリック１０００から
除去し、それを別の装置対装置ファブリックに加えるよう用いることもできる。後者のシナリオは、ユーザが適切に供されなかった使用済の装置をその古い装置対装置ファブリックから獲得するときに特に有用となり得る。

【0299】

装置対装置加入プロセスは、いくつかの実施の形態では、新たな装置を既存のＷｉＦｉファブリック１０００に加えるよう用いられなくてもよいことが注記される。これに対して、ユーザは、上述の図６２～図６４を参照して論じられたＷｉＦｉ加入プロセスに従ってもよい。さらに、装置対装置加入プロセスは、既にＷｉＦｉファブリック１０００のメンバーである装置を装置対装置ファブリックに加えるよう用いられなくてもよい。したがって、ユーザが適切に供されなかった使用済の装置をその元のＷｉＦｉファブリックから獲得する場合においては、ユーザは、装置上で工場リセットを実行した後に装置対装置ファブリック１０００加入プロセスに進んでもよい。

【0300】

装置対装置加入プロセスは、図６５のフローチャート１９００に示されるように、加えられるべき２つの装置のうちの第１の装置（たとえば装置１）が起動されるときに開始してもよい（ブロック１９０２）。たとえば、第１の装置の販売箱における命令に基づいて、ユーザは第１の装置上のボタンを押してもよい。ここで、ユーザが装置を既存のファブリックに追加する場合には、ユーザは追加されるべき装置上のボタンを押すよう命令されてもよい。ユーザが２つの独立した装置から新たなファブリック１０００を形成している場合には、ユーザはどちらかの装置を第１の装置として選択してもよい。さらに、第１の装置がＷｉＦｉファブリックのメンバーである場合には、第１の装置はいかなるさらなるアクションも取らなくてもよく、加入手順は停止する。第１の装置がＷｉＦｉファブリックのメンバーである場合には、第１の装置は、ＷｉＦｉファブリック１０００との関連づけを解除された後に、（たとえば工場リセットを介して）装置対装置ネットワークに加わってもよい。

【0301】

既存のＷｉＦｉファブリックのメンバーでないときには、第１の装置（たとえば装置１）は、ブロック１９０２にあるように起動されたときに、ある初期化手順を開始してもよい。たとえば、装置１は時間とともに増分するカウンタを起動してもよい（たとえば１秒に複数回）。適切である場合には、このカウンタは、後で、２つの装置のうちのどの装置がファブリックを確立することにおいて優先権を有するかを判断するために用いられる。装置１は、さらに、８０２．１５．４ワイヤレスネットワークを形成してもよく、それは８０２．１５．４加入ネットワークと呼ばれてもよい（ブロック１９０４）。この８０２．１５．４加入ネットワークは、一般的に一意の、保護されないネットワークであってもよい。たとえば、８０２．１５．４加入ネットワークは、以下の情報：（ａ）ネットワークを加入ネットワークとして識別する文字列、（ｂ）第１の装置のノードｉｄ、および（ｃ）装置がファブリックの一部であるかどうかを示すフラグを含む一般的に一意のELoWPAN１１０ネットワーク名を用いてもよい。加入ネットワークが確立されると、装置１は、
さらに、加入ネットワークにおいて、それ自体に２つのＩＰｖ６アドレスを割当ててもよい（ブロック１９０６）。これらは、たとえば、（ａ）ランデブープレフィックスと称されてもよい識別的プレフィックスおよび装置のＭＡＣアドレスから導出されるインターフェイス識別子を伴うＩＰｖ６ ＵＬＡまたはＥＵＬＡ、ならびに（ｂ）ランデブーアドレスと称されてもよい、ランデブープレフィックスおよび１のインターフェイス識別子を伴うＩＰｖ６ ＵＬＡまたはＥＵＬＡを含んでもよい。

【0302】

装置１は、次いで、別の装置によって形成される８０２．１５．４ネットワークに対して継続的に走査を行なってもよい（ブロック１９０８）。実際、ブロック１９０２～１９０８の動作と並行して、またはそれらの後に、第２の装置（装置２）は上記の動作をそれ自体で実行してもよい（ブロック１９１０）。装置１または装置２のどちらかが他方の加入ネットワークを検出してもよい（ブロック１９１２）。先に他方を検出する装置－装置
１または装置２－のある特性によって、装置は（たとえば図６６に示されるように）開始側装置プロセスまたは（図６７に示されるように）応答側装置プロセスを実行してもよい。つまり、装置の１つが他方の加入ネットワークを発見すると、装置はその加入ネットワーク名に含まれる情報をそれ自体の情報と比較し、以下の処理を行なってもよい：（ａ）装置が独立した装置であり他方の装置がファブリックのメンバーである場合には、装置は、図６６の開始側装置プロセスに示される処理を実行してもよく；または（ｂ）装置がファブリック１０００のメンバーであり他方の装置が独立した装置である場合には、装置は図６７の応答側装置プロセスに示される処理を実行してもよい。いずれの装置もファブリックのメンバーでない場合、または両方の装置がファブリックのメンバーである場合には、他方の装置の加入ネットワークを検出した装置が、（ａ）そのノードｉｄを他方の装置のノードｉｄと比較してもよく、（ｂ）その装置のノードｉｄが他方の装置のノードｉｄ未満である場合には、装置は図６６の開始側装置プロセスに示される処理を実行してもよい。いずれの装置もファブリックのメンバーでない場合、または両方の装置がファブリックのメンバーである場合には、他方の装置の加入ネットワークを検出した装置が、（ａ）自装置のノードｉｄを他方の装置のノードｉｄと比較し、（ｂ）自装置のノードｉｄが他方の装置のノードｉｄより大きい場合には、図６７の応答側装置プロセスによって示される処理を実行してもよい。

【0303】

図６６の開始側装置プロセスを実行する装置は、上記のように、装置１または装置２のいずれであってもよい。したがって、図６６の開始側装置プロセスを実行する装置は、ここでは「開始側装置」と称することにする。同様に、図６７の応答側装置プロセスを実行する装置は開始側装置として動作しない装置であり得、上記のように装置１または装置２のいずれであってもよい。したがって、図６７の応答側装置プロセスを実行する装置はここでは「応答側装置」と称することにする。

【0304】

フローチャート１９２０において見られるように、図６６の開始側装置プロセスは、開始側装置がその加入ネットワークを終了させ、応答側装置によって形成される加入ネットワークに接続するときに開始してもよい（ブロック１９２２）。開始側装置は、それ自体に対して、ランデブープレフィックスおよびそれのＭＡＣアドレスから導き出されるインターフェイス識別子を伴うＩＰｖ６ ＵＬＡまたはＥＵＬＡを割当ててもよい（ブロック１９２４）。開始側装置はSolicit Joining（加入請求）メッセージを応答側装置に対し
てそのランデブーアドレスで送信してもよい。開始側装置からのSolicit Joiningメッセ
ージは以下の情報：（ａ）装置および起動したときに起動されるカウンタの値にセットされる数値的識別値、および（ｂ）装置が既にファブリックのメンバーであるかどうかを示すフラグを含んでもよい。開始側装置は、次いで、応答側装置からの応答メッセージを待ってもよく、Join Existing Fabric（既存のファブリックに加わる）要求またはSolicit Joining要求を受信する（ブロック１９２８）。

【0305】

開始側装置がJoin Existing Fabric要求を受信する場合には、開始側装置は、適切である場合には、それの現在のファブリックを出てもよく、それ自体を独立した装置として再初期化してもよく、Join Existing Fabric要求における情報を用いて、それ自体を応答側装置と既存のファブリック１０００の一部にしてもよい（ブロック１９３０）。開始側装置はJoin Existing Fabric応答を応答側装置に送信して、それが現在は既存のファブリック１０００のメンバーである旨を示してもよい（ブロック１９３２）。

【0306】

開始側装置がSolicit Joining要求を受信する場合には、開始側装置は、それが独立し
た装置であるかまたは既存のファブリックのメンバーであるかによって、異なる態様で応答してもよいが、いずれの場合においても、ファブリック１０００情報をJoin Existing Fabric要求で送信してもよい（ブロック１９３４）。たとえば、開始側装置が独立した装置である場合には、開始側装置は、新たなファブリックｉｄおよび対応のファブリックセ
キュリティ情報を生成することによって新たなファブリック１０００を形成してもよく、それ自体を新たなファブリックの一部にしてもよく、Join Existing Fabric要求を応答側装置に送信してもよい。Join Existing Fabric要求は新たなファブリックに対する情報を含んでもよい。そうでない場合、装置がファブリックのメンバーである場合には、装置は、開始側装置がメンバーである既存のファブリック１０００の情報を含むJoin Existing Fabric要求を応答側装置に送信してもよい。開始側装置は、次いで、応答側装置が開始側装置のファブリック１０００に加わるときには、応答側装置からのJoin Existing Fabric応答を待ち、それを受信してもよい。

【0307】

図６７の応答側装置プロセスは、応答側装置が開始側装置との関係において振舞ってもよい態様を記載する。図６７の応答側装置プロセスはフローチャート１９５０によって記載される。フローチャート１９５０は、応答側装置が開始側装置からSolicit Joiningメ
ッセージを受信したときに開始する（ブロック１９５２）。

【0308】

応答側装置が独立した装置であって、既存のファブリック１０００にない場合には（判断ブロック１９５４）、応答側装置は、新たなファブリックｉｄおよび対応のファブリックセキュリティ情報を生成することによって新たなファブリック１０００を形成してもよい（ブロック１９５６）。応答側装置はそれ自体を新たなファブリック１０００の一部としてもよい（ブロック１９５８）。応答側装置は、次いで、応答側装置の新たなファブリックに対する情報を含むJoin Existing Fabric要求を開始側装置に送信してもよい（ブロック１９６０）。応答側装置は開始側装置からのJoin Existing Fabric応答を待ってもよい。

【0309】

そうでない場合には、Solicit Joiningメッセージの受信で（ブロック１９５２）、応
答側装置が既存のファブリック１０００にある場合には（判断ブロック１９５４）、応答側装置は異なる挙動を採用してもよい。具体的には、応答側装置がファブリックにある場合には、応答側装置はSolicit Joiningメッセージを調べてもよい（ブロック１９６２）
。応答側装置は、Solicit Joiningにおける識別値（開始側装置のカウンタ値）および「
ファブリックのメンバーである」フラグを調べてもよい。

【0310】

そうでない場合、Solicit Joiningメッセージが、開始側装置がファブリック１０００
のメンバーでない旨を示す場合、または識別値が、応答側装置が起動したときに応答側装置によって起動されるカウンタ以上である場合には（判断ブロック１９６４）、応答側装置は、応答側装置のファブリック１０００に対する情報を含むJoin Existing Fabric要求を開始側装置に送信してもよい（ブロック１９７４）。応答側装置は開始側装置からJoin
Existing Fabric応答を待ってもよい。

【0311】

Solicit Joiningメッセージが、開始側装置がファブリック１０００のメンバーである
旨を示す場合、または識別値が、応答側装置が起動したときに応答側装置によって起動されるカウンタ未満である場合には（判断ブロック１９６４）、応答側装置はそれの現在のファブリック１０００を出て、それ自体を独立した装置として再初期化してもよい（ブロック１９６６）。応答側装置は、さらに、Solicit Joiningメッセージを開始側装置に送
信してもよく（ブロック１９６８）、開始側装置からのJoin Existing Fabric要求を待ってもよい。開始側装置からのJoin Existing Fabric要求を受信すると（ブロック１９７０）、応答側装置は、Join Existing Fabric要求における情報を用いて、それ自体を新たなファブリック１０００の一部にしてもよい（ブロック１９７２）。応答側装置は、さらに、Join Existing Fabric応答を送信して、それが今では開始側装置の既存のファブリック１０００のメンバーである旨を示してもよい。

【0312】

上に記載される具体的な実施の形態は例示によって示されたものであり、これらの実施
の形態はさまざまな修正および代替形式が可能であり得ることが理解されるべきである。さらに、特許請求の範囲は開示される特定の形式に限定されるよう意図されるものではなく、本開示の精神および範囲内に入るすべての修正物、均等物および代替物を包含することが理解されるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図7C】

【図7D】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】

【図49】

【図50】

【図51】

【図52】

【図53】

【図54】

【図55】

【図56】

【図57】

【図58】

【図59】

【図60】

【図61】

【図62】

【図63】

【図64】

【図65】

【図66】

【図67】