JP2011530860A - インテリジェント移動体デバイス管理クライアント - Google Patents

Abstract

ＯＭＡ ＤＭ対応移動体クライアント・デバイスのためのインテリジェント・エージェントの実施形態。このインテリジェント・エージェントは、移動体クライアント・デバイスのＯＭＡ ＤＭ管理ツリーの１つ以上のモードに管理プロパティ値を格納するモジュールを含む。ワイヤレス・ネットワークを通じて移動体クライアント・デバイスに結合されたサーバ・コンピュータにおいて、管理値の一部を分析し設定する。インテリジェント移動体クライアントは、サーバによって供給される初期命令および方針に基づいて、それ自体を管理するように構成されている。初期命令および方針は、ＯＭＡ ＤＭプロトコルによってクライアントに送られる。インテリジェント・エージェントは、ノード厳格性値を表すステータス・プロパティ、および規則、動作プロパティ、およびしきい値から成るプロパティ・グループを含むように、１組の管理プロパティを定める。
【選択図】図１

Description

関連出願に対する相互引用
本願は、２００８年８月８日に出願し本発明と同じ譲受人に譲渡された"Managing and Enforcing Policies on Mobile Devices"（移動体デバイスに関する方針の管理および実施）と題する米国特許出願第１２／１８８，９３６号の一部継続出願である。
技術分野
遠隔通信デバイスに関する実施形態について記載する。更に特定すれば、地球規模のネットワークにおいて用いるためのインテリジェント移動体クライアント・デバイスに関する実施形態について記載する。

従来技術

典型的な移動体電話機の基本的機能は、単なる音声指向から複雑な機構や豊富なデータ集約アプリケーションをサポートすることができるものにまで、劇的な変化を遂げた。移動体デバイスの複雑化および能力向上というこの傾向は続き、生産およびサービスの改革において著しい増大を推進することが予期される。多くの観点において、移動体デバイスの管理は、旧来からの企業管理と非常に良く似ている。これは、移動体加入者に対して新たなデバイスおよびサービスを設定する能力であるプロビジョニング、新たな更新プログラムおよびデータの配信、構成設定および撤去を含むファームウェアおよびソフトウェアのライフサイクル管理、電話機構の遠隔診断、ソフトウェアおよびネットワークの接続(connectivity)、資産管理、報告およびその他の機構を含む。使い易さを確保するために、インテリジェント管理、予防的監視、および診断が、ワイヤレス／移動体運営業者には必要である。

本システム、ネットワーク、および企業管理の解決策は、通例、２つの主要な項目を定めるプロトコルに基づく。これら２つの主要な項目とは、マネージド・オブジェクトとその管理部との間において受け渡されるコンテンツを記述するＰＤＵ（プロトコル・データ・ユニット）、およびマネージド・オブジェクトの位置および構造を一意に記述するデータ・モデルである。移動体デバイスにとって、卓越した規格は、ＯＭＡ ＤＭ（Open Mobile Alliance's Device Management：オープン移動体連合のデバイス管理）規格である。通例、キャリア(carrier：電気通信事業者)は、ＭＤＭ（移動体デバイス管理）プラットフォームの１つ以上のインスタンスを運用して、関連する移動体デバイスを管理する。ＯＭＡ ＤＭプロトコルは、普及しているブラウザ−クライアント・ウェブ−サーバ相互作用モデルおよびＨＴＴＰトランスポート・メカニズムを利用する。管理プラットフォームとデバイスとの間における相互作用は、サーバ（管理プラットフォーム）またはクライアント（移動体デバイス）のいずれによってでも開始することができる。クライアントが開始した相互作用の後には、ウェブ・ブラウザがウェブ・サーバとのセッションを開始するという馴染みのあるパラダイムが続く。サーバが相互作用を開始したい場合、クライアントが再度ブラウザ状セッションをサーバと開始することができるように、クライアントに通知することによって開始しなければならない。このサーバ−クライアント通知は、ＳＭＳ（ショート・メッセージ・サービス）通信チャネル・テキスト・メッセージを通じて伝えられる。このＳＭＳ通信チャネル・テキスト・メッセージは、移動体デバイスによって特別に認識され、ＯＭＡ ＤＭクライアント・ソフトウェアに導かれ、サーバとのセッションを確立できるようになっている。一旦ＳＭＳ型通知が受信されると、クライアント−サーバセッションが確立され、クライアントが開始する相互作用と同様に進められる。

ＭＤＭシステムにおいては、リモート・デバイスを複数の異なる方法で制御することができる。制御には、使用制御および動作制御という、２つの基本的次元がある。使用制御とは、デバイスに利用可能であり、そこで実行されるまたはそれによってアクセスされるアプリケーションおよびサービスに対する制御に関する。使用制御の例には、サービス運営業者がある種のアプリケーションの使用を制限し、支払いが済んでいるアプリケーションのみが所与のデバイスにおいて使用できるようにすること、加入者である親（マスタ加入者(master subscriber)と呼ぶ）が、彼らの子供が学校にいる間は、音楽プレーヤまたはゲーム・アプリケーションを彼らのセル・フォンでは使用しないことを確保すること、あるいは企業がその従業員に、彼らが重役会議室にいるときには、呼び出し音を出すのではなく、振動するように指示すること、ならびに他の同様なアプリケーション制御が含まれる。動作制御とは、デバイス自体ならびに、電源、入力／出力、および送受信回路というようなデバイスの種々のハードウェア・エレメントの動作に関する。動作制御の例には、バッテリの残量が少なくなってきた場合にデバイスの電力消費を制限すること、干渉が検出された場合無線感度を高めること、ノイズが多い環境ではスピーカの音量を増大すること、およびその他の同様な動作特性が含まれる。

現在では、移動体デバイスは殆どユーザだけによって制御されている。即ち、ユーザは、呼び出し音モード、スピーカ音量、キーパッド構成等のような動作設定値を手動で設定または変更しなければならない。使用制御に関して、サービス・プロバイダは、一般に、リモート・デバイスにおけるある種の機能をイネーブルまたはディスエーブルすることができるが、制御は単純なオン／オフ設定に制限されるのが一般である。現在のデバイスは、当該デバイスの動的特性または動作特性に基づく使用制御をサポートしない。その結果、このような制御にはユーザの設定(configuration)が必要になる。つまり、使用方針または規則を実施するためには、あるいはある種の動作特性を設定するためには、比較的高いレベルのユーザ入力が必要となる。したがって、現在の移動体デバイスは、受動デバイスであり、重要な自動動作ができず、逆にサービス・プロバイダおよびユーザによる能動的な監視および構成設定が必要となる。

場合によっては、サーバが標準的な管理プロトコルを用いて、移動体クライアントの管理プロパティ値(property values)を引き出し、分析し、設定することができる。管理プロパティ値は、デバイス管理ツリーのような、既知の構造の中に格納することができる。このようなサーバ主導管理は強制的なチャネルを表すが、サーバが移動体クライアントについて管理判断を下すことを主要な役割とするコンポーネントになることを意味する。このような既存の管理パラダイムは、したがって、予防的ではなく反応的と見なすことができる。何故なら、管理および監視は、問題が消費者によって報告された後に行われるからである。

したがって、移動体デバイスの自律制御および動作に対処する、移動体デバイス方針配信および実施システムが求められている。

更に、移動体デバイスにおいて検知される動作および使用状態に基づいて、移動体デバイスの管理を容易にする移動体デバイス存在管理フレームワークも求められている。

添付図面の図において、本発明の実施形態を、限定ではなく一例として図示する。図面において、同様の参照番号は同様の要素を示すものとする。
図１は、インテリジェント移動体クライアントのための移動体方針管理システムの１つ以上の実施形態を実現するコンピュータ・ネットワーク・システムを示す。 図２は、一実施形態の下において、インテリジェント移動体クライアントと共に用いるための動作規則集のコンポーネントを示す。 図３は、一実施形態の下において、クライアント側方針管理プロセスの全体的アーキテクチャ体系を示す。 図４Ａは、一実施形態の下において動作規則を登録するステップを示す。 図４Ｂは、一実施形態の下において動作規則を評価するステップを示す。 図５は、一実施形態の下において、インテリジェント移動体クライアントのクライアント側アーキテクチャを定めるコンポーネントのＵＭＬ図を示す。 図６は、一実施形態の下において、マネージド遠隔クライアント・デバイスと共に用いるためのＭＤＭサーバを示す。 図７は、一実施形態の下における、ＭＤＭプラットフォームとＯＭＡ ＤＭ対応移動体デバイスとの間の移動体デバイス管理のためのシステムを示す。 図８は、一実施形態の下における、移動体クライアント・デバイスのＯＭＡＤＭ管理ツリーの一例を示す。 図９は、一実施形態の下において、アラーム通知およびアラーム引き出し(alarm retrieval)をインテリジェント・エージェントに供給するシステムを示すブロック図である。

本明細書に記載する本発明の実施形態は、先に述べたような従来の方法の問題に対する解決策を提案する。以下の説明では、例示のために種々の例を示すが、限定を意図するものは何もない。大規模分散型ネットワークにおいて用いるためのインテリジェント移動体クライアントの実施形態について説明する。インテリジェント移動体クライアントは、ＯＭＡ ＤＭ対応移動体クライアント・デバイスとすることができる。クライアントのインテリジェント・エージェントは、移動体クライアント・デバイスのＯＭＡ ＤＭ管理ツリーの１つ以上のノードに管理プロパティ値を格納するモジュールを含む。ワイヤレス・ネットワークによって移動体クライアント・デバイスに結合されているサーバ・コンピュータにおいて、管理値のうち少なくとも一部を分析し、設定する。インテリジェント移動体クライアントは、サーバによって供給され、ＯＭＡ ＤＭプロトコルによってクライアントに送られる初期命令および方針に基づいて、それ自体を管理するように構成されている。例えば、クライアントは、バッテリがほぼ空であることに気付くこともでき、したがって自動的にそれ自体のバックライト照明レベルを低下させる。

本明細書において記載する１つ以上の実施形態の態様は、ソフトウェア命令を実行する１つ以上のコンピュータにおいて実現することができる。これらのコンピュータをネットワーク状に接続し、クライアント−サーバ構成または同様の分散型コンピュータ・ネットワークとすることができる。図１は、移動体方針管理システムの１つ以上の実施形態を実現するコンピュータ・ネットワーク・システム１００を示す。システム１００において、ネットワーク・サーバ・コンピュータ１０４が、直接または間接的に、１つ以上のネットワーク・クライアント・コンピュータ１０２および１１８にネットワーク１１０を通じて結合されており、更にセルラ電話ネットワーク１１１のような１つ以上の可能な他のネットワークにも結合されている。サーバ・コンピュータ１０４とクライアント・コンピュータ１０２との間にあるネットワーク・インターフェースは、サーバとクライアント・コンピュータとの間で送信されるデータをバッファしルーティングする役割を果たす１つ以上のルータを含むことができる。ネットワーク１１０は、インターネット、ワイド・エリア・ネットワーク（ＷＡＮ）、ローカル・エリア・ネットワーク（ＬＡＮ）、またはその任意の組み合わせとすることができる。

一実施形態では、ネットワーク・システム１００におけるサーバ１０４は、サーバ側移動体デバイス方針実施プロセス１１２を実行するサーバである。このプロセスは、１つ以上の実行可能プログラム・モジュールを表すことができ、ネットワーク・サーバ１０４内に格納され、このサーバ内においてローカルに実行される。しかしながら、代わりに、サーバ１０４またはネットワーク１１０に結合されサーバ１０４によってアクセスされるリモート・ストレージまたは処理デバイスに格納し、ローカルに実行することもできる。更に別の代替実施形態では、方針管理プロセス１１２は、複数の異なるプログラム・モジュールに実装することもできる。これらのプログラム・モジュールの各々は、互いに結合されているまたはネットワーク１１０に別々に結合されている２つ以上の分散型サーバ・コンピュータによって実行することができる。サーバおよびクライアント・コンピュータは、専用アプリケーション・プログラムおよびＡＰＩ（アプリケーション・プログラム・インターフェース）通信体系を用いることもできる。

一実施形態では、クライアント・デバイス１０２はクライアント側方針管理システムを実行して、サーバ側方針管理プロセス１１２と相互作用し、デバイスの自律制御を可能にする。管理値のうち少なくとも一部は、ワイヤレス・ネットワークを通じて移動体クライアント・デバイスに結合されているサーバ・コンピュータにおいて分析され格納される。インテリジェント移動体クライアント１０２は、サーバによって供給され、リモート・デバイス管理に最適化された既定のネットワーク・プロトコルを用いることによって、クライアントに送られる初期命令および方針に基づいて、それ自体を管理するように構成されている。別のコンテンツ・プロバイダ１０３が、方針管理プロセスに含まれるデータの一部を供給することができる。方針、業務規則等のうち任意のもののデータは、サーバ１０４および／またはクライアント１０２のうち任意のものに密にまたは疎に結合されているデータ・ストア１２０によって供給することができる。

クライアント・デバイスは、通例、通信、娯楽、ナビゲーション、情報管理、および基本計算機能というような種々のユーティリティを提供する移動体クライアント・デバイスである。移動体クライアント１０２は、セル・フォン、スマートフォン、またはネットワーク１１０へのアクセスを与え、クライアント側方針実施プロセス１０５を実行するのに十分な度合いのユーザ入力および処理能力を有する任意の移動体通信デバイスとすることができる。また、クライアント・コンピュータ１０２は、ノートブック・コンピュータ、パーソナル・ディジタル・アシスタント、ゲーム・コンソール、メディア再生ユニット、または同様の計算機というような、標準的な移動体計算機１１８においても具体化することができる。クライアント・コンピュータ１０２および１１８は、有線接続、ワイヤレス接続、またはその任意の組み合わせを通じて、サーバ・コンピュータ１０４に結合することができる。例えば、移動体クライアント１０２がセル・フォンである場合、移動体デバイスとネットワーク１１０との間におけるアクセスは、遠隔通信プロバイダによって維持されている別のセル・ネットワーク１１１を利用すると思われる。ネットワーク１１０がインターネットである一実施形態では、ネットワーク・サーバ１０４はワールド・ワイド・ウェブ（ＷＷＷ）サーバ・プロセス１１６を実行することができる。このプロセス１１６は、ウェブ・ページの形態でデータを格納し、これらのページをハイパーテキスト・マークアップ言語（ＨＴＭＬ）ファイルとして、インターネット１１０を通じてクライアント１０２および１１８に送信する。この実施形態では、クライアント１１８のようなクライアントは、ウェブ・ブラウザ・プログラム１１４を実行して、サーバ・コンピュータ１０４および任意の利用可能なコンテンツ・プロバイダまたは補助サーバ１０３によって提供される(serve)ウェブ・ページにアクセスすることができる。

図１に示すように、サーバ・コンピュータ１０４はサーバ側方針管理プロセス１１２を実行する。このプロセスは、クライアント側プロセス１０５と共に、方針管理フレームワークを構成する。この方針管理フレームワークは、管理当局（例えば、キャリアおよびＩＴ監理者(administrator)）が、アクセス制御、リソースおよびアプリケーション利用、動作特性、監視、およびロギング(logging)というような態様を決定する方針にしたがって移動体デバイスの行動を制御することを可能にする。サーバ側プロセス１１２は、方針を作成し、編集し、デバイスに提出し、次いでその後これらの方針を管理および監視する機能を備えている。次いで、クライアント側プロセス１０５は、これらの方針および規則を実施して、それ自体の動作機能および使用機能を自律的に制御する。このように、サーバ１０４および／または任意のシステム監理エンティティ、ならびに移動体デバイス１０２のユーザは、定められた方針およびその実施態様に関して、デバイスの動作への関与は最小限で済む。

一般に、方針管理は、管理当局が移動体デバイスの行動を定めることを可能とし、移動体デバイスが特定のネットワークまたは会社のデバイス使用方針に従うようにする、あるいは定められた動作制約または原理にしたがって動作するようにする機能である。例えば、ＩＴ管理部は、移動体デバイスのユーザが業務時間中はインターネット・ブラウザ使用を許可しないことを指定することができる。サーバ側方針管理機能を用いると、業務時間中（例えば、月曜日から金曜日までの午前８時から午後５時）には、電話機のブラウザを起動できないことを指定する方針を定めることができる。サーバは、この方針を移動体クライアントに送り、またそうでなければそれをクライアントに利用可能にする。次いで、クライアント側方針管理プロセス１０５は、方針をインストールしそれを実施する。この実施は、ユーザが許可されていない時間中にブラウザを起動しようとした場合、ブラウザが起動するのを方針フレームワークが自動的に妨げることを意味する。本システムによって、多くの異なるタイプの方針および規則を定め、クライアント・デバイスにおいて実施することができる。一実施形態では、方針管理フレームワークは、インターネット、電子メール、および会社のデータベースにアクセスする機能を備えているスマートフォンのような、企業デバイスを目標に設定し、多くの場合、信頼性のあるデータを格納する。動作規則管理によって、ＩＴ監理者はこれらのデバイスが会社の方針に忠実であることを保証することができる。

このフレームワークは、柔軟な方針を用いて、移動体デバイスがサーバによって定められた行動にしたがって自己管理することを可能にするインテリジェントな自律システムを提供する。この手法は、移動体デバイスのユーザによる大量の入力を必要とせずに効率的な管理を確保し、ネットワーク帯域幅、サーバ電力、メモリ、プロセッサ・オーバーヘッド、およびその他のリソースというようなリソースの利用も確保する。
クライアント側プロセス
先に述べたように、方針管理フレームワークは、サーバ側コンポーネントおよびクライアント側コンポーネントから成る。サーバ側プロセスは、動作規則集を作成、編集、および配信する機能を設ける。クライアント側プロセスは、クライアント・デバイスにおいて動作規則集を適用し(activate)、終了し(deactivate)、リストに纏め、実施する機能を設ける。

一実施形態では、クライアント側プロセス１０５は、動作規則として表される方針を実施する。動作規則の実施には、イベントを配信し、条件を評価し、１群の条件が真と評価された場合に、動作を誘起する機能が必要となる。更に、クライアント側アーキテクチャは、動作規則の遵守を監視できなければならず、したがって違反を検出し報告しなければならない。

動作規則集とは、特定の行為を実施する４つのタイプのコンポーネントの集合体である。これらのコンポーネントは、トリガ、条件群(condition group)、条件(condition)、および動作(action)である。図２は、一実施形態の下における動作規則集のこれら４つのコンポーネントを示す。図２に示すように、トリガ２０２は、ある対象の変数の状態変化を動作規則２０４に対して示すイベントである。トリガは、デバイスの動作特性、および／またはシステムによって定められる方針規則に関係付けることができる。トリガの例には、とりわけ、バッテリ・レベルがある充電率に達したこと、デバイスが特定の場所に入ったこと、または１日の時刻(time of day)が設定時刻に変化したことが含まれる。トリガ２０２が動作規則集２０４を通知すると、動作規則はその述部（条件）２０６を評価する。様々な異なる条件２０８を１つ以上の条件群２０６に編成することができる。条件が真となる場合、動作規則２０４は、関連した動作２１０の実行を起こさせる。

一実施形態では、各条件２０８はブール表現を含む。これは、真（「１」）または偽（ヌルまたは「０」）のいずれかとなる表現である。条件の一例は、batteryLevel＜１０％である。動作規則は、任意の実用的な数０〜ｎの条件を有することができ、これらの条件は条件群２０６によって互いに分類することができる。一般に、動作２１０は、動作規則述部が真と評価されたときに実行されるタスクである。この動作の一例には、ローカル・デバイス・コマンド「switchOffCamera」がある。つまり、例えば、トリガがバッテリの充電レベルである場合、条件batteryLevel＜１０％が真になると、その結果生ずる動作は、移動体デバイスのカメラ・コンポーネントをオフに切り換えることである。

クライアント側プロセス１０５は、クライアント・デバイスにおいて動作規則集を適用する、終了する、リストに纏める、および実施する機能コンポーネントを含む。これらのコンポーネントは、条件を評価し、１つ以上の条件が真であるときに動作を誘起する。図１に示すように、クライアント側方針管理プロセス１０５は、イベント・ソース１４２のための処理モジュールと、方針管理コンポーネント１４４を含む。クライアント側プロセスは、移動体クライアント・デバイスにおいて方針を適用、終了、および実施する機能を設ける。方針実施には、一般に、イベントを配信し、条件を評価し、条件の１群が真状態と評価されたときに動作を誘起する機能が必要となる。更に、クライアント側プロセスは、方針の準素を監視し、方針違反を検出および報告するように動作する。図３は、一実施形態の下におけるクライアント側方針管理プロセスの概略的なアーキテクチャ体系全体を示す。図３に示すように、クライアント側方針管理プロセスは、以下のコンポーネント、即ち、３０２および３０４のようなイベント・ソース、および方針管理コンポーネント３０６から成る。方針管理コンポーネント３０６は、述部評価部、動作処理部、トリガ管理部、および遵守監視部を含む。

イベント・ソースは、トリガを発生することを役割とする。イベント・ソース３０２および３０４のように、任意の数のイベント・ソースを設けることができる。イベント・ソースは、特定の状態をカプセル化し、ある種の予め設定されていた条件を満たすときにはいつでも、指定されたリスナ(listener)に通知を送る。例えば、タイマ・イベント・ソースは「ｘ」秒毎にイベントを発生する（「ｘ」は設定変更可能）。方針管理部３０６は、方針適用、終了、および実施を含む、全ての方針関連クライアント活動(activities)を調整する。これは、３つのコンポーネントを利用してタスクを遂行する。３つのコンポーネントとは、述部評価部、トリガ管理部、および動作処理部である。述部評価部は、指定された方針の条件を評価することを役割とする。条件を評価するために、条件処理部を拠り所とする。各条件処理部は、特定のタイプの論理表現（例えば、＞、＜、および＝）をどのように評価するか分かっている。動作処理部は、動作インスタンスの実行を調整する機能を設ける。動作処理部は、ベスト・エフォート、または厳格に全てというような、異なるセマンティクス(semantics)を与える。トリガ管理部は、トリガ（イベント・ソースによって発生された）を方針にマッピングする表を維持する。トリガ管理部がトリガ通知を受けると、この表を用いて、影響を受ける方針を判定する。次いで、影響を受ける方針毎に、トリガ管理部は、方針を評価する要求を方針管理部に送る。方針管理部は、述部評価部を利用して、方針の述部を評価し、この述部が真である場合、トリガ管理部は動作処理部と相互作用して、動作を実行する。遵守管理部は、方針違反をチェックして報告する。実施態様の構成に応じて、１からＮまでの任意の数の条件処理部、イベント・ソース、および動作を、クライアント側プロセス３００によって対処することができる。

一実施形態では、登録動作規則および評価動作規則を伴う動作には、１組の動作シーケンスが必要となる。動作規則登録は、移動体デバイスにおいてローカルに動作規則をイネーブルすることを役割とする。図４Ａは、一実施形態の下において動作規則を登録するステップを示す。このプロセスは、サーバ・デバイス管理プロセス４０２から開始して、動作規則情報を有する新たな管理対象（ＭＯ）を作成し、動作規則管理部４０４の「適用」動作に対する実行可能コマンドを呼び出す。この動作規則プロセスは、実行コマンドを受ける。動作規則管理部４０４は、起動時に、動作規則動作ノード（適用、終了、および除去）を登録し、したがって、動作規則のＵＲＩを用いてコールバック(callback)を得る。次に、動作規則管理部４０４は、トリガ管理部４０６のRegisterTriggersプロセスを呼び出す。このプロセスは、ＭＯからのトリガの情報を解析し、各トリガのＩＤを抽出し、最後にしかるべきトリガ４０８を呼び出してそれを登録する。

トリガを発火すると、動作規則管理部に通知され、動作規則評価プロセスが実行される。図４Ｂは、一実施形態の下における動作規則評価プロセスを示す。トリガ登録時に指定された条件が満たされると、イベント・ソースが通知をトリガ管理部４０６に送る。トリガ管理部は、動作規則ＵＲＩをイベントから引き出し、動作規則管理部４０４においてEvaluateActionRuleプロセスを呼び出す。動作規則管理部は、条件評価部４０８において動作規則の述部を評価し、この述部が真である場合、動作規則管理部は、動作管理部４１０を通じて動作規則の動作を実行する。

クライアント側プロセスは、統一モデリング言語（ＵＭＬ：unified modeling language）モデルによって表すことができる。このモデルは、クライアント・システムの抽象モデルを作成するために１組のグラフィカル表記技法を含む。図５は、一実施形態の下における、クライアント側アーキテクチャを定めるコンポーネントのＵＭＬ図を示す。図５のＵＭＬモデル５００では、イベント・ソース管理部５０２は、システムに登録されている全てのイベント・ソースのリストを維持し、これらを管理する機能を設ける。イベント・ソース・リストの状態は、
EventSourceList：全てのイベント・ソースが登録されているリスト。イベント・ソース・リストのメソッドは、次の通りである。

イベント・ソース５０４は、トリガ機能を実施する。イベント・ソースは、１組の条件が満たされたときにはいつでも、通知をリスナに送る。これらの条件は、各イベント・ソース毎に異なる。イベント・ソースは、動的にロード可能なモジュールとして構築され、したがって、実行時にシステムに追加することができ、更に、ＳＣｏＭＯ（ソフトウェア・コンポーネント管理オブジェクト）のようなメカニズムを用いて配備することができる。あらゆるイベント・ソースは一意のＩＤを有する。イベント・ソース管理部に登録するときに、イベント・ソースＩＤが、イベント・ソース管理部によって処理される表に格納されるので、このＩＤはシステムの残りの部分に利用可能になる。

イベント・リスナ・リスト５０６の状態は、EventListenerListである。登録されている全てのイベント・リスナをリストする。イベント・リスナ・リストのメソッドは次の通りである。

イベント・リスナとは、イベント・ソースから通知を受けるオブジェクトである。イベント・ソースは、加入条件が満たされたときに、notify(TupleContainer event)メソッドを呼び出す。入力パラメータは、イベントを記述する名称および値の対を含むタプル・コンテナである。イベントのタイプを識別する２つの必須パラメータ（EventIDおよびEventName）がある。

方針管理部５０８は、クライアント側インフラストラクチャ５００の中心的コンポーネントである。これは、４つのコンポーネントを利用してその機能を実施する。４つのコンポーネントとは、トリガ管理部５１６、動作管理部５１２、述部評価部５１４、および遵守監視部５１０である。policyInstantiated(URI uri)メソッドが、管理ツリー・コールバック・メカニズムによって呼び出される。パラメータは、新たにインスタンス化される方針に対するＵＲＩである。evaluatePolicy(URI uri)メソッドは、ＵＲＩによって指し示される方針条件を評価する。このプロセスは、述部を評価し、この述部が真である場合に関連した動作を呼び出すことを含む(imply)。register(String URI)メソッドは、方針トリガへの経路を受け、ツリー情報を解析し、しかるべきイベント・ソースを登録する。

トリガ管理部５１６は、トリガを方針に関連付け、トリガを受けたときに、影響を受ける方針を引き出すことを役割とする。トリガ管理部は、イベント・リスナであり、したがって、イベント・ソースから通知を受ける。トリガ管理部の状態は、TriggerToURIMappingsである。これは、トリガを方針のＵＲＩに関連付ける表である。トリガ・イベントを受けると、トリガ管理部はこの表をチェックして、評価しなければならない方針（１つまたは複数）はどれか決定する。notify(TupleContainer event)メソッドが、イベント・ソースによって呼び出される。入力パラメータは、イベントについての情報を含む。トリガ管理部がイベントを受けると、イベントＩＤを抽出し、それを用いてTriggerToURIMappings表にインデックスを付ける。その結果、トリガ管理部は、イベント（トリガ）と関連付けられた方針のリストを得る。トリガ管理部は、これらの方針について反復して(iterate over)、方針管理部によってエクスポートされた方針の述部を評価する「evaluatePolicy」メソッド（述部評価部）を呼び出し、述部が真である場合、方針動作を実行する（動作管理部）。addMapping(String evld, String uri)メソッドは、新たなマッピングTriggerToURIMappings表を格納する。removeMapping(String evld, String uri)メソッドは、TriggerToURIMappings表からマッピングを除去する。第２パラメータ（ＵＲＩ）がヌルである場合、このメソッドは、供給されたイベントに関連した全てのマッピングを除去する。第２パラメータがヌルでない場合、この方法は、指定されたバインディング(binding)だけを検出する。

述部評価部５１４は、方針インスタンスの述部の条件を評価することを役割とする。このコンポーネントは、条件ＩＤにしたがって、しかるべき条件処理部に実際の評価を代表委任する。evaluate(String URI)メソッドは、パラメータとして供給された方針の条件を評価する。このパラメータは、管理ツリーにおける方針条件のルート・ノードの位置を判定する。このメソッドは、サブツリーにわたって反復して、条件毎に条件ＩＤを抽出し、このＩＤを用いて、条件処理部が登録される表にインデックスを付ける。最後に、サブツリーから抽出したパラメータを用いて、条件処理部を呼び出す。

条件処理部５２０は、特定の条件クラス（例えば、＞、＜、およびストリング比較）を評価することができるコンポーネントである。これらの条件処理部には、一意のＩＤを用いた述部評価部が登録されている。条件処理部は、動的にシステムに登録することができる。evaluate(Condition condition)メソッドは、条件インスタンスを受け、それを評価し、そしてブール値を返す。

動作管理部５１２は、方針インスタンスの動作を実行することを役割とする。このコンポーネントは、特定のアクションＩＤにしたがって、しかるべき動作処理部に実際の実行を委任する。execute(String URI)メソッドは、パラメータとして供給された方針の動作を実行する。このパラメータは、管理ツリーにおける方針動作のルート・ノードの位置を判定する。このメソッドは、サブツリーにわたって反復して、条件毎に動作ＩＤを抽出し、このＩＤを用いて、条件処理部が登録される表にインデックスを付ける。最後に、サブツリーから抽出したパラメータを用いて、条件処理部を呼び出す。

動作処理部５１８は、特定の動作クラス（例えば、アプリケーション開始、アプリケーション停止、およびカメラのスイッチを切る）を実行することができるコンポーネントである。これらの動作処理部には、一意のＩＤを用いて動作管理部を登録する。動作処理部には動的にシステムを登録することができる。execute(Action action)メソッドは、動作インスタンスを受け、それを実行する。動作実行が失敗した場合、動作処理部は例外を返す。すると、動作管理部５１２は、残りの動作を実行するのか、実行を停止するのか、および／または失敗を報告するのか、判断することを役割とする。

遵守監視部５１０は、総合的に、管理サーバによって定められた方針に移動体デバイスが忠実であるか否かチェックすることを役割とする。遵守監視部は、方針違反を検出し、それらを、サーバ・プロセスのようなしかるべきサービスに報告する。

クライアント側プロセス５００は、概略的に、ダウン・タイムを極力抑えるようにして新たな機能を受け入れるように構成され、新たな機構が利用可能になる毎にシステムを再インストールする必要性を回避する。クライアント側プロセス全体は、コア・インフラストラクチャの２つのエレメント、および方針構築ブロック処理部に分割することができる。コア・インフラストラクチャは、方針管理をイネーブルする基本的な機能を設け、一方方針処理部は、３つの方針構築ブロック、即ち、トリガ、条件、および動作を操作することができるコンポーネントである。一般に、コア機能は、各方針インスタンスの特定の詳細には依存しない。これは、単に、包括的規則にしたがって、異なる方針構築ブロック処理部間において相互作用を調整するだけである。一方、方針構築ブロック処理部（トリガ、動作処理部、および条件処理部）は、特定の方針インスタンスの各々に密に結合されている。その結果、クライアント・プロセスは、実行時に新たな方針構築ブロック処理部を組み込み、ときと共に新たなタイプの方針を収容するように、十分に柔軟になるように実施される。更に、この柔軟性は、移動体デバイスがデバイス構成設定の間または起動時にどの方針構築ブロックをサポートするのか設定する際にも役に立つ。これができることによって、例えば、デバイス・タイプまたはハードウェア特性に応じて、異なる方針管理能力を有するデバイスの部分集合を作成し易くなる。

方針管理クライアント・アーキテクチャは、動的に構成設定可能なインフラストラクチャを利用し、実行時に利用可能な方針構築ブロック処理部を操作することを可能にする。一実施形態では、これを遂行するには、動的にロード可能なモジュールを用いて、トリガ、動作、および条件処理部を実装する。これらのモジュールは、実行時に配備およびインストールすることができ、その結果、新たな処理部がシステムに利用可能となる。

動作規則管理クライアント・プロセスの一例について、既に出荷されて現在用いられており、動作規則フレームワーク・インフラストラクチャがインストールされているデバイスについて、次のように説明する。キャリアがバッテリ流出(設定)率を監視し、この率がある値よりも高くなったときに通知を送るが、デバイスはバッテリの流出を管理するトリガを有しておらず、通知を送る動作処理部を有していない場合、キャリアは、ＳＣｏＭＯのような、定められたプロトコルを用いて、２つのモジュール、即ち、バッテリ・トリガおよび通知動作を配備する。デバイスは、これらのモジュールを受け、これらが動作規則処理部であることを検出し、したがってこれらを動作規則システムに実行時に登録する。動作規則（方針）フレームワークは、トリガ・モジュールをロードし、これにイベント・ソース管理部を登録する。次いで、動作処理部をロードし、それに動作管理部を登録する。登録の後、トリガおよび動作処理部ＩＤ双方が利用可能となり、使用する準備ができており、方針に対する動作規則を実施することができる。
サーバ側プロセス
クライアント側方針管理プロセスを移動体クライアント・デバイスにおいて制御する方針管理フレームワーク全体は、図１に示すように、サーバ側プロセス１１２によって制御される。サーバ側方針管理プロセス１１２は、様々な異なる機能ブロックを備えており、これらの機能ブロックには、方針作成部１２２、グループ方針管理プロセス１２４、デバイス方針管理プロセス１２６、およびシステム監理部１４０との相互作用を可能にするユーザ・インターフェースが含まれる。サーバ側管理システム１１２は、比較的単純で規格に基づいており多種多様の使用事例シナリオに対応する方針表現を実現するように構成されている。これらの方針表現は、サーバ１０４のデータ・ストア１２０にロードし格納することができる。一実施形態では、サーバは、異なる規準(criteria)に基づいて、新たな方針を動的に移動体デバイスにアップロードするように構成されている。企業の実施態様では、１つの主要な規準が、加入者が属するオーソリティ・グループ(authority group)となり、他の規準は、デバイス・タイプ、配備位置、配備時間、およびその他の同様の規準を含むことができる。

方針作成コンポーネント１２２は、システム監査部ユーザ１４０が、必要とされるコンポーネント（トリガ、条件、動作）から方針の新たなインスタンスを状態機械として作成すること、ならびに既存の方針を編集／更新し、既存の方針を削除し、または方針インスタンスをインポートおよびエクスポートすることを可能にする。一実施形態では、ユーザ・インターフェース１２８はユーザ１４０に既存の方針のリストを状態機械として提示する。方針を作成または編集するために、ユーザ・インターフェース１２８の一部は、それらがコンポーネントを表す際には、動的となる。ユーザがトリガ、条件、および動作に基づいて状態機械を構築した後、方針をデータ・ストア１２０に保存することができる。インポートおよび削除機能は、単にユーザに利用可能な方針のリストを変化させるだけである。エクスポート時に、ユーザは方針インスタンスをファイルとして保存することができる。

グループ方針管理ツールは、ユーザが、目標グループおよび関連した方針を管理することを可能にする。一般に、２つのビュー、即ち、目標グループ・ビューおよび方針ビューが利用可能である。目標グループ・ビューは、ユーザが全ての目標グループを見ること、目標グループを作成、編集、削除すること、そして選択された目標グループ毎に方針を見ることを可能にする。このビューにおいて利用可能なタスクには、選択された目標グループにまたはから方針を追加または除去すること、方針を適用または終了すること、方針遵守が最新であるか否かチェックすること、デバイスと同期することが含まれる。この実施形態では、ユーザ・インターフェースは、既存の目標グループのリストを提示する。任意の目標グループについて、関連する方針を見ることができる。この新たなビューは、これらの方針のリストを含み、前述の動作が利用可能である。方針を追加すると、利用可能な全ての方針のリストが示され、この中からユーザは１つを選択することができる。１つ以上の方針について遵守をチェックすると、同期されていないデバイスおよびその理由を含むリストが表示される(populate)。ユーザは、デバイスに同期し、したがって遵守を実施する選択肢を有する。

グループ方針管理ツールにおける第２のビューは、方針ビューである。このビューは、ユーザが全ての方針を見ること、および選択された方針毎に目標グループを見ることを可能にする。この場合、ユーザ・インターフェースは利用可能な全ての方針を示し、ユーザは、方針について関連した目標グループを見ることができる。

一実施形態では、方針管理サーバ側プロセスが、ＭＤＭプラットフォームに構築され、ＭＤＭプラットフォームは、方針監理のようなサービスの統合を簡略化するモジュール状アーキテクチャを設ける。ＭＤＭプラットフォームは、リモート移動体デバイスの標準的な管理をイネーブルするＯＭＡ ＤＭプロトコルを実施する。これは、方針管理に対する要件の１つである。図６は、一実施形態の下における、マネージド・リモート・クライアント・デバイスと共に用いるためのＭＤＭサーバ６００を示す。サーバ側サービスは、必要とされるコンポーネント（トリガ、条件、動作）から新たな方針を作成する方針作成部を含む。インターフェースを通じて、監理部６０４は、既存の方針を編集／更新し、既存の方針を削除し、または方針インスタンスをインポートおよびエクスポートすることができる。また、監理部は、ＭＤＭインスタンスのコンポーネントをインポート、エクスポート、および削除することもできる。

方針管理コンポーネント６０２は、監理部が目標グループおよび関連した方針を管理することを可能にする目標グループ方針管理部を含む。ユーザ・インターフェースを通じて、目標グループおよび方針のビューが利用可能である。目標グループ・ビューでは、監理者は全ての目標グループを見ること、目標グループを作成、編集、削除すること、そして選択した目標グループによって方針を見ることができる。また、ユーザは、選択された目標グループへ／から方針を追加または除去すること（まだデバイスに送っていない）、方針を適用または終了すること（まだデバイスに送っていない）、方針遵守（最新）およびデバイスと同期する可能性（マス・ジョブ(mass job)を通じてインストール、除去、適用、終了、または更新する）をチェックすることもできる。方針ビューでは、監理部は、選択した方針によって全ての方針を見ることまたは目標グループを見ることができる。

方針管理コンポーネント６０２は、管理者が１つのクライアント・デバイスについて既存の方針を管理することを可能にする、デバイス／加入方針管理部を含む。ユーザ・インターフェースを通じて、ユーザはデバイスにおいて全ての方針を見ること（直接または間接的にフィルタリングする可能性）、１つのジョブを通じて直接方針をインストール、更新、除去、適用、または終了すること、間接方針を更新、除去、適用、または終了すること、ならびに間接方針についての方針遵守（最新）およびデバイスと同期する可能性をチェックすることができる。クライアント相互作用のワークフローは、ユーザが方針を照会、インストール、更新、除去、適用、終了することを可能にする。

一実施形態では、サーバ６００は、複数の異なるクライアント・デバイス毎に管理方針を格納するように構成することができる。異なるクライアントを、デバイス・タイプ、位置、ユーザ・グループ、サービス・グループ、時間帯等というような、１つ以上の異なる特性によって編成することができる。これらの方針は、サーバにアクセス可能な組織的なデータベースに格納することができる。次いで、これらの分類された方針を特定の目標設定されたクライアント・デバイスに配信し、関連した特性に基づいた効率的な構成再設定に対処することができる。
移動体デバイス管理の実施
一実施形態では、図１の移動体デバイス方針管理フレームワークは、移動体デバイスにおいて、判断方針および能動的方針を含む、方針を管理するように構成されたシステムを含む。このシステムは、前述のように、デバイス方針レポジトリ、方針判断点、判断方針実施部、および能動的方針実施部を含む。本システムは、移動体デバイスにおいて方針を実施する方法を含む。この方法は、実行環境を予防的に監視し、能動的方針を自動的に誘起する。更に、この方法は、インターフェースをエクスポートし、判断方針を評価し実施する機能を設ける。本システムは、方針の矛盾を検出し回避することを含む、異なるソースからの方針を組み合わせることができる。

一実施形態では、図１のクライアント側プロセス１０５は、移動体クライアント・デバイス１０２に位置するインテリジェント管理エージェントとして実装される。このインテリジェント管理エージェントは、移動体デバイスに位置するクライアント側移動体管理プロセスと、サーバ１０４に位置するサーバ側移動体デバイス管理（ＭＤＭ）プロセス１１２との間における通信を拠り所とする。

ＯＭＡ ＤＭ（オープン移動体連合デバイス管理）のような標準的な管理プロトコルが、サーバによって用いられ、移動体クライアントについての管理プロパティ値を引き出し、分析し、設定する。一般に、ＯＭＡ ＤＭ使用は、セル・フォン、ＰＤＡ、およびパーム・トップ・コンピュータのような小型移動体デバイスの管理に最適化されているが、事実上あらゆるタイプのネットワーク型デバイスを管理するために用いることができる。デバイス管理機能は、以下の典型的な使用をサポートすることを意図する。デバイスの構成設定を含むプロビジョニング、機構のイネーブルおよびディスエーブル、ソフトウェアのアップグレード、障害管理等。

一実施形態では、ＯＭＡ ＤＭプロトコル、および移動体デバイスにおいて遠隔でソフトウェアを管理するプロトコルを指定するＳＣｏＭＯ（ソフトウェア・コンポーネント管理オブジェクト）規格を用いて、クライアント側プロセスをクライアント・デバイスにダウンロードすることもできる。ＳＣｏＭＯは、一般に、移動体デバイスにおけるソフトウェアのインストール、アンインストール、起動、および終了を指令する。図１の移動体クライアント１０２、およびＯＭＡ ＤＭをサポートする他のあらゆるデバイスは、管理ツリーを内蔵する。管理ツリーは、サーバ１０４が一意のＵＲＩ（ユニフォーム・リソース識別子）によってあらゆるノードに直接アクセスすることができるように、利用可能な全ての管理オブジェクトを含み組織化する。

既に述べたように、方針は、それぞれの動作−条件−トリガ・コンポーネントについて、ＸＭＬ構造を用いて、サーバにおいて表される。移動体クライアント・デバイスにおいて、各方針はサブツリーとして表される。このメカニズムは、ＯＭＡ ＤＭによって供給されるサブツリー構造を利用し、移動体クライアントにおける実行を容易にする。一実施形態では、サーバはＸＭＬを利用して方針を格納するが、クライアントはそうしない。クライアントは、ＯＭＡ ＤＭ管理ツリー構造を用いて、情報を格納する。サーバは、ＸＭＬ文書を解析し、全ての情報を含むサブツリーを自動的に作成する。次いで、サーバはクライアント・デバイスにおいてサブツリーを遠隔で作成する。

一実施形態では、ソフトウェア管理プロセスを設けて、クライアント側管理プロセスの移動体クライアント・デバイスへのダウンロードを容易にすることができる。一実施態様では、ユーザは、ダウンロードすべきソフトウェアを制御し（ユーザ・プル・シナリオ）、サード・パーティ・サーバによってアプリケーションを供給することができる。ユーザは、最初に、移動体デバイス自体にあろうと別のコンピュータを経由してであろうと、サーバ・コンピュータのソフトウェア管理ポータルにアクセスする。アプリケーションおよびその属性を選択する場所であるポータルは、任意のサード・パーティ・アプリケーションまたはコンテンツ・サーバと通信する。ＭＤＭ サーバは、移動体クライアントに対する制御接続を開始し、その後コンテンツ・サーバへの接続が許可され確立される。他の実施態様では、運営業者または企業がアプリケーションのダウンロードを制御する（運営業者プッシュ・シナリオ）。例えば、企業の設定では、ＩＴ部署がアプリケーション・パッチまたは新たなアンチウイルス署名ファイル(anti-virus signature file)のダウンロードを命令するとよい。ここで、企業または運営業者は、ＭＤＭコンソールを通じて、動作中にダウンロードを設定する。次いで、ＭＤＭサーバおよび任意のサード・パーティ・コンテンツ・サーバは、移動体デバイスへの接続を確立する。

一実施形態では、ＭＤＭサーバのキャリア・スイート(carrier suite)における構成管理部は、移動体デバイスにおける構成設定値をワイヤレス（セルラ）ネットワークを通じて管理する。ＯＭＡ ＤＭアプリケーションでは、キャリア・スイートは、移動体デバイスにおいて事実上あらゆるアプリケーションの構成を設定する。移動体デバイスの構成は、ＯＭＡ ＤＭ管理ツリーにおいてオブジェクトの値を設定することによって扱われる。ある種のＯＭＡ ＤＭアプリケーションには、ブートストラップ・ルーチン、診断、および他のアプリケーションのように、予め定めておくことができるものもある。
ＭＤＭマネージド・クライアント
クライアント・デバイス１２０は、通例、移動体クライアント・デバイスであり、通信、娯楽、ナビゲーション、情報管理、および基本的な計算機能というような、種々の機能およびユーティリティを提供する複数の異なるアプリケーション・プログラムを実行する。移動体クライアント１２０は、セル・フォン、スマートフォン、またはネットワークへのアクセスを提供し、方針を実施しＭＤＭサーバ１０２によって管理されるタスクを実行するための十分な程度のユーザ入力および処理能力を有する任意の移動通信デバイスとすることができる。計算環境によっては、クライアント・デバイスを、ノートブック・コンピュータ、パーソナル・ディジタル・アシスタント、ゲーム・コンソール、メディア再生ユニット、または同様の計算機のような、標準的な移動体計算機において具体化することもできる。このようなクライアント・コンピュータは、有線接続、ワイヤレス接続、またはその任意の組み合わせによって、サーバ・コンピュータに結合することができる。

一実施形態では、移動体デバイスは、ＭＤＭキャリア・スイートのサーバ１０２の処理エレメントと通信する、インテリジェント管理エージェントを含む。一実施形態では、移動体クライアントについて管理プロパティ値を引き出し、分析し、設定するために、ＯＭＡ ＤＭ（オープン移動体連合デバイス管理）のような標準的な管理プロトコルがサーバによって用いられる。

図７は、一実施形態の下において、ＭＤＭプラットフォームとＯＭＡ ＤＭ対応移動体デバイスとの間における移動体デバイス管理システムを示す。ＯＭＡ ＤＭプロトコルを用いて、サーバ７０２は、移動体デバイス７０６の管理ツリー７０４に格納されている管理プロパティ値を引き出し、分析し、設定することができる。デバイス管理機能は、以下の典型的な使用をサポートすることを意図している。デバイスの構成設定を含むプロビジョニング、機構のイネーブルおよびディスエーブル、ソフトウェアのアップグレード、障害管理等。一実施形態では、ＭＤＭサーバ１０２のキャリア・スイート(carrier suite)における構成管理部１０４は、移動体デバイスにおける構成設定値をワイヤレス（セルラ）ネットワークを通じて管理する。ＯＭＡ ＤＭアプリケーションでは、キャリア・スイートは、移動体デバイスにおいて事実上あらゆるアプリケーションの構成を設定する。移動体デバイスの構成は、ＯＭＡ ＤＭ管理ツリーにおいてオブジェクトの値を設定することによって扱われる。ある種のＯＭＡ ＤＭアプリケーションには、ブートストラップ・ルーチン、診断、および他のアプリケーションのように、予め定めておくことができるものもある。

管理ツリー７０４は、移動体デバイスの任意のタイプの構成態様(configuration aspect)を表し、関連する設定値、機能などに関する動作パラメータを格納する複数のノードを備えている。図８は、一実施形態の下における、移動体クライアント・デバイスのＯＭＡ ＤＭ管理ツリーの一例を示す。この管理ツリーは、ルート・ノード８０２と、このルート・ノードの下にある複数のサブノードを含む。これらのサブノードは、ＤＭＡｃｃノード８０４、販売業者ノード８０６、および運営業者ノード８０８を含むことができる。各ノードにはＵＲＩが関連付けられている。例えば、図８の管理ツリーにおける「ABC Inc」ノードにアクセスするためには、正しいＵＲＩは「./DMAcc/ABCInc」となる。ＤＭＡｃｃノード８０４は、マネージド・デバイスにおけるデバイス管理クライアントの設定値を総合的に指定する。任意の数の機能、アプリケーション、またはクライアントに関連する設定値を、管理ツリーにおけるサブノードによって指定することができる。図８の例では、移動体クライアントの呼び出し音信号８１２およびスクリーン・セーバ８１４の設定値に対するサブノードが示されている。これらおよび任意の他の設定値は、ＭＤＭサーバ監理部、キャリア・サービス監理部、または任意の他のサード・パーティ・プロバイダによって提供されるファームウェア更新によって設定することができる。

管理ツリーは、サーバが一意のＵＲＩ（ユニフォーム・リソース識別子）によってあらゆるノードに直接アクセスすることができるように、利用可能な全ての管理オブジェクトを含み組織化する。管理ツリーは、複数の階層的に組織化されたノードを備えている。内部ノードは、無限数のチャイルド・ノードを有することができ、一方リーフ・ノードは、ヌルを含む値を含まなければならない。各ノードは、それに関連付けられている１組の実行時プロパティを有する。全てのプロパティは、関連したノードのみに有効である。アクセス制御リスト（ＡＣＬ）は、どのサーバがそのノードを操作することができるかを表す。この操作には、チャイルド・ノードを追加すること、ノードのプロパティを入手すること、このノードを交換すること、またはこのノードを削除すること、そして他の実行時プロパティを含む。管理ツリー、または移動体デバイスの任意のサブツリーは、ＭＤＭサーバ・プラットフォーム８０２からのＯＭＡメッセージ呼び出し(invocation)を通じてアクセスすることができる。

一実施形態では、移動体デバイス方針管理システムは、ノード管理プロパティを増大するメカニズムを含む。一般に、管理情報の構造は、管理ノードを定める。本方法は、以下の集合を含むように、１組の標準的管理プロパティを増大する。ステータス、リフレッシュ間隔、状態（イネーブル／ディスエーブル）、およびロギング・フラグ(logging flag)。加えて、管理プロパティは、些細な動作、しきい値および単純な規則、ならびに重要な動作、しきい値、および単純な規則を含む。「ステータス」プロパティは、知覚されるノード厳格性、即ち、なし、些細、または重要と同等である。「リフレッシュ」間隔は、規則評価の期間を定める。管理状態は、システムがノード評価を保留または再開することを可能にする。ロギング・フラグは、所与のノードに対するロギング方針を制御する。プロパティ・グループは、サポートされている厳格度レベル毎に繰り返される。「動作」プロパティは、単純な規則が満たされた場合に発火される動作を表す。「しきい値」は、規則パラメータとして用いられるしきい値を表す。

一実施形態では、本システムは、デバイス管理ツリーにおけるアクティブな監視ノード毎に周期的な監視を必要とする移動体エージェント行動を定める。本プロセスは、規則評価、ロギング、および補正動作の実行を含む。移動体エージェントは、ＭＤＭによって送られる標準的なＯＭＡメッセージの実行、およびアクティブ・ノードの永続的監視を組み合わせる。

また、移動体エージェント・プロセスは、警報の表記(notation)を供給する機能も含むことができる。例えば、１つの規則が満たされる毎に、エージェントが警報記録(alarm record)を発生する。警報記録は、ノードＵＲＩ、ノード値、厳格性タイムスタンプ、および知覚された厳格度を含む。警報通知をサーバに送ろうとするエージェントは、専用の管理ノードを用いて、全ての警報を引き出すことができる。図９は、一実施形態の下において、インテリジェント・エージェントのために警報通知および警報引き出しを行うシステムを示すブロック図である。図９に示すように、インテリジェント・エージェント９０４は、警報管理ノード９０６を含む。このエージェントは、ＭＤＭプラットフォームと通信して、警報通知をこのプラットフォームに供給し、警報管理ノード９０６においてこのプラットフォームから警報を引き出す。

一実施形態では、インテリジェント・エージェントは、デバイス管理ツリーにおけるサブツリー毎にステータス集合を供給する。これによって、サーバは、個々のノードに照会する必要なく、デバイス・ステータス全体を得ることができる。

図６のＭＤＭサーバは、監視構成を格納および配信するために用いることができる。この実施形態の下では、１組の増大したノード・プロパティに基づく監視構成を、手順が定める。管理サーバは、監視構成を作成、格納、および配信するために用いられる。

図１のクライアント側およびサーバ側方針処理モジュールによって、複数の異なる管理機能および値を分析し、ワイヤレス・ネットワークを通じて複数の移動体クライアント・デバイスに結合されているサーバ・コンピュータに格納することができる。クライアント側プロセスによって、インテリジェント移動体クライアントは、サーバによって供給されＯＭＡ ＤＭプロトコルによってクライアントに送られる初期命令および方針に基づいて、これらの方針を実施し、本質的にそれ自体を管理することが可能になる。任意の実用的な数の条件および動作に対処することができ、バッテリの低レベルが検出された場合のターン・オフ機能のような動作機能、またはユーザの特権に基づいてユーザのアクセスを制限するというような使用機能を含む。

このアーキテクチャを用いると、総合的リモート・デバイス・プロビジョニング・システムを実現することができ、配備されたデバイスのある種の部分集合について、方針規則が定められる。次いで、カスタム化されたモジュール、パッチ、更新などをデバイスに送信することができ、各デバイスはしかるべきモジュールを実装し実行することができる。これによって、現在のプロビジョニング・システムにおいて必要とされる手間を大幅に削減する。現在のプロビジョニング・システムでは、共通モジュールが全てのデバイスに送られ、次いでユーザが彼自身または彼女自身で更新を実施および管理しなければならず、あるいはシステム監理者が各クライアント・デバイスを別々に更新および監理する手間を引き受けなければならない。クライアント側プロセスがサーバ側ＭＤＭプラットフォームと共に提供する方針定義および配信体系は、ユーザおよびシステム監理者の入力を最小限に抑えて、分散された移動体デバイスの自律動作を大幅に増強する。

実施形態は、ネットワークを通じて移動体クライアント・デバイスを管理する方法を対象とする。この方法は、移動体クライアント・デバイスの管理ツリーの１つ以上のノードにおいて、管理プロパティ値を格納するステップと、ワイヤレス・ネットワークを通じて移動体クライアント・デバイスに結合されているサーバ・コンピュータにおいて、管理値のうち少なくとも一部を分析し設定するステップと、ノードの厳格性値を表すステータス・プロパティ、および規則と、この規則が満たされた場合に実行される動作を表す動作プロパティと、規則パラメータとして用いられる最小値を表すしきい値とを含むプロパティ・グループを含むように、１組の管理プロパティを定めるステップとを備えている。

この実施形態では、移動体クライアント・デバイスが、オープン移動体連合デバイス管理（ＯＭＡ ＤＭ）対応移動体クライアント・デバイスを含む。各ノードは、１つ以上の動作規則集を備えることができ、各動作規則集が、対象変数の状態変化を動作プロパティに示すトリガ・イベントと、対象変数と関連したｙｅｓまたはｎｏ値を含む条件と、対応する条件が真である場合に移動体デバイスによって実行されるタスクを含む動作とを備えている。この方法では、ノード厳格性値には、なし、些細、重要から成る１群から選択される厳格性レベルを割り当てることができる。管理プロパティは、更に、サーバ・コンピュータによる規則評価のための時間期間を定めるリフレッシュ間隔、または定められたノードに対するロギング方針を制御するロギング・フラグを備えることができる。更に、本方法は、管理ツリーにおける各アクティブ・ノードを周期的に監視するステップを備えることができる。周期的に監視するステップは、各規則を評価するステップと、各規則を記録するステップと、障害状態の場合に、補正動作を実行するステップとを含むことができる。

一実施形態では、規則が満たされる毎に警報記録が発生し、この警報記録が、規則が満たされたノードに対するリソース識別子と、厳格性タイムスタンプと、厳格性値とを含む。更に、本方法は、サーバ・コンピュータの専用管理ノードにおいて全ての警報記録を受けるステップを備えることができる。

この方法では、管理ツリーが、複数のサブツリーを含むこともでき、本方法は、更に、移動体デバイスの全体的なステータスを得るために、サブツリー毎にステータスを集めるステップを備えている。

また、実施形態は、マネージド・オブジェクト移動体デバイスを対象とする。この移動体デバイスは、前記移動体クライアント・デバイスの管理ツリーの１つ以上のノードにおいて、移動体デバイスの管理プロパティ値を格納し、ノードの厳格性値を表すステータス・プロパティ、および規則と、この規則が満たされた場合に実行される動作を表す動作プロパティと、規則パラメータとして用いられる最小値を表すしきい値とを含むプロパティ・グループを含むように、１組の管理プロパティを定めるインテリジェント管理エージェントと、遠隔結合され、管理ツリーの管理値のうち少なくとも一部を分析し設定するように構成されているサーバ・コンピュータに、管理ツリー・データを送信する送信モジュールとを備えている。この実施形態では、移動体デバイスが、オープン移動体連合デバイス管理（ＯＭＡ ＤＭ）対応クライアント・デバイスを含み、送信ではＯＭＡ ＤＭ通信プロトコルを利用する。各ノードは、１つ以上の動作規則集を備えており、各動作規則集が、対象変数の状態変化を動作プロパティに示すトリガ・イベントと、対象変数と関連したｙｅｓまたはｎｏ値を含む条件と、対応する条件が真である場合に移動体デバイスによって実行されるタスクを含む動作とを備えている。ノード厳格性値には、なし、些細、重要から成る１群から選択される厳格性レベルが割り当てられる。

一実施形態では、管理プロパティが、更に、サーバ・コンピュータによる規則評価のための時間期間を定めるリフレッシュ間隔と、定められたノードに対するロギング方針を制御するロギング・フラグとを備えている。一実施形態のデバイスは、更に、管理ツリーにおける各アクティブ・ノードを周期的に監視する監視モジュールを備えることもでき、周期的な監視が、各規則を評価することと、各規則を記録することと、障害状態の場合に、補正動作を実行することを含む。本デバイスは、規則が満たされる毎に警報記録を発生するように構成されている警報管理ノードとすることができ、警報記録が、規則が満たされたノードに対するリソース識別子と、厳格性タイムスタンプと、厳格性値とを含む。この実施形態では、全ての警報記録を、サーバ・コンピュータの専用管理ノードにおいて受けることができる。

本デバイスの一実施形態では、管理ツリーが、複数のサブツリーを含み、本方法が、更に、移動体デバイスの全体的なステータスを得るために、サブツリー毎にステータスを集めるステップを備えている。

また、実施形態は、コンピュータ・ネットワークを通じてサーバ・コンピュータに結合されているオープン移動体連合デバイス管理（ＯＭＡ ＤＭ）対応移動体クライアント・デバイスにおいて方針を定め実施するシステムを対象とする。この移動体クライアント・デバイスは、定められた方針の作成、変更、および移動体クライアント・デバイスへの送信を可能にするように構成されているサーバ側プロセスと、移動体クライアント・デバイスの１つ以上の特性、移動体クライアント・デバイスのユーザの１つ以上の特性、および１つ以上のスケジューリング・パラメータによって定められる実施要件に基づいて、定められた方針を格納するデータ・ストアと、実施要件にしたがって、方針を移動体クライアント・デバイスに送信する送信プロセスと、移動体クライアント・デバイスにおいて実行され、移動体クライアント・デバイスの中にあるＯＭＡ ＤＭ管理ツリーにおける定められた方針を、管理対象として格納するように構成されているクライアント側プロセスであって、定められた方針の各方針が、管理ツリーのサブノードとして表されており、更に、実施要件にしたがって、定められた方針を自動的に実施するように構成されている、クライアント側プロセスとを備えている。

このシステムでは、ユーザの１つ以上の特性が、ユーザ識別、ユーザ特権、ユーザ位置、およびユーザ年齢から成る１群から選択される。このシステムでは、移動体クライアント・デバイスの１つ以上の特性が、デバイス位置、デバイス・アクセス・サービス・タイプ、ならびにデバイス製造業者およびモデルから成る１群から選択される。

本明細書において記載したシステムおよび方法は、処理システムを含む、および／または処理システムの下でおよび／またはこれと連携して実行する。この処理システムは、当技術分野では周知のように、共に動作するプロセッサベースのデバイスまたは計算機、あるいは処理システムまたはデバイスのコンポーネントの任意の集合体を含む。例えば、処理システムは、携帯用コンピュータ、通信ネットワークにおいて動作する携帯用通信デバイス、および／またはネットワーク・サーバのうち１つ以上を含むことができる。携帯用コンピュータは、パーソナル・コンピュータ、セルラ電話機、パーソナル・ディジタル・アシスタント、携帯用計算機、および携帯用通信デバイスの中から選択される複数のデバイスおよび／またはその組み合わせのうち任意のものとすることができるが、それに限定されるのではない。処理システムは、それよりも大きなコンピュータ・システムの中にあるコンポーネントを含むことができる。

一実施形態の処理システムは、少なくとも１つのプロセッサと、少なくとも１つのメモリ・デバイスまたはサブシステムとを含む。また、処理システムは、少なくとも１つのデータベースを含むか、またはこれに結合することができる。「プロセッサ」という用語は、本明細書において一般に用いられる場合、１つ以上の中央処理ユニット（ＣＰＵ）、ディジタル信号プロセッサ（ＤＳＰ）、特定用途集積回路（ＡＳＩＣ）等のような、任意の論理的処理ユニットを指す。プロセッサおよびメモリは、１つのチップにモノリシックに集積すること、複数のチップまたはコンポーネント間に分散させること、および／または何らかのアルゴリズムの組み合わせによって設けることができる。本明細書において記載した方法は、ソフトウェア・アルゴリズム（１つまたは複数）、プログラム、ファームウェア、ハードウェア、コンポーネント、回路のうち１つ以上で任意の組み合わせで実現することができる。

本明細書において記載したシステムおよび方法のコンポーネントは、一緒に配置することまたは別の位置に配置することができる。通信経路は、これらのコンポーネントを結合し、これらのコンポーネント間においてファイルを通信または伝送する任意の媒体を含む。通信経路は、ワイヤレス接続、有線接続、および混成ワイヤレス／有線接続を含む。また、通信経路は、ローカル・エリア・ネットワーク（ＬＡＮ）、都市エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、企業所有のネットワーク、事務所間またはバックエンド・ネットワーク、およびインターネットを含むネットワークへの結合(coupling)または接続も含む。更に、通信経路は、フロッピ・ディスク、ハード・ディスク・ドライブ、およびＣＤ−ＲＯＭディスクというようなリムーバブル固定媒体、更にはフラッシュＲＡＭ、ユニバーサル・シリアル・バス（ＵＳＢ）接続、ＲＳ−２３２接続、電話線、バス、および電子メール・メッセージも含む。

文脈上特に必要であることが明らかでない限り、明細書および特許請求の範囲を通じて、「含む（又は備える）」、「含んでいる（又は備えている）」等の言葉は、排他的または網羅的意味ではなく、包含的意味で解釈するものとする。即ち、「含むが、限定されない」という意味である。単数または複数を用いる単語も、それぞれ、複数および単数を含むものとする。加えて、「ここでは」、「以後」、「以上で」、「以下で」という単語、および同様な意義の単語は、本願において用いられる場合、本願全体を指すのであり、本願のいずれの特定部分を指すのではないとする。「または」という用語が２つ以上の項目のリストを引用して用いられる場合、この用語は当該用語の以下の解釈全てに該当するものとする。リストにおける品目のいずれか、リストにおける品目の全て、およびリストにおける品目のあらゆる組み合わせ。

本明細書において記載したシステムおよび方法の実施形態についてのこれまでの説明は、それで全てであることも、開示した正確な形態に本発明を限定することも意図していない。本明細書において記載したシステムおよび方法の具体的な実施形態および例を例示を目的としてここで記載したが、種々の等価な変更も本発明の範囲内で可能であることは、当業者は認めよう。本明細書において記載したシステムおよび方法の教示は、他の処理システムや方法にも適用することができ、前述したシステムおよび方法のみに適用できるのではない。

前述の種々の実施形態の要素や作用を組み合わせると、更に別の実施形態を得ることができる。以上の詳細な説明に鑑みれば、これらおよびその他の変更を、本明細書において記載したシステムおよび方法に行うことができる。

Claims (23)

1. ネットワークを通じて移動体クライアント・デバイスを管理する方法であって、
   前記移動体クライアント・デバイスの管理ツリーの１つ以上のノードにおいて、管理プロパティ値を格納するステップと、
   ワイヤレス・ネットワークを通じて前記移動体クライアント・デバイスに結合されたサーバ・コンピュータにおいて、前記管理値のうち少なくとも一部を分析し設定するステップと、
   ノードの厳格性値を表すステータス・プロパティ、および規則と、この規則が満たされた場合に実行される動作を表す動作プロパティと、規則パラメータとして用いられる最小値を表すしきい値とを含むプロパティ・グループを含むように、１組の管理プロパティを定めるステップと、
   を含む、方法。
2. 請求項１記載の方法において、前記移動体クライアント・デバイスが、オープン移動体連合デバイス管理（ＯＭＡ ＤＭ）対応の移動体クライアント・デバイスを含む、方法。
3. 請求項２記載の方法において、各ノードが１つ以上の動作規則集を含み、各動作規則集が、
   対象変数の状態変化を動作プロパティに示すトリガ・イベントと、
   前記対象変数と関連したｙｅｓまたはｎｏの値を含む条件と、
   対応する条件が真である場合に前記移動体デバイスによって実行されるタスクを含む動作と、
   を含む、方法。
4. 請求項３記載の方法において、前記ノード厳格性値には、なし、些細、重要から成る１群から選択される厳格性レベルが割り当てられる、方法。
5. 請求項３記載の方法において、前記管理プロパティが、更に、前記サーバ・コンピュータによる規則評価のための時間期間を定めるリフレッシュ間隔を含む、方法。
6. 請求項５記載の方法において、前記管理プロパティが、更に、定められたノードに対するロギング方針を制御するロギング・フラグを含む、方法。
7. 請求項１記載の方法であって、更に、前記管理ツリーにおける各アクティブ・ノードを周期的に監視するステップを含む、方法。
8. 請求項７記載の方法において、前記周期的に監視するステップが、
   各規則を評価するステップと、
   各規則を記録するステップと、
   障害状態の場合に、補正動作を実行するステップと、
   を含む、方法。
9. 請求項７記載の方法であって、更に、
   規則が満たされる毎に警報記録を発生するステップを含み、前記警報記録が、前記規則が満たされたノードに対するリソース識別子と、厳格性タイムスタンプと、厳格性値とを含む、方法。
10. 請求項９記載の方法であって、更に、前記サーバ・コンピュータの専用管理ノードにおいて全ての警報記録を受けるステップを含む、方法。
11. 請求項１記載の方法において、前記管理ツリーが、複数のサブツリーを含み、前記方法が、更に、前記移動体デバイスの全体的なステータスを得るために、サブツリー毎にステータスを集めるステップを含む、方法。
12. マネージド・オブジェクト移動体デバイスであって、
    前記移動体クライアント・デバイスの管理ツリーの１つ以上のノードにおいて、前記移動体デバイスの管理プロパティ値を格納し、ノードの厳格性値を表すステータス・プロパティ、および規則と、この規則が満たされた場合に実行される動作を表す動作プロパティと、規則パラメータとして用いられる最小値を表すしきい値とを含むプロパティ・グループを含むように、１組の管理プロパティを定めるインテリジェント管理エージェントと、
    前記管理ツリーの管理値のうち少なくとも一部を分析し設定するように構成された遠隔結合されたサーバ・コンピュータに、管理ツリー・データを送信する送信モジュールと、
    を含む、マネージド・オブジェクト移動体デバイス。
13. 請求項１２記載のデバイスにおいて、前記移動体デバイスが、オープン移動体連合デバイス管理（ＯＭＡ ＤＭ）対応のクライアント・デバイスを含み、前記送信が前記ＯＭＡ ＤＭ通信プロトコルを利用する、デバイス。
14. 請求項１３記載のデバイスにおいて、各ノードが、１つ以上の動作規則集を含み、各動作規則集が、
    対象変数の状態変化を動作プロパティに示すトリガ・イベントと、
    前記対象変数と関連したｙｅｓまたはｎｏの値を含む条件と、
    対応する条件が真である場合に前記移動体デバイスによって実行されるタスクを含む動作と、
    を含む、デバイス。
15. 請求項１４記載のデバイスにおいて、前記ノード厳格性値には、なし、些細、重要から成る１群から選択される厳格性レベルが割り当てられる、デバイス。
16. 請求項１５記載のデバイスにおいて、前記管理プロパティが、更に、
    前記サーバ・コンピュータによる規則評価のための時間期間を定めるリフレッシュ間隔と、
    定められたノードに対するロギング方針を制御するロギング・フラグと、
    を含む、デバイス。
17. 請求項１３記載のデバイスであって、更に、前記管理ツリーにおける各アクティブ・ノードを周期的に監視する監視モジュールを含み、周期的な監視が、各規則を評価することと、各規則を記録することと、障害状態の場合に、補正動作を実行すること、
    を含む、デバイス。
18. 請求項１７記載のデバイスであって、更に、
    規則が満たされる毎に警報記録を発生するように構成された警報管理ノードを含み、前記警報記録が、前記規則が満たされたノードに対するリソース識別子と、厳格性タイムスタンプと、厳格性値とを含む、デバイス。
19. 請求項１８記載のデバイスにおいて、全ての警報記録が、前記サーバ・コンピュータの専用管理ノードにおいて受けられる、デバイス。
20. 請求項１９記載のデバイスにおいて、前記管理ツリーが、複数のサブツリーを含み、前記方法が、更に、前記移動体デバイスの全体的なステータスを得るために、サブツリー毎にステータスを集めるステップを含む、デバイス。
21. コンピュータ・ネットワークを通じてサーバ・コンピュータに結合されたオープン移動体連合デバイス管理（ＯＭＡ ＤＭ）対応の移動体クライアント・デバイスにおいて方針を定め実施するシステムであって、
    定められた方針の作成、変更、および前記移動体クライアント・デバイスへの送信を可能にするように構成されたサーバ側プロセスと、
    前記移動体クライアント・デバイスの１つ以上の特性、前記移動体クライアント・デバイスのユーザの１つ以上の特性、および１つ以上のスケジューリング・パラメータによって定められる実施要件に基づいて、前記定められた方針を格納するデータ・ストアと、
    前記実施要件にしたがって、前記方針を前記移動体クライアント・デバイスに送信する送信プロセスと、
    前記移動体クライアント・デバイスにおいて実行され、前記移動体クライアント・デバイスの中にあるＯＭＡ ＤＭ管理ツリーにおける前記定められた方針を、管理対象として格納するように構成されたクライアント側プロセスであって、前記定められた方針の各方針が、前記管理ツリーのサブノードとして表され、更に、前記実施要件にしたがって、前記定められた方針を自動的に実施するように構成された、クライアント側プロセスと、
    を含む、システム。
22. 請求項２１記載のシステムにおいて、ユーザの前記１つ以上の特性が、ユーザ識別、ユーザ特権、ユーザ位置、およびユーザ年齢から成る１群から選択される、システム。
23. 請求項２２記載のシステムにおいて、前記移動体クライアント・デバイスの１つ以上の特性が、デバイス位置、デバイス・アクセス・サービス・タイプ、ならびにデバイス製造業者およびモデルから成る１群から選択される、システム。

Images