JP5873782B2 - 端末管理装置、端末管理システム - Google Patents

Description

本発明は、端末を遠隔管理する技術に関する。

組込機器の品質保証や保守費用削減のため、組込機器はその種別に応じた通信プロトコルによって遠隔管理される。例えば、携帯電話のような移動体通信機器は、ＯＭＡ−ＤＭ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ − Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）プロトコルによって管理され、ブロードバンドルーターのような固定通信機器は、ＴＲ−０６９（Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ０６９）プロトコルによって管理される（非特許文献１、２）。

ＯＭＡ−ＤＭや、ＴＲ−０６９の関連仕様であるＴＲ−１０６は、端末のＩＤや端末内のソフトウェア情報等のインベントリをツリー構造で管理することを規定している。端末制御命令は、ツリー内の特定ノードの属性値を変更することによって実現される。具体的には、ソフトウェアの状態を表すＳｔａｔｅノードを用意し、ソフトウェアの停止状態を指定する属性値であるｉｄｌｅを端末制御命令によってそのノードに格納する。これにより、端末内のソフトウェアをその属性値に対応する状態に変更する遠隔管理命令が発行される。端末制御命令を追加する場合は、端末に新たなツリーを追加し、そのツリー内のデータを解釈することができるツリー操作プログラムを端末に追加すればよい。すなわち、端末と端末管理サーバ間の通信プロトコルを修正する必要がないため、ツリー形式で制御データを記述する遠隔管理方式は高い拡張性を有すると考えられている。

下記特許文献１では、管理プロトコルが異なる複数種類の端末を、端末管理サーバから共通の管理プロトコルで管理するシステムが記載されている。このシステムでは、固定通信機器については、ＴＲ−０６９プロトコルで管理する。端末管理サーバは、宅内にある固定通信機器とプロトコル変換機能を有するサーバを経由し、移動体通信機器に端末制御命令を送信する。端末管理サーバの端末制御命令は、プロトコル変換機能によって、ＴＲ−０６９プロトコルから移動体端末専用の管理プロトコルに変換されるため、端末管理サーバは、ＴＲ−０６９プロトコルのみによって、異なる種類の端末を管理できる。

遠隔管理システムとしての拡張性を担保するためには、端末側だけでなく、端末管理サーバ側のデータ構造も拡張性が必要になると考えられる。データ構造に拡張性を持たせる技術の例として、下記特許文献２では、ツリー構造を持つＸＭＬ文書をＲＤＢ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ）へマッピングする技術が記載されている。同文献に記載されている技術では、ＸＭＬ文書に属する各要素を、階層レベルと親ノード情報とともにＲＤＢへ格納することにより、ＲＤＢ内のデータをＸＭＬ文書として読み出すことができる。

特表２０１２−５０２５７８公報 特願２００４−１１１９７９公報

Open Mobile Alliance、URL：http://www.openmobilealliance.org/default.aspx（２０１２年２月１４日取得） broadband forum、URL：http://www.broadband-forum.org/（２０１２年２月１４日取得）

特許文献２に記載されている技術では、ＲＤＢの１レコードにつき、ツリーの１要素とそのツリー内における位置情報を格納する。そのため、要素間の関連に基づきデータを検索するためには、検索処理を複数回繰り返さなければならない。例えば、ソフトウェアＡのＳｔａｔｅがｉｄｌｅである端末を検索する場合、ソフトウェアＡとｉｄｌｅを検索条件として位置情報を検索し、端末ＩＤが格納された要素に辿り着かなければならない。ＲＤＢは関連のある情報を１レコードに格納することにより、高い検索性能を発揮できるＤＢであるので、特許文献２に記載されているようなデータ構造では、ＲＤＢの検索性能を十分には発揮できないと考えられる。

本発明は、上記のような課題を解決するためになされたものであり、ツリー形式で稼動状態情報を記述する遠隔管理プロトコルを用いる場合において、ツリー形式の拡張性を保持しつつ、データツリーを格納するＤＢの検索性能を向上させることを目的とする。

本発明に係る端末管理装置は、端末の稼動状態情報を記述するデータツリー上の少なくともいずれかのノード毎に１つ管理テーブルを備え、さらに、管理テーブルに対して稼動状態情報を書き込むテーブル操作プログラムを管理テーブル毎に備えている。

本発明に係る端末管理装置によれば、ツリー形式による拡張性を利用することによって管理対象項目を動的に拡張できるようにしつつ、データツリーの検索性能を向上させることができる。

実施形態１に係る端末管理システム１０００の構成図である。 管理対象端末２００の稼動状態情報を記述するためのデータツリーの例を示す図である。 基本情報管理テーブル１４１の構成とデータ例を示す図である。 アプリケーション情報管理テーブル１４２の構成とデータ例を示す図である。 端末管理エージェント２１０に対して端末管理プラグイン２２０内のサブプログラムを登録する処理を説明するシーケンス図である。 端末管理サーバ１００が管理対象端末２００から稼動状態情報を記述したデータツリーを収集する処理を説明するシーケンス図である。 データツリー操作プログラム１２１がデータツリーをサーバ側データツリー格納部１４０に格納する処理を説明するシーケンス図である。 管理者が管理者端末３００を用いて管理対象端末２００のアプリケーション状態を参照する処理を説明するシーケンス図である。 データツリー操作プログラム１２１がデータツリー内から指定されたレコードを検索する処理を説明するシーケンス図である。 端末管理サーバ１００が管理対象端末２００に対して制御命令を発行する処理を説明するシーケンス図である。 コマンド管理テーブル１５０の構成とデータ例を示す図である。 端末管理サーバ１００が発行した制御命令を管理対象端末２００が実行する処理を説明するシーケンス図である。 実施形態２に係る端末管理システム１０００の構成図である。 管理対象端末２００のファームウェア情報を管理する機能を端末管理システム１０００に追加する処理を説明するシーケンス図である。 ステップＳ１４０５において端末管理サーバ１００が発行する制御命令を格納したコマンド管理テーブル１５０の構成を例示する図である。 ＦａｒｍｗａｒｅＩｎｆｏツリーの１例を示す図である。 ファームウェア情報管理テーブル１４３の構成とデータ例を示す図である。

＜実施の形態１＞
図１は、本発明の実施形態１に係る端末管理システム１０００の構成図である。端末管理システム１０００は、管理対象端末２００の稼動状態情報を管理し、管理対象端末２００に対して制御命令を発行するシステムであり、端末管理サーバ１００（端末管理装置）、管理者端末３００を有する。これら機器は、ネットワークを介して接続されている。以下の説明では記載の便宜上、各プログラムを動作主体として説明する場合があるが、実際にこれらプログラムを実行するのはＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などの演算装置であり、プログラムを搭載した機器はこれを実行する演算装置を備えているものとする。

管理対象端末２００は、端末管理システム１０００の管理対象となる端末であり、端末管理エージェント２１０（端末管理部）、端末管理プラグイン２２０、端末側データツリー格納部２３０を備える。

端末管理エージェント２１０は、端末管理サーバ１００に対して当該端末の稼動状態情報を送信し、端末管理サーバ１００から制御命令を受信するプログラムである。端末管理プラグイン２２０は、端末管理エージェント２１０を介して、端末管理サーバ１００に対して当該端末の稼動状態情報を送信し、端末管理サーバ１００から制御命令を受信して実行するプログラムである。端末管理プラグイン２２０は、管理対象となる稼動状態情報に対応したサブプログラムを有する。ここでは、後述するＡｐｐｌｉｃａｔｉｏｎＩｎｆｏに対応するアプリケーション管理プログラム２２１と、ＤｅｖｉｃｅＩｎｆｏ項目に対応する基本情報管理プログラム２２２を例示した。端末側データツリー格納部２３０は、管理対象端末２００の稼動状態情報をツリー形式で記述したデータツリーを記憶する記憶装置である。

端末管理サーバ１００は、管理対象端末２００の稼動状態情報を収集・管理し、管理者端末３００からの指令に基づき、管理対象端末２００に対して制御命令を発行する。制御命令の例としては、アプリケーションのインストール、起動・停止などが挙げられる。端末管理サーバ１００は、先述のＯＭＡ−ＤＭのようにツリー形式で稼動状態情報を記述する遠隔管理プロトコルを用いて、管理対象端末２００の稼動状態情報を取得し、または管理対象端末２００に対して制御命令を発行する。

端末管理サーバ１００は、管理者端末通信プログラム１１１、管理対象端末通信プログラム１１２、データツリー操作プログラム１２１、コマンド操作プログラム１２２、サブツリー操作プログラム１３０、サーバ側データツリー格納部１４０、コマンド管理テーブル１５０を備える。

管理者端末通信プログラム１１１は、管理者端末３００から指令を受信するプログラムである。管理対象端末通信プログラム１１２は、管理対象端末２００から稼動状態情報を受信し、管理対象端末２００に対して制御命令を送信するプログラムである。データツリー操作プログラム１２１は、サーバ側データツリー格納部１４０が格納しているデータツリーに対する読込要求や書込要求を受け取り、サブツリー操作プログラム１３０内の対応するプログラムにその要求を振り分けるプログラムである。サブツリー操作プログラム１３０は、サーバ側データツリー格納部１４０が格納しているデータツリーを読み込み、またはデータを書き込むプログラムである。サブツリー操作プログラム１３０は、端末管理プラグイン２２０が備えるサブプログラムに対応するサブプログラムとして、基本情報操作プログラム１３１とアプリケーション情報操作プログラム１３２を備える。サーバ側テータツリー格納部１４０については後述する。コマンド操作プログラム１２２は、管理対象端末２００に対する制御命令をツリー形式で記述してコマンド管理テーブル１５０に格納する。コマンド管理テーブル１５０の具体例については後述する。

管理者端末３００は、管理対象端末２００を管理する管理者が使用する端末であり、管理対象端末２００の状態監視、アプリケーション起動・停止などの遠隔制御などの処理を実行する。管理者端末３００は、端末操作プログラム３１０を備える。端末操作プログラム３１０は、端末管理サーバ１００から管理対象端末２００の稼動状態情報を取得してディスプレイなどに表示し、管理対象端末２００に対する制御指令を入力するユーザインターフェースを提供する。

図２は、端末管理サーバ１００と管理対象端末２００が使用する遠隔管理プロトコルにおいて使用される、管理対象端末２００の稼動状態情報を記述するためのデータツリーの例を示す図である。データツリーは、ツリーのパスによって属性値を指定できるように構成された、データの論理構造である。データツリーは、管理対象端末２００から取得した稼動状態情報を記述するために使用することもできるし、管理対象端末２００に対する制御命令を記述するために使用することもできる。

図２に示すデータツリーは、管理対象端末２００の基本情報を格納するＤｅｖｉｃｅＩｎｆｏサブツリーと、管理対象端末２００にインストールされているアプリケーションの属性情報を格納するＡｐｐｌｉｃａｔｉｏｎＩｎｆｏサブツリーを有する。ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏサブツリーは、管理対象端末２００にインストールされているアプリケーションと同数の子ノードを持ち、それぞれの子ノードは属性値として、アプリケーションのＩＤであるＡｐｐＩＤ、起動・停止状態を表すＳｔａｔｕｓ、アプリケーションのバージョンを表すＶｅｒｓｉｏｎを有する。ツリーのパスとして、／ＤｅｖｉｃｅＩｎｆｏ／ＤｅｖｉｃｅＩＤを指定すると、属性値Ｄ００００１を取得し、または更新することができる。

アプリケーション管理プログラム２２１はＡｐｐｌｉｃａｔｉｏｎＩｎｆｏサブツリーの属性値を取得または更新し、基本情報管理プログラム２２２はＤｅｖｉｃｅＩｎｆｏサブツリーの属性値を取得または更新する。端末管理エージェント２１０は、管理対象端末２００に対して稼動状態情報の取得または更新を指示する命令を受信すると、その命令の宛先に対応する端末管理プラグイン２２０内のサブプログラムに命令を振り分ける。

図３は、基本情報管理テーブル１４１の構成とデータ例を示す図である。基本情報管理テーブル１４１は、ＤｅｖｉｃｅＩｎｆｏサブツリーの値を格納するテーブルであり、同サブツリーが有する各属性値に対応するフィールドを有する。

図４は、アプリケーション情報管理テーブル１４２の構成とデータ例を示す図である。アプリケーション情報管理テーブル１４２は、ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏサブツリーの値を格納するテーブルであり、同サブツリーが有する各属性値に対応するフィールドを有する。ただし、個々の管理対象端末２００を識別するため、これらフィールドに加えてＤｅｖｉｃｅＩＤフィールドも備えている。

基本情報管理テーブル１４１とアプリケーション情報管理テーブル１４２は、図２に示すデータツリーのうち一部のノードを抽出し、ＲＤＢのスキーマ形式によって記述したテーブルである。ＲＤＢの形式でデータを格納することにより、ＲＤＢの検索性能を利用してデータツリーを検索することができる。データ項目を拡張する場合は、新たに追加するツリーノードに対応するテーブルを設け、同テーブルに対応するサブプログラムをサブツリー操作プログラム１３０と端末管理プラグイン２２０に追加すればよいので、ツリー形式の拡張性もそのまま利用することができる。

端末管理サーバ１００は、例えばＡｐｐＩＤ＝Ａ００１のＳｔａｔｕｓをｉｄｌｅからａｃｔｉｖｅに変更するコマンドを管理対象端末２００に対して発行することにより、停止状態にある管理対象端末２００上のアプリケーションＡ００１を起動させることができる。

以上、端末管理システムの構成について説明した。以下では、端末管理システムの動作例について説明する。必要に応じて、具体例として、図２〜図４に記載しているデータを用いる。

図５は、端末管理エージェント２１０に対して端末管理プラグイン２２０内のサブプログラムを登録する処理を説明するシーケンス図である。端末管理エージェント２１０は、端末管理サーバ１００から稼動状態情報を取得または更新する命令を受け取ると、対応するサブプログラムに命令を振り分ける必要がある。このときの対応関係をあらかじめ定義しておく処理を、登録と呼ぶことにする。以下、図５の各ステップについて説明する。
（図５：ステップＳ５０１）
端末管理プラグイン２２０内のサブプログラムは、自身のプログラムパスと、管理するデータツリーのルートパスを、端末管理エージェント２１０に登録する。プログラムパスとは、端末管理プラグイン２２０のインスタンスが格納されるメモリ上のアドレスである。ルートパスとは、サブツリーのルートノード名である。例えばＤｅｖｉｃｅＩｎｆｏツリーであればＤｅｖｉｃｅＩｎｆｏ、ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏツリーであればＡｐｐｌｉｃａｔｉｏｎＩｎｆｏとなる。
（図５：ステップＳ５０１：補足）
組込機器向けＪａｖａプラットフォームであるＯＳＧｉでは、任意の文字列によるインスタンスの登録・検索機能であるＳｅｒｖｉｃｅＴｒａｃｋｅｒを設けているので、端末管理エージェント２１０と端末管理プラグイン２２０がＯＳＧｉ上で動作するＯＳＧｉバンドルとして実装されている場合は、その機能を利用して本ステップを実施することができる。例えば、基本情報管理プログラム２２２は、自身に対応する命令を表す文字列としてＤｅｖｉｃｅＩｎｆｏを指定し、自身のインスタンスをＳｅｒｖｉｃｅＴｒａｃｋｅｒに登録する。以後、端末管理エージェント２１０は、文字列「ＤｅｖｉｃｅＩｎｆｏ」を指定することにより、基本情報管理プログラム２２２のインスタンスを検索し、その機能を呼び出すことができる。

（図５：ステップＳ５０２）
端末管理エージェント２１０は、端末管理プラグイン２２０内の対応するサブプログラムに対し、管理しているデータツリーを送信するよう要求する。
（図５：ステップＳ５０３）
端末管理プラグイン２２０内のサブプログラムは、自身が管理するデータツリーを端末管理エージェント２１０に送信する。基本情報管理プログラム２２２はＤｅｖｉｃｅＩｎｆｏツリーを送信し、アプリケーション管理プログラム２２１はＡｐｐｌｉｃａｔｉｏｎＩｎｆｏツリーを送信する。
（図５：ステップＳ５０４）
端末管理エージェント２１０は、ステップＳ５０３で受信したデータツリーを端末側データツリー格納部２３０に格納する。

図６は、端末管理サーバ１００が管理対象端末２００から稼動状態情報を記述したデータツリーを収集する処理を説明するシーケンス図である。以下、図６の各ステップについて説明する。
（図６：ステップＳ６０１）
端末管理エージェント２１０は、データツリーを端末側データツリー格納部２３０から読み込む。このとき読み込む値は、ツリーのパスと値のペアである。図２に示したデータツリーを例にすると、パス／ＤｅｖｉｃｅＩｎｆｏ／ＤｅｖｉｃｅＩＤと値Ｄ００００１、パス／ＤｅｖｉｃｅＩｎｆｏ／Ｍａｎｕｆａｃｔｕｒｅｒと値ＣｏｍｐａｎｙＡ、パス／ＤｅｖｉｃｅＩｎｆｏ／Ｍｏｄｅｌと値ＳｍａｒｔＰｈｏｎｅ、パス／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００１／ＡｐｐＩＤと値Ａ００１、パス／ＤｅｖｉｃｅＩｎｆｏ／Ｓｔａｔｕｓと値ｉｄｌｅ、パス／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００１／Ｖｅｒｓｉｏｎと値１．０．１、パス／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００２／ＡｐｐＩＤと値Ａ００２、パス／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００２／Ｓｔａｔｕｓと値ａｃｔｉｖｅ、／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００２／Ｖｅｒｓｉｏｎと値２．２．０のペアが読み込まれる。
（図６：ステップＳ６０２）
端末管理エージェント２１０は、ステップＳ６０１で読み込んだＤｅｖｉｃｅＩＤの値とデータツリーを、管理対象端末通信プログラム１１２に送信する。
（図６：ステップＳ６０３）
管理対象端末通信プログラム１１２は、ステップＳ６０２で取得したＤｅｖｉｃｅＩＤの値とデータツリーを、データツリー操作プログラム１２１に送信する。以降、図７の処理に進む。

図７は、データツリー操作プログラム１２１がデータツリーをサーバ側データツリー格納部１４０に格納する処理を説明するシーケンス図である。以下、図７の各ステップについて説明する。
（図７：ステップＳ７０１）
データツリー操作プログラム１２１は、ステップＳ６０３で管理対象端末通信プログラム１１２から受け取ったデータツリーのルートパスを取得する。図２のデータツリーの場合、ＤｅｖｉｃｅＩｎｆｏノードとＡｐｐｌｉｃａｔｉｏｎＩｎｆｏノードを取得する。
（図７：ステップＳ７０２）
データツリー操作プログラム１２１は、ステップＳ７０１で取得したルートパスに対応するサブツリー操作プログラム１３０内のサブプログラムを特定する。アプリケーションサーバ向けＪａｖａプラットフォームであるＪａｖａＥＥ（Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）では、ＯＳＧｉと同様に、任意の文字列を用いてインスタンスを登録・検索する機構であるＪＮＤＩ（Ｊａｖａ Ｎａｍｉｎｇ ａｎｄ Ｄｉｒｅｃｔｏｒｙ Ｉｎｔｅｒｆａｃｅ）を設けているので、これを用いてサブプログラムを特定することができる。例えば基本情報操作プログラム１３１は、文字列ＤｅｖｉｃｅＩｎｆｏによって特定し、そのインスタンスをＪＮＤＩに登録することができる。本ステップにおいては、サブツリー操作プログラム１３０として、基本情報操作プログラム１３１とアプリケーション情報操作プログラム１３２のインスタンスが取得される。

（図７：ステップＳ７０３）
データツリー操作プログラム１２１は、ステップＳ７０２で取得したサブツリー操作プログラム１３０内のサブプログラムに対し、ＤｅｖｉｃｅＩＤと対応するサブツリーを送信する。具体的には、パス／ＤｅｖｉｃｅＩｎｆｏ／ＤｅｖｉｃｅＩＤと値Ｄ００００１、パス／ＤｅｖｉｃｅＩｎｆｏ／Ｍａｎｕｆａｃｔｕｒｅｒと値ＣｏｍｐａｎｙＡ、パス／ＤｅｖｉｃｅＩｎｆｏ／Ｍｏｄｅｌと値ＳｍａｒｔＰｈｏｎｅのペアが、基本情報操作プログラム１３１に渡され、パス／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００１／ＡｐｐＩＤと値Ａ００１、パス／ＤｅｖｉｃｅＩｎｆｏ／Ｓｔａｔｕｓと値ｉｄｌｅ、パス／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００１／Ｖｅｒｓｉｏｎと値１．０．１、パス／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００２／ＡｐｐＩＤと値Ａ００２、パス／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００２／Ｓｔａｔｕｓと値ａｔｉｖｅ、／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００２／Ｖｅｒｓｉｏｎと値２．２．０のペアが、アプリケーション情報操作プログラム１３２に渡される。
（図７：ステップＳ７０４）
サブツリー操作プログラム１３０内の各サブプログラムは、ステップＳ７０３で受け取ったＤｅｖｉｃｅＩＤとデータツリーを、サーバ側データツリー格納部１４０内の、自身の管理するテーブルに格納する。具体的には、基本情報操作プログラム１３１は、受け取ったパスと値のペアを基本情報管理テーブル１４１に格納しアプリケーション情報操作プログラム１３２は、アプリケーション情報テーブルに格納する。

図８は、管理者が管理者端末３００を用いて管理対象端末２００のアプリケーション状態を参照する処理を説明するシーケンス図である。以下、図８の各ステップについて説明する。
（図８：ステップＳ８０１）
端末操作プログラム３１０は、アプリケーション状態を参照する管理対象端末２００のＤｅｖｉｃｅＩＤ、状態を参照するアプリケーションのＡｐｐＩＤ、アプリケーション状態が格納されるデータツリーのルートパスであるＡｐｐｌｉｃａｔｉｏｎＩｎｆｏを、管理者端末通信プログラム１１１に送信する。以降、ＤｅｖｉｃｅＩＤをＤ００００１、ＡｐｐＩＤをＡ００１として、説明する。
（図８：ステップＳ８０２）
管理者端末通信プログラム１１１は、ステップＳ８０１で受信したＤｅｖｉｃｅＩＤと文字列ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏを、データツリー操作プログラム１２１に送信する。データツリー操作プログラム１２１は、図９で説明する処理によって対応する属性値を検索し、検索結果を管理者端末通信プログラム１１１に返信する。図４に示すデータ例に拠れば、ＤｅｖｉｃｅＩＤ＝Ｄ００００１、ＡｐｐＩＤ＝Ａ００１のレコードが、管理者端末通信プログラム１１１に返される。

（図８：ステップＳ８０３）
管理者端末通信プログラム１１１は、データツリー検操作プログラム１２１から受信したツリーデータを端末操作プログラム３１０に送信する。
（図８：ステップＳ８０４）
端末操作プログラム３１０は、ステップＳ８０３で受信したツリーデータを管理者端末３００上のディスプレイなどに表示する。具体的には、ＤｅｖｉｃｅＩＤ＝Ｄ００００１、ＡｐｐＩＤ＝Ａ００１、Ｖｅｒｓｉｏｎ＝１．０．１、Ｓｔａｔｕｓ＝ｉｄｌｅが表示される。これにより管理者は、端末Ｄ００００１のアプリケーションＡ００１が停止状態にあることを知ることができる。

図９は、データツリー操作プログラム１２１がデータツリー内から指定されたレコードを検索する処理を説明するシーケンス図である。以下、図９の各ステップについて説明する。
（図９：ステップＳ９０１）
データツリー操作プログラム１２１は、データツリー操作プログラム１２１の呼び出し元（管理者端末通信プログラム１１１または管理対象端末通信プログラム１１２）から受け取ったルートパスに対応する、サブツリー操作プログラム１３０内のサブプログラムを特定する。ルートパスがＡｐｐｌｉｃａｔｉｏｎＩｎｆｏの場合、アプリケーション情報操作プログラム１３２が特定される。
（図９：ステップＳ９０２）
データツリー操作プログラム１２１は、ステップＳ９０１で特定したサブツリー操作プログラム１３０内のサブプログラムに、検索条件を送信する。

（図９：ステップＳ９０３）
サブツリー操作プログラム１３０内のサブプログラムは、受信した検索条件にしたがって、サーバ側データツリー格納部１４０内の自身が管理するテーブルから該当するレコードを検索し、検索結果をデータツリー操作プログラム１２１に送信する。例えば検索条件が、ＤｅｖｉｃｅＩＤ＝Ｄ００００１、ＡｐｐＩＤ＝Ａ００１であった場合、図４に示す１レコード目が取得される。
（図９：ステップＳ９０４）
データツリー操作プログラム１２１は、ステップＳ９０３で取得した検索結果を、データツリー操作プログラム１２１の呼び出し元（管理者端末通信プログラム１１１または管理対象端末通信プログラム１１２）に返す。

図１０は、端末管理サーバ１００が管理対象端末２００に対して制御命令を発行する処理を説明するシーケンス図である。以下、図１０の各ステップについて説明する。
（図１０：ステップＳ１００１）
端末操作プログラム３１０は、制御命令の宛先である管理対象端末２００のＤｅｖｉｃｅＩＤ、更新するデータツリーのパス、および更新後の値を、管理者端末通信プログラム１１１に送信する。例えば、端末Ｄ００００１のアプリケーションＡ００１を起動する場合は、データツリーのパスは／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００１／Ｓｔａｔｕｓ、値はａｔｉｖｅとなる。
（図１０：ステップＳ１００２）
管理者端末通信プログラム１１１は、ステップＳ１００１で受信したＤｅｖｉｃｅＩＤ、データツリーのパス、値をコマンド操作プログラム１２２に送信する。
（図１０：ステップＳ１００３）
コマンド操作プログラム１２２は、ステップＳ１００２で受信したＤｅｖｉｃｅＩＤ、データツリーのパス、値をコマンド管理テーブル１５０に格納する。

図１１は、コマンド管理テーブル１５０の構成とデータ例を示す図である。管理対象端末２００に対する制御命令は、稼動状態情報と同じツリー形式によって記述することができる。ステップＳ１００１の例の場合、図１１の１レコード目のように記述することができる。コマンド管理テーブル１５０に格納された制御命令は、図１２で説明するシーケンスによって実行される。

図１２は、端末管理サーバ１００が発行した制御命令を管理対象端末２００が実行する処理を説明するシーケンス図である。以下、図１２の各ステップについて説明する。
（図１２：ステップＳ１２０１）
端末管理エージェント２１０は、管理対象端末通信プログラム１１２に対して自身のＤｅｖｉｃｅＩＤを通知し、自身に対する制御命令が端末管理サーバ１００から発行されているか否かを問い合わせる。
（図１２：ステップＳ１２０２）
管理対象端末通信プログラム１１２は、ステップＳ１２０１で受信したＤｅｖｉｃｅＩＤを、コマンド操作プログラム１２２に送信する。

（図１２：ステップＳ１２０３）
コマンド操作プログラム１２２は、ステップＳ１２０２で受信したＤｅｖｉｃｅＩＤをコマンド管理テーブル１５０から検索し、検索結果を管理対象端末通信プログラム１１２に返す。ＤｅｖｉｃｅＩＤ＝Ｄ００００１であれば、図１１の１レコード目が管理対象端末通信プログラム１１２に返される。
（図１２：ステップＳ１２０４）
管理対象端末通信プログラム１１２は、ステップＳ１２０３で受信した検索結果を、端末管理エージェント２１０に送信する。
（図１２：ステップＳ１２０５）
端末管理エージェント２１０は、ステップＳ１２０４で受信したレコードが記述しているデータツリーのパスからルートパスを求め、対応する端末管理プラグイン２２０内のサブプログラムを特定し、データツリーのパスと値を渡す。ＤｅｖｉｃｅＩＤ＝Ｄ００００１であれば、データツリーのパスは／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００１／Ｓｔａｔｕｓであり、ルートパスはＡｐｐｌｉｃａｔｉｏｎＩｎｆｏとなるため、アプリケーション管理プログラム２２１が選択され、パス／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００１／Ｓｔａｔｕｓ、値ａｔｉｖｅが渡される。アプリケーション管理プログラム２２１は、渡されたパスと値が指定する制御命令にしたがって、アプリケーションＡ００１を起動する。

＜実施の形態１：まとめ＞
以上のように、本実施形態１に係る端末管理サーバ１００は、管理対象端末２００との間で使用する遠隔管理プロトコルが使用するツリー形式データのうち一部のノードの属性値を格納する管理テーブルを備える。さらに端末管理サーバ１００は、各管理テーブルに対してデータを書き込み、またはデータを読み取る操作プログラムを、管理テーブル毎に備えている。これにより、ＲＤＢの検索性能を保ちつつ、ツリー形式データの拡張性を利用して端末管理を柔軟に実施することができる。

＜実施の形態２＞
実施形態１では、サブツリー操作プログラム１３０内のサブプログラム、対応する管理テーブル、および端末管理プラグイン２２０内のサブプログラムを追加することにより、ＲＤＢ形式のテーブルを利用しつつデータツリーを拡張できることを説明した。本発明の実施形態２では、その１例として、管理用端末２００のファームウェア情報を管理項目として新たに追加した構成例を説明する。

図１３は、本実施形態２に係る端末管理システム１０００の構成図である。管理対象端末２００上においては、端末管理プラグイン２２０内のサブプログラムとして、ファームウェア管理プログラム２２３が追加されている。端末管理サーバ１００上においては、サブツリー操作プログラム１３０内のサブプログラムとして、ファームウェア情報操作プログラム１３３が追加されている。サーバ側データツリー格納部１４０には、ファームウェア情報テーブル１４３が追加されている。

端末管理システム１０００はさらに、バイナリ管理サーバ４００を有する。バイナリ管理サーバ４００は、管理対象端末２００にファームウェア管理プログラム２２３を配信するためのサーバである。端末管理エージェント２１０は、端末管理サーバ１００が発行する制御命令にしたがって、バイナリ管理サーバ４００からファームウェア管理プログラム２２３をダウンロードし、管理対象端末２００上にインストールする。

図１４は、管理対象端末２００のファームウェア情報を管理する機能を端末管理システム１０００に追加する処理を説明するシーケンス図である。以下、図１４の各ステップについて説明する。
（図１４：ステップＳ１４０１）
端末操作プログラム３１０は、管理者端末通信プログラム１１１に、ファームウェア情報操作プログラム１３３を送信する。
（図１４：ステップＳ１４０２）
管理者端末通信プログラム１１１は、ステップＳ１４０１で受信したファームウェア情報操作プログラム１３３を、端末管理サーバ１００上で起動する。端末管理サーバ１００のプラットフォームがＪａｖａＥＥである場合、ファームウェア管理用のデータツリーのルートパスをあらわす文字列であるＦａｒｍｗａｒｅＩｎｆｏを指定して、ファームウェア情報操作プログラム１３３のインスタンスをＪＮＤＩに登録する。

（図１４：ステップＳ１４０３）
ファームウェア情報操作プログラム１３３は、サーバ側データツリー格納部１４０に、ファームウェア情報管理テーブル１４３を生成する。ファームウェア情報管理テーブル１４３の構成については後述する。本ステップは、ファームウェア情報操作プログラム１３３に代えて、管理者などが手動で実施してもよい。
（図１４：ステップＳ１４０４）
端末操作プログラムは、ファームウェア管理プログラム２２３のバイナリを、バイナリ管理サーバ４００にアップロードする。

（図１４：ステップＳ１４０５）
端末管理サーバ１００は、図１０で説明したものと同様の手順を用いて、管理対象端末２００に対して、ファームウェア管理プログラム２２３をインストールするよう支持する制御命令を発行する。
（図１４：ステップＳ１４０６）
端末管理エージェント２１０は、図１２で説明したものと同様の手順を用いて、ステップＳ１４０５で発行された制御命令にしたがって、ファームウェア管理プログラム２２３を管理対象端末２００にインストールする。

（図１４：ステップＳ１４０７）
端末管理エージェント２１０は、図５で説明したものと同様の手順を用いて、ファームウェア管理プログラム２２３を端末管理エージェント２１０上に登録する。ファームウェア管理プログラム２２３は、管理対象端末２００のファームウェア情報を取得してＦａｒｍｗａｒｅＩｎｆｏツリーを生成し、端末管理エージェント２１０を介して、端末側データツリー格納部２３０に格納する。
（図１４：ステップＳ１４０８）
端末管理サーバ１００は、図６で説明したものと同様の手順を用いて、管理対象端末２００のファームウェアに関するデータツリー（ＦａｒｍｗａｒｅＩｎｆｏツリー）を収集してファームウェア情報管理テーブル１４３に格納する。

以上のステップＳ１４０１からステップＳ１４０８までの処理により、端末管理システム１０００にファームウェア管理機能が新たに追加される。以降、図１０で説明した登録処理と図１２で説明した実行処理によって、管理対象端末２００に対して新たなファームウェアを配信し、その状態を管理することができる。

図１５は、ステップＳ１４０５において端末管理サーバ１００が発行する制御命令を格納したコマンド管理テーブル１５０の構成を例示する図である。図１５に示すデータ例において、ファームウェア管理プログラム２２３のＡｐｐＩＤはＡ００３であり、／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００３／ＵＲＬ属性にはファームウェア管理プログラム２２３のダウンロード元ＵＲＬとして１３３．１０８．ｘｘｘ．ｘｘｘ／Ａｐｐｌｉｃａｔｉｏｎ／Ａ００３が指定され、／ＡｐｐｌｉｃａｔｉｏｎＩｎｆｏ／Ａ００３／Ｓｔａｔｕｓ属性にはバイナリのダウンロードとインストール開始を指示するｄｏｗｎｌｏａｄＡｎｄＩｎｓｔａｌｌが指定されている。

端末管理エージェント２１０は、図１５に例示するような制御命令にしたがって、ダウンロード元である１３３．１０８．ｘｘｘ．ｘｘｘ／Ａｐｐｌｉｃａｔｉｏｎ／Ａ００３からファームウェア管理プログラム２２３をダウンロードし、管理対象端末２００上にインストールする。

図１６は、ＦａｒｍｗａｒｅＩｎｆｏツリーの１例を示す図である。ＦａｒｍｗａｒｅＩｎｆｏツリーは、ファームウェア情報を保持する属性値として、ＦａｒｍＩＤ、Ｖｅｒｓｉｏｎ、ＢｙｔｅＳｉｚｅを有する。

図１７は、ファームウェア情報管理テーブル１４３の構成とデータ例を示す図である。ファームウェア情報管理テーブル１４３は、ＦａｒｍｗａｒｅＩｎｆｏサブツリーの値を格納するテーブルであり、同サブツリーが有する各属性値に対応するフィールドを有する。ただし、個々の管理対象端末２００を識別するため、これらフィールドに加えてＤｅｖｉｃｅＩＤフィールドも備えている。

＜実施の形態２：まとめ＞
以上のように、本実施形態２においては、管理対象端末２００の管理対象項目を追加する例として、ファームウェア情報を管理する機能を例示した。本実施形態２で説明したように、追加する管理対象項目を記述するツリーノードに対応して、サブツリー操作プログラム１３０、対応する管理テーブル、および端末管理プラグインを追加することにより、端末管理システム１０００に新たな機能を動的に追加することができる。これはツリー形式のデータフォーマットの利点を活かしたものであると同時に、ＲＤＢの検索性能を利用することができる点で、有用であると考えられる。

１００：端末管理サーバ、１１１：管理者端末通信プログラム、１１２：管理対象端末通信プログラム、１２１：データツリー操作プログラム、１２２：コマンド操作プログラム、１３０：サブツリー操作プログラム、１４０：サーバ側データツリー格納部、１５０：コマンド管理テーブル、２００：管理対象端末、２１０：端末管理エージェント、２２０：端末管理プラグイン、２３０：端末側データツリー格納部、３００：管理者端末、３１０：端末操作プログラム、端末管理システム１０００。

Claims (8)

1. ツリー形式で端末の稼動状態情報を記述する遠隔管理プロトコルを用いて、管理対象である端末からその端末の稼動状態情報を取得する端末通信部と、
   前記端末通信部が前記端末から取得した稼動状態情報を格納する管理テーブルと、
   前記管理テーブルに対して前記稼動状態情報を書き込む処理を実装したテーブル操作プログラムと、
   を備え、
   前記管理テーブルは、前記ツリー形式上の少なくともいずれかのノード毎に１つ設けられ、各前記管理テーブルは、対応する前記ノードに属する属性値を格納するフィールドを有しており、
   前記テーブル操作プログラムは、前記管理テーブル毎に設けられ、各前記テーブル操作プログラムは、対応する前記管理テーブルに対して前記属性値を書き込む処理を実装している
   ことを特徴とする端末管理装置。
2. 前記管理テーブルは、少なくとも前記ツリー形式上の属性値を集約するいずれかの前記ノード毎に設けられている
   ことを特徴とする請求項１記載の端末管理装置。
3. 請求項１または２記載の端末管理装置と、
   前記端末管理装置の管理対象であり、前記端末管理装置に対して前記遠隔管理プロトコルを用いて前記稼動状態情報を送信する端末と、
   を有することを特徴とする端末管理システム。
4. 前記端末は、前記端末の稼動状態情報を取得する管理プログラムを備え、
   前記管理プログラムは、前記ツリー形式上の少なくともいずれかのノード毎に１つ設けられ、各前記管理プログラムは、対応する前記ノードに属する属性値を前記端末から取得する処理を実装している
   ことを特徴とする請求項３記載の端末管理システム。
5. 前記管理プログラムは、前記管理テーブル毎に設けられている
   ことを特徴とする請求項４記載の端末管理システム。
6. 前記端末管理システムは、前記端末に対して前記管理プログラムを配布するバイナリ管理サーバを有し、
   前記端末は、前記バイナリ管理サーバから前記管理プログラムを取得して前記端末上にインストールする端末管理部を備える
   ことを特徴とする請求項４または５記載の端末管理システム。
7. 前記管理プログラムは、ＯＳＧｉフレームワーク上に実装されたＯＳＧｉバンドルとして構成されている
   ことを特徴とする請求項４から６のいずれか１項記載の端末管理システム。
8. 前記遠隔管理プロトコルは、ＯＭＡ−ＤＭ、ＴＲ−０６９およびＴＲ−１０６、またはＥＴＳＩ Ｍ２Ｍのうち少なくともいずれかである
   ことを特徴とする請求項３から７のいずれか１項記載の端末管理システム。

Images