JP6434611B2 - デバイス管理プロトコルを用いるインターワーキングライトウェイトマシンツーマシンプロトコル - Google Patents

Description

（関連出願の相互参照）
本願は、２０１４年７月２２日に出願された米国仮特許出願第６２／０２７，３９５号の利益を主張するものであり、該仮出願の開示は、あたかもその全体が本明細書中に開示されているかのように本明細書中に援用される。

オープンモバイルアライアンス（ＯＭＡ）は、ＯＭＡデバイス管理（ＤＭ）プロトコル、ＯＭＡゲートウェイ管理オブジェクト（ＧｗＭＯ）プロトコル、およびＯＭＡライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）プロトコルを含む、ネットワーク内のデバイス管理のためのいくつかのプロトコルが開発している。ＯＭＡ ＤＭプロトコルは、ネットワーク内のモバイルデバイス等の独立型デバイスを管理するために使用されてもよい。ＯＭＡ ＧｗＭＯプロトコルは、ゲートウェイの背後のエンドデバイスを管理するために使用されてもよく、ＯＭＡ ＬＷＭ２Ｍは、制約付きマシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）デバイスを管理するために使用されてもよい。

ＯＭＡＤＭプロトコルの一般的アーキテクチャは、図１に示される。ＤＭサーバ１０２（管理サーバとも称される）は、コマンドをそれらを管理するデバイスまたはゲートウェイ（デバイスまたはゲートウェイ１０４等）上で起動するＤＭクライアントに送信する、マスタエンティティである。ＤＭクライアントは、デバイスまたはゲートウェイ上で起動し、ＤＭサーバ１０２との通信を提供する、エンティティである。これは、管理クライアントとも称される。ＤＭセッションは、ＤＭサーバとＤＭクライアントとの間に作成されたＯＭＡＤＭプロトコル管理セッションである。ＤＭコマンドは、２つのエンティティ間の本セッション内で送信される。

コマンドは、デバイス上の管理オブジェクト（ＭＯ）にともに論理的にグループ化される、ノード上で動作する。ＭＯは、集合的に、ソフトウェアダウンロード（ＳＣＯＭＯ）またはデバイス情報（ＤｅｖＩｎｆｏ ＭＯ）等のいくつかの管理動作を提供する、ＤＭノードの集合体である。ＭＯは、図１の１０６に示される、ＤＭツリーまたは管理ツリーと呼ばれる階層ツリー構造に編成される。例示的ＤＭツリーは、図２に図示される。

ＤＭノードは、管理オブジェクトまたはＤＭツリー内の単一要素である。これは、内部ノードまたはリーフノードであることができる。内部ノードは、子ノードを有し、リーフノードは、子ノードを有さず、ある値を含有する、または実行コマンドによってオンに動作されることができる。

ＯＭＡ ＤＭプロトコルでは、各ＭＯは、ＯＭＡデバイス記述フレームワーク（ＤＤＦ）によって記述される。本ＤＤＦは、ＤＭサーバによって読み取られ、管理オブジェクト内に含有される全ノードを完全に記述する、拡張マークアップ言語（ＸＭＬ）ドキュメントであって、各ノード上で実施されることができるアクションを記述する。ＤＤＦに見出される要素は、リーフノードと関連付けられたノード名、ノードプロパティ、および値である。ノードプロパティは、記述フレームワークプロパティ（ＤＦプロパティ）を含む。これらのＤＦプロパティは、各ノードについてのメタデータを含有する。ＤＦプロパティは、ＭＯの指定の際に定義されるプロパティであって、実施例として、ＡｃｃｅｓｓＴｙｐｅ、ＤｅｆａｕｌｔＶａｌｕｅ、Ｄｅｓｃｒｉｐｔｉｏｎ、ＤＦＦｏｒｍａｔ、Ｏｃｃｕｒｒｅｎｃｅ、Ｓｃｏｐｅ、ＤＦＴｉｔｌｅ、ＤＦＴｙｐｅ、およびＣａｓｅＳｅｎｓｅが挙げられる。加えて、ランタイムプロパティ（ＲＴプロパティ）は、ランタイム時に生成され、Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌリスト（ＡＣＬ）、Ｆｏｒｍａｔ、Ｎａｍｅ、Ｓｉｚｅ、Ｔｉｔｌｅ、Ｔｉｍｅｓｔａｍｐ、Ｔｙｐｅ、およびＶｅｒｓｉｏｎ Ｎｕｍｂｅｒ等のプロパティを含む。

図３は、ＤＤＦドキュメントの単純実施例を示す。ＤＦプロパティの詳細は、簡潔にするためだけに意図的に除外されていることに留意されたい。本実施例では、ＤＤＦは、ＵＲＩ「Ｖｅｎｄｏｒ／ＩＳＰ／ＧＷＩｎｆｏ」を用いて内部ノードを記述し、値「ｇｗ．ｙｙｙ．ｓｅ」を含有する「ＧＷＮａｍｅ」と称される子ノードを有する。「Ｖｅｎｄｏｒ」、「ＩＳＰ」、および「ＧＷＩｎｆｏ」は、内部ノードの名称である一方、「ＧＷＮａｍｅ」は、リーフノードの名称である。ＤＤＦファイルは、管理オブジェクトのフォーマットおよび各ノードがとり得る可能性として考えられる値を示す。クライアントおよび／またはサーバは、値を各ノードに割り当てることに責任がある。ＤＤＦファイルは、ＤＭサーバおよびＤＭクライアントにプロビジョニングされ、対応するＭＯのエンドツーエンドサポートを有効にする。典型的には、これは、ＤＭプロトコルの通常動作からアウトオブバンドで実施される。

図４は、ＧｗＭＯプロトコルのアーキテクチャを図示する。ＧｗＭＯプロトコルは、デバイス管理機能性を、直接ＤＭサーバ４０６によって到達可能ではない、エンドデバイスに拡張することに役立つ、中間ＯＭＡ ＤＭゲートウェイ４０２を定義する。エンドデバイス４０４ａ、４０４ｂ、および４０４ｃ等のエンドデバイスは、ＯＭＡ ＤＭゲートウェイ４０２に通信し、これは、次いで、ＤＭサーバ４０６に新しいエンドデバイスをアラートする。デバイス管理コマンドは、ＤＭサーバ４０６からＯＭＡ ＤＭゲートウェイ４０２に送信され、これは、次いで、いくつかの異なる動作モードのうちの１つに従って、コマンドをエンドデバイスに配信する。３つのモードは、トランスペアレント、プロキシ、および適応モードと定義される。トランスペアレントおよびプロキシモードの両方では、エンドデバイスは、ネイティブＯＭＡ ＤＭコマンドを理解する一方、適応モードは、ＯＭＡ ＤＭプロトコルから非ＯＭＡ ＤＭプロトコルへの変換を要求する。

ＯＭＡ ＤＭゲートウェイ４０２の動作の中心は、ＧｗＭＯコンポーネント（図示せず）である。本エンティティは、デバイスインベントリ、ゲートウェイ構成、ファンアウト、イメージインベントリ、およびエンドデバイストリガの５つのＭＯを提供し、ゲートウェイの背後のエンドデバイスを管理する。これらのＭＯの機能性は、ＯＭＡ ＤＭプロトコルと同一メッセージフォーマットを再使用し、したがって、ＯＭＡ ＤＭシステムとシームレスに機能するように設計される。ＧｗＭＯコンポーネントの定義は、ＯＭＡが、その範囲を拡張し、そのうちのいくつかが既存のＯＭＡ ＤＭデバイスより制約され得る、非ＯＭＡ ＤＭデバイスをサポートすることを可能にする。

ＬＷＭ２Ｍプロトコルは、Ｍ２Ｍ通信ネットワークの増加する人気に対処するために、そのようなネットワーク内でＭ２Ｍデバイスを管理するための手段として開発された。ＬＷＭ２Ｍは、ＯＭＡ ＤＭと同一クライアントサーバアーキテクチャに基づくが、Ｍ２Ｍ通信ネットワーク内で見出されるもの等の制約付きデバイスにより適用可能である、より単純かつより平坦なリソースツリーを伴う、異なる通信プロトコルを使用する。特に、ＬＷＭ２Ｍは、制約付きアプリケーションプロトコル（ＣｏＡＰ）を使用し、そのリソースツリーは、より少ない階層レベルを伴う平坦構造に編成された下層リソースを伴う、オブジェクトとして定義される。ＬＷＭ２Ｍにおけるオブジェクトおよびリソースの定義は、ＯＭＡ ＤＭプロトコルにおけるＭＯおよびノードのものに類似する。図５は、ＬＷＭ２Ｍアーキテクチャを図示する。示されるように、ＬＷＭ２Ｍサーバ５０２は、ＯＭＡ ＬＷＭ２Ｍプロトコル内のマスタエンティティである。これは、ＬＷＭ２Ｍクライアント（例えば、ＬＷＭ２Ｍクライアント５０４）に通信し、デバイス管理および情報報告能力を提供する。ＬＷＭ２Ｍクライアントは、デバイス管理および情報報告能力をＬＷＭ２Ｍサーバに提供する、Ｍ２ＭまたはＩｏＴシステム内のＭ２Ｍデバイス５０６等の制約付きデバイス上で起動する。

デバイス管理のサポートに加え、ＬＷＭ２Ｍプロトコルはまた、制約付きデバイスによって提供されるサービス実施可能要件もサポートする。制約付きデバイスは、大部分は、その特定のアプリケーションのためのデータ測定を提供するため、情報報告は、プロトコル内で規定される主要サービス実施可能要件のうちの１つである。したがって、オブジェクトの設計は、デバイス管理および情報報告をサポートするであろう、リソースの提供に焦点を当てる。

本明細書に開示される実施形態は、ＬＷＭ２Ｍとインターワーキングすることも可能にしながら、追加機能性を提供する、既存のＯＭＡ ＤＭおよびＧｗＭＯプロトコルの拡張を提供する。本願の一側面によると、新しいＤＤＦ ＭＯが、作成され、ＬＷＭ２Ｍオブジェクト定義をＤＭサーバおよびゲートウェイに追加することを有効にする。本ＭＯは、ＤＭサーバ／ゲートウェイが、ＬＷＭ２Ｍオブジェクト定義等の新しく定義されたＭＯを容認することを可能にする。別の側面では、新しいプロシージャは、ＤＤＦドキュメントを新しく作成されたＤＤＦ ＭＯに登録するために定義される。別の側面は、新しい登録インターフェースをＧｗＭＯプロトコル内に追加し、ＬＷＭ２Ｍサーバが、エンドデバイスをＤＭゲートウェイに登録することを可能にすることを伴う。さらに別の側面は、プロトコル変換機構を導入し、ＯＭＡ ＤＭおよび／またはＧｗＭＯからＬＷＭ２Ｍ等の非ＲＥＳＴｆｕｌからＲＥＳＴｆｕｌプロトコル間のギャップをブリッジする。

本概要は、以下の発明を実施するための形態にさらに説明される簡略化された形態における一連の概念を紹介するために提供される。本概要は、請求される主題の重要な特徴または不可欠な特徴を識別することを意図するものではなく、請求される主題の範囲を限定するために使用されることを意図するものでもない。さらに、請求される主題は、本開示の任意の部分に記載される任意または全ての不利点を解決する制限に限定されない。
本明細書は、例えば、以下を提供する。
（項目１）
プロセッサおよびメモリを備える、デバイス管理サーバであって、上記メモリは、上記プロセッサによって実行されると、上記デバイス管理サーバに、
上記デバイス管理サーバのメモリ内に、上記デバイス管理サーバによってサポートされる複数の他の管理オブジェクト毎に、デバイス記述フレームワークドキュメントのコピーをそのような他の管理オブジェクトのために記憶する、デバイス記述フレームワーク管理オブジェクトを維持することと、
新しい管理オブジェクトを上記デバイス管理サーバに登録するための要求を受信することであって、上記要求は、上記新しい管理オブジェクトのためのデバイス記述フレームワークドキュメントを含む、ことと、
上記要求に応答して、上記新しい管理オブジェクトのためのデバイス記述フレームワークドキュメントを上記デバイス管理サーバによって維持される上記デバイス記述フレームワーク管理オブジェクトに追加することと
を行わせるコンピュータ実行可能命令を記憶する、デバイス管理サーバ。
（項目２）
上記コンピュータ実行可能命令はさらに、上記デバイス管理サーバに、上記新しい管理オブジェクトのデバイス記述フレームワークドキュメントのフォーマットの妥当性を確認することを、それを上記デバイス記述フレームワーク管理オブジェクトに追加することに先立って行わせる、項目１に記載のデバイス管理サーバ。
（項目３）
上記デバイス記述フレームワーク管理オブジェクトは、上記デバイス管理サーバによってサポートされる上記他の管理オブジェクト毎に、上記他の管理オブジェクトについての情報を含有するノードのセットを備え、上記ノードのうちの１つは、上記デバイス記述フレームワークドキュメントのコピーをそのような他の管理オブジェクトのために保持する、項目１に記載のデバイス管理サーバ。
（項目４）
上記新しい管理オブジェクトのためのデバイス記述フレームワークドキュメントを上記デバイス記述フレームワーク管理オブジェクトに追加することは、
上記デバイス記述フレームワーク管理オブジェクト内に、上記新しい管理オブジェクトのためのノードのセットを作成することと、
上記新しい管理オブジェクトのためのドキュメント記述フレームワークドキュメントのコピーを上記セットの１つのノード内に記憶することと、
を含む、項目１に記載のデバイス管理サーバ。
（項目５）
上記デバイス記述フレームワーク管理オブジェクト内の相互管理オブジェクトのためのノードのセットはさらに、
上記他の管理オブジェクトの名称を含有する、ノードと、
上記他の管理オブジェクトのバージョンのインジケーションを含有する、ノードと、
上記他の管理オブジェクトを識別するために使用され得る、オブジェクト識別子（ＩＤ）を含有する、ノードと、
上記他の管理オブジェクトのためのドキュメント記述フレームワークドキュメントの名称を含有する、ノードと、
上記他の管理オブジェクトのためのドキュメント記述フレームワークドキュメントと関連付けられたユニフォームリソースロケータ（ｕｒｌ）を含有する、ノードと、
上記他の管理オブジェクトのステータスのインジケーションを含有する、ノードと、
上記他の管理オブジェクト上で実施され得る、動作を表す、複数のノードであって、上記動作は、アップロード、アップロードアクティブ化、アクティブ化、および非アクティブ化動作のうちの１つまたはそれを上回るものを含む、ノードと、
のうちの１つまたはそれを上回るものを含む、項目１に記載のデバイス管理サーバ。
（項目６）
ゲートウェイプロセッサおよびメモリを備える、デバイス管理サーバであって、上記メモリは、上記プロセッサによって実行されると、上記デバイス管理サーバに、
上記ゲートウェイデバイス管理サーバのメモリ内に、上記ゲートウェイデバイス管理サーバによってサポートされる複数の他の管理オブジェクト毎に、デバイス記述フレームワークドキュメントのコピーをそのような他の管理オブジェクトのために記憶する、デバイス記述フレームワーク管理オブジェクトを維持することと、
新しい管理オブジェクトを上記ゲートウェイデバイス管理サーバに登録するための要求を受信することであって、上記新しい管理オブジェクトは、ライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）プロトコルに従って動作するサーバによってサポートされるオブジェクトを表す、ことと、
上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを表す、デバイス記述フレームワークドキュメントを受信することと、
上記要求に応答して、上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを上記ゲートウェイデバイス管理サーバによって維持されるデバイス記述フレームワーク管理オブジェクトに追加することと
を行わせるコンピュータ実行可能命令を記憶する、デバイス管理サーバ。
（項目７）
上記コンピュータ実行可能命令はさらに、上記ゲートウェイデバイス管理サーバに、
上記ＬＷＭ２Ｍサーバに、上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを上記ＬＷＭ２Ｍサーバから要求するための要求を伝送することと、
上記要求に応答して、上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを受信することと
を行わせる、項目６に記載のゲートウェイデバイス管理サーバ。
（項目８）
上記コンピュータ実行可能命令はさらに、上記ゲートウェイデバイス管理サーバに、
上記ＬＷＭ２Ｍサーバから、上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを登録するための要求を受信することであって、上記要求は、上記ＬＷＭ２Ｍプロトコルに従って形成される、ことと、
上記ＬＷＭ２Ｍサーバから受信された要求を上記新しい管理オブジェクトを上記ゲートウェイデバイス管理サーバに登録する要求に変換することと
を行わせる、項目６に記載のゲートウェイデバイス管理サーバ。
（項目９）
上記コンピュータ実行可能命令はさらに、上記ゲートウェイデバイス管理サーバに、ＤＤＦ登録アラートメッセージをデバイス管理（ＤＭ）サーバに送信させ、それへの登録のために、上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを表すデバイス記述フレームワークドキュメントを上記ＤＭサーバに提供させる、項目６に記載のゲートウェイデバイス管理サーバ。
（項目１０）
プロセッサおよびメモリを備える、デバイス管理（ＤＭ）サーバであって、上記メモリは、上記プロセッサによって実行されると、上記デバイス管理サーバに、
上記ＤＭサーバのメモリ内に、上記ＤＭサーバによってサポートされる複数の他の管理オブジェクト毎に、デバイス記述フレームワークドキュメントのコピーをそのような他の管理オブジェクトのために記憶する、デバイス記述フレームワーク管理オブジェクトを維持することと、
新しい管理オブジェクトを上記ＤＭサーバに登録するための要求を受信することであって、上記新しい管理オブジェクトは、ライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）プロトコルに従って動作するサーバによってサポートされるオブジェクトを表す、ことと、
上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを表す、デバイス記述フレームワークドキュメントを受信することと、
上記要求に応答して、上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを上記ＤＭサーバによって維持されるデバイス記述フレームワーク管理オブジェクトに追加することと
を行わせるコンピュータ実行可能命令を記憶する、ＤＭサーバ。
（項目１１）
上記コンピュータ実行可能命令はさらに、上記ＤＭサーバに、
上記ＬＷＭ２Ｍサーバに、上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを上記ＬＷＭ２Ｍサーバから要求するための要求を伝送することと、
上記要求に応答して、上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを受信することと
を行わせる、項目１０に記載のＤＭサーバ。
（項目１２）
上記コンピュータ実行可能命令はさらに、上記ＤＭサーバに、
上記ＬＷＭ２Ｍサーバから、上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを登録するための要求を受信することであって、上記要求は、上記ＬＷＭ２Ｍプロトコルに従って形成される、ことと、
上記ＬＷＭ２Ｍサーバから受信される要求を上記新しい管理オブジェクトを上記ＤＭサーバに登録するための要求に変換することと
を行わせる、項目１０に記載のＤＭサーバ。
（項目１３）
プロセッサおよびメモリを備える、プロトコルトランスレータであって、上記メモリは、上記プロセッサによって実行されると、上記プロトコルトランスレータに、
ライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）サーバから、上記サーバによってサポートされるＬＷＭ２Ｍオブジェクトをデバイス管理（ＤＭ）ゲートウェイに登録するための要求を受信することであって、上記要求は、上記ＬＷＭ２Ｍプロトコルに従ってフォーマットされる、ことと、
上記ＬＷＭ２Ｍサーバからの要求をデバイス登録要求に変換することであって、上記変換された要求のフォーマットは、上記オープンモバイルアライアンス（ＯＭＡ）デバイス管理（ＤＭ）プロトコルに準拠する、ことと、
上記変換されたデバイス登録要求を上記ＤＭゲートウェイに転送することと
を行わせるコンピュータ実行可能命令を記憶する、プロトコルトランスレータ。
（項目１４）
上記コンピュータ実行可能命令はさらに、上記プロトコルトランスレータに、
上記ＤＭゲートウェイから、上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを要求するための要求を受信することと、
上記デバイス記述フレームワークドキュメントのための要求を上記ＬＷＭ２Ｍサーバに伝送することと、
上記ＬＷＭ２Ｍサーバから、上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを受信することと、
上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを上記ＤＭゲートウェイに伝送することと
を行わせる、項目１３に記載のプロトコルトランスレータ。
（項目１５）
上記デバイス記述フレームワークドキュメントは、ＤＤＦ登録アラートメッセージの一部として、上記ＤＭゲートウェイに伝送される、項目１４に記載のプロトコルトランスレータ。
（項目１６）
ネットワークに接続されるデバイス管理サーバにおいて、
上記デバイス管理サーバのメモリ内に、上記デバイス管理サーバによってサポートされる複数の他の管理オブジェクト毎に、デバイス記述フレームワークドキュメントのコピーをそのような他の管理オブジェクトのために記憶する、デバイス記述フレームワーク管理オブジェクトを維持するステップと、
新しい管理オブジェクトを上記デバイス管理サーバに登録するための要求を受信するステップであって、上記要求は、上記新しい管理オブジェクトのためのデバイス記述フレームワークドキュメントを含む、ステップと、
上記要求に応答して、上記新しい管理オブジェクトのためのデバイス記述フレームワークドキュメントを上記デバイス管理サーバによって維持される上記デバイス記述フレームワーク管理オブジェクトに追加するステップと、
を含む、方法。
（項目１７）
上記新しい管理オブジェクトのデバイス記述フレームワークドキュメントのフォーマットの妥当性を確認することを、それを上記デバイス記述フレームワーク管理オブジェクトに追加することに先立って行うステップをさらに含む、項目１６に記載の方法。
（項目１８）
上記デバイス記述フレームワーク管理オブジェクトは、上記デバイス管理サーバによってサポートされる上記他の管理オブジェクト毎に、上記他の管理オブジェクトについての情報を含有するノードのセットを備え、上記ノードのうちの１つは、上記デバイス記述フレームワークドキュメントのコピーをそのような他の管理オブジェクトのために保持する、項目１６に記載の方法。
（項目１９）
上記新しい管理オブジェクトのためのデバイス記述フレームワークドキュメントを上記デバイス記述フレームワーク管理オブジェクトに追加するステップは、
上記デバイス記述フレームワーク管理オブジェクト内に、上記新しい管理オブジェクトのためのノードのセットを作成するステップと、
上記新しい管理オブジェクトのためのドキュメント記述フレームワークドキュメントのコピーを上記セットの１つのノード内に記憶するステップと、
を含む、項目１６に記載の方法。
（項目２０）
ネットワークに接続されるゲートウェイデバイス管理サーバにおいて、
上記ゲートウェイデバイス管理サーバのメモリ内に、上記ゲートウェイデバイス管理サーバによってサポートされる複数の他の管理オブジェクト毎に、デバイス記述フレームワークドキュメントのコピーをそのような他の管理オブジェクトのために記憶する、デバイス記述フレームワーク管理オブジェクトを維持するステップと、
新しい管理オブジェクトを上記ゲートウェイデバイス管理サーバに登録するための要求を受信するステップであって、上記新しい管理オブジェクトは、ライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）プロトコルに従って動作するサーバによってサポートされるオブジェクトを表す、ステップと、
上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを表す、デバイス記述フレームワークドキュメントを受信するステップと、
上記要求に応答して、上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを上記ゲートウェイデバイス管理サーバによって維持されるデバイス記述フレームワーク管理オブジェクトに追加するステップと、
を含む、方法。
（項目２１）
上記ＬＷＭ２Ｍサーバに、上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを上記ＬＷＭ２Ｍサーバから要求するための要求を伝送するステップと、
上記要求に応答して、上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを受信するステップと、
をさらに含む、項目２０に記載の方法。
（項目２２）
上記ＬＷＭ２Ｍサーバから、上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを登録するための要求を受信するステップであって、上記要求は、上記ＬＷＭ２Ｍプロトコルに従って形成される、ステップと、
上記ＬＷＭ２Ｍサーバから受信された要求を上記新しい管理オブジェクトを上記ゲートウェイデバイス管理サーバに登録する要求に変換するステップと、
をさらに含む、項目２０に記載の方法。
（項目２３）
ＤＤＦ登録アラートメッセージをデバイス管理（ＤＭ）サーバに送信し、上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを表すデバイス記述フレームワークドキュメントを、それへの登録のために上記ＤＭサーバに提供するステップをさらに含む、項目２０に記載の方法。
（項目２４）
ネットワークに接続されるデバイス管理（ＤＭ）サーバにおいて、
上記ＤＭサーバのメモリ内に、上記ＤＭサーバによってサポートされる複数の他の管理オブジェクト毎に、デバイス記述フレームワークドキュメントのコピーをそのような他の管理オブジェクトのために記憶する、デバイス記述フレームワーク管理オブジェクトを維持するステップと、
新しい管理オブジェクトを上記ＤＭサーバに登録するための要求を受信するステップであって、上記新しい管理オブジェクトは、ライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）プロトコルに従って動作するサーバによってサポートされるオブジェクトを表す、ステップと、
上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを表す、デバイス記述フレームワークドキュメントを受信するステップと、
上記要求に応答して、上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを上記ＤＭサーバによって維持されるデバイス記述フレームワーク管理オブジェクトに追加するステップと、
を含む、方法。
（項目２５）
上記ＬＷＭ２Ｍサーバに、上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを上記ＬＷＭ２Ｍサーバから要求するための要求を伝送するステップと、
上記要求に応答して、上記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを受信するステップと、
をさらに含む、項目２４に記載の方法。
（項目２６）
上記コンピュータ実行可能命令はさらに、上記ＤＭサーバに、
上記ＬＷＭ２Ｍサーバから、上記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを登録するための要求を受信することであって、上記要求は、上記ＬＷＭ２Ｍプロトコルに従って形成される、ことと、
上記ＬＷＭ２Ｍサーバから受信される要求を上記新しい管理オブジェクトを上記ＤＭサーバに登録するための要求に変換することと
を行わせる、項目２４に記載の方法。

より詳細な理解は、同一番号が全体を通して同一要素を示す、付随の図面と併せて一例として与えられる、以下の発明を実施するための形態から得られ得る。

図１は、ＯＭＡ ＤＭプロトコルの一般的アーキテクチャを図示する、ブロック図である。 図２は、ＯＭＡ ＤＭプロトコルＤＭツリーの実施例を示す。 図３は、ＯＭＡ ＤＭ ＤＤＦドキュメントの単純実施例を示す。 図４は、ＯＭＡ ＧｗＭＯプロトコルのアーキテクチャを図示する。 図５は、ＯＭＡ ＬＷＭ２Ｍプロトコルのアーキテクチャを図示する。 図６は、一実施形態による、ＯＭＡ ＧｗＭＯアーキテクチャの一実施形態のブロック図であって、ＬＷＭ２Ｍシステムのオーバーレイおよび本願の種々の側面もまた、図示される。 図７は、その一実施形態による、新しいＤＤＦ ＭＯのノードを図示する、略図である。 図８は、本明細書に説明されるＤＤＦ ＭＯ登録プロシージャによってＤＭサーバ内でトリガされ得る、処理ステップの一実施形態を図示する、フロー図である。 図９は、新しいＤＤＦをＤＤＦ ＭＯに登録するための方法の一実施形態を図示する、コールフローである。 図１０Ａは、ＤＤＦファイルがメッセージ内に埋め込まれる、ＤＤＦ登録アラートメッセージの一実施例を示す。 図１０Ｂは、ＤＤＦファイルの場所がＵＲＩによって規定される、ＤＤＦ登録アラートメッセージの別の実施例を示す。 図１１は、新しいＧｗＭＯデバイス登録プロシージャの一実施形態を図示する、コールフローである。 図１２は、ＯＭＡ ＧｗＭＯプロトコル仕様に説明されるようなデバイスインベントリＭＯの構造の一実施形態を図示するが、新しいノードであるＳｕｐｐｏｒｔｅｄＭＯおよびその子ノードの追加を伴う、略図である。 図１３Ａは、デバイス登録メッセージの一実施例を示す。 図１３Ｂは、登録解除メッセージの一実施例を示す。 図１４は、２つの追加および１つの削除コマンドを含有する、シーケンスコマンドの実施例を示す。 図１５Ａおよび１５Ｂはともに、その一実施形態による、プロトコルトランスレータによって実施され得る、プロトコル変換の一実施例を図示する、コールフローを構成する。 図１５Ａおよび１５Ｂはともに、その一実施形態による、プロトコルトランスレータによって実施され得る、プロトコル変換の一実施例を図示する、コールフローを構成する。 図１６は、ＯＭＡ ＧｗＭＯ適応動作モードの使用を通して、ＬＷＭ２ＭシステムとＯＭＡ ＤＭシステムとの間のインターワーキングを提供する、システムの実施形態を示す。 図１７Ａ、１７Ｂ、および１７Ｃは、一実施形態による、図１６のシステムの動作を図示する、コールフローを構成する。 図１７Ａ、１７Ｂ、および１７Ｃは、一実施形態による、図１６のシステムの動作を図示する、コールフローを構成する。 図１７Ａ、１７Ｂ、および１７Ｃは、一実施形態による、図１６のシステムの動作を図示する、コールフローを構成する。 図１８は、その一実施形態による、表示され得る、グラフィカルユーザインターフェースの一実施例を示す。 図１９Ａは、１つまたはそれを上回る開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システムの略図である。 図１９Ｂは、図１９Ａのシステムのさらなる詳細を図示する、略図である。 図１９Ｃは、種々の実施形態において使用され得る、エンドデバイスの例示的アーキテクチャを図示する、略図である。 図１９Ｄは、本明細書に図示されるおよび説明される論理エンティティのいずれかを実装するために使用され得る、コンピュータシステムまたはサーバのブロック図である。

前述のＯＭＡプロトコルの開発は、ＯＭＡによって取り組まれている最先端技術としての漸進的進化を反映する。ＯＭＡ ＬＷＭ２Ｍプロトコルは、Ｍ２Ｍ、ＩｏＴ、およびモノのウェブ（ＷｏＴ）デバイスにおける関心の高まりに伴って、より制約付きのデバイスの管理の提供を試みている。

ＬＷＭ２Ｍプロトコルは、先行するＯＭＡ ＤＭおよびＧｗＭＯプロトコルのものと異なる。これは、より平坦かつより単純なリソースツリーを伴う制約付きデバイスにより貢献する、通信プロトコルを使用する。データタイプは、簡略化され、ペイロードは、より効率的である。その結果、ＬＷＭ２Ｍプロトコルは、現在、ＯＭＡ ＤＭおよびＧｗＭＯのものと互換性がない。

さらに、ＯＭＡ ＤＭプロトコルは、新しいデバイスＭＯの追加を動的にサポートするための機構を欠いている。ＤＤＦドキュメントは、ＭＯ内の全ノードおよびその関連付けられた機能性を完全に定義し、ＤＭサーバ、ＤＭゲートウェイ、およびＤＭクライアントによって使用され、その個別の管理ツリーを構築する。クライアントが、ＤＭサーバがＤＤＦファイルを有していない、ＭＯを含む場合、ＤＭサーバは、ＭＯを認識することが不可能である。そのような機構の省略は、ＬＷＭ２Ｍオブジェクト定義をＯＭＡ ＤＭに追加する能力を妨げ、ＬＷＭ２ＭからＯＭＡ ＤＭへのインターワーキングをより困難にする。

加えて、ＯＭＡ ＧｗＭＯプロトコルは、デバイスがＤＭゲートウェイに動的に登録する能力を欠いている。ＧｗＭＯは、デバイスインベントリＭＯを有し、それがゲートウェイの背後で管理するデバイスを追跡するが、デバイスがそれに登録するために使用することができる、インターフェースを定義しない。Ｍ２Ｍ／ＩｏＴデバイスは、プラグアンドプレイ様式で追加されることができない。すなわち、ＧｗＭＯ内で最初にプロビジョニングされる必要がある。エンドユーザがデバイスをインストールし、ゲートウェイに通信する、展開シナリオでは、プラグアンドプレイ特徴の欠如は、望ましくない。

最後に、プロトコル変換機構が、ＯＭＡ ＤＭとＯＭＡ ＬＷＭ２Ｍプロトコルとの間のギャップをブリッジするために必要である。これらのプロトコルは、メッセージング要件が非常に異なり、異なる市場区分のために設計されたものである。コマンド構造および使用も異なり、下層トランスポート層プロトコルもまた、異なる。これらの差異は、システムを可能な限りシームレスに相互動作させるために、いくつかの良好に定義された変換機構を要求する。

前述の欠点への対処として、本願は、ＯＭＡ ＬＷＭ２Ｍシステムが、ＯＭＡ ＤＭおよびＧｗＭＯシステムと相互動作することを可能にする、インターワーキング機構を開示する。

本明細書に開示される第１の側面によると、新しいデバイス記述フレームワーク（ＤＤＦ）管理オブジェクト（ＭＯ）が、ＤＭサーバおよびＤＭゲートウェイが、ＬＷＭ２Ｍオブジェクトを認識することを可能にするために定義される。本ＭＯは、ＤＭサーバ／ゲートウェイが、ＬＷＭ２Ｍオブジェクト定義等の新しく定義されたＭＯを容認することを可能にするであろう。

本明細書に開示される第２の側面によると、新しいＤＤＦ登録プロシージャが、新しく定義されたＤＤＦの追加または更新を動的にサポートするために定義される。いったんＬＷＭ２Ｍオブジェクトが、ＤＤＦフォーマットにコンバートされると、結果として生じるドキュメントは、次いで、ＤＭサーバまたはＤＭゲートウェイのいずれかに登録されることができる。本特徴は、ＤＭサーバおよびＤＭゲートウェイが、ＬＷＭ２ＭオブジェクトをＤＭ ＭＯとして認識することを可能にする。

本明細書に開示される第３の側面によると、新しいＧｗＭＯ登録プロシージャが、デバイスが、それ自体をＬＷＭ２Ｍサーバを通してＤＭゲートウェイに登録することを可能にするために定義される。新しい登録プロセスは、デバイスをＤＭゲートウェイに登録するためのＬＷＭ２Ｍデバイス「登録」動作を拡張する。ＬＷＭ２Ｍサーバが「登録」動作を完了後、新しい登録プロシージャの一部として、それがデバイスについて有する情報をＤＭゲートウェイに送信する。ＤＭゲートウェイは、順に、デバイスインベントリＭＯをデバイスについての情報で更新する。本特徴は、Ｍ２Ｍ／ＩｏＴデバイスが、ＯＭＡ ＤＭシステムの中に動的に「プラグアンドプレイ」することを可能にする。

本明細書に開示される第４の側面によると、プロトコル変換機構が、ＬＷＭ２ＭからＯＭＡ ＤＭプロトコルへのインターワーキングをサポートするために定義される。ＯＭＡ ＤＭは、ＲＥＳＴｆｕｌプロトコルではない一方、ＬＷＭ２Ｍは、ＲＥＳＴｆｕｌである。すなわち、いくつかの変換が、ＬＷＭ２ＭからＤＭにインターワーキングするために要求される。加えて、いくつかのＤＭコマンドは、コマンドを処理するために、状態情報が保たれることを要求する。これらのコマンドは、ＲＥＳＴｆｕｌコマンドに変換される必要あり、状態情報は、インターワーキング機能によって、変換を補助するために保たれる。

図６は、ＯＭＡ ＧｗＭＯアーキテクチャの一実施形態のブロック図であって、ＬＷＭ２Ｍシステムのオーバーレイおよび本願の種々の側面もまた、図示される。示されるように、本実施形態では、ＯＭＡ ＤＭサーバ６０１は、ＯＭＡ ＤＭゲートウェイ６０２と通信する。ＯＭＡ ＤＭゲートウェイ６０２は、そのトランスペアレントモードを介して、いくつかのエンドデバイス（例えば、モバイルデバイス６０４）と、そのプロキシモードを介して、他のエンドデバイス（例えば、コンピュータ６０６）と通信してもよい。加えて、ＯＭＡ ＤＭゲートウェイ６０２は、その適応モードを介して、ＯＭＡ ＬＷＭ２Ｍサーバ６０８と通信してもよい。ＬＷＭ２Ｍサーバ６０８は、Ｍ２Ｍデバイス６１０ａ、６１０ｂ、および６１０ｃ等のいくつかの典型的には制約付きのデバイスと通信し、それを管理する。

図６はさらに、本明細書に説明される機構およびプロシージャが図示されるアーキテクチャ上にオーバーレイされ得る方法を図示する。例えば、新しく定義されたＤＤＦ ＭＯ６１２は、ＯＭＡ ＤＭサーバ６０１およびＯＭＡ ＤＭゲートウェイ６０２の両方に記憶されてもよい。本明細書に説明されるＤＤＦ ＭＯ登録プロシージャ６１４の側面は、ＯＭＡ ＤＭサーバ６０１とＯＭＡ ＤＭゲートウェイ６０２との間ならびにＯＭＡ ＤＭゲートウェイ６０２とＯＭＡ ＬＷＭ２Ｍサーバ６０８との間で実施されてもよい。プロトコル変換機能／エンティティ６１６およびＧｗＭＯデバイス登録プロシージャ６２０は、ＯＭＡ ＬＷＭ２Ｍサーバ６０８とＯＭＡ ＤＭゲートウェイ６０２との間で実施されてもよい。

種々の実施形態では、ＬＷＭ２Ｍサーバ６０８およびＤＭゲートウェイ６０２は、同じ場所に位置することができる、または別個に位置することもできる。プロトコル変換機能／エンティティ６１６は、別個のエンティティであることができる、またはＤＭゲートウェイ６０２もしくはＬＷＭ２Ｍサーバ６０８のいずれかの一部であることができる。

本明細書に説明される機構およびプロシージャの利点は、Ｍ２Ｍサービス層アーキテクチャとのデバイス管理動作の収束を促すことである。現在、ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍ等のアーキテクチャは、デバイス管理を実施するための手段として、すでにＯＭＡ ＤＭを規定している。しかしながら、現在のＯＭＡ ＤＭおよびＧｗＭＯプロトコル内のＭ２Ｍ／ＩｏＴデバイスの管理は、完全に規定されていない。本開示に提示されるＬＷＭ２Ｍプロトコルならびに機構およびプロシージャの導入に伴って、Ｍ２Ｍ／ＩｏＴの管理は、サービス層アーキテクチャを用いて完全に実現されることができる。展開は、次いで、これらの拡張を利用することができ、例えば、ＤＭサーバ６０１は、Ｍ２Ｍサーバの一部であって、ＤＭゲートウェイ６０２は、Ｍ２Ｍゲートウェイの一部である。

エンドデバイス６０４、６０６、または６１０ａ−ｃ等のエンドデバイスは、例えば、機械、センサ、器具、もしくは同等物、移動局、固定もしくはモバイル加入者ユニット、ポケベル、携帯情報端末（ＰＤＡ）、コンピュータ、携帯電話もしくはスマートフォン、または有線もしくは無線環境において動作可能な任意の他のタイプのデバイスを含む、Ｍ２ＭまたはＭＴＣデバイス等の無線ネットワーク内で通信可能な任意の無線デバイスを備えてもよい。エンドデバイスの例示的アーキテクチャは、図１９Ｃに関連して以下に説明される。本願では、エンドデバイス６０４、６０６、および６１０ａ−ｃ等のエンドデバイスはまた、ＯＭＡ ＤＭクライアントと称され得る。

一実施形態では、ＯＭＡ ＤＭサーバ６０１、ＯＭＡ ＤＭゲートウェイ６０２、プロトコルトランスレータ６１６、およびＯＭＡ ＬＷＭ２Ｍサーバ６０８は、コンピューティングシステムまたはサーバのメモリ内に記憶され、そのコンピューティングシステムまたはサーバのプロセッサによって実行される、コンピュータ実行可能命令の形態で具現化され得る、論理エンティティ（例えば、ソフトウェア）である。これらの論理エンティティが実装され得る、例示的コンピューティングシステムまたはサーバは、図１９Ｄに関連して以下に説明される。他の実施形態では、これらのエンティティは、ハードウェアまたはハードウェアおよびソフトウェアの任意の組み合わせ内に全体的に実装されてもよい。ＯＭＡ ＤＭサーバ６０１、ＯＭＡ ＤＭゲートウェイ６０２、プロトコルトランスレータ６１６、およびＯＭＡ ＬＷＭ２Ｍサーバ６０８等の図６に図示される種々のネットワークエンティティは、図では、別個のコンピュータシステムまたはサーバとして図示されるが、それらの任意の２つまたはそれを上回るものは、単一コンピューティングシステムまたはサーバ内の別個の論理エンティティとして具現化され得ることを理解されたい。

さらに、本明細書に説明されるＤＤＦ ＭＯ登録プロシージャ６１４、プロトコル変換機能６１６、およびＧｗＭＯデバイス登録プロシージャ６２０を実装または実施する、ＯＭＡ ＤＭサーバ６０１、ＯＭＡ ＤＭゲートウェイ６０２、およびＯＭＡ ＬＷＭ２Ｍサーバ６０８内の機能性はまた、個別のサーバ６０１、６０２、もしくは６０８または別のコンピュータシステムもしくはサーバ（図示せず）のうちの１つ、もしくはハードウェアおよびソフトウェアの任意の他の組み合わせのプロセッサ上で実行するコンピュータ実行可能命令（例えば、ソフトウェア）の形態で実装されてもよいことを理解されたい。
（デバイス記述フレームワーク管理オブジェクト（ＤＤＦ ＭＯ））

ＯＭＡ ＤＭプロトコルでは、ＯＭＡデバイス記述フレームワーク（ＤＤＦ）は、管理オブジェクト内の全ノード、その関連付けられたプロパティ、およびその値を定義する。また、ＯＭＡ ＤＭプロトコルでは、ＤＭサーバ、ＤＭゲートウェイ、およびＤＭクライアントは、ＤＤＦ内の情報を使用して、ＯＭＡ ＤＭ管理ツリーのその個別のバージョンを構築してもよい。典型的には、ＤＤＦドキュメントは、アウトオブバンドでこれらのエンティティに提供され、本プロビジョニングは、実際の動作に先立って生じる。本明細書に開示されるのは、ＤＭサーバの動作を妨害せずに、ＤＭサーバに知らせ、そのＤＤＦドキュメントをアップロードするための新しく定義されたＤＤＦを伴うデバイスのための機構である。

具体的には、新しいＤＤＦ ＭＯ６１２は、ＤＭサーバ（例えば、ＤＭサーバ６０１）およびまたＤＭゲートウェイ（例えば、ＤＭゲートウェイ６０２）において使用するために本明細書に開示される。ＤＭサーバにおける新しいＤＤＦ ＭＯの使用の以下の任意の議論は、ＤＭゲートウェイにおける使用にも等しく適用可能であって、その逆も同様であることを理解されたい。

本実施形態では、新しく定義されたＤＤＦ ＭＯ６１２は、他のＭＯと同一ＤＭツリー内に常住してもよく、ＤＭサーバによってサポートされる全ＭＯのＤＤＦのコピーを保持するであろう。種々の実施形態では、ＭＯは、ＤＭサーバにおけるインターフェース内で、ウェブサービスＡＰＩインターフェースを通して、またはＤＭクライアントによって実行される新しいＤＤＦ登録プロシージャを通してのいずれかにおいて、ＤＭサーバに登録されることができ、その方法は全て、以下にさらに説明される。

新しいＤＤＦ ＭＯ６１２のための構造の一実施形態は、図７に示される。本実施形態では、構造は、ＤＭサーバが、ＭＯの複数のバージョンをサポートすることを可能にする。また、本実施形態では、ＤＤＦ ＭＯは、ＤＭサーバに事前にプロビジョニングされ、開始に応じて、ＤＤＦ ＭＯの構造をＤＭツリーのＤＭサーバのバージョン内に構築することができる。一実施形態では、ＤＤＦ ＭＯは、ＤＭツリーのルートノードに常駐することができるが、しかしながら、他の実施形態では、所望に応じて、別の場所にも常駐することができる。

図７のＤＤＦ ＭＯのノード毎の説明は、ＯＭＡ ＤＭ専門用語を使用して以下に説明される。列挙される全ＵＲＩは、．／ＤＤＦ ＭＯ ＵＲＩ、すなわち、ＤＤＦ ＭＯのためのベースＵＲＩに対するものである。以下の説明では、「ステータス」は、ノードが必須または随意であるかどうかを示し、「ツリー発生」は、ＤＤＦ ＭＯ内に出現し得るノードのインスタンスの数を示し、「フォーマット」は、ノードのためのデータフォーマットを示し、「アクセスタイプ」は、取得、追加、コピー、および削除等のノードに実施され得る、動作を示す。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞
本プレースホルダノードは、ＭＯの名称を含有し、そのＤＤＦは、子ノード内で参照される。実施例は、ＳＣＯＭＯ、ＦＵＭＯ、ＤｅｖＩｎｆｏ等を含む。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞
本プレースホルダノードは、ＭＯのバージョンを含有し、そのＤＤＦは、子ノード内で参照される。本ノードの存在は、ＤＭサーバが、同一ＭＯの異なるバージョン、例えば、バージョン１．０および１．１をサポートすることを可能にする。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／ＯｂｊｅｃｔＩＤ
本リーフノードは、ＤＭサーバがＭＯを識別するために使用し得る、オブジェクトＩＤを含有する。好ましくは、ＤＭツリー内で一意に規定されたＩＤである。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／ＤｄｆＮａｍｅ
本リーフノードは、ＤＤＦの名称を含有する。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／Ｄｅｓｃｒｉｐｔｉｏｎ
本リーフノードは、先祖ノードにおいて参照されるＭＯバージョンの記述を含有する。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／Ｓｔａｔｕｓ
本リーフノードは、ノードの動作のステータスを含有する。先祖ノード（＜ＭｏＶｅｒｓｉｏｎ＞）が作成されると、ＤＭサーバは、自動的に、本ノードをデフォルト値（０）に設定する。次いで、ＤＭサーバは、クライアントによって実施される動作に応じて、本ノードを適切に設定するであろう。一実施形態では、許容可能値は、以下の通りである。
・０−ＤＤＦが存在しない（デフォルト）：これは、ＤＤＦが存在しないことを規定する、デフォルト状態である。
・１−アップロード済み：本状態は、ＤＤＦがＤＭサーバ／ゲートウェイにアップロードされたことを規定する。
・２−アクティブ化済み：本状態は、ＭＯが使用のために利用可能であることを規定する。ＤＭサーバ／ゲートウェイは、アップロードされたＤＤＦが適切にフォーマットされたことを確認する。
・３−エラー：ＤＤＦドキュメントが不正形式である場合、ＤＭサーバは、ステータスフィールドをエラーに設定し、ＤＤＦが処理されることができないことを示す。
・４−非アクティブ化済み：本状態は、以前にアクティブ化されたＭＯが現在非アクティブ化されていることを規定する。本状態にあるとき、新しいＭＯは、作成されることができないが、既存のＭＯが、存在することができる。本状態は、より古いバージョンの機能性を保存しながら、ＭＯのより新しいバージョンにアップグレードするために使用される。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／ＰｒｏｔｏｃｏｌＮａｍｅ
本リーフノードは、下層ＤＤＦのプロトコル名称を含有し、ＤＭサーバ／ゲートウェイによって使用され、使用すべきＧｗＭＯモードを判定する。許容可能値は、以下の通りである。
・０−ＯＭＡ ＤＭ（デフォルト）
・１−ＯＭＡＬＷ２ＭＷ

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／ＤｄｆＦｉｌｅ
本リーフノードは、ＤＭサーバ内にローカルで記憶される、ＤＤＦの実際のファイルを含有する。本ノードは、．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒｓｉｏｎ＞／ＤｄｆＵｒｉノードのものと相互に排他的である。１つのみが、一度にアクティブであるべきである。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／ＤｄｆＵｒｉ
本リーフノードは、ＤＤＦファイルが記憶される場所のＵＲＩを含有する。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／Ｏｐｅｒａｔｉｏｎｓ
本内部ノードは、ＤＤＦ ＭＯによってサポートされる全アクションのための親ノードである。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／Ｏｐｅｒａｔｉｏｎｓ／Ｕｐｌｏａｄ
本リーフノードは、実行コマンドがＤＤＦファイルをアップロードするための標的ノードである。ステータスは、いったん実行コマンドが完了すると、ＤＭサーバによってアップロードするように設定される。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／Ｏｐｅｒａｔｉｏｎｓ／ＵｐｌｏａｄＡｃｔｉｖａｔｅ
本随意のリーフノードは、実行コマンドがＤＤＦファイルをアップロードし、いったんアップロードが完了すると、その動作をアクティブ化するための標的ノードである。ステータスは、いったん実行コマンドが完了すると、ＤＭサーバによってアクティブ化するように設定される。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／Ｏｐｅｒａｔｉｏｎｓ／Ａｃｔｉｖａｔｅ
本リーフノードは、アップロード済みになった後、実行コマンドが参照されるＤＤＦをアクティブ化するための標的ノードである。ステータスは、いったん実行コマンドが完了すると、ＤＭサーバによってアクティブ化されるように設定される。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／Ｏｐｅｒａｔｉｏｎｓ／ＤｅＡｃｔｉｖａｔｅ
本リーフノードは、動作された後、実行コマンドが参照されるＭＯを非アクティブ化するための標的ノードである。ＭＯが非アクティブ化されると、ＤＭサーバは、ＤＤＦに基づいて、新しいＭＯの作成を可能にしないであろうが、既存のＭＯが動作することを可能にするであろう。本特徴は、より古いバージョンとの互換性を保ちながら、ＭＯバージョンをアップグレードするために使用される。ステータスは、いったん実行コマンドが完了すると、ＤＭサーバによって非アクティブ化するように設定される。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／Ｏｐｅｒａｔｉｏｎｓ／Ｅｘｔ
本内部ノードは、ベンダ特有または将来的ＯＭＡ ＤＭ拡張をＤＤＦ ＭＯに提供する。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒ＞／Ｅｘｔ
本内部ノードは、ベンダ特有または将来的ＯＭＡ ＤＭ拡張をＤＤＦ ＭＯに提供する。

ＵＲＩ：．／＜ＭｏＮａｍｅ＞／Ｅｘｔ
本内部ノードは、ベンダ特有または将来的ＯＭＡ ＤＭ拡張をＤＤＦ ＭＯに提供する。

ＵＲＩ：．／Ｅｘｔ
本内部ノードは、ベンダ特有または将来的ＯＭＡ ＤＭ拡張をＤＤＦ ＭＯに提供する。
（ＤＤＦ ＭＯ登録プロシージャ６１４）

一実施形態による、いったんＤＭサーバが起動し、前述のＤＤＦ ＭＯのノードが作成されると、新しいＭＯが、追加される、または既存のＭＯが、そのＤＤＦファイルをＤＭサーバに登録することによって、動的に更新されることができる。新しいＭＯのＤＤＦを登録するための複数の実施形態が、本明細書に説明される。

第１の実施形態では、既存のＭＯへの更新のための新しいＭＯまたはＤＤＦのＤＤＦは、ＤＭサーバアドミニストレータまたは権限が付与されたユーザによって、例えば、ＤＭサーバの管理ユーザインターフェースの使用を通して、ＤＭサーバにローカルで登録されてもよい。本第１の実施形態における登録プロシージャは、現在のＭＯがプロビジョニングされる方法に類似するが、ＭＯが、ＤＭサーバの通常動作の間、動的にプロビジョニングされることができるという点において異なる。ＤＭサーバとのユーザインターフェースの使用を通して、ＤＭサーバアドミニストレータまたはさらに権限が付与されたユーザは、ＤＤＦファイルをＤＭサーバにアップロードすることができる。これは、ＤＭサーバがデバイスへおよびからの継続中のＤＭコマンドを処理中に行われることができる。いったんＤＤＦドキュメントがアップロードされると、ＤＤＦは、アクティブ化され、同一ユーザインターフェースを通して使用されることができる。アクティブ化プロセスの間、ＤＤＦチェッカが、新しくアップロードされたファイルに対して起動され、有効な構文を有する、すなわち、ＯＭＡ ＤＭプロトコルによって規定されたＤＤＦファイルの要件に準拠することを確実にしてもよい。ＤＤＦチェッカがＤＤＦドキュメントの妥当性を確認する場合、ＤＭサーバは、ＤＤＦ ＭＯ内の新しいＭＯのためのステータスノード（前述）をアクティブ化に設定する。ＤＤＦチェックが、ＤＤＦドキュメント内にエラーを見出す場合、ＤＭサーバは、ステータスノードをエラーに設定する。

図８は、本明細書に説明されるＤＤＦ ＭＯ登録プロシージャによってＤＭサーバ内でトリガされ得る、処理ステップの一実施形態を図示する、フロー図である。いったんＸＭＬフォーマットにおけるＤＤＦファイルがアップロードされると、ＤＤＦドキュメントは、ステップ８０２において、ＸＭＬドキュメントを解析するために、ＤＤＦリーダによって読み取られる。次いで、ステップ８０４において、ＤＤＦドキュメントの妥当性を確認するかどうか決定が行われてもよい。そうでなければ、制御は、ステップ８０８に進み、ＤＤＦドキュメントは、処理のために、ＯＭＡ ＤＭプロトコル機能性（以下、「ＤＭエンジン」と称される）を実装する、ＤＭサーバのソフトウェアコンポーネントにパスされる。妥当性の確認が実施されるべき場合、制御は、ステップ８０６に進み、ＤＤＦチェッカは、新しいＤＤＦファイルをＤＭエンジンに送信する前に、適切なＤＤＦルール／構文が満たされているかどうか確認してもよい。例えば、ＤＤＦチェッカは、ＤＤＦドキュメントを分析し、その構文およびフォーマットがＯＭＡ ＤＭプロトコル仕様の要件に準拠することを確実にしてもよい。エラーが、ＤＤＦファイルのフォーマット内で検出される場合、制御は、ステップ８１４に進んでもよく、ＤＭサーバのＤＭエンジンは、．／ＤＤＦ ＭＯ／＜ＭＯＮＡＭＥ＞／＜ＭＯＶｅｒ＞／ステータスノードを作成し、値をエラー状態に設定する。エラーが、ステップ８０６において検出されず、ＤＤＦファイルの妥当性が確認される場合、制御は、ステップ８０８に進み、ＤＤＦファイルは、ＤＭエンジンにパスされる。

ステップ８１０において、ＤＭエンジンは、次いで、新しいＤＤＦファイルによって表されるＭＯのための図７に示される対応するＤＤＦ ＭＯノードの作成に進むであろう。すなわち、ＤＭエンジンは、メモリ内に、それらのノードのそれぞれを実装するデータ構造を作成するであろう。ノードが作成された後、ステップ８１２において、ＤＭエンジンは、．／ＤＤＦ ＭＯ／＜ＭＯＮＡＭＥ＞／＜ＭＯＶｅｒ＞／ステータスノードをアクティブ化状態に設定する。

第２の実施形態では、新しいまたは更新されたＭＯのＤＤＦが、ＤＭサーバによって提供されるウェブサービスアプリケーションプログラミングインターフェース（ＡＰＩ）の使用を通して、ＤＭサーバに登録されてもよい。本実施形態は、非ＯＭＡ ＤＭエンティティが、そのリソースツリーをＤＭサーバに通信し、よりシームレスなインターワーキングを提供することを可能にする。本機構を使用することができる、非ＯＭＡ ＤＭエンティティの一実施例は、ＬＷＭ２Ｍサーバである。各ＬＷＭ２Ｍオブジェクトは、ＤＤＦファイルにコンバートされ、ウェブサービスＡＰＩを通して、ＤＭサーバにアップロードされることができる。ＤＤＦがアップロードされた後、図８のステップは、前述のように施行される。

第３の実施形態では、新しいまたは更新されたＭＯのＤＤＦは、新しい登録プロシージャを使用して、ＤＭプロトコルを介して、ＤＭクライアントまたはＤＭゲートウェイから動的にＤＭサーバに登録されてもよい。本実施形態は、新しいＤＤＦ登録アラートメッセージの作成によって実装されてもよい。現在、ＤＭクライアントは、アラートコード１２０１を伴うアラートメッセージを使用して、ＤＭサーバへのＤＭセッションを作成することができる。これは、ＤＭサーバ内にＤＭセッションを確立するための「クライアント開始管理セッション」要求を示す。本第３の実施形態では、付加的アラートコードが、追加され、ＤＭクライアントがアップロードするための新しいＤＤＦファイルを有することを示すために使用されてもよい。一実施形態では、新しいアラートメッセージは、以下のデータを含んでもよい。
・＜Ｍｅｔａ＞／＜Ｔｙｐｅ＞要素：アラートコンテンツの媒体タイプを含有する。例示的値は、「ｕｒｎ：ｏｍａ：ａｔ：ｏｍａ−ＤＤＦ ＭＯ：ｒｅｇｉｓｔｅｒｄｄｆ：１．０」であってもよい。
・＜Ｍｅｔａ＞／＜Ｆｏｒｍａｔ＞要素：アラートのフォーマットを含有する。本値は、＜Ｓｏｕｒｃｅ＞／＜ＬｏｃＵＲＩ＞または＜Ｉｔｅｍ＞／＜Ｄａｔａ＞要素が、それぞれ、規定されたかどうかに応じて、「ｃｈｒ」または「ｘｍｌ」であってもよい。
・＜Ｓｏｕｒｃｅ＞／＜ＬｏｃＵＲＩ＞要素：ＤＭサーバによって読み出されることができるＤＤＦファイルのＵＲＩを含有する。一実施形態では、本要素は、＜Ｉｔｅｍ＞／＜Ｄａｔａ＞要素と相互に排他的である。一方が存在する場合、他方は、存在しないはずである。
・＜Ｔａｒｇｅｔ＞／＜ＬｏｃＵＲＩ＞要素：ＤＤＦファイルが記憶されるべき宛先ＤＭツリーの標的ＵＲＩを含有する。
・＜Ｉｔｅｍ＞／＜Ｄａｔａ＞要素：＜Ｄａｔａ＞＜／Ｄａｔａ＞タグ内にｘｍｌフォーマットでＤＤＦファイルのコンテンツを含有する。前述のように、前述の一実施形態では、本要素は、＜Ｓｏｕｒｃｅ＞／＜ＬｏｃＵＲＩ＞要素と相互に排他的である。一方が存在する場合、他方は、存在しないはずである。

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

図９は、新しいＤＤＦをＤＤＦ ＭＯに登録するための本第３の実施形態の一実施例を図示する、コールフローである。本実施例では、ステップは、ＤＭゲートウェイ／クライアント９０２およびＤＭサーバ９０４によって実施される。ＤＭクライアントはまた、本図９に概略されるものと同一様式でＤＭゲートウェイまたはＤＭサーバのいずれかにＤＤＦ ＭＯ登録プロシージャを実施することができることに留意されたい。

示されるように、ステップ１において、ＤＭゲートウェイは、新しいＤＤＦドキュメントを得る。ステップ２において、ＤＭゲートウェイは、ＤＭサーバとＤＭセッションを開始する。加えて、ＤＤＦ登録アラートメッセージおよびＤＤＦ ＭＯのアップロードアクティブ化ノードにおける実行コマンドを送信する。本実施形態では、ＤＤＦファイルの場所のためのＵＲＩが、アラートメッセージがＤＤＦファイル自体のテキストを含有する代わりに、ＤＤＦ登録アラートメッセージ内で提供されると仮定される。

ステップ３において、ＤＭサーバは、ＤＤＦ登録アラートメッセージを受信し、ＤＤＦドキュメントを提供されるＵＲＩからフェッチする。ＤＭサーバは、次いで、ＤＤＦチェッカを使用して、ＤＤＦドキュメントの妥当性を確認してもよい。妥当性の確認が成功する場合、ＤＭサーバは、．／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒｓｉｏｎ＞／ステータスノードをアクティブ化に設定してもよい。次いで、ステップ４において、ＤＭサーバは、実行コマンドのステータスを、登録プロシージャが完了したことの確認のためのアラートとともに、ＤＭゲートウェイに送信してもよい。ステップ５において、ＤＭゲートウェイは、登録が完了したことのステータスを送信してもよい。ステップ６において、ＤＭサーバは、クライアントステータスを確認応答し、ＤＭセッションを閉鎖してもよい。

図１０Ａは、ＤＤＦファイルがメッセージ内に埋め込まれる、ＤＤＦ登録アラートメッセージの一実施例を示す。図１０Ｂは、ＤＤＦファイルの場所がＵＲＩによって規定される、ＤＤＦ登録アラートメッセージの別の実施例を示す。
（ＧｗＭＯデバイス登録プロシージャ６２０）

ＯＭＡ ＧｗＭＯプロトコル仕様は、ＤＭゲートウェイがゲートウェイに接続されるエンドデバイスのリストを維持するための方法を提供する、デバイスインベントリＭＯを定義する。しかしながら、エンドデバイスがＤＭゲートウェイに登録される方法について規定された機構はない。本願の別の側面として、本明細書に開示されるのは、ＬＷＭ２Ｍサーバが、エンドデバイスをＤＭゲートウェイに登録し、ＤＭゲートウェイにデバイスがサポートするＭＯのリストを提供し得る、新しいデバイス登録プロシージャ６２０である。一実施形態では、本デバイス登録プロシージャは、ＣｏＡＰリソースディレクトリ（ＲＤ）、ＥＴＳＩ Ｍ２Ｍサーバ、またはｏｎｅＭ２Ｍ共通サービスエンティティ（ＣＳＥ）等の任意の非ＯＭＡ ＤＭサーバに適用されてもよい。加えて、ＬＷＭ２Ｍサーバは、ＤＭゲートウェイの代わりに、直接、ＤＭサーバに通信し、ＤＭゲートウェイと同一機能性を提供してもよい。

図１１は、新しいＧｗＭＯデバイス登録プロシージャ６２０の一実施形態を図示する、コールフローである。図１１に図示されるように、プロセスに関わるエンティティは、ＬＷＭ２Ｍクライアント９０６、ＬＷＭ２Ｍサーバ６０８、プロトコルトランスレータ６１６、およびＤＭゲートウェイ６０２である。ＬＷＭ２Ｍクライアント、ＬＷＭ２Ｍサーバ、およびＤＭゲートウェイエンティティは、個別のＯＭＡ ＬＷＭ２ＭおよびＯＭＡ ＤＭプロトコル仕様に記載の様式で実装されてもよいが、必要に応じて、本明細書に説明される新しいＧｗＭＯデバイス登録プロシージャを実装するために修正される。プロトコルトランスレータ６１６は、以下にさらに詳細に説明される、新しい論理エンティティである。図１１では、プロトコルトランスレータ６１６は、別個のエンティティとして示される。しかしながら、他の実施形態では、プロトコルトランスレータ６１６は、ＬＷＭ２Ｍサーバ６０８またはＤＭゲートウェイ６０２のいずれかの一部として統合されてもよい。

図１１を参照すると、ステップ１において、ＬＷＭ２Ｍクライアント（デバイス）９０６は、ＬＷＭ２Ｍサーバ６０８に登録し、デバイスがサポートするＬＷＭ２Ｍオブジェクトのリストを提供する。本登録ステップは、既存のＯＭＡ ＬＷＭ２Ｍプロトコル仕様に従って実施される。

ステップ２ｂにおいて、ＬＷＭ２Ｍサーバは、ステップ２ａにおいて作成されたメッセージでデバイスに応答し、デバイスおよびそのサポートされるオブジェクトについての情報をプロトコルトランスレータに転送する。他の実施形態では、ＬＷＭ２Ｍサーバはまた、本ステップの間、ＤＤＦドキュメントを提供してもよい。その場合、以下に説明されるステップ６−９は、省略されてもよい。

ステップ３において、プロトコルトランスレータは、それが受信する情報を使用して、デバイス登録要求を作成する。プロトコルトランスレータが、デバイスによってサポートされるＬＷＭ２ＭオブジェクトのＤＤＦドキュメントでプロビジョニングされる、他の実施形態では、また、それらをデバイス登録要求とともに送信することもできる。再び、これは、以下に説明されるステップ６−９を実行する必要性を除去するであろう。

ステップ４において、プロトコルトランスレータは、デバイス登録要求をＤＭゲートウェイに送信する。

ステップ５において、ＤＭゲートウェイは、そのＤＤＦ ＭＯ内にデバイスによってサポートされるＬＷＭ２ＭオブジェクトのためのＭＯを見出すことができないことを発見するであろう。ＤＤＦドキュメントが提供された場合、制御は、直接、ステップ１０に進み、ＤＭゲートウェイによって新しいＭＯとして取り扱われるであろう、ＤＤＦドキュメントが提供された新しいＬＷＭ２Ｍオブジェクト毎に、ＤＭゲートウェイは、そのＤＤＦ ＭＯ内にノードのセットを作成し、その新しいＬＷＭ２Ｍオブジェクト（すなわち、新しいＭＯ）のためのＤＤＦドキュメントおよび他の情報を記憶するであろう。このように、新しいオブジェクト（ＭＯ）は、ＤＭゲートウェイのＤＭツリーに登録および追加される。しかしながら、ＤＤＦドキュメントにデバイス登録要求が供給されなかった場合、制御は、ステップ６に進む。

ステップ６において、ＤＭゲートウェイは、ＤＤＦドキュメントのための要求をプロトコルトランスレータに送信する。ステップ７において、プロトコルトランスレータは、要求をＬＷＭ２Ｍサーバに転送する。ステップ８において、ＬＷＭ２Ｍサーバは、ＬＷＭ２Ｍクライアントデバイスのオブジェクト（すなわち、ＭＯ）のためのＤＤＦドキュメントまたはそれらのＤＤＦドキュメントのためのＵＲＩを返信することによって応答する。

ステップ９において、プロトコルトランスレータは、ＤＤＦ登録アラートメッセージをＤＭゲートウェイに送信する。ステップ１０において、ＤＭゲートウェイは、そのＤＤＦ ＭＯを前述のように更新し、登録プロセスを完了する。また、そのデバイスインベントリＭＯを更新する。ステップ１１において、ＤＭゲートウェイは、デバイス登録完了メッセージをプロトコルトランスレータを通してＬＷＭ２Ｍサーバに送信する。

図１２は、ＯＭＡ ＧｗＭＯプロトコル仕様に説明されるようなデバイスインベントリＭＯの構造の一実施形態を図示するが、新しいノードであるサポートされるＭＯ８２０およびその子ノード８２２、８２４の追加を伴う、略図である。これらの新しいノードは、特定のデバイスがＯＭＡ ＤＭプロトコル仕様のＭＯのリストのものに類似する方式でサポートする、ＭＯ（例えば、ＬＷＭ２Ｍオブジェクト）を追跡するために使用されてもよい。デバイスインベントリＭＯ内へのサポートされるＭＯノード８２０の含有は、適切なＤＤＦドキュメントがＤＭゲートウェイのＤＤＦ ＭＯ内に存在することを確実にする。ドキュメントが存在しない場合、ＤＭゲートウェイは、前述のデバイス登録プロシージャの間にＤＤＦドキュメントを提供するようにＬＷＭ２Ｍサーバまたはプロトコルトランスレータにアラートしてもよい。一実施形態では、ノードは、ＬＷＭ２Ｍサーバが、ＤＤＦエントリをＤＤＦ ＭＯ内にアップロードし、アクティブ化した後、ＤＭゲートウェイによってポピュレートされる。

以下は、一実施形態による、新しいノードおよびそのＤＦプロパティの記述である。

ＵＲＩ：．／＜ｘ＞／Ｉｎｖｅｎｔｏｒｙ／Ｒｅｃｏｒｄｓ／＜ｘ＞^＊／ＳｐｐｏｒｔｅｄＭＯ
本内部ノード８２０は、デバイスがサポートする全ＭＯのリストのための親ノードである。

ＵＲＩ：．／＜ｘ＞／Ｉｎｖｅｎｔｏｒｙ／Ｒｅｃｏｒｄｓ／＜ｘ＞^＊／ＳｐｐｏｒｔｅｄＭＯ／＜ｘ＞^＊
本プレースホルダノード８２２は、デバイスがサポートするＭＯの名称を提供する。

ＵＲＩ：．／＜ｘ＞／Ｉｎｖｅｎｔｏｒｙ／Ｒｅｃｏｒｄｓ／＜ｘ＞^＊／ＳｐｐｏｒｔｅｄＭＯ／＜ｘ＞^＊／ＭｏＶｅｒＲｅｆ
本リーフノード８２４の値は、デバイスがサポートするＤＤＦのバージョンにポイントする、ＤＭツリー内のＵＲＩのノード名を提供する。値は、ＤＤＦ ＭＯ内に登録されるＤＤＦファイルのもの、例えば、．／ＤＤＦ ＭＯ／＜ＭｏＮａｍｅ＞／＜ＭｏＶｅｒｓｉｏｎ＞と合致しなければならない。そうではない場合、ＤＭゲートウェイは、デバイス登録プロシージャの間に、ＤＤＦドキュメントをＬＷＭ２Ｍサーバからまたはプロトコルトランスレータから要求する必要がある。

一実施形態では、図１１に図示されるデバイス登録プロシージャは、本明細書では、登録コマンドと称される、新しいＤＭコマンドによって実装されてもよい。ある実施形態では、登録コマンドは、ＯＭＡデバイス管理表現プロトコルのバージョン１．２．１のアトミックおよびシーケンスコマンドの両方のプロパティ要件を組み合わせ、これは、ＤＭゲートウェイが、それらが規定されたシーケンスで、かつ全か無か方式で、登録コマンド内の全下位コマンドを処理することが要求されることを意味する。これらの要件は、デバイスについての全情報がＤＭゲートウェイに正しく入力されることを確実にするために重要であり得る。好ましくは、関わるデバイスは、工場ブートストラップまたは動的にブートストラップされるかにかかわらず、ＤＭゲートウェイと適切に通信するために、証明書でプロビジョニングされている。

一実施形態では、以下の情報が、登録コマンド内に規定されてもよい。
１． デバイスインベントリ記録が作成される標的経路、例えば、．／＜ｘ＞／Ｉｎｖｅｎｔｏｒｙ／Ｒｅｃｏｒｄｓ／＜ｘ＞ｗｈｅｒｅ＜ｘ＞が、規定される。一実施形態では、本アイテムは、登録メッセージ内に要求される。
２． デバイスＩＤフィールド−一実施形態では、本フィールドは、デバイスがＤｅｖＩｎｆｏ ＭＯに見出されるｄｅｖＩＤを有する場合に規定されるべきである。デバイスがそのようなノードを有していない場合、登録メッセージは、本フィールドを含まなくてもよい。ＤＭゲートウェイは、本フィールドが規定されないとき、値を割り当ててもよい。図１２のデバイスインベントリＭＯのデバイスＩＤノードは、デバイス登録プロシージャの一部として提供される場合、本値でポピュレートされるであろう。
３． デバイスタイプフィールド−ＤｅｖＤｅｔａｉｌ ＭＯのＤｅｖＴｙｐｅノードに見出されるデバイスタイプを規定する。一実施形態では、非ＯＭＡ ＤＭデバイスのために、「Ｍ２Ｍデバイス」等の値が、規定されてもよい。一実施形態では、本アイテムは、登録メッセージ内に要求される。図１２のデバイスインベントリＭＯのＤｅｖＴｙｐｅノードは、デバイス登録プロシージャの一部として提供される場合、本値でポピュレートされるであろう。
４． 動作モード−デバイスが、それが動作し得るＧｗＭＯ動作モードの知識でプロビジョニングされる場合、本フィールドのための値を規定してもよい。デバイスが非ＯＭＡ ＤＭ準拠である場合、一実施形態では、本フィールドは、使用される適応モードを規定する、４に設定されてもよい。図１２のデバイスインベントリＭＯのモードノードは、デバイス登録プロシージャの一部として提供される場合、本値でポピュレートされるであろう。

登録コマンドの受信に応じて、ＤＭゲートウェイは、デバイス登録メッセージの下位追加コマンド（例えば、図１３Ａの例示的下位追加コマンド）に見出される規定されたノードを作成してもよく、成功する場合、デバイスインベントリＭＯのネットワーク接続ノードＬＡＮＲｅｆ８２６、アドレスタイプ８２８、およびアドレス８３０を供給するであろう。本情報は、ＤＭゲートウェイに既知である。すなわち、ＤＭゲートウェイは、デバイスが接続することができる、種々のネットワーク接続（ｗｉｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）等）を提供する（潜在的に）。これらの接続オプションは、それが展開されるときに、ＤＭゲートウェイによって把握される。１つのエントリが、デバイスインベントリＭＯツリーの．／＜ｘ＞／Ｉｎｖｅｎｔｏｒｙ／ＬＡＮノード下の接続オプション毎に存在する（図１２参照）。

図１３Ａは、デバイス登録メッセージの一実施例を示す。デバイス登録プロシージャの間、ＬＷＭ２Ｍサーバまたはプロトコルトランスレータのいずれかは、サポートされるＭＯがＤＭゲートウェイのＤＤＦ ＭＯに見出されない場合、ＤＤＦ ＭＯ登録プロシージャを使用して、ＤＤＦをアップロードしてもよい。いったんデバイス登録プロシージャが完了すると、ＤＭゲートウェイは、デバイスアタッチアラートをＤＭサーバに送信し、それに新しいデバイスがＤＭゲートウェイに登録され、現時点で管理され得ることを知らせる。

デバイスが、それ自体をＬＷＭ２Ｍサーバから登録解除すると、デバイス登録解除プロシージャが、実行され、ＤＭゲートウェイに、デバイスがもはや利用可能ではないことを知らせてもよい。同一登録コマンドが、追加コマンドの代わりに、削除コマンドを内側に伴って、送信されてもよい。これは、初期デバイス登録プロシージャによって作成された記録エントリを削除する。ＤＭゲートウェイは、順に、規定されたノードをデバイスインベントリＭＯから除去し、ＤＭサーバにデバイスデタッチアラートを送信し、サーバに、デバイスがもはや管理されるために利用可能ではないことを知らせてもよい。登録解除メッセージの一実施例は、図１３Ｂに示される。
（プロトコル変換インターワーキング）

本明細書に開示されるプロトコル変換機能は、ＯＭＡ ＤＭプロトコルをＬＷＭ２Ｍプロトコルにおよびその逆に変換するために使用されてもよい。種々の実施形態では、１）ＬＷＭ２Ｍサーバで内部から、２）ＬＷＭ２Ｍサーバから全メッセージを受信する別個のエンティティで外部から、または３）ＤＭゲートウェイのコンポーネントとしての３つの異なる方法のうちの１つで実装されてもよい。第１の実装の場合、ＤＭクライアントは、ＬＷＭ２Ｍサーバに統合されてもよく、前述のＤＤＦ ＭＯ登録およびデバイス登録のための新しい登録プロシージャをサポートするように更新されてもよい。第２の実装に関して、ＬＷＭ２Ｍサーバは、外部プロトコル変換インターワーキングエンティティに、それが受信する全メッセージを送信し、そのエンティティに本項に提案される変換を実施させてもよい。第３の実装に関して、ＤＭゲートウェイは、ＬＷＭ２Ｍメッセージの受信をサポートし、また、ＤＤＦ ＭＯ登録およびデバイス登録のための新しい登録プロシージャをサポートするように更新されてもよい。

表１は、本明細書に開示されるプロトコルトランスレータ（例えば、図１１に図示されるプロトコルトランスレータ）の一実施形態による、ＯＭＡ ＤＭコマンドとＬＷＭ２Ｍ動作との間およびＬＷＭ２Ｍ動作からＯＭＡ ＤＭコマンドへのプロトコル変換を説明する。本変換は、要求側に応じて、プロトコルトランスレータによって実施されてもよい。表１に記載のように、プロトコルトランスレータがアトミックおよびシーケンスＤＭコマンドの変換をハンドリングする様式は、以下により完全に説明される。

付加的背景として、ＯＭＡ ＤＭプロトコルは、ＨＴＴＰ／ＴＣＰの上で動作し、故に、サーバとクライアントとの間のセッション指向通信を維持するために、ＴＣＰプロトコルに依存する。一方、ＯＭＡ ＬＷＭ２Ｍは、ＣｏＡＰ／ＵＤＰの上で動作し、その結果、ＣｏＡＰの確認可能な再伝送機構を利用して、受信側から確認応答を得る必要がある。これは、ＤＭコマンドのグループがともに処理されるように規定される、アトミックおよびシーケンスＤＭコマンドのサービシングに関して特に重要である。

前述のように、ＤＭセッションは、ＯＭＡ ＤＭプロトコル内でＤＭサーバとＤＭクライアントとの間で作成され、ＤＭコマンドを２つのエンティティ間で伝送する。本管理セッションは、２つのエンドポイント間の信頼性があって、秩序のある通信をもたらす接続指向プロトコルである、ＴＣＰプロトコルのコンテキスト内で作成される。ＯＭＡ ＬＷＭ２Ｍは、制約付きデバイスに好適な低オーバーヘッドおよび短縮された待ち時間をもたらす無接続プロトコルである、ＵＤＰと呼ばれる、より軽量のトランスポート層プロトコルを使用する。その結果、接続指向プロトコルと無接続プロトコルおよびその逆間のギャップをブリッジするための機構が、ＬＷＭ２ＭおよびＯＭＡ ＤＭをインターワーキングさせるときに必要とされる。

ＯＭＡ ＤＭプロトコルでは、コマンドは、単一コマンドとして、またはアトミックまたはシーケンスコマンド内でともにグループ化されてのいずれかとして伝送されることができる。各コマンドは、関連付けられたコマンドＩＤ（ＣｍｄＩＤ）を有し、それを他のコマンドから区別する。一実施形態では、本ＣｍｄＩＤは、単一コマンドが送信されるとき、ＯＭＡ ＤＭからＬＷＭ２Ｍへの変換のためのＣｏＡＰトークンとして使用されてもよい。アトミックおよびシーケンスコマンドに関して、コマンドのグループのためのＣｍｄＩＤおよびグループ内のコマンド毎に別個のＣｍｄＩＤが存在してもよい。図１４は、２つの追加および１つの削除コマンドを含有する、シーケンスコマンドの実施例を示す。シーケンスコマンドは、ＣｍｄＩＤを有し、追加および削除コマンドはそれぞれ、その独自のＣｍｄＩＤを有する。アトミックコマンドの構造は、複数のＣｍｄＩＤを伴うシーケンスコマンドのものに類似する。これらの場合、一実施形態では、アトミックまたはシーケンスコマンドのいずれか内のコマンドのＣｍｄＩＤは、ＣｏＡＰメッセージＩＤにマップされてもよい一方、アトミックまたはシーケンスコマンドのＣｍｄＩＤは、トークンにマップされてもよい。

ＣｍｄＩＤのＣｏＡＰトークンおよびメッセージＩＤへのマッピングに加え、本願のプロトコルトランスレータは、アトミックおよびシーケンスコマンドの両方の要件を考慮する。アトミックコマンドに関して、要件は、全下位コマンドがセットとして実行され、ユニットとして成功または失敗することである。本要件が満たされない場合、実行された全下位コマンドは、その以前の状態にロールバックされる必要がある。その結果、本明細書に開示されるプロトコル変換機能は、全下位コマンドの実行前後に、影響されたノードの状態を追跡する。任意の下位コマンドがアトミックコマンド内で失敗する場合、プロトコルトランスレータは、全ての以前に実行された下位コマンドを元に戻さなければならない。その結果、一実施形態では、プロトコルトランスレータは、最初に、下位コマンドを実行する前に、ノードの状態を読み出し、それを保存する。

シーケンスコマンドはまた、コマンドをともにグループ化する能力をもたらすが、唯一の要件は、コマンドが規定された順序で実行されることであるという点において異なる。アトミックコマンド内の下位コマンドは、順序通り実行されるように保証されない。この場合、一実施形態では、プロトコルトランスレータは、下位コマンドの実行シーケンスを追跡する。

ＬＷＭ２ＭサーバがＤＭサーバに関してデバイスからデータを収集させる、情報報告の場合、ＬＷＭ２Ｍサーバは、ＬＷＭ２ＭオブジェクトのＵＲＩを標的化する一般的アラートを、デバイスから収集されたデータとともに、ＤＭゲートウェイに送信してもよく、これは、次いで、メッセージをＤＭサーバに中継するであろう。代替として、別の実施形態では、アラートノードが、ＬＷＭ２ＭオブジェクトのＤＤＦファイルに追加されてもよく、ＬＷＭ２Ｍサーバは、次いで、通常ＯＭＡ ＤＭコマンドを実行してもよい。

図１５Ａおよび１５Ｂはともに、ＤＭゲートウェイ６０２と関連付けられた第１のテキストボックス８５０に示される、ＤＭシーケンスコマンドのために本明細書に開示されるプロトコルトランスレータ６１６によって実施され得る、プロトコル変換の一実施例を図示する、コールフローを構成する。本実施例では、プロトコルトランスレータ６１６およびＬＷＭ２Ｍサーバ６０８は、図では、２つの別個のエンティティとして示されることに留意されたい。しかしながら、他の実施形態では、１つエンティティとして共存してもよい。

下位コマンド取得、置換、および実行は、プロトコルトランスレータによって、順序通り処理され、それぞれ、読取、書込、および実行動作に変換される。示されるように、ＬＷＭ２Ｍ動作のために使用されるトークンは全て、個々の下位コマンドではなく、シーケンスコマンドのＣｍｄＩＤにポイントする。示されるＵＲＩは、ＯＭＡのＬＷＭ２Ｍ技術仕様の候補バージョン１．０毎にプレフィックス「／３」を伴うＬＷＭ２Ｍデバイスオブジェクトに対応する。変換の詳細は、以下の通りである。

シーケンスＣｍｄＩＤが、プロトコルトランスレータとＬＷＭ２Ｍサーバ６０８との間で使用されるＣｏＡＰトークンにマップされる。また、ＬＷＭ２Ｍサーバ６０８とＬＷＭ２Ｍクライアント９０６との間でも使用される。

取得／３／０下位コマンドが、読取／３／０動作にマップされ、これは、／Ｄｅｖｉｃｅ／Ｍａｎｕｆａｃｔｕｒｅｒ（／３／０）リソースの読取をデバイス上で実施する。

値「Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ」が、／３／０リソースのために返される。

置換／３／１下位コマンドが、書込／３／１動作にマップされる、これは、／Ｄｅｖｉｃｅ／ＭｏｄｅｌＮｕｍｂｅｒ（／３／１）リソースへの書込をデバイス上で実施する。

値「Ｌｉｇｈｔｗｅｉｇｈｔ Ｍ２Ｍ Ｃｌｉｅｎｔ」が、／３／１リソースの中に書き込まれる。

実行／３／４下位コマンドが、実行／３／４動作にマップされ、これは、デバイスのリブートを実施する。

デバイスが「２．０４ Ｃｈａｎｇｅｄ」応答を実行動作に返した後、プロトコルトランスレータは、ステータス応答をＤＭゲートウェイに処理する。

各ＤＭコマンドへのステータスが、最初に与えられ、取得動作への結果が、ＤＭゲートウェイへの応答内に続く。
（ＧｗＭＯを使用したＯＭＡ ＬＷＭ２ＭからＯＭＡ ＤＭへのインターワーキング）

Ｍ２Ｍ／ＩｏＴデバイスの市場の成長に伴って、デバイスが、典型的には、建物、橋、交通信号等の到達が困難な場所に展開されるため、それらを管理するための機構を有することが、ますます重要となっている。ＯＭＡ ＤＭサービスプロバイダは、ＤＭサーバおよびＤＭゲートウェイのバックボーンインフラストラクチャを提供し、そのサービスをＭ２Ｍ／ＩｏＴサービスプロバイダに提供することができ、それらは、次いで、Ｍ２Ｍデバイスに提供し、動作させる。

図１６はＯＭＡ ＧｗＭＯ適応動作モードの使用を通して、ＬＷＭ２ＭシステムとＯＭＡ ＤＭシステムとの間のインターワーキングを提供する、システム７００の実施形態を示す。本実施形態では、ＬＷＭ２Ｍシステムは、ＬＷＭ２Ｍオブジェクト７１４を含む、ＬＷＭ２Ｍデバイス７１２と、ＬＷＭ２Ｍクライアント７０６と、ＬＷＭ２Ｍサーバ７０８とを備える。ＯＭＡ ＤＭシステムは、ＧｗＭＯコンポーネント（ＤＭゲートウェイ）７０２と、ＤＭサーバ７０４とを備える。前述のように、他の実施形態では、ＤＭゲートウェイ７０２およびＤＭサーバ７０４は両方とも、そのＤＭツリーの一部として、ＤＤＦ ＭＯ、すなわち、本明細書に説明されるようなＤＤＦ ＭＯ６１２をホストし、新しいＭＯの登録を可能にする。ＬＷＭ２Ｍオブジェクト７１４は、前述の提案されるＤＤＦ ＭＯ登録プロシージャの実施形態のうちの１つを使用して、ＤＤＦフォーマットにコンバートされ、ＤＭゲートウェイ７０２に提供される。ＬＷＭ２ＭオブジェクトからＤＤＦフォーマットへの変換は、例えば、標準化団体またはベンダによって、アウトオブバンドで実施されてもよい。そのような変換を実施する方法の１つは、ＬＷＭ２Ｍオブジェクトを、１つずつ、ＯＭＡ ＤＭ ＭＯにマップし、データタイプ変換を考慮することである。

ＤＭゲートウェイ７０２は、順に、前述の新しいＤＤＦ ＭＯ登録プロシージャ６１４を使用して、ＤＭサーバ７０４に、ＬＷＭ２Ｍオブジェクト７１４を記述する新しいＤＤＦを通知するであろう。これらのプロシージャは、ＤＭゲートウェイ７０２およびＤＭサーバ７０４の両方が、その個別のＤＭツリー内のＬＷＭ２Ｍオブジェクトを認識し、それらにおけるアクションをサポートすることを可能にする。

いったんＬＷＭ２Ｍオブジェクト７１４が、ＤＤＦ ＭＯに追加されると、ＬＷＭ２Ｍサーバ７０８は、前述の新しいＧｗＭＯデバイス登録プロシージャ６２０を使用して、そのデータベース内のデバイス情報をＤＭゲートウェイ７０２に提供してもよい。ＤＭゲートウェイ７０２は、次いで、ＯＭＡ ＧｗＭＯプロトコル仕様のデバイスアタッチアラートメッセージを使用して、ＤＭサーバ７０４に、新しいデバイスをアラートするであろう。本時点で、ＤＭサーバ７０４は、デバイスについての全情報を有し、ＯＭＡ ＤＭプロトコルを使用して、デバイス管理を実施することができる。情報報告の場合、デバイスは、その測定をＬＷＭ２Ｍサーバ７０８に報告し、これは、次いで、プロトコルトランスレータ６１６を通して、メッセージをＤＭゲートウェイ７０２に転送するであろう。ＤＭゲートウェイ７０２は、デバイス測定をＯＭＡ ＤＭプロトコルの一般的アラートメッセージ内でＤＭサーバ７０４に送信してもよい。

図１７Ａ、１７Ｂ、および１７Ｃは、図１６に図示される実施形態に従ってより詳細に前述されたロセスを図示する、コールフローを構成する。図１７Ａに示されるように、ステップ１−２において、デバイス７１２上で起動するＬＷＭ２Ｍクライアント７０６は、ＯＭＡ ＬＷＭ２Ｍプロトコル仕様に従って、ＬＷＭ２Ｍサーバ７０８に登録する。ステップ３−６において、前述でより詳細に説明される、新しいＧｗＭＯデバイス登録プロシージャ６２０が、実施される。ステップ７−８において、前述でより詳細に説明される、新しいＤＤＦ ＭＯ登録プロシージャ６１４が実施される。ステップ９−１０において、ＤＭゲートウェイ７０２は、デバイスアタッチアラートをＤＭサーバ７０４に送信する。

ここで図１７Ｂを参照すると、ステップ１１−１９において、ＤＭサーバ７０４は、ＤｅｖＩｎｆｏ取得要求を実施する。ステップ１１および１８は、ＯＭＡ ＤＭプロトコルに従って実施され、ステップ１４−１５は、ＬＷＭ２Ｍプロトコルに従って実施され、残りのステップは、本明細書に説明されるインターワーキングプロシージャに従って実施される。

最後に、図１７Ｃを参照すると、ステップ２０−２４において、ＬＷＭ２Ｍクライアント７０６は、通知メッセージをセンサ測定とともにＤＭサーバ７０４に送信する。ステップ２０は、ＬＷＭ２Ｍプロトコルに従って実施され、ステップ２１−２２は、本明細書に開示されるインターワーキングプロシージャに従って実施され、ステップ２３は、ＯＭＡ ＤＭプロトコルに従って実施される。

前述のように、また、以下に説明されるように、図９、１１、１５Ａ−Ｂ、および１７Ａ−Ｃに図示されるステップを実施するエンティティは、ネットワークに接続される、図１９Ｄに図示されるコンピュータシステム（以下に説明される）等、コンピュータシステムまたはサーバのメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実行され得る、論理エンティティである。さらに、図９、１１、１５Ａ−Ｂ、および１７Ａ−Ｃに図示される方法は、個別のエンティティのメモリ内に記憶される、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてもよく、そのコンピュータ実行可能命令は、エンティティのプロセッサ（例えば、図１９Ｄのプロセッサ９１）によって実行されると、図９、１１、１５Ａ−Ｂ、および１７Ａ−Ｃに図示される個別のステップを実施する。また、これらの図に図示される任意の伝送および受信するステップは、エンティティのプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下、個別のエンティティの通信回路（例えば、図１９Ｄの回路９７）によって実施されてもよいことを理解されたい。
例示的グラフィカルユーザインターフェース

図１８は、一実施形態による、図６のＤＭサーバ６０１またはＤＭゲートウェイ６０２または図１６のＤＭゲートウェイ７０２またはＤＭサーバ７０４等のＤＭサーバまたはＤＭゲートウェイによって表示され得る、グラフィカルユーザインターフェース９５０の一実施例を示す。グラフィカルユーザインターフェース９５０は、以下に説明されるように、ＤＭサーバまたはＤＭゲートウェイを実装するために使用され得る、図１９Ｄのコンピュータシステムのディスプレイ８６等、ＤＭサーバまたはＤＭゲートウェイのディスプレイ上に表示されてもよい。

示されるように、グラフィカルユーザインターフェース９５０は、ユーザ（例えば、ネットワークアドミニストレータ）に、ＤＭプロトコルへのＬＷＭ２Ｍプロトコルの統合を示すために使用されてもよい。示される実施形態では、グラフィカルユーザインターフェースは、サーバ／ゲートウェイによってサポートされる管理オブジェクト（ＭＯ）のリストを表示する、第１のウィンドウ９５２を含んでもよく、そのリストは、前述の方法に従って、ＯＭＡ ＤＭ ＭＯならびにＬＷＭ２Ｍオブジェクトの両方を含んでもよい。サーバ／ゲートウェイによって管理されるデバイスは、インターフェース９５０のウィンドウ９５４内に表示されてもよい。また、本実施形態では、別のウィンドウ９５６が、選択されたデバイス（ウィンドウ９５４内のリストから選択された）のためのリソースツリーを表示してもよく、そのデバイスは、本明細書に開示される原理に従ってＬＷＭ２Ｍデバイスを備えてもよい。
（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴシステム）

図１９Ａは、１つまたはそれを上回る開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントならびにＩｏＴ／ＷｏＴサービス層等であってもよい。

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

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

図１９Ｂを参照すると、フィールドドメイン内の図示したＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、図１９Ｄに図示され、以下に説明されるコンピュータシステム等、１つまたはそれを上回るサーバ、コンピュータ、もしくは同等物によって実装されてもよい。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用される、サービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウド、または同等物で等、種々の方法で実装されてもよい。

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

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

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

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

新しいＤＤＦ ＭＯ６１２、ＤＤＦ ＭＯ登録プロシージャ６１４、ＧｗＭＯデバイス登録プロシージャ６２０、およびプロトコル変換機能６１６は、例えば、ＥＴＳＩ Ｍ２ＭまたはｏｎｅＭ２Ｍアーキテクチャによって定義されたサービス層を含む、図１９Ｂに図示されるサービス層２２および２２’等のサービス層のためのデバイス管理ソリューションの一部として利用されることができる。そのようなサービス層は、サービス層が、それが管理を所望するＭ２Ｍデバイスを把握しているであろうため、ＤＤＦ登録およびＧｗＭＯデバイス登録プロシージャ６１４、６２０を開始してもよい。本明細書に説明されるプロシージャおよび機能は、展開を補助してもよく、ＤＭサーバ（前述のプロシージャを実施するように修正される）は、Ｍ２Ｍサーバの一部であって、ＤＭゲートウェイ（前述のプロシージャを実施するように修正される）は、Ｍ２Ｍゲートウェイの一部である。

図１９Ｃは、図６のエンドデバイス６０４、６０６、または６１０ａ−ｃ、図１６のＬＷＭ２Ｍデバイス７１２、ならびに図１９Ａおよび１９ＢのＭ２Ｍデバイス１８およびゲートウェイ１４等の例示的エンドデバイス３０の略図である。前述のように、エンドデバイスは、Ｍ２Ｍデバイス、ＭＴＣデバイス、またはＬＷＭ２Ｍデバイス、例えば、機械、センサ、器具、または同等物、移動局、固定もしくはモバイル加入者ユニット、ポケベル、携帯情報端末（ＰＤＡ）、コンピュータ、携帯電話もしくはスマートフォン、または有線もしくは無線環境内で動作可能な任意の他のタイプのデバイスを含む、無線ネットワーク内で通信可能な任意の無線デバイスを備えてもよい。図１９Ｃに示されるように、エンドデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッドおよび／またはインジケータ４２、非可撤性メモリ４４と、可撤性メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含んでもよい。エンドデバイス３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。

プロセッサ３２は、汎用プロセッサ、特殊用途プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたはそれを上回るマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン、および同等物であってもよい。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはエンドデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たしてもよい。プロセッサ３２は、伝送／受信要素３６に連結され得る、送受信機３４に連結されてもよい。図１９Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは通信を行ってもよい。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行ってもよい。プロセッサ３２は、ＤＭクライアントまたはＬＷＭ２Ｍクライアントの機能性をデバイス３０上に実装する、コンピュータ実行可能命令を実行してもよい。

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

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

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

プロセッサ３２は、非可撤性メモリ４４および／または可撤性メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶してもよい。非可撤性メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。可撤性メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード、および同等物を含んでもよい。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のエンドデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶してもよい。

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

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

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

図１９Ｄは、例えば、ＤＭサーバ、ＤＭゲートウェイ、ＬＷＭ２Ｍサーバ、プロトコルトランスレータ、Ｍ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサービス層、または同等物を含む、図６、９、１１、１５Ａ−Ｂ、１６、１７Ａ−Ｃ、または１９Ａ−Ｂに図示される論理エンティティのいずれかを実装するために使用され得る、コンピュータシステムまたはサーバ９０のブロック図である。図１９Ｄのコンピュータシステムまたはサーバ９０は、主に、ソフトウェアの形態であり得るコンピュータ可読命令によって制御されてもよく、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶あるいはアクセスされる。そのようなコンピュータ可読命令は、コンピュータシステム９０を起動させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行されてもよい。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備えてもよい。コプロセッサ８１は、付加的な機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、Ｐ２Ｐ通信に関連するデータを受信、生成、ならびに処理してもよい。

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

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

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

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

ＤＤＦ ＭＯ登録プロシージャ６１４、ＧｗＭＯデバイス登録プロシージャ６２０、およびプロトコル変換機能６１６を含む、本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、エンドデバイス、プロセッサ、または同等物等のマシンによって実行されたときに、本明細書で説明されるシステム、方法、ならびにプロセスを実施するおよび／または実装される、コンピュータ可読記憶媒体上に記憶されたコンピュータ実行可能命令（例えば、プログラムコード）の形態で具現化され得ることが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装されてもよい。コンピュータ可読記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、可撤性および非可撤性媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は、信号を含まない。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含むが、それらに限定されない。

Claims (26)

1. プロセッサおよびメモリを備えるデバイス管理サーバであって、前記メモリは、コンピュータ実行可能な命令を記憶し、前記コンピュータ実行可能な命令は、前記プロセッサによって実行されると、
   前記デバイス管理サーバの前記メモリ内にデバイス記述フレームワーク管理オブジェクトを維持することであって、前記デバイス記述フレームワーク管理オブジェクトは、前記デバイス管理サーバによってサポートされる複数の他の管理オブジェクトのそれぞれに対して、そのような他の管理オブジェクトのためのデバイス記述フレームワークドキュメントのコピーを記憶する、ことと、
   新しい管理オブジェクトを前記デバイス管理サーバに登録するための要求を受信することであって、前記要求は、前記新しい管理オブジェクトのためのデバイス記述フレームワークドキュメントを含む、ことと、
   前記要求に応答して、前記新しい管理オブジェクトのための前記デバイス記述フレームワークドキュメントを前記デバイス管理サーバによって維持される前記デバイス記述フレームワーク管理オブジェクトに追加することと
   を前記デバイス管理サーバに行わせる、デバイス管理サーバ。
2. 前記コンピュータ実行可能な命令は、前記新しい管理オブジェクトの前記デバイス記述フレームワークドキュメントを前記デバイス記述フレームワーク管理オブジェクトに追加することに先立って、前記新しい管理オブジェクトの前記デバイス記述フレームワークドキュメントのフォーマットの妥当性を確認することを前記デバイス管理サーバにさらに行わせる、請求項１に記載のデバイス管理サーバ。
3. 前記デバイス記述フレームワーク管理オブジェクトは、前記デバイス管理サーバによってサポートされる前記複数の他の管理オブジェクトのそれぞれに対して、前記他の管理オブジェクトについての情報を含有するノードのセットを備え、前記ノードのうちの１つは、前記デバイス記述フレームワークドキュメントのコピーをそのような他の管理オブジェクトのために保持する、請求項１に記載のデバイス管理サーバ。
4. 前記新しい管理オブジェクトのための前記デバイス記述フレームワークドキュメントを前記デバイス記述フレームワーク管理オブジェクトに追加することは、
   前記デバイス記述フレームワーク管理オブジェクト内に前記新しい管理オブジェクトのためのノードのセットを作成することと、
   前記新しい管理オブジェクトのための前記デバイス記述フレームワークドキュメントのコピーを前記セットの１つのノード内に記憶することと
   を含む、請求項１に記載のデバイス管理サーバ。
5. 前記デバイス記述フレームワーク管理オブジェクト内のそれぞれの他の管理オブジェクトのためのノードのセットは、
   前記他の管理オブジェクトの名称を含有するノードと、
   前記他の管理オブジェクトのバージョンのインジケーションを含有するノードと、
   前記他の管理オブジェクトを識別するために使用され得るオブジェクト識別子（ＩＤ）を含有するノードと、
   前記他の管理オブジェクトのための前記デバイス記述フレームワークドキュメントの名称を含有するノードと、
   前記他の管理オブジェクトのための前記デバイス記述フレームワークドキュメントと関連付けられたユニフォームリソースロケータ（ｕｒｌ）を含有するノードと、
   前記他の管理オブジェクトのステータスのインジケーションを含有するノードと、
   前記他の管理オブジェクト上で実施され得る複数の動作を表す複数のノードであって、前記複数の動作は、アップロード動作、アップロードアクティブ化動作、アクティブ化動作、非アクティブ化動作のうちの１つ以上を含む、複数のノードと
   のうちの１つ以上をさらに含む、請求項１に記載のデバイス管理サーバ。
6. プロセッサおよびメモリを備えるゲートウェイデバイス管理サーバであって、前記メモリは、コンピュータ実行可能な命令を記憶し、前記コンピュータ実行可能な命令は、前記プロセッサによって実行されると、
   前記ゲートウェイデバイス管理サーバの前記メモリ内にデバイス記述フレームワーク管理オブジェクトを維持することであって、前記デバイス記述フレームワーク管理オブジェクトは、前記ゲートウェイデバイス管理サーバによってサポートされる複数の他の管理オブジェクトのそれぞれに対して、そのような他の管理オブジェクトのためのデバイス記述フレームワークドキュメントのコピーを記憶する、ことと、
   新しい管理オブジェクトを前記ゲートウェイデバイス管理サーバに登録するための要求を受信することであって、前記新しい管理オブジェクトは、ライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）プロトコルに従って動作するＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを表す、ことと、
   前記ＬＷＭ２Ｍサーバによってサポートされる前記ＬＷＭ２Ｍオブジェクトを表すデバイス記述フレームワークドキュメントを受信することと、
   前記要求に応答して、前記ＬＷＭ２Ｍサーバによってサポートされる前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを前記ゲートウェイデバイス管理サーバによって維持される前記デバイス記述フレームワーク管理オブジェクトに追加することと
   を前記ゲートウェイデバイス管理サーバに行わせる、ゲートウェイデバイス管理サーバ。
7. 前記コンピュータ実行可能な命令は、
   前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを前記ＬＷＭ２Ｍサーバから要求するための要求を前記ＬＷＭ２Ｍサーバに伝送することと、
   前記要求に応答して、前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを受信することと
   を前記ゲートウェイデバイス管理サーバにさらに行わせる、請求項６に記載のゲートウェイデバイス管理サーバ。
8. 前記コンピュータ実行可能な命令は、
   前記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを登録するための要求を前記ＬＷＭ２Ｍサーバから受信することであって、前記要求は、前記ＬＷＭ２Ｍプロトコルに従って形成される、ことと、
   前記ＬＷＭ２Ｍサーバから受信された要求を前記新しい管理オブジェクトを前記ゲートウェイデバイス管理サーバに登録する要求に変換することと
   を前記ゲートウェイデバイス管理サーバにさらに行わせる、請求項６に記載のゲートウェイデバイス管理サーバ。
9. 前記コンピュータ実行可能な命令は、ＤＤＦ登録アラートメッセージをデバイス管理（ＤＭ）サーバに送信することにより、前記ＤＭサーバへの登録のために、前記ＬＷＭ２Ｍサーバによってサポートされる前記ＬＷＭ２Ｍオブジェクトを表す前記デバイス記述フレームワークドキュメントを前記ＤＭサーバに提供することを前記ゲートウェイデバイス管理サーバにさらに行わせる、請求項６に記載のゲートウェイデバイス管理サーバ。
10. プロセッサおよびメモリを備えるデバイス管理（ＤＭ）サーバであって、前記メモリは、コンピュータ実行可能な命令を記憶し、前記コンピュータ実行可能な命令は、前記プロセッサによって実行されると、
    前記ＤＭサーバの前記メモリ内にデバイス記述フレームワーク管理オブジェクトを維持することであって、前記デバイス記述フレームワーク管理オブジェクトは、前記ＤＭサーバによってサポートされる複数の他の管理オブジェクトのそれぞれに対して、そのような他の管理オブジェクトのためのデバイス記述フレームワークドキュメントのコピーを記憶する、ことと、
    新しい管理オブジェクトを前記ＤＭサーバに登録するための要求を受信することであって、前記新しい管理オブジェクトは、ライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）プロトコルに従って動作するＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを表す、ことと、
    前記ＬＷＭ２Ｍサーバによってサポートされる前記ＬＷＭ２Ｍオブジェクトを表すデバイス記述フレームワークドキュメントを受信することと、
    前記要求に応答して、前記ＬＷＭ２Ｍサーバによってサポートされる前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを前記ＤＭサーバによって維持される前記デバイス記述フレームワーク管理オブジェクトに追加することと
    を前記デバイス管理サーバに行わせる、ＤＭサーバ。
11. 前記コンピュータ実行可能な命令は、
    前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを前記ＬＷＭ２Ｍサーバから要求するための要求を前記ＬＷＭ２Ｍサーバに伝送することと、
    前記要求に応答して、前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを受信することと
    を前記ＤＭサーバにさらに行わせる、請求項１０に記載のＤＭサーバ。
12. 前記コンピュータ実行可能な命令は、
    前記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを登録するための要求を前記ＬＷＭ２Ｍサーバから受信することであって、前記要求は、前記ＬＷＭ２Ｍプロトコルに従って形成される、ことと、
    前記ＬＷＭ２Ｍサーバから受信される要求を前記新しい管理オブジェクトを前記ＤＭサーバに登録するための要求に変換することと
    を前記ＤＭサーバにさらに行わせる、請求項１０に記載のＤＭサーバ。
13. プロセッサおよびメモリを備えるプロトコルトランスレータであって、前記メモリは、コンピュータ実行可能な命令を記憶し、前記コンピュータ実行可能な命令は、前記プロセッサによって実行されると、
    ライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）サーバから、前記サーバによってサポートされるＬＷＭ２Ｍオブジェクトをデバイス管理（ＤＭ）ゲートウェイに登録するための要求を受信することであって、前記要求は、ＬＷＭ２Ｍプロトコルに従ってフォーマットされる、ことと、
    前記ＬＷＭ２Ｍサーバからの要求をデバイス登録要求に変換することであって、前記変換された要求のフォーマットは、オープンモバイルアライアンス（ＯＭＡ）デバイス管理（ＤＭ）プロトコルに準拠する、ことと、
    前記変換されたデバイス登録要求を前記ＤＭゲートウェイに転送することと
    を前記プロトコルトランスレータに行わせる、プロトコルトランスレータ。
14. 前記コンピュータ実行可能な命令は、
    前記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを要求するための要求を前記ＤＭゲートウェイから受信することと、
    前記デバイス記述フレームワークドキュメントのための前記要求を前記ＬＷＭ２Ｍサーバに伝送することと、
    前記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを前記ＬＷＭ２Ｍサーバから受信することと、
    前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを前記ＤＭゲートウェイに伝送することと
    を前記プロトコルトランスレータにさらに行わせる、請求項１３に記載のプロトコルトランスレータ。
15. 前記デバイス記述フレームワークドキュメントは、ＤＤＦ登録アラートメッセージの一部として、前記ＤＭゲートウェイに伝送される、請求項１４に記載のプロトコルトランスレータ。
16. ネットワークに接続されたデバイス管理サーバにおける方法であって、
    前記デバイス管理サーバのメモリ内にデバイス記述フレームワーク管理オブジェクトを維持することであって、前記デバイス記述フレームワーク管理オブジェクトは、前記デバイス管理サーバによってサポートされる複数の他の管理オブジェクトのそれぞれに対して、そのような他の管理オブジェクトのためのデバイス記述フレームワークドキュメントのコピーを記憶する、ことと、
    新しい管理オブジェクトを前記デバイス管理サーバに登録するための要求を受信することであって、前記要求は、前記新しい管理オブジェクトのためのデバイス記述フレームワークドキュメントを含む、ことと、
    前記要求に応答して、前記新しい管理オブジェクトのための前記デバイス記述フレームワークドキュメントを前記デバイス管理サーバによって維持される前記デバイス記述フレームワーク管理オブジェクトに追加することと
    を含む、方法。
17. 前記新しい管理オブジェクトの前記デバイス記述フレームワークドキュメントを前記デバイス記述フレームワーク管理オブジェクトに追加することに先立って、前記新しい管理オブジェクトの前記デバイス記述フレームワークドキュメントのフォーマットの妥当性を確認することをさらに含む、請求項１６に記載の方法。
18. 前記デバイス記述フレームワーク管理オブジェクトは、前記デバイス管理サーバによってサポートされる前記複数の他の管理オブジェクトのそれぞれに対して、前記他の管理オブジェクトについての情報を含有するノードのセットを備え、前記ノードのうちの１つは、前記デバイス記述フレームワークドキュメントのコピーをそのような他の管理オブジェクトのために保持する、請求項１６に記載の方法。
19. 前記新しい管理オブジェクトのための前記デバイス記述フレームワークドキュメントを前記デバイス記述フレームワーク管理オブジェクトに追加することは、
    前記デバイス記述フレームワーク管理オブジェクト内に前記新しい管理オブジェクトのためのノードのセットを作成することと、
    前記新しい管理オブジェクトのための前記デバイス記述フレームワークドキュメントのコピーを前記セットの１つのノード内に記憶することと
    を含む、請求項１６に記載の方法。
20. ネットワークに接続されたゲートウェイデバイス管理サーバにおける方法であって、
    前記ゲートウェイデバイス管理サーバのメモリ内にデバイス記述フレームワーク管理オブジェクトを維持することであって、前記デバイス記述フレームワーク管理オブジェクトは、前記ゲートウェイデバイス管理サーバによってサポートされる複数の他の管理オブジェクトのそれぞれに対して、そのような他の管理オブジェクトのためのデバイス記述フレームワークドキュメントのコピーを記憶する、ことと、
    新しい管理オブジェクトを前記ゲートウェイデバイス管理サーバに登録するための要求を受信することであって、前記新しい管理オブジェクトは、ライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）プロトコルに従って動作するＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを表す、ことと、
    前記ＬＷＭ２Ｍサーバによってサポートされる前記ＬＷＭ２Ｍオブジェクトを表すデバイス記述フレームワークドキュメントを受信することと、
    前記要求に応答して、前記ＬＷＭ２Ｍサーバによってサポートされる前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを前記ゲートウェイデバイス管理サーバによって維持される前記デバイス記述フレームワーク管理オブジェクトに追加することと
    を含む、方法。
21. 前記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを前記ＬＷＭ２Ｍサーバから要求するための要求を前記ＬＷＭ２Ｍサーバに伝送することと、
    前記要求に応答して、前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを受信することと
    をさらに含む、請求項２０に記載の方法。
22. 前記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを登録するための要求を前記ＬＷＭ２Ｍサーバから受信することであって、前記要求は、前記ＬＷＭ２Ｍプロトコルに従って形成される、ことと、
    前記ＬＷＭ２Ｍサーバから受信された要求を前記新しい管理オブジェクトを前記ゲートウェイデバイス管理サーバに登録する要求に変換することと
    をさらに含む、請求項２０に記載の方法。
23. ＤＤＦ登録アラートメッセージをデバイス管理（ＤＭ）サーバに送信することにより、前記ＤＭサーバへの登録のために、前記ＬＷＭ２Ｍサーバによってサポートされる前記ＬＷＭ２Ｍオブジェクトを表す前記デバイス記述フレームワークドキュメントを前記ＤＭサーバに提供することをさらに含む、請求項２０に記載の方法。
24. ネットワークに接続されたデバイス管理（ＤＭ）サーバにおける方法であって、
    前記ＤＭサーバのメモリ内にデバイス記述フレームワーク管理オブジェクトを維持することであって、前記デバイス記述フレームワーク管理オブジェクトは、前記ＤＭサーバによってサポートされる複数の他の管理オブジェクトのそれぞれに対して、そのような他の管理オブジェクトのためのデバイス記述フレームワークドキュメントのコピーを記憶する、ことと、
    新しい管理オブジェクトを前記ＤＭサーバに登録するための要求を受信することであって、前記新しい管理オブジェクトは、ライトウェイトマシンツーマシン（ＬＷＭ２Ｍ）プロトコルに従って動作するＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを表す、ことと、
    前記ＬＷＭ２Ｍサーバによってサポートされる前記ＬＷＭ２Ｍオブジェクトを表すデバイス記述フレームワークドキュメントを受信することと、
    前記要求に応答して、前記ＬＷＭ２Ｍサーバによってサポートされる前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを前記ＤＭサーバによって維持される前記デバイス記述フレームワーク管理オブジェクトに追加することと
    を含む、方法。
25. 前記ＬＷＭ２Ｍオブジェクトのためのデバイス記述フレームワークドキュメントを前記ＬＷＭ２Ｍサーバから要求するための要求を前記ＬＷＭ２Ｍサーバに伝送することと、
    前記要求に応答して、前記ＬＷＭ２Ｍオブジェクトのための前記デバイス記述フレームワークドキュメントを受信することと
    をさらに含む、請求項２４に記載の方法。
26. 前記ＬＷＭ２ＭサーバによってサポートされるＬＷＭ２Ｍオブジェクトを登録するための要求を前記ＬＷＭ２Ｍサーバから受信することであって、前記要求は、前記ＬＷＭ２Ｍプロトコルに従って形成される、ことと、
    前記ＬＷＭ２Ｍサーバから受信される要求を前記新しい管理オブジェクトを前記ＤＭサーバに登録するための要求に変換することと
    をさらに含む、請求項２４に記載の方法。