JP5397010B2 - 端末装置 - Google Patents

Description

本発明は、端末装置に関する。

近年、会話に使用される情報を記憶可能な携帯電話端末がある。会話に使用される情報は、例えば、スケジュール等の日時や時刻情報、品物の価格や数量等の数値情報である。上述した会話に使用される情報は、主にビジネスでの会話に使用される。会話に使用される情報は、携帯電話端末の入力装置を用いた入力や、そのような情報を有する電子メールの受信によって携帯電話端末に入力され、携帯電話端末内の記録媒体上に記憶される。記憶された情報は、情報を閲覧するためのアプリケーションプログラムの実行を介して携帯電話端末の表示装置上に呼び出すことができる。

携帯電話端末は、通常、専用のオペレーティングシステム（以下、「ＯＳ」と表記）と１以上のアプリケーションプログラム（以下、「アプリケーション」と表記）とが予め組み込まれている。１以上のアプリケーションは、上記した会話に使用される情報の呼び出し処理を実行するアプリケーションを含む。

ＯＳは、携帯電話端末の通話中（in service）における音声通話処理を行う。通話中において、ＯＳは、アプリケーションの実行又は処理の動作を制限する。これによって、ＯＳによる音声通話処理がアプリケーションの動作負荷の影響を受けることが抑えられ、音声通話の品質が維持される。

特開２００５−１２１５３１号公報 特開２００６−２５２２１８号公報 特開２００２−２６１９１９号公報

近年、汎用ＯＳで通話処理を行う携帯端末がある。例えば、スマートフォンと呼ばれる、携帯電話，ＰＨＳ（Personal Handy Phone），又は無線ＩＰ電話とＰＤＡ（Personal Digital Assistants）とを組み合わせた携帯端末である。汎用ＯＳで音声通話処理を行う
携帯端末は、通常、ユーザが自由にアプリケーションを追加可能な仕様を有する。また、汎用ＯＳで音声通話処理を行う携帯端末では、通常、汎用ＯＳによる音声通話中のアプリケーションの動作制限処理が行われない。従って、ユーザは、通話中であっても携帯端末の操作によってアプリケーションを動作させることができる。アプリケーションの動作によって、ユーザは、会話に使用する情報を閲覧し、会話に利用することができる。

しかしながら、通話中にアプリケーションが動作すると、携帯端末のリソースがアプリケーション動作のために消費されるので、汎用ＯＳによる円滑な音声通話処理が阻害されるおそれがあった。円滑な音声通話処理が阻害されると、音声通話の品質が劣化したり、音声通話の切断が起こったりするおそれがあった。

本発明の態様の一つは、通話中のアプリケーションの起動による通話品質劣化を通話相手に報知可能な端末装置を提供することを目的とする。

本発明の態様の一つは、携帯端末であって、通話相手との通話処理を行う通話処理部と、
アプリケーションプログラムの実行を制御するアプリケーション制御部と、
前記通話処理部による通話処理中において前記アプリケーションプログラムの起動が前記実行処理部に指示された場合に、前記アプリケーションの起動によって通話品質が劣化するか否かを判定する判定部と、
前記通話品質が劣化すると判定される場合に、通話品質劣化を予告するための予告メッセージを前記通話相手に送信する送信部とを含む。

本発明の他の態様の一つは、上記した携帯端末による予告メッセージの送信方法である。また、本発明の他の態様の一つは、携帯端末として機能するコンピュータに上述した予告メッセージの送信のための処理を実行させるプログラム、或いは当該プログラムを記録したコンピュータ読み取り可能な記録媒体である。

本発明の一態様によれば、通話中のアプリケーションの起動による通話品質劣化を通話相手に報知することができる。

図１は、実施形態に係る携帯端末が適用される移動体通信システムの例を示す図である。 図２は、通話制御プログラムがＣＰＵによって実行されることによって実現される機能を模式的に示すブロック図である。 図３は、動作例１における、通話中のアプリケーション起動時における携帯端末の処理（通話制御プログラムの実行による処理）の例を示すフローチャートである。 図４Ａは、ＳＩＰメッセージのフォーマット例を示す。 図４Ｂは、会話制御メッセージのフォーマット例を示す。 図５Ａは、予告メッセージ受信時における、通話相手である携帯端末における処理を示すフローチャートである。 図５Ｂは、復旧メッセージ受信時における、通話相手である携帯端末の処理例を示すフローチャートである。 図６は、動作例２におけるアプリケーション起動時における携帯端末の処理例を示すフローチャートである。 図７は、動作例２における、通話相手である携帯端末の予告メッセージ受信時の処理例を示すフローチャートである。 図８は、負荷テーブルに対する情報の格納処理例を示すフローチャートである。

以下、図面を参照して本発明の実施形態について説明する。下記の実施形態の構成は例示であり、本発明は、実施形態の構成に限定されない。

＜移動体通信システム＞
図１は、実施形態に係る端末装置が適用される移動体通信システムの例を示す図である。図１において、移動体通信システムは、網側設備として、携帯電話網Ｎ１と、携帯電話網Ｎ１に接続された基地局Ｂ１及びＢ２と、ＩＰ（Internet Protocol）網Ｎ２と、ＩＰ
網Ｎ２に接続されたアクセスポイントＡ１及びＡ２とを備える。

図１には、端末装置の例示として、携帯型の無線端末装置（以下、「携帯端末」と称す
る）１０及び２０が図示されている。携帯端末１０は、携帯端末２０を通話相手として、基地局Ｂ１，携帯電話網Ｎ１及び基地局Ｂ２を介して通話、すなわち電話通信を行うことができる。また、携帯端末１０は、携帯端末２０を通話相手として、アクセスポイントＡ１，ＩＰ網Ｎ２及びアクセスポイントＡ２を介してＩＰ通信を行うことができる。ＩＰ網Ｎ２は、例えば、インターネットやイントラネットである。

＜携帯端末＞
携帯端末１０及び２０は、同じ構成を持つ。携帯端末１０を例として説明する。携帯端末１０は、携帯電話端末又はＰＨＳ端末としての機能と、無線ＬＡＮ端末機能を有するＰＤＡとしての機能との双方を有する。このような端末装置は、スマートフォンと呼ばれる。

携帯端末１０は、ＣＰＵ（中央演算処理装置）１，主記憶装置２，二次記憶装置３，入力装置４，出力装置５，ＲＦ(Radio Frequency)回路６，無線ＬＡＮ(Local Area Network)インタフェース（無線ＬＡＮ Ｉ／Ｆ）７を備える。

ＣＰＵ１，主記憶装置２，二次記憶装置３，入力装置４，出力装置５，ＲＦモジュール６，無線ＬＡＮインタフェース７は、バスＢＵ，図示しない入出力装置，インタフェース回路を介して相互に接続されている。

主記憶装置２は、データやプログラムを記録したＲＯＭ（Read Only Memory）と、ＣＰＵ１のワークエリアとして使用されるＲＡＭ（Random Access Memory：メモリと呼ばれる）とを備えている。

二次記憶装置３は、例えば、ＥＰＲＯＭ（Erasable Programmable ROM）やＨＤＤ（Hard Disc Drive）であり、ＣＰＵ１によって実行されるＯＳ８、及び複数のアプリケーション９のようなプログラムがインストールされている。また、二次記憶装置３は、ＯＳ８やアプリケーション９のようなプログラムが実行される際に使用されるデータを格納している。また、アプリケーション９の一つとして、ＳＩＰ（Session Initiation Protocol）
を用いたＩＰ電話機能を司るＶｏＩＰ（Voice over IP）アプリケーションを含む。

ここに、ＯＳ８は、アプリケーション９の管理及び動作制御を行う。また、ＯＳ８は、携帯端末１０が携帯電話端末として通話相手（例えば携帯端末２０）と音声通話を実施する場合における呼処理などを含む音声通話処理を行う。

これに対し、複数のアプリケーション９は、例えば、電子メールの送受信及び管理機能を司るメーラ、ユーザのスケジュールを管理するためのスケジューリングソフトウェアである。メーラによって送受信された電子メールや、スケジューラを用いて作成されたスケジュールデータは、二次記憶装置３の所定の記憶領域に格納される。

電子メールやスケジュールデータに含まれた情報は、出力装置５に含まれる表示装置の画面上に呼び出すことができ、ユーザは、表示された情報を会話、すなわち通話のための情報として利用することができる。

ＲＦ回路６は、携帯電話機能を用いた通話時に、携帯端末１０が在圏する通信エリアの基地局（図１では基地局Ｂ１）とアンテナ６Ａを介して無線通信を行い、通話に係る音声を送受信することができる。

無線ＬＡＮインタフェース７は、無線ＬＡＮ端末機能を用いたＩＰ通信時に、携帯端末１０が在圏する通信エリアのアクセスポイント（図１ではアクセスポイントＡ１）とアン
テナ７Ａを介して無線通信を行い、ＩＰ通信に係るデータ（パケット）を送受信することができる。

入力装置４は、ユーザがデータを入力するための複数のキー又はボタンと、ユーザが音声を入力するためのマイクロフォンとを備えている。出力装置５は、主記憶装置２や二次記憶装置３に格納されたデータ又は情報を表示するための表示装置と、携帯端末１０に入力又は受信された音声データに基づく音声を出力するためのスピーカとを備えている。

ＣＰＵ１は、主記憶装置２のＲＯＭに格納されたプログラム、二次記憶装置３に格納されたＯＳ８やアプリケーション９のようなプログラムを主記憶装置２のＲＡＭ（メモリ）にロードして実行する。プログラムの実行を通じて、ＣＰＵ１は、上述したような携帯電話端末としての機能と、ＰＤＡとしての機能とを実現する。すなわち、携帯端末は、携帯電話端末，ＰＨＳ端末，或いはＩＰ電話端末として機能し、通信相手と通話を行うことができる。

ＯＳ８は、汎用ＯＳである。ＯＳ８は、携帯電話機能の実現に係る音声通話処理を司る。すなわち、ＣＰＵ１がＯＳ８を実行することによって、音声通話処理を行う通話制御部としての機能が実現される。

また、携帯端末１０は、ＩＰ網Ｎ２から所望のアプリケーション９をダウンロードして二次記憶装置３にインストールすることができる。また、ＯＳ８は、音声通話処理中（通話中）において、アプリケーション９の起動、動作を制限しない。このため、ユーザが通話中に、或るアプリケーション９を起動して、閲覧を望む情報を表示装置上に呼び出し、その情報を参照しながら会話を継続する利用方法が考えられる。

しかしながら、ＯＳ８は、複数のアプリケーション９と、ＣＰＵ１，主記憶装置２のメモリ，ネットワークのようなシステムリソース（以下、単に「リソース」と表記）を共用する。このため、例えば、ＯＳ８の音声通話処理時にリソースの８０％が消費されると仮定すると、音声通話処理中に、上記した或るアプリケーション９が残りの２０％のリソースを消費すると、円滑な音声通話処理が阻害され、音切れのような通話品質への影響、すなわち通話品質の低下が生じる可能性がある。通話品質の低下が著しい場合には、会話の継続が困難となる。或いは、呼の切断が生じる可能性もある。

また、上記した或るアプリケーション９が定常状態では残りの２０％の範囲でリソースを消費する場合であっても、当該或るアプリケーション９の起動時において、２０％以上のリソースが消費されることが起こり得る。この場合には、当該或るアプリケーション９が起動してから定常状態に遷移するまでの間、通話品質に影響を及ぼす可能性があった。

実施形態における携帯端末１０は、上述したような問題に鑑み、通話中、すなわちＯＳ８による音声通話処理中に複数のアプリケーション９の一つが起動された場合に、携帯端末１０のリソース消費量を考慮して、通話品質劣化を予告する予告メッセージを通話相手に送信する。また、携帯端末１０は、上記した複数のアプリケーション９の一つが起動し、定常状態に遷移したと認められる状態になったときに、通話品質が復旧したことを示す復旧メッセージを通話相手に送信する。このような機能は、上述した複数のアプリケーション９の一つとしてインストールされた、通話制御プログラムがＣＰＵ１によって実行されることにより実現される。

図２は、アプリケーション９の一つである通話制御プログラムがＣＰＵ１によって実行されることによって実現される機能を模式的に示すブロック図である。図２に示すように、通話制御プログラムがＣＰＵ１によって実行されることで、音声通話処理部８０と、ア
プリケーション監視部８１と、アプリケーション起動制御部８２と、負荷制御部８３と、ＵＩ（User Interface）制御部８４と、メッセージ制御部８５とが実現される。さらに、負荷テーブル８６が作成される。負荷テーブル８６は、主記憶装置２のメモリ上、又は二次記憶装置３の記憶領域上に作成される。

負荷テーブル８６は、携帯端末１０にインストールされた複数のアプリケーション９の起動時に要求されるリソース使用率（負荷）を格納する。この負荷値は、例えば、ＣＰＵ１の使用率や、メモリの使用率、或いはＣＰＵ１の使用率とメモリの使用率の組み合わせから決定することができる。各アプリケーション９の負荷値は、予め実験等によって求めた値を静的に負荷テーブル８６に格納しておくことができる。或いは、負荷テーブル８６は、動的に作成することが可能である。動的な負荷テーブル８６の作成方法については後述する（図８）。

ここに、アプリケーション監視部８１は、各アプリケーション９の状態及び動作を監視する。アプリケーション起動制御部８２は、各アプリケーション９の起動処理を制御する。負荷制御部８３は、携帯端末１０におけるＣＰＵ１の使用率やメモリの使用率のような負荷（リソース使用率）を監視する。負荷制御部８３は、負荷テーブル８６に対する情報の読み出し／書き込み、及び後述する負荷判定などを行う。ＵＩ制御部８４は、出力装置４の表示装置に対する情報の表示制御や、出力装置４のスピーカに対する音声情報の出力制御を司る。メッセージ制御部８５は、上記した予告メッセージや復旧メッセージの作成・送信処理を司る。予告メッセージ及び復旧メッセージをまとめて指す場合には、“会話制御メッセージ”との表記を用いる。

なお、ＯＳ８やアプリケーション９を実行するＣＰＵ１が、本発明の一態様である端末装置の通話制御部、アプリケーション制御部、判定部に相当し、当該アプリケーション制御部は、アプリケーション起動制御部８２として機能するＣＰＵ１によって実現される。また、当該判定部は、負荷制御部８３として機能するＣＰＵ１によって実現される。

また、無線ＬＡＮインタフェース７が、本発明の一態様である端末装置の送信部及び受信部に相当し、送信部及び受信部としての無線ＬＡＮインタフェース７は、メッセージ制御部８５として機能するＣＰＵ１によって制御される。

また、出力装置５は、本発明の一態様である端末装置の問い合わせ部及び報知部に相当し、出力装置５は、ＵＩ制御部８４として機能するＣＰＵ１によって制御される。また、入力装置４は、回答入力をユーザが入力するために使用される。

＜動作例１＞
以下、携帯端末１０の動作例１について説明する。図１において、携帯端末１０のユーザ（ユーザＡと称する）が、携帯端末２０のユーザ（ユーザＢと称する）と携帯電話機能を用いた通話が行われていると仮定する。この場合、携帯端末１０と携帯端末２０との間に、携帯基地局Ｂ１，携帯電話網Ｎ１，基地局Ｂ２を介した呼が確立され、携帯端末１０と携帯端末２０との間で音声通話、すなわち、ユーザＡとユーザＢとの会話が行われる。

呼を確立するための処理、マイクロフォンから入力されたユーザＡ側の音声を符号化及び変調してアンテナ６Ａから基地局Ｂ１へ送信するための処理、アンテナ６Ａから受信された無線信号に対する復調処理及び復号処理を通じてユーザＢ側の音声をスピーカから出力するための処理のような、音声通話に係る様々な処理は、携帯端末１０及び２０のそれぞれにおけるＯＳ８がＣＰＵ１によって実行されることによって実現される通話制御部としての機能により実現される。なお、音声通話において、携帯端末１０及び２０は、２０ミリ秒毎に、約３００バイトの音声データを送信することができる。

このような音声通話中に、ユーザＡが携帯端末１０の入力装置２（キー又はボタン）を操作し、複数のアプリケーション９の一つ（アプリケーションＡ）の起動指示を入力したと仮定する。

図３は、通話中のアプリケーション起動時における携帯端末１０の処理（通話制御プログラムの実行による処理）の例を示すフローチャートである。図３のフローチャートにおいて、アプリケーション監視部８１（図２）が、アプリケーションＡの起動操作、すなわちアプリケーションＡの起動指示入力を検出する（図３：ステップＳ０１）。すると、アプリケーション監視部８１は、アプリケーションＡの起動命令をアプリケーション起動制御部８２に与える。

起動命令を受け取ったアプリケーション起動制御部８２は、アプリケーションＡの起動を負荷制御部８３に知らせる。アプリケーションＡの起動を知らされた負荷制御部８３は、負荷テーブル８６からアプリケーションＡのリソース使用率を読み出し、現在のリソース使用率に加算する（図３：ステップＳ０２）。

負荷制御部８３は、リソース不足による通話品質が劣化するリソース使用率の閾値（閾値１と称する）を予め有しており、加算値と閾値１とを比較する（図３：ステップＳ０３）。このとき、加算値が閾値１を下回る場合（Ｓ０３：ＮＯ）には、負荷制御部８３は、アプリケーション起動制御部８２にアプリケーション起動の許可を与え、アプリケーション起動制御部８２が、アプリケーションＡの起動処理を開始する（図３：ステップＳ０８）。その後、通話制御プログラムの実行による処理が終了する。

これに対し、加算値１が閾値１以上である場合（Ｓ０３：ＹＥＳ）には、予告メッセージの送信処理が行われる（図３：ステップＳ０４）。すなわち、負荷制御部８３は、現在のリソース使用率、すなわちアプリケーションＡの起動前のリソース使用率を負荷テーブル８６に書き込む。また、負荷制御部８３は、メッセージ制御部８５に対し、予告メッセージの送信指示を与える。メッセージ制御部８５は、予告メッセージを生成する。実施形態に係る携帯端末１０は、予告メッセージの伝達手法として、ＳＩＰを用いる。すなわち、予告メッセージを含むＳＩＰメッセージを生成し、携帯端末２０へ送信する。

図４Ａは、ＳＩＰメッセージのフォーマット例を示し、図４Ｂは、会話制御メッセージのフォーマット例を示す。図４Ａに示すように、ＳＩＰメッセージは、数十バイト程度の文字データであり、ＳＩＰメッセージフォーマットは、記載内容が制限されない拡張領域を有している。この拡張領域に会話制御メッセージ文が記載される。

図４Ｂに示す例では、会話制御メッセージは“メッセージ種別：ＳＩＰＵＲＩ リソース種別 状態種別 日付 時刻”の規定フォーマットを持つ。メッセージ種別として、“Alert-ON”，“Alert-OFF”，“Dialog-OPEN”，“Dialog-OK”，“Dialog-CLOSE”の５
タイプが用意されている。

メッセージ種別“Alert-ON”は、メッセージが“通話品質劣化の予告又は警告”メッセージであることを示す。メッセージ種別“Alert-OFF”は、メッセージが“通話品質劣化
の警告解除又は通話品質劣化状態からの復旧”であることを示す。メッセージ種別“Dialog-OPEN”は、メッセージが“ダイアログボックス（ウィンドウ）表示指示”メッセージ
であることを示す。メッセージ種別“Dialog-OK”は、表示されたダイアログボックスの
表示内容を許可するメッセージであることを示す。メッセージ種別“Dialog-CLOSE”は、ダイアログボックスの表示内容を拒否するメッセージであることを示す。

ＳＩＰＵＲＩは、ＳＩＰにおけるアドレス（ユーザ識別子）であるＵＲＩ（Uniform Resource Identifier）であり、ここでは、正式なＵＲＩからユーザ名部分のみが表記され
る。言い換えれば、アットマーク（＠）以降の部分が省略表記される。例えば、携帯端末１０（ユーザＡ）のＵＲＩは、“user1@domain.com”であり、拡張領域上のＳＩＰＵＲＩ表記として、“user1”と表記される。

リソース種別として、“ＣＰＵ”，“ＭＥＭＯＲＹ（主記憶装置）”，“ＳＴＯＲＡＧＥ（二次記憶装置）”，“ＯＴＨＥＲ（その他）”が用意されている。状態種別として、ＣＰＵの状態を示す“ＢＵＳＹ”及び“ＳＴＡＢＬＥ”と、メモリ又はストレージの状態を示す“ＦＵＬＬ”及び“ＦＲＥＥ”が用意されている。また、日付及び時刻は、タイムスタンプとして使用される。

例えば、図４Ａの拡張領域に示された“Alert-ON: user1 CPU BUSY 20081217 15:12:32”は、ＳＩＰメッセージが２００８年１２月１７日の１５時１２分３２秒に発行されたユーザ１（携帯端末１０）のＣＰＵ１がビジーであることを理由とする通話品質劣化の予告メッセージであることを示す。

動作例１では、メッセージ種別として、“Alert-ON”及び“Alert-OFF”が使用される
。また、リソース種別及び状態種別はオプションである。また、動作例１では、リソース使用率の例として、ＣＰＵ１の使用率（ＣＰＵ１の負荷）が適用されている。

図３のステップＳ０４において、図４Ａに示すような会話メッセージ“Alert-ON: user1 CPU BUSY 20081217 15:12:32”を含むＳＩＰメッセージ、すなわち予告メッセージが送信される。すなわち、メッセージ制御部８５は、無線ＬＡＮインタフェース７を制御して、ＳＩＰメッセージを無線通信によりアンテナ７ＡからアクセスポイントＡ１（図１）へ送信する。アクセスポイントＡ１に受信されたＳＩＰメッセージは、ＩＰ網Ｎ２，アクセスポイントＡ２を介して携帯端末２０に受信される。

図５Ａは、予告メッセージ受信時における、通話相手である携帯端末２０における処理を示すフローチャートである。携帯端末２０のアンテナ７Ａから受信されたＳＩＰメッセージは、無線ＬＡＮインタフェース７を介してＣＰＵ１（メッセージ制御部８５）に与えられる。

メッセージ制御部８５は、受信されたＳＩＰメッセージの解析を行い、当該ＳＩＰメッセージがメッセージ種別“Alert-ON”を有する予告メッセージであることを検知（判定）する（図５Ａ：ステップＳ２１）。すると、メッセージ制御部８５は、ＵＩ制御部８４に対し、“Alert-ON”、すなわち予告メッセージの報知を指示し、ＵＩ制御部８４が予告メッセージの報知処理を行う（図５Ａ：ステップＳ２２）。動作例１では、メッセージ制御部８５は、予告メッセージに応じた表示内容を出力装置５の表示装置に表示することを指示する。

ここに、二次記憶装置３の記憶領域には、会話制御メッセージのメッセージ種別に応じた表示画面データ（表示内容データ）が予め保持されている。ＵＩ制御部８４は、出力装置５の表示装置を制御して、メッセージ種別“Alert-ON”、すなわち予告メッセージに対応する表示画面データに基づく表示画面を表示装置上に表示させる。

表示内容は、例えば、通話品質劣化に伴い会話を控えることを促す文字メッセージ“しばらくお待ち下さい”である（図５Ａの画面Ｍ１参照）。或いは、文字メッセージは、通話品質がしばらくの間劣化することを予告する内容の文字メッセージを含むことができる。また、文字メッセージの表示に加えて、ＵＩ制御部８４は、出力装置５を制御し、スピ
ーカから警告音（アラーム）や、音声ガイダンスを出力することができる。アラーム音や音声ガイダンスの音声データは、予め二次記憶装置３の記憶領域に用意しておくことができる。

これによって、携帯端末２０のユーザＢは、表示装置に表示された文字メッセージや、アラーム及び／又は音声ガイダンスによって、通話品質が低下することを認識し、会話をしばらく控えることができる。

一方、携帯端末１０では、図３のステップＳ０４の処理後、メッセージ制御部８５によるＳＩＰメッセージ（予告メッセージ）の送信がアプリケーション起動制御部８２に通知される。すると、アプリケーション起動制御部８２は、アプリケーションＡの起動処理を開始する（図３：ステップＳ０５）。

アプリケーションＡの起動処理に伴って、携帯端末１０のリソースが消費され、起動処理が終了するまでの間、携帯端末１０のリソース使用率が一時的に上昇し、高負荷状態となる。負荷制御部８３は、アプリケーションＡの起動開始前から継続的にリソース使用率、すなわち負荷を監視し、リソース使用率がアプリケーションＡの起動処理が終了し、定常状態になった場合におけるリソース使用率となるのを待つ。

例えば、アプリケーションＡの起動処理の終了後の定常状態では、リソース使用率が起動処理前より５％程度上昇すると仮定する。この場合、負荷制御部８３は、リソース使用率が、アプリケーションＡの起動前より５％程度上昇した状態、すなわち定常状態になるのを待つ。

負荷制御部８３は、アプリケーションＡの定常状態におけるリソース使用率（上記例では５％）を予め保持している。このリソース使用率を負荷テーブル８６に格納したアプリケーション起動前のリソース使用率に加算し、アプリケーションＡが定常状態か否かを判断するための閾値（閾値２）を生成する。

例えば、アプリケーションＡの起動前におけるリソース使用率が６０％であり、アプリケーションＡの定常状態におけるリソース使用率が５％であると仮定すると、閾値２は、６５％、或いは６５％より数％高い値に設定される。

負荷制御部８３は、リソース使用率が閾値２以下か否かを判定し（図３：ステップＳ０６）、現在のリソース使用率が閾値２以下となった場合（Ｓ０６；ＹＥＳ）に、アプリケーションＡの起動処理が終了し、定常状態になったと判定する。なお、アプリケーションＡの定常状態におけるリソース使用率は、負荷テーブル８６に予め登録しておくこともできる。

リソース使用率が閾値２以下になると、復旧メッセージの送信処理が行われる（図３：ステップＳ０７）。すなわち、負荷制御部８３は、リソース使用率が閾値２以下になると、メッセージ制御部８５に対して、通話品質劣化状態からの復旧を示す復旧メッセージ（会話制御メッセージの一つ）の送信指示を与える。

メッセージ制御部８５は、復旧メッセージを生成する。すなわち、メッセージ制御部は、復旧メッセージ、例えば“Alert-OFF: user1 CPU STABLE 20081217 15:15:30 ”のような会話制御メッセージが拡張領域に格納されたＳＩＰメッセージを生成し、携帯端末２０へ送信する。

復旧メッセージを含むＳＩＰメッセージは、予告メッセージを含むＳＩＰメッセージ同
様の経路を通って携帯端末２０に到達する。携帯端末２０では、アンテナ７Ａで受信された復旧メッセージを含むＳＩＰメッセージは、無線ＬＡＮインタフェース７を介してＣＰＵ１（メッセージ制御部８５）に与えられる。

図５Ｂは、復旧メッセージ受信時における、通話相手である携帯端末２０の処理例を示すフローチャートである。図５Ｂにおいて、メッセージ制御部８５は、受信されたＳＩＰメッセージの解析を行い、当該ＳＩＰメッセージがメッセージ種別“Alert-OFF”を有す
る復旧メッセージであることを検知（判定）する（図５Ｂ：ステップＳ２３）。

すると、復旧メッセージの報知処理が行われる（図５Ｂ：ステップＳ２４）。すなわち、メッセージ制御部８５は、ＵＩ制御部８４に対し、“Alert-OFF”、すなわち復旧メッ
セージの報知を指示する。動作例１では、メッセージ制御部８５は、復旧メッセージに応じた表示内容を、出力装置５の表示装置に表示することを指示する。

すると、ＵＩ制御部８４は、復旧メッセージに対応する表示画面データを二次記憶装置３の記憶領域から読み出し、出力装置５の表示装置を制御して、復旧メッセージにの表示画面データに基づく表示画面を表示装置上に表示させる。

表示内容は、例えば、通話品質劣化状態から復旧により会話を再開することを促す文字メッセージ“お待たせしました”である（図５Ｂの画面Ｍ２参照）。或いは、文字メッセージは、通話品質が劣化状態から復旧したことを示す内容の文字メッセージを含むことができる。また、文字メッセージの表示に加えて、ＵＩ制御部８４は、出力装置５を制御し、スピーカから警告音（アラーム）や、音声ガイダンスを出力することができる。アラーム音や音声ガイダンスの音声データは、予め二次記憶装置３の記憶領域に用意しておくことができる。

これによって、携帯端末２０のユーザＢは、表示装置に表示された文字メッセージや、アラーム及び／又は音声ガイダンスによって、通話品質劣化状態からの復旧により、会話を再開できることを知ることができる。

＜動作例２＞
次に、携帯端末１０の動作例２について説明する。動作例２は、動作例１と共通点を含むので、主として相違点について説明する。図６は、動作例２における、通話中のアプリケーション起動時における携帯端末１０の処理例を示すフローチャートである。図７は、動作例２における、通話相手である携帯端末２０の予告メッセージ受信時の処理例を示すフローチャートである。

動作例２の前提、すなわち、図６に示す処理開始の条件は、動作例１と同じにすることができる。図６に示す処理は、携帯端末１０と携帯端末２０との音声通話中に、携帯端末１０において、例えばアプリケーションＡの起動操作が行われたことを契機として開始される。

図６におけるステップＳ０１からステップＳ０３における処理は、動作例１（図３）と同じであるので説明を省略する。ステップＳ０３において、現在のリソース使用率とアプリケーションＡのリソース使用率との加算値が閾値１未満である場合（Ｓ０３；ＮＯ）には、アプリケーションＡが起動され（図６：ステップＳ０８）、図６に示す処理が終了する。すなわち、携帯端末１０のユーザＡと携帯端末２０のユーザＢとは、アプリケーションＡの起動にかかわらず、良好な通話品質で会話を継続することができる。

これに対し、上記した加算値が閾値１以上である場合（Ｓ０３；ＹＥＳ）には、確認画
面表示処理が行われる（図６：ステップＳ１１）。すなわち、負荷制御部８３は、現在のリソース使用率、すなわちアプリケーションＡの起動前のリソース使用率を負荷テーブル８６に書き込む。また、負荷制御部８３は、ＵＩ制御部８４に対し、確認画面の表示指示を与える。

ＵＩ制御部８４は、二次記憶装置３の記憶領域に予め格納されている確認画面のデータを読み出し、出力装置５の表示装置を制御して、確認画面データに基づく確認画面Ｍ３（図６）を表示装置に表示させる。

確認画面Ｍ３は、図６に示すように、“アプリケーションを起動すると音声通話品質が劣化します。起動を続行しますか？ ＹＥＳ／ＮＯ”のような、通話品質の劣化を予告（警告）した上で、起動を続行するか否かの回答をユーザ（ユーザＡ）に促す文字メッセージを含むことができる。

携帯端末１０のユーザＡは、確認画面Ｍ３に対して、入力装置４の操作を通じて、問い合わせに対する回答（ＹＥＳ又はＮＯ）を入力することができる。また、確認画面Ｍ３には、回答入力時間の残り時間を示す時間表示を表示することができる。残り時間の表示により、ユーザＡの迅速な回答入力が促される。

ＵＩ制御部８４は、回答入力時間が尽きるまで、ユーザＡの回答入力を待つ。ユーザＡからの回答は、入力装置１を介してＵＩ制御部８４に与えられる。ＵＩ制御部８４は、回答結果が“ＹＥＳ”であるか“ＮＯ”であるかを判定することによって、ユーザＡが通話品質の劣化を許容する否かを判定する（図６：ステップＳ１２）。

このとき、回答結果が“ＮＯ”である場合（Ｓ１２；ＮＯ）には、ユーザＡが通話品質の劣化を許容せず、アプリケーションＡの起動処理の続行を望まないものとして、ＵＩ制御部８４は、アプリケーションＡの起動キャンセルをアプリケーション起動制御部８２に指示する。すると、アプリケーション起動制御部８２は、アプリケーションＡの起動をキャンセルする（図６：ステップＳ１５）。その後、図６の処理が終了する。これによって、アプリケーションＡは起動せず、ユーザＡは、アプリケーションＡの起動による通話品質の劣化なく、ユーザＢとの会話を継続することができる。

なお、回答入力時間が尽きるまでの間に、ユーザＡからの回答入力が無かった場合には、回答結果が“ＮＯ”である場合と同様に、ＵＩ制御部８４がアプリケーションＡの起動キャンセルをアプリケーション起動制御部８２に指示し、アプリケーション起動制御部８２がアプリケーションＡの起動をキャンセルする（図６：ステップＳ１５）。

これに対し、回答結果が“ＹＥＳ”である場合（Ｓ１２；ＹＥＳ）には、ユーザＡが通話品質の劣化を許容する、すなわち、アプリケーションＡの起動を望むと判定される。この場合には、予告メッセージの送信処理が実行される（図６：ステップＳ０４）。

すなわち、ＵＩ制御部８４は、メッセージ制御部８５に対し、予告メッセージの送信を指示する。メッセージ制御部８５は、予告メッセージを生成する。このとき、メッセージ制御部８５は、会話制御メッセージ（図４Ａ）として、メッセージ種別“Dialog-ON”を
含む予告メッセージを生成する。例えば、“Dialog-ON: user1 CPU Busy 20081217 16:12:32”のような会話制御メッセージを含むＳＩＰメッセージが生成され、携帯端末２０へ
送信される。

ＳＩＰメッセージ（予告メッセージ）は、動作例１で説明した通信経路と同様の経路を通じて携帯端末２０で受信される。図７は、動作例２における、通話相手である携帯端末
２０の予告メッセージ受信時の処理例を示すフローチャートである。

図７において、ＳＩＰメッセージは、動作例１と同様に、携帯端末２０のメッセージ制御部８５に与えられる。メッセージ制御部８５は、受信されたＳＩＰメッセージの解析を行い、当該ＳＩＰメッセージがメッセージ種別“Dialog-ON”を有する予告メッセージで
あることを検知（判定）する（図７：ステップＳ２１）。

すると、選択画面の表示処理が行われる（図７：ステップＳ３１）。すなわち、メッセージ制御部８５は、ＵＩ制御部８４に対し、メッセージ種別“Dialog-ON”に基づく選択
画面（ダイアログボックス）の表示指示を与える。ＵＩ制御部８４は、二次記憶装置３の記憶領域に予め格納されている選択画面のデータを読み出し、この選択画面のデータに基づく選択画面Ｍ４（図７参照）を、出力装置５の表示装置に表示させる。

選択画面Ｍ４には、例えば、図７に示すような“通話相手側で音声通話品質劣化イベントが発生します。許容しますか？ ＹＥＳ／ＮＯ”のような、通話品質劣化イベントの発生を予告するとともに、通話品質劣化イベントの発生を許容するか否かを問い合わせる文字メッセージが表示される。

選択画面Ｍ４には、また、回答入力時間の残り時間を示す時間表示が表示される。残り時間の表示により、ユーザＡの迅速な回答入力が促される。携帯端末２０のユーザＢは、選択画面Ｍ４に対して、入力装置４の操作を通じて、問い合わせに対する回答（ＹＥＳ又はＮＯ）を入力することができる。

ＵＩ制御部８４は、回答入力時間が尽きるまで、ユーザＢの回答入力を待つ（図７：ステップＳ３２）。ユーザＢからの回答は、入力装置１を介してＵＩ制御部８４に与えられる。ＵＩ制御部８４は、回答結果が“ＹＥＳ”であるか“ＮＯ”であるかを判定することによって、ユーザＢが通話品質の劣化を許容する否かを判定する（図７：ステップＳ３３）。

このとき、回答結果が“ＮＯ”である場合（Ｓ３３；ＮＯ）には、処理がステップＳ３４の回答結果返信処理に進む。ステップＳ３４では、ユーザＢが通話品質の劣化を許容せず、アプリケーションＡの起動処理の続行を望まないことを示す応答メッセージが生成される。すなわち、ＵＩ制御部８４は、回答結果が“ＮＯ”であることを示す応答メッセージの作成指示をメッセージ制御部８５に与える。メッセージ制御部８５は、応答メッセージを会話制御メッセージを含むＳＩＰメッセージのフォーマットを用いて作成する。

この場合、メッセージ制御部８５は、メッセージ種別“Dialog-CLOSE”を含む会話制御メッセージ（図４Ａ，図４Ｂ参照）が拡張領域に記載されたＳＩＰメッセージを生成し、携帯端末１０へ送信する。

なお、ユーザＢが回答入力時間内に回答を入力しなかった場合にも、ＵＩ制御部８４は、回答結果が“ＮＯ”であることを示す応答メッセージの作成指示をメッセージ制御部８５に与え、メッセージ制御部８５は、メッセージ種別“Dialog-CLOSE”を含む会話制御メッセージ（図４Ａ，図４Ｂ参照）が拡張領域に記載されたＳＩＰメッセージを生成し、携帯端末１０へ送信する。

“Dialog-CLOSE”を含む会話制御メッセージが拡張領域に記載されたＳＩＰメッセー
ジが携帯端末１０へ送信される。

これに対し、回答結果が“ＹＥＳ”である場合（Ｓ３３；ＹＥＳ）には、ＵＩ制御部３
４が予告メッセージの報知処理を行う（図７：ステップＳ２２）。これによって、動作例１と同様の手法で、通話品質劣化予告が報知される。例えば、図７に示すような、通話品質劣化に伴い会話を控えることを促す文字メッセージ“しばらくお待ち下さい”を含む画面Ｍ１が表示装置に表示される。或いは、画面表示に加えて、スピーカから警告音（アラーム）や音声ガイダンスが出力される。

これによって、携帯端末２０のユーザＢは、表示装置に表示された文字メッセージや、アラーム及び／又は音声ガイダンスによって、通話品質が低下することを認識し、会話をしばらく控えることができる。その後、処理がステップＳ３４に進む。

ステップＳ３４では、ＵＩ制御部８４は、ユーザＢが通話品質の劣化を許容することを示す応答メッセージが生成される。すなわち、ＵＩ制御部８４は、回答結果が“ＮＯ”であることを示す応答メッセージの作成指示をメッセージ制御部８５に与える。メッセージ制御部８５は、会話制御メッセージを含むＳＩＰメッセージのフォーマットを用いて応答メッセージを作成する。

この場合、メッセージ制御部８５は、メッセージ種別“Dialog-OK”を含む会話制御メ
ッセージ（図４Ａ，図４Ｂ参照）が拡張領域に記載されたＳＩＰメッセージ、すなわち応答メッセージを生成し、携帯端末１０へ送信する。その後、図７に示す携帯端末２０の処理が終了する。

ところで、携帯端末１０では、予告メッセージの送信が行われると（図６：ステップＳ０４）、所定期間、携帯端末２０からの応答メッセージの受信を待つ（図６：ステップＳ１３）。所定期間内に応答メッセージが受信された場合、及び応答メッセージの受信なく所定期間が経過した場合には、処理がステップＳ１４に進む。

応答メッセージとしてのＳＩＰメッセージは、携帯端末１０で受信されると、メッセージ制御部８５に与えられる。ステップＳ１４において、メッセージ制御部８５は、ＳＩＰメッセージの解析を行い、ＳＩＰメッセージの拡張領域に記載されたメッセージ種別が
“Dialog-CLOSE”であるか“Dialog-OK”であるかを判定する。

このとき、メッセージ種別が“Dialog-CLOSE”であれば、メッセージ制御部８５は、ユーザＢ（すなわち通話相手）が通話品質の劣化を許容しないと判定し（Ｓ１４；ＮＯ）、処理がステップＳ１５に進む。ステップＳ１５では、アプリケーションＡの起動がキャンセルされる。その後、図６における携帯端末１０の処理が終了する。なお、上記した所定期間内に応答メッセージが受信されなかった場合にも、メッセージ種別“Dialog-CLOSE”を含む応答メッセージが受信された場合と同様の処理が行われる。

これに対し、メッセージ種別が“Dialog-OK”であれば、メッセージ制御部８５は、ユ
ーザＢ（すなわち通話相手）が通話品質の劣化を許容すると判定し（Ｓ１４；ＹＥＳ）、処理が図６のステップＳ０５に進む。図６に示すステップＳ０５からステップＳ０７の処理は、動作例１と同様であるので説明を省略する。また、ステップＳ０７において、復旧メッセージが携帯端末２０に送信され、携帯端末２０にて、図５Ｂに示した処理と同様の処理が行われる。

動作例２によれば、携帯端末１０でのリソース使用率が閾値１を超えている場合に、アプリケーションＡの起動の確認画面Ｍ３が表示され、ユーザＡに対してアプリケーションＡの起動を許容するか否かの回答が求められる。ユーザＡが起動を許容しないのであれば、アプリケーションＡの起動がキャンセルされる。これに対し、ユーザＡが起動を許容するのであれば、予告メッセージが携帯端末２０に送信される。

予告メッセージを受信した携帯端末２０では、選択画面Ｍ４（ダイアログボックス）が表示装置に表示され、ユーザＢに対してアプリケーションＡの起動を許容するか否かの回答が求められる。ユーザＢが起動を許容しないとの回答を入力した場合には、起動を許容しないことを示す応答メッセージが携帯端末１０に送信される。ユーザＢが起動を許容するとの回答を入力した場合には、起動を許容することを示す応答メッセージが携帯端末１０に送信される。

応答メッセージを受信した携帯端末１０では、応答メッセージがアプリケーションＡの起動を許容しないことを示す場合に、アプリケーションＡの起動がキャンセルされる。これに対し、応答メッセージがアプリケーションＡの起動の許容を示す場合に、アプリケーションＡの起動処理が開始される。その後、アプリケーションＡの起動処理が終了した時点、すなわちリソース使用率が閾値２以下となった時点で、復旧メッセージが携帯端末２０に送信される。

携帯端末２０では、復旧メッセージに基づき、ユーザＢが通話品質劣化状態からの復旧を知ることができる。このように、動作例２によれば、動作例１と同様の効果に加えて、ユーザＡ及びユーザＢの双方が通話品質の劣化を許容する場合にアプリケーションＡを起動することができる。よって、ユーザＡの判断のみで、通話品質劣化状態へ遷移することが防止される。

上述した動作例１と動作例２とは選択的に実行されることができる。すなわち、携帯端末１０及び２０は、上述した動作例１及び動作例２の一方のみを実行可能な携帯端末で合っても良い。なお、携帯端末１０と携帯端末２０との通話中に携帯端末２０で或るアプリケーションの起動操作が行われた場合には、携帯端末２０が動作例１又は２における携帯端末１０の動作を行い、携帯端末１０が動作例１又は２における携帯端末２０の動作を行う。

また、動作例２において、確認画面表示に係るステップＳ１１及びＳ１２（図６）は、オプションとすることができる。すなわち、ステップＳ１１及びＳ１２は省略可能である。一方、動作例２において、選択画面表示に係るステップＳ３１からＳ３３は、オプションとすることが可能である。すなわち、ステップＳ３１からＳ３３は省略可能である。

上述した実施形態では、負荷テーブル８６に対し、各アプリケーションの負荷（リソース使用率）が予め格納されている例について示した。図８は、負荷テーブル８６に対する情報の格納処理例を示すフローチャートである。

図８に示す処理は、例えば、アプリケーション監視部８１からアプリケーション起動制御部８２に対して、或るアプリケーション（この例では、アプリケーションＢとする）の起動命令が通知された場合に開始される。

アプリケーションＢの起動命令を受け取ったアプリケーション起動制御部８２は、負荷テーブル８６を参照し、アプリケーションＢに対するエントリが負荷テーブル８６に格納されているか否かを判定する（ステップＳ００１）。

このとき、アプリケーションＢのエントリが負荷テーブル８６に格納されていれば（Ｓ００１；ＹＥＳ）、図８に示す処理が終了する。これに対し、アプリケーションＢに対するエントリが負荷テーブル８６に格納されていなければ（Ｓ００１；ＮＯ）、アプリケーション起動制御部８２は、アプリケーションＢのエントリを負荷テーブル８６に作成し（ステップＳ００２）、アプリケーションＢの起動を負荷制御部８３に通知する。

アプリケーションＢの起動が通知された負荷制御部８３は、現在のリソース使用率を得て、アプリケーションＢの起動前のリソース使用率として、負荷テーブル８６中のアプリケーションＢのエントリに格納する（ステップＳ００３）。負荷制御部８３は、起動前のリソース使用率が格納されたことをアプリケーションＢに通知する。

起動前のリソース使用率の格納が通知されたアプリケーション起動制御部８２は、アプリケーションＢの起動処理を開始し（ステップＳ００４）、アプリケーションＢの起動開始通知を負荷制御部８３に与える。負荷制御部８３は、起動開始通知を受け取ると、リソース使用率を継続的に監視する（ステップＳ００５）。

アプリケーション起動制御部８２は、アプリケーションＢの起動処理が完了すると（ステップＳ００６；ＹＥＳ）、アプリケーションＢの起動完了通知を負荷制御部８３に与える。負荷制御部８３は、起動完了通知を受け取ると、起動開始通知を受け取ってから起動完了通知を受け取るまでの間におけるリソース使用率の平均値を算出する（ステップＳ００７）。

続いて、負荷制御部８３は、起動前のリソース使用率を負荷テーブル８６のアプリケーションＢのエントリから読み出し、平均値との差分を算出する。負荷制御部８３は、算出された差分を、アプリケーションＢのリソース使用率、すなわち閾値１として、負荷テーブル８６のアプリケーションＢのエントリに登録する（ステップＳ００８）。

また、負荷制御部８３は、現在のリソース使用率、すなわち、アプリケーションＢの定常状態時のリソース使用率を取得し（ステップＳ００９）、起動前のリソース使用率との差分を得る。負荷制御部８３は、定常状態時のリソース使用率と起動前のリソース使用率との差分を、動作例１及び動作例２で説明した閾値２を算出するための値として、負荷テーブル８３のアプリケーションＢのエントリに登録する（ステップＳ０１０）。

その後、通話中にアプリケーションＢの起動操作が行われた場合には、負荷テーブル８６に格納された閾値１を用いてステップＳ０３（図３、図６）の処理が実行され、閾値２を算出するための値を用いて、ステップＳ０６（図３、図６）の処理を実行するための閾値２が算出される。

図８に示した処理において、起動前のリソースの使用率は、閾値１が登録される間での間、一時的に格納されるようにしても良い。平均値の代わりに、起動処理中の最大リソース使用率が採用されても良い。また、エントリは、アプリケーション起動制御部８２の代わりに負荷制御部８３が作成するようにしても良い。

上述した実施形態によれば、携帯端末１０と携帯端末２０との間での通話中に、ユーザＡ又はユーザＢが、携帯端末１０又は携帯端末２０に記憶された会話に必要な情報を呼び出して会話に利用することを所望する場合に、通話相手に対して予告メッセージが送信されることによって、通話品質の劣化を予告し、会話の中断を促すことができる。また、通話品質劣化状態からの復旧時に復旧メッセージが送信されることによって、会話の再開を促すことができる。これによって、携帯端末に記憶された情報を利用しつつ、ストレスのない会話を行うことができる。

また、上述した実施形態では、携帯電話機能を用いた通話について説明したが、ＩＰ電話機能を用いた通話中における他のアプリケーションの起動命令が発行された場合にも、動作例１及び動作例２の動作を行うことが可能である。また、実施形態に示した携帯端末の構成及び機能は、固定型の端末装置にも適用可能であるが、携帯端末に適用するのが好
適である。

また、上述した実施形態では、携帯電話網Ｎ１を用いた通話中に、アプリケーションの起動に伴う各種のメッセージをＩＰ網Ｎ２を介して送受信する例について説明した。但し、他の実施形態として、携帯電話網Ｎ１のみを用いて通話及びメッセージ送受信のためのＩＰ通信を行う構成を採用可能である。すなわち、予告メッセージや復旧メッセージ等の各種のメッセージの送受信に携帯電話網Ｎ１を用いたＩＰ通信を適用することができる。或いは、他の実施形態として、ＩＰ網Ｎ１のみを用いてＩＰ電話による通話とメッセージ送受信のためのＩＰ通信を行う構成を適用することもできる。すなわち、通話は、携帯電話網を用いた通話であっても、ＩＰ電話によるＩＰ網Ｎ１を用いた通話であっても良い。また、メッセージの送受信は、携帯電話網Ｎ１を介したＩＰ通信であっても、ＩＰ網Ｎ２を通じたＩＰ通信であっても良い。通話とメッセージの送受信とのそれぞれに適用される網は、適宜決定することができる。

＜その他＞
上述した実施形態は、以下の発明を開示する。以下の発明は適宜組み合わせることができる。
（付記１）通話相手との通話処理を行う通話制御部と、
アプリケーションプログラムの実行を制御するアプリケーション制御部と、
前記通話制御部による通話処理中に前記アプリケーションプログラムの起動が前記アプリケーション制御部に指示された場合に、前記アプリケーションプログラムの起動によって通話品質が劣化するか否かを判定する判定部と、
前記通話品質が劣化すると判定される場合に、通話品質劣化を予告する予告メッセージを前記通話相手に送信する送信部と
を含む端末装置。（１）
（付記２） 前記アプリケーション制御部は、前記予告メッセージの送信後に前記アプリケーションプログラムの起動処理を行い、
前記送信部は、前記アプリケーションプログラムの起動処理の終了後に、通話品質劣化状態からの復旧を知らせるための復旧メッセージを前記通話相手に送信する
付記１に記載の端末装置。（２）
（付記３） 前記通話品質が劣化すると判定される場合に、前記端末装置のユーザに対して、前記アプリケーションプログラムの起動による通話品質劣化を許容するか否かの回答入力を促す問い合わせ部をさらに含み、
ユーザから入力された回答入力が前記通話品質劣化の許容を示す場合に、前記送信部が前記予告メッセージを前記通話相手に送信し、前記回答入力が前記通話品質劣化を許容しないことを示す場合に、前記アプリケーション制御部が前記アプリケーションの起動をキャンセルする
付記１に記載の端末装置。（３）
（付記４） 前記予告メッセージに対する応答メッセージを受信する受信部をさらに含み、
前記アプリケーション制御部は、前記応答メッセージが前記通話相手が通話品質劣化を許容することを示す場合に前記アプリケーションプログラムの起動処理を開始し、前記応答メッセージが前記通話相手が通話品質劣化を許容しないことを示す場合に前記アプリケーションプログラムの起動をキャンセルする
付記１に記載の端末装置。（４）
（付記５） 前記判定部は、前記アプリケーションプログラムの起動によって前記端末装置の負荷が閾値を超える場合に、前記通話の品質が劣化すると判定する
付記１に記載の端末装置。
（付記６）
前記送信部は、前記端末装置の負荷が前記アプリケーションプログラムの起動処理の終
了を示す状態となった場合に、前記復旧メッセージを送信する
付記２に記載の端末装置。
（付記７）
前記通話相手からの前記予告メッセージを受信する受信部と、
前記予告メッセージが受信された場合に、前記予告メッセージに基づく通話品質劣化の予告を報知する報知部とをさらに含む
付記１に記載の端末装置。
（付記８）
前記通話相手からの前記復旧メッセージを受信する受信部と、
前記復旧メッセージが受信された場合に、前記通話の品質の劣化状態からの復旧を報知する報知部とをさらに含む
付記１に記載の端末装置。
（付記９）
通話相手との通話に係る処理を行う通話制御部と、
前記通話制御部による通話処理中に、通話品質劣化を予告するための予告メッセージを前記通話相手から受信する受信部と、
前記予告メッセージに基づく通話品質劣化を報知する報知部と、
を含む端末装置。（５）
（付記１０）
前記受信部は、通話品質劣化の状態からの復旧を知らせるための復旧メッセージを前記通話相手から受信し、
前記報知制御部は、前記復旧メッセージに基づく通話品質劣化状態からの復旧を報知する報知処理を行う
付記１０に記載の端末装置。
（付記１１）
前記予告メッセージの受信時に、通話品質劣化を許容するか否かの回答入力をユーザに促す問い合わせ部と、
前記ユーザから入力された回答を示す応答メッセージを前記通話相手に送信する送信部とをさらに含む
付記１０に記載の端末装置。

Ａ１，Ａ２・・・アクセスポイント
Ｂ１，Ｂ２・・・基地局
Ｎ１・・・携帯電話網
Ｎ２・・・ＩＰ網
１・・・ＣＰＵ
２・・・主記憶装置
３・・・二次記憶装置
４・・・入力装置
５・・・出力装置
６・・・ＲＦ回路
７・・・無線ＬＡＮインタフェース
８・・・オペレーティングシステム（ＯＳ）
９・・・アプリケーションプログラム
８１・・・アプリケーション監視部
８２・・・アプリケーション起動制御部
８３・・・負荷制御部
８４・・・ＵＩ制御部
８５・・・メッセージ制御部
８６・・・負荷テーブル

Claims (5)

1. 通話相手との通話処理を行う通話制御部と、
   アプリケーションプログラムの実行を制御するアプリケーション制御部と、
   前記通話制御部による通話処理中に前記アプリケーションプログラムの起動が前記アプリケーション制御部に指示された場合に、前記アプリケーションプログラムの起動によって通話品質が劣化するか否かを判定する判定部と、
   前記通話品質が劣化すると判定される場合に、通話品質劣化を前記通話相手のユーザに予告するための予告メッセージを前記通話相手に送信する送信部と
   を含む端末装置。
2. 前記アプリケーション制御部は、前記予告メッセージの送信後に前記アプリケーションプログラムの起動処理を行い、
   前記送信部は、前記アプリケーションプログラムの起動処理の終了後に、通話品質劣化状態からの復旧を知らせるための復旧メッセージを前記通話相手に送信する
   請求項１に記載の端末装置。
3. 前記通話の品質が劣化すると判定される場合に、前記端末装置のユーザに対して、前記アプリケーションプログラムの起動による通話品質の劣化を許容するか否かの回答入力を促す問い合わせ部をさらに含み、
   ユーザから入力された回答入力が前記通話品質の劣化の許容を示す場合に、前記送信部が前記予告メッセージを前記通話相手に送信し、前記回答入力が前記通話品質の劣化を許容しないことを示す場合に、前記アプリケーション制御部が前記アプリケーションの起動をキャンセルする
   請求項１に記載の端末装置。
4. 前記予告メッセージに対する応答メッセージを受信する受信部をさらに含み、
   前記アプリケーション制御部は、前記応答メッセージが前記通話相手が通話品質劣化を許容することを示す場合に前記アプリケーションプログラムの起動処理を開始し、前記応答メッセージが前記通話相手が通話品質劣化を許容しないことを示す場合に前記アプリケーションプログラムの起動をキャンセルする
   請求項１に記載の端末装置。
5. 通話相手との通話に係る処理を行う通話制御部と、
   前記通話制御部による通話処理中に、前記通話相手による通話中のアプリケーションの起動によって起こる通話品質劣化をユーザに予告するための予告メッセージを前記通話相手から受信する受信部と、
   前記予告メッセージに基づく通話品質劣化の予告をユーザに報知する報知部と、
   を含む端末装置。
   
   

Images