(57)【要約】  端末装置１００は、端末装置１００にインストールされたアプリケーションＡが使用する資源の集合｛Ｒ１，Ｒ２，Ｒ３｝を示す使用資源情報１１１を記憶する第１の記憶部１０１を有する。また、端末装置１００は、特定プロセスＰ１とＰ３によりアクセスが提供される特定資源Ｒ１とＲ３をそれぞれ特定プロセスＰ１とＰ３と対応づける対応づけ情報１１２を記憶する第２の記憶部１０２を有する。また、端末装置１００は、使用資源情報１１１により示される資源の集合に含まれるいずれかの資源に対応づけ情報１１２により対応づけられている特定プロセスの集合｛Ｐ１，Ｐ３｝を含む、アプリケーションＡに関連するプロセスグループ｛ＰＡ１，ＰＡ２，Ｐ１，Ｐ３｝を認識する認識部１０３を有する。
2012127596.tif 000002
【特許請求の範囲】
【請求項１】
端末装置であって、
前記端末装置にインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を記憶する第１の記憶部と、
特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を記憶する第２の記憶部と、
前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する認識部と
を備えることを特徴とする端末装置。
【請求項２】
前記認識部は、さらに、前記アプリケーションの実行により生成されるプロセスを前記プロセスグループの要素として認識する
ことを特徴とする請求項１に記載の端末装置。
【請求項３】
前記アプリケーションのパッケージに含まれる１つ以上のプログラムをそれぞれ識別するプログラム識別情報を含む構成情報を記憶する第３の記憶部をさらに備え、
前記認識部は、前記構成情報を参照することにより、前記アプリケーションの実行により生成される前記プロセスを認識する
ことを特徴とする請求項２に記載の端末装置。
【請求項４】
前記パッケージは、前記アプリケーションが使用する各資源を識別する第１の資源識別情報を含み、
前記使用資源情報は、
前記パッケージから抽出される前記第１の資源識別情報、または
前記端末装置が使用可能な各資源を識別するように前記第１の資源識別情報と対応づけられて決められた第２の資源識別情報
により、前記アプリケーションが使用する前記資源の前記集合を示す
ことを特徴とする請求項３に記載の端末装置。
【請求項５】
前記認識部は、認識した前記プロセスグループに属する任意のプロセスの子孫プロセスを、さらに前記プロセスグループの要素として認識する
ことを特徴とする請求項２から４のいずれか１項に記載の端末装置。
【請求項６】
前記アプリケーションが、起動されるとき、一時停止状態から再開されるとき、バックグラウンドでの実行状態からフォアグラウンドでの実行状態に遷移するとき、またはフォアグラウンドで実行中のときに、前記プロセスグループに含まれるプロセスと前記プロセスグループに含まれないプロセスに対して異なる制御を行う制御部
をさらに備えることを特徴とする請求項２から５のいずれか１項に記載の端末装置。
【請求項７】
前記制御部は、前記プロセスグループに含まれるプロセスの優先度を、前記プロセスグループに含まれないプロセスの優先度よりも高くする
ことを特徴とする請求項６に記載の端末装置。
【請求項８】
前記制御部は、前記プロセスグループに含まれるプロセスの実行を継続させ、前記プロセスグループに含まれないプロセスを一時停止させる
ことを特徴とする請求項６に記載の端末装置。
【請求項９】
前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源を確保している確保中プロセスが、前記プロセスグループに含まれない場合、前記制御部は、
前記確保中プロセスが一時停止中であれば、前記確保中プロセスを再開し、
前記確保中プロセスが実行中であれば、前記確保中プロセスの実行を継続させる
ことを特徴とする請求項８に記載の端末装置。
【請求項１０】
前記使用資源情報により示される前記資源の前記集合に含まれる資源のうち、少なくとも、前記対応づけ情報により前記特定プロセスと対応づけられていない資源に対するオープン操作とクローズ操作を監視する資源監視部をさらに備え、
前記制御部は、前記資源監視部による監視結果にしたがって、前記確保中プロセスを識別する
ことを特徴とする請求項９に記載の端末装置。
【請求項１１】
前記制御部は、前記プロセスグループに含まれるプロセスの実行を継続させ、前記プロセスグループに含まれないプロセスのうち少なくとも一部を強制終了させる
ことを特徴とする請求項６から１０のいずれか１項に記載の端末装置。
【請求項１２】
前記端末装置が備えるメモリの空き容量が基準以上であるか否かを監視するメモリ監視部をさらに備え、
前記制御部は、前記メモリの空き容量が前記基準未満であることを前記メモリ監視部が検出したときに、前記プロセスグループに含まれないプロセスの少なくとも一部を強制終了させる
ことを特徴とする請求項１１に記載の端末装置。
【請求項１３】
前記アプリケーションをフォアグラウンドで実行するための指示の入力を受け付ける入力部をさらに備え、
前記制御部は、前記指示の前記入力を前記入力部が受け付けたことを契機として、前記プロセスグループに含まれるプロセスと前記プロセスグループに含まれないプロセスに対して異なる制御を行う
ことを特徴とする請求項６から１２のいずれか１項に記載の端末装置。
【請求項１４】
前記端末装置において使用可能な複数の資源のうち少なくとも一部に対するオープン操作とクローズ操作を監視し、前記オープン操作を検出したとき、検出した前記オープン操作によりオープンされた資源と、検出した前記オープン操作を呼び出したプロセスとを対応づけ、前記クローズ操作を検出したとき、検出した前記クローズ操作によりクローズされた資源と、検出した前記クローズ操作を呼び出したプロセスとの対応づけを解消する資源監視部をさらに備え、
前記対応づけ情報のうち少なくとも一部は、或る特定プロセスからの或る特定資源に対するオープン操作を前記資源監視部が検出したときに、前記或る特定資源と前記或る特定プロセスを前記資源監視部が対応づけることにより生成されて、前記第２の記憶部に記憶された情報である
ことを特徴とする請求項１〜９、１１〜１３のいずれか１項に記載の端末装置。
【請求項１５】
前記対応づけ情報は、
前記特定資源と前記特定資源以外の資源を区別する第１の区別情報と、前記特定プロセスと前記特定プロセス以外のプロセスを区別する第２の区別情報の一方または双方、
前記特定資源を表すファイル名と、前記ファイル名とは独立に前記特定資源を論理的に識別する論理資源識別情報の一方または双方、
特定プログラムの実行により前記特定プロセスが生成されるときに前記特定プロセスに動的に割り当てられる、前記特定プロセスに一意のプロセス識別子と、前記特定プログラムを識別するプログラム識別情報の一方または双方、
を用いて、前記特定資源を前記特定プロセスと対応づける情報である
ことを特徴とする請求項１から１４のいずれか１項に記載の端末装置。
【請求項１６】
前記端末装置が使用可能な各資源は、
前記端末装置に内蔵もしくは接続されている物理デバイス、または
前記端末装置が記憶する、データベースもしくは他の所定ファイル
であることを特徴とする請求項１から１５のいずれか１項に記載の端末装置。
【請求項１７】
コンピュータが実行するプロセス管理方法であって、
前記コンピュータにインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を取得し、
特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を取得し、
前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する
ことを含むことを特徴とするプロセス管理方法。
【請求項１８】
コンピュータに、
前記コンピュータにインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を取得し、
特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を取得し、
前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する
ことを含む処理を実行させることを特徴とするプロセス管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末装置におけるプロセスの管理に関する。
【背景技術】
【０００２】
多くの情報処理装置は、単一のプロセスのみを実行するのではなく、複数のプロセスを実行する。そのため、プロセス間での資源配分や、プロセスのスケジューリングなど、プロセスの管理に関する様々な技術が研究されている。【０００３】
例えば、１つの情報処理手段上で、制御処理のリアルタイム性の保証およびネットワーク通信処理のスループットの保証をともに実現することを目的とした次のようなコントローラが提案されている。【０００４】
コントローラは、複数のタスクを、ネットワーク通信系と通信を行うための通信タスクグループと、監視制御対象を監視制御するための制御タスクグループとに分けて管理する。また、コントローラは、複数のタスクの実行順序をグループ単位で切り換え、切り換えられたタスク群にしたがって、監視制御対象またはネットワーク通信系から得られた情報の処理を実行する。【０００５】
また、時分割スケジューリングを前提としたアプリケーションに対して、実行アプリケーション数が頻繁に増減する環境においてもアプリケーションの応答性能を容易に、かつ自動的に最大限に引き出すことを目的とした、次のような技術も提案されている。【０００６】
当該技術によれば、アプリケーション依存解析部が、時分割スケジューリング上で動作するプロセスにおける起床から休止までの処理をノードとして扱い、ノード間の依存関係の解析を行い、ノードの実行順序と依存関係とを示す依存解析情報を形成する。また、制御変更判定部が、依存解析情報に基づいて、アプリケーションを構成するプロセスを時分割スケジューリングからグループスケジューリングへ移行させる。そして、グループスケジューリング実行部が、移行したプロセスについて、依存解析情報に基づいて、プロセス単位でグループスケジューリングを実施する。【０００７】
さらに、オーバヘッドの増加を極力抑えてタスク優先度の逆転現象を防止することを目的とした、次のような技術も提案されている。
低位優先度の第１のタスクが資源管理手段を介して共有資源を専有使用している最中に、高位優先度の第２のタスクから同じ共有資源の使用要求が発行される場合がある。この場合、タスク管理手段は、第１のタスクの優先度を、共有資源の使用終了までの間、第２のタスクの優先度に一時変更する。【０００８】
優先度の一時変更により、タスク優先度の逆転現象が防止される。すなわち、「第１のタスクによる共有資源の使用中に中位優先度の第３のタスクから割り込みが入って、第１のタスクの処理が後回しになり、結果として、第３のタスクがより優先度の高い第２のタスクより先に処理を行う」という逆転現象が防止される。【０００９】
また、複数のアプリケーションソフトを起動する場合でのメモリの容量不足を解消して快適な動作環境を実現することを目的とした次のような情報端末装置も提案されている。
情報端末装置は、情報端末装置に搭載された複数のアプリケーションソフトに、常駐型または一時型の属性情報を設定しておき、その属性情報を現在動作中のアプリケーションソフトに対応づけてテーブルで管理する。また、情報端末装置は、アプリケーション起動時に、テーブルを参照して現在動作中のアプリケーションソフトに設定された属性情報を判断する。【００１０】
そして、情報端末装置は、常駐型の属性情報が設定されたアプリケーションソフトを実行メモリにそのまま残し、一時型の属性情報が設定されたアプリケーションソフトを強制終了して実行メモリから解放する。これにより、「多数のアプリケーションソフトの使用によってメモリ容量が不足となり、実行動作が遅くなったり、ソフトが暴走したりする」などの問題を回避することができる。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００３−６７２０１号公報
【特許文献２】特開２００９−４８３５８号公報
【特許文献３】特開平８−７７０２５号公報
【特許文献４】特開２００３−１５８９２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
様々な分野において、様々に異なる用途に、様々なハードウェア構成の装置が利用されている。そのため、ある特定の装置に適したプロセス管理方法が他の装置にも適しているとは限らない。【００１３】
例えば、或る種の端末装置では、ユーザによるアプリケーションのインストールが制限されている。そして、或る種のプロセス管理方法では、端末装置の性能を引き出すために、「限られた特定のアプリケーションしか実行されない」という前提条件が利用され、限られた特定のアプリケーションに応じたチューニングが行われることがある。【００１４】
他方、ユーザが任意のアプリケーションをインストールすることのできる端末装置の利用も広まりつつある。ユーザが任意のアプリケーションをインストールすることのできる端末装置においては、上記前提条件が成立しないので、上記の或る種のプロセス管理方法は不適当である。【００１５】
そこで本発明は、任意のアプリケーションがインストールされ得る端末装置におけるプロセス管理に好適な、プロセスのグルーピングを実現することを目的とする。
【課題を解決するための手段】
【００１６】
一態様により提供される端末装置は、第１の記憶部と第２の記憶部と認識部を含む。前記第１の記憶部は、前記端末装置にインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を記憶する。また、前記第２の記憶部は、特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を記憶する。そして、前記認識部は、前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する。
【発明の効果】
【００１７】
上記端末装置にインストールされた或るアプリケーションが使用する或る資源へのアクセスが、或る特定プロセスによって提供される場合、上記端末装置によれば、上記認識部により認識されるプロセスグループは、当該或る特定プロセスを含む。つまり、当該或るアプリケーションに関連するプロセスグループの要素として、当該或る特定プロセスが認識される。そして、複数の任意のアプリケーションがインストールされた場合でも、上記端末装置の認識部は、各アプリケーションについて同様にプロセスグループを認識することができる。【００１８】
以上のようにして認識されるプロセスグループは、例えば、プロセス間の優先度制御、一時停止するプロセスの決定、強制終了するプロセスの決定など、様々なプロセス管理における管理単位として好適である。そして、上記のようにして認識された適切なプロセスグループを用いて適宜のプロセス管理が行われれば、アプリケーション開発者は、他のアプリケーションの実行に支障をきたさないようにするための特別な仕組みを予めアプリケーション内に組み込む必要がない。すなわち、上記端末装置によるプロセスグループの認識は、アプリケーション開発者の負担を減らして開発と設計の自由度を高めるための基盤技術としての潜在力を有する。【００１９】
以上のように、上記端末装置は、任意のアプリケーションがインストールされ得る端末装置におけるプロセス管理に好適な、プロセスのグルーピングを実現することができる。
【図面の簡単な説明】
【００２０】
【図１】第１実施形態の端末装置のブロック構成図である。
【図２】スマートフォンのハードウェア構成図である。
【図３】適切なプロセスグループの例を説明する図である。
【図４】スマートフォンにおけるアプリケーションパッケージの管理を説明する図である。
【図５】第２実施形態によるスマートフォンのブロック構成図である。
【図６】アプリケーションパッケージと資源とプロセスの具体例を説明する図である。
【図７】各種データの具体例を説明する図である。
【図８】第２実施形態において切り替えイベント通知部が行う処理のフローチャートである。
【図９】第２実施形態においてプローブが行う処理のフローチャートである。
【図１０】第２実施形態において依存関係管理部が行う処理のフローチャートである。
【図１１】第２実施形態においてプロセスグループ判定部が行う処理のフローチャートである。
【図１２】第２実施形態においてプロセス制御モジュールが行う処理のフローチャート（その１）である。
【図１３】第２実施形態においてプロセス制御モジュールが行う処理のフローチャート（その２）である。
【図１４】図１２〜１３の処理から呼び出されるサブルーチンのフローチャートである。
【図１５】第２実施形態の変形例において、図１４のサブルーチンの代わりにプロセス制御モジュールが実行するサブルーチンのフローチャートである。
【図１６】第２実施形態の変形例によるスマートフォンのブロック構成図である。
【図１７】第２実施形態の変形例においてアプリケーション情報解析部が行う処理のフローチャートである。
【図１８】第２実施形態の変形例においてプローブが行う処理のフローチャートである。
【図１９】第２実施形態の変形例において監視資源フィルタが行う処理のフローチャートである。
【図２０】第２実施形態の変形例においてプローブが行う処理のフローチャートである。
【図２１】第２実施形態の変形例においてプロセスグループ判定部が行う処理のフローチャートである。
【図２２】第２実施形態の変形例において既知メンバ検出部が行う処理のフローチャートである。
【図２３】プロセスの親子関係を示す樹形図の例である。
【図２４】第２実施形態の変形例においてプロセスグループ判定部が行う処理のフローチャートである。
【図２５】第２実施形態の変形例において親子関係判定部が行う処理のフローチャートである。
【図２６】第２実施形態の変形例においてプロセス制御モジュールが行う処理のフローチャートである。
【図２７】第２実施形態の変形例において、図１４のサブルーチンの代わりにプロセス制御モジュールが実行するサブルーチンのフローチャートである。
【図２８】第２実施形態の変形例におけるメモリ管理モジュールの詳細を示すブロック構成図である。
【図２９】第２実施形態の変形例においてメモリ管理モジュールが行う処理のフローチャートである。
【発明を実施するための形態】
【００２１】
以下、実施形態について、図面を参照しながら詳細に説明する。まず、図１を参照して第１実施形態について説明する。次に、図２〜２９を参照して、第２実施形態および第２実施形態に関するいくつかの変形例について説明する。
【００２２】
図１は、第１実施形態の端末装置のブロック構成図である。図１の端末装置１００は、第１の記憶部１０１と第２の記憶部１０２と認識部１０３を有する。また、端末装置１００はさらに第３の記憶部１０４と制御部１０５を有することが好ましい。端末装置１００はさらに入力部１０６と資源監視部１０７とメモリ監視部１０８を有してもよい。
【００２３】
第１の記憶部１０１と第２の記憶部１０２と第３の記憶部１０４は、物理的には１つのメモリモジュール内の異なる３つの記憶領域であってもよいし、物理的に異なるメモリモジュールであってもよい。また、認識部１０３と制御部１０５と資源監視部１０７とメモリ監視部１０８は、例えば、端末装置１００が備える不図示のＣＰＵ（Central Processing Unit）により実現されてもよい。入力部１０６は、例えば、入力キーであってもよいし、タッチスクリーンでもよい。
【００２４】
第１の記憶部１０１は、端末装置１００にインストールされたアプリケーションが使用する資源の集合を示す使用資源情報１１１を記憶する。図１には、アプリケーションＡが資源Ｒ１と資源Ｒ２と資源Ｒ３を使用する場合の使用資源情報１１１が例示されている。
【００２５】
なお、端末装置１００には任意の複数のアプリケーションがインストールされ得る。図１には、アプリケーションＡについての使用資源情報１１１のみが例示されているが、第１の記憶部１０１は、インストールされた複数のアプリケーションのそれぞれについて、同様に使用資源情報１１１を記憶することができる。
【００２６】
また、「資源」は、具体的には、例えば（１ａ）〜（１ｃ）のいずれかであってもよい。
（１ａ）端末装置１００に内蔵もしくは接続されている物理デバイス（例えば、サウンドデバイスやセンサなど）
（１ｂ）端末装置１００が記憶するデータベース
（１ｃ）端末装置１００が記憶する所定ファイル（例えば、複数のアプリケーションからのアクセスが許可された共通の設定ファイルなど）
また、端末装置１００において使用可能な資源の中には、ユーザアプリケーションのプロセスからはアクセスされない資源（以下「特定資源」ともいう）がある。特定資源へのアクセスは、所定のプログラム（以下「特定プログラム」ともいう）のプロセス（以下「特定プロセス」ともいう）により提供され、ユーザアプリケーションは特定プロセスを介して特定資源にアクセスする。
【００２７】
例えば、特定資源は、サウンドチップまたはサウンドカードなどのサウンドデバイスであってもよい。そして、特定プロセスは、サウンドデバイスから音声を出す処理を行うために特定資源を独占的に占有するデーモンプロセスであってもよい。
【００２８】
アプリケーションが上記デーモンプロセスに対して音声の出力を要求し、デーモンプロセスが要求にしたがって動作することにより、サウンドデバイスが音声を出力し、スピーカから放音される。なお、特定資源へのアクセスを提供するために特定資源を占有するデーモンは、「サービス」と呼ばれることもある。換言すれば、特定プロセスは、特定資源へのアクセスのためのＡＰＩ（Application Programming Interface）を提供する。
【００２９】
端末装置１００の第２の記憶部１０２は、特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ特定プロセスと対応づける対応づけ情報１１２を記憶する。図１には、端末装置１００から使用可能な資源のうち、資源Ｒ１と資源Ｒ３が特定資源である場合の対応づけ情報１１２が例示されている。
【００３０】
図１の例では、資源Ｒ１に対応する特定プロセスはプロセスＰ１であり、資源Ｒ３に対応する特定プロセスはプロセスＰ３である。また、図１の例では、資源Ｒ２は特定資源ではない。よって、アプリケーションＡは、特定プロセスを介さずに、例えば、「オープン」（open）、「リード」（read）、「ライト」（write）、「クローズ」（close）などのシステムコールを呼び出すことで、資源Ｒ２にアクセスする。
【００３１】
認識部１０３は、使用資源情報１１１と対応づけ情報１１２を用いて、端末装置１００にインストールされたアプリケーションに関連するプロセスグループを認識する。アプリケーションに関連するプロセスグループは、使用資源情報１１１により示される資源の集合に含まれるいずれかの資源に対応づけ情報１１２により対応づけられている特定プロセスの集合を、少なくとも含む。
【００３２】
例えば、アプリケーションＡに関して、使用資源情報１１１により示される資源の集合は、図１の例では｛Ｒ１，Ｒ２，Ｒ３｝である。そして、この集合｛Ｒ１，Ｒ２，Ｒ３｝に含まれるいずれかの資源に、対応づけ情報１１２により対応づけられている特定プロセスの集合は、図１の例では、｛Ｐ１，Ｐ３｝である。したがって、認識部１０３が認識する、アプリケーションＡに関するプロセスグループは、少なくとも、特定プロセスの集合｛Ｐ１，Ｐ３｝を含む。
【００３３】
以上のようにして認識されるプロセスグループは、プロセス間の優先度制御、一時停止（suspend）するプロセスの決定、強制終了するプロセスの決定など、様々なプロセス管理における管理単位として好適である。
【００３４】
例えば、端末装置１００は、アプリケーションＡをフォアグラウンドで実行するとき、アプリケーションＡを利用するユーザが感じる性能を上げるために、アプリケーションＡのプロセスの優先度を上げてもよい。それにより、端末装置１００は、アプリケーションＡのプロセスに割り当てるＣＰＵ時間を増やす。例えば、アプリケーションＡのプロセスに割り当てられたＣＰＵ時間が多いほど、ユーザによる入力操作から応答までにかかる応答時間が短く、応答時間が短いほど、ユーザが感じる性能は高い。
【００３５】
しかしながら、単にアプリケーションＡのプロセスの優先度を上げるだけでは、応答時間短縮などの効果が得られないおそれがある。なぜなら、アプリケーションＡはプロセスＰ１を介して資源Ｒ１を使用し、プロセスＰ３を介して資源Ｒ３を使用するからである。
【００３６】
もし、プロセスＰ１の優先度が低ければ、プロセスＰ１にはあまりＣＰＵ時間が割り当てられない。その結果、アプリケーションＡからプロセスＰ１を介して資源Ｒ１にアクセスするのに時間がかかるかもしれない。プロセスＰ３についても同様である。
【００３７】
よって、応答時間短縮などの効果を得るには、プロセスＰ１やプロセスＰ３も含むプロセスグループ全体の優先度を上げることが好ましい。そして、認識部１０３は、上記のとおり、アプリケーションＡに関連するプロセスグループがプロセスＰ１およびプロセスＰ３を含むことを認識する。
【００３８】
もちろん、一時停止や強制終了など、優先度制御以外のプロセス管理のための管理単位としても、認識部１０３により認識されたプロセスグループは好適である。
また、認識部１０３は、アプリケーションＡの実行により生成されるプロセスも、アプリケーションＡに関連するプロセスグループの要素として認識することが望ましい。認識部１０３は、具体的には、第３の記憶部１０４に記憶された構成情報１１３を参照することにより、アプリケーションＡの実行により生成されるプロセスを認識してもよい。
【００３９】
構成情報１１３は、アプリケーションのパッケージに含まれる１つ以上のプログラムをそれぞれ識別するプログラム識別情報を含む情報である。プログラム識別情報は、例えばプログラムの名前である。図１に例示した構成情報１１３は、アプリケーションＡのパッケージが「Ａ１」と「Ａ２」という名前の２つのプログラムを含むことを示す。
【００４０】
アプリケーションＡの実行時には、具体的にはこれら２つのプログラムが実行される。よって、認識部１０３は、構成情報１１３を参照し、「Ａ１」と「Ａ２」という名前の２つのプログラムに対応するプロセスを特定することで、アプリケーションＡの実行により生成されるプロセスを認識する。
【００４１】
例えば、認識部１０３は、「ｐｓ」コマンドを利用して実行中のプロセスの一覧を得てもよい。プロセスの一覧にはプロセスの名前とプロセス識別子（process identifier; PID）が含まれる。また、プロセスの名前としては、プログラムの名前が使われる。よって、認識部１０３は、プロセスの一覧から、「Ａ１」と「Ａ２」という名前の２つのプログラムの実行により生成される２つのプロセスそれぞれのＰＩＤを得ることができる。
【００４２】
例えば以上のようにして、認識部１０３は、構成情報１１３を参照することにより、アプリケーションＡの実行により生成される２つのプロセスを認識することができる。そして、認識部１０３は、認識した２つのプロセスも、アプリケーションＡに関連するプロセスグループの要素として認識する。
【００４３】
図１には、以上のようにして認識部１０３が認識した認識結果１１４も例示されている。すなわち、認識結果１１４によれば、アプリケーションＡに関連するプロセスグループは、以下の（２ａ）〜（２ｄ）の４つのプロセスを含む。
【００４４】
（２ａ）構成情報１１３に示される「Ａ１」という名前のプログラムの実行により生成されるプロセスＰＡ１
（２ｂ）構成情報１１３に示される「Ａ２」という名前のプログラムの実行により生成されるプロセスＰＡ２
（２ｃ）使用資源情報１１１に示される資源Ｒ１に対応する特定プロセスであるプロセスＰ１
（２ｄ）使用資源情報１１１に示される資源Ｒ３に対応する特定プロセスであるプロセスＰ３
なお、上記（２ａ）〜（２ｄ）のいずれかのプロセスが子孫プロセスを生成し得る場合は、認識部１０３は、生成された子孫プロセスもアプリケーションＡに関連するプロセスグループの要素として認識することが好ましい。
【００４５】
また、図１に示すように、端末装置１００は、認識部１０３が認識したプロセスグループを用いてプロセス管理を行う制御部１０５をさらに有することが好ましい。具体的には、制御部１０５は、認識部１０３が認識したプロセスグループに含まれるプロセスと、当該プロセスグループに含まれないプロセスに対して異なる制御を行う。
【００４６】
また、端末装置１００は、アプリケーションをフォアグラウンドで実行するための指示の入力を受け付ける入力部１０６さらに有してもよい。アプリケーションをフォアグラウンドで実行するための指示の具体例は、下記の（３ａ）〜（３ｃ）である。
【００４７】
（３ａ）新たにアプリケーションを起動し、起動したアプリケーションをフォアグラウンドで実行するための指示
（３ｂ）一時停止状態のアプリケーションを再開し、再開したアプリケーションをフォアグラウンドで実行するための指示
（３ｃ）バックグラウンドで実行中のアプリケーションを、フォアグラウンドでの実行状態に遷移させるための指示
そして、制御部１０５は、入力部１０６が指示の入力を受け付けたことを契機として、認識部１０３が認識したプロセスグループに含まれるプロセスと当該プロセスグループに含まれないプロセスに対して異なる制御を行ってもよい。もちろん、制御部１０５は、入力部１０６による入力の受け付け以外のイベントを契機にして、制御を行ってもよい。
【００４８】
例えば、制御部１０５は、以下の（４ａ）〜（４ｄ）のいずれのタイミングで制御を行ってもよいが、（４ｄ）のタイミングは、入力部１０６による入力の受け付け以外のイベント（例えばタイマによる定期的な割り込み）を契機として検出されてもよい。
【００４９】
（４ａ）アプリケーションが起動されるとき
（４ｂ）アプリケーションが一時停止状態から再開されるとき
（４ｃ）アプリケーションがバックグラウンドでの実行状態からフォアグラウンドでの実行状態に遷移するとき
（４ｄ）アプリケーションがフォアグラウンドで実行中のとき
また、認識部１０３が認識したプロセスグループに含まれるプロセスと当該プロセスグループに含まれないプロセスに対して制御部１０５が行う上記の「異なる制御」は、より具体的には、例えば以下のような制御である。
【００５０】
制御部１０５は、認識部１０３が認識したプロセスグループに含まれるプロセスの優先度を、当該プロセスグループに含まれないプロセスの優先度よりも高くしてもよい。
あるいは、制御部１０５は、認識部１０３が認識したプロセスグループに含まれるプロセスの実行を継続させ、当該プロセスグループに含まれないプロセスを一時停止させてもよい。
【００５１】
さらに、制御部１０５は、使用資源情報１１１により示される資源の集合に含まれるいずれかの資源を確保しているプロセス（以下「確保中プロセス」という）が、認識部１０３が認識したプロセスグループに含まれない場合、以下の制御を行ってもよい。すなわち、制御部１０５は、確保中プロセスが一時停止中であれば、確保中プロセスを再開し、確保中プロセスが実行中であれば、確保中プロセスの実行を継続させる。制御部１０５はさらに、確保中プロセスが確保していた資源を解放したら、確保中プロセスを一時停止させてもよい。
【００５２】
例えば、図１の例によれば、アプリケーションＡが使用する資源Ｒ２は、特定資源ではない。よって、アプリケーションＡの実行中に、資源Ｒ２が他のアプリケーション（説明の便宜上「アプリケーションＢ」とする）によりアクセスされている可能性がある。しかし、アプリケーションＢのプロセス（すなわち、アプリケーションＢのパッケージに含まれるプログラムの実行により生成されるプロセス）は、認識部１０３が認識したアプリケーションＡに関するプロセスグループに属さない。
【００５３】
よって、もし制御部１０５が、認識部１０３により認識されたプロセスグループに属さないすべてのプロセスを一時停止させてしまうと、資源Ｒ２がアプリケーションＢのプロセスにより確保されたまま解放されないおそれがある。そこで、制御部１０５は、上記のとおり、確保中プロセス（例えば資源Ｒ２をオープンして資源Ｒ２にアクセス中のアプリケーションＢのプロセス）がある場合、確保中プロセスを一時停止させないように制御する。
【００５４】
すると、確保中プロセスがいずれ資源を解放すれば、解放された資源へのアクセスが可能となる。つまり、制御部１０５が上記のように確保中プロセスに関する例外処理を行うことで、認識部１０３が認識したプロセスグループに基づく一時停止制御に起因する副作用をなくすことができる。
【００５５】
具体的には、例えば以下のようにして制御部１０５が確保中プロセスを識別することができる。
図１の例において、対応づけ情報１１２により対応づけられているのは、特定資源と特定プロセスである。しかし、対応づけ情報１１２がさらに、特定資源以外の資源と特定プロセス以外のプロセスとを対応づける情報を含んでいてもよい。
【００５６】
例えば、アプリケーションＢの実行により１つまたは複数のプロセスが生成され得るが、そのうちの１つを、説明の便宜上「プロセスＰＢ１」と表記することにする。図１の例では、資源Ｒ２は特定資源ではないので、資源Ｒ２がプロセスＰＢ１により確保されることもあり得る。
【００５７】
対応づけ情報１１２は、資源Ｒ２がプロセスＰＢ１により確保されている場合、資源Ｒ２とプロセスＰＢ１を対応づける情報を含んでもよい。また、資源Ｒ２とプロセスＰＢ１を対応づける情報は、プロセスＰＢ１が資源Ｒ２を解放したら、対応づけ情報１１２から削除される。
【００５８】
以上説明したように拡張された対応づけ情報１１２は、例えば、資源監視部１０７による監視の結果として得られてもよい。
例えば、資源監視部１０７は、使用資源情報１１１により示される資源の集合に含まれる資源のうち、少なくとも、対応づけ情報１１２により特定プロセスと対応づけられていない資源に対するオープン操作とクローズ操作を監視してもよい。すると、制御部１０５は、資源監視部１０７による監視結果にしたがって、確保中プロセスを識別することができる。
【００５９】
オープン操作は、換言すれば、資源を獲得するための獲得操作である。オープン操作は、具体的には「オープン」システムコールであってもよい。また、クローズ操作は、換言すれば、オープン操作により確保した資源を解放するための解放操作である。クローズ操作は、具体的には「クローズ」システムコールであってもよい。
【００６０】
よって、或るプロセスが或る資源をオープンしてから当該或る資源をクローズするまでの間は、当該或る資源は、当該或るプロセスにより確保されている。そのため、制御部１０５は、資源監視部１０７による監視結果から、確保中プロセスを識別することができる。
【００６１】
例えば、図１の例では、資源Ｒ２は、特定プロセスと対応づけられてはいないので、資源監視部１０７は少なくとも資源Ｒ２に対するオープン操作とクローズ操作を監視する。上記のとおり、特定資源以外の資源と特定プロセス以外のプロセスとを対応づける情報をさらに含むように、対応づけ情報１１２が拡張される実施形態では、資源監視部１０７が以下の（５ａ）〜（５ｂ）のように動作してもよい。
【００６２】
（５ａ）プロセスＰＢ１が資源Ｒ２をオープンしたとき、資源監視部１０７は、資源Ｒ２とプロセスＰＢ１を対応づける情報を、対応づけ情報１１２に追加する。
（５ｂ）プロセスＰＢ１が資源Ｒ２をクローズしたとき、資源監視部１０７は、資源Ｒ２とプロセスＰＢ１を対応づける情報を、対応づけ情報１１２から削除する。すなわち、資源監視部１０７は、資源Ｒ２とプロセスＰＢ１の対応づけを解消する。
【００６３】
以上のとおり、拡張された対応づけ情報１１２には、資源監視部１０７による監視結果が反映される。よって、制御部１０５は、拡張された対応づけ情報１１２を参照することで、確保中プロセスを識別してもよい。
【００６４】
また、特定資源と特定プロセスの対応づけは、予め静的に対応づけ情報１１２に記録されていてもよいし、資源監視部１０７により動的に行われてもよい。資源監視部１０７は、具体的には以下のように動作してもよい。
【００６５】
資源監視部１０７は、端末装置１００において使用可能な複数の資源のうち少なくとも一部に対するオープン操作とクローズ操作を監視する。資源監視部１０７は、特定資源以外の資源に対するオープン操作とクローズ操作を監視するだけでなく、特定資源に対するオープン操作とクローズ操作を監視してもよい。
【００６６】
そして、資源監視部１０７は、オープン操作を検出したとき、検出したオープン操作によりオープンされた資源と、検出したオープン操作を呼び出したプロセスとを対応づける。具体的には、資源監視部１０７は、資源とプロセスを対応づける情報を、拡張された対応づけ情報１１２に追加することで、資源とプロセスの対応づけを行ってもよい。
【００６７】
また、資源監視部１０７は、クローズ操作を検出したとき、検出したクローズ操作によりクローズされた資源と、検出したクローズ操作を呼び出したプロセスとの対応づけを解消する。具体的には、資源監視部１０７は、資源とプロセスを対応づける情報を、拡張された対応づけ情報１１２から削除することで、対応づけの解消を行ってもよい。
【００６８】
そして、上記のとおり資源監視部１０７の監視対象の資源の中には、特定資源が含まれていてもよい。或る特定資源が監視対象の場合、対応づけ情報１１２のうち少なくとも一部（すなわち、当該或る特定資源に対応する部分）は、当該或る特定プロセスからの或る特定資源に対するオープン操作を資源監視部１０７が検出したときに動的に生成される情報である。つまり、対応づけ情報１１２のうち当該或る特定資源に対応する部分は、当該或る特定資源と当該或る特定プロセスを資源監視部１０７が対応づけることにより生成されて、第２の記憶部１０２に記憶された情報である。
【００６９】
以上説明したように、対応づけ情報１１２は、特定資源以外の資源と特定プロセス以外のプロセスとの対応づけをも示すように拡張されてもよい。また、対応づけ情報１１２のうち、特定資源と特定プロセスの対応づけを示す部分は、静的に予め作られていてもよいし、特定プロセスが特定資源を実際にオープンしたときに生成されてもよい。
【００７０】
ところで、制御部１０５は、認識部１０３が認識したプロセスグループに含まれるプロセスの実行を継続させ、当該プロセスグループに含まれないプロセスのうち少なくとも一部を強制終了させてもよい。
【００７１】
プロセスの強制終了により、端末装置１００が備えるメモリの空き容量を増やすことができる。例えば、図１の例において、アプリケーションＡのフォアグラウンドでの実行中に、メモリの空き容量が少なくなったとき、制御部１０５は、認識部１０３が認識したプロセスグループに含まれないプロセスのうちの少なくとも一部を、強制終了させてもよい。
【００７２】
すると、フォアグラウンドで実行中のアプリケーションＡが使用可能なメモリの容量が増える。その結果、アプリケーションＡを使用中のユーザが感じる性能が高まると期待される。
【００７３】
そこで、状況に応じた強制終了を可能とするため、端末装置１００は、メモリ監視部１０８を有してもよい。メモリ監視部１０８は、アプリケーションが使用可能なメモリの空き容量が基準以上であるか否かを監視する。なお、当該基準は、例えば、下記（６ａ）〜（６ｄ）のうちの１つ以上の組み合わせにより定義される基準であってもよいし、他の適宜の基準が使われてもよい。
【００７４】
（６ａ）固定的に決められた閾値
（６ｂ）プロセスから割り当てを要求されたメモリの量そのもの
（６ｃ）上記（６ｂ）の量に、所定の数α１（α１＞１）を掛けた量
（６ｄ）上記（６ｂ）の量に、所定の数α２（α２＞０）を足した量
そして、メモリの空き容量が基準未満であることをメモリ監視部１０８が検出したときに、制御部１０５は、認識部１０３により認識されたプロセスグループに含まれないプロセスの少なくとも一部を、強制終了させてもよい。例えばアプリケーションＡのフォアグラウンドでの実行中に、以上のような強制終了処理が行われる場合、アプリケーションＡとは無関係なプロセスが強制終了される。よって、アプリケーションＡを利用中のユーザは、「応答性能が悪い」とあまり感じないであろう。
【００７５】
以上説明したように、認識部１０３によるプロセスグループの認識と、認識されたプロセスグループに基づく制御部１０５による制御は、高度なプロセス管理を実現する。プロセス管理の適否は、端末装置１００のハードウェアが貧弱な場合は特に、ユーザが感じる性能に与える影響が大きい。したがって、認識部１０３が認識したプロセスグループに基づく制御部１０５による制御は、端末装置１００が貧弱なハードウェアしか持たない場合に特に好適である。
【００７６】
端末装置１００は、例えば、携帯電話、スマートフォン、タブレット端末、ＰＤＡ（Personal Digital Assistant）、ノート型ＰＣ（Personal Computer）、デスクトップ型ＰＣのいずれであってもよい。そして、多くの場合、ＰＣに比べると、携帯電話、スマートフォン、タブレット端末、およびＰＤＡは、消費電力、発熱量、および製造コストなどの様々な制約上、ＣＰＵの性能が劣り、搭載しているメモリの容量も少ない。よって、携帯電話、スマートフォン、タブレット端末、ＰＤＡなどの、ハードウェアが比較的貧弱な端末装置では、ユーザにハードウェアの貧弱さをなるべく感じさせないような制御が実装されることが好ましい。
【００７７】
そして、本実施形態によれば、制御部１０５が行う制御によって適切なプロセス管理がなされる。よって、端末装置１００では、例えば、次の（７ａ）や（７ｂ）などの効果が得られるので、ユーザがハードウェアの貧弱さあまり感じずに済む。つまり、たとえ端末装置１００のハードウェアが貧弱でも、ユーザが感じる性能は、比較的良好である。
【００７８】
（７ａ）フォアグラウンドで実行されているアプリケーションの応答時間が短い
（７ｂ）フォアグラウンドで実行されているアプリケーションがメモリ不足に陥りにくい
また、本実施形態によれば、ユーザが感じる性能は、制御部１０５による制御によって改善される。したがって、個々のアプリケーションの開発者は、「ユーザが感じる性能を悪化させないために、他のアプリケーションとの相互の影響を考慮に入れたチューニングを行う」などの作業をしなくてもよい。すなわち、本実施形態によれば、アプリケーション開発者の設計の自由度が高まる。
【００７９】
さらに、制御部１０５が一時停止制御を行う場合、本実施形態には、消費電力を低減する効果もある。
ところで、図１では、説明の便宜上、プロセスや資源などが英数字で表記されている。しかし、プロセスや資源などを示すのにそれぞれ用いる情報の種類は、実施形態に応じて様々であってよい。
【００８０】
例えば、ある種のＯＳ（Operating System）では、デバイスへのアクセスのインタフェイスを提供するために、スペシャルファイル（「デバイスファイル」とも呼ばれる）が使われる。よって、資源が物理デバイスである場合、当該物理デバイスに対応するスペシャルファイルのファイル名が、資源を識別する資源識別情報として利用されてもよい。
【００８１】
また、資源がデータベースであれば、データベースファイルのファイル名が資源識別情報として利用可能である。そして、資源が所定のファイルであれば、当該所定のファイルのファイル名が資源識別情報として利用可能である。なお、以上の説明における「ファイル名」は、より具体的には、ルートディレクトリからのパスを含む「／ｄｅｖ／ｔｔｙ１」のようなフルパスファイル名であってもよい。
【００８２】
もちろん、ファイル名とは独立に資源を論理的に識別するような情報（便宜上「論理資源識別情報」という）が使われてもよい。例えば、各資源を表す一意な文字列または一意な番号が予め決められていれば、当該文字列または当該番号が論理資源識別情報として使われてもよい。例えば、サウンドデバイスの論理資源識別情報として、「サウンド」という予約文字列が使われてもよい。
【００８３】
また、例えば後述の図７の資源・ファイル対応表５０４ａのように、各資源のファイル名と論理資源識別情報とを対応づける情報がさらに使われてもよい。
また、プロセスは、プロセス名によって表されてもよいし、ＰＩＤによって表されてもよい。たとえプロセスがプロセス名によって表されていても、例えば「ｐｓ」コマンドなどを利用することで、プロセス名からＰＩＤを特定することが可能である。認識部１０３が最終的に認識するプロセスグループは、具体的には、ＰＩＤの集合により表されてもよい。
【００８４】
そして、アプリケーションや、アプリケーションのパッケージに含まれるプログラムは、名前により表すことができる。
また、使用資源情報１１１、対応づけ情報１１２、構成情報１１３および認識結果１１４の具体的なフォーマットも実施形態に応じて様々であってよい。図１に例示したフォーマットは、理解を助けるための一例にすぎない。
【００８５】
例えば、アプリケーションのパッケージが構成情報１１３を含んでいてもよく、パッケージ情報１１３はパッケージから抽出されて第３の記憶部１０４に記憶されてもよい。そして、アプリケーションのパッケージがさらに、アプリケーションが使用する各資源を識別する第１の資源識別情報を含んでもよい。
【００８６】
第１の資源識別情報は、具体的には、上記の論理資源識別情報（例えば、各資源に対して予め決められた一意な文字列など）であってもよい。使用資源情報１１１は、具体的には、アプリケーションのパッケージから抽出される第１の資源識別情報により、アプリケーションが使用する資源の集合を示してもよい。
【００８７】
例えば、アプリケーションのパッケージは、後述の図７のパッケージ情報ＤＢ５０６ａのような形式の情報を含んでもよい。この場合、第１の資源識別情報は、図７の「利用外部資源名リスト」の各要素のように、例えば「サウンド」などの文字列であってもよい。
【００８８】
あるいは、使用資源情報１１１は、端末装置１００が使用可能な各資源を識別するように第１の資源識別情報と対応づけられて決められた第２の資源識別情報により、アプリケーションが使用する資源の集合を示してもよい。第２の資源識別情報は、具体的には、資源のファイル名であってもよい。なお、第１と第２の資源識別情報の対応づけは、例えば、後述の図７の資源・ファイル対応表５０４ａのような情報により定義されていてもよい。
【００８９】
また、対応づけ情報１１２の具体的なフォーマットも実施形態に応じて様々であってよい。対応づけ情報１１２は、特定資源を特定プロセスと対応づけることさえ可能であればどのようなフォーマットであってもよく、物理的には複数のファイルに分けられた情報であってもよい。
【００９０】
例えば、対応づけ情報１１２は、下記（８ａ）〜（８ｃ）の情報を含む情報であってもよい。つまり、下記（８ａ）〜（８ｃ）の情報の対応づけにより特定資源を特定プロセスと対応づける情報が、対応づけ情報１１２として使われてもよい。
【００９１】
（８ａ）特定資源と特定資源以外の資源を区別する第１の区別情報と、特定プロセスと特定プロセス以外のプロセスを区別する第２の区別情報の、一方または双方
（８ｂ）特定資源を表すファイル名と、ファイル名とは独立に特定資源を論理的に識別する論理資源識別情報の、一方または双方
（８ｃ）特定プログラムの実行により特定プロセスが生成されるときに特定プロセスに動的に割り当てられる、特定プロセスに一意のプロセス識別子（例えばＰＩＤ）と、特定プログラムを識別するプログラム識別情報の、一方または双方
なお、上記（８ａ）における第１の区別情報は、例えば、端末装置１００が使用可能な複数の資源に対してそれぞれ０または１に設定されるフラグであってもよい。後述の図７の資源・ファイル対応表５０４ａにおけるフラグは、第１の区別情報の具体例である。
【００９２】
あるいは、第１の区別情報は、特定資源を識別する情報（例えば、特定資源のファイル名、一意に決められた文字列、一意に決められた番号、など）を要素として含むリスト（または他の形式のデータ）であってもよい。つまり、当該リストに識別情報が含まれる資源は特定資源であり、当該設定ファイルに識別情報が含まれない資源は特定資源以外の資源である。したがって、当該リストによれば、特定資源と他の資源を区別することが可能である。
【００９３】
例えば、後述の図７の資源・プロセス名対応表５２０ａにはエントリが１つしか例示されていないが、エントリの数は複数でもよい。そして、資源・プロセス名対応表５２０ａの「外部資源名」の列は、第１の区別情報の具体例でもある。
【００９４】
また、特定プロセスは、具体的には、或る特定プログラムの実行により生成されるプロセスであるから、特定プロセスの名前は、当該特定プログラムの名前である。例えば、サウンドデバイスが特定資源であり、サウンドデバイスを占有するデーモンプログラムが「サウンドデーモン」という名前ならば、特定プロセスのプロセス名も「サウンドデーモン」である。
【００９５】
よって、上記（８ａ）における第２の区別情報は、例えば、特定プロセスの名前のリスト（または他の形式のデータ）であってもよい。つまり、当該リストにプロセス名が含まれるプロセスは特定プロセスであり、当該リストにプロセス名が含まれないプロセスは特定プロセス以外のプロセスである。したがって、当該リストによれば、特定プロセスと他のプロセスを区別することが可能である。
【００９６】
例えば、後述の図７の資源・プロセス名対応表５２０ａのエントリの数は、複数でもよい。そして、資源・プロセス名対応表５２０ａの「プロセス名」の列は、第２の区別情報の具体例でもある。
【００９７】
また、上記（８ｂ）の情報の具体例は、例えば、後述の図７の資源・ファイル対応表５０４ａにおける３番目のエントリ（すなわち、１という値のフラグにより、特定資源に対応することが示されているエントリ）である。上記（８ｂ）の情報の他の具体例は、図７の資源依存関係表５０５ａの３番目のエントリにおける「資源ファイル名」であり、さらに他の具体例は、図７の資源・プロセス名対応表５２０ａの「外部資源名」列である。
【００９８】
そして、上記（８ｃ）のプログラム識別情報は、具体的には特定プログラムの名前である。例えば、特定プログラムの名前が「サウンドデーモン」である場合、上記（８ｃ）の情報の具体例は、後述の図７のプロセス一覧５０７ａにおける、「サウンドデーモン」というプロセス名（すなわちプログラム名）である。また、図７のプロセス一覧５０７ａにおける、「サウンドデーモン」に対応する１０というＰＩＤも、（８ｃ）の情報の具体例である。
【００９９】
以上説明したように、（８ａ）〜（８ｃ）の情報を含む対応づけ情報１１２は、例えば図７に例示するいくつかのテーブルに分散した情報であってもよい。そして、対応づけ情報１１２は、特定資源に対する獲得操作と解放操作の監視に基づいて生成されてもよい。監視は、例えば資源監視部１０７により行われてもよい。
【０１００】
例えば、後述の図７の資源依存関係表５０５ａの少なくとも一部のエントリは、対応づけ情報１１２における上記（８ｂ）と（８ｃ）の対応づけに使われてもよい。そして、資源依存関係表５０５ａは、詳しくは後述するとおり、監視に基づいて動的に書き換えられる。
【０１０１】
あるいは、特定資源と特定プロセスの関係は予め決められているので、監視なしに、対応づけ情報１１２が予め定義されていてもよい。対応づけ情報１１２が予め定義される場合、認識部１０３は、特定プロセスの名前とＰＩＤの対応関係を、例えば「ｐｓ」コマンドなどを用いて認識することで、ＰＩＤにより各プロセスを表したプロセスグループを認識することができる。
【０１０２】
例えば、後述の図７の資源・プロセス名対応表５２０ａは、特定資源と特定プロセスを予め対応づける対応づけ情報１１２の一例である。そして、認識部１０３は、「ｐｓ」コマンドにより図７のプロセス一覧５０７ａを得ることができ、プロセス一覧５０７ａから特定プロセスの名前とＰＩＤの対応関係を認識することができる。
【０１０３】
ところで、以上説明した第１実施形態において、認識部１０３が認識するプロセスグループを形式的に定義すれば、以下のとおりである。
まず、任意のアプリケーションｘに対してプロセスの集合ｄｅｆｉｎｅｄ（ｘ）と資源の集合ｕｓｅｄ（ｘ）を式（１）と（２）のように定義する。
【０１０４】
defined(x)
={p|アプリケーションxのパッケージに含まれると定義されている
プログラムの実行により、プロセスpが生成される}        (1)
used(x)
={r|アプリケーションxが資源rを使うことが定義されている｝  (2)
認識部１０３は、式（１）のプロセスの集合ｄｅｆｉｎｅｄ（ｘ）を、構成情報１１３と「ｐｓ」コマンドに基づいて、認識することができる。また、認識部１０３は、式（２）の資源の集合ｕｓｅｄ（ｘ）を、使用資源情報１１１から認識することができる。
【０１０５】
さらに、任意の資源の集合Ｒに対してプロセスの集合ｓｅｒｖｉｃｅ（Ｒ）を式（３）のように定義する。式（３）は特定プロセスの集合を表す。
service(R)
={p|(r∈R)∧(資源rへのアクセスはプロセスpにより提供される)}  (3)
以上の式（１）〜（３）を用いると、認識部１０３が任意のアプリケーションｘに関して認識するプロセスグループｇｒｏｕｐ（ｘ）は、式（４）のように表現することができる。
【０１０６】
group(x)
=defined(x)∪service(used(x))                             (4)
認識部１０３は、使用資源情報１１１と対応づけ情報１１２を用いて、式（４）におけるｓｅｒｖｉｃｅ（ｕｓｅｄ（ｘ））を認識する。また、図１の例を式（１）〜（４）に代入すると、具体的には式（５）〜（８）が得られる。
【０１０７】
defined(A)={PA1, PA2}                                    (5)
used(A)={R1, R2, R3}                                     (6)
service({R1, R2, R3})={P1, P3}                           (7)
group(A)={PA1, PA2, P1, P3}                              (8)
ところで、より好ましくは、認識部１０３は、アプリケーションｘに関して式（９）のプロセスグループｇｒｏｕｐ（ｘ）を認識するとよい。なぜなら、式（４）で定義されるプロセスグループに属するいずれかのプロセスが、子孫プロセスを生成する可能性があるからである。
【０１０８】
group(x)
=defined(x)∪service(used(x))∪
descendant(defined(x)∪service(used(x)))                 (9)
なお、任意のプロセスの集合Ｐに対して、プロセスの集合ｄｅｓｃｅｎｄａｎｔ（Ｐ）は、式（１０）のとおりであるとする。
【０１０９】
descendant(P)
={q|(p∈P)∧(プロセスqはプロセスpの子孫プロセスである)}  (10)
さて、続いて、図２〜２９を参照して第２実施形態と、第２実施形態に関わるいくつかの変形例について説明する。なお、第２実施形態とその変形例は、ＰＣにも適用可能だが、携帯電話、スマートフォン、タブレット端末、ＰＤＡなどの、ＰＣと比べてハードウェアが比較的貧弱な端末装置に好適である。以下では便宜上、第２実施形態がスマートフォンに適用される場合を例にして説明する。
【０１１０】
図２は、スマートフォンのハードウェア構成図である。図２のスマートフォン２００は、ＣＰＵ２０１、ＲＡＭ（Random Access Memory）２０２、無線ＬＡＮ（Local Area Network）インタフェイス２０３、フラッシュメモリ２０４を有する。また、スマートフォン２００は、ＳＤ（Secure Digital）メモリカード２２０のカードリーダ／ライタ２０５も有する。
【０１１１】
スマートフォン２００はさらに、入力キー２０６、ディスプレイ２０７、マイク２０８、スピーカ２０９、３Ｇ（第３世代）通信機２１０、ＧＰＳ（Global Positioning System）受信機２１１、および加速度センサ２１２を有する。スマートフォン２００内の各部は、バス２１３を介して互いに接続されている。
【０１１２】
ＣＰＵ２０１は、様々なプログラムをＲＡＭ２０２にロードして実行する。また、ＣＰＵ２０１は、ＲＡＭ２０２をワークエリアとしても用いる。
また、ＣＰＵ２０１は、音声出力機能を有してもよい。すなわち、スマートフォン２００が使用するサウンドデバイスが、具体的にはＣＰＵ２０１であってもよい。もちろん、スマートフォン２００は、サウンドデバイスとして、ＣＰＵ２０１とは別のオンボード型サウンドチップを有してもよい。あるいは、サウンドデバイスとしてのサウンドカードがスマートフォン２００に取り付けられていてもよい。
【０１１３】
無線ＬＡＮインタフェイス２０３は、例えば、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１シリーズの規格に則った通信インタフェイスであり、アンテナ、変調器、復調器などを含む。スマートフォン２００は無線ＬＡＮインタフェイス２０３を介してＩＰ（Internet Protocol）ネットワークに接続可能である。
【０１１４】
また、フラッシュメモリ２０４には、様々なプログラムや、その他のデータが記憶される。フラッシュメモリ２０４の代わりに他の種類の不揮発性記憶装置（例えばハードディスク装置）が使われてもよい。
【０１１５】
また、ＳＤメモリカード２２０は、コンピュータ読み取り可能な記憶媒体の一例である。そして、カードリーダ／ライタ２０５は、記憶媒体の駆動装置の一例である。
入力キー２０６は、ユーザからの入力を受け付ける入力装置の一例である。ディスプレイ２０７はタッチスクリーンであってもよい。タッチスクリーンは入力装置でもあり出力装置でもある。また、マイク２０８も入力装置の一例である。スピーカ２０９は出力装置の一例である。
【０１１６】
また、３Ｇ通信機２１０もアンテナ、変調器、復調器などを含む。スマートフォン２００は、３Ｇ通信機２１０を介して３Ｇ通信ネットワークに接続可能である。３Ｇ通信機２１０は、電話機能およびデータ通信機能を提供する。
【０１１７】
ＧＰＳ受信機２１１は、ＧＰＳ衛星からの測位信号を受信して、スマートフォン２００の位置を計算し、出力する。また、加速度センサ２１２は、スマートフォン２００にかかる加速度を感知し、出力する。加速度センサ２１２の出力は、例えば、ディスプレイ２０７の表示方向の切り換えなどにも利用される。スマートフォン２００は、不図示の他のセンサをさらに有してもよいし、不図示のカメラをさらに有してもよい。
【０１１８】
なお、携帯電話、スマートフォン、タブレット端末、ＰＤＡ、ＰＣなど各種の端末装置は、いずれもコンピュータの一種である。携帯電話、タブレット端末、ＰＤＡ、ＰＣなどの端末装置も、図２のスマートフォン２００と同様に、ＣＰＵとＲＡＭと記憶装置と入出力装置を備え、好ましくは、さらに何らかの通信インタフェイスおよび記憶媒体の駆動装置をさらに備える。通信インタフェイスの例は、有線ＬＡＮインタフェイス、無線ＬＡＮインタフェイス、３Ｇ通信機などである。
【０１１９】
また、端末装置の種類によっては、フラッシュメモリ２０４の代わりにハードディスク装置が使われてもよい。そして、ＳＤメモリカード２２０のカードリーダ／ライタ２０５の代わりに、他の種類の記憶媒体の駆動装置が使われてもよい。利用可能な記憶媒体の例は、磁気ディスク、光磁気ディスク、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスク、ＵＳＢ（Universal Serial Bus）メモリなどの半導体メモリなどである。
【０１２０】
なお、ＲＡＭ２０２、フラッシュメモリ２０４、ハードディスク装置なども一種の記憶媒体である。そして、以上例示した種々の記憶媒体は、いずれも有形の（tangible）媒体であり、信号搬送波のような一時的な（transitory）媒体ではない。
【０１２１】
また、ＣＰＵ２０１が実行するプログラムは、予めフラッシュメモリ２０４またはハードディスク装置にインストールされていてもよい。または、プログラムは、ＳＤメモリカード２２０またはその他の記憶媒体に記憶されて提供され、カードリーダ／ライタ２０５または適宜の駆動装置により読み取られて、端末装置にインストールされてもよい。あるいは、プログラムは、無線ＬＡＮインタフェイス２０３または３Ｇ通信機２１０などの通信インタフェイスを介して、ネットワークから端末装置にダウンロードされてもよい。
【０１２２】
続いて、図２に示すハードウェア構成を有するスマートフォン２００に適用される第２実施形態について詳しく説明する。
ここで、第２実施形態の利点についての理解を助けるため、従来の携帯電話および汎用のＰＣと比較しながら、スマートフォンの特徴について説明する。
【０１２３】
従来の携帯電話の組み込みＯＳでは、シングルウィンドウシステムが採用されている。また、従来の携帯電話の組み込みＯＳは、シングルタスクＯＳである。したがって、従来の携帯電話においては、現在アクティブなウィンドウのアプリケーションがＣＰＵを占有し、バックグラウンドで並列に実行されるアプリケーションはない。よって、バックグラウンドのアプリケーションとフォアグラウンドのアプリケーションを調停する必要がそもそもない。また、従来の携帯電話では、ユーザが任意のアプリケーションをインストールすることもない。
【０１２４】
他方、汎用的なＰＣには、ユーザが任意のアプリケーションをインストールすることができる。また、インストールされたアプリケーションは、必ずしもパッケージ管理されているとは限らないので、各アプリケーションに関するメタ情報は必ずしも利用可能ではない。なお、アプリケーションに関するメタ情報の例は、例えば、アプリケーションパッケージに含まれる実行プログラムの名前や、アプリケーションが利用する資源の名前などである。
【０１２５】
そして、汎用的なＰＣ用のＯＳ（「デスクトップＯＳ」ともいう）では、マルチウィンドウシステムが採用されている。また、汎用的なＰＣ用のＯＳは、マルチタスクＯＳである。よって、現在アクティブなウィンドウのアプリケーション以外に、バックグラウンドで他のアプリケーションも実行される状況がしばしば生じる。
【０１２６】
換言すれば、汎用的なＰＣにおいては、「必ずしもメタ情報が利用可能ではない任意の複数のアプリケーションが、並行して実行される」という状況がしばしば起こり得る。しかし、並行してフォアグラウンドとバックグラウンドで複数の任意のアプリケーションが実行される場合、アプリケーション間の優先度を自動的に判定することは困難である。よって、汎用的なＰＣでは、「バックグラウンドのアプリケーションとフォアグラウンドのアプリケーションを優先度に応じて調停することで、優先度の高いアプリケーションにＣＰＵ時間をより多く割り当てる」といった制御は困難である。
【０１２７】
しかしながら、汎用的なＰＣは、携帯電話やスマートフォンなどの端末装置と比べれば、ハードウェアが潤沢である。例えば、スマートフォンと比較すると、汎用的なＰＣでは、搭載されているＣＰＵのクロック周波数がより高く、搭載されているメモリの容量がより多い。
【０１２８】
したがって、たとえ優先度に応じたアプリケーション間の調停が行われなくても、汎用的なＰＣは、ユーザに特段の性能低下を感じさせずに、複数のアプリケーションを並行して実行することが可能である。つまり、汎用的なＰＣでは、バックグラウンドのアプリケーションとフォアグラウンドのアプリケーションを優先度に応じて調停する必要性があまりない。
【０１２９】
それに対して、スマートフォンでは、バックグラウンドのアプリケーションとフォアグラウンドのアプリケーションを優先度に応じて調停することが好ましい。理由は、次のとおりである。
【０１３０】
スマートフォン用の最近のＯＳはマルチタスクＯＳである。よって、複数のアプリケーションが並行して実行され得る。他方で、スマートフォンは、汎用的なＰＣと比べて貧弱なハードウェアしか持たないことが多い。したがって、スマートフォンでは、汎用的なＰＣと同様に複数のアプリケーションが並行して実行された場合、例えば応答時間の長期化などにより、ユーザが不便を感じてしまうことがある。
【０１３１】
そこで、ユーザに感じさせる不便さを低減するために（換言すれば、ユーザが感じる性能を向上させるために）、スマートフォンにおいてはアプリケーション間の調停が有効である。そして、第２実施形態によれば、スマートフォン用のＯＳの特性を利用することで、アプリケーションの調停のためのプロセス制御に有益なプロセスグループが得られる。具体的には、第２実施形態では、次の（９ａ）と（９ｂ）の特性が利用される。
【０１３２】
（９ａ）スマートフォン用のＯＳでは、シングルウィンドウシステムが採用されている。よって、ユーザが現在対話的に利用しているフォアグラウンドのアプリケーションは、一意に特定可能である。
【０１３３】
（９ｂ）スマートフォン用のＯＳは、スマートフォンにインストールされるアプリケーションのパッケージを管理するパッケージ管理モジュールを含む。よって、たとえ任意のアプリケーションがインストールされようとも、どのアプリケーションについても、メタ情報であるパッケージ情報が利用可能である。なお、パッケージ情報は、より具体的には、アプリケーションパッケージに含まれる１つまたは複数のバイナリプログラムを識別する情報と、アプリケーションが直接または間接にアクセスする資源を識別する情報とを含む。
【０１３４】
上記（９ａ）の特性は、優先度の高いアプリケーションの判別のために使われる。そして、（９ｂ）の特性は、アプリケーションに関連するプロセスグループの認識のために使われる。
【０１３５】
続いて、ストリーミング配信される動画を再生する動画再生アプリケーションを例に、「具体的にどのプロセスをプロセスグループのメンバとして認識することが適切なのか」ということに関する方針の概要を説明する。図３は、適切なプロセスグループの例を説明する図である。
【０１３６】
図３の例では、スマートフォン３００が、サーバ３１０と、ＷＡＮ（Wide Area Network）３２０を介して接続されている。ＷＡＮ３２０の代わりに、インターネット、ＬＡＮ、３Ｇ通信ネットワークなど任意のネットワークにより、スマートフォン３００がサーバ３１０と接続されていてもよい。
【０１３７】
スマートフォン３００には動画再生アプリケーション３０１がインストールされている。動画再生アプリケーション３０１は、動画再生モジュール３０２とダウンロードモジュール３０３を含む。なお、図３にはスマートフォン３００のＯＳのカーネル３０４と、ＯＳが提供する標準的なサービス３０５と、サウンドデバイス３０６も図示されている。サウンドデバイス３０６は、具体的には、例えば、サウンド機能を持つＣＰＵ、ＣＰＵとは独立したオンボード型のサウンドチップ、または外付けのサウンドカードであってもよい。
【０１３８】
サーバ３１０は、動画ＤＢ（データベース）３１１を有する。また、サーバ３１０上では、ファイル転送サービス３１２が動作している。ファイル転送サービス３１２は、スマートフォン３００からの要求に応じて、動画ＤＢ３１１から動画ファイル３１３を読み出し、動画ファイル３１３をパケット化する。図３の例では、パケット化された３つの動画断片３３１〜３３３が例示されている。そして、ファイル転送サービス３１２は、ＷＡＮ３２０を介して動画断片３３１〜３３３をスマートフォン３００に送信する。
【０１３９】
スマートフォン３００が、例えばユーザからの指示に応じて動画再生アプリケーション３０１を起動すると、動画再生モジュール３０２がフォアグラウンドで動作し、ダウンロードモジュール３０３がバックグラウンドで動作する。具体的には、ダウンロードモジュール３０３は、サーバ３１０から動画断片３３１〜３３３をダウンロードしてメモリに記憶する。そして、動画再生モジュール３０２は、ダウンロードされてメモリに記憶された動画断片３３１〜３３３を再生する。
【０１４０】
再生は、具体的には、サービス３０５を介して行われる。様々なアプリケーションにより使用され得るサウンドデバイス３０６は、サービス３０５（つまりＯＳにより提供される一種のデーモン）により占有され、サービス３０５を介してのみアクセスされる。一般のアプリケーションは、サウンドデバイス３０６へのアクセス要求をサービス３０５に出力することにより、サービス３０５を介してサウンドデバイス３０６にアクセスする。したがって、動画再生モジュール３０２は、ダウンロードモジュール３０３によりダウンロードされた動画断片３３１〜３３３の画像をディスプレイに描画するとともに、動画断片３３１〜３３３の音声を出力するようサービス３０５に要求する。
【０１４１】
さて、上述のとおり、スマートフォン３００では優先度に基づくアプリケーション間の調停により、ユーザが感じる性能を向上させることが好ましい。そこで、動画再生アプリケーション３０１がフォアグラウンドで実行されるとき（つまり、動画再生モジュール３０２が画像を表示するウィンドウがアクティブのとき）、動画再生アプリケーション３０１に関するプロセスグループの優先度を上げることが好ましい。
【０１４２】
ここで、動画再生アプリケーション３０１のメインタスクは、動画再生モジュール３０２による再生である。しかし、仮に動画再生モジュール３０２の優先度のみを高めても、ダウンロードモジュール３０３の優先度が低ければ、ダウンロードが順調に進行しない。その結果として、動画の再生も順調に進行しない（例えば、あるフレーム画像のところで再生が停止してしまうかもしれない）。また、仮に動画再生モジュール３０２とダウンロードモジュール３０３の優先度のみを高めても、サービス３０５の優先度が低ければ、画像に合わせてタイムリーに音が出力されず、「音が途切れる」などの不具合が生じ得る。
【０１４３】
したがって、動画再生アプリケーション３０１に関するプロセスグループは、下記（１０ａ）のプロセスのみならず、（１０ｂ）と（１０ｃ）のプロセスも含むことが適切である。
【０１４４】
（１０ａ）フォアグラウンドで動作する動画再生モジュール３０２のプロセス。すなわち、動画再生アプリケーション３０１のメインタスクのプロセス。
（１０ｂ）バックグラウンドで動作するダウンロードモジュール３０３のプロセス。すなわち、動画再生アプリケーション３０１のパッケージに同封された、メインタスク以外のバックグラウンドタスクのプロセス。
（１０ｃ）動画再生モジュール３０２がサウンドデバイス３０６という資源を利用するために呼び出すサービス３０５のプロセス。すなわち、動画再生アプリケーション３０１が利用する資源を占有して資源へのアクセスを仲介するプロセス。
【０１４５】
以下に詳しく説明するとおり、第２実施形態によれば、（１０ａ）〜（１０ｃ）を含むプロセスグループが、動画再生アプリケーション３０１に関するプロセスグループとしてスマートフォン３００に認識される。したがってスマートフォン３００は、ユーザが感じる性能を向上させるために、「認識したプロセスグループに属する（１０ａ）〜（１０ｃ）のプロセスの優先度をまとめて高くする」などの適切なプロセス制御を行うことができる。
【０１４６】
さて、続いて、上記（９ｂ）に述べたスマートフォンにおけるアプリケーションパッケージの管理について、より詳しく説明する。図４は、スマートフォンにおけるアプリケーションパッケージの管理を説明する図である。
【０１４７】
図４には、スマートフォン４００と、スマートフォン４００にインストールされるアプリケーションパッケージＣが例示されている。
なお、以下では説明の便宜上、アプリケーション、アプリケーションパッケージ、プログラム、およびプロセスに付した英文字から始まる参照符号は、名前でもあるものとする。例えば、図４のアプリケーションパッケージＣの名前は「Ｃ」である。また、説明の簡単化のため、アプリケーションパッケージの名前はアプリケーションの名前と同じであるとする。
【０１４８】
図４には、スマートフォン４００のＯＳのカーネル４０１が示されている。また、ＯＳに付属して、いくつかの標準的なサービス４０２〜４０５、アプリケーション管理マネジャ４０６、ウィンドウシステム４０７、およびインストーラ４０８が、スマートフォン４００に予めインストールされている。
【０１４９】
スマートフォン４００のハードウェア構成は、例えば図２と同様であってもよい。図４には、スマートフォン４００が有するいくつかの物理デバイスのうち、ＧＰＳ受信機４０９が例示されている。
【０１５０】
サービス４０２〜４０５のそれぞれは、デーモンであってもよい。サービス４０２〜４０５は、アプリケーションに対して標準的なサービスを提供する。例えば、図４の例では、サービス４０４は、アプリケーションに対してＧＰＳ受信機４０９へのアクセスを提供する。
【０１５１】
また、アプリケーション管理マネジャ４０６は、アプリケーションの起動、終了、一時停止、再開などを管理する。また、アプリケーション管理マネジャ４０６は、アプリケーションの状態の変化をウィンドウシステム４０７に通知する。するとウィンドウシステム４０７は、状態の変化に応じて適宜のアプリケーションのウィンドウをスマートフォン４００のディスプレイに描画する。
【０１５２】
インストーラ４０８は、アプリケーションパッケージのインストールを制御する。具体的には、インストーラ４０８は、インストールする対象のアプリケーションパッケージに含まれるバイナリプログラムなどの各種データをファイルシステム４１０の適宜のディレクトリに格納する。また、インストーラ４０８は、インストールする対象のアプリケーションパッケージについてのメタ情報であるパッケージ情報を、パッケージ情報ＤＢ４１１に格納する。
【０１５３】
例えば、図４のアプリケーションパッケージＣは、アプリケーションＣのパッケージであり、具体的には以下の（１１ａ）〜（１１ｅ）を含む。
（１１ａ）フォアグラウンドで実行されるメインプロセス用のバイナリプログラムＣ１
（１１ｂ）バックグラウンドプロセス用のバイナリプログラムＣ２
（１１ｃ）アプリケーションＣに関する各種設定値を規定する設定ファイル４１２
（１１ｄ）「アプリケーションＣがプログラムＣ１とプログラムＣ２を含む」という、アプリケーションＣの構成を示す構成情報４１３
（１１ｅ）「アプリケーションＣはＧＰＳ情報を読み取る」という、アプリケーションＣが依存する資源を示す依存関係情報４１４
【０１５４】
上記（１１ａ）〜（１１ｅ）を含むアプリケーションパッケージＣがインストーラ４０８によりスマートフォン４００にインストールされると、プログラムＣ１、プログラムＣ２、および設定ファイル４１２がファイルシステム４１０内の適宜のディレクトリに格納される。また、パッケージ情報は、具体的には構成情報４１３と依存関係情報４１４を含む情報である。よって、インストーラ４０８は、構成情報４１３と依存関係情報４１４をアプリケーションＣと関連づけてパッケージ情報ＤＢ４１１に格納する。
【０１５５】
そして、スマートフォン４００にアプリケーションＣがインストールされ、アプリケーションＣが起動されると、プログラムＣ１とＣ２が実行される。すなわち、「Ｃ１」という名前のプログラムＣ１の実行により、同じく「Ｃ１」という名前を持つプロセスＣ１が生成され、「Ｃ２」という名前のプログラムＣ２の実行により、「Ｃ２」という名前のプロセスＣ２が生成される。
【０１５６】
また、図４の例では、ＧＰＳ受信機４０９が取得したＧＰＳ情報を読み取る処理は、プロセスＣ２から呼び出される処理である。しかし、図４の例では、プロセスＣ２が直接ＧＰＳ受信機４０９にアクセスしてＧＰＳ情報を読み取るのではなく、サービス４０４がＧＰＳ受信機４０９を占有し、ＧＰＳ受信機４０９へのアクセスはサービス４０４を介して行われる。
【０１５７】
よって、図３の例からも理解されるとおり、図４の例におけるアプリケーションＣに関する適切なプロセスグループは、フォアグラウンドで実行されるプロセスＣ１だけでなく、バックグラウンドで実行されるプロセスＣ２と、サービス４０４のプロセスも含む。ここで、プロセスＣ１とプロセスＣ２は、パッケージ情報ＤＢ４１１に格納された構成情報４１３に示された「Ｃ１」および「Ｃ２」という名前から特定可能である。しかしながら、サービス４０４のプロセスは、パッケージ情報ＤＢ４１１に格納された依存関係情報４１４から直接的に特定することができない。
【０１５８】
その理由の１つは、依存関係情報４１４では資源を論理的に識別する情報が使われているからである。他の理由は、アプリケーションのプロセス（例えばプロセスＣ２）が他のプロセス（例えばサービス４０４のプロセス）を介して資源にアクセスするのか否かに関する情報を、依存関係情報４１４が含まないからである。そして、これら２つの理由についてより詳しく説明すれば、以下のとおりである。
【０１５９】
依存関係情報４１４は、もともと、セキュリティを目的としてアプリケーションパッケージＣに含められる情報である。ユーザが知らないうちにアプリケーションが資源にアクセスすることを防ぐため、依存関係情報４１４は、例えば以下のようにして利用される。
【０１６０】
まず、不図示の入力装置（例えば図２の入力キー２０６またはタッチスクリーン）が、アプリケーションパッケージＣのインストールを指示するユーザからの指示の入力を受け付ける。すると、インストーラ４０８は、依存関係情報４１４を参照する。その結果、インストーラ４０８は、アプリケーションＣがＧＰＳ情報を読み取ることを認識する。
【０１６１】
インストーラ４０８は、認識した結果に基づいて、ユーザに対して、「あなたがインストールしようとしているアプリケーションＣは、ＧＰＳ情報を読み取りますが、アプリケーションＣをインストールしても構いませんか」と尋ねるメッセージを表示する。
【０１６２】
したがって、ＧＰＳ情報を読み取るアプリケーションをインストールしたくないユーザは、インストールの中止を指示することができる。また、ＧＰＳ情報を読み取るアプリケーションをインストールしてもよいと考えるユーザは、インストールの続行を指示することができる。その結果、「ユーザが知らないうちにアプリケーションＣによりＧＰＳ情報が読み取られる」という、セキュリティ上のリスクが予防される。
【０１６３】
以上述べたように、依存関係情報４１４は、セキュリティ目的のアクセス制御情報である。そのため、依存関係情報４１４は、具体的には、アプリケーションが利用する資源と、アプリケーションがその資源に対して行う操作（例えば、「読み取り」、「書き込み」など）を表す。なお、図４の例では、依存関係情報４１４は１つの資源についての情報のみを含むが、複数の資源にアクセスするアプリケーションの依存関係情報では、複数の資源それぞれに関して操作が指定される。
【０１６４】
よって、スマートフォン４００は、パッケージ情報ＤＢ４１１に格納されたパッケージ情報を参照することにより。インストール済みの各アプリケーションについて、どの資源へのアクセスが許可されているのかを認識することができる。しかし、依存関係情報４１４において資源を識別するために使われる情報は、資源を論理的に識別する情報であり、スマートフォン４００において資源を物理的に識別する情報とは異なる。
【０１６５】
例えば、ＧＰＳ受信機４０９は、スマートフォン４００において、特定のパスにある特定のファイル名のデバイスファイルとして抽象化されていてもよい。しかし、依存関係情報４１４においては、スマートフォン４００での実装に依存する物理的な識別情報（例えば、ＧＰＳ受信機４０９のデバイスファイルのフルパスファイル名）は使われない。その代わりに、依存関係情報４１４では、スマートフォン４００での実装に依存しない論理的な識別情報（例えば「ＧＰＳ情報」のような予約文字列など）が使われる。
【０１６６】
さらに、図４の例のように、依存関係情報４１４に示された資源（つまりＧＰＳ受信機４０９）へのアクセスが、アプリケーションＣのプロセスＣ２から直接行われるのではなく、サービス４０４を介して行われることがある。しかし、依存関係情報４１４は、アプリケーションＣがどの資源にどのような種類のアクセス（例えば、「読み取り」、「書き込み」など）を行う可能性があるかを示すだけである。
【０１６７】
つまり、依存関係情報４１４は、アクセスが他のプロセス（例えばサービス４０４のプロセス）を介して行われるか否かに関する情報を含まない。なぜなら、そのような情報を含まなくても、上記のセキュリティ目的は達せられるからである。
【０１６８】
依存関係情報４１４には以上説明したような特徴があるので、スマートフォン４００が依存関係情報４１４から直接的に、「サービス４０４のプロセスは、アプリケーションＣに関するプロセスグループに属する」と認識することは困難である。そこで、第２実施形態では、この困難を克服するため、他の様々な情報が使われる。以下、図５〜１４を参照して、第２実施形態のさらなる詳細について説明する。
【０１６９】
図５は、第２実施形態によるスマートフォンのブロック構成図である。なお、図５に示す各種データの詳細は図７とともに後述し、図５に示す各種処理部の動作の詳細は図８〜１４とともに後述する。
【０１７０】
図５に示すスマートフォン５００は、アプリケーションに関連するプロセスグループを判定するプロセスグループ判定部５０１を有する。プロセスグループ判定部５０１が判定したプロセスグループは、プロセスグループメンバ表５０２に記録される。また、スマートフォン５００は、プロセスグループメンバ表５０２を参照して適宜のプロセス制御を行うプロセス制御モジュール５０３を有する。
【０１７１】
プロセスグループ判定部５０１は、資源・ファイル対応表５０４、資源依存関係表５０５、パッケージ情報ＤＢ５０６、およびプロセス一覧５０７を参照することにより、プロセス管理の管理単位として適切なプロセスグループを判定することができる。
【０１７２】
詳しくは後述するが、資源・ファイル対応表５０４には予めデータが設定される。また、パッケージ情報ＤＢ５０６は、図４のパッケージ情報ＤＢ４１１と同様であり、アプリケーションパッケージのインストールとアンインストールのたびに書き換えられる。資源依存関係表５０５とプロセス一覧５０７は、スマートフォン５００の動作に応じて変化する。
【０１７３】
具体的には、スマートフォン５００はさらに依存関係管理部５０８とプローブ５０９を有する。そして、プローブ５０９はプロセスによる資源の獲得と解放を監視し、監視結果を依存関係管理部５０８に通知する。すると、依存関係管理部５０８は、プローブ５０９からの通知に応じて、資源依存関係表５０５を動的に書き換える。また、プロセス一覧５０７は、スマートフォン５００において動作中のプロセスの一覧であるから、当然、取得されるタイミングに応じて内容が異なる。
【０１７４】
スマートフォン５００は、さらに、ユーザからの入力を受け付ける入力部５１０を有する。入力部５１０は、例えば図２の入力キー２０６、タッチスクリーン、またはその組み合わせである。
【０１７５】
また、スマートフォン５００は、図４のアプリケーション管理マネジャ４０６と同様にアプリケーションの起動、終了、一時停止、再開などを管理するアプリケーション管理マネジャ５１１も有する。より詳しくは、アプリケーション管理マネジャ５１１は、図５に示すように、アプリケーションの切り替えが起きたときに切り替えイベントの発生を他のモジュールに通知する切り替えイベント通知部５１２を含む。
【０１７６】
また、図５には、スマートフォン５００のＯＳのカーネル５１３と、カーネル５１３内のデバイスドライバ５１４も図示されている。第２実施形態では、上記プローブ５０９もカーネル５１３内に実装される。
【０１７７】
さらに、スマートフォン５００は、いくつかの物理デバイス５１５を有する。物理デバイス５１５は資源の具体例である。なお、図５では便宜上、物理デバイス５１５のブロックは１つだけ示してある。
【０１７８】
物理デバイス５１５へのインタフェイスを実現するために、スマートフォン５００のＯＳでは、物理デバイス５１５を資源ファイル５１６（つまり「スペシャルファイル」または「デバイスファイル」と呼ばれるファイル）に抽象化する技法が採用されている。図５では便宜上、資源ファイル５１６のブロックが１つだけ示されているが、複数の物理デバイス５１５にそれぞれ対応する複数の資源ファイル５１６があってもよい。
【０１７９】
また、図５にはスマートフォン５００が実行するプロセス５１７も図示されている。図５では便宜上、プロセス５１７のブロックは１つだけ示してあるが、スマートフォン５００は複数のプロセス５１７を実行する。また、プロセス５１７は、ユーザアプリケーションのプロセスでもよいし、ＯＳに付属するサービス等のプロセスでもよい。
【０１８０】
なお、第２実施形態では、プロセス５１７から物理デバイス５１５へのアクセスは、具体的には、資源ファイル５１６に対するシステムコールにより実現される。よって、プローブ５０９は、資源ファイル５１６に対するシステムコールを監視することで、資源（つまり物理デバイス５１５）の獲得と解放を監視する。なお、スマートフォン５００は、プローブ５０９が監視する対象の資源ファイル５１６のリストを予め監視対象資源ファイルリスト５１８として記憶している。
【０１８１】
続いて、図６を参照して、アプリケーションパッケージと資源とプロセスの具体例を説明する。
図６のスマートフォン６００は、図５のスマートフォン５００と同様の構成要素を含むが、図６では、図５に示す構成要素の一部が省略され、一部がより具体化されている。
【０１８２】
すなわち、スマートフォン６００は、図５の物理デバイス５１５の具体例として、ＧＰＳ受信機６０１と加速度センサ６０２とサウンドデバイス６０３とディスプレイ６０４を有する。また、以下では説明の便宜上、サウンドデバイス６０３は、特定プロセスによってアクセスが占有される特定資源であるものと仮定し、他の３つの物理デバイスは、特定資源ではないものと仮定する。
【０１８３】
また、スマートフォン６００は、ファイルシステム６０５とパッケージ情報ＤＢ６０６を含む。図５ではファイルシステムが省略されているが、図６のファイルシステム６０５は、図４のファイルシステム４１０と同様である。また、パッケージ情報ＤＢ６０６は、図４のパッケージ情報ＤＢ４１１および図５のパッケージ情報ＤＢ５０６に相当する。
【０１８４】
また、スマートフォン６００は、ＯＳのカーネル６０７と、デバイスドライバ６０８を含む。カーネル６０７は図４のカーネル４０１および図５のカーネル５１３に相当し、デバイスドライバ６０８は図５のデバイスドライバ５１４に相当する。
【０１８５】
そして、スマートフォン６００は、図５の資源ファイル５１６の具体例として、資源ファイル６０９〜６１２を含む。図６では説明の便宜上、資源ファイル６０９〜６１２のブロックの中にそれぞれのフルパスファイル名が書かれている。以下では説明の簡単化のため、フルパスファイル名を単に「ファイル名」ともいう。
【０１８６】
具体的には、ＧＰＳ受信機６０１に対応する資源ファイル６０９のファイル名は「／ｄｅｖ／ｔｔｙ１」である。また、加速度センサ６０２に対応する資源ファイル６１０のファイル名は「／ｄｅｖ／ｔｔｙ２」である。そして、サウンドデバイス６０３に対応する資源ファイル６１１のファイル名は「／ｄｅｖ／ｓｎｄ」である。また、ディスプレイ６０４に対応する資源ファイル６１２のファイル名は「／ｄｅｖ／ｆｂ」である。
【０１８７】
また、図６には、図５のプロセス５１７の具体例として、ＯＳにより提供される標準的ないくつかのプログラムのプロセスと、ユーザからの指示に基づいてインストールされたアプリケーションのプロセスが例示されている。具体的には、図６には、ロケーションマネジャ６１３、サウンドデーモン６１４、ウィンドウシステム６１５、アプリケーション管理マネジャ６１６、およびインストーラ６１７それぞれのプロセスが例示されている。さらに、図６には、インストーラ６１７によりスマートフォン６００にインストールされたアプリケーションＤとＥの実行により生成されるプロセスＤ１、Ｄ２、Ｅ１およびＥ２も例示されている。
【０１８８】
なお、ロケーションマネジャ６１３は、ＧＰＳ受信機６０１に対応する資源ファイル６０９を参照することで、スマートフォン６００の位置に関する情報を得る。そして、ロケーションマネジャ６１３は、任意のアプリケーションに対して位置情報を提供する。図６の例では、ロケーションマネジャ６１３のプロセスのＰＩＤは５である。なお、資源ファイル６０９には、ロケーションマネジャ６１３以外のアプリケーションのプロセスもアクセス可能である。
【０１８９】
また、サウンドデーモン６１４は、サウンドデバイス６０３に対応する資源ファイル６１１へのアクセスを独占する。他のプログラムのプロセスは、サウンドデーモン６１４のプロセスに対してサウンドデバイス６０３へのアクセスを要求し、サウンドデーモン６１４が要求に応じて資源ファイル６１１を操作する。すなわち、図６の例では、サウンドデバイス６０３は特定資源であり、サウンドデーモン６１４のプロセスは特定プロセスである。また、図６の例では、サウンドデバイス６０３のプロセスのＰＩＤは１０である。
【０１９０】
ウィンドウシステム６１５は図４のウィンドウシステム４０７と同様である。ウィンドウシステム６１５は、ディスプレイ６０４に対応する資源ファイル６１２を操作することで、ウィンドウの描画を制御する。図６の例では、ウィンドウシステム６１５のプロセスのＰＩＤは２０である。
【０１９１】
アプリケーション管理マネジャ６１６は、図４のアプリケーション管理マネジャ４０６および図５のアプリケーション管理マネジャ５１１に対応し、アプリケーションの起動、終了、一時停止、再開などを管理する。図６では省略されているが、図５と同様に、アプリケーション管理マネジャ６１６は切り替えイベント通知部５１２を含む。なお、図６の例では、アプリケーション管理マネジャ６１６のプロセスのＰＩＤは３０である。
【０１９２】
インストーラ６１７は、図４のインストーラ４０８に相当する。スマートフォン６００へのアプリケーションパッケージのインストールは、インストーラ６１７を介して行われる。そして、アプリケーションパッケージに含まれるバイナリプログラムと設定ファイルは、ファイルシステム６０５に格納され、アプリケーションパッケージに含まれるパッケージ情報はパッケージ情報ＤＢ６０６に格納される。図６の例では、インストーラ６１７のプロセスのＰＩＤは４０である。
【０１９３】
また、図６には２つのアプリケーションパッケージＤとＥが例示されている。そして、図６は、インストールされたアプリケーションＤとＥが実行されている状態を示す。
具体的には、アプリケーションパッケージＤは、プログラムＤ１とＤ２と依存関係情報６１８と構成情報６１９を含む。依存関係情報６１８は、アプリケーションＤが加速度センサ６０２を利用することを示す。また、構成情報６１９は、アプリケーションパッケージＤがプログラムＤ１とＤ２を含むことを示す。
【０１９４】
また、アプリケーションパッケージＥは、プログラムＥ１とＥ２と依存関係情報６２０と構成情報６２１を含む。依存関係情報６２０は、アプリケーションＥがサウンドデバイス６０３を利用することを示す。また、構成情報６２１はアプリケーションパッケージＥがプログラムＥ１とＥ２を含むことを示す。
【０１９５】
そして、スマートフォン６００にインストールされたアプリケーションＤが起動されると、具体的にはプログラムＤ１の実行によりプロセスＤ１が生成され、プログラムＤ２の実行によりプロセスＤ２が生成される。図６の例では、プロセスＤ１のＰＩＤは１００１であり、プロセスＤ２のＰＩＤは１０１１である。
【０１９６】
また、アプリケーションＤがフォアグラウンドアプリケーションであるとき、プロセスＤ１は、フォアグラウンドで動作する。つまり、アプリケーションＤのウィンドウ表示に関する命令をウィンドウシステム６１５のプロセスに送信するプロセスは、プロセスＤ１である。
【０１９７】
他方、プロセスＤ２はバックグラウンドプロセスである。なお、依存関係情報６１８が示すように、アプリケーションＤは加速度センサ６０２を利用する。図６の例では、具体的には、プロセスＤ２が、加速度センサ６０２に対応する資源ファイル６１０に対して、オープン操作、リード操作、クローズ操作などの操作をすることで、アプリケーションＤからの加速度センサ６０２へのアクセスが実現される。
【０１９８】
また、スマートフォン６００にインストールされたアプリケーションＥが起動されると、具体的にはプログラムＥ１の実行によりプロセスＥ１が生成され、プログラムＥ２の実行によりプロセスＥ２が生成される。図６の例では、プロセスＥ１のＰＩＤは１００２であり、プロセスＥ２のＰＩＤは１０１２である。
【０１９９】
また、アプリケーションＥがフォアグラウンドアプリケーションであるとき、プロセスＥ１は、フォアグラウンドで動作する。つまり、アプリケーションＥのウィンドウ表示に関する命令をウィンドウシステム６１５のプロセスに送信するプロセスは、プロセスＥ１である。
【０２００】
他方、プロセスＥ２はバックグラウンドプロセスである。なお、依存関係情報６２０が示すように、アプリケーションＥはサウンドデバイス６０３を利用する。図６の例では、具体的には、プロセスＥ２がサウンドデバイス６０３を利用するための処理を行う。ただし、図６の例では、特定資源であるサウンドデバイス６０３へのアクセスは、特定プロセスであるサウンドデーモン６１４のプロセスにより占有される。
【０２０１】
したがって、プロセスＥ２は、具体的には、サウンドデバイス６０３に音声を出力させるための指示を、サウンドデーモン６１４のプロセスに送信する。すると、サウンドデーモン６１４のプロセスが、プロセスＥからの指示にしたがって、サウンドデバイス６０３にアクセスする（より具体的には、例えば、「ライト」システムコールを呼び出す）。その結果、サウンドデバイス６０３が音声を出力する。
【０２０２】
図７は、各種データの具体例を説明する図である。なお、図７の各種データの例は、図６の例に対応する。
図７には、図５に示したプロセスグループメンバ表５０２、資源・ファイル対応表５０４、資源依存関係表５０５、パッケージ情報ＤＢ５０６、プロセス一覧５０７、および監視対象資源ファイルリスト５１８の具体例が例示されている。図７にはさらに、後述の変形例で使われる資源・プロセス名対応表５２０、アプリケーション利用時刻表５２９、および強制終了除外プロセスリスト５３０の具体例も例示されている。変形例で使われるデータについては、後述することにし、ここでは説明を省略する。
【０２０３】
さて、図７に例示されるプロセスグループメンバ表５０２ａにおける各エントリは、アプリケーション名と、アプリケーション名により識別されるアプリケーションに関連するプロセスグループの各メンバのＰＩＤを要素とするＰＩＤリストとを対応づける。
【０２０４】
１つ目のエントリによれば、アプリケーションＤのプロセスグループは、ＰＩＤが１００１のプロセス（つまり図６のプロセスＤ１）と、ＰＩＤが１０１１のプロセス（つまり図６のプロセスＤ２）を含む。
【０２０５】
また、２つ目のエントリによれば、アプリケーションＥのプロセスグループは、ＰＩＤが１００２のプロセス（つまり図６のプロセスＥ１）と、ＰＩＤが１０１２のプロセス（つまり図６のプロセスＥ２）を含む。アプリケーションＥのプロセスグループはさらに、ＰＩＤが１０のプロセス（つまり図６のサウンドデーモン６１４のプロセス）も含む。なぜなら、アプリケーションＥが利用するサウンドデバイス６０３は特定資源であり、サウンドデバイス６０３に対応する特定プロセスはサウンドデーモン６１４のプロセスだからである。
【０２０６】
また、図７に例示される資源・ファイル対応表５０４ａにおける各エントリは、スマートフォン５００において利用可能な個々の資源に対応する。第２実施形態における資源は、具体的には物理デバイス５１５であるが、もちろん、スマートフォン５００が備える不図示のデータベースまたはスマートフォン５００が記憶する所定のファイルが資源として使われてもよい。
【０２０７】
資源・ファイル対応表５０４ａの各エントリは、フラグと外部資源名と資源ファイル名を含む。
フラグは、当該エントリに対応する資源が特定資源であるか否かを示す。図７の例では、フラグの値が１のエントリは特定資源に対応し、フラグの値が０のエントリは特定資源以外の資源に対応する。
【０２０８】
また、外部資源名は、当該エントリに対応する資源を論理的に識別する識別情報であり、具体的には、アプリケーションパッケージの依存関係情報において資源を論理的に識別するのに使われる名前である。
【０２０９】
資源ファイル名は、当該エントリに対応する資源へのインタフェイスたる資源ファイル５１６の、フルパスファイル名である。
例えば、１番目のエントリによれば、「ＧＰＳ」という名前で論理的に識別される資源（つまり図６のＧＰＳ受信機６０１）に対応する資源ファイル６０９のフルパスファイル名は「／ｄｅｖ／ｔｔｙ１」である。そして、当該資源へのアクセスは特定プロセスからのアクセスに限定されるわけではないのでフラグの値は０である。
【０２１０】
また、２番目のエントリによれば、「加速度センサ」という名前で論理的に識別される資源（つまり図６の加速度センサ６０２）に対応する資源ファイル６１０のフルパスファイル名は「／ｄｅｖ／ｔｔｙ２」である。そして、当該資源へのアクセスは特定プロセスからのアクセスに限定されるわけではないのでフラグの値は０である。
【０２１１】
また、３番目のエントリによれば、「サウンド」という名前で論理的に識別される資源（つまり図６のサウンドデバイス６０３）に対応する資源ファイル６１１のフルパスファイル名は「／ｄｅｖ／ｓｎｄ」である。そして、当該資源へのアクセスは特定プロセス（つまり図６のサウンドデーモン６１４のプロセス）からのアクセスに限定されるのでフラグの値は１である。
【０２１２】
さて、図７に例示される資源依存関係表５０５ａの各エントリは、資源ファイル名と、当該資源ファイル名に対応する資源を確保中のプロセスのＰＩＤとを対応づける。
例えば、１番目のエントリによれば、フルパスファイル名が「／ｄｅｖ／ｔｔｙ１」の資源ファイルによりインタフェイスが提供される資源は、現在、ＰＩＤが５のプロセスによりオープンされており、ＰＩＤが５のプロセスにより確保されている。つまり、１番目のエントリは、「ＧＰＳ受信機６０１が現在ロケーションマネジャ６１３のプロセスにより確保されている」という、図６の状況を表す。
【０２１３】
また、２番目のエントリによれば、フルパスファイル名が「／ｄｅｖ／ｔｔｙ２」の資源ファイルによりインタフェイスが提供される資源は、現在、ＰＩＤが１０１１のプロセスによりオープンされており、ＰＩＤが１０１１のプロセスにより確保されている。つまり、２番目のエントリは、「加速度センサ６０２が現在プロセスＤ２により確保されている」という、図６の状況を表す。
【０２１４】
そして、３番目のエントリによれば、フルパスファイル名が「／ｄｅｖ／ｓｎｄ」の資源ファイルによりインタフェイスが提供される資源は、現在、ＰＩＤが１０プロセスによりオープンされており、ＰＩＤが１０のプロセスにより確保されている。つまり、３番目のエントリは、「サウンドデバイス６０３が現在サウンドデーモン６１４のプロセスにより確保されている」という、図６の状況を表す。
【０２１５】
また、図７に例示されるパッケージ情報ＤＢ５０６ａの各エントリは、アプリケーションに対応する。各エントリは、アプリケーション名と、プログラム名リストと、利用外部資源名リストを含む。アプリケーション名は、当該エントリに対応するアプリケーションの名前である。また、プログラム名リストは、当該アプリケーション名で識別されるアプリケーションパッケージに含まれるバイナリプログラムの名前のリストである。そして、利用外部資源名リストは、当該アプリケーション名で識別されるアプリケーションパッケージからアクセスされる可能性のある資源を論理的に識別する識別情報のリストである。換言すれば、利用外部資源名リストは、アプリケーションパッケージのインストール時に、ユーザによりアクセスが容認された資源を論理的に識別する識別情報のリストである。
【０２１６】
例えば、１番目のエントリによれば、アプリケーションＤはプログラムＤ１とプログラムＤ２を含み、アプリケーションＤからは、「加速度センサ」という名前で論理的に識別される資源がアクセスされる可能性がある。つまり、１番目のエントリは、図６のアプリケーションパッケージＤがインストールされるときに、依存関係情報６１８と構成情報６１９に基づいて生成される。
【０２１７】
また、２番目のエントリによれば、アプリケーションＥはプログラムＥ１とプログラムＥ２を含み、アプリケーションＥからは、「サウンド」という名前で論理的に識別される資源がアクセスされる可能性がある。つまり、２番目のエントリは、図６のアプリケーションパッケージＥがインストールされるときに、依存関係情報６２０と構成情報６２１に基づいて生成される。
【０２１８】
また、図７に例示されるプロセス一覧５０７ａの各エントリは、動作中のプロセスに対応し、当該プロセスのＰＩＤとプロセス名を含む。図７のプロセス一覧５０７ａは、図６に例示した９つのプロセスと、スマートフォンの起動中は常に存在する「ｉｎｉｔ」プロセスにそれぞれ対応するエントリを含む。なお、図７に示すように、「ｉｎｉｔ」プロセスのＰＩＤは１である。
【０２１９】
そして、図７に例示される監視対象資源ファイルリスト５１８ａは、プローブ５０９による監視の対象を定義するためのリストであり、具体的には、監視対象の資源ファイル５１６のフルパスファイル名のリストである。
【０２２０】
図６の例によれば、スマートフォン６００はＧＰＳ受信機６０１、加速度センサ６０２、サウンドデバイス６０３、およびディスプレイ６０４という資源を有する。ただし、以下ではディスプレイ６０４は監視の対象ではないものとする。よって、監視対象資源ファイルリスト５１８ａは、ＧＰＳ受信機６０１に対応する資源ファイル６０９と、加速度センサ６０２に対応する資源ファイル６１０と、サウンドデバイス６０３に対応する資源ファイル６１１の、フルパスファイル名のリストである。
【０２２１】
続いて、以上のとおり図６〜７に示した具体例も参照しながら、図５のスマートフォン５００の各部の動作について、図８〜１４のフローチャートを参照して説明する。
【０２２２】
図８は、第２実施形態において切り替えイベント通知部５１２を含むアプリケーション管理マネジャ５１１が行う処理のフローチャートである。図８の処理は、スマートフォン５００が起動されると開始される。
【０２２３】
ステップＳ１０１でアプリケーション管理マネジャ５１１は、アプリケーションの管理に関わるイベントの発生を待つ。そして、イベントが発生すると、処理はステップＳ１０２に移行する。なお、イベントは、例えばユーザからの入力を入力部５１０が受け取ったときなどに発生する。
【０２２４】
さて、ステップＳ１０２でアプリケーション管理マネジャ５１１は、ステップＳ１０１で検出したイベントに応じた、通常のアプリケーション管理処理を実行する。つまり、イベントの種類に応じて、アプリケーション管理マネジャ５１１は、例えば以下の（１２ａ）〜（１２ｇ）の処理のうち１つ以上を適宜行う。
【０２２５】
（１２ａ）新たなアプリケーションを起動する。
（１２ｂ）今までフォアグラウンドで実行していたアプリケーションを終了する。
（１２ｃ）今までフォアグラウンドで実行していたアプリケーションをバックグラウンドに遷移させる。
（１２ｄ）今までフォアグラウンドで実行していたアプリケーションを一時停止させる。
（１２ｅ）今までバックグラウンドで実行していたアプリケーションをフォアグラウンドに遷移させる。
（１２ｆ）今まで一時停止していたアプリケーションを再開する。
（１２ｇ）ウィンドウシステムに対してウィンドウの表示方向の切り替えを命令する。
【０２２６】
そして、ステップＳ１０２の実行後、処理はステップＳ１０３に移行する。すると、ステップＳ１０３で切り替えイベント通知部５１２は、発生したイベントの種類を判定する。そして、発生したイベントが、アプリケーションを切り替えるイベント（すなわち、画面の切り替えをともなうイベント）である場合、処理はステップＳ１０４に移行する。
【０２２７】
例えば、何もアプリケーションが起動されていないときに、新たなアプリケーションを起動するイベントが発生すると、処理はステップＳ１０４に移行する。同様に、既に起動されているアプリケーションがあるときに、他のアプリケーションを起動することによってフォアグラウンドのアプリケーションを切り替えるイベントが発生すると、やはり処理はステップＳ１０４に移行する。また、現在フォアグラウンドで実行中のアプリケーションに対して明示的な終了指示が入力された場合も、一種のアプリケーションの切り替えが生じるので、処理はステップＳ１０４へ移行する。
【０２２８】
逆に、発生したイベントが、その他の種類のイベントである場合、処理はステップＳ１０１に戻る。例えば、ユーザがスマートフォン５００の向きを縦から横に変えたとき、ウィンドウの表示方向を切り替えるイベントが発生する。しかし、この場合は、ウィンドウに表示されるコンテンツ自体は変わらないし、当然アプリケーションの切り替えも発生しない。したがって、処理はステップＳ１０４からステップＳ１０１へと戻る。
【０２２９】
ステップＳ１０４で切り替えイベント通知部５１２は、アプリケーションの切り替えの発生をプロセスグループ判定部５０１とプロセス制御モジュール５０３に通知する。そして、処理はステップＳ１０１に戻る。
【０２３０】
なお、ステップＳ１０４での通知を受けたプロセスグループ判定部５０１の動作の詳細は図１１とともに後述する。また、ステップＳ１０４での通知を受けたプロセス制御モジュール５０３の動作の詳細は、図１２〜１４とともに後述する。
【０２３１】
続いて、図９のフローチャートを参照して、第２実施形態においてプローブ５０９が行う処理について説明する。図９の処理は、スマートフォン５００が起動されると開始される。
【０２３２】
ステップＳ２０１でプローブ５０９は、監視対象資源ファイルリスト５１８を読み取り、監視対象の資源に対応する資源ファイル５１６を認識する。そして、プローブ５０９は、監視対象資源ファイルリスト５１８で指定される各資源（つまり、監視対象資源ファイルリスト５１８中にファイル名のある資源ファイル５１６に対応する各物理デバイス５１５）に対するシステムコールの監視を開始する。図６と図７の例では、監視対象の資源は資源ファイル６０９〜６１１に対応するＧＰＳ受信機６０１、加速度センサ６０２およびサウンドデバイス６０３である。
【０２３３】
そして、次のステップＳ２０２でプローブ５０９は、監視対象の資源に対応する資源ファイル５１６に対するシステムコールの呼び出しを待つ。そして、システムコールの呼び出しがあると、処理はステップＳ２０３に移行する。
【０２３４】
ステップＳ２０３でプローブ５０９は、システムコールの種類を判定する。システムコールの種類が、資源獲得のための「オープン」または資源解放のための「クローズ」である場合、処理はステップＳ２０４に移行する。他の種類（例えば「リード」や「ライト」など）のシステムコールの場合、処理はステップＳ２０５に移行する。
【０２３５】
そして、ステップＳ２０４でプローブ５０９は、依存関係管理部５０８に、操作内容、操作対象、および呼び出し元ＰＩＤを通知する。操作内容は、具体的にはシステムコールの種類であり、操作対象は資源ファイル５１６のファイル名により表される。
【０２３６】
例えば、ＰＩＤが１０１１のプロセスＤ２から、資源ファイル６１０に対する「オープン」システムコールが呼び出されたとする。図７の監視対象資源ファイルリスト５１８ａによれば、図６の資源ファイル６１０は監視対象である。よって、この場合、プローブ５０９はステップ２０４において、操作内容が「オープン」操作であること、操作対象が「／ｄｅｖ／ｔｔｙ２」であること、および、呼び出し元ＰＩＤが１０１１であることを、依存関係管理部５０８に通知する。
【０２３７】
ステップＳ２０４での通知の後、処理はステップＳ２０５に移行する。すると、ステップＳ２０５でプローブ５０９は、ステップＳ２０２で検出したシステムコールを呼び出す。その結果、システムコールが実行される。そして、処理はステップＳ２０２に戻る。
【０２３８】
例えば、ステップＳ２０２で、プロセスＤ２からの資源ファイル６１０に対する「オープン」システムコールの呼び出しが検出された場合、ステップＳ２０５では、資源ファイル６１０に対する「オープン」システムコールが実行される。つまり、カーネル５１３により資源ファイル６１０がオープンされる。
【０２３９】
なお、カーネル５１３は、資源ファイル６１０に対する「オープン」操作が成功したことを示す返り値をプローブ５０９に返してもよい。プローブ５０９は、ステップＳ２０５においてさらに、カーネル５１３からの返り値をシステムコールの本来の呼び出し元のプロセスに返してもよい。あるいは、カーネル５１３は、システムコールの本来の呼び出し元のプロセスに、直接、返り値を返してもよい。
【０２４０】
以上の図９の処理によれば、監視対象資源ファイルリスト５１８にファイル名が含まれるいずれかの資源ファイル５１６に対する「オープン」または「クローズ」システムコールが呼び出されるたびに、プローブ５０９から依存関係管理部５０８への通知がなされる。なお、プローブ５０９による監視対象ではない資源（例えば、図６と図７の例ではディスプレイ６０４）に対するシステムコールに応じて、カーネル５１３が適宜の処理を実行することは無論である。
【０２４１】
図１０は、第２実施形態において依存関係管理部５０８が行う処理のフローチャートである。図１０の処理も、スマートフォン５００が起動されると開始される。
ステップＳ３０１で依存関係管理部５０８は、プローブ５０９からの通知を待つ。そして、依存関係管理部５０８がプローブ５０９から通知を受けると、処理はステップＳ３０２に移行する。
【０２４２】
ステップＳ３０２で依存関係管理部５０８は、プローブ５０９から通知されたイベントの種類（すなわち、プローブ５０９が検出したシステムコールの種類）を判定する。なお、図９とともに説明したとおり、プローブ５０９が依存関係管理部５０８に通知するのは、監視対象の資源ファイル５１６に対する「オープン」または「クローズ」システムコールの発生のみである。
【０２４３】
プローブ５０９から通知されたイベントの種類が資源の獲得である場合（すなわち、通知された操作内容が「オープン」操作である場合）、処理はステップＳ３０３に移行する。逆に、プローブ５０９から通知されたイベントの種類が資源の解放である場合（すなわち、通知された操作内容が「クローズ」操作である場合）、処理はステップＳ３０４に移行する。
【０２４４】
ステップＳ３０３で依存関係管理部５０８は、資源依存関係表５０５において、オープンされた資源ファイル５１６に対応づけてＰＩＤを書き込む。書き込みの後、処理はステップＳ３０１に戻る。
【０２４５】
例えば、プローブ５０９から通知された呼び出し元ＰＩＤが５であり、プローブ５０９から通知された操作対象が「／ｄｅｖ／ｔｔｙ１」であるとする。この場合、ステップＳ３０３で依存関係管理部５０８は、資源依存関係表５０５において資源ファイル名が「／ｄｅｖ／ｔｔｙ１」のエントリを検索し、見つかったエントリのＰＩＤフィールドに、プローブ５０９から通知された５というＰＩＤを書き込む。
【０２４６】
また、ステップＳ３０４で依存関係管理部５０８は、資源依存関係表５０５において、クローズされた資源ファイル５１６に対応するＰＩＤを消去する。消去の後、処理はステップＳ３０１に戻る。
【０２４７】
例えば、プローブ５０９から通知された呼び出し元ＰＩＤが１０１１であり、プローブ５０９から通知された操作対象が「／ｄｅｖ／ｔｔｙ２」であるとする。この場合、ステップＳ３０４で依存関係管理部５０８は、資源依存関係表５０５において資源ファイル名が「／ｄｅｖ／ｔｔｙ２」のエントリを検索し、見つかったエントリのＰＩＤフィールドをクリアする。
【０２４８】
以上説明した図９〜１０の処理により、監視対象資源ファイルリスト５１８に指定されたいずれかの資源ファイル５１６がオープンまたはクローズされるたびに、資源依存関係表５０５が動的に書き換えられる。
【０２４９】
なお、上記では説明を省略したが、資源依存関係表５０５は、監視対象資源ファイルリスト５１８に合わせて初期化される。例えば、スマートフォン５００が起動されたときに、依存関係管理部５０８が監視対象資源ファイルリスト５１８を参照して資源依存関係表５０５を初期化してもよい。
【０２５０】
初期状態の資源依存関係表５０５は、監視対象資源ファイルリスト５１８に含まれる各資源ファイル名に対応するエントリを有し、各エントリのＰＩＤフィールドはクリアされた状態である。例えば、図７の監視対象資源ファイルリスト５１８ａには「／ｄｅｖ／ｔｔｙ１」と「／ｄｅｖ／ｔｔｙ２」と「／ｄｅｖ／ｓｎｄ」という３つの資源ファイル名が含まれるので、資源依存関係表５０５はこれら３つの資源ファイル名に対応する３つのエントリを持つように初期化され、各エントリのＰＩＤフィールドはクリアされる。
【０２５１】
さて、図１１は、第２実施形態においてプロセスグループ判定部５０１が行う処理のフローチャートである。図１１の処理も、スマートフォン５００が起動すると開始される。
ステップＳ４０１でプロセスグループ判定部５０１は、アプリケーションの状態変化イベントが切り替えイベント通知部５１２から通知されるまで待つ。すなわち、図８のステップＳ１０４で切り替えイベント通知部５１２が通知を出すまで、プロセスグループ判定部５０１はステップＳ４０１で待機する。
【０２５２】
そして、アプリケーションを新たに起動するイベントが通知された場合、処理はステップＳ４０２に移行する。逆に、アプリケーションを停止するイベントが通知された場合、処理はステップＳ４１３に移行する。
【０２５３】
また、起動でも停止でもないイベントが通知された場合、プロセスグループ判定部５０１はステップＳ４０１で待機し続ける。例えば、既にバックグラウンドで実行中のアプリケーションがフォアグラウンドに切り替えられた場合、当該アプリケーションのプロセスグループは変化しないので、プロセスグループ判定部５０１は何もする必要がない。したがって、プロセスグループ判定部５０１はステップＳ４０１で待機し続ける。
【０２５４】
ステップＳ４０２でプロセスグループ判定部５０１は、起動したアプリケーションのパッケージ情報から、実行プログラム名と利用資源名を取得する。取得される実行プログラム名の数は１以上であり、取得される利用資源名の数は０以上である。
【０２５５】
例えば、アプリケーションＥが起動したことを切り替えイベント通知部５１２がプロセスグループ判定部５０１に通知したとする。この場合、プロセスグループ判定部５０１はステップＳ４０２において、切り替えイベント通知部５１２から通知された「Ｅ」というアプリケーション名を検索キーにして、パッケージ情報ＤＢ５０６ａを検索する。
【０２５６】
そして、プロセスグループ判定部５０１は、見つかったエントリのプログラム名リストから、アプリケーションＥの実行プログラム名として「Ｅ１」と「Ｅ２」を取得する。また、プロセスグループ判定部５０１は、見つかったエントリの利用外部資源名リストから、アプリケーションＥの利用資源名として「サウンド」という論理的な名前を取得する。
【０２５７】
続いて、ステップＳ４０３でプロセスグループ判定部５０１は、例えば「ｐｓ」コマンドなどを用いて、プロセス一覧５０７を取得する。図７に例示したとおり、プロセス一覧５０７は、各プロセスのプロセス名とＰＩＤを少なくとも含む。
【０２５８】
そして、次のステップＳ４０４でプロセスグループ判定部５０１は、ステップＳ４０２で取得した各実行プログラム名について、以下の処理を行う。すなわち、プロセスグループ判定部５０１は、取得した実行プログラム名を検索キーにして、ステップＳ４０３で取得したプロセス一覧５０７を検索し、プログラムの実行により生成されたプロセスのＰＩＤを検索結果から取得する。
【０２５９】
例えば、ステップＳ４０２で「Ｅ１」と「Ｅ２」という実行プログラム名が取得され、ステップＳ４０３で図７のプロセス一覧５０７ａが取得されたとする。この場合、ステップＳ４０４でプロセスグループ判定部５０１は、「Ｅ１」という名前を検索キーにして１００２というＰＩＤを取得するとともに、「Ｅ２」という名前を検索キーにして１０１２というＰＩＤを取得する。
【０２６０】
さらに、次のステップＳ４０５でプロセスグループ判定部５０１は、ステップＳ４０４で取得した全ＰＩＤを、プロセスグループメンバ表５０２に書き込む。
より詳しくは、プロセスグループ判定部５０１は、プロセスグループメンバ表５０２に新たなエントリを追加する。また、プロセスグループ判定部５０１は、追加したエントリの「アプリケーション名」フィールドに、起動したアプリケーションの名前を書き込む。なお、プロセスグループ判定部５０１は、切り替えイベント通知部５１２からの通知により、起動したアプリケーションの名前を認識することが可能である。そして、プロセスグループ判定部５０１は追加したエントリの「ＰＩＤリスト」フィールドに、ステップＳ４０４で取得した全ＰＩＤを書き込む。
【０２６１】
例えば、ステップＳ４０４で上記の例のように１００２と１０１２というＰＩＤを得た場合、ステップＳ４０５でプロセスグループ判定部５０１は、起動したアプリケーションＥに対応するエントリを作成する。そして、プロセスグループ判定部５０１は、「Ｅ」というアプリケーション名に対応づけて、１００２および１０１２というＰＩＤをプロセスグループメンバ表５０２に記録する。
【０２６２】
続いて、ステップＳ４０６でプロセスグループ判定部５０１は、ステップＳ４０２で取得した利用資源名のうち、ステップＳ４０７以降の処理の対象としてまだ注目していない利用資源名がまだあるか否かを判断する。ステップＳ４０２で取得した利用資源名の数がそもそも０であるか、または、取得したすべての利用資源名に既に注目し終わっている場合、処理はステップＳ４１２に移行する。逆に、ステップＳ４０２で取得した利用資源名のうち、未注目のものがまだある場合、処理はステップＳ４０７に移行する。
【０２６３】
そして、ステップＳ４０７でプロセスグループ判定部５０１は、次の利用資源名に注目し、資源・ファイル対応表５０４を用いて、論理的な利用資源名から物理的な資源ファイル名を取得する。つまり、プロセスグループ判定部５０１は、注目した利用資源名を検索キーにして資源・ファイル対応表５０４を検索し、見つかったエントリから資源ファイル名を読み取る。
【０２６４】
例えば、プロセスグループ判定部５０１がステップＳ４０７で「サウンド」という利用資源名に注目しており、資源・ファイル対応表５０４が図７の資源・ファイル対応表５０４ａのとおりであるとする。この場合、ステップＳ４０７でプロセスグループ判定部５０１は、「サウンド」という名前から、「／ｄｅｖ／ｓｎｄ」という資源ファイル名を取得する。
【０２６５】
そして、次のステップＳ４０８でプロセスグループ判定部５０１は、起動したアプリケーションの利用する資源を確保しているプロセスのＰＩＤを、資源依存関係表５０５から読み取る。すなわち、プロセスグループ判定部５０１は、ステップＳ４０７で取得した資源ファイル名を検索キーにして資源依存関係表５０５を検索し、見つかったエントリからＰＩＤを読む。
【０２６６】
例えば、ステップＳ４０７で「／ｄｅｖ／ｓｎｄ」というファイル名が取得され、資源依存関係表５０５が図７の資源依存関係表５０５ａのとおりであるとする。この場合、ステップＳ４０８でプロセスグループ判定部５０１は、「／ｄｅｖ／ｓｎｄ」というファイル名から、１０というＰＩＤを取得する。
【０２６７】
なお、図１０のステップＳ３０４に関して説明したとおり、資源が解放されると資源依存関係表５０５のＰＩＤはクリアされる。よって、現在プロセスグループ判定部５０１が注目している資源を現在確保しているプロセスがない場合、ステップＳ４０８では、有効なＰＩＤの値は取得されない。なお、ＰＩＤをクリアする操作は、実施形態に応じて、ＮＵＬＬ値を上書きする操作であってもよいし、ＰＩＤとしては使われない−１などの特定の数値を上書きする操作であってもよい。よって、プロセスグループ判定部５０１は、ステップＳ４０８で取得した値がＮＵＬＬや−１などであれば、「ＰＩＤがクリアされている」と判断することができる。
【０２６８】
そして、次のステップＳ４０９でプロセスグループ判定部５０１は、現在注目している資源ファイル名に対応して資源依存関係表５０５に有効なＰＩＤが存在するか否かを判断する。つまり、プロセスグループ判定部５０１は、ステップＳ４０８で有効なＰＩＤを取得することができたか否かを判断する。
【０２６９】
そして、有効なＰＩＤがステップＳ４０８で取得された場合は、取得されたＰＩＤをプロセスグループに追加するか否かの判断のため、処理はステップＳ４１０に移行する。逆に、ＰＩＤがクリアされていれば、現在プロセスグループ判定部５０１が注目している資源に関連してプロセスグループに追加するＰＩＤが存在しないので、処理はステップＳ４０６に戻る。
【０２７０】
また、ステップＳ４１０でプロセスグループ判定部５０１は、ステップＳ４０８で読み取ったＰＩＤのプロセスの種類が、資源へのアクセスを提供するために資源を占有するシステムサービスなのか、それともアプリケーションなのかを判断する。つまり、プロセスグループ判定部５０１は、ステップＳ４０８で読み取ったＰＩＤのプロセスが、特定プロセスなのか否かを判断する。
【０２７１】
例えば、資源・ファイル対応表５０４が図７の資源・ファイル対応表５０４ａのように「フラグ」フィールドを有する場合、プロセスグループ判定部５０１は次のようにしてステップＳ４１０の判断を行う。プロセスグループ判定部５０１は、ステップＳ４０７で検索して見つけたエントリのフラグを参照する。そして、フラグの値が１であれば、プロセスグループ判定部５０１は、「プロセスの種類はシステムサービスである」と判断する。逆に、フラグの値が０であれば、プロセスグループ判定部５０１は、「プロセスの種類はアプリケーションである」と判断する。
【０２７２】
実施形態によっては、プロセスグループ判定部５０１は、他の種類の情報を用いてステップＳ４１０の判断を行ってもよい。資源へのアクセスを提供するために資源を占有するシステムサービスの名前のリストをスマートフォン５００が保持してもよく、プロセスグループ判定部５０１はリストを参照することでステップＳ４１０の判断を行ってもよい。
【０２７３】
なお、プロセスグループ判定部５０１は、ステップＳ４０３で取得したプロセス一覧５０７から、ステップＳ４０８で読み取ったＰＩＤに対応するプロセス名を取得することができる。よって、プロセスグループ判定部５０１は、システムサービスの名前のリストに、取得したプロセス名が含まれるか否かを判断することにより、ステップＳ４１０の判断を行ってもよい。
【０２７４】
そして、ステップＳ４０８で読み取ったＰＩＤのプロセスの種類が、資源へのアクセスを提供するために資源を占有するシステムサービスであれば、処理はステップＳ４１１に移行する。つまり、プロセスグループ判定部５０１が現在注目している資源が、特定プロセスによって占有される特定資源であれば、処理はステップＳ４１１に移行する。
【０２７５】
逆に、ステップＳ４０８で読み取ったＰＩＤのプロセスの種類が、アプリケーションであれば、処理はステップＳ４０６に戻る。つまり、プロセスグループ判定部５０１が現在注目している資源が、特定資源以外の通常の資源である（すなわち、任意のアプリケーションプロセスから直接アクセスされ得る資源である）場合、処理はステップＳ４０６に戻る。
【０２７６】
なぜなら、プロセスグループ判定部５０１が現在注目している資源が、たまたま別のアプリケーションのプロセスによって現在オープンされているとしても、起動したアプリケーションと当該別のアプリケーションは独立しているからである。独立した２つのアプリケーションのプロセスを同じプロセスグループに含めることは、「アプリケーション単位での適切なプロセス管理のためのプロセスグループの認識」という目的にそぐわない。そのため、ステップＳ４０８で読み取ったＰＩＤのプロセスの種類が、アプリケーションであれば、処理はステップＳ４０６に戻る。
【０２７７】
そして、ステップＳ４１１でプロセスグループ判定部５０１は、ステップＳ４０８で読み取ったＰＩＤを、プロセスグループメンバ表５０２の、ステップＳ４０５で追加したエントリのＰＩＤリストに追加する。追加の後、処理はステップＳ４０６に戻る。
【０２７８】
例えば、上記の例のように、プロセスグループ判定部５０１が、ステップＳ４０５でアプリケーション名「Ｅ」に対応づけて１００２および１０１２というＰＩＤをプロセスグループメンバ表５０２に記録し、ステップＳ４０８で１０というＰＩＤを取得したとする。すると、プロセスグループ判定部５０１はステップＳ４１１でさらに１０というＰＩＤを追加する。その結果、図７のプロセスグループメンバ表５０２ａの２番目のエントリのとおり、１０、１００２、および１０１２というＰＩＤのプロセスを含むプロセスグループが、アプリケーションＥのプロセスグループとしてプロセスグループメンバ表５０２に登録される。
【０２７９】
さて、ステップＳ４１２が実行されるのは、起動したアプリケーションに関するプロセスグループに属するＰＩＤが、すべてプロセスグループメンバ表５０２に登録された後である。そこで、ステップＳ４１２でプロセスグループ判定部５０１は、プロセスグループメンバ表５０２の更新をプロセス制御モジュール５０３に通知する。プロセス制御モジュール５０３は、ステップＳ４１２でのプロセスグループ判定部５０１からの通知を待つことにより、確実に、更新後のプロセスグループメンバ表５０２を参照することができる。ステップＳ４１２の通知の後、処理はステップＳ４０１に戻る。
【０２８０】
さて、ステップＳ４１３では、プロセスグループ判定部５０１が、プロセスグループメンバ表５０２から、停止したアプリケーションのプロセスグループを削除する。つまり、プロセスグループ判定部５０１は、停止したアプリケーションに対応するエントリを、プロセスグループメンバ表５０２から削除する。そして、処理はステップＳ４０１に戻る。
【０２８１】
例えば、アプリケーションＤが停止したことを、切り替えイベント通知部５１２がプロセスグループ判定部５０１に通知したとする。この場合、プロセスグループ判定部５０１はステップＳ４１３において、「Ｄ」というアプリケーション名を検索キーにしてプロセスグループメンバ表５０２を検索し、見つかったエントリをプロセスグループメンバ表５０２から削除する。
【０２８２】
なお、プロセスグループ判定部５０１が資源・ファイル対応表５０４ａのフラグを用いてステップＳ４１０の判断を行う場合、上記の図１１の処理は次のように変形されてもよい。すなわち、プロセスグループ判定部５０１はステップＳ４０７で資源ファイル名とともにフラグの値を取得し、フラグの値が０であれば、ステップＳ４０８〜Ｓ４１１を省略して、ステップＳ４０６に戻ってもよい。そして、ステップＳ４０７で取得したフラグの値が1の場合、プロセスグループ判定部５０１は、ステップＳ４０８とＳ４１１の処理を行ってもよい。
【０２８３】
また、図１１では省略されているが、ステップＳ４０２は次のようなエラー処理を含んでもよい。
アプリケーション管理マネジャ５１１は、ユーザアプリケーション以外のプログラムの起動も検出するよう構成されていてもよい。その場合、何らかの理由でサウンドデーモン６１４などのサービスが再起動された場合などにも、切り替えイベント通知部５１２からプロセスグループ判定部５０１への通知が行われることがある。
【０２８４】
そこで、図１１ではエラー処理が省略されているが、ステップＳ４０２におけるパッケージ情報ＤＢ５０６の検索でエントリが見つからなければ、プロセスグループ判定部５０１は、図１１の処理を直ちに終了してもよい。
【０２８５】
すると、たとえサービスの起動を契機に処理がステップＳ４０１からステップＳ４０２に移行した場合であっても、起動したサービスに関するエントリが誤ってプロセスグループメンバ表５０２に作成されることはない。また、アプリケーション管理マネジャ５１１がユーザアプリケーションと他のプログラム（例えばサービスなど）を区別することができる場合、切り替えイベント通知部５１２は、ユーザアプリケーションの状態変化イベントのみを通知対象とてもよい。すると、上記のようなステップＳ４０２でのエラー処理がなくても、サービスに関連づけられたエントリが誤ってプロセスグループメンバ表５０２に作成されることはない。
【０２８６】
さて、図１２〜１３は、第２実施形態においてプロセス制御モジュール５０３が行う処理のフローチャートである。図１２〜１３の処理は、スマートフォン５００が起動されると開始される。また、図１４は、図１２と１３から呼び出されるサブルーチンのフローチャートである。
【０２８７】
ステップＳ５０１でプロセス制御モジュール５０３は必要に応じて適宜の初期化を行う。例えば、プロセス制御モジュール５０３は、内部データを初期化する。また、後述の変形例のように、予め定義された何らかの情報（例えば資源・ファイル対応表５０４）をプロセスグループ判定部５０１が利用する場合、プロセスグループ判定部５０１はステップＳ５０１で、予め定義された情報を読み込んでもよい。
【０２８８】
次のステップＳ５０２でプロセス制御モジュール５０３は、切り替えイベント通知部５１２からの、アプリケーションの切り替え通知を所定時間待つ。切り替えイベント通知部５１２からプロセス制御モジュール５０３への通知は、図８のステップＳ１０４に示したとおりである。
【０２８９】
所定時間内に切り替えイベント通知部５１２からの通知がなかった場合、処理はステップＳ５０３に移行する。また、他のアプリケーションへの切り替えをともなわずに、フォアグラウンドで実行されていたアプリケーションが単に終了したことを切り替えイベント通知部５１２がプロセスグループ判定部５０１に通知した場合も、処理はステップＳ５０３に移行する。
【０２９０】
新たなアプリケーションが起動されたこと、または、既に起動されているアプリケーションがフォアグラウンドに遷移したことの通知を切り替えイベント通知部５１２からプロセスグループ判定部５０１が受けた場合、処理はステップＳ５０５に移行する。例えば、バックグラウンドで実行中のアプリケーション、または一時停止中のアプリケーションが、フォアグラウンドでの実行のために選択された場合、処理はステップＳ５０２からステップＳ５０５へ移行する。
【０２９１】
ステップＳ５０３でプロセス制御モジュール５０３は、プロセス制御モジュール５０３の内部データとして保持する保留プロセスリストを参照する。詳しくは後述するが、保留プロセスリストは、プロセス制御モジュール５０３がプロセスに対して何らかの制御を試みて失敗したときに、将来のリトライに備えて、処理対象のプロセスと制御の内容を記録するためのリストである。
【０２９２】
例えば、図５においてプロセス制御モジュール５０３からカーネル５１３への矢印とカーネル５１３からプロセス５１７への矢印により表されるとおり、プロセス制御モジュール５０３は、システムコールを用いてプロセスを制御してもよい。保留プロセスリストの各要素は、例えば、プロセスのＰＩＤを引数として含むシステムコールであってもよい。あるいは、保留プロセスリストの各要素は、プロセスのＰＩＤと、プロセスに送信するシグナルのペアであってもよい。
【０２９３】
プロセス制御モジュール５０３は、ステップＳ５０３で保留プロセスリストを参照し、未注目のプロセスが保留プロセスリストに残っているか否かを判断する。保留プロセスリスト自体が空の場合、または、保留プロセスリスト中の全プロセスについて既に注目してステップＳ５０４の処理を終えた場合は、処理はステップＳ５０２に戻る。逆に、保留プロセスリストが空でなく、まだステップＳ５０４の処理の対象として注目していないプロセスが１つ以上保留プロセスリストに残っている場合は、処理はステップＳ５０４に移行する。
【０２９４】
そして、ステップＳ５０４でプロセス制御モジュール５０３は、保留プロセスリスト中の次の未注目のプロセスに対して、保留プロセスリストに記録された操作を試みる。
例えば、ＰＩＤが１２００のプロセスに対して以前プロセス制御モジュール５０３が一時停止を試み、何らかの理由で一時停止に失敗したとする。この場合、保留プロセスリストには、１２００というＰＩＤと、一時停止という操作内容が記録されている。そこで、ステップＳ５０４でプロセス制御モジュール５０３は、ＰＩＤが１２００のプロセスの一時停止を再度試みる。
【０２９５】
なお、ステップＳ５０４の詳細は図１４とともに後述する。図１４に示すサブルーチンは、具体的には、プロセスのＰＩＤと、操作内容と、リトライフラグを引数として含む。リトライフラグは、「プロセスに対する操作が、保留プロセスリストに基づくリトライなのか、それとも最初の試みなのか」ということを示す。ステップＳ５０４でのサブルーチンコールにおいて、プロセス制御モジュール５０３は、リトライフラグを、リトライを示す値（例えば１）に設定する。また、ステップＳ５０４の実行後、処理はステップＳ５０３に戻る。
【０２９６】
プロセス制御モジュール５０３は、以上のステップＳ５０２〜Ｓ５０４のようにして、暇な時間（つまり、アプリケーションの切り替えが発生していないのでステップＳ５０５以降の処理を実行する必要がない時間）に、必要に応じてリトライ処理を行う。
【０２９７】
さて、ステップＳ５０５でプロセス制御モジュール５０３は、切り替えイベント通知部５１２から通知されたイベントが新たなアプリケーションの起動であるか否かを判断する。
【０２９８】
新たなアプリケーションが起動された場合、プロセス制御モジュール５０３が以下で参照するプロセスグループメンバ表５０２は、プロセスグループ判定部５０１によってまさに書き換えられるところである。そこで、プロセスグループ判定部５０１によるプロセスグループメンバ表５０２の書き換えの完了を待つため、処理はステップＳ５０６に移行する。
【０２９９】
逆に、新たなアプリケーションが起動されたのではない場合、新たにフォアグラウンドになったアプリケーションのプロセスグループは既にプロセスグループメンバ表５０２に登録されている。例えば、一旦起動された後にバックグラウンドに遷移し、直前までバックグラウンドで実行されていたアプリケーションが、フォアグラウンドに遷移した場合、プロセスグループは既にプロセスグループメンバ表５０２に登録されている。また、一旦起動された後に一時停止されたアプリケーションが再開されてフォアグラウンドで実行される場合も、プロセスグループは既にプロセスグループメンバ表５０２に登録されている。よって、新たなアプリケーションが起動されたのではない場合、処理はステップＳ５０７に移行する。
【０３００】
ステップＳ５０６でプロセス制御モジュール５０３は、「プロセスグループメンバ表５０２を更新が完了した」というプロセスグループ判定部５０１からの通知を受け取るまで待つ。ステップＳ５０６でプロセス制御モジュール５０３が受け取る通知は、図１１のステップＳ４１２でプロセスグループ判定部５０１が出す通知である。プロセス制御モジュール５０３が通知を受け取ると、処理はステップＳ５０７に移行する。
【０３０１】
さて、ステップＳ５０７でプロセス制御モジュール５０３は、プロセス一覧５０７を取得する。
例えば、アプリケーションＥが新たに起動された場合、アプリケーションＥのプログラムＥ１とＥ２の実行は、ステップＳ５０６で検出される通知がプロセス制御モジュール５０３に届いた時点で、既に開始されている。よって、ステップＳ５０７で取得されるプロセス一覧５０７には、プロセスＥ１とＥ２がリストアップされている。
【０３０２】
そして、次のステップＳ５０８でプロセス制御モジュール５０３は、新たにフォアグラウンドで実行されることになったアプリケーションのプロセスグループを認識する。以下では説明の便宜上、ステップＳ５０８で認識されるプロセスグループを「フォアグラウンドプロセスグループ」という。
【０３０３】
例えば、「アプリケーションＥが起動された」という通知を、プロセス制御モジュール５０３がステップＳ５０２で切り替えイベント通知部５１２から受け取ったとする。この場合、ステップＳ５０８でプロセス制御モジュール５０３は、「Ｅ」というアプリケーション名を検索キーにしてプロセスグループメンバ表５０２を検索し、アプリケーションＥに対応づけられているプロセスグループを認識する。プロセスグループメンバ表５０２が図７のプロセスグループメンバ表５０２ａのとおりである場合、ステップＳ５０８でプロセス制御モジュール５０３は、ＰＩＤが１０と１００２と１０１２のプロセスを含むプロセスグループを認識する。
【０３０４】
そして、次のステップＳ５０９でプロセス制御モジュール５０３は、保留プロセスリスト中に、フォアグラウンドプロセスグループに属するプロセスがあるか否かを判断する。フォアグラウンドプロセスグループに属するプロセスが保留プロセスリスト中に含まれる場合、処理はステップＳ５１０に移行する。逆に、フォアグラウンドプロセスグループに属するどのプロセスも保留プロセスリスト中には含まれない場合、処理は図１３のステップＳ５１１に移行する。
【０３０５】
ステップＳ５１０でプロセス制御モジュール５０３は、フォアグラウンドプロセスグループに属するプロセスを、保留プロセスリストから削除する。
例えば、保留プロセスリストには、ＰＩＤが１２００のプロセスに対する一時停止操作が記録されているとする。また、ＰＩＤが１２００のプロセスがフォアグラウンドプロセスグループに属するとする。
【０３０６】
ここで、フォアグラウンドプロセスグループに属するプロセスは、以下に説明するステップＳ５１１〜Ｓ５１３のとおり、今まさにプロセス制御モジュール５０３が制御しようとしているプロセスである。具体的には、プロセス制御モジュール５０３は、フォアグラウンドプロセスグループに属するプロセスに対する操作内容を、ステップＳ５１１で決める。
【０３０７】
仮に、ＰＩＤが１２００のプロセスが保留プロセスリストから削除されないとすると、ＰＩＤが１２００のプロセスは、ステップＳ５１１〜Ｓ５１３で適宜に制御された後、再び実行される将来のステップＳ５０４において、一時停止されてしまう。つまり、ＰＩＤが１２００のプロセスに対する適切な制御としてプロセス制御モジュール５０３が決めた操作の種類が変化する場合に、新しい方の操作が古い方の操作で上書きされてしまう。
【０３０８】
そこで、「新しい方の操作が古い方の操作で上書きされる」という不都合を防ぐため、ステップＳ５１０でプロセス制御モジュール５０３は、フォアグラウンドプロセスグループに属するプロセスを、保留プロセスリストから削除する。そして、処理は図１３のステップＳ５１１に移行する。
【０３０９】
ステップＳ５１１でプロセス制御モジュール５０３は、フォアグラウンドプロセスグループに対する操作の内容を決める。具体的には、プロセス制御モジュール５０３は、フォアグラウンドプロセスグループに属する各プロセスに対して、優先度を上げる操作または再開操作を行うことを決める。
【０３１０】
なお、実施形態に応じて、プロセス制御モジュール５０３は、ステップＳ５１１において常に、フォアグラウンドプロセスグループに対する操作を、優先度を上げる操作に決めてもよい。または、プロセス制御モジュール５０３は、ステップＳ５１１において常に、フォアグラウンドプロセスグループに対する操作を、再開操作に決めてもよい。あるいは、プロセス制御モジュール５０３は、スマートフォン５００の負荷などの状況に応じて、ステップＳ５１１において操作内容を決めてもよい。
【０３１１】
そして、次のステップＳ５１２において、プロセス制御モジュール５０３は、フォアグラウンドプロセスグループ中に未注目のプロセスが残っているか否かを判断する。フォアグラウンドプロセスグループ中に、まだステップＳ５１３の処理の対象としてプロセス制御モジュール５０３が注目していないプロセスが残っていれば、処理はステップＳ５１３に移行する。逆に、フォアグラウンドプロセスグループ中のすべてのプロセスについてプロセス制御モジュール５０３が既にステップＳ５１３の処理を実行し終わっていれば、処理はステップＳ５１４に移行する。
【０３１２】
ステップＳ５１３でプロセス制御モジュール５０３は、フォアグラウンドプロセスグループ中の次の未注目のプロセスに対して、ステップＳ５１１で決めた操作を試みる。そして、処理はステップＳ５１２に戻る。
【０３１３】
なお、ステップＳ５１３の詳細は、図１４とともに後述するが、ステップＳ５１３では、前述のリトライフラグが、最初の試みを示す値（例えば０）に設定される。
また、ステップＳ５１４でプロセス制御モジュール５０３は、フォアグラウンドからバックグラウンドに遷移したアプリケーションのプロセスグループを認識する。以下では説明の便宜上、ステップＳ５１４で認識されるプロセスグループを「バックグラウンドプロセスグループ」という。
【０３１４】
例えば、切り替えイベント通知部５１２からステップＳ５０２で通知されたイベントが、「アプリケーションＥが起動され、今までフォアグラウンドで実行されていたアプリケーションＤがバックグラウンドに遷移した」というイベントであるとする。この場合、バックグラウンドプロセスグループは、アプリケーションＤに対応づけられてプロセスグループメンバ表５０２に記録されているプロセスグループである。
【０３１５】
あるいは、切り替えイベント通知部５１２からステップＳ５０２で通知されたイベントが、「何もアプリケーションが実行されていない状態から、新規にアプリケーションＥが起動された」というイベントであるとする。この場合、フォアグラウンドからバックグラウンドに遷移するアプリケーションはそもそも存在しない。よって、プロセス制御モジュール５０３はステップＳ５１４で「バックグラウンドプロセスグループは空である」と認識する。
【０３１６】
そして、次のステップＳ５１５でプロセス制御モジュール５０３は、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないプロセスに対する操作の内容を決める。ステップＳ５１５で決定される操作内容は、具体的には、優先度を下げる操作または一時停止操作である。
【０３１７】
なお、実施形態に応じて、プロセス制御モジュール５０３は、優先度を下げる操作をステップＳ５１５において常に選択してもよい。または、プロセス制御モジュール５０３は、一時停止操作をステップＳ５１５において常に選択してもよい。あるいは、プロセス制御モジュール５０３は、スマートフォン５００の負荷などの状況に応じて、ステップＳ５１５において操作内容を決めてもよい。
【０３１８】
そして、次のステップＳ５１６でプロセス制御モジュール５０３は、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないプロセスの中に、未注目のプロセスが残っているか否かを判断する。
【０３１９】
もし、まだステップＳ５１７の処理の対象としてプロセス制御モジュール５０３が注目していないプロセスが残っていれば、処理はステップＳ５１７に移行する。
【０３２０】
逆に、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないすべてのプロセスについて、プロセス制御モジュール５０３が既にステップＳ５１７の処理を実行し終わっていれば、処理は図１２のステップＳ５０２に戻る。なお、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないプロセスがそもそも存在しない場合も同様に、処理はステップＳ５０２に戻る。
【０３２１】
ステップＳ５１７でプロセス制御モジュール５０３は、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないプロセスの中の次の未注目のプロセスに対して、ステップＳ５１５で決めた操作を試みる。そして、処理はステップＳ５１６に戻る。
【０３２２】
なお、ステップＳ５１７の詳細は、図１４とともに後述するが、ステップＳ５１７では、前述のリトライフラグが、最初の試みを示す値（例えば０）に設定される。
また、ステップＳ５１７の処理の対象から、フォアグラウンドプロセスグループに属するプロセスが除外される理由は、次のとおりである。
【０３２３】
第１と第２のアプリケーションが同じ特定資源を利用する場合、同じ特定プロセスが第１のアプリケーションのプロセスグループにも含まれ、第２のアプリケーションのプロセスグループにも含まれる。例えば、第１と第２のアプリケーションがいずれもサウンドデバイス６０３を利用するとする。この場合、サウンドデバイス６０３を占有してサウンドデバイス６０３へのアクセスを提供するサウンドデーモン６１４のプロセスは、第１のアプリケーションのプロセスグループにも含まれ、第２のアプリケーションのプロセスグループにも含まれる。
【０３２４】
すると、フォアグラウンドアプリケーションが第１のアプリケーションから第２のアプリケーションへと切り替わる場合、バックグラウンドプロセスグループに属するすべてのプロセスに対してステップＳ５１７の処理を行うことは不適切である。仮に、サウンドデーモン６１４のプロセスが、バックグラウンドプロセスグループに属するからといって、優先度が下げられてしまうと、サウンドデバイス６０３を利用する第２のアプリケーションの性能に悪影響が出てしまう。よって、バックグラウンドプロセスグループに属するプロセスのうち、フォアグラウンドプロセスグループにも属するプロセスは、ステップＳ５１７の処理対象から除外することが適切である。
【０３２５】
なお、以上の図１２〜１３についての説明から明らかなように、どのアプリケーションのプロセスグループにも属さないプロセスは、プロセス制御モジュール５０３による制御を受けない。
【０３２６】
例えば、図７の資源・ファイル対応表５０４ａには、ディスプレイ６０４と資源ファイル６１２を対応づけるエントリが登録されていない。よって、資源ファイル６１２にアクセスするウィンドウシステム６１５も、当然、どのアプリケーションのプロセスグループにも属さない。したがって、ウィンドウシステム６１５のプロセスは、プロセス制御モジュール５０３の制御を受けない。
【０３２７】
ほとんどのアプリケーションはウィンドウシステム６１５を利用する。そのため、プロセス制御モジュール５０３が、ウィンドウシステム６１５のプロセスの優先度を下げたり、ウィンドウシステム６１５のプロセスを一時停止させたりすることは、不適切である。しかし、上記のとおりウィンドウシステム６１５のプロセスは、プロセス制御モジュール５０３の制御を受けないので、そのような不適切な制御も当然生じない。
【０３２８】
また、上記のとおり、アプリケーション以外のプロセス（例えばサービス等のプロセス）に対応づけられたエントリは、プロセスグループメンバ表５０２には含まれない。よって、「ｉｎｉｔ」プロセスのような特殊なプロセスも、プロセス制御モジュール５０３による制御を受けない。つまり、プロセス制御モジュール５０３による制御は、アプリケーションと無関係な特殊なプロセスに対して悪影響を及ぼさない。
【０３２９】
続いて、図１４を参照して、上述のステップＳ５０４、Ｓ５１３およびＳ５１７から呼び出されるサブルーチンの詳細を説明する。なお、図１４のサブルーチンの引数は、具体的には、操作対象のプロセスを指定するＰＩＤと、操作の種類と、リトライフラグを含む。
【０３３０】
ステップＳ６０１でプロセス制御モジュール５０３は、引数で指定された操作の種類を判定する。そして、指定された操作の種類が優先度の変更である場合、処理はステップＳ６０２に移行する。また、指定された操作の種類が一時停止または再開である場合、処理はステップＳ６０３に移行する。
【０３３１】
ステップＳ６０２でプロセス制御モジュール５０３は、引数でＰＩＤが指定されたプロセスの優先度クラスを、引数で指定されたクラスに変更する。プロセスの優先度は、ＯＳに応じて異なる方法で管理される。例えば第２実施形態では、プロセスの優先度は、複数の優先度クラスのいずれかに指定される。
【０３３２】
例えば、ＯＳによって定義された優先度クラスが「高優先度クラス」と「低優先度クラス」の２つであってもよい。この場合、優先度を上げる操作とは、具体的には優先度クラスを高優先度クラスに設定する操作であり、優先度を下げる操作とは、優先度クラスを低優先度クラスに設定する操作である。
【０３３３】
もちろん、３つ以上の優先度クラスが定義されていてもよい。その場合、プロセス制御モジュール５０３は、優先度をどの程度上げるかをステップＳ５１１で決め、優先度をどの程度下げるかをステップＳ５１５で決めてもよい。
【０３３４】
なお、最低の優先度のクラスは、ＣＰＵ時間の割り当てが固定的に０と決められるような、特殊なクラスであってもよい。その場合、優先度を下げる操作によって、実質的には一時停止操作を実現することも可能である。
【０３３５】
また、ステップＳ６０３でプロセス制御モジュール５０３は、引数でＰＩＤが指定されたプロセスに対し、引数で指定された操作に応じたシグナルを送信する。なお、操作の内容を示す引数が、送信するシグナルの値そのものであってもよい。
【０３３６】
例えば、指定された操作が一時停止ならば、プロセス制御モジュール５０３は、一時停止のためのシグナル（例えばＳＩＧＳＴＯＰ）を送信する。また、指定された操作が再開ならば、プロセス制御モジュール５０３は、再開のためのシグナル（例えばＳＩＧＣＯＮＴ）を送信する。なお、一時停止中ではないプロセス（つまり実行中のプロセス）に再開のためのシグナルが送信されても、シグナルは単に無視されるだけなので、有害な副作用は生じない。
【０３３７】
そして、ステップＳ６０２またはＳ６０３の実行後、処理はステップＳ６０４に移行する。ステップＳ６０４でプロセス制御モジュール５０３は、「ステップＳ６０２またはＳ６０３の操作が、成功したか失敗したか」ということを判断する。
【０３３８】
例えば、ステップＳ６０２とＳ６０３の処理は、システムコールにより実現されてもよい。そして、システムコールが成功したか失敗したかを示す返り値が、カーネル５１３からプロセス制御モジュール５０３に返されてもよい。すると、プロセス制御モジュール５０３は、返り値に基づいてステップＳ６０４の判断を実行することができる。
【０３３９】
あるいは、プロセス制御モジュール５０３は、ステップＳ６０４において、制御の対象のプロセスの優先度クラスを参照し、優先度クラスが引数で指定されたとおりに正しく設定されたか否かを判断してもよい。同様に、プロセス制御モジュール５０３は、ステップＳ６０４において、制御の対象のプロセスの状態を参照し、プロセスが正しく一時停止または再開されたか否かを判断してもよい。
【０３４０】
そして、ステップＳ６０２またはＳ６０３の操作が成功した場合、処理はステップＳ６０５に移行する。逆に、ステップＳ６０２またはＳ６０３の操作が失敗した場合、処理はステップＳ６０７に移行する。なお、ステップＳ６０２またはＳ６０３の操作が失敗する場合としては、例えば、操作対象のプロセスが何らかのシステムコールを実行中の場合や、何らかの資源をオープンして確保している場合などがあり得る。
【０３４１】
ステップＳ６０５でプロセス制御モジュール５０３は、引数として指定されたリトライフラグの値を参照して、今回のサブルーチンコールがリトライなのか否かを判断する。そして、今回のサブルーチンコールがリトライであれば、処理はステップＳ６０６に移行し、今回のサブルーチンコールが１回目の試みであれば、図１４の処理は終了する。
【０３４２】
そして、ステップＳ６０６でプロセス制御モジュール５０３は、引数で指定されたＰＩＤと、引数で指定された操作内容のペアを保留プロセスリストから削除する。つまり、リトライによって成功した操作は、さらにもう一度試みる必要がないので、ステップＳ６０６では保留プロセスリストからの要素の削除が行われる。そして、図１４の処理は終了する。
【０３４３】
また、ステップＳ６０７でプロセス制御モジュール５０３は、引数として指定されたリトライフラグの値を参照して、今回のサブルーチンコールがリトライなのか否かを判断する。
【０３４４】
そして、今回のサブルーチンコールがリトライであれば、プロセス制御モジュール５０３は保留プロセスリストを更新せずに図１４の処理を終了する。なぜなら、プロセス制御モジュール５０３が以前失敗した操作に再度失敗した場合、当該操作は依然としてリトライの対象のままだからである。
【０３４５】
逆に、今回のサブルーチンコールが１回目の試みであれば、処理はステップＳ６０８に移行する。そして、ステップＳ６０８でプロセス制御モジュール５０３は、引数で指定されたＰＩＤと、引数で指定された操作内容のペアを保留プロセスリストに追加する。そして、図１４の処理は終了する。
【０３４６】
以上説明したように、第２実施形態によれば、アプリケーションが利用する資源に基づいて適切なプロセスグループが認識される。そして、フォアグラウンドで実行されるアプリケーションのプロセスグループと、フォアグラウンドからバックグラウンドに遷移したアプリケーションのプロセスグループに対して、それぞれ適宜の制御が行われる。そのため、たとえスマートフォン５００のハードウェアが貧弱であっても、フォアグラウンドアプリケーションのプロセスグループに対して重点的にハードウェアが割り当てられる。その結果、フォアグラウンドアプリケーションを利用するユーザが感じる性能は、良好に保たれる。
【０３４７】
例えば、スマートフォン５００が有するＣＰＵ２０１のクロック周波数がさほど高くなくても、第２実施形態によれば、フォアグラウンドアプリケーションのプロセスグループに属するプロセスに対してＣＰＵ時間が重点的に割り当てられる。そのため、例えば比較的短い応答時間が実現される。その結果、ユーザは、快適にフォアグラウンドアプリケーションを利用することができ、性能の良さを感じるであろう。
【０３４８】
さて、以上説明した第２実施形態は、下記（１３ａ）〜（１３ｈ）に示す観点から変形することができ、（１３ａ）〜（１３ｈ）の変形例は、互いに矛盾しない限り任意に組み合わせることが可能である。
【０３４９】
（１３ａ）ＯＳの優先度制御の仕組みに応じて、プロセス制御モジュール５０３による優先度制御の方法は、適宜変形されてよい。
（１３ｂ）プローブ５０９の負荷を削減するために、使用されないことが明らかな資源は、プローブ５０９による監視対象から除外されてもよい。
（１３ｃ）プローブ５０９の負荷を削減するために、必ず特定プロセスからアクセスされる特定資源は、プローブ５０９による監視対象から除外されてもよい。
（１３ｄ）動的に子孫プロセスが生成され得る場合に、より適切なプロセスグループの認識を可能とするために、プロセス同士の親子関係が参照されてもよい。
（１３ｅ）プロセス制御モジュール５０３が一時停止制御を行う場合に、一時停止にともなう副作用を回避するための例外処理が行われてもよい。
（１３ｆ）メモリ不足の解消のため、プロセスグループを利用した強制終了制御が行われてもよい。
（１３ｇ）プローブ５０９は必ずしもカーネル５１３内に実装されなくてもよい。
（１３ｈ）保留リストを用いる制御は適宜変形されてもよい。
【０３５０】
以下では上記（１３ａ）〜（１３ｈ）の変形例について説明する。
ＯＳによって優先度制御の仕組みは異なり、ある種のＯＳでは、優先度クラスが１つしかない。優先度クラスが１つしかないある種のＯＳでは、動的に変動する値によりプロセスの優先度が管理される。そして、ＯＳ内のプロセススケジューラは、動的に変動する値に応じてプロセスをスケジューリングする。上記（１３ａ）の変形例は、具体的には、優先度クラスが１つしかない場合に、図１４のサブルーチンが図１５のように変形される例である。
【０３５１】
優先度クラスが１つしかないＯＳでは、例えば「ｎｉｃｅ」コマンドによってプロセスに設定されるｎｉｃｅ値（niceness）に基づいて、プロセスの優先度が動的に制御される。例えば、プロセスがＣＰＵ時間を消費するほど、プロセスの優先度を示す動的な値は、より低い優先度を示す値に書き換えられる。よって、プロセスの優先度を示す動的な値は、時間の経過につれて、より低い優先度を示すようになる傾向がある。
【０３５２】
そこで、（１３ａ）の変形例では、図１４のサブルーチンが図１５のサブルーチンで置き換えられる。また、プロセス制御モジュール５０３は、動的に低下する傾向のある優先度を再設定するための内部データとして、優先度操作対象リストを保持する。優先度操作対象リストの各要素は、ＰＩＤとｎｉｃｅ値のペアである。
【０３５３】
また、図示は省略したが、（１３ａ）の変形例では、プロセス制御モジュール５０３による図１２〜１３の処理が次のように変形される。すなわち、プロセス制御モジュール５０３は、ステップＳ５１２よりも前（例えばステップＳ５１１の直後）に、優先度操作対象リストをクリアする。
【０３５４】
以下、図１５の処理について説明する。ステップＳ７０１でプロセス制御モジュール５０３は、引数で指定された操作の種類を判定する。そして、指定された操作の種類が優先度の変更である場合、処理はステップＳ７０２に移行する。また、指定された操作の種類が一時停止または再開である場合、処理はステップＳ７０４に移行する。
【０３５５】
ステップＳ７０２でプロセス制御モジュール５０３は、引数でＰＩＤが指定されたプロセスの静的優先度を示すｎｉｃｅ値を、引数で指定された値に変更する。ステップＳ７０２の処理は、具体的には「ｎｉｃｅ」コマンドの実行により実現されてもよい。
【０３５６】
そして、次のステップＳ７０３でプロセス制御モジュール５０３は、優先度操作対象リストに、引数で指定されたＰＩＤと引数で指定された値のペアを追加する。そして、処理はステップＳ７０５に移行する。
【０３５７】
また、ステップＳ７０４でプロセス制御モジュール５０３は、引数でＰＩＤが指定されたプロセスに対し、引数で指定された操作に応じたシグナルを送信する。ステップＳ７０４はステップＳ６０３と同様である。ステップＳ７０４の実行後、処理はステップＳ７０５に移行する。
【０３５８】
ステップＳ７０５〜Ｓ７０９は、図１４のステップＳ６０４〜Ｓ６０８と同様である。
ところで、（１３ａ）の変形例では、プロセス制御モジュール５０３がさらに定期的に以下の処理も行う。すなわち、プロセス制御モジュール５０３は、優先度操作対象リストの各要素（すなわちＰＩＤとｎｉｃｅ値のペア）に対して、当該ペアのＰＩＤで識別されるプロセスに、当該ペアに記録されているｎｉｃｅ値を設定する。
【０３５９】
上記のとおり、プロセスの優先度を示す動的な値は、時間の経過とともに、より低い優先度を示すようになる傾向がある。しかし、動的な値は、ｎｉｃｅ値の設定を契機としてリセットされる。
【０３６０】
そのため、プロセス制御モジュール５０３が上記のように定期的に優先度操作対象リストに登録された各プロセスのｎｉｃｅ値を再設定することで、優先度操作対象リストに登録された各プロセスの動的な優先度の低下を、ある程度抑制することができる。すなわち、図１３のステップＳ５１１において、フォアグラウンドプロセスグループが優先度を上げる対象として決定された場合に、フォアグラウンドプロセスグループに属する各プロセスの動的な優先度を高く保つために、ｎｉｃｅ値の定期的な再設定が行われる。
【０３６１】
続いて、（１３ｂ）〜（１３ｆ）の変形例について説明する。（１３ｂ）〜（１３ｆ）の変形例では、図５のスマートフォン５００にさらに処理モジュールが追加され、スマートフォン５００はさらに他のデータも保持する。そこで、（１３ｂ）〜（１３ｆ）の変形例において追加される処理モジュールとデータについて、図１６を参照して説明する。
【０３６２】
図１６は、（１３ｂ）〜（１３ｆ）の変形を組み合わせた場合の、スマートフォン５００ａのブロック構成図である。図１６のスマートフォン５００ａは、図５のスマートフォン５００と同様の各種処理モジュールを有し、スマートフォン５００と同様の各種データを保持する。
【０３６３】
さらに、スマートフォン５００ａは、（１３ｂ）の変形例で使われるアプリケーション情報解析部５１９を含む。また、スマートフォン５００ａは、（１３ｃ）の変形例で使われる資源・プロセス名対応表５２０と監視資源フィルタ５２１と既知メンバ検出部５２２を含む。そして、スマートフォン５００ａは、（１３ｄ）の変形例で使われる親子関係判定部５２３も含む。
【０３６４】
さらに、スマートフォン５００ａのプロセス制御モジュール５０３は、（１３ｅ）の変形例で使われる競合判定部５２４を含む。また、スマートフォン５００ａのカーネル５１３は、（１３ｆ）の変形例で使われるメモリ管理モジュール５２５を含む。なお、メモリ管理モジュール５２５の詳細は、図２８とともに後述する。
【０３６５】
図１６のスマートフォン５００ａに追加された上記処理モジュールとデータの詳細は、（１３ｂ）〜（１３ｆ）の変形例についての詳しい説明とともに後述する。
【０３６６】
なお、図示の便宜上、図１６には（１３ｂ）〜（１３ｆ）の変形を組み合わせた場合のスマートフォン５００ａを例示した。しかし、もちろん、（１３ｂ）〜（１３ｆ）の変形は、単独に第２実施形態に適用されてもよい。例えば、（１３ｆ）の変形のみを第２実施形態に適用する場合は、図５のスマートフォン５００のカーネル５１３に図１６のメモリ管理モジュール５２５が追加されるだけで構わない。他の（１３ｂ）〜（１３ｅ）の変形例についても同様に、単独で第２実施形態に適用可能である。
【０３６７】
続いて、使用されないことが明らかな資源をプローブ５０９による監視対象から除外することでプローブ５０９の処理負荷を削減する、（１３ｂ）の変形例について説明する。
【０３６８】
第２実施形態における監視対象資源ファイルリスト５１８は、スマートフォン５００のハードウェア構成に応じて予め設定された静的な情報である。しかし、例えばスマートフォン５００が有する複数の物理デバイス５１５の中には、スマートフォン５００にインストール済みのどのユーザアプリケーションからもアクセスされない物理デバイス５１５があるかもしれない。すると、どのユーザアプリケーションからもアクセスされない物理デバイス５１５へのアクセスをプローブ５０９が監視する必要はない。
【０３６９】
例えば、図１６のスマートフォン５００ａは、物理デバイス５１５の１つとして、図６のＧＰＳ受信機６０１を有するかもしれない。しかし、ＧＰＳ受信機６０１を使用するいかなるアプリケーションも、スマートフォン５００ａにはインストールされていないかもしれない。
【０３７０】
すると、アプリケーションに関連するプロセスグループの認識のためには、ＧＰＳ受信機６０１へのアクセスを監視することは不要である。したがって、ＧＰＳ受信機６０１をプローブ５０９による監視対象から除外することにより、プローブ５０９にかかる不要な負荷をなくすことができる。
【０３７１】
なお、たとえＧＰＳ受信機６０１を使用するアプリケーションがなくても、ＯＳにより提供されるロケーションマネジャ６１３がＧＰＳ受信機６０１を使用する可能性はある。しかし、プロセスグループ判定部５０１が認識しようとする各プロセスグループは、アプリケーションに対応するものである。よって、アプリケーションと無関係にロケーションマネジャ６１３がＧＰＳ受信機６０１にアクセスするのをプローブ５０９が監視する必要はない。
【０３７２】
そこで、（１３ｂ）の変形例では、アプリケーションによって使用されないことが明らかな資源が、プローブ５０９による監視対象から除外される。
具体的には、（１３ｂ）の変形例では、スマートフォン５００ａに実際にインストールされたアプリケーションに応じて監視対象資源ファイルリスト５１８が書き換えられる。そして、監視対象資源ファイルリスト５１８の書き換えのため、スマートフォン５００ａは、アプリケーション情報解析部５１９を備える。また、プローブ５０９は、監視対象資源ファイルリスト５１８の変更に応じて、監視対象を変更する。以下、図１７と１８を参照して、（１３ｂ）の変形例のさらなる詳細を説明する。
【０３７３】
図１７は、（１３ｂ）の変形例においてアプリケーション情報解析部５１９が行う処理のフローチャートである。図１７の処理は、スマートフォン５００ａが起動されると開始される。
【０３７４】
ステップＳ８０１でアプリケーション情報解析部５１９は、インストーラ６１７の動作を監視する。そして、インストーラ６１７によってアプリケーションの追加（すなわちインストール）または削除（すなわちアンインストール）の開始をアプリケーション情報解析部５１９が検出すると、処理はステップＳ８０２に移行する。インストーラ６１７によってその他の処理が行われる場合、あるいは、インストーラ６１７が何も行わない間は、アプリケーション情報解析部５１９はステップＳ８０１で待機する。
【０３７５】
そして、ステップＳ８０２でアプリケーション情報解析部５１９は、追加または削除されるアプリケーションが利用する資源の一覧を作成する。具体的には、アプリケーション情報解析部５１９は、パッケージ情報ＤＢ５０６から利用外部資源名リストを抽出する。
【０３７６】
なお、アプリケーション情報解析部５１９は、追加または削除されるアプリケーションの名前を、インストーラ６１７の監視結果から認識することができる。また、アプリケーション情報解析部５１９は、アプリケーションの追加と削除のどちらが行われるのかも、インストーラ６１７の監視結果から認識することができる。
【０３７７】
アプリケーションが追加される場合、アプリケーション情報解析部５１９は、アプリケーションパッケージ中のパッケージ情報がパッケージ情報ＤＢ５０６に格納され終わるのを待つ。そして、アプリケーション情報解析部５１９は、アプリケーション名を検索キーにしてパッケージ情報ＤＢ５０６を検索し、見つかったエントリから利用外部資源名リストを抽出する。
【０３７８】
また、アプリケーションが削除される場合、アプリケーション情報解析部５１９は、アプリケーションの削除にともなってパッケージ情報ＤＢ５０６からエントリが削除される前に、アプリケーション名を検索キーにしてパッケージ情報ＤＢ５０６を検索する。そして、アプリケーション情報解析部５１９は、見つかったエントリから利用外部資源名リストを抽出する。
【０３７９】
以上のようにして、ステップＳ８０２でアプリケーション情報解析部５１９は、追加または削除されるアプリケーションの利用外部資源名リストを抽出する。しかし、こうして抽出される利用外部資源名リストでは、図７に例示するように、各資源が論理的識別情報により表されている。
【０３８０】
そこで、次のステップＳ８０３でアプリケーション情報解析部５１９は、資源・ファイル対応表５０４を用いて、物理監視対象の一覧を作成する。具体的には、アプリケーション情報解析部５１９は、ステップＳ８０２で作成した一覧に含まれる各論理的識別情報に対応する資源ファイル名を、資源・ファイル対応表５０４から取得し、取得した資源ファイル名の一覧を作成する。
【０３８１】
例えば、ＧＰＳ受信機６０１とサウンドデバイス６０３を使用するアプリケーションが追加または削除されるとする。この場合、ステップＳ８０２で抽出される利用外部資源名リストには、「ＧＰＳ」という文字列で表される論理的識別情報と、「サウンド」という文字列で表される論理的識別情報が含まれる。そこで、アプリケーション情報解析部５１９は、資源・ファイル対応表５０４を参照して、ＧＰＳ受信機６０１とサウンドデバイス６０３にそれぞれ対応する資源ファイル名「／ｄｅｖ／ｔｔｙ１」と「／ｄｅｖ／ｓｎｄ」を取得する。そして、アプリケーション情報解析部５１９は、取得した資源ファイル名の一覧を作成する。
【０３８２】
続いて、ステップＳ８０４でアプリケーション情報解析部５１９は、アプリケーションの追加または削除による監視対象資源ファイルリスト５１８への影響があるか否かを判断する。そして、影響がある場合、処理はステップＳ８０５に移行し、影響がない場合、処理はステップＳ８０１に戻る。
【０３８３】
具体的には、アプリケーション情報解析部５１９は、以下のようにしてステップＳ８０４の判断を行う。
ステップＳ８０１でアプリケーションの追加を検出した場合、アプリケーション情報解析部５１９は、現在の監視対象資源ファイルリスト５１８には含まれない資源ファイル名が、ステップＳ８０３で作成した一覧の中にあるか否かを判断する。
【０３８４】
もし、現在の監視対象資源ファイルリスト５１８には含まれない資源ファイル名が、ステップＳ８０３で作成した一覧の中にあれば、アプリケーション情報解析部５１９は「影響あり」と判断する。逆に、ステップＳ８０３で作成した一覧に含まれるすべての資源ファイル名が、既に監視対象資源ファイルリスト５１８にリストアップされていれば、アプリケーション情報解析部５１９は「影響なし」と判断する。
【０３８５】
また、ステップＳ８０１でアプリケーションの削除を検出した場合、アプリケーション情報解析部５１９は、ステップＳ８０２で作成した一覧に含まれる各資源名について、以下の処理を行う。すなわち、アプリケーション情報解析部５１９は、パッケージ情報ＤＢ５０６を参照して、当該資源名で識別される資源を利用する他のアプリケーションが存在するか否かを確認する。
【０３８６】
そして、もし、削除されるアプリケーション以外のどのアプリケーションによっても利用されない資源が１つ以上見つかれば、アプリケーション情報解析部５１９は、「影響あり」と判断する。逆に、削除されるアプリケーションが利用するすべての資源が、他のいずれかのアプリケーションによっても利用されることが判明すれば、アプリケーション情報解析部５１９は、「影響なし」と判断する。
【０３８７】
ステップＳ８０５でアプリケーション情報解析部５１９は、監視対象資源ファイルリスト５１８を更新する。
具体的には、ステップＳ８０１でアプリケーションの追加を検出した場合、アプリケーション情報解析部５１９は、下記の（１４ａ）と（１４ｂ）の条件をともに満たすすべての資源ファイル名を、監視対象資源ファイルリスト５１８に追加する。
（１４ａ）現在の監視対象資源ファイルリスト５１８には含まれない
（１４ｂ）ステップＳ８０３で作成した一覧には含まれる
【０３８８】
ステップＳ８０１でアプリケーションの削除を検出した場合、アプリケーション情報解析部５１９は、削除されるアプリケーション以外のどのアプリケーションによっても利用されない資源の資源ファイル名を、監視対象資源ファイルリスト５１８から削除する。
【０３８９】
そして、次のステップＳ８０６でアプリケーション情報解析部５１９は、資源依存関係表５０５のエントリを追加または削除する。ステップＳ８０６の意味と詳細は以下のとおりである。
【０３９０】
第２実施形態では、監視対象資源ファイルリスト５１８は静的なデータである。そして、図１０に関して説明したとおり、資源依存関係表５０５は、「監視対象資源ファイルリスト５１８に含まれる各資源ファイル名に対応するエントリを有し、かつ、各エントリのＰＩＤフィールドはクリアされている」という状態に初期化される。
【０３９１】
それに対して、（１３ｂ）の変形例は、アプリケーションの追加または削除に応じて監視対象資源ファイルリスト５１８が動的に変化し得る。ステップＳ８０６の処理は、監視対象資源ファイルリスト５１８の変化に合わせて資源依存関係表５０５を更新するために行われる。
【０３９２】
したがって、具体的には、ステップＳ８０１でアプリケーションの追加を検出した場合、アプリケーション情報解析部５１９は、ステップＳ８０５で監視対象資源ファイルリスト５１８に追加した各資源ファイル名について、以下の処理を行う。すなわち、アプリケーション情報解析部５１９は、監視対象資源ファイルリスト５１８に追加した資源ファイル名を含む新規エントリを資源依存関係表５０５に追加し、追加したエントリのＰＩＤフィールドをクリアする。
【０３９３】
また、ステップＳ８０１でアプリケーションの削除を検出した場合、アプリケーション情報解析部５１９は、ステップＳ８０５で監視対象資源ファイルリスト５１８から削除した各資源ファイル名に対応するエントリを資源依存関係表５０５から削除する。
【０３９４】
ステップＳ８０６における以上のようなエントリの追加または削除により、アプリケーション情報解析部５１９は、資源依存関係表５０５と監視対象資源ファイルリスト５１８の整合性を保つ。
【０３９５】
そして、次のステップＳ８０７でアプリケーション情報解析部５１９は、監視対象の追加または削除をプローブ５０９に通知する。そして、処理はステップＳ８０１に戻る。なお、ステップＳ８０７での通知を受けたときのプローブ５０９の動作は、図１８とともに後述する。
【０３９６】
なお、アプリケーションが削除されたときのステップＳ８０４の判断の負荷削減のために、監視対象資源ファイルリスト５１８のデータ形式が変形されてもよい。すなわち、監視対象資源ファイルリスト５１８は、資源ファイル名と、当該資源ファイル名に対応する資源を利用するアプリケーションの数とを対応づけるエントリを有するテーブル（以下便宜的に「監視対象資源ファイルテーブル」という）に変形されてもよい。
【０３９７】
アプリケーション情報解析部５１９は、ステップＳ８０１でアプリケーションの追加を検出した場合、ステップＳ８０３で作成した一覧に含まれる各資源ファイルに対応する監視対象資源ファイルテーブルのエントリにおいて、アプリケーションの数を１増やす。逆に、アプリケーション情報解析部５１９は、ステップＳ８０１でアプリケーションの削除を検出した場合は、アプリケーションの数を１減らす。
【０３９８】
すると、アプリケーション情報解析部５１９は、ステップＳ８０１でアプリケーションの削除を検出した場合、ステップＳ８０４において、単に、アプリケーションの数が０のエントリが監視対象資源ファイルテーブルにあるか否かを判断するだけでよい。つまり、多数のアプリケーションがスマートフォン５００にインストールされている場合でも、アプリケーション情報解析部５１９は、パッケージ情報ＤＢ５０６の多数のエントリを参照する必要がない。
【０３９９】
さて、図１８は、（１３ｂ）の変形例においてプローブ５０９が行う処理のフローチャートである。図１８の処理は、スマートフォン５００ａが起動されると開始される。
ステップＳ９０１でプローブ５０９は、監視対象資源ファイルリスト５１８を読み取り、監視対象の資源に対応する資源ファイル５１６を認識する。そして、プローブ５０９は、監視対象資源ファイルリスト５１８で指定される各資源に対するシステムコールの監視を開始する。ステップＳ９０１は図９のステップＳ２０１と同様だが、読み取る対象の監視対象資源ファイルリスト５１８が静的か動的かという点がステップＳ２０１とＳ９０１では異なる。
【０４００】
そして、次のステップＳ９０２でプローブ５０９は、アプリケーション情報解析部５１９から通知されたイベントがあるか否かを確認する。そして、監視対象の追加または削除というイベントがアプリケーション情報解析部５１９から通知されている場合、処理はステップＳ９０３に移行する。逆に、何のイベントもアプリケーション情報解析部５１９から通知されていない場合、処理はステップＳ９０４に移行する。
【０４０１】
ステップＳ９０３でプローブ５０９は、アプリケーション情報解析部５１９により更新された監視対象資源ファイルリスト５１８を参照する。そして、更新された監視対象資源ファイルリスト５１８にしたがって、プローブ５０９は、監視対象デバイスを追加または削除する。ステップＳ９０３の処理は、具体的には、例えば、監視対象デバイスを示すプローブ５０９の内部変数の値を、監視対象資源ファイルリスト５１８の変更に応じて変更する処理である。ステップＳ９０３の実行後、処理はステップＳ９０４に移行する。
【０４０２】
ステップＳ９０４でプローブ５０９は、監視対象の資源に対応する資源ファイル５１６に対するシステムコールの呼び出しを所定の時間待つ。所定の時間以内にシステムコールの呼び出しがあると、処理はステップＳ９０５に移行する。逆に、所定の時間待っても、監視対象の資源に対応する資源ファイル５１６に対するシステムコールの呼び出しがない場合は、処理はステップＳ９０２に戻る。
【０４０３】
そして、ステップＳ９０５でプローブ５０９は、システムコールの種類を判定する。システムコールの種類が、資源獲得のための「オープン」または資源解放のための「クローズ」である場合、処理はステップＳ９０６に移行する。他の種類のシステムコールの場合、処理はステップＳ９０７に移行する。
【０４０４】
そして、ステップＳ９０６でプローブ５０９は、図９のステップＳ２０４と同様に、依存関係管理部５０８に、操作内容、操作対象、および呼び出し元ＰＩＤを通知する。そして、処理はステップＳ９０７に移行する。
【０４０５】
ステップＳ９０７では、図９のステップＳ２０５と同様にシステムコールが実行される。そして、処理はステップＳ９０２に戻る。
なお、以上説明した（１３ｂ）の変形例において、プロセスグループ判定部５０１、プロセス制御モジュール５０３、依存関係管理部５０８、および、切り替えイベント通知部５１２を含むアプリケーション管理マネジャ５１１の動作は、第２実施形態と同じである。
【０４０６】
続いて、上記（１３ｂ）の変形例とは別の観点からプローブ５０９の負荷を削減する、（１３ｃ）の変形例について説明する。具体的には、（１３ｃ）の変形例では、必ず特定プロセスからアクセスされる特定資源が、プローブ５０９による動的な監視対象から除外され、それによってプローブ５０９の負荷が削減される。そして、（１３ｃ）の変形例では、静的な情報を用いることで、特定プロセスを介したアクセスにより特定資源を利用するアプリケーションのプロセスグループに特定プロセスが追加される。また、プローブ５０９とプロセスグループ判定部５０１の動作が第２実施形態とは異なる。
【０４０７】
図１６に関して説明したとおり、（１３ｃ）の変形例では、資源・プロセス名対応表５２０と監視資源フィルタ５２１と既知メンバ検出部５２２が追加される。
資源・プロセス名対応表５２０は、特定資源と特定プロセスを静的に対応づける情報である。また、監視資源フィルタ５２１は、資源・プロセス名対応表５２０と資源・ファイル対応表５０４に基づいて、監視対象から除外される資源ファイル５１６を判別し、監視対象から除外される資源ファイル５１６をプローブ５０９に通知する。そして、既知メンバ検出部５２２は、プロセスグループ判定部５０１からの要求に応じて、資源・プロセス名対応表５２０とプロセス一覧５０７を参照し、特定プロセスのＰＩＤのリストをプロセスグループ判定部５０１に返す。すると、プロセスグループ判定部５０１は、既知メンバ検出部５２２から得たリストに基づいて、特定プロセスをプロセスグループに追加する。
【０４０８】
ここで、資源・プロセス名対応表５２０の具体例である資源・プロセス名対応表５２０ａについて、図７を参照して説明する。図７の資源・プロセス名対応表５２０ａは、特定資源の論理的識別情報としての外部資源名と、特定プロセスのプロセス名を対応づける静的な情報である。図７の例では、資源・プロセス名対応表５２０ａは１つだけエントリを持つが、もちろんエントリの数は任意である。
【０４０９】
図７に例示したエントリでは、サウンドデバイス６０３を論理的に識別する「サウンド」という文字列と、サウンドデーモン６１４のプロセス名（すなわちサウンドデーモン６１４のプログラム名）である「サウンドデーモン」という名前が対応づけられている。このエントリは、次の（１５ａ）と（１５ｂ）を表す。
【０４１０】
（１５ａ）サウンドデバイス６０３という特定資源が、サウンドデーモン６１４という特定プログラムのプロセスである特定プロセスにより占有される。
（１５ｂ）サウンドデバイス６０３という特定資源への、他のプロセスからのアクセスは、特定プロセスであるサウンドデーモン６１４のプロセスを介して行われる。つまり、特定プロセスは特定資源へのインタフェイスを他のプロセスに対して提供する。
【０４１１】
また、資源・プロセス名対応表５２０ａにおいてＰＩＤではなくプロセス名が使われる理由は、資源・プロセス名対応表５２０ａが静的に予め設定される情報だからである。例えば、サウンドデバイス６０３という特定資源とサウンドデーモン６１４という特定プログラムの対応関係は、スマートフォン５００ａのＯＳの設計に応じて静的に決まる。しかし、サウンドデーモン６１４のプロセスに割り当てられるＰＩＤは、スマートフォン５００ａが起動するたびに異なる可能性がある。そこで、サウンドデーモン６１４のプロセスを識別することが可能な情報であり、かつ静的な情報でもあるプロセス名が、資源・プロセス名対応表５２０ａでは使われる。
【０４１２】
また、特定資源の場合は、資源・プロセス名対応表５２０ａのいずれかのエントリの「外部資源名」フィールドに論理的識別情報が登録されている。他方、特定資源以外の資源の場合は、資源・プロセス名対応表５２０ａのどのエントリにも論理的識別情報が登録されていない。よって、特定資源と他の資源の区別は、資源・プロセス名対応表５２０ａから判定可能である。
【０４１３】
他方、図７の資源・ファイル対応表５０４ａの「フラグ」フィールドも、特定資源と他の資源を区別するための情報である。したがって、資源・プロセス名対応表５２０ａが使われる場合、資源・ファイル対応表５０４ａの「フラグ」フィールドはなくてもよい。
【０４１４】
続いて、図１９を参照して、（１３ｃ）の変形例において監視資源フィルタ５２１が行う処理について説明する。図１９の処理も、スマートフォン５００ａが起動すると開始される。
【０４１５】
ステップＳ１００１で監視資源フィルタ５２１は、資源・プロセス名対応表５２０を読み取る。また、次のステップＳ１００２で監視資源フィルタ５２１は、資源・ファイル対応表５０４を読み取る。
【０４１６】
そして、次のステップＳ１００３で、監視資源フィルタ５２１は、プローブ５０９による監視対象から除外する物理資源を特定し、特定した物理資源をプローブ５０９に通知する。具体的には、監視資源フィルタ５２１は、資源・プロセス名対応表５２０の各エントリについて、当該エントリの外部資源名を検索キーにして資源・ファイル対応表５０４を検索し、外部資源名に対応する資源ファイル名を取得する。そして、監視資源フィルタ５２１は、取得した資源ファイル名のリストをプローブ５０９に通知する。
【０４１７】
例えば、資源・プロセス名対応表５２０が図７の資源・プロセス名対応表５２０ａのとおりであるとし、資源・ファイル対応表５０４が図７の資源・ファイル対応表５０４ａのとおりであるとする。すると、ステップＳ１００３で監視資源フィルタ５２１は、資源・プロセス名対応表５２０ａのエントリの「サウンド」という外部資源名を検索キーにして資源・ファイル対応表５０４ａを検索し、「／ｄｅｖ／ｓｎｄ」という資源ファイル名を得る。そして、監視資源フィルタ５２１は、「／ｄｅｖ／ｓｎｄ」という資源ファイル名をプローブ５０９に通知する。
【０４１８】
ステップＳ１００３での通知の後、処理はステップＳ１００４に移行する。そして、ステップＳ１００４で監視資源フィルタ５２１は、資源・プロセス名対応表５２０の更新を監視する。資源・プロセス名対応表５２０が更新されなければ、監視資源フィルタ５２１はステップＳ１００４で待機する。逆に、資源・プロセス名対応表５２０が更新されると、処理はステップＳ１００１に戻る。
【０４１９】
なお、資源・プロセス名対応表５２０が更新されるのは、例えば、サードパーティによるサービスの追加やＯＳのアップグレードなどにともなって、サービスの新規追加や削除が発生した場合、もしくは、サービスの仕様が変更された場合などである。
【０４２０】
ところで、（１３ｂ）と（１３ｃ）の変形は、プローブ５０９の負荷を削減するという目的において共通である。よって、プローブ５０９の負荷削減のためには、（１３ｂ）と（１３ｃ）の変形を組み合わせることが好ましい。そこで、図２０を参照して、（１３ｂ）と（１３ｃ）の変形を組み合わせた場合にプローブ５０９が行う処理について説明する。
【０４２１】
なお、（１３ｃ）の変形のみが採用される場合は、図２０のステップＳ１１０２〜Ｓ１１０３が省略される。また、図２０の処理も、スマートフォン５００ａが起動されると開始される。
【０４２２】
ステップＳ１１０１でプローブ５０９は、監視対象資源ファイルリスト５１８を読み取り、監視対象の資源に対応する資源ファイル５１６を認識する。そして、プローブ５０９は、監視対象資源ファイルリスト５１８で指定される各資源に対するシステムコールの監視を開始する。ステップＳ１１０１は図１８のステップＳ９０１と同様である。
【０４２３】
そして、次のステップＳ１１０２でプローブ５０９は、アプリケーション情報解析部５１９から通知されたイベントがあるか否かを確認する。そして、監視対象の追加または削除というイベントがアプリケーション情報解析部５１９から通知されている場合、処理はステップＳ１１０３に移行する。逆に、何のイベントもアプリケーション情報解析部５１９から通知されていない場合、処理はステップＳ１１０４に移行する。
【０４２４】
ステップＳ１１０３でプローブ５０９は、アプリケーション情報解析部５１９により更新された監視対象資源ファイルリスト５１８を参照する。そして、更新された監視対象資源ファイルリスト５１８にしたがって、プローブ５０９は監視対象デバイスを追加または削除する。ステップＳ１１０３の詳細は図１８のステップＳ９０３と同様である。ステップＳ１１０３の実行後、処理はステップＳ１１０４に移行する。
【０４２５】
ステップＳ１１０４でプローブ５０９は、監視資源フィルタ５２１からの通知（つまり、図１９のステップＳ１００３で行われる通知）があったか否かを確認する。そして、監視資源フィルタ５２１からの通知があった場合、処理はステップＳ１１０５に移行する。逆に、監視資源フィルタ５２１から通知がなかった場合、処理はステップＳ１１０６に移行する。
【０４２６】
ステップＳ１１０５でプローブ５０９は、監視資源フィルタ５２１からの通知に応じて、監視対象デバイスを追加または削除する。ステップＳ１１０５の処理は、具体的には、例えば、監視対象デバイスを示すプローブ５０９の内部変数の値を、監視資源フィルタ５２１から通知された内容に応じて変更する処理である。
【０４２７】
具体的には、今まで監視対象だった物理デバイス５１５が、監視対象ではなくなった場合、プローブ５０９は、監視資源フィルタ５２１からの通知に応じて、監視対象デバイスを削除する。つまり、プローブ５０９は、監視資源フィルタ５２１から通知された資源ファイル名を現在は監視対象として認識している場合、通知された資源ファイル名を監視対象から除外する。
【０４２８】
逆に、今まで監視対象ではなかった物理デバイス５１５が、新たに監視対象になった場合、プローブ５０９は、監視資源フィルタ５２１からの通知に応じて、監視対象デバイスを追加する。つまり、プローブ５０９は、監視対象資源ファイルリスト５１８に含まれる資源ファイル名のうちで現在は監視対象として認識していない資源ファイル名が監視資源フィルタ５２１からの通知に含まれない場合、当該資源ファイル名を監視対象に追加する。
【０４２９】
ステップＳ１１０５の実行後、処理はステップＳ１１０６に移行する。なお、図２０のステップＳ１１０６〜Ｓ１１０９は、図１８のステップＳ９０４〜Ｓ９０７と同様である。
【０４３０】
続いて、（１３ｃ）の変形例におけるプロセスグループ判定部５０１の動作について、図２１を参照して説明する。（１３ｃ）の変形例では、図１１のステップＳ４０６で未注目の利用資源名がなかった場合、ステップＳ４１２の通知の前に、プロセスグループ判定部５０１が図２１のステップＳ１２０１〜Ｓ１２０３の処理を行う。
【０４３１】
すなわち、ステップＳ１２０１でプロセスグループ判定部５０１は、起動したアプリケーションが利用する資源のうちで、もし特定プロセスによって占有される特定資源があれば、特定プロセスのＰＩＤを通知してくれるよう、既知メンバ検出部５２２に要求する。具体的には、ステップＳ１２０１においてプロセスグループ判定部５０１は、ステップＳ４０２で取得した利用資源名のリストを、要求の引数として、既知メンバ検出部５２２に出力する。なお、上記のとおり、ステップＳ４０２で取得される利用資源名の数は０以上である。
【０４３２】
そして、次のステップＳ１２０２でプロセスグループ判定部５０１は、既知メンバ検出部５２２から回答が得られるまで待つ。既知メンバ検出部５２２からの回答が得られると、処理はステップＳ１２０３に移行する。
【０４３３】
なお、ステップＳ１２０１でのプロセスグループ判定部５０１からの要求を受けた既知メンバ検出部５２２は、０個以上のＰＩＤのリストをプロセスグループ判定部５０１に返す。既知メンバ検出部５２２の動作の詳細は、図２２とともに後述する。
【０４３４】
そして、ステップＳ１２０３でプロセスグループ判定部５０１は、既知メンバ検出部５２２から得られた回答リスト中の全ＰＩＤを、プロセスグループメンバ表５０２の、起動したアプリケーションに対応するエントリのＰＩＤリストに追加する。その後、処理はステップＳ４１２に移行する。
【０４３５】
例えば、新たに起動したアプリケーションが、ＧＰＳ受信機６０１と加速度センサ６０２とサウンドデバイス６０３という３つの物理デバイス５１５を利用するとする。この場合、ステップＳ１２０１では、これら３つの物理デバイス５１５の資源名のリストが出力される。
【０４３６】
そして、資源・プロセス名対応表５２０が例えば図７の資源・プロセス名対応表５２０ａのとおりであるとする。つまり、上記３つの物理デバイス５１５のうち、サウンドデバイス６０３のみが特定資源である。したがって、既知メンバ検出部５２２からプロセスグループ判定部５０１が受け取る回答リストには、サウンドデバイス６０３を占有してサウンドデバイス６０３へのアクセスを仲介するサウンドデーモン６１４のプロセスのＰＩＤのみが含まれる。
【０４３７】
よって、プロセスグループ判定部５０１はステップＳ１２０３で、プロセスグループメンバ表５０２における、起動したアプリケーションに対応するエントリのＰＩＤリストに、サウンドデーモン６１４のプロセスのＰＩＤを追加する。
【０４３８】
続いて、（１３ｃ）の変形例における既知メンバ検出部５２２の動作について、図２２を参照して説明する。図２２の処理はスマートフォン５００ａが起動すると開始される。
ステップＳ１３０１で既知メンバ検出部５２２は、プロセスグループ判定部５０１からの要求を受け取るまで待機する。すなわち、プロセスグループ判定部５０１が図２１のステップＳ１２０１で利用資源名のリストを既知メンバ検出部５２２に出力するまで、既知メンバ検出部５２２は待機する。
【０４３９】
既知メンバ検出部５２２がプロセスグループ判定部５０１からの要求を受け取ると、処理はステップＳ１３０２に移行する。そして、ステップＳ１３０２で既知メンバ検出部５２２は、プロセスグループ判定部５０１に返すためのＰＩＤリストを、空に初期化する。
【０４４０】
また、次のステップＳ１３０３で既知メンバ検出部５２２はプロセス一覧５０７を取得する。
そして、次のステップＳ１３０４で既知メンバ検出部５２２は、プロセスグループ判定部５０１からの要求で指定されているリスト中で未注目の利用資源名があるか否かを判断する。
【０４４１】
プロセスグループ判定部５０１からの要求の引数であるリスト中に、まだ既知メンバ検出部５２２が注目していない利用資源名が残っている場合、処理はステップＳ１３０５に移行する。
【０４４２】
逆に、プロセスグループ判定部５０１からの要求の引数であるリスト中のすべての利用資源名に、既知メンバ検出部５２２が既に注目し終わっている場合、処理はステップＳ１３０８に移行する。また、プロセスグループ判定部５０１からの要求の引数であるリストがそもそも空リストの場合も、処理はステップＳ１３０８に移行する。
【０４４３】
ステップＳ１３０５で既知メンバ検出部５２２は、資源・プロセス名対応表５２０に、既知メンバ検出部５２２が現在注目している利用資源名のエントリがあるか否かを判断する。なお、以下では説明の便宜上、既知メンバ検出部５２２が現在注目している利用資源名を「注目資源名」といい、注目資源名で識別される資源を「注目資源」という。
【０４４４】
もし、注目資源名のエントリが資源・プロセス名対応表５２０になければ、注目資源は、特定資源以外の資源である。よって、「注目資源をアプリケーションが利用する」という事実は、アプリケーションのプロセスグループに影響を及ぼさない。したがって、処理はステップＳ１３０４に戻る。
【０４４５】
逆に、注目資源名のエントリが資源・プロセス名対応表５２０にあれば、注目資源は、特定資源である。よって、「注目資源をアプリケーションが利用する」という事実は、アプリケーションのプロセスグループに影響を及ぼす。したがって、処理はステップＳ１３０６に移行する。
【０４４６】
ステップＳ１３０６で既知メンバ検出部５２２は、ステップＳ１３０５で見つかったエントリ（すなわち注目資源名のエントリ）のプロセス名に対応するＰＩＤを、ステップＳ１３０３で取得したプロセス一覧５０７から抽出する。
【０４４７】
例えば、注目資源名が「サウンド」であり、資源・プロセス名対応表５２０が図７の資源・プロセス名対応表５２０ａのとおりであり、ステップＳ１３０３で得られたプロセス一覧５０７が図７のプロセス一覧５０７ａのとおりであるとする。すると、ステップＳ１３０５では、「サウンド」という注目資源名に対応する資源・プロセス名対応表５２０ａのエントリが見つかる。また、見つかったエントリのプロセス名は「サウンドデーモン」である。そして、プロセス一覧５０７ａによれば、「サウンドデーモン」というプロセス名に対応するＰＩＤは１０である。よって、ステップＳ１３０６では１０というＰＩＤが抽出される。
【０４４８】
そして、次のステップＳ１３０７において既知メンバ検出部５２２は、ステップＳ１３０６で抽出したＰＩＤをＰＩＤリストに追加する。そして、処理はステップＳ１３０４に戻る。
【０４４９】
また、ステップＳ１３０８で既知メンバ検出部５２２は、プロセスグループ判定部５０１にＰＩＤリストを返す。そして処理はステップＳ１３０１に戻る。
なお、以上説明した（１３ｃ）の変形例において、プロセス制御モジュール５０３、依存関係管理部５０８、および、切り替えイベント通知部５１２を含むアプリケーション管理マネジャ５１１の動作は、第２実施形態と同じである。
【０４５０】
続いて、動的に子孫プロセスが生成され得る場合にも適切なプロセスグループの認識を可能とするための、（１３ｄ）の変形例について説明する。
プロセスの中には、実行中に子プロセスを生成するものがある。よって、或るアプリケーションに関するプロセスグループに属する或るプロセスが、子プロセスを生成した場合、ユーザが感じる性能を向上させるには、プロセス制御モジュール５０３が子プロセスも親プロセスと同様に制御することが望ましい。つまり、子プロセスも同じプロセスグループに含まれるように、プロセスグループ判定部５０１がプロセスグループメンバ表５０２のデータを生成することが望ましい。そこで、（１３ｄ）の変形例では、親子関係判定部５２３が追加される。
【０４５１】
以下では、（１３ｄ）の変形についての理解の助けとするため、まずプロセスの親子関係について図２３の例を参照して説明する。その後、図２４を参照してプロセスグループ判定部５０１の動作を説明し、図２５を参照して親子関係判定部５２３の動作を説明する。なお、プロセス制御モジュール５０３、依存関係管理部５０８、プローブ５０９、および、切り替えイベント通知部５１２を含む切り替えイベント通知部５１２の動作は、第２実施形態と同様である。
【０４５２】
図２３は、プロセスの親子関係を示す樹形図の例である。図２３の樹形図７００における各ノードは、プロセスを表す。図２３では、各ノードの中にプロセスＩＤ（ＰＩＤ）とプロセス名と親プロセスのＰＩＤが示されている。
【０４５３】
樹形図７００によれば、根ノードに相当するプロセスのプロセス名は「ｉｎｉｔ」である。「ｉｎｉｔ」プロセスは、スマートフォン５００ａが起動されるときに最初に生成されるプロセスなので、ＰＩＤは１であり、親プロセスは存在しない。なお、「ｉｎｉｔ」プロセスは、スマートフォン５００ａが起動している間は常に存在し続ける特殊なプロセスである。
【０４５４】
図２３の例では、「ｉｎｉｔ」プロセスは３つの子プロセスを有する。１つ目の子プロセスは、ＰＩＤが１３０でありプロセス名が「Ｆ１」である。また、２つ目の子プロセスは、ＰＩＤが１５０でありプロセス名が「Ｇ１」である。そして、３つ目の子プロセスは、ＰＩＤが２１０でありプロセス名が「Ｈ１」である。
【０４５５】
さらに、プロセスＦ１は、ＰＩＤが１４０でありプロセス名が「Ｆ２」の子プロセスを有する。
また、プロセスＧ１は、ＰＩＤが１６０でありプロセス名が「Ｇ２」の子プロセスを有する。そして、プロセスＧ２は、ＰＩＤが１７０でありプロセス名が「Ｇ３」の子プロセスを有する。
【０４５６】
また、プロセスＨ１は、ＰＩＤが２２０でプロセス名が「Ｈ２」の子プロセスを有する。
図２３の例では、プロセスＦ１は、ＯＳが提供するプログラムのプロセスであるものとする。したがって、子プロセスＦ２も、ＯＳが提供するプログラムのプロセスである。例えば、子プロセスＦ２が、或るサービスを実質的に提供するプロセスであってもよい。そして、プロセスＦ１は、プロセスＦ２の状態を監視して管理するサービスマネジャのプロセスであってもよい。
【０４５７】
同様に、プロセスＧ１はサービスマネジャのプロセスであってもよく、プロセスＧ２はサービスのプロセスであってもよい。また、サービスの一部の機能が、プロセスＧ２の子プロセスＧ３によって提供されてもよい。
【０４５８】
また、或るアプリケーションパッケージＨが含むバイナリプログラムの数が１つであり、プロセスＨ１は当該１つのバイナリプログラムの実行によって生成されたプロセスであるとする。そして、当該１つのバイナリプログラムは、子プロセスを生成するコードを含んでおり、その結果、プロセスＨ１がプロセスＨ２を生成したとする。
【０４５９】
さらに、アプリケーションパッケージＨは、２つの特定資源を含む、２つ以上の資源を利用するものとする。そして、１つ目の特定資源へのアクセスは、プロセスＦ２のサービスによって提供されるものとし、２つ目の特定資源のアクセスは、プロセスＧ２のサービスによって提供されるものとする。
【０４６０】
すると、プロセスグループ判定部５０１が図１１のフローチャートにしたがってプロセスグループを認識する場合、アプリケーションＨに対応してプロセスグループメンバ表５０２に登録されるＰＩＤリストは、（２１０，１４０，１６０）というリストである。
【０４６１】
しかし、アプリケーションＨの機能の一部はプロセスＨ２により提供される。よって、プロセスグループ判定部５０１が「プロセスＨ２はアプリケーションＨのプロセスグループに属さない」と判定して、プロセス制御モジュール５０３がプロセスＨ２の優先度を下げたり、またはプロセスＨ２を一時停止したりすることは、望ましくない。同様に、アプリケーションＨから特定資源を利用するための機能の一部は、プロセスＧ３により提供されるので、「プロセスＧ３はアプリケーションＨのプロセスグループに属さない」と判定されることも、望ましくない。
【０４６２】
換言すれば、アプリケーションＨを利用するユーザが感じる性能を上げるためには、アプリケーションＨのプロセスグループとして、プロセスＨ２とプロセスＧ３をも含むプロセスグループ７０１をプロセスグループ判定部５０１が認識することが望ましい。そこで、（１３ｄ）の変形例では親子関係判定部５２３が追加され、プロセスグループ判定部５０１による図１１の処理は図２４に示すように変形される。
【０４６３】
すなわち、（１３ｄ）の変形例では、図１１のステップＳ４０６で未注目の利用資源名がなかった場合、ステップＳ４１２の通知の前に、プロセスグループ判定部５０１が図２４のステップＳ１４０１〜Ｓ１４０３の処理を行う。
【０４６４】
具体的には、ステップＳ１４０１でプロセスグループ判定部５０１は、起動したアプリケーションに対応づけて現在プロセスグループメンバ表５０２に記録してあるＰＩＤのリストについて、子孫プロセスの調査を親子関係判定部５２３に要求する。
【０４６５】
例えば、図２３の例では、ステップＳ１４０１の実行時には、プロセスグループメンバ表５０２において、アプリケーションＨに対応するエントリのＰＩＤリストには、２１０、１４０、および１６０という３つのＰＩＤが含まれる。よって、ステップＳ１４０１でプロセスグループ判定部５０１は、（２１０，１４０，１６０）というＰＩＤリストについての子孫プロセスの調査を親子関係判定部５２３に要求する。
【０４６６】
そして、次のステップＳ１４０２でプロセスグループ判定部５０１は、親子関係判定部５２３から返答が得られるまで待つ。親子関係判定部５２３からの返答が得られると、処理はステップＳ１４０３に移行する。
【０４６７】
なお、プロセスグループ判定部５０１が親子関係判定部５２３に引数として渡すＰＩＤリストが示すプロセス集合をＰとすると、ステップＳ１４０２では、集合（Ｐ∪ｄｅｓｃｅｎｄａｎｔ（Ｐ））を表すＰＩＤリストが返される。
【０４６８】
そして、ステップＳ１４０３でプロセスグループ判定部５０１は、親子関係判定部５２３から通知されたすべてのＰＩＤを、起動したアプリケーションに対応づけてプロセスグループメンバ表５０２に記録する。換言すれば、プロセスグループ判定部５０１は、起動したアプリケーションに対応するプロセスグループメンバ表５０２のエントリのＰＩＤリストを、親子関係判定部５２３から通知された結果で置き換える。
【０４６９】
例えば、図２３の例では、親子関係判定部５２３からプロセスグループ７０１を示すＰＩＤのリスト（２１０，２２０，１４０，１６０，１７０）が、プロセスグループメンバ表５０２においてアプリケーションＨに対応するエントリに記録される。そして、処理はステップＳ４１２に移行する。
【０４７０】
なお、図示は省略したが、（１３ｄ）の変形例においてプロセスグループ判定部５０１はさらに、以下のような処理も行う。以下の処理を行う理由は、任意のタイミングで子プロセスが生成され得るからである。
【０４７１】
すなわち、プロセスグループ判定部５０１は、適宜の間隔で定期的に、現在フォアグラウンドで実行中のアプリケーションに対応するプロセスグループメンバ表５０２のエントリからＰＩＤリストを読み取る。そして、プロセスグループ判定部５０１は、読み取ったＰＩＤリストに関して、図２４のステップＳ１４０１と同様にして子孫プロセスの調査を親子関係判定部５２３に要求する。
【０４７２】
さらに、プロセスグループ判定部５０１は、現在フォアグラウンドで実行中のアプリケーションに対応するプロセスグループメンバ表５０２のエントリのＰＩＤリストを、親子関係判定部５２３から通知された結果に置き換える。そして、プロセスグループ判定部５０１は、ステップＳ４１２と同様にプロセスグループメンバ表５０２の更新をプロセス制御モジュール５０３に通知する。プロセス制御モジュール５０３は、プロセスグループ判定部５０１からの通知を契機として、図１２〜１３のステップＳ５０７〜Ｓ５１３の処理を行う。
【０４７３】
さて、図２５は、（１３ｄ）の変形例において親子関係判定部５２３が行う処理のフローチャートである。図２５の処理は、スマートフォン５００ａが起動されると開始される。
【０４７４】
ステップＳ１５０１で親子関係判定部５２３は、プロセスグループ判定部５０１からの指示を待つ。指示がない間、親子関係判定部５２３はステップＳ１５０１で待機する。プロセスグループ判定部５０１からの指示（すなわち図２４のステップＳ１４０１での指示）を親子関係判定部５２３が受け取ると、処理はステップＳ１５０２に移行する。
【０４７５】
ステップＳ１５０２で親子関係判定部５２３は、例えば「ｐｓ」コマンドを用いることにより、プロセス一覧５０７を取得する。なお、（１３ｄ）の変形例におけるプロセス一覧５０７は、ＰＩＤとプロセス名だけでなく、親プロセスのＰＩＤ（すなわちＰＰＩＤ（Parent Process Identifier））を含む。
【０４７６】
そして、次のステップＳ１５０３で親子関係判定部５２３は、取得したプロセス一覧５０７中のＰＰＩＤに基づき、動作中の全プロセス（すなわちプロセス一覧５０７に含まれる全プロセス）の親子関係を示す樹形図を作成する。なお、図２３では理解の助けとするために、樹形図７００中の各ノードに、ＰＩＤだけでなくプロセス名とＰＰＩＤも示してあるが、ステップＳ１５０３で親子関係判定部５２３が作成する樹形図は、少なくとも各ノードがＰＩＤを含んでいればよい。
【０４７７】
また、親子関係判定部５２３がステップＳ１５０３で作成するデータは、樹形図を表すことができるデータであれば、具体的なデータ構造は任意である。例えば、ポインタを用いたツリー構造のデータが使われてもよいし、配列が使われてもよい。
【０４７８】
さらに、次のステップＳ１５０４で親子関係判定部５２３は、プロセスグループ判定部５０１からの調査指示に含まれる各ＰＩＤを、樹形図中から検索する。
【０４７９】
そして、次のステップＳ１５０５で親子関係判定部５２３は、ステップＳ１５０４の検索の結果発見されたいずれかのＰＩＤのノードを根とするサブツリーに含まれるＰＩＤのリストを作成する。
【０４８０】
続いて、ステップＳ１５０６で親子関係判定部５２３は、ステップＳ１５０５で作成したＰＩＤのリストをプロセスグループ判定部５０１に返す。そして、処理はステップＳ１５０１に戻る。
【０４８１】
例えば、ステップＳ１５０３で作成された樹形図が図２３の樹形図７００のとおりであり、プロセスグループ判定部５０１からの調査指示には２１０、１４０、および１６０という３つのＰＩＤが含まれるとする。この場合、ステップＳ１５０４において親子関係判定部５２３は、樹形図７００の中から、ＰＩＤが２１０、１４０、および１６０のプロセスのノードを検索する。
【０４８２】
すると、ステップＳ１５０５において親子関係判定部５２３が作成するリストには、「以下の（１６ａ）〜（１６ｃ）のいずれかのサブツリーに含まれる」という条件を満たすすべてのノードのＰＩＤが含まれる。つまり、ステップＳ１５０５において親子関係判定部５２３は、２１０、２２０、１４０、１６０、および１７０という５つのＰＩＤを含むリストを作成する。
【０４８３】
（１６ａ）ＰＩＤが２１０のプロセスのノードを根とするサブツリー。すなわち、ＰＩＤが２１０のプロセスＨ１のノードと、ＰＩＤが２２０のプロセスＨ２のノードを含むサブツリー。
（１６ｂ）ＰＩＤが１４０のプロセスのノードを根とするサブツリー。すなわち、ＰＩＤが１４０のプロセスＦ２のノードのみを含むサブツリー。
（１６ｃ）ＰＩＤが１６０のプロセスのノードを根とするサブツリー。すなわち、ＰＩＤが１６０のプロセスＧ２のノードと、ＰＩＤが１７０のプロセスＧ３のノードを含むサブツリー。
【０４８４】
続いて、プロセス制御モジュール５０３が一時停止制御を行う場合に、一時停止にともなう副作用を回避するための、（１３ｅ）の変形例について説明する。（１３ｅ）の変形例では、プロセス制御モジュール５０３が競合判定部５２４を含むように変形される。しかし、プロセスグループ判定部５０１、依存関係管理部５０８、プローブ５０９、およびアプリケーション管理マネジャ５１１の動作は第２実施形態と同様である。
【０４８５】
具体的には、（１３ｅ）の変形例では、プロセス制御モジュール５０３による図１２〜１３の処理が図２６のように変形される。すなわち、図１３のステップＳ５１５とＳ５１６の間に図２６のステップＳ１６０１が追加される。また、処理がステップＳ５１６から図１２のステップＳ５０２に戻る際に、ステップＳ５１６とステップＳ５０２の間に図２６のステップＳ１６０１〜Ｓ１６０４が追加される。
【０４８６】
ステップＳ１６０１でプロセス制御モジュール５０３内の競合判定部５２４は、以下の（１７ａ）と（１７ｂ）の条件をともに満たすプロセス（以下「確保中プロセス」という）の集合を認識する。確保中プロセスは、新たにフォアグラウンドになったアプリケーションとの間で資源の競合を生じる他のアプリケーションのプロセスである。
（１７ａ）新たにフォアグラウンドになったアプリケーションが使ういずれかの資源を確保中である
（１７ｂ）フォアグラウンドプロセスグループには属さない
【０４８７】
具体的には、競合判定部５２４は、新たにフォアグラウンドになったアプリケーションが使う資源を、パッケージ情報ＤＢ５０６を参照することで認識する。また、競合判定部５２４は、認識した各資源に対応する資源ファイル名を、資源・ファイル対応表５０４を参照することで認識する。
【０４８８】
そして、競合判定部５２４は、認識した各資源ファイル名で識別される資源ファイルを現在オープンしているプロセスがあるか否かを、資源依存関係表５０５を参照することで認識する。また、もし、競合判定部５２４が認識した資源ファイル名で識別される資源ファイルを現在オープンしているプロセスがあれば、競合判定部５２４は、当該プロセスのＰＩＤも、資源依存関係表５０５から読み取る。
【０４８９】
以上のようにして、競合判定部５２４は、（１７ａ）の条件を満たすプロセスのＰＩＤの集合を得る。また、プロセス制御モジュール５０３は、既にステップＳ５０８でフォアグラウンドプロセスグループを認識しており、プロセス制御モジュール５０３に含まれる競合判定部５２４は、プロセス制御モジュール５０３による認識結果を参照することができる。したがって、ステップＳ１６０１で競合判定部５２４は、確保中プロセスの集合を表すＰＩＤのリストを取得することができる。
【０４９０】
例えば、起動したアプリケーションがＧＰＳ受信機６０１を利用するとする。また、ＧＰＳ受信機６０１は、特定資源ではないものとする。つまり、ＧＰＳ受信機６０１は、ロケーションマネジャ６１３を介さずにアプリケーションから直接アクセス可能な資源である。また、ロケーションマネジャ６１３はＧＰＳ受信機６０１を独占しない。
【０４９１】
さらに、ＧＰＳ受信機６０１の資源ファイル６０９を、他のアプリケーション（例えば、以前に起動され、現在バックグラウンドで実行中か、または一時停止中のアプリケーション）のプロセスが現在オープンしているとする。すると、ステップＳ１６０１では、資源ファイル６０９をオープンしているプロセスのＰＩＤが、確保中プロセスのＰＩＤとして得られる。
【０４９２】
さて、以上のようにして競合判定部５２４により認識された確保中プロセスの集合は、プロセス制御モジュール５０３からも参照可能であるものとする。また、競合判定部５２４によるステップＳ１６０１の実行後、プロセス制御モジュール５０３は、図１３と同様にステップＳ５１６〜Ｓ５１７の繰り返しループ処理を行う。そして、バックグラウンドプロセスグループに属し、かつフォアグラウンドプロセスグループに属さないすべてのプロセスにプロセス制御モジュール５０３が注目し終わると、処理はステップＳ１６０２に移行する。
【０４９３】
そして、ステップＳ１６０２でプロセス制御モジュール５０３は、ステップＳ１６０１で認識した確保中プロセスの集合の中に、ステップＳ１６０３〜Ｓ１６０４の処理対象としてまだ注目していないプロセスが残っているか否かを判断する。
【０４９４】
確保中プロセスの集合の中に未注目のプロセスがまだ残っている場合、処理はステップＳ１６０３に移行する。逆に、すべての確保中プロセスに既にプロセス制御モジュール５０３が注目し終えていれば、符号「Ｉ」に示すように、処理は図１２のステップＳ５０２に戻る。また、ステップＳ１６０１で認識された確保中プロセスの集合がそもそも空である場合も、処理はステップＳ５０２に戻る。
【０４９５】
そして、ステップＳ１６０３でプロセス制御モジュール５０３は、次の確保中プロセスに注目し、注目した確保中プロセスが一時停止中か否かを判断する。図７のプロセス一覧５０７ａの例では省略されているが、プロセス一覧５０７は、各プロセスの状態を示す項目を含んでいてもよい。よって、プロセス制御モジュール５０３は、プロセス一覧５０７を参照することで、注目した確保中プロセスが一時停止中か否かを判断することができる。
【０４９６】
そして、注目した確保中プロセスが一時停止中の場合、処理はステップＳ１６０４に移行する。逆に、注目した確保中プロセスが一時停止中ではない場合（つまりバックグラウンドで実行中の場合）、処理はステップＳ１６０２に戻る。
【０４９７】
そして、ステップＳ１６０４でプロセス制御モジュール５０３は、ステップＳ１６０３で注目した確保中プロセスを再開する。ステップＳ１６０４の処理は、図１４のステップＳ６０３と同様に、シグナルの送信により実現されてもよい。また、ステップＳ１６０４の実行後、処理はステップＳ１６０２に戻る。
【０４９８】
さて、（１３ｅ）の変形例では、プロセス制御モジュール５０３による図１４の処理も、図２７に示すように変形される。
第２実施形態の図１４のステップＳ６０１では、引数で指定された操作の種類が一時停止の場合も再開の場合も、処理がステップＳ６０３へと移行する。それに対して、（１３ｅ）の変形例では、一時停止の場合は処理がステップＳ６０１からステップＳ１７０１へと移行し、再開の場合は図１４と同様に処理がステップＳ６０１からステップＳ６０３へと移行する。
【０４９９】
そして、ステップＳ１７０１でプロセス制御モジュール５０３は、図１４のステップＳ６０５やＳ６０７と同様に、引数のリトライフラグを参照することで、今回のサブルーチンコールがリトライのための呼び出しなのか否かを判断する。リトライのための呼び出しの場合、プロセス制御モジュール５０３は単に引数で指定されたとおりにプロセスを制御すればよいので、処理はステップＳ６０３に移行する。逆に、今回が初めての試みの場合、処理はステップＳ１７０２に移行する。
【０５００】
そして、ステップＳ１７０２でプロセス制御モジュール５０３は、引数で指定されたプロセスが確保中プロセスの集合に属するか否かを判断する。なお、ステップＳ１７０２の処理が実行されるのは、図２６のステップＳ５１７からのサブルーチンコールの場合のみである。よって、既に競合判定部５２４により確保中プロセスの集合は認識されており、プロセス制御モジュール５０３はステップＳ１７０２において確保中プロセスの集合を参照することができる。
【０５０１】
引数で指定されたプロセスが確保中プロセスの集合に属する場合、仮に、引数で指定されたプロセスをプロセス制御モジュール５０３が一時停止してしまうと、新たにフォアグラウンドになったアプリケーションの利用する資源が解放されなくなってしまう。そこで、引数で指定されたプロセスが確保中プロセスの集合に属する場合は、引数で指定されたプロセスの実行を継続させるため、プロセス制御モジュール５０３は、引数で指定されたプロセスに対する積極的な一時停止制御を行わずに、図２７の処理を終える。
【０５０２】
逆に、引数で指定されたプロセスが確保中プロセスの集合に属さない場合は、処理はステップＳ６０３に移行する。
以上の図２６〜２７に示した変形により、プロセス制御モジュール５０３は、実行中の確保中プロセスについては、一時停止を避けて実行を継続させるとともに、一時停止中の確保中プロセスを再開させる。その結果、どの確保中プロセスも実行される。したがって、時間の経過にともない、確保中プロセスは、確保している資源をいずれ解放すると期待される。その結果、新たにフォアグラウンドになったアプリケーションのプロセスは、解放された資源を利用することが可能となる。
【０５０３】
以上説明した（１３ｅ）の変形例によれば、利用する資源が競合するアプリケーションがあっても、プロセス制御モジュール５０３による制御による副作用が避けられる。
例えば、アプリケーションＩがフォアグラウンドで実行されているときに、アプリケーションＩのプロセスが或る資源（例えば加速度センサ６０２）をオープンして確保していたとする。そして、アプリケーションＩのプロセスが加速度センサ６０２を解放する前に、フォアグラウンドアプリケーションが、アプリケーションＩから、加速度センサ６０２を利用しないアプリケーションＪへと切り替えられたとする。
【０５０４】
すると、プロセス制御モジュール５０３が図２６のステップＳ５１５で一時停止操作を選択する場合、切り替えにともなって、アプリケーションＩのプロセスは一時停止される。
【０５０５】
その後、さらにフォアグラウンドアプリケーションがアプリケーションＪからアプリケーションＫへと切り替えられ、アプリケーションＫは加速度センサ６０２を利用するものとする。すると、アプリケーションＫが起動された時点で、加速度センサ６０２は一時停止中のアプリケーションＩのプロセスにより確保されている。
【０５０６】
しかし、上述の（１３ｅ）の変形例によれば、アプリケーションＩのプロセスがステップＳ１６０１で確保中プロセスとして認識され、ステップＳ１６０４で再開される。よって、加速度センサ６０２はいずれ解放される。すなわち、「加速度センサ６０２を確保しているプロセスが一時停止中のため、加速度センサ６０２が解放されず、アプリケーションＫが加速度センサ６０２を利用することができない」といった事態が回避される。
【０５０７】
また、アプリケーションＩのプロセスが加速度センサ６０２を解放する前に、フォアグラウンドアプリケーションが、アプリケーションＩからアプリケーションＫへと切り替えられた場合も、上述の（１３ｅ）の変形例によれば、副作用が避けられる。なぜなら、たとえプロセス制御モジュール５０３が図２６のステップＳ５１５で一時停止操作を選択しても、図２７のステップＳ１７０２の判断に基づき、アプリケーションＩのプロセスは一時停止されないからである。
【０５０８】
なお、（１３ｅ）の変形例は、さらに次のように変形されてもよい。
依存関係管理部５０８は、図１０のステップＳ３０４において、さらに、資源ファイル５１６をクローズしたプロセスのＰＩＤと、クローズされた資源ファイル５１６の名前のペアを競合判定部５２４に通知してもよい。また、競合判定部５２４は、確保中プロセスを上記のようにＰＩＤの集合を用いて管理する代わりに、ＰＩＤと資源ファイル名のペアの集合を用いて管理してもよい。以下では説明の便宜上、ＰＩＤと資源ファイル名のペアを要素として含むリストである「確保中プロセスリスト」が、確保中プロセスの管理用に使われるものとする。
【０５０９】
競合判定部５２４は、依存関係管理部５０８から通知を受けると、「通知されたペアが確保中プロセスリストに含まれ、かつ、通知されたペアのＰＩＤと同じＰＩＤを含む他のペアは確保中プロセスリストに存在しない」という条件が成立するか否かを判断する。そして、当該条件が成立する場合、競合判定部５２４は、依存関係管理部５０８から通知されたペアのＰＩＤを、一時停止制御の対象としてプロセス制御モジュール５０３に通知する。また、競合判定部５２４は、依存関係管理部５０８から通知されたペアを確保中プロセスリストから削除する。
【０５１０】
プロセス制御モジュール５０３は、以上のようにして競合判定部５２４から通知を受けると、競合判定部５２４から通知されたＰＩＤのプロセスに対して、例えば図１４と同様にして、一時停止を試みる。なお、リトライフラグは、初めての試みを示す値に設定される。
【０５１１】
以上のように（１３ｅ）の変形例をさらに変形することにより、一時停止制御の副作用を防ぐ目的で例外的に一時停止を免除されていたプロセスは、資源の解放を契機として、一時停止される。その結果、フォアグラウンドプロセスグループに属するプロセスのために、より多くのＣＰＵ時間とより多くのメモリが利用可能となる。よって、ユーザが感じる性能も、さらに向上すると期待される。
【０５１２】
続いて、メモリ不足の解消のため、プロセスグループを利用した強制終了制御が行われる（１３ｆ）の変形例について説明する。図１６に関して説明したとおり、（１３ｆ）の変形例ではメモリ管理モジュール５２５が追加される。
【０５１３】
図２８は、（１３ｆ）の変形例におけるメモリ管理モジュール５２５の詳細を示すブロック構成図である。図２８には、図１６のスマートフォン５００ａのうちの一部もあわせて図示されている。
【０５１４】
メモリ管理モジュール５２５は、ＯＳのカーネル５１３内に設けられる。メモリ管理モジュール５２５は、強制終了するプロセス５１７を選択するプロセス選択部５２６と、プロセス選択部５２６が選択したプロセス５１７を強制終了させるプロセス強制終了部５２７を含む。また、メモリ管理モジュール５２５は、プロセスグループメンバ表５０２のキャッシュ５２８と、アプリケーション利用時刻表５２９と、強制終了除外プロセスリスト５３０を保持する。
【０５１５】
プロセスグループメンバ表５０２は、カーネル５１３外のプロセスグループ判定部５０１により作成されるデータなので、ユーザメモリ空間内にある。他方、キャッシュ５２８は、カーネルメモリ空間内にある。プロセスグループメンバ表５０２とキャッシュ５２８のデータの内容は同じである。
【０５１６】
なお、ＯＳのアーキテクチャによっては、カーネル５１３の内部とカーネル５１３の外部の双方からアクセス可能なメモリ空間があってもよい。そのようなメモリ空間がある場合、キャッシュ５２８は省略可能である。
【０５１７】
また、アプリケーション利用時刻表５２９は、アプリケーション管理マネジャ５１１内の切り替えイベント通知部５１２からカーネル５１３への通知にともなって、メモリ管理モジュール５２５により更新される。アプリケーション利用時刻表５２９には、起動中の各アプリケーションについて、アプリケーション名と時刻を対応づける情報が記録される。
【０５１８】
アプリケーション利用時刻表５２９の具体例は、図７のアプリケーション利用時刻表５２９ａである。アプリケーション利用時刻表５２９ａの各エントリは、スマートフォン５００ａにおいて起動された状態にある各アプリケーションに対応する。つまり、各エントリは、現在フォアグラウンドもしくはバックグラウンドで実行中か、一時停止中のアプリケーションに対応する。アプリケーション利用時刻表５２９ａには、既に終了したアプリケーションに対応するエントリは含まれない。
【０５１９】
アプリケーション利用時刻表５２９ａの各エントリは、アプリケーションを識別する「アプリケーション名」フィールドと、当該アプリケーションが直近にフォアグラウンドになった時刻を示す「前回利用時刻」フィールドを含む。なお、アプリケーションがフォアグラウンドになった時刻とは、（１８ａ）〜（１８ｃ）のいずれかである。したがって、アプリケーション利用時刻表５２９ａの前回利用時刻は、（１８ａ）〜（１８ｃ）のいずれかのうち直近の時刻である。
【０５２０】
（１８ａ）アプリケーションが新たに起動された時刻
（１８ｂ）バックグラウンドのアプリケーションがフォアグラウンドに遷移した時刻
（１８ｃ）一時停止中のアプリケーションが再開されてフォアグラウンドで実行され始めた時刻
【０５２１】
図７のアプリケーション利用時刻表５２９ａは、以下の（１９ａ）〜（１９ｃ）を表す。
（１９ａ）アプリケーションＤが直近にフォアグラウンドになった時刻はＴＤである。
（１９ｂ）アプリケーションＥが直近にフォアグラウンドになった時刻はＴＥである。
（１９ｃ）現在スマートフォン５００ａ上では、他のアプリケーションは起動されていない。
【０５２２】
なお、（１３ｆ）の変形例では、アプリケーション管理マネジャ５１１内の切り替えイベント通知部５１２が、図８のステップＳ１０４において、さらにメモリ管理モジュール５２５にもアプリケーションの切り替えの発生を通知する。そして、通知を受けたメモリ管理モジュール５２５は、以下のように動作する。
【０５２３】
アプリケーションが終了した場合、メモリ管理モジュール５２５は、終了したアプリケーションに対応するエントリをアプリケーション利用時刻表５２９から削除する。
逆に、新たにアプリケーションが起動した場合、メモリ管理モジュール５２５は、新たに起動したアプリケーションの名前と現在時刻を対応づける新たなエントリを、アプリケーション利用時刻表５２９に追加する。
【０５２４】
また、バックグラウンドで実行中のアプリケーションがフォアグラウンドに遷移した場合、または、一時停止中のアプリケーションが再開されてフォアグラウンドで実行される場合、メモリ管理モジュール５２５は次のように動作する。すなわち、メモリ管理モジュール５２５は、当該アプリケーションに対応するアプリケーション利用時刻表５２９中のエントリを検索し、見つかったエントリの前回利用時刻フィールドに現在時刻を設定する。
【０５２５】
さて、図２８の強制終了除外プロセスリスト５３０は、予め静的に決められたデータであり、強制終了の対象から除外されるプロセスの名前のリストである。例えば、ＯＳが標準的に提供するサービスなどの名前が、強制終了除外プロセスリスト５３０には含まれる。
【０５２６】
強制終了除外プロセスリスト５３０の具体例は、図７の強制終了除外プロセスリスト５３０ａである。強制終了除外プロセスリスト５３０ａによれば、「ｉｎｉｔ」プロセスは強制終了の対象から除外される。また、強制終了除外プロセスリスト５３０ａによれば、ＯＳにより提供されるサービスのうち、サウンドデーモン６１４、ウィンドウシステム６１５、およびアプリケーション管理マネジャ６１６それぞれのプロセスも、強制終了の対象から除外される。しかし、強制終了除外プロセスリスト５３０ａの例によれば、ＯＳにより提供されるサービスのうちロケーションマネジャ６１３とインストーラ６１７は、強制終了の対象から除外されず、場合によっては強制終了され得る。
【０５２７】
また、図７には不図示の他のプロセスがさらに強制終了除外プロセスリスト５３０に含まれていていてもよい。例えば、実施形態によっては、ロケーションマネジャ６１３やインストーラ６１７のプロセス名が、さらに強制終了除外プロセスリスト５３０に含まれていてもよい。
【０５２８】
また、ＯＳが提供するサービスの中には、アプリケーションには開放されていない、ＯＳ自体のみが使うためのサービスもある。例えば、ディスク装置に書き出すデータをメモリ上にキャッシュし、ディスク装置への実際の書き出しを遅延させ、適宜のタイミングでディスク装置への実際の書き出しを行うサービスは、ＯＳ内部で利用されるだけである。例えば以上のような、ＯＳ自体が利用するためのサービスの名前も、強制終了除外プロセスリスト５３０に含まれる。
【０５２９】
さて、図２９は、（１３ｆ）の変形例においてメモリ管理モジュール５２５が行う処理のフローチャートである。図２９の処理は、下記の（２０ａ）かつ（２０ｂ）の場合に開始される。
【０５３０】
（２０ａ）カーネル５１３外のプロセスから、例えば標準ライブラリを介して、メモリ確保のためのシステムコールが呼び出された。
（２０ｂ）ユーザメモリ空間内で確保可能なメモリ容量が、要求されたメモリの量に満たない。
【０５３１】
以下、図２９の処理の流れを説明した後、図７の具体例に沿って図２９の各ステップの詳細について補足説明する。
ステップＳ１８０１でプロセス選択部５２６は、アプリケーション利用時刻表５２９を読み取る。
【０５３２】
そして次のステップＳ１８０２でプロセス選択部５２６は、読み取ったアプリケーション利用時刻表５２９のエントリ数が０か否かを判断する。エントリ数が０の場合、すなわち、現在起動されているアプリケーションが存在しない場合、処理はステップＳ１８０３に移行する。逆に、エントリ数が１以上の場合、すなわち、１つ以上のアプリケーションが起動されている状態の場合、処理はステップＳ１８０８に移行する。
【０５３３】
ステップＳ１８０３でプロセス選択部５２６は、プロセス一覧５０７（すなわち、動作中のすべてのプロセスの一覧）を取得する。
また、次のステップＳ１８０４でプロセス選択部５２６は、強制終了除外プロセスリスト５３０を読み取る。
【０５３４】
そして、次のステップＳ１８０５でプロセス選択部５２６は、ステップＳ１８０３で取得したプロセス一覧５０７のプロセス集合と、ステップＳ１８０４で読み取った強制終了除外プロセスリスト５３０のプロセス集合に差があるか否かを判断する。なお、強制終了除外プロセスリスト５３０のプロセス集合は、プロセス一覧５０７のプロセス集合の部分集合である。
【０５３５】
２つの集合に差がない場合、処理はステップＳ１８０６に移行する。逆に、２つの集合に差がある場合、すなわち、強制終了除外プロセスリスト５３０に含まれないプロセスがプロセス一覧５０７に含まれる場合、処理はステップＳ１８０７に移行する。
【０５３６】
ステップＳ１８０６が実行されるのは、「強制終了除外プロセスリスト５３０に含まれる最低限のプロセスしか動作していないにも関わらず、メモリが不足している」という予期せぬエラーが発生した例外的ケースである。したがって、ステップＳ１８０６でプロセス選択部５２６は、個別のプロセスを強制終了するのではなくスマートフォン５００ａのシステム全体を再起動する（すなわちＯＳを再起動する）ことに決める。
【０５３７】
そして、プロセス選択部５２６はＯＳを再起動する。あるいは、プロセス選択部５２６は、カーネル５１３内の不図示の他のモジュールに対してＯＳの再起動を指示することにより、間接的にＯＳを再起動してもよい。再起動のための適宜の処理の実行後、図２９の処理は終了し、ＯＳが再起動する。
【０５３８】
また、ステップＳ１８０７でプロセス選択部５２６は、ステップＳ１８０５で判明した差分に含まれるプロセスのうち１つをランダムに選択し、選択したプロセスのＰＩＤをプロセス強制終了部５２７に通知する。すると、プロセス強制終了部５２７は、通知されたＰＩＤのプロセスを強制終了する。例えば、プロセス強制終了部５２７は、強制終了のためのシグナルを、通知されたＰＩＤのプロセスに対して送信することで、プロセスを強制終了する。そして、処理はステップＳ１８１４に移行する。
【０５３９】
さて、ステップＳ１８０８が実行されるのは、１つ以上のアプリケーションが実行中の場合である。そこで、プロセス選択部５２６は、ステップＳ１８０１でアプリケーション利用時刻表５２９から読み取った内容から、最後にフォアグラウンドになってからの経過時間が最も長いアプリケーションを選択する。換言すれば、プロセス選択部５２６は、アプリケーション利用時刻表５２９のエントリの中で前回利用時刻が最も古いエントリのアプリケーションを選択する。
【０５４０】
そして、次のステップＳ１８０９でプロセス選択部５２６は、プロセスグループメンバ表５０２を読み、ステップＳ１８０８で選択したアプリケーションのプロセスグループを認識する。
【０５４１】
また、次のステップＳ１８１０でプロセス選択部５２６は、強制終了除外プロセスリスト５３０を読み取る。
そして、次のステップＳ１８１１でプロセス選択部５２６は、ステップＳ１８０９で認識したプロセスグループから、強制終了除外プロセスリスト５３０で指定されているプロセス集合に属するプロセスを除き、除いた結果をプロセス強制終了部５２７に通知する。
【０５４２】
次に、ステップＳ１８１２でプロセス強制終了部５２７は、除かれずに残っているプロセス（すなわち、ステップＳ１８１１でプロセス選択部５２６から通知されたプロセス）をすべて強制終了する。
【０５４３】
そして、ステップＳ１８１３でメモリ管理モジュール５２５は、アプリケーション利用時刻表５２９から、強制終了されたアプリケーション（すなわちステップＳ１８０８で選択されたアプリケーション）のエントリを消去する。消去の後、処理はステップＳ１８１４に移行する。
【０５４４】
ステップＳ１８１４においてメモリ管理モジュール５２５は、メモリ残量（より具体的には、ユーザメモリ空間で新たな割り当てが可能な容量）が基準以上か否かを判断する。そして、メモリ残量が基準以上であれば、図２９の処理は終了する。逆に、メモリ残量が基準未満であれば、処理はステップＳ１８０１に戻る。なお、ステップＳ１８１４における基準は、例えば、第１実施形態に関して説明した（６ａ）〜（６ｄ）の基準のうち1つ以上の適宜の組み合わせであってよい。
【０５４５】
また、以上説明したステップＳ１８０８〜Ｓ１８１３の具体例を、図７を参照しながら説明すれば以下のとおりである。
図７のアプリケーション利用時刻表５２９ａのエントリ数は２なので、処理はステップＳ１８０２からステップＳ１８０８に移行する。ここで、説明の便宜上、時刻ＴＥの方が時刻ＴＤよりも古いとする。すると、ステップＳ１８０８でプロセス選択部５２６はアプリケーションＥを選択する。
【０５４６】
また、プロセスグループメンバ表５０２ａによれば、アプリケーションＥのプロセスグループは３つのプロセスを含み、それら３つのプロセスのＰＩＤは１０と１００２と１０１２である。したがって、ステップＳ１８０９でプロセス選択部５２６は、これら３つのプロセスを含むプロセスプロセスグループを認識する。
【０５４７】
続いて、プロセス選択部５２６は、ステップＳ１８１０で強制終了除外プロセスリスト５３０ａを読み取り、さらに、プロセス一覧５０７を取得する。そして、プロセス選択部５２６は、プロセス一覧５０７を参照することで、強制終了除外プロセスリスト５３０ａにプロセス名が含まれる各プロセスのＰＩＤを認識する。
【０５４８】
図７の例によれば、プロセス選択部５２６は、ステップＳ１８１０で除外対象のプロセスのＰＩＤとして、１、１０、２０、および３０というＰＩＤを認識する。その結果、プロセス選択部５２６は、ステップＳ１８０９で認識したプロセスグループから、除外対象の１０というＰＩＤを除外する。そして、残った１００２と１０１２というＰＩＤをそれぞれ有する２つのプロセスを、ステップＳ１８１２でプロセス強制終了部５２７が強制終了する。そして、ステップＳ１８１３でメモリ管理モジュール５２５は、アプリケーションＥのエントリをアプリケーション利用時刻表５２９ａから削除する。
【０５４９】
なお、複数のアプリケーションが同じ特定資源（例えばサウンドデバイス６０３）を利用する場合、特定プロセス(例えばサウンドデーモン６１４のプロセス）が、両方のアプリケーションのプロセスグループにともに含まれる。すると、ステップＳ１８０９で認識されたプロセスグループの中に、現在フォアグラウンドで実行中のアプリケーションのプロセスグループに属する特定プロセスが含まれることもあり得る。しかし、この特定プロセスを強制終了することは好ましくない。
【０５５０】
そこで、フォアグラウンドで実行されているアプリケーションのプロセスグループに含まれる特定プロセスの強制終了を防ぐには、例えば、次の第１の手法または第２の手法が採られてもよい。
【０５５１】
第１の手法は、特定資源を独占して特定資源へのアクセスを提供する特定プロセスのプロセス名が、必ず強制終了除外プロセスリスト５３０に含まれるように、強制終了除外プロセスリスト５３０を予め定義しておく手法である。
【０５５２】
第２の手法は、アプリケーション利用時刻表５２９のエントリ数が２以上の場合にプロセス選択部５２６が次のように動作する手法である。
プロセス選択部５２６は、ステップＳ１８０８でさらに、経過時間が最も短いアプリケーション（すなわちフォアグラウンドで現在実行中のアプリケーション）を認識する。そして、プロセス選択部５２６は、ステップＳ１８０９でさらに、フォアグラウンドで実行中のアプリケーションのプロセスグループ（便宜上、「フォアグラウンドプロセスグループ」という）を認識する。また、プロセス選択部５２６は、ステップＳ１８１１でさらに、フォアグラウンドプロセスグループに属するプロセスも、強制終了の対象から除外する。
【０５５３】
第１の手法は、各々が特定資源を独占して特定資源へのアクセスを提供する特定プロセスが複数存在する場合に、一律にすべての特定プロセスを強制終了の対象から除外する手法である。それに対して、第２の手法は、複数の特定プロセスがある場合に、フォアグラウンドで実行中のアプリケーションとは無関係な特定プロセスを強制終了させることができる。そして、そのぶんだけ、第１の手法よりも割り当て可能なメモリの量を増やすことができる。
【０５５４】
続いて、プローブ５０９の実装に関する（１３ｇ）の変形例について説明する。図５と１６のいずれにおいても、プローブ５０９はカーネル５１３の一部である。カーネル５１３がプローブ５０９を含む実施形態には、プローブ５０９によるシステムコールの監視のオーバヘッドが少ないという利点がある。
【０５５５】
しかし、必ずしもカーネル５１３がプローブ５０９を含まなくてもよい。プローブ５０９は、システムコールの呼び出しを検出することさえできれば、カーネル５１３の外部に実装されていてもよい。
【０５５６】
例えば、システムの性能情報取得などを目的としたカーネルインタフェイスとして、システムコールのフックが予め用意されている場合がある。フックを利用すれば、システムコールが呼ばれたときにユーザ空間内のプログラムを呼び出すことが可能である。よって、プローブ５０９のプログラムは、ユーザ空間内のプログラムであってもよい。
【０５５７】
または、ＯＳによって提供される基本ライブラリ内にプローブ５０９のモジュールが追加されてもよい。
次に、プロセス制御モジュール５０３による保留プロセスリストを用いる制御に関する（１３ｈ）の変形例について説明する。（１３ｈ）の変形例では、保留プロセスリストに含まれるプロセスに対する操作の再失敗を防ぐための仕組みが導入される。
【０５５８】
図１４、１５、または２７のようなプロセス制御モジュール５０３によるプロセスに対する操作が失敗し得るのは、例えば、操作対象のプロセスが何らかのシステムコールを実行中の場合である。そこで、操作対象のプロセスからのシステムコールを抑制することによってプロセス制御モジュール５０３による操作の再失敗を防ぐような仕組みが導入されてもよい。
【０５５９】
例えば、カーネル５１３または基本ライブラリに、システムコールの実行を抑制する対象のプロセスを外部から指定するためのインタフェイスが追加されてもよい。プロセス制御モジュール５０３は、保留プロセスリストにＰＩＤと操作内容のペアを追加するときに、上記の追加されたインタフェイスに対して、当該ＰＩＤを指定する。
【０５６０】
すると、たとえ保留プロセスリストにＰＩＤが含まれるプロセスがシステムコールを呼び出しても、呼び出しはすぐにカーネル５１３によって拒絶され、システムコールは実行されない。よって、プロセス制御モジュール５０３が保留プロセスリストにしたがってリトライ処理を行う際の、操作の成功率が高まる。
【０５６１】
また、プロセス制御モジュール５０３によるプロセスに対する操作は、操作対象のプロセスが何らかの資源を確保している場合にも失敗することがある。そこで、プロセス制御モジュール５０３は、プロセスに強制的に資源を解放させることで、操作の再失敗を防いでもよい。
【０５６２】
例えば、保留プロセスリストの各要素が、ＰＩＤと操作内容だけでなくリトライ回数も含むように変形されてもよい。そして、プロセス制御モジュール５０３は、所定回数のリトライを繰り返してもなお資源を確保しているプロセスに対して、次回のリトライを成功させるため、資源の解放を強制してもよい。
【０５６３】
続いて、以上説明した第２実施形態と（１３ａ）〜（１３ｈ）の変形例と、図１の第１実施形態について比較する。
図１の使用資源情報１１１は、例えば、図６の依存関係情報６１８から抽出されてパッケージ情報ＤＢ６０６（つまり図５のパッケージ情報ＤＢ５０６）に格納された情報に対応する。
【０５６４】
また、図１の対応づけ情報１１２は、例えば、図７の資源・プロセス名対応表５２０ａのように資源名とプロセス名を直接対応づける情報を含んでもよい。対応づけ情報１１２は、プロセス一覧５０７ａのようにプロセス名とＰＩＤを対応づける情報と、資源・ファイル対応表５０４ａのように論理的な資源名と物理的な資源ファイル名を対応づける情報の、一方または双方を、さらに含んでもよい。
【０５６５】
あるいは、図１の対応づけ情報１１２は、図７の資源・ファイル対応表５０４ａのように、特定資源と他の資源を区別するフラグと、特定資源を識別する情報としての資源ファイル名とを対応づける情報を含んでもよい。そして、対応づけ情報１１２は、さらに資源依存関係表５０５ａのように資源ファイル名とＰＩＤを対応づける情報を含んでもよい。すると、資源ファイル名を介して、特定資源と特定プロセスのＰＩＤが対応づけ情報１１２において対応づけられる。
【０５６６】
もちろん、資源・ファイル対応表５０４ａの代わりに資源依存関係表５０５ａにフラグフィールドが設けられていてもよい。あるいは、資源・ファイル対応表５０４ａと資源依存関係表５０５ａが、１つのテーブルにまとめられていてもよい。
【０５６７】
また、図１の構成情報１１３は、例えば、図６の構成情報６１９から抽出されてパッケージ情報ＤＢ６０６（つまり図５のパッケージ情報ＤＢ５０６）に格納された情報に対応する。
【０５６８】
そして、図１の認識部１０３による認識結果１１４は、プロセスグループメンバ表５０２に対応する。すなわち、プロセスグループを認識する認識部１０３は、プロセスグループ判定部５０１に対応する。
【０５６９】
そして、図１においてプロセスを制御する制御部１０５は、プロセス制御モジュール５０３、メモリ管理モジュール５２５、またはその組み合わせに対応する。また、入力部１０６は入力部５１０に対応し、資源監視部１０７はプローブ５０９と依存関係管理部５０８の組み合わせに対応する。そして、メモリ監視部１０８はメモリ管理モジュール５２５に対応する。
【０５７０】
ところで、第２実施形態と（１３ａ）〜（１３ｈ）の変形例には、以下のように様々な利点がある。
プロセスグループ判定部５０１によって判定されるプロセスグループが、プロセス制御モジュール５０３による制御の単位として好適であることは上述したとおりである。そして、好適なプロセスグループを利用することにより、ユーザが感じる性能を上げることができるのも、上述したとおりである。
【０５７１】
さらに、プロセス制御モジュール５０３が一時停止制御を行う場合、第２実施形態と（１３ａ）〜（１３ｈ）の変形例には、消費電力を低減する効果もある。
また、上記のとおり、プロセスグループの認識と、プロセスグループに基づくプロセスの制御は、自動的に行われる。また、予めスマートフォン５００のＯＳまたはアプリケーションの設計者等がチューニングを行う必要はない。
【０５７２】
例えば、資源・ファイル対応表５０４は、予め作られる情報だが、設計者が特に資源・ファイル対応表５０４をチューニングする必要はない。資源・ファイル対応表５０４は、スマートフォン５００のハードウェア構成とＯＳの仕様から単純に定義することができる。
【０５７３】
また、実施形態によっては監視対象資源ファイルリスト５１８が予め作られることもあるが、その場合でも、監視対象資源ファイルリスト５１８は、スマートフォン５００のハードウェア構成とＯＳの仕様から単純に定義することができる。同様に、実施形態によっては、強制終了除外プロセスリスト５３０が予め作られることもあるが、強制終了除外プロセスリスト５３０もＯＳの仕様から単純に定義することができる。
【０５７４】
また、パッケージ情報ＤＢ５０６は、インストーラ６１７によって自動的に作成される既存のＤＢであってもよいし、既存のＤＢに含まれる情報の一部を抽出した別のＤＢであってもよい。いずれにしろ、パッケージ情報ＤＢ５０６の各エントリは、アプリケーションパッケージに含まれる既存の情報から抽出されるので、パッケージ情報ＤＢ５０６を作成するためにアプリケーション開発者に新たなデータ作成の手間をかけさせるようなことにはならない。
【０５７５】
また、例えば産業用ロボットの制御用のコンピュータなど、限られたアプリケーションしかインストールされない環境では、限られたアプリケーションに関する知識に基づいてチューニングされた方針にしたがって、プロセスグループが管理されることがある。しかし、スマートフォン５００のように任意のアプリケーションがインストールされ得る環境では、そのようなチューニングは現実的ではなく、困難である。
【０５７６】
例えば、一般のユーザはチューニングをするのに十分な知識を持たない。また、専門家たるアプリケーション開発者といえども、同じスマートフォン５００にインストールされ得る非常に多数の他のアプリケーションについて十分な知識を持つとは限らない。
【０５７７】
第２実施形態とその変形例によれば、困難なチューニングをせずとも、スマートフォン５００のハードウェア構成とＯＳの仕様から単純に定義することのできる設定ファイルを利用することで、自動的に適切なプロセスグループによる制御が行われる。プロセスグループ管理のためのチューニングが不要なことは非常に大きな利点である。また、アプリケーション開発者は、他のアプリケーションを考慮したチューニングを行う必要がないので、アプリケーション開発の自由度も高まると期待される。
【０５７８】
さらに、第２実施形態とその変形例によれば、プロセスグループの認識のために使われる情報は、予め決められた情報か、ある特定のイベントが発生したときに取得される情報である。換言すれば、リアルタイムにプロセスの振る舞いすべてをトレースする仕組みがなくても、第２実施形態とその変形例によれば、適切なプロセスグループが認識される。リアルタイムのトレースは負荷が非常に大きく、ユーザに性能低下を感じさせてしまう要因なので、リアルタイムのトレースが不要なことは大きな利点である。
【０５７９】
例えば、プローブ５０９はシステムコールを監視するが、プロセスの振る舞いすべてをトレースするのに比べれば、プローブ５０９の負荷は遥かに小さい。また、プローブ５０９の監視対象は限定されているので、その分、負荷も小さい。さらに、（１３ｂ）、（１３ｃ）、またはその双方の変形を組み合わせることで、プローブ５０９の負荷はさらに軽減される。
【０５８０】
また、或る種のＯＳでは、資源の獲得を待つためのキューを参照することで、プロセス間の資源の競合を検出可能である。例えば、第１のプロセスが資源の獲得を要求したときに第２のプロセスが既に当該資源を利用中であれば、第１のプロセスはキューに登録され、資源が解放されるまで待つ。
【０５８１】
しかし、スマートフォン、タブレット端末、ＰＣなどで一般的なＯＳにはそのようなキューがない。そのため、第１のプロセスが資源の獲得を要求したときに第２のプロセスが既に当該資源を利用中であれば、すぐに要求に対して単に「獲得失敗」という結果が返されるだけである。よって、スマートフォン、タブレット端末、ＰＣなどで一般的なＯＳ上では、キューに基づいて資源の競合を検出することはできない。
【０５８２】
しかし、第２実施形態とその変形例によれば、プローブ５０９からの通知に基づいて依存関係管理部５０８が書き換える資源依存関係表５０５により、どのプロセスがどの資源ファイルを現在オープンしているかが判明する。また、どのアプリケーションのプロセスがどの資源を利用する可能性があるかということがパッケージ情報ＤＢ５０６から判明する。よって、資源獲得待ちのためのキューを備えないＯＳが使われる環境でも、資源の競合が検出可能であり、検出結果に応じた適宜の制御が可能である。
【０５８３】
特に、プロセス制御モジュール５０３が競合判定部５２４を含む（１３ｅ）の変形例によれば、他のアプリケーションのプロセスが資源を確保したまま一時停止することによる副作用を回避することができる。
【０５８４】
さらに、（１３ｆ）の変形例において、メモリが不足したときに強制終了するプロセスをプロセス選択部５２６が選択する基準は、「ユーザになるべく不便を感じさせない」という観点において、優れている。
【０５８５】
例えば、第１の比較例として、単純に利用頻度が低いアプリケーションのプロセスから順に強制終了させる方針が考えられる。しかし、インストール直後のアプリケーションの利用頻度は低い。よって、第１の比較例によれば、インストール直後のアプリケーションをユーザがフォアグラウンドで利用しているときにメモリ不足に陥ると、ユーザがまさに利用中のアプリケーションが強制終了されてしまうことがあり、大変不便である。
【０５８６】
また、第２の比較例として、第１の比較例の欠点を克服するために単位時間あたりの利用頻度を利用する方針が考えられる。しかし、第２の比較例には、単位時間あたりの利用頻度を計算するコストがかかるという、別の欠点がある。単位時間を長くすれば計算コストは下がるが、あまり単位時間が長いと、単位時間よりも短い時間以内にインストールされたアプリケーションの利用頻度がゼロとなり、第１の比較例と同じ問題が発生する。逆に、単位時間が短ければ、単位時間の経過のたびに行われる計算のコストが増大する。
【０５８７】
また、第３の比較例として、ランダムにプロセスを強制終了する方針が考えられる。しかし、現在フォアグラウンドで実行中のアプリケーションのプロセスグループに属するプロセスが、偶然強制終了されるおそれがある。
【０５８８】
さらに、第４の比較例として、予め固定的に決められた順序でプロセスを強制終了する方針が考えられる。しかし、任意のアプリケーションがインストールされ得る環境では、予め固定的に順序を定義することは現実的ではない。
【０５８９】
以上のような第１〜第４の比較例と比べると、（１３ｆ）の変形例におけるプロセス選択部５２６の選択基準は優れている。
なぜなら、第１に、アプリケーション利用時刻表５２９が使われるので、フォアグラウンドで実行中のアプリケーションのプロセスグループに属するプロセスが他のアプリケーションのプロセスよりも先に強制終了されることはないからである。つまり、フォアグラウンドで実行中のアプリケーションは、たとえ最近インストールされたものだとしても、「インストールされてからの経過時間が短いせいで先に強制される」という事態には陥らずに済む。
【０５９０】
また、第２に、アプリケーション利用時刻表５２９への時刻の登録を行うコストが、単位時間あたりの利用頻度を単位時間が経過するたびに計算するコストと比べて、非常に小さいからである。
【０５９１】
そして、第３に、プロセスを強制終了する順序を予め固定的に定義する必要もないからである。
また、第４に、プロセス選択部５２６は、個々のプロセスをばらばらに選ぶ代わりに、アプリケーションに注目して１つまたは複数のプロセスをまとめて選ぶからである。マルチプロセスのアプリケーションにおいて、１つのプロセスだけを強制終了した場合、「アプリケーション自体は動作しなくなるにもかかわらず、残りの他のプロセスが終了していないため、無駄にメモリを消費する」といった事態に陥るおそれがある。しかし、プロセス選択部５２６によれば、そのような事態が避けられるので、無駄なメモリ消費を避けられる。
【０５９２】
また、図２８のようにメモリ管理モジュール５２５がカーネル５１３内に含まれる場合、「ユーザメモリ空間でのメモリが不足しているときに、強制終了するプロセスを選択するためにさらにユーザメモリ空間のメモリを消費する」という本末転倒が回避可能である。なぜなら、メモリ管理モジュール５２５のプロセス選択部５２６がプロセスを選択するために行う処理のワーキングエリアはカーネルメモリ空間内にあるからである。
【０５９３】
なお、本発明は上記の実施形態およびその変形例に限られるものではなく、様々に変形可能である。
例えば、マルチスレッドで実行されるプロセスが存在し得る場合、認識部１０３またはプロセスグループ判定部５０１は、プロセスグループではなく、スレッドグループを認識してもよい。プロセスグループとスレッドグループは、単に粒度が違うだけであり、グループの認識のための方法は同じである。
【０５９４】
例えば、「ｐｓ」コマンドによりスレッドの一覧を得ることも可能である。よって、認識部１０３またはプロセスグループ判定部５０１は、プロセスグループを認識するのと同様にして、「ｐｓ」コマンドの出力を利用して、アプリケーションに関連するスレッドグループを認識することもできる。
【０５９５】
また、例えば図４では、「Ｃ」という名前のアプリケーションのパッケージに含まれるメインタスク用のプログラムの名前が「Ｃ１」であるが、メインタスク用のプログラムの名前がアプリケーションの名前と同じ「Ｃ」であってもよい。
【０５９６】
そして、プログラムの名前はプロセスの名前でもあるが、プロセスの名前が非常に長い場合、「ｐｓ」コマンドの出力結果にはプロセスの名前の一部しか含まれないこともあり得る。その場合、プロセス一覧５０７を参照してプロセス名からＰＩＤを得る処理は、プロセス名に関して、文字列の完全一致検索の代わりに、部分一致検索を行う処理を含む。
【０５９７】
また、上記の説明においては、リストやテーブルなどのデータ構造を例示したが、他の適宜のデータ構造が利用されてもよいことは当然である。また、例えばプロセス集合を示すのにＰＩＤのリストが使われてもよいが、リスト内でのＰＩＤの順序によらず、リストが表すプロセス集合は同じである。
【０５９８】
そして、様々なフローチャートを例示したが、フローチャート中のステップの順序は一例にすぎない。ステップの順序は、矛盾が生じない限り適宜入れ替えられてもよい。
【符号の説明】
【０５９９】
１００  端末装置
１０１、１０２、１０４  第１〜第３の記憶部
１０３  認識部
１０５  制御部
１０６、５１０  入力部
１０７  資源監視部
１０８  メモリ監視部
１１１  使用資源情報
１１２  対応づけ情報
１１３、４１３、６１９、６２１  構成情報
１１４  認識結果
２００、３００、４００、５００、６００  スマートフォン
２０１  ＣＰＵ
２０２  ＲＡＭ
２０３  無線ＬＡＮインタフェイス
２０４  フラッシュメモリ
２０５  カードリーダ／ライタ
２０６  入力キー
２０７、６０４  ディスプレイ
２０８  マイク
２０９  スピーカ
２１０  ３Ｇ通信機
２１１、４０９、６０１  ＧＰＳ受信機
２１２、６０２  加速度センサ
２１３  バス
２２０  ＳＤメモリカード
３０１  動画再生アプリケーション
３０２  動画再生モジュール
３０３  ダウンロードモジュール
３０４、４０１、５１３、６０７  カーネル
３０５、４０２〜４０５  サービス
３０６、６０３  サウンドデバイス
３１０  サーバ
３１１  動画ＤＢ
３１２  ファイル転送サービス
３１３  動画ファイル
３２０  ＷＡＮ
３３１〜３３３  動画断片
４０６、５１１、６１６  アプリケーション管理マネジャ
４０７、６１５  ウィンドウシステム
４０８、６１７  インストーラ
４１０、６０５  ファイルシステム
４１１、５０６、５０６ａ、６０６  パッケージ情報ＤＢ
４１２  設定ファイル
４１４、６１８、６２０  依存関係情報
５０１  プロセスグループ判定部
５０２、５０２ａ  プロセスグループメンバ表
５０３  プロセス制御モジュール
５０４、５０４ａ  資源・ファイル対応表
５０５、５０５ａ  資源依存関係表
５０７、５０７ａ  プロセス一覧
５０８  依存関係管理部
５０９  プローブ
５１２  切り替えイベント通知部
５１４、６０８  デバイスドライバ
５１５  物理デバイス
５１６、６０９〜６１２  資源ファイル
５１７  プロセス
５１８、５１８ａ  監視対象資源ファイルリスト
５１９  アプリケーション情報解析部
５２０、５２０ａ  資源・プロセス名対応表
５２１  監視資源フィルタ
５２２  既知メンバ検出部
５２３  親子関係判定部
５２４  競合判定部
５２５  メモリ管理モジュール
５２６  プロセス選択部
５２７  プロセス強制終了部
５２８  プロセスグループメンバ表のキャッシュ
５２９、５２９ａ  アプリケーション利用時刻表
５３０、５３０ａ  強制終了除外プロセスリスト
６１３  ロケーションマネジャ
６１４  サウンドデーモン
７００  樹形図
７０１  プロセスグループ
【図１】
2012127596.tif 000003
【図２】
2012127596.tif 000004
【図３】
2012127596.tif 000005
【図４】
2012127596.tif 000006
【図５】
2012127596.tif 000007
【図６】
2012127596.tif 000008
【図７】
2012127596.tif 000009
【図８】
2012127596.tif 000010
【図９】
2012127596.tif 000011
【図１０】
2012127596.tif 000012
【図１１】
2012127596.tif 000013
【図１２】
2012127596.tif 000014
【図１３】
2012127596.tif 000015
【図１４】
2012127596.tif 000016
【図１５】
2012127596.tif 000017
【図１６】
2012127596.tif 000018
【図１７】
2012127596.tif 000019
【図１８】
2012127596.tif 000020
【図１９】
2012127596.tif 000021
【図２０】
2012127596.tif 000022
【図２１】
2012127596.tif 000023
【図２２】
2012127596.tif 000024
【図２３】
2012127596.tif 000025
【図２４】
2012127596.tif 000026
【図２５】
2012127596.tif 000027
【図２６】
2012127596.tif 000028
【図２７】
2012127596.tif 000029
【図２８】
2012127596.tif 000030
【図２９】
2012127596.tif 000031
【手続補正書】
【提出日】平成25年9月19日(2013.9.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
端末装置であって、
前記端末装置にインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を記憶する第１の記憶部と、
特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を記憶する第２の記憶部と、
前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する認識部と
を備えることを特徴とする端末装置。
【請求項２】
前記認識部は、さらに、前記アプリケーションの実行により生成されるプロセスを前記プロセスグループの要素として認識する
ことを特徴とする請求項１に記載の端末装置。
【請求項３】
前記認識部は、認識した前記プロセスグループに属する任意のプロセスの子孫プロセスを、さらに前記プロセスグループの要素として認識する
ことを特徴とする請求項２に記載の端末装置。
【請求項４】
前記アプリケーションが、起動されるとき、一時停止状態から再開されるとき、バックグラウンドでの実行状態からフォアグラウンドでの実行状態に遷移するとき、またはフォアグラウンドで実行中のときに、前記プロセスグループに含まれるプロセスと前記プロセスグループに含まれないプロセスに対して異なる制御を行う制御部
をさらに備えることを特徴とする請求項２または３に記載の端末装置。
【請求項５】
前記制御部は、前記プロセスグループに含まれるプロセスの優先度を、前記プロセスグループに含まれないプロセスの優先度よりも高くする
ことを特徴とする請求項４に記載の端末装置。
【請求項６】
前記制御部は、前記プロセスグループに含まれるプロセスの実行を継続させ、前記プロセスグループに含まれないプロセスを一時停止させる
ことを特徴とする請求項４に記載の端末装置。
【請求項７】
前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源を確保している確保中プロセスが、前記プロセスグループに含まれない場合、前記制御部は、
前記確保中プロセスが一時停止中であれば、前記確保中プロセスを再開し、
前記確保中プロセスが実行中であれば、前記確保中プロセスの実行を継続させる
ことを特徴とする請求項６に記載の端末装置。
【請求項８】
前記制御部は、前記プロセスグループに含まれるプロセスの実行を継続させ、前記プロセスグループに含まれないプロセスのうち少なくとも一部を強制終了させる
ことを特徴とする請求項４から７のいずれか１項に記載の端末装置。
【請求項９】
前記端末装置において使用可能な複数の資源のうち少なくとも一部に対するオープン操作とクローズ操作を監視し、前記オープン操作を検出したとき、検出した前記オープン操作によりオープンされた資源と、検出した前記オープン操作を呼び出したプロセスとを対応づけ、前記クローズ操作を検出したとき、検出した前記クローズ操作によりクローズされた資源と、検出した前記クローズ操作を呼び出したプロセスとの対応づけを解消する資源監視部をさらに備え、
前記対応づけ情報のうち少なくとも一部は、或る特定プロセスからの或る特定資源に対するオープン操作を前記資源監視部が検出したときに、前記或る特定資源と前記或る特定プロセスを前記資源監視部が対応づけることにより生成されて、前記第２の記憶部に記憶された情報である
ことを特徴とする請求項１〜８のいずれか１項に記載の端末装置。
【請求項１０】
コンピュータが実行するプロセス管理方法であって、
前記コンピュータにインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を取得し、
特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を取得し、
前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する
ことを含むことを特徴とするプロセス管理方法。
【請求項１１】
コンピュータに、
前記コンピュータにインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を取得し、
特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を取得し、
前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する
ことを含む処理を実行させることを特徴とするプロセス管理プログラム。
【国際調査報告】
2012127596.tif 000032
2012127596.tif 000033
2012127596.tif 000034
2012127596.tif 000035