(57)【要約】  遠隔管理プロトコルにより、互いとインタフェースをとる顧客宅内装置（ＣＰＥ）と遠隔管理サーバ（ＡＣＳ）との間のアラーム通知のための方法は、−  顧客宅内装置（ＣＰＥ）内でアラーム状態を検出すること、−  遠隔管理プロトコルを介して、顧客宅内装置（ＣＰＥ）から遠隔管理サーバ（ＡＣＳ）に明示的アラーム通知を転送すること、および−  前記遠隔管理サーバ（ＡＣＳ）におけるアラーム基準の事前検証なしで、遠隔管理サーバ（ＡＣＳ）によって明示的アラーム通知に応答することを含む。
2012517724.tif 000002
【特許請求の範囲】
【請求項１】
遠隔管理プロトコルにより互いとインタフェースをとる顧客宅内装置（ＣＰＥ）と遠隔管理サーバ（ＡＣＳ）との間のアラーム通知のための方法であって、
−  前記顧客宅内装置（ＣＰＥ）内でアラーム状態を検出するステップと、
−  前記遠隔管理プロトコルを介して、前記顧客宅内装置（ＣＰＥ）から前記遠隔管理サーバ（ＡＣＳ）に明示的アラーム通知を転送するステップと、
−  前記遠隔管理サーバ（ＡＣＳ）におけるアラーム基準の事前検証なしで、前記遠隔管理サーバ（ＡＣＳ）によって前記明示的アラーム通知に応答するステップとを含むことを特徴とする、方法。
【請求項２】
前記遠隔管理プロトコルがＴＲ−０６９ＣＰＥ  ＷＡＮ管理プロトコルであることを特徴とする、請求項１に記載の方法。
【請求項３】
前記明示的アラーム通知が専用アラームリモートプロシージャコールからなることを特徴とする、請求項２に記載の方法。
【請求項４】
前記明示的アラーム通知が、ＴＲ−０６９インフォームリモートプロシージャコールに含まれるアラームイベントからなることを特徴とする、請求項２に記載の方法。
【請求項５】
前記方法が、前記専用アラームリモートプロシージャコールの転送および応答を、他のＴＲ−０６９リモートプロシージャコールよりも優先させることをさらに含むことを特徴とする、請求項３に記載の方法。
【請求項６】
請求項１に記載の方法における使用に適合された、遠隔管理サーバ（ＡＣＳ）。
【請求項７】
請求項１に記載の方法における使用に適合された、顧客宅内装置（ＣＰＥ）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概して、顧客宅内機器（ＣＰＥ）と、本特許出願を通して遠隔管理サーバという名称の自動構成サーバ（ＡＣＳ）との間のアラーム通知に関する。ＣＰＥ、すなわち顧客宅内装置の例は、デジタル加入者線（ＤＳＬ）モデム、セットトップボックス（ＳＴＢ）、ＷｉＦｉホットスポットやＦＥＭＴＯセルなどの無線ルータ、携帯電話、携帯情報端末（ＰＤＡ）などの無線端末などである。顧客宅内機器および遠隔管理サーバは、遠隔管理プロトコルにより、互いとインタフェースをとると想定される。本特許出願のコンテキストにおけるアラームは、たとえば限界バッテリレベル、ハッキングの試みなどのセキュリティ違反の通知などを含む。
【背景技術】
【０００２】
遠隔管理システムは、顧客装置内の管理プラットフォーム、ネットワーク内の遠隔管理サーバ、ならびに顧客装置内の管理プラットフォーム上で稼動する管理クライアントまたはエージェントと、遠隔管理サーバとの間の通信用の遠隔管理プロトコルからなる。
【０００３】
管理プラットフォーム例は、ＯＳＧｉ（オープンサービスゲートウェイ構想）サービスプラットフォームであり、このプラットフォームは、遠隔管理される顧客装置内にあるＪａｖａ（登録商標）仮想マシン（ＪＶＭ）の上で稼動するＪａｖａ（登録商標）ベースのサービスプラットフォームである。ＯＳＧｉサービスプラットフォームが顧客装置内にあることにより、顧客装置の動作を中断することなく、ネットワーク内のどこでも、自動構成サーバからのソフトウェアの遠隔インストールおよび管理が可能になる。このように、ソフトウェアアプリケーションのインストール、新バージョンへのソフトウェアアプリケーションのアップグレード、アプリケーションの再構成、アプリケーションの新規特徴の追加または認証、および顧客装置からのアプリケーションの削除が、顧客施設内に技師を派遣することなく、また、顧客による介入を必要とせずに可能にされる。管理プラットフォームのおかげで、１台の顧客装置上で稼動するソフトウェアサービスまたはアプリケーションは、その能力を互いと共有することができる。
【０００４】
管理エージェントまたは管理クライアントは、バンドルまたはソフトウェアアプリケーションと、遠隔管理サーバとの間のインタフェースとして作用し、顧客装置内の管理プラットフォームが遠隔管理サーバに管理可能パラメータを公開するのを可能にする。
【０００５】
管理プロトコルの役割は、自動構成サーバがパラメータ値を安全に読み込み、または書き込んで、顧客装置内でソフトウェアを構成し、最終的には顧客装置の状況および統計値を監視することができるようにするための機構を提供することである。顧客装置の安全な遠隔管理のための管理プロトコル例は、たとえば以下のＵＲＬによりインターネットから入手することができる、「ＣＰＥ  ＷＡＮ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ」という名称の、技術報告ＴＲ−０６９においてＤＳＬフォーラムによって定義されるＴＲ−０６９プロトコルである：
ｈｔｔｐ：／／ｄｓｌｆｏｒｕｍ．ｏｒｇ／ａｂｏｕｔｄｓｌ／ｔｒ＿ｔａｂｌｅ．ｈｔｍｌ
ＴＲ−０６９プロトコルは、ＣＰＥ装置上で稼動するソフトウェア構成要素のパラメータおよびパラメータ属性を自動構成サーバが読込み／書込み／構成可能にするためのリモートプロシージャコール（ＲＰＣ）に基づく、すなわち汎用メッセージに基づく機構である。各パラメータは、名前と値のペアからなる。名前は、特定のパラメータを識別し、ディレクトリ中のファイルと同様の階層構造をもち、異なるレベルが「．」（ドット）によって区切られる。パラメータの値は、いくつかの定義済みデータタイプの１つでよい。各パラメータはさらに、自動構成サーバが、パラメータを読み込むことだけを認められるか、それともパラメータの値を変更することも認められるかに依存して、読取り専用または読み書き可能パラメータとして定義され得る。
【０００６】
ある特定の例は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）サービス、またはクライアント−サーバ通信用にＡＤＳＬもしくはＶＤＳＬモデムにインストールされるアプリケーションであり得る。ＨＴＴＰアプリケーションの全パラメータが、ＨＴＴＰアプリケーションのパラメータモデルを構成する。パラメータ例は、ＨＴＴＰアプリケーションがリッスンするポートの番号または識別である。ＡＤＳＬまたはＶＤＳＬモデムは、Ｊａｖａ（登録商標）仮想マシンの上で稼動するＯＳＧｉプラットフォームをもつものと想定される。ＯＳＧｉプラットフォームは、ＨＴＴＰアプリケーションの能力を、他のアプリケーション、たとえばウェブブラウザと共有することを可能にする。ＯＳＧｉプラットフォームの上にインストールされたＴＲ−０６９管理エージェントを介して、ＨＴＴＰアプリケーションのパラメータが、ＤＳＬネットワークまたは他の任意のＴＲ−０６９認識バンドル内の自動構成サーバ（ＡＣＳ）にとって可視的にされ、アクセス可能にされ得る。
【０００７】
事業者は、アラーム管理のサポートを要求しているが、現時点では、ＴＲ−０６９においてアラームを記述し管理する標準的なやり方はない。ＴＲ−０６９に基づく遠隔管理システムにおいてアラーム管理を実装するための直接的なやり方では、ＴＲ−０６９機構を用いて、オブジェクトモデルにおけるパラメータの値変化をＡＣＳに通知する。
【０００８】
パラメータの通知属性は、そのパラメータの変化値を、ＴＲ−０６９セッション中にＡＣＳに送信されるインフォームメッセージに、それともインフォームリモートプロシージャコール（ＲＰＣ）に、ＣＰＥが含めるべきかを示す。パラメータの値変化の「能動的」と「受動的」通知との区別がなされる。受動的通知のケースでは、ＣＰＥは、パラメータの新規値を、ＡＣＳに対して確立される次のＴＲ−０６９セッション中に送信されるインフォームＲＰＣのＰａｒａｍｅｔｅｒＬｉｓｔに含めなければならない。能動的通知のケースでは、ＣＰＥは、ＡＣＳに対してＴＲ−０６９セッションを開始し、新規値を、関連づけられたインフォームＲＰＣのＰａｒａｍｅｔｅｒＬｉｓｔに含めなければならない。
【０００９】
たとえば、従来技術の方法による低バッテリアラーム管理について検討する。これに対して、ＣＰＥのＴＲ−０６９データモデルは、ＣＰＥ装置のバッテリのレベルを示すＢａｔｔｅｒｙＬｅｖｅｌパラメータを含むと仮定される。ＴＲ−０６９データモデルにおいて、このパラメータは、たとえば以下のように命名され得る：
ｄｅｖｉｃｅ．＊．Ｂａｔｔｅｒｙ．｛ｉ｝．ＢａｔｔｅｒｙＬｅｖｅｌ
ここで、「ｄｅｖｉｃｅ」は、ＴＲ−０６９ツリーのルートオブジェクトであり、「＊」は、子ＴＲ−０６９オブジェクト用のワイルドカードであり、「｛ｉ｝」は、ＴＲ−０６９データモデルにいくつかのＢａｔｔｅｒｙオブジェクトが存在し得ることを示す。
【００１０】
初期バッテリレベルは１００％であり、ＣＰＥ装置は電源に接続されておらず、その結果、バッテリレベルが時間とともに低下するとさらに再度仮定される。ＣＰＥ装置は、バッテリレベルの変化を５％の増分／減分で検出可能であるとも仮定される。
【００１１】
ＡＣＳは、「ｄｅｖｉｃｅ．＊．Ｂａｔｔｅｒｙ．｛ｉ｝．ＢａｔｔｅｒｙＬｅｖｅｌ」パラメータを、能動的通知で構成すると仮定される。ＡＣＳにおいて、ローカルアラーム基準が構成される。すなわち、パラメータ「ｄｅｖｉｃｅ．＊．Ｂａｔｔｅｒｙ．｛ｉ｝．ＢａｔｔｅｒｙＬｅｖｅｌ」の値が２０％以下になるとすぐに、低バッテリアラーム状態が発せられる。ＡＣＳは、外部システム、たとえば事業者に低バッテリアラーム状態を報告するようにさらに構成され得る。
【００１２】
パラメータ値変化報告に基づく直接的な手法では、ＣＰＥは、９５％、９０％、８５％、８０％、７５％、７０％、．．．、２０％、１５％、．．．というバッテリレベル値に対して、ＡＣＳへのＴＲ−０６９インフォームＲＰＣを使うことになる。このことは、ＡＣＳがアラーム状態を検出する前に、かなりの数の値変化インフォームメッセージがＣＰＥによってＡＣＳに報告され、ＣＰＥとＡＣＳとの間のネットワークセグメント内の資源を不必要に占有し、報告される値変化をアラーム基準と突き合わせて検証するために、ＡＣＳ内の資源を不必要に占有してしまうことを意味する。
【００１３】
ＣＰＥのデータモデルがｙ個の分岐を含み、各分岐がｉ個のパラメータをもつ第２の例について検討する。全分岐中の全パラメータは、能動的通知用にマーキングされる。したがって、最悪のケースでは、従来技術ソリューションにおいてＣＰＥからＡＣＳに送信される値変化インフォームＲＰＣは、以下のパラメータリストを含むことになる：
ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈ１．Ａ１、ｖａｌｕｅ＝ｂ１ａ１
ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈ１．Ａ２、ｖａｌｕｅ＝ｂ１ａ２
．．．
ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈ１．Ａｉ、ｖａｌｕｅ＝ｂ１ａｉ
ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈ２．Ａ１、ｖａｌｕｅ＝ｂ２ａ１
ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈ２．Ａ２、ｖａｌｕｅ＝ｂ２ａ２
．．．
ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈ２．Ａｉ、ｖａｌｕｅ＝ｂ２ａｉ
．．．
ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈｙ．Ａ１、ｖａｌｕｅ＝ｂｙａ１
ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈｙ．Ａ２、ｖａｌｕｅ＝ｂｙａ２
．．．
ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈｙ．Ａｉ、ｖａｌｕｅ＝ｂｙａｉ
【００１４】
このような値変化インフォームＲＰＣが受け取られることになったとき、ＡＣＳは、インフォームＲＰＣ中の各新規パラメータ値を、ローカルアラーム基準と比較し、アラームを発する状態の少なくとも１つが満たされるかどうか検証しなければならなくなる。このことは、特に分岐の量が多い、たとえばｙ＝１０であると想定され、分岐ごとのパラメータの数が大きい、たとえばｉ＝１００であると想定される場合、ＡＣＳに対してかなりの負荷となる。
【００１５】
要約すると、アラーム通知のためにＴＲ−０６９値変更通知機構を使うことの欠点は、そのスケーラビリティであり、ＡＣＳに対して課される特有の負荷である。実際、変化したパラメータ値をＡＣＳに報告する各インフォームメッセージごとに、ＡＣＳは、アラーム状態が満たされるかどうか判定しなければならない。そうするために、ＡＣＳは、たとえば新規パラメータ値を閾値と比較するなど、ローカルアラーム基準を評価しなければならない。このようなローカルアラーム基準の数によっては、ＡＣＳは、報告されるパラメータ値変化の処理に、大幅な時間および資源量を費やし得る。
【００１６】
ＴＲ−０６９インフォームメッセージに基づく直接的なアラーム管理手法の別の欠点は、「リアルタイム」のアラーム通知を遂行することの難しさである。特に、セキュリティ攻撃や低バッテリ状況のような緊急アラーム状態に対して、事業者は、ＴＲ−０６９プラットフォームにおけるリアルタイムアラーム通知のサポートを要求している。しかし、ＴＲ−０６９では、ＴＲ−０６９セッションごとにただ１つのインフォームメッセージしか送信することができない。このことは、既存のＴＲ−０６９セッション中にアラーム状態が検出されたとき、現在のＴＲ−０６９セッションが終わり、新たなＴＲ−０６９セッションが開かれ、パラメータ値変化が転送され処理されるまで、ＣＰＥは、パラメータ値変化を報告することができず、ＡＣＳは、アラーム状態に関する知識を得ることができないということを含意する。ＴＲ−０６９セッションがＴＣＰベースであるケースでは、ＴＲ−０６９セッションが終了されると、ＴＣＰ接続が閉じられなければならない。その結果、新たなＴＣＰ接続が開かれ得る前に、最大セグメント生存時間（ＭＳＬ）の２倍が経過することになり、アラーム用パラメータ値変化を報告するための総持続期間が数分まで増す可能性があり、これは事業者にとって許容できない。事業者は、リアルタイムに、すなわち３０秒以内、または６０秒以内にＡＣＳに緊急アラームが報告されることを望む。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】欧州特許出願公開第０８２９０３３３号明細書
【非特許文献】
【００１８】
【非特許文献１】ＴＲ−０６９「ＣＰＥ  ＷＡＮ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ」、ｈｔｔｐ：／／ｄｓｌｆｏｒｕｍ．ｏｒｇ／ａｂｏｕｔｄｓｌ／ｔｒ＿ｔａｂｌｅ．ｈｔｍｌ
【発明の概要】
【発明が解決しようとする課題】
【００１９】
本発明の目的は、遠隔管理システムにおけるアラーム通知を可能にするが、直接的なパラメータ値変更通知に基づく機構の上述した欠点および短所を克服する方法、ＣＰＥおよびＡＣＳを提供することである。詳細には、ＡＣＳに対する負荷を削減するアラーム管理をサポートする遠隔管理システムを提供することが目的である。さらに、リアルタイムのアラーム管理を可能にする遠隔管理システムを提供することが目的である。
【課題を解決するための手段】
【００２０】
本発明によれば、上で定義した目的は、請求項１によって定義される、遠隔管理プロトコルにより互いとインタフェースをとる顧客宅内装置（ＣＰＥ）と遠隔管理サーバ（ＡＣＳ）との間のアラーム通知のための方法によって実現され、この方法は、
−  顧客宅内装置（ＣＰＥ）内でアラーム状態を検出するステップと、
−  遠隔管理プロトコルを介して顧客宅内装置（ＣＰＥ）から遠隔管理サーバ（ＡＣＳ）に明示的アラーム通知を転送するステップと、
−  前記遠隔管理サーバ（ＡＣＳ）におけるアラーム基準の事前検証なしで、遠隔管理サーバ（ＡＣＳ）によって明示的アラーム通知に応答するステップとを含む。
【００２１】
実際、パラメータ値変更通知を用いるのではなく、アラーム基準に合致するかどうか検出することが可能なＣＰＥ装置が、ＡＣＳに明示的アラーム通知を送信することができる。このような明示的アラーム通知はたとえば、ＴＲ−０６９インフォームＲＰＣにおける新規「アラーム」イベントでもよく、新規「アラーム」ＲＰＣでもよい。本発明は、アラーム状態が満たされるかどうか判定するための、ＡＣＳによって実施される操作を簡素化する。というのは、アラーム通知を受信すると、ＡＣＳでは、新たなパラメータ値と閾値レベルとの比較も、他の処理も必要とされないからである。本発明はまた、すべてのパラメータ値変化がＡＣＳに報告される必要はないので、ＣＰＥとＡＣＳとの間のインタフェースに対する負荷を削減する。要するに、本発明は、遠隔管理システムにおけるアラーム管理のスケーラビリティを増大させる。
【００２２】
専用アラームＲＰＣまたは専用アラームコマンドにより明示的アラーム通知が実装されるケースでは、このようなＲＰＣは、既存のＴＲ−０６９セッション中にいつでも送信することができ、事業者のリアルタイム要件を満たすのを助ける。ＴＲ−０６９インフォームＲＰＣ中の新たなアラームイベントにより明示的アラーム通知が実装されるケースでは、本発明は、「Ｍｅｔｈｏｄｓ  ｆｏｒ  Ａｕｔｏｍａｔｉｃａｌｌｙ  Ｃｏｎｆｉｇｕｒｉｎｇ  Ｄｅｖｉｃｅｓ  ｉｎ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｎｅｔｗｏｒｋｓ  ａｎｄ  Ｄｅｖｉｃｅｓ  ｆｏｒ  Ｕｓｅ  ｗｉｔｈ  Ｓｕｃｈ  Ｍｅｔｈｏｄｓ」という名称の欧州特許出願第０８２９０３３３．７号に記載されている技法で補えばよい。この中では、単一ＴＲ−０６９セッション中に複数のインフォームＲＰＣが送信され得るように、ＴＲ−０６９プロトコルを拡張／修正することが提案されている。このように、リアルタイムの制約も満たすことができよう。
【００２３】
本発明はさらに、本発明による方法における使用に両方とも適合された、請求項６によって定義される遠隔管理サーバ（ＡＣＳ）および請求項７によって定義される顧客宅内装置（ＣＰＥ）に関することに注目されたい。
【００２４】
任意選択で、請求項２によって定義されるように、本発明による方法における遠隔管理プロトコルは、ＴＲ−０６９ＣＰＥ  ＷＡＮ管理プロトコルである。
【００２５】
本特許出願の導入部において既に言及したように、ＤＳＬフォーラムは、その技術報告ＴＲ−０６９において、遠隔管理のためのプロトコル、すなわち階層状に構築された形でのパラメータの命名法、およびこうしたパラメータを、一連のメッセージ、いわゆるリモートプロシージャコール（ＲＰＣ）により、ネットワーク内の離れた場所から安全に読み込む／書き込むやり方を定義済みである。明らかに、ＣＰＥにおけるアラーム状態の検出、およびＡＣＳまたは遠隔管理サーバへの明示的アラーム通知による、スケーラブルなアラーム管理機構のサポートは、ある特定の既存または将来の遠隔管理プロトコルに限定されない。本発明とともに現在または将来のバージョンが使われ得る変形管理プロトコルはたとえば、移動顧客装置のためのＯＭＡ−ＤＭ  Ｏｐｅｎ  Ｍｏｂｉｌｅ  Ａｌｌｉａｎｃｅ  Ｄｅｖｉｃｅ  ＭａｎａｇｅｍｅｎｔプロトコルやＳＮＭＰ（簡易ネットワーク管理プロトコル）である。
【００２６】
さらに任意選択で、本発明による方法における明示的アラーム通知は、請求項３によって定義されるように、専用アラームリモートプロシージャコールからなり得る。
【００２７】
実際、ＣＰＥがアラーム状態を検出済みであるパラメータのみ、すなわち値が変化しているパラメータのサブセットのみを含む新たな専用メッセージまたはＲＰＣが、明示的アラーム通知として作用し得る。このような新たな専用アラームＲＰＣは、たとえばＴＲ−０６９仕様の将来のバージョンで標準化される可能性があり、あるいは固有アラームＲＰＣが用いられ得る。ただし、このような固有ＲＰＣは、異なるベンダ製のＡＣＳには知られていないので、このようなＡＣＳによって解釈することができない。
【００２８】
あるいは、請求項４によって示されるように、本発明による方法における明示的アラーム通知は、ＴＲ−０６９インフォームリモートプロシージャコールに含まれるアラームイベントからなり得る。
【００２９】
したがって、新たな専用ＲＰＣではなく、新たなアラームイベントをもつＴＲ−０６９インフォームＲＰＣが、本発明の変形実装形態において明示的アラーム通知として作用し得る。それに対して、「アラーム」オブジェクトおよび対応するプレースホルダーが、ＣＰＥ内のオブジェクトモデル中で作成されることになる。このプレースホルダーはたとえば、ＣＰＥによって監視されるある特定のパラメータ用のブールパラメータ、たとえばアラーム状態が検出される（ビットが１にセットされる）か、それとも検出されない（ビットがゼロにセットされる）かを示す「ＬｏｗＢａｔｔｅｒｙＡｌａｒｍＲａｉｓｅｄ」のリストを含むはずである。この場合、ＡＣＳは、「アラーム発生」ビットがセットされているパラメータをリスト中で検索するだけでよく、いかなるローカルアラーム基準も評価する必要はない。本発明の本実装形態は、現在のＴＲ−０６９標準に準拠するとともに、いかなる新規ＲＰＣが標準化されることも、所有権が与えられることも求めないという点で有利である。既存の「インフォーム」ＲＰＣが使われる。
【００３０】
本発明による方法の、さらに任意選択の有利な態様は、前記専用アラームリモートプロシージャコールの転送および応答を、他のＴＲ−０６９リモートプロシージャコールよりも優先させることを含み得ることである。本任意選択の態様は、請求項５によって定義される。
【００３１】
明示的アラーム通知を行うのに、新たな専用アラームコマンドまたはＲＰＣが使われるケースでは、このＲＰＣは、緊急アラーム処置に対する、事業者からのリアルタイム要件を満たすのを助けるために、他のコマンドまたはＲＰＣよりも優先され得る。これはたとえば、ＡＣＳがアラームＲＰＣを他のＲＰＣよりも優先させ得る、ＡＣＳでの輻輳というケースにおいて有益であり得る。これが有益であり得る別の例は、ＣＰＥとＡＣＳとの間の、ネットワークにおける輻輳というケースである。このネットワークセグメント内の移送ノードは、アラームＲＰＣを優先させ、他のＲＰＣをより低い優先度で扱うように構成され得る。
【図面の簡単な説明】
【００３２】
【図１】本発明の実施形態による明示的アラーム通知をサポートするＣＰＥ装置におけるデータモデルを示す図である。
【発明を実施するための形態】
【００３３】
第１の例示的実施形態において、低バッテリアラーム管理の例を再度検討する。これに関して、ＣＰＥのＴＲ−０６９データモデルが、ＣＰＥ装置のバッテリのレベルを示すＢａｔｔｅｒｙＬｅｖｅｌパラメータを含むと再度仮定される。ＴＲ−０６９データモデルでは、このパラメータは、たとえば以下のように命名され得る：
ｄｅｖｉｃｅ．＊．Ｂａｔｔｅｒｙ．｛ｉ｝．ＢａｔｔｅｒｙＬｅｖｅｌ
ここで、「ｄｅｖｉｃｅ」は、ＴＲ−０６９ツリーのルートオブジェクトであり、「＊」は、子ＴＲ−０６９オブジェクト用のワイルドカードであり、「｛ｉ｝」は、ＴＲ−０６９データモデルにいくつかのＢａｔｔｅｒｙオブジェクトが存在し得ることを示す。
【００３４】
初期バッテリレベルは１００％であり、ＣＰＥ装置は電源に接続されておらず、その結果、バッテリレベルが時間とともに低下するとさらに再度仮定される。ＣＰＥ装置は、バッテリレベルの変化を５％の増分／減分で検出可能であることも仮定される。
【００３５】
本発明によれば、Ｂａｔｔｅｒｙオブジェクトは、「ｄｅｖｉｃｅ．＊．Ｂａｔｔｅｒｙ．｛ｉ｝．ＢａｔｔｅｒｙＬｅｖｅｌ」パラメータに加えて、パラメータ「ｄｅｖｉｃｅ．＊．Ｂａｔｔｅｒｙ．｛ｉ｝．ＡｌａｒｍＲａｉｓｅｄ」を含むことになる。このパラメータ「ｄｅｖｉｃｅ．＊．Ｂａｔｔｅｒｙ．｛ｉ｝．ＡｌａｒｍＲａｉｓｅｄ」はたとえば、バッテリレベルが２０％以下になったことをＣＰＥが検出したときに値が１（１または「真」）にセットされ、バッテリレベルが２０％を超えている限り値が０（ゼロまたは「偽」）にセットされるブーリアンパラメータである。「ｄｅｖｉｃｅ．＊．Ｂａｔｔｅｒｙ．｛ｉ｝．ＢａｔｔｅｒｙＬｅｖｅｌ」パラメータは、能動的通知用にはそれ以上マーキングされない。そうではなく、「ｄｅｖｉｃｅ．＊．Ｂａｔｔｅｒｙ．｛ｉ｝．ＡｌａｒｍＲａｉｓｅｄ」は、ＡＣＳによる能動的通知用にマーキングされる。
【００３６】
ＣＰＥは、低バッテリ状態を検出することができると想定される。バッテリレベルが２０％以下になると、ＣＰＥは、「ｄｅｖｉｃｅ．＊．Ｂａｔｔｅｒｙ．｛ｉ｝．ＡｌａｒｍＲａｉｓｅｄ」パラメータを「真」にセットし、ＡＣＳに明示的アラーム通知を送信する。第１の実装形態において、ＣＰＥは、「アラーム」イベントを含むインフォームＲＰＣを送信する。このインフォームＲＰＣは、既存のＴＲ−０６９セッションにおける追加インフォームＲＰＣでもよく、ＴＲ−０６９セッションごとにただ１つのインフォームＲＰＣを送信することができるケースでは、次のＴＲ−０６９セッションのインフォームＲＰＣでもよい。第２の実装形態において、ＣＰＥは、ＡＣＳに専用「アラーム」ＲＰＣを送信する。両方の実装形態において、ＡＣＳは、単一の明示的アラーム通知を受け取り、報告されたパラメータ値を、ローカルに実装されたアラーム基準に突き合わせてそれ以上検証しなくてよい。
【００３７】
図１は、本発明の第２の実施形態におけるＣＰＥのデータモデルを示す。分岐１または１０１中の全パラメータ、すなわち１１１、１１２．．．１１３は、アラームを示し、この分岐中のパラメータの量が多い、たとえばｉ＝１００であると仮定される。図１には示さないが、ＡＣＳに対して、ローカルアラーム基準が定義される。このような基準の例は、以下の通りである：
値変化インフォームＲＰＣに「ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈ１．Ａ１」が存在する場合、「アラームＡ１」が発せられ、
値変化インフォームＲＰＣに「ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈ１．Ａ２」が存在し、このパラメータの新たな値がｘ％より小さい場合、「アラームＡ２」が発せられ、
．．．
値変化インフォームＲＰＣに「ｄｅｖｉｃｅ．＊．Ｂｒａｎｃｈ１．Ａｉ」が存在する場合、「アラームＡｉ」が発せられる。
【００３８】
いくつかの分岐、すなわち分岐１または１０１、分岐２または１０２、．．．、分岐ｙまたは１０３が存在する。ｙは大きい、たとえばｙ＝１０であると仮定される。
【００３９】
本発明によれば、図１にそのデータモデルが描かれているＣＰＥは、ＣＰＥがアラームを検出済みであるパラメータ、すなわち、分岐１．．．分岐ｙというそれぞれの分岐におけるパラメータのサブセットのみを含む専用「アラーム」ＲＰＣをＡＣＳに報告しなければならない。サブセットである理由は、全パラメータの値が変化していても、全部のパラメータがアラームを示すわけではないからである。変形実装形態において、図１で示すＣＰＥは、「アラーム」イベントを含むインフォームＲＰＣを送信することになる。ＡＣＳは次いで、「アラーム発生」ビットがセットされているパラメータをリスト中で検索するだけでよく、いかなるローカルアラーム基準も評価する必要はない。
【００４０】
具体的な実施形態を参照して本発明を解説したが、本発明は、上記の例示的実施形態の詳細に限定されず、本発明は、その範囲から逸脱することなく、様々な変更および修正とともに実施され得ることが当業者には明らかであろう。本実施形態はしたがって、すべての点において、例示であって限定ではないと見なされるべきであり、上記の説明ではなく添付の請求項によって示される本発明の範囲、および請求項と等価な意味および範囲内であるすべての変更はしたがって、その中に包含されることが意図される。言い換えると、基本的な根本原理の範囲内であるとともに、本質的属性が本特許出願において権利請求されるあらゆる修正形態、変形形態または等価物をカバーすることが想定される。「ｃｏｍｐｒｉｓｉｎｇ」または「ｃｏｍｐｒｉｓｅ」という単語は、他の要素またはステップを排除するものではなく、「ａ」または「ａｎ」という単語は、複数を排除するものではなく、コンピュータシステム、プロセッサ、または別の統合型ユニットなどの単一要素が、請求項において引用されるいくつかの手段の機能を遂行し得ることが、本特許出願の読者にはさらに理解されよう。請求項におけるどの参照符号も、関係するそれぞれの請求項を限定するものと想定されるべきではない。「第１」、「第２」、「第３」、「ａ」、「ｂ」、「ｃ」などの用語は、説明または請求項において使われる場合、同様の要素またはステップを区別するために採り入れられているのであって、必ずしも発生順または時系列順を記述しているわけではない。同様に、「ｔｏｐ」、「ｂｏｔｔｏｍ」、「ｏｖｅｒ」、「ｕｎｄｅｒ」などの用語は、記述目的で採り入れられているのであって、必ずしも相対的な位置を示すわけではない。このように使われている用語は、適切な状況の下で入替え可能であり、本発明の実施形態は、本発明によれば、他の順序で、または上で記述し、または説明したものとは異なる方向性で動作することが可能であることを理解されたい。
【図１】
2012517724.tif 000003
【国際調査報告】
2012517724.tif 000004
2012517724.tif 000005
2012517724.tif 000006