JP5095831B6 - 機器管理の方法、端末、装置およびシステム - Google Patents

Description

本開示は、ネットワーク通信の技術分野での機器管理の方法、端末、装置、およびシステムに関する。

モバイル端末はモバイル・オペレーション・サービス・システムにおける重要なコンポーネントである。機器管理（ＤＭ、Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）とは、データパケットがオーバ・ザ・エア（ＯＴＡ、Ｏｖｅｒ Ｔｈｅ Ａｉｒ）モードでネットワーク側から端末機器へダウンロードされ、端末機器が、パラメータ・コンフィギュレーション、ソフトウェア設置、およびエラー診断のようなその後の機能を達成するため、処理を実行するよう命令されることを意味する。

オープン・モバイル・アライアンスＤＭ（ＯＭＡ ＤＭ）により設計されたＤＭ仕様では、端末機器の管理のためのプロトコルサポートは既に達成されている。図１は、端末機器を管理するＤＭサーバの全体的構造の概略図である。端末機器上のＤＭクライアントはＤＭサーバによって配信された管理コマンドを説明し実行するよう適合している。端末機器上のＤＭ管理ツリーは、ＤＭサーバがＤＭプロトコルを通じて端末機器を管理するインターフェイスとしてみなされることがある。管理オブジェクト（ＭＯ、Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）のグループは管理ツリーの中に存在する。ＤＭサーバは、ＭＯの中のノード（管理ノード）の動作を通じて端末リソースを管理する目的を達成する。

図１に示されているように、従来技術では、ＤＭ管理は２つのステップ、すなわち、ブートストラップおよびその後の管理を通じて実行される。ブートストラップは、サーバと端末機器との間の管理セッションが実際の管理のため確立される前に起こり、（ユーザ名およびパスワードのような）アカウント情報と（接続パラメータのような）他のパラメータとを構成するよう適合する。その後の管理プロセスにおいて、管理セッションが確立される。サーバは、端末機器のＭＯを通じて、端末の（ファームウェアバージョン、ソフトウェアバージョン、および大規模オブジェクトサポートのような）基本情報を獲得し、その後の管理アクションの基礎としてこの基本情報を使用することができる。

従来技術では、端末機器の管理のためのプロトコルサポートは既に達成されているが、管理有効性、効率、および通信トラフィックのような問題が依然として存在する。たとえば、サーバは、端末ＤＭオブジェクトのアドレスおよび（ソフトウェアコンポーネント管理のサポートおよびファームウェアアップグレードのサポートの能力のような）端末によってサポートされるＤＭ能力を迅速に取得しない可能性があり、端末は再ブートストラップのためＳｍａｒｔＣａｒｄを使用する。具体的には以下の通りである。

１． 端末がローカルに再ブートストラップされた後（たとえば、機器が交換された後）、サーバは端末がブートストラップされたことが認知しないので、サーバに記憶されている認証関連情報は端末がブートストラップされた後の認証関連情報と矛盾する場合があり、結果として、同一性認証が両当事者のためには達成されない可能性があり、通常の管理は失敗することになる。

２． サーバが端末機器による管理ツリーの制限または端末による管理ツリーの実施の制限に関する状況を取得することを可能にするため、従来技術では、端末製造業者は、その端末製造業者の機器を記述し、機器記述フレームワーク（ＤＤＦ、Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）を介してＤＭ当事者による照会のための記述を公表する。しかし、既存プロトコルでは、サーバ側は端末機器を通じてその対応するＤＤＦを見つけることができないため、サーバがＤＤＦを獲得することはより困難である。

３． サーバは、端末によってサポートされる管理オブジェクト（ＭＯ）タイプを取得しない可能性があり、ネットワークリソースをさらに浪費する。ＤＤＦは、通常は、静的であるか、または、殆ど動的に変更されないので、サーバが端末によってサポートされるすべてのＭＯタイプをＤＤＦに従って取得することは難しい。サーバは、対応する管理コマンドが配信され、配信されたコマンドが大量のデータ（たとえば、ソフトウェアコンポーネント管理）を伝達した後に限り、端末によって返送される結果を通じて端末がある一定のＤＭ能力をサポートするかどうかを判定するので、サーバおよびネットワークリソースは浪費される。

４． 従来技術では、サーバは、非直列化モードにおいて一括して機器管理ツリー上のある一定の管理サブツリーの中のすべての管理ノードの具体的な特性値を獲得しない可能性があり、したがって、特性は数回に亘って獲得される必要があり、結果として、効率が低くなる。

５． サーバが端末の管理ノードを検索することは非常に困難であり、エアリソースが消費される。端末管理ノードを獲得するため、サーバは、数回に亘って端末と相互に作用するか、または、端末のディレクトリ構造全体を獲得する必要がある場合があるので、エアリソースは占有され、サーバ上の負荷が増大する。

６． 従来技術では、サーバは、端末に単一の管理コマンドで複数の要素を順次実行するよう命令しない可能性があるので、順次実行を必要とするアクションは、実施のため順次実行される複数の管理コマンドに分割される必要があり、したがって、端末によるメッセージ管理および解析と実行とのコストが増大する。

７． 端末またはサーバがアクションを処理するために長時間を要するとき、セッションは中断される場合があり、管理アクションが完了できない。このようにして、長時間を要する管理は困難になる。その上、当事者が管理コマンドは間もなく送信される必要があることを確認するとき、現在のセッションは維持されない可能性があり、現在のセッションは中断される場合がある。管理セッションは、管理コマンドがその後に送信される必要があるときに再確立されるべきであり、大きなコストを引き起こす。

８． 端末が複数のＭＯインスタンスを有するとき、サーバは現在アクティブ化されているインスタンスを認知しないため、結果として、サーバ管理の難易度が高くなる。

実施形態では、本開示は、ユーザがブートストラップを実行した後に通常の管理が実行されない可能性があるという従来技術における第１の技術的課題を解決する。

実施形態では、本開示は、プロトコルサーバが対応する機器記述フレームワーク（ＤＤＦ）を獲得することが難しいという従来技術における第２の技術的課題を解決する。

実施形態では、本開示は、サーバが非直列化モードにおいて一括して機器管理ツリー上のある一定の管理サブツリーの中のすべての管理ノードの具体的な特性値を獲得しないことがあるという従来技術における第３の技術的課題を解決する。

実施形態では、本開示は、サーバが端末の管理ノードを検索することが難しく、エアリソースが浪費され、サーバの負荷が高いという従来技術における第４の技術的課題を解決する。

実施形態では、本開示は、既存のサーバが端末に、単一の管理コマンドの中の複数の要素を順次実行するよう命令しない可能性があるという従来技術における第５の技術的課題を解決する。

実施形態では、本開示は、セッションを維持する方法が利用できないとき、予期しない中断がセッションの中で起こる可能性があるという従来技術における第６の技術的課題を解決する。

実施形態では、本開示は、端末が複数の管理オブジェクト（ＭＯ）インスタンスを有し、サーバが現在アクティブ化されているインスタンスを認知しないので、サーバを管理する難易度が高くなるという従来技術における第７の技術的課題を解決する。

本発明の第１の態様によれば、機器管理方法であって、サーバと端末との間に管理セッションを確立し、サーバによって、検索されるべき管理オブジェクトの識別子（ＭＯＩＤ）を伝達するＩｔｅｍ／Ｄａｔａ要素を伝達し、機器管理ツリーの中のサブツリーのルートノードＵＲＩを伝達するＩｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩ要素と、端末にサブツリーの中の管理オブジェクト（ＭＯ）の出現するルートノードＵＲＩを検索し返送するよう命令する検索命令パラメータとを伝達するＧｅｔコマンドを端末へ送信し、端末によって、Ｇｅｔコマンドを受信し、サブツリーの中でサーバによりアクセス権限が所有されているＭＯの出現を検索し、端末によって、端末がＭＯの１回以上の出現を見つけたとき、Ｇｅｔコマンドのステータス情報と、ステータス情報の後に続いて見つけられたＭＯのルートノードＵＲＩとをサーバへ返送するか、または、端末がＭＯの出現を見つけられなかったとき、Ｇｅｔコマンドのステータス情報をサーバへ返送する、ことを含む機器管理方法が提供される。

本発明の第２の態様によれば、機器管理（ＤＭ）端末であって、検索されるべき管理オブジェクト（ＭＯ）の識別子（ＩＤ）（ＭＯＩＤ）を伝達し、機器管理ツリーの中のサブツリーのルート・ノード・パス、および、サブツリーの中のＭＯの出現するルート・ノード・パスを検索して返送するよう端末に命令する検索命令パラメータを伝達するＧｅｔコマンドを受信するよう適合された受信モジュールと、サーバがサブツリーの中でアクセス権限を有するＭＯの出現を検索し、Ｇｅｔコマンドのステータス情報とステータス情報の後に続いて見つけられたＭＯの前記ルート・ノード・パスとをサーバへ返送するよう適合された検索モジュールと、を備える機器管理端末が提供される。

本発明の第３の態様によれば、機器管理（ＤＭ）装置は、検索されるべき管理オブジェクト（ＭＯ）の識別子（ＩＤ）（ＭＯＩＤ）と、機器管理ツリーの中のサブツリーのルートノードＵＲＩと、サブツリーの中のＭＯの出現するルートノードＵＲＩを検索し返送するよう端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを送信するよう適合された送信モジュールと、Ｇｅｔコマンドのステータス情報と、端末によって返送されたサブツリーの中のＭＯの出現するルートノードＵＲＩとを受信するよう適合された受信モジュールと、を備える機器管理装置が提供される。

本発明の第４の態様によれば、上記第２の態様による端末と、上記第３の態様による機器管理装置と、を備える機器管理のシステムが提供される。

本開示の技術的な解決手段は、添付図面を参照してさらに詳細に記載される。
従来技術において端末を管理するＤＭサーバの全体的構造の概略図である。 本開示の実施形態によるブートストラップ方法のフローチャートである。 本開示の実施形態によるブートストラップ方法においてブートストラップタイプ管理ノードをＤＭＡｃｃ ＭＯに追加する概略図である。 本開示の実施形態によるＤＤＦを獲得する方法のフローチャートである。 本開示によるＤＤＦを獲得する方法の解析プロセスの概略図である。 本開示の実施形態による端末管理方法において機器管理ツリーの中にサポートノードを追加する概略図である。 本開示の実施形態によるＭＯアドレスを検索する方法の概略図である。 本開示の実施形態によるコマンドの実行モードを管理する方法のフローチャートである。 本開示の実施形態による管理セッションを維持する方法のフローチャートである。 本開示の実施形態による管理セッションを維持する方法の解析プロセスのフローチャートである。 本開示の実施形態による端末アクティブ化ＭＯを取得する方法のフローチャートである。 本開示の実施形態による機器管理ツリーの中のアクティブ化ＭＯに関する情報を記憶する概略図である。

機器管理（ＤＭ）は、主として２つの段階、すなわち、ブートストラップの段階とその後の管理の段階とにおいて実行される。ブートストラップは、管理セッションがサーバと端末機器との間で確立される前に生じ、主として、端末で、サーバの（サーバのアドレス、ユーザ名、およびパスワード）のようなアカウント情報を構成し、（ネットワーク・アクセス・ポイントの情報のような）他のパラメータを構成する。ブートストラップ段階で構成された情報は、その後の管理セッションの確立のための基礎となる。サーバのアカウント情報の構成が完了した後、サーバは端末を管理することができる。管理アクションは、サーバと端末機器との間に確立された管理セッションを通じて達成される。

本開示における改良点は、ブートストラップおよびその後の管理セッションを含む２つの部分を用いて以下で詳細に明らかにされている。

Ｉ． ブートストラップ

ブートストラップの主な目的は、端末とサーバとの間に通常の管理セッションを確立することを可能にするためサーバのアカウント情報を構成することである。同時に、接続設定のような他の関連パラメータがさらに構成されることがある。この具体的な構成方法は以下の通りである。構成されるべきサーバのアカウント情報および他の関連パラメータは、クライアントプロビジョニング（ＣＰ）ファイルフォーマットまたは管理オブジェクト（ＭＯ）直列化フォーマットの中にカプセル化され、カプセル化されたブートストラップ情報がプレインストレーション配信、ＯＴＡプッシュ、または、ＳｍａｒｔＣａｒｄのようなモードで端末へ配信される。端末はサーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を格納するサーバのカプセル化されたブートストラップ情報を受信し、端末はブートストラップまたは再ブートストラップのためブートストラップ情報を使用する。構成の主な仕事は、ブートストラップ情報の中のサーバのアカウント情報を、端末ＤＭツリーの中のサーバアカウントＭＯ（以下、ＤＭＡｃｃと称する）と他の関連ＭＯとに変換することである。その後、ＤＭＡｃｃに対応するサーバに先に接続されていた端末は、サーバ上の管理状態をアクティブ化する。接続が確立されているとき、サーバは、「ＬｏｃＮａｍｅ」（ＬｏｃＮａｍｅの値はＤＭＡｃｃ ＭＯの中で「ＡＡＵＴＨＮＡＭＥ」と呼ばれるノードの値である）を通じて端末のユーザ名を取得し、そして、認証のためのユーザ名に対応するパスワードをさらに使用する。メッセージ・ダイジェスト・アルゴリズム５（ＭＤ５）認証では、ノンスがリプレイ攻撃を阻止するために取得されることがさらに必要である。

特に、ＳｍａｒｔＣａｒｄモードは、初期構成を都合良く実行し、端末のアカウント情報に問題が起こったとき、または、端末（たとえば、携帯電話機）が交換されたとき、再構成を実行することがある安全かつ便利な構成モードである。端末機器が構成済みのアカウントに関する再構成（たとえば、ＳｍａｒｔＣａｒｄモードによる再構成）をローカルで実行するとき、サーバが初期構成後にＯＴＡモードにおいて構成済みのアカウントのパスワードを変更し、ＳｍａｒｔＣａｒｄ上のブートストラップ情報の中のアカウントに対応するパスワードが変更されていないならば、端末のローカル再構成後に、ＤＭＡｃｃ上のパスワードはリセットされることになる（パスワードは変更前に元の値に再変換される）。再構成は、ローカルなアクションであり、サーバはアカウント情報が再構成されたことを知ることができないので、端末に記憶されているパスワードはサーバに記憶されているパスワードと矛盾する。同時に、サーバは端末を認証できず、管理セッションは確立されない可能性がある。

本開示の第１の実施形態では、ブートストラップ構成問題が解決される。２つの主要な方法が以下の通り説明される。

１． 図２に示されているように、サーバのアカウント情報がブートストラップまたは再ブートストラップされた後、端末はセッション要求メッセージをサーバへ送信する。セッション要求メッセージは、端末がブートストラップまたは再ブートストラップされたことをサーバに警告するよう構成される。

サーバがセッション要求メッセージを受信した後、パスワードと、セッション要求メッセージの中で搬送されるＬｏｃＮａｍｅに対応するノンスとが、端末を認証するためサーバによって記憶されたブートストラップ情報から獲得される。認証が成功した後、サーバ側の認証情報が初期化されるか、または、リセットされる。

端末がサーバに、端末がブートストラップまたは再ブートストラップされたことを警告する方法は以下の通りである。

端末がブートストラップまたは再ブートストラップされた後、端末は、最初に、端末がブートストラップまたは再ブートストラップされたことをサーバに知らせるため、セッション要求メッセージをサーバへ送信する。セッション要求メッセージは、端末機器情報、ＬｏｃＮａｍｅ、端末認証情報、および、ブートストラップまたは再ブートストラップ警告情報を含むことができる。ブートストラップまたは再ブートストラップ警告情報の具体的な実施方法は以下の通りである。

端末は、警告情報を実施するために「Ａｌｅｒｔ」コマンドの特定のタイプコードの「Ａｌｅｒｔ」コマンドを使用する。ＡｌｅｒｔコマンドおよびＡｌｅｒｔコマンドのタイプコードは、特に、端末情報レポートＡｌｅｒｔコマンド（すなわち、コマンド・タイプコードが１２２６である一般的な警告（Ｇｅｎｒｉｃ Ａｌｅｒｔ））と、端末事象レポート警告コマンド（すなわち、コマンド・タイプコードが１２２４であるクライアント事象警告（Ｃｌｉｅｎｔ Ｅｖｅｎｔ Ａｌｅｒｔ））、または、具体的には以下の通りの警告情報を報告するための新しいセッションタイプであってもよい。

事象タイプ（Ｅｖｅｎｔ ｔｙｐｅ）は、たとえば、一般的な警告、または、クライアント事象警告、たとえば、ｏｒｇ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｄｍ．ｂｏｏｔｓｔｒａｐを採用するために最初に定義される必要がある。以下、一般的な警告は一実施例として採用されている。クライアント事象報告を使用する方法は以下に類似する。

警告情報を報告する新しいセッションタイプを追加する方法は以下の通りである。新しいＡｌｅｒｔコマンドのタイプコードが追加される。タイプコードを伝達するＡｌｅｒｔコマンドは新しいセッションタイプを指示するよう構成される。タイプコードは１２０２であってもよい。実施例は以下の通りである。

端末によって開始されたサーバへのセッション要求メッセージは、ブートストラップ警告情報を伝達する。サーバが要求メッセージを受信した後、サーバは、セッション要求メッセージの中で伝達された警告情報を解析することにより、端末がブートストラップまたは再ブートストラップされたことを認知し、次に、端末要求を認証するためサーバ側で記憶されたブートストラップ情報の中のパスワードを獲得する。その後の管理において、サーバは端末によって記憶されたパスワードを更新することができる。

安全性のため（たとえば、悪質なサーバがセッション要求メッセージを傍受し、リプレイ攻撃を始める問題を防止するため）、端末によって送信されたセッション要求メッセージを認証した後、サーバは端末への認証チャレンジをさらに開始することができる。チャレンジは、サーバによって生成された新しいノンスを伝達する。サーバによって送信されたチャレンジメッセージを受信した後、端末は新しいノンスを使用して新しい認証情報を生成し、認証情報をサーバへ送信する。サーバは端末を再び認証する。認証が成功した後、サーバは他の管理オペレーションを実行することができ、たとえば、サーバパスワードを更新することができる。

再ブートストラップは、ある一定の条件（たとえば、携帯電話機カードが新しい携帯電話機に挿入される）において端末機器によって自動的にトリガされ、または、端末ユーザインターフェイス（ＵＩ）を介してユーザによってトリガされることが可能である。

２． ＳｍａｒｔＣａｒｄ上のブートストラップ情報が端末によって更新可能である場合、ブートストラップ方法は以下の通りである。端末は、端末のＤＭツリーのＤＭＡｃｃ ＭＯに記憶されたユーザ名、パスワードまたはノンスを更新するため、サーバのＤＭコマンドを受信する。更新が成功した後、端末は、ＳｍａｒｔＣａｒｄオペレーションコマンドを通じて自動的にＳｍａｒｔＣａｒｄにおけるブートストラップファイルの中の対応するユーザ名、パスワードまたはノンス情報を更新する。上記処理後の２つの状況は以下の通りである。

１） ブートストラップファイルの更新が、ブートストラップファイルの中で伝達されるユーザ名、パスワード、およびノンスが、サーバによって記憶されたユーザ名、パスワード、およびノンスと整合していることを保証できる場合、その後のブートストラップは更新済みのブートストラップファイルを用いて実行され、そして、ブートストラップ後に、サーバに通知する必要がない（すなわち、ブートストラップ事象をサーバへ報告する専用セッションが必要とされない）。

２） ブートストラップファイルの更新が、ブートストラップファイルの中で伝達されるユーザ名、パスワード、およびノンスが、サーバによって記憶されたユーザ名、パスワード、およびノンスと整合していることを保証できない場合、ユーザ名、パスワード、またはノンスのようなアカウントデータの更新を効率的に制御し、サーバと端末との間の同期を容易に行うために、ブートストラップファイルが更新された後に、更新情報が更新済みのブートストラップファイルの中に記録される。更新情報はバージョンフィールドを追加することにより記録されることができる。さらに、セッションがブートストラップの後にブートストラップファイルを使用することにより初めて確立されるとき、記録された更新情報がセッション要求メッセージの中で報告される。サーバは更新に従って処理を実行する。

ブートストラップは複数のモードを含む。しかし、これまでのところ、ブートストラップによって生成された機器管理ツリーのＤＭＡｃｃ ＭＯの中の情報は、アカウントが生成されたブートストラップモードに関する記録を含まない。したがって、サーバは、ブートストラップモードを通じてブートストラップの安全性レベルを判断することができず、すべての端末について採用されたブートストラップ方法の統計を取ることができない。本開示の第２の実施形態では、上記課題を解決する方法が以下の通り記載される。サーバが端末のブートストラップのソースを取得することができるよう、本実施形態では、端末がブートストラップされるモード、すなわち、ブートストラップタイプを記憶するため、管理ノード（たとえば、図３における「ブートストラップタイプ」）が端末ＤＭツリーのＤＭＡｃｃ ＭＯに追加される。具体的な実施形態は図３に示されている通りである。ブートストラップタイプの値は、表１に示されているように整数でもよい。

端末のブートストラップが成功した後、ブートストラップモードは管理ノードの中に記憶される。サーバは端末の中のアカウントに対応するブートストラップモードを獲得するために管理セッションを介してＧｅｔコマンドを管理モードへ配信する。サーバの権限を認証した後、端末は管理ノード値を返送する。

第３の実施形態では、本開示は、端末が複数のＤＭＡｃｃを生成するため数回に亘って同じＳｅｒｖｅｒＩＤアカウントでブートストラップを実行する状況を回避するように、ブートストラップ情報を処理する方法について記載する。具体的なブートストラップ方法は以下のステップを含む。

１． 端末の管理ツリーは、以下の通り、ＳｅｒｖｅｒＩＤに対応するＤＭＡｃｃ ＭＯが既に存在するかどうかを判定するため検索される。現在構成されるべきサーバアカウントに対応するＳｅｒｖｅｒＩＤが装置管理ツリーの中のＤＭＡｃｃ ＭＯのＳｅｒｖｅｒＩＤノードの値と同じであるかどうかが比較され、一方、現在構成されるべきサーバアカウントに対応するＳｅｒｖｅｒＩＤが装置管理ツリーの中のＤＭＡｃｃ ＭＯのＳｅｒｖｅｒＩＤノードの値と同じである場合、対応するアカウント情報が存在し、現在構成されるべきサーバアカウントに対応するＳｅｒｖｅｒＩＤが装置管理ツリーの中のＤＭＡｃｃ ＭＯのＳｅｒｖｅｒＩＤノードの値と同じでない場合、対応するアカウント情報が存在しない。ＳｅｒｖｅｒＩＤに対応するＤＭＡｃｃ ＭＯが端末の管理ツリーの中に見つけられる場合、ステップ２が実行され、ＳｅｒｖｅｒＩＤに対応するＤＭＡｃｃ ＭＯが端末の管理ツリーの中で見つからない場合、ステップ３が実行される。

２． ブートストラップオペレーションが反復ブートストラップまたは再ブートストラップであるかどうかが判定される（たとえば、ユーザの確認情報を通じて複数のモードで判定されることがある）。ブートストラップオペレーションが反復ブートストラップである場合、ブートストラップオペレーションはキャンセルされる。ブートストラップオペレーションが再ブートストラップである場合、機器管理ツリー上の対応するＤＭＡｃｃ ＭＯの中の管理ノード上のデータが直接的にリフレッシュされる。

３． ブートストラップ情報の中のカウント情報が端末ＤＭツリーの中のＤＭＡｃｃ ＭＯに変換され、アクセス制御リスト（ＡＣＬ）がＤＭＡｃｃ ＭＯについて分配される。

前述の第１の実施形態では、ユーザが再ブートストラップされた（たとえば、機器が交換された）後に端末がブートストラップされたかどうかをサーバが認知できず、それゆえ、先行するユーザの端末情報の影響の下で通常の管理が失敗する可能性があるという課題を効果的に解決するブートストラップ方法が図示されている。第２の実施形態では、サーバが端末のブートストラップモードを取得していない可能性があり、そして、ブートストラップモードに従ってブートストラップの安全性レベルを判断できないことがあるという課題が解決される。第３の実施形態では、同じＳｅｒｖｅｒＩＤが数回に亘ってブートストラップされたとき、同じＳｅｒｖｅｒＩＤに対応する複数のＤＭＡｃｃ ＭＯがブートストラップ競合に起因して端末ＤＭツリーの中に存在する状況を回避し、反復ブートストラップによって引き起こされるアカウント管理の混乱を回避するように、処理方法が提供される。

本開示におけるその後の管理セッションの改良点は以下の通り詳細に明らかにされる。

ＩＩ． 管理セッション

ブートストラップが端末上で成功した後、管理セッションがサーバと端末との間に確立されることが可能であり、管理メッセージがセッションの中で交換されることが可能である。このセッションは、セッション確立段階と管理段階とを含む。セッション確立段階では、同一性が相互に認証され、同時に、端末が、ＤｅｖＩｎｆｏ ＭＯに記憶された端末基本情報を報告する。管理段階では、サーバが、管理アクションを端末へ配信するように、端末の管理ツリー上のＭＯへ保守オペレーションを配送する。機器管理ツリーの管理ノードは、管理ノードのためのサーバのオペレーション権限を制御するためにＡＣＬを有する。

１． サーバが端末機器による管理ツリーへの制限または端末による管理ツリーの実施状況を知ることができるよう、機器記述フレームワーク（ＤＤＦ）が、機器を記述するために採用される。サーバが機器を理解し管理を実行することが必要であるとき、まず、ＤＤＦに従って端末を管理するように機器のＤＤＦが獲得される。しかし、既存のプロトコルでは、サーバ側は端末機器を介して対応するＤＤＦを見つけられない可能性があり、サーバがＤＤＦを獲得することがより困難である。

本開示の実施形態においてＤＤＦを獲得する方法は図４に示される通りであり、以下のステップを含む。

ＤＤＦのユニフォーム・リソース・ロケータ（ＵＲＬ）は端末の管理ツリーに記憶される。

サーバはＵＲＬを通じて端末のＤＤＦを獲得する。

サーバ側によるＤＤＦの獲得を容易に実現するため、ＤＤＦのＵＲＬは、サーバがＵＲＬを通じて端末のＤＤＦを獲得するように、または、ＤＤＦデータが端末の管理ツリーにさらに記憶されるように、端末の管理ツリーに記憶されることがある。このようにして、サーバは、図４の実施形態に限定されることなく、端末から直接的にＤＤＦ情報を獲得することがある。具体的な実例は次の通りである。

端末がＤＤＦのＵＲＬを記憶する実施方法は以下の通りである。管理ノードは端末のＤＭツリーの中に追加され、端末のＤＤＦのＵＲＬは追加された管理ノードの中に記憶される（複数のＤＤＦが存在する可能があり、複数のノードがＵＲＬを記憶するため使用されない可能性がある）。好ましくは、上記記憶アクションは機器の配信の前に達成され、機器の使用中に記憶アクションは実際の状況に従って更新されることがある（たとえば、機器製造業者がＤＤＦの記憶アドレスを更新する）。追加された管理ノードは、既存のＤｅｖＩｎｆｏ ＭＯまたは機器詳細情報（ＤｅｖＤｅｔａｉｌ）ＭＯの中に記憶されてもよく、または、ＭＯとして別々に存在してもよい。ノード特性は表２に示されている通りである。

端末がＤＤＦのＵＲＬを記憶し、そして、管理サーバがＤＤＦを獲得し使用する２つの方法は以下の通りである。

第１の方法では、端末は、最初に、ＤＤＦ管理ノードの値または管理ノードの位置を報告する。具体的な方法は以下の通りである。端末は以下の機会に報告する。

第１の機会では、ある一定のサーバアカウントが端末のため構成された後（たとえば、ブートストラップ後）、端末はサーバへの登録セッション（端末とサーバとの間の第１のセッション）を開始する。このセッションでは、ＤＤＦ管理ノードの値またはＤＤＦ管理ノードの位置が報告される。その後の管理セッションでは、ＤＤＦ管理ノードの値およびＤＤＦ管理ノードの位置は、サーバがそれらを再獲得するためにＧｅｔコマンドを配信しない限り、最初に報告されない（方法２を参照のこと）。好ましくは、管理セッションのセッション要求メッセージは、ＤＤＦ管理ノードの値またはＤＤＦ管理ノードの位置を伝達する。

第２の機会では、端末は、各管理セッションのセッション要求メッセージの中でＤｅｖＩｎｆｏと一緒にＤＤＦ管理ノードの値またはＤＤＦ管理ノードの位置を報告する。

ＤＤＦ管理ノードを記憶する位置が報告される場合、いずれかのその後の管理セッションにおいて、サーバは、ＤＤＦ管理ノードを記憶する位置に従ってＤＤＦ管理ノードの値を獲得する（ＤＤＦ管理ノードの値はＤＤＦのＵＲＬ情報である）。

サーバがＤＤＦのＵＲＬ情報を受信した後、ＤＤＦが必要とされるとき（たとえば、端末の詳細な管理または構成が実施される前）、具体的なＤＤＦ情報がＵＲＬに従って獲得され、端末はＤＤＦに従って生成された管理コマンドに従って管理される。

第２の方法では、サーバはサーバと端末との間で確立された管理セッションにおいて最初にＤＤＦ情報を獲得する。具体的なプロセスは図５に示されている通りであり、具体的なステップは以下の通り明らかにされる。

ステップ１では、ＤＭサーバは、管理プロセスにおいて端末からＤＤＦ管理ノードに記憶されたＵＲＬを獲得する。具体的な方法は以下の通りである。

端末はサーバの命令情報を受信する。命令情報は、サーバによって送信された通知メッセージ（セッション・トリガ・メッセージ）の中で伝達される。命令情報は、端末に、ＤＤＦ管理ノードに記憶された端末ＤＭツリーのＤＤＦのＵＲＬまたは端末によってサポートされたある一定のＭＯのＤＤＦのＵＲＬを報告するよう命令する。その後に、端末は通知の中の情報に従って管理セッションを開始するセッション要求メッセージを生成する。ＵＲＬはセッション要求メッセージの中で報告される。具体的なレポート方法は以下の通りである。警告タイプは端末のために拡張される。ＡｌｅｒｔコマンドはタイプおよびＵＲＬを伝達する。タイプがＭＯのＤＤＦである場合、ＭＯＩＤがさらに伝達されることがある。サーバは警告タイプおよびＭＯＩＤに従ってＵＲＬを特定する。

代替的に、ノードはＤｅｖＤｅｔａｉｌ ＭＯまたは他のＭＯに記憶される。サーバは、確立された管理セッションの中でＧｅｔコマンドを通じてノードの値を獲得する。ＤｅｖＤｅｔａｉｌ ＭＯを一実施例として採用すると、サーバが、ノードと、端末ＤＭツリーの中でノードを記憶するＤｅｖＤｅｔａｉｌ ＭＯのパスとを知らない場合、ノードは以下の方法を通じて検索される。

サーバは端末ＤＭツリーの構造情報を獲得し、構造情報を直接的に分析することにより端末ＤＭツリーの中の管理ノードの位置を検索する。

代替的に、サーバは、以下の通り具体的に、最初に管理ノードのＭＯ（ここでは、ＤｅｖＤｅｔａｉｌ）の位置を獲得する。サーバはＧｅｔコマンドを通じてＤｅｖＤｅｔａｉｌ ＭＯの位置を検索するか、または、ＤｅｖＤｅｔａｉｌの位置情報を端末のＤｅｖＩｎｆｏに記憶する。端末は、（最初のＤＭセッションの中で報告されるか、１回報告されるか、または、各セッションで報告されることがある）セッション要求メッセージの中でＤｅｖＩｎｆｏと一緒にＤｅｖＤｅｔａｉｌ ＭＯの位置（ルート・ノード・パス）をサーバへ報告する。サーバは、ＤｅｖＤｅｔａｉｌの位置およびＤｅｖＤｅｔａｉｌ ＭＯの構造情報（機器管理ツリーの中で獲得されたＤｅｖＤｅｔａｉｌ ＭＯルートノードのパスと、ＤｅｖＤｅｔａｉｌ構造の中のＤｅｖＤｅｔａｉｌルートノードと相対的なＤＤＦ管理ノードの相対パスとを接続することにより形成されたＤＤＦ管理ノードのパス）に従ってＤＤＦ管理ノードの位置を検索する。

ＤＤＦ管理ノードの位置が検索された後、ＧｅｔコマンドがＤＤＦ管理ノードの値を獲得するため配信される。

ステップ２では、端末は、記憶しているＤＤＦのアドレスをＤＭサーバへ返送する。具体的な方法は以下の通りである。ノードがＤｅｖＩｎｆｏ ＭＯに記憶されている場合、端末はセッション要求メッセージの中でアドレスを伝達する。ノードがＤｅｖＤｅｔａｉｌ ＭＯの中に記憶されている場合、端末はサーバによって送信された問い合わせコマンドの結果（リザルト）メッセージの中でＤＤＦアドレスを返送する。

ステップ３では、ＤＭサーバは、ＤＤＦを獲得するため、獲得されたＤＤＦ記憶アドレスに対応するリモートＤＤＦ記憶サーバと通信する。

ステップ４では、リモートＤＤＦ記憶サーバはＤＤＦ記述ファイルをＤＭサーバへ返送する。

ステップ５〜７では、ＤＭサーバは、その後の管理のための基準としてＤＤＦを使用することにより管理アクションを生成し、端末を管理し、端末は実行結果を返送する。

ＤＤＦのその後の獲得のコストを削減するため、ＤＭサーバは獲得されたＤＤＦデータをローカルに一時的に記憶することができる。

端末がＤＤＦを記憶する実施方法は以下の通りである。管理ノードは端末のＤＭツリーの中に追加される。管理ノードは端末ＤＭツリーの中のある一定のＭＯに追加され、ＤＤＦの内容はノードの中に記憶される。値は、機器配信前にノードに割り当てられることがある。機器の使用中に、ＤＭクライアントは実際の状況に従って更新を実行する。好ましくは、ノードはＤｅｖＤｅｔａｉｌ ＭＯに追加される。ノード特性は表３に示されている通りである。

この方法では、サーバは管理プロセスにおいてＤＤＦの内容であるノードの値を獲得する。具体的に、４つの方法が、ノードの値がＤｅｖＤｅｔａｉｌに記憶される実施例を採用することにより、以下の通り例示されている。

第１の方法では、サーバは、以下の通り具体的に、ＤＤＦを獲得するために直接的にＤＤＦの管理ノードの位置を検索する。サーバは、Ｇｅｔコマンドを配信することにより機器管理ツリーの構造をまず獲得し、機器管理ツリーの構造を通じて直接的に管理ノードを検索する。代替的に、端末は、（最初のＤＭセッションで報告されるか、１回だけ報告されるか、または、各セッションの中で報告される）セッション要求メッセージの中で管理ノードの位置をまず報告する。その後、サーバは管理ノードの値（すなわち、ＤＤＦ）を獲得するためコマンドを配信し、値はその後の管理のための基礎として使用される。

第２の方法では、サーバは機器管理ツリーの中のＤｅｖＤｅｔａｉｌの位置をまず獲得し、以下の通り具体的に、ＤＤＦを獲得するようにＤＤＦ管理ノードの位置を間接的に検索する。サーバは、ＤＤＦ管理ノードのＭＯ（ここではＤｅｖＤｅｔａｉｌ）の位置をまず獲得する。サーバは、Ｇｅｔコマンドを配信することにより機器管理ツリーの中のＤｅｖＤｅｔａｉｌ ＭＯの位置を検索するか、または、ＤｅｖＤｅｔａｉｌの位置情報を端末のＤｅｖＩｎｆｏに記憶する。端末は、セッション要求メッセージの中で、（最初のＤＭセッションの中で報告されるか、１回だけ報告されるか、または、各セッションで報告されることがある）ＤｅｖＤｅｔａｉｌ ＭＯの位置（ルート・ノード・パス）をサーバへまず報告する。その後、サーバは、Ｇｅｔコマンドを配信することによって、値（すなわち、ＤＤＦ）を獲得するように、ＤｅｖＤｅｔａｉｌ ＭＯの位置情報および構造を通じてＤＤＦ管理ノードの位置を検索する。ＤＤＦはその後の管理のための基礎として使用される。

第３の方法では、ある一定のサーバアカウントが端末のため構成された後（たとえば、ブートストラップ後）、端末は最初にサーバへの登録セッション（端末とサーバとの間の最初のセッション）を開始する。ＤＤＦはこのセッションにおいて報告される。その後の管理セッションにおいて、ＤＤＦは、サーバが再獲得のためのＧｅｔコマンドを配信しない限り、最初に報告されない。

第４の方法では、端末はサーバの命令情報を受信する。命令情報はサーバによって送信された通知メッセージの中で伝達される。命令情報は、端末にＤＤＦ管理ノードに記憶された端末ＤＭツリーのＤＤＦまたは端末によってサポートされたある一定のＭＯのＤＤＦを報告するよう命令する。その後、端末は、通知の中の情報に従って管理セッションを開始するセッション要求メッセージを生成する。ＤＤＦはセッション要求メッセージの中で伝達され、具体的な実行方法は以下の通りである。警告タイプは端末のため拡張される。警告タイプおよびＤＤＦはＡｌｅｒｔコマンドの中で伝達される。警告タイプがＭＯのＤＤＦである場合、ＭＯＩＤがさらに伝達されることができる。サーバは警告タイプおよびＭＯＩＤに従ってＤＤＦを特定する。

ＤＤＦを獲得する２つの方法が、サーバに対応するＤＤＦをサーバが見つけられない可能性があるという従来技術の課題を解決することができる。特に、ＤＤＦは比較的安定した情報であり、情報は大量であるので、頻繁なレポートはサーバおよびネットワーク伝送に負荷を引き起こす。これらの方法では、必要に応じて、サーバの情報を検索して獲得する能力を提供するように、端末が最初にある一定の条件下でＤＤＦを報告するか、または、サーバが最初にノードを検索してＤＤＦを獲得し、その結果、ネットワークおよびサーバへの負荷は、ＤＤＦを獲得する能力が提供されたままで、最大限に低減される。

２． 管理セッションはサーバと端末との間に確立可能であり、このことはサーバが端末のＤＭツリーへのオペレーションだけを実行可能であることを意味するに過ぎない。しかし、いくつかの機能は、ＳＣＯＭＯのような、具体的なＭＯ、および、端末上の（ＤＭアプリケーションと呼ばれる）クライアントプログラムに依存する必要がある。種々の端末が種々のＤＭアプリケーションをサポートし、これは、具体的なクライアントがその後の使用プロセスにおいて設置された後で配信または能力がサポートされる前は、異なる実施であってもよい。端末がある一定のＤＭアプリケーションをサポートするかどうかは、ＤＭアプリケーション機能が達成可能であるかどうかの根拠となる。したがって、端末はサーバにサポートされているＤＭアプリケーションを通知することが必要である。サーバ管理の困難さは、端末によってサポートされているＤＭアプリケーション（すなわち、ＭＯタイプ）をサーバが見分けられないために増大するという従来技術の課題を解決するため、本実施形態では、管理ノードが端末によってサポートされているＤＭアプリケーションを記録するために端末の管理ツリーに追加される。各ノードは端末によってサポートされるＤＭアプリケーションを記憶する。

図６を参照すると、本実施形態では、追加された管理ノードは、内部ノードおよびそのサブノードを含むように設計されることがある。たとえば、「ＳｕｐｐｏｒｔｅｄＡｐｐ」ノードは、ＤｅｖＩｎｆｏまたはＤｅｖＤｅｔａｉｌ ＭＯの中のノードでもよい内部ノードとして設定される。内部ノードのサブノード「ｘ^＊」は、リーフノードであり、複数のインスタンスを有してもよい。各インスタンスはＤＭアプリケーションに対応する。端末は、このノードを端末の実際の条件に従って維持する。たとえば、ある一定のＤＭアプリケーションが端末に追加される場合、端末はＳｕｐｐｏｒｔｅｄＡｐｐノードの中にリーフノードを追加し、ＤＭアプリケーションの情報を記憶する。各ＭＯは対応するＭＯＩＤを有するので、たとえば、ファームウェアＭＯのＭＯＩＤは“ｕｒｎ：ｏｍａ：ｍｏ：ｏｍａ−ｆｕｍｏ：１．０”であり、サポート対象ＭＯのＭＯＩＤはノードに記憶され、すなわち、．．．／ＳｕｐｐｏｒｔｅｄＡｐｐ／＜ｘ＞ノードの値はＭＯＩＤである。

ＤＭアプリケーションに関して、端末がＤＭアプリケーションをサポートする限り、管理ツリーの中に存在するＤＭアプリケーションの個数（０または１または複数）とは無関係に、ＤＭアプリケーションに関して１個のＭＯＩＤだけがサポート対象ノードの下で追加される。管理プロセスでは、端末によってサポートされたＤＭアプリケーションを獲得するステップは以下の通りである。

ステップＡでは、サーバは、端末によってサポートされたＤＭアプリケーションが獲得されるべきであることを判定する。

ステップＢでは、サーバはサブノードとサブノードの値とを獲得するためにＧｅｔコマンドを端末のＤＭツリーのＳｕｐｐｏｒｔｅｄＡｐｐノードへ送信し、端末は対応する結果を返送する。

ステップＣでは、サーバは、端末によってサポートされたＤＭアプリケーションを判定するために取得されたノード値（ＭＯＩＤ）を分析する。

本実施形態における方法は、サーバが端末によってサポートされたＤＭアプリケーションを認知しないという課題を解決することができ、この方法では、具体的な管理オペレーションは、サーバの管理をより柔軟かつ効率的にするため配信される。

３． 管理プロセスでは、サーバは、具体的な管理機能を実施するためにＭＯの中のノードに対しオペレーションを実行するように端末のＭＯを検索する必要がある。従来技術では、サーバが端末の管理ノードを検索することは非常に困難であり、エアリソースが消費され、サーバは大きな負荷を受ける。本開示では、サーバが端末のＤＭツリーの中でＭＯを検索する効率を改良するため、ＭＯルートノードの位置を検索する方法が提供される。図７に示されているように、この方法は以下のステップを含む。

サーバはＧｅｔコマンドを端末へ送信する。Ｇｅｔコマンドは、獲得されるべきターゲット・オペレーション・パスの情報と値フィルタリング情報とを伝達する。

サーバのＧｅｔコマンドを受信した後、端末は、Ｇｅｔコマンドに対応した、指定されたサブツリーの構造情報およびノードの特性情報を獲得するよう命令される。特性値および構造情報はサーバへ返送される。

図７は、ＭＯアドレス検索の実施形態だけを示している。具体的に、サーバは、Ｇｅｔコマンドを端末へさらに送信することができ、Ｇｅｔコマンドは、検索されるべきＭＯのＩＤを伝達し、検索されるべきサブツリーのルートノードのユニフォーム・リソース識別子（ＵＲＩ）および検索を命令するパラメータを伝達する。パラメータは端末に機器管理ツリーの中のＭＯのＩＤをＭＯのルートノードのＵＲＩへ返送するよう命令する。

Ｇｅｔコマンドの受信後、端末は、ＵＲＩ命令ノードとすべての内部サブノードの中でＩＤを満たすノードとを検索し、対応する結果をサーバへ返送する。

本実施形態では、ＭＯアドレス検索は以下の３つのモードで具体的に実施される。

第１の方法では、管理ツリー構造が返送されるときに同時に特性値が伝達され、具体的には以下の通りであることができる。

サーバはＧｅｔコマンドを端末へ送信する。端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報はＧｅｔコマンドの“Ｔａｒｇｅｔ／ＬｏｃＵＲＩ”要素で伝達される。同時に、獲得されるべき値フィルタリング情報が伝達される。値フィルタリング情報は、端末に、機器管理ツリーの中でルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報と、サブツリーの中の各ノードの指定された特性の特性値とを返送するよう命令する。

伝達されるフィルタ情報のフォーマットは、＜ＵＲＩ＞？ｌｉｓｔ＝Ｓｔｒｕｃｔ＋＜ｐｒｏｐｅｒｔｙ＿ｎａｍｅ＞であってもよい。複合パラメータ中の「Ｓｔｒｕｃｔ」は、端末に、機器管理ツリーの中でＵＲＩによって指示されたノードおよびこのノードのサブノードの構造情報を返送するよう命令する。構造は、端末によって返送されたノードの（“ＬｏｃＵＲＩ”の中で伝達される）ＵＲＩによって表現される。複合パラメータの中の＜ｐｒｏｐｅｒｔｙ＿ｎａｍｅ＞は、ある一定のノードの特性名であり、端末に、ＵＲＩによって指示されたノードおよびこのノードのサブノードの特性の特性値を返送するよう命令する。特性は、ノードタイプ特性、ノードＡＣＬ特性、ノード値フォーマット特性、ノードタイトル特性、ノード値サイズ特性、ノード変更タイムスタンプ（ＴＳｔａｍｐ）特性、または、ノードバージョン番号（ＶｅｒＮｏ）特性のような端末によってサポートされるいかなる特性であってもよい。使用例は以下の通りである。

サーバのＧｅｔコマンドの受信後、端末は、Ｇｅｔコマンドに従って指定サブツリーの構造情報およびノードの特性情報を獲得するよう命令され（獲得中に、サーバが管理ノードのＡＣＬ権限、ここでは、具体的に取得権限（Ｇｅｔ ｒｉｇｈｔ）を有するかどうかが認証される）、次に、構造情報と共に特性値をサーバへ返送する。

特性情報は、Ｇｅｔコマンドに対応する「Ｒｅｓｕｌｔ」コマンドの中で伝達される（異なるノードはＲｅｓｕｌｔ要素の中の異なるＩｔｅｍサブ要素の中に分配されるか、または、それぞれが単一のＩｔｅｍを含む異なるＲｅｓｕｌｔ要素に分配されることがある）。具体的な特性値は、Ｒｅｓｕｌｔ／Ｉｔｅｍ／Ｄａｔａ要素の中で伝達され、返送されることができる。「Ｒｅｓｕｌｔ」コマンドの中の“Ｓｏｕｒｃｅ／ＬｏｃＵＲＩ”要素は、ノードＵＲＩと、特性名を指示するパラメータとを伝達する。その複合は、ＵＲＩ？ｐｒｏｐ＝＜ｐｒｏｅｒｔｙ＿ｎａｍｅ＞である。コマンドの受信後、サーバは、ノードＵＲＩに従って機器管理ツリーの指定された部分の構造を分析し、？ｐｒｏｐ＝＜ｐｒｏｅｒｔｙ＿ｎａｍｅ＞部分からＤａｔａの中で伝達される特性値に対応する特性名を取得し、データ要素から特性値を獲得する。用法は以下の通りである。

機器管理ツリーの中のＭＯのＭＯＩＤはＭＯルートノードのタイプ特性に記憶されるので、複合パラメータの＜ｐｒｏｐｅｒｔｙ＿ｎａｍｅ＞は、タイプ特性に設定され、サブツリー構造が返送されるときと同時に、サブツリーの中のすべてのＭＯＩＤを返送する。具体的に、サーバは、サブツリーの中の各ノードのタイプ特性の値を獲得した後に判定を行う。ノードが内部ノードであり、タイプ特性の値が空でない場合、ノードは、返送された情報からＭＯのルートノードのＵＲＩを獲得するため、ＭＯのルートノードであり且つ空でないタイプ特性の値はＭＯＩＤであると判定される。ＭＯのＵＲＩの獲得後、サーバは、ＭＯの中のノードのより詳細な情報を獲得するためＧｅｔコマンドを送信するか、または、管理コマンドを直接的に送信する。

この方法は、サーバが、非直列化モードにおいて一括して機器管理ツリーの中のある一定の管理サブツリーの中のすべての管理ノードのうちのある一定の特性値を獲得しない可能性がある、という課題を解決することができる。この方法を通じて、ある一定の特性値は、サブツリー構造が獲得されたときに同時に獲得されることができるので、特性獲得のための相互作用は減少され、効率が増大される。同時に、管理サブツリーの中のすべてのＭＯは、特性値をタイプとして指定することにより獲得されることができるので、管理サブツリーの中のすべてのＭＯが効率的に獲得できない可能性がある、という課題が解決される。

第２の方法では、端末は、具体的なＭＯのルートノードを検索し、ルートノードのＵＲＩを返送する。具体的な実施形態は以下の事項を含む。

サーバはＧｅｔコマンドを端末へ送信する。検索されるべきＭＯの識別子（ＭＯＩＤ）はＧｅｔコマンドにおいてＩｔｅｍ／Ｄａｔａ要素の中で伝達される。ＭＯＩＤが検索されるサブツリーのルートノードのＵＲＩと、検索を命令するパラメータとが、Ｉｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩ要素の中で伝達される。パラメータは、端末に、Ｉｔｅｍ／Ｔａｅｇｅｔ／ＬｏｃＵＲＩ要素によって提示された機器管理ツリーのサブツリーのＩｔｅｍ／Ｄａｔａ要素の中で伝達されるＭＯＩＤにより識別されるＭＯの出現するルートノードのＵＲＩを検索するよう命令する。サブツリーのルートノードのＵＲＩと検索を命令するパラメータとを伝達する情報のフォーマットは、ＵＲＩ？ｌｉｓｔ＝ＭＯ＿ＲＯＯＴでもよい。メッセージはＤＭメッセージの中で伝達される。コマンドの具体的な実施例は以下の通りである。

コマンドの受信後、端末は、サーバがＡＣＬ権限（ここでは、Ｇｅｔ権限）を有し、ノードがコマンドの中のルートノードＵＲＩとそのサブノードとに対応する場合に、ノードにおいてＤａｔａ要素の中で伝達されるＭＯＩＤの値をもつＴｙｐｅ特性を有するすべてのノードを検索し、結果（すなわち、検索されたノードのＵＲＩ）をサーバへ返送する。検索プロセスは、内部ノードだけで実行され（すなわち、フォーマット特性はノードである）、リーフノードのためには実行されない。代替的に、端末は、＜ＭＯルートノード、ＭＯＩ＞記憶マッピング表を記憶する。サーバからのＧｅｔコマンドが受信された後、ＭＯ位置はマッピング表から即座に獲得され、結果がサーバへ返送される。結果を返送する方法は以下のステップを含む。

１） 検索条件を満たす１個以上のノードが見つけられる場合、Ｇｅｔコマンドのステータスの後、すべての検索結果（すなわち、ＭＯの出現するルートノードＵＲＩ）がＲｅｓｕｌｔコマンドを通じて返送される。異なるノードがＲｅｓｕｌｔ要素の中の複数のＩｔｅｍ要素の中に分配されてもよく、または、各々が単一のＩｔｅｍを含む異なる結果の中に分配されてもよい。結果は、ＭＯＩＤを伝達してもよく、ＭＯＩＤを伝達しなくてもよい。

ＭＯＩＤを伝達する結果を返送する方法は以下の通りである。結果のＩｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩは、端末によって検索されたノードのＵＲＩを伝達し、同時に、タイプ特性：？ｐｒｏｐ＝Ｔｙｐｅを含むパラメータを伝達し、ＭＯＩＤがＩｔｅｍ／Ｄａｔａの中で伝達される。ＭＯＩＤを伝達する結果を返送する方法は、対応するＧｅｔコマンドの中のＩｔｅｍの個数を制限することがなく、すなわち、サーバは、Ｇｅｔコマンドの中で端末から複数のＭＯＩＤに対応するＭＯの出現するルートノードＵＲＩを検索するため、同じＧｅｔコマンドの中で複数のＩｔｅｍを伝達することがある。具体的な使用例は以下の通りである。

ＭＯＩＤを伝達しない結果の返送方法は以下の通りである。端末によって見つけられたノードのＵＲＩだけが、結果のＩｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩの中で伝達される。ＭＯＩＤを伝達しない結果の返送方法は、結果に対応するＧｅｔコマンドが１個のＩｔｅｍだけを伝達すること、すなわち、サーバがＧｅｔコマンドの中の端末から１個のＭＯＩＤに対応するＭＯの出現するルートノードＵＲＩを検索することを要求する。複数のＩｔｅｍが伝達される場合、サーバは返送された結果に対応するＩｔｅｍを識別することができない。使用例は以下の通りである。

ＭＯのＵＲＩを獲得した後、サーバは、ＭＯの中のノードのより詳細な情報を獲得するためＧｅｔコマンドを送信するか、または、管理コマンドを直接的に送信することがある。

２） 条件を満たすノードが見つからない場合（たとえば、Ｇｅｔコマンドの中のターゲットＵＲＩがリーフノードを参照するか、または、Ｇｅｔコマンドの中のターゲットＵＲＩが内部ノードを参照するとしても、ターゲットＵＲＩにルートがあるサブツリーの中のＭＯＩＤによって識別されたＭＯが発生しない場合）、結果は返送されず、「４０４ Ｎｏｔ Ｆｏｕｎｄ」がＧｅｔコマンドに対応する「Ｓｔａｔｕｓ」コマンドの中で返送される。

端末が具体的なＭＯのルートノードを検索し、ルートノードのＵＲＩを返送する第２の方法では、具体的なＭＯＩＤは指定されない可能性があり、すなわち、ＧｅｔコマンドのＩｔｅｍ要素はデータサブ要素を含まないことがある。コマンドを受信した後、端末は、ターゲットＵＲＩに対応するノードの下で、すべてのＭＯのＭＯＩＤとＭＯのルートノードＵＲＩとを検索し、結果を返送する。検索方法は以下の通りでもよい。ターゲットＵＲＩに対応するノードのすべての内部サブノードの中で、空でないタイプ特性値を有する（すなわち、ノードのＦｏｒｍａｔ特性値がノードである）すべてのノードが検索されるか、または、マッピング表が端末で維持される。サーバのＧｅｔコマンドを受信するとき、端末はマッピング表の中で直接的に検索を行う。結果を返送する方法は、ＭＯＩＤを伝達する結果を返送する方法と同じである。

第３の方法では、端末に対応する管理ツリーはサーバ側で維持される。Ｒｅｐｌａｃｅ、Ｃｏｐｙ、ＤｅｌｅｔｅおよびＡｄｄのような機器管理ツリーによって送信された管理ツリーノードを変更するコマンドに従って、オペレーションが成功したとき、サーバはサーバによって記憶されている対応する管理ツリーを維持する。機器管理ツリーの構造が取得される必要があるとき、サーバは、ターゲット・オペレーション・ノードのＵＲＩを判定するため、サーバ側で維持されたターゲット・オペレーション端末サブツリーの構造をまず獲得し、管理コマンドを生成し、コマンドをターゲット・オペレーション端末へ配信する。

本実施形態では、この方法は、サーバが、端末ＤＭツリーの中でＭＯの位置を検索することが困難であるという課題を解決する。サーバが端末ＤＭツリーの中でＭＯの位置を検索する作業は、サーバと端末との間で分担されるので、ＭＯを検索する複雑なロジックは端末によってローカルに達成され、このことは、サーバが端末ＤＭツリーの中でＭＯの位置を効果的に検索する効率を改良し、管理オペレーション中の相互作用を削減し、管理効率を改良し、サーバおよびネットワーク伝送への負荷を軽減する。

４． 管理プロセスでは、サーバによって端末へ配信された管理コマンドは、同じ管理コマンドが端末の複数の管理ノードで動作する機能を達成するために、複数のＩｔｅｍを伝達することがある。たとえば、Ｒｅｐｌａｃｅの文法は、＜！ＥＬＥＭＥＮＴ Ｒｅｐｌａｃｅ（ＣｍｄＩＤ，ＮｏＲｅｓｐ？，Ｃｒｅｄ？，Ｍｅｔａ？，Ｉｔｅｍ＋）＞であり、すなわち、Ｒｅｐｌａｃｅコマンドは、端末に、複数の管理ツリーノードのためのＲｅｐｌａｃｅアクションを実行するよう命令するために、複数のＩｔｅｍを伝達する。ある場合には、複数のＩｔｅｍが端末で順次処理されるべきであり、ある場合には、非順次に処理されることがある。サーバは、端末に、管理コマンドの中の複数のＩｔｅｍを順次実行するように命令するため、実行が順次であるかどうかを判定する。

図８の実施形態に示されているように、以下のステップを含むコマンドの実行モードを管理する方法が提供される。

管理コマンドの中の複数のサブコマンドを順次実行する命令は、サーバによって送信された管理コマンドの中で伝達される。

管理コマンドの受信後、端末は、順次実行の命令を解析し、管理コマンドの中の各サブアイテムに対応する管理ノードで管理コマンドアクションを順次実行する。

具体的に、Ｉｔｅｍを順次実行する命令は、サーバによって端末へ配信される管理コマンドの中で伝達される。伝達方法は以下の通りである（Ｒｅｐｌａｃｅコマンドが実施例として採用され、他の管理コマンドの伝達方法はＲｅｐｌａｃｅコマンドに類似している）。

特性はＩｔｅｍ要素の親要素の中で伝達される。特性は、サブ要素が順次実行されることを示す。管理コマンドのＲｅｐｌａｃｅを実施例として採用すると、Ｒｅｐｌａｃｅのための命令特性を定義するＤＴＤは、＜！ＡＴＴＬＩＳＴ Ｒｅｐｌａｃｅ ｏｒｄｅｒ（Ｓｅｑｕｅｎｃｅ｜Ａｎｙ）“Ａｎｙ”＞であってもよい。特性順序の値は以下の意味をもつ。“Ａｎｙ”は、端末の実行ノードが制限されないことを表現する。“Ｓｅｑｕｅｎｃｅ”は、端末が順次実行のため命令されることを表現する。特性が追加された後の実施例は以下の通りである。

命令のサブ要素はＩｔｅｍ要素の親要素の中に追加され（要素はＩｔｅｍ要素の兄弟要素である）、サブ要素が追加された後のＤＴＤは、＜！ＥＬＥＭＮＴ Ｒｅｐｌａｃｅ（ＣｍｄＩＤ，ＮｏＲｅｓｐ？，Ｃｒｅｄ？，Ｍｅｔａ？，Ｏｒｄｅｒ？，Ｉｔｅｍ＋）＞として定義される。

シェル要素（すなわち、管理コマンドのサブ要素、および、同時にＩｔｅｍの親要素）は、Ｉｔｅｍが順次実行されるため追加される。シェル要素は、シェルの中の要素が順次実行される必要がないことを端末に通知するだけである。

端末がＲｅｐｌａｃｅコマンドの中で伝達されるアイテムを順次実行する命令を解析した後、Ｒｅｐｌａｃｅコマンドはアイテム命令ノードのため順次実行される。

本実施形態における方法は、サーバが端末に管理コマンドの中の複数のターゲット・オペレーション・アイテムに対し管理コマンドを順次実行するよう命令しない可能性がある、という課題を解決することを目指し、この方法では、サーバは端末による管理コマンドの実行モードを柔軟に制御し、実行エラーの可能性を低下させることがある。

５． ＤＭの管理アクションが実行される前に、管理セッションはまずサーバと端末との間に確立されることが必要である。すべての管理コマンドは管理セッションにおいて達成される。サーバまたは端末がアクションを処理するために長時間を要することがある。代替的に、管理アクションが近いうちに送信されるべきことが期待される。セッションを再確立するコストを削減するため、現在のセッションが維持されることがある。図９において実施形態に示されているように、以下のステップを含む管理セッションを維持する方法が提供される。

セッション維持コマンドが管理セッションの中で反対端へ送信されるべきことが判定されるとき、サーバまたは端末は、セッション維持コマンドを伝達するメッセージを反対端へ送信する。

メッセージの受信後、反対端は肯定応答メッセージを返送し、セッション維持コマンドに対応するオペレーションを実行する。

本実施形態では、以下の通り具体的に、２つの維持方法がセッションのため設計される。

セッション中の中断を回避するため、セッション維持コマンドが設計されることがある。セッション維持アクションが実行されるべきことが判定されるとき（たとえば、データ処理の所要時間が長いと判定されたとき）、サーバまたは端末は、“ＳｙｎｃＭＬ”メッセージを他の当事者へ送信する。メッセージはセッション維持コマンドを伝達し、他の当事者は肯定応答を用いて応答する。プロセスは、セッション維持コマンドの送信者が大量の管理コマンドを他の当事者へ送信するか、または、他の当事者にセッションを終了することを通知するまで、必要に応じて反復的に実行されることがある。セッション維持コマンドを伝達する“ＳｙｎｃＭＬ”メッセージが他の管理コマンドを含む場合、他の当事者はセッション維持コマンドを無視することができる。

図１０において実施形態に示されているように、サーバがセッション維持コマンドを送信することを実施例として採用して、セッションを維持するプロセス（端末がセッション維持コマンドを送信するプロセスは類似しているので、その説明はここでは省略されている）が説明される。

ステップ２１では、認証が端末およびサーバで実行され、管理セッションが端末とサーバとの間で確立される。

ステップ２２では、ＤＭコマンドの相互作用が両当事者のために実行される。

ステップ２３では、サーバは、受信した管理コマンドを処理し、内部データ処理を実行し、セッションが待機する。

ステップ２４では、サーバが、（サーバ内部の処理所要時間がセッション中断またはタイムアウトを引き起こす場合）セッションは維持されるべきであると判定したとき、サーバはセッション維持コマンドを送信する。

ステップ２５では、端末は、セッション維持コマンド肯定応答メッセージを送信し、両当事者はサーバ側が新しい管理メッセージを送信するまでセッションを維持する。管理メッセージは管理コマンドもしくはセッション維持コマンドを伝達するか、または、管理メッセージは管理コマンドを伝達しない空メッセージである。

ステップ２６では、サーバは端末データの処理を終了し、処理結果に従って端末へ送信されるべき管理コマンドを生成する。

具体的に、セッション維持コマンドはＡｌｅｒｔコマンドを使用してもよく、新しいタイプコード“Ａｌｅｒｔ Ｃｏｄｅ”はＡｌｅｒｔコマンドのため設計されてもよい。コードの意味は表４に示されている通りである。

コマンドの具体的な使用例は以下の通りである。

セッション維持コマンドは他のデータ（たとえば、Ｉｔｅｍ）を伝達しないことがある。サーバによって送信されたセッション維持コマンドを受信した後、端末は大量の管理コマンドを実行することはなく、以下の通りの肯定応答メッセージがそのコマンドに対し返送される。

実施形態は、一方の当事者が、もう一方の当事者はセッションを維持するよう命令されるべきであると判定したとき、一方の当事者がセッション維持コマンドを反対端へ送信する課題を解決し、セッションの異常な中断を減少し、効率を改善する。

端末機器の管理はクライアント／サーバ（Ｃ／Ｓ）モードに属している。サーバは、管理アクションが配信されるべきであるかどうかと、配信されるべき管理アクションと、を判定する。サーバは支配的な地位にある。したがって、ＤＭにおけるセッションの終了はサーバによって判定される。

本開示の実施形態では、セッションを終了させる命令をするコマンドが設計される。コマンドはサーバによって端末へ送信される。コマンドは端末へ配信されるべきパケットの中に別々に収容されるか、または、サーバによって端末へ配信されるべき管理コマンドの最終的なグループと共にパッケージ化され、その後に、端末へ送信されてもよい。前者のモードでは、端末はコマンドを受信した後にセッションを正常に終了する。後者のモードでは、端末は、まずパケットの中の他の管理コマンドを実行し、実行が完了した直後にセッションを終了し、関連した管理コマンドの実行結果はサーバへ返送されない。端末は、サーバが必要に応じて結果を獲得するように、最終的なパケットの中に管理コマンドの実行結果を一時的に記憶することもある。セッションを終了させる命令をするコマンドはＡｌｅｒｔコマンドを通じて実施されてもよく、具体的なＣｏｄｅは、Ａｌｅｒｔコマンドがセッションを正常に終了させることを命令するため設計される必要があり、たとえば、Ｃｏｄｅは１２１０である。

従来技術では、セッションが終了されるべきであるかどうかを判定する方法は以下の通りである。端末は、サーバが空メッセージを送信した場合にセッションを終了する。命令は端末にとって不明確であり、端末の正確な管理に悪影響を与える。本実施形態で設計された具体的な終了命令コマンドは、端末の正確な管理を実現しやすくする。

６． 端末で、ある一定のＭＯは複数のインスタンスを有することが可能である。しかし、時々、ＭＯインスタンスが一つのみアクティブ化される。たとえば、端末リソース・オペレーション・タイプのＭＯに対し、端末リソースは制限され、排他的であるので、複数のＭＯインスタンスが同時にまたはある一定の期間の範囲内に存在する場合、リソースは、１個のＭＯインスタンスだけによって占有されて作動（すなわち、アクティブ化）されることがある。他のＭＯインスタンスを通じてサーバによって配信された管理アクションは拒絶され、エラーコード４０３、４０５または５００が返送される。従来技術では、複数のＭＯインスタンスが端末の中に存在するとき、サーバは現在アクティブ化されているインスタンスを認知しないので、サーバ管理の難しさが増加する。図１１に示されているように、以下のステップを含む端末アクティブ化ＭＯを取得する方法が提供される。

端末が端末リソースをＭＯインスタンスに割り当てるか、または、端末がＭＯインスタンスをアクティブ化して使用し、すなわち、ＭＯインスタンスは現在利用できるＭＯとしての機能を果たす。

ＭＯインスタンスをローカルに記録するとき、サーバは、端末アクティブ化ＭＯを獲得するためにセッション管理プロセスの中でＧｅｔコマンドを端末へ送信する。端末はアクティブ化ＭＯに関する情報をサーバへ返送する。

本実施形態では、現在アクティブ化されているＭＯインスタンス（すなわち、端末リソースを現在占有中であり、かつ、端末リソースを動作させることができるＭＯ）を指示する２つの方法は以下の通りである。

端末はアクティブ化ＭＯリストをローカルに維持する。アクティブ化ＭＯリストは機器管理ツリーの中に表現されていない。サーバは、Ｇｅｔコマンドを端末のルートノードへ送信し、パラメータを伝達することによりデータを獲得する。

Ｇｅｔコマンドの中で伝達されるパラメータは、たとえば、．？ｌｉｓｔ＝ＡｃｔｉｖｅｄＲｅｓｏｕｒｃｅＭＯとして設計されてもよいＧｅｔ／Ｉｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＬの中で伝達されてもよい。端末は、端末リソースに対応し、アクティブ化されたＭＯのルートノードのＵＲＩを返送する。サーバは、ある一定のタイプの具体的なＭＯを返送するよう端末に命令するために、コマンドのアイテムの中でデータ要素を伝達してもよく、データ要素の値はＭＯＩＤである。使用例は以下の通りである。

端末は、アクティブ化ＭＯインスタンスの情報を管理ツリーに記憶し、具体的には以下の事項を含む。

ａ． 管理ツリーのサブツリーは機器管理ツリーの中に追加される。端末のすべてのアクティブ化ＭＯのルートノードのＵＲＩリストは、管理ツリーのサブツリーに記憶される。追加された管理サブツリーは図１２に示されている通りであり、アクティブ化ＭＯリストが記憶される管理サブツリーはＤｅｖＤｅｔａｉｌ ＭＯに記憶されてもよい。サーバは、端末アクティブ化ＭＯを取得するために、値を獲得するため直接的にＧｅｔコマンドをアクティブ化ＭＯノードのサブノードに配信してもよい。具体的なコマンドおよびオペレーションは他のノードのコマンドおよびオペレーションに類似しているので、ここではそれらの説明は省略される。

ｂ． ＭＯインスタンスがアクティブ化ＭＯインスタンスであるかどうかがＭＯインスタンスのルートノードのノード特性値に記録される。その後、サーバは、ＭＯインスタンスがアクティブ化ＭＯインスタンスであるかどうかを判定するために直接的にＭＯのルートノードの特性値を獲得する。具体的な方法は以下の通りである。

既存のＭＯのルートノードのタイプ特性値の構造が拡張される。変更された値構造は複合値を伝達することができる。複合値は、ＭＯＩＤフィールドと、ＡｃｔｉｖａｔｅｄまたはＤｅａｃｔｉｖａｔｅｄフィールドの２つのフィールドを含む。２つのフィールドはプラス符号で繋がれる。使用例は以下の通りである。

ある一定のＭＯのアクティブ化状態のルートノードのＴｙｐｅ特性値はＭＯＩＤ＋Ａｃｔｉｖａｔｅｄである。

端末は、機器管理ツリーの中のＭＯのアクティブ化状態を判定し、ＭＯのルートノードのタイプ特性値を維持する。

端末のアクティブ化ＭＯを取得するとき、サーバは、値を獲得するためにＧｅｔコマンドをＭＯのルートノードのＴｙｐｅ特性に送信し、その後、ＭＯインスタンスがアクティブ化ＭＯであるかどうかを判定するためＡｃｔｉｖａｔｅｄ／Ｄｅａｃｔｉｖａｔｅｄフィールドの値を抽出する。

本実施形態では、端末がアクティブ化ＭＯを特定し、その後、サーバがアクティブ化ＭＯを獲得する方法が提供され、アクティブ化ＭＯが識別されないので、サーバがＭＯをアクティブ化するため即座にオペレーションを検索しない可能性があるという従来技術における課題を解決し、その結果、管理効率が改良される。

本開示は異なる形式で複数の特定の実施形態を有する。以下、本開示の技術的解決手段が図２ないし１２を参照して説明される。これは、本開示の具体的な実施例が実施形態による具体的なプロセスまたは構造だけに限定されることを意味しない。当業者には上述された具体的な実施が多数の好ましい解決手段の中のいくつかの実施例に過ぎないことを理解されたい。

実施形態では、本開示は、第１の受信モジュールおよび構成モジュールを含むＤＭ端末を提供する。第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。

さらに、本実施形態は警告モジュールおよび第１の記録モジュールをさらに含んでもよい。警告モジュールは、端末のブートストラップまたは再ブートストラップのための警告情報を伝達するセッション要求メッセージをサーバへ送信するよう適合される。第１の記録モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバのサーバアカウントＭＯの管理ノードに記録するよう適合される。

構成モジュールは、検索ユニット、第１の処理ユニット、および第２の処理ユニットを含む。検索ユニットは、ＳｅｒｖｅｒＩＤに対応するサーバアカウントＭＯが端末ＤＭツリーの中に存在するかどうかを検索するよう適合する。第１の処理ユニットは、ブートストラップが反復ブートストラップまたは再ブートストラップであるかどうかを区別し、検索ユニットが端末ＤＭツリーの中でＳｅｒｖｅｒＩＤに対応するサーバアカウントＭＯを見つけたときに、対応するオペレーションを実行するよう適合する。第２の処理ユニットは、検索ユニットが端末ＤＭツリーの中のＳｅｒｖｅｒＩＤに対応するサーバアカウントＭＯを見つけることに失敗したとき、ブートストラップ情報に従って端末ＤＭツリーの中のサーバのサーバアカウントＭＯを生成するよう適合される。

実施形態では、本開示は、第１の受信モジュールおよび認証モジュールを含むＤＭ装置を提供する。第１の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを受信するよう適合される。認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。

実施形態では、本開示は、第１の送信モジュールおよび第１の獲得モジュールを含む別のＤＭ装置を提供する。第１の送信モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバアカウントＭＯに記録する管理ノードの値を獲得するためにＧｅｔコマンドを送信するよう適合される。第１の獲得モジュールは構成モード情報を獲得するよう適合される。

実施形態では、本開示は、端末およびサーバを含むブートストラップシステムを提供する。端末は、第１の受信モジュール、構成モジュール、および警告モジュールを含む。第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。警告モジュールは、端末のブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを送信するよう適合される。サーバは第１の受信モジュールおよび認証モジュールを含む。第１の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを受信するよう適合される。認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。

実施形態では、本開示は、端末およびサーバを含む別のブートストラップシステムを提供する。端末は、第１の受信モジュール、構成モジュール、および第１の記録モジュールを含む。第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。第１の記録モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバのサーバアカウントＭＯの管理ノードに記録するよう適合される。サーバは、第１の送信モジュールおよび第１の獲得モジュールを含む。第１の送信モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバアカウントＭＯに記録する管理ノードの値を獲得するためにＧｅｔコマンドを送信するよう適合される。第１の獲得モジュールは構成モード情報を獲得するよう適合される。

実施形態では、本開示は、作成モジュールおよび第２の記録モジュールを含む別のＤＭ端末を提供する。作成モジュールは管理ノードを端末のＤＭツリーに追加するよう適合される。第２の記録モジュールは、端末によってサポートされたＤＭオブジェクトタイプを端末のＤＭツリーに追加された管理ノードに記録するよう適合される。

実施形態では、本開示は、第２の獲得モジュールおよび決定モジュールを含む別のＤＭ装置を提供する。第２の獲得モジュールは、端末との管理セッションにおいて端末のＤＭツリーに追加された端末によってサポートされたＤＭオブジェクトタイプを記録する管理ノードの値を獲得するよう適合される。決定モジュールは管理ノードの値に従って端末によってサポートされたＤＭオブジェクトタイプを判定するよう適合される。

実施形態では、本開示は、端末およびサーバを含む管理端末システムを提供する。端末は、作成モジュールおよび第２の記録モジュールを含む。作成モジュールは管理ノードを端末のＤＭツリーに追加するよう適合される。第２の記録モジュールは、端末によってサポートされたＤＭオブジェクトタイプを端末のＤＭツリーに追加された管理ノードに記録するよう適合される。サーバは、第２の獲得モジュールおよび決定モジュールを含む。第２の獲得モジュールは、端末との管理セッションにおいて端末のＤＭツリーに追加された端末によってサポートされたＤＭオブジェクトタイプを記録する管理ノードの値を獲得するよう適合される。決定モジュールは管理ノードの値に従って端末によってサポートされたＤＭオブジェクトタイプを判定するよう適合される。

実施形態では、本開示は、第２の受信モジュールおよび実行モジュールを含むＤＭ端末をさらに提供する。第２の受信モジュールは、端末ＤＭツリーのターゲット・オペレーション・ノードを伝達するパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報のＧｅｔコマンドとを受信するよう適合される。実行モジュールは、ターゲット・オペレーション・ノードのパス情報および値フィルタリング情報に従ってサブツリーの構造情報、および、サブツリーの中の各ノードの特性値を獲得し、特性値および構造情報を返送するよう適合される。

実施形態では、本開示は、第２の送信モジュールおよび第３の受信モジュールを含む別のＤＭ装置を提供する。第２の送信モジュールは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報とを伝達するＧｅｔコマンドを送信するよう適合される。第３の受信モジュールは、サブツリーの構造情報と、端末によって返送されたサブツリーの中の各ノードの特性値とを受信するよう適合される。

実施形態では、本開示は、端末およびサーバを含み、管理ノード特性を獲得するシステムを提供する。端末は、第２の受信モジュールおよび実行モジュールを含む。第２の受信モジュールは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報のＧｅｔコマンドとを受信するよう適合される。実行モジュールは、ターゲット・オペレーション・ノードのパス情報および値フィルタリング情報に従って、サブツリーの構造情報、および、サブツリーの中の各ノードの特性値を獲得し、特性値および構造情報を返送するよう適合される。サーバは、第２の送信モジュールおよび第３の受信モジュールを含む。第２の送信モジュールは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報とを伝達するＧｅｔコマンドを送信するよう適合される。第３の受信モジュールは、サブツリーの構造情報と、端末によって返送されたサブツリーの中の各ノードの特性値とを受信するよう適合される。

実施形態では、本開示は、第４の受信モジュールおよび検索モジュールを含む別のＤＭ端末を提供する。第４の受信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを受信するよう適合される。検索モジュールは、検索されるべきサブツリーの中でＭＯを検索し、見つけられたＭＯのルート・ノード・パスを返送するよう適合される。

実施形態では、本開示は、第３の送信モジュールおよび第５の受信モジュールを含む別のＤＭ装置を提供する。第３の送信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを送信するよう適合される。第５の受信モジュールは、端末によって返送された検索されるべきサブツリーの中のＭＯのルート・ノード・パスを受信するよう適合される。

本開示は、端末およびサーバを含み、ＭＯアドレスを検索するシステムを提供する。端末は、第４の受信モジュールおよび検索モジュールを含む。第４の受信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータと、を伝達するＧｅｔコマンドを受信するよう適合される。検索モジュールは、検索されるべきサブツリーの中でＭＯを検索し、見つけられたＭＯのルート・ノード・パスを返送するよう適合される。サーバは、第３の送信モジュールおよび第５の受信モジュールを含む。第３の送信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータと、を伝達するＧｅｔコマンドを送信するよう適合される。第５の受信モジュールは、端末によって返送された検索されるべきサブツリーの中のＭＯのルート・ノード・パスを受信するよう適合される。

当業者には、実施形態による方法のステップの全部または一部が関連したハードウェアに命令するプログラムによって実施されることがあることを理解されたい。プログラムはコンピュータ読み取り可能な媒体に記憶されることができる。プログラムが実行されるとき、実施形態による方法のステップが実行される。記憶媒体は、リード・オンリ・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気ディスクまたは光ディスクのようなプログラムコードを記憶することができる媒体であればどのような媒体であってもよい。

最後に、上記実施形態は本開示の技術的解決手段を単に説明するために与えられているだけであり、本開示を限定することを意図しないことに注意を要する。本開示は実施形態を参照して詳細に記載されているが、本開示の精神および範囲から逸脱しない限り、実施形態に記載された技術的解決手段に対する変更、または、技術的解決手段のいくつかの技術的特徴に対する等価的な置換が行われることがあることが当業者には理解されたい。

Claims (19)

1. サーバと端末との間に管理セッションを確立し、
   前記サーバによって、検索されるべき管理オブジェクトの識別子（ＭＯＩＤ）を伝達するＩｔｅｍ／Ｄａｔａ要素を伝達し、機器管理ツリーの中のサブツリーのルートノードＵＲＩを伝達するＩｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩ要素と、前記サブツリーの中の管理オブジェクト（ＭＯ）の出現する前記ルートノードＵＲＩを検索して返送するよう前記端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを前記端末へ送信し、
   前記端末によって、前記Ｇｅｔコマンドを受信し、前記サブツリーの中で前記サーバによりアクセス権限が保有されている前記ＭＯの出現を検索し、前記サブツリーの中で前記サーバによりアクセス権限が保有されている前記ＭＯの出現を検索することは、前記サーバによるＧｅｔ権限を保有するすべてのノードであって、且つ、前記コマンドの中の前記ルートノードＵＲＩに対応する前記ノードおよびそのサブノードにおいて前記Ｄａｔａ要素で伝達される前記ＭＯＩＤの値をもつＴｙｐｅ特性を有するすべてのノードを前記端末によって検索することを含み、
   前記端末によって、前記端末が前記ＭＯの１回以上の出現を見つけたとき、前記Ｇｅｔコマンドのステータス情報と、前記ステータス情報の後に続いて前記見つけられたＭＯの前記ルートノードＵＲＩとを前記サーバへ返送する、
   ことを備える、機器管理の方法。
2. 前記端末によって、前記見つけられたＭＯの前記ルートノードＵＲＩを前記サーバへ返送することが、
   前記端末が前記ＭＯの１回以上の出現を見つけたとき、前記端末によって、Ｒｅｓｕｌｔコマンドの複数の「Ｉｔｅｍ」要素で伝達されるか、または、単一の「Ｉｔｅｍ」要素を含む複数のＲｅｓｕｌｔコマンドで伝達される前記見つけられたＭＯの前記ルートノードＵＲＩを返送することを含み、前記ＭＯＩＤは返送されない
   請求項１に記載の方法。
3. 前記検索命令パラメータが前記Ｇｅｔコマンドの前記Ｉｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩ要素の「リスト」コマンドとして前記端末へ配信される請求項１に記載の方法。
4. 前記サーバと前記端末との間に前記セッションを確立する前に、
   ＳｍａｒｔＣａｒｄモードにおいて前記端末の前記機器管理ツリーへの前記サーバのアカウント情報を含むブートストラップ情報を構成することをさらに備える
   請求項１に記載の方法。
5. 前記サーバによって、ＯＴＡモードにおいて前記アカウント情報のパスワードおよびノンスのうち少なくとも一つを更新するためにＤＭコマンドを前記端末へ配信し、
   前記端末によって、前記端末の前記機器管理ツリーのＤＭＡｃｃ ＭＯに保存されたパスワードおよびノンスのうちの少なくとも一つを更新するために前記サーバからＤＭコマンドを受信し、
   前記端末によって、前記端末の前記機器管理ツリーの前記ＤＭＡｃｃ ＭＯに保存された前記パスワードおよびノンスのうちの少なくとも一つの更新後にＳｍａｒｔＣａｒｄオペレーションコマンドを通じて自動的に前記ＳｍａｒｔＣａｒｄのブートストラップファイルの中の対応するパスワードおよびノンスのうちの少なくとも一つを更新する、
   ことをさらに備える請求項４に記載の方法。
6. 前記端末によって、前記更新されたブートストラップファイルを用いてその後のブートストラップを実行し、
   前記サーバによって、前記サーバと前記更新されたブートストラップファイルによってブートストラップされた前記端末との間に前記管理セッションを確立するとき、前記更新されたパスワードおよびノンスのうちの少なくとも一つを用いて前記端末を認証する、
   ことをさらに備える請求項５に記載の方法。
7. 前記端末によりサポートされたＤＭ ＭＯのタイプを前記機器管理ツリーの中の追加された管理ノードに記憶し、
   前記サーバと前記端末との間に前記管理セッションを確立した後に、
   前記サーバによって、前記管理ノードに記憶された値を検索し、前記管理ノードに記憶された前記値に従って前記端末によりサポートされたＤＭ ＭＯのタイプを判定する、
   ことをさらに備える請求項１に記載の方法。
8. 前記端末によりサポートされたＤＭ ＭＯのタイプを追加された管理ノードに記憶することが、
   前記端末によりサポートされたＤＭ ＭＯのタイプを記憶するため管理ノードを追加し、
   前記端末によりサポートされたＤＭ ＭＯの識別子を前記追加された管理ノードに記憶する、
   ことを含む請求項７に記載の方法。
9. 前記管理ノードが前記ＤＭツリーの中のＤｅｖＤｅｔａｉｌ ＭＯに追加され、
   前記サーバによって、前記管理ノードに記憶された値を検索することが、
   前記サーバによって、Ｇｅｔコマンドを、前記管理セッションにおいて前記端末の前記機器管理ツリーの前記ＤｅｖＤｅｔａｉｌ ＭＯの中の追加された管理ノードへ送信し、
   前記端末によって、前記Ｇｅｔコマンドに従って前記管理ノードに記憶された値を返送する、
   ことを含む請求項８に記載の方法。
10. 検索されるべき管理オブジェクト（ＭＯ）の識別子（ＩＤ）（ＭＯＩＤ）を伝達するＩｔｅｍ／Ｄａｔａ要素、機器管理ツリーの中のサブツリーのルートノードＵＲＩを伝達するＩｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩ要素、および、前記サブツリーの中の前記ＭＯの出現する前記ルートノードＵＲＩを検索して返送するよう端末に命令する検索命令パラメータを伝達するＧｅｔコマンドを受信するよう適合された受信モジュールと、
    サーバが前記サブツリーの中でアクセス権限を有する前記ＭＯの出現を検索し、前記サブツリーの中で前記サーバがアクセス権限を保有する前記ＭＯの出現を検索することが、前記サーバがＧｅｔ権限を保有するすべてのノードであって、且つ、前記Ｇｅｔコマンドの中の前記ルートノードＵＲＩに対応する前記ノードおよびそのサブノードにおいて前記Ｄａｔａ要素で伝達されるＭＯＩＤの値をもつＴｙｐｅ特性を有するすべてのノードを検索することを含み、前記ＭＯの１回以上の出現を見つけたとき、前記Ｇｅｔコマンドのステータス情報と、前記ステータス情報の後に続いて前記見つけられたＭＯの前記ルートノードＵＲＩとを前記サーバへ返送するよう適合された検索モジュールと、
    を備える、機器管理（ＤＭ）端末。
11. 前記端末によりサポートされたＤＭ ＭＯのタイプを前記端末の前記ＤＭツリーの中の追加された管理ノードに記憶するよう適合された記録モジュールをさらに備える請求項１０に記載の端末。
12. ＳｍａｒｔＣａｒｄモードにおいて前記端末の前記機器管理ツリーへの前記サーバのアカウント情報を含むブートストラップ情報を構成するモジュールをさらに備える
    請求項１１に記載の端末。
13. 前記端末の前記機器管理ツリーのＤＭＡｃｃ ＭＯに保存されたパスワードおよびノンスのうちの少なくとも一つを更新するために前記サーバからＤＭコマンドを受信するよう適合されたモジュールと、
    前記端末の前記機器管理ツリーの前記ＤＭＡｃｃ ＭＯに保存された前記パスワードおよびノンスのうちの少なくとも一つの更新後にＳｍａｒｔＣａｒｄオペレーションコマンドを通じて自動的に前記ＳｍａｒｔＣａｒｄのブートストラップファイルの中の対応するパスワードおよびノンスのうちの少なくとも一つを更新するよう適合されたモジュールと、
    をさらに備える請求項１２に記載の端末。
14. 前記更新されたブートストラップファイルを用いてその後のブートストラップを実行するよう適合されたモジュールと、
    前記サーバによって、前記サーバと前記更新されたブートストラップファイルによってブートストラップされた前記端末との間に前記管理セッションを確立するとき、前記更新されたパスワードおよびノンスのうちの少なくとも一つを用いて前記端末を認証するよう適合されたモジュールと、
    をさらに備える請求項１３に記載の端末。
15. 前記端末によりサポートされたＤＭ ＭＯのタイプを前記機器管理ツリーの中の追加された管理ノードに記憶するよう適合されたモジュールを更に備える
    請求項１３に記載の端末。
16. 前記端末によりサポートされたＤＭ ＭＯのタイプを追加された管理ノードに記憶するモジュールが、更に、
    前記端末によりサポートされたＤＭ ＭＯのタイプを記憶するため管理ノードを追加するよう適合されたモジュールと、
    前記端末によりサポートされたＤＭ ＭＯの識別子を前記追加された管理ノードに記憶するよう適合されたモジュールと、
    を備える請求項１５に記載の端末。
17. 機器管理ツリーの中のサブツリーの中でサーバによりアクセス権限が保有されているＭＯの出現を端末によって検索させ、該アクセス権限が保有されているＭＯの出現を検索することは、サーバによるＧｅｔ権限を保有するすべてのノードであって、且つ、Ｇｅｔコマンドの中のルートノードＵＲＩに対応するノードおよびそのサブノードにおいてＤａｔａ要素で伝達されるＭＯＩＤの値をもつＴｙｐｅ特性を有するすべてのノードを検索することを含み、前記端末が前記ＭＯの１回以上の出現を見つけたとき、Ｇｅｔコマンドのステータス情報と、前記ステータス情報の後に続いて前記見つけられたＭＯのルートノードＵＲＩとを前記サーバへ前記端末によって返送させるため、検索されるべき管理オブジェクト（ＭＯ）の識別子（ＩＤ）（ＭＯＩＤ）を伝達するＩｔｅｍ／Ｄａｔａ要素と、機器管理ツリーの中のサブツリーのルートノードＵＲＩを伝達するＩｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩ要素と、前記サブツリーの中の前記ＭＯの出現する前記ルートノードＵＲＩを検索して返送するよう端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを送信するよう適合された送信モジュールと、
    前記端末によって返送された前記Ｇｅｔコマンドのステータス情報と前記サブツリーの中の前記ＭＯの出現する前記ルートノードＵＲＩとを受信するよう適合された受信モジュールと、
    を備える、機器管理（ＤＭ）装置。
18. 管理セッションにおいて前記端末の前記ＤＭツリーの中で前記端末によりサポートされたＤＭ ＭＯのタイプを記録する追加された管理ノードに記憶された値を獲得するよう適合された第２の獲得モジュールをさらに備える請求項１７に記載の装置。
19. 請求項１０〜１６のいずれか１項に記載の端末と、
    請求項１７または１８に記載の装置と、
    を備える機器管理のシステム。

Images