JP2004078936A - 情報処理端末及び情報処理方法 - Google Patents

Abstract

【課題】　アプリケーションが必要以上にリソース競合解決を意識しないでも、システム全体として整合の取れた動作をおこなえるようにすることである。また、アプリケーションやリソースを制御するドライバの再利用性を高めることである。
【解決手段】　リソースアクセス部１１は、競合判定部１３の結果を基に、アプリケーションがリソース部１６にアクセスできるかどうかを判断し、アクセスできる場合はあらかじめリソース部１６が登録してある関数を呼ぶことで、アプリケーションはリソース競合解決を意識しないで作成可能になり、また、リソース部１６の再利用がしやすくなり、かつシステム全体として整合の取れた動作を行うことができる。
【選択図】　図１

Description

　本発明は、情報処理端末及び情報処理方法に関し、より特定的には、複数のソフトウェアによる同一リソースへのアクセスを制御する情報処理端末及び情報処理方法に関する。

　従来、情報処理端末（例えば携帯電話）において、特定のアプリケーション（例えば電話機能）に特定のリソース（例えばスピーカ）を、他のアプリケーション（例えばウェブブラウザ）より優先的に割り当てることがある。例えば携帯電話では、ウェブページの閲覧よりも通話の方が利用者にとって重要である。よって、ユーザがウェブブラウザを用いてコンテンツを閲覧中に電話の着信があった場合には、ウェブページの表示処理やＢＧＭ等の音声出力処理を中断して、電話の着信画面を表示するとともに着信音を出力するのが一般的である（図１４参照）。

　従来は、上記のような処理を実現するために、各リソースに対してどのアプリケーションをどの優先度で割り当てるのかを全アプリケーションについて管理するソフトウェアコンポーネント（競合解決部）が設けられていた（図１５参照）。この競合解決部は、あるアプリケーション（アプリケーションＡ）が現在使用中のリソースに対して別のアプリケーション（アプリケーションＢ）からのアクセス要求を受け付けると（２）、アプリケーションＢの優先度がアプリケーションＡよりも高い場合に、アプリケーションＡに対してリソースを開放するように要求する（３）。アプリケーションＡは、この要求を受けて、リソースの使用を中断するための処理（４）を行った後、競合解決部に対して、リソースの開放を完了した旨の通知を返す（５）。競合解決部はこの通知を受けて、アプリケーションＢに対してリソースへのアクセス許可を行い（６）、アプリケーションＢは、この許可を受けて初めてリソースへアクセスする（７）。

　また別の方法として、リソースへアクセスするための関数として特別な関数を用意しておき、その特別な関数の中で、例えばあるリソースをどのようなアプリケーションが使用中でも電話アプリケーションが必ずそのリソースを優先的に取得するようなコードを記述して、アドホックな対応で優先度を管理する場合もあった。

　あるいは、アプリケーションが切り替わるタイミングにおいて全てのアプリケーションが使用中のリソースを一旦開放するように、アプリケーション自身が設計される場合もあった。

　さらに、アプリケーションの競合を避ける別種の方法として、特許第２８２８９７１号公報（特許文献１）に開示されているように、キューを用いる方法がある。ユーザはキューに入れられたジョブの順番を自由に入れ替えることができるので、特定のアプリケーションによる要求をキューの先頭に登録することによって、そのアプリケーションに優先的にリソースを割り当てることが可能となる。
特許第２８２８９７１号公報

　しかしながら、上記の従来の方法には以下の問題がある。

　つまり、図１５に示した競合解決部を用いる方法では、アプリケーションの作成者は、リソース競合を解決するソフトウェアコンポーネントである競合解決部の仕組みを理解し、その仕組みに沿ってアプリケーションを作成しなければならない。すなわち、図１５の（３）の要求の有無をモニタし、この要求が出た場合に（４）の処理を実行後、（５）の通知を行うといった一連の処理や、（２）の要求を出した後、（６）の許可を受けてから（７）のアクセスを開始するといった一連の処理が、予めアプリケーションに組み込まれている必要があった。したがって、アプリケーションの作成が困難であった。また、もし仮にその仕組みに沿って作成されていない不正なアプリケーションが存在した場合には、優先度の高いアプリケーションがリソースを要求したとしても、不正なアプリケーションによってリソースが占有されたままになってしまうという重大な問題があった。つまり、たった一つのアプリケーションの不備がシステム全体に影響を及ぼしてしまう可能性があった。

　また、リソースにアクセスするための関数として例えば電話アプリケーション専用の特別な関数を用意してアドホックな対応で優先度を管理する場合には、汎用的ではない関数を組み込む必要があるため、ソフトウェアの再利用が困難であった。すなわち、リソースにアクセスする関数やリソースのプログラムが特殊化されるため、これらを汎用的に利用することが困難であった。

　また、キューを用いる方法では、ユーザが意図的にキューの順番を入れ替えない限り、リソースへのアクセス要求は、要求が発せられた順番に処理される。したがって、特定のアプリケーションの処理を自動的に他のアプリケーションよりも優先して処理することはできない。

　それゆえに、本発明は、アプリケーションの作成者が特別な注意を払わなくてもリソース競合解決が適切に行われるような情報処理端末及び情報処理方法を提供することを目的とする。

　また、リソース競合解決の仕組みに沿わない不正なアプリケーションが存在する場合においてもリソース競合解決が適切に行われるような情報処理端末及び情報処理方法を提供することを目的とする。

　また、特殊な関数を用意することなくリソース競合解決が適切に行われるような情報処理端末及び情報処理方法を提供することを目的とする。これにより、リソース部へアクセスするための関数やリソース部のプログラムを汎用的に記述することができ、その結果、それらを再利用して他のシステムに容易に適用することができる。

　上記目的を達成するために、本発明は以下の構成を採用した。すなわち本発明の情報処理端末は、複数のソフトウェアを含む実行部と、前記ソフトウェアによりアクセスされる１以上のリソースを含むリソース部と、前記リソース部にアクセスするための汎用的なインターフェイスを用いて、前記実行部のソフトウェアによるリソースへのアクセスを仲介するリソースアクセス部と、リソースが現在使用されているかどうかを判定する使用状態判定部と、リソースを現在使用しているソフトウェアである使用中ソフトウェアの優先度を管理する使用中ソフトウェア優先度管理部と、リソースへのアクセス要求を行っているソフトウェアである要求ソフトウェアの優先度を取得する要求ソフトウェア優先度取得部と、前記使用中ソフトウェア優先度管理部から得た優先度と、前記要求ソフトウェア優先度取得部から得た優先度とを比較し、どちらのソフトウェアが優先されるかを判定する競合判定部とを備える。そして、前記リソースアクセス部は、前記使用状態判定部の判定結果と前記競合判定部の判定結果に基づいて、（Ａ）リソースが現在空いている場合、もしくは要求ソフトウェアの優先度が使用中ソフトウェアの優先度よりも高い場合には、要求ソフトウェアの要求に従ってリソースにアクセスするとともに、使用中ソフトウェアに対してエラーを通知し、（Ｂ）要求ソフトウェアの優先度が使用中ソフトウェアの優先度よりも低い場合には、要求ソフトウェアにエラーを通知する。

　以上のように本発明によれば、リソースアクセス部により優先度に基づきリソースのアクセス制御を行うことで、個々のソフトウェア作成時に、特定のソフトウェア（例えば携帯電話の場合には電話機能）を優先することを考慮しなくてよくなり、ソフトウェア作成者の負担が減少し、ソフトウェアの構成もより単純になる。また、特定の機能（例えば電話機能）を優先するという特別なルールが不要になるため、サードパーティがソフトウェアを作成する敷居が低くなり、より多くのソフトウェアが作成されることが期待される。また、各ソフトウェアの優先度を任意に設定しなおしたい場合には、テーブル等で規定されたルールを変更するだけでよく、ソフトウェアの再利用性が向上する。さらに、リソース部１６のプログラムとしては、本発明の競合解決の枠組みに合う関数を作成してリソースアクセス部１１に登録するだけでよく、リソース部１６の再利用性が高まる。

　以下、本発明の種々の実施の形態について、図面を参照して説明する。

　（第１の実施形態）
　図１に、本発明の第１の実施形態に係る情報処理端末の構成を示す。図１において、情報処理端末は、リソースアクセス部１１と、使用状態判定部１２と、競合判定部１３と、使用中ソフトウェア優先度管理部１４と、要求ソフトウェア優先度取得部１５と、リソース部１６と、実行部１７とから構成される。

　リソース部１６は、携帯端末などにおけるデバイスであって、例えばスピーカや液晶ディスプレイなどである。実行部１７はプログラムであって、より具体的には、アプリケーション、あるいはアプリケーションにくみ込み可能なライブラリやその他のミドルウェア、あるいはドライバである。

　次に、上記構成を有する情報処理端末の動作を、図２のシーケンスチャートを参照して説明する。この図のシーケンスチャートを説明するにあたり、実行部１７はアプリケーションであると仮定する。また、リソース部１６にアクセスするための関数群は予めリソースアクセス部１１に登録してあるとする。この登録は、リソースアクセス部１１が提供する汎用的なインタフェースにより行われるため、リソース部１６の作成者はそのガイドラインにさえ従っていれば良く、第三者がこのリソース部１６を作成することは容易である。

　まず、ユーザの操作を契機として、アプリケーションＡよりも優先度が高いアプリケーションＢが、リソース部１６を使用するためにリソースアクセス部１１に対してアクセス要求を行う（Ｓ１）。

　次に、リソースアクセス部１１は、アプリケーションＢの要求を解析し、アプリケーションＢがアクセスしようとしているリソースを認識し、そのリソースを他のアプリケーションが現在使用中かどうか、使用状態判定部１２に対して問い合わせを行う。使用状態判定部１２は、指定されたリソースにアクセスしているアプリケーションがあるかどうかを判定し、リソースアクセス部１１にこの判定結果を返す（Ｓ２）。リソースアクセス部１１はこの判定結果を受けて、リソースを現在使用中のアプリケーションがなければ（Ｓ２でＮＯ）、アプリケーションＢが要求したコマンドをリソース部１６に伝える（Ｓ８）。このとき、予めリソースアクセス部１１に登録しておいた関数が使用される。

　ステップＳ２で、リソースを現在使用中のアプリケーション（アプリケーションＡ）があると判定された場合は（Ｓ２でＹＥＳ）、リソースアクセス部１１は競合を解決するために競合判定部１３にアプリケーションＢの情報を渡し、判定を要求する。競合判定部１３は、まず現在使用中のアプリケーションＡの優先度を使用中ソフトウェア優先度管理部１４に問い合わせ、アプリケーションＡのリソースに対する優先度を得る（Ｓ３）。なお、使用中ソフトウェア優先度管理部１４は、あるアプリケーションがあるリソースを使用したときに、例えば図３に示すような優先度管理テーブルを参照してこのアプリケーションの優先度を取得し、管理する。

　次に、競合判定部１３は、要求ソフトウェア優先度取得部１５に問い合わせて、アプリケーションＢのリソースに対する優先度を得る（Ｓ４）。なお、要求ソフトウェア優先度取得部１５は、例えば図３に示すような優先度管理テーブルを参照して、アプリケーションＢの優先度を取得する。このテーブルにおいて、アプリケーションの種類としては、例えば、図３に示すようにアプリケーションの名前を使用してもよいし、アプリケーション毎に振られるアプリケーションＩＤを使用してもよいし、アプリケーションをグループ化した場合にアプリケーショングループ毎に振られるアプリケーショングループＩＤを使用してもよいし、アプリケーションを実行しているプロセスやスレッドのＩＤを使用してもよい。このようにテーブルで優先度を管理することで、簡単に優先度の設定を変更ができ、将来優先度が変更した場合にもアプリケーションを変更しなくてもよい。

　そして、競合判定部１３は、使用中ソフトウェア優先度管理部１４から得られたアプリケーションＡの優先度と、要求ソフトウェア優先度取得部１５から得られたアプリケーションＢの優先度とを比較し、その比較結果をリソースアクセス部１１に返す。（ステップＳ５）。

　リソースアクセス部１１は、競合判定部１３の比較結果を基に、アプリケーションＢの優先度がアプリケーションＡよりも低ければ、リソースへのアクセスを拒否すべくアプリケーションＢに対してアクセスエラーを返す（Ｓ６）。一方、アプリケーションＢの優先度がアプリケーションＡよりも高ければ、予め登録されている関数をコールすることによってリソース部１６に対してアプリケーションＡの処理をキャンセルするよう要求する（Ｓ７）。例えばアプリケーションＡがスピーカから音楽を出力させていた場合には、スピーカに音楽の出力を中止させる。つづいてアプリケーションＢの要求にしたがってリソースにアクセスする（Ｓ８）。このときリソースアクセス部１１は、リソース競合が発生してリソースが奪われたことをアプリケーションＡに対してエラーとして通知する。同時にどのアプリケーションとリソースの競合が発生しているのか通知することも可能である。

　このように、本実施形態では、例えばアプリケーションＡがスピーカを使用しているときにアプリケーションＢが緊急に音を鳴らしたい場合に、アプリケーションＢがスピーカへのアクセス要求をリソースアクセス部１１に行うと、リソースアクセス部１１は自動的にアプリケーションＡによるスピーカの使用をキャンセルしてアプリケーションＢの要求を実行する。したがって、アプリケーションＡやアプリケーションＢは、競合を解決するための特別な処理（図１５の（２）、（３）〜（６））を行う必要が無く、単にリソースアクセス部１１にリソースへのアクセス要求を行うだけでよい。また、アプリケーションの優先度を変更する必要が生じた場合にも、図３に示すようなテーブルの内容を更新するだけでよく、アプリケーションやリソース部１６に手を加える必要がない。また、リソース部１６の実行関数としては、単に処理のキャンセルを行う関数や処理を実行する関数を作成してリソースアクセス部１１に登録しておくだけでよいため、競合解決のために特別な関数を用意する必要がない。

　したがって、本発明の第１の実施形態によれば、アプリケーションの作成者がリソース競合解決について意識しつつアプリケーションを作成しなくても、アプリケーションの優先度をアプリケーションと関連付けて管理することにより、リアルタイムシステムなどで必要となるリソースの瞬時の委譲を行うことが可能となる。また、リソース部１６を汎用的な枠組みで作成することができるため、リソース部１６の再利用性が高くなる。

　なお、本実施形態では、実行部１７がアプリケーションであると仮定したが、実行部１７はアプリケーションに限らず、単にアプリケーションから要求を受けたミドルウェアや、ドライバなどのソフトウェアであってもよい。

　また本実施形態では、使用中ソフトウェア優先度管理部１４および要求ソフトウェア優先度取得部１５は、図３に示すような単にアプリケーション毎に優先度が設定されているような優先度管理テーブルに基づいて優先度を取得するとしたが、本発明はこれに限らない。例えば、図４に示すように、アプリケーションの種類とリソースの種類との組み合わせ毎に優先度が設定されているような優先度管理テーブルに基づいて優先度を取得してもよい。

　さらには、アプリケーションが使用しているリソースの数や時間を計測しておき、それらの情報に基づいて優先度を判定してもよい。例えば、より多くのリソースを占有しているアプリケーションほど、またはより長くリソースを使用しているアプリケーションほど優先度が低くなるように優先度を動的に変化させてもよい。そうすることによって、一部のアプリケーションだけがリソースを使用し続けたり多数のリソースを占有したりすることを防ぐことができる。

　また、リソースの一例としてスピーカをあげたが、リソースはスピーカに限らず、例えばＬＥＤやディスプレイであってもよいし、さらには具体的なデバイスに限らず、通信コネクションのような抽象的なリソースであってもよい。

　また、本実施形態では、アプリケーションＡとアプリケーションＢの優先度が同じ場合には図２のステップＳ５でＮＯと判断されてアプリケーションＢにエラーが通知されるとしたが、変形例として、アプリケーションＡとアプリケーションＢの優先度が同じ場合にはステップＳ５でＹＥＳと判断してアプリケーションＡの処理をキャンセルするようにしてもよい。

　また、例えばアプリケーションＡが使用していたリソースをアプリケーションＢが奪ったときに、リソースアクセス部１１がその旨を記憶しておき、その後、アプリケーションＢがこのリソースを開放した時点で、リソースアクセス部１１がこのリソースに関するアプリケーションＡの処理を実行するようにしてもよい。また、アプリケーションＡが使用していたリソースをアプリケーションＢが奪い、さらにこのリソースをアプリケーションＣが奪った場合などに、アプリケーションＣがこのリソースを開放した時点で、リソースを奪われていたアプリケーション（ここではアプリケーションＡおよびアプリケーションＢ）の中から最も優先度の高いアプリケーションを選択して、開放されたリソースに対するこの選択されたアプリケーションの処理を実行するようにしてもよい。このとき、処理を再開したことをこの選択されたアプリケーションに通知してもよい。

　（第２の実施形態）
　次に、本発明の第２の実施形態について説明する。本実施形態は、使用中のリソースを一旦他のアプリケーションに奪われたアプリケーションがこのリソースに対して再度アクセスを要求したときに、リソースアクセス部がこのアプリケーションに対して、リソースが他のアプリケーションに奪われていたことを通知することを特徴とする。これにより、その通知を受けたアプリケーションが、その後必要な処理を行うことが可能になる。

　図５に、第２の実施形態の情報処理端末の構成を示す。なお図５において、図１と同一の構成には同一の参照符号を付し、説明を省略する。

　アプリ別デバイス状態管理部１８は、例えば図６に示すようなテーブルにより、アプリケーション（より一般的にはソフトウェア）毎に、デバイス（より一般的にはリソース）の使用状態等を管理する。なお、図６において、「デバイスの使用状態」としては、アプリケーションによるデバイスの使用状態が保持される。例えば図５の例では、メロディプレイヤーが使用していたＭＩＤＩデバイスを電話アプリが奪って現在使用していることが分かる。「リソース初期化関数へのポインタ」としては、アプリケーションが使用するリソースタイプごとに定義できるリソース初期化関数が指定される。デフォルトの初期化関数を使用することも可能である。リソース初期化関数が必要ない場合にはＮＵＬＬとなる。「イベント要否」としては、リソースを再取得したとき、もしくはリソースを奪われた時などに、アプリケーションに通知をすべきかどうかが指定される。

　次に、第２の実施形態の処理を、図７のシーケンスチャートを参照して説明する。ここでは、アプリケーションＡがあるリソースに対して一度アクセスしてから、再度同じリソースにアクセスするときを想定して説明する。

　まずアプリケーションＡが、リソースアクセス部１１に対してリソースに対するアクセスを要求する（Ｓ１１）。

　ステップＳ１２〜Ｓ１７の処理については、要求ソフトウェアがアプリケーションＡであって、使用中ソフトウェアがアプリケーションＢである点を除いて、図２に示したステップＳ２〜Ｓ７の処理と同じであるため、説明を省略する。

　ステップＳ１２で、アプリケーションＡがアクセスしようとするリソースが使用中でなかった場合には、ステップＳ１８に進む。また、ステップＳ１７の後もステップＳ１８に進む。

　ステップＳ１８で、リソースアクセス部１１は、要求ソフトウェアであるアプリケーションＡが、リソースを使用中に他のアプリケーションにリソースを奪われている状態かどうかを判断する。この判断は、アプリ別デバイス状態管理部１８で管理されているアプリケーションＡのデバイス使用状態（図６の「デバイス使用状態」）を参照してなされる。アプリケーションＡがリソースを使用中に他のアプリケーションにリソースを奪われていたことが判明した場合には、リソースアクセス部１１はこの旨をアプリケーションＡに通知する（Ｓ１９）。そうでなかった場合には、リソースアクセス部１１はアプリケーションＡのアクセス要求に基づいてリソースにアクセスする（Ｓ２０）。

　ステップＳ１９でリソースアクセス部１１からの通知を受けたアプリケーションＡは、必要に応じて、リソースの初期化処理等を改めて行う。アプリケーションＡが使用していたリソースを一旦他のアプリケーションに奪われたということは、リソースの設定が、アプリケーションＡが使用していたときの状態から変更されてしまっている可能性があるからである。

　以上のように、本実施形態によれば、あるアプリケーションが使用中のリソースを他のアプリケーションに奪われたときに、その旨をアプリ別デバイス状態管理部１８で管理しておくことにより、このアプリケーションが再度リソースにアクセスした時に、このアプリケーションにその旨を通知することができる。この通知によって、アプリケーションは、以前使用していたときからリソースの状態が変わっているかも知れないことが分かり、必要なリソースの初期化処理などを再度行うことが可能となる。

　（第３の実施形態）
　上記の第２の実施形態では、リソースアクセス部からの通知を受けたときに、アプリケーション自身が適宜リソースの初期化処理を行うが、第３の実施形態では、この初期化処理をリソースアクセス部が代行することを特徴とする。なお、第３の実施形態に係る情報処理端末は、第２の実施形態のものと比較して、リソースアクセス部の動作が上記のように異なるだけであるので、本実施形態の構成を示す図として図５を援用する。

　以下に、リソース毎に初期化が必要かどうかを判定し、必要であったときに初期化処理をリソースアクセス部が実行する場合の処理の流れを、図８に示すシーケンスチャートを用いて説明する。なお、図８のステップＳ２１〜Ｓ２７の処理は、図２のＳ１〜Ｓ７の処理と同じであるため説明を省略する。

　ステップＳ２８では、リソースアクセス部１１は、アプリケーションＢの要求に従ってリソースにアクセスする前に、リソースのリセット（初期化）が必要かどうか判定し（ステップＳ２８）、初期化が必要ない場合はそのままリソースへアクセスを行うが、初期化が必要な場合はステップＳ２９でリソースの初期化を行ってからリソースにアクセスする（Ｓ３０）。なお、リソースアクセス部１１は、初期化が必要かどうかをアプリ別デバイス状態管理部１８で管理されている図６のテーブルの「リソース初期化関数へのポインタ」の項目を参照して判断することができる。アプリケーションは、リソースを再取得した時にリソースアクセス部１１に初期化処理を代行してもらいたい場合に、その旨を予めリソースアクセス部１１を通じてアプリ別デバイス状態管理部１８の「リソース初期化関数へのポインタ」の項目に登録しておく。そして、この項目がＮＵＬＬであれば、リソースアクセス部１１はリソースの初期化が不要であると判断する。

　以上のように、本実施形態では、アプリケーションからアクセス要求があったときに、リソースアクセス部が必要に応じてリソースを初期化するため、アプリケーションが初期化をするかどうか意識する必要がなくなる。

　なお、ここではリソースごとに初期化が必要かどうかの判断を行うとしたが、リソースとアプリケーションとの組み合わせに基づいてリセットを行うかどうかを判断してもよい。また、ごく単純なシステムで、予めリセットをしてよいことが分かっている場合は、すべての場合においてリセットを行うようにしてもよい。

　また、あるアプリケーション（仮にアプリケーションＡとする）がリソースを使用している最中に他のアプリケーションにリソースを奪われた場合に、アプリケーションＡがリソースを使用していたときのリソースの状態をリソースアクセス部１１がアプリ別デバイス状態管理部１８に登録しておけば、アプリケーションＡが再びリソースにアクセスしようとしたときに、リソースアクセス部１１が前もってリソースの状態を以前の状態に戻すことができる。これにより、アプリケーションＡは、たとえ途中でリソースを奪われたとしてもリソースのリセットを行うことなく再び以前と同じ状態でリソースにアクセスすることができる。例えば、アプリケーションＡがスピーカを音量３で使用中に、アプリケーションＢにスピーカを奪われた場合に、アプリケーションＢがスピーカを音量５に変更しても、再びアプリケーションＡがスピーカを使用するときにはリソースアクセス部１１がリソースの状態を以前の状態（つまり音量３の状態）に自動的に戻してくれるため、アプリケーションＡは、リソースを奪われたことを意識せずともリソースを使用することができる。

　（第４の実施形態）
　図９に、第４の実施形態の情報処理端末の構成を示す。なお、図９において、図１と同一の構成には同一の参照符号を付し、説明を省略する。なお、本実施の形態が第１の実施形態と異なる点は、アプリケーションの優先度が暗号化されてアプリケーション自体に組み込まれている点である。

　暗号解析部１９は、アプリケーションに組み込まれている暗号化された優先度を解読する機能を有する。

　以下、第４の実施形態の動作を図１０のシーケンスチャートを参照して説明する。図１０において、ステップＳ４１〜Ｓ４４の処理は、ステップＳ４４で要求ソフトウェア優先度取得部１５が取得する要求ソフトウェアの優先度の情報が暗号化されている点を除けば、図２のステップＳ１〜Ｓ４の処理と同じである。

　ステップＳ４５で、暗号解析部１９は、要求ソフトウェア優先度取得部１５がアプリケーションＢから取得した暗号化された優先度を解読するが、この暗号解読に失敗すると、アプリケーションＢは信用できないアプリケーションであるとして、アクセス要求を受け入れずにアプリケーションＢにエラーを返す（Ｓ４７）。暗号解読に成功すると、ステップＳ４６に進む。ステップＳ４６以降の処理は、図２のステップＳ５以降の処理と同じである。

　以上のように、優先度の信頼性を高めることにより、不正なアプリケーションが他の優先度の高いアプリケーションになりすましたり、自身の優先度を自由にコントロールするような事態を防止することができる。

　（第５の実施形態）
　次に、本発明の第５の実施形態の情報処理端末について説明する。

　なお第５の実施形態が第１の実施形態と異なる点は、アプリケーションの優先度が、アプリケーションに組み込まれているライブラリやモジュールによって変化する点である。その他の構成や動作については第１の実施形態と同様であるので、本実施形態の説明では図１を援用する。

　第１の実施形態では図３に示すように競合判定部１３がアプリケーションの種類をもとに優先度を判断したが、本実施形態では図１１に示すように、競合判定部１３がライブラリやモジュールの種類をもとに優先度を判断する。さらにライブラリ内で優先度を変えたい場合は、処理ごとに優先度の異なるスレッドを作成してもよい。あるいは、ライブラリの管理者ＩＤなどの属性値をもとに優先度を判断してもよい。

　また、アプリケーションがリソースにアクセスする毎に使用中ソフトウェア優先度管理部１４に優先度を記述することで、アプリケーションを構成するモジュールごとに優先度を変えながら処理をすることが可能となる。

　優先度としては、アプリケーションごとに含まれるモジュールの優先度の内、最高の優先度同士を比較してもよいし、最低の優先度同士を比較してもよい。また、実行中のライブラリにあわせて優先度を変化させても良い。

　以上のように優先度を動的に変化させることにより、例えば同じアプリケーションであっても、処理の内容によって優先度が高い状態で処理したい場合や、低い優先度でも良い場合などが混在した場合に、状況に応じた最適な優先度で処理することができる。具体的には、電話の通話中には電話アプリケーションの優先度を高くして、電話のメニューを表示している場合では電話アプリケーションの優先度を低くするなど、状況によって最適な優先度は異なる。

　また、あるアプリケーションが、信頼できないソフトウェアハウスによって作成されたライブラリ（例えば図１１のライブラリＢ）を使用している場合、そのアプリケーション自体の信頼度が低下するために、そのライブラリの優先度にあわせてアプリケーションの優先度を低くして動作することは合理的であると考えられる。

　（第６の実施形態）
　次に、本発明の第６の実施形態の情報処理端末について説明する。図１２に、情報処理端末の構成を示す。なお、図１２において、図１と同一の構成には同一の参照符号を付し、説明を省略する。本実施形態では、リソースアクセス部１１は、画面制御部２２から画面の重なり具合の情報を得て優先度を判断する。リソースアクセス部１１は、画面の重なり具合が変わるたびに画面制御部２２から通知を受け、画像が最上面にあるアプリケーションをもっとも優先度が高いアプリケーションとして扱う。

　例えば、図１３に示すように、メロディプレイヤＡの演奏画面とメロディプレイヤＢの演奏画面をユーザが任意に切り替える場合には、画面が切り替わるたびに画面制御部２２からリソースアクセス部１１に対して通知がなされ、リソースアクセス部１１は、この通知に基づいて、演奏画面が最上面として表示されている方のメロディプレイヤの優先度を、他方のメロディプレイヤの優先度よりも高いものとして扱う。その結果、メロディプレイヤＡの演奏画面が最上面である場合には、メロディプレイヤＡにより再生された音楽（図１３の例では動画に合わせた音楽）がスピーカから出力され、一方、メロディプレイヤＢの演奏画面が最上面である場合には、メロディプレイヤＢにより再生された音楽（図１３の例では着信メロディ）がスピーカから出力される。

　なお、これを応用して、最上面に表示されているアプリケーションが例えばリソースを要求していなければ、そのリソースへのすべてのアクセスを拒否するようにしてもよい。

　また、情報処理端末のディスプレイにメロディプレイヤＡの演奏画面とメロディプレイヤＢの演奏画面が両方表示される場合（例えば画面の上半分にメロディプレイヤＡの演奏画面が表示され、下半分にメロディプレイヤＢの演奏画面が表示されるような場合）には、ユーザがキー操作によって選択した側の画面（上半分または下半分）のメロディプレイヤの音をスピーカより出力してもよい。

　また、最上面に表示されているアプリケーションからのリソースアクセス要求が終わると、上から２番目の面のアプリケーションに対してリソースアクセスを許すようにしてもよい。

　また、通常はアプリケーションの優先度を画面の重なり具合で判断するのではなくその他の指標（例えば図３のテーブル等）によって判断し、判断の結果、複数のアプリケーションの優先度が同じだった場合にのみ、画面の重なり具合に基づいて優先度を判断するようにしてもよい。

　また、最上面に表示されているアプリケーションがリソースをいったん開放した後、別のアプリケーションがこのリソースを獲得し、さらにその後、最上面に表示されていた元のアプリケーションが再度リソースを要求した場合に、再度このアプリケーションにリソースを渡すこともできる。

　以上のように、第６の実施形態によれば、例えば同じ優先度のアプリケーション（例えばメロディプレイヤ）が２つあった場合にも、最前面に表示されているアプリケーションが音を優先的に鳴らすことが可能となり、かつ、バックグラウンドに回されたアプリケーションはリソースアクセス部１１の働きによってリソースの開放を意識しなくてよくなる。さらに、フォアグラウンドにいるアプリケーションが音の出力を止めた場合（すなわちリソースを開放した場合）には、バックグラウンドにいたアプリケーションがリソースを取得して音の出力を再開することができる。

　なお、以上の実施形態において、リソースを奪われたアプリケーションは、その旨をユーザに通知してもよい。このとき、リソースが奪われたことだけでなく、なぜ奪われたかをユーザに通知してもよい。

　また、以上の実施形態において、リソースを奪われたアプリケーションは、その旨をユーザに通知せずにそのまま処理を継続し、処理が完了した時点で処理が完了した旨をユーザに通知してもよい。

　本発明にかかる情報処理端末及び情報処理方法は、一例として携帯電話に適用することが可能であり、この場合、携帯電話で実行される個々のアプリケーション作成時に、アプリケーション作成者の負担が減少し、アプリケーションの構成もより単純になるという効果を奏する。

本発明の第１の実施形態に係る情報処理端末の構成を示すブロック図である。 本発明の第１の実施形態に係る情報処理端末の処理手順を示すシーケンスチャートである。 本発明の第１の実施形態に係る情報処理端末においてアプリケーション毎に優先度を管理するための優先度管理テーブルの一例である。 本発明の第１の実施形態に係る情報処理端末においてアプリケーション毎に優先度を管理するための優先度管理テーブルの一例である。 本発明の第２の実施形態に係る情報処理端末の構成を示すブロック図である。 本発明の第２の実施形態に係る情報処理端末においてアプリ別デバイス状態管理部が管理するテーブルの一例である。 本発明の第２の実施形態に係る情報処理端末の処理手順を示すシーケンスチャートである。 本発明の第３の実施形態に係る情報処理端末の処理手順を示すシーケンスチャートである。 本発明の第４の実施形態に係る情報処理端末の構成を示すブロック図である。 本発明の第４の実施形態に係る情報処理端末の処理手順を示すシーケンスチャートである。 本発明の第５の実施形態に係る情報処理端末においてライブラリ毎に優先度を管理するための優先度管理テーブルの一例である。 本発明の第６の実施形態に係る情報処理端末の構成を示すブロック図である。 本発明の第６の実施形態において画面の上下関係が切り替わるときの様子を示す図である。 従来の携帯電話においてウェブページの表示中に電話が着信したときに電話機能が優先される様子を示す図である。 競合解決部を用いて競合を解決する従来の装置の構成を示す図である。

符号の説明

１１　リソースアクセス部
１２　使用状態判定部
１３　競合判定部
１４　使用中ソフトウェア優先度管理部
１５　要求ソフトウェア優先度取得部
１６　リソース部
１７　実行部
１８　アプリ別デバイス状態管理部
１９　暗号解析部
２２　画面制御部

Claims (14)

1. 　複数のソフトウェアを含む実行部と、
   　前記ソフトウェアによりアクセスされる１以上のリソースを含むリソース部と、
   　前記リソース部にアクセスするための汎用的なインターフェイスを用いて、前記実行部のソフトウェアによるリソースへのアクセスを仲介するリソースアクセス部と、
   　リソースが現在使用されているかどうかを判定する使用状態判定部と、
   　リソースを現在使用しているソフトウェアである使用中ソフトウェアの優先度を管理する使用中ソフトウェア優先度管理部と、
   　リソースへのアクセス要求を行っているソフトウェアである要求ソフトウェアの優先度を取得する要求ソフトウェア優先度取得部と、
   　前記使用中ソフトウェア優先度管理部から得た優先度と、前記要求ソフトウェア優先度取得部から得た優先度とを比較し、どちらのソフトウェアが優先されるかを判定する競合判定部とを備え、
   　前記リソースアクセス部は、前記使用状態判定部の判定結果と前記競合判定部の判定結果に基づいて、
   （Ａ）リソースが現在空いている場合、もしくは要求ソフトウェアの優先度が使用中ソフトウェアの優先度よりも高い場合には、要求ソフトウェアの要求に従ってリソースにアクセスするとともに、使用中ソフトウェアに対してエラーを通知し、
   （Ｂ）要求ソフトウェアの優先度が使用中ソフトウェアの優先度よりも低い場合には、要求ソフトウェアにエラーを通知することを特徴とする、情報処理端末。
2. 　ソフトウェア毎にリソースの使用状態を管理するソフトウェア別リソース状態管理部をさらに備え、
   　前記リソースアクセス部は、前記実行部からリソースに対するアクセス要求を受けたときに前記ソフトウェア別リソース状態管理部を検索し、前回の使用中に一旦リソースを奪われたソフトウェアからの再度のアクセスだと判断した場合に、リソースが以前途中で奪われたことを当該ソフトウェアに通知することを特徴とする、請求項１に記載の情報処理端末。
3. 　前記リソースアクセス部は、優先度の高いソフトウェアが優先度の低いソフトウェアからリソースを奪ったときに、リソースを奪われたソフトウェアに対してリソースが奪われたことを通知し、その後、奪われていた当該リソースが開放されて前記優先度の低いソフトウェアが当該リソースを再度獲得したときに、当該リソースが一旦他のソフトウェアに奪われていた旨を当該ソフトウェアに通知することを特徴とする、請求項１に記載の情報処理端末。
4. 　前記リソースアクセス部は、優先度の高いソフトウェアが優先度の低いソフトウェアからリソースを奪う場合に、当該優先度の低いソフトウェアによって現在実行されている処理をキャンセルした後で、リソースごとにリソースのリセットが必要かどうかを判断し、リセットが必要な場合にはリセット処理をしたあとで、リソースにアクセスすることを特徴とする、請求項１に記載の情報処理端末。
5. 　前記リソースアクセス部は、優先度の高いソフトウェアが優先度の低いソフトウェアからリソースを奪う場合に、前記優先度の低いソフトウェアによって現在実行されている処理をキャンセルした後で、リソースごとにリソースのリセットが必要かどうかを判断し、リセットが必要な場合には予めソフトウェアによって登録された所定のリセット処理を実行した後で、前記優先度の高いソフトウェアの要求に応じてリソースにアクセスすることを特徴とする、請求項４に記載の情報処理端末。
6. 　ソフトウェア毎にリソースの使用状態を管理するソフトウェア別リソース状態管理部をさらに備え、
   　前記リソースアクセス部は、一旦リソースが奪われてから当該リソースが開放されたため再度当該リソースにアクセス可能になったソフトウェアのためにリソースのリセット処理を実行し、当該リセット処理は、以前リソースが奪われたときの当該リソースの使用状態を前記ソフトウェア別リソース状態管理部から読み出し、その状態にリセット処理をした後で、当該ソフトウェアの要求に応じてリソースにアクセスすることを特徴とする、請求項１に記載の情報処理端末。
7. 　ソフトウェアから提供される暗号化された優先度を解読する暗号解析部をさらに備え、
   　前記競合判定部は、前記暗号解析部の解読結果に基づいて判定を行うことを特徴とする、請求項１に記載の情報処理端末。
8. 　前記競合判定部は、ソフトウェア毎に設定される優先度に加えて、ソフトウェアによってロードまたはリンクされて動作するモジュール毎に設定される優先度をも考慮して判定を行うことを特徴とする、請求項１に記載の情報処理端末。
9. 　前記競合判定部は、表示画面の重なりの制御を行うコンポーネントである画面制御部から各ソフトウェアの画面の順位を得て、当該情報に基づいてリソースにアクセスするための各ソフトウェアの優先度を判定することを特徴とする、請求項１に記載の情報処理端末。
10. 　前記競合判定部は、優先度が等しい複数のソフトウェアからアクセス要求を受け付けた場合に、前記画面制御部から各ソフトウェアの画面の順位を得て、画面が最上位にあるソフトウェアに対してリソースへのアクセスを優先的に許可することを特徴とする、請求項９に記載の情報処理端末。
11. 　ソフトウェアによりアクセスされる１以上のリソースを含むリソース部にアクセスするための汎用的なインターフェイスを用いて、ソフトウェアによるリソースへのアクセスを仲介するリソースアクセスステップと、
    　リソースが現在使用されているかどうかを判定する使用状態判定ステップと、
    　リソースを現在使用しているソフトウェアである使用中ソフトウェアの優先度を管理する使用中ソフトウェア優先度管理ステップと、
    　リソースへのアクセス要求を行っているソフトウェアである要求ソフトウェアの優先度を取得する要求ソフトウェア優先度取得ステップと、
    　前記使用中ソフトウェア優先度管理ステップで管理する優先度と、前記要求ソフトウェア優先度取得ステップで取得する優先度とを比較し、どちらのソフトウェアが優先されるかを判定する競合判定ステップとを備え、
    　前記リソースアクセスステップでは、前記使用状態判定ステップの判定結果と前記競合判定ステップの判定結果に基づいて、
    （Ａ）リソースが現在空いている場合、もしくは要求ソフトウェアの優先度が使用中ソフトウェアの優先度よりも高い場合には、要求ソフトウェアの要求に従ってリソースにアクセスするとともに、使用中ソフトウェアに対してエラーを通知し、
    （Ｂ）要求ソフトウェアの優先度が使用中ソフトウェアの優先度よりも低い場合には、要求ソフトウェアにエラーを通知することを特徴とする、情報処理方法。
12. 　ソフトウェア毎にリソースの使用状態を管理するソフトウェア別リソース状態管理ステップをさらに備え、
    　前記リソースアクセスステップでは、一旦リソースが奪われてから当該リソースが開放されたため再度当該リソースにアクセス可能になったソフトウェアのためにリソースのリセット処理を実行し、当該リセット処理は、前記ソフトウェア別リソース状態管理ステップで管理している以前リソースが奪われたときの当該リソースの使用状態を読み出し、その状態にリセット処理をした後で、当該ソフトウェアの要求に応じてリソースにアクセスすることを特徴とする、請求項１１に記載の情報処理方法。
13. 　前記競合判定ステップは、表示画面の重なりの制御を行うコンポーネントである画面制御部から各ソフトウェアの画面の順位を得て、当該情報に基づいてリソースにアクセスするための各ソフトウェアの優先度を判定することを特徴とする、請求項１１に記載の情報処理方法。
14. 　前記競合判定ステップでは、優先度が等しい複数のソフトウェアからアクセス要求を受け付けた場合に、前記画面制御部から各ソフトウェアの画面の順位を得て、画面が最上位にあるソフトウェアに対してリソースへのアクセスを優先的に許可することを特徴とする、請求項１３に記載の情報処理方法。
    
    

Images