機器管理の方法、端末、装置およびシステム
機器管理のための方法、端末、装置、システム、及びブートストラップ方法が提供され、これは、機器管理のための端末、機器管理のための装置、ブートストラップの方法及びシステム、機器記述フレームワークを獲得する方法、端末を管理する方法およびシステム、管理ノード属性を獲得する方法およびシステム、管理オブジェクトアドレスを調べる方法およびシステム、命令の動作モードを管理する方法、管理セッションを維持する方法、及び、端末作動管理オブジェクトを取得する方法を含み、ブートストラップ方法は、端末がサーバのブートストラップ情報を受信し、ブートストラップ情報がサーバのサーバ識別情報を含み、端末がブートストラップ情報を使用してブートストラップまたは再ブートストラップを実行することを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、ネットワーク通信の技術分野での機器管理の方法、端末、装置、およびシステムに関する。
【背景技術】
【０００２】
モバイル端末はモバイル・オペレーション・サービス・システムにおける重要なコンポーネントである。機器管理（ＤＭ、Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）とは、データパケットがオーバ・ザ・エア（ＯＴＡ、Ｏｖｅｒ Ｔｈｅ Ａｉｒ）モードでネットワーク側から端末機器へダウンロードされ、端末機器が、パラメータ・コンフィギュレーション、ソフトウェア設置、およびエラー診断のようなその後の機能を達成するため、処理を実行するよう命令されることを意味する。
【０００３】
オープン・モバイル・アライアンスＤＭ（ＯＭＡ ＤＭ）により設計されたＤＭ仕様では、端末機器の管理のためのプロトコルサポートは既に達成されている。図１は、端末機器を管理するＤＭサーバの全体的構造の概略図である。端末機器上のＤＭクライアントはＤＭサーバによって配信された管理コマンドを説明し実行するよう適合している。端末機器上のＤＭ管理ツリーは、ＤＭサーバがＤＭプロトコルを通じて端末機器を管理するインターフェイスとしてみなされることがある。管理オブジェクト（ＭＯ、Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）のグループは管理ツリーの中に存在する。ＤＭサーバは、ＭＯの中のノード（管理ノード）の動作を通じて端末リソースを管理する目的を達成する。
【０００４】
図１に示されているように、従来技術では、ＤＭ管理は２つのステップ、すなわち、ブートストラップおよびその後の管理を通じて実行される。ブートストラップは、サーバと端末機器との間の管理セッションが実際の管理のため確立される前に起こり、（ユーザ名およびパスワードのような）アカウント情報と（接続パラメータのような）他のパラメータとを構成するよう適合する。その後の管理プロセスにおいて、管理セッションが確立される。サーバは、端末機器のＭＯを通じて、端末の（ファームウェアバージョン、ソフトウェアバージョン、および大規模オブジェクトサポートのような）基本情報を獲得し、その後の管理アクションの基礎としてこの基本情報を使用することができる。
【０００５】
従来技術では、端末機器の管理のためのプロトコルサポートは既に達成されているが、管理有効性、効率、および通信トラフィックのような問題が依然として存在する。たとえば、サーバは、端末ＤＭオブジェクトのアドレスおよび（ソフトウェアコンポーネント管理のサポートおよびファームウェアアップグレードのサポートの能力のような）端末によってサポートされるＤＭ能力を迅速に取得しない可能性があり、端末は再ブートストラップのためＳｍａｒｔＣａｒｄを使用する。具体的には以下の通りである。
【０００６】
１． 端末がローカルに再ブートストラップされた後（たとえば、機器が交換された後）、サーバは端末がブートストラップされたことが認知しないので、サーバに記憶されている認証関連情報は端末がブートストラップされた後の認証関連情報と矛盾する場合があり、結果として、同一性認証が両当事者のためには達成されない可能性があり、通常の管理は失敗することになる。
【０００７】
２． サーバが端末機器による管理ツリーの制限または端末による管理ツリーの実施の制限に関する状況を取得することを可能にするため、従来技術では、端末製造業者は、その端末製造業者の機器を記述し、機器記述フレームワーク（ＤＤＦ、Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）を介してＤＭ当事者による照会のための記述を公表する。しかし、既存プロトコルでは、サーバ側は端末機器を通じてその対応するＤＤＦを見つけることができないため、サーバがＤＤＦを獲得することはより困難である。
【０００８】
３． サーバは、端末によってサポートされる管理オブジェクト（ＭＯ）タイプを取得しない可能性があり、ネットワークリソースをさらに浪費する。ＤＤＦは、通常は、静的であるか、または、殆ど動的に変更されないので、サーバが端末によってサポートされるすべてのＭＯタイプをＤＤＦに従って取得することは難しい。サーバは、対応する管理コマンドが配信され、配信されたコマンドが大量のデータ（たとえば、ソフトウェアコンポーネント管理）を伝達した後に限り、端末によって返送される結果を通じて端末がある一定のＤＭ能力をサポートするかどうかを判定するので、サーバおよびネットワークリソースは浪費される。
【０００９】
４． 従来技術では、サーバは、非直列化モードにおいて一括して機器管理ツリー上のある一定の管理サブツリーの中のすべての管理ノードの具体的な特性値を獲得しない可能性があり、したがって、特性は数回に亘って獲得される必要があり、結果として、効率が低くなる。
【００１０】
５． サーバが端末の管理ノードを検索することは非常に困難であり、エアリソースが消費される。端末管理ノードを獲得するため、サーバは、数回に亘って端末と相互に作用するか、または、端末のディレクトリ構造全体を獲得する必要がある場合があるので、エアリソースは占有され、サーバ上の負荷が増大する。
【００１１】
６． 従来技術では、サーバは、端末に単一の管理コマンドで複数の要素を順次実行するよう命令しない可能性があるので、順次実行を必要とするアクションは、実施のため順次実行される複数の管理コマンドに分割される必要があり、したがって、端末によるメッセージ管理および解析と実行とのコストが増大する。
【００１２】
７． 端末またはサーバがアクションを処理するために長時間を要するとき、セッションは中断される場合があり、管理アクションが完了できない。このようにして、長時間を要する管理は困難になる。その上、当事者が管理コマンドは間もなく送信される必要があることを確認するとき、現在のセッションは維持されない可能性があり、現在のセッションは中断される場合がある。管理セッションは、管理コマンドがその後に送信される必要があるときに再確立されるべきであり、大きなコストを引き起こす。
【００１３】
８． 端末が複数のＭＯインスタンスを有するとき、サーバは現在アクティブ化されているインスタンスを認知しないため、結果として、サーバ管理の難易度が高くなる。
【発明の概要】
【発明が解決しようとする課題】
【００１４】
実施形態では、本開示は、ユーザがブートストラップを実行した後に通常の管理が実行されない可能性があるという従来技術における第１の技術的課題を解決する。
【００１５】
実施形態では、本開示は、プロトコルサーバが対応する機器記述フレームワーク（ＤＤＦ）を獲得することが難しいという従来技術における第２の技術的課題を解決する。
【００１６】
実施形態では、本開示は、サーバが非直列化モードにおいて一括して機器管理ツリー上のある一定の管理サブツリーの中のすべての管理ノードの具体的な特性値を獲得しないことがあるという従来技術における第３の技術的課題を解決する。
【００１７】
実施形態では、本開示は、サーバが端末の管理ノードを検索することが難しく、エアリソースが浪費され、サーバの負荷が高いという従来技術における第４の技術的課題を解決する。
【００１８】
実施形態では、本開示は、既存のサーバが端末に、単一の管理コマンドの中の複数の要素を順次実行するよう命令しない可能性があるという従来技術における第５の技術的課題を解決する。
【００１９】
実施形態では、本開示は、セッションを維持する方法が利用できないとき、予期しない中断がセッションの中で起こる可能性があるという従来技術における第６の技術的課題を解決する。
【００２０】
実施形態では、本開示は、端末が複数の管理オブジェクト（ＭＯ）インスタンスを有し、サーバが現在アクティブ化されているインスタンスを認知しないので、サーバを管理する難易度が高くなるという従来技術における第７の技術的課題を解決する。
【課題を解決するための手段】
【００２１】
本開示の実施形態における第１の技術的課題を解決するため、本開示の実施形態は、以下のステップを含むブートストラップ方法を提供する。
端末はサーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を含むサーバのブートストラップ情報を受信する。
端末はブートストラップまたは再ブートストラップのためブートストラップ情報を使用する。
【００２２】
本開示の実施形態における第１の技術的課題を解決するため、本開示の実施形態は、第１の受信モジュールおよび構成モジュールを含む機器管理（ＤＭ）端末をさらに提供する。
第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。
構成モジュールはブートストラップまたは再ブートストラップのためブートストラップ情報を使用するよう適合される。
【００２３】
本開示の実施形態における第１の技術的課題を解決するため、本開示の実施形態は、第１の受信モジュールおよび認証モジュールを含むＤＭ装置をさらに提供する。
第１の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを受信するよう適合される。
認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。
【００２４】
本開示の実施形態における第１の技術的課題を解決するため、本開示の実施形態は、端末およびサーバを含むブートストラップシステムをさらに提供する。
端末は、第１の受信モジュール、構成モジュール、および警告モジュールを含む。
第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。
構成モジュールはブートストラップまたは再ブートストラップのためブートストラップ情報を使用するよう適合される。
警告モジュールは、端末のブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを送信するよう適合される。
サーバは第１の受信モジュールおよび認証モジュールを含む。
第１の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを受信するよう適合される。
認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。
【００２５】
本開示の実施形態における第２の技術的課題を解決するため、本開示の実施形態は、以下のステップを含むＤＤＦを獲得する方法を提供する。
管理ノードが端末のＤＭツリーに追加され、端末のＤＤＦの記憶アドレスが管理ノードに記憶される。
管理プロセスでは、サーバはＤＤＦの記憶アドレスを獲得するために端末から管理ノードの値を獲得する。
サーバはＤＤＦの記憶アドレスに従って端末のＤＤＦを獲得する。
【００２６】
本開示の実施形態における第３の技術的課題を解決するため、本開示の実施形態は、以下のステップを含む管理ノード特性を獲得する方法を提供する。
サーバは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報および獲得されるべき値フィルタリング情報を伝達するＧｅｔコマンドを端末へ送信し、値フィルタリング情報は、ルートとしてターゲット・オペレーション・ノードを含むサブツリーの構造情報を返送する命令と、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令とを含む。
端末がサーバからＧｅｔコマンドを受信した後、サブツリーの構造情報およびサブツリーの中の各ノードの特性値は、ターゲット・オペレーション・ノードのパス情報および値フィルタリング情報に従って獲得され、特性値および構造情報がサーバへ返送される。
【００２７】
本開示の実施形態における第４の技術的課題を解決するため、本開示の実施形態は、以下のステップを含むＭＯアドレスを検索する方法を提供する。
サーバは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索を命令するパラメータとを伝達するＧｅｔコマンドを端末へ送信し、パラメータは端末に検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう命令する。
端末がＧｅｔコマンドを受信した後、ＭＯは検索されるべきサブツリーの中で検索され、見つけられたＭＯのルート・ノード・パスがサーバへ返送される。
【００２８】
本開示の実施形態における第４の技術的課題を解決するため、本開示の実施形態は、第４の受信モジュールおよび検索モジュールを含むＤＭ端末をさらに提供する。
第４の受信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索を命令するパラメータとを伝達するＧｅｔコマンドを受信するよう適合され、パラメータは端末に検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう命令する。
検索モジュールは、サーバが検索されるべきサブツリーの中にアクセス制御リスト（ＡＣＬ）を有するＭＯを検索し、Ｇｅｔコマンドのステータス情報を返送した後、見つけられたＭＯのルート・ノード・パスをサーバへ返送するよう適合される。
【００２９】
本開示の実施形態における第４の技術的課題を解決するため、本開示の実施形態は、第３の送信モジュールおよび第５の受信モジュールを含むＤＭ装置をさらに提供する。
第３の送信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索を命令するパラメータとを伝達するＧｅｔコマンドを送信するよう適合され、パラメータが端末に検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう命令する。
第５の受信モジュールは、端末から返送されたＧｅｔコマンドのステータス情報と検索されるべきサブツリーの中のＭＯのルート・ノード・パスとを受信するよう適合する。
【００３０】
本開示の実施形態における第４の技術的課題を解決するため、本開示の実施形態は、端末およびサーバを含むＭＯアドレスを検索するシステムをさらに提供する。
端末は第４の受信モジュールおよび検索モジュールを含む。
第４の受信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索を命令するパラメータとを伝達するＧｅｔコマンドを受信するよう適合され、パラメータが端末に検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう命令する。
検索モジュールは、サーバが検索されるべきサブツリーの中にＡＣＬを有するＭＯを検索し、Ｇｅｔコマンドのステータス情報を返送した後、見つけられたＭＯのルート・ノード・パスをサーバへ返送するよう適合される。
サーバは第３の送信モジュールおよび第５の受信モジュールを含む。
第３の送信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索を命令するパラメータとを伝達するＧｅｔコマンドを送信するよう適合され、パラメータが端末に検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう命令する。
第５の受信モジュールは、端末から返送されたＧｅｔコマンドのステータス情報と検索されるべきサブツリーの中のＭＯのルート・ノード・パスとを受信するよう適合される。
【００３１】
本開示の実施形態における第５の技術的課題を解決するため、本開示の実施形態は、以下のステップを含むコマンドの実行モードを管理する方法を提供する。
サーバは、管理コマンドの中の複数のサブアイテムを順次実行する命令を伝達する管理コマンドを送信する。
管理コマンドを受信した後、端末は、順次実行の命令を解析し、管理コマンドの中の各サブアイテムに対応する管理ノードの順序に管理コマンドを実行する。
【００３２】
本開示の実施形態における第６の技術的課題を解決するため、本開示の実施形態は、以下のステップを含む管理セッションを維持する方法を提供する。
ＤＭセッションがサーバと端末との間に確立され、ＤＭコマンドがＤＭセッションの中で送信される。
サーバまたは端末は受信された管理コマンドを処理し、管理コマンドを処理する所要時間がセッション中断またはタイムアウトを引き起こすと判定されたとき、セッション維持コマンドを伝達するＤＭメッセージを反対端へ送信する。
メッセージを受信した後、反対端は、肯定応答メッセージを返送し、セッション維持コマンドの送信元によって送信された新しい管理メッセージが受信されるまでセッションを維持し、管理メッセージが管理コマンドもしくはセッション維持コマンドを伝達するか、または、管理コマンドを伝達しない空メッセージである。
【００３３】
本開示の実施形態における第７の技術的課題を解決するため、本開示の実施形態は、以下のステップを含む端末アクティブ化ＭＯを取得する方法を提供する。
端末は端末リソースをＭＯインスタンスに割り当てるか、または、端末はＭＯインスタンスを使用するためアクティブ化する。
端末はＭＯインスタンスをローカルに記録し、サーバが管理セッションのプロセスの中で端末アクティブ化ＭＯを獲得するためにＧｅｔコマンドを端末へ送信し、端末がローカルに記録されたアクティブ化ＭＯに関する情報をサーバへ返送する。
【図面の簡単な説明】
【００３４】
本開示の技術的な解決手段は、添付図面を参照してさらに詳細に記載される。
【図１】従来技術において端末を管理するＤＭサーバの全体的構造の概略図である。
【図２】本開示の実施形態によるブートストラップ方法のフローチャートである。
【図３】本開示の実施形態によるブートストラップ方法においてブートストラップタイプ管理ノードをＤＭＡｃｃ ＭＯに追加する概略図である。
【図４】本開示の実施形態によるＤＤＦを獲得する方法のフローチャートである。
【図５】本開示によるＤＤＦを獲得する方法の解析プロセスの概略図である。
【図６】本開示の実施形態による端末管理方法において機器管理ツリーの中にサポートノードを追加する概略図である。
【図７】本開示の実施形態によるＭＯアドレスを検索する方法の概略図である。
【図８】本開示の実施形態によるコマンドの実行モードを管理する方法のフローチャートである。
【図９】本開示の実施形態による管理セッションを維持する方法のフローチャートである。
【図１０】本開示の実施形態による管理セッションを維持する方法の解析プロセスのフローチャートである。
【図１１】本開示の実施形態による端末アクティブ化ＭＯを取得する方法のフローチャートである。
【図１２】本開示の実施形態による機器管理ツリーの中のアクティブ化ＭＯに関する情報を記憶する概略図である。
【発明を実施するための形態】
【００３５】
機器管理（ＤＭ）は、主として２つの段階、すなわち、ブートストラップの段階とその後の管理の段階とにおいて実行される。ブートストラップは、管理セッションがサーバと端末機器との間で確立される前に生じ、主として、端末で、サーバの（サーバのアドレス、ユーザ名、およびパスワード）のようなアカウント情報を構成し、（ネットワーク・アクセス・ポイントの情報のような）他のパラメータを構成する。ブートストラップ段階で構成された情報は、その後の管理セッションの確立のための基礎となる。サーバのアカウント情報の構成が完了した後、サーバは端末を管理することができる。管理アクションは、サーバと端末機器との間に確立された管理セッションを通じて達成される。
【００３６】
本開示における改良点は、ブートストラップおよびその後の管理セッションを含む２つの部分を用いて以下で詳細に明らかにされている。
【００３７】
Ｉ． ブートストラップ
【００３８】
ブートストラップの主な目的は、端末とサーバとの間に通常の管理セッションを確立することを可能にするためサーバのアカウント情報を構成することである。同時に、接続設定のような他の関連パラメータがさらに構成されることがある。この具体的な構成方法は以下の通りである。構成されるべきサーバのアカウント情報および他の関連パラメータは、クライアントプロビジョニング（ＣＰ）ファイルフォーマットまたは管理オブジェクト（ＭＯ）直列化フォーマットの中にカプセル化され、カプセル化されたブートストラップ情報がプレインストレーション配信、ＯＴＡプッシュ、または、ＳｍａｒｔＣａｒｄのようなモードで端末へ配信される。端末はサーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を格納するサーバのカプセル化されたブートストラップ情報を受信し、端末はブートストラップまたは再ブートストラップのためブートストラップ情報を使用する。構成の主な仕事は、ブートストラップ情報の中のサーバのアカウント情報を、端末ＤＭツリーの中のサーバアカウントＭＯ（以下、ＤＭＡｃｃと称する）と他の関連ＭＯとに変換することである。その後、ＤＭＡｃｃに対応するサーバに先に接続されていた端末は、サーバ上の管理状態をアクティブ化する。接続が確立されているとき、サーバは、「ＬｏｃＮａｍｅ」（ＬｏｃＮａｍｅの値はＤＭＡｃｃ ＭＯの中で「ＡＡＵＴＨＮＡＭＥ」と呼ばれるノードの値である）を通じて端末のユーザ名を取得し、そして、認証のためのユーザ名に対応するパスワードをさらに使用する。メッセージ・ダイジェスト・アルゴリズム５（ＭＤ５）認証では、ノンスがリプレイ攻撃を阻止するために取得されることがさらに必要である。
【００３９】
特に、ＳｍａｒｔＣａｒｄモードは、初期構成を都合良く実行し、端末のアカウント情報に問題が起こったとき、または、端末（たとえば、携帯電話機）が交換されたとき、再構成を実行することがある安全かつ便利な構成モードである。端末機器が構成済みのアカウントに関する再構成（たとえば、ＳｍａｒｔＣａｒｄモードによる再構成）をローカルで実行するとき、サーバが初期構成後にＯＴＡモードにおいて構成済みのアカウントのパスワードを変更し、ＳｍａｒｔＣａｒｄ上のブートストラップ情報の中のアカウントに対応するパスワードが変更されていないならば、端末のローカル再構成後に、ＤＭＡｃｃ上のパスワードはリセットされることになる（パスワードは変更前に元の値に再変換される）。再構成は、ローカルなアクションであり、サーバはアカウント情報が再構成されたことを知ることができないので、端末に記憶されているパスワードはサーバに記憶されているパスワードと矛盾する。同時に、サーバは端末を認証できず、管理セッションは確立されない可能性がある。
【００４０】
本開示の第１の実施形態では、ブートストラップ構成問題が解決される。２つの主要な方法が以下の通り説明される。
【００４１】
１． 図２に示されているように、サーバのアカウント情報がブートストラップまたは再ブートストラップされた後、端末はセッション要求メッセージをサーバへ送信する。セッション要求メッセージは、端末がブートストラップまたは再ブートストラップされたことをサーバに警告するよう構成される。
【００４２】
サーバがセッション要求メッセージを受信した後、パスワードと、セッション要求メッセージの中で搬送されるＬｏｃＮａｍｅに対応するノンスとが、端末を認証するためサーバによって記憶されたブートストラップ情報から獲得される。認証が成功した後、サーバ側の認証情報が初期化されるか、または、リセットされる。
【００４３】
端末がサーバに、端末がブートストラップまたは再ブートストラップされたことを警告する方法は以下の通りである。
【００４４】
端末がブートストラップまたは再ブートストラップされた後、端末は、最初に、端末がブートストラップまたは再ブートストラップされたことをサーバに知らせるため、セッション要求メッセージをサーバへ送信する。セッション要求メッセージは、端末機器情報、ＬｏｃＮａｍｅ、端末認証情報、および、ブートストラップまたは再ブートストラップ警告情報を含むことができる。ブートストラップまたは再ブートストラップ警告情報の具体的な実施方法は以下の通りである。
【００４５】
端末は、警告情報を実施するために「Ａｌｅｒｔ」コマンドの特定のタイプコードの「Ａｌｅｒｔ」コマンドを使用する。ＡｌｅｒｔコマンドおよびＡｌｅｒｔコマンドのタイプコードは、特に、端末情報レポートＡｌｅｒｔコマンド（すなわち、コマンド・タイプコードが１２２６である一般的な警告（Ｇｅｎｒｉｃ Ａｌｅｒｔ））と、端末事象レポート警告コマンド（すなわち、コマンド・タイプコードが１２２４であるクライアント事象警告（Ｃｌｉｅｎｔ Ｅｖｅｎｔ Ａｌｅｒｔ））、または、具体的には以下の通りの警告情報を報告するための新しいセッションタイプであってもよい。
【００４６】
事象タイプ（Ｅｖｅｎｔ ｔｙｐｅ）は、たとえば、一般的な警告、または、クライアント事象警告、たとえば、ｏｒｇ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｄｍ．ｂｏｏｔｓｔｒａｐを採用するために最初に定義される必要がある。以下、一般的な警告は一実施例として採用されている。クライアント事象報告を使用する方法は以下に類似する。
【００４７】
【数１】
【００４８】
警告情報を報告する新しいセッションタイプを追加する方法は以下の通りである。新しいＡｌｅｒｔコマンドのタイプコードが追加される。タイプコードを伝達するＡｌｅｒｔコマンドは新しいセッションタイプを指示するよう構成される。タイプコードは１２０２であってもよい。実施例は以下の通りである。
【００４９】
【数２】
【００５０】
端末によって開始されたサーバへのセッション要求メッセージは、ブートストラップ警告情報を伝達する。サーバが要求メッセージを受信した後、サーバは、セッション要求メッセージの中で伝達された警告情報を解析することにより、端末がブートストラップまたは再ブートストラップされたことを認知し、次に、端末要求を認証するためサーバ側で記憶されたブートストラップ情報の中のパスワードを獲得する。その後の管理において、サーバは端末によって記憶されたパスワードを更新することができる。
【００５１】
安全性のため（たとえば、悪質なサーバがセッション要求メッセージを傍受し、リプレイ攻撃を始める問題を防止するため）、端末によって送信されたセッション要求メッセージを認証した後、サーバは端末への認証チャレンジをさらに開始することができる。チャレンジは、サーバによって生成された新しいノンスを伝達する。サーバによって送信されたチャレンジメッセージを受信した後、端末は新しいノンスを使用して新しい認証情報を生成し、認証情報をサーバへ送信する。サーバは端末を再び認証する。認証が成功した後、サーバは他の管理オペレーションを実行することができ、たとえば、サーバパスワードを更新することができる。
【００５２】
再ブートストラップは、ある一定の条件（たとえば、携帯電話機カードが新しい携帯電話機に挿入される）において端末機器によって自動的にトリガされ、または、端末ユーザインターフェイス（ＵＩ）を介してユーザによってトリガされることが可能である。
【００５３】
２． ＳｍａｒｔＣａｒｄ上のブートストラップ情報が端末によって更新可能である場合、ブートストラップ方法は以下の通りである。端末は、端末のＤＭツリーのＤＭＡｃｃ ＭＯに記憶されたユーザ名、パスワードまたはノンスを更新するため、サーバのＤＭコマンドを受信する。更新が成功した後、端末は、ＳｍａｒｔＣａｒｄオペレーションコマンドを通じて自動的にＳｍａｒｔＣａｒｄにおけるブートストラップファイルの中の対応するユーザ名、パスワードまたはノンス情報を更新する。上記処理後の２つの状況は以下の通りである。
【００５４】
１） ブートストラップファイルの更新が、ブートストラップファイルの中で伝達されるユーザ名、パスワード、およびノンスが、サーバによって記憶されたユーザ名、パスワード、およびノンスと整合していることを保証できる場合、その後のブートストラップは更新済みのブートストラップファイルを用いて実行され、そして、ブートストラップ後に、サーバに通知する必要がない（すなわち、ブートストラップ事象をサーバへ報告する専用セッションが必要とされない）。
【００５５】
２） ブートストラップファイルの更新が、ブートストラップファイルの中で伝達されるユーザ名、パスワード、およびノンスが、サーバによって記憶されたユーザ名、パスワード、およびノンスと整合していることを保証できない場合、ユーザ名、パスワード、またはノンスのようなアカウントデータの更新を効率的に制御し、サーバと端末との間の同期を容易に行うために、ブートストラップファイルが更新された後に、更新情報が更新済みのブートストラップファイルの中に記録される。更新情報はバージョンフィールドを追加することにより記録されることができる。さらに、セッションがブートストラップの後にブートストラップファイルを使用することにより初めて確立されるとき、記録された更新情報がセッション要求メッセージの中で報告される。サーバは更新に従って処理を実行する。
【００５６】
ブートストラップは複数のモードを含む。しかし、これまでのところ、ブートストラップによって生成された機器管理ツリーのＤＭＡｃｃ ＭＯの中の情報は、アカウントが生成されたブートストラップモードに関する記録を含まない。したがって、サーバは、ブートストラップモードを通じてブートストラップの安全性レベルを判断することができず、すべての端末について採用されたブートストラップ方法の統計を取ることができない。本開示の第２の実施形態では、上記課題を解決する方法が以下の通り記載される。サーバが端末のブートストラップのソースを取得することができるよう、本実施形態では、端末がブートストラップされるモード、すなわち、ブートストラップタイプを記憶するため、管理ノード（たとえば、図３における「ブートストラップタイプ」）が端末ＤＭツリーのＤＭＡｃｃ ＭＯに追加される。具体的な実施形態は図３に示されている通りである。ブートストラップタイプの値は、表１に示されているように整数でもよい。
【００５７】
【表１】
【００５８】
端末のブートストラップが成功した後、ブートストラップモードは管理ノードの中に記憶される。サーバは端末の中のアカウントに対応するブートストラップモードを獲得するために管理セッションを介してＧｅｔコマンドを管理モードへ配信する。サーバの権限を認証した後、端末は管理ノード値を返送する。
【００５９】
第３の実施形態では、本開示は、端末が複数のＤＭＡｃｃを生成するため数回に亘って同じＳｅｒｖｅｒＩＤアカウントでブートストラップを実行する状況を回避するように、ブートストラップ情報を処理する方法について記載する。具体的なブートストラップ方法は以下のステップを含む。
【００６０】
１． 端末の管理ツリーは、以下の通り、ＳｅｒｖｅｒＩＤに対応するＤＭＡｃｃ ＭＯが既に存在するかどうかを判定するため検索される。現在構成されるべきサーバアカウントに対応するＳｅｒｖｅｒＩＤが装置管理ツリーの中のＤＭＡｃｃ ＭＯのＳｅｒｖｅｒＩＤノードの値と同じであるかどうかが比較され、一方、現在構成されるべきサーバアカウントに対応するＳｅｒｖｅｒＩＤが装置管理ツリーの中のＤＭＡｃｃ ＭＯのＳｅｒｖｅｒＩＤノードの値と同じである場合、対応するアカウント情報が存在し、現在構成されるべきサーバアカウントに対応するＳｅｒｖｅｒＩＤが装置管理ツリーの中のＤＭＡｃｃ ＭＯのＳｅｒｖｅｒＩＤノードの値と同じでない場合、対応するアカウント情報が存在しない。ＳｅｒｖｅｒＩＤに対応するＤＭＡｃｃ ＭＯが端末の管理ツリーの中に見つけられる場合、ステップ２が実行され、ＳｅｒｖｅｒＩＤに対応するＤＭＡｃｃ ＭＯが端末の管理ツリーの中で見つからない場合、ステップ３が実行される。
【００６１】
２． ブートストラップオペレーションが反復ブートストラップまたは再ブートストラップであるかどうかが判定される（たとえば、ユーザの確認情報を通じて複数のモードで判定されることがある）。ブートストラップオペレーションが反復ブートストラップである場合、ブートストラップオペレーションはキャンセルされる。ブートストラップオペレーションが再ブートストラップである場合、機器管理ツリー上の対応するＤＭＡｃｃ ＭＯの中の管理ノード上のデータが直接的にリフレッシュされる。
【００６２】
３． ブートストラップ情報の中のカウント情報が端末ＤＭツリーの中のＤＭＡｃｃ ＭＯに変換され、アクセス制御リスト（ＡＣＬ）がＤＭＡｃｃ ＭＯについて分配される。
【００６３】
前述の第１の実施形態では、ユーザが再ブートストラップされた（たとえば、機器が交換された）後に端末がブートストラップされたかどうかをサーバが認知できず、それゆえ、先行するユーザの端末情報の影響の下で通常の管理が失敗する可能性があるという課題を効果的に解決するブートストラップ方法が図示されている。第２の実施形態では、サーバが端末のブートストラップモードを取得していない可能性があり、そして、ブートストラップモードに従ってブートストラップの安全性レベルを判断できないことがあるという課題が解決される。第３の実施形態では、同じＳｅｒｖｅｒＩＤが数回に亘ってブートストラップされたとき、同じＳｅｒｖｅｒＩＤに対応する複数のＤＭＡｃｃ ＭＯがブートストラップ競合に起因して端末ＤＭツリーの中に存在する状況を回避し、反復ブートストラップによって引き起こされるアカウント管理の混乱を回避するように、処理方法が提供される。
【００６４】
本開示におけるその後の管理セッションの改良点は以下の通り詳細に明らかにされる。
【００６５】
ＩＩ． 管理セッション
【００６６】
ブートストラップが端末上で成功した後、管理セッションがサーバと端末との間に確立されることが可能であり、管理メッセージがセッションの中で交換されることが可能である。このセッションは、セッション確立段階と管理段階とを含む。セッション確立段階では、同一性が相互に認証され、同時に、端末が、ＤｅｖＩｎｆｏ ＭＯに記憶された端末基本情報を報告する。管理段階では、サーバが、管理アクションを端末へ配信するように、端末の管理ツリー上のＭＯへ保守オペレーションを配送する。機器管理ツリーの管理ノードは、管理ノードのためのサーバのオペレーション権限を制御するためにＡＣＬを有する。
【００６７】
１． サーバが端末機器による管理ツリーへの制限または端末による管理ツリーの実施状況を知ることができるよう、機器記述フレームワーク（ＤＤＦ）が、機器を記述するために採用される。サーバが機器を理解し管理を実行することが必要であるとき、まず、ＤＤＦに従って端末を管理するように機器のＤＤＦが獲得される。しかし、既存のプロトコルでは、サーバ側は端末機器を介して対応するＤＤＦを見つけられない可能性があり、サーバがＤＤＦを獲得することがより困難である。
【００６８】
本開示の実施形態においてＤＤＦを獲得する方法は図４に示される通りであり、以下のステップを含む。
【００６９】
ＤＤＦのユニフォーム・リソース・ロケータ（ＵＲＬ）は端末の管理ツリーに記憶される。
【００７０】
サーバはＵＲＬを通じて端末のＤＤＦを獲得する。
【００７１】
サーバ側によるＤＤＦの獲得を容易に実現するため、ＤＤＦのＵＲＬは、サーバがＵＲＬを通じて端末のＤＤＦを獲得するように、または、ＤＤＦデータが端末の管理ツリーにさらに記憶されるように、端末の管理ツリーに記憶されることがある。このようにして、サーバは、図４の実施形態に限定されることなく、端末から直接的にＤＤＦ情報を獲得することがある。具体的な実例は次の通りである。
【００７２】
端末がＤＤＦのＵＲＬを記憶する実施方法は以下の通りである。管理ノードは端末のＤＭツリーの中に追加され、端末のＤＤＦのＵＲＬは追加された管理ノードの中に記憶される（複数のＤＤＦが存在する可能があり、複数のノードがＵＲＬを記憶するため使用されない可能性がある）。好ましくは、上記記憶アクションは機器の配信の前に達成され、機器の使用中に記憶アクションは実際の状況に従って更新されることがある（たとえば、機器製造業者がＤＤＦの記憶アドレスを更新する）。追加された管理ノードは、既存のＤｅｖＩｎｆｏ ＭＯまたは機器詳細情報（ＤｅｖＤｅｔａｉｌ）ＭＯの中に記憶されてもよく、または、ＭＯとして別々に存在してもよい。ノード特性は表２に示されている通りである。
【００７３】
【表２】
【００７４】
端末がＤＤＦのＵＲＬを記憶し、そして、管理サーバがＤＤＦを獲得し使用する２つの方法は以下の通りである。
【００７５】
第１の方法では、端末は、最初に、ＤＤＦ管理ノードの値または管理ノードの位置を報告する。具体的な方法は以下の通りである。端末は以下の機会に報告する。
【００７６】
第１の機会では、ある一定のサーバアカウントが端末のため構成された後（たとえば、ブートストラップ後）、端末はサーバへの登録セッション（端末とサーバとの間の第１のセッション）を開始する。このセッションでは、ＤＤＦ管理ノードの値またはＤＤＦ管理ノードの位置が報告される。その後の管理セッションでは、ＤＤＦ管理ノードの値およびＤＤＦ管理ノードの位置は、サーバがそれらを再獲得するためにＧｅｔコマンドを配信しない限り、最初に報告されない（方法２を参照のこと）。好ましくは、管理セッションのセッション要求メッセージは、ＤＤＦ管理ノードの値またはＤＤＦ管理ノードの位置を伝達する。
【００７７】
第２の機会では、端末は、各管理セッションのセッション要求メッセージの中でＤｅｖＩｎｆｏと一緒にＤＤＦ管理ノードの値またはＤＤＦ管理ノードの位置を報告する。
【００７８】
ＤＤＦ管理ノードを記憶する位置が報告される場合、いずれかのその後の管理セッションにおいて、サーバは、ＤＤＦ管理ノードを記憶する位置に従ってＤＤＦ管理ノードの値を獲得する（ＤＤＦ管理ノードの値はＤＤＦのＵＲＬ情報である）。
【００７９】
サーバがＤＤＦのＵＲＬ情報を受信した後、ＤＤＦが必要とされるとき（たとえば、端末の詳細な管理または構成が実施される前）、具体的なＤＤＦ情報がＵＲＬに従って獲得され、端末はＤＤＦに従って生成された管理コマンドに従って管理される。
【００８０】
第２の方法では、サーバはサーバと端末との間で確立された管理セッションにおいて最初にＤＤＦ情報を獲得する。具体的なプロセスは図５に示されている通りであり、具体的なステップは以下の通り明らかにされる。
【００８１】
ステップ１では、ＤＭサーバは、管理プロセスにおいて端末からＤＤＦ管理ノードに記憶されたＵＲＬを獲得する。具体的な方法は以下の通りである。
【００８２】
端末はサーバの命令情報を受信する。命令情報は、サーバによって送信された通知メッセージ（セッション・トリガ・メッセージ）の中で伝達される。命令情報は、端末に、ＤＤＦ管理ノードに記憶された端末ＤＭツリーのＤＤＦのＵＲＬまたは端末によってサポートされたある一定のＭＯのＤＤＦのＵＲＬを報告するよう命令する。その後に、端末は通知の中の情報に従って管理セッションを開始するセッション要求メッセージを生成する。ＵＲＬはセッション要求メッセージの中で報告される。具体的なレポート方法は以下の通りである。警告タイプは端末のために拡張される。ＡｌｅｒｔコマンドはタイプおよびＵＲＬを伝達する。タイプがＭＯのＤＤＦである場合、ＭＯＩＤがさらに伝達されることがある。サーバは警告タイプおよびＭＯＩＤに従ってＵＲＬを特定する。
【００８３】
代替的に、ノードはＤｅｖＤｅｔａｉｌ ＭＯまたは他のＭＯに記憶される。サーバは、確立された管理セッションの中でＧｅｔコマンドを通じてノードの値を獲得する。ＤｅｖＤｅｔａｉｌ ＭＯを一実施例として採用すると、サーバが、ノードと、端末ＤＭツリーの中でノードを記憶するＤｅｖＤｅｔａｉｌ ＭＯのパスとを知らない場合、ノードは以下の方法を通じて検索される。
【００８４】
サーバは端末ＤＭツリーの構造情報を獲得し、構造情報を直接的に分析することにより端末ＤＭツリーの中の管理ノードの位置を検索する。
【００８５】
代替的に、サーバは、以下の通り具体的に、最初に管理ノードのＭＯ（ここでは、ＤｅｖＤｅｔａｉｌ）の位置を獲得する。サーバはＧｅｔコマンドを通じてＤｅｖＤｅｔａｉｌ ＭＯの位置を検索するか、または、ＤｅｖＤｅｔａｉｌの位置情報を端末のＤｅｖＩｎｆｏに記憶する。端末は、（最初のＤＭセッションの中で報告されるか、１回報告されるか、または、各セッションで報告されることがある）セッション要求メッセージの中でＤｅｖＩｎｆｏと一緒にＤｅｖＤｅｔａｉｌ ＭＯの位置（ルート・ノード・パス）をサーバへ報告する。サーバは、ＤｅｖＤｅｔａｉｌの位置およびＤｅｖＤｅｔａｉｌ ＭＯの構造情報（機器管理ツリーの中で獲得されたＤｅｖＤｅｔａｉｌ ＭＯルートノードのパスと、ＤｅｖＤｅｔａｉｌ構造の中のＤｅｖＤｅｔａｉｌルートノードと相対的なＤＤＦ管理ノードの相対パスとを接続することにより形成されたＤＤＦ管理ノードのパス）に従ってＤＤＦ管理ノードの位置を検索する。
【００８６】
ＤＤＦ管理ノードの位置が検索された後、ＧｅｔコマンドがＤＤＦ管理ノードの値を獲得するため配信される。
【００８７】
ステップ２では、端末は、記憶しているＤＤＦのアドレスをＤＭサーバへ返送する。具体的な方法は以下の通りである。ノードがＤｅｖＩｎｆｏ ＭＯに記憶されている場合、端末はセッション要求メッセージの中でアドレスを伝達する。ノードがＤｅｖＤｅｔａｉｌ ＭＯの中に記憶されている場合、端末はサーバによって送信された問い合わせコマンドの結果（リザルト）メッセージの中でＤＤＦアドレスを返送する。
【００８８】
ステップ３では、ＤＭサーバは、ＤＤＦを獲得するため、獲得されたＤＤＦ記憶アドレスに対応するリモートＤＤＦ記憶サーバと通信する。
【００８９】
ステップ４では、リモートＤＤＦ記憶サーバはＤＤＦ記述ファイルをＤＭサーバへ返送する。
【００９０】
ステップ５〜７では、ＤＭサーバは、その後の管理のための基準としてＤＤＦを使用することにより管理アクションを生成し、端末を管理し、端末は実行結果を返送する。
【００９１】
ＤＤＦのその後の獲得のコストを削減するため、ＤＭサーバは獲得されたＤＤＦデータをローカルに一時的に記憶することができる。
【００９２】
端末がＤＤＦを記憶する実施方法は以下の通りである。管理ノードは端末のＤＭツリーの中に追加される。管理ノードは端末ＤＭツリーの中のある一定のＭＯに追加され、ＤＤＦの内容はノードの中に記憶される。値は、機器配信前にノードに割り当てられることがある。機器の使用中に、ＤＭクライアントは実際の状況に従って更新を実行する。好ましくは、ノードはＤｅｖＤｅｔａｉｌ ＭＯに追加される。ノード特性は表３に示されている通りである。
【００９３】
【表３】
【００９４】
この方法では、サーバは管理プロセスにおいてＤＤＦの内容であるノードの値を獲得する。具体的に、４つの方法が、ノードの値がＤｅｖＤｅｔａｉｌに記憶される実施例を採用することにより、以下の通り例示されている。
【００９５】
第１の方法では、サーバは、以下の通り具体的に、ＤＤＦを獲得するために直接的にＤＤＦの管理ノードの位置を検索する。サーバは、Ｇｅｔコマンドを配信することにより機器管理ツリーの構造をまず獲得し、機器管理ツリーの構造を通じて直接的に管理ノードを検索する。代替的に、端末は、（最初のＤＭセッションで報告されるか、１回だけ報告されるか、または、各セッションの中で報告される）セッション要求メッセージの中で管理ノードの位置をまず報告する。その後、サーバは管理ノードの値（すなわち、ＤＤＦ）を獲得するためコマンドを配信し、値はその後の管理のための基礎として使用される。
【００９６】
第２の方法では、サーバは機器管理ツリーの中のＤｅｖＤｅｔａｉｌの位置をまず獲得し、以下の通り具体的に、ＤＤＦを獲得するようにＤＤＦ管理ノードの位置を間接的に検索する。サーバは、ＤＤＦ管理ノードのＭＯ（ここではＤｅｖＤｅｔａｉｌ）の位置をまず獲得する。サーバは、Ｇｅｔコマンドを配信することにより機器管理ツリーの中のＤｅｖＤｅｔａｉｌ ＭＯの位置を検索するか、または、ＤｅｖＤｅｔａｉｌの位置情報を端末のＤｅｖＩｎｆｏに記憶する。端末は、セッション要求メッセージの中で、（最初のＤＭセッションの中で報告されるか、１回だけ報告されるか、または、各セッションで報告されることがある）ＤｅｖＤｅｔａｉｌ ＭＯの位置（ルート・ノード・パス）をサーバへまず報告する。その後、サーバは、Ｇｅｔコマンドを配信することによって、値（すなわち、ＤＤＦ）を獲得するように、ＤｅｖＤｅｔａｉｌ ＭＯの位置情報および構造を通じてＤＤＦ管理ノードの位置を検索する。ＤＤＦはその後の管理のための基礎として使用される。
【００９７】
第３の方法では、ある一定のサーバアカウントが端末のため構成された後（たとえば、ブートストラップ後）、端末は最初にサーバへの登録セッション（端末とサーバとの間の最初のセッション）を開始する。ＤＤＦはこのセッションにおいて報告される。その後の管理セッションにおいて、ＤＤＦは、サーバが再獲得のためのＧｅｔコマンドを配信しない限り、最初に報告されない。
【００９８】
第４の方法では、端末はサーバの命令情報を受信する。命令情報はサーバによって送信された通知メッセージの中で伝達される。命令情報は、端末にＤＤＦ管理ノードに記憶された端末ＤＭツリーのＤＤＦまたは端末によってサポートされたある一定のＭＯのＤＤＦを報告するよう命令する。その後、端末は、通知の中の情報に従って管理セッションを開始するセッション要求メッセージを生成する。ＤＤＦはセッション要求メッセージの中で伝達され、具体的な実行方法は以下の通りである。警告タイプは端末のため拡張される。警告タイプおよびＤＤＦはＡｌｅｒｔコマンドの中で伝達される。警告タイプがＭＯのＤＤＦである場合、ＭＯＩＤがさらに伝達されることができる。サーバは警告タイプおよびＭＯＩＤに従ってＤＤＦを特定する。
【００９９】
ＤＤＦを獲得する２つの方法が、サーバに対応するＤＤＦをサーバが見つけられない可能性があるという従来技術の課題を解決することができる。特に、ＤＤＦは比較的安定した情報であり、情報は大量であるので、頻繁なレポートはサーバおよびネットワーク伝送に負荷を引き起こす。これらの方法では、必要に応じて、サーバの情報を検索して獲得する能力を提供するように、端末が最初にある一定の条件下でＤＤＦを報告するか、または、サーバが最初にノードを検索してＤＤＦを獲得し、その結果、ネットワークおよびサーバへの負荷は、ＤＤＦを獲得する能力が提供されたままで、最大限に低減される。
【０１００】
２． 管理セッションはサーバと端末との間に確立可能であり、このことはサーバが端末のＤＭツリーへのオペレーションだけを実行可能であることを意味するに過ぎない。しかし、いくつかの機能は、ＳＣＯＭＯのような、具体的なＭＯ、および、端末上の（ＤＭアプリケーションと呼ばれる）クライアントプログラムに依存する必要がある。種々の端末が種々のＤＭアプリケーションをサポートし、これは、具体的なクライアントがその後の使用プロセスにおいて設置された後で配信または能力がサポートされる前は、異なる実施であってもよい。端末がある一定のＤＭアプリケーションをサポートするかどうかは、ＤＭアプリケーション機能が達成可能であるかどうかの根拠となる。したがって、端末はサーバにサポートされているＤＭアプリケーションを通知することが必要である。サーバ管理の困難さは、端末によってサポートされているＤＭアプリケーション（すなわち、ＭＯタイプ）をサーバが見分けられないために増大するという従来技術の課題を解決するため、本実施形態では、管理ノードが端末によってサポートされているＤＭアプリケーションを記録するために端末の管理ツリーに追加される。各ノードは端末によってサポートされるＤＭアプリケーションを記憶する。
【０１０１】
図６を参照すると、本実施形態では、追加された管理ノードは、内部ノードおよびそのサブノードを含むように設計されることがある。たとえば、「ＳｕｐｐｏｒｔｅｄＡｐｐ」ノードは、ＤｅｖＩｎｆｏまたはＤｅｖＤｅｔａｉｌ ＭＯの中のノードでもよい内部ノードとして設定される。内部ノードのサブノード「ｘ＊」は、リーフノードであり、複数のインスタンスを有してもよい。各インスタンスはＤＭアプリケーションに対応する。端末は、このノードを端末の実際の条件に従って維持する。たとえば、ある一定のＤＭアプリケーションが端末に追加される場合、端末はＳｕｐｐｏｒｔｅｄＡｐｐノードの中にリーフノードを追加し、ＤＭアプリケーションの情報を記憶する。各ＭＯは対応するＭＯＩＤを有するので、たとえば、ファームウェアＭＯのＭＯＩＤは“ｕｒｎ：ｏｍａ：ｍｏ：ｏｍａ−ｆｕｍｏ：１．０”であり、サポート対象ＭＯのＭＯＩＤはノードに記憶され、すなわち、．．．／ＳｕｐｐｏｒｔｅｄＡｐｐ／＜ｘ＞ノードの値はＭＯＩＤである。
【０１０２】
ＤＭアプリケーションに関して、端末がＤＭアプリケーションをサポートする限り、管理ツリーの中に存在するＤＭアプリケーションの個数（０または１または複数）とは無関係に、ＤＭアプリケーションに関して１個のＭＯＩＤだけがサポート対象ノードの下で追加される。管理プロセスでは、端末によってサポートされたＤＭアプリケーションを獲得するステップは以下の通りである。
【０１０３】
ステップＡでは、サーバは、端末によってサポートされたＤＭアプリケーションが獲得されるべきであることを判定する。
【０１０４】
ステップＢでは、サーバはサブノードとサブノードの値とを獲得するためにＧｅｔコマンドを端末のＤＭツリーのＳｕｐｐｏｒｔｅｄＡｐｐノードへ送信し、端末は対応する結果を返送する。
【０１０５】
ステップＣでは、サーバは、端末によってサポートされたＤＭアプリケーションを判定するために取得されたノード値（ＭＯＩＤ）を分析する。
【０１０６】
本実施形態における方法は、サーバが端末によってサポートされたＤＭアプリケーションを認知しないという課題を解決することができ、この方法では、具体的な管理オペレーションは、サーバの管理をより柔軟かつ効率的にするため配信される。
【０１０７】
３． 管理プロセスでは、サーバは、具体的な管理機能を実施するためにＭＯの中のノードに対しオペレーションを実行するように端末のＭＯを検索する必要がある。従来技術では、サーバが端末の管理ノードを検索することは非常に困難であり、エアリソースが消費され、サーバは大きな負荷を受ける。本開示では、サーバが端末のＤＭツリーの中でＭＯを検索する効率を改良するため、ＭＯルートノードの位置を検索する方法が提供される。図７に示されているように、この方法は以下のステップを含む。
【０１０８】
サーバはＧｅｔコマンドを端末へ送信する。Ｇｅｔコマンドは、獲得されるべきターゲット・オペレーション・パスの情報と値フィルタリング情報とを伝達する。
【０１０９】
サーバのＧｅｔコマンドを受信した後、端末は、Ｇｅｔコマンドに対応した、指定されたサブツリーの構造情報およびノードの特性情報を獲得するよう命令される。特性値および構造情報はサーバへ返送される。
【０１１０】
図７は、ＭＯアドレス検索の実施形態だけを示している。具体的に、サーバは、Ｇｅｔコマンドを端末へさらに送信することができ、Ｇｅｔコマンドは、検索されるべきＭＯのＩＤを伝達し、検索されるべきサブツリーのルートノードのユニフォーム・リソース識別子（ＵＲＩ）および検索を命令するパラメータを伝達する。パラメータは端末に機器管理ツリーの中のＭＯのＩＤをＭＯのルートノードのＵＲＩへ返送するよう命令する。
【０１１１】
Ｇｅｔコマンドの受信後、端末は、ＵＲＩ命令ノードとすべての内部サブノードの中でＩＤを満たすノードとを検索し、対応する結果をサーバへ返送する。
【０１１２】
本実施形態では、ＭＯアドレス検索は以下の３つのモードで具体的に実施される。
【０１１３】
第１の方法では、管理ツリー構造が返送されるときに同時に特性値が伝達され、具体的には以下の通りであることができる。
【０１１４】
サーバはＧｅｔコマンドを端末へ送信する。端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報はＧｅｔコマンドの“Ｔａｒｇｅｔ／ＬｏｃＵＲＩ”要素で伝達される。同時に、獲得されるべき値フィルタリング情報が伝達される。値フィルタリング情報は、端末に、機器管理ツリーの中でルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報と、サブツリーの中の各ノードの指定された特性の特性値とを返送するよう命令する。
【０１１５】
伝達されるフィルタ情報のフォーマットは、＜ＵＲＩ＞？ｌｉｓｔ＝Ｓｔｒｕｃｔ＋＜ｐｒｏｐｅｒｔｙ＿ｎａｍｅ＞であってもよい。複合パラメータ中の「Ｓｔｒｕｃｔ」は、端末に、機器管理ツリーの中でＵＲＩによって指示されたノードおよびこのノードのサブノードの構造情報を返送するよう命令する。構造は、端末によって返送されたノードの（“ＬｏｃＵＲＩ”の中で伝達される）ＵＲＩによって表現される。複合パラメータの中の＜ｐｒｏｐｅｒｔｙ＿ｎａｍｅ＞は、ある一定のノードの特性名であり、端末に、ＵＲＩによって指示されたノードおよびこのノードのサブノードの特性の特性値を返送するよう命令する。特性は、ノードタイプ特性、ノードＡＣＬ特性、ノード値フォーマット特性、ノードタイトル特性、ノード値サイズ特性、ノード変更タイムスタンプ（ＴＳｔａｍｐ）特性、または、ノードバージョン番号（ＶｅｒＮｏ）特性のような端末によってサポートされるいかなる特性であってもよい。使用例は以下の通りである。
【０１１６】
【数３】
【０１１７】
サーバのＧｅｔコマンドの受信後、端末は、Ｇｅｔコマンドに従って指定サブツリーの構造情報およびノードの特性情報を獲得するよう命令され（獲得中に、サーバが管理ノードのＡＣＬ権限、ここでは、具体的に取得権限（Ｇｅｔ ｒｉｇｈｔ）を有するかどうかが認証される）、次に、構造情報と共に特性値をサーバへ返送する。
【０１１８】
特性情報は、Ｇｅｔコマンドに対応する「Ｒｅｓｕｌｔ」コマンドの中で伝達される（異なるノードはＲｅｓｕｌｔ要素の中の異なるＩｔｅｍサブ要素の中に分配されるか、または、それぞれが単一のＩｔｅｍを含む異なるＲｅｓｕｌｔ要素に分配されることがある）。具体的な特性値は、Ｒｅｓｕｌｔ／Ｉｔｅｍ／Ｄａｔａ要素の中で伝達され、返送されることができる。「Ｒｅｓｕｌｔ」コマンドの中の“Ｓｏｕｒｃｅ／ＬｏｃＵＲＩ”要素は、ノードＵＲＩと、特性名を指示するパラメータとを伝達する。その複合は、ＵＲＩ？ｐｒｏｐ＝＜ｐｒｏｅｒｔｙ＿ｎａｍｅ＞である。コマンドの受信後、サーバは、ノードＵＲＩに従って機器管理ツリーの指定された部分の構造を分析し、？ｐｒｏｐ＝＜ｐｒｏｅｒｔｙ＿ｎａｍｅ＞部分からＤａｔａの中で伝達される特性値に対応する特性名を取得し、データ要素から特性値を獲得する。用法は以下の通りである。
【０１１９】
【数４】
【０１２０】
機器管理ツリーの中のＭＯのＭＯＩＤはＭＯルートノードのタイプ特性に記憶されるので、複合パラメータの＜ｐｒｏｐｅｒｔｙ＿ｎａｍｅ＞は、タイプ特性に設定され、サブツリー構造が返送されるときと同時に、サブツリーの中のすべてのＭＯＩＤを返送する。具体的に、サーバは、サブツリーの中の各ノードのタイプ特性の値を獲得した後に判定を行う。ノードが内部ノードであり、タイプ特性の値が空でない場合、ノードは、返送された情報からＭＯのルートノードのＵＲＩを獲得するため、ＭＯのルートノードであり且つ空でないタイプ特性の値はＭＯＩＤであると判定される。ＭＯのＵＲＩの獲得後、サーバは、ＭＯの中のノードのより詳細な情報を獲得するためＧｅｔコマンドを送信するか、または、管理コマンドを直接的に送信する。
【０１２１】
この方法は、サーバが、非直列化モードにおいて一括して機器管理ツリーの中のある一定の管理サブツリーの中のすべての管理ノードのうちのある一定の特性値を獲得しない可能性がある、という課題を解決することができる。この方法を通じて、ある一定の特性値は、サブツリー構造が獲得されたときに同時に獲得されることができるので、特性獲得のための相互作用は減少され、効率が増大される。同時に、管理サブツリーの中のすべてのＭＯは、特性値をタイプとして指定することにより獲得されることができるので、管理サブツリーの中のすべてのＭＯが効率的に獲得できない可能性がある、という課題が解決される。
【０１２２】
第２の方法では、端末は、具体的なＭＯのルートノードを検索し、ルートノードのＵＲＩを返送する。具体的な実施形態は以下の事項を含む。
【０１２３】
サーバはＧｅｔコマンドを端末へ送信する。検索されるべきＭＯの識別子（ＭＯＩＤ）はＧｅｔコマンドにおいてＩｔｅｍ／Ｄａｔａ要素の中で伝達される。ＭＯＩＤが検索されるサブツリーのルートノードのＵＲＩと、検索を命令するパラメータとが、Ｉｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩ要素の中で伝達される。パラメータは、端末に、Ｉｔｅｍ／Ｔａｅｇｅｔ／ＬｏｃＵＲＩ要素によって提示された機器管理ツリーのサブツリーのＩｔｅｍ／Ｄａｔａ要素の中で伝達されるＭＯＩＤにより識別されるＭＯの出現するルートノードのＵＲＩを検索するよう命令する。サブツリーのルートノードのＵＲＩと検索を命令するパラメータとを伝達する情報のフォーマットは、ＵＲＩ？ｌｉｓｔ＝ＭＯ＿ＲＯＯＴでもよい。メッセージはＤＭメッセージの中で伝達される。コマンドの具体的な実施例は以下の通りである。
【０１２４】
【数５】
【０１２５】
コマンドの受信後、端末は、サーバがＡＣＬ権限（ここでは、Ｇｅｔ権限）を有し、ノードがコマンドの中のルートノードＵＲＩとそのサブノードとに対応する場合に、ノードにおいてＤａｔａ要素の中で伝達されるＭＯＩＤの値をもつＴｙｐｅ特性を有するすべてのノードを検索し、結果（すなわち、検索されたノードのＵＲＩ）をサーバへ返送する。検索プロセスは、内部ノードだけで実行され（すなわち、フォーマット特性はノードである）、リーフノードのためには実行されない。代替的に、端末は、＜ＭＯルートノード、ＭＯＩ＞記憶マッピング表を記憶する。サーバからのＧｅｔコマンドが受信された後、ＭＯ位置はマッピング表から即座に獲得され、結果がサーバへ返送される。結果を返送する方法は以下のステップを含む。
【０１２６】
１） 検索条件を満たす１個以上のノードが見つけられる場合、Ｇｅｔコマンドのステータスの後、すべての検索結果（すなわち、ＭＯの出現するルートノードＵＲＩ）がＲｅｓｕｌｔコマンドを通じて返送される。異なるノードがＲｅｓｕｌｔ要素の中の複数のＩｔｅｍ要素の中に分配されてもよく、または、各々が単一のＩｔｅｍを含む異なる結果の中に分配されてもよい。結果は、ＭＯＩＤを伝達してもよく、ＭＯＩＤを伝達しなくてもよい。
【０１２７】
ＭＯＩＤを伝達する結果を返送する方法は以下の通りである。結果のＩｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩは、端末によって検索されたノードのＵＲＩを伝達し、同時に、タイプ特性：？ｐｒｏｐ＝Ｔｙｐｅを含むパラメータを伝達し、ＭＯＩＤがＩｔｅｍ／Ｄａｔａの中で伝達される。ＭＯＩＤを伝達する結果を返送する方法は、対応するＧｅｔコマンドの中のＩｔｅｍの個数を制限することがなく、すなわち、サーバは、Ｇｅｔコマンドの中で端末から複数のＭＯＩＤに対応するＭＯの出現するルートノードＵＲＩを検索するため、同じＧｅｔコマンドの中で複数のＩｔｅｍを伝達することがある。具体的な使用例は以下の通りである。
【０１２８】
【数６】
【０１２９】
ＭＯＩＤを伝達しない結果の返送方法は以下の通りである。端末によって見つけられたノードのＵＲＩだけが、結果のＩｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩの中で伝達される。ＭＯＩＤを伝達しない結果の返送方法は、結果に対応するＧｅｔコマンドが１個のＩｔｅｍだけを伝達すること、すなわち、サーバがＧｅｔコマンドの中の端末から１個のＭＯＩＤに対応するＭＯの出現するルートノードＵＲＩを検索することを要求する。複数のＩｔｅｍが伝達される場合、サーバは返送された結果に対応するＩｔｅｍを識別することができない。使用例は以下の通りである。
【０１３０】
【数７】
【０１３１】
ＭＯのＵＲＩを獲得した後、サーバは、ＭＯの中のノードのより詳細な情報を獲得するためＧｅｔコマンドを送信するか、または、管理コマンドを直接的に送信することがある。
【０１３２】
２） 条件を満たすノードが見つからない場合（たとえば、Ｇｅｔコマンドの中のターゲットＵＲＩがリーフノードを参照するか、または、Ｇｅｔコマンドの中のターゲットＵＲＩが内部ノードを参照するとしても、ターゲットＵＲＩにルートがあるサブツリーの中のＭＯＩＤによって識別されたＭＯが発生しない場合）、結果は返送されず、「４０４ Ｎｏｔ Ｆｏｕｎｄ」がＧｅｔコマンドに対応する「Ｓｔａｔｕｓ」コマンドの中で返送される。
【０１３３】
端末が具体的なＭＯのルートノードを検索し、ルートノードのＵＲＩを返送する第２の方法では、具体的なＭＯＩＤは指定されない可能性があり、すなわち、ＧｅｔコマンドのＩｔｅｍ要素はデータサブ要素を含まないことがある。コマンドを受信した後、端末は、ターゲットＵＲＩに対応するノードの下で、すべてのＭＯのＭＯＩＤとＭＯのルートノードＵＲＩとを検索し、結果を返送する。検索方法は以下の通りでもよい。ターゲットＵＲＩに対応するノードのすべての内部サブノードの中で、空でないタイプ特性値を有する（すなわち、ノードのＦｏｒｍａｔ特性値がノードである）すべてのノードが検索されるか、または、マッピング表が端末で維持される。サーバのＧｅｔコマンドを受信するとき、端末はマッピング表の中で直接的に検索を行う。結果を返送する方法は、ＭＯＩＤを伝達する結果を返送する方法と同じである。
【０１３４】
第３の方法では、端末に対応する管理ツリーはサーバ側で維持される。Ｒｅｐｌａｃｅ、Ｃｏｐｙ、ＤｅｌｅｔｅおよびＡｄｄのような機器管理ツリーによって送信された管理ツリーノードを変更するコマンドに従って、オペレーションが成功したとき、サーバはサーバによって記憶されている対応する管理ツリーを維持する。機器管理ツリーの構造が取得される必要があるとき、サーバは、ターゲット・オペレーション・ノードのＵＲＩを判定するため、サーバ側で維持されたターゲット・オペレーション端末サブツリーの構造をまず獲得し、管理コマンドを生成し、コマンドをターゲット・オペレーション端末へ配信する。
【０１３５】
本実施形態では、この方法は、サーバが、端末ＤＭツリーの中でＭＯの位置を検索することが困難であるという課題を解決する。サーバが端末ＤＭツリーの中でＭＯの位置を検索する作業は、サーバと端末との間で分担されるので、ＭＯを検索する複雑なロジックは端末によってローカルに達成され、このことは、サーバが端末ＤＭツリーの中でＭＯの位置を効果的に検索する効率を改良し、管理オペレーション中の相互作用を削減し、管理効率を改良し、サーバおよびネットワーク伝送への負荷を軽減する。
【０１３６】
４． 管理プロセスでは、サーバによって端末へ配信された管理コマンドは、同じ管理コマンドが端末の複数の管理ノードで動作する機能を達成するために、複数のＩｔｅｍを伝達することがある。たとえば、Ｒｅｐｌａｃｅの文法は、＜！ＥＬＥＭＥＮＴ Ｒｅｐｌａｃｅ（ＣｍｄＩＤ，ＮｏＲｅｓｐ？，Ｃｒｅｄ？，Ｍｅｔａ？，Ｉｔｅｍ＋）＞であり、すなわち、Ｒｅｐｌａｃｅコマンドは、端末に、複数の管理ツリーノードのためのＲｅｐｌａｃｅアクションを実行するよう命令するために、複数のＩｔｅｍを伝達する。ある場合には、複数のＩｔｅｍが端末で順次処理されるべきであり、ある場合には、非順次に処理されることがある。サーバは、端末に、管理コマンドの中の複数のＩｔｅｍを順次実行するように命令するため、実行が順次であるかどうかを判定する。
【０１３７】
図８の実施形態に示されているように、以下のステップを含むコマンドの実行モードを管理する方法が提供される。
【０１３８】
管理コマンドの中の複数のサブコマンドを順次実行する命令は、サーバによって送信された管理コマンドの中で伝達される。
【０１３９】
管理コマンドの受信後、端末は、順次実行の命令を解析し、管理コマンドの中の各サブアイテムに対応する管理ノードで管理コマンドアクションを順次実行する。
【０１４０】
具体的に、Ｉｔｅｍを順次実行する命令は、サーバによって端末へ配信される管理コマンドの中で伝達される。伝達方法は以下の通りである（Ｒｅｐｌａｃｅコマンドが実施例として採用され、他の管理コマンドの伝達方法はＲｅｐｌａｃｅコマンドに類似している）。
【０１４１】
特性はＩｔｅｍ要素の親要素の中で伝達される。特性は、サブ要素が順次実行されることを示す。管理コマンドのＲｅｐｌａｃｅを実施例として採用すると、Ｒｅｐｌａｃｅのための命令特性を定義するＤＴＤは、＜！ＡＴＴＬＩＳＴ Ｒｅｐｌａｃｅ ｏｒｄｅｒ（Ｓｅｑｕｅｎｃｅ｜Ａｎｙ）“Ａｎｙ”＞であってもよい。特性順序の値は以下の意味をもつ。“Ａｎｙ”は、端末の実行ノードが制限されないことを表現する。“Ｓｅｑｕｅｎｃｅ”は、端末が順次実行のため命令されることを表現する。特性が追加された後の実施例は以下の通りである。
【０１４２】
【数８】
【０１４３】
命令のサブ要素はＩｔｅｍ要素の親要素の中に追加され（要素はＩｔｅｍ要素の兄弟要素である）、サブ要素が追加された後のＤＴＤは、＜！ＥＬＥＭＮＴ Ｒｅｐｌａｃｅ（ＣｍｄＩＤ，ＮｏＲｅｓｐ？，Ｃｒｅｄ？，Ｍｅｔａ？，Ｏｒｄｅｒ？，Ｉｔｅｍ＋）＞として定義される。
【０１４４】
【数９】
【０１４５】
シェル要素（すなわち、管理コマンドのサブ要素、および、同時にＩｔｅｍの親要素）は、Ｉｔｅｍが順次実行されるため追加される。シェル要素は、シェルの中の要素が順次実行される必要がないことを端末に通知するだけである。
【０１４６】
端末がＲｅｐｌａｃｅコマンドの中で伝達されるアイテムを順次実行する命令を解析した後、Ｒｅｐｌａｃｅコマンドはアイテム命令ノードのため順次実行される。
【０１４７】
本実施形態における方法は、サーバが端末に管理コマンドの中の複数のターゲット・オペレーション・アイテムに対し管理コマンドを順次実行するよう命令しない可能性がある、という課題を解決することを目指し、この方法では、サーバは端末による管理コマンドの実行モードを柔軟に制御し、実行エラーの可能性を低下させることがある。
【０１４８】
５． ＤＭの管理アクションが実行される前に、管理セッションはまずサーバと端末との間に確立されることが必要である。すべての管理コマンドは管理セッションにおいて達成される。サーバまたは端末がアクションを処理するために長時間を要することがある。代替的に、管理アクションが近いうちに送信されるべきことが期待される。セッションを再確立するコストを削減するため、現在のセッションが維持されることがある。図９において実施形態に示されているように、以下のステップを含む管理セッションを維持する方法が提供される。
【０１４９】
セッション維持コマンドが管理セッションの中で反対端へ送信されるべきことが判定されるとき、サーバまたは端末は、セッション維持コマンドを伝達するメッセージを反対端へ送信する。
【０１５０】
メッセージの受信後、反対端は肯定応答メッセージを返送し、セッション維持コマンドに対応するオペレーションを実行する。
【０１５１】
本実施形態では、以下の通り具体的に、２つの維持方法がセッションのため設計される。
【０１５２】
セッション中の中断を回避するため、セッション維持コマンドが設計されることがある。セッション維持アクションが実行されるべきことが判定されるとき（たとえば、データ処理の所要時間が長いと判定されたとき）、サーバまたは端末は、“ＳｙｎｃＭＬ”メッセージを他の当事者へ送信する。メッセージはセッション維持コマンドを伝達し、他の当事者は肯定応答を用いて応答する。プロセスは、セッション維持コマンドの送信者が大量の管理コマンドを他の当事者へ送信するか、または、他の当事者にセッションを終了することを通知するまで、必要に応じて反復的に実行されることがある。セッション維持コマンドを伝達する“ＳｙｎｃＭＬ”メッセージが他の管理コマンドを含む場合、他の当事者はセッション維持コマンドを無視することができる。
【０１５３】
図１０において実施形態に示されているように、サーバがセッション維持コマンドを送信することを実施例として採用して、セッションを維持するプロセス（端末がセッション維持コマンドを送信するプロセスは類似しているので、その説明はここでは省略されている）が説明される。
【０１５４】
ステップ２１では、認証が端末およびサーバで実行され、管理セッションが端末とサーバとの間で確立される。
【０１５５】
ステップ２２では、ＤＭコマンドの相互作用が両当事者のために実行される。
【０１５６】
ステップ２３では、サーバは、受信した管理コマンドを処理し、内部データ処理を実行し、セッションが待機する。
【０１５７】
ステップ２４では、サーバが、（サーバ内部の処理所要時間がセッション中断またはタイムアウトを引き起こす場合）セッションは維持されるべきであると判定したとき、サーバはセッション維持コマンドを送信する。
【０１５８】
ステップ２５では、端末は、セッション維持コマンド肯定応答メッセージを送信し、両当事者はサーバ側が新しい管理メッセージを送信するまでセッションを維持する。管理メッセージは管理コマンドもしくはセッション維持コマンドを伝達するか、または、管理メッセージは管理コマンドを伝達しない空メッセージである。
【０１５９】
ステップ２６では、サーバは端末データの処理を終了し、処理結果に従って端末へ送信されるべき管理コマンドを生成する。
【０１６０】
具体的に、セッション維持コマンドはＡｌｅｒｔコマンドを使用してもよく、新しいタイプコード“Ａｌｅｒｔ Ｃｏｄｅ”はＡｌｅｒｔコマンドのため設計されてもよい。コードの意味は表４に示されている通りである。
【０１６１】
【表４】
【０１６２】
コマンドの具体的な使用例は以下の通りである。
【０１６３】
【数１０】
【０１６４】
セッション維持コマンドは他のデータ（たとえば、Ｉｔｅｍ）を伝達しないことがある。サーバによって送信されたセッション維持コマンドを受信した後、端末は大量の管理コマンドを実行することはなく、以下の通りの肯定応答メッセージがそのコマンドに対し返送される。
【０１６５】
【数１１】
【０１６６】
実施形態は、一方の当事者が、もう一方の当事者はセッションを維持するよう命令されるべきであると判定したとき、一方の当事者がセッション維持コマンドを反対端へ送信する課題を解決し、セッションの異常な中断を減少し、効率を改善する。
【０１６７】
端末機器の管理はクライアント／サーバ（Ｃ／Ｓ）モードに属している。サーバは、管理アクションが配信されるべきであるかどうかと、配信されるべき管理アクションと、を判定する。サーバは支配的な地位にある。したがって、ＤＭにおけるセッションの終了はサーバによって判定される。
【０１６８】
本開示の実施形態では、セッションを終了させる命令をするコマンドが設計される。コマンドはサーバによって端末へ送信される。コマンドは端末へ配信されるべきパケットの中に別々に収容されるか、または、サーバによって端末へ配信されるべき管理コマンドの最終的なグループと共にパッケージ化され、その後に、端末へ送信されてもよい。前者のモードでは、端末はコマンドを受信した後にセッションを正常に終了する。後者のモードでは、端末は、まずパケットの中の他の管理コマンドを実行し、実行が完了した直後にセッションを終了し、関連した管理コマンドの実行結果はサーバへ返送されない。端末は、サーバが必要に応じて結果を獲得するように、最終的なパケットの中に管理コマンドの実行結果を一時的に記憶することもある。セッションを終了させる命令をするコマンドはＡｌｅｒｔコマンドを通じて実施されてもよく、具体的なＣｏｄｅは、Ａｌｅｒｔコマンドがセッションを正常に終了させることを命令するため設計される必要があり、たとえば、Ｃｏｄｅは１２１０である。
【０１６９】
従来技術では、セッションが終了されるべきであるかどうかを判定する方法は以下の通りである。端末は、サーバが空メッセージを送信した場合にセッションを終了する。命令は端末にとって不明確であり、端末の正確な管理に悪影響を与える。本実施形態で設計された具体的な終了命令コマンドは、端末の正確な管理を実現しやすくする。
【０１７０】
６． 端末で、ある一定のＭＯは複数のインスタンスを有することが可能である。しかし、時々、ＭＯインスタンスが一つのみアクティブ化される。たとえば、端末リソース・オペレーション・タイプのＭＯに対し、端末リソースは制限され、排他的であるので、複数のＭＯインスタンスが同時にまたはある一定の期間の範囲内に存在する場合、リソースは、１個のＭＯインスタンスだけによって占有されて作動（すなわち、アクティブ化）されることがある。他のＭＯインスタンスを通じてサーバによって配信された管理アクションは拒絶され、エラーコード４０３、４０５または５００が返送される。従来技術では、複数のＭＯインスタンスが端末の中に存在するとき、サーバは現在アクティブ化されているインスタンスを認知しないので、サーバ管理の難しさが増加する。図１１に示されているように、以下のステップを含む端末アクティブ化ＭＯを取得する方法が提供される。
【０１７１】
端末が端末リソースをＭＯインスタンスに割り当てるか、または、端末がＭＯインスタンスをアクティブ化して使用し、すなわち、ＭＯインスタンスは現在利用できるＭＯとしての機能を果たす。
【０１７２】
ＭＯインスタンスをローカルに記録するとき、サーバは、端末アクティブ化ＭＯを獲得するためにセッション管理プロセスの中でＧｅｔコマンドを端末へ送信する。端末はアクティブ化ＭＯに関する情報をサーバへ返送する。
【０１７３】
本実施形態では、現在アクティブ化されているＭＯインスタンス（すなわち、端末リソースを現在占有中であり、かつ、端末リソースを動作させることができるＭＯ）を指示する２つの方法は以下の通りである。
【０１７４】
端末はアクティブ化ＭＯリストをローカルに維持する。アクティブ化ＭＯリストは機器管理ツリーの中に表現されていない。サーバは、Ｇｅｔコマンドを端末のルートノードへ送信し、パラメータを伝達することによりデータを獲得する。
【０１７５】
Ｇｅｔコマンドの中で伝達されるパラメータは、たとえば、．？ｌｉｓｔ＝ＡｃｔｉｖｅｄＲｅｓｏｕｒｃｅＭＯとして設計されてもよいＧｅｔ／Ｉｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＬの中で伝達されてもよい。端末は、端末リソースに対応し、アクティブ化されたＭＯのルートノードのＵＲＩを返送する。サーバは、ある一定のタイプの具体的なＭＯを返送するよう端末に命令するために、コマンドのアイテムの中でデータ要素を伝達してもよく、データ要素の値はＭＯＩＤである。使用例は以下の通りである。
【０１７６】
【数１２】
【０１７７】
端末は、アクティブ化ＭＯインスタンスの情報を管理ツリーに記憶し、具体的には以下の事項を含む。
【０１７８】
ａ． 管理ツリーのサブツリーは機器管理ツリーの中に追加される。端末のすべてのアクティブ化ＭＯのルートノードのＵＲＩリストは、管理ツリーのサブツリーに記憶される。追加された管理サブツリーは図１２に示されている通りであり、アクティブ化ＭＯリストが記憶される管理サブツリーはＤｅｖＤｅｔａｉｌ ＭＯに記憶されてもよい。サーバは、端末アクティブ化ＭＯを取得するために、値を獲得するため直接的にＧｅｔコマンドをアクティブ化ＭＯノードのサブノードに配信してもよい。具体的なコマンドおよびオペレーションは他のノードのコマンドおよびオペレーションに類似しているので、ここではそれらの説明は省略される。
【０１７９】
ｂ． ＭＯインスタンスがアクティブ化ＭＯインスタンスであるかどうかがＭＯインスタンスのルートノードのノード特性値に記録される。その後、サーバは、ＭＯインスタンスがアクティブ化ＭＯインスタンスであるかどうかを判定するために直接的にＭＯのルートノードの特性値を獲得する。具体的な方法は以下の通りである。
【０１８０】
既存のＭＯのルートノードのタイプ特性値の構造が拡張される。変更された値構造は複合値を伝達することができる。複合値は、ＭＯＩＤフィールドと、ＡｃｔｉｖａｔｅｄまたはＤｅａｃｔｉｖａｔｅｄフィールドの２つのフィールドを含む。２つのフィールドはプラス符号で繋がれる。使用例は以下の通りである。
【０１８１】
ある一定のＭＯのアクティブ化状態のルートノードのＴｙｐｅ特性値はＭＯＩＤ＋Ａｃｔｉｖａｔｅｄである。
【０１８２】
端末は、機器管理ツリーの中のＭＯのアクティブ化状態を判定し、ＭＯのルートノードのタイプ特性値を維持する。
【０１８３】
端末のアクティブ化ＭＯを取得するとき、サーバは、値を獲得するためにＧｅｔコマンドをＭＯのルートノードのＴｙｐｅ特性に送信し、その後、ＭＯインスタンスがアクティブ化ＭＯであるかどうかを判定するためＡｃｔｉｖａｔｅｄ／Ｄｅａｃｔｉｖａｔｅｄフィールドの値を抽出する。
【０１８４】
本実施形態では、端末がアクティブ化ＭＯを特定し、その後、サーバがアクティブ化ＭＯを獲得する方法が提供され、アクティブ化ＭＯが識別されないので、サーバがＭＯをアクティブ化するため即座にオペレーションを検索しない可能性があるという従来技術における課題を解決し、その結果、管理効率が改良される。
【０１８５】
本開示は異なる形式で複数の特定の実施形態を有する。以下、本開示の技術的解決手段が図２ないし１２を参照して説明される。これは、本開示の具体的な実施例が実施形態による具体的なプロセスまたは構造だけに限定されることを意味しない。当業者には上述された具体的な実施が多数の好ましい解決手段の中のいくつかの実施例に過ぎないことを理解されたい。
【０１８６】
実施形態では、本開示は、第１の受信モジュールおよび構成モジュールを含むＤＭ端末を提供する。第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。
【０１８７】
さらに、本実施形態は警告モジュールおよび第１の記録モジュールをさらに含んでもよい。警告モジュールは、端末のブートストラップまたは再ブートストラップのための警告情報を伝達するセッション要求メッセージをサーバへ送信するよう適合される。第１の記録モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバのサーバアカウントＭＯの管理ノードに記録するよう適合される。
【０１８８】
構成モジュールは、検索ユニット、第１の処理ユニット、および第２の処理ユニットを含む。検索ユニットは、ＳｅｒｖｅｒＩＤに対応するサーバアカウントＭＯが端末ＤＭツリーの中に存在するかどうかを検索するよう適合する。第１の処理ユニットは、ブートストラップが反復ブートストラップまたは再ブートストラップであるかどうかを区別し、検索ユニットが端末ＤＭツリーの中でＳｅｒｖｅｒＩＤに対応するサーバアカウントＭＯを見つけたときに、対応するオペレーションを実行するよう適合する。第２の処理ユニットは、検索ユニットが端末ＤＭツリーの中のＳｅｒｖｅｒＩＤに対応するサーバアカウントＭＯを見つけることに失敗したとき、ブートストラップ情報に従って端末ＤＭツリーの中のサーバのサーバアカウントＭＯを生成するよう適合される。
【０１８９】
実施形態では、本開示は、第１の受信モジュールおよび認証モジュールを含むＤＭ装置を提供する。第１の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを受信するよう適合される。認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。
【０１９０】
実施形態では、本開示は、第１の送信モジュールおよび第１の獲得モジュールを含む別のＤＭ装置を提供する。第１の送信モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバアカウントＭＯに記録する管理ノードの値を獲得するためにＧｅｔコマンドを送信するよう適合される。第１の獲得モジュールは構成モード情報を獲得するよう適合される。
【０１９１】
実施形態では、本開示は、端末およびサーバを含むブートストラップシステムを提供する。端末は、第１の受信モジュール、構成モジュール、および警告モジュールを含む。第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。警告モジュールは、端末のブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを送信するよう適合される。サーバは第１の受信モジュールおよび認証モジュールを含む。第１の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを受信するよう適合される。認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。
【０１９２】
実施形態では、本開示は、端末およびサーバを含む別のブートストラップシステムを提供する。端末は、第１の受信モジュール、構成モジュール、および第１の記録モジュールを含む。第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。第１の記録モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバのサーバアカウントＭＯの管理ノードに記録するよう適合される。サーバは、第１の送信モジュールおよび第１の獲得モジュールを含む。第１の送信モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバアカウントＭＯに記録する管理ノードの値を獲得するためにＧｅｔコマンドを送信するよう適合される。第１の獲得モジュールは構成モード情報を獲得するよう適合される。
【０１９３】
実施形態では、本開示は、作成モジュールおよび第２の記録モジュールを含む別のＤＭ端末を提供する。作成モジュールは管理ノードを端末のＤＭツリーに追加するよう適合される。第２の記録モジュールは、端末によってサポートされたＤＭオブジェクトタイプを端末のＤＭツリーに追加された管理ノードに記録するよう適合される。
【０１９４】
実施形態では、本開示は、第２の獲得モジュールおよび決定モジュールを含む別のＤＭ装置を提供する。第２の獲得モジュールは、端末との管理セッションにおいて端末のＤＭツリーに追加された端末によってサポートされたＤＭオブジェクトタイプを記録する管理ノードの値を獲得するよう適合される。決定モジュールは管理ノードの値に従って端末によってサポートされたＤＭオブジェクトタイプを判定するよう適合される。
【０１９５】
実施形態では、本開示は、端末およびサーバを含む管理端末システムを提供する。端末は、作成モジュールおよび第２の記録モジュールを含む。作成モジュールは管理ノードを端末のＤＭツリーに追加するよう適合される。第２の記録モジュールは、端末によってサポートされたＤＭオブジェクトタイプを端末のＤＭツリーに追加された管理ノードに記録するよう適合される。サーバは、第２の獲得モジュールおよび決定モジュールを含む。第２の獲得モジュールは、端末との管理セッションにおいて端末のＤＭツリーに追加された端末によってサポートされたＤＭオブジェクトタイプを記録する管理ノードの値を獲得するよう適合される。決定モジュールは管理ノードの値に従って端末によってサポートされたＤＭオブジェクトタイプを判定するよう適合される。
【０１９６】
実施形態では、本開示は、第２の受信モジュールおよび実行モジュールを含むＤＭ端末をさらに提供する。第２の受信モジュールは、端末ＤＭツリーのターゲット・オペレーション・ノードを伝達するパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報のＧｅｔコマンドとを受信するよう適合される。実行モジュールは、ターゲット・オペレーション・ノードのパス情報および値フィルタリング情報に従ってサブツリーの構造情報、および、サブツリーの中の各ノードの特性値を獲得し、特性値および構造情報を返送するよう適合される。
【０１９７】
実施形態では、本開示は、第２の送信モジュールおよび第３の受信モジュールを含む別のＤＭ装置を提供する。第２の送信モジュールは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報とを伝達するＧｅｔコマンドを送信するよう適合される。第３の受信モジュールは、サブツリーの構造情報と、端末によって返送されたサブツリーの中の各ノードの特性値とを受信するよう適合される。
【０１９８】
実施形態では、本開示は、端末およびサーバを含み、管理ノード特性を獲得するシステムを提供する。端末は、第２の受信モジュールおよび実行モジュールを含む。第２の受信モジュールは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報のＧｅｔコマンドとを受信するよう適合される。実行モジュールは、ターゲット・オペレーション・ノードのパス情報および値フィルタリング情報に従って、サブツリーの構造情報、および、サブツリーの中の各ノードの特性値を獲得し、特性値および構造情報を返送するよう適合される。サーバは、第２の送信モジュールおよび第３の受信モジュールを含む。第２の送信モジュールは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報とを伝達するＧｅｔコマンドを送信するよう適合される。第３の受信モジュールは、サブツリーの構造情報と、端末によって返送されたサブツリーの中の各ノードの特性値とを受信するよう適合される。
【０１９９】
実施形態では、本開示は、第４の受信モジュールおよび検索モジュールを含む別のＤＭ端末を提供する。第４の受信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを受信するよう適合される。検索モジュールは、検索されるべきサブツリーの中でＭＯを検索し、見つけられたＭＯのルート・ノード・パスを返送するよう適合される。
【０２００】
実施形態では、本開示は、第３の送信モジュールおよび第５の受信モジュールを含む別のＤＭ装置を提供する。第３の送信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを送信するよう適合される。第５の受信モジュールは、端末によって返送された検索されるべきサブツリーの中のＭＯのルート・ノード・パスを受信するよう適合される。
【０２０１】
本開示は、端末およびサーバを含み、ＭＯアドレスを検索するシステムを提供する。端末は、第４の受信モジュールおよび検索モジュールを含む。第４の受信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータと、を伝達するＧｅｔコマンドを受信するよう適合される。検索モジュールは、検索されるべきサブツリーの中でＭＯを検索し、見つけられたＭＯのルート・ノード・パスを返送するよう適合される。サーバは、第３の送信モジュールおよび第５の受信モジュールを含む。第３の送信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータと、を伝達するＧｅｔコマンドを送信するよう適合される。第５の受信モジュールは、端末によって返送された検索されるべきサブツリーの中のＭＯのルート・ノード・パスを受信するよう適合される。
【０２０２】
当業者には、実施形態による方法のステップの全部または一部が関連したハードウェアに命令するプログラムによって実施されることがあることを理解されたい。プログラムはコンピュータ読み取り可能な媒体に記憶されることができる。プログラムが実行されるとき、実施形態による方法のステップが実行される。記憶媒体は、リード・オンリ・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気ディスクまたは光ディスクのようなプログラムコードを記憶することができる媒体であればどのような媒体であってもよい。
【０２０３】
最後に、上記実施形態は本開示の技術的解決手段を単に説明するために与えられているだけであり、本開示を限定することを意図しないことに注意を要する。本開示は実施形態を参照して詳細に記載されているが、本開示の精神および範囲から逸脱しない限り、実施形態に記載された技術的解決手段に対する変更、または、技術的解決手段のいくつかの技術的特徴に対する等価的な置換が行われることがあることが当業者には理解されたい。
【技術分野】
【０００１】
本開示は、ネットワーク通信の技術分野での機器管理の方法、端末、装置、およびシステムに関する。
【背景技術】
【０００２】
モバイル端末はモバイル・オペレーション・サービス・システムにおける重要なコンポーネントである。機器管理（ＤＭ、Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）とは、データパケットがオーバ・ザ・エア（ＯＴＡ、Ｏｖｅｒ Ｔｈｅ Ａｉｒ）モードでネットワーク側から端末機器へダウンロードされ、端末機器が、パラメータ・コンフィギュレーション、ソフトウェア設置、およびエラー診断のようなその後の機能を達成するため、処理を実行するよう命令されることを意味する。
【０００３】
オープン・モバイル・アライアンスＤＭ（ＯＭＡ ＤＭ）により設計されたＤＭ仕様では、端末機器の管理のためのプロトコルサポートは既に達成されている。図１は、端末機器を管理するＤＭサーバの全体的構造の概略図である。端末機器上のＤＭクライアントはＤＭサーバによって配信された管理コマンドを説明し実行するよう適合している。端末機器上のＤＭ管理ツリーは、ＤＭサーバがＤＭプロトコルを通じて端末機器を管理するインターフェイスとしてみなされることがある。管理オブジェクト（ＭＯ、Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）のグループは管理ツリーの中に存在する。ＤＭサーバは、ＭＯの中のノード（管理ノード）の動作を通じて端末リソースを管理する目的を達成する。
【０００４】
図１に示されているように、従来技術では、ＤＭ管理は２つのステップ、すなわち、ブートストラップおよびその後の管理を通じて実行される。ブートストラップは、サーバと端末機器との間の管理セッションが実際の管理のため確立される前に起こり、（ユーザ名およびパスワードのような）アカウント情報と（接続パラメータのような）他のパラメータとを構成するよう適合する。その後の管理プロセスにおいて、管理セッションが確立される。サーバは、端末機器のＭＯを通じて、端末の（ファームウェアバージョン、ソフトウェアバージョン、および大規模オブジェクトサポートのような）基本情報を獲得し、その後の管理アクションの基礎としてこの基本情報を使用することができる。
【０００５】
従来技術では、端末機器の管理のためのプロトコルサポートは既に達成されているが、管理有効性、効率、および通信トラフィックのような問題が依然として存在する。たとえば、サーバは、端末ＤＭオブジェクトのアドレスおよび（ソフトウェアコンポーネント管理のサポートおよびファームウェアアップグレードのサポートの能力のような）端末によってサポートされるＤＭ能力を迅速に取得しない可能性があり、端末は再ブートストラップのためＳｍａｒｔＣａｒｄを使用する。具体的には以下の通りである。
【０００６】
１． 端末がローカルに再ブートストラップされた後（たとえば、機器が交換された後）、サーバは端末がブートストラップされたことが認知しないので、サーバに記憶されている認証関連情報は端末がブートストラップされた後の認証関連情報と矛盾する場合があり、結果として、同一性認証が両当事者のためには達成されない可能性があり、通常の管理は失敗することになる。
【０００７】
２． サーバが端末機器による管理ツリーの制限または端末による管理ツリーの実施の制限に関する状況を取得することを可能にするため、従来技術では、端末製造業者は、その端末製造業者の機器を記述し、機器記述フレームワーク（ＤＤＦ、Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）を介してＤＭ当事者による照会のための記述を公表する。しかし、既存プロトコルでは、サーバ側は端末機器を通じてその対応するＤＤＦを見つけることができないため、サーバがＤＤＦを獲得することはより困難である。
【０００８】
３． サーバは、端末によってサポートされる管理オブジェクト（ＭＯ）タイプを取得しない可能性があり、ネットワークリソースをさらに浪費する。ＤＤＦは、通常は、静的であるか、または、殆ど動的に変更されないので、サーバが端末によってサポートされるすべてのＭＯタイプをＤＤＦに従って取得することは難しい。サーバは、対応する管理コマンドが配信され、配信されたコマンドが大量のデータ（たとえば、ソフトウェアコンポーネント管理）を伝達した後に限り、端末によって返送される結果を通じて端末がある一定のＤＭ能力をサポートするかどうかを判定するので、サーバおよびネットワークリソースは浪費される。
【０００９】
４． 従来技術では、サーバは、非直列化モードにおいて一括して機器管理ツリー上のある一定の管理サブツリーの中のすべての管理ノードの具体的な特性値を獲得しない可能性があり、したがって、特性は数回に亘って獲得される必要があり、結果として、効率が低くなる。
【００１０】
５． サーバが端末の管理ノードを検索することは非常に困難であり、エアリソースが消費される。端末管理ノードを獲得するため、サーバは、数回に亘って端末と相互に作用するか、または、端末のディレクトリ構造全体を獲得する必要がある場合があるので、エアリソースは占有され、サーバ上の負荷が増大する。
【００１１】
６． 従来技術では、サーバは、端末に単一の管理コマンドで複数の要素を順次実行するよう命令しない可能性があるので、順次実行を必要とするアクションは、実施のため順次実行される複数の管理コマンドに分割される必要があり、したがって、端末によるメッセージ管理および解析と実行とのコストが増大する。
【００１２】
７． 端末またはサーバがアクションを処理するために長時間を要するとき、セッションは中断される場合があり、管理アクションが完了できない。このようにして、長時間を要する管理は困難になる。その上、当事者が管理コマンドは間もなく送信される必要があることを確認するとき、現在のセッションは維持されない可能性があり、現在のセッションは中断される場合がある。管理セッションは、管理コマンドがその後に送信される必要があるときに再確立されるべきであり、大きなコストを引き起こす。
【００１３】
８． 端末が複数のＭＯインスタンスを有するとき、サーバは現在アクティブ化されているインスタンスを認知しないため、結果として、サーバ管理の難易度が高くなる。
【発明の概要】
【発明が解決しようとする課題】
【００１４】
実施形態では、本開示は、ユーザがブートストラップを実行した後に通常の管理が実行されない可能性があるという従来技術における第１の技術的課題を解決する。
【００１５】
実施形態では、本開示は、プロトコルサーバが対応する機器記述フレームワーク（ＤＤＦ）を獲得することが難しいという従来技術における第２の技術的課題を解決する。
【００１６】
実施形態では、本開示は、サーバが非直列化モードにおいて一括して機器管理ツリー上のある一定の管理サブツリーの中のすべての管理ノードの具体的な特性値を獲得しないことがあるという従来技術における第３の技術的課題を解決する。
【００１７】
実施形態では、本開示は、サーバが端末の管理ノードを検索することが難しく、エアリソースが浪費され、サーバの負荷が高いという従来技術における第４の技術的課題を解決する。
【００１８】
実施形態では、本開示は、既存のサーバが端末に、単一の管理コマンドの中の複数の要素を順次実行するよう命令しない可能性があるという従来技術における第５の技術的課題を解決する。
【００１９】
実施形態では、本開示は、セッションを維持する方法が利用できないとき、予期しない中断がセッションの中で起こる可能性があるという従来技術における第６の技術的課題を解決する。
【００２０】
実施形態では、本開示は、端末が複数の管理オブジェクト（ＭＯ）インスタンスを有し、サーバが現在アクティブ化されているインスタンスを認知しないので、サーバを管理する難易度が高くなるという従来技術における第７の技術的課題を解決する。
【課題を解決するための手段】
【００２１】
本開示の実施形態における第１の技術的課題を解決するため、本開示の実施形態は、以下のステップを含むブートストラップ方法を提供する。
端末はサーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を含むサーバのブートストラップ情報を受信する。
端末はブートストラップまたは再ブートストラップのためブートストラップ情報を使用する。
【００２２】
本開示の実施形態における第１の技術的課題を解決するため、本開示の実施形態は、第１の受信モジュールおよび構成モジュールを含む機器管理（ＤＭ）端末をさらに提供する。
第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。
構成モジュールはブートストラップまたは再ブートストラップのためブートストラップ情報を使用するよう適合される。
【００２３】
本開示の実施形態における第１の技術的課題を解決するため、本開示の実施形態は、第１の受信モジュールおよび認証モジュールを含むＤＭ装置をさらに提供する。
第１の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを受信するよう適合される。
認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。
【００２４】
本開示の実施形態における第１の技術的課題を解決するため、本開示の実施形態は、端末およびサーバを含むブートストラップシステムをさらに提供する。
端末は、第１の受信モジュール、構成モジュール、および警告モジュールを含む。
第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。
構成モジュールはブートストラップまたは再ブートストラップのためブートストラップ情報を使用するよう適合される。
警告モジュールは、端末のブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを送信するよう適合される。
サーバは第１の受信モジュールおよび認証モジュールを含む。
第１の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを受信するよう適合される。
認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。
【００２５】
本開示の実施形態における第２の技術的課題を解決するため、本開示の実施形態は、以下のステップを含むＤＤＦを獲得する方法を提供する。
管理ノードが端末のＤＭツリーに追加され、端末のＤＤＦの記憶アドレスが管理ノードに記憶される。
管理プロセスでは、サーバはＤＤＦの記憶アドレスを獲得するために端末から管理ノードの値を獲得する。
サーバはＤＤＦの記憶アドレスに従って端末のＤＤＦを獲得する。
【００２６】
本開示の実施形態における第３の技術的課題を解決するため、本開示の実施形態は、以下のステップを含む管理ノード特性を獲得する方法を提供する。
サーバは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報および獲得されるべき値フィルタリング情報を伝達するＧｅｔコマンドを端末へ送信し、値フィルタリング情報は、ルートとしてターゲット・オペレーション・ノードを含むサブツリーの構造情報を返送する命令と、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令とを含む。
端末がサーバからＧｅｔコマンドを受信した後、サブツリーの構造情報およびサブツリーの中の各ノードの特性値は、ターゲット・オペレーション・ノードのパス情報および値フィルタリング情報に従って獲得され、特性値および構造情報がサーバへ返送される。
【００２７】
本開示の実施形態における第４の技術的課題を解決するため、本開示の実施形態は、以下のステップを含むＭＯアドレスを検索する方法を提供する。
サーバは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索を命令するパラメータとを伝達するＧｅｔコマンドを端末へ送信し、パラメータは端末に検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう命令する。
端末がＧｅｔコマンドを受信した後、ＭＯは検索されるべきサブツリーの中で検索され、見つけられたＭＯのルート・ノード・パスがサーバへ返送される。
【００２８】
本開示の実施形態における第４の技術的課題を解決するため、本開示の実施形態は、第４の受信モジュールおよび検索モジュールを含むＤＭ端末をさらに提供する。
第４の受信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索を命令するパラメータとを伝達するＧｅｔコマンドを受信するよう適合され、パラメータは端末に検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう命令する。
検索モジュールは、サーバが検索されるべきサブツリーの中にアクセス制御リスト（ＡＣＬ）を有するＭＯを検索し、Ｇｅｔコマンドのステータス情報を返送した後、見つけられたＭＯのルート・ノード・パスをサーバへ返送するよう適合される。
【００２９】
本開示の実施形態における第４の技術的課題を解決するため、本開示の実施形態は、第３の送信モジュールおよび第５の受信モジュールを含むＤＭ装置をさらに提供する。
第３の送信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索を命令するパラメータとを伝達するＧｅｔコマンドを送信するよう適合され、パラメータが端末に検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう命令する。
第５の受信モジュールは、端末から返送されたＧｅｔコマンドのステータス情報と検索されるべきサブツリーの中のＭＯのルート・ノード・パスとを受信するよう適合する。
【００３０】
本開示の実施形態における第４の技術的課題を解決するため、本開示の実施形態は、端末およびサーバを含むＭＯアドレスを検索するシステムをさらに提供する。
端末は第４の受信モジュールおよび検索モジュールを含む。
第４の受信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索を命令するパラメータとを伝達するＧｅｔコマンドを受信するよう適合され、パラメータが端末に検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう命令する。
検索モジュールは、サーバが検索されるべきサブツリーの中にＡＣＬを有するＭＯを検索し、Ｇｅｔコマンドのステータス情報を返送した後、見つけられたＭＯのルート・ノード・パスをサーバへ返送するよう適合される。
サーバは第３の送信モジュールおよび第５の受信モジュールを含む。
第３の送信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索を命令するパラメータとを伝達するＧｅｔコマンドを送信するよう適合され、パラメータが端末に検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう命令する。
第５の受信モジュールは、端末から返送されたＧｅｔコマンドのステータス情報と検索されるべきサブツリーの中のＭＯのルート・ノード・パスとを受信するよう適合される。
【００３１】
本開示の実施形態における第５の技術的課題を解決するため、本開示の実施形態は、以下のステップを含むコマンドの実行モードを管理する方法を提供する。
サーバは、管理コマンドの中の複数のサブアイテムを順次実行する命令を伝達する管理コマンドを送信する。
管理コマンドを受信した後、端末は、順次実行の命令を解析し、管理コマンドの中の各サブアイテムに対応する管理ノードの順序に管理コマンドを実行する。
【００３２】
本開示の実施形態における第６の技術的課題を解決するため、本開示の実施形態は、以下のステップを含む管理セッションを維持する方法を提供する。
ＤＭセッションがサーバと端末との間に確立され、ＤＭコマンドがＤＭセッションの中で送信される。
サーバまたは端末は受信された管理コマンドを処理し、管理コマンドを処理する所要時間がセッション中断またはタイムアウトを引き起こすと判定されたとき、セッション維持コマンドを伝達するＤＭメッセージを反対端へ送信する。
メッセージを受信した後、反対端は、肯定応答メッセージを返送し、セッション維持コマンドの送信元によって送信された新しい管理メッセージが受信されるまでセッションを維持し、管理メッセージが管理コマンドもしくはセッション維持コマンドを伝達するか、または、管理コマンドを伝達しない空メッセージである。
【００３３】
本開示の実施形態における第７の技術的課題を解決するため、本開示の実施形態は、以下のステップを含む端末アクティブ化ＭＯを取得する方法を提供する。
端末は端末リソースをＭＯインスタンスに割り当てるか、または、端末はＭＯインスタンスを使用するためアクティブ化する。
端末はＭＯインスタンスをローカルに記録し、サーバが管理セッションのプロセスの中で端末アクティブ化ＭＯを獲得するためにＧｅｔコマンドを端末へ送信し、端末がローカルに記録されたアクティブ化ＭＯに関する情報をサーバへ返送する。
【図面の簡単な説明】
【００３４】
本開示の技術的な解決手段は、添付図面を参照してさらに詳細に記載される。
【図１】従来技術において端末を管理するＤＭサーバの全体的構造の概略図である。
【図２】本開示の実施形態によるブートストラップ方法のフローチャートである。
【図３】本開示の実施形態によるブートストラップ方法においてブートストラップタイプ管理ノードをＤＭＡｃｃ ＭＯに追加する概略図である。
【図４】本開示の実施形態によるＤＤＦを獲得する方法のフローチャートである。
【図５】本開示によるＤＤＦを獲得する方法の解析プロセスの概略図である。
【図６】本開示の実施形態による端末管理方法において機器管理ツリーの中にサポートノードを追加する概略図である。
【図７】本開示の実施形態によるＭＯアドレスを検索する方法の概略図である。
【図８】本開示の実施形態によるコマンドの実行モードを管理する方法のフローチャートである。
【図９】本開示の実施形態による管理セッションを維持する方法のフローチャートである。
【図１０】本開示の実施形態による管理セッションを維持する方法の解析プロセスのフローチャートである。
【図１１】本開示の実施形態による端末アクティブ化ＭＯを取得する方法のフローチャートである。
【図１２】本開示の実施形態による機器管理ツリーの中のアクティブ化ＭＯに関する情報を記憶する概略図である。
【発明を実施するための形態】
【００３５】
機器管理（ＤＭ）は、主として２つの段階、すなわち、ブートストラップの段階とその後の管理の段階とにおいて実行される。ブートストラップは、管理セッションがサーバと端末機器との間で確立される前に生じ、主として、端末で、サーバの（サーバのアドレス、ユーザ名、およびパスワード）のようなアカウント情報を構成し、（ネットワーク・アクセス・ポイントの情報のような）他のパラメータを構成する。ブートストラップ段階で構成された情報は、その後の管理セッションの確立のための基礎となる。サーバのアカウント情報の構成が完了した後、サーバは端末を管理することができる。管理アクションは、サーバと端末機器との間に確立された管理セッションを通じて達成される。
【００３６】
本開示における改良点は、ブートストラップおよびその後の管理セッションを含む２つの部分を用いて以下で詳細に明らかにされている。
【００３７】
Ｉ． ブートストラップ
【００３８】
ブートストラップの主な目的は、端末とサーバとの間に通常の管理セッションを確立することを可能にするためサーバのアカウント情報を構成することである。同時に、接続設定のような他の関連パラメータがさらに構成されることがある。この具体的な構成方法は以下の通りである。構成されるべきサーバのアカウント情報および他の関連パラメータは、クライアントプロビジョニング（ＣＰ）ファイルフォーマットまたは管理オブジェクト（ＭＯ）直列化フォーマットの中にカプセル化され、カプセル化されたブートストラップ情報がプレインストレーション配信、ＯＴＡプッシュ、または、ＳｍａｒｔＣａｒｄのようなモードで端末へ配信される。端末はサーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を格納するサーバのカプセル化されたブートストラップ情報を受信し、端末はブートストラップまたは再ブートストラップのためブートストラップ情報を使用する。構成の主な仕事は、ブートストラップ情報の中のサーバのアカウント情報を、端末ＤＭツリーの中のサーバアカウントＭＯ（以下、ＤＭＡｃｃと称する）と他の関連ＭＯとに変換することである。その後、ＤＭＡｃｃに対応するサーバに先に接続されていた端末は、サーバ上の管理状態をアクティブ化する。接続が確立されているとき、サーバは、「ＬｏｃＮａｍｅ」（ＬｏｃＮａｍｅの値はＤＭＡｃｃ ＭＯの中で「ＡＡＵＴＨＮＡＭＥ」と呼ばれるノードの値である）を通じて端末のユーザ名を取得し、そして、認証のためのユーザ名に対応するパスワードをさらに使用する。メッセージ・ダイジェスト・アルゴリズム５（ＭＤ５）認証では、ノンスがリプレイ攻撃を阻止するために取得されることがさらに必要である。
【００３９】
特に、ＳｍａｒｔＣａｒｄモードは、初期構成を都合良く実行し、端末のアカウント情報に問題が起こったとき、または、端末（たとえば、携帯電話機）が交換されたとき、再構成を実行することがある安全かつ便利な構成モードである。端末機器が構成済みのアカウントに関する再構成（たとえば、ＳｍａｒｔＣａｒｄモードによる再構成）をローカルで実行するとき、サーバが初期構成後にＯＴＡモードにおいて構成済みのアカウントのパスワードを変更し、ＳｍａｒｔＣａｒｄ上のブートストラップ情報の中のアカウントに対応するパスワードが変更されていないならば、端末のローカル再構成後に、ＤＭＡｃｃ上のパスワードはリセットされることになる（パスワードは変更前に元の値に再変換される）。再構成は、ローカルなアクションであり、サーバはアカウント情報が再構成されたことを知ることができないので、端末に記憶されているパスワードはサーバに記憶されているパスワードと矛盾する。同時に、サーバは端末を認証できず、管理セッションは確立されない可能性がある。
【００４０】
本開示の第１の実施形態では、ブートストラップ構成問題が解決される。２つの主要な方法が以下の通り説明される。
【００４１】
１． 図２に示されているように、サーバのアカウント情報がブートストラップまたは再ブートストラップされた後、端末はセッション要求メッセージをサーバへ送信する。セッション要求メッセージは、端末がブートストラップまたは再ブートストラップされたことをサーバに警告するよう構成される。
【００４２】
サーバがセッション要求メッセージを受信した後、パスワードと、セッション要求メッセージの中で搬送されるＬｏｃＮａｍｅに対応するノンスとが、端末を認証するためサーバによって記憶されたブートストラップ情報から獲得される。認証が成功した後、サーバ側の認証情報が初期化されるか、または、リセットされる。
【００４３】
端末がサーバに、端末がブートストラップまたは再ブートストラップされたことを警告する方法は以下の通りである。
【００４４】
端末がブートストラップまたは再ブートストラップされた後、端末は、最初に、端末がブートストラップまたは再ブートストラップされたことをサーバに知らせるため、セッション要求メッセージをサーバへ送信する。セッション要求メッセージは、端末機器情報、ＬｏｃＮａｍｅ、端末認証情報、および、ブートストラップまたは再ブートストラップ警告情報を含むことができる。ブートストラップまたは再ブートストラップ警告情報の具体的な実施方法は以下の通りである。
【００４５】
端末は、警告情報を実施するために「Ａｌｅｒｔ」コマンドの特定のタイプコードの「Ａｌｅｒｔ」コマンドを使用する。ＡｌｅｒｔコマンドおよびＡｌｅｒｔコマンドのタイプコードは、特に、端末情報レポートＡｌｅｒｔコマンド（すなわち、コマンド・タイプコードが１２２６である一般的な警告（Ｇｅｎｒｉｃ Ａｌｅｒｔ））と、端末事象レポート警告コマンド（すなわち、コマンド・タイプコードが１２２４であるクライアント事象警告（Ｃｌｉｅｎｔ Ｅｖｅｎｔ Ａｌｅｒｔ））、または、具体的には以下の通りの警告情報を報告するための新しいセッションタイプであってもよい。
【００４６】
事象タイプ（Ｅｖｅｎｔ ｔｙｐｅ）は、たとえば、一般的な警告、または、クライアント事象警告、たとえば、ｏｒｇ．ｏｐｅｎｍｏｂｉｌｅａｌｌｉａｎｃｅ．ｄｍ．ｂｏｏｔｓｔｒａｐを採用するために最初に定義される必要がある。以下、一般的な警告は一実施例として採用されている。クライアント事象報告を使用する方法は以下に類似する。
【００４７】
【数１】
【００４８】
警告情報を報告する新しいセッションタイプを追加する方法は以下の通りである。新しいＡｌｅｒｔコマンドのタイプコードが追加される。タイプコードを伝達するＡｌｅｒｔコマンドは新しいセッションタイプを指示するよう構成される。タイプコードは１２０２であってもよい。実施例は以下の通りである。
【００４９】
【数２】
【００５０】
端末によって開始されたサーバへのセッション要求メッセージは、ブートストラップ警告情報を伝達する。サーバが要求メッセージを受信した後、サーバは、セッション要求メッセージの中で伝達された警告情報を解析することにより、端末がブートストラップまたは再ブートストラップされたことを認知し、次に、端末要求を認証するためサーバ側で記憶されたブートストラップ情報の中のパスワードを獲得する。その後の管理において、サーバは端末によって記憶されたパスワードを更新することができる。
【００５１】
安全性のため（たとえば、悪質なサーバがセッション要求メッセージを傍受し、リプレイ攻撃を始める問題を防止するため）、端末によって送信されたセッション要求メッセージを認証した後、サーバは端末への認証チャレンジをさらに開始することができる。チャレンジは、サーバによって生成された新しいノンスを伝達する。サーバによって送信されたチャレンジメッセージを受信した後、端末は新しいノンスを使用して新しい認証情報を生成し、認証情報をサーバへ送信する。サーバは端末を再び認証する。認証が成功した後、サーバは他の管理オペレーションを実行することができ、たとえば、サーバパスワードを更新することができる。
【００５２】
再ブートストラップは、ある一定の条件（たとえば、携帯電話機カードが新しい携帯電話機に挿入される）において端末機器によって自動的にトリガされ、または、端末ユーザインターフェイス（ＵＩ）を介してユーザによってトリガされることが可能である。
【００５３】
２． ＳｍａｒｔＣａｒｄ上のブートストラップ情報が端末によって更新可能である場合、ブートストラップ方法は以下の通りである。端末は、端末のＤＭツリーのＤＭＡｃｃ ＭＯに記憶されたユーザ名、パスワードまたはノンスを更新するため、サーバのＤＭコマンドを受信する。更新が成功した後、端末は、ＳｍａｒｔＣａｒｄオペレーションコマンドを通じて自動的にＳｍａｒｔＣａｒｄにおけるブートストラップファイルの中の対応するユーザ名、パスワードまたはノンス情報を更新する。上記処理後の２つの状況は以下の通りである。
【００５４】
１） ブートストラップファイルの更新が、ブートストラップファイルの中で伝達されるユーザ名、パスワード、およびノンスが、サーバによって記憶されたユーザ名、パスワード、およびノンスと整合していることを保証できる場合、その後のブートストラップは更新済みのブートストラップファイルを用いて実行され、そして、ブートストラップ後に、サーバに通知する必要がない（すなわち、ブートストラップ事象をサーバへ報告する専用セッションが必要とされない）。
【００５５】
２） ブートストラップファイルの更新が、ブートストラップファイルの中で伝達されるユーザ名、パスワード、およびノンスが、サーバによって記憶されたユーザ名、パスワード、およびノンスと整合していることを保証できない場合、ユーザ名、パスワード、またはノンスのようなアカウントデータの更新を効率的に制御し、サーバと端末との間の同期を容易に行うために、ブートストラップファイルが更新された後に、更新情報が更新済みのブートストラップファイルの中に記録される。更新情報はバージョンフィールドを追加することにより記録されることができる。さらに、セッションがブートストラップの後にブートストラップファイルを使用することにより初めて確立されるとき、記録された更新情報がセッション要求メッセージの中で報告される。サーバは更新に従って処理を実行する。
【００５６】
ブートストラップは複数のモードを含む。しかし、これまでのところ、ブートストラップによって生成された機器管理ツリーのＤＭＡｃｃ ＭＯの中の情報は、アカウントが生成されたブートストラップモードに関する記録を含まない。したがって、サーバは、ブートストラップモードを通じてブートストラップの安全性レベルを判断することができず、すべての端末について採用されたブートストラップ方法の統計を取ることができない。本開示の第２の実施形態では、上記課題を解決する方法が以下の通り記載される。サーバが端末のブートストラップのソースを取得することができるよう、本実施形態では、端末がブートストラップされるモード、すなわち、ブートストラップタイプを記憶するため、管理ノード（たとえば、図３における「ブートストラップタイプ」）が端末ＤＭツリーのＤＭＡｃｃ ＭＯに追加される。具体的な実施形態は図３に示されている通りである。ブートストラップタイプの値は、表１に示されているように整数でもよい。
【００５７】
【表１】
【００５８】
端末のブートストラップが成功した後、ブートストラップモードは管理ノードの中に記憶される。サーバは端末の中のアカウントに対応するブートストラップモードを獲得するために管理セッションを介してＧｅｔコマンドを管理モードへ配信する。サーバの権限を認証した後、端末は管理ノード値を返送する。
【００５９】
第３の実施形態では、本開示は、端末が複数のＤＭＡｃｃを生成するため数回に亘って同じＳｅｒｖｅｒＩＤアカウントでブートストラップを実行する状況を回避するように、ブートストラップ情報を処理する方法について記載する。具体的なブートストラップ方法は以下のステップを含む。
【００６０】
１． 端末の管理ツリーは、以下の通り、ＳｅｒｖｅｒＩＤに対応するＤＭＡｃｃ ＭＯが既に存在するかどうかを判定するため検索される。現在構成されるべきサーバアカウントに対応するＳｅｒｖｅｒＩＤが装置管理ツリーの中のＤＭＡｃｃ ＭＯのＳｅｒｖｅｒＩＤノードの値と同じであるかどうかが比較され、一方、現在構成されるべきサーバアカウントに対応するＳｅｒｖｅｒＩＤが装置管理ツリーの中のＤＭＡｃｃ ＭＯのＳｅｒｖｅｒＩＤノードの値と同じである場合、対応するアカウント情報が存在し、現在構成されるべきサーバアカウントに対応するＳｅｒｖｅｒＩＤが装置管理ツリーの中のＤＭＡｃｃ ＭＯのＳｅｒｖｅｒＩＤノードの値と同じでない場合、対応するアカウント情報が存在しない。ＳｅｒｖｅｒＩＤに対応するＤＭＡｃｃ ＭＯが端末の管理ツリーの中に見つけられる場合、ステップ２が実行され、ＳｅｒｖｅｒＩＤに対応するＤＭＡｃｃ ＭＯが端末の管理ツリーの中で見つからない場合、ステップ３が実行される。
【００６１】
２． ブートストラップオペレーションが反復ブートストラップまたは再ブートストラップであるかどうかが判定される（たとえば、ユーザの確認情報を通じて複数のモードで判定されることがある）。ブートストラップオペレーションが反復ブートストラップである場合、ブートストラップオペレーションはキャンセルされる。ブートストラップオペレーションが再ブートストラップである場合、機器管理ツリー上の対応するＤＭＡｃｃ ＭＯの中の管理ノード上のデータが直接的にリフレッシュされる。
【００６２】
３． ブートストラップ情報の中のカウント情報が端末ＤＭツリーの中のＤＭＡｃｃ ＭＯに変換され、アクセス制御リスト（ＡＣＬ）がＤＭＡｃｃ ＭＯについて分配される。
【００６３】
前述の第１の実施形態では、ユーザが再ブートストラップされた（たとえば、機器が交換された）後に端末がブートストラップされたかどうかをサーバが認知できず、それゆえ、先行するユーザの端末情報の影響の下で通常の管理が失敗する可能性があるという課題を効果的に解決するブートストラップ方法が図示されている。第２の実施形態では、サーバが端末のブートストラップモードを取得していない可能性があり、そして、ブートストラップモードに従ってブートストラップの安全性レベルを判断できないことがあるという課題が解決される。第３の実施形態では、同じＳｅｒｖｅｒＩＤが数回に亘ってブートストラップされたとき、同じＳｅｒｖｅｒＩＤに対応する複数のＤＭＡｃｃ ＭＯがブートストラップ競合に起因して端末ＤＭツリーの中に存在する状況を回避し、反復ブートストラップによって引き起こされるアカウント管理の混乱を回避するように、処理方法が提供される。
【００６４】
本開示におけるその後の管理セッションの改良点は以下の通り詳細に明らかにされる。
【００６５】
ＩＩ． 管理セッション
【００６６】
ブートストラップが端末上で成功した後、管理セッションがサーバと端末との間に確立されることが可能であり、管理メッセージがセッションの中で交換されることが可能である。このセッションは、セッション確立段階と管理段階とを含む。セッション確立段階では、同一性が相互に認証され、同時に、端末が、ＤｅｖＩｎｆｏ ＭＯに記憶された端末基本情報を報告する。管理段階では、サーバが、管理アクションを端末へ配信するように、端末の管理ツリー上のＭＯへ保守オペレーションを配送する。機器管理ツリーの管理ノードは、管理ノードのためのサーバのオペレーション権限を制御するためにＡＣＬを有する。
【００６７】
１． サーバが端末機器による管理ツリーへの制限または端末による管理ツリーの実施状況を知ることができるよう、機器記述フレームワーク（ＤＤＦ）が、機器を記述するために採用される。サーバが機器を理解し管理を実行することが必要であるとき、まず、ＤＤＦに従って端末を管理するように機器のＤＤＦが獲得される。しかし、既存のプロトコルでは、サーバ側は端末機器を介して対応するＤＤＦを見つけられない可能性があり、サーバがＤＤＦを獲得することがより困難である。
【００６８】
本開示の実施形態においてＤＤＦを獲得する方法は図４に示される通りであり、以下のステップを含む。
【００６９】
ＤＤＦのユニフォーム・リソース・ロケータ（ＵＲＬ）は端末の管理ツリーに記憶される。
【００７０】
サーバはＵＲＬを通じて端末のＤＤＦを獲得する。
【００７１】
サーバ側によるＤＤＦの獲得を容易に実現するため、ＤＤＦのＵＲＬは、サーバがＵＲＬを通じて端末のＤＤＦを獲得するように、または、ＤＤＦデータが端末の管理ツリーにさらに記憶されるように、端末の管理ツリーに記憶されることがある。このようにして、サーバは、図４の実施形態に限定されることなく、端末から直接的にＤＤＦ情報を獲得することがある。具体的な実例は次の通りである。
【００７２】
端末がＤＤＦのＵＲＬを記憶する実施方法は以下の通りである。管理ノードは端末のＤＭツリーの中に追加され、端末のＤＤＦのＵＲＬは追加された管理ノードの中に記憶される（複数のＤＤＦが存在する可能があり、複数のノードがＵＲＬを記憶するため使用されない可能性がある）。好ましくは、上記記憶アクションは機器の配信の前に達成され、機器の使用中に記憶アクションは実際の状況に従って更新されることがある（たとえば、機器製造業者がＤＤＦの記憶アドレスを更新する）。追加された管理ノードは、既存のＤｅｖＩｎｆｏ ＭＯまたは機器詳細情報（ＤｅｖＤｅｔａｉｌ）ＭＯの中に記憶されてもよく、または、ＭＯとして別々に存在してもよい。ノード特性は表２に示されている通りである。
【００７３】
【表２】
【００７４】
端末がＤＤＦのＵＲＬを記憶し、そして、管理サーバがＤＤＦを獲得し使用する２つの方法は以下の通りである。
【００７５】
第１の方法では、端末は、最初に、ＤＤＦ管理ノードの値または管理ノードの位置を報告する。具体的な方法は以下の通りである。端末は以下の機会に報告する。
【００７６】
第１の機会では、ある一定のサーバアカウントが端末のため構成された後（たとえば、ブートストラップ後）、端末はサーバへの登録セッション（端末とサーバとの間の第１のセッション）を開始する。このセッションでは、ＤＤＦ管理ノードの値またはＤＤＦ管理ノードの位置が報告される。その後の管理セッションでは、ＤＤＦ管理ノードの値およびＤＤＦ管理ノードの位置は、サーバがそれらを再獲得するためにＧｅｔコマンドを配信しない限り、最初に報告されない（方法２を参照のこと）。好ましくは、管理セッションのセッション要求メッセージは、ＤＤＦ管理ノードの値またはＤＤＦ管理ノードの位置を伝達する。
【００７７】
第２の機会では、端末は、各管理セッションのセッション要求メッセージの中でＤｅｖＩｎｆｏと一緒にＤＤＦ管理ノードの値またはＤＤＦ管理ノードの位置を報告する。
【００７８】
ＤＤＦ管理ノードを記憶する位置が報告される場合、いずれかのその後の管理セッションにおいて、サーバは、ＤＤＦ管理ノードを記憶する位置に従ってＤＤＦ管理ノードの値を獲得する（ＤＤＦ管理ノードの値はＤＤＦのＵＲＬ情報である）。
【００７９】
サーバがＤＤＦのＵＲＬ情報を受信した後、ＤＤＦが必要とされるとき（たとえば、端末の詳細な管理または構成が実施される前）、具体的なＤＤＦ情報がＵＲＬに従って獲得され、端末はＤＤＦに従って生成された管理コマンドに従って管理される。
【００８０】
第２の方法では、サーバはサーバと端末との間で確立された管理セッションにおいて最初にＤＤＦ情報を獲得する。具体的なプロセスは図５に示されている通りであり、具体的なステップは以下の通り明らかにされる。
【００８１】
ステップ１では、ＤＭサーバは、管理プロセスにおいて端末からＤＤＦ管理ノードに記憶されたＵＲＬを獲得する。具体的な方法は以下の通りである。
【００８２】
端末はサーバの命令情報を受信する。命令情報は、サーバによって送信された通知メッセージ（セッション・トリガ・メッセージ）の中で伝達される。命令情報は、端末に、ＤＤＦ管理ノードに記憶された端末ＤＭツリーのＤＤＦのＵＲＬまたは端末によってサポートされたある一定のＭＯのＤＤＦのＵＲＬを報告するよう命令する。その後に、端末は通知の中の情報に従って管理セッションを開始するセッション要求メッセージを生成する。ＵＲＬはセッション要求メッセージの中で報告される。具体的なレポート方法は以下の通りである。警告タイプは端末のために拡張される。ＡｌｅｒｔコマンドはタイプおよびＵＲＬを伝達する。タイプがＭＯのＤＤＦである場合、ＭＯＩＤがさらに伝達されることがある。サーバは警告タイプおよびＭＯＩＤに従ってＵＲＬを特定する。
【００８３】
代替的に、ノードはＤｅｖＤｅｔａｉｌ ＭＯまたは他のＭＯに記憶される。サーバは、確立された管理セッションの中でＧｅｔコマンドを通じてノードの値を獲得する。ＤｅｖＤｅｔａｉｌ ＭＯを一実施例として採用すると、サーバが、ノードと、端末ＤＭツリーの中でノードを記憶するＤｅｖＤｅｔａｉｌ ＭＯのパスとを知らない場合、ノードは以下の方法を通じて検索される。
【００８４】
サーバは端末ＤＭツリーの構造情報を獲得し、構造情報を直接的に分析することにより端末ＤＭツリーの中の管理ノードの位置を検索する。
【００８５】
代替的に、サーバは、以下の通り具体的に、最初に管理ノードのＭＯ（ここでは、ＤｅｖＤｅｔａｉｌ）の位置を獲得する。サーバはＧｅｔコマンドを通じてＤｅｖＤｅｔａｉｌ ＭＯの位置を検索するか、または、ＤｅｖＤｅｔａｉｌの位置情報を端末のＤｅｖＩｎｆｏに記憶する。端末は、（最初のＤＭセッションの中で報告されるか、１回報告されるか、または、各セッションで報告されることがある）セッション要求メッセージの中でＤｅｖＩｎｆｏと一緒にＤｅｖＤｅｔａｉｌ ＭＯの位置（ルート・ノード・パス）をサーバへ報告する。サーバは、ＤｅｖＤｅｔａｉｌの位置およびＤｅｖＤｅｔａｉｌ ＭＯの構造情報（機器管理ツリーの中で獲得されたＤｅｖＤｅｔａｉｌ ＭＯルートノードのパスと、ＤｅｖＤｅｔａｉｌ構造の中のＤｅｖＤｅｔａｉｌルートノードと相対的なＤＤＦ管理ノードの相対パスとを接続することにより形成されたＤＤＦ管理ノードのパス）に従ってＤＤＦ管理ノードの位置を検索する。
【００８６】
ＤＤＦ管理ノードの位置が検索された後、ＧｅｔコマンドがＤＤＦ管理ノードの値を獲得するため配信される。
【００８７】
ステップ２では、端末は、記憶しているＤＤＦのアドレスをＤＭサーバへ返送する。具体的な方法は以下の通りである。ノードがＤｅｖＩｎｆｏ ＭＯに記憶されている場合、端末はセッション要求メッセージの中でアドレスを伝達する。ノードがＤｅｖＤｅｔａｉｌ ＭＯの中に記憶されている場合、端末はサーバによって送信された問い合わせコマンドの結果（リザルト）メッセージの中でＤＤＦアドレスを返送する。
【００８８】
ステップ３では、ＤＭサーバは、ＤＤＦを獲得するため、獲得されたＤＤＦ記憶アドレスに対応するリモートＤＤＦ記憶サーバと通信する。
【００８９】
ステップ４では、リモートＤＤＦ記憶サーバはＤＤＦ記述ファイルをＤＭサーバへ返送する。
【００９０】
ステップ５〜７では、ＤＭサーバは、その後の管理のための基準としてＤＤＦを使用することにより管理アクションを生成し、端末を管理し、端末は実行結果を返送する。
【００９１】
ＤＤＦのその後の獲得のコストを削減するため、ＤＭサーバは獲得されたＤＤＦデータをローカルに一時的に記憶することができる。
【００９２】
端末がＤＤＦを記憶する実施方法は以下の通りである。管理ノードは端末のＤＭツリーの中に追加される。管理ノードは端末ＤＭツリーの中のある一定のＭＯに追加され、ＤＤＦの内容はノードの中に記憶される。値は、機器配信前にノードに割り当てられることがある。機器の使用中に、ＤＭクライアントは実際の状況に従って更新を実行する。好ましくは、ノードはＤｅｖＤｅｔａｉｌ ＭＯに追加される。ノード特性は表３に示されている通りである。
【００９３】
【表３】
【００９４】
この方法では、サーバは管理プロセスにおいてＤＤＦの内容であるノードの値を獲得する。具体的に、４つの方法が、ノードの値がＤｅｖＤｅｔａｉｌに記憶される実施例を採用することにより、以下の通り例示されている。
【００９５】
第１の方法では、サーバは、以下の通り具体的に、ＤＤＦを獲得するために直接的にＤＤＦの管理ノードの位置を検索する。サーバは、Ｇｅｔコマンドを配信することにより機器管理ツリーの構造をまず獲得し、機器管理ツリーの構造を通じて直接的に管理ノードを検索する。代替的に、端末は、（最初のＤＭセッションで報告されるか、１回だけ報告されるか、または、各セッションの中で報告される）セッション要求メッセージの中で管理ノードの位置をまず報告する。その後、サーバは管理ノードの値（すなわち、ＤＤＦ）を獲得するためコマンドを配信し、値はその後の管理のための基礎として使用される。
【００９６】
第２の方法では、サーバは機器管理ツリーの中のＤｅｖＤｅｔａｉｌの位置をまず獲得し、以下の通り具体的に、ＤＤＦを獲得するようにＤＤＦ管理ノードの位置を間接的に検索する。サーバは、ＤＤＦ管理ノードのＭＯ（ここではＤｅｖＤｅｔａｉｌ）の位置をまず獲得する。サーバは、Ｇｅｔコマンドを配信することにより機器管理ツリーの中のＤｅｖＤｅｔａｉｌ ＭＯの位置を検索するか、または、ＤｅｖＤｅｔａｉｌの位置情報を端末のＤｅｖＩｎｆｏに記憶する。端末は、セッション要求メッセージの中で、（最初のＤＭセッションの中で報告されるか、１回だけ報告されるか、または、各セッションで報告されることがある）ＤｅｖＤｅｔａｉｌ ＭＯの位置（ルート・ノード・パス）をサーバへまず報告する。その後、サーバは、Ｇｅｔコマンドを配信することによって、値（すなわち、ＤＤＦ）を獲得するように、ＤｅｖＤｅｔａｉｌ ＭＯの位置情報および構造を通じてＤＤＦ管理ノードの位置を検索する。ＤＤＦはその後の管理のための基礎として使用される。
【００９７】
第３の方法では、ある一定のサーバアカウントが端末のため構成された後（たとえば、ブートストラップ後）、端末は最初にサーバへの登録セッション（端末とサーバとの間の最初のセッション）を開始する。ＤＤＦはこのセッションにおいて報告される。その後の管理セッションにおいて、ＤＤＦは、サーバが再獲得のためのＧｅｔコマンドを配信しない限り、最初に報告されない。
【００９８】
第４の方法では、端末はサーバの命令情報を受信する。命令情報はサーバによって送信された通知メッセージの中で伝達される。命令情報は、端末にＤＤＦ管理ノードに記憶された端末ＤＭツリーのＤＤＦまたは端末によってサポートされたある一定のＭＯのＤＤＦを報告するよう命令する。その後、端末は、通知の中の情報に従って管理セッションを開始するセッション要求メッセージを生成する。ＤＤＦはセッション要求メッセージの中で伝達され、具体的な実行方法は以下の通りである。警告タイプは端末のため拡張される。警告タイプおよびＤＤＦはＡｌｅｒｔコマンドの中で伝達される。警告タイプがＭＯのＤＤＦである場合、ＭＯＩＤがさらに伝達されることができる。サーバは警告タイプおよびＭＯＩＤに従ってＤＤＦを特定する。
【００９９】
ＤＤＦを獲得する２つの方法が、サーバに対応するＤＤＦをサーバが見つけられない可能性があるという従来技術の課題を解決することができる。特に、ＤＤＦは比較的安定した情報であり、情報は大量であるので、頻繁なレポートはサーバおよびネットワーク伝送に負荷を引き起こす。これらの方法では、必要に応じて、サーバの情報を検索して獲得する能力を提供するように、端末が最初にある一定の条件下でＤＤＦを報告するか、または、サーバが最初にノードを検索してＤＤＦを獲得し、その結果、ネットワークおよびサーバへの負荷は、ＤＤＦを獲得する能力が提供されたままで、最大限に低減される。
【０１００】
２． 管理セッションはサーバと端末との間に確立可能であり、このことはサーバが端末のＤＭツリーへのオペレーションだけを実行可能であることを意味するに過ぎない。しかし、いくつかの機能は、ＳＣＯＭＯのような、具体的なＭＯ、および、端末上の（ＤＭアプリケーションと呼ばれる）クライアントプログラムに依存する必要がある。種々の端末が種々のＤＭアプリケーションをサポートし、これは、具体的なクライアントがその後の使用プロセスにおいて設置された後で配信または能力がサポートされる前は、異なる実施であってもよい。端末がある一定のＤＭアプリケーションをサポートするかどうかは、ＤＭアプリケーション機能が達成可能であるかどうかの根拠となる。したがって、端末はサーバにサポートされているＤＭアプリケーションを通知することが必要である。サーバ管理の困難さは、端末によってサポートされているＤＭアプリケーション（すなわち、ＭＯタイプ）をサーバが見分けられないために増大するという従来技術の課題を解決するため、本実施形態では、管理ノードが端末によってサポートされているＤＭアプリケーションを記録するために端末の管理ツリーに追加される。各ノードは端末によってサポートされるＤＭアプリケーションを記憶する。
【０１０１】
図６を参照すると、本実施形態では、追加された管理ノードは、内部ノードおよびそのサブノードを含むように設計されることがある。たとえば、「ＳｕｐｐｏｒｔｅｄＡｐｐ」ノードは、ＤｅｖＩｎｆｏまたはＤｅｖＤｅｔａｉｌ ＭＯの中のノードでもよい内部ノードとして設定される。内部ノードのサブノード「ｘ＊」は、リーフノードであり、複数のインスタンスを有してもよい。各インスタンスはＤＭアプリケーションに対応する。端末は、このノードを端末の実際の条件に従って維持する。たとえば、ある一定のＤＭアプリケーションが端末に追加される場合、端末はＳｕｐｐｏｒｔｅｄＡｐｐノードの中にリーフノードを追加し、ＤＭアプリケーションの情報を記憶する。各ＭＯは対応するＭＯＩＤを有するので、たとえば、ファームウェアＭＯのＭＯＩＤは“ｕｒｎ：ｏｍａ：ｍｏ：ｏｍａ−ｆｕｍｏ：１．０”であり、サポート対象ＭＯのＭＯＩＤはノードに記憶され、すなわち、．．．／ＳｕｐｐｏｒｔｅｄＡｐｐ／＜ｘ＞ノードの値はＭＯＩＤである。
【０１０２】
ＤＭアプリケーションに関して、端末がＤＭアプリケーションをサポートする限り、管理ツリーの中に存在するＤＭアプリケーションの個数（０または１または複数）とは無関係に、ＤＭアプリケーションに関して１個のＭＯＩＤだけがサポート対象ノードの下で追加される。管理プロセスでは、端末によってサポートされたＤＭアプリケーションを獲得するステップは以下の通りである。
【０１０３】
ステップＡでは、サーバは、端末によってサポートされたＤＭアプリケーションが獲得されるべきであることを判定する。
【０１０４】
ステップＢでは、サーバはサブノードとサブノードの値とを獲得するためにＧｅｔコマンドを端末のＤＭツリーのＳｕｐｐｏｒｔｅｄＡｐｐノードへ送信し、端末は対応する結果を返送する。
【０１０５】
ステップＣでは、サーバは、端末によってサポートされたＤＭアプリケーションを判定するために取得されたノード値（ＭＯＩＤ）を分析する。
【０１０６】
本実施形態における方法は、サーバが端末によってサポートされたＤＭアプリケーションを認知しないという課題を解決することができ、この方法では、具体的な管理オペレーションは、サーバの管理をより柔軟かつ効率的にするため配信される。
【０１０７】
３． 管理プロセスでは、サーバは、具体的な管理機能を実施するためにＭＯの中のノードに対しオペレーションを実行するように端末のＭＯを検索する必要がある。従来技術では、サーバが端末の管理ノードを検索することは非常に困難であり、エアリソースが消費され、サーバは大きな負荷を受ける。本開示では、サーバが端末のＤＭツリーの中でＭＯを検索する効率を改良するため、ＭＯルートノードの位置を検索する方法が提供される。図７に示されているように、この方法は以下のステップを含む。
【０１０８】
サーバはＧｅｔコマンドを端末へ送信する。Ｇｅｔコマンドは、獲得されるべきターゲット・オペレーション・パスの情報と値フィルタリング情報とを伝達する。
【０１０９】
サーバのＧｅｔコマンドを受信した後、端末は、Ｇｅｔコマンドに対応した、指定されたサブツリーの構造情報およびノードの特性情報を獲得するよう命令される。特性値および構造情報はサーバへ返送される。
【０１１０】
図７は、ＭＯアドレス検索の実施形態だけを示している。具体的に、サーバは、Ｇｅｔコマンドを端末へさらに送信することができ、Ｇｅｔコマンドは、検索されるべきＭＯのＩＤを伝達し、検索されるべきサブツリーのルートノードのユニフォーム・リソース識別子（ＵＲＩ）および検索を命令するパラメータを伝達する。パラメータは端末に機器管理ツリーの中のＭＯのＩＤをＭＯのルートノードのＵＲＩへ返送するよう命令する。
【０１１１】
Ｇｅｔコマンドの受信後、端末は、ＵＲＩ命令ノードとすべての内部サブノードの中でＩＤを満たすノードとを検索し、対応する結果をサーバへ返送する。
【０１１２】
本実施形態では、ＭＯアドレス検索は以下の３つのモードで具体的に実施される。
【０１１３】
第１の方法では、管理ツリー構造が返送されるときに同時に特性値が伝達され、具体的には以下の通りであることができる。
【０１１４】
サーバはＧｅｔコマンドを端末へ送信する。端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報はＧｅｔコマンドの“Ｔａｒｇｅｔ／ＬｏｃＵＲＩ”要素で伝達される。同時に、獲得されるべき値フィルタリング情報が伝達される。値フィルタリング情報は、端末に、機器管理ツリーの中でルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報と、サブツリーの中の各ノードの指定された特性の特性値とを返送するよう命令する。
【０１１５】
伝達されるフィルタ情報のフォーマットは、＜ＵＲＩ＞？ｌｉｓｔ＝Ｓｔｒｕｃｔ＋＜ｐｒｏｐｅｒｔｙ＿ｎａｍｅ＞であってもよい。複合パラメータ中の「Ｓｔｒｕｃｔ」は、端末に、機器管理ツリーの中でＵＲＩによって指示されたノードおよびこのノードのサブノードの構造情報を返送するよう命令する。構造は、端末によって返送されたノードの（“ＬｏｃＵＲＩ”の中で伝達される）ＵＲＩによって表現される。複合パラメータの中の＜ｐｒｏｐｅｒｔｙ＿ｎａｍｅ＞は、ある一定のノードの特性名であり、端末に、ＵＲＩによって指示されたノードおよびこのノードのサブノードの特性の特性値を返送するよう命令する。特性は、ノードタイプ特性、ノードＡＣＬ特性、ノード値フォーマット特性、ノードタイトル特性、ノード値サイズ特性、ノード変更タイムスタンプ（ＴＳｔａｍｐ）特性、または、ノードバージョン番号（ＶｅｒＮｏ）特性のような端末によってサポートされるいかなる特性であってもよい。使用例は以下の通りである。
【０１１６】
【数３】
【０１１７】
サーバのＧｅｔコマンドの受信後、端末は、Ｇｅｔコマンドに従って指定サブツリーの構造情報およびノードの特性情報を獲得するよう命令され（獲得中に、サーバが管理ノードのＡＣＬ権限、ここでは、具体的に取得権限（Ｇｅｔ ｒｉｇｈｔ）を有するかどうかが認証される）、次に、構造情報と共に特性値をサーバへ返送する。
【０１１８】
特性情報は、Ｇｅｔコマンドに対応する「Ｒｅｓｕｌｔ」コマンドの中で伝達される（異なるノードはＲｅｓｕｌｔ要素の中の異なるＩｔｅｍサブ要素の中に分配されるか、または、それぞれが単一のＩｔｅｍを含む異なるＲｅｓｕｌｔ要素に分配されることがある）。具体的な特性値は、Ｒｅｓｕｌｔ／Ｉｔｅｍ／Ｄａｔａ要素の中で伝達され、返送されることができる。「Ｒｅｓｕｌｔ」コマンドの中の“Ｓｏｕｒｃｅ／ＬｏｃＵＲＩ”要素は、ノードＵＲＩと、特性名を指示するパラメータとを伝達する。その複合は、ＵＲＩ？ｐｒｏｐ＝＜ｐｒｏｅｒｔｙ＿ｎａｍｅ＞である。コマンドの受信後、サーバは、ノードＵＲＩに従って機器管理ツリーの指定された部分の構造を分析し、？ｐｒｏｐ＝＜ｐｒｏｅｒｔｙ＿ｎａｍｅ＞部分からＤａｔａの中で伝達される特性値に対応する特性名を取得し、データ要素から特性値を獲得する。用法は以下の通りである。
【０１１９】
【数４】
【０１２０】
機器管理ツリーの中のＭＯのＭＯＩＤはＭＯルートノードのタイプ特性に記憶されるので、複合パラメータの＜ｐｒｏｐｅｒｔｙ＿ｎａｍｅ＞は、タイプ特性に設定され、サブツリー構造が返送されるときと同時に、サブツリーの中のすべてのＭＯＩＤを返送する。具体的に、サーバは、サブツリーの中の各ノードのタイプ特性の値を獲得した後に判定を行う。ノードが内部ノードであり、タイプ特性の値が空でない場合、ノードは、返送された情報からＭＯのルートノードのＵＲＩを獲得するため、ＭＯのルートノードであり且つ空でないタイプ特性の値はＭＯＩＤであると判定される。ＭＯのＵＲＩの獲得後、サーバは、ＭＯの中のノードのより詳細な情報を獲得するためＧｅｔコマンドを送信するか、または、管理コマンドを直接的に送信する。
【０１２１】
この方法は、サーバが、非直列化モードにおいて一括して機器管理ツリーの中のある一定の管理サブツリーの中のすべての管理ノードのうちのある一定の特性値を獲得しない可能性がある、という課題を解決することができる。この方法を通じて、ある一定の特性値は、サブツリー構造が獲得されたときに同時に獲得されることができるので、特性獲得のための相互作用は減少され、効率が増大される。同時に、管理サブツリーの中のすべてのＭＯは、特性値をタイプとして指定することにより獲得されることができるので、管理サブツリーの中のすべてのＭＯが効率的に獲得できない可能性がある、という課題が解決される。
【０１２２】
第２の方法では、端末は、具体的なＭＯのルートノードを検索し、ルートノードのＵＲＩを返送する。具体的な実施形態は以下の事項を含む。
【０１２３】
サーバはＧｅｔコマンドを端末へ送信する。検索されるべきＭＯの識別子（ＭＯＩＤ）はＧｅｔコマンドにおいてＩｔｅｍ／Ｄａｔａ要素の中で伝達される。ＭＯＩＤが検索されるサブツリーのルートノードのＵＲＩと、検索を命令するパラメータとが、Ｉｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩ要素の中で伝達される。パラメータは、端末に、Ｉｔｅｍ／Ｔａｅｇｅｔ／ＬｏｃＵＲＩ要素によって提示された機器管理ツリーのサブツリーのＩｔｅｍ／Ｄａｔａ要素の中で伝達されるＭＯＩＤにより識別されるＭＯの出現するルートノードのＵＲＩを検索するよう命令する。サブツリーのルートノードのＵＲＩと検索を命令するパラメータとを伝達する情報のフォーマットは、ＵＲＩ？ｌｉｓｔ＝ＭＯ＿ＲＯＯＴでもよい。メッセージはＤＭメッセージの中で伝達される。コマンドの具体的な実施例は以下の通りである。
【０１２４】
【数５】
【０１２５】
コマンドの受信後、端末は、サーバがＡＣＬ権限（ここでは、Ｇｅｔ権限）を有し、ノードがコマンドの中のルートノードＵＲＩとそのサブノードとに対応する場合に、ノードにおいてＤａｔａ要素の中で伝達されるＭＯＩＤの値をもつＴｙｐｅ特性を有するすべてのノードを検索し、結果（すなわち、検索されたノードのＵＲＩ）をサーバへ返送する。検索プロセスは、内部ノードだけで実行され（すなわち、フォーマット特性はノードである）、リーフノードのためには実行されない。代替的に、端末は、＜ＭＯルートノード、ＭＯＩ＞記憶マッピング表を記憶する。サーバからのＧｅｔコマンドが受信された後、ＭＯ位置はマッピング表から即座に獲得され、結果がサーバへ返送される。結果を返送する方法は以下のステップを含む。
【０１２６】
１） 検索条件を満たす１個以上のノードが見つけられる場合、Ｇｅｔコマンドのステータスの後、すべての検索結果（すなわち、ＭＯの出現するルートノードＵＲＩ）がＲｅｓｕｌｔコマンドを通じて返送される。異なるノードがＲｅｓｕｌｔ要素の中の複数のＩｔｅｍ要素の中に分配されてもよく、または、各々が単一のＩｔｅｍを含む異なる結果の中に分配されてもよい。結果は、ＭＯＩＤを伝達してもよく、ＭＯＩＤを伝達しなくてもよい。
【０１２７】
ＭＯＩＤを伝達する結果を返送する方法は以下の通りである。結果のＩｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩは、端末によって検索されたノードのＵＲＩを伝達し、同時に、タイプ特性：？ｐｒｏｐ＝Ｔｙｐｅを含むパラメータを伝達し、ＭＯＩＤがＩｔｅｍ／Ｄａｔａの中で伝達される。ＭＯＩＤを伝達する結果を返送する方法は、対応するＧｅｔコマンドの中のＩｔｅｍの個数を制限することがなく、すなわち、サーバは、Ｇｅｔコマンドの中で端末から複数のＭＯＩＤに対応するＭＯの出現するルートノードＵＲＩを検索するため、同じＧｅｔコマンドの中で複数のＩｔｅｍを伝達することがある。具体的な使用例は以下の通りである。
【０１２８】
【数６】
【０１２９】
ＭＯＩＤを伝達しない結果の返送方法は以下の通りである。端末によって見つけられたノードのＵＲＩだけが、結果のＩｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＩの中で伝達される。ＭＯＩＤを伝達しない結果の返送方法は、結果に対応するＧｅｔコマンドが１個のＩｔｅｍだけを伝達すること、すなわち、サーバがＧｅｔコマンドの中の端末から１個のＭＯＩＤに対応するＭＯの出現するルートノードＵＲＩを検索することを要求する。複数のＩｔｅｍが伝達される場合、サーバは返送された結果に対応するＩｔｅｍを識別することができない。使用例は以下の通りである。
【０１３０】
【数７】
【０１３１】
ＭＯのＵＲＩを獲得した後、サーバは、ＭＯの中のノードのより詳細な情報を獲得するためＧｅｔコマンドを送信するか、または、管理コマンドを直接的に送信することがある。
【０１３２】
２） 条件を満たすノードが見つからない場合（たとえば、Ｇｅｔコマンドの中のターゲットＵＲＩがリーフノードを参照するか、または、Ｇｅｔコマンドの中のターゲットＵＲＩが内部ノードを参照するとしても、ターゲットＵＲＩにルートがあるサブツリーの中のＭＯＩＤによって識別されたＭＯが発生しない場合）、結果は返送されず、「４０４ Ｎｏｔ Ｆｏｕｎｄ」がＧｅｔコマンドに対応する「Ｓｔａｔｕｓ」コマンドの中で返送される。
【０１３３】
端末が具体的なＭＯのルートノードを検索し、ルートノードのＵＲＩを返送する第２の方法では、具体的なＭＯＩＤは指定されない可能性があり、すなわち、ＧｅｔコマンドのＩｔｅｍ要素はデータサブ要素を含まないことがある。コマンドを受信した後、端末は、ターゲットＵＲＩに対応するノードの下で、すべてのＭＯのＭＯＩＤとＭＯのルートノードＵＲＩとを検索し、結果を返送する。検索方法は以下の通りでもよい。ターゲットＵＲＩに対応するノードのすべての内部サブノードの中で、空でないタイプ特性値を有する（すなわち、ノードのＦｏｒｍａｔ特性値がノードである）すべてのノードが検索されるか、または、マッピング表が端末で維持される。サーバのＧｅｔコマンドを受信するとき、端末はマッピング表の中で直接的に検索を行う。結果を返送する方法は、ＭＯＩＤを伝達する結果を返送する方法と同じである。
【０１３４】
第３の方法では、端末に対応する管理ツリーはサーバ側で維持される。Ｒｅｐｌａｃｅ、Ｃｏｐｙ、ＤｅｌｅｔｅおよびＡｄｄのような機器管理ツリーによって送信された管理ツリーノードを変更するコマンドに従って、オペレーションが成功したとき、サーバはサーバによって記憶されている対応する管理ツリーを維持する。機器管理ツリーの構造が取得される必要があるとき、サーバは、ターゲット・オペレーション・ノードのＵＲＩを判定するため、サーバ側で維持されたターゲット・オペレーション端末サブツリーの構造をまず獲得し、管理コマンドを生成し、コマンドをターゲット・オペレーション端末へ配信する。
【０１３５】
本実施形態では、この方法は、サーバが、端末ＤＭツリーの中でＭＯの位置を検索することが困難であるという課題を解決する。サーバが端末ＤＭツリーの中でＭＯの位置を検索する作業は、サーバと端末との間で分担されるので、ＭＯを検索する複雑なロジックは端末によってローカルに達成され、このことは、サーバが端末ＤＭツリーの中でＭＯの位置を効果的に検索する効率を改良し、管理オペレーション中の相互作用を削減し、管理効率を改良し、サーバおよびネットワーク伝送への負荷を軽減する。
【０１３６】
４． 管理プロセスでは、サーバによって端末へ配信された管理コマンドは、同じ管理コマンドが端末の複数の管理ノードで動作する機能を達成するために、複数のＩｔｅｍを伝達することがある。たとえば、Ｒｅｐｌａｃｅの文法は、＜！ＥＬＥＭＥＮＴ Ｒｅｐｌａｃｅ（ＣｍｄＩＤ，ＮｏＲｅｓｐ？，Ｃｒｅｄ？，Ｍｅｔａ？，Ｉｔｅｍ＋）＞であり、すなわち、Ｒｅｐｌａｃｅコマンドは、端末に、複数の管理ツリーノードのためのＲｅｐｌａｃｅアクションを実行するよう命令するために、複数のＩｔｅｍを伝達する。ある場合には、複数のＩｔｅｍが端末で順次処理されるべきであり、ある場合には、非順次に処理されることがある。サーバは、端末に、管理コマンドの中の複数のＩｔｅｍを順次実行するように命令するため、実行が順次であるかどうかを判定する。
【０１３７】
図８の実施形態に示されているように、以下のステップを含むコマンドの実行モードを管理する方法が提供される。
【０１３８】
管理コマンドの中の複数のサブコマンドを順次実行する命令は、サーバによって送信された管理コマンドの中で伝達される。
【０１３９】
管理コマンドの受信後、端末は、順次実行の命令を解析し、管理コマンドの中の各サブアイテムに対応する管理ノードで管理コマンドアクションを順次実行する。
【０１４０】
具体的に、Ｉｔｅｍを順次実行する命令は、サーバによって端末へ配信される管理コマンドの中で伝達される。伝達方法は以下の通りである（Ｒｅｐｌａｃｅコマンドが実施例として採用され、他の管理コマンドの伝達方法はＲｅｐｌａｃｅコマンドに類似している）。
【０１４１】
特性はＩｔｅｍ要素の親要素の中で伝達される。特性は、サブ要素が順次実行されることを示す。管理コマンドのＲｅｐｌａｃｅを実施例として採用すると、Ｒｅｐｌａｃｅのための命令特性を定義するＤＴＤは、＜！ＡＴＴＬＩＳＴ Ｒｅｐｌａｃｅ ｏｒｄｅｒ（Ｓｅｑｕｅｎｃｅ｜Ａｎｙ）“Ａｎｙ”＞であってもよい。特性順序の値は以下の意味をもつ。“Ａｎｙ”は、端末の実行ノードが制限されないことを表現する。“Ｓｅｑｕｅｎｃｅ”は、端末が順次実行のため命令されることを表現する。特性が追加された後の実施例は以下の通りである。
【０１４２】
【数８】
【０１４３】
命令のサブ要素はＩｔｅｍ要素の親要素の中に追加され（要素はＩｔｅｍ要素の兄弟要素である）、サブ要素が追加された後のＤＴＤは、＜！ＥＬＥＭＮＴ Ｒｅｐｌａｃｅ（ＣｍｄＩＤ，ＮｏＲｅｓｐ？，Ｃｒｅｄ？，Ｍｅｔａ？，Ｏｒｄｅｒ？，Ｉｔｅｍ＋）＞として定義される。
【０１４４】
【数９】
【０１４５】
シェル要素（すなわち、管理コマンドのサブ要素、および、同時にＩｔｅｍの親要素）は、Ｉｔｅｍが順次実行されるため追加される。シェル要素は、シェルの中の要素が順次実行される必要がないことを端末に通知するだけである。
【０１４６】
端末がＲｅｐｌａｃｅコマンドの中で伝達されるアイテムを順次実行する命令を解析した後、Ｒｅｐｌａｃｅコマンドはアイテム命令ノードのため順次実行される。
【０１４７】
本実施形態における方法は、サーバが端末に管理コマンドの中の複数のターゲット・オペレーション・アイテムに対し管理コマンドを順次実行するよう命令しない可能性がある、という課題を解決することを目指し、この方法では、サーバは端末による管理コマンドの実行モードを柔軟に制御し、実行エラーの可能性を低下させることがある。
【０１４８】
５． ＤＭの管理アクションが実行される前に、管理セッションはまずサーバと端末との間に確立されることが必要である。すべての管理コマンドは管理セッションにおいて達成される。サーバまたは端末がアクションを処理するために長時間を要することがある。代替的に、管理アクションが近いうちに送信されるべきことが期待される。セッションを再確立するコストを削減するため、現在のセッションが維持されることがある。図９において実施形態に示されているように、以下のステップを含む管理セッションを維持する方法が提供される。
【０１４９】
セッション維持コマンドが管理セッションの中で反対端へ送信されるべきことが判定されるとき、サーバまたは端末は、セッション維持コマンドを伝達するメッセージを反対端へ送信する。
【０１５０】
メッセージの受信後、反対端は肯定応答メッセージを返送し、セッション維持コマンドに対応するオペレーションを実行する。
【０１５１】
本実施形態では、以下の通り具体的に、２つの維持方法がセッションのため設計される。
【０１５２】
セッション中の中断を回避するため、セッション維持コマンドが設計されることがある。セッション維持アクションが実行されるべきことが判定されるとき（たとえば、データ処理の所要時間が長いと判定されたとき）、サーバまたは端末は、“ＳｙｎｃＭＬ”メッセージを他の当事者へ送信する。メッセージはセッション維持コマンドを伝達し、他の当事者は肯定応答を用いて応答する。プロセスは、セッション維持コマンドの送信者が大量の管理コマンドを他の当事者へ送信するか、または、他の当事者にセッションを終了することを通知するまで、必要に応じて反復的に実行されることがある。セッション維持コマンドを伝達する“ＳｙｎｃＭＬ”メッセージが他の管理コマンドを含む場合、他の当事者はセッション維持コマンドを無視することができる。
【０１５３】
図１０において実施形態に示されているように、サーバがセッション維持コマンドを送信することを実施例として採用して、セッションを維持するプロセス（端末がセッション維持コマンドを送信するプロセスは類似しているので、その説明はここでは省略されている）が説明される。
【０１５４】
ステップ２１では、認証が端末およびサーバで実行され、管理セッションが端末とサーバとの間で確立される。
【０１５５】
ステップ２２では、ＤＭコマンドの相互作用が両当事者のために実行される。
【０１５６】
ステップ２３では、サーバは、受信した管理コマンドを処理し、内部データ処理を実行し、セッションが待機する。
【０１５７】
ステップ２４では、サーバが、（サーバ内部の処理所要時間がセッション中断またはタイムアウトを引き起こす場合）セッションは維持されるべきであると判定したとき、サーバはセッション維持コマンドを送信する。
【０１５８】
ステップ２５では、端末は、セッション維持コマンド肯定応答メッセージを送信し、両当事者はサーバ側が新しい管理メッセージを送信するまでセッションを維持する。管理メッセージは管理コマンドもしくはセッション維持コマンドを伝達するか、または、管理メッセージは管理コマンドを伝達しない空メッセージである。
【０１５９】
ステップ２６では、サーバは端末データの処理を終了し、処理結果に従って端末へ送信されるべき管理コマンドを生成する。
【０１６０】
具体的に、セッション維持コマンドはＡｌｅｒｔコマンドを使用してもよく、新しいタイプコード“Ａｌｅｒｔ Ｃｏｄｅ”はＡｌｅｒｔコマンドのため設計されてもよい。コードの意味は表４に示されている通りである。
【０１６１】
【表４】
【０１６２】
コマンドの具体的な使用例は以下の通りである。
【０１６３】
【数１０】
【０１６４】
セッション維持コマンドは他のデータ（たとえば、Ｉｔｅｍ）を伝達しないことがある。サーバによって送信されたセッション維持コマンドを受信した後、端末は大量の管理コマンドを実行することはなく、以下の通りの肯定応答メッセージがそのコマンドに対し返送される。
【０１６５】
【数１１】
【０１６６】
実施形態は、一方の当事者が、もう一方の当事者はセッションを維持するよう命令されるべきであると判定したとき、一方の当事者がセッション維持コマンドを反対端へ送信する課題を解決し、セッションの異常な中断を減少し、効率を改善する。
【０１６７】
端末機器の管理はクライアント／サーバ（Ｃ／Ｓ）モードに属している。サーバは、管理アクションが配信されるべきであるかどうかと、配信されるべき管理アクションと、を判定する。サーバは支配的な地位にある。したがって、ＤＭにおけるセッションの終了はサーバによって判定される。
【０１６８】
本開示の実施形態では、セッションを終了させる命令をするコマンドが設計される。コマンドはサーバによって端末へ送信される。コマンドは端末へ配信されるべきパケットの中に別々に収容されるか、または、サーバによって端末へ配信されるべき管理コマンドの最終的なグループと共にパッケージ化され、その後に、端末へ送信されてもよい。前者のモードでは、端末はコマンドを受信した後にセッションを正常に終了する。後者のモードでは、端末は、まずパケットの中の他の管理コマンドを実行し、実行が完了した直後にセッションを終了し、関連した管理コマンドの実行結果はサーバへ返送されない。端末は、サーバが必要に応じて結果を獲得するように、最終的なパケットの中に管理コマンドの実行結果を一時的に記憶することもある。セッションを終了させる命令をするコマンドはＡｌｅｒｔコマンドを通じて実施されてもよく、具体的なＣｏｄｅは、Ａｌｅｒｔコマンドがセッションを正常に終了させることを命令するため設計される必要があり、たとえば、Ｃｏｄｅは１２１０である。
【０１６９】
従来技術では、セッションが終了されるべきであるかどうかを判定する方法は以下の通りである。端末は、サーバが空メッセージを送信した場合にセッションを終了する。命令は端末にとって不明確であり、端末の正確な管理に悪影響を与える。本実施形態で設計された具体的な終了命令コマンドは、端末の正確な管理を実現しやすくする。
【０１７０】
６． 端末で、ある一定のＭＯは複数のインスタンスを有することが可能である。しかし、時々、ＭＯインスタンスが一つのみアクティブ化される。たとえば、端末リソース・オペレーション・タイプのＭＯに対し、端末リソースは制限され、排他的であるので、複数のＭＯインスタンスが同時にまたはある一定の期間の範囲内に存在する場合、リソースは、１個のＭＯインスタンスだけによって占有されて作動（すなわち、アクティブ化）されることがある。他のＭＯインスタンスを通じてサーバによって配信された管理アクションは拒絶され、エラーコード４０３、４０５または５００が返送される。従来技術では、複数のＭＯインスタンスが端末の中に存在するとき、サーバは現在アクティブ化されているインスタンスを認知しないので、サーバ管理の難しさが増加する。図１１に示されているように、以下のステップを含む端末アクティブ化ＭＯを取得する方法が提供される。
【０１７１】
端末が端末リソースをＭＯインスタンスに割り当てるか、または、端末がＭＯインスタンスをアクティブ化して使用し、すなわち、ＭＯインスタンスは現在利用できるＭＯとしての機能を果たす。
【０１７２】
ＭＯインスタンスをローカルに記録するとき、サーバは、端末アクティブ化ＭＯを獲得するためにセッション管理プロセスの中でＧｅｔコマンドを端末へ送信する。端末はアクティブ化ＭＯに関する情報をサーバへ返送する。
【０１７３】
本実施形態では、現在アクティブ化されているＭＯインスタンス（すなわち、端末リソースを現在占有中であり、かつ、端末リソースを動作させることができるＭＯ）を指示する２つの方法は以下の通りである。
【０１７４】
端末はアクティブ化ＭＯリストをローカルに維持する。アクティブ化ＭＯリストは機器管理ツリーの中に表現されていない。サーバは、Ｇｅｔコマンドを端末のルートノードへ送信し、パラメータを伝達することによりデータを獲得する。
【０１７５】
Ｇｅｔコマンドの中で伝達されるパラメータは、たとえば、．？ｌｉｓｔ＝ＡｃｔｉｖｅｄＲｅｓｏｕｒｃｅＭＯとして設計されてもよいＧｅｔ／Ｉｔｅｍ／Ｔａｒｇｅｔ／ＬｏｃＵＲＬの中で伝達されてもよい。端末は、端末リソースに対応し、アクティブ化されたＭＯのルートノードのＵＲＩを返送する。サーバは、ある一定のタイプの具体的なＭＯを返送するよう端末に命令するために、コマンドのアイテムの中でデータ要素を伝達してもよく、データ要素の値はＭＯＩＤである。使用例は以下の通りである。
【０１７６】
【数１２】
【０１７７】
端末は、アクティブ化ＭＯインスタンスの情報を管理ツリーに記憶し、具体的には以下の事項を含む。
【０１７８】
ａ． 管理ツリーのサブツリーは機器管理ツリーの中に追加される。端末のすべてのアクティブ化ＭＯのルートノードのＵＲＩリストは、管理ツリーのサブツリーに記憶される。追加された管理サブツリーは図１２に示されている通りであり、アクティブ化ＭＯリストが記憶される管理サブツリーはＤｅｖＤｅｔａｉｌ ＭＯに記憶されてもよい。サーバは、端末アクティブ化ＭＯを取得するために、値を獲得するため直接的にＧｅｔコマンドをアクティブ化ＭＯノードのサブノードに配信してもよい。具体的なコマンドおよびオペレーションは他のノードのコマンドおよびオペレーションに類似しているので、ここではそれらの説明は省略される。
【０１７９】
ｂ． ＭＯインスタンスがアクティブ化ＭＯインスタンスであるかどうかがＭＯインスタンスのルートノードのノード特性値に記録される。その後、サーバは、ＭＯインスタンスがアクティブ化ＭＯインスタンスであるかどうかを判定するために直接的にＭＯのルートノードの特性値を獲得する。具体的な方法は以下の通りである。
【０１８０】
既存のＭＯのルートノードのタイプ特性値の構造が拡張される。変更された値構造は複合値を伝達することができる。複合値は、ＭＯＩＤフィールドと、ＡｃｔｉｖａｔｅｄまたはＤｅａｃｔｉｖａｔｅｄフィールドの２つのフィールドを含む。２つのフィールドはプラス符号で繋がれる。使用例は以下の通りである。
【０１８１】
ある一定のＭＯのアクティブ化状態のルートノードのＴｙｐｅ特性値はＭＯＩＤ＋Ａｃｔｉｖａｔｅｄである。
【０１８２】
端末は、機器管理ツリーの中のＭＯのアクティブ化状態を判定し、ＭＯのルートノードのタイプ特性値を維持する。
【０１８３】
端末のアクティブ化ＭＯを取得するとき、サーバは、値を獲得するためにＧｅｔコマンドをＭＯのルートノードのＴｙｐｅ特性に送信し、その後、ＭＯインスタンスがアクティブ化ＭＯであるかどうかを判定するためＡｃｔｉｖａｔｅｄ／Ｄｅａｃｔｉｖａｔｅｄフィールドの値を抽出する。
【０１８４】
本実施形態では、端末がアクティブ化ＭＯを特定し、その後、サーバがアクティブ化ＭＯを獲得する方法が提供され、アクティブ化ＭＯが識別されないので、サーバがＭＯをアクティブ化するため即座にオペレーションを検索しない可能性があるという従来技術における課題を解決し、その結果、管理効率が改良される。
【０１８５】
本開示は異なる形式で複数の特定の実施形態を有する。以下、本開示の技術的解決手段が図２ないし１２を参照して説明される。これは、本開示の具体的な実施例が実施形態による具体的なプロセスまたは構造だけに限定されることを意味しない。当業者には上述された具体的な実施が多数の好ましい解決手段の中のいくつかの実施例に過ぎないことを理解されたい。
【０１８６】
実施形態では、本開示は、第１の受信モジュールおよび構成モジュールを含むＤＭ端末を提供する。第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。
【０１８７】
さらに、本実施形態は警告モジュールおよび第１の記録モジュールをさらに含んでもよい。警告モジュールは、端末のブートストラップまたは再ブートストラップのための警告情報を伝達するセッション要求メッセージをサーバへ送信するよう適合される。第１の記録モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバのサーバアカウントＭＯの管理ノードに記録するよう適合される。
【０１８８】
構成モジュールは、検索ユニット、第１の処理ユニット、および第２の処理ユニットを含む。検索ユニットは、ＳｅｒｖｅｒＩＤに対応するサーバアカウントＭＯが端末ＤＭツリーの中に存在するかどうかを検索するよう適合する。第１の処理ユニットは、ブートストラップが反復ブートストラップまたは再ブートストラップであるかどうかを区別し、検索ユニットが端末ＤＭツリーの中でＳｅｒｖｅｒＩＤに対応するサーバアカウントＭＯを見つけたときに、対応するオペレーションを実行するよう適合する。第２の処理ユニットは、検索ユニットが端末ＤＭツリーの中のＳｅｒｖｅｒＩＤに対応するサーバアカウントＭＯを見つけることに失敗したとき、ブートストラップ情報に従って端末ＤＭツリーの中のサーバのサーバアカウントＭＯを生成するよう適合される。
【０１８９】
実施形態では、本開示は、第１の受信モジュールおよび認証モジュールを含むＤＭ装置を提供する。第１の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを受信するよう適合される。認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。
【０１９０】
実施形態では、本開示は、第１の送信モジュールおよび第１の獲得モジュールを含む別のＤＭ装置を提供する。第１の送信モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバアカウントＭＯに記録する管理ノードの値を獲得するためにＧｅｔコマンドを送信するよう適合される。第１の獲得モジュールは構成モード情報を獲得するよう適合される。
【０１９１】
実施形態では、本開示は、端末およびサーバを含むブートストラップシステムを提供する。端末は、第１の受信モジュール、構成モジュール、および警告モジュールを含む。第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。警告モジュールは、端末のブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを送信するよう適合される。サーバは第１の受信モジュールおよび認証モジュールを含む。第１の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを受信するよう適合される。認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。
【０１９２】
実施形態では、本開示は、端末およびサーバを含む別のブートストラップシステムを提供する。端末は、第１の受信モジュール、構成モジュール、および第１の記録モジュールを含む。第１の受信モジュールは、サーバのＳｅｒｖｅｒＩＤを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。第１の記録モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバのサーバアカウントＭＯの管理ノードに記録するよう適合される。サーバは、第１の送信モジュールおよび第１の獲得モジュールを含む。第１の送信モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末ＤＭツリーの中のサーバアカウントＭＯに記録する管理ノードの値を獲得するためにＧｅｔコマンドを送信するよう適合される。第１の獲得モジュールは構成モード情報を獲得するよう適合される。
【０１９３】
実施形態では、本開示は、作成モジュールおよび第２の記録モジュールを含む別のＤＭ端末を提供する。作成モジュールは管理ノードを端末のＤＭツリーに追加するよう適合される。第２の記録モジュールは、端末によってサポートされたＤＭオブジェクトタイプを端末のＤＭツリーに追加された管理ノードに記録するよう適合される。
【０１９４】
実施形態では、本開示は、第２の獲得モジュールおよび決定モジュールを含む別のＤＭ装置を提供する。第２の獲得モジュールは、端末との管理セッションにおいて端末のＤＭツリーに追加された端末によってサポートされたＤＭオブジェクトタイプを記録する管理ノードの値を獲得するよう適合される。決定モジュールは管理ノードの値に従って端末によってサポートされたＤＭオブジェクトタイプを判定するよう適合される。
【０１９５】
実施形態では、本開示は、端末およびサーバを含む管理端末システムを提供する。端末は、作成モジュールおよび第２の記録モジュールを含む。作成モジュールは管理ノードを端末のＤＭツリーに追加するよう適合される。第２の記録モジュールは、端末によってサポートされたＤＭオブジェクトタイプを端末のＤＭツリーに追加された管理ノードに記録するよう適合される。サーバは、第２の獲得モジュールおよび決定モジュールを含む。第２の獲得モジュールは、端末との管理セッションにおいて端末のＤＭツリーに追加された端末によってサポートされたＤＭオブジェクトタイプを記録する管理ノードの値を獲得するよう適合される。決定モジュールは管理ノードの値に従って端末によってサポートされたＤＭオブジェクトタイプを判定するよう適合される。
【０１９６】
実施形態では、本開示は、第２の受信モジュールおよび実行モジュールを含むＤＭ端末をさらに提供する。第２の受信モジュールは、端末ＤＭツリーのターゲット・オペレーション・ノードを伝達するパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報のＧｅｔコマンドとを受信するよう適合される。実行モジュールは、ターゲット・オペレーション・ノードのパス情報および値フィルタリング情報に従ってサブツリーの構造情報、および、サブツリーの中の各ノードの特性値を獲得し、特性値および構造情報を返送するよう適合される。
【０１９７】
実施形態では、本開示は、第２の送信モジュールおよび第３の受信モジュールを含む別のＤＭ装置を提供する。第２の送信モジュールは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報とを伝達するＧｅｔコマンドを送信するよう適合される。第３の受信モジュールは、サブツリーの構造情報と、端末によって返送されたサブツリーの中の各ノードの特性値とを受信するよう適合される。
【０１９８】
実施形態では、本開示は、端末およびサーバを含み、管理ノード特性を獲得するシステムを提供する。端末は、第２の受信モジュールおよび実行モジュールを含む。第２の受信モジュールは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報のＧｅｔコマンドとを受信するよう適合される。実行モジュールは、ターゲット・オペレーション・ノードのパス情報および値フィルタリング情報に従って、サブツリーの構造情報、および、サブツリーの中の各ノードの特性値を獲得し、特性値および構造情報を返送するよう適合される。サーバは、第２の送信モジュールおよび第３の受信モジュールを含む。第２の送信モジュールは、端末ＤＭツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報とを伝達するＧｅｔコマンドを送信するよう適合される。第３の受信モジュールは、サブツリーの構造情報と、端末によって返送されたサブツリーの中の各ノードの特性値とを受信するよう適合される。
【０１９９】
実施形態では、本開示は、第４の受信モジュールおよび検索モジュールを含む別のＤＭ端末を提供する。第４の受信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを受信するよう適合される。検索モジュールは、検索されるべきサブツリーの中でＭＯを検索し、見つけられたＭＯのルート・ノード・パスを返送するよう適合される。
【０２００】
実施形態では、本開示は、第３の送信モジュールおよび第５の受信モジュールを含む別のＤＭ装置を提供する。第３の送信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを送信するよう適合される。第５の受信モジュールは、端末によって返送された検索されるべきサブツリーの中のＭＯのルート・ノード・パスを受信するよう適合される。
【０２０１】
本開示は、端末およびサーバを含み、ＭＯアドレスを検索するシステムを提供する。端末は、第４の受信モジュールおよび検索モジュールを含む。第４の受信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータと、を伝達するＧｅｔコマンドを受信するよう適合される。検索モジュールは、検索されるべきサブツリーの中でＭＯを検索し、見つけられたＭＯのルート・ノード・パスを返送するよう適合される。サーバは、第３の送信モジュールおよび第５の受信モジュールを含む。第３の送信モジュールは、検索されるべきＭＯのＩＤと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のＭＯのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータと、を伝達するＧｅｔコマンドを送信するよう適合される。第５の受信モジュールは、端末によって返送された検索されるべきサブツリーの中のＭＯのルート・ノード・パスを受信するよう適合される。
【０２０２】
当業者には、実施形態による方法のステップの全部または一部が関連したハードウェアに命令するプログラムによって実施されることがあることを理解されたい。プログラムはコンピュータ読み取り可能な媒体に記憶されることができる。プログラムが実行されるとき、実施形態による方法のステップが実行される。記憶媒体は、リード・オンリ・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、磁気ディスクまたは光ディスクのようなプログラムコードを記憶することができる媒体であればどのような媒体であってもよい。
【０２０３】
最後に、上記実施形態は本開示の技術的解決手段を単に説明するために与えられているだけであり、本開示を限定することを意図しないことに注意を要する。本開示は実施形態を参照して詳細に記載されているが、本開示の精神および範囲から逸脱しない限り、実施形態に記載された技術的解決手段に対する変更、または、技術的解決手段のいくつかの技術的特徴に対する等価的な置換が行われることがあることが当業者には理解されたい。
【特許請求の範囲】
【請求項１】
端末によって、サーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を含む前記サーバのブートストラップ情報を受信し、
前記端末によって、前記ブートストラップ情報によってブートストラップまたは再ブートストラップを実行する、
ブートストラップ方法。
【請求項２】
前記端末によって、前記ブートストラップ情報によってブートストラップまたは再ブートストラップを実行した後、
前記端末の前記ブートストラップもしくは前記再ブートストラップの警告情報または前記ブートストラップ情報の更新情報を伝達するセッション要求メッセージを送信し、
前記サーバによって、前記セッション要求メッセージを受信し、前記端末を認証するために前記警告情報または前記ブートストラップ情報の前記更新情報に従って認証情報を生成する、
ことをさらに備える請求項１に記載のブートストラップ方法。
【請求項３】
前記サーバによって前記セッション要求メッセージを受信した後、
新しいノンスを伝達するチャレンジメッセージを前記端末へ送信し、前記端末によって、前記新しいノンスを通じて認証情報を生成し、前記チャレンジメッセージを受信した後に認証のため前記認証情報を前記サーバへ送信することをさらに備える
請求項２に記載のブートストラップ方法。
【請求項４】
前記端末によって、前記ブートストラップ情報によって前記ブートストラップまたは再ブートストラップを実行することが、
前記端末によって、前記ブートストラップまたは再ブートストラップを実行する前に、前記ＳｅｒｖｅｒＩＤに対応するサーバアカウントの管理オブジェクト（ＭＯ）が端末機器管理（ＤＭ）ツリーの中に存在するかどうかを検索し、存在する場合、反復ブートストラップまたは再ブートストラップが実行されたかどうかを見分け、対応するオペレーションを実行し、存在しない場合、前記ブートストラップ情報に従って前記サーバの前記ＭＯを前記端末ＤＭツリーの中に生成することを含む
請求項１または２に記載のブートストラップ方法。
【請求項５】
管理ノードを端末の機器管理（ＤＭ）ツリーの中の管理オブジェクト（ＭＯ）に追加し、前記端末の機器記述フレームワーク（ＤＤＦ）の記憶アドレスまたは端末ＤＤＦ情報が前記管理ノードに記憶され、
サーバによって、前記サーバと前記端末との間の管理セッションを通じて前記管理ノードの値を獲得し、前記管理ノードの値に従って前記端末ＤＤＦに関する情報を獲得する、
ことを備える、機器記述フレームワーク（ＤＤＦ）を獲得する方法。
【請求項６】
前記サーバによって、前記サーバと前記端末との間の前記管理セッションを通じて前記管理ノードの前記値を獲得することが、
前記端末によって、前記端末と前記サーバとの間に確立された第１の管理セッションにおいて前記管理ノードの前記値を報告するか、または、
前記端末によって、前記端末と前記サーバとの間に確立された第１の管理セッションにおいて前記管理ノードの端末管理ツリーの位置を報告し、前記サーバによって、前記位置に従っていずれかのその後の管理セッションにおいて前記管理ノードの前記値を獲得するか、または、
前記端末によって、前記端末と前記サーバとの間に確立された管理セッションにおいてセッション要求メッセージの中で前記管理ノードの端末管理ツリーの位置を報告し、前記サーバによって、前記位置に従っていずれかのその後の管理セッションにおいて前記管理ノードの前記値を獲得するか、または、
前記端末によって、セッション・トリガ・メッセージの中で伝達され、前記管理ノードに記憶された前記端末ＤＤＦ、前記端末によってサポートされたＭＯのＤＤＦ、または、ＤＤＦの記憶アドレスを報告するよう前記端末に命令する前記サーバの命令情報を受信し、前記端末によって、セッション要求メッセージの中で前記管理ノードの前記値を報告するか、または、
前記サーバによって、前記ＭＯの位置を獲得し、前記ＭＯの前記位置および前記ＭＯの標準構造に従って端末管理ツリーの中の前記管理ノードの位置を検索するか、もしくは、前記サーバによって、前記端末管理ツリーの構造情報を獲得し、前記構造情報によって直接的に端末管理ツリーの中での前記管理ノードの位置を検索し、前記管理ノードの前記位置に従って前記管理ノードの前記値を獲得する、
ことを含む請求項５に記載の方法。
【請求項７】
前記管理ノードの前記値が前記ＤＤＦの前記記憶アドレスである場合、
前記サーバによって、前記管理ノードの前記値を獲得した後、前記管理ノードの前記値に従って前記端末ＤＤＦに関する情報を獲得する、
ことをさらに備える請求項５または６に記載の方法。
【請求項８】
サーバによって、端末機器管理（ＤＭ）ツリーの中のターゲット・オペレーション・ノードのパス情報、および、ルートとして前記ターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令と、前記サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令とを含む獲得されるべき値フィルタリング情報を伝達するＧｅｔコマンドを端末へ送信し、
前記端末によって、前記サーバの前記Ｇｅｔコマンドを受信し、前記ターゲット・オペレーション・ノードのパス情報および前記値フィルタリング情報に従って前記サブツリーの前記構造情報および前記サブツリーの中の各ノードの前記特性値を獲得し、前記特性値および前記構造情報を前記サーバへ返送する、
ことを備える、管理ノード特性を獲得する方法。
【請求項９】
前記指定された特性がノードタイプ特性、ノードアクセス制御リスト（ＡＣＬ）特性、ノード値Ｆｏｒｍａｔ特性、ノードＴｉｔｌｅ特性、ノード値Ｓｉｚｅ特性、ノード変更タイムスタンプ（ＴＳｔａｍｐ）特性、または、ノードバージョン番号（ＶｅｒＮｏ）特性である請求項８に記載の方法。
【請求項１０】
サーバによって、されるべき（）と、機器管理ツリーの中のサブツリーのルート・ノード・パスと、前記サブツリーの中の管理オブジェクト（ＭＯ）の出現する前記ルート・ノード・パスを検索して返送するよう端末に命令する検索命令パラメータと、を伝達するＧｅｔコマンドを前記端末へ送信し、
前記端末によって、前記Ｇｅｔコマンドを受信し、前記サブツリーの中で前記サーバによりアクセス権限が保有されている前記ＭＯの出現を検索し、前記Ｇｅｔコマンドのステータス情報を返送し、前記ステータス情報の後に続いて見つけられたＭＯの前記ルート・ノード・パスを前記サーバへ返送する、
ことを備える、管理オブジェクト（ＭＯ）アドレスを検索する方法。
【請求項１１】
前記端末によって、前記見つけられたＭＯの前記ルート・ノード・パスを前記サーバへ返送することが、
前記端末が条件を満たす前記ＭＯの１回以上の出現を見つけたとき、前記端末によって、同じ結果コマンドの複数の「Ｉｔｅｍ」サブ要素で伝達されるか、または、単一の「Ｉｔｅｍ」」要素を含む複数の結果コマンドで伝達される前記見つけられたＭＯの前記ルート・ノード・パスを返送することを含み、
返送される情報がＭＯＩＤを伝達するか、または、伝達しない
請求項１０に記載のＭＯアドレスを検索する方法。
【請求項１２】
前記検索命令パラメータが前記Ｇｅｔコマンドの「リスト」特性の特性値として前記端末へ配信される請求項１０に記載のＭＯアドレスを検索する方法。
【請求項１３】
サーバによって、送信された管理コマンドの中で前記管理コマンドの中の複数のサブアイテムを順次実行する命令を伝達し、
端末によって、前記管理コマンドを受信し、前記順次実行する命令を解析し、前記管理コマンドの中の前記サブアイテムに対応する管理ノードのための前記管理コマンドを順次実行する、
ことを備える、コマンドの実行モードを管理する方法。
【請求項１４】
前記サーバによって、前記送信された管理コマンドの中で前記管理コマンドの中の前記複数のサブアイテムを順次実行する前記命令を伝達することが、
前記サーバによって、前記サブアイテムを順次実行する前記命令を前記管理コマンドの要素の特性として前記端末へ配信するか、または、
前記サーバによって、前記サブアイテムを順次実行する前記命令を前記管理コマンドの要素のサブ要素として前記端末へ配信するか、または、
前記サーバによって、前記サブアイテムを順次実行する前記命令を前記管理コマンドの要素のサブ要素であるが前記サブアイテムの親要素として前記端末へ配信する、
ことを含む請求項１３に記載の方法。
【請求項１５】
機器管理（ＤＭ）コマンドが相互に作用させられる機器管理（ＤＭ）セッションをサーバと端末との間に確立し、
前記サーバまたは前記端末によって、受信された前記管理コマンドを処理し、前記管理コマンドの処理時間がセッション中断またはタイムアウトを引き起こすことを判定し、セッション維持コマンドを伝達するＤＭメッセージを反対端へ送信し、
前記反対端によって、前記メッセージを受信し、肯定応答メッセージを返送し、前記セッション維持コマンドの送信元によって送信された、前記管理コマンドもしくは前記セッション維持コマンドを伝達するか、または、管理コマンドを伝達しない空メッセージである新しい管理メッセージが受信されるまで、セッションを維持する、
ことを備える、管理セッションを維持する方法。
【請求項１６】
前記セッション維持コマンドが警告コマンドであり、前記サーバまたは前記端末が、前記警告コードの特定のタイプコードによってセッション維持オペレーションを実行するよう前記反対端に命令する請求項１５に記載の方法。
【請求項１７】
端末によって、端末リソースを管理オブジェクト（ＭＯ）インスタンスに割り当てるか、または、前記端末によって、ＭＯインスタンスをアクティブ化して使用し、
前記端末によって、前記ＭＯインスタンスをローカルに記録し、サーバが前記端末アクティブ化ＭＯを獲得するために管理セッションプロセスの中でＧｅｔコマンドを前記端末へ送信し、前記端末が前記ローカルに記録されたアクティブ化ＭＯに関する情報を前記サーバへ返送する、
ことを備える、端末アクティブ化管理オブジェクト（ＭＯ）を取得する方法。
【請求項１８】
前記端末によって、前記ＭＯインスタンスをローカルに記録することが、
前記端末によって、管理ツリーの中での前記ＭＯインスタンスの位置情報である前記アクティブ化ＭＯインスタンスに関する情報をローカル非管理ツリーの記憶空間の中で維持するか、または、
前記端末によって、管理ノードの値として役立つ前記アクティブ化ＭＯインスタンスに関する前記情報をローカル管理ツリーに記録することであって、前記アクティブ化ＭＯインスタンスに関する前記記録された情報が前記管理ツリーの中の前記オブジェクトインスタンスの前記位置情報である、前記記録することか、または、
前記端末によって、前記ＭＯインスタンスのルートノードの特性値としてローカルに前記アクティブ化ＭＯインスタンスに関する前記情報を使用すること、
を含む請求項１７に記載の方法。
【請求項１９】
サーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を含む前記サーバのブートストラップ情報を受信するよう適合された第１の受信モジュールと、
前記ブートストラップ情報によって、ブートストラップまたは再ブートストラップを実行するよう適合された構成モジュールと、
を備える、機器管理（ＤＭ）端末。
【請求項２０】
前記端末の前記ブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを前記サーバへ送信するよう適合された警告モジュールをさらに備える請求項１９に記載のＤＭ端末。
【請求項２１】
前記構成モジュールが、
前記ＳｅｒｖｅｒＩＤに対応するサーバアカウントの管理オブジェクト（ＭＯ）が端末ＤＭツリーの中に存在するかどうかを検索するよう適合された検索ユニットと、
反復ブートストラップまたは再ブートストラップが実行されるかどうかを見分け、前記検索ユニットが前記端末ＤＭツリーの中で前記ＳｅｒｖｅｒＩＤに対応する前記サーバアカウントの前記ＭＯを見つけたとき、対応するオペレーションを実行するよう適合された第１の処理ユニットと、
前記検索ユニットが前記端末ＤＭツリーの中で前記ＳｅｒｖｅｒＩＤに対応する前記サーバアカウントの前記ＭＯを見つけられなかったときに、前記ブートストラップ情報に従って前記端末ＤＭツリーの中に前記サーバのサーバアカウントのＭＯを生成するよう適合された第２の処理ユニットと、
を含む請求項１９または２０に記載のＤＭ端末。
【請求項２２】
端末によって送信されたブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを受信するよう適合された第１の受信モジュールと、
前記警告情報に従って前記端末を認証するため認証情報を生成するよう適合された認証モジュールと、
を備える、機器管理（ＤＭ）装置。
【請求項２３】
端末およびサーバを備えるブートストラップシステムであって、
前記端末は、
前記サーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を含む前記サーバのブートストラップ情報を受信するよう適合された第１の受信モジュールと、
前記ブートストラップ情報によって、ブートストラップまたは再ブートストラップを実行するよう適合された構成モジュールと、
前記端末のブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを送信するよう適合された警告モジュールと、
を備え、
前記サーバは、
前記端末によって送信された前記ブートストラップまたは再ブートストラップに関する前記警告情報を伝達する前記セッション要求メッセージを受信するよう適合された第１の受信モジュールと、
前記警告情報に従って前記端末を認証するために認証情報を生成するよう適合された認証モジュールと、
を備える、ブートストラップシステム。
【請求項２４】
検索されるべき管理オブジェクト（ＭＯ）の識別子（ＩＤ）（ＭＯＩＤ）を伝達し、機器管理ツリーの中のサブツリーのルート・ノード・パス、および、前記サブツリーの中の前記ＭＯの出現する前記ルート・ノード・パスを検索して返送するよう端末に命令する検索命令パラメータを伝達するＧｅｔコマンドを受信するよう適合された第４の受信モジュールと、
サーバが前記サブツリーの中でアクセス権限を有する前記ＭＯの出現を検索し、前記Ｇｅｔコマンドのステータス情報を返送し、前記ステータス情報の後に続いて前記見つけられたＭＯの前記ルート・ノード・パスを前記サーバへ返送するよう適合された検索モジュールと、
を備える、機器管理（ＤＭ）端末。
【請求項２５】
検索されるべき管理オブジェクト（ＭＯ）の識別子（ＩＤ）（ＭＯＩＤ）と、機器管理ツリーの中のサブツリーのルート・ノード・パスと、前記サブツリーの中の前記ＭＯの出現する前記ルート・ノード・パスを検索して返送するよう端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを送信するよう適合された第３の送信モジュールと、
前記端末によって返送された前記Ｇｅｔコマンドのステータス情報と前記サブツリーの中の前記ＭＯの出現する前記ルート・ノード・パスとを受信するよう適合された第５の受信モジュールと、
を備える、機器管理（ＤＭ）装置。
【請求項２６】
端末およびサーバを備え、管理オブジェクト（ＭＯ）アドレスを検索するシステムであって、
前記端末が、
検索されるべきＭＯの識別子（ＩＤ）（ＭＯＩＤ）と、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスと、前記サブツリーの中の前記ＭＯの出現する前記ルート・ノード・パスを検索して返送するよう前記端末に命令する検索命令パラメータと、を伝達するＧｅｔコマンドを受信するよう適合された第４の受信モジュールと、
前記サーバが前記サブツリーの中でアクセス権限を有するＭＯを検索し、前記Ｇｅｔコマンドのステータス情報と、前記ステータス情報の後に続いて前記見つけられたＭＯの前記ルート・ノード・パスと、をサーバへ返送するよう適合された検索モジュールと、
を備え、
前記サーバが、
検索されるべき前記ＭＯの前記ＩＤ（ＭＯＩＤ）と、前記機器管理ツリーの中の前記サブツリーの前記ルート・ノード・パスと、前記サブツリーの中の前記ＭＯの出現する前記ルート・ノード・パスを検索して返送するよう前記端末に命令する前記検索命令パラメータと、を伝達するＧｅｔコマンドを送信するよう適合された第３の送信モジュールと、
前記端末によって返送された前記Ｇｅｔコマンドの前記ステータス情報と前記サブツリーの中の前記ＭＯの前記ルート・ノード・パスとを受信するよう適合された第５の受信モジュールと、
を備える、システム。
【請求項１】
端末によって、サーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を含む前記サーバのブートストラップ情報を受信し、
前記端末によって、前記ブートストラップ情報によってブートストラップまたは再ブートストラップを実行する、
ブートストラップ方法。
【請求項２】
前記端末によって、前記ブートストラップ情報によってブートストラップまたは再ブートストラップを実行した後、
前記端末の前記ブートストラップもしくは前記再ブートストラップの警告情報または前記ブートストラップ情報の更新情報を伝達するセッション要求メッセージを送信し、
前記サーバによって、前記セッション要求メッセージを受信し、前記端末を認証するために前記警告情報または前記ブートストラップ情報の前記更新情報に従って認証情報を生成する、
ことをさらに備える請求項１に記載のブートストラップ方法。
【請求項３】
前記サーバによって前記セッション要求メッセージを受信した後、
新しいノンスを伝達するチャレンジメッセージを前記端末へ送信し、前記端末によって、前記新しいノンスを通じて認証情報を生成し、前記チャレンジメッセージを受信した後に認証のため前記認証情報を前記サーバへ送信することをさらに備える
請求項２に記載のブートストラップ方法。
【請求項４】
前記端末によって、前記ブートストラップ情報によって前記ブートストラップまたは再ブートストラップを実行することが、
前記端末によって、前記ブートストラップまたは再ブートストラップを実行する前に、前記ＳｅｒｖｅｒＩＤに対応するサーバアカウントの管理オブジェクト（ＭＯ）が端末機器管理（ＤＭ）ツリーの中に存在するかどうかを検索し、存在する場合、反復ブートストラップまたは再ブートストラップが実行されたかどうかを見分け、対応するオペレーションを実行し、存在しない場合、前記ブートストラップ情報に従って前記サーバの前記ＭＯを前記端末ＤＭツリーの中に生成することを含む
請求項１または２に記載のブートストラップ方法。
【請求項５】
管理ノードを端末の機器管理（ＤＭ）ツリーの中の管理オブジェクト（ＭＯ）に追加し、前記端末の機器記述フレームワーク（ＤＤＦ）の記憶アドレスまたは端末ＤＤＦ情報が前記管理ノードに記憶され、
サーバによって、前記サーバと前記端末との間の管理セッションを通じて前記管理ノードの値を獲得し、前記管理ノードの値に従って前記端末ＤＤＦに関する情報を獲得する、
ことを備える、機器記述フレームワーク（ＤＤＦ）を獲得する方法。
【請求項６】
前記サーバによって、前記サーバと前記端末との間の前記管理セッションを通じて前記管理ノードの前記値を獲得することが、
前記端末によって、前記端末と前記サーバとの間に確立された第１の管理セッションにおいて前記管理ノードの前記値を報告するか、または、
前記端末によって、前記端末と前記サーバとの間に確立された第１の管理セッションにおいて前記管理ノードの端末管理ツリーの位置を報告し、前記サーバによって、前記位置に従っていずれかのその後の管理セッションにおいて前記管理ノードの前記値を獲得するか、または、
前記端末によって、前記端末と前記サーバとの間に確立された管理セッションにおいてセッション要求メッセージの中で前記管理ノードの端末管理ツリーの位置を報告し、前記サーバによって、前記位置に従っていずれかのその後の管理セッションにおいて前記管理ノードの前記値を獲得するか、または、
前記端末によって、セッション・トリガ・メッセージの中で伝達され、前記管理ノードに記憶された前記端末ＤＤＦ、前記端末によってサポートされたＭＯのＤＤＦ、または、ＤＤＦの記憶アドレスを報告するよう前記端末に命令する前記サーバの命令情報を受信し、前記端末によって、セッション要求メッセージの中で前記管理ノードの前記値を報告するか、または、
前記サーバによって、前記ＭＯの位置を獲得し、前記ＭＯの前記位置および前記ＭＯの標準構造に従って端末管理ツリーの中の前記管理ノードの位置を検索するか、もしくは、前記サーバによって、前記端末管理ツリーの構造情報を獲得し、前記構造情報によって直接的に端末管理ツリーの中での前記管理ノードの位置を検索し、前記管理ノードの前記位置に従って前記管理ノードの前記値を獲得する、
ことを含む請求項５に記載の方法。
【請求項７】
前記管理ノードの前記値が前記ＤＤＦの前記記憶アドレスである場合、
前記サーバによって、前記管理ノードの前記値を獲得した後、前記管理ノードの前記値に従って前記端末ＤＤＦに関する情報を獲得する、
ことをさらに備える請求項５または６に記載の方法。
【請求項８】
サーバによって、端末機器管理（ＤＭ）ツリーの中のターゲット・オペレーション・ノードのパス情報、および、ルートとして前記ターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令と、前記サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令とを含む獲得されるべき値フィルタリング情報を伝達するＧｅｔコマンドを端末へ送信し、
前記端末によって、前記サーバの前記Ｇｅｔコマンドを受信し、前記ターゲット・オペレーション・ノードのパス情報および前記値フィルタリング情報に従って前記サブツリーの前記構造情報および前記サブツリーの中の各ノードの前記特性値を獲得し、前記特性値および前記構造情報を前記サーバへ返送する、
ことを備える、管理ノード特性を獲得する方法。
【請求項９】
前記指定された特性がノードタイプ特性、ノードアクセス制御リスト（ＡＣＬ）特性、ノード値Ｆｏｒｍａｔ特性、ノードＴｉｔｌｅ特性、ノード値Ｓｉｚｅ特性、ノード変更タイムスタンプ（ＴＳｔａｍｐ）特性、または、ノードバージョン番号（ＶｅｒＮｏ）特性である請求項８に記載の方法。
【請求項１０】
サーバによって、されるべき（）と、機器管理ツリーの中のサブツリーのルート・ノード・パスと、前記サブツリーの中の管理オブジェクト（ＭＯ）の出現する前記ルート・ノード・パスを検索して返送するよう端末に命令する検索命令パラメータと、を伝達するＧｅｔコマンドを前記端末へ送信し、
前記端末によって、前記Ｇｅｔコマンドを受信し、前記サブツリーの中で前記サーバによりアクセス権限が保有されている前記ＭＯの出現を検索し、前記Ｇｅｔコマンドのステータス情報を返送し、前記ステータス情報の後に続いて見つけられたＭＯの前記ルート・ノード・パスを前記サーバへ返送する、
ことを備える、管理オブジェクト（ＭＯ）アドレスを検索する方法。
【請求項１１】
前記端末によって、前記見つけられたＭＯの前記ルート・ノード・パスを前記サーバへ返送することが、
前記端末が条件を満たす前記ＭＯの１回以上の出現を見つけたとき、前記端末によって、同じ結果コマンドの複数の「Ｉｔｅｍ」サブ要素で伝達されるか、または、単一の「Ｉｔｅｍ」」要素を含む複数の結果コマンドで伝達される前記見つけられたＭＯの前記ルート・ノード・パスを返送することを含み、
返送される情報がＭＯＩＤを伝達するか、または、伝達しない
請求項１０に記載のＭＯアドレスを検索する方法。
【請求項１２】
前記検索命令パラメータが前記Ｇｅｔコマンドの「リスト」特性の特性値として前記端末へ配信される請求項１０に記載のＭＯアドレスを検索する方法。
【請求項１３】
サーバによって、送信された管理コマンドの中で前記管理コマンドの中の複数のサブアイテムを順次実行する命令を伝達し、
端末によって、前記管理コマンドを受信し、前記順次実行する命令を解析し、前記管理コマンドの中の前記サブアイテムに対応する管理ノードのための前記管理コマンドを順次実行する、
ことを備える、コマンドの実行モードを管理する方法。
【請求項１４】
前記サーバによって、前記送信された管理コマンドの中で前記管理コマンドの中の前記複数のサブアイテムを順次実行する前記命令を伝達することが、
前記サーバによって、前記サブアイテムを順次実行する前記命令を前記管理コマンドの要素の特性として前記端末へ配信するか、または、
前記サーバによって、前記サブアイテムを順次実行する前記命令を前記管理コマンドの要素のサブ要素として前記端末へ配信するか、または、
前記サーバによって、前記サブアイテムを順次実行する前記命令を前記管理コマンドの要素のサブ要素であるが前記サブアイテムの親要素として前記端末へ配信する、
ことを含む請求項１３に記載の方法。
【請求項１５】
機器管理（ＤＭ）コマンドが相互に作用させられる機器管理（ＤＭ）セッションをサーバと端末との間に確立し、
前記サーバまたは前記端末によって、受信された前記管理コマンドを処理し、前記管理コマンドの処理時間がセッション中断またはタイムアウトを引き起こすことを判定し、セッション維持コマンドを伝達するＤＭメッセージを反対端へ送信し、
前記反対端によって、前記メッセージを受信し、肯定応答メッセージを返送し、前記セッション維持コマンドの送信元によって送信された、前記管理コマンドもしくは前記セッション維持コマンドを伝達するか、または、管理コマンドを伝達しない空メッセージである新しい管理メッセージが受信されるまで、セッションを維持する、
ことを備える、管理セッションを維持する方法。
【請求項１６】
前記セッション維持コマンドが警告コマンドであり、前記サーバまたは前記端末が、前記警告コードの特定のタイプコードによってセッション維持オペレーションを実行するよう前記反対端に命令する請求項１５に記載の方法。
【請求項１７】
端末によって、端末リソースを管理オブジェクト（ＭＯ）インスタンスに割り当てるか、または、前記端末によって、ＭＯインスタンスをアクティブ化して使用し、
前記端末によって、前記ＭＯインスタンスをローカルに記録し、サーバが前記端末アクティブ化ＭＯを獲得するために管理セッションプロセスの中でＧｅｔコマンドを前記端末へ送信し、前記端末が前記ローカルに記録されたアクティブ化ＭＯに関する情報を前記サーバへ返送する、
ことを備える、端末アクティブ化管理オブジェクト（ＭＯ）を取得する方法。
【請求項１８】
前記端末によって、前記ＭＯインスタンスをローカルに記録することが、
前記端末によって、管理ツリーの中での前記ＭＯインスタンスの位置情報である前記アクティブ化ＭＯインスタンスに関する情報をローカル非管理ツリーの記憶空間の中で維持するか、または、
前記端末によって、管理ノードの値として役立つ前記アクティブ化ＭＯインスタンスに関する前記情報をローカル管理ツリーに記録することであって、前記アクティブ化ＭＯインスタンスに関する前記記録された情報が前記管理ツリーの中の前記オブジェクトインスタンスの前記位置情報である、前記記録することか、または、
前記端末によって、前記ＭＯインスタンスのルートノードの特性値としてローカルに前記アクティブ化ＭＯインスタンスに関する前記情報を使用すること、
を含む請求項１７に記載の方法。
【請求項１９】
サーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を含む前記サーバのブートストラップ情報を受信するよう適合された第１の受信モジュールと、
前記ブートストラップ情報によって、ブートストラップまたは再ブートストラップを実行するよう適合された構成モジュールと、
を備える、機器管理（ＤＭ）端末。
【請求項２０】
前記端末の前記ブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを前記サーバへ送信するよう適合された警告モジュールをさらに備える請求項１９に記載のＤＭ端末。
【請求項２１】
前記構成モジュールが、
前記ＳｅｒｖｅｒＩＤに対応するサーバアカウントの管理オブジェクト（ＭＯ）が端末ＤＭツリーの中に存在するかどうかを検索するよう適合された検索ユニットと、
反復ブートストラップまたは再ブートストラップが実行されるかどうかを見分け、前記検索ユニットが前記端末ＤＭツリーの中で前記ＳｅｒｖｅｒＩＤに対応する前記サーバアカウントの前記ＭＯを見つけたとき、対応するオペレーションを実行するよう適合された第１の処理ユニットと、
前記検索ユニットが前記端末ＤＭツリーの中で前記ＳｅｒｖｅｒＩＤに対応する前記サーバアカウントの前記ＭＯを見つけられなかったときに、前記ブートストラップ情報に従って前記端末ＤＭツリーの中に前記サーバのサーバアカウントのＭＯを生成するよう適合された第２の処理ユニットと、
を含む請求項１９または２０に記載のＤＭ端末。
【請求項２２】
端末によって送信されたブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを受信するよう適合された第１の受信モジュールと、
前記警告情報に従って前記端末を認証するため認証情報を生成するよう適合された認証モジュールと、
を備える、機器管理（ＤＭ）装置。
【請求項２３】
端末およびサーバを備えるブートストラップシステムであって、
前記端末は、
前記サーバのサーバ識別子（ＳｅｒｖｅｒＩＤ）を含む前記サーバのブートストラップ情報を受信するよう適合された第１の受信モジュールと、
前記ブートストラップ情報によって、ブートストラップまたは再ブートストラップを実行するよう適合された構成モジュールと、
前記端末のブートストラップまたは再ブートストラップに関する警告情報を伝達するセッション要求メッセージを送信するよう適合された警告モジュールと、
を備え、
前記サーバは、
前記端末によって送信された前記ブートストラップまたは再ブートストラップに関する前記警告情報を伝達する前記セッション要求メッセージを受信するよう適合された第１の受信モジュールと、
前記警告情報に従って前記端末を認証するために認証情報を生成するよう適合された認証モジュールと、
を備える、ブートストラップシステム。
【請求項２４】
検索されるべき管理オブジェクト（ＭＯ）の識別子（ＩＤ）（ＭＯＩＤ）を伝達し、機器管理ツリーの中のサブツリーのルート・ノード・パス、および、前記サブツリーの中の前記ＭＯの出現する前記ルート・ノード・パスを検索して返送するよう端末に命令する検索命令パラメータを伝達するＧｅｔコマンドを受信するよう適合された第４の受信モジュールと、
サーバが前記サブツリーの中でアクセス権限を有する前記ＭＯの出現を検索し、前記Ｇｅｔコマンドのステータス情報を返送し、前記ステータス情報の後に続いて前記見つけられたＭＯの前記ルート・ノード・パスを前記サーバへ返送するよう適合された検索モジュールと、
を備える、機器管理（ＤＭ）端末。
【請求項２５】
検索されるべき管理オブジェクト（ＭＯ）の識別子（ＩＤ）（ＭＯＩＤ）と、機器管理ツリーの中のサブツリーのルート・ノード・パスと、前記サブツリーの中の前記ＭＯの出現する前記ルート・ノード・パスを検索して返送するよう端末に命令する検索命令パラメータとを伝達するＧｅｔコマンドを送信するよう適合された第３の送信モジュールと、
前記端末によって返送された前記Ｇｅｔコマンドのステータス情報と前記サブツリーの中の前記ＭＯの出現する前記ルート・ノード・パスとを受信するよう適合された第５の受信モジュールと、
を備える、機器管理（ＤＭ）装置。
【請求項２６】
端末およびサーバを備え、管理オブジェクト（ＭＯ）アドレスを検索するシステムであって、
前記端末が、
検索されるべきＭＯの識別子（ＩＤ）（ＭＯＩＤ）と、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスと、前記サブツリーの中の前記ＭＯの出現する前記ルート・ノード・パスを検索して返送するよう前記端末に命令する検索命令パラメータと、を伝達するＧｅｔコマンドを受信するよう適合された第４の受信モジュールと、
前記サーバが前記サブツリーの中でアクセス権限を有するＭＯを検索し、前記Ｇｅｔコマンドのステータス情報と、前記ステータス情報の後に続いて前記見つけられたＭＯの前記ルート・ノード・パスと、をサーバへ返送するよう適合された検索モジュールと、
を備え、
前記サーバが、
検索されるべき前記ＭＯの前記ＩＤ（ＭＯＩＤ）と、前記機器管理ツリーの中の前記サブツリーの前記ルート・ノード・パスと、前記サブツリーの中の前記ＭＯの出現する前記ルート・ノード・パスを検索して返送するよう前記端末に命令する前記検索命令パラメータと、を伝達するＧｅｔコマンドを送信するよう適合された第３の送信モジュールと、
前記端末によって返送された前記Ｇｅｔコマンドの前記ステータス情報と前記サブツリーの中の前記ＭＯの前記ルート・ノード・パスとを受信するよう適合された第５の受信モジュールと、
を備える、システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公表番号】特表２０１１−５１７７９２（Ｐ２０１１−５１７７９２Ａ）
【公表日】平成２３年６月１６日（２０１１．６．１６）
【国際特許分類】
【出願番号】特願２０１０−５４５３４６（Ｐ２０１０−５４５３４６）
【出願日】平成２０年７月２８日（２００８．７．２８）
【国際出願番号】ＰＣＴ／ＣＮ２００８／０７１７８５
【国際公開番号】ＷＯ２００９／１００６３２
【国際公開日】平成２１年８月２０日（２００９．８．２０）
【出願人】（５０３４３３４２０）華為技術有限公司 (107)
【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ ５１８１２９ Ｐ．Ｒ． Ｃｈｉｎａ
【Ｆターム（参考）】
【公表日】平成２３年６月１６日（２０１１．６．１６）
【国際特許分類】
【出願日】平成２０年７月２８日（２００８．７．２８）
【国際出願番号】ＰＣＴ／ＣＮ２００８／０７１７８５
【国際公開番号】ＷＯ２００９／１００６３２
【国際公開日】平成２１年８月２０日（２００９．８．２０）
【出願人】（５０３４３３４２０）華為技術有限公司 (107)
【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ ５１８１２９ Ｐ．Ｒ． Ｃｈｉｎａ
【Ｆターム（参考）】
[ Back to top ]