JP2016525728A - 無線通信システムにおけるサーバーの端末のリソース要請又は端末のリソース提供のための方法及びこのための装置 - Google Patents

Abstract

【課題】ＭＯインスタンスに割り当てられたキャッシュ検証子を用いたＭＯデータ要請を処理するための方法を提供する。【解決手段】ＭＯインスタンスは、一つ以上のノードからなるツリー構造で構成され、ＭＯデータは、ＭＯインスタンスに含まれたノードの名前、ノードの値及びノードの構造を含み、方法は、端末によって行われ、サーバーからＭＯインスタンスの特定ＭＯデータを要請するためのＭＯデータを識別するＵＲＩ情報を受信し、ＵＲＩ情報に第１のＣＶが含まれているか否かを判断し、ＵＲＩ情報に第１のＣＶが含まれていないと、要請された特定ＭＯデータをサーバーに伝送し、ＵＲＩ情報が前記ＭＯインスタンスのルート（ｒｏｏｔ）ノードを指示すると、ＭＯインスタンスに対する第２のＣＶを伝送する。【選択図】図５

Description

本発明は、無線通信システムにおけるサーバーの端末のリソース要請又は端末のリソース提供のための方法及びこのための装置に関し、より詳細には、キャッシュ検証子を用いたリソース要請又は提供方法に関する。

一般に、装置管理（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ；ＤＭ）技術は、装置管理サーバーが効果的な方法で特定装置に格納された変数や客体の値を遠隔的に制御することによって、その装置の設定を変更できる技術である。装置管理技術は、ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）でＳｙｎｃＭＬイニシアティブ（Ｉｎｉｔｉａｔｉｖｅ）（Ｓｙｎｃｈｒｏｎｉｓａｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）フォーラムで作成したＳｙｎｃｈＭＬデータ同期化（Ｄａｔａ Ｓｙｎｃｈｒｏｎｉｓａｔｉｏｎ）を基盤にして国際規格として開発進行中にあり、既に他の標準化団体と全世界の通信事業者達に、事実上、今後の装置管理技術表準として受け入れられている。ＯＭＡ装置管理技術は、他の装置管理技術に比べて最も多様な機能をサポートする規格であって、装置管理プロトコル規格、装置管理文書表現方式に関する規格、伝送プロトコルとの連結（ｂｉｎｄｉｎｇ）に関する規格、装置管理ツリーと装置管理ノードに関する規格、ＤＤＦ（Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）に関する規格、通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）に関する規格などを含む。

このような装置管理は、装置の内部に存在する管理客体（Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ；ＭＯ）に対する命令を装置管理サーバー（ＤＭＳ）が装置に伝送し、装置の装置管理クライアント（ＤＭＣ）が命令を行うことによって達成することができる。ＤＭＣは、装置に搭載され、ＤＭＳからの命令を受けて行うエンティティに該当する。ＭＯは、装置の内部に存在する管理ツリー（又はツリー）又はツリーのノードと論理的に連結されている。したがって、装置管理サーバーは、ＭＯに対する命令を通じて命令の対象となるＭＯ又はこのようなＭＯと連関したツリー又はノードに対する制御を行うことができる。ＭＯは、一般に装置のデータベースに存在し、装置管理サーバーは、ＭＯにツリー又はノードのＵＲＩを介して接近し、管理命令を指示することができる。

本発明は、無線通信システムにおけるサーバーの端末のリソース要請方法及び端末のリソース提供方法及びこのための装置を提案しようとする。

本発明で達成しようとする技術的課題は、前記技術的課題に制限されず、言及していない他の技術的課題は、下記の記載から本発明の属する技術分野で通常の知識を有する者に明確に理解され得るだろう。

本発明の一実施例に係るＭＯ（Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）インスタンスに割り当てられたキャッシュ検証子（ｃａｃｈｅ ｖａｌｉｄａｔｏｒ；ＣＶ）を用いたＭＯデータの要請を処理するための方法であって、前記方法は端末によって行われ、前記ＭＯインスタンスは、一つ以上のノードからなるツリー構造で構成され、前記ＭＯデータは、前記ＭＯインスタンスに含まれたノードの名前、ノードの値及びノードの構造を含み、前記方法は、サーバーから前記ＭＯインスタンスの特定ＭＯデータを獲得するための前記特定ＭＯデータを識別するＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）情報を含む要請を受信すること、及び前記ＵＲＩ情報に第１のＣＶが含まれているか否かを判断することを含み、前記ＵＲＩ情報に前記第１のＣＶが含まれていないと、前記要請された特定ＭＯデータを前記サーバーに伝送すること、及び前記ＵＲＩ情報が前記ＭＯインスタンスのルート（ｒｏｏｔ）ノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを伝送することを含むことができる。

好ましくは、前記ＵＲＩ情報に前記第１のＣＶが含まれていると、前記第１のＣＶを検証することを含み、前記第１のＣＶが有効なものと検証されると、前記第１のＣＶが有効であることを指示する結果を前記サーバーに伝送することを含み、前記第１のＣＶが有効でないものと検証されると、前記要請された特定ＭＯデータを前記サーバーに伝送すること、及び前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを伝送することを含むことができる。

好ましくは、前記ＭＯインスタンスに変更が発生すると、前記方法は、前記ＭＯインスタンスに対する第２のＣＶをアップデートすることを含むことができる。

好ましくは、前記ＭＯインスタンスは、キャッシュが設定可能な（ｃａｃｈｅａｂｌｅ）ものであり得る。

好ましくは、前記第１のＣＶは、前記ＵＲＩに含まれた特定フィールドによって提供することができる。

好ましくは、前記ＭＯインスタンスに何ら変更も発生していないと、前記第１のＣＶは有効であると判断することができる。

本発明の他の一実施例に係るＭＯ（Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）インスタンスに割り当てられたキャッシュ検証子（ｃａｃｈｅ ｖａｌｉｄａｔｏｒ；ＣＶ）を用いたＭＯデータを要請するための方法であって、前記方法はサーバーによって行われ、前記ＭＯインスタンスは、一つ以上のノードからなるツリー構造で構成され、前記ＭＯデータは、前記ＭＯインスタンスに含まれたノードの名前、ノードの値及びノードの構造を含み、前記方法は、前記ＭＯインスタンスの特定ＭＯデータを獲得するための前記特定ＭＯデータを識別するＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）情報を含む要請を前記端末に伝送することを含み、前記ＭＯインスタンスに対する第１のＣＶを知っていると、前記ＵＲＩ情報に前記第１のＣＶを含ませ、前記ＭＯインスタンスに対する第１のＣＶを知っていないと、前記ＵＲＩ情報に前記第１のＣＶを含ませず、前記ＵＲＩ情報に前記第１のＣＶが含まれないと、前記要請された特定ＭＯデータを前記端末から受信すること、及び前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを受信することを含むことができる。

好ましくは、前記ＵＲＩ情報に前記第１のＣＶが含まれると、前記端末によって前記第１のＣＶが検証され、前記第１のＣＶが有効なものと検証されると、前記第１のＣＶが有効であることを指示する結果を前記端末から受信することを含み、前記第１のＣＶが有効でないものと検証されると、前記要請された特定ＭＯデータを前記端末から受信すること、及び前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを前記端末から受信することを含むことができる。

好ましくは、前記ＭＯインスタンス内の特定リソースが変更されると、前記ＭＯインスタンスに対する第２のＣＶはアップデートすることができる。

好ましくは、前記ＭＯインスタンスは、キャッシュが設定可能な（ｃａｃｈｅａｂｌｅ）ものであり得る。

好ましくは、前記第１のＣＶは、前記ＵＲＩに含まれた特定フィールドによって提供することができる。

好ましくは、前記ＭＯインスタンスに何ら変更も発生していないと、前記第１のＣＶが有効なものと判断することができる。

本発明の他の一実施例に係るＭＯ（Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）インスタンスに割り当てられたキャッシュ検証子（ｃａｃｈｅ ｖａｌｉｄａｔｏｒ；ＣＶ）を用いたＭＯデータ要請を処理するための端末であって、前記ＭＯインスタンスは、一つ以上のノードからなるツリー構造で構成され、前記ＭＯデータは、前記ＭＯインスタンスに含まれたノードの名前、ノードの値及びノードの構造を含み、前記端末は、無線周波数（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ、ＲＦ）ユニット、及び前記ＲＦユニットを制御するように構成されたプロセッサを含み、前記プロセッサは、サーバーから前記ＭＯインスタンスの特定ＭＯデータを要請するための前記特定ＭＯデータを識別するＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）情報を含む要請を受信し、前記ＵＲＩ情報に第１のＣＶが含まれているか否かを判断するように構成され、前記ＵＲＩ情報に前記第１のＣＶが含まれていないと、前記プロセッサは、前記特定ＭＯデータを前記サーバーに伝送し、前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを伝送するように構成することができる。

本発明の他の一実施例に係るＭＯ（Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）インスタンスに割り当てられたキャッシュ検証子（ｃａｃｈｅ ｖａｌｉｄａｔｏｒ；ＣＶ）を用いたＭＯデータを要請するためのサーバーであって、前記ＭＯインスタンスは、一つ以上のノードからなるツリー構造で構成され、前記ＭＯデータは、前記ＭＯインスタンスに含まれたノードの名前、ノードの値及びノードの構造を含み、前記サーバーは、無線周波数（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ、ＲＦ）ユニット、及び前記ＲＦユニットを制御するように構成されたプロセッサを含み、前記プロセッサは、前記ＭＯインスタンスの特定ＭＯデータを要請するための前記特定ＭＯデータを識別するＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）情報を含む要請を前記端末に伝送し、前記ＭＯインスタンスに対する第１のＣＶを知っていると、前記ＵＲＩ情報に前記第１のＣＶを含ませるように構成され、前記ＵＲＩ情報に前記第１のＣＶが含まれていないと、前記プロセッサは、前記要請された特定ＭＯデータを前記端末から受信し、前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを受信するように構成することができる。

前記技術的解決方法は、本発明の各実施例の一部に過ぎなく、本願発明の技術的特徴が反映された多様な実施例は、当該技術分野で通常の知識を有する者によって以下で説明する本発明の詳細な説明に基づいて導出されて理解され得る。

本発明の一実施例によると、サーバーの端末のリソース要請及びサーバーへのリソース提供の管理を効率的に行うことができる。

本発明で得られる効果は、以上で言及した各効果に制限されず、言及していない他の効果は、下記の記載から本発明の属する技術分野で通常の知識を有する者に明確に理解され得るだろう。

本発明に関する理解を促進するために詳細な説明の一部として含まれる添付の図面は、本発明に対する実施例を提供し、詳細な説明と共に本発明の技術的思想を説明する。

ＨＴＴＰウェブキャッシュを示す図である。 ＤＭ（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）で定義されたＭＯ（Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）インスタンスの一例を示す図である。 本発明の一実施例に係るＭＯインスタンス―特定キャッシュ検証子の割り当て例を示す図である。 本発明の一実施例に係るリソース要請方法を示す図である。 本発明の一実施例に係るリソース提供方法を示す図である。 本発明の一実施例と対比され得る方法を示す図である。 本発明の実施例を具現するための装置のブロック図である。

本発明に係る好ましい実施形態を添付の図面を参照して詳細に説明する。添付の図面と共に以下で開示する詳細な説明は、本発明の例示的な実施形態を説明するためのものであって、本発明が実施され得る唯一の実施形態を示すためのものではない。以下の詳細な説明は、本発明の完全な理解を提供するために具体的な細部事項を含む。しかし、当業者は、本発明がこのような具体的な細部事項なしでも実施され得ることが分かる。

いくつかの場合、本発明の概念が曖昧になることを避けるために公知の構造及び装置を省略したり、各構造及び装置の核心機能を中心にしたブロック図の形式で図示することができる。また、本明細書全体において、同一の構成要素に対しては同一の図面符号を使用して説明する。

本明細書において、装置は、固定されたり、移動性を有することができ、サーバー又はゲートウェイと通信し、ユーザーデータ及び／または制御情報を送受信する各種機器がこれに属する。装置は、端末（Ｔｅｒｍｉｎａｌ Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｌ）、ＵＴ（Ｕｓｅｒ Ｔｅｒｍｉｎａｌ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅ Ｓｔａｔｉｏｎ）、無線機器（ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、無線モデム（ｗｉｒｅｌｅｓｓ ｍｏｄｅｍ）、携帯機器（ｈａｎｄｈｅｌｄ ｄｅｖｉｃｅ）などと称することができる。本発明において、サーバーとゲートウェイは、一般に装置、ゲートウェイ及び／又は他のサーバーと通信する固定局（ｆｉｘｅｄ ｓｔａｔｉｏｎ）をいい、装置、ゲートウェイ及び／又は他のサーバーと通信し、各種データ及び制御情報を交換する。また、サーバー又はゲートウェイは、それぞれサーバー装置又はゲートウェイ装置と称することもできる。

以下では、本発明と関連する背景技術について説明する。

装置管理（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）

装置管理（ＤＭ；Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ）は、多様な管理当局（Ｍａｎａｇｅｍｅｎｔ Ａｕｔｈｏｒｉｔｉｅｓ）の観点で、装置構成及び各装置の他の管理された客体を管理することを称する。装置管理は、各装置内の絶え間なく持続する情報の順次的なアップデート、各装置からの管理情報の検索、及び各装置によって生成された各イベントと各アラームの処理を含むが、各装置内の初期構成情報を設定することに限定されない。（Ｍａｎａｇｅｍｅｎｔ ｏｆ ｔｈｅ Ｄｅｖｉｃｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ ｏｔｈｅｒ ｍａｎａｇｅｄ ｏｂｊｅｃｔｓ ｏｆ Ｄｅｖｉｃｅｓ ｆｒｏｍ ｔｈｅ ｐｏｉｎｔ ｏｆ ｖｉｅｗ ｏｆ ｔｈｅ ｖａｒｉｏｕｓ Ｍａｎａｇｅｍｅｎｔ Ａｕｔｈｏｒｉｔｉｅｓ．Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ ｉｎｃｌｕｄｅｓ，ｂｕｔ ｉｓ ｎｏｔ ｒｅｓｔｒｉｃｔｅｄ ｔｏ ｓｅｔｔｉｎｇ ｉｎｉｔｉａｌ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ ｉｎ Ｄｅｖｉｃｅｓ，ｓｕｂｓｅｑｕｅｎｔ ｕｐｄａｔｅｓ ｏｆ ｐｅｒｓｉｓｔｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ ｉｎ Ｄｅｖｉｃｅｓ，ｒｅｔｒｉｅｖａｌ ｏｆ ｍａｎａｇｅｍｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ ｆｒｏｍ Ｄｅｖｉｃｅｓ ａｎｄ ｐｒｏｅｓｓｉｎｇ ｅｖｅｎｔｓ ａｎｄ ａｌａｒｍｓ ｇｅｎｅｒａｔｅｄ ｂｙ Ｄｅｖｉｃｅｓ．）

管理ツリー（Ｍａｎａｇｅｍｅｎｔ Ｔｒｅｅ）

管理ツリーは、例えば、管理ツリーに各値を格納したり、管理ツリーから各値を検索することによって、そして、管理ツリーの各属性を操作することによって、管理サーバーがＤＭクライアントと相互作用するためのインターフェースであって、例えば、管理ツリーの一つの属性としてＡＣＬ（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔ）がある。（Ｔｈｅ ｉｎｔｅｒｆａｃｅ ｂｙ ｗｈｉｃｈ ｔｈｅ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ ｉｎｔｅｒａｃｔｓ ｗｉｔｈ ｔｈｅ ｃｌｉｅｎｔ，ｅ．ｇ．ｂｙ ｓｔｏｒｉｎｇ ａｎｄ ｒｅｔｒｉｅｖｉｎｇ ｖａｌｕｅｓ ｆｒｏｍ ｉｔ ａｎｄ ｂｙ ｍａｎｉｐｕｌａｔｉｎｇ ｔｈｅ ｐｒｏｐｅｒｔｉｅｓ ｏｆ ｉｔ，ｆｏｒ ｅｘａｍｌｅ ｔｈｅ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔｓ．）本明細書では、管理ツリーは、装置管理ツリー又はＤＭツリーと相互互換可能なものと称することができる。

ＭＯ（管理客体；Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ）

管理客体は、互いにいくつかの方式で関連した各ノードの集合（一つのノード単独でも可能）になることが意図された管理ツリーのサブツリーである。例えば、．／Ｄｅｖｌｎｆｏノードとその子ノードは管理客体を形成することができる。簡単な管理客体は、一つの単独（ｓｉｎｇｌｅ）ノードで構成することができる。（Ａ Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ ｉｓ ａ ｓｕｂｔｒｅｅ ｏｆ ｔｈｅ Ｍａｎａｇｅｍｅｎｔ Ｔｒｅｅ ｗｈｉｃｈ ｉｓ ｉｎｔｅｎｄｅｄ ｔｏ ｂｅ ａ （ｐｏｓｓｉｂｌｙ ｓｉｎｇｌｅｔｏｎ） ｃｏｌｌｅｃｔｉｏｎ ｏｆ Ｎｏｄｅｓ ｗｈｉｃｈ ａｒｅ ｒｅｌａｔｅｄ ｉｎ ｓｏｍｅ ｗａｙ．Ｆｏｒ ｅｘａｍｐｌｅ，ｔｈｅ ．／Ｄｅｖｌｎｆｏ Ｎｏｄｅｓ ｆｏｒｍ ａ Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ．Ａ ｓｉｍｐｌｅ Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ ｍａｙ ｃｏｎｓｉｓｔ ｏｆ ｏｎｅ ｓｉｎｇｌｅ Ｎｏｄｅ．）

ＤＭサーバー又はＤＭＳ（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ）

ＤＭサーバー又はＤＭＳは、ＤＭサーバー又はＤＭＳに対して特定されたＯＭＡ装置管理イネーブラー（Ｅｎａｂｌｅｒ）固定適合（ｓｔａｔｉｃ ｃｏｎｆｏｒｍａｎｃｅ）要求事項に従う装置管理インフラストラクチャーにある概念的なソフトウェアコンポーネントであり得る。ＤＭサーバー又はＤＭＳは、ＤＭクライアント―サーバープロトコル及びＤＭサーバー―サーバーインターフェースのエンド―ポイントとしてサービスすることができる。（Ａｎ ａｂｓｔｒａｃｔ ｓｏｆｔｗａｒｅ ｃｏｍｐｏｎｅｎｔ ｉｎ ａ ｄｅｐｌｏｙｅｄ Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｔｈａｔ ｃｏｎｆｏｒｍｓ ｔｏ ｔｈｅ ＯＭＡ Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｅｎａｂｌｅｒ ｓｔａｔｉｃ ｃｏｎｆｏｒｍａｎｃｅ ｒｅｑｕｉｒｅｍｅｎｔｓ ｓｐｅｃｉｆｉｅｄ ｆｏｒ ＤＭ Ｓｅｒｖｅｒｓ．Ｉｔ ｓｅｒｖｅｓ ａｓ ａｎ ｅｎｄ―ｐｏｉｎｔ ｏｆ ｔｈｅ ＤＭ Ｃｌｉｅｎｔ―Ｓｅｒｖｅｒ Ｐｒｏｔｏｃｏｌｓ ａｎｄ ＤＭ Ｓｅｒｖｅｒ―Ｓｅｒｖｅｒ Ｉｎｔｅｒｆａｃｅ）。

また、本明細書において、ＤＭサーバー又はＤＭＳは、通信モジュール、プロセッサモジュールなどを備える装置、デバイス、コンピューターなどに搭載された状態で提供することができ、したがって、一つの装置として具現することができる。

ＤＭクライアント又はＤＭＣ（Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｃｌｉｅｎｔ）

ＤＭクライアント又はＤＭＣは、ＤＭクライアント又はＤＭＣに対して特定されたＯＭＡ装置管理イネーブラー固定適合要求事項に従う装置インプリメンテーション（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）にある概念的なソフトウェアコンポーネントであり得る。ＤＭクライアント又はＤＭＣは、ＤＭクライアント―サーバープロトコルのエンド―ポイントとしてサービスすることができる。（Ａｎ ａｂｓｔｒａｃｔ ｓｏｆｔｗａｒｅ ｃｏｍｐｏｎｅｎｔ ｉｎ ａ Ｄｅｖｉｃｅ ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｔｈａｔ ｃｏｎｆｏｒｍｓ ｔｏ ｔｈｅ ＯＭＡ Ｄｅｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｅｎａｂｌｅｒ ｓｔａｔｉｃ ｃｏｎｆｏｒｍａｎｃｅ ｒｅｑｕｉｒｅｍｅｎｔｓ ｓｐｅｃｉｆｉｅｄ ｆｏｒ ＤＭ Ｃｌｉｅｎｔｓ．Ｉｔ ｓｅｒｖｅｓ ａｓ ａｎ ｅｎｄ―ｐｏｉｎｔ ｏｆ ｔｈｅ ＤＭ Ｃｌｉｅｎｔ―Ｓｅｒｖｅｒ Ｐｒｏｔｏｃｏｌｓ．）

また、本明細書において、ＤＭクライアント又はＤＭＣは、通信モジュール、プロセッサモジュールなどを備えるＤＭの対象となる装置内に搭載された状態で提供することができ、したがって、一つの装置として具現することができる。

ＡＣＬ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）

ＡＣＬは、管理ツリー内の特定ノードに対するＤＭサーバー識別子及びそれぞれのＤＭサーバー識別子と連関した各接近権限（ａｃｃｅｓｓ ｒｉｇｈｔ）のリストを称する。（Ａ ｌｉｓｔ ｏｆ ｉｄｅｎｔｉｆｉｅｒｓ ａｎｄ ａｃｃｅｓｓ ｒｉｇｈｔｓ ａｓｓｏｃｉａｔｅｄ ｗｉｔｈ ｅａｃｈ ｉｄｅｎｔｉｆｉｅｒ）

ノード（Ｎｏｄｅ）

ノードは、管理ツリーにある単独エレメントである。管理ツリー内で、ノードとしては、二つの種類：インテリアノード及びリーフノードがあり得る。ノードのフォーマット属性は、ノードがリーフノードであるか、それともインテリアノードであるかに関する情報を提供する。（Ａ Ｎｏｄｅ ｉｓ ａ ｓｉｎｇｌｅ ｅｌｅｍｅｎｔ ｉｎ ａ Ｍａｎａｇｅｍｅｎｔ Ｔｒｅｅ．Ｔｈｅｒｅ ｃａｎ ｂｅ ｔｗｏ ｋｉｎｄｓ ｏｆ Ｎｏｄｅｓ ｉｎ ａ Ｍａｎａｇｅｍｅｎｔ Ｔｒｅｅ：Ｉｎｔｅｒｉｏｒ Ｎｏｄｅｓ ａｎｄ Ｌｅａｆ Ｎｏｄｅｓ．Ｔｈｅ Ｆｏｒｍａｔ ｐｒｏｐｅｒｔｙ ｏｆ ａ Ｎｏｄｅ ｐｒｏｖｉｄｅｓ ｉｎｆｏｒｍａｔｉｏｎ ａｂｏｕｔ ｗｈｅｔｈｅｒ ａ Ｎｏｄｅ ｉｓ ａ ｌｅａｆ ｏｒ ａｎ Ｉｎｔｅｒｉｏｒ Ｎｏｄｅ．）

インテリアノード（Ｉｎｔｅｒｉｏｒ Ｎｏｄｅ）

インテリアノードは、子ノードを有し得る一方、ノードに割り当てられた値、すなわち、ノード値（ｎｏｄｅ ｖａｌｕｅ）を有することはできない。インテリアノードのフォーマット属性は「ｎｏｄｅ」である。（Ａ Ｎｏｄｅ ｔｈａｔ ｍａｙ ｈａｖｅ ｃｈｉｌｄ Ｎｏｄｅｓ，ｂｕｔ ｃａｎｎｏｔ ｓｔｏｒｅ ａｎｙ ｖａｌｕｅ．Ｔｈｅ Ｆｏｒｍａｔ ｐｒｏｐｅｒｔｙ ｏｆ ａｎ Ｉｎｔｅｒｉｏｒ Ｎｏｄｅ ｉｓ ｎｏｄｅ．）

リーフノード（Ｌｅａｆ Ｎｏｄｅ）

リーフノードは、子ノードを有することができなく、その代わりにノード値を有することができる。リーフノードのフォーマット属性は「ｎｏｄｅ」ではない。（Ａ Ｎｏｄｅ ｔｈａｔ ｃａｎ ｓｔｏｒｅ ａ ｖａｌｕｅ，ｂｕｔ ｃａｎｎｏｔ ｈａｖｅ ｃｈｉｌｄ Ｎｏｄｅｓ．Ｔｈｅ Ｆｏｒｍａｔ ｐｒｏｐｅｒｔｙ ｏｆ ａ Ｌｅａｆ Ｎｏｄｅ ｉｓ ｎｏｔ ｎｏｄｅ．）

したがって、全ての親（ｐａｒｅｎｔ）ノードは、インテリアノードになるべきである。

永久ノード（Ｐｅｒｍａｎｅｎｔ Ｎｏｄｅ）

永久ノードは、ＤＤＦ属性スコープがパーマネント（Ｐｅｒｍａｎｅｎｔ）に設定されているノードである。ノードが永久ノードでないと、動的ノードに該当する。永久ノードは、サーバーによって動的に生成されたり削除され得ない。（Ａ Ｎｏｄｅ ｉｓ ｐｅｒｍａｎｅｎｔ ｉｆ ｔｈｅ ＤＤＦ ｐｒｏｐｅｒｔｙ Ｓｃｏｐｅ ｉｓ ｓｅｔ ｔｏ Ｐｅｒｍａｎｅｎｔ．Ｉｆ ａ Ｎｏｄｅ ｉｓ ｎｏｔ ｐｅｒｍａｎｅｎｔ，ｉｔ ｉｓ ｄｙｎａｍｉｃ．Ａ ｐｅｒｍａｎｅｎｔ Ｎｏｄｅ ｃａｎ ｎｅｖｅｒ ｂｅ ｄｅｌｅｔｅｄ ｂｙ ｔｈｅ ｓｅｒｖｅｒ．）

動的ノード（Ｄｙｎａｍｉｃ Ｎｏｄｅ）

動的ノードは、ＤＤＦ属性スコープ（Ｓｃｏｐｅ）がダイナミック（Ｄｙｎａｍｉｃ）に設定されているか、ＤＤＦ属性スコープが特定されていないノードである。（Ａ Ｎｏｄｅ ｉｓ ｄｙｎａｍｉｃ ｉｆ ｔｈｅ ＤＤＦ ｐｒｏｐｅｒｔｙ Ｓｃｏｐｅ ｉｓ ｓｅｔ ｔｏ Ｄｙｎａｍｉｃ，ｏｒ ｉｆ ｔｈｅ Ｓｃｏｐｅ ｐｒｏｐｅｒｔｙ ｉｓ ｕｎｓｐｅｃｉｆｉｅｄ．）

サーバー識別子（Ｓｅｖｅｒ Ｉｄｅｎｔｉｆｉｅｒ）

サーバー識別子は、ＤＭサーバーに対するＯＭＡ ＤＭ内部の名前を称する。ＤＭサーバーは、ＯＭＡ ＤＭアカウントを通じて装置に存在するサーバー識別子と連関する。（Ｔｈｅ ＯＭＡ ＤＭ ｉｎｔｅｒｎａｌ ｎａｍｅ ｆｏｒ ａ ＤＭ Ｓｅｒｖｅｒ．Ａ ＤＭ Ｓｅｒｖｅｒ ｉｓ ａｓｓｏｃｉａｔｅｄ ｗｉｔｈ ａｎ ｅｘｉｓｔｉｎｇ Ｓｅｒｖｅｒ Ｉｄｅｎｔｉｆｉｅｒ ｉｎ ａ ｄｅｖｉｃｅ ｔｈｒｏｕｇｈ ＯＭＡ ＤＭ ａｃｃｏｕｎｔ．）

ＡＣＬ属性及びＡＣＬ値

ＤＭ（ｄｅｖｉｃｅ ｍａｎａｇｅｍｅｎｔ）１．３プロトコルで管理される全ての端末は、ルートノード（ｒｏｏｔ ｎｏｄｅ）から開始される一つのＤＭツリー（ｔｒｅｅ）を有するようになり、ＤＭプロトコルは、ＤＭツリーの各ノードを操作することによって端末に管理命令を行う。例えば、端末にダウンロードされたソフトウェアを設置するとき、そのソフトウェアとマッチングされているインストール（ｉｎｓｔａｌｌ）というノードを実行（Ｅｘｅｃ）すると、該当のソフトウェアを設置することができる。それぞれのノードは、数字などの単純な情報を示すこともでき、イメージデータやログデータなどの複雑なデータを示すこともできる。また、ノードは、実行、ダウンロードなどのように一つの命令を示すこともできる。

それぞれのノードは、ノードと関連するメタ情報を提供する属性（ｐｒｏｐｅｒｔｙ）を有する。この属性中にランタイム（ｒｕｎｔｉｍｅ）属性があるが、この属性は、ノードがＤＭツリー内に生成されて消滅するまで使用可能な属性を意味する。このようなランタイム属性には、ＡＣＬ、Ｆｏｒｍａｔ、Ｎａｍｅ、Ｓｉｚｅ、Ｔｉｔｌｅ、ＴＳｔａｍ、Ｔｙｐｅ、ＶｅｒＮｏがある。

ＡＣＬ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ）は、ＤＭ １．３プロトコルでは端末とサーバーが全て具現しなければならない必須機能である。ＡＣＬは、特定ＤＭサーバーが特定ノードに遂行可能なＤＭ命令（ｃｏｍｍａｎｄ）を明示し、明示されていないＤＭ命令は行うことができない。言い換えると、ＡＣＬは、特定ＤＭサーバーが特定ノードに対して許容された権限を意味する。ＤＭプロトコルにおいて、ＡＣＬは、ＤＭサーバーのサーバー識別子に付与され、ＵＲＩ、ＩＰ住所、ＤＭサーバー資格（ｃｅｒｔｉｆｉｃａｔｅ）に付与されない。このサーバー識別子は、ＤＭプロトコルでＤＭサーバーを認証する識別子として使用される。また、このようなＡＣＬは、ＡＣＬ属性とＡＣＬ属性に付与されたＡＣＬ値として提供することができる。一方、本明細書において、ＡＣＬ値は、ＡＣＬ情報（ＡＣＬ ｉｎｆｏｒｍａｔｉｏｎ）又はＡＣＬに関する情報と相互互換可能なものと称することができる。ＤＭ １．３プロトコルでは、全てのノードがＡＣＬ属性を有するように定義されており、ＡＣＬ属性を有する全てのノードは、空いている（ｅｍｐｔｙ）ＡＣＬ値又は空いていない（ｎｏｎ―ｅｍｐｔｙ）ＡＣＬ値を有するように定義される。

ＡＣＬは、他のランタイム属性と異なる独特の性質を有するが、このような独特の代表的な性質として、ＡＣＬ相続（ＡＣＬ ｉｎｈｅｒｉｔａｎｃｅ）がある。ＡＣＬ相続は、ＤＭツリー内のいずれかのノードがＡＣＬ値を有していないとき、そのノードに対するＡＣＬ値を親ノードのＡＣＬ値から持ってくる概念である。親ノードもＡＣＬ値を有していないと、その親ノードの親ノードからＡＣＬ値を持ってくるようになる。ＤＭプロトコルでは、ＤＭツリーの最上位ノードであるルートノードが必ずＡＣＬ値を有するように明示しているので、ＡＣＬ値は必ず相続されるようになる。このようなＡＣＬ相続は、個別ＤＭ命令別に行われなく、全体のＡＣＬ値に対して行われるので、ＡＣＬ値が空いているときのみに、親ノードからＡＣＬ相続が行われるようになる。すなわち、いずれかのノードのＡＣＬ値がＡｄｄ権限のみを明示している場合、明示されていないＧｅｔ（持ってくること）権限などは相続されない。

ＤＭプロトコルでは、ルートノードは、ＡＣＬに対する基本値として「Ａｄｄ＝＊＆Ｇｅｔ＝＊」を有するようになり、ここで、「＊」は、ワイルドカード（ｗｉｌｄ ｃａｒｄ）であって、任意のＤＭサーバーを意味する。ＤＭサーバーがＡＣＬ値を得るためにはＧｅｔ命令を用いればよく、「．／ＮｏｄｅＡ／Ｎｏｄｅｌ？ｐｒｏｐ＝ＡＣＬ」に対するＧｅｔ命令は、．／ＮｏｄｅＡ／ＮｏｄｅｌのＡＣＬ値を持ってくるようになる。また、ＡＣＬ値を変えるためには、交替（Ｒｅｐｌａｃｅ）命令を用いればよく、「．／ＮｏｄｅＡ／Ｎｏｄｅｌ？ｐｒｏｐ＝ＡＣＬ」に交替命令を行い、「Ａｄｄ＝ＤＭＳｌ＆Ｄｅｌｅｔｅ＝ＤＭＳｌ＆Ｇｅｔ＝ＤＭＳｌ」に値を変えると、ＡＣＬ値が変わるようになる。ＤＭプロトコルでは、個別ＡＣＬエントリー（ａｃｌ ｅｎｔｒｙ）を変えることができなく、全体のＡＣＬ値を変えるように定義されている。ＡＣＬ値を持ってきて修正する権限もＡＣＬに基づいて定義されるが、インタリアノードとリーフノードに対する権限は少し異なる形に定義されている。

― インテリアノード
該当のノードにＧｅｔとＲｅｐｌａｃｅ権限を有している場合、該当のノードのＡＣＬ値をそれぞれ持ってきて交替できる権限がある。また、Ｒｅｐｌａｃｅ権限は、全ての子ノードのＡＣＬ値を交替できる権限を意味する。

― リーフノード
該当のノードの親ノードにＲｅｐｌａｃｅ権限を有している場合、そのノードのＡＣＬ値を交替できる権限がある。該当のノードのＡＣＬを持ってくるためには、親ノードにＧｅｔ権限を有していなければならない。同様に、該当のノードにＲｅｐｌａｃｅ権限を有していると、そのノードの値を交替できる権限を意味し、ＡＣＬを交替するためには親ノードにＲｅｐｌａｃｅ権限を有していなければならない。

インテリアノードであるのか、それともリーフノードであるのかとは関係なく、該当のノードのＡＣＬ値を交替する権限は、親ノードのＡＣＬ値によって制御することができる。インテリアノードにＲｅｐｌａｃｅ権限を有していると、該当のインテリアノードはもちろん、全ての子ノードのＡＣＬ値を交替できる権限を意味する。したがって、ルートノードにＲｅｐｌａｃｅ権限を有していると、ＤＭツリー内の全てのノードに如何なる権限も有し得るという意味になる。しかし、親ノードにＲｅｐｌａｃｅ権限を有していることが、直ぐ子ノードにＧｅｔなどの特定権限を内包することはなく、該当の子ノードに直接Ｇｅｔなどの権限が明示されていなければならない。したがって、命令の遂行前にＡＣＬ値を修正しなければならなく、修正しようとするノードに行く道にある全てのノードに対するＡＣＬ値の修正を通じて、最終的に該当の子ノードのＡＣＬ値を修正するようになる。これは不便であるので、ＤＭプロトコルでは、親或いは先祖ノード（ａｎｃｅｓｔｏｒ ｎｏｄｅ）にＲｅｐｌａｃｅ権限を有している場合、中間ノードのＡＣＬ値の修正なしで、直ぐ該当のノードのＡＣＬ値の修正を許容している。

ＤＭサーバーが新たなノードを追加（Ａｄｄ）命令を通じて生成した場合、生成されたノードは、一般にＡＣＬ値を有しなくなり、全ての権限が親から相続されるようになる。しかし、生成したノードがインテリアノードで、親ノードにＲｅｐｌａｃｅ権限を有していない場合、生成と同時にＡＣＬ値を設定し、該当のノードを管理するための十分な権限を有することが必要である。

ＡＣＬ値を示すための文法は、［ＤＭ―ＴＮＤ］に定義されており、ＡＣＬ値の一例としては、「Ｇｅｔ＝ＤＭＳｌ＆Ｒｅｐｌａｃｅ＝ＤＭＳｌ＆Ｄｅｌｅｔｅ＝ＤＭＳ２」を挙げることができる。ここで、ＤＭＳ１とＤＭＳ２は、ＤＭサーバーのサーバー識別子で、Ｇｅｔ、Ｒｅｐｌａｃｅ、ＤｅｌｅｔｅはＤＭ命令である。したがって、該当のノードに対して、ＤＭＳ１は、ＧｅｔとＲｅｐｌａｃｅ命令を行うことができ、ＤＭＳ２はＤｅｌｅｔｅ命令を行うことができる。ここで、Ｇｅｔ＝ＤＭＳｌ、Ｒｅｐｌａｃｅ＝ＤＭＳｌ、Ｄｅｌｅｔｅ＝ＤＭＳ２のそれぞれがＡＣＬ―エントリー（ａｃｌ―ｅｎｔｒｙ）で、ＤＭサーバーの個別命令権限を示す。言い換えると、ＡＣＬ値は、個別ＡＣＬ―エントリ（ａｃｌ―ｅｎｔｒｙ）の集合で、各ノードのＡＣＬ値は少なくとも一つのＡＣＬエントリーを含むことができる。

ＤＤＦ（Ｄｅｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｆｒａｍｅｗｏｒｋ）

ＤＤＦは、特定デバイスタイプに対する管理シンタックスとセマンティックスを記述する方法に関する説明である。（Ａ ｓｐｅｃｉｆｉｃａｔｉｏｎ ｆｏｒ ｈｏｗ ｔｏ ｄｅｓｃｒｉｂｅ ｔｈｅ ｍａｎａｇｅｍｅｎｔ ｓｙｎｔａｘ ａｎｄ ｓｅｍａｎｔｉｃｓ ｆｏｒ ａ ｐａｒｔｉｃｕｌａｒ ｄｅｖｉｃｅ ｔｙｐｅ．）ＤＤＦは、端末のＭＯ、管理機能及びＤＭツリー構造に対する情報を提供する。

ＤＭ １．３認証

ＤＭ １．３では、ＡＣＬに基づいて認証を行う。ＤＭ認証は、それぞれのＤＭ命令に対して別途に行われる。ＤＭサーバーが多数のＤＭ命令を伝送した場合、ＤＭクライアント（ｃｌｉｅｎｔ、以下、ＤＭＣ）は、個別命令を行う前に認証を行い、その結果として許可されたＤＭ命令のみを行うようになる。

ＤＭツリー

ＤＭツリーは、ＤＭクライアントによって露出した各ＭＯインスタンスの集合を称する。ＤＭツリーは、クライアントと相互作用する管理サーバーによるインターフェースとして機能し、例えば、管理サーバーは、ＤＭツリーから特定値を格納して検索（ｒｅｔｒｉｅｖｅ）し、ＤＭツリーの属性を操作することができる。

ＭＯデータ（Ｄａｔａ）

ＭＯデータは、ＤＭツリーに関する情報に該当する。情報は、ＤＭツリー全体に対するものであってもよく、ＤＭツリーの一部（例えば、ＭＯインスタンス内のサブツリー）に対するものであってもよい。ＤＭ ２．０プロトコルで、ＤＭサーバーは、ＣｌｉｅｎｔＵＲＩを用いてＭＯデータを要請し、ＭＯデータは、ノードの名前、ノード値及びノード構造で構成される。

リソースキャッシング（Ｒｅｓｏｕｒｃｅ Ｃａｃｈｉｎｇ）

キャッシングは、サーバーとクライアントとの間の各リソースの不必要な伝送を減少させる技術を称する一般用語である。クライアントは、サーバーから以前の各応答を格納し、同一のリソースを要請するとき、格納されたものを再使用する。

キャッシュ検証子（Ｃａｃｈｅ Ｖａｌｉｄａｔｏｒ）

キャッシュ検証子は、キャッシュを検証するのに使用されるコンポーネントである。キャッシュ検証は、リソース要請者にキャッシングされたリソースが最新であるか否かを決定するプロセスである。「最新（ｆｒｅｓｈｎｅｓｓ）」という用語は、リソースがリソース要請者に伝達された後、変更されていないかどうかを意味する。キャッシュ検証子の一般的な例は、ウェブキャッシュで使用されるＥＴａｇ及びＬａｓｔ―Ｍｏｄｉｆｉｅｄフィールドである。

ＭＯインスタンス

ＭＯインスタンスは、ＤＭクライアントによって公開された管理客体（Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ；ＭＯ）の存在（ｏｃｃｕｒｒｅｎｃｅ）である。ＭＯの各インスタンスは同一のノード定義及び行動を共有し、ＤＭクライアントによって公開された関連ノードの集合として表現することができる。一つのＭＯの多重インスタンスがＤＭツリー内に存在し得る。

ＣｌｉｅｎｔＵＲＩ

ＣｌｉｅｎｔＵＲＩは、端末に存在するＤＭツリーの特定ノードを識別する。ＣｌｉｅｎｔＵＲＩは、インテリアノード又はリーフノードを指示（Ｐｏｉｎｔ）することができる。したがって、ＣｌｉｅｎｔＵＲＩは、特定ノードを指示する指示子又は情報と表現することができる。

ＨＴＴＰウェブキャッシュ

ＨＴＴＰは、ウェブでリソースを取り交わすために広く使用されるプロトコルである。ＨＴＴＰでは、ＵＲＩで示されるリソースに対してＧＥＴ、ＤＥＬＥＴＥ、ＰＵＴ、ＰＯＳＴなどのＨＴＴＰ命令を使用してリソースを操作するようになる。例えば、ＨＴＴＰクライアントは、ウェブ上に存在するイメージファイルを獲得するために、該当のイメージファイルを称するＵＲＩを知っていなければならなく、該当のＵＲＩが「ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／ａ．ｊｐｇ」である場合、該当のＵＲＩを対象としてＨＴＴＰ ＧＥＴ命令を送るようになる。ＨＴＴＰサーバーは、ＨＴＰ ＧＥＴ命令に対する応答として、該当のイメージファイルをＨＴＴＰクライアントに送るようになる。

ＨＴＴＰクライアントが一度ダウンロードした同一のリソースを後ほどで再び要請したとき、該当のイメージファイルがアップデートされていないと、同一のリソースをＨＴＴＰクライアントに再び伝送することは非効率的であり得る。このような非効率を解決するための代表的な方法として、ウェブキャッシュ（ｗｅｂ ｃａｃｈｅ）が広く使用されている。このようなウェブキャッシュは、ＨＴＴＰサーバーとＨＴＴＰクライアントとの間の応答速度を高め（ｌｏｗ ｌａｔｅｎｃｙ）、ネットワークトラフィックを減少させることができる。ウェブキャッシュのために、ＨＴＴＰクライアントは、ＨＴＴＰサーバーから受けたリソースをローカルに格納（ローカルコピー；ｌｏｃａｌ ｃｏｐｙ）し、同一のＵＲＩで再び要請するとき、該当のリソースが変更された場合のみにＨＴＴＰサーバーから再びリソースを受けるようになる。このために、該当のリソースが変更されたか否かを判断できる手順が必要であり、通常、これをキャッシュ検証手順（Ｃａｃｈｅ Ｖａｌｉｄａｔｉｏｎ Ｐｒｏｃｅｓｓ或いはＣａｃｈｅ Ｖａｌｉｄａｔｉｏｎ）と称する。キャッシュ検証手順（Ｃａｃｈｅ Ｖａｌｉｄａｔｉｏｎ）は、キャッシュが有効であるか、それとも満了したかを確認する手順であり、このようなキャッシュ検証手順でキャッシュに対する有効性情報を与えることをキャッシュ検証子という。ＨＴＴＰでは、代表的にＥＴａｇとＬａｓｔ―Ｍｏｄｉｆｉｅｄをキャッシュ検証子として使用する。

ＥＴａｇは、ＨＴＴＰサーバーが特定バージョンのリソースに付与する一種のアイディー（ｉｄｅｎｔｉｆｉｅｒ）である。ＨＴＴＰサーバーは、リソース要請に対する応答を伝送するとき、ＵＲＩが示すリソースとそのリソースに割り当てられたＥＴａｇ値を共に伝送する。ＨＴＴＰサーバーは、リソースが変更されると（リソースのバージョンが変わると）、ＥＴａｇ値を変えるようになり、キャッシュ検証手順でＨＴＴＰクライアントが送ってきたＥＴａｇ値と自分が有しているＥＴａｇ値とを比較することによって、ＨＴＴＰクライアントが有しているローカルコピーが最新バージョンであるか否かを判断するようになる。

最新バージョンのリソースをＨＴＴＰクライアントが有している場合、ＨＴＴＰサーバーは、リソースを再び伝送する必要がない。図１の左側テーブルは、ＥＴａｇを用いたウェブキャッシュを大略的に示しており、右側テーブルは、Ｌａｓｔ―Ｍｏｄｉｆｉｅｄを用いたウェブキャッシュを示している。

図１の左側テーブルにおいて、ＨＴＴＰクライアントは、「ｈｔｔｐ：／／ｗｗｗ．ｓｅｒｖｅｒ．ｃｏｍ／ａ．ｊｐｇ」というＵＲＩを通じて「ａ．ｊｐｇ」というイメージファイルリソースを要請している（Ｓ１０１―ａ）。ＨＴＴＰサーバーは、要請されたリソースであるイメージファイルと共に、ＥＴａｇというＨＴＴＰヘッダーを含ませて伝送する（Ｓ１０２―ａ）。このＥＴａｇヘッダーは、現在のバージョンのイメージファイルリソースに付与されたＥＴａｇ値を示す。ＨＴＴＰクライアントは、応答を受けて、イメージファイルリソースをローカルに格納（ｌｏｃａｌ ｃｏｐｙ）し、ＥＴａｇ値も共に格納する。

ＨＴＴＰクライアントが同一のＵＲＩに対する要請を伝送するとき、格納しているＥＴａｇを含ませるが、このために、Ｉｆ―Ｎｏｎｅ―ＭａｔｃｈというＨＴＴＰヘッダーを使用するようになる（Ｓ１０３―ａ）。ＨＴＴＰサーバーは、この要請を受けて、ＵＩが示すリソースの現在のバージョンに対するＥＴａｇ値と比較するようになり、二つの値が同一であると、ＨＴＴＰクライアントにリソースが修正されていないことを「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」応答コードを用いて知らせる（Ｓ１０４―ａ）。ＨＴＴＰクライアントは、ＨＴＴＰサーバーからこのような応答を受けると、自分が格納しているリソースが最新バージョンであることを確認するようになり、最新バージョンリソースをサーバーから再び受けることなく使用するようになる。

ＥＴａｇの他に主に使用されるＨＴＴＰキャッシュ検証子として、Ｌａｓｔ―Ｍｏｄｉｆｉｅｄがある。Ｌａｓｔ―Ｍｏｄｉｆｉｅｄの基本動作は、図１の右側テーブルに示すように、ＥＴａｇとほぼ同一である。ＥＴａｇとの相違点は、ＥＴａｇが特定バージョンのリソースに付与された任意の識別子であると、Ｌａｓｔ―Ｍｏｄｉｆｉｅｒはリソースが最後に変更された時間を意味する。すなわち、ＨＴＴＰサーバーは、ＨＴＴＰクライアントにリソースを伝送するとき、リソースが最後に変更された時間をＨＴＴＰのＬａｓｔ―Ｍｏｄｉｆｉｅｄヘッダーに含ませて送る（Ｓ１０２―ｂ）。ＨＴＴＰクライアントは、リソースとＬａｓｔ―Ｍｏｄｉｆｉｅｄ値をローカルに格納してから、同一のＵＲＩに要請を送るとき、Ｉｆ―Ｍｏｄｉｆｉｅｄ―Ｓｉｎｃｅヘッダーに受信したリソースの最後の変更時間を含ませて送る（Ｓ１０３―ｂ）。ＨＴＴＰサーバーは、リソースが変更される度にリソース変更時間をアップデートするようになり、同一のＵＲＩに対する要請がＩｆ―Ｍｏｄｉｆｉｅｄ―Ｓｉｎｃｅヘッダーを含んでいる場合、Ｉｆ―Ｍｏｄｉｆｉｅｄ―Ｓｉｎｃｅヘッダーに含まれた時間と自分が格納している最後のリソース変更時間とを比較し、リソースが変更されたと考えられると、要請したリソースを再び伝送するようになる。リソースが変更されていないと、「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」応答コードを伝送する（Ｓ１０４―ｂ）。

ＤＭ ２．０基盤のリソース獲得

ＤＭサーバーは、端末に格納されている情報の伝送をＤＭクライアントに要請することができる。ＯＭＡ ＤＭ ２．０で、このような情報は、ＤＭツリーの形態で構成されて端末に格納され、通常、管理客体データ（Ｍａｎａｇｅｍｅｎｔ Ｏｂｊｅｃｔ ｄａｔａ；ＭＯ Ｄａｔａ）と称する。ＭＯデータは、全体のＤＭツリー情報になってもよく、一つのノードに格納されている値であってもよい。図２は、ＯＭＡ ＤＭ ２．０で端末に格納されたＤＭツリーを例示した図である。ＯＭＡ ＤＭ ２．０は、端末にあるＭＯインスタンス（すなわち、端末に生成されたＭＯ関連ノードの集合）が階層的なツリー構造で構成されるように制限しなく、これは、ＤＭツリーのノードを称するＣｌｉｅｎｔＵＲＩがＭＯインスタンスに基づいてノードの住所を指定するためである。

ＯＭＡ ＤＭ ２．０で、ＤＭサーバーがＭＯデータを獲得する要請は、一般にＧＥＴ命令を通じて具現される。ＤＭサーバーは、ＧＥＴ命令をＤＭクライアントに伝達する過程でＧＥＴ命令のパラメーターでＣｌｉｅｎｔＵＲＩを共に伝達し、ＣｌｉｅｎｔＵＲＩは、ＤＭツリーの特定ノードを称する。ＤＭサーバーがＤＭクライアントに命令を伝達するためにＰａｃｋａｇｅ＃２が使用され、Ｐａｃｋａｇｅ＃２は、複数のＤＭ命令を含むことができる。下記は、二つのＧＥＴ命令を含むＰａｃｋａｇｅ＃２を例示するが、１番目のＧＥＴ命令は、端末に格納されているＤｅｖｌｎｆｏ管理客体を要請し、２番目のＧＥＴ命令は、端末に設置されている全てのソフトウェアコンポーネントのアイディーを要請する。

前記の例において、二つのＧＥＴ命令が入っていることを確認することができ、ＧＥＴ命令語の次に来る要素はＣｌｉｅｎｔＵＲＩである。すなわち、１番目のＧＥＴ命令は、「ｏｍａ：ｍｏ：ｏｍａ―ｄｍ―ｄｅｖｉｎｆｏ：１．０／／」で示されるＤｅｖｌｎｆｏ管理客体全体に対するＭＯデータを要請する命令で、２番目のＧＥＴ命令は、「ｕｒｎ：ｏｍａ：ｍｏ：ｏｍａ―ｓｃｏｍｏ：１．０／／Ｉｎｖｅｎｔｏｒｙ／Ｄｅｐｌｏｙｅｄ／＊／１Ｄ」が示す設置されている全てのソフトウェアコンポーネント識別子（ＩＤ）に対する伝送を要請する。ＤＭクライアンは、このような要請を受けると、下記のような応答メッセージを介してＤＭサーバーに要請されたＭＯデータを伝達する。各命令に対する応答コード伝送は、Ｐａｃｋａｇｅ＃３を用いて行われ、前記のＰａｃｋａｇｅ＃２に対する応答として、ＤＭクライアントは下記のようなＨＴＴＰメッセージを伝送する。

前記の例において、ＤＭクライアントの応答はＨＴＴＰマルチパート（ｍｕｌｔｉｐａｒｔ）を用いて行われており、１番目のカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）はＰａｃｋａｇｅ＃３を含んでおり、２番目のカプセル化は１番目のＧＥＴ命令に対する応答で、３番目のカプセル化は２番目のＧＥＴ命令に対する応答である。ＤＭサーバーは、ＤＭクライアントにこのような式でＭＯデータを要請し、ＤＭクライアントは、要請されたＭＯデータをＤＭサーバーに伝達するようになる。

前記のようにＤＭサーバーがＧＥＴを用いて要請したＭＯデータをＤＭクライアントが常に伝送すると、非効率が発生し得る。すなわち、ＭＯデータの伝送に必要な時間が長くなり、応答時間が長くなり、必要でないデータの伝送によってネットワーク資源の浪費をもたらし得る。

ＤＭ ２．０にＨＴＴＰウェブキャッシュを適用した例

前記で説明したＨＴＴＰウェブキャッシュをＯＭＡ ＤＭ ２．０にそのまま適用することもできる。このために、ＨＴＴＰでリソース別にキャッシュ検証子を割り当てて管理する場合のように、ＤＭクライアントはＤＭツリーの全てのノードにキャッシュ検証子を割り当てて管理することができる。ＤＭサーバーは、ＤＭクライアントにＣｌｉｅｎｔＵＲＩで示されるリソースをＤＭ ＧＥＴ命令で要請しながら、キャッシュ検証子がある場合、これを追加的に伝達し、要請するリソースが変更されていないと、リソースが変更されていないことを示す状態コードを受けるようになる。もちろん、ＣｌｉｅｎｔＵＲＩで要請するリソースに対してキャッシュ検証子を有していない場合、キャッシュ検証子なしで要請を伝送するようになる。

下記は、Ｄｅｖｌｎｆｏ ＭＯのＦｗＶノード（デバイスのファームウェアバージョン情報を格納）を要請するＧＥＴ命令を示したものである。ＦｗＶノード（リソース）を要請する１番目のＧＥＴ命令である場合、ＤＭサーバーは、これに対するローカルキャッシュはもちろん、これに対するキャッシュ検証子を有していない可能性があるので、キャッシュ検証子なしで、ＧＥＴ命令を下記のように伝送するようになる。

ＤＭクライアントが前記のＧＥＴ命令を受けると、キャッシュ検証子がないので、下記のようにＤＭサーバーが要請したリソースを送るようになる。ＤＭクライアントは、リソースを伝送するとき、リソースに対するキャッシュ検証子を共に送ることができ、下記の「ＣＶ」キーを通じてキャッシュ検証子を伝達する。ここでは、ＥＴａｇをキャッシュ検証子であると仮定した。

ＤＭクライアントから前記のような応答を受けた場合、ＤＭサーバーは、端末のファームウェアバージョンである「ａｎｄｒｏｉｄ４．０．４」とこのリソースに対するキャッシュ検証子である「６８６８９７６９６ａ７ｃ８７６ｂ７ｅ」を共に格納することができる。この場合、後ほどで同一のリソースをＤＭサーバーが要請するとき、下記のようなＧＥＴ命令を使用してリソースを要請することができる。ＧＥＴ命令の２番目のパラメーターに入った「６８６８９７６９６ａ７ｃ８７６ｂ７ｅ」がキャッシュ検証子である。

ＤＭクライアントは、このようなＰａｃｋａｇｅ＃２を受けたとき、キャッシュ検証手順を行った後、キャッシュが有効であると、ＤＭサーバーに「Ｎｏｔ Ｍｏｄｉｆｉｅｄ」を知らせる状態コード（３０４）を伝送する。この場合、ＤＭサーバーは、ローカルキャッシュが依然として有効であることを知るようになり、ローカルキャッシュに格納された「ａｎｄｒｏｉｄ４．０．４」を使用することができる。下記は、「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」を知らせるＰａｃｋａｇｅ＃３である。

ＤＭクライアントがキャッシュ検証手順を通じてキャッシュが有効でないことを知ると、ソースを送るようになり、それに該当するキャッシュ検証子も送ることができる。下記は、この場合に対するＰａｃｋａｇｅ＃３である。

このようにＨＴＴＰウェブキャッシュをＯＭＡ ＤＭ ２．０に直ぐ適用した場合、ＤＭクライアントは、全てのリソースに対してキャッシュ検証子を付与しなければならないので、多数のキャッシュ検証子に対する管里問題と全体のプロトコルが重くなるという結果をもたらす。また、インテリアノードにキャッシュ検証子が割り当てられたとき、該当のキャッシュ検証子が有効性を検証しなければならないリソースの範囲がどこまでかという問題が生じる。すなわち、インテリアノードに割り当てられたキャッシュ検証子の場合、その子ノードや子孫ノードがアップデートされた場合、キャッシュ検証子をアップデートしなければならないかどうかなどが問題となる。

また、全てのリソースごとにキャッシュ検証子が割り当てられるので、「ＤＭ ２．０基盤のリソース獲得」で例を挙げたように、多数のノードを称するＣｌｉｅｎｔＵＲＩ（「ｕｒｎ：ｏｍａ：ｍｏ：ｏｍａ―ｓｃｏｍｏ：１．０／／Ｉｎｖｅｎｔｏｒｙ／Ｄｅｐｌｏｙｅｄ／＊／ＩＤ」）をＧＥＴ命令に使用する場合に問題が発生する。すなわち、ＣｌｉｅｎｔＵＲＩが多数のノードを称するので、ＧＥＴ命令でいずれのキャッシュ検証子を送るべきであるかを選択することができなく、さらに、ＤＭサーバーは、どれだけ多くのノードがＣｌｉｅｎｔＵＲＩと指定されるのかを知ることができないので、キャッシュ検証子を選択することができない。

併せて、全てのリソースごとにキャッシュ検証子を割り当てず、一部のリソースに選択的にキャッシュ検証子を割り当てる方案を考慮できるが、このような方案も、結局、いずれのリソースにキャッシュ検証子を割り当てるのか、又はキャッシュ検証子が割り当てられないリソースは如何なる式でバージョン又はアップデートを管理するのかが問題となる。

このような従来技術の問題を解決するための本発明の一実施例を説明する。

図３は、本発明の一実施例に係るキャッシュ検証子割り当て例を示す。

キャッシュ検証子は、サーバーが有しているローカルキャッシュに対する有効性情報を与えることができるエンティティである。言い換えると、キャッシュ検証子は、ローカルキャッシュに対する最新性情報を提供する。キャッシュ検証子の代表的な例として、時間情報（Ｌａｓｔ―Ｍｏｄｉｆｉｅｄ）やＥＴａｇなどを挙げることができる。本発明の一実施例では、図３に示したように、ＭＯインスタンス（Ｉｎｓｔａｎｃｅ）のみにキャッシュ検証子を割り当てる。しかし、ＤＭツリー内の全てのＭＯインスタンスにキャッシュ検証子を割り当てるのではなく、ＭＯインスタンスを選択し、必要なＭＯインスタンスのみにキャッシュ検証子を割り当てることができる。図３は、端末のＤＭツリーに存在する３個のＭＯインスタンスのうち２個のＭＯインスタンス（ＦＵＭＯインスタンス、ＳC０ＭＯインスタンス）にキャッシュ検証子を割り当てたことを図式化した。

このようにキャッシュ検証子が割り当てられたＭＯインスタンスをキャッシュ可能ＭＯインスタンス（ｃａｃｈｅａｂｌｅ ＭＯ Ｉｎｓｔａｎｃｅ）と称する。キャッシュを使用するために、まず、キャッシュ可能ＭＯインスタンスが端末（又はＤＭクライアント）やＤＭサーバーによって選択されなければならなく、選択されたＭＯインスタンスにキャッシュ検証子を割り当てて管理しなければならない。それぞれのキャッシュ可能ＭＯインスタンスに対して、ＤＭクライアントは必ずキャッシュ検証子を割り当てなければならなく、ＭＯインスタンスのデータ（ノード値の変更、新たなノードの追加及び削除、ノード名前の変更など）が変わる度に、割り当てられたキャッシュ検証子をアップデートしなければならない。

このようにキャッシュ検証子をＭＯインスタンスのみに割り当てると、キャッシュを用いたリソース要請／提供方法を効率的に行うことができる。

キャッシュ検証手順（Ｃａｃｈｅ Ｖａｌｉｄａｔｉｏｎ Ｐｒｏｃｅｓｓ）は、キャッシュ又はキャッシュ格納本（ｃａｃｈｅ ｃｏｐｙ）が有効であるか否かを検査する過程である。キャッシュ検証子はキャッシュ可能ＭＯインスタンスに割り当てられているので、キャッシュ検証は、キャッシュ可能ＭＯインスタンス内のいずれのデータも変更されていないと成功（「ｓｕｃｃｅｓｓ」又は「ｔｒｕｅ」）を返還し、いずれかのデータが変更された場合、失敗（「ｆａｌｓｅ」）をリターンしなければならない。例えば、キャッシュ検証は、キャッシュ検証子がＥＴａｇである場合、ＤＭサーバーが伝送したＥＴａｇ値と端末が管理する該当のＭＯインスタンスのＥＴａｇ値とを比較することによって行うことができる。端末は、ＤＭサーバーから伝送されたＥＴａｇ値と自分が管理するＥＴａｇ値とが同一であると「成功」を返還し、値が異なると「失敗」を返還する。

キャッシュ検証子がＭＯインスタンスに割り当てられているが、キャッシュ検証子は、ＭＯインスタンス内の全てのノードに対してＧＥＴ命令を伝送するときに使用することができる。例えば、ＣｌｉｅｎｔＵＲＩが特定のリーフノードを対象とするＧＥＴ命令である場合にも、ＤＭサーバーは、ＭＯインスタンスに対するキャッシュ検証子を伝達することができる。ＤＭクライアントは、ＭＯインスタンスが変更されていないかどうかを受け取ったキャッシュ検証子を通じて検証し、ＭＯインスタンスが変更されていないと、特定のリーフノードも当然変更されていないので、「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」コードをＤＭサーバーに伝達するようになる。「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」を受けたＤＭサーバーは、ローカルキャッシュされたデータを参照することができる。

キャッシュ検証子をＤＭサーバーがＤＭクライアントに伝達する方法は多様であり得るが、本発明の一実施例では、ＣｌｉｅｎｔＵＲＩに含まれ得るｃｖフィールド（ｆｉｅｌｄ）を使用することにする。ｃｖフィールドを使用すると、別途のパラメーターでキャッシュ検証子を伝達する必要がなく、キャッシュ検証子をＣｌｉｅｎｔＵＲＩに統合して伝達すればよいので、リソース要請が簡便である。ＣｌｉｅｎｔＵＲＩは特定ノードを示すので、該当の特定ノードが含まれたＭＯインスタンスに対するキャッシュ検証子をｃｖフィールドが伝達するようになる。例えば、ｃｖフィールドが含まれたＣｌｉｅｎｔＵＲＩは「ｏｍａ：ｍｏ：ｏｍ―ｄｍ―ｄｅｖｉｎｆｏ：１．０／／ＦｗＶ？ｃｖ＝６８６８９７６９６ａ７ｃ８７６ｂ７ｅ」と同一であり得る。このＣｌｉｅｎｔＵＲＩは、Ｄｅｖｌｎｆｏ ＭＯの「ＦｗＶ」ノードを称するが、このノードは、Ｄｅｖｌｎｆｏ ＭＯインスタンスに含まれているノードであるので、ｃｖフィールドで伝達された値キャッシュ検証子「６８６８９７６９６ａ７ｃ８７６ｂ７ｅ」は、このＤｅｖｌｎｆｏ ＭＯインスタンスに対するキャッシュ検証子になる。

図４は、本発明の一実施例によってＭＯインスタンスに割り当てられたキャッシュ検証子を用いたリソース要請の例を示す。

ＤＭサーバーは、ＣｌｉｅｎｔＵＲＩで示されるＭＯデータ（リソース）を要請することを決定することができる（Ｓ４０１）。要請のために、ＧＥＴ命令を使用することができる。

その後、ＤＭサーバーが、ＣｌｉｅｎｔＵＲＩが示すノードを含んでいるＭＯインスタンスに対するキャッシュ検証子を有しているか否かを決定することができる（Ｓ４０２）。

ＤＭサーバーがＣｌｉｅｎｔＵＲＩが示すノードを含んでいるＭＯインスタンスに対するキャッシュ検証子を有していると、ＤＭサーバーは、ｃｖフィールドをＣｌｉｅｎｔＵＲＩに含ませてＤＭ命令を送ることができる（Ｓ４０３）。ｃｖフィールドは、該当のＭＯインスタンスに対するキャッシュ検証子を伝達するようになる。キャッシュ検証子は、リソースを獲得する命令に対して使用できるので、ＤＭ ＧＥＴ／ＨＰＵＴ／ＨＰＯＳＴ命令に対して使用することができる。

ＤＭサーバーが、ＣｌｉｅｎｔＵＲＩが示すノードを含んでいるＭＯインスタンスに対するキャッシュ検証子を有していないと、ＤＭサーバーは、ｃｖフィールドなしで、リソース要請命令をＤＭクライアントに伝達することができる（Ｓ４０３）。

ＤＭクライアント（端末）は、ＤＭサーバーがリソースを要請してきた場合、図５に例示した方法によって処理するようになる。

図５は、本発明の一実施例によってＭＯインスタンスに割り当てられたキャッシュ検証子を用いたリソース要請に対する応答又は処理の例を示す。

ＤＭクライアントは、リソース（ＭＯデータ）を獲得するＤＭ命令をＤＭサーバーから受信することができる（Ｓ５０１）。リソースを要請するＤＭ命令は、ＧＥＴ／ＨＰＵＴ／ＨＰＯＳＴのうち一つであり、ＤＭ命令は、ＣｌｉｅｎｔＵＲＩというパラメーターを共に伝達するようになる。このリソース獲得命令は、ＣｌｉｅｎｔＵＲＩが示すノードに対するＭＯデータを要請する命令と解釈することができる。

ＤＭクライアントは、ＤＭ命令のＣｌｉｅｎｔＵＲＩがｃｖフィールドを含んでいるか否かを判断することができる（Ｓ５０２）。

ＤＭ命令のＣｌｉｅｎｔＵＲＩがｃｖフィールドを含んでいると、ＤＭクライアントは、キャッシュ検証手順を行うようになる（Ｓ５０３）。キャッシュ検証手順において、ｃｖフィールドによって提供されたＣＶに対応するＭＯデータが端末で変更されていないと「成功」を返還し、ＭＯデータの一部分でも変更されると「失敗」をリターンしなければならない。ＥＴａｇを例に挙げると、キャッシュ検証手順は、ＤＭクライアントがｃｖフィールドによって提供されたＣＶ（以下、「第１のＣＶ」）がＤＭクライアント内に格納又は存在するＣＶ（以下、「第２のＣＶ」）と同一であるか否かを判断する手順であり、第１のＣＶと第２のＣＶとが同一であると前記手順は成功であり、そうでないと前記手順は失敗である。本キャッシュ検証手順は、キャッシュ検証子の種類によって変わり得る。

一方、前記では、説明の便宜のために、「第１のＣＶ」と「第２のＣＶ」とに区分して説明した。簡単に説明すると、第１のＣＶはＤＭサーバー内に格納されたＣＶで、第２のＣＶはＤＭクライアント（すなわち、端末）内に格納されたＣＶである。第１のＣＶは、第２のＣＶから始まるが（なぜなら、特定ＭＯインスタンス、すなわち、ＭＯ関連ノードの集合に対するＣＶはＤＭ端末によって割り当てられ、後述するように、ＣＶを有していないＤＭサーバーは、特定リソースの要請時、ｃｖフィールドを要請のためのＣｌｉｅｎｔＵＲＩに含ませないことによってＤＭ端末からＣＶを最初に受信するようになる）、説明の便宜のために、ＤＭサーバーとＤＭ端末のそれぞれが格納しているＣＶをそれぞれ第１のＣＶと第２のＣＶと称することができることを知らせておく。

ＭＯデータが変更されていないと、すなわち、キャッシュ検証手順が「成功」を返還すると（Ｅｔａｇキャッシュ検証子の場合、第１のＣＶと第２のＣＶとが同一であると「成功」）、ＤＭクライアントは、「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」をＤＭサーバーに伝送し、要請されたＭＯデータをＤＭサーバーに伝送しない。この応答を受けたＤＭサーバーは、ローカルキャッシュを利用又は参照する。

ＤＭ命令のＣｌｉｅｎｔＵＲＩがｃｖフィールドを含んでいないと、ＤＭクライアントは、ＣｌｉｅｎｔＵＲＩによって称されるＭＯデータをＤＭサーバーに伝送することができる（Ｓ５０５）。また、Ｓ５０３において、キャッシュ検証手順が「失敗」である場合、すなわち、ＤＭサーバーが有している該当のＭＯデータのｃｖ（第１のＣＶ）がＤＭクライアントが管理している該当のＭＯデータのｃｖ（第２のＣＶ）と異なる場合、ＤＭクライアントは、ＣｌｉｅｎｔＵＲＩによって称されるＭＯデータをＤＭサーバーに伝送することができる（Ｓ５０５）。

一方、リソースを要請するＤＭ命令内のｃｖフィールド（簡単に、ｃｖ）が含まれていないか、キャッシュ検証手順が失敗である場合、ＤＭクライアントは、リソース（すなわち、ＭＯデータ）をＤＭサーバーに伝送するが、追加的にｃｖを伝送するか否かを決定することができる。その一方、従来技術の場合、如何なる理由（例えば、主にアップデート）によってＤＭサーバーが格納しているｃｖとＤＭクライアントが管理するｃｖとが異なると、該当のリソースと共に、ＤＭクライアントが管理するｃｖをＤＭサーバーに伝送する。

追加的にｃｖを伝送するか否かを決定するために、ＤＭクライアントは、ＤＭ命令、より詳細には、ＣｌｉｅｎｔＵＲＩがキャッシュ可能ＭＯインスタンスのルートノードを称しているか否かを判断することができる（Ｓ５０６）。すなわち、ＤＭクライアントは、ＣｌｉｅｎｔＵＲＩが示すノードが含まれたＭＯインスタンスがキャッシュ可能ＭＯインスタンスであるか否かと、ＣｌｉｅｎｔＵＲＩで示されたノードがキャッシュ可能ＭＯインスタンスのルートノードであるか否かを判断することができる。

ＣｌｉｅｎｔＵＲＩがＭＯインスタンスのルートノードを称し、ＭＯインスタンスがキャッシュ可能ＭＯインスタンスであると、ＤＭクライアントは、ＭＯインスタンスに対するキャッシュ検証子を追加的にＤＭサーバーに伝送することができる（Ｓ５０７）。ＤＭクライアントの応答過程はここで終了する。ＤＭサーバーは、キャッシュ検証子を格納し、後ほどでＭＯデータを要請するときに使用することができる。

ＣｌｉｅｎｔＵＲＩがＭＯインスタンスのルートノードを称しないか、ＭＯインスタンスがキャッシュ可能ＭＯインスタンスでないと、ＤＭクライアントは、追加的にキャッシュ検証子をＤＭサーバーに伝送しない（Ｓ５０８）。

ＤＭクライアントは、Ｓ５０７でキャッシュ検証子をＤＭサーバーに伝送することができる。キャッシュ検証子は、ＭＯデータと共に伝達され、ＣｌｉｅｎｔＵＲＩがキャッシュ可能ＭＯインスタンスのルートノードを称する場合にＤＭサーバーに伝達する。ＣｌｉｅｎｔＵＲＩがキャッシュ可能ＭＯインスタンスのルートノードを称していない場合はキャッシュ検証子を伝達してはならない。キャッシュ検証子は、ＭＯインスタンス全体に対する有効性情報を与えるようになるが、これは、ＭＯインスタンスの一部のみをＤＭサーバーが受けた場合、後ほどでＤＭクライアントの有効性検証に問題が生じるためである。

すなわち、ＤＭサーバーから要請されたリソースがＭＯインスタンスのルートノードの下位にあるノード（リソース）で、要請されたリソース以外の他のリソースが変更された場合であると、ＤＭクライアントが要請されたリソースをＤＭサーバーに伝送するとき、変更されたリソース（この変更されたリソースは、ＤＭサーバーが要請したリソースではないので、ＤＭサーバーに伝送されない）が反映された第２のＣＶをＤＭサーバーに伝送すると、ＤＭサーバーは、端末では変更されたが、自分が獲得できなかった要請されたリソース以外の他のリソースに対する獲得機会を失い、これは、ＣＶの機能喪失を意味する。

このような有効性検証問題に対して、図６を参照してより具体的に説明する。図６は、ＤＭサーバーがＤＭクライアントへのキャッシュ可能ＭＯインスタンスのルートノードに対する要請及びルートノードでないリソースに対する要請を全て含む場合を例示する。

ＤＭサーバーは、ＤＭクライアントにＣｌｉｅｎｔＵＲＩ「ｍｏｉｄ：１．１」をＭＯ ＩＤとして有するＭＯインスタンスを要請する（Ｓ６０１）。ＣｌｉｅｎｔＵＲＩ「ｍｏｉｄ：１．１／／」は、該当のＭＯインスタンスのルートノードを称する。端末が有しているＭＯインスタンスは、図６の右側の上に共に表現した。

ＤＭクライアントは、ＤＭサーバーが要請したＭＯインスタンスの全体データを伝送し、ＭＯインスタンスに割り当てられたキャッシュ検証子「ＣＶ１」をＤＭサーバーに伝達する（Ｓ６０２）。ＤＭクライアントは、ｃノードの名前を変えるなど、ｃノードに対するアップデートを行う。その後、ＭＯインスタンスの情報（すなわち、ｃノードに対する情報）が変わったので、キャッシュ検証子を「ＣＶ２」にアップデートする（Ｓ６０３）。

ＤＭサーバーは、ＣｌｉｅｎｔＵＲＩ「ｍｏｉｄ：１．１／／ｂ？ｃｖ＝ＣＶ１」でインテリアノードｂとその下位ノードに対する情報を要請する（Ｓ６０４）。このとき、Ｓ６０２で受信した「ＣＶ１」は、ｃｖフィールドを通じてＤＭクライアントに伝達する。

その後、ＤＭクライアントは、受信されたＣＶ１に基づいてキャッシュ検証手順を行うことができる（Ｓ６０５）。すなわち、ＤＭクライアントは、「ＣＶ１」が有効であるか否かを判断することができる。Ｓ６０３において、ＤＭクライアントは、ＭＯインスタンスの情報をアップデートし、それによって、キャッシュ検証子をＣＶ２にアップデートした。したがって、ＤＭクライアントは、ＤＭサーバーからＳ６０４で受信された「ＣＶ１」と自分が有しているキャッシュ検証子「ＣＶ２」とが異なるので、キャッシュ有効性検証を失敗と判断する（例では、キャッシュ検証子がＥＴａｇであることを仮定した）。

したがって、ＤＭクライアントは、Ｓ６０４で要請された情報（ノードｂとその下位ノードｄ及びｅ）と自分が有しているキャッシュ検証子「ＣＶ２」とをＤＭサーバーに伝送することができる（Ｓ６０６）。図５と関連して説明した本発明の一実施例は、Ｓ６０６に対応する場合に「ＣＶ２」の伝達を許容しないが、キャッシュ検証子「ＣＶ２」を伝達するように設定し、問題を示すようにする。すなわち、Ｓ６０６では、図５と関連して説明した本発明の一実施例とは異なり、ＤＭクライアントは、ＤＭサーバーからの要請がＭＯインスタンスのルートノードに対する要請でないにもかかわらず、キャッシュ検証子をＤＭサーバーに伝送する。

そのため、ＤＭサーバーは、キャッシュ検証子「ＣＶ２」を格納（すなわち、既存の「ＣＶ１」から「ＣＶ２」にアップデート）することができる。

ＤＭサーバーは、ＣｌｉｅｎｔＵＲＩ「ｍｏｉｄ：１．１／／ｃ？ｃｖ＝ＣＶ２」を使用してｃノードに対する情報を要請する（Ｓ６０７）。このとき、ＤＭサーバーは、Ｓ６０６でＤＭクライアントから伝達されたキャッシュ検証子「ＣＶ２」をｃｖフィールドの形態で共に伝達する。

ＤＭクライアントは、Ｓ６０５と同様に、ＤＭサーバーからのキャッシュ検証子を検証するためのキャッシュ検証手順を行うことができる（Ｓ６０８）。ＤＭクライアントが有しているキャッシュ検証子も「ＣＶ２」であるので、ＤＭクライアントは、ＤＭサーバーからのキャッシュ検証子「ＣＶ２」が有効であると判断し、キャッシュ検証手順を「成功」と決定する。キャッシュ検証手順が成功であるので、ＤＭクライアントは、「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」という応答コードをＤＭサーバーに伝送する（Ｓ６０９）。

ここで、問題は、ＤＭサーバーがアップデートされたｃノードの最新情報を有していないにもかかわらず、Ｓ６０９で「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」という応答を受けるようになり、ＤＭサーバーが自分がｃノードに対する最新情報を有していると誤認するという点にある。これは、ＤＭサーバーの要請がＭＯインスタンスルートノードを対象としないにもかかわらず、ＤＭクライアントがＳ６０６でキャッシュ検証子「ＣＶ２」をＤＭサーバーに伝達するためである。伝達された「ＣＶ２」は、結局、ＤＭサーバーがＳ６０７でｃノードに対する情報を要請するときに使用されるので、ＤＭクライアントは、ＤＭサーバーがｃノードに対する最新情報を有していると誤って判断し、ｃノードのアップデートされた情報をＤＭサーバーに伝送しない。このような問題を事前に防止するために、Ｓ６０７の要請に一つのｃノードに対するキャッシュ検証子を含むこともできる。しかし、結局、これは、サブツリーごとにキャッシュ検証子が存在するＨＴＴＰウェブキャッシュ方法と類似しており、したがって、キャッシュ検証子を管理し、リソースを要請／応答するメカニズムが複雑になる。

しかし、図５と関連する本発明の一実施例によると、キャッシュ検証子をＭＯインスタンス自体のみに選択的に割り当て、キャッシュ検証子の割り当てによるプロセッシング負荷を減少させることができ、キャッシュ検証子を用いたキャッシュ検証手順を簡略且つ効率的に行うことができる。

すなわち、本発明の一実施例は、従来技術で全てのリソースのそれぞれに対してキャッシュ検証子（ＣＶ）を割り当てた場合と異なり、キャッシュ検証子をＭＯインスタンス自体のみに割り当て、ＣＶをいずれのノードに割り当てるのかに対する複雑な問題を解消することができる。また、このようなＭＯインスタンス自体に割り当てられたＣＶを通じて全てのリソースの最新性をＤＭサーバー―ＤＭ端末間で共有するために、ＤＭサーバーからのＣＶ（第１のＣＶ）が有効でないと検証されるとしても、常にＤＭ端末に格納されたＣＶ（第２のＣＶ）をＤＭサーバーに伝送しない。この場合、第２のＣＶの伝送の有無を判断するために要請されたリソースがいずれのリソースであるかを確認し、事前に特定されたリソースである場合のみに、ＤＭ端末は第２のＣＶをＤＭサーバーに伝送することができる。

次に、本発明の一実施例を具体的な例に挙げて説明する。

下記は、Ｄｅｖｌｎｆｏ ＭＯのＦｗＶノード（デバイスのファームウェアバージョン情報を格納）を要請するＧＥＴ命令を示したものである。ＦｗＶノードを要請する１番目のＧＥＴ命令である場合、ＤＭサーバーは、これに対するローカルキャッシュはもちろん、これに対するキャッシュ検証子を有していない可能性があるので、キャッシュ検証子なしで、ＧＥＴ命令を下記のように伝送するようになる。

ＤＭクライアントが前記のＧＥＴ命令を受けると、キャッシュ検証子がないので、下記のようにＤＭサーバーが要請したリソースを伝送するようになる。ＤＭクライアントは、リソースを伝送するとき、リソースに対するキャッシュ検証子を共に送ることができ、これは、以下の「ＣＶ」キーを通じてキャッシュ検証子を伝達する。ここでは、ＥＴａｇをキャッシュ検証子と仮定した。

ＤＭクライアントから前記のような応答を受けた場合、ＤＭサーバーは、端末のファームウェアバージョンである「ａｎｄｒｏｉｄ４．０．４」とこのリソースに対するキャッシュ検証子である「６８６８９７６９６ａ７ｃ８７６ｂ７ｅ」を共に格納することができる。この場合、後ほどで同一のリソースをＤＭサーバーが要請するとき、下記のようなＧＥＴ命令を使用してリソースを要請することができる。ＣｌｉｅｎｔＵＲＩのｃｖフィールドで伝達された「６８６８９７６９６ａ７ｃ８７６ｂ７ｅ」がキャッシュ検証子である。

ＤＭクライアントは、このようなＰａｃｋａｇｅ＃２を受けたとき、キャッシュ検証手順を行った後、キャッシュが有効であると、ＤＭサーバーに「Ｎｏｔ Ｍｏｄｉｆｉｅｄ」を知らせる状態コード（３０４）を伝送する。この場合、ＤＭサーバーは、ローカルキャッシュが依然として有効であることを知るようになり、ローカルキャッシュに格納された「ａｎｄｒｏｉｄ４．０．４」を使用することができる。下記は、「３０４ Ｎｏｔ Ｍｏｄｉｆｉｅｄ」を知らせるＰａｃｋａｇｅ＃３である。

ＤＭクライアントがキャッシュ検証手順を通じてキャッシュが有効でないことを知ると、リソースを送ることができる。下記は、この場合に対するＰａｃｋａｇｅ＃３である。

図７は、本発明の各実施例を行うように構成された装置のブロック図である。伝送装置１０及び受信装置２０は、情報及び／又はデータ、信号、メッセージなどを運ぶ無線信号を伝送又は受信できるＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）ユニット１３、２３と、無線通信システム内の通信と関連する各種情報を格納するメモリ１２、２２と、ＲＦユニット１３、２３及びメモリ１２、２２などの構成要素と動作的に連結され、構成要素を制御し、該当の装置が上述した本発明の各実施例のうち少なくとも一つを行うようにメモリ１２、２２及び／又はＲＦユニット１３、２３を制御するように構成されたプロセッサ１１、２１とをそれぞれ含む。

メモリ１２、２２は、プロセッサ１１、２１の処理及び制御のためのプログラムを格納することができ、入／出力される情報を臨時格納することができる。メモリ１２、２２はバッファーとして活用することができる。

プロセッサ１１、２１は、通常、伝送装置又は受信装置内の各種モジュールの全般的な動作を制御する。特に、プロセッサ１１、２１は、本発明を行うための各種制御機能を行うことができる。プロセッサ１１、２１は、コントローラー、マイクロコントローラー、マイクロプロセッサ、マイクロコンピューターなどと称することもできる。プロセッサ１１、２１は、ハードウェア、ファームウェア、ソフトウェア、又はこれらの結合によって具現することができる。ハードウェアを用いて本発明を具現する場合は、本発明を行うように構成されたＡＳＩＣｓ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔｓ）、ＤＳＰｓ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒｓ）、ＤＳＰＤｓ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ ｄｅｖｉｃｅｓ）、ＰＬＤｓ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｄｅｖｉｃｅｓ）、ＦＰＧＡｓ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙｓ）などをプロセッサ１１、２１に備えることができる。一方、ファームウェアやソフトウェアを用いて本発明を具現する場合は、本発明の機能又は各動作を行うモジュール、手順又は関数などを含むようにファームウェアやソフトウェアを構成することができ、本発明を行えるように構成されたファームウェア又はソフトウェアは、プロセッサ１１、２１内に備えたり、メモリ１２、２２に格納してプロセッサ１１、２１によって駆動することができる。

本発明の各実施例において、端末、ＤＭクライアント、ＤＭサーバーなどは、それぞれ伝送装置１０又は受信装置２０として動作することができる。

このような受信装置又は伝送装置として、端末、ＤＭクライアント、ＤＭサーバーなどの具体的な構成は、図面と関連して上述した本発明の多様な実施例で説明した各事項を独立的に適用したり、又は二つ以上の実施例を同時に適用するように具現することができる。

上述したように開示された本発明の好ましい各実施例に対する詳細な説明は、当業者が本発明を具現して実施できるように提供された。以上では、本発明の好ましい各実施例を参照して説明したが、該当の技術分野で熟練した当業者は、下記の特許請求の範囲に記載した本発明の思想及び領域から逸脱しない範囲内で本発明を多様に修正及び変更させ得ることを理解できるだろう。したがって、本発明は、ここに示した各実施形態に制限されるものではなく、ここで開示した各原理及び新規な各特徴と一致する最広の範囲を付与しようとするものである。

本発明は、端末、基地局、サーバーなどの無線通信装置に使用することができる。

Claims (14)

1. ＭＯインスタンスに割り当てられたキャッシュ検証子（ＣＶ）を用いたＭＯデータの要請を処理するための方法であって、前記方法は端末によって行われ、前記ＭＯインスタンスは、一つ以上のノードからなるツリー構造で構成され、前記ＭＯデータは、前記ＭＯインスタンスに含まれたノードの名前、ノードの値及びノードの構造を含み、前記方法は、
   サーバーから前記ＭＯインスタンスの特定ＭＯデータを獲得するための前記特定ＭＯデータを識別するＵＲＩ情報を含む要請を受信するステップと、
   前記ＵＲＩ情報に第１のＣＶが含まれているか否かを判断するステップと、を含み、
   前記ＵＲＩ情報に前記第１のＣＶが含まれていないと、
   前記要請された特定ＭＯデータを前記サーバーに伝送するステップと、
   前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを伝送するステップと、を含むことを特徴とする、リソース要請処理方法。
2. 前記ＵＲＩ情報に前記第１のＣＶが含まれていると、前記第１のＣＶを検証するステップと、
   前記第１のＣＶが有効であると検証されると、前記第１のＣＶの有効であることを指示する結果を前記サーバーに伝送するステップと、
   前記第１のＣＶが有効でないと検証されると、前記要請された特定ＭＯデータを前記サーバーに伝送し、前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを伝送するステップと、をさらに含む、請求項１に記載のリソース要請処理方法。
3. 前記ＭＯインスタンスに変更が発生すると、前記ＭＯインスタンスに対する第２のＣＶをアップデートするステップをさらに含む、請求項１に記載のリソース要請処理方法。
4. 前記ＭＯインスタンスは、キャッシュが設定可能である、請求項１に記載のリソース要請処理方法。
5. 前記第１のＣＶは、前記ＵＲＩに含まれた特定フィールドによって提供される、請求項１に記載のリソース要請処理方法。
6. 前記ＭＯインスタンスに何ら変更も発生していないと、前記第１のＣＶは有効であると判断される、請求項２に記載のリソース要請処理方法。
7. ＭＯインスタンスに割り当てられたキャッシュ検証子（ＣＶ）を用いたＭＯデータを要請するための方法であって、前記方法はサーバーによって行われ、前記ＭＯインスタンスは、一つ以上のノードからなるツリー構造で構成され、前記ＭＯデータは、前記ＭＯインスタンスに含まれたノードの名前、ノードの値及びノードの構造を含み、前記方法は、
   前記ＭＯインスタンスの特定ＭＯデータを獲得するための前記特定ＭＯデータを識別するＵＲＩ情報を含む要請を前記端末に伝送するステップと、
   前記ＭＯインスタンスに対する第１のＣＶを知っていると、前記ＵＲＩ情報に前記第１のＣＶを含ませるステップと、
   前記ＭＯインスタンスに対する第１のＣＶを知っていないと、前記ＵＲＩ情報に前記第１のＣＶを含ませることを防ぐステップと、
   前記ＵＲＩ情報に前記第１のＣＶが含まれていないと、前記要請された特定ＭＯデータを前記端末から受信し、前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを受信するステップと、を含むことを特徴とする、リソース要請方法。
8. 前記ＵＲＩ情報に前記第１のＣＶが含まれると、前記端末によって前記第１のＣＶが検証され、
   前記第１のＣＶが有効なものと検証されると、前記第１のＣＶの有効性を指示する結果を前記端末から受信するステップと、
   前記第１のＣＶが有効でないと検証されると、前記要請された特定ＭＯデータを前記端末から受信し、前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを前記端末から受信するステップと、を含む、請求項７に記載のリソース要請方法。
9. 前記ＭＯインスタンス内の特定リソースが変更されると、前記ＭＯインスタンスに対する第２のＣＶはアップデートされる、請求項７に記載のリソース要請方法。
10. 前記ＭＯインスタンスは、キャッシュが設定可能である、請求項７に記載のリソース要請方法。
11. 前記第１のＣＶは、前記ＵＲＩに含まれた特定フィールドによって提供される、請求項７に記載のリソース要請方法。
12. 前記ＭＯインスタンスに何ら変更も発生していないと、前記第１のＣＶは有効であると判断される、請求項８に記載のリソース要請方法。
13. ＭＯインスタンスに割り当てられたキャッシュ検証子（ＣＶ）を用いたＭＯデータ要請を処理するための端末であって、前記ＭＯインスタンスは、一つ以上のノードからなるツリー構造で構成され、前記ＭＯデータは、前記ＭＯインスタンスに含まれたノードの名前、ノードの値及びノードの構造を含み、前記端末は、
    無線周波数（ＲＦ）ユニットと、
    前記ＲＦユニットを制御するように構成されたプロセッサと、を含み、
    前記プロセッサは、サーバーから前記ＭＯインスタンスの特定ＭＯデータを要請するための前記特定ＭＯデータを識別するＵＲＩ情報を含む要請を受信し、前記ＵＲＩ情報に第１のＣＶが含まれているか否かを判断するように構成され、
    前記ＵＲＩ情報に前記第１のＣＶが含まれていないと、前記プロセッサは、前記特定ＭＯデータを前記サーバーに伝送し、前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを伝送するように構成されることを特徴とする端末。
14. ＭＯインスタンスに割り当てられたキャッシュ検証子（ＣＶ）を用いたＭＯデータを要請するためのサーバーであって、前記ＭＯインスタンスは、一つ以上のノードからなるツリー構造で構成され、前記ＭＯデータは、前記ＭＯインスタンスに含まれたノードの名前、ノードの値及びノードの構造を含み、前記サーバーは、
    無線周波数（ＲＦ）ユニットと、
    前記ＲＦユニットを制御するように構成されたプロセッサと、を含み、
    前記プロセッサは、前記ＭＯインスタンスの特定ＭＯデータを要請するための前記特定ＭＯデータを識別するＵＲＩ情報を含む要請を前記端末に伝送し、前記ＭＯインスタンスに対する第１のＣＶを知っていると、前記ＵＲＩ情報に前記第１のＣＶを含ませるように構成され、
    前記ＵＲＩ情報に前記第１のＣＶが含まれていないと、前記プロセッサは、前記要請された特定ＭＯデータを前記端末から受信し、前記ＵＲＩ情報が前記ＭＯインスタンスのルートノードを指示すると、前記ＭＯインスタンスに対する第２のＣＶを受信するように構成されることを特徴とする、サーバー。

Images