JP2013502635A - 通信システムにおけるデバイス管理をサポートするためにゲートウェイ機能を制御する技術 - Google Patents

Abstract

本発明は、デバイス管理(ＤＭ)サーバが直接制御できないＤＭゲートウェイ、ＤＭサーバ及びエンドデバイスを含む通信システムにおいて、デバイスがＤＭゲートウェイを通じてＤＭサーバにより管理されるようにＤＭゲートウェイを運用する方法、通信システムでＤＭゲートウェイが特定クラスのデバイスに対するブートストラップ情報を更新する方法、ＤＭゲートウェイがＤＭコマンドを処理する方法、ＤＭゲートウェイがトラップメッセージを処理する方法、ＤＭゲートウェイが周期的サービス/能力広告メッセージを処理する方法と、及びＤＭゲートウェイがハートビートタイムアウトを処理する方法を提供する。ＤＭゲートウェイ、ＤＭサーバ及びデバイスを含む通信システムにおけるＤＭゲートウェイを運用する方法は、ＤＭゲートウェイがデバイスからサービス/能力広告メッセージを受信するステップと、ＤＭゲートウェイが受信されたサービス/能力広告メッセージに含まれた情報に基づいてデバイスのうち一つ又はそれ以上の特徴を決定するステップと、ＤＭゲートウェイがデバイスの決定された一つ又はそれ以上の特徴に基づいてアルゴリズムを呼び出すステップとを有し、ＤＭゲートウェイは、呼び出されたアルゴリズムにより動作し、ＤＭサーバがＤＭゲートウェイを通じてデバイスに管理コマンドを送信し、ＤＭゲートウェイを通じてデバイスから受信された警告を処理することで、上記デバイスを管理できる。

Description

本発明は通信システムにおけるデバイス管理(Device Management：ＤＭ)に関するもので、特に、通信システムにおけるＤＭをサポートするためにゲートウェイ機能を制御する技術に関する。

ユビキタス(ubiquitous)通信技術及びシステムが成長するにつれて、デバイスの機能及び複雑性が増加する。しかしながら、デバイスの機能及び複雑性の増加とともに、デバイス管理のための必要性も増加している。このような要求を解決するために、ＯＭＡ(Open Mobile Alliance)は、デバイスを管理するためのプロトコル及びメカニズムを特定するためにデバイス管理(ＤＭ)ワーキンググループを組織した。ＯＭＡ ＤＭワーキンググループは、デバイスの遠隔管理に使用されるデバイスに関連したＤＭクライアントとＤＭサーバとの間の双方向プロトコルを定義するＯＭＡ-ＤＭ仕様を開発した。ＤＭサーバとＤＭクライアントとの間の関連インスタンス(instance)はＤＭセッションと呼ばれ、ＤＭクライアント又はＤＭサーバによって開始される。ＤＭクライアントはデバイス内に存在し、ＤＭサーバはＤＭクライアント上にコマンドを呼び出してデバイスを管理する。ＤＭクライアントは、コマンドを処理して応答をＤＭサーバに送信する。サーバとクライアントとの間の通信は、ＳｙｎｃＭＬ(Synchronization Markup Language)メッセージの交換を含む。一般的に、デバイスは無線デバイスであったが、最近では、ＯＭＡ-ＤＭが有線デバイスの遠隔管理を解決し始めた。ＯＭＡ-ＤＭの例は、デバイスの初期構成情報の設定、デバイスの永続的な(persistent)情報の後続設置及び更新、デバイスからの管理情報検索、及びデバイスによって生成されるイベント及びアラームの処理を含む。

以下では、図１を参照して、ＯＭＡ-ＤＭ構成の実施形態を説明する。

図１を参照すると、ＯＭＡ-ＤＭ構成は、ＤＭサーバ１４０、ＤＭクライアント１１０、及びＤＭ標準管理オブジェクト(Management Object：ＭＯ)１２０を含む。ＤＭクライアント１１０とＤＭ標準ＭＯ１２０は、デバイス１００内に同一の場所に位置する。ＯＭＡ-ＤＭ構成は、追加的な構造的要素を含むことができる。しかしながら、ＯＭＡ-ＤＭ構成の追加的な構成要素に関する説明は、簡潔性のために省略する。

上記したＤＭサーバ１４０及びＤＭクライアント１１０は、インターフェースＤＭ-１ １３０とＤＭ-２ １３２を通じて通信する。ＤＭクライアント１１０は、インターフェースＤＭ-５ １３４を通じてＤＭ標準ＭＯ１２０と通信する。

ＤＭプロトコルは、ＤＭクライアント１１０のすべての実施形態がサポートしなければならない３個の標準ＭＯ１２０を定義する。これらＤＭ標準ＭＯ１２０は、ＤＭアカウント(Ａｃｃ)ＭＯ１２２、デバイス情報(ＤｅｖＩｎｆｏ)ＭＯ１２４、及びデバイス詳細(ＤｅｖＤｅｔａｉｌ)ＭＯ１２６を含む。

ＤＭ Ａｃｃ ＭＯ１２２は、ブートストラップされたＤＭサーバ１４０に関する情報を管理するために使用される。ＤＭデバイス１１０に対して、間違いなくブートストラップされた各ＤＭサーバ１４０において、ＤＭ Ａｃｃ ＭＯ１２２は、ＤＭサーバ識別子(ＩＤ)、接続(connectivity)情報、サーバアドレス、サーバ及びクライアント認証情報(credentials)などに関する情報を維持する。ＤｅｖＩｎｆｏ ＭＯ１２４は、ＤＭクライアント１１０に関連したデバイス１００に関する基本情報を提供する。この基本情報は、デバイスＩＤ、デバイス製造業者ＩＤ、モデルＩＤ、及び言語設定を含む。ＤｅｖＤｅｔａｉｌ ＭＯ１２６は、ＤＭクライアント１１０に関連したデバイス１００に関する付加情報を提供する。この付加情報は、デバイスタイプ、ＯＥＭ(Original Equipment Manufacturer)、ハードウェアバージョン、ファームウェアバージョン、ソフトウェアバージョン、デバイス１００のオプション特性(例えば、ラージオブジェクト(large-object)取扱能力)をサポートするか否かの表示、管理ツリーの最大深さ、ＵＲＩ(Uniform Resource ID)の最大総長、及びＵＲＩセグメントの最大総長を含む。

以下、ＯＭＡ-ＤＭを採用する通信システムの実施形態について、図２を参照して説明する。

図２を参照すると、ＯＭＡ-ＤＭを採用する通信システムの実施形態は、有線ネットワーク２００、無線ネットワーク２０２、有線デバイス２１０、無線デバイス２１２、ＤＭサーバ２２０、及びＤＭ管理者(authority)２３０を含む。有線デバイス２１０及び無線デバイス２１２の各々は、ＤＭクライアント(図示せず)と関連付けられる。また、ＤＭ管理者２３０は、ＯＳＳ(Operations Support System)であり得る。図２で、実線は物理的接続(physical connectivity)を示し、点線は論理的接続(logical connectivity)を示す。

図２に示すＯＭＡ-ＤＭを採用する通信システムの実施形態は、複数の可能な実施形態のうち一つに過ぎない。例えば、有線ネットワーク２００と無線ネットワーク２０２のうちいずれか一つが省略され得る。あるいは、有線ネットワーク２００と無線ネットワーク２０２は、結合することもできる。また、ＤＭサーバ２２０とＤＭ管理者２３０は有線ネットワーク２００に接続されているように示されているが、ＤＭサーバ２２０とＤＭ管理者２３０のうち一つ又は両方ともが、無線ネットワーク２０２に接続することもできる。

図２に示す通信システムにおけるＯＭＡ-ＤＭを容易にするために、ＯＭＡ-ＤＭ仕様に基づいた双方向プロトコルは、ＤＭサーバ２２０と無線デバイス２１２に関連付けられるＤＭクライアントとの間と、ＤＭサーバ２２０と有線デバイス２１０に関連付けられるＤＭクライアントとの間で、利用される。ＤＭ管理者２３０は、有線デバイス２１０と無線デバイス２１２のそれぞれに関連したＤＭクライアントのＤＭ動作をＤＭサーバ２２０を通じて指示できる。ＤＭサーバ２２０と有線デバイス２１０と無線デバイス２１２のそれぞれに関連したＤＭクライアントとの間の相互交信(interaction)のみがＯＭＡ-ＤＭ仕様の範囲内にある。

ＤＭクライアントとＤＭサーバ開始されるＤＭセッションに対する実施形態は、図３を参照して説明する。

図３は、関連技術によるところの通信システムにおけるＤＭクライアントとＤＭセッションが開始されるＤＭサーバに対する信号フローを示す。

図３を参照すると、ＤＭサーバ３０２とＤＭクライアント３０４との間のＤＭセッションが開始されたＤＭサーバは、２つの段階を踏む。第１の段階は、設定段階３１０であり、第２の段階は管理段階３２０である。設定段階３１０は、認証及びデバイス情報のための情報の交換を含む。設定段階３１０での情報の交換は、各々複数のメッセージが含まれる３個のパッケージ、すなわちパッケージ０ ３１２、パッケージ１ ３１４、及びパッケージ２ ３１６を含む。パッケージ０ ３１２は、ＤＭサーバ３０２からＤＭクライアント３０４に送信され、通知メッセージと呼ばれる。パッケージ１ ３１４は、ＤＭクライアント３０４からＤＭサーバ３０２に送信される。パッケージ１ ３１４は、クライアント開始情報とデバイス情報を含む。クライアント開始情報は、クライアント認証情報を含む。パッケージ２ ３１６は、ＤＭサーバ３０２からＤＭクライアント３０４に送信される。パッケージ２ ３１６は、サーバ開始情報と初期管理動作を含む。サーバ開始情報は、一つ又はそれ以上のサーバ認証情報を含む。

管理ステップ３２０は、２個のパッケージ、すなわちパッケージ３ ３２２とパッケージ４ ３２４との交換を含む。パッケージ３ ３２２は、ＤＭクライアント３０４からＤＭサーバ３０２に送信される。パッケージ３ ３２２は、パッケージ２３１６によってトリガーされる管理動作に関するクライアント応答情報を含む。パッケージ４ ３２４は、ＤＭサーバ３０２からＤＭクライアント３０４に送信される。ＤＭセッションがパッケージ２のメッセージ３１６以降も続行される場合、パッケージ４ ３２４は、追加的な管理動作と一つ又はそれ以上の追加的なユーザー相互交信コマンドのうち少なくとも一つを含む。パッケージ３のメッセージ３２２とパッケージ４のメッセージ３２４の付加的なサイクルは、ＤＭセッションが終了するまでＤＭサーバ３０２とＤＭクライアント３０４との間に送信される。

現在公開されているＯＭＡ-ＤＭ標準バージョンは、バージョン１.２.１である。ＯＭＡ-ＤＭワーキンググループは、現在２個の新たなＤＭプロトコルバージョン、すなわちＯＭＡ-ＤＭバージョン１.３とＯＭＡ-ＤＭバージョン２.０を開発中である。ＯＭＡ-ＤＭバージョン１.３は、ＯＭＡ-ＤＭバージョン１.２.１でのセキュリティ脆弱性のうち一部を解決するために開発されている。

しかしながら、ＯＭＡ-ＤＭの新たなバージョンの開発は、ＤＭワーキンググループによって解決される必要があるいくつかの新たな課題が提示する。例えば、ＯＭＡ-ＤＭバージョン１.２.１とは異なり、新たなＯＭＡ-ＤＭバージョンにより管理されるデバイスは、世界的にルーティング可能なアドレスを有していないこともある。この主な原因は、セキュリティの理由のために、新たなＯＭＡ-ＤＭバージョンでターゲットとなるデバイスのうち大部分がＮＡＴ(Network Address Translation)及び/又はファイアウォール機能を提供するデバイスの後に公開されるためである。また、このデバイスの大部分は移動性を持ち、そのアドレスは自身が配置されているネットワークにより制御される。新たなＯＭＡ-ＤＭバージョンによる他の課題は、このデバイスの一部がＯＭＡ-ＤＭクライアントを内蔵しないこともある。

ゲートウェイ装置が、上記した課題の一部を解決するために研究されている。ゲートウェイ装置は、ＤＭサーバとＤＭクライアントとの間の自力での(unaided)相互交信が可能でない状況で、少なくとも一つがＯＭＡ-ＤＭを駆動するＤＭサーバとＤＭクライアントとの間の相互交信を容易にする実体(entity)である。

現在ＯＭＡ-ＤＭパラダイムとは違って、ゲートウェイ装置は、新たなＯＭＡ-ＤＭバージョンでデバイス管理の重要な役割をすると予想される。したがって、新たなＯＭＡ-ＤＭバージョンとの利用のためにゲートウェイＭＯ(ＧｗＭＯ)イネーブラが開発中である。

したがって、通信システムにおけるＤＭをサポートするためにゲートウェイ機能を制御するための技術の需要がある。

したがって、本発明は上記した従来技術の問題点に鑑みてなされたものであって、その目的は、通信システムにおけるＤＭをサポートするためのゲートウェイ機能を制御するための技術を提供することにある。

このような目的を達成するために、本発明の一態様によれば、ＤＭゲートウェイ、ＤＭサーバ、及びデバイスを含む通信システムにおけるＤＭゲートウェイを運用する方法が提供される。その方法は、ＤＭゲートウェイにより、新たな管理可能なデバイスを検出するステップと、ＤＭゲートウェイにより、デバイスの一つ又はそれ以上の特徴を決定するステップと、ＤＭゲートウェイにより、デバイスの決定された一つ以上の特徴に基づいてアルゴリズムを呼び出すステップとを有し、ＤＭゲートウェイは、呼び出したアルゴリズムによって動作し、それによってＤＭサーバは、ＤＭゲートウェイを通じてデバイスに管理コマンドを送信し、ＤＭゲートウェイを通じてデバイスから受信された警告を処理することによってデバイスを管理できる。

本発明の他の態様によれば、ＤＭゲートウェイ、ＤＭサーバ、及びデバイスを含む通信システムにおけるＤＭゲートウェイを運用する方法が提供される。その方法は、ＤＭゲートウェイにより、デバイスからサービス/能力広告メッセージ(capability advertisement message)を受信するステップと、ＤＭゲートウェイにより、サービス/能力広告メッセージに基づいてデバイスがＤＭサーバによって使用されるＤＭプロトコルをサポートするか否かを判定するステップと、デバイスがＤＭサーバによって使用されるＤＭプロトコルをサポートしないと判定した場合、デバイスに対するＩｎｆｏｒｍ ＤＭサーバフラグがゲートウェイ構成(Ｃｏｎｆｉｇ)ＭＯで真に設定されるか否かを判定するステップと、Ｉｎｆｏｒｍ ＤＭサーバフラグが真に設定されると判定した場合、デバイスの代わりにＤＭサーバとの通信を試してローカルエリアネットワーク(ＬＡＮ)デバイスインベントリＭＯのデバイスに対するＤＭサーバ接続属性を更新するステップとを有する。

また、本発明の他の態様によれば、通信システムにおけるＤＭゲートウェイが特定クラスのデバイスに対するブートストラップ情報を更新する方法が提供される。その方法は、ＤＭゲートウェイにより、特定クラスのデバイスに対するブートストラップ情報を受信するステップと、ＤＭゲートウェイにより、特定クラスのデバイスに対するブートストラップ情報を更新するステップと、ＤＭゲートウェイにより、デバイスタイプが更新されたブートストラップ情報のデバイスタイプと一致するデバイスに対するＬＡＮデバイスインベントリＭＯを検索するステップとを有する。

さらに、本発明の他の態様によれば、通信システムにおけるＤＭゲートウェイがＤＭコマンドを処理する方法が提供される。その方法は、ＤＭゲートウェイにより、ＤＭサーバからデバイスに対するＤＭコマンドを受信するステップと、ＤＭゲートウェイにより、ＬＡＮデバイスインベントリＭＯにデバイスに対するエントリが存在するか否かを判定するステップと、ＬＡＮデバイスインベントリＭＯにデバイスに対するエントリが存在すると判定した場合、ＤＭゲートウェイにより、デバイスにＤＭコマンドを送信して所定時間内で応答を待機するステップと、応答が所定時間内に受信される場合、ＤＭゲートウェイにより、ＤＭサーバに応答を送信するステップとを有する。

本発明の他の態様によれば、通信システムのＤＭゲートウェイがトラップメッセージを処理する方法が提供される。その方法は、ＤＭゲートウェイにより、デバイスからトラップメッセージを受信するステップと、ＤＭゲートウェイにより、ＬＡＮデバイスインベントリＭＯにデバイスに対するエントリがあるか否かを判定するステップと、ＬＡＮデバイスインベントリＭＯにデバイスに対するエントリがないと判定した場合、ＤＭゲートウェイにより、プロキシサーバの役割及びプロトコル適応の役割のうちいずれか一つを呼び出し、受信されたトラップメッセージ内にＤＭサーバを識別する目的地情報があるか否かを判定するステップと、ＬＡＮデバイスインベントリＭＯにデバイスに対するエントリがあると判定した場合、ＤＭゲートウェイにより、受信されたトラップメッセージ内にＤＭサーバを識別する目的地情報があるか否かを判定するステップと、受信されたトラップメッセージにＤＭサーバを識別する目的地情報があると判定した場合、ＤＭゲートウェイにより、トラップメッセージを目的地情報で識別されたＤＭサーバに送信するステップとを有する。

また、本発明の他の態様によれば、通信システムにおけるＤＭゲートウェイが周期的なサービス/能力広告メッセージを処理する方法が提供される。その方法は、ＤＭゲートウェイにより、デバイスから周期的サービス/能力広告メッセージを受信するステップと、ＤＭゲートウェイにより、ＬＡＮデバイスインベントリＭＯのデバイスに対する有効時間を再設定するステップとを有する。

なお、本発明の他の態様によれば、通信システムにおけるＤＭゲートウェイがハートビートタイムアウト(heartbeat timeout)を処理する方法が提供される。その方法は、ＤＭゲートウェイにより、ハートビートタイマが経過したか否かを判定するステップと、ハートビートタイマが経過したと判定する場合、ＬＡＮデバイスインベントリＭＯで、ＤＭゲートウェイにより、有効時間が経過したデバイスのエントリを削除するステップとを有する。

本発明は、通信システムでのＤＭをサポートするためのゲートウェイ機能を制御するための技術を提供することができる。

本発明による実施形態の上記及び他の態様、特徴、及び利点は、添付の図面と共に述べる以下の詳細な説明から、一層明らかになるはずである。

関連技術によるＯＭＡ-ＤＭ構成を示す図である。 関連技術によるＯＭＡ-ＤＭを採用する通信システムの一例を示す図である。 関連技術による通信システムにおけるＤＭクライアントとＤＭサーバ開始されるＤＭセッションに対する信号フローを示す図である。 本発明の一実施形態による初期サービス/能力広告メッセージ処理を示すフローチャートである。 本発明の一実施形態によるブートストラップサーバの役割のアルゴリズムを示すフローチャートである。 本発明の一実施形態によるプロキシサーバの役割のアルゴリズムを示すフローチャートである。 本発明の一実施形態によるプロトコル適応役割のアルゴリズムを実現するためにＤＭゲートウェイの機能実行を示すフローチャートである。 本発明の一実施形態による特定デバイスタイプに対するブートストラップ情報を更新する手順を示すフローチャートである。 本発明の一実施形態によって、ＤＭゲートウェイがプロキシサーバの役割又はプロトコル適応の役割をする場合に、エンドユーザーデバイスを目的地とするＤＭコマンドの処理手順を示すフローチャートである。 本発明の一実施形態によるＤＭゲートウェイでのトラップメッセージの処理手順を示すフローチャートである。 本発明の一実施形態によるＤＭゲートウェイでの周期的サービス/能力メッセージの処理手順を示すフローチャートである。 本発明の一実施形態によるＤＭゲートウェイでのハートビートタイムアウト(Heartbeat Timeout)メッセージの処理手順を示すフローチャートである。 本発明の一実施形態によるＤＭゲートウェイを示すブロック構成図である。

以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。

添付の図面を参照した下記の説明は、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるような本発明の実施形態の包括的な理解を助けるために提供するものであり、この理解を助けるための様々な特定の詳細を含むが、唯一つの実施形態に過ぎない。したがって、本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。

次の説明及び請求項に使用する用語及び単語は、辞典的意味に限定されるものではなく、発明者により本発明の理解を明確且つ一貫性があるようにするために使用する。従って、特許請求の範囲とこれと均等なものに基づいて定義されるものであり、本発明の実施形態の説明が単に実例を提供するためのものであって、本発明の目的を限定するものでないことは、本発明の技術分野における通常の知識を持つ者には明らかである。

英文明細書に記載の“ａ”、“ａｎ”、及び“ｔｈｅ”、すなわち単数形は、コンテキスト中に特記で明示されない限り、複数形を含むことは、当業者には理解できるものである。したがって、例えば、“コンポーネント表面(a component surface)”との記載は一つ又は複数の表面を含む。

“実質的に(substantially)”という用語は、提示された特徴、パラメータ、又は値が正確に設定される必要はないが、許容誤差、測定誤り、測定精度限界及び当業者に知られているか、あるいは当業者によって実験なしに得られる要素を含む偏差又は変化が、これら特性が提供しようとする効果を排除しない範囲内で発生することを意味する。

後述する本発明の実施形態は、通信システムのデバイス管理(ＤＭ)のための技術に関する。より具体的には、本発明の実施形態は、通信システムにおけるＤＭをサポートするためにゲートウェイ機能を制御する技術に関するものである。通信システムにおけるＤＭをサポートするためにゲートウェイ機能を制御する技術が、ＯＭＡ-ＤＭバージョン２.０(以下、“ＤＭ２.０”と称する)及び/又はゲートウェイ管理オブジェクト(ＧｗＭＯ)イネーブラの状況で記述されるが、本発明は、他のＤＭ又は他のＯＭＡ-ＤＭバージョン及びイネーブラと同様に適用可能である。以下、通信システムにおいてＤＭをサポートするためのゲートウェイ装置は、ＤＭゲートウェイと称する。

用語“デバイス”が言及される場合、用語“デバイス”は、このデバイス上で実行される関連したＤＭクライアントを含むことができることに留意する。さらに、本発明の実施形態は、単一ＤＭサーバと与えられたＤＭゲートウェイに対する単一デバイスの状況で説明されるが、任意の数のＤＭサーバ及び/又はデバイスも与えられたＤＭゲートウェイとともに使用され得る。ＤＭゲートウェイは、物理的に通信システムのどこにも位置できるが、好ましくは、論理的にはＤＭサーバとデバイスとの間に配置される。

下記の説明は、単に説明の簡潔さのために様々な標準的に利用される技術用語を使用することを理解していただきたい。例えば、下記の説明は、ＯＭＡ-ＤＭ標準のようなに、ＯＭＡ標準のうちいずれか一つで使用される用語を使用する。しかしながら、この説明は、上記標準に限定されると解されてはならない。通信システムにおいて、ＤＭをサポートするためにゲートウェイ機能を制御するのに使用されるメカニズムとは独立的に、その能力のために標準化したメカニズムに合わせることが適している。

以下、本発明の実施形態によるＤＭゲートウェイの多様な役割及び新たな管理オブジェクト(ＭＯ)の機能について説明する。

ＤＭゲートウェイの役割
ＤＭゲートウェイは、ブートストラップサーバの役割、プロキシサーバの役割、及びプロトコル適応の役割を含む数多くの役割を遂行することができる。ブートストラップサーバの役割では、ＤＭゲートウェイは、デバイス上にＤＭクライアントをブートストラップ(すなわち、デバイスに関連したＤＭクライアントとＤＭサーバとの間の接続を設定)する責任がある。その中でも、ブートストラップサーバの役割は、デバイスのローカル送信アドレスをそのＷＡＮ(Wide Area Network)アドレスにマッピングすることである。ここで、デバイスのＬＡＮ(Local Area Network)アドレスは、ＷＡＮ上にルーティング可能でないこともあることに留意すべきである。一旦デバイスと関連するＤＭクライアントとＤＭサーバとの間の接続が設定されると、ＤＭゲートウェイは、デバイスの管理にもうこれ以上の役割をしない。

プロキシサーバの役割において、エンドユーザーデバイスとＤＭサーバとの間のすべての通信は、ＤＭゲートウェイを通してなされる。ここで、ＤＭゲートウェイは、デバイスに対するＤＭサーバの役割を果たし、ＤＭゲートウェイはデバイスの代わりに外部のＤＭサーバと通信する。

プロトコル適応の役割において、ＤＭゲートウェイは、上記したプロキシサーバ機能を提供する。また、ＤＭゲートウェイは、デバイスのネイティブ(native)管理プロトコルと、ＤＭサーバにより利用されるＯＭＡ-ＤＭプロトコルとの間で適応させる。

本発明の実施形態において、デバイスは、ＤＭゲートウェイが受信するサービス/能力広告(service/capability advertisement)メッセージを発行すると仮定する。ここで、サービス/能力広告メッセージは、サービス及び/又は能力を広告するデバイスが送信したいかなるメッセージ、又は類似した機能を遂行するいかなるメッセージを含むことを目的とする。サービス/能力広告メッセージは、デバイスのパワーオン及び/又は周期的に発行される。デバイス又はサービスを発見するためのメカニズムに対する詳細は、この開示の範囲を外れるので、簡潔さのために省略する。

新たなＭＯ機能
ＤＭゲートウェイが動作できる異なる役割を説明するために、新たなＭＯ機能が本発明の実施形態により適用される。これら新たなＭＯ機能は、ゲートウェイ構成(Ｃｏｎｆｉｇ)ＭＯ及びＬＡＮデバイスインベントリ(inventory)ＭＯを含む新たなＭＯによって例示される。用語“Ｃｏｎｆｉｇ ＭＯ”及び“ＬＡＮデバイスインベントリＭＯ”は、説明の便宜のために使用されるだけで、標準化団体が採択する名称によって変わることができる。また、Ｃｏｎｆｉｇ ＭＯ及びＬＡＮデバイスインベントリＭＯが説明の便宜のために別途のＭＯとして説明されるが、これらの集合的機能は異なる数のＭＯに分配され、及び/またはその集合的機能の全部または一部が他のＭＯに含まれることもできる。これら新たなＭＯは、デバイス発見、ＬＡＮ/ＷＡＮアドレスマッピング、管理プロトコル適応のような多くの特定の実施形態に対しての詳細が残されているが、ＤＭゲートウェイがサポートする必要のある機能的能力に焦点を合わせる。

ゲートウェイＣｏｎｆｉｇ ＭＯの機能は、異なるタイプのデバイスに対してＤＭアカウント(Ａｃｃ)を維持するものである。各ＤＭ Ａｃｃプロファイルは、該当ＤＭ Ａｃｃ ＭＯに含まれるものに類似した情報を含む。この情報は、ＤＭサーバ識別子(ＩＤ)、ＤＭサーバアドレス、及び認証情報を含んでいる。各ＤＭ Ａｃｃプロファイルは固有ＩＤを有し、複数のデバイスは同一のＤＭ Ａｃｃプロファイルを共有できる。各ＤＭ Ａｃｃプロファイルは、所定のデバイスタイプに特定され得る。各デバイスタイプに対して、ゲートウェイＣｏｎｆｉｇ ＭＯは、ＤＭサーバが特定タイプの新たなデバイスの検出時にコンタクトされなければならないか否かを示すブール(Boolean)フラグを含むことができる。ＤＭサーバは、ゲートウェイＣｏｎｆｉｇ ＭＯに対する読み取り-書き込みのアクセスを有する。

ＬＡＮデバイスインベントリＭＯの機能は、ＤＭゲートウェイが発見したＬＡＮにあるデバイスのリストを維持するものである。上記したように、ＤＭゲートウェイによるデバイス発見のためのメカニズムは、特定の実施形態に対しての他の詳細がに残されている。ゲートウェイＣｏｎｆｉｇ ＭＯとは違って、ＤＭサーバは、ＬＡＮデバイスインベントリＭＯに対する読み取り専用アクセスのみを有することができる。ＤＭゲートウェイがＬＡＮで新たなデバイスを発見する場合、ＬＡＮデバイスインベントリＭＯは、ＤＭゲートウェイ上で動作しているＤＭクライアントにより追加される。ＬＡＮデバイスインベントリＭＯがＬＡＮで発見された各デバイスに対して維持できる情報の例は、次のうち、一つ又はそれ以上を含む。

・デバイスタイプ及び/又はデバイスサブタイプ
・デバイスハードウェアアドレス(すなわち、ＭＡＣ(Media Access Control)アドレス、ＩＭＥＩ(International Mobile Equipment Identity)、ＭＥＩＤ(Mobile Equipment ID)など)
・ＤＭ ＡｃｃプロファイルＩＤ
・このデバイスに対してＤＭゲートウェイにより遂行される役割(すなわち、ブートストラップサーバ、プロキシサーバ、又はプロトコル適応)
・有効期間(すなわち、新たなハートビートタイムアウトメッセージがＤＭゲートウェイにより受信されない場合、デバイスエントリがインベントリから除去されるまでの時間)
・デバイスのＷＡＮとＬＡＮ側アドレスとの間のマッピング(ブートストラップサーバの役割のみの場合)
・ＤＭサーバ接続状態(すなわち、ＤＭサーバとの接続がうまく設定されたか否かを示す状態)
・進行中のＤＭトランザクション情報

実施形態による新たなＭＯを用いるＤＭゲートウェイ機能
以下、上述した新たなＭＯの機能を用いるＤＭゲートウェイ機能を含む本発明の実施形態について説明する。ＤＭゲートウェイデバイスが遂行する多様な役割に対する状況について、図４を参照して以下で説明する。

図４は、本発明の一実施形態による初期サービス/能力広告メッセージを処理するためのフローチャートである。

図４を参照すると、ＤＭゲートウェイは、ステップ４０２で、デバイスからサービス/能力広告メッセージを受信する。サービス/能力広告メッセージは、デバイスにより周期的に発行できることに留意する。ここで、ステップ４０２で、受信されたサービス/能力広告メッセージは、第１のサービス/能力広告メッセージであると仮定する。

ステップ４０４で、ＤＭゲートウェイは、デバイスがＤＭサーバに直接接続され、ＤＭゲートウェイをバイパス(bypass)するか否かを決定する。ここで、ＤＭゲートウェイは、デバイスをサービス/能力広告メッセージに含まれた情報を確認してＤＭサーバに直接接続するか否かを判定することができる。さらに、ＤＭサーバに直接接続されたデバイス(すなわち、ＤＭゲートウェイをバイパスするデバイス)は、サービス/能力広告メッセージを発行しないことにも留意する。また、ＤＭサーバに直接接続されたデバイスの場合、ＤＭゲートウェイは、ＬＡＮで該当デバイスを知っていないこともある。ＤＭゲートウェイは、デバイスがＤＭサーバに直接接続され、ＤＭゲートウェイをバイパスすると判定する場合、プロセスは終了する。一方、ＤＭゲートウェイは、デバイスがＤＭサーバに直接接続されず、ＤＭゲートウェイをバイパスしないと判定した場合、プロセスは、ステップ４０６に進行する。

ステップ４０６で、ＤＭゲートウェイは、デバイスがＯＭＡ-ＤＭをサポートするか否かを判定する。ここで、ＤＭゲートウェイは、サービス/能力広告メッセージに含まれた情報を確認することによってデバイスがＯＭＡ-ＤＭをサポートするか否かを判定できる。デバイスがＯＭＡ-ＤＭをサポートしないと判定される場合、ＤＭゲートウェイは、ステップ４０８で、プロトコル適応役割アルゴリズムを呼び出す。その後、プロセスは終了する。プロトコル適応役割アルゴリズムは、図７を参照して、以下に詳細に説明する。一方、デバイスがＯＭＡ-ＤＭをサポートするとＤＭゲートウェイが判定した場合、プロセスは、ステップ４１０に進行する。

ステップ４１０で、ＤＭゲートウェイは、デバイスがＤＭサーバにプロキシ接続のために構成されるか否かを判定する。ここで、ＤＭゲートウェイは、サービス/能力広告メッセージに含まれた情報を確認することによって、デバイスがＤＭサーバにプロキシ接続のために構成されるか否かを判定する。ＤＭゲートウェイは、デバイスがＤＭサーバにプロキシ接続のために構成されないと判定した場合、ステップ４１２で、ブートストラップサーバ役割アルゴリズムを呼び出す。その後、プロセスが終了する。以下に、ブートストラップサーバ役割アルゴリズムは、以下に図５を参照して詳細に説明する。一方、デバイスがＤＭサーバにプロキシ接続のために構成されるとＤＭゲートウェイが判定した場合、ＤＭゲートウェイは、ステップ４１４で、プロキシサーバ役割アルゴリズムを呼び出す。以後、プロセスを終了する。プロキシサーバ役割アルゴリズムは、図６を参照して、以下に詳細に説明する。

ここで、図４のフローチャートのステップは任意の順序でも呼び出すことに留意する。以下、ＤＭゲートウェイのブートストラップサーバの役割を図５を参照して説明する。

図５は、本発明の一実施形態によるブートストラップサーバ役割アルゴリズムを示すフローチャートである。

図５を参照すると、ＤＭゲートウェイは、ステップ５０２で、デバイスに対するＷＡＮ側アドレスを獲得する。ＤＭゲートウェイは、ＳＴＵＮ(Simple Traversal of User Datagram Protocol through NAT)、ＴＵＲＮ(Traversal Using Relay NAT)のようにすべての知られているＮＡＴ(Network Address Translation)トラバース方式を用い、あるいはこのような目的の権利化された方式を使用することができる。

ステップ５０４で、ＤＭゲートウェイは、ＬＡＮデバイスインベントリＭＯにデバイスに関する情報を追加する。ステップ５０６で、ＤＭゲートウェイは、ゲートウェイＣｏｎｆｉｇ ＭＯがこのデバイスタイプに対するブートストラップ情報を有するか否かを判定する。ゲートウェイＣｏｎｆｉｇ ＭＯがこのデバイスタイプに対してブートストラップ情報を有すると判定した場合、ＤＭゲートウェイは、プロセスをステップ５０８に進行する。ステップ５０８で、ＤＭゲートウェイは、ブートストラップ情報をデバイスに転送する。ステップ５１０で、ＤＭゲートウェイは、デバイスのＷＡＮ側アドレスをデバイスに転送する。その後、プロセスは終了する。一方、ゲートウェイＣｏｎｆｉｇ ＭＯがこのようなデバイスタイプに対するブートストラップ情報を有していないとＤＭゲートウェイが判定した場合、プロセスは、ステップ５１２に進行する。ステップ５１２で、ＤＭゲートウェイは、ＷＡＮ側アドレスのみをデバイスに転送することができる。以後に、プロセスは終了する。

ここで、ステップ５１０及び５１２は選択的であり、ステップ５１０及び５１２のうち一つ又はそれ以上は省略することができる。ステップ５１０及び５１２のうち一つ又はそれ以上が省略される場合、プロセスは、次のステップに進行する。

ＤＭゲートウェイのプロキシサーバの役割について、図６を参照して説明する。

図６は、本発明の一実施形態によるプロキシサーバ役割アルゴリズムを示すフローチャートである。

図６を参照すると、ＤＭゲートウェイは、ステップ６０２で、ＬＡＮデバイスインベントリＭＯにデバイスに関する情報を追加する。ステップ６０４で、ＤＭゲートウェイは、ＤＭゲートウェイのアドレスでデバイスをＤＭブートストラップする。ステップ６０６で、ＤＭゲートウェイは、デバイスにより発行されたサービス/能力広告メッセージがブートストラップ情報を含むか否かを判定する。デバイスにより発行されたサービス/能力広告メッセージがブートストラップ情報を含んでいないとＤＭゲートウェイが判定した場合、プロセスは、ステップ６０８に進行する。

ステップ６０８で、ＤＭゲートウェイは、このようなデバイスタイプに対するＤＭブートストラップ情報がゲートウェイＣｏｎｆｉｇ ＭＯにあるか否かを判定する。ＤＭゲートウェイは、このデバイスタイプに対するＤＭブートストラップ情報がゲートウェイＣｏｎｆｉｇＭＯに存在しないと判定した場合、プロセスは終了する。一方、このデバイスタイプに対するＤＭブートストラップ情報がゲートウェイＣｏｎｆｉｇＭＯに存在するとＤＭゲートウェイが判定した場合、プロセスは、ステップ６１０に進行する。ステップ６１０で、ＤＭゲートウェイは、ゲートウェイＣｏｎｆｉｇ ＭＯによって提供されたような、正確なＤＭ ＡｃｃプロファイルＩＤでＬＡＮデバイスインベントリＭＯでデバイスに対するエントリを更新できる。その後、プロセスは、さらに後述されるステップ６１６に進行する。

ステップ６０６に戻り、デバイスが発行したサービス/能力広告メッセージがブートストラップ情報を含んでいるとＤＭゲートウェイが判定した場合、プロセスは、ステップ６１２に進行する。ステップ６１２で、ＤＭゲートウェイは、ゲートウェイＣｏｎｆｉｇ ＭＯに新たなＤＭ Ａｃｃプロファイルを生成できる。ステップ６１４で、ＤＭゲートウェイは、ＬＡＮデバイスインベントリＭＯのデバイスエントリを新たなＤＭ ＡｃｃプロファイルＩＤに更新できる。その後、プロセスは、ステップ６１６に進行する。

ステップ６１６で、ＤＭゲートウェイは、該当するデバイスタイプに対する“Ｉｎｆｏｒｍ ＤＭ Ｓｅｒｖｅｒ”フラグが真であるか否かを判定する。ＤＭゲートウェイは、フラグが真に設定されていないと判定した場合、プロセスは終了する。一方、フラグが真に設定されていると判定した場合、ＤＭゲートウェイは、ステップ６１８で、適切な認証情報を用いてデバイスの代わりにＤＭサーバとの通信を試す。ステップ６２０で、ＤＭゲートウェイは、ＤＭサーバとの試みた通信の状態に基づいて、ＬＡＮデバイスインベントリＭＯのこのようなデバイスに対するＤＭサーバ接続属性を更新できる。以後に、プロセスは終了する。

ここで、ステップ６１０〜６１４及びステップ６２０は、選択的であるので、ステップ６１０〜６１４及びステップ６２０のうち一つ又はそれ以上が省略され得る。ステップ６１０〜６１４及びステップ６２０のうち一つ又はそれ以上が省略されると、プロセスは次のステップに進行する。

以下、このＤＭゲートウェイのプロトコル適応の役割について、図７を参照して説明する。

図７は、本発明の一実施形態によるプロトコル適応役割アルゴリズムを実現するＤＭゲートウェイ上で実行される機能を示すフローチャートである。

図７を参照すると、ＤＭゲートウェイは、ステップ７０２で、ＬＡＮデバイスインベントリＭＯのデバイスに関する情報を付加する。ステップ７０４で、ＤＭゲートウェイは、このデバイスタイプに対するＤＭブートストラップ情報がゲートウェイＣｏｎｆｉｇ ＭＯに存在するか否かを判定する。このようなデバイスタイプに対するＤＭブートストラップ情報がゲートウェイＣｏｎｆｉｇ ＭＯに存在しないとＤＭゲートウェイが判定した場合、プロセスは終了する。一方、このデバイスタイプに対するＤＭブートストラップ情報がゲートウェイＣｏｎｆｉｇ ＭＯに存在すると判定した場合、ＤＭゲートウェイは、プロセスをステップ７０６に進行する。ステップ７０６で、ＤＭゲートウェイは、ゲートウェイＣｏｎｆｉｇ ＭＯによって提供されるような正確なＤＭ ＡｃｃプロファイルＩＤでＬＡＮデバイスインベントリＭＯのデバイスに対するエントリを更新する。ステップ７０８で、ゲートウェイは、該当するデバイスタイプに対する“Ｉｎｆｏｒｍ ＤＭ Ｓｅｒｖｅｒ”フラグが真であるか否かを判定する。ＤＭゲートウェイがこのフラグが真に設定されないと判定した場合、プロセスは終了する。一方、ＤＭゲートウェイがフラグが真に設定されていると判定した場合、プロセスは、ステップ７１０に進行する。ステップ７１０で、ＤＭゲートウェイは、適切な認証情報を用いてデバイスの代わりにＤＭサーバとの通信を試みる。ステップ７１２で、ＤＭゲートウェイは、ＤＭサーバとの試みた通信の状態に基づいて、ＬＡＮデバイスインベントリＭＯのデバイスに対するＤＭサーバ接続属性を更新する。その後、プロセスは終了する。

ここで、ステップ７０６及び７１２は選択的であるので、これらのうち一つ又はそれ以上が省略され得る。ステップ７０６及び７１２のうち一つ又はそれ以上が省略される場合には、プロセスは、次のステップに進行する。

上記したように、ＤＭ Ａｃｃプロファイルは、相互に異なるデバイスタイプに対する一つ又はそれ以上のＭＯにより維持される。ゲートウェイＣｏｎｆｉｇ ＭＯでＤＭ Ａｃｃプロファイルを更新するアルゴリズムについて、図８を参照して説明する。

図８は、本発明の一実施形態による特定デバイスタイプに対するブートストラップ情報を更新する手順を示すフローチャートである。

図８を参照すると、ＤＭゲートウェイは、ステップ８０２で、特定デバイスタイプに対するブートストラップ更新メッセージを受信する。ステップ８０４で、ＤＭゲートウェイは、ブートストラップ更新メッセージに特定されているデバイスタイプ又はブートストラップ情報を更新する。ステップ８０６で、ＤＭゲートウェイは、ＬＡＮデバイスインベントリＭＯの次のエントリを選択する。ここで、その直前のステップがステップ８０４であると、ＬＡＮデバイスインベントリＭＯで選択されたエントリは、第１のエントリである。

ステップ８０８で、ＤＭゲートウェイは、ＬＡＮデバイスインベントリＭＯをスキャンし、ＬＡＮインベントリＭＯのデバイスに対するデバイスタイプとブートストラップ更新メッセージに特定されているデバイスタイプが一致するか否かを判定する。ＤＭゲートウェイが一致しないと判定する場合、プロセスは、後述されるステップ８１６に進行する。その一方、ＤＭゲートウェイが一致すると判定した場合には、プロセスは、ステップ８１０に進行する。

ステップ８１０で、ＤＭゲートウェイは、自身がデバイスに対するブートストラップサーバの役割にあるか否かを判定する。ＤＭゲートウェイは、自身がデバイスに対するブートストラップサーバの役割に存在しないと判定した場合、プロセスを下記のステップ８１４に進行する。一方、自身がデバイスに対するブートストラップサーバの役割にあるとＤＭゲートウェイが判定した場合、プロセスは、ステップ８１２に進行する。ステップ８１２で、ＤＭゲートウェイは、更新されたＤＭブートストラップ情報をデバイスに転送(push)する。ステップ８１４で、ＤＭゲートウェイは、ＬＡＮデバイスインベントリＭＯの影響を受けるデバイスに対するエントリを更新する。ここで、ステップ８１４は、選択的であるので、省略され得る。ステップ８１４が省略される場合、プロセスは、ステップ８１６に進行する。ステップ８１６で、ＤＭゲートウェイは、他のエントリがあるか否かを判定する。ＤＭゲートウェイが他のエントリがあると判定する場合、プロセスは、ステップ８０６に戻り、そうでない場合には、プロセスは終了する。

ＤＭゲートウェイがプロキシサーバの役割又はプロトコル適応の役割にある場合に、エンドユーザーデバイスを目的地とするＤＭコマンドを処理するアルゴリズムは、以下に、図９を参照して説明する。

図９は、本発明の一実施形態により、ＤＭゲートウェイがプロキシサーバの役割又はプロトコル適応の役割にある場合、エンドユーザーデバイスを目的地とするＤＭゲートウェイでＤＭコマンドの処理を手順を示すフローチャートである。

図９を参照すると、ＤＭゲートウェイは、ステップ９０２で、ＤＭサーバからＬＡＮデバイスをターゲットとするＤＭコマンドを受信する。ステップ９０４で、ＤＭゲートウェイは、ターゲットデバイスがＬＡＮデバイスインベントリＭＯにあるか否かを判定する。ターゲットデバイスがＬＡＮデバイスインベントリＭＯに存在しないとＤＭゲートウェイが判定した場合、ステップ９０６で、失敗応答は、ＤＭサーバに送信される。その後、プロセスは終了する。一方、ターゲットデバイスがＬＡＮデバイスインベントリＭＯにあるとＤＭゲートウェイが判定した場合には、プロセスは、ステップ９０８に進行する。

ステップ９０８で、ＤＭゲートウェイは、自身がプロトコル適応の役割にあるか否か判定する。ＤＭゲートウェイがプロトコル適応の役割に自身が存在しないと判定する場合、プロセスは、後述されるステップ９１２に進行する。一方、ＤＭゲートウェイは、プロトコル適応の役割に自身があると判定した場合、ステップ９１０で、デバイスによって元々サポートされる管理プロトコルにＤＭコマンドを適応させ、ステップ９１２に進行する。ステップ９１２で、このコマンドは、デバイスに転送される。ステップ９１４で、ＤＭゲートウェイは、転送されたコマンドに対する応答を待機し、応答が受信されたか否かを判定する。応答が所定期間内に受信されない場合には、ＤＭゲートウェイは、ステップ９１６でＤＭサーバに失敗応答を送信する。以後、プロセスは、終了する。一方、所定期間内に応答が受信される場合、ＤＭゲートウェイは、ステップ９１８に進行する。
ステップ９１８で、ＤＭゲートウェイは、自身がプロトコル適応の役割にあるか否かを判定する。デバイスがＯＭＡ-ＤＭをサポートしない場合、ＤＭゲートウェイは、プロトコル適応の役割担うことができる。ＤＭゲートウェイは、自身がプロトコル適応の役割にないと判定した場合、以下に説明されるステップ９２２に進行する。その反面、ＤＭゲートウェイは、自身がプロトコル適応の役割にあると判定した場合、ステップ９２０で応答をＯＭＡ-ＤＭに適応させ、ステップ９２２に進行する。ステップ９２２で、ＤＭゲートウェイは、応答をＤＭサーバに転送する。その後、プロセスは終了する。

非要求(unsolicited)メッセージ(又はトラップメッセージ)の処理について、図１０を参照して説明する。

図１０は、本発明の一実施形態によるＤＭゲートウェイでのトラップメッセージの処理を示すフローチャートである。

図１０を参照すると、ＤＭゲートウェイは、ステップ１００２で、デバイスに対するトラップメッセージ(非要求メッセージ)を受信する。ステップ１００４で、ＤＭゲートウェイは、デバイスが現在ＬＡＮデバイスインベントリＭＯに存在するか否かを判定する。デバイスが現在ＬＡＮデバイスインベントリＭＯに存在するとＤＭゲートウェイが判定した場合、プロセスは、以下に、さらに説明されるステップ１０１２に進行する。一方、デバイスが現在ＬＡＮデバイスインベントリＭＯに存在しないとＤＭゲートウェイが判定した場合、プロセスは、ステップ１００６に進行する。ステップ１００６で、ＤＭゲートウェイは、トラップメッセージがＯＭＡ-ＤＭメッセージであるか否かを判定する。トラップメッセージがＯＭＡ-ＤＭメッセージであると判定した場合、ＤＭゲートウェイは、ステップ１００８で、デバイスをＬＡＮデバイスインベントリＭＯに追加してプロキシサーバの役割アルゴリズムを呼び出し、ステップ１０１２に進行する。一方、トラップメッセージがＯＭＡ-ＤＭメッセージでないと判定した場合、ＤＭゲートウェイは、ステップ１０１０で、デバイスをＬＡＮデバイスインベントリＭＯに追加してプロトコル適応の役割アルゴリズムのＤＭゲートウェイを呼び出し、ステップ１０１２に進行する。
ステップ１０１２で、ＤＭゲートウェイは、デバイスからのトラップメッセージに(すなわち、ＤＭサーバに対する)目的地情報があるか否かを判定する。デバイスからのトラップメッセージに目的地情報がないとＤＭゲートウェイが判定した場合、プロセスは、ステップ１０１４に進行する。ステップ１０１４で、ＤＭゲートウェイは、トラップに対する目的地情報のロケーティング(locating)を試す。ＤＭゲートウェイが目的地情報を判定できない場合、プロセスは終了する。一方、ＤＭゲートウェイがトラップ目的地情報を判定できる場合、ＤＭゲートウェイは、ステップ１０１６で、ゲートウェイＣｏｎｆｉｇ ＭＯから該当ＤＭサーバ情報を読み取ることができ、すると、プロセスは、後述されるステップ１０２２に進行する。ここで、ステップ１０１６は、選択的であるので省略され得る。ステップ１０１６が省略されると、プロセスは、ステップ１０２２に進行する。

ステップ１０１２に戻り、ＤＭゲートウェイがデバイスからのトラップメッセージに目的地情報が存在すると判定した場合、プロセスは、ステップ１０１８に進行する。ステップ１０１８で、ＤＭゲートウェイは、自身がプロトコル適応の役割にあるか否かを判定する。自身がプロトコル適応の役割にないとＤＭゲートウェイが判定した場合、プロセスは、ステップ１０２２に進行する。一方、自身がプロトコル適応の役割にあると判定した場合、ＤＭゲートウェイは、ステップ１０２０で、デバイスからのメッセージをＯＭＡ-ＤＭフォーマットに適応させ、プロセスはステップ１０２２に進行する。ステップ１０２２で、ＤＭゲートウェイは、メッセージを該当ＤＭサーバに転送する。以後、プロセスは終了する。

上記したように、デバイスは、サービス/能力広告をパワーオン時だけでなく、周期的に発行することができる。図１１を参照して、周期的なサービス/能力広告を受信する実施形態を説明する。

図１１は、本発明の一実施形態によるＤＭゲートウェイでの周期的サービス/能力メッセージの処理手順を示すフローチャートである。

図１１を参照すると、ＤＭゲートウェイは、ステップ１１０２で、デバイスから周期的なサービス/能力メッセージを受信する。ステップ１１０４で、ＤＭゲートウェイは、ＬＡＮデバイスインベントリＭＯのデバイスに対する“有効時間”を再設定する。このメカニズムは、デバイスが故障し、バッテリーが切れ、あるいはＤＭゲートウェイの管轄権を外れるなどのＭＯのエントリに対するリンガリング(lingering)を避ける。その後、プロセスは終了する。

図１２を参照して、ＤＭゲートウェイでのハートビートタイムアウトメッセージ処理の実施形態について説明する。

図１２は、本発明の一実施形態によるＤＭゲートウェイでのハートビートタイムアウトメッセージ処理を示すフローチャートである。

図１２を参照すると、ステップ１２０２で、ハートビートタイマが経過する。ステップ１２０４で、ＤＭゲートウェイは、ＬＡＮインベントリＭＯの次のデバイスエントリを選択する。ここで、まだどのデバイスも選択されたことがないと、最初のデバイスが選択される。ステップ１２０６で、ＤＭゲートウェイは、選択されたデバイスに対する“有効時間”が経過したか否かを判定する。選択されたデバイスに対する“有効時間”が経過しないとＤＭゲートウェイが判定する場合、プロセスは、以下にさらに説明されるステップ１２１０に進行する。一方、選択されたデバイスに対する“有効時間”が経過したとＤＭゲートウェイが判定する場合、プロセスは、ステップ１２０８に進行する。ステップ１２０８で、ＤＭゲートウェイは、ＬＡＮインベントリＭＯから選択されたデバイスのエントリを削除し、プロセスはステップ１２１０に進行する。ステップ１２１０で、ＤＭゲートウェイは、ＬＡＮインベントリＭＯにもう他のエントリが存在するか否かを判定する。ＬＡＮインベントリＭＯに他のエントリが存在するとＤＭゲートウェイが判定した場合、プロセスはステップ１２０４に戻る。一方、ＬＡＮインベントリＭＯに他のエントリがないとＤＭゲートウェイが判定した場合、プロセスはステップ１２０２に戻る。

図１３を参照して、本発明の一実施形態によるＤＭゲートウェイデバイスの構成について説明する。

図１３は、本発明の一実施形態によるＤＭゲートウェイを示すブロック構成図である。

図１３を参照すると、ＤＭゲートウェイ１３０２は、プロセッサ１３０４、メモリ１３０６、及び通信部１３０８を含む。ＤＭゲートウェイ１３０２は、他の追加的な構成要素を含むことができる。しかしながら、このＤＭゲートウェイ１３０２の追加的な構成要素に関する説明は、簡潔さのために省略する。

プロセッサ１３０４は、ＤＭゲートウェイ１３０２の一般的な動作を処理するのに使用され、ＤＭゲートウェイにより遂行されると明示的又は暗に説明された機能/動作/アルゴリズム/役割のうちいずれかを遂行するためのコードを実行するために使用することができる。また、プロセッサ１３０４は、メモリ１３０６及び/又は通信部１３０８と通信及び/又は制御を遂行することができる。ここで、用語“コード”は、メモリ１３０６に格納される実行可能な指示、オペランド(operand)データ、構成パラメータ、及び他の情報のうち一つ又はそれ以上を表すために使用することができる。

メモリ１３０６は、ＤＭゲートウェイが遂行すると明示的又は暗に説明された機能/動作/アルゴリズム/役割のうちいずれかを遂行するためにプロセッサ１３０４により処理されるコードを格納することができる。さらに、実行可能な指示、オペランドデータ、構成パラメータ、及び他の情報のうち一つ又はそれ以上は、メモリ１３０６に格納することができる。ＤＭゲートウェイ１３０２の正確な構成に基づき、メモリ１３０６は、(ＲＡＭ(Random-Access Memory)のような)揮発性、(ＲＯＭ(Read-Only Memory)、フラッシュメモリのような)非揮発性、あるいはこれら両方の特定組み合わせであり得る。

通信部１３０８は、デバイス、ＤＭサーバ、及び他のエンティティのうち一つ又はそれ以上の間でデータを送受信する。この通信部１３０８は、有線又は無線のように、すべてのタイプの送受信器、受信器、及び送信器を複数含むことができる。

上記した本発明による実施形態は、コンピュータ読み取り可能な記録媒体に対するコンピュータ読み取り可能なコードとして実施されることができる。このコンピュータ読み取り可能な記録媒体は、コンピュータシステムによって読み取り可能なデータを格納するデータストレージデバイスとなり得る。コンピュータ読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ-ＲＯＭ、磁気テープ、フロッピーディスク、光データ格納装置、及び搬送波(有無線伝送経路を介してインターネットを経由するデータ伝送のような)を含むが、これに限定されることではない。また、このコンピュータ読み取り可能な記録媒体を、ネットワーク接続されたコンピュータシステムにわたって分布することによって、コンピュータ読み取り可能なコードは分布した形で格納及び遂行される。また、本発明を達成するための機能(function)プログラム、コード、及びコードセグメントは、当該技術分野における技術に長けたプログラマにとっては容易に理解できることである。

以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。

１００ ・・・ デバイス
１１０ ・・・ ＤＭクライアント
１２０ ・・・ ＤＭ標準ＭＯ
１４０ ・・・ ＤＭサーバ

Claims (28)

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. 前記ＤＭゲートウェイにより、前記デバイスに対するプロトコル適応の役割を遂行するか否かを判定するステップと、
    前記ＤＭゲートウェイが前記デバイスに対するプロトコル適応の役割を遂行すると判定した場合、前記トラップメッセージが前記ＤＭサーバに送信される前に、前記トラップメッセージを前記ＤＭサーバによってサポートされるプロトコルに適応させるステップをさらに有することを特徴とする請求項２３に記載の方法。
27. 通信システムにおけるデバイス管理(ＤＭ)ゲートウェイが周期的なサービス/能力広告メッセージを処理する方法であって、
    前記ＤＭゲートウェイにより、デバイスから周期的サービス/能力広告メッセージを受信するステップと、
    前記ＤＭゲートウェイにより、ローカルエリアネットワーク(ＬＡＮ)デバイスインベントリ管理オブジェクト(ＭＯ)の前記デバイスに対する有効時間を再設定するステップと、
    を有することを特徴とする方法。
28. 通信システムにおけるデバイス管理(ＤＭ)ゲートウェイがハートビートタイムアウトを処理する方法であって、
    前記ＤＭゲートウェイにより、ハートビートタイマが経過したか否かを判定するステップと、
    前記ハートビートタイマが経過したと判定する場合、ローカルエリアネットワーク(ＬＡＮ)デバイスインベントリ管理オブジェクト(ＭＯ)で、前記ＤＭゲートウェイにより、有効時間が経過したデバイスのエントリを削除するステップと、
    を有することを特徴とする方法。

Images