"端末装置であって、前記端末装置にインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を記憶する第1の記憶部と、特定プロセスによりアクセスが提供される1つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を記憶する第2の記憶部と、前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する認識部とを備えることを特徴とする端末装置。前記認識部は、さらに、前記アプリケーションの実行により生成されるプロセスを前記プロセスグループの要素として認識することを特徴とする請求項1に記載の端末装置。前記アプリケーションのパッケージに含まれる1つ以上のプログラムをそれぞれ識別するプログラム識別情報を含む構成情報を記憶する第3の記憶部をさらに備え、前記認識部は、前記構成情報を参照することにより、前記アプリケーションの実行により生成される前記プロセスを認識することを特徴とする請求項2に記載の端末装置。前記パッケージは、前記アプリケーションが使用する各資源を識別する第1の資源識別情報を含み、前記使用資源情報は、前記パッケージから抽出される前記第1の資源識別情報、または前記端末装置が使用可能な各資源を識別するように前記第1の資源識別情報と対応づけられて決められた第2の資源識別情報により、前記アプリケーションが使用する前記資源の前記集合を示すことを特徴とする請求項3に記載の端末装置。前記認識部は、認識した前記プロセスグループに属する任意のプロセスの子孫プロセスを、さらに前記プロセスグループの要素として認識することを特徴とする請求項2から4のいずれか1項に記載の端末装置。前記アプリケーションが、起動されるとき、一時停止状態から再開されるとき、バックグラウンドでの実行状態からフォアグラウンドでの実行状態に遷移するとき、またはフォアグラウンドで実行中のときに、前記プロセスグループに含まれるプロセスと前記プロセスグループに含まれないプロセスに対して異なる制御を行う制御部をさらに備えることを特徴とする請求項2から5のいずれか1項に記載の端末装置。前記制御部は、前記プロセスグループに含まれるプロセスの優先度を、前記プロセスグループに含まれないプロセスの優先度よりも高くすることを特徴とする請求項6に記載の端末装置。前記制御部は、前記プロセスグループに含まれるプロセスの実行を継続させ、前記プロセスグループに含まれないプロセスを一時停止させることを特徴とする請求項6に記載の端末装置。前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源を確保している確保中プロセスが、前記プロセスグループに含まれない場合、前記制御部は、前記確保中プロセスが一時停止中であれば、前記確保中プロセスを再開し、前記確保中プロセスが実行中であれば、前記確保中プロセスの実行を継続させることを特徴とする請求項8に記載の端末装置。前記使用資源情報により示される前記資源の前記集合に含まれる資源のうち、少なくとも、前記対応づけ情報により前記特定プロセスと対応づけられていない資源に対するオープン操作とクローズ操作を監視する資源監視部をさらに備え、前記制御部は、前記資源監視部による監視結果にしたがって、前記確保中プロセスを識別することを特徴とする請求項9に記載の端末装置。前記制御部は、前記プロセスグループに含まれるプロセスの実行を継続させ、前記プロセスグループに含まれないプロセスのうち少なくとも一部を強制終了させることを特徴とする請求項6から10のいずれか1項に記載の端末装置。前記端末装置が備えるメモリの空き容量が基準以上であるか否かを監視するメモリ監視部をさらに備え、前記制御部は、前記メモリの空き容量が前記基準未満であることを前記メモリ監視部が検出したときに、前記プロセスグループに含まれないプロセスの少なくとも一部を強制終了させることを特徴とする請求項11に記載の端末装置。前記アプリケーションをフォアグラウンドで実行するための指示の入力を受け付ける入力部をさらに備え、前記制御部は、前記指示の前記入力を前記入力部が受け付けたことを契機として、前記プロセスグループに含まれるプロセスと前記プロセスグループに含まれないプロセスに対して異なる制御を行うことを特徴とする請求項6から12のいずれか1項に記載の端末装置。前記端末装置において使用可能な複数の資源のうち少なくとも一部に対するオープン操作とクローズ操作を監視し、前記オープン操作を検出したとき、検出した前記オープン操作によりオープンされた資源と、検出した前記オープン操作を呼び出したプロセスとを対応づけ、前記クローズ操作を検出したとき、検出した前記クローズ操作によりクローズされた資源と、検出した前記クローズ操作を呼び出したプロセスとの対応づけを解消する資源監視部をさらに備え、前記対応づけ情報のうち少なくとも一部は、或る特定プロセスからの或る特定資源に対するオープン操作を前記資源監視部が検出したときに、前記或る特定資源と前記或る特定プロセスを前記資源監視部が対応づけることにより生成されて、前記第2の記憶部に記憶された情報であることを特徴とする請求項1~9、11~13のいずれか1項に記載の端末装置。前記対応づけ情報は、前記特定資源と前記特定資源以外の資源を区別する第1の区別情報と、前記特定プロセスと前記特定プロセス以外のプロセスを区別する第2の区別情報の一方または双方、前記特定資源を表すファイル名と、前記ファイル名とは独立に前記特定資源を論理的に識別する論理資源識別情報の一方または双方、特定プログラムの実行により前記特定プロセスが生成されるときに前記特定プロセスに動的に割り当てられる、前記特定プロセスに一意のプロセス識別子と、前記特定プログラムを識別するプログラム識別情報の一方または双方、を用いて、前記特定資源を前記特定プロセスと対応づける情報であることを特徴とする請求項1から14のいずれか1項に記載の端末装置。前記端末装置が使用可能な各資源は、前記端末装置に内蔵もしくは接続されている物理デバイス、または前記端末装置が記憶する、データベースもしくは他の所定ファイルであることを特徴とする請求項1から15のいずれか1項に記載の端末装置。コンピュータが実行するプロセス管理方法であって、前記コンピュータにインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を取得し、特定プロセスによりアクセスが提供される1つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を取得し、前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識することを含むことを特徴とするプロセス管理方法。コンピュータに、前記コンピュータにインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を取得し、特定プロセスによりアクセスが提供される1つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を取得し、前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識することを含む処理を実行させることを特徴とするプロセス管理プログラム。様々な分野において、様々に異なる用途に、様々なハードウェア構成の装置が利用されている。そのため、ある特定の装置に適したプロセス管理方法が他の装置にも適しているとは限らない。例えば、或る種の端末装置では、ユーザによるアプリケーションのインストールが制限されている。そして、或る種のプロセス管理方法では、端末装置の性能を引き出すために、限られた特定のアプリケーションしか実行されないという前提条件が利用され、限られた特定のアプリケーションに応じたチューニングが行われることがある。他方、ユーザが任意のアプリケーションをインストールすることのできる端末装置の利用も広まりつつある。ユーザが任意のアプリケーションをインストールすることのできる端末装置においては、上記前提条件が成立しないので、上記の或る種のプロセス管理方法は不適当である。そこで本発明は、任意のアプリケーションがインストールされ得る端末装置におけるプロセス管理に好適な、プロセスのグルーピングを実現することを目的とする。一態様により提供される端末装置は、第1の記憶部と第2の記憶部と認識部を含む。前記第1の記憶部は、前記端末装置にインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を記憶する。また、前記第2の記憶部は、特定プロセスによりアクセスが提供される1つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を記憶する。そして、前記認識部は、前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する。上記端末装置にインストールされた或るアプリケーションが使用する或る資源へのアクセスが、或る特定プロセスによって提供される場合、上記端末装置によれば、上記認識部により認識されるプロセスグループは、当該或る特定プロセスを含む。つまり、当該或るアプリケーションに関連するプロセスグループの要素として、当該或る特定プロセスが認識される。そして、複数の任意のアプリケーションがインストールされた場合でも、上記端末装置の認識部は、各アプリケーションについて同様にプロセスグループを認識することができる。以上のようにして認識されるプロセスグループは、例えば、プロセス間の優先度制御、一時停止するプロセスの決定、強制終了するプロセスの決定など、様々なプロセス管理における管理単位として好適である。そして、上記のようにして認識された適切なプロセスグループを用いて適宜のプロセス管理が行われれば、アプリケーション開発者は、他のアプリケーションの実行に支障をきたさないようにするための特別な仕組みを予めアプリケーション内に組み込む必要がない。すなわち、上記端末装置によるプロセスグループの認識は、アプリケーション開発者の負担を減らして開発と設計の自由度を高めるための基盤技術としての潜在力を有する。以上のように、上記端末装置は、任意のアプリケーションがインストールされ得る端末装置におけるプロセス管理に好適な、プロセスのグルーピングを実現することができる。以下、実施形態について、図面を参照しながら詳細に説明する。まず、図1を参照して第1実施形態について説明する。次に、図2~29を参照して、第2実施形態および第2実施形態に関するいくつかの変形例について説明する。図1は、第1実施形態の端末装置のブロック構成図である。図1の端末装置100は、第1の記憶部101と第2の記憶部102と認識部103を有する。また、端末装置100はさらに第3の記憶部104と制御部105を有することが好ましい。端末装置100はさらに入力部106と資源監視部107とメモリ監視部108を有してもよい。第1の記憶部101と第2の記憶部102と第3の記憶部104は、物理的には1つのメモリモジュール内の異なる3つの記憶領域であってもよいし、物理的に異なるメモリモジュールであってもよい。また、認識部103と制御部105と資源監視部107とメモリ監視部108は、例えば、端末装置100が備える不図示のCPUCentralProcessingUnitにより実現されてもよい。入力部106は、例えば、入力キーであってもよいし、タッチスクリーンでもよい。第1の記憶部101は、端末装置100にインストールされたアプリケーションが使用する資源の集合を示す使用資源情報111を記憶する。図1には、アプリケーションAが資源R1と資源R2と資源R3を使用する場合の使用資源情報111が例示されている。なお、端末装置100には任意の複数のアプリケーションがインストールされ得る。図1には、アプリケーションAについての使用資源情報111のみが例示されているが、第1の記憶部101は、インストールされた複数のアプリケーションのそれぞれについて、同様に使用資源情報111を記憶することができる。また、資源は、具体的には、例えば1a~1cのいずれかであってもよい。1a端末装置100に内蔵もしくは接続されている物理デバイス例えば、サウンドデバイスやセンサなど1b端末装置100が記憶するデータベース1c端末装置100が記憶する所定ファイル例えば、複数のアプリケーションからのアクセスが許可された共通の設定ファイルなどまた、端末装置100において使用可能な資源の中には、ユーザアプリケーションのプロセスからはアクセスされない資源以下特定資源ともいうがある。特定資源へのアクセスは、所定のプログラム以下特定プログラムともいうのプロセス以下特定プロセスともいうにより提供され、ユーザアプリケーションは特定プロセスを介して特定資源にアクセスする。例えば、特定資源は、サウンドチップまたはサウンドカードなどのサウンドデバイスであってもよい。そして、特定プロセスは、サウンドデバイスから音声を出す処理を行うために特定資源を独占的に占有するデーモンプロセスであってもよい。アプリケーションが上記デーモンプロセスに対して音声の出力を要求し、デーモンプロセスが要求にしたがって動作することにより、サウンドデバイスが音声を出力し、スピーカから放音される。なお、特定資源へのアクセスを提供するために特定資源を占有するデーモンは、サービスと呼ばれることもある。換言すれば、特定プロセスは、特定資源へのアクセスのためのAPIApplicationProgrammingInterfaceを提供する。端末装置100の第2の記憶部102は、特定プロセスによりアクセスが提供される1つ以上の特定資源をそれぞれ特定プロセスと対応づける対応づけ情報112を記憶する。図1には、端末装置100から使用可能な資源のうち、資源R1と資源R3が特定資源である場合の対応づけ情報112が例示されている。図1の例では、資源R1に対応する特定プロセスはプロセスP1であり、資源R3に対応する特定プロセスはプロセスP3である。また、図1の例では、資源R2は特定資源ではない。よって、アプリケーションAは、特定プロセスを介さずに、例えば、オープンopen、リードread、ライトwrite、クローズcloseなどのシステムコールを呼び出すことで、資源R2にアクセスする。認識部103は、使用資源情報111と対応づけ情報112を用いて、端末装置100にインストールされたアプリケーションに関連するプロセスグループを認識する。アプリケーションに関連するプロセスグループは、使用資源情報111により示される資源の集合に含まれるいずれかの資源に対応づけ情報112により対応づけられている特定プロセスの集合を、少なくとも含む。例えば、アプリケーションAに関して、使用資源情報111により示される資源の集合は、図1の例では{R1,R2,R3}である。そして、この集合{R1,R2,R3}に含まれるいずれかの資源に、対応づけ情報112により対応づけられている特定プロセスの集合は、図1の例では、{P1,P3}である。したがって、認識部103が認識する、アプリケーションAに関するプロセスグループは、少なくとも、特定プロセスの集合{P1,P3}を含む。以上のようにして認識されるプロセスグループは、プロセス間の優先度制御、一時停止suspendするプロセスの決定、強制終了するプロセスの決定など、様々なプロセス管理における管理単位として好適である。例えば、端末装置100は、アプリケーションAをフォアグラウンドで実行するとき、アプリケーションAを利用するユーザが感じる性能を上げるために、アプリケーションAのプロセスの優先度を上げてもよい。それにより、端末装置100は、アプリケーションAのプロセスに割り当てるCPU時間を増やす。例えば、アプリケーションAのプロセスに割り当てられたCPU時間が多いほど、ユーザによる入力操作から応答までにかかる応答時間が短く、応答時間が短いほど、ユーザが感じる性能は高い。しかしながら、単にアプリケーションAのプロセスの優先度を上げるだけでは、応答時間短縮などの効果が得られないおそれがある。なぜなら、アプリケーションAはプロセスP1を介して資源R1を使用し、プロセスP3を介して資源R3を使用するからである。もし、プロセスP1の優先度が低ければ、プロセスP1にはあまりCPU時間が割り当てられない。その結果、アプリケーションAからプロセスP1を介して資源R1にアクセスするのに時間がかかるかもしれない。プロセスP3についても同様である。よって、応答時間短縮などの効果を得るには、プロセスP1やプロセスP3も含むプロセスグループ全体の優先度を上げることが好ましい。そして、認識部103は、上記のとおり、アプリケーションAに関連するプロセスグループがプロセスP1およびプロセスP3を含むことを認識する。もちろん、一時停止や強制終了など、優先度制御以外のプロセス管理のための管理単位としても、認識部103により認識されたプロセスグループは好適である。また、認識部103は、アプリケーションAの実行により生成されるプロセスも、アプリケーションAに関連するプロセスグループの要素として認識することが望ましい。認識部103は、具体的には、第3の記憶部104に記憶された構成情報113を参照することにより、アプリケーションAの実行により生成されるプロセスを認識してもよい。構成情報113は、アプリケーションのパッケージに含まれる1つ以上のプログラムをそれぞれ識別するプログラム識別情報を含む情報である。プログラム識別情報は、例えばプログラムの名前である。図1に例示した構成情報113は、アプリケーションAのパッケージがA1とA2という名前の2つのプログラムを含むことを示す。アプリケーションAの実行時には、具体的にはこれら2つのプログラムが実行される。よって、認識部103は、構成情報113を参照し、A1とA2という名前の2つのプログラムに対応するプロセスを特定することで、アプリケーションAの実行により生成されるプロセスを認識する。例えば、認識部103は、psコマンドを利用して実行中のプロセスの一覧を得てもよい。プロセスの一覧にはプロセスの名前とプロセス識別子processidentifierPIDが含まれる。また、プロセスの名前としては、プログラムの名前が使われる。よって、認識部103は、プロセスの一覧から、A1とA2という名前の2つのプログラムの実行により生成される2つのプロセスそれぞれのPIDを得ることができる。例えば以上のようにして、認識部103は、構成情報113を参照することにより、アプリケーションAの実行により生成される2つのプロセスを認識することができる。そして、認識部103は、認識した2つのプロセスも、アプリケーションAに関連するプロセスグループの要素として認識する。図1には、以上のようにして認識部103が認識した認識結果114も例示されている。すなわち、認識結果114によれば、アプリケーションAに関連するプロセスグループは、以下の2a~2dの4つのプロセスを含む。2a構成情報113に示されるA1という名前のプログラムの実行により生成されるプロセスPA12b構成情報113に示されるA2という名前のプログラムの実行により生成されるプロセスPA22c使用資源情報111に示される資源R1に対応する特定プロセスであるプロセスP12d使用資源情報111に示される資源R3に対応する特定プロセスであるプロセスP3なお、上記2a~2dのいずれかのプロセスが子孫プロセスを生成し得る場合は、認識部103は、生成された子孫プロセスもアプリケーションAに関連するプロセスグループの要素として認識することが好ましい。また、図1に示すように、端末装置100は、認識部103が認識したプロセスグループを用いてプロセス管理を行う制御部105をさらに有することが好ましい。具体的には、制御部105は、認識部103が認識したプロセスグループに含まれるプロセスと、当該プロセスグループに含まれないプロセスに対して異なる制御を行う。また、端末装置100は、アプリケーションをフォアグラウンドで実行するための指示の入力を受け付ける入力部106さらに有してもよい。アプリケーションをフォアグラウンドで実行するための指示の具体例は、下記の3a~3cである。3a新たにアプリケーションを起動し、起動したアプリケーションをフォアグラウンドで実行するための指示3b一時停止状態のアプリケーションを再開し、再開したアプリケーションをフォアグラウンドで実行するための指示3cバックグラウンドで実行中のアプリケーションを、フォアグラウンドでの実行状態に遷移させるための指示そして、制御部105は、入力部106が指示の入力を受け付けたことを契機として、認識部103が認識したプロセスグループに含まれるプロセスと当該プロセスグループに含まれないプロセスに対して異なる制御を行ってもよい。もちろん、制御部105は、入力部106による入力の受け付け以外のイベントを契機にして、制御を行ってもよい。例えば、制御部105は、以下の4a~4dのいずれのタイミングで制御を行ってもよいが、4dのタイミングは、入力部106による入力の受け付け以外のイベント例えばタイマによる定期的な割り込みを契機として検出されてもよい。4aアプリケーションが起動されるとき4bアプリケーションが一時停止状態から再開されるとき4cアプリケーションがバックグラウンドでの実行状態からフォアグラウンドでの実行状態に遷移するとき4dアプリケーションがフォアグラウンドで実行中のときまた、認識部103が認識したプロセスグループに含まれるプロセスと当該プロセスグループに含まれないプロセスに対して制御部105が行う上記の異なる制御は、より具体的には、例えば以下のような制御である。制御部105は、認識部103が認識したプロセスグループに含まれるプロセスの優先度を、当該プロセスグループに含まれないプロセスの優先度よりも高くしてもよい。あるいは、制御部105は、認識部103が認識したプロセスグループに含まれるプロセスの実行を継続させ、当該プロセスグループに含まれないプロセスを一時停止させてもよい。さらに、制御部105は、使用資源情報111により示される資源の集合に含まれるいずれかの資源を確保しているプロセス以下確保中プロセスというが、認識部103が認識したプロセスグループに含まれない場合、以下の制御を行ってもよい。すなわち、制御部105は、確保中プロセスが一時停止中であれば、確保中プロセスを再開し、確保中プロセスが実行中であれば、確保中プロセスの実行を継続させる。制御部105はさらに、確保中プロセスが確保していた資源を解放したら、確保中プロセスを一時停止させてもよい。例えば、図1の例によれば、アプリケーションAが使用する資源R2は、特定資源ではない。よって、アプリケーションAの実行中に、資源R2が他のアプリケーション説明の便宜上アプリケーションBとするによりアクセスされている可能性がある。しかし、アプリケーションBのプロセスすなわち、アプリケーションBのパッケージに含まれるプログラムの実行により生成されるプロセスは、認識部103が認識したアプリケーションAに関するプロセスグループに属さない。よって、もし制御部105が、認識部103により認識されたプロセスグループに属さないすべてのプロセスを一時停止させてしまうと、資源R2がアプリケーションBのプロセスにより確保されたまま解放されないおそれがある。そこで、制御部105は、上記のとおり、確保中プロセス例えば資源R2をオープンして資源R2にアクセス中のアプリケーションBのプロセスがある場合、確保中プロセスを一時停止させないように制御する。すると、確保中プロセスがいずれ資源を解放すれば、解放された資源へのアクセスが可能となる。つまり、制御部105が上記のように確保中プロセスに関する例外処理を行うことで、認識部103が認識したプロセスグループに基づく一時停止制御に起因する副作用をなくすことができる。具体的には、例えば以下のようにして制御部105が確保中プロセスを識別することができる。図1の例において、対応づけ情報112により対応づけられているのは、特定資源と特定プロセスである。しかし、対応づけ情報112がさらに、特定資源以外の資源と特定プロセス以外のプロセスとを対応づける情報を含んでいてもよい。例えば、アプリケーションBの実行により1つまたは複数のプロセスが生成され得るが、そのうちの1つを、説明の便宜上プロセスPB1と表記することにする。図1の例では、資源R2は特定資源ではないので、資源R2がプロセスPB1により確保されることもあり得る。対応づけ情報112は、資源R2がプロセスPB1により確保されている場合、資源R2とプロセスPB1を対応づける情報を含んでもよい。また、資源R2とプロセスPB1を対応づける情報は、プロセスPB1が資源R2を解放したら、対応づけ情報112から削除される。以上説明したように拡張された対応づけ情報112は、例えば、資源監視部107による監視の結果として得られてもよい。例えば、資源監視部107は、使用資源情報111により示される資源の集合に含まれる資源のうち、少なくとも、対応づけ情報112により特定プロセスと対応づけられていない資源に対するオープン操作とクローズ操作を監視してもよい。すると、制御部105は、資源監視部107による監視結果にしたがって、確保中プロセスを識別することができる。オープン操作は、換言すれば、資源を獲得するための獲得操作である。オープン操作は、具体的にはオープンシステムコールであってもよい。また、クローズ操作は、換言すれば、オープン操作により確保した資源を解放するための解放操作である。クローズ操作は、具体的にはクローズシステムコールであってもよい。よって、或るプロセスが或る資源をオープンしてから当該或る資源をクローズするまでの間は、当該或る資源は、当該或るプロセスにより確保されている。そのため、制御部105は、資源監視部107による監視結果から、確保中プロセスを識別することができる。例えば、図1の例では、資源R2は、特定プロセスと対応づけられてはいないので、資源監視部107は少なくとも資源R2に対するオープン操作とクローズ操作を監視する。上記のとおり、特定資源以外の資源と特定プロセス以外のプロセスとを対応づける情報をさらに含むように、対応づけ情報112が拡張される実施形態では、資源監視部107が以下の5a~5bのように動作してもよい。5aプロセスPB1が資源R2をオープンしたとき、資源監視部107は、資源R2とプロセスPB1を対応づける情報を、対応づけ情報112に追加する。5bプロセスPB1が資源R2をクローズしたとき、資源監視部107は、資源R2とプロセスPB1を対応づける情報を、対応づけ情報112から削除する。すなわち、資源監視部107は、資源R2とプロセスPB1の対応づけを解消する。以上のとおり、拡張された対応づけ情報112には、資源監視部107による監視結果が反映される。よって、制御部105は、拡張された対応づけ情報112を参照することで、確保中プロセスを識別してもよい。また、特定資源と特定プロセスの対応づけは、予め静的に対応づけ情報112に記録されていてもよいし、資源監視部107により動的に行われてもよい。資源監視部107は、具体的には以下のように動作してもよい。資源監視部107は、端末装置100において使用可能な複数の資源のうち少なくとも一部に対するオープン操作とクローズ操作を監視する。資源監視部107は、特定資源以外の資源に対するオープン操作とクローズ操作を監視するだけでなく、特定資源に対するオープン操作とクローズ操作を監視してもよい。そして、資源監視部107は、オープン操作を検出したとき、検出したオープン操作によりオープンされた資源と、検出したオープン操作を呼び出したプロセスとを対応づける。具体的には、資源監視部107は、資源とプロセスを対応づける情報を、拡張された対応づけ情報112に追加することで、資源とプロセスの対応づけを行ってもよい。また、資源監視部107は、クローズ操作を検出したとき、検出したクローズ操作によりクローズされた資源と、検出したクローズ操作を呼び出したプロセスとの対応づけを解消する。具体的には、資源監視部107は、資源とプロセスを対応づける情報を、拡張された対応づけ情報112から削除することで、対応づけの解消を行ってもよい。そして、上記のとおり資源監視部107の監視対象の資源の中には、特定資源が含まれていてもよい。或る特定資源が監視対象の場合、対応づけ情報112のうち少なくとも一部すなわち、当該或る特定資源に対応する部分は、当該或る特定プロセスからの或る特定資源に対するオープン操作を資源監視部107が検出したときに動的に生成される情報である。つまり、対応づけ情報112のうち当該或る特定資源に対応する部分は、当該或る特定資源と当該或る特定プロセスを資源監視部107が対応づけることにより生成されて、第2の記憶部102に記憶された情報である。以上説明したように、対応づけ情報112は、特定資源以外の資源と特定プロセス以外のプロセスとの対応づけをも示すように拡張されてもよい。また、対応づけ情報112のうち、特定資源と特定プロセスの対応づけを示す部分は、静的に予め作られていてもよいし、特定プロセスが特定資源を実際にオープンしたときに生成されてもよい。ところで、制御部105は、認識部103が認識したプロセスグループに含まれるプロセスの実行を継続させ、当該プロセスグループに含まれないプロセスのうち少なくとも一部を強制終了させてもよい。プロセスの強制終了により、端末装置100が備えるメモリの空き容量を増やすことができる。例えば、図1の例において、アプリケーションAのフォアグラウンドでの実行中に、メモリの空き容量が少なくなったとき、制御部105は、認識部103が認識したプロセスグループに含まれないプロセスのうちの少なくとも一部を、強制終了させてもよい。すると、フォアグラウンドで実行中のアプリケーションAが使用可能なメモリの容量が増える。その結果、アプリケーションAを使用中のユーザが感じる性能が高まると期待される。そこで、状況に応じた強制終了を可能とするため、端末装置100は、メモリ監視部108を有してもよい。メモリ監視部108は、アプリケーションが使用可能なメモリの空き容量が基準以上であるか否かを監視する。なお、当該基準は、例えば、下記6a~6dのうちの1つ以上の組み合わせにより定義される基準であってもよいし、他の適宜の基準が使われてもよい。6a固定的に決められた閾値6bプロセスから割り当てを要求されたメモリの量そのもの6c上記6bの量に、所定の数α1α1>1を掛けた量6d上記6bの量に、所定の数α2α2>0を足した量そして、メモリの空き容量が基準未満であることをメモリ監視部108が検出したときに、制御部105は、認識部103により認識されたプロセスグループに含まれないプロセスの少なくとも一部を、強制終了させてもよい。例えばアプリケーションAのフォアグラウンドでの実行中に、以上のような強制終了処理が行われる場合、アプリケーションAとは無関係なプロセスが強制終了される。よって、アプリケーションAを利用中のユーザは、応答性能が悪いとあまり感じないであろう。以上説明したように、認識部103によるプロセスグループの認識と、認識されたプロセスグループに基づく制御部105による制御は、高度なプロセス管理を実現する。プロセス管理の適否は、端末装置100のハードウェアが貧弱な場合は特に、ユーザが感じる性能に与える影響が大きい。したがって、認識部103が認識したプロセスグループに基づく制御部105による制御は、端末装置100が貧弱なハードウェアしか持たない場合に特に好適である。端末装置100は、例えば、携帯電話、スマートフォン、タブレット端末、PDAPersonalDigitalAssistant、ノート型PCPersonalComputer、デスクトップ型PCのいずれであってもよい。そして、多くの場合、PCに比べると、携帯電話、スマートフォン、タブレット端末、およびPDAは、消費電力、発熱量、および製造コストなどの様々な制約上、CPUの性能が劣り、搭載しているメモリの容量も少ない。よって、携帯電話、スマートフォン、タブレット端末、PDAなどの、ハードウェアが比較的貧弱な端末装置では、ユーザにハードウェアの貧弱さをなるべく感じさせないような制御が実装されることが好ましい。そして、本実施形態によれば、制御部105が行う制御によって適切なプロセス管理がなされる。よって、端末装置100では、例えば、次の7aや7bなどの効果が得られるので、ユーザがハードウェアの貧弱さあまり感じずに済む。つまり、たとえ端末装置100のハードウェアが貧弱でも、ユーザが感じる性能は、比較的良好である。7aフォアグラウンドで実行されているアプリケーションの応答時間が短い7bフォアグラウンドで実行されているアプリケーションがメモリ不足に陥りにくいまた、本実施形態によれば、ユーザが感じる性能は、制御部105による制御によって改善される。したがって、個々のアプリケーションの開発者は、ユーザが感じる性能を悪化させないために、他のアプリケーションとの相互の影響を考慮に入れたチューニングを行うなどの作業をしなくてもよい。すなわち、本実施形態によれば、アプリケーション開発者の設計の自由度が高まる。さらに、制御部105が一時停止制御を行う場合、本実施形態には、消費電力を低減する効果もある。ところで、図1では、説明の便宜上、プロセスや資源などが英数字で表記されている。しかし、プロセスや資源などを示すのにそれぞれ用いる情報の種類は、実施形態に応じて様々であってよい。例えば、ある種のOSOperatingSystemでは、デバイスへのアクセスのインタフェイスを提供するために、スペシャルファイルデバイスファイルとも呼ばれるが使われる。よって、資源が物理デバイスである場合、当該物理デバイスに対応するスペシャルファイルのファイル名が、資源を識別する資源識別情報として利用されてもよい。また、資源がデータベースであれば、データベースファイルのファイル名が資源識別情報として利用可能である。そして、資源が所定のファイルであれば、当該所定のファイルのファイル名が資源識別情報として利用可能である。なお、以上の説明におけるファイル名は、より具体的には、ルートディレクトリからのパスを含む/dev/tty1のようなフルパスファイル名であってもよい。もちろん、ファイル名とは独立に資源を論理的に識別するような情報便宜上論理資源識別情報というが使われてもよい。例えば、各資源を表す一意な文字列または一意な番号が予め決められていれば、当該文字列または当該番号が論理資源識別情報として使われてもよい。例えば、サウンドデバイスの論理資源識別情報として、サウンドという予約文字列が使われてもよい。また、例えば後述の図7の資源ファイル対応表504aのように、各資源のファイル名と論理資源識別情報とを対応づける情報がさらに使われてもよい。また、プロセスは、プロセス名によって表されてもよいし、PIDによって表されてもよい。たとえプロセスがプロセス名によって表されていても、例えばpsコマンドなどを利用することで、プロセス名からPIDを特定することが可能である。認識部103が最終的に認識するプロセスグループは、具体的には、PIDの集合により表されてもよい。そして、アプリケーションや、アプリケーションのパッケージに含まれるプログラムは、名前により表すことができる。また、使用資源情報111、対応づけ情報112、構成情報113および認識結果114の具体的なフォーマットも実施形態に応じて様々であってよい。図1に例示したフォーマットは、理解を助けるための一例にすぎない。例えば、アプリケーションのパッケージが構成情報113を含んでいてもよく、パッケージ情報113はパッケージから抽出されて第3の記憶部104に記憶されてもよい。そして、アプリケーションのパッケージがさらに、アプリケーションが使用する各資源を識別する第1の資源識別情報を含んでもよい。第1の資源識別情報は、具体的には、上記の論理資源識別情報例えば、各資源に対して予め決められた一意な文字列などであってもよい。使用資源情報111は、具体的には、アプリケーションのパッケージから抽出される第1の資源識別情報により、アプリケーションが使用する資源の集合を示してもよい。例えば、アプリケーションのパッケージは、後述の図7のパッケージ情報DB506aのような形式の情報を含んでもよい。この場合、第1の資源識別情報は、図7の利用外部資源名リストの各要素のように、例えばサウンドなどの文字列であってもよい。あるいは、使用資源情報111は、端末装置100が使用可能な各資源を識別するように第1の資源識別情報と対応づけられて決められた第2の資源識別情報により、アプリケーションが使用する資源の集合を示してもよい。第2の資源識別情報は、具体的には、資源のファイル名であってもよい。なお、第1と第2の資源識別情報の対応づけは、例えば、後述の図7の資源ファイル対応表504aのような情報により定義されていてもよい。また、対応づけ情報112の具体的なフォーマットも実施形態に応じて様々であってよい。対応づけ情報112は、特定資源を特定プロセスと対応づけることさえ可能であればどのようなフォーマットであってもよく、物理的には複数のファイルに分けられた情報であってもよい。例えば、対応づけ情報112は、下記8a~8cの情報を含む情報であってもよい。つまり、下記8a~8cの情報の対応づけにより特定資源を特定プロセスと対応づける情報が、対応づけ情報112として使われてもよい。8a特定資源と特定資源以外の資源を区別する第1の区別情報と、特定プロセスと特定プロセス以外のプロセスを区別する第2の区別情報の、一方または双方8b特定資源を表すファイル名と、ファイル名とは独立に特定資源を論理的に識別する論理資源識別情報の、一方または双方8c特定プログラムの実行により特定プロセスが生成されるときに特定プロセスに動的に割り当てられる、特定プロセスに一意のプロセス識別子例えばPIDと、特定プログラムを識別するプログラム識別情報の、一方または双方なお、上記8aにおける第1の区別情報は、例えば、端末装置100が使用可能な複数の資源に対してそれぞれ0または1に設定されるフラグであってもよい。後述の図7の資源ファイル対応表504aにおけるフラグは、第1の区別情報の具体例である。あるいは、第1の区別情報は、特定資源を識別する情報例えば、特定資源のファイル名、一意に決められた文字列、一意に決められた番号、などを要素として含むリストまたは他の形式のデータであってもよい。つまり、当該リストに識別情報が含まれる資源は特定資源であり、当該設定ファイルに識別情報が含まれない資源は特定資源以外の資源である。したがって、当該リストによれば、特定資源と他の資源を区別することが可能である。例えば、後述の図7の資源プロセス名対応表520aにはエントリが1つしか例示されていないが、エントリの数は複数でもよい。そして、資源プロセス名対応表520aの外部資源名の列は、第1の区別情報の具体例でもある。また、特定プロセスは、具体的には、或る特定プログラムの実行により生成されるプロセスであるから、特定プロセスの名前は、当該特定プログラムの名前である。例えば、サウンドデバイスが特定資源であり、サウンドデバイスを占有するデーモンプログラムがサウンドデーモンという名前ならば、特定プロセスのプロセス名もサウンドデーモンである。よって、上記8aにおける第2の区別情報は、例えば、特定プロセスの名前のリストまたは他の形式のデータであってもよい。つまり、当該リストにプロセス名が含まれるプロセスは特定プロセスであり、当該リストにプロセス名が含まれないプロセスは特定プロセス以外のプロセスである。したがって、当該リストによれば、特定プロセスと他のプロセスを区別することが可能である。例えば、後述の図7の資源プロセス名対応表520aのエントリの数は、複数でもよい。そして、資源プロセス名対応表520aのプロセス名の列は、第2の区別情報の具体例でもある。また、上記8bの情報の具体例は、例えば、後述の図7の資源ファイル対応表504aにおける3番目のエントリすなわち、1という値のフラグにより、特定資源に対応することが示されているエントリである。上記8bの情報の他の具体例は、図7の資源依存関係表505aの3番目のエントリにおける資源ファイル名であり、さらに他の具体例は、図7の資源プロセス名対応表520aの外部資源名列である。そして、上記8cのプログラム識別情報は、具体的には特定プログラムの名前である。例えば、特定プログラムの名前がサウンドデーモンである場合、上記8cの情報の具体例は、後述の図7のプロセス一覧507aにおける、サウンドデーモンというプロセス名すなわちプログラム名である。また、図7のプロセス一覧507aにおける、サウンドデーモンに対応する10というPIDも、8cの情報の具体例である。以上説明したように、8a~8cの情報を含む対応づけ情報112は、例えば図7に例示するいくつかのテーブルに分散した情報であってもよい。そして、対応づけ情報112は、特定資源に対する獲得操作と解放操作の監視に基づいて生成されてもよい。監視は、例えば資源監視部107により行われてもよい。例えば、後述の図7の資源依存関係表505aの少なくとも一部のエントリは、対応づけ情報112における上記8bと8cの対応づけに使われてもよい。そして、資源依存関係表505aは、詳しくは後述するとおり、監視に基づいて動的に書き換えられる。あるいは、特定資源と特定プロセスの関係は予め決められているので、監視なしに、対応づけ情報112が予め定義されていてもよい。対応づけ情報112が予め定義される場合、認識部103は、特定プロセスの名前とPIDの対応関係を、例えばpsコマンドなどを用いて認識することで、PIDにより各プロセスを表したプロセスグループを認識することができる。例えば、後述の図7の資源プロセス名対応表520aは、特定資源と特定プロセスを予め対応づける対応づけ情報112の一例である。そして、認識部103は、psコマンドにより図7のプロセス一覧507aを得ることができ、プロセス一覧507aから特定プロセスの名前とPIDの対応関係を認識することができる。ところで、以上説明した第1実施形態において、認識部103が認識するプロセスグループを形式的に定義すれば、以下のとおりである。まず、任意のアプリケーションxに対してプロセスの集合definedxと資源の集合usedxを式1と2のように定義する。definedpアプリケーションxのパッケージに含まれると定義されているプログラムの実行により、プロセスpが生成されるusedrアプリケーションxが資源rを使うことが定義されている}認識部103は、式1のプロセスの集合definedxを、構成情報113とpsコマンドに基づいて、認識することができる。また、認識部103は、式2の資源の集合usedxを、使用資源情報111から認識することができる。さらに、任意の資源の集合Rに対してプロセスの集合serviceRを式3のように定義する。式3は特定プロセスの集合を表す。servicep∧以上の式1~3を用いると、認識部103が任意のアプリケーションxに関して認識するプロセスグループgroupxは、式4のように表現することができる。groupdefined∪service認識部103は、使用資源情報111と対応づけ情報112を用いて、式4におけるserviceusedxを認識する。また、図1の例を式1~4に代入すると、具体的には式5~8が得られる。definedPA1PA2usedR1R2R3serviceP1P3groupPA1PA2P1P3ところで、より好ましくは、認識部103は、アプリケーションxに関して式9のプロセスグループgroupxを認識するとよい。なぜなら、式4で定義されるプロセスグループに属するいずれかのプロセスが、子孫プロセスを生成する可能性があるからである。groupdefined∪service∪descendant∪serviceなお、任意のプロセスの集合Pに対して、プロセスの集合descendantPは、式10のとおりであるとする。descendantq∧さて、続いて、図2~29を参照して第2実施形態と、第2実施形態に関わるいくつかの変形例について説明する。なお、第2実施形態とその変形例は、PCにも適用可能だが、携帯電話、スマートフォン、タブレット端末、PDAなどの、PCと比べてハードウェアが比較的貧弱な端末装置に好適である。以下では便宜上、第2実施形態がスマートフォンに適用される場合を例にして説明する。図2は、スマートフォンのハードウェア構成図である。図2のスマートフォン200は、CPU201、RAMRandomAccessMemory202、無線LANLocalAreaNetworkインタフェイス203、フラッシュメモリ204を有する。また、スマートフォン200は、SDSecureDigitalメモリカード220のカードリーダ/ライタ205も有する。スマートフォン200はさらに、入力キー206、ディスプレイ207、マイク208、スピーカ209、3G第3世代通信機210、GPSGlobalPositioningSystem受信機211、および加速度センサ212を有する。スマートフォン200内の各部は、バス213を介して互いに接続されている。CPU201は、様々なプログラムをRAM202にロードして実行する。また、CPU201は、RAM202をワークエリアとしても用いる。また、CPU201は、音声出力機能を有してもよい。すなわち、スマートフォン200が使用するサウンドデバイスが、具体的にはCPU201であってもよい。もちろん、スマートフォン200は、サウンドデバイスとして、CPU201とは別のオンボード型サウンドチップを有してもよい。あるいは、サウンドデバイスとしてのサウンドカードがスマートフォン200に取り付けられていてもよい。無線LANインタフェイス203は、例えば、IEEEInstituteofElectricalandElectronicsEngineers802.11シリーズの規格に則った通信インタフェイスであり、アンテナ、変調器、復調器などを含む。スマートフォン200は無線LANインタフェイス203を介してIPInternetProtocolネットワークに接続可能である。また、フラッシュメモリ204には、様々なプログラムや、その他のデータが記憶される。フラッシュメモリ204の代わりに他の種類の不揮発性記憶装置例えばハードディスク装置が使われてもよい。また、SDメモリカード220は、コンピュータ読み取り可能な記憶媒体の一例である。そして、カードリーダ/ライタ205は、記憶媒体の駆動装置の一例である。入力キー206は、ユーザからの入力を受け付ける入力装置の一例である。ディスプレイ207はタッチスクリーンであってもよい。タッチスクリーンは入力装置でもあり出力装置でもある。また、マイク208も入力装置の一例である。スピーカ209は出力装置の一例である。また、3G通信機210もアンテナ、変調器、復調器などを含む。スマートフォン200は、3G通信機210を介して3G通信ネットワークに接続可能である。3G通信機210は、電話機能およびデータ通信機能を提供する。GPS受信機211は、GPS衛星からの測位信号を受信して、スマートフォン200の位置を計算し、出力する。また、加速度センサ212は、スマートフォン200にかかる加速度を感知し、出力する。加速度センサ212の出力は、例えば、ディスプレイ207の表示方向の切り換えなどにも利用される。スマートフォン200は、不図示の他のセンサをさらに有してもよいし、不図示のカメラをさらに有してもよい。なお、携帯電話、スマートフォン、タブレット端末、PDA、PCなど各種の端末装置は、いずれもコンピュータの一種である。携帯電話、タブレット端末、PDA、PCなどの端末装置も、図2のスマートフォン200と同様に、CPUとRAMと記憶装置と入出力装置を備え、好ましくは、さらに何らかの通信インタフェイスおよび記憶媒体の駆動装置をさらに備える。通信インタフェイスの例は、有線LANインタフェイス、無線LANインタフェイス、3G通信機などである。また、端末装置の種類によっては、フラッシュメモリ204の代わりにハードディスク装置が使われてもよい。そして、SDメモリカード220のカードリーダ/ライタ205の代わりに、他の種類の記憶媒体の駆動装置が使われてもよい。利用可能な記憶媒体の例は、磁気ディスク、光磁気ディスク、CDCompactDiscやDVDDigitalVersatileDiskなどの光ディスク、USBUniversalSerialBusメモリなどの半導体メモリなどである。なお、RAM202、フラッシュメモリ204、ハードディスク装置なども一種の記憶媒体である。そして、以上例示した種々の記憶媒体は、いずれも有形のtangible媒体であり、信号搬送波のような一時的なtransitory媒体ではない。また、CPU201が実行するプログラムは、予めフラッシュメモリ204またはハードディスク装置にインストールされていてもよい。または、プログラムは、SDメモリカード220またはその他の記憶媒体に記憶されて提供され、カードリーダ/ライタ205または適宜の駆動装置により読み取られて、端末装置にインストールされてもよい。あるいは、プログラムは、無線LANインタフェイス203または3G通信機210などの通信インタフェイスを介して、ネットワークから端末装置にダウンロードされてもよい。続いて、図2に示すハードウェア構成を有するスマートフォン200に適用される第2実施形態について詳しく説明する。ここで、第2実施形態の利点についての理解を助けるため、従来の携帯電話および汎用のPCと比較しながら、スマートフォンの特徴について説明する。従来の携帯電話の組み込みOSでは、シングルウィンドウシステムが採用されている。また、従来の携帯電話の組み込みOSは、シングルタスクOSである。したがって、従来の携帯電話においては、現在アクティブなウィンドウのアプリケーションがCPUを占有し、バックグラウンドで並列に実行されるアプリケーションはない。よって、バックグラウンドのアプリケーションとフォアグラウンドのアプリケーションを調停する必要がそもそもない。また、従来の携帯電話では、ユーザが任意のアプリケーションをインストールすることもない。他方、汎用的なPCには、ユーザが任意のアプリケーションをインストールすることができる。また、インストールされたアプリケーションは、必ずしもパッケージ管理されているとは限らないので、各アプリケーションに関するメタ情報は必ずしも利用可能ではない。なお、アプリケーションに関するメタ情報の例は、例えば、アプリケーションパッケージに含まれる実行プログラムの名前や、アプリケーションが利用する資源の名前などである。そして、汎用的なPC用のOSデスクトップOSともいうでは、マルチウィンドウシステムが採用されている。また、汎用的なPC用のOSは、マルチタスクOSである。よって、現在アクティブなウィンドウのアプリケーション以外に、バックグラウンドで他のアプリケーションも実行される状況がしばしば生じる。換言すれば、汎用的なPCにおいては、必ずしもメタ情報が利用可能ではない任意の複数のアプリケーションが、並行して実行されるという状況がしばしば起こり得る。しかし、並行してフォアグラウンドとバックグラウンドで複数の任意のアプリケーションが実行される場合、アプリケーション間の優先度を自動的に判定することは困難である。よって、汎用的なPCでは、バックグラウンドのアプリケーションとフォアグラウンドのアプリケーションを優先度に応じて調停することで、優先度の高いアプリケーションにCPU時間をより多く割り当てるといった制御は困難である。しかしながら、汎用的なPCは、携帯電話やスマートフォンなどの端末装置と比べれば、ハードウェアが潤沢である。例えば、スマートフォンと比較すると、汎用的なPCでは、搭載されているCPUのクロック周波数がより高く、搭載されているメモリの容量がより多い。したがって、たとえ優先度に応じたアプリケーション間の調停が行われなくても、汎用的なPCは、ユーザに特段の性能低下を感じさせずに、複数のアプリケーションを並行して実行することが可能である。つまり、汎用的なPCでは、バックグラウンドのアプリケーションとフォアグラウンドのアプリケーションを優先度に応じて調停する必要性があまりない。それに対して、スマートフォンでは、バックグラウンドのアプリケーションとフォアグラウンドのアプリケーションを優先度に応じて調停することが好ましい。理由は、次のとおりである。スマートフォン用の最近のOSはマルチタスクOSである。よって、複数のアプリケーションが並行して実行され得る。他方で、スマートフォンは、汎用的なPCと比べて貧弱なハードウェアしか持たないことが多い。したがって、スマートフォンでは、汎用的なPCと同様に複数のアプリケーションが並行して実行された場合、例えば応答時間の長期化などにより、ユーザが不便を感じてしまうことがある。そこで、ユーザに感じさせる不便さを低減するために換言すれば、ユーザが感じる性能を向上させるために、スマートフォンにおいてはアプリケーション間の調停が有効である。そして、第2実施形態によれば、スマートフォン用のOSの特性を利用することで、アプリケーションの調停のためのプロセス制御に有益なプロセスグループが得られる。具体的には、第2実施形態では、次の9aと9bの特性が利用される。9aスマートフォン用のOSでは、シングルウィンドウシステムが採用されている。よって、ユーザが現在対話的に利用しているフォアグラウンドのアプリケーションは、一意に特定可能である。9bスマートフォン用のOSは、スマートフォンにインストールされるアプリケーションのパッケージを管理するパッケージ管理モジュールを含む。よって、たとえ任意のアプリケーションがインストールされようとも、どのアプリケーションについても、メタ情報であるパッケージ情報が利用可能である。なお、パッケージ情報は、より具体的には、アプリケーションパッケージに含まれる1つまたは複数のバイナリプログラムを識別する情報と、アプリケーションが直接または間接にアクセスする資源を識別する情報とを含む。上記9aの特性は、優先度の高いアプリケーションの判別のために使われる。そして、9bの特性は、アプリケーションに関連するプロセスグループの認識のために使われる。続いて、ストリーミング配信される動画を再生する動画再生アプリケーションを例に、具体的にどのプロセスをプロセスグループのメンバとして認識することが適切なのかということに関する方針の概要を説明する。図3は、適切なプロセスグループの例を説明する図である。図3の例では、スマートフォン300が、サーバ310と、WANWideAreaNetwork320を介して接続されている。WAN320の代わりに、インターネット、LAN、3G通信ネットワークなど任意のネットワークにより、スマートフォン300がサーバ310と接続されていてもよい。スマートフォン300には動画再生アプリケーション301がインストールされている。動画再生アプリケーション301は、動画再生モジュール302とダウンロードモジュール303を含む。なお、図3にはスマートフォン300のOSのカーネル304と、OSが提供する標準的なサービス305と、サウンドデバイス306も図示されている。サウンドデバイス306は、具体的には、例えば、サウンド機能を持つCPU、CPUとは独立したオンボード型のサウンドチップ、または外付けのサウンドカードであってもよい。サーバ310は、動画DBデータベース311を有する。また、サーバ310上では、ファイル転送サービス312が動作している。ファイル転送サービス312は、スマートフォン300からの要求に応じて、動画DB311から動画ファイル313を読み出し、動画ファイル313をパケット化する。図3の例では、パケット化された3つの動画断片331~333が例示されている。そして、ファイル転送サービス312は、WAN320を介して動画断片331~333をスマートフォン300に送信する。スマートフォン300が、例えばユーザからの指示に応じて動画再生アプリケーション301を起動すると、動画再生モジュール302がフォアグラウンドで動作し、ダウンロードモジュール303がバックグラウンドで動作する。具体的には、ダウンロードモジュール303は、サーバ310から動画断片331~333をダウンロードしてメモリに記憶する。そして、動画再生モジュール302は、ダウンロードされてメモリに記憶された動画断片331~333を再生する。再生は、具体的には、サービス305を介して行われる。様々なアプリケーションにより使用され得るサウンドデバイス306は、サービス305つまりOSにより提供される一種のデーモンにより占有され、サービス305を介してのみアクセスされる。一般のアプリケーションは、サウンドデバイス306へのアクセス要求をサービス305に出力することにより、サービス305を介してサウンドデバイス306にアクセスする。したがって、動画再生モジュール302は、ダウンロードモジュール303によりダウンロードされた動画断片331~333の画像をディスプレイに描画するとともに、動画断片331~333の音声を出力するようサービス305に要求する。さて、上述のとおり、スマートフォン300では優先度に基づくアプリケーション間の調停により、ユーザが感じる性能を向上させることが好ましい。そこで、動画再生アプリケーション301がフォアグラウンドで実行されるときつまり、動画再生モジュール302が画像を表示するウィンドウがアクティブのとき、動画再生アプリケーション301に関するプロセスグループの優先度を上げることが好ましい。ここで、動画再生アプリケーション301のメインタスクは、動画再生モジュール302による再生である。しかし、仮に動画再生モジュール302の優先度のみを高めても、ダウンロードモジュール303の優先度が低ければ、ダウンロードが順調に進行しない。その結果として、動画の再生も順調に進行しない例えば、あるフレーム画像のところで再生が停止してしまうかもしれない。また、仮に動画再生モジュール302とダウンロードモジュール303の優先度のみを高めても、サービス305の優先度が低ければ、画像に合わせてタイムリーに音が出力されず、音が途切れるなどの不具合が生じ得る。したがって、動画再生アプリケーション301に関するプロセスグループは、下記10aのプロセスのみならず、10bと10cのプロセスも含むことが適切である。10aフォアグラウンドで動作する動画再生モジュール302のプロセス。すなわち、動画再生アプリケーション301のメインタスクのプロセス。10bバックグラウンドで動作するダウンロードモジュール303のプロセス。すなわち、動画再生アプリケーション301のパッケージに同封された、メインタスク以外のバックグラウンドタスクのプロセス。10c動画再生モジュール302がサウンドデバイス306という資源を利用するために呼び出すサービス305のプロセス。すなわち、動画再生アプリケーション301が利用する資源を占有して資源へのアクセスを仲介するプロセス。以下に詳しく説明するとおり、第2実施形態によれば、10a~10cを含むプロセスグループが、動画再生アプリケーション301に関するプロセスグループとしてスマートフォン300に認識される。したがってスマートフォン300は、ユーザが感じる性能を向上させるために、認識したプロセスグループに属する10a~10cのプロセスの優先度をまとめて高くするなどの適切なプロセス制御を行うことができる。さて、続いて、上記9bに述べたスマートフォンにおけるアプリケーションパッケージの管理について、より詳しく説明する。図4は、スマートフォンにおけるアプリケーションパッケージの管理を説明する図である。図4には、スマートフォン400と、スマートフォン400にインストールされるアプリケーションパッケージCが例示されている。なお、以下では説明の便宜上、アプリケーション、アプリケーションパッケージ、プログラム、およびプロセスに付した英文字から始まる参照符号は、名前でもあるものとする。例えば、図4のアプリケーションパッケージCの名前はCである。また、説明の簡単化のため、アプリケーションパッケージの名前はアプリケーションの名前と同じであるとする。図4には、スマートフォン400のOSのカーネル401が示されている。また、OSに付属して、いくつかの標準的なサービス402~405、アプリケーション管理マネジャ406、ウィンドウシステム407、およびインストーラ408が、スマートフォン400に予めインストールされている。スマートフォン400のハードウェア構成は、例えば図2と同様であってもよい。図4には、スマートフォン400が有するいくつかの物理デバイスのうち、GPS受信機409が例示されている。サービス402~405のそれぞれは、デーモンであってもよい。サービス402~405は、アプリケーションに対して標準的なサービスを提供する。例えば、図4の例では、サービス404は、アプリケーションに対してGPS受信機409へのアクセスを提供する。また、アプリケーション管理マネジャ406は、アプリケーションの起動、終了、一時停止、再開などを管理する。また、アプリケーション管理マネジャ406は、アプリケーションの状態の変化をウィンドウシステム407に通知する。するとウィンドウシステム407は、状態の変化に応じて適宜のアプリケーションのウィンドウをスマートフォン400のディスプレイに描画する。インストーラ408は、アプリケーションパッケージのインストールを制御する。具体的には、インストーラ408は、インストールする対象のアプリケーションパッケージに含まれるバイナリプログラムなどの各種データをファイルシステム410の適宜のディレクトリに格納する。また、インストーラ408は、インストールする対象のアプリケーションパッケージについてのメタ情報であるパッケージ情報を、パッケージ情報DB411に格納する。例えば、図4のアプリケーションパッケージCは、アプリケーションCのパッケージであり、具体的には以下の11a~11eを含む。11aフォアグラウンドで実行されるメインプロセス用のバイナリプログラムC111bバックグラウンドプロセス用のバイナリプログラムC211cアプリケーションCに関する各種設定値を規定する設定ファイル41211dアプリケーションCがプログラムC1とプログラムC2を含むという、アプリケーションCの構成を示す構成情報41311eアプリケーションCはGPS情報を読み取るという、アプリケーションCが依存する資源を示す依存関係情報414上記11a~11eを含むアプリケーションパッケージCがインストーラ408によりスマートフォン400にインストールされると、プログラムC1、プログラムC2、および設定ファイル412がファイルシステム410内の適宜のディレクトリに格納される。また、パッケージ情報は、具体的には構成情報413と依存関係情報414を含む情報である。よって、インストーラ408は、構成情報413と依存関係情報414をアプリケーションCと関連づけてパッケージ情報DB411に格納する。そして、スマートフォン400にアプリケーションCがインストールされ、アプリケーションCが起動されると、プログラムC1とC2が実行される。すなわち、C1という名前のプログラムC1の実行により、同じくC1という名前を持つプロセスC1が生成され、C2という名前のプログラムC2の実行により、C2という名前のプロセスC2が生成される。また、図4の例では、GPS受信機409が取得したGPS情報を読み取る処理は、プロセスC2から呼び出される処理である。しかし、図4の例では、プロセスC2が直接GPS受信機409にアクセスしてGPS情報を読み取るのではなく、サービス404がGPS受信機409を占有し、GPS受信機409へのアクセスはサービス404を介して行われる。よって、図3の例からも理解されるとおり、図4の例におけるアプリケーションCに関する適切なプロセスグループは、フォアグラウンドで実行されるプロセスC1だけでなく、バックグラウンドで実行されるプロセスC2と、サービス404のプロセスも含む。ここで、プロセスC1とプロセスC2は、パッケージ情報DB411に格納された構成情報413に示されたC1およびC2という名前から特定可能である。しかしながら、サービス404のプロセスは、パッケージ情報DB411に格納された依存関係情報414から直接的に特定することができない。その理由の1つは、依存関係情報414では資源を論理的に識別する情報が使われているからである。他の理由は、アプリケーションのプロセス例えばプロセスC2が他のプロセス例えばサービス404のプロセスを介して資源にアクセスするのか否かに関する情報を、依存関係情報414が含まないからである。そして、これら2つの理由についてより詳しく説明すれば、以下のとおりである。依存関係情報414は、もともと、セキュリティを目的としてアプリケーションパッケージCに含められる情報である。ユーザが知らないうちにアプリケーションが資源にアクセスすることを防ぐため、依存関係情報414は、例えば以下のようにして利用される。まず、不図示の入力装置例えば図2の入力キー206またはタッチスクリーンが、アプリケーションパッケージCのインストールを指示するユーザからの指示の入力を受け付ける。すると、インストーラ408は、依存関係情報414を参照する。その結果、インストーラ408は、アプリケーションCがGPS情報を読み取ることを認識する。インストーラ408は、認識した結果に基づいて、ユーザに対して、あなたがインストールしようとしているアプリケーションCは、GPS情報を読み取りますが、アプリケーションCをインストールしても構いませんかと尋ねるメッセージを表示する。したがって、GPS情報を読み取るアプリケーションをインストールしたくないユーザは、インストールの中止を指示することができる。また、GPS情報を読み取るアプリケーションをインストールしてもよいと考えるユーザは、インストールの続行を指示することができる。その結果、ユーザが知らないうちにアプリケーションCによりGPS情報が読み取られるという、セキュリティ上のリスクが予防される。以上述べたように、依存関係情報414は、セキュリティ目的のアクセス制御情報である。そのため、依存関係情報414は、具体的には、アプリケーションが利用する資源と、アプリケーションがその資源に対して行う操作例えば、読み取り、書き込みなどを表す。なお、図4の例では、依存関係情報414は1つの資源についての情報のみを含むが、複数の資源にアクセスするアプリケーションの依存関係情報では、複数の資源それぞれに関して操作が指定される。よって、スマートフォン400は、パッケージ情報DB411に格納されたパッケージ情報を参照することにより。インストール済みの各アプリケーションについて、どの資源へのアクセスが許可されているのかを認識することができる。しかし、依存関係情報414において資源を識別するために使われる情報は、資源を論理的に識別する情報であり、スマートフォン400において資源を物理的に識別する情報とは異なる。例えば、GPS受信機409は、スマートフォン400において、特定のパスにある特定のファイル名のデバイスファイルとして抽象化されていてもよい。しかし、依存関係情報414においては、スマートフォン400での実装に依存する物理的な識別情報例えば、GPS受信機409のデバイスファイルのフルパスファイル名は使われない。その代わりに、依存関係情報414では、スマートフォン400での実装に依存しない論理的な識別情報例えばGPS情報のような予約文字列などが使われる。さらに、図4の例のように、依存関係情報414に示された資源つまりGPS受信機409へのアクセスが、アプリケーションCのプロセスC2から直接行われるのではなく、サービス404を介して行われることがある。しかし、依存関係情報414は、アプリケーションCがどの資源にどのような種類のアクセス例えば、読み取り、書き込みなどを行う可能性があるかを示すだけである。つまり、依存関係情報414は、アクセスが他のプロセス例えばサービス404のプロセスを介して行われるか否かに関する情報を含まない。なぜなら、そのような情報を含まなくても、上記のセキュリティ目的は達せられるからである。依存関係情報414には以上説明したような特徴があるので、スマートフォン400が依存関係情報414から直接的に、サービス404のプロセスは、アプリケーションCに関するプロセスグループに属すると認識することは困難である。そこで、第2実施形態では、この困難を克服するため、他の様々な情報が使われる。以下、図5~14を参照して、第2実施形態のさらなる詳細について説明する。図5は、第2実施形態によるスマートフォンのブロック構成図である。なお、図5に示す各種データの詳細は図7とともに後述し、図5に示す各種処理部の動作の詳細は図8~14とともに後述する。図5に示すスマートフォン500は、アプリケーションに関連するプロセスグループを判定するプロセスグループ判定部501を有する。プロセスグループ判定部501が判定したプロセスグループは、プロセスグループメンバ表502に記録される。また、スマートフォン500は、プロセスグループメンバ表502を参照して適宜のプロセス制御を行うプロセス制御モジュール503を有する。プロセスグループ判定部501は、資源ファイル対応表504、資源依存関係表505、パッケージ情報DB506、およびプロセス一覧507を参照することにより、プロセス管理の管理単位として適切なプロセスグループを判定することができる。詳しくは後述するが、資源ファイル対応表504には予めデータが設定される。また、パッケージ情報DB506は、図4のパッケージ情報DB411と同様であり、アプリケーションパッケージのインストールとアンインストールのたびに書き換えられる。資源依存関係表505とプロセス一覧507は、スマートフォン500の動作に応じて変化する。具体的には、スマートフォン500はさらに依存関係管理部508とプローブ509を有する。そして、プローブ509はプロセスによる資源の獲得と解放を監視し、監視結果を依存関係管理部508に通知する。すると、依存関係管理部508は、プローブ509からの通知に応じて、資源依存関係表505を動的に書き換える。また、プロセス一覧507は、スマートフォン500において動作中のプロセスの一覧であるから、当然、取得されるタイミングに応じて内容が異なる。スマートフォン500は、さらに、ユーザからの入力を受け付ける入力部510を有する。入力部510は、例えば図2の入力キー206、タッチスクリーン、またはその組み合わせである。また、スマートフォン500は、図4のアプリケーション管理マネジャ406と同様にアプリケーションの起動、終了、一時停止、再開などを管理するアプリケーション管理マネジャ511も有する。より詳しくは、アプリケーション管理マネジャ511は、図5に示すように、アプリケーションの切り替えが起きたときに切り替えイベントの発生を他のモジュールに通知する切り替えイベント通知部512を含む。また、図5には、スマートフォン500のOSのカーネル513と、カーネル513内のデバイスドライバ514も図示されている。第2実施形態では、上記プローブ509もカーネル513内に実装される。さらに、スマートフォン500は、いくつかの物理デバイス515を有する。物理デバイス515は資源の具体例である。なお、図5では便宜上、物理デバイス515のブロックは1つだけ示してある。物理デバイス515へのインタフェイスを実現するために、スマートフォン500のOSでは、物理デバイス515を資源ファイル516つまりスペシャルファイルまたはデバイスファイルと呼ばれるファイルに抽象化する技法が採用されている。図5では便宜上、資源ファイル516のブロックが1つだけ示されているが、複数の物理デバイス515にそれぞれ対応する複数の資源ファイル516があってもよい。また、図5にはスマートフォン500が実行するプロセス517も図示されている。図5では便宜上、プロセス517のブロックは1つだけ示してあるが、スマートフォン500は複数のプロセス517を実行する。また、プロセス517は、ユーザアプリケーションのプロセスでもよいし、OSに付属するサービス等のプロセスでもよい。なお、第2実施形態では、プロセス517から物理デバイス515へのアクセスは、具体的には、資源ファイル516に対するシステムコールにより実現される。よって、プローブ509は、資源ファイル516に対するシステムコールを監視することで、資源つまり物理デバイス515の獲得と解放を監視する。なお、スマートフォン500は、プローブ509が監視する対象の資源ファイル516のリストを予め監視対象資源ファイルリスト518として記憶している。続いて、図6を参照して、アプリケーションパッケージと資源とプロセスの具体例を説明する。図6のスマートフォン600は、図5のスマートフォン500と同様の構成要素を含むが、図6では、図5に示す構成要素の一部が省略され、一部がより具体化されている。すなわち、スマートフォン600は、図5の物理デバイス515の具体例として、GPS受信機601と加速度センサ602とサウンドデバイス603とディスプレイ604を有する。また、以下では説明の便宜上、サウンドデバイス603は、特定プロセスによってアクセスが占有される特定資源であるものと仮定し、他の3つの物理デバイスは、特定資源ではないものと仮定する。また、スマートフォン600は、ファイルシステム605とパッケージ情報DB606を含む。図5ではファイルシステムが省略されているが、図6のファイルシステム605は、図4のファイルシステム410と同様である。また、パッケージ情報DB606は、図4のパッケージ情報DB411および図5のパッケージ情報DB506に相当する。また、スマートフォン600は、OSのカーネル607と、デバイスドライバ608を含む。カーネル607は図4のカーネル401および図5のカーネル513に相当し、デバイスドライバ608は図5のデバイスドライバ514に相当する。そして、スマートフォン600は、図5の資源ファイル516の具体例として、資源ファイル609~612を含む。図6では説明の便宜上、資源ファイル609~612のブロックの中にそれぞれのフルパスファイル名が書かれている。以下では説明の簡単化のため、フルパスファイル名を単にファイル名ともいう。具体的には、GPS受信機601に対応する資源ファイル609のファイル名は/dev/tty1である。また、加速度センサ602に対応する資源ファイル610のファイル名は/dev/tty2である。そして、サウンドデバイス603に対応する資源ファイル611のファイル名は/dev/sndである。また、ディスプレイ604に対応する資源ファイル612のファイル名は/dev/fbである。また、図6には、図5のプロセス517の具体例として、OSにより提供される標準的ないくつかのプログラムのプロセスと、ユーザからの指示に基づいてインストールされたアプリケーションのプロセスが例示されている。具体的には、図6には、ロケーションマネジャ613、サウンドデーモン614、ウィンドウシステム615、アプリケーション管理マネジャ616、およびインストーラ617それぞれのプロセスが例示されている。さらに、図6には、インストーラ617によりスマートフォン600にインストールされたアプリケーションDとEの実行により生成されるプロセスD1、D2、E1およびE2も例示されている。なお、ロケーションマネジャ613は、GPS受信機601に対応する資源ファイル609を参照することで、スマートフォン600の位置に関する情報を得る。そして、ロケーションマネジャ613は、任意のアプリケーションに対して位置情報を提供する。図6の例では、ロケーションマネジャ613のプロセスのPIDは5である。なお、資源ファイル609には、ロケーションマネジャ613以外のアプリケーションのプロセスもアクセス可能である。また、サウンドデーモン614は、サウンドデバイス603に対応する資源ファイル611へのアクセスを独占する。他のプログラムのプロセスは、サウンドデーモン614のプロセスに対してサウンドデバイス603へのアクセスを要求し、サウンドデーモン614が要求に応じて資源ファイル611を操作する。すなわち、図6の例では、サウンドデバイス603は特定資源であり、サウンドデーモン614のプロセスは特定プロセスである。また、図6の例では、サウンドデバイス603のプロセスのPIDは10である。ウィンドウシステム615は図4のウィンドウシステム407と同様である。ウィンドウシステム615は、ディスプレイ604に対応する資源ファイル612を操作することで、ウィンドウの描画を制御する。図6の例では、ウィンドウシステム615のプロセスのPIDは20である。アプリケーション管理マネジャ616は、図4のアプリケーション管理マネジャ406および図5のアプリケーション管理マネジャ511に対応し、アプリケーションの起動、終了、一時停止、再開などを管理する。図6では省略されているが、図5と同様に、アプリケーション管理マネジャ616は切り替えイベント通知部512を含む。なお、図6の例では、アプリケーション管理マネジャ616のプロセスのPIDは30である。インストーラ617は、図4のインストーラ408に相当する。スマートフォン600へのアプリケーションパッケージのインストールは、インストーラ617を介して行われる。そして、アプリケーションパッケージに含まれるバイナリプログラムと設定ファイルは、ファイルシステム605に格納され、アプリケーションパッケージに含まれるパッケージ情報はパッケージ情報DB606に格納される。図6の例では、インストーラ617のプロセスのPIDは40である。また、図6には2つのアプリケーションパッケージDとEが例示されている。そして、図6は、インストールされたアプリケーションDとEが実行されている状態を示す。具体的には、アプリケーションパッケージDは、プログラムD1とD2と依存関係情報618と構成情報619を含む。依存関係情報618は、アプリケーションDが加速度センサ602を利用することを示す。また、構成情報619は、アプリケーションパッケージDがプログラムD1とD2を含むことを示す。また、アプリケーションパッケージEは、プログラムE1とE2と依存関係情報620と構成情報621を含む。依存関係情報620は、アプリケーションEがサウンドデバイス603を利用することを示す。また、構成情報621はアプリケーションパッケージEがプログラムE1とE2を含むことを示す。そして、スマートフォン600にインストールされたアプリケーションDが起動されると、具体的にはプログラムD1の実行によりプロセスD1が生成され、プログラムD2の実行によりプロセスD2が生成される。図6の例では、プロセスD1のPIDは1001であり、プロセスD2のPIDは1011である。また、アプリケーションDがフォアグラウンドアプリケーションであるとき、プロセスD1は、フォアグラウンドで動作する。つまり、アプリケーションDのウィンドウ表示に関する命令をウィンドウシステム615のプロセスに送信するプロセスは、プロセスD1である。他方、プロセスD2はバックグラウンドプロセスである。なお、依存関係情報618が示すように、アプリケーションDは加速度センサ602を利用する。図6の例では、具体的には、プロセスD2が、加速度センサ602に対応する資源ファイル610に対して、オープン操作、リード操作、クローズ操作などの操作をすることで、アプリケーションDからの加速度センサ602へのアクセスが実現される。また、スマートフォン600にインストールされたアプリケーションEが起動されると、具体的にはプログラムE1の実行によりプロセスE1が生成され、プログラムE2の実行によりプロセスE2が生成される。図6の例では、プロセスE1のPIDは1002であり、プロセスE2のPIDは1012である。また、アプリケーションEがフォアグラウンドアプリケーションであるとき、プロセスE1は、フォアグラウンドで動作する。つまり、アプリケーションEのウィンドウ表示に関する命令をウィンドウシステム615のプロセスに送信するプロセスは、プロセスE1である。他方、プロセスE2はバックグラウンドプロセスである。なお、依存関係情報620が示すように、アプリケーションEはサウンドデバイス603を利用する。図6の例では、具体的には、プロセスE2がサウンドデバイス603を利用するための処理を行う。ただし、図6の例では、特定資源であるサウンドデバイス603へのアクセスは、特定プロセスであるサウンドデーモン614のプロセスにより占有される。したがって、プロセスE2は、具体的には、サウンドデバイス603に音声を出力させるための指示を、サウンドデーモン614のプロセスに送信する。すると、サウンドデーモン614のプロセスが、プロセスEからの指示にしたがって、サウンドデバイス603にアクセスするより具体的には、例えば、ライトシステムコールを呼び出す。その結果、サウンドデバイス603が音声を出力する。図7は、各種データの具体例を説明する図である。なお、図7の各種データの例は、図6の例に対応する。図7には、図5に示したプロセスグループメンバ表502、資源ファイル対応表504、資源依存関係表505、パッケージ情報DB506、プロセス一覧507、および監視対象資源ファイルリスト518の具体例が例示されている。図7にはさらに、後述の変形例で使われる資源プロセス名対応表520、アプリケーション利用時刻表529、および強制終了除外プロセスリスト530の具体例も例示されている。変形例で使われるデータについては、後述することにし、ここでは説明を省略する。さて、図7に例示されるプロセスグループメンバ表502aにおける各エントリは、アプリケーション名と、アプリケーション名により識別されるアプリケーションに関連するプロセスグループの各メンバのPIDを要素とするPIDリストとを対応づける。1つ目のエントリによれば、アプリケーションDのプロセスグループは、PIDが1001のプロセスつまり図6のプロセスD1と、PIDが1011のプロセスつまり図6のプロセスD2を含む。また、2つ目のエントリによれば、アプリケーションEのプロセスグループは、PIDが1002のプロセスつまり図6のプロセスE1と、PIDが1012のプロセスつまり図6のプロセスE2を含む。アプリケーションEのプロセスグループはさらに、PIDが10のプロセスつまり図6のサウンドデーモン614のプロセスも含む。なぜなら、アプリケーションEが利用するサウンドデバイス603は特定資源であり、サウンドデバイス603に対応する特定プロセスはサウンドデーモン614のプロセスだからである。また、図7に例示される資源ファイル対応表504aにおける各エントリは、スマートフォン500において利用可能な個々の資源に対応する。第2実施形態における資源は、具体的には物理デバイス515であるが、もちろん、スマートフォン500が備える不図示のデータベースまたはスマートフォン500が記憶する所定のファイルが資源として使われてもよい。資源ファイル対応表504aの各エントリは、フラグと外部資源名と資源ファイル名を含む。フラグは、当該エントリに対応する資源が特定資源であるか否かを示す。図7の例では、フラグの値が1のエントリは特定資源に対応し、フラグの値が0のエントリは特定資源以外の資源に対応する。また、外部資源名は、当該エントリに対応する資源を論理的に識別する識別情報であり、具体的には、アプリケーションパッケージの依存関係情報において資源を論理的に識別するのに使われる名前である。資源ファイル名は、当該エントリに対応する資源へのインタフェイスたる資源ファイル516の、フルパスファイル名である。例えば、1番目のエントリによれば、GPSという名前で論理的に識別される資源つまり図6のGPS受信機601に対応する資源ファイル609のフルパスファイル名は/dev/tty1である。そして、当該資源へのアクセスは特定プロセスからのアクセスに限定されるわけではないのでフラグの値は0である。また、2番目のエントリによれば、加速度センサという名前で論理的に識別される資源つまり図6の加速度センサ602に対応する資源ファイル610のフルパスファイル名は/dev/tty2である。そして、当該資源へのアクセスは特定プロセスからのアクセスに限定されるわけではないのでフラグの値は0である。また、3番目のエントリによれば、サウンドという名前で論理的に識別される資源つまり図6のサウンドデバイス603に対応する資源ファイル611のフルパスファイル名は/dev/sndである。そして、当該資源へのアクセスは特定プロセスつまり図6のサウンドデーモン614のプロセスからのアクセスに限定されるのでフラグの値は1である。さて、図7に例示される資源依存関係表505aの各エントリは、資源ファイル名と、当該資源ファイル名に対応する資源を確保中のプロセスのPIDとを対応づける。例えば、1番目のエントリによれば、フルパスファイル名が/dev/tty1の資源ファイルによりインタフェイスが提供される資源は、現在、PIDが5のプロセスによりオープンされており、PIDが5のプロセスにより確保されている。つまり、1番目のエントリは、GPS受信機601が現在ロケーションマネジャ613のプロセスにより確保されているという、図6の状況を表す。また、2番目のエントリによれば、フルパスファイル名が/dev/tty2の資源ファイルによりインタフェイスが提供される資源は、現在、PIDが1011のプロセスによりオープンされており、PIDが1011のプロセスにより確保されている。つまり、2番目のエントリは、加速度センサ602が現在プロセスD2により確保されているという、図6の状況を表す。そして、3番目のエントリによれば、フルパスファイル名が/dev/sndの資源ファイルによりインタフェイスが提供される資源は、現在、PIDが10プロセスによりオープンされており、PIDが10のプロセスにより確保されている。つまり、3番目のエントリは、サウンドデバイス603が現在サウンドデーモン614のプロセスにより確保されているという、図6の状況を表す。また、図7に例示されるパッケージ情報DB506aの各エントリは、アプリケーションに対応する。各エントリは、アプリケーション名と、プログラム名リストと、利用外部資源名リストを含む。アプリケーション名は、当該エントリに対応するアプリケーションの名前である。また、プログラム名リストは、当該アプリケーション名で識別されるアプリケーションパッケージに含まれるバイナリプログラムの名前のリストである。そして、利用外部資源名リストは、当該アプリケーション名で識別されるアプリケーションパッケージからアクセスされる可能性のある資源を論理的に識別する識別情報のリストである。換言すれば、利用外部資源名リストは、アプリケーションパッケージのインストール時に、ユーザによりアクセスが容認された資源を論理的に識別する識別情報のリストである。例えば、1番目のエントリによれば、アプリケーションDはプログラムD1とプログラムD2を含み、アプリケーションDからは、加速度センサという名前で論理的に識別される資源がアクセスされる可能性がある。つまり、1番目のエントリは、図6のアプリケーションパッケージDがインストールされるときに、依存関係情報618と構成情報619に基づいて生成される。また、2番目のエントリによれば、アプリケーションEはプログラムE1とプログラムE2を含み、アプリケーションEからは、サウンドという名前で論理的に識別される資源がアクセスされる可能性がある。つまり、2番目のエントリは、図6のアプリケーションパッケージEがインストールされるときに、依存関係情報620と構成情報621に基づいて生成される。また、図7に例示されるプロセス一覧507aの各エントリは、動作中のプロセスに対応し、当該プロセスのPIDとプロセス名を含む。図7のプロセス一覧507aは、図6に例示した9つのプロセスと、スマートフォンの起動中は常に存在するinitプロセスにそれぞれ対応するエントリを含む。なお、図7に示すように、initプロセスのPIDは1である。そして、図7に例示される監視対象資源ファイルリスト518aは、プローブ509による監視の対象を定義するためのリストであり、具体的には、監視対象の資源ファイル516のフルパスファイル名のリストである。図6の例によれば、スマートフォン600はGPS受信機601、加速度センサ602、サウンドデバイス603、およびディスプレイ604という資源を有する。ただし、以下ではディスプレイ604は監視の対象ではないものとする。よって、監視対象資源ファイルリスト518aは、GPS受信機601に対応する資源ファイル609と、加速度センサ602に対応する資源ファイル610と、サウンドデバイス603に対応する資源ファイル611の、フルパスファイル名のリストである。続いて、以上のとおり図6~7に示した具体例も参照しながら、図5のスマートフォン500の各部の動作について、図8~14のフローチャートを参照して説明する。図8は、第2実施形態において切り替えイベント通知部512を含むアプリケーション管理マネジャ511が行う処理のフローチャートである。図8の処理は、スマートフォン500が起動されると開始される。ステップS101でアプリケーション管理マネジャ511は、アプリケーションの管理に関わるイベントの発生を待つ。そして、イベントが発生すると、処理はステップS102に移行する。なお、イベントは、例えばユーザからの入力を入力部510が受け取ったときなどに発生する。さて、ステップS102でアプリケーション管理マネジャ511は、ステップS101で検出したイベントに応じた、通常のアプリケーション管理処理を実行する。つまり、イベントの種類に応じて、アプリケーション管理マネジャ511は、例えば以下の12a~12gの処理のうち1つ以上を適宜行う。12a新たなアプリケーションを起動する。12b今までフォアグラウンドで実行していたアプリケーションを終了する。12c今までフォアグラウンドで実行していたアプリケーションをバックグラウンドに遷移させる。12d今までフォアグラウンドで実行していたアプリケーションを一時停止させる。12e今までバックグラウンドで実行していたアプリケーションをフォアグラウンドに遷移させる。12f今まで一時停止していたアプリケーションを再開する。12gウィンドウシステムに対してウィンドウの表示方向の切り替えを命令する。そして、ステップS102の実行後、処理はステップS103に移行する。すると、ステップS103で切り替えイベント通知部512は、発生したイベントの種類を判定する。そして、発生したイベントが、アプリケーションを切り替えるイベントすなわち、画面の切り替えをともなうイベントである場合、処理はステップS104に移行する。例えば、何もアプリケーションが起動されていないときに、新たなアプリケーションを起動するイベントが発生すると、処理はステップS104に移行する。同様に、既に起動されているアプリケーションがあるときに、他のアプリケーションを起動することによってフォアグラウンドのアプリケーションを切り替えるイベントが発生すると、やはり処理はステップS104に移行する。また、現在フォアグラウンドで実行中のアプリケーションに対して明示的な終了指示が入力された場合も、一種のアプリケーションの切り替えが生じるので、処理はステップS104へ移行する。逆に、発生したイベントが、その他の種類のイベントである場合、処理はステップS101に戻る。例えば、ユーザがスマートフォン500の向きを縦から横に変えたとき、ウィンドウの表示方向を切り替えるイベントが発生する。しかし、この場合は、ウィンドウに表示されるコンテンツ自体は変わらないし、当然アプリケーションの切り替えも発生しない。したがって、処理はステップS104からステップS101へと戻る。ステップS104で切り替えイベント通知部512は、アプリケーションの切り替えの発生をプロセスグループ判定部501とプロセス制御モジュール503に通知する。そして、処理はステップS101に戻る。なお、ステップS104での通知を受けたプロセスグループ判定部501の動作の詳細は図11とともに後述する。また、ステップS104での通知を受けたプロセス制御モジュール503の動作の詳細は、図12~14とともに後述する。続いて、図9のフローチャートを参照して、第2実施形態においてプローブ509が行う処理について説明する。図9の処理は、スマートフォン500が起動されると開始される。ステップS201でプローブ509は、監視対象資源ファイルリスト518を読み取り、監視対象の資源に対応する資源ファイル516を認識する。そして、プローブ509は、監視対象資源ファイルリスト518で指定される各資源つまり、監視対象資源ファイルリスト518中にファイル名のある資源ファイル516に対応する各物理デバイス515に対するシステムコールの監視を開始する。図6と図7の例では、監視対象の資源は資源ファイル609~611に対応するGPS受信機601、加速度センサ602およびサウンドデバイス603である。そして、次のステップS202でプローブ509は、監視対象の資源に対応する資源ファイル516に対するシステムコールの呼び出しを待つ。そして、システムコールの呼び出しがあると、処理はステップS203に移行する。ステップS203でプローブ509は、システムコールの種類を判定する。システムコールの種類が、資源獲得のためのオープンまたは資源解放のためのクローズである場合、処理はステップS204に移行する。他の種類例えばリードやライトなどのシステムコールの場合、処理はステップS205に移行する。そして、ステップS204でプローブ509は、依存関係管理部508に、操作内容、操作対象、および呼び出し元PIDを通知する。操作内容は、具体的にはシステムコールの種類であり、操作対象は資源ファイル516のファイル名により表される。例えば、PIDが1011のプロセスD2から、資源ファイル610に対するオープンシステムコールが呼び出されたとする。図7の監視対象資源ファイルリスト518aによれば、図6の資源ファイル610は監視対象である。よって、この場合、プローブ509はステップ204において、操作内容がオープン操作であること、操作対象が/dev/tty2であること、および、呼び出し元PIDが1011であることを、依存関係管理部508に通知する。ステップS204での通知の後、処理はステップS205に移行する。すると、ステップS205でプローブ509は、ステップS202で検出したシステムコールを呼び出す。その結果、システムコールが実行される。そして、処理はステップS202に戻る。例えば、ステップS202で、プロセスD2からの資源ファイル610に対するオープンシステムコールの呼び出しが検出された場合、ステップS205では、資源ファイル610に対するオープンシステムコールが実行される。つまり、カーネル513により資源ファイル610がオープンされる。なお、カーネル513は、資源ファイル610に対するオープン操作が成功したことを示す返り値をプローブ509に返してもよい。プローブ509は、ステップS205においてさらに、カーネル513からの返り値をシステムコールの本来の呼び出し元のプロセスに返してもよい。あるいは、カーネル513は、システムコールの本来の呼び出し元のプロセスに、直接、返り値を返してもよい。以上の図9の処理によれば、監視対象資源ファイルリスト518にファイル名が含まれるいずれかの資源ファイル516に対するオープンまたはクローズシステムコールが呼び出されるたびに、プローブ509から依存関係管理部508への通知がなされる。なお、プローブ509による監視対象ではない資源例えば、図6と図7の例ではディスプレイ604に対するシステムコールに応じて、カーネル513が適宜の処理を実行することは無論である。図10は、第2実施形態において依存関係管理部508が行う処理のフローチャートである。図10の処理も、スマートフォン500が起動されると開始される。ステップS301で依存関係管理部508は、プローブ509からの通知を待つ。そして、依存関係管理部508がプローブ509から通知を受けると、処理はステップS302に移行する。ステップS302で依存関係管理部508は、プローブ509から通知されたイベントの種類すなわち、プローブ509が検出したシステムコールの種類を判定する。なお、図9とともに説明したとおり、プローブ509が依存関係管理部508に通知するのは、監視対象の資源ファイル516に対するオープンまたはクローズシステムコールの発生のみである。プローブ509から通知されたイベントの種類が資源の獲得である場合すなわち、通知された操作内容がオープン操作である場合、処理はステップS303に移行する。逆に、プローブ509から通知されたイベントの種類が資源の解放である場合すなわち、通知された操作内容がクローズ操作である場合、処理はステップS304に移行する。ステップS303で依存関係管理部508は、資源依存関係表505において、オープンされた資源ファイル516に対応づけてPIDを書き込む。書き込みの後、処理はステップS301に戻る。例えば、プローブ509から通知された呼び出し元PIDが5であり、プローブ509から通知された操作対象が/dev/tty1であるとする。この場合、ステップS303で依存関係管理部508は、資源依存関係表505において資源ファイル名が/dev/tty1のエントリを検索し、見つかったエントリのPIDフィールドに、プローブ509から通知された5というPIDを書き込む。また、ステップS304で依存関係管理部508は、資源依存関係表505において、クローズされた資源ファイル516に対応するPIDを消去する。消去の後、処理はステップS301に戻る。例えば、プローブ509から通知された呼び出し元PIDが1011であり、プローブ509から通知された操作対象が/dev/tty2であるとする。この場合、ステップS304で依存関係管理部508は、資源依存関係表505において資源ファイル名が/dev/tty2のエントリを検索し、見つかったエントリのPIDフィールドをクリアする。以上説明した図9~10の処理により、監視対象資源ファイルリスト518に指定されたいずれかの資源ファイル516がオープンまたはクローズされるたびに、資源依存関係表505が動的に書き換えられる。なお、上記では説明を省略したが、資源依存関係表505は、監視対象資源ファイルリスト518に合わせて初期化される。例えば、スマートフォン500が起動されたときに、依存関係管理部508が監視対象資源ファイルリスト518を参照して資源依存関係表505を初期化してもよい。初期状態の資源依存関係表505は、監視対象資源ファイルリスト518に含まれる各資源ファイル名に対応するエントリを有し、各エントリのPIDフィールドはクリアされた状態である。例えば、図7の監視対象資源ファイルリスト518aには/dev/tty1と/dev/tty2と/dev/sndという3つの資源ファイル名が含まれるので、資源依存関係表505はこれら3つの資源ファイル名に対応する3つのエントリを持つように初期化され、各エントリのPIDフィールドはクリアされる。さて、図11は、第2実施形態においてプロセスグループ判定部501が行う処理のフローチャートである。図11の処理も、スマートフォン500が起動すると開始される。ステップS401でプロセスグループ判定部501は、アプリケーションの状態変化イベントが切り替えイベント通知部512から通知されるまで待つ。すなわち、図8のステップS104で切り替えイベント通知部512が通知を出すまで、プロセスグループ判定部501はステップS401で待機する。そして、アプリケーションを新たに起動するイベントが通知された場合、処理はステップS402に移行する。逆に、アプリケーションを停止するイベントが通知された場合、処理はステップS413に移行する。また、起動でも停止でもないイベントが通知された場合、プロセスグループ判定部501はステップS401で待機し続ける。例えば、既にバックグラウンドで実行中のアプリケーションがフォアグラウンドに切り替えられた場合、当該アプリケーションのプロセスグループは変化しないので、プロセスグループ判定部501は何もする必要がない。したがって、プロセスグループ判定部501はステップS401で待機し続ける。ステップS402でプロセスグループ判定部501は、起動したアプリケーションのパッケージ情報から、実行プログラム名と利用資源名を取得する。取得される実行プログラム名の数は1以上であり、取得される利用資源名の数は0以上である。例えば、アプリケーションEが起動したことを切り替えイベント通知部512がプロセスグループ判定部501に通知したとする。この場合、プロセスグループ判定部501はステップS402において、切り替えイベント通知部512から通知されたEというアプリケーション名を検索キーにして、パッケージ情報DB506aを検索する。そして、プロセスグループ判定部501は、見つかったエントリのプログラム名リストから、アプリケーションEの実行プログラム名としてE1とE2を取得する。また、プロセスグループ判定部501は、見つかったエントリの利用外部資源名リストから、アプリケーションEの利用資源名としてサウンドという論理的な名前を取得する。続いて、ステップS403でプロセスグループ判定部501は、例えばpsコマンドなどを用いて、プロセス一覧507を取得する。図7に例示したとおり、プロセス一覧507は、各プロセスのプロセス名とPIDを少なくとも含む。そして、次のステップS404でプロセスグループ判定部501は、ステップS402で取得した各実行プログラム名について、以下の処理を行う。すなわち、プロセスグループ判定部501は、取得した実行プログラム名を検索キーにして、ステップS403で取得したプロセス一覧507を検索し、プログラムの実行により生成されたプロセスのPIDを検索結果から取得する。例えば、ステップS402でE1とE2という実行プログラム名が取得され、ステップS403で図7のプロセス一覧507aが取得されたとする。この場合、ステップS404でプロセスグループ判定部501は、E1という名前を検索キーにして1002というPIDを取得するとともに、E2という名前を検索キーにして1012というPIDを取得する。さらに、次のステップS405でプロセスグループ判定部501は、ステップS404で取得した全PIDを、プロセスグループメンバ表502に書き込む。より詳しくは、プロセスグループ判定部501は、プロセスグループメンバ表502に新たなエントリを追加する。また、プロセスグループ判定部501は、追加したエントリのアプリケーション名フィールドに、起動したアプリケーションの名前を書き込む。なお、プロセスグループ判定部501は、切り替えイベント通知部512からの通知により、起動したアプリケーションの名前を認識することが可能である。そして、プロセスグループ判定部501は追加したエントリのPIDリストフィールドに、ステップS404で取得した全PIDを書き込む。例えば、ステップS404で上記の例のように1002と1012というPIDを得た場合、ステップS405でプロセスグループ判定部501は、起動したアプリケーションEに対応するエントリを作成する。そして、プロセスグループ判定部501は、Eというアプリケーション名に対応づけて、1002および1012というPIDをプロセスグループメンバ表502に記録する。続いて、ステップS406でプロセスグループ判定部501は、ステップS402で取得した利用資源名のうち、ステップS407以降の処理の対象としてまだ注目していない利用資源名がまだあるか否かを判断する。ステップS402で取得した利用資源名の数がそもそも0であるか、または、取得したすべての利用資源名に既に注目し終わっている場合、処理はステップS412に移行する。逆に、ステップS402で取得した利用資源名のうち、未注目のものがまだある場合、処理はステップS407に移行する。そして、ステップS407でプロセスグループ判定部501は、次の利用資源名に注目し、資源ファイル対応表504を用いて、論理的な利用資源名から物理的な資源ファイル名を取得する。つまり、プロセスグループ判定部501は、注目した利用資源名を検索キーにして資源ファイル対応表504を検索し、見つかったエントリから資源ファイル名を読み取る。例えば、プロセスグループ判定部501がステップS407でサウンドという利用資源名に注目しており、資源ファイル対応表504が図7の資源ファイル対応表504aのとおりであるとする。この場合、ステップS407でプロセスグループ判定部501は、サウンドという名前から、/dev/sndという資源ファイル名を取得する。そして、次のステップS408でプロセスグループ判定部501は、起動したアプリケーションの利用する資源を確保しているプロセスのPIDを、資源依存関係表505から読み取る。すなわち、プロセスグループ判定部501は、ステップS407で取得した資源ファイル名を検索キーにして資源依存関係表505を検索し、見つかったエントリからPIDを読む。例えば、ステップS407で/dev/sndというファイル名が取得され、資源依存関係表505が図7の資源依存関係表505aのとおりであるとする。この場合、ステップS408でプロセスグループ判定部501は、/dev/sndというファイル名から、10というPIDを取得する。なお、図10のステップS304に関して説明したとおり、資源が解放されると資源依存関係表505のPIDはクリアされる。よって、現在プロセスグループ判定部501が注目している資源を現在確保しているプロセスがない場合、ステップS408では、有効なPIDの値は取得されない。なお、PIDをクリアする操作は、実施形態に応じて、NULL値を上書きする操作であってもよいし、PIDとしては使われない-1などの特定の数値を上書きする操作であってもよい。よって、プロセスグループ判定部501は、ステップS408で取得した値がNULLや-1などであれば、PIDがクリアされていると判断することができる。そして、次のステップS409でプロセスグループ判定部501は、現在注目している資源ファイル名に対応して資源依存関係表505に有効なPIDが存在するか否かを判断する。つまり、プロセスグループ判定部501は、ステップS408で有効なPIDを取得することができたか否かを判断する。そして、有効なPIDがステップS408で取得された場合は、取得されたPIDをプロセスグループに追加するか否かの判断のため、処理はステップS410に移行する。逆に、PIDがクリアされていれば、現在プロセスグループ判定部501が注目している資源に関連してプロセスグループに追加するPIDが存在しないので、処理はステップS406に戻る。また、ステップS410でプロセスグループ判定部501は、ステップS408で読み取ったPIDのプロセスの種類が、資源へのアクセスを提供するために資源を占有するシステムサービスなのか、それともアプリケーションなのかを判断する。つまり、プロセスグループ判定部501は、ステップS408で読み取ったPIDのプロセスが、特定プロセスなのか否かを判断する。例えば、資源ファイル対応表504が図7の資源ファイル対応表504aのようにフラグフィールドを有する場合、プロセスグループ判定部501は次のようにしてステップS410の判断を行う。プロセスグループ判定部501は、ステップS407で検索して見つけたエントリのフラグを参照する。そして、フラグの値が1であれば、プロセスグループ判定部501は、プロセスの種類はシステムサービスであると判断する。逆に、フラグの値が0であれば、プロセスグループ判定部501は、プロセスの種類はアプリケーションであると判断する。実施形態によっては、プロセスグループ判定部501は、他の種類の情報を用いてステップS410の判断を行ってもよい。資源へのアクセスを提供するために資源を占有するシステムサービスの名前のリストをスマートフォン500が保持してもよく、プロセスグループ判定部501はリストを参照することでステップS410の判断を行ってもよい。なお、プロセスグループ判定部501は、ステップS403で取得したプロセス一覧507から、ステップS408で読み取ったPIDに対応するプロセス名を取得することができる。よって、プロセスグループ判定部501は、システムサービスの名前のリストに、取得したプロセス名が含まれるか否かを判断することにより、ステップS410の判断を行ってもよい。そして、ステップS408で読み取ったPIDのプロセスの種類が、資源へのアクセスを提供するために資源を占有するシステムサービスであれば、処理はステップS411に移行する。つまり、プロセスグループ判定部501が現在注目している資源が、特定プロセスによって占有される特定資源であれば、処理はステップS411に移行する。逆に、ステップS408で読み取ったPIDのプロセスの種類が、アプリケーションであれば、処理はステップS406に戻る。つまり、プロセスグループ判定部501が現在注目している資源が、特定資源以外の通常の資源であるすなわち、任意のアプリケーションプロセスから直接アクセスされ得る資源である場合、処理はステップS406に戻る。なぜなら、プロセスグループ判定部501が現在注目している資源が、たまたま別のアプリケーションのプロセスによって現在オープンされているとしても、起動したアプリケーションと当該別のアプリケーションは独立しているからである。独立した2つのアプリケーションのプロセスを同じプロセスグループに含めることは、アプリケーション単位での適切なプロセス管理のためのプロセスグループの認識という目的にそぐわない。そのため、ステップS408で読み取ったPIDのプロセスの種類が、アプリケーションであれば、処理はステップS406に戻る。そして、ステップS411でプロセスグループ判定部501は、ステップS408で読み取ったPIDを、プロセスグループメンバ表502の、ステップS405で追加したエントリのPIDリストに追加する。追加の後、処理はステップS406に戻る。例えば、上記の例のように、プロセスグループ判定部501が、ステップS405でアプリケーション名Eに対応づけて1002および1012というPIDをプロセスグループメンバ表502に記録し、ステップS408で10というPIDを取得したとする。すると、プロセスグループ判定部501はステップS411でさらに10というPIDを追加する。その結果、図7のプロセスグループメンバ表502aの2番目のエントリのとおり、10、1002、および1012というPIDのプロセスを含むプロセスグループが、アプリケーションEのプロセスグループとしてプロセスグループメンバ表502に登録される。さて、ステップS412が実行されるのは、起動したアプリケーションに関するプロセスグループに属するPIDが、すべてプロセスグループメンバ表502に登録された後である。そこで、ステップS412でプロセスグループ判定部501は、プロセスグループメンバ表502の更新をプロセス制御モジュール503に通知する。プロセス制御モジュール503は、ステップS412でのプロセスグループ判定部501からの通知を待つことにより、確実に、更新後のプロセスグループメンバ表502を参照することができる。ステップS412の通知の後、処理はステップS401に戻る。さて、ステップS413では、プロセスグループ判定部501が、プロセスグループメンバ表502から、停止したアプリケーションのプロセスグループを削除する。つまり、プロセスグループ判定部501は、停止したアプリケーションに対応するエントリを、プロセスグループメンバ表502から削除する。そして、処理はステップS401に戻る。例えば、アプリケーションDが停止したことを、切り替えイベント通知部512がプロセスグループ判定部501に通知したとする。この場合、プロセスグループ判定部501はステップS413において、Dというアプリケーション名を検索キーにしてプロセスグループメンバ表502を検索し、見つかったエントリをプロセスグループメンバ表502から削除する。なお、プロセスグループ判定部501が資源ファイル対応表504aのフラグを用いてステップS410の判断を行う場合、上記の図11の処理は次のように変形されてもよい。すなわち、プロセスグループ判定部501はステップS407で資源ファイル名とともにフラグの値を取得し、フラグの値が0であれば、ステップS408~S411を省略して、ステップS406に戻ってもよい。そして、ステップS407で取得したフラグの値が1の場合、プロセスグループ判定部501は、ステップS408とS411の処理を行ってもよい。また、図11では省略されているが、ステップS402は次のようなエラー処理を含んでもよい。アプリケーション管理マネジャ511は、ユーザアプリケーション以外のプログラムの起動も検出するよう構成されていてもよい。その場合、何らかの理由でサウンドデーモン614などのサービスが再起動された場合などにも、切り替えイベント通知部512からプロセスグループ判定部501への通知が行われることがある。そこで、図11ではエラー処理が省略されているが、ステップS402におけるパッケージ情報DB506の検索でエントリが見つからなければ、プロセスグループ判定部501は、図11の処理を直ちに終了してもよい。すると、たとえサービスの起動を契機に処理がステップS401からステップS402に移行した場合であっても、起動したサービスに関するエントリが誤ってプロセスグループメンバ表502に作成されることはない。また、アプリケーション管理マネジャ511がユーザアプリケーションと他のプログラム例えばサービスなどを区別することができる場合、切り替えイベント通知部512は、ユーザアプリケーションの状態変化イベントのみを通知対象とてもよい。すると、上記のようなステップS402でのエラー処理がなくても、サービスに関連づけられたエントリが誤ってプロセスグループメンバ表502に作成されることはない。さて、図12~13は、第2実施形態においてプロセス制御モジュール503が行う処理のフローチャートである。図12~13の処理は、スマートフォン500が起動されると開始される。また、図14は、図12と13から呼び出されるサブルーチンのフローチャートである。ステップS501でプロセス制御モジュール503は必要に応じて適宜の初期化を行う。例えば、プロセス制御モジュール503は、内部データを初期化する。また、後述の変形例のように、予め定義された何らかの情報例えば資源ファイル対応表504をプロセスグループ判定部501が利用する場合、プロセスグループ判定部501はステップS501で、予め定義された情報を読み込んでもよい。次のステップS502でプロセス制御モジュール503は、切り替えイベント通知部512からの、アプリケーションの切り替え通知を所定時間待つ。切り替えイベント通知部512からプロセス制御モジュール503への通知は、図8のステップS104に示したとおりである。所定時間内に切り替えイベント通知部512からの通知がなかった場合、処理はステップS503に移行する。また、他のアプリケーションへの切り替えをともなわずに、フォアグラウンドで実行されていたアプリケーションが単に終了したことを切り替えイベント通知部512がプロセスグループ判定部501に通知した場合も、処理はステップS503に移行する。新たなアプリケーションが起動されたこと、または、既に起動されているアプリケーションがフォアグラウンドに遷移したことの通知を切り替えイベント通知部512からプロセスグループ判定部501が受けた場合、処理はステップS505に移行する。例えば、バックグラウンドで実行中のアプリケーション、または一時停止中のアプリケーションが、フォアグラウンドでの実行のために選択された場合、処理はステップS502からステップS505へ移行する。ステップS503でプロセス制御モジュール503は、プロセス制御モジュール503の内部データとして保持する保留プロセスリストを参照する。詳しくは後述するが、保留プロセスリストは、プロセス制御モジュール503がプロセスに対して何らかの制御を試みて失敗したときに、将来のリトライに備えて、処理対象のプロセスと制御の内容を記録するためのリストである。例えば、図5においてプロセス制御モジュール503からカーネル513への矢印とカーネル513からプロセス517への矢印により表されるとおり、プロセス制御モジュール503は、システムコールを用いてプロセスを制御してもよい。保留プロセスリストの各要素は、例えば、プロセスのPIDを引数として含むシステムコールであってもよい。あるいは、保留プロセスリストの各要素は、プロセスのPIDと、プロセスに送信するシグナルのペアであってもよい。プロセス制御モジュール503は、ステップS503で保留プロセスリストを参照し、未注目のプロセスが保留プロセスリストに残っているか否かを判断する。保留プロセスリスト自体が空の場合、または、保留プロセスリスト中の全プロセスについて既に注目してステップS504の処理を終えた場合は、処理はステップS502に戻る。逆に、保留プロセスリストが空でなく、まだステップS504の処理の対象として注目していないプロセスが1つ以上保留プロセスリストに残っている場合は、処理はステップS504に移行する。そして、ステップS504でプロセス制御モジュール503は、保留プロセスリスト中の次の未注目のプロセスに対して、保留プロセスリストに記録された操作を試みる。例えば、PIDが1200のプロセスに対して以前プロセス制御モジュール503が一時停止を試み、何らかの理由で一時停止に失敗したとする。この場合、保留プロセスリストには、1200というPIDと、一時停止という操作内容が記録されている。そこで、ステップS504でプロセス制御モジュール503は、PIDが1200のプロセスの一時停止を再度試みる。なお、ステップS504の詳細は図14とともに後述する。図14に示すサブルーチンは、具体的には、プロセスのPIDと、操作内容と、リトライフラグを引数として含む。リトライフラグは、プロセスに対する操作が、保留プロセスリストに基づくリトライなのか、それとも最初の試みなのかということを示す。ステップS504でのサブルーチンコールにおいて、プロセス制御モジュール503は、リトライフラグを、リトライを示す値例えば1に設定する。また、ステップS504の実行後、処理はステップS503に戻る。プロセス制御モジュール503は、以上のステップS502~S504のようにして、暇な時間つまり、アプリケーションの切り替えが発生していないのでステップS505以降の処理を実行する必要がない時間に、必要に応じてリトライ処理を行う。さて、ステップS505でプロセス制御モジュール503は、切り替えイベント通知部512から通知されたイベントが新たなアプリケーションの起動であるか否かを判断する。新たなアプリケーションが起動された場合、プロセス制御モジュール503が以下で参照するプロセスグループメンバ表502は、プロセスグループ判定部501によってまさに書き換えられるところである。そこで、プロセスグループ判定部501によるプロセスグループメンバ表502の書き換えの完了を待つため、処理はステップS506に移行する。逆に、新たなアプリケーションが起動されたのではない場合、新たにフォアグラウンドになったアプリケーションのプロセスグループは既にプロセスグループメンバ表502に登録されている。例えば、一旦起動された後にバックグラウンドに遷移し、直前までバックグラウンドで実行されていたアプリケーションが、フォアグラウンドに遷移した場合、プロセスグループは既にプロセスグループメンバ表502に登録されている。また、一旦起動された後に一時停止されたアプリケーションが再開されてフォアグラウンドで実行される場合も、プロセスグループは既にプロセスグループメンバ表502に登録されている。よって、新たなアプリケーションが起動されたのではない場合、処理はステップS507に移行する。ステップS506でプロセス制御モジュール503は、プロセスグループメンバ表502を更新が完了したというプロセスグループ判定部501からの通知を受け取るまで待つ。ステップS506でプロセス制御モジュール503が受け取る通知は、図11のステップS412でプロセスグループ判定部501が出す通知である。プロセス制御モジュール503が通知を受け取ると、処理はステップS507に移行する。さて、ステップS507でプロセス制御モジュール503は、プロセス一覧507を取得する。例えば、アプリケーションEが新たに起動された場合、アプリケーションEのプログラムE1とE2の実行は、ステップS506で検出される通知がプロセス制御モジュール503に届いた時点で、既に開始されている。よって、ステップS507で取得されるプロセス一覧507には、プロセスE1とE2がリストアップされている。そして、次のステップS508でプロセス制御モジュール503は、新たにフォアグラウンドで実行されることになったアプリケーションのプロセスグループを認識する。以下では説明の便宜上、ステップS508で認識されるプロセスグループをフォアグラウンドプロセスグループという。例えば、アプリケーションEが起動されたという通知を、プロセス制御モジュール503がステップS502で切り替えイベント通知部512から受け取ったとする。この場合、ステップS508でプロセス制御モジュール503は、Eというアプリケーション名を検索キーにしてプロセスグループメンバ表502を検索し、アプリケーションEに対応づけられているプロセスグループを認識する。プロセスグループメンバ表502が図7のプロセスグループメンバ表502aのとおりである場合、ステップS508でプロセス制御モジュール503は、PIDが10と1002と1012のプロセスを含むプロセスグループを認識する。そして、次のステップS509でプロセス制御モジュール503は、保留プロセスリスト中に、フォアグラウンドプロセスグループに属するプロセスがあるか否かを判断する。フォアグラウンドプロセスグループに属するプロセスが保留プロセスリスト中に含まれる場合、処理はステップS510に移行する。逆に、フォアグラウンドプロセスグループに属するどのプロセスも保留プロセスリスト中には含まれない場合、処理は図13のステップS511に移行する。ステップS510でプロセス制御モジュール503は、フォアグラウンドプロセスグループに属するプロセスを、保留プロセスリストから削除する。例えば、保留プロセスリストには、PIDが1200のプロセスに対する一時停止操作が記録されているとする。また、PIDが1200のプロセスがフォアグラウンドプロセスグループに属するとする。ここで、フォアグラウンドプロセスグループに属するプロセスは、以下に説明するステップS511~S513のとおり、今まさにプロセス制御モジュール503が制御しようとしているプロセスである。具体的には、プロセス制御モジュール503は、フォアグラウンドプロセスグループに属するプロセスに対する操作内容を、ステップS511で決める。仮に、PIDが1200のプロセスが保留プロセスリストから削除されないとすると、PIDが1200のプロセスは、ステップS511~S513で適宜に制御された後、再び実行される将来のステップS504において、一時停止されてしまう。つまり、PIDが1200のプロセスに対する適切な制御としてプロセス制御モジュール503が決めた操作の種類が変化する場合に、新しい方の操作が古い方の操作で上書きされてしまう。そこで、新しい方の操作が古い方の操作で上書きされるという不都合を防ぐため、ステップS510でプロセス制御モジュール503は、フォアグラウンドプロセスグループに属するプロセスを、保留プロセスリストから削除する。そして、処理は図13のステップS511に移行する。ステップS511でプロセス制御モジュール503は、フォアグラウンドプロセスグループに対する操作の内容を決める。具体的には、プロセス制御モジュール503は、フォアグラウンドプロセスグループに属する各プロセスに対して、優先度を上げる操作または再開操作を行うことを決める。なお、実施形態に応じて、プロセス制御モジュール503は、ステップS511において常に、フォアグラウンドプロセスグループに対する操作を、優先度を上げる操作に決めてもよい。または、プロセス制御モジュール503は、ステップS511において常に、フォアグラウンドプロセスグループに対する操作を、再開操作に決めてもよい。あるいは、プロセス制御モジュール503は、スマートフォン500の負荷などの状況に応じて、ステップS511において操作内容を決めてもよい。そして、次のステップS512において、プロセス制御モジュール503は、フォアグラウンドプロセスグループ中に未注目のプロセスが残っているか否かを判断する。フォアグラウンドプロセスグループ中に、まだステップS513の処理の対象としてプロセス制御モジュール503が注目していないプロセスが残っていれば、処理はステップS513に移行する。逆に、フォアグラウンドプロセスグループ中のすべてのプロセスについてプロセス制御モジュール503が既にステップS513の処理を実行し終わっていれば、処理はステップS514に移行する。ステップS513でプロセス制御モジュール503は、フォアグラウンドプロセスグループ中の次の未注目のプロセスに対して、ステップS511で決めた操作を試みる。そして、処理はステップS512に戻る。なお、ステップS513の詳細は、図14とともに後述するが、ステップS513では、前述のリトライフラグが、最初の試みを示す値例えば0に設定される。また、ステップS514でプロセス制御モジュール503は、フォアグラウンドからバックグラウンドに遷移したアプリケーションのプロセスグループを認識する。以下では説明の便宜上、ステップS514で認識されるプロセスグループをバックグラウンドプロセスグループという。例えば、切り替えイベント通知部512からステップS502で通知されたイベントが、アプリケーションEが起動され、今までフォアグラウンドで実行されていたアプリケーションDがバックグラウンドに遷移したというイベントであるとする。この場合、バックグラウンドプロセスグループは、アプリケーションDに対応づけられてプロセスグループメンバ表502に記録されているプロセスグループである。あるいは、切り替えイベント通知部512からステップS502で通知されたイベントが、何もアプリケーションが実行されていない状態から、新規にアプリケーションEが起動されたというイベントであるとする。この場合、フォアグラウンドからバックグラウンドに遷移するアプリケーションはそもそも存在しない。よって、プロセス制御モジュール503はステップS514でバックグラウンドプロセスグループは空であると認識する。そして、次のステップS515でプロセス制御モジュール503は、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないプロセスに対する操作の内容を決める。ステップS515で決定される操作内容は、具体的には、優先度を下げる操作または一時停止操作である。なお、実施形態に応じて、プロセス制御モジュール503は、優先度を下げる操作をステップS515において常に選択してもよい。または、プロセス制御モジュール503は、一時停止操作をステップS515において常に選択してもよい。あるいは、プロセス制御モジュール503は、スマートフォン500の負荷などの状況に応じて、ステップS515において操作内容を決めてもよい。そして、次のステップS516でプロセス制御モジュール503は、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないプロセスの中に、未注目のプロセスが残っているか否かを判断する。もし、まだステップS517の処理の対象としてプロセス制御モジュール503が注目していないプロセスが残っていれば、処理はステップS517に移行する。逆に、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないすべてのプロセスについて、プロセス制御モジュール503が既にステップS517の処理を実行し終わっていれば、処理は図12のステップS502に戻る。なお、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないプロセスがそもそも存在しない場合も同様に、処理はステップS502に戻る。ステップS517でプロセス制御モジュール503は、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないプロセスの中の次の未注目のプロセスに対して、ステップS515で決めた操作を試みる。そして、処理はステップS516に戻る。なお、ステップS517の詳細は、図14とともに後述するが、ステップS517では、前述のリトライフラグが、最初の試みを示す値例えば0に設定される。また、ステップS517の処理の対象から、フォアグラウンドプロセスグループに属するプロセスが除外される理由は、次のとおりである。第1と第2のアプリケーションが同じ特定資源を利用する場合、同じ特定プロセスが第1のアプリケーションのプロセスグループにも含まれ、第2のアプリケーションのプロセスグループにも含まれる。例えば、第1と第2のアプリケーションがいずれもサウンドデバイス603を利用するとする。この場合、サウンドデバイス603を占有してサウンドデバイス603へのアクセスを提供するサウンドデーモン614のプロセスは、第1のアプリケーションのプロセスグループにも含まれ、第2のアプリケーションのプロセスグループにも含まれる。すると、フォアグラウンドアプリケーションが第1のアプリケーションから第2のアプリケーションへと切り替わる場合、バックグラウンドプロセスグループに属するすべてのプロセスに対してステップS517の処理を行うことは不適切である。仮に、サウンドデーモン614のプロセスが、バックグラウンドプロセスグループに属するからといって、優先度が下げられてしまうと、サウンドデバイス603を利用する第2のアプリケーションの性能に悪影響が出てしまう。よって、バックグラウンドプロセスグループに属するプロセスのうち、フォアグラウンドプロセスグループにも属するプロセスは、ステップS517の処理対象から除外することが適切である。なお、以上の図12~13についての説明から明らかなように、どのアプリケーションのプロセスグループにも属さないプロセスは、プロセス制御モジュール503による制御を受けない。例えば、図7の資源ファイル対応表504aには、ディスプレイ604と資源ファイル612を対応づけるエントリが登録されていない。よって、資源ファイル612にアクセスするウィンドウシステム615も、当然、どのアプリケーションのプロセスグループにも属さない。したがって、ウィンドウシステム615のプロセスは、プロセス制御モジュール503の制御を受けない。ほとんどのアプリケーションはウィンドウシステム615を利用する。そのため、プロセス制御モジュール503が、ウィンドウシステム615のプロセスの優先度を下げたり、ウィンドウシステム615のプロセスを一時停止させたりすることは、不適切である。しかし、上記のとおりウィンドウシステム615のプロセスは、プロセス制御モジュール503の制御を受けないので、そのような不適切な制御も当然生じない。また、上記のとおり、アプリケーション以外のプロセス例えばサービス等のプロセスに対応づけられたエントリは、プロセスグループメンバ表502には含まれない。よって、initプロセスのような特殊なプロセスも、プロセス制御モジュール503による制御を受けない。つまり、プロセス制御モジュール503による制御は、アプリケーションと無関係な特殊なプロセスに対して悪影響を及ぼさない。続いて、図14を参照して、上述のステップS504、S513およびS517から呼び出されるサブルーチンの詳細を説明する。なお、図14のサブルーチンの引数は、具体的には、操作対象のプロセスを指定するPIDと、操作の種類と、リトライフラグを含む。ステップS601でプロセス制御モジュール503は、引数で指定された操作の種類を判定する。そして、指定された操作の種類が優先度の変更である場合、処理はステップS602に移行する。また、指定された操作の種類が一時停止または再開である場合、処理はステップS603に移行する。ステップS602でプロセス制御モジュール503は、引数でPIDが指定されたプロセスの優先度クラスを、引数で指定されたクラスに変更する。プロセスの優先度は、OSに応じて異なる方法で管理される。例えば第2実施形態では、プロセスの優先度は、複数の優先度クラスのいずれかに指定される。例えば、OSによって定義された優先度クラスが高優先度クラスと低優先度クラスの2つであってもよい。この場合、優先度を上げる操作とは、具体的には優先度クラスを高優先度クラスに設定する操作であり、優先度を下げる操作とは、優先度クラスを低優先度クラスに設定する操作である。もちろん、3つ以上の優先度クラスが定義されていてもよい。その場合、プロセス制御モジュール503は、優先度をどの程度上げるかをステップS511で決め、優先度をどの程度下げるかをステップS515で決めてもよい。なお、最低の優先度のクラスは、CPU時間の割り当てが固定的に0と決められるような、特殊なクラスであってもよい。その場合、優先度を下げる操作によって、実質的には一時停止操作を実現することも可能である。また、ステップS603でプロセス制御モジュール503は、引数でPIDが指定されたプロセスに対し、引数で指定された操作に応じたシグナルを送信する。なお、操作の内容を示す引数が、送信するシグナルの値そのものであってもよい。例えば、指定された操作が一時停止ならば、プロセス制御モジュール503は、一時停止のためのシグナル例えばSIGSTOPを送信する。また、指定された操作が再開ならば、プロセス制御モジュール503は、再開のためのシグナル例えばSIGCONTを送信する。なお、一時停止中ではないプロセスつまり実行中のプロセスに再開のためのシグナルが送信されても、シグナルは単に無視されるだけなので、有害な副作用は生じない。そして、ステップS602またはS603の実行後、処理はステップS604に移行する。ステップS604でプロセス制御モジュール503は、ステップS602またはS603の操作が、成功したか失敗したかということを判断する。例えば、ステップS602とS603の処理は、システムコールにより実現されてもよい。そして、システムコールが成功したか失敗したかを示す返り値が、カーネル513からプロセス制御モジュール503に返されてもよい。すると、プロセス制御モジュール503は、返り値に基づいてステップS604の判断を実行することができる。あるいは、プロセス制御モジュール503は、ステップS604において、制御の対象のプロセスの優先度クラスを参照し、優先度クラスが引数で指定されたとおりに正しく設定されたか否かを判断してもよい。同様に、プロセス制御モジュール503は、ステップS604において、制御の対象のプロセスの状態を参照し、プロセスが正しく一時停止または再開されたか否かを判断してもよい。そして、ステップS602またはS603の操作が成功した場合、処理はステップS605に移行する。逆に、ステップS602またはS603の操作が失敗した場合、処理はステップS607に移行する。なお、ステップS602またはS603の操作が失敗する場合としては、例えば、操作対象のプロセスが何らかのシステムコールを実行中の場合や、何らかの資源をオープンして確保している場合などがあり得る。ステップS605でプロセス制御モジュール503は、引数として指定されたリトライフラグの値を参照して、今回のサブルーチンコールがリトライなのか否かを判断する。そして、今回のサブルーチンコールがリトライであれば、処理はステップS606に移行し、今回のサブルーチンコールが1回目の試みであれば、図14の処理は終了する。そして、ステップS606でプロセス制御モジュール503は、引数で指定されたPIDと、引数で指定された操作内容のペアを保留プロセスリストから削除する。つまり、リトライによって成功した操作は、さらにもう一度試みる必要がないので、ステップS606では保留プロセスリストからの要素の削除が行われる。そして、図14の処理は終了する。また、ステップS607でプロセス制御モジュール503は、引数として指定されたリトライフラグの値を参照して、今回のサブルーチンコールがリトライなのか否かを判断する。そして、今回のサブルーチンコールがリトライであれば、プロセス制御モジュール503は保留プロセスリストを更新せずに図14の処理を終了する。なぜなら、プロセス制御モジュール503が以前失敗した操作に再度失敗した場合、当該操作は依然としてリトライの対象のままだからである。逆に、今回のサブルーチンコールが1回目の試みであれば、処理はステップS608に移行する。そして、ステップS608でプロセス制御モジュール503は、引数で指定されたPIDと、引数で指定された操作内容のペアを保留プロセスリストに追加する。そして、図14の処理は終了する。以上説明したように、第2実施形態によれば、アプリケーションが利用する資源に基づいて適切なプロセスグループが認識される。そして、フォアグラウンドで実行されるアプリケーションのプロセスグループと、フォアグラウンドからバックグラウンドに遷移したアプリケーションのプロセスグループに対して、それぞれ適宜の制御が行われる。そのため、たとえスマートフォン500のハードウェアが貧弱であっても、フォアグラウンドアプリケーションのプロセスグループに対して重点的にハードウェアが割り当てられる。その結果、フォアグラウンドアプリケーションを利用するユーザが感じる性能は、良好に保たれる。例えば、スマートフォン500が有するCPU201のクロック周波数がさほど高くなくても、第2実施形態によれば、フォアグラウンドアプリケーションのプロセスグループに属するプロセスに対してCPU時間が重点的に割り当てられる。そのため、例えば比較的短い応答時間が実現される。その結果、ユーザは、快適にフォアグラウンドアプリケーションを利用することができ、性能の良さを感じるであろう。さて、以上説明した第2実施形態は、下記13a~13hに示す観点から変形することができ、13a~13hの変形例は、互いに矛盾しない限り任意に組み合わせることが可能である。13aOSの優先度制御の仕組みに応じて、プロセス制御モジュール503による優先度制御の方法は、適宜変形されてよい。13bプローブ509の負荷を削減するために、使用されないことが明らかな資源は、プローブ509による監視対象から除外されてもよい。13cプローブ509の負荷を削減するために、必ず特定プロセスからアクセスされる特定資源は、プローブ509による監視対象から除外されてもよい。13d動的に子孫プロセスが生成され得る場合に、より適切なプロセスグループの認識を可能とするために、プロセス同士の親子関係が参照されてもよい。13eプロセス制御モジュール503が一時停止制御を行う場合に、一時停止にともなう副作用を回避するための例外処理が行われてもよい。13fメモリ不足の解消のため、プロセスグループを利用した強制終了制御が行われてもよい。13gプローブ509は必ずしもカーネル513内に実装されなくてもよい。13h保留リストを用いる制御は適宜変形されてもよい。以下では上記13a~13hの変形例について説明する。OSによって優先度制御の仕組みは異なり、ある種のOSでは、優先度クラスが1つしかない。優先度クラスが1つしかないある種のOSでは、動的に変動する値によりプロセスの優先度が管理される。そして、OS内のプロセススケジューラは、動的に変動する値に応じてプロセスをスケジューリングする。上記13aの変形例は、具体的には、優先度クラスが1つしかない場合に、図14のサブルーチンが図15のように変形される例である。優先度クラスが1つしかないOSでは、例えばniceコマンドによってプロセスに設定されるnice値nicenessに基づいて、プロセスの優先度が動的に制御される。例えば、プロセスがCPU時間を消費するほど、プロセスの優先度を示す動的な値は、より低い優先度を示す値に書き換えられる。よって、プロセスの優先度を示す動的な値は、時間の経過につれて、より低い優先度を示すようになる傾向がある。そこで、13aの変形例では、図14のサブルーチンが図15のサブルーチンで置き換えられる。また、プロセス制御モジュール503は、動的に低下する傾向のある優先度を再設定するための内部データとして、優先度操作対象リストを保持する。優先度操作対象リストの各要素は、PIDとnice値のペアである。また、図示は省略したが、13aの変形例では、プロセス制御モジュール503による図12~13の処理が次のように変形される。すなわち、プロセス制御モジュール503は、ステップS512よりも前例えばステップS511の直後に、優先度操作対象リストをクリアする。以下、図15の処理について説明する。ステップS701でプロセス制御モジュール503は、引数で指定された操作の種類を判定する。そして、指定された操作の種類が優先度の変更である場合、処理はステップS702に移行する。また、指定された操作の種類が一時停止または再開である場合、処理はステップS704に移行する。ステップS702でプロセス制御モジュール503は、引数でPIDが指定されたプロセスの静的優先度を示すnice値を、引数で指定された値に変更する。ステップS702の処理は、具体的にはniceコマンドの実行により実現されてもよい。そして、次のステップS703でプロセス制御モジュール503は、優先度操作対象リストに、引数で指定されたPIDと引数で指定された値のペアを追加する。そして、処理はステップS705に移行する。また、ステップS704でプロセス制御モジュール503は、引数でPIDが指定されたプロセスに対し、引数で指定された操作に応じたシグナルを送信する。ステップS704はステップS603と同様である。ステップS704の実行後、処理はステップS705に移行する。ステップS705~S709は、図14のステップS604~S608と同様である。ところで、13aの変形例では、プロセス制御モジュール503がさらに定期的に以下の処理も行う。すなわち、プロセス制御モジュール503は、優先度操作対象リストの各要素すなわちPIDとnice値のペアに対して、当該ペアのPIDで識別されるプロセスに、当該ペアに記録されているnice値を設定する。上記のとおり、プロセスの優先度を示す動的な値は、時間の経過とともに、より低い優先度を示すようになる傾向がある。しかし、動的な値は、nice値の設定を契機としてリセットされる。そのため、プロセス制御モジュール503が上記のように定期的に優先度操作対象リストに登録された各プロセスのnice値を再設定することで、優先度操作対象リストに登録された各プロセスの動的な優先度の低下を、ある程度抑制することができる。すなわち、図13のステップS511において、フォアグラウンドプロセスグループが優先度を上げる対象として決定された場合に、フォアグラウンドプロセスグループに属する各プロセスの動的な優先度を高く保つために、nice値の定期的な再設定が行われる。続いて、13b~13fの変形例について説明する。13b~13fの変形例では、図5のスマートフォン500にさらに処理モジュールが追加され、スマートフォン500はさらに他のデータも保持する。そこで、13b~13fの変形例において追加される処理モジュールとデータについて、図16を参照して説明する。図16は、13b~13fの変形を組み合わせた場合の、スマートフォン500aのブロック構成図である。図16のスマートフォン500aは、図5のスマートフォン500と同様の各種処理モジュールを有し、スマートフォン500と同様の各種データを保持する。さらに、スマートフォン500aは、13bの変形例で使われるアプリケーション情報解析部519を含む。また、スマートフォン500aは、13cの変形例で使われる資源プロセス名対応表520と監視資源フィルタ521と既知メンバ検出部522を含む。そして、スマートフォン500aは、13dの変形例で使われる親子関係判定部523も含む。さらに、スマートフォン500aのプロセス制御モジュール503は、13eの変形例で使われる競合判定部524を含む。また、スマートフォン500aのカーネル513は、13fの変形例で使われるメモリ管理モジュール525を含む。なお、メモリ管理モジュール525の詳細は、図28とともに後述する。図16のスマートフォン500aに追加された上記処理モジュールとデータの詳細は、13b~13fの変形例についての詳しい説明とともに後述する。なお、図示の便宜上、図16には13b~13fの変形を組み合わせた場合のスマートフォン500aを例示した。しかし、もちろん、13b~13fの変形は、単独に第2実施形態に適用されてもよい。例えば、13fの変形のみを第2実施形態に適用する場合は、図5のスマートフォン500のカーネル513に図16のメモリ管理モジュール525が追加されるだけで構わない。他の13b~13eの変形例についても同様に、単独で第2実施形態に適用可能である。続いて、使用されないことが明らかな資源をプローブ509による監視対象から除外することでプローブ509の処理負荷を削減する、13bの変形例について説明する。第2実施形態における監視対象資源ファイルリスト518は、スマートフォン500のハードウェア構成に応じて予め設定された静的な情報である。しかし、例えばスマートフォン500が有する複数の物理デバイス515の中には、スマートフォン500にインストール済みのどのユーザアプリケーションからもアクセスされない物理デバイス515があるかもしれない。すると、どのユーザアプリケーションからもアクセスされない物理デバイス515へのアクセスをプローブ509が監視する必要はない。例えば、図16のスマートフォン500aは、物理デバイス515の1つとして、図6のGPS受信機601を有するかもしれない。しかし、GPS受信機601を使用するいかなるアプリケーションも、スマートフォン500aにはインストールされていないかもしれない。すると、アプリケーションに関連するプロセスグループの認識のためには、GPS受信機601へのアクセスを監視することは不要である。したがって、GPS受信機601をプローブ509による監視対象から除外することにより、プローブ509にかかる不要な負荷をなくすことができる。なお、たとえGPS受信機601を使用するアプリケーションがなくても、OSにより提供されるロケーションマネジャ613がGPS受信機601を使用する可能性はある。しかし、プロセスグループ判定部501が認識しようとする各プロセスグループは、アプリケーションに対応するものである。よって、アプリケーションと無関係にロケーションマネジャ613がGPS受信機601にアクセスするのをプローブ509が監視する必要はない。そこで、13bの変形例では、アプリケーションによって使用されないことが明らかな資源が、プローブ509による監視対象から除外される。具体的には、13bの変形例では、スマートフォン500aに実際にインストールされたアプリケーションに応じて監視対象資源ファイルリスト518が書き換えられる。そして、監視対象資源ファイルリスト518の書き換えのため、スマートフォン500aは、アプリケーション情報解析部519を備える。また、プローブ509は、監視対象資源ファイルリスト518の変更に応じて、監視対象を変更する。以下、図17と18を参照して、13bの変形例のさらなる詳細を説明する。図17は、13bの変形例においてアプリケーション情報解析部519が行う処理のフローチャートである。図17の処理は、スマートフォン500aが起動されると開始される。ステップS801でアプリケーション情報解析部519は、インストーラ617の動作を監視する。そして、インストーラ617によってアプリケーションの追加すなわちインストールまたは削除すなわちアンインストールの開始をアプリケーション情報解析部519が検出すると、処理はステップS802に移行する。インストーラ617によってその他の処理が行われる場合、あるいは、インストーラ617が何も行わない間は、アプリケーション情報解析部519はステップS801で待機する。そして、ステップS802でアプリケーション情報解析部519は、追加または削除されるアプリケーションが利用する資源の一覧を作成する。具体的には、アプリケーション情報解析部519は、パッケージ情報DB506から利用外部資源名リストを抽出する。なお、アプリケーション情報解析部519は、追加または削除されるアプリケーションの名前を、インストーラ617の監視結果から認識することができる。また、アプリケーション情報解析部519は、アプリケーションの追加と削除のどちらが行われるのかも、インストーラ617の監視結果から認識することができる。アプリケーションが追加される場合、アプリケーション情報解析部519は、アプリケーションパッケージ中のパッケージ情報がパッケージ情報DB506に格納され終わるのを待つ。そして、アプリケーション情報解析部519は、アプリケーション名を検索キーにしてパッケージ情報DB506を検索し、見つかったエントリから利用外部資源名リストを抽出する。また、アプリケーションが削除される場合、アプリケーション情報解析部519は、アプリケーションの削除にともなってパッケージ情報DB506からエントリが削除される前に、アプリケーション名を検索キーにしてパッケージ情報DB506を検索する。そして、アプリケーション情報解析部519は、見つかったエントリから利用外部資源名リストを抽出する。以上のようにして、ステップS802でアプリケーション情報解析部519は、追加または削除されるアプリケーションの利用外部資源名リストを抽出する。しかし、こうして抽出される利用外部資源名リストでは、図7に例示するように、各資源が論理的識別情報により表されている。そこで、次のステップS803でアプリケーション情報解析部519は、資源ファイル対応表504を用いて、物理監視対象の一覧を作成する。具体的には、アプリケーション情報解析部519は、ステップS802で作成した一覧に含まれる各論理的識別情報に対応する資源ファイル名を、資源ファイル対応表504から取得し、取得した資源ファイル名の一覧を作成する。例えば、GPS受信機601とサウンドデバイス603を使用するアプリケーションが追加または削除されるとする。この場合、ステップS802で抽出される利用外部資源名リストには、GPSという文字列で表される論理的識別情報と、サウンドという文字列で表される論理的識別情報が含まれる。そこで、アプリケーション情報解析部519は、資源ファイル対応表504を参照して、GPS受信機601とサウンドデバイス603にそれぞれ対応する資源ファイル名/dev/tty1と/dev/sndを取得する。そして、アプリケーション情報解析部519は、取得した資源ファイル名の一覧を作成する。続いて、ステップS804でアプリケーション情報解析部519は、アプリケーションの追加または削除による監視対象資源ファイルリスト518への影響があるか否かを判断する。そして、影響がある場合、処理はステップS805に移行し、影響がない場合、処理はステップS801に戻る。具体的には、アプリケーション情報解析部519は、以下のようにしてステップS804の判断を行う。ステップS801でアプリケーションの追加を検出した場合、アプリケーション情報解析部519は、現在の監視対象資源ファイルリスト518には含まれない資源ファイル名が、ステップS803で作成した一覧の中にあるか否かを判断する。もし、現在の監視対象資源ファイルリスト518には含まれない資源ファイル名が、ステップS803で作成した一覧の中にあれば、アプリケーション情報解析部519は影響ありと判断する。逆に、ステップS803で作成した一覧に含まれるすべての資源ファイル名が、既に監視対象資源ファイルリスト518にリストアップされていれば、アプリケーション情報解析部519は影響なしと判断する。また、ステップS801でアプリケーションの削除を検出した場合、アプリケーション情報解析部519は、ステップS802で作成した一覧に含まれる各資源名について、以下の処理を行う。すなわち、アプリケーション情報解析部519は、パッケージ情報DB506を参照して、当該資源名で識別される資源を利用する他のアプリケーションが存在するか否かを確認する。そして、もし、削除されるアプリケーション以外のどのアプリケーションによっても利用されない資源が1つ以上見つかれば、アプリケーション情報解析部519は、影響ありと判断する。逆に、削除されるアプリケーションが利用するすべての資源が、他のいずれかのアプリケーションによっても利用されることが判明すれば、アプリケーション情報解析部519は、影響なしと判断する。ステップS805でアプリケーション情報解析部519は、監視対象資源ファイルリスト518を更新する。具体的には、ステップS801でアプリケーションの追加を検出した場合、アプリケーション情報解析部519は、下記の14aと14bの条件をともに満たすすべての資源ファイル名を、監視対象資源ファイルリスト518に追加する。14a現在の監視対象資源ファイルリスト518には含まれない14bステップS803で作成した一覧には含まれるステップS801でアプリケーションの削除を検出した場合、アプリケーション情報解析部519は、削除されるアプリケーション以外のどのアプリケーションによっても利用されない資源の資源ファイル名を、監視対象資源ファイルリスト518から削除する。そして、次のステップS806でアプリケーション情報解析部519は、資源依存関係表505のエントリを追加または削除する。ステップS806の意味と詳細は以下のとおりである。第2実施形態では、監視対象資源ファイルリスト518は静的なデータである。そして、図10に関して説明したとおり、資源依存関係表505は、監視対象資源ファイルリスト518に含まれる各資源ファイル名に対応するエントリを有し、かつ、各エントリのPIDフィールドはクリアされているという状態に初期化される。それに対して、13bの変形例は、アプリケーションの追加または削除に応じて監視対象資源ファイルリスト518が動的に変化し得る。ステップS806の処理は、監視対象資源ファイルリスト518の変化に合わせて資源依存関係表505を更新するために行われる。したがって、具体的には、ステップS801でアプリケーションの追加を検出した場合、アプリケーション情報解析部519は、ステップS805で監視対象資源ファイルリスト518に追加した各資源ファイル名について、以下の処理を行う。すなわち、アプリケーション情報解析部519は、監視対象資源ファイルリスト518に追加した資源ファイル名を含む新規エントリを資源依存関係表505に追加し、追加したエントリのPIDフィールドをクリアする。また、ステップS801でアプリケーションの削除を検出した場合、アプリケーション情報解析部519は、ステップS805で監視対象資源ファイルリスト518から削除した各資源ファイル名に対応するエントリを資源依存関係表505から削除する。ステップS806における以上のようなエントリの追加または削除により、アプリケーション情報解析部519は、資源依存関係表505と監視対象資源ファイルリスト518の整合性を保つ。そして、次のステップS807でアプリケーション情報解析部519は、監視対象の追加または削除をプローブ509に通知する。そして、処理はステップS801に戻る。なお、ステップS807での通知を受けたときのプローブ509の動作は、図18とともに後述する。なお、アプリケーションが削除されたときのステップS804の判断の負荷削減のために、監視対象資源ファイルリスト518のデータ形式が変形されてもよい。すなわち、監視対象資源ファイルリスト518は、資源ファイル名と、当該資源ファイル名に対応する資源を利用するアプリケーションの数とを対応づけるエントリを有するテーブル以下便宜的に監視対象資源ファイルテーブルというに変形されてもよい。アプリケーション情報解析部519は、ステップS801でアプリケーションの追加を検出した場合、ステップS803で作成した一覧に含まれる各資源ファイルに対応する監視対象資源ファイルテーブルのエントリにおいて、アプリケーションの数を1増やす。逆に、アプリケーション情報解析部519は、ステップS801でアプリケーションの削除を検出した場合は、アプリケーションの数を1減らす。すると、アプリケーション情報解析部519は、ステップS801でアプリケーションの削除を検出した場合、ステップS804において、単に、アプリケーションの数が0のエントリが監視対象資源ファイルテーブルにあるか否かを判断するだけでよい。つまり、多数のアプリケーションがスマートフォン500にインストールされている場合でも、アプリケーション情報解析部519は、パッケージ情報DB506の多数のエントリを参照する必要がない。さて、図18は、13bの変形例においてプローブ509が行う処理のフローチャートである。図18の処理は、スマートフォン500aが起動されると開始される。ステップS901でプローブ509は、監視対象資源ファイルリスト518を読み取り、監視対象の資源に対応する資源ファイル516を認識する。そして、プローブ509は、監視対象資源ファイルリスト518で指定される各資源に対するシステムコールの監視を開始する。ステップS901は図9のステップS201と同様だが、読み取る対象の監視対象資源ファイルリスト518が静的か動的かという点がステップS201とS901では異なる。そして、次のステップS902でプローブ509は、アプリケーション情報解析部519から通知されたイベントがあるか否かを確認する。そして、監視対象の追加または削除というイベントがアプリケーション情報解析部519から通知されている場合、処理はステップS903に移行する。逆に、何のイベントもアプリケーション情報解析部519から通知されていない場合、処理はステップS904に移行する。ステップS903でプローブ509は、アプリケーション情報解析部519により更新された監視対象資源ファイルリスト518を参照する。そして、更新された監視対象資源ファイルリスト518にしたがって、プローブ509は、監視対象デバイスを追加または削除する。ステップS903の処理は、具体的には、例えば、監視対象デバイスを示すプローブ509の内部変数の値を、監視対象資源ファイルリスト518の変更に応じて変更する処理である。ステップS903の実行後、処理はステップS904に移行する。ステップS904でプローブ509は、監視対象の資源に対応する資源ファイル516に対するシステムコールの呼び出しを所定の時間待つ。所定の時間以内にシステムコールの呼び出しがあると、処理はステップS905に移行する。逆に、所定の時間待っても、監視対象の資源に対応する資源ファイル516に対するシステムコールの呼び出しがない場合は、処理はステップS902に戻る。そして、ステップS905でプローブ509は、システムコールの種類を判定する。システムコールの種類が、資源獲得のためのオープンまたは資源解放のためのクローズである場合、処理はステップS906に移行する。他の種類のシステムコールの場合、処理はステップS907に移行する。そして、ステップS906でプローブ509は、図9のステップS204と同様に、依存関係管理部508に、操作内容、操作対象、および呼び出し元PIDを通知する。そして、処理はステップS907に移行する。ステップS907では、図9のステップS205と同様にシステムコールが実行される。そして、処理はステップS902に戻る。なお、以上説明した13bの変形例において、プロセスグループ判定部501、プロセス制御モジュール503、依存関係管理部508、および、切り替えイベント通知部512を含むアプリケーション管理マネジャ511の動作は、第2実施形態と同じである。続いて、上記13bの変形例とは別の観点からプローブ509の負荷を削減する、13cの変形例について説明する。具体的には、13cの変形例では、必ず特定プロセスからアクセスされる特定資源が、プローブ509による動的な監視対象から除外され、それによってプローブ509の負荷が削減される。そして、13cの変形例では、静的な情報を用いることで、特定プロセスを介したアクセスにより特定資源を利用するアプリケーションのプロセスグループに特定プロセスが追加される。また、プローブ509とプロセスグループ判定部501の動作が第2実施形態とは異なる。図16に関して説明したとおり、13cの変形例では、資源プロセス名対応表520と監視資源フィルタ521と既知メンバ検出部522が追加される。資源プロセス名対応表520は、特定資源と特定プロセスを静的に対応づける情報である。また、監視資源フィルタ521は、資源プロセス名対応表520と資源ファイル対応表504に基づいて、監視対象から除外される資源ファイル516を判別し、監視対象から除外される資源ファイル516をプローブ509に通知する。そして、既知メンバ検出部522は、プロセスグループ判定部501からの要求に応じて、資源プロセス名対応表520とプロセス一覧507を参照し、特定プロセスのPIDのリストをプロセスグループ判定部501に返す。すると、プロセスグループ判定部501は、既知メンバ検出部522から得たリストに基づいて、特定プロセスをプロセスグループに追加する。ここで、資源プロセス名対応表520の具体例である資源プロセス名対応表520aについて、図7を参照して説明する。図7の資源プロセス名対応表520aは、特定資源の論理的識別情報としての外部資源名と、特定プロセスのプロセス名を対応づける静的な情報である。図7の例では、資源プロセス名対応表520aは1つだけエントリを持つが、もちろんエントリの数は任意である。図7に例示したエントリでは、サウンドデバイス603を論理的に識別するサウンドという文字列と、サウンドデーモン614のプロセス名すなわちサウンドデーモン614のプログラム名であるサウンドデーモンという名前が対応づけられている。このエントリは、次の15aと15bを表す。15aサウンドデバイス603という特定資源が、サウンドデーモン614という特定プログラムのプロセスである特定プロセスにより占有される。15bサウンドデバイス603という特定資源への、他のプロセスからのアクセスは、特定プロセスであるサウンドデーモン614のプロセスを介して行われる。つまり、特定プロセスは特定資源へのインタフェイスを他のプロセスに対して提供する。また、資源プロセス名対応表520aにおいてPIDではなくプロセス名が使われる理由は、資源プロセス名対応表520aが静的に予め設定される情報だからである。例えば、サウンドデバイス603という特定資源とサウンドデーモン614という特定プログラムの対応関係は、スマートフォン500aのOSの設計に応じて静的に決まる。しかし、サウンドデーモン614のプロセスに割り当てられるPIDは、スマートフォン500aが起動するたびに異なる可能性がある。そこで、サウンドデーモン614のプロセスを識別することが可能な情報であり、かつ静的な情報でもあるプロセス名が、資源プロセス名対応表520aでは使われる。また、特定資源の場合は、資源プロセス名対応表520aのいずれかのエントリの外部資源名フィールドに論理的識別情報が登録されている。他方、特定資源以外の資源の場合は、資源プロセス名対応表520aのどのエントリにも論理的識別情報が登録されていない。よって、特定資源と他の資源の区別は、資源プロセス名対応表520aから判定可能である。他方、図7の資源ファイル対応表504aのフラグフィールドも、特定資源と他の資源を区別するための情報である。したがって、資源プロセス名対応表520aが使われる場合、資源ファイル対応表504aのフラグフィールドはなくてもよい。続いて、図19を参照して、13cの変形例において監視資源フィルタ521が行う処理について説明する。図19の処理も、スマートフォン500aが起動すると開始される。ステップS1001で監視資源フィルタ521は、資源プロセス名対応表520を読み取る。また、次のステップS1002で監視資源フィルタ521は、資源ファイル対応表504を読み取る。そして、次のステップS1003で、監視資源フィルタ521は、プローブ509による監視対象から除外する物理資源を特定し、特定した物理資源をプローブ509に通知する。具体的には、監視資源フィルタ521は、資源プロセス名対応表520の各エントリについて、当該エントリの外部資源名を検索キーにして資源ファイル対応表504を検索し、外部資源名に対応する資源ファイル名を取得する。そして、監視資源フィルタ521は、取得した資源ファイル名のリストをプローブ509に通知する。例えば、資源プロセス名対応表520が図7の資源プロセス名対応表520aのとおりであるとし、資源ファイル対応表504が図7の資源ファイル対応表504aのとおりであるとする。すると、ステップS1003で監視資源フィルタ521は、資源プロセス名対応表520aのエントリのサウンドという外部資源名を検索キーにして資源ファイル対応表504aを検索し、/dev/sndという資源ファイル名を得る。そして、監視資源フィルタ521は、/dev/sndという資源ファイル名をプローブ509に通知する。ステップS1003での通知の後、処理はステップS1004に移行する。そして、ステップS1004で監視資源フィルタ521は、資源プロセス名対応表520の更新を監視する。資源プロセス名対応表520が更新されなければ、監視資源フィルタ521はステップS1004で待機する。逆に、資源プロセス名対応表520が更新されると、処理はステップS1001に戻る。なお、資源プロセス名対応表520が更新されるのは、例えば、サードパーティによるサービスの追加やOSのアップグレードなどにともなって、サービスの新規追加や削除が発生した場合、もしくは、サービスの仕様が変更された場合などである。ところで、13bと13cの変形は、プローブ509の負荷を削減するという目的において共通である。よって、プローブ509の負荷削減のためには、13bと13cの変形を組み合わせることが好ましい。そこで、図20を参照して、13bと13cの変形を組み合わせた場合にプローブ509が行う処理について説明する。なお、13cの変形のみが採用される場合は、図20のステップS1102~S1103が省略される。また、図20の処理も、スマートフォン500aが起動されると開始される。ステップS1101でプローブ509は、監視対象資源ファイルリスト518を読み取り、監視対象の資源に対応する資源ファイル516を認識する。そして、プローブ509は、監視対象資源ファイルリスト518で指定される各資源に対するシステムコールの監視を開始する。ステップS1101は図18のステップS901と同様である。そして、次のステップS1102でプローブ509は、アプリケーション情報解析部519から通知されたイベントがあるか否かを確認する。そして、監視対象の追加または削除というイベントがアプリケーション情報解析部519から通知されている場合、処理はステップS1103に移行する。逆に、何のイベントもアプリケーション情報解析部519から通知されていない場合、処理はステップS1104に移行する。ステップS1103でプローブ509は、アプリケーション情報解析部519により更新された監視対象資源ファイルリスト518を参照する。そして、更新された監視対象資源ファイルリスト518にしたがって、プローブ509は監視対象デバイスを追加または削除する。ステップS1103の詳細は図18のステップS903と同様である。ステップS1103の実行後、処理はステップS1104に移行する。ステップS1104でプローブ509は、監視資源フィルタ521からの通知つまり、図19のステップS1003で行われる通知があったか否かを確認する。そして、監視資源フィルタ521からの通知があった場合、処理はステップS1105に移行する。逆に、監視資源フィルタ521から通知がなかった場合、処理はステップS1106に移行する。ステップS1105でプローブ509は、監視資源フィルタ521からの通知に応じて、監視対象デバイスを追加または削除する。ステップS1105の処理は、具体的には、例えば、監視対象デバイスを示すプローブ509の内部変数の値を、監視資源フィルタ521から通知された内容に応じて変更する処理である。具体的には、今まで監視対象だった物理デバイス515が、監視対象ではなくなった場合、プローブ509は、監視資源フィルタ521からの通知に応じて、監視対象デバイスを削除する。つまり、プローブ509は、監視資源フィルタ521から通知された資源ファイル名を現在は監視対象として認識している場合、通知された資源ファイル名を監視対象から除外する。逆に、今まで監視対象ではなかった物理デバイス515が、新たに監視対象になった場合、プローブ509は、監視資源フィルタ521からの通知に応じて、監視対象デバイスを追加する。つまり、プローブ509は、監視対象資源ファイルリスト518に含まれる資源ファイル名のうちで現在は監視対象として認識していない資源ファイル名が監視資源フィルタ521からの通知に含まれない場合、当該資源ファイル名を監視対象に追加する。ステップS1105の実行後、処理はステップS1106に移行する。なお、図20のステップS1106~S1109は、図18のステップS904~S907と同様である。続いて、13cの変形例におけるプロセスグループ判定部501の動作について、図21を参照して説明する。13cの変形例では、図11のステップS406で未注目の利用資源名がなかった場合、ステップS412の通知の前に、プロセスグループ判定部501が図21のステップS1201~S1203の処理を行う。すなわち、ステップS1201でプロセスグループ判定部501は、起動したアプリケーションが利用する資源のうちで、もし特定プロセスによって占有される特定資源があれば、特定プロセスのPIDを通知してくれるよう、既知メンバ検出部522に要求する。具体的には、ステップS1201においてプロセスグループ判定部501は、ステップS402で取得した利用資源名のリストを、要求の引数として、既知メンバ検出部522に出力する。なお、上記のとおり、ステップS402で取得される利用資源名の数は0以上である。そして、次のステップS1202でプロセスグループ判定部501は、既知メンバ検出部522から回答が得られるまで待つ。既知メンバ検出部522からの回答が得られると、処理はステップS1203に移行する。なお、ステップS1201でのプロセスグループ判定部501からの要求を受けた既知メンバ検出部522は、0個以上のPIDのリストをプロセスグループ判定部501に返す。既知メンバ検出部522の動作の詳細は、図22とともに後述する。そして、ステップS1203でプロセスグループ判定部501は、既知メンバ検出部522から得られた回答リスト中の全PIDを、プロセスグループメンバ表502の、起動したアプリケーションに対応するエントリのPIDリストに追加する。その後、処理はステップS412に移行する。例えば、新たに起動したアプリケーションが、GPS受信機601と加速度センサ602とサウンドデバイス603という3つの物理デバイス515を利用するとする。この場合、ステップS1201では、これら3つの物理デバイス515の資源名のリストが出力される。そして、資源プロセス名対応表520が例えば図7の資源プロセス名対応表520aのとおりであるとする。つまり、上記3つの物理デバイス515のうち、サウンドデバイス603のみが特定資源である。したがって、既知メンバ検出部522からプロセスグループ判定部501が受け取る回答リストには、サウンドデバイス603を占有してサウンドデバイス603へのアクセスを仲介するサウンドデーモン614のプロセスのPIDのみが含まれる。よって、プロセスグループ判定部501はステップS1203で、プロセスグループメンバ表502における、起動したアプリケーションに対応するエントリのPIDリストに、サウンドデーモン614のプロセスのPIDを追加する。続いて、13cの変形例における既知メンバ検出部522の動作について、図22を参照して説明する。図22の処理はスマートフォン500aが起動すると開始される。ステップS1301で既知メンバ検出部522は、プロセスグループ判定部501からの要求を受け取るまで待機する。すなわち、プロセスグループ判定部501が図21のステップS1201で利用資源名のリストを既知メンバ検出部522に出力するまで、既知メンバ検出部522は待機する。既知メンバ検出部522がプロセスグループ判定部501からの要求を受け取ると、処理はステップS1302に移行する。そして、ステップS1302で既知メンバ検出部522は、プロセスグループ判定部501に返すためのPIDリストを、空に初期化する。また、次のステップS1303で既知メンバ検出部522はプロセス一覧507を取得する。そして、次のステップS1304で既知メンバ検出部522は、プロセスグループ判定部501からの要求で指定されているリスト中で未注目の利用資源名があるか否かを判断する。プロセスグループ判定部501からの要求の引数であるリスト中に、まだ既知メンバ検出部522が注目していない利用資源名が残っている場合、処理はステップS1305に移行する。逆に、プロセスグループ判定部501からの要求の引数であるリスト中のすべての利用資源名に、既知メンバ検出部522が既に注目し終わっている場合、処理はステップS1308に移行する。また、プロセスグループ判定部501からの要求の引数であるリストがそもそも空リストの場合も、処理はステップS1308に移行する。ステップS1305で既知メンバ検出部522は、資源プロセス名対応表520に、既知メンバ検出部522が現在注目している利用資源名のエントリがあるか否かを判断する。なお、以下では説明の便宜上、既知メンバ検出部522が現在注目している利用資源名を注目資源名といい、注目資源名で識別される資源を注目資源という。もし、注目資源名のエントリが資源プロセス名対応表520になければ、注目資源は、特定資源以外の資源である。よって、注目資源をアプリケーションが利用するという事実は、アプリケーションのプロセスグループに影響を及ぼさない。したがって、処理はステップS1304に戻る。逆に、注目資源名のエントリが資源プロセス名対応表520にあれば、注目資源は、特定資源である。よって、注目資源をアプリケーションが利用するという事実は、アプリケーションのプロセスグループに影響を及ぼす。したがって、処理はステップS1306に移行する。ステップS1306で既知メンバ検出部522は、ステップS1305で見つかったエントリすなわち注目資源名のエントリのプロセス名に対応するPIDを、ステップS1303で取得したプロセス一覧507から抽出する。例えば、注目資源名がサウンドであり、資源プロセス名対応表520が図7の資源プロセス名対応表520aのとおりであり、ステップS1303で得られたプロセス一覧507が図7のプロセス一覧507aのとおりであるとする。すると、ステップS1305では、サウンドという注目資源名に対応する資源プロセス名対応表520aのエントリが見つかる。また、見つかったエントリのプロセス名はサウンドデーモンである。そして、プロセス一覧507aによれば、サウンドデーモンというプロセス名に対応するPIDは10である。よって、ステップS1306では10というPIDが抽出される。そして、次のステップS1307において既知メンバ検出部522は、ステップS1306で抽出したPIDをPIDリストに追加する。そして、処理はステップS1304に戻る。また、ステップS1308で既知メンバ検出部522は、プロセスグループ判定部501にPIDリストを返す。そして処理はステップS1301に戻る。なお、以上説明した13cの変形例において、プロセス制御モジュール503、依存関係管理部508、および、切り替えイベント通知部512を含むアプリケーション管理マネジャ511の動作は、第2実施形態と同じである。続いて、動的に子孫プロセスが生成され得る場合にも適切なプロセスグループの認識を可能とするための、13dの変形例について説明する。プロセスの中には、実行中に子プロセスを生成するものがある。よって、或るアプリケーションに関するプロセスグループに属する或るプロセスが、子プロセスを生成した場合、ユーザが感じる性能を向上させるには、プロセス制御モジュール503が子プロセスも親プロセスと同様に制御することが望ましい。つまり、子プロセスも同じプロセスグループに含まれるように、プロセスグループ判定部501がプロセスグループメンバ表502のデータを生成することが望ましい。そこで、13dの変形例では、親子関係判定部523が追加される。以下では、13dの変形についての理解の助けとするため、まずプロセスの親子関係について図23の例を参照して説明する。その後、図24を参照してプロセスグループ判定部501の動作を説明し、図25を参照して親子関係判定部523の動作を説明する。なお、プロセス制御モジュール503、依存関係管理部508、プローブ509、および、切り替えイベント通知部512を含む切り替えイベント通知部512の動作は、第2実施形態と同様である。図23は、プロセスの親子関係を示す樹形図の例である。図23の樹形図700における各ノードは、プロセスを表す。図23では、各ノードの中にプロセスIDPIDとプロセス名と親プロセスのPIDが示されている。樹形図700によれば、根ノードに相当するプロセスのプロセス名はinitである。initプロセスは、スマートフォン500aが起動されるときに最初に生成されるプロセスなので、PIDは1であり、親プロセスは存在しない。なお、initプロセスは、スマートフォン500aが起動している間は常に存在し続ける特殊なプロセスである。図23の例では、initプロセスは3つの子プロセスを有する。1つ目の子プロセスは、PIDが130でありプロセス名がF1である。また、2つ目の子プロセスは、PIDが150でありプロセス名がG1である。そして、3つ目の子プロセスは、PIDが210でありプロセス名がH1である。さらに、プロセスF1は、PIDが140でありプロセス名がF2の子プロセスを有する。また、プロセスG1は、PIDが160でありプロセス名がG2の子プロセスを有する。そして、プロセスG2は、PIDが170でありプロセス名がG3の子プロセスを有する。また、プロセスH1は、PIDが220でプロセス名がH2の子プロセスを有する。図23の例では、プロセスF1は、OSが提供するプログラムのプロセスであるものとする。したがって、子プロセスF2も、OSが提供するプログラムのプロセスである。例えば、子プロセスF2が、或るサービスを実質的に提供するプロセスであってもよい。そして、プロセスF1は、プロセスF2の状態を監視して管理するサービスマネジャのプロセスであってもよい。同様に、プロセスG1はサービスマネジャのプロセスであってもよく、プロセスG2はサービスのプロセスであってもよい。また、サービスの一部の機能が、プロセスG2の子プロセスG3によって提供されてもよい。また、或るアプリケーションパッケージHが含むバイナリプログラムの数が1つであり、プロセスH1は当該1つのバイナリプログラムの実行によって生成されたプロセスであるとする。そして、当該1つのバイナリプログラムは、子プロセスを生成するコードを含んでおり、その結果、プロセスH1がプロセスH2を生成したとする。さらに、アプリケーションパッケージHは、2つの特定資源を含む、2つ以上の資源を利用するものとする。そして、1つ目の特定資源へのアクセスは、プロセスF2のサービスによって提供されるものとし、2つ目の特定資源のアクセスは、プロセスG2のサービスによって提供されるものとする。すると、プロセスグループ判定部501が図11のフローチャートにしたがってプロセスグループを認識する場合、アプリケーションHに対応してプロセスグループメンバ表502に登録されるPIDリストは、210,140,160というリストである。しかし、アプリケーションHの機能の一部はプロセスH2により提供される。よって、プロセスグループ判定部501がプロセスH2はアプリケーションHのプロセスグループに属さないと判定して、プロセス制御モジュール503がプロセスH2の優先度を下げたり、またはプロセスH2を一時停止したりすることは、望ましくない。同様に、アプリケーションHから特定資源を利用するための機能の一部は、プロセスG3により提供されるので、プロセスG3はアプリケーションHのプロセスグループに属さないと判定されることも、望ましくない。換言すれば、アプリケーションHを利用するユーザが感じる性能を上げるためには、アプリケーションHのプロセスグループとして、プロセスH2とプロセスG3をも含むプロセスグループ701をプロセスグループ判定部501が認識することが望ましい。そこで、13dの変形例では親子関係判定部523が追加され、プロセスグループ判定部501による図11の処理は図24に示すように変形される。すなわち、13dの変形例では、図11のステップS406で未注目の利用資源名がなかった場合、ステップS412の通知の前に、プロセスグループ判定部501が図24のステップS1401~S1403の処理を行う。具体的には、ステップS1401でプロセスグループ判定部501は、起動したアプリケーションに対応づけて現在プロセスグループメンバ表502に記録してあるPIDのリストについて、子孫プロセスの調査を親子関係判定部523に要求する。例えば、図23の例では、ステップS1401の実行時には、プロセスグループメンバ表502において、アプリケーションHに対応するエントリのPIDリストには、210、140、および160という3つのPIDが含まれる。よって、ステップS1401でプロセスグループ判定部501は、210,140,160というPIDリストについての子孫プロセスの調査を親子関係判定部523に要求する。そして、次のステップS1402でプロセスグループ判定部501は、親子関係判定部523から返答が得られるまで待つ。親子関係判定部523からの返答が得られると、処理はステップS1403に移行する。なお、プロセスグループ判定部501が親子関係判定部523に引数として渡すPIDリストが示すプロセス集合をPとすると、ステップS1402では、集合P∪descendantPを表すPIDリストが返される。そして、ステップS1403でプロセスグループ判定部501は、親子関係判定部523から通知されたすべてのPIDを、起動したアプリケーションに対応づけてプロセスグループメンバ表502に記録する。換言すれば、プロセスグループ判定部501は、起動したアプリケーションに対応するプロセスグループメンバ表502のエントリのPIDリストを、親子関係判定部523から通知された結果で置き換える。例えば、図23の例では、親子関係判定部523からプロセスグループ701を示すPIDのリスト210,220,140,160,170が、プロセスグループメンバ表502においてアプリケーションHに対応するエントリに記録される。そして、処理はステップS412に移行する。なお、図示は省略したが、13dの変形例においてプロセスグループ判定部501はさらに、以下のような処理も行う。以下の処理を行う理由は、任意のタイミングで子プロセスが生成され得るからである。すなわち、プロセスグループ判定部501は、適宜の間隔で定期的に、現在フォアグラウンドで実行中のアプリケーションに対応するプロセスグループメンバ表502のエントリからPIDリストを読み取る。そして、プロセスグループ判定部501は、読み取ったPIDリストに関して、図24のステップS1401と同様にして子孫プロセスの調査を親子関係判定部523に要求する。さらに、プロセスグループ判定部501は、現在フォアグラウンドで実行中のアプリケーションに対応するプロセスグループメンバ表502のエントリのPIDリストを、親子関係判定部523から通知された結果に置き換える。そして、プロセスグループ判定部501は、ステップS412と同様にプロセスグループメンバ表502の更新をプロセス制御モジュール503に通知する。プロセス制御モジュール503は、プロセスグループ判定部501からの通知を契機として、図12~13のステップS507~S513の処理を行う。さて、図25は、13dの変形例において親子関係判定部523が行う処理のフローチャートである。図25の処理は、スマートフォン500aが起動されると開始される。ステップS1501で親子関係判定部523は、プロセスグループ判定部501からの指示を待つ。指示がない間、親子関係判定部523はステップS1501で待機する。プロセスグループ判定部501からの指示すなわち図24のステップS1401での指示を親子関係判定部523が受け取ると、処理はステップS1502に移行する。ステップS1502で親子関係判定部523は、例えばpsコマンドを用いることにより、プロセス一覧507を取得する。なお、13dの変形例におけるプロセス一覧507は、PIDとプロセス名だけでなく、親プロセスのPIDすなわちPPIDParentProcessIdentifierを含む。そして、次のステップS1503で親子関係判定部523は、取得したプロセス一覧507中のPPIDに基づき、動作中の全プロセスすなわちプロセス一覧507に含まれる全プロセスの親子関係を示す樹形図を作成する。なお、図23では理解の助けとするために、樹形図700中の各ノードに、PIDだけでなくプロセス名とPPIDも示してあるが、ステップS1503で親子関係判定部523が作成する樹形図は、少なくとも各ノードがPIDを含んでいればよい。また、親子関係判定部523がステップS1503で作成するデータは、樹形図を表すことができるデータであれば、具体的なデータ構造は任意である。例えば、ポインタを用いたツリー構造のデータが使われてもよいし、配列が使われてもよい。さらに、次のステップS1504で親子関係判定部523は、プロセスグループ判定部501からの調査指示に含まれる各PIDを、樹形図中から検索する。そして、次のステップS1505で親子関係判定部523は、ステップS1504の検索の結果発見されたいずれかのPIDのノードを根とするサブツリーに含まれるPIDのリストを作成する。続いて、ステップS1506で親子関係判定部523は、ステップS1505で作成したPIDのリストをプロセスグループ判定部501に返す。そして、処理はステップS1501に戻る。例えば、ステップS1503で作成された樹形図が図23の樹形図700のとおりであり、プロセスグループ判定部501からの調査指示には210、140、および160という3つのPIDが含まれるとする。この場合、ステップS1504において親子関係判定部523は、樹形図700の中から、PIDが210、140、および160のプロセスのノードを検索する。すると、ステップS1505において親子関係判定部523が作成するリストには、以下の16a~16cのいずれかのサブツリーに含まれるという条件を満たすすべてのノードのPIDが含まれる。つまり、ステップS1505において親子関係判定部523は、210、220、140、160、および170という5つのPIDを含むリストを作成する。16aPIDが210のプロセスのノードを根とするサブツリー。すなわち、PIDが210のプロセスH1のノードと、PIDが220のプロセスH2のノードを含むサブツリー。16bPIDが140のプロセスのノードを根とするサブツリー。すなわち、PIDが140のプロセスF2のノードのみを含むサブツリー。16cPIDが160のプロセスのノードを根とするサブツリー。すなわち、PIDが160のプロセスG2のノードと、PIDが170のプロセスG3のノードを含むサブツリー。続いて、プロセス制御モジュール503が一時停止制御を行う場合に、一時停止にともなう副作用を回避するための、13eの変形例について説明する。13eの変形例では、プロセス制御モジュール503が競合判定部524を含むように変形される。しかし、プロセスグループ判定部501、依存関係管理部508、プローブ509、およびアプリケーション管理マネジャ511の動作は第2実施形態と同様である。具体的には、13eの変形例では、プロセス制御モジュール503による図12~13の処理が図26のように変形される。すなわち、図13のステップS515とS516の間に図26のステップS1601が追加される。また、処理がステップS516から図12のステップS502に戻る際に、ステップS516とステップS502の間に図26のステップS1601~S1604が追加される。ステップS1601でプロセス制御モジュール503内の競合判定部524は、以下の17aと17bの条件をともに満たすプロセス以下確保中プロセスというの集合を認識する。確保中プロセスは、新たにフォアグラウンドになったアプリケーションとの間で資源の競合を生じる他のアプリケーションのプロセスである。17a新たにフォアグラウンドになったアプリケーションが使ういずれかの資源を確保中である17bフォアグラウンドプロセスグループには属さない具体的には、競合判定部524は、新たにフォアグラウンドになったアプリケーションが使う資源を、パッケージ情報DB506を参照することで認識する。また、競合判定部524は、認識した各資源に対応する資源ファイル名を、資源ファイル対応表504を参照することで認識する。そして、競合判定部524は、認識した各資源ファイル名で識別される資源ファイルを現在オープンしているプロセスがあるか否かを、資源依存関係表505を参照することで認識する。また、もし、競合判定部524が認識した資源ファイル名で識別される資源ファイルを現在オープンしているプロセスがあれば、競合判定部524は、当該プロセスのPIDも、資源依存関係表505から読み取る。以上のようにして、競合判定部524は、17aの条件を満たすプロセスのPIDの集合を得る。また、プロセス制御モジュール503は、既にステップS508でフォアグラウンドプロセスグループを認識しており、プロセス制御モジュール503に含まれる競合判定部524は、プロセス制御モジュール503による認識結果を参照することができる。したがって、ステップS1601で競合判定部524は、確保中プロセスの集合を表すPIDのリストを取得することができる。例えば、起動したアプリケーションがGPS受信機601を利用するとする。また、GPS受信機601は、特定資源ではないものとする。つまり、GPS受信機601は、ロケーションマネジャ613を介さずにアプリケーションから直接アクセス可能な資源である。また、ロケーションマネジャ613はGPS受信機601を独占しない。さらに、GPS受信機601の資源ファイル609を、他のアプリケーション例えば、以前に起動され、現在バックグラウンドで実行中か、または一時停止中のアプリケーションのプロセスが現在オープンしているとする。すると、ステップS1601では、資源ファイル609をオープンしているプロセスのPIDが、確保中プロセスのPIDとして得られる。さて、以上のようにして競合判定部524により認識された確保中プロセスの集合は、プロセス制御モジュール503からも参照可能であるものとする。また、競合判定部524によるステップS1601の実行後、プロセス制御モジュール503は、図13と同様にステップS516~S517の繰り返しループ処理を行う。そして、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないすべてのプロセスにプロセス制御モジュール503が注目し終わると、処理はステップS1602に移行する。そして、ステップS1602でプロセス制御モジュール503は、ステップS1601で認識した確保中プロセスの集合の中に、ステップS1603~S1604の処理対象としてまだ注目していないプロセスが残っているか否かを判断する。確保中プロセスの集合の中に未注目のプロセスがまだ残っている場合、処理はステップS1603に移行する。逆に、すべての確保中プロセスに既にプロセス制御モジュール503が注目し終えていれば、符号Iに示すように、処理は図12のステップS502に戻る。また、ステップS1601で認識された確保中プロセスの集合がそもそも空である場合も、処理はステップS502に戻る。そして、ステップS1603でプロセス制御モジュール503は、次の確保中プロセスに注目し、注目した確保中プロセスが一時停止中か否かを判断する。図7のプロセス一覧507aの例では省略されているが、プロセス一覧507は、各プロセスの状態を示す項目を含んでいてもよい。よって、プロセス制御モジュール503は、プロセス一覧507を参照することで、注目した確保中プロセスが一時停止中か否かを判断することができる。そして、注目した確保中プロセスが一時停止中の場合、処理はステップS1604に移行する。逆に、注目した確保中プロセスが一時停止中ではない場合つまりバックグラウンドで実行中の場合、処理はステップS1602に戻る。そして、ステップS1604でプロセス制御モジュール503は、ステップS1603で注目した確保中プロセスを再開する。ステップS1604の処理は、図14のステップS603と同様に、シグナルの送信により実現されてもよい。また、ステップS1604の実行後、処理はステップS1602に戻る。さて、13eの変形例では、プロセス制御モジュール503による図14の処理も、図27に示すように変形される。第2実施形態の図14のステップS601では、引数で指定された操作の種類が一時停止の場合も再開の場合も、処理がステップS603へと移行する。それに対して、13eの変形例では、一時停止の場合は処理がステップS601からステップS1701へと移行し、再開の場合は図14と同様に処理がステップS601からステップS603へと移行する。そして、ステップS1701でプロセス制御モジュール503は、図14のステップS605やS607と同様に、引数のリトライフラグを参照することで、今回のサブルーチンコールがリトライのための呼び出しなのか否かを判断する。リトライのための呼び出しの場合、プロセス制御モジュール503は単に引数で指定されたとおりにプロセスを制御すればよいので、処理はステップS603に移行する。逆に、今回が初めての試みの場合、処理はステップS1702に移行する。そして、ステップS1702でプロセス制御モジュール503は、引数で指定されたプロセスが確保中プロセスの集合に属するか否かを判断する。なお、ステップS1702の処理が実行されるのは、図26のステップS517からのサブルーチンコールの場合のみである。よって、既に競合判定部524により確保中プロセスの集合は認識されており、プロセス制御モジュール503はステップS1702において確保中プロセスの集合を参照することができる。引数で指定されたプロセスが確保中プロセスの集合に属する場合、仮に、引数で指定されたプロセスをプロセス制御モジュール503が一時停止してしまうと、新たにフォアグラウンドになったアプリケーションの利用する資源が解放されなくなってしまう。そこで、引数で指定されたプロセスが確保中プロセスの集合に属する場合は、引数で指定されたプロセスの実行を継続させるため、プロセス制御モジュール503は、引数で指定されたプロセスに対する積極的な一時停止制御を行わずに、図27の処理を終える。逆に、引数で指定されたプロセスが確保中プロセスの集合に属さない場合は、処理はステップS603に移行する。以上の図26~27に示した変形により、プロセス制御モジュール503は、実行中の確保中プロセスについては、一時停止を避けて実行を継続させるとともに、一時停止中の確保中プロセスを再開させる。その結果、どの確保中プロセスも実行される。したがって、時間の経過にともない、確保中プロセスは、確保している資源をいずれ解放すると期待される。その結果、新たにフォアグラウンドになったアプリケーションのプロセスは、解放された資源を利用することが可能となる。以上説明した13eの変形例によれば、利用する資源が競合するアプリケーションがあっても、プロセス制御モジュール503による制御による副作用が避けられる。例えば、アプリケーションIがフォアグラウンドで実行されているときに、アプリケーションIのプロセスが或る資源例えば加速度センサ602をオープンして確保していたとする。そして、アプリケーションIのプロセスが加速度センサ602を解放する前に、フォアグラウンドアプリケーションが、アプリケーションIから、加速度センサ602を利用しないアプリケーションJへと切り替えられたとする。すると、プロセス制御モジュール503が図26のステップS515で一時停止操作を選択する場合、切り替えにともなって、アプリケーションIのプロセスは一時停止される。その後、さらにフォアグラウンドアプリケーションがアプリケーションJからアプリケーションKへと切り替えられ、アプリケーションKは加速度センサ602を利用するものとする。すると、アプリケーションKが起動された時点で、加速度センサ602は一時停止中のアプリケーションIのプロセスにより確保されている。しかし、上述の13eの変形例によれば、アプリケーションIのプロセスがステップS1601で確保中プロセスとして認識され、ステップS1604で再開される。よって、加速度センサ602はいずれ解放される。すなわち、加速度センサ602を確保しているプロセスが一時停止中のため、加速度センサ602が解放されず、アプリケーションKが加速度センサ602を利用することができないといった事態が回避される。また、アプリケーションIのプロセスが加速度センサ602を解放する前に、フォアグラウンドアプリケーションが、アプリケーションIからアプリケーションKへと切り替えられた場合も、上述の13eの変形例によれば、副作用が避けられる。なぜなら、たとえプロセス制御モジュール503が図26のステップS515で一時停止操作を選択しても、図27のステップS1702の判断に基づき、アプリケーションIのプロセスは一時停止されないからである。なお、13eの変形例は、さらに次のように変形されてもよい。依存関係管理部508は、図10のステップS304において、さらに、資源ファイル516をクローズしたプロセスのPIDと、クローズされた資源ファイル516の名前のペアを競合判定部524に通知してもよい。また、競合判定部524は、確保中プロセスを上記のようにPIDの集合を用いて管理する代わりに、PIDと資源ファイル名のペアの集合を用いて管理してもよい。以下では説明の便宜上、PIDと資源ファイル名のペアを要素として含むリストである確保中プロセスリストが、確保中プロセスの管理用に使われるものとする。競合判定部524は、依存関係管理部508から通知を受けると、通知されたペアが確保中プロセスリストに含まれ、かつ、通知されたペアのPIDと同じPIDを含む他のペアは確保中プロセスリストに存在しないという条件が成立するか否かを判断する。そして、当該条件が成立する場合、競合判定部524は、依存関係管理部508から通知されたペアのPIDを、一時停止制御の対象としてプロセス制御モジュール503に通知する。また、競合判定部524は、依存関係管理部508から通知されたペアを確保中プロセスリストから削除する。プロセス制御モジュール503は、以上のようにして競合判定部524から通知を受けると、競合判定部524から通知されたPIDのプロセスに対して、例えば図14と同様にして、一時停止を試みる。なお、リトライフラグは、初めての試みを示す値に設定される。以上のように13eの変形例をさらに変形することにより、一時停止制御の副作用を防ぐ目的で例外的に一時停止を免除されていたプロセスは、資源の解放を契機として、一時停止される。その結果、フォアグラウンドプロセスグループに属するプロセスのために、より多くのCPU時間とより多くのメモリが利用可能となる。よって、ユーザが感じる性能も、さらに向上すると期待される。続いて、メモリ不足の解消のため、プロセスグループを利用した強制終了制御が行われる13fの変形例について説明する。図16に関して説明したとおり、13fの変形例ではメモリ管理モジュール525が追加される。図28は、13fの変形例におけるメモリ管理モジュール525の詳細を示すブロック構成図である。図28には、図16のスマートフォン500aのうちの一部もあわせて図示されている。メモリ管理モジュール525は、OSのカーネル513内に設けられる。メモリ管理モジュール525は、強制終了するプロセス517を選択するプロセス選択部526と、プロセス選択部526が選択したプロセス517を強制終了させるプロセス強制終了部527を含む。また、メモリ管理モジュール525は、プロセスグループメンバ表502のキャッシュ528と、アプリケーション利用時刻表529と、強制終了除外プロセスリスト530を保持する。プロセスグループメンバ表502は、カーネル513外のプロセスグループ判定部501により作成されるデータなので、ユーザメモリ空間内にある。他方、キャッシュ528は、カーネルメモリ空間内にある。プロセスグループメンバ表502とキャッシュ528のデータの内容は同じである。なお、OSのアーキテクチャによっては、カーネル513の内部とカーネル513の外部の双方からアクセス可能なメモリ空間があってもよい。そのようなメモリ空間がある場合、キャッシュ528は省略可能である。また、アプリケーション利用時刻表529は、アプリケーション管理マネジャ511内の切り替えイベント通知部512からカーネル513への通知にともなって、メモリ管理モジュール525により更新される。アプリケーション利用時刻表529には、起動中の各アプリケーションについて、アプリケーション名と時刻を対応づける情報が記録される。アプリケーション利用時刻表529の具体例は、図7のアプリケーション利用時刻表529aである。アプリケーション利用時刻表529aの各エントリは、スマートフォン500aにおいて起動された状態にある各アプリケーションに対応する。つまり、各エントリは、現在フォアグラウンドもしくはバックグラウンドで実行中か、一時停止中のアプリケーションに対応する。アプリケーション利用時刻表529aには、既に終了したアプリケーションに対応するエントリは含まれない。アプリケーション利用時刻表529aの各エントリは、アプリケーションを識別するアプリケーション名フィールドと、当該アプリケーションが直近にフォアグラウンドになった時刻を示す前回利用時刻フィールドを含む。なお、アプリケーションがフォアグラウンドになった時刻とは、18a~18cのいずれかである。したがって、アプリケーション利用時刻表529aの前回利用時刻は、18a~18cのいずれかのうち直近の時刻である。18aアプリケーションが新たに起動された時刻18bバックグラウンドのアプリケーションがフォアグラウンドに遷移した時刻18c一時停止中のアプリケーションが再開されてフォアグラウンドで実行され始めた時刻図7のアプリケーション利用時刻表529aは、以下の19a~19cを表す。19aアプリケーションDが直近にフォアグラウンドになった時刻はTDである。19bアプリケーションEが直近にフォアグラウンドになった時刻はTEである。19c現在スマートフォン500a上では、他のアプリケーションは起動されていない。なお、13fの変形例では、アプリケーション管理マネジャ511内の切り替えイベント通知部512が、図8のステップS104において、さらにメモリ管理モジュール525にもアプリケーションの切り替えの発生を通知する。そして、通知を受けたメモリ管理モジュール525は、以下のように動作する。アプリケーションが終了した場合、メモリ管理モジュール525は、終了したアプリケーションに対応するエントリをアプリケーション利用時刻表529から削除する。逆に、新たにアプリケーションが起動した場合、メモリ管理モジュール525は、新たに起動したアプリケーションの名前と現在時刻を対応づける新たなエントリを、アプリケーション利用時刻表529に追加する。また、バックグラウンドで実行中のアプリケーションがフォアグラウンドに遷移した場合、または、一時停止中のアプリケーションが再開されてフォアグラウンドで実行される場合、メモリ管理モジュール525は次のように動作する。すなわち、メモリ管理モジュール525は、当該アプリケーションに対応するアプリケーション利用時刻表529中のエントリを検索し、見つかったエントリの前回利用時刻フィールドに現在時刻を設定する。さて、図28の強制終了除外プロセスリスト530は、予め静的に決められたデータであり、強制終了の対象から除外されるプロセスの名前のリストである。例えば、OSが標準的に提供するサービスなどの名前が、強制終了除外プロセスリスト530には含まれる。強制終了除外プロセスリスト530の具体例は、図7の強制終了除外プロセスリスト530aである。強制終了除外プロセスリスト530aによれば、initプロセスは強制終了の対象から除外される。また、強制終了除外プロセスリスト530aによれば、OSにより提供されるサービスのうち、サウンドデーモン614、ウィンドウシステム615、およびアプリケーション管理マネジャ616それぞれのプロセスも、強制終了の対象から除外される。しかし、強制終了除外プロセスリスト530aの例によれば、OSにより提供されるサービスのうちロケーションマネジャ613とインストーラ617は、強制終了の対象から除外されず、場合によっては強制終了され得る。また、図7には不図示の他のプロセスがさらに強制終了除外プロセスリスト530に含まれていていてもよい。例えば、実施形態によっては、ロケーションマネジャ613やインストーラ617のプロセス名が、さらに強制終了除外プロセスリスト530に含まれていてもよい。また、OSが提供するサービスの中には、アプリケーションには開放されていない、OS自体のみが使うためのサービスもある。例えば、ディスク装置に書き出すデータをメモリ上にキャッシュし、ディスク装置への実際の書き出しを遅延させ、適宜のタイミングでディスク装置への実際の書き出しを行うサービスは、OS内部で利用されるだけである。例えば以上のような、OS自体が利用するためのサービスの名前も、強制終了除外プロセスリスト530に含まれる。さて、図29は、13fの変形例においてメモリ管理モジュール525が行う処理のフローチャートである。図29の処理は、下記の20aかつ20bの場合に開始される。20aカーネル513外のプロセスから、例えば標準ライブラリを介して、メモリ確保のためのシステムコールが呼び出された。20bユーザメモリ空間内で確保可能なメモリ容量が、要求されたメモリの量に満たない。以下、図29の処理の流れを説明した後、図7の具体例に沿って図29の各ステップの詳細について補足説明する。ステップS1801でプロセス選択部526は、アプリケーション利用時刻表529を読み取る。そして次のステップS1802でプロセス選択部526は、読み取ったアプリケーション利用時刻表529のエントリ数が0か否かを判断する。エントリ数が0の場合、すなわち、現在起動されているアプリケーションが存在しない場合、処理はステップS1803に移行する。逆に、エントリ数が1以上の場合、すなわち、1つ以上のアプリケーションが起動されている状態の場合、処理はステップS1808に移行する。ステップS1803でプロセス選択部526は、プロセス一覧507すなわち、動作中のすべてのプロセスの一覧を取得する。また、次のステップS1804でプロセス選択部526は、強制終了除外プロセスリスト530を読み取る。そして、次のステップS1805でプロセス選択部526は、ステップS1803で取得したプロセス一覧507のプロセス集合と、ステップS1804で読み取った強制終了除外プロセスリスト530のプロセス集合に差があるか否かを判断する。なお、強制終了除外プロセスリスト530のプロセス集合は、プロセス一覧507のプロセス集合の部分集合である。2つの集合に差がない場合、処理はステップS1806に移行する。逆に、2つの集合に差がある場合、すなわち、強制終了除外プロセスリスト530に含まれないプロセスがプロセス一覧507に含まれる場合、処理はステップS1807に移行する。ステップS1806が実行されるのは、強制終了除外プロセスリスト530に含まれる最低限のプロセスしか動作していないにも関わらず、メモリが不足しているという予期せぬエラーが発生した例外的ケースである。したがって、ステップS1806でプロセス選択部526は、個別のプロセスを強制終了するのではなくスマートフォン500aのシステム全体を再起動するすなわちOSを再起動することに決める。そして、プロセス選択部526はOSを再起動する。あるいは、プロセス選択部526は、カーネル513内の不図示の他のモジュールに対してOSの再起動を指示することにより、間接的にOSを再起動してもよい。再起動のための適宜の処理の実行後、図29の処理は終了し、OSが再起動する。また、ステップS1807でプロセス選択部526は、ステップS1805で判明した差分に含まれるプロセスのうち1つをランダムに選択し、選択したプロセスのPIDをプロセス強制終了部527に通知する。すると、プロセス強制終了部527は、通知されたPIDのプロセスを強制終了する。例えば、プロセス強制終了部527は、強制終了のためのシグナルを、通知されたPIDのプロセスに対して送信することで、プロセスを強制終了する。そして、処理はステップS1814に移行する。さて、ステップS1808が実行されるのは、1つ以上のアプリケーションが実行中の場合である。そこで、プロセス選択部526は、ステップS1801でアプリケーション利用時刻表529から読み取った内容から、最後にフォアグラウンドになってからの経過時間が最も長いアプリケーションを選択する。換言すれば、プロセス選択部526は、アプリケーション利用時刻表529のエントリの中で前回利用時刻が最も古いエントリのアプリケーションを選択する。そして、次のステップS1809でプロセス選択部526は、プロセスグループメンバ表502を読み、ステップS1808で選択したアプリケーションのプロセスグループを認識する。また、次のステップS1810でプロセス選択部526は、強制終了除外プロセスリスト530を読み取る。そして、次のステップS1811でプロセス選択部526は、ステップS1809で認識したプロセスグループから、強制終了除外プロセスリスト530で指定されているプロセス集合に属するプロセスを除き、除いた結果をプロセス強制終了部527に通知する。次に、ステップS1812でプロセス強制終了部527は、除かれずに残っているプロセスすなわち、ステップS1811でプロセス選択部526から通知されたプロセスをすべて強制終了する。そして、ステップS1813でメモリ管理モジュール525は、アプリケーション利用時刻表529から、強制終了されたアプリケーションすなわちステップS1808で選択されたアプリケーションのエントリを消去する。消去の後、処理はステップS1814に移行する。ステップS1814においてメモリ管理モジュール525は、メモリ残量より具体的には、ユーザメモリ空間で新たな割り当てが可能な容量が基準以上か否かを判断する。そして、メモリ残量が基準以上であれば、図29の処理は終了する。逆に、メモリ残量が基準未満であれば、処理はステップS1801に戻る。なお、ステップS1814における基準は、例えば、第1実施形態に関して説明した6a~6dの基準のうち1つ以上の適宜の組み合わせであってよい。また、以上説明したステップS1808~S1813の具体例を、図7を参照しながら説明すれば以下のとおりである。図7のアプリケーション利用時刻表529aのエントリ数は2なので、処理はステップS1802からステップS1808に移行する。ここで、説明の便宜上、時刻TEの方が時刻TDよりも古いとする。すると、ステップS1808でプロセス選択部526はアプリケーションEを選択する。また、プロセスグループメンバ表502aによれば、アプリケーションEのプロセスグループは3つのプロセスを含み、それら3つのプロセスのPIDは10と1002と1012である。したがって、ステップS1809でプロセス選択部526は、これら3つのプロセスを含むプロセスプロセスグループを認識する。続いて、プロセス選択部526は、ステップS1810で強制終了除外プロセスリスト530aを読み取り、さらに、プロセス一覧507を取得する。そして、プロセス選択部526は、プロセス一覧507を参照することで、強制終了除外プロセスリスト530aにプロセス名が含まれる各プロセスのPIDを認識する。図7の例によれば、プロセス選択部526は、ステップS1810で除外対象のプロセスのPIDとして、1、10、20、および30というPIDを認識する。その結果、プロセス選択部526は、ステップS1809で認識したプロセスグループから、除外対象の10というPIDを除外する。そして、残った1002と1012というPIDをそれぞれ有する2つのプロセスを、ステップS1812でプロセス強制終了部527が強制終了する。そして、ステップS1813でメモリ管理モジュール525は、アプリケーションEのエントリをアプリケーション利用時刻表529aから削除する。なお、複数のアプリケーションが同じ特定資源例えばサウンドデバイス603を利用する場合、特定プロセス例えばサウンドデーモン614のプロセスが、両方のアプリケーションのプロセスグループにともに含まれる。すると、ステップS1809で認識されたプロセスグループの中に、現在フォアグラウンドで実行中のアプリケーションのプロセスグループに属する特定プロセスが含まれることもあり得る。しかし、この特定プロセスを強制終了することは好ましくない。そこで、フォアグラウンドで実行されているアプリケーションのプロセスグループに含まれる特定プロセスの強制終了を防ぐには、例えば、次の第1の手法または第2の手法が採られてもよい。第1の手法は、特定資源を独占して特定資源へのアクセスを提供する特定プロセスのプロセス名が、必ず強制終了除外プロセスリスト530に含まれるように、強制終了除外プロセスリスト530を予め定義しておく手法である。第2の手法は、アプリケーション利用時刻表529のエントリ数が2以上の場合にプロセス選択部526が次のように動作する手法である。プロセス選択部526は、ステップS1808でさらに、経過時間が最も短いアプリケーションすなわちフォアグラウンドで現在実行中のアプリケーションを認識する。そして、プロセス選択部526は、ステップS1809でさらに、フォアグラウンドで実行中のアプリケーションのプロセスグループ便宜上、フォアグラウンドプロセスグループというを認識する。また、プロセス選択部526は、ステップS1811でさらに、フォアグラウンドプロセスグループに属するプロセスも、強制終了の対象から除外する。第1の手法は、各々が特定資源を独占して特定資源へのアクセスを提供する特定プロセスが複数存在する場合に、一律にすべての特定プロセスを強制終了の対象から除外する手法である。それに対して、第2の手法は、複数の特定プロセスがある場合に、フォアグラウンドで実行中のアプリケーションとは無関係な特定プロセスを強制終了させることができる。そして、そのぶんだけ、第1の手法よりも割り当て可能なメモリの量を増やすことができる。続いて、プローブ509の実装に関する13gの変形例について説明する。図5と16のいずれにおいても、プローブ509はカーネル513の一部である。カーネル513がプローブ509を含む実施形態には、プローブ509によるシステムコールの監視のオーバヘッドが少ないという利点がある。しかし、必ずしもカーネル513がプローブ509を含まなくてもよい。プローブ509は、システムコールの呼び出しを検出することさえできれば、カーネル513の外部に実装されていてもよい。例えば、システムの性能情報取得などを目的としたカーネルインタフェイスとして、システムコールのフックが予め用意されている場合がある。フックを利用すれば、システムコールが呼ばれたときにユーザ空間内のプログラムを呼び出すことが可能である。よって、プローブ509のプログラムは、ユーザ空間内のプログラムであってもよい。または、OSによって提供される基本ライブラリ内にプローブ509のモジュールが追加されてもよい。次に、プロセス制御モジュール503による保留プロセスリストを用いる制御に関する13hの変形例について説明する。13hの変形例では、保留プロセスリストに含まれるプロセスに対する操作の再失敗を防ぐための仕組みが導入される。図14、15、または27のようなプロセス制御モジュール503によるプロセスに対する操作が失敗し得るのは、例えば、操作対象のプロセスが何らかのシステムコールを実行中の場合である。そこで、操作対象のプロセスからのシステムコールを抑制することによってプロセス制御モジュール503による操作の再失敗を防ぐような仕組みが導入されてもよい。例えば、カーネル513または基本ライブラリに、システムコールの実行を抑制する対象のプロセスを外部から指定するためのインタフェイスが追加されてもよい。プロセス制御モジュール503は、保留プロセスリストにPIDと操作内容のペアを追加するときに、上記の追加されたインタフェイスに対して、当該PIDを指定する。すると、たとえ保留プロセスリストにPIDが含まれるプロセスがシステムコールを呼び出しても、呼び出しはすぐにカーネル513によって拒絶され、システムコールは実行されない。よって、プロセス制御モジュール503が保留プロセスリストにしたがってリトライ処理を行う際の、操作の成功率が高まる。また、プロセス制御モジュール503によるプロセスに対する操作は、操作対象のプロセスが何らかの資源を確保している場合にも失敗することがある。そこで、プロセス制御モジュール503は、プロセスに強制的に資源を解放させることで、操作の再失敗を防いでもよい。例えば、保留プロセスリストの各要素が、PIDと操作内容だけでなくリトライ回数も含むように変形されてもよい。そして、プロセス制御モジュール503は、所定回数のリトライを繰り返してもなお資源を確保しているプロセスに対して、次回のリトライを成功させるため、資源の解放を強制してもよい。続いて、以上説明した第2実施形態と13a~13hの変形例と、図1の第1実施形態について比較する。図1の使用資源情報111は、例えば、図6の依存関係情報618から抽出されてパッケージ情報DB606つまり図5のパッケージ情報DB506に格納された情報に対応する。また、図1の対応づけ情報112は、例えば、図7の資源プロセス名対応表520aのように資源名とプロセス名を直接対応づける情報を含んでもよい。対応づけ情報112は、プロセス一覧507aのようにプロセス名とPIDを対応づける情報と、資源ファイル対応表504aのように論理的な資源名と物理的な資源ファイル名を対応づける情報の、一方または双方を、さらに含んでもよい。あるいは、図1の対応づけ情報112は、図7の資源ファイル対応表504aのように、特定資源と他の資源を区別するフラグと、特定資源を識別する情報としての資源ファイル名とを対応づける情報を含んでもよい。そして、対応づけ情報112は、さらに資源依存関係表505aのように資源ファイル名とPIDを対応づける情報を含んでもよい。すると、資源ファイル名を介して、特定資源と特定プロセスのPIDが対応づけ情報112において対応づけられる。もちろん、資源ファイル対応表504aの代わりに資源依存関係表505aにフラグフィールドが設けられていてもよい。あるいは、資源ファイル対応表504aと資源依存関係表505aが、1つのテーブルにまとめられていてもよい。また、図1の構成情報113は、例えば、図6の構成情報619から抽出されてパッケージ情報DB606つまり図5のパッケージ情報DB506に格納された情報に対応する。そして、図1の認識部103による認識結果114は、プロセスグループメンバ表502に対応する。すなわち、プロセスグループを認識する認識部103は、プロセスグループ判定部501に対応する。そして、図1においてプロセスを制御する制御部105は、プロセス制御モジュール503、メモリ管理モジュール525、またはその組み合わせに対応する。また、入力部106は入力部510に対応し、資源監視部107はプローブ509と依存関係管理部508の組み合わせに対応する。そして、メモリ監視部108はメモリ管理モジュール525に対応する。ところで、第2実施形態と13a~13hの変形例には、以下のように様々な利点がある。プロセスグループ判定部501によって判定されるプロセスグループが、プロセス制御モジュール503による制御の単位として好適であることは上述したとおりである。そして、好適なプロセスグループを利用することにより、ユーザが感じる性能を上げることができるのも、上述したとおりである。さらに、プロセス制御モジュール503が一時停止制御を行う場合、第2実施形態と13a~13hの変形例には、消費電力を低減する効果もある。また、上記のとおり、プロセスグループの認識と、プロセスグループに基づくプロセスの制御は、自動的に行われる。また、予めスマートフォン500のOSまたはアプリケーションの設計者等がチューニングを行う必要はない。例えば、資源ファイル対応表504は、予め作られる情報だが、設計者が特に資源ファイル対応表504をチューニングする必要はない。資源ファイル対応表504は、スマートフォン500のハードウェア構成とOSの仕様から単純に定義することができる。また、実施形態によっては監視対象資源ファイルリスト518が予め作られることもあるが、その場合でも、監視対象資源ファイルリスト518は、スマートフォン500のハードウェア構成とOSの仕様から単純に定義することができる。同様に、実施形態によっては、強制終了除外プロセスリスト530が予め作られることもあるが、強制終了除外プロセスリスト530もOSの仕様から単純に定義することができる。また、パッケージ情報DB506は、インストーラ617によって自動的に作成される既存のDBであってもよいし、既存のDBに含まれる情報の一部を抽出した別のDBであってもよい。いずれにしろ、パッケージ情報DB506の各エントリは、アプリケーションパッケージに含まれる既存の情報から抽出されるので、パッケージ情報DB506を作成するためにアプリケーション開発者に新たなデータ作成の手間をかけさせるようなことにはならない。また、例えば産業用ロボットの制御用のコンピュータなど、限られたアプリケーションしかインストールされない環境では、限られたアプリケーションに関する知識に基づいてチューニングされた方針にしたがって、プロセスグループが管理されることがある。しかし、スマートフォン500のように任意のアプリケーションがインストールされ得る環境では、そのようなチューニングは現実的ではなく、困難である。例えば、一般のユーザはチューニングをするのに十分な知識を持たない。また、専門家たるアプリケーション開発者といえども、同じスマートフォン500にインストールされ得る非常に多数の他のアプリケーションについて十分な知識を持つとは限らない。第2実施形態とその変形例によれば、困難なチューニングをせずとも、スマートフォン500のハードウェア構成とOSの仕様から単純に定義することのできる設定ファイルを利用することで、自動的に適切なプロセスグループによる制御が行われる。プロセスグループ管理のためのチューニングが不要なことは非常に大きな利点である。また、アプリケーション開発者は、他のアプリケーションを考慮したチューニングを行う必要がないので、アプリケーション開発の自由度も高まると期待される。さらに、第2実施形態とその変形例によれば、プロセスグループの認識のために使われる情報は、予め決められた情報か、ある特定のイベントが発生したときに取得される情報である。換言すれば、リアルタイムにプロセスの振る舞いすべてをトレースする仕組みがなくても、第2実施形態とその変形例によれば、適切なプロセスグループが認識される。リアルタイムのトレースは負荷が非常に大きく、ユーザに性能低下を感じさせてしまう要因なので、リアルタイムのトレースが不要なことは大きな利点である。例えば、プローブ509はシステムコールを監視するが、プロセスの振る舞いすべてをトレースするのに比べれば、プローブ509の負荷は遥かに小さい。また、プローブ509の監視対象は限定されているので、その分、負荷も小さい。さらに、13b、13c、またはその双方の変形を組み合わせることで、プローブ509の負荷はさらに軽減される。また、或る種のOSでは、資源の獲得を待つためのキューを参照することで、プロセス間の資源の競合を検出可能である。例えば、第1のプロセスが資源の獲得を要求したときに第2のプロセスが既に当該資源を利用中であれば、第1のプロセスはキューに登録され、資源が解放されるまで待つ。しかし、スマートフォン、タブレット端末、PCなどで一般的なOSにはそのようなキューがない。そのため、第1のプロセスが資源の獲得を要求したときに第2のプロセスが既に当該資源を利用中であれば、すぐに要求に対して単に獲得失敗という結果が返されるだけである。よって、スマートフォン、タブレット端末、PCなどで一般的なOS上では、キューに基づいて資源の競合を検出することはできない。しかし、第2実施形態とその変形例によれば、プローブ509からの通知に基づいて依存関係管理部508が書き換える資源依存関係表505により、どのプロセスがどの資源ファイルを現在オープンしているかが判明する。また、どのアプリケーションのプロセスがどの資源を利用する可能性があるかということがパッケージ情報DB506から判明する。よって、資源獲得待ちのためのキューを備えないOSが使われる環境でも、資源の競合が検出可能であり、検出結果に応じた適宜の制御が可能である。特に、プロセス制御モジュール503が競合判定部524を含む13eの変形例によれば、他のアプリケーションのプロセスが資源を確保したまま一時停止することによる副作用を回避することができる。さらに、13fの変形例において、メモリが不足したときに強制終了するプロセスをプロセス選択部526が選択する基準は、ユーザになるべく不便を感じさせないという観点において、優れている。例えば、第1の比較例として、単純に利用頻度が低いアプリケーションのプロセスから順に強制終了させる方針が考えられる。しかし、インストール直後のアプリケーションの利用頻度は低い。よって、第1の比較例によれば、インストール直後のアプリケーションをユーザがフォアグラウンドで利用しているときにメモリ不足に陥ると、ユーザがまさに利用中のアプリケーションが強制終了されてしまうことがあり、大変不便である。また、第2の比較例として、第1の比較例の欠点を克服するために単位時間あたりの利用頻度を利用する方針が考えられる。しかし、第2の比較例には、単位時間あたりの利用頻度を計算するコストがかかるという、別の欠点がある。単位時間を長くすれば計算コストは下がるが、あまり単位時間が長いと、単位時間よりも短い時間以内にインストールされたアプリケーションの利用頻度がゼロとなり、第1の比較例と同じ問題が発生する。逆に、単位時間が短ければ、単位時間の経過のたびに行われる計算のコストが増大する。また、第3の比較例として、ランダムにプロセスを強制終了する方針が考えられる。しかし、現在フォアグラウンドで実行中のアプリケーションのプロセスグループに属するプロセスが、偶然強制終了されるおそれがある。さらに、第4の比較例として、予め固定的に決められた順序でプロセスを強制終了する方針が考えられる。しかし、任意のアプリケーションがインストールされ得る環境では、予め固定的に順序を定義することは現実的ではない。以上のような第1~第4の比較例と比べると、13fの変形例におけるプロセス選択部526の選択基準は優れている。なぜなら、第1に、アプリケーション利用時刻表529が使われるので、フォアグラウンドで実行中のアプリケーションのプロセスグループに属するプロセスが他のアプリケーションのプロセスよりも先に強制終了されることはないからである。つまり、フォアグラウンドで実行中のアプリケーションは、たとえ最近インストールされたものだとしても、インストールされてからの経過時間が短いせいで先に強制されるという事態には陥らずに済む。また、第2に、アプリケーション利用時刻表529への時刻の登録を行うコストが、単位時間あたりの利用頻度を単位時間が経過するたびに計算するコストと比べて、非常に小さいからである。そして、第3に、プロセスを強制終了する順序を予め固定的に定義する必要もないからである。また、第4に、プロセス選択部526は、個々のプロセスをばらばらに選ぶ代わりに、アプリケーションに注目して1つまたは複数のプロセスをまとめて選ぶからである。マルチプロセスのアプリケーションにおいて、1つのプロセスだけを強制終了した場合、アプリケーション自体は動作しなくなるにもかかわらず、残りの他のプロセスが終了していないため、無駄にメモリを消費するといった事態に陥るおそれがある。しかし、プロセス選択部526によれば、そのような事態が避けられるので、無駄なメモリ消費を避けられる。また、図28のようにメモリ管理モジュール525がカーネル513内に含まれる場合、ユーザメモリ空間でのメモリが不足しているときに、強制終了するプロセスを選択するためにさらにユーザメモリ空間のメモリを消費するという本末転倒が回避可能である。なぜなら、メモリ管理モジュール525のプロセス選択部526がプロセスを選択するために行う処理のワーキングエリアはカーネルメモリ空間内にあるからである。なお、本発明は上記の実施形態およびその変形例に限られるものではなく、様々に変形可能である。例えば、マルチスレッドで実行されるプロセスが存在し得る場合、認識部103またはプロセスグループ判定部501は、プロセスグループではなく、スレッドグループを認識してもよい。プロセスグループとスレッドグループは、単に粒度が違うだけであり、グループの認識のための方法は同じである。例えば、psコマンドによりスレッドの一覧を得ることも可能である。よって、認識部103またはプロセスグループ判定部501は、プロセスグループを認識するのと同様にして、psコマンドの出力を利用して、アプリケーションに関連するスレッドグループを認識することもできる。また、例えば図4では、Cという名前のアプリケーションのパッケージに含まれるメインタスク用のプログラムの名前がC1であるが、メインタスク用のプログラムの名前がアプリケーションの名前と同じCであってもよい。そして、プログラムの名前はプロセスの名前でもあるが、プロセスの名前が非常に長い場合、psコマンドの出力結果にはプロセスの名前の一部しか含まれないこともあり得る。その場合、プロセス一覧507を参照してプロセス名からPIDを得る処理は、プロセス名に関して、文字列の完全一致検索の代わりに、部分一致検索を行う処理を含む。また、上記の説明においては、リストやテーブルなどのデータ構造を例示したが、他の適宜のデータ構造が利用されてもよいことは当然である。また、例えばプロセス集合を示すのにPIDのリストが使われてもよいが、リスト内でのPIDの順序によらず、リストが表すプロセス集合は同じである。そして、様々なフローチャートを例示したが、フローチャート中のステップの順序は一例にすぎない。ステップの順序は、矛盾が生じない限り適宜入れ替えられてもよい。"