通信端末デバイスを管理するための方法、通信端末、及び通信システム
【課題】改善されたデバイス管理(DM)技術を提供する。
【解決手段】この発明は通信技術に関し、通信端末のデバイス管理方法は、指定されたプログラム起動状態の制御指示から成るデバイス管理命令を端末へ送信するステップを有する。指定されたプログラム起動状態を実行する上記端末は、上記制御指示に基づいて処理を行なう。また、関連する通信端末及びシステムが提供される。改善されたDM技術は、1つのプログラム又は1つのプロセス起動状態を遠隔制御する機能を与えられる。サービスの正常な稼動を確実にするために、DMサーバによって、サービス開始の前に、サービスに関連するプログラム又は対応するプロセスを遠隔で前もって起動できる。サービス稼動時に関連プログラムを直ちに起動できるほかにも、所定の条件下であらかじめ構成されたサービス発行計画に基づいて関連サービスプログラムを起動できる。
【解決手段】この発明は通信技術に関し、通信端末のデバイス管理方法は、指定されたプログラム起動状態の制御指示から成るデバイス管理命令を端末へ送信するステップを有する。指定されたプログラム起動状態を実行する上記端末は、上記制御指示に基づいて処理を行なう。また、関連する通信端末及びシステムが提供される。改善されたDM技術は、1つのプログラム又は1つのプロセス起動状態を遠隔制御する機能を与えられる。サービスの正常な稼動を確実にするために、DMサーバによって、サービス開始の前に、サービスに関連するプログラム又は対応するプロセスを遠隔で前もって起動できる。サービス稼動時に関連プログラムを直ちに起動できるほかにも、所定の条件下であらかじめ構成されたサービス発行計画に基づいて関連サービスプログラムを起動できる。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信技術、特に、通信端末デバイスを管理するための方法、通信端末、及び通信システムに関する。
【背景技術】
【0002】
現在、中国における携帯電話ユーザの数は2億人に達しようとしている。ユーザの要求がますます多様化かつ個別化するにつれて、中国の遠隔通信の革新は一層高度化し、かつ固定電話及び携帯電話が再構築及び改良されるにつれ、サービス提供者は、BCAST(Broadcast)サービス、VoIP(Voice over Internet Protocol)サービス、PoC(Push-to-Talk Over Cellular)サービスなどといった、より多岐にわたるサービスをユーザへ提供し始めた。
【0003】
VoIPは、主にIP(Internet Protocol)電話を基盤として実現され、かつ対応する付加価値サービスを提供する技術である。VoIPを用いることで、バーチャルフォン、インターネットコール管理、テレビ会議、及びさまざま情報の格納及び送信といった、音声、FAX、映像、及びデータを含むサービス情報の転送がIPネットワーク上で安価に実現できる。
【0004】
移動端末(Mobile Terminal,MT)に適したVoIPシステムが、PoCサービスによって定義される。ワイヤレスデータネットワークのパケット交換機能を使用することで、PoCサービスは立地の制限を受けない。
【0005】
OMA(Open Mobile Alliance)は、PoCサービスの規格化に向けて作業を進めている。OMAのPoCソリューションは、インターネット技術タスクフォース(Internet Engineering Task Force,IETF)によって定義されたセッション確立プロトコル(Session Initiation Protocol,SIP)及びリアルタイム転送プロトコル(RealTime Transfer Protocol,RTP)に基づくものである。
【0006】
通信技術の発展と共に、ネットワークの規模はますます肥大化し、かつその構造もますます複雑化している。サービス品質(Quality of Service,QoS)の向上及び運用コストの削減のためには、効率的なネットワーク管理システムを構築する必要がある。結果として、遠隔通信管理ネットワーク(Telecommunication Management Network,TMN)が時勢の要望として現れた。
【0007】
TMNは、遠隔通信リソース、ネットワーク稼働率、サービス、及び管理を計画し、監視し、設計し、かつ制御するための方針及び方法を提供するとともに、オペレータ/マネージャ及び端末ユーザのために機能する遠隔通信ネットワークOAM(Operation Administration Maintenance)を備えたシステムを提供する。遠隔通信ネットワーク全体にわたって管理ネットワークを利用することによって、ネットワークリソースの全面的及び効率的な監視及び管理が実現できるだけでなく、複数の管理範囲にわたるサービスを開始できるように、ネットワークシステムを相互接続することもできる。
【0008】
TMNの実現は、2つの部分に分けられる。第1部分では、複数のサブネットワーク間でインタフェース通信が実現できるように、ネットワーク層より下位の遠隔通信リソースを監視及び制御するためのシステムが構築される。故に、ローカルネットワーク、アクセスネットワーク、及びSDH(Synchronous Digital Hierarchy)の透過的な制御及び監視が実現する。第2部分では、例えば、ユーザ管理、ネットワーク設備管理、労働力管理、請求、支払、及び会計管理、QoS及びネットワークパフォーマンス管理、トラフィック測定及び解析管理、保守管理、セキュリティ管理、ログ管理などの21世紀へ向けた管理サービスが開発されるように、遠隔通信ネットワークの意志決定サポートシステムがネットワーク層上に構築される。
【0009】
TMNシステム構成情報モデルの大部分は、階層構造ツリーを用いて、構成モデルの階層構造を記述する。それは、構成情報モデルツリーと称される。
【0010】
いわゆる情報モデルにおいて、ネットワークリソースは、管理の観点から運用される必要のある多数の小さな構成単位に分割される。ついで、これらの小さな構成単位は、複数の管理対象(Management Object,MO)を生成するために抽象化される。手短に言えば、情報モデルとは、ネットワーク管理システムによって運用されるリソースから抽象化されたMOの集合である。リソース管理は、これらのリソース抽象化エンティティ、すなわちMOを処理することによって間接的に実行される。MO交換情報を用いることによって管理動作を完遂するために、命令を発する責任があるマネージャと、命令を実行する責任があるエージェントとが必要とされる。命令を完遂するために、エージェントは、その名称、属性、従属関係などといった処理されるべき対象を知ってなくてはならない。このような情報のすべては、MIB(Manager Information Base)から得る。MIB中の情報は、規則に従って組織的に構成されている。情報モデルの方法を用いることによって、MIBは、ツリー構造が形成されるように、従属関係及び導出の規則に従って、トップからボトムへ抽象化されたMOを論理的に配置する。言い換えれば、検索を容易にする上記の情報モデルツリーが構築される。
【0011】
OMA DM(Device Management)規格において、端末を管理、診断、及び保守するためのTMN技術が計画され、かつサーバは、DM管理ツリーを介して、端末に対するファームウェアアップデート、アプリケーションダウンロード、診断及び監視、バックアップ及びリストアなどといった管理動作を実行できる。端末は、携帯電話、PDA(Personal Digital Assistant)、ノートブックコンピュータ、組込みデバイス、オンボードシステムなどである。
【0012】
現在のOMA DM規格は、ソフトウェアコンポーネント管理技術、すなわち、端末上のソフトウェアコンポーネントを管理するためのDMサーバに対するメカニズムを提供する。
【0013】
ソフトウェアコンポーネントは、実行可能アプリケーション、ダイナミックリンクライブラリ、ユーザインタフェース(User Interface,UI)などである。管理動作は、端末パラメータ設定、ファームウェアアップデート、エラー診断、バックアップ又はリストアのほかにも、ソフトウェアコンポーネントの問い合わせ、インストール、アップデート、アクティベーション、又は削除であってよい。
【0014】
DM規格によって表された全体の構成が、図1に示される。端末10上のDMエージェント11は、DMサーバ20によって発せられた管理命令を解釈及び実行するように構成される。端末に格納されたDM管理ツリー12は、DMサーバ20に対するインタフェースと見なすことができ、DMプロトコルを介して端末10を管理する。DM管理ツリー12は、いくつかの基本的なMOを含む。DMサーバ20は、MOに関する動作を介して端末10のリソースを制御する。例えば、ソフトウェアコンポーネントに関する管理は、端末10上のソフトウェアコンポーネント管理オブジェクト(Software Component Management Object,SCoMO)を追加、削除、及び修正することによって実行される。
【0015】
DM規格においてソフトウェアコンポーネントを管理するための方法が、図2に示される。
【0016】
ステップ201において、DMサーバは、端末に、インストールされたソフトウェアコンポーネントのインベントリの問い合わせを行う。
【0017】
ステップ202において、端末は、ユーザに認証を要求する。
【0018】
ステップ203において、ユーザは、認証を確認する。
【0019】
ステップ204において、端末は、ソフトウェアコンポーネントインベントリをDMサーバへ送信する。
【0020】
ステップ205において、DMサーバは、ソフトウェアコンポーネントの端末へのダウンロード及びインストール動作を開始する。
【0021】
ステップ206において、端末は、DMサーバに確認メッセージを返す。
【先行技術文献】
【特許文献】
【0022】
【特許文献1】国際公開第2006/006803号
【特許文献2】特開2005−244403号公報
【特許文献3】国際公開第2005/004395号
【非特許文献】
【0023】
【非特許文献1】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
【発明の概要】
【発明が解決しようとする課題】
【0024】
研究の間に、発明者は、上記のソリューションが以下の短所を有することに気づいた。すなわち、ソフトウェアコンポーネントの追加、削除、及び修正といった静的状態しか制御できない。四六時中ネットワーク側から配信されるサービスを効果的に受信するために、端末は、サービス受信部などのそのサービス機能を稼動状態に保たなければならない。受信するサービスがない場合、稼動状態にあるサービス機能は、対応するハードウェアリソースが電気エネルギーを不要に消費する原因となる。故に、通信端末の電力消費量が大きくなり、それと同時に、端末の中央演算ユニット(Central Processing Unit,CPU)などのリソースが占有される。結果的に、無駄が生じる。
【課題を解決するための手段】
【0025】
本発明の一実施形態は、通信端末デバイスを管理するための方法を提供する。上記方法は、指定された機能の動作状態に関する制御指示から成るデバイス管理命令を端末へ送信する段階と、制御指示に従って、指定された機能の動作状態に関する動作を端末で実行する段階とを有する。
【0026】
さらに、本発明の一実施形態は、対応する通信端末を提供する。上記端末は、機能を提供するように構成された機能モジュールと、指定された機能の動作状態に関する制御指示から成るデバイス管理命令を受信及び分解(resolve)するように構成されたデバイス管理エージェントと、制御指示に従って、指定された機能の動作状態に関する動作を実行するように構成されたデバイス管理サービス機能クライアントとを具備する。
【0027】
さらに、本発明の一実施形態は、通信システムを提供する。上記システムは、通信端末及びDMサーバを具備する。デバイス管理サーバは、指定された機能の稼動状態に関する制御指示から成るデバイス管理命令を通信端末へ送信するように構成される。通信端末は、制御指示に従って、指定された機能の動作状態に関する動作を実行するように構成される。
【発明の効果】
【0028】
本発明の技術的ソリューションでは、例えば、アプリケーションの開始、停止又は中断、及び再開の制御などのアプリケーションの動作状態を遠隔制御する機能を有することができるように、DM技術が強化されるということが、比較によって明らかとなった。
【0029】
サービスが正常に動作することを保証できるように、サービス実行より先に、サービスに関連するアプリケーションがあらかじめ端末上でDMサーバによって遠隔開始される。実行の必要があるサービスに間に合うように、関連するアプリケーションが起動されるので、アプリケーションが端末上で四六時中稼動する必要は無い。従って、端末の貴重な電気エネルギーを節約できる。
【0030】
また、サービスが実行されている場合、端末上で稼動しているサービスに関連するアプリケーションは、アプリケーションが稼動する必要の無いときに、アプリケーションによって占有される端末のCPUリソースを解放し、それと同時に、端末の電気エネルギーを節約できるように、DMサーバによって遠隔中断される。アプリケーションが再び稼動する必要のあるとき、CPUを除く、アプリケーションによって占有されたリソースは解放されていないので、アプリケーションの稼動状態は、DMサーバを介して遠隔再開指示を端末へ送信することによって迅速に再開される。結果的に、ユーザ体験が向上する。
【0031】
さらにまた、関連するアプリケーションが、サービスが実行されたときに、直ちに開始されるか、又は関連するサービス機能が、あらかじめ構築されたサービス配信プランに従って、所定のサービス配信時間に開始される。これら2つのモードを臨機応変に用いることによって、必要とされる異なるサービスがより良く手配できる。
【図面の簡単な説明】
【0032】
【図1】従来技術におけるOMA DM規格に記載された全体の構成を示す概略図である。
【図2】従来技術におけるOMA DM規格でのソフトウェアコンポーネント管理方法のフローチャートである。
【図3】サービス機能が本発明に従って開始又は停止される場合の状態遷移を示す概略図である。
【図4】本発明の第1実施形態に従って通信端末機能を開始又は停止するための方法のフローチャートである。
【図5】本発明の第2実施形態に従って通信端末機能を開始又は停止するための方法のフローチャートである。
【図6】本発明の第3実施形態に従って通信端末機能を開始又は停止するための方法のフローチャートである。
【図7】本発明の一実施形態による通信端末の構成図である。
【図8】本発明の第4実施形態に従って通信端末とサーバ側と間で通信を行うためのシステムの構成図である。
【図9】本発明の第4実施形態によるサービス機能管理システムの構成図である。
【図10】本発明の第4実施形態によるDMツリーの部分的な構成図である。
【図11】本発明の第4実施形態に従ってスケジューリング許可部を介して対応する機能を呼び出すことによって機能を開始又は停止するためのシステムの構成図である。
【図12】本発明の第5実施形態に従って通信端末機能を中断及び再開するための方法のフローチャートである。
【図13】本発明の第5実施形態による機能の中断と再開との間の状態遷移の概略図である。
【図14】本発明の第6実施形態に従って機能を中断又は再開するためのシステムの構成図である。
【図15】本発明の第6実施形態によるDMツリーの部分的な構成図である。
【図16】本発明の第6実施形態によるDMツリーの部分的な構成図である。
【図17】本発明の第6実施形態によるDMツリーの部分的な構成図である。
【発明を実施するための形態】
【0033】
本発明の目的、技術的解決策、及び利点をより明白にするために、これより、本発明を図面と併せてさらに詳細に記載する。
【0034】
本発明において、サービス提供者は、指定された機能の動作状態に関する制御指示を含むメッセージを端末へ送信する。端末は、メッセージに含まれた制御指示に従って、指定された機能に対応する制御動作を実行する。制御動作は、開始(start)、停止(stop)、中断(suspend)、再開(resume)などの動作を含む。
【0035】
本明細書中のいわゆる機能は、一般的な表現であり、端末の実行環境で実行可能なソフトウェア、プログラムの一部、プロシージャ、(XMLのような)スクリプト言語の一部などであってよい。例えば、機能は、診断処理、トラップ機能、又はスケジューリングコンポーネントなどであってもよい。
【0036】
本発明の実施形態における機能の状態遷移が、図3に示される。それは、停止状態及び稼動状態の2つの状態を有する。機能が停止状態にある場合のみ、機能に対する開始動作を実行でき、かつ機能が稼動状態にある場合のみ、機能に対する停止動作を実行できる。
【0037】
さらにまた、サービス提供者は、DMサーバを介して、指定された機能を中断又は再開するための指示を含むメッセージを端末へ送信する。端末は、メッセージに含まれた指示に従って、指定された機能を中断又は再開する。機能が稼動状態にある場合のみ、中断動作を実行できる。
【0038】
本発明の第1実施形態に従って通信端末機能を開始又は停止するための方法が、図4に示される。ここで、現在の端末で開始される必要のある診断機能は停止状態にあると想定する。
【0039】
ステップ401において、端末のためにサービスを実行する必要がある場合、まず、サービス提供者は、DMサーバに問い合わせ要求を依頼する。例えば、ネットワーク側のサービスサーバは、端末上のサービス機能が開始されたかどうか、すなわち、機能が稼動状態にあるかどうかを問合せるように、DMサーバに指示する。
【0040】
特に、問い合わせの主な命令は、以下の通りである。
<Get>
<Item>
<Target>
<LocURI>./Diagnostic Function/StateValue(./BCAST client/state value)</LocURI>
</Target>
</Item>
</Get>
【0041】
ステップ402において、DMサーバは、デバイス管理命令を発行するとともに、端末に機能の現在状態を問い合わせる。DMサーバ及び端末のDMエージェントは、標準OMA DMプロトコルを介して互いに情報をやりとりする。
【0042】
ステップ403において、端末は以下の問い合わせ結果を返す。
<Results>
<Item>
<Source>
<LocURI>./Diagnostic Function/StateValue</LocURI>
</Source>
<Data>Stopped</Data>
</Item>
</Results>
【0043】
ここで、取得した結果は機能が停止状態にあることだと想定する。
【0044】
ステップ404において、DMサーバは、サービスサーバに問い合わせ結果を返す。
【0045】
ステップ405において、問い合わせ結果に従って、開始する必要のあるサービス機能が開始されていない場合、サービスサーバは、DMサーバへメッセージを送信するとともに、メッセージ中の機能を開始するための動作指示を配信する。
【0046】
ステップ406において、DMサーバは、端末のDMエージェントへメッセージを転送するとともに、端末上の診断機能を開始するために、以下の管理命令を発行する。
<Exec>
<item>
<Target>
<LocURI>./Diagnostic Function/Operations/Start</LocURI>
</Target>
</Item>
</Exec>
【0047】
ステップ407において、DM命令を受信した後、DMエージェントは、DM命令のソースが妥当なものであるかどうかを判断する。妥当である場合、DMエージェントは、メッセージを解釈するとともに、メッセージに含まれた動作指示を取得する。そうでない場合、DMエージェントは、DM命令を棄却する。
【0048】
セキュリティ、プライバシーなどの問題に関しては、DMエージェントは、動作指示に従って、端末のUIを介してユーザへ問い合わせメッセージをさらに送信するとともに、サービスを受け入れるかどうかを判断するように、ユーザに要求する。
【0049】
ユーザがサービスについて省略時(default)動作を設定していた場合、DMエージェントは、ユーザからの確認メッセージを取得する過程を実行する必要は無い。その代わりに、DMエージェントは、設定された省略時動作に従って、DMサーバによって直接発行された命令を処理し、ついでステップ409へ進む。
【0050】
ステップ408において、ユーザは、UIを介してサービスを確認する。ユーザがサービスの受け入れを望まない場合、又はサービスを受け入れることがユーザにとって都合が悪い場合、ユーザは、取り消し動作を実行する。ユーザがサービスを受け入れる場合、承認動作が実行される。ユーザが取り消し動作の実行も承認動作の実行も行わない場合、省略時処理モードが設定されてよい。例えば、ユーザがサービスを棄却するとみなされる。
【0051】
例えば、ユーザがサービスを受け入れることを示す確認メッセージ(受理又は棄却)は、端末のUIを介してDMエージェントへ返される。
【0052】
上記のステップ407及びステップ408は任意に選択できる。ユーザは、端末でのユーザ確認をトリガするためのポリシをあらかじめ設定できる。例えば、サーバが機能を制御するための命令を初めて送信したときには、ユーザの確認を必要とするが、以後、サーバは機能を直接制御するための命令を送信できる。
【0053】
ステップ409において、端末は、DMサーバによって送信された命令を実行するとともに、ユーザ承認に基づいたサービスの機能を開始する。DMツリーは、端末に格納されてよい。DMツリーは、機能を開始するノードと、機能を停止するノードとを有する。2つのノードがどちらも実行可能ノードである場合、DMエージェントは、DMサービス機能クライアントの許可モジュールを介して、指定された機能の対応する開始又は停止動作を実行するために、DMサーバによって送信された命令に含まれた制御指示に従って、対応する実行可能ノードを直接トリガする。2つのノードがどちらもDMツリー中の指示ノードである場合、DMエージェントは、DMサーバによって送信された命令中の指示に従って、対応する指示ノードの値を修正し、かつ端末は、指示ノードの値の変化を監視することによって、指定された機能の対応する開始又は停止動作を実行する。
【0054】
対応する開始(又は停止)動作が実行された後、動作結果がDMサーバに報告される。
<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>
【0055】
ユーザが判断に従ってサービスを棄却した場合、DMサーバは、サービス要求を終了するために通知を受ける。
【0056】
ステップ410において、DMサーバは、動作結果をサービスサーバに通知する。
【0057】
ステップ411において、受信した動作結果が、端末サービスが開始されていることを示す場合、サービスサーバは、端末との接続を確立するとともに、端末へのサービスの配信又はサービスの管理を開始する。返された動作結果が、端末サービスが停止中であることを示す場合、端末との接続は切断され、かつ端末に対するサービスの配信又は管理動作は停止される。
【0058】
上記の方法に従って、関連する機能は、実行する必要のあるサービスより先に開始される。機能はもはや端末上で四六時中稼動する必要はなく、端末の貴重な電気エネルギーを節約できる。さらに、遠隔で開始又は停止される機能は診断機能であってよく、それによって、ネットワーク側は、他の機能は通常のものであるのかどうか、指定された機能の状態などといった情報を取得できる。故に、端末の稼動状態が、臨機応変に監視できる。
【0059】
本発明の第2実施形態に従って通信端末機能を開始又は停止するための方法が、図5に示される。ここで、現在の端末で開始する必要のある機能は稼動状態にあり、かつネットワーク側がサービスサーバを介してサービスを制御すると想定する。この実施形態と先の実施形態との間の主な差異は、サービスサーバが制御指示を送信する前に、端末中の指定された機能の動作状態が問い合わせを受けないことにある。代わりに、制御指示は、現在のサービスによって問い合わせられたものとして直接送信され、かつ端末は、指定された機能の現在の動作状態に従って、制御指示の実行又は無視を決定する。この実施形態においては、一例として、DMサーバが開始指示を送信する場合に行われる。他の指示も同様である。
【0060】
ステップ501において、サービスサーバは、サービスに必要な機能の開始指示をDMサーバへ送信する。
【0061】
ステップ502からステップ504は、ステップ406からステップ408とそれぞれ同一である。
【0062】
ステップ505において、ユーザ承認を得た後、DMエージェントは、端末中の指定された機能の状態に従って、開始指示を実行又は無視する。例えば、指定された機能が稼動状態にある場合、DM命令中の指定された機能を開始するための指示は無視される。
【0063】
端末中の指定された機能が非稼動状態にある場合、DM命令中の指定された機能を開始するための指示は実行される。
【0064】
ついで、動作結果、すなわち、現在、機能は稼動状態にあるということが、DMサーバへ報告される。さらに、ユーザ確認メッセージが棄却である場合、DMサーバは、サービス要求を終了させるために通知を受ける。
【0065】
ステップ506及びステップ507は、ステップ410及びステップ411とそれぞれ同一であるので、ここで繰り返して記載はしない。
【0066】
本発明の第3実施形態に従って通信端末機能を開始又は停止するための方法が図6に示される。この実施形態において、現在の端末で開始する必要のある機能は停止状態にあると想定する。
【0067】
ステップ601において、サービスサーバは、サービス配信プラン又はサービス管理プランを作成する。プランは、時刻に基づいている。例えば、BCASTサーバは、タイムテーブルに従って、毎日10:00〜11:00と16:00〜17:00とに、端末にサービスをブロードキャストするとともに、タイムテーブル中の時間枠に従って、BCASTクライアントを開始するように、端末に指示を行う。また、プランは、端末上のイベントに基づいている。例えば、端末は、機能の自動更新が完了したときに機能を自動的に停止するように指示される。
【0068】
ついで、サービスサーバは、DMサーバのウェブサービスインタフェース(Web Service Interface,WSI)を介してDMサーバへサービス配信プランを提示する。サービス配信プランは、機能ID、時間又は条件などを含む。
【0069】
ステップ602において、DMサーバは、サービスサーバによって提示されたサービス配信プランに従って、スケジューリングを生成する。スケジューリングは、トリガ条件及び所定の動作を含む。例えば、トリガ条件は、10:00 AMであり、かつ所定の動作は、クライアント上のBCAST機能を開始することである。
【0070】
ついで、DMサーバは、標準OMA DMプロトコルを介して端末のDMエージェントへ生成されたスケジューリングを送信する。
【0071】
ステップ603において、DMエージェントは、端末のUIを介して、スケジューリングを導入するのかどうかの判断をユーザに要求する。
【0072】
ユーザがサービスに対して省略時動作を設定する場合、DMエージェントは、ユーザ確認を必要とせずに、省略時動作に従ってスケジューリングを直接処理し、かつステップ606へ進む。
【0073】
ステップ604において、ユーザは、UIを介してスケジューリングを確認する。ユーザがサービスの受け入れを望まない場合、又はサービスの受け入れがユーザにとって都合が悪い場合、ユーザは、取り消し動作を実行する。ユーザがサービスを受け入れる場合、ユーザは、承認動作を実行する。ユーザが取り消し動作の実行も承認動作の実行も行わない場合、省略時処理が実行されてよい。例えば、ユーザがサービスを棄却するとみなされる。
【0074】
例えば、ユーザがサービスを受け入れることを示す確認メッセージ(受理又は棄却)は、端末のUIを介してDMエージェントへ返される。
【0075】
さらにまた、ユーザは、UIを介してスケジューリングを修正できる。例えば、ユーザは、ブロードキャストが10:00〜11:00の時間枠のみで受信されるように、タイムテーブルを修正できる。
【0076】
DMエージェントは、スケジューリングを導入するように端末に指示するとともに、ユーザの承認又は修正に従って、スケジューリングを実行する。ユーザ確認メッセージが導入棄却である場合、スケジューリングは取り消される。
【0077】
ステップ605において、スケジューリングのトリガ条件に合致した場合、例えば、時刻が10:00に達したか、又は機能更新が完了した場合に、ユーザは、スケジューリングに対応する機能の開始又は停止動作を実行するかどうか、例えば、ブロードキャストサービスの受信を開始するかどうかの確認を要求される。
【0078】
しかしながら、また、省略時動作が設定されていれば、ユーザの確認を要求することなく、省略時動作が適宜に実行される。
【0079】
ステップ606は、ステップ408と同一である。
【0080】
ステップ607において、DMエージェントは、ユーザ承認に基づくスケジューリング中の所定の動作を実行し、現在稼動状態にある機能を開始(又は、機能を停止、例えば、DMエージェントが11:00に停止動作を実行)し、かつ動作結果をDMサーバへ返す。
【0081】
端末が開始(又は停止)動作を実行するときに、機能が稼動状態にある場合、DM命令中の開始(停止)指示は無視される。
【0082】
ステップ608は、ステップ410と同一であるので、ここで繰り返して記載はしない。
【0083】
ステップ609において、サービスサーバは、端末との接続を確立するとともに、返された動作結果が開始である場合に、サービス配信又はサービス管理を開始する。返された動作結果が停止である場合、端末との接続は切断され、かつ端末に対するサービス又は管理動作は停止される。
【0084】
関連するサービス機能は、サービスが実行されたときに直ちに開始されてよく、又はあらかじめ構築されたサービス開始プランに従って、所定のサービス開始時刻に開始されてもよい。これら2つのモードを臨機応変に用いることによって、異なるサービスの要求により良く対処できる。
【0085】
本発明の第4実施形態による通信端末の構成が図7に示される。通信端末は、1つ以上の機能モジュール31と、DMエージェント32と、1つ以上のDMサービス機能クライアント33とを具備する。機能モジュール31は、さまざまなサービスを実行する機能を提供するように構成される。DMエージェント32は、ネットワーク側のDMサーバからデバイス管理命令を受信及び分解して、対応する制御指示を取得し、ついでDMツリーを動作させ、かつ維持するように構成される。DMサービス機能クライアント33は、DMエージェント32で取得した制御指示に従って、指定された機能の動作状態に関する対応する制御動作を実行するように構成される。
【0086】
BCASTサービス及びPoCサービスの機能の一例として、通信端末30、DMサーバ40、及びサービスサーバの間で通信を行うためのシステムの構成が図8に示される。BCASTサービスの機能モジュールは、BCASTクライアント311として構成され、PoCサービスの機能モジュールは、PoCクライアント312として構成され、かつサービスは、BCASTプロトコル及びPoCプロトコルをそれぞれ用いて、BCASTサーバ51及びPoCサーバ52によって配信される。DMエージェント32は、DMサービス機能クライアント33を介してサービスクライアントを管理する。特定のサービス機能に従って、DMサービス機能クライアントは、アプリケーション管理クライアント、診断及び監視(Diagnostic and Monitoring,DiagMon)クライアント、スケジューリングクライアントなどであってよい。
【0087】
図9は、DMサービス機能クライアントが特にDiagMonクライアントであるサービス機能管理システムの構成を表す。
【0088】
図9において、DMエージェント32は、DMサーバ40によって発行されたデバイス管理命令を解釈するとともに、その中の制御指示をDiagMonクライアント330へ提供する。
【0089】
DiagMonクライアント330は、主に以下のモジュールを具備する。
【0090】
状態問い合わせモジュール3301。これは、端末上の機能の状態を問い合わせるためにDMサーバ40をサポートするように構成される。
【0091】
開始/停止許可モジュール3302。これは、ソフトウェアの開始及び停止をサポートするように構成される。端末は、DMサーバ40によって送信された命令を受信した後に、開始/停止許可モジュールを介して関連する実行可能ノードを制御することによって機能の開始及び停止を実現する。開始/停止許可モジュールは、ロジック機能モジュールであり、DMサービス機能クライアントに、又はその他の位置にあってよい。
【0092】
DMサービス機能サーバ4は、主にDMサーバ40を具備する。DMサーバは、管理指示を端末へ送信するとともに、端末によって返されたメッセージを受信する。
【0093】
サービスサーバ5とサーバ4とは、WSIインタフェースを介して互いに情報をやりとりする。
【0094】
ユーザインタフェース34は、ユーザに認証要求を送信するとともに、DiagMonクライアント330が制御指示を実行したときに、ユーザから認証を受け取るように構成される。
【0095】
また、DiagMonクライアント330は、アプリケーション管理クライアント、スケジューリングクライアントなどといったその他のDMサービス機能クライアント331と情報をやりとりしてもよい。
【0096】
DMエージェントは、DMツリーのノードを動作させることによって、DMサービス機能クライアントへ制御指示を提供する。図9に対応して、DMツリーは、機能を開始するノード及び機能を停止するノードを有する。これら2つのノードが実行可能ノードである場合、実行可能ノードは、DMサーバによって送信されたDM命令を介して、機能の開始又は停止動作を実行するために直接トリガされる。2つのノードが指示ノードである場合、DMエージェントは、DM命令中の指示に従って、指示ノードの値を修正し、かつ端末は、指示ノードの値の変化を監視するために、図9の破線部で示すような状態監視モジュール35を用いるとともに、指示ノードの値の変化に従って、対応する開始又は停止動作を実行するために、DMサービス機能クライアントに通知を行う。DMツリーの部分的な構成が図10に示される。
【0097】
【表1】
【0098】
<Interior Node>は、内部ノードを意味し、サービス機能MOのルートノードである。MOは、ScoMO、DiagMon Mo、スケジューリングMO又はアプリケーション管理MOなどであってよい。
【0099】
<x>は置換子(placeholder)であり、特定の情報と、導入された機能の関連する実行可能動作とが、このノード下に格納される。
【0100】
便宜上、以下の記載においては、<Interior Node/x>は<./x>に置き換えられる。
【0101】
【表2】
【0102】
ソフトウェアIDは、このノードに格納される。
【0103】
【表3】
【0104】
このノードは、ソフトウェアの状態を表す。ノードの値は、以下のようになる。
【0105】
【表4】
【0106】
このノードは、一連の実行可能ノードの親ノードである。
【0107】
【表5】
【0108】
このノードは、実行可能ノードであり、機能又は処理を開始するように構成される。例えば、0は、初期状態又は動作の完了を表し、かつ1は、機能を開始する必要があることを表す。
【0109】
【表6】
【0110】
このノードは、実行可能ノードであり、機能又は処理を停止するように構成される。例えば、0は、初期状態又は動作の完了を表し、かつ1は、機能又は処理を停止する必要があることを表す。
【0111】
開始及び停止ノードは、Runノード、Exitノードなどとも称される。特定の解釈又は実行が、端末のサービス機能モジュールによって成し遂げられる。
【0112】
【表7】
【0113】
このノードは、実行可能ノードであり、機能又は処理を削除するように構成される。例えば、0は、初期状態又は動作の完了を表し、かつ1は、機能を取り去らなければならないことを表す。
【0114】
【表8】
【0115】
このノードは、将来の拡張のための予備である。
【0116】
上記の実施形態において、開始ノード及び停止ノードは各サービス機能MOで定義されるが、機能の開始及び停止は、図11に示されるように、スケジューリングモードでこれらのノードを呼び出すことによって実行することもできる。特に、以下の2つの実行モードがある。
【0117】
モード1:通信端末は、端末機能を開始又は停止するための命令(指示)を含む所定のタスクを受信する。端末は、スケジューリングクライアント332を開始させるとともに、条件に合致したときに、DiagMonクライアント330のような、対応するDMサービス機能クライアントを呼び出す。指定された機能を開始又は停止するために、機能を開始又は停止するように構成された実行可能ノードが実行される。しかしながら、他のDMサービス機能クライアント334が、特定の制御指示に従って呼び出されてもよい。
【0118】
モード2:通信端末は、端末機能を開始又は停止するためのコード又は機能の一部を含む所定のタスクを受信する。端末は、スケジューリングクライアント332を開始させ、かつボトム−レイヤオペレーティングシステムは、条件に合致したときに、指定された機能を開始又は停止するために所定のタスク中のコード又は機能の一部を実行する。
【0119】
さらにまた、機能が開始される前の確認のためにユーザへの入力要求が必要かどうかをユーザが設定できるように、上記の実施形態に基づいて、インタフェースが提供される。例えば、ユーザは次のように設定する。サーバが機能を開始するための命令を最初に送信するときには、ユーザは確認の必要があるが、以後、その機能は、ユーザの確認無しに直接開始できる。故に、必要の無い確認が特定のアプリケーション環境では回避でき、ユーザ体験が向上する。
【0120】
本発明の第5実施形態に従って通信端末機能を中断又は再開するための方法が図12に示される。ここで、現在の端末で中断又は再開される必要のある機能は稼動状態にあると想定する。稼動状態にあるサービス機能の中断と再開との間の状態遷移が図13に示されており、2つの状態、すなわち、稼動状態及び中断状態が存在する。
【0121】
特に、中断動作は、機能が稼動状態にある場合のみ実行でき、それによって、機能は中断状態へ遷移する。再開動作は、機能が中断状態にある場合のみ実行でき、それによって、機能は稼動状態へ遷移する。
【0122】
ステップ1201からステップ1204は、ステップ401からステップ404と同一である。
【0123】
ステップ1205において、サービスサーバは、受信した指定された機能の現在の状態を解析するとともに、指定された機能を中断又は再開するための指示を端末へ送信するかどうかを決定する。中断動作は機能が稼動状態にある場合のみ、その機能に対して実行でき、かつ再開動作は機能が中断状態にある場合のみ、その機能に対して実行できるので、中断指示が送信されるときに指定された機能が稼動状態にある場合、又は再開指示が送信されるときに指定された機能が中断状態にある場合は、ステップ1206が実行され、そうでない場合は、手順は終了する。
【0124】
ステップ1206において、サービスサーバは、指定された機能を中断又は再開するための指示を含む中断要求又は再開要求を端末へ送信する。稼動状態にある指定された機能を中断することによって、機能によって占有されていた端末のCPUリソースを、それが機能を動作させるために必要で無いときに解放でき、それと同時に、端末の電気エネルギーを節約できる。
【0125】
ステップ1207において、DMサーバは、サービスサーバからの要求に従って、対応する中断又は再開命令を端末中のDMエージェントへ送信する。
【0126】
ステップ1208において、DMエージェントがDMサーバからDM命令を受信した後、端末のDMツリー中の機能を中断及び再開するノードが実行可能ノードである場合、DMエージェントは、DM命令に含まれた制御指示に従って、対応する実行可能ノードを直接トリガし、かつ指定された機能は、DMサービス機能クライアント中の許可モジュールによって中断又は再開される。端末のDMツリー中の機能を中断及び再開するノードが指示ノードである場合、DMエージェントは、DM命令中の指示に従って、対応する中断指示ノード又は再開指示ノードの値を修正し、ついで、端末は、指示ノードの値の変化を監視することによって、機能を相応に中断又は再開する。
【0127】
指定された機能が中断された場合、機能は、端末のCPUリソースを占有しないが、その他のリソースを占有し続ける。機能を再び動作させることが要求されるとき、機能の稼動状態は、機能によって占有されている端末のリソースが、CPUリソースを除けば解放されていないので、DMサーバを介して遠隔再開指示を送信することによって、すみやかに再開される。従って、ユーザ体験が向上する。
【0128】
ステップ1209及びステップ1210は、ステップ409及びステップ410と同一であるので、ここで繰り返して記載はしない。
【0129】
本発明の第6実施形態に従って機能を中断及び再開するためのシステムの構成が図14に示される。上記システムは、端末60、DMサービス機能サーバ7、及びサービスサーバ8を具備する。
【0130】
DMサービス機能サーバ7は、主にDMサーバ70を具備する。DMサーバは、管理命令を端末60へ送信するとともに、端末によって返されたメッセージを受信するように構成される。
【0131】
サービスサーバ8とサーバ7とは、WSIインタフェースを介して互いに情報をやりとりする。
【0132】
端末60は、機能モジュール61、DMエージェント62、DMサービス機能クライアント63、及びユーザインタフェース64を具備する。
【0133】
機能モジュール61は、機能及びその実行環境を提供するとともに、開始、停止、中断などの動作の実際の実行を制御する役目を果たす。実行環境は、Java(登録商標)又はローカルなアプリケーションプラットフォームであってよい。
【0134】
DMエージェント62は、DMエージェント62とDMサーバ70との間の基本DMプロトコルを解釈及び実行するとともに、動作、命令などを含む機能管理に関する制御指示を取得する役目を果たす。また、DMエージェント62は、DiagMon MOのようなDMツリーを維持する役目を果たす。機能ID、名称、動作のような診断機能の関連情報が、DiagMon管理ツリーに格納される。動作は、開始、停止、中断、再開などを含む。
【0135】
DMサービス機能クライアント63は、DMエージェント62が取得した制御指示に従って、指定された機能の動作状態を制御するように構成される。DMサービス機能クライアント63は、主に、状態問い合わせ許可モジュール6301と、開始/停止許可モジュール6302とを具備する。これらの機能は、第4実施形態の同名のモジュールと同一である。さらに、DMサービス機能クライアント63は、稼動状態にある機能の中断及び再開をサポートするように構成された中断/再開許可モジュール6303を具備する。
【0136】
ユーザインタフェース64は、ユーザに認証要求を送信するとともに、DMサービス機能クライアント63が制御命令を実行したときに、ユーザから認証承認を受け取るように構成される。
【0137】
DMエージェントは、DMツリーのノードを動作させることによって、DMサービス機能クライアントへ制御指示を提供する。図14に対応して、DMツリーは、機能を中断するノードと、機能を再開するノードとを有する。これら2つのノードが実行可能ノードである場合、実行可能ノードは、DMサーバによって送信されたDM命令に従って、DMエージェントによって機能を中断又は再開するために直接トリガされる。2つのノードが指示ノードであり、かつ状態値がその中に格納されている場合、DMエージェントは、DM命令中の指示に従って、指示ノードの値を修正し、かつ端末は、指示ノードの値の変化を監視するために、図14の破線部で示されたような状態監視モジュール65を用いるとともに、指示ノードの値の変化に従って、対応する中断又は再開動作を実行するように、DMサービス機能クライアントに通知する。状態監視モジュールは、ロジックモジュールであり、DMサービス機能クライアント63中の許可モジュールによって実行されてよく、又は外部機能若しくは他の許可構成要素によって実行されてもよい。
【0138】
DMツリーの部分的な構成が図15に示される。DMツリー中の中断動作又は再開動作を実行するノードが指示ノードである場合、解釈は以下のようになる。
【0139】
【表9】
【0140】
このノードは、機能又は処理を中断する動作を表すように構成される。例えば、0は、初期状態又は中断動作の完了を表し、かつ1は、機能又は処理を中断する必要があることを表す。
【0141】
【表10】
【0142】
このノードは、機能の再スタート、すなわち、再開動作を表す。例えば、0は、初期状態又は再開動作の完了を表し、かつ1は、機能を再開する必要があることを表す。
【0143】
さらに、動作命令のソース情報を格納する必要がある場合、情報は、<Exit>拡張ノードに、又はノードの属性に格納できる。
【0144】
DMツリーの構成は、先に記載された構成に限定されない。例えば、図16に示すように、開始ノードと停止ノードとが1つのノードに結合されてよく、かつ中断ノードと再開ノードとが1つのノードに結合されてもよい。開始/停止ノードに対しては、0は初期状態を表すために用いられ、1は機能又は処理の開始を表すために用いられ、2は機能又は処理の停止を表すために用いられ、かつ3は動作の完了を表すために用いられる。同様に、中断/再開ノードに対しては、0は初期状態を表すために用いられ、1は機能又は処理の中断を表すために用いられ、2は機能又は処理の再開を表すために用いられ、かつ3は動作の完了を表すために用いられる。
【0145】
別の実施形態におけるDMツリーの構成が図17に示される。葉ノードは、各ノードの状態と、ソースサーバの情報とを表す。フラグノードは、動作命令の状態を表すために用いられ、ソースノードは、動作命令がどのサーバから来たかなどといった動作命令のソースを表すために用いられる。DM命令を受信したとき、命令ソースの妥当性は、ソースノードの情報に従って判断される。
【0146】
上記の実施形態において、開始及び停止ノードと同様に、中断及び再開ノードもSCoMOで定義されている。これをここで繰り返し記載はしない。さらにまた、中断及び再開ノードは、他の複数の名称を持つ。
【0147】
さらなる利点及び修正が当業者によって容易に実現される。従って、より広い見地において、本発明は、明細書中に図示及び記載された特定の詳細及び代表的な実施形態に限定されない。故に、添付された特許請求の範囲及びそれらの均等物によって定義された本発明の精神又は範囲から逸脱することなく、さまざまな修正及び変形がなされる。
【符号の説明】
【0148】
30 端末
31 機能モジュール
311 BCASTクライアント
312 PoCクライアント
32 DMエージェント
33 DMサービス機能クライアント
330 DiagMonクライアント(DMサービス機能クライアント)
3301 状態問い合わせモジュール
3302 開始/停止許可モジュール
331、334 その他のDMサービス機能クライアント
332 スケジューリングクライアント(DMサービス機能クライアント)
34 ユーザインタフェース
35 状態監視モジュール
4 DMサービス機能(サーバ側)
40 DMサーバ
5 サービスサーバ
51 BCASTサーバ
52 PoCサーバ
【技術分野】
【0001】
本発明は、通信技術、特に、通信端末デバイスを管理するための方法、通信端末、及び通信システムに関する。
【背景技術】
【0002】
現在、中国における携帯電話ユーザの数は2億人に達しようとしている。ユーザの要求がますます多様化かつ個別化するにつれて、中国の遠隔通信の革新は一層高度化し、かつ固定電話及び携帯電話が再構築及び改良されるにつれ、サービス提供者は、BCAST(Broadcast)サービス、VoIP(Voice over Internet Protocol)サービス、PoC(Push-to-Talk Over Cellular)サービスなどといった、より多岐にわたるサービスをユーザへ提供し始めた。
【0003】
VoIPは、主にIP(Internet Protocol)電話を基盤として実現され、かつ対応する付加価値サービスを提供する技術である。VoIPを用いることで、バーチャルフォン、インターネットコール管理、テレビ会議、及びさまざま情報の格納及び送信といった、音声、FAX、映像、及びデータを含むサービス情報の転送がIPネットワーク上で安価に実現できる。
【0004】
移動端末(Mobile Terminal,MT)に適したVoIPシステムが、PoCサービスによって定義される。ワイヤレスデータネットワークのパケット交換機能を使用することで、PoCサービスは立地の制限を受けない。
【0005】
OMA(Open Mobile Alliance)は、PoCサービスの規格化に向けて作業を進めている。OMAのPoCソリューションは、インターネット技術タスクフォース(Internet Engineering Task Force,IETF)によって定義されたセッション確立プロトコル(Session Initiation Protocol,SIP)及びリアルタイム転送プロトコル(RealTime Transfer Protocol,RTP)に基づくものである。
【0006】
通信技術の発展と共に、ネットワークの規模はますます肥大化し、かつその構造もますます複雑化している。サービス品質(Quality of Service,QoS)の向上及び運用コストの削減のためには、効率的なネットワーク管理システムを構築する必要がある。結果として、遠隔通信管理ネットワーク(Telecommunication Management Network,TMN)が時勢の要望として現れた。
【0007】
TMNは、遠隔通信リソース、ネットワーク稼働率、サービス、及び管理を計画し、監視し、設計し、かつ制御するための方針及び方法を提供するとともに、オペレータ/マネージャ及び端末ユーザのために機能する遠隔通信ネットワークOAM(Operation Administration Maintenance)を備えたシステムを提供する。遠隔通信ネットワーク全体にわたって管理ネットワークを利用することによって、ネットワークリソースの全面的及び効率的な監視及び管理が実現できるだけでなく、複数の管理範囲にわたるサービスを開始できるように、ネットワークシステムを相互接続することもできる。
【0008】
TMNの実現は、2つの部分に分けられる。第1部分では、複数のサブネットワーク間でインタフェース通信が実現できるように、ネットワーク層より下位の遠隔通信リソースを監視及び制御するためのシステムが構築される。故に、ローカルネットワーク、アクセスネットワーク、及びSDH(Synchronous Digital Hierarchy)の透過的な制御及び監視が実現する。第2部分では、例えば、ユーザ管理、ネットワーク設備管理、労働力管理、請求、支払、及び会計管理、QoS及びネットワークパフォーマンス管理、トラフィック測定及び解析管理、保守管理、セキュリティ管理、ログ管理などの21世紀へ向けた管理サービスが開発されるように、遠隔通信ネットワークの意志決定サポートシステムがネットワーク層上に構築される。
【0009】
TMNシステム構成情報モデルの大部分は、階層構造ツリーを用いて、構成モデルの階層構造を記述する。それは、構成情報モデルツリーと称される。
【0010】
いわゆる情報モデルにおいて、ネットワークリソースは、管理の観点から運用される必要のある多数の小さな構成単位に分割される。ついで、これらの小さな構成単位は、複数の管理対象(Management Object,MO)を生成するために抽象化される。手短に言えば、情報モデルとは、ネットワーク管理システムによって運用されるリソースから抽象化されたMOの集合である。リソース管理は、これらのリソース抽象化エンティティ、すなわちMOを処理することによって間接的に実行される。MO交換情報を用いることによって管理動作を完遂するために、命令を発する責任があるマネージャと、命令を実行する責任があるエージェントとが必要とされる。命令を完遂するために、エージェントは、その名称、属性、従属関係などといった処理されるべき対象を知ってなくてはならない。このような情報のすべては、MIB(Manager Information Base)から得る。MIB中の情報は、規則に従って組織的に構成されている。情報モデルの方法を用いることによって、MIBは、ツリー構造が形成されるように、従属関係及び導出の規則に従って、トップからボトムへ抽象化されたMOを論理的に配置する。言い換えれば、検索を容易にする上記の情報モデルツリーが構築される。
【0011】
OMA DM(Device Management)規格において、端末を管理、診断、及び保守するためのTMN技術が計画され、かつサーバは、DM管理ツリーを介して、端末に対するファームウェアアップデート、アプリケーションダウンロード、診断及び監視、バックアップ及びリストアなどといった管理動作を実行できる。端末は、携帯電話、PDA(Personal Digital Assistant)、ノートブックコンピュータ、組込みデバイス、オンボードシステムなどである。
【0012】
現在のOMA DM規格は、ソフトウェアコンポーネント管理技術、すなわち、端末上のソフトウェアコンポーネントを管理するためのDMサーバに対するメカニズムを提供する。
【0013】
ソフトウェアコンポーネントは、実行可能アプリケーション、ダイナミックリンクライブラリ、ユーザインタフェース(User Interface,UI)などである。管理動作は、端末パラメータ設定、ファームウェアアップデート、エラー診断、バックアップ又はリストアのほかにも、ソフトウェアコンポーネントの問い合わせ、インストール、アップデート、アクティベーション、又は削除であってよい。
【0014】
DM規格によって表された全体の構成が、図1に示される。端末10上のDMエージェント11は、DMサーバ20によって発せられた管理命令を解釈及び実行するように構成される。端末に格納されたDM管理ツリー12は、DMサーバ20に対するインタフェースと見なすことができ、DMプロトコルを介して端末10を管理する。DM管理ツリー12は、いくつかの基本的なMOを含む。DMサーバ20は、MOに関する動作を介して端末10のリソースを制御する。例えば、ソフトウェアコンポーネントに関する管理は、端末10上のソフトウェアコンポーネント管理オブジェクト(Software Component Management Object,SCoMO)を追加、削除、及び修正することによって実行される。
【0015】
DM規格においてソフトウェアコンポーネントを管理するための方法が、図2に示される。
【0016】
ステップ201において、DMサーバは、端末に、インストールされたソフトウェアコンポーネントのインベントリの問い合わせを行う。
【0017】
ステップ202において、端末は、ユーザに認証を要求する。
【0018】
ステップ203において、ユーザは、認証を確認する。
【0019】
ステップ204において、端末は、ソフトウェアコンポーネントインベントリをDMサーバへ送信する。
【0020】
ステップ205において、DMサーバは、ソフトウェアコンポーネントの端末へのダウンロード及びインストール動作を開始する。
【0021】
ステップ206において、端末は、DMサーバに確認メッセージを返す。
【先行技術文献】
【特許文献】
【0022】
【特許文献1】国際公開第2006/006803号
【特許文献2】特開2005−244403号公報
【特許文献3】国際公開第2005/004395号
【非特許文献】
【0023】
【非特許文献1】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
【発明の概要】
【発明が解決しようとする課題】
【0024】
研究の間に、発明者は、上記のソリューションが以下の短所を有することに気づいた。すなわち、ソフトウェアコンポーネントの追加、削除、及び修正といった静的状態しか制御できない。四六時中ネットワーク側から配信されるサービスを効果的に受信するために、端末は、サービス受信部などのそのサービス機能を稼動状態に保たなければならない。受信するサービスがない場合、稼動状態にあるサービス機能は、対応するハードウェアリソースが電気エネルギーを不要に消費する原因となる。故に、通信端末の電力消費量が大きくなり、それと同時に、端末の中央演算ユニット(Central Processing Unit,CPU)などのリソースが占有される。結果的に、無駄が生じる。
【課題を解決するための手段】
【0025】
本発明の一実施形態は、通信端末デバイスを管理するための方法を提供する。上記方法は、指定された機能の動作状態に関する制御指示から成るデバイス管理命令を端末へ送信する段階と、制御指示に従って、指定された機能の動作状態に関する動作を端末で実行する段階とを有する。
【0026】
さらに、本発明の一実施形態は、対応する通信端末を提供する。上記端末は、機能を提供するように構成された機能モジュールと、指定された機能の動作状態に関する制御指示から成るデバイス管理命令を受信及び分解(resolve)するように構成されたデバイス管理エージェントと、制御指示に従って、指定された機能の動作状態に関する動作を実行するように構成されたデバイス管理サービス機能クライアントとを具備する。
【0027】
さらに、本発明の一実施形態は、通信システムを提供する。上記システムは、通信端末及びDMサーバを具備する。デバイス管理サーバは、指定された機能の稼動状態に関する制御指示から成るデバイス管理命令を通信端末へ送信するように構成される。通信端末は、制御指示に従って、指定された機能の動作状態に関する動作を実行するように構成される。
【発明の効果】
【0028】
本発明の技術的ソリューションでは、例えば、アプリケーションの開始、停止又は中断、及び再開の制御などのアプリケーションの動作状態を遠隔制御する機能を有することができるように、DM技術が強化されるということが、比較によって明らかとなった。
【0029】
サービスが正常に動作することを保証できるように、サービス実行より先に、サービスに関連するアプリケーションがあらかじめ端末上でDMサーバによって遠隔開始される。実行の必要があるサービスに間に合うように、関連するアプリケーションが起動されるので、アプリケーションが端末上で四六時中稼動する必要は無い。従って、端末の貴重な電気エネルギーを節約できる。
【0030】
また、サービスが実行されている場合、端末上で稼動しているサービスに関連するアプリケーションは、アプリケーションが稼動する必要の無いときに、アプリケーションによって占有される端末のCPUリソースを解放し、それと同時に、端末の電気エネルギーを節約できるように、DMサーバによって遠隔中断される。アプリケーションが再び稼動する必要のあるとき、CPUを除く、アプリケーションによって占有されたリソースは解放されていないので、アプリケーションの稼動状態は、DMサーバを介して遠隔再開指示を端末へ送信することによって迅速に再開される。結果的に、ユーザ体験が向上する。
【0031】
さらにまた、関連するアプリケーションが、サービスが実行されたときに、直ちに開始されるか、又は関連するサービス機能が、あらかじめ構築されたサービス配信プランに従って、所定のサービス配信時間に開始される。これら2つのモードを臨機応変に用いることによって、必要とされる異なるサービスがより良く手配できる。
【図面の簡単な説明】
【0032】
【図1】従来技術におけるOMA DM規格に記載された全体の構成を示す概略図である。
【図2】従来技術におけるOMA DM規格でのソフトウェアコンポーネント管理方法のフローチャートである。
【図3】サービス機能が本発明に従って開始又は停止される場合の状態遷移を示す概略図である。
【図4】本発明の第1実施形態に従って通信端末機能を開始又は停止するための方法のフローチャートである。
【図5】本発明の第2実施形態に従って通信端末機能を開始又は停止するための方法のフローチャートである。
【図6】本発明の第3実施形態に従って通信端末機能を開始又は停止するための方法のフローチャートである。
【図7】本発明の一実施形態による通信端末の構成図である。
【図8】本発明の第4実施形態に従って通信端末とサーバ側と間で通信を行うためのシステムの構成図である。
【図9】本発明の第4実施形態によるサービス機能管理システムの構成図である。
【図10】本発明の第4実施形態によるDMツリーの部分的な構成図である。
【図11】本発明の第4実施形態に従ってスケジューリング許可部を介して対応する機能を呼び出すことによって機能を開始又は停止するためのシステムの構成図である。
【図12】本発明の第5実施形態に従って通信端末機能を中断及び再開するための方法のフローチャートである。
【図13】本発明の第5実施形態による機能の中断と再開との間の状態遷移の概略図である。
【図14】本発明の第6実施形態に従って機能を中断又は再開するためのシステムの構成図である。
【図15】本発明の第6実施形態によるDMツリーの部分的な構成図である。
【図16】本発明の第6実施形態によるDMツリーの部分的な構成図である。
【図17】本発明の第6実施形態によるDMツリーの部分的な構成図である。
【発明を実施するための形態】
【0033】
本発明の目的、技術的解決策、及び利点をより明白にするために、これより、本発明を図面と併せてさらに詳細に記載する。
【0034】
本発明において、サービス提供者は、指定された機能の動作状態に関する制御指示を含むメッセージを端末へ送信する。端末は、メッセージに含まれた制御指示に従って、指定された機能に対応する制御動作を実行する。制御動作は、開始(start)、停止(stop)、中断(suspend)、再開(resume)などの動作を含む。
【0035】
本明細書中のいわゆる機能は、一般的な表現であり、端末の実行環境で実行可能なソフトウェア、プログラムの一部、プロシージャ、(XMLのような)スクリプト言語の一部などであってよい。例えば、機能は、診断処理、トラップ機能、又はスケジューリングコンポーネントなどであってもよい。
【0036】
本発明の実施形態における機能の状態遷移が、図3に示される。それは、停止状態及び稼動状態の2つの状態を有する。機能が停止状態にある場合のみ、機能に対する開始動作を実行でき、かつ機能が稼動状態にある場合のみ、機能に対する停止動作を実行できる。
【0037】
さらにまた、サービス提供者は、DMサーバを介して、指定された機能を中断又は再開するための指示を含むメッセージを端末へ送信する。端末は、メッセージに含まれた指示に従って、指定された機能を中断又は再開する。機能が稼動状態にある場合のみ、中断動作を実行できる。
【0038】
本発明の第1実施形態に従って通信端末機能を開始又は停止するための方法が、図4に示される。ここで、現在の端末で開始される必要のある診断機能は停止状態にあると想定する。
【0039】
ステップ401において、端末のためにサービスを実行する必要がある場合、まず、サービス提供者は、DMサーバに問い合わせ要求を依頼する。例えば、ネットワーク側のサービスサーバは、端末上のサービス機能が開始されたかどうか、すなわち、機能が稼動状態にあるかどうかを問合せるように、DMサーバに指示する。
【0040】
特に、問い合わせの主な命令は、以下の通りである。
<Get>
<Item>
<Target>
<LocURI>./Diagnostic Function/StateValue(./BCAST client/state value)</LocURI>
</Target>
</Item>
</Get>
【0041】
ステップ402において、DMサーバは、デバイス管理命令を発行するとともに、端末に機能の現在状態を問い合わせる。DMサーバ及び端末のDMエージェントは、標準OMA DMプロトコルを介して互いに情報をやりとりする。
【0042】
ステップ403において、端末は以下の問い合わせ結果を返す。
<Results>
<Item>
<Source>
<LocURI>./Diagnostic Function/StateValue</LocURI>
</Source>
<Data>Stopped</Data>
</Item>
</Results>
【0043】
ここで、取得した結果は機能が停止状態にあることだと想定する。
【0044】
ステップ404において、DMサーバは、サービスサーバに問い合わせ結果を返す。
【0045】
ステップ405において、問い合わせ結果に従って、開始する必要のあるサービス機能が開始されていない場合、サービスサーバは、DMサーバへメッセージを送信するとともに、メッセージ中の機能を開始するための動作指示を配信する。
【0046】
ステップ406において、DMサーバは、端末のDMエージェントへメッセージを転送するとともに、端末上の診断機能を開始するために、以下の管理命令を発行する。
<Exec>
<item>
<Target>
<LocURI>./Diagnostic Function/Operations/Start</LocURI>
</Target>
</Item>
</Exec>
【0047】
ステップ407において、DM命令を受信した後、DMエージェントは、DM命令のソースが妥当なものであるかどうかを判断する。妥当である場合、DMエージェントは、メッセージを解釈するとともに、メッセージに含まれた動作指示を取得する。そうでない場合、DMエージェントは、DM命令を棄却する。
【0048】
セキュリティ、プライバシーなどの問題に関しては、DMエージェントは、動作指示に従って、端末のUIを介してユーザへ問い合わせメッセージをさらに送信するとともに、サービスを受け入れるかどうかを判断するように、ユーザに要求する。
【0049】
ユーザがサービスについて省略時(default)動作を設定していた場合、DMエージェントは、ユーザからの確認メッセージを取得する過程を実行する必要は無い。その代わりに、DMエージェントは、設定された省略時動作に従って、DMサーバによって直接発行された命令を処理し、ついでステップ409へ進む。
【0050】
ステップ408において、ユーザは、UIを介してサービスを確認する。ユーザがサービスの受け入れを望まない場合、又はサービスを受け入れることがユーザにとって都合が悪い場合、ユーザは、取り消し動作を実行する。ユーザがサービスを受け入れる場合、承認動作が実行される。ユーザが取り消し動作の実行も承認動作の実行も行わない場合、省略時処理モードが設定されてよい。例えば、ユーザがサービスを棄却するとみなされる。
【0051】
例えば、ユーザがサービスを受け入れることを示す確認メッセージ(受理又は棄却)は、端末のUIを介してDMエージェントへ返される。
【0052】
上記のステップ407及びステップ408は任意に選択できる。ユーザは、端末でのユーザ確認をトリガするためのポリシをあらかじめ設定できる。例えば、サーバが機能を制御するための命令を初めて送信したときには、ユーザの確認を必要とするが、以後、サーバは機能を直接制御するための命令を送信できる。
【0053】
ステップ409において、端末は、DMサーバによって送信された命令を実行するとともに、ユーザ承認に基づいたサービスの機能を開始する。DMツリーは、端末に格納されてよい。DMツリーは、機能を開始するノードと、機能を停止するノードとを有する。2つのノードがどちらも実行可能ノードである場合、DMエージェントは、DMサービス機能クライアントの許可モジュールを介して、指定された機能の対応する開始又は停止動作を実行するために、DMサーバによって送信された命令に含まれた制御指示に従って、対応する実行可能ノードを直接トリガする。2つのノードがどちらもDMツリー中の指示ノードである場合、DMエージェントは、DMサーバによって送信された命令中の指示に従って、対応する指示ノードの値を修正し、かつ端末は、指示ノードの値の変化を監視することによって、指定された機能の対応する開始又は停止動作を実行する。
【0054】
対応する開始(又は停止)動作が実行された後、動作結果がDMサーバに報告される。
<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>
【0055】
ユーザが判断に従ってサービスを棄却した場合、DMサーバは、サービス要求を終了するために通知を受ける。
【0056】
ステップ410において、DMサーバは、動作結果をサービスサーバに通知する。
【0057】
ステップ411において、受信した動作結果が、端末サービスが開始されていることを示す場合、サービスサーバは、端末との接続を確立するとともに、端末へのサービスの配信又はサービスの管理を開始する。返された動作結果が、端末サービスが停止中であることを示す場合、端末との接続は切断され、かつ端末に対するサービスの配信又は管理動作は停止される。
【0058】
上記の方法に従って、関連する機能は、実行する必要のあるサービスより先に開始される。機能はもはや端末上で四六時中稼動する必要はなく、端末の貴重な電気エネルギーを節約できる。さらに、遠隔で開始又は停止される機能は診断機能であってよく、それによって、ネットワーク側は、他の機能は通常のものであるのかどうか、指定された機能の状態などといった情報を取得できる。故に、端末の稼動状態が、臨機応変に監視できる。
【0059】
本発明の第2実施形態に従って通信端末機能を開始又は停止するための方法が、図5に示される。ここで、現在の端末で開始する必要のある機能は稼動状態にあり、かつネットワーク側がサービスサーバを介してサービスを制御すると想定する。この実施形態と先の実施形態との間の主な差異は、サービスサーバが制御指示を送信する前に、端末中の指定された機能の動作状態が問い合わせを受けないことにある。代わりに、制御指示は、現在のサービスによって問い合わせられたものとして直接送信され、かつ端末は、指定された機能の現在の動作状態に従って、制御指示の実行又は無視を決定する。この実施形態においては、一例として、DMサーバが開始指示を送信する場合に行われる。他の指示も同様である。
【0060】
ステップ501において、サービスサーバは、サービスに必要な機能の開始指示をDMサーバへ送信する。
【0061】
ステップ502からステップ504は、ステップ406からステップ408とそれぞれ同一である。
【0062】
ステップ505において、ユーザ承認を得た後、DMエージェントは、端末中の指定された機能の状態に従って、開始指示を実行又は無視する。例えば、指定された機能が稼動状態にある場合、DM命令中の指定された機能を開始するための指示は無視される。
【0063】
端末中の指定された機能が非稼動状態にある場合、DM命令中の指定された機能を開始するための指示は実行される。
【0064】
ついで、動作結果、すなわち、現在、機能は稼動状態にあるということが、DMサーバへ報告される。さらに、ユーザ確認メッセージが棄却である場合、DMサーバは、サービス要求を終了させるために通知を受ける。
【0065】
ステップ506及びステップ507は、ステップ410及びステップ411とそれぞれ同一であるので、ここで繰り返して記載はしない。
【0066】
本発明の第3実施形態に従って通信端末機能を開始又は停止するための方法が図6に示される。この実施形態において、現在の端末で開始する必要のある機能は停止状態にあると想定する。
【0067】
ステップ601において、サービスサーバは、サービス配信プラン又はサービス管理プランを作成する。プランは、時刻に基づいている。例えば、BCASTサーバは、タイムテーブルに従って、毎日10:00〜11:00と16:00〜17:00とに、端末にサービスをブロードキャストするとともに、タイムテーブル中の時間枠に従って、BCASTクライアントを開始するように、端末に指示を行う。また、プランは、端末上のイベントに基づいている。例えば、端末は、機能の自動更新が完了したときに機能を自動的に停止するように指示される。
【0068】
ついで、サービスサーバは、DMサーバのウェブサービスインタフェース(Web Service Interface,WSI)を介してDMサーバへサービス配信プランを提示する。サービス配信プランは、機能ID、時間又は条件などを含む。
【0069】
ステップ602において、DMサーバは、サービスサーバによって提示されたサービス配信プランに従って、スケジューリングを生成する。スケジューリングは、トリガ条件及び所定の動作を含む。例えば、トリガ条件は、10:00 AMであり、かつ所定の動作は、クライアント上のBCAST機能を開始することである。
【0070】
ついで、DMサーバは、標準OMA DMプロトコルを介して端末のDMエージェントへ生成されたスケジューリングを送信する。
【0071】
ステップ603において、DMエージェントは、端末のUIを介して、スケジューリングを導入するのかどうかの判断をユーザに要求する。
【0072】
ユーザがサービスに対して省略時動作を設定する場合、DMエージェントは、ユーザ確認を必要とせずに、省略時動作に従ってスケジューリングを直接処理し、かつステップ606へ進む。
【0073】
ステップ604において、ユーザは、UIを介してスケジューリングを確認する。ユーザがサービスの受け入れを望まない場合、又はサービスの受け入れがユーザにとって都合が悪い場合、ユーザは、取り消し動作を実行する。ユーザがサービスを受け入れる場合、ユーザは、承認動作を実行する。ユーザが取り消し動作の実行も承認動作の実行も行わない場合、省略時処理が実行されてよい。例えば、ユーザがサービスを棄却するとみなされる。
【0074】
例えば、ユーザがサービスを受け入れることを示す確認メッセージ(受理又は棄却)は、端末のUIを介してDMエージェントへ返される。
【0075】
さらにまた、ユーザは、UIを介してスケジューリングを修正できる。例えば、ユーザは、ブロードキャストが10:00〜11:00の時間枠のみで受信されるように、タイムテーブルを修正できる。
【0076】
DMエージェントは、スケジューリングを導入するように端末に指示するとともに、ユーザの承認又は修正に従って、スケジューリングを実行する。ユーザ確認メッセージが導入棄却である場合、スケジューリングは取り消される。
【0077】
ステップ605において、スケジューリングのトリガ条件に合致した場合、例えば、時刻が10:00に達したか、又は機能更新が完了した場合に、ユーザは、スケジューリングに対応する機能の開始又は停止動作を実行するかどうか、例えば、ブロードキャストサービスの受信を開始するかどうかの確認を要求される。
【0078】
しかしながら、また、省略時動作が設定されていれば、ユーザの確認を要求することなく、省略時動作が適宜に実行される。
【0079】
ステップ606は、ステップ408と同一である。
【0080】
ステップ607において、DMエージェントは、ユーザ承認に基づくスケジューリング中の所定の動作を実行し、現在稼動状態にある機能を開始(又は、機能を停止、例えば、DMエージェントが11:00に停止動作を実行)し、かつ動作結果をDMサーバへ返す。
【0081】
端末が開始(又は停止)動作を実行するときに、機能が稼動状態にある場合、DM命令中の開始(停止)指示は無視される。
【0082】
ステップ608は、ステップ410と同一であるので、ここで繰り返して記載はしない。
【0083】
ステップ609において、サービスサーバは、端末との接続を確立するとともに、返された動作結果が開始である場合に、サービス配信又はサービス管理を開始する。返された動作結果が停止である場合、端末との接続は切断され、かつ端末に対するサービス又は管理動作は停止される。
【0084】
関連するサービス機能は、サービスが実行されたときに直ちに開始されてよく、又はあらかじめ構築されたサービス開始プランに従って、所定のサービス開始時刻に開始されてもよい。これら2つのモードを臨機応変に用いることによって、異なるサービスの要求により良く対処できる。
【0085】
本発明の第4実施形態による通信端末の構成が図7に示される。通信端末は、1つ以上の機能モジュール31と、DMエージェント32と、1つ以上のDMサービス機能クライアント33とを具備する。機能モジュール31は、さまざまなサービスを実行する機能を提供するように構成される。DMエージェント32は、ネットワーク側のDMサーバからデバイス管理命令を受信及び分解して、対応する制御指示を取得し、ついでDMツリーを動作させ、かつ維持するように構成される。DMサービス機能クライアント33は、DMエージェント32で取得した制御指示に従って、指定された機能の動作状態に関する対応する制御動作を実行するように構成される。
【0086】
BCASTサービス及びPoCサービスの機能の一例として、通信端末30、DMサーバ40、及びサービスサーバの間で通信を行うためのシステムの構成が図8に示される。BCASTサービスの機能モジュールは、BCASTクライアント311として構成され、PoCサービスの機能モジュールは、PoCクライアント312として構成され、かつサービスは、BCASTプロトコル及びPoCプロトコルをそれぞれ用いて、BCASTサーバ51及びPoCサーバ52によって配信される。DMエージェント32は、DMサービス機能クライアント33を介してサービスクライアントを管理する。特定のサービス機能に従って、DMサービス機能クライアントは、アプリケーション管理クライアント、診断及び監視(Diagnostic and Monitoring,DiagMon)クライアント、スケジューリングクライアントなどであってよい。
【0087】
図9は、DMサービス機能クライアントが特にDiagMonクライアントであるサービス機能管理システムの構成を表す。
【0088】
図9において、DMエージェント32は、DMサーバ40によって発行されたデバイス管理命令を解釈するとともに、その中の制御指示をDiagMonクライアント330へ提供する。
【0089】
DiagMonクライアント330は、主に以下のモジュールを具備する。
【0090】
状態問い合わせモジュール3301。これは、端末上の機能の状態を問い合わせるためにDMサーバ40をサポートするように構成される。
【0091】
開始/停止許可モジュール3302。これは、ソフトウェアの開始及び停止をサポートするように構成される。端末は、DMサーバ40によって送信された命令を受信した後に、開始/停止許可モジュールを介して関連する実行可能ノードを制御することによって機能の開始及び停止を実現する。開始/停止許可モジュールは、ロジック機能モジュールであり、DMサービス機能クライアントに、又はその他の位置にあってよい。
【0092】
DMサービス機能サーバ4は、主にDMサーバ40を具備する。DMサーバは、管理指示を端末へ送信するとともに、端末によって返されたメッセージを受信する。
【0093】
サービスサーバ5とサーバ4とは、WSIインタフェースを介して互いに情報をやりとりする。
【0094】
ユーザインタフェース34は、ユーザに認証要求を送信するとともに、DiagMonクライアント330が制御指示を実行したときに、ユーザから認証を受け取るように構成される。
【0095】
また、DiagMonクライアント330は、アプリケーション管理クライアント、スケジューリングクライアントなどといったその他のDMサービス機能クライアント331と情報をやりとりしてもよい。
【0096】
DMエージェントは、DMツリーのノードを動作させることによって、DMサービス機能クライアントへ制御指示を提供する。図9に対応して、DMツリーは、機能を開始するノード及び機能を停止するノードを有する。これら2つのノードが実行可能ノードである場合、実行可能ノードは、DMサーバによって送信されたDM命令を介して、機能の開始又は停止動作を実行するために直接トリガされる。2つのノードが指示ノードである場合、DMエージェントは、DM命令中の指示に従って、指示ノードの値を修正し、かつ端末は、指示ノードの値の変化を監視するために、図9の破線部で示すような状態監視モジュール35を用いるとともに、指示ノードの値の変化に従って、対応する開始又は停止動作を実行するために、DMサービス機能クライアントに通知を行う。DMツリーの部分的な構成が図10に示される。
【0097】
【表1】
【0098】
<Interior Node>は、内部ノードを意味し、サービス機能MOのルートノードである。MOは、ScoMO、DiagMon Mo、スケジューリングMO又はアプリケーション管理MOなどであってよい。
【0099】
<x>は置換子(placeholder)であり、特定の情報と、導入された機能の関連する実行可能動作とが、このノード下に格納される。
【0100】
便宜上、以下の記載においては、<Interior Node/x>は<./x>に置き換えられる。
【0101】
【表2】
【0102】
ソフトウェアIDは、このノードに格納される。
【0103】
【表3】
【0104】
このノードは、ソフトウェアの状態を表す。ノードの値は、以下のようになる。
【0105】
【表4】
【0106】
このノードは、一連の実行可能ノードの親ノードである。
【0107】
【表5】
【0108】
このノードは、実行可能ノードであり、機能又は処理を開始するように構成される。例えば、0は、初期状態又は動作の完了を表し、かつ1は、機能を開始する必要があることを表す。
【0109】
【表6】
【0110】
このノードは、実行可能ノードであり、機能又は処理を停止するように構成される。例えば、0は、初期状態又は動作の完了を表し、かつ1は、機能又は処理を停止する必要があることを表す。
【0111】
開始及び停止ノードは、Runノード、Exitノードなどとも称される。特定の解釈又は実行が、端末のサービス機能モジュールによって成し遂げられる。
【0112】
【表7】
【0113】
このノードは、実行可能ノードであり、機能又は処理を削除するように構成される。例えば、0は、初期状態又は動作の完了を表し、かつ1は、機能を取り去らなければならないことを表す。
【0114】
【表8】
【0115】
このノードは、将来の拡張のための予備である。
【0116】
上記の実施形態において、開始ノード及び停止ノードは各サービス機能MOで定義されるが、機能の開始及び停止は、図11に示されるように、スケジューリングモードでこれらのノードを呼び出すことによって実行することもできる。特に、以下の2つの実行モードがある。
【0117】
モード1:通信端末は、端末機能を開始又は停止するための命令(指示)を含む所定のタスクを受信する。端末は、スケジューリングクライアント332を開始させるとともに、条件に合致したときに、DiagMonクライアント330のような、対応するDMサービス機能クライアントを呼び出す。指定された機能を開始又は停止するために、機能を開始又は停止するように構成された実行可能ノードが実行される。しかしながら、他のDMサービス機能クライアント334が、特定の制御指示に従って呼び出されてもよい。
【0118】
モード2:通信端末は、端末機能を開始又は停止するためのコード又は機能の一部を含む所定のタスクを受信する。端末は、スケジューリングクライアント332を開始させ、かつボトム−レイヤオペレーティングシステムは、条件に合致したときに、指定された機能を開始又は停止するために所定のタスク中のコード又は機能の一部を実行する。
【0119】
さらにまた、機能が開始される前の確認のためにユーザへの入力要求が必要かどうかをユーザが設定できるように、上記の実施形態に基づいて、インタフェースが提供される。例えば、ユーザは次のように設定する。サーバが機能を開始するための命令を最初に送信するときには、ユーザは確認の必要があるが、以後、その機能は、ユーザの確認無しに直接開始できる。故に、必要の無い確認が特定のアプリケーション環境では回避でき、ユーザ体験が向上する。
【0120】
本発明の第5実施形態に従って通信端末機能を中断又は再開するための方法が図12に示される。ここで、現在の端末で中断又は再開される必要のある機能は稼動状態にあると想定する。稼動状態にあるサービス機能の中断と再開との間の状態遷移が図13に示されており、2つの状態、すなわち、稼動状態及び中断状態が存在する。
【0121】
特に、中断動作は、機能が稼動状態にある場合のみ実行でき、それによって、機能は中断状態へ遷移する。再開動作は、機能が中断状態にある場合のみ実行でき、それによって、機能は稼動状態へ遷移する。
【0122】
ステップ1201からステップ1204は、ステップ401からステップ404と同一である。
【0123】
ステップ1205において、サービスサーバは、受信した指定された機能の現在の状態を解析するとともに、指定された機能を中断又は再開するための指示を端末へ送信するかどうかを決定する。中断動作は機能が稼動状態にある場合のみ、その機能に対して実行でき、かつ再開動作は機能が中断状態にある場合のみ、その機能に対して実行できるので、中断指示が送信されるときに指定された機能が稼動状態にある場合、又は再開指示が送信されるときに指定された機能が中断状態にある場合は、ステップ1206が実行され、そうでない場合は、手順は終了する。
【0124】
ステップ1206において、サービスサーバは、指定された機能を中断又は再開するための指示を含む中断要求又は再開要求を端末へ送信する。稼動状態にある指定された機能を中断することによって、機能によって占有されていた端末のCPUリソースを、それが機能を動作させるために必要で無いときに解放でき、それと同時に、端末の電気エネルギーを節約できる。
【0125】
ステップ1207において、DMサーバは、サービスサーバからの要求に従って、対応する中断又は再開命令を端末中のDMエージェントへ送信する。
【0126】
ステップ1208において、DMエージェントがDMサーバからDM命令を受信した後、端末のDMツリー中の機能を中断及び再開するノードが実行可能ノードである場合、DMエージェントは、DM命令に含まれた制御指示に従って、対応する実行可能ノードを直接トリガし、かつ指定された機能は、DMサービス機能クライアント中の許可モジュールによって中断又は再開される。端末のDMツリー中の機能を中断及び再開するノードが指示ノードである場合、DMエージェントは、DM命令中の指示に従って、対応する中断指示ノード又は再開指示ノードの値を修正し、ついで、端末は、指示ノードの値の変化を監視することによって、機能を相応に中断又は再開する。
【0127】
指定された機能が中断された場合、機能は、端末のCPUリソースを占有しないが、その他のリソースを占有し続ける。機能を再び動作させることが要求されるとき、機能の稼動状態は、機能によって占有されている端末のリソースが、CPUリソースを除けば解放されていないので、DMサーバを介して遠隔再開指示を送信することによって、すみやかに再開される。従って、ユーザ体験が向上する。
【0128】
ステップ1209及びステップ1210は、ステップ409及びステップ410と同一であるので、ここで繰り返して記載はしない。
【0129】
本発明の第6実施形態に従って機能を中断及び再開するためのシステムの構成が図14に示される。上記システムは、端末60、DMサービス機能サーバ7、及びサービスサーバ8を具備する。
【0130】
DMサービス機能サーバ7は、主にDMサーバ70を具備する。DMサーバは、管理命令を端末60へ送信するとともに、端末によって返されたメッセージを受信するように構成される。
【0131】
サービスサーバ8とサーバ7とは、WSIインタフェースを介して互いに情報をやりとりする。
【0132】
端末60は、機能モジュール61、DMエージェント62、DMサービス機能クライアント63、及びユーザインタフェース64を具備する。
【0133】
機能モジュール61は、機能及びその実行環境を提供するとともに、開始、停止、中断などの動作の実際の実行を制御する役目を果たす。実行環境は、Java(登録商標)又はローカルなアプリケーションプラットフォームであってよい。
【0134】
DMエージェント62は、DMエージェント62とDMサーバ70との間の基本DMプロトコルを解釈及び実行するとともに、動作、命令などを含む機能管理に関する制御指示を取得する役目を果たす。また、DMエージェント62は、DiagMon MOのようなDMツリーを維持する役目を果たす。機能ID、名称、動作のような診断機能の関連情報が、DiagMon管理ツリーに格納される。動作は、開始、停止、中断、再開などを含む。
【0135】
DMサービス機能クライアント63は、DMエージェント62が取得した制御指示に従って、指定された機能の動作状態を制御するように構成される。DMサービス機能クライアント63は、主に、状態問い合わせ許可モジュール6301と、開始/停止許可モジュール6302とを具備する。これらの機能は、第4実施形態の同名のモジュールと同一である。さらに、DMサービス機能クライアント63は、稼動状態にある機能の中断及び再開をサポートするように構成された中断/再開許可モジュール6303を具備する。
【0136】
ユーザインタフェース64は、ユーザに認証要求を送信するとともに、DMサービス機能クライアント63が制御命令を実行したときに、ユーザから認証承認を受け取るように構成される。
【0137】
DMエージェントは、DMツリーのノードを動作させることによって、DMサービス機能クライアントへ制御指示を提供する。図14に対応して、DMツリーは、機能を中断するノードと、機能を再開するノードとを有する。これら2つのノードが実行可能ノードである場合、実行可能ノードは、DMサーバによって送信されたDM命令に従って、DMエージェントによって機能を中断又は再開するために直接トリガされる。2つのノードが指示ノードであり、かつ状態値がその中に格納されている場合、DMエージェントは、DM命令中の指示に従って、指示ノードの値を修正し、かつ端末は、指示ノードの値の変化を監視するために、図14の破線部で示されたような状態監視モジュール65を用いるとともに、指示ノードの値の変化に従って、対応する中断又は再開動作を実行するように、DMサービス機能クライアントに通知する。状態監視モジュールは、ロジックモジュールであり、DMサービス機能クライアント63中の許可モジュールによって実行されてよく、又は外部機能若しくは他の許可構成要素によって実行されてもよい。
【0138】
DMツリーの部分的な構成が図15に示される。DMツリー中の中断動作又は再開動作を実行するノードが指示ノードである場合、解釈は以下のようになる。
【0139】
【表9】
【0140】
このノードは、機能又は処理を中断する動作を表すように構成される。例えば、0は、初期状態又は中断動作の完了を表し、かつ1は、機能又は処理を中断する必要があることを表す。
【0141】
【表10】
【0142】
このノードは、機能の再スタート、すなわち、再開動作を表す。例えば、0は、初期状態又は再開動作の完了を表し、かつ1は、機能を再開する必要があることを表す。
【0143】
さらに、動作命令のソース情報を格納する必要がある場合、情報は、<Exit>拡張ノードに、又はノードの属性に格納できる。
【0144】
DMツリーの構成は、先に記載された構成に限定されない。例えば、図16に示すように、開始ノードと停止ノードとが1つのノードに結合されてよく、かつ中断ノードと再開ノードとが1つのノードに結合されてもよい。開始/停止ノードに対しては、0は初期状態を表すために用いられ、1は機能又は処理の開始を表すために用いられ、2は機能又は処理の停止を表すために用いられ、かつ3は動作の完了を表すために用いられる。同様に、中断/再開ノードに対しては、0は初期状態を表すために用いられ、1は機能又は処理の中断を表すために用いられ、2は機能又は処理の再開を表すために用いられ、かつ3は動作の完了を表すために用いられる。
【0145】
別の実施形態におけるDMツリーの構成が図17に示される。葉ノードは、各ノードの状態と、ソースサーバの情報とを表す。フラグノードは、動作命令の状態を表すために用いられ、ソースノードは、動作命令がどのサーバから来たかなどといった動作命令のソースを表すために用いられる。DM命令を受信したとき、命令ソースの妥当性は、ソースノードの情報に従って判断される。
【0146】
上記の実施形態において、開始及び停止ノードと同様に、中断及び再開ノードもSCoMOで定義されている。これをここで繰り返し記載はしない。さらにまた、中断及び再開ノードは、他の複数の名称を持つ。
【0147】
さらなる利点及び修正が当業者によって容易に実現される。従って、より広い見地において、本発明は、明細書中に図示及び記載された特定の詳細及び代表的な実施形態に限定されない。故に、添付された特許請求の範囲及びそれらの均等物によって定義された本発明の精神又は範囲から逸脱することなく、さまざまな修正及び変形がなされる。
【符号の説明】
【0148】
30 端末
31 機能モジュール
311 BCASTクライアント
312 PoCクライアント
32 DMエージェント
33 DMサービス機能クライアント
330 DiagMonクライアント(DMサービス機能クライアント)
3301 状態問い合わせモジュール
3302 開始/停止許可モジュール
331、334 その他のDMサービス機能クライアント
332 スケジューリングクライアント(DMサービス機能クライアント)
34 ユーザインタフェース
35 状態監視モジュール
4 DMサービス機能(サーバ側)
40 DMサーバ
5 サービスサーバ
51 BCASTサーバ
52 PoCサーバ
【特許請求の範囲】
【請求項1】
管理ツリーノードを端末のデバイス管理ツリーに設定又は追加する段階であって、前記管理ツリーノードが指示ノードである、段階と、
指定された機能の動作状態に関する制御指示から成るデバイス管理命令を送信する段階であって、前記制御指示が前記端末の前記デバイス管理ツリーの前記指示ノードの値を修正することによる、段階と、
前記指示ノードの値の変化を前記端末によって監視するとともに、前記変化を前記指定された機能の実行環境に通知する段階と、
前記指示ノードの値の前記変化に従って、前記機能に関する動作を前記指定された機能の前記実行環境で実行する段階と
を有し、
前記指定された機能の前記動作状態は、稼動状態と非稼動状態とを含み、
前記制御指示は、前記端末中の前記指定された機能を開始又は停止するための指示を含むことを特徴とする通信端末デバイスを管理するための方法。
【請求項2】
前記方法は、
前記デバイス管理命令が前記端末へ送信される前に、前記指定された機能の現在の動作状態を前記端末に問い合わせるとともに、前記現在の動作状態をサービスサーバへ送信し、
前記指定された機能の前記現在の動作状態に従って、送信される前記デバイス管理命令中の前記制御指示を前記サービスサーバによって決定する段階、
及び/又は、
前記端末が前記動作を実行する前に、前記指定された機能の現在の動作状態を前記端末によって判断して、
非稼動状態にある前記指定された機能に応じて、前記指定された機能に関する開始動作を実行し、
稼動状態にある前記指定された機能に応じて、前記指定された機能に関する停止動作を実行し、
さもなければ、前記デバイス管理命令中の前記制御指示を無視する段階
をさらに有することを特徴とする請求項1に記載の通信端末デバイスを管理するための方法。
【請求項3】
前記制御指示は、前記指定された機能を中断又は再開するための指示をさらに含み、
前記制御指示に従って前記端末によって実行される、前記指定された機能の前記動作状態に関する前記動作は、前記端末中の前記指定された機能の中断又は再開から成ることを特徴とする請求項1に記載の通信端末デバイスを管理するための方法。
【請求項4】
前記機能の前記動作状態は、稼動状態と中断状態とをさらに含み、
前記方法は、
前記デバイス管理命令が前記端末へ送信される前に、前記指定された機能の現在の動作状態を前記端末に問い合わせるとともに、前記現在の動作状態をサービスサーバへ送信し、
前記指定された機能の前記現在の動作状態に従って、送信される前記デバイス管理命令中の前記制御指示を前記サービスサーバによって決定する段階、
及び/又は、
前記端末が前記動作を実行する前に、前記指定された機能の現在の動作状態を前記端末によって判断して、
稼動状態にある前記指定された機能に応じて、前記指定された機能に関する中断動作を実行し、
中断状態にある前記指定された機能に応じて、前記指定された機能に関する再開動作を実行し、
さもなければ、前記デバイス管理命令中の前記制御指示を無視する段階
をさらに有することを特徴とする請求項3に記載の通信端末デバイスを管理するための方法。
【請求項5】
前記制御指示は、所定の条件下で動作を実行するための指示であり、
前記制御指示に従って前記端末によって実行される前記動作は、前記制御指示中の前記所定の条件を保存することと、前記所定の条件に合致した場合に、前記制御指示に従って前記動作を実行することとから成ることを特徴とする請求項1に記載の通信端末デバイスを管理するための方法。
【請求項6】
所定の機能を提供するように構成された機能モジュールと、
指定された機能の動作状態に関する制御指示から成るデバイス管理命令を受信及び分解するように、かつ、デバイス管理ツリーを維持するとともに、前記デバイス管理命令に従って前記デバイス管理ツリーの管理ツリーノードを操作するように構成されたデバイス管理エージェントであって、前記管理ツリーノードが指示ノードであり、前記デバイス管理命令に従って前記デバイス管理ツリーの前記管理ツリーノードを操作することが前記指示ノードの値を変化させることである、デバイス管理エージェントと、
前記指示ノードの値の変化を監視するとともに、前記変化をデバイス管理サービス機能クライアントに通知するように構成された状態監視モジュールと、
前記指示ノードの値に従って、前記指定された機能の前記動作状態に関する動作を実行するように構成されたデバイス管理サービス機能クライアントと
を具備し、
前記指定された機能の前記動作状態は、稼動状態と非稼動状態とを含み、
前記制御指示は、前記端末中の前記指定された機能を開始又は停止するための指示を含むことを特徴とする通信端末。
【請求項7】
通信システムであって、
通信端末と、
前記通信端末との通信機能を有するデバイス管理サーバと
を具備し、
前記デバイス管理サーバは、指定された機能の動作状態に関する制御指示から成るデバイス管理命令を前記通信端末へ送信するように構成され、
前記通信端末は、
所定の機能を提供するように構成された機能モジュールと、
前記デバイス管理命令を受信及び分解するように、かつ、デバイス管理ツリーを維持するとともに、前記デバイス管理命令に従って前記デバイス管理ツリーの管理ツリーノードを操作するように構成されたデバイス管理エージェントであって、前記管理ツリーノードが指示ノードであり、前記デバイス管理命令に従って前記デバイス管理ツリーの前記管理ツリーノードを操作することが前記指示ノードの値を変化させることである、デバイス管理エージェントと、
前記指示ノードの値の変化を監視するとともに、前記変化をデバイス管理サービス機能クライアントに通知するように構成された状態監視モジュールと、
前記指示ノードの値に従って、前記指定された機能の前記動作状態に関する動作を実行するように構成されたデバイス管理サービス機能クライアントと
を具備し、
前記指定された機能の前記動作状態は、稼動状態と非稼動状態とを含み、
前記制御指示は、前記端末中の前記指定された機能を開始又は停止するための指示を含むことを特徴とする通信システム。
【請求項1】
管理ツリーノードを端末のデバイス管理ツリーに設定又は追加する段階であって、前記管理ツリーノードが指示ノードである、段階と、
指定された機能の動作状態に関する制御指示から成るデバイス管理命令を送信する段階であって、前記制御指示が前記端末の前記デバイス管理ツリーの前記指示ノードの値を修正することによる、段階と、
前記指示ノードの値の変化を前記端末によって監視するとともに、前記変化を前記指定された機能の実行環境に通知する段階と、
前記指示ノードの値の前記変化に従って、前記機能に関する動作を前記指定された機能の前記実行環境で実行する段階と
を有し、
前記指定された機能の前記動作状態は、稼動状態と非稼動状態とを含み、
前記制御指示は、前記端末中の前記指定された機能を開始又は停止するための指示を含むことを特徴とする通信端末デバイスを管理するための方法。
【請求項2】
前記方法は、
前記デバイス管理命令が前記端末へ送信される前に、前記指定された機能の現在の動作状態を前記端末に問い合わせるとともに、前記現在の動作状態をサービスサーバへ送信し、
前記指定された機能の前記現在の動作状態に従って、送信される前記デバイス管理命令中の前記制御指示を前記サービスサーバによって決定する段階、
及び/又は、
前記端末が前記動作を実行する前に、前記指定された機能の現在の動作状態を前記端末によって判断して、
非稼動状態にある前記指定された機能に応じて、前記指定された機能に関する開始動作を実行し、
稼動状態にある前記指定された機能に応じて、前記指定された機能に関する停止動作を実行し、
さもなければ、前記デバイス管理命令中の前記制御指示を無視する段階
をさらに有することを特徴とする請求項1に記載の通信端末デバイスを管理するための方法。
【請求項3】
前記制御指示は、前記指定された機能を中断又は再開するための指示をさらに含み、
前記制御指示に従って前記端末によって実行される、前記指定された機能の前記動作状態に関する前記動作は、前記端末中の前記指定された機能の中断又は再開から成ることを特徴とする請求項1に記載の通信端末デバイスを管理するための方法。
【請求項4】
前記機能の前記動作状態は、稼動状態と中断状態とをさらに含み、
前記方法は、
前記デバイス管理命令が前記端末へ送信される前に、前記指定された機能の現在の動作状態を前記端末に問い合わせるとともに、前記現在の動作状態をサービスサーバへ送信し、
前記指定された機能の前記現在の動作状態に従って、送信される前記デバイス管理命令中の前記制御指示を前記サービスサーバによって決定する段階、
及び/又は、
前記端末が前記動作を実行する前に、前記指定された機能の現在の動作状態を前記端末によって判断して、
稼動状態にある前記指定された機能に応じて、前記指定された機能に関する中断動作を実行し、
中断状態にある前記指定された機能に応じて、前記指定された機能に関する再開動作を実行し、
さもなければ、前記デバイス管理命令中の前記制御指示を無視する段階
をさらに有することを特徴とする請求項3に記載の通信端末デバイスを管理するための方法。
【請求項5】
前記制御指示は、所定の条件下で動作を実行するための指示であり、
前記制御指示に従って前記端末によって実行される前記動作は、前記制御指示中の前記所定の条件を保存することと、前記所定の条件に合致した場合に、前記制御指示に従って前記動作を実行することとから成ることを特徴とする請求項1に記載の通信端末デバイスを管理するための方法。
【請求項6】
所定の機能を提供するように構成された機能モジュールと、
指定された機能の動作状態に関する制御指示から成るデバイス管理命令を受信及び分解するように、かつ、デバイス管理ツリーを維持するとともに、前記デバイス管理命令に従って前記デバイス管理ツリーの管理ツリーノードを操作するように構成されたデバイス管理エージェントであって、前記管理ツリーノードが指示ノードであり、前記デバイス管理命令に従って前記デバイス管理ツリーの前記管理ツリーノードを操作することが前記指示ノードの値を変化させることである、デバイス管理エージェントと、
前記指示ノードの値の変化を監視するとともに、前記変化をデバイス管理サービス機能クライアントに通知するように構成された状態監視モジュールと、
前記指示ノードの値に従って、前記指定された機能の前記動作状態に関する動作を実行するように構成されたデバイス管理サービス機能クライアントと
を具備し、
前記指定された機能の前記動作状態は、稼動状態と非稼動状態とを含み、
前記制御指示は、前記端末中の前記指定された機能を開始又は停止するための指示を含むことを特徴とする通信端末。
【請求項7】
通信システムであって、
通信端末と、
前記通信端末との通信機能を有するデバイス管理サーバと
を具備し、
前記デバイス管理サーバは、指定された機能の動作状態に関する制御指示から成るデバイス管理命令を前記通信端末へ送信するように構成され、
前記通信端末は、
所定の機能を提供するように構成された機能モジュールと、
前記デバイス管理命令を受信及び分解するように、かつ、デバイス管理ツリーを維持するとともに、前記デバイス管理命令に従って前記デバイス管理ツリーの管理ツリーノードを操作するように構成されたデバイス管理エージェントであって、前記管理ツリーノードが指示ノードであり、前記デバイス管理命令に従って前記デバイス管理ツリーの前記管理ツリーノードを操作することが前記指示ノードの値を変化させることである、デバイス管理エージェントと、
前記指示ノードの値の変化を監視するとともに、前記変化をデバイス管理サービス機能クライアントに通知するように構成された状態監視モジュールと、
前記指示ノードの値に従って、前記指定された機能の前記動作状態に関する動作を実行するように構成されたデバイス管理サービス機能クライアントと
を具備し、
前記指定された機能の前記動作状態は、稼動状態と非稼動状態とを含み、
前記制御指示は、前記端末中の前記指定された機能を開始又は停止するための指示を含むことを特徴とする通信システム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【公開番号】特開2012−231540(P2012−231540A)
【公開日】平成24年11月22日(2012.11.22)
【国際特許分類】
【出願番号】特願2012−172716(P2012−172716)
【出願日】平成24年8月3日(2012.8.3)
【分割の表示】特願2008−551630(P2008−551630)の分割
【原出願日】平成19年1月8日(2007.1.8)
【出願人】(504277388)▲ホア▼▲ウェイ▼技術有限公司 (220)
【Fターム(参考)】
【公開日】平成24年11月22日(2012.11.22)
【国際特許分類】
【出願日】平成24年8月3日(2012.8.3)
【分割の表示】特願2008−551630(P2008−551630)の分割
【原出願日】平成19年1月8日(2007.1.8)
【出願人】(504277388)▲ホア▼▲ウェイ▼技術有限公司 (220)
【Fターム(参考)】
[ Back to top ]