(57)【要約】【課題】  携帯型音楽プレイヤーで再生している楽曲データを他のユーザにも試聴できるようにする。【解決手段】  (a)携帯型音楽プレイヤー１０２は配信サーバ１００から楽曲データをダウンロードする。(b)この楽曲データを再生すると、そのうち一部を成すサンプル楽曲データが周囲のプレイヤー１０４に無線で配信される。その際、プレイヤー１０２の端末識別番号IDaが楽曲データのタグ情報に含められる。(c)プレイヤー１０４のユーザは、配信サーバ１００から該サンプル楽曲データに係る有償の楽曲データをダウンロードできる。(d)その販売額の一部がプレイヤー１０２のユーザに対して還元される。【選択図】  図１
2006267763.tif 000002
【特許請求の範囲】
【請求項１】
ユニークな識別番号を記憶する識別番号記憶手段と、
一または複数の楽曲データを記憶する楽曲データ記憶手段と、
前記楽曲データを読み出して再生する再生手段と、
前記再生手段において再生中の楽曲データの一部を成す音声データを記憶するキャッシュメモリと、
他の音楽再生装置から楽曲提供要求を受信すると、該他の音楽再生装置に対して、前記識別番号と前記音声データとを送信する音声データ送信手段と、
前記他の音楽再生装置に対して前記楽曲提供要求を送信する楽曲提供要求送信手段と、
前記他の音楽再生装置から前記楽曲提供要求に応じて供給された音声データを記憶する音声データ記憶手段と
を有することを特徴とする音楽再生装置。
【請求項２】
前記再生手段において前記楽曲データの再生が停止されると、前記キャッシュメモリに記憶されている音声データを破棄する音声データ破棄手段
をさらに有することを特徴とする請求項１記載の音楽再生装置。
【請求項３】
前記音声データ送信手段は、前記楽曲データを特定する楽曲データ識別情報を送信するものであり、
前記楽曲データを提供する配信装置に対して、前記楽曲データ識別情報を送信する楽曲データ識別情報送信手段と、
前記配信装置から前記楽曲データ識別情報に係る楽曲データを受信する楽曲データ受信手段と、
前記楽曲データ受信手段を介して前記楽曲データを受信すると、前記音声データ記憶手段内の対応する音声データを削除する音声データ削除手段と
をさらに有することを特徴とする請求項１または２記載の音楽再生装置。
【請求項４】
処理装置と、ユニークな識別番号を記憶する識別番号記憶手段と、一または複数の楽曲データを記憶する楽曲データ記憶手段と、前記楽曲データを読み出して再生する再生手段とを有する音楽再生装置の前記処理装置に対して、
前記再生手段において再生中の楽曲データの一部を成す音声データをキャッシュメモリに記憶する過程と、
他の音楽再生装置から楽曲提供要求を受信すると、該他の音楽再生装置に対して、前記識別番号と前記音声データとを送信する音声データ送信過程と、
前記他の音楽再生装置に対して前記楽曲提供要求を送信する楽曲提供要求送信過程と、
前記他の音楽再生装置から前記楽曲提供要求に応じて供給された音声データを記憶する音声データ記憶過程と
を実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯型音楽プレイヤーに用いて好適な音楽再生装置およびプログラムに関する。
【背景技術】
【０００２】
従来より、ＭＰ３形式等の楽曲ファイルを再生する携帯型音楽プレイヤーが知られている。この種のプレイヤーにおいては、各種の楽曲ファイルをキオスク端末を介してダウンロードして内部のハードディスク等に格納し、これら楽曲ファイルを再生することが可能である。また、特許文献１においては、列車内で音楽等のコンテンツを配信するシステムが開示されている。配信されるコンテンツは、このシステムの運用者によって予め用意されているものである。また、特許文献２には、携帯端末に対して情報配信を行う技術が開示されている。これは、ホットスポットに存在する携帯端末に対して各種コンテンツの配信を行うものである。
【０００３】
【特許文献１】特開２００３−１５０６８１号公報
【特許文献２】特開２００２−１８５６１２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１に開示された技術によれば、列車内でＦＭ放送や楽曲データを配信することは可能であるが、あらかじめ決められたプログラムに従いデータが配信されるのみであり意外性に乏しいという問題があった。これに対して、一般ユーザが携帯型音楽プレイヤー等で再生している楽曲データを収集して他の乗客に分配しようとすると、大規模な設備が必要になるという問題がある。さらに、通常乗客は頻繁に乗り降りするものであるから、蓄積しておくデータの更新管理を常時行う必要もある。 
【０００５】
また、特許文献１に係る技術においては、各乗客は、結局は電車設備から配信を希望するコンテンツを逐一選択しなければならず、操作が面倒であった。
さらに、単純に一般のユーザ間で音声データの配信ならびに受信・再生を許容した場合、著作物の使用料を把握することはきわめて困難であり、楽曲著作権者の権益は何ら保護されない可能性が高いという問題がある。
この発明は上述した事情に鑑みてなされたものであり、楽曲データを再生する音楽再生装置のユーザ以外の者にも鑑賞に堪える音質の音声データを簡単な構成で配信できる音楽再生装置およびプログラムを提供することを第１の目的としている。また、これらにおいて、楽曲データ等の著作権を保護することを第２の目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するため本発明にあっては、下記構成を具備することを特徴とする。なお、括弧内は例示である。
請求項１記載の音楽再生装置にあっては、ユニークな識別番号（IDa，IDb）を記憶する識別番号記憶手段（２３）と、一または複数の楽曲データを記憶する楽曲データ記憶手段（２２）と、前記楽曲データを読み出して再生する再生手段（８）と、前記再生手段（８）において再生中の楽曲データの一部を成す音声データを記憶するキャッシュメモリ（８８）と、他の音楽再生装置から楽曲提供要求（ＳＰ１８２）を受信すると、該他の音楽再生装置に対して、前記識別番号（IDa，IDb）と前記音声データとを送信する音声データ送信手段（１４，ＳＰ１５８）と、前記他の音楽再生装置に対して前記楽曲提供要求を送信する楽曲提供要求送信手段（１４，ＳＰ１８２）と、前記他の音楽再生装置から前記楽曲提供要求に応じて供給された音声データを記憶する音声データ記憶手段（２２，３０６，ＳＰ１９０）とを有することを特徴とする。
さらに、請求項２記載の構成にあっては、請求項１記載の音楽再生装置において、前記再生手段（８）において前記楽曲データの再生が停止されると、前記キャッシュメモリ（８８）に記憶されている音声データを破棄する音声データ破棄手段（ＳＰ３４，ＳＰ３０４）をさらに有することを特徴とする。
さらに、請求項３記載の構成にあっては、請求項１または２記載の音楽再生装置において、前記音声データ送信手段（１４，ＳＰ１５８）は、前記楽曲データを特定する楽曲データ識別情報（TAGs）を送信するものであり、前記楽曲データを提供する配信装置（１００）に対して、前記楽曲データ識別情報（TAGs）を送信する楽曲データ識別情報送信手段（１４，ＳＰ２１０）と、前記配信装置（１００）から前記楽曲データ識別情報（TAGs）に係る楽曲データを受信する楽曲データ受信手段（１４，ＳＰ２１２）と、前記楽曲データ受信手段（１４，ＳＰ２１２）を介して前記楽曲データを受信すると、前記音声データ記憶手段（２２，３０６）内の対応する音声データを削除する音声データ削除手段（ＳＰ２１４）とをさらに有することを特徴とする。
また、請求項４記載のプログラムにあっては、処理装置（２）と、ユニークな識別番号（IDa，IDb）を記憶する識別番号記憶手段（２３）と、一または複数の楽曲データを記憶する楽曲データ記憶手段（２２）と、前記楽曲データを読み出して再生する再生手段（８）とを有する音楽再生装置の前記処理装置（２）に対して、前記再生手段（８）において再生中の楽曲データの一部を成す音声データをキャッシュメモリ（８８）に記憶する過程と、他の音楽再生装置から楽曲提供要求（ＳＰ１８２）を受信すると、該他の音楽再生装置に対して、前記識別番号（IDa，IDb）と前記音声データとを送信する音声データ送信過程（ＳＰ１５８）と、前記他の音楽再生装置に対して前記楽曲提供要求を送信する楽曲提供要求送信過程（ＳＰ１８２）と、前記他の音楽再生装置から前記楽曲提供要求に応じて供給された音声データを記憶する音声データ記憶過程（ＳＰ１９０）とを実行させることを特徴とする。
【発明の効果】
【０００７】
このように、本発明によれば、他の音楽再生装置から楽曲提供要求に応じて供給された音声データを取得できるから、楽曲データを再生する音楽再生装置のユーザ以外の者にも鑑賞に堪える音質の音声データを配信できる。また、該音声データは再生中の楽曲データの利用態様が制限されたものであるから、楽曲データ等の著作権を保護することができる。さらに、楽曲データを再生するユーザ以外の他のユーザにとっては音声データの内容は未知のものであるから、音楽再生装置を意外性に富んだ方法で使用することができる。
【発明を実施するための最良の形態】
【０００８】
1．実施例の概要
次に、後述する第１，第２実施例の概要を図１を参照し説明する。図１(a)において１０２は携帯型音楽プレイヤーであり、配信サーバ１００から有償で楽曲ファイルをダウンロードすることができる。配信サーバ１００には、ネットワークを介して複数のキオスク端末が接続されており、各携帯型音楽プレイヤーは何れかのキオスク端末を介して配信サーバ１００と通信することになる。楽曲データの販売代金の決済には「購入ポイント」という一種の電子マネーが用いられ、各ユーザは予め購入ポイントをチャージすることによって楽曲データを購入することができる。
【０００９】
各プレイヤーにおいては楽曲データがＭＰ３形式等の形式を有する楽曲ファイルとして記憶される。各プレイヤーは固有の識別番号を有しており、プレイヤー１０２には端末識別番号IDaが付与されている。従って、配信サーバ１００においては、この端末識別番号IDaに基づいて各種ユーザ管理処理が行われることになる。なお、識別番号は携帯型音楽プレイヤーを一意に特定できる情報であればどのようなものであってもよいが、例えばプレイヤーのＭＡＣアドレスを用いることができる。
【００１０】
次に、図１(b)において携帯型音楽プレイヤー１０２のユーザＡが実際に該楽曲ファイルを再生すると、この楽曲ファイルに基づいて、他のプレイヤーに無償で提供するためのサンプル楽曲データが自動的に生成される。このサンプル楽曲データのタグ情報には、作成元のプレイヤー１０２の端末識別番号IDaが記録されている。ここで、プレイヤー１０２に他の携帯型音楽プレイヤー１０４が近接したとする。携帯型音楽プレイヤーは相互に無線ネットワークを介して通信することができ、プレイヤー１０４にはこのサンプル楽曲データが供給される。
【００１１】
次に、図１(c)において、携帯型音楽プレイヤー１０４のユーザＢがこのサンプル楽曲データを試聴した結果、有償の楽曲データの購入を希望する場合には、配信サーバ１００から当該楽曲データを有償でダウンロードすることができる。その際、プレイヤー１０４から配信サーバ１００に対して、プレイヤー１０４自体の端末識別番号IDbとともに、サンプル楽曲データの提供元になった携帯型音楽プレイヤー１０２の端末識別番号IDaも通知される。次に、図１(d)において、該端末識別番号IDaに対しては、「サンプル楽曲データを頒布した」ことの対価として、所定の購入ポイントがチャージされる。そして、次にユーザＡが他の楽曲データを購入するときに、この購入ポイントに応じた額だけ支払い金額が値引きされる。従って、各ユーザは、サンプル楽曲データの頒布に積極的に協力するようになる。
【００１２】
2．第１実施例
2．1．ハードウエア構成
まず、携帯型音楽プレイヤーの構成を図２(a)を参照し説明する。
２はＣＰＵであり、フラッシュメモリ４に記憶されたプログラム（詳細は後述する）に基づいて、バス１６を介して他の構成要素を制御する。フラッシュメモリ４には、プログラムの他、購入ポイント等の情報が記録される。６はＲＡＭであり、ＣＰＵ２のワークメモリとして用いられる。８はＣＯＤＥＣであり、未圧縮の音声信号を圧縮してＭＰ３形式の楽曲データを生成するとともに、ＭＰ３形式の楽曲データを解凍してＰＣＭ形式の音声信号を得る。１０はサウンドシステムであり、ＣＯＤＥＣ８から出力された音声信号をアナログ信号に変換し、ヘッドホン１２を介して放音する。
【００１３】
１４は無線インタフェースであり、ブルートゥース（商標）に準拠しており、他の携帯型音楽プレイヤーまたはキオスク端末との間で双方向通信を行う。１８はディスプレイであり、ユーザに対して各種情報を表示する。２０は操作部であり、各種キーから構成されている。特に、操作部２０の内部にはプレイ・ストップボタン２０ａが設けられている。２２はハードディスクであり、楽曲ファイル、サンプル楽曲ファイル等を記憶する。２３はＲＯＭであり、該プレイヤーの端末識別番号を記憶する。２４はその他インタフェースであり、必要に応じて他の各種の機器に接続されデータ通信を実行する。
【００１４】
次に、配信サーバ１００（あるいはキオスク端末）の構成を図２(b)を参照し説明する。図において、３２はハードディスクであり、オペレーティングシステム、各種アプリケーションプログラム、楽曲データ等が格納される。３４はディスプレイであり、ユーザに対して各種情報を表示する。３６は入力装置であり、文字入力用キーボードおよびマウス等から構成されている。４０は通信インタフェースであり、配信サーバ１００は通信インタフェース４０を介してキオスク端末と通信するとともに、キオスク端末は携帯型音楽プレイヤーおよび配信サーバ１００との間でそれぞれデータ通信を行う。４２はＣＰＵであり、バス３８を介して他の構成要素を制御する。４４はＲＯＭであり、配信サーバ１００（キオスク端末）のイニシャルプログラムローダ等が記憶されている。４６はＲＡＭであり、ＣＰＵ４２のワークメモリとして用いられる。配信サーバ１００とキオスク端末とは、それぞれ独立したコンピュータ装置であるが、図示しない通信ネットワークを介して相互に共働することにより一つの配信システムとして機能する。以下、説明の便宜上、この配信システムを指して配信サーバ１００という。
【００１５】
2．2．データ構成
次に、携帯型音楽プレイヤーのハードディスク２２内のメモリマップを図３を参照し説明する。
図においてハードディスク２２内の領域は、ファイル管理テーブル領域５０と、楽曲ファイルエリア５２と、サンプル楽曲ファイルエリア６０とから成る。ここで、楽曲ファイルエリア５２には、複数の楽曲ファイル５４が格納され、サンプル楽曲ファイルエリア６０には複数のサンプル楽曲ファイル６２が格納されている。楽曲ファイル５４，６２は共にＭＰ３形式のファイルであるが、楽曲ファイル５４は有償で売買されるものであり、サンプル楽曲ファイル６２は無償で頒布されるものである。
【００１６】
各楽曲ファイル５４は、タグ情報５６と圧縮音声データ５８とから成る。同様に、各サンプル楽曲ファイル６２は、タグ情報６４と圧縮音声データ６６とから成る。ここで、タグ情報には、圧縮音声データに係るアルバムのタイトル、著作権情報などが記録されている。サンプル楽曲ファイル６２のタグ情報６４は、オリジナルタグ情報６８、生成時刻７０、取得時刻７２、提供元情報７４、およびその他情報７６から成る。サンプル楽曲ファイル６２は他の携帯型音楽プレイヤーのハードディスク２２内に記録された通常の楽曲ファイル５４から生成されたものであり、オリジナルタグ情報６８はこの楽曲ファイルに元々含まれていたタグ情報の内容に等しい。また、生成時刻７０は該サンプル楽曲ファイルが生成された時刻であり、取得時刻７２は当該携帯型音楽プレイヤーが該サンプル楽曲ファイルを取得した時刻を表す。また、提供元情報７４は該サンプル楽曲ファイルに係るサンプル楽曲データを作成した携帯型音楽プレイヤーの識別番号である。
【００１７】
2．3．ＣＯＤＥＣの構成
次に、ＣＯＤＥＣ８の詳細構成を図４を参照し説明する。図において８０はデコーダであり、ハードディスク２２から読み出された楽曲ファイル５４，６２中の圧縮音声データ５８，６６をデコードし、非圧縮の音声信号（ＰＣＭデータ）に変換する。但し、楽曲ファイルに含まれるタグ情報５６はＣＰＵ２によって読み取られ、オリジナルタグ情報TAGsとしてＣＯＤＥＣ８に別途供給される。８２はＦＩＦＯバッファであり、該音声信号を受信するとともに、その出力信号をサウンドシステム１０およびアンド回路８４の一入力端に供給する。ここで、ＣＰＵ２によって、下記の信号がＣＯＤＥＣ８に対して供給される。
【００１８】
（１）リクエストフラグREQ：これは、ＦＩＦＯバッファ８２の出力信号がサンプル楽曲データに含めるべき期間であるときに“true”に設定される。これは、例えば、楽曲データの再生開始時から「３０」秒の期間である。それ以外の期間はリクエストフラグREQは“false”に設定される。また、楽曲ファイルとしてサンプル楽曲ファイル６２を再生中であれば、リクエストフラグREQは常に“false”に設定される。
（２）音量係数AMP：これはサンプル楽曲データの音量を決定する係数であり、特にリクエストフラグREQが“false”になる数秒前から該サンプル楽曲データをフェードアウトするために用いられる。
（３）オリジナルタグ情報TAGs：これは、ハードディスク２２から読出され再生されている楽曲ファイル５４の元々のタグ情報５６の内容である。
【００１９】
（４）端末識別番号IDa:上述した通り、当該携帯型音楽プレイヤーのユニークな識別番号である。
（５）サンプル楽曲データ生成時刻TIME:これは、サンプル楽曲データを生成した時刻である。なお、時刻情報はＣＰＵ２の内蔵クロックから取得される。
（６）センドフラグSEND:これは、サンプル楽曲データを作成した後、他の携帯型音楽プレイヤーに送信するタイミングに“true”、それ以外の期間は“false”に設定される。
（７）その他：以上の他、各キャッシュメモリをクリアする信号等が必要に応じてＣＰＵ２からＣＯＤＥＣ８に供給される。
【００２０】
楽曲ファイルを再生中にその再生位置がサンプル楽曲データに係る位置になると、リクエストフラグREQが“true”になるため、ＦＩＦＯバッファ８２から出力される音声信号がアンド回路８４を介して出力される。８６は増幅部であり、この音声信号に対して音量係数AMPに応じてゲイン調節を施す。８８はキャッシュメモリであり、ゲイン調節の施された音声信号を一時的に格納する。９０はエンコーダであり、キャッシュメモリ８８内の音声信号に対して圧縮処理を施す。
【００２１】
９２はキャッシュメモリであり、ＣＰＵ２から受信した端末識別番号IDaと、サンプル楽曲データ生成時刻TIMEと、オリジナルタグ情報TAGsとを入力するとともに、エンコーダ９０から出力された圧縮音声データを入力し、これらを結合したサンプル楽曲データを記録する。９４はキャッシュ制御回路であり、ＣＰＵ２からのセンドフラグSENDが“true”になると、キャッシュメモリ９２の内容を無線インタフェース１４に供給する。また、キャッシュ制御回路９４は、キャッシュメモリ９２の状態として、以下のうち何れかのキャッシュステータスSTATEをＣＰＵ２に対して返信する。
（１）NO PLAY：キャッシュメモリ９２にデータが記憶されていない状態。
（２）READY：サンプル楽曲データを作成中の状態。
（３）STAND BY：サンプル楽曲データが完成し、送信可能になっている状態。
【００２２】
これにより、サンプル楽曲データが他の携帯型音楽プレイヤーに送信される。また、無線インタフェース１４においては、他のプレイヤーやキオスク端末から、楽曲データやサンプル楽曲データ等を受信することも可能である。このようにした受信されたデータは、キャッシュメモリ９６に記憶された後、ハードディスク２２に記憶されることになる。
【００２３】
2．4．第１実施例の動作
2．4．1．メインルーチンの処理
次に、本実施例の動作を説明する。まず、携帯型音楽プレイヤーの電源が投入されると、図５に示すメインルーチンが起動される。図５において処理がステップＳＰ２に進むと、各種パラメータが初期化される。ここで、初期化されるパラメータのうち主要なものについて説明する。まず、上述したＣＯＤＥＣ８に供給されるフラグ等は以下の値に初期化される。
（１）リクエストフラグREQ：“false”、
（２）音量係数AMP：「0.0」、
（３）センドフラグSEND：“false”。
【００２４】
また、本実施例のプログラム中では、動作状態を決定するための各種フラグが使用される。これらのフラグのうち主要なものの内容および初期化状態は以下の通りである。
（１）検索フラグSEARCH：これは、当該プレイヤーが他ノード（他のプレイヤーまたはキオスク端末）を検索するか否かを示すフラグであり、“false”（検索しない）に初期化される。
（２）再生中フラグPLAY：これは、当該プレイヤーにおいて楽曲データを再生中であるか否かを示すフラグであり、“false”（非再生中）に初期化される。
（３）リクエスト許可フラグALLOWREQ：これは、他ノードからのサンプル楽曲データのリクエストを容認するか否かを示すフラグであり、“false”に初期化される。
【００２５】
次に、処理がステップＳＰ４に進むと、無線インタフェース１４の初期化が行われる。次に、処理がステップＳＰ６に進むと、検索フラグSEARCHが“true”に設定され、他ノードの検索が開始される。次に、処理がステップＳＰ８に進むと、各種イベントが発生したか否かが検出され、イベントが検出された場合には、処理はステップＳＰ１０に進み、当該イベントに応じた各種の処理が実行される。以後、ステップＳＰ８，ＳＰ１０の処理が繰り返される。なお、ステップＳＰ８において検出されるイベントとは、操作部２０における操作やタイマ割込み等である。以下、各種イベントの内容と対応する処理について個々に詳述する。
【００２６】
2．4．2．プレイ・ストップイベント処理
(1)楽曲ファイルの再生を開始する場合
操作部２０においてプレイ・ストップボタン２０ａの押下イベントが発生すると、プレイ・ストップイベント処理ルーチン（図６）が起動される。図６において処理がステップＳＰ２０に進むと、再生中フラグPLAYに基づいて、現在は楽曲ファイルの再生中であるか否かが判定される。再生中でなければ処理はステップＳＰ２２に進み、検索フラグSEARCHが“false”に設定される。これは、自機に元々格納されている楽曲データをこれから再生するのであるから、他ノードが提供するサンプル楽曲データは検索しないということである。
【００２７】
次に、処理がステップＳＰ２４に進むと、楽曲データの中からタグ情報が切り出されＲＡＭ６内の所定領域に格納される。次に、処理がステップＳＰ２６に進むと、再生中フラグPLAYが“true”に設定される。これにより、後述する図７(a)のルーチンにより、楽曲ファイル５４が再生され、デコーダ８０、ＦＩＦＯバッファ８２を介してサウンドシステム１０から楽音信号が放音されるようになる。次に、処理がステップＳＰ２８に進むと、タグ情報内に端末識別番号IDaが存在するか否かが判定される。なお、タグ情報内に端末識別番号IDaが存在する楽曲ファイルはサンプル楽曲ファイルであり、存在しない楽曲ファイルは通常の楽曲ファイルである。
【００２８】
ステップＳＰ２８において「ＮＯ」（通常の楽曲ファイル）と判定されると、処理はステップＳＰ３０に進む。ここでは、リクエスト許可フラグALLOWREQは“true”に設定される。これは、自機で再生中の楽曲ファイルに基づいてサンプル楽曲データを生成し、他ノードからのリクエストに応じる、ということである。また、リクエストフラグREQが“true”に設定され、音量係数AMPが「1.0」に設定され、サンプル生成残り時間TMRが全サンプル生成時間MAX_LEN（例えば３０秒）に設定される。これらの設定を行うと、ＣＯＤＥＣ８からREADY状態のキャッシュステータスSTATEが返信されるから、この返信を確認した後に本ルーチンが終了する。一方、ステップＳＰ２８において「ＹＥＳ」（サンプル楽曲ファイル）と判定されると、上記ステップＳＰ３０はスキップされる。すなわち、本実施例においては、サンプル楽曲ファイルを再生する場合には、他のノードに対してこれをさらに転送しないこととしている。
【００２９】
(2)楽曲ファイルの再生を停止する場合
一方、ステップＳＰ２０において再生中である（再生中フラグPLAYが“true”である）と判定されると、処理はステップＳＰ３４に進む。ここでは、キャッシュメモリ９２がクリアされる。これに応じてＣＯＤＥＣ８からＣＰＵ２に対してNO PLAY状態のキャッシュステータスSTATEが返信されるため、この返信があるまで処理が待機する。次に、処理がステップＳＰ３８に進むと、再生中フラグPLAYが“false”に設定される。これにより、後述する再生タイマ割込処理ルーチン（図７(a)）においては実質的な再生処理が実行されなくなり、楽曲ファイルの再生が停止することになる。
【００３０】
次に、処理がステップＳＰ４０に進むと、検索フラグSEARCHが“true”に設定され、他ノード検索が再開される。さらに、リクエスト許可フラグALLOWREQが“false”に設定され、他ノードからのリクエストに応じなくなる。すなわち、自機に記憶されている楽曲ファイルを再生しないために、他ノードからサンプル楽曲データを受信することが可能になり、また、自機自体は他ノードにサンプル楽曲データを提供できないため、他ノードのリクエストを許可しないことになる。
【００３１】
2．4．3．再生タイマ割込処理（図７(a)）
ＣＰＵ２においては、数msec毎のタイマ割込み間隔dT毎に図７(a)に示す再生タイマ割込処理ルーチンが起動される。図において処理がステップＳＰ５０に進むと、再生中フラグPLAYに基づいて楽曲ファイルが現在再生中であるか否かが判定される。ここで再生中フラグPLAYが“false”であれば本ルーチンは直ちに終了する。一方、再生中フラグPLAYが“true”であれば処理はステップＳＰ５２に進む。ここでは、ハードディスク２２における楽曲ファイルの読み出し位置のアドレスが所定のステップ幅だけ更新される。
【００３２】
次に、処理がステップＳＰ５４に進むと、読み出し位置のアドレスから上記ステップ幅分のデータが読み出され、ＣＯＤＥＣ８内のデコーダ８０に供給される。これにより、ＣＯＤＥＣ８の内部においては、供給されたデータがデコードされ非圧縮のＰＣＭデータが生成されるとともに、該ＰＣＭデータがＦＩＦＯバッファ８２に蓄積される。次に、処理がステップＳＰ５６に進むと、更新後の読み出し位置がファイル終了位置EOFに達したか否かが判定される。ここで「ＹＥＳ」と判定されると、処理はステップＳＰ５８に進み、プレイ・ストップイベント処理ルーチン（図６）が強制的に呼び出される。これにより、上記ステップＳＰ３４〜ＳＰ４０の処理が実行され、再生中フラグPLAYは“false”に設定されることになる。一方、ステップＳＰ５６において「ＮＯ」と判定されると、該ステップＳＰ５８はスキップされる。
【００３３】
2．4．4．サンプル再生タイマ割込処理（図７(b)）
また、再生タイマ割込処理ルーチン（図７(a)）と同一の周期であるタイマ割込み間隔dT毎に（同一のタイミングでなくてもよい）図７(b)に示すサンプル再生タイマ割込処理ルーチンが起動される。図７(b)において処理がステップＳＰ７２に進むと、リクエストフラグREQに基づいて、サンプル楽曲データを作成中であるか否かが判定される。リクエストフラグREQが“false”であれば、本ルーチンは直ちに終了する。
【００３４】
一方、リクエストフラグREQが“true”であれば処理はステップＳＰ７４に進み、サンプル生成残り時間TMRがフェードアウト時間T1以下になったか否かが判定される。なお、フェードアウト時間T1は「２」秒程度の時間である。ここで、“true”と判定されると、処理はステップＳＰ７６に進み、音量係数AMPから所定のステップ値STPが減算される。一方、ＣＯＤＥＣ８の内部においては、ＦＩＦＯバッファ８２から出力されたＰＣＭデータに、増幅部８６において該音量係数AMPが乗算された後にキャッシュメモリ８８に格納されてゆく。従って、サンプル生成残り時間TMRがフェードアウト時間T1に達していなければ、ステップＳＰ７６はスキップされ、ＦＩＦＯバッファ８２の出力音声信号は減衰されることなくキャッシュメモリ８８に格納されることになる。次に、処理がステップＳＰ７８に進むと、キャッシュメモリ８８への音声信号の転送が確認される。
【００３５】
次に、処理がステップＳＰ８０に進むと、サンプル生成残り時間TMRからタイマ割込み間隔dTが減算される。次に、処理がステップＳＰ８２に進むと、サンプル生成残り時間TMRが「０」になったか否かが判定される。ここで“false”と判定されると、本ルーチンの処理は直ちに終了する。一方、ステップＳＰ８２において“true”と判定されると処理はステップＳＰ８４に進み、ＣＰＵ２からＣＯＤＥＣ８に対してサンプル楽曲データ生成コマンドが供給される。ＣＯＤＥＣ８においては、該コマンドに応じて、オリジナルタグ情報TAGsと、当該携帯型音楽プレイヤーの端末識別番号IDaと、サンプル楽曲データ生成時刻TIMEとに基づいて、サンプル楽曲データに付加すべきタグ情報が生成される。
【００３６】
これに引き続いて、キャッシュメモリ８８に記憶されたＰＣＭデータがエンコーダ９０に供給され、該ＰＣＭデータが圧縮される。そして、その結果得られた圧縮音声データにタグ情報が付加されキャッシュメモリ９２に記憶される。かかる処理により、キャッシュメモリ９２には、他の携帯型音楽プレイヤーに提供しうるサンプル楽曲データが記憶されることになる。以上の処理によって、サンプル楽曲データを生成するためのＣＰＵ２側の処理は完了したため、次に処理がステップＳＰ８６に進むと、リクエストフラグREQが“false”に設定される。その後に、ＣＯＤＥＣ８内においてサンプル楽曲データの生成が完了すると、キャッシュステータスSTATEがSTAND BY状態に設定されるため、その旨が確認されると本ルーチンの処理は終了する。
【００３７】
2．4．5．他ノード探索割込処理（図８(a)）
ＣＰＵ２においては、数秒毎のタイマ割込み間隔dTA毎に図８(a)に示す他ノード探索割込処理ルーチンが起動される。図において処理がステップＳＰ１００に進むと、検索フラグSEARCHに基づいて他ノード検索を実行するか否かが判定される。ここで検索フラグSEARCHが“false”であれば本ルーチンは直ちに終了する。一方、検索フラグSEARCHが“true”であれば処理はステップＳＰ１０２に進み、通信プロトコルに従って、他ノードとのコネクションが確立するように試行される。すなわち、無線インタフェース１４から所定のコネクション要求が出力され、他ノードからの応答があった場合にはその旨が検出される。
【００３８】
ここで、コネクションが確立すると、処理はステップＳＰ１０４に進み、自機の種類が「携帯型音楽プレイヤー」であることを明示するとともに、相手側ノードの種類を問い合わせるための問合せ信号が出力される。次に、処理がステップＳＰ１０６に進むと、相手側ノードの種類を示す種類識別データが受信される。なお、上記ステップＳＰ１０２〜ＳＰ１０６の処理が所定時間内に完了しなかった場合には、タイムアウトになったこととして処理はステップＳＰ１２０に進み、携帯型音楽プレイヤーが待ち受け状態に移行した後に本ルーチンの処理が終了する。
【００３９】
一方、上記ステップＳＰ１０２〜ＳＰ１０６の処理が該所定時間内に完了した場合は処理はステップＳＰ１０８に進み、受信した種類識別データが「携帯型音楽プレイヤー」か否かが確認される。ここで「ＹＥＳ」と判定されると、処理はステップＳＰ１１０に進み、検索フラグSEARCHが“false”に設定され他ノード探索が停止される。次に、処理がステップＳＰ１１２に進むと、相手側ノードに対してサンプル楽曲データをリクエストする提供リクエスト処理ルーチン（図９）が起動される。なお、その処理については後述する。
【００４０】
一方、種類識別データが「携帯型音楽プレイヤー」ではなかった場合は処理はステップＳＰ１１４に進み、種類識別データが「キオスク端末」であるか否かが判定される。ここで「ＮＯ」と判定されると、処理はステップＳＰ１２０に進み、プレイヤーが待ち受け状態に移行した後に本ルーチンの処理が終了する。一方、ステップＳＰ１１４において「ＹＥＳ」と判定されると、処理はステップＳＰ１１６に進み、検索フラグSEARCHが“false”に設定されることにより、他ノード探索が停止される。次に処理がステップＳＰ１１８に進むと、該キオスク端末に対して楽曲データをリクエストするサイトアクセスルーチン（図１０）が起動される。なお、その処理については後述する。
【００４１】
2．4．6．リクエスト受信処理（図８(b)）
また、ＣＰＵ２においては、数秒毎のタイマ割込み間隔dTB毎に図８(b)に示すリクエスト受信処理ルーチンが起動される。図において処理がステップＳＰ１３０に進むと、リクエスト許可フラグALLOWREQが“true”であるか否かが判定される。該フラグALLOWREQが“false”である場合には、本ルーチンの処理は直ちに終了する。一方、フラグALLOWREQが“true”であれば処理はステップＳＰ１３２に進み、無線インタフェース１４において他ノードからのコネクション要求を受けているか否かが判定される。ここで、コネクション要求が無ければ本ルーチンの処理は直ちに終了する。
【００４２】
一方、他ノードからコネクション要求を受信している場合には処理はステップＳＰ１３４に進み、通信プロトコルに従って、コネクションが確立するように試行される。ここで、コネクションが確立すると、処理はステップＳＰ１３６に進み、所定時間を限度として、相手側ノードから種類の問合せ信号を受信するまで処理が待機する。ここで、上記ステップＳＰ１３４，ＳＰ１３６の処理が該所定時間内に完了しなかった場合には、処理はステップＳＰ１４４に進み、携帯型音楽プレイヤーが待ち受け状態に移行した後に本ルーチンの処理が終了する。これは、種類の問合せを受けなかったということは、自機とは異種の装置であると考えられるためである。
【００４３】
一方、上記ステップＳＰ１３４，ＳＰ１３６の処理が該所定時間内に完了した場合には処理はステップＳＰ１３８に進む。ここでは、相手側ノード（これは自機と同種の携帯型音楽プレイヤーである）に対して、自機の種類識別データが返信される。次に、処理がステップＳＰ１４０に進むと、リクエスト許可フラグALLOWREQが“false”に設定され、以後、上記相手側ノード以外の他ノードからコネクション要求を受信したとしてもこれに応答しなくなる。次に処理がステップＳＰ１４２に進むと、図９に示す提供処理ルーチンが起動される。
【００４４】
2．4．7．提供処理および提供リクエスト処理
図１(b)において、携帯型音楽プレイヤー１０２から携帯型音楽プレイヤー１０４に対してサンプル楽曲データが提供される旨を述べたが、より詳細には、プレイヤー１０４において上述した他ノード探索割込処理ルーチン（図８(a)）のステップＳＰ１１２を介して提供リクエスト処理ルーチンが実行され、プレイヤー１０２において上述したリクエスト受信処理ルーチン（図８(b)）のステップＳＰ１４２を介して提供ルーチンが起動されるということである。そこで、かかる場合におけるプレイヤー１０２，１０４の処理の内容を図９を参照し説明する。
【００４５】
まず、プレイヤー１０４において処理がステップＳＰ１７２に進むと、プレイヤー１０４からプレイヤー１０２に対して、プレイヤー１０２のキャッシュメモリ９２の状態すなわちキャッシュステータスSTATEを送信するように問合せが出力される。プレイヤー１０２においては、この問合せが受信されると処理はステップＳＰ１５２に進み、プレイヤー１０４に対してキャッシュステータスSTATEが送信される。プレイヤー１０４において該キャッシュステータスSTATEが受信されると、処理はステップＳＰ１７４に進み、これがSTAND BY状態であるか否かが判定される。ここで「ＮＯ」と判定されると、処理はステップＳＰ１７６に進み、キャッシュステータスSTATEはREADY状態であるか否かが判定される。ここで「ＹＥＳ」と判定されると、処理は再びステップＳＰ１７２に戻り、キャッシュステータスSTATEの内容を繰り返し問い合わせる。
【００４６】
このように、プレイヤー１０２から返信されるキャッシュステータスSTATEがREADY状態であり続けると、プレイヤー１０４においてステップＳＰ１７２，ＳＰ１７４，ＳＰ１７６のループが繰り返されるが、このループ時間が所定時間を超えると、ステップＳＰ１７６においてタイムアウトが発生したものと判定され、処理はステップＳＰ１８４に進む。ここでは、コネクションが切断された後、再び検索フラグSEARCHが“true”に設定され、他ノード検索が開始される。そして、プレイヤー１０４が待ち受け状態に移行した後に本ルーチンが終了する。また、プレイヤー１０２からキャッシュステータスSTATEとしてNO PLAY状態が通知された場合には、ステップＳＰ１７４，ＳＰ１７６を介して、ステップＳＰ１８４の処理が直ちに実行される。
【００４７】
一方、携帯型音楽プレイヤー１０２からSTAND BY状態のキャッシュステータスSTATEを受信すると、プレイヤー１０４において処理はステップＳＰ１７８に進み、サンプル楽曲データを特定する楽曲データをプレイヤー１０２に要求する楽曲データ要求信号が送信される。プレイヤー１０２においては、該楽曲データ要求信号が受信されると処理はステップＳＰ１５４に進み、サンプル楽曲データに係る楽曲ＩＤがプレイヤー１０４に対して返信される。なお、楽曲ＩＤとは楽曲を一意に特定する識別番号である。一般的に、ＣＤ等に記録された楽曲をＭＰ３形式に変換する場合には、当該ＣＤの識別番号がタグ情報に記録される。そこで、このＣＤの識別番号と、該ＣＤのトラック番号とを結合したものを楽曲ＩＤとするとよい。
【００４８】
次に、プレイヤー１０４において該楽曲ＩＤが受信されると、処理はステップＳＰ１８０に進み、当該楽曲ＩＤに係る楽曲データ（通常の楽曲データ）が未取得であるか否かが判定される。ここで、該楽曲ＩＤに係る楽曲データが既に楽曲ファイルエリア５２内に記憶されている場合には“false”と判定され、処理はステップＳＰ１８４に進む。すなわち、かかる場合には、サンプル楽曲データをダウンロードする利点が無いため、コネクションが切断された後、再び検索フラグSEARCHが“true”に設定され、他ノード検索が開始される。この場合において、他ノード検索を開始する代わりに、既に取得していたサンプル楽曲データを再生するために、これを再生ファイルに設定するとともにプレイ・ストップイベントを発生させる処理（後述のステップＳＰ１９２，ＳＰ１９４）を実行してもよい。
【００４９】
一方、ステップＳＰ１８０において“true”と判定されると、処理はステップＳＰ１８２に進み、該サンプル楽曲データの転送要求がプレイヤー１０２に対して送信される。プレイヤー１０２においては、該転送要求が受信されると、センドフラグSENDが“true”に設定される。そして、プレイヤー１０２において処理がステップＳＰ１５８に進むと、サンプル楽曲データがパケット化され、無線インタフェース１４を介して出力される。
【００５０】
携帯型音楽プレイヤー１０４においては、該サンプル楽曲データが受信されると処理はステップＳＰ１８６に進み、該サンプル楽曲データがに基づいてハードディスク２２内にサンプル楽曲ファイル６２が生成される。なお、再び図３を参照すると、サンプル楽曲ファイル６２のタグ情報６４のうちオリジナルタグ情報６８、生成時刻７０、および提供元情報７４は、受信したサンプル楽曲データに含まれるオリジナルタグ情報TAGs、サンプル楽曲データ生成時刻TIMEおよび端末識別番号IDaに等しい。さらに、プレイヤー１０４において該サンプル楽曲データを受信した時刻が取得時刻７２としてサンプル楽曲ファイルに追加されることになる。
【００５１】
ここで、プレイヤー１０２においては、サンプル楽曲データの送信が完了すると、処理はステップＳＰ１６０に進み、センドフラグSENDが“false”に設定される。そして、プレイヤー１０４とのコネクションが切断される。次に、プレイヤー１０２において処理がステップＳＰ１６２に進むと、該プレイヤー１０２の状態が待ち受け状態に移行し、処理がステップＳＰ１６４に進むと、他の携帯型音楽プレイヤーからのリクエストに応答すべくリクエスト許可フラグALLOWREQが“true”に設定され、プレイヤー１０２の提供処理ルーチンの処理が終了する。
【００５２】
一方、携帯型音楽プレイヤー１０４においては、上記ステップＳＰ１８６においてサンプル楽曲ファイル６２が生成されると、プレイヤー１０２とのコネクションが切断される。次に、処理がステップＳＰ１８８に進むと、プレイヤー１０４の状態が待ち受け状態に移行する。次に処理がステップＳＰ１９０に進むと、先に受信したサンプル楽曲ファイル６２が再生すべきファイル（再生ファイル）として指定される。次に処理がステップＳＰ１９４に進むと、現在の再生ファイルに対するプレイ・ストップイベントが強制的に発生される。これにより、上述したプレイ・ストップイベント処理ルーチン（図６）が起動され、サンプル楽曲データが自動的に再生される。
【００５３】
2．4．8．サイトアクセス処理および楽曲データ配信処理
図１(c)において、携帯型音楽プレイヤー１０４においては、配信サーバ１００のキオスク端末を介して有償の楽曲データをダウンロードできる旨を述べたが、より詳細には、プレイヤー１０４において上述した他ノード探索割込処理ルーチン（図８(a)）のステップＳＰ１１８を介してサイトアクセスルーチンが実行され、配信サーバ１００において楽曲データを配信する配信処理が起動されるということである。そこで、かかる場合におけるプレイヤー１０４および配信サーバ１００の処理の内容を図１０を参照し説明する。
【００５４】
プレイヤー１０４において処理がステップＳＰ２０２に進むと、プレイヤー１０４の端末識別番号IDbが配信サーバ１００に通知される。配信サーバ１００においては、該端末識別番号IDbの通知を受けると処理はステップＳＰ２３０に進み、ユーザデータベースの中から該端末識別番号IDbのレコードが読み出され、該レコード内になるキャッシュバックデータの内容が確認される。なお、キャッシュバックデータとは、携帯型音楽プレイヤーに対して購入ポイントを発行する根拠となるデータであり、キャッシュバックデータをチャージする処理内容については後述する。次に、配信サーバ１００において処理がステップＳＰ２３２に進むと、プレイヤー１０４に対してなんらかのキャッシュバックデータが記録されているか否かが判定される。
【００５５】
ステップＳＰ２３２において「ＹＥＳ」と判定されると処理はステップＳＰ２３４に進み、キャッシュバックデータに応じた金額の購入ポイントがプレイヤー１０４に発行される。次に、処理がステップＳＰ２３６に進むと、端末識別番号IDbに対するキャッシュバックデータが消去される。一方、プレイヤー１０４においては、ステップＳＰ２０４において購入ポイントの発行を受けたか否かが判定され、購入ポイントの発行を受けた場合には処理はステップＳＰ２０６に進み、該購入ポイントがチャージされる。具体的には、暗号化された購入ポイント金額がフラッシュメモリ４内の所定領域に記録される。
【００５６】
次に、携帯型音楽プレイヤー１０４において処理がステップＳＰ２０８に進むと、サンプル楽曲ファイルの曲名等のリストがディスプレイ１８に表示される。そして、プレイヤー１０４のユーザは、この中から購入する楽曲ファイルを選択することができる。また、該ユーザは、サンプル楽曲ファイルとは無関係に楽曲ファイルを購入する場合もある。かかる場合は、キオスク端末に設けられたディスプレイおよびキーボード等を介して楽曲ファイルが選択されることになる（ステップＳＰ２３８）。
【００５７】
ここで、ユーザが携帯型音楽プレイヤー１０４において何れかのサンプル楽曲ファイルに対応する楽曲ファイルを購入する操作を行った場合は、プレイヤー１０４において処理がステップＳＰ２１０に進み、当該楽曲ファイルの楽曲ＩＤと、該サンプル楽曲ファイルを作成したプレイヤー１０２の端末識別番号IDaとが配信サーバ１００に対して通知される。ユーザが何れの操作を行った場合においても、配信サーバ１００においては処理がステップＳＰ２４０に進み、販売する楽曲ファイルが特定される。次に、処理がステップＳＰ２４２に進むと、該楽曲ファイルがパケットに変換され、プレイヤー１０４に対して送信される。これに対して、プレイヤー１０４においては処理はステップＳＰ２１２に進み、該楽曲ファイルのパケットが復元される。
【００５８】
次に、処理がステップＳＰ２１４に進むと、復元された楽曲ファイルに対応するサンプル楽曲ファイルが削除される。なお、楽曲ファイルがサンプル楽曲ファイルとは無関係に購入されたものである場合には、対応するサンプル楽曲ファイルはそもそも存在しないから、ステップＳＰ２１４において削除されるファイルは無い。次に、配信サーバ１００において処理がステップＳＰ２４４に進むと、購入ポイントの消費額がプレイヤー１０４に通知される。これを受けて、プレイヤー１０４においては処理はステップＳＰ２１６に進み、通知された消費額だけ購入ポイントがディスチャージされる。なお、プレイヤー１０４にチャージされている購入ポイントが楽曲ファイルを購入する金額に満たない場合には、その旨を報告するとともに購入ポイントのチャージ（入金）を促すメッセージがプレイヤー１０４に送信され、そのディスプレイ１８に表示される。
【００５９】
次に、プレイヤー１０４において処理がステップＳＰ２１８に進むと、楽曲データの取得が完了した旨のメッセージとともに、楽曲データの購入を終了させるか否かの問合せメッセージがディスプレイ１８に表示される。次に、処理がステップＳＰ２２０に進むと、楽曲データの購入を終了させるか否かの指示が入力されるまで処理が待機する。ここで、ユーザによって「終了させない」旨の指示が入力されると、処理はステップＳＰ２０８に戻り、次に購入する楽曲ファイルに関して、上述したステップＳＰ２０８〜ＳＰ２１８と同様の処理が実行される。
【００６０】
そして、ステップＳＰ２２０において「終了させる」旨の指示が入力されると、携帯型音楽プレイヤー１０４とキオスク端末との間のコネクションが切断される。次に、処理がステップＳＰ２２２に進むと、検索フラグSEARCHが“true”に設定され他ノード探索が再開される。次に、処理がステップＳＰ２２４に進むと、プレイヤー１０４の状態が待ち受け状態に移行し、本ルーチンの処理が終了する。
【００６１】
一方、配信サーバ１００において処理がステップＳＰ２４６に進むと、上記ステップＳＰ２１０，ＳＰ２４０において通知された端末識別番号IDaのレコードが読み出される。次に、処理がステップＳＰ２４８に進むと、該端末識別番号IDaのユーザに対してキャッシュバックデータが追加される。これにより、次に端末識別番号IDaの携帯型音楽プレイヤー１０２において楽曲データを購入しようとすると、上記ステップＳＰ２０４，２０６において述べたように、携帯型音楽プレイヤー１０２に対して購入ポイントがチャージされる。なお、上記ステップＳＰ２４０経由で楽曲データが購入された場合には配信サーバ１００には端末識別番号IDaは通知されないため、ステップＳＰ２４６およびＳＰ２４８の処理はスキップされる。そして、処理がステップＳＰ２５０に進むと、配信サーバ１００側においてもコネクションが切断され、キオスク端末が待ち受け状態に移行する。
【００６２】
3．第２実施例
3．1．ハードウエア構成
次に本発明の第２実施例について説明する。上記第１実施例においては、サンプル楽曲データとしてはＭＰ３形式で圧縮された楽曲データを使用したが、サンプル楽曲データは短い区間の楽曲データであるため、非圧縮のＰＣＭデータを用いたとしてもハードディスク２２の容量をそれほど圧迫することはない。また、第１実施例では携帯型音楽プレイヤーにＭＰ３形式の楽曲データをエンコードする機能を必要としたが、この機能を省略できれば装置のコストダウンを図ることができる。かかる観点により、第２実施例においては、非圧縮のＰＣＭデータによってサンプル楽曲データを生成しようとするものである。すなわち、サンプル楽曲データを提供するプレイヤーにおいては、非圧縮音声データが繰り返し送信され、受信する側のプレイヤーにおいては、該非圧縮音声データが繰り返し受信されることになる。両者の通信には、例えばブルートゥースのＳＣＯリンクが用いられる。
【００６３】
第２実施例における配信サーバ１００および携帯型音楽プレイヤー１０２，１０４のハードウエア構成は第１実施例のものとほぼ同様であるが、第１実施例のＣＯＤＥＣ８に代えて、図１１に示すＣＯＤＥＣ３００が用いられる。図１１において３０２はキャッシュメモリ８８を制御するためのキャッシュ制御回路であり、ＣＰＵ２からのセンドフラグSEND1が“true”になると、キャッシュメモリ８８の内容を無線インタフェース１４に供給する。また、キャッシュ制御回路３０２は、キャッシュメモリ８８の状態として、以下のうち何れかのキャッシュステータスSTATEをＣＰＵ２に対して返信する。
（１）NO PLAY：キャッシュメモリ８８にデータが記憶されていない状態。
（２）READY：サンプル楽曲データを作成中の状態。
（３）STAND BY：サンプル楽曲データが完成し、送信可能になっている状態。
【００６４】
また、３０４はキャッシュメモリ３１０を制御するためのキャッシュ制御回路であり、ＣＰＵ２からのセンドフラグSEND2が“true”になると、キャッシュメモリ３１０の内容、すなわちオリジナルタグ情報TAGs、端末識別番号IDaおよびサンプル楽曲データ生成時刻TIMEを無線インタフェース１４に供給する。３０６，３０８はキャッシュメモリであり、無線インタフェース１４が他ノードから楽曲データを受信したときに該楽曲データの内容を記憶する。すなわち、キャッシュメモリ３０６には圧縮または非圧縮音声データを記憶し、キャッシュメモリ３０８はタグ情報を記憶する。
【００６５】
また、第１実施例におけるハードディスク２２のメモリマップ（図３）と比較して、本実施例においてはサンプル楽曲ファイル６２の構成が異なる。すなわち、本実施例においては、サンプル楽曲ファイル６２はタグ情報６４のみから構成され、サンプル楽曲ファイル６２には圧縮音声データ６６は含まれない。なお、タグ情報６４自体の内容は第１実施例のものと同様である。
【００６６】
3．2．第２実施例の動作
3．2．1．プレイ・ストップイベント処理（図１２）
次に、本実施例の動作について説明する。本実施例における各ルーチンは、特に断らない限り第１実施例の各ルーチンと同様である。従って、両実施例の異なる点につき以下説明する。まず、本実施例のプレイ・ストップイベント処理ルーチンを図１２を参照し説明する。本ルーチンは第１実施例の対応するルーチン（図６）のステップＳＰ３０およびＳＰ３４に代えて、ステップＳＰ３０２およびＳＰ３０４が各々実行される。まず、ＳＰ３０２は、キャッシュステータスSTATEがSTAND BY状態になるまで処理が待機する点を除いて第１実施例のステップＳＰ３０と同様である。
【００６７】
本実施例においては、圧縮音声データを生成することなく非圧縮音声データをそのまま他の携帯型音楽プレイヤーに送信するものであり、各プレイヤーのサンプリング周波数は同一であるから、キャッシュメモリ８８に僅かなサンプルが蓄積されると、直ちにサンプル楽曲データの送信を開始することができる。すなわち、キャッシュメモリ８８には、送信のための読出し速度と同一速度で新たなサンプルが順次追加されてゆくから、キャッシュメモリ８８に非圧縮音声データが途中までしか記憶されていない場合であっても送信を開始することができる。従って、プレイ・ストップイベントが発生した後にキャッシュステータスSTATEはきわめて短い時間内にSTAND BY状態になるため、かかる状態になるまで処理を待機させたのである。また、サンプル楽曲データを送信するにあたっては、キャッシュメモリ８８，３１０の双方が使用されるから、ステップＳＰ３０４においては、この双方のキャッシュメモリがクリアされる。
【００６８】
3．2．2．サンプル再生タイマ割込処理（図１３）
次に、本実施例のサンプル再生タイマ割込処理ルーチンを図１３を参照し説明する。本ルーチンは第１実施例の対応するルーチン（図７(b)）のステップＳＰ８４およびＳＰ８６に代えて、ステップＳＰ３１４およびＳＰ３１６が各々実行される。まず、ＳＰ３１４においては、キャッシュメモリ８８の末端に数秒の無音区間が追加される。これは、本実施例においては携帯型音楽プレイヤー１０２からプレイヤー１０４に対して同一の非圧縮音声データが繰り返し送信されるため、各繰り返しの切れ目を解り易くするためである。また、ステップＳＰ３１６においてはリクエストフラグREQが“false”に設定される。但し、キャッシュステータスSTATEがSTAND BY状態に遷移したことは既に上記ステップＳＰ３０２において確認されているため、このステップＳＰ３１６ではキャッシュステータスSTATEの確認は行われない。
【００６９】
3．2．3．提供処理および提供リクエスト処理（図１４）
次に、本実施例の提供処理および提供リクエスト処理ルーチンを図１４を参照し説明する。本ルーチンは第１実施例の対応するルーチン（図９）と比較すると、プレイヤー１０２のステップＳＰ１５４以降およびプレイヤー１０４のステップＳＰ１８２以降の処理内容が異なる。まず、サンプル楽曲データを提供するプレイヤー１０２においては、ステップＳＰ１５４の処理が終了した後、プレイヤー１０４から転送要求を受信すると、処理はステップＳＰ３２４に進み、センドフラグSEND1，SEND2が共に“true”に設定される。次に、プレイヤー１０２においては、ステップＳＰ３３２以下およびＳＰ３２６以下の処理が並列に実行される。
【００７０】
まず、ステップＳＰ３３２においては、キャッシュメモリ８８に記憶された非圧縮音声データがプレイヤー１０４に対して繰り返し送信される。また、ステップＳＰ３２６においては、キャッシュメモリ３１０内のタグ情報がキャッシュ制御回路３０４においてパケット化され、無線インタフェース１４を介してプレイヤー１０４に送信される。このタグ情報は「１」回送信すればよいため、タグ情報の送信が終了すると処理はステップＳＰ３２８に進み、センドフラグSEND2が“false”に設定される。
【００７１】
一方、サンプル楽曲データの提供を受けるプレイヤー１０４においては、ステップＳＰ１８２の転送要求処理が終了すると、プレイヤー１０２からタグ情報または非圧縮音声データが提供されるまで処理が待機する。そして、プレイヤー１０２からタグ情報が受信されると、処理はステップＳＰ３４２に進み、タグ情報に係るパケットが復元される。次に、処理がステップＳＰ３４４に進むと、復元された内容（すなわちオリジナルタグ情報TAGs、端末識別番号IDaおよびサンプル楽曲データ生成時刻TIME）と、プレイヤー１０４内のクロックの現在時刻（取得時刻７２）とに基づいて、タグ情報６４が生成されハードディスク２２に記憶される。
【００７２】
また、プレイヤー１０４において非圧縮音声データが受信されると、処理はステップＳＰ３４０に進み、受信した非圧縮音声データが再生される。上述したように、プレイヤー１０２においては非圧縮音声データが繰り返し送信されるから、プレイヤー１０２，１０４間のコネクションが確立している限り、プレイヤー１０４においては該非圧縮音声データが繰り返し再生されることになる。
【００７３】
ここで、プレイヤー１０２，１０４間のコネクションが切断されると、プレイヤー１０２においてはステップＳＰ３３４およびＳＰ３３０の処理が実行され、センドフラグSEND1が“false”に設定されるとともに、プレイヤー１０２の状態が待ち受け状態に移行し、提供処理が終了する。一方、プレイヤー１０４においては、コネクションが切断されると処理はステップＳＰ３４６に進み、プレイヤー１０４の状態が待ち受け状態に移行し、提供リクエスト処理が終了する。
【００７４】
4．変形例
本発明は上述した実施例に限定されるものではなく、例えば以下のように種々の変形が可能である。
(1)上記各実施例においては楽曲ファイルの形式としてＭＰ３形式を採用したが、ファイル形式はＭＰ３以外の他の圧縮音声データ形式であってもよい。また、楽曲データを保存する媒体はハードディスクに限らず、フラッシュメモリ等の半導体記憶素子やＭＯ、ＭＤ等の光磁気記録媒体やＣＤやＤＶＤなどの相転移型の光記録媒体でもよい。また、各ノード間の通信方式はブルートゥース★に限られるものではなく、双方向にディジタルデータの交換が可能な他の無線通信方式であってもよい。
【００７５】
(2)上記各実施例においては、ステップＳＰ２３０〜ＳＰ２５０（図１０）の処理を配信サーバ１００において実行したが、これらの処理のうち一部をキオスク端末に委任することにより、該キオスク端末において一部の処理を実行してもよい。
【００７６】
(3)上記各実施例においては、楽曲データの再生開始後に全サンプル生成時間MAX_LENに基づいてサンプル楽曲データを生成したが、サンプル楽曲データを生成する期間は元々の楽曲データ内の他の区間にしてもよい。例えば、楽曲データの「サビ」の部分をサンプル楽曲データにしてもよい。この場合は、「サビ」の部分の開始時刻および終了時刻を楽曲ファイル５４のタグ情報５６として含めておき、これに応じてリクエストフラグREQの値を設定するとよい。また、元々の楽曲データのサンプリング周波数よりもサンプル楽曲データのサンプリング周波数を低くしておいてもよい。例えば、元々のサンプリング周波数が「４４ｋＨｚ」であった場合にはサンプル楽曲データのサンプリング周波数を「２２ｋＨｚ」にしてもよい。
【００７７】
(4)上記第１実施例においては、ＣＯＤＥＣ８内のデコーダ８０によって楽曲ファイル内の圧縮音声データ５８，６６をデコードし、その結果をさらにエンコーダ９０によってエンコードすることによってサンプル楽曲データ用の圧縮音声データを生成した。しかし、再生対象の楽曲ファイルに含まれる圧縮音声データの一部を直接切り出すことによってサンプル楽曲データ用の圧縮音声データを生成するようにしてもよい。
【００７８】
(5)また、上記各実施例において、サンプル楽曲データを取得した携帯型音楽プレイヤーにおいては、所定時間（数分程度）は他のサンプル楽曲データの取得を行わないようにしてもよい。これは、同一の携帯型音楽プレイヤーに対して何回もアクセスすることを防止するためである。複数の携帯型音楽プレイヤーとのコネクションを同時に確立しておき、ユーザの指示に応じてサンプル楽曲データを取得する相手側ノードを切り替えるようにしてもよい。なお、通信プロトコルとしてブルートゥース★を使用する場合には、最大「７」台の他のノードとコネクションを確立することができる。
【００７９】
(6)また、上記各実施例においては、楽曲データの非再生時に各プレイヤーが自動的に他ノードを探索したが、他ノードの探索はユーザから明示的に指示を受けた場合にのみ実行するようにしてもよい。また、サンプル楽曲データには生成時刻７０および取得時刻７２が記録されているが、何れかの時刻から所定の時間（例えば１週間）が経過したときに該サンプル楽曲データを自動的に削除するようにしてもよい。
【００８０】
(7)また、上記各実施例においては、プリペイド方式の購入ポイントにより楽曲ファイルの購入を行ったが、キオスク端末に直接現金を投入する方式でもよいし、クレジット情報を事前に登録しておきクレジット決済を行ってもよい。この場合キャッシュバックの設定に応じて新規購入楽曲データの購入金額に対して割引を行えばよい。 
【００８１】
(8)また、上記各実施例においては、サンプル楽曲データとして元の楽曲データの一部分を提供するようにしたが、携帯音楽プレイヤーにおいて再生される楽曲データをＤＲＭ（ディジタル著作権管理）技術により再生内容（例えば再生時間あるいは再生区間）制限された楽曲データとし、有償の楽曲データをそのまま提供するようにしてもよい。この場合、サンプル楽曲データの提供を受けた側はキオスク端末からＤＲＭ技術による再生制限を解除するための鍵データを購入乃至ダウンロードするようにすればよい。 
【００８２】
(9)また、上記各実施例においては、各携帯型音楽プレイヤーに対する課金処理はキオスク端末を介するものであったが、課金処理はこれに限られるものではない。例えば、携帯電話における有料サービスの課金態様の如く、携帯型音楽プレイヤーが課金システムサーバと直接的に交信を行って決済を行うようにしてもよい。この場合、正規の楽曲データ又は上記鍵データもあわせて課金システムサーバ（または他のサーバ）との交信によりダウンロードするようにしてもよい。 
【００８３】
(10)上記各実施例においては、配信サーバ１００あるいは携帯型音楽プレイヤー上で動作するプログラムによって各種処理を実行したが、これらのプログラムのみをＣＤ−ＲＯＭ、フレキシブルディスク等の記録媒体に格納して頒布し、あるいは伝送路を通じて頒布してもよい。
【図面の簡単な説明】
【００８４】
【図１】本発明の第１実施例の動作説明図である。
【図２】第１実施例の携帯型音楽プレイヤーおよび配信サーバ１００のブロック図である。
【図３】第１実施例のハードディスク２２のメモリマップである。
【図４】第１実施例のＣＯＤＥＣ８のブロック図である。
【図５】第１実施例のメインルーチンのフローチャートである。
【図６】第１実施例のプレイ・ストップイベント処理ルーチンのフローチャートである。
【図７】第１実施例の各種割込処理ルーチンのフローチャートである。
【図８】第１実施例の他ノード探索割込処理ルーチンおよびリクエスト受信処理ルーチンのフローチャートである。
【図９】第１実施例の提供処理および提供リクエスト処理ルーチンのフローチャートである。
【図１０】第１実施例のサイトアクセスルーチンのフローチャートである。
【図１１】第２実施例のＣＯＤＥＣ３００のブロック図である。
【図１２】第２実施例のプレイ・ストップイベント処理ルーチンのフローチャートである。
【図１３】第２実施例のサンプル再生タイマ割込処理ルーチンのフローチャートである。
【図１４】第２実施例の提供処理および提供リクエスト処理ルーチンのフローチャートである。
【符号の説明】
【００８５】
２：ＣＰＵ（処理装置）、１００：（配信装置）、４：フラッシュメモリ、６：ＲＡＭ、８：ＣＯＤＥＣ（再生手段）、１０：サウンドシステム、１２：ヘッドホン、１４：無線インタフェース（音声データ送信手段，楽曲提供要求送信手段，楽曲データ識別情報送信手段，楽曲データ受信手段）、１６：バス、１８：ディスプレイ、２０：操作部、２０ａ：プレイ・ストップボタン、２２：ハードディスク（楽曲データ記憶手段，音声データ記憶手段）、２３：ＲＯＭ、２４：その他インタフェース、３２：ハードディスク、３４：ディスプレイ、３６：入力装置、３８：バス、４０：通信インタフェース、４２：ＣＰＵ、４４：ＲＯＭ、４６：ＲＡＭ、５０：ファイル管理テーブル領域、５２：楽曲ファイルエリア、５４，６２：楽曲ファイル、５６：タグ情報、５８，６６：圧縮音声データ、６０：サンプル楽曲ファイルエリア、６２：サンプル楽曲ファイル、６４：タグ情報、６８：オリジナルタグ情報、７０：生成時刻、７２：取得時刻、７４：提供元情報、７６：その他情報、８０：デコーダ、８２：ＦＩＦＯバッファ、８４：アンド回路、８６：増幅部、８８，９２：キャッシュメモリ、９０：エンコーダ、９４：キャッシュ制御回路、９６：キャッシュメモリ、１００：配信サーバ、１０２，１０４：携帯型音楽プレイヤー、３００：ＣＯＤＥＣ、３０２，３０４：キャッシュ制御回路、３０６，３０８，３１０：キャッシュメモリ（音声データ記憶手段）。
【図１】
2006267763.tif 000003
【図２】
2006267763.tif 000004
【図３】
2006267763.tif 000005
【図４】
2006267763.tif 000006
【図５】
2006267763.tif 000007
【図６】
2006267763.tif 000008
【図７】
2006267763.tif 000009
【図８】
2006267763.tif 000010
【図９】
2006267763.tif 000011
【図１０】
2006267763.tif 000012
【図１１】
2006267763.tif 000013
【図１２】
2006267763.tif 000014
【図１３】
2006267763.tif 000015
【図１４】
2006267763.tif 000016