(57)【要約】【課題】  携帯通信端末にすでに格納されている音楽再生用の楽曲データの中から、発信者を推定できる楽曲を自動で検索して着信音とすることができる携帯通信端末を提供する。【解決手段】  携帯通信端末にメールの着信があると（Ｓ１でＹＥＳ）、メールヘッダーに含まれる発信者のメールアドレスを確認する（Ｓ２）。この発信者のメールアドレスに対応するアドレス帳ＤＢの連絡先属性情報である人名「小倉（おぐら）」などを読み出す（ステップＳ３）。次に、人名「小倉（おぐら）」をキーワードとして、楽曲ＤＢの楽曲属性情報（歌詞、曲名、作曲者名、作詞者名、歌手名等）を検索し、同じキーワードが含まれている楽曲を探す。そして、歌手名「小椋（おぐら）」が一致し、その曲「しくらめん」が検出される（ステップＳ４）。そして、楽曲ＤＢの曲「しくらめん」を読み出して、拡張処理等を行い、鳴動部へ送出して着信音として鳴動させる（ステップＳ５）。【選択図】  図４
2007124585.tif 000002
【特許請求の範囲】
【請求項１】
連絡先の通信番号および連絡先属性情報を格納したアドレス帳記憶手段と、
楽曲の曲データおよび楽曲属性情報を格納した楽曲記憶手段と、
前記連絡先属性情報をキーワードとして、前記楽曲属性情報に一致する楽曲を選択し、当該楽曲を当該連絡先から着信があった時の着信音として設定する制御手段とを
具備することを特徴とする携帯通信端末。
【請求項２】
前記制御手段は、
連絡先から着信があった時に、前記アドレス帳記憶手段に格納されている当該連絡先の通信番号に該当する連絡先属性情報をキーワードとして、前記楽曲属性情報に一致する楽曲を選択し、当該楽曲を着信音として鳴動させること
を特徴とする請求項１に記載の携帯通信端末。
【請求項３】
前記制御手段は、
前記連絡先属性情報をキーワードとして、前記楽曲属性情報に一致する楽曲を選択し、当該楽曲を当該連絡先から着信があった時の着信音として前記アドレス帳記憶手段に予め登録し、連絡先から着信があった時に、当該連絡先に該当する前記アドレス帳記憶手段の着信音を鳴動させること
を特徴とする請求項１に記載の携帯通信端末。
【請求項４】
連絡先の通信番号および連絡先属性情報を格納したアドレス帳記憶手段と、
楽曲の曲データおよび当該曲データのフレーズに同期した歌詞情報を格納した楽曲記憶手段と、
前記連絡先属性情報をキーワードとして、前記歌詞情報に一致する楽曲のフレーズを選択し、当該楽曲のフレーズを含む楽曲部分を主要部分として着信音として設定する制御手段とを
具備することを特徴とする携帯通信端末。
【請求項５】
連絡先の通信番号、連絡先属性情報および発着信頻度を格納したアドレス帳記憶手段と、
楽曲の曲データおよび楽曲属性情報を格納した楽曲記憶手段と、
前記発着信頻度に対応する言語を記憶する発着信頻度言語記憶手段と、
前記連絡先との間の発着信頻度を算出して当該発着信頻度を前記アドレス帳記憶手段に記憶させる共に、前記発着信頻度に対応する言語をキーワードとして、前記楽曲属性情報に一致する楽曲を選択し、当該楽曲を当該連絡先から着信があった時の着信音として設定する制御手段とを
具備することを特徴とする携帯通信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、着信時の着信音を出力する携帯通信端末において、発信者に対応した着信音を設定する携帯通信端末に関する。
【背景技術】
【０００２】
固有の名前を組み込んだ着信音を提供する着信音提供システムがある（例えば、特許文献１参照。）。この特許文献１では、携帯端末のユーザが、発信者の名前を含む着信音、例えば「○○○さんから電話です」という着信音データをサーバを利用して作成し、携帯端末にダウンロードする。そして、携帯端末の電話帳データの設定において、当該発信者からの着信時の着信音としてその着信音データを設定している。それにより、当該発信者からの着信時には当該発信者の名前の入った着信音「○○○さんから電話です」が出力され、誰からの着信であるかがすぐに分かるものである。
【特許文献１】特開２００４−１９３８４０号公報（第６頁、第１０頁、図３）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
背景技術の着信音提供システムでは、ユーザは、電話帳データに登録されている多数の発信者毎に、着信音データをサーバを利用して作成する必要があり、ユーザにとって負担が大きいという問題があった。また、着信音は音声データであり、音楽ではないために、着信メロディーや着歌として音楽を楽しむということができなかった。  
本発明は、上記の問題点を解決するためになされたもので、音楽プレーヤ機能を持つ携帯通信端末にすでに格納されている音楽再生用の楽曲データの中から、発信者を推定できる楽曲を自動で検索して着信音とすることにより、アドレス帳の多数の発信者毎に手動で着信音を検索作成する手間を省くことができる。また、音楽として楽しめる着信音でありながら、誰からの着信であるかを推定できる着信音を有する携帯通信端末を提供することを目的とする。
【課題を解決するための手段】
【０００４】
上記目的を達成するために、本発明の携帯通信端末は、連絡先の通信番号および連絡先属性情報を格納したアドレス帳記憶手段と、楽曲の曲データおよび楽曲属性情報を格納した楽曲記憶手段と、前記連絡先属性情報をキーワードとして、前記楽曲属性情報に一致する楽曲を選択し、当該楽曲を当該連絡先から着信があった時の着信音として設定する制御手段とを具備することを特徴とする。
【発明の効果】
【０００５】
本発明によれば、音楽再生用の楽曲データの中から、発信者を推定できる楽曲を自動で検索して着信音とすることにより、アドレス帳の多数の発信者毎に手動で着信音を検索作成する手間を省くことができる。また、音楽として楽しめる着信音でありながら、誰からの着信であるかを推定できる着信音とすることが可能になる。
【発明を実施するための最良の形態】
【０００６】
図１は、本発明の各実施例に係る携帯通信端末の構成図である。携帯通信端末１００は、キー入力部１、表示部２、アンテナ３、通信部４、発着信頻度言語ＤＢ５、アドレス帳ＤＢ６、楽曲ＤＢ７、鳴動部８、制御部９などによって構成される。更に、制御部９は、着信音設定用ＵＩ部１０、キーワード作成部１１、楽曲選択部１２などを含む。  
キー入力部１は、ユーザ操作による入力手段である。表示部２は、ＬＣＤ等の表示手段である。アンテナ３は、図示しない基地局との間で電波の送信受信を行う。通信部４は、変調復調処理等を行う。発着信頻度言語ＤＢ５は、携帯通信端末１００の通信相手との間の発着信の頻度に対応する言語、例えば「おひさしぶり」、「たびたび」などを記憶するデータベースである。アドレス帳ＤＢ６は、通信相手の人名、メールアドレス、電話番号、住所などを記憶するデータベースであり、後の図３で詳述する。楽曲ＤＢ７は、携帯通信端末１００を音楽再生プレーヤとして使用する場合の音楽データ記憶手段であり、圧縮された曲データが記憶されている。これらは、ユーザがインターネットや記憶媒体を介して入手した好みの音楽データを記憶するデータベースであり、後の図２で詳述する。鳴動部８は、着信音、警告音、楽曲ＤＢ７に記憶されている楽曲等をユーザに対して出力する。
【０００７】
制御部９は、図示しないＣＰＵ、ＤＳＰ、プログラムＲＯＭ、ワーキングＲＡＭ等により構成され、携帯通信端末１００の主要な制御を行う。特に、制御部９内の着信音設定用ＵＩ部１０は、ユーザ操作により着信音の設定等を行うユーザインターフェースである。キーワード作成部１１は、発着信頻度言語ＤＢ５およびアドレス帳ＤＢ６のデータからキーワードを作成する。楽曲選択部１２は、このキーワードで楽曲ＤＢ７を検索して、着信音を選択作成する。
【０００８】
図２は、本発明の各実施例に係る携帯通信端末の楽曲ＤＢのデータ構成を説明する図である。楽曲ＤＢ７は、ユーザがインターネットや記憶媒体を介して予め入手し、記憶したものである。または、携帯通信端末１００に予め記憶されていたものであってもよい。２つの楽曲である曲ＩＤ７１と曲ＩＤ７２について図示する。各楽曲のデータとして、符号７ａ欄は曲ＩＤ、符号７ｂ欄は実際に演奏される曲データである。その他の欄は、楽曲属性情報であり、符号７ｃ欄は歌詞データ、符号７ｄ欄は曲名、符号７ｅは作曲者名、符号７ｆ欄は作詞者名、符号７ｇ欄は歌手名が記憶されている。例えば、曲ＩＤ７１の楽曲は、曲名「しくらめん」、歌手名「小椋（おぐら）」であり、その他の欄にもデータが記憶されている。
【０００９】
図３は、本発明の各実施例に係る携帯通信端末のアドレス帳ＤＢのデータ構成を説明する図である。アドレス帳ＤＢ６は、ユーザが予め通信相手となる連絡先の人名やメールアドレス等を登録したものである。２人の連絡先６１、６２について図示する。連絡先属性情報として、符号６ａ欄は人名、符号６ｂ欄は住所が記憶されている。通信相手を特定する通信番号として、符号６ｃ欄はメールアドレス、符号６ｄ欄は電話番号である。符号６ｅ欄は着信音ＩＤが記憶される。例えば、連絡先６１は、人名「小倉（おぐら）」、メールアドレス「ａｂｃ＠ｄｅｆ」であり、その他の欄にもデータが記憶されている。符号６ｅ欄の着信音ＩＤは後述の実施例２に関連しており、後の実施例２、図５で詳述する。
【００１０】
なお、符号６ａ欄は人名に限らず、会社名等、連絡先を表すものであれば何でもよい。また、連絡先属性情報は、人名、住所等に限らず、連絡先に関連した趣味や特徴等、その他の情報を新たに追加してもよい。
【実施例１】
【００１１】
本発明の実施例１は、着信時に、発信者に関するキーワードで楽曲ＤＢを検索し、検索した楽曲を着信音として鳴動させるものである。  
図４は、本発明の実施例１に係る携帯通信端末の制御部の動作フローチャートであり、他の携帯通信端末から着信があった時の処理である。図１、図２、図３も用いて動作を説明する。制御部９は、アンテナ３、通信部４を経由して他の携帯通信端末からの着信をチェックしている（ステップＳ１）。例えば、メールの着信があると（ステップＳ１でＹＥＳ）、メールヘッダーに含まれる発信者のメールアドレスを確認する（ステップＳ２）。この発信者のメールアドレスが「ａｂｃ＠ｄｅｆ」とすると、アドレス帳ＤＢ６に「ａｂｃ＠ｄｅｆ」が登録してあるかをチェックし、連絡先６１に該当することがわかり、連絡先６１の連絡先属性情報である人名「小倉」、住所「・・・」を読み出す（ステップＳ３）。
【００１２】
次に、人名「小倉」、住所「・・・」のいずれか、例えば、人名「小倉」をキーワードとして、楽曲ＤＢ７の楽曲属性情報を検索し、同じキーワードが含まれている楽曲を探す。このキーワードの一致条件は、漢字コードが一致しなくても、音読みでのコードが一致していてもよい。従って、連絡先属性情報である人名「小倉（おぐら）」に一致する楽曲属性情報の歌手名「小椋（おぐら）」が一致し、その曲ＩＤ７１（曲名「しくらめん」）が検出される（ステップＳ４）。そして、楽曲ＤＢ７の曲ＩＤ７１の曲データを読み出して、拡張処理等を行い、鳴動部８へ送出して着信音として鳴動させる（ステップＳ５）。これを聞いたユーザは、自分が楽曲ＤＢ７に登録した好みの楽曲であるので、曲名「しくらめん」、歌手名「小椋（おぐら）」であることがすぐにわかる。そして、この着信は、発信者「小倉（おぐら）」からの通信であることをすぐに理解することができる。
【００１３】
なお、キーワードとする連絡先属性情報は、人名、住所、会社名、趣味、特徴等の発信者を特定しやすいものであれば何でもよい。また、そのキーワードをもとに検索する対象の楽曲属性情報は、歌詞、曲名、作曲者名、作詞者名、歌手名等の楽曲を特定しやすいものであれば何でもよい。また、連絡先属性情報の人名、住所、会社名、趣味、特徴等と、楽曲属性情報の歌詞、曲名、作曲者名、作詞者名、歌手名等との組み合わせは任意に設定してよい。  
また、着信時にチェックする発信者の番号は、メールアドレスに限らず、電話番号でもよい。すなわち、メールアドレスや電話番号等の通信相手を特定できる固有の通信番号であればよい。それらの通信番号を基にアドレス帳ＤＢをチェックして同様の処理を行えばよい。
【００１４】
実施例１によれば、着信時に、発信者に関するキーワードで楽曲ＤＢを検索し、検索した楽曲を着信音として鳴動させる。それにより、ユーザが予め音楽再生用として記憶している好みの楽曲の中から自動で選択して着信音として聞くことができると共に、その着信音を聞くだけで誰からの着信であるかを知ることができる。
【実施例２】
【００１５】
本発明の実施例２は、ユーザが予めユーザインターフェース処理のサポートにより簡単な操作で、アドレス帳の連絡先に関するキーワードで自動検索された楽曲を着信音としてアドレス帳に登録する。そして、着信時にその着信音を鳴動するものである。  
図５（ａ）および図５（ｂ）は、本発明の実施例２に係る携帯通信端末の制御部の動作フローチャートである。
【００１６】
図５（ａ）は、ユーザが予め着信音を登録する時の制御部の動作フローチャートである。
【００１７】
制御部９は、アドレス帳ＤＢ６を読み取って表示部２への表示を行う（ステップＳ１１）。そして、アドレス帳ＤＢ６（図３）の登録案件、例えば、連絡先６１について、連絡先属性情報である人名「小倉」、住所「・・・」を読み出す（ステップＳ１２）。次に、人名「小倉」、住所「・・・」のいずれか、例えば、人名「小倉」をキーワードとして、楽曲ＤＢ７（図２）の楽曲属性情報を検索し、歌手名「小椋（おぐら）」を検出し、その曲ＩＤ７１（曲名「しくらめん」）が選択され、曲ＩＤ７１の楽曲属性情報を表示する（ステップＳ１３）。
【００１８】
ユーザがそれを見て、確定操作を行う（ステップＳ１４でＹＥＳ）と、制御部９は、楽曲ＤＢ７の曲ＩＤ７１（曲名「しくらめん」）を、アドレス帳ＤＢ６の連絡先６１の符号６ｅの着信音ＩＤ欄に登録記憶する（ステップＳ１５）。ステップＳ１４で「ＮＯ」の場合、ステップＳ１３の検索を再度行い、ユーザがＯＫを出すまでステップＳ１３とＳ１４を繰り返す。なお、繰り返さないで、ステップＳ１４で「ＮＯ」の場合、ステップＳ１５を飛ばして、ステップＳ１６の処理へ進んでもよい。
【００１９】
ステップＳ１５で連絡先６１についての着信音ＩＤの登録が済んだら、次に、継続操作か終了操作かをチェックし（ステップＳ１６）、終了するまで、全通信相手について、ステップＳ１２〜Ｓ１５の処理を繰り返す。
【００２０】
図５（ｂ）は、図５（ａ）の登録処理が終わった後に、他の携帯通信端末から着信があった時の着信音鳴動の制御部の動作フローチャートである。制御部９は、他の携帯通信端末からの着信をチェックしている（ステップＳ２１）。メールの着信があると（ステップＳ２１でＹＥＳ）、メールヘッダーに含まれる発信者のメールアドレスを確認する（ステップＳ２２）。この発信者のメールアドレスが「ａｂｃ＠ｄｅｆ」とすると、アドレス帳ＤＢ６に「ａｂｃ＠ｄｅｆ」が登録してあるかをチェックし、連絡先６１に該当することがわかり、連絡先６１に登録してある曲ＩＤ７１（曲名「しくらめん」）を読み出す（ステップＳ２３）。
【００２１】
そして、楽曲ＤＢ７の曲ＩＤ７１の曲データを読み出して、拡張処理等を行い、鳴動部８へ送出して着信音として鳴動させる（ステップＳ２４）。これを聞いたユーザは、自分がアドレス帳ＤＢ６に登録した着信音であり、発信者「小倉（おぐら）」からの通信であることをすぐに理解することができる。
【００２２】
この着信時の処理では、実施例１の図４のステップＳ４の処理、すなわち、連絡先属性情報をキーワードとして大量の楽曲ＤＢ７の楽曲属性情報を検索する処理時間が不要となり、着信時にスムーズに着信音を鳴動させることができる。
【００２３】
実施例２によれば、ユーザは、予め、アドレス帳の通信相手と着信音とを対応付けて認識することができ、着信音を聞いた時に誰から掛かって来たかを判定しやすい。また、着信時にスムーズに着信音を鳴動させることができる。
【実施例３】
【００２４】
本発明の実施例３は、楽曲ＤＢとして曲データおよび歌詞データをフレーズに細分した形態とし、アドレス帳の発信者に関するキーワードで歌詞データのフレーズ部分に対して検索を行い、そのフレーズ部分を着信音とするものである。
【００２５】
図６は、本発明の実施例３に係る携帯通信端末の楽曲ＤＢのデータ構成を説明する図である。楽曲ＤＢ１０７は、ユーザがインターネットや記憶媒体を介して予め入手し、記憶したものである。または、携帯通信端末１００に予め記憶されていたものであってもよい。１つの楽曲である曲ＩＤ７１について図示する。符号７ａ欄は曲ＩＤであり、曲ＩＤ７１が記憶される。符号７ｂ欄は実際に演奏される曲データであり、例えば、フレーズＮｏ．１〜Ｎｏ．５のフレーズに細分された曲データとして記憶される。符号７ｃ欄は歌詞データであり、フレーズＮｏ．１〜Ｎｏ．５に対応した歌詞が記憶されている。例えば、フレーズＮｏ．３には、「・・・太郎・・・」という歌詞が記憶されている。
【００２６】
図７は、本発明の実施例３に係る携帯通信端末のアドレス帳ＤＢのデータ構成を説明する図である。アドレス帳ＤＢ１０６は、アドレス帳ＤＢ６（図３）に比べて、符号６ｆ欄のフレーズＮｏ．が新たに追加になっている。符号６ｅ欄の着信音ＩＤおよび符号６ｆ欄のフレーズＮｏ．は後述の図８（ａ）の処理により登録される。連絡先６１の人名は「鈴木太郎」、メールアドレスは「ａｂｃ＠ｄｅｆ」とする。
【００２７】
図８（ａ）および図８（ｂ）は、本発明の実施例３に係る携帯通信端末の制御部の動作フローチャートである。  
図８（ａ）は、ユーザが予め着信音を登録する時の制御部の動作フローチャートである。  制御部９は、アドレス帳ＤＢ１０６（図７）を読み取って表示部２への表示を行う（ステップＳ３１）。そして、アドレス帳ＤＢ１０６の登録案件、例えば、連絡先６１について、連絡先属性情報である人名「鈴木太郎」、住所「・・・」を読み出す（ステップＳ３２）。次に、人名「鈴木太郎」、住所「・・・」のいずれか、例えば、人名「鈴木太郎」の全体または一部をキーワードとして、楽曲ＤＢ１０７（図６）の楽曲属性情報の歌詞データを検索し、曲ＩＤ７１のフレーズＮｏ．３「・・・太郎・・・」が検出されると、曲ＩＤ７１の楽曲属性情報とフレーズＮｏ．３の歌詞「・・・太郎・・・」を表示する（ステップＳ３３、Ｓ３４）。
【００２８】
ユーザがそれを見て、確定操作を行う（ステップＳ３５でＹＥＳ）と、制御部９は、楽曲ＤＢ１０７の曲ＩＤ７１およびフレーズＮｏ．３を、アドレス帳ＤＢ１０６の連絡先６１の符号６ｅの着信音ＩＤ欄および符号６ｆのフレーズＮｏ欄に登録記憶する（ステップＳ３６）。ステップＳ３５で「ＮＯ」の場合、ステップＳ３３、Ｓ３４の検索を再度行い、ユーザがＯＫを出すまでステップＳ３３とＳ３４を繰り返す。なお、繰り返さないで、ステップＳ３５で「ＮＯ」の場合、ステップＳ３６を飛ばして、ステップＳ３７の処理へ進んでもよい。  
ステップＳ３６で連絡先６１についての着信音ＩＤおよびフレーズＮｏの登録が済んだら、次に、継続操作か終了操作かをチェックし（ステップＳ３７）、終了するまで、全通信相手について、ステップＳ３２〜Ｓ３６の処理を繰り返す。
【００２９】
図８（ｂ）は、図８（ａ）の登録処理が終わった後に、他の携帯通信端末から着信があった時の着信音鳴動の制御部の動作フローチャートである。制御部９は、他の携帯通信端末からの着信をチェックしている（ステップＳ４１）。メールの着信があると（ステップＳ４１でＹＥＳ）、メールヘッダーに含まれる発信者のメールアドレスを確認する（ステップＳ４２）。この発信者のメールアドレスが「ａｂｃ＠ｄｅｆ」とすると、アドレス帳ＤＢ１０６（図７）に「ａｂｃ＠ｄｅｆ」が登録してあるかをチェックし、連絡先６１に該当することがわかり、連絡先６１に登録してある着信音ＩＤ欄の曲ＩＤ７１およびフレームＮｏ欄のフレームＮｏ．３を読み出す（ステップＳ４３）。
【００３０】
そして、楽曲ＤＢ１０７（図６）の曲ＩＤ７１のフレーズＮｏ．３の曲データを読み出して、拡張処理等を行い、鳴動部８へ送出して着信音として鳴動させる（ステップＳ４４）。これを聞いたユーザは、フレーズＮｏ．３の歌詞「・・・太郎・・・」を直接聞くことになり、発信者「鈴木太郎」からの通信であることをすぐに理解することができる。
【００３１】
なお、フレーズＮｏ．３の部分を着信音の先頭で鳴動させるのではなく、その前のフレーズＮｏ．２あたりを先頭としてフレーズＮｏ．３を含めた着信音としてもよい。または、フレーズＮｏ．３を繰り返してもよい。ユーザは、いきなり着信音が鳴った時、先頭部分を聞き漏らすことがあるので、このようにしてもよい。  
また、ユーザが予め着信音を登録するようにしたが、実施例１と同様に、着信時に自動で検索して着信音を選択するようにしてもよい。
【００３２】
実施例３によれば、アドレス帳の連絡先に関するキーワードで自動検索された楽曲の歌詞フレーズが着信音として直接に鳴動するため、ユーザは、着信音を聞いた時に誰から掛かって来たかをすぐに理解することができる。
【実施例４】
【００３３】
本発明の実施例４は、通信相手との発着信頻度を基にしたキーワードで自動検索して着信音を選択作成するものである。
【００３４】
図９は、本発明の実施例４に係る携帯通信端末の発着信頻度言語ＤＢのデータ構成を説明する図である。発着信頻度言語ＤＢ５は、符号５ａ欄は所定期間内の発着信頻度であり、「０〜２回」、「３〜５回」、「６〜８回」などの回数が記憶される。符号５ｂ欄は符号５ａ欄の発着信頻度を表す言語、例えば「おひさしぶり」、「たびたび」、「いつも」などが記憶されている。符号５ｃ欄の着信音ＩＤ欄は、後述の図１１（ａ）の処理により登録される。
【００３５】
図１０は、本発明の実施例４に係る携帯通信端末のアドレス帳ＤＢのデータ構成を説明する図である。アドレス帳ＤＢ２０６は、アドレス帳ＤＢ６（図３）に比べて、符号６ｅ欄の「発着信頻度」が新たに追加になっている。この発着信頻度は、携帯通信端末１００とアドレス帳ＤＢに登録してある連絡先との間の所定期間内の発着信頻度であり、図示しないが、所定期間内の携帯通信端末１００からの発信および携帯通信端末１００への着信回数をカウントして、符号６ｅ欄に履歴として記憶させるものである。この例では、連絡先６１との間の発着信頻度は１回、連絡先６２との間の発着信頻度は５回が記録されている。
【００３６】
図１１（ａ）および図１１（ｂ）は、本発明の実施例４に係る携帯通信端末の制御部の動作フローチャートである。  
図１１（ａ）は、ユーザが予め着信音を登録する時の制御部の動作フローチャートである。制御部９は、発着信頻度言語ＤＢ５（図９）を読み取って表示部２への表示を行う（ステップＳ５１）。そして、発着信頻度言語ＤＢ５の発着信頻度「０〜２回」を表す言語、例えば「おひさしぶり」を読み出す（ステップＳ５２）。次に、この「おひさしぶり」をキーワードとして、楽曲ＤＢ７（図２）の楽曲属性情報を検索し、一致する楽曲を抽出し、表示する（ステップＳ５３）。なお、楽曲ＤＢ１０７（図６）の歌詞データのフレーズを検索して一致するフレーズを抽出するようにしてもよい。
【００３７】
ユーザがそれを見て、確定操作を行う（ステップＳ５４でＹＥＳ）と、制御部９は、この楽曲の曲ＩＤを、発着信頻度言語ＤＢ５の符号５ｃの着信音ＩＤ欄に登録記憶する（ステップＳ５５）。ステップＳ５４で「ＮＯ」の場合、ステップＳ５３の検索を再度行い、ユーザがＯＫを出すまでステップＳ５３を繰り返す。なお、繰り返さないで、ステップＳ５４で「ＮＯ」の場合、ステップＳ５５を飛ばして、ステップＳ５６の処理へ進んでもよい。
【００３８】
ステップＳ５５で、発着信頻度「０〜２回」についての着信音ＩＤの登録が済んだら、次に、継続操作か終了操作かをチェックし（ステップＳ５６）、発着信頻度「３〜５回」や「６〜８回」についても、ステップＳ５２〜Ｓ５５の処理を繰り返す。
【００３９】
図１１（ｂ）は、図１１（ａ）の登録処理が終わった後に、他の携帯通信端末から着信があった時の着信音鳴動の制御部の動作フローチャートである。制御部９は、他の携帯通信端末からの着信をチェックしている（ステップＳ６１）。メールの着信があると（ステップＳ６１でＹＥＳ）、メールヘッダーに含まれる発信者のメールアドレスを確認する（ステップＳ６２）。この発信者のメールアドレスが「ａｂｃ＠ｄｅｆ」とすると、アドレス帳ＤＢ２０６（図１０）に「ａｂｃ＠ｄｅｆ」が登録してあるかをチェックし、連絡先６１に該当することがわかり、連絡先６１の符号６ｅ欄の発着信頻度の履歴データ「１回」を読み出す（ステップＳ６３）。そして、この「１回」に該当する発着信頻度言語ＤＢ５の発着信頻度「０〜２回」に登録してある着信音ＩＤ欄の曲ＩＤを選択する（ステップＳ６４）。そして、楽曲ＤＢ７（図２）または楽曲ＤＢ１０７（図６）の当該曲ＩＤの曲データや曲データフレーズを読み出して、拡張処理等を行い、鳴動部８へ送出して着信音として鳴動させる（ステップＳ６５）。これを聞いたユーザは、「おひさしぶり」の通信相手であることを知ることができる。
【００４０】
なお、発着信頻度言語ＤＢ５の発着信頻度を表す言語は予め記憶されているとしたが、図１１（ａ）の着信音ユーザ登録時に、ユーザが発着信頻度の回数および言語を任意に作成して登録するようにしてもよい。  
また、着信音ユーザ登録を予め行わないで、実施例１のように、着信時にキーワードを基に検索して着信音を決めてもよい。
【００４１】
実施例４によれば、着信があった時に着信音を聞くことにより、通信相手を直接特定することはできないが、通信相手が「おひさしぶり」であるか、「たびたび」であるか、「いつも」であるかなどの発着信頻度を知ることができる。
【図面の簡単な説明】
【００４２】
【図１】本発明の各実施例に係る携帯通信端末の構成図。
【図２】本発明の各実施例に係る携帯通信端末の楽曲ＤＢのデータ構成を説明する図。
【図３】本発明の各実施例に係る携帯通信端末のアドレス帳ＤＢのデータ構成を説明する図。
【図４】本発明の実施例１に係る携帯通信端末の制御部の動作フローチャート。
【図５】本発明の実施例２に係る携帯通信端末の制御部の動作フローチャート。
【図６】本発明の実施例３に係る携帯通信端末の楽曲ＤＢのデータ構成を説明する図。
【図７】本発明の実施例３に係る携帯通信端末のアドレス帳ＤＢのデータ構成を説明する図。
【図８】本発明の実施例３に係る携帯通信端末の制御部の動作フローチャート。
【図９】本発明の実施例４に係る携帯通信端末の発着信頻度言語ＤＢのデータ構成を説明する図。
【図１０】本発明の実施例４に係る携帯通信端末のアドレス帳ＤＢのデータ構成を説明する図。
【図１１】本発明の実施例４に係る携帯通信端末の制御部の動作フローチャート。
【符号の説明】
【００４３】
１  キー入力部
２  表示部
３  アンテナ
４  通信部
５  発着信頻度言語ＤＢ
６、１０６、２０６  アドレス帳ＤＢ
７、１０７  楽曲ＤＢ
８  鳴動部
９  制御部
１０  着信音設定用ＵＩ部
１１  キーワード作成部
１２  楽曲選択部
１００  携帯通信端末
【図１】
2007124585.tif 000003
【図２】
2007124585.tif 000004
【図３】
2007124585.tif 000005
【図４】
2007124585.tif 000006
【図５】
2007124585.tif 000007
【図６】
2007124585.tif 000008
【図７】
2007124585.tif 000009
【図８】
2007124585.tif 000010
【図９】
2007124585.tif 000011
【図１０】
2007124585.tif 000012
【図１１】
2007124585.tif 000013