JP2009033495A - 通信端末装置及びプログラム - Google Patents

Abstract

【課題】通信を行うことをユーザが意識しなくても、通信が必要なときに必要な相手を案内できるようにする。
【解決手段】ＣＰＵ１は、発信履歴テーブルＣＬの内容に基づいて次回の通信タイミングを決定するほか、この通信タイミングで通信を行う相手を通信候補相手として特定し、この通信タイミングにおいて当該通信候補相手への通信要否を案内報知する。
【選択図】 図１

Description

この発明は、通信機能を備えた通信端末装置及びプログラムに関する。

近年、通信端末装置としての携帯電話装置は、気楽なコミュニケーションツールとして頻繁に使われており、人によっては電子メールを送信するタイミング、電話をするタイミングとその相手が略決められている場合が多い。例えば、通勤電車に乗った直後に電子メールを送信する相手が決められていたり、仕事の昼休み時間や１５時の休み時間などに電話する相手が決められていたり、毎週土曜日の午前中に親元に電話したりするなど、略決められている場合が多い。このような場合、従来においては、電子メールを送信する際に前回送信した宛先を自動設定することによって必要な相手に直ちにメールを送信するようにした技術が知られている（特許文献１参照）。
特開２００５−１１０８７号公報

しかしながら、上述した先行技術では、電子メール機能を起動していることが前提となるため、その起動自体を忘れているような場合にはその相手にメールを送信することができなくなってしまう。
この発明の課題は、通信を行うことをユーザが意識しなくても、通信が必要なときに必要な相手を案内できるようにすることである。

請求項１記載の発明は、通信機能を備えた通信端末装置であって、通信相手との過去の通信履歴を記憶する記憶手段と、この通信履歴記憶手段の内容に基づいて次回の通信タイミングを決定する決定手段と、この決定手段によって決定された通信タイミングで通信を行う相手を通信候補相手として特定する特定手段と、前記決定手段によって決定された通信タイミングにおいて、前記特定手段によって特定された通信候補相手への通信要否を案内報知する報知手段とを具備したことを特徴とする。
更に、コンピュータに対して、上述した請求項１記載の発明に示した主要機能を実現させるためのプログラムを提供する（請求項９記載の発明）。

なお、上述した請求項１記載の発明は次のようなものであってもよい。
前記通信履歴記憶手段は、通信を実行した際の通信日時とその通信相手とを含む通信履歴を記憶し、前記特定手段は、予め決められている相手を前記通信タイミングでの通信候補相手として特定し、前記決定手段は、前記特定手段によって特定された通信候補相手に対応する前記通信履歴を参照し、その通信日時から次回の通信タイミングを決定する（請求項２記載の発明）。

前記決定手段は、前記通信履歴を参照し、同一の通信相手と複数回の通信が行われている場合に、その各通信日時に共通する時間的要素が含まれていれば、当該共通要素に基づいて次回の通信タイミングを決定し、前記特定手段は、前記複数回の通信が行われた相手を通信候補相手として特定する（請求項３記載の発明）。

前記通信履歴記憶手段は、通信を実行した際の通信日時とその通信相手とを含む通信履歴を記憶し、前記特定手段は、前記特定手段によって特定された通信候補相手に対応する前記通信履歴を参照し、その最新の通信日時からの経過時間に基づいて次回の通信タイミングを決定する（請求項４記載の発明）。

現在の環境状況を取得する環境状況取得手段と、前記通信履歴記憶手段は、通信を実行した際に前記取得した環境状況とその通信相手とを含む通信履歴を記憶し、前記報知手段は、前記決定手段によって決定された通信タイミングにおいて、前記取得した現在の環境状況が前記通信履歴としての環境状況に該当したことを条件に前記通信候補相手への通信要否を案内報知する（請求項５記載の発明）。

現在の動作状況を取得する動作状況取得手段と、前記通信履歴記憶手段は、通信を実行した際に前記取得した動作状況とその通信相手とを含む通信履歴を記憶し、前記報知手段は、前記決定手段によって決定された通信タイミングにおいて、前記取得した動作状況が前記通信履歴としての動作状況に該当したことを条件に前記通信候補相手への通信要否を案内報知する（請求項６記載の発明）。

前記通信履歴記憶手段は、通信を実行した際にその通信機能の種別とその通信日時とその通信相手とを含む通信履歴を記憶し、前記報知手段は、通信候補相手への通信要否を案内報知するほか、通信機能の種別を案内報知する（請求項７記載の発明）。

前記報知手段によって通信候補相手への通信要否の案内報知に応答して通信要がユーザ指示された際に、通信機能を起動して当該通信候補相手との通信を実行する（請求項８記載の発明）。

この発明は、通信を行うことをユーザが意識しなくても、通信が必要なときに必要な相手を案内することができ、速やかな通信と共に、ユーザの負担を軽減することが可能となる。

以下、図１〜図８を参照して本発明の実施例を説明する。
この実施例は、通信端末装置として携帯電話装置に適用した場合を例示したもので、図１は、この携帯電話装置の基本的な構成要素を示したブロック図である。
この携帯電話装置は、例えば、２つの筐体（操作部筐体、表示部筐体）が開閉可能に取り付けられた折り畳み自在なもので、通話機能（電話機能）、電子メール機能、インターネット接続機能（Ｗｅｂアクセス機能）など、各種の機能が備えられている。

ＣＰＵ１は、記憶部２内の各種のプログラムに応じてこの携帯電話装置の全体動作を制御する中核的な中央演算処理装置である。記憶部２は、内部メモリであり、プログラム領域とデータ領域とを有し、このプログラム領域には、後述する図５〜図７に示す動作手順に応じて本実施例を実現するためのプログラムが格納され、また、そのデータ領域には、通信相手毎にその相手の名前、電話番号などを記憶する電話帳ＡＤのほか、後述する発信履歴テーブルＣＬ、相手別条件テーブルＰＴ、案内テーブルＧＤなどが格納されている。記録メディア３は、着脱自在な可搬型メモリで、例えば、ＳＤカード、ＩＣカードなどによって構成されている。メモリ４は、ワーク領域を有する内部メモリで、必要に応じてメモリ４内の各種のデータは、記憶部２にセーブされる。

電話通信部５は、無線部を構成するアンテナに接続された送受信部（ベースバンド部）の受信側から信号を取り込んで受信ベースバンド信号に復調したのち、音声制御部６を介して受話スピーカＳＰから音声出力させる。また、電話通信部５は、送話マイクＭＣからの入力音声を音声制御部６から取り込み、送信ベースバンド信号に符号化したのち、送受信部の送信側に与えてアンテナから発信出力させる。一方、電子メール機能、インターネット接続機能によって電話通信部５を介して受信取得した表示データは、表示制御部７を介して高精細液晶、有機ＥＬなどを使用したメイン表示部８に与えられて表示出力される。なお、サブ表示部９は現在日時、簡易なメッセージ、アイコンなどを表示するもので、装置本体を閉じた状態でも視認可能なものである。

操作部１０は、ダイヤル入力、文字入力、コマンド入力などを行うもので、ＣＰＵ１は、操作部１０からのキー入力信号に応じた処理を実行する。報知部１１は、サウンドスピーカ、ＬＥＤ（発光ダイオード）、振動モータを備え、電話あるいはメール着信時に駆動されて着信報知を行うほか、アラーム報知時にも駆動される。なお、電話あるいはメール着信時に、スピーカからの着信報知に代わって振動モータによるバイブレーション報知を行う“マナーモード”がユーザ操作によって任意に設定／解除されると、ＣＰＵ１は、この設定／解除に応じて着信報知の仕方を変更するようにしている。ＲＴＣ（リアルタイムクロックモジュール）１２は、時計部を構成するもので、ＣＰＵ１は、ＲＴＣ１２から現在の時刻情報（日時情報を含む）を取得する。ＧＰＳ（Global Positioning System）部１３は、衛星と地上の制御局を利用し、現在の位置情報（経緯度情報）を受信するもので、ＣＰＵ１は、例えば、一定時間毎にＧＰＳ部１３をアクセスしながら現在位置を監視するようにしている。

図２は、発信履歴テーブルＣＬを説明するための図である。
発信履歴テーブルＣＬは、発信毎（電話機能を起動して音声発信を行う毎あるいは電子メール機能を起動してメール送信を行う毎）に、その発信履歴（何時、誰に、どのような状況で電話あるいはメールを行ったか）を記憶するもので、この履歴レコードは、「日」、「時」、「曜日」、「発信先」、「環境（位置）」、「動作状況」、「通信種別」の各項目を有している。「日」、「時」、「曜日」は、発信日時を示す情報であり、「日」はその月日情報、「時」はその時分情報、「曜日」は曜日情報である。「発信先」は通信相手を示す情報（例えば、電話番号、メールアドレス）である。「環境（位置）」はＧＰＳ部１３で取得した発信場所（例えば、自宅あるいは会社）を示す現在の位置情報である。「動作状況」は例えば、上述した“マナーモード”が設定されている動作状況あるいはそれが解除されている動作状況など、発信時における現在の動作状況を示す情報である。「通信種別」は電話機能による音声発信を行った場合か電子メール機能によるメール送信を行った場合かの発信種別（電話／メール）を示す情報である。

この発信履歴テーブルＣＬの内容に基づいてＣＰＵ１は、次回の通信タイミング（電子メールを送信するタイミングあるいは電話をするタイミング）を決定するほか、この通信タイミングで通信する相手を通信候補相手として特定して、この通信タイミングで当該通信候補相手への通信要否を案内報知するようにしている。この通信要否の案内報知は、特定された通信候補相手に対応する履歴レコード内の「環境（位置）」、「動作状況」が現在の位置、現在の動作状態に一致していることを条件に行われる。なお、この実施例では、発信履歴テーブルＣＬのほかに、後述する相手別条件テーブルＰＴを参照することによって通信タイミングの決定と通信候補相手の特定を行う場合と、相手別条件テーブルＰＴを参照せずに、発信履歴テーブルＣＬの内容から通信タイミングの決定と通信候補相手の特定を行う場合とがある。

図３は、相手別条件テーブルＰＴを説明するための図である。
相手別条件テーブルＰＴは、例えば、得意先などのように重要な通信相手に対して定期的に連絡するような場合に、その相手別にその発信条件を記憶するためのテーブルで、「相手」、「時間条件」、「状況」の各項目を有している。言い換えれば、相手別条件テーブルＰＴは、過去と同じ時間帯に発信したい、同じ曜日に発信したい、一定の時間間隔毎に発信したい場合に、それを発信条件として相手別に記憶するテーブルである。「時間条件」は更に「時間帯」、「曜日帯」、「時間間隔」の各項目を有し、「状況」は更に「環境」、「動作」の各項目を有している。この「時間帯」、「曜日帯」、「時間間隔」、「環境」、「動作」の各項目のうち、所望する項目を任意に選択可能となっており、図中、丸印はユーザ操作によって任意に選択された項目を示している。

この「時間条件」としての「時間帯」は、過去と同じ時間帯に発信したい場合に選択される条件項目である。「時間条件」としての「曜日帯」は過去と同じ曜日に発信したい場合に選択され、「時間間隔」は一定の時間間隔毎に発信したい場合に選択される条件項目である。なお、「時間条件」として「時間間隔」を選択した場合には、例えば、６時間などのようにその具体的なデータも設定するようにしている。また、「状況」としての「環境」は、現在の位置が発信履歴の「環境（位置）」に一致することを条件に上述した通信要否の案内報知を希望する場合に選択される項目であり、「状況」としての「動作」は、現在の動作状態が発信履歴の「動作状況」に一致することを条件に上述した通信要否の案内報知を希望する場合に選択される項目である。なお、「環境」、「動作」のいずれの項目も選択されていない場合には、現在の状況を考慮せずに通信要否の案内報知することを示している。

図示の例は、通信相手の“Ａ”に対応してその条件として「時間帯」が選択され、「状況」として「環境」が選択された場合を示し、また、通信相手の“Ｂ”に対応してその条件として「曜日帯」が選択され、また、通信相手の“Ｃ”に対応してその条件として「時間間隔」が選択され、「状況」として「動作」が選択された場合を示している。なお、相手別条件テーブルＰＴに「相手」として設定された以外の相手については、この相手別条件テーブルＰＴの内容に関わらず、「環境」及び「動作」のいずれも選択するようにしているが、そのいずれか一方を固定的に選択するようにしてもよい。

図４は、案内テーブルＧＤを説明するための図である。
案内テーブルＧＤは、次回の通信タイミングに通信候補相手への通信要否を案内する案内データを記憶するもので、「次回日時」、「相手」、「種別」、「環境」、「動作」の各項目を有している。ＣＰＵ１は、上述のようにして次回の通信タイミングを決定すると共に通信候補相手を特定した際に、これらを通信要否案内用のデータとして案内テーブルＧＤにセットするようにしている。「次回日時」は次回の通信タイミングを示し、「相手」は通信タイミングで通信を行う通信候補相手を示している。「種別」は電話かメールかの通信種別を示している。「環境」、「動作」は上述した通信要否の案内報知時に、現在の環境（位置）、現在の動作状況に応じてその案内報知を行うか否かを示している。この案内テーブルＧＤは定期的に作成されたもので、この案内テーブル作成処理は例えば、１週間に１回実行するようにしている。

次に、この実施例における携帯電話装置の動作概念を図５〜図７に示すフローチャートを参照して説明する。ここで、これらのフローチャートに記述されている各機能は、読み取り可能なプログラムコードの形態で格納されており、このプログラムコードにしたがった動作が逐次実行される。また、伝送媒体を介して伝送されてきた上述のプログラムコードに従った動作を逐次実行することもできる。すなわち、記録媒体のほかに、伝送媒体を介して外部供給されたプログラム／データを利用してこの実施例特有の動作を実行することもできる。
なお、図５〜図７は、携帯電話装置の全体動作のうち、本実施例の特徴部分の動作概要を示したフローチャートであり、この図５〜図７のフローから抜けた際には、全体動作のフロー（図示省略）に戻る。

図５及び図６は、定期的（例えば、１週間毎）に実行開始される案内テーブル作成処理を示したフローチャートである。なお、発信履歴テーブルＣＬには、図４に示すような各履歴レコードが記録されているものとして、以下、発信履歴テーブルＣＬの内容を参照しながら案内テーブル作成処理を具体的に説明するものとする。
先ず、ＣＰＵ１は、ＲＴＣ１２から現在日時を取得すると共に（ステップＡ１）、発信履歴テーブルＣＬの各履歴レコードのうち、現在日時から１週間前の各履歴レコードを検索対象範囲として指定しておく（ステップＡ２）。例えば、現在日時が“８月５日（月曜）８時００分”であるとすると、“７月３０日（月曜）８時００分”から現在日時までの各履歴レコードが検索対象範囲として指定される。

この状態において、相手別条件テーブルＰＴの先頭から１つの「相手」を指定して読み出すと共に（ステップＡ３）、発信履歴テーブルＣＬの検索対象範囲内で当該指定相手が「発信先」としてセットされているか否かを調べる（ステップＡ４）。ここで、指定相手が検索対象範囲に存在していなければ（ステップＡ４でＮＯ）、後述するステップＡ１３に移る。いま、図示の例においては、相手別条件テーブルＰＴの先頭から「相手」として“Ａ”が読み出されるが、この“Ａ”を「発信先」とする発信履歴はその２レコード目に存在しているので（ステップ４ＡでＹＥＳ）、ＣＰＵ１は、該当する履歴レコードを指定したのち（ステップＡ５）、相手別条件テーブルＰＴからその「相手」の「時間条件」を読み出し（ステップＡ６）、この「時間条件」と当該発信履歴（２レコード目）の内容から次回の通信タイミングを決定する（ステップＡ７）。いま、相手別条件テーブルＰＴには相手“Ａ”に対応する「時間条件」として「時間帯」が選択されているので、その指定履歴レコードの「時」から“翌日の８時２０分”を次回の通信タイミングとして決定する。

そして、当該相手に対応する相手別条件テーブルＰＴ内の「状況」を参照し、「環境」、「動作」のうち、少なくともその一方が選択されているかを調べ（ステップＡ８）、いずれかの項目が選択されていれば、指定履歴レコードから該当する「環境（位置）」、「動作状況」を読み出す（ステップＡ９）。いま、相手別条件テーブルＰＴには相手“Ａ”に対応する「状況」として、「環境」が選択されているので、指定履歴レコードから「環境（位置）」として「会社」が読み出される。更に、指定履歴レコードから「通信種別」を読み出したのち（ステップＡ１０）、上述のようにして得られた各種のデータから案内レコードを生成して（ステップＡ１１）、案内テーブルＧＤに追加登録する（ステップＡ１２）。この場合、案内テーブルＧＤの１レコード目が生成され、「次回日時」として“８月６日０８時２０分”、「相手」として“Ａ”、「種別」として“電話”、「環境」として“会社”がセットされる。

そして、相手“Ａ”に基づいて検索対象範囲内の各履歴レコードを全て指定し終わったかを調べ（ステップＡ１３）、指定し終わるまで上述のステップＡ４に戻り、以下、上述の動作を繰り返す（ステップＡ４〜Ａ１３）。これによって発信履歴テーブルＣＬの５レコード目に基づいて案内テーブルＧＤの２レコード目が生成される結果、「次回日時」として“８月６日１２時５０分”、「相手」として“Ａ”、「種別」として“メール”、「環境」として“会社”がセットされる。ここで、相手“Ａ”の各履歴レコードを全て指定し終わった場合には（ステップＡ１３でＹＥＳ）、相手別条件テーブルＰＴには他の未指定相手が有るかを調べるが（ステップＡ１４）、いま、最初の相手を指定し終わった場合であるから、上述のステップＡ３に戻り、次の「相手」として“Ｂ”を指定して相手別条件テーブルＰＴから読み出す。

この場合、この相手“Ｂ”を「発信先」とする発信履歴はその１レコード目に存在しているので（ステップＡ４でＹＥＳ）、この履歴レコードを指定したのち（ステップＡ５）、相手別条件テーブルＰＴからその「相手」の「時間条件」を読み出し（ステップＡ６）、この「時間条件」と当該発信履歴（２レコード目）の内容から次回の通信タイミングを決定する（ステップＡ７）。いま、相手別条件テーブルＰＴには相手“Ｂ”に対応する「時間条件」として「曜日帯」が選択されているので、その指定履歴レコードの「曜日」から１週間後の“８月６日の８時１０分”が次回の通信タイミングとして決定される。

そして、相手別条件テーブルＰＴの「相手」に対応する「状況」を参照し、「環境」、「動作」のうち、少なくともその一方が選択されているかを調べるが（ステップＡ８）、相手“Ｂ”に対応する「状況」にはいずれも選択されていないので（ステップＡ８でＮＯ）、次のステップＡ１０に移り、「通信種別」を読み出したのち、案内レコードを生成して（ステップＡ１１）、案内テーブルＧＤに追加登録する（ステップＡ１２）。これによって案内テーブルＧＤには、「次回日時」として“８月６日（月曜日）０８時１０分”、「相手」として“Ｂ”、「種別」として“電話”がセットされるが、その「環境」、「動作」にはデータはセットされない。以下、同様に、発信履歴テーブルＣＬには、“８月２日（水曜日）、１２時３０分”に発信した履歴が相手“Ｂ”に関する履歴レコードとして存在しているので、案内テーブルＧＤには、「次回日時」として“８月９日（水曜日）１２時３０分”、「相手」として“Ｂ”、「種別」として“メール”がセットされる。

次に、「相手」として“Ｃ”が指定されて相手別条件テーブルＰＴから読み出される（ステップＡ３）。この場合、相手“Ｃ”に関する履歴レコードとして、発信履歴テーブルＣＬには、“７月３０日、１５時１０分”に発信した履歴が存在しているので、この履歴レコードに基づいて案内レコードが生成される。その際、相手別条件テーブルＰＴには相手“Ｃ”に対応する「時間条件」として「時間間隔（６時間）」が選択されているので、その履歴レコードの「時」から６時間後の“２１時１０分”を次回の通信タイミングとして決定して（ステップＡ７）、この日時を案内レコードの「次回日時」としてセットする（ステップＡ１１）。また、相手別条件テーブルＰＴには相手“Ｃ”に対応する「状況」として「動作」が選択されているので、案内レコードの「動作」に“マナー”をセットする。

なお、特定された相手の履歴レコードとして、例えば、“１２月１０日、１５時１０分”に発信した履歴に続いて、“１２月１０日、１５時３０分”のように、「時間間隔」との関係上、その時間内に複数の発信履歴が存在するような場合には、最新の発信日時である“１５時３０分”から６時間後の“２１時３０分”を次回の通信タイミングとして決定するようにしてもよい。言い換えれば、「時間間隔」が６時間であれば、この６時間内に複数の発信履歴が存在していても、最新の発信日時から６時間後を次回の通信タイミングとして決定するようにしてもよい。

このように得意先などの重要な通信相手に対して定期的に連絡するために相手別条件テーブルＰＴを参照しながら案内テーブルを作成する処理が終わった場合には、（ステップＡ１４でＹＥＳ）、相手別条件テーブルＰＴを参照せず、発信履歴テーブルＣＬの内容に応じて案内テーブルを作成する処理に移る（図６のフロー）。すなわち、発信履歴テーブルＣＬの内容を解析し、同一の通信相手と複数回の通信が行われている場合に、その各通信日時に共通する時間的要素が含まれていれば、当該共通要素に基づいて次回の通信タイミングを決定するほか、複数回の通信が行われた相手を通信候補相手として特定して案内テーブルを作成する処理に移る。

先ず、発信履歴テーブルＣＬの各履歴レコードを順次アクセスしながら同一相手の複数の履歴レコードを検索する（図６のステップＡ１５）。つまり、相手別条件テーブルＰＴに設定されている相手（「Ａ」、「Ｂ」、「Ｃ」）以外の相手を対象として、同一相手の複数の履歴レコードを検索し、該当する複数レコードが有るかを調べる（ステップＡ１６）。いま、相手“Ｆ”の履歴レコードが複数存在しているので（ステップＡ１６でＹＥＳ）、この各履歴レコード内の「日」、「時」、「曜日」を比較し、それらに共通する時間的要素が含まれているかを調べる（ステップＡ１７）。

この場合、相手“Ｆ”の履歴レコードとしては、「日」が“７月３０日”で「時」が“１２時１０分”の履歴レコードと、「日」が“８月２日”で「時」が“１２時０５分”の履歴レコードが存在しているが、その「時」の間隔（時間帯）が短いために、その時間帯（例えば、１２時００分〜１２時３０分）が各履歴レコードに共通する時間的要素となる。このように共通する時間的要素が含まれていれば（ステップＡ１７でＹＥＳ）、同一相手の各履歴レコード内の「環境（位置）」、「動作状況」を比較し、同一の環境で同一の動作状況であるかを調べる（ステップＡ１８）。

いま、同一の環境で同一の動作状況であれば（ステップＡ１８でＹＥＳ）、更に、同一相手の各履歴レコードの「通信種別」を比較して、「通信種別」が共通しているかを調べる（ステップＡ１９）。なお、共通する時間的要素が含まれていない場合（ステップＡ１７でＮＯ）、同一の環境で同一の動作状況でない場合（ステップＡ１８でＮＯ）、「通信種別」が共通していない場合には（ステップＡ１９でＮＯ）、上述のように検索した各履歴レコードを無視するために上述のステップＡ１５に戻る。いま、同一相手の各履歴レコードに共通する時間的要素が含まれ、かつ、同一の環境で同一の動作状況であり、更に、「通信種別」が共通していることを条件に（ステップＡ１９でＹＥＳ）、この共通要素に基づいて次回の通信タイミングを決定する（ステップＡ２０）。なお、上述した例においては、相手“Ｆ”の発信時刻“１２時１０分”、“１２時０５分”のうち、そのいずれか一方“１２時１０分”を次回の通信タイミングとして決定するようにしている。

そして、複数回の通信が行われた同一の相手を通信候補相手として特定する（ステップＡ２１）。このようにして得られた各種のデータから案内レコードを生成して（ステップＡ２２）、案内テーブルＧＤに追加登録する（ステップＡ２３）。この場合、相手“Ｆ”の案内レコードは、「次回日時」として“８月６日１２時１０分”、「相手」として“Ｆ”、「種別」として“メール”、「環境」として“会社”、「動作」として“マナー”がセットされる。なお、同一相手の各履歴レコードの「通信種別」を比較した結果、“電話”と“メール”とに別れている場合でも、「通信種別」が“電話”の履歴レコードが複数あれば、“電話”の案内レコードを生成して登録するようにしてもよく、また、“メール”の履歴レコードが複数あれば、“メール”の案内レコードを生成して登録するようにしてもよい。

そして、上述のステップＡ１５に戻り、未指定の各履歴レコードの中から同一相手の複数の履歴レコードを検索し、該当する履歴レコードの有無を調べるが（ステップＡ１６）、いま、相手“Ｄ”の履歴レコードが複数存在しているので（ステップＡ１６でＹＥＳ）、これらの履歴レコード内の「日」、「時」、「曜日」を比較し、共通する時間的要素が含まれているかを調べる（ステップＡ１７）。この場合、共通する時間的要素が含まれているか否かを判断する際には、時間帯、曜日、時間間隔の優先順位で判断するようにしている。

すなわち、上述のように相手“Ｄ”の履歴レコードとしては、「日」が“７月３０日”で「時」が“１２時１５分”、「曜日」が“月曜日”の履歴レコードと、「日」が“７月３０日”で「時」が“１８時１０分”、「曜日」が“月曜日”の履歴レコードが存在しているが、それらの「時」の間隔（時間帯）が長いために、その時間帯は各履歴レコードに共通する時間的要素とせず、「曜日」を共通する時間的要素とするようにしている。また、「曜日」が共通していなければ、それらの「時」の“時間間隔”を算出して、この“時間間隔”を各履歴レコードに共通する時間的要素とするようにしている。

次に、同一相手の各履歴レコード内の「環境（位置）」、「動作状況」を比較し、それらは同一の環境で同一の動作状況であるかを調べるが（ステップＡ１８）、いま、相手“Ｄ”の各履歴レコードは、「環境（位置）」、「動作状況」がそれぞれ異なるため、この相手“Ｄ”の履歴レコードを無視するために、上述のステップＡ１５に戻り、以下、上述の動作を繰り返す。

図７は、案内テーブルＧＤの内容を定期的（例えば、１０分毎）にチェックする定期チェック処理を示したフローチャートである。
先ず、ＣＰＵ１は、ＲＴＣ１２から現在時刻を読み出すと共に、この現在時刻に基づいて案内テーブルＧＤの「次回日時」をチェックし（ステップＢ１）、現在時刻に該当する「次回日時」の有無を調べる（ステップＢ２）。なお、現在時刻と「次回日時」とが完全に一致する場合に限らず、例えば、それらに１０分程度の時間的な“ずれ”があってもよい。いま、該当する「次回日時」が無ければ（ステップＢ２でＮＯ）、このフローから抜けるが、該当する「次回日時」が１つでも有れば（ステップＢ２でＹＥＳ）、ＧＰＳ部１３から現在環境（位置）を取得すると共に、現在の動作状況（例えば、マナーモードの状態）を取得する（ステップＢ３）。

そして、現在時刻に該当する「次回日時」を含む案内レコード内に「環境」、「動作」の両方あるいはいずれか一方が設定されている場合には、この「環境」、「動作」と現在の環境（位置）、動作状況とを比較し（ステップＢ４）、現在の環境、動作状況と一致するかを調べる（ステップＢ５）。ここで、不一致の場合には（ステップＢ５でＮＯ）、このフローから抜けるが、一致する場合には（ステップＢ５でＹＥＳ）、当該案内レコードの内容を報知する（ステップＢ６）。なお。案内レコードに「環境」、「動作」のいずれも設定されていなければ、上述のステップＢ５では一致すると判断されて当該案内レコードの内容を報知する処理に移る（ステップＢ６）。

図８は、案内レコードの内容に応じて通信要否を報知する案内報知画面を示した図である。
この案内報知画面は、通信候補相手への通信要否を案内報知する画面であり、図示の例は、“０８時１０分”に会社に居る場合を例示したもので、図４に示すように、現在時刻に該当する「次回日時」を含む案内レコードとしては、「次回日時」が“８月６日、０８時２０分”、「相手」が“Ａ”、「種別」が“電話”、「環境」が“会社”の案内レコードと、「次回日時」が“８月６日、０８時１０分”、「相手」が“Ｂ”、「種別」が“電話”の案内レコードが該当するため、これらのレコード内容か案内報知される。

すなわち、この案内報知画面には、「Ａさん、Ｂさんに電話するタイミングです。電話しますか？」のメッセージ表示のほか、“Ａさん”あるいは“Ｂさん”を選択する選択ボタンと、通話の要否に応じて電話を“する／しない”のボタンが配置表示されている。なお、図示の例は、電話を“する／しない”を案内する画面であるが、「種別」が“メール”の場合には、「Ｂさんにメールを送信する時刻です。メールしますか？」のようにメールの送信を“する／しない”を案内する画面となる。また、該当者が一人の場合には、上述した“Ａさん”、“Ｂさん”のような選択ボタンは表示されない。

いま、案内報知画面内の“Ａさん”あるいは“Ｂさん”を選択する選択ボタンのうち、例えば、“Ａさん”のボタンが操作されると共に、“する／しない”のボタンのうち、“しない”のボタンが操作された場合には（ステップＢ７でＮＯ）、ステップＢ１２に移り、案内報知画面を消去すると共に、案内テーブルＧＤから当該する案内レコードを削除する。また、例えば、“Ａさん”のボタンが操作されると共に、“する”のボタンが操作された場合には（ステップＢ７でＹＥＳ）、この案内レコード内の「種別」に対応する機能（電話機能／電子メール機能）を起動すると共に、案内レコード内の「相手」を読み出して電話帳ＡＤを検索し、該当する「電話番号」／「メールアドレス」を発信先としてセットしたのち（ステップＢ８）、当該「電話番号」／「メールアドレス」に発信する通信処理を開始する（ステップＢ９）。

そして、ＧＰＳ部１３から現在環境（位置）を取得すると共に、現在の動作状況（例えば、マナーモード状態）を取得して、今回の発信履歴レコードを生成して発信履歴テーブルＣＬに記録する（ステップＢ１０）。そして、案内報知画面の終了がユーザ指示されたかを調べ（ステップＢ１１）、その終了が指示されるまで上述のステップＢ７に戻るが、終了指示を受けた場合には（ステップＢ１１でＹＥＳ）、案内報知画面を消去すると共に、案内テーブルＧＤから当該する案内レコードを削除する（ステップＢ１２）。

以上のように、この実施例においてＣＰＵ１は、発信履歴テーブルＣＬの内容に基づいて次回の通信タイミングを決定するほか、この通信タイミングで通信を行う相手を通信候補相手として特定し、この通信タイミングにおいて通信候補相手への通信要否を案内報知するようにしたので、通信を行うことをユーザが意識しなくても、通信が必要なときに必要な相手を案内することができ、速やかな通信と共に、ユーザの負担を軽減することが可能となる。

ＣＰＵ１は、特定した通信候補相手に対応する発信履歴レコードを参照し、その発信日時から次回の通信タイミングを決定するようにしたので、過去の発信履歴から次回の発信タイミングを予測して決定することができる。

ＣＰＵ１は、発信履歴テーブルＣＬの内容を解析し、同一の通信相手と複数回の通信が行われている場合に、その各通信日時に共通する時間的要素が含まれていれば、当該共通要素に基づいて次回の通信タイミングを決定するほか、複数回の通信が行われた相手を通信候補相手として特定するようにしたので、過去の発信履歴から定期的に連絡している同一相手がいる場合には、その定期的な連絡から次回の通信タイミングを決定することができ、その相手を通信候補相手として特定することができる。

特定された相手の履歴レコードと相手別条件テーブルＰＴの「時間間隔」とから次回の通信タイミングを決定する場合に、例えば、「時間間隔」が６時間であれば、この６時間内に複数の発信履歴が存在していても、最新の発信日時から６時間後を次回の通信タイミングとして決定するようにしたので、発信履歴毎に通信要否を報知しなくても、「時間間隔」毎に通信要否の案内報知が可能となる。

現在時刻に該当する「次回日時」を含む案内レコード内に「環境」、「動作」の両方あるいは一方が設定されていれば、この「環境」、「動作」と現在の環境（位置）、動作状況とを比較し、現在の環境、動作状況と一致していることを条件に、当該案内レコードの内容を報知するようにしたので、過去の発信状況と同一の状況下で案内報知することができる。

通信候補相手への通信要否を案内報知するほか、通信機能の種別を案内報知するようにしたので、電話をするのかメールを送信するのかを知ることができる。

通信候補相手への通信要否の案内報知に応答して通信要がユーザ指示された際に、通信機能を起動して当該通信候補相手との通信を実行するようにしたので、容易かつ確実にその相手への連絡が可能となる。

なお、上述した実施例においては、同一の通信相手と複数回の通信が行われている場合に、その各通信日時に共通する時間的要素に基づいて次回の通信タイミングを決定する際に、その共通する時間的要素としては、時間帯、曜日、時間間隔を例示したが、これに限らず、日、週、月、年を共通要素としてもよい。例えば、５日・１週間・１ヶ月毎などのように次回の通信タイミングを決定するようにしてもよい。また、共通する時間的要素が含まれているか否かを判断する際に、時間帯、曜日、時間間隔の優先順位で判断するようにしたが、この順位も勿論、任意である。

また、上述した実施例においては、通信機能として、電話機能、電子メール機能を例示したが、この電話機能を音声電話機能とテレビ電話機能に分けてもよく、また、内線電話機能、外線電話機能に分けてもよい。

また、通信候補相手への通信要否の案内報知は、表示メッセージに限らず、音声メッセージで案内報知するようにしてもよい。
その他、携帯電話装置に限らず、例えば、通信機能付きＰＤＡ、電子カメラ、電子腕時計、音楽再生機などの通信端末装置であっても同様に適用可能である。勿論、設置型の固定電話装置にも適用可能である。

通信端末装置として適用した携帯電話装置の基本的な構成要素を示したブロック図。 発信履歴テーブルＣＬを説明するための図。 相手別条件テーブルＰＴを説明するための図。 案内テーブルＧＤを説明するための図。 定期的（例えば、１週間毎）に実行開始される案内テーブル作成処理を示したフローチャート。 図５に続くフローチャート。 案内テーブルＧＤの内容を定期的（例えば、１０分毎）にチェックする定期チェック処理を示したフローチャート。 案内レコードの内容に応じて通信要否を報知する案内報知画面を示した図。

符号の説明

１ ＣＰＵ
２ 記憶部
５ 電話通信部
６ 音声制御部
８ メイン表示部
１０ 操作部
１１ 報知部
１２ ＲＴＣ
１３ ＧＰＳ部
ＡＤ 電話帳
ＣＬ 発信履歴テーブル
ＰＴ 相手別条件テーブル
ＧＤ 案内テーブル

Claims (9)

1. 通信機能を備えた通信端末装置であって、
   通信相手との過去の通信履歴を記憶する記憶手段と、
   この通信履歴記憶手段の内容に基づいて次回の通信タイミングを決定する決定手段と、
   この決定手段によって決定された通信タイミングで通信を行う相手を通信候補相手として特定する特定手段と、
   前記決定手段によって決定された通信タイミングにおいて、前記特定手段によって特定された通信候補相手への通信要否を案内報知する報知手段と、
   を具備したことを特徴とする通信端末装置。
2. 前記通信履歴記憶手段は、通信を実行した際の通信日時とその通信相手とを含む通信履歴を記憶し、
   前記特定手段は、予め決められている相手を前記通信タイミングでの通信候補相手として特定し、
   前記決定手段は、前記特定手段によって特定された通信候補相手に対応する前記通信履歴を参照し、その通信日時から次回の通信タイミングを決定する、
   ようにしたことを特徴とする請求項１記載の通信端末装置。
3. 前記決定手段は、前記通信履歴を参照し、同一の通信相手と複数回の通信が行われている場合に、その各通信日時に共通する時間的要素が含まれていれば、当該共通要素に基づいて次回の通信タイミングを決定し、
   前記特定手段は、前記複数回の通信が行われた相手を通信候補相手として特定する、
   ようにしたことを特徴とする請求項１記載の通信端末装置。
4. 前記通信履歴記憶手段は、通信を実行した際の通信日時とその通信相手とを含む通信履歴を記憶し、
   前記特定手段は、前記特定手段によって特定された通信候補相手に対応する前記通信履歴を参照し、その最新の通信日時からの経過時間に基づいて次回の通信タイミングを決定する、
   ようにしたことを特徴とする請求項１記載の通信端末装置。
5. 現在の環境状況を取得する環境状況取得手段と、
   前記通信履歴記憶手段は、通信を実行した際に前記取得した環境状況とその通信相手とを含む通信履歴を記憶し、
   前記報知手段は、前記決定手段によって決定された通信タイミングにおいて、前記取得した現在の環境状況が前記通信履歴としての環境状況に該当したことを条件に前記通信候補相手への通信要否を案内報知する、
   ようにしたことを特徴とする請求項１記載の通信端末装置。
6. 現在の動作状況を取得する動作状況取得手段と、
   前記通信履歴記憶手段は、通信を実行した際に前記取得した動作状況とその通信相手とを含む通信履歴を記憶し、
   前記報知手段は、前記決定手段によって決定された通信タイミングにおいて、前記取得した動作状況が前記通信履歴としての動作状況に該当したことを条件に前記通信候補相手への通信要否を案内報知する、
   ようにしたことを特徴とする請求項１記載の通信端末装置。
7. 前記通信履歴記憶手段は、通信を実行した際にその通信機能の種別とその通信日時とその通信相手とを含む通信履歴を記憶し、
   前記報知手段は、通信候補相手への通信要否を案内報知するほか、通信機能の種別を案内報知する、
   ようにしたことを特徴とする請求項１記載の通信端末装置。
8. 前記報知手段によって通信候補相手への通信要否の案内報知に応答して通信要がユーザ指示された際に、通信機能を起動して当該通信候補相手との通信を実行する、
   ようにしたことを特徴とする請求項１記載の通信端末装置。
9. コンピュータに対して、
   通信相手との過去の通信履歴が記憶されている状態において、この通信履歴に基づいて次回の通信タイミングを決定する機能と、
   前記決定された通信タイミングで通信を行う相手を通信候補相手として特定する機能と、
   前記決定された通信タイミングにおいて、前記特定された通信候補相手への通信要否を案内報知する機能と、
   を実現させるためのプログラム。

Images