JP2019516186A - モノのインターネット（ＩｏＴ）デバイスのグループのための連携サービス - Google Patents

Abstract

ＩｏＴ連携グループが、動的に作成されることができる。これらの連携グループは、選択されたトリガに基づいて、アクティブにされることができる。連携動作の一部として、サービス配信が、一次デバイスからＩｏＴ連携グループにリダイレクトされることができる。ＩｏＴ連携グループのメンバから発信されたメッセージは、一次デバイスから生じるかのように処理され、外部に転送されることができる。さらに、連携サービスは、選択されたトリガに基づいて、非アクティブにされることができる。

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／３２６，９４１号（２０１６年４月２５日出願、名称「Ｔｗｉｎｎｉｎｇ Ｓｅｒｖｉｃｅ Ｆｏｒ Ｇｒｏｕｐｓ ｏｆ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ （ＩＯＴ） Ｄｅｖｉｃｅｓ」）の利益を主張し、上記出願の開示は、その全体が記載されている場合のように参照により本明細書に引用される。

マシンツーマシン（Ｍ２Ｍ）／モノのインターネット（ＩｏＴ）サービス層（ＳＬ）は、Ｍ２Ｍ／ＩｏＴデバイスおよびアプリケーションのための付加価値サービスを提供することを標的とする技術である。ｏｎｅＭ２Ｍは、Ｍ２Ｍ／ＩｏＴ ＳＬを開発し、インターネット／ウェブ、セルラー、企業、およびホームネットワークを用いた展開の中へのＭ２Ｍ／ＩｏＴデバイスおよびアプリケーションの統合に関連付けられた課題に対処している、例示的グローバル規格組織である。

Ｍ２Ｍ／ＩｏＴ ＳＬは、アプリケーションおよびデバイスアクセスをＭ２Ｍ／ＩｏＴ向け能力の集合に提供することができる。例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含む。これらの能力は、Ｍ２Ｍ／ＩｏＴ ＳＬによってサポートされるメッセージフォーマット、リソース構造、およびリソース表現を利用する、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して、アプリケーションに利用可能である。

プロトコルスタックの観点から、サービス層は、典型的には、既存のネットワークプロトコルスタックの上に層化され、付加価値サービスをクライアントアプリケーションならびに他のサービスに提供する。故に、サービス層は、多くの場合、「ミドルウェア」サービス層として分類される。

図１は、インターネットプロトコル（ＩＰ）ネットワーキングスタック１０４とアプリケーション１０６との間に位置する、サービス層１０２を示す。代替として、サービス層１０２は、伝送制御プロトコル（ＴＣＰ）もしくはユーザデータグラムプロトコル（ＵＤＰ）等のトランスポートプロトコルを経由して、またはＳＯＡＰ（図１には図示せず）等の非ＲＥＳＴｆｕｌプロトコルを経由して、直接層化されることができる。

ネットワーク内のサービス層インスタンスの例示的展開シナリオが、図２に示されている。この例では、サービス層インスタンスは、種々のネットワークノード（ゲートウェイおよびサーバ）上で展開され、付加価値サービスを、ネットワークアプリケーション、デバイスアプリケーション、およびネットワークノード自体に提供している。

ｏｎｅＭ２Ｍ規格（ｏｎｅＭ２Ｍ−ＴＳ−０００１ ｏｎｅＭ２Ｍ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．０．０）は、図３に図示されるように、「共通サービスエンティティ（ＣＳＥ）」と呼ばれるサービス層を定義する。サービス層の目的は、ｅ−ヘルス、フリート管理、およびスマートホーム等の異なる「バーティカル」Ｍ２Ｍシステムおよびアプリケーションによって利用され得る、「ホリゾンタル」サービスを提供することである。

ＣＳＥ３０２は、４つの参照点をサポートする。Ｍｃａ参照点は、アプリケーションエンティティ（ＡＥ）３０４とインターフェースをとる。Ｍｃｃ参照点は、同一サービスプロバイダドメイン内の別のＣＳＥ３０６とインターフェースをとり、Ｍｃｃ’参照点は、異なるサービスプロバイダドメイン３０８内の別のＣＳＥとインターフェースをとる。Ｍｃｎ参照点は、下層ネットワークサービスエンティティ（ＮＳＥ）３１０とインターフェースをとる。ＮＳＥ３１０は、デバイス管理、位置特定サービス、およびデバイストリガ等の下層ネットワークサービスをＣＳＥに提供する。ＣＳＥ３０２は、「発見」および「データ管理およびリポジトリ」等の「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含む。

図４は、ｏｎｅＭ２Ｍ規格に定義されたＣＳＦを図示する。発見４０２および登録４０４等の基本ＣＳＦから課金４０６およびデータ管理４０８等のより複雑なＣＳＦまでの広範囲のＣＳＦが、定義される。

デバイス管理（ＤＭ）は、中央に位置する施設におけるユーザが、遠隔に位置するデバイスを構成、監視、診断、および別様に管理し得る、プロセスである。これは、デバイスが本質的にモバイル性である、またはそれらへのアクセスを困難にする遠隔エリアに展開されるとき、特に貴重である。典型的には、中央施設におけるＤＭサーバ５０２が、デバイス５０４上で実行されるためのコマンドをプッシュする。デバイス５０４上で起動するＤＭクライアントは、これらのコマンドを受信し、所望の動作を実行するために必要な状態変更を処理することができる。ＤＭサーバ５０２とＤＭクライアントとの間の本通信機構は、定義されたプロシージャおよびメッセージフォーマットを使用して実装され、ＤＭプロトコルとして知られる。２つの周知のオープンモバイルアライアンス（ＯＭＡ）ＤＭプロトコルは、ＤＭプロトコル（ｈｔｔｐ：／／ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇ／ａｂｏｕｔ−ｏｍａ／ｗｏｒｋ−ｐｒｏｇｒａｍ／ｄｅｖｉｃｅ−ｍａｎａｇｅｍｅｎｔ／）およびＬＷＭ２Ｍプロトコルである。

図５は、ＤＭサーバ５０２がデバイス管理コマンドをデバイス５０４上で起動するＤＭクライアントに送信する、ＯＭＡ ＤＭプロトコルアーキテクチャを示す。ＤＭクライアントは、管理オブジェクト（ＭＯ）５０６のセットをＤＭツリー５０８と称されるリソース構造内に維持する。これらのＭＯ５０６は、ソフトウェア更新等のデバイス上の特定の機能を管理するために使用される。管理コマンドは、ＤＭツリー５０８のノード上で動作し、状態変更をデバイス内に生じさせ得る。これらの管理コマンドは、ＤＭプロトコルを使用して、ＤＭインターフェース５１０を経由して送信される。デバイス特有インターフェース５１４は、ＤＭプロトコルの範囲外にあって、プラットフォーム特有である。

ＯＭＡ ＬＷＭ２Ｍプロトコルは、ＬＷＭ２Ｍサーバ６０２がデバイス６０８上で起動するＬＷＭ２Ｍクライアント６０４を管理する、クライアント−サーバアーキテクチャを提供する。図６は、ＬＷＭ２Ｍアーキテクチャと、それが提供する異なるインターフェースとを示す。加えて、ＬＷＭ２Ｍオブジェクト６０６は、デバイス６０８上に常駐するリソースであって、ＤＭ動作は、オブジェクト６０６上で実施される。

ＯＭＡ ＬＷＭ２Ｍプロトコルは、制約アプリケーションプロトコル（ＣｏＡＰ）規格群を組み込む。ＣｏＡＰ規格群は、「Ｔｈｅ Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣｏＡＰ）−ＲＦＣ７２５２」、「Ｇｒｏｕｐ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｏｒ ｔｈｅ Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣｏＡＰ）−ＲＦＣ７３９０」、「ＣｏＲＥ Ｒｅｓｏｕｒｃｅ Ｄｉｒｅｃｔｏｒｙ」、および「ＣｏＲＥ Ｌｉｎｋ Ｆｏｒｍａｔ−ＲＦＣ ６６９０」をその仕様の一部として含むことができる。

ＣｏＡＰは、ＩｏＴシナリオのために最適化されたアプリケーションレベルウェブ転送プロトコルである。ＣｏＡＰは、現在のウェブにおける今日のＨＴＴＰの顕著な役割に類似する、顕著な役割を将来的ＩｏＴ通信において担うことが予期される。ＣｏＡＰは、ユニバーサルリソースインジケータ（ＵＲＩ）およびクライアント／サーバベースの表現状態転送（ＲＥＳＴ）通信モデル等の現在のインターネットウェブからの重要な概念を再使用する。また、ＣｏＡＰは、ＩｏＴシナリオのために最適化されるため、現在のウェブにおいて利用不可能ないくつかの特徴をサポートする。例えば、ＣｏＡＰは、トランスポートのためのＵＤＰおよびバイナリメッセージヘッダエンコーディングを使用するため、非常に低オーバーヘッドを有する。ＣｏＡＰはまた、１つのクライアントから複数のサーバへのメッセージのマルチキャスト配布をサポートする（Ｇｒｏｕｐ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｏｒ ｔｈｅ Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣｏＡＰ）−ＲＦＣ７３９０）。

ＣｏＡＰの相互作用モデルは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）のクライアント／サーバモデルに類似する。ＣｏＡＰ７０２は、図７に示されるように、論理上、２層アプローチを使用するものと見なされ得る。特に、ＣｏＡＰメッセージ層７０４は、ＵＤＰ７０６（異なる信頼性要件を伴う）に対処する一方、要求／応答層７０８は、メソッド（ＧＥＴ、ＰＵＴ、ＰＯＳＴ、ＤＥＬＥＴＥ）および要求／応答コードを使用することによって、相互作用の非同期性質に対処する。しかしながら、ＣｏＡＰ７０２は、論理メッセージ層および要求／応答層がＣｏＡＰヘッダの単なる特徴であるという意味では、単一プロトコルである。

ＣｏＡＰはまた、ネットワーク内の他のデバイス上の利用可能なＵＲＩ（リソース）についての情報を記憶する、リソースディレクトリ（ＲＤ）と呼ばれる中央サーバを導入する。これは、ＲＤコアリソースディレクトリ上の単一ルックアップインターフェースを介して、任意のＩｏＴデバイスによって要求されるＵＲＩの迅速発見を可能にする。要求されるＵＲＩについての情報は、ＲＤによって、リンクフォーマットと呼ばれる具体的フォーマットにおいて返される（ＣｏＲＥ Ｌｉｎｋ Ｆｏｒｍａｔ−ＲＦＣ６６９０）。

本開示は、単一一次デバイスおよび関連連携させられた二次デバイスのグループを伴う、ＩｏＴシナリオにおけるＩＰベースのサービスのための連携動作を説明する。デバイスは、サブスクライバ識別モジュール（ＳＩＭ）を有していないと仮定される。具体的には、本開示は、以下のための新しいサービス層論理を説明する。
− ＩｏＴ連携グループを動的に作成する（適切な連携グループへのデバイスの自動割り当てを含む）
− 選択されたトリガに基づいて、連携サービスをアクティブにする（すなわち、ＳＬサーバの内部論理または外部ノード入力から）
− 次いで、連携動作の一部として、
ｏ サービス配信を一次デバイスからＩｏＴ連携グループにリダイレクトする
ｏ ＩｏＴ連携グループのメンバから発信されたメッセージを処理し、一次デバイスから生じるかのようにそれらを外部から転送する
− 選択されたトリガに基づいて、連携サービスを非アクティブにする（ＳＬサーバの内部または外部ノード入力から）

ＩｏＴグループ連携サービスのＯＭＡ ＬＷＭ２Ｍ実施形態および別個のｏｎｅＭ２Ｍ実施形態が、説明される。また、新しいユーザインターフェースが、所与のＩｏＴ連携グループの一次および二次メンバを図式的に表示するために定義される。最後に、本特徴をサポートするためのＯＭＡ、ＩＥＴＦ、およびｏｎｅＭ２Ｍ規格に対する提案される変更が、説明される。

本概要は、以下の発明を実施するための形態においてさらに説明される、一連の概念を簡略化された形態において導入するために提供される。本概要は、請求される主題の重要な特徴または不可欠な特徴を識別することを意図するものではなく、請求される主題の範囲を限定するために使用されることを意図するものでもない。さらに、請求される主題は、本開示の任意の部分に記載される不利点のいずれかまたは全てを解決する制限に限定されない。

より詳細な理解が、付随の図面と併せて一例として挙げられる、以下の説明からもたらされ得る。

図１は、サービス層をサポートするプロトコルスタックを図示する。

図２は、ネットワーク内の例示的サービス層展開を図示する。

図３は、ｏｎｅＭ２Ｍアーキテクチャを図示する。

図４は、ｏｎｅＭ２Ｍ共通サービス機能（ＣＳＦ）を図示する。

図５は、ＯＭＡ ＤＭプロトコルアーキテクチャを図示する。

図６は、ＯＭＡ ＬＷＭ２Ｍプロトコルアーキテクチャを図示する。

図７は、ＣｏＡＰのための抽象化層を図示する。

図８は、連携サービス配信概念を図示する。

図９は、連携サービス発信概念を図示する。

図１０は、ユーザアクティブ化連携サービスを図示する。

図１１Ａは、自宅所有者がアラームサービスがトリガされるときにＴＶを鑑賞している実施形態を図示する。

図１１Ｂは、配信されるグループデバイスのための連携サービスを図示する。

図１２は、一実施形態の連携サービス装置を図示する。

図１３は、連携グループ形成のためのサービス層サーバフローチャートを図示する。

図１４は、連携グループサービスアクティブ化のためのサービス層サーバフローチャートを図示する。

図１５は、サービストリガおよび連携グループへの配信のためのサービス層サーバフローチャートを図示する。

図１６は、連携グループから発信されたサービスのためのサービス層サーバフローチャートを図示する。

図１７は、自宅内のグループ連携サービスのためのネットワークアーキテクチャを図示する。

図１８は、連携グループ形成段階を図示する。

図１９は、連携グループサービスアクティブ化段階を図示する。

図２０は、連携グループサービスのためのサービストリガ段階を図示する。

図２１は、連携グループへのサービス配信を図示する。

図２２は、連携させられたデバイスのグループにおけるメッセージの最終表示を図示する。

図２３は、連携グループサービスのためのｏｎｅＭ２Ｍ ＣＳＦを図示する。

図２４は、連携グループへのサービス配信の例を図示する。

図２５は、ｏｎｅＭ２Ｍ「連携グループ」リソースタイプを図示する。

図２６は、ＩｏＴ連携グループメンバ識別のための例示的ユーザインターフェースを図示する。

図２７Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システムの略図である。

図２７Ｂは、Ｍ２Ｍサービス層を図示する、略図である。

図２７Ｃは、Ｍ２Ｍネットワークノードの例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。

図２７Ｄは、Ｍ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る、例示的コンピューティングシステムのブロック図である。

最も広義における連携は、一般に、ある他の識別のためにサービス存在を確立することを指す。連携が確立されると、サービスは、デバイスおよびサービスの能力に従って、一次デバイス８０２から連携させられた（二次）デバイス８０４に拡張されることができる。例えば、そのようなサービスは、音声、ビデオ、メッセージング、およびＩＰデータを含むことができる。また、連携させられた（二次）デバイス８０４から発信されたメッセージは、一次デバイス８０２から生じるかのように現れることができる。

図８は、連携サービス配信の概念を図示する。図８のステップ１では、送信側デバイス８０６が、ＩＤ−Ａのネットワーク識別子を有する、一次デバイス８０２に向けて、一般的メッセージ（例えば、トリガ指示、電子メール、ビデオクリップ等）を送信する。メッセージは、最初に、サービス層（ＳＬ）サーバ８０８にルーティングされ、連携がアクティブにされる場合、代わりに、図８のステップ２において、メッセージを連携させられた（二次）デバイス８０４にルーティングすることができる。これを遂行するために、ＳＬサーバ８０８は、メッセージの宛先ネットワーク識別子を連携させられたデバイス８０４（すなわち、ＩＤ−ＡからＩＤ−Ｂ）に切り替えることが可能であることが要求される。また、ＳＬサーバ８０８は、サービスの一部として遂行される必要がある、他の関連アクション（例えば、データを記憶する、メッセージフォーマットを変更する等）をトリガし得る。全てのこれらのアクションは、典型的には、ＳＬサーバ８０８に定義されたポリシによって規定されることができる。

図９は、連携サービス発信の概念を図示する。図９のステップ１では、連携させられた（二次）デバイス８０４が、一次デバイス８０２の代わりに、ＩＤ−Ｃのネットワーク識別子を有する、外部デバイス９０２に向けて一般的メッセージ（例えば、トリガ指示、電子メール、ビデオクリップ等）を送信する。メッセージは、最初に、ＳＬサーバ８０８にルーティングされ、連携がアクティブにされる場合、図９のステップ２において、メッセージを外部デバイスにルーティングすることができる。これを遂行するために、ＳＬサーバ８０８は、一次デバイス８０２のネットワーク識別子である、メッセージの送信側デバイスネットワーク識別子をＩＤ−Ａ（すなわち、ＩＤ−Ｂから）に切り替えることが可能であることが要求される。また、ＳＬサーバ８０８は、サービスの一部として遂行される必要がある、他の関連アクション（例えば、データを記憶する、メッセージフォーマットを変更する等）をトリガし得る。全てのこれらのアクションは、典型的には、ＳＬサーバ８０８に定義されたポリシによって規定されることができる。

連携とコール転送およびペアリング等の代替特徴との間の重要な技術的差異を比較することが、有益である。コール転送は、アクティブにされると、電話コールを１つの宛先（例えば、電話−Ａ）から別の宛先（例えば、電話−Ｂ）にリダイレクトする、一般的音声電話特徴である。リダイレクトは、条件付きであることができる（例えば、３回鳴った後、電話−Ａユーザが応答しない場合のみ転送する）。またはリダイレクトは、絶対的であることができる（例えば、電話−Ａを全く鳴らさず、代わりに、直ちに電話−Ｂに転送する）。

ペアリングは、最近、Ａｐｐｌｅ Ｃｏｒｐｏｒａｔｉｏｎによって一般化されたものである。所与のユーザのＡｐｐｌｅウォッチが、例えば、ローカル短距離Ｂｌｕｅｔｏｏｔｈ（登録商標）接続を介して、そのＡｐｐｌｅ ｉＰｈｏｎｅ（登録商標）と明示的にペアリングされることができる。主要なネットワーク接続は、ｉＰｈｏｎｅ（登録商標）を通して行われ、情報が、次いで、要求に応じて（ユーザがｉＰｈｏｎｅ（登録商標）、ウォッチ、または両方上で起動するように構成したアプリケーションに基づいて）、ｉＰｈｏｎｅ（登録商標）からウォッチに選択的に中継されることができる。現在のＯＭＡ連携仕様化取組と異なり、Ａｐｐｌｅウォッチは、現在、ＳＩＭカードまたはセルラー接続能力を有していないことに留意されたい。全てのセルラーおよびＩＰサービスは、最初に、ｉＰｈｏｎｅ（登録商標）に配信されなければならず、これは、次いで、要求されるサービスをウォッチに選択的に中継することができる。

連携とこれらの代替特徴との間の重要な差異のうちのいくつかは、以下である。

コール転送は、一方向のみである。コールをデバイスの所与のセットのうちの１つに配信する。しかしながら、デバイスのセットのいずれかから発信されたコールのための任意の特徴サポートを有していない。対照的に、連携は、双方向特徴サポートを有することができる（すなわち、配信および発信の両方）。

ペアリングは、２つのデバイス（例えば、電話およびウォッチ）間のローカル特徴であって、これらのデバイスの一方（例えば、電話）のみが、ネットワークへの接続を有する。ネットワークは、他方のデバイス（例えば、ウォッチ）を認識することさえない場合がある。ネットワークに接続されるデバイス（例えば、電話）は、次いで、ユーザがそのデバイス（ウォッチ）上の所与のアプリケーションにアクセスすることを所望すると、他方のデバイス（例えば、ウォッチ）のためのネットワーク中継器として作用することができる。対照的に、連携は、所与のデバイスが中継器として作用することを要求しない。言い換えると、連携では、全てのデバイスが、ネットワークと直接通信することが可能であり得る。

また、これらのサービスの他の変形例も存在するが、全ての場合において、連携と比較して、いくつかの重要な技術的差異が存在する。

ＯＭＡにおける最新連携仕様作業は、ＳＩＭを伴うセルラーデバイスを対象とする。ＯＭＡアプローチはまた、連携を有効にするためにリアルタイム手動構成を要求する（例えば、アクティブ化コードを打ち込む）。本アプローチは、以下のＩｏＴユースケースでは、良好に機能しない。
（１） 多くのＩｏＴデバイスが、ＳＩＭを有していない。
（２） ＩｏＴデバイスのリアルタイム手動構成は、複雑である（時として、実行可能ですらない）
（３） ＩｏＴデバイスは、関連デバイスのグループ内で展開される。

現在ＯＭＡは、ＯＭＡが主にセルラーデバイスユースケースに関心があるため、それぞれＳＩＭカードを有するデバイスの連携のみを検討している。したがって、ＩｏＴデバイス（多くの場合、ＳＩＭカードを有していない）は、現在のＯＭＡ仕様化取組では、あまり考慮されない。また、ＯＭＡは、連携プロセスの間、ヒト手動介入を要求する（例えば、アクティブ化コードを手動で打ち込む）。最後に、関連デバイスのグループ等のＩｏＴデバイスの他の特性も、ＯＭＡ仕様化取組によって良好にサポートされない。

以下は、現在のＯＭＡ仕様化取組において良好に網羅されていない、ユースケースのいくつかの例である。
１． 健康関連測定を監視するウェアラブルウォッチ（ＳＩＭを伴わない）と連携する、モバイル電話−Ａ（ＳＩＭを伴う）
２．健康監視アプリケーションを起動するラップトップ（ＳＩＭを伴わない）と連携する健康関連測定を監視する、スマートウォッチ（ＳＩＭを伴わない）。
３． コネクテッドハウスの複数の部屋にわたって散乱されたＳＩＭを伴わないエンターテインメントユニット（ＴＶ、ｉＰｏｄ（登録商標）等）のグループと連携する、モバイル電話−Ａ（ＳＩＭを伴う）。
４． コネクテッドハウスの複数の部屋にわたって散乱されたＳＩＭを伴わないエンターテインメントユニット（ＴＶ、ｉＰｏｄ（登録商標）等）のグループと連携する、スマートウォッチ（ＳＩＭを伴わない）

前述のユースケース＃４は、ＩｏＴデバイス（ＳＩＭを伴わない）をサポートする連携特徴を有することの価値を示すために、次の節においてさらに展開される。

ＯＭＡは、モバイルデバイスの連携をサポートするためのＯＭＡプロトコルＴｗｉｎｎｉｎｇ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｅｖｉｃｅｓ（ＴＷＩＮ）ｐｒｅｓｅｎｔａｔｉｏｎ（ＯＭＡ−ＴＰ−２０１４−０１２８−ＩＮＰ＿ＬｏｏｋＦｗｄ＿Ｗｅａｒａｂｌｅ＿Ｄｅｖｉｃｅ＿Ｔｗｉｎｎｉｎｇｈｔｔｐ：／／ｍｅｍｂｅｒ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇ／ｆｔｐ／Ｐｕｂｌｉｃ＿ｄｏｃｕｍｅｎｔｓ／ＴＰ／２０１４／）およびＲＥＳＴｆｕｌ Ｎｅｔｗｏｒｋ ＡＰＩ ｆｏｒ Ｔｗｉｎｎｉｎｇ Ｒｅｑｕｉｒｅｍｅｎｔｓ（ＯＭＡ−ＲＤ−ＲＥＳＴ＿ＮｅｔＡＰＩ＿Ｔｗｉｎ−Ｖ１＿０−２０１５０４０７−Ｃ“ｈｔｔｐ：／／ｔｅｃｈｎｉｃａｌ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇ／Ｔｅｃｈｎｉｃａｌ／ｔｅｃｈｎｉｃａｌ−ｉｎｆｏｒｍａｔｉｏｎ／ｒｅｌｅａｓｅ−ｐｒｏｇｒａｍ／ｃｕｒｒｅｎｔ−ｒｅｌｅａｓｅｓ／ｔｗｉｎｎｉｎｇ−ｖ１−０”）への変更についての調査するための作業項目を採用している。

ＯＭＡ連携規格が必要とされる理由に関してＯＭＡによって識別される理由のうちのいくつかは、以下を含む。
・ 複数の独立してネットワーク化されたデバイス上のユーザ存在の確立は、例えば、電子メール、ソーシャルネットワーキング、通信のために、すでに共通ＵＸ（ユーザ体験）である。
・ 多くの新しいデバイスタイプが、市場に出回っており、例えば、一般には、ウェアラブル、コネクテッドカー、およびコネクテッドデバイスである。
・ これらのデバイスの多くは、限定されたＵＩ（ユーザインターフェース）能力を有し得る。
・ これらのデバイス上のユーザ存在の確立は、単純かつ効果的である必要がある。
・ 市場は、このための規格が開発されない限り、分断化されたままとなるであろう。

「コネクテッドカーディスプレイを一次モバイルデバイスに連携させる」ための連携要件に関するＲＥＳＴｆｕｌネットワークＡＰＩからのＯＭＡユースケースに目を向けることが、有益である。
・ このシナリオは、ユーザに、コネクテッドカーディスプレイをその一次モバイルデバイスに連携させる能力を提供する。
・ これは、ユーザが、コール／テキストの宛先が一次デバイス８０２である、音声コールおよびテキストメッセージを車のディスプレイ上で受信する結果をもたらすであろう。また、車のディスプレイの能力に応じて、ユーザは、音声コールまたはテキストメッセージングを発信し得る一方、その宛先におけるユーザは、発信側ユーザの一次デバイス８０２から発信されたコール／テキストを確認するであろう。

連携要件に関するＲＥＳＴｆｕｌネットワークＡＰＩからの前述のための詳細なユースケース説明は、以下の通りである。
１． Ｔｏｍは、連携特徴のサブスクライバである。
２． Ｔｏｍは、その一次モバイルデバイスから連携アクティブ化要求を開始する。
３． Ｔｏｍは、認証され、連携動作の認可が、与えられる。次いで、Ｔｏｍは、その一次デバイス８０２（ＡＰＩゲートウェイまたはバックエンドシステムによって）の画面上において、有効連携コードを打ち込む必要があることをプロンプトされる。また、有効連携コードを取得する方法に関する指示も、画面上に表示される。
４． Ｔｏｍは、指示に従って、その二次デバイス（すなわち、車のディスプレイ）から連携コードに関する要求を開始する。
５． ＡＰＩゲートウェイは、有効連携コードをＴｏｍの二次デバイスに返し、これは、Ｔｏｍに表示される。
６． Ｔｏｍは、連携コードを確認し、連携コードを一次デバイス８０２（Ｔｏｍがコードを打ち込み、「継続」を押下することを待つ）の連携アクティブ化画面に打ち込む。
７． ＡＰＩゲートウェイは、認可サーバおよび連携イネーブラと併せて、アクセストークンおよび連携コードの妥当性を検証し、連携イネーブラにおいて、一次デバイス８０２と二次デバイスとの間の適切な連携関連付けを設定する。一次および二次デバイス間の連携ステータスは、連携アクティブ化動作に応じて、デフォルトによって「オン」に設定される。
８． ＡＰＩゲートウェイは、必要とされるとき／場合、後続動作のために（例えば、トグル連携特徴）、異なるＯＡｕｔｈアクセストークンを一次および二次デバイス上の両アプリケーションに提供する。

ＯＭＡは、現在、一次および二次デバイスの両方がＳＩＭカードを有する場合の連携プロトコルを定義している（Ｅｎａｂｌｅｒ Ｒｅｌｅａｓｅ Ｄｅｆｉｎｉｔｉｏｎ ｆｏｒ ＲＥＳＴｆｕｌ Ｎｅｔｗｏｒｋ ＡＰＩ ｆｏｒ Ｔｗｉｎｎｉｎｇ ＯＭＡ−ＥＲＥＬＤ−ＲＥＳＴ＿ＮｅｔＡＰＩ＿Ｔｗｉｎｎｉｎｇ−Ｖ１＿０−２０１５０４０７−Ｃａｎｄｈｔｔｐ：／／ｔｅｃｈｎｉｃａｌ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｏｒｇ／Ｔｅｃｈｎｉｃａｌ／ｔｅｃｈｎｉｃａｌ−ｉｎｆｏｒｍａｔｉｏｎ／ｒｅｌｅａｓｅ−ｐｒｏｇｒａｍ／ｃｕｒｒｅｎｔ−ｒｅｌｅａｓｅｓ／ｔｗｉｎｎｉｎｇ−ｖ１−０）

これは、主に、セルラーインフラストラクチャを使用した連携シナリオのためのセキュリティおよび課金を制御する理由からである。

本節は、家庭設定におけるＩｏＴデバイスのグループを伴う連携サービスのためのユースケース（今日の技術においてサポートされていない）を詳述する。本ユースケースでは、一次デバイス８０２は、スマートウォッチである。二次デバイスは、単一デバイスではなく、代わりに、関連ＩｏＴデバイスのグループ（すなわち、ＴＶとして特徴付けられるが、また、コンピュータディスプレイ、タブレット等でもあり得る、家庭内のディスプレイデバイスのグループ）である。連携サービスとは、本質的に、スマートウォッチ（一次デバイス８０２）上に表示されることが意味される任意のホームセキュリティアラームメッセージが、代わりに、家庭内の全てのＴＶ（二次デバイスグループ）上に表示され得るものである。スマートウォッチが、自宅にない場合、連携サービスは、トリガされず、代わりに、アラームメッセージのみが、スマートウォッチである、一次デバイス８０２上に表示される。

このユースケースは、自宅所有者がその家に入り、図１０のそのスマートウォッチ１００２を介して、その「ホームセキュリティ−グループ通知モード」をオンにすることで開始する。

図１１Ａに示されるように、一定時間後、自宅所有者１１０２は、その書斎に行き、ＴＶ１１０４を鑑賞する。その瞬間、野球をしている近隣の子供が、自宅所有者の台所の窓に誤ってボールを投げ込み、窓を破損する。ホームセキュリティシステムが、台所の窓の損傷を直ちに検出する。グループ連携サービスが、次いで、図１１Ａに示されるように、トリガされ、通知１１０６が、家庭内の全てのＴＶ画面上に表示される。グループ連携サービスが、アクティブではない場合、通知のみが、自宅所有者のスマートウォッチ１００２上に表示されるであろうことに留意されたい。

最後に、図１１Ｂは、家庭内の３つのＴＶ１１１０、１１１２、および１１１４のそれぞれ上に表示されているグループ連携メッセージを示す。同一メッセージが、ＩｏＴデバイスの全てのグループの画面上に示される。表示されているメッセージは、「セキュリティシステム−台所の窓がたった今壊されました」。これは、自宅の任意の他の居住者（自宅所有者に加え）がセキュリティアラートを認識することを可能にすることができる。

主な相違は、連携可能ＩｏＴデバイス（ＳＩＭを伴わない）をサポートすることと、また、関連デバイスの連携グループもサポートすることである（単一二次デバイスの代わりに）。また、現在のＯＭＡ連携アプローチは、ユーザがその携帯電話と二次デバイスとの間の連携特徴を手動でアクティブにすることを要求する（例えば、連携認可コードをデバイスに打ち込むことによって）。本アプローチは、連携の候補であり得、かつリアルタイム手動構成が典型的には容易ではない、関連デバイスのグループを有し得る、ＩｏＴユースケースに適さない。

図１２は、サービス層（ＳＬ）サーバ１２０２を示す。サービス層（ＳＬ）サーバ１２０２は、ＬＷＭ２Ｍサーバまたはある他のタイプのサーバであることができる。サービス層（ＳＬ）サーバ１２０２は、連携サービス１２０４と、位置特定サービス１２０６とを含むことができる。連携サービス１２０４は、連携グループおよび連携グループのデバイスへまたはそこからのメッセージのリダイレクトを維持することができる。位置特定サービス１２０６は、一次デバイス８０２の場所を決定し、一次デバイス８０２が連携サービス１２０６をアクティブにするために適切な場所にあるかどうかを決定することができる。

図１２に図示される機能性は、それらの以下に説明される図２７Ｃまたは２７Ｄに図示されるもののうちの１つ等、Ｍ２Ｍネットワーク（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のノードのメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得ることを理解されたい。

図１３は、以下のステップを伴う、ＳＬサーバ１２０２におけるＩｏＴ連携グループ形成のためのフローチャートを示す。

図１３のステップ１では、ＳＬサーバ１２０２に関連付けられた二次ＩｏＴデバイスが、登録される。登録は、デバイスのタイプおよび機能等の識別情報、場所情報、ＩＰアドレス、サービス層識別子、アプリケーション識別子、またはデバイスハードウェア識別子等のデバイス識別子、ネットワークパスワード、製造業者識別子等を含むことができる。

図１３のステップ２では、受信された情報に基づいて、ＳＬサーバ１２０２は、デバイスが連携グループ１２１４に割り当てられることができるかどうかを決定する。例えば、ある機能（例えば、カメラ監視、ビデオ表示、または音楽生成）対応の全てのデバイスが、その具体的機能のために連携グループの一部として割り当てられるための候補であり得る。

図１３のステップ４および５では、ＳＬサーバ１２０２は、次いで、デバイスのための候補連携グループ１２１４が場所依存であるかどうか（例えば、全てのカメラが、家庭の所与の部屋内に位置しなければならない）、該当する場合、デバイスが正しい場所にあるかどうかとをチェックする。候補メンバはまた、そのスリープスケジュール、伝送ビットレート、製造業者互換性等の他の要因に関してチェックされ得る（図示せず）。

図１３のステップ６および７では、ＳＬサーバ１２０２は、全てのチェックに合格する場合、連携グループの一部としてデバイスを内部で関連付ける。そうでなければ、プロセスを停止する。

図１３のステップ８では、可能である場合、ＳＬサーバ１２０２は、デバイスをトリガし、ＩＰマルチキャストグループに加える（例えば、Ｇｒｏｕｐ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｏｒ ｔｈｅ Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣｏＡＰ）−ＲＦＣ７３９０参照）。これは、ＳＬと連携グループ１２１４との間の効率的将来的相互作用を可能にすることができる。（不可能である場合、ＳＬサーバ１２０２は、依然として、情報をグループに配布するためのシリアルユニキャスト、ブロードキャスト、または他の機構を介して、連携グループ１２１４内のデバイスにコンタクトすることができる。便宜上、本書の残りは、連携グループデバイスがＩＰマルチキャストグループの一部であると仮定し得る。）デバイスに送信されるトリガメッセージは、ＩＰマルチキャストグループに関する識別情報を含むことができ、連携グループ１２１４に関する識別情報を含み得る。

本プロセスの終了時、以下の識別情報が、連携プロセスのためにＳＬサーバ１２０２において利用可能となり得る。
・ 二次デバイス１２０８、１２１０、および１２１２：
ｏ ＩＰマルチキャスト（グループ）アドレス
・ 通常マルチキャストＩＰアドレス割り当てプロシージャ（例えば、ＩＡＮＡ Ｇｕｉｄｅｌｉｎｅｓ ｆｏｒ ＩＰｖ４ Ｍｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓ Ａｓｓｉｇｎｍｅｎｔｓ−ＲＦＣ５７７１−ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５７７１）に従って割り当てられ得る
ｏ サービス層連携グループＩＤ
・ ＳＬサーバ１２０２によって割り当てられる
・ 所与の二次デバイスが、１以上の独立連携グループに割り当てられ得る
・ 一次デバイス８０２：
ｏ ユニキャストＩＰアドレス
・ 通常ＩＰアドレス割り当てプロシージャ（例えば、ＤＨＣＰ Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＤＨＣＰ）−ＲＦＣ２１３１ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ２１３１）に従って割り当てられる
ｏ 一次デバイス８０２は、所与の連携グループ（すなわち、サービス層連携グループＩＤ）に関連付けられるように事前にプロビジョニングされる必要があるであろう。事前プロビジョニングは、手動で、またはいくつかのアプリケーション論理を通して行われ得る。２つ以上の一次デバイス８０２が、所与の連携グループに接続されることができない。しかしながら、所与の一次デバイス８０２

図１３に図示されるステップを行うエンティティは、図２７Ｃまたは図２７Ｄに図示されるもの等の、ネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１３に図示される方法は、図２７Ｃまたは図２７Ｄに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１３に図示されるステップを実施する。また、図１３に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解されたい。

図１４は、以下のステップを伴う、ＳＬサーバ１２０２におけるＩｏＴ連携グループサービスアクティブ化のためのフローチャートを示す。

図１４のステップ１では、一次デバイス８０２（所与の連携グループに関連付けられる）が、所与の連携グループ１２１４がアクティブにされるべきであることを示す、メッセージを送信する。メッセージはまた、一次デバイス８０２の場所を含み得る。

図１４のステップ２では、トリガも、ＳＬサーバ論理によって内部で生成され得る（例えば、所与の連携グループは、所与の時刻にアクティブにされ得る）。

図１４のステップ３−５では、ＳＬサーバ１２０２は、次いで、連携サービスが場所依存であるかどうかと、一次デバイス８０２が正しい場所にあるかどうかとをチェックする。ＳＬサーバ１２０２はまた、時刻等の他の条件をチェックし得る（図示せず）。

図１４のステップ６では、全ての条件が満たされる場合、ＳＬサーバ１２０２は、所与の連携グループサービスがここでアクティブにされることを内部で記録する。

連携グループサービスを非アクティブにする逆のプロセスは、類似するが、より単純なプロセスであることができる。具体的には、一次デバイス８０２は、非アクティブ化を示すメッセージをＳＬサーバに送信することができる。ＳＬサーバ１２０２はまた、内部論理トリガに基づいて、特定のグループメンバに関する連携サービス１２１４を非アクティブにすることを決定することができる。トリガの例は、デバイスがその場所を変更する、新しいＩＰアドレスを入手する、再認可する、再認証する等であり得る。次いで、ＳＬサーバ１２０２は、所与の連携グループサービスを非アクティブ化としてマークすることができる。

図１４に図示されるステップを行うエンティティは、図２７Ｃまたは図２７Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る、論理エンティティであることが理解される。すなわち、図１４に図示される方法は、図２７Ｃまたは図２７Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１４に図示されるステップを行う。また、図１４に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解されたい。

図１５は、以下のステップを伴う、ＳＬサーバ１２０２による連携グループへのサービス配信のためのフローチャートを示す。

図１５のステップ１ａ−１ｂでは、第三者デバイス（例えば、典型的には、アラームコントローラ等の所与のサービスに関連付けられる）が、一次デバイス８０２のためのメッセージを送信する。または、代替として、ＳＬサーバ１２０２内の内部トリガ論理が、メッセージを開始し得る。

図１５のステップ２−３では、ＳＬサーバ１２０２は、所与の連携サービスが場所依存であるかどうかと、該当する場合、一次デバイス８０２が正しい場所にあるかどうかとをチェックする。ＳＬはまた、時刻等の他の条件をチェックし得る（図示せず）。

図１５のステップ５では、次いで、ＳＬサーバ１２０２は、連携サービスが現在アクティブであるかどうかをチェックする。

図１５のステップ４および６では、一次デバイス８０２が、正しい場所にない、または連携サービスがアクティブではない（または他の条件のうちの１つが満たされない）場合、連携プロセスは、停止され、メッセージが、直接、一次デバイス８０２に配信される（すなわち、何も連携グループに配信されない）。

図１５のステップ７では、全ての条件が満たされる場合、ＳＬサーバ１２０２は、次いで、任意の要求されるサービス関連マルチキャストメッセージを全ての連携グループメンバに送信する。また、ＳＬサーバ１２０２は、サービスの一部として遂行される必要がある他の関連アクション（例えば、データを記憶する、メッセージフォーマットを変更する等）をトリガし得る。全てのこれらのアクションは、典型的には、ＳＬサーバ１２０２に定義されたポリシによって規定されることができる。

典型的ケースでは、連携させられたサービスは、二次デバイス１２０８、１２１０、および１２１２（すなわち、ＩｏＴ連携グループメンバ）のみにリダイレクトされる。しかしながら、ＳＬサーバ１２０２ポリシが、決定付ける場合、連携させられたサービスはまた、その二次デバイス１２０８、１２１０、および１２１２に連携させられているものに加え、一次デバイス８０２上にミラーリングされ得る。

所与の二次デバイスは、複数の独立連携グループに属し得る。したがって、２つまたはそれを上回るサービスは、メッセージを所与の二次デバイスに同時に配信することを試みてもよいことが、可能である。その場合、連携サービス優先順位レベルが、適切な優先順位化が、同時連携サービスの処理、表示等の観点から、ＳＬサーバ１２０２および二次デバイスの両方において行われ得るように、各サービスに割り当てられるべきである。

図１５に図示されるステップを行うエンティティは、図２７Ｃまたは図２７Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る、論理エンティティであることが理解される。すなわち、図１５に図示される方法は、図２７Ｃまたは図２７Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１５に図示されるステップを行う。また、図１５に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解されたい。

図１６は、以下のステップを伴う、連携グループから発信されたサービス配信のためにＳＬサーバ１２０２において行われるフローチャートを示す。

図１６のステップ１では、ＩｏＴ連携グループのメンバは、発信メッセージをＳＬサーバ１２０２に送信する。

図１６のステップ２では、ＳＬサーバ１２０２は、メッセージが現在のサービスの状態に影響を及ぼすかどうかをチェックする。

図１６のステップ３では、該当する場合、ＳＬサーバ１２０２は、マルチキャストサービスメッセージをグループの全ての他のメンバに送信する。また、ＳＬサーバ１２０２は、サービスの一部として遂行される必要がある他の関連アクション（例えば、データを記憶する、メッセージフォーマットを変更する等）をトリガし得る。全てのこれらのアクションは、典型的には、ＳＬサーバ１２０２に定義されたポリシによって規定されることができる。

図１６のステップ４では、受信されたメッセージが、現在のサービスに影響を及ぼさないことが意図される場合、ＳＬサーバ１２０２が、代わりに、一次デバイス８０２の代わりに外部から送信されるかどうかをチェックする。

該当しない場合、図１６のステップ５では、プロセスは、停止する。該当する場合、図１６のステップ６では、ＳＬサーバ１２０２は、次いで、一次デバイス８０２の代わりに、メッセージをＩＰネットワークに送信する。このステップの一部として重要な点は、ＳＬサーバ１２０２が、（発信側の）ネットワークアドレスをＩｏＴ連携グループメンバ（二次デバイス１２０８、１２１０、および１２１２）から一次デバイス８０２のものに切り替えることができることである。また、ＳＬサーバ１２０２は、サービスの一部として遂行される必要がある他の関連アクション（例えば、データを記憶する、メッセージフォーマットを変更する等）をトリガし得る。全てのこれらのアクションは、典型的には、ＳＬサーバ１２０２に定義されたポリシによって規定されることができる。

図１６に図示されるステップを行うエンティティは、図２７Ｃまたは図２７Ｄに図示されるもの等、ネットワークノードまたはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１６に図示される方法は、図２７Ｃまたは図２７Ｄに図示されるノードまたはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１６に図示されるステップを実施する。また、図１６に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解されたい。

本節は、本開示に概略された強化点とともにＯＭＡ ＬＷＭ２Ｍプロトコルを使用して、連携させられたＩｏＴデバイスのグループのためのサービス配信を達成する方法の詳細な実施形態を提供する。（ＯＭＡ ＬＷＭ２Ｍプロトコルは、その下層機構のためにＣｏＡＰ規格群を利用することに留意されたい）。具体的には、自宅アラームシステムの前のユースケースが、さらに展開される。本ユースケースにおける一次デバイス８０２は、スマートウォッチである。二次ＩｏＴデバイスの連携グループは、家庭内のＴＶのグループである。連携サービスは、本質的に、スマートウォッチ（自宅にある間）上に表示されることが意味される任意の着信セキュリティアラートメッセージが、代わりに、同時に、家庭内の全てのＴＶ（二次デバイスグループ）上に表示されることができるものである。スマートウォッチが、自宅にない場合、連携サービスは、トリガされず、代わりに、メッセージは、単に、スマートウォッチである、一次デバイス８０２上に表示される。

図１７は、ＩｏＴグループのための連携サービス１２０４のネットワークアーキテクチャを示す。このシナリオにおけるＳＬサーバは、インターネットクラウドに位置し得る、または代替として、ＩｏＴデバイスを格納する敷地（すなわち、この場合、自宅１７０４）に位置し得る、ＬＷＭ２Ｍサーバ１７０２である。示されるように、ＳＬサーバは、位置特定サービス１２０６等の他のより周知の特徴に加え、新しい連携サービス１２０４を有する。Ｗｉ−Ｆｉルータ１７０６は、ＴＶ画面１１１０、１１１２、および１１１４（Ｗｉ−Ｆｉを装備する）とＬＷＭ２Ｍサーバ１７０２との間のＩＰ接続性（可能性として、インターネットを通して）を提供する。

家庭内の全てのデバイス（すなわち、ＴＶ、スマートウォッチ、およびセキュリティコントローラ）は、ＬＷＭ２Ｍクライアントであって、したがって、ＣｏＡＰを経由してＬＷＭ２Ｍプロトコルを起動し、ＤＴＬＳ接続によって保護される。ＤＴＬＳは、連携サービスのための強固なセキュリティ基盤（例えば、認証、暗号化）を提供することができる。

図１８は、以下のステップを伴う、連携グループ形成段階を示す。

図１８のステップ１では、ＴＶ（すなわち、二次デバイス１２０８、１２１０、および１２１２）は全て、ＬＷＭ２Ｍクライアントを有し、最初の電源投入時、ＬＷＭ２Ｍサーバ１７０２に登録される。それらは、ＬＷＭ２Ｍ登録を通して、ＬＷＭ２Ｍサーバ１７０２に、それらが、連携可能であって（すなわち、連携シナリオにおいて二次デバイス１２０８、１２１０、および１２１２になり得る）、その主要な機能が、ディスプレイ画面であることを示す。それらはまた、例えば、屋内測位システム座標を通して、その場所を示す。

本節に説明される連携プロシージャに関わるエンティティは、最初に、発見、登録、セキュリティ等のための通常ＬＷＭ２Ｍプロシージャを経ると仮定される。

図１８のステップ２では、ＬＷＭ２Ｍサーバ１７０２が、登録を受信すると、最初に、場所が自宅であるかどうかをチェックする。デバイスのスリープスケジュール、伝送レート等の他のチェックも、行われ得る（図示せず）。チェックのいずれかが失敗する場合、非連携ケースであるように進められる。

ＬＷＭ２Ｍサーバ１７０２は、位置特定サービス１２０６および連携サービス１２０４を含む、いくつかのサブコンポーネントを有する。

図１８のステップ３では、全てのチェックが合格する場合、連携サービスは、次いで、全てのＴＶを「自宅ディスプレイ」連携グループの一部として登録することができる。

図１８のステップ４では、要求される場合、ＬＷＭ２Ｍ連携サービス１２０４は、次いで、ＴＶをトリガし、全てＩＰマルチキャストグループに加えることができる。これは、後続ステップにおけるより効率的グループ通信を可能にすることができる。

図１９は、以下のステップを伴う、連携グループサービスのアクティブ化段階を示す。

図１８９のステップ５では、スマートウォッチ（すなわち、一次デバイス８０２）は、自宅グループ連携モードをアクティブにする。これは、ユーザによって手動でトリガされるか、または、例えば、場所によって（例えば、ユーザが家の中に入ると）トリガされるかのいずれかであり得る。ウォッチは、次いで、例えば、屋内測位システム座標を通して、その場所情報を含む、ＬＷＭ２Ｍ更新メッセージをＬＷＭ２Ｍサーバ１７０２に送信する。スマートウォッチは、一次デバイス８０２としてＬＷＭ２Ｍサーバ１７０２に事前に登録されていると仮定される（図示せず）。これは、典型的には、手動で、またはいくつかのアプリケーション論理を通して、行われるであろう。

図１９のステップ６では、ＬＷＭ２Ｍサーバ１７０２は、次いで、ウォッチの場所をチェックすることができる。時刻等の他のチェックも、行われ得る（図示せず）。ウォッチが、自宅にない場合、連携サービスは、このサービスが自宅においてのみ適用可能であるため、トリガされないであろう。

図１９のステップ７および８では、ウォッチが、自宅にある（かつ全ての他の要求されるチェックに合格している）場合、連携サービスは、アクティブにされる。

図２０は、以下のステップを伴う、連携グループサービスのサービストリガ段階を示す。

図２０のステップ９では、同様にＬＷＭ２Ｍクライアントである、セキュリティコントローラ２００２が、破損した窓（すなわち、近隣子供の野球のボールによって誤って損傷された）を感知し、ＬＷＭ２Ｍ書き込みをＬＷＭ２Ｍサーバ１７０２に送信し、適切なデバイスにアラームを知らせることを要求する。

図２０のステップ１０では、ＬＷＭ２Ｍ位置特定サービス１２０４は、次いで、スマートウォッチが自宅にあるかどうかをチェックすることができる。スマートウォッチが、自宅にない場合、連携サービス１２０４は、トリガされず、ウォッチは、直接、知らされる。

しかしながら、図２０のステップ１１では、スマートウォッチが、自宅にある場合、連携サービス１２０４は、アラームについてトリガされる。

図２０のステップ１２では、連携モードアクティビティが、次いで、アクティブであるかどうかを確認するためにチェックされる。

アクティブではない場合、一次デバイス８０２（すなわち、ウォッチ）は、直接、アラームを知らされる。（このステップはまた、ＴＶのうちの少なくとも１つ以上のものがオンである、またはそうでなければ、単に、直接、ウォッチに知らせることもまた確実にするために、条件付きチェック（図示せず）を用いて拡張され得る）。

アクティブである場合、ＩｏＴ連携グループへのサービス配信に関する図２１を参照されたい。

図２１は、以下のステップを伴う、ＩｏＴ連携グループへのサービス配信を示す。

図２１のステップ１３および１４では、以前にトリガされたＬＷＭ２Ｍサーバ連携サービス１２０４が、ここで、書き込み要求を「自宅ディスプレイ」連携グループに送信し、アラームメッセージを表示する。

図２１のステップ１５では、アラームが、次いで、好ましくは、アラームを伝送するための最も効率的機構であり得る、ＩＰマルチキャストメッセージによって、自宅ディスプレイグループ内の個々のＴＶに伝送される。

図２２は、以下のステップを伴う、連携させられたデバイス上でのメッセージの最終表示を示す。

図２２のステップ１６では、連携グループ内の３つのＴＶ（すなわち、ＴＶ−１、ＴＶ−２、およびＴＶ−３）の各々が、同時に、アラームメッセージを表示する。一次デバイス８０２（すなわち、スマートウォッチ）は、サービスが、スマートウォッチが自宅にあるとき、代わりに、アラームメッセージがＴＶ画面上に表示されるために構成されるため、何も表示しないことに留意されたい。

所望に応じて、ＬＷＭ２Ｍ連携サービスはまた、ＴＶに加え、一次デバイス８０２（すなわち、スマートウォッチ）上にもアラームメッセージを表示するように構成され得る。

図１８−２２に図示されるステップを行うエンティティは、図２７Ｃまたは図２７Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図８−２２に図示される方法は、図２７Ｃまたは図２７Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１８−２２に図示されるステップを行う。また、図１８−２２に図示される任意の伝送および受信ステップは、ノードのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路によって行われ得ることも理解されたい。

前の節に説明されるプロシージャおよび信号フローに加え、いくつかの他の重要な変更が、連携をサポートするためにＯＭＡ ＬＷＭ２Ｍおよびその下層ＩＥＴＦ ＣｏＡＰ規格群に要求される。具体的には、以下である。
１）コアリンクフォーマットは、新しい「連携可能」リソースタイプをサポートするために変更を必要とする：
新しいリソースタイプ（ｒｔ）は、以下のように定義される必要がある：
ｒｔ＝”ｔｗｉｎｎａｂｌｅ”
使用の例：
ＬＷＭ２Ｍクライアントが、登録されると、本新しいリソースタイプを使用して、ＩｏＴ連携グループに潜在的に加わるために、所与のリソースがもたらされるかどうかを示すべきである。
本リソースタイプはまた、ＩｏＴ連携グループに加わるために割り当てられる場合、ＬＷＭ２ＭクライアントがＩＰマルチキャストグループに加わることが可能である指示を与える。
２）コアリンクフォーマットは、デバイスが“ｔｗｉｎｎａｂｌｅ＿ｄｅｖｉｃｅ”であるかどうかを示すための新しいデバイスレベル属性をサポートするために変更を必要とする。これは、リソース毎にステータスを示す、ｒｔ＝”ｔｗｉｎｎａｂｌｅ”（上記（１）に示されるように）の使用の代替実施形態であり得る。
−新しいデバイスレベルデバイスタイプ（ｄｔ）が、以下のように定義されることができる：
ｄｔ＝”ｔｗｉｎｎａｂｌｅ＿ｄｅｖｉｃｅ”，ｏｒｄｔ＝”ｎｏｎ＿ｔｗｉｎｎａｂｌｅ＿ｄｅｖｉｃｅ”
（これは、上記の（１）に示される“ｒｔ＝ｔｗｉｎｎａｂｌｅ”アプローチの代替実施形態である）。
３）ＯＭＡ ＬＷＭ２Ｍは、一次デバイス８０２とデバイスのその連携させられた二次グループとの間の相関を可能にするためにそのアクセス制御オブジェクト構造に変更を必要とする。具体的には、ＬＷＭ２Ｍでは、制御ＬＷＭ２Ｍサーバ１７０２は、アクセス制御リスト（ＡＣＬ）プロパティをＬＷＭ２Ｍクライアント内に設定する。連携特徴の追加に起因して、制御ＬＷＭ２Ｍサーバ１７０２は、それが設定する全てのＡＣＬプロパティが一次デバイス８０２およびデバイスのその関連連携させられた二次グループの所与のセットを横断して一貫することを確実にする必要がある。これは、動的連携グループの作成（またはメンバシップの変更）時における制御ＬＷＭ２ＭサーバＡＣＬデータ構造を反映されるものとする。

図２３は、ＣＳＥ参照モデル内のハイライトされた連携グループサービス（ＴＧＳ）ＣＳＦ２３０２を示す。連携グループサービス２３０２は、ｏｎｅＭ２Ｍ共通サービスエンティティ（ＣＳＥ）３０２内の新しい共通サービス機能（ＣＳＦ）である。

連携グループサービス（ＴＧＳ）ＣＳＦ２３０２は、アプリケーションエンティティ（ＡＥ）サービス配信が一次フィールドドメインノード（すなわち、単一一次ＡＳＮ）から二次フィールドドメインノードのグループ（すなわち、関連二次ＡＳＮのグループ）にリダイレクトされることを有効にする。ＴＧＳ ＣＳＦ２３０２はまた、二次フィールドドメインノードのグループのうちの１つから発信されたＡＥサービスが、アプリケーションサービスが代わりに一次フィールドドメインノードから発信されたかのように外部ネットワークノードに現れることを有効にする。

代替アプローチは、本開示に定義された新しいＴＧＳ ＣＳＦを新しいサブ機能としてｏｎｅＭ２Ｍ規格の既存のグループ管理（ＧＭＧ）ＣＳＦにまとめるであろう。これは、可能であるが、新しいＴＧＳが、グループを形成する、グループをアクティブにする際等、ＧＭＧと完全に異なるアプローチを有するため、ＴＧＳを新しいＣＳＦとして定義することがより明確である。また、新しいＴＧＳは、ＧＭＧが全くサポートしない、トラフィックのリダイレクトのような機能を有する。しかしながら、本開示は、ＧＭＧ ＣＳＦが本明細書に説明される機能性の一部または全部をサポートすることを除外するものではない。

本節は、一次および二次フィールドドメインノードが、便宜上、ＡＳＮであると仮定する。しかしながら、これらのノードはまた、本節で規定されたアプリケーション専用ノード（ＡＤＮ）およびプロシージャであり得、リソースおよび属性は、この場合、等しく良好に機能するであろう。

新しいｏｎｅＭ２Ｍリソースタイプは、連携グループサービスを有効にするために定義される。新しいリソースタイプは、＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞２５０２であって、図２５に示されるように、連携グループの作成、アクティブ化、およびステータスに関する情報を記憶する。

＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞リソースタイプ２５０２は、以下の表に規定された属性を含むことができる。

また、図２６に定義された新しいｔｗｉｎｎｉｎｇＣａｐａｂｉｌｉｔｙ属性を含むことも非常に有用であり得る。

以下のように、ＴＧＳ ＣＳＦ２３０２の動作には、いくつかの異なる段階が存在する。
１． 連携グループ形成−
ａ． 本節に説明される連携プロシージャに関わるエンティティは、最初に、発見、登録、セキュリティ等に関する通常ｏｎｅＭ２Ｍプロシージャを得ると仮定される。
ｂ．連携グループは、最初に、一次ノード（すなわち、単一一次ＡＳＮ ＴＧＳ ＣＳＦ）がＣＲＥＡＴＥ要求をＩＮ／ＭＮ ＴＧＳ ＣＳＦ上の＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞リソースに送信すると形成される。形成されるグループのタイプは、ＣＲＥＡＴＥ要求内で送信されるｔｗｉｎｎｉｎｇＣａｐａｂｉｌｉｔｙおよびｄｅｖｉｃｅＬｏｃａｔｉｏｎ属性によって示されることができる。リソースがＩＮ／ＭＮ ＴＧＳ ＣＳＦにおいて作成された後、応答内において、所与のグループに割り当てられるｔｗｉｎｎｉｎｇＧｒｏｕｐＩｄ属性を返信することができる。
・ 所与の連携グループが、後に、一次ノード（ＡＳＮ ＴＧＳ ＣＳＦ）がＤＥＬＥＴＥ要求をｔｗｉｎｎｉｎｇＧｒｏｕｐＩｄ属性とともに所与のＩＮ／ＭＮ（ＴＧＳ ＣＳＦ）に送信することによって削除されることができる
ｃ． 次のステップは、所与のグループに加わるための個々の二次ノード（すなわち、関連二次ＡＳＮのグループ）のためのものである。これは、各個々の二次ＡＳＮ ＴＧＳ ＣＳＦにＵＰＤＡＴＥ要求をＩＮ／ＭＮ ＴＧＳ ＣＳＦ内の＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞リソースに送信させることによって遂行される。本要求では、二次ＡＳＮは、その独自のｔｗｉｎｎｉｎｇＣａｐａｂｉｌｉｔｙおよびｄｅｖｉｃｅＬｏｃａｔｉｏｎを含むことができる。ＩＮ／ＭＮ ＴＧＳ ＣＳＦは、次いで、応答内において、ｔｗｉｎｎｉｎｇＧｒｏｕｐＩｄ属性を返信し、二次ＡＳＮを正しいマッチンググループに割り当てることができる（すなわち、属性にマッチングさせることによって）。
・ 所与の二次ノードは、後に、ＵＰＤＡＴＥ要求を送信し、ｔｗｉｎｎｉｎｇＧｒｏｕｐＩｄならびにヌルｔｗｉｎｎｉｎｇＣａｐａｂｉｌｉｔｙおよびｄｅｖｉｃｅＬｏｃａｔｉｏｎ属性を示すことによって、所与のグループから関連付け解除されることができる
２． 連携グループサービスアクティブ化−
ａ． 連携グループが形成された後（上記ステップ１において）、一次ノード（すなわち、単一一次ＡＳＮ ＴＧＳ ＣＳＦ）がＵＰＤＡＴＥ要求をＩＮ／ＭＮ ＴＧＳ ＣＳＦ内の＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞リソースに送信することによって、アクティブにされることができる。要求は、ｔｗｉｎｎｉｎｇＧｒｏｕｐＩｄおよびｔｗｉｎｎｉｎｇＡｃｔｉｖａｔｉｏｎ属性を含むことができる。随意に、一次ノードはまた、ｄｅｖｉｃｅＬｏｃａｔｉｏｎ属性を介して、その独自の現在の場所を示し得る。
・ 同様に、連携グループは、後に、前述に従って、但し、グループの無効化を示すように設定されるｔｗｉｎｎｉｎｇＡｃｔｉｖａｔｉｏｎ属性を伴って、非アクティブにされることができる。
・ アクティブ化／非アクティブ化の両方はまた、ＩＮ／ＭＮ−ＡＥによって行われることができる。
３． 連携グループへのＡＥサービス配信−
ａ． グループが、形成され、アクティブにされると（上記ステップ１および２において）、連携グループサービスは、任意の関心アプリケーションエンティティ（ＡＥ）による使用のための準備ができる。具体的には、サービスに関心があるＡＥは、ＲＥＴＲＩＥＶＥ要求をＩＮ／ＭＮ ＴＧＳ ＣＳＦ内の＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞リソースに送信することができる。要求は、ＡＥが関心がある、ｔｗｉｎｎｉｎｇＣａｐａｂｉｌｉｔｙおよび随意にｄｅｖｉｃｅＬｏｃａｔｉｏｎ属性を含むことができる。応答は、正しいマッチンググループのｔｗｉｎｎｉｎｇＧｒｏｕｐＩｄおよびｔｗｉｎｎｉｎｇＡｃｔｉｖａｔｉｏｎ属性を含むことができる（すなわち、属性をマッチングさせることによって）。
ｂ． 本情報を使用して、ＩＮ／ＭＮ内のＡＥは、任意の着信ＡＥサービスフローを一次ノードからリダイレクトし、代わりに、それを二次ノードのそれぞれに配信（ファンアウト）することができる。本ファンアウトは、ＩＰマルチキャスト等の下層ネットワークサービスエンティティ（ＮＳＥ）能力を使用して遂行されることができる（すなわち、ｔｗｉｎｎｉｎｇＧｒｏｕｐＩｄ属性とＩＰマルチキャストアドレスを相関させる）。全体的サービス配信プロセスは、図２４に示される。
・ 典型的ケースでは、連携させられたサービスは、二次ノードのみにリダイレクトされる。しかしながら、また、連携させられたサービスはまた、二次デバイスにリダイレクトされることに加え、同時に、一次デバイス８０２上にミラーリングされ得ることも実行可能である。
・ 所与の二次デバイスは、複数の独立連携グループに属し得る：
・ この場合、二次デバイスは、上記ステップ１ｃにおいて加えられると、複数のｔｗｉｎｎｉｎｇＧｒｏｕｐＩｄ属性（すなわち、連携グループ毎に１つ）を割り当てられるであろう。
・ したがって、次いで、２つまたはそれを上回る連携させられたＡＥサービスフローが、同時に、メッセージを所与の二次デバイスに配信することを試み得ることも可能である。その場合、連携グループ毎の連携サービス優先順位レベルが、適切な優先順位化がＳＬサーバおよび二次デバイスの両方において行われ得ることを確実にするために使用されるべきである。連携サービス優先順位レベルは、ネットワークアドミニストレータによって割り当てられる属性であるべきである。連携サービス優先順位レベルは、例えば、ｏｎｅＭ２Ｍ規格に定義された既存のｍ２ｍＳｅｒｖｉｃｅＳｕｂｓｃｒｉｐｔｉｏｎＰｒｏｆｉｌｅリソースの新しい属性として割り当てられる。
・ ｃ）連携グループからのサービス発信−同様に、上記ステップ（ａ）からの情報を使用して、ＩＮ／ＭＮ内のＡＥが、サービスメッセージを連携グループのメンバ（すなわち、関連二次ＡＳＮのうちの１つ）から受信する場合、ＡＥは、外部ノード（例えば、連携グループに全く関連しないＡＳＮ）に向けられているかどうかをチェックすることができる。該当する場合、ＩＮまたはＭＮ内のＡＥは、サービスメッセージを転送するが、しかし、サービスメッセージの発信側の識別を変更し、サービスメッセージを実際に送信した二次ノードの代わりに、一次ノード（すなわち、連携グループに関連付けられた単一一次ＡＳＮ）を示すことができる。

本節は、＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞リソース（ＩＮ／ＭＮ ＴＧＳ ＣＳＦ上に位置する）上の動作のために要求される主要なプロシージャを説明する。すなわち、以下である。
・ 連携グループ形成：
ｏ ＣＲＥＡＴＥ要求（一次ノードＡＳＮ ＴＧＳ ＣＳＦによって送信される）
ｏ ＤＥＬＥＴＥ要求（一次ノードＡＳＮ ＴＧＳ ＣＳＦによって送信される）
ｏ ＵＰＤＡＴＥ要求（二次ノードＡＳＮ ＴＧＳ ＣＳＦによって送信される）
・ 連携グループサービスアクティブ化
ｏ ＵＰＤＡＴＥ要求（一次ノードＡＳＮ ＴＧＳ ＣＳＦまたはＩＮ／ＭＮ ＡＥによって送信される）
・ ＡＥサービス配信
ｏ ＲＥＴＲＩＥＶＥ要求（ＩＮ／ＭＮ ＡＥによって送信される）

＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞の作成
本プロシージャは、＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞リソースを作成するために使用されることができる。

（＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞の削除）
本プロシージャは、既存の＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞リソースを削除するために使用されることができる。

（＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞の更新）
本プロシージャは、既存の＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞リソースを更新するために使用されることができる。

（＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞の読み出し）
本プロシージャは、既存の＜ｔｗｉｎｎｉｎｇＧｒｏｕｐ＞リソースのコンテンツを読み出すために使用されることができる。

（ＡＥサービスフローのためのセキュリティ）
ＩＮ／ＭＮノードのアクセス制御ポリシは、ＡＥサービスフローのために、一次デバイス８０２とデバイスのその連携させられた二次グループとの間の相関を可能にするように更新される必要がある。すなわち、連携特徴の追加に起因して、ＩＮ／ＭＮノードは、ここで、ＡＥサービスフローが一次および二次デバイス間で切り替えられ得るにつれて、全てのアクセス制御リスト（ＡＣＬ）プロパティが一次デバイス８０２およびデバイスのその連携させられた二次グループの所与のセットを横断して常に設定されることを確実にしなければならない（例えば、図２４参照）。これは、例えば、連携グループの作成（またはメンバシップの更新）時、動的ＡＣＬデータ構造を設定することによって遂行され得る。

グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースが、ユーザが連携サービスに関連する機能性を制御および／または構成することを補助するために使用されることができる。図２６は、インターフェース２６０２を図示する、略図である。ユーザインターフェース２６０２は、所与のＩｏＴ連携グループに関連付けられた現在の二次デバイスと、また、その関連付けられた一次デバイス８０２とのリストである。情報は、ＩｏＴ連携グループサービス論理をハンドリングする所与のＳＬサーバ１２０２に関連付けられたユーザインターフェースに表示されることができる。ユーザインターフェース２６０２はまた、連携グループを調節または作成するために使用されることができる。図２６における情報は、テキストリストとして表示されるが、しかしながら、また、アイコン、写真等を使用して、描写的に図示され得る。インターフェース２６０２は、以下に説明される図２７Ｃ−Ｄに示されるもの等のディスプレイを使用して生成されることができることを理解されたい。

（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）
本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法を達成するように、単独で、または相互と組み合わせて動作し得る。本明細書で使用されるように、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」という用語は、同義的に使用され得る。

サービス層は、ネットワークサービスアーキテクチャ内の機能層であり得る。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴ等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、例えば、制御層およびトランスポート／アクセス層等の下位リソース層におけるコアネットワークへのインターフェースも提供する。サービス層は、サービス定義、サービス実行時間有効化、ポリシ管理、アクセス制御、およびサービスクラスタ化を含む、（サービス）能力または機能性の複数のカテゴリをサポートする。近年、いくつかの業界規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合に関連付けられる課題に対処するように、Ｍ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、ＣＳＥまたはＳＣＬと称され得る、サービス層によってサポートされる上記の能力もしくは機能性の集合またはセットへのアクセスをアプリケーションおよび／または種々のデバイスに提供することができる。いくつかの例は、種々のアプリケーションによって一般に使用されることができる、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含むが、それらに限定されない。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されるメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションに利用可能にされる。ＣＳＥまたはＳＣＬは、ハードウェアおよび／またはソフトウェアによって実装され得、それらがそのような能力または機能を使用するために、種々のアプリケーションならびに／もしくはデバイス（すなわち、そのような機能エンティティ間の機能インターフェース）にエクスポーズされる（サービス）能力または機能性を提供する、機能エンティティである。

図２７Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、もしくはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノードならびにＩｏＴ／ＷｏＴサービス層等であり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、連携サービス１２０４；位置特定サービス１２０６；一次デバイス８０２；連携させられたデバイス８０４；送信側デバイス８０６；サービス層１０２および８０８；外部デバイス９０２；アプリケーション１０６；ＩＰネットワーキングスタック１０４；ＣＳＥ３０２、３０６；ＡＥ３０４；ＮＳＥ３１０；ＣＳＦ；ＤＭサーバ５０２；ＤＭインターフェース５１０；ＤＭツリー５０８；ＭＯ５０６；デバイス５０４ ６０８；ＬＷＭ２Ｍサーバ６０２、１７０２；ＬＷＭ２Ｍクライアント６０４；ＬＷＭ２Ｍオブジェクト６０６；ＣｏＡＰ７０２；スマートウォッチ１００２；ＬＷＭ２Ｍクライアント／ＴＶ１１０４、１１１０、１１１２、１１１４；サービス層サーバ１２０２；二次デバイス１２０８、１２１０、１２１２；ＷｉＦｉ１７０６；セキュリティコントローラ２００２；連携グループサービスＣＳＦ２３０２；ならびにインターフェース２６０２等のインターフェースを生成する論理エンティティ等の機能性および論理エンティティを含むことができる。

図２７Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ等）または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、多重アクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

図２７Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャと、フィールドドメインを含み得る。インフラストラクチャドメインとは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインとは、通常は、Ｍ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、種々の異なるネットワークノード（例えば、サーバ、ゲートウェイ、デバイス等）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信回路を使用して、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍ端末デバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０または他のＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍ端末デバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍ端末デバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍ端末デバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。ホームネットワーク

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および気象モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、保健および健康モニタ、照明、サーモスタット、電化製品、ガレージドア、および他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

図２７Ｂを参照すると、フィールドドメイン内の図示されたＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、連携サービス１２０４；位置特定サービス１２０６；一次デバイス８０２；連携させられたデバイス８０４；送信側デバイス８０６；サービス層１０２および８０８；外部デバイス９０２；アプリケーション１０６；ＩＰネットワーキングスタック１０４；ＣＳＥ３０２、３０６；ＡＥ３０４；ＮＳＥ３１０；ＣＳＦ；ＤＭサーバ５０２；ＤＭインターフェース５１０；ＤＭツリー５０８；ＭＯ５０６；デバイス５０４ ６０８；ＬＷＭ２Ｍサーバ６０２、１７０２；ＬＷＭ２Ｍクライアント６０４；ＬＷＭ２Ｍオブジェクト６０６；ＣｏＡＰ７０２；スマートウォッチ１００２；ＬＷＭ２Ｍクライアント／ＴＶ１１０４、１１１０、１１１２、１１１４；サービス層サーバ１２０２；二次デバイス１２０８、１２１０、１２１２；ＷｉＦｉ１７０６；セキュリティコントローラ２００２；連携グループサービスＣＳＦ２３０２；ならびにインターフェース２６０２等のインターフェースを生成する論理エンティティ等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図２７Ｃおよび２７Ｄに図示されるデバイスを含む、１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。

図示されたＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍデバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／記憶ファーム等）等を備え得る、ネットワークの１つ以上のノードによって実装され得る。

また、図２７Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができる、サービス配信能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、ネットワーク１２を通して通信することも可能にする。

本願の方法は、サービス層２２および２２’の一部として実装され得る。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍは両方とも、本願の接続方法を含有し得る、サービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含み得、また、他の開示されるシステムおよび方法と併せて使用され得る。

一実施形態では、連携サービス１２０４；位置特定サービス１２０６；一次デバイス８０２；連携させられたデバイス８０４；送信側デバイス８０６；サービス層１０２および８０８；外部デバイス９０２；アプリケーション１０６；ＩＰネットワーキングスタック１０４；ＣＳＥ３０２、３０６；ＡＥ３０４；ＮＳＥ３１０；ＣＳＦ；ＤＭサーバ５０２；ＤＭインターフェース５１０；ＤＭツリー５０８；ＭＯ５０６；デバイス５０４ ６０８；ＬＷＭ２Ｍサーバ６０２、１７０２；ＬＷＭ２Ｍクライアント６０４；ＬＷＭ２Ｍオブジェクト６０６；ＣｏＡＰ７０２；スマートウォッチ１００２；ＬＷＭ２Ｍクライアント／ＴＶ１１０４、１１１０、１１１２、１１１４；サービス層サーバ１２０２；二次デバイス１２０８、１２１０、１２１２；ＷｉＦｉ１７０６；セキュリティコントローラ２００２；連携グループサービスＣＳＦ２３０２；ならびにインターフェース２６０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、図２７Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、連携サービス１２０４；位置特定サービス１２０６；一次デバイス８０２；連携させられたデバイス８０４；送信側デバイス８０６；サービス層１０２および８０８；外部デバイス９０２；アプリケーション１０６；ＩＰネットワーキングスタック１０４；ＣＳＥ３０２、３０６；ＡＥ３０４；ＮＳＥ３１０；ＣＳＦ；ＤＭサーバ５０２；ＤＭインターフェース５１０；ＤＭツリー５０８；ＭＯ５０６；デバイス５０４ ６０８；ＬＷＭ２Ｍサーバ６０２、１７０２；ＬＷＭ２Ｍクライアント６０４；ＬＷＭ２Ｍオブジェクト６０６；ＣｏＡＰ７０２；スマートウォッチ１００２；ＬＷＭ２Ｍクライアント／ＴＶ１１０４、１１１０、１１１２、１１１４；サービス層サーバ１２０２；二次デバイス１２０８、１２１０、１２１２；ＷｉＦｉ１７０６；セキュリティコントローラ２００２；連携グループサービスＣＳＦ２３０２；ならびにインターフェース２６０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、本システムのデバイス、ゲートウェイ、サーバ、および他のノードを横断して起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャは両方とも、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで、もしくはネットワークのある他のノードで具現化されるかどうかにかかわらず、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピュータデバイスまたはノードを含む、ネットワーク内の１つ以上の独立型ノード上で、もしくは１つ以上の既存のノードの一部としてのいずれかで実行する、論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として実装され得る。例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図２７Ｃまたは図２７Ｄで図示される一般アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で起動するソフトウェアの形態で実装され得る。

さらに、連携サービス１２０４；位置特定サービス１２０６；一次デバイス８０２；連携させられたデバイス８０４；送信側デバイス８０６；サービス層１０２および８０８；外部デバイス９０２；アプリケーション１０６；ＩＰネットワーキングスタック１０４；ＣＳＥ３０２、３０６；ＡＥ３０４；ＮＳＥ３１０；ＣＳＦ；ＤＭサーバ５０２；ＤＭインターフェース５１０；ＤＭツリー５０８；ＭＯ５０６；デバイス５０４ ６０８；ＬＷＭ２Ｍサーバ６０２、１７０２；ＬＷＭ２Ｍクライアント６０４；ＬＷＭ２Ｍオブジェクト６０６；ＣｏＡＰ７０２；スマートウォッチ１００２；ＬＷＭ２Ｍクライアント／ＴＶ１１０４、１１１０、１１１２、１１１４；サービス層サーバ１２０２；二次デバイス１２０８、１２１０、１２１２；ＷｉＦｉ１７０６；セキュリティコントローラ２００２；連携グループサービスＣＳＦ２３０２；ならびにインターフェース２６０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

図２７Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、連携サービス１２０４；位置特定サービス１２０６；一次デバイス８０２；連携させられたデバイス８０４；送信側デバイス８０６；サービス層１０２および８０８；外部デバイス９０２；アプリケーション１０６；ＩＰネットワーキングスタック１０４；ＣＳＥ３０２、３０６；ＡＥ３０４；ＮＳＥ３１０；ＣＳＦ；ＤＭサーバ５０２；ＤＭインターフェース５１０；ＤＭツリー５０８；ＭＯ５０６；デバイス５０４ ６０８；ＬＷＭ２Ｍサーバ６０２、１７０２；ＬＷＭ２Ｍクライアント６０４；ＬＷＭ２Ｍオブジェクト６０６；ＣｏＡＰ７０２；スマートウォッチ１００２；ＬＷＭ２Ｍクライアント／ＴＶ１１０４、１１１０、１１１２、１１１４；サービス層サーバ１２０２；二次デバイス１２０８、１２１０、１２１２；ＷｉＦｉ１７０６；セキュリティコントローラ２００２；連携グループサービスＣＳＦ２３０２；ならびにインターフェース２６０２等のインターフェースを生成する論理エンティティ等の論理エンティティを実行する、または含むことができる。デバイス３０は、図２７Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部または非Ｍ２Ｍネットワークの一部であることができる。図２７Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。本ノードは、本明細書に説明される機能性を実装する、ノードであり得る。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されたコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする、任意の他の機能性を果たし得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動し得る。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を実施し得る。

図２７Ｃに示されるように、プロセッサ２３は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に結合される。プロセッサ２３は、コンピュータ実行可能命令の実行を通して、それが接続されるネットワークを介してノード３０を他のノードと通信させるために、通信回路を制御し得る。具体的には、プロセッサ３２は、本明細書および請求項に説明される伝送および受信ステップを行うために、通信回路を制御し得る。図２７Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップ内にともに統合され得ることが理解されるであろう。

伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、他のＭ２Ｍノードに信号を伝送する、またはそこから信号を受信するように構成され得る。例えば、ある実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送／受信要素３６は、無線もしくは有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図２７Ｃで描写されているが、Ｍ２Ｍノード３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、Ｍ２Ｍノード３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、Ｍ２Ｍノード３０は、無線信号を伝送および受信するための２つまたはそれを上回る伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、Ｍ２Ｍノード３０は、マルチモード能力を有し得る。したがって、送受信機３４は、Ｍ２Ｍノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ３２は、上で説明されるように、セッションコンテキストをそのメモリの中に記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたは自宅コンピュータ上等のＭ２Ｍノード３０上に物理的に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、ディスプレイ上の視覚的指示を制御し、システムのステータスを決定させる、または入力をユーザから得る、もしくは能力または設定についての情報をユーザに表示するように構成され得る。ディスプレイ上に示され得る、グラフィカルユーザインターフェースは、ユーザが本明細書に説明される機能性を双方向に行うことを可能にするように、ＡＰＩの上で層化され得る。

プロセッサ３２は、電源４８から電力を受電してもよく、Ｍ２Ｍノード３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、Ｍ２Ｍノード３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

プロセッサ３２はまた、Ｍ２Ｍノード３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成される、ＧＰＳチップセット５０に結合され得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続性を提供する、１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る、他の周辺機器５２に結合され得る。例えば、周辺機器５２は、加速度計、バイオメトリック（例えば、指紋）センサ等の種々のセンサ、ｅ−コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポートまたは他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

ノード３０は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の他の装置もしくはデバイスで具現化され得る。ノード３０は、周辺機器５２のうちの１つを備え得る相互接続インターフェース等の１つ以上の相互接続インターフェースを介して、そのような装置もしくはデバイスの他のコンポーネント、モジュール、またはシステムに接続し得る。代替として、ノード３０は、センサ、消費者電子機器、スマートウォッチまたはスマート衣類等のウェアラブルデバイス、医療またはｅ−ヘルスデバイス、ロボット、産業機器、ドローン、車、トラック、電車、または飛行機等の車両等の装置もしくはデバイスを備え得る。

図２７Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のノード等のＭ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る、例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備えてもよく、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。コンピューティングシステム９０は、連携サービス１２０４；位置特定サービス１２０６；一次デバイス８０２；連携させられたデバイス８０４；送信側デバイス８０６；サービス層１０２および８０８；外部デバイス９０２；アプリケーション１０６；ＩＰネットワーキングスタック１０４；ＣＳＥ３０２、３０６；ＡＥ３０４；ＮＳＥ３１０；ＣＳＦ；ＤＭサーバ５０２；ＤＭインターフェース５１０；ＤＭツリー５０８；ＭＯ５０６；デバイス５０４ ６０８；ＬＷＭ２Ｍサーバ６０２、１７０２；ＬＷＭ２Ｍクライアント６０４；ＬＷＭ２Ｍオブジェクト６０６；ＣｏＡＰ７０２；スマートウォッチ１００２；ＬＷＭ２Ｍクライアント／ＴＶ１１０４、１１１０、１１１２、１１１４；サービス層サーバ１２０２；二次デバイス１２０８、１２１０、１２１２；ＷｉＦｉ１７０６；セキュリティコントローラ２００２；連携グループサービスＣＳＦ２３０２；ならびにインターフェース２６０２等のインターフェースを生成する論理エンティティ等の論理エンティティを実行する、または含むことができる。コンピューティングシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む、任意の他のノードであることができる。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの公知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たす、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等のＥ２Ｅ Ｍ２Ｍサービス層セッションのための開示されたシステムおよび方法に関連するデータを受信、生成、ならびに処理し得る。

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、ならびにそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、インタラプトを送信するため、およびシステムバスを動作させるための制御ラインとを含む。そのようなシステムバス８０の例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。

システムバス８０に結合されるメモリは、ランダムアクセスメモリ（ＲＡＭ）８２と、読み取り専用メモリ（ＲＯＭ）９３とを含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正されることができない、記憶されたデータを含む。ＲＡＭ８２内に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られる、もしくは変更されることができる。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離する、メモリ保護機能を提供し得る。したがって、第１のモードで起動するプログラムは、その独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を通信する責任がある、周辺機器コントローラ８３を含有し得る。

ディスプレイコントローラ９６によって制御される、ディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される、電子コンポーネントを含む。

さらに、コンピューティングシステム９０は、コンピューティングシステム９０がネットワークの他のノードと通信することを可能にするように、図２７Ａおよび図２７Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、例えば、ネットワークアダプタ９７等の通信回路を含有し得る。

ユーザ機器（ＵＥ）は、通信するためにエンドユーザによって使用される任意のデバイスであることができる。これは、ハンドヘルド電話、モバイルブロードバンドアダプタを装備するラップトップコンピュータ、または任意の他のデバイスであることができる。例えば、ＵＥは、図２７Ａ−ＢのＭ２Ｍ端末デバイス１８または図２７Ｃのデバイス３０として実装されることができる。

本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、Ｍ２Ｍネットワークのノード等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施ならびに／もしくは実装することが理解される。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、上で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。連携サービス１２０４；位置特定サービス１２０６；一次デバイス８０２；連携させられたデバイス８０４；送信側デバイス８０６；サービス層１０２および８０８；外部デバイス９０２；アプリケーション１０６；ＩＰネットワーキングスタック１０４；ＣＳＥ３０２、３０６；ＡＥ３０４；ＮＳＥ３１０；ＣＳＦ；ＤＭサーバ５０２；ＤＭインターフェース５１０；ＤＭツリー５０８；ＭＯ５０６；デバイス５０４ ６０８；ＬＷＭ２Ｍサーバ６０２、１７０２；ＬＷＭ２Ｍクライアント６０４；ＬＷＭ２Ｍオブジェクト６０６；ＣｏＡＰ７０２；スマートウォッチ１００２；ＬＷＭ２Ｍクライアント／ＴＶ１１０４、１１１０、１１１２、１１１４；サービス層サーバ１２０２；二次デバイス１２０８、１２１０、１２１２；ＷｉＦｉ１７０６；セキュリティコントローラ２００２；連携グループサービスＣＳＦ２３０２；ならびにインターフェース２６０２等のインターフェースを生成する論理エンティティ等の論理エンティティは、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令の形態で具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理）方法もしくは技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用されることができ、かつコンピュータによってアクセスされることができる、任意の他の有形もしくは物理的媒体を含むが、それらに限定されない。

図に図示されるような本開示の主題の好ましい実施形態を説明する際に、具体的用語が、明確にするために採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図せず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用することと、任意の組み込まれた方法を行うこととを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の要素を含む場合に、請求項の範囲内であることを意図している。

Claims (23)

1. 装置による使用のための方法であって、前記装置は、プロセッサと、メモリとを備え、前記装置は、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、サービス層を実装し、
   一次デバイスに関連付けられた連携グループを設定することであって、前記設定することは、１つ以上のデバイスをメンバとして前記連携グループに割り当てることと、前記１つ以上のデバイスの１つ以上のインターネットプロトコル（ＩＰ）アドレスを前記連携グループに関連付けることとを含む、ことと、
   前記一次デバイスのためのメッセージを受信することと、
   前記メッセージを前記連携グループの前記１つ以上のデバイスの１つ以上のＩＰアドレスにリダイレクトすることと
   を含む方法の機能を実施することを前記装置に行わせる、方法。
2. 前記１つ以上のインターネットプロトコル（ＩＰ）アドレスは、ＩＰマルチキャストアドレスであり、前記リダイレクトすることは、前記メッセージを前記ＩＰマルチキャストアドレスに送信することを含む、請求項１に記載の方法。
3. 前記連携グループは、複数のモノのインターネット（ＩｏＴ）デバイスを含む、請求項１に記載の方法
4. 前記連携グループのメンバの場所をチェックすることをさらに含む、請求項１に記載の方法。
5. リダイレクトする前に前記連携グループをアクティブにすることをさらに含む、請求項１に記載の方法。
6. 前記アクティブにすることは、サーバ論理によって行われる、請求項１に記載の方法。
7. 前記アクティブにすることは、一次デバイスにおけるユーザによって行われる、請求項１に記載の方法。
8. 通信ネットワーク内で使用される装置であって、前記装置は、プロセッサと、メモリとを備え、前記装置は、前記装置のメモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記装置のプロセッサによって実行されると、
   サービス層を実装し、
   一次デバイスに関連付けられた連携グループを設定することであって、前記設定することは、１つ以上のデバイスをメンバとして前記連携グループに割り当てることと、前記１つ以上のデバイスの１つ以上のインターネットプロトコル（ＩＰ）アドレスを前記連携グループに関連付けることとを含む、ことと、
   前記一次デバイスのためのメッセージを受信することと、
   前記メッセージを前記連携グループの前記１つ以上のデバイスの１つ以上のＩＰアドレスにリダイレクトすることと
   を前記装置に行わせる、装置。
9. 前記１つ以上のインターネットプロトコル（ＩＰ）アドレスは、ＩＰマルチキャストアドレスであり、前記装置は、前記メッセージを前記ＩＰマルチキャストアドレスに送信する、請求項８に記載の装置。
10. 前記連携グループは、複数のモノのインターネット（ＩｏＴ）デバイスを含む、請求項８に記載の装置
11. 前記連携グループのメンバの場所をチェックすることをさらに含む、請求項８に記載の装置。
12. 前記装置が前記メッセージをリダイレクトする前に前記連携グループをアクティブにすることをさらに含む、請求項８に記載の装置。
13. 前記アクティブにすることは、サーバ論理によって行われる、請求項８に記載の装置。
14. 前記アクティブにすることは、一次デバイスにおけるユーザによって行われる、請求項８に記載の装置。
15. 装置による使用のための方法であって、前記装置は、プロセッサと、メモリとを備え、前記装置は、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
    連携モードおよび連携グループに関連付けられた一次デバイスのためのメッセージを受信することと、
    前記連携モードが場所依存であるかどうかをチェックすることと、
    前記連携グループが場所依存である場合、前記一次デバイスが特定の場所にあるかどうかをチェックすることと、
    前記一次デバイスが前記特定の場所にある場合、前記連携モードがアクティブにされているかどうかをチェックすることと、
    前記連携モードがアクティブにされている場合、前記メッセージを前記連携グループに関連付けられた少なくとも１つのインターネットプロトコル（ＩＰ）アドレスに送信することと
    を含む方法の機能を実施する、方法。
16. 前記１つ以上のインターネットプロトコル（ＩＰ）アドレスは、ＩＰマルチキャストアドレスであり、前記メッセージは、前記ＩＰマルチキャストアドレスに送信される、請求項１５に記載の方法。
17. 前記連携グループは、複数のモノのインターネット（ＩｏＴ）デバイスを含む、請求項１５に記載の方法。
18. 前記メッセージは、サーバ論理によって開始される、請求項１５に記載の方法。
19. 前記メッセージは、外部デバイスから送信される、請求項１５に記載の方法。
20. 前記連携グループは、一次デバイスに関連付けられて設定され、設定することは、１つ以上のデバイスをメンバとして前記連携グループに割り当てることと、前記１つ以上のデバイスの１つ以上のインターネットプロトコル（ＩＰ）アドレスを前記連携グループに関連付けることとを含む、請求項１５に記載の方法。
21. 装置による使用のための方法であって、前記装置は、プロセッサと、メモリとを備え、前記装置は、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
    サービス層サーバから、ＩＰマルチキャストグループおよび連携グループに加わるためのトリガを受信することであって、前記トリガは、前記ＩＰマルチキャストグループおよび前記連携グループを示す、ことと、
    前記ＩＰマルチキャストグループおよび前記連携グループに加わることと
    を含む方法の機能を実施する、方法。
22. 装置による使用のための方法であって、前記装置は、プロセッサと、メモリとを備え、前記装置は、前記メモリ内に記憶されたコンピュータ実行可能命令をさらに含み、前記命令は、前記プロセッサによって実行されると、
    トリガ条件に基づいて、連携グループのアクティブ化／非アクティブ化をトリガすることと、
    アクティブ化／非アクティブ化メッセージを前記連携グループ内のデバイスに送信することと
    を含む方法の機能を実施する、方法。
23. 前記トリガ条件は、時刻である、請求項２２に記載の方法。