JP5095831B6 - 機器管理の方法、端末、装置およびシステム - Google Patents
機器管理の方法、端末、装置およびシステム Download PDFInfo
- Publication number
- JP5095831B6 JP5095831B6 JP2010545346A JP2010545346A JP5095831B6 JP 5095831 B6 JP5095831 B6 JP 5095831B6 JP 2010545346 A JP2010545346 A JP 2010545346A JP 2010545346 A JP2010545346 A JP 2010545346A JP 5095831 B6 JP5095831 B6 JP 5095831B6
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- server
- management
- command
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000007726 management method Methods 0.000 title claims description 6
- 230000000875 corresponding Effects 0.000 claims description 50
- 206010046306 Upper respiratory tract infection Diseases 0.000 claims description 16
- 230000005540 biological transmission Effects 0.000 claims description 14
- 238000000034 method Methods 0.000 description 19
- 238000001914 filtration Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 7
- 239000002131 composite material Substances 0.000 description 5
- 230000004913 activation Effects 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000006011 modification reaction Methods 0.000 description 1
- 230000003287 optical Effects 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 230000003068 static Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001960 triggered Effects 0.000 description 1
Images
Description
本開示は、ネットワーク通信の技術分野での機器管理の方法、端末、装置、およびシステムに関する。
モバイル端末はモバイル・オペレーション・サービス・システムにおける重要なコンポーネントである。機器管理(DM、Device Management)とは、データパケットがオーバ・ザ・エア(OTA、Over The Air)モードでネットワーク側から端末機器へダウンロードされ、端末機器が、パラメータ・コンフィギュレーション、ソフトウェア設置、およびエラー診断のようなその後の機能を達成するため、処理を実行するよう命令されることを意味する。
オープン・モバイル・アライアンスDM(OMA DM)により設計されたDM仕様では、端末機器の管理のためのプロトコルサポートは既に達成されている。図1は、端末機器を管理するDMサーバの全体的構造の概略図である。端末機器上のDMクライアントはDMサーバによって配信された管理コマンドを説明し実行するよう適合している。端末機器上のDM管理ツリーは、DMサーバがDMプロトコルを通じて端末機器を管理するインターフェイスとしてみなされることがある。管理オブジェクト(MO、Management Object)のグループは管理ツリーの中に存在する。DMサーバは、MOの中のノード(管理ノード)の動作を通じて端末リソースを管理する目的を達成する。
図1に示されているように、従来技術では、DM管理は2つのステップ、すなわち、ブートストラップおよびその後の管理を通じて実行される。ブートストラップは、サーバと端末機器との間の管理セッションが実際の管理のため確立される前に起こり、(ユーザ名およびパスワードのような)アカウント情報と(接続パラメータのような)他のパラメータとを構成するよう適合する。その後の管理プロセスにおいて、管理セッションが確立される。サーバは、端末機器のMOを通じて、端末の(ファームウェアバージョン、ソフトウェアバージョン、および大規模オブジェクトサポートのような)基本情報を獲得し、その後の管理アクションの基礎としてこの基本情報を使用することができる。
従来技術では、端末機器の管理のためのプロトコルサポートは既に達成されているが、管理有効性、効率、および通信トラフィックのような問題が依然として存在する。たとえば、サーバは、端末DMオブジェクトのアドレスおよび(ソフトウェアコンポーネント管理のサポートおよびファームウェアアップグレードのサポートの能力のような)端末によってサポートされるDM能力を迅速に取得しない可能性があり、端末は再ブートストラップのためSmartCardを使用する。具体的には以下の通りである。
1. 端末がローカルに再ブートストラップされた後(たとえば、機器が交換された後)、サーバは端末がブートストラップされたことが認知しないので、サーバに記憶されている認証関連情報は端末がブートストラップされた後の認証関連情報と矛盾する場合があり、結果として、同一性認証が両当事者のためには達成されない可能性があり、通常の管理は失敗することになる。
2. サーバが端末機器による管理ツリーの制限または端末による管理ツリーの実施の制限に関する状況を取得することを可能にするため、従来技術では、端末製造業者は、その端末製造業者の機器を記述し、機器記述フレームワーク(DDF、Device Description Framework)を介してDM当事者による照会のための記述を公表する。しかし、既存プロトコルでは、サーバ側は端末機器を通じてその対応するDDFを見つけることができないため、サーバがDDFを獲得することはより困難である。
3. サーバは、端末によってサポートされる管理オブジェクト(MO)タイプを取得しない可能性があり、ネットワークリソースをさらに浪費する。DDFは、通常は、静的であるか、または、殆ど動的に変更されないので、サーバが端末によってサポートされるすべてのMOタイプをDDFに従って取得することは難しい。サーバは、対応する管理コマンドが配信され、配信されたコマンドが大量のデータ(たとえば、ソフトウェアコンポーネント管理)を伝達した後に限り、端末によって返送される結果を通じて端末がある一定のDM能力をサポートするかどうかを判定するので、サーバおよびネットワークリソースは浪費される。
4. 従来技術では、サーバは、非直列化モードにおいて一括して機器管理ツリー上のある一定の管理サブツリーの中のすべての管理ノードの具体的な特性値を獲得しない可能性があり、したがって、特性は数回に亘って獲得される必要があり、結果として、効率が低くなる。
5. サーバが端末の管理ノードを検索することは非常に困難であり、エアリソースが消費される。端末管理ノードを獲得するため、サーバは、数回に亘って端末と相互に作用するか、または、端末のディレクトリ構造全体を獲得する必要がある場合があるので、エアリソースは占有され、サーバ上の負荷が増大する。
6. 従来技術では、サーバは、端末に単一の管理コマンドで複数の要素を順次実行するよう命令しない可能性があるので、順次実行を必要とするアクションは、実施のため順次実行される複数の管理コマンドに分割される必要があり、したがって、端末によるメッセージ管理および解析と実行とのコストが増大する。
7. 端末またはサーバがアクションを処理するために長時間を要するとき、セッションは中断される場合があり、管理アクションが完了できない。このようにして、長時間を要する管理は困難になる。その上、当事者が管理コマンドは間もなく送信される必要があることを確認するとき、現在のセッションは維持されない可能性があり、現在のセッションは中断される場合がある。管理セッションは、管理コマンドがその後に送信される必要があるときに再確立されるべきであり、大きなコストを引き起こす。
8. 端末が複数のMOインスタンスを有するとき、サーバは現在アクティブ化されているインスタンスを認知しないため、結果として、サーバ管理の難易度が高くなる。
実施形態では、本開示は、ユーザがブートストラップを実行した後に通常の管理が実行されない可能性があるという従来技術における第1の技術的課題を解決する。
実施形態では、本開示は、プロトコルサーバが対応する機器記述フレームワーク(DDF)を獲得することが難しいという従来技術における第2の技術的課題を解決する。
実施形態では、本開示は、サーバが非直列化モードにおいて一括して機器管理ツリー上のある一定の管理サブツリーの中のすべての管理ノードの具体的な特性値を獲得しないことがあるという従来技術における第3の技術的課題を解決する。
実施形態では、本開示は、サーバが端末の管理ノードを検索することが難しく、エアリソースが浪費され、サーバの負荷が高いという従来技術における第4の技術的課題を解決する。
実施形態では、本開示は、既存のサーバが端末に、単一の管理コマンドの中の複数の要素を順次実行するよう命令しない可能性があるという従来技術における第5の技術的課題を解決する。
実施形態では、本開示は、セッションを維持する方法が利用できないとき、予期しない中断がセッションの中で起こる可能性があるという従来技術における第6の技術的課題を解決する。
実施形態では、本開示は、端末が複数の管理オブジェクト(MO)インスタンスを有し、サーバが現在アクティブ化されているインスタンスを認知しないので、サーバを管理する難易度が高くなるという従来技術における第7の技術的課題を解決する。
本発明の第1の態様によれば、機器管理方法であって、サーバと端末との間に管理セッションを確立し、サーバによって、検索されるべき管理オブジェクトの識別子(MOID)を伝達するItem/Data要素を伝達し、機器管理ツリーの中のサブツリーのルートノードURIを伝達するItem/Target/LocURI要素と、端末にサブツリーの中の管理オブジェクト(MO)の出現するルートノードURIを検索し返送するよう命令する検索命令パラメータとを伝達するGetコマンドを端末へ送信し、端末によって、Getコマンドを受信し、サブツリーの中でサーバによりアクセス権限が所有されているMOの出現を検索し、端末によって、端末がMOの1回以上の出現を見つけたとき、Getコマンドのステータス情報と、ステータス情報の後に続いて見つけられたMOのルートノードURIとをサーバへ返送するか、または、端末がMOの出現を見つけられなかったとき、Getコマンドのステータス情報をサーバへ返送する、ことを含む機器管理方法が提供される。
本発明の第2の態様によれば、機器管理(DM)端末であって、検索されるべき管理オブジェクト(MO)の識別子(ID)(MOID)を伝達し、機器管理ツリーの中のサブツリーのルート・ノード・パス、および、サブツリーの中のMOの出現するルート・ノード・パスを検索して返送するよう端末に命令する検索命令パラメータを伝達するGetコマンドを受信するよう適合された受信モジュールと、サーバがサブツリーの中でアクセス権限を有するMOの出現を検索し、Getコマンドのステータス情報とステータス情報の後に続いて見つけられたMOの前記ルート・ノード・パスとをサーバへ返送するよう適合された検索モジュールと、を備える機器管理端末が提供される。
本発明の第3の態様によれば、機器管理(DM)装置は、検索されるべき管理オブジェクト(MO)の識別子(ID)(MOID)と、機器管理ツリーの中のサブツリーのルートノードURIと、サブツリーの中のMOの出現するルートノードURIを検索し返送するよう端末に命令する検索命令パラメータとを伝達するGetコマンドを送信するよう適合された送信モジュールと、Getコマンドのステータス情報と、端末によって返送されたサブツリーの中のMOの出現するルートノードURIとを受信するよう適合された受信モジュールと、を備える機器管理装置が提供される。
本発明の第4の態様によれば、上記第2の態様による端末と、上記第3の態様による機器管理装置と、を備える機器管理のシステムが提供される。
本開示の技術的な解決手段は、添付図面を参照してさらに詳細に記載される。
従来技術において端末を管理するDMサーバの全体的構造の概略図である。
本開示の実施形態によるブートストラップ方法のフローチャートである。
本開示の実施形態によるブートストラップ方法においてブートストラップタイプ管理ノードをDMAcc MOに追加する概略図である。
本開示の実施形態によるDDFを獲得する方法のフローチャートである。
本開示によるDDFを獲得する方法の解析プロセスの概略図である。
本開示の実施形態による端末管理方法において機器管理ツリーの中にサポートノードを追加する概略図である。
本開示の実施形態によるMOアドレスを検索する方法の概略図である。
本開示の実施形態によるコマンドの実行モードを管理する方法のフローチャートである。
本開示の実施形態による管理セッションを維持する方法のフローチャートである。
本開示の実施形態による管理セッションを維持する方法の解析プロセスのフローチャートである。
本開示の実施形態による端末アクティブ化MOを取得する方法のフローチャートである。
本開示の実施形態による機器管理ツリーの中のアクティブ化MOに関する情報を記憶する概略図である。
機器管理(DM)は、主として2つの段階、すなわち、ブートストラップの段階とその後の管理の段階とにおいて実行される。ブートストラップは、管理セッションがサーバと端末機器との間で確立される前に生じ、主として、端末で、サーバの(サーバのアドレス、ユーザ名、およびパスワード)のようなアカウント情報を構成し、(ネットワーク・アクセス・ポイントの情報のような)他のパラメータを構成する。ブートストラップ段階で構成された情報は、その後の管理セッションの確立のための基礎となる。サーバのアカウント情報の構成が完了した後、サーバは端末を管理することができる。管理アクションは、サーバと端末機器との間に確立された管理セッションを通じて達成される。
本開示における改良点は、ブートストラップおよびその後の管理セッションを含む2つの部分を用いて以下で詳細に明らかにされている。
I. ブートストラップ
ブートストラップの主な目的は、端末とサーバとの間に通常の管理セッションを確立することを可能にするためサーバのアカウント情報を構成することである。同時に、接続設定のような他の関連パラメータがさらに構成されることがある。この具体的な構成方法は以下の通りである。構成されるべきサーバのアカウント情報および他の関連パラメータは、クライアントプロビジョニング(CP)ファイルフォーマットまたは管理オブジェクト(MO)直列化フォーマットの中にカプセル化され、カプセル化されたブートストラップ情報がプレインストレーション配信、OTAプッシュ、または、SmartCardのようなモードで端末へ配信される。端末はサーバのサーバ識別子(ServerID)を格納するサーバのカプセル化されたブートストラップ情報を受信し、端末はブートストラップまたは再ブートストラップのためブートストラップ情報を使用する。構成の主な仕事は、ブートストラップ情報の中のサーバのアカウント情報を、端末DMツリーの中のサーバアカウントMO(以下、DMAccと称する)と他の関連MOとに変換することである。その後、DMAccに対応するサーバに先に接続されていた端末は、サーバ上の管理状態をアクティブ化する。接続が確立されているとき、サーバは、「LocName」(LocNameの値はDMAcc MOの中で「AAUTHNAME」と呼ばれるノードの値である)を通じて端末のユーザ名を取得し、そして、認証のためのユーザ名に対応するパスワードをさらに使用する。メッセージ・ダイジェスト・アルゴリズム5(MD5)認証では、ノンスがリプレイ攻撃を阻止するために取得されることがさらに必要である。
特に、SmartCardモードは、初期構成を都合良く実行し、端末のアカウント情報に問題が起こったとき、または、端末(たとえば、携帯電話機)が交換されたとき、再構成を実行することがある安全かつ便利な構成モードである。端末機器が構成済みのアカウントに関する再構成(たとえば、SmartCardモードによる再構成)をローカルで実行するとき、サーバが初期構成後にOTAモードにおいて構成済みのアカウントのパスワードを変更し、SmartCard上のブートストラップ情報の中のアカウントに対応するパスワードが変更されていないならば、端末のローカル再構成後に、DMAcc上のパスワードはリセットされることになる(パスワードは変更前に元の値に再変換される)。再構成は、ローカルなアクションであり、サーバはアカウント情報が再構成されたことを知ることができないので、端末に記憶されているパスワードはサーバに記憶されているパスワードと矛盾する。同時に、サーバは端末を認証できず、管理セッションは確立されない可能性がある。
本開示の第1の実施形態では、ブートストラップ構成問題が解決される。2つの主要な方法が以下の通り説明される。
1. 図2に示されているように、サーバのアカウント情報がブートストラップまたは再ブートストラップされた後、端末はセッション要求メッセージをサーバへ送信する。セッション要求メッセージは、端末がブートストラップまたは再ブートストラップされたことをサーバに警告するよう構成される。
サーバがセッション要求メッセージを受信した後、パスワードと、セッション要求メッセージの中で搬送されるLocNameに対応するノンスとが、端末を認証するためサーバによって記憶されたブートストラップ情報から獲得される。認証が成功した後、サーバ側の認証情報が初期化されるか、または、リセットされる。
端末がサーバに、端末がブートストラップまたは再ブートストラップされたことを警告する方法は以下の通りである。
端末がブートストラップまたは再ブートストラップされた後、端末は、最初に、端末がブートストラップまたは再ブートストラップされたことをサーバに知らせるため、セッション要求メッセージをサーバへ送信する。セッション要求メッセージは、端末機器情報、LocName、端末認証情報、および、ブートストラップまたは再ブートストラップ警告情報を含むことができる。ブートストラップまたは再ブートストラップ警告情報の具体的な実施方法は以下の通りである。
端末は、警告情報を実施するために「Alert」コマンドの特定のタイプコードの「Alert」コマンドを使用する。AlertコマンドおよびAlertコマンドのタイプコードは、特に、端末情報レポートAlertコマンド(すなわち、コマンド・タイプコードが1226である一般的な警告(Genric Alert))と、端末事象レポート警告コマンド(すなわち、コマンド・タイプコードが1224であるクライアント事象警告(Client Event Alert))、または、具体的には以下の通りの警告情報を報告するための新しいセッションタイプであってもよい。
事象タイプ(Event type)は、たとえば、一般的な警告、または、クライアント事象警告、たとえば、org.openmobilealliance.dm.bootstrapを採用するために最初に定義される必要がある。以下、一般的な警告は一実施例として採用されている。クライアント事象報告を使用する方法は以下に類似する。
警告情報を報告する新しいセッションタイプを追加する方法は以下の通りである。新しいAlertコマンドのタイプコードが追加される。タイプコードを伝達するAlertコマンドは新しいセッションタイプを指示するよう構成される。タイプコードは1202であってもよい。実施例は以下の通りである。
端末によって開始されたサーバへのセッション要求メッセージは、ブートストラップ警告情報を伝達する。サーバが要求メッセージを受信した後、サーバは、セッション要求メッセージの中で伝達された警告情報を解析することにより、端末がブートストラップまたは再ブートストラップされたことを認知し、次に、端末要求を認証するためサーバ側で記憶されたブートストラップ情報の中のパスワードを獲得する。その後の管理において、サーバは端末によって記憶されたパスワードを更新することができる。
安全性のため(たとえば、悪質なサーバがセッション要求メッセージを傍受し、リプレイ攻撃を始める問題を防止するため)、端末によって送信されたセッション要求メッセージを認証した後、サーバは端末への認証チャレンジをさらに開始することができる。チャレンジは、サーバによって生成された新しいノンスを伝達する。サーバによって送信されたチャレンジメッセージを受信した後、端末は新しいノンスを使用して新しい認証情報を生成し、認証情報をサーバへ送信する。サーバは端末を再び認証する。認証が成功した後、サーバは他の管理オペレーションを実行することができ、たとえば、サーバパスワードを更新することができる。
再ブートストラップは、ある一定の条件(たとえば、携帯電話機カードが新しい携帯電話機に挿入される)において端末機器によって自動的にトリガされ、または、端末ユーザインターフェイス(UI)を介してユーザによってトリガされることが可能である。
2. SmartCard上のブートストラップ情報が端末によって更新可能である場合、ブートストラップ方法は以下の通りである。端末は、端末のDMツリーのDMAcc MOに記憶されたユーザ名、パスワードまたはノンスを更新するため、サーバのDMコマンドを受信する。更新が成功した後、端末は、SmartCardオペレーションコマンドを通じて自動的にSmartCardにおけるブートストラップファイルの中の対応するユーザ名、パスワードまたはノンス情報を更新する。上記処理後の2つの状況は以下の通りである。
1) ブートストラップファイルの更新が、ブートストラップファイルの中で伝達されるユーザ名、パスワード、およびノンスが、サーバによって記憶されたユーザ名、パスワード、およびノンスと整合していることを保証できる場合、その後のブートストラップは更新済みのブートストラップファイルを用いて実行され、そして、ブートストラップ後に、サーバに通知する必要がない(すなわち、ブートストラップ事象をサーバへ報告する専用セッションが必要とされない)。
2) ブートストラップファイルの更新が、ブートストラップファイルの中で伝達されるユーザ名、パスワード、およびノンスが、サーバによって記憶されたユーザ名、パスワード、およびノンスと整合していることを保証できない場合、ユーザ名、パスワード、またはノンスのようなアカウントデータの更新を効率的に制御し、サーバと端末との間の同期を容易に行うために、ブートストラップファイルが更新された後に、更新情報が更新済みのブートストラップファイルの中に記録される。更新情報はバージョンフィールドを追加することにより記録されることができる。さらに、セッションがブートストラップの後にブートストラップファイルを使用することにより初めて確立されるとき、記録された更新情報がセッション要求メッセージの中で報告される。サーバは更新に従って処理を実行する。
ブートストラップは複数のモードを含む。しかし、これまでのところ、ブートストラップによって生成された機器管理ツリーのDMAcc MOの中の情報は、アカウントが生成されたブートストラップモードに関する記録を含まない。したがって、サーバは、ブートストラップモードを通じてブートストラップの安全性レベルを判断することができず、すべての端末について採用されたブートストラップ方法の統計を取ることができない。本開示の第2の実施形態では、上記課題を解決する方法が以下の通り記載される。サーバが端末のブートストラップのソースを取得することができるよう、本実施形態では、端末がブートストラップされるモード、すなわち、ブートストラップタイプを記憶するため、管理ノード(たとえば、図3における「ブートストラップタイプ」)が端末DMツリーのDMAcc MOに追加される。具体的な実施形態は図3に示されている通りである。ブートストラップタイプの値は、表1に示されているように整数でもよい。
端末のブートストラップが成功した後、ブートストラップモードは管理ノードの中に記憶される。サーバは端末の中のアカウントに対応するブートストラップモードを獲得するために管理セッションを介してGetコマンドを管理モードへ配信する。サーバの権限を認証した後、端末は管理ノード値を返送する。
第3の実施形態では、本開示は、端末が複数のDMAccを生成するため数回に亘って同じServerIDアカウントでブートストラップを実行する状況を回避するように、ブートストラップ情報を処理する方法について記載する。具体的なブートストラップ方法は以下のステップを含む。
1. 端末の管理ツリーは、以下の通り、ServerIDに対応するDMAcc MOが既に存在するかどうかを判定するため検索される。現在構成されるべきサーバアカウントに対応するServerIDが装置管理ツリーの中のDMAcc MOのServerIDノードの値と同じであるかどうかが比較され、一方、現在構成されるべきサーバアカウントに対応するServerIDが装置管理ツリーの中のDMAcc MOのServerIDノードの値と同じである場合、対応するアカウント情報が存在し、現在構成されるべきサーバアカウントに対応するServerIDが装置管理ツリーの中のDMAcc MOのServerIDノードの値と同じでない場合、対応するアカウント情報が存在しない。ServerIDに対応するDMAcc MOが端末の管理ツリーの中に見つけられる場合、ステップ2が実行され、ServerIDに対応するDMAcc MOが端末の管理ツリーの中で見つからない場合、ステップ3が実行される。
2. ブートストラップオペレーションが反復ブートストラップまたは再ブートストラップであるかどうかが判定される(たとえば、ユーザの確認情報を通じて複数のモードで判定されることがある)。ブートストラップオペレーションが反復ブートストラップである場合、ブートストラップオペレーションはキャンセルされる。ブートストラップオペレーションが再ブートストラップである場合、機器管理ツリー上の対応するDMAcc MOの中の管理ノード上のデータが直接的にリフレッシュされる。
3. ブートストラップ情報の中のカウント情報が端末DMツリーの中のDMAcc MOに変換され、アクセス制御リスト(ACL)がDMAcc MOについて分配される。
前述の第1の実施形態では、ユーザが再ブートストラップされた(たとえば、機器が交換された)後に端末がブートストラップされたかどうかをサーバが認知できず、それゆえ、先行するユーザの端末情報の影響の下で通常の管理が失敗する可能性があるという課題を効果的に解決するブートストラップ方法が図示されている。第2の実施形態では、サーバが端末のブートストラップモードを取得していない可能性があり、そして、ブートストラップモードに従ってブートストラップの安全性レベルを判断できないことがあるという課題が解決される。第3の実施形態では、同じServerIDが数回に亘ってブートストラップされたとき、同じServerIDに対応する複数のDMAcc MOがブートストラップ競合に起因して端末DMツリーの中に存在する状況を回避し、反復ブートストラップによって引き起こされるアカウント管理の混乱を回避するように、処理方法が提供される。
本開示におけるその後の管理セッションの改良点は以下の通り詳細に明らかにされる。
II. 管理セッション
ブートストラップが端末上で成功した後、管理セッションがサーバと端末との間に確立されることが可能であり、管理メッセージがセッションの中で交換されることが可能である。このセッションは、セッション確立段階と管理段階とを含む。セッション確立段階では、同一性が相互に認証され、同時に、端末が、DevInfo MOに記憶された端末基本情報を報告する。管理段階では、サーバが、管理アクションを端末へ配信するように、端末の管理ツリー上のMOへ保守オペレーションを配送する。機器管理ツリーの管理ノードは、管理ノードのためのサーバのオペレーション権限を制御するためにACLを有する。
1. サーバが端末機器による管理ツリーへの制限または端末による管理ツリーの実施状況を知ることができるよう、機器記述フレームワーク(DDF)が、機器を記述するために採用される。サーバが機器を理解し管理を実行することが必要であるとき、まず、DDFに従って端末を管理するように機器のDDFが獲得される。しかし、既存のプロトコルでは、サーバ側は端末機器を介して対応するDDFを見つけられない可能性があり、サーバがDDFを獲得することがより困難である。
本開示の実施形態においてDDFを獲得する方法は図4に示される通りであり、以下のステップを含む。
DDFのユニフォーム・リソース・ロケータ(URL)は端末の管理ツリーに記憶される。
サーバはURLを通じて端末のDDFを獲得する。
サーバ側によるDDFの獲得を容易に実現するため、DDFのURLは、サーバがURLを通じて端末のDDFを獲得するように、または、DDFデータが端末の管理ツリーにさらに記憶されるように、端末の管理ツリーに記憶されることがある。このようにして、サーバは、図4の実施形態に限定されることなく、端末から直接的にDDF情報を獲得することがある。具体的な実例は次の通りである。
端末がDDFのURLを記憶する実施方法は以下の通りである。管理ノードは端末のDMツリーの中に追加され、端末のDDFのURLは追加された管理ノードの中に記憶される(複数のDDFが存在する可能があり、複数のノードがURLを記憶するため使用されない可能性がある)。好ましくは、上記記憶アクションは機器の配信の前に達成され、機器の使用中に記憶アクションは実際の状況に従って更新されることがある(たとえば、機器製造業者がDDFの記憶アドレスを更新する)。追加された管理ノードは、既存のDevInfo MOまたは機器詳細情報(DevDetail)MOの中に記憶されてもよく、または、MOとして別々に存在してもよい。ノード特性は表2に示されている通りである。
端末がDDFのURLを記憶し、そして、管理サーバがDDFを獲得し使用する2つの方法は以下の通りである。
第1の方法では、端末は、最初に、DDF管理ノードの値または管理ノードの位置を報告する。具体的な方法は以下の通りである。端末は以下の機会に報告する。
第1の機会では、ある一定のサーバアカウントが端末のため構成された後(たとえば、ブートストラップ後)、端末はサーバへの登録セッション(端末とサーバとの間の第1のセッション)を開始する。このセッションでは、DDF管理ノードの値またはDDF管理ノードの位置が報告される。その後の管理セッションでは、DDF管理ノードの値およびDDF管理ノードの位置は、サーバがそれらを再獲得するためにGetコマンドを配信しない限り、最初に報告されない(方法2を参照のこと)。好ましくは、管理セッションのセッション要求メッセージは、DDF管理ノードの値またはDDF管理ノードの位置を伝達する。
第2の機会では、端末は、各管理セッションのセッション要求メッセージの中でDevInfoと一緒にDDF管理ノードの値またはDDF管理ノードの位置を報告する。
DDF管理ノードを記憶する位置が報告される場合、いずれかのその後の管理セッションにおいて、サーバは、DDF管理ノードを記憶する位置に従ってDDF管理ノードの値を獲得する(DDF管理ノードの値はDDFのURL情報である)。
サーバがDDFのURL情報を受信した後、DDFが必要とされるとき(たとえば、端末の詳細な管理または構成が実施される前)、具体的なDDF情報がURLに従って獲得され、端末はDDFに従って生成された管理コマンドに従って管理される。
第2の方法では、サーバはサーバと端末との間で確立された管理セッションにおいて最初にDDF情報を獲得する。具体的なプロセスは図5に示されている通りであり、具体的なステップは以下の通り明らかにされる。
ステップ1では、DMサーバは、管理プロセスにおいて端末からDDF管理ノードに記憶されたURLを獲得する。具体的な方法は以下の通りである。
端末はサーバの命令情報を受信する。命令情報は、サーバによって送信された通知メッセージ(セッション・トリガ・メッセージ)の中で伝達される。命令情報は、端末に、DDF管理ノードに記憶された端末DMツリーのDDFのURLまたは端末によってサポートされたある一定のMOのDDFのURLを報告するよう命令する。その後に、端末は通知の中の情報に従って管理セッションを開始するセッション要求メッセージを生成する。URLはセッション要求メッセージの中で報告される。具体的なレポート方法は以下の通りである。警告タイプは端末のために拡張される。AlertコマンドはタイプおよびURLを伝達する。タイプがMOのDDFである場合、MOIDがさらに伝達されることがある。サーバは警告タイプおよびMOIDに従ってURLを特定する。
代替的に、ノードはDevDetail MOまたは他のMOに記憶される。サーバは、確立された管理セッションの中でGetコマンドを通じてノードの値を獲得する。DevDetail MOを一実施例として採用すると、サーバが、ノードと、端末DMツリーの中でノードを記憶するDevDetail MOのパスとを知らない場合、ノードは以下の方法を通じて検索される。
サーバは端末DMツリーの構造情報を獲得し、構造情報を直接的に分析することにより端末DMツリーの中の管理ノードの位置を検索する。
代替的に、サーバは、以下の通り具体的に、最初に管理ノードのMO(ここでは、DevDetail)の位置を獲得する。サーバはGetコマンドを通じてDevDetail MOの位置を検索するか、または、DevDetailの位置情報を端末のDevInfoに記憶する。端末は、(最初のDMセッションの中で報告されるか、1回報告されるか、または、各セッションで報告されることがある)セッション要求メッセージの中でDevInfoと一緒にDevDetail MOの位置(ルート・ノード・パス)をサーバへ報告する。サーバは、DevDetailの位置およびDevDetail MOの構造情報(機器管理ツリーの中で獲得されたDevDetail MOルートノードのパスと、DevDetail構造の中のDevDetailルートノードと相対的なDDF管理ノードの相対パスとを接続することにより形成されたDDF管理ノードのパス)に従ってDDF管理ノードの位置を検索する。
DDF管理ノードの位置が検索された後、GetコマンドがDDF管理ノードの値を獲得するため配信される。
ステップ2では、端末は、記憶しているDDFのアドレスをDMサーバへ返送する。具体的な方法は以下の通りである。ノードがDevInfo MOに記憶されている場合、端末はセッション要求メッセージの中でアドレスを伝達する。ノードがDevDetail MOの中に記憶されている場合、端末はサーバによって送信された問い合わせコマンドの結果(リザルト)メッセージの中でDDFアドレスを返送する。
ステップ3では、DMサーバは、DDFを獲得するため、獲得されたDDF記憶アドレスに対応するリモートDDF記憶サーバと通信する。
ステップ4では、リモートDDF記憶サーバはDDF記述ファイルをDMサーバへ返送する。
ステップ5〜7では、DMサーバは、その後の管理のための基準としてDDFを使用することにより管理アクションを生成し、端末を管理し、端末は実行結果を返送する。
DDFのその後の獲得のコストを削減するため、DMサーバは獲得されたDDFデータをローカルに一時的に記憶することができる。
端末がDDFを記憶する実施方法は以下の通りである。管理ノードは端末のDMツリーの中に追加される。管理ノードは端末DMツリーの中のある一定のMOに追加され、DDFの内容はノードの中に記憶される。値は、機器配信前にノードに割り当てられることがある。機器の使用中に、DMクライアントは実際の状況に従って更新を実行する。好ましくは、ノードはDevDetail MOに追加される。ノード特性は表3に示されている通りである。
この方法では、サーバは管理プロセスにおいてDDFの内容であるノードの値を獲得する。具体的に、4つの方法が、ノードの値がDevDetailに記憶される実施例を採用することにより、以下の通り例示されている。
第1の方法では、サーバは、以下の通り具体的に、DDFを獲得するために直接的にDDFの管理ノードの位置を検索する。サーバは、Getコマンドを配信することにより機器管理ツリーの構造をまず獲得し、機器管理ツリーの構造を通じて直接的に管理ノードを検索する。代替的に、端末は、(最初のDMセッションで報告されるか、1回だけ報告されるか、または、各セッションの中で報告される)セッション要求メッセージの中で管理ノードの位置をまず報告する。その後、サーバは管理ノードの値(すなわち、DDF)を獲得するためコマンドを配信し、値はその後の管理のための基礎として使用される。
第2の方法では、サーバは機器管理ツリーの中のDevDetailの位置をまず獲得し、以下の通り具体的に、DDFを獲得するようにDDF管理ノードの位置を間接的に検索する。サーバは、DDF管理ノードのMO(ここではDevDetail)の位置をまず獲得する。サーバは、Getコマンドを配信することにより機器管理ツリーの中のDevDetail MOの位置を検索するか、または、DevDetailの位置情報を端末のDevInfoに記憶する。端末は、セッション要求メッセージの中で、(最初のDMセッションの中で報告されるか、1回だけ報告されるか、または、各セッションで報告されることがある)DevDetail MOの位置(ルート・ノード・パス)をサーバへまず報告する。その後、サーバは、Getコマンドを配信することによって、値(すなわち、DDF)を獲得するように、DevDetail MOの位置情報および構造を通じてDDF管理ノードの位置を検索する。DDFはその後の管理のための基礎として使用される。
第3の方法では、ある一定のサーバアカウントが端末のため構成された後(たとえば、ブートストラップ後)、端末は最初にサーバへの登録セッション(端末とサーバとの間の最初のセッション)を開始する。DDFはこのセッションにおいて報告される。その後の管理セッションにおいて、DDFは、サーバが再獲得のためのGetコマンドを配信しない限り、最初に報告されない。
第4の方法では、端末はサーバの命令情報を受信する。命令情報はサーバによって送信された通知メッセージの中で伝達される。命令情報は、端末にDDF管理ノードに記憶された端末DMツリーのDDFまたは端末によってサポートされたある一定のMOのDDFを報告するよう命令する。その後、端末は、通知の中の情報に従って管理セッションを開始するセッション要求メッセージを生成する。DDFはセッション要求メッセージの中で伝達され、具体的な実行方法は以下の通りである。警告タイプは端末のため拡張される。警告タイプおよびDDFはAlertコマンドの中で伝達される。警告タイプがMOのDDFである場合、MOIDがさらに伝達されることができる。サーバは警告タイプおよびMOIDに従ってDDFを特定する。
DDFを獲得する2つの方法が、サーバに対応するDDFをサーバが見つけられない可能性があるという従来技術の課題を解決することができる。特に、DDFは比較的安定した情報であり、情報は大量であるので、頻繁なレポートはサーバおよびネットワーク伝送に負荷を引き起こす。これらの方法では、必要に応じて、サーバの情報を検索して獲得する能力を提供するように、端末が最初にある一定の条件下でDDFを報告するか、または、サーバが最初にノードを検索してDDFを獲得し、その結果、ネットワークおよびサーバへの負荷は、DDFを獲得する能力が提供されたままで、最大限に低減される。
2. 管理セッションはサーバと端末との間に確立可能であり、このことはサーバが端末のDMツリーへのオペレーションだけを実行可能であることを意味するに過ぎない。しかし、いくつかの機能は、SCOMOのような、具体的なMO、および、端末上の(DMアプリケーションと呼ばれる)クライアントプログラムに依存する必要がある。種々の端末が種々のDMアプリケーションをサポートし、これは、具体的なクライアントがその後の使用プロセスにおいて設置された後で配信または能力がサポートされる前は、異なる実施であってもよい。端末がある一定のDMアプリケーションをサポートするかどうかは、DMアプリケーション機能が達成可能であるかどうかの根拠となる。したがって、端末はサーバにサポートされているDMアプリケーションを通知することが必要である。サーバ管理の困難さは、端末によってサポートされているDMアプリケーション(すなわち、MOタイプ)をサーバが見分けられないために増大するという従来技術の課題を解決するため、本実施形態では、管理ノードが端末によってサポートされているDMアプリケーションを記録するために端末の管理ツリーに追加される。各ノードは端末によってサポートされるDMアプリケーションを記憶する。
図6を参照すると、本実施形態では、追加された管理ノードは、内部ノードおよびそのサブノードを含むように設計されることがある。たとえば、「SupportedApp」ノードは、DevInfoまたはDevDetail MOの中のノードでもよい内部ノードとして設定される。内部ノードのサブノード「x*」は、リーフノードであり、複数のインスタンスを有してもよい。各インスタンスはDMアプリケーションに対応する。端末は、このノードを端末の実際の条件に従って維持する。たとえば、ある一定のDMアプリケーションが端末に追加される場合、端末はSupportedAppノードの中にリーフノードを追加し、DMアプリケーションの情報を記憶する。各MOは対応するMOIDを有するので、たとえば、ファームウェアMOのMOIDは“urn:oma:mo:oma−fumo:1.0”であり、サポート対象MOのMOIDはノードに記憶され、すなわち、.../SupportedApp/<x>ノードの値はMOIDである。
DMアプリケーションに関して、端末がDMアプリケーションをサポートする限り、管理ツリーの中に存在するDMアプリケーションの個数(0または1または複数)とは無関係に、DMアプリケーションに関して1個のMOIDだけがサポート対象ノードの下で追加される。管理プロセスでは、端末によってサポートされたDMアプリケーションを獲得するステップは以下の通りである。
ステップAでは、サーバは、端末によってサポートされたDMアプリケーションが獲得されるべきであることを判定する。
ステップBでは、サーバはサブノードとサブノードの値とを獲得するためにGetコマンドを端末のDMツリーのSupportedAppノードへ送信し、端末は対応する結果を返送する。
ステップCでは、サーバは、端末によってサポートされたDMアプリケーションを判定するために取得されたノード値(MOID)を分析する。
本実施形態における方法は、サーバが端末によってサポートされたDMアプリケーションを認知しないという課題を解決することができ、この方法では、具体的な管理オペレーションは、サーバの管理をより柔軟かつ効率的にするため配信される。
3. 管理プロセスでは、サーバは、具体的な管理機能を実施するためにMOの中のノードに対しオペレーションを実行するように端末のMOを検索する必要がある。従来技術では、サーバが端末の管理ノードを検索することは非常に困難であり、エアリソースが消費され、サーバは大きな負荷を受ける。本開示では、サーバが端末のDMツリーの中でMOを検索する効率を改良するため、MOルートノードの位置を検索する方法が提供される。図7に示されているように、この方法は以下のステップを含む。
サーバはGetコマンドを端末へ送信する。Getコマンドは、獲得されるべきターゲット・オペレーション・パスの情報と値フィルタリング情報とを伝達する。
サーバのGetコマンドを受信した後、端末は、Getコマンドに対応した、指定されたサブツリーの構造情報およびノードの特性情報を獲得するよう命令される。特性値および構造情報はサーバへ返送される。
図7は、MOアドレス検索の実施形態だけを示している。具体的に、サーバは、Getコマンドを端末へさらに送信することができ、Getコマンドは、検索されるべきMOのIDを伝達し、検索されるべきサブツリーのルートノードのユニフォーム・リソース識別子(URI)および検索を命令するパラメータを伝達する。パラメータは端末に機器管理ツリーの中のMOのIDをMOのルートノードのURIへ返送するよう命令する。
Getコマンドの受信後、端末は、URI命令ノードとすべての内部サブノードの中でIDを満たすノードとを検索し、対応する結果をサーバへ返送する。
本実施形態では、MOアドレス検索は以下の3つのモードで具体的に実施される。
第1の方法では、管理ツリー構造が返送されるときに同時に特性値が伝達され、具体的には以下の通りであることができる。
サーバはGetコマンドを端末へ送信する。端末DMツリーの中のターゲット・オペレーション・ノードのパス情報はGetコマンドの“Target/LocURI”要素で伝達される。同時に、獲得されるべき値フィルタリング情報が伝達される。値フィルタリング情報は、端末に、機器管理ツリーの中でルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報と、サブツリーの中の各ノードの指定された特性の特性値とを返送するよう命令する。
伝達されるフィルタ情報のフォーマットは、<URI>?list=Struct+<property_name>であってもよい。複合パラメータ中の「Struct」は、端末に、機器管理ツリーの中でURIによって指示されたノードおよびこのノードのサブノードの構造情報を返送するよう命令する。構造は、端末によって返送されたノードの(“LocURI”の中で伝達される)URIによって表現される。複合パラメータの中の<property_name>は、ある一定のノードの特性名であり、端末に、URIによって指示されたノードおよびこのノードのサブノードの特性の特性値を返送するよう命令する。特性は、ノードタイプ特性、ノードACL特性、ノード値フォーマット特性、ノードタイトル特性、ノード値サイズ特性、ノード変更タイムスタンプ(TStamp)特性、または、ノードバージョン番号(VerNo)特性のような端末によってサポートされるいかなる特性であってもよい。使用例は以下の通りである。
サーバのGetコマンドの受信後、端末は、Getコマンドに従って指定サブツリーの構造情報およびノードの特性情報を獲得するよう命令され(獲得中に、サーバが管理ノードのACL権限、ここでは、具体的に取得権限(Get right)を有するかどうかが認証される)、次に、構造情報と共に特性値をサーバへ返送する。
特性情報は、Getコマンドに対応する「Result」コマンドの中で伝達される(異なるノードはResult要素の中の異なるItemサブ要素の中に分配されるか、または、それぞれが単一のItemを含む異なるResult要素に分配されることがある)。具体的な特性値は、Result/Item/Data要素の中で伝達され、返送されることができる。「Result」コマンドの中の“Source/LocURI”要素は、ノードURIと、特性名を指示するパラメータとを伝達する。その複合は、URI?prop=<proerty_name>である。コマンドの受信後、サーバは、ノードURIに従って機器管理ツリーの指定された部分の構造を分析し、?prop=<proerty_name>部分からDataの中で伝達される特性値に対応する特性名を取得し、データ要素から特性値を獲得する。用法は以下の通りである。
機器管理ツリーの中のMOのMOIDはMOルートノードのタイプ特性に記憶されるので、複合パラメータの<property_name>は、タイプ特性に設定され、サブツリー構造が返送されるときと同時に、サブツリーの中のすべてのMOIDを返送する。具体的に、サーバは、サブツリーの中の各ノードのタイプ特性の値を獲得した後に判定を行う。ノードが内部ノードであり、タイプ特性の値が空でない場合、ノードは、返送された情報からMOのルートノードのURIを獲得するため、MOのルートノードであり且つ空でないタイプ特性の値はMOIDであると判定される。MOのURIの獲得後、サーバは、MOの中のノードのより詳細な情報を獲得するためGetコマンドを送信するか、または、管理コマンドを直接的に送信する。
この方法は、サーバが、非直列化モードにおいて一括して機器管理ツリーの中のある一定の管理サブツリーの中のすべての管理ノードのうちのある一定の特性値を獲得しない可能性がある、という課題を解決することができる。この方法を通じて、ある一定の特性値は、サブツリー構造が獲得されたときに同時に獲得されることができるので、特性獲得のための相互作用は減少され、効率が増大される。同時に、管理サブツリーの中のすべてのMOは、特性値をタイプとして指定することにより獲得されることができるので、管理サブツリーの中のすべてのMOが効率的に獲得できない可能性がある、という課題が解決される。
第2の方法では、端末は、具体的なMOのルートノードを検索し、ルートノードのURIを返送する。具体的な実施形態は以下の事項を含む。
サーバはGetコマンドを端末へ送信する。検索されるべきMOの識別子(MOID)はGetコマンドにおいてItem/Data要素の中で伝達される。MOIDが検索されるサブツリーのルートノードのURIと、検索を命令するパラメータとが、Item/Target/LocURI要素の中で伝達される。パラメータは、端末に、Item/Taeget/LocURI要素によって提示された機器管理ツリーのサブツリーのItem/Data要素の中で伝達されるMOIDにより識別されるMOの出現するルートノードのURIを検索するよう命令する。サブツリーのルートノードのURIと検索を命令するパラメータとを伝達する情報のフォーマットは、URI?list=MO_ROOTでもよい。メッセージはDMメッセージの中で伝達される。コマンドの具体的な実施例は以下の通りである。
コマンドの受信後、端末は、サーバがACL権限(ここでは、Get権限)を有し、ノードがコマンドの中のルートノードURIとそのサブノードとに対応する場合に、ノードにおいてData要素の中で伝達されるMOIDの値をもつType特性を有するすべてのノードを検索し、結果(すなわち、検索されたノードのURI)をサーバへ返送する。検索プロセスは、内部ノードだけで実行され(すなわち、フォーマット特性はノードである)、リーフノードのためには実行されない。代替的に、端末は、<MOルートノード、MOI>記憶マッピング表を記憶する。サーバからのGetコマンドが受信された後、MO位置はマッピング表から即座に獲得され、結果がサーバへ返送される。結果を返送する方法は以下のステップを含む。
1) 検索条件を満たす1個以上のノードが見つけられる場合、Getコマンドのステータスの後、すべての検索結果(すなわち、MOの出現するルートノードURI)がResultコマンドを通じて返送される。異なるノードがResult要素の中の複数のItem要素の中に分配されてもよく、または、各々が単一のItemを含む異なる結果の中に分配されてもよい。結果は、MOIDを伝達してもよく、MOIDを伝達しなくてもよい。
MOIDを伝達する結果を返送する方法は以下の通りである。結果のItem/Target/LocURIは、端末によって検索されたノードのURIを伝達し、同時に、タイプ特性:?prop=Typeを含むパラメータを伝達し、MOIDがItem/Dataの中で伝達される。MOIDを伝達する結果を返送する方法は、対応するGetコマンドの中のItemの個数を制限することがなく、すなわち、サーバは、Getコマンドの中で端末から複数のMOIDに対応するMOの出現するルートノードURIを検索するため、同じGetコマンドの中で複数のItemを伝達することがある。具体的な使用例は以下の通りである。
MOIDを伝達しない結果の返送方法は以下の通りである。端末によって見つけられたノードのURIだけが、結果のItem/Target/LocURIの中で伝達される。MOIDを伝達しない結果の返送方法は、結果に対応するGetコマンドが1個のItemだけを伝達すること、すなわち、サーバがGetコマンドの中の端末から1個のMOIDに対応するMOの出現するルートノードURIを検索することを要求する。複数のItemが伝達される場合、サーバは返送された結果に対応するItemを識別することができない。使用例は以下の通りである。
MOのURIを獲得した後、サーバは、MOの中のノードのより詳細な情報を獲得するためGetコマンドを送信するか、または、管理コマンドを直接的に送信することがある。
2) 条件を満たすノードが見つからない場合(たとえば、Getコマンドの中のターゲットURIがリーフノードを参照するか、または、Getコマンドの中のターゲットURIが内部ノードを参照するとしても、ターゲットURIにルートがあるサブツリーの中のMOIDによって識別されたMOが発生しない場合)、結果は返送されず、「404 Not Found」がGetコマンドに対応する「Status」コマンドの中で返送される。
端末が具体的なMOのルートノードを検索し、ルートノードのURIを返送する第2の方法では、具体的なMOIDは指定されない可能性があり、すなわち、GetコマンドのItem要素はデータサブ要素を含まないことがある。コマンドを受信した後、端末は、ターゲットURIに対応するノードの下で、すべてのMOのMOIDとMOのルートノードURIとを検索し、結果を返送する。検索方法は以下の通りでもよい。ターゲットURIに対応するノードのすべての内部サブノードの中で、空でないタイプ特性値を有する(すなわち、ノードのFormat特性値がノードである)すべてのノードが検索されるか、または、マッピング表が端末で維持される。サーバのGetコマンドを受信するとき、端末はマッピング表の中で直接的に検索を行う。結果を返送する方法は、MOIDを伝達する結果を返送する方法と同じである。
第3の方法では、端末に対応する管理ツリーはサーバ側で維持される。Replace、Copy、DeleteおよびAddのような機器管理ツリーによって送信された管理ツリーノードを変更するコマンドに従って、オペレーションが成功したとき、サーバはサーバによって記憶されている対応する管理ツリーを維持する。機器管理ツリーの構造が取得される必要があるとき、サーバは、ターゲット・オペレーション・ノードのURIを判定するため、サーバ側で維持されたターゲット・オペレーション端末サブツリーの構造をまず獲得し、管理コマンドを生成し、コマンドをターゲット・オペレーション端末へ配信する。
本実施形態では、この方法は、サーバが、端末DMツリーの中でMOの位置を検索することが困難であるという課題を解決する。サーバが端末DMツリーの中でMOの位置を検索する作業は、サーバと端末との間で分担されるので、MOを検索する複雑なロジックは端末によってローカルに達成され、このことは、サーバが端末DMツリーの中でMOの位置を効果的に検索する効率を改良し、管理オペレーション中の相互作用を削減し、管理効率を改良し、サーバおよびネットワーク伝送への負荷を軽減する。
4. 管理プロセスでは、サーバによって端末へ配信された管理コマンドは、同じ管理コマンドが端末の複数の管理ノードで動作する機能を達成するために、複数のItemを伝達することがある。たとえば、Replaceの文法は、<!ELEMENT Replace(CmdID,NoResp?,Cred?,Meta?,Item+)>であり、すなわち、Replaceコマンドは、端末に、複数の管理ツリーノードのためのReplaceアクションを実行するよう命令するために、複数のItemを伝達する。ある場合には、複数のItemが端末で順次処理されるべきであり、ある場合には、非順次に処理されることがある。サーバは、端末に、管理コマンドの中の複数のItemを順次実行するように命令するため、実行が順次であるかどうかを判定する。
図8の実施形態に示されているように、以下のステップを含むコマンドの実行モードを管理する方法が提供される。
管理コマンドの中の複数のサブコマンドを順次実行する命令は、サーバによって送信された管理コマンドの中で伝達される。
管理コマンドの受信後、端末は、順次実行の命令を解析し、管理コマンドの中の各サブアイテムに対応する管理ノードで管理コマンドアクションを順次実行する。
具体的に、Itemを順次実行する命令は、サーバによって端末へ配信される管理コマンドの中で伝達される。伝達方法は以下の通りである(Replaceコマンドが実施例として採用され、他の管理コマンドの伝達方法はReplaceコマンドに類似している)。
特性はItem要素の親要素の中で伝達される。特性は、サブ要素が順次実行されることを示す。管理コマンドのReplaceを実施例として採用すると、Replaceのための命令特性を定義するDTDは、<!ATTLIST Replace order(Sequence|Any)“Any”>であってもよい。特性順序の値は以下の意味をもつ。“Any”は、端末の実行ノードが制限されないことを表現する。“Sequence”は、端末が順次実行のため命令されることを表現する。特性が追加された後の実施例は以下の通りである。
命令のサブ要素はItem要素の親要素の中に追加され(要素はItem要素の兄弟要素である)、サブ要素が追加された後のDTDは、<!ELEMNT Replace(CmdID,NoResp?,Cred?,Meta?,Order?,Item+)>として定義される。
シェル要素(すなわち、管理コマンドのサブ要素、および、同時にItemの親要素)は、Itemが順次実行されるため追加される。シェル要素は、シェルの中の要素が順次実行される必要がないことを端末に通知するだけである。
端末がReplaceコマンドの中で伝達されるアイテムを順次実行する命令を解析した後、Replaceコマンドはアイテム命令ノードのため順次実行される。
本実施形態における方法は、サーバが端末に管理コマンドの中の複数のターゲット・オペレーション・アイテムに対し管理コマンドを順次実行するよう命令しない可能性がある、という課題を解決することを目指し、この方法では、サーバは端末による管理コマンドの実行モードを柔軟に制御し、実行エラーの可能性を低下させることがある。
5. DMの管理アクションが実行される前に、管理セッションはまずサーバと端末との間に確立されることが必要である。すべての管理コマンドは管理セッションにおいて達成される。サーバまたは端末がアクションを処理するために長時間を要することがある。代替的に、管理アクションが近いうちに送信されるべきことが期待される。セッションを再確立するコストを削減するため、現在のセッションが維持されることがある。図9において実施形態に示されているように、以下のステップを含む管理セッションを維持する方法が提供される。
セッション維持コマンドが管理セッションの中で反対端へ送信されるべきことが判定されるとき、サーバまたは端末は、セッション維持コマンドを伝達するメッセージを反対端へ送信する。
メッセージの受信後、反対端は肯定応答メッセージを返送し、セッション維持コマンドに対応するオペレーションを実行する。
本実施形態では、以下の通り具体的に、2つの維持方法がセッションのため設計される。
セッション中の中断を回避するため、セッション維持コマンドが設計されることがある。セッション維持アクションが実行されるべきことが判定されるとき(たとえば、データ処理の所要時間が長いと判定されたとき)、サーバまたは端末は、“SyncML”メッセージを他の当事者へ送信する。メッセージはセッション維持コマンドを伝達し、他の当事者は肯定応答を用いて応答する。プロセスは、セッション維持コマンドの送信者が大量の管理コマンドを他の当事者へ送信するか、または、他の当事者にセッションを終了することを通知するまで、必要に応じて反復的に実行されることがある。セッション維持コマンドを伝達する“SyncML”メッセージが他の管理コマンドを含む場合、他の当事者はセッション維持コマンドを無視することができる。
図10において実施形態に示されているように、サーバがセッション維持コマンドを送信することを実施例として採用して、セッションを維持するプロセス(端末がセッション維持コマンドを送信するプロセスは類似しているので、その説明はここでは省略されている)が説明される。
ステップ21では、認証が端末およびサーバで実行され、管理セッションが端末とサーバとの間で確立される。
ステップ22では、DMコマンドの相互作用が両当事者のために実行される。
ステップ23では、サーバは、受信した管理コマンドを処理し、内部データ処理を実行し、セッションが待機する。
ステップ24では、サーバが、(サーバ内部の処理所要時間がセッション中断またはタイムアウトを引き起こす場合)セッションは維持されるべきであると判定したとき、サーバはセッション維持コマンドを送信する。
ステップ25では、端末は、セッション維持コマンド肯定応答メッセージを送信し、両当事者はサーバ側が新しい管理メッセージを送信するまでセッションを維持する。管理メッセージは管理コマンドもしくはセッション維持コマンドを伝達するか、または、管理メッセージは管理コマンドを伝達しない空メッセージである。
ステップ26では、サーバは端末データの処理を終了し、処理結果に従って端末へ送信されるべき管理コマンドを生成する。
具体的に、セッション維持コマンドはAlertコマンドを使用してもよく、新しいタイプコード“Alert Code”はAlertコマンドのため設計されてもよい。コードの意味は表4に示されている通りである。
コマンドの具体的な使用例は以下の通りである。
セッション維持コマンドは他のデータ(たとえば、Item)を伝達しないことがある。サーバによって送信されたセッション維持コマンドを受信した後、端末は大量の管理コマンドを実行することはなく、以下の通りの肯定応答メッセージがそのコマンドに対し返送される。
実施形態は、一方の当事者が、もう一方の当事者はセッションを維持するよう命令されるべきであると判定したとき、一方の当事者がセッション維持コマンドを反対端へ送信する課題を解決し、セッションの異常な中断を減少し、効率を改善する。
端末機器の管理はクライアント/サーバ(C/S)モードに属している。サーバは、管理アクションが配信されるべきであるかどうかと、配信されるべき管理アクションと、を判定する。サーバは支配的な地位にある。したがって、DMにおけるセッションの終了はサーバによって判定される。
本開示の実施形態では、セッションを終了させる命令をするコマンドが設計される。コマンドはサーバによって端末へ送信される。コマンドは端末へ配信されるべきパケットの中に別々に収容されるか、または、サーバによって端末へ配信されるべき管理コマンドの最終的なグループと共にパッケージ化され、その後に、端末へ送信されてもよい。前者のモードでは、端末はコマンドを受信した後にセッションを正常に終了する。後者のモードでは、端末は、まずパケットの中の他の管理コマンドを実行し、実行が完了した直後にセッションを終了し、関連した管理コマンドの実行結果はサーバへ返送されない。端末は、サーバが必要に応じて結果を獲得するように、最終的なパケットの中に管理コマンドの実行結果を一時的に記憶することもある。セッションを終了させる命令をするコマンドはAlertコマンドを通じて実施されてもよく、具体的なCodeは、Alertコマンドがセッションを正常に終了させることを命令するため設計される必要があり、たとえば、Codeは1210である。
従来技術では、セッションが終了されるべきであるかどうかを判定する方法は以下の通りである。端末は、サーバが空メッセージを送信した場合にセッションを終了する。命令は端末にとって不明確であり、端末の正確な管理に悪影響を与える。本実施形態で設計された具体的な終了命令コマンドは、端末の正確な管理を実現しやすくする。
6. 端末で、ある一定のMOは複数のインスタンスを有することが可能である。しかし、時々、MOインスタンスが一つのみアクティブ化される。たとえば、端末リソース・オペレーション・タイプのMOに対し、端末リソースは制限され、排他的であるので、複数のMOインスタンスが同時にまたはある一定の期間の範囲内に存在する場合、リソースは、1個のMOインスタンスだけによって占有されて作動(すなわち、アクティブ化)されることがある。他のMOインスタンスを通じてサーバによって配信された管理アクションは拒絶され、エラーコード403、405または500が返送される。従来技術では、複数のMOインスタンスが端末の中に存在するとき、サーバは現在アクティブ化されているインスタンスを認知しないので、サーバ管理の難しさが増加する。図11に示されているように、以下のステップを含む端末アクティブ化MOを取得する方法が提供される。
端末が端末リソースをMOインスタンスに割り当てるか、または、端末がMOインスタンスをアクティブ化して使用し、すなわち、MOインスタンスは現在利用できるMOとしての機能を果たす。
MOインスタンスをローカルに記録するとき、サーバは、端末アクティブ化MOを獲得するためにセッション管理プロセスの中でGetコマンドを端末へ送信する。端末はアクティブ化MOに関する情報をサーバへ返送する。
本実施形態では、現在アクティブ化されているMOインスタンス(すなわち、端末リソースを現在占有中であり、かつ、端末リソースを動作させることができるMO)を指示する2つの方法は以下の通りである。
端末はアクティブ化MOリストをローカルに維持する。アクティブ化MOリストは機器管理ツリーの中に表現されていない。サーバは、Getコマンドを端末のルートノードへ送信し、パラメータを伝達することによりデータを獲得する。
Getコマンドの中で伝達されるパラメータは、たとえば、.?list=ActivedResourceMOとして設計されてもよいGet/Item/Target/LocURLの中で伝達されてもよい。端末は、端末リソースに対応し、アクティブ化されたMOのルートノードのURIを返送する。サーバは、ある一定のタイプの具体的なMOを返送するよう端末に命令するために、コマンドのアイテムの中でデータ要素を伝達してもよく、データ要素の値はMOIDである。使用例は以下の通りである。
端末は、アクティブ化MOインスタンスの情報を管理ツリーに記憶し、具体的には以下の事項を含む。
a. 管理ツリーのサブツリーは機器管理ツリーの中に追加される。端末のすべてのアクティブ化MOのルートノードのURIリストは、管理ツリーのサブツリーに記憶される。追加された管理サブツリーは図12に示されている通りであり、アクティブ化MOリストが記憶される管理サブツリーはDevDetail MOに記憶されてもよい。サーバは、端末アクティブ化MOを取得するために、値を獲得するため直接的にGetコマンドをアクティブ化MOノードのサブノードに配信してもよい。具体的なコマンドおよびオペレーションは他のノードのコマンドおよびオペレーションに類似しているので、ここではそれらの説明は省略される。
b. MOインスタンスがアクティブ化MOインスタンスであるかどうかがMOインスタンスのルートノードのノード特性値に記録される。その後、サーバは、MOインスタンスがアクティブ化MOインスタンスであるかどうかを判定するために直接的にMOのルートノードの特性値を獲得する。具体的な方法は以下の通りである。
既存のMOのルートノードのタイプ特性値の構造が拡張される。変更された値構造は複合値を伝達することができる。複合値は、MOIDフィールドと、ActivatedまたはDeactivatedフィールドの2つのフィールドを含む。2つのフィールドはプラス符号で繋がれる。使用例は以下の通りである。
ある一定のMOのアクティブ化状態のルートノードのType特性値はMOID+Activatedである。
端末は、機器管理ツリーの中のMOのアクティブ化状態を判定し、MOのルートノードのタイプ特性値を維持する。
端末のアクティブ化MOを取得するとき、サーバは、値を獲得するためにGetコマンドをMOのルートノードのType特性に送信し、その後、MOインスタンスがアクティブ化MOであるかどうかを判定するためActivated/Deactivatedフィールドの値を抽出する。
本実施形態では、端末がアクティブ化MOを特定し、その後、サーバがアクティブ化MOを獲得する方法が提供され、アクティブ化MOが識別されないので、サーバがMOをアクティブ化するため即座にオペレーションを検索しない可能性があるという従来技術における課題を解決し、その結果、管理効率が改良される。
本開示は異なる形式で複数の特定の実施形態を有する。以下、本開示の技術的解決手段が図2ないし12を参照して説明される。これは、本開示の具体的な実施例が実施形態による具体的なプロセスまたは構造だけに限定されることを意味しない。当業者には上述された具体的な実施が多数の好ましい解決手段の中のいくつかの実施例に過ぎないことを理解されたい。
実施形態では、本開示は、第1の受信モジュールおよび構成モジュールを含むDM端末を提供する。第1の受信モジュールは、サーバのServerIDを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。
さらに、本実施形態は警告モジュールおよび第1の記録モジュールをさらに含んでもよい。警告モジュールは、端末のブートストラップまたは再ブートストラップのための警告情報を伝達するセッション要求メッセージをサーバへ送信するよう適合される。第1の記録モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末DMツリーの中のサーバのサーバアカウントMOの管理ノードに記録するよう適合される。
構成モジュールは、検索ユニット、第1の処理ユニット、および第2の処理ユニットを含む。検索ユニットは、ServerIDに対応するサーバアカウントMOが端末DMツリーの中に存在するかどうかを検索するよう適合する。第1の処理ユニットは、ブートストラップが反復ブートストラップまたは再ブートストラップであるかどうかを区別し、検索ユニットが端末DMツリーの中でServerIDに対応するサーバアカウントMOを見つけたときに、対応するオペレーションを実行するよう適合する。第2の処理ユニットは、検索ユニットが端末DMツリーの中のServerIDに対応するサーバアカウントMOを見つけることに失敗したとき、ブートストラップ情報に従って端末DMツリーの中のサーバのサーバアカウントMOを生成するよう適合される。
実施形態では、本開示は、第1の受信モジュールおよび認証モジュールを含むDM装置を提供する。第1の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを受信するよう適合される。認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。
実施形態では、本開示は、第1の送信モジュールおよび第1の獲得モジュールを含む別のDM装置を提供する。第1の送信モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末DMツリーの中のサーバアカウントMOに記録する管理ノードの値を獲得するためにGetコマンドを送信するよう適合される。第1の獲得モジュールは構成モード情報を獲得するよう適合される。
実施形態では、本開示は、端末およびサーバを含むブートストラップシステムを提供する。端末は、第1の受信モジュール、構成モジュール、および警告モジュールを含む。第1の受信モジュールは、サーバのServerIDを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。警告モジュールは、端末のブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを送信するよう適合される。サーバは第1の受信モジュールおよび認証モジュールを含む。第1の受信モジュールは、端末によって送信されたブートストラップまたは再ブートストラップの警告情報を伝達するセッション要求メッセージを受信するよう適合される。認証モジュールは、端末を認証するため警告情報に従って認証情報を生成するよう適合される。
実施形態では、本開示は、端末およびサーバを含む別のブートストラップシステムを提供する。端末は、第1の受信モジュール、構成モジュール、および第1の記録モジュールを含む。第1の受信モジュールは、サーバのServerIDを含むサーバのブートストラップ情報を受信するよう適合される。構成モジュールはブートストラップ情報を通じてブートストラップまたは再ブートストラップを実行するよう適合される。第1の記録モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末DMツリーの中のサーバのサーバアカウントMOの管理ノードに記録するよう適合される。サーバは、第1の送信モジュールおよび第1の獲得モジュールを含む。第1の送信モジュールは、端末のブートストラップまたは再ブートストラップの構成モード情報を端末DMツリーの中のサーバアカウントMOに記録する管理ノードの値を獲得するためにGetコマンドを送信するよう適合される。第1の獲得モジュールは構成モード情報を獲得するよう適合される。
実施形態では、本開示は、作成モジュールおよび第2の記録モジュールを含む別のDM端末を提供する。作成モジュールは管理ノードを端末のDMツリーに追加するよう適合される。第2の記録モジュールは、端末によってサポートされたDMオブジェクトタイプを端末のDMツリーに追加された管理ノードに記録するよう適合される。
実施形態では、本開示は、第2の獲得モジュールおよび決定モジュールを含む別のDM装置を提供する。第2の獲得モジュールは、端末との管理セッションにおいて端末のDMツリーに追加された端末によってサポートされたDMオブジェクトタイプを記録する管理ノードの値を獲得するよう適合される。決定モジュールは管理ノードの値に従って端末によってサポートされたDMオブジェクトタイプを判定するよう適合される。
実施形態では、本開示は、端末およびサーバを含む管理端末システムを提供する。端末は、作成モジュールおよび第2の記録モジュールを含む。作成モジュールは管理ノードを端末のDMツリーに追加するよう適合される。第2の記録モジュールは、端末によってサポートされたDMオブジェクトタイプを端末のDMツリーに追加された管理ノードに記録するよう適合される。サーバは、第2の獲得モジュールおよび決定モジュールを含む。第2の獲得モジュールは、端末との管理セッションにおいて端末のDMツリーに追加された端末によってサポートされたDMオブジェクトタイプを記録する管理ノードの値を獲得するよう適合される。決定モジュールは管理ノードの値に従って端末によってサポートされたDMオブジェクトタイプを判定するよう適合される。
実施形態では、本開示は、第2の受信モジュールおよび実行モジュールを含むDM端末をさらに提供する。第2の受信モジュールは、端末DMツリーのターゲット・オペレーション・ノードを伝達するパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報のGetコマンドとを受信するよう適合される。実行モジュールは、ターゲット・オペレーション・ノードのパス情報および値フィルタリング情報に従ってサブツリーの構造情報、および、サブツリーの中の各ノードの特性値を獲得し、特性値および構造情報を返送するよう適合される。
実施形態では、本開示は、第2の送信モジュールおよび第3の受信モジュールを含む別のDM装置を提供する。第2の送信モジュールは、端末DMツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報とを伝達するGetコマンドを送信するよう適合される。第3の受信モジュールは、サブツリーの構造情報と、端末によって返送されたサブツリーの中の各ノードの特性値とを受信するよう適合される。
実施形態では、本開示は、端末およびサーバを含み、管理ノード特性を獲得するシステムを提供する。端末は、第2の受信モジュールおよび実行モジュールを含む。第2の受信モジュールは、端末DMツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報のGetコマンドとを受信するよう適合される。実行モジュールは、ターゲット・オペレーション・ノードのパス情報および値フィルタリング情報に従って、サブツリーの構造情報、および、サブツリーの中の各ノードの特性値を獲得し、特性値および構造情報を返送するよう適合される。サーバは、第2の送信モジュールおよび第3の受信モジュールを含む。第2の送信モジュールは、端末DMツリーの中のターゲット・オペレーション・ノードのパス情報と、ルートとしてターゲット・オペレーション・ノードを有するサブツリーの構造情報を返送する命令、および、サブツリーの中のすべてのノードの指定された特性の特性値を返送する命令を含む獲得されるべき値フィルタリング情報とを伝達するGetコマンドを送信するよう適合される。第3の受信モジュールは、サブツリーの構造情報と、端末によって返送されたサブツリーの中の各ノードの特性値とを受信するよう適合される。
実施形態では、本開示は、第4の受信モジュールおよび検索モジュールを含む別のDM端末を提供する。第4の受信モジュールは、検索されるべきMOのIDと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のMOのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータとを伝達するGetコマンドを受信するよう適合される。検索モジュールは、検索されるべきサブツリーの中でMOを検索し、見つけられたMOのルート・ノード・パスを返送するよう適合される。
実施形態では、本開示は、第3の送信モジュールおよび第5の受信モジュールを含む別のDM装置を提供する。第3の送信モジュールは、検索されるべきMOのIDと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のMOのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータとを伝達するGetコマンドを送信するよう適合される。第5の受信モジュールは、端末によって返送された検索されるべきサブツリーの中のMOのルート・ノード・パスを受信するよう適合される。
本開示は、端末およびサーバを含み、MOアドレスを検索するシステムを提供する。端末は、第4の受信モジュールおよび検索モジュールを含む。第4の受信モジュールは、検索されるべきMOのIDと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のMOのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータと、を伝達するGetコマンドを受信するよう適合される。検索モジュールは、検索されるべきサブツリーの中でMOを検索し、見つけられたMOのルート・ノード・パスを返送するよう適合される。サーバは、第3の送信モジュールおよび第5の受信モジュールを含む。第3の送信モジュールは、検索されるべきMOのIDと、機器管理ツリーの中で検索されるべきサブツリーのルート・ノード・パスに関する情報と、検索されるべきサブツリーの中のMOのルート・ノード・パスを検索し返送するよう端末に命令する検索命令パラメータと、を伝達するGetコマンドを送信するよう適合される。第5の受信モジュールは、端末によって返送された検索されるべきサブツリーの中のMOのルート・ノード・パスを受信するよう適合される。
当業者には、実施形態による方法のステップの全部または一部が関連したハードウェアに命令するプログラムによって実施されることがあることを理解されたい。プログラムはコンピュータ読み取り可能な媒体に記憶されることができる。プログラムが実行されるとき、実施形態による方法のステップが実行される。記憶媒体は、リード・オンリ・メモリ(ROM)、ランダム・アクセス・メモリ(RAM)、磁気ディスクまたは光ディスクのようなプログラムコードを記憶することができる媒体であればどのような媒体であってもよい。
最後に、上記実施形態は本開示の技術的解決手段を単に説明するために与えられているだけであり、本開示を限定することを意図しないことに注意を要する。本開示は実施形態を参照して詳細に記載されているが、本開示の精神および範囲から逸脱しない限り、実施形態に記載された技術的解決手段に対する変更、または、技術的解決手段のいくつかの技術的特徴に対する等価的な置換が行われることがあることが当業者には理解されたい。
Claims (19)
- サーバと端末との間に管理セッションを確立し、
前記サーバによって、検索されるべき管理オブジェクトの識別子(MOID)を伝達するItem/Data要素を伝達し、機器管理ツリーの中のサブツリーのルートノードURIを伝達するItem/Target/LocURI要素と、前記サブツリーの中の管理オブジェクト(MO)の出現する前記ルートノードURIを検索して返送するよう前記端末に命令する検索命令パラメータとを伝達するGetコマンドを前記端末へ送信し、
前記端末によって、前記Getコマンドを受信し、前記サブツリーの中で前記サーバによりアクセス権限が保有されている前記MOの出現を検索し、前記サブツリーの中で前記サーバによりアクセス権限が保有されている前記MOの出現を検索することは、前記サーバによるGet権限を保有するすべてのノードであって、且つ、前記コマンドの中の前記ルートノードURIに対応する前記ノードおよびそのサブノードにおいて前記Data要素で伝達される前記MOIDの値をもつType特性を有するすべてのノードを前記端末によって検索することを含み、
前記端末によって、前記端末が前記MOの1回以上の出現を見つけたとき、前記Getコマンドのステータス情報と、前記ステータス情報の後に続いて前記見つけられたMOの前記ルートノードURIとを前記サーバへ返送する、
ことを備える、機器管理の方法。 - 前記端末によって、前記見つけられたMOの前記ルートノードURIを前記サーバへ返送することが、
前記端末が前記MOの1回以上の出現を見つけたとき、前記端末によって、Resultコマンドの複数の「Item」要素で伝達されるか、または、単一の「Item」要素を含む複数のResultコマンドで伝達される前記見つけられたMOの前記ルートノードURIを返送することを含み、前記MOIDは返送されない
請求項1に記載の方法。 - 前記検索命令パラメータが前記Getコマンドの前記Item/Target/LocURI要素の「リスト」コマンドとして前記端末へ配信される請求項1に記載の方法。
- 前記サーバと前記端末との間に前記セッションを確立する前に、
SmartCardモードにおいて前記端末の前記機器管理ツリーへの前記サーバのアカウント情報を含むブートストラップ情報を構成することをさらに備える
請求項1に記載の方法。 - 前記サーバによって、OTAモードにおいて前記アカウント情報のパスワードおよびノンスのうち少なくとも一つを更新するためにDMコマンドを前記端末へ配信し、
前記端末によって、前記端末の前記機器管理ツリーのDMAcc MOに保存されたパスワードおよびノンスのうちの少なくとも一つを更新するために前記サーバからDMコマンドを受信し、
前記端末によって、前記端末の前記機器管理ツリーの前記DMAcc MOに保存された前記パスワードおよびノンスのうちの少なくとも一つの更新後にSmartCardオペレーションコマンドを通じて自動的に前記SmartCardのブートストラップファイルの中の対応するパスワードおよびノンスのうちの少なくとも一つを更新する、
ことをさらに備える請求項4に記載の方法。 - 前記端末によって、前記更新されたブートストラップファイルを用いてその後のブートストラップを実行し、
前記サーバによって、前記サーバと前記更新されたブートストラップファイルによってブートストラップされた前記端末との間に前記管理セッションを確立するとき、前記更新されたパスワードおよびノンスのうちの少なくとも一つを用いて前記端末を認証する、
ことをさらに備える請求項5に記載の方法。 - 前記端末によりサポートされたDM MOのタイプを前記機器管理ツリーの中の追加された管理ノードに記憶し、
前記サーバと前記端末との間に前記管理セッションを確立した後に、
前記サーバによって、前記管理ノードに記憶された値を検索し、前記管理ノードに記憶された前記値に従って前記端末によりサポートされたDM MOのタイプを判定する、
ことをさらに備える請求項1に記載の方法。 - 前記端末によりサポートされたDM MOのタイプを追加された管理ノードに記憶することが、
前記端末によりサポートされたDM MOのタイプを記憶するため管理ノードを追加し、
前記端末によりサポートされたDM MOの識別子を前記追加された管理ノードに記憶する、
ことを含む請求項7に記載の方法。 - 前記管理ノードが前記DMツリーの中のDevDetail MOに追加され、
前記サーバによって、前記管理ノードに記憶された値を検索することが、
前記サーバによって、Getコマンドを、前記管理セッションにおいて前記端末の前記機器管理ツリーの前記DevDetail MOの中の追加された管理ノードへ送信し、
前記端末によって、前記Getコマンドに従って前記管理ノードに記憶された値を返送する、
ことを含む請求項8に記載の方法。 - 検索されるべき管理オブジェクト(MO)の識別子(ID)(MOID)を伝達するItem/Data要素、機器管理ツリーの中のサブツリーのルートノードURIを伝達するItem/Target/LocURI要素、および、前記サブツリーの中の前記MOの出現する前記ルートノードURIを検索して返送するよう端末に命令する検索命令パラメータを伝達するGetコマンドを受信するよう適合された受信モジュールと、
サーバが前記サブツリーの中でアクセス権限を有する前記MOの出現を検索し、前記サブツリーの中で前記サーバがアクセス権限を保有する前記MOの出現を検索することが、前記サーバがGet権限を保有するすべてのノードであって、且つ、前記Getコマンドの中の前記ルートノードURIに対応する前記ノードおよびそのサブノードにおいて前記Data要素で伝達されるMOIDの値をもつType特性を有するすべてのノードを検索することを含み、前記MOの1回以上の出現を見つけたとき、前記Getコマンドのステータス情報と、前記ステータス情報の後に続いて前記見つけられたMOの前記ルートノードURIとを前記サーバへ返送するよう適合された検索モジュールと、
を備える、機器管理(DM)端末。 - 前記端末によりサポートされたDM MOのタイプを前記端末の前記DMツリーの中の追加された管理ノードに記憶するよう適合された記録モジュールをさらに備える請求項10に記載の端末。
- SmartCardモードにおいて前記端末の前記機器管理ツリーへの前記サーバのアカウント情報を含むブートストラップ情報を構成するモジュールをさらに備える
請求項11に記載の端末。 - 前記端末の前記機器管理ツリーのDMAcc MOに保存されたパスワードおよびノンスのうちの少なくとも一つを更新するために前記サーバからDMコマンドを受信するよう適合されたモジュールと、
前記端末の前記機器管理ツリーの前記DMAcc MOに保存された前記パスワードおよびノンスのうちの少なくとも一つの更新後にSmartCardオペレーションコマンドを通じて自動的に前記SmartCardのブートストラップファイルの中の対応するパスワードおよびノンスのうちの少なくとも一つを更新するよう適合されたモジュールと、
をさらに備える請求項12に記載の端末。 - 前記更新されたブートストラップファイルを用いてその後のブートストラップを実行するよう適合されたモジュールと、
前記サーバによって、前記サーバと前記更新されたブートストラップファイルによってブートストラップされた前記端末との間に前記管理セッションを確立するとき、前記更新されたパスワードおよびノンスのうちの少なくとも一つを用いて前記端末を認証するよう適合されたモジュールと、
をさらに備える請求項13に記載の端末。 - 前記端末によりサポートされたDM MOのタイプを前記機器管理ツリーの中の追加された管理ノードに記憶するよう適合されたモジュールを更に備える
請求項13に記載の端末。 - 前記端末によりサポートされたDM MOのタイプを追加された管理ノードに記憶するモジュールが、更に、
前記端末によりサポートされたDM MOのタイプを記憶するため管理ノードを追加するよう適合されたモジュールと、
前記端末によりサポートされたDM MOの識別子を前記追加された管理ノードに記憶するよう適合されたモジュールと、
を備える請求項15に記載の端末。 - 機器管理ツリーの中のサブツリーの中でサーバによりアクセス権限が保有されているMOの出現を端末によって検索させ、該アクセス権限が保有されているMOの出現を検索することは、サーバによるGet権限を保有するすべてのノードであって、且つ、Getコマンドの中のルートノードURIに対応するノードおよびそのサブノードにおいてData要素で伝達されるMOIDの値をもつType特性を有するすべてのノードを検索することを含み、前記端末が前記MOの1回以上の出現を見つけたとき、Getコマンドのステータス情報と、前記ステータス情報の後に続いて前記見つけられたMOのルートノードURIとを前記サーバへ前記端末によって返送させるため、検索されるべき管理オブジェクト(MO)の識別子(ID)(MOID)を伝達するItem/Data要素と、機器管理ツリーの中のサブツリーのルートノードURIを伝達するItem/Target/LocURI要素と、前記サブツリーの中の前記MOの出現する前記ルートノードURIを検索して返送するよう端末に命令する検索命令パラメータとを伝達するGetコマンドを送信するよう適合された送信モジュールと、
前記端末によって返送された前記Getコマンドのステータス情報と前記サブツリーの中の前記MOの出現する前記ルートノードURIとを受信するよう適合された受信モジュールと、
を備える、機器管理(DM)装置。 - 管理セッションにおいて前記端末の前記DMツリーの中で前記端末によりサポートされたDM MOのタイプを記録する追加された管理ノードに記憶された値を獲得するよう適合された第2の獲得モジュールをさらに備える請求項17に記載の装置。
- 請求項10〜16のいずれか1項に記載の端末と、
請求項17または18に記載の装置と、
を備える機器管理のシステム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200810057697.0 | 2008-02-04 | ||
CN2008100576970A CN101505550B (zh) | 2008-02-04 | 2008-02-04 | 设备管理的方法和终端、装置、系统 |
PCT/CN2008/071785 WO2009100632A1 (zh) | 2008-02-04 | 2008-07-28 | 设备管理的方法和终端、装置、系统 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2011517792A JP2011517792A (ja) | 2011-06-16 |
JP5095831B2 JP5095831B2 (ja) | 2012-12-12 |
JP5095831B6 true JP5095831B6 (ja) | 2013-03-27 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9246781B2 (en) | Method, terminal, apparatus, and system for device management | |
US9615346B2 (en) | Method and apparatus for notifying information change in wireless communication system | |
US8139509B2 (en) | Installation and management of mobile device [{S]} configuration | |
EP1782189B1 (en) | Device management system | |
US8051186B2 (en) | Method for device capability negotiation, method, system and device for synchronization | |
CN102136934B (zh) | 实现Zigbee设备远程升级的方法、装置及网络系统 | |
US20110173685A1 (en) | Method for terminal configuration and management and terminal device | |
KR100896942B1 (ko) | 이동 장치들 및 서비스들을 다루기 위한 통합된 방법 및장치 | |
JP2007525870A (ja) | 装置管理システム内における管理ノードの指定 | |
WO2008022195A1 (en) | Device management system for mobile devices that supports multiple-point transport | |
KR20080087891A (ko) | 의존성 통지 | |
KR20050117936A (ko) | 장치 관리 기술에서의 장치 관리 시스템 및 방법 | |
CN104883266A (zh) | 网络配置访问方法及装置 | |
US20130346610A1 (en) | Device Management Method and Apparatus | |
US9438603B2 (en) | Method for managing access right of terminal to resource by server in wireless communication system, and device for same | |
CN112307486B (zh) | 一种权限获取方法、设备和系统 | |
CN102571418B (zh) | 设备管理的方法 | |
WO2010124571A1 (zh) | 节点信息获取方法、客户端、服务器 | |
US20120254393A1 (en) | Device management method, device management apparatus, and device management system | |
JP5095831B6 (ja) | 機器管理の方法、端末、装置およびシステム | |
US10084748B2 (en) | Method and apparatus for requesting or providing resource by terminal of server in wireless communication system | |
US9762465B2 (en) | Method and apparatus for transmitting a response to a command in wireless communication system | |
CN102572957B (zh) | 设备管理的方法和终端、装置、系统 | |
Alliance | Gateway management object technical specification | |
KR20100067332A (ko) | 의존성 통지 |