JP2016015149A - アプリケーション特有のリソース管理 - Google Patents

Abstract

【課題】限りある数のリソースを利用する複数のアプリケーションを適切にモニタリングするリソース管理システム及び方法を提供する。
【解決手段】少なくとも１つの動作プロファイルを含むサービスの品質モジュールであるＱｏＳモジュール203ａ〜２０３ｃを備えた複数のアプリケーション／プロセス201と、グローバル動作プロファイルを備え、かつ、アプリケーション／プロセス201の動作プロファイルに依存してモバイルデバイス105のリソースを割り当てるように構成されたリソース管理モジュール208とを備える。
【選択図】図２

Description

発明の分野
[0001] 本実施例は、電子デバイスにおけるリソース管理に関連する。より具体的には、これらの実施例は、限りある数のリソースを利用する複数のアプリケーションを適応的にモニタリングするシステムおよび方法に関連する。

関連分野の説明
[0002] デジタルテレビ、デジタルダイレクトブロードキャストシステム（digital direct broadcast system）、ワイヤレス通信デバイス、携帯情報端末（ＰＤＡ）、ラップトップコンピュータ、デスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、セルラまたは衛星無線電話などを含む広い範囲の電子デバイスは、複数の、内部および外部両方のリソースへのアクセスを要求する。これらのデバイスは、非同期的に、メールサーバとコンタクトし、電話およびテキストメッセージを受信し、またはデジタルカメラを動作させている。これらの機能の各々は、ビデオ符号化および復号化、グラフィック処理、アンテナ送信変更、改変バッテリの需要などのような、より低いレベルの動作を要求することができる。アプリケーション、およびそれらが使用するリソースの集合は、総称して、モバイルデバイスの「エコシステム」と称されうる。残念ながら、アプリケーションが様々なリソースを求めているので、結果として生じるリソースの割り当ては概して、ユーザまたはシステム設計者の、好ましいモードの動作とは対応しない。例えば、各々のアプリケーションはメモリの所定の量を要求することができるけれども、いずれの特定のデバイスにおけるメモリの量も固定されている。従っていくつかの点で、もう１つのプログラムを起動することは、デバイスの全体的なメモリの割り当てを厳しく制約することがある。エコシステムは、限定されたリソースのために好ましい仕方で作動しなくなり、早期に停止に、または望ましくない様式（fashion）になりうる。

[0003] 特に、これらのリソースの多くは時間期間にわたって限られた量の累加的サービスのみを、ならびに任意の所与の瞬間に限られた量のサービスのみを提供することができる。多すぎるアプリケーションが一度に１つのリソースにアクセスするとき、または一握りのアプリケーションがリソースを独占するとき、おそらくユーザまたは設計者によってより高く優先される他のアプリケーションは、最適には及ばない状態で動作することになるか、またはまったく動作しなくなる。さらにアプリケーション開発者は概して、彼らのアプリケーションが起動されることになる特定の環境を予期することができず、また彼らはシステム設計者によって課された全ての制限に気付かない。

[0004] ある特定の実施例は、モバイルデバイスリソース管理システムを備える。システムは各々がサービスの品質（quality of service）モジュールを備える複数のソフトウェアアプリケーションを含むことができ、サービスの品質モジュールは少なくとも１つの動作プロファイル（operational profile）を備える。システムは、グローバル動作プロファイル（global operational profile）を備え、ならびにソフトウェアアプリケーションの動作プロファイルに依存してモバイルデバイスのリソースを割り当てるように構成されたリソース管理モジュールを含むことができる。

[0005] いくつかの実施例においてリソースはローカルハードウェアリソース、ローカルソフトウェアリソース、遠隔ハードウェアリソース、および遠隔ソフトウェアリソースを備える。少なくとも１つのローカルソフトウェアリソースは、少なくとも１つの複数のソフトウェアアプリケーションを備えることができる。いくつかの実施例において、第１のアプリケーションの動作プロファイルは第２のアプリケーションの動作プロファイルを参照する。

[0006] ある特定の実施例において、ローカルハードウェアリソースはトランシーバを備える。いくつかの実施例において、少なくとも１つの動作プロファイルは、少なくとも部分的にトランシーバのビットレートに基づいている。動作プロファイルの少なくとも１つは、復号器用にリソースパラメータを指定することができる。

[0007] 少なくとも１つのソフトウェアアプリケーションは、第１の動作プロファイル、第２の動作プロファイル、および遷移機能（transition function）を備えることができ、その機能は、第１の動作プロファイルから第２の動作プロファイルへの遷移の際に実行される。遷移機能はセキュリティチェックを備えることができる。

[0008] いくつかの実施例において、グローバル動作プロファイルは緊急電力管理に関する要件を指定する。少なくとも１つのアプリケーションは、専用バッテリ管理プロセスを備えることができる。リソース管理モジュールは、ソフトウェアアプリケーションの動作プロファイルに定期的にポーリングする（poll）ように構成されうる。

[0009] また、アクティブプロセスの階層を決定すること、新たなプロセスを求めるリクエストを受信すること、新たなプロセスの動作プロファイルにアクセスすること、および少なくとも新たなプロセスの動作プロファイルに基づいて新たなプロセスを開始すべきかどうかを決定することを備える、ソフトウェアアプリケーションを管理するための方法も開示されている。いくつかの実施例において、新たなプロセスを開始すべきかどうかを決定することは、階層における新たなプロセスの位置を決定することを備える。新たなプロセスを開始すべきかどうかを決定することは、階層における少なくとも１つのプロセスを終了させることを備えることができる。

[0010] いくつかの実施例は、コンピュータプロセッサ上で実行されるように構成されたプログラム命令を備えるコンピュータ可読媒体を備え、その命令は、アクティブプロセスの階層を決定するステップ、新たなプロセスを求めるリクエストを受信するステップ、新たなプロセスの動作プロファイルにアクセスするステップ、少なくとも新たなプロセスの動作プロファイルに基づいて新たなプロセスを開始すべきかどうかを決定するステップ、を実行するように構成される。

[0011] いくつかの実施例は、アプリケーションの好ましいセットの動作制約を指定する手段、グローバルセットの動作制約を指定する手段、および、アプリケーションの指定する手段と前記グローバルの指定する手段との間を調停する（arbitrate）手段を備えるモバイルデバイスのためのリソース管理システムを開示している。前記指定する手段は、拡張マークアップ言語（ＸＭＬ）で表される動作プロファイルを備えることができる。前記指定する手段は、アプリケーションのコードで表される動作プロファイルを備えることができる。いくつかの実施例において、グローバルの指定する手段は、ＸＭＬで表されるグローバル動作プロファイルを備える。

[0012] 開示される 実施例の特徴、目的および利点は、同じ参照記号が全体を通して対応して識別する図面と関連して捉えられるとき、以下で述べられる詳細な説明からより明らかになる。
モバイルデバイスおよび、ある特定のローカルおよび遠隔リソースとの様々な関係の１つの実施例のトップレベルのブロック図。 ワイヤレスデバイス内の様々なアプリケーション、それらの互いの関係のいくらか、利用可能なリソースとのそれらの関連、およびリソース管理システムとのそれらの関連のブロック図。 アプリケーションおよびリソース管理モジュールの相関的な構造を描写するモバイルデバイスの概略図。 リソース管理モジュールのある特定の実施例によって用いられる１つのプロセスの論理フロー図。 リソース管理モジュールのある特定の実施例によって用いられる１つのプロセスの論理フロー図。

詳細な説明

[0018] 発明の実施例は、複数のアプリケーションを、それらが電子デバイス内で起動する間、管理するためのシステムおよび方法を含む。各々のデバイスは通常、複数の既定のリソースを有している。１つの実施例において、システムおよび方法は、アプリケーションの開発者の要求仕様（specification）と電子システムのリソース容量との間の電子ネゴシエーションに基づいて各々のアプリケーションの動作を制御する。十分なリソースは、緊急電話の呼び出しおよびバッテリ寿命のような優先されるアプリケーションに、それらがカメラ機能のような重要度のより低い特徴に対して先行するように割り当てられる。アプリケーションが、それらに利用可能なアプリケーション／リソースエコシステムに調整された方法で起動する場合、動作における順序立て（gradation）も可能である。

[0019] １つの実施例において、リソース消費は、少なくとも部分的にアプリケーション開発者の要求仕様とシステム設計者の要求仕様との間のネゴシエーションを容易にするインタフェースによって、各々のアプリケーションに対して決定される。システム設計者が特定のアプリケーションの最適の動きに関する詳細な知識を有することは必要ない。むしろ、この実施例においては、アプリケーション開発者は、アプリケーションのパフォーマンスに関する特徴の知識を例示する複数の適切な動作プロファイルを指定する。この方法で、システム設計者が各々の開発者のアプリケーションに関する膨大な知識を有すことを要求することなく、アプリケーション開発者およびシステム設計者両方にとって満足いくようなより最適なエコシステムが達成されうる。

[0020] １つの実施例において、電子デバイスは、その電話内の電子リソースへのアクセスを制御するリソース管理モジュールを含むワイヤレス電話でありうる。そのようなリソースは、メモリスペース、Ｉ／Ｏポート、およびプロセッサタイムを含むことができる。ユーザによって開始される各々のアプリケーションは、ここではサービスの品質（Quality of Service）モジュールと呼ばれ、以下でより詳しく論じられるような、アプリケーションの最適の動きを制御するためのアプリケーション要求仕様のセットを含む。従って、ユーザが特定のアプリケーションを開始するとき、リソース管理モジュールはアプリケーション要求仕様を読み込み、どのように新たなアプリケーションを扱うべきかについての決定を下す。新たなアプリケーションが他の起動中のアプリケーションよりも高い優先順位を有する場合、リソース管理モジュールは、より低い優先順位を有するアプリケーションをシャットダウンすることができる。代わりに、リソース管理モジュールは、より低い優先順位のアプリケーションに利用可能であるリソースを限定し、新たなアプリケーションにフルセットの要求されるリソースを与えることができる。新たなアプリケーションがワイヤレス電話上で起動している他のアプリケーションよりも低い優先順位を有する場合、そのときリソース管理モジュールは、アプリケーションが開始することを許容せず、その代わりに、新たなアプリケーションを開始するには不十分なリソースしかないという通知をユーザに提供することができる。

[0021] 従って、この実施例において、リソース管理モジュールは、アプリケーションの動作の要件、および電子デバイス内でのそれらの優先順位を読み込む。所定の階層の命令のセットを使用して、リソース管理モジュールは、新たに起動しているアプリケーションが、すでにデバイスに存在する他のアプリケーションに対して優先権を有すべきかどうかを決定する。新たなアプリケーションがより高い優先順位を有する場合、そのときリソース管理モジュールは、新たなプログラムが効率的に起動することができるように、他のプログラムへのリソース割り当てを減少させることを開始させ、または、より低い優先順位のアプリケーションを終了させる。リソース管理モジュールはそれによって、システムがリソース制約されるようになり、機能しなくなり始めるようなときまで、システムが新たなアプリケーションを継続的に開始することを防ぐ。

[0022] 図１は、モバイルデバイス１０５を含むシステム１００を例示する。モバイルデバイス１０５は、メモリ１０６およびプロセッサ１０７を有する。メモリ１０６は、静的メモリ記憶装置、および動的メモリ記憶装置の両方を備えることができる。フラッシュメモリ、ハードドライブ記憶装置などもまた、メモリ１０６に含まれうる。メモリ１０６は、さらに、モバイルデバイスに挿入されうる、加入者識別モジュール（ＳＩＭ）、またはリムーバブルユーザ識別モジュール（Ｒ−ＵＩＭ）も備えることができる。代わりに、モバイルデバイス１０５は、サービス提供者によってメモリ１０６の中にプログラムされた構成データに基づいて動作することができる。プロセッサ１０７は、グラフィックサブプロセッサ、数学コプロセッサ（mathematics coprocessor）、トランスコーディング（transcoding）制御プロセッサなどを含む複数のサブプロセッサを備えることができる。プロセッサ１０７は、さらに、オペレーティングシステムを含む全てのアプリケーションに対する汎用プロセッサとしての役割も果たすことができる。

[0023] 同時に、プロセッサ１０７およびメモリ１０６は、ユーザインタフェース１０８、デバイスインタフェース１０９、およびトランシーバ１１０のような様々な他のデバイスおよびアプリケーションによって、通常オペレーティングシステム（図示せず）を介して使用される。いくつかの実施例におけるユーザインタフェース１０８は、視覚および聴覚機能と同様に触覚システム、つまり、キーボード、タッチスクリーンディスプレイ、ＬＣＤ、干渉変調器のアレイ、オーディオの受信および発生（audio reception and generation）などを備えることができる。デバイスインタフェース１０９は、外部ハードウェアの取り付けのための様々なポートを含むことができる。ユニバーサルシリアルバス（ＵＳＢ）、ＲＳ−２３２シリアル、パラレル、ファイアワイヤなどは全て、デバイスインタフェース１０９によって収容されうる（accommodate）適切なインタフェース規格の例である。これらのインタフェースは、周辺デバイス１０２のような、様々な外部ハードウェアに接続するだろう。周辺デバイスの例は、プリンタ、個人健康デバイス（グルコースモニタ）、追加データ記憶装置などを含む。デバイスインタフェース１０９は、さらに、いくつかの実施例において、ユーザが外部デバイスまたはソフトウェアアプリケーションを通じて選好を設定できるようにコンピュータシステムに接続することができる。モバイルデバイス１０５は通常、バッテリインタフェース、および１つまたは複数の再充電バッテリまたはバッテリパック（図示せず）の両方を含む。バッテリは、モバイルデバイス１０５おける電気回路に電力を供給し、バッテリインタフェースはバッテリに対する機械的かつ電気的接続を提供する。

[0024] デバイスインタフェース１０９は、さらに、モバイルデバイスを更新し、ワイヤレストランシーバ１１０を通じてソフトウェアおよびメディアをダウンロードするように使用されうる。トランシーバ１１０は通常、様々なデータのワイヤレス受信および送信の両方のために使用される。別個のトランシーバは、音声およびデジタルデータのために、または送信および受信用の冗長パスを提供するために使用されうる。トランシーバ１１０は、さらに、赤外線データ協会（ＩｒＤＡ）の通信またはＢｌｕｅｔｏｏｔｈ（登録商標）通信も含むことができる。トランシーバ１１０は、３ＧＰＰ２（第３世代パートナーシッププロジェクト２）規格に従ってＣＤＭＡ（符号分割多元接続）を通じて通信することができる。さらなるワイヤレス通信システムは、ＩＳ−１３６、ＩＳ−９５またはＩＳ−８３３通信システム、移動通信のためのグローバルシステム（ＧＳＭ（登録商標））通信システム、汎用パケット無線サービス（ＧＰＲＳ）通信システム、ユニバーサルモバイル通信システム（ＵＭＴＳ）通信システム、例えば、８０２．１１、８０２．１５、８０２．１６、または８０２．２０規格のような、ＩＥＥＥ（米国電気電子学会）の８０２．ｘｘ規格によって記述されるようなワイヤレスローカルエリアネットワーク（ＷＬＡＮ）通信システム、または直交周波数分割多重（ＯＦＤＭ）通信システムのような第４世代（４Ｇ）通信システムを含む。

[0025] 図１において描写されるように、トランシーバ１１０は、サーバ１０１、ネットワーク接続１０３、および電話サービス接続１０４のような、様々な遠隔ハードウェアリソースおよびデバイスと通信する。これらのデバイスは、それら自体で、モバイルデバイス１０５によって利用される遠隔ソフトウェアリソースを有することができる。所与の瞬間に、モバイルデバイス１０５は、周辺デバイス１０２、サーバ１０１、ネットワーク１０３、および電話サービス接続１０４の各々から情報を受信している。例えばいくつかの実施例において、モバイルデバイス１０５は、電話サービス接続１０４上のユーザ間の呼を管理することと、システム更新のためにサーバ１０１にポーリングすることと、モバイルメディアプレイヤのような周辺デバイス１０２から入力を受信することと、ネットワーク接続１０３から後続のプレイバック用の動画情報を復号することとを同時に行うことができる。加えて、特定のアプリケーションは、さらに、全世界測位システム（ＧＰＳ）のクライアントおよびカレンダーソフトウェアのような、ローカルソフトウェアリソースが同時に動作中であることを要求しながら、バックライトがトーチとして使用されることや、スピーカフォンがアクティブにされることを要求するような、デバイスのローカルハードウェアリソースを求めている。通常ワイヤレス通信ができないコンピュータまたは他の機器がモバイルデバイスに接続するように適応されうることもまた考慮される。そのような事例において、各々のアプリケーションに関する結果として生じる優先順位および利用可能なリソースは劇的に変化しうる。特に関連するのは、一度モバイルデバイスがドッキングステーションに配置されると十分に利用可能になりうる電力であろう。

[0026] さらに、アプリケーションの動作上の制約は、エコシステムの閉ざされた領域（ecosystem’s closed universe）の機能のみではない。時間、使用、および変化する外部条件に伴い、様々なアプリケーションが互いに先行することができる。例えば、引き伸ばされたモバイルデバイスの使用は、トランシーバ１１０が過度の使用でヒートアップするときのように、リソースの使用に不利に影響を及ぼすことがある。トランシーバ１１０の温度は、ある特定の規定のパラメータの範囲を超えた場合、トランシーバ１１０は望ましくない信号雑音を発し、従ってＲＦ基準のアプリケーションは引き下げられた優先順位を与えられるべきである。同様に、モバイルデバイスの再充電バッテリの温度が非常に長い間、ある特定の規定のパラメータの範囲を超えて上がり、バッテリは永続的なダメージを経験しうる。従ってモバイルデバイス１０５は、さらに、１つまたは複数の温度センサおよびバッテリ電圧センサ（図示せず）を含むことができる。例えば、サーミスタは、バッテリ、バッテリパック、トランシーバ１１０、プロセッサ１０７、および他のコンポーネントの温度変化を検出するように使用されうる。温度、電流、および電圧センサは、ローカルにしきい値を決定し、または直接プロセッサに接続されうる。

[0027] 図１において提示されるリソースに加えて、当業者（one）は、これらのモバイルデバイスに共通の他のリソースおよび従属物を容易に認識することになる。例えば、多くのソフトウェアアプリケーションは他のソフトウェアアプリケーションに依存する。例えば、オペレーティングシステムにおける低いレベルのサービス提供プロセス（servicing process）が、それらの特徴のいくらかを裏付ける（instantiate）または支援するために様々なアプリケーションによって依拠されうる。アプリケーションは、さらに、様々なリソースパラメータにポーリングするための、および適正な情報を取り出すための（例えば、ビットレートのような、復号器またはトランシーバのリソースパラメータにポーリングするための）他のプロセスにも依拠することができる。必然的に、アプリケーション開発者は実行時に全ての可能性のあるエコシステム構成を予測することはできない。

[0028] 従って、独立したモジュールとしてまたはプロセッサ１０７上で動作されるプロセスとして、中央リソース管理モジュール（ＲＭＭ（Resource Manager Module））２０８は、アプリケーション開発者の好ましいモードの操作のどれが実施されるべきかを命令するために使用されることになる設計制約（designer constraint）を指定する。それらの部分に関してアプリケーション開発者は、ＲＭＭとのネゴシエーションに基づいて、ＲＭＭとインタフェースで接続し、様々なレベルの動作で起動する（または全く起動しない）ようにそれらのアプリケーションを設計する。ＲＭＭによって課された制約を満たすことができないアプリケーションは終了させられる。このように、ＲＭＭは、ある時間期間に渡るのと同様に所与の瞬間におけるリソースへの要求を効率的に制限することができる。

[0029] 図２は、モバイルデバイス内の様々なモジュール、およびそれらの互いの、ならびにＲＭＭ２０８との関係のいくらかを備えるモバイルデバイスリソース管理システムを例示している。当業者（ｏｎｅ）は、ＲＭＭ２０８はいくつかの実施例においてメモリ１０６とは別個で図示されているけれども、ＲＭＭ２０８は、メモリ１０６において記憶され、かつプロセッサ１０７によって実行されるソフトウェアまたはファームウェアを備えるだろうことは容易に認識するであろう。同様に、ＲＭＭ２０８と複数のアプリケーション／プロセッサ２０１との間の関係は、独立したモジュールを通じて、またはプロセッサ１０７およびメモリ１０６を通じて生じうる。一般的に言えば、モバイルデバイス１０５は、様々な開発者によって作られるメモリ１０６内に記憶される複数のアプリケーション２０１、そのいくつかはオペレーティングシステムの一部を含んでおり、およびその他を備える。アプリケーションはそれら自体が、マルチスレッドの環境で様々な機能を実行する、１つまたは複数のプロセスを備える。このアプリケ―ション全体を通じて、アプリケーションが単一のプロセスまたは多くの様々なプロセスを備えうるので、プロセス管理それ自体がアプリケーション管理の形態であるように２つの用語が交換可能に使用される。各々のアプリケーション／プロセス２０２ａ−ｃは、１つまたは複数のサービスの品質モジュール（ＱｏＳモジュール２０３ａ−２０３ｃ）と関連することができる。図２に図示されている特定の実施例において、別個のＱｏＳモジュール２０３ａ−ｃは別個のプロセス２０２ａ−ｃと関連する。ＱｏＳモジュールは、システム設計者または他の中央エンティティによって発行されたガイドラインに基づいて、アプリケーション／プロセスの各々の開発者によって書き込まれており、アプリケーションが自発的に起動しようとする構成を指定する。これらの構成の各々は、所与のレベルの動作のために好ましいリソースが利用可能であること（preferred resource availability）も含むことができる「動作プロファイル（operational profile）」として称される。動作プロファイルは、ＸＭＬ、ＳＱＬデータベース、内部ソフトウェアデータ構造（アプリケーションコードの一部）などを含む多様なスキームで表されうる。動作プロファイルは、アプリケーションの好ましいセットの動作制約を指定する１つの可能性のある手段としての役目をする。ＱｏＳモジュールの機能は、図３に関して以下で詳しく論じられることになる。「モジュール」と称されるけれども、ＱｏＳモジュールは、いくつかの実施例において、動作プロファイルの集合を備えることができる。

[0030] リソース管理モジュール２０８は、アプリケーション／プロセス２０１および複数のリソース２０５、２０６と相互動作するツールの集合を備える。リソースインタフェース２０９は、アプリケーション／プロセスの各々に関心がある様々なリソースを識別およびモニタリングする。アービトレーションモジュール（arbitration module）２０４は、各々のプロセスのＱｏＳモジュール、利用可能なリソース、および概してモバイルデバイスの望ましい動作を指定する「グローバル動作プロファイル」のうちの少なくとも１つに基づいて所与のエコシステムの適切な動作に関する決定を下す。グローバル動作プロファイルは、さらに、ＸＭＬ、ＳＱＬデータベース、内部ソフトウェアデータ構造（アプリケーションコードの一部）などを含む多様なスキームで表されうる。グローバル動作プロファイルは、グローバルセットの動作制約を指定する１つの可能性のある手段としての役目をする。アービトレーションモジュール２０４の機能は、さらに、図３に関して以下で詳しく論じられることになる。

[0031] リソース２０５、２０６は、ローカルリソース２０５ａ−ｂおよび遠隔リソース２０６ａ−ｂの両方を備える。言及されるように、ローカルリソースは、さらに、アプリケーション／プロセス２０１も備えることができる。リソースインタフェース２０９は、ローカルリソース２０５ａ−ｂおよび遠隔リソース２０６ａ−ｂの両方をモニタリングして、その決断においてアービトレーションモジュール２０４をサポートする。当業者（ｏｎｅ）は、ソフトウェアコールバック、通知キュー（ｎｏｔｉｆｉｃａｔｉｏｎ ｑｕｅｕｅ）、ハードウェア割り込みなど、またはそれらの様々な組み合わせのどちらかを使用してリソースにポーリングすることを含む、インタフェース２０９をインプリメントするための多くの方法を認識することになる。

[0032] 図３は、リソース管理モジュール２０８とプロセス２０２ａとの間の関係をより詳しく例示している。リソース管理モジュール２０８は、複数のグローバル動作プロファイル３０１ａ−ｄを備える。グローバル動作プロファイルは、システム設計者によって指定されうるが、ある特定の実施例は、グローバル動作プロファイルを作る、または指定するデバイスユーザもしくは第３のディストリビュータ（distributer）を考慮する。各々のグローバル動作プロファイルは、エコシステムを渡って適用、または特定の状況のために調整されうる動作のためのある特定の一般的な規格を概説する。例えば、グローバル動作プロファイルは、ある特定のプロセスが他のプロセスに対する優先権を受信しなければならないかどうかを指定するだろう。グローバル動作プロファイルは、さらに、優先のプロセスに対する不可欠で最小のリソース割り当ても指定することができる。動作中、グローバル動作プロファイルは、各々のプロセスのために使用されるべき動作プロファイル、またはプロセスが終了させられるべきかどうかを決定するために、電子デバイス内のエコシステムと比較されうる。新たなプロセスの動作プロファイルは、同様にグローバル動作プロファイルの点から考慮されるだろう。許容できる動作プロファイルが存在する場合、そのプロセスは起動され、そうでなければ、その動作は、おそらく無期限に保留されることになる。リソース管理モジュールと様々なプロセス／アプリケーションとの間のネゴシエーションは、エコシステムの最適な再割り当て、および各々のプロセスの動作プロファイルの選択を決定するために生じうる。そのような再割り当ては、ユーザによって、新たなグローバル動作プロファイルの選択または指定によって始動されうる。いくつかの実施例において、アービトレーションモジュール２０４は、特にこれらのネゴシエーションを容易にするために設計される。アービトレーションモジュール２０４は、そのことに関して、アプリケーションの動作プロファイルとグローバル動作プロファイルとの間をアービトレートするための１つの可能性のある手段としての役割を果たす。この比較およびネゴシエーションは以下でより詳しく説明される。

[0033] 言及されるように、アプリケーション／プロセス２０２ａは、さらに、１つまたは複数の動作プロファイル３０２ａ−ｃを備える。動作プロファイルは、モバイルデバイスのオペレーティングソフトウェア、または内部ファームウェアと接続して供給されるＡＰＩを参照してアプリケーション開発者によって作られる。エコシステムの一般的な動作に関連することよりもむしろ、各々の動作プロファイル３０２は、所与のレベルの動作のために要求されるリソース特性の範囲を指定する。例えば、プロセス２０２ａがビデオをディスプレイにレンダリングすることに関連する場合、低い解像度が第２のセットの低いしきい値で値を要求するだけでありうるのに対し、高い解像度のディスプレイは第１のセットのしきい値でバス帯域幅およびプロセッサが利用可能なことを要求することができる。動作プロファイル３０２ａ−ｃは、これらの条件の各々（様々なリソースＡ、Ｂ、Ｃのパラメータに対する最小レベル１、２、３など）を指定する。ＡＰＩは、さらに、プロセスが動作プロファイル間の遷移を通知されるようにプロトコルを提供することができる。このように、プロセスは「シャットダウン」動作を実行、または機能のグレースフルデグラデーション（graceful degradation）を提供するために「遷移機能（transition function）」を呼び出すことができる。そのような呼は、さらに、アプリケーションが安全でない方法では動作を中止しないけれども終了前に様々な「ハウスクリーニング（house cleaning）」動作を実行する安全な退去（dismissal）を容易にすることができる。加えてプロセス２０２ａは、リソースパラメータに基づいて動作にアクセスするときに開発者によって生成されるパフォーマンスメトリック３０３を参照する、または備えるサービスの品質（ＱｏＳ）モジュール２０３ａにリンクされうる。

[0034] ２つの例が提供される。

緊急呼び出し
[0035] バッテリ電力は、モバイルデバイスの最も重要なリソースの１つを備える。グローバル動作プロファイルは、様々なプロセスの電力要件に関わらず、緊急呼び出しが出されうるように十分な電力が常にとどまらなければならないことを指定することができる。緊急「テキストメッセージ」または呼び出しがなされるべきかどうかはそれ自体がグローバル動作プロファイルにおいて指定されうる。どちらのイベントにおいても、全てのプロセスが、この目的を維持するのに適切なプロファイルで導入され、起動される。通信の受信は、それでも許容されうるけれどもより不利な条件上に抑止されうる。結果としてシステムは、いずれの非緊急通信または機能（例えば、インスタントメッセージ、インターネットブラウジングなど）を許容しない。トランシーバ１１０および周辺インタフェース１０９は電源が切られうる、そしてその使用を要求する動作プロファイルを有するのみのプロセスは終了させられることになる。

[0036] 様々な適切な動作プロファイルの割り当てが、モバイルデバイスが動作中である間、この「緊急状態」に先立ってなされうることは留意されたい。緊急リザーブ（ｅｍｅｒｇｅｎｃｙ ｒｅｓｅｒｖｅ）のための要件は、定期的に再発するネゴシエーションプロセスの間に考慮される多くの制約のうちの１つでしかないだろう。

[0037] さらなる機能が、グローバル動作プロファイルおいて認められる制約の定義において考慮されうる。例えば、モバイルデバイスは時々、緊急呼び出しが終了されられた後に数分間続く緊急コールバック期間に入る。このことは公共安全応答ポイント（Public Safety Answer Point）（ＰＳＡＰ）がユーザの場所を確認できるようにする。このような考慮は、グローバル動作プロファイルの動作に含まれるだろう。システム設計者によって作られる特定の「専用バッテリ管理プロセス」はこれらの動作を管理すること、および緊急電力管理を提供することに専用でありうる。そのようなプロセスは、タイムクリティカルな（time-critical）ユーザ入力の必要性を制限こと、ならびにユーザインタフェース１０８またはトランシーバ１１０が汎用メッセージのために使用するだろう電力を節約することの両方のための「予め築かれた機能」および「既定の緊急メッセージ」を含むことができる。

加入メディアサービス
[0038] 別の例において、アプリケーション開発者は、ペイパービュー方式（ｐａｙ−ｐｅｒ−ｖｉｅｗ）に基づいて、動画のようなメディアをモバイルデバイスのユーザに提供する加入サービスである。「ペイバービュー方式」は、モバイルデバイス上にローカルに記憶されることになるものではないが遠隔ロケーションからリアルタイムに送信される時間依存のメディアの集合を備えるだろう。そのようなサービスシステムは、ユーザがプロバイダによって課された分配制限を乱用、または回避することがないことを確証するために適切な認証およびセキュリティサービスを要求する。いくらかのユーザは、彼らが適切に支払ったマテリアルの視聴を妨害する正真正銘の電力または送信問題を経験しうるのに対し、より悪質なユーザ（more malicious users）が、彼らが一度の視聴にしか支払っていないメディアをリプレイする意図を持ってそのようなイベントをシュミレートすることができる。理論的に言えばシステムはこの２つの間を区別することができる。

[0039] アプリケーション開発者は、リソース（電力、帯域幅）が利用不可能になると、デグラデーションの完全な記録がセキュリティチェックの一部としてローカルに、または遠隔に、のどちらかで記憶および／またはモニタリングされるように、動作プロファイルおよび付随する遷移機能を提供するだろう。リソースが再び利用可能になり、ユーザが、メディアがリプレイされることを要求するとき、アプリケーションは、どれほどの視聴時間が適切にユーザに与えられるべきかを決定するためにログを参照することができる。収入を発生させるために広告を使用するシステムは同様に、要求された広告がメディアを提供する前に再生されていることを確証するためにそのシステムを使用することができる。

[0040] これらの全ての例から明確であるように、リソース管理モジュールそれ自体は、前もって考えられたアプリケーションの「パフォーマンス」の概念または「品質」のコンセプトを有さない場合がある。むしろ、その代わりに、所与のセットのリソースが利用可能であるときに使用されうる機能および関連する動作プロファイルを定義することは、アプリケーションの開発者にゆだねられる。つまり、いずれのリソースパラメータが適切であるか、ならびに、アプリケーションを全く起動しないでおくほどリソースが不十分であるときを決定するのは、開発者である。

[0041] ある特定の実施例においてネゴシエーションは、リソース管理モジュールがまず優先のプロセスを通じて反復し、グローバル動作プロファイルの要求仕様の点からそれがそれらの動作のためにどのリソースをリザーブすることになるかを決定することによって進行する。一度最小の条件が優先のプロセスのために知られると、リソース管理モジュールはその後、すでに起動している、または起動されることを要求している優先でないプロセスを調べるだろう。リソース管理モジュールは、様々なリソースのステータスをプロセスに示すことができる、またはプロセスはそれ自体で決定を下すことができる。どちらのイベントにおいても、プロセスは、好ましい動作プロファイルのリソース要件をリソース管理モジュールに示すことになる。これらの好ましい条件を受信して、リソース管理モジュールは、グローバル動作プロファイルに基づいて、使用傾向およびユーザの選好を優先順位付け（triage）し、動作プロファイルが許容できること、またはより少ないリソースの強力な代わり（a less resource intensive alternative）が使用されるべきことをプロセスに示すことができる。後者の場合、その後プロセスはより適切な動作プロファイルで応答することになる。代わりのプロファイルが存在しない、つまりプロセスが、それが自発的に考慮する動作プロファイルの全てを通じて反復した場合、その後プロセス、またはリソース管理モジュールはプロセスのグレースフルな（graceful）終了を開始することができる。このように、前に記述されたメディアプログラムは、例えば、高い解像度を有する高輝度ディスプレイを、高い解像度を有する薄暗いディスプレイへ、低い解像度を有する薄暗いディスプレイへ、最終的にはグレースフルな終了を実行するために必要な最小のリソースへ向かうように要求するプロファイルを介して遷移することができる。理論的に言うと、システムは、場合によっては、ユーザを促して、プロセスを終了させることに先立ってグローバル動作プロファイルを調整する機会を彼らに提供する。そのような通知は、リソース管理モジュールまたはアプリケーション主導の下でもたらされうる。場合によっては、システムは他と比較して１つのグローバル動作プロファイルを選択することになる結果をユーザに通知することができる。リソース管理モジュールのアクティビティは、さらに、（例えば、配偶者または子供の１人が互いにモバイルデバイスを共有する場合）現在アクティブのユーザプロファイルによって命令されうる。線形プログラミングまたは制約を基準とした分析アルゴリズムは、最適なソリューションエコシステムが様々なアプリケーションの制約を与えられることを識別するために使用されうる。当業者は、ソフトウェアコールバック、ハードウェアインタラプト、定期的なポーリング、または様々な組み合わせのシステムが多くのプロセスの間でネゴシエーションを遂行するために使用されうることを容易に認識するだろう。留意されるように、ユーザは各々のアプリケーションに関する特定の選好を指定することができる。

[0042] 以下で、新たなプロセスの導入に関する２つの可能性のある実施例が説明される。当業者はこれらの方法への多くの変更を容易に認識し、これらが単に一般的な手法を示し、これらのステップがここで示されている様々な順序で実行され、ある特定のステップは完全に省かれうることを理解することになる。図４は、例えば、新たなプロセスが全体の順序付けの一部として識別され、大規模なネゴシエーションの代わりに最適のエコシステムを発見するために反復して取り除かれる、「トライアンドダイ（ｔｒｙ−ａｎｄ−ｄｉｅ）」プロセス４００を例示している。プロセス４００は、開始状態４０１で始まり、その後、ＲＭＭが、通常グローバル動作プロファイルの要件に関連してプロセスの階層を定義する状態４０２に移動する。この階層は、全ての入ってくるプロセス、およびアクティブのプロセスの全体の順序付けを可能にする。当業者は、プロセス間の全ての順序が簡略化のために説明されているけれども、部分的な順序、または細かな（granular）ルールセットを含むための変更が容易に考案されうることを認識することになる。

[0043] プロセス４００はその後、状態４０３で特定の動作プロファイルを起動することを望む別の新たなプロセスによるリクエストを受信する。新たなプロセスが状態４０３で挿入をリクエストするとき、ＲＭＭが、新たなプロセスが階層においていずれの現在起動中のプロセスよりも高いポジションに配置されたかどうかを決定状態４０４で決定することができるように、望ましい動作プロファイルがそのリクエストと共に含まれる。この決定、および階層における新たなプロセスの配置は通常、新たなプロセスにおいて利用可能な動作プロファイル、ユーザの個人設定、およびグローバルファイルを参照して（つまり、プロセスの動作プロファイルにアクセスして）なされるだろう。新たなプロセスのランキングが、決定状態４０４において、いずれの現在起動中のプロセスよりも高くない場合、そのときプロセス４００は新たなプロセスが開始されない状態４０５に移動する。当業者は、例えば、提案された動作プロファイルが最低の起動中のプロセスの最低の動作プロファイルよりも効率的なシステムを提供したかどうかを決定する、決定状態４０４における代わりの決定を容易に認識することができる。あるいは、プロセスが起動されるけれどもリクエストされたものとは別の第２の動作プロファイルを使用する。

[0044] 新たなアプリケーションが階層において少なくとも１つの起動中のプロセスよりも高くランク付けられる決定が、決定状態４０４において下される場合、最低の起動中のプロセスは状態４０６において終了させられ、起動中のプロファイルの結果として生じるＱｏＳがグローバル動作プロファイルと一致するかどうかという決定が決定状態４０７において下される。十分なＱｏＳが決定状態４０７において利用可能でない（つまり、１つまたは複数のプロセスが、グローバル動作プロファイルの要件と反目する動作プロファイルを使用しなければならない）場合、プロセス４００は、新たなアプリケーションがいずれの他の起動中のアプリケーションよりも高いレベルであるかどうかの決定が下される決定状態４０４に戻る。この方法は、適切なＱｏＳが達成されるまで、または新たなプロセスが階層において最低であり、起動することを妨げられるまで、終了させるプロセスを繰り返す。

[0045] 決定状態４０７でグローバル動作プロファイルおよび利用可能なリソースの制約に基づいて、必要なだけのプロセスが代わりに十分なＱｏＳを提示している（つまり、それらが、それらが満足する動作プロファイルを識別した）場合、そのとき新たなプロセスが開始される。プロセス４００はその後、リソースが、新たなプロセスを開始するために、プロセス間で再割り当てされ、または動的に決定されうる状態４１１に移動する。新たなプロセスが、状態４１２においてリクエストされた動作プロファイルで起動されうる。最後に、動作プロファイルおよびグローバル動作プロファイルは、プロセス４００が終了状態４０９で止まる前に、状態４１３において必要に応じて更新されうる。

[0046] 図５は、既存のプロセスが新たなプロセスに対して好まれる、さらに別の「予測的」手法を例示している。プロセス５００は、開始状態５０１で始まり、その後、アクティブプロセスの階層がグローバル動作プロファイルに基づいて決定される状態５０２に移動する。プロセス５００はその後、新たなプロセスを求めるリクエストが受信される状態５０３に移動する。プロセス５００は、次に決定状態５０５に移動し、動作プロファイルのいずれかが現在のグローバル動作プロファイルを満たすことになるかどうかを決定するために新たなプロセスの動作プロファイルを調べる。１つの実施例において、プロセスは、さらに、既存のプロセスのプロファイルを再考することができる。適切な動作プロファイルが、決定状態５０５において、新たなプロセス内に見つけられることができない場合、または既存のプロセスのどれもグローバル動作プロファイルに基づいて新たな動作プロファイルに向けられることができない場合、プロセス５００は、新たなプロセスが起動されないことになる状態５０４に移動する。しかしながら、適切な選択が可能である場合、プロセス５００は、システムの階層における新たなプロセスの位置を決定するための状態５０６に移動する。プロセス５００はその後、リソースがプロセス間で再割り当てされる状態５０７に移動する。１つの実施例において、リソースは適切な動作プロファイルの選択によって割り当てられる。新たなプロセスは次に、状態５０８において、適切な動作プロファイルと共に起動されうるが、一度裏付けられる（instantiated）と、新たなプロファイルが状態５０９において各々のプロセスのＱｏＳに基づいて選択または更新されうる。裏付け後の後続の再割り当ては、予期されない副作用の場合に必要であることがある。動作はその後、終了状態５１０で終了し、システムは次のプロセスの導入を待つ。

[0047] 従って、様々なリソース間で様々なアプリケーションを導く新たなかつ改善された方法および装置が記述されている。当業者は、ここで開示された実施例と関係して記述されている様々な実例となる論理ブロック、モジュール、回路、アルゴリズムステップが電子ハードウェア、コンピュータソフトウェアまたは両方の組み合わせとしてインプリメントされうることを理解するであろう。様々な実例となるコンポーネント、ブロック、モジュール、回路、およびステップは、それらの機能の点から一般的に記述されてきた。ハードウェア、または、ソフトウェアとして機能がインプリメントされるかどうかは、特定のアプリケーションとシステム全体に課された設計制約とに依存する。当業者は、これらの状況下でハードウェアとソフトウェアが交換可能であること、および各々の特定のアプリケーションのために記述された機能をインプリメントすることがどれほど最善であるかを認識する。例として、ここで開示される実施例と関係して記述された様々な実例となる論理ブロック、モジュール、回路、およびアルゴリズムステップが、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタ論理、例えば、レジスタおよびＦＩＦＯのようなディスクリートハードウェアコンポーネント、ファームウェア命令のセットを実行するプロセッサ、任意の従来のプログラマブルソフトウェアモジュールおよびプロセッサ、またはそれらの任意の組み合わせと共にインプリメントまたは実装されうる。プロセッサはマイクロプロセッサでありうるが、代わりとして、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンでありうる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または、当技術分野において周知の記憶媒体の任意の他の形態に存在しうる。当業者は、上記の記述全体を通して参照されうるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場または磁性粒子、光場または光粒子、またはこれらの任意の組み合わせによって示されることをさらに認識するだろう。

[0048] いずれの 当業者も開示された実施例を実施および使用することを可能にするために、好ましい実施例の前述の記述が提供される。これらの実施例に対する様々な変更は当業者には容易に明らかになり、ここで定義された包括的な原理は、発明力の使用なしに他の実施例に適用されうる。従って開示された実施例は、ここで提示された実施例に制限されることを意図せず、ここに開示された原理および新規な特徴と合致する最も広い範囲が与えられるべきである。

[0048] いずれの当業者も開示された実施例を実施および使用することを可能にするために、好ましい実施例の前述の記述が提供される。これらの実施例に対する様々な変更は当業者には容易に明らかになり、ここで定義された包括的な原理は、発明力の使用なしに他の実施例に適用されうる。従って開示された実施例は、ここで提示された実施例に制限されることを意図せず、ここに開示された原理および新規な特徴と合致する最も広い範囲が与えられるべきである。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］ 各々がサービスの品質モジュールを備える複数のソフトウェアアプリケーションであって、前記サービスの品質モジュールは少なくとも１つの動作プロファイルを備える、複数のソフトウェアアプリケーションと、
グローバル動作プロファイルを備え、かつ前記ソフトウェアアプリケーションの前記動作プロファイルに依存して前記モバイルデバイスのリソースを割り当てるように構成されたリソース管理モジュールと
を備える、モバイルデバイスリソース管理システム。
［Ｃ２］ 前記リソースは、ローカルハードウェアリソース、ローカルソフトウェアリソース、遠隔ハードウェアリソース、および遠隔ソフトウェアリソースを備える、Ｃ１に記載のシステム。
［Ｃ３］ 少なくとも１つ前記ローカルソフトウェアリソースは、少なくとも１つ前記複数のソフトウェアアプリケーションを備える、Ｃ２に記載のシステム。
［Ｃ４］ 第１のアプリケーションの動作プロファイルは、第２のアプリケーションの動作プロファイルを参照する、Ｃ３に記載のシステム。
［Ｃ５］ 前記ローカルハードウェアリソースは、トランシーバを備える、Ｃ２に記載のシステム。
［Ｃ６］ 少なくとも１つの前記動作プロファイルは、少なくとも部分的に前記トランシーバのビットレートに基づいている、Ｃ５に記載のシステム。
［Ｃ７］ 少なくとも１つの前記動作プロファイルは、復号器用のリソースパラメータを指定する、Ｃ６に記載のシステム。
［Ｃ８］ 少なくとも１つのソフトウェアアプリケーションは、第１の動作プロファイル、第２の動作プロファイル、および遷移機能を備え、前記機能は、前記第１の動作プロファイルから前記第２の動作プロファイルへの遷移の際に実行される、Ｃ１に記載のシステム。
［Ｃ９］ 前記遷移機能は、セキュリティチェックを備える、Ｃ８に記載のシステム。
［Ｃ１０］ 前記グローバル動作プロファイルは、緊急電力管理に関する要件を指定する、Ｃ１に記載のシステム。
［Ｃ１１］ 少なくとも１つのアプリケーションは、専用バッテリ管理プロセスを備える、Ｃ１０に記載のシステム。
［Ｃ１２］ 前記リソース管理モジュールは、前記ソフトウェアアプリケーションの前記動作プロファイルに定期的にポーリングするように構成される、Ｃ１に記載のシステム。
［Ｃ１３］ アクティブプロセスの階層を決定することと、
新たなプロセスを求めるリクエストを受信することと、
前記新たなプロセスの動作プロファイルにアクセスすることと、
少なくとも前記新たなプロセスの前記動作プロファイルに基づいて前記新たなプロセスを開始すべきかどうかを決定することと、
を備える、ソフトウェアアプリケーションを管理するための方法。
［Ｃ１４］ 前記新たなプロセスを開始すべきかどうかを決定することは、前記階層における前記新たなプロセスの位置を決定することを備える、Ｃ１３に記載の方法。
［Ｃ１５］ 前記新たなプロセスを開始すべきかどうかを決定することは、前記階層における少なくとも１つのプロセスを終了させることを備える、Ｃ１３に記載の方法。
［Ｃ１６］ コンピュータプロセッサ上で実行されるように構成されるプログラム命令を備えるコンピュータ可読媒体であって、前記命令は、
アクティブプロセスの階層を決定するステップと、
新たなプロセスを求めるリクエストを受信するステップと、
前記新たなプロセスの動作プロファイルにアクセスするステップと、
少なくとも前記新たなプロセスの前記動作プロファイルに基づいて前記新たなプロセスを開始すべきかどうかを決定するステップと、
を実行するように構成される、コンピュータ可読媒体。
［Ｃ１７］ アプリケーションの動作制約の好ましいセットを指定する手段と、
動作制約のグローバルセットを指定する手段と、
前記アプリケーションの指定する手段と前記グローバルの指定する手段との間を調停する手段と、
を備える、モバイルデバイスのためのリソース管理システム。
［Ｃ１８］ 前記アプリケーションの指定する手段は、ＸＭＬで表される動作プロファイルを備える、Ｃ１７に記載のシステム。
［Ｃ１９］ 前記アプリケーションの指定する手段は、前記アプリケーションのコードで表される動作プロファイルを備える、Ｃ１７に記載のシステム。
［Ｃ２０］ 前記グローバルの指定する手段は、ＸＭＬで表されるグローバル動作プロファイルを備える、Ｃ１７に記載のシステム。

Claims (20)

1. 各々がサービスの品質モジュールを備える複数のソフトウェアアプリケーションであって、前記サービスの品質モジュールは少なくとも１つの動作プロファイルを備える、複数のソフトウェアアプリケーションと、
   グローバル動作プロファイルを備え、かつ前記ソフトウェアアプリケーションの前記動作プロファイルに依存して前記モバイルデバイスのリソースを割り当てるように構成されたリソース管理モジュールと
   を備える、モバイルデバイスリソース管理システム。
2. 前記リソースは、ローカルハードウェアリソース、ローカルソフトウェアリソース、遠隔ハードウェアリソース、および遠隔ソフトウェアリソースを備える、請求項１に記載のシステム。
3. 少なくとも１つ前記ローカルソフトウェアリソースは、少なくとも１つ前記複数のソフトウェアアプリケーションを備える、請求項２に記載のシステム。
4. 第１のアプリケーションの動作プロファイルは、第２のアプリケーションの動作プロファイルを参照する、請求項３に記載のシステム。
5. 前記ローカルハードウェアリソースは、トランシーバを備える、請求項２に記載のシステム。
6. 少なくとも１つの前記動作プロファイルは、少なくとも部分的に前記トランシーバのビットレートに基づいている、請求項５に記載のシステム。
7. 少なくとも１つの前記動作プロファイルは、復号器用のリソースパラメータを指定する、請求項６に記載のシステム。
8. 少なくとも１つのソフトウェアアプリケーションは、第１の動作プロファイル、第２の動作プロファイル、および遷移機能を備え、前記機能は、前記第１の動作プロファイルから前記第２の動作プロファイルへの遷移の際に実行される、請求項１に記載のシステム。
9. 前記遷移機能は、セキュリティチェックを備える、請求項８に記載のシステム。
10. 前記グローバル動作プロファイルは、緊急電力管理に関する要件を指定する、請求項１に記載のシステム。
11. 少なくとも１つのアプリケーションは、専用バッテリ管理プロセスを備える、請求項１０に記載のシステム。
12. 前記リソース管理モジュールは、前記ソフトウェアアプリケーションの前記動作プロファイルに定期的にポーリングするように構成される、請求項１に記載のシステム。
13. アクティブプロセスの階層を決定することと、
    新たなプロセスを求めるリクエストを受信することと、
    前記新たなプロセスの動作プロファイルにアクセスすることと、
    少なくとも前記新たなプロセスの前記動作プロファイルに基づいて前記新たなプロセスを開始すべきかどうかを決定することと、
    を備える、ソフトウェアアプリケーションを管理するための方法。
14. 前記新たなプロセスを開始すべきかどうかを決定することは、前記階層における前記新たなプロセスの位置を決定することを備える、請求項１３に記載の方法。
15. 前記新たなプロセスを開始すべきかどうかを決定することは、前記階層における少なくとも１つのプロセスを終了させることを備える、請求項１３に記載の方法。
16. コンピュータプロセッサ上で実行されるように構成されるプログラム命令を備えるコンピュータ可読媒体であって、前記命令は、
    アクティブプロセスの階層を決定するステップと、
    新たなプロセスを求めるリクエストを受信するステップと、
    前記新たなプロセスの動作プロファイルにアクセスするステップと、
    少なくとも前記新たなプロセスの前記動作プロファイルに基づいて前記新たなプロセスを開始すべきかどうかを決定するステップと、
    を実行するように構成される、コンピュータ可読媒体。
17. アプリケーションの動作制約の好ましいセットを指定する手段と、
    動作制約のグローバルセットを指定する手段と、
    前記アプリケーションの指定する手段と前記グローバルの指定する手段との間を調停する手段と、
    を備える、モバイルデバイスのためのリソース管理システム。
18. 前記アプリケーションの指定する手段は、ＸＭＬで表される動作プロファイルを備える、請求項１７に記載のシステム。
19. 前記アプリケーションの指定する手段は、前記アプリケーションのコードで表される動作プロファイルを備える、請求項１７に記載のシステム。
20. 前記グローバルの指定する手段は、ＸＭＬで表されるグローバル動作プロファイルを備える、請求項１７に記載のシステム。

Images