JP2005191912A - 再生用データ更新システムおよび再生用データ更新方法 - Google Patents

Abstract

【課題】 着信メロディなどの再生用データの更新を簡単に行うことのできる再生用データ更新システムを提供する。
【解決手段】 携帯端末１００と、携帯端末１００により再生される再生用データを管理するデータベースを備えた配信サーバー２００とを有する。携帯端末１００は、配信サーバー２００から取得した再生用データを格納するための記憶部を備え、該記憶部の内容が、特定の条件で行われる上記データベースの更新に同期して更新される。
【選択図】図１

Description

本発明は、例えば携帯電話機に代表される携帯端末などで使用される着信メロディや待ち受け用画像データなどの再生用データを更新するシステムおよび方法に関する。

近年、着信メロディは、携帯電話の付加サービスとして欠かすことが出来ないものとなっている。通常、利用者は、携帯電話機内に予め登録されている複数種類の着信メロディの中から任意に着信メロディを設定することができるようになっている。また、インターネットへの接続機能を備える携帯電話機においては、利用者は、その携帯電話機を使って、インターネット上の、着信メロディのデータを配信している業者のサイトにアクセスして、そこから所望の着信メロディのデータをダウンロードすることが可能である。例えば、特許文献１には、利用者の生年月日、性別、趣味、好きな音楽のジャンル、希望する着信メロディの曲想などのデータを予め登録しておき、利用者の携帯電話機からの発呼があると、その登録データに基づいて利用者に嗜好に合った着信メロディを自動的に選択して携帯電話機へ送信するようにしたものが提案されている。
特開２００３−２５９０１０号公報

しかしながら、従来の着信メロディの更新は、利用者により手動で行われることが殆どであり、煩わしいものとなっていた。

また、利用者の中には、例えば、関心のあるランキングの順位変動や、好きな芸能人がどの様な着信メロディを用いているかなどを知りたい、といった要求があるが、従来の着信メロディの更新では、そのような情報的価値を付加することは困難であった。

さらに、着信メロディ配信事業者は、利用者の多様な趣味嗜好に応えるために膨大な着信メロディデータを用意する必要があった。

本発明の目的は、上記問題を解決し、着信メロディなどの再生用データの更新を簡単に行うことのできる、システムおよび方法を提供することにある。

本発明の別の目的は、そのような再生用データ更新システムを実現する携帯端末および配信サーバーを提供することにある。

本発明の他の目的は、そのような再生用データ更新方法を実現するためのプログラムを提供することにある。

本発明の再生用データ更新システムは、携帯端末と、前記携帯端末により再生される再生用データを管理するデータベースを備えた配信サーバーと、を有し、前記携帯端末は、前記配信サーバーから取得した再生用データを格納するための記憶部を備え、該記憶部の内容が、特定の条件で行われる前記データベースの更新に同期して更新されることを特徴とする。この構成によれば、携帯端末における、例えば着信メロディなど再生用データの更新は、携帯端末の利用者によって設定された特定の条件で行われるデータベースの更新に同期して行われるので、従来のような煩わしい操作を行う必要がない。また、着信メロディ配信事業者も、特定の条件の設定により、必要となる着信メロディをある程度予測できるため、従来何万曲も用意していた着信メロディをある程度抑制することができる。

上記再生用データ更新システムにおいて、配信サーバーから取得した再生用データを格納するための記憶部を備えた別の携帯端末をさらに有し、特定の条件で行われるデータベースの更新が、前記別の携帯端末の記憶部に格納されている再生用データの更新であってもよい。この構成によれば、他の利用者がどのような再生用データ（着信メロディや待ち受け画像データ）を用いているかを知ることができる。加えて、他の利用者の携帯端末の更新内容がそのまま自身の携帯端末に反映されるので、例えば、友人の携帯端末との更新内容の共通化を行うことが可能となり、利便性が向上する。

また、別の携帯端末は１つまたはそれ以上あり、配信サーバーは、それぞれの別の携帯端末の利用者の公開名を含むメニュー画面を携帯端末へ送信し、該送信したメニュー画面上で選択された公開名の利用者によって使用されている別の携帯端末の記憶部の更新と前記携帯端末の記憶部の更新とを同期させるようにしてもよい。この構成によれば、例えば、別の携帯端末の利用者として例えば芸能人を採用すれば、利用者は、メニュー画面上で任意に選択した芸能人がどのような再生用データ（着信メロディや待ち受け画像）を用いているかを知ることができる。加えて、その芸能人の携帯端末の更新内容がそのまま自身の携帯端末に反映されるので、利用者は、好きな芸能人と常に同じ着信メロディを利用することが可能となる。また、メニューに沿った着信メロディの配信が可能となるため、着信メロディ配信事業者は、用意しておく着信メロディの量をさらに抑制することができる。

さらに、携帯端末は複数あり、データベースは、前記携帯端末のうち、別の携帯端末の利用者によって許可された端末の利用者の識別コードを含み、配信サーバーが、前記別の携帯端末の記憶部の変更と前記サーバーに格納されている識別コードから特定される利用者によって使用されている携帯端末の記憶部の更新とを同期させるようにしてもよい。この構成によれば、再生用データ（着信メロディや待ち受け画像）の更新をグループ内で共通化することができる。すなわち、グループ全体で同じ再生用データ（着信メロディや待ち受け画像）を使用することができる。これにより、利便性が向上する。

さらに、再生用データがランク付けの可能なデータであり、特定の条件で行われるデータベースの更新が前記ランク付けの変更であってもよい。この構成によれば、例えば、曲のランキング順位が変動した場合、その変動に同期して利用者の携帯端末の着信メロディの内容が更新される。よって、利用者は、携帯端末上で着信メロディが更新されることで、現在のランキングの順位を知ることができる。また、ランキング順位の変動として、今、人気が上昇してきているもの（急上昇中のもの）、地域的に人気が上昇してきているものを設定することで、他の人より早く、人気の着信メロディを取得することが可能となる。さらに、ランキング順位の対応ジャンルを限定することもできる。

本発明の再生用データ更新方法は、携帯端末と、該携帯端末により再生される再生用データを管理するデータベースを備えた配信サーバーと、を有するシステムにおいて行われる再生用データ更新方法であって、前記携帯端末が、自端末内の記憶部に前記配信サーバーから取得した再生用データを格納するステップと、前記配信サーバーが、特定の条件で行われる前記データベースの更新に同期して前記記憶部の内容を更新させるステップと、を含むことを特徴とする。この方法も、上述した本発明の再生用データ更新システムと同様な作用を有する。

本発明の配信サーバーは、携帯端末により再生される再生用データを管理するデータベースと、特定の条件で行われる前記データベースの更新と前記携帯端末に格納されている再生用データの更新とを同期させる処理部と、を有することを特徴とする。この配信サーバーも、上述した本発明の再生用データ更新システムと同様な作用を有する。

本発明の携帯端末は、記憶部と、再生用データを管理するデータベースを備えた配信サーバーから取得した前記再生用データを前記記憶部に格納する処理部と、を有し、前記記憶部に格納されている再生用データの更新が、特定の条件で行われる前記データベースの更新に同期して行われることを特徴とする。この携帯端末も、上述した本発明の再生用データ更新システムと同様な作用を有する。

本発明の第１のプログラムは、配信サーバーのコンピュータに、携帯端末により再生される再生用データをデータベースで管理する処理と、特定の条件で行われる前記データベースの更新と前記携帯端末に格納されている再生用データの更新とを同期させる処理と、を実行させることを特徴とする。この第１のプログラムも、上述した本発明の再生用データ更新システムと同様な作用を有する。

本発明の第２のプログラムは、携帯端末のコンピュータに、再生用データを管理するデータベースを備えた配信サーバーから取得した前記再生用データを記憶部に格納する処理部と、前記記憶部に格納されている再生用データを、特定の条件で行われる前記データベースの更新に同期して更新する処理と、を実行させることを特徴とする。この第２のプログラムも、上述した本発明の再生用データ更新システムと同様な作用を有する。

上記のとおりの本発明によれば、携帯端末における再生用データ（着信メロディや待ち受け画像）は、利用者によって設定された特定の条件で行われるデータベースの更新と同期して自動更新されるので、例えば、利用者は、手動で着信メロディを更新する必要なく、趣味嗜好に合致した着信メロディの更新を行うことができる。

加えて、例えば「有名芸能人と同じ着信メロディ」、「その日に一番売り上げが伸びた曲」等、着信メロディそのものを超える情報的価値を付加することができる。

着信メロディ配信事業者（システム運用者）は、ある程度メニューに沿った着信メロディを配信することが可能であるので、データ量の削減が可能である。

次に、本発明の実施の形態について図面を参照して詳細に説明する。

図１は、本発明の一実施形態である着信メロディ更新システムの概略構成を示すブロック図である。この着信メロディ更新システムでは、利用者が利用する端末１００と着信メロディを配信サービスを行う事業者によって運用される配信サーバー２００とがネットワーク３００を介して相互通信可能に接続されている。端末１００は、例えば携帯電話端末などのネットワーク３００への接続が可能な端末である。利用者は、端末１００を使用して配信サーバー２００へアクセスすることができる。

図２に、端末１００の主要部を示す。図２を参照すると、端末１００は、記憶部１０１、処理部１０２、通信部１０３、入力部１０４、出力部１０５からなり、これら各部がバス等を介して相互に接続されている。

記憶部１０１は、ソフトウェアやソフトウェアに用いられるデータが保持される領域であり、一般的には、ＥＥＰＲＯＭなどの書き換え可能な記憶手段からなるが、ソフトウェア本体等のデータが変更されないようにＲＯＭなどの書き換え不可能な記憶手段より構成することもできる。処理部１０２は、データ処理を行う部分であって、一般的には、ＭＰＵ等の演算処理装置と、キャッシュメモリやＲＡＭ等の一時記憶装置から構成される。通信部１０３は、ネットワーク３００を通じて配信サーバー２００とデータ通信を行う部分である。例えば、携帯電話機の場合であれば、この通信部１０３は、ネットワークと無線通信を行うためのアンテナや、デジタル化・暗号化・復号化などを行う通信処理チップなどから構成される。入力部１０４は、利用者が操作するキーや、音声を入力するマイク等である。出力部１０５は、視覚的・聴覚的な出力を行うものであって、例えば液晶パネルやスピーカーなどから構成される。

図３に、記憶部１０１に格納されるデータの構成例を示す。図３を参照すると、記憶部１０１には、端末１００上で使用されるソフトウェア１０１ａの他、利用者識別コード１０１ｂと、着信メロディデータ１０１ｃおよびこれに対応する着信メロディ識別コード１０１ｄとが格納される。

ソフトウェア１０１ａは、後述の更新チェック処理を実行するためのものである。このソフトウェア１０１ａは、例えば、利用者が、端末１００を使用して配信サーバー２００にアクセスして利用者登録を行った際にダウンロードされる。利用者識別コード１０１ｂは、各利用者に固有のコードである。例えば、端末１００が携帯電話端末である場合は、電話番号や端末ＩＤ等がこの利用者識別コード１０１ｂに相当する。一般に、携帯電話通信ネットワークにおいては、課金等の処理を行うため、当該ネットワークを通じて接続している利用者を特定できる情報をサービス事業者に提供する様々な機能が備わっており、本実施形態では、それら機能が適宜採用される。例えば、利用者識別コード１０１ｂは、ソフトウェアのダウンロードと同時にダウンロードされても良いし、利用者識別画面を提示して、接続時に、利用者が、その利用者識別画面上で予め与えられた利用者識別コードを入力する形式でも良い。本実施形態では、利用者には、一般利用者と有名人利用者があり、利用者識別コードにより利用者の種類が特定されるようになっている。

図４は、端末１００における着信メロディの再生手順を説明するためのフローチャートである。端末１００は、通信部１０３にて通話の着信が行われるのを待ち受けている（ステップＳ１０）。着信すると、記憶部１０１に格納された着信メロディデータ１０１ｄを再生し（ステップＳ１１）、入力部１０４において利用者が電話に出るための所定の操作を行うのを待ち受ける（ステップＳ１２）。利用者が電話に出ると、着信メロディデータ１０１ｄの再生を止め（ステップＳ１３）、通話が終了するのを待ち受ける（ステップＳ１４）。通話が終了すると、通話の着信待ち受けに戻る（ステップＳ１５）。

上記のよう着信メロディの再生は、通話の着信時の他、電子メールが着信した時、タイマー設定時刻に達した時、等の条件に合わせて行うことができる。これらの着信メロディの再生は、基本的には、利用者が特に明示的な操作を行う必要なく、端末１００の電源が入っている限り行われる。なお、サイレントモード等の設定が行っている場合には、着信メロディの再生を行わないようにすることもできる。ここで説明した着信メロディの再生は、既存の携帯電話端末に備わっているものであり、その再生にあたっては、他の既存の機能に基づく制御を適宜活用することができる。

また、端末１００は、インターネットへの接続機能としてよく知られたブラウザ機能を備えており、ネットワーク３００を通じて配信サーバー２００へ、要求や利用者の入力したデータを送信し、配信サーバー２００から返信されたデータを処理することができる。このようなネットワークブラウザが有する一般的な機能としては、例えば、
（ａ）利用者により指定されたネットワークＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に対しＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ ＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）等のプロトコルを用いて要求を送信する機能、
（ｂ）要求に対して返信されたｃＨＴＭＬ（Ｃｏｍｐａｃｔ ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐ Ｌａｎｇｕａｇｅ）等の形式で記述された文字・画像・入力フォーム等のデータを表示する機能、
（ｃ）表示された入力フォームに対し利用者の入力を受け付け、入力された情報をサーバーに送信する機能、
（ｄ）要求に対する返信がソフトウェアプログラムの場合これをネットワーク経由でダウンロードし記憶部に格納する機能、
（ｅ）要求に対する返信が着信メロディデータの場合これをダウンロードし記憶部に格納する機能、
などがある。ネットワークブラウザは、従来から一般的な携帯電話端末に備わっているものであり、上述した配信サーバー２００との間の要求やデータの送受信処理が可能であれば、他のネットワークブラウザを使用してもよい。

図５に、配信サーバー２００の主要部を示す。図５を参照すると、配信サーバー２００は、記憶部２０１、処理部２０２、通信部２０３からなり、これら各部がバス等を介して相互に接続されている。記憶部２０１は、例えばハードディスクドライブに代表される書き換え可能な記憶装置よりなる。処理部２０２は、ＭＰＵ等の演算処理装置と、キャッシュメモリやＲＡＭ等の一時記憶装置とからなる。通信部２０３は、ネットワーク３００を通じて端末１００とデータ通信を行うためのものであって、ネットワーク３００に有線接続されている。

配信サーバー２００には、上記の各構成の他、端末１００の要求に対して、対応した返信データを返信するネットワークサーバー機能、その要求から利用者識別コードを取得する利用者識別機能が備わっている。

次に、配信サーバー２００の記憶部２０１に格納されるデータに関して説明する。図６に、記憶部２０１に格納される利用者表の論理データ構造（データベース）を示す。この利用者表は、一般利用者の表であって、利用者コードとメニューコードを対応づけて格納した構成になっている。例えば、利用者コードとして「１０００１」、「１０００２」、「１０００３」が格納され、それぞれの利用者コードの欄にメニューコードとして「Ａ」、「Ｂ」、「Ｃ」が格納されている。

図７に、記憶部２０１に格納される着信メロディ表の論理データ構造（データベース）を示す。この着信メロディ表は、着信メロディコードとそれに対応する着信メロディ名、着信メロディデータを格納したものである。この例では、着信メロディコードとして「１０００００１」、「１０００００２」、「１０００００３」が格納されており、それぞれの着信メロディコードの欄に、着信メロディ名とそれに対応する着信メロディデータが対応付けられて格納されている。着信メロディ表の内容は、配信サーバー２００の運営者によって管理されており、新しい着信メロディが追加される度に更新される。

図８に、記憶部２０１に格納されるメニュー表の論理データ構造（データベース）を示す。このメニュー表は、当該システムを利用する有名人利用者が自身の端末で実際に使用している着信メロディに関する情報を格納するものであって、メニューコードとそれに対応するメニュー名、利用者コード、着信メロディコードを格納するようになっている。メニュー表のメニューコードおよび利用者コードは、図６に示した利用者表のメニューコードおよび利用者コードと対応する。メニュー表の着信メロディコードは、図７に示した着信メロディ表の着信メロディコードに対応する。

上記のメニュー表の作成にあたっては、配信サーバー２００の運用者と有名人利用者本人や代理人との間で予め契約が行われる。メニュー表の内容は、新たな有名人利用者との間で契約が行われる度に、上述した利用者表およびメニュー表の内容が配信サーバー２００の運営者によって更新される。なお、本発明において有名人とは着信メロディを公開する価値が認められる人であれば足り、当該人を知る人数の多寡を限定するものではない。例えば特定の地域でのみ有名な人や、特定の分野でのみ有名な人でもよい。

上述した利用者表、着信メロディ表およびメニュー表は、ＲＤＢＭＳ（ＲｅｌａｔｉｏｎａｌＤａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）等により管理されており、データの検索、更新、追加、削除などが可能である。

次に、本実施形態の着信メロディ配信システムにおける着信メロディの配信動作について具体的に説明する。図９は、配信サーバー２００の動作を示したフローチャートである。以下、図９を参照して動作説明をする。

配信サーバー２００では、端末１００からの要求（メニュー要求、着信メロディデータ要求、着信メロディメニュー選択要求、更新チェック要求）を待ち受けており（ステップＳ２０〜Ｓ２３）、受信した要求に応じた処理が行われる。

（１）メニュー要求受信：
端末１００には、一般利用者によって使用される端末Ａと、有名人利用者によって使用される端末Ｂとがある。メニュー要求には、端末Ａが配信サーバー２００に対して行う第１のメニュー要求と、端末Ｂが配信サーバー２００に対して行う第２のメニュー要求とがある。第１のメニュー要求は、一般利用者が、着信メロディメニューリスト（具体的には、図８のメニュー表に登録されている有名人のリストで、少なくとも１つの有名人の項目を選択指定することができる）を取得する際に、端末Ａ上で所定の入力操作を行うことで発行される。第２のメニュー要求は、有名人利用者が、着信メロディリスト（ダウンロード可能な着信メロディに関するリスト）を取得する際に、端末Ａ上で所定の入力操作を行うことで発行される。

配信サーバー２００は、まず、端末１００からメニュー要求（第１または第２のメニュー要求）を受信したかどうかを判断する（ステップＳ２０）。この判断で「Ｎｏ」となった場合は、後述の「（２）着信メロディデータ要求受信」の処理に移行する。「Ｙｅｓ」となった場合（第１または第２のメニュー要求を受信した場合）は、続いて、利用者識別機能を用いて、その受信したメニュー要求から利用者識別コードを取得する（ステップＳ２４）。このとき、メニュー要求が第１のメニュー要求である場合は、一般利用者の利用者識別コードが取得され、第２のメニュー要求である場合は、有名人利用者の利用者識別コードが取得される。

次に、配信サーバー２００は、図８に示したメニュー表の利用者コードの欄（ここには、有名人利用者に関する利用者コードが格納されている）に、ステップＳ２４で取得した利用者識別コードと合致するものがあるかどうかで、受信したメニュー要求が有名人利用者の端末Ｂからのものであるか否かを判断する（ステップＳ２５）。取得した利用者識別コードと合致するものが見つかった場合（「Ｙｅｓ」の場合）は、有名人利用者からの第２のメニュー要求であると判断し、図７に示した着信メロディ表の着信メロディコード・着信メロディ名からなる着信メロディリストを作成し、これを有名人利用者の端末Ｂへ送信する（ステップＳ２６）。他方、取得した利用者識別コードと合致するものが見つからない場合（「Ｎｏ」の場合）は、一般利用者からの第１のメニュー要求であると判断して、図８に示したメニュー表のメニューコードとメニュー名からなる着信メロディメニューリストを作成し、これを一般利用者の端末Ａへ送信する（ステップＳ２７）。ステップＳ２６またはステップＳ２７の処理を終えた後、「開始」に戻る。

（２）着信メロディデータ要求受信：
配信サーバー２００は、着信メロディデータ要求を受信したか否かを判断する（ステップＳ２１）。ステップＳ２６で送信された着信メロディリストを受信した端末Ｂ上で、有名人利用者が所定の入力操作、例えば着信メロディリスト中の所望の着信メロディ名を選択入力すると、該操作に応じて、端末Ｂが、その選択された着信メロディに関するデータ要求（着信メロディデータ要求）を配信サーバー２００へ送信する。この着信メロディデータ要求の送信により、配信サーバー２００では、ステップＳ２１の判断が「Ｙｅｓ」となって、以下の処理が実行される。なお、ステップＳ２１の判断が「Ｎｏ」となった場合は、後述する「（３）着信メロディメニュー選択要求受信」の処理に移行する。

配信サーバー２００は、まず、受信した着信メロディデータ要求に含まれている着信メロディコードで図７に示した着信メロディ表を検索し、対応する着信メロディデータを端末Ｂへ送信する（ステップＳ２８）。続いて、利用者識別機能により、受信した着信メロディデータ要求から利用者識別コードを取得する（ステップＳ２９）。そして、取得した利用者識別コードで図８に示したメニュー表を検索し、そのメニュー表内の、該当する利用者コードと対応づけて格納されている着信メロディコードを、ステップＳ２８で送信した着信メロディコードに更新する（ステップＳ３０）。この処理を終えた後、「開始」に戻る。

（３）着信メロディメニュー選択要求受信：
配信サーバー２００は、着信メロディメニュー選択要求を受信したか否かを判断する（ステップＳ２２）。ステップＳ２７で送信された着信メロディメニューリストを受信した端末Ａ上で、一般利用者が所定の入力操作、例えば着信メロディメニューリスト中の所望のメニュー名を選択入力すると、該操作に応じて、端末Ａが、その選択されたメニュー名に関するデータ要求（着信メロディメニュー選択要求）を配信サーバー２００へ送信する。この着信メロディメニュー選択要求の送信により、配信サーバー２００では、ステップＳ２２の判断が「Ｙｅｓ」となって、以下の処理が実行される。なお、ステップＳ２２の判断が「Ｎｏ」となった場合は、後述する「（４）更新チェック要求受信」の処理に移行する。

配信サーバー２００は、まず、利用者識別機能により、受信した着信メロディメニュー選択要求から利用者識別コードを取得する（ステップＳ３１）。そして、取得した利用者識別コードで図６に示した一般利用者表を検索し、該当する利用者コードの欄のメニューコードを着信メロディメニュー選択要求に含まれるメニューコードに更新する（ステップＳ３２）。この処理を終えた後、「開始」に戻る。

（４）更新チェック要求受信：
配信サーバー２００は、更新チェック要求を受信したか否かを判断する（ステップＳ２３）。一般利用者が使用する端末Ａでは、定期的に、または、特定のタイミングで、自端末内の記憶部に現在格納されている着信メロディの情報（例えば着信メロディコード）を含む更新チェック要求が配信サーバー２００へ送信される。この更新チェック要求の送信により、配信サーバー２００では、ステップＳ２３の判断が「Ｙｅｓ」となって、以下の処理が実行される。なお、この判断が「Ｎｏ」となった場合は、「開始」に戻る。

配信サーバー２００は、まず、利用者識別機能により、端末Ａから受信した更新チェック要求から利用者識別コードを取得する（ステップＳ３３）。続いて、取得した利用者識別コードで図６に示した一般利用者表を検索し、該当するメニューコードを取得し、さらに、その取得したメニューコードを用いて図８に示したメニュー表を検索し、該当するレコードの着信メロディコードを取得して、この取得した着信メロディコードと受信した更新チェック要求に含まれる着信メロディコードとを比較する（ステップＳ３４）。この比較が合致しない場合には、更新ありと判断し、メニュー表から取得した着信メロディコードで着信メロディ表を検索し、対応する着信メロディコードを端末Ａへ送信する（ステップＳ３５）。比較が合致する場合は、更新なしと判断して、更新が無い旨を端末Ａへ送信する（ステップＳ３６）。ステップＳ３５、Ｓ３６のいずれかの処理を終えた後、「開始」に戻る。

次に、有名人利用者が端末Ｂを使って着信メロディ更新を行う場合の動作について説明する。図１０は、有名人利用者が行う着信メロディ更新手順を示すフローチャートである。

有名人利用者が、端末Ｂ上で、ネットワークブラウザ機能を用いて配信サーバー２００にアクセスし、所定の入力操作（選択操作）を行うと、端末Ｂは、メニュー要求（第２のメニュー）を配信サーバー２００へ送信し（ステップＳ４０）、配信サーバー２００からの着信メロディリストの受信を待ち受ける（ステップＳ４１）。このメニュー要求を受信した配信サーバー２００は、上述した図９のステップＳ２４〜Ｓ２６の処理を行って、着信メロディリスト（着信メロディ名とその着信メロディコードを含む）を端末Ｂへ送信する。

配信サーバー２００から着信メロディメニューリストを受信すると、端末Ｂは、図１１に示すような着信メロディ名の一覧を含む着信メロディ選択画面を表示して、有名人利用者の選択を受け付ける（ステップＳ４２）。続いて、有名人利用者が着信メロディ選択画面上で所望の着信メロディ名を選択すると、端末Ｂは、その選択された着信メロディ名の着信メロディコードを含む着信メロディデータ要求を配信サーバー２００に送信し（ステップＳ４３）、配信サーバー２００からの着信メロディデータの受信を持ち受ける（ステップＳ４４）。この着信メロディデータ要求を受信配信サーバー２００は、上述した図９のステップＳ２１、Ｓ２８の処理を行って、着信メロディデータ要求に含まれている着信メロディコードに対応する着信メロディデータを端末Ｂへ送信する。端末Ｂは、配信サーバー２００からの着信メロディデータを受信すると、その受信した着信メロディデータを図２に示した記憶部２０１に格納する（ステップＳ４５）。

次に、一般利用者が端末Ａを使って着信メロディメニュー選択を行う場合の動作について説明する。図１２に、一般利用者が行う着信メロディメニュー選択手順を示す。

一般利用者が、端末Ａ上で、ネットワークブラウザ機能を用いて配信サーバー２００にアクセスし、所定の入力操作（選択操作）を行うと、端末Ａは、メニュー要求（第１のメニュー要求）を配信サーバー２００へ送信し（ステップＳ５０）、配信サーバー２００からの着信メロディメニューリストの受信を待ち受ける（ステップＳ５１）。メニュー要求を受信した配信サーバー２００は、上述した図９のステップＳ２４、Ｓ２５、Ｓ２７の処理を行って、着信メロディメニューリスト（メニュー名とそのメニューコード）を端末Ａへ送信する。

配信サーバー２００から着信メロディリストを受信すると、端末Ａは、図１３に示すような有名人の一覧を含む着信メロディメニュー選択画面を表示し、一般利用者の選択を受け付ける（ステップＳ５２）。一般利用者が着信メロディメニュー選択画面上で所望の有名人を選択すると、続いて、端末Ａは、その選択された有名人のメニューコードを含む着信メロディメニュー選択要求を配信サーバー２００へ送信する（ステップＳ５３）。この着信メロディメニュー選択要求を受信した配信サーバー２００は、上述した図９のステップＳ２２、Ｓ３１、Ｓ３２の処理を行う。

次に、端末Ａが備える更新チェック機能による、着信メロディの自動更新動作について説明する。図１４は、端末Ａにおける着信メロディの自動更新動作を説明するためのフローチャートである。

まず、端末Ａは、配信サーバー２００に対して、現在記憶部１０１に格納されている着信メロディの着信メロディコードを含む更新チェック要求を送信し（ステップＳ６０）、その返信を待ち受ける（ステップＳ６１）。更新チェック要求を受信した配信サーバー２００は、上述した図９のステップＳ３３〜Ｓ３６の処理を行って、着信メロディデータまたは更新無しの通知を端末Ａへ送信する。配信サーバー２００から着信メロディデータを受信した場合は、端末Ａは、その受信した着信メロディデータとこれに対応する着信メロディコードとを記憶部１０１に格納し（ステップＳ６２）、タイマー処理に進む（ステップＳ６３）。配信サーバー２００から更新無しの通知を受信した場合は、端末Ａは、何も処理を行わずにステップＳ６３のタイマー処理に進む。ここで、ステップＳ６３のタイマー処理とは、更新チェックを一定間隔で行うためのものである。このタイマー処理では、例えば１日、１２時間などの時間間隔や、２３時などの時刻に基づいて、次回更新チェック要求を送信するタイミングを決定する。

上述した本実施形態の着信メロディ更新システムによれば、一般利用者の端末Ａ内に格納される着信メロディのデータは、任意に選択した有名人利用者の端末Ｂにて使用されている着信メロディと合致するようになっている。よって、一般利用者は、有名人利用者が現在どのような着信メロディを使用しているかを知ることができる。加えて、例えば、所望の有名人が携帯端末上で使用している着信メロディと同じ着信メロディを自身の携帯端末に設定することができる。

また、有名人が端末Ｂ上で着信メロディを更新した場合には、定期的に、または、特定のタイミングで、その更新内容が一般利用者の端末Ａ内に格納されている着信メロディのデータに自動的に反映される。よって、一般利用者は、着信メロディの更新の際の煩わしい入力操作を行うことなく、自身の携帯端末において、有名人による着信メロディの更新に追従した着信メロディ更新を行うことができる。

さらに、ある程度メニューに沿った着信メロディの配信が可能であるため、配信サーバーの運用者（配信業者）は、何万曲も着信メロディを用意する必要がなく、データ量の削減が可能である。

以上、本発明の第１の実施形態について主要部の構成を説明したが、この他、以下のような構成または機能の付加・変更が可能である。

例えば、図６に示した一般利用者表に、一般利用者毎に、何回着信メロディの自動更新が行われたかの情報を記録し、この記録に基づき、一般利用者への従量課金を行うように構成することが可能である。さらに、この場合、着信メロディ自動更新時に、図７に示した着信メロディ表に、着信メロディが配信された利用者数を記録し、この記録に基づき著作権者への支払いを行うように構成することもできる。

さらに、定期的（月末など）に、図６に示した一般利用者表の着信メロディメニュー列に登録されているメニューコードの数に基づき、当該メニューコードに該当する有名人に報酬を支払うようなシステムを追加することもできる。

（実施形態２）
利用者の端末１００内に格納される着信メロディを、配信サーバー内のデータベースに格納されている楽曲ランキングの変化に応じて更新するようにすることができる。ここでは、本発明の第２の実施形態として、そのような楽曲ランキングの変化に応じた着信メロディの更新が可能な着信メロディ更新システムについて説明する。ここでは、利用者は、一般、有名人といった区分はなく、当該システムを利用して着信メロディの取得および更新を行う者を意味する。

本実施形態の着信メロディ更新システムは、図１〜８に示した構成および動作を備える端末１００および配信サーバー２００を備えるシステムであるが、一部の構成および動作が第１の実施形態のものと異なる。以下では、動作の異なる部分を中心に説明する。

図１５に、配信サーバー２００内の記憶部２０１に格納されるメニュー表の論理データ構造（データベース）を示す。このメニュー表は、楽曲ランキングに係る着信メロディメニューと、これら着信メロディメニューに該当する着信メロディコードとを格納するようになっている。着信メロディメニューとしては、例えば着信メロディがその時点の邦楽ＰＯＰＳなど特定ジャンルの売上ランキングでナンバー１の曲に更新されるメニューや、特定ジャンルの売上ランキングのうちランクが急上昇中の注目曲に更新されるメニューなど、楽曲のランキングに係る様々なメニューが提供される。メニュー表の着信メロディコードは、図７に示した着信メロディ表の着信メロディコードに対応しており、これら表の着信メロディコードが、定期的、または、特定のタイミングで最新のランキングデータを基に該当する曲に更新される。

ランキング情報提供業者など他の事業者と提携して当該事業者から提供されたデータに基づいてメニュー表の作成・更新を行ってもよい。また、配信サーバー２００の運用者が独力で売上データを分析して手動でメニュー表を作成・更新しても良い。他の事業者と提携してメニュー表の更新を行う場合は、例えば当該事業者のランキングデータベースとの間にインターネットを通じたデータ更新システムを構築することで、人の手を介さずメニュー表の自動更新を行うことが望ましい。図１６に、そのようなデータ更新システムを持つ場合のメニュー表の自動更新動作の一例を示す。

図１６を参照すると、配信サーバー２００は、外部ランキングデータベースに対して、メニュー表で提供されるメニュー毎に、定期的、または、特定のタイミングでランキングデータの問い合わせを行って最新のランキングデータを取得する（ステップＳ７１）。そして、その取得した最新のランキングデータで、メニュー表を更新する（ステップＳ７２）。

上記のメニュー表の更新では、配信サーバー２００は、例えば、取得した最新のランキングデータに関する着信メロディコードを自動的に付与することができる。配信サーバー２００の運用者は、最新のランキングデータに関する着信メロディデータを自身で作成または他の提携業者から入手し、その作成または入手した着信メロディデータと、その着信メロディ名および配信サーバー２００が付与した着信メロディコードと基づいて、着信メロディ表を更新する。こうして、ステップＳ７２でのメニュー表の更新に対応した、着信メロディ表の更新を行うことができる。

次に、本実施形態の着信メロディ配信システムにおける着信メロディの配信動作について具体的に説明する。

図１７は、配信サーバー２００の動作を説明するためのフローチャートである。配信サーバー２００では、端末１００からの要求（メニュー要求、着信メロディメニュー選択要求、更新チェック要求）を待ち受けており（ステップＳ８１〜Ｓ８３）、受信した要求に応じた処理が行われる。

（１）メニュー要求受信：
配信サーバー２００は、端末１００からメニュー要求（第１または第２のメニュー要求）を受信したかどうかを判断する（ステップＳ８１）。この判断で「Ｎｏ」となった場合は、後述の「（２）着信メロディメニュー選択要求受信」の処理に移行する。「Ｙｅｓ」となった場合は、図１５に示したメニュー表のメニューコードとメニュー名からなる着信メロディメニューリストを作成し、これを端末１００へ送信する（ステップＳ８２）。この処理を終えた後、「開始」に戻る。

（２）着信メロディデータ要求受信：
配信サーバー２００は、着信メロディメニュー選択要求を受信したか否かを判断する（ステップＳ８２）。この判断が「Ｎｏ」となった場合は、後述する「（３）更新チェック要求受信」の処理に移行する。「Ｙｅｓ」となった場合は、配信サーバー２００は、まず、利用者識別機能により、受信した着信メロディメニュー選択要求から利用者識別コードを取得する（ステップＳＳ８５）。そして、更新チェック処理を行う（ステップＳ８６）。この更新チェック処理では、取得した利用者識別コードで図６に示したような利用者表を検索し、該当する利用者コードの欄のメニューコードを着信メロディメニュー選択要求に含まれるメニューコードに更新する。この処理を終えた後、「開始」に戻る。

（３）更新チェック要求受信：
配信サーバー２００は、更新チェック要求を受信したか否かを判断する（ステップＳ８３）。利用者が使用する端末１００では、定期的に、または、特定のタイミングで、自端末内の記憶部に現在格納されている着信メロディの情報（例えば着信メロディコード）を含む更新チェック要求が配信サーバー２００へ送信される。この更新チェック要求の送信により、配信サーバー２００では、ステップＳ８３の判断が「Ｙｅｓ」となって、以下の処理が実行される。なお、この判断が「Ｎｏ」となった場合は、「開始」に戻る。

配信サーバー２００は、まず、利用者識別機能により、端末１００から受信した更新チェック要求から利用者識別コードを取得する（ステップＳ８７）。続いて、取得した利用者識別コードで図６に示した利用者表を検索し、該当するメニューコードを取得し、さらに、その取得したメニューコードを用いて図８に示したメニュー表を検索し、該当するレコードの着信メロディコードを取得して、この取得した着信メロディコードと受信した更新チェック要求に含まれる着信メロディコードとを比較する（ステップＳ８８）。この比較が合致しない場合には、更新ありと判断し、メニュー表から取得した着信メロディコードで着信メロディ表を検索し、対応する着信メロディコードを端末１００へ送信する（ステップＳ８９）。比較が合致する場合は、更新なしと判断して、更新が無い旨を端末１００へ送信する（ステップＳ９０）。ステップＳ８９、Ｓ９０のいずれかの処理を終えた後、「開始」に戻る。

次に、端末１００側の動作について説明する。端末１００では、利用者による着信メロディメニュー選択が行われる。この着信メロディメニュー選択の動作は、図１２に示した手順と同じ手順で行われるが、端末１００上に表示される着信メロディメニュー選択画面は、図１８に示すようなものが使用される。この着信メロディメニュー選択画面では、図１６に示したメニュー表のメニュー名の一覧が表示され、利用者は、その画面上で所望のメニュー名を選択することができる。

また、端末１００では、着信メロディの自動更新が行われる。この着信メロディの自動更新も、図１４に示した手順と同じ手順で行われる。

（実施形態３）
本発明の第３の実施形態である着信メロディ更新システムは、基本的には、図１に示したシステムにより構成されるが、端末１００として、自身の端末上で任意に作成した着信メロディデータを公開する公開者によって使用される公開者端末と、その公開されたデータを利用する同期者によって使用される同期者端末とを有する。本実施形態の着信メロディ更新システムの、端末１００および配信サーバー２００は、図１〜６に示したものと基本的には同じであるが、一部の構成および動作が第１の実施形態のものと異なる。以下では、動作の異なる部分を中心に説明する。

配信サーバー２００は、着信メロディメニューを提供する利用者（公開者）が、他のどの利用者（同期者）に着信メロディ公開を許可するかを管理するための公開許可者表（データベース）を有する。図１９に、その管理表の一例を示す。この管理表は、利用者コードと許可利用者コードとを対応づけて格納したもので、例えば、利用者コード「１０００１」の利用者（公開者）は、許可利用者コード「１０００２」の利用者（同期者）に許可する、といった情報が格納される。

また、配信サーバー２００は、図７に示した着信メロディ表に加えて、図２０に示すような着信メロディメニュー表を有する。この着信メロディメニュー表は、着信メロディメニューを提供する利用者（公開者）が、端末上で現在用いている着信メロディを管理するためのものである。

次に、本実施形態の着信メロディ配信システムにおける着信メロディの配信動作について具体的に説明する。

図２１は、配信サーバー２００の動作を説明するためのフローチャートである。配信サーバー２００では、端末１００からの要求（メニュー要求、着信メロディ公開許可者指定要求、着信メロディデータ要求、着信メロディメニュー選択要求、更新チェック要求）を待ち受けており（ステップＳ１１〜Ｓ９５）、受信した要求に応じた処理が行われる。

（１）メニュー要求受信：
端末１００から配信サーバー２００へ送信されるメニュー要求には、初回利用者による第１のメニュー要求、公開者による第２のメニュー要求、同期者による第３のメニュー要求の３つがある。

配信サーバー２００は、端末１００からメニュー要求（第１、第２、ないし第３のメニュー要求）を受信したかどうかを判断する（ステップＳ９１）。この判断で「Ｎｏ」となった場合は、後述の「（２）着信メロディメニュー選択要求受信」の処理に移行する。「Ｙｅｓ」となった場合は、利用者識別機能を用いて、その受信したメニュー要求から利用者識別コードを取得する（ステップＳ９６）。

次に、配信サーバー２００は、受信したメニュー要求が初回利用者によるもの（第１のメニュー要求）である否かを判断する（ステップＳ９７）。具体的には、利用者表（図６参照）とメニュー表（図２０参照）の利用者コード列の中に、ステップＳ９６で取得した利用者識別コードと合致するものがあるかどうかを調べ、いずれの表にも取得した利用者識別コードが見つからなかった場合に、初回利用者と判断する（ステップＳ９７の「Ｙｅｓ」）。初回利用者でない場合（ステップＳ９７の「Ｎｏ」）は、続いて、受信したメニュー要求が着信メロディ公開者によるもの（第２のメニュー要求）であるか否かを判断する（ステップＳ９８）。具体的には、取得した利用者識別コードと合致したものがメニュー表に見つかった場合に、着信メロディ公開者と判断する（ステップＳ９８の「Ｙｅｓ」）。取得した利用者識別コードと合致したものが利用者表に見つかった場合は、着信メロディ同期者と判断する（ステップＳ９８の「Ｎｏ」）。

ステップＳ９７で初回利用者と判断した場合は、配信サーバー２００は、その利用者が着信メロディを公開するか、他の公開している利用者に同期するかの選択を行うためのモード選択画面をその利用者の端末へ送信する（ステップＳ９９）。そして、利用者が、モード選択画面の選択肢として着信メロディ公開を選んだ場合（ステップＳ１００の「Ｙｅｓ」）には、着信メロディメニュー表（図２０参照）に新規メニューの項目を追加して当該利用者の利用者コードを保存し（ステップＳ１０１）、着信メロディ公開者メニューを当該利用者の端末へ送信する（ステップＳ１０２）。一方、モード選択画面の選択肢として同期を選んだ場合（ステップＳ１００の「Ｎｏ」）は、当該利用者の識別コードで着信メロディ公開許可リストの許可利用者列を検索し（ステップＳ１０３）、当該利用者に対して着信メロディを公開している公開者からなる着信メロディメニューリストを当該利用者の端末へ送信する（ステップＳ１０４）。

ステップＳ９８で着信メロディ公開者と判断した場合は、配信サーバー２００は、着信メロディ公開者メニュー画面を当該着信メロディ公開者の端末へ送信する（ステップＳ１０５）。そして、着信メロディ公開者が、公開者メニュー画面の選択肢として着信メロディ変更を選択した場合（ステップＳ１０６の「変更」）は、着信メロディ表（図７参照）の着信メロディコードと着信メロディ名からなる着信メロディリストを作成し、これを当該着信メロディ公開者の端末へ送信する（ステップＳ１０７）。一方、着信メロディ公開者が、公開者メニュー画面の選択肢として公開許可者指定を選択した場合（ステップＳ１０６の「指定」）は、公開許可者指定画面を当該着信メロディ公開者の端末へ送信する（ステップＳ１０８）。

ステップＳ９８で同期者と判断した場合、当該利用者識別コードで着信メロディ公開許可リストの許可利用者列を検索し、当該利用者に対して着信メロディを公開している公開者からなる着信メロディメニューリストを送信する（ステップＳ１０９）。ステップＳ１０２、Ｓ１０４、Ｓ１０７、Ｓ１０８、Ｓ１０９のいずれかの処理を終えた後、「開始」に戻る。

（２）着信メロディ公開許可者指定要求受信：
配信サーバー２００は、着信メロディ公開許可者指定要求を受信したか否かを判断する（ステップＳ９２）。この判断が「Ｎｏ」となった場合は、後述する「（３）着信メロディデータ要求受信」の処理に移行する。「Ｙｅｓ」となった場合は、配信サーバー２００は、公開許可者表（図１９参照）に当該利用者コードと指定された許可者の利用者コードを対応付けたレコードを追加する（ステップＳ１１０）。この処理を終えた後、「開始」に戻る。

（３）着信メロディデータ要求受信：
配信サーバー２００は、着信メロディデータ要求を受信したか否かを判断する（ステップＳ９３）。この判断が「Ｎｏ」となった場合は、後述する「（４）着信メロディメニュー要求受信」の処理に移行する。「Ｙｅｓ」となった場合は、配信サーバー２００は、着信メロディデータ要求に含まれる着信メロディコードで着信メロディ表（図７参照）を検索し、対応する着信メロディデータを要求元の端末へ送信する（ステップＳ１１１）。そして、利用者識別コードでメニュー表を検索し、メニュー表（図２０参照）内の、該当する利用者コードと対応づけて格納されている着信メロディコードを、ステップＳ１１１で送信した着信メロディコードに更新する（ステップＳ１１２）。この処理を終えた後、「開始」に戻る。

（４）着信メロディメニュー選択要求受信：
配信サーバー２００は、着信メロディメニュー要求を受信したか否かを判断する（ステップＳ９４）。この判断が「Ｎｏ」となった場合は、後述する「（５）更新チェック要求受信」の処理に移行する。「Ｙｅｓ」となった場合は、配信サーバー２００は、利用者表（図６参照）の該当するレコードのメニューコードを着信メロディメニュー選択要求に含まれるメニューコードに更新する（ステップＳ１１３）。この処理を終えた後、「開始」に戻る。

（５）更新チェック要求受信：
配信サーバー２００は、更新チェック要求を受信したか否かを判断する（ステップＳ８３）。利用者が使用する端末１００では、定期的に、または、特定のタイミングで、自端末内の記憶部に現在格納されている着信メロディの情報（例えば着信メロディコード）を含む更新チェック要求が配信サーバー２００へ送信される。この更新チェック要求の送信により、配信サーバー２００では、ステップＳ９５の判断が「Ｙｅｓ」となって、以下の処理が実行される。なお、この判断が「Ｎｏ」となった場合は、「開始」に戻る。

配信サーバー２００は、まず、利用者識別機能により、端末１００から受信した更新チェック要求から利用者識別コードを取得し、取得した利用者識別コードで利用者表（図６参照）を検索し、該当するメニューコードを取得し、さらに、その取得したメニューコードを用いてメニュー表（図２０参照）を検索し、該当するレコードの着信メロディコードを取得して、この取得した着信メロディコードと受信した更新チェック要求に含まれる着信メロディコードとを比較する（ステップＳ１１４）。この比較が合致しない場合には、更新ありと判断し、メニュー表から取得した着信メロディコードで着信メロディ表を検索し、対応する着信メロディコードを端末１００へ送信する（ステップＳ１１５）。比較が合致する場合は、更新なしと判断して、更新が無い旨を端末１００へ送信する（ステップＳ１１６）。ステップＳ１１５、Ｓ１１６のいずれかの処理を終えた後、「開始」に戻る。

端末１００側の動作は、第１の実施形態の場合と同様であるが、表示されるメニューが異なる。図２２に、モード選択画面の一例を示す。このモード選択画面は、選択肢として「着信メロディを公開する」および「着信メロディを同期させる」の２つの項目が表示されるようになっている。図２１のステップＳ９９では、配信サーバー２０からこの図２２に示したモード選択画面が送信されて端末１００上に表示される。利用者は、このモード選択画面上でいずれかの項目を選択入力する。

図２３に、着信メロディ公開者メニュー画面の一例を示す。この着信メロディ公開者メニュー画面は、選択肢として、「着信メロディを更新する」および「公開を許可する利用者を指定する」の２つの項目が表示されるようになっている。図２１のステップＳ１０５では、配信サーバー２０からこの図２３に示した着信メロディ公開者メニュー画面が送信されて端末１００上に表示される。利用者は、この着信メロディ公開者メニュー画面上でいずれかの項目を選択入力する。

図２４に、許可利用者指定画面の一例を示す。許可利用者指定画面は、中央に許可利用者のコードを入力するための欄が表示されるようになっている。図２１のステップＳ１０８では、配信サーバー２０からこの図２４に示した許可利用者指定画面が送信されて端末１００上に表示される。利用者は、この許可利用者指定画面上でいずれかの項目を選択入力する。

図２５に、着信メロディメニュー選択画面の一例を示す。着信メロディメニュー選択画面は、メニュー選択肢として、公開者の利用者コードのリストが表示されるようになっている。図２１のステップＳ９４で配信サーバー２００が着信メロディメニュー選択を受信するにあたり、配信サーバー２００は、図２５に示したような着信メロディメニュー選択画面を端末１００へ送信する。端末１００では、受信した着信メロディメニュー選択画面が表示され、その画面上で、利用者がリスト中の所望の利用者コードを選択入力する。

以上説明した各実施形態において、携帯端末１００および配信サーバー２００の動作は、基本的には、プログラム制御により実現される。具体的には、図２および図５に示した処理部において、演算処理装置が、キャッシュメモリやＲＡＭ等の一時記憶装置あるいはディスク装置などの外部記憶装置に格納されたプログラムにしたがって動作することで前述した着信メロディ更新動作が実現される。

また、各実施形態の構成および動作は本発明の一例であって、発明の趣旨を逸脱しない範囲で適宜変更することができる。

例えば、着信メロディは、他の再生用データ、例えば待ち受け画像データと置き換えることもできる。この場合も、基本的な構成および動作は同じである。

また、着信メロディの自動更新と同時に、更新に関連する情報（曲名など）も同時に更新されるようにして、利用者が、自端末上で任意に表示させるようにしてもよい。

さらに、夜間に着信メロディを更新し、目覚まし時計として用いるような構成としてもよい。これにより、その日のランキングなどが分かる。

また、利用者の端末の着信メロディの更新は、各実施形態で述べたように、端末が、定期的または特定のタイミングで配信サーバーにデータベースの更新を問い合わせることにより行うようにする他、配信サーバーが、データベースが更新されると、該更新内容を端末に送信して更新を行わせるようにしてもよい。さらに、配信サーバーが、データベースが更新されると、該更新データを取得するためのアクセス情報（ＵＲＬなど）を含む更新通知を携帯端末に送信し、端末が、その更新通知に含まれているアクセス情報に基づいて更新データを取得して更新を行うようにしてもよい。

配信サーバーは、必ずしも物理的に一体のサーバーでなくてもよく、複数のサーバがＬＡＮ（ＬｏｃａｌＡｒｅａ Ｎｅｔｗｏｒｋ）やインターネット等のネットワーク経由で接続されることで併せて同一の機能を実現しても良い。例えば、データの管理を専門に行うデータベースサーバーを別に設けても良い。また、着信メロディ表の着信メロディデータが本実施形態の運営者とは別の運営者の運営するサーバーに存在しても良い。この場合、着信メロディ表には着信メロディデータそのものの代わりに、ＵＲＬなどで表される着信メロディデータのネットワークアドレスが格納されることにより、利用者の求めに応じて適宜インターネットなどを通じて配信サーバーにデータをダウンロードすることができる。

以上説明した本発明の構成は、携帯電話の他に、小型情報端末やカーナビゲーションシステムなどにも適用可能である。

本発明の一実施形態である着信メロディ更新システムの概略構成を示すブロック図である。 図１に示す着信メロディ更新システムを構成する端末の主要部を示すブロック図である。 図２に示す端末の記憶部に格納されるデータの構成例を示す図である。 図１に示す着信メロディ更新システムを構成する端末における着信メロディの再生手順を説明するためのフローチャートである。 図１に示す着信メロディ更新システムを構成する配信サーバーの主要部を示すブロック図である。 図５に示す配信サーバーの記憶部に格納される利用者表の論理データ構造を示す図である。 図５に示す配信サーバーの記憶部に格納される着信メロディ表の論理データ構造を示す図である。 図５に示す配信サーバーの記憶部に格納されるメニュー表の論理データ構造を示す図である。 図１に示す着信メロディ更新システムを構成する配信サーバーの動作を説明するためのフローチャートである。 有名人利用者が行う着信メロディ更新手順の一例を示すフローチャートである。 着信メロディ選択画面の一例を示す図である。 一般利用者が行う着信メロディメニュー選択手順の一例を示すフローチャートである。 着信メロディメニュー選択画面の一例を示す図である。 図１に示す着信メロディ更新システムを構成する端末の持つ更新チェック機能の動作を説明するためのフローチャートである。 本発明の第２の実施形態である着信メロディ更新システムの配信サーバーにおいて用いられるメニュー表の論理データ構造を示す図である。 本発明の第２の実施形態である着信メロディ更新システムに具備されるデータ更新システムにより行われるメニュー表の自動更新動作を説明するためのフローチャートである。 本発明の第２の実施形態である着信メロディ更新システムの配信サーバーの動作を説明するためのフローチャートである。 着信メロディメニュー選択画面の一例を示す図である。 管理表の一例を示す図である。 着信メロディメニュー表の一例を示す図である。 本発明の第３の実施形態である着信メロディ更新システムの配信サーバーの動作を説明するためのフローチャートである。 モード選択画面の一例を示す図である。 着信メロディ公開者メニュー画面の一例を示す図である。 許可利用者指定画面の一例を示す図である。 着信メロディメニュー選択画面の一例を示す図である。

符号の説明

１００ 端末
１０１、 ２０１ 記憶部
１０１ａ ソフトウェア
１０１ｂ 利用者識別コード
１０１ｃ 着信メロディ識別コード
１０１ｄ 着信メロディデータ
１０２、２０２ 処理部
１０３、２０３ 通信部
１０４ 入力部
１０５ 出力部
２００ 配信サーバー
３００ ネットワーク

Claims (44)

1. 携帯端末と、
   前記携帯端末により再生される再生用データを管理するデータベースを備えた配信サーバーと、を有し、
   前記携帯端末は、前記配信サーバーから取得した再生用データを格納するための記憶部を備え、該記憶部の内容が、特定の条件で行われる前記データベースの更新に同期して更新される再生用データ更新システム。
2. 携帯端末は、定期的または特定のタイミングで配信サーバーにデータベースの更新を問い合わせることにより記憶部の更新を行う、請求項１に記載の再生用データ更新システム。
3. 配信サーバーは、データベースが更新されると、該更新内容を携帯端末に送信して記憶部の更新を行わせる、請求項１に記載の再生用データ更新システム。
4. 配信サーバーは、データベースが更新されると、該更新データを取得するためのアクセス情報を含む更新通知を携帯端末に送信し、
   前記携帯端末は、前記配信サーバーから前記更新通知を受信すると、該受信した更新通知に含まれている前記アクセス情報に基づいて前記更新データを取得して記憶部の更新を行う、請求項１に記載の再生用データ更新システム。
5. 配信サーバーから取得した再生用データを格納するための記憶部を備えた別の携帯端末をさらに有し、
   特定の条件で行われるデータベースの更新が、前記別の携帯端末の記憶部に格納されている再生用データの更新である、請求項１から４のいずれか１項に記載の再生用データ更新システム。
6. 別の携帯端末は一つまたはそれ以上あり、
   配信サーバーは、それぞれの別の携帯端末の利用者の公開名を含むメニュー画面を携帯端末へ送信し、該送信したメニュー画面上で選択された公開名の利用者によって使用されている別の携帯端末の記憶部の更新と前記携帯端末の記憶部の更新とを同期させる、請求項５に記載の再生用データ更新システム。
7. 別の携帯端末は一つまたはそれ以上あり、データベースは、前記別の携帯端末のそれぞれの利用者の識別コードとその利用者によって使用されている再生用データの情報とが対応つけて格納されており、
   配信サーバーが、携帯端末によって指定された前記識別コードで前記データベース内を検索し、該当する利用者の再生用データの更新と前記携帯端末の記憶部の更新とを同期させる、請求項５に記載の再生用データ更新システム。
8. 携帯端末は複数あり、データベースは、前記携帯端末のうち、別の携帯端末の利用者によって許可された端末の利用者の識別コードを含み、
   配信サーバーが、前記別の携帯端末の記憶部の変更と前記サーバーに格納されている識別コードから特定される利用者によって使用されている携帯端末の記憶部の更新とを同期させる、請求項５に記載の再生用データ更新システム。
9. 再生用データがランク付けの可能なデータであり、特定の条件で行われるデータベースの更新が前記ランク付けの変更である、請求項１から４のいずれか１項に記載の再生用データ更新システム。
10. 配信サーバーは、再生用データに関する複数のジャンル項目を含むメニュー画面を携帯端末へ送信し、該送信したメニュー画面上で選択されたジャンルのランク付けの変更に同期して前記携帯端末の記憶部を更新する、請求項５に記載の再生用データ更新システム。
11. 再生用データが着信メロディデータである、請求項１から１０のいずれか１項に記載の再生用データ更新システム。
12. 再生用データが画像データである、請求項１から１０のいずれか１項に記載の再生用データ更新システム。
13. 携帯端末と、該携帯端末により再生される再生用データを管理するデータベースを備えた配信サーバーと、を有するシステムにおいて行われる再生用データ更新方法であって、
    前記携帯端末が、自端末内の記憶部に前記配信サーバーから取得した再生用データを格納するステップと、
    前記配信サーバーが、特定の条件で行われる前記データベースの更新に同期して前記記憶部の内容を更新させるステップと、を含む再生用データ更新方法。
14. 携帯端末が、定期的または特定のタイミングで配信サーバーにデータベースの更新を問い合わせることにより記憶部の更新を行うステップを含む、請求項１３に記載の再生用データ更新方法。
15. 配信サーバーが、データベースが更新されると、該更新内容を携帯端末に送信して記憶部の更新を行わせるステップを含む、請求項１３に記載の再生用データ更新方法。
16. 配信サーバーが、データベースが更新されると、該更新データを取得するためのアクセス情報を含む更新通知を携帯端末に送信し、
    前記携帯端末が、前記配信サーバーから前記更新通知を受信すると、該受信した更新通知に含まれている前記アクセス情報に基づいて前記更新データを取得して記憶部の更新を行うステップとを含む、請求項１３に記載の再生用データ更新方法。
17. 配信サーバーと接続される別の携帯端末が、前記配信サーバーから再生用データを取得して自端末内の記憶部に格納するステップと、
    前記配信サーバーが、前記別の携帯端末の記憶部の更新と携帯端末の記憶部の更新とを同期させるステップと、を含む請求項１３から１６のいずれか１項に記載の再生用データ更新方法。
18. 別の携帯端末は一つまたはそれ以上あり、配信サーバーが、それぞれの別の携帯端末の利用者の公開名を含むメニュー画面を第１の携帯端末へ送信し、該送信したメニュー画面上で選択された公開名の利用者によって使用されている別の携帯端末の記憶部の更新と前記携帯端末の記憶部の更新とを同期させるステップを含む、請求項１７に記載の再生用データ更新方法。
19. 別の携帯端末は一つまたはそれ以上あり、データベースは、前記別の携帯端末のそれぞれの利用者の識別コードとその利用者によって使用されている再生用データの情報とが対応つけて格納されており、
    配信サーバーが、携帯端末によって指定された前記識別コードで前記データベース内を検索し、該当する利用者の再生用データの更新と前記携帯端末の記憶部の更新とを同期させるステップを含む、請求項１７に記載の再生用データ更新方法。
20. 携帯端末は複数あり、データベースは、前記携帯端末のうち、別の携帯端末の利用者によって許可された端末の利用者の識別コードを含み、
    配信サーバーが、前記別の携帯端末の記憶部の変更と前記サーバーに格納されている識別コードから特定される利用者によって使用されている携帯端末の記憶部の更新とを同期させるステップを含む、請求項１７に記載の再生用データ更新方法。
21. 再生用データがランク付けの可能なデータであり、特定の条件で行われるデータベースの更新が前記ランク付けの変更である、請求項１３から１６のいずれか１項に記載の再生用データ更新方法。
22. 配信サーバーが、再生用データに関する複数のジャンル項目を含むメニュー画面を携帯端末へ送信し、該送信したメニュー画面上で選択されたジャンルのランク付けの変更に同期して前記携帯端末の記憶部を更新するステップを含む、請求項２２に記載の再生用データ更新方法。
23. 再生用データが着信メロディデータである、請求項１３から２２のいずれか１項に記載の再生用データ更新方法。
24. 再生用データが画像データである、請求項１３から２２のいずれか１項に記載の再生用データ更新方法。
25. 携帯端末により再生される再生用データを管理するデータベースと、
    特定の条件で行われる前記データベースの更新と前記携帯端末に格納されている再生用データの更新とを同期させる処理部と、を有することを特徴とする配信サーバー。
26. 処理部は、データベースが更新されると、該更新内容を携帯端末に送信する、請求項２５に記載の配信サーバー。
27. 処理部は、データベースが更新されると、該更新データを取得するためのアクセス情報を含む更新通知を携帯端末に送信する、請求項２５に記載の配信サーバー。
28. 特定の条件で行われるデータベースの更新が、再生用データを格納する別の携帯端末における前記再生用データの更新である、請求項２５から２７のいずれか１項に記載の配信サーバー。
29. 別の携帯端末は一つまたはそれ以上あり、処理部は、それぞれの別の携帯端末の利用者の公開名を含むメニュー画面を携帯端末へ送信し、該送信したメニュー画面上で選択された公開名の利用者の端末で使用されている再生データの更新と前記携帯端末における再生データの更新とを同期させる、請求項２８に記載の配信サーバー。
30. 別の携帯端末は一つまたはそれ以上あり、データベースは、それぞれの別の携帯端末の利用者の識別コードとその利用者によって使用されている再生用データの情報とが対応つけて格納されており、
    処理部は、携帯端末によって指定された前記識別コードで前記データベース内を検索し、該当する利用者の再生用データの更新と前記携帯端末における再生データの更新とを同期させる、請求項２８に記載の配信サーバー。
31. 携帯端末は複数あり、データベースは、前記携帯端末のうち、別の携帯端末の利用者によって許可された端末の利用者の識別コードを含み、
    処理部が、前記別の携帯端末における再生用データの変更と前記サーバーに格納されている識別コードから特定される利用者によって使用されている携帯端末における再生用データの更新とを同期させる、請求項２８に記載の配信サーバー。
32. 再生用データがランク付けの可能なデータであり、特定の条件で行われるデータベースの更新が前記ランク付けの変更である、請求項２５から２７のいずれか１項に記載の配信サーバー。
33. 処理部が、再生用データに関する複数のジャンル項目を含むメニュー画面を携帯端末へ送信し、該送信したメニュー画面上で選択されたジャンルのランク付けの変更に同期して前記携帯端末の記憶部を更新する、請求項３２に記載の配信サーバー。
34. 再生用データが着信メロディデータである、請求項２５から３３のいずれか１項に記載の配信サーバー。
35. 再生用データが画像データである、請求項２５から３３のいずれか１項に記載の配信サーバー。
36. 記憶部と、
    再生用データを管理するデータベースを備えた配信サーバーから取得した前記再生用データを前記記憶部に格納する処理部と、を有し、
    前記記憶部に格納されている再生用データの更新が、特定の条件で行われる前記データベースの更新に同期して行われることを特徴とする携帯端末。
37. 処理部は、定期的または特定のタイミングで配信サーバーにデータベースの更新を問い合わせることにより記憶部の更新を行う、請求項３６に記載の携帯端末。
38. 処理部は、データベースが更新された際に、該更新データを取得するためのアクセス情報を含む更新通知を配信サーバーから受信するとともに、該受信した更新通知に含まれている前記アクセス情報に基づいて前記更新データを取得して記憶部の更新を行う、請求項３６に記載の携帯端末。
39. 記憶部の更新が、配信サーバーから取得した再生用データを格納する別の携帯端末における前記再生用データの更新と同期している、請求項３６から３８のいずれか１項に記載の携帯端末。
40. 再生用データがランク付けの可能なデータであり、特定の条件で行われるデータベースの更新が前記ランク付けの変更である、請求項３６から３８のいずれか１項に記載の携帯端末。
41. 再生用データが着信メロディデータである、請求項３６から４０のいずれか１項に記載の携帯端末。
42. 再生用データが画像データである、請求項３６から４０のいずれか１項に記載の携帯端末。
43. 配信サーバーのコンピュータに、
    携帯端末により再生される再生用データをデータベースで管理する処理と、
    特定の条件で行われる前記データベースの更新と前記携帯端末に格納されている再生用データの更新とを同期させる処理と、を実行させるプログラム。
44. 携帯端末のコンピュータに、
    再生用データを管理するデータベースを備えた配信サーバーから取得した前記再生用データを記憶部に格納する処理部と、
    前記記憶部に格納されている再生用データを、特定の条件で行われる前記データベースの更新に同期して更新する処理と、を実行させるプログラム。

Images