JP6858300B2 - 電子装置、通信方法、およびプログラム - Google Patents

Description

本開示は１つ以上のネットワークタイプを用いて電子装置を接続するファブリックネットワークに関する。

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

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

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

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

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

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

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

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

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

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

実施の形態に従って、ファブリックネットワークを用いて他の装置と相互接続されてもよい電子装置のブロック図である。 実施の形態に従って、図１の一般的な装置がファブリックネットワークを介して他の装置と通信してもよい住宅環境のブロック図を示す。 実施の形態に従って、図２の住宅環境に対して通信システムを特徴付ける開放型システム間相互接続（ＯＳＩ）モデルのブロック図を示す。 実施の形態に従って、単一の論理ネットワークトポロジを有するファブリックネットワークを示す。 実施の形態に従って、星形ネットワークトポロジを有するファブリックネットワークを示す。 実施の形態に従って、重なったネットワークトポロジを有するファブリックネットワークを示す。 実施の形態に従って、１つ以上のファブリックネットワークと通信するサービスを示す。 実施の形態に従って、ファブリックネットワークにおいて通信可能な接続状態にある２つの装置を示す。 実施の形態に従って、ファブリックネットワークにおいて装置をアドレス指定するよう用いられてもよい固有ローカルアドレスフォーマット（ＵＬＡ）を示す。 実施の形態に従って、ハブネットワーク上で周辺装置をプロキシ化するプロセスを示す。 実施の形態に従って、ファブリックネットワークによりデータを送信するために用いられてもよいタグ‐長さ‐値（ＴＬＶ）パケットを示す。 実施の形態に従って、ファブリックネットワークにより図１１のＴＬＶパケットを含んでもよいデータを送信するために用いられてもよい一般的なメッセージプロトコル（ＧＭＰ）を示す。 実施の形態に従って、図１２のＧＭＰのメッセージヘッダフィールドを示す。 実施の形態に従って、図１２のＧＭＰのキー識別子フィールドを示す。 実施の形態に従って、図１２のＧＭＰのアプリケーションペイロードフィールドを示す。 実施の形態に従って、ファブリックネットワークにおいてステータス情報を更新するために用いられてもよいステータス報告スキーマを示す。 実施の形態に従って、図１６のステータス報告スキーマのプロファイルフィールドを示す。 実施の形態に従って、クライアントとサーバとの間においてソフトウェア更新を実行するために用いられてもよいプロトコルシーケンスを示す。 実施の形態に従って、図１８のプロトコルシーケンスにおいて用いられてもよいイメージクエリフレームを示す。 実施の形態に従って、図１９のイメージクエリフレームのフレーム制御フィールドを示す。 実施の形態に従って、図１９のイメージクエリフレームの製品仕様フィールドを示す。 実施の形態に従って、図１９のイメージクエリフレームのバージョン仕様フィールドを示す。 実施の形態に従って、図１９のイメージクエリフレームのロケール仕様フィールドを示す。 実施の形態に従って、図１９のイメージクエリフレームの被サポート完全性タイプフィールドを示す。 実施の形態に従って、図１９のイメージクエリフレームの被サポート更新スキームフィールドを示す。 実施の形態に従って、図１８のプロトコルシーケンスにおいて用いられてもよいイメージクエリ応答フレームを示す。 実施の形態に従って、図２６のイメージクエリ応答フレームの統一的リソース識別子（ＵＲＩ）フィールドを示す。 実施の形態に従って、図２６のイメージクエリ応答フレームの完全性仕様フィールドを示す。 実施の形態に従って、図２６のイメージクエリ応答フレームの更新スキームフィールドを示す。 実施の形態に従って、ファブリックネットワークにおいて装置間でデータを管理するようデータ管理プロトコルを用いるよう用いられるシーケンスを示す。 実施の形態に従って、図３０のシーケンスにおいて用いられてもよいスナップショット要求フレームを示す。 実施の形態に従って、図３１のスナップショット要求フレームを用いてアクセスされてもよい例示プロファイルスキーマを示す。 実施の形態に従って、プロファイルスキーマにおいてパスを示してもよいパスのバイナリフォーマットである。 実施の形態に従って、図３０のシーケンスにおいて用いられてもよい要求監視フレームを示す。 実施の形態に従って、図３０のシーケンスにおいて用いられてもよい周期的な更新要求フレームを示す。 実施の形態に従って、図３０のシーケンスにおいて用いられてもよいリフレッシュ要求フレームを示す。 実施の形態に従って、図３０のシーケンスにおいて用いられてもよいビュー取消要求を示す。 実施の形態に従って、図３０のシーケンスにおいて用いられてもよいビュー応答フレームを示す。 実施の形態に従って、図３０のシーケンスにおいて用いられてもよい明示的な更新要求フレームを示す。 実施の形態に従って、図３０のシーケンスにおいて用いられてもよいビュー更新要求フレームを示す。 実施の形態に従って、図３０のシーケンスを用いて更新されてもよい更新項目フレームを示す。 実施の形態に従って、図３０のシーケンスにおいて更新応答メッセージとして送信されてもよい更新応答フレームを示す。 実施の形態に従って、大容量データ転送において、送信側と受信側との間において、通信可能な接続を示す。 実施の形態に従って、図４３の送信側によって通信可能な接続を開始するために用いられてもよいSendInit（送信開始）メッセージを示す。 実施の形態に従って、図４４のSendInitメッセージの転送制御フィールドを示す。 実施の形態に従って、図４５のSendInitメッセージの範囲制御フィールドを示す。 実施の形態に従って、図４４の送信側によって送信される図４４のSendInitメッセージによって提案される通信可能な接続を受入れるために用いられてもよいSendAccept（送信受容）メッセージを示す。 実施の形態に従って、図４４の送信側によって送信される図４４のSendInitメッセージによって提案される通信可能な接続を拒絶するために用いられてもよいSendReject（送信拒絶）メッセージを示す。 実施の形態に従って、図４４の受信側によって提案される通信可能な接続を受入れるために用いられてもよいReceiveAccept（受信受容）メッセージを示す。

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

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

本開示の実施の形態は一般的に、住宅環境において互いと通信する装置および／またはサービスによって用いられ得る効率的ファブリックネットワークに関する。一般的に、住宅で生活する消費者は、彼らの住宅にあるさまざまな装置のすべてが効率よく動作されるように、それらの装置の動作を調整することは有用であることを見出し得る。たとえば、サーモスタット装置を用いて、住宅の温度を検出し、その検出された温度に基づいて他の装置（たとえば照明）の動作を調整してもよい。この例においては、サーモスタット装置は住宅の外の温度が日中時間に対応することを示し得る温度を検出してもよい。サーモスタット装置は、次いで、住宅に利用可能な日光があり得ること、およびしたがって照明を切るべきであることを、照明装置に伝えてもよい。

消費者は、これらの装置を効率よく動作させることに加えて、概して、最小量のセットアップまたは初期化を伴うユーザに親切な装置を用いることを好む。つまり、消費者は、概して、年齢または技術的な熟練に関係なくほとんどどのような個人によっても実行され得る少ない数の初期化ステップを実行した後に十分に動作可能な装置を購入することを好み得る。

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

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

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

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

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

電源コンポーネント１６は、電力接続および／またはローカルバッテリを含んでもよい。たとえば、電力接続は、装置１０を、線間電圧源のような電源に接続してもよい。いくつかの例では、ＡＣ電源を用いて、（たとえば再充電可能な）ローカルバッテリを繰返し
充電し得、バッテリは、後で、ＡＣ電源が利用可能でないときに装置１０に電力を供給するよう用いられてもよい。ある実施の形態では、電源コンポーネント１６は、住宅内においてＡＣプラグを介して与えられるよりも少なくてもよい間欠的または低減された電力接続を含んでもよい。ある実施の形態では、バッテリおよび／または間欠的もしくは低減された電力を伴う装置は、電力消費を低減するようオンライン／起動状態とオフライン／スリープ状態との間で交互する「スリーピー状態装置」として動作してもよい。

ネットワークインターフェイス１８は、ファブリックネットワーク内における１つ以上の論理ネットワークを用いて、装置１０が装置間で通信することを可能にする１つ以上のコンポーネントを含んでもよい。一実施の形態では、ネットワークインターフェイス１８は、効率的ネットワーク層をその開放型システム間相互接続（ＯＳＩ）モデルの一部として用いて通信してもよい。ある実施の形態では、ネットワークインターフェイス１８の１つのコンポーネントは１つの論理ネットワーク（たとえばWiFi）と通信してもよく、ネットワークインターフェイスの他のコンポーネントは別の論理ネットワーク（たとえば802.15.4）と通信してもよい。換言すれば、ネットワークインターフェイス１８は、装置１０が複数のＩＰｖ６ネットワークを介して無線で通信することを可能にする。したがって、ネットワークインターフェイス１８は、ワイヤレスカード、イーサネット（登録商標）ポート、および／または他の好適な送信機接続を含んでもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ネットワーク層９６は、宛先ノードに転送されているデータがどのようにルーティングされるかを規定してもよい。ネットワーク層９６は、さらに、転送されているデータの完全性を維持し得るセキュリティプロトコルを提供してもよい。上に論じられた効率的ネットワーク層は、ネットワーク層９６に対応する。ある実施の形態では、ネットワーク層９６は、プラットフォーム層１００から完全に独立していてもよく、任意の好適なＩＰｖ６ネットワークタイプ（たとえばWiFi、イーサネット、ホームプラグ、８０２．１５．４など）を含んでもよい。

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

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

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

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

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

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

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

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

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

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

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

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

各ノードは、１つが各ネットワークインターフェイスに割当てられるリンクローカルアドレス（ＬＬＡ）の組を割当てられてもよい。これらのＬＬＡを用いて、同じネットワーク上の他の装置と通信してもよい。加えて、ＬＬＡは、ＩＰｖ６近隣探索プロトコルのようなさまざまな通信手順に対して用いられてもよい。ＬＬＡに加えて、各ノードは固有の
ローカルアドレス（ＵＬＡ）を割当てられてもよい。

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

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

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

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

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

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

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

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

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

以下に論じられる以下のデータフレーム、プロファイルおよび／またはフォーマットの各々は、メッセージの送信前および／または送信後にメモリ（たとえば装置１０のメモリ）に記憶されてもよいことが理解されるべきである。換言すれば、データフレーム、プロファイルおよびフォーマットは一般的にはデータの送信として論じられるが、それらは、さらに、データフレーム、プロファイル、および／またはフォーマットの送信前、送信中および／または送信後に（たとえばバッファに）物理的に記憶されてもよい。さらに、以下のデータフレーム、プロファイル、スキーマ、および／またはフォーマットは、電子装置がデータフレーム、プロファイル、スキーマおよび／またはフォーマットにアクセスすることを可能にする非一時的なコンピュータ読取可能媒体に記憶されてもよい。たとえば、データフレーム、プロファイル、スキーマおよび／またはフォーマットをフォーマットするための命令は、装置１０に対するメモリ、他の装置のメモリ、ポータブルメモリ装置（たとえばコンパクトディスク、フラッシュドライブなど）、またはデータフレーム、プロファイル、スキーマおよび／もしくはフォーマットを記憶するための他の好適な物理的装置などのような、任意の好適なコンピュータ読取可能媒体に記憶されてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (21)

1. 住宅環境において複数の装置を備えるファブリックネットワーク上で通信するよう構成された電子装置であって、前記ファブリックネットワークは複数の論理ネットワークを含み、前記電子装置は、
   前記ファブリックネットワーク内の前記複数の装置のうちの別の装置への送信のためのメッセージを生成するよう構成され、前記メッセージは、前記別の装置のアドレスを含み、前記電子装置はさらに、
   前記生成されたメッセージを前記ファブリックネットワーク内のプラットフォーム層を介してクラウドサービスに送信するよう構成され、前記送信は、前記クラウドサービスに前記アドレスを使用させて前記メッセージを前記別の装置に転送させるのに有効であり、前記電子装置は、第１の通信プロトコルを使用して前記ファブリックネットワークの第１のネットワーク内で通信するよう構成され、前記別の装置は、第２の通信プロトコルを使用して前記ファブリックネットワークの第２のネットワーク内で通信するよう構成される、住宅環境において複数の装置を備えるファブリックネットワーク上で通信するよう構成された電子装置。
2. 前記第１のネットワークはＷｉ−Ｆｉネットワークであり、前記第２のネットワークはＩＥＥＥ８０２．１５．４ネットワークである、請求項１に記載の電子装置。
3. 前記メッセージは、前記第１のネットワーク内のＷｉ−Ｆｉルータを介して送信される、請求項２に記載の電子装置。
4. 前記別の装置は、消費者装置、クラウドサーバ、ハザード検出器、セキュリティ装置、サーモスタット、またはカメラうちの１つである、請求項１〜請求項３のいずれか１項に記載の電子装置。
5. 前記生成されたメッセージはファブリック識別子（ＩＤ）を含み、前記ファブリックＩＤはグローバル識別子およびサブネット識別子を含む、請求項１〜請求項４のいずれか１項に記載の電子装置。
6. 前記メッセージは、１つ以上のインターネットプロトコルバージョン６（ＩＰｖ６）パケットとして送信される、請求項１〜請求項５のいずれか１項に記載の電子装置。
7. 前記メッセージは、伝送制御プロトコル（ＴＣＰ）またはユーザデータグラムプロトコル（ＵＤＰ）を使用して複数のネットワークにわたって送信される、請求項１〜請求項６のいずれか１項に記載の電子装置。
8. 前記電子装置と前記別の装置との間の通信は、一方向または双方向である、請求項１〜請求項７のいずれか１項に記載の電子装置。
9. 前記電子装置はさらに、前記別の装置から前記送信されたメッセージに対する応答を受信するよう構成される、請求項１〜請求項８のいずれか１項に記載の電子装置。
10. 住宅環境において複数の装置を備えるファブリックネットワーク上で電子装置によって通信する方法であって、前記ファブリックネットワークは複数の論理ネットワークを含み、前記方法は、
    前記電子装置が、前記ファブリックネットワーク内の前記複数の装置のうちの別の装置への送信のためのメッセージを生成することを備え、前記メッセージは、前記別の装置のアドレスを含み、前記方法はさらに、
    前記生成されたメッセージを前記ファブリックネットワーク内のプラットフォーム層を介してクラウドサービスに送信することを備え、前記送信することは、前記クラウドサービスに前記アドレスを使用させて前記メッセージを前記別の装置に転送させるのに有効であり、前記電子装置は、第１の通信プロトコルを使用して前記ファブリックネットワークの第１のネットワーク内で通信するよう構成され、前記別の装置は、第２の通信プロトコルを使用して前記ファブリックネットワークの第２のネットワーク内で通信するよう構成される、住宅環境において複数の装置を備えるファブリックネットワーク上で電子装置によって通信する方法。
11. 前記第１のネットワークはＷｉ−Ｆｉネットワークであり、前記第２のネットワークはＩＥＥＥ８０２．１５．４ネットワークであり、前記メッセージを送信することは、第１のネットワーク内のＷｉ−Ｆｉルータを介して行われる、請求項１０に記載の方法。
12. 前記生成されたメッセージはファブリック識別子（ＩＤ）を含み、前記ファブリックＩＤはグローバル識別子およびサブネット識別子を含む、請求項１０または請求項１１に記載の方法。
13. 前記メッセージは１つ以上のインターネットプロトコルバージョン６（ＩＰｖ６）パケットとして送信され、前記メッセージは伝送制御プロトコル（ＴＣＰ）またはユーザデータグラムプロトコル（ＵＤＰ）を使用して複数のネットワークにわたって送信される、請求項１０〜請求項１２のいずれか１項に記載の方法。
14. さらに、
    前記生成されたメッセージを送信することに応答して、前記別の装置から前記送信されたメッセージに対する応答を受信することを備える、請求項１０〜請求項１３のいずれか１項に記載の方法。
15. 前記別の装置は、消費者装置、クラウドサーバ、ハザード検出器、セキュリティ装置、サーモスタット、またはカメラうちの１つである、請求項１０〜請求項１４のいずれか１項に記載の方法。
16. 前記電子装置と前記別の装置との間の通信は、一方向または双方向である、請求項１０〜請求項１５のいずれか１項に記載の方法。
17. システムであって、
    住宅環境において複数の装置を備えるファブリックネットワーク上で通信するよう構成された電子装置を備え、前記ファブリックネットワークは複数の論理ネットワークを含み、前記電子装置は、
    前記ファブリックネットワーク内の前記複数の装置のうちの別の装置への送信のためのメッセージを生成するよう構成され、前記メッセージは、前記別の装置のアドレスを含み、前記電子装置はさらに、
    前記生成されたメッセージを前記ファブリックネットワーク内のプラットフォーム層を介してクラウドサービスに送信するよう構成され、前記送信は、前記クラウドサービスに前記アドレスを使用させて前記メッセージを前記別の装置に転送させるのに有効であり、前記電子装置は、第１の通信プロトコルを使用して前記ファブリックネットワークの第１のネットワーク内で通信するよう構成され、
    前記別の装置は、
    前記生成されたメッセージを受信し、
    前記メッセージの受信に応答して、前記電子装置に応答を送信するよう構成され、前記別の装置は、第２の通信プロトコルを使用して前記ファブリックネットワークの第２のネットワーク内で通信するよう構成される、システム。
18. 前記生成されたメッセージはファブリック識別子（ＩＤ）を含み、前記ファブリックＩＤはグローバル識別子およびサブネット識別子を含み、前記メッセージは１つ以上のインターネットプロトコルバージョン６（ＩＰｖ６）パケットとして送信され、前記メッセージは伝送制御プロトコル（ＴＣＰ）またはユーザデータグラムプロトコル（ＵＤＰ）を使用して複数のネットワークにわたって送信される、請求項１７に記載のシステム。
19. 前記別の装置は、消費者装置、クラウドサーバ、ハザード検出器、セキュリティ装置、サーモスタット、またはカメラうちの１つである、請求項１７または請求項１８に記載のシステム。
20. 前記第１のネットワークはＷｉ−Ｆｉネットワークであり、前記第２のネットワークはＩＥＥＥ８０２．１５．４ネットワークである、請求項１７〜請求項１９のいずれか１項に記載のシステム。
21. 装置の１以上のプロセッサによって実行されることにより、前記装置に請求項１０〜請求項１６のいずれか１項に記載の方法を実施させる、プログラム。

Images