情報処理装置
【課題】煩雑な操作を行うことなくスケジュールの件数等を簡易に把握できる情報処理装置を提供する。
【解決手段】携帯電話機は、ＣＰＵ１００、メモリ１０６、ＬＥＤ２７を備えている。メモリ１０６には、予定日時（予定日、予定時刻）に対応づけてスケジュールが記憶されている。ＣＰＵ１００は、所定期間内、たとえば予定当日一日に含まれているスケジュールをメモリ１０６から抽出し、抽出したスケジュールに基づいて、ＬＥＤ２７を点滅させる。ユーザは、ＬＥＤ２７の点滅回数を見ることで、容易にスケジュール件数を把握することができる。
【解決手段】携帯電話機は、ＣＰＵ１００、メモリ１０６、ＬＥＤ２７を備えている。メモリ１０６には、予定日時（予定日、予定時刻）に対応づけてスケジュールが記憶されている。ＣＰＵ１００は、所定期間内、たとえば予定当日一日に含まれているスケジュールをメモリ１０６から抽出し、抽出したスケジュールに基づいて、ＬＥＤ２７を点滅させる。ユーザは、ＬＥＤ２７の点滅回数を見ることで、容易にスケジュール件数を把握することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関するものであり、特に、携帯電話機やＰＤＡ（Personal Digital Assistant）等の携帯型情報処理装置に用いて好適なものである。
【背景技術】
【０００２】
従来、携帯電話機やＰＤＡ等には、スケジュール管理機能が備えられており、ユーザは、この機能を利用して、自己のスケジュールを管理することができる。スケジュール管理機能を備えた携帯電話機の一例が、たとえば、以下の特許文献１に記載されている。
【０００３】
このような携帯電話機において、当日のスケジュールを確認したい場合、ユーザは、スケジュール管理機能を起動させ、スケジュールを確認するための画面を開いて、登録されているスケジュールの件数や内容を確認する。
【特許文献１】特開２００７−１１０３９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、この構成では、スケジュール確認のために複数回の操作が必要となるため、操作に時間を割けないほど多忙な場合には、スケジュール確認を行うのがかなり難しくなる。一方、ユーザは、このような状況にあるときでも、少なくとも、その日のスケジュールの件数や大まかなタイミング等を知りたい場合があり、これらの情報が、特に装置を操作せずとも、あるいは単純な操作のみによって把握できれば、ユーザにおいて、かなりの助けとなり得る。
【０００５】
また、意図的にスケジュールを確認せずとも、ユーザが知り得るタイミングでスケジュール件数等が報知されれば、ユーザメリットを向上させることができる。たとえば、机上に携帯電話機を置いた状態で業務を行っている際に、五感で容易に感知できる形態でスケジュール件数等が報知されれば、ユーザは、多忙な状況にありながら、その日のスケジュールの件数等を容易に把握することができる。
【０００６】
本発明は、このような課題に鑑みてなされたものであり、煩雑な操作を行うことなくスケジュールの件数等を簡易に把握できる情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の情報処理装置は、予定日時に対応づけてスケジュールを記憶する記憶手段と、所定期間内に含まれる前記スケジュールを前記記憶手段から抽出する抽出手段と、抽出された前記スケジュールに基づいて報知のための出力をオン／オフ制御する報知手段とを備えることを特徴とする。
【０００８】
ここで、前記報知手段は、たとえば、抽出された前記スケジュールの個数に応じた回数の前記出力を、１回の報知サイクルにおいて行う。前記出力は、たとえば、光、音、振動、または、これらを組み合わせたものとすることができる。
【０００９】
この構成では、たとえば、所定期間が予定当日一日である場合、その日のスケジュール件数に応じた回数だけ出力がオン／オフされる。たとえば、出力が光によるものであれば、その日のスケジュール件数に応じた回数だけ光が点滅する。
【００１０】
ユーザは、出力のオン／オフ回数を認識することにより、スケジュール件数を容易に把握することができる。よって、ユーザは、多忙な状況下でも、大まかなスケジュール状態を、容易に把握することができる。
【００１１】
さらに、本発明の情報処理装置において、前記報知手段は、前記期間における時間軸上の前記スケジュールの出現タイミングに応じて前記出力のタイミングを制御する構成とすることができる。
【００１２】
この構成によれば、各出力が、時間軸上におけるスケジュールの出現タイミングに対応するタイミングでなされるため、ユーザは、１報知サイクル期間中のどのあたりで出力がなされたかによって、各スケジュールがどの時間帯にあるかを感覚的に把握することができる。また、どの時間帯にスケジュールが密集しており、どの時間帯ではスケジュールが空いている等の情報を、大まかに把握することもできる。
【００１３】
さらに、本発明の情報処理装置において、前記報知手段は、抽出された前記スケジュールが報知の実行時よりも前か後かに応じて前記出力の形態を変化させる構成とすることができる。
【００１４】
この構成によれば、ユーザは、所定期間のスケジュール全件のうち、既に何件のスケジュールが遂行状態にあり、今後何件のスケジュールが残っているのかを容易に把握することができる。
【００１５】
さらに、本発明の情報管理装置において、前記報知手段は、予め設定された参照時刻より前の前記スケジュールに対する前記出力の形態と後の前記スケジュールに対する前記出力の形態を異ならせる構成とすることができる。あるいは、前記報知手段は、予め設定された参照時刻を報知するための出力を、前記スケジュールの報知のための形態とは異なる形態で実行し、前記参照時刻より前のスケジュールに対する前記出力と後のスケジュールに対する前記出力を、前記参照時刻を報知する出力を挟んで実行する構成とすることができきる。
【００１６】
これらの構成とすれば、参照時刻を境にして、それより前に何件程度のスケジュールがあり、それより後に何件程度のスケジュールがあるかを、ユーザが容易に把握することができる。たとえば、所定期間が予定当日一日であり、参照時刻を正午とした場合には、午前中に何件のスケジュールがあり、午後に何件のスジュールがあるのかを、ユーザが容易に把握することができる。
【００１７】
さらに、本発明の情報処理装置において、前記抽出手段は、報知の実行時よりも後のスケジュールを抽出する構成とすることができる。こうすると、ユーザは、今後予定されたスケジュールについてだけ件数等を把握することができる。
【００１８】
さらに、本発明の情報処理装置は、外部から情報を受信する受信手段をさらに備える構成とすることができる。この場合、前記記憶手段は、前記受信手段を介して取得した前記スケジュールとその取得形態を示す情報を予定日時に対応づけて記憶し、前記報知手段は、前記受信手段を介して取得したスケジュールに対する前記出力をその他の前記スケジュールに対する前記出力と異なる形態にて実行する構成とすることができる。
【００１９】
この構成では、外部から設定されたスケジュールの報知形態と、ユーザ自身の意図により設定されたスケジュールの報知形態が区別されるため、ユーザは、外部から設定されたスケジュールを把握していない場合にも、その存在を容易に把握することができる。
【００２０】
さらに、本発明の情報処理装置において、前記報知手段は、本体装置が使用状態にあるかを判別し、使用状態にあるときの所定のタイミングで、前記報知を実行する構成とすることができる。
【００２１】
この構成によれば、ユーザが本体装置を使用状態にあるタイミング、即ち、ユーザが報知に気付き得る適正なタイミングで、スケジュールに関する報知を行うことができる。よって、ユーザに対し、スケジュールの件数等を的確に知らしめることができる。
【発明の効果】
【００２２】
以上のとおり、本発明によれば、煩雑な操作を行うことなくスケジュールの件数等を簡易に把握可能な情報処理装置を提供することができる。
【００２３】
本発明の効果ないし意義は、以下に示す実施の形態の説明により更に明らかとなろう。ただし、以下の実施の形態は、あくまでも、本発明を実施化する際の一つの例示であって、本発明は、以下の実施の形態に記載されたものに何ら制限されるものではない。
【発明を実施するための最良の形態】
【００２４】
以下、本発明の実施の形態につき図面を参照して説明する。図１は携帯電話機の外観構成を示す図であり、同図（ａ）は、第１キャビネット１に対して第２キャビネット２をほぼ鉛直に立てた状態を示す側面図、同図（ｂ）は同じ状態での背面図である。
【００２５】
携帯電話機は、第１キャビネット１と第２キャビネット２を備える。第１キャビネット１の正面側には、キー操作部１１が設けられている。キー操作部１１には、各種の機能モード（カメラ撮影モード、メール送受信モード、インターネットモード）への切替えキー、通話開始キー、通話終了キー、番号・文字入力キーなどの各種キーが配されている。
【００２６】
キー操作部１１の背後には、バックライト装置１２（以下、「キーバックライト」という）が配されている。キーバックライト１２は、光源となるＬＥＤを備え、キー操作部１１に光を供給する。キー操作部１１の主要なキーは、キーに付された表示の部分が透光性を有するよう構成されており、バックライト１２で照らされることにより表示が光る。これにより、ユーザは、周囲が暗くてもキーに付された表示を見ることができる。
【００２７】
第２キャビネット２の正面側には、縦長の矩形状を有する液晶表示パネル２１（以下、「メイン表示パネル」という）が配されており、その表示画面が正面に臨んでいる。メイン表示パネル２１の背後には、バックライト装置２２（以下、「メインバックライト」という）が配されている。メインバックライト２２は、光源となるＬＥＤを備え、メイン表示パネル２１に光を供給する。
【００２８】
第２キャビネット２の背面側には、液晶表示パネル２３（以下、「サブ表示パネル」という）が配されており、その表示画面が背面に臨んでいる。サブ表示パネル２３の背後には、バックライト装置２４（以下、「サブバックライト」という）が配されている。サブバックライト２４は、光源となるＬＥＤを備え、サブ表示パネル２３に光を供給する。サブ表示パネル２３は、メイン表示パネル２１よりも小さなサイズであり、横長の矩形状を有している。サブバックライト２４も、サブ表示パネル２３に合わせ、メインバックライト２２より小さなサイズになっている。
【００２９】
また、第２キャビネット２の内部には、カメラモジュール２５が配されており、第２キャビネット２の背面には、カメラモジュール２５に対応するレンズ窓２６が設けられている。このレンズ窓２６から被写体の像がカメラモジュール２５に取り込まれる。
【００３０】
第２キャビネットの背面側には、レンズ窓２６の下方位置に、多色発光タイプのＬＥＤ２７が配されている。ＬＥＤ駆動回路（後述）による駆動によって、ＬＥＤ２７から７色の光が出力され得る。
【００３１】
ＬＥＤ２７は、通常、電話や電子メールの着信があったときに、それを知らせる着信音とともに点灯される。さらに、本実施の形態では、後述するスケジュール件数の簡易報知を行う際に、このＬＥＤ２７がスケジュール件数に応じて点灯される。
【００３２】
第２キャビネット２は、ヒンジ部３によって、第１キャビネット１に対し回動可能に連結されている。ヒンジ部３は、第２キャビネット２の連結側端部から左右に延びる一対の回転軸３１と、第１キャビネット１の連結側端部に形成され、回転軸３１を受ける一対の軸受部３２によって構成されている。
【００３３】
第１キャビネット１と第２キャビネット２は、メイン表示パネル２１とキー操作部１１が向かい合った状態となるように折り畳まれる。よって、折り畳まれた状態（閉じた状態）では、メイン表示パネル２１とキー操作部１１が外部から隠れた状態となる。
【００３４】
第２キャビネット２は、閉じた状態（図１（ａ）に一点鎖線で示す）から開き方向に回転されることにより、１８０度近くまで開くことができる。ヒンジ部３には、第２キャビネット２が最後まで開いた位置と、第１キャビネット１と第２キャビネット２とが略９０度となる位置（９０度よりやや大きい角度位置）にクリック感を持たせるよう、図示しないクリック機構が備えられている。第２キャビネット２が開くと、メイン表示パネル２１とキー操作部１１が外部に露出する。
【００３５】
第１キャビネット１と第２キャビネット２には、第２キャビネット２の開閉を検出するための開閉検出部４が配されている。開閉検出部４は、第１キャビネット１側に設けられた閉センサ４１と、第２キャビネット２側に設けられた磁石４２によって構成されている。磁石４２は、第２キャビネット２のヒンジ部３近傍に配されており、閉センサ４１は、第２キャビネット２が完全に閉じたときに、磁石４２に近接する位置に配されている。
【００３６】
閉センサ４１は、たとえば、ＭＲセンサ（磁気抵抗素子）で構成され、磁石４２の磁力に反応して検出信号を出力する。第２キャビネット２が閉じた状態から開いた状態となると、閉センサ４１からオフ信号が出力される。反対に、第２キャビネット２が開いた状態から閉じた状態になると、閉センサ４１からオン信号が出力される。
【００３７】
図２は、携帯電話機の全体構成を示すブロック図である。本実施の形態の携帯電話機は、上述した各構成要素の他、ＣＰＵ１００、映像エンコーダ１０１、マイク１０２、音声エンコーダ１０３、時計回路１０４、通信モジュール１０５、メモリ１０６、バックライト駆動回路１０７、映像デコーダ１０８、音声デコーダ１０９、スピーカ１１０、ＬＥＤ駆動回路１１１、振動装置１１２を備えている。
【００３８】
カメラモジュール２５は、撮像レンズ２５ａ、撮像素子２５ｂなどから構成されている。撮像レンズ２５ａは、被写体の像を撮像素子２５ｂ上に結像させる。撮像素子２５ｂは、例えばＣＣＤからなり、取り込んだ画像に応じた撮像信号を生成し、映像エンコーダ１０１へ出力する。映像エンコーダ１０１は、撮像素子２５ｂからの撮像信号を、ＣＰＵ１００が処理できるディジタルの撮像信号に変換してＣＰＵ１００へ出力する。
【００３９】
マイク１０２は、音声信号を電気信号に変換して音声エンコーダ１０３へ出力する。音声エンコーダ１０３は、マイク１０２からの音声信号を、ＣＰＵ１００が処理できるディジタルの音声信号に変換してＣＰＵ１００へ出力する。時計回路１０４は、日時を計測してＣＰＵ１００へ出力する。
【００４０】
通信モジュール１０５は、ＣＰＵ１００からの音声信号や画像信号、テキスト信号などを無線信号に変換し、アンテナ１０５ａを介して基地局へ送信する。また、アンテナ１０５ａを介して受信した無線信号を音声信号や画像信号、テキスト信号などに変換してＣＰＵ１００へ出力する。
【００４１】
メモリ１０６は、ＲＯＭおよびＲＡＭを含む。メモリ１０６には、ＣＰＵ１００に制御機能を付与するための制御プログラムが記憶されている。また、メモリ１０６には、カメラモジュール２５で撮影した画像データや通信モジュール１０５を介して外部から取り込んだ画像データ、テキストデータ（メールデータ）などが所定のファイル形式で保存される。
【００４２】
さらに、メモリ１０６には、図３（ａ）に示すスケジュールテーブルが記憶されている。スケジュールテーブルには、スケジュールが、予定日、予定時刻、登録日、登録時刻および識別フラグに対応づけて登録されている。
【００４３】
バックライト駆動回路１０７は、ＣＰＵ１００からの制御信号に応じた電圧信号をメインバックライト２２、サブバックライト２４およびキーバックライト１２に供給する。
【００４４】
映像デコーダ１０８は、ＣＰＵ１００からの映像信号をメイン表示パネル２１およびサブ表示パネル２３で表示できるアナログの映像信号に変換し、メイン表示パネル２１およびサブ表示パネル２３に出力する。
【００４５】
音声デコーダ１０９は、ＣＰＵ１００からの音声信号をスピーカ１１０で出力できるアナログの音声信号に変換し、スピーカ１１０に出力する。スピーカ１１０は、音声デコーダ１０９からの音声信号を音声として再生する。
【００４６】
ＬＥＤ駆動回路１１１は、ＣＰＵ１００から出力される制御信号に従ってＬＥＤ２７を駆動する。振動装置１１１は、ＣＰＵ１００から出力される駆動信号に応じた振動パターンにて振動する。
【００４７】
ＣＰＵ１００は、カメラモジュール２５、マイク１０２、キー操作１１など各部からの入力信号に基づいて、通信モジュール１０５、映像デコーダ１０８、音声デコーダ１０９などの各部に制御信号を出力することにより、各種の機能モードの処理を行う。
【００４８】
本実施の形態の携帯電話機では、機能モードの１つとして、スケジュール管理モードを実行することができる。ユーザはこの機能を利用することによって、自己のスケジュールを管理することができる。
【００４９】
ＣＰＵ１００は、スケジュール管理モードにおいて、キー操作部１１を通じて、ユーザからスケジュールおよびそのスケジュールの予定日、予定時刻の登録があると、図３（ａ）に示す如く、そのスケジュールを、予定日、予定時刻、さらには、登録日、登録時刻、識別フラグに対応づけてメモリ１０６に記憶させる。
【００５０】
また、ＣＰＵ１００は、通信モジュール１０５が受信したメールデータの中に、スケジュール、予定日、予定時刻が含まれていた場合、同じく図３（ａ）に示す如く、そのスケジュールを、予定日、予定時刻、登録日、登録時刻および識別フラグに対応づけてメモリ１０６に記憶させる。たとえば、スケジュール、予定日、予定時刻の情報は、Ｖカードのファイル形式により電子メールに添付されて送られてくる。一方、予定管理の機能モードを実行するためのソフトウェアには、Ｖカードのファイル形式を識別および解析するためのルーチンが含まれており、これによって、ＣＰＵ１００は、スケジュール、予定日、予定時刻の情報を取得することができる。
【００５１】
なお、識別フラグは、スケジュールの取得形態を示すフラグであり、たとえば、ユーザによる登録（当該携帯電話機をキー操作して登録）の場合は、リセット状態（「０」）に設定され、電子メールに基づく登録、即ち他人による登録の場合は、セット状態（「１」）に設定される。
【００５２】
ユーザは、登録したスケジュールを確認する場合、スケジュール管理モードを起動し、スケジュールを確認するための画面を開いて、登録されているスケジュールの件数や内容を確認する。しかしながら、この場合には、スケジュール確認のために複数回の操作が必要となるため、操作に時間を割けないほど多忙な場合には、スケジュール確認を行うのがかなり難しくなる。
【００５３】
そこで、本実施の形態に係る携帯電話機では、携帯電話機を閉じた状態で、ユーザがスケジュール件数等を簡易に確認できるスケジュール簡易報知機能が備えられている。この機能が設定された場合、ＣＰＵ１００は、報知のための所定の条件が満たされると、所定期間（以下、「スケジュール抽出期間」という）内に含まれるスケジュールをメモリ１０６から抽出し、抽出したスケジュール件数に基づいて、ＬＥＤ駆動回路１１１に制御信号を出力し、ＬＥＤ２７をオン／オフ制御する。ここでは、報知のための条件を、たとえば、ユーザによって予め設定される報知時刻としており、また、スケジュール抽出期間を、たとえば、現在日時を含む０時から２４時までの一日（以下、「予定当日」という）としている。
【００５４】
図４は、スケジュール簡易報知機能の制御処理を示すフローチャートである。また、図５および図６は、ＬＥＤによるスケジュールの報知形態について説明するための図である。図５（ａ）は基本となる報知形態を示し、図５（ｂ）および図６（ａ）、（ｂ）は、そのバリエーションとなる報知形態を示す。なお、図５（ａ）および図６（ａ）、（ｂ）に示されている２つの図のうち、下の図は、ＣＰＵ１００からＬＥＤ駆動回路１１１に出力される制御信号の出力タイミングを示す図であり、上の図は、この制御信号に基づくＬＥＤ２７の動作状態を示す図である。
【００５５】
以下、スケジュール簡易報知機能の制御処理について、これら図４ないし図６を参照して説明する。
【００５６】
処理が開始されると、ＣＵＰ１００は、報知時刻になったか否かを判断する（Ｓ１０１）。報知時刻は、所定の設定画面においてユーザにより設定される。ユーザは、たとえば、朝６時にその日のスケジュール件数を知りたい場合は、報知時刻を午前６時に設定する。
【００５７】
ＣＰＵ１００は、ステップＳ１０１の処理において、報知時刻になったと判断すると、メモリ１０６のスケジュールテーブルから、予定当日一日分のスケジュールに関するデータ、即ち、予定日、予定時刻、登録日、登録時刻および識別フラグ（図３（ｂ）参照）を抽出する（Ｓ１０２）。
【００５８】
次に、ＣＰＵ１００は、スケジュール件数の報知を開始する旨の報知を行う（Ｓ１０３）。即ち、図５（ａ）に示すように、ＣＰＵ１００は、緑色用の制御信号を一定時間（たとえば０．５秒）出力する。これにより、ＬＥＤ駆動回路１１１から緑色用の駆動信号がＬＥＤ２７に出力され、ＬＥＤ２７が緑色に点灯する。
【００５９】
その後、ＣＰＵ１００は、スケジュール件数の報知を行う（Ｓ１０４）。即ち、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出し、図５（ａ）に示すように、算出したスケジュール件数分の赤色用の制御信号を、緑色用の制御信号の直後から一定周期（たとえば０．５秒オン−０．５秒オフ）で出力する。これにより、ＬＥＤ駆動回路１１１から赤色用の駆動信号がＬＥＤ２７に出力され、ＬＥＤ２７がスケジュール件数の回数分だけ赤色に点滅する。たとえば、図３（ｂ）の抽出データのように、予定当日のスケジュール件数が７件であれば、ＬＥＤ２７が７回点滅する。なお、ＬＥＤ２７は、緑色から赤色に移行する際、連続的に点灯しているが、ＬＥＤ２７が緑色に点灯してから赤色に点灯するまでの間に消灯期間（制御信号のオフ期間）が設けられても良い。
【００６０】
次に、ＣＰＵ１００は、スケジュール件数の報知サイクルが所定の設定回数だけ繰り返されたか否かを判断する（Ｓ１０５）。この設定回数は、ユーザによって、報知時刻を設定する際に一緒に設定される。ユーザは、設定回数を所望の回数に設定できる。
【００６１】
ＣＰＵ１００は、報知サイクルが設定回数だけ繰り返されていないと判断すると（Ｓ１０５：ＮＯ）、ステップＳ１０３の処理に戻り、設定回数になるまで、ステップＳ１０３とＳ１０４の処理を繰り返す。こうして、ＬＥＤ２７が緑色に点灯した後に赤色でスケジュール件数の回数だけ点滅するサイクルが繰り返される。
【００６２】
そして、ＣＰＵ１００は、ステップＳ１０５の処理において、スケジュール件数の報知サイクルが設定回数だけ繰り返されたと判断すると、スケジュール件数の報知を終了する旨の報知を行う（Ｓ１０６）。即ち、図５（ａ）に示すように、ＣＰＵ１００は、緑色用の制御信号を報知サイクルの開始時よりも長い一定時間（たとえば１秒）出力する。これにより、ＬＥＤ駆動回路１１１から緑色用の駆動信号がＬＥＤ２７に出力され、ＬＥＤ２７が緑色に点灯する。こうして、スケジュールの簡易報知が終了する。
【００６３】
なお、本実施の形態では、上述のように、外部から受信した情報にスケジュールが含まれている場合に、スケジュールが予定日等の付加情報に対応づけられて自動的にメモリ１０６に記憶される。このようなスケジュールは、ユーザが自ら登録したものでないため、ユーザに把握されていないことが多いと考えられる。
【００６４】
そこで、ステップＳ１０４の処理によるスケジュールの報知形態は、図５（ｂ）に示すものに変更することもできる。
【００６５】
この報知形態では、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出するとともに、識別フラグを判定し、識別フラグがセットされたスケジュールに対応する制御信号を赤色用の制御信号ではなく、黄色用の制御信号とする。これにより、図５（ｂ）に示すように、ＬＥＤ２７は、他人により登録された（自動登録された）スケジュールに対応するタイミングにおいて赤色ではなく黄色で点灯する。たとえば、図３（ｂ）に示すように、予定当日の３つ目のスケジュールと６つ目のスケジュールが他人による登録である場合、ＬＥＤ２７の３回目と６回目の点灯が黄色になる。
【００６６】
また、本実施の形態では、ユーザは、報知時刻を所望の時刻に設定できる。上述のように、報知時刻が、その日の最初のスケジュールよりも早い時刻（午前６時）に設定された場合には、報知実行時に完了しているスケジュールはないが、たとえば、その日の午後５時に報知時刻が設定された場合には、報知実行時にすでに予定時刻が経過したスケジュールも出てくる。
【００６７】
そこで、ステップＳ１０４の処理によるスケジュール件数の報知形態は、図６（ａ）、（ｂ）に示すものに変更することもできる。
【００６８】
図６（ａ）の報知形態では、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出するとともに、予定時刻を報知時刻と比較する。そして、報知時刻より前のスケジュールに対応する制御信号として、赤色用の制御信号ではなく黄色用の制御信号を出力する。これにより、図６（ａ）に示すように、ＬＥＤ２７は、報知時刻より前のスケジュールに対応するタイミングにおいて、赤色ではなく黄色で点灯する。たとえば、報知時刻が午後５時であり、図３（ｂ）に示すように、１件から５件分のスケジュールの予定時刻が報知時刻より早い場合には、報知時刻のタイミングで既に５件のスケジュールの予定時刻が経過しているので、ＬＥＤ２７は、５回目までは黄色で点滅し、６回目と７回目は赤色で点滅する。
【００６９】
図６（ｂ）の報知形態とする場合には、まず、ステップＳ１０２において、ＣＰＵ１００は、予定当日一日のスケジュールのうち、予定時刻が報知時刻より後のスケジュール項目（予定日、予定時刻、登録日、登録時刻および識別フラグ）を、メモリ１０６のスケジュールテーブルから抽出する。たとえば、報知時刻が午後５時であれば、図３（ｂ）に示す最後の２件のスケジュールのみが抽出される。
【００７０】
そして、ステップＳ１０４の処理において、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出し、図６（ｂ）に示すように、算出したスケジュール件数分の赤色用の制御信号を出力する。これにより、報知時刻から予定当日の終わりまでのスケジュール、即ち、その日に残っているスケジュール件数の回数だけＬＥＤ２７が点滅する。
【００７１】
以上、本実施の形態によれば、ユーザは、ＬＥＤ２７の点滅回数（オン／オフ回数）を見ることにより、スケジュール件数を容易に把握することができる。特に、多忙な状況の中、ユーザがスケジュールの確認に十分注力できなくても、ＬＥＤ２７が点滅する形態であれば、容易にある程度の感知がなされ得るため、ユーザは、多忙な状況下でも、大まかなスケジュール状態を、容易に把握することができる。
【００７２】
また、図５（ｂ）のような報知形態とすれば、ユーザは、自ら登録していないため事前に把握しにくいスケジュールの存在を容易に把握することができる。
【００７３】
なお、他人によるスケジュールの登録が予定当日になされた場合には、特に事前の把握が難しくなる。そこで、図５（ｂ）の報知形態では、他人により当日登録されたスケジュールをユーザが的確に把握できるよう、識別フラグとともに登録日をもＣＰＵ１００において判定し、他人によって当日に登録されたスケジュールを、他人によって当日以外の日に登録されたスケジュールに対し、ＬＥＤ２７の発光色を変えるようにしても良い。
【００７４】
さらに、図６（ａ）の報知形態とすれば、ユーザは、予定当日一日のスケジュール全件のうち、何件のスケジュールが遂行状態にあり、今後何件のスケジュールが残っているのかを容易に把握することができる。
【００７５】
さらに、図６（ｂ）の報知形態とすれば、ユーザは、今後予定されているスケジュールの件数のみを把握することができる。
【００７６】
ところで、上記実施の形態では、ＬＥＤ２７の点滅周期が一定とされている。このため、上記実施の形態による報知では、スケジュール件数の把握は行えるが、個々のスケジュールの予定時刻までは把握できない。
【００７７】
そこで、各スケジュールの予定時刻が加味された報知形態となるよう、上記実施の形態のステップＳ１０４の処理による報知形態を、さらに、以下の変更例１のように変更することができる。
【００７８】
＜変更例１＞
図７から図９は、変更例１に係るスケジュールの報知形態について説明するための図である。図７は基本となる報知形態を示し、図８および図９は、そのバリエーションとなる報知形態を示す。
【００７９】
この報知形態では、図７（ａ）に示すように、スケジュール件数を報知するための報知時間Ｔが一定時間に固定されており、この報知時間Ｔを一日とみなして、これを１２の区間に区分し、１区間ｔが１日中の２時間の時間帯に対応するように構成されている。たとえば、報知時間Ｔが１２秒とされた場合、２時間の時間帯に対応する区間ｔは、１秒となる。
【００８０】
ＣＰＵ１００は、ステップＳ１０４の処理において、抽出したデータから、個々のスケジュールの予定時刻を判定し、この予定時刻を含む時間帯において制御信号が出力されるよう、制御信号の出力タイミングを決める。
【００８１】
たとえば、図３（ｂ）に示す抽出データの場合には、１４時から１６時の時間帯、１６時から１８時の時間帯、２０時から２２時の時間帯および２２時から２４時の時間帯にスケジュールの予定時刻が１つ含まれる。よって、図７（ａ）に示すように、これらの時間帯に対応する区間ｔにおいて、それぞれ１つの制御信号がＣＰＵ１００から出力される。また、図３（ｂ）の抽出データでは、１０時から１２時の時間帯には、２つの予定時刻が含まれる。よって、図７（ａ）に示すように、この時間帯に対応する区間ｔにおいて、２つの制御信号がＣＰＵ１００から出力される。こうして、ＬＥＤ２７は、報知時間Ｔの中で、予定時刻の時間帯に対応したタイミングで点灯することになる。
【００８２】
このように、変更例１に係る報知形態とすれば、各スケジュールに対応するＬＥＤ２７の点灯タイミングが、そのスケジュールの予定時刻を反映したものとなるため、ユーザは、報知時間Ｔ（１報知サイクル期間）中のどのあたりで出力がなされたかによって、各スケジュールがどの時間帯に含まれるかを感覚的に把握することができる。また、この出力によって、どの時間帯にスケジュールが密集しており、どの時間帯ではスケジュールが空いているか等の情報を大まかに把握することができる。
【００８３】
なお、制御信号のオン／オフ周期は、図７（ｂ）に示すように、一つの時間帯中に含まれるスケジュールの件数が少ない場合は、基準周期、たとえば、０．５秒周期（０．２５秒オン−０．２５秒オフ）となる。この場合、上記のように一つ時間帯に対応する区間ｔが１秒であれば、スケジュール２件まではこの基準周期で制御信号が出力され、ＬＥＤ２７が基準周期で点滅する。
【００８４】
一方、同図（ｃ）、（ｄ）に示すように、一つの時間帯中に含まれるスケジュールの件数が多くなると、制御信号のオン／オフ周期が、その件数に合わせて短くなるように、自動的に調整される。よって、スケジュール件数が多くなれば、それに合わせて、ＬＥＤ２７の点滅周期が短くなる。
【００８５】
そして、一つの時間帯中に含まれるスケジュールの件数がかなり多くなり、回路的にＬＥＤ２７をオン／オフ駆動することができないほどにまで短いオン／オフ周期になると、制御信号は、同図（ｅ）に示すように、オン／オフされずに、その時間帯に対応する区間ｔにおいて出力され続ける。これにより、ＬＥＤ２７は、その区間ｔにおいて連続的に点灯する。
【００８６】
変更例１に係る報知形態は、さらに、図８（ａ）、（ｂ）に示すものに変更することもできる。
【００８７】
図８（ａ）の報知形態では、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出するとともに、予定時刻を予め設定された参照時刻と比較する。そして、ＣＰＵ１００は、参照時刻、ここでは一日の中間となる正午（午後１２時）より前のスケジュールに対応する制御信号として、赤色用の制御信号ではなく、青色用の制御信号をＬＥＤ駆動回路１１１に出力する。これにより、図８（ａ）に示すように、ＬＥＤ２７は、正午より前のスケジュールに対応するタイミングにおいて、赤色ではなく青色で点灯する。
【００８８】
図８（ｂ）の報知形態では、ＣＰＵ１００は、予め設定された参照時刻（ここでは正午のタイミング）に黄色の制御信号を出力する。これにより、ＬＥＤ２７は、正午の時刻のタイミングにおいて黄色で点灯する。スケジュールに対応するタイミングでは、図７の場合と同様、赤色でＬＥＤ２７が点灯される。
【００８９】
このように、図８（ａ）、（ｂ）の報知形態とすれば、ユーザは、参照時刻を境にしてそれより前に何件程度のスケジュールがあり、それより後に何件程度のスケジュールがあるかを容易に把握することができる。たとえば、上記のように参照時刻が正午であれば、ユーザは、午前中に何件のスケジュールがあり、午後に何件のスジュールがあるのかを、容易に把握することができる。
【００９０】
変更例１に係る報知形態は、さらに、図９に示すものとすることもできる。
【００９１】
図９の報知形態では、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出するとともに、各スケジュールの予定時刻同士を比較する。そして、ＣＰＵ１００は、互いに重複した予定時刻（いわゆるダブルブッキング）があれば、そのスケジュールに対応する制御信号として、赤色用の制御信号ではなく、青色用の制御信号をＬＥＤ駆動回路１１１に出力する。これにより、同図に示すように、ＬＥＤ２７は、重複したスケジュールに対応するタイミングにおいて赤色ではなく青色で点灯する。
【００９２】
このような報知形態とすれば、ユーザは、予定時刻が重複するスケジュール（ダブルブッキング）があることを容易に把握することができる。
【００９３】
さらに、変更例１の構成においては、図５（ｂ）および図６に示す上記実施の形態のバリエーションの構成を適用することができる。即ち、変更例１の構成に図５（ｂ）に示す構成を適用することにより、他人により登録されたスケジュールに対応して点灯されるＬＥＤ２７の色をその他のスケジュールに対応して点灯されるＬＥＤ２７の色と異ならせる構成とすることができる。また、変更例１の構成に図６（ａ）に示す構成を適用することにより、報知時刻の前後でＬＥＤ２７の色を異ならせる構成とすることもできる。さらに、変更例１の構成に図６（ｂ）に示す構成を適用することで、その日のスケジュールのうち、報知時刻より後のスケジュールのみを報知させる構成とすることもできる。
【００９４】
反対に、上記実施の形態に、図８および図９に示す変更例１のバリエーションの構成を適用することもできる。即ち、上記実施の形態に図８に示す構成を適用することにより、参照時刻、たとえば、正午（午後１２時）の前後でＬＥＤ２７の色を変えたり、参照時刻を示すＬＥＤ２７の点灯を行ったりする構成とすることができる。また、上記実施の形態に図９に示す構成を適用することにより、予定時刻が重複した場合に、そのスケジュールに対応して点灯されるＬＥＤ２７の色を、他のスケジュールに対応して点灯されるＬＥＤ２７の色と異ならせる構成とすることもできる。
【００９５】
さて、上記実施の形態および変更例１では、スケジュールが抽出される期間を予定当日としているが、以下に示す変更例２のように、スケジュール抽出期間を報知時刻から一定時間とすることもできる。
【００９６】
＜変更例２＞
図１０は、変更例２に係るＬＥＤによるスケジュールの報知形態について説明するための図である。
【００９７】
変更例２では、スケジュール抽出期間が報知時刻から一定時間、たとえば１時間とされているとともに、変更例１と同様、報知時間Ｔが一定時間に固定されている。図１０に示すように、スケジュール抽出期間が１時間とされた場合、この報知時間Ｔを１時間とみなして、これを１２の区間に区分し、１区間ｔあたり５分の時間帯となるように構成されている。たとえば、報知時間Ｔが１２秒とされた場合、５分の時間帯に対応する区間ｔは１秒となる。
【００９８】
こうして、同図に示すように、報知時刻から１時間以内に予定時刻があるスケジュールがあれば、そのスケジュールの予定時刻に対応するタイミングでＬＥＤ２７が点灯する。
【００９９】
さらに、上記実施の形態では、ユーザよって予め設定された報知時刻にスケジュール報知が行われる構成である、報知が実行される条件を、以下の変更例３のように変更することができる。
【０１００】
＜変更例３＞
図１１は、変更例３に係るスケジュール簡易報知機能の制御処理を示すフローチャートである。同図（ａ）は、第２キャビネットが開放される回数（フリップオープンの回数）に基づいて報知を行う例を示し、同図（ｂ）は、キー操作に基づいて報知する例を示す。なお、同図（ａ）、（ｂ）の処理は、たとえば、予定当日の開始時点に開始される。
【０１０１】
同図（ａ)の例では、処理が開始されると、ＣＰＵ１００は、フリップオープン回数が規定回数Ｎになったか否かを判断する（Ｓ１１１）。
【０１０２】
ユーザが一日の活動を始め、携帯電話機が使用され始めると、第２キャビネット２が開いたり閉じたりされる。そこで、フリップ回数が規定回数Ｎになれば、ユーザによって携帯電話機が使用されており、その際にスケジュール報知を行えば、それがユーザに知られ得ると判断することができる。
【０１０３】
ＣＰＵ１００は、フリップオープン回数が規定回数Ｎに達したと判断すると（Ｓ１１１：ＹＥＳ）、さらに、第２キャビネット２が閉じられたか(フリップクローズか)否かを判断する（Ｓ１１２）。
【０１０４】
通話やメール発信等が終わり、ユーザによって第２キャビネット２が閉じられると（Ｓ１１２：ＹＥＳ）、ＣＰＵ１００は、メモリ１０６からのスケジュール抽出を行う（Ｓ１０２）。
【０１０５】
このような構成とすれば、ユーザが意図的に操作しなくても、ユーザが知り得る適正なタイミングでスケジュール報知を行うことができる。
【０１０６】
次に、図１１（ｂ)の例では、処理が開始されると、ＣＰＵ１００は、報知のためのキー操作がされたか否かを判断する（Ｓ１２１）。
【０１０７】
ユーザは、スケジュール件数を知りたいタイミングで、報知のためのキー操作を行う。たとえば、ユーザは、携帯電話機の側面に設けられたサイドキー（図示せず）を３秒間押す（長押しを行う）。
【０１０８】
ＣＰＵ１００は、報知のためのキー操作がなされたと判断すると（Ｓ１２１：ＹＥＳ）、メモリ１０６からのスケジュール抽出を行う（Ｓ１０２）。
【０１０９】
このような構成とすれば、ユーザは、所望のタイミングでスケジュールの確認を行うことができる。
【０１１０】
なお、変更例３（図１１（ａ）、（ｂ）の例）の構成において、ステップＳ１０２からＳ１０６の処理については、上記実施の形態と同様であり、ステップＳ１０４の処理では、上記実施の形態や変更例１に示すような報知形態にて、スケジュールが報知される。
【０１１１】
なお、ステップＳ１０４の処理によりスケジュール報知を行う場合に、報知時刻から直近の一定時間（たとえば、１時間）のスケジュールに対応して点灯されるＬＥＤ２７の色を他の時間のスケジュールに対応して点灯されるＬＥＤ２７の色と異ならせるようにしても良い。また、特に、図１１（ａ）の構成とした場合に、ステップＳ１０３の開始報知の処理において、ＬＥＤ２７の緑色での点灯とともに音による報知を行うようにすれば、スケジュール報知が開始されることをユーザに確実に知らせることができる。
【０１１２】
＜その他＞
本発明の実施形態は、上記以外にさらに、以下のように種々の変更が可能である。
【０１１３】
上記実施の形態では、電話や電子メールの着信時にもＬＥＤ２７が点灯する構成であるため、スケジュール報知時に電話等の着信がある場合がある。そこで、スケジュール報知の途中に、電話等の着信があった場合には、スケジュール報知を中断し、ＬＥＤ２７を着信報知のための点灯に切り替えるような構成としても良い。この場合、その後、適宜のタイミングで、メイン表示パネル２１にポップアップ形式等にてスケジュール件数等を報知することが望ましい。あるいは、スケジュール報知の途中に、電話等の着信があった場合に、スケジュール報知を中断せず、それまでの色と異なる色でＬＥＤ２７を点灯させ、スケジュール報知と着信報知とを兼ねた報知を行うような構成としても良い。
【０１１４】
また、上記実施の形態の構成に加え、スケジュールの緊急度や重要度等に係る情報がスケジュールテーブルに登録されるようにし、これらの情報に応じたＬＥＤ２７の点灯が行われるようにしても良い。たとえば、午後１時から午後１０時までの続くような長い会議がある場合、このような会議は、一日の大半のスケジュールを占めるので重要と考えられる。そこで、この場合には、ＬＥＤ２７を七色（１回の点灯で七色に移り変わる）に点灯させるなど、ＬＥＤ２７を、単なる色変え程度ではない特別な形態で点灯させることができる。
【０１１５】
さらに、上記実施の形態では、スケジュール報知がＬＥＤ２７により行われる構成とされているが、これ限らず、たとえば、サブ表示パネル２３を点滅させるような構成としても良い。また、ＬＥＤ２７やサブ表示パネル２３を用いた光による報知ではなく、スピーカ１１０を用いた音による報知、あるいは振動装置１１２を用いた振動による報知としても良い。さらには、光、音、振動による報知を適宜組み合わせる構成としても良い。
【０１１６】
さらに、上記実施の形態や、変更例１、変更例２において、種々の報知形態について説明したが、これら報知形態の中から、ユーザが所望のものを選択できる構成としても良い。また、報知するための条件を、設定した報知時刻とするか、フリップオープン回数とするか、キー操作とするか、ユーザが選択できる構成としても良い。
【０１１７】
さらに、本発明の情報処理装置は、携帯電話機に限られず、ＰＤＡ（Personal Digital Assistant）等であっても良い。
【０１１８】
この他、本発明の実施の形態は、特許請求の範囲に示された技術的思想の範囲内において、適宜、種々の変更が可能である。
【図面の簡単な説明】
【０１１９】
【図１】実施の形態に係る携帯電話機の外観構成を示す図
【図２】実施の形態に係る携帯電話機の全体構成を示すブロック図
【図３】実施の形態に係るスケジュールテーブルの構成を示す図
【図４】実施の形態に係るスケジュール簡易報知機能の制御処理を示すフローチャート
【図５】実施の形態に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図６】実施の形態に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図７】変更例１に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図８】変更例１に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図９】変更例１に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図１０】変更例２に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図１１】変更例３に係るスケジュール簡易報知機能の制御処理を示すフローチャート
【符号の説明】
【０１２０】
２７ ＬＥＤ（報知手段）
１００ ＣＰＵ（抽出手段、報知手段）
１０５ 通信モジュール（受信手段）
１０６ メモリ（記憶手段）
【技術分野】
【０００１】
本発明は、情報処理装置に関するものであり、特に、携帯電話機やＰＤＡ（Personal Digital Assistant）等の携帯型情報処理装置に用いて好適なものである。
【背景技術】
【０００２】
従来、携帯電話機やＰＤＡ等には、スケジュール管理機能が備えられており、ユーザは、この機能を利用して、自己のスケジュールを管理することができる。スケジュール管理機能を備えた携帯電話機の一例が、たとえば、以下の特許文献１に記載されている。
【０００３】
このような携帯電話機において、当日のスケジュールを確認したい場合、ユーザは、スケジュール管理機能を起動させ、スケジュールを確認するための画面を開いて、登録されているスケジュールの件数や内容を確認する。
【特許文献１】特開２００７−１１０３９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、この構成では、スケジュール確認のために複数回の操作が必要となるため、操作に時間を割けないほど多忙な場合には、スケジュール確認を行うのがかなり難しくなる。一方、ユーザは、このような状況にあるときでも、少なくとも、その日のスケジュールの件数や大まかなタイミング等を知りたい場合があり、これらの情報が、特に装置を操作せずとも、あるいは単純な操作のみによって把握できれば、ユーザにおいて、かなりの助けとなり得る。
【０００５】
また、意図的にスケジュールを確認せずとも、ユーザが知り得るタイミングでスケジュール件数等が報知されれば、ユーザメリットを向上させることができる。たとえば、机上に携帯電話機を置いた状態で業務を行っている際に、五感で容易に感知できる形態でスケジュール件数等が報知されれば、ユーザは、多忙な状況にありながら、その日のスケジュールの件数等を容易に把握することができる。
【０００６】
本発明は、このような課題に鑑みてなされたものであり、煩雑な操作を行うことなくスケジュールの件数等を簡易に把握できる情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の情報処理装置は、予定日時に対応づけてスケジュールを記憶する記憶手段と、所定期間内に含まれる前記スケジュールを前記記憶手段から抽出する抽出手段と、抽出された前記スケジュールに基づいて報知のための出力をオン／オフ制御する報知手段とを備えることを特徴とする。
【０００８】
ここで、前記報知手段は、たとえば、抽出された前記スケジュールの個数に応じた回数の前記出力を、１回の報知サイクルにおいて行う。前記出力は、たとえば、光、音、振動、または、これらを組み合わせたものとすることができる。
【０００９】
この構成では、たとえば、所定期間が予定当日一日である場合、その日のスケジュール件数に応じた回数だけ出力がオン／オフされる。たとえば、出力が光によるものであれば、その日のスケジュール件数に応じた回数だけ光が点滅する。
【００１０】
ユーザは、出力のオン／オフ回数を認識することにより、スケジュール件数を容易に把握することができる。よって、ユーザは、多忙な状況下でも、大まかなスケジュール状態を、容易に把握することができる。
【００１１】
さらに、本発明の情報処理装置において、前記報知手段は、前記期間における時間軸上の前記スケジュールの出現タイミングに応じて前記出力のタイミングを制御する構成とすることができる。
【００１２】
この構成によれば、各出力が、時間軸上におけるスケジュールの出現タイミングに対応するタイミングでなされるため、ユーザは、１報知サイクル期間中のどのあたりで出力がなされたかによって、各スケジュールがどの時間帯にあるかを感覚的に把握することができる。また、どの時間帯にスケジュールが密集しており、どの時間帯ではスケジュールが空いている等の情報を、大まかに把握することもできる。
【００１３】
さらに、本発明の情報処理装置において、前記報知手段は、抽出された前記スケジュールが報知の実行時よりも前か後かに応じて前記出力の形態を変化させる構成とすることができる。
【００１４】
この構成によれば、ユーザは、所定期間のスケジュール全件のうち、既に何件のスケジュールが遂行状態にあり、今後何件のスケジュールが残っているのかを容易に把握することができる。
【００１５】
さらに、本発明の情報管理装置において、前記報知手段は、予め設定された参照時刻より前の前記スケジュールに対する前記出力の形態と後の前記スケジュールに対する前記出力の形態を異ならせる構成とすることができる。あるいは、前記報知手段は、予め設定された参照時刻を報知するための出力を、前記スケジュールの報知のための形態とは異なる形態で実行し、前記参照時刻より前のスケジュールに対する前記出力と後のスケジュールに対する前記出力を、前記参照時刻を報知する出力を挟んで実行する構成とすることができきる。
【００１６】
これらの構成とすれば、参照時刻を境にして、それより前に何件程度のスケジュールがあり、それより後に何件程度のスケジュールがあるかを、ユーザが容易に把握することができる。たとえば、所定期間が予定当日一日であり、参照時刻を正午とした場合には、午前中に何件のスケジュールがあり、午後に何件のスジュールがあるのかを、ユーザが容易に把握することができる。
【００１７】
さらに、本発明の情報処理装置において、前記抽出手段は、報知の実行時よりも後のスケジュールを抽出する構成とすることができる。こうすると、ユーザは、今後予定されたスケジュールについてだけ件数等を把握することができる。
【００１８】
さらに、本発明の情報処理装置は、外部から情報を受信する受信手段をさらに備える構成とすることができる。この場合、前記記憶手段は、前記受信手段を介して取得した前記スケジュールとその取得形態を示す情報を予定日時に対応づけて記憶し、前記報知手段は、前記受信手段を介して取得したスケジュールに対する前記出力をその他の前記スケジュールに対する前記出力と異なる形態にて実行する構成とすることができる。
【００１９】
この構成では、外部から設定されたスケジュールの報知形態と、ユーザ自身の意図により設定されたスケジュールの報知形態が区別されるため、ユーザは、外部から設定されたスケジュールを把握していない場合にも、その存在を容易に把握することができる。
【００２０】
さらに、本発明の情報処理装置において、前記報知手段は、本体装置が使用状態にあるかを判別し、使用状態にあるときの所定のタイミングで、前記報知を実行する構成とすることができる。
【００２１】
この構成によれば、ユーザが本体装置を使用状態にあるタイミング、即ち、ユーザが報知に気付き得る適正なタイミングで、スケジュールに関する報知を行うことができる。よって、ユーザに対し、スケジュールの件数等を的確に知らしめることができる。
【発明の効果】
【００２２】
以上のとおり、本発明によれば、煩雑な操作を行うことなくスケジュールの件数等を簡易に把握可能な情報処理装置を提供することができる。
【００２３】
本発明の効果ないし意義は、以下に示す実施の形態の説明により更に明らかとなろう。ただし、以下の実施の形態は、あくまでも、本発明を実施化する際の一つの例示であって、本発明は、以下の実施の形態に記載されたものに何ら制限されるものではない。
【発明を実施するための最良の形態】
【００２４】
以下、本発明の実施の形態につき図面を参照して説明する。図１は携帯電話機の外観構成を示す図であり、同図（ａ）は、第１キャビネット１に対して第２キャビネット２をほぼ鉛直に立てた状態を示す側面図、同図（ｂ）は同じ状態での背面図である。
【００２５】
携帯電話機は、第１キャビネット１と第２キャビネット２を備える。第１キャビネット１の正面側には、キー操作部１１が設けられている。キー操作部１１には、各種の機能モード（カメラ撮影モード、メール送受信モード、インターネットモード）への切替えキー、通話開始キー、通話終了キー、番号・文字入力キーなどの各種キーが配されている。
【００２６】
キー操作部１１の背後には、バックライト装置１２（以下、「キーバックライト」という）が配されている。キーバックライト１２は、光源となるＬＥＤを備え、キー操作部１１に光を供給する。キー操作部１１の主要なキーは、キーに付された表示の部分が透光性を有するよう構成されており、バックライト１２で照らされることにより表示が光る。これにより、ユーザは、周囲が暗くてもキーに付された表示を見ることができる。
【００２７】
第２キャビネット２の正面側には、縦長の矩形状を有する液晶表示パネル２１（以下、「メイン表示パネル」という）が配されており、その表示画面が正面に臨んでいる。メイン表示パネル２１の背後には、バックライト装置２２（以下、「メインバックライト」という）が配されている。メインバックライト２２は、光源となるＬＥＤを備え、メイン表示パネル２１に光を供給する。
【００２８】
第２キャビネット２の背面側には、液晶表示パネル２３（以下、「サブ表示パネル」という）が配されており、その表示画面が背面に臨んでいる。サブ表示パネル２３の背後には、バックライト装置２４（以下、「サブバックライト」という）が配されている。サブバックライト２４は、光源となるＬＥＤを備え、サブ表示パネル２３に光を供給する。サブ表示パネル２３は、メイン表示パネル２１よりも小さなサイズであり、横長の矩形状を有している。サブバックライト２４も、サブ表示パネル２３に合わせ、メインバックライト２２より小さなサイズになっている。
【００２９】
また、第２キャビネット２の内部には、カメラモジュール２５が配されており、第２キャビネット２の背面には、カメラモジュール２５に対応するレンズ窓２６が設けられている。このレンズ窓２６から被写体の像がカメラモジュール２５に取り込まれる。
【００３０】
第２キャビネットの背面側には、レンズ窓２６の下方位置に、多色発光タイプのＬＥＤ２７が配されている。ＬＥＤ駆動回路（後述）による駆動によって、ＬＥＤ２７から７色の光が出力され得る。
【００３１】
ＬＥＤ２７は、通常、電話や電子メールの着信があったときに、それを知らせる着信音とともに点灯される。さらに、本実施の形態では、後述するスケジュール件数の簡易報知を行う際に、このＬＥＤ２７がスケジュール件数に応じて点灯される。
【００３２】
第２キャビネット２は、ヒンジ部３によって、第１キャビネット１に対し回動可能に連結されている。ヒンジ部３は、第２キャビネット２の連結側端部から左右に延びる一対の回転軸３１と、第１キャビネット１の連結側端部に形成され、回転軸３１を受ける一対の軸受部３２によって構成されている。
【００３３】
第１キャビネット１と第２キャビネット２は、メイン表示パネル２１とキー操作部１１が向かい合った状態となるように折り畳まれる。よって、折り畳まれた状態（閉じた状態）では、メイン表示パネル２１とキー操作部１１が外部から隠れた状態となる。
【００３４】
第２キャビネット２は、閉じた状態（図１（ａ）に一点鎖線で示す）から開き方向に回転されることにより、１８０度近くまで開くことができる。ヒンジ部３には、第２キャビネット２が最後まで開いた位置と、第１キャビネット１と第２キャビネット２とが略９０度となる位置（９０度よりやや大きい角度位置）にクリック感を持たせるよう、図示しないクリック機構が備えられている。第２キャビネット２が開くと、メイン表示パネル２１とキー操作部１１が外部に露出する。
【００３５】
第１キャビネット１と第２キャビネット２には、第２キャビネット２の開閉を検出するための開閉検出部４が配されている。開閉検出部４は、第１キャビネット１側に設けられた閉センサ４１と、第２キャビネット２側に設けられた磁石４２によって構成されている。磁石４２は、第２キャビネット２のヒンジ部３近傍に配されており、閉センサ４１は、第２キャビネット２が完全に閉じたときに、磁石４２に近接する位置に配されている。
【００３６】
閉センサ４１は、たとえば、ＭＲセンサ（磁気抵抗素子）で構成され、磁石４２の磁力に反応して検出信号を出力する。第２キャビネット２が閉じた状態から開いた状態となると、閉センサ４１からオフ信号が出力される。反対に、第２キャビネット２が開いた状態から閉じた状態になると、閉センサ４１からオン信号が出力される。
【００３７】
図２は、携帯電話機の全体構成を示すブロック図である。本実施の形態の携帯電話機は、上述した各構成要素の他、ＣＰＵ１００、映像エンコーダ１０１、マイク１０２、音声エンコーダ１０３、時計回路１０４、通信モジュール１０５、メモリ１０６、バックライト駆動回路１０７、映像デコーダ１０８、音声デコーダ１０９、スピーカ１１０、ＬＥＤ駆動回路１１１、振動装置１１２を備えている。
【００３８】
カメラモジュール２５は、撮像レンズ２５ａ、撮像素子２５ｂなどから構成されている。撮像レンズ２５ａは、被写体の像を撮像素子２５ｂ上に結像させる。撮像素子２５ｂは、例えばＣＣＤからなり、取り込んだ画像に応じた撮像信号を生成し、映像エンコーダ１０１へ出力する。映像エンコーダ１０１は、撮像素子２５ｂからの撮像信号を、ＣＰＵ１００が処理できるディジタルの撮像信号に変換してＣＰＵ１００へ出力する。
【００３９】
マイク１０２は、音声信号を電気信号に変換して音声エンコーダ１０３へ出力する。音声エンコーダ１０３は、マイク１０２からの音声信号を、ＣＰＵ１００が処理できるディジタルの音声信号に変換してＣＰＵ１００へ出力する。時計回路１０４は、日時を計測してＣＰＵ１００へ出力する。
【００４０】
通信モジュール１０５は、ＣＰＵ１００からの音声信号や画像信号、テキスト信号などを無線信号に変換し、アンテナ１０５ａを介して基地局へ送信する。また、アンテナ１０５ａを介して受信した無線信号を音声信号や画像信号、テキスト信号などに変換してＣＰＵ１００へ出力する。
【００４１】
メモリ１０６は、ＲＯＭおよびＲＡＭを含む。メモリ１０６には、ＣＰＵ１００に制御機能を付与するための制御プログラムが記憶されている。また、メモリ１０６には、カメラモジュール２５で撮影した画像データや通信モジュール１０５を介して外部から取り込んだ画像データ、テキストデータ（メールデータ）などが所定のファイル形式で保存される。
【００４２】
さらに、メモリ１０６には、図３（ａ）に示すスケジュールテーブルが記憶されている。スケジュールテーブルには、スケジュールが、予定日、予定時刻、登録日、登録時刻および識別フラグに対応づけて登録されている。
【００４３】
バックライト駆動回路１０７は、ＣＰＵ１００からの制御信号に応じた電圧信号をメインバックライト２２、サブバックライト２４およびキーバックライト１２に供給する。
【００４４】
映像デコーダ１０８は、ＣＰＵ１００からの映像信号をメイン表示パネル２１およびサブ表示パネル２３で表示できるアナログの映像信号に変換し、メイン表示パネル２１およびサブ表示パネル２３に出力する。
【００４５】
音声デコーダ１０９は、ＣＰＵ１００からの音声信号をスピーカ１１０で出力できるアナログの音声信号に変換し、スピーカ１１０に出力する。スピーカ１１０は、音声デコーダ１０９からの音声信号を音声として再生する。
【００４６】
ＬＥＤ駆動回路１１１は、ＣＰＵ１００から出力される制御信号に従ってＬＥＤ２７を駆動する。振動装置１１１は、ＣＰＵ１００から出力される駆動信号に応じた振動パターンにて振動する。
【００４７】
ＣＰＵ１００は、カメラモジュール２５、マイク１０２、キー操作１１など各部からの入力信号に基づいて、通信モジュール１０５、映像デコーダ１０８、音声デコーダ１０９などの各部に制御信号を出力することにより、各種の機能モードの処理を行う。
【００４８】
本実施の形態の携帯電話機では、機能モードの１つとして、スケジュール管理モードを実行することができる。ユーザはこの機能を利用することによって、自己のスケジュールを管理することができる。
【００４９】
ＣＰＵ１００は、スケジュール管理モードにおいて、キー操作部１１を通じて、ユーザからスケジュールおよびそのスケジュールの予定日、予定時刻の登録があると、図３（ａ）に示す如く、そのスケジュールを、予定日、予定時刻、さらには、登録日、登録時刻、識別フラグに対応づけてメモリ１０６に記憶させる。
【００５０】
また、ＣＰＵ１００は、通信モジュール１０５が受信したメールデータの中に、スケジュール、予定日、予定時刻が含まれていた場合、同じく図３（ａ）に示す如く、そのスケジュールを、予定日、予定時刻、登録日、登録時刻および識別フラグに対応づけてメモリ１０６に記憶させる。たとえば、スケジュール、予定日、予定時刻の情報は、Ｖカードのファイル形式により電子メールに添付されて送られてくる。一方、予定管理の機能モードを実行するためのソフトウェアには、Ｖカードのファイル形式を識別および解析するためのルーチンが含まれており、これによって、ＣＰＵ１００は、スケジュール、予定日、予定時刻の情報を取得することができる。
【００５１】
なお、識別フラグは、スケジュールの取得形態を示すフラグであり、たとえば、ユーザによる登録（当該携帯電話機をキー操作して登録）の場合は、リセット状態（「０」）に設定され、電子メールに基づく登録、即ち他人による登録の場合は、セット状態（「１」）に設定される。
【００５２】
ユーザは、登録したスケジュールを確認する場合、スケジュール管理モードを起動し、スケジュールを確認するための画面を開いて、登録されているスケジュールの件数や内容を確認する。しかしながら、この場合には、スケジュール確認のために複数回の操作が必要となるため、操作に時間を割けないほど多忙な場合には、スケジュール確認を行うのがかなり難しくなる。
【００５３】
そこで、本実施の形態に係る携帯電話機では、携帯電話機を閉じた状態で、ユーザがスケジュール件数等を簡易に確認できるスケジュール簡易報知機能が備えられている。この機能が設定された場合、ＣＰＵ１００は、報知のための所定の条件が満たされると、所定期間（以下、「スケジュール抽出期間」という）内に含まれるスケジュールをメモリ１０６から抽出し、抽出したスケジュール件数に基づいて、ＬＥＤ駆動回路１１１に制御信号を出力し、ＬＥＤ２７をオン／オフ制御する。ここでは、報知のための条件を、たとえば、ユーザによって予め設定される報知時刻としており、また、スケジュール抽出期間を、たとえば、現在日時を含む０時から２４時までの一日（以下、「予定当日」という）としている。
【００５４】
図４は、スケジュール簡易報知機能の制御処理を示すフローチャートである。また、図５および図６は、ＬＥＤによるスケジュールの報知形態について説明するための図である。図５（ａ）は基本となる報知形態を示し、図５（ｂ）および図６（ａ）、（ｂ）は、そのバリエーションとなる報知形態を示す。なお、図５（ａ）および図６（ａ）、（ｂ）に示されている２つの図のうち、下の図は、ＣＰＵ１００からＬＥＤ駆動回路１１１に出力される制御信号の出力タイミングを示す図であり、上の図は、この制御信号に基づくＬＥＤ２７の動作状態を示す図である。
【００５５】
以下、スケジュール簡易報知機能の制御処理について、これら図４ないし図６を参照して説明する。
【００５６】
処理が開始されると、ＣＵＰ１００は、報知時刻になったか否かを判断する（Ｓ１０１）。報知時刻は、所定の設定画面においてユーザにより設定される。ユーザは、たとえば、朝６時にその日のスケジュール件数を知りたい場合は、報知時刻を午前６時に設定する。
【００５７】
ＣＰＵ１００は、ステップＳ１０１の処理において、報知時刻になったと判断すると、メモリ１０６のスケジュールテーブルから、予定当日一日分のスケジュールに関するデータ、即ち、予定日、予定時刻、登録日、登録時刻および識別フラグ（図３（ｂ）参照）を抽出する（Ｓ１０２）。
【００５８】
次に、ＣＰＵ１００は、スケジュール件数の報知を開始する旨の報知を行う（Ｓ１０３）。即ち、図５（ａ）に示すように、ＣＰＵ１００は、緑色用の制御信号を一定時間（たとえば０．５秒）出力する。これにより、ＬＥＤ駆動回路１１１から緑色用の駆動信号がＬＥＤ２７に出力され、ＬＥＤ２７が緑色に点灯する。
【００５９】
その後、ＣＰＵ１００は、スケジュール件数の報知を行う（Ｓ１０４）。即ち、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出し、図５（ａ）に示すように、算出したスケジュール件数分の赤色用の制御信号を、緑色用の制御信号の直後から一定周期（たとえば０．５秒オン−０．５秒オフ）で出力する。これにより、ＬＥＤ駆動回路１１１から赤色用の駆動信号がＬＥＤ２７に出力され、ＬＥＤ２７がスケジュール件数の回数分だけ赤色に点滅する。たとえば、図３（ｂ）の抽出データのように、予定当日のスケジュール件数が７件であれば、ＬＥＤ２７が７回点滅する。なお、ＬＥＤ２７は、緑色から赤色に移行する際、連続的に点灯しているが、ＬＥＤ２７が緑色に点灯してから赤色に点灯するまでの間に消灯期間（制御信号のオフ期間）が設けられても良い。
【００６０】
次に、ＣＰＵ１００は、スケジュール件数の報知サイクルが所定の設定回数だけ繰り返されたか否かを判断する（Ｓ１０５）。この設定回数は、ユーザによって、報知時刻を設定する際に一緒に設定される。ユーザは、設定回数を所望の回数に設定できる。
【００６１】
ＣＰＵ１００は、報知サイクルが設定回数だけ繰り返されていないと判断すると（Ｓ１０５：ＮＯ）、ステップＳ１０３の処理に戻り、設定回数になるまで、ステップＳ１０３とＳ１０４の処理を繰り返す。こうして、ＬＥＤ２７が緑色に点灯した後に赤色でスケジュール件数の回数だけ点滅するサイクルが繰り返される。
【００６２】
そして、ＣＰＵ１００は、ステップＳ１０５の処理において、スケジュール件数の報知サイクルが設定回数だけ繰り返されたと判断すると、スケジュール件数の報知を終了する旨の報知を行う（Ｓ１０６）。即ち、図５（ａ）に示すように、ＣＰＵ１００は、緑色用の制御信号を報知サイクルの開始時よりも長い一定時間（たとえば１秒）出力する。これにより、ＬＥＤ駆動回路１１１から緑色用の駆動信号がＬＥＤ２７に出力され、ＬＥＤ２７が緑色に点灯する。こうして、スケジュールの簡易報知が終了する。
【００６３】
なお、本実施の形態では、上述のように、外部から受信した情報にスケジュールが含まれている場合に、スケジュールが予定日等の付加情報に対応づけられて自動的にメモリ１０６に記憶される。このようなスケジュールは、ユーザが自ら登録したものでないため、ユーザに把握されていないことが多いと考えられる。
【００６４】
そこで、ステップＳ１０４の処理によるスケジュールの報知形態は、図５（ｂ）に示すものに変更することもできる。
【００６５】
この報知形態では、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出するとともに、識別フラグを判定し、識別フラグがセットされたスケジュールに対応する制御信号を赤色用の制御信号ではなく、黄色用の制御信号とする。これにより、図５（ｂ）に示すように、ＬＥＤ２７は、他人により登録された（自動登録された）スケジュールに対応するタイミングにおいて赤色ではなく黄色で点灯する。たとえば、図３（ｂ）に示すように、予定当日の３つ目のスケジュールと６つ目のスケジュールが他人による登録である場合、ＬＥＤ２７の３回目と６回目の点灯が黄色になる。
【００６６】
また、本実施の形態では、ユーザは、報知時刻を所望の時刻に設定できる。上述のように、報知時刻が、その日の最初のスケジュールよりも早い時刻（午前６時）に設定された場合には、報知実行時に完了しているスケジュールはないが、たとえば、その日の午後５時に報知時刻が設定された場合には、報知実行時にすでに予定時刻が経過したスケジュールも出てくる。
【００６７】
そこで、ステップＳ１０４の処理によるスケジュール件数の報知形態は、図６（ａ）、（ｂ）に示すものに変更することもできる。
【００６８】
図６（ａ）の報知形態では、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出するとともに、予定時刻を報知時刻と比較する。そして、報知時刻より前のスケジュールに対応する制御信号として、赤色用の制御信号ではなく黄色用の制御信号を出力する。これにより、図６（ａ）に示すように、ＬＥＤ２７は、報知時刻より前のスケジュールに対応するタイミングにおいて、赤色ではなく黄色で点灯する。たとえば、報知時刻が午後５時であり、図３（ｂ）に示すように、１件から５件分のスケジュールの予定時刻が報知時刻より早い場合には、報知時刻のタイミングで既に５件のスケジュールの予定時刻が経過しているので、ＬＥＤ２７は、５回目までは黄色で点滅し、６回目と７回目は赤色で点滅する。
【００６９】
図６（ｂ）の報知形態とする場合には、まず、ステップＳ１０２において、ＣＰＵ１００は、予定当日一日のスケジュールのうち、予定時刻が報知時刻より後のスケジュール項目（予定日、予定時刻、登録日、登録時刻および識別フラグ）を、メモリ１０６のスケジュールテーブルから抽出する。たとえば、報知時刻が午後５時であれば、図３（ｂ）に示す最後の２件のスケジュールのみが抽出される。
【００７０】
そして、ステップＳ１０４の処理において、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出し、図６（ｂ）に示すように、算出したスケジュール件数分の赤色用の制御信号を出力する。これにより、報知時刻から予定当日の終わりまでのスケジュール、即ち、その日に残っているスケジュール件数の回数だけＬＥＤ２７が点滅する。
【００７１】
以上、本実施の形態によれば、ユーザは、ＬＥＤ２７の点滅回数（オン／オフ回数）を見ることにより、スケジュール件数を容易に把握することができる。特に、多忙な状況の中、ユーザがスケジュールの確認に十分注力できなくても、ＬＥＤ２７が点滅する形態であれば、容易にある程度の感知がなされ得るため、ユーザは、多忙な状況下でも、大まかなスケジュール状態を、容易に把握することができる。
【００７２】
また、図５（ｂ）のような報知形態とすれば、ユーザは、自ら登録していないため事前に把握しにくいスケジュールの存在を容易に把握することができる。
【００７３】
なお、他人によるスケジュールの登録が予定当日になされた場合には、特に事前の把握が難しくなる。そこで、図５（ｂ）の報知形態では、他人により当日登録されたスケジュールをユーザが的確に把握できるよう、識別フラグとともに登録日をもＣＰＵ１００において判定し、他人によって当日に登録されたスケジュールを、他人によって当日以外の日に登録されたスケジュールに対し、ＬＥＤ２７の発光色を変えるようにしても良い。
【００７４】
さらに、図６（ａ）の報知形態とすれば、ユーザは、予定当日一日のスケジュール全件のうち、何件のスケジュールが遂行状態にあり、今後何件のスケジュールが残っているのかを容易に把握することができる。
【００７５】
さらに、図６（ｂ）の報知形態とすれば、ユーザは、今後予定されているスケジュールの件数のみを把握することができる。
【００７６】
ところで、上記実施の形態では、ＬＥＤ２７の点滅周期が一定とされている。このため、上記実施の形態による報知では、スケジュール件数の把握は行えるが、個々のスケジュールの予定時刻までは把握できない。
【００７７】
そこで、各スケジュールの予定時刻が加味された報知形態となるよう、上記実施の形態のステップＳ１０４の処理による報知形態を、さらに、以下の変更例１のように変更することができる。
【００７８】
＜変更例１＞
図７から図９は、変更例１に係るスケジュールの報知形態について説明するための図である。図７は基本となる報知形態を示し、図８および図９は、そのバリエーションとなる報知形態を示す。
【００７９】
この報知形態では、図７（ａ）に示すように、スケジュール件数を報知するための報知時間Ｔが一定時間に固定されており、この報知時間Ｔを一日とみなして、これを１２の区間に区分し、１区間ｔが１日中の２時間の時間帯に対応するように構成されている。たとえば、報知時間Ｔが１２秒とされた場合、２時間の時間帯に対応する区間ｔは、１秒となる。
【００８０】
ＣＰＵ１００は、ステップＳ１０４の処理において、抽出したデータから、個々のスケジュールの予定時刻を判定し、この予定時刻を含む時間帯において制御信号が出力されるよう、制御信号の出力タイミングを決める。
【００８１】
たとえば、図３（ｂ）に示す抽出データの場合には、１４時から１６時の時間帯、１６時から１８時の時間帯、２０時から２２時の時間帯および２２時から２４時の時間帯にスケジュールの予定時刻が１つ含まれる。よって、図７（ａ）に示すように、これらの時間帯に対応する区間ｔにおいて、それぞれ１つの制御信号がＣＰＵ１００から出力される。また、図３（ｂ）の抽出データでは、１０時から１２時の時間帯には、２つの予定時刻が含まれる。よって、図７（ａ）に示すように、この時間帯に対応する区間ｔにおいて、２つの制御信号がＣＰＵ１００から出力される。こうして、ＬＥＤ２７は、報知時間Ｔの中で、予定時刻の時間帯に対応したタイミングで点灯することになる。
【００８２】
このように、変更例１に係る報知形態とすれば、各スケジュールに対応するＬＥＤ２７の点灯タイミングが、そのスケジュールの予定時刻を反映したものとなるため、ユーザは、報知時間Ｔ（１報知サイクル期間）中のどのあたりで出力がなされたかによって、各スケジュールがどの時間帯に含まれるかを感覚的に把握することができる。また、この出力によって、どの時間帯にスケジュールが密集しており、どの時間帯ではスケジュールが空いているか等の情報を大まかに把握することができる。
【００８３】
なお、制御信号のオン／オフ周期は、図７（ｂ）に示すように、一つの時間帯中に含まれるスケジュールの件数が少ない場合は、基準周期、たとえば、０．５秒周期（０．２５秒オン−０．２５秒オフ）となる。この場合、上記のように一つ時間帯に対応する区間ｔが１秒であれば、スケジュール２件まではこの基準周期で制御信号が出力され、ＬＥＤ２７が基準周期で点滅する。
【００８４】
一方、同図（ｃ）、（ｄ）に示すように、一つの時間帯中に含まれるスケジュールの件数が多くなると、制御信号のオン／オフ周期が、その件数に合わせて短くなるように、自動的に調整される。よって、スケジュール件数が多くなれば、それに合わせて、ＬＥＤ２７の点滅周期が短くなる。
【００８５】
そして、一つの時間帯中に含まれるスケジュールの件数がかなり多くなり、回路的にＬＥＤ２７をオン／オフ駆動することができないほどにまで短いオン／オフ周期になると、制御信号は、同図（ｅ）に示すように、オン／オフされずに、その時間帯に対応する区間ｔにおいて出力され続ける。これにより、ＬＥＤ２７は、その区間ｔにおいて連続的に点灯する。
【００８６】
変更例１に係る報知形態は、さらに、図８（ａ）、（ｂ）に示すものに変更することもできる。
【００８７】
図８（ａ）の報知形態では、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出するとともに、予定時刻を予め設定された参照時刻と比較する。そして、ＣＰＵ１００は、参照時刻、ここでは一日の中間となる正午（午後１２時）より前のスケジュールに対応する制御信号として、赤色用の制御信号ではなく、青色用の制御信号をＬＥＤ駆動回路１１１に出力する。これにより、図８（ａ）に示すように、ＬＥＤ２７は、正午より前のスケジュールに対応するタイミングにおいて、赤色ではなく青色で点灯する。
【００８８】
図８（ｂ）の報知形態では、ＣＰＵ１００は、予め設定された参照時刻（ここでは正午のタイミング）に黄色の制御信号を出力する。これにより、ＬＥＤ２７は、正午の時刻のタイミングにおいて黄色で点灯する。スケジュールに対応するタイミングでは、図７の場合と同様、赤色でＬＥＤ２７が点灯される。
【００８９】
このように、図８（ａ）、（ｂ）の報知形態とすれば、ユーザは、参照時刻を境にしてそれより前に何件程度のスケジュールがあり、それより後に何件程度のスケジュールがあるかを容易に把握することができる。たとえば、上記のように参照時刻が正午であれば、ユーザは、午前中に何件のスケジュールがあり、午後に何件のスジュールがあるのかを、容易に把握することができる。
【００９０】
変更例１に係る報知形態は、さらに、図９に示すものとすることもできる。
【００９１】
図９の報知形態では、ＣＰＵ１００は、抽出したデータからスケジュール件数を算出するとともに、各スケジュールの予定時刻同士を比較する。そして、ＣＰＵ１００は、互いに重複した予定時刻（いわゆるダブルブッキング）があれば、そのスケジュールに対応する制御信号として、赤色用の制御信号ではなく、青色用の制御信号をＬＥＤ駆動回路１１１に出力する。これにより、同図に示すように、ＬＥＤ２７は、重複したスケジュールに対応するタイミングにおいて赤色ではなく青色で点灯する。
【００９２】
このような報知形態とすれば、ユーザは、予定時刻が重複するスケジュール（ダブルブッキング）があることを容易に把握することができる。
【００９３】
さらに、変更例１の構成においては、図５（ｂ）および図６に示す上記実施の形態のバリエーションの構成を適用することができる。即ち、変更例１の構成に図５（ｂ）に示す構成を適用することにより、他人により登録されたスケジュールに対応して点灯されるＬＥＤ２７の色をその他のスケジュールに対応して点灯されるＬＥＤ２７の色と異ならせる構成とすることができる。また、変更例１の構成に図６（ａ）に示す構成を適用することにより、報知時刻の前後でＬＥＤ２７の色を異ならせる構成とすることもできる。さらに、変更例１の構成に図６（ｂ）に示す構成を適用することで、その日のスケジュールのうち、報知時刻より後のスケジュールのみを報知させる構成とすることもできる。
【００９４】
反対に、上記実施の形態に、図８および図９に示す変更例１のバリエーションの構成を適用することもできる。即ち、上記実施の形態に図８に示す構成を適用することにより、参照時刻、たとえば、正午（午後１２時）の前後でＬＥＤ２７の色を変えたり、参照時刻を示すＬＥＤ２７の点灯を行ったりする構成とすることができる。また、上記実施の形態に図９に示す構成を適用することにより、予定時刻が重複した場合に、そのスケジュールに対応して点灯されるＬＥＤ２７の色を、他のスケジュールに対応して点灯されるＬＥＤ２７の色と異ならせる構成とすることもできる。
【００９５】
さて、上記実施の形態および変更例１では、スケジュールが抽出される期間を予定当日としているが、以下に示す変更例２のように、スケジュール抽出期間を報知時刻から一定時間とすることもできる。
【００９６】
＜変更例２＞
図１０は、変更例２に係るＬＥＤによるスケジュールの報知形態について説明するための図である。
【００９７】
変更例２では、スケジュール抽出期間が報知時刻から一定時間、たとえば１時間とされているとともに、変更例１と同様、報知時間Ｔが一定時間に固定されている。図１０に示すように、スケジュール抽出期間が１時間とされた場合、この報知時間Ｔを１時間とみなして、これを１２の区間に区分し、１区間ｔあたり５分の時間帯となるように構成されている。たとえば、報知時間Ｔが１２秒とされた場合、５分の時間帯に対応する区間ｔは１秒となる。
【００９８】
こうして、同図に示すように、報知時刻から１時間以内に予定時刻があるスケジュールがあれば、そのスケジュールの予定時刻に対応するタイミングでＬＥＤ２７が点灯する。
【００９９】
さらに、上記実施の形態では、ユーザよって予め設定された報知時刻にスケジュール報知が行われる構成である、報知が実行される条件を、以下の変更例３のように変更することができる。
【０１００】
＜変更例３＞
図１１は、変更例３に係るスケジュール簡易報知機能の制御処理を示すフローチャートである。同図（ａ）は、第２キャビネットが開放される回数（フリップオープンの回数）に基づいて報知を行う例を示し、同図（ｂ）は、キー操作に基づいて報知する例を示す。なお、同図（ａ）、（ｂ）の処理は、たとえば、予定当日の開始時点に開始される。
【０１０１】
同図（ａ)の例では、処理が開始されると、ＣＰＵ１００は、フリップオープン回数が規定回数Ｎになったか否かを判断する（Ｓ１１１）。
【０１０２】
ユーザが一日の活動を始め、携帯電話機が使用され始めると、第２キャビネット２が開いたり閉じたりされる。そこで、フリップ回数が規定回数Ｎになれば、ユーザによって携帯電話機が使用されており、その際にスケジュール報知を行えば、それがユーザに知られ得ると判断することができる。
【０１０３】
ＣＰＵ１００は、フリップオープン回数が規定回数Ｎに達したと判断すると（Ｓ１１１：ＹＥＳ）、さらに、第２キャビネット２が閉じられたか(フリップクローズか)否かを判断する（Ｓ１１２）。
【０１０４】
通話やメール発信等が終わり、ユーザによって第２キャビネット２が閉じられると（Ｓ１１２：ＹＥＳ）、ＣＰＵ１００は、メモリ１０６からのスケジュール抽出を行う（Ｓ１０２）。
【０１０５】
このような構成とすれば、ユーザが意図的に操作しなくても、ユーザが知り得る適正なタイミングでスケジュール報知を行うことができる。
【０１０６】
次に、図１１（ｂ)の例では、処理が開始されると、ＣＰＵ１００は、報知のためのキー操作がされたか否かを判断する（Ｓ１２１）。
【０１０７】
ユーザは、スケジュール件数を知りたいタイミングで、報知のためのキー操作を行う。たとえば、ユーザは、携帯電話機の側面に設けられたサイドキー（図示せず）を３秒間押す（長押しを行う）。
【０１０８】
ＣＰＵ１００は、報知のためのキー操作がなされたと判断すると（Ｓ１２１：ＹＥＳ）、メモリ１０６からのスケジュール抽出を行う（Ｓ１０２）。
【０１０９】
このような構成とすれば、ユーザは、所望のタイミングでスケジュールの確認を行うことができる。
【０１１０】
なお、変更例３（図１１（ａ）、（ｂ）の例）の構成において、ステップＳ１０２からＳ１０６の処理については、上記実施の形態と同様であり、ステップＳ１０４の処理では、上記実施の形態や変更例１に示すような報知形態にて、スケジュールが報知される。
【０１１１】
なお、ステップＳ１０４の処理によりスケジュール報知を行う場合に、報知時刻から直近の一定時間（たとえば、１時間）のスケジュールに対応して点灯されるＬＥＤ２７の色を他の時間のスケジュールに対応して点灯されるＬＥＤ２７の色と異ならせるようにしても良い。また、特に、図１１（ａ）の構成とした場合に、ステップＳ１０３の開始報知の処理において、ＬＥＤ２７の緑色での点灯とともに音による報知を行うようにすれば、スケジュール報知が開始されることをユーザに確実に知らせることができる。
【０１１２】
＜その他＞
本発明の実施形態は、上記以外にさらに、以下のように種々の変更が可能である。
【０１１３】
上記実施の形態では、電話や電子メールの着信時にもＬＥＤ２７が点灯する構成であるため、スケジュール報知時に電話等の着信がある場合がある。そこで、スケジュール報知の途中に、電話等の着信があった場合には、スケジュール報知を中断し、ＬＥＤ２７を着信報知のための点灯に切り替えるような構成としても良い。この場合、その後、適宜のタイミングで、メイン表示パネル２１にポップアップ形式等にてスケジュール件数等を報知することが望ましい。あるいは、スケジュール報知の途中に、電話等の着信があった場合に、スケジュール報知を中断せず、それまでの色と異なる色でＬＥＤ２７を点灯させ、スケジュール報知と着信報知とを兼ねた報知を行うような構成としても良い。
【０１１４】
また、上記実施の形態の構成に加え、スケジュールの緊急度や重要度等に係る情報がスケジュールテーブルに登録されるようにし、これらの情報に応じたＬＥＤ２７の点灯が行われるようにしても良い。たとえば、午後１時から午後１０時までの続くような長い会議がある場合、このような会議は、一日の大半のスケジュールを占めるので重要と考えられる。そこで、この場合には、ＬＥＤ２７を七色（１回の点灯で七色に移り変わる）に点灯させるなど、ＬＥＤ２７を、単なる色変え程度ではない特別な形態で点灯させることができる。
【０１１５】
さらに、上記実施の形態では、スケジュール報知がＬＥＤ２７により行われる構成とされているが、これ限らず、たとえば、サブ表示パネル２３を点滅させるような構成としても良い。また、ＬＥＤ２７やサブ表示パネル２３を用いた光による報知ではなく、スピーカ１１０を用いた音による報知、あるいは振動装置１１２を用いた振動による報知としても良い。さらには、光、音、振動による報知を適宜組み合わせる構成としても良い。
【０１１６】
さらに、上記実施の形態や、変更例１、変更例２において、種々の報知形態について説明したが、これら報知形態の中から、ユーザが所望のものを選択できる構成としても良い。また、報知するための条件を、設定した報知時刻とするか、フリップオープン回数とするか、キー操作とするか、ユーザが選択できる構成としても良い。
【０１１７】
さらに、本発明の情報処理装置は、携帯電話機に限られず、ＰＤＡ（Personal Digital Assistant）等であっても良い。
【０１１８】
この他、本発明の実施の形態は、特許請求の範囲に示された技術的思想の範囲内において、適宜、種々の変更が可能である。
【図面の簡単な説明】
【０１１９】
【図１】実施の形態に係る携帯電話機の外観構成を示す図
【図２】実施の形態に係る携帯電話機の全体構成を示すブロック図
【図３】実施の形態に係るスケジュールテーブルの構成を示す図
【図４】実施の形態に係るスケジュール簡易報知機能の制御処理を示すフローチャート
【図５】実施の形態に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図６】実施の形態に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図７】変更例１に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図８】変更例１に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図９】変更例１に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図１０】変更例２に係るＬＥＤによるスケジュールの報知形態について説明するための図
【図１１】変更例３に係るスケジュール簡易報知機能の制御処理を示すフローチャート
【符号の説明】
【０１２０】
２７ ＬＥＤ（報知手段）
１００ ＣＰＵ（抽出手段、報知手段）
１０５ 通信モジュール（受信手段）
１０６ メモリ（記憶手段）
【特許請求の範囲】
【請求項１】
予定日時に対応づけてスケジュールを記憶する記憶手段と、
所定期間内に含まれる前記スケジュールを前記記憶手段から抽出する抽出手段と、
抽出された前記スケジュールに基づいて報知のための出力をオン／オフ制御する報知手段と、
を備えたことを特徴とする情報処理装置。
【請求項２】
請求項１において、
前記報知手段は、抽出された前記スケジュールの個数に応じた回数の前記出力を、１回の報知サイクルにおいて行う、
ことを特徴とする情報処理装置。
【請求項３】
請求項２において、
前記報知手段は、前記期間における時間軸上の前記スケジュールの出現タイミングに応じて前記出力のタイミングを制御する、
ことを特徴とする情報処理装置。
【請求項４】
請求項２または３において、
前記報知手段は、抽出された前記スケジュールが報知の実行時よりも前か後かに応じて前記出力の形態を変化させる、
ことを特徴とする情報処理装置。
【請求項５】
請求項２または３において、
前記報知手段は、予め設定された参照時刻より前の前記スケジュールに対する前記出力の形態と後の前記スケジュールに対する前記出力の形態を異ならせる、
ことを特徴とする情報処理装置。
【請求項６】
請求項２または３において、
前記報知手段は、予め設定された参照時刻を報知するための出力を、前記スケジュールの報知のための形態とは異なる形態で実行し、前記参照時刻より前のスケジュールに対する前記出力と後のスケジュールに対する前記出力を、前記参照時刻を報知する出力を挟んで実行する、
ことを特徴とする情報処理装置。
【請求項７】
請求項２ないし６の何れか一項において、
前記抽出手段は、報知の実行時よりも後のスケジュールを抽出する、
ことを特徴とする情報処理装置。
【請求項８】
請求項１ないし７の何れか一項において、
外部から情報を受信する受信手段をさらに備え、
前記記憶手段は、前記受信手段を介して取得した前記スケジュールとその取得形態を示す情報を予定日時に対応づけて記憶し、
前記報知手段は、前記受信手段を介して取得したスケジュールに対する前記出力をその他の前記スケジュールに対する前記出力と異なる形態にて実行する、
ことを特徴とする情報処理装置。
【請求項９】
請求項１ないし８の何れか一項において、
前記出力は、光、音、振動、または、これらを組み合わせたものである、
ことを特徴とする情報処理装置。
【請求項１０】
請求項１ないし９の何れか一項において、
前記報知手段は、本体装置が使用状態にあるかを判別し、使用状態にあるときの所定のタイミングで、前記報知を実行する、
ことを特徴とする情報処理装置。
【請求項１】
予定日時に対応づけてスケジュールを記憶する記憶手段と、
所定期間内に含まれる前記スケジュールを前記記憶手段から抽出する抽出手段と、
抽出された前記スケジュールに基づいて報知のための出力をオン／オフ制御する報知手段と、
を備えたことを特徴とする情報処理装置。
【請求項２】
請求項１において、
前記報知手段は、抽出された前記スケジュールの個数に応じた回数の前記出力を、１回の報知サイクルにおいて行う、
ことを特徴とする情報処理装置。
【請求項３】
請求項２において、
前記報知手段は、前記期間における時間軸上の前記スケジュールの出現タイミングに応じて前記出力のタイミングを制御する、
ことを特徴とする情報処理装置。
【請求項４】
請求項２または３において、
前記報知手段は、抽出された前記スケジュールが報知の実行時よりも前か後かに応じて前記出力の形態を変化させる、
ことを特徴とする情報処理装置。
【請求項５】
請求項２または３において、
前記報知手段は、予め設定された参照時刻より前の前記スケジュールに対する前記出力の形態と後の前記スケジュールに対する前記出力の形態を異ならせる、
ことを特徴とする情報処理装置。
【請求項６】
請求項２または３において、
前記報知手段は、予め設定された参照時刻を報知するための出力を、前記スケジュールの報知のための形態とは異なる形態で実行し、前記参照時刻より前のスケジュールに対する前記出力と後のスケジュールに対する前記出力を、前記参照時刻を報知する出力を挟んで実行する、
ことを特徴とする情報処理装置。
【請求項７】
請求項２ないし６の何れか一項において、
前記抽出手段は、報知の実行時よりも後のスケジュールを抽出する、
ことを特徴とする情報処理装置。
【請求項８】
請求項１ないし７の何れか一項において、
外部から情報を受信する受信手段をさらに備え、
前記記憶手段は、前記受信手段を介して取得した前記スケジュールとその取得形態を示す情報を予定日時に対応づけて記憶し、
前記報知手段は、前記受信手段を介して取得したスケジュールに対する前記出力をその他の前記スケジュールに対する前記出力と異なる形態にて実行する、
ことを特徴とする情報処理装置。
【請求項９】
請求項１ないし８の何れか一項において、
前記出力は、光、音、振動、または、これらを組み合わせたものである、
ことを特徴とする情報処理装置。
【請求項１０】
請求項１ないし９の何れか一項において、
前記報知手段は、本体装置が使用状態にあるかを判別し、使用状態にあるときの所定のタイミングで、前記報知を実行する、
ことを特徴とする情報処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１０−３４９０３（Ｐ２０１０−３４９０３Ａ）
【公開日】平成２２年２月１２日（２０１０．２．１２）
【国際特許分類】
【出願番号】特願２００８−１９５５１６（Ｐ２００８−１９５５１６）
【出願日】平成２０年７月２９日（２００８．７．２９）
【出願人】（０００００６６３３）京セラ株式会社 (13,660)
【Ｆターム（参考）】
【公開日】平成２２年２月１２日（２０１０．２．１２）
【国際特許分類】
【出願日】平成２０年７月２９日（２００８．７．２９）
【出願人】（０００００６６３３）京セラ株式会社 (13,660)
【Ｆターム（参考）】
[ Back to top ]