情報処理装置および画面表示方法
【課題】 様々な機種における操作性を統一させることができる情報処理装置および画面表示方法を提供することを目的とする。
【解決手段】 キー入力部２１において受け付けられたキー入力による画面表示が例外処理要求を必要とすると、メインシステム制御部２３により判断されると、メインシステム制御部２３は、例外処理要求をＵＩエンジン３０に通知する。一方、ＵＩエンジン３０において、メインシステム２０から例外処理要求が通知されると、ＵＩコンテンツ制御部３１の制御のもと、格納部３２が当該例外処理要求を記憶する。そして、その後、メインシステム２０において受け付けられたキー入力およびその時点でのページ状態が、例外処理記憶部３２２に記憶されている例外処理要求と一致する場合には、ＵＩコンテンツ制御部３１は例外処理発生の通知をメインシステム２０に行い、メインシステム２０では、通知にしたがった内容を表示部２４に表示させる。
【解決手段】 キー入力部２１において受け付けられたキー入力による画面表示が例外処理要求を必要とすると、メインシステム制御部２３により判断されると、メインシステム制御部２３は、例外処理要求をＵＩエンジン３０に通知する。一方、ＵＩエンジン３０において、メインシステム２０から例外処理要求が通知されると、ＵＩコンテンツ制御部３１の制御のもと、格納部３２が当該例外処理要求を記憶する。そして、その後、メインシステム２０において受け付けられたキー入力およびその時点でのページ状態が、例外処理記憶部３２２に記憶されている例外処理要求と一致する場合には、ＵＩコンテンツ制御部３１は例外処理発生の通知をメインシステム２０に行い、メインシステム２０では、通知にしたがった内容を表示部２４に表示させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツを表示することのできる情報処理装置および画面表示方法に関する。
【背景技術】
【０００２】
移動機におけるメニューなどの表示画面（以下、ＵＩ（User Interface）コンテンツとする）はコンテンツ化されており、ユーザの嗜好に沿ったカスタマイズを行うことができるシステムが構築されている。例えば、特開２００５−３５２９４３号（特許文献１）には、メニューなどの表示画面をユーザの使用形態を反映させてカスタマイズすることができる情報端末が記載されている。また、特開２００６−３１１４９８号公報（特許文献２）には、特定のイベントが発生すると移動体のディスプレイを変化させる手段が開示されており、また端末機において、移動体（アイコンに相当）を魚のキャラクター化し、そのキャラクター化したイメージをディスプレイすることが記載されている。
【特許文献１】特開２００５−３５２９４３号公報
【特許文献２】特開２００６−３１１４９８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このＵＩコンテンツの表現力に自由度をもたせるために、ＵＩコンテンツはウエブサイトからダウンロードすることが考えられている。また、基本的には、移動機のキーイベントについては、ＵＩコンテンツを制御するＵＩエンジン部が取得して、それに対する表示動作についても、ＵＩコンテンツにしたがってＵＩエンジン部が決定権を持つことが考えられている。例えば、あるキーイベントが発生すると、ＵＩエンジン部がキー内容を取得し、ＵＩコンテンツにしたがってどのようなコンテンツを表示するかを判断し、表示することが考えられている。
【０００４】
しかしながら、ＵＩエンジン部およびその制御を行うシステム部のある特定の状態においては、例外処理的に、キーイベントに対する表示動作の決定権をシステム部がもつ必要がある。例えば、あるキーイベントに対して表示される表示画面を統一させたい場合がある。ＵＩエンジン部におけるＵＩコンテンツの描画処理は、ＵＩコンテンツにしたがった処理を行うことを前提とするものであることから、ユーザまたはＵＩコンテンツの製作者が、キーイベントに対するコンテンツの描画を適宜変えることができる。したがって、ＵＩコンテンツのカスタマイズを前提とするＵＩエンジン部に操作の統一対象となるキーイベントの決定権を渡すことは妥当ではない。
【０００５】
一方、システム部が常にＵＩエンジン部におけるＵＩコンテンツの表示状態を把握し、その表示状態に応じて処理を分けることで解決可能であるが、ＵＩコンテンツの状態変化のたびに、ＵＩエンジン部がシステム部に状態通知を行うことは、ＵＩコンテンツの表示速度を著しく低下させる可能性がある。例えば、ＵＩエンジン部におけるページ遷移などＵＩコンテンツの状態変化の度に、ＵＩエンジン部からシステム部に状態通知が行われ、また、システム部では、スタックされた状態通知に応じて状態判定を行う処理時間が消費される。
【０００６】
そこで、上述の課題を解決するために、本発明は、ＵＩコンテンツの状態をシステム部に通知することなく、様々な機種における操作性を統一させることができる情報処理装置および画面表示方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述の課題を解決するために、本発明の情報処理装置は、装置の制御を行うシステム部と、前記システム部による制御のもと、コンテンツの描画処理を行うコンテンツエンジン部と、を備える情報処理装置において、前記システム部は、ユーザからキー入力を受け付けるキー入力手段と、前記キー入力手段により受け付けられたキー入力による画面表示が例外処理要求を必要とするか否かを判断する判断手段と、前記判断手段により例外処理要求が必要であると判断されると、前記コンテンツエンジン部にコンテンツの再生要求および例外処理要求の内容を通知し、例外処理要求が必要でないと判断されると、例外処理要求の通知を行わずに、コンテンツの再生要求を行う例外要求通知手段と、前記コンテンツエンジン部において描画処理されたコンテンツを表示する表示手段と、前記コンテンツエンジン部から例外処理発生の通知を受けると、当該通知にしたがった表示内容を前記表示手段に出力する例外処理手段と、を備え、前記コンテンツエンジン部は、前記例外要求通知手段により例外処理要求が通知されると、当該例外処理要求を記憶する記憶手段と、前記記憶手段に例外処理内容が記憶された後に、前記キー入力手段によるキー入力が前記記憶手段に記憶されている例外処理要求に一致する場合には、例外処理発生の通知を前記システム部に行う例外処理通知手段と、前記記憶手段に例外処理要求が記憶された後に、前記キー入力手段によるキー入力が前記記憶手段に記憶されている例外処理要求に一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを前記表示手段に出力する描画処理手段と、を備えている。
【０００８】
この発明によれば、システム部において、受け付けられたキー入力による画面表示が例外処理要求を必要とすると判断されると、コンテンツの再生要求および例外処理要求の内容をコンテンツエンジン部に通知し、例外処理要求が必要でないと判断されると、例外処理要求の通知を行わずに、コンテンツの再生要求を行う。
【０００９】
一方、コンテンツエンジン部において、システム部から例外処理要求が通知されると、当該例外処理要求を記憶する。そして、その後、システム部において受け付けられたキー入力が、記憶されている例外処理要求に一致する場合には、例外処理発生の通知をシステム部に行い、通知にしたがった内容を表示させる。また、システム部において受け付けられたキー入力が、記憶されている例外処理要求に一致しない場合には、キー入力にしたがった描画処理を行い、描画処理したコンテンツを表示させる。
【００１０】
これにより、コンテンツエンジン部において例外処理の発生を判断し、システム部において例外処理を実行することができ、ユーザの操作性を統一させることを可能とさせる。
【００１１】
また、本発明の情報処理装置において、例外処理要求は、入力されたキーを示すキー種別および表示されているページを示すページ状態を含み、前記コンテンツエンジン部における前記例外処理通知手段は、現に表示されているページのページ状態および前記キーイベント通知手段により通知されたキー入力のキー種別が、前記記憶手段に記憶されている例外処理要求の内容と一致する場合には、例外処理発生の通知を前記システム部に行い、一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを前記表示手段に出力することが好ましい。
【００１２】
この発明によれば、現に表示されているページのページ状態および通知されたキー入力のキー種別が、予め記憶されている例外処理要求の内容と一致しているか否かを判断することができ、システム部に例外処理の発生の通知を適切に行うことができる。
【００１３】
ところで、本発明は、上記のように情報処理装置の発明として記述できる他に、以下のように、画面表示方法の発明としても記述することができる。これらはカテゴリーが異なるだけで、実質的に同一の発明であり、同様の作用・効果を奏する。
【００１４】
すなわち、本発明の画面表示方法は、装置の制御を行うシステム部と、前記システム部による制御のもと、コンテンツの描画処理を行うコンテンツエンジン部と、を備える情報処理装置の画面表示方法において、前記システム部は、ユーザからキー入力を受け付けるキー入力ステップと、前記キー入力ステップにより受け付けられたキー入力による画面表示が例外処理要求を必要とするか否かを判断する判断ステップと、前記判断ステップにより例外処理要求が必要であると判断されると、前記コンテンツエンジン部にコンテンツの再生要求および例外処理要求の内容を通知し、例外処理要求でないと判断されると、例外処理要求の通知を行わずに、コンテンツの再生要求を行う例外処理要求通知ステップと、を備え、前記コンテンツエンジン部は、前記例外要求通知ステップにより例外処理要求が通知されると、当該例外処理要求を記憶する記憶ステップと、前記記憶ステップに例外処理内容が記憶された後に、前記キー入力ステップによるキー入力が予め記憶されている例外処理要求に一致する場合には、例外処理発生の通知を前記システム部に行う例外処理通知ステップと、例外処理要求が記憶された後に、前記キー入力ステップによるキー入力が予め記憶されている例外処理要求に一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを表示させる描画処理ステップと、を備え、前記システム部は、前記コンテンツエンジン部の描画処理ステップにおいて処理されたコンテンツを表示する表示ステップと、前記コンテンツエンジン部の前記例外処理通知ステップにおいて処理された例外処理発生の通知を受けると、当該通知にしたがった表示内容を表示させる例外処理ステップと、
をさらに備えている。
【発明の効果】
【００１５】
本発明によれば、コンテンツエンジン部において例外処理の発生を判断し、システム部において例外処理を実行することができ、ユーザの操作性を統一させることを可能とさせる。
【発明を実施するための最良の形態】
【００１６】
本発明は、一実施形態のために示された添付図面を参照して以下の詳細な記述を考慮することによって容易に理解することができる。引き続いて、添付図面を参照しながら本発明の実施形態を説明する。可能な場合には、同一の部分には同一の符号を付して、重複する説明を省略する。
【００１７】
図１は、本実施形態の携帯電話機１０の機能ブロックを示すブロック図である。図１に示すように、携帯電話機１０は、メインシステム２０（システム部）およびＵＩエンジン３０（コンテンツエンジン部）を含んで構成されている。さらに、メインシステム２０は、キー入力部２１（キー入力手段）、ＵＩコンテンツ格納部２２、メインシステム制御部２３、および表示部２４（表示手段）を含んで構成されており、ＵＩエンジン３０は、ＵＩコンテンツ制御部３１、格納部３２、ＵＩコンテンツ描画部３３を含んで構成されている。この携帯電話機１０は、図２に示されているハードウェアから構成されている。
【００１８】
図２は、携帯電話機１０のハードウェア構成図である。図１に示される携帯電話機１０は、物理的には、図２に示すように、ＣＰＵ１０１、主記憶部１０２、補助記憶部１０３、通信制御部１０４、表示部１０５、および操作部１０６などを含むコンピュータシステムとして構成されている。図１において説明した各機能は、図２に示すＣＰＵ１０１、主記憶部１０２等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ１０１の制御のもとで通信制御部１０４、表示部１０５、操作部１０６を動作させるとともに、主記憶部１０２、補助記憶装置１０３におけるデータの読み出し及び書き込みを行うことで実現される。
【００１９】
なお、この携帯電話機１０におけるモジュール構成は図３に示す構成からなる。図３は、本実施形態の携帯電話機１０に搭載されている各モジュールのモジュール構成図である。図３に示されているように、ＯＳ（Operating System）５０の上にミドルウエアであるメインシステム制御モジュール（アプリケーション）５１およびＵＩエンジン制御モジュール５２が動作し、メインシステム制御モジュール５１とＵＩエンジン制御モジュール５２とは、相互に制御指示の送受を行うことを可能にしている。
【００２０】
このＵＩエンジン制御モジュール５２は、キャリア事業者がメーカに対して提供するモジュールの一つであって、コンテンツメーカが製作したメニュー画面など、ダウンロードされたコンテンツの描画表現を可能に構成されたモジュールである。この描画表現は、当該コンテンツに記述されているスクリプトにしたがって表現されるものである。本実施形態においては、コンテンツメーカ独自の表現を可能にするコンテンツであって、メニュー画面を構成するためのコンテンツの描画処理を可能にするように構成されてものである。
【００２１】
このコンテンツがメニュー画面を構成するためのものである場合には、コンテンツメーカによって、その操作内容は異なっている場合がある。一方で、メインシステム制御モジュール５１は、例えば、移動通信網のキャリア事業者により定められた基本設計に基づいて構成されたものであり、メインシステム２０は同一のキャリア事業者から提供されている端末であればメーカが異なってもその操作性などの基本思想はほぼ同一のものとなるよう構成されている。
【００２２】
また、メインシステム制御モジュール５１は、メインシステム制御部２３として機能するのであって、ＯＳ５０を介してキー入力部２１のキー入力の受付を判断し、また、ＯＳ５０を介して表示部２４に対して表示処理を行うことができる。また、ＵＩエンジン制御モジュール５２は、ＵＩエンジン制御部３５として機能するものであって、ハードウェアとして構成されている格納部３２（例えば、主記憶部１０２または補助記憶部１０３内にその格納領域が形成されている）に対して各種情報の格納処理または読み出し処理を行う。以下、図１に示す機能ブロックに基づいて、各機能ブロックを説明する。
【００２３】
メインシステム２０は、装置全体を制御する制御モジュールであって、キー入力部２１（操作部１０６に相当）、メインシステム制御部２３（ＣＰＵ１０１に相当）、および表示部２４（表示部１０５に相当）から構成されている。
【００２４】
キー入力部２１は、ユーザからの操作を受け付ける部分であり、例えば、本実施形態においては少なくとも、メニュー画面を表示することを指示するためのメニューキー、メールメニュー画面を表示するためのメールキー、ブラウザメニュー画面を表示するためのインターネットキー、入力した文字を削除しまたは画面を一つ前に戻るためのクリアキー、および０を含んだ英数字のキーを含んでいる。
【００２５】
ＵＩコンテンツ格納部２２は、メニュー画面を構成するためのフレームデータ、アイコンデータおよびメニュー画面における操作ルールが記述されているスクリプトデータなどのコンテンツデータを格納する部分である。このＵＩコンテンツ格納部２２に格納されているフレームデータ、アイコンデータおよびスクリプトデータは、予め格納されたものでもよいし、ダウンロードされることにより取得されるものでもよい。
【００２６】
メインシステム制御部２３は、判断部２３１（判断手段）、通知部２３２（例外要求通知手段）および例外処理部２３３（例外処理手段）を備える。判断部２３１は、キー入力部２１において受け付けられたキー操作内容に基づいて、例外処理要求が必要であるか否かを判断する部分であり、例えば、メインシステム制御部２３は、キー入力部２１において、メニューキー、メールキー、またはインターネットキーの入力の受け付けがなされか否かを判断し、例外処理の要求が必要であるか否かを判断する。
【００２７】
ここで判断部２３１が、メニューキー、メールキー、またはインターネットキーのいずれかの入力の受付がなされ、例外処理の要求が必要であると判断すると、通知部２３２は、その入力に対応したＴＯＰメニュー画面、メールメニュー画面、ブラウザメニュー画面のいずれかの画面を構成するコンテンツデータが記憶されているＵＩコンテンツ格納部２２の領域のアドレスデータ、そのコンテンツデータの再生要求、および例外処理要求をＵＩエンジン３０に出力する。なお、通知部２３２は、アドレスデータを出力する代わりに、コンテンツデータそのものを出力するようにしてもよい。
【００２８】
また、判断部２３１は、上述のように予め定められた例外処理要求が必要ではないキー操作がキー入力部２１により受け付けられたと判断した場合には、通知部２３２はその入力に対応したコンテンツデータの再生要求をＵＩエンジン３０に出力する。この再生要求通知には、ＵＩコンテンツ格納部２２に記憶されているコンテンツデータの記憶領域を示すアドレスデータが含まれている。
【００２９】
例外処理部２３３は、通知部２３２がキーイベント通知を行った後に、ＵＩエンジン３０から例外処理発生通知とともに、上述キー入力に応じた動作要求を受けると、当該動作要求に応じた処理を実行する。例えば、メインシステム制御部２３は、メニューキーの押下によりＴＯＰメニュー画面を表示し、その表示時に、キー入力部２１において０キーが入力された場合には、ＵＩエンジン３０から例外処理発生通知とともに自局番号の表示要求を受信し、自局番号を表示部２４に表示させる。
なお、メインシステム制御部２３は、キー処理部（図示せず）および状態格納部（図示せず）をさらに備えており、この状態格納部は、ＵＩエンジン３０（ＵＩコンテンツ制御部３１）からＵＩコンテンツ再生要求に応じた応答信号を受けると、ＵＩコンテンツ再生中の旨を記憶する。メインシステム部２３は、キー入力があったとき、この状態格納部に記憶されている情報に基づいて、通知部２３２がＵＩコンテンツを利用するためのコンテンツ再生要求を行うか、若しくはキーイベント通知を行うか、またはキー処理部を用いた、ＵＩコンテンツを利用しないキー入力処理を行うかを判断する。状態格納部にＵＩコンテンツが再生中である旨の情報が記憶されている場合には、通知部２３２はキーイベント通知を行うよう処理する。状態格納部に当該情報が記憶されていない場合には、キー処理部は受け付けたキー入力に対応した処理（ＵＩコンテンツの再生要求、またはキー処理部によるキー処理）を実行する。
【００３０】
表示部２４は、ＵＩエンジン３０において描画処理されたメニュー画面などのコンテンツまたはメインシステム２０において処理されたデータを表示する部分である。
【００３１】
ＵＩエンジン３０は、ＵＩコンテンツ制御部３１（例外処理通知手段）、格納部３２（記憶手段）、およびＵＩコンテンツ描画部３３（描画処理手段）を含んで構成されている。
【００３２】
ＵＩコンテンツ制御部３１は、メインシステム２０から送信されたＵＩコンテンツ再生要求およびそのアドレスデータを受信すると、ＵＩコンテンツ再生要求およびアドレスデータにしたがって、コンテンツデータをＵＩコンテンツ格納部２２から読み出し、読み出したコンテンツデータをＵＩコンテンツ描画部３３に出力し、描画処理をさせる。また、ＵＩコンテンツ描画部３３から描画要求に対する応答を受けると、当該ＵＩコンテンツ再生要求に基づいたページ状態を記憶するようページ状態を示す情報をページ状態記憶部３２１に出力する。
【００３３】
また、ＵＩコンテンツ制御部３１は、メインシステム２０から例外処理要求を受信すると、例外処理要求に含まれている情報を例外処理記憶部３２２に出力し、記憶させる。例外処理要求には、ページ状態、キー種別、および動作種別が含まれている。ここで具体例を、図を用いて説明する。図４は、例外処理記憶部３２２に記憶されている例外処理要求一覧を示す説明図である。図４に示されているように、メニューキーが押下された場合、ページ状態として、ＴＯＰメニューページ、キー種別として、０キー、動作種別として、自局番号の表示要求がメインシステム２０から送信され、例外処理記憶部３２２にはこれら情報が記憶される。なお、説明の便宜上、メニューキーが押下された場合、メールキーが押下され場合の両方を記憶されていることにしているが、通常いずれか一方のみが記憶され、または両方が記憶されていない状態である。
【００３４】
また、ＵＩコンテンツ制御部３１は、メインシステム制御部２３からキーイベント通知を受信すると、そのキーイベント通知に含まれているキー内容が、例外処理記憶部３２２に記憶されているキー種別に一致するか否かを、まず判断する。一致すると判断した場合には、つぎにページ状態記憶部３２１に記憶されているページ状態と例外処理記憶部３２２に記憶されているページ状態と一致するか否かを判断する。ここで、ページ状態も一致すると判断した場合には、ＵＩコンテンツ制御部３１は、例外処理発生通知をメインシステム２０に出力する。この例外処理発生通知には、例外処理発生の旨および例外処理の内容（例えば、自局番号表示をする旨）が含まれている。
【００３５】
なお、キー種別およびページ状態の一致・不一致の判断を両方行うとともにその判断結果をフラグで管理し、キー種別、ページ状態いずれのフラグも立っている状態である場合に、例外処理発生通知を行うようにしてもよい。このようにフラグで管理することにより、判定の種類が増えた場合、例えば入力文字列などの一致を判断したい場合を追加した場合にも、容易に設計変更を行うことを可能にする。
【００３６】
また、ＵＩコンテンツ制御部３１は、当該ＵＩコンテンツの再生が終了された場合には、例外処理記憶部３２２に記憶されている例外処理要求情報を消去する処理を行うことが好ましい。
【００３７】
格納部３２は、ページ状態記憶部３２１および例外処理記憶部３２２から構成されており、それぞれ現在表示しているページを示すページ状態情報、メインシステム２０から出力された例外処理要求情報（キー種別、ページ状態、動作種別）を記憶する。
【００３８】
ＵＩコンテンツ描画部３３は、ＵＩコンテンツ制御部３１からの指示により描画処理を行う部分であり、例えばメニュー画面を生成する部分である。
【００３９】
つぎに、このように構成された携帯電話機１０の動作について、図５および図６を用いて説明する。図５は、メニューキーが押下された場合の例外処理を実行する携帯電話機１０のシーケンス図であり、図６は、通常処理を実行する携帯電話機１０のシーケンス図である。
【００４０】
まず、図５で示される例外処理が行われるときの携帯電話機１０のシーケンス図について説明する。キー入力部２１においてユーザによりメニューキーが押下されると（Ｓ１０１）、その旨がメインシステム制御部２３に出力される（Ｓ１０２）。メインシステム制御部２３では、判断部２３１により出力されたキー入力による表示画面が例外処理要求を必要とするか否かが判断される（Ｓ１０３）。ここでは、判断処理後、まずはメインシステム制御部２３の通知部２３２により、ＵＩコンテンツ再生要求およびコンテンツデータのアドレスデータが、ＵＩエンジン３０に出力される（Ｓ１０４、Ｓ１０５）。また、キー入力はメニューキーの入力であり、例外処理要求が必要であるため、例外処理要求が通知部２３２によりＵＩエンジン３０に出力される（Ｓ１０６）。
【００４１】
ＵＩエンジン３０では、入力された例外処理要求が、ＵＩコンテンツ制御部３１により例外処理記憶部３２２に出力され、記憶される（Ｓ１０７）。また、ＵＩコンテンツ再生要求およびアドレスデータにしたがって、ＵＩコンテンツ制御部３１によりＵＩコンテンツデータがＵＩコンテンツ格納部２２から読み出され（図示せず）、読み出されたコンテンツデータはＵＩコンテンツ描画部３３に出力され、ＵＩコンテンツ描画部３３においてＵＩコンテンツデータに基づいてＵＩコンテンツ、すなわちここではメニュー画面が生成され（Ｓ１０８）、その応答信号がＵＩコンテンツ制御部３１、メインシステム制御部２３に出力される（Ｓ１０９）。ＵＩコンテンツ制御部３１では、この応答信号を受けると、ページ状態記憶部３２１に出力し、ページ状態情報を記憶させる（Ｓ１１０）。ここでは、ページ状態情報として“ＴＯＰメニューページ”が記憶される。一方で、ＵＩコンテンツ制御部３１からメインシステム制御部２０が応答信号を受けると、メインシステム制御部２０に備えられている状態格納部（図示せず）にＵＩコンテンツが再生中である旨が記憶される。
【００４２】
ＵＩコンテンツ描画部３３により生成されたメニュー画面データは、メインシステム２０における表示部２４に出力され（Ｓ１１１）、ＴＯＰメニュー画面が表示部２４に表示される（Ｓ１１２）。
【００４３】
つぎに、ＴＯＰメニュー画面を見ながらユーザが操作するときの処理について、図５を用いて引き続き説明する。ここでは、０キーが押下された場合について説明している。表示部２４におけるＴＯＰメニュー画面表示後、ユーザによる押下操作により０キーが押下されたことがキー入力部２１に受け付けられ（Ｓ１１３）、０キーが押下されたことがキーイベント通知としてメインシステム制御部２３を介してＵＩコンテンツ制御部３１に出力される（Ｓ１１４）。なお、メインシステム制御部２３では、通知部２３２は、キー入力が行われると、ＵＩコンテンツが再生中である旨を状態格納部が記憶していることを確認してからキーイベント通知をＵＩコンテンツ制御部３１に出力する。ＵＩコンテンツが再生中である旨を状態格納部が記憶していない場合には、通知部２３２の処理は行われることなく、メインシステム制御部２３内においてキー入力に応じた処理、またはそのキー入力がＵＩコンテンツの再生要求である場合には当該再生要求が行われる。
【００４４】
ＵＩエンジン３０では、ＵＩコンテンツ制御部３１によりキーイベント通知が入力されると、例外処理記億部３２２に記憶されている例外処理要求と、キーイベント通知により通知されたキーとを照合し、キー種別判断として、例外処理要求と一致することを確認する（Ｓ１１５）。そして、確認後、ページ状態判断として、現在のＵＩコンテンツ制御部３１において把握しているページ状態、すなわちページ状態記憶部３２１に記憶されているページ状態情報と例外処理記憶部３２２に記憶されているページ状態情報とを比較し、一致していることを確認する（Ｓ１１６）。すなわち、例外処理の要求としてＴＯＰメニューページが記憶され、ページ状態としてＳ１１０でＴＯＰメニューページが記憶されており、ページ状態と例外処理の要求とが一致していることを確認する。
【００４５】
確認後、ＵＩコンテンツ制御部３１によりこのキーイベント通知は例外処理要求であると判断され、ＵＩコンテンツ制御部３１により例外処理発生通知およびその動作内容である自局番号の表示要求がメインシステム２０に出力される（Ｓ１１７）。
【００４６】
メインシステム２０では、例外処理部２３３により例外処理に基づいた自局番号表示処理が行われ、表示部２４には自局番号が表示される（Ｓ１１８）。
【００４７】
以上の通り、メインシステム２０において例外処理を行うときの条件をＵＩエンジン３０に通知し、ＵＩエンジン３０ではその条件を満たした場合に、メインシステム２０に通知し、メインシステム２０において例外処理にしたがった処理、ここでは自局番号の表示を行うことができる。よって、例外処理時には、ＵＩコンテンツに依存することなく、メインシステム２０において例外処理を実行することができ、操作の統一性を簡単に図ることができる。
【００４８】
つぎに、図６に示される、例外処理を行わない通常処理、すなわち、キーイベントをＵＩエンジン３０側でコンテンツの生成処理に利用するときの携帯電話機１０の処理のシーケンス図について説明する。
【００４９】
図５におけるＳ１０９でのメニュー画面表示後に、０キー以外のキーが押下されると（例えば１キーなど）、すなわち操作の統一性の対象ではないキーが押下されると（Ｓ２０１）、メインシステム制御部２３に押下されたキー内容を含んだキーイベント通知が出力され、メインシステム制御部２３では、ＵＩコンテンツが再生中であることを確認した後、ＵＩエンジン３０にキーイベント通知として、キー内容が出力される（Ｓ２０２）。ＵＩエンジン３０では、ＵＩコンテンツ制御部３１によりキー種別が判断され（Ｓ２０３）、例外処理の要求ではないと判断されると、ページ状態を確認することなく、描画要求がＵＩコンテンツ描画部３３に出力される（Ｓ２０４）。ここでは、１キーが押下されたため、例外処理記憶部３２２に記憶されている例外処理要求のキー種別（０キー）とは異なっていることが確認され、ページ状態判定が行われることなく、ＵＩコンテンツ描画部３３において、コンテンツ内のスクリプトによる１キーにしたがった描画処理が行われ、表示部２４に出力される。
【００５０】
ＵＩコンテンツ描画部３３から、描画要求に応じた応答がＵＩコンテンツ制御部３１により受信されると、キーイベント通知に応じたページを示すページ状態が、ページ状態記憶部３２１に記憶される（Ｓ２０６）。そして、ＵＩコンテンツ描画部３３によりコンテンツデータが生成され、生成されたコンテンツデータは、表示部２４に出力され（Ｓ２０７）、表示される（Ｓ２０８）。
【００５１】
つぎに、メールキーが押下されたときの例外処理について説明する。図７は、メールキーが押下された場合の携帯電話機１０における例外処理を示すシーケンス図であり、図８は、通常処理を示すシーケンス図である。図７および図８は、図５および図６におけるメニューキーの押下およびそれに対応する処理が、メールキー押下およびそれに対応する処理に置き換わったものである。
【００５２】
すなわち、図７に示すとおり、ユーザによりメールキーが押下され、キー入力部２１により受け付けられると（Ｓ１０１ａ）、その旨がメインシステム制御部２３に出力され（Ｓ１０２）、メインシステム制御部２３において例外処理要求が必要であるか否かが判断される（Ｓ１０３）。以下、図５におけるＳ１０４〜Ｓ１１１に示される処理が実行される。すなわち、ＵＩコンテンツの再生要求、アドレスデータ、例外処理要求が、ＵＩエンジン３０に出力され、ＵＩエンジン３０において例外処理要求を記憶するとともに、メールメニューの描画要求が行われる。そして、描画要求が行われると、メールメニュー画面が表示部２４に表示される（Ｓ１１２ａ）。
【００５３】
その後、クリアキー押下がなされると（Ｓ１１３ａ）、ＵＩコンテンツが表示中であることを確認した後、キーイベントが通知され（Ｓ１１４）、キー種別判断、ページ状態の判断がなされ（Ｓ１１５、Ｓ１１６）、待ち受け画面が表示部２４に表示される（Ｓ１１８ａ）。
【００５４】
同様に、図８に示すように、クリアキー以外が押下されると（Ｓ２０１ａ）、キーイベントが通知され、キー種別判断、描画要求、ページ状態記憶が行われ、その後、キーイベント通知に対応した画面データが出力され、表示される（Ｓ２０２〜Ｓ２０８）。
【００５５】
このような処理により、メニューキーが押下され、メニューキーが表示されている状態でクリアキーが押下されると待ち受け画面に移行するよう、メインシステム側で管理することができ、その操作性を統一させることが容易となる。
【００５６】
このように構成された携帯電話機１０の表示部２４に表示される画面遷移を説明する。図９は、ＴＯＰメニューからの画面遷移を示す説明図である。携帯電話機１０に形成されているメニューキーが押下されると、ＴＯＰメニュー画面６０が表示されるよう構成されている。このＴＯＰメニュー画面６０は、インターネット、メール、アプリ、データＢＯＸなどの各種機能を起動させるための選択画面から構成されている。
【００５７】
ＴＯＰメニュー画面６０において、“２”キーが押下されると、メールメニュー画面６１が表示される。さらに、メールメニュー画面６１において、“１”キーが押下されると、受信ＢＯＸメニュー画面６２が表示される。一方、ＴＯＰメニュー画面６０において、“０”キーが押下されると、自局番号表示画面６３が表示される。従来においては、ＵＩエンジン３０において“０”キーが押下されると自局番号表示する、という設定がなされていないと、自局番号表示ができなかったが、本実施形態においては上述説明したとおりメインシステム２０において、自局番号表示の処理を実行することができる。よって、その操作性の統一性を保障することができる。
【００５８】
図１０は、メールニューからの画面遷移を示す説明図である。メールキーが押下されるとメールメニュー画面７０が表示される。このメールメニュー画面７０において、“１”キーが押下されると、受信ＢＯＸメニュー画面７１が表示される。一方、メールメニュー画面７０が表示されている状態において、クリアキーが押下されると、待受け画面７２が表示される。図９の場合と同様に、メインシステム２０において、待受け画面への遷移を実行することができ、その操作性を統一させることができる。
【００５９】
つぎに、本実施形態の携帯電話機１０の作用効果について説明する。本実施形態の携帯電話機１０のメインシステム２０において、キー入力部２１において受け付けられたキー入力による表示画面が例外処理要求を必要とすると、メインシステム制御部２３（判断部２３１）により判断されると、メインシステム制御部２３（通知部２３２）は、ＵＩコンテンツの再生要求および例外処理要求の内容をＵＩエンジン３０（ＵＩコンテンツ制御部３１）に通知する。また、メインシステム制御部２３（判断部２３１）により例外処理要求が必要でないと判断されると、メインシステム制御部２３（通知部２３２）は例外処理要求の通知を行わずに、ＵＩコンテンツの再生要求をＵＩエンジン３０に通知する。
【００６０】
一方、ＵＩエンジン３０において、メインシステム２０（通知部２３２）から例外処理要求が通知されると、ＵＩコンテンツ制御部３１の制御のもと、格納部３２（例外処理記憶部３２２）が当該例外処理要求を記憶する。そして、その後、メインシステム２０において受け付けられたキー入力が、例外処理記憶部３２２に記憶されている例外処理要求と一致すると、ＵＩコンテンツ制御部３１が判断する場合には、ＵＩコンテンツ制御部３１は例外処理発生の通知をメインシステム２０に行い、メインシステム２０では、通知にしたがった内容を表示部２４に表示させる。
【００６１】
また、メインシステム２０において受け付けられたキー入力が、例外処理記憶部３２２に記憶されている例外処理要求と一致しないと、ＵＩコンテンツ制御部３１が判断する場合には、ＵＩコンテンツ描画部３３に対して、キー入力にしたがった描画処理を行わせ、ＵＩコンテンツ描画部３３は、描画処理したコンテンツを表示部２４に表示させる。
【００６２】
これにより、ＵＩエンジン３０において例外処理の発生を判断し、メインシステム２０において例外処理を実行することができ、ユーザの操作性を統一させることを可能とさせる。
【００６３】
例えば、従来の方法においては、ＵＩエンジン３０側に、操作受け付けに対する処理の決定権があり、異なる機種間では必ずしも同じ操作性を保障していなかったが、本実施形態においては、メールキー押下によるメールメニュー画面を表示しているときに、クリアキーを押下すると、必ず待受け画面となるように設計することができる。以下、その具体例について説明する。図１１は、本実施形態における画面遷移の例を示した説明図である。図１１に示すように、操作例（１）、操作例（２）を対比しつつ説明する。
【００６４】
図１１の操作例（１）は、メニュー画面表示（状態（２））時のＵＩコンテンツ再生要求後に、例外処理要求を通知しない例であり、操作例（２）は、メールメニュー画面表示（状態（３））時のＵＩコンテンツ再生要求後に、例外処理要求を通知するする例である。操作例（１）（２）ともに、状態（１）として待受け画面表示状態が示されている。操作例（１）において、待受け画面表示中に（状態（１））、メニューキーが押下されると（イベント（１））、メニュー画面が表示され（状態（２））、さらに決定キーが押下されると（イベント（２））、メール画面表示状態となる（状態（３））。一方、操作例（２）においては、メールキーが押下されると（イベント（２））、同様にメール画面表示状態となる（状態（３））。
【００６５】
以下、図１１では、操作例（１）（２）ともに、メールメニュー画面表示状態から、決定キー押下（イベント（３））、受信ＢＯＸ画面表示（状態（４））、クリアキー押下（イベント（４））、メール画面表示（状態（５））と遷移している。
【００６６】
メール画面表示状態において、クリアキーが押下されると（イベント（５））、操作例（１）ではメニュー画面表示状態となる（状態（６））。一方、操作例（２）では、クリアキーが押下されると（イベント（５））、例外処理通知による例外処理が実行され待受け画面表示状態となる（状態（６））。従来において、イベント（５）においてクリアキーが押下された場合、その後に遷移する画面はＵＩエンジン３０側に依存していたため、ＵＩコンテンツを製作するメーカの仕様によっては必ずしも待受け画面表示にならない場合もある。
【００６７】
しかしながら、操作性の統一という観点で、操作例（２）のイベント（５）を条件に、メインシステム２０において待受け画面表示をさせることに統一させることで、操作性を向上させることができる。すなわち、機種およびＵＩコンテンツの種別に依存せず、メールキーによるメールメニュー画面が表示された場合に、クリアキーを押下すると、必ず待受け画面表示状態に遷移することができ、その操作性を向上させることができる。なお、操作例（１）においては、メニューキーを起点にメール画面を表示している。この場合には、クリアキーは一つ前の画面に戻ることがユーザの観点から望ましいと考えられている。よって、状態（５）においては同じ操作をしても、その起点が異なっている場合、その後の処理も変わるように制御されている。
【００６８】
また、例外処理記憶部３２２は、少なくとも入力されたキーを示すキー種別および表示されているページを示すページ状態を記憶しておき、ＵＩコンテンツ制御部３１は、現に表示されているページのページ状態および通知されたキー入力のキー種別が、例外処理記憶部３２２に記憶されている例外処理要求の内容と一致しているか否かを判断する。これにより、メインシステム２０に例外処理の発生の通知を適切に行うことができる。
【図面の簡単な説明】
【００６９】
【図１】、本実施形態の携帯電話機１０の機能ブロックを示すブロック図である。
【図２】携帯電話機１０のハードウェア構成図である。
【図３】本実施形態の携帯電話機１０に搭載されている各モジュールのモジュール構成図である。
【図４】例外処理記憶部３２２に記憶されている例外処理要求一覧を示す説明図である。
【図５】メニューキーが押下された場合の例外処理を実行する携帯電話機１０のシーケンス図である。
【図６】通常処理を実行する携帯電話機１０のシーケンス図である。
【図７】メールキーが押下された場合の携帯電話機１０における例外処理を示すシーケンス図である。
【図８】携帯電話機１０における通常処理を示すシーケンス図である。
【図９】ＴＯＰメニューからの画面遷移を示す説明図である。
【図１０】メールニューからの画面遷移を示す説明図である。
【図１１】本実施形態における画面遷移の例を示した説明図である。
【符号の説明】
【００７０】
１０…携帯電話機、２０…メインシステム、２１…キー入力部、２２…ＵＩコンテンツ格納部、２３…メインシステム制御部、２３１…判断部、２３２…通知部、２３３…例外処理部、２４…表示部、３０…ＵＩエンジン、３１…コンテンツ制御部、３２…格納部、３２１…ページ状態記憶部、３２２…例外処理記憶部、３３…コンテンツ描画部、３５…エンジン制御部、５１…メインシステム制御モジュール、５２…ＵＩエンジン制御モジュール。
【技術分野】
【０００１】
本発明は、コンテンツを表示することのできる情報処理装置および画面表示方法に関する。
【背景技術】
【０００２】
移動機におけるメニューなどの表示画面（以下、ＵＩ（User Interface）コンテンツとする）はコンテンツ化されており、ユーザの嗜好に沿ったカスタマイズを行うことができるシステムが構築されている。例えば、特開２００５−３５２９４３号（特許文献１）には、メニューなどの表示画面をユーザの使用形態を反映させてカスタマイズすることができる情報端末が記載されている。また、特開２００６−３１１４９８号公報（特許文献２）には、特定のイベントが発生すると移動体のディスプレイを変化させる手段が開示されており、また端末機において、移動体（アイコンに相当）を魚のキャラクター化し、そのキャラクター化したイメージをディスプレイすることが記載されている。
【特許文献１】特開２００５−３５２９４３号公報
【特許文献２】特開２００６−３１１４９８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このＵＩコンテンツの表現力に自由度をもたせるために、ＵＩコンテンツはウエブサイトからダウンロードすることが考えられている。また、基本的には、移動機のキーイベントについては、ＵＩコンテンツを制御するＵＩエンジン部が取得して、それに対する表示動作についても、ＵＩコンテンツにしたがってＵＩエンジン部が決定権を持つことが考えられている。例えば、あるキーイベントが発生すると、ＵＩエンジン部がキー内容を取得し、ＵＩコンテンツにしたがってどのようなコンテンツを表示するかを判断し、表示することが考えられている。
【０００４】
しかしながら、ＵＩエンジン部およびその制御を行うシステム部のある特定の状態においては、例外処理的に、キーイベントに対する表示動作の決定権をシステム部がもつ必要がある。例えば、あるキーイベントに対して表示される表示画面を統一させたい場合がある。ＵＩエンジン部におけるＵＩコンテンツの描画処理は、ＵＩコンテンツにしたがった処理を行うことを前提とするものであることから、ユーザまたはＵＩコンテンツの製作者が、キーイベントに対するコンテンツの描画を適宜変えることができる。したがって、ＵＩコンテンツのカスタマイズを前提とするＵＩエンジン部に操作の統一対象となるキーイベントの決定権を渡すことは妥当ではない。
【０００５】
一方、システム部が常にＵＩエンジン部におけるＵＩコンテンツの表示状態を把握し、その表示状態に応じて処理を分けることで解決可能であるが、ＵＩコンテンツの状態変化のたびに、ＵＩエンジン部がシステム部に状態通知を行うことは、ＵＩコンテンツの表示速度を著しく低下させる可能性がある。例えば、ＵＩエンジン部におけるページ遷移などＵＩコンテンツの状態変化の度に、ＵＩエンジン部からシステム部に状態通知が行われ、また、システム部では、スタックされた状態通知に応じて状態判定を行う処理時間が消費される。
【０００６】
そこで、上述の課題を解決するために、本発明は、ＵＩコンテンツの状態をシステム部に通知することなく、様々な機種における操作性を統一させることができる情報処理装置および画面表示方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述の課題を解決するために、本発明の情報処理装置は、装置の制御を行うシステム部と、前記システム部による制御のもと、コンテンツの描画処理を行うコンテンツエンジン部と、を備える情報処理装置において、前記システム部は、ユーザからキー入力を受け付けるキー入力手段と、前記キー入力手段により受け付けられたキー入力による画面表示が例外処理要求を必要とするか否かを判断する判断手段と、前記判断手段により例外処理要求が必要であると判断されると、前記コンテンツエンジン部にコンテンツの再生要求および例外処理要求の内容を通知し、例外処理要求が必要でないと判断されると、例外処理要求の通知を行わずに、コンテンツの再生要求を行う例外要求通知手段と、前記コンテンツエンジン部において描画処理されたコンテンツを表示する表示手段と、前記コンテンツエンジン部から例外処理発生の通知を受けると、当該通知にしたがった表示内容を前記表示手段に出力する例外処理手段と、を備え、前記コンテンツエンジン部は、前記例外要求通知手段により例外処理要求が通知されると、当該例外処理要求を記憶する記憶手段と、前記記憶手段に例外処理内容が記憶された後に、前記キー入力手段によるキー入力が前記記憶手段に記憶されている例外処理要求に一致する場合には、例外処理発生の通知を前記システム部に行う例外処理通知手段と、前記記憶手段に例外処理要求が記憶された後に、前記キー入力手段によるキー入力が前記記憶手段に記憶されている例外処理要求に一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを前記表示手段に出力する描画処理手段と、を備えている。
【０００８】
この発明によれば、システム部において、受け付けられたキー入力による画面表示が例外処理要求を必要とすると判断されると、コンテンツの再生要求および例外処理要求の内容をコンテンツエンジン部に通知し、例外処理要求が必要でないと判断されると、例外処理要求の通知を行わずに、コンテンツの再生要求を行う。
【０００９】
一方、コンテンツエンジン部において、システム部から例外処理要求が通知されると、当該例外処理要求を記憶する。そして、その後、システム部において受け付けられたキー入力が、記憶されている例外処理要求に一致する場合には、例外処理発生の通知をシステム部に行い、通知にしたがった内容を表示させる。また、システム部において受け付けられたキー入力が、記憶されている例外処理要求に一致しない場合には、キー入力にしたがった描画処理を行い、描画処理したコンテンツを表示させる。
【００１０】
これにより、コンテンツエンジン部において例外処理の発生を判断し、システム部において例外処理を実行することができ、ユーザの操作性を統一させることを可能とさせる。
【００１１】
また、本発明の情報処理装置において、例外処理要求は、入力されたキーを示すキー種別および表示されているページを示すページ状態を含み、前記コンテンツエンジン部における前記例外処理通知手段は、現に表示されているページのページ状態および前記キーイベント通知手段により通知されたキー入力のキー種別が、前記記憶手段に記憶されている例外処理要求の内容と一致する場合には、例外処理発生の通知を前記システム部に行い、一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを前記表示手段に出力することが好ましい。
【００１２】
この発明によれば、現に表示されているページのページ状態および通知されたキー入力のキー種別が、予め記憶されている例外処理要求の内容と一致しているか否かを判断することができ、システム部に例外処理の発生の通知を適切に行うことができる。
【００１３】
ところで、本発明は、上記のように情報処理装置の発明として記述できる他に、以下のように、画面表示方法の発明としても記述することができる。これらはカテゴリーが異なるだけで、実質的に同一の発明であり、同様の作用・効果を奏する。
【００１４】
すなわち、本発明の画面表示方法は、装置の制御を行うシステム部と、前記システム部による制御のもと、コンテンツの描画処理を行うコンテンツエンジン部と、を備える情報処理装置の画面表示方法において、前記システム部は、ユーザからキー入力を受け付けるキー入力ステップと、前記キー入力ステップにより受け付けられたキー入力による画面表示が例外処理要求を必要とするか否かを判断する判断ステップと、前記判断ステップにより例外処理要求が必要であると判断されると、前記コンテンツエンジン部にコンテンツの再生要求および例外処理要求の内容を通知し、例外処理要求でないと判断されると、例外処理要求の通知を行わずに、コンテンツの再生要求を行う例外処理要求通知ステップと、を備え、前記コンテンツエンジン部は、前記例外要求通知ステップにより例外処理要求が通知されると、当該例外処理要求を記憶する記憶ステップと、前記記憶ステップに例外処理内容が記憶された後に、前記キー入力ステップによるキー入力が予め記憶されている例外処理要求に一致する場合には、例外処理発生の通知を前記システム部に行う例外処理通知ステップと、例外処理要求が記憶された後に、前記キー入力ステップによるキー入力が予め記憶されている例外処理要求に一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを表示させる描画処理ステップと、を備え、前記システム部は、前記コンテンツエンジン部の描画処理ステップにおいて処理されたコンテンツを表示する表示ステップと、前記コンテンツエンジン部の前記例外処理通知ステップにおいて処理された例外処理発生の通知を受けると、当該通知にしたがった表示内容を表示させる例外処理ステップと、
をさらに備えている。
【発明の効果】
【００１５】
本発明によれば、コンテンツエンジン部において例外処理の発生を判断し、システム部において例外処理を実行することができ、ユーザの操作性を統一させることを可能とさせる。
【発明を実施するための最良の形態】
【００１６】
本発明は、一実施形態のために示された添付図面を参照して以下の詳細な記述を考慮することによって容易に理解することができる。引き続いて、添付図面を参照しながら本発明の実施形態を説明する。可能な場合には、同一の部分には同一の符号を付して、重複する説明を省略する。
【００１７】
図１は、本実施形態の携帯電話機１０の機能ブロックを示すブロック図である。図１に示すように、携帯電話機１０は、メインシステム２０（システム部）およびＵＩエンジン３０（コンテンツエンジン部）を含んで構成されている。さらに、メインシステム２０は、キー入力部２１（キー入力手段）、ＵＩコンテンツ格納部２２、メインシステム制御部２３、および表示部２４（表示手段）を含んで構成されており、ＵＩエンジン３０は、ＵＩコンテンツ制御部３１、格納部３２、ＵＩコンテンツ描画部３３を含んで構成されている。この携帯電話機１０は、図２に示されているハードウェアから構成されている。
【００１８】
図２は、携帯電話機１０のハードウェア構成図である。図１に示される携帯電話機１０は、物理的には、図２に示すように、ＣＰＵ１０１、主記憶部１０２、補助記憶部１０３、通信制御部１０４、表示部１０５、および操作部１０６などを含むコンピュータシステムとして構成されている。図１において説明した各機能は、図２に示すＣＰＵ１０１、主記憶部１０２等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ１０１の制御のもとで通信制御部１０４、表示部１０５、操作部１０６を動作させるとともに、主記憶部１０２、補助記憶装置１０３におけるデータの読み出し及び書き込みを行うことで実現される。
【００１９】
なお、この携帯電話機１０におけるモジュール構成は図３に示す構成からなる。図３は、本実施形態の携帯電話機１０に搭載されている各モジュールのモジュール構成図である。図３に示されているように、ＯＳ（Operating System）５０の上にミドルウエアであるメインシステム制御モジュール（アプリケーション）５１およびＵＩエンジン制御モジュール５２が動作し、メインシステム制御モジュール５１とＵＩエンジン制御モジュール５２とは、相互に制御指示の送受を行うことを可能にしている。
【００２０】
このＵＩエンジン制御モジュール５２は、キャリア事業者がメーカに対して提供するモジュールの一つであって、コンテンツメーカが製作したメニュー画面など、ダウンロードされたコンテンツの描画表現を可能に構成されたモジュールである。この描画表現は、当該コンテンツに記述されているスクリプトにしたがって表現されるものである。本実施形態においては、コンテンツメーカ独自の表現を可能にするコンテンツであって、メニュー画面を構成するためのコンテンツの描画処理を可能にするように構成されてものである。
【００２１】
このコンテンツがメニュー画面を構成するためのものである場合には、コンテンツメーカによって、その操作内容は異なっている場合がある。一方で、メインシステム制御モジュール５１は、例えば、移動通信網のキャリア事業者により定められた基本設計に基づいて構成されたものであり、メインシステム２０は同一のキャリア事業者から提供されている端末であればメーカが異なってもその操作性などの基本思想はほぼ同一のものとなるよう構成されている。
【００２２】
また、メインシステム制御モジュール５１は、メインシステム制御部２３として機能するのであって、ＯＳ５０を介してキー入力部２１のキー入力の受付を判断し、また、ＯＳ５０を介して表示部２４に対して表示処理を行うことができる。また、ＵＩエンジン制御モジュール５２は、ＵＩエンジン制御部３５として機能するものであって、ハードウェアとして構成されている格納部３２（例えば、主記憶部１０２または補助記憶部１０３内にその格納領域が形成されている）に対して各種情報の格納処理または読み出し処理を行う。以下、図１に示す機能ブロックに基づいて、各機能ブロックを説明する。
【００２３】
メインシステム２０は、装置全体を制御する制御モジュールであって、キー入力部２１（操作部１０６に相当）、メインシステム制御部２３（ＣＰＵ１０１に相当）、および表示部２４（表示部１０５に相当）から構成されている。
【００２４】
キー入力部２１は、ユーザからの操作を受け付ける部分であり、例えば、本実施形態においては少なくとも、メニュー画面を表示することを指示するためのメニューキー、メールメニュー画面を表示するためのメールキー、ブラウザメニュー画面を表示するためのインターネットキー、入力した文字を削除しまたは画面を一つ前に戻るためのクリアキー、および０を含んだ英数字のキーを含んでいる。
【００２５】
ＵＩコンテンツ格納部２２は、メニュー画面を構成するためのフレームデータ、アイコンデータおよびメニュー画面における操作ルールが記述されているスクリプトデータなどのコンテンツデータを格納する部分である。このＵＩコンテンツ格納部２２に格納されているフレームデータ、アイコンデータおよびスクリプトデータは、予め格納されたものでもよいし、ダウンロードされることにより取得されるものでもよい。
【００２６】
メインシステム制御部２３は、判断部２３１（判断手段）、通知部２３２（例外要求通知手段）および例外処理部２３３（例外処理手段）を備える。判断部２３１は、キー入力部２１において受け付けられたキー操作内容に基づいて、例外処理要求が必要であるか否かを判断する部分であり、例えば、メインシステム制御部２３は、キー入力部２１において、メニューキー、メールキー、またはインターネットキーの入力の受け付けがなされか否かを判断し、例外処理の要求が必要であるか否かを判断する。
【００２７】
ここで判断部２３１が、メニューキー、メールキー、またはインターネットキーのいずれかの入力の受付がなされ、例外処理の要求が必要であると判断すると、通知部２３２は、その入力に対応したＴＯＰメニュー画面、メールメニュー画面、ブラウザメニュー画面のいずれかの画面を構成するコンテンツデータが記憶されているＵＩコンテンツ格納部２２の領域のアドレスデータ、そのコンテンツデータの再生要求、および例外処理要求をＵＩエンジン３０に出力する。なお、通知部２３２は、アドレスデータを出力する代わりに、コンテンツデータそのものを出力するようにしてもよい。
【００２８】
また、判断部２３１は、上述のように予め定められた例外処理要求が必要ではないキー操作がキー入力部２１により受け付けられたと判断した場合には、通知部２３２はその入力に対応したコンテンツデータの再生要求をＵＩエンジン３０に出力する。この再生要求通知には、ＵＩコンテンツ格納部２２に記憶されているコンテンツデータの記憶領域を示すアドレスデータが含まれている。
【００２９】
例外処理部２３３は、通知部２３２がキーイベント通知を行った後に、ＵＩエンジン３０から例外処理発生通知とともに、上述キー入力に応じた動作要求を受けると、当該動作要求に応じた処理を実行する。例えば、メインシステム制御部２３は、メニューキーの押下によりＴＯＰメニュー画面を表示し、その表示時に、キー入力部２１において０キーが入力された場合には、ＵＩエンジン３０から例外処理発生通知とともに自局番号の表示要求を受信し、自局番号を表示部２４に表示させる。
なお、メインシステム制御部２３は、キー処理部（図示せず）および状態格納部（図示せず）をさらに備えており、この状態格納部は、ＵＩエンジン３０（ＵＩコンテンツ制御部３１）からＵＩコンテンツ再生要求に応じた応答信号を受けると、ＵＩコンテンツ再生中の旨を記憶する。メインシステム部２３は、キー入力があったとき、この状態格納部に記憶されている情報に基づいて、通知部２３２がＵＩコンテンツを利用するためのコンテンツ再生要求を行うか、若しくはキーイベント通知を行うか、またはキー処理部を用いた、ＵＩコンテンツを利用しないキー入力処理を行うかを判断する。状態格納部にＵＩコンテンツが再生中である旨の情報が記憶されている場合には、通知部２３２はキーイベント通知を行うよう処理する。状態格納部に当該情報が記憶されていない場合には、キー処理部は受け付けたキー入力に対応した処理（ＵＩコンテンツの再生要求、またはキー処理部によるキー処理）を実行する。
【００３０】
表示部２４は、ＵＩエンジン３０において描画処理されたメニュー画面などのコンテンツまたはメインシステム２０において処理されたデータを表示する部分である。
【００３１】
ＵＩエンジン３０は、ＵＩコンテンツ制御部３１（例外処理通知手段）、格納部３２（記憶手段）、およびＵＩコンテンツ描画部３３（描画処理手段）を含んで構成されている。
【００３２】
ＵＩコンテンツ制御部３１は、メインシステム２０から送信されたＵＩコンテンツ再生要求およびそのアドレスデータを受信すると、ＵＩコンテンツ再生要求およびアドレスデータにしたがって、コンテンツデータをＵＩコンテンツ格納部２２から読み出し、読み出したコンテンツデータをＵＩコンテンツ描画部３３に出力し、描画処理をさせる。また、ＵＩコンテンツ描画部３３から描画要求に対する応答を受けると、当該ＵＩコンテンツ再生要求に基づいたページ状態を記憶するようページ状態を示す情報をページ状態記憶部３２１に出力する。
【００３３】
また、ＵＩコンテンツ制御部３１は、メインシステム２０から例外処理要求を受信すると、例外処理要求に含まれている情報を例外処理記憶部３２２に出力し、記憶させる。例外処理要求には、ページ状態、キー種別、および動作種別が含まれている。ここで具体例を、図を用いて説明する。図４は、例外処理記憶部３２２に記憶されている例外処理要求一覧を示す説明図である。図４に示されているように、メニューキーが押下された場合、ページ状態として、ＴＯＰメニューページ、キー種別として、０キー、動作種別として、自局番号の表示要求がメインシステム２０から送信され、例外処理記憶部３２２にはこれら情報が記憶される。なお、説明の便宜上、メニューキーが押下された場合、メールキーが押下され場合の両方を記憶されていることにしているが、通常いずれか一方のみが記憶され、または両方が記憶されていない状態である。
【００３４】
また、ＵＩコンテンツ制御部３１は、メインシステム制御部２３からキーイベント通知を受信すると、そのキーイベント通知に含まれているキー内容が、例外処理記憶部３２２に記憶されているキー種別に一致するか否かを、まず判断する。一致すると判断した場合には、つぎにページ状態記憶部３２１に記憶されているページ状態と例外処理記憶部３２２に記憶されているページ状態と一致するか否かを判断する。ここで、ページ状態も一致すると判断した場合には、ＵＩコンテンツ制御部３１は、例外処理発生通知をメインシステム２０に出力する。この例外処理発生通知には、例外処理発生の旨および例外処理の内容（例えば、自局番号表示をする旨）が含まれている。
【００３５】
なお、キー種別およびページ状態の一致・不一致の判断を両方行うとともにその判断結果をフラグで管理し、キー種別、ページ状態いずれのフラグも立っている状態である場合に、例外処理発生通知を行うようにしてもよい。このようにフラグで管理することにより、判定の種類が増えた場合、例えば入力文字列などの一致を判断したい場合を追加した場合にも、容易に設計変更を行うことを可能にする。
【００３６】
また、ＵＩコンテンツ制御部３１は、当該ＵＩコンテンツの再生が終了された場合には、例外処理記憶部３２２に記憶されている例外処理要求情報を消去する処理を行うことが好ましい。
【００３７】
格納部３２は、ページ状態記憶部３２１および例外処理記憶部３２２から構成されており、それぞれ現在表示しているページを示すページ状態情報、メインシステム２０から出力された例外処理要求情報（キー種別、ページ状態、動作種別）を記憶する。
【００３８】
ＵＩコンテンツ描画部３３は、ＵＩコンテンツ制御部３１からの指示により描画処理を行う部分であり、例えばメニュー画面を生成する部分である。
【００３９】
つぎに、このように構成された携帯電話機１０の動作について、図５および図６を用いて説明する。図５は、メニューキーが押下された場合の例外処理を実行する携帯電話機１０のシーケンス図であり、図６は、通常処理を実行する携帯電話機１０のシーケンス図である。
【００４０】
まず、図５で示される例外処理が行われるときの携帯電話機１０のシーケンス図について説明する。キー入力部２１においてユーザによりメニューキーが押下されると（Ｓ１０１）、その旨がメインシステム制御部２３に出力される（Ｓ１０２）。メインシステム制御部２３では、判断部２３１により出力されたキー入力による表示画面が例外処理要求を必要とするか否かが判断される（Ｓ１０３）。ここでは、判断処理後、まずはメインシステム制御部２３の通知部２３２により、ＵＩコンテンツ再生要求およびコンテンツデータのアドレスデータが、ＵＩエンジン３０に出力される（Ｓ１０４、Ｓ１０５）。また、キー入力はメニューキーの入力であり、例外処理要求が必要であるため、例外処理要求が通知部２３２によりＵＩエンジン３０に出力される（Ｓ１０６）。
【００４１】
ＵＩエンジン３０では、入力された例外処理要求が、ＵＩコンテンツ制御部３１により例外処理記憶部３２２に出力され、記憶される（Ｓ１０７）。また、ＵＩコンテンツ再生要求およびアドレスデータにしたがって、ＵＩコンテンツ制御部３１によりＵＩコンテンツデータがＵＩコンテンツ格納部２２から読み出され（図示せず）、読み出されたコンテンツデータはＵＩコンテンツ描画部３３に出力され、ＵＩコンテンツ描画部３３においてＵＩコンテンツデータに基づいてＵＩコンテンツ、すなわちここではメニュー画面が生成され（Ｓ１０８）、その応答信号がＵＩコンテンツ制御部３１、メインシステム制御部２３に出力される（Ｓ１０９）。ＵＩコンテンツ制御部３１では、この応答信号を受けると、ページ状態記憶部３２１に出力し、ページ状態情報を記憶させる（Ｓ１１０）。ここでは、ページ状態情報として“ＴＯＰメニューページ”が記憶される。一方で、ＵＩコンテンツ制御部３１からメインシステム制御部２０が応答信号を受けると、メインシステム制御部２０に備えられている状態格納部（図示せず）にＵＩコンテンツが再生中である旨が記憶される。
【００４２】
ＵＩコンテンツ描画部３３により生成されたメニュー画面データは、メインシステム２０における表示部２４に出力され（Ｓ１１１）、ＴＯＰメニュー画面が表示部２４に表示される（Ｓ１１２）。
【００４３】
つぎに、ＴＯＰメニュー画面を見ながらユーザが操作するときの処理について、図５を用いて引き続き説明する。ここでは、０キーが押下された場合について説明している。表示部２４におけるＴＯＰメニュー画面表示後、ユーザによる押下操作により０キーが押下されたことがキー入力部２１に受け付けられ（Ｓ１１３）、０キーが押下されたことがキーイベント通知としてメインシステム制御部２３を介してＵＩコンテンツ制御部３１に出力される（Ｓ１１４）。なお、メインシステム制御部２３では、通知部２３２は、キー入力が行われると、ＵＩコンテンツが再生中である旨を状態格納部が記憶していることを確認してからキーイベント通知をＵＩコンテンツ制御部３１に出力する。ＵＩコンテンツが再生中である旨を状態格納部が記憶していない場合には、通知部２３２の処理は行われることなく、メインシステム制御部２３内においてキー入力に応じた処理、またはそのキー入力がＵＩコンテンツの再生要求である場合には当該再生要求が行われる。
【００４４】
ＵＩエンジン３０では、ＵＩコンテンツ制御部３１によりキーイベント通知が入力されると、例外処理記億部３２２に記憶されている例外処理要求と、キーイベント通知により通知されたキーとを照合し、キー種別判断として、例外処理要求と一致することを確認する（Ｓ１１５）。そして、確認後、ページ状態判断として、現在のＵＩコンテンツ制御部３１において把握しているページ状態、すなわちページ状態記憶部３２１に記憶されているページ状態情報と例外処理記憶部３２２に記憶されているページ状態情報とを比較し、一致していることを確認する（Ｓ１１６）。すなわち、例外処理の要求としてＴＯＰメニューページが記憶され、ページ状態としてＳ１１０でＴＯＰメニューページが記憶されており、ページ状態と例外処理の要求とが一致していることを確認する。
【００４５】
確認後、ＵＩコンテンツ制御部３１によりこのキーイベント通知は例外処理要求であると判断され、ＵＩコンテンツ制御部３１により例外処理発生通知およびその動作内容である自局番号の表示要求がメインシステム２０に出力される（Ｓ１１７）。
【００４６】
メインシステム２０では、例外処理部２３３により例外処理に基づいた自局番号表示処理が行われ、表示部２４には自局番号が表示される（Ｓ１１８）。
【００４７】
以上の通り、メインシステム２０において例外処理を行うときの条件をＵＩエンジン３０に通知し、ＵＩエンジン３０ではその条件を満たした場合に、メインシステム２０に通知し、メインシステム２０において例外処理にしたがった処理、ここでは自局番号の表示を行うことができる。よって、例外処理時には、ＵＩコンテンツに依存することなく、メインシステム２０において例外処理を実行することができ、操作の統一性を簡単に図ることができる。
【００４８】
つぎに、図６に示される、例外処理を行わない通常処理、すなわち、キーイベントをＵＩエンジン３０側でコンテンツの生成処理に利用するときの携帯電話機１０の処理のシーケンス図について説明する。
【００４９】
図５におけるＳ１０９でのメニュー画面表示後に、０キー以外のキーが押下されると（例えば１キーなど）、すなわち操作の統一性の対象ではないキーが押下されると（Ｓ２０１）、メインシステム制御部２３に押下されたキー内容を含んだキーイベント通知が出力され、メインシステム制御部２３では、ＵＩコンテンツが再生中であることを確認した後、ＵＩエンジン３０にキーイベント通知として、キー内容が出力される（Ｓ２０２）。ＵＩエンジン３０では、ＵＩコンテンツ制御部３１によりキー種別が判断され（Ｓ２０３）、例外処理の要求ではないと判断されると、ページ状態を確認することなく、描画要求がＵＩコンテンツ描画部３３に出力される（Ｓ２０４）。ここでは、１キーが押下されたため、例外処理記憶部３２２に記憶されている例外処理要求のキー種別（０キー）とは異なっていることが確認され、ページ状態判定が行われることなく、ＵＩコンテンツ描画部３３において、コンテンツ内のスクリプトによる１キーにしたがった描画処理が行われ、表示部２４に出力される。
【００５０】
ＵＩコンテンツ描画部３３から、描画要求に応じた応答がＵＩコンテンツ制御部３１により受信されると、キーイベント通知に応じたページを示すページ状態が、ページ状態記憶部３２１に記憶される（Ｓ２０６）。そして、ＵＩコンテンツ描画部３３によりコンテンツデータが生成され、生成されたコンテンツデータは、表示部２４に出力され（Ｓ２０７）、表示される（Ｓ２０８）。
【００５１】
つぎに、メールキーが押下されたときの例外処理について説明する。図７は、メールキーが押下された場合の携帯電話機１０における例外処理を示すシーケンス図であり、図８は、通常処理を示すシーケンス図である。図７および図８は、図５および図６におけるメニューキーの押下およびそれに対応する処理が、メールキー押下およびそれに対応する処理に置き換わったものである。
【００５２】
すなわち、図７に示すとおり、ユーザによりメールキーが押下され、キー入力部２１により受け付けられると（Ｓ１０１ａ）、その旨がメインシステム制御部２３に出力され（Ｓ１０２）、メインシステム制御部２３において例外処理要求が必要であるか否かが判断される（Ｓ１０３）。以下、図５におけるＳ１０４〜Ｓ１１１に示される処理が実行される。すなわち、ＵＩコンテンツの再生要求、アドレスデータ、例外処理要求が、ＵＩエンジン３０に出力され、ＵＩエンジン３０において例外処理要求を記憶するとともに、メールメニューの描画要求が行われる。そして、描画要求が行われると、メールメニュー画面が表示部２４に表示される（Ｓ１１２ａ）。
【００５３】
その後、クリアキー押下がなされると（Ｓ１１３ａ）、ＵＩコンテンツが表示中であることを確認した後、キーイベントが通知され（Ｓ１１４）、キー種別判断、ページ状態の判断がなされ（Ｓ１１５、Ｓ１１６）、待ち受け画面が表示部２４に表示される（Ｓ１１８ａ）。
【００５４】
同様に、図８に示すように、クリアキー以外が押下されると（Ｓ２０１ａ）、キーイベントが通知され、キー種別判断、描画要求、ページ状態記憶が行われ、その後、キーイベント通知に対応した画面データが出力され、表示される（Ｓ２０２〜Ｓ２０８）。
【００５５】
このような処理により、メニューキーが押下され、メニューキーが表示されている状態でクリアキーが押下されると待ち受け画面に移行するよう、メインシステム側で管理することができ、その操作性を統一させることが容易となる。
【００５６】
このように構成された携帯電話機１０の表示部２４に表示される画面遷移を説明する。図９は、ＴＯＰメニューからの画面遷移を示す説明図である。携帯電話機１０に形成されているメニューキーが押下されると、ＴＯＰメニュー画面６０が表示されるよう構成されている。このＴＯＰメニュー画面６０は、インターネット、メール、アプリ、データＢＯＸなどの各種機能を起動させるための選択画面から構成されている。
【００５７】
ＴＯＰメニュー画面６０において、“２”キーが押下されると、メールメニュー画面６１が表示される。さらに、メールメニュー画面６１において、“１”キーが押下されると、受信ＢＯＸメニュー画面６２が表示される。一方、ＴＯＰメニュー画面６０において、“０”キーが押下されると、自局番号表示画面６３が表示される。従来においては、ＵＩエンジン３０において“０”キーが押下されると自局番号表示する、という設定がなされていないと、自局番号表示ができなかったが、本実施形態においては上述説明したとおりメインシステム２０において、自局番号表示の処理を実行することができる。よって、その操作性の統一性を保障することができる。
【００５８】
図１０は、メールニューからの画面遷移を示す説明図である。メールキーが押下されるとメールメニュー画面７０が表示される。このメールメニュー画面７０において、“１”キーが押下されると、受信ＢＯＸメニュー画面７１が表示される。一方、メールメニュー画面７０が表示されている状態において、クリアキーが押下されると、待受け画面７２が表示される。図９の場合と同様に、メインシステム２０において、待受け画面への遷移を実行することができ、その操作性を統一させることができる。
【００５９】
つぎに、本実施形態の携帯電話機１０の作用効果について説明する。本実施形態の携帯電話機１０のメインシステム２０において、キー入力部２１において受け付けられたキー入力による表示画面が例外処理要求を必要とすると、メインシステム制御部２３（判断部２３１）により判断されると、メインシステム制御部２３（通知部２３２）は、ＵＩコンテンツの再生要求および例外処理要求の内容をＵＩエンジン３０（ＵＩコンテンツ制御部３１）に通知する。また、メインシステム制御部２３（判断部２３１）により例外処理要求が必要でないと判断されると、メインシステム制御部２３（通知部２３２）は例外処理要求の通知を行わずに、ＵＩコンテンツの再生要求をＵＩエンジン３０に通知する。
【００６０】
一方、ＵＩエンジン３０において、メインシステム２０（通知部２３２）から例外処理要求が通知されると、ＵＩコンテンツ制御部３１の制御のもと、格納部３２（例外処理記憶部３２２）が当該例外処理要求を記憶する。そして、その後、メインシステム２０において受け付けられたキー入力が、例外処理記憶部３２２に記憶されている例外処理要求と一致すると、ＵＩコンテンツ制御部３１が判断する場合には、ＵＩコンテンツ制御部３１は例外処理発生の通知をメインシステム２０に行い、メインシステム２０では、通知にしたがった内容を表示部２４に表示させる。
【００６１】
また、メインシステム２０において受け付けられたキー入力が、例外処理記憶部３２２に記憶されている例外処理要求と一致しないと、ＵＩコンテンツ制御部３１が判断する場合には、ＵＩコンテンツ描画部３３に対して、キー入力にしたがった描画処理を行わせ、ＵＩコンテンツ描画部３３は、描画処理したコンテンツを表示部２４に表示させる。
【００６２】
これにより、ＵＩエンジン３０において例外処理の発生を判断し、メインシステム２０において例外処理を実行することができ、ユーザの操作性を統一させることを可能とさせる。
【００６３】
例えば、従来の方法においては、ＵＩエンジン３０側に、操作受け付けに対する処理の決定権があり、異なる機種間では必ずしも同じ操作性を保障していなかったが、本実施形態においては、メールキー押下によるメールメニュー画面を表示しているときに、クリアキーを押下すると、必ず待受け画面となるように設計することができる。以下、その具体例について説明する。図１１は、本実施形態における画面遷移の例を示した説明図である。図１１に示すように、操作例（１）、操作例（２）を対比しつつ説明する。
【００６４】
図１１の操作例（１）は、メニュー画面表示（状態（２））時のＵＩコンテンツ再生要求後に、例外処理要求を通知しない例であり、操作例（２）は、メールメニュー画面表示（状態（３））時のＵＩコンテンツ再生要求後に、例外処理要求を通知するする例である。操作例（１）（２）ともに、状態（１）として待受け画面表示状態が示されている。操作例（１）において、待受け画面表示中に（状態（１））、メニューキーが押下されると（イベント（１））、メニュー画面が表示され（状態（２））、さらに決定キーが押下されると（イベント（２））、メール画面表示状態となる（状態（３））。一方、操作例（２）においては、メールキーが押下されると（イベント（２））、同様にメール画面表示状態となる（状態（３））。
【００６５】
以下、図１１では、操作例（１）（２）ともに、メールメニュー画面表示状態から、決定キー押下（イベント（３））、受信ＢＯＸ画面表示（状態（４））、クリアキー押下（イベント（４））、メール画面表示（状態（５））と遷移している。
【００６６】
メール画面表示状態において、クリアキーが押下されると（イベント（５））、操作例（１）ではメニュー画面表示状態となる（状態（６））。一方、操作例（２）では、クリアキーが押下されると（イベント（５））、例外処理通知による例外処理が実行され待受け画面表示状態となる（状態（６））。従来において、イベント（５）においてクリアキーが押下された場合、その後に遷移する画面はＵＩエンジン３０側に依存していたため、ＵＩコンテンツを製作するメーカの仕様によっては必ずしも待受け画面表示にならない場合もある。
【００６７】
しかしながら、操作性の統一という観点で、操作例（２）のイベント（５）を条件に、メインシステム２０において待受け画面表示をさせることに統一させることで、操作性を向上させることができる。すなわち、機種およびＵＩコンテンツの種別に依存せず、メールキーによるメールメニュー画面が表示された場合に、クリアキーを押下すると、必ず待受け画面表示状態に遷移することができ、その操作性を向上させることができる。なお、操作例（１）においては、メニューキーを起点にメール画面を表示している。この場合には、クリアキーは一つ前の画面に戻ることがユーザの観点から望ましいと考えられている。よって、状態（５）においては同じ操作をしても、その起点が異なっている場合、その後の処理も変わるように制御されている。
【００６８】
また、例外処理記憶部３２２は、少なくとも入力されたキーを示すキー種別および表示されているページを示すページ状態を記憶しておき、ＵＩコンテンツ制御部３１は、現に表示されているページのページ状態および通知されたキー入力のキー種別が、例外処理記憶部３２２に記憶されている例外処理要求の内容と一致しているか否かを判断する。これにより、メインシステム２０に例外処理の発生の通知を適切に行うことができる。
【図面の簡単な説明】
【００６９】
【図１】、本実施形態の携帯電話機１０の機能ブロックを示すブロック図である。
【図２】携帯電話機１０のハードウェア構成図である。
【図３】本実施形態の携帯電話機１０に搭載されている各モジュールのモジュール構成図である。
【図４】例外処理記憶部３２２に記憶されている例外処理要求一覧を示す説明図である。
【図５】メニューキーが押下された場合の例外処理を実行する携帯電話機１０のシーケンス図である。
【図６】通常処理を実行する携帯電話機１０のシーケンス図である。
【図７】メールキーが押下された場合の携帯電話機１０における例外処理を示すシーケンス図である。
【図８】携帯電話機１０における通常処理を示すシーケンス図である。
【図９】ＴＯＰメニューからの画面遷移を示す説明図である。
【図１０】メールニューからの画面遷移を示す説明図である。
【図１１】本実施形態における画面遷移の例を示した説明図である。
【符号の説明】
【００７０】
１０…携帯電話機、２０…メインシステム、２１…キー入力部、２２…ＵＩコンテンツ格納部、２３…メインシステム制御部、２３１…判断部、２３２…通知部、２３３…例外処理部、２４…表示部、３０…ＵＩエンジン、３１…コンテンツ制御部、３２…格納部、３２１…ページ状態記憶部、３２２…例外処理記憶部、３３…コンテンツ描画部、３５…エンジン制御部、５１…メインシステム制御モジュール、５２…ＵＩエンジン制御モジュール。
【特許請求の範囲】
【請求項１】
装置の制御を行うシステム部と、前記システム部による制御のもと、コンテンツの描画処理を行うコンテンツエンジン部と、を備える情報処理装置において、
前記システム部は、
ユーザからキー入力を受け付けるキー入力手段と、
前記キー入力手段により受け付けられたキー入力による画面表示が例外処理要求を必要とするか否かを判断する判断手段と、
前記判断手段により例外処理要求が必要であると判断されると、前記コンテンツエンジン部にコンテンツの再生要求および例外処理要求の内容を通知し、例外処理要求が必要でないと判断されると、例外処理要求の通知を行わずに、コンテンツの再生要求を行う例外要求通知手段と、
前記コンテンツエンジン部において描画処理されたコンテンツを表示する表示手段と、
前記コンテンツエンジン部から例外処理発生の通知を受けると、当該通知にしたがった表示内容を前記表示手段に出力する例外処理手段と、
を備え、
前記コンテンツエンジン部は、
前記例外要求通知手段により例外処理要求が通知されると、当該例外処理要求を記憶する記憶手段と、
前記記憶手段に例外処理内容が記憶された後に、前記キー入力手段によるキー入力が前記記憶手段に記憶されている例外処理要求に一致する場合には、例外処理発生の通知を前記システム部に行う例外処理通知手段と、
前記記憶手段に例外処理要求が記憶された後に、前記キー入力手段によるキー入力が前記記憶手段に記憶されている例外処理要求に一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを前記表示手段に出力する描画処理手段と、
を備える情報処理装置。
【請求項２】
前記例外処理要求は、入力されたキーを示すキー種別および表示されているページを示すページ状態を含み、
前記コンテンツエンジン部における前記例外処理通知手段は、現に表示されているページのページ状態および前記キー入力手段によるキー入力のキー種別が、前記記憶手段に記憶されている例外処理要求の内容と一致する場合には、例外処理発生の通知を前記システム部に行い、一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを前記表示手段に出力することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
装置の制御を行うシステム部と、前記システム部による制御のもと、コンテンツの描画処理を行うコンテンツエンジン部と、を備える情報処理装置の画面表示方法において、
前記システム部は、
ユーザからキー入力を受け付けるキー入力ステップと、
前記キー入力ステップにより受け付けられたキー入力による画面表示が例外処理要求を必要とするか否かを判断する判断ステップと、
前記判断ステップにより例外処理要求が必要であると判断されると、前記コンテンツエンジン部にコンテンツの再生要求および例外処理要求の内容を通知し、例外処理要求でないと判断されると、例外処理要求の通知を行わずに、コンテンツの再生要求を行う例外処理要求通知ステップと、
を備え、
前記コンテンツエンジン部は、
前記例外要求通知ステップにより例外処理要求が通知されると、当該例外処理要求を記憶する記憶ステップと、
前記記憶ステップに例外処理内容が記憶された後に、前記キー入力ステップによるキー入力が予め記憶されている例外処理要求に一致する場合には、例外処理発生の通知を前記システム部に行う例外処理通知ステップと、
例外処理要求が記憶された後に、前記キー入力ステップによるキー入力が予め記憶されている例外処理要求に一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを表示させる描画処理ステップと、
を備え、
前記システム部は、
前記コンテンツエンジン部の描画処理ステップにおいて処理されたコンテンツを表示する表示ステップと、
前記コンテンツエンジン部の前記例外処理通知ステップにおいて処理された例外処理発生の通知を受けると、当該通知にしたがった表示内容を表示させる例外処理ステップと、
をさらに備えることを特徴とする画面表示方法。
【請求項１】
装置の制御を行うシステム部と、前記システム部による制御のもと、コンテンツの描画処理を行うコンテンツエンジン部と、を備える情報処理装置において、
前記システム部は、
ユーザからキー入力を受け付けるキー入力手段と、
前記キー入力手段により受け付けられたキー入力による画面表示が例外処理要求を必要とするか否かを判断する判断手段と、
前記判断手段により例外処理要求が必要であると判断されると、前記コンテンツエンジン部にコンテンツの再生要求および例外処理要求の内容を通知し、例外処理要求が必要でないと判断されると、例外処理要求の通知を行わずに、コンテンツの再生要求を行う例外要求通知手段と、
前記コンテンツエンジン部において描画処理されたコンテンツを表示する表示手段と、
前記コンテンツエンジン部から例外処理発生の通知を受けると、当該通知にしたがった表示内容を前記表示手段に出力する例外処理手段と、
を備え、
前記コンテンツエンジン部は、
前記例外要求通知手段により例外処理要求が通知されると、当該例外処理要求を記憶する記憶手段と、
前記記憶手段に例外処理内容が記憶された後に、前記キー入力手段によるキー入力が前記記憶手段に記憶されている例外処理要求に一致する場合には、例外処理発生の通知を前記システム部に行う例外処理通知手段と、
前記記憶手段に例外処理要求が記憶された後に、前記キー入力手段によるキー入力が前記記憶手段に記憶されている例外処理要求に一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを前記表示手段に出力する描画処理手段と、
を備える情報処理装置。
【請求項２】
前記例外処理要求は、入力されたキーを示すキー種別および表示されているページを示すページ状態を含み、
前記コンテンツエンジン部における前記例外処理通知手段は、現に表示されているページのページ状態および前記キー入力手段によるキー入力のキー種別が、前記記憶手段に記憶されている例外処理要求の内容と一致する場合には、例外処理発生の通知を前記システム部に行い、一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを前記表示手段に出力することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
装置の制御を行うシステム部と、前記システム部による制御のもと、コンテンツの描画処理を行うコンテンツエンジン部と、を備える情報処理装置の画面表示方法において、
前記システム部は、
ユーザからキー入力を受け付けるキー入力ステップと、
前記キー入力ステップにより受け付けられたキー入力による画面表示が例外処理要求を必要とするか否かを判断する判断ステップと、
前記判断ステップにより例外処理要求が必要であると判断されると、前記コンテンツエンジン部にコンテンツの再生要求および例外処理要求の内容を通知し、例外処理要求でないと判断されると、例外処理要求の通知を行わずに、コンテンツの再生要求を行う例外処理要求通知ステップと、
を備え、
前記コンテンツエンジン部は、
前記例外要求通知ステップにより例外処理要求が通知されると、当該例外処理要求を記憶する記憶ステップと、
前記記憶ステップに例外処理内容が記憶された後に、前記キー入力ステップによるキー入力が予め記憶されている例外処理要求に一致する場合には、例外処理発生の通知を前記システム部に行う例外処理通知ステップと、
例外処理要求が記憶された後に、前記キー入力ステップによるキー入力が予め記憶されている例外処理要求に一致しない場合には、前記キー入力にしたがった描画処理を行い、描画処理したコンテンツを表示させる描画処理ステップと、
を備え、
前記システム部は、
前記コンテンツエンジン部の描画処理ステップにおいて処理されたコンテンツを表示する表示ステップと、
前記コンテンツエンジン部の前記例外処理通知ステップにおいて処理された例外処理発生の通知を受けると、当該通知にしたがった表示内容を表示させる例外処理ステップと、
をさらに備えることを特徴とする画面表示方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００９−１１８４３１（Ｐ２００９−１１８４３１Ａ）
【公開日】平成２１年５月２８日（２００９．５．２８）
【国際特許分類】
【出願番号】特願２００７−２９２４１９（Ｐ２００７−２９２４１９）
【出願日】平成１９年１１月９日（２００７．１１．９）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【出願人】（５０５０５７６４６）株式会社アクロディア (7)
【Ｆターム（参考）】
【公開日】平成２１年５月２８日（２００９．５．２８）
【国際特許分類】
【出願日】平成１９年１１月９日（２００７．１１．９）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【出願人】（５０５０５７６４６）株式会社アクロディア (7)
【Ｆターム（参考）】
[ Back to top ]