通信システムにおけるデバイス管理をサポートするためにゲートウェイ機能を制御する技術
本発明は、デバイス管理(DM)サーバが直接制御できないDMゲートウェイ、DMサーバ及びエンドデバイスを含む通信システムにおいて、デバイスがDMゲートウェイを通じてDMサーバにより管理されるようにDMゲートウェイを運用する方法、通信システムでDMゲートウェイが特定クラスのデバイスに対するブートストラップ情報を更新する方法、DMゲートウェイがDMコマンドを処理する方法、DMゲートウェイがトラップメッセージを処理する方法、DMゲートウェイが周期的サービス/能力広告メッセージを処理する方法と、及びDMゲートウェイがハートビートタイムアウトを処理する方法を提供する。DMゲートウェイ、DMサーバ及びデバイスを含む通信システムにおけるDMゲートウェイを運用する方法は、DMゲートウェイがデバイスからサービス/能力広告メッセージを受信するステップと、DMゲートウェイが受信されたサービス/能力広告メッセージに含まれた情報に基づいてデバイスのうち一つ又はそれ以上の特徴を決定するステップと、DMゲートウェイがデバイスの決定された一つ又はそれ以上の特徴に基づいてアルゴリズムを呼び出すステップとを有し、DMゲートウェイは、呼び出されたアルゴリズムにより動作し、DMサーバがDMゲートウェイを通じてデバイスに管理コマンドを送信し、DMゲートウェイを通じてデバイスから受信された警告を処理することで、上記デバイスを管理できる。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は通信システムにおけるデバイス管理(Device Management:DM)に関するもので、特に、通信システムにおけるDMをサポートするためにゲートウェイ機能を制御する技術に関する。
【背景技術】
【0002】
ユビキタス(ubiquitous)通信技術及びシステムが成長するにつれて、デバイスの機能及び複雑性が増加する。しかしながら、デバイスの機能及び複雑性の増加とともに、デバイス管理のための必要性も増加している。このような要求を解決するために、OMA(Open Mobile Alliance)は、デバイスを管理するためのプロトコル及びメカニズムを特定するためにデバイス管理(DM)ワーキンググループを組織した。OMA DMワーキンググループは、デバイスの遠隔管理に使用されるデバイスに関連したDMクライアントとDMサーバとの間の双方向プロトコルを定義するOMA-DM仕様を開発した。DMサーバとDMクライアントとの間の関連インスタンス(instance)はDMセッションと呼ばれ、DMクライアント又はDMサーバによって開始される。DMクライアントはデバイス内に存在し、DMサーバはDMクライアント上にコマンドを呼び出してデバイスを管理する。DMクライアントは、コマンドを処理して応答をDMサーバに送信する。サーバとクライアントとの間の通信は、SyncML(Synchronization Markup Language)メッセージの交換を含む。一般的に、デバイスは無線デバイスであったが、最近では、OMA-DMが有線デバイスの遠隔管理を解決し始めた。OMA-DMの例は、デバイスの初期構成情報の設定、デバイスの永続的な(persistent)情報の後続設置及び更新、デバイスからの管理情報検索、及びデバイスによって生成されるイベント及びアラームの処理を含む。
【0003】
以下では、図1を参照して、OMA-DM構成の実施形態を説明する。
【0004】
図1を参照すると、OMA-DM構成は、DMサーバ140、DMクライアント110、及びDM標準管理オブジェクト(Management Object:MO)120を含む。DMクライアント110とDM標準MO120は、デバイス100内に同一の場所に位置する。OMA-DM構成は、追加的な構造的要素を含むことができる。しかしながら、OMA-DM構成の追加的な構成要素に関する説明は、簡潔性のために省略する。
【0005】
上記したDMサーバ140及びDMクライアント110は、インターフェースDM-1 130とDM-2 132を通じて通信する。DMクライアント110は、インターフェースDM-5 134を通じてDM標準MO120と通信する。
【0006】
DMプロトコルは、DMクライアント110のすべての実施形態がサポートしなければならない3個の標準MO120を定義する。これらDM標準MO120は、DMアカウント(Acc)MO122、デバイス情報(DevInfo)MO124、及びデバイス詳細(DevDetail)MO126を含む。
【0007】
DM Acc MO122は、ブートストラップされたDMサーバ140に関する情報を管理するために使用される。DMデバイス110に対して、間違いなくブートストラップされた各DMサーバ140において、DM Acc MO122は、DMサーバ識別子(ID)、接続(connectivity)情報、サーバアドレス、サーバ及びクライアント認証情報(credentials)などに関する情報を維持する。DevInfo MO124は、DMクライアント110に関連したデバイス100に関する基本情報を提供する。この基本情報は、デバイスID、デバイス製造業者ID、モデルID、及び言語設定を含む。DevDetail MO126は、DMクライアント110に関連したデバイス100に関する付加情報を提供する。この付加情報は、デバイスタイプ、OEM(Original Equipment Manufacturer)、ハードウェアバージョン、ファームウェアバージョン、ソフトウェアバージョン、デバイス100のオプション特性(例えば、ラージオブジェクト(large-object)取扱能力)をサポートするか否かの表示、管理ツリーの最大深さ、URI(Uniform Resource ID)の最大総長、及びURIセグメントの最大総長を含む。
【0008】
以下、OMA-DMを採用する通信システムの実施形態について、図2を参照して説明する。
【0009】
図2を参照すると、OMA-DMを採用する通信システムの実施形態は、有線ネットワーク200、無線ネットワーク202、有線デバイス210、無線デバイス212、DMサーバ220、及びDM管理者(authority)230を含む。有線デバイス210及び無線デバイス212の各々は、DMクライアント(図示せず)と関連付けられる。また、DM管理者230は、OSS(Operations Support System)であり得る。図2で、実線は物理的接続(physical connectivity)を示し、点線は論理的接続(logical connectivity)を示す。
【0010】
図2に示すOMA-DMを採用する通信システムの実施形態は、複数の可能な実施形態のうち一つに過ぎない。例えば、有線ネットワーク200と無線ネットワーク202のうちいずれか一つが省略され得る。あるいは、有線ネットワーク200と無線ネットワーク202は、結合することもできる。また、DMサーバ220とDM管理者230は有線ネットワーク200に接続されているように示されているが、DMサーバ220とDM管理者230のうち一つ又は両方ともが、無線ネットワーク202に接続することもできる。
【0011】
図2に示す通信システムにおけるOMA-DMを容易にするために、OMA-DM仕様に基づいた双方向プロトコルは、DMサーバ220と無線デバイス212に関連付けられるDMクライアントとの間と、DMサーバ220と有線デバイス210に関連付けられるDMクライアントとの間で、利用される。DM管理者230は、有線デバイス210と無線デバイス212のそれぞれに関連したDMクライアントのDM動作をDMサーバ220を通じて指示できる。DMサーバ220と有線デバイス210と無線デバイス212のそれぞれに関連したDMクライアントとの間の相互交信(interaction)のみがOMA-DM仕様の範囲内にある。
【0012】
DMクライアントとDMサーバ開始されるDMセッションに対する実施形態は、図3を参照して説明する。
【0013】
図3は、関連技術によるところの通信システムにおけるDMクライアントとDMセッションが開始されるDMサーバに対する信号フローを示す。
【0014】
図3を参照すると、DMサーバ302とDMクライアント304との間のDMセッションが開始されたDMサーバは、2つの段階を踏む。第1の段階は、設定段階310であり、第2の段階は管理段階320である。設定段階310は、認証及びデバイス情報のための情報の交換を含む。設定段階310での情報の交換は、各々複数のメッセージが含まれる3個のパッケージ、すなわちパッケージ0 312、パッケージ1 314、及びパッケージ2 316を含む。パッケージ0 312は、DMサーバ302からDMクライアント304に送信され、通知メッセージと呼ばれる。パッケージ1 314は、DMクライアント304からDMサーバ302に送信される。パッケージ1 314は、クライアント開始情報とデバイス情報を含む。クライアント開始情報は、クライアント認証情報を含む。パッケージ2 316は、DMサーバ302からDMクライアント304に送信される。パッケージ2 316は、サーバ開始情報と初期管理動作を含む。サーバ開始情報は、一つ又はそれ以上のサーバ認証情報を含む。
【0015】
管理ステップ320は、2個のパッケージ、すなわちパッケージ3 322とパッケージ4 324との交換を含む。パッケージ3 322は、DMクライアント304からDMサーバ302に送信される。パッケージ3 322は、パッケージ2316によってトリガーされる管理動作に関するクライアント応答情報を含む。パッケージ4 324は、DMサーバ302からDMクライアント304に送信される。DMセッションがパッケージ2のメッセージ316以降も続行される場合、パッケージ4 324は、追加的な管理動作と一つ又はそれ以上の追加的なユーザー相互交信コマンドのうち少なくとも一つを含む。パッケージ3のメッセージ322とパッケージ4のメッセージ324の付加的なサイクルは、DMセッションが終了するまでDMサーバ302とDMクライアント304との間に送信される。
【0016】
現在公開されているOMA-DM標準バージョンは、バージョン1.2.1である。OMA-DMワーキンググループは、現在2個の新たなDMプロトコルバージョン、すなわちOMA-DMバージョン1.3とOMA-DMバージョン2.0を開発中である。OMA-DMバージョン1.3は、OMA-DMバージョン1.2.1でのセキュリティ脆弱性のうち一部を解決するために開発されている。
【0017】
しかしながら、OMA-DMの新たなバージョンの開発は、DMワーキンググループによって解決される必要があるいくつかの新たな課題が提示する。例えば、OMA-DMバージョン1.2.1とは異なり、新たなOMA-DMバージョンにより管理されるデバイスは、世界的にルーティング可能なアドレスを有していないこともある。この主な原因は、セキュリティの理由のために、新たなOMA-DMバージョンでターゲットとなるデバイスのうち大部分がNAT(Network Address Translation)及び/又はファイアウォール機能を提供するデバイスの後に公開されるためである。また、このデバイスの大部分は移動性を持ち、そのアドレスは自身が配置されているネットワークにより制御される。新たなOMA-DMバージョンによる他の課題は、このデバイスの一部がOMA-DMクライアントを内蔵しないこともある。
【0018】
ゲートウェイ装置が、上記した課題の一部を解決するために研究されている。ゲートウェイ装置は、DMサーバとDMクライアントとの間の自力での(unaided)相互交信が可能でない状況で、少なくとも一つがOMA-DMを駆動するDMサーバとDMクライアントとの間の相互交信を容易にする実体(entity)である。
【0019】
現在OMA-DMパラダイムとは違って、ゲートウェイ装置は、新たなOMA-DMバージョンでデバイス管理の重要な役割をすると予想される。したがって、新たなOMA-DMバージョンとの利用のためにゲートウェイMO(GwMO)イネーブラが開発中である。
【0020】
したがって、通信システムにおけるDMをサポートするためにゲートウェイ機能を制御するための技術の需要がある。
【発明の概要】
【発明が解決しようとする課題】
【0021】
したがって、本発明は上記した従来技術の問題点に鑑みてなされたものであって、その目的は、通信システムにおけるDMをサポートするためのゲートウェイ機能を制御するための技術を提供することにある。
【課題を解決するための手段】
【0022】
このような目的を達成するために、本発明の一態様によれば、DMゲートウェイ、DMサーバ、及びデバイスを含む通信システムにおけるDMゲートウェイを運用する方法が提供される。その方法は、DMゲートウェイにより、新たな管理可能なデバイスを検出するステップと、DMゲートウェイにより、デバイスの一つ又はそれ以上の特徴を決定するステップと、DMゲートウェイにより、デバイスの決定された一つ以上の特徴に基づいてアルゴリズムを呼び出すステップとを有し、DMゲートウェイは、呼び出したアルゴリズムによって動作し、それによってDMサーバは、DMゲートウェイを通じてデバイスに管理コマンドを送信し、DMゲートウェイを通じてデバイスから受信された警告を処理することによってデバイスを管理できる。
【0023】
本発明の他の態様によれば、DMゲートウェイ、DMサーバ、及びデバイスを含む通信システムにおけるDMゲートウェイを運用する方法が提供される。その方法は、DMゲートウェイにより、デバイスからサービス/能力広告メッセージ(capability advertisement message)を受信するステップと、DMゲートウェイにより、サービス/能力広告メッセージに基づいてデバイスがDMサーバによって使用されるDMプロトコルをサポートするか否かを判定するステップと、デバイスがDMサーバによって使用されるDMプロトコルをサポートしないと判定した場合、デバイスに対するInform DMサーバフラグがゲートウェイ構成(Config)MOで真に設定されるか否かを判定するステップと、Inform DMサーバフラグが真に設定されると判定した場合、デバイスの代わりにDMサーバとの通信を試してローカルエリアネットワーク(LAN)デバイスインベントリMOのデバイスに対するDMサーバ接続属性を更新するステップとを有する。
【0024】
また、本発明の他の態様によれば、通信システムにおけるDMゲートウェイが特定クラスのデバイスに対するブートストラップ情報を更新する方法が提供される。その方法は、DMゲートウェイにより、特定クラスのデバイスに対するブートストラップ情報を受信するステップと、DMゲートウェイにより、特定クラスのデバイスに対するブートストラップ情報を更新するステップと、DMゲートウェイにより、デバイスタイプが更新されたブートストラップ情報のデバイスタイプと一致するデバイスに対するLANデバイスインベントリMOを検索するステップとを有する。
【0025】
さらに、本発明の他の態様によれば、通信システムにおけるDMゲートウェイがDMコマンドを処理する方法が提供される。その方法は、DMゲートウェイにより、DMサーバからデバイスに対するDMコマンドを受信するステップと、DMゲートウェイにより、LANデバイスインベントリMOにデバイスに対するエントリが存在するか否かを判定するステップと、LANデバイスインベントリMOにデバイスに対するエントリが存在すると判定した場合、DMゲートウェイにより、デバイスにDMコマンドを送信して所定時間内で応答を待機するステップと、応答が所定時間内に受信される場合、DMゲートウェイにより、DMサーバに応答を送信するステップとを有する。
【0026】
本発明の他の態様によれば、通信システムのDMゲートウェイがトラップメッセージを処理する方法が提供される。その方法は、DMゲートウェイにより、デバイスからトラップメッセージを受信するステップと、DMゲートウェイにより、LANデバイスインベントリMOにデバイスに対するエントリがあるか否かを判定するステップと、LANデバイスインベントリMOにデバイスに対するエントリがないと判定した場合、DMゲートウェイにより、プロキシサーバの役割及びプロトコル適応の役割のうちいずれか一つを呼び出し、受信されたトラップメッセージ内にDMサーバを識別する目的地情報があるか否かを判定するステップと、LANデバイスインベントリMOにデバイスに対するエントリがあると判定した場合、DMゲートウェイにより、受信されたトラップメッセージ内にDMサーバを識別する目的地情報があるか否かを判定するステップと、受信されたトラップメッセージにDMサーバを識別する目的地情報があると判定した場合、DMゲートウェイにより、トラップメッセージを目的地情報で識別されたDMサーバに送信するステップとを有する。
【0027】
また、本発明の他の態様によれば、通信システムにおけるDMゲートウェイが周期的なサービス/能力広告メッセージを処理する方法が提供される。その方法は、DMゲートウェイにより、デバイスから周期的サービス/能力広告メッセージを受信するステップと、DMゲートウェイにより、LANデバイスインベントリMOのデバイスに対する有効時間を再設定するステップとを有する。
【0028】
なお、本発明の他の態様によれば、通信システムにおけるDMゲートウェイがハートビートタイムアウト(heartbeat timeout)を処理する方法が提供される。その方法は、DMゲートウェイにより、ハートビートタイマが経過したか否かを判定するステップと、ハートビートタイマが経過したと判定する場合、LANデバイスインベントリMOで、DMゲートウェイにより、有効時間が経過したデバイスのエントリを削除するステップとを有する。
【発明の効果】
【0029】
本発明は、通信システムでのDMをサポートするためのゲートウェイ機能を制御するための技術を提供することができる。
【0030】
本発明による実施形態の上記及び他の態様、特徴、及び利点は、添付の図面と共に述べる以下の詳細な説明から、一層明らかになるはずである。
【図面の簡単な説明】
【0031】
【図1】関連技術によるOMA-DM構成を示す図である。
【図2】関連技術によるOMA-DMを採用する通信システムの一例を示す図である。
【図3】関連技術による通信システムにおけるDMクライアントとDMサーバ開始されるDMセッションに対する信号フローを示す図である。
【図4】本発明の一実施形態による初期サービス/能力広告メッセージ処理を示すフローチャートである。
【図5】本発明の一実施形態によるブートストラップサーバの役割のアルゴリズムを示すフローチャートである。
【図6】本発明の一実施形態によるプロキシサーバの役割のアルゴリズムを示すフローチャートである。
【図7】本発明の一実施形態によるプロトコル適応役割のアルゴリズムを実現するためにDMゲートウェイの機能実行を示すフローチャートである。
【図8】本発明の一実施形態による特定デバイスタイプに対するブートストラップ情報を更新する手順を示すフローチャートである。
【図9】本発明の一実施形態によって、DMゲートウェイがプロキシサーバの役割又はプロトコル適応の役割をする場合に、エンドユーザーデバイスを目的地とするDMコマンドの処理手順を示すフローチャートである。
【図10】本発明の一実施形態によるDMゲートウェイでのトラップメッセージの処理手順を示すフローチャートである。
【図11】本発明の一実施形態によるDMゲートウェイでの周期的サービス/能力メッセージの処理手順を示すフローチャートである。
【図12】本発明の一実施形態によるDMゲートウェイでのハートビートタイムアウト(Heartbeat Timeout)メッセージの処理手順を示すフローチャートである。
【図13】本発明の一実施形態によるDMゲートウェイを示すブロック構成図である。
【発明を実施するための形態】
【0032】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
【0033】
添付の図面を参照した下記の説明は、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるような本発明の実施形態の包括的な理解を助けるために提供するものであり、この理解を助けるための様々な特定の詳細を含むが、唯一つの実施形態に過ぎない。したがって、本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。
【0034】
次の説明及び請求項に使用する用語及び単語は、辞典的意味に限定されるものではなく、発明者により本発明の理解を明確且つ一貫性があるようにするために使用する。従って、特許請求の範囲とこれと均等なものに基づいて定義されるものであり、本発明の実施形態の説明が単に実例を提供するためのものであって、本発明の目的を限定するものでないことは、本発明の技術分野における通常の知識を持つ者には明らかである。
【0035】
英文明細書に記載の“a”、“an”、及び“the”、すなわち単数形は、コンテキスト中に特記で明示されない限り、複数形を含むことは、当業者には理解できるものである。したがって、例えば、“コンポーネント表面(a component surface)”との記載は一つ又は複数の表面を含む。
【0036】
“実質的に(substantially)”という用語は、提示された特徴、パラメータ、又は値が正確に設定される必要はないが、許容誤差、測定誤り、測定精度限界及び当業者に知られているか、あるいは当業者によって実験なしに得られる要素を含む偏差又は変化が、これら特性が提供しようとする効果を排除しない範囲内で発生することを意味する。
【0037】
後述する本発明の実施形態は、通信システムのデバイス管理(DM)のための技術に関する。より具体的には、本発明の実施形態は、通信システムにおけるDMをサポートするためにゲートウェイ機能を制御する技術に関するものである。通信システムにおけるDMをサポートするためにゲートウェイ機能を制御する技術が、OMA-DMバージョン2.0(以下、“DM2.0”と称する)及び/又はゲートウェイ管理オブジェクト(GwMO)イネーブラの状況で記述されるが、本発明は、他のDM又は他のOMA-DMバージョン及びイネーブラと同様に適用可能である。以下、通信システムにおいてDMをサポートするためのゲートウェイ装置は、DMゲートウェイと称する。
【0038】
用語“デバイス”が言及される場合、用語“デバイス”は、このデバイス上で実行される関連したDMクライアントを含むことができることに留意する。さらに、本発明の実施形態は、単一DMサーバと与えられたDMゲートウェイに対する単一デバイスの状況で説明されるが、任意の数のDMサーバ及び/又はデバイスも与えられたDMゲートウェイとともに使用され得る。DMゲートウェイは、物理的に通信システムのどこにも位置できるが、好ましくは、論理的にはDMサーバとデバイスとの間に配置される。
【0039】
下記の説明は、単に説明の簡潔さのために様々な標準的に利用される技術用語を使用することを理解していただきたい。例えば、下記の説明は、OMA-DM標準のようなに、OMA標準のうちいずれか一つで使用される用語を使用する。しかしながら、この説明は、上記標準に限定されると解されてはならない。通信システムにおいて、DMをサポートするためにゲートウェイ機能を制御するのに使用されるメカニズムとは独立的に、その能力のために標準化したメカニズムに合わせることが適している。
【0040】
以下、本発明の実施形態によるDMゲートウェイの多様な役割及び新たな管理オブジェクト(MO)の機能について説明する。
【0041】
DMゲートウェイの役割
DMゲートウェイは、ブートストラップサーバの役割、プロキシサーバの役割、及びプロトコル適応の役割を含む数多くの役割を遂行することができる。ブートストラップサーバの役割では、DMゲートウェイは、デバイス上にDMクライアントをブートストラップ(すなわち、デバイスに関連したDMクライアントとDMサーバとの間の接続を設定)する責任がある。その中でも、ブートストラップサーバの役割は、デバイスのローカル送信アドレスをそのWAN(Wide Area Network)アドレスにマッピングすることである。ここで、デバイスのLAN(Local Area Network)アドレスは、WAN上にルーティング可能でないこともあることに留意すべきである。一旦デバイスと関連するDMクライアントとDMサーバとの間の接続が設定されると、DMゲートウェイは、デバイスの管理にもうこれ以上の役割をしない。
【0042】
プロキシサーバの役割において、エンドユーザーデバイスとDMサーバとの間のすべての通信は、DMゲートウェイを通してなされる。ここで、DMゲートウェイは、デバイスに対するDMサーバの役割を果たし、DMゲートウェイはデバイスの代わりに外部のDMサーバと通信する。
【0043】
プロトコル適応の役割において、DMゲートウェイは、上記したプロキシサーバ機能を提供する。また、DMゲートウェイは、デバイスのネイティブ(native)管理プロトコルと、DMサーバにより利用されるOMA-DMプロトコルとの間で適応させる。
【0044】
本発明の実施形態において、デバイスは、DMゲートウェイが受信するサービス/能力広告(service/capability advertisement)メッセージを発行すると仮定する。ここで、サービス/能力広告メッセージは、サービス及び/又は能力を広告するデバイスが送信したいかなるメッセージ、又は類似した機能を遂行するいかなるメッセージを含むことを目的とする。サービス/能力広告メッセージは、デバイスのパワーオン及び/又は周期的に発行される。デバイス又はサービスを発見するためのメカニズムに対する詳細は、この開示の範囲を外れるので、簡潔さのために省略する。
【0045】
新たなMO機能
DMゲートウェイが動作できる異なる役割を説明するために、新たなMO機能が本発明の実施形態により適用される。これら新たなMO機能は、ゲートウェイ構成(Config)MO及びLANデバイスインベントリ(inventory)MOを含む新たなMOによって例示される。用語“Config MO”及び“LANデバイスインベントリMO”は、説明の便宜のために使用されるだけで、標準化団体が採択する名称によって変わることができる。また、Config MO及びLANデバイスインベントリMOが説明の便宜のために別途のMOとして説明されるが、これらの集合的機能は異なる数のMOに分配され、及び/またはその集合的機能の全部または一部が他のMOに含まれることもできる。これら新たなMOは、デバイス発見、LAN/WANアドレスマッピング、管理プロトコル適応のような多くの特定の実施形態に対しての詳細が残されているが、DMゲートウェイがサポートする必要のある機能的能力に焦点を合わせる。
【0046】
ゲートウェイConfig MOの機能は、異なるタイプのデバイスに対してDMアカウント(Acc)を維持するものである。各DM Accプロファイルは、該当DM Acc MOに含まれるものに類似した情報を含む。この情報は、DMサーバ識別子(ID)、DMサーバアドレス、及び認証情報を含んでいる。各DM Accプロファイルは固有IDを有し、複数のデバイスは同一のDM Accプロファイルを共有できる。各DM Accプロファイルは、所定のデバイスタイプに特定され得る。各デバイスタイプに対して、ゲートウェイConfig MOは、DMサーバが特定タイプの新たなデバイスの検出時にコンタクトされなければならないか否かを示すブール(Boolean)フラグを含むことができる。DMサーバは、ゲートウェイConfig MOに対する読み取り-書き込みのアクセスを有する。
【0047】
LANデバイスインベントリMOの機能は、DMゲートウェイが発見したLANにあるデバイスのリストを維持するものである。上記したように、DMゲートウェイによるデバイス発見のためのメカニズムは、特定の実施形態に対しての他の詳細がに残されている。ゲートウェイConfig MOとは違って、DMサーバは、LANデバイスインベントリMOに対する読み取り専用アクセスのみを有することができる。DMゲートウェイがLANで新たなデバイスを発見する場合、LANデバイスインベントリMOは、DMゲートウェイ上で動作しているDMクライアントにより追加される。LANデバイスインベントリMOがLANで発見された各デバイスに対して維持できる情報の例は、次のうち、一つ又はそれ以上を含む。
【0048】
・デバイスタイプ及び/又はデバイスサブタイプ
・デバイスハードウェアアドレス(すなわち、MAC(Media Access Control)アドレス、IMEI(International Mobile Equipment Identity)、MEID(Mobile Equipment ID)など)
・DM AccプロファイルID
・このデバイスに対してDMゲートウェイにより遂行される役割(すなわち、ブートストラップサーバ、プロキシサーバ、又はプロトコル適応)
・有効期間(すなわち、新たなハートビートタイムアウトメッセージがDMゲートウェイにより受信されない場合、デバイスエントリがインベントリから除去されるまでの時間)
・デバイスのWANとLAN側アドレスとの間のマッピング(ブートストラップサーバの役割のみの場合)
・DMサーバ接続状態(すなわち、DMサーバとの接続がうまく設定されたか否かを示す状態)
・進行中のDMトランザクション情報
【0049】
実施形態による新たなMOを用いるDMゲートウェイ機能
以下、上述した新たなMOの機能を用いるDMゲートウェイ機能を含む本発明の実施形態について説明する。DMゲートウェイデバイスが遂行する多様な役割に対する状況について、図4を参照して以下で説明する。
【0050】
図4は、本発明の一実施形態による初期サービス/能力広告メッセージを処理するためのフローチャートである。
【0051】
図4を参照すると、DMゲートウェイは、ステップ402で、デバイスからサービス/能力広告メッセージを受信する。サービス/能力広告メッセージは、デバイスにより周期的に発行できることに留意する。ここで、ステップ402で、受信されたサービス/能力広告メッセージは、第1のサービス/能力広告メッセージであると仮定する。
【0052】
ステップ404で、DMゲートウェイは、デバイスがDMサーバに直接接続され、DMゲートウェイをバイパス(bypass)するか否かを決定する。ここで、DMゲートウェイは、デバイスをサービス/能力広告メッセージに含まれた情報を確認してDMサーバに直接接続するか否かを判定することができる。さらに、DMサーバに直接接続されたデバイス(すなわち、DMゲートウェイをバイパスするデバイス)は、サービス/能力広告メッセージを発行しないことにも留意する。また、DMサーバに直接接続されたデバイスの場合、DMゲートウェイは、LANで該当デバイスを知っていないこともある。DMゲートウェイは、デバイスがDMサーバに直接接続され、DMゲートウェイをバイパスすると判定する場合、プロセスは終了する。一方、DMゲートウェイは、デバイスがDMサーバに直接接続されず、DMゲートウェイをバイパスしないと判定した場合、プロセスは、ステップ406に進行する。
【0053】
ステップ406で、DMゲートウェイは、デバイスがOMA-DMをサポートするか否かを判定する。ここで、DMゲートウェイは、サービス/能力広告メッセージに含まれた情報を確認することによってデバイスがOMA-DMをサポートするか否かを判定できる。デバイスがOMA-DMをサポートしないと判定される場合、DMゲートウェイは、ステップ408で、プロトコル適応役割アルゴリズムを呼び出す。その後、プロセスは終了する。プロトコル適応役割アルゴリズムは、図7を参照して、以下に詳細に説明する。一方、デバイスがOMA-DMをサポートするとDMゲートウェイが判定した場合、プロセスは、ステップ410に進行する。
【0054】
ステップ410で、DMゲートウェイは、デバイスがDMサーバにプロキシ接続のために構成されるか否かを判定する。ここで、DMゲートウェイは、サービス/能力広告メッセージに含まれた情報を確認することによって、デバイスがDMサーバにプロキシ接続のために構成されるか否かを判定する。DMゲートウェイは、デバイスがDMサーバにプロキシ接続のために構成されないと判定した場合、ステップ412で、ブートストラップサーバ役割アルゴリズムを呼び出す。その後、プロセスが終了する。以下に、ブートストラップサーバ役割アルゴリズムは、以下に図5を参照して詳細に説明する。一方、デバイスがDMサーバにプロキシ接続のために構成されるとDMゲートウェイが判定した場合、DMゲートウェイは、ステップ414で、プロキシサーバ役割アルゴリズムを呼び出す。以後、プロセスを終了する。プロキシサーバ役割アルゴリズムは、図6を参照して、以下に詳細に説明する。
【0055】
ここで、図4のフローチャートのステップは任意の順序でも呼び出すことに留意する。以下、DMゲートウェイのブートストラップサーバの役割を図5を参照して説明する。
【0056】
図5は、本発明の一実施形態によるブートストラップサーバ役割アルゴリズムを示すフローチャートである。
【0057】
図5を参照すると、DMゲートウェイは、ステップ502で、デバイスに対するWAN側アドレスを獲得する。DMゲートウェイは、STUN(Simple Traversal of User Datagram Protocol through NAT)、TURN(Traversal Using Relay NAT)のようにすべての知られているNAT(Network Address Translation)トラバース方式を用い、あるいはこのような目的の権利化された方式を使用することができる。
【0058】
ステップ504で、DMゲートウェイは、LANデバイスインベントリMOにデバイスに関する情報を追加する。ステップ506で、DMゲートウェイは、ゲートウェイConfig MOがこのデバイスタイプに対するブートストラップ情報を有するか否かを判定する。ゲートウェイConfig MOがこのデバイスタイプに対してブートストラップ情報を有すると判定した場合、DMゲートウェイは、プロセスをステップ508に進行する。ステップ508で、DMゲートウェイは、ブートストラップ情報をデバイスに転送する。ステップ510で、DMゲートウェイは、デバイスのWAN側アドレスをデバイスに転送する。その後、プロセスは終了する。一方、ゲートウェイConfig MOがこのようなデバイスタイプに対するブートストラップ情報を有していないとDMゲートウェイが判定した場合、プロセスは、ステップ512に進行する。ステップ512で、DMゲートウェイは、WAN側アドレスのみをデバイスに転送することができる。以後に、プロセスは終了する。
【0059】
ここで、ステップ510及び512は選択的であり、ステップ510及び512のうち一つ又はそれ以上は省略することができる。ステップ510及び512のうち一つ又はそれ以上が省略される場合、プロセスは、次のステップに進行する。
【0060】
DMゲートウェイのプロキシサーバの役割について、図6を参照して説明する。
【0061】
図6は、本発明の一実施形態によるプロキシサーバ役割アルゴリズムを示すフローチャートである。
【0062】
図6を参照すると、DMゲートウェイは、ステップ602で、LANデバイスインベントリMOにデバイスに関する情報を追加する。ステップ604で、DMゲートウェイは、DMゲートウェイのアドレスでデバイスをDMブートストラップする。ステップ606で、DMゲートウェイは、デバイスにより発行されたサービス/能力広告メッセージがブートストラップ情報を含むか否かを判定する。デバイスにより発行されたサービス/能力広告メッセージがブートストラップ情報を含んでいないとDMゲートウェイが判定した場合、プロセスは、ステップ608に進行する。
【0063】
ステップ608で、DMゲートウェイは、このようなデバイスタイプに対するDMブートストラップ情報がゲートウェイConfig MOにあるか否かを判定する。DMゲートウェイは、このデバイスタイプに対するDMブートストラップ情報がゲートウェイConfigMOに存在しないと判定した場合、プロセスは終了する。一方、このデバイスタイプに対するDMブートストラップ情報がゲートウェイConfigMOに存在するとDMゲートウェイが判定した場合、プロセスは、ステップ610に進行する。ステップ610で、DMゲートウェイは、ゲートウェイConfig MOによって提供されたような、正確なDM AccプロファイルIDでLANデバイスインベントリMOでデバイスに対するエントリを更新できる。その後、プロセスは、さらに後述されるステップ616に進行する。
【0064】
ステップ606に戻り、デバイスが発行したサービス/能力広告メッセージがブートストラップ情報を含んでいるとDMゲートウェイが判定した場合、プロセスは、ステップ612に進行する。ステップ612で、DMゲートウェイは、ゲートウェイConfig MOに新たなDM Accプロファイルを生成できる。ステップ614で、DMゲートウェイは、LANデバイスインベントリMOのデバイスエントリを新たなDM AccプロファイルIDに更新できる。その後、プロセスは、ステップ616に進行する。
【0065】
ステップ616で、DMゲートウェイは、該当するデバイスタイプに対する“Inform DM Server”フラグが真であるか否かを判定する。DMゲートウェイは、フラグが真に設定されていないと判定した場合、プロセスは終了する。一方、フラグが真に設定されていると判定した場合、DMゲートウェイは、ステップ618で、適切な認証情報を用いてデバイスの代わりにDMサーバとの通信を試す。ステップ620で、DMゲートウェイは、DMサーバとの試みた通信の状態に基づいて、LANデバイスインベントリMOのこのようなデバイスに対するDMサーバ接続属性を更新できる。以後に、プロセスは終了する。
【0066】
ここで、ステップ610〜614及びステップ620は、選択的であるので、ステップ610〜614及びステップ620のうち一つ又はそれ以上が省略され得る。ステップ610〜614及びステップ620のうち一つ又はそれ以上が省略されると、プロセスは次のステップに進行する。
【0067】
以下、このDMゲートウェイのプロトコル適応の役割について、図7を参照して説明する。
【0068】
図7は、本発明の一実施形態によるプロトコル適応役割アルゴリズムを実現するDMゲートウェイ上で実行される機能を示すフローチャートである。
【0069】
図7を参照すると、DMゲートウェイは、ステップ702で、LANデバイスインベントリMOのデバイスに関する情報を付加する。ステップ704で、DMゲートウェイは、このデバイスタイプに対するDMブートストラップ情報がゲートウェイConfig MOに存在するか否かを判定する。このようなデバイスタイプに対するDMブートストラップ情報がゲートウェイConfig MOに存在しないとDMゲートウェイが判定した場合、プロセスは終了する。一方、このデバイスタイプに対するDMブートストラップ情報がゲートウェイConfig MOに存在すると判定した場合、DMゲートウェイは、プロセスをステップ706に進行する。ステップ706で、DMゲートウェイは、ゲートウェイConfig MOによって提供されるような正確なDM AccプロファイルIDでLANデバイスインベントリMOのデバイスに対するエントリを更新する。ステップ708で、ゲートウェイは、該当するデバイスタイプに対する“Inform DM Server”フラグが真であるか否かを判定する。DMゲートウェイがこのフラグが真に設定されないと判定した場合、プロセスは終了する。一方、DMゲートウェイがフラグが真に設定されていると判定した場合、プロセスは、ステップ710に進行する。ステップ710で、DMゲートウェイは、適切な認証情報を用いてデバイスの代わりにDMサーバとの通信を試みる。ステップ712で、DMゲートウェイは、DMサーバとの試みた通信の状態に基づいて、LANデバイスインベントリMOのデバイスに対するDMサーバ接続属性を更新する。その後、プロセスは終了する。
【0070】
ここで、ステップ706及び712は選択的であるので、これらのうち一つ又はそれ以上が省略され得る。ステップ706及び712のうち一つ又はそれ以上が省略される場合には、プロセスは、次のステップに進行する。
【0071】
上記したように、DM Accプロファイルは、相互に異なるデバイスタイプに対する一つ又はそれ以上のMOにより維持される。ゲートウェイConfig MOでDM Accプロファイルを更新するアルゴリズムについて、図8を参照して説明する。
【0072】
図8は、本発明の一実施形態による特定デバイスタイプに対するブートストラップ情報を更新する手順を示すフローチャートである。
【0073】
図8を参照すると、DMゲートウェイは、ステップ802で、特定デバイスタイプに対するブートストラップ更新メッセージを受信する。ステップ804で、DMゲートウェイは、ブートストラップ更新メッセージに特定されているデバイスタイプ又はブートストラップ情報を更新する。ステップ806で、DMゲートウェイは、LANデバイスインベントリMOの次のエントリを選択する。ここで、その直前のステップがステップ804であると、LANデバイスインベントリMOで選択されたエントリは、第1のエントリである。
【0074】
ステップ808で、DMゲートウェイは、LANデバイスインベントリMOをスキャンし、LANインベントリMOのデバイスに対するデバイスタイプとブートストラップ更新メッセージに特定されているデバイスタイプが一致するか否かを判定する。DMゲートウェイが一致しないと判定する場合、プロセスは、後述されるステップ816に進行する。その一方、DMゲートウェイが一致すると判定した場合には、プロセスは、ステップ810に進行する。
【0075】
ステップ810で、DMゲートウェイは、自身がデバイスに対するブートストラップサーバの役割にあるか否かを判定する。DMゲートウェイは、自身がデバイスに対するブートストラップサーバの役割に存在しないと判定した場合、プロセスを下記のステップ814に進行する。一方、自身がデバイスに対するブートストラップサーバの役割にあるとDMゲートウェイが判定した場合、プロセスは、ステップ812に進行する。ステップ812で、DMゲートウェイは、更新されたDMブートストラップ情報をデバイスに転送(push)する。ステップ814で、DMゲートウェイは、LANデバイスインベントリMOの影響を受けるデバイスに対するエントリを更新する。ここで、ステップ814は、選択的であるので、省略され得る。ステップ814が省略される場合、プロセスは、ステップ816に進行する。ステップ816で、DMゲートウェイは、他のエントリがあるか否かを判定する。DMゲートウェイが他のエントリがあると判定する場合、プロセスは、ステップ806に戻り、そうでない場合には、プロセスは終了する。
【0076】
DMゲートウェイがプロキシサーバの役割又はプロトコル適応の役割にある場合に、エンドユーザーデバイスを目的地とするDMコマンドを処理するアルゴリズムは、以下に、図9を参照して説明する。
【0077】
図9は、本発明の一実施形態により、DMゲートウェイがプロキシサーバの役割又はプロトコル適応の役割にある場合、エンドユーザーデバイスを目的地とするDMゲートウェイでDMコマンドの処理を手順を示すフローチャートである。
【0078】
図9を参照すると、DMゲートウェイは、ステップ902で、DMサーバからLANデバイスをターゲットとするDMコマンドを受信する。ステップ904で、DMゲートウェイは、ターゲットデバイスがLANデバイスインベントリMOにあるか否かを判定する。ターゲットデバイスがLANデバイスインベントリMOに存在しないとDMゲートウェイが判定した場合、ステップ906で、失敗応答は、DMサーバに送信される。その後、プロセスは終了する。一方、ターゲットデバイスがLANデバイスインベントリMOにあるとDMゲートウェイが判定した場合には、プロセスは、ステップ908に進行する。
【0079】
ステップ908で、DMゲートウェイは、自身がプロトコル適応の役割にあるか否か判定する。DMゲートウェイがプロトコル適応の役割に自身が存在しないと判定する場合、プロセスは、後述されるステップ912に進行する。一方、DMゲートウェイは、プロトコル適応の役割に自身があると判定した場合、ステップ910で、デバイスによって元々サポートされる管理プロトコルにDMコマンドを適応させ、ステップ912に進行する。ステップ912で、このコマンドは、デバイスに転送される。ステップ914で、DMゲートウェイは、転送されたコマンドに対する応答を待機し、応答が受信されたか否かを判定する。応答が所定期間内に受信されない場合には、DMゲートウェイは、ステップ916でDMサーバに失敗応答を送信する。以後、プロセスは、終了する。一方、所定期間内に応答が受信される場合、DMゲートウェイは、ステップ918に進行する。
ステップ918で、DMゲートウェイは、自身がプロトコル適応の役割にあるか否かを判定する。デバイスがOMA-DMをサポートしない場合、DMゲートウェイは、プロトコル適応の役割担うことができる。DMゲートウェイは、自身がプロトコル適応の役割にないと判定した場合、以下に説明されるステップ922に進行する。その反面、DMゲートウェイは、自身がプロトコル適応の役割にあると判定した場合、ステップ920で応答をOMA-DMに適応させ、ステップ922に進行する。ステップ922で、DMゲートウェイは、応答をDMサーバに転送する。その後、プロセスは終了する。
【0080】
非要求(unsolicited)メッセージ(又はトラップメッセージ)の処理について、図10を参照して説明する。
【0081】
図10は、本発明の一実施形態によるDMゲートウェイでのトラップメッセージの処理を示すフローチャートである。
【0082】
図10を参照すると、DMゲートウェイは、ステップ1002で、デバイスに対するトラップメッセージ(非要求メッセージ)を受信する。ステップ1004で、DMゲートウェイは、デバイスが現在LANデバイスインベントリMOに存在するか否かを判定する。デバイスが現在LANデバイスインベントリMOに存在するとDMゲートウェイが判定した場合、プロセスは、以下に、さらに説明されるステップ1012に進行する。一方、デバイスが現在LANデバイスインベントリMOに存在しないとDMゲートウェイが判定した場合、プロセスは、ステップ1006に進行する。ステップ1006で、DMゲートウェイは、トラップメッセージがOMA-DMメッセージであるか否かを判定する。トラップメッセージがOMA-DMメッセージであると判定した場合、DMゲートウェイは、ステップ1008で、デバイスをLANデバイスインベントリMOに追加してプロキシサーバの役割アルゴリズムを呼び出し、ステップ1012に進行する。一方、トラップメッセージがOMA-DMメッセージでないと判定した場合、DMゲートウェイは、ステップ1010で、デバイスをLANデバイスインベントリMOに追加してプロトコル適応の役割アルゴリズムのDMゲートウェイを呼び出し、ステップ1012に進行する。
ステップ1012で、DMゲートウェイは、デバイスからのトラップメッセージに(すなわち、DMサーバに対する)目的地情報があるか否かを判定する。デバイスからのトラップメッセージに目的地情報がないとDMゲートウェイが判定した場合、プロセスは、ステップ1014に進行する。ステップ1014で、DMゲートウェイは、トラップに対する目的地情報のロケーティング(locating)を試す。DMゲートウェイが目的地情報を判定できない場合、プロセスは終了する。一方、DMゲートウェイがトラップ目的地情報を判定できる場合、DMゲートウェイは、ステップ1016で、ゲートウェイConfig MOから該当DMサーバ情報を読み取ることができ、すると、プロセスは、後述されるステップ1022に進行する。ここで、ステップ1016は、選択的であるので省略され得る。ステップ1016が省略されると、プロセスは、ステップ1022に進行する。
【0083】
ステップ1012に戻り、DMゲートウェイがデバイスからのトラップメッセージに目的地情報が存在すると判定した場合、プロセスは、ステップ1018に進行する。ステップ1018で、DMゲートウェイは、自身がプロトコル適応の役割にあるか否かを判定する。自身がプロトコル適応の役割にないとDMゲートウェイが判定した場合、プロセスは、ステップ1022に進行する。一方、自身がプロトコル適応の役割にあると判定した場合、DMゲートウェイは、ステップ1020で、デバイスからのメッセージをOMA-DMフォーマットに適応させ、プロセスはステップ1022に進行する。ステップ1022で、DMゲートウェイは、メッセージを該当DMサーバに転送する。以後、プロセスは終了する。
【0084】
上記したように、デバイスは、サービス/能力広告をパワーオン時だけでなく、周期的に発行することができる。図11を参照して、周期的なサービス/能力広告を受信する実施形態を説明する。
【0085】
図11は、本発明の一実施形態によるDMゲートウェイでの周期的サービス/能力メッセージの処理手順を示すフローチャートである。
【0086】
図11を参照すると、DMゲートウェイは、ステップ1102で、デバイスから周期的なサービス/能力メッセージを受信する。ステップ1104で、DMゲートウェイは、LANデバイスインベントリMOのデバイスに対する“有効時間”を再設定する。このメカニズムは、デバイスが故障し、バッテリーが切れ、あるいはDMゲートウェイの管轄権を外れるなどのMOのエントリに対するリンガリング(lingering)を避ける。その後、プロセスは終了する。
【0087】
図12を参照して、DMゲートウェイでのハートビートタイムアウトメッセージ処理の実施形態について説明する。
【0088】
図12は、本発明の一実施形態によるDMゲートウェイでのハートビートタイムアウトメッセージ処理を示すフローチャートである。
【0089】
図12を参照すると、ステップ1202で、ハートビートタイマが経過する。ステップ1204で、DMゲートウェイは、LANインベントリMOの次のデバイスエントリを選択する。ここで、まだどのデバイスも選択されたことがないと、最初のデバイスが選択される。ステップ1206で、DMゲートウェイは、選択されたデバイスに対する“有効時間”が経過したか否かを判定する。選択されたデバイスに対する“有効時間”が経過しないとDMゲートウェイが判定する場合、プロセスは、以下にさらに説明されるステップ1210に進行する。一方、選択されたデバイスに対する“有効時間”が経過したとDMゲートウェイが判定する場合、プロセスは、ステップ1208に進行する。ステップ1208で、DMゲートウェイは、LANインベントリMOから選択されたデバイスのエントリを削除し、プロセスはステップ1210に進行する。ステップ1210で、DMゲートウェイは、LANインベントリMOにもう他のエントリが存在するか否かを判定する。LANインベントリMOに他のエントリが存在するとDMゲートウェイが判定した場合、プロセスはステップ1204に戻る。一方、LANインベントリMOに他のエントリがないとDMゲートウェイが判定した場合、プロセスはステップ1202に戻る。
【0090】
図13を参照して、本発明の一実施形態によるDMゲートウェイデバイスの構成について説明する。
【0091】
図13は、本発明の一実施形態によるDMゲートウェイを示すブロック構成図である。
【0092】
図13を参照すると、DMゲートウェイ1302は、プロセッサ1304、メモリ1306、及び通信部1308を含む。DMゲートウェイ1302は、他の追加的な構成要素を含むことができる。しかしながら、このDMゲートウェイ1302の追加的な構成要素に関する説明は、簡潔さのために省略する。
【0093】
プロセッサ1304は、DMゲートウェイ1302の一般的な動作を処理するのに使用され、DMゲートウェイにより遂行されると明示的又は暗に説明された機能/動作/アルゴリズム/役割のうちいずれかを遂行するためのコードを実行するために使用することができる。また、プロセッサ1304は、メモリ1306及び/又は通信部1308と通信及び/又は制御を遂行することができる。ここで、用語“コード”は、メモリ1306に格納される実行可能な指示、オペランド(operand)データ、構成パラメータ、及び他の情報のうち一つ又はそれ以上を表すために使用することができる。
【0094】
メモリ1306は、DMゲートウェイが遂行すると明示的又は暗に説明された機能/動作/アルゴリズム/役割のうちいずれかを遂行するためにプロセッサ1304により処理されるコードを格納することができる。さらに、実行可能な指示、オペランドデータ、構成パラメータ、及び他の情報のうち一つ又はそれ以上は、メモリ1306に格納することができる。DMゲートウェイ1302の正確な構成に基づき、メモリ1306は、(RAM(Random-Access Memory)のような)揮発性、(ROM(Read-Only Memory)、フラッシュメモリのような)非揮発性、あるいはこれら両方の特定組み合わせであり得る。
【0095】
通信部1308は、デバイス、DMサーバ、及び他のエンティティのうち一つ又はそれ以上の間でデータを送受信する。この通信部1308は、有線又は無線のように、すべてのタイプの送受信器、受信器、及び送信器を複数含むことができる。
【0096】
上記した本発明による実施形態は、コンピュータ読み取り可能な記録媒体に対するコンピュータ読み取り可能なコードとして実施されることができる。このコンピュータ読み取り可能な記録媒体は、コンピュータシステムによって読み取り可能なデータを格納するデータストレージデバイスとなり得る。コンピュータ読み取り可能な記録媒体の例としては、ROM、RAM、CD-ROM、磁気テープ、フロッピーディスク、光データ格納装置、及び搬送波(有無線伝送経路を介してインターネットを経由するデータ伝送のような)を含むが、これに限定されることではない。また、このコンピュータ読み取り可能な記録媒体を、ネットワーク接続されたコンピュータシステムにわたって分布することによって、コンピュータ読み取り可能なコードは分布した形で格納及び遂行される。また、本発明を達成するための機能(function)プログラム、コード、及びコードセグメントは、当該技術分野における技術に長けたプログラマにとっては容易に理解できることである。
【0097】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。
【符号の説明】
【0098】
100 ・・・ デバイス
110 ・・・ DMクライアント
120 ・・・ DM標準MO
140 ・・・ DMサーバ
【技術分野】
【0001】
本発明は通信システムにおけるデバイス管理(Device Management:DM)に関するもので、特に、通信システムにおけるDMをサポートするためにゲートウェイ機能を制御する技術に関する。
【背景技術】
【0002】
ユビキタス(ubiquitous)通信技術及びシステムが成長するにつれて、デバイスの機能及び複雑性が増加する。しかしながら、デバイスの機能及び複雑性の増加とともに、デバイス管理のための必要性も増加している。このような要求を解決するために、OMA(Open Mobile Alliance)は、デバイスを管理するためのプロトコル及びメカニズムを特定するためにデバイス管理(DM)ワーキンググループを組織した。OMA DMワーキンググループは、デバイスの遠隔管理に使用されるデバイスに関連したDMクライアントとDMサーバとの間の双方向プロトコルを定義するOMA-DM仕様を開発した。DMサーバとDMクライアントとの間の関連インスタンス(instance)はDMセッションと呼ばれ、DMクライアント又はDMサーバによって開始される。DMクライアントはデバイス内に存在し、DMサーバはDMクライアント上にコマンドを呼び出してデバイスを管理する。DMクライアントは、コマンドを処理して応答をDMサーバに送信する。サーバとクライアントとの間の通信は、SyncML(Synchronization Markup Language)メッセージの交換を含む。一般的に、デバイスは無線デバイスであったが、最近では、OMA-DMが有線デバイスの遠隔管理を解決し始めた。OMA-DMの例は、デバイスの初期構成情報の設定、デバイスの永続的な(persistent)情報の後続設置及び更新、デバイスからの管理情報検索、及びデバイスによって生成されるイベント及びアラームの処理を含む。
【0003】
以下では、図1を参照して、OMA-DM構成の実施形態を説明する。
【0004】
図1を参照すると、OMA-DM構成は、DMサーバ140、DMクライアント110、及びDM標準管理オブジェクト(Management Object:MO)120を含む。DMクライアント110とDM標準MO120は、デバイス100内に同一の場所に位置する。OMA-DM構成は、追加的な構造的要素を含むことができる。しかしながら、OMA-DM構成の追加的な構成要素に関する説明は、簡潔性のために省略する。
【0005】
上記したDMサーバ140及びDMクライアント110は、インターフェースDM-1 130とDM-2 132を通じて通信する。DMクライアント110は、インターフェースDM-5 134を通じてDM標準MO120と通信する。
【0006】
DMプロトコルは、DMクライアント110のすべての実施形態がサポートしなければならない3個の標準MO120を定義する。これらDM標準MO120は、DMアカウント(Acc)MO122、デバイス情報(DevInfo)MO124、及びデバイス詳細(DevDetail)MO126を含む。
【0007】
DM Acc MO122は、ブートストラップされたDMサーバ140に関する情報を管理するために使用される。DMデバイス110に対して、間違いなくブートストラップされた各DMサーバ140において、DM Acc MO122は、DMサーバ識別子(ID)、接続(connectivity)情報、サーバアドレス、サーバ及びクライアント認証情報(credentials)などに関する情報を維持する。DevInfo MO124は、DMクライアント110に関連したデバイス100に関する基本情報を提供する。この基本情報は、デバイスID、デバイス製造業者ID、モデルID、及び言語設定を含む。DevDetail MO126は、DMクライアント110に関連したデバイス100に関する付加情報を提供する。この付加情報は、デバイスタイプ、OEM(Original Equipment Manufacturer)、ハードウェアバージョン、ファームウェアバージョン、ソフトウェアバージョン、デバイス100のオプション特性(例えば、ラージオブジェクト(large-object)取扱能力)をサポートするか否かの表示、管理ツリーの最大深さ、URI(Uniform Resource ID)の最大総長、及びURIセグメントの最大総長を含む。
【0008】
以下、OMA-DMを採用する通信システムの実施形態について、図2を参照して説明する。
【0009】
図2を参照すると、OMA-DMを採用する通信システムの実施形態は、有線ネットワーク200、無線ネットワーク202、有線デバイス210、無線デバイス212、DMサーバ220、及びDM管理者(authority)230を含む。有線デバイス210及び無線デバイス212の各々は、DMクライアント(図示せず)と関連付けられる。また、DM管理者230は、OSS(Operations Support System)であり得る。図2で、実線は物理的接続(physical connectivity)を示し、点線は論理的接続(logical connectivity)を示す。
【0010】
図2に示すOMA-DMを採用する通信システムの実施形態は、複数の可能な実施形態のうち一つに過ぎない。例えば、有線ネットワーク200と無線ネットワーク202のうちいずれか一つが省略され得る。あるいは、有線ネットワーク200と無線ネットワーク202は、結合することもできる。また、DMサーバ220とDM管理者230は有線ネットワーク200に接続されているように示されているが、DMサーバ220とDM管理者230のうち一つ又は両方ともが、無線ネットワーク202に接続することもできる。
【0011】
図2に示す通信システムにおけるOMA-DMを容易にするために、OMA-DM仕様に基づいた双方向プロトコルは、DMサーバ220と無線デバイス212に関連付けられるDMクライアントとの間と、DMサーバ220と有線デバイス210に関連付けられるDMクライアントとの間で、利用される。DM管理者230は、有線デバイス210と無線デバイス212のそれぞれに関連したDMクライアントのDM動作をDMサーバ220を通じて指示できる。DMサーバ220と有線デバイス210と無線デバイス212のそれぞれに関連したDMクライアントとの間の相互交信(interaction)のみがOMA-DM仕様の範囲内にある。
【0012】
DMクライアントとDMサーバ開始されるDMセッションに対する実施形態は、図3を参照して説明する。
【0013】
図3は、関連技術によるところの通信システムにおけるDMクライアントとDMセッションが開始されるDMサーバに対する信号フローを示す。
【0014】
図3を参照すると、DMサーバ302とDMクライアント304との間のDMセッションが開始されたDMサーバは、2つの段階を踏む。第1の段階は、設定段階310であり、第2の段階は管理段階320である。設定段階310は、認証及びデバイス情報のための情報の交換を含む。設定段階310での情報の交換は、各々複数のメッセージが含まれる3個のパッケージ、すなわちパッケージ0 312、パッケージ1 314、及びパッケージ2 316を含む。パッケージ0 312は、DMサーバ302からDMクライアント304に送信され、通知メッセージと呼ばれる。パッケージ1 314は、DMクライアント304からDMサーバ302に送信される。パッケージ1 314は、クライアント開始情報とデバイス情報を含む。クライアント開始情報は、クライアント認証情報を含む。パッケージ2 316は、DMサーバ302からDMクライアント304に送信される。パッケージ2 316は、サーバ開始情報と初期管理動作を含む。サーバ開始情報は、一つ又はそれ以上のサーバ認証情報を含む。
【0015】
管理ステップ320は、2個のパッケージ、すなわちパッケージ3 322とパッケージ4 324との交換を含む。パッケージ3 322は、DMクライアント304からDMサーバ302に送信される。パッケージ3 322は、パッケージ2316によってトリガーされる管理動作に関するクライアント応答情報を含む。パッケージ4 324は、DMサーバ302からDMクライアント304に送信される。DMセッションがパッケージ2のメッセージ316以降も続行される場合、パッケージ4 324は、追加的な管理動作と一つ又はそれ以上の追加的なユーザー相互交信コマンドのうち少なくとも一つを含む。パッケージ3のメッセージ322とパッケージ4のメッセージ324の付加的なサイクルは、DMセッションが終了するまでDMサーバ302とDMクライアント304との間に送信される。
【0016】
現在公開されているOMA-DM標準バージョンは、バージョン1.2.1である。OMA-DMワーキンググループは、現在2個の新たなDMプロトコルバージョン、すなわちOMA-DMバージョン1.3とOMA-DMバージョン2.0を開発中である。OMA-DMバージョン1.3は、OMA-DMバージョン1.2.1でのセキュリティ脆弱性のうち一部を解決するために開発されている。
【0017】
しかしながら、OMA-DMの新たなバージョンの開発は、DMワーキンググループによって解決される必要があるいくつかの新たな課題が提示する。例えば、OMA-DMバージョン1.2.1とは異なり、新たなOMA-DMバージョンにより管理されるデバイスは、世界的にルーティング可能なアドレスを有していないこともある。この主な原因は、セキュリティの理由のために、新たなOMA-DMバージョンでターゲットとなるデバイスのうち大部分がNAT(Network Address Translation)及び/又はファイアウォール機能を提供するデバイスの後に公開されるためである。また、このデバイスの大部分は移動性を持ち、そのアドレスは自身が配置されているネットワークにより制御される。新たなOMA-DMバージョンによる他の課題は、このデバイスの一部がOMA-DMクライアントを内蔵しないこともある。
【0018】
ゲートウェイ装置が、上記した課題の一部を解決するために研究されている。ゲートウェイ装置は、DMサーバとDMクライアントとの間の自力での(unaided)相互交信が可能でない状況で、少なくとも一つがOMA-DMを駆動するDMサーバとDMクライアントとの間の相互交信を容易にする実体(entity)である。
【0019】
現在OMA-DMパラダイムとは違って、ゲートウェイ装置は、新たなOMA-DMバージョンでデバイス管理の重要な役割をすると予想される。したがって、新たなOMA-DMバージョンとの利用のためにゲートウェイMO(GwMO)イネーブラが開発中である。
【0020】
したがって、通信システムにおけるDMをサポートするためにゲートウェイ機能を制御するための技術の需要がある。
【発明の概要】
【発明が解決しようとする課題】
【0021】
したがって、本発明は上記した従来技術の問題点に鑑みてなされたものであって、その目的は、通信システムにおけるDMをサポートするためのゲートウェイ機能を制御するための技術を提供することにある。
【課題を解決するための手段】
【0022】
このような目的を達成するために、本発明の一態様によれば、DMゲートウェイ、DMサーバ、及びデバイスを含む通信システムにおけるDMゲートウェイを運用する方法が提供される。その方法は、DMゲートウェイにより、新たな管理可能なデバイスを検出するステップと、DMゲートウェイにより、デバイスの一つ又はそれ以上の特徴を決定するステップと、DMゲートウェイにより、デバイスの決定された一つ以上の特徴に基づいてアルゴリズムを呼び出すステップとを有し、DMゲートウェイは、呼び出したアルゴリズムによって動作し、それによってDMサーバは、DMゲートウェイを通じてデバイスに管理コマンドを送信し、DMゲートウェイを通じてデバイスから受信された警告を処理することによってデバイスを管理できる。
【0023】
本発明の他の態様によれば、DMゲートウェイ、DMサーバ、及びデバイスを含む通信システムにおけるDMゲートウェイを運用する方法が提供される。その方法は、DMゲートウェイにより、デバイスからサービス/能力広告メッセージ(capability advertisement message)を受信するステップと、DMゲートウェイにより、サービス/能力広告メッセージに基づいてデバイスがDMサーバによって使用されるDMプロトコルをサポートするか否かを判定するステップと、デバイスがDMサーバによって使用されるDMプロトコルをサポートしないと判定した場合、デバイスに対するInform DMサーバフラグがゲートウェイ構成(Config)MOで真に設定されるか否かを判定するステップと、Inform DMサーバフラグが真に設定されると判定した場合、デバイスの代わりにDMサーバとの通信を試してローカルエリアネットワーク(LAN)デバイスインベントリMOのデバイスに対するDMサーバ接続属性を更新するステップとを有する。
【0024】
また、本発明の他の態様によれば、通信システムにおけるDMゲートウェイが特定クラスのデバイスに対するブートストラップ情報を更新する方法が提供される。その方法は、DMゲートウェイにより、特定クラスのデバイスに対するブートストラップ情報を受信するステップと、DMゲートウェイにより、特定クラスのデバイスに対するブートストラップ情報を更新するステップと、DMゲートウェイにより、デバイスタイプが更新されたブートストラップ情報のデバイスタイプと一致するデバイスに対するLANデバイスインベントリMOを検索するステップとを有する。
【0025】
さらに、本発明の他の態様によれば、通信システムにおけるDMゲートウェイがDMコマンドを処理する方法が提供される。その方法は、DMゲートウェイにより、DMサーバからデバイスに対するDMコマンドを受信するステップと、DMゲートウェイにより、LANデバイスインベントリMOにデバイスに対するエントリが存在するか否かを判定するステップと、LANデバイスインベントリMOにデバイスに対するエントリが存在すると判定した場合、DMゲートウェイにより、デバイスにDMコマンドを送信して所定時間内で応答を待機するステップと、応答が所定時間内に受信される場合、DMゲートウェイにより、DMサーバに応答を送信するステップとを有する。
【0026】
本発明の他の態様によれば、通信システムのDMゲートウェイがトラップメッセージを処理する方法が提供される。その方法は、DMゲートウェイにより、デバイスからトラップメッセージを受信するステップと、DMゲートウェイにより、LANデバイスインベントリMOにデバイスに対するエントリがあるか否かを判定するステップと、LANデバイスインベントリMOにデバイスに対するエントリがないと判定した場合、DMゲートウェイにより、プロキシサーバの役割及びプロトコル適応の役割のうちいずれか一つを呼び出し、受信されたトラップメッセージ内にDMサーバを識別する目的地情報があるか否かを判定するステップと、LANデバイスインベントリMOにデバイスに対するエントリがあると判定した場合、DMゲートウェイにより、受信されたトラップメッセージ内にDMサーバを識別する目的地情報があるか否かを判定するステップと、受信されたトラップメッセージにDMサーバを識別する目的地情報があると判定した場合、DMゲートウェイにより、トラップメッセージを目的地情報で識別されたDMサーバに送信するステップとを有する。
【0027】
また、本発明の他の態様によれば、通信システムにおけるDMゲートウェイが周期的なサービス/能力広告メッセージを処理する方法が提供される。その方法は、DMゲートウェイにより、デバイスから周期的サービス/能力広告メッセージを受信するステップと、DMゲートウェイにより、LANデバイスインベントリMOのデバイスに対する有効時間を再設定するステップとを有する。
【0028】
なお、本発明の他の態様によれば、通信システムにおけるDMゲートウェイがハートビートタイムアウト(heartbeat timeout)を処理する方法が提供される。その方法は、DMゲートウェイにより、ハートビートタイマが経過したか否かを判定するステップと、ハートビートタイマが経過したと判定する場合、LANデバイスインベントリMOで、DMゲートウェイにより、有効時間が経過したデバイスのエントリを削除するステップとを有する。
【発明の効果】
【0029】
本発明は、通信システムでのDMをサポートするためのゲートウェイ機能を制御するための技術を提供することができる。
【0030】
本発明による実施形態の上記及び他の態様、特徴、及び利点は、添付の図面と共に述べる以下の詳細な説明から、一層明らかになるはずである。
【図面の簡単な説明】
【0031】
【図1】関連技術によるOMA-DM構成を示す図である。
【図2】関連技術によるOMA-DMを採用する通信システムの一例を示す図である。
【図3】関連技術による通信システムにおけるDMクライアントとDMサーバ開始されるDMセッションに対する信号フローを示す図である。
【図4】本発明の一実施形態による初期サービス/能力広告メッセージ処理を示すフローチャートである。
【図5】本発明の一実施形態によるブートストラップサーバの役割のアルゴリズムを示すフローチャートである。
【図6】本発明の一実施形態によるプロキシサーバの役割のアルゴリズムを示すフローチャートである。
【図7】本発明の一実施形態によるプロトコル適応役割のアルゴリズムを実現するためにDMゲートウェイの機能実行を示すフローチャートである。
【図8】本発明の一実施形態による特定デバイスタイプに対するブートストラップ情報を更新する手順を示すフローチャートである。
【図9】本発明の一実施形態によって、DMゲートウェイがプロキシサーバの役割又はプロトコル適応の役割をする場合に、エンドユーザーデバイスを目的地とするDMコマンドの処理手順を示すフローチャートである。
【図10】本発明の一実施形態によるDMゲートウェイでのトラップメッセージの処理手順を示すフローチャートである。
【図11】本発明の一実施形態によるDMゲートウェイでの周期的サービス/能力メッセージの処理手順を示すフローチャートである。
【図12】本発明の一実施形態によるDMゲートウェイでのハートビートタイムアウト(Heartbeat Timeout)メッセージの処理手順を示すフローチャートである。
【図13】本発明の一実施形態によるDMゲートウェイを示すブロック構成図である。
【発明を実施するための形態】
【0032】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
【0033】
添付の図面を参照した下記の説明は、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるような本発明の実施形態の包括的な理解を助けるために提供するものであり、この理解を助けるための様々な特定の詳細を含むが、唯一つの実施形態に過ぎない。したがって、本発明の範囲及び趣旨を逸脱することなく、ここに説明する実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。
【0034】
次の説明及び請求項に使用する用語及び単語は、辞典的意味に限定されるものではなく、発明者により本発明の理解を明確且つ一貫性があるようにするために使用する。従って、特許請求の範囲とこれと均等なものに基づいて定義されるものであり、本発明の実施形態の説明が単に実例を提供するためのものであって、本発明の目的を限定するものでないことは、本発明の技術分野における通常の知識を持つ者には明らかである。
【0035】
英文明細書に記載の“a”、“an”、及び“the”、すなわち単数形は、コンテキスト中に特記で明示されない限り、複数形を含むことは、当業者には理解できるものである。したがって、例えば、“コンポーネント表面(a component surface)”との記載は一つ又は複数の表面を含む。
【0036】
“実質的に(substantially)”という用語は、提示された特徴、パラメータ、又は値が正確に設定される必要はないが、許容誤差、測定誤り、測定精度限界及び当業者に知られているか、あるいは当業者によって実験なしに得られる要素を含む偏差又は変化が、これら特性が提供しようとする効果を排除しない範囲内で発生することを意味する。
【0037】
後述する本発明の実施形態は、通信システムのデバイス管理(DM)のための技術に関する。より具体的には、本発明の実施形態は、通信システムにおけるDMをサポートするためにゲートウェイ機能を制御する技術に関するものである。通信システムにおけるDMをサポートするためにゲートウェイ機能を制御する技術が、OMA-DMバージョン2.0(以下、“DM2.0”と称する)及び/又はゲートウェイ管理オブジェクト(GwMO)イネーブラの状況で記述されるが、本発明は、他のDM又は他のOMA-DMバージョン及びイネーブラと同様に適用可能である。以下、通信システムにおいてDMをサポートするためのゲートウェイ装置は、DMゲートウェイと称する。
【0038】
用語“デバイス”が言及される場合、用語“デバイス”は、このデバイス上で実行される関連したDMクライアントを含むことができることに留意する。さらに、本発明の実施形態は、単一DMサーバと与えられたDMゲートウェイに対する単一デバイスの状況で説明されるが、任意の数のDMサーバ及び/又はデバイスも与えられたDMゲートウェイとともに使用され得る。DMゲートウェイは、物理的に通信システムのどこにも位置できるが、好ましくは、論理的にはDMサーバとデバイスとの間に配置される。
【0039】
下記の説明は、単に説明の簡潔さのために様々な標準的に利用される技術用語を使用することを理解していただきたい。例えば、下記の説明は、OMA-DM標準のようなに、OMA標準のうちいずれか一つで使用される用語を使用する。しかしながら、この説明は、上記標準に限定されると解されてはならない。通信システムにおいて、DMをサポートするためにゲートウェイ機能を制御するのに使用されるメカニズムとは独立的に、その能力のために標準化したメカニズムに合わせることが適している。
【0040】
以下、本発明の実施形態によるDMゲートウェイの多様な役割及び新たな管理オブジェクト(MO)の機能について説明する。
【0041】
DMゲートウェイの役割
DMゲートウェイは、ブートストラップサーバの役割、プロキシサーバの役割、及びプロトコル適応の役割を含む数多くの役割を遂行することができる。ブートストラップサーバの役割では、DMゲートウェイは、デバイス上にDMクライアントをブートストラップ(すなわち、デバイスに関連したDMクライアントとDMサーバとの間の接続を設定)する責任がある。その中でも、ブートストラップサーバの役割は、デバイスのローカル送信アドレスをそのWAN(Wide Area Network)アドレスにマッピングすることである。ここで、デバイスのLAN(Local Area Network)アドレスは、WAN上にルーティング可能でないこともあることに留意すべきである。一旦デバイスと関連するDMクライアントとDMサーバとの間の接続が設定されると、DMゲートウェイは、デバイスの管理にもうこれ以上の役割をしない。
【0042】
プロキシサーバの役割において、エンドユーザーデバイスとDMサーバとの間のすべての通信は、DMゲートウェイを通してなされる。ここで、DMゲートウェイは、デバイスに対するDMサーバの役割を果たし、DMゲートウェイはデバイスの代わりに外部のDMサーバと通信する。
【0043】
プロトコル適応の役割において、DMゲートウェイは、上記したプロキシサーバ機能を提供する。また、DMゲートウェイは、デバイスのネイティブ(native)管理プロトコルと、DMサーバにより利用されるOMA-DMプロトコルとの間で適応させる。
【0044】
本発明の実施形態において、デバイスは、DMゲートウェイが受信するサービス/能力広告(service/capability advertisement)メッセージを発行すると仮定する。ここで、サービス/能力広告メッセージは、サービス及び/又は能力を広告するデバイスが送信したいかなるメッセージ、又は類似した機能を遂行するいかなるメッセージを含むことを目的とする。サービス/能力広告メッセージは、デバイスのパワーオン及び/又は周期的に発行される。デバイス又はサービスを発見するためのメカニズムに対する詳細は、この開示の範囲を外れるので、簡潔さのために省略する。
【0045】
新たなMO機能
DMゲートウェイが動作できる異なる役割を説明するために、新たなMO機能が本発明の実施形態により適用される。これら新たなMO機能は、ゲートウェイ構成(Config)MO及びLANデバイスインベントリ(inventory)MOを含む新たなMOによって例示される。用語“Config MO”及び“LANデバイスインベントリMO”は、説明の便宜のために使用されるだけで、標準化団体が採択する名称によって変わることができる。また、Config MO及びLANデバイスインベントリMOが説明の便宜のために別途のMOとして説明されるが、これらの集合的機能は異なる数のMOに分配され、及び/またはその集合的機能の全部または一部が他のMOに含まれることもできる。これら新たなMOは、デバイス発見、LAN/WANアドレスマッピング、管理プロトコル適応のような多くの特定の実施形態に対しての詳細が残されているが、DMゲートウェイがサポートする必要のある機能的能力に焦点を合わせる。
【0046】
ゲートウェイConfig MOの機能は、異なるタイプのデバイスに対してDMアカウント(Acc)を維持するものである。各DM Accプロファイルは、該当DM Acc MOに含まれるものに類似した情報を含む。この情報は、DMサーバ識別子(ID)、DMサーバアドレス、及び認証情報を含んでいる。各DM Accプロファイルは固有IDを有し、複数のデバイスは同一のDM Accプロファイルを共有できる。各DM Accプロファイルは、所定のデバイスタイプに特定され得る。各デバイスタイプに対して、ゲートウェイConfig MOは、DMサーバが特定タイプの新たなデバイスの検出時にコンタクトされなければならないか否かを示すブール(Boolean)フラグを含むことができる。DMサーバは、ゲートウェイConfig MOに対する読み取り-書き込みのアクセスを有する。
【0047】
LANデバイスインベントリMOの機能は、DMゲートウェイが発見したLANにあるデバイスのリストを維持するものである。上記したように、DMゲートウェイによるデバイス発見のためのメカニズムは、特定の実施形態に対しての他の詳細がに残されている。ゲートウェイConfig MOとは違って、DMサーバは、LANデバイスインベントリMOに対する読み取り専用アクセスのみを有することができる。DMゲートウェイがLANで新たなデバイスを発見する場合、LANデバイスインベントリMOは、DMゲートウェイ上で動作しているDMクライアントにより追加される。LANデバイスインベントリMOがLANで発見された各デバイスに対して維持できる情報の例は、次のうち、一つ又はそれ以上を含む。
【0048】
・デバイスタイプ及び/又はデバイスサブタイプ
・デバイスハードウェアアドレス(すなわち、MAC(Media Access Control)アドレス、IMEI(International Mobile Equipment Identity)、MEID(Mobile Equipment ID)など)
・DM AccプロファイルID
・このデバイスに対してDMゲートウェイにより遂行される役割(すなわち、ブートストラップサーバ、プロキシサーバ、又はプロトコル適応)
・有効期間(すなわち、新たなハートビートタイムアウトメッセージがDMゲートウェイにより受信されない場合、デバイスエントリがインベントリから除去されるまでの時間)
・デバイスのWANとLAN側アドレスとの間のマッピング(ブートストラップサーバの役割のみの場合)
・DMサーバ接続状態(すなわち、DMサーバとの接続がうまく設定されたか否かを示す状態)
・進行中のDMトランザクション情報
【0049】
実施形態による新たなMOを用いるDMゲートウェイ機能
以下、上述した新たなMOの機能を用いるDMゲートウェイ機能を含む本発明の実施形態について説明する。DMゲートウェイデバイスが遂行する多様な役割に対する状況について、図4を参照して以下で説明する。
【0050】
図4は、本発明の一実施形態による初期サービス/能力広告メッセージを処理するためのフローチャートである。
【0051】
図4を参照すると、DMゲートウェイは、ステップ402で、デバイスからサービス/能力広告メッセージを受信する。サービス/能力広告メッセージは、デバイスにより周期的に発行できることに留意する。ここで、ステップ402で、受信されたサービス/能力広告メッセージは、第1のサービス/能力広告メッセージであると仮定する。
【0052】
ステップ404で、DMゲートウェイは、デバイスがDMサーバに直接接続され、DMゲートウェイをバイパス(bypass)するか否かを決定する。ここで、DMゲートウェイは、デバイスをサービス/能力広告メッセージに含まれた情報を確認してDMサーバに直接接続するか否かを判定することができる。さらに、DMサーバに直接接続されたデバイス(すなわち、DMゲートウェイをバイパスするデバイス)は、サービス/能力広告メッセージを発行しないことにも留意する。また、DMサーバに直接接続されたデバイスの場合、DMゲートウェイは、LANで該当デバイスを知っていないこともある。DMゲートウェイは、デバイスがDMサーバに直接接続され、DMゲートウェイをバイパスすると判定する場合、プロセスは終了する。一方、DMゲートウェイは、デバイスがDMサーバに直接接続されず、DMゲートウェイをバイパスしないと判定した場合、プロセスは、ステップ406に進行する。
【0053】
ステップ406で、DMゲートウェイは、デバイスがOMA-DMをサポートするか否かを判定する。ここで、DMゲートウェイは、サービス/能力広告メッセージに含まれた情報を確認することによってデバイスがOMA-DMをサポートするか否かを判定できる。デバイスがOMA-DMをサポートしないと判定される場合、DMゲートウェイは、ステップ408で、プロトコル適応役割アルゴリズムを呼び出す。その後、プロセスは終了する。プロトコル適応役割アルゴリズムは、図7を参照して、以下に詳細に説明する。一方、デバイスがOMA-DMをサポートするとDMゲートウェイが判定した場合、プロセスは、ステップ410に進行する。
【0054】
ステップ410で、DMゲートウェイは、デバイスがDMサーバにプロキシ接続のために構成されるか否かを判定する。ここで、DMゲートウェイは、サービス/能力広告メッセージに含まれた情報を確認することによって、デバイスがDMサーバにプロキシ接続のために構成されるか否かを判定する。DMゲートウェイは、デバイスがDMサーバにプロキシ接続のために構成されないと判定した場合、ステップ412で、ブートストラップサーバ役割アルゴリズムを呼び出す。その後、プロセスが終了する。以下に、ブートストラップサーバ役割アルゴリズムは、以下に図5を参照して詳細に説明する。一方、デバイスがDMサーバにプロキシ接続のために構成されるとDMゲートウェイが判定した場合、DMゲートウェイは、ステップ414で、プロキシサーバ役割アルゴリズムを呼び出す。以後、プロセスを終了する。プロキシサーバ役割アルゴリズムは、図6を参照して、以下に詳細に説明する。
【0055】
ここで、図4のフローチャートのステップは任意の順序でも呼び出すことに留意する。以下、DMゲートウェイのブートストラップサーバの役割を図5を参照して説明する。
【0056】
図5は、本発明の一実施形態によるブートストラップサーバ役割アルゴリズムを示すフローチャートである。
【0057】
図5を参照すると、DMゲートウェイは、ステップ502で、デバイスに対するWAN側アドレスを獲得する。DMゲートウェイは、STUN(Simple Traversal of User Datagram Protocol through NAT)、TURN(Traversal Using Relay NAT)のようにすべての知られているNAT(Network Address Translation)トラバース方式を用い、あるいはこのような目的の権利化された方式を使用することができる。
【0058】
ステップ504で、DMゲートウェイは、LANデバイスインベントリMOにデバイスに関する情報を追加する。ステップ506で、DMゲートウェイは、ゲートウェイConfig MOがこのデバイスタイプに対するブートストラップ情報を有するか否かを判定する。ゲートウェイConfig MOがこのデバイスタイプに対してブートストラップ情報を有すると判定した場合、DMゲートウェイは、プロセスをステップ508に進行する。ステップ508で、DMゲートウェイは、ブートストラップ情報をデバイスに転送する。ステップ510で、DMゲートウェイは、デバイスのWAN側アドレスをデバイスに転送する。その後、プロセスは終了する。一方、ゲートウェイConfig MOがこのようなデバイスタイプに対するブートストラップ情報を有していないとDMゲートウェイが判定した場合、プロセスは、ステップ512に進行する。ステップ512で、DMゲートウェイは、WAN側アドレスのみをデバイスに転送することができる。以後に、プロセスは終了する。
【0059】
ここで、ステップ510及び512は選択的であり、ステップ510及び512のうち一つ又はそれ以上は省略することができる。ステップ510及び512のうち一つ又はそれ以上が省略される場合、プロセスは、次のステップに進行する。
【0060】
DMゲートウェイのプロキシサーバの役割について、図6を参照して説明する。
【0061】
図6は、本発明の一実施形態によるプロキシサーバ役割アルゴリズムを示すフローチャートである。
【0062】
図6を参照すると、DMゲートウェイは、ステップ602で、LANデバイスインベントリMOにデバイスに関する情報を追加する。ステップ604で、DMゲートウェイは、DMゲートウェイのアドレスでデバイスをDMブートストラップする。ステップ606で、DMゲートウェイは、デバイスにより発行されたサービス/能力広告メッセージがブートストラップ情報を含むか否かを判定する。デバイスにより発行されたサービス/能力広告メッセージがブートストラップ情報を含んでいないとDMゲートウェイが判定した場合、プロセスは、ステップ608に進行する。
【0063】
ステップ608で、DMゲートウェイは、このようなデバイスタイプに対するDMブートストラップ情報がゲートウェイConfig MOにあるか否かを判定する。DMゲートウェイは、このデバイスタイプに対するDMブートストラップ情報がゲートウェイConfigMOに存在しないと判定した場合、プロセスは終了する。一方、このデバイスタイプに対するDMブートストラップ情報がゲートウェイConfigMOに存在するとDMゲートウェイが判定した場合、プロセスは、ステップ610に進行する。ステップ610で、DMゲートウェイは、ゲートウェイConfig MOによって提供されたような、正確なDM AccプロファイルIDでLANデバイスインベントリMOでデバイスに対するエントリを更新できる。その後、プロセスは、さらに後述されるステップ616に進行する。
【0064】
ステップ606に戻り、デバイスが発行したサービス/能力広告メッセージがブートストラップ情報を含んでいるとDMゲートウェイが判定した場合、プロセスは、ステップ612に進行する。ステップ612で、DMゲートウェイは、ゲートウェイConfig MOに新たなDM Accプロファイルを生成できる。ステップ614で、DMゲートウェイは、LANデバイスインベントリMOのデバイスエントリを新たなDM AccプロファイルIDに更新できる。その後、プロセスは、ステップ616に進行する。
【0065】
ステップ616で、DMゲートウェイは、該当するデバイスタイプに対する“Inform DM Server”フラグが真であるか否かを判定する。DMゲートウェイは、フラグが真に設定されていないと判定した場合、プロセスは終了する。一方、フラグが真に設定されていると判定した場合、DMゲートウェイは、ステップ618で、適切な認証情報を用いてデバイスの代わりにDMサーバとの通信を試す。ステップ620で、DMゲートウェイは、DMサーバとの試みた通信の状態に基づいて、LANデバイスインベントリMOのこのようなデバイスに対するDMサーバ接続属性を更新できる。以後に、プロセスは終了する。
【0066】
ここで、ステップ610〜614及びステップ620は、選択的であるので、ステップ610〜614及びステップ620のうち一つ又はそれ以上が省略され得る。ステップ610〜614及びステップ620のうち一つ又はそれ以上が省略されると、プロセスは次のステップに進行する。
【0067】
以下、このDMゲートウェイのプロトコル適応の役割について、図7を参照して説明する。
【0068】
図7は、本発明の一実施形態によるプロトコル適応役割アルゴリズムを実現するDMゲートウェイ上で実行される機能を示すフローチャートである。
【0069】
図7を参照すると、DMゲートウェイは、ステップ702で、LANデバイスインベントリMOのデバイスに関する情報を付加する。ステップ704で、DMゲートウェイは、このデバイスタイプに対するDMブートストラップ情報がゲートウェイConfig MOに存在するか否かを判定する。このようなデバイスタイプに対するDMブートストラップ情報がゲートウェイConfig MOに存在しないとDMゲートウェイが判定した場合、プロセスは終了する。一方、このデバイスタイプに対するDMブートストラップ情報がゲートウェイConfig MOに存在すると判定した場合、DMゲートウェイは、プロセスをステップ706に進行する。ステップ706で、DMゲートウェイは、ゲートウェイConfig MOによって提供されるような正確なDM AccプロファイルIDでLANデバイスインベントリMOのデバイスに対するエントリを更新する。ステップ708で、ゲートウェイは、該当するデバイスタイプに対する“Inform DM Server”フラグが真であるか否かを判定する。DMゲートウェイがこのフラグが真に設定されないと判定した場合、プロセスは終了する。一方、DMゲートウェイがフラグが真に設定されていると判定した場合、プロセスは、ステップ710に進行する。ステップ710で、DMゲートウェイは、適切な認証情報を用いてデバイスの代わりにDMサーバとの通信を試みる。ステップ712で、DMゲートウェイは、DMサーバとの試みた通信の状態に基づいて、LANデバイスインベントリMOのデバイスに対するDMサーバ接続属性を更新する。その後、プロセスは終了する。
【0070】
ここで、ステップ706及び712は選択的であるので、これらのうち一つ又はそれ以上が省略され得る。ステップ706及び712のうち一つ又はそれ以上が省略される場合には、プロセスは、次のステップに進行する。
【0071】
上記したように、DM Accプロファイルは、相互に異なるデバイスタイプに対する一つ又はそれ以上のMOにより維持される。ゲートウェイConfig MOでDM Accプロファイルを更新するアルゴリズムについて、図8を参照して説明する。
【0072】
図8は、本発明の一実施形態による特定デバイスタイプに対するブートストラップ情報を更新する手順を示すフローチャートである。
【0073】
図8を参照すると、DMゲートウェイは、ステップ802で、特定デバイスタイプに対するブートストラップ更新メッセージを受信する。ステップ804で、DMゲートウェイは、ブートストラップ更新メッセージに特定されているデバイスタイプ又はブートストラップ情報を更新する。ステップ806で、DMゲートウェイは、LANデバイスインベントリMOの次のエントリを選択する。ここで、その直前のステップがステップ804であると、LANデバイスインベントリMOで選択されたエントリは、第1のエントリである。
【0074】
ステップ808で、DMゲートウェイは、LANデバイスインベントリMOをスキャンし、LANインベントリMOのデバイスに対するデバイスタイプとブートストラップ更新メッセージに特定されているデバイスタイプが一致するか否かを判定する。DMゲートウェイが一致しないと判定する場合、プロセスは、後述されるステップ816に進行する。その一方、DMゲートウェイが一致すると判定した場合には、プロセスは、ステップ810に進行する。
【0075】
ステップ810で、DMゲートウェイは、自身がデバイスに対するブートストラップサーバの役割にあるか否かを判定する。DMゲートウェイは、自身がデバイスに対するブートストラップサーバの役割に存在しないと判定した場合、プロセスを下記のステップ814に進行する。一方、自身がデバイスに対するブートストラップサーバの役割にあるとDMゲートウェイが判定した場合、プロセスは、ステップ812に進行する。ステップ812で、DMゲートウェイは、更新されたDMブートストラップ情報をデバイスに転送(push)する。ステップ814で、DMゲートウェイは、LANデバイスインベントリMOの影響を受けるデバイスに対するエントリを更新する。ここで、ステップ814は、選択的であるので、省略され得る。ステップ814が省略される場合、プロセスは、ステップ816に進行する。ステップ816で、DMゲートウェイは、他のエントリがあるか否かを判定する。DMゲートウェイが他のエントリがあると判定する場合、プロセスは、ステップ806に戻り、そうでない場合には、プロセスは終了する。
【0076】
DMゲートウェイがプロキシサーバの役割又はプロトコル適応の役割にある場合に、エンドユーザーデバイスを目的地とするDMコマンドを処理するアルゴリズムは、以下に、図9を参照して説明する。
【0077】
図9は、本発明の一実施形態により、DMゲートウェイがプロキシサーバの役割又はプロトコル適応の役割にある場合、エンドユーザーデバイスを目的地とするDMゲートウェイでDMコマンドの処理を手順を示すフローチャートである。
【0078】
図9を参照すると、DMゲートウェイは、ステップ902で、DMサーバからLANデバイスをターゲットとするDMコマンドを受信する。ステップ904で、DMゲートウェイは、ターゲットデバイスがLANデバイスインベントリMOにあるか否かを判定する。ターゲットデバイスがLANデバイスインベントリMOに存在しないとDMゲートウェイが判定した場合、ステップ906で、失敗応答は、DMサーバに送信される。その後、プロセスは終了する。一方、ターゲットデバイスがLANデバイスインベントリMOにあるとDMゲートウェイが判定した場合には、プロセスは、ステップ908に進行する。
【0079】
ステップ908で、DMゲートウェイは、自身がプロトコル適応の役割にあるか否か判定する。DMゲートウェイがプロトコル適応の役割に自身が存在しないと判定する場合、プロセスは、後述されるステップ912に進行する。一方、DMゲートウェイは、プロトコル適応の役割に自身があると判定した場合、ステップ910で、デバイスによって元々サポートされる管理プロトコルにDMコマンドを適応させ、ステップ912に進行する。ステップ912で、このコマンドは、デバイスに転送される。ステップ914で、DMゲートウェイは、転送されたコマンドに対する応答を待機し、応答が受信されたか否かを判定する。応答が所定期間内に受信されない場合には、DMゲートウェイは、ステップ916でDMサーバに失敗応答を送信する。以後、プロセスは、終了する。一方、所定期間内に応答が受信される場合、DMゲートウェイは、ステップ918に進行する。
ステップ918で、DMゲートウェイは、自身がプロトコル適応の役割にあるか否かを判定する。デバイスがOMA-DMをサポートしない場合、DMゲートウェイは、プロトコル適応の役割担うことができる。DMゲートウェイは、自身がプロトコル適応の役割にないと判定した場合、以下に説明されるステップ922に進行する。その反面、DMゲートウェイは、自身がプロトコル適応の役割にあると判定した場合、ステップ920で応答をOMA-DMに適応させ、ステップ922に進行する。ステップ922で、DMゲートウェイは、応答をDMサーバに転送する。その後、プロセスは終了する。
【0080】
非要求(unsolicited)メッセージ(又はトラップメッセージ)の処理について、図10を参照して説明する。
【0081】
図10は、本発明の一実施形態によるDMゲートウェイでのトラップメッセージの処理を示すフローチャートである。
【0082】
図10を参照すると、DMゲートウェイは、ステップ1002で、デバイスに対するトラップメッセージ(非要求メッセージ)を受信する。ステップ1004で、DMゲートウェイは、デバイスが現在LANデバイスインベントリMOに存在するか否かを判定する。デバイスが現在LANデバイスインベントリMOに存在するとDMゲートウェイが判定した場合、プロセスは、以下に、さらに説明されるステップ1012に進行する。一方、デバイスが現在LANデバイスインベントリMOに存在しないとDMゲートウェイが判定した場合、プロセスは、ステップ1006に進行する。ステップ1006で、DMゲートウェイは、トラップメッセージがOMA-DMメッセージであるか否かを判定する。トラップメッセージがOMA-DMメッセージであると判定した場合、DMゲートウェイは、ステップ1008で、デバイスをLANデバイスインベントリMOに追加してプロキシサーバの役割アルゴリズムを呼び出し、ステップ1012に進行する。一方、トラップメッセージがOMA-DMメッセージでないと判定した場合、DMゲートウェイは、ステップ1010で、デバイスをLANデバイスインベントリMOに追加してプロトコル適応の役割アルゴリズムのDMゲートウェイを呼び出し、ステップ1012に進行する。
ステップ1012で、DMゲートウェイは、デバイスからのトラップメッセージに(すなわち、DMサーバに対する)目的地情報があるか否かを判定する。デバイスからのトラップメッセージに目的地情報がないとDMゲートウェイが判定した場合、プロセスは、ステップ1014に進行する。ステップ1014で、DMゲートウェイは、トラップに対する目的地情報のロケーティング(locating)を試す。DMゲートウェイが目的地情報を判定できない場合、プロセスは終了する。一方、DMゲートウェイがトラップ目的地情報を判定できる場合、DMゲートウェイは、ステップ1016で、ゲートウェイConfig MOから該当DMサーバ情報を読み取ることができ、すると、プロセスは、後述されるステップ1022に進行する。ここで、ステップ1016は、選択的であるので省略され得る。ステップ1016が省略されると、プロセスは、ステップ1022に進行する。
【0083】
ステップ1012に戻り、DMゲートウェイがデバイスからのトラップメッセージに目的地情報が存在すると判定した場合、プロセスは、ステップ1018に進行する。ステップ1018で、DMゲートウェイは、自身がプロトコル適応の役割にあるか否かを判定する。自身がプロトコル適応の役割にないとDMゲートウェイが判定した場合、プロセスは、ステップ1022に進行する。一方、自身がプロトコル適応の役割にあると判定した場合、DMゲートウェイは、ステップ1020で、デバイスからのメッセージをOMA-DMフォーマットに適応させ、プロセスはステップ1022に進行する。ステップ1022で、DMゲートウェイは、メッセージを該当DMサーバに転送する。以後、プロセスは終了する。
【0084】
上記したように、デバイスは、サービス/能力広告をパワーオン時だけでなく、周期的に発行することができる。図11を参照して、周期的なサービス/能力広告を受信する実施形態を説明する。
【0085】
図11は、本発明の一実施形態によるDMゲートウェイでの周期的サービス/能力メッセージの処理手順を示すフローチャートである。
【0086】
図11を参照すると、DMゲートウェイは、ステップ1102で、デバイスから周期的なサービス/能力メッセージを受信する。ステップ1104で、DMゲートウェイは、LANデバイスインベントリMOのデバイスに対する“有効時間”を再設定する。このメカニズムは、デバイスが故障し、バッテリーが切れ、あるいはDMゲートウェイの管轄権を外れるなどのMOのエントリに対するリンガリング(lingering)を避ける。その後、プロセスは終了する。
【0087】
図12を参照して、DMゲートウェイでのハートビートタイムアウトメッセージ処理の実施形態について説明する。
【0088】
図12は、本発明の一実施形態によるDMゲートウェイでのハートビートタイムアウトメッセージ処理を示すフローチャートである。
【0089】
図12を参照すると、ステップ1202で、ハートビートタイマが経過する。ステップ1204で、DMゲートウェイは、LANインベントリMOの次のデバイスエントリを選択する。ここで、まだどのデバイスも選択されたことがないと、最初のデバイスが選択される。ステップ1206で、DMゲートウェイは、選択されたデバイスに対する“有効時間”が経過したか否かを判定する。選択されたデバイスに対する“有効時間”が経過しないとDMゲートウェイが判定する場合、プロセスは、以下にさらに説明されるステップ1210に進行する。一方、選択されたデバイスに対する“有効時間”が経過したとDMゲートウェイが判定する場合、プロセスは、ステップ1208に進行する。ステップ1208で、DMゲートウェイは、LANインベントリMOから選択されたデバイスのエントリを削除し、プロセスはステップ1210に進行する。ステップ1210で、DMゲートウェイは、LANインベントリMOにもう他のエントリが存在するか否かを判定する。LANインベントリMOに他のエントリが存在するとDMゲートウェイが判定した場合、プロセスはステップ1204に戻る。一方、LANインベントリMOに他のエントリがないとDMゲートウェイが判定した場合、プロセスはステップ1202に戻る。
【0090】
図13を参照して、本発明の一実施形態によるDMゲートウェイデバイスの構成について説明する。
【0091】
図13は、本発明の一実施形態によるDMゲートウェイを示すブロック構成図である。
【0092】
図13を参照すると、DMゲートウェイ1302は、プロセッサ1304、メモリ1306、及び通信部1308を含む。DMゲートウェイ1302は、他の追加的な構成要素を含むことができる。しかしながら、このDMゲートウェイ1302の追加的な構成要素に関する説明は、簡潔さのために省略する。
【0093】
プロセッサ1304は、DMゲートウェイ1302の一般的な動作を処理するのに使用され、DMゲートウェイにより遂行されると明示的又は暗に説明された機能/動作/アルゴリズム/役割のうちいずれかを遂行するためのコードを実行するために使用することができる。また、プロセッサ1304は、メモリ1306及び/又は通信部1308と通信及び/又は制御を遂行することができる。ここで、用語“コード”は、メモリ1306に格納される実行可能な指示、オペランド(operand)データ、構成パラメータ、及び他の情報のうち一つ又はそれ以上を表すために使用することができる。
【0094】
メモリ1306は、DMゲートウェイが遂行すると明示的又は暗に説明された機能/動作/アルゴリズム/役割のうちいずれかを遂行するためにプロセッサ1304により処理されるコードを格納することができる。さらに、実行可能な指示、オペランドデータ、構成パラメータ、及び他の情報のうち一つ又はそれ以上は、メモリ1306に格納することができる。DMゲートウェイ1302の正確な構成に基づき、メモリ1306は、(RAM(Random-Access Memory)のような)揮発性、(ROM(Read-Only Memory)、フラッシュメモリのような)非揮発性、あるいはこれら両方の特定組み合わせであり得る。
【0095】
通信部1308は、デバイス、DMサーバ、及び他のエンティティのうち一つ又はそれ以上の間でデータを送受信する。この通信部1308は、有線又は無線のように、すべてのタイプの送受信器、受信器、及び送信器を複数含むことができる。
【0096】
上記した本発明による実施形態は、コンピュータ読み取り可能な記録媒体に対するコンピュータ読み取り可能なコードとして実施されることができる。このコンピュータ読み取り可能な記録媒体は、コンピュータシステムによって読み取り可能なデータを格納するデータストレージデバイスとなり得る。コンピュータ読み取り可能な記録媒体の例としては、ROM、RAM、CD-ROM、磁気テープ、フロッピーディスク、光データ格納装置、及び搬送波(有無線伝送経路を介してインターネットを経由するデータ伝送のような)を含むが、これに限定されることではない。また、このコンピュータ読み取り可能な記録媒体を、ネットワーク接続されたコンピュータシステムにわたって分布することによって、コンピュータ読み取り可能なコードは分布した形で格納及び遂行される。また、本発明を達成するための機能(function)プログラム、コード、及びコードセグメントは、当該技術分野における技術に長けたプログラマにとっては容易に理解できることである。
【0097】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。
【符号の説明】
【0098】
100 ・・・ デバイス
110 ・・・ DMクライアント
120 ・・・ DM標準MO
140 ・・・ DMサーバ
【特許請求の範囲】
【請求項1】
デバイス管理(DM)ゲートウェイ、DMサーバ、及びデバイスを含む通信システムにおけるDMゲートウェイを運用する方法であって、
DMゲートウェイにより、新たな管理可能なデバイスを検出するステップと、
DMゲートウェイにより、前記デバイスの一つ又はそれ以上の特徴を決定するステップと、
DMゲートウェイにより、前記デバイスの決定された一つ以上の特徴に基づいてアルゴリズムを呼び出すステップと、を有し、
前記DMゲートウェイは、前記呼び出したアルゴリズムによって動作し、それによってDMサーバは、DMゲートウェイを通じて前記デバイスに管理コマンドを送信し、DMゲートウェイを通じて前記デバイスから受信された警告を処理することによって前記デバイスを管理できることを特徴とする方法。
【請求項2】
前記デバイスの一つ以上の特徴は、前記デバイスが前記DMサーバにより使用されるDMプロトコルをサポートするか否かに関する第1の特徴、前記デバイスが前記DMサーバとのプロキシ接続のために構成されるか否かに関する第2の特徴、及び前記デバイスの前記DMゲートウェイをバイパスするために構成されるか否かに関する第3の特徴のうち少なくとも一つを含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記デバイスが前記DMサーバにより使用されるDMプロトコルをサポートしないと判定される場合、前記DMゲートウェイが前記デバイスに対するプロキシDMサーバとして動作し、前記デバイスの代わりに前記DMサーバと通信し、前記DMサーバと前記デバイスとの間でプロトコル適応を遂行するプロトコル適応アルゴリズムを呼び出すステップを有することを特徴とする請求項2に記載の方法。
【請求項4】
前記プロトコル適応アルゴリズムが呼び出される場合、DMゲートウェイの動作は、
前記デバイスに関する情報をローカルエリアネットワーク(LAN)デバイスインベントリ管理オブジェクト(MO)に付加するステップと、
DMブートストラップ情報がゲートウェイ構成(Config)MOに含まれるか否かを判定するステップと、
を有することを特徴とする請求項3に記載の方法。
【請求項5】
前記プロトコル適応アルゴリズムが呼び出された場合、DMゲートウェイの動作は、
前記DMブートストラップ情報がゲートウェイConfig MOに含まれると、前記ゲートウェイConfig MOに含まれたDMブートストラップ情報を用いてLANデバイスインベントリMOのデバイスに対するDMアカウント(Acc)プロファイル識別子(ID)を更新するステップをさらに有することを特徴とする請求項4に記載の方法。
【請求項6】
前記プロトコル適応アルゴリズムが呼び出された場合、DMゲートウェイの動作は、前記デバイスのワイドエリアネットワーク(WAN)アドレスを獲得するステップをさらに有することを特徴とする請求項4に記載の方法。
【請求項7】
前記デバイスが前記DMサーバにより使用されるDMプロトコルをサポートすると判定した場合、前記デバイスがDMサーバとのプロキシ接続のために構成される場合、前記DMゲートウェイが前記デバイスに対するプロキシDMサーバとして動作し、前記デバイスの代わりに前記DMサーバと通信するようにするプロキシサーバアルゴリズムを呼び出すことを特徴とする請求項2に記載のDMサポート方法。
【請求項8】
前記プロキシサーバアルゴリズムが呼び出される場合に、前記DMゲートウェイ動作は、
前記デバイスに関する情報をLANデバイスインベントリMOに付加するステップと、
前記DMゲートウェイのアドレスを用いて前記デバイスをDMブートストラップするステップと、
前記受信されたサービス/能力広告メッセージが前記デバイスに対するDMブートストラップ情報を含むか否かを判定するステップと、
前記サービス/能力広告メッセージが前記DMブートストラップ情報を含まないと判定される場合、前記DMブートストラップ情報がゲートウェイConfig MOに含まれるか否かを判定するステップと、
前記デバイスに対するInform DMサーバフラグがゲートウェイConfig MOで真に設定されるか否かを判定するステップと、
を有することを特徴とする請求項7に記載の方法。
【請求項9】
前記プロキシサーバアルゴリズムが呼び出される場合、前記DMゲートウェイ動作は、
前記DMブートストラップ情報が前記ゲートウェイConfig MOに含まれた場合、前記ゲートウェイConfig MOに含まれたDMブートストラップ情報を用いて、LANデバイスインベントリMOの前記デバイスに対するDMアカウント(Acc)プロファイルIDを更新するステップをさらに有することを特徴とする請求項8に記載の方法。
【請求項10】
前記プロキシサーバアルゴリズムが呼び出される場合、前記DMゲートウェイの動作は、
前記サービス/能力広告メッセージが前記DMブートストラップ情報を含むと判定した場合、前記ゲートウェイConfig MOに新たなDM Accプロファイルを生成し、前記新たなDM Accプロファイルを用いてLANデバイスインベントリMOの前記デバイスに対するDM AccプロファイルIDを更新するステップをさらに有することを特徴とする請求項8に記載の方法。
【請求項11】
前記プロキシサーバアルゴリズムが呼び出されると、前記DMゲートウェイの動作は、
前記デバイスに対するInform DMサーバフラグが真に設定されると判定した場合、前記デバイスの代わりに前記DMサーバとの通信を試すステップと、
前記LANデバイスインベントリMOの前記デバイスに対するDMサーバ接続属性を更新するステップと、
をさらに有することを特徴とする請求項8に記載の方法。
【請求項12】
前記デバイスが前記DMサーバによって使用されるDMプロトコルをサポートし、前記デバイスが前記DMサーバとのプロキシ接続が不可能であると判定した場合、前記DMゲートウェイが前記DMサーバと前記デバイスとの間の接続を容易にするブートストラップサーバアルゴリズムを呼び出すことを特徴とする請求項2に記載の方法。
【請求項13】
前記ブートストラップサーバアルゴリズムが呼び出される場合、前記DMゲートウェイの動作は、
前記デバイスのWANアドレスを獲得するステップと、
前記デバイスに関する情報をLANデバイスインベントリMOに追加するステップと、
前記デバイスのDMブートストラップ情報がゲートウェイConfig MOに含まれるか否かを判定するステップと、
前記デバイスの前記DMブートストラップ情報が前記ゲートウェイConfig MOに含まれる場合、前記DMブートストラップ情報を前記デバイスに送信するステップと、
を有することを特徴とする請求項12に記載の方法。
【請求項14】
前記ブートストラップサーバアルゴリズムが呼び出される場合、前記DMゲートウェイの動作は、
前記デバイスの前記DMブートストラップ情報が前記ゲートウェイConfig MOに含まれる場合、前記WANアドレスを前記デバイスに送信するステップと、
前記デバイスに対する前記DMブートストラップ情報が前記ゲートウェイConfig MOに含まれない場合、前記デバイスの前記WANアドレスを前記デバイスに送信するステップと、
を有することを特徴とする請求項13に記載の方法。
【請求項15】
デバイス管理(DM)ゲートウェイ、DMサーバ、及びデバイスを含む通信システムにおけるDMゲートウェイを運用する方法であって、
前記DMゲートウェイにより、前記デバイスからサービス/能力広告メッセージを受信するステップと、
前記DMゲートウェイにより、前記サービス/能力広告メッセージに基づいて前記デバイスがDMサーバによって使用されるDMプロトコルをサポートするか否かを判定するステップと、
前記デバイスがDMサーバによって使用される前記DMプロトコルをサポートしないと判定した場合、前記デバイスに対するInform DMサーバフラグがゲートウェイ構成(Config)管理オフジェクト(MO)で真に設定されるか否かを判定するステップと、
前記Inform DMサーバフラグが真に設定されると判定した場合、前記デバイスの代わりに前記DMサーバとの通信を試してローカルエリアネットワーク(LAN)デバイスインベントリMOの前記デバイスに対するDMサーバ接続属性を更新するステップと、
を有することを特徴とする方法。
【請求項16】
通信システムにおけるデバイス管理(DM)ゲートウェイが特定クラスのデバイスに対するブートストラップ情報を更新する方法であって、
前記DMゲートウェイにより、前記特定クラスのデバイスに対するブートストラップ情報を受信するステップと、
前記DMゲートウェイにより、前記特定クラスのデバイスに対するブートストラップ情報を更新するステップと、
DMゲートウェイにより、デバイスタイプが前記更新されたブートストラップ情報の前記デバイスタイプと一致する前記デバイスに対するローカルエリアネットワーク(LAN)デバイスインベントリ管理オブジェクト(MO)を検索するステップと、
を有することを特徴とする方法。
【請求項17】
前記DMゲートウェイにより、前記DMゲートウェイが前記検索されたデバイスのうちいずれかに対してブートストラップサーバとして動作するか否かをは判定するステップと、
前記DMゲートウェイが前記ブートストラップサーバとして動作すると判定する前記検索された装置のうちいずれかに対して、前記DMゲートウェイにより、前記更新されたブートストラップ情報を送信するステップと、
をさらに有することを特徴とする請求項16に記載の方法。
【請求項18】
通信システムにおけるデバイス管理(DM)ゲートウェイがDMコマンドを処理する方法であって、
前記DMゲートウェイにより、DMサーバからデバイスに対するDMコマンドを受信するステップと、
前記DMゲートウェイにより、ローカルエリアネットワーク(LAN)デバイスインベントリMOに前記デバイスに対するエントリが存在するか否かを判定するステップと、
前記LANデバイスインベントリMOに前記デバイスに対するエントリが存在すると判定した場合、前記DMゲートウェイにより、前記デバイスに前記DMコマンドを送信して所定時間内に応答を待機するステップと、
前記応答が所定時間内に受信される場合、DMゲートウェイにより、前記DMサーバに前記応答を送信するステップと、
を有することを特徴とする方法。
【請求項19】
前記LANデバイスインベントリMOに前記デバイスに対するエントリが存在しないと判定した場合、前記DMゲートウェイにより、前記DMサーバに失敗メッセージを送信するステップをさらに有することを特徴とする請求項18に記載の方法。
【請求項20】
前記応答が前記所定時間内に受信されない場合、前記DMゲートウェイにより、前記DMサーバに失敗メッセージを送信するステップをさらに有することを特徴とする請求項18に記載の方法。
【請求項21】
前記DMゲートウェイにより、前記デバイスに対するプロトコル適応の役割を遂行するか否かを判定するステップと、
前記DMゲートウェイが前記デバイスに対するプロトコル適応の役割を遂行すると判定される場合に、前記DMゲートウェイにより、前記DMコマンドを前記デバイスによりサポートされるプロトコルに適応させた後に、前記デバイスに送信するステップをさらに有することを特徴とする請求項18に記載の方法。
【請求項22】
前記DMゲートウェイにより、前記デバイスに対するプロトコル適応の役割を遂行するか否かを判定するステップと、
前記デバイスに対するプロトコル適応の役割を遂行すると判定した場合、前記DMゲートウェイにより、前記応答を前記DMサーバによりサポートされるプロトコルに適応させた後に、前記DMサーバに送信するステップをさらに有することを特徴とする請求項18に記載の方法。
【請求項23】
通信システムのデバイス管理(DM)ゲートウェイがトラップメッセージを処理する方法であって、
前記DMゲートウェイにより、デバイスからトラップメッセージを受信するステップと、
前記DMゲートウェイにより、ローカルエリアネットワーク(LAN)デバイスインベントリMOに前記デバイスに対するエントリがあるか否かを判定するステップと、
前記LANデバイスインベントリMOに前記デバイスに対するエントリがないと判定した場合、前記DMゲートウェイにより、プロキシサーバの役割及びプロトコル適応の役割のうちいずれか一つを呼び出し、前記受信されたトラップメッセージ内にDMサーバを識別する目的地情報があるか否かを判定するステップと、
前記LANデバイスインベントリMOに前記デバイスに対するエントリがあると判定した場合、前記DMゲートウェイにより、前記受信されたトラップメッセージ内に前記DMサーバを識別する目的地情報があるか否かを判定するステップと、
前記受信されたトラップメッセージに前記DMサーバを識別する前記目的地情報があると判定した場合、前記DMゲートウェイにより、前記トラップメッセージを前記目的地情報で識別された前記DMサーバに送信するステップと、
を有することを特徴とする方法。
【請求項24】
前記受信されたトラップメッセージに前記DMサーバを識別する前記目的地情報がないと判定した場合、前記DMサーバがゲートウェイ構成(Config)MOで識別されるか否かを判定し、前記DMサーバが前記ゲートウェイConfig MOで識別される場合、前記トラップメッセージをゲートウェイConfig MOに識別された前記DMサーバに送信するステップをさらに有することを特徴とする請求項23に記載の方法。
【請求項25】
前記プロキシサーバの役割は、前記トラップメッセージが前記DMサーバによってサポートされるプロトコルにあると前記DMゲートウェイが判定した場合に呼び出され、
前記プロトコル適応の役割は、前記トラップメッセージが前記DMサーバによってサポートされるプロトコルにないと前記DMゲートウェイが判定した場合に呼び出されることを特徴とする請求項23に記載の方法。
【請求項26】
前記DMゲートウェイにより、前記デバイスに対するプロトコル適応の役割を遂行するか否かを判定するステップと、
前記DMゲートウェイが前記デバイスに対するプロトコル適応の役割を遂行すると判定した場合、前記トラップメッセージが前記DMサーバに送信される前に、前記トラップメッセージを前記DMサーバによってサポートされるプロトコルに適応させるステップをさらに有することを特徴とする請求項23に記載の方法。
【請求項27】
通信システムにおけるデバイス管理(DM)ゲートウェイが周期的なサービス/能力広告メッセージを処理する方法であって、
前記DMゲートウェイにより、デバイスから周期的サービス/能力広告メッセージを受信するステップと、
前記DMゲートウェイにより、ローカルエリアネットワーク(LAN)デバイスインベントリ管理オブジェクト(MO)の前記デバイスに対する有効時間を再設定するステップと、
を有することを特徴とする方法。
【請求項28】
通信システムにおけるデバイス管理(DM)ゲートウェイがハートビートタイムアウトを処理する方法であって、
前記DMゲートウェイにより、ハートビートタイマが経過したか否かを判定するステップと、
前記ハートビートタイマが経過したと判定する場合、ローカルエリアネットワーク(LAN)デバイスインベントリ管理オブジェクト(MO)で、前記DMゲートウェイにより、有効時間が経過したデバイスのエントリを削除するステップと、
を有することを特徴とする方法。
【請求項1】
デバイス管理(DM)ゲートウェイ、DMサーバ、及びデバイスを含む通信システムにおけるDMゲートウェイを運用する方法であって、
DMゲートウェイにより、新たな管理可能なデバイスを検出するステップと、
DMゲートウェイにより、前記デバイスの一つ又はそれ以上の特徴を決定するステップと、
DMゲートウェイにより、前記デバイスの決定された一つ以上の特徴に基づいてアルゴリズムを呼び出すステップと、を有し、
前記DMゲートウェイは、前記呼び出したアルゴリズムによって動作し、それによってDMサーバは、DMゲートウェイを通じて前記デバイスに管理コマンドを送信し、DMゲートウェイを通じて前記デバイスから受信された警告を処理することによって前記デバイスを管理できることを特徴とする方法。
【請求項2】
前記デバイスの一つ以上の特徴は、前記デバイスが前記DMサーバにより使用されるDMプロトコルをサポートするか否かに関する第1の特徴、前記デバイスが前記DMサーバとのプロキシ接続のために構成されるか否かに関する第2の特徴、及び前記デバイスの前記DMゲートウェイをバイパスするために構成されるか否かに関する第3の特徴のうち少なくとも一つを含むことを特徴とする請求項1に記載の方法。
【請求項3】
前記デバイスが前記DMサーバにより使用されるDMプロトコルをサポートしないと判定される場合、前記DMゲートウェイが前記デバイスに対するプロキシDMサーバとして動作し、前記デバイスの代わりに前記DMサーバと通信し、前記DMサーバと前記デバイスとの間でプロトコル適応を遂行するプロトコル適応アルゴリズムを呼び出すステップを有することを特徴とする請求項2に記載の方法。
【請求項4】
前記プロトコル適応アルゴリズムが呼び出される場合、DMゲートウェイの動作は、
前記デバイスに関する情報をローカルエリアネットワーク(LAN)デバイスインベントリ管理オブジェクト(MO)に付加するステップと、
DMブートストラップ情報がゲートウェイ構成(Config)MOに含まれるか否かを判定するステップと、
を有することを特徴とする請求項3に記載の方法。
【請求項5】
前記プロトコル適応アルゴリズムが呼び出された場合、DMゲートウェイの動作は、
前記DMブートストラップ情報がゲートウェイConfig MOに含まれると、前記ゲートウェイConfig MOに含まれたDMブートストラップ情報を用いてLANデバイスインベントリMOのデバイスに対するDMアカウント(Acc)プロファイル識別子(ID)を更新するステップをさらに有することを特徴とする請求項4に記載の方法。
【請求項6】
前記プロトコル適応アルゴリズムが呼び出された場合、DMゲートウェイの動作は、前記デバイスのワイドエリアネットワーク(WAN)アドレスを獲得するステップをさらに有することを特徴とする請求項4に記載の方法。
【請求項7】
前記デバイスが前記DMサーバにより使用されるDMプロトコルをサポートすると判定した場合、前記デバイスがDMサーバとのプロキシ接続のために構成される場合、前記DMゲートウェイが前記デバイスに対するプロキシDMサーバとして動作し、前記デバイスの代わりに前記DMサーバと通信するようにするプロキシサーバアルゴリズムを呼び出すことを特徴とする請求項2に記載のDMサポート方法。
【請求項8】
前記プロキシサーバアルゴリズムが呼び出される場合に、前記DMゲートウェイ動作は、
前記デバイスに関する情報をLANデバイスインベントリMOに付加するステップと、
前記DMゲートウェイのアドレスを用いて前記デバイスをDMブートストラップするステップと、
前記受信されたサービス/能力広告メッセージが前記デバイスに対するDMブートストラップ情報を含むか否かを判定するステップと、
前記サービス/能力広告メッセージが前記DMブートストラップ情報を含まないと判定される場合、前記DMブートストラップ情報がゲートウェイConfig MOに含まれるか否かを判定するステップと、
前記デバイスに対するInform DMサーバフラグがゲートウェイConfig MOで真に設定されるか否かを判定するステップと、
を有することを特徴とする請求項7に記載の方法。
【請求項9】
前記プロキシサーバアルゴリズムが呼び出される場合、前記DMゲートウェイ動作は、
前記DMブートストラップ情報が前記ゲートウェイConfig MOに含まれた場合、前記ゲートウェイConfig MOに含まれたDMブートストラップ情報を用いて、LANデバイスインベントリMOの前記デバイスに対するDMアカウント(Acc)プロファイルIDを更新するステップをさらに有することを特徴とする請求項8に記載の方法。
【請求項10】
前記プロキシサーバアルゴリズムが呼び出される場合、前記DMゲートウェイの動作は、
前記サービス/能力広告メッセージが前記DMブートストラップ情報を含むと判定した場合、前記ゲートウェイConfig MOに新たなDM Accプロファイルを生成し、前記新たなDM Accプロファイルを用いてLANデバイスインベントリMOの前記デバイスに対するDM AccプロファイルIDを更新するステップをさらに有することを特徴とする請求項8に記載の方法。
【請求項11】
前記プロキシサーバアルゴリズムが呼び出されると、前記DMゲートウェイの動作は、
前記デバイスに対するInform DMサーバフラグが真に設定されると判定した場合、前記デバイスの代わりに前記DMサーバとの通信を試すステップと、
前記LANデバイスインベントリMOの前記デバイスに対するDMサーバ接続属性を更新するステップと、
をさらに有することを特徴とする請求項8に記載の方法。
【請求項12】
前記デバイスが前記DMサーバによって使用されるDMプロトコルをサポートし、前記デバイスが前記DMサーバとのプロキシ接続が不可能であると判定した場合、前記DMゲートウェイが前記DMサーバと前記デバイスとの間の接続を容易にするブートストラップサーバアルゴリズムを呼び出すことを特徴とする請求項2に記載の方法。
【請求項13】
前記ブートストラップサーバアルゴリズムが呼び出される場合、前記DMゲートウェイの動作は、
前記デバイスのWANアドレスを獲得するステップと、
前記デバイスに関する情報をLANデバイスインベントリMOに追加するステップと、
前記デバイスのDMブートストラップ情報がゲートウェイConfig MOに含まれるか否かを判定するステップと、
前記デバイスの前記DMブートストラップ情報が前記ゲートウェイConfig MOに含まれる場合、前記DMブートストラップ情報を前記デバイスに送信するステップと、
を有することを特徴とする請求項12に記載の方法。
【請求項14】
前記ブートストラップサーバアルゴリズムが呼び出される場合、前記DMゲートウェイの動作は、
前記デバイスの前記DMブートストラップ情報が前記ゲートウェイConfig MOに含まれる場合、前記WANアドレスを前記デバイスに送信するステップと、
前記デバイスに対する前記DMブートストラップ情報が前記ゲートウェイConfig MOに含まれない場合、前記デバイスの前記WANアドレスを前記デバイスに送信するステップと、
を有することを特徴とする請求項13に記載の方法。
【請求項15】
デバイス管理(DM)ゲートウェイ、DMサーバ、及びデバイスを含む通信システムにおけるDMゲートウェイを運用する方法であって、
前記DMゲートウェイにより、前記デバイスからサービス/能力広告メッセージを受信するステップと、
前記DMゲートウェイにより、前記サービス/能力広告メッセージに基づいて前記デバイスがDMサーバによって使用されるDMプロトコルをサポートするか否かを判定するステップと、
前記デバイスがDMサーバによって使用される前記DMプロトコルをサポートしないと判定した場合、前記デバイスに対するInform DMサーバフラグがゲートウェイ構成(Config)管理オフジェクト(MO)で真に設定されるか否かを判定するステップと、
前記Inform DMサーバフラグが真に設定されると判定した場合、前記デバイスの代わりに前記DMサーバとの通信を試してローカルエリアネットワーク(LAN)デバイスインベントリMOの前記デバイスに対するDMサーバ接続属性を更新するステップと、
を有することを特徴とする方法。
【請求項16】
通信システムにおけるデバイス管理(DM)ゲートウェイが特定クラスのデバイスに対するブートストラップ情報を更新する方法であって、
前記DMゲートウェイにより、前記特定クラスのデバイスに対するブートストラップ情報を受信するステップと、
前記DMゲートウェイにより、前記特定クラスのデバイスに対するブートストラップ情報を更新するステップと、
DMゲートウェイにより、デバイスタイプが前記更新されたブートストラップ情報の前記デバイスタイプと一致する前記デバイスに対するローカルエリアネットワーク(LAN)デバイスインベントリ管理オブジェクト(MO)を検索するステップと、
を有することを特徴とする方法。
【請求項17】
前記DMゲートウェイにより、前記DMゲートウェイが前記検索されたデバイスのうちいずれかに対してブートストラップサーバとして動作するか否かをは判定するステップと、
前記DMゲートウェイが前記ブートストラップサーバとして動作すると判定する前記検索された装置のうちいずれかに対して、前記DMゲートウェイにより、前記更新されたブートストラップ情報を送信するステップと、
をさらに有することを特徴とする請求項16に記載の方法。
【請求項18】
通信システムにおけるデバイス管理(DM)ゲートウェイがDMコマンドを処理する方法であって、
前記DMゲートウェイにより、DMサーバからデバイスに対するDMコマンドを受信するステップと、
前記DMゲートウェイにより、ローカルエリアネットワーク(LAN)デバイスインベントリMOに前記デバイスに対するエントリが存在するか否かを判定するステップと、
前記LANデバイスインベントリMOに前記デバイスに対するエントリが存在すると判定した場合、前記DMゲートウェイにより、前記デバイスに前記DMコマンドを送信して所定時間内に応答を待機するステップと、
前記応答が所定時間内に受信される場合、DMゲートウェイにより、前記DMサーバに前記応答を送信するステップと、
を有することを特徴とする方法。
【請求項19】
前記LANデバイスインベントリMOに前記デバイスに対するエントリが存在しないと判定した場合、前記DMゲートウェイにより、前記DMサーバに失敗メッセージを送信するステップをさらに有することを特徴とする請求項18に記載の方法。
【請求項20】
前記応答が前記所定時間内に受信されない場合、前記DMゲートウェイにより、前記DMサーバに失敗メッセージを送信するステップをさらに有することを特徴とする請求項18に記載の方法。
【請求項21】
前記DMゲートウェイにより、前記デバイスに対するプロトコル適応の役割を遂行するか否かを判定するステップと、
前記DMゲートウェイが前記デバイスに対するプロトコル適応の役割を遂行すると判定される場合に、前記DMゲートウェイにより、前記DMコマンドを前記デバイスによりサポートされるプロトコルに適応させた後に、前記デバイスに送信するステップをさらに有することを特徴とする請求項18に記載の方法。
【請求項22】
前記DMゲートウェイにより、前記デバイスに対するプロトコル適応の役割を遂行するか否かを判定するステップと、
前記デバイスに対するプロトコル適応の役割を遂行すると判定した場合、前記DMゲートウェイにより、前記応答を前記DMサーバによりサポートされるプロトコルに適応させた後に、前記DMサーバに送信するステップをさらに有することを特徴とする請求項18に記載の方法。
【請求項23】
通信システムのデバイス管理(DM)ゲートウェイがトラップメッセージを処理する方法であって、
前記DMゲートウェイにより、デバイスからトラップメッセージを受信するステップと、
前記DMゲートウェイにより、ローカルエリアネットワーク(LAN)デバイスインベントリMOに前記デバイスに対するエントリがあるか否かを判定するステップと、
前記LANデバイスインベントリMOに前記デバイスに対するエントリがないと判定した場合、前記DMゲートウェイにより、プロキシサーバの役割及びプロトコル適応の役割のうちいずれか一つを呼び出し、前記受信されたトラップメッセージ内にDMサーバを識別する目的地情報があるか否かを判定するステップと、
前記LANデバイスインベントリMOに前記デバイスに対するエントリがあると判定した場合、前記DMゲートウェイにより、前記受信されたトラップメッセージ内に前記DMサーバを識別する目的地情報があるか否かを判定するステップと、
前記受信されたトラップメッセージに前記DMサーバを識別する前記目的地情報があると判定した場合、前記DMゲートウェイにより、前記トラップメッセージを前記目的地情報で識別された前記DMサーバに送信するステップと、
を有することを特徴とする方法。
【請求項24】
前記受信されたトラップメッセージに前記DMサーバを識別する前記目的地情報がないと判定した場合、前記DMサーバがゲートウェイ構成(Config)MOで識別されるか否かを判定し、前記DMサーバが前記ゲートウェイConfig MOで識別される場合、前記トラップメッセージをゲートウェイConfig MOに識別された前記DMサーバに送信するステップをさらに有することを特徴とする請求項23に記載の方法。
【請求項25】
前記プロキシサーバの役割は、前記トラップメッセージが前記DMサーバによってサポートされるプロトコルにあると前記DMゲートウェイが判定した場合に呼び出され、
前記プロトコル適応の役割は、前記トラップメッセージが前記DMサーバによってサポートされるプロトコルにないと前記DMゲートウェイが判定した場合に呼び出されることを特徴とする請求項23に記載の方法。
【請求項26】
前記DMゲートウェイにより、前記デバイスに対するプロトコル適応の役割を遂行するか否かを判定するステップと、
前記DMゲートウェイが前記デバイスに対するプロトコル適応の役割を遂行すると判定した場合、前記トラップメッセージが前記DMサーバに送信される前に、前記トラップメッセージを前記DMサーバによってサポートされるプロトコルに適応させるステップをさらに有することを特徴とする請求項23に記載の方法。
【請求項27】
通信システムにおけるデバイス管理(DM)ゲートウェイが周期的なサービス/能力広告メッセージを処理する方法であって、
前記DMゲートウェイにより、デバイスから周期的サービス/能力広告メッセージを受信するステップと、
前記DMゲートウェイにより、ローカルエリアネットワーク(LAN)デバイスインベントリ管理オブジェクト(MO)の前記デバイスに対する有効時間を再設定するステップと、
を有することを特徴とする方法。
【請求項28】
通信システムにおけるデバイス管理(DM)ゲートウェイがハートビートタイムアウトを処理する方法であって、
前記DMゲートウェイにより、ハートビートタイマが経過したか否かを判定するステップと、
前記ハートビートタイマが経過したと判定する場合、ローカルエリアネットワーク(LAN)デバイスインベントリ管理オブジェクト(MO)で、前記DMゲートウェイにより、有効時間が経過したデバイスのエントリを削除するステップと、
を有することを特徴とする方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【公表番号】特表2013−502635(P2013−502635A)
【公表日】平成25年1月24日(2013.1.24)
【国際特許分類】
【出願番号】特願2012−525493(P2012−525493)
【出願日】平成22年8月19日(2010.8.19)
【国際出願番号】PCT/KR2010/005493
【国際公開番号】WO2011/021865
【国際公開日】平成23年2月24日(2011.2.24)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.フロッピー
【出願人】(503447036)サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Fターム(参考)】
【公表日】平成25年1月24日(2013.1.24)
【国際特許分類】
【出願日】平成22年8月19日(2010.8.19)
【国際出願番号】PCT/KR2010/005493
【国際公開番号】WO2011/021865
【国際公開日】平成23年2月24日(2011.2.24)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.フロッピー
【出願人】(503447036)サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Fターム(参考)】
[ Back to top ]