JP5783246B2 - 端末装置、プロセス管理方法、およびプロセス管理プログラム - Google Patents

端末装置、プロセス管理方法、およびプロセス管理プログラム Download PDF

Info

Publication number
JP5783246B2
JP5783246B2 JP2013505671A JP2013505671A JP5783246B2 JP 5783246 B2 JP5783246 B2 JP 5783246B2 JP 2013505671 A JP2013505671 A JP 2013505671A JP 2013505671 A JP2013505671 A JP 2013505671A JP 5783246 B2 JP5783246 B2 JP 5783246B2
Authority
JP
Japan
Prior art keywords
resource
application
information
specific
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013505671A
Other languages
English (en)
Other versions
JPWO2012127596A1 (ja
Inventor
正明 野呂
正明 野呂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2012127596A1 publication Critical patent/JPWO2012127596A1/ja
Application granted granted Critical
Publication of JP5783246B2 publication Critical patent/JP5783246B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/48—Indexing scheme relating to G06F9/48
    • G06F2209/485—Resource constraint

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Description

本発明は、端末装置におけるプロセスの管理に関する。
多くの情報処理装置は、単一のプロセスのみを実行するのではなく、複数のプロセスを実行する。そのため、プロセス間での資源配分や、プロセスのスケジューリングなど、プロセスの管理に関する様々な技術が研究されている。
例えば、１つの情報処理手段上で、制御処理のリアルタイム性の保証およびネットワーク通信処理のスループットの保証をともに実現することを目的とした次のようなコントローラが提案されている。
コントローラは、複数のタスクを、ネットワーク通信系と通信を行うための通信タスクグループと、監視制御対象を監視制御するための制御タスクグループとに分けて管理する。また、コントローラは、複数のタスクの実行順序をグループ単位で切り換え、切り換えられたタスク群にしたがって、監視制御対象またはネットワーク通信系から得られた情報の処理を実行する。
また、時分割スケジューリングを前提としたアプリケーションに対して、実行アプリケーション数が頻繁に増減する環境においてもアプリケーションの応答性能を容易に、かつ自動的に最大限に引き出すことを目的とした、次のような技術も提案されている。
当該技術によれば、アプリケーション依存解析部が、時分割スケジューリング上で動作するプロセスにおける起床から休止までの処理をノードとして扱い、ノード間の依存関係の解析を行い、ノードの実行順序と依存関係とを示す依存解析情報を形成する。また、制御変更判定部が、依存解析情報に基づいて、アプリケーションを構成するプロセスを時分割スケジューリングからグループスケジューリングへ移行させる。そして、グループスケジューリング実行部が、移行したプロセスについて、依存解析情報に基づいて、プロセス単位でグループスケジューリングを実施する。
さらに、オーバヘッドの増加を極力抑えてタスク優先度の逆転現象を防止することを目的とした、次のような技術も提案されている。
低位優先度の第１のタスクが資源管理手段を介して共有資源を専有使用している最中に、高位優先度の第２のタスクから同じ共有資源の使用要求が発行される場合がある。この場合、タスク管理手段は、第１のタスクの優先度を、共有資源の使用終了までの間、第２のタスクの優先度に一時変更する。
優先度の一時変更により、タスク優先度の逆転現象が防止される。すなわち、「第１のタスクによる共有資源の使用中に中位優先度の第３のタスクから割り込みが入って、第１のタスクの処理が後回しになり、結果として、第３のタスクがより優先度の高い第２のタスクより先に処理を行う」という逆転現象が防止される。
また、複数のアプリケーションソフトを起動する場合でのメモリの容量不足を解消して快適な動作環境を実現することを目的とした次のような情報端末装置も提案されている。
情報端末装置は、情報端末装置に搭載された複数のアプリケーションソフトに、常駐型または一時型の属性情報を設定しておき、その属性情報を現在動作中のアプリケーションソフトに対応づけてテーブルで管理する。また、情報端末装置は、アプリケーション起動時に、テーブルを参照して現在動作中のアプリケーションソフトに設定された属性情報を判断する。
そして、情報端末装置は、常駐型の属性情報が設定されたアプリケーションソフトを実行メモリにそのまま残し、一時型の属性情報が設定されたアプリケーションソフトを強制終了して実行メモリから解放する。これにより、「多数のアプリケーションソフトの使用によってメモリ容量が不足となり、実行動作が遅くなったり、ソフトが暴走したりする」などの問題を回避することができる。
特開２００３−６７２０１号公報 特開２００９−４８３５８号公報 特開平８−７７０２５号公報 特開２００３−１５８９２号公報
様々な分野において、様々に異なる用途に、様々なハードウェア構成の装置が利用されている。そのため、ある特定の装置に適したプロセス管理方法が他の装置にも適しているとは限らない。
例えば、或る種の端末装置では、ユーザによるアプリケーションのインストールが制限されている。そして、或る種のプロセス管理方法では、端末装置の性能を引き出すために、「限られた特定のアプリケーションしか実行されない」という前提条件が利用され、限られた特定のアプリケーションに応じたチューニングが行われることがある。
他方、ユーザが任意のアプリケーションをインストールすることのできる端末装置の利用も広まりつつある。ユーザが任意のアプリケーションをインストールすることのできる端末装置においては、上記前提条件が成立しないので、上記の或る種のプロセス管理方法は不適当である。
そこで本発明は、任意のアプリケーションがインストールされ得る端末装置におけるプロセス管理に好適な、プロセスのグルーピングを実現することを目的とする。
一態様により提供される端末装置は、第１の記憶部と第２の記憶部と認識部を含む。前記第１の記憶部は、前記端末装置にインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を記憶する。また、前記第２の記憶部は、特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を記憶する。そして、前記認識部は、前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する。
上記端末装置にインストールされた或るアプリケーションが使用する或る資源へのアクセスが、或る特定プロセスによって提供される場合、上記端末装置によれば、上記認識部により認識されるプロセスグループは、当該或る特定プロセスを含む。つまり、当該或るアプリケーションに関連するプロセスグループの要素として、当該或る特定プロセスが認識される。そして、複数の任意のアプリケーションがインストールされた場合でも、上記端末装置の認識部は、各アプリケーションについて同様にプロセスグループを認識することができる。
以上のようにして認識されるプロセスグループは、例えば、プロセス間の優先度制御、一時停止するプロセスの決定、強制終了するプロセスの決定など、様々なプロセス管理における管理単位として好適である。そして、上記のようにして認識された適切なプロセスグループを用いて適宜のプロセス管理が行われれば、アプリケーション開発者は、他のアプリケーションの実行に支障をきたさないようにするための特別な仕組みを予めアプリケーション内に組み込む必要がない。すなわち、上記端末装置によるプロセスグループの認識は、アプリケーション開発者の負担を減らして開発と設計の自由度を高めるための基盤技術としての潜在力を有する。
以上のように、上記端末装置は、任意のアプリケーションがインストールされ得る端末装置におけるプロセス管理に好適な、プロセスのグルーピングを実現することができる。
第１実施形態の端末装置のブロック構成図である。 スマートフォンのハードウェア構成図である。 適切なプロセスグループの例を説明する図である。 スマートフォンにおけるアプリケーションパッケージの管理を説明する図である。 第２実施形態によるスマートフォンのブロック構成図である。 アプリケーションパッケージと資源とプロセスの具体例を説明する図である。 各種データの具体例を説明する図である。 第２実施形態において切り替えイベント通知部が行う処理のフローチャートである。 第２実施形態においてプローブが行う処理のフローチャートである。 第２実施形態において依存関係管理部が行う処理のフローチャートである。 第２実施形態においてプロセスグループ判定部が行う処理のフローチャートである。 第２実施形態においてプロセス制御モジュールが行う処理のフローチャート（その１）である。 第２実施形態においてプロセス制御モジュールが行う処理のフローチャート（その２）である。 図１２〜１３の処理から呼び出されるサブルーチンのフローチャートである。 第２実施形態の変形例において、図１４のサブルーチンの代わりにプロセス制御モジュールが実行するサブルーチンのフローチャートである。 第２実施形態の変形例によるスマートフォンのブロック構成図である。 第２実施形態の変形例においてアプリケーション情報解析部が行う処理のフローチャートである。 第２実施形態の変形例においてプローブが行う処理のフローチャートである。 第２実施形態の変形例において監視資源フィルタが行う処理のフローチャートである。 第２実施形態の変形例においてプローブが行う処理のフローチャートである。 第２実施形態の変形例においてプロセスグループ判定部が行う処理のフローチャートである。 第２実施形態の変形例において既知メンバ検出部が行う処理のフローチャートである。 プロセスの親子関係を示す樹形図の例である。 第２実施形態の変形例においてプロセスグループ判定部が行う処理のフローチャートである。 第２実施形態の変形例において親子関係判定部が行う処理のフローチャートである。 第２実施形態の変形例においてプロセス制御モジュールが行う処理のフローチャートである。 第２実施形態の変形例において、図１４のサブルーチンの代わりにプロセス制御モジュールが実行するサブルーチンのフローチャートである。 第２実施形態の変形例におけるメモリ管理モジュールの詳細を示すブロック構成図である。 第２実施形態の変形例においてメモリ管理モジュールが行う処理のフローチャートである。
以下、実施形態について、図面を参照しながら詳細に説明する。まず、図１を参照して第１実施形態について説明する。次に、図２〜２９を参照して、第２実施形態および第２実施形態に関するいくつかの変形例について説明する。
図１は、第１実施形態の端末装置のブロック構成図である。図１の端末装置１００は、第１の記憶部１０１と第２の記憶部１０２と認識部１０３を有する。また、端末装置１００はさらに第３の記憶部１０４と制御部１０５を有することが好ましい。端末装置１００はさらに入力部１０６と資源監視部１０７とメモリ監視部１０８を有してもよい。
第１の記憶部１０１と第２の記憶部１０２と第３の記憶部１０４は、物理的には１つのメモリモジュール内の異なる３つの記憶領域であってもよいし、物理的に異なるメモリモジュールであってもよい。また、認識部１０３と制御部１０５と資源監視部１０７とメモリ監視部１０８は、例えば、端末装置１００が備える不図示のＣＰＵ（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つ以上の適宜の組み合わせであってよい。
また、以上説明したステップＳ１８０８〜Ｓ１８１３の具体例を、図７を参照しながら説明すれば以下のとおりである。
図７のアプリケーション利用時刻表５２９ａのエントリ数は２なので、処理はステップＳ１８０２からステップＳ１８０８に移行する。ここで、説明の便宜上、時刻ＴＥの方が時刻ＴＤよりも古いとする。すると、ステップＳ１８０８でプロセス選択部５２６はアプリケーションＥを選択する。
また、プロセスグループメンバ表５０２ａによれば、アプリケーションＥのプロセスグループは３つのプロセスを含み、それら３つのプロセスのＰＩＤは１０と１００２と１０１２である。したがって、ステップＳ１８０９でプロセス選択部５２６は、これら３つのプロセスを含むプロセスプロセスグループを認識する。
続いて、プロセス選択部５２６は、ステップＳ１８１０で強制終了除外プロセスリスト５３０ａを読み取り、さらに、プロセス一覧５０７を取得する。そして、プロセス選択部５２６は、プロセス一覧５０７を参照することで、強制終了除外プロセスリスト５３０ａにプロセス名が含まれる各プロセスのＰＩＤを認識する。
図７の例によれば、プロセス選択部５２６は、ステップＳ１８１０で除外対象のプロセスのＰＩＤとして、１、１０、２０、および３０というＰＩＤを認識する。その結果、プロセス選択部５２６は、ステップＳ１８０９で認識したプロセスグループから、除外対象の１０というＰＩＤを除外する。そして、残った１００２と１０１２というＰＩＤをそれぞれ有する２つのプロセスを、ステップＳ１８１２でプロセス強制終了部５２７が強制終了する。そして、ステップＳ１８１３でメモリ管理モジュール５２５は、アプリケーションＥのエントリをアプリケーション利用時刻表５２９ａから削除する。
なお、複数のアプリケーションが同じ特定資源（例えばサウンドデバイス６０３）を利用する場合、特定プロセス(例えばサウンドデーモン６１４のプロセス）が、両方のアプリケーションのプロセスグループにともに含まれる。すると、ステップＳ１８０９で認識されたプロセスグループの中に、現在フォアグラウンドで実行中のアプリケーションのプロセスグループに属する特定プロセスが含まれることもあり得る。しかし、この特定プロセスを強制終了することは好ましくない。
そこで、フォアグラウンドで実行されているアプリケーションのプロセスグループに含まれる特定プロセスの強制終了を防ぐには、例えば、次の第１の手法または第２の手法が採られてもよい。
第１の手法は、特定資源を独占して特定資源へのアクセスを提供する特定プロセスのプロセス名が、必ず強制終了除外プロセスリスト５３０に含まれるように、強制終了除外プロセスリスト５３０を予め定義しておく手法である。
第２の手法は、アプリケーション利用時刻表５２９のエントリ数が２以上の場合にプロセス選択部５２６が次のように動作する手法である。
プロセス選択部５２６は、ステップＳ１８０８でさらに、経過時間が最も短いアプリケーション（すなわちフォアグラウンドで現在実行中のアプリケーション）を認識する。そして、プロセス選択部５２６は、ステップＳ１８０９でさらに、フォアグラウンドで実行中のアプリケーションのプロセスグループ（便宜上、「フォアグラウンドプロセスグループ」という）を認識する。また、プロセス選択部５２６は、ステップＳ１８１１でさらに、フォアグラウンドプロセスグループに属するプロセスも、強制終了の対象から除外する。
第１の手法は、各々が特定資源を独占して特定資源へのアクセスを提供する特定プロセスが複数存在する場合に、一律にすべての特定プロセスを強制終了の対象から除外する手法である。それに対して、第２の手法は、複数の特定プロセスがある場合に、フォアグラウンドで実行中のアプリケーションとは無関係な特定プロセスを強制終了させることができる。そして、そのぶんだけ、第１の手法よりも割り当て可能なメモリの量を増やすことができる。
続いて、プローブ５０９の実装に関する（１３ｇ）の変形例について説明する。図５と１６のいずれにおいても、プローブ５０９はカーネル５１３の一部である。カーネル５１３がプローブ５０９を含む実施形態には、プローブ５０９によるシステムコールの監視のオーバヘッドが少ないという利点がある。
しかし、必ずしもカーネル５１３がプローブ５０９を含まなくてもよい。プローブ５０９は、システムコールの呼び出しを検出することさえできれば、カーネル５１３の外部に実装されていてもよい。
例えば、システムの性能情報取得などを目的としたカーネルインタフェイスとして、システムコールのフックが予め用意されている場合がある。フックを利用すれば、システムコールが呼ばれたときにユーザ空間内のプログラムを呼び出すことが可能である。よって、プローブ５０９のプログラムは、ユーザ空間内のプログラムであってもよい。
または、ＯＳによって提供される基本ライブラリ内にプローブ５０９のモジュールが追加されてもよい。
次に、プロセス制御モジュール５０３による保留プロセスリストを用いる制御に関する（１３ｈ）の変形例について説明する。（１３ｈ）の変形例では、保留プロセスリストに含まれるプロセスに対する操作の再失敗を防ぐための仕組みが導入される。
図１４、１５、または２７のようなプロセス制御モジュール５０３によるプロセスに対する操作が失敗し得るのは、例えば、操作対象のプロセスが何らかのシステムコールを実行中の場合である。そこで、操作対象のプロセスからのシステムコールを抑制することによってプロセス制御モジュール５０３による操作の再失敗を防ぐような仕組みが導入されてもよい。
例えば、カーネル５１３または基本ライブラリに、システムコールの実行を抑制する対象のプロセスを外部から指定するためのインタフェイスが追加されてもよい。プロセス制御モジュール５０３は、保留プロセスリストにＰＩＤと操作内容のペアを追加するときに、上記の追加されたインタフェイスに対して、当該ＰＩＤを指定する。
すると、たとえ保留プロセスリストにＰＩＤが含まれるプロセスがシステムコールを呼び出しても、呼び出しはすぐにカーネル５１３によって拒絶され、システムコールは実行されない。よって、プロセス制御モジュール５０３が保留プロセスリストにしたがってリトライ処理を行う際の、操作の成功率が高まる。
また、プロセス制御モジュール５０３によるプロセスに対する操作は、操作対象のプロセスが何らかの資源を確保している場合にも失敗することがある。そこで、プロセス制御モジュール５０３は、プロセスに強制的に資源を解放させることで、操作の再失敗を防いでもよい。
例えば、保留プロセスリストの各要素が、ＰＩＤと操作内容だけでなくリトライ回数も含むように変形されてもよい。そして、プロセス制御モジュール５０３は、所定回数のリトライを繰り返してもなお資源を確保しているプロセスに対して、次回のリトライを成功させるため、資源の解放を強制してもよい。
続いて、以上説明した第２実施形態と（１３ａ）〜（１３ｈ）の変形例と、図１の第１実施形態について比較する。
図１の使用資源情報１１１は、例えば、図６の依存関係情報６１８から抽出されてパッケージ情報ＤＢ６０６（つまり図５のパッケージ情報ＤＢ５０６）に格納された情報に対応する。
また、図１の対応づけ情報１１２は、例えば、図７の資源・プロセス名対応表５２０ａのように資源名とプロセス名を直接対応づける情報を含んでもよい。対応づけ情報１１２は、プロセス一覧５０７ａのようにプロセス名とＰＩＤを対応づける情報と、資源・ファイル対応表５０４ａのように論理的な資源名と物理的な資源ファイル名を対応づける情報の、一方または双方を、さらに含んでもよい。
あるいは、図１の対応づけ情報１１２は、図７の資源・ファイル対応表５０４ａのように、特定資源と他の資源を区別するフラグと、特定資源を識別する情報としての資源ファイル名とを対応づける情報を含んでもよい。そして、対応づけ情報１１２は、さらに資源依存関係表５０５ａのように資源ファイル名とＰＩＤを対応づける情報を含んでもよい。すると、資源ファイル名を介して、特定資源と特定プロセスのＰＩＤが対応づけ情報１１２において対応づけられる。
もちろん、資源・ファイル対応表５０４ａの代わりに資源依存関係表５０５ａにフラグフィールドが設けられていてもよい。あるいは、資源・ファイル対応表５０４ａと資源依存関係表５０５ａが、１つのテーブルにまとめられていてもよい。
また、図１の構成情報１１３は、例えば、図６の構成情報６１９から抽出されてパッケージ情報ＤＢ６０６（つまり図５のパッケージ情報ＤＢ５０６）に格納された情報に対応する。
そして、図１の認識部１０３による認識結果１１４は、プロセスグループメンバ表５０２に対応する。すなわち、プロセスグループを認識する認識部１０３は、プロセスグループ判定部５０１に対応する。
そして、図１においてプロセスを制御する制御部１０５は、プロセス制御モジュール５０３、メモリ管理モジュール５２５、またはその組み合わせに対応する。また、入力部１０６は入力部５１０に対応し、資源監視部１０７はプローブ５０９と依存関係管理部５０８の組み合わせに対応する。そして、メモリ監視部１０８はメモリ管理モジュール５２５に対応する。
ところで、第２実施形態と（１３ａ）〜（１３ｈ）の変形例には、以下のように様々な利点がある。
プロセスグループ判定部５０１によって判定されるプロセスグループが、プロセス制御モジュール５０３による制御の単位として好適であることは上述したとおりである。そして、好適なプロセスグループを利用することにより、ユーザが感じる性能を上げることができるのも、上述したとおりである。
さらに、プロセス制御モジュール５０３が一時停止制御を行う場合、第２実施形態と（１３ａ）〜（１３ｈ）の変形例には、消費電力を低減する効果もある。
また、上記のとおり、プロセスグループの認識と、プロセスグループに基づくプロセスの制御は、自動的に行われる。また、予めスマートフォン５００のＯＳまたはアプリケーションの設計者等がチューニングを行う必要はない。
例えば、資源・ファイル対応表５０４は、予め作られる情報だが、設計者が特に資源・ファイル対応表５０４をチューニングする必要はない。資源・ファイル対応表５０４は、スマートフォン５００のハードウェア構成とＯＳの仕様から単純に定義することができる。
また、実施形態によっては監視対象資源ファイルリスト５１８が予め作られることもあるが、その場合でも、監視対象資源ファイルリスト５１８は、スマートフォン５００のハードウェア構成とＯＳの仕様から単純に定義することができる。同様に、実施形態によっては、強制終了除外プロセスリスト５３０が予め作られることもあるが、強制終了除外プロセスリスト５３０もＯＳの仕様から単純に定義することができる。
また、パッケージ情報ＤＢ５０６は、インストーラ６１７によって自動的に作成される既存のＤＢであってもよいし、既存のＤＢに含まれる情報の一部を抽出した別のＤＢであってもよい。いずれにしろ、パッケージ情報ＤＢ５０６の各エントリは、アプリケーションパッケージに含まれる既存の情報から抽出されるので、パッケージ情報ＤＢ５０６を作成するためにアプリケーション開発者に新たなデータ作成の手間をかけさせるようなことにはならない。
また、例えば産業用ロボットの制御用のコンピュータなど、限られたアプリケーションしかインストールされない環境では、限られたアプリケーションに関する知識に基づいてチューニングされた方針にしたがって、プロセスグループが管理されることがある。しかし、スマートフォン５００のように任意のアプリケーションがインストールされ得る環境では、そのようなチューニングは現実的ではなく、困難である。
例えば、一般のユーザはチューニングをするのに十分な知識を持たない。また、専門家たるアプリケーション開発者といえども、同じスマートフォン５００にインストールされ得る非常に多数の他のアプリケーションについて十分な知識を持つとは限らない。
第２実施形態とその変形例によれば、困難なチューニングをせずとも、スマートフォン５００のハードウェア構成とＯＳの仕様から単純に定義することのできる設定ファイルを利用することで、自動的に適切なプロセスグループによる制御が行われる。プロセスグループ管理のためのチューニングが不要なことは非常に大きな利点である。また、アプリケーション開発者は、他のアプリケーションを考慮したチューニングを行う必要がないので、アプリケーション開発の自由度も高まると期待される。
さらに、第２実施形態とその変形例によれば、プロセスグループの認識のために使われる情報は、予め決められた情報か、ある特定のイベントが発生したときに取得される情報である。換言すれば、リアルタイムにプロセスの振る舞いすべてをトレースする仕組みがなくても、第２実施形態とその変形例によれば、適切なプロセスグループが認識される。リアルタイムのトレースは負荷が非常に大きく、ユーザに性能低下を感じさせてしまう要因なので、リアルタイムのトレースが不要なことは大きな利点である。
例えば、プローブ５０９はシステムコールを監視するが、プロセスの振る舞いすべてをトレースするのに比べれば、プローブ５０９の負荷は遥かに小さい。また、プローブ５０９の監視対象は限定されているので、その分、負荷も小さい。さらに、（１３ｂ）、（１３ｃ）、またはその双方の変形を組み合わせることで、プローブ５０９の負荷はさらに軽減される。
また、或る種のＯＳでは、資源の獲得を待つためのキューを参照することで、プロセス間の資源の競合を検出可能である。例えば、第１のプロセスが資源の獲得を要求したときに第２のプロセスが既に当該資源を利用中であれば、第１のプロセスはキューに登録され、資源が解放されるまで待つ。
しかし、スマートフォン、タブレット端末、ＰＣなどで一般的なＯＳにはそのようなキューがない。そのため、第１のプロセスが資源の獲得を要求したときに第２のプロセスが既に当該資源を利用中であれば、すぐに要求に対して単に「獲得失敗」という結果が返されるだけである。よって、スマートフォン、タブレット端末、ＰＣなどで一般的なＯＳ上では、キューに基づいて資源の競合を検出することはできない。
しかし、第２実施形態とその変形例によれば、プローブ５０９からの通知に基づいて依存関係管理部５０８が書き換える資源依存関係表５０５により、どのプロセスがどの資源ファイルを現在オープンしているかが判明する。また、どのアプリケーションのプロセスがどの資源を利用する可能性があるかということがパッケージ情報ＤＢ５０６から判明する。よって、資源獲得待ちのためのキューを備えないＯＳが使われる環境でも、資源の競合が検出可能であり、検出結果に応じた適宜の制御が可能である。
特に、プロセス制御モジュール５０３が競合判定部５２４を含む（１３ｅ）の変形例によれば、他のアプリケーションのプロセスが資源を確保したまま一時停止することによる副作用を回避することができる。
さらに、（１３ｆ）の変形例において、メモリが不足したときに強制終了するプロセスをプロセス選択部５２６が選択する基準は、「ユーザになるべく不便を感じさせない」という観点において、優れている。
例えば、第１の比較例として、単純に利用頻度が低いアプリケーションのプロセスから順に強制終了させる方針が考えられる。しかし、インストール直後のアプリケーションの利用頻度は低い。よって、第１の比較例によれば、インストール直後のアプリケーションをユーザがフォアグラウンドで利用しているときにメモリ不足に陥ると、ユーザがまさに利用中のアプリケーションが強制終了されてしまうことがあり、大変不便である。
また、第２の比較例として、第１の比較例の欠点を克服するために単位時間あたりの利用頻度を利用する方針が考えられる。しかし、第２の比較例には、単位時間あたりの利用頻度を計算するコストがかかるという、別の欠点がある。単位時間を長くすれば計算コストは下がるが、あまり単位時間が長いと、単位時間よりも短い時間以内にインストールされたアプリケーションの利用頻度がゼロとなり、第１の比較例と同じ問題が発生する。逆に、単位時間が短ければ、単位時間の経過のたびに行われる計算のコストが増大する。
また、第３の比較例として、ランダムにプロセスを強制終了する方針が考えられる。しかし、現在フォアグラウンドで実行中のアプリケーションのプロセスグループに属するプロセスが、偶然強制終了されるおそれがある。
さらに、第４の比較例として、予め固定的に決められた順序でプロセスを強制終了する方針が考えられる。しかし、任意のアプリケーションがインストールされ得る環境では、予め固定的に順序を定義することは現実的ではない。
以上のような第１〜第４の比較例と比べると、（１３ｆ）の変形例におけるプロセス選択部５２６の選択基準は優れている。
なぜなら、第１に、アプリケーション利用時刻表５２９が使われるので、フォアグラウンドで実行中のアプリケーションのプロセスグループに属するプロセスが他のアプリケーションのプロセスよりも先に強制終了されることはないからである。つまり、フォアグラウンドで実行中のアプリケーションは、たとえ最近インストールされたものだとしても、「インストールされてからの経過時間が短いせいで先に強制される」という事態には陥らずに済む。
また、第２に、アプリケーション利用時刻表５２９への時刻の登録を行うコストが、単位時間あたりの利用頻度を単位時間が経過するたびに計算するコストと比べて、非常に小さいからである。
そして、第３に、プロセスを強制終了する順序を予め固定的に定義する必要もないからである。
また、第４に、プロセス選択部５２６は、個々のプロセスをばらばらに選ぶ代わりに、アプリケーションに注目して１つまたは複数のプロセスをまとめて選ぶからである。マルチプロセスのアプリケーションにおいて、１つのプロセスだけを強制終了した場合、「アプリケーション自体は動作しなくなるにもかかわらず、残りの他のプロセスが終了していないため、無駄にメモリを消費する」といった事態に陥るおそれがある。しかし、プロセス選択部５２６によれば、そのような事態が避けられるので、無駄なメモリ消費を避けられる。
また、図２８のようにメモリ管理モジュール５２５がカーネル５１３内に含まれる場合、「ユーザメモリ空間でのメモリが不足しているときに、強制終了するプロセスを選択するためにさらにユーザメモリ空間のメモリを消費する」という本末転倒が回避可能である。なぜなら、メモリ管理モジュール５２５のプロセス選択部５２６がプロセスを選択するために行う処理のワーキングエリアはカーネルメモリ空間内にあるからである。
なお、本発明は上記の実施形態およびその変形例に限られるものではなく、様々に変形可能である。
例えば、マルチスレッドで実行されるプロセスが存在し得る場合、認識部１０３またはプロセスグループ判定部５０１は、プロセスグループではなく、スレッドグループを認識してもよい。プロセスグループとスレッドグループは、単に粒度が違うだけであり、グループの認識のための方法は同じである。
例えば、「ｐｓ」コマンドによりスレッドの一覧を得ることも可能である。よって、認識部１０３またはプロセスグループ判定部５０１は、プロセスグループを認識するのと同様にして、「ｐｓ」コマンドの出力を利用して、アプリケーションに関連するスレッドグループを認識することもできる。
また、例えば図４では、「Ｃ」という名前のアプリケーションのパッケージに含まれるメインタスク用のプログラムの名前が「Ｃ１」であるが、メインタスク用のプログラムの名前がアプリケーションの名前と同じ「Ｃ」であってもよい。
そして、プログラムの名前はプロセスの名前でもあるが、プロセスの名前が非常に長い場合、「ｐｓ」コマンドの出力結果にはプロセスの名前の一部しか含まれないこともあり得る。その場合、プロセス一覧５０７を参照してプロセス名からＰＩＤを得る処理は、プロセス名に関して、文字列の完全一致検索の代わりに、部分一致検索を行う処理を含む。
また、上記の説明においては、リストやテーブルなどのデータ構造を例示したが、他の適宜のデータ構造が利用されてもよいことは当然である。また、例えばプロセス集合を示すのにＰＩＤのリストが使われてもよいが、リスト内でのＰＩＤの順序によらず、リストが表すプロセス集合は同じである。
そして、様々なフローチャートを例示したが、フローチャート中のステップの順序は一例にすぎない。ステップの順序は、矛盾が生じない限り適宜入れ替えられてもよい。
１００ 端末装置
１０１、１０２、１０４ 第１〜第３の記憶部
１０３ 認識部
１０５ 制御部
１０６、５１０ 入力部
１０７ 資源監視部
１０８ メモリ監視部
１１１ 使用資源情報
１１２ 対応づけ情報
１１３、４１３、６１９、６２１ 構成情報
１１４ 認識結果
２００、３００、４００、５００、６００ スマートフォン
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ 無線ＬＡＮインタフェイス
２０４ フラッシュメモリ
２０５ カードリーダ／ライタ
２０６ 入力キー
２０７、６０４ ディスプレイ
２０８ マイク
２０９ スピーカ
２１０ ３Ｇ通信機
２１１、４０９、６０１ ＧＰＳ受信機
２１２、６０２ 加速度センサ
２１３ バス
２２０ ＳＤメモリカード
３０１ 動画再生アプリケーション
３０２ 動画再生モジュール
３０３ ダウンロードモジュール
３０４、４０１、５１３、６０７ カーネル
３０５、４０２〜４０５ サービス
３０６、６０３ サウンドデバイス
３１０ サーバ
３１１ 動画ＤＢ
３１２ ファイル転送サービス
３１３ 動画ファイル
３２０ ＷＡＮ
３３１〜３３３ 動画断片
４０６、５１１、６１６ アプリケーション管理マネジャ
４０７、６１５ ウィンドウシステム
４０８、６１７ インストーラ
４１０、６０５ ファイルシステム
４１１、５０６、５０６ａ、６０６ パッケージ情報ＤＢ
４１２ 設定ファイル
４１４、６１８、６２０ 依存関係情報
５０１ プロセスグループ判定部
５０２、５０２ａ プロセスグループメンバ表
５０３ プロセス制御モジュール
５０４、５０４ａ 資源・ファイル対応表
５０５、５０５ａ 資源依存関係表
５０７、５０７ａ プロセス一覧
５０８ 依存関係管理部
５０９ プローブ
５１２ 切り替えイベント通知部
５１４、６０８ デバイスドライバ
５１５ 物理デバイス
５１６、６０９〜６１２ 資源ファイル
５１７ プロセス
５１８、５１８ａ 監視対象資源ファイルリスト
５１９ アプリケーション情報解析部
５２０、５２０ａ 資源・プロセス名対応表
５２１ 監視資源フィルタ
５２２ 既知メンバ検出部
５２３ 親子関係判定部
５２４ 競合判定部
５２５ メモリ管理モジュール
５２６ プロセス選択部
５２７ プロセス強制終了部
５２８ プロセスグループメンバ表のキャッシュ
５２９、５２９ａ アプリケーション利用時刻表
５３０、５３０ａ 強制終了除外プロセスリスト
６１３ ロケーションマネジャ
６１４ サウンドデーモン
７００ 樹形図
７０１ プロセスグループ

Claims (6)

  1. 端末装置であって、
    前記端末装置にインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を記憶する第１の記憶部と、
    特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を記憶する第２の記憶部と、
    前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識し、さらに、前記アプリケーションの実行により生成されるプロセスを前記プロセスグループの要素として認識する認識部と、
    前記アプリケーションが、起動されるとき、一時停止状態から再開されるとき、バックグラウンドでの実行状態からフォアグラウンドでの実行状態に遷移するとき、またはフォアグラウンドで実行中のときに、前記端末装置で実行される各プロセスのうち、前記アプリケーションに関連するプロセスグループに含まれるプロセスの実行を継続させ、前記アプリケーションに関連するプロセスグループに含まれないプロセスを一時停止させる制御を行う制御部と
    を備え、
    前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源を確保している確保中プロセスが、前記アプリケーションに関連するプロセスグループに含まれない場合、前記制御部は、
    前記確保中プロセスが一時停止中であれば、前記確保中プロセスを再開し、
    前記確保中プロセスが実行中であれば、前記確保中プロセスの実行を継続させ、
    前記端末装置は、前記使用資源情報により示される前記資源の前記集合に含まれる資源のうち、少なくとも、前記対応づけ情報により前記特定プロセスと対応づけられていない資源に対するオープン操作とクローズ操作を監視する資源監視部をさらに備え、
    前記制御部は、前記資源監視部による監視結果にしたがって、前記確保中プロセスを識別する
    ことを特徴とする端末装置。
  2. 前記認識部は、認識した前記プロセスグループに属する任意のプロセスの子孫プロセスを、さらに前記プロセスグループの要素として認識する
    ことを特徴とする請求項１に記載の端末装置。
  3. 前記制御部は、前記プロセスグループに含まれるプロセスの実行を継続させ、前記プロセスグループに含まれないプロセスのうち少なくとも一部を強制終了させる
    ことを特徴とする請求項１または２に記載の端末装置。
  4. 端末装置であって、
    前記端末装置にインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を記憶する第１の記憶部と、
    特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を記憶する第２の記憶部と、
    前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識する認識部と、
    前記端末装置において使用可能な複数の資源のうち少なくとも一部に対するオープン操作とクローズ操作を監視し、前記オープン操作を検出したとき、検出した前記オープン操作によりオープンされた資源と、検出した前記オープン操作を呼び出したプロセスとを対応づけ、前記クローズ操作を検出したとき、検出した前記クローズ操作によりクローズされた資源と、検出した前記クローズ操作を呼び出したプロセスとの対応づけを解消する資源監視部と
    を備え、
    前記対応づけ情報のうち少なくとも一部は、或る特定プロセスからの或る特定資源に対するオープン操作を前記資源監視部が検出したときに、前記或る特定資源と前記或る特定プロセスを前記資源監視部が対応づけることにより生成されて、前記第２の記憶部に記憶された情報である
    ことを特徴とする端末装置。
  5. コンピュータが実行するプロセス管理方法であって、
    前記コンピュータにインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を取得し、
    特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を取得し、
    前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識し、
    前記アプリケーションが、起動されるとき、一時停止状態から再開されるとき、バックグラウンドでの実行状態からフォアグラウンドでの実行状態に遷移するとき、またはフォアグラウンドで実行中のときに、前記コンピュータで実行される各プロセスのうち、前記アプリケーションに関連するプロセスグループに含まれるプロセスの実行を継続させ、前記アプリケーションに関連するプロセスグループに含まれないプロセスを一時停止させる制御を行う
    ことを含み、
    前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源を確保している確保中プロセスが、前記アプリケーションに関連するプロセスグループに含まれない場合、前記制御では、
    前記確保中プロセスが一時停止中であれば、前記確保中プロセスを再開し、
    前記確保中プロセスが実行中であれば、前記確保中プロセスの実行を継続させ、
    前記プロセス管理方法は、前記使用資源情報により示される前記資源の前記集合に含まれる資源のうち、少なくとも、前記対応づけ情報により前記特定プロセスと対応づけられていない資源に対するオープン操作とクローズ操作を監視することを更に含み、
    前記制御では、前記監視結果にしたがって、前記確保中プロセスを識別する
    ことを特徴とするプロセス管理方法。
  6. コンピュータに、
    前記コンピュータにインストールされたアプリケーションが使用する資源の集合を示す使用資源情報を取得し、
    特定プロセスによりアクセスが提供される１つ以上の特定資源をそれぞれ前記特定プロセスと対応づける対応づけ情報を取得し、
    前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源に前記対応づけ情報により対応づけられている前記特定プロセスの集合を含む、前記アプリケーションに関連するプロセスグループを認識し、
    前記アプリケーションが、起動されるとき、一時停止状態から再開されるとき、バックグラウンドでの実行状態からフォアグラウンドでの実行状態に遷移するとき、またはフォアグラウンドで実行中のときに、前記コンピュータで実行される各プロセスのうち、前記アプリケーションに関連するプロセスグループに含まれるプロセスの実行を継続させ、前記アプリケーションに関連するプロセスグループに含まれないプロセスを一時停止させる制御を行う
    ことを含む処理を実行させるプロセス管理プログラムであって、
    前記使用資源情報により示される前記資源の前記集合に含まれるいずれかの資源を確保している確保中プロセスが、前記アプリケーションに関連するプロセスグループに含まれない場合、前記制御では、
    前記確保中プロセスが一時停止中であれば、前記確保中プロセスを再開し、
    前記確保中プロセスが実行中であれば、前記確保中プロセスの実行を継続させ、
    前記プロセス管理プログラムは、前記使用資源情報により示される前記資源の前記集合に含まれる資源のうち、少なくとも、前記対応づけ情報により前記特定プロセスと対応づけられていない資源に対するオープン操作とクローズ操作を監視する処理を更に前記コンピュータに実行させ、
    前記制御では、前記監視結果にしたがって、前記確保中プロセスを識別する
    ことを特徴とするプロセス管理プログラム。
JP2013505671A 2011-03-19 2011-03-19 端末装置、プロセス管理方法、およびプロセス管理プログラム Active JP5783246B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/056666 WO2012127596A1 (ja) 2011-03-19 2011-03-19 端末装置、プロセス管理方法、およびプロセス管理プログラム

Publications (2)

Publication Number Publication Date
JPWO2012127596A1 JPWO2012127596A1 (ja) 2014-07-24
JP5783246B2 true JP5783246B2 (ja) 2015-09-24

Family

ID=46878793

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013505671A Active JP5783246B2 (ja) 2011-03-19 2011-03-19 端末装置、プロセス管理方法、およびプロセス管理プログラム

Country Status (4)

Country Link
US (1) US9424085B2 (ja)
JP (1) JP5783246B2 (ja)
CN (1) CN103443770B (ja)
WO (1) WO2012127596A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112018006950B4 (de) 2018-02-28 2022-07-14 Mitsubishi Electric Corporation Ressourcensteuerungseinrichtung, Ressourcensteuerungsverfahren und Ressourcensteuerungsprogramm

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9372716B1 (en) * 2013-09-23 2016-06-21 Amazon Technologies, Inc. Download prioritization
CN104636177A (zh) * 2013-11-11 2015-05-20 中兴通讯股份有限公司 一种终端及其控制后台投影的方法
KR102148948B1 (ko) * 2013-12-06 2020-08-27 삼성전자주식회사 전자 장치의 멀티 태스킹 방법 및 그 전자 장치
KR102277258B1 (ko) * 2014-02-27 2021-07-14 엘지전자 주식회사 디지털 디바이스 및 상기 디지털 디바이스에서 애플리케이션 처리 방법
US9871741B2 (en) * 2014-03-10 2018-01-16 Microsoft Technology Licensing, Llc Resource management based on device-specific or user-specific resource usage profiles
US20160005433A1 (en) * 2014-07-07 2016-01-07 Oaluwaseun Adedeji Application for enhancing a multimedia usage on an electronic device
CN105468441A (zh) * 2014-08-28 2016-04-06 中兴通讯股份有限公司 任务进程的处理方法及装置
CN104239094B (zh) * 2014-08-29 2017-12-08 小米科技有限责任公司 后台应用程序的控制方法、装置及终端设备
CN104268022B (zh) * 2014-09-23 2017-06-27 浪潮(北京)电子信息产业有限公司 一种操作系统中进程的资源分配方法及系统
CN104536822B (zh) * 2014-12-31 2018-03-23 中科创达软件股份有限公司 一种进程调度优化方法、进程执行方法及相关装置
US10019461B2 (en) * 2015-03-26 2018-07-10 Ca, Inc. Transparent and near-real time code deploys
RU2632141C2 (ru) * 2015-06-30 2017-10-02 Общество С Ограниченной Ответственностью "Яндекс" Способ и компьютерное устройство для динамической индексации и загрузки кодов модулей
CN106502767B (zh) * 2015-09-08 2019-11-19 大唐移动通信设备有限公司 一种进程管理方法及其装置
CN105653952B (zh) * 2015-12-23 2019-03-12 北京奇虎科技有限公司 一种远程控制程序的识别方法及装置
DE102016200777A1 (de) * 2016-01-21 2017-07-27 Robert Bosch Gmbh Verfahren und Vorrichtung zum Überwachen und Kontrollieren quasi-paralleler Ausführungsstränge in einem ereignisorientierten Betriebssystem
KR102500608B1 (ko) * 2016-01-28 2023-02-16 삼성전자주식회사 어플리케이션을 제어하는 전자 장치와 이의 동작 방법
US10826310B2 (en) * 2016-03-29 2020-11-03 Huawei Technologies Co., Ltd. Resource statistics collection method and apparatus and terminal
CN107632888A (zh) * 2016-07-18 2018-01-26 中兴通讯股份有限公司 一种应用管理方法及装置、移动终端
US10037230B2 (en) * 2016-07-29 2018-07-31 Hewlett Packard Enterprise Development Lp Managing data processing resources
CN107807847B (zh) * 2016-09-09 2022-04-29 华为技术有限公司 应用进程的管理方法和终端设备
US10860369B2 (en) * 2017-01-11 2020-12-08 International Business Machines Corporation Self-adjusting system for prioritizing computer applications
EP3611615A4 (en) * 2017-04-19 2020-04-29 Guangdong Oppo Mobile Telecommunications Corp., Ltd. METHOD AND DEVICE FOR ACCELERATED START-UP OF AN APPLICATION AND TERMINAL
CN107463403B (zh) * 2017-07-31 2020-04-21 Oppo广东移动通信有限公司 进程控制方法、装置、存储介质以及电子设备
JP7155584B2 (ja) * 2018-03-30 2022-10-19 株式会社リコー 情報処理装置、情報処理方法及び情報処理プログラム
CN109246080B (zh) * 2018-08-03 2021-08-27 广东工业大学 一种资源共享方法、装置、设备及计算机可读存储介质
CN110955498B (zh) * 2019-11-21 2022-03-22 北京浪潮数据技术有限公司 一种进程处理方法、装置、设备及计算机可读存储介质
US12073231B2 (en) * 2021-10-27 2024-08-27 SambaNova Systems, Inc. Fractional force-quit for reconfigurable processors

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09251390A (ja) * 1996-03-15 1997-09-22 Sharp Corp プロセスのプライオリティ設定方法
JP2004078936A (ja) * 2002-07-31 2004-03-11 Matsushita Electric Ind Co Ltd 情報処理端末及び情報処理方法
JP2004310615A (ja) * 2003-04-09 2004-11-04 Sony Corp プログラム処理システム及びプログラム処理方法、並びにコンピュータ・プログラム
JP2009048358A (ja) * 2007-08-17 2009-03-05 Nec Corp 情報処理装置及びスケジューリング方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0357026A (ja) * 1989-07-26 1991-03-12 Hitachi Ltd タスク制御方式
JPH0877025A (ja) 1994-09-01 1996-03-22 Kokusai Electric Co Ltd タスクの優先度制御方法、タスクの優先度制御装置
JP3262689B2 (ja) * 1995-05-19 2002-03-04 富士通株式会社 遠隔操作システム
JP2002244869A (ja) * 2001-02-19 2002-08-30 Hitachi Ltd メモリ管理装置
JP2003015892A (ja) 2001-06-29 2003-01-17 Casio Comput Co Ltd 情報端末装置及びアプリケーション管理プログラム
JP2003067201A (ja) 2001-08-30 2003-03-07 Hitachi Ltd コントローラとオペレーティングシステム
EP1387593A3 (en) * 2002-07-31 2005-06-15 Matsushita Electric Industrial Co., Ltd. Information processing terminal and information processing method
US7493656B2 (en) * 2005-06-02 2009-02-17 Seagate Technology Llc Drive security session manager

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09251390A (ja) * 1996-03-15 1997-09-22 Sharp Corp プロセスのプライオリティ設定方法
JP2004078936A (ja) * 2002-07-31 2004-03-11 Matsushita Electric Ind Co Ltd 情報処理端末及び情報処理方法
JP2004310615A (ja) * 2003-04-09 2004-11-04 Sony Corp プログラム処理システム及びプログラム処理方法、並びにコンピュータ・プログラム
JP2009048358A (ja) * 2007-08-17 2009-03-05 Nec Corp 情報処理装置及びスケジューリング方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112018006950B4 (de) 2018-02-28 2022-07-14 Mitsubishi Electric Corporation Ressourcensteuerungseinrichtung, Ressourcensteuerungsverfahren und Ressourcensteuerungsprogramm

Also Published As

Publication number Publication date
WO2012127596A1 (ja) 2012-09-27
CN103443770B (zh) 2017-12-12
US9424085B2 (en) 2016-08-23
CN103443770A (zh) 2013-12-11
US20140013331A1 (en) 2014-01-09
JPWO2012127596A1 (ja) 2014-07-24

Similar Documents

Publication Publication Date Title
JP5783246B2 (ja) 端末装置、プロセス管理方法、およびプロセス管理プログラム
KR101724176B1 (ko) 기회적 멀티태스킹
US10725972B2 (en) Continuous and concurrent device experience in a multi-device ecosystem
US8762480B2 (en) Client, brokerage server and method for providing cloud storage
JP5597196B2 (ja) プロセス内のスケジューラインスタンス
KR20200060421A (ko) 리소스 관리 방법 및 단말 장치
US20230205603A1 (en) Communications Framework for Multi-Cluster Management Systems
WO2007020735A1 (ja) 競合解決装置
JP2014522023A (ja) メモリタイプ間でデータを移動させるための技術
JP2005338985A (ja) 記憶領域管理方法及びシステム
TW201826102A (zh) 應用運行方法及裝置
WO2021018052A1 (zh) 一种垃圾回收方法及装置
CN112698793A (zh) 一种数据存储方法、装置、机器可读介质及设备
JP6272556B2 (ja) 共有リソース更新装置及び共有リソース更新方法
JP2005115603A (ja) 記憶デバイス制御装置及びその制御方法
KR20150128714A (ko) 최적화된 파일 조작을 위한 파일 그룹화 기법
JP2014063235A (ja) 実行制御方法、およびマルチプロセッサシステム
JP5956064B2 (ja) 計算機システム、データ管理方法、及び計算機
JP6720357B2 (ja) ネットワークアクセス可能なデータボリューム変更
CN102426535A (zh) 动态进程虚拟化
KR20030055482A (ko) 선택적인 캐시관리방법 및 장치
US20110106861A1 (en) Interface Techniques Providing Contiguous Storage For Files
CN111930781B (zh) 对缓存数据库的数据请求的处理方法和装置
CN113032171B (zh) 一种控制方法及装置
CN112578996B (zh) 一种存储系统的元数据的发送方法及存储系统

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150331

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150415

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150623

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150706

R150 Certificate of patent or registration of utility model

Ref document number: 5783246

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150