JP6080634B2 - 情報処理装置及び情報処理方法及びプログラム - Google Patents

Description

本発明は、複数のアプリケーションプログラム（以下、アプリケーションという）を同時に実行・表示する情報処理装置に関する。
以下では、主に、複数のアプリケーションプログラムを同時に実行・表示するカーナビゲーションシステムについて説明を行う。

１画面上で複数のアプリケーションを同時に実行可能なカーナビゲーションシステムにおいて、複数人でそれぞれのアプリケーションの操作を行う場合を想定する。
このとき、経路案内アプリケーションの動作の快適性を損なうことなく、各アプリケーションの動作応答性を向上させることを考える。
まず、アプリケーションの組み合わせごとに、各アプリケーションの実行優先度を前もって設定しておく方法が考えられるが、ユーザ−がアプリケーションの追加・削除を行えるカーナビゲーションシステムでは、実行するアプリケーションの組み合わせと、それぞれのアプリケーションの優先度を前もって設定することは難しい。
また、経路案内アプリケーションの優先度を最優先に設定した場合、道なりを走行する場合や、目的地が設定されておらず、経路案内機能を利用しない場合でもＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）リソースが経路案内アプリケーションに割り当てられてしまい、他のアプリケーションの動作を阻害することになる。
そのため、各アプリケーションのプロセス優先度を動的に変更することで、任意のアプリケーションの応答性を向上する手段を提供することが考えられる。

特許文献１では、アプリケーションの操作ができる状態とアイコンのようにアプリケーションの操作ができない状態への変化に応じて、プロセスの優先度を変更する手法が提案されている。
特許文献２では、複数アプリケーションのウィンドウの面積の大きさに応じて、プロセスの優先度を変更する手法が提案されている。
特許文献３では、アプリケーションのウィンドウの使用頻度に応じて、前面に表示する時間を変更する手法が提案されている。
特許文献４では、アプリケーションの選択回数が所定の回数に達した時にマンマシンインターフェースの優先度を高く切り替える手法が提案されている。
特許文献５では、タッチパネルのスライド操作の速度や移動量に応じて、ユーザインタフェースを変更する手法が提案されている。
特許文献６では、車両の速度と加速度から運転特性を導き、運転者に適したナビゲーションモードを判定する運転特性評価工程が提案されている。

特開平４−２５０５２３号公報 特開平１０−１５４０６０公報 特開平８−１６１１３９公報 特開平９−１３８７０２公報 特許４３６０８７１号 特許４７９０４６９号

また、従来のプロセス優先度変更手法では、画面の大きさ、過去の使用頻度に応じて、該当するアプリケーションに対するプロセス優先度を変更していた。
また、ある特定のアプリケーション、たとえば、経路案内アプリケーションのプロセス優先度が常に最高になるように調整することで、経路案内アプリケーションの快適性を阻害することなく、複数のアプリケーションを動作させていた。
そのため、目的地を設定していない場合や、経路案内が必要な交差点手前や高速道路出入口手前、目的地周辺以外のように、経路案内機能が不要な場合でも経路案内アプリケーションが最優先で処理されてしまうため、経路案内以外のアプリケーションの動作を阻害することになる。

この発明は上記の課題を解決することを主な目的としており、複数のアプリケーションが効率良く動作する環境を提供することを主な目的とする。

本発明に係る情報処理装置は、
タッチパネル式のディスプレイ装置に接続され、前記ディスプレイ装置の表示画面に複数のアプリケーションの領域を表示させる情報処理装置であって、
アプリケーションごとに、領域の前記表示画面上の座標範囲を管理するアプリケーション領域管理部と、
前記ディスプレイ装置へのタッチがあった場合に、タッチ位置の前記表示画面上の座標とタッチがあった時刻とを取得するタッチ座標取得部と、
前記タッチ座標取得部により取得されたタッチ位置の座標と前記アプリケーション領域管理部により管理されている各アプリケーションの領域の座標範囲とに基づき、いずれのアプリケーションの領域がタッチされたかを算出するタッチ情報算出部と、
アプリケーションごとに所定時間単位で領域のタッチ状況を解析し、タッチ状況の解析結果に基づき、アプリケーションごとに所定時間単位でハードウェアリソースの割当て比率を動的に決定する割当て比率決定部とを有することを特徴とする。

本発明によれば、アプリケーションごとに所定時間単位で領域のタッチ状況を解析し、タッチ状況の解析結果に基づき、アプリケーションごとに所定時間単位でハードウェアリソースの割当て比率を動的に決定することで、複数のアプリケーションを効率良く動作させることができる。

実施の形態１〜３のハードウェア構成図。 実施の形態１〜３のソフトウェア構成図。 タッチ情報算出部のソフトウェア構成図。 プロセス優先度算出部のソフトウェア構成図。 実施の形態１の複数アプリケーションの表示例を示す図。 タッチ座標取得部が記録するタッチイベント情報のリストの一例を示す図。 アプリケーション領域管理部が管理するアプリケーション領域情報の一例を示す図。 実施の形態１の全体処理フローを示す図。 実施の形態２の経路案内アプリケーションの画面の一例を示す図。 実施の形態２の経路案内アプリケーションで、経路案内地点の５００ｍ手前地点での画面の一例を示す図。 実施の形態２の経路案内アプリケーションで、経路案内地点手前での画面の一例を示す図。 実施の形態２の経路案内を行う地点の緯度・経度を記録したリストの一例を示す図。 実施の形態２の経路案内地点までの距離と経路案内アプリケーションのプロセス優先度の関係の一例を示す図。 実施の形態２の全体処理フローを示す図。 実施の形態３の複数アプリケーションの実行画面の一例を示す図。 実施の形態３の複数アプリケーションの実行画面で、経路案内地点の５００ｍ手前地点での画面の一例を示す図。 実施の形態３の複数アプリケーションの事項画面で、経路案内地点手前での画面の一例を示す図。 実施の形態３の経路案内地点までの距離と複数アプリケーションのプロセス優先度の関係の一例を示す図。 実施の形態３の全体処理フローを示す図。

実施の形態１〜３では、複数のアプリケーションを同時に表示・実行できるカーナビゲーションシステムにおいて、運転席および助手席から複数人同時に操作する場合、経路案内アプリケーションが最優先で動作するため、同時に動作している経路案内アプリケーション以外のアプリケーションのプロセス優先度が相対的に低くなり、これらのアプリケーションに対する操作レスポンスが悪化するという課題を解決するための構成を説明する。

具体的には、経路案内アプリケーションを含む複数のアプリケーションを同時に実行・表示するカーナビゲーションシステムであって、各アプリケーションに対するタッチパネルからのタッチイベントの任意の一定期間の変化量から各アプリケーションのプロセス優先度を算出する、タッチイベント変化量対応プロセス優先度算出手段と、現在地から交差点手前や高速道出入口手前、目的地周辺などの経路案内が必要な地点までの距離に応じて経路案内アプリケーションのプロセス優先度を算出する、経路案内地点距離対応プロセス優先度算出手段と、上記経路案内距離の比率から経路案内アプリケーションのプロセス優先度を算出した上で、タッチイベント変化量に応じて残りのアプリケーションのプロセス優先度を算出することで、経路案内アプリケーション他すべてのアプリケーションのプロセス優先度を調整するプロセス優先度調整手段を具備することをカーナビゲーションシステムを説明する。

そして、このような構成により、経路案内アプリケーションの快適性を損なうことなく、複数同時表示するアプリケーションの操作レスポンスを向上することができる。

実施の形態１．
図１は、実施の形態１〜３のカーナビゲーションシステムのハードウェア構成を示す。
図１に示すカーナビゲーションシステムは、情報処理装置の例に相当する。

この図で、ＨＷ＿１はＣＰＵで、各プロセスの優先度に従って、処理割り当てを配分する機能を有する。
ＨＷ＿２はＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）で、アプリケーションのプログラムコードやアプリケーションのデータ（変数値やパラメータ値）を一時的に格納し、ＣＰＵでのアプリケーションの実行に用いられる記憶手段である。
ＨＷ＿３はストレージで、複数のアプリケーションのプログラムコードや地図データなどを保存するための、フラッシュＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やハードディスクドライブなどを指す。

ＨＷ＿４はディスプレイで、カーナビゲーションシステムで動作するアプリケーションを表示するための手段である。
ＨＷ＿５はタッチパネルで、上記ディスプレイに対して指で触れた画面上の座標を取得するための手段である。
なお、本タッチパネルは複数の指、および複数人の指の座標を同時に取得することが可能である。
また、ディスプレイＨＷ＿４とタッチパネルＨＷ＿５は、一体となって、タッチパネル式のディスプレイ装置として構成されている。

ＨＷ＿６はタイマーで、アプリケーションの実行タイミングや、プロセス配分タイミングの他、タッチパネルで触った時刻を計測するための手段である。
ＨＷ＿７はＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）で、自車位置の緯度・経度の座標を取得するための手段である。
ＨＷ＿８は無線モジュールで、本カーナビゲーションシステムとインターネット接続を行うための手段である。
本モジュールを利用して、インターネット経由でアプリケーションを入手することが可能である。

図２は実施の形態１〜３のカーナビゲーションシステムのソフトウェア構成を示す。

この図で、ＳＷ＿ＡＰＰはアプリケーションレイヤで、ＳＷ＿ＡＰＰ＿１、ＳＷ＿ＡＰＰ＿２、ＳＷ＿ＡＰＰ＿３など複数のアプリケーションから構成される。

ＳＷ＿ＡＰＰ＿１は経路案内アプリケーションで、ナビゲーションシステムの中核をなすアプリケーションである。
本アプリケーションは自車位置から目的地へ運転者を誘導するための経路案内や交差点の右左折などの音声案内などを行う。
また、右左折交差点や高速道出入口など、詳細な経路案内を行う地点の集合である、経路案内地点リストを保有する。

ＳＷ＿ＡＰＰ＿２、ＳＷ＿ＡＰＰ＿３は、経路案内アプリケーション以外のアプリケーションである。
これらのアプリケーションは工場出荷時にインストール済みでも、インターネット経由で取得したアプリケーションでも構わない。

ＳＷ＿ＭＷはミドルウェアで、アプリケーションレイヤに属する複数のアプリケーションから利用できる共通処理（ライブラリ）から構成される。

ＳＷ＿ＭＷ＿１はタッチ座標取得部で、図１のタッチパネルから取得した、指が触れた座標の他、タッチした時刻を取得し、タッチイベントとして保存・管理するための手段である。

ＳＷ＿ＭＷ＿２はアプリケーション領域管理部で、ディスプレイＨＷ＿４で画面表示が行われている各アプリケーションの表示領域情報を管理するための手段である。
つまり、アプリケーション領域管理部ＳＷ＿ＭＷ＿２は、アプリケーションごとに、領域の表示画面上の座標範囲を管理する。

ＳＷ＿ＭＷ＿２はタッチ情報算出部で、タッチ座標取得部ＳＷ＿ＭＷ＿１で得られたタッチイベント情報とアプリケーション領域管理部ＳＷ＿ＭＷ＿２で得られたアプリケーション領域情報から任意の極短期間に各アプリケーションごとにタッチされた回数や、移動距離を算出するための手段である。
つまり、タッチ情報算出部ＳＷ＿ＭＷ＿３は、タッチ座標取得部ＳＷ＿ＭＷ＿１で取得されたタッチ位置の座標とアプリケーション領域管理部ＳＷ＿ＭＷ＿２により管理されている各アプリケーションの領域の座標範囲とに基づき、いずれのアプリケーションの領域がタッチされたかを算出する。
そして、アプリケーションごとにタッチされた回数や、移動距離を算出する。

ＳＷ＿ＭＷ＿４は自車位置取得部で、ＧＰＳ ＨＷ＿７から取得した自車位置の緯度・経度を取得するための手段である。

ＳＷ＿ＭＷ＿５は経路案内地点リスト取得部で、経路案内アプリケーションＳＷ＿ＡＰＰ＿１が保有する経路案内地点リストを取得するための手段である。
経路案内地点リストには、経路案内アプリケーションＳＷ＿ＡＰＰ＿１において詳細な案内を行う経路案内地点（詳細案内位置）の座標情報が示されており、経路案内地点リスト取得部ＳＷ＿ＭＷ＿５は経路案内地点リストを取得し、保持する。
経路案内地点リスト取得部ＳＷ＿ＭＷ＿５の動作は主に実施の形態２で説明する。
なお、経路案内地点リスト取得部ＳＷ＿ＭＷ＿５は、詳細案内位置記憶部の例に相当する。

ＳＷ＿ＭＷ＿６は経路案内地点距離算出部で、自車位置取得部ＳＷ＿ＭＷ＿４から取得した自車位置と経路案内地点リスト取得部ＳＷ＿ＭＷ＿５で取得した最寄りの経路案内地点の位置の間の距離を求めるための算出手段である。
経路案内地点距離算出部ＳＷ＿ＭＷ＿６の動作は主に実施の形態２で説明する。
なお、経路案内地点距離算出部ＳＷ＿ＭＷ＿６は、距離判定部の例に相当する。

ＳＷ＿ＭＷ＿７はプロセス優先度算出部で、タッチ情報算出部ＳＷ＿ＭＷ＿３で算出した各アプリケーションのタッチ頻度などの情報や、経路案内地点距離算出部ＳＷ＿ＭＷ＿６で得られた経路案内地点までの距離から現在表示されているアプリケーションのプロセス優先度を求めるための手段である。
なお、本プロセス優先度の算出はタッチ情報算出部ＳＷ＿ＭＷ＿３単体、あるいは経路案内地点距離算出部ＳＷ＿ＭＷ＿６単体の情報を利用して、プロセスの優先度を算出しても構わない。
プロセス優先度は、アプリケーションの実行のために用いられるハードウェアリソース（具体的にはＣＰＵリソース）の割当て比率である。
このように、プロセス優先度算出部ＳＷ＿ＭＷ＿７は、アプリケーションごとに所定時間単位で領域のタッチ状況を解析し、タッチ状況の解析結果に基づき、アプリケーションごとに所定時間単位でハードウェアリソースの割当て比率を動的に決定しており、割当て比率決定部の例に相当する。

ＳＷ＿ＯＳはＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）で、ＣＰＵやタッチパネルなどのＨ／Ｗリソースの管理を行う。
なお、プロセス優先度算出部ＳＷ＿ＭＷ＿７で算出された各アプリケーションのプロセス優先度の値に従って、各アプリケーションに対するＣＰＵリソースの配分を行う。

図３は、図２に記載のタッチ情報算出部ＳＷ＿ＭＷ＿３のＳ／Ｗ構成図を表す図である。

この図で、ＳＷ＿ＭＷ＿３＿１はタッチ頻度算出部で、タッチ座標取得部ＳＷ＿ＭＷ＿１のタッチイベント情報とアプリケーション領域管理部ＳＷ＿ＭＷ＿２のアプリケーション領域情報から任意の極短期間に各アプリケーションごとにタッチされた回数をカウントするための手段である。

ＳＷ＿ＭＷ＿３＿３はタッチ移動速度算出部で、タッチ座標取得部ＳＷ＿ＭＷ＿１のタッチイベント情報とアプリケーション領域管理部ＳＷ＿ＭＷ＿２のアプリケーション領域情報から任意の極短期間に各アプリケーションの、連続するタッチ座標の距離から移動速度を算出するための手段である。

図４は図２に記載のプロセス優先度算出部ＳＷ＿ＭＷ＿７のＳ／Ｗ構成図を表す図である。

この図で、ＳＷ＿ＭＷ＿７＿１はタッチイベント変化量対応プロセス優先度算出部で、タッチ情報算出部ＳＷ＿ＭＷ＿３で算出した各アプリケーションのタッチイベント変化量の比率に応じて、各アプリケーションのプロセス優先度（プロセスの割当量）を算出するための手段である。

ＳＷ＿ＭＷ＿７＿２は経路案内地点距離対応プロセス優先度算出部で、経路案内地点距離算出部ＳＷ＿ＭＷ＿６で求めた経路案内地点までの距離に応じて、経路案内アプリケーションＳＷ＿ＡＰＰ＿１のプロセス優先度（プロセス割当量）を算出するための手段である。
経路案内地点距離対応プロセス優先度算出部ＳＷ＿ＭＷ＿７＿２の動作は主に実施の形態２で説明する。

ＳＷ＿ＭＷ＿７＿３はプロセス優先度調整部で、ＳＷ＿ＭＷ＿７＿２で求めた経路案内アプリケーションＳＷ＿ＡＰＰ＿１のプロセス優先度から余剰なプロセス割当量を求め、そのプロセス割当量に対して、ＳＷ＿ＭＷ＿７＿１によってその他のアプリケーションのプロセス優先度を算出するための手段である。
プロセス優先度調整部ＳＷ＿ＭＷ＿７＿３の動作は主に実施の形態３で説明する。

図２〜図４に示した各ソフトウェアは、通常はハードディスク装置等のストレージＨＷ＿３に記憶されており、ＲＡＭ ＨＷ＿２にロードされた状態で、ＣＰＵ ＨＷ＿１に読み込まれ、実行される。

図５は、実施の形態１の画面表示の一例である。
図５は、経路案内アプリケーションＳＷ＿ＡＰＰ＿１の領域を配置し、左側にアプリケーションＳＷ＿ＡＰＰ＿１およびＳＷ＿ＡＰＰ＿２の領域を配置・表示した例である。
図５では、アプリケーションＳＷ＿ＡＰＰ＿１およびＳＷ＿ＡＰＰ＿２の領域は、操作可能な状態で表示されているが、アイコンのように、アプリケーションを起動するための領域が表示されていてもよい。

図６は、タッチイベント情報の例である。
この図で、タッチ時刻はタッチイベントを受信した時刻を記録した例である。
また、タッチ座標はその時刻に検知したタッチイベントの座標で、左上を（０，０）として記録している。
このタッチイベント情報は、タッチ座標取得部ＳＷ＿ＭＷ＿１により生成される。

図７は、アプリケーション領域情報の例である。
この図で、アプリケーションは経路案内アプリケーションＳＷ＿ＡＰＰ＿１の他、アプリケーション２ ＳＷ＿ＡＰＰ＿２とアプリケーション３ ＳＷ＿ＡＰＰ＿３の計３つのアプリケーションが実行され、各アプリケーションの領域が図５のように表示されており、それぞれのアプリケーションの領域が表示されている左上座標と右下座標をテーブルとして保存・管理している。
なお、アプリケーションの領域の大きさはユーザ操作により動的に変更が可能で、変更に伴い、このアプリケーション領域情報も変更される。
このアプリケーション領域情報は、アプリケーション領域管理部ＳＷ＿ＭＷ＿２により生成・更新される。

実施の形態１における、全体の処理フローを図８を用いて説明する。

なお、カーナビゲーションシステムは複数ユーザからのタッチ動作をタッチパネルＨＷ＿５から受け取り、その情報をタッチ座標取得部ＳＷ＿ＭＷ＿１がタッチイベント情報として保存しておくこととする。
また、ディスプレイＨＷ＿４上で実行・表示されているアプリケーションのアプリケーション領域情報はアプリケーション領域管理部ＳＷ＿ＭＷ＿２が随時更新しているものとする。

まず、タッチ情報算出部ＳＷ＿ＭＷ＿３は、タッチ座標取得部ＳＷ＿ＭＷ＿１からタッチイベント情報を、アプリケーション領域管理部ＳＷ＿ＭＷ＿２からアプリケーション領域情報を取得する（Ｓ１）。

次に、タッチ情報算出部ＳＷ＿ＭＷ＿３は、タッチイベント情報に記載された各タッチイベントがどのアプリケーションの領域に属するのかを算出する（Ｓ２）。
そして、タッチ情報算出部ＳＷ＿ＭＷ＿３は、それぞれのアプリケーションごとのタッチイベントの変化量を算出する。
このとき、変化量とは、任意の極短期間における各アプリケーションのタッチイベントの回数（頻度）や、最大移動速度などである（Ｓ３）。

そして、タッチイベント変化量対応プロセス優先度算出部ＳＷ＿ＭＷ＿７＿１は、これらの各アプリケーションの変化量に応じて各アプリケーションに割り振るプロセス優先度を算出する。
例えば、１００ｍｓｅｃの間に各アプリケーションのイベントタッチ回数が５回、３回、２回の場合、それぞれのアプリケーションのプロセス優先度（割当量）は５０％、３０％、２０％となる（Ｓ４）。
そして、算出したプロセス優先度をＯＳ ＳＷ＿ＯＳに渡す。
ＯＳ ＳＷ＿ＯＳは、プロセス優先度に応じて各アプリケーションのプロセスに対してＣＰＵリソースの割り当てを行う（Ｓ５）。
そして、再び、Ｓ１に遷移し、プロセス優先度変更を繰り返す。

［実施例１］
実施の形態１における実施例として、各アプリケーションに対するタッチイベントの頻度の比較によって各アプリケーションのプロセス優先度を変更する手法が考えられる。

実施例１の動作の説明のため、図５のように、ＳＷ＿ＡＰＰ＿１、ＳＷ＿ＡＰＰ＿２、およびＳＷ＿ＡＰＰ＿３の３つのアプリケーションが実行されており、それぞれのアプリケーションは図７に示す領域を占めていることとする。

例えば、ある任意の１秒間（２０１２／１２／２７ １０：００：０３−０４）の間において、タッチ座標取得部ＳＷ＿ＭＷ＿１が図６に示すようなタッチイベントを受信したと仮定する。
このとき、タッチ頻度算出部ＳＷ＿ＭＷ＿３＿１はアプリケーション領域管理部ＳＷ＿ＭＷ＿２が保持するアプリケーション領域情報から各アプリケーションでどの程度タッチイベントを受け付けたかを算出する。
図６の例の場合、経路案内アプリケーションＳＷ＿ＡＰＰ＿１は３回、アプリケーションＳＷ＿ＡＰＰ＿２は５回、アプリケーションＳＷ＿ＡＰＰ＿３は２回タッチイベントを受け付けたことが分かる。
プロセス優先度算出部ＳＷ＿ＭＷ＿７はこれらのタッチイベントの頻度からプロセス優先度を算出する。
この場合、タッチイベント数はＳＷ＿ＡＰＰ＿１：ＳＷ＿ＡＰＰ＿２：ＳＷ＿ＡＰＰ＿３＝３：５：２のため、アプリケーションのプロセス優先度をそれぞれ、３０％、５０％、２０％に設定し、ＳＷ＿ＯＳに通知する。
ＯＳ ＳＷ＿ＯＳは指定されたプロセス優先度に従い、ＣＰＵのリソースを割り振る。

これによって、タッチ頻度が高いアプリケーションのプロセスの優先度を相対的に高くすることができ、ユーザ操作が最も行われているアプリケーションに対してＣＰＵリソースを割り振り、操作のレスポンスを向上させることが可能である。

［実施例２］
実施の形態１における別の実施例として、各アプリケーションに対するタッチイベントの移動速度の比較によって各アプリケーションのプロセス優先度を変更する手法が考えられる。

実施例２の動作の説明のため、図５のように、ＳＷ＿ＡＰＰ＿１、ＳＷ＿ＡＰＰ＿２、およびＳＷ＿ＡＰＰ＿３の３つのアプリケーションが実行されており、それぞれのアプリケーションは図７に示す領域を占めていることとする。

例えば、ある任意の１秒間（２０１２／１２／２７ １０：００：０３−０４）の間において、タッチ座標取得部ＳＷ＿ＭＷ＿１が図６に示すようなタッチイベントを受信したと仮定する。
このとき、タッチ移動速度算出部ＳＷ＿ＭＷ＿３＿３はアプリケーション領域管理部ＳＷ＿ＭＷ＿２が保持するアプリケーション領域情報から各アプリケーションで連続するタッチの移動量と連続時間から移動速度を算出する。
この例の場合、経路案内アプリケーションＳＷ＿ＡＰＰ＿１の最大移動速度は２０１２／１２／２７／１０：００：０３：５００〜６００間の（５００，０）−（５００，７００）間で７００／ｍｓｅｃ、アプリケーションＳＷ＿ＡＰＰ＿２の最大移動速度は２０１２／１２／２７／１０：００：０３：１００〜２００間の（２０，１０）−（２０，５０）＝４０／ｍｓｅｃ、アプリケーションＳＷ＿ＡＰＰ＿３の最大移動速度は２０１２／１２／２７／１０：００：０３：８００〜９００間の（６０，６００）−（６０，５００）＝１００／ｍｓｅｃとなることが分かる。
プロセス優先度算出部ＳＷ＿ＭＷ＿７はこれらのタッチイベントの最大移動速度からプロセス優先度を算出する。
この場合、最大移動速度はＳＷ＿ＡＰＰ＿１：ＳＷ＿ＡＰＰ＿２：ＳＷ＿ＡＰＰ＿３＝７０：４：１０のため、アプリケーションのプロセス優先度をそれぞれ、８３％、５％、１２％に設定し、ＳＷ＿ＯＳに通知する。
ＯＳ ＳＷ＿ＯＳは指定されたプロセス優先度に従い、ＣＰＵのリソースを割り振る。

これによって、タッチの移動速度が最も速いアプリケーションのプロセスの優先度を相対的に高くすることができる。
例えば、タッチパネルをなぞる速度（スクロール操作の速度）が最も速いアプリケーションに対してＣＰＵリソースを割り振り操作のレスポンスを向上させることが可能である。

実施の形態２．
図９は、実施の形態２の経路案内アプリケーションの経路案内画面である。
この図で、ＮａｖｉＤｉｓｐｌａｙ＿１はカーナビゲーションシステムのタッチパネル付きディスプレイである。
ＮａｖｉＡｐｐ＿１は経路案内アプリケーションの画面表示である。
ＣａｒＰｏｓ＿１は走行中の自車位置である。
Ｐａｔｈ＿１は経路で、経路案内アプリケーションが導出する自車位置ＣａｒＰｏｓ＿１から目的地への経路情報である。本図では太いラインで示す。
ＧｕｉｄｅＰｏｉｎｔ＿１は経路案内地点を指す。
ここで、経路案内地点とは、経路案内アプリケーションがユーザに対して経路を間違いなく進めるようにするために、情報量を増やしてユーザに通知する地点で、例えば、右左折の指示や、道路の走行レーン情報、高速道路の入口あるいは出口の情報を、音声、あるいは、２画面表示にてユーザに通知される。
このとき、建物の３Ｄ表示処理や音声出力など、複数の処理を同時に行う必要があるため、ＣＰＵリソースを通常よりも必要とする。
このように経路案内地点は、経路案内アプリケーションにおいて詳細な案内が行われる位置であり、詳細案内位置に相当する。
経路案内地点の座標情報は、経路案内地点リスト取得部ＳＷ＿ＭＷ＿５により保持されている。

図１０は、実施の形態１の経路案内アプリケーションの経路案内画面で、特に、図９の自車位置ＣａｒＰｏｓ＿２が経路案内地点ＧｕｉｄｅＰｏｉｎｔ＿２まで５００ｍに差し掛かった画面である。
このとき、経路表示の画面は大きく変わらないが、経路に関する音声案内出力ＧｕｉｄｅＳｏｕｎｄ＿２が出力される。
例えば、「５００ｍ先、左方向です」といった音声ガイダンスなどがそれに当たる。
なお、本例では音声案内を５００ｍ前に出力することとしているが、任意の距離で構わない。
経路表示に加え、音声案内が加わることで、図９の時よりもＣＰＵ負荷が若干増加する。

図１１は、自車が経路案内地点に到達した時点での、実施の形態１の経路案内アプリケーションの経路案内画面である。
この図で、ＮａｖｉＡｐｐ＿３は自車が経路案内地点に到達した時点での経路案内アプリケーションの画面表示で、左半分画面には通常の経路案内画面を横に１／２にした表示（ＧｕｉｄｅＭａｐ＿３）、右半分画面を経路案内地点の詳細の地図表示（ＧｕｉｄｅＤｅｔａｉｌ＿３）を示す。
また、同時に、進行方向に関する音声案内を行う（ＧｕｉｄｅＳｏｕｎｄ＿３）。
なお、ＣａｒＰｏｓ＿３−１、ＣａｒＰｏｓ＿３−２は共に走行中の自車位置である。
ＧｕｉｄｅＭａｐ＿３の自車位置とＧｕｉｄｅＤｅｔａｉｌ＿３の自車位置は同期をしており、地理的に同じ地点を指す。
つまり、経路案内地点ではＧｕｉｄｅＭａｐ＿３とＧｕｉｄｅＤｅｔａｉｌ＿３の２画面表示で、かつ、音声案内ＧｕｉｄｅＳｏｕｎｄ＿３を同時に実行しなければならないため、ＣＰＵ使用率が自ずと高くなってしまう。

図１２は経路案内地点リストの例で、右左折行う交差点や高速道出入口など、音声案内や詳細画面表示を利用して経路案内を行う、経路案内地点の緯度・経度のリストである。

図１３は、実施の形態２の経路案内アプリケーションのプロセス優先度と経路案内を行う交差点までの距離の関係を示すグラフ図である。
縦軸は経路案内アプリケーションのプロセス優先度であり、上方向に行くほど優先度が高くなる。
横軸は現在地から経路案内地点までの距離を指す。
本例では、経路案内地点を右左折を行う交差点として説明する。

まず、この図で、自車が交差点５００ｍ前に到達するまでは緩やかに優先度を上げ、さらに交差点３００ｍ前に向けて優先度の増加率を上げ、経路案内アプリケーションへの優先度割当て最大値に到達させる。
そして、自車が交差点を過ぎると、再び割り当て優先度最小値になるよう、優先度を減少させる。

本例では、交差点を例にしているが、高速道路の出入口手前や、目的地周辺に適用しても構わない。
また、距離に対する優先度の変化率は変更することが可能である。

実施の形態２における、経路案内地点距離対応プロセス優先度算出部ＳＷ＿ＭＷ＿７＿２等の処理フローを図１４を用いて説明する。
なお、カーナビゲーションシステムは自車位置取得部ＳＷ＿ＭＷ＿４においてＧＰＳ ＨＷ＿７から自車の緯度経度情報を受け取り保存しておくこととする。

まず、経路案内アプリケーションＳＷ＿ＡＰＰ＿１はユーザにより目的地が設定されると、現在地から目的地までの経路を算出する。
このとき、経路中の交差点や、高速道路の出入口など、音声案内や案内詳細図の表示が必要となる地点のリストを経路案内地点リストとして生成する（Ｔ１）。

次に、自車位置取得部ＳＷ＿ＭＷ＿４が自車位置を取得する。
また、経路案内地点リスト取得部ＳＷ＿ＭＷ＿５は経路案内アプリケーションＳＷ＿ＡＰＰ＿１から経路案内地点リストを取得する（Ｔ２）。

そして、経路案内地点距離算出部ＳＷ＿ＭＷ＿６は自車位置から最寄りの経路案内地点までの距離を算出する（Ｔ３）。

次に、経路案内地点距離対応プロセス優先度算出部ＳＷ＿ＭＷ＿７＿２は、Ｔ３で求めた距離と図１３で示す、経路案内地点距離とプロセス優先度割り当ての関係式から、その距離に応じた、経路案内アプリケーションのプロセス優先度を算出する（Ｔ４）。
そして、算出したプロセス優先度をＯＳ ＳＷ＿ＯＳに渡す。
ＯＳ ＳＷ＿ＯＳはそのプロセス優先度に応じて各プロセスに対してＣＰＵリソースの割り当てを行う（Ｔ５）。
そして、再び、Ｔ１に遷移し、プロセス優先度変更を繰り返す。

［実施例３］
実施の形態２における実施例として、道なり走行時でのＣＰＵ負荷低減方法がある。

実施例３の動作説明のため、図１３のように、経路案内を行う交差点までの間における経路案内アプリケーションに対するプロセス優先度割り当てを行うものとする。
例えば、自車が交差点５００ｍ前に到達するまでは緩やかにプロセス優先度を上げるため、ＣＰＵ負荷を低減しながら動作する。
そして、そして、交差点３００ｍ手前まで音声案内を行うため、プロセス優先度を徐々に割り当て最大値まで上げる。
そして、交差点３００ｍに到達すると、図１１のように経路案内詳細図と共に、交差点の左折案内の音声案内を行うため、プロセス優先度を割り当て最大値にする。そして、交差点を左折すると同時にそのプロセス優先度を割り当て最小値まで低下させる。

これによって、経路案内をほとんど必要としない走行区画において、ＣＰＵ負荷を低減し、電力消費を抑えることが可能である。
例えば、道なりに走行する場合や、高速道路走行中に出口やパーキングエリアまでの距離が長い場合にＣＰＵ負荷を低減することが可能である。

このように、本実施の形態では、自車が経路案内地点に達する前は、自車の所在位置と経路案内地点との間の距離が所定の閾値（例えば３００ｍ）よりも長い間は、自車の所在位置と経路案内地点との間の距離が短くなるのに従って経路案内アプリケーションへのＣＰＵリソースの割当て比率を高くしていく。
そして、自車の所在位置と経路案内地点との間の距離が閾値以下になった時点で、経路案内アプリケーションへのＣＰＵリソースの割当て比率を経路案内アプリケーションに許容されている最高割当て比率にする。
その後、自車が経路案内地点に到達した後は、自車の所在位置と経路案内地点との間の距離が長くなるのに従って経路案内アプリケーションへのＣＰＵリソースの割当て比率を低くしていく。
なお、この割り当て方法は一例であり、自車が経路案内地点に到達した後も、一定の距離の間（例えば３００ｍ）は、最高割当て比率を維持していてもよい。

実施の形態３．
図１５は、図９で説明した経路案内アプリケーションＮａｖｉＡｐｐ＿４と、二つのアプリケーションＡｐｐ＿４＿１とＡｐｐ＿４＿２を同時に実行させた例を示す。
Ａｐｐ＿４＿１とＡｐｐ＿４＿２は経路案内アプリケーション以外のアプリケーションで、例えば、ブラウザや、メーラ、動画再生、オーディオプレーヤーアプリケーションなど、ナビゲーションシステムで動作するアプリケーションである。
なお、これらのアプリケーションは画面上に表示されており、いずれのアプリケーションもタッチパネルによる操作が可能である。
また、例えば、Ａｐｐ＿４＿２を動画再生やオーディオプレーヤーアプリケーションなどと仮定すると、Ｍｕｓｉｃ＿４＿２のように表示の他に音声出力することが可能である。

図１６は、図１５の画面からさらに自車が経路案内地点５００ｍ手前まで進んだ状態である。
このとき、経路案内アプリケーションＮａｖｉＡｐｐ＿５からは交差点右左折指示などの音声案内ＧｕｉｄｅＳｏｕｎｄ＿５が流れる。
さらに、図１５と同様に二つのアプリケーションＡｐｐ＿５＿１とＡｐｐ＿５＿２を同時に実行している。
つまり、図１５から音声案内ＧｕｉｄｅＳｏｕｎｄ＿５が加わることで、ＣＰＵ負荷が若干増加する。

図１７は、図１１で説明したものと同様の経路案内アプリケーションＮａｖｉＡｐｐ＿６と、二つのアプリケーションＡｐｐ＿６＿１とＡｐｐ＿６＿２を同時に実行させた例を示す。
このとき経路案内アプリケーションは二つの案内画面ＧｕｉｄｅＭａｐ＿６とＧｕｉｄｅＤｅｔａｉｌ＿６を出力し、音声案内処理ＧｕｉｄｅＳｏｕｎｄ＿６を同時に行う。
そのため、ＣＰＵ負荷としては最大となる。

図１８は、実施の形態２で説明した図１３に、長鎖線で経路案内アプリケーション以外のプロセスに割り当てられるプロセス優先度（割当量）を重畳した図である。
経路案内アプリケーションに対するプロセス優先度の変化は図１３で説明したものと同じであるが、そのグラフと反比例してその他のアプリケーションのプロセス優先度を変化させている。
つまり、アプリケーションに許容されているプロセス優先度の総量から経路案内アプリケーションへのプロセス優先度を差し引いた残りの優先度を、経路案内アプリケーション以外のアプリケーションへのプロセス優先度としている。

実施の形態３における、プロセス優先度調整部ＳＷ＿ＭＷ＿７＿３等の処理フローを図１９を用いて説明する。

まず、実施の形態２の方法で、経路案内アプリケーションのプロセス優先度を求める（Ｕ１）。

次に、プロセス優先度調整部ＳＷ＿ＭＷ＿７＿３は図１８のその他アプリケーションプロセス優先度グラフのように、経路案内プロセス優先度グラフに反比例した形で余剰優先度を算出する（Ｕ２）。

そして、タッチイベント変化量対応プロセス優先度算出部ＳＷ＿ＭＷ＿７＿１が、Ｕ２で求めた余剰プロセス優先度に対して実施の形態１の手法にて、他のアプリケーションのプロセス優先度を算出する（Ｕ３）。

そして、算出したプロセス優先度をＯＳ ＳＷ＿ＯＳに渡す。
ＯＳ ＳＷ＿ＯＳはそのプロセス優先度に応じて各プロセスに対してＣＰＵリソースの割り当てを行う（Ｕ４）。
そして、再び、Ｕ１に遷移し、プロセス優先度変更を繰り返す。

［実施例４］
実施の形態３における実施例として、道なり走行時での複数アプリケーションの負荷平準化方法がある。

実施例４の動作説明のため、図１８のように、経路案内を行う交差点までの経路案内アプリケーションの優先度とその他のアプリケーションの優先度を設定することとする。
例えば、自車が交差点５００ｍ前に到達するまでは、その他のアプリケーションのプロセス優先度を割り当て最大値から緩やかに減少、逆に経路案内アプリケーションのプロセス優先度を徐々に高くしていく。
そして、交差点３００ｍ前にて、経路案内アプリケーションのプロセス優先度を割り当て最大値にし、その他のアプリケーションをその最小値に設定する。
そして、交差点を過ぎると、再び、そのプロセス優先度を逆転させる。

これによって、経路案内をほとんど必要としない走行区画において、その他のアプリケーションのプロセス優先度を上げることができる。
例えば、この走行区間において、動画再生アプリケーションのプロセス優先度を経路案内アプリケーションのプロセス優先度よりも上げることで、経路案内の動作に影響を与えることなく、動画の再生をスムーズに行うことが可能である。

以上の実施の形態１〜３では、任意の一定期間における、複数のアプリケーションに対するタッチイベントの変化量と、目的地までに通過する交差点や高速道路出入り口などの経路案内地点までの距離に応じて、経路案内アプリケーションを含むすべてのアプリケーションのプロセス優先度を動的に変更することで、経路案内アプリケーションの快適性を阻害することなく、複数のアプリケーションが効率良く動作する環境を提供する構成を説明した。

そして、実施の形態１〜３によれば、経路案内アプリケーションと同時に表示されるアプリケーションに対して、各アプリケーションに対するタッチパネルからのタッチイベントの任意の一定期間の変化量から各アプリケーションのプロセス優先度を算出する手段と、車両が今後目的地までに通過する交差点や高速道路出入り口などの経路案内地点までの距離に応じて経路案内アプリケーションのプロセス優先度を算出する手段により、各アプリケーションのプロセス優先度を動的に変更して、経路案内アプリケーションの快適性を損なうことなく、複数同時表示するアプリケーションの操作レスポンスを向上することができることを説明した。

以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。
あるいは、これらの実施の形態のうち、１つを部分的に実施しても構わない。
あるいは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。
なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。

ＳＷ＿ＡＰＰ＿１ 経路案内アプリケーション、ＳＷ＿ＡＰＰ＿２ アプリケーション、ＳＷ＿ＡＰＰ＿３ アプリケーション、ＳＷ＿ＭＷ ミドルウェア、ＳＷ＿ＭＷ＿１ タッチ座標取得部、ＳＷ＿ＭＷ＿２ アプリケーション領域管理部、ＳＷ＿ＭＷ＿２ タッチ情報算出部、ＳＷ＿ＭＷ＿４ 自車位置取得部、ＳＷ＿ＭＷ＿５ 経路案内地点リスト取得部、ＳＷ＿ＭＷ＿６ 経路案内地点距離算出部、ＳＷ＿ＭＷ＿７ プロセス優先度算出部、ＳＷ＿ＯＳ ＯＳ、ＳＷ＿ＭＷ＿３＿１ タッチ頻度算出部、ＳＷ＿ＭＷ＿３＿３ タッチ移動速度算出部、ＳＷ＿ＭＷ＿７＿１ タッチイベント変化量対応プロセス優先度算出部、ＳＷ＿ＭＷ＿７＿２ 経路案内地点距離対応プロセス優先度算出部、ＳＷ＿ＭＷ＿７＿３ プロセス優先度調整部。

Claims (5)

1. タッチパネル式のディスプレイ装置に接続され、前記ディスプレイ装置の表示画面に複数のアプリケーションの領域を表示させる情報処理装置であって、
   アプリケーションごとに、領域の前記表示画面上の座標範囲を管理するアプリケーション領域管理部と、
   前記ディスプレイ装置へのタッチがあった場合に、タッチ位置の前記表示画面上の座標とタッチがあった時刻とを取得するタッチ座標取得部と、
   前記タッチ座標取得部により取得されたタッチ位置の座標と前記アプリケーション領域管理部により管理されている各アプリケーションの領域の座標範囲とに基づき、いずれのアプリケーションの領域がタッチされたかを算出するタッチ情報算出部と、
   アプリケーションごとに所定時間単位で領域のタッチの移動速度を解析し、移動速度が速いアプリケーションほどハードウェアリソースの割当て比率を大きくして、アプリケーションごとに所定時間単位でハードウェアリソースの割当て比率を動的に決定する割当て比率決定部とを有することを特徴とする情報処理装置。
2. 前記割当て比率決定部は、
   アプリケーションごとに所定時間単位で領域へのタッチ回数を解析し、タッチ回数が多いアプリケーションほどハードウェアリソースの割当て比率を大きくすることを特徴とする請求項１に記載の情報処理装置。
3. 前記複数のアプリケーションのうちの少なくとも１つのアプリケーションは、移動体の経路案内を行う経路案内アプリケーションであることを特徴とする請求項１に記載の情報処理装置。
4. タッチパネル式のディスプレイ装置に接続され、前記ディスプレイ装置の表示画面に複数のアプリケーションの領域を表示させるコンピュータが行う情報処理方法であって、
   前記コンピュータが、アプリケーションごとに、領域の前記表示画面上の座標範囲を管理するアプリケーション領域管理ステップと、
   前記ディスプレイ装置へのタッチがあった場合に、前記コンピュータが、タッチ位置の前記表示画面上の座標とタッチがあった時刻とを取得するタッチ座標取得ステップと、
   前記タッチ座標取得ステップにより取得されたタッチ位置の座標と前記アプリケーション領域管理ステップにより管理されている各アプリケーションの領域の座標範囲とに基づき、前記コンピュータが、いずれのアプリケーションの領域がタッチされたかを算出するタッチ情報算出ステップと、
   前記コンピュータが、アプリケーションごとに所定時間単位で領域のタッチの移動速度を解析し、移動速度が速いアプリケーションほどハードウェアリソースの割当て比率を大きくして、アプリケーションごとに所定時間単位でハードウェアリソースの割当て比率を動的に決定する割当て比率決定ステップとを有することを特徴とする情報処理方法。
5. コンピュータを、請求項１に記載された情報処理装置として機能させることを特徴とするプログラム。