JP2009054163A - 移動通信装置用の装置管理用ツリーの設定を可能にするオブジェクトを定義する方法および装置 - Google Patents

Abstract

【課題】階層構造化した装置定義フレームワーク（ＤＤＦ）の中にオブジェクトを定義する好適な方法を提案する。
【解決手段】ＤＤＦは、階層化されて互いに関連づけられた一種のツリー様構造を形成する複数のオブジェクトによって構成される。固定オブジェクトと実行時オブジェクトは、その直接下位に関連づけられた子オブジェクトを０個以上有することが許される。少なくとも１つの新たなオブジェクトが、親オブジェクトと関連づけられて定義される。親オブジェクトのオブジェクトタイプがチェックされる。親オブジェクトが実行時オブジェクトであれば、上記少なくとも１つの新たなオブジェクトを固定オブジェクトか葉オブジェクトかのいずれかにすることが可能となる。ＤＤＦは管理ツリーの少なくとも一部を生成するために採用されている。管理ツリーは複数のオブジェクトを具備しており、それらに移動通信可能な装置の管理関連情報が分散される。
【選択図】図４ａ

Description

本発明は、移動通信装置の管理関連情報用の装置管理用ツリー構造を設定することを可能にする階層オブジェクト構造の形でオブジェクトを定義し、追加する方法および装置に関する。特に、本発明は、上記管理ツリー内に１乃至いくつかのオブジェクトを作成する方法に関する。上記管理ツリーによって、動的な構造を有する管理ツリーが結果として得られ、効率のよい、明瞭で、管理可能な、望ましい組織化が提供される。さらに、本発明は、前述の方法を処理するようになっている装置およびシステムに関するものである。

データの同期は、少なくとも２つの異なる電子装置を用いて同じデータを処理するすべてのユーザにとって良く知られた問題である。一般に、同期は、（移動電話などの）端末装置と（ローカルなＰＣや専用の同期サーバ内のアプリケーションなどの）サーバ側装置との間で行われる。携帯用コンピュータ、ＰＤＡ端末装置（個人用情報機器）、移動局あるいはポケットベル（登録商標）などの携帯用端末装置のデータは、ネットワークのアプリケーションやデスクトップ型コンピュータのアプリケーションと、あるいは通信システムの別のデータベースとの同期をとることが可能であるが、この場合、データベースという用語は可能な限り広義なものとして、すなわち任意のデータのセットをカバーするものとして理解すべきである。特に、カレンダのデータおよび電子メール用アプリケーションは同期が行われる代表的なものである。

同期は、互換性のないメーカー固有の異なるプロトコルの使用に基づいて行われる。この異なるプロトコルの使用によって、端末装置のタイプやデータタイプの利用が限定され、ユーザにとってしばしばトラブルを引き起こす原因となることが多い。特に、移動通信においては、使用する端末装置およびアプリケーションに関係なくデータの検索と更新とが可能であることが重要である。

アプリケーションデータの同期の改善を図るために、拡張マークアップ言語（ＸＭＬ）をベースとする同期マークアップ言語ＳｙｎｃＭＬとして知られている言語、並びに、対応する標準化されたドキュメントタイプ記述（ＤＴＤ）が開発されている。ＳｙｎｃＭＬフォーマットの形のメッセージが採用されているＳｙｎｃＭＬ同期プロトコルを用いることにより、ネットワーク化された端末装置と任意の種類のネットワークサーバ間で任意のアプリケーションのデータの同期をとることが可能となる。ＳｙｎｃＭＬ同期プロトコルは、無線ネットワークおよび固定ネットワークの双方で機能し、いくつかの送信プロトコルをサポートしている。

ＳｙｎｃＭＬ同期技術はデータベースの同期を処理するものである。データベースの同期と類似する問題として、異なるネットワーク搬送波の移動通信ネットワーク内で作動する、移動電話などの変化する環境内での電子装置の操作に必要な構成データと設定値との管理によって生じる問題がある。上記構成データと設定値には、ネットワークアクセスポイント（ＮＡＰ）定義、プロキシおよびゲートウェイサーバアドレス、情報および定義、ショートメッセージサービス（ＳＭＳ）、マルチメディアメッセージサービス（ＭＭＳ）等のような或る一定のサービスを提供するサーバのアドレス情報などの構成についての個々の搬送波と関連づけられた設定値を必要とする。ＳｙｎｃＭＬ装置管理はこのような構成データと設定値との調和に関係するものである。それぞれの装置特性および実施可能なアプリケーションとそれぞれ関連づけられて、上記それぞれの構成データと情報とが管理オブジェクトの形でそれぞれ含まれる。

ＳｙｎｃＭＬ装置管理（ＳｙｎｃＭＬ ＤＭ）用プロトコルは、管理オブジェクトに対する管理コマンドの実行を可能にし、パッケージフォーマットに類似したＳｙｎｃＭＬ同期プロトコルおよび関連する定義を使用し、さらに、ＸＭＬ、あるいは、２進符号化ＸＭＬなどの関連するＸＭＬ符号化をベースにするものである。管理オブジェクトは、装置用の１組の構成パラメータ、すなわち、装置特性を示す構成パラメータおよび／または装置で実行されるソフトウェアアプリケーションの構成パラメータと設定値を反映するものであってもよい。上記オブジェクトに対して行うことができるアクションは、読出し用および設定用のパラメータキーと値とを含むものであってもよい。別の管理オブジェクトは、装置で実行するソフトウェアアプリケーション用の実行時環境であってもよい。このタイプのオブジェクトに対して行うことができるアクションは、ソフトウェア・エレメントのインストール、アップグレードあるいはアンインストールを含むものであってもよい。好適には、専用の管理用サーバが前述の装置管理情報の同期用の所望の構成パラメータ、設定値、キーおよび値を提供することが望ましい。

ＳｙｎｃＭＬ ＤＭに準拠する装置管理は、ＳｙｎｃＭＬ ＤＭプロトコルを用いて管理可能なすべての情報を含む、階層をなす管理ツリーの形で管理オブジェクトの構造化を可能にするものである。この管理ツリーは、ＳｙｎｃＭＬ装置管理をサポートするそれぞれの電子装置メーカーにより定義され、提供される管理ツリーの永続的部分に基づくものである。このような操作対象電子装置の中に存在する実際の管理ツリーは、管理ツリーの１乃至いくつかの動的に形成された部分により拡大される管理ツリーの上記永続的部分から構成される。一種の予め定義されたツリーフレームワーク（装置定義フレームワーク）から或る方法で実際の管理ツリーの説明を行うことにする。

上述のようなタイプの電子装置の作動に必要な管理情報を含むこのような管理ツリーの階層構造が、端末装置によりユーザへ提供される機能、並びに、構成データと設定値の格納、管理および／または検索用の管理ツリーにすべてアクセスする端末装置で実施可能なアプリケーションに依存してかなり複雑なものになることは明らかである。特に、電子装置に追加されるさらに別の個々の機能や、電子装置の中へ実装されるアプリケーションの結果、管理ツリーの階層構造全体が増加し、さらに複雑な階層構造を生じる原因になる。端末装置の操作を改善するアプリケーションの種類と機能および／または数は未知である。しかし、将来利用するための構成データと設定値の格納、検索および／または管理用として、上記生じた階層をなす管理ツリーの保守管理を行うことが望ましい。

本発明の目的は、複数の個々のオブジェクトにより構成される階層オブジェクト構造の少なくとも１つのオブジェクトを定義し、このオブジェクトを追加する方法を提供することである。その場合、上記階層オブジェクト構造によって電子装置の管理ツリーを記述し、それによって、上記の結果得られる管理ツリーをできるだけ効果的で将来においても耐久性のあるものとして構造化することを意図するものである。効率のよい構造化された管理ツリーは、１または２以上の或る管理オブジェクトの効率のよい管理と検索とを行い、上記管理オブジェクトの内容の管理と検索とを意図するものである。さらに、効率のよい構造化された管理ツリーは、限定されたリソース（メモリ、処理能力など）も考慮するものである。階層オブジェクト構造、特に、管理ツリーに含まれる１または２以上のオブジェクトはいくつかの定義規則と規定とに基づくオブジェクトであり、これらのオブジェクトに対する考慮の結果として、非常に効率のよい、最適化され、構造化された管理ツリーが得られることになる。

本発明の上記目的は、階層オブジェクト構造の中へ少なくとも１つのオブジェクトを追加する方法と、上記方法を実行するように適合された対応するシステムと装置と、独立クレームに開示されているコンピュータプログラムとソフトウェア・ツールとによって達成される。本発明の好適な実施形態は従属クレームに開示されている。

本発明の実施形態によれば、階層オブジェクト構造の中へ少なくとも１つのオブジェクトを追加する方法が提供される。上記階層オブジェクト構造は複数のオブジェクトによって構成される。これらのオブジェクトは階層的に相互に関連づけられる。上記オブジェクトの階層上の関連性は、第１のオブジェクトタイプと第２のオブジェクトタイプとの少なくとも２つの異なるタイプのオブジェクトを用いることにより得られる。第１のオブジェクトタイプと第２のオブジェクトタイプの双方が、これらのオブジェクトと直接関連する下位に配したオブジェクトを有することが可能である。

上記少なくとも１つのオブジェクトの上位に配され、かつ、上記少なくとも１つのオブジェクトと直接関連づけられる親オブジェクトと関連づけるように、上記少なくとも１つのオブジェクトが定義される。すなわち、定義対象の上記少なくとも１つのオブジェクトは上記親オブジェクトの子オブジェクトとなる。上記親オブジェクトは階層オブジェクト構造の一部である。上記親オブジェクトのオブジェクトタイプを取得して、該オブジェクトタイプを上記定義対象の子オブジェクトのオブジェクトタイプと比較する。上記親オブジェクトと上記少なくとも１つの子オブジェクトの双方のオブジェクトタイプが相互に一致し、かつ、双方のオブジェクトタイプが第１のタイプに一致すれば、第２のオブジェクトタイプを有するオブジェクトが、上記親オブジェクトと上記子オブジェクトとの間に置かれる。第２のオブジェクトタイプを有する少なくとも１つのオブジェクトによって、第１のオブジェクトタイプを有するオブジェクトをこれらオブジェクトの階層構成の中で常時分離することが上記のような分離によって保証される。

本発明の実施形態によれば、少なくとも２つの異なるオブジェクトタイプには実行時オブジェクトタイプと固定オブジェクトタイプとが含まれる。前述の第１のオブジェクトタイプは上記実行時オブジェクトタイプに対応し、前述の第２のタイプは上記固定オブジェクトタイプに対応する。

本発明の実施形態によれば、少なくとも以下のオブジェクトタイプが適している：固定オブジェクトタイプ、実行時オブジェクトタイプ、葉オブジェクトタイプ。

前述のオブジェクトタイプのうちのいずれか１つのタイプを含む個々のオブジェクトは、親オブジェクトとして示される、上位に配された１つの直接関連づけられたオブジェクトを有する。しかし、固定オブジェクトタイプまたは実行時オブジェクトタイプを含むオブジェクトの場合、該オブジェクトと直接関連づけられ、かつ、該オブジェクトの下位に配された０、１または２個以上のオブジェクトを含むことが許される。これら異なるオブジェクトタイプでは、上述のオブジェクトタイプのうちの１つのタイプを個々に含む複数のオブジェクトによって構成される階層オブジェクト構造の形成が許される。

したがって、本発明の実施形態に基づき少なくとも１つのオブジェクトを追加する前述の方法について上記とは別様に以下のように説明することができる。上記少なくとも１つのオブジェクトが定義されて、親オブジェクトと関連づけられる。検査対象として親オブジェクトのオブジェクトタイプが取得される。親オブジェクトのオブジェクトタイプが固定オブジェクトタイプであれば、上記少なくとも１つのオブジェクトは、固定オブジェクトタイプか、実行時オブジェクトタイプか、葉オブジェクトタイプかのいずれかのタイプを有することが許される。親オブジェクトのオブジェクトタイプが、実行時オブジェクトタイプであれば、少なくとも１つのオブジェクトが、固定オブジェクトタイプか葉オブジェクトタイプかのいずれかのタイプを有することが許される。

少なくとも１つのオブジェクトの定義づけを行うことにより、オブジェクトプロパティの定義づけがさらに必要となる場合がある。これらのオブジェクトプロパティは、ＡｃｃｅｓｓＴｙｐｅ、ＤｅｆａｕｌｔＶａｌｕｅ、Ｄｅｓｃｒｉｐｔｉｏｎ、ＤＦＦｏｒｍａｔ、Ｏｃｃｕｒｒｅｎｃｅ、Ｓｃｏｐｅ、ＤＦＴｉｔｌｅおよびＤＦＴｙｐｅを含むグループの中から１または２以上のプロパティを含むものであってもよい。これら生じる可能性のあるオブジェクトプロパティは提示した上記プロパティに限定されるものではなく、別の異なるオブジェクトプロパティも有効なプロパティとすることができる。

本発明の実施形態によれば、親オブジェクトが、下位として関連づけられた１または２以上の予め直接配設されたオブジェクトを含むかどうかがチェックされる。既存の１または２以上のオブジェクトがすでに存在すれば、これらの１または２以上のオブジェクトの１または２以上のオブジェクトタイプが決定され、上記取得された１または２以上のオブジェクトタイプが子オブジェクトのオブジェクトタイプと比較され、階層オブジェクト構造に追加される。上記取得された１または２以上のオブジェクトタイプと、子オブジェクトのオブジェクトタイプとがすべて第１のオブジェクトタイプ（すなわち実行時オブジェクトタイプ）であることが証明された場合、子オブジェクトと少なくとも１つの既存のオブジェクトとが共通のフォーマットを有するという条件の下で子オブジェクトが親オブジェクトに追加される。

オブジェクトのフォーマットは、どの種類の管理関連情報をそれぞれのオブジェクト間で配信し、階層を成して配設されたオブジェクトを当該それぞれのオブジェクトの下位として関連づけることが許されるか、および／または、該管理関連情報が上記配信との関連づけに適しているかを定義するものとする。共通のフォーマットを有するオブジェクトは、同じ装置機能および／または装置用アプリケーションと関連づけられた類似の管理関連情報をこれらのオブジェクトおよび下位に配したオブジェクト間で配信する旨の定義を行う。

本発明の実施形態に従って親オブジェクトのオブジェクトタイプが決定される。さらに、親オブジェクトがすでに１または２以上の子オブジェクトを有するかどうかのチェックが行われる。親オブジェクトが子オブジェクトを持たず、かつ、親オブジェクトと、定義対象の少なくとも１つのオブジェクトとが、双方とも第２のオブジェクトタイプを持っていれば、親オブジェクトと少なくとも１つのオブジェクトとは第２のオブジェクトタイプを持つ単一のオブジェクトに集約される。この集約は、親オブジェクトと少なくとも１つのオブジェクトとを単一オブジェクトと置き換えることにより行われる。

本発明の実施形態によれば、記述ドキュメントの少なくとも一部は、少なくとも１つの定義済みオブジェクトに基づいて符号化される。符号化された上記記述ドキュメントの少なくとも一部には、少なくとも１つのオブジェクトと、予め定義された少なくとも１つのオブジェクトのプロパティとに関する情報とが含まれる。この符号化済み記述ドキュメントによって、階層構造の中に含まれる複数のオブジェクト間で配信される電子装置の管理関連情報を格納するための階層オブジェクト構造の取得が可能となる。上記符号化済み記述ドキュメントあるいは上記記述ドキュメントの１または２以上の関連する部分の構文解析をそれぞれ行うことにより、１乃至いくつかのオブジェクトと、階層オブジェクト構造の少なくとも一部とを取得するようにしてもよい。

本発明の実施形態によれば、複数のオブジェクトを含む階層オブジェクト構造によって階層型管理構造の記述が行われる。この階層型管理構造はデータベースの階層的フレームワークとして理解してもよく、上記階層型構造に従って、上記データベース内に、特に移動通信端末の電子装置の管理関連情報が格納される。構成データおよび／または設定値である上記管理関連情報の或る部分は、上記オブジェクトと関連づけられるか、上記オブジェクトの中に含まれる。

本発明の実施形態によれば、オブジェクトのフォーマットは、どの種類の管理関連情報をそれぞれのオブジェクト間で配信し、階層を成して配設されたオブジェクトを当該それぞれのオブジェクトの下位として関連づけることが許されるか、および／または、該管理関連情報が上記配信との関連づけに適しているかを定義する。共通のフォーマットを有するオブジェクトは、同じ装置機能および／または装置用アプリケーションと関連づけられた類似の管理関連情報をこれらのオブジェクトおよび下位に配したオブジェクト間で配信する旨の定義を行う。

本発明の実施形態によれば、複数のオブジェクトを含む階層オブジェクト構造は装置定義フレームワーク（ＤＤＦ）情報に対応し、および／または、複数のオブジェクトを含む階層オブジェクト構造は電子装置の装置管理用管理ツリーに対応する。装置定義フレームワーク（ＤＤＦ）情報および／または管理ツリーが提供され、同期マークアップ言語装置管理（ＳｙｎｃＭＬ ＤＭ）用規格の形でＳｙｎｃＭＬイニシアチブによって標準化される。

本発明の実施形態によれば、上記記述ドキュメントは装置定義フレームワーク（ＤＤＦ）ドキュメントに対応する。ＤＤＦドキュメントは、対応する記述フレームワークドキュメントタイプ記述（ＤＴＤ）に基づいて符号化される拡張マークアップ言語（ＸＭＬ）符号化ドキュメントである。拡張マークアップ言語（ＸＭＬ）は以下に提示する明瞭な（プレーン）テキストＸＭＬ符号化に限定されるだけでなく、ＸＭＬ等に基づく２進符号化もカバーするものとする。

本発明の実施形態によれば、階層オブジェクト構造を確定する少なくとも１つのオブジェクトを複数のオブジェクトの中へ追加するソフトウェア・ツールが提供される。このソフトウェア・ツールには、コンピュータプログラムの形でソフトウェア・ツールを実現および／または実行するとき、本発明の任意の実施形態に基づいて前述の方法の処理を実行するプログラム部分が含まれる。

本発明の実施形態によれば、階層オブジェクト構造を確定する複数のオブジェクトの中へ少なくとも１つのオブジェクトを追加するコンピュータプログラムが提供される。このコンピュータプログラムには、該プログラムが、コンピュータやネットワーク装置の処理用装置で実行される本発明の任意の実施形態に基づいて前述の方法の処理を実行するロード可能なプログラムコード部分が含まれる。

本発明の実施形態によれば、コンピュータプログラム成果物が提供され、コンピュータやネットワーク装置の処理用装置でこのプログラム成果物を実行するとき、本発明の任意の実施形態に基づいて前述の方法を実行するコンピュータ可読媒体に格納されたプログラムコード部分が前記プログラム成果物には含まれる。

本発明の実施形態によれば、コンピュータデータ信号が提供される。このコンピュータデータ信号は搬送波の形で具現化され、プロセッサによりこのデータ信号を実行するとき、本発明の任意の実施形態に基づいて前述の方法を実行させるプログラムあるいはプログラムコード部分を表わす。

本発明の実施形態によれば、処理ユニット、メモリユニットおよび通信用インタフェースを備えた処理用装置が提供される。上記処理ユニットはメモリユニット、および、該処理ユニットとメモリユニット間でのデータ交換を可能にする通信ユニットと接続される。上記処理用装置の処理ユニットは、階層オブジェクト構造の中への少なくとも１つのオブジェクトの追加を可能にするように構成される。上記階層オブジェクト構造は複数のオブジェクトにより構成される。これらのオブジェクトは互いに階層的に関連づけが行われる。第１のオブジェクトタイプと第２のオブジェクトタイプの少なくとも２つの異なるタイプのオブジェクトを用いることにより、これらオブジェクトの階層上の関連づけは得られる。第１のオブジェクトタイプと第２のオブジェクトタイプの双方は、第１および第２のオブジェクトタイプと直接関連づけられた下位に配したオブジェクトを有することが許される。

上記少なくとも１つのオブジェクトの上位に配され、かつ、上記少なくとも１つのオブジェクトと直接関連づけられた親オブジェクトと関連づけるように上記少なくとも１つのオブジェクトは定義される。すなわち、定義対象の上記少なくとも１つのオブジェクトは上記親オブジェクトの少なくとも１つの子オブジェクトとなる。上記親オブジェクトは階層オブジェクト構造の一部である。上記親オブジェクトのオブジェクトタイプを取得して、該オブジェクトタイプを上記定義対象の少なくとも１つのオブジェクトのオブジェクトタイプと比較する。上記親オブジェクトと上記少なくとも１つの子オブジェクトの双方のオブジェクトタイプが互いに一致し、かつ、双方のオブジェクトタイプが第１のタイプに一致すれば、第２のオブジェクトタイプを有するオブジェクトが、上記親オブジェクトと上記少なくとも１つのオブジェクトとの間に置かれる。第２のオブジェクトタイプを有する少なくとも１つのオブジェクトにより、第１のオブジェクトタイプを有するオブジェクトをこれらオブジェクトの階層が相互に依存する形で常時分離することが上記のような分離によって保証される。

本発明の実施形態によれば、少なくとも１つのオブジェクトを階層オブジェクト構造の中へ追加する方法を示す前述の実施形態のうちのいずれか１つの実施形態の処理を可能にする処理用装置がさらに構成される。

本発明の実施形態によれば、管理対象のクライアント側装置または管理用サーバ側装置などの処理用装置および階層オブジェクト構造を具備する管理システムが提供される。上記階層オブジェクト構造は、階層的に関連づけられた複数のオブジェクトにより構成される。これら複数のオブジェクトの個々のオブジェクトは、第１のオブジェクトタイプと第２のオブジェクトタイプの、適用可能な少なくとも２つのオブジェクトタイプである或る一定のオブジェクトタイプを有する。第１のオブジェクトタイプまたは第２のオブジェクトタイプを有する個々のオブジェクトは、これら個々のオブジェクトの下位として関連づけられる、直接配設されたオブジェクトを有することが許される。

互いに階層を成して配設され、互いに関連づけられ、双方が第１のオブジェクトタイプを有する個々の２つのオブジェクトは、階層構造の形で第２のオブジェクトタイプを有する、上記２つのオブジェクトの間に置かれた少なくとも１つのオブジェクトによって分離される。すなわち、第１のオブジェクトタイプを有する階層的に関連づけられたオブジェクトを互いに対して直接配設することは許されない。

上記処理用装置は、階層オブジェクト構造の少なくとも一部を生成することが可能な少なくとも１つの管理用コンポーネントを備える。これによって、階層オブジェクト構造の階層構成は、結果として生じる階層オブジェクト構造の少なくとも一部の階層構成に対応づけられる。上記階層オブジェクト構造は、管理対象の移動通信が可能な装置の管理関連情報の検索と、格納と、管理とを行う機能を提供する。

本発明の実施形態によれば、少なくとも２つの異なるオブジェクトタイプが実行時親オブジェクトタイプと、固定親オブジェクトタイプとを具備する。前述の第１のオブジェクトタイプは実行時親オブジェクトタイプに対応し、前述の第２のタイプは固定親オブジェクトタイプに対応する。

本発明の実施形態によれば、少なくとも以下のオブジェクトタイプが利用に適している：固定親オブジェクトタイプ、実行時親オブジェクトタイプおよび葉オブジェクトタイプ。

前述のオブジェクトタイプうちのいずれか１つのタイプを含む個々のオブジェクトは、親オブジェクトとして示される、上位に配した１つの直接関連づけられたオブジェクトを有する。しかし、固定親オブジェクトタイプまたは実行時親オブジェクトタイプを含むオブジェクトの場合、該オブジェクトと直接関連づけられ、かつ、該オブジェクトの下位に配したオブジェクトを１つも含まないこと、あるいは１または２以上のオブジェクトを含むことが許される。これら異なるオブジェクトタイプでは、上述のオブジェクトタイプのうちの１つのタイプを個々に含む複数のオブジェクトにより構成される階層オブジェクト構造の形成が許される。

本発明の実施形態によれば、第１のタイプを有し、それらの上位には１つのオブジェクトが直接配設されて関連付けられている２または３以上のオブジェクトは共通のフォーマットを有する。オブジェクトのフォーマットは、どの種類の管理関連情報をそれぞれのオブジェクト間で配信し、階層を成して配設されたオブジェクトを当該それぞれのオブジェクトの下位として関連づけることが許されるか、および／または、該管理関連情報が上記配信との関連づけに適しているかを定義するものとする。共通のフォーマットを有するオブジェクトは、同じ装置機能および／または装置用アプリケーションと関連づけられた類似の管理関連情報をこれらのオブジェクトおよび下位に配したオブジェクト間で配信する旨の定義を行う。

本発明の実施形態によれば、互いに関連づけられ、双方とも前記第１のタイプを有する２つの直接配設されたオブジェクト、すなわち、双方とも第２のタイプを有する親オブジェクトと子オブジェクトとが、第２のオブジェクトタイプを有する集約オブジェクトと階層をなすオブジェクトツリーの形で取り替えられる。この集約オブジェクトは上記２つの置き換えられたオブジェクトから構成される。すなわち、上記階層オブジェクト構造は、上述の２つの直接配設されたオブジェクトから得られる集約オブジェクトを具備し、その結果、親オブジェクトおよびその子オブジェクト（第２のタイプの双方のオブジェクト）のみの直接の配置構成が階層オブジェクト構造では生じないことになる。

本発明の実施形態によれば、上記処理用装置は、少なくともクライアント側装置の管理用コンポーネント、すなわちクライアント管理用エージェントと格納用コンポーネントとを具備する管理対象の移動通信が可能な装置である。クライアント側装置管理用コンポーネントにより、階層オブジェクト構造の少なくとも一部を生成して、階層オブジェクト構造の一部を確定し、管理対象の移動通信が可能な装置の格納用コンポーネントの中へ階層オブジェクト構造の少なくとも一部を実現することが可能となる。この実現は、階層オブジェクト構造を動的に拡張する上記生成された階層オブジェクト構造の少なくとも一部を現在存在する階層オブジェクト構造の中へ実現するものであってもよい。クライアント側装置管理用コンポーネントは、上記階層オブジェクト構造を構成する複数のオブジェクト間で管理関連情報を配信し、さらに、装置および／または該装置を用いて実施可能なアプリケーションの機能を構成するために、複数のオブジェクトの１または２以上のオブジェクトから管理関連情報の少なくとも一部を検索することが可能である。

本発明の実施形態によれば、上記処理用装置は、少なくともサーバ側装置管理用コンポーネント、すなわちサーバ管理用エージェントおよび／またはサービス管理用エンジンおよび通信用インタフェースを具備する管理用サーバ側装置である。上記サーバ側装置管理用コンポーネントは、階層オブジェクト構造の少なくとも一部の生成と、生成された階層オブジェクト構造の少なくとも一部に基づく、管理命令並びに対応する管理関連データを含む１または２以上の管理メッセージの生成とを可能にする。上記サーバ側装置管理用コンポーネントは、さらに、取得した１または２以上の管理メッセージを通信用インタフェースで制御して管理対象の移動通信が可能な装置へ送信することが可能である。

上記１または２以上の管理メッセージは、送信済み管理情報に基づいてサーバ側装置の格納済みの階層オブジェクト構造を動的に拡張し、上記サーバ側装置が提供した管理関連情報を階層オブジェクト構造の或るオブジェクト間で配信し、上記生成済み階層オブジェクト構造の少なくとも一部等から得られるアドレス情報手段によって特定される（アドレス指定される）階層オブジェクト構造の或るオブジェクトから管理関連情報を検索するように管理対象の移動通信が可能な装置に指示することができる。

添付図面を参照しながら、実施形態に従って本発明についてさらに詳述する。

以下、ＳｙｎｃＭＬ装置管理用規格または関連するＳｙｎｃＭＬ規格をサポートするシステムに関する本発明の実施形態について説明するが、本発明はこのシステムに限定されるものではない。上記ＳｙｎｃＭＬ規格とＳｙｎｃＭＬ装置管理（ＳｙｎｃＭＬ ＤＭ）用規格とに関する情報は完全な規格ドキュメンテーションを公開して提供しているＳｙｎｃＭＬイニシアチブから得ることができる。図示の同じ部分あるいは均等な部分、特性および／または処理は同じ参照番号を用いて参照することにする。

図１は、装置間で情報の同期処理を行うことができる１組の電子装置を例示するブロック図を示す。望ましい移動端末装置の或る一定のデータベース内容を、指示された装置が提供するデータベースの内容と調和させるものとする。従来、移動端末装置は、専用のサーバ側装置によって、或る予め定義されたデータをデータベースまたはいくつかのデータベースの内容と調和させたり、同期させたりする同期クライアントとして機能するものである。図１は、同期処理用の複数の可能なクライアント側装置とサーバ側装置とを例示する図である。典型的には、クライアント側装置は、移動電話１７のような移動局や個人用情報機器（ＰＤＡ）、ノートブックのような移動用コンピュータ１５、デジタルカメラ１６あるいはパーソナルコンピュータ（ＰＣ）である。さらに、専用の同期サーバ側装置は、パーソナルコンピュータ１０のようなデスクトップ型コンピュータ、専用のネットワークサーバ１１あるいはノートブック１２のような移動用コンピュータであってもよい。専用のサービス提供用装置と接続された移動端末装置という観点から、同期についての上記提示コンセプトを説明するものではあるが、クライアント側装置の機能が上述のような移動端末装置に限定されるものではないことに留意されたい。

ＳｙｎｃＭＬプロトコル規格またはＳｙｎｃＭＬ装置管理用プロトコル規格に準拠する対応する同期処理は、それぞれ、適切な論理通信接続を介して設定することも可能である。同期プロトコルを適合させたトランスポートプロトコルと組み合わせた任意の通信ネットワークによって上記論理通信接続を行ってもよい。適切な通信ネットワークとしては、構内ネットワークローカルエリアネットワーク（ＬＡＮ）、インターネットおよび企業のイントラネットを具備することができる広域ネットワーク（ＷＡＮ）であってもよいが、ユニバーサルシリアルバス（ＵＳＢ）のような有線ベースのシリアルネットワークや（ＲＳ−３２３などの）標準化されたシリアル通信であってもよい。参加する同期用装置は、移動通信用広域システム（ＧＳＭ）サービスをサポートするおよび／または一般パケット無線サービス（ＧＰＲＳ）をサポートする移動通信ネットワーク、一般移動通信システム（ＵＭＴＳ）ネットワーク、無線ローカルエリアネットワーク（ＷＬＡＮ）、ブルートゥースネットワークあるいは赤外線ネットワーク（ＩｒＤＡ）などの第３世代移動通信ネットワークなどの無線通信ネットワークを介して接続されたものであってもよい。前述のタイプの単一の通信ネットワークによって、これらの参加する同期用装置間での論理通信接続を行うことも可能であるが、専用のネットワークルーティング用装置により相互接続された前述のタイプのいくつかの通信ネットワークによって上記論理通信接続を行うことも可能である。

ＳｙｎｃＭＬプロトコル規格と関連して、ＳｙｎｃＭＬ同期プロトコル、したがってＳｙｎｃＭＬ装置管理用プロトコル規格とも関連して、採用した通信ネットワークのタイプに準拠する適切なプロトコルの最上位にＳｙｎｃＭＬ装置管理用プロトコルを実装してもよい。ＳｙｎｃＭＬ同期プロトコルを最上位に実装することができる適切なプロトコルとしては、短距離無線周波数接続（ブルートゥース）用または赤外線接続（ＩｒＤＡ）用の、ハイパテキスト転送プロトコル（ｈｔｔｐ）、無線アプリケーション用プロトコル（ＷＡＰ）規格の無線セッションプロトコル（ＷＳＰ）、無線データグラムプロトコル（ＷＤＰ）、ユニバーサルシリアルバス（ＵＳＢ）やＲＳ−２３２のようなケーブル接続用として使用するオブジェクト交換プロトコル（ＯＢＥＸ）、トランスポート制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）スタック、並びに、トランスポート層の最上位に、（シンプルメール転送プロトコル、ＳＭＴＰなどの）電子メールプロトコルにより提供されるサービスがある。

ショートメッセージＳＭＳ（ショートメッセージサービス）や別のシグナリングタイプの送信方法（ＵＳＳＤ：非構造的補助サービスデータなど）や、回線交換型データコールや、パケット交換型データ転送サービスを利用する基底を成すネットワークに対応して、低位層における転送を行うことが可能である。

一般的同期並びに装置管理用同期についても上述したが、革新的なコンセプトについての以下の説明はＳｙｎｃＭＬ ＤＭプロトコルについて明示的に言及するものである。

ＳｙｎｃＭＬ ＤＭサービス自体は管理用ドキュメントの交換に基づいて行われるものであり、この管理用ドキュメントは、それぞれが、装置管理用データ、すなわち構成データ並びに設定値の同期をとることを意図する命令を含む複数のメッセージすなわちパッケージに分けることが可能である。ＳｙｎｃＭＬ ＤＭプロトコルには、認証および装置情報の交換を含む設定フェーズと管理フェーズの２つの部分が含まれる。管理フェーズはサーバが望む回数だけ反復することが可能である。

管理フェーズは複数のプロトコル反復から構成される。すなわち、プロトコル反復は、管理対象のクライアント側装置から管理用サーバ側へのパッケージ、並びに、管理用サーバ側から管理対象のクライアント側装置へのパッケージを意味する。管理用サーバ側から管理対象のクライアント側装置へ送られるパッケージの内容によって、セッションの継続が必要かどうかが判定される。管理用サーバが、管理対象のクライアント側装置からの応答（状態または結果）を必要とする管理操作をパッケージの形で送った場合、プロトコルの管理フェーズは、管理操作に対するクライアント側の応答を含む、管理対象のクライアント側装置から管理用サーバ側への新たなパッケージを続行する。管理対象のクライアント側装置からの応答パッケージは新たなプロトコル反復を開始する。上記管理用サーバは、新たな管理操作用パッケージを送り、したがって、上記管理用サーバが望む反復回数だけ新たなプロトコルを開始することができる。

上記パッケージ交換のおおまかな概観を示すために、設定フェーズと管理フェーズとに基づく例示のおよび有効な総パッケージシーケンスについて以下のセクションで説明する。

パッケージ０−管理セッションの開始：ほとんどの管理対象のクライアント側装置は“通知”と呼ばれることもある無応答型メッセージを受け取る場合がある。管理用サーバは、管理用サーバへ戻る接続をクライアントに開始させるこの通知能力を利用することができる。いくつかのベアラを管理開始通知の送信に利用することができる。管理開始通知を受信する同一の効果を別の方法で生じさせることが可能であることに留意されたい。

パッケージ１−管理対象のクライアント側装置から管理用サーバ側への初期化：管理対象のクライアント側装置により送られる初期化パッケージの目的として以下が挙げられる：
−（メーカー、モデルなどの）管理対象のクライアント側装置情報を装置管理用サーバ側へ送信すること。
−管理対象のクライアント側装置を管理用サーバに対して特定すること。
−（パッケージ０でトリガーを送信することにより）サーバによって、あるいは、（メニュー項目を選択するエンドユーザのような）クライアントによって管理セッションが開始されたかどうかをサーバに通知すること。

パッケージ２−管理用サーバ側から管理対象のクライアント側装置への初期化：管理用サーバにより送られる初期化パッケージの目的として以下が挙げられる：
−管理対象のクライアント側装置に対して装置管理用サーバを特定すること。
−管理用コマンドと管理用データとをオプションとして管理対象のクライアント側装置へ送信すること。
−ユーザとの対話処理用コマンドのようなさらなる別のコマンドをオプションとして送信すること。

パッケージ１および２は管理用操作の設定フェーズの一部である。以下のパッケージ３と４とは管理セッションの管理フェーズの一部である。

パッケージ３−管理用サーバへの管理対象のクライアント側装置の応答：この管理パッケージの目的として以下が挙げられる：
−管理用サーバから管理対象のクライアントへ送られる管理コマンドの結果を送信すること。
−オプションのユーザとの対話処理用コマンドの結果を送信すること。

パッケージ４−さらなる管理用サーバ操作：この管理パッケージの目的として以下が挙げられる：
−管理用サーバ側から管理対象のクライアント側へ任意のさらに別の必要な管理操作やコマンドをそれぞれ送信すること。
−管理セッションを閉じること。

さらに別の管理操作を含むパッケージ４によって、一種のパッケージ３の形で管理対象のクライアント側装置の応答が引き起こされる。したがって、上記管理セッションは、任意の反復回数のパッケージ３と４とを含むことが可能となる。

上述のフェーズとパッケージとに従う管理メッセージの交換に基づいて行われる前述のＳｙｎｃＭＬ ＤＭサービスは、管理対象情報を構造化し、この情報をそれぞれ含む管理ツリーを構成するオブジェクトに対してそれぞれアクションを行うものである。この管理ツリーは、すべての利用可能な、使用管理エンティティのはっきりと定義された、階層構造化された配置構成を成すものであり、その場合、その位置、並びにこれに対応して、或る管理用エンティティの中に含まれている或る情報を示す上記位置のアドレス指定は、上記管理情報の内容をそれぞれ反映することになる。データベースについての上述の広範な定義に照らして、上記管理ツリーは、はっきり定義された階層編成の形で構成データと設定値とを格納するためのデータベースと理解することができる。管理ツリー内での管理関連情報の位置は、操作用のそれぞれの管理関連情報を採用する或る一定の装置機能および／または装置用アプリケーションとそれぞれ相関づけられる。このはっきりと定義された階層構造は管理ツリーと呼ばれるものである。管理オブジェクトの階層的な組織化は主として、階層構造化された配置構成に対応する個々の単一の管理オブジェクト用の適切でかつ一意の固有アドレス指定方式の提供を求める必要性に対応するものである。ある特定の上位オブジェクト（ルートエンティティ）によってすべての階層を成して配設された管理オブジェクトの起源が提供される。すなわち、管理ツリーのルートオブジェクトは、管理オブジェクトの配設時に相対的な基準とするオブジェクトである。

異なる種類の管理オブジェクトが区別される。階層オブジェクト構造、特に管理ツリーは、以下で、（内部）ノードとしても示す内部オブジェクト並びに葉オブジェクトを有する。葉オブジェクトは、任意の但し予め定義された内容を含むことが許される葉オブジェクトと、階層オブジェクト構造内の或るオブジェクトのアドレス情報を含むリンクオブジェクトとの間で区別される。内部オブジェクトすなわち内部ノードは、それに従属する１乃至いくつかのオブジェクトを関連づけるために用いるエンティティを表す。すなわち、上記内部ノードは、１乃至いくつかの、但し、或る態様では所定数の直接（即座に）関連づけられ、階層において下位に配したオブジェクトを含む階層的構造化を行うエンティティを表わすものであり、上記オブジェクトは、親オブジェクトすなわち親ノードに対してそれぞれ関連づけられ、配設される１または２以上の子オブジェクトすなわち子ノードとして示されることになる。個々の内部オブジェクトすなわち内部ノード自体は１つの内部オブジェクトすなわち内部ノードあるいは最上位の階層レベルを有する内部オブジェクトすなわち内部ノードであるルートオブジェクト／ノードと関連づけられる。上記間連鎖（inter-concatenation）に基づいて、階層オブジェクト構造、すなわち管理ツリーが設定される。上記内部オブジェクトは、永続的内部オブジェクトと動的内部オブジェクトとの間で区別される。“永続的”という命名が示すように、永続的オブジェクトは、稼動している管理対象のクライアント側装置またはアプリケーションのいずれの操作状態にも左右されずに管理ツリーの中に常に存在しているが、これに対して、動的オブジェクトは、階層構造（管理ツリーの動的な一部）の中に含まれる情報の必要性に対応する管理対象のクライアント側装置または管理用サーバによって、追加、置換、変更および／または削除を行うことも可能である。

葉オブジェクトは、上位の内部オブジェクトと関連づけられるが、下位オブジェクトの関連づけは許されない。すなわち、関連づけられた子オブジェクトを持っていない。代わりに、葉オブジェクトは、任意の、但し予め定義されたコンテントタイプの或る内容を含むためのコンテナとして用いられる。すなわち、葉オブジェクトは、或る内容、整数値のような値など、さらに大きな値（プレーンテキスト、値のアレイ）、複雑なデータ型、画像およびプログラムコードを含むものであってもよい。葉オブジェクトには、装置操作および／またはアプリケーション操作に必要な構成データおよび／または設定値が含まれる。葉オブジェクトは、管理ツリーの枝のオブジェクトの“終端”を表わす。すなわち管理ツリーのそれぞれの枝の最下位の階層レベルである。

図１ｂは移動通信装置などの管理対象のクライアント側装置において実現される管理ツリーの一部分の一例を示す。管理ツリーの例示部分はルートオブジェクト“／”を有し、このルートオブジェクトから管理ツリーが設定される。本明細書では、管理ツリーの例示部分の図示は最上位レベルの構造に限定される。ルートオブジェクトの下位に、装置定義フレームワーク（ＤＤＦ）オブジェクト、装置情報（ＤｅｖＩｎｆｏ）オブジェクト、装置詳細情報（ＤｅｖＤｅｔａｉｌ）オブジェクトおよび例示オブジェクトＡＰが描かれている。これらオブジェクトのすべては、内部オブジェクトであり、この内部オブジェクトの下位にさらなるオブジェクトを設けることが可能である。ルートオブジェクト（ルートノード）“／”と関連づけられたオブジェクトの数は上記図示されたオブジェクトの数に限定されるものではない。これらは単なる例示である。すなわち、０、１または２個以上の追加オブジェクトをルートオブジェクト“／”の下位オブジェクトとして関連づけることも可能である。オブジェクトＤＤＦ、ＤｅｖＩｎｆｏおよびＤｅｖＤｅｔａｉｌは、管理対象のクライアント側装置用の選択された必須オブジェクト（但しこれら必須オブジェクトに限定するものではない）を表わすものであり、この必須オブジェクトはＳｙｎｃＭＬ装置管理サービスに関する操作を行うことを可能にするオブジェクトである。ＤｅｖＤｅｔａｉｌオブジェクトおよびＤｅｖＤｅｔａｉｌオブジェクトは下位オブジェクトであるが、この下位に無限定の数のさらなる下位オブジェクト（並びにリンクオブジェクト）が配されることを意味している。管理ツリーは、管理対象のクライアント側装置のスイッチ・オン時に設定してもよい。ＳｙｎｃＭＬ装置管理サービスに対応する管理情報の上述の交換に従って管理ツリーの適合化処理および／または変更処理を行うことも可能である。

個々のオブジェクト、すなわち或るオブジェクトの中に含まれる個々の情報はアドレス指定が可能である。或るオブジェクトのアドレス指定はインスタンス識別子に基づいて行われる。インスタンス識別子は、管理ツリーの個々のオブジェクトに対して割り当てられる。オブジェクトに対してインスタンス識別子を割り当てる際に、個々のオブジェクトのアドレス指定を一意のものとする必要があることを考慮する必要がある。これは、下位オブジェクトが１または２以上の直接関連づけられた下位オブジェクト（下位オブジェクト、葉オブジェクト、リンクオブジェクト）を持っているかもしれないことを意味する。管理ツリー内の個々のオブジェクトに対して一意のアドレス指定を取得するためには、これらの直接関連づけられた下位オブジェクトのインスタンス識別子は互いに異なるものでなければならない。アドレス情報には、ルートオブジェクトから操作対象オブジェクトまでのインスタンス識別子が含まれ、これらインスタンス識別子は管理ツリーの階層構造に従って受け渡される。適切な区切り文字によってそれぞれのインスタンス識別子は分離される。

管理ツリーというコンセプトは異なる機能を実行する広範な数の管理対象のクライアント側装置に対しておよび／または同一ではない広範な数の異なるアプリケーションを操作する管理対象のクライアント側装置に対して提供される。このことは、同じ構造の管理ツリーで管理対象のクライアント側装置を記述できないこと、したがって、ＳｙｎｃＭＬ装置管理サービスという点から見た管理対象のクライアント側装置の振舞いは異なるものとなることを意味するものである。

上記問題は装置定義フレームワーク（ＤＤＦ）により処理される。装置定義フレームワーク（ＤＤＦ）の利用によって、管理対象のクライアント側装置のメーカーが、装置定義フレームワークの異なる動的なすべての（実行時）表現で管理ツリーを記述する情報の提供を行うことが可能となり、その結果、ＳｙｎｃＭＬ装置管理サービスに基づいて管理用サーバが行う管理対象のクライアント側装置の管理が可能となる。柔軟かつ容易に拡張可能な方法で上記装置定義フレームワーク（ＤＤＦ）を適用できるように、さらに、管理ツリーに対する将来の要求もカバーできるように、上記装置定義フレームワークの具現化を行うことが望ましい。上記装置定義フレームワーク（ＤＤＦ）はオブジェクトの要約記述である。したがって、装置定義フレームワーク（ＤＤＦ）から管理ツリー自体を導き出すことが可能であり、その場合、装置定義フレームワーク（ＤＤＦ）は、異なる状況に適合するようになっている対応する管理対象のクライアント側装置として使用されるすべての有効な広範な数の個々の管理ツリー構造をサポートする。したがって、この装置定義フレームワーク（ＤＤＦ）には、オブジェクト（永続的／動的内部オブジェクト、葉オブジェクトおよびリンクオブジェクト）を導き出すことを可能にする記述オブジェクトと、オブジェクトのプロパティと、オブジェクトの連鎖（管理ツリー内での関連づけ、配置構成）とが含まれることになる。したがって、装置定義フレームワーク（ＤＤＦ）の記述オブジェクトには、オブジェクトしたがって管理ツリーの設定に必要な情報をそれぞれ有効に詳述する定義が含まれる。装置定義フレームワーク（ＤＤＦ）の記述オブジェクトは階層オブジェクト構造を反映し、その結果得られる管理ツリーのテンプレート階層構造として機能する。

本発明の発明概念は、上述の利点が達成されるように、装置定義フレームワーク（ＤＤＦ）に記載されているオブジェクトの定義づけと追加とを行う時に適用される規則および規定に関するものである。

管理ツリーおよび対応する装置定義フレームワーク（ＤＤＦ）の記述を図による描写と関連して示すことにする。

図２ａは、オブジェクトタイプにより区別されるオブジェクトの図による表記に用いるエレメントを図示する表を示す。この図的表現はオブジェクトの意味（オブジェクトタイプ）と比較される。管理ツリーの形成に利用可能なオブジェクトに対応して、上記表には、固定（親）オブジェクトタイプと、実行時（親）オブジェクトタイプと、葉オブジェクトタイプとが含まれる。本明細書には、別のさらなるオブジェクトタイプである、リンクオブジェクトタイプが示されている。前述のように、リンクオブジェクトタイプは或る別のオブジェクトのアドレス指定情報を階層オブジェクト構造内に格納する特定の葉オブジェクトタイプである。すなわち、リンクオブジェクトタイプは、プレーンテキスト値であるリンク値を含む葉オブジェクトタイプを定義して、ユニフォームリソースインジケータ（ＵＲＩ）あるいは任意の同様の対応するまたは関連するアドレス指定値を符号化するものである。固定親オブジェクトタイプを有する固定親オブジェクトは、インスタンス識別子を表示するタイトル（この図では“固定”という語によって置き換えられている）を含む矩形によって表され、実行時オブジェクトタイプを有する実行時オブジェクトは、タイトル（この図では“実行時”という語によって置き換えられている）を含む丸いコーナーを持つ矩形により表され、葉オブジェクトタイプを有する葉オブジェクトは単に、インスタンス識別子を表わすそのタイトル（この図では“葉”という語によって置き換えられている）により表され、最後に、リンクオブジェクトタイプを有するリンクオブジェクトは、インスタンス識別子を表わすアンダーラインを付したタイトル（この図では“リンク”という語によって置き換えられている）によって単に表されている。

オブジェクトのタイトル（すなわちインスタンス識別子）は、記述オブジェクトの１つのプロパティエレメント（ＮｏｄｅＮａｍｅエレメントと名づけられる）である。前述のように、オブジェクトは、予め設定した値（固定オブジェクト）や動的な割り当て値（実行時オブジェクト）を持つＮｏｄｅＮａｍｅエレメントにより特定可能である。さらに別のプロパティエレメントは、以下のプロパティエレメントを含まなければならない場合や、含むものであってもよい場合がある：ＡｃｃｅｓｓＴｙｐｅ、ＤｅｆａｕｌｔＶａｌｕｅ、Ｄｅｓｃｒｉｐｔｉｏｎ、ＤＦＦｏｒｍａｔ、Ｏｃｃｕｒｒｅｎｃｅ、Ｓｃｏｐｅ、ＤＦＴｉｔｌｅおよびＤＦＴｙｐｅ。これらプロパティエレメントの提示リストは、単に例示のためのものであり、上記プロパティエレメントに限定されるものではないものと理解すべきである。ＡｃｃｅｓｓＴｙｐｅのエレメントは、オブジェクトに対してどのコマンドが許されるか（オブジェクトに対してどのアクションをとることが許されるか）およびどのコマンドを定義しなければならないかを指定するものである。ＡｃｃｅｓｓＴｙｐｅのエレメントとしては、取得、削除、追加並びに置換があり得る。ＤｅｆａｕｌｔＶａｌｕｅエレメントは、オブジェクト値が別の値に明確に設定されていない場合に、装置で使用するオブジェクト値をオプションとして定義するものである。Ｄｅｓｃｒｉｐｔｉｏｎエレメントは、人間が理解できるオプションのオブジェクト記述を定義する。ＤＦＦｏｒｍａｔエレメントはオブジェクトの必須データフォーマットを定義する。Ｏｃｃｕｒｒｅｎｃｅエレメントは、管理ツリー内の当該オブジェクトから発生するかもしれないインスタンスの数、すなわち、特に、１つの親オブジェクトの下位に関連づけられるように直接配設された子オブジェクトの数をオプションとして指定する。Ｓｃｏｐｅエレメントは、このオブジェクトが永続的オブジェクトを記述するものであるか、動的オブジェクトを記述するものであるかをオプションとして指定するものである。ＤＦＴｉｔｌｅエレメントは、人間が理解できるオプションのオブジェクト名を定義する。ＤＦＴｙｐｅエレメントは、葉オブジェクトに対してはオブジェクト値のＭＩＭＥタイプ（多目的インターネットメール拡張子タイプ）を、内部オブジェクトに対しては、ヌルまたはＤＤＦドキュメント名を定義する。

固定親オブジェクトは永続的オブジェクトまたは動的内部オブジェクトである。親オブジェクトのタイトルは固定され、管理ツリーでのインスタンス識別子として使用される。固定親オブジェクトのＯｃｃｕｒｒｅｎｃｅが１（Ｏｎｅ）の場合、対応する内部オブジェクトは永続的内部オブジェクトとなる。すなわちＳｃｏｐｅは永続的なものとなるのに対して、固定親オブジェクトのＯｃｃｕｒｒｅｎｃｅが０あるいは１（ＺｅｒｏＯｒＯｎｅ）の場合、固定親オブジェクトのＳｃｏｐｅは動的なものになり、その結果、管理用サーバにより実行時に内部オブジェクトの作成と削除とが可能となる。

実行時（親）オブジェクトは動的内部オブジェクトである。実行時オブジェクトのタイトルは固定されない。すなわち,動的内部オブジェクト名はその作成中実行時に動的に定義され、管理ツリー内のインスタンス識別子として使用される。動的に定義されたインスタンス識別子は英数文字（最大９文字）からなる任意の文字列を有することができる。以下、実行時オブジェクトのタイトルを＜Ｘ＞または＜Ｙ＞により表わすことにする。

葉オブジェクトとリンクオブジェクトのタイトルはそれぞれ固定される。葉オブジェクトに含まれる内容のコンテントタイプ（そのＭＩＭＥタイプ）を指定する必要があるのに対して、ＵＲＩ（ユニフォームリソースインジケータ）などのアドレス情報を符号化するために、リンクオブジェクトのコンテントタイプは対応する葉オブジェクトのコンテントタイプを指定する。

以下の規則では、上記或るオブジェクトタイプを持つオブジェクトと関連する規定および方法を示す。この提示されたオブジェクトタイプはオブジェクトタイプをこのオブジェクトタイプに限定するものではない。というのは、本発明の概念を妨げないさらに別のオブジェクトタイプを含むことも可能であるからである。

図２ｂは、オブジェクトの図による表記用としてさらに使用される特殊文字を例示する表を示す図である。上記表によって文字とそれらの意味との比較が行われる。これらの文字はオブジェクトのＯｃｃｕｒｒｅｎｃｅプロパティエレメントを表わす。このＯｃｃｕｒｒｅｎｃｅエレメントは、管理ツリーで発生する可能性があるオブジェクトインスタンスの数をオプションとして指定する。デフォルトによって、および、追加文字がオブジェクトのタイトルに付加されていない場合、管理ツリーにおける対応するオブジェクトの発生回数は（正確に）１回である。オブジェクトのタイトルに付加される“＋”符号は管理ツリー内での対応するオブジェクトの発生回数が１回であるか、１回よりも多い回数となる場合があることを示す（Ｏｃｃｕｒｒｅｎｃｅ：ＯｎｅＯｒＭｏｒｅ、ＯｎｅＯｒＮ）。オブジェクトのタイトルに付加された“＊”符号は、管理ツリーにおける対応するオブジェクトの発生回数が０回か、０回よりも多い回数であってもよいことを示す（Ｏｃｃｕｒｒｅｎｃｅ：ＺｅｒｏＯＲＭｏｒｅ、ＺｅｒｏＯｒＮ）。記述オブジェクトのタイトルに付加された“？”符号は０回または１回の管理ツリー内での対応するオブジェクトの発生回数を示す（Ｏｃｃｕｒｒｅｎｃｅ：ＺｅｒｏＯｒＯｎｅ）。

次の図３ａ〜図３ｅは、オブジェクトの定義づけと追加が行われている間、本発明の実施形態に従って少なくとも１つのオブジェクトを追加する方法の例により、次の図４ａで具現化される階層オブジェクト構造で適用され、遵守される規則と規定とを例示する図である。

図３ａは本発明の実施形態に基づく記述オブジェクトの第１の配置構成を示す図である。上記第１の配置構成は第１の固定（親）オブジェクト“Ｎｏｄｅ＿１”と、１または２以上の実行時（親）オブジェクト＜Ｘ＞＊と、第２の固定（親）オブジェクト“Ｎｏｄｅ＿２”とを含む。１または２以上の実行時オブジェクト＜Ｘ＞＊が第１の固定（親）オブジェクト“Ｎｏｄｅ＿１”の下位として関連づけられるのに対して、第２の固定親オブジェクト“Ｎｏｄｅ＿２”は、１または２以上の実行時オブジェクト＜Ｘ＞＊の各々の下位としてそれぞれ関連づけられる。

上述の装置定義フレームワーク（ＤＤＦ）構造に基づいて、および、記述オブジェクトのグラフィック定義に基づいて、結果として生じる管理ツリーの一部はインスタンス識別子“Ｎｏｄｅ＿１”を伴う第１の固定親オブジェクト“Ｎｏｄｅ＿１”および０回、１回または２回以上の実行時オブジェクト＜Ｘ＞＊を含む。上記実行時オブジェクト＜Ｘ＞＊のインスタンス識別子は実行時に定義され、例えば、“ｒｕｎ−ｔｉｍｅ＿１”、“ｒｕｎ−ｔｉｍｅ＿２”等々である。

インスタンス識別子“ｒｕｎ−ｔｉｍｅ＿１”を持つ１つの実行時オブジェクト＜Ｘ＞＊が（上記図示に従って）作成されていると仮定する。実行時オブジェクト“ｒｕｎ−ｔｉｍｅ＿１”は固定オブジェクト“Ｎｏｄｅ＿１”の下位として関連づけられる。すなわち実行時オブジェクト“ｒｕｎ−ｔｉｍｅ＿１”は固定オブジェクト“Ｎｏｄｅ＿１”の子オブジェクトである。第２の固定オブジェクト“Ｎｏｄｅ＿２”の範囲定義（Ｓｃｏｐｅエレメント）によれば、実行時オブジェクト“ｒｕｎ−ｔｉｍｅ＿１”は固定オブジェクト“Ｎｏｄｅ＿２”に対する親オブジェクトである。すなわち固定オブジェクト“Ｎｏｄｅ＿２”は実行時オブジェクト“ｒｕｎ−ｔｉｍｅ＿１”に対する子オブジェクトである。

インスタンス識別子“ｒｕｎ−ｔｉｍｅ＿１”と“ｒｕｎ−ｔｉｍｅ＿２”とを持つ２つの実行時オブジェクト＜Ｘ＞＊が作成されていると仮定する。実行時オブジェクト“ｒｕｎ−ｔｉｍｅ＿１”と“ｒｕｎ−ｔｉｍｅ＿２”とは固定オブジェクト“Ｎｏｄｅ＿１”に対する子オブジェクトである。さらに、第２の固定オブジェクト“Ｎｏｄｅ＿２”の範囲定義（Ｓｃｏｐｅエレメント）によれば、実行時オブジェクト“ｒｕｎ−ｔｉｍｅ＿１”は固定オブジェクト“Ｎｏｄｅ＿２”に対する親オブジェクトであり、同時に、実行時オブジェクト“ｒｕｎ−ｔｉｍｅ＿２”は固定オブジェクト“Ｎｏｄｅ＿２”に対する親オブジェクトである。同じインスタンス識別子“Ｎｏｄｅ＿２”を持つこれら双方の子オブジェクトは、管理ツリー内でこれら子オブジェクトの異なる依存状態（関連づけ、親オブジェクト）により区別することが可能である。

図３ｂは、本発明の実施形態に基づく記述オブジェクトの第２の配置構成を示す図である。この第２の配置構成には、第１の固定オブジェクト“Ｎｏｄｅ＿３”、１または２以上の実行時オブジェクト＜Ｙ＞＋、第２の固定オブジェクト“Ｎｏｄｅ＿４”および葉オブジェクト“Ｌｅａｆ”が含まれる。上記１または２以上の実行時オブジェクト＜Ｙ＞＋が、第１の固定オブジェクト“Ｎｏｄｅ＿３”の下位として関連づけられるのに対して、第２の固定オブジェクト“Ｎｏｄｅ＿４”と葉オブジェクト“Ｌｅａｆ＿１”とは、１または２以上の実行時オブジェクト＜Ｙ＞＋の各々の下位として関連づけられる。図３ｂは、１つの固定オブジェクト“Ｎｏｄｅ＿４”と、１つの葉オブジェクト“Ｌｅａｆ＿１”という２つの子オブジェクトを有する１回だけのオブジェクト＜Ｙ＞＋を意味する“最も単純な”状況を例示する。

上述の装置定義フレームワーク（ＤＤＦ）構造に基づいて、結果として得られる管理ツリーの一部には、インスタンス識別子“Ｎｏｄｅ＿３”を持つ第１の固定オブジェクト“Ｎｏｄｅ＿３”と、第１の固定オブジェクト“Ｎｏｄｅ＿３”に対して直接配設され、かつ、第１の固定オブジェクト“Ｎｏｄｅ＿３”の下位として関連づけられる少なくとも１または２以上の実行時オブジェクト＜Ｙ＞＋（すなわち第１の固定オブジェクト“Ｎｏｄｅ＿３”の子オブジェクト）とが含まれる。これらの子オブジェクトのインスタンス識別子は、実行時で定義され、例えば“ｒｕｎ−ｔｉｍｅ＿１”、“ｒｕｎ−ｔｉｍｅ＿２”等々と同じように呼ぶことができる。実行時オブジェクト“ｒｕｎ−ｔｉｍｅ＿１”、“ｒｕｎ−ｔｉｍｅ＿２”、．．．の各々は、第２の固定オブジェクト“Ｎｏｄｅ＿４”と、葉オブジェクト“Ｌｅａｆ＿１”という２つの子オブジェクトを有する。

図３ａおよび図３ｂと関して説明した上記構造は、使用が許される装置定義フレームワーク（ＤＤＦ）の定義構造を表わすものである。この構造とは逆に、図３ｃは、本発明の概念を示す規則と規定とに基づいて回避されるオブジェクトの配置構成を示す。

記述オブジェクトの第１の配置構成は、発生回数が０回、１回またはそれ以上の回数であるいくつかの第１の実行時オブジェクト＜Ｘ＞＊と、さらに、発生回数がやはり０回、１回またはそれ以上の回数であるいくつかの第２の実行時オブジェクト＜Ｙ＞＊である。図３ｃの例は、１つの第１の実行時オブジェクト＜Ｘ＞＊と１つの第２の実行時オブジェクト＜Ｙ＞＊の連鎖を示すものである。さらに一般的には、１または２以上の第１の実行時オブジェクト＜Ｘ＞＊と、１または２以上の第２の実行時オブジェクト＜Ｙ＞＊とが存在する場合、第１の実行時オブジェクト＜Ｘ＞＊の各々は、該第１の実行時オブジェクトに対する子オブジェクトである１乃至いくつかの第２の実行時オブジェクト＜Ｙ＞＊に対する親オブジェクトとなる。したがって、親オブジェクトである１または２以上の第１の実行時オブジェクト＜Ｘ＞＊の各々は、動的な割当て済みインスタンス識別子を有する。さらに、子オブジェクトである１または２以上の第２の実行時オブジェクト＜Ｙ＞＊の各々は、やはり動的な割当て済みインスタンス識別子を有する。

異なる階層レベルで動的な割当て済みインスタンス識別子を備えた、連続する直接配設された実行時オブジェクトを含むこのような階層オブジェクト構造は、特に、管理ツリーの探査という点から、オブジェクトを容易に特定する能力の不足に起因して管理が困難な複雑な構造を示すものであることが容易に理解される。

オブジェクトの定義づけを行うための規則全体として、固定親オブジェクトの下位として実行時オブジェクトを関連づける必要があり、さらに、この実行時オブジェクトは、少なくとも１つの下位に関連づけられた固定オブジェクトおよび／または葉オブジェクトおよび／またはリンクオブジェクトに対する親オブジェクトとして機能する必要がある。

図３ｄは、本発明の実施形態に基づいて単一のオブジェクトに集約すべきオブジェクトの配置構成を示す図である。この配置構成は、固定オブジェクト“Ｎｏｄｅ＿５”と、固定オブジェクト“Ｎｏｄｅ＿６”という２つの連続する固定オブジェクトを有し、この場合、固定オブジェクト“Ｎｏｄｅ＿５”の唯一の子オブジェクトは固定オブジェクト“Ｎｏｄｅ＿６”である。この種の固定親オブジェクトを並べることは有益な情報を示すことにならないので、固定オブジェクト“Ｎｏｄｅ＿５”と固定オブジェクト“Ｎｏｄｅ＿６”とを同じ情報を示す単一の固定オブジェクト“Ｎｏｄｅ＿５Ｎｏｄｅ６”に集約することができる。この集約によって、管理ツリーの探査と、それらのアドレス指定の単純化による、集約した固定親オブジェクト“Ｎｏｄｅ＿５Ｎｏｄｅ６”の下位に配したオブジェクトのアクセスという点から、結果として得られる管理ツリーの単純化が行われる。

図３ｅは、本発明の実施形態に基づいて回避されることになるオブジェクトの配置構成を示す図である。上記配置構成には、第１の実行時オブジェクト＜Ｘ＞＊並びに第２の実行時オブジェクト＜Ｙ＞＋という子オブジェクトと直接関連づけられた固定オブジェクト“Ｎｏｄｅ＿７”とが含まれる。第１の実行時オブジェクト＜Ｘ＞＊と第２の実行時オブジェクト＜Ｙ＞＋とは個々に異なるフォーマットのオブジェクトと関連づけられる。これは、第１の実行時オブジェクト＜Ｘ＞＊と第２の実行時オブジェクト＜Ｙ＞＋とが異なる機能およびアプリケーションにそれぞれ関係することを意味する。オブジェクトのフォーマットは、どの種類の管理関連情報をそれぞれのオブジェクト間で配信し、階層を成して配設されたオブジェクトを当該それぞれのオブジェクトの下位オブジェクトとして関連づけることが許されるか、および／または、該管理関連情報が上記配信との関連づけに適しているかを定義するものとする。共通のフォーマットを有するオブジェクトは、同じ装置機能および／または装置用アプリケーションと関連づけられた類似の管理関連情報をこれらのオブジェクトおよび下位に配したオブジェクト間で配信する旨の定義を行う。

管理可能でかつ明瞭な管理ツリーを取得するために、異なるタイプの実行時オブジェクトを、上記の図３ｅに示すように（固定オブジェクトである）共通の親オブジェクトの下位として関連づけないようにすべきである。代わりに、管理対象のクライアント側装置の異なる機能およびアプリケーションに関連する異なるフォーマットの実行時オブジェクトは、それぞれ、（固定オブジェクトである）異なる親オブジェクトと関連づけられ、明瞭に系統的で、利用可能で、かつ、管理可能な管理ツリーが提供されることになる。

図４ａは、本発明の１実施形態に準拠してオブジェクトの定義づけを行う第１の例示フローチャートを示す。例示の第１のフローチャートには、オブジェクトと、該オブジェクトのプロパティと、依存状態との定義づけを行うのために、上記で例示し、説明した規則および規定をそれぞれ考慮する実施形態例が表されている。

処理Ｓ１００で、少なくとも１つの新たなオブジェクトの定義づけ／追加を行う、本発明の１つの実施形態に基づく処理シーケンスが開始される。

処理Ｓ１１０で親オブジェクトのオブジェクトタイプが決定される。新たなオブジェクトに対するこの親オブジェクトは固定オブジェクトまたは実行時オブジェクトであり得る。図３ｃと関連して説明した規則と規定とによれば、階層オブジェクト構造と装置ドキュメントフレームワーク（ＤＤＦ）とにおいて２つの実行時オブジェクトを連続してそれぞれ配設することが回避される。これに対応して、親オブジェクトが実行時オブジェクトであるか、固定オブジェクトであるかのチェックが行われる。親オブジェクトが実行時タイプのものであれば、図示された処理シーケンスは処理Ｓ１４０に続き、連続する実行時オブジェクトの定義および追加を行うことができないことが保証される。親オブジェクトが固定タイプのものであれば、図示された処理シーケンスは処理Ｓ１２０に続き、任意のタイプのオブジェクトを固定オブジェクトである親オブジェクトと関連づけることが可能となる。

処理Ｓ１２０で、新たな実行時オブジェクトの定義／追加を行うかどうかのチェックが行われ、該定義／追加を行う場合、処理シーケンスは処理Ｓ１３０に続く。上記定義／追加を行わない場合には、処理シーケンスは処理Ｓ１４０に続く。

処理Ｓ１３０で、新たな実行時オブジェクトが定義される。上記定義づけには、新たな実行時オブジェクトをその上位に位置する親オブジェクトと階層オブジェクト構造とにそれぞれ関連づける（すなわち追加、含有）処理が含まれる。上記説明した規則と規定とに対応して、上位に位置する親オブジェクトは固定オブジェクトである。新たな実行時オブジェクトのさらなる定義づけは、ＡｃｃｅｓｓＴｙｐｅ、ＤｅｆａｕｌｔＶａｌｕｅ、Ｄｅｓｃｒｉｐｔｉｏｎ、ＤＦＦｏｒｍａｔ、Ｏｃｃｕｒｒｅｎｃｅ、Ｓｃｏｐｅ、ＤＦＴｉｔｌｅおよびＤＦＴｙｐｅを有するさらに別のプロパティエレメントの定義づけを含むものであってもよい。すべての必要なかつ所望のプロパティエレメントの定義づけ並びに新たな実行時オブジェクトの階層オブジェクト構造内への追加を終了した後、新たなオブジェクトの定義づけを行うための処理シーケンスは処理Ｓ２００に続き、そこで処理シーケンスは終了する。上記説明した処理シーケンスを再開することにより、さらに別の新たなオブジェクトの定義づけを行うことも可能である。

処理Ｓ１４０で、新たな固定オブジェクトを定義するかどうかのチェックが行われ、定義する場合には、処理シーケンスは処理Ｓ１５０に続く。そうでない場合には、処理シーケンスは処理Ｓ１６０に続く。

処理Ｓ１５０で新たな固定オブジェクトが定義される。上記定義づけには、新たな固定親オブジェクトをその上位に位置する親オブジェクトおよび階層オブジェクト構造とにそれぞれ関連づける（すなわち追加、含有）処理が含まれる。上記説明した規則と規定とに対応して、上位に位置する親オブジェクトは、固定親オブジェクトか、実行時（親）オブジェクトかのいずれかである。新たな固定親オブジェクトのさらなる定義づけは、ＡｃｃｅｓｓＴｙｐｅ、ＤｅｆａｕｌｔＶａｌｕｅ、Ｄｅｓｃｒｉｐｔｉｏｎ、ＤＦＦｏｒｍａｔ、Ｏｃｃｕｒｒｅｎｃｅ、Ｓｃｏｐｅ、ＤＦＴｉｔｌｅおよびＤＦＴｙｐｅを有するさらに別のプロパティエレメントの定義づけを含むものであってもよい。すべての必要なかつ所望のプロパティエレメントの定義づけ並びに新たな固定親オブジェクトの階層オブジェクト構造内への追加を終了した後、新たなオブジェクトの定義づけを行うための処理シーケンスは処理Ｓ２００に続き、そこで処理シーケンスは終了する。上記説明した処理シーケンスを再開することにより、さらに別の新たなオブジェクトの定義づけを行ってもよい。

処理Ｓ１６０で、新たな葉オブジェクトを定義するかどうかのチェックが行われ、新たな葉オブジェクトを定義する場合には、処理シーケンスは処理Ｓ１７０に続く。新たな葉オブジェクトを定義しない場合には、処理シーケンスは処理Ｓ１８０に続く。

処理Ｓ１７０で新たな葉オブジェクトが定義される。上記定義づけには、上位に位置する親オブジェクトと階層オブジェクト構造とのそれぞれに新たな葉オブジェクトを関連づける（すなわち追加、含有）処理が含まれる。上記説明した規則と規定とに対応して、上位に位置する親オブジェクトは、固定親オブジェクトか、実行時（親）オブジェクトかのいずれかである。新たな葉オブジェクトのさらなる定義づけは、ＡｃｃｅｓｓＴｙｐｅ、ＤｅｆａｕｌｔＶａｌｕｅ、Ｄｅｓｃｒｉｐｔｉｏｎ、ＤＦＦｏｒｍａｔ、Ｏｃｃｕｒｒｅｎｃｅ、Ｓｃｏｐｅ、ＤＦＴｉｔｌｅおよびＤＦＴｙｐｅを有するさらに別のプロパティエレメントの定義づけを含むものであってもよい。すべての必要なかつ所望のプロパティエレメントの定義づけ並びに新たな葉オブジェクトの階層オブジェクト構造内への追加を終了した後、新たなオブジェクトの定義づけを行うための処理シーケンスは処理Ｓ２００に続き、そこで処理シーケンスは終了する。上記説明した処理シーケンスを再開することにより、さらに別の新たなオブジェクトの定義づけを行ってもよい。

処理Ｓ１８０で新たなリンクオブジェクトを定義するかどうかのチェックが行われ、定義する場合には、処理シーケンスは処理Ｓ１９０に続く。本発明では４つの異なるタイプのオブジェクトが提示される。これに対応して、チェック処理Ｓ１２０、Ｓ１４０、Ｓ１６０、Ｓ１８０によってこれら４つのタイプがカバーされる。装置定義フレームワーク（ＤＤＦ）の中へ１または２以上のさらに別のタイプのオブジェクトを含むことも可能であることを付記しておく。新たなリンクオブジェクトが定義されない場合、その時点での状況に従って、処理シーケンスは処理Ｓ２００に続く。すなわち何らかの新たなオブジェクト定義がなければ処理シーケンスは終了する。それぞれのタイプのオブジェクトと関連して上述した上記チェック処理、定義づけ処理および定義づけ処理と同様に、本処理シーケンスに対するチェック処理、定義づけ処理および追加処理を１または２以上のさらに別のタイプのオブジェクトに関して実行することも可能である。

処理Ｓ１９０で新たなリンクオブジェクトが定義される。上記定義づけには、新たなリンクオブジェクトをその上位に位置する親オブジェクトと階層オブジェクト構造とにそれぞれ関連づける（すなわち追加、含有）処理が含まれる。上記説明した規則と規定とに対応して、上位に位置する親オブジェクトは、固定親オブジェクトか、実行時（親）オブジェクトかのいずれかである。新たなリンクオブジェクトのさらなる定義づけは、ＡｃｃｅｓｓＴｙｐｅ、ＤｅｆａｕｌｔＶａｌｕｅ、Ｄｅｓｃｒｉｐｔｉｏｎ、ＤＦＦｏｒｍａｔ、Ｏｃｃｕｒｒｅｎｃｅ、Ｓｃｏｐｅ、ＤＦＴｉｔｌｅおよびＤＦＴｙｐｅを有するさらに別のプロパティエレメントの定義づけを含むものであってもよい。すべての必要かつ所望のプロパティエレメントの定義づけ並びに新たなリンクオブジェクトの階層オブジェクト構造内への追加処理を終了した後、新たなオブジェクトの定義づけを行うための処理シーケンスは処理Ｓ２００に続き、そこで処理シーケンスは終了する。上記説明した処理シーケンスを再開することにより、さらに別の新たなオブジェクトの定義づけを行ってもよい。

処理Ｓ２００において、本発明の１つの実施形態に基づく１つの新たなオブジェクトの定義づけ／追加処理は終了する。

実行時オブジェクトが、階層オブジェクト構造で連続して配設されないことが保証される上記提示の処理シーケンスとは別に、２つの連続して配設された実行時オブジェクトの間に固定オブジェクトを追加並びに挿入する操作も上記規定を実現するものであることを付記しておく。連続する実行時オブジェクト内に固定オブジェクトを挿入することによって、上記連続する配置構成が妨げられ、この結果として生じる同じ階層オブジェクト構造へ最終的に導かれる。

本発明の（改善された）別の実施形態によれば、処理シーケンスは、追加のクライアントオブジェクトとして直接関連づけようとしている新たなオブジェクトの親オブジェクトに既に関連づけられている実行時オブジェクトのオブジェクトフォーマットのチェックも考慮する。図３ｅと関連して、対応する規則と規定について以下詳細に説明する。

処理Ｓ１３０で親オブジェクトの既存の“並列”子オブジェクトが決定される。既存の記述子オブジェクトが存在する場合、異なるフォーマットの実行時オブジェクトと同じ親オブジェクトとの関連づけは回避することが望ましい。或る一定のフォーマットを有する既存の実行時オブジェクトと並列に関連づけるように、異なるフォーマットの実行時オブジェクトを定義する場合、定義づけは拒絶され、処理シーケンスは処理Ｓ２００に続く。すなわち処理シーケンスは終了する。

本発明の（改善された）別の実施形態によれば、上記処理シーケンスは、（追加の）クライアントオブジェクトとして直接関連づけようとしている新規オブジェクトに対する親オブジェクトは既に関連づけられているオブジェクトのオブジェクトタイプのチェックも考慮する。図３ｄと関連して、対応する規則と調整について以下詳細に説明する。

処理Ｓ１５０で親オブジェクトの既存の“並列”子オブジェクトが決定される。“並列”記述子オブジェクトが存在せず、親オブジェクトが固定オブジェクトの場合、新たな固定オブジェクトと、既存の上位に関連づけられた固定親オブジェクトとが新たな単一の固定オブジェクトに集約されて、親オブジェクトの置き換えを行い、階層オブジェクト構造と装置定義フレームワーク（ＤＤＦ）とをそれぞれ単純化する。

図４ｂは、本発明の１実施形態に準拠する装置定義フレームワーク（ＤＤＦ）およびＤＤＦドキュメントの少なくとも一部の定義づけと作成とをそれぞれ例示する第２の例示フローチャートを示す。この処理シーケンスには、本発明の１つの実施形態によれば図４ａに描かれた処理シーケンスが含まれる。

処理Ｓ３００で、本発明の実施形態に基づく新たなオブジェクトの定義づけに基づいてＤＤＦドキュメントを作成する上記処理シーケンスが開始される。

処理Ｓ３１０でオブジェクトが定義される。デフォルトによりルートオブジェクトが存在する。すなわち、このルートオブジェクトによって、装置定義フレームワーク（ＤＤＦ）が構造化され、それによってＤＤＦドキュメントを組み立てる相対的な基準としての基礎が形成される。処理Ｓ３１０でのオブジェクトの定義づけには、図４ａを参照しながら詳述した、図４ａに示した処理が含まれる。

処理Ｓ３２０で、結果として生じる定義済みの新たなオブジェクトは、処理Ｓ３１０で実行した定義に基づいてＤＤＦドキュメントにおいて符号化される。ＤＤＦドキュメントの符号化は拡張マークアップ言語（ＸＭＬ）符号化に基づくものであってもよい。ＸＭＬ符号化は、ＤＤＦドキュメントに必要なＸＭＬ符号化の言語エレメントを定義づける対応するドキュメントタイプ記述（ＤＴＤ）で提供されるタイプ記述に基づいて行われる。ＸＭＬ符号化は２進符号化ＸＭＬ符号化などの任意の適切なＸＭＬ符号化であってもよい。

処理Ｓ３３０で、別の新たなオブジェクトが現時点の装置定義フレームワークとＤＤＦドキュメントにそれぞれ追加されるべきである場合、処理シーケンスは処理Ｓ３１０へ戻る。新たなオブジェクトが追加されない場合、現時点の装置定義フレームワークとＤＤＦドキュメントはそれぞれ完了する。すなわち、別のオブジェクトは追加されず、処理シーケンスは処理Ｓ３４０に続く。

処理Ｓ３４０で、結果として生じる装置定義フレームワークとＤＤＦドキュメントとは、格納され、管理用サーバ側および／または管理対象のクライアント側装置へそれぞれ送信されて、管理ツリーの確定、生成、変更などに利用することができる。さらに、結果として生じる装置定義フレームワークとＤＤＦドキュメントとはそれぞれ処理されて、管理ツリーの少なくとも一部の生成が図られる。装置定義フレームワークとＤＤＦドキュメントとのそのような処理は図４ｃを参照しながら、後にそれぞれ説明する。

処理Ｓ３５０で、本発明の実施形態に基づく新たなオブジェクトの定義づけに従って行われるＤＤＦドキュメントの作成処理シーケンスは終了する。

新たなオブジェクトの定義づけを行う処理Ｓ３１０と、新たなオブジェクトを符号化する処理Ｓ３２０とを分離処理として説明したことを付記しておく。処理Ｓ３１０と処理Ｓ３２０の双方を包括処理として具現化し、定義づけと符号化との同時処理を図ることも可能であると理解すべきである。

図４ｃは、本発明の１実施形態に準拠する装置定義フレームワークとＤＤＦドキュメントとにそれぞれ基づいて、管理ツリーの少なくとも一部の構文解析と生成とを行う第３の例示フローチャートを示す。

処理Ｓ４００で、本発明の実施形態に基づく装置定義フレームワークとＤＤＦドキュメントとに基づいて、管理ツリーの少なくとも１部を作成／生成する処理シーケンスがそれぞれ開始される。

処理Ｓ４１０で、それに対応して管理ツリーのオブジェクトが生成されることになる装置定義フレームワークと符号化されたオブジェクトを有するＤＤＦドキュメントとが格納用装置から検索され、或いは、装置管理用サーバや電子装置メーカーのサポート用サーバなどのエンティティから受信される。例えば、管理対象のクライアント側装置が装置定義フレームワークとＤＤＦドキュメントとを管理用サーバ側から受信するか、或いは管理用サーバがＤＤＦ出力用のネットワーク化したサーバから受信するようにしてもよい。前述のように、装置定義フレームワークとＤＤＦドキュメントとのそれぞれの可用性によって、処理用装置が有効かつ適切な管理ツリー構造を生成することが可能となり、装置定義フレームワークとＤＤＦドキュメントの適用性が保証される。

処理Ｓ４２０で、装置定義フレームワークとＤＤＦドキュメントとの構文解析がそれぞれ行われる。この構文解析は、情報の抽出および／または構文解析による取得情報の解釈を含むものであってもよい。本願で具現化されているようにオブジェクト毎に上記構文解析処理を行ってもよいし、あるいは、ブロック毎に処理を行ってもよい。すなわち１組の関連する記述オブジェクトの構文解析を行うことによって処理を行うようにしてもよい。装置定義フレームワーク（ＤＤＦ）とＤＤＦドキュメントとの構文解析にはそれぞれ特定の処理がさらに含まれ、装置定義フレームワークとＤＤＦドキュメントとの全体から、それぞれ、所望のオブジェクト情報の構文解析／抽出を行うようにしてもよい。

処理Ｓ４３０で、処理Ｓ４２０により取得した情報に基づいて、１乃至いくつかのオブジェクトが生成される。個々のオブジェクトの生成は、装置定義フレームワークとＤＤＦドキュメントとの中にそれぞれ含まれるオブジェクト情報に対応して実行される。これら生成されたオブジェクトは、生成されるべき管理ツリーの少なくとも一部に含まれる。装置定義フレームワークとＤＤＦドキュメントとでそれぞれ定義された階層上の関連性を考慮して新たなオブジェクトの追加が実行され、正確な階層構造を持つ管理ツリーの少なくとも一部の生成が図られる。さらに、図４ａを参照しながら、実施形態として、階層オブジェクト構造にオブジェクトを追加する方法を適用して、（ＤＤＦドキュメントが前述の規則と規定とを考慮しない場合であっても）結果として生じる階層を成すオブジェクトツリー（管理ツリー）によって本発明による規則と規定とを満たすように保証することが可能となる。

必要に応じて、処理Ｓ４３０で１または２以上の値が新たな生成済みオブジェクトに割り当てられる。

処理Ｓ４４０で、所望のオブジェクト情報の構文解析／抽出をオブジェクト毎に行い、かつ、管理ツリーの少なくとも一部の生成が終了していない場合、処理シーケンスは別の所望のオブジェクト情報の構文解析／抽出処理Ｓ４２０へ戻る。管理ツリーの少なくとも一部の生成が終了した場合、管理ツリーの少なくとも一部の生成は終了し、処理シーケンスは処理Ｓ４５０に続く。

処理Ｓ４５０で、結果として生じる生成済み管理ツリーの少なくとも一部が適用される。結果として生じる管理ツリーの少なくとも一部の適用は、管理対象のクライアント側装置における管理ツリーの設定、１またはそれ以上の装置機能および／またはアプリケーションが必要とする追加構成データや設定値を管理ツリーに追加するための既存の管理ツリー内への追加ブランチの実現であってもよい。さらに、結果として生じた管理ツリーの少なくとも一部を管理対象のクライアント側に実装するために、管理用サーバが管理ツリーの少なくとも一部を生成し、管理対象のクライアント側へ送るようにしてもよい。

結果として生じる管理ツリーの少なくとも一部の適用は、上述のＳｙｎｃＭＬ装置管理サービスおよび管理用ドキュメントの交換と関連して理解すべきである。

処理Ｓ４６０で、本発明の実施形態に基づく装置定義フレームワークとＤＤＦドキュメントとに従う管理ツリーの少なくとも一部の作成／生成を行う処理シーケンスはそれぞれ終了する。

次の図５ａは、装置定義フレームワークの例示部分を図示する。図５ｂと図５ｃとは対応するＤＤＦドキュメントを示し、図５ｄは、図５ａに例示の装置定義フレームワークの例に一致し、図５ｂと図５ｃに図示のドキュメントの形で符号化される管理ツリーの例を例示する図である。

図５ａは、本発明の実施形態に基づく装置定義フレームワークの例示部分を示す。この図は、移動データ通信が可能なクライアント装置のアクセスポイント（ＡＰ）の設定に関する。この図は、移動データ通信が可能なクライアント装置の管理ツリーの１または２以上のブランチを導き出すことに基づく関連オブジェクトの一部を示すものである。

アクセスポイント設定値は、ルートオブジェクト“／”と直接関連づけられた最上位レベルの内部オブジェクト“．／ＡＰ”の下にサブサマライズ（subsummarize）される。すなわちオブジェクト“．／ＡＰ”は、ルートオブジェクト“／”の子オブジェクトであり、すべてのアクセスポイント（ＡＰ）設定値に対応する親オブジェクトとなる。これに対応して、描かれた最上位レベルのオブジェクト“．／ＡＰ”は、インスタント識別子“．／ＡＰ”を持つ固定親オブジェクトを定義する。固定親オブジェクト“．／ＡＰ”は固定親オブジェクト“．／ＡＰ”の下位に配した実行時オブジェクト＜Ｘ_１＞＊と関連づけられる。この実行時オブジェクト＜Ｘ_１＞＊によって、対応する内部親オブジェクト“．／ＡＰ”の子オブジェクトである、動的に割り当てられたインスタント識別子を有する１または２以上の対応する内部オブジェクトをいずれも導き出せなくなる。個々のアクセスポイント設定値に関する個々のセットの情報は、実行時オブジェクト＜Ｘ_１＞＊のうちの１つのオブジェクトの下に在る管理ツリーのうちの１つに格納される。これらの実行時オブジェクト＜Ｘ_１＞＊のインスタント識別子は、個々のアクセスポイント設定値が関連する種類のアクセスポイントを示すことが望ましい。

実行時オブジェクト ＜Ｘ_１＞＊の個々の１つは、固定オブジェクト“Ｐｘ”、固定オブジェクト“ＮＡＰＤｅｆ？”、葉オブジェクト“ＣｌｉｅｎｔＩＤ？”および固定オブジェクト“ＢＳ？”と関連づけられる。これらのオブジェクトは、実行時オブジェクト＜Ｘ_１＞＊のうちの個々のオブジェクトの下位に配された管理ツリーに０回または１回発生することが許される。

固定オブジェクト“Ｐｘ”は１または２以上の実行時オブジェクト＜Ｘ_２＞＊に対する親オブジェクトであり、固定オブジェクト“ＮＡＰＤｅｆ？”は１または２以上の実行時オブジェクト＜Ｘ_３＞＊に対する親オブジェクトであり、固定オブジェクト“ＢＳ？”は実行時オブジェクト＜Ｘ_４＞＊に対する親オブジェクトである。固定オブジェクト“Ｐｘ”が管理ツリーの中に存在すると、固定オブジェクト“Ｐｘ”は、動的に定義されたインスタント識別子を有する０、１または２個以上の実行時オブジェクト＜Ｘ_２＞＊を有することができる。同様に、固定オブジェクト“ＮＡＰＤｅｆ？”が管理ツリーの中に存在すると、固定オブジェクト“ＮＡＰＤｅｆ？”は０、１または２個以上の実行時オブジェクト＜Ｘ_３＞＊を有することができ、固定オブジェクト“ＢＳ？”が管理ツリーの中に存在すると、固定オブジェクト“ＢＳ？”は０、１または２個以上の実行時オブジェクト＜Ｘ_４＞＊を有することができる。実行時オブジェクト＜Ｘ_２＞＊と＜Ｘ_３＞＊とのさらなる構造については省略する。

実行時オブジェクト＜Ｘ_４＞＊には、いくつかの子オブジェクト、例えば、葉オブジェクト“Ｎａｍｅ？”、固定親オブジェクト“Ｎｅｔｗｏｒｋ？”、および葉オブジェクト“Ｃｏｕｎｔｒｙ？”などが含まれる。

次いで、固定オブジェクト“Ｎｅｔｗｏｒｋ？”は、固定オブジェクト“Ｎｅｔｗｏｒｋ？”の下位に配した１または２以上の実行時オブジェクト＜Ｘ_５＞＋と関連づけられる。実行時オブジェクト＜Ｘ_５＞＋の定義により、固定オブジェクト“Ｎｅｔｗｏｒｋ？”が存在すれば、少なくとも１または２以上の実行時オブジェクト＜Ｘ_５＞＋は、内部子オブジェクトとして固定オブジェクト“Ｎｅｔｗｏｒｋ？”と関連づけられる。

上記図示した構造内の実行時オブジェクトが少なくとも１つの固定オブジェクトにより常に分離されていること、および、固定オブジェクトの連続的配設が回避されていること、並びに、異なるものではないフォーマットの実行時オブジェクトが１つの（固定／実行時オブジェクト）親オブジェクトの子オブジェクトとして共存して、上記叙述が、上述の規則と規定とをそれぞれ履行するようになっていることが理解できる。

図示された装置定義フレームワークを用いて対応するＤＤＦドキュメントを取得することができる。図に含まれる図形要素の意味を対応するＤＤＦドキュメントに変換して、少なくともＤＤＦドキュメントのフレームワークを取得することができる。

図５ｂは、図５ａに示されたものに対応するＤＤＦドキュメントの抜粋の第１の部分を示す。図５ｃは、図５ｂに示されたＤＤＦドキュメントの抜粋の第２の部分を示す。以下、図５ｂと図５ｃについてまとめて説明する。

以下のＤＤＦドキュメントの抜粋は装置定義フレームワークの拡張マークアップ言語（ＸＭＬ）による符号化に基づくものである。ＸＭＬ符号化は、オブジェクト並びに該オブジェクトのプロパティの定義づけを行うための、ドキュメントタイプ記述定義づけ用タグにさらに基づくものであり、結果として生じるＤＤＦドキュメントを一意的に変換できるようにするものである。ＸＭＬ符号化は、可能な符号化方法を示すボード番号の１つである。以下のＤＤＦドキュメントは、ＳｙｎｃＭＬイニシアチブにより提供される装置定義フレームワーク用のドキュメントタイプ記述に基づくものである。

００１〜００７行にはＤＤＦドキュメントのヘッダセクションが含まれる。上記ヘッダセクションによって、ＸＭＬ符号化バージョン（１.０）、符号化文字（ＵＴＦ−８）、考慮の対象とするＤＴＤのバージョン（１.１）、メーカー（ノキア）、ＤＤＦドキュメントが関係する相手先クライアント側装置のモデル識別子（コメントにより省略）が定義される。

００８〜０１８行には、ＸＭＬ符号化済みＤＤＦドキュメントの一部が含まれ、このＸＭＬ符号化済みＤＤＦドキュメントの一部は、固定オブジェクト“ＡＰ”と、ルートオブジェクト“／”を基準とする相対的な、管理ツリー内の上記固定オブジェクト“ＡＰ”の位置と、上記固定オブジェクト“ＡＰ”のプロパティエレメントとに専用のものである。固定オブジェクト“ＡＰ”の前述のプロパティに対応して、１組のオブジェクトプロパティエレメントがそのプロパティを指定する。詳細には、アクセスが読出し処理に限定され、オブジェクトのフォーマットが内部オブジェクトを指示するノードに設定され、発生回数が１回と定義され、範囲が永続的な範囲とされ、さらに、人間が理解できる記述並びに人間が理解できるタイトルが定義される。

０１９〜０２６行で実行時オブジェクト＜Ｘ_１＞＊が定義される。名称は省かれる。というのは、実行時オブジェクトのインスタンス識別子は実行時に割り当てられるからである。オブジェクトプロパティエレメントによって、追加、削除、取得および置換へのアクセスが指定され、オブジェクトのフォーマットがノードとして定義され、発生回数は０、１または２回以上（ＺｅｒｏＯｒＭｏｒｅ）とされ、さらに、範囲は動的な範囲とされる。人間が理解できるタイトルが定義される。

０２７〜０３７行で固定親オブジェクト“Ｐｘ”が指定される。これに対応して、名称が“Ｐｘ”として定義される。オブジェクトプロパティエレメントは読出し処理に限定されるアクセス（ｇｅｔ）を指定し、オブジェクトのフォーマットがノードとして定義され、発生回数は１とされ、範囲は動的な範囲とされる。人間が理解できるタイトルが定義される。

０３６行で、省略マークは、描かれたＤＤＦドキュメント内での位置であって、実行時オブジェクト＜Ｘ_２＞＊の仕様が含まれている位置を示す。ここに提示されている実行時オブジェクトの仕様の特定と同様にして実行時オブジェクト＜Ｘ_２＞＊の仕様の特定が行なわれる。

０３８〜０４８行で固定オブジェクト“ＮＡＰＤｅｆ？”が指定される。これに対応して、名称が“ＮＡＰＤｅｆ”として定義される。オブジェクトプロパティエレメントが読出し処理に限定されるアクセス（ｇｅｔ）を指定し、オブジェクトのフォーマットがノードとして定義され、発生回数は０または１回とされ、範囲は動的な範囲とされる。人間が理解できるタイトルが定義される。

０４７行で省略マークは、描かれたＤＤＦドキュメント内での位置であって、実行時オブジェクト＜Ｘ_３＞＊の仕様が含まれている位置を示す。ここに提示されている実行時オブジェクトの仕様の特定と同様にして実行時オブジェクト＜Ｘ_３＞＊の仕様の特定が行なわれる。

０４９〜０５９行で葉オブジェクト“ＣｌｉｅｎｔＩＤ？”が指定される。この名称は上記に対応して“クライアントＩｄ”として定義される。オブジェクトプロパティエレメントは、追加、削除、取得および置換へのアクセスを指定し、オブジェクトのフォーマットは、或る葉オブジェクトであるキャラクタフォーマット（ｃｈｒ）として定義され、発生回数は０または１回とされ、範囲は動的な範囲とされる。人間が理解できるタイトルが定義される。葉オブジェクトには情報が含まれる。この種の情報、すなわち情報を表すデータのコンテントタイプフォーマットは予め定義する必要がある。したがって、対応するタイプのエレメント（ＤＦＴｙｐｅ）には格納対象の内容（ここではプレーンテキスト情報）を示すＭＩＭＥタイプ定義が含まれることになる。

０６０〜０６９行で固定親オブジェクト“ＢＳ？”が指定される。この名称は上記に対応して“ＢＳ”として定義される。オブジェクトプロパティエレメントは読出し処理に限定されるアクセス（ｇｅｔ）を指定し、オブジェクトのフォーマットがノードとして定義され、発生回数は０または１回とされ、範囲は動的な範囲とされる。人間が理解できるタイトルが定義される。

０７０〜０７７行で実行時オブジェクト＜Ｘ_５＞＊が定義される。名称は省かれる。というのは、実行時オブジェクトのインスタンス識別子が実行時に割り当てられるからである。オブジェクトプロパティエレメントによって、追加、削除、取得および置換へのアクセスが指定され、オブジェクトのフォーマットがノードとして定義され、発生回数は０、１または２回以上（ＺｅｒｏＯｒＭｏｒｅ）とされ、さらに、範囲は動的な範囲とされる。人間が理解できるタイトルが定義される。

０７８〜０８８行で葉オブジェクト“Ｎａｍｅ？”が指定される。この名称は上記に対応して“Ｎａｍｅ”として定義される。オブジェクトプロパティエレメントは、追加、削除、取得および置換へのアクセスを指定し、オブジェクトのフォーマットは、或る葉オブジェクトであるキャラクタフォーマット（ｃｈｒ）として定義され、発生回数は０または１回とされ、範囲は動的な範囲とされる。人間が理解できるタイトルが定義される。コンテントタイプはＭＩＭＥタイプ定義によりプレーンテキストとして指定される。

０８９〜１００行で固定親オブジェクト“Ｎｅｔｗｏｒｋ？”が指定される。この名称は上記に対応して“Ｎｅｔｗｏｒｋ”として定義される。オブジェクトプロパティエレメントは読出し処理に限定されるアクセス（ｇｅｔ）を指定し、オブジェクトのフォーマットがノードとして定義され、発生回数は０または１回とされ、範囲は動的な範囲とされる。人間が理解できるタイトルが定義される。

０９８行で、省略マークは描かれたＤＤＦドキュメント内での位置であって、実行時オブジェクト＜Ｘ_５＞＊の仕様が含まれている位置を示す。ここに提示されている実行時オブジェクトの仕様の特定と同様にして、実行時オブジェクト＜Ｘ_５＞＊の仕様の特定が行なわれる。

１０１〜１１０行で葉オブジェクト“Ｃｏｕｎｔｒｙ？”が指定される。この名称は上記に対応して“Ｃｏｕｎｔｒｙ？”として定義される。オブジェクトプロパティエレメントは、追加、削除、取得および置換へのアクセスを指定し、オブジェクトのフォーマットは、或る葉オブジェクトであるキャラクタフォーマット（ｃｈｒ）として定義され、発生回数は０または１回とされ、範囲は動的な範囲される。人間が理解できるタイトルが定義される。コンテントタイプはＭＩＭＥタイプ定義によりプレーンテキストとして指定される。

１１１行で、省略マークは、描かれたＤＤＦドキュメント内での位置であって、実行時オブジェクト＜Ｘ_５＞＊と関連づけられたさらに別のオブジェクトが含まれている位置を示す。

図５ａ示される装置定義フレームワークの階層構造は、上記記載の並びに上述の仕様のカプセル化によって装置定義フレームワークとＤＤＦドキュメントとにそれぞれ対応づけられる。

装置定義フレームワークとＤＤＦドキュメントとの採用により、オブジェクト仕様のカプセル化によって実現される階層構造は、この階層構造から引き出される管理ツリーの階層テンプレート構造を表わす。上記とは別に、上記階層構造を定義づける仕様のカプセル化を利用する代わり、オブジェクト仕様に経路情報を追加するようにしてもよい。この経路情報は対応するオブジェクトの階層構造内の位置を指定するものである。

固定オブジェクト“．／ＡＰ”の仕様の範囲は、００７行から始まり１１５行で終る下位に配されたオブジェクトのオブジェクト仕様をカバーするものであり、その場合、固定オブジェクト“．／ＡＰ”の仕様自体は上記カプセル化の中に含まれる。

実行時オブジェクト＜Ｘ_１＞＊の仕様の範囲は０１８行から始まり１１４行で終る下位に配されたオブジェクトのオブジェクト仕様をカバーし、その場合、実行時オブジェクト＜Ｘ_１＞＊の仕様自体は上記カプセル化の中に含まれている。

固定オブジェクト“Ｐｘ”の仕様の範囲は、０２７行から始まり０３７行で終る下位に配されたオブジェクトのオブジェクト仕様をカバーし、その場合、固定オブジェクト“Ｐｘ”の仕様自体は上記カプセル化の中に含まれ、０３６行の省略マークは、階層上、下位に配された省略されたオブジェクト仕様を示している。

固定オブジェクト“ＮＡＰＤｅｆ？”の仕様の範囲は、０３８行から始まり０４８行で終る下位に配されたオブジェクトのオブジェクト仕様をカバーし、その場合、固定オブジェクト“ＮＡＰＤｅｆ？”自体の仕様は上記カプセル化の中に含まれ、０４７行の省略マークは、階層上、下位に配された省略されたオブジェクト仕様を示す。

固定オブジェクト“ＢＳ？”の仕様の範囲は、０６０行から始まり１１３行で終る下位に配されたオブジェクトのオブジェクト仕様をカバーし、その場合、親オブジェクト“ＢＳ？”の仕様自体は上記カプセル化の中に含まれている。

実行時オブジェクト＜Ｘ_４＞＊の仕様の範囲は０６９行で始まり１１２行で終る下位に配したオブジェクトオブジェクト仕様をカバーし、その場合、実行時オブジェクト＜Ｘ_４＞＊の仕様自体は上記カプセル化の中に含まれ、１１１行の省略マークは階層上、下位に配された省かれたオブジェクト仕様を示す。

固定オブジェクト“Ｎｅｔｗｏｒｋ？”の仕様の範囲は０８９行から始まり０９９行で終る下位に配されたオブジェクトのオブジェクト仕様をカバーし、その場合、固定オブジェクト“Ｎｅｔｗｏｒｋ？”の仕様自体は上記カプセル化の中に含まれている。

図５ｄは、本発明の実施形態に基づく、図５ａに例示の装置定義フレームワークに従う管理ツリーの抜粋の例を示す。提示された管理ツリーは、対応するオブジェクトから導き出される複数のオブジェクトから構成され、装置定義フレームワークにより記述された定義済みの階層構造に対応して互いに関連づけられる。

図において固定オブジェクト“．／ＡＰ”は最上位レベルのオブジェクトを表わすものである。すなわち、オブジェクト“．／ＡＰ”は管理ツリーのルートオブジェクト“／”の下位に直接配設され、管理ツリーのルートオブジェクト“／”と関連づけられる。オブジェクト“．／ＡＰ”は、移動通信端末のネットワークアクセスに関する管理関連情報を含むものとする。

オブジェクト“．／ＡＰ”には、３つの子オブジェクト、すなわち、オブジェクト“．／ＡＰ”の下位に直接配設され、オブジェクト“．／ＡＰ”と関連づけられたオブジェクトであるオブジェクト“Ｐｒｏｖ＿１”、オブジェクト“Ｐｒｏｖ＿２”、オブジェクト“Ｐｒｏｖ＿３”並びにさらに別のオブジェクトが含まれる。これらのオブジェクトは、前述の実行時オブジェクト＜Ｘ_１＞＊に対応する実行時オブジェクトである。共通の親の子オブジェクトである実行時オブジェクトを構成する前述の規定によれば、これらすべての実行時オブジェクトは同じ下位構造に対してサービスを提供する必要がある。実行時オブジェクトの実際の下位構造は異なるものであってもよい。というのは、直接および間接に配設され、かつ、下位に関連づけられたオブジェクトは動的なオブジェクトであってもよいからである。しかし、実行時オブジェクト“Ｐｒｏｖ＿１”、オブジェクト“Ｐｒｏｖ＿２”およびオブジェクト“Ｐｒｏｖ＿３”は、これらのオブジェクトが同じ機能またはアプリケーション管理用構成情報とに関係するように設定される。本明細書では、実行時オブジェクト“Ｐｒｏｖ＿１”、オブジェクト“Ｐｒｏｖ＿２”およびオブジェクト“Ｐｒｏｖ＿３”はネットワークサービスプロバイダの構成情報に関係する。固定オブジェクト“．／ＡＰ”はネットワークサービスプロバイダ構成情報に関するすべての管理情報をサブサマライズするように機能する。

実行時オブジェクト“Ｐｒｏｖ＿１”は、２つの子オブジェクトである、オブジェクト“Ｐｘ”とオブジェクト“ＮＡＰＤｅｆ”とを有する。実行時オブジェクトを連続して配設する前述の調整に従って、オブジェクト“Ｐｘ”とオブジェクト“ＮＡＰＤｅｆ”は双方とも固定オブジェクトである。さらに別の可能な直接配設され、下位に関連づけられたオブジェクトに対して定義された発生回数に対応して、葉オブジェクト“ＣｌｉｅｎｔＩＤ”と固定オブジェクト“ＢＳ”とを子オブジェクトとしてオブジェクト“Ｐｒｏｖ＿１”に動的に配設することは可能ではあるが、そのような配設は行うべきではない。本願では、上記可能なさらに別のオブジェクトのいずれもオブジェクト“Ｐｒｏｖ＿１”の管理用サブツリーの中では実現されない。オブジェクト“Ｐｘ”は、ネットワークプロバイダサービス“Ｐｒｏｖ＿１”のプロキシ構成情報に関し、さらに、オブジェクト“ＮＡＰＤｅｆ”はネットワークプロバイダサービス“Ｐｒｏｖ＿１”のネットワークアクセスポイントの定義構成情報に関する。

オブジェクト“Ｐｒｏｖ＿１”の下位に配した固定オブジェクト“Ｐｘ”は実行時オブジェクト“ＤＤＦ＿Ｐｘ”と実行時オブジェクト“Ｐｘ＿１”とを有する。実行時オブジェクト“ＤＤＦ＿Ｐｘ”と実行時オブジェクト“Ｐｘ＿１”との双方は実行時オブジェクト＜Ｘ_２＞＊に対応する。オブジェクト“Ｐｘ”はネットワークプロバイダサービス“Ｐｒｏｖ＿１”のすべてのプロキシ構成情報をサブサマライズするように機能する。さらに別の実行時オブジェクトが、実行時オブジェクト＜Ｘ_２＞＊について考察した際に説明した定義にも対応すれば（すなわち同じ（およびそれぞれ共通の）フォーマットを有するものであれば）、オブジェクト“Ｐｘ”に対する子オブジェクトとして上記別の実行時オブジェクトを関連づけることも許される。

オブジェクト“Ｐｒｏｖ＿１”の下位に配した固定オブジェクト“ＮＡＰＤｅｆ”は実行時オブジェクト“ＮＡＰ＿ｄｅｆ”と実行時オブジェクト“ＮＡＰ＿１”とを有する。実行時オブジェクト“ＮＡＰ＿Ｄｅｆ”と実行時オブジェクト“ＮＡＰ＿１”との双方は実行時オブジェクト＜Ｘ_３＞＊に対応する。オブジェクト“ＮＡＰＤｅｆ”はネットワークプロバイダサービス“Ｐｒｏｖ＿１”のすべてのネットワークアクセスポイント定義構成情報をサブサマライズするように機能する。さらに別の実行時オブジェクトが、実行時オブジェクト＜Ｘ_３＞＊によって設けた定義にも対応すれば（すなわち同じ（およびそれぞれ共通の）フォーマットを有するものであれば）、これらの別の実行時オブジェクトをオブジェクト“ＮＡＰＤｅｆ”に対する子オブジェクトとして関連づけることも許される。

実行時オブジェクト“Ｄｅｆ＿Ｐｘ”並びに“Ｐｘ＿１”の場合、固定オブジェクト“Ｐｘ”は、実行時オブジェクトを分離する前述の規定に対応して上位に配した実行時オブジェクト“Ｐｒｏｖ＿１”から上記実行時オブジェクトを分離する。同様に、実行時オブジェクト“ＮＡＰ＿Ｄｅｆ”並びに“ＮＡＰ＿１”の場合、固定オブジェクト“ＮＡＰＤｅｆ”は、実行時オブジェクトを分離する前述の規定に対応して上位に配した実行時オブジェクト“Ｐｒｏｖ＿１”からこれらの実行時オブジェクトを分離する。

固定オブジェクト“Ｐｒｏｖ＿２”は、３つの子オブジェクトである固定オブジェクト“ＮＡＰＤｅｆ”、葉オブジェクト“ＣｌｉｅｎｔＩＤ”および固定オブジェクト“ＢＳ”を有する。直接配設されかつ上位に関連づけられたオブジェクト“Ｐｒｏｖ＿２”が実行時タイプのオブジェクトであるため、親オブジェクト“ＮＡＰＤｅｆ”並びに親オブジェクト“ＢＳ”はいずれも固定オブジェクトタイプを備えることになる。

オブジェクト“Ｐｒｏｖ＿２”の下位に配した固定親オブジェクト“ＮＡＰＤｅｆ”は１つの子オブジェクト、実行時オブジェクト“ＮＡＰ＿Ｄｅｆ”を有する。

オブジェクト“Ｐｒｏｖ＿２”の下位に配した固定オブジェクト“ＢＳ”は１つの子オブジェクト（実行時親オブジェクト“Ｂｏｏｔ”）を有する。オブジェクト“ＢＳ”はネットワークプロバイダサービスのブートストラップ構成情報“Ｐｒｏｖ＿２”に関する。オブジェクト＜Ｘ_３＞＊に対応して、オブジェクト“ＢＳ”は、双方とも葉オブジェクトタイプを持つ子オブジェクト“Ｎａｍｅ”並びに“Ｃｏｕｎｔｒｙ”を有する。オブジェクト＜Ｘ_３＞＊に対応するさらに別の子オブジェクトをオブジェクト“ＢＳ”に関連づけることも可能である。

図６は、本発明の実施形態に基づく前述の方法を処理するコンポーネントを含む装置を示すブロック図を示す。サーバ側装置管理用エージェント２２０は、別の相手側クライアント装置管理用エージェント３２０を装置管理に提供するネットワーク化されたサービスを表わす。サーバ側装置管理用エージェント２２０またはクライアント側装置管理用エージェント３２０がそれぞれ装置管理用データを提供あるいは処理することが可能である。サーバ側装置管理用エージェント２２０のホストはサーバ２０であり、このサーバ２０は図１を参照して前述したサーバ側装置に対応するサーバ側装置であってもよい。同様に、クライアント側装置管理用エージェント３２０のホストはクライアント３０であり、図１を参照して前述したクライアント側装置に対応するクライアント側装置であってもよい。装置管理はサーバ２０とクライアント３０との間で実行される。

サーバ２０とクライアント３０とは任意のネットワークを介して接続される。ネットワークはサーバ２０とクライアント３０と間で論理通信接続を行い、これにより、装置管理セッションと命名することができる装置管理中にエンドツーエンド通信の確立が可能となる。論理接続および論理接続のベアラの選択が図１に記載されている。

クライアント３０は、同期アダプタ３４０と同期インタフェース３３０と共にクライアント側装置管理用エージェント３２０を使用して、ネットワークにアクセスし、ＳｙｎｃＭＬ ＤＭプロトコル規格に準拠して同期アダプタ３４０と同期インタフェース３３０とを介してサーバへメッセージを送信するようにしてもよい。サーバ２０またはサーバ側装置管理２２０は、それぞれ、同期アダプタ２４０と同期インタフェース２３０を介してメッセージの送受信を行い、サーバ側装置管理用エンジン２１０とを介して装置の管理操作全体の管理を行う。装置管理操作は概念的には装置管理用フレームの中へ結合されるが、この装置管理用フレームは１または２以上の必要なパッケージ用の概念的フレームである。

サーバ側装置管理用エンジン２１０は、ユーザが、良好に構成された装置機能および／または装置の利用を可能にするようにクライアント３０へ送信すべき、或るクライアント側装置の機能に関連する構成データ並びに設定値あるいはクライアント３０を用いて実施可能なアプリケーションなどの、管理対象のクライアント３０に関する情報を含むように適合された装置管理用データベース２００にアクセスする可能性を有する。上記装置管理用データベース２００は、クライアント側装置３０用として有効な管理ツリーの少なくとも一部を導き出すためにメーカーが定義し、提供するＤＤＦドキュメントなどのクライアントに関連づけられた装置定義フレームワーク（ＤＤＦ）情報と、管理ツリー自体の一部分と、操作対象クライアント３０の管理ツリー内での実際の位置に関する情報並びにさらに別の装置管理関連情報とをさらに含むものであってもよい。さらに、サーバ２０のサーバ側装置管理用エンジン２１０は、クライアント３０と交換される装置管理用ドキュメントを生成することができる。この生成は可能である。というのは、ＤＤＦ情報（ＤＤＦドキュメント）によって、サーバ２０が、クライアント３０と交換するのに必要な装置固有の管理用ドキュメントを適切に符号化して、管理関連情報がクライアント３０側に実現された管理ツリーに従うようにすることが可能となるからである。例えば、或る一定のクライアント機能を起動するために或る管理関連情報をクライアントへ送信するものとする。最初に動的に設定された或る一定の管理ツリー領域（或る一定のブランチ）の間でこの管理関連情報をさらに配信するものとする。サーバ２０並びにクライアント３０は装置定義フレームワーク（ＤＤＦ）３１０に関して知られており、サーバ２０がクライアントに指示して、専用の動的な管理ツリー領域の正確なオブジェクト間での管理用小売り送信情報の配信を可能にする適切な方法で、さらに、上記情報を必要とする対応する装置機能および／または装置用アプリケーションへの上記情報の提供を含む正しい方法で、動的な実行の管理と検索とをクライアント３０が行うことを可能にする適切な方法で管理ツリーの動的な拡張処理を行うようになっている。

相手側クライアント３０は、クライアント側装置管理用エージェント３２０を採用して管理要求に対する応答を行うことができる。特に、クライアント側装置管理用エージェント３２０は、該エージェントの装置管理用ツリー３００、および、管理ツリー３００の階層構造とオブジェクトとを定義づける該エージェントの装置定義フレームワーク（ＤＤＦ）３１０へのアクセスを行う。

サーバ２０とクライアント３０の双方は、その中に格納されているＤＤＦ情報（ＤＤＦドキュメント）を利用して、クライアント２０の管理ツリーに対して実行するアクションの符号化を行うようにすることができる。このＤＤＦ情報（ＤＤＦドキュメント）によって、クライアント３０の操作に関する新たなあるいは動的な管理関連情報の格納に必要な管理ツリーの動的な一部の生成が可能となる。ＤＤＦ情報（ＤＤＦドキュメント）に基づく管理ツリーの一部の上記生成は、サーバ側装置管理用エージェント２２０とクライアント側装置管理用エージェント３２０とのそれぞれによって処理されるが、上記生成は、どちらの装置で管理ツリー３００の変更あるいは適合化が処理されるかに依存するものとなる。

主として、装置定義フレームワーク（ＤＤＦ）は、クライアント３０などの或る一定のクライアント側装置のメーカーによってサーバ２０などの装置管理用サーバへ供給され、それによって、該サーバは、クライアント側装置の適切な方法で上述のような管理アクションを生成することにより、上記クライアントを用いて装置管理の操作を行うことが可能となる。さらに、クライアント３０にとって利用可能なＤＤＦ情報（ＤＤＦドキュメント）により、その時点までクライアント３０用の管理ツリーが利用可能でない場合に、クライアント３０のスイッチ・オン時にクライアントが管理ツリーを生成することが可能となる。ＤＤＦ情報（ＤＤＦドキュメント）は、通常行われる、拡張可能で、柔軟な方法で、上記管理ツリーおよび生じる可能性のある管理ツリーをそれぞれ表し、記述するテンプレートとして上述のように機能する。

サーバ２０またはクライアント３０のそれぞれ、サーバ側装置管理用エージェント２２０、サーバ側装置管理用エンジン２１０、装置用データベース２００のそれぞれ、並びに、クライアント側装置管理用エージェント３２０と装置管理用ツリー２００のそれぞれの提示コンポーネントは、サーバ２０またはクライアント３０がそれぞれ具備することができるデータ処理用装置によって構成することも可能である。さらに、必要な処理操作の実行命令を含むコード・セクションによって上記コンポーネントを構成して、サーバ２０側またはクライアント３０側でそれぞれ上記実行命令を実行するようにしてもよい。

技術の進歩に伴って、広範な数の方法で本発明の概念を実現できることは当業者には明らかである。したがって、本発明並びにその実施形態は上記記載の例に限定されるものではなく、特許請求の範囲で変更することも可能である。

装置間で情報の同期処理作を行うことができる１組の例示電子装置を図示するブロック図を示す。 例示管理ツリーの一部全体を示す。 装置定義フレームワークのオブジェクトのグラフ表記に使用するエレメントを例示する表を示す。 装置定義フレームワークのオブジェクトのグラフ表記用として追加して使用される特殊キャラクタを例示する表を示す。 本発明の実施形態に基づく記述オブジェクトの第１の配置構成を示す。 本発明の実施形態に基づく記述オブジェクトの第２の配置構成を示す。 本発明の実施形態に基づいて回避される記述オブジェクトの配置構成を示す。 本発明の実施形態に基づいて単一の記述オブジェクトに集約される記述オブジェクトの配置構成を示す。 本発明の実施形態に基づいて回避される記述オブジェクトの配置構成を示す。 本発明の実施形態に基づく記述オブジェクトの定義づけを例示する第１のフローチャートを示す。 本発明の１実施形態に準拠してＤＤＦドキュメントの少なくとも一部の定義づけと作成とをそれぞれ例示する第２のフローチャートを示す。 本発明の実施形態に基づいて、ＤＤＦドキュメントに基づく管理ツリーの少なくとも一部の構文解析と生成とを例示する第３の例示フローチャートを示す。 本発明の実施形態に基づく装置定義フレームワークの抜粋の例を示す。 図５ａに対応し、本発明の実施形態に基づくＤＤＦドキュメントの抜粋の第１の部分を示す。 本発明の実施形態に基づく図５ｂに図示のＤＤＦドキュメントの抜粋の第２の部分を示す。 本発明の実施形態に基づく図５ａに例示の装置定義フレームワークに従う管理ツリーの抜粋の例を示す。 本発明の実施形態に準拠する前述の方法を処理するコンポーネントを含む装置を例示するブロック図を示す。

Claims (13)

1. コンピュータおよびソフトウェアプログラムにより実現される装置において、
   前記装置により、階層的に関連付けられた複数のオブジェクトを具備する階層オブジェクト構造の一部を提供することと、
   ここで前記複数のオブジェクトは固定オブジェクトタイプおよび実行時オブジェクトタイプを少なくとも含むグループの中からの異なるタイプのオブジェクトを含み、前記固定オブジェクトタイプは固定タイトルを有し、前記実行時オブジェクトは実行中に定義可能なタイトルを有し、
   前記装置により、親オブジェクトの前記タイプをチェックすることと、
   前記装置により、子オブジェクトの前記タイプをチェックすることと、
   ここで前記親オブジェクトと前記子オブジェクトは前記階層オブジェクトの一部であって互いに階層的に直接的に配置され、
   前記親オブジェクトと前記子オブジェクトが実行時オブジェクトタイプであれば、
   前記装置により、少なくとも１つの新規オブジェクトを、直接の上位に配置された前記親オブジェクトと直接の下位に配置された前記子オブジェクトとの間に包含させるべく定義することと、を具備する方法であって、
   前記新規オブジェクトは前記固定オブジェクトタイプであり、
   前記複数のオブジェクトは、階層ノード構造を有する相応の装置記述を導き出すテンプレートオブジェクトの役割を果たし、
   複数の前記ノードを具備する前記階層ノード構造は、被管理電子装置の管理ツリーの少なくとも一部を確立すべく採用されており、管理関連情報は前記管理ツリーの前記少なくとも一部に分散される、方法。
2. 前記装置により、前記親オブジェクトがその直接の下位に配置された１以上の関連オブジェクトを既に有しているかをチェックすることと、
   前記装置により、前記１以上の既に存在する関連オブジェクトと前記子オブジェクトの前記タイプを比較することとを具備し、
   少なくとも１つの前記１つ以上の既に存在するオブジェクトが前記実行時オブジェクトであれば、前記新規オブジェクトの前記定義は、前記装置により、拒絶される請求項１記載の方法。
3. 前記親オブジェクトが固定オブジェクトタイプであるかチェックすることと、
   前記親オブジェクトがその直接の下位に配置された１以上の関連オブジェクトを既に有しているかをチェックすることを具備し、
   前記親オブジェクトが関連オブジェクトを既に持たず、前記親オブジェクトが前記固定オブジェクトタイプであれば、前記親オブジェクトと前記１つ以上の既に存在する関連オブジェクトが、固定オブジェクトタイプである１つの結合された新規オブジェクトに集約される請求項１記載の方法。
4. 前記新規オブジェクトの前記定義に基づき、前記新規オブジェクトに関する情報を含む前記記述ドキュメントの少なくとも一部を符号化することを具備する請求項１記載の方法。
5. 前記階層オブジェクト構造が装置定義フレームワークの一部である情報であり、
   前記階層ノード情報がＳｙｎｃＭＬイニシャチブによって定義される同期マークアップ言語装置管理用規格に準拠する装置管理用として採用された前記管理ツリーのテンプレートである請求項１記載の方法。
6. 記述ドキュメントが装置定義フレームワークドキュメントの少なくとも一部であり、前記装置定義フレームワークドキュメントが、対応する記述フレームワークドキュメントタイプ記述に準拠して符号化された、拡張マークアップ言語で符号化されたドキュメントである請求項１に記載の方法。
7. 処理装置、ネットワーク化された装置、ネットワーク化されたサーバ、端末装置または通信端末装置上で実行されるとき、請求項１〜６のいずれか１項記載の方法を実現する、プログラムコード部分を具備するプログラム。
8. 階層的に関連付けられた複数のオブジェクトを具備する階層オブジェクト構造の一部を具備する装置であり、
   ここで前記複数のオブジェクトは固定オブジェクトタイプおよび、実行時オブジェクトタイプを少なくとも含むグループの中からの異なるタイプのオブジェクトを含み、
   前記固定オブジェクトタイプは固定タイトルを有し、前記実行時オブジェクトは実行中に定義されるタイトルを有し、
   前記装置の処理ユニットは、親オブジェクトのタイプをチェックすることと、
   子オブジェクトのタイプをチェックすることと、
   ここで前記親オブジェクトと前記子オブジェクトは前記階層化オブジェクト構造の一部であって互いに階層的に直接的に配置され、
   ここで前記親オブジェクトと前記子オブジェクトが前記固定オブジェクトタイプであれば、
   少なくとも１つの新規オブジェクトを、直接の上位に配置された前記親オブジェクトと直接の下位に配置された前記子オブジェクトとの間に包含させるべく定義することとを行うように構成されるものであり、
   前記新規オブジェクトは前記固定オブジェクトタイプであり、
   前記複数のオブジェクトは、階層ノード構造を有する相応の装置記述を導き出すテンプレートオブジェクトの役割を果たし、
   複数の前記ノードを具備する前記階層ノード構造は、被管理電子装置の管理ツリーの少なくとも一部を確立するべく採用されており、管理関連情報は前記管理ツリーの前記少なくとも一部に分散される、装置。
9. 前記階層オブジェクト構造から前記階層ノード構造の少なくとも一部を生成して前記管理ツリーの前記一部を確立し前記被管理電子装置に前記管理ツリーの前記一部を実装することを可能にするように構成された装置管理用エージェントをさらに具備し、
   前記装置管理用エージェントは、前記管理関連情報を前記管理ツリーの前記一部に分散させるべく構成され、
   前記装置管理用エージェントは、前記電子装置および前記被管理電子装置上で実行されるアプリケーションの少なくとも１つの機能を構成するために、装置管理データベースについて前記管理関連情報の少なくとも一部を検索するように構成される請求項８記載の装置。
10. 管理サーバと、
    被管理クライアントとを具備する管理システムであって、
    前記管理サーバは、階層的に関連付けられた複数のオブジェクトを具備する階層オブジェクト構造の一部を具備し、
    前記複数のオブジェクトは固定オブジェクトタイプおよび実行的オブジェクトタイプを少なくとも含むグループの中からの異なるタイプのオブジェクトを具備し、
    前記固定オブジェクトタイプは固定タイトルを有し、前記実行的オブジェクトは実行中に定義されるタイトルを有し、
    前記管理サーバは、
    親オブジェクトのタイプをチェックすることと、
    子オブジェクトのタイプをチェックすることと、
    ここで前記親オブジェクトと前記子オブジェクトは前記階層オブジェクトの一部であって互いに階層的に直接的に配置され、
    前記親オブジェクトと前記子オブジェクトが前記固定オブジェクトタイプであれば、少なくとも１つの新規オブジェクトを、直接の上位に配置された前記親オブジェクトと直接の下位に配置された前記子オブジェクトの間に包含させるべく定義することと、を具備し、
    前記新規オブジェクトは前記固定オブジェクトタイプであり、
    前記複数のオブジェクトは、階層ノード構造を有する相応の装置記述を導き出すテンプレートオブジェクトの役割を果たし、
    複数の前記ノードを具備する前記階層ノード構造は、前記被管理クライアントの管理ツリーの少なくとも一部を確立すべく採用されており、管理関連情報は前記管理ツリーの前記少なくとも一部に分散される、管理システム。
11. 前記被管理クライアントは、
    前記装置記述から管理ツリーの前記少なくとも一部を生成して被管理クライアントに実装するように構成された装置管理用エージェントをさらに具備し、
    管理ツリーの前記少なくとも一部は、前記被管理クライアントの管理関連情報を分散させるべく採用されており、
    前記装置管理用エージェントは、管理関連情報を管理ツリーの前記少なくとも一部に分散させるべく構成され、
    前記装置管理用エージェントは前記被管理クライアント上で実行される機能またはアプリケーションを構成するために、管理ツリーの前記少なくとも一部から前記管理関連情報の少なくとも一部を検索するようにさらに構成される、請求項１０記載の管理システム。
12. 前記被管理クライアントは移動データ通信可能な装置である請求項１１記載の管理システム。
13. 前記管理サーバと被管理クライアントはデータ通信接続を介して通信する請求項１１記載の管理システム。

Images