JP2008219074A - 携帯情報端末および制御プログラム - Google Patents

Abstract

【課題】通信先端末のキャリアを判断する携帯情報端末を提供する。
【解決手段】携帯情報端末１は、ディスプレイ４と、電話番号と電子メールアドレスとが対応付けて記憶されている電話帳ＤＢ３２ａと、電子メールアドレスのドメインと、そのドメインを提供するキャリアとが対応付けられている対応テーブル３２ｂと、ディスプレイ４に対して表示処理を行なう制御部３０とを備える。制御部３０は、入力された電話番号について電話帳ＤＢ３２ａから検索する。電話帳ＤＢ３２ａにその電話番号が登録されていた場合、対応テーブル３２ｂを参照して、電話番号に対応付けられた電子メールアドレスのドメインから電話番号のキャリアを判断する。
【選択図】図３

Description

本発明は、携帯情報端末および制御プログラムに関する。特に、通信相手が利用している通信事業者を判断する技術に関する。

通信サービスを提供する通信事業者（以下、「キャリア」と呼ぶ）は複数存在しており、各キャリアによって料金体系が異なる。このため、通信時に利用するキャリアによっては、他のキャリアを利用するよりも通信料金が安くなることがある。

たとえば、特許文献１では、最低通話料金の通話回線を自動的に選択して通話することが可能なボタン電話装置が提案されている。

また、最近の携帯電話機は、インターネットを介した電子メールや、同一キャリア間で提供されるショートメッセージサービス（ＳＭＳ：Short Message Service）など、様々なメール種別が利用できる。

たとえば、特許文献２では、通信相手が対応可能なメール種別を確認することができる電話機が提案されている。
特開昭６４−７４８９３号公報 特開２０００−３４９９２３号公報

携帯電話機の急速な普及に伴い、最近は一人で複数の携帯電話機を持つ人が増えてきている。このような人と通信する際は、どのキャリアが提供する電話番号（またはアドレス）に発信するかによって通信料金が異なることになる。一般的に、同一キャリアが提供する電話番号で通信すると、通信料金が安くなることが多い。このため、ユーザは、料金的なメリットを享受するのに、同一キャリアの電話番号や相手名を記憶しておく、またはメモしておく必要があった。

本発明は、上記のような問題を解決するためになされたものであって、その目的は、通信先端末のキャリアを判断する携帯情報端末および制御プログラムを提供することである。

本発明の１つの局面に従うと、携帯情報端末であって、表示手段と、個人を特定するための情報と電話番号とを関連付けて記憶するための記憶手段と、表示手段に対する表示処理の制御を行なうための制御手段とを備え、記憶手段は、電話番号を提供する通信事業者を判断するための情報をさらに含み、制御手段は、判断するための情報に基づき、与えられた電話番号の通信事業者を判断するための通信事業者判断手段と、表示手段に対し、与えられた電話番号について通信事業者判断手段の判断結果に従った表示をするための表示制御手段とを含む。

好ましくは、記憶手段は、個人を特定するための情報と関連付けられた電話番号と対応付けて電子メールアドレスを記憶し、判断するための情報は、電子メールアドレスのドメインとドメインを提供する通信事業者とが対応付けられた通信事業者対応テーブルであり、通信事業者判断手段は、与えられた電話番号を記憶手段の中から検索するための手段と、検索された電話番号に対応付けられた電子メールアドレスを取得するための手段と、通信事業者対応テーブルに基づき、取得した電子メールアドレスのドメインに対応付けられた通信事業者を特定するための手段とを有する。

好ましくは、通信するための通信手段と、通信相手との呼接続のための操作を受け付ける操作手段とをさらに備え、操作手段を介したユーザの操作により、呼接続のための処理が行なわれる際に、前記表示制御手段は、前記通信事業者判断手段の判断結果に従った表示を行なう。

好ましくは、表示制御手段は、操作手段を介したユーザの操作により、個人を特定するための情報と、個人を特定するための情報に関連付けられた複数の電話番号から構成される一覧表を表示し、一覧表は、複数の電話番号のそれぞれについて、通信事業者判断手段の判断結果を含む。

好ましくは、通信事業者判断手段は、操作手段を介してユーザが電話番号を入力したことに応じて、ユーザが入力した電話番号の通信事業者を判断し、表示制御手段は、ユーザが入力した電話番号に対して発信している際に、表示手段において、通信事業者判断手段の判断結果を表示する。

好ましくは、通信するための通信手段と、通信手段が受信した発呼者端末の電話番号を検出するための番号検出手段とをさらに備え、番号検出手段は、検出した発呼者端末の電話番号を通信事業者判断手段に与え、通信事業者判断手段は、番号検出手段から与えられた発呼者端末の電話番号の通信事業者を判断し、表示制御手段は、着信画面において、発呼者の電話番号について通信事業者判断手段の判断結果に従った表示を行なう。

好ましくは、記憶手段は、個人を特定するための情報に関連付けられた、複数の電話番号および複数の電子メールアドレスと、複数の電話番号および複数の電子メールアドレスそれぞれが属するカテゴリとを記憶し、判断するための情報は、電子メールアドレスのドメインとドメインの通信事業者とが対応付けられた通信事業者対応テーブルであり、通信事業者判断手段は、与えられた電話番号を記憶手段の中から検索するための手段と、検索された電話番号のカテゴリと、検索された電話番号と関連付けられた、個人を特定するための情報に対応する複数の電子メールアドレスのうちから、同一のカテゴリの電子メールアドレスを取得するための手段と、通信事業者対応テーブルに基づき、取得した電子メールアドレスのドメインに対応付けられた通信事業者を特定するための手段とを有する。

好ましくは、判断するための情報は、自端末の電話番号の通信事業者と記憶手段に記憶された電話番号の通信事業者とが同一か否かを示す情報である。

好ましくは、同一通信事業者端末間で電話番号を宛先として通信できる同一通信事業者間メールを、通信手段により送受信することによって、通信相手の通信事業者が自端末の通信事業者と同一か否かを登録するための通信事業者登録手段とをさらに備える。

好ましくは、通信事業者登録手段は、（ｉ）通信手段が受信した同一通信事業者間メールに基づいて、同一通信事業者間メールの送信者の電話番号を取得し、（ｉｉ）記憶手段の中から、取得した電話番号を検索し、（ｉｉｉ）記憶手段に対し、検索した電話番号について、通信事業者が同一であるという情報を登録する。

好ましくは、通信事業者登録手段は、通信手段が送信した、記憶手段に記憶された電話番号を宛先とした同一通信事業者間メールについて、通信手段がサーバからのエラーメッセージを受信したとの判断に応じて、送信した同一通信事業者間メールの宛先の電話番号について、通信事業者が異なるという情報を登録し、所定時間以内に、通信手段がエラーメッセージを受信していないとの判断に応じて、送信した同一通信事業者間メールの宛先の電話番号について、通信事業者が同一であるという情報を登録する。

好ましくは、記憶手段は、通信事業者ごとに、表示可能な絵文字の情報を記憶し、表示制御手段は、記憶手段から、通信事業者判断手段が特定した通信事業者で表示可能な絵文字の情報を読み込んで、表示手段に表示する。

好ましくは、通信事業者判断手段は、同一通信事業者の端末間において電話番号を宛先として通信できる同一通信事業者間メールにおいて、記憶手段に記憶された電話番号が宛先として入力されたことに応じて、宛先として入力された電話番号の通信事業者が自端末の通信事業者と同一か否かを判断し、表示制御手段は、通信事業者判断手段が、宛先として入力された電話番号の通信事業者が自端末の通信事業者と同一でないと判断したことに応じて、表示手段に、宛先として入力された電話番号に対し同一通信事業者間メールを送信できない旨の表示を行なう。

好ましくは、記憶手段は、通信事業者とメール種別とが対応付けられたメール種別対応テーブルを記憶し、メール作成時において、（ｉ）通信事業者判断手段は、ユーザによって入力された電子メールのアドレスまたは電話番号に基づき、メールの送信相手の通信事業者を特定し、（ｉｉ）表示制御手段は、メール種別対応テーブルにおいて、特定された通信事業者に対応付けられたメール種別で送信する旨の表示を行なう。

本発明の他の局面に従うと、演算部および記憶部を有するコンピュータに、コンピュータに接続された表示装置における表示処理をさせるための制御プログラムであって、記憶部は、個人を特定するための情報と電話番号とが関連付けられた電話帳データおよび電話番号を提供する通信事業者を判断するための情報を記憶し、演算部は、電話帳データおよび判断するための情報に基づき、与えられた電話番号の通信事業者を判断するステップと、演算部は、表示装置に対し、与えられた電話番号について通信事業者を判断判断するステップの判断結果に従った表示をするステップとを備える。

本発明によれば、通信先端末のキャリアを判断することができる。これにより、キャリアに応じた通信方法をユーザに促すことができ、ユーザは料金的なメリットを享受できる。

以下、図面を参照しつつ本発明の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについては詳細な説明は繰り返さない。

［実施の形態１］
本実施の形態に係る携帯情報端末は、電話番号と電子メール（Ｅｍａｉｌ）アドレスとが対応付けられている電話帳データベースから、発着信される電話番号の検索を行なう。その電話番号が電話帳データベースに登録されている場合、電話番号に対応付けられているＥｍａｉｌアドレスのドメインからキャリアを判断し、キャリア名等をディスプレイに表示する。

図１は、本実施の形態に係る携帯情報端末１の一例を示した斜視図であり、筐体を展開した状態を示した図である。

図２は、携帯情報端末１の筐体を閉じた状態を示す図である。
図１および図２を参照して、携帯情報端末１について説明する。この携帯情報端末１は、いわゆる折り畳み式の携帯電話機であり、第１の筐体２および第２の筐体３が図示しないヒンジ部を介して連結され、第１の筐体２および第２の筐体３の筐体面を対向させた状態で折り畳むことができるようになっている。

第１の筐体２は、ディスプレイ４およびスピーカ６０を備える。
第２の筐体３は、アンテナ７を備える。さらに、第２の筐体３の内面側には、各種の操作キーおよび操作ボタンを含む操作部１７が設けられる。また、第２の筐体３の下端部内面側表面にはマイクロフォン５３が設けられる。操作部１７は、テンキー１１と、方向キー１２と、確定キー１３と、オンフックキー１４と、クリアキー１５と、オフフックキー１６とを含む。

図３は、携帯情報端末１の機能的構成を示す機能ブロック図である。
図３を参照して、携帯情報端末１の機能的構成について説明する。

携帯情報端末１の上記構成は、携帯情報端末１全体の制御を行なう制御部３０と、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）などから構成される記憶部３２と、ユーザの操作により制御部３０へ動作の指示を行なう操作部１７と、アンテナ７および変調／復調機能を備える無線部６５を介して無線通信制御を行なう通信制御部３５と、マイクロフォン５３からの音声に対して信号処理を実行する音声信号処理部３９と、スピーカ６０へ音声などを出力するための信号再生処理を行なう再生回路３６と、ディスプレイ４に表示する画像の表示制御を行なう表示ドライバ部３４とから構成される。

記憶部３２には、制御部３０が実行するプログラム、自端末のキャリアを特定する情報（たとえば、以下の説明では、携帯情報端末１のキャリアを「キャリア１」とする）、文字等の各種データが予め格納されている。また、記憶部３２には、電話帳データベース（ＤＢ）３２ａおよび対応テーブル３２ｂが格納されている。

電話帳ＤＢ３２ａは、メインＤＢおよびサブＤＢを含む。
メインＤＢは、複数のレコードから構成される。レコードは、個人を特定するための情報（たとえば、氏名や写真）、電話番号およびＥｍａｉｌアドレス等のフィールドから構成される。また、サブＤＢは、メインＤＢの各レコードにおいて、電話番号と、その電話番号に対応するＥｍａｉｌアドレスを示す。なお、メインＤＢやサブＤＢを構成するレコードに含まれる電話番号やＥｍａｉｌアドレスは、複数であってもよい。

対応テーブル３２ｂは、Ｅｍａｉｌアドレスのドメインと、そのドメインに対応するキャリアを示す。

図４は、電話帳ＤＢ３２ａのデータ構造の一例を示した図である。特に、図４（Ａ）はメインＤＢを示す図であり、図４（Ｂ）はサブＤＢを示す図である。

図４を参照して、電話帳ＤＢ３２ａのデータ構造について説明する。
図４（Ａ）に示すように、メインＤＢ１１０は、複数のレコード（１件目〜ｎ件目）から構成される。レコード１００は、１名分のデータを示している。

レコード１００は、行１２０に示される名前と、行１２１〜１２３に示される電話番号と、行１２４〜１２６に示されるＥｍａｉｌアドレス等のフィールドから構成される。このように、１名分のデータには、複数の電話番号とＥｍａｉｌアドレスとが含まれていてもよいし、それぞれ１つずつ含まれるようにしていてもよい。

図４（Ｂ）に示すように、サブＤＢ１６０は、メインＤＢ１１０と同様に、複数のレコードから構成される。レコード１５０は、１名分のデータを示している。サブＤＢ１６０の１件目〜ｎ件目のデータは、それぞれメインＤＢの１件目〜ｎ件目のデータに対応する。

レコード１５０は、レコード１００における電話番号とその電話番号に対応するＥｍａｉｌアドレスとを示している。たとえば、行１７０に示される電話番号１は、Ｅｍａｉｌアドレス１に対応している。また、行１７１に示される電話番号２は、Ｅｍａｉｌアドレス２に対応している。このように、サブＤＢでは、電話番号とＥｍａｉｌアドレスとが１対１対応している。

なお、サブＤＢは、ユーザが操作部１７を介して入力するようにしてもよいし、赤外線通信等により、ユーザが通信相手の携帯電話機の電話帳データを取得した際に、自動的にその携帯電話機の電話番号とアドレスとを対応付けてサブＤＢに登録するようにしてもよい。

また、サブＤＢで示される電話番号とＥｍａｉｌアドレスとの対応関係について、以下で説明するように、メインＤＢにおいて示されるようなデータ構造にしてもよい。

図５は、電話帳ＤＢ３２ａのデータ構造の一例を示す図である。
図５を参照して、図４とは異なる電話帳ＤＢのデータ構造について説明する。

図５で示す電話帳ＤＢ２１０は、複数のレコードから構成される。レコード２００は、１名分のデータを示している。なお、レコード２００は、図４のレコード１００およびレコード１５０の内容を書き換えたものであり、メインＤＢの中にサブＤＢが組み込まれた形式となっている。

レコード２００は、行２２０に示される名前と、行２２１，２２３，２２５に示される電話番号と、行２２２，２２４，２２６で示される、電話番号と対応関係にあるＥｍａｉｌアドレス、行２２７〜２２９に示されるＥｍａｉｌアドレス等のフィールドから構成される。ここでは、行２２２，２２４，２２６で示される対応関係が図４のサブＤＢの内容に対応している。

たとえば、行２２２では、電話番号１と対応付けられているアドレスとしてＥｍａｉｌアドレス１が示されている。このＥｍａｉｌアドレス１は、行２２７に示されているものである。また、行２２６に示すように、電話番号３と対応しているＥｍａｉｌアドレスはないため「無」と示されている。

なお、電話番号と対応関係にあるＥｍａｉｌアドレスはユーザが操作部１７を介して入力してもよいし、赤外線通信等で自動的に登録されるようにしてもよい。

図６は、ドメインとキャリアとの対応関係を表わしたテーブルを示す図である。
図６を参照して、対応テーブル３２ｂについて説明する。

テーブル２５０は、Ｅｍａｉｌアドレスのドメインと、そのドメインに対応するキャリアを示す。たとえば、行２６０，２６１に示すようにドメイン１および２はキャリア１に対応する。行２６２に示すドメイン３はキャリア２に、行２６３に示すドメイン４はキャリア３に対応する。このような対応関係を示す対応テーブル３２ｂは、予め記憶部３２に書き込まれている。また、手動で更新やネットワークと同期をとることにより更新できてもよい。

ここで、ドメイン（名）とは、インターネットにおけるネットワークの組織を識別するための文字列のことをいう。ドメイン名は、インターネット上の住所表示であり、ホームページのアドレスやメールアドレスなどの一部分として使われる。

たとえば、「ｚｚｚｚ＠ＡＡＡ．ｎｅ．ｊｐ」というアドレスの場合、「ＡＡＡ．ｎｅ．ｊｐ」の部分がドメインである。ドメインによってネットワークの組織を識別することができる。このため、携帯情報端末の電話番号に対応するＥｍａｉｌアドレスのドメインを、その電話番号を提供するキャリアを判定するのに用いることができる。

次に、以上のような構成をもつ携帯情報端末１が行なう処理について説明する。
図７は、音声着信時の処理を示したフローチャートである。

図７を参照して、音声着信時における処理について説明する。なお、図７のフローチャートで示す処理は、制御部３０として機能するプロセッサが記憶部３２に記憶されるプログラムを読み出して実行し、図３に示された各部を制御することによって実現される。また、図７のフローチャートで示す処理は、音声着信時の処理の一具体例に過ぎず、たとえば、ステップの順番を入れ替えて実行してもよい。

まず、ステップＳ１００において、制御部３０は、通信制御部３５から、音声着信があることの通知を受ける。

次いで、ステップＳ１０２において、制御部３０は、着信に対し、発信者番号の通知があるかどうかを判定する。

発信者番号の通知がない（非通知）と判断すれば（ステップＳ１０２において、ＮＯ）、ステップＳ１１６において、制御部３０は、表示ドライバ部３４に対し、ディスプレイ４にキャリア名表示のない着信画面を表示するように指示する。

一方、発信者番号の通知があると判断すれば（ステップＳ１０２において、ＹＥＳ）、ステップＳ１０４において、制御部３０は、記憶部３２から電話帳ＤＢ３２ａを読み込み、通知された発信者番号を含む電話帳レコードを検索する。たとえば、制御部３０は、メインＤＢを構成する各レコードに含まれる電話番号と発信者番号とを照会し、同一のものがあるかどうかを調べる。

次いで、ステップＳ１０６において、制御部３０は、ステップＳ１０４の検索結果から、発信者番号が電話帳ＤＢ３２ａに登録されているかどうかを判定する。

発信者番号が電話帳ＤＢ３２ａに登録されていないと判断すれば（ステップＳ１０６において、ＮＯ）、ステップＳ１１６の処理に進む。

一方、発信者番号が電話帳ＤＢ３２ａに登録されていると判断すれば（ステップＳ１０６において、ＹＥＳ）、ステップＳ１０８において、制御部３０は、該当電話帳レコード内の該当電話番号に対応するＥｍａｉｌアドレスの登録があるかどうかを判定する。ここでは、制御部３０は、電話帳ＤＢ３２ａからサブＤＢを読み込み、該当電話番号に対応付けられたＥｍａｉｌアドレスがあるかどうかを確認する。

Ｅｍａｉｌアドレスの登録がないと判断すれば（ステップＳ１０８において、ＮＯ）、ステップＳ１１６の処理に進む。

一方、Ｅｍａｉｌアドレスの登録があると判断すれば（ステップＳ１０８において、ＹＥＳ）、ステップＳ１１０において、制御部３０は、サブＤＢから該当電話番号の連携先として登録されたＥｍａｉｌアドレスを取得する。

続いて、ステップＳ１１２において、制御部３０は、対応するＥｍａｉｌアドレスからキャリア名が判断できるかどうかを判定する。ここで、まず、制御部３０は、Ｅｍａｉｌアドレスからドメインに該当する文字列を抜き出す。そして、制御部３０は、記憶部３２から対応テーブル３２ｂを読み込み、ドメインに対応するキャリアがあるかどうかを調べる。

対応するＥｍａｉｌアドレスからキャリア名が判断できなければ（ステップＳ１１２において、ＮＯ）、ステップＳ１１６の処理に進む。ここでは、対応テーブル３２ｂに、Ｅｍａｉｌアドレスのドメインと対応関係にあるキャリアが存在しなかった場合は、キャリア名が判断できないとする。

対応するＥｍａｉｌアドレスからキャリア名が判断できれば（ステップＳ１１２において、ＹＥＳ）、ステップＳ１１４において、制御部３０は、表示ドライバ部３４に対し、ディスプレイ４にキャリア名を含む着信画面を表示するように指示する。ここでは、対応テーブル３２ｂに基づいて、そのＥｍａｉｌアドレスのドメインからキャリアが特定できる場合、キャリア名が判断できるとする。

以上のようにして、音声着信時の処理を終了する。
図８は、音声着信時の着信画面例を示した図である。

図８を参照して、音声着信時には、ディスプレイ４上に、符号３００に示すような発信者番号とともに、符号３０１で示すような、その発信者番号に対応するＥｍａｉｌアドレスから特定されたキャリア名が表示される。キャリアが特定できない場合は、キャリア名は表示されない。また、キャリアが自端末と異なる場合は、キャリア名を表示しないようにしてもよい。なお、キャリア名を表示するのではなく、自端末と同一のキャリアであるという旨の表示または、自端末と異なるキャリアであるという旨の表示であってもよい。この場合、上記処理によって特定されたキャリア名と、記憶部３２に予め書き込まれた自端末のキャリア名とからキャリアが同一か否かを判定することができる。

また、携帯情報端末１は、音声着信時だけでなく、他の場合においても、キャリア名を表示させることができる。

図９は、電話帳データ表示の画面例を示した図である。
図９に示すように、制御部３０は、電話帳データの電話番号について、図７のステップＳ１０８〜Ｓ１１６で示したようにして、電話番号のキャリアを特定する。そして、電話帳データをディスプレイ４に表示させるときに、表示ドライバ部３４に対し、電話番号のキャリア名を表示するように指示する。これにより、符号３０２に示すように、電話番号のキャリアが表示される。なお、キャリア名を表示するのではなく、自端末と同一のキャリアであるという旨の表示であってもよい。

図１０は、音声発信時の画面例を示した図である。
図１０を参照して、音声発信時のディスプレイの画面例について説明する。なお、本実施の形態において、「発信」とは、通信制御部３５が与えられた電話番号への呼接続を行なうことをいう。また、「通信相手との呼接続のための操作」とは、ユーザが電話番号を入力、または、図９で示すような電話帳データにより電話番号を選択する操作をいう。また、「呼接続のための処理」とは、ユーザが電話番号を入力または選択し、通信制御部３５が確定された電話番号に対して呼接続する処理をいう。

ユーザは、発信する際、操作部１７を介して発信先電話番号を入力する。制御部３０は、表示ドライバ部３４に対し、ディスプレイ４に入力された発信先電話番号を表示するよう指示する。表示ドライバ部３４は、画面Ｄ１０のように入力された発信先電話番号を表示する。

さらに、ユーザが確定キー１３等を押下して発信を確定させたことに応じて、制御部３０は、発信先電話番号について電話帳検索する。これにより、発信先電話番号のキャリア名を表示させる。なお、発信先電話番号のキャリア名を表示させる処理については、図７で示した処理において、発信者電話番号に代わって発信先電話番号についてステップＳ１０２〜１１６までの処理を行なうことと同じである。このため、処理の説明は省略する。

発信先電話番号のキャリアと、自端末のキャリアとが一致しなければ、制御部３０は、表示ドライバ部３４に対し、キャリア名表示のない発信中画面の表示を行なうよう指示する。表示ドライバ部３４は、ディスプレイ４において、たとえば、画面Ｄ１２のような表示を行なう。画面Ｄ１２では、発信先電話番号と、その電話番号と同じレコードに含まれる発信先相手の氏名が表示される。

一方、発信先電話番号のキャリアと、自端末のキャリアとが一致すれば、制御部３０は、表示ドライバ部３４に対し、キャリア名を示した発信中画面の表示を行なうよう指示する。表示ドライバ部３４は、ディスプレイ４において、たとえば、画面Ｄ１４のような表示を行なう。画面Ｄ１４では、発信先電話番号と、その電話番号と同じレコードに含まれる発信先相手の氏名とともに、キャリア名が表示される。なお、キャリア名を表示するのではなく、自端末と同一のキャリアであるという旨の表示であってもよい。

なお、キャリア名の表示は、電話帳の表示時および発信中にキャリア名を表示させてもよいし、いずれか一方の場合においてキャリア名を表示させるようにしてもよい。

図１１は、発信履歴の画面例を示した図である。
図１１を参照して、発信履歴の画面例について説明する。

制御部３０は、発信した電話番号を記憶部３２に書き込む。この際、発信した電話番号のうち、図１０で説明したようにして、自端末のキャリアと発信先電話番号のキャリアとが同一と判断した電話番号については、キャリアが同一である旨を記憶しておいてもよい。

そして、ユーザが発信した電話番号の履歴を表示させる操作を行なったことに応じて、記憶部３２から電話番号の履歴を読み込む。制御部３０は、この時点で、読み込んだ電話番号についてキャリアの判断を行なってもよい。次いで、制御部３０は、キャリアが同一である発信先については、表示ドライバ部３４に対し、キャリア名の表示を行なうよう指示する。たとえば、符号３０４，３０６のように発信先相手の氏名とともにキャリア名を表示する。なお、キャリア名を表示するのではなく、自端末と同一のキャリアであるという旨の表示であってもよい。

上述したように、本実施の形態に係る携帯情報端末は、電話番号とＥｍａｉｌ（電子メール）アドレスとが対応付けられている電話帳データベースから、発着信される電話番号の検索を行なう。その電話番号が電話帳データベースに登録されている場合、電話番号に対応付けられているＥｍａｉｌアドレスのドメインからキャリアを判断し、キャリア名等をディスプレイに表示する。これにより、ユーザに対し、キャリアに応じた通話を促すことができる。たとえば、同一キャリアからの着信であれば、通話料金が安くなることが多いため、ユーザは長時間通話しても、料金的なメリットを受けることができる。また、複数の携帯電話を持つ人に発信する場合、電話帳に表示された同一キャリアの表示に従って同一キャリアの電話番号に発信すれば、ユーザは料金的なメリットを受けることができる。

また、近年では、ナンバーポータビリティの制度が導入されつつある。ナンバーポータビリティとは、通信端末の加入者が別のキャリアに契約を切り替えても、同一の電話番号での発着信を可能とする制度である。このため、ユーザは、電話番号に対してキャリアを記憶しておいても、キャリアが変更されている場合がある。このような場合に対しても、最新の電子メールアドレスからキャリアを判断することにより、ユーザにキャリアが同一か否かを通知することができる。

［実施の形態２］
本実施の形態に係る携帯情報端末１は、サブＤＢを持たず、電話帳レコードに電話番号およびＥｍａｉｌアドレスのカテゴリを示すフィールドが含まれる点が実施の形態１に係る携帯電話機と異なる。一般的に、電話帳のデータには電話番号やＥｍａｉｌアドレスがどのような種類に属するかを示すためのフィールドが設けられていることが多い。たとえば、ある電話番号に対して、ユーザは「携帯電話」や「自宅」などをカテゴリとして入力する。これにより、その電話番号が携帯電話や自宅（たとえば、固定電話）の電話番号であることが分かる。

図１２は、電話帳ＤＢ３２ａのデータ構造の一例を示した図である。
図１２を参照して、本実施の形態に係る電話帳ＤＢ３２ａのデータ構造について説明する。

図１２に示すように、電話帳のデータベース４１０は、複数のレコード（１件目〜ｎ件目）から構成される。レコード４００は、１名分のデータを示している。

レコード４００は、行４２０に示される名前と、行４２１，４２３，４２５に示される電話番号と、行４２２，４２４，４２６に示される電話番号のカテゴリと、行４２７，４２９，４３１に示されるＥｍａｉｌアドレスと、行４２８，４３０，４３２に示されるＥｍａｉｌアドレスのカテゴリ等とのフィールドから構成される。このように、１名分のデータには、複数の電話番号、Ｅｍａｉｌアドレスおよびそれらのカテゴリが含まれる。

ユーザは、たとえば、行４２２に示すように、電話番号１のカテゴリを「携帯電話（私物）」と操作部１７を介して入力する。または、カテゴリを入力する際に、メニュー形式により、いくつかのカテゴリをユーザに提示し、ユーザは方向キー１２等を押下してカテゴリを選択することで入力するようにしてもよい。

制御部３０は、同じカテゴリの電話番号とＥｍａｉｌアドレスとは対応関係にあると判断する。たとえば、行４２２に示す電話番号１のカテゴリと行４２８に示すＥｍａｉｌアドレスのカテゴリとは、共に「携帯電話（私物）」であるため、制御部３０は、これらが対応関係にあると判断する。また、行４２６に示す電話番号３のカテゴリと行４３０に示すＥｍａｉｌアドレスのカテゴリとは、共に「携帯電話（会社）」であるため、制御部３０は、これらが対応関係にあると判断する。

次に、以上のようなデータ構造の電話帳ＤＢを用いて携帯情報端末１が音声着信時に行なう処理について説明する。

本実施の形態に係る携帯情報端末１は、実施の形態１と同様に音声着信時において同一キャリアからの着信であれば、ディスプレイに同一キャリアからの着信である旨の表示を行なう。この際、実施の形態１とはキャリアが同一かどうかの判断方法が異なる。

図１３は、音声着信時の処理を示したフローチャートである。
図１３を参照して、音声着信時における処理について説明する。なお、図１３のフローチャートで示す処理は、制御部３０として機能するプロセッサが記憶部３２に記憶されるプログラムを読み出して実行し、図３に示された各部を制御することによって実現される。また、図１３のフローチャートで示す処理は、音声着信時の処理の一具体例に過ぎず、たとえば、ステップの順番を入れ替えて実行してもよい。

なお、ステップＳ１２０〜１２６およびステップＳ１５２の処理は、図７のステップＳ１００〜１０６およびステップＳ１１６の処理と同じなので説明は省略する。

ステップＳ１２８において、制御部３０は、該当電話帳レコード内に登録されているＥｍａｉｌアドレスの数を取得する。

続いて、ステップＳ１３０において、制御部３０は、変数ｉを１にセットする。
さらに、ステップＳ１３２において、制御部３０は、カウンタｊを０にセットする。カウンタｊは、発信者番号と同一カテゴリのＥｍａｉｌアドレスをカウントするのに用いられる。

そして、ステップＳ１３４において、制御部３０は、該当電話帳レコードにおいて、Ｅｍａｉｌアドレスｉのカテゴリと、登録されている発信者番号のカテゴリとが同一であるかどうかを判定する。

カテゴリが同一でないと判断すれば（ステップＳ１３４において、ＮＯ）、ステップＳ１４２の処理に進む。

一方、カテゴリが同一であると判断すれば（ステップＳ１３４において、ＹＥＳ）、ステップＳ１３６において、現在のカウンタｊが１であるかどうか判断する。

現在のカウンタｊが１であると判断した場合（ステップＳ１３６において、ＹＥＳ）、発信者電話番号と同一のカテゴリをもつＥｍａｉｌアドレスが複数あることになるため、発信者電話番号と対応関係にあるＥｍａｉｌアドレスが判断できない。したがって、制御部３０はステップＳ１５２の処理に進む。

一方、現在のカウンタｊが１でないと判断すれば（ステップＳ１３６において、ＮＯ）、ステップＳ１３８において、制御部３０は、現在のカウンタｊに１を加算し、更新する。

次いで、ステップＳ１４０において、制御部３０は、ステップＳ１３４でカテゴリが同一であると判断した、該当Ｅｍａｉｌアドレスを記憶部３２に書き込む。

そして、ステップＳ１４２において、制御部３０は、ステップＳ１２８で取得した、電話帳レコード内のＥｍａｉｌアドレスの数と変数ｉとが同じかどうかを判定する。

アドレスの数と変数ｉとが同じでないと判断すれば（ステップＳ１４２において、ＮＯ）、ステップＳ１４４において、制御部３０は変数ｉに１を加算し、ステップＳ１３４の処理に戻る。

一方、アドレスの数と変数ｉとが同じと判断すれば（ステップＳ１４２において、ＹＥＳ）、ステップＳ１４６において、制御部３０はカウンタｊが１かどうかを判定する。

カウンタｊが１でないと判断すれば（ステップＳ１４６において、ＮＯ）、発信者電話番号と同一カテゴリのＥｍａｉｌアドレスはないということなので、ステップＳ１５２の処理に進む。

一方、カウンタｊが１であると判断すれば（ステップＳ１４６において、ＹＥＳ）、ステップＳ１４８において、制御部３０は、ステップＳ１４０で記憶部３２に書き込んだＥｍａｉｌアドレスのドメインが対応テーブル３２ｂに含まれるかどうかを判断する。

ドメインが対応テーブルに含まれないと判断すれば（ステップＳ１４８において、ＮＯ）、ドメインからキャリア名は特定できないため、ステップＳ１５２の処理に進む。

一方、ドメインが対応テーブルに含まれると判断すれば（ステップＳ１４８において、ＹＥＳ）、ステップＳ１５０において、制御部３０は、表示ドライバ部３４に対し、ディスプレイ４にキャリア名を含む着信画面を表示するように指示する。

以上のようにして、音声着信時の処理を終了する。
本実施の形態に係る携帯情報端末は、電話帳レコードに含まれる、電話番号およびＥｍａｉｌアドレスのカテゴリに基づきキャリアを判断する。これにより、既存の電話帳のデータを利用して、キャリア名を判断できるため、新たにサブＤＢを作る手間を省くことができる。

［実施の形態３］
本実施の形態に係る携帯情報端末１は、通信先端末と自端末が同一キャリアか否かを自動的に登録する点が実施の形態１と異なる。

図１４は、電話帳ＤＢ３２ａのデータ構造の一例を示した図である。
図１４を参照して、本実施の形態に係る電話帳ＤＢ３２ａのデータ構造について説明する。

図１４に示すように、電話帳のデータベース５１０は、複数のレコード（１件目〜ｎ件目）から構成される。レコード５００は、１名分のデータを示している。

レコード５００は、行５２０に示される名前と、行５２１，５２３，５２５に示される電話番号と、行５２２，５２４，５２６に示されるキャリア情報と、行５２７〜５２９に示されるＥｍａｉｌアドレス等とのフィールドから構成される。このように、１名分のデータには、複数の電話番号、Ｅｍａｉｌアドレスおよびキャリア情報が含まれていてもよいし、それぞれ１つずつ含まれるようにしてもよい。

ここで、「キャリア情報」とは、自端末に割り当てられている電話番号を提供するキャリアと通信相手の電話番号を提供するキャリアとが同一か否かを示す情報をいう。たとえば、行５２２に示すようにキャリア情報１は、行５２１に示す電話番号１のキャリアと自端末の電話番号のキャリアとが同一であることを示している。また、行５２４に示すキャリア情報２は、行５２３に示す電話番号２のキャリアと自端末の電話番号のキャリアとが同一であるかどうかは未登録であることを示している。さらに、行５２６に示すキャリア情報３は、行５２５に示す電話番号３のキャリアと自端末の電話番号のキャリアとは異なることを示している。キャリア情報は、以下で説明するようにして自動登録されるが、ユーザが入力するようにしてもよい。

本実施の形態に係る携帯情報端末１は、電話番号を宛先として同一キャリア間でのみ送受信できるメール（以下、「同一キャリア間メール」と呼ぶ）を利用して、キャリア情報を自動登録する。同一キャリア間メールによってメッセージを送信する際は、電話番号を宛先とする。このため、通信端末間においてキャリアが異なる場合は、ショートメッセージを送信しても、サーバよりエラーメッセージが返送される。本実施の形態に係る携帯情報端末１は、同一キャリア間メールのこのような仕組みを利用して、キャリア情報を自動登録するものである。

図１５は、受信した同一キャリア間メールに基づきキャリア情報を自動登録する処理を示したフローチャートである。

図１５を参照して、受信した同一キャリア間メールに基づきキャリア情報を自動登録する処理について説明する。

まず、ステップＳ１６０において、制御部３０は、通信制御部３５から、無線部６５を介した同一キャリア間メール受信の通知を受ける。

次いで、ステップＳ１６２において、制御部３０は、同一キャリア間メールの送信者の電話番号が電話帳ＤＢ３２ａに登録されているかどうかを判定する。ここでは、制御部３０は、電話帳ＤＢ３２ａを構成するレコードに含まれる電話番号と送信者の電話番号とを照会し、一致するものがあるかどうかを調べる。

電話帳ＤＢに登録されていないと判断すれば（ステップＳ１６２において、ＮＯ）、処理を終了する。

一方、電話帳ＤＢに登録されていると判断すれば（ステップＳ１６２において、ＹＥＳ）、ステップＳ１６４において、制御部３０は、当該電話番号に対応するキャリア情報が登録されているかどうかを調べる。

キャリア情報が登録されていると判断すれば（ステップＳ１６４において、ＹＥＳ）、処理を終了する。

一方、キャリア情報が登録されていないと判断すれば（ステップＳ１６４において、ＮＯ）、ステップＳ１６６において、制御部３０は、該当電話番号が自端末と同一キャリアである旨の登録を行ない、処理を終了する。

以上のようにして、受信した同一キャリア間メールに基づきキャリア情報を自動登録する処理を実行する。

図１６は、送信した同一キャリア間メールに基づきキャリア情報を自動登録する処理を示したフローチャートである。

図１６を参照して、送信した同一キャリア間メールに基づきキャリア情報を自動登録する処理について説明する。

まず、ステップＳ１７０において、制御部３０は、通信制御部３５に対し、同一キャリア間メールを送信するよう指示する。ただし、送信した同一キャリア間メールの宛先は電話帳ＤＢ３２ａに登録されているものとする。

次いで、ステップＳ１７２において、制御部３０は、内蔵するタイマーを初期化し、時刻カウントを開始する。

そして、ステップＳ１７４において、制御部３０は、通信制御部３０が、同一キャリア間メールのサーバからエラーメッセージを受信したかどうかを判定する。

エラーメッセージを受信していないと判断すれば（ステップＳ１７４において、ＮＯ）、ステップＳ１７８において、制御部３０は、時刻カウントを開始してから所定時間経過したかどうかを判定する。

所定時間経過していないと判断すれば（ステップＳ１７８において、ＮＯ）、ステップＳ１７４の処理に戻る。また、所定時間経過したと判断すれば（ステップＳ１７８において、ＹＥＳ）、ステップＳ１８０において、制御部３０は、送信した同一キャリア間メールの宛先の電話番号のキャリアと自端末のキャリアとが同一と判断する。そして、該当電話番号のキャリア情報にキャリア同一と登録し、処理を終了する。

一方、エラーメッセージを受信したと判断すれば（ステップＳ１７４において、ＹＥＳ）、ステップＳ１７６において、制御部３０は、送信した同一キャリア間メールの宛先の電話番号のキャリアと自端末のキャリアとが異なると判断する。そして、該当電話番号のキャリア情報にキャリアが異なると登録し、処理を終了する。

以上のようにして、送信した同一キャリア間メールに基づきキャリア情報を自動登録する処理を実行する。

上述したように、本実施の形態に係る携帯情報端末は、通信先端末と自端末が同一キャリアか否かを自動的に登録する。これにより、ユーザがキャリアを特定するための情報を入力する手間を省くことができる。

［実施の形態４］
本実施の形態に係る携帯情報端末１は、メール作成時において、メールの電話番号宛先から送信先端末のキャリアを判断し、キャリアに応じた絵文字情報をユーザに通知する。

図１７は、キャリアと絵文字情報との対応関係を表わすテーブルを示す図である。
図１７を参照して、キャリアと絵文字情報との対応関係を表わすテーブルについて説明する。

図１７に示すように、記憶部３２には、キャリアと絵文字情報との対応関係を表わすテーブル６００が格納されている。

テーブル６００では、行６１０〜６１２にあるように、キャリアと、そのキャリアで利用できる絵文字の情報とが対応付けて示されている。

制御部３０は、たとえば、実施の形態１で示したように、宛先として指定されたＥｍａｉｌアドレスや電話番号について、電話帳ＤＢ３２ａおよび対応テーブル３２ｂからキャリアを特定する。

そして、制御部３０は、テーブル６００を参照して、当該キャリアに対応する絵文字情報を記憶部３２から読み込む。そして、表示ドライバ部３４に対し、ディスプレイ４において、読み込んだ絵文字情報に従って絵文字を表示するよう指示する。

図１８は、絵文字表示の画面例を示した図である。
図１８を参照して、メールの送信先端末と同一キャリアの場合の絵文字表示した画面の例について説明する。なお、ここでは、自端末のキャリアをキャリア１とする。また、キャリア名の表示処理については、実施の形態１と同じであるため、説明は省略する。

メール作成画面を示す画面Ｄ２０において、宛先欄７１０に入力された宛先のキャリアは「キャリア１」である。つまり、送信先端末と自端末とは同一キャリアである。

次いで、メール本文作成の画面Ｄ２２において、絵文字入力のための操作を行なうと、画面Ｄ２４に示すように、絵文字の配列表７２０が表示される。ここで、自端末と送信先端末のキャリアは同一であるため、入力が制限される絵文字はない。したがって、どの絵文字も表示をマスクされない。

図１９は、図１８とは異なる、絵文字表示の画面例を示した図である。
図１９を参照して、メールの送信先端末と異なるキャリアの場合の絵文字表示した画面の例について説明する。なお、ここでは、自端末のキャリアをキャリア１とする。また、キャリア名の表示処理については、実施の形態１と同じであるため、説明は省略する。

メール作成画面を示す画面Ｄ３０において、宛先欄７３０に入力された宛先のキャリアは「キャリア２」である。つまり、送信先端末と自端末とはキャリアが異なる。

次いで、メール本文作成の画面Ｄ３２において、絵文字入力のための操作を行なうと、画面Ｄ３４に示すように、絵文字の配列表７４０が表示される。ここで、自端末と送信先端末のキャリアは異なるため、入力が制限される絵文字はマスク（配列表７４０の網掛け部分）される。

上述したように、本実施の形態に係る携帯情報端末は、メール作成時において、メールの電話番号宛先から送信先端末のキャリアを判断し、キャリアに応じた絵文字情報をユーザに通知する。メール作成において利用する絵文字等によっては、キャリアごとに文字コードが異なることがある。このため、絵文字がユーザの意図通りに表示されないということがおこる。キャリアに応じた絵文字情報をユーザに通知ことにより、ユーザは入力した通りの絵文字を送信することができる。

［実施の形態５］
本実施の形態に係る携帯情報端末１は、電話番号を宛先とする、同一キャリア間メールを作成する場合で、自端末と異なるキャリアの電話番号を宛先として選択したとき、ユーザに同一キャリア間メールが利用できないことを通知する。

図２０は、同一キャリア間メール作成時における処理を示したフローチャートである。
図２０を参照して、携帯情報端末１の同一キャリア間メール作成時における処理について説明する。

まず、ステップＳ１８０において、制御部３０は、操作部１７を介して入力された、同一キャリア間メールの宛先（電話番号）を受付ける。なお、ここで入力される電話番号は、電話帳ＤＢ３２ａの電話帳データから選択されるものとする。

次いで、ステップＳ１８２において、制御部３０は、入力された電話番号が自端末のキャリアと同一であるか否かを判定する。たとえば、図７や図１３で示したようにして同一キャリアか否かを判定する。

同一キャリアであると判断すれば（ステップＳ１８２において、ＹＥＳ）、ステップＳ１８４において、制御部３０は、入力された電話番号を、同一キャリア間メールの宛先として確定する。

一方、同一キャリアでないと判断すれば（ステップＳ１８２において、ＮＯ）、ステップＳ１８６において、制御部３０は、入力された電話番号を宛先とする同一キャリア間メールは送信できないため、表示ドライバ部３４に対し、ディスプレイ４においてメール送信不可の通知を表示するよう指示する。

以上のようにして同一キャリア間メール作成時における処理を終了する。なお、同一キャリアか否かの判断ができない場合は、ステップＳ１８４の処理を行なってもよいし、ステップＳ１８６の処理を行なってもよいし、他の処理をおこなってもよい。

図２１は、同一キャリア間メール作成時における画面例を示した図である。
図２１を参照して、同一キャリア間メール作成時におけるディスプレイ４における表示について説明する。なお、自端末のキャリアを「キャリア１」とする。また、電話帳表示時におけるキャリア名表示処理については、実施の形態１と同じであるため、説明は省略する。

画面Ｄ４０は、同一キャリア間メール作成時における、宛先等の入力画面を示している。ここで、宛先欄４１にフォーカスをあてて確定キー１３等を押下すると、ディスプレイ４は、電話帳データを示す画面Ｄ４２に切り替わる。

画面Ｄ４２の符号４３に示すように、同一キャリアであることを示す表示（ここでは、キャリア１）のある電話番号を選択すると、画面Ｄ４４のように表示が切り替わり、宛先として入力される。

また、画面Ｄ４２において、方向キー１２等を押下してフォーカスを移動させると、画面Ｄ４６のように表示が切り替わる。

画面Ｄ４６の符号４７に示すように、同一キャリアでないことを示す表示（ここでは、キャリア名表示無し）の電話番号を選択すると、画面Ｄ４８のように表示が切り替わり、選択した電話番号には同一キャリア間メールの送信はできない旨の通知が表示される。そして、再び、画面Ｄ４０に戻る。

上述したように、本実施の形態に係る携帯情報端末は、同一キャリア間で送受信可能なメール作成する場合で、自端末と異なるキャリアの電話番号を宛先として選択したとき、ユーザに同一キャリア間メールが利用できないことを通知する。これにより、ユーザは誤って同一キャリア間メールを送信することを防ぐことができる。

［実施の形態６］
本実施の形態に係る携帯情報端末１は、メール作成時において、ユーザが選択した宛先のキャリアに応じて、予めキャリアと対応付けられた（最適な）メール種別をユーザに通知する。たとえば、通信料金が安くなるメール種別（たとえば、電子メールやＳＭＳメールなど）を最適なメール種別としてキャリアと対応付けておくことにより、ユーザは料金的なメリットのあるメール種別を知ることができる。

図２２は、キャリアとそのキャリアに最適なメール種別との対応関係を表わしたテーブルを示す図である。

図２２を参照して、キャリアと、そのキャリアに最適なメール種別との対応関係を表わしたテーブルについて説明する。

図２２に示すように、記憶部３２には、キャリアとそのキャリアに最適なメール種別との対応関係を表わすテーブル６５０が格納されている。

テーブル６５０は、行６６０〜６６２にあるように、キャリアと、そのキャリアに最適なメール種別とが対応付けられている。たとえば、そのキャリアの端末にメールを送信する際に、通信料金が安くなるメール種別を対応付ける。各キャリアに対する最適なメール種別は、ユーザが設定することもできるし、製造時において予め設定されていてもよい。

制御部３０は、たとえば、図７や図１３で示したように、宛先として入力された電話番号やＥｍａｉｌアドレスから通信相手のキャリアを判断する。

そして、制御部３０は、テーブル６５０を参照して、当該キャリアについて最適なメール種別を特定する。さらに、制御部３０は、ユーザが最適なメール種別とは異なるメール種別でメール送信しようとしている場合は、最適なメール種別で送信する旨の通知を行なう。

図２３は、メール作成時の画面例を示す図である。
図２３を参照して、メール作成時において、最適なメール種別を表示する画面例について説明する。

たとえば、メール種別Ｂでのメール作成画面Ｄ６０において、フォーカスを宛先欄６１にあてて、確定キー１３等を押下すると、ディスプレイ４は、画面Ｄ６２のように切り替わる。

画面Ｄ６２の符号６３に示すように、キャリア１の電話番号を宛先に選択する。この場合、テーブル６５０の行６６０に示すように、キャリア１では最適なメール種別はメール種別Ａである。このため、画面Ｄ６４に示すように、メール種別Ａで送信する旨の通知がなされる。そして、画面Ｄ６６に示すように、メール種別Ａでのメール作成画面に切り替わる。なお、画面Ｄ６４では、料金的なメリットのあるメール種別Ａで送信するか、そのままメール種別Ｂで送信するかを選択できる表示をしてもよい。

上述したように、本実施の形態に係る携帯情報端末は、メール作成時において、ユーザが選択した宛先のキャリアに応じて、最適なメール種別をユーザに通知する。これにより、ユーザは最適なメール種別でメール送信することができるため、たとえば、料金的なメリットを享受することができる。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

本実施の形態に係る携帯情報端末１の一例を示した斜視図である。 携帯情報端末１の筐体を閉じた状態を示す図である。 携帯情報端末１の機能的構成を示す機能ブロック図である。 電話帳ＤＢ３２ａのデータ構造の一例を示した図である。 電話帳ＤＢ３２ａのデータ構造の一例を示す図である。 ドメインとキャリアとの対応関係を表わしたテーブルを示す図である。 音声着信時の処理を示したフローチャートである。 音声着信時の着信画面例を示した図である。 電話帳データ表示の画面例を示した図である。 音声発信時の画面例を示した図である。 発信履歴の画面例を示した図である。 電話帳ＤＢ３２ａのデータ構造の一例を示した図である。 音声着信時の処理を示したフローチャートである。 電話帳ＤＢ３２ａのデータ構造の一例を示した図である。 受信した同一キャリア間メールに基づきキャリア情報を自動登録する処理を示したフローチャートである。 送信した同一キャリア間メールに基づきキャリア情報を自動登録する処理を示したフローチャートである。 キャリアと絵文字情報との対応関係を表わすテーブルを示す図である。 絵文字表示の画面例を示した図である。 図１８とは異なる、絵文字表示の画面例を示した図である。 同一キャリア間メール作成時における処理を示したフローチャートである。 同一キャリア間メール作成時における画面例を示した図である。 キャリアとそのキャリアに最適なメール種別との対応関係を表わしたテーブルを示す図である。 メール作成時の画面例を示す図である。

符号の説明

１ 携帯情報端末、２ 第１の筐体、３ 第２の筐体、４ ディスプレイ、７ アンテナ、１１ テンキー、１２ 方向キー、１３ 確定キー、１４ オンフックキー、１５ クリアキー、１６ オフフックキー、１７ 操作部、３０ 制御部、３２ 記憶部、３４ 表示ドライバ部、３５ 通信制御部、３６ 再生回路、３９ 音声信号処理部、５３ マイクロフォン、６０ スピーカ、６５ 無線部。

Claims (15)

1. 表示手段と、
   個人を特定するための情報と電話番号とを関連付けて記憶するための記憶手段と、
   前記表示手段に対する表示処理の制御を行なうための制御手段とを備え、
   前記記憶手段は、電話番号を提供する通信事業者を判断するための情報をさらに含み、
   前記制御手段は、
   前記判断するための情報に基づき、与えられた電話番号の通信事業者を判断するための通信事業者判断手段と、
   前記表示手段に対し、前記与えられた電話番号について前記通信事業者判断手段の判断結果に従った表示をするための表示制御手段とを含む、携帯情報端末。
2. 前記記憶手段は、前記個人を特定するための情報と関連付けられた電話番号と対応付けて電子メールアドレスを記憶し、
   前記判断するための情報は、電子メールアドレスのドメインと前記ドメインを提供する通信事業者とが対応付けられた通信事業者対応テーブルであり、
   前記通信事業者判断手段は、
   前記与えられた電話番号を前記記憶手段の中から検索するための手段と、
   前記検索された電話番号に対応付けられた電子メールアドレスを取得するための手段と、
   前記通信事業者対応テーブルに基づき、前記取得した電子メールアドレスのドメインに対応付けられた通信事業者を特定するための手段とを有する、請求項１記載の携帯情報端末。
3. 通信するための通信手段と、
   通信相手との呼接続のための操作を受け付ける操作手段とをさらに備え、
   前記操作手段を介した前記ユーザの操作により、前記呼接続のための処理が行なわれる際に、前記表示制御手段は、前記通信事業者判断手段の判断結果に従った表示を行なう、請求項２記載の携帯情報端末。
4. 前記表示制御手段は、前記操作手段を介した前記ユーザの操作により、前記個人を特定するための情報と、前記個人を特定するための情報に関連付けられた複数の電話番号から構成される一覧表を表示し、
   前記一覧表は、前記複数の電話番号のそれぞれについて、前記通信事業者判断手段の判断結果を含む、請求項３記載の携帯情報端末。
5. 前記通信事業者判断手段は、前記操作手段を介して前記ユーザが電話番号を入力したことに応じて、前記ユーザが入力した前記電話番号の通信事業者を判断し、
   前記表示制御手段は、前記ユーザが入力した前記電話番号に対して発信している際に、前記表示手段において、前記通信事業者判断手段の判断結果を表示する、請求項３記載の携帯情報端末。
6. 通信するための通信手段と、
   前記通信手段が受信した発呼者端末の電話番号を検出するための番号検出手段とをさらに備え、
   前記番号検出手段は、前記検出した発呼者端末の電話番号を前記通信事業者判断手段に与え、
   前記通信事業者判断手段は、前記番号検出手段から与えられた前記発呼者端末の電話番号の通信事業者を判断し、
   前記表示制御手段は、着信画面において、前記発呼者の電話番号について前記通信事業者判断手段の判断結果に従った表示を行なう、請求項２記載の携帯情報端末。
7. 前記記憶手段は、前記個人を特定するための情報に関連付けられた、複数の電話番号および複数の電子メールアドレスと、前記複数の電話番号および前記複数の電子メールアドレスそれぞれが属するカテゴリとを記憶し、
   前記判断するための情報は、前記電子メールアドレスのドメインと前記ドメインの通信事業者とが対応付けられた通信事業者対応テーブルであり、
   前記通信事業者判断手段は、
   前記与えられた電話番号を前記記憶手段の中から検索するための手段と、
   前記検索された電話番号のカテゴリと、前記検索された電話番号と関連付けられた、前記個人を特定するための情報に対応する複数の前記電子メールアドレスのうちから、同一のカテゴリの電子メールアドレスを取得するための手段と、
   前記通信事業者対応テーブルに基づき、前記取得した電子メールアドレスのドメインに対応付けられた通信事業者を特定するための手段とを有する、請求項１記載の携帯情報端末。
8. 前記判断するための情報は、自端末の電話番号の通信事業者と前記記憶手段に記憶された電話番号の通信事業者とが同一か否かを示す情報である、請求項１記載の携帯情報端末。
9. 通信するための通信手段と、
   同一通信事業者端末間で電話番号を宛先として通信できる同一通信事業者間メールを、前記通信手段により送受信することによって、通信相手の通信事業者が前記自端末の通信事業者と同一か否かを登録するための通信事業者登録手段とをさらに備える、請求項８記載の携帯情報端末。
10. 前記通信事業者登録手段は、
    ｉ）前記通信手段が受信した前記同一通信事業者間メールに基づいて、前記同一通信事業者間メールの送信者の電話番号を取得し、
    ｉｉ）前記記憶手段の中から、前記取得した電話番号を検索し、
    ｉｉｉ）前記記憶手段に対し、前記検索した電話番号について、通信事業者が同一であるという情報を登録する、請求項９記載の携帯情報端末。
11. 前記通信事業者登録手段は、前記通信手段が送信した、前記記憶手段に記憶された電話番号を宛先とした同一通信事業者間メールについて、
    前記通信手段がサーバからのエラーメッセージを受信したとの判断に応じて、前記送信した同一通信事業者間メールの宛先の電話番号について、通信事業者が異なるという情報を登録し、
    所定時間以内に、前記通信手段が前記エラーメッセージを受信していないとの判断に応じて、前記送信した同一通信事業者間メールの宛先の電話番号について、通信事業者が同一であるという情報を登録する、請求項９記載の携帯情報端末。
12. 前記記憶手段は、通信事業者ごとに、表示可能な絵文字の情報を記憶し、
    前記表示制御手段は、前記記憶手段から、前記通信事業者判断手段が特定した通信事業者で表示可能な絵文字の情報を読み込んで、前記表示手段に表示する、請求項２記載の携帯情報端末。
13. 前記通信事業者判断手段は、同一通信事業者の端末間において電話番号を宛先として通信できる同一通信事業者間メールにおいて、前記記憶手段に記憶された電話番号が宛先として入力されたことに応じて、前記宛先として入力された電話番号の通信事業者が自端末の通信事業者と同一か否かを判断し、
    前記表示制御手段は、前記通信事業者判断手段が、前記宛先として入力された電話番号の通信事業者が前記自端末の通信事業者と同一でないと判断したことに応じて、前記表示手段に、前記宛先として入力された電話番号に対し同一通信事業者間メールを送信できない旨の表示を行なう、請求項９記載の携帯情報端末。
14. 前記記憶手段は、通信事業者とメール種別とが対応付けられたメール種別対応テーブルを記憶し、
    メール作成時において、
    ｉ）前記通信事業者判断手段は、ユーザによって入力された電子メールのアドレスまたは電話番号に基づき、前記メールの送信相手の通信事業者を特定し、
    ｉｉ）前記表示制御手段は、前記メール種別対応テーブルにおいて、前記特定された通信事業者に対応付けられたメール種別で送信する旨の表示を行なう、請求項２記載の携帯情報端末。
15. 演算部および記憶部を有するコンピュータに、前記コンピュータに接続された表示装置における表示処理をさせるための制御プログラムであって、
    前記記憶部は、個人を特定するための情報と電話番号とが関連付けられた電話帳データおよび電話番号を提供する通信事業者を判断するための情報を記憶し、
    前記演算部は、前記電話帳データおよび前記判断するための情報に基づき、与えられた電話番号の通信事業者を判断するステップと、
    前記演算部は、前記表示装置に対し、前記与えられた電話番号について前記通信事業者を判断判断するステップの判断結果に従った表示をするステップとを備える、制御プログラム。

Images