JP4563710B2

JP4563710B2 - 携帯電話端末装置及びプログラム管理方法並びにそのコンピュータプログラム

Info

Publication number: JP4563710B2
Application number: JP2004100269A
Authority: JP
Inventors: 哲西田
Original assignee: Kyocera Corp
Current assignee: Kyocera Corp
Priority date: 2004-03-30
Filing date: 2004-03-30
Publication date: 2010-10-13
Anticipated expiration: 2024-03-30
Also published as: JP2005284906A

Description

本発明は、複数のプログラムを制御する携帯電話端末装置及びプログラム制御方法並びにそのコンピュータプログラムに関する。

従来の技術では、シングルタスクオペレーティングシステムにおいて、マルチタスク的な動きをさせるために、ＯＳ（オペレーティングシステム）のメモリ上で動作しているアプリケーションプログラムについてのスレッド履歴を記憶しておく。そして、次に動作を要求するアプリケーションプログラムがあるか否かをオペレーティングシステムにてタイマー等により監視する。次に動作を要求するアプリケーションプログラムがある場合には、アプリケーションプログラムのスレッド履歴に当該アプリケーションプログラムを追加し、当該アプリケーションプログラムにオペレーティングシステムが制御を切り替える。元に使用していたアプリケーションプログラムを再び操作するために切り替えるときは、蓄積されたスレッド履歴において最先に蓄積されたものから順に読み出して１つずつ処理を切り替える形にして実現していた（例えば、特許文献１）。

特許文献１に示す技術は、処理能力的に携帯電話機よりも余裕があり、かつ、着信のような突発的割り込み制御の発生率が低いパーソナルコンピュータ上での制御例である。
携帯電話機における従来技術では、複数のアプリケーションプログラムの起動指示がタイマー等から指定されたとしても、１つずつの処理が完了しない限りは、次のアプリケーションプログラムの処理に入ることができなかった。さらに、元のアプリケーションプログラムの状態を複数保持しておくこともできなかった。そのため、従来技術である特許文献２に示す携帯端末では、着信等の事象発生時にアプリケーションプログラムの種別または状態によって個別に監視して制御を行っている。
特開平６−４４０８４号公報特開２００３−３１９０２０号公報

しかしながら、特許文献１における技術はメモリ容量が豊富なパーソナルコンピュータ上での技術であり、アプリケーションプログラムが追加され、競合条件等が増えてもメモリを容易に追加することが可能である。一方、携帯電話端末装置はメモリが限られており、容易にメモリを増加することも困難であるという問題がある。また、特許文献２における技術においても、メモリの容量を考慮して割り込みイベント等の処理を考慮していないという問題がある。

本発明は、上記問題を解決すべくなされたもので、その目的は、限られたメモリ容量において、複数のプログラムを制御する携帯電話端末装置を提供することにある。

上述した課題を解決するために、本発明は、個別の処理を行うワーカー処理を複数含むアプリケーションプログラムを複数有する携帯電話端末装置であって、イベント情報を受信し、当該イベント情報に対応する処理を行うワーカー処理を有するアプリケーションプログラムを複数のプログラムの中から特定するとともに、当該特定したアプリケーションプログラムを含む前記複数のアプリケーションプログラムの動作を管理するプログラム管理手段と、前記プログラム管理手段により更新され、前記複数のアプリケーションプログラムの動作状態を記憶する動作状態記憶部と、前記複数のアプリケーションプログラムごとに関連付けて設けられ、自己の関連付けられたアプリケーションプログラムに含まれるワーカー処理を実行可能か否かを、予め設定されている所定の競合条件に基づいて判断する複数のイベントジャッジ手段と、を備え、前記プログラム管理手段は、前記イベント情報の受信に基づいて特定された所定のワーカー処理を実行するよう、前記複数のイベントジャッジ手段のうち、前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段に対して要求し、前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段は、前記所定の競合条件に基づいて、実行要求された前記所定のワーカー処理の実行可否を判断するとともに、前記所定のワーカー処理を実行可能と判断される場合には、前記プログラム管理手段は、前記動作状態記憶部を参照して、動作中として記憶されている他のアプリケーションプログラムを停止するとともに、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行し、前記所定のワーカー処理を実行不能と判断される場合には、前記プログラム管理手段は、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行せず、前記動作状態記憶部にて動作中として記憶されている他のアプリケーションプログラムの動作を維持することを特徴とする携帯電話端末装置である。

本発明は、上記の発明において、前記プログラム管理手段は、前記動作中のプログラムを停止させる際に、前記プログラムを復帰させるための復帰情報を所定の記憶領域（復帰レベルテーブル８０）に記憶し、前記動作中のプログラムが終了した際に、前記復帰情報に基づいて前記プログラムを復帰させることを特徴とする。

本発明は、個別の処理を行うワーカー処理を複数含むアプリケーションプログラムを複数有する携帯電話端末装置のプログラム管理方法であって、イベント情報を受信し、当該イベント情報に対応する処理を行うワーカー処理を有するアプリケーションプログラムを複数のプログラムの中から特定するとともに、当該特定したアプリケーションプログラムを含む前記複数のアプリケーションプログラムの動作を管理するプログラム管理手段と、前記プログラム管理手段により更新され、前記複数のアプリケーションプログラムの動作状態を記憶する動作状態記憶部と、前記複数のアプリケーションプログラムごとに関連付けて設けられ、自己の関連付けられたアプリケーションプログラムに含まれるワーカー処理を実行可能か否かを、予め設定されている所定の競合条件に基づいて判断する複数のイベントジャッジ手段と、を備え、前記プログラム管理手段が、前記イベント情報の受信に基づいて特定された所定のワーカー処理を実行するよう、前記複数のイベントジャッジ手段のうち、前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段に対して要求する過程と、前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段が、前記所定の競合条件に基づいて、実行要求された前記所定のワーカー処理の実行可否を判断するとともに、前記所定のワーカー処理を実行可能と判断される場合には、前記プログラム管理手段が、前記動作状態記憶部を参照して、動作中として記憶されている他のアプリケーションプログラムを停止するとともに、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行し、前記所定のワーカー処理を実行不能と判断される場合には、前記プログラム管理手段が、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行せず、前記動作状態記憶部にて動作中として記憶されている他のアプリケーションプログラムの動作を維持する過程と、を備えたことを特徴とするプログラム管理方法である。

本発明は、個別の処理を行うワーカー処理を複数含むアプリケーションプログラムを複数有し、イベント情報を受信し、当該イベント情報に対応する処理を行うワーカー処理を有するアプリケーションプログラムを複数のプログラムの中から特定するとともに、当該特定したアプリケーションプログラムを含む前記複数のアプリケーションプログラムの動作を管理するプログラム管理手段と、前記プログラム管理手段により更新され、前記複数のアプリケーションプログラムの動作状態を記憶する動作状態記憶部と、前記複数のアプリケーションプログラムごとに関連付けて設けられ、自己の関連付けられたアプリケーションプログラムに含まれるワーカー処理を実行可能か否かを、予め設定されている所定の競合条件に基づいて判断する複数のイベントジャッジ手段と、を備える携帯電話端末装置のコンピュータに、前記プログラム管理手段が、前記イベント情報の受信に基づいて特定された所定のワーカー処理を実行するよう、前記複数のイベントジャッジ手段のうち、前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段に対して要求する手順、前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段が、前記所定の競合条件に基づいて、実行要求された前記所定のワーカー処理の実行可否を判断するとともに、前記所定のワーカー処理を実行可能と判断される場合には、前記プログラム管理手段は、前記動作状態記憶部を参照して、動作中として記憶されている他のアプリケーションプログラムを停止するとともに、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行し、前記所定のワーカー処理を実行不能と判断される場合には、前記プログラム管理手段は、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行せず、前記動作状態記憶部にて動作中として記憶されている他のアプリケーションプログラムの動作を維持する手順、を実行させるコンピュータプログラムである。

以上説明したように、この発明によれば、イベント情報によって新たなプログラムが起動された際に、他のプログラムの状態を参照して起動中のプログラムを停止させる構成となっている。そのため、携帯電話端末上では常に１つのプログラムだけを起動するように管理することができる。それによって、オペレーティングシステムが備えている複数のプログラムを同時に起動し、切り替える機能を利用する必要がなくなるため、プログラムを利用するアプリケーション側のメモリを節約して利用することが可能となる。

また、この発明によれば、起動中のプログラムを終了させる際に、当該プログラムを復帰させるための復帰情報を記憶する構成となっている。そのため、起動中の他のプログラムが終了した後に復帰させることが可能となる。それによって、オペレーティングシステムで備えていた複数のプログラムを切り替える機能と同じ機能を実現しつつ、メモリを節約することを可能としている。

以下、本発明の一実施形態による携帯電話端末装置を図面を参照して説明する。
図１は、この発明の一実施形態による携帯電話端末装置におけるアプリケーションプログラム管理に関わる部分の構成を示す概略ブロック図である。
イベントアプリケーションテーブル７０は、オペレーティングシステム（以下、ＯＳ：ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍと略す。）や他のアプリケーションプログラムから通知されたイベントをどのアプリケーションプログラムに通知するものかの対応付けを記憶しているテーブルである。

アプリケーション状態テーブル７１は、それぞれのアプリケーションプログラムの状態を記憶する。アプリケーション内部状態７２は、動作中のアプリケーションプログラムの動作状態を記憶する。
また、復帰レベルテーブル８０は、起動中に停止（＝Ｓｕｓｐｅｎｄ）されたアプリケーションプログラムや後述する競合判定により起動時に保留（＝Ｉｄｌｅ）されたアプリケーションプログラムの復帰時に必要な復帰情報を記憶するスタック型の記憶部である。
アプリケーション３０ａ、３０ｂ、３０ｃは、携帯電話端末装置内で動作するアプリケーションプログラムであり、待ち受けアプリケーション、メール、カメラ等のプログラムがある。

イベントジャッジ部２０ａ、２０ｂ、２０ｃは、アプリケーション３０ａ、３０ｂ、３０ｃごとに設けられており、アプリケーションプログラムを起動するイベントを受信した際に、起動中のアプリケーションプログラムとの関係で起動が可能か否かの競合状態を判定する。競合状態の判定のため、他のアプリケーションの状態や内部状態を照会する。また、自らが管理するアプリケーションプログラムに固有の競合条件を予め記憶しており、他のアプリケーションの状態や記憶している固有の競合条件に基づいて、アプリケーションプログラムの動作を決定する。

同図において、アプリケーション管理部（図中のＡＰＭＡＮ）１０は、携帯電話端末装置で発生する全てのイベントを受信し、受信したイベントを現在動作中のアプリケーション、もしくは、イベントアプリケーションテーブル７０に対応付けられているアプリケーションプログラムにイベントを通知する。

また、アプリケーション管理部１０は、アプリケーションプログラムの起動要求やその他のイベントの受信をＯＳから受信し、イベントアプリケーションテーブル７０から対応するアプリケーションプログラムのイベントジャッジ部にイベントを送信する。イベントジャッジ部からの問い合わせによって他のアプリケーションの状態情報等を応答する。イベントジャッジ部における結果に従って、起動要求のあったアプリケーションプログラムを起動し、現在動作中のアプリケーションを停止する。

また、イベントジャッジ部における判定結果において将来起動予定として保留されたアプリケーションや現在動作中で停止されたアプリケーションの復帰情報を復帰レベルテーブルに記憶する。また、動作中のアプリケーションの正常終了により、復帰レベルテーブルが記憶している中から優先度の最も高いアプリケーションの復帰情報を読み出して復帰させる。

図２は、従来と本実施形態のアプリケーション管理に関わる機能ブロックの構成の違いを示した図である。同図の（１）及び（２）において、ＯＳライブラリ１は、携帯電話端末装置においてアプリケーションプログラムを実際に実行するためのオペレーティングシステムの一部であり、ユーザが携帯電話端末装置を操作した場合等にその操作に基づいてイベントを発生させる。

同図（１）は、従来における構成を示した図であり、携帯電話端末装置のＯＳライブラリ１がユーザの操作によって発生する信号を受信し、アプリケーション３０にイベントの振り分けを行う。また、ＯＳライブラリ１は、アプリケーションの競合管理等も行っており、アプリケーションが追加される度に競合処理を新たに作り込む必要があるため、競合処理のために大きなテーブルを必要とし、非常に複雑な構成となっていた。

同図（２）は、本実施形態における構成を示した図であり、ＯＳライブラリ１はイベントをアプリケーション３０に直接通知せず、最初に、アプリケーション管理部１０に全てを通知する。各アプリケーション３０にはそれぞれのアプリケーション３０の競合条件を記憶しているイベントジャッジ部２０が個別に備えられている。アプリケーション管理部１０は、受信したイベントを各アプリケーション３０に振り分ける際、最初に対応するイベントジャッジ部２０に通知する。

イベントジャッジ部２０は、予め記憶している自らが管理するアプリケーションプログラムの競合条件に照らし合わせて、起動できるかどうかを判定する。その際、イベントジャッジ部は携帯電話端末装置のカメラ等を利用するための装置のリソースの状態や、他のアプリケーションの状態等をアプリケーション管理部１０に要求して取得する。そして、起動可能と判定した場合には対応するアプリケーション３０を起動する。起動可能でない場合には、保留するため復帰情報を復帰レベルテーブル８０に記憶する。

また、同図（２）において、アプリケーション管理部１０は、携帯電話端末装置において動作中のアプリケーション３０が常に１つになるように制御を行う。そのため、新しいアプリケーション３０が起動すると、起動中のアプリケーション３０を停止し、メモリ上から退避させるためにそのアプリケーションプログラムを終了させて、復帰情報を上述した復帰レベルテーブル８０に記憶する制御も行う。

従来では、ＯＳライブラリ１が、イベントの振り分け処理とアプリケーション３０の起動、終了、停止、保留及び復帰の処理と競合判定の処理を行っていた。一方、本実施形態では、アプリケーション管理部１０が、イベントの振り分け処理とアプリケーション３０の起動、終了、停止、保留及び復帰の処理を行い、それぞれのイベントジャッジ部２０が対応するアプリケーション３０に閉じて競合判定の処理を行っている。

そのため、競合判定の処理が１つの部分に集中せずに分散され、アプリケーション３０が追加されても、イベントジャッジ部２０を新たに設けることで、競合判定処理の追加をすることができる。例えば、カメラデバイスの性能向上時などにおいても、競合判定処理を変更する必要がなく、カメラデバイスの制御関係のアプリケーションプログラムの変更で済み、ＯＳやアプリケーション管理部１０等については大きな変更が伴わないようにすることができる。

また、アプリケーション管理部１０は、携帯電話端末装置上で１つしかアプリケーション３０を起動しないように制御している。そのため、ＯＳ上では１つのアプリケーションプログラムしか起動していないことになり、優先処理などの複雑な復帰処理ができないＯＳライブラリ１のスタック記憶領域を利用する必要がなくなる。

それによって、アプリケーションプログラムの競合判定をアプリケーション管理部１０だけで制御することが可能となり、機能追加等もＯＳを変更する必要なくアプリケーション側に閉じて実施することが可能となる。さらに、常に１つしかアプリケーションが起動しないため、競合判定処理の制約も少なくシンプルにすることができ、処理が容易になるだけでなく、設計上も有利に働く。

図３は、上述した復帰レベルテーブル８０を利用することによって達成するアプリケーションプログラム復帰時の優先処理の具体例を示した図である。
同図において、携帯電話端末装置上のアプリケーションプログラムの例として予め設定してある日付及び時刻になるとアラームが鳴動するスケジュールアラームと時間がくると自動的に電源を落とすオートパワーオフを取り上げている。

ここで、着信中にスケジュールアラームのイベントが通知され、その後オートパワーオフのイベントが通知された場合を想定する。従来では、スタックの最先にあるイベントから復帰させることしかできなかったため、オートパワーオフが復帰し、スケジュールアラームを鳴動することなく携帯電話端末装置の電源がオフ状態となる。このような仕様では、ユーザにとって不都合であるため、本実施形態では、最初にスケジュールアラームを鳴動し、その後オートパワーオフで電源をオフにするという順序の入れ替えを復帰レベルテーブル８０を利用して可能としている。

図４は、アプリケーション管理部１０がイベントを制御するための情報を記憶するテーブルを示した図である。
同図（１）のイベントアプリケーションテーブル７０は、アプリケーション管理部１０がＯＳライブラリ１から受信したイベントを振り分ける際に参照するテーブルであり、イベントとアプリケーションプログラムへの参照情報を対応付けて記憶している。
同図（２）のアプリケーション状態テーブル７１は、各アプリケーションの現在の状態を記憶しているテーブルであり、状態には動作中（Ａｃｔｉｖｅ）、停止中（Ｓｕｓｐｅｎｄ）、保留中（Ｉｄｌｅ）がある。

同図（３）のアプリケーション内部状態テーブル７２は、各アプリケーションの内部状態を記憶しているテーブルであり、例えば、Ｄｏｒｍａｎｔ（休止中）、ＮＵＬＬ（状態無し）、Ｗａｉｔ（待機中）、Ｃｏｎｎｅｃｔ（接続中）等、各アプリケーションに特有の状態を記憶している。

図５は、イベントジャッジ部２０の競合判定の結果によりアプリケーション管理部１０が起動中に停止、若しくは起動時に保留したアプリケーションプログラムを復帰させる際に必要となる情報を記憶する復帰レベルテーブル８０を示した図である。復帰レベルテーブル８０は、スタック型の記憶領域であり、最先に記憶したものから順に復帰させることになる。

また、同図に示す通り、復帰レベルテーブル８０ａ、８０ｂ、８０ｃ、８０ｄのように幾つかの復帰レベルごとにスタックを備えている。そして、アプリケーションプログラムに予め設定されている復帰レベルに従って、各アプリケーションプログラムを該当するレベルのスタックに記憶する。そして、現在動作中のアプリケーションが正常終了した際に、アプリケーション管理部１０が復帰レベルテーブルを参照し、優先度のレベルが最も高く、最先に記憶したアプリケーションプログラムを復帰させる。

上述したＯＳライブラリ１もアプリケーションを停止及び保留するためのスタック型の記憶領域を有しているが、１つしか有していないため、スタックに記憶したうち最先のアプリケーションプログラムからしか復帰させることができなかった。一方、本実施形態では、アプリケーションプログラムに予め設定された復帰レベルに従って記憶するため、携帯電話端末装置の仕様に合わせて復帰させるべき順番でアプリケーションプログラムを復帰させることを可能としている。また、アプリケーションプログラムの復帰レベルは任意に変更することができるため、携帯電話端末装置上で個々のユーザが自由に設定することが可能となる。

例えば、復帰に関する優先順位をユーザに指定可能にするならば、競合の発生するアプリケーションそれぞれに関し、個別の復帰レベルの番号を割振るよう、特に図示しない携帯電話端末装置の表示部にグラフィックユーザインタフェースを用いて表示させる。例えば、カメラ、Ｅメール受信、メール作成、オートパワーオフ、スケジュールアラーム、目覚ましアラーム等といった競合の起こりうる事象を列挙しておき、これらの隣に図示しないテンキーなどにより、個別の通し番号を１から割振らせる。

ここで、復帰レベルテーブルは通し番号分設けられており、これらのアプリケーションのそれぞれが保留されたときに、その時点のワーカーがスタックされていくこととなる。アプリケーションの数と通し番号の和は一致しなく、重複する番号が多少あっても良い。しかし、重複する場合は、重複する番号の復帰レベルテーブルに、異なるアプリケーションがスタックされうることとなり、復帰時には新しいものが先に復帰するような扱いとなる。

ここで、復帰レベルとして指定する番号に、「０」を指定させても良い。この場合は、復帰レベルテーブル「０」を設けるというよりも、保留指示がなされて通常は復帰レベルに従って復帰レベルテーブルにスタックされるところだが、「０」であるため復帰レベルテーブルにスタックされることなく、終了の処理扱いとなる。つまり、復帰レベル「０」の指定されたアプリケーションが起動されようとしたが、既に起動しているほかのアプリケーションとの競合判定が行われる。

そして、その判定の結果、起動不可と判定され、保留すると決定されたが、復帰レベルテーブルにこのワーカーはスタックされず、終了の扱いとなる。ユーザが、既に何らかのアプリケーションを起動している場合には、目覚ましアラームは鳴動させなくとも良いと思う場合に、この復帰レベル「０」を予め指定しておけばよい。それによって、このような細かなニーズにも対応できるようになる。

図６の子チェーンテーブル８１は、復帰の際にアプリケーションプログラムの親子関係を考慮して復帰させるために親子関係を記憶している。復帰レベルテーブル８０を参照して復帰させるアプリケーションプログラムを検出する際に、子の関係に該当するアプリケーションプログラムを検出する場合等にアプリケーション管理部１０が参照する。

図７は、本実施形態におけるアプリケーションプログラムの構成を示したブロック図である。同図において、ＯＳアプレット６０は、ＯＳに備わっているアプリケーションプログラムであり、ユーザがインターネット等のサービスを利用するために用いるブラウザ６２やＥメール６３等のプログラムの他に、待機機能６１ａ、アドレス帳６１ｂ等の一般的に用いられるアプリケーションを１つにパッケージ化したＯＳアプリケーション６１から構成されている。

ダウンロードアプレット４０は、ユーザが携帯電話端末装置を介して自らダウンロードしたゲーム等の幾つかのアプレット４０ａ、４０ｂ…を有している。ＵＩ（ＵｓｅｒＩｎｔｅｒｆａｃｅ）プロキシ５０は、主に各種アプリケーションプログラムの起動に関わるユーザへの画面表示などの制御を行うためのプログラムであって、電話機能５１、データ通信のためのコネクタ通信５２、発信確認画面５３、待受け５４及びＳＭＳ（ＳｈｏｒｔＭｅｓｓａｇｅＳｅｒｖｉｃｅ）５５等を備えている。

以下、本実施形態では、競合判定や復帰制御の対象をアプレットではなく、アプレットを構成する最小構成単位であるワーカーを基に処理や制御について説明する。制御対象をアプレットとしないのは、アプレットは更に幾つかのワーカーから構成されており、アプレット単位で制御を行うことは、そのアプレットに関連する複数のワーカーの動作も制御することになるため制御が複雑になるからである。

同図において、ワーカーとは例えば、ＯＳアプリケーション６１の待機機能６１ａ、アドレス帳６１ｂ等のそれぞれがワーカーとなる。また、ダウンロードアプレット４０においては、アプレット４０ａ及び４０ｂがワーカーとなる。さらに、また、ＵＩプロキシ５０の電話機能５１においては第１呼通話５１ａ及び第２呼通話５１ｂがワーカーとなり、待受け５４においては、それに含まれるスクリーンセーバー５４ａ及び節電５４ｂがワーカーとなる。

図８から図１４を参照して、イベントジャッジ部２０における競合判定の制御について説明する。図８は、競合判定制御におけるアプリケーション管理部１０及びイベントジャッジ部２０の関係を示した概略図である。

同図において、（１）アプリケーション管理部１０のイベント受信部１０ａは、アプレット６０（またはアプレット５０）からイベントを受信する。（２）イベント受信部１０ａは、アプレットに設定されているクラスＩＤ等の情報からどのワーカーに対する要求なのかを判断する。（３）イベントジャッジ部２０は、競合判定を行い、オペレーションを決定する。競合判定は、そのワーカーが起動できる状態かどうかを判断し、競合している場合には、起動ワーカーの保留、拒否及び起動中ワーカーの終了等の処理を決定する。（４）アプリケーション管理部１０のオペレーション実行制御部１０ｂは、決定されたオペレーションに従い、対応するアプレット６０（またはアプレット５０）において、ワーカーの起動だけでなく、終了及びワーカー復帰のための処理をアプリケーション終了制御部１０ｃやアプリケーション復帰制御部１０ｄに行わせる。

図９は、各ワーカーに割り当てられたイベントジャッジ部２０ごとに予め設定する競合条件テーブル９０の構成を示した図である。競合条件テーブル９０は同図に示すとおり、拒否条件９０ａと保留条件９０ｂのテーブルから構成されており、拒否条件９０ａ及び保留条件９０ｂごとに幾つかの条件の組み合わせを設定する。

ちなみに、携帯電話端末装置内部にて発生する全てのアプリケーションプログラムに伴うワーカーが起動する際に、既に起動中のアプリケーションプログラムのワーカーと競合し、即起動してはならない条件の全てが競合条件として拒否条件９０ａもしくは保留条件９０ｂのいずれかに予め記述される。例えば、スケジュールアラーム起動のワーカーは着信中には保留されるよう、スケジュールアラーム起動のワーカーに関する保留条件テーブルに条件の一つとして「着信中」が記述されている。

また、オートパワーオフ起動のワーカーも同様に着信中には保留されるよう、オートパワーオフ起動のワーカー保留条件の一つに「着信中」が記述される。さらに、拒否条件テーブルには、既に何らかのワーカーに対して割り込みで生じた場合には、起動する必要の無いような競合条件が記述される。

競合判定においては最初に、拒否条件９０ａを判定し、設定されている条件のうちいずれかの条件に該当した場合に、判定結果が拒否となる。拒否条件のいずれにも該当しない場合には、次に、保留条件９０ｂを判定し、保留条件９０ｂに設定されているいずれかの条件を満たしたときに、競合判定結果は保留となる。

拒否条件９０ａ及び保留条件９０ｂのどちらにも当てはまらなければ、競合判定結果は許可となる。例えば、着信中に予め設定していた時刻が到来し、スケジュールアラーム鳴動のワーカーがイベントジャッジ部に通知されたときには、イベントジャッジ部はこの「着信中」という競合条件が競合条件テーブルに記述されているか否かを判定する。この場合、先に述べたように保留条件９０ｂにこの条件が記述されるため、着信のワーカーを停止することなく、スケジュールアラーム鳴動のワーカーが起動を保留する。そして、イベントジャッジ部２０は、オペレーション実行制御部１０ｂに決定した内容を通知する。

図１０は、図９の条件の記述を具体的に示した図である。例えば、拒否条件としては
Ｅメール通信中（同図の条件１０）またはＳＭＳ通信中（条件１１）が設定されている。保留条件９０ｂはカメラ起動中（条件５０）かつ、カメラ撮影中（条件１２）の条件と、カメラ起動中（条件５０）かつ、カメラ保存中（条件１３）が設定されている。
なお、各条件に設定されている携帯電話端末装置のカメラ等を利用するための装置のリソース状態及び他のアプレットの状態等の競合判定に必要な情報については、イベントを受信したイベントジャッジ部２０がアプリケーション管理部１０に照会を行う。照会を受けたアプリケーション管理部１０は、装置のリソース情報及び各イベントジャッジ部が登録している各アプリケーションの状態等の情報を応答する。

図１１は、イベントジャッジ部２０の競合条件判定において競合判定の制御ができない様々なイベント発生時等の状況において、共通の状態に起因して携帯電話端末装置内部で発生する事象を考慮した特例措置の手段を説明するための図である。

同図において、特例競合管理テーブル９１は、複数のイベントに共通の競合条件をまとめたものであり、それぞれのイベントジャッジ部に対応する競合条件テーブル９０に個別に設定するよりも１つにまとめることで管理が容易による。設定されている値がＮＵＬＬの場合は、特例競合判定による動作が設定されていないことを意味する。ＮＵＬＬで無い場合には、ワーカー別特例競合テーブル９２への参照情報が格納される。

ワーカー別特例競合テーブル９２は、特例競合処理が必要なイベント、例えばワーカー起動、ワーカー終了等のイベントが設定されており、それに該当する特例競合処理関数９３への参照情報を格納している。
特例競合処理関数９３が実行する特例競合処理は、制御を決定する処理及びその他の必要な処理である。特例競合処理関数９３は、各ワーカーが提供するアプリケーションインタフェース（ＡＰＩ）であり、判定結果としてイベントジャッジ部２０の判定結果と同じ返り値である許可、保留、拒否を返すことで、その後のワーカー起動や終了の処理はイベントジャッジ部２０における競合判定処理と同様に行われる。

ここで、特例競合管理テーブル９１に設定される具体的な特例となる競合の例としてバッテリー残量を取り上げて説明する。携帯電話端末装置には充電式のバッテリーが搭載されており、このバッテリーは図示しないバッテリー電圧管理部により、残量が管理されている。このバッテリー残量が第１の所定値を下回ると、メモリへの書き込みや読み出しが不安定になりがちであるため、第１の所定値以下になると限られた一部のワーカー以外は起動を受け付けなくなる。例えば、カメラ起動などは受け付けないが、着信があれば着信通知は行う、といった状態になる。さらに、残量が少なくなり、第１の所定値よりも低い第２の所定値にまで落ち込むと、バッテリー切れをユーザインタフェース上で通知した後に、全てのワーカーを強制終了させる。ここでいう、バッテリー電圧管理部からの、残量警告のイベントに対応するワーカーへの入力を受け付けたイベントジャッジ部が特例判定を行うことになる。

ここで、ＮＵＬＬとならないワーカーとして、上述した残量警告のイベントのような特殊な条件でのワーカーが挙げられる。第１の所定値に基づく残量警告イベントに対応するワーカーならば、ワーカー別特例競合テーブルのワーカー起動にはカメラ起動中やスケジュールアラーム等の条件が記述され、これに基づく特例競合処理関数には許可を応答する関数が記述される。

さらに、ワーカー別特例競合テーブル９２のワーカー終了として、着信中が記述され、これは特例競合処理関数９３として保留を返す関数が設定される。その他、許可、保留もしくは拒否のいずれかが記述されることとなる。また、第２の所定値に基づく残量警告ならば、ほぼ全てのアプリケーションプログラムに基づくワーカーが、ワーカー起動かつ許可（つまり、第２の所定値に基づく残量警告ならば即実行）として記述されることとなる。

第２の所定値に基づく残量警告がイベントとして発生した場合として、特例競合管理テーブル９１には、たいていがワーカー起動かつ許可として記述されているが、条件付許可として「通信中」も記述されている。つまり、バッテリー残量が低下し、通信が維持できなくなる危険性が生じると前述の警告がイベントとして発生し、ほぼ全てのワーカーを終了させる。しかし、特例として、通信中の場合には、通信を終了させる前に、必ず課金に関する通話時間や獲得パケット数を計算し、これをメモリに格納もしくは通信網に送信し終わってから通信を終了するという、条件付き許可が記述されている。

一方、ＮＵＬＬとなるワーカーは、上述の特殊な競合判定ではなく、一般的なワーカーに基づくものに記述される場合と、個別の競合条件テーブル９０に設定されているため特例競合管理テーブル９１においてはＮＵＬＬと設定されている場合がある。

また、バッテリー残量以外の特例競合の判定を伴う例として、通話中に通話を維持した状態で必要に迫られＥメールを起動する場合がある。Ｅメールの起動によりイベントとして「Ｅメール展開要求」が発生し、イベントを受信したイベントジャッジ部は特例競合管理テーブル９１を参照する。このとき、「Ｅメール展開要求」のイベントに特例競合条件として登録されているのは上述した「バッテリー残量低（第２所定値）」だけであるとする。バッテリー残量に余裕がある場合には、この条件には該当しないため、次に競合テーブルが参照され、通話中であってもＥメールの展開要求は許可であるため、Ｅメールを展開しＥメールを表示する。表示されたＥメールのテキスト中に０で始まる１１桁の数字列が含まれていると、これを電話番号であると自動認識し、その数字列の表示色を変更するようになっている。

上記の状態に継続して、その数字列がユーザが操作するカーソルによって選択され、決定キーが押下されると、その番号に発呼する「Ｐｈｏｎｅｔｏ機能」が起動し、発呼要求のイベントが発生する。このイベントについてもイベントジャッジ部は特例競合管理テーブル９１が設定されており、発呼要求のイベントには、拒否条件として「通話中」が記述されているとする。この時、発呼要求のイベントは「通信中」の条件に従って、新たな発呼をすることができず、エラーの表示を行う。

ただし、３者通話契約を事前に通信事業者との間でなされていたならば、「許可」が記述されており、発呼することができる。ただし、この「許可」には３者通話という条件の関数が指定されており、この条件において許可される。このとき、特例競合管理テーブル９１の「発呼要求イベント」発生時の「通話中」の場合の条件として「拒否」から「条件付許可」に書き換えられる。この書き換えはローダーマシンにて行っても良いし、特例競合管理テーブル９１としてまとめられているため書き換えが容易になっているために、無線通信で書き換えを基地局経由で行っても良い。

また、さらに、特例として設定する事例として、外部インタフェースの接続有無なども挙げられる。携帯電話端末装置は通常１０〜１８芯程度のコネクタを有しており、内部のメモリの書き換えや読み出し、または携帯電話端末装置をモデムとして使用するためにパーソナルコンピュータが接続されるときに外部インタフェースとして使用される。この外部インタフェースの使用時にはたいていの操作を「拒否」するように構成したいときにも特例競合条件テーブル９１は有効となる。つまり、外部インタフェース使用中か否かの判断テーブルを作成するだけでよく、他の多くの競合条件テーブル９０については手を加えることもなく競合判定処理が行えるからである。

こういった特例の条件は、メーカ側としてはモデルチェンジしても変更するような仕様でないため、設計変更する際に変更箇所が少なくてすむため非常に有効な手段である。つまり、特例競合条件テーブル９１にて許可が指定されるイベントは、複数のイベントに重複して発生しうる条件が記述されることが多くなる。

図１２は、イベントジャッジ部２０におけるワーカー起動時の処理を示したフローチャートである。
イベントジャッジ部２０は、上述した競合条件テーブル９０に従って判定処理を行う。
同図におけるイベントジャッジ部２０ａは、ワーカー起動のイベントをアプリケーション管理部１０から受信したイベントジャッジ部２０ａであり後述する競合状態により停止し、終了させられるワーカーに対応するイベントジャッジ部２０ｂと区別するために符号を別にしている。

最初にアプリケーション管理部１０のイベント受信部１０ａからワーカー起動のイベントを受信し、上述した特例競合管理テーブル９１に従って特例競合条件判定処理を実行する（ステップＳ１２−１）。特例競合条件判定処理の結果を判定し（ステップＳ１２−２）、一致する条件がある場合、即ち競合条件有りとなった場合にはステップＳ１２−４の競合判定結果の処理に進む。一致する条件が無い場合、即ち特例競合管理テーブルにＮＵＬＬと記述されているなど、競合条件無しとなった場合には、競合条件テーブル９０に設定されている条件に従って競合条件判定処理を行う（ステップＳ１２−３）。

そして、競合条件判定処理の結果を判定し（ステップＳ１２−４）、拒否の場合は競合判定結果拒否をアプリケーション管理部１０に送信する。判定結果が保留の場合には後述するワーカー保留処理を実行すると共に、アプリケーション復帰制御部１０ｄに保留ワーカー追加指示を送信する。アプリケーション復帰制御部１０ｄは復帰レベルテーブル８０にそのワーカーを追加する（ステップＳ１２−５）。

許可の場合にはワーカーを起動するために競合しているワーカーを終了する必要があり、競合ワーカー終了制御を実行する。その際、アプリケーション終了制御部１０ｃに競合する起動中のワーカーを停止し、終了させるワーカー終了を指示する（ステップＳ１２−６）。起動中のワーカーを終了させた後、起動要求のあったワーカーを起動すると共に、アプリケーション終了制御部１０ｃにワーカー起動を指示する（ステップＳ１２−７）。

ワーカーの起動または終了を行ったアプリケーション終了制御部１０ｃはワーカー起動またはワーカー終了の処理を行って、アプリケーション管理部１０にワーカー起動またはワーカー終了を通知する。
イベントジャッジ部２０ａは、競合判定の結果が許可もしくは保留の場合もアプリケーション管理部１０に競合判定結果許可もしくは競合判定結果保留の情報を送信する。拒否、保留、許可、ワーカー起動及びワーカー終了を受信したアプリケーション管理部１０は、ワーカーの起動及び終了をＯＳに対して指示し、起動中のワーカーが終了し、起動を要求されたワーカーが起動する。

図１３は、図１２において競合により停止し、終了させるワーカーが存在した場合に、当該ワーカーに対応するイベントジャッジ部２０ｂが実行する処理を示したフローチャートである。
同図においてワーカー終了のイベントは図１２のイベントジャッジ部２０ａの起動中ワーカー終了の要求に基づいてアプリケーション管理部１０が送信したものである。ワーカー終了のイベントを受信したイベントジャッジ部２０ｂは、特例競合管理テーブル９１に従って特例競合条件判定処理を実行する（ステップＳ１３−１）。

特例競合条件判定処理の結果を判定し（ステップＳ１３−２）、一致する条件がある場合、即ち競合条件有りとなった場合にはステップＳ１３−４の競合判定結果の処理に進む。一致する条件が無い場合、即ち競合条件無しとなった場合には、競合条件テーブル９０に設定されている条件に従って競合条件判定処理を行う（ステップＳ１３−３）。

そして、競合条件判定処理の結果を判定する（ステップＳ１３−４）。競合判定の結果が、拒否もしくは保留の場合はその結果をアプリケーション管理部１０に送信する。結果が許可の場合にはワーカー終了処理を行う。その際、アプリケーション終了制御部１０ｃに当該ワーカー終了を指示する。また、ワーカーの終了を行ったアプリケーション終了制御部１０ｃはワーカー終了をアプリケーション管理部１０に送信する（ステップＳ１３−５）。ワーカー終了を受信したアプリケーション終了制御部１０ｃは、ワーカー終了の処理を行いアプリケーション管理部１０にワーカー終了を通知する。アプリケーション管理部１０は当該ワーカーの終了をＯＳに対して指示する。

図１４は、図１２の処理において、競合判定の結果、保留されたワーカー及び、起動中に停止し、終了させられたワーカーを復帰させる場合のイベントジャッジ部２０ａにおける処理のフローチャートである。
起動中のワーカーが強制的ではなく正常に終了すると、その旨を受信したアプリケーション管理部１０が復帰レベルテーブル８０から復帰させるワーカーを読み出し、そのワーカーのイベントジャッジ部２０ｃにワーカー起動を送信する。

最初にワーカー起動のイベントを受信したイベントジャッジ部２０ａは、特例競合管理テーブル９１に従って特例競合条件判定処理を実行する（ステップＳ１４−１）。特例競合条件判定処理の結果を判定し（ステップＳ１４−２）、一致する条件がある場合、即ち競合条件有りとなった場合にはステップＳ１３−４の競合判定結果の処理に進む。一致する条件が無い場合、即ち競合条件無しとなった場合には、競合条件テーブル９０に設定されている条件に従って競合条件判定処理を行う（ステップＳ１４−３）。

そして、競合条件判定処理の結果を判定する（ステップＳ１４−４）。判定結果が許可の場合には競合ワーカー終了制御の処理を行い、競合しているワーカーを終了させるためアプリケーション終了制御部１０ｃに終了を指示し、許可の結果をアプリケーション復帰制御部１０ｄに送信する（ステップＳ１４−５）。

判定結果が、拒否または保留の場合はその結果をアプリケーション復帰制御部１０ｄに送信する。拒否を受信したアプリケーション復帰制御部１０ｄは該当するワーカーを復帰レベルテーブル８０から削除する。保留を受信した場合には、再び復帰レベルテーブル８０に登録する。許可を受信した場合には、復帰レベルテーブル８０に記憶している当該ワーカーを読み出してアプリケーション管理部１０に当該ワーカーへの参照情報を含んだワーカー起動を送信する。競合するワーカーの終了指示を受信したアプリケーション終了制御部１０ｃは、ワーカー終了の処理を行って、ワーカー終了をアプリケーション管理部１０に送信する。

図１５から図１９を参照して上述したアプリケーション終了制御部１０ｃが実行するワーカーの起動及び終了の処理について説明する。これらに基づき、復帰レベルテーブルへの書き込み、読み出し、削除、さらに強制終了させる場合などにおいてイベントジャッジ部は親ワーカーと子ワーカーとを共に取り扱う。

図１５は、ワーカー間の親子関係を記憶している子チェーンテーブル８１を示したものである。あるワーカーを終了させるとそれに従属するワーカーも終了させるなどの連鎖した終了処理を制御するためのテーブルである。
同図では、基準となるルートから起動されたワーカーをリンクさせていくことで親子関係が生じることを示している。起動するワーカーを子とするかどうかは、動作結果を期待するワーカーなのか、自身を終了したとき一緒に終了させたいワーカーなのか、または、他ワーカーから引用されて起動されているワーカーなのか等を携帯電話端末装置の仕様に基づいて決定する必要がある。

図１６は、従属関係が親子関係無しの場合を示した図であり、ワーカーＣがルートから直接リンクされる。
図１７は、従属関係が親子関係有りの場合を示した図であり、ワーカーＡとワーカーＤが親子関係となっている。ワーカーＤがユーザ操作によって起動したものである場合には、ワーカーＡが終了してもリンクされているワーカーＤは終了せずに親がリンクしていた場所、即ちルートにリンクする。一方、ワーカーＤがワーカーＡから引用されて起動したものである場合には、ワーカーＡが終了するとワーカーＤも終了する。

図１８は、子のワーカーＤが終了した場合の処理を示した図である。アプリケーション管理部１０からの要求により子のワーカーＤが終了すると、子のワーカーＤは親のワーカーＡに終了通知を送信する。終了通知を受信した親のワーカーＡは子ワーカーＤの情報を削除する等の処理を行う。

図１９は、アプリケーション終了制御部１０ｃの処理を示したフローチャートである。イベントジャッジ部２０よりワーカー起動を受信し、起動を要求したワーカーの子であるか否かを判定する（ステップＳ１９−１）。起動を要求したワーカーの子の場合には、子チェーンテーブル８０ｄに起動を要求したワーカーの子としてリンクする（ステップＳ１９−２）。起動元の子で無い場合には子チェーンテーブル８１においてルートにリンクする（ステップＳ１９−３）。

次に、動作中（＝アクティブ）ワーカーが有るか否かを判定する（ステップＳ１９−４）。動作中のワーカーが有る場合には、ワーカー追加指示をアプリケーション復帰制御部１０ｄに送信して復帰レベルテーブル８０に動作中のワーカーを記憶させ、アプリケーション管理部１０にワーカー起動を送信する。また、動作中のワーカーが無い場合にもアプリケーション管理部１０にワーカー起動を送信する。この処理によって、競合によって起動中から保留されたワーカーを復帰レベルテーブルに記憶する。
ワーカー終了を受信した場合には、子チェーンテーブル８１から終了要求のあったワーカーを削除してワーカー終了をアプリケーション管理部１０に送信する。

次に、図２０から図２５を参照して、図６で取り上げた復帰レベルテーブル８０へのワーカーの追加手段について説明する。
復帰レベルテーブル８０がワーカーを追加する場合としては、動作中であったワーカーが保留状態になる場合、または、上記競合判定において起動を保留された場合がある。
復帰レベルテーブルに対する制御としては、復帰レベルテーブル８０にワーカーを追加する制御、起動を保留されている親子関係のある保留ワーカーにリンクする制御等がある。

図２０に示す復帰レベルテーブルにワーカーを追加する処理は、動作中のワーカーが、ユーザ操作によって待ち受けアプリケーションが起動したワーカーである場合と、電話機能アプリケーション及びアラームなどの割り込みワーカーである場合に発生する。つまり、親子関係を持たず、上記したルートに直接リンクするワーカーの場合に復帰レベルテーブルに直接積み上げられることになる。

図２１に示す保留ワーカーに動作中のワーカーをリンクする処理は、動作中のワーカーが、待ち受けアプリケーション以外のワーカーからのユーザ操作にワーカー起動だった場合に発生する。この場合は、上述した親子関係をもつワーカーにおいて、子のワーカーが動作中であり、親ワーカーが保留中の場合に発生することになる。

図２２は、他のワーカーからリンクされているワーカーが終了した場合の処理を示した図である。同図において保留ワーカー（２）が終了すると、終了したワーカー（２）の子のワーカーである（３）が（１）にリンクすることになる。例えば、カメラに関するワーカーについて考え、用法を示す。この場合、親となるのは「カメラ起動中」ワーカーである。さらに、子ワーカーとなるのが、「セルフタイマー」や「ズームアップ」である。図２２に置き換えると、（１）がカメラ起動中、（２）がセルフタイマー、（３）ズームアップとなる。仕様にもよるが、例えば、これら（１）から（３）が起動している状態で、さらに目覚ましアラーム起動のワーカーが入ってくるとイベントジャッジ部はオペレーション実効性魚部の時にアプリケーション復帰管理部にて、カメラ関係のワーカーの保留要求がなされる。

担当のイベントジャッジ部では、これら（１）から（３）について図２２の左図に示すように親子関係を対応付けたまま復帰レベルテーブルに積み上げられる。そして目覚ましアラームの処理が完了したとき、特に（２）のセルフタイマーについてはタイムカウントに間が空いてしまい、セルフタイマーとしては使い物にならなくなってしまう場合がある。その場合には、これを削除し（３）のズームアップを繰り上げて右図のように（２）として積み上げ直し、この積み上げ直し後の復帰レベルテーブルに従って、カメラに関するアプリケーションを復帰させる。

図２３は、ワーカー起動を受信した場合のアプリケーション復帰制御部１０ｄの内部処理を示したフローチャートである。同図は、アプリケーション終了制御部１０ｃがイベントジャッジ部２０からワーカー起動の指示を受信し、既に動作中のワーカーがある場合に、動作中のワーカーを保留するためにワーカー追加指示をアプリケーション復帰制御部１０ｄに送信した場合を示している。ワーカー追加指示を受信したアプリケーション復帰制御部１０ｄは、ワーカー追加指示に含まれている当該ワーカーが復帰するための情報を設定されているレベルに合わせて復帰レベルテーブルに追加して処理を終了する。

図２４は、起動したワーカーが、競合判定の結果により保留ワーカーとなった場合を示した図であり、新たに発生した保留ワーカーを設定されているレベルに合わせて復帰レベルテーブルに追加する。

図２５は、図２４の場合におけるアプリケーション復帰制御部１０ｄの内部処理を示したフローチャートである。
競合判定結果が保留の場合にイベントジャッジ部２０はアプリケーション復帰制御部１０ｄに保留ワーカー追加指示を送信する。保留ワーカー追加を受信したアプリケーション復帰制御部１０ｄは、保留ワーカー追加指示に含まれている復帰のための情報及びレベルに合わせてワーカーを復帰レベルテーブルに追加して処理を終了する。

以上のように、アプリケーション管理部１０は、携帯電話端末装置上で１つしかアプリケーション３０を起動しないように制御している。そのため、ＯＳ上では１つのアプリケーションプログラムしか起動していないことになり、優先処理などの複雑な復帰処理ができないＯＳライブラリ１のスタック記憶領域を利用する必要がなくなる。それによって、アプリケーションプログラムの競合判定をアプリケーション管理部１０だけで制御することが可能となり、機能追加等もＯＳを変更する必要なくアプリケーション側に閉じて実施することが可能となる。

そのため、予め、オートパワーオフの復帰レベルをスケジュールアラームの復帰レベルよりも低く設定してあれば、着信中にスケジュールアラームのイベントが通知され、さらにオートパワーオフのイベントが通知された２つのイベントが保留された場合でも、着信の終了後に先にオートパワーオフが復帰し、スケジュールアラームが放置され電源オフしてしまうようなことがなくなる。さらに、復帰レベルを任意に設定可能にすることにより、携帯電話端末装置上のアプリケーションプログラムの任意の順序での復帰制御を可能としている。それによって、例えば、着信中などの割り込み処理、Ｅメール着信、アラームの順でプログラムが保留にされても、最初にアラームを復帰させてその後Ｅメール着信の処理を行わせるなどの制御が可能となる。

上述の携帯電話端末装置は内部に、コンピュータシステムを有している。そして、上述した携帯電話端末装置の処理過程は、プログラムの形式でコンピュータ読み取り可能な記
録媒体に記憶されており、このプログラムをコンピュータが読み出して実行すること
によって、上記処理が行われる。ここでコンピュータ読み取り可能な記録媒体とは、
磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等を
いう。また、このコンピュータプログラムを通信回線によってコンピュータに配信
し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。

本発明の一実施形態による携帯電話端末装置におけるアプリケーションプログラム管理に関わる部分の構成を示すブロック図である。従来技術と同実施形態におけるアプリケーション管理に関わる機能ブロックの構成の違いを示した図である。同実施形態におけるアプリケーションプログラム復帰時の優先処理の具体例を示した図である。同実施形態におけるアプリケーション管理部がイベント制御のための情報を記憶するテーブル構成図である。同実施形態における復帰レベルテーブルを示した図である。同実施形態における子チェーンテーブルを示した図である。同実施形態におけるアプリケーションプログラムの構成を示したブロック図である。同実施形態におけるアプリケーション管理部及びイベントジャッジ部の競合判定制御における関係図である。同実施形態における競合条件テーブルの構成図である。同実施形態における競合条件テーブルの具体的設定形態を示す図である。同実施形態における特例措置の手段を示した図である。同実施形態におけるイベントジャッジ部のワーカー起動の処理を示したフローチャートである。同実施形態におけるイベントジャッジ部の競合発生によるワーカー終了の処理を示したフローチャートである。同実施形態におけるイベントジャッジ部の保留ワーカー復帰の処理を示したフローチャートである。同実施形態におけるワーカー間の親子関係を記憶している子チェーンテーブルを示した図である。同実施形態におけるワーカー間の従属関係が親子関係無しの場合を示した図である。同実施形態におけるワーカー間の従属関係が親子関係有りの場合を示した図である。同実施形態における子が終了時の処理を示した図である。同実施形態におけるアプリケーション終了制御部の処理を示したフローチャートである。同実施形態における復帰レベルテーブルにワーカーを追加する処理を示した図である。同実施形態における保留ワーカーに動作中のワーカーをリンクする処理を示した図である。同実施形態における他のワーカーからリンクされているワーカーを終了させた場合の処理を示した図である。同実施形態におけるアプリケーション復帰制御部の処理を示したフローチャート（その１）である。同実施形態における起動中ワーカーが競合判定の結果により保留ワーカーとなった場合を示した図である。同実施形態におけるアプリケーション復帰制御部の処理を示したフローチャート（その２）である。

符号の説明

１０アプリケーション管理部
３０（３０ａ〜３０ｃ）アプリケーション
７１アプリケーション状態テーブル

Claims

個別の処理を行うワーカー処理を複数含むアプリケーションプログラムを複数有する携帯電話端末装置であって、
イベント情報を受信し、当該イベント情報に対応する処理を行うワーカー処理を有するアプリケーションプログラムを複数のプログラムの中から特定するとともに、当該特定したアプリケーションプログラムを含む前記複数のアプリケーションプログラムの動作を管理するプログラム管理手段と、
前記プログラム管理手段により更新され、前記複数のアプリケーションプログラムの動作状態を記憶する動作状態記憶部と、
前記複数のアプリケーションプログラムごとに関連付けて設けられ、自己の関連付けられたアプリケーションプログラムに含まれるワーカー処理を実行可能か否かを、予め設定されている所定の競合条件に基づいて判断する複数のイベントジャッジ手段と、
を備え、
前記プログラム管理手段は、前記イベント情報の受信に基づいて特定された所定のワーカー処理を実行するよう、前記複数のイベントジャッジ手段のうち、前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段に対して要求し、
前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段は、前記所定の競合条件に基づいて、実行要求された前記所定のワーカー処理の実行可否を判断するとともに、
前記所定のワーカー処理を実行可能と判断される場合には、前記プログラム管理手段は、前記動作状態記憶部を参照して、動作中として記憶されている他のアプリケーションプログラムを停止するとともに、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行し、
前記所定のワーカー処理を実行不能と判断される場合には、前記プログラム管理手段は、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行せず、前記動作状態記憶部にて動作中として記憶されている他のアプリケーションプログラムの動作を維持する
ことを特徴とする携帯電話端末装置。
前記プログラム管理手段は、前記動作中のプログラムを停止させる際に、前記プログラムを復帰させるための復帰情報を所定の記憶領域に記憶し、前記動作中のプログラムが終了した際に、前記復帰情報に基づいて前記プログラムを復帰させることを特徴とする請求項１に記載の携帯電話端末装置。
個別の処理を行うワーカー処理を複数含むアプリケーションプログラムを複数有する携帯電話端末装置のプログラム管理方法であって、
イベント情報を受信し、当該イベント情報に対応する処理を行うワーカー処理を有するアプリケーションプログラムを複数のプログラムの中から特定するとともに、当該特定したアプリケーションプログラムを含む前記複数のアプリケーションプログラムの動作を管理するプログラム管理手段と、
前記プログラム管理手段により更新され、前記複数のアプリケーションプログラムの動作状態を記憶する動作状態記憶部と、
前記複数のアプリケーションプログラムごとに関連付けて設けられ、自己の関連付けられたアプリケーションプログラムに含まれるワーカー処理を実行可能か否かを、予め設定されている所定の競合条件に基づいて判断する複数のイベントジャッジ手段と、
を備え、
前記プログラム管理手段が、前記イベント情報の受信に基づいて特定された所定のワーカー処理を実行するよう、前記複数のイベントジャッジ手段のうち、前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段に対して要求する過程と、
前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段が、前記所定の競合条件に基づいて、実行要求された前記所定のワーカー処理の実行可否を判断するとともに、
前記所定のワーカー処理を実行可能と判断される場合には、前記プログラム管理手段が、前記動作状態記憶部を参照して、動作中として記憶されている他のアプリケーションプログラムを停止するとともに、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行し、
前記所定のワーカー処理を実行不能と判断される場合には、前記プログラム管理手段が、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行せず、前記動作状態記憶部にて動作中として記憶されている他のアプリケーションプログラムの動作を維持する過程と、
を備えたことを特徴とするプログラム管理方法。
個別の処理を行うワーカー処理を複数含むアプリケーションプログラムを複数有し、
イベント情報を受信し、当該イベント情報に対応する処理を行うワーカー処理を有するアプリケーションプログラムを複数のプログラムの中から特定するとともに、当該特定したアプリケーションプログラムを含む前記複数のアプリケーションプログラムの動作を管理するプログラム管理手段と、
前記プログラム管理手段により更新され、前記複数のアプリケーションプログラムの動作状態を記憶する動作状態記憶部と、
前記複数のアプリケーションプログラムごとに関連付けて設けられ、自己の関連付けられたアプリケーションプログラムに含まれるワーカー処理を実行可能か否かを、予め設定されている所定の競合条件に基づいて判断する複数のイベントジャッジ手段と、
を備える携帯電話端末装置のコンピュータに、
前記プログラム管理手段が、前記イベント情報の受信に基づいて特定された所定のワーカー処理を実行するよう、前記複数のイベントジャッジ手段のうち、前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段に対して要求する手順、
前記所定のアプリケーションプログラムに関連付けられたイベントジャッジ手段が、前記所定の競合条件に基づいて、実行要求された前記所定のワーカー処理の実行可否を判断するとともに、
前記所定のワーカー処理を実行可能と判断される場合には、前記プログラム管理手段は、前記動作状態記憶部を参照して、動作中として記憶されている他のアプリケーションプログラムを停止するとともに、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行し、
前記所定のワーカー処理を実行不能と判断される場合には、前記プログラム管理手段は、前記所定のワーカー処理を含む所定のアプリケーションプログラムを実行せず、前記動作状態記憶部にて動作中として記憶されている他のアプリケーションプログラムの動作を維持する手順、
を実行させるコンピュータプログラム。