以下、本発明の実施の形態につき図面を参照して説明する。図1は携帯電話機の外観構成を示す図であり、同図(a)は、第1キャビネット1に対して第2キャビネット2をほぼ鉛直に立てた状態を示す側面図、同図(b)は同じ状態での背面図である。
携帯電話機は、第1キャビネット1と第2キャビネット2を備える。第1キャビネット1の正面側には、キー操作部11が設けられている。キー操作部11には、各種の機能モード(カメラ撮影モード、メール送受信モード、インターネットモード)への切替えキー、通話開始キー、通話終了キー、番号・文字入力キーなどの各種キーが配されている。
キー操作部11の背後には、バックライト装置12(以下、「キーバックライト」という)が配されている。キーバックライト12は、光源となるLEDを備え、キー操作部11に光を供給する。キー操作部11の主要なキーは、キーに付された表示の部分が透光性を有するよう構成されており、バックライト12で照らされることにより表示が光る。これにより、ユーザは、周囲が暗くてもキーに付された表示を見ることができる。
第2キャビネット2の正面側には、縦長の矩形状を有する液晶表示パネル21(以下、「メイン表示パネル」という)が配されており、その表示画面が正面に臨んでいる。メイン表示パネル21の背後には、バックライト装置22(以下、「メインバックライト」という)が配されている。メインバックライト22は、光源となるLEDを備え、メイン表示パネル21に光を供給する。
第2キャビネット2の背面側には、液晶表示パネル23(以下、「サブ表示パネル」という)が配されており、その表示画面が背面に臨んでいる。サブ表示パネル23の背後には、バックライト装置24(以下、「サブバックライト」という)が配されている。サブバックライト24は、光源となるLEDを備え、サブ表示パネル23に光を供給する。サブ表示パネル23は、メイン表示パネル21よりも小さなサイズであり、横長の矩形状を有している。サブバックライト24も、サブ表示パネル23に合わせ、メインバックライト22より小さなサイズになっている。
また、第2キャビネット2の内部には、カメラモジュール25が配されており、第2キャビネット2の背面には、カメラモジュール25に対応するレンズ窓26が設けられている。このレンズ窓26から被写体の像がカメラモジュール25に取り込まれる。
第2キャビネットの背面側には、レンズ窓26の下方位置に、多色発光タイプのLED27が配されている。LED駆動回路(後述)による駆動によって、LED27から7色の光が出力され得る。
LED27は、通常、電話や電子メールの着信があったときに、それを知らせる着信音とともに点灯される。さらに、本実施の形態では、後述するスケジュール件数の簡易報知を行う際に、このLED27がスケジュール件数に応じて点灯される。
第2キャビネット2は、ヒンジ部3によって、第1キャビネット1に対し回動可能に連結されている。ヒンジ部3は、第2キャビネット2の連結側端部から左右に延びる一対の回転軸31と、第1キャビネット1の連結側端部に形成され、回転軸31を受ける一対の軸受部32によって構成されている。
第1キャビネット1と第2キャビネット2は、メイン表示パネル21とキー操作部11が向かい合った状態となるように折り畳まれる。よって、折り畳まれた状態(閉じた状態)では、メイン表示パネル21とキー操作部11が外部から隠れた状態となる。
第2キャビネット2は、閉じた状態(図1(a)に一点鎖線で示す)から開き方向に回転されることにより、180度近くまで開くことができる。ヒンジ部3には、第2キャビネット2が最後まで開いた位置と、第1キャビネット1と第2キャビネット2とが略90度となる位置(90度よりやや大きい角度位置)にクリック感を持たせるよう、図示しないクリック機構が備えられている。第2キャビネット2が開くと、メイン表示パネル21とキー操作部11が外部に露出する。
第1キャビネット1と第2キャビネット2には、第2キャビネット2の開閉を検出するための開閉検出部4が配されている。開閉検出部4は、第1キャビネット1側に設けられた閉センサ41と、第2キャビネット2側に設けられた磁石42によって構成されている。磁石42は、第2キャビネット2のヒンジ部3近傍に配されており、閉センサ41は、第2キャビネット2が完全に閉じたときに、磁石42に近接する位置に配されている。
閉センサ41は、たとえば、MRセンサ(磁気抵抗素子)で構成され、磁石42の磁力に反応して検出信号を出力する。第2キャビネット2が閉じた状態から開いた状態となると、閉センサ41からオフ信号が出力される。反対に、第2キャビネット2が開いた状態から閉じた状態になると、閉センサ41からオン信号が出力される。
図2は、携帯電話機の全体構成を示すブロック図である。本実施の形態の携帯電話機は、上述した各構成要素の他、CPU100、映像エンコーダ101、マイク102、音声エンコーダ103、時計回路104、通信モジュール105、メモリ106、バックライト駆動回路107、映像デコーダ108、音声デコーダ109、スピーカ110、LED駆動回路111、振動装置112を備えている。
カメラモジュール25は、撮像レンズ25a、撮像素子25bなどから構成されている。撮像レンズ25aは、被写体の像を撮像素子25b上に結像させる。撮像素子25bは、例えばCCDからなり、取り込んだ画像に応じた撮像信号を生成し、映像エンコーダ101へ出力する。映像エンコーダ101は、撮像素子25bからの撮像信号を、CPU100が処理できるディジタルの撮像信号に変換してCPU100へ出力する。
マイク102は、音声信号を電気信号に変換して音声エンコーダ103へ出力する。音声エンコーダ103は、マイク102からの音声信号を、CPU100が処理できるディジタルの音声信号に変換してCPU100へ出力する。時計回路104は、日時を計測してCPU100へ出力する。
通信モジュール105は、CPU100からの音声信号や画像信号、テキスト信号などを無線信号に変換し、アンテナ105aを介して基地局へ送信する。また、アンテナ105aを介して受信した無線信号を音声信号や画像信号、テキスト信号などに変換してCPU100へ出力する。
メモリ106は、ROMおよびRAMを含む。メモリ106には、CPU100に制御機能を付与するための制御プログラムが記憶されている。また、メモリ106には、カメラモジュール25で撮影した画像データや通信モジュール105を介して外部から取り込んだ画像データ、テキストデータ(メールデータ)などが所定のファイル形式で保存される。
さらに、メモリ106には、図3(a)に示すスケジュールテーブルが記憶されている。スケジュールテーブルには、スケジュールが、予定日、予定時刻、登録日、登録時刻および識別フラグに対応づけて登録されている。
バックライト駆動回路107は、CPU100からの制御信号に応じた電圧信号をメインバックライト22、サブバックライト24およびキーバックライト12に供給する。
映像デコーダ108は、CPU100からの映像信号をメイン表示パネル21およびサブ表示パネル23で表示できるアナログの映像信号に変換し、メイン表示パネル21およびサブ表示パネル23に出力する。
音声デコーダ109は、CPU100からの音声信号をスピーカ110で出力できるアナログの音声信号に変換し、スピーカ110に出力する。スピーカ110は、音声デコーダ109からの音声信号を音声として再生する。
LED駆動回路111は、CPU100から出力される制御信号に従ってLED27を駆動する。振動装置111は、CPU100から出力される駆動信号に応じた振動パターンにて振動する。
CPU100は、カメラモジュール25、マイク102、キー操作11など各部からの入力信号に基づいて、通信モジュール105、映像デコーダ108、音声デコーダ109などの各部に制御信号を出力することにより、各種の機能モードの処理を行う。
本実施の形態の携帯電話機では、機能モードの1つとして、スケジュール管理モードを実行することができる。ユーザはこの機能を利用することによって、自己のスケジュールを管理することができる。
CPU100は、スケジュール管理モードにおいて、キー操作部11を通じて、ユーザからスケジュールおよびそのスケジュールの予定日、予定時刻の登録があると、図3(a)に示す如く、そのスケジュールを、予定日、予定時刻、さらには、登録日、登録時刻、識別フラグに対応づけてメモリ106に記憶させる。
また、CPU100は、通信モジュール105が受信したメールデータの中に、スケジュール、予定日、予定時刻が含まれていた場合、同じく図3(a)に示す如く、そのスケジュールを、予定日、予定時刻、登録日、登録時刻および識別フラグに対応づけてメモリ106に記憶させる。たとえば、スケジュール、予定日、予定時刻の情報は、Vカードのファイル形式により電子メールに添付されて送られてくる。一方、予定管理の機能モードを実行するためのソフトウェアには、Vカードのファイル形式を識別および解析するためのルーチンが含まれており、これによって、CPU100は、スケジュール、予定日、予定時刻の情報を取得することができる。
なお、識別フラグは、スケジュールの取得形態を示すフラグであり、たとえば、ユーザによる登録(当該携帯電話機をキー操作して登録)の場合は、リセット状態(「0」)に設定され、電子メールに基づく登録、即ち他人による登録の場合は、セット状態(「1」)に設定される。
ユーザは、登録したスケジュールを確認する場合、スケジュール管理モードを起動し、スケジュールを確認するための画面を開いて、登録されているスケジュールの件数や内容を確認する。しかしながら、この場合には、スケジュール確認のために複数回の操作が必要となるため、操作に時間を割けないほど多忙な場合には、スケジュール確認を行うのがかなり難しくなる。
そこで、本実施の形態に係る携帯電話機では、携帯電話機を閉じた状態で、ユーザがスケジュール件数等を簡易に確認できるスケジュール簡易報知機能が備えられている。この機能が設定された場合、CPU100は、報知のための所定の条件が満たされると、所定期間(以下、「スケジュール抽出期間」という)内に含まれるスケジュールをメモリ106から抽出し、抽出したスケジュール件数に基づいて、LED駆動回路111に制御信号を出力し、LED27をオン/オフ制御する。ここでは、報知のための条件を、たとえば、ユーザによって予め設定される報知時刻としており、また、スケジュール抽出期間を、たとえば、現在日時を含む0時から24時までの一日(以下、「予定当日」という)としている。
図4は、スケジュール簡易報知機能の制御処理を示すフローチャートである。また、図5および図6は、LEDによるスケジュールの報知形態について説明するための図である。図5(a)は基本となる報知形態を示し、図5(b)および図6(a)、(b)は、そのバリエーションとなる報知形態を示す。なお、図5(a)および図6(a)、(b)に示されている2つの図のうち、下の図は、CPU100からLED駆動回路111に出力される制御信号の出力タイミングを示す図であり、上の図は、この制御信号に基づくLED27の動作状態を示す図である。
以下、スケジュール簡易報知機能の制御処理について、これら図4ないし図6を参照して説明する。
処理が開始されると、CPU100は、報知時刻になったか否かを判断する(S101)。報知時刻は、所定の設定画面においてユーザにより設定される。ユーザは、たとえば、朝6時にその日のスケジュール件数を知りたい場合は、報知時刻を午前6時に設定する。
CPU100は、ステップS101の処理において、報知時刻になったと判断すると、メモリ106のスケジュールテーブルから、予定当日一日分のスケジュールに関するデータ、即ち、予定日、予定時刻、登録日、登録時刻および識別フラグ(図3(b)参照)を抽出する(S102)。
次に、CPU100は、スケジュール件数の報知を開始する旨の報知を行う(S103)。即ち、図5(a)に示すように、CPU100は、緑色用の制御信号を一定時間(たとえば0.5秒)出力する。これにより、LED駆動回路111から緑色用の駆動信号がLED27に出力され、LED27が緑色に点灯する。
その後、CPU100は、スケジュール件数の報知を行う(S104)。即ち、CPU100は、抽出したデータからスケジュール件数を算出し、図5(a)に示すように、算出したスケジュール件数分の赤色用の制御信号を、緑色用の制御信号の直後から一定周期(たとえば0.5秒オン−0.5秒オフ)で出力する。これにより、LED駆動回路111から赤色用の駆動信号がLED27に出力され、LED27がスケジュール件数の回数分だけ赤色に点滅する。たとえば、図3(b)の抽出データのように、予定当日のスケジュール件数が7件であれば、LED27が7回点滅する。なお、LED27は、緑色から赤色に移行する際、連続的に点灯しているが、LED27が緑色に点灯してから赤色に点灯するまでの間に消灯期間(制御信号のオフ期間)が設けられても良い。
次に、CPU100は、スケジュール件数の報知サイクルが所定の設定回数だけ繰り返されたか否かを判断する(S105)。この設定回数は、ユーザによって、報知時刻を設定する際に一緒に設定される。ユーザは、設定回数を所望の回数に設定できる。
CPU100は、報知サイクルが設定回数だけ繰り返されていないと判断すると(S105:NO)、ステップS103の処理に戻り、設定回数になるまで、ステップS103とS104の処理を繰り返す。こうして、LED27が緑色に点灯した後に赤色でスケジュール件数の回数だけ点滅するサイクルが繰り返される。
そして、CPU100は、ステップS105の処理において、スケジュール件数の報知サイクルが設定回数だけ繰り返されたと判断すると、スケジュール件数の報知を終了する旨の報知を行う(S106)。即ち、図5(a)に示すように、CPU100は、緑色用の制御信号を報知サイクルの開始時よりも長い一定時間(たとえば1秒)出力する。これにより、LED駆動回路111から緑色用の駆動信号がLED27に出力され、LED27が緑色に点灯する。こうして、スケジュールの簡易報知が終了する。
なお、本実施の形態では、上述のように、外部から受信した情報にスケジュールが含まれている場合に、スケジュールが予定日等の付加情報に対応づけられて自動的にメモリ106に記憶される。このようなスケジュールは、ユーザが自ら登録したものでないため、ユーザに把握されていないことが多いと考えられる。
そこで、ステップS104の処理によるスケジュールの報知形態は、図5(b)に示すものに変更することもできる。
この報知形態では、CPU100は、抽出したデータからスケジュール件数を算出するとともに、識別フラグを判定し、識別フラグがセットされたスケジュールに対応する制御信号を赤色用の制御信号ではなく、黄色用の制御信号とする。これにより、図5(b)に示すように、LED27は、他人により登録された(自動登録された)スケジュールに対応するタイミングにおいて赤色ではなく黄色で点灯する。たとえば、図3(b)に示すように、予定当日の3つ目のスケジュールと6つ目のスケジュールが他人による登録である場合、LED27の3回目と6回目の点灯が黄色になる。
また、本実施の形態では、ユーザは、報知時刻を所望の時刻に設定できる。上述のように、報知時刻が、その日の最初のスケジュールよりも早い時刻(午前6時)に設定された場合には、報知実行時に完了しているスケジュールはないが、たとえば、その日の午後5時に報知時刻が設定された場合には、報知実行時にすでに予定時刻が経過したスケジュールも出てくる。
そこで、ステップS104の処理によるスケジュール件数の報知形態は、図6(a)、(b)に示すものに変更することもできる。
図6(a)の報知形態では、CPU100は、抽出したデータからスケジュール件数を算出するとともに、予定時刻を報知時刻と比較する。そして、報知時刻より前のスケジュールに対応する制御信号として、赤色用の制御信号ではなく黄色用の制御信号を出力する。これにより、図6(a)に示すように、LED27は、報知時刻より前のスケジュールに対応するタイミングにおいて、赤色ではなく黄色で点灯する。たとえば、報知時刻が午後5時であり、図3(b)に示すように、1件から5件分のスケジュールの予定時刻が報知時刻より早い場合には、報知時刻のタイミングで既に5件のスケジュールの予定時刻が経過しているので、LED27は、5回目までは黄色で点滅し、6回目と7回目は赤色で点滅する。
図6(b)の報知形態とする場合には、まず、ステップS102において、CPU100は、予定当日一日のスケジュールのうち、予定時刻が報知時刻より後のスケジュール項目(予定日、予定時刻、登録日、登録時刻および識別フラグ)を、メモリ106のスケジュールテーブルから抽出する。たとえば、報知時刻が午後5時であれば、図3(b)に示す最後の2件のスケジュールのみが抽出される。
そして、ステップS104の処理において、CPU100は、抽出したデータからスケジュール件数を算出し、図6(b)に示すように、算出したスケジュール件数分の赤色用の制御信号を出力する。これにより、報知時刻から予定当日の終わりまでのスケジュール、即ち、その日に残っているスケジュール件数の回数だけLED27が点滅する。
以上、本実施の形態によれば、ユーザは、LED27の点滅回数(オン/オフ回数)を見ることにより、スケジュール件数を容易に把握することができる。特に、多忙な状況の中、ユーザがスケジュールの確認に十分注力できなくても、LED27が点滅する形態であれば、容易にある程度の感知がなされ得るため、ユーザは、多忙な状況下でも、大まかなスケジュール状態を、容易に把握することができる。
また、図5(b)のような報知形態とすれば、ユーザは、自ら登録していないため事前に把握しにくいスケジュールの存在を容易に把握することができる。
なお、他人によるスケジュールの登録が予定当日になされた場合には、特に事前の把握が難しくなる。そこで、図5(b)の報知形態では、他人により当日登録されたスケジュールをユーザが的確に把握できるよう、識別フラグとともに登録日をもCPU100において判定し、他人によって当日に登録されたスケジュールを、他人によって当日以外の日に登録されたスケジュールに対し、LED27の発光色を変えるようにしても良い。
さらに、図6(a)の報知形態とすれば、ユーザは、予定当日一日のスケジュール全件のうち、何件のスケジュールが遂行状態にあり、今後何件のスケジュールが残っているのかを容易に把握することができる。
さらに、図6(b)の報知形態とすれば、ユーザは、今後予定されているスケジュールの件数のみを把握することができる。
ところで、上記実施の形態では、LED27の点滅周期が一定とされている。このため、上記実施の形態による報知では、スケジュール件数の把握は行えるが、個々のスケジュールの予定時刻までは把握できない。
そこで、各スケジュールの予定時刻が加味された報知形態となるよう、上記実施の形態のステップS104の処理による報知形態を、さらに、以下の変更例1のように変更することができる。
<変更例1>
図7から図9は、変更例1に係るスケジュールの報知形態について説明するための図である。図7は基本となる報知形態を示し、図8および図9は、そのバリエーションとなる報知形態を示す。
この報知形態では、図7(a)に示すように、スケジュール件数を報知するための報知時間Tが一定時間に固定されており、この報知時間Tを一日とみなして、これを12の区間に区分し、1区間tが1日中の2時間の時間帯に対応するように構成されている。たとえば、報知時間Tが12秒とされた場合、2時間の時間帯に対応する区間tは、1秒となる。
CPU100は、ステップS104の処理において、抽出したデータから、個々のスケジュールの予定時刻を判定し、この予定時刻を含む時間帯において制御信号が出力されるよう、制御信号の出力タイミングを決める。
たとえば、図3(b)に示す抽出データの場合には、14時から16時の時間帯、16時から18時の時間帯、20時から22時の時間帯および22時から24時の時間帯にスケジュールの予定時刻が1つ含まれる。よって、図7(a)に示すように、これらの時間帯に対応する区間tにおいて、それぞれ1つの制御信号がCPU100から出力される。また、図3(b)の抽出データでは、10時から12時の時間帯には、2つの予定時刻が含まれる。よって、図7(a)に示すように、この時間帯に対応する区間tにおいて、2つの制御信号がCPU100から出力される。こうして、LED27は、報知時間Tの中で、予定時刻の時間帯に対応したタイミングで点灯することになる。
このように、変更例1に係る報知形態とすれば、各スケジュールに対応するLED27の点灯タイミングが、そのスケジュールの予定時刻を反映したものとなるため、ユーザは、報知時間T(1報知サイクル期間)中のどのあたりで出力がなされたかによって、各スケジュールがどの時間帯に含まれるかを感覚的に把握することができる。また、この出力によって、どの時間帯にスケジュールが密集しており、どの時間帯ではスケジュールが空いているか等の情報を大まかに把握することができる。
なお、制御信号のオン/オフ周期は、図7(b)に示すように、一つの時間帯中に含まれるスケジュールの件数が少ない場合は、基準周期、たとえば、0.5秒周期(0.25秒オン−0.25秒オフ)となる。この場合、上記のように一つ時間帯に対応する区間tが1秒であれば、スケジュール2件まではこの基準周期で制御信号が出力され、LED27が基準周期で点滅する。
一方、同図(c)、(d)に示すように、一つの時間帯中に含まれるスケジュールの件数が多くなると、制御信号のオン/オフ周期が、その件数に合わせて短くなるように、自動的に調整される。よって、スケジュール件数が多くなれば、それに合わせて、LED27の点滅周期が短くなる。
そして、一つの時間帯中に含まれるスケジュールの件数がかなり多くなり、回路的にLED27をオン/オフ駆動することができないほどにまで短いオン/オフ周期になると、制御信号は、同図(e)に示すように、オン/オフされずに、その時間帯に対応する区間tにおいて出力され続ける。これにより、LED27は、その区間tにおいて連続的に点灯する。
変更例1に係る報知形態は、さらに、図8(a)、(b)に示すものに変更することもできる。
図8(a)の報知形態では、CPU100は、抽出したデータからスケジュール件数を算出するとともに、予定時刻を予め設定された参照時刻と比較する。そして、CPU100は、参照時刻、ここでは一日の中間となる正午(午後12時)より前のスケジュールに対応する制御信号として、赤色用の制御信号ではなく、青色用の制御信号をLED駆動回路111に出力する。これにより、図8(a)に示すように、LED27は、正午より前のスケジュールに対応するタイミングにおいて、赤色ではなく青色で点灯する。
図8(b)の報知形態では、CPU100は、予め設定された参照時刻(ここでは正午のタイミング)に黄色の制御信号を出力する。これにより、LED27は、正午の時刻のタイミングにおいて黄色で点灯する。スケジュールに対応するタイミングでは、図7の場合と同様、赤色でLED27が点灯される。
このように、図8(a)、(b)の報知形態とすれば、ユーザは、参照時刻を境にしてそれより前に何件程度のスケジュールがあり、それより後に何件程度のスケジュールがあるかを容易に把握することができる。たとえば、上記のように参照時刻が正午であれば、ユーザは、午前中に何件のスケジュールがあり、午後に何件のスジュールがあるのかを、容易に把握することができる。
変更例1に係る報知形態は、さらに、図9に示すものとすることもできる。
図9の報知形態では、CPU100は、抽出したデータからスケジュール件数を算出するとともに、各スケジュールの予定時刻同士を比較する。そして、CPU100は、互いに重複した予定時刻(いわゆるダブルブッキング)があれば、そのスケジュールに対応する制御信号として、赤色用の制御信号ではなく、青色用の制御信号をLED駆動回路111に出力する。これにより、同図に示すように、LED27は、重複したスケジュールに対応するタイミングにおいて赤色ではなく青色で点灯する。
このような報知形態とすれば、ユーザは、予定時刻が重複するスケジュール(ダブルブッキング)があることを容易に把握することができる。
さらに、変更例1の構成においては、図5(b)および図6に示す上記実施の形態のバリエーションの構成を適用することができる。即ち、変更例1の構成に図5(b)に示す構成を適用することにより、他人により登録されたスケジュールに対応して点灯されるLED27の色をその他のスケジュールに対応して点灯されるLED27の色と異ならせる構成とすることができる。また、変更例1の構成に図6(a)に示す構成を適用することにより、報知時刻の前後でLED27の色を異ならせる構成とすることもできる。さらに、変更例1の構成に図6(b)に示す構成を適用することで、その日のスケジュールのうち、報知時刻より後のスケジュールのみを報知させる構成とすることもできる。
反対に、上記実施の形態に、図8および図9に示す変更例1のバリエーションの構成を適用することもできる。即ち、上記実施の形態に図8に示す構成を適用することにより、参照時刻、たとえば、正午(午後12時)の前後でLED27の色を変えたり、参照時刻を示すLED27の点灯を行ったりする構成とすることができる。また、上記実施の形態に図9に示す構成を適用することにより、予定時刻が重複した場合に、そのスケジュールに対応して点灯されるLED27の色を、他のスケジュールに対応して点灯されるLED27の色と異ならせる構成とすることもできる。
さて、上記実施の形態および変更例1では、スケジュールが抽出される期間を予定当日としているが、以下に示す変更例2のように、スケジュール抽出期間を報知時刻から一定時間とすることもできる。
<変更例2>
図10は、変更例2に係るLEDによるスケジュールの報知形態について説明するための図である。
変更例2では、スケジュール抽出期間が報知時刻から一定時間、たとえば1時間とされているとともに、変更例1と同様、報知時間Tが一定時間に固定されている。図10に示すように、スケジュール抽出期間が1時間とされた場合、この報知時間Tを1時間とみなして、これを12の区間に区分し、1区間tあたり5分の時間帯となるように構成されている。たとえば、報知時間Tが12秒とされた場合、5分の時間帯に対応する区間tは1秒となる。
こうして、同図に示すように、報知時刻から1時間以内に予定時刻があるスケジュールがあれば、そのスケジュールの予定時刻に対応するタイミングでLED27が点灯する。
さらに、上記実施の形態では、ユーザよって予め設定された報知時刻にスケジュール報知が行われる構成である、報知が実行される条件を、以下の変更例3のように変更することができる。
<変更例3>
図11は、変更例3に係るスケジュール簡易報知機能の制御処理を示すフローチャートである。同図(a)は、第2キャビネットが開放される回数(フリップオープンの回数)に基づいて報知を行う例を示し、同図(b)は、キー操作に基づいて報知する例を示す。なお、同図(a)、(b)の処理は、たとえば、予定当日の開始時点に開始される。
同図(a)の例では、処理が開始されると、CPU100は、フリップオープン回数が規定回数Nになったか否かを判断する(S111)。
ユーザが一日の活動を始め、携帯電話機が使用され始めると、第2キャビネット2が開いたり閉じたりされる。そこで、フリップ回数が規定回数Nになれば、ユーザによって携帯電話機が使用されており、その際にスケジュール報知を行えば、それがユーザに知られ得ると判断することができる。
CPU100は、フリップオープン回数が規定回数Nに達したと判断すると(S111:YES)、さらに、第2キャビネット2が閉じられたか(フリップクローズか)否かを判断する(S112)。
通話やメール発信等が終わり、ユーザによって第2キャビネット2が閉じられると(S112:YES)、CPU100は、メモリ106からのスケジュール抽出を行う(S102)。
このような構成とすれば、ユーザが意図的に操作しなくても、ユーザが知り得る適正なタイミングでスケジュール報知を行うことができる。
次に、図11(b)の例では、処理が開始されると、CPU100は、報知のためのキー操作がされたか否かを判断する(S121)。
ユーザは、スケジュール件数を知りたいタイミングで、報知のためのキー操作を行う。たとえば、ユーザは、携帯電話機の側面に設けられたサイドキー(図示せず)を3秒間押す(長押しを行う)。
CPU100は、報知のためのキー操作がなされたと判断すると(S121:YES)、メモリ106からのスケジュール抽出を行う(S102)。
このような構成とすれば、ユーザは、所望のタイミングでスケジュールの確認を行うことができる。
なお、変更例3(図11(a)、(b)の例)の構成において、ステップS102からS106の処理については、上記実施の形態と同様であり、ステップS104の処理では、上記実施の形態や変更例1に示すような報知形態にて、スケジュールが報知される。
なお、ステップS104の処理によりスケジュール報知を行う場合に、報知時刻から直近の一定時間(たとえば、1時間)のスケジュールに対応して点灯されるLED27の色を他の時間のスケジュールに対応して点灯されるLED27の色と異ならせるようにしても良い。また、特に、図11(a)の構成とした場合に、ステップS103の開始報知の処理において、LED27の緑色での点灯とともに音による報知を行うようにすれば、スケジュール報知が開始されることをユーザに確実に知らせることができる。
<その他>
本発明の実施形態は、上記以外にさらに、以下のように種々の変更が可能である。
上記実施の形態では、電話や電子メールの着信時にもLED27が点灯する構成であるため、スケジュール報知時に電話等の着信がある場合がある。そこで、スケジュール報知の途中に、電話等の着信があった場合には、スケジュール報知を中断し、LED27を着信報知のための点灯に切り替えるような構成としても良い。この場合、その後、適宜のタイミングで、メイン表示パネル21にポップアップ形式等にてスケジュール件数等を報知することが望ましい。あるいは、スケジュール報知の途中に、電話等の着信があった場合に、スケジュール報知を中断せず、それまでの色と異なる色でLED27を点灯させ、スケジュール報知と着信報知とを兼ねた報知を行うような構成としても良い。
また、上記実施の形態の構成に加え、スケジュールの緊急度や重要度等に係る情報がスケジュールテーブルに登録されるようにし、これらの情報に応じたLED27の点灯が行われるようにしても良い。たとえば、午後1時から午後10時までの続くような長い会議がある場合、このような会議は、一日の大半のスケジュールを占めるので重要と考えられる。そこで、この場合には、LED27を七色(1回の点灯で七色に移り変わる)に点灯させるなど、LED27を、単なる色変え程度ではない特別な形態で点灯させることができる。
さらに、上記実施の形態では、スケジュール報知がLED27により行われる構成とされているが、これ限らず、たとえば、サブ表示パネル23を点滅させるような構成としても良い。また、LED27やサブ表示パネル23を用いた光による報知ではなく、スピーカ110を用いた音による報知、あるいは振動装置112を用いた振動による報知としても良い。さらには、光、音、振動による報知を適宜組み合わせる構成としても良い。
さらに、上記実施の形態や、変更例1、変更例2において、種々の報知形態について説明したが、これら報知形態の中から、ユーザが所望のものを選択できる構成としても良い。また、報知するための条件を、設定した報知時刻とするか、フリップオープン回数とするか、キー操作とするか、ユーザが選択できる構成としても良い。
さらに、本発明の情報処理装置は、携帯電話機に限られず、PDA(Personal Digital Assistant)等であっても良い。
この他、本発明の実施の形態は、特許請求の範囲に示された技術的思想の範囲内において、適宜、種々の変更が可能である。