(57)【要約】【課題】  クライアント端末での高負荷処理が不要な楽曲データ配信システムを提供する。【解決手段】  楽曲データ配信サーバは、楽曲データ配信要求を連続して受信し、該要求に応じて楽曲データを小片に分割して生成した小片音声データを着信メロディファイルに埋め込んで送信する。調を特定するための情報が変更された場合には、変更前の調に対応するトラックの配信区間と、新たな配信区間とを合成した小片音声データを着信メロディファイルに埋め込んで送信する。楽曲データ受信端末は、前記楽曲データ配信要求を送信して、前記着信メロディファイルを順次受信するとともに、再度配信要求を送信する。受信した着信メロディファイルは、受信した順番で連続して再生される。また、調の変更を前記楽曲データ配信サーバに要求する。【選択図】  図２
2007256784.tif 000002
【特許請求の範囲】
【請求項１】
１つの楽曲について調の異なる複数のトラックを有する楽曲データを記憶する記憶手段と、
楽曲データの調及び配信区間を特定するための情報を含む楽曲データ配信要求を通信ネットワークを介して連続して受信する受信手段と、
前記楽曲データ配信要求に基づき、前記記憶手段に記憶されている楽曲データの前記調に対応するトラックの前記配信区間を送信区間として設定する設定手段と、
前記楽曲データを前記設定された送信区間に対応する小片に分割して生成した小片音声データを着信メロディファイルに埋め込んで送信する送信手段であって、前記楽曲データ配信要求に含まれる調を特定するための情報が変更された場合に、変更前の調に対応するトラックの前記配信区間と、新たな配信区間とを合成した小片音声データを着信メロディファイルに埋め込んで送信する送信手段と
を有する楽曲データ配信装置。
【請求項２】
楽曲データの調及び配信区間を特定するための情報を含む楽曲データ配信要求を通信ネットワークを介して楽曲データ配信サーバに送信する第１の送信手段と、
楽曲データを小片に分割した小片音声データが埋め込まれた着信メロディファイルを前記楽曲データ配信サーバから順次受信する受信手段と、
前記着信メロディファイルを受信したら、前記配信区間を次の配信区間に変更して、再度楽曲データ配信要求を通信ネットワークを介して前記楽曲データ配信サーバに送信する第２の送信手段と、
前記受信した着信メロディファイルを、受信した順番で連続して再生する再生手段と、
前記楽曲データ配信要求に含まれる前記楽曲データの調を特定するための情報を変更することにより、前記楽曲データ配信サーバに前記楽曲データの調の変更を要求する要求手段と
を有する楽曲データ受信装置。
【請求項３】
１つの楽曲について調の異なる複数のトラックを有する楽曲データを記憶する記憶手段と、楽曲データの調及び配信区間を特定するための情報を含む楽曲データ配信要求を通信ネットワークを介して連続して受信する受信手段と、前記楽曲データ配信要求に基づき、前記記憶手段に記憶されている楽曲データの前記調に対応するトラックの前記配信区間を送信区間として設定する設定手段と、前記楽曲データを前記設定された送信区間に対応する小片に分割して生成した小片音声データを着信メロディファイルに埋め込んで送信する送信手段であって、前記楽曲データ配信要求に含まれる調を特定するための情報が変更された場合に、変更前の調に対応するトラックの前記配信区間と、新たな配信区間とを合成した小片音声データを着信メロディファイルに埋め込んで送信する送信手段とを有する楽曲データ配信サーバと、
前記楽曲データ配信要求を前記楽曲データ配信サーバに送信する第１の送信手段と、前記着信メロディファイルを前記楽曲データ配信サーバから順次受信する受信手段と、前記着信メロディファイルを受信したら、前記配信区間を次の配信区間に変更して、再度楽曲データ配信要求を前記楽曲データ配信サーバに送信する第２の送信手段と、前記受信した着信メロディファイルを、受信した順番で連続して再生する再生手段と、前記楽曲データ配信要求に含まれる前記楽曲データの調を特定するための情報を変更することにより、前記楽曲データ配信サーバに前記楽曲データの調の変更を要求する要求手段とを有する楽曲データ受信端末と
を通信ネットワークを介して接続することで構成される楽曲データ配信システム。
【請求項４】
１つの楽曲について調の異なる複数のトラックを有する楽曲データを記憶する記憶手段を有するコンピュータで実行可能な楽曲データ配信プログラムであって、
楽曲データの調及び配信区間を特定するための情報を含む楽曲データ配信要求を通信ネットワークを介して連続して受信する受信手順と、
前記楽曲データ配信要求に基づき、前記記憶手段に記憶されている楽曲データの前記調に対応するトラックの前記配信区間を送信区間として設定する設定手順と、
前記楽曲データを前記設定された送信区間に対応する小片に分割して生成した小片音声データを着信メロディファイルに埋め込んで送信する送信手順であって、前記楽曲データ配信要求に含まれる調を特定するための情報が変更された場合に、変更前の調に対応するトラックの前記配信区間と、新たな配信区間とを合成した小片音声データを着信メロディファイルに埋め込んで送信する送信手順と
を有する楽曲データ配信プログラム。
【請求項５】
楽曲データの調及び配信区間を特定するための情報を含む楽曲データ配信要求を通信ネットワークを介して楽曲データ配信サーバに送信する第１の送信手順と、
楽曲データを小片に分割した小片音声データが埋め込まれた着信メロディファイルを前記楽曲データ配信サーバから順次受信する受信手順と、
前記着信メロディファイルを受信したら、前記配信区間を次の配信区間に変更して、再度楽曲データ配信要求を通信ネットワークを介して前記楽曲データ配信サーバに送信する第２の送信手順と、
前記受信した着信メロディファイルを、受信した順番で連続して再生する再生手順と、
前記楽曲データ配信要求に含まれる前記楽曲データの調を特定するための情報を変更することにより、前記楽曲データ配信サーバに前記楽曲データの調の変更を要求する要求手順と
を有する楽曲データ受信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、楽曲データ配信装置及び楽曲データ受信端末に関に関する。
【背景技術】
【０００２】
近年、インターネット等の通信ネットワークを介して、配信サーバから楽曲データをダウンロードすることが広く行われている。配信する楽曲データが、音声データである場合に当該楽曲を移調するためには、クライアント端末の処理能力では間に合わない場合がある。
【０００３】
そこで、配信サーバと受信端末からなる楽曲データ配信システムにおいて、配信する１つの楽曲データに対して、サーバ側で複数の調性に対応した複数のトラックを用意し、クライアント端末からの移調指示に対応して、トラックを切り替えて、該トラックの楽曲データをストリーミングで配信することが知られている（例えば特許文献１参照）。
【０００４】
【特許文献１】特開２００５-２８４０４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
上述の従来技術による楽曲データ配信システムでは、クライアント端末側での周波数変換処理を省略できるという利点があるが、例えば、携帯電話端末などの一度の送受信データ量に制限のある端末をクライアント端末として用いる場合には、楽曲長や品質によっては配信できないことがある。
【０００６】
また、ストリーミングによる楽曲データの送受信は、配信サーバ及びクライアント端末の双方で比較的負荷の高い処理を実行する必要があり、そのような処理に対応させるためにはクライアント端末のコストの上昇を招く恐れがある。
【０００７】
本発明の目的は、クライアント端末での高負荷処理が不要な楽曲データ配信システムを提供することである。
【０００８】
本発明の他の目的は、クライアント端末で高負荷処理を実行せずに楽曲データの移調を行える楽曲データ配信システムを提供することである。
【課題を解決するための手段】
【０００９】
本発明の一観点によれば、楽曲データ配信装置は、１つの楽曲について調の異なる複数のトラックを有する楽曲データを記憶する記憶手段と、楽曲データの調及び配信区間を特定するための情報を含む楽曲データ配信要求を通信ネットワークを介して連続して受信する受信手段と、前記楽曲データ配信要求に基づき、前記記憶手段に記憶されている楽曲データの前記調に対応するトラックの前記配信区間を送信区間として設定する設定手段と、前記楽曲データを前記設定された送信区間に対応する小片に分割して生成した小片音声データを着信メロディファイルに埋め込んで送信する送信手段であって、前記楽曲データ配信要求に含まれる調を特定するための情報が変更された場合に、変更前の調に対応するトラックの前記配信区間と、新たな配信区間とを合成した小片音声データを着信メロディファイルに埋め込んで送信する送信手段とを有する。
【００１０】
また、本発明の他の観点によれば、楽曲データ受信装置は、楽曲データの調及び配信区間を特定するための情報を含む楽曲データ配信要求を通信ネットワークを介して楽曲データ配信サーバに送信する第１の送信手段と、楽曲データを小片に分割した小片音声データが埋め込まれた着信メロディファイルを前記楽曲データ配信サーバから順次受信する受信手段と、前記着信メロディファイルを受信したら、前記配信区間を次の配信区間に変更して、再度楽曲データ配信要求を通信ネットワークを介して前記楽曲データ配信サーバに送信する第２の送信手段と、前記受信した着信メロディファイルを、受信した順番で連続して再生する再生手段と、前記楽曲データ配信要求に含まれる前記楽曲データの調を特定するための情報を変更することにより、前記楽曲データ配信サーバに前記楽曲データの調の変更を要求する要求手段とを有する。
【発明の効果】
【００１１】
本発明によれば、クライアント端末での高負荷処理が不要な楽曲データ配信システムを提供することができる。
【００１２】
また、本発明によれば、クライアント端末で高負荷処理を実行せずに楽曲データの移調を行える楽曲データ配信システムを提供することができる。
【発明を実施するための最良の形態】
【００１３】
図１は、本発明の実施例による携帯電話端末1のハードウェア構成を表すブロック図である。
【００１４】
携帯電話端末１のバス６には、ＲＡＭ７、ＲＯＭ８、ＣＰＵ９、外部記憶装置１５、検出回路１１、表示回路１３、音源回路１８、効果回路１９、通信インターフェイス（Ｉ／Ｆ）２１が接続される。
【００１５】
ＲＡＭ７は、各種バッファ領域、フラグ、レジスタ、各種パラメータ等を記憶するＣＰＵ９のワーキングエリアを有する。
【００１６】
ＲＯＭ８には、各種パラメータ及び制御プログラム、又は本実施例を実現するためのプログラム等を記憶することができる。この場合、プログラム等を重ねて、外部記憶装置１５に記憶する必要は無い。
【００１７】
ＣＰＵ９は、ＲＯＭ８又は、外部記憶装置１５に記憶されている制御プログラム等に従い、演算又は制御を行う。タイマ１０は、ＣＰＵ９に接続されており、基本クロック信号、割り込み処理タイミング等をＣＰＵ９に供給する。
【００１８】
ユーザは、検出回路１１に接続される入力操作子１２を用いて、各種入力及び設定、選択をすることができる。入力操作子１２は、例えば、数字キー、文字入力用キーボード、スイッチ等、ユーザの入力に応じた信号を出力できるものならどのようなものでもよい。また、入力操作子１２は、マウス等の他の操作子を用いて操作するディスプレイ１４上に表示されるソフトスイッチ等でもよい。
【００１９】
表示回路１３は、ディスプレイ１４に接続され、各種情報をディスプレイ１４に表示することができる。ユーザは、このディスプレイ１４に表示される情報を参照して、各種入力及び設定を行う。また、ディスプレイ１４は、外部の表示装置を接続することにより構成してもよい。
【００２０】
外部記憶装置１５は、外部記憶装置用のインターフェイスを含み、そのインターフェイスを介してバス６に接続される。外部記憶装置１５は、例えば、半導体メモリ等である。
【００２１】
音源回路１８は、外部記憶装置１５、ＲＯＭ８又はＲＡＭ７等に記録された伴奏パターンデータ、演奏データ若しくはＭＩＤＩインターフェイス１６に接続されたＭＩＤＩ機器１７等から供給される演奏信号、ＭＩＤＩ信号等に応じて楽音信号を生成し、効果回路１９を介して、サウンドシステム２０に供給する。
【００２２】
効果回路１９は、音源回路１８から供給される楽音信号に対して、各種音楽的効果を付与する。サウンドシステム２０は、Ｄ／Ａ変換器及びスピーカーを含み、供給されるデジタル形式の楽音信号をアナログ形式に変換し、発音する。
【００２３】
通信インターフェイス２１は、携帯電話回線及びインターネット等の通信ネットワーク３に接続可能であり、通信回路とアンテナで構成される。通信ネットワーク３を介して、サーバ２及び他の携帯電話端末１と相互に接続可能である。
【００２４】
なお、通信インターフェイス２１及び通信ネットワーク３は、無線の携帯電話網に接続するための物に加えて、有線の例えば、ＵＳＢインターフェイスを備えていても良い。
【００２５】
サーバ２は、一般的なコンピュータで構成され、ＲＡＭ７、ＲＯＭ８、ＣＰＵ９、外部記憶装置１５、検出回路１１、表示回路１３、音源回路１８、効果回路１９、通信インターフェイス（Ｉ／Ｆ）２１等を含んで構成される。
【００２６】
図２は、本発明の実施例による楽曲データ配信システム１００の構成を表すブロック図である。図３は、配信サーバ２と携帯電話端末との間で送信される要求情報ＲＩとデータの流れを表すタイムチャートである。以下に、図２に示す楽曲データ配信システム１００の機能を、図３に示すタイムチャートを適宜参照して説明する。
【００２７】
楽曲データ配信システム１００は、ユーザ端末（携帯電話端末）１と配信サーバ（楽曲データ配信装置）２とを通信ネットワーク３で相互接続することで構成される。配信サーバ２は、一般的なコンピュータであり、通信ネットワーク３は、例えば、インターネットである。携帯電話端末１と配信サーバ３は、図示しない携帯電話の通信網及び所定のゲートウェイを介して通信ネットワーク３に接続される。
【００２８】
携帯電話端末１は、配信サーバ２とのデータのやり取りを行うためのアプリケーションプログラムを備え、該アプリケーションを用いて、配信サーバ２に対して各種リクエスト（要求情報ＲＩの送信）を行う。
【００２９】
配信サーバ２は、例えば、楽曲データ記憶部１５０、ファイル読出制御部９０、合成部９１及び送信制御部２１０を含んで構成される。楽曲データ記憶部１５０に記憶されている楽曲データは、例えば、ＡＤＰＣＭ等の波形データであり、複数のトラック（ｔｒａｃｋ１〜１３）を含み、各トラックはキーコントロール（移調）される複数の音程に対応する。配信サーバ２が±６のキーコントロールに対応する場合は、各楽曲データあたり１３トラックの楽曲データが存在する。各楽曲データのトラックは、予め用意されており、音楽的なタイミング、再生時間は同一（厳密に同一でなくとも、基準ピッチトラックと比較して全体として数ｍｓｅｃ程度ずれていても良い）である。
【００３０】
図３に示すように、携帯電話端末から初回の配信要求を受け取ると、配信サーバ２は、携帯電話端末1に指示書を送信し、携帯電話端末1では、指示書に基づき初期設定を行う、その後、実際の楽曲データを含む着信メロディファイルの配信要求を行う。以降、配信サーバ２から着信メロディファイルを受信するごとに、次の着信メロディファイルの配信要求を行う。
【００３１】
携帯電話端末１は、初回の楽曲データ配信要求を、楽曲選択情報（ｓｉｄ）、機種情報（ｔｙｐ）を含めたＵＲＬ（例えば、http://contserv/?sid=xxxx&typ=yyyy）を配信サーバ２に送信する。楽曲選択情報（ｓｉｄ）は、楽曲選択を行うための画面情報を予め配信サーバ２からダウンロードしておき、リスト表示される等した楽曲をユーザが操作子を操作することで選択する。また、機種情報（ｔｙｐ）は、携帯電話端末１のＲＯＭ８（図１）から読み出される携帯電話端末１の機種を識別するための情報である。
【００３２】
携帯電話端末１は、配信サーバ２からデータを受け取ると、当該データを受信バッファ７１に一時的に保存する。配信サーバ２から「指示書」を受け取ると、該指示書に含まれる小片音声データの再生時間（Ｔ）及び全体の再生時間をレジスタ７２に書き込む。その後、１つ目の着信メロディファイルの配信要求をサーバ２に対して行う。この要求情報は、楽曲選択情報（ｓｉｄ）、配信区間を表すタイムスロット値（ｔｉｍｅ）、楽曲の調を指定するキーコントロール値（ｐｔ）、及び楽曲の品質を指定する要求品質値（ｑｔ）を含むＵＲＬ（例えば、http://contserv/?sid=xxxx&time=0&pt=0&qt=high）を配信サーバ２に送信することで行われる。なお、タイムスロット値の初期値は「０」である。携帯電話端末１では、この要求情報ＲＩを配信サーバ２に送信するたびにタイマ１１０をリセットしてタイマ値（ｔ）を「０」にする。すなわち、タイマ値（ｔ）は、着信メロディファイルの配信要求を行ってから、当該ファイルのダウンロードが完了して次のファイルの配信要求を行うまでの間の時間をカウントする値である。
【００３３】
キーコントロール値（ｐｔ）は、配信される着信メロディファイル内の小片音声データの調（ピッチ）を指定するためのパラメータであり、例えば、「ｐｔ＝０」は、初期設定値、すなわちキーコントロール（移調指示）無しを表し、「ｐｔ＝１〜６」は、それぞれ＋１〜＋６度のキーコントロールを表し、「ｐｔ＝Ａ〜Ｆ」は、それぞれ−１〜−６度のキーコントロールを表す。キーコントロール値の変更は、例えば、携帯電話端末１の電話番号キーの「１」が押されるたびに、キーを１つ下げ、「３」が押されるたびにキーを１つ上げることにより行われる。
【００３４】
要求品質値（ｑｔ）は、配信される着信メロディファイル内の小片音声データの品質を表すパラメータであり、例えば、「ｑｔ＝ｈｉｇｈ」は高品質（例えば、４４ｋｈｚ／１６ｋｂｐｓ）を表し、「ｑｔ＝ｍｉｄ」は中品質（例えば、２２ｋｈｚ／１６ｋｂｐｓ）を表し、「ｑｔ＝ｌｏｗ」は低品質（例えば、１１ｋｈｚ／８ｋｂｐｓ）を表す。
【００３５】
携帯電話端末１は、２回目以降の配信サーバ２からのデータ受信、すなわち、実際の楽曲データを含む着信メロディを受信すると、受信したデータを受信バッファ７１に読み込むとともに、受信したファイルに含まれる小片音声データを音声バッファ７４に展開して、Ｄ／Ａコンバータ１２０でアナログ音声信号に変換して、アンプ及びスピーカーを含むサウンドシステム１２１により発音することにより順次再生される。
【００３６】
カウンタ７３は、受信した小片音声データのサンプル数をカウントし、全体の再生時間のチェックを行うとともに、受信ファイル数をカウントし、タイムスロット値（ｔｉｍｅ）を「１」増加させる。また、新たな音声データを受信した時点で、前回の音声データの再生時間（Ｔ´）を比較部１９０に送るようにしても良い。
【００３７】
比較部１９０では、レジスタ７２に記憶されている指示書に含まれる再生時間（Ｔ）（若しくは、カウンタ７３からの前回のデータの再生時間（Ｔ´））と、タイマ１１０でカウントされる今回の音声データの配信要求を行ってからの時間（ｔ）とを比較する。音声が途切れること無く再生されるためには、小片音声データの再生時間（Ｔ）は、着信メロディファイルのダウンロード時間（ｔ）よりも長い（Ｔ＞ｔ）必要がある。なお、伝送路の状態によっては、着信メロディファイルのダウンロード時間（ｔ）が小片音声データの再生時間（Ｔ）を上回る（Ｔ＜ｔ）場合がある。その場合には、携帯電話端末１は、次のファイルの配信要求をする際に、楽曲データの品質変更を、要求品質値（ｑｔ）の値を下方に修正することで要求する。
【００３８】
なお、携帯電話端末１では、カウンタ７３により受信データサンプル数により累算される再生時間と、指示書にて通知された全体の再生時間とを比較して、サンプル数基準の再生時間が指示書で通知された再生時間に到達した場合、再生終了と判断して、当該楽曲に関する以降の配信要求を終了する。
【００３９】
配信サーバ２は、携帯電話端末１から、初回の楽曲データの配信要求があると、まず始めに、楽曲データの送信を開始する前に、小片音声データの再生時間（Ｔ）として１タイムスロットの間隔（例えば、５００ｍｓｅｃ）及び全再生時間を「指示書」として携帯電話端末１に通知する。
【００４０】
なお、品質の変更を行う場合に、再生すべき音声サンプリング値が不連続になる恐れがある。携帯電話端末１側では、音声バッファ７４内の音声データを再生する際に、ファイル接続区間に相当するデータの近傍でクロスフェードしたり補間したりして、ファイル間で滑らかにサンプル値が遷移するように制御してもよい。
【００４１】
同様に、小片音声データが、時間内受信できなかった場合に、現在の再生を一時停止するとともにフォースダンプし、次の小片音声データが到着次第、再生ポインタを当該フォースダンプをした時点まで戻し、そこから再生を再開（あわせて、ボリュームを滑らかに上げて）するようにしても良い。
【００４２】
配信サーバ２は、その後、再度、携帯電話端末１から要求情報ＲＩを受け取ると、ファイル読み出し制御部９０が、楽曲データを１タイムスロットの間隔分（例えば、５００ｍｓｅｃ）にタイムスロット値（ｔｉｍｅ）でかけた値の位置（読み出しポインタ値）から１タイムスロットの間隔分の楽曲データを読み出すことにより、楽曲データを小片音声データに分割し、合成部９１に送出する。携帯電話端末１からのキーコントロールの指示（移調指示）が無い場合（ｑｔの値の変更が無い場合）は、合成部９１に送られた小片音声データは、送信制御部２１０にて、当該携帯電話端末１に対応した着信メロディファイルに埋め込まれて、携帯電話端末１に送信される。
【００４３】
携帯電話端末１から移調指示があった場合は、トラックの切替は、小片音声データのタイミング（１タイムスロットの間隔）ごとに行うが、そのまま送信すると、波形データが不連続となるため、切り替え前のトラックと切替後のトラックの双方を読み出して、合成部９１でクロスフェードすることにより合成して、送信する。
【００４４】
合成部９１は、トラックを切り替えるためのスイッチＳＷ、乗算回路ＭＰ及び加算回路ＡＤＤを含んで構成される。合成を行う場合は、図４に示すように、調変更前のトラック（ｋｅｙ＝０）と調変更後のトラック（ｋｅｙ＝２）に対応する２つのスイッチＳＷをＯＮして、両者を並行して読み出し、「１〜０」にクロスフェード期間（５ｍｓｅｃ〜２０ｍｓｅｃ）で変化するように読出制御部９０から出力される乗算係数を変更前のトラックに対して乗算回路ＭＰで乗算し、「０〜１」にクロスフェード期間（５ｍｓｅｃ〜２０ｍｓｅｃ）で変化するように読出制御部９０から出力される乗算係数を変更後のトラックに対して乗算回路ＭＰで乗算する。その後、両者を加算回路ＡＤＤで加算することにより、クロスフェードを行う。なお、合成を行わない場合は、１つのトラックからのみ読み出しを行うように、所定のトラックのスイッチＳＷのみをＯＮして、その他のトラックに対応するスイッチＳＷをＯＦＦする。また、読出制御部９０からは、乗算係数「１」が送られてきて、乗算回路ＭＰにて「１」が乗算され、加算回路ＡＤＤを介して、送信制御部２１０に送られる。
【００４５】
送信制御部２１０では、合成部９１から送られる小片音声データをバッファＢＵＦに一時的に保存して、テンプレートＴＰを適用することにより、着信メロディファイルに小片音声データを埋め込んで、通信ネットワーク３を介して、携帯電話端末に送信する。
【００４６】
図５は、本発明の実施例による携帯電話端末１によるダウンロード処理を表すフローチャートである。
【００４７】
ステップＳＡ１で、ダウンロード処理を開始し、ステップＳＡ２では、配信サーバ２から、通信ネットワーク３を介して、配信可能な楽曲のリストを受信して、ディスプレイ１４に当該リストを表示する。
【００４８】
ステップＳＡ３では、ステップＳＡ２で表示した楽曲リストから、楽曲が選択されたか否かを判断する。選択された場合は、ＹＥＳの矢印で示すステップＳＡ４に進み、それ以外の場合は、ＮＯの矢印で示すステップＳＡ５に進む。
【００４９】
ステップＳＡ４では、ステップＳＡ３で検出した楽曲の選択に対応する楽曲データの配信を要求するためのＵＲＬをサーバに要求する。その後、ステップＳＡ９に進む。
【００５０】
ステップＳＡ５では、キー（調）変更の指示があるか否かを判断する。キー変更の指示がある場合は、ＹＥＳの矢印で示すステップＳＡ６に進み。それ以外の場合は、ＮＯの矢印で示すステップＳＡ７に進む。
【００５１】
ステップＳＡ６では、ステップＳＡ５で検出した指示に対応するキーコントロール値（ｐｔ）を設定する。その後、ステップＳＡ９に進む。
【００５２】
ステップＳＡ７では、ダウンロード処理の終了指示の有無を検出する。終了指示があった場合には、ＹＥＳの矢印で示すステップＳＡ１８に進み、この処理を終了し、終了指示以外の指示を検出した場合は、ＮＯの矢印で示すステップＳＡ８に進み、その他の処理を実行し、その後、ステップＳＡ９に進む。
【００５３】
ステップＳＡ９では、受信ファイルの有無を検出する。受信ファイルが無い場合は、ＮＯの矢印で示すステップＳＡ３に戻り以降の処理を繰り返す。「指示書」を受信した場合は、「Ａ」の矢印で示すステップＳＡ１０に進み、初期設定を行うとともに、タイムスロット値（ｔｉｍｅ）を「０」に設定し、ステップＳＡ１６に進む。小片音声データを含む着信メロディファイルを受信した場合は、「Ｂ」の矢印で示すステップＳＡ１１に進む。
【００５４】
ステップＳＡ１１では、図２のレジスタ７２に記憶されている再生時間（Ｔ）（若しくは、カウンタ７３から供給される前回のデータの再生時間（Ｔ´））と、タイマ１１０でカウントされる今回の音声データの配信要求を行ってからのタイマ値（ｔ）とを比較する。タイマ値（ｔ）が、再生時間（Ｔ）より大きい場合（ｔ＞Ｔ）、すなわち、小片音声データの再生時間よりもダウンロード時間の方が長い場合は、ＹＥＳの矢印で示すステップＳＡ１２に進み、要求品質値（ｑｔ）の値を下方に修正して、ステップＳＡ１３に進む。タイマ値（ｔ）が、再生時間（Ｔ）より小さい場合（ｔ＜Ｔ）は、ＮＯの矢印で示すステップＳＡ１３に進む。
【００５５】
ステップＳＡ１３では、ステップＳＡ９で受信を検出した着信メロディファイルに埋め込まれている小片音声データを抽出して、音声バッファ７４に展開して、当該小片音声データの再生を開始する。ステップＳＡ１４では、受信した小片音声データのサンプル数をカウントし、音声バッファ７４に展開した小片音声データの再生が終了するまで、再生時間（Ｔ）をカウントする。
【００５６】
ステップＳＡ１５では、カウンタ７３により受信データサンプル数により累算される再生時間と、指示書にて通知された全体の再生時間とを比較して、楽曲データの再生が終了したか否かを判断する。サンプル数基準の再生時間が指示書で通知された全体の再生時間に到達した場合、再生終了と判断して、ＹＥＳの矢印で示すステップＳＡ２に戻り、以降の処理を繰り返す。再生が終了していないと判断した場合は、ＮＯの矢印で示すステップＳＡ１６に進む。
【００５７】
ステップＳＡ１６では、タイムスロット値（ｔｉｍｅ）に「１」を加算し、次のファイルを配信サーバ２に要求する。なお、ここで送信される要求情報ＲＩは、ステップＳＡ６でキーコントロール値（ｐｔ）が変更された場合は、キーコントロール値（ｐｔ）を変更された値に修正する。また、ステップＳＡ１２で要求品質値（ｑｔ）が変更された場合は、要求品質値（ｑｔ）を変更された値に修正する。その後、ステップＳＡ１７に進み、タイムスロット値（ｔ）をリセット（「０」に設定）して、ステップＳＡ３の処理に戻り、以降の処理を繰り返す。
【００５８】
図６は、本発明の実施例による配信サーバ２による楽曲データ配信処理を表すフローチャートである。配信サーバ２は、電源投入後、電源切断までの間、常に携帯電話端末１からの楽曲要求を受け付けられるように待機しているものとする。
【００５９】
ステップＳＢ１で待機中の配信サーバ２に、携帯電話端末１からのアクセスがあると、ステップＳＢ２に進み、当該アクセスが、楽曲の配信要求であるか否かを判断する。楽曲の配信要求である場合は、ＹＥＳの矢印で示すステップＳＢ５に進み、それ以外の場合は、ＮＯの矢印で示すステップＳＢ３に進む。
【００６０】
ステップＳＢ３では、該アクセスが、その他の要求に係るものであるか否かを判断する。その他の要求である場合は、ＹＥＳの矢印で示すステップＳＢ４に進み、当該要求に対応する処理を行う。ここで、その他の要求とは、例えば、配信可能な楽曲リストの要求等である。その後、ステップＳＢ１４に進み、再度待機状態となる。その他の要求も無い場合は、ＮＯ矢印で示すステップＳＢ１４に進み、再度待機状態となる。
【００６１】
ステップＳＢ５では、今回の配信要求が初回の要求であるか否かを判断する。初回の要求である場合は、ＹＥＳの矢印で示すステップＳＢ６に進み、同一楽曲に対する２回目以降の要求である場合は、ＮＯの矢印で示すステップＳＢ７に進む。
【００６２】
ステップＳＢ６では、受信した配信要求に含まれる機種情報（ｔｙｐ）に基づきテンプレートを設定し、楽曲選択情報（ｓｉｄ）に基づき指示書を生成して、携帯電話端末１に送信する。テンプレートは、当該機種で再生可能な着信メロディファイルを作成して、小片音声データを埋め込むための情報である。指示書は、上述したように、１タイムスロットの間隔（例えば、５００ｍｓｅｃ）及び全再生時間を含む情報である。
【００６３】
ステップＳＢ７では、前回の配信要求からキーコントロール値（ｐｔ）が変更されたか否かを判断する。変更された場合は、ＹＥＳの矢印で示すステップＳＢ１０に進み、変更されていない場合は、ＮＯの矢印で示すステップＳＢ８に進む。
【００６４】
ステップＳＢ８では、受信した配信要求に含まれる楽曲選択情報（ｓｉｄ）に基づき楽曲ファイルを設定し、楽曲の調を指定するキーコントロール値（ｐｔ）に基づき楽曲ファイル内のトラックを設定し、配信区間を表すタイムスロット値（ｔｉｍｅ）に基づき読み出し区間を設定する。読出し区間の設定は、１タイムスロットの間隔（例えば、５００ｍｓｅｃ）にタイムスロット値（ｔｉｍｅ）を乗算して得られる読出し開始時間から１タイムスロットの間隔の時間分を設定する。
【００６５】
ステップＳＢ９では、ステップＳＢ８で設定したパラメータに基づき、小片音声データを読み出す。その後、ステップＳＢ１２に進む。
【００６６】
ステップＳＢ１０では、受信した配信要求に含まれる楽曲選択情報（ｓｉｄ）に基づき楽曲ファイルを設定し、楽曲の調を指定するキーコントロール値（ｐｔ）に基づき楽曲ファイル内のキー変更後のトラックＡを設定し、前回の配信要求に含まれていたキーコントロール値（ｐｔ０）に基づき楽曲ファイル内のキー変更前のトラックＢを設定し、配信区間を表すタイムスロット値（ｔｉｍｅ）に基づき読み出し区間を設定する。
【００６７】
ステップＳＢ１１では、ステップＳＢ１０で設定されたパラメータに基づき、切り替え前のトラックＢと切替後のトラックＡの双方を並行して読み出して、クロスフェードすることにより合成して、小片音声データを生成する。なお、合成の詳細については、図２の合成部９１の説明を参照する。
【００６８】
ステップＳＢ１２では、ステップＳＢ９で読み出された小片音声データ又はステップＳＢ１１で生成された小片音声データを受信した配信要求に含まれる要求品質値（ｑｔ）に対応する品質に変換する。なお、音声データの品質の変換は周知の技術による。また、それぞれの品質に対応したトラックを予め用意しておいて、上述のステップＳＢ９または、ステップＳＢ１１で要求品質値（ｑｔ）に対応するトラックを読み出すようにしても良い。その場合は、このステップは省略される。
【００６９】
ステップＳＢ１３では、ステップＳＢ６で設定したテンプレートを用いて、ステップＳＢ１２で品質変換された小片音声データを携帯電話端末１で再生可能な着信メロディファイルに埋め込んで、携帯電話端末１に送信する。その後、ステップＳＢ１４に進み、配信サーバ２を待機状態にする。
【００７０】
以上、本発明の実施例によれば、配信サーバ２で音声データを小片音声データに分割して、着信メロディファイルに埋め込んで携帯電話端末１に配信することができる。よって、携帯電話端末１では、元の楽曲データのデータ量にかかわらず、楽曲データを受信することができる。
【００７１】
また携帯電話端末側では、受信した着信メロディファイルを連続して再生するので、当該楽曲データの処理をストリーミング配信される楽曲データに比べて、処理負荷が軽減し、容易に行うことができる。また、配信サーバ２と携帯電話端末１との間で同期を取る必要も無い。また、配信サーバ２側でも、音声を切り出して送信することを連続して行うことで、処理負荷を軽減することができる。
【００７２】
また、以上のような構成により、伝送路の制限に関係なく、高品位で移調可能な、着信メロディ配信サービスや、カラオケサービスを提供することができる。
【００７３】
また、本発明の実施例によれば、携帯電話端末１から移調の指示がある場合には、移調前と移調後の小片音声データをクロスフェードして合成してから配信するので、移調による音声の不連続等を軽減することができる。
【００７４】
なお、上述の実施例では、キー値（調）が異なるトラックを複数有する一つの楽曲データを用いて説明したが、これに限るものではない。例えば、キー値（調）が異なる複数の楽曲データを用意しても良い。この場合、楽曲選択情報（ｓｉｄ）とキーコントロール値（ｐｔ）との組み合わせで、読み出し、送信するべきデータが決定される。
【００７５】
また、上述の実施例では、一つの楽曲データの中で、調を変更することのみを例示したが、配信要求のたびに異なる楽曲データを指定するようにしてもよい。この場合、ＤＪ或いは、いわゆるヒップホップのような複数の楽曲の小片を結合した楽曲演奏サービスを提供することができる。
【００７６】
また、上述の実施例では、携帯電話端末の機種を表す機種情報（ｔｙｐ）を最初にもに送るものとして説明したが、配信要求を送るたびに、機種情報（ｔｙｐ）を指定し、配信サーバ２側では、配信要求があるたびにテンプレートを設定しても良い。
【００７７】
以上実施例に沿って本発明を説明したが、本発明はこれらに制限されるものではない。例えば、種々の変更、改良、組み合わせ等が可能なことは当業者に自明であろう。
【図面の簡単な説明】
【００７８】
【図１】本発明の実施例による携帯電話端末1のハードウェア構成を表すブロック図である。
【図２】本発明の実施例による楽曲データ配信システム１００の構成を表すブロック図である。
【図３】図３は、配信サーバ２と携帯電話端末との間で送信される要求情報ＲＩとデータの流れを表すタイムチャートである。
【図４】図２の合成部９１による合成処理を説明するための概念図である。
【図５】本発明の実施例による携帯電話端末１によるダウンロード処理を表すフローチャートである。
【図６】本発明の実施例による配信サーバ２による楽曲データ配信処理を表すフローチャートである。
【符号の説明】
【００７９】
１…携帯電話端末、２…配信サーバ、３…通信ネットワーク、６…バス、７…ＲＡＭ、８…ＲＯＭ、９…ＣＰＵ、１０…タイマ、１１…検出回路、１２…入力操作子、１３…表示回路、１４…ディスプレイ、１５…外部記憶装置、１８…音源回路、１９…効果回路、２０…サウンドシステム、２１…通信Ｉ／Ｆ、７１…受信バッファ、７２…レジスタ、７３…カウンタ、７４…音声バッファ、９０…読出制御部、９１…合成部、１１０…タイマ、１２０…Ｄ／Ａコンバータ、１２１…サウンドシステム、１５０…楽曲データ記憶部、１９０…比較部、２１０…送信制御部
【図１】
2007256784.tif 000003
【図２】
2007256784.tif 000004
【図３】
2007256784.tif 000005
【図４】
2007256784.tif 000006
【図５】
2007256784.tif 000007
【図６】
2007256784.tif 000008