JP5306523B2 - 通信端末デバイスを管理するための方法、通信端末、及び通信システム - Google Patents

Description

本発明は、通信技術、特に、通信端末デバイスを管理するための方法、通信端末、及び通信システムに関する。

現在、中国における携帯電話ユーザの数は２億人に達しようとしている。ユーザの要求がますます多様化かつ個別化するにつれて、中国の遠隔通信の革新は一層高度化し、かつ固定電話及び携帯電話が再構築及び改良されるにつれ、サービス提供者は、ＢＣＡＳＴ（Broadcast）サービス、ＶｏＩＰ（Voice over Internet Protocol）サービス、ＰｏＣ（Push-to-Talk Over Cellular）サービスなどといった、より多岐にわたるサービスをユーザへ提供し始めた。

ＶｏＩＰは、主にＩＰ（Internet Protocol）電話を基盤として実現され、かつ対応する付加価値サービスを提供する技術である。ＶｏＩＰを用いることで、バーチャルフォン、インターネットコール管理、テレビ会議、及びさまざま情報の格納及び送信といった、音声、ＦＡＸ、映像、及びデータを含むサービス情報の転送がＩＰネットワーク上で安価に実現できる。

移動端末（Mobile Terminal，ＭＴ）に適したＶｏＩＰシステムが、ＰｏＣサービスによって定義される。ワイヤレスデータネットワークのパケット交換機能を使用することで、ＰｏＣサービスは立地の制限を受けない。

ＯＭＡ（Open Mobile Alliance）は、ＰｏＣサービスの規格化に向けて作業を進めている。ＯＭＡのＰｏＣソリューションは、インターネット技術タスクフォース（Internet Engineering Task Force，ＩＥＴＦ）によって定義されたセッション確立プロトコル（Session Initiation Protocol，ＳＩＰ）及びリアルタイム転送プロトコル（RealTime Transfer Protocol，ＲＴＰ）に基づくものである。

通信技術の発展と共に、ネットワークの規模はますます肥大化し、かつその構造もますます複雑化している。サービス品質（Quality of Service，ＱｏＳ）の向上及び運用コストの削減のためには、効率的なネットワーク管理システムを構築する必要がある。結果として、遠隔通信管理ネットワーク（Telecommunication Management Network，ＴＭＮ）が時勢の要望として現れた。

ＴＭＮは、遠隔通信リソース、ネットワーク稼働率、サービス、及び管理を計画し、監視し、設計し、かつ制御するための方針及び方法を提供するとともに、オペレータ／マネージャ及び端末ユーザのために機能する遠隔通信ネットワークＯＡＭ（Operation Administration Maintenance）を備えたシステムを提供する。遠隔通信ネットワーク全体にわたって管理ネットワークを利用することによって、ネットワークリソースの全面的及び効率的な監視及び管理が実現できるだけでなく、複数の管理範囲にわたるサービスを開始できるように、ネットワークシステムを相互接続することもできる。

ＴＭＮの実現は、２つの部分に分けられる。第１部分では、複数のサブネットワーク間でインタフェース通信が実現できるように、ネットワーク層より下位の遠隔通信リソースを監視及び制御するためのシステムが構築される。故に、ローカルネットワーク、アクセスネットワーク、及びＳＤＨ（Synchronous Digital Hierarchy）の透過的な制御及び監視が実現する。第２部分では、例えば、ユーザ管理、ネットワーク設備管理、労働力管理、請求、支払、及び会計管理、ＱｏＳ及びネットワークパフォーマンス管理、トラフィック測定及び解析管理、保守管理、セキュリティ管理、ログ管理などの２１世紀へ向けた管理サービスが開発されるように、遠隔通信ネットワークの意志決定サポートシステムがネットワーク層上に構築される。

ＴＭＮシステム構成情報モデルの大部分は、階層構造ツリーを用いて、構成モデルの階層構造を記述する。それは、構成情報モデルツリーと称される。

いわゆる情報モデルにおいて、ネットワークリソースは、管理の観点から運用される必要のある多数の小さな構成単位に分割される。ついで、これらの小さな構成単位は、複数の管理対象（Management Object，ＭＯ）を生成するために抽象化される。手短に言えば、情報モデルとは、ネットワーク管理システムによって運用されるリソースから抽象化されたＭＯの集合である。リソース管理は、これらのリソース抽象化エンティティ、すなわちＭＯを処理することによって間接的に実行される。ＭＯ交換情報を用いることによって管理動作を完遂するために、命令を発する責任があるマネージャと、命令を実行する責任があるエージェントとが必要とされる。命令を完遂するために、エージェントは、その名称、属性、従属関係などといった処理されるべき対象を知ってなくてはならない。このような情報のすべては、ＭＩＢ（Manager Information Base）から得る。ＭＩＢ中の情報は、規則に従って組織的に構成されている。情報モデルの方法を用いることによって、ＭＩＢは、ツリー構造が形成されるように、従属関係及び導出の規則に従って、トップからボトムへ抽象化されたＭＯを論理的に配置する。言い換えれば、検索を容易にする上記の情報モデルツリーが構築される。

ＯＭＡ ＤＭ（Device Management）規格において、端末を管理、診断、及び保守するためのＴＭＮ技術が計画され、かつサーバは、ＤＭ管理ツリーを介して、端末に対するファームウェアアップデート、アプリケーションダウンロード、診断及び監視、バックアップ及びリストアなどといった管理動作を実行できる。端末は、携帯電話、ＰＤＡ（Personal Digital Assistant）、ノートブックコンピュータ、組込みデバイス、オンボードシステムなどである。

現在のＯＭＡ ＤＭ規格は、ソフトウェアコンポーネント管理技術、すなわち、端末上のソフトウェアコンポーネントを管理するためのＤＭサーバに対するメカニズムを提供する。

ソフトウェアコンポーネントは、実行可能アプリケーション、ダイナミックリンクライブラリ、ユーザインタフェース（User Interface，ＵＩ）などである。管理動作は、端末パラメータ設定、ファームウェアアップデート、エラー診断、バックアップ又はリストアのほかにも、ソフトウェアコンポーネントの問い合わせ、インストール、アップデート、アクティベーション、又は削除であってよい。

ＤＭ規格によって表された全体の構成が、図１に示される。端末１０上のＤＭエージェント１１は、ＤＭサーバ２０によって発せられた管理命令を解釈及び実行するように構成される。端末に格納されたＤＭ管理ツリー１２は、ＤＭサーバ２０に対するインタフェースと見なすことができ、ＤＭプロトコルを介して端末１０を管理する。ＤＭ管理ツリー１２は、いくつかの基本的なＭＯを含む。ＤＭサーバ２０は、ＭＯに関する動作を介して端末１０のリソースを制御する。例えば、ソフトウェアコンポーネントに関する管理は、端末１０上のソフトウェアコンポーネント管理オブジェクト（Software Component Management Object，ＳＣｏＭＯ）を追加、削除、及び修正することによって実行される。

ＤＭ規格においてソフトウェアコンポーネントを管理するための方法が、図２に示される。

ステップ２０１において、ＤＭサーバは、端末に、インストールされたソフトウェアコンポーネントのインベントリの問い合わせを行う。

ステップ２０２において、端末は、ユーザに認証を要求する。

ステップ２０３において、ユーザは、認証を確認する。

ステップ２０４において、端末は、ソフトウェアコンポーネントインベントリをＤＭサーバへ送信する。

ステップ２０５において、ＤＭサーバは、ソフトウェアコンポーネントの端末へのダウンロード及びインストール動作を開始する。

ステップ２０６において、端末は、ＤＭサーバに確認メッセージを返す。

国際公開第２００６／００６８０３号 特開２００５−２４４４０３号公報 国際公開第２００５／００４３９５号

Software Componet Management Object, Open Mobile Alliance Ltd., 2005年4月4日, Draft Version 1.0, p.4-25, URL, http://member.openmobilealliance.org/ftp/Public_documents/DM/SCOMO/2005/OMA-DM-SCOMO-2005-0002R01-Software_Component_Management-.zip

研究の間に、発明者は、上記のソリューションが以下の短所を有することに気づいた。すなわち、ソフトウェアコンポーネントの追加、削除、及び修正といった静的状態しか制御できない。四六時中ネットワーク側から配信されるサービスを効果的に受信するために、端末は、サービス受信部などのそのサービス機能を稼動状態に保たなければならない。受信するサービスがない場合、稼動状態にあるサービス機能は、対応するハードウェアリソースが電気エネルギーを不要に消費する原因となる。故に、通信端末の電力消費量が大きくなり、それと同時に、端末の中央演算ユニット（Central Processing Unit，ＣＰＵ）などのリソースが占有される。結果的に、無駄が生じる。

本発明の一実施形態は、通信端末デバイスを管理するための方法を提供する。上記方法は、指定された機能の動作状態に関する制御指示から成るデバイス管理命令を端末へ送信する段階と、制御指示に従って、指定された機能の動作状態に関する動作を端末で実行する段階とを有する。

さらに、本発明の一実施形態は、対応する通信端末を提供する。上記端末は、機能を提供するように構成された機能モジュールと、指定された機能の動作状態に関する制御指示から成るデバイス管理命令を受信及び分解（resolve）するように構成されたデバイス管理エージェントと、制御指示に従って、指定された機能の動作状態に関する動作を実行するように構成されたデバイス管理サービス機能クライアントとを具備する。

さらに、本発明の一実施形態は、通信システムを提供する。上記システムは、通信端末及びＤＭサーバを具備する。デバイス管理サーバは、指定された機能の稼動状態に関する制御指示から成るデバイス管理命令を通信端末へ送信するように構成される。通信端末は、制御指示に従って、指定された機能の動作状態に関する動作を実行するように構成される。

本発明の技術的ソリューションでは、例えば、アプリケーションの開始、停止又は中断、及び再開の制御などのアプリケーションの動作状態を遠隔制御する機能を有することができるように、ＤＭ技術が強化されるということが、比較によって明らかとなった。

サービスが正常に動作することを保証できるように、サービス実行より先に、サービスに関連するアプリケーションがあらかじめ端末上でＤＭサーバによって遠隔開始される。実行の必要があるサービスに間に合うように、関連するアプリケーションが起動されるので、アプリケーションが端末上で四六時中稼動する必要は無い。従って、端末の貴重な電気エネルギーを節約できる。

また、サービスが実行されている場合、端末上で稼動しているサービスに関連するアプリケーションは、アプリケーションが稼動する必要の無いときに、アプリケーションによって占有される端末のＣＰＵリソースを解放し、それと同時に、端末の電気エネルギーを節約できるように、ＤＭサーバによって遠隔中断される。アプリケーションが再び稼動する必要のあるとき、ＣＰＵを除く、アプリケーションによって占有されたリソースは解放されていないので、アプリケーションの稼動状態は、ＤＭサーバを介して遠隔再開指示を端末へ送信することによって迅速に再開される。結果的に、ユーザ体験が向上する。

さらにまた、関連するアプリケーションが、サービスが実行されたときに、直ちに開始されるか、又は関連するサービス機能が、あらかじめ構築されたサービス配信プランに従って、所定のサービス配信時間に開始される。これら２つのモードを臨機応変に用いることによって、必要とされる異なるサービスがより良く手配できる。

従来技術におけるＯＭＡ ＤＭ規格に記載された全体の構成を示す概略図である。 従来技術におけるＯＭＡ ＤＭ規格でのソフトウェアコンポーネント管理方法のフローチャートである。 サービス機能が本発明に従って開始又は停止される場合の状態遷移を示す概略図である。 本発明の第１実施形態に従って通信端末機能を開始又は停止するための方法のフローチャートである。 本発明の第２実施形態に従って通信端末機能を開始又は停止するための方法のフローチャートである。 本発明の第３実施形態に従って通信端末機能を開始又は停止するための方法のフローチャートである。 本発明の一実施形態による通信端末の構成図である。 本発明の第４実施形態に従って通信端末とサーバ側と間で通信を行うためのシステムの構成図である。 本発明の第４実施形態によるサービス機能管理システムの構成図である。 本発明の第４実施形態によるＤＭツリーの部分的な構成図である。 本発明の第４実施形態に従ってスケジューリング許可部を介して対応する機能を呼び出すことによって機能を開始又は停止するためのシステムの構成図である。 本発明の第５実施形態に従って通信端末機能を中断及び再開するための方法のフローチャートである。 本発明の第５実施形態による機能の中断と再開との間の状態遷移の概略図である。 本発明の第６実施形態に従って機能を中断又は再開するためのシステムの構成図である。 本発明の第６実施形態によるＤＭツリーの部分的な構成図である。 本発明の第６実施形態によるＤＭツリーの部分的な構成図である。 本発明の第６実施形態によるＤＭツリーの部分的な構成図である。

本発明の目的、技術的解決策、及び利点をより明白にするために、これより、本発明を図面と併せてさらに詳細に記載する。

本発明において、サービス提供者は、指定された機能の動作状態に関する制御指示を含むメッセージを端末へ送信する。端末は、メッセージに含まれた制御指示に従って、指定された機能に対応する制御動作を実行する。制御動作は、開始（start）、停止（stop）、中断（suspend）、再開（resume）などの動作を含む。

本明細書中のいわゆる機能は、一般的な表現であり、端末の実行環境で実行可能なソフトウェア、プログラムの一部、プロシージャ、（ＸＭＬのような）スクリプト言語の一部などであってよい。例えば、機能は、診断処理、トラップ機能、又はスケジューリングコンポーネントなどであってもよい。

本発明の実施形態における機能の状態遷移が、図３に示される。それは、停止状態及び稼動状態の２つの状態を有する。機能が停止状態にある場合のみ、機能に対する開始動作を実行でき、かつ機能が稼動状態にある場合のみ、機能に対する停止動作を実行できる。

さらにまた、サービス提供者は、ＤＭサーバを介して、指定された機能を中断又は再開するための指示を含むメッセージを端末へ送信する。端末は、メッセージに含まれた指示に従って、指定された機能を中断又は再開する。機能が稼動状態にある場合のみ、中断動作を実行できる。

本発明の第１実施形態に従って通信端末機能を開始又は停止するための方法が、図４に示される。ここで、現在の端末で開始される必要のある診断機能は停止状態にあると想定する。

ステップ４０１において、端末のためにサービスを実行する必要がある場合、まず、サービス提供者は、ＤＭサーバに問い合わせ要求を依頼する。例えば、ネットワーク側のサービスサーバは、端末上のサービス機能が開始されたかどうか、すなわち、機能が稼動状態にあるかどうかを問合せるように、ＤＭサーバに指示する。

特に、問い合わせの主な命令は、以下の通りである。
<Get>
<Item>
<Target>
<LocURI>./Diagnostic Function/StateValue(./BCAST client/state value)</LocURI>
</Target>
</Item>
</Get>

ステップ４０２において、ＤＭサーバは、デバイス管理命令を発行するとともに、端末に機能の現在状態を問い合わせる。ＤＭサーバ及び端末のＤＭエージェントは、標準ＯＭＡ ＤＭプロトコルを介して互いに情報をやりとりする。

ステップ４０３において、端末は以下の問い合わせ結果を返す。
<Results>
<Item>
<Source>
<LocURI>./Diagnostic Function/StateValue</LocURI>
</Source>
<Data>Stopped</Data>
</Item>
</Results>

ここで、取得した結果は機能が停止状態にあることだと想定する。

ステップ４０４において、ＤＭサーバは、サービスサーバに問い合わせ結果を返す。

ステップ４０５において、問い合わせ結果に従って、開始する必要のあるサービス機能が開始されていない場合、サービスサーバは、ＤＭサーバへメッセージを送信するとともに、メッセージ中の機能を開始するための動作指示を配信する。

ステップ４０６において、ＤＭサーバは、端末のＤＭエージェントへメッセージを転送するとともに、端末上の診断機能を開始するために、以下の管理命令を発行する。
<Exec>
<item>
<Target>
<LocURI>./Diagnostic Function/Operations/Start</LocURI>
</Target>
</Item>
</Exec>

ステップ４０７において、ＤＭ命令を受信した後、ＤＭエージェントは、ＤＭ命令のソースが妥当なものであるかどうかを判断する。妥当である場合、ＤＭエージェントは、メッセージを解釈するとともに、メッセージに含まれた動作指示を取得する。そうでない場合、ＤＭエージェントは、ＤＭ命令を棄却する。

セキュリティ、プライバシーなどの問題に関しては、ＤＭエージェントは、動作指示に従って、端末のＵＩを介してユーザへ問い合わせメッセージをさらに送信するとともに、サービスを受け入れるかどうかを判断するように、ユーザに要求する。

ユーザがサービスについて省略時（default）動作を設定していた場合、ＤＭエージェントは、ユーザからの確認メッセージを取得する過程を実行する必要は無い。その代わりに、ＤＭエージェントは、設定された省略時動作に従って、ＤＭサーバによって直接発行された命令を処理し、ついでステップ４０９へ進む。

ステップ４０８において、ユーザは、ＵＩを介してサービスを確認する。ユーザがサービスの受け入れを望まない場合、又はサービスを受け入れることがユーザにとって都合が悪い場合、ユーザは、取り消し動作を実行する。ユーザがサービスを受け入れる場合、承認動作が実行される。ユーザが取り消し動作の実行も承認動作の実行も行わない場合、省略時処理モードが設定されてよい。例えば、ユーザがサービスを棄却するとみなされる。

例えば、ユーザがサービスを受け入れることを示す確認メッセージ（受理又は棄却）は、端末のＵＩを介してＤＭエージェントへ返される。

上記のステップ４０７及びステップ４０８は任意に選択できる。ユーザは、端末でのユーザ確認をトリガするためのポリシをあらかじめ設定できる。例えば、サーバが機能を制御するための命令を初めて送信したときには、ユーザの確認を必要とするが、以後、サーバは機能を直接制御するための命令を送信できる。

ステップ４０９において、端末は、ＤＭサーバによって送信された命令を実行するとともに、ユーザ承認に基づいたサービスの機能を開始する。ＤＭツリーは、端末に格納されてよい。ＤＭツリーは、機能を開始するノードと、機能を停止するノードとを有する。２つのノードがどちらも実行可能ノードである場合、ＤＭエージェントは、ＤＭサービス機能クライアントの許可モジュールを介して、指定された機能の対応する開始又は停止動作を実行するために、ＤＭサーバによって送信された命令に含まれた制御指示に従って、対応する実行可能ノードを直接トリガする。２つのノードがどちらもＤＭツリー中の指示ノードである場合、ＤＭエージェントは、ＤＭサーバによって送信された命令中の指示に従って、対応する指示ノードの値を修正し、かつ端末は、指示ノードの値の変化を監視することによって、指定された機能の対応する開始又は停止動作を実行する。

対応する開始（又は停止）動作が実行された後、動作結果がＤＭサーバに報告される。
<Alert>
<CmdID>2</CmdID>
<Data>1226</Data> <-- Generic Alert -->
<Item>
<Source><LocURI>./Diagnostic Function/Operations/Start
</LocURI>
</Source>
<Meta>
<Type>org.openmobilealliance.Diagnosticfunction.start</Type>
<Format>null</Format>
</Meta>
<Data>200</Data> <-- OK! -->(command execution successful)
</Item>
</Alert>

ユーザが判断に従ってサービスを棄却した場合、ＤＭサーバは、サービス要求を終了するために通知を受ける。

ステップ４１０において、ＤＭサーバは、動作結果をサービスサーバに通知する。

ステップ４１１において、受信した動作結果が、端末サービスが開始されていることを示す場合、サービスサーバは、端末との接続を確立するとともに、端末へのサービスの配信又はサービスの管理を開始する。返された動作結果が、端末サービスが停止中であることを示す場合、端末との接続は切断され、かつ端末に対するサービスの配信又は管理動作は停止される。

上記の方法に従って、関連する機能は、実行する必要のあるサービスより先に開始される。機能はもはや端末上で四六時中稼動する必要はなく、端末の貴重な電気エネルギーを節約できる。さらに、遠隔で開始又は停止される機能は診断機能であってよく、それによって、ネットワーク側は、他の機能は通常のものであるのかどうか、指定された機能の状態などといった情報を取得できる。故に、端末の稼動状態が、臨機応変に監視できる。

本発明の第２実施形態に従って通信端末機能を開始又は停止するための方法が、図５に示される。ここで、現在の端末で開始する必要のある機能は稼動状態にあり、かつネットワーク側がサービスサーバを介してサービスを制御すると想定する。この実施形態と先の実施形態との間の主な差異は、サービスサーバが制御指示を送信する前に、端末中の指定された機能の動作状態が問い合わせを受けないことにある。代わりに、制御指示は、現在のサービスによって問い合わせられたものとして直接送信され、かつ端末は、指定された機能の現在の動作状態に従って、制御指示の実行又は無視を決定する。この実施形態においては、一例として、ＤＭサーバが開始指示を送信する場合に行われる。他の指示も同様である。

ステップ５０１において、サービスサーバは、サービスに必要な機能の開始指示をＤＭサーバへ送信する。

ステップ５０２からステップ５０４は、ステップ４０６からステップ４０８とそれぞれ同一である。

ステップ５０５において、ユーザ承認を得た後、ＤＭエージェントは、端末中の指定された機能の状態に従って、開始指示を実行又は無視する。例えば、指定された機能が稼動状態にある場合、ＤＭ命令中の指定された機能を開始するための指示は無視される。

端末中の指定された機能が非稼動状態にある場合、ＤＭ命令中の指定された機能を開始するための指示は実行される。

ついで、動作結果、すなわち、現在、機能は稼動状態にあるということが、ＤＭサーバへ報告される。さらに、ユーザ確認メッセージが棄却である場合、ＤＭサーバは、サービス要求を終了させるために通知を受ける。

ステップ５０６及びステップ５０７は、ステップ４１０及びステップ４１１とそれぞれ同一であるので、ここで繰り返して記載はしない。

本発明の第３実施形態に従って通信端末機能を開始又は停止するための方法が図６に示される。この実施形態において、現在の端末で開始する必要のある機能は停止状態にあると想定する。

ステップ６０１において、サービスサーバは、サービス配信プラン又はサービス管理プランを作成する。プランは、時刻に基づいている。例えば、ＢＣＡＳＴサーバは、タイムテーブルに従って、毎日１０：００〜１１：００と１６：００〜１７：００とに、端末にサービスをブロードキャストするとともに、タイムテーブル中の時間枠に従って、ＢＣＡＳＴクライアントを開始するように、端末に指示を行う。また、プランは、端末上のイベントに基づいている。例えば、端末は、機能の自動更新が完了したときに機能を自動的に停止するように指示される。

ついで、サービスサーバは、ＤＭサーバのウェブサービスインタフェース（Web Service Interface，ＷＳＩ）を介してＤＭサーバへサービス配信プランを提示する。サービス配信プランは、機能ＩＤ、時間又は条件などを含む。

ステップ６０２において、ＤＭサーバは、サービスサーバによって提示されたサービス配信プランに従って、スケジューリングを生成する。スケジューリングは、トリガ条件及び所定の動作を含む。例えば、トリガ条件は、１０：００ ＡＭであり、かつ所定の動作は、クライアント上のＢＣＡＳＴ機能を開始することである。

ついで、ＤＭサーバは、標準ＯＭＡ ＤＭプロトコルを介して端末のＤＭエージェントへ生成されたスケジューリングを送信する。

ステップ６０３において、ＤＭエージェントは、端末のＵＩを介して、スケジューリングを導入するのかどうかの判断をユーザに要求する。

ユーザがサービスに対して省略時動作を設定する場合、ＤＭエージェントは、ユーザ確認を必要とせずに、省略時動作に従ってスケジューリングを直接処理し、かつステップ６０６へ進む。

ステップ６０４において、ユーザは、ＵＩを介してスケジューリングを確認する。ユーザがサービスの受け入れを望まない場合、又はサービスの受け入れがユーザにとって都合が悪い場合、ユーザは、取り消し動作を実行する。ユーザがサービスを受け入れる場合、ユーザは、承認動作を実行する。ユーザが取り消し動作の実行も承認動作の実行も行わない場合、省略時処理が実行されてよい。例えば、ユーザがサービスを棄却するとみなされる。

例えば、ユーザがサービスを受け入れることを示す確認メッセージ（受理又は棄却）は、端末のＵＩを介してＤＭエージェントへ返される。

さらにまた、ユーザは、ＵＩを介してスケジューリングを修正できる。例えば、ユーザは、ブロードキャストが１０：００〜１１：００の時間枠のみで受信されるように、タイムテーブルを修正できる。

ＤＭエージェントは、スケジューリングを導入するように端末に指示するとともに、ユーザの承認又は修正に従って、スケジューリングを実行する。ユーザ確認メッセージが導入棄却である場合、スケジューリングは取り消される。

ステップ６０５において、スケジューリングのトリガ条件に合致した場合、例えば、時刻が１０：００に達したか、又は機能更新が完了した場合に、ユーザは、スケジューリングに対応する機能の開始又は停止動作を実行するかどうか、例えば、ブロードキャストサービスの受信を開始するかどうかの確認を要求される。

しかしながら、また、省略時動作が設定されていれば、ユーザの確認を要求することなく、省略時動作が適宜に実行される。

ステップ６０６は、ステップ４０８と同一である。

ステップ６０７において、ＤＭエージェントは、ユーザ承認に基づくスケジューリング中の所定の動作を実行し、現在稼動状態にある機能を開始（又は、機能を停止、例えば、ＤＭエージェントが１１：００に停止動作を実行）し、かつ動作結果をＤＭサーバへ返す。

端末が開始（又は停止）動作を実行するときに、機能が稼動状態にある場合、ＤＭ命令中の開始（停止）指示は無視される。

ステップ６０８は、ステップ４１０と同一であるので、ここで繰り返して記載はしない。

ステップ６０９において、サービスサーバは、端末との接続を確立するとともに、返された動作結果が開始である場合に、サービス配信又はサービス管理を開始する。返された動作結果が停止である場合、端末との接続は切断され、かつ端末に対するサービス又は管理動作は停止される。

関連するサービス機能は、サービスが実行されたときに直ちに開始されてよく、又はあらかじめ構築されたサービス開始プランに従って、所定のサービス開始時刻に開始されてもよい。これら２つのモードを臨機応変に用いることによって、異なるサービスの要求により良く対処できる。

本発明の第４実施形態による通信端末の構成が図７に示される。通信端末は、１つ以上の機能モジュール３１と、ＤＭエージェント３２と、１つ以上のＤＭサービス機能クライアント３３とを具備する。機能モジュール３１は、さまざまなサービスを実行する機能を提供するように構成される。ＤＭエージェント３２は、ネットワーク側のＤＭサーバからデバイス管理命令を受信及び分解して、対応する制御指示を取得し、ついでＤＭツリーを動作させ、かつ維持するように構成される。ＤＭサービス機能クライアント３３は、ＤＭエージェント３２で取得した制御指示に従って、指定された機能の動作状態に関する対応する制御動作を実行するように構成される。

ＢＣＡＳＴサービス及びＰｏＣサービスの機能の一例として、通信端末３０、ＤＭサーバ４０、及びサービスサーバの間で通信を行うためのシステムの構成が図８に示される。ＢＣＡＳＴサービスの機能モジュールは、ＢＣＡＳＴクライアント３１１として構成され、ＰｏＣサービスの機能モジュールは、ＰｏＣクライアント３１２として構成され、かつサービスは、ＢＣＡＳＴプロトコル及びＰｏＣプロトコルをそれぞれ用いて、ＢＣＡＳＴサーバ５１及びＰｏＣサーバ５２によって配信される。ＤＭエージェント３２は、ＤＭサービス機能クライアント３３を介してサービスクライアントを管理する。特定のサービス機能に従って、ＤＭサービス機能クライアントは、アプリケーション管理クライアント、診断及び監視（Diagnostic and Monitoring，ＤｉａｇＭｏｎ）クライアント、スケジューリングクライアントなどであってよい。

図９は、ＤＭサービス機能クライアントが特にＤｉａｇＭｏｎクライアントであるサービス機能管理システムの構成を表す。

図９において、ＤＭエージェント３２は、ＤＭサーバ４０によって発行されたデバイス管理命令を解釈するとともに、その中の制御指示をＤｉａｇＭｏｎクライアント３３０へ提供する。

ＤｉａｇＭｏｎクライアント３３０は、主に以下のモジュールを具備する。

状態問い合わせモジュール３３０１。これは、端末上の機能の状態を問い合わせるためにＤＭサーバ４０をサポートするように構成される。

開始／停止許可モジュール３３０２。これは、ソフトウェアの開始及び停止をサポートするように構成される。端末は、ＤＭサーバ４０によって送信された命令を受信した後に、開始／停止許可モジュールを介して関連する実行可能ノードを制御することによって機能の開始及び停止を実現する。開始／停止許可モジュールは、ロジック機能モジュールであり、ＤＭサービス機能クライアントに、又はその他の位置にあってよい。

ＤＭサービス機能サーバ４は、主にＤＭサーバ４０を具備する。ＤＭサーバは、管理指示を端末へ送信するとともに、端末によって返されたメッセージを受信する。

サービスサーバ５とサーバ４とは、ＷＳＩインタフェースを介して互いに情報をやりとりする。

ユーザインタフェース３４は、ユーザに認証要求を送信するとともに、ＤｉａｇＭｏｎクライアント３３０が制御指示を実行したときに、ユーザから認証を受け取るように構成される。

また、ＤｉａｇＭｏｎクライアント３３０は、アプリケーション管理クライアント、スケジューリングクライアントなどといったその他のＤＭサービス機能クライアント３３１と情報をやりとりしてもよい。

ＤＭエージェントは、ＤＭツリーのノードを動作させることによって、ＤＭサービス機能クライアントへ制御指示を提供する。図９に対応して、ＤＭツリーは、機能を開始するノード及び機能を停止するノードを有する。これら２つのノードが実行可能ノードである場合、実行可能ノードは、ＤＭサーバによって送信されたＤＭ命令を介して、機能の開始又は停止動作を実行するために直接トリガされる。２つのノードが指示ノードである場合、ＤＭエージェントは、ＤＭ命令中の指示に従って、指示ノードの値を修正し、かつ端末は、指示ノードの値の変化を監視するために、図９の破線部で示すような状態監視モジュール３５を用いるとともに、指示ノードの値の変化に従って、対応する開始又は停止動作を実行するために、ＤＭサービス機能クライアントに通知を行う。ＤＭツリーの部分的な構成が図１０に示される。

<Interior Node>は、内部ノードを意味し、サービス機能ＭＯのルートノードである。ＭＯは、ＳｃｏＭＯ、ＤｉａｇＭｏｎ Ｍｏ、スケジューリングＭＯ又はアプリケーション管理ＭＯなどであってよい。

<x>は置換子（placeholder）であり、特定の情報と、導入された機能の関連する実行可能動作とが、このノード下に格納される。

便宜上、以下の記載においては、<Interior Node/x>は<./x>に置き換えられる。

ソフトウェアＩＤは、このノードに格納される。

このノードは、ソフトウェアの状態を表す。ノードの値は、以下のようになる。

このノードは、一連の実行可能ノードの親ノードである。

このノードは、実行可能ノードであり、機能又は処理を開始するように構成される。例えば、０は、初期状態又は動作の完了を表し、かつ１は、機能を開始する必要があることを表す。

このノードは、実行可能ノードであり、機能又は処理を停止するように構成される。例えば、０は、初期状態又は動作の完了を表し、かつ１は、機能又は処理を停止する必要があることを表す。

開始及び停止ノードは、Ｒｕｎノード、Ｅｘｉｔノードなどとも称される。特定の解釈又は実行が、端末のサービス機能モジュールによって成し遂げられる。

このノードは、実行可能ノードであり、機能又は処理を削除するように構成される。例えば、０は、初期状態又は動作の完了を表し、かつ１は、機能を取り去らなければならないことを表す。

このノードは、将来の拡張のための予備である。

上記の実施形態において、開始ノード及び停止ノードは各サービス機能ＭＯで定義されるが、機能の開始及び停止は、図１１に示されるように、スケジューリングモードでこれらのノードを呼び出すことによって実行することもできる。特に、以下の２つの実行モードがある。

モード１：通信端末は、端末機能を開始又は停止するための命令（指示）を含む所定のタスクを受信する。端末は、スケジューリングクライアント３３２を開始させるとともに、条件に合致したときに、ＤｉａｇＭｏｎクライアント３３０のような、対応するＤＭサービス機能クライアントを呼び出す。指定された機能を開始又は停止するために、機能を開始又は停止するように構成された実行可能ノードが実行される。しかしながら、他のＤＭサービス機能クライアント３３４が、特定の制御指示に従って呼び出されてもよい。

モード２：通信端末は、端末機能を開始又は停止するためのコード又は機能の一部を含む所定のタスクを受信する。端末は、スケジューリングクライアント３３２を開始させ、かつボトム−レイヤオペレーティングシステムは、条件に合致したときに、指定された機能を開始又は停止するために所定のタスク中のコード又は機能の一部を実行する。

さらにまた、機能が開始される前の確認のためにユーザへの入力要求が必要かどうかをユーザが設定できるように、上記の実施形態に基づいて、インタフェースが提供される。例えば、ユーザは次のように設定する。サーバが機能を開始するための命令を最初に送信するときには、ユーザは確認の必要があるが、以後、その機能は、ユーザの確認無しに直接開始できる。故に、必要の無い確認が特定のアプリケーション環境では回避でき、ユーザ体験が向上する。

本発明の第５実施形態に従って通信端末機能を中断又は再開するための方法が図１２に示される。ここで、現在の端末で中断又は再開される必要のある機能は稼動状態にあると想定する。稼動状態にあるサービス機能の中断と再開との間の状態遷移が図１３に示されており、２つの状態、すなわち、稼動状態及び中断状態が存在する。

特に、中断動作は、機能が稼動状態にある場合のみ実行でき、それによって、機能は中断状態へ遷移する。再開動作は、機能が中断状態にある場合のみ実行でき、それによって、機能は稼動状態へ遷移する。

ステップ１２０１からステップ１２０４は、ステップ４０１からステップ４０４と同一である。

ステップ１２０５において、サービスサーバは、受信した指定された機能の現在の状態を解析するとともに、指定された機能を中断又は再開するための指示を端末へ送信するかどうかを決定する。中断動作は機能が稼動状態にある場合のみ、その機能に対して実行でき、かつ再開動作は機能が中断状態にある場合のみ、その機能に対して実行できるので、中断指示が送信されるときに指定された機能が稼動状態にある場合、又は再開指示が送信されるときに指定された機能が中断状態にある場合は、ステップ１２０６が実行され、そうでない場合は、手順は終了する。

ステップ１２０６において、サービスサーバは、指定された機能を中断又は再開するための指示を含む中断要求又は再開要求を端末へ送信する。稼動状態にある指定された機能を中断することによって、機能によって占有されていた端末のＣＰＵリソースを、それが機能を動作させるために必要で無いときに解放でき、それと同時に、端末の電気エネルギーを節約できる。

ステップ１２０７において、ＤＭサーバは、サービスサーバからの要求に従って、対応する中断又は再開命令を端末中のＤＭエージェントへ送信する。

ステップ１２０８において、ＤＭエージェントがＤＭサーバからＤＭ命令を受信した後、端末のＤＭツリー中の機能を中断及び再開するノードが実行可能ノードである場合、ＤＭエージェントは、ＤＭ命令に含まれた制御指示に従って、対応する実行可能ノードを直接トリガし、かつ指定された機能は、ＤＭサービス機能クライアント中の許可モジュールによって中断又は再開される。端末のＤＭツリー中の機能を中断及び再開するノードが指示ノードである場合、ＤＭエージェントは、ＤＭ命令中の指示に従って、対応する中断指示ノード又は再開指示ノードの値を修正し、ついで、端末は、指示ノードの値の変化を監視することによって、機能を相応に中断又は再開する。

指定された機能が中断された場合、機能は、端末のＣＰＵリソースを占有しないが、その他のリソースを占有し続ける。機能を再び動作させることが要求されるとき、機能の稼動状態は、機能によって占有されている端末のリソースが、ＣＰＵリソースを除けば解放されていないので、ＤＭサーバを介して遠隔再開指示を送信することによって、すみやかに再開される。従って、ユーザ体験が向上する。

ステップ１２０９及びステップ１２１０は、ステップ４０９及びステップ４１０と同一であるので、ここで繰り返して記載はしない。

本発明の第６実施形態に従って機能を中断及び再開するためのシステムの構成が図１４に示される。上記システムは、端末６０、ＤＭサービス機能サーバ７、及びサービスサーバ８を具備する。

ＤＭサービス機能サーバ７は、主にＤＭサーバ７０を具備する。ＤＭサーバは、管理命令を端末６０へ送信するとともに、端末によって返されたメッセージを受信するように構成される。

サービスサーバ８とサーバ７とは、ＷＳＩインタフェースを介して互いに情報をやりとりする。

端末６０は、機能モジュール６１、ＤＭエージェント６２、ＤＭサービス機能クライアント６３、及びユーザインタフェース６４を具備する。

機能モジュール６１は、機能及びその実行環境を提供するとともに、開始、停止、中断などの動作の実際の実行を制御する役目を果たす。実行環境は、Ｊａｖａ（登録商標）又はローカルなアプリケーションプラットフォームであってよい。

ＤＭエージェント６２は、ＤＭエージェント６２とＤＭサーバ７０との間の基本ＤＭプロトコルを解釈及び実行するとともに、動作、命令などを含む機能管理に関する制御指示を取得する役目を果たす。また、ＤＭエージェント６２は、ＤｉａｇＭｏｎ ＭＯのようなＤＭツリーを維持する役目を果たす。機能ＩＤ、名称、動作のような診断機能の関連情報が、ＤｉａｇＭｏｎ管理ツリーに格納される。動作は、開始、停止、中断、再開などを含む。

ＤＭサービス機能クライアント６３は、ＤＭエージェント６２が取得した制御指示に従って、指定された機能の動作状態を制御するように構成される。ＤＭサービス機能クライアント６３は、主に、状態問い合わせ許可モジュール６３０１と、開始／停止許可モジュール６３０２とを具備する。これらの機能は、第４実施形態の同名のモジュールと同一である。さらに、ＤＭサービス機能クライアント６３は、稼動状態にある機能の中断及び再開をサポートするように構成された中断／再開許可モジュール６３０３を具備する。

ユーザインタフェース６４は、ユーザに認証要求を送信するとともに、ＤＭサービス機能クライアント６３が制御命令を実行したときに、ユーザから認証承認を受け取るように構成される。

ＤＭエージェントは、ＤＭツリーのノードを動作させることによって、ＤＭサービス機能クライアントへ制御指示を提供する。図１４に対応して、ＤＭツリーは、機能を中断するノードと、機能を再開するノードとを有する。これら２つのノードが実行可能ノードである場合、実行可能ノードは、ＤＭサーバによって送信されたＤＭ命令に従って、ＤＭエージェントによって機能を中断又は再開するために直接トリガされる。２つのノードが指示ノードであり、かつ状態値がその中に格納されている場合、ＤＭエージェントは、ＤＭ命令中の指示に従って、指示ノードの値を修正し、かつ端末は、指示ノードの値の変化を監視するために、図１４の破線部で示されたような状態監視モジュール６５を用いるとともに、指示ノードの値の変化に従って、対応する中断又は再開動作を実行するように、ＤＭサービス機能クライアントに通知する。状態監視モジュールは、ロジックモジュールであり、ＤＭサービス機能クライアント６３中の許可モジュールによって実行されてよく、又は外部機能若しくは他の許可構成要素によって実行されてもよい。

ＤＭツリーの部分的な構成が図１５に示される。ＤＭツリー中の中断動作又は再開動作を実行するノードが指示ノードである場合、解釈は以下のようになる。

このノードは、機能又は処理を中断する動作を表すように構成される。例えば、０は、初期状態又は中断動作の完了を表し、かつ１は、機能又は処理を中断する必要があることを表す。

このノードは、機能の再スタート、すなわち、再開動作を表す。例えば、０は、初期状態又は再開動作の完了を表し、かつ１は、機能を再開する必要があることを表す。

さらに、動作命令のソース情報を格納する必要がある場合、情報は、<Exit>拡張ノードに、又はノードの属性に格納できる。

ＤＭツリーの構成は、先に記載された構成に限定されない。例えば、図１６に示すように、開始ノードと停止ノードとが１つのノードに結合されてよく、かつ中断ノードと再開ノードとが１つのノードに結合されてもよい。開始／停止ノードに対しては、０は初期状態を表すために用いられ、１は機能又は処理の開始を表すために用いられ、２は機能又は処理の停止を表すために用いられ、かつ３は動作の完了を表すために用いられる。同様に、中断／再開ノードに対しては、０は初期状態を表すために用いられ、１は機能又は処理の中断を表すために用いられ、２は機能又は処理の再開を表すために用いられ、かつ３は動作の完了を表すために用いられる。

別の実施形態におけるＤＭツリーの構成が図１７に示される。葉ノードは、各ノードの状態と、ソースサーバの情報とを表す。フラグノードは、動作命令の状態を表すために用いられ、ソースノードは、動作命令がどのサーバから来たかなどといった動作命令のソースを表すために用いられる。ＤＭ命令を受信したとき、命令ソースの妥当性は、ソースノードの情報に従って判断される。

上記の実施形態において、開始及び停止ノードと同様に、中断及び再開ノードもＳＣｏＭＯで定義されている。これをここで繰り返し記載はしない。さらにまた、中断及び再開ノードは、他の複数の名称を持つ。

さらなる利点及び修正が当業者によって容易に実現される。従って、より広い見地において、本発明は、明細書中に図示及び記載された特定の詳細及び代表的な実施形態に限定されない。故に、添付された特許請求の範囲及びそれらの均等物によって定義された本発明の精神又は範囲から逸脱することなく、さまざまな修正及び変形がなされる。

３０ 端末
３１ 機能モジュール
３１１ ＢＣＡＳＴクライアント
３１２ ＰｏＣクライアント
３２ ＤＭエージェント
３３ ＤＭサービス機能クライアント
３３０ ＤｉａｇＭｏｎクライアント（ＤＭサービス機能クライアント）
３３０１ 状態問い合わせモジュール
３３０２ 開始／停止許可モジュール
３３１、３３４ その他のＤＭサービス機能クライアント
３３２ スケジューリングクライアント（ＤＭサービス機能クライアント）
３４ ユーザインタフェース
３５ 状態監視モジュール
４ ＤＭサービス機能（サーバ側）
４０ ＤＭサーバ
５ サービスサーバ
５１ ＢＣＡＳＴサーバ
５２ ＰｏＣサーバ

Claims (7)

1. 管理ツリーノードを端末のデバイス管理ツリーに設定又は追加する段階であって、前記管理ツリーノードが指示ノードである、段階と、
   指定された機能の動作状態に関する制御指示から成るデバイス管理命令を送信する段階であって、前記制御指示が前記端末の前記デバイス管理ツリーの前記指示ノードの値を修正することによる、段階と、
   前記指示ノードの値の変化を前記端末によって監視するとともに、前記変化を前記指定された機能の実行環境に通知する段階と、
   前記指示ノードの値の前記変化に従って、前記機能に関する動作を前記指定された機能の前記実行環境で実行する段階と
   を有し、
   前記指定された機能の前記動作状態は、稼動状態と非稼動状態とを含み、
   前記制御指示は、前記端末中の前記指定された機能を開始又は停止するための指示を含むことを特徴とする通信端末デバイスを管理するための方法。
2. 前記方法は、
   前記デバイス管理命令が前記端末へ送信される前に、前記指定された機能の現在の動作状態を前記端末に問い合わせるとともに、前記現在の動作状態をサービスサーバへ送信し、
   前記指定された機能の前記現在の動作状態に従って、送信される前記デバイス管理命令中の前記制御指示を前記サービスサーバによって決定する段階、
   及び／又は、
   前記端末が前記動作を実行する前に、前記指定された機能の現在の動作状態を前記端末によって判断して、
   非稼動状態にある前記指定された機能に応じて、前記指定された機能に関する開始動作を実行し、
   稼動状態にある前記指定された機能に応じて、前記指定された機能に関する停止動作を実行し、
   さもなければ、前記デバイス管理命令中の前記制御指示を無視する段階
   をさらに有することを特徴とする請求項１に記載の通信端末デバイスを管理するための方法。
3. 前記制御指示は、前記指定された機能を中断又は再開するための指示をさらに含み、
   前記制御指示に従って前記端末によって実行される、前記指定された機能の前記動作状態に関する前記動作は、前記端末中の前記指定された機能の中断又は再開から成ることを特徴とする請求項１に記載の通信端末デバイスを管理するための方法。
4. 前記機能の前記動作状態は、稼動状態と中断状態とをさらに含み、
   前記方法は、
   前記デバイス管理命令が前記端末へ送信される前に、前記指定された機能の現在の動作状態を前記端末に問い合わせるとともに、前記現在の動作状態をサービスサーバへ送信し、
   前記指定された機能の前記現在の動作状態に従って、送信される前記デバイス管理命令中の前記制御指示を前記サービスサーバによって決定する段階、
   及び／又は、
   前記端末が前記動作を実行する前に、前記指定された機能の現在の動作状態を前記端末によって判断して、
   稼動状態にある前記指定された機能に応じて、前記指定された機能に関する中断動作を実行し、
   中断状態にある前記指定された機能に応じて、前記指定された機能に関する再開動作を実行し、
   さもなければ、前記デバイス管理命令中の前記制御指示を無視する段階
   をさらに有することを特徴とする請求項３に記載の通信端末デバイスを管理するための方法。
5. 前記制御指示は、所定の条件下で動作を実行するための指示であり、
   前記制御指示に従って前記端末によって実行される前記動作は、前記制御指示中の前記所定の条件を保存することと、前記所定の条件に合致した場合に、前記制御指示に従って前記動作を実行することとから成ることを特徴とする請求項１に記載の通信端末デバイスを管理するための方法。
6. 所定の機能を提供するように構成された機能モジュールと、
   指定された機能の動作状態に関する制御指示から成るデバイス管理命令を受信及び分解するように、かつ、デバイス管理ツリーを維持するとともに、前記デバイス管理命令に従って前記デバイス管理ツリーの管理ツリーノードを操作するように構成されたデバイス管理エージェントであって、前記管理ツリーノードが指示ノードであり、前記デバイス管理命令に従って前記デバイス管理ツリーの前記管理ツリーノードを操作することが前記指示ノードの値を変化させることである、デバイス管理エージェントと、
   前記指示ノードの値の変化を監視するとともに、前記変化をデバイス管理サービス機能クライアントに通知するように構成された状態監視モジュールと、
   前記指示ノードの値に従って、前記指定された機能の前記動作状態に関する動作を実行するように構成されたデバイス管理サービス機能クライアントと
   を具備し、
   前記指定された機能の前記動作状態は、稼動状態と非稼動状態とを含み、
   前記制御指示は、前記端末中の前記指定された機能を開始又は停止するための指示を含むことを特徴とする通信端末。
7. 通信システムであって、
   通信端末と、
   前記通信端末との通信機能を有するデバイス管理サーバと
   を具備し、
   前記デバイス管理サーバは、指定された機能の動作状態に関する制御指示から成るデバイス管理命令を前記通信端末へ送信するように構成され、
   前記通信端末は、
   所定の機能を提供するように構成された機能モジュールと、
   前記デバイス管理命令を受信及び分解するように、かつ、デバイス管理ツリーを維持するとともに、前記デバイス管理命令に従って前記デバイス管理ツリーの管理ツリーノードを操作するように構成されたデバイス管理エージェントであって、前記管理ツリーノードが指示ノードであり、前記デバイス管理命令に従って前記デバイス管理ツリーの前記管理ツリーノードを操作することが前記指示ノードの値を変化させることである、デバイス管理エージェントと、
   前記指示ノードの値の変化を監視するとともに、前記変化をデバイス管理サービス機能クライアントに通知するように構成された状態監視モジュールと、
   前記指示ノードの値に従って、前記指定された機能の前記動作状態に関する動作を実行するように構成されたデバイス管理サービス機能クライアントと
   を具備し、
   前記指定された機能の前記動作状態は、稼動状態と非稼動状態とを含み、
   前記制御指示は、前記端末中の前記指定された機能を開始又は停止するための指示を含むことを特徴とする通信システム。

Images