JP2002055687A - 音楽ファイル送受信システム - Google Patents

Abstract

(57)【要約】 【課題】確実かつ短時間に音楽ファイルの内容を確認す
ることができる音楽ファイル送受信システムの提供。 【解決手段】 このような状況において、ユーザーＸ
は端末コンピュータ２３を利用して、音楽ファイルサー
バ２５に対して曲名「xxx」の楽曲のサビファイルを送
るように要求する。要求を受けた音楽ファイルサーバ
２５は、曲名「xxx」の楽曲の音楽ファイルからサビ部
分のみを抽出し当該楽曲のサビファイルを生成する。
音楽ファイルサーバ２５は、生成したサビファイルを端
末コンピュータ２３へ送信する。端末コンピュータ２
３で受信したサビファイルを再生する。これにより、
ユーザーＸは曲名「xxx」の楽曲が希望する楽曲である
か否かを容易に判断することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、音楽ファイルの送
受信に関するものであり、特に音楽ファイルの一部を送
信するものに関する。

【０００２】

【従来の技術】現在、ネットワーク、特にインターネッ
トを介した音楽配信が行われている。このようなネット
ワークを介した音楽配信は次のようにして行われてい
る。

【０００３】まず、音楽ファイルをダウンロードしよう
とするユーザーは、目的とする音楽ファイルが、どの場
所（例えば、URLやサイト名）に存在するのかを知る必
要がある。音楽ファイルが存在する場所を知るために
は、音楽ファイル専用サーチエンジンや音楽専門誌等を
活用することが一般的である。つまり、楽曲名やアーテ
ィスト名等の楽曲に関する書誌的事項から、目的とする
楽曲の音楽ファイルが存在する場所を検索する。

【０００４】目的とする音楽ファイルが存在する場所が
分かれば、その場所にアクセスし、音楽ファイルをコン
ピュータやデジタル音楽再生装置（例えば、mp3再生装
置）等にダウンロードする。そして、ダウンロードした
音楽ファイルをコンピュータおよびデジタル音楽再生装
置で再生して楽しむ。

【０００５】

【発明が解決しようとする課題】しかし、前記音楽配信
方法には、次のような問題点がある。ユーザはダウンロ
ードを希望する曲の書誌的事項を知らない場合がある。
このような場合には、試行錯誤で希望する曲を探し出す
しかなく、時間的にも手続き的にも無駄が生ずる。

【０００６】そこで、本発明は、書誌的事項が不明確で
あっても、確実かつ短時間に音楽ファイルの内容を確認
することができる音楽ファイル送受信システムを提供す
ることを目的とする。

【０００７】

【課題を解決するための手段および発明の効果】（１）
本発明にかかる音楽ファイル送受信システムでは、ネッ
トワークを介して接続された第１の通信装置と第２の通
信装置との間で、時間の経過にともなう音の連続的な変
化を記録した音楽ファイルのやりとりを行う音楽ファイ
ル送受信システムにおいて、第２の通信装置は、音楽フ
ァイルと、音楽ファイルの一部であって、当該音楽ファ
イルの内容の特徴的部分である特徴音楽ファイルを音楽
ファイルから特定する特定情報と、を有しており、第１
の通信装置が、特徴音楽ファイルを要求する要求信号を
送信し、第２の通信装置が当該要求信号を受信すると、
第２の通信装置は、特定情報に基づいて、音楽ファイル
から特徴音楽ファイルを生成し、第１の通信装置へ送信
する。

【０００８】これにより、音楽ファイルの書誌的事項が
明確には分からない場合であっても、当該音楽ファイル
の内容の特徴的部分が分かれば、確実かつ短時間に音楽
ファイルの内容を確認することができる。

【０００９】また、第２の通信装置において、特徴音楽
ファイルを予め生成し、有しておく必要がないので、第
２の通信装置の記憶容量を有効に利用することができ
る。

【００１０】さらに、第２の通信装置は、第１の通信装
置に対して、音楽ファイルの特徴的部分である特徴音楽
ファイルを送信する。したがって、通信量を減少させる
ことができ、ひいては通信回線の効率利用を図ることが
できる。

【００１１】（２）本発明にかかる音楽ファイル送受信
システムでは、特徴音楽ファイルは、音楽ファイルのサ
ビ部分によって構成されている。これにより、音楽ファ
イルの内容の確認をサビ部分によって行うことができ
る。したがって、確実かつ短時間に音楽ファイルの内容
を確認することができる。

【００１２】（３）本発明にかかる音楽ファイル送信装
置では、ネットワークを介して接続された他の通信装置
に対して、時間の経過にともなう音の連続的な変化を記
録した音楽ファイルの送信を行う音楽ファイル送信装置
において、音楽ファイルと、音楽ファイルの一部であっ
て、当該音楽ファイルの内容の特徴的部分である特徴音
楽ファイルを音楽ファイルから特定する特定情報と、を
有しており、他の通信装置からの特徴音楽ファイルを要
求する要求信号を受信すると、特定情報に基づいて、音
楽ファイルから特徴音楽ファイルを生成し、他の通信装
置へ送信する。

【００１３】これにより、音楽ファイルの書誌的事項が
明確には分からない場合であっても、当該音楽ファイル
の内容の特徴的部分が分かれば、確実かつ短時間に音楽
ファイルの内容を確認することができる。

【００１４】また、特徴音楽ファイルを予め生成し、有
しておく必要がないので、当該音楽ファイル送信装置の
記憶容量を有効に利用することができる。

【００１５】さらに、当該音楽ファイル送信装置は、音
楽ファイルの特徴的部分である特徴音楽ファイルを送信
する。したがって、通信量を減少させることができ、ひ
いては通信回線の効率利用を図ることができる。

【００１６】（４）本発明にかかる記録媒体は、他の通
信装置から送られてきたデータを再生する処理をコンピ
ュータに実行させるプログラムを記録した記録媒体であ
って、当該プログラムは、画面上に特徴音楽ファイル獲
得ボタンを表示し、特徴音楽ファイル獲得ボタンが選択
されると、他の通信装置に対して要求信号を発信し、当
該要求信号に基づき他の通信装置から送られてきたデー
タを、音楽ファイルの一部であって、当該音楽ファイル
の内容の特徴的部分である特徴音楽ファイルとして再生
する処理をコンピュータに実行させるためのプログラム
である。

【００１７】これにより、特徴音楽ファイルを容易に再
生することができる。したがって、確実かつ短時間に音
楽ファイルの内容を確認することができる。

【００１８】（５）本発明にかかる時系データ簡易確認
方法は、人間の感覚で判断できる特徴量の大きさが時間
の経過にともない連続して変化する時系データを記録し
たファイルを確認する時系データ簡易確認方法におい
て、時系データと、時系データの一部であって、当該時
系データの内容の特徴的部分である特徴時系データを時
系データから特定する特定情報と、が記録されており、
特徴時系データを要求すると、特定情報に基づいて、時
系データから特徴時系データを生成し、生成した特徴時
系データを確認させるために出力すること、を特徴とす
る。

【００１９】これにより、特徴時系データから、対応す
る時系データの内容を、確実かつ短時間に確認すること
ができる。

【００２０】ここで、請求項の構成要素と実施形態の構
成要素との対応関係について説明する。第１の通信装置
は端末コンピュータ２３およびストリームデータ再生装
置１０００に、第２の通信装置は音楽ファイルサーバ２
５およびサーバ１００に、音楽ファイルはオリジナルフ
ァイルに、特徴音楽ファイルはサビ抜きファイルに、特
定情報はサビ部分特定情報に、要求信号はサビ抜きファ
イル要求信号に、特徴音楽ファイル獲得ボタンはサビボ
タンＢ３ａ、Ｂ３ｂ、Ｂ３ｃに、時系データはオリジナ
ルファイルに、特徴時系データはサビ抜きファイルに、
それぞれ対応する。

【００２１】

【発明の実施の形態】［第１の実施形態］ １．機能ブロック図 本発明にかかる音楽ファイル送受信システムの第１の実
施形態における機能ブロック図を図１に示す。音楽ファ
イル送受信システム１は、第１の通信装置３および第２
の通信装置５を有している。

【００２２】音楽ファイル送受信システム１は、ネット
ワークを介して接続された第１の通信装置３と第２の通
信装置５との間で、時間の経過にともなう音の連続的な
変化を記録した音楽ファイルのやりとりを行う音楽ファ
イル送受信システムである。

【００２３】また、第２の通信装置５は、音楽ファイル
と、音楽ファイルの一部であって、当該音楽ファイルの
内容の特徴的部分である特徴音楽ファイルを音楽ファイ
ルから特定する特定情報と、を有している。

【００２４】さらに、音楽ファイル送受信システム１で
は、第１の通信装置３が、特徴音楽ファイルを要求する
要求信号を送信し、第２の通信装置５が当該要求信号を
受信すると、第２の通信装置５は、特定情報に基づい
て、音楽ファイルから特徴音楽ファイルを生成し、第１
の通信装置３へ送信する。

【００２５】さらに、第２の通信装置が生成する特徴音
楽ファイルは、音楽ファイルのサビ部分によって構成さ
れている。

【００２６】さらに、第１の通信装置３は、第２の通信
装置５から送られてきたデータを再生する処理をコンピ
ュータに実行させるプログラムに基づいて稼働してい
る。なお、このプログラムは、画面上に特徴音楽ファイ
ル獲得ボタンを表示し、特徴音楽ファイル獲得ボタンが
選択されると、他の通信装置に対して要求信号を発信
し、当該要求信号に基づき他の通信装置から送られてき
たデータを、音楽ファイルの一部であって、当該音楽フ
ァイルの内容の特徴的部分である特徴音楽ファイルとし
て再生する処理をコンピュータに実行させるものであ
る。

【００２７】これにより、確実かつ短時間に音楽ファイ
ルの内容を確認することができる音楽ファイル送受信シ
ステムを提供することができる。

【００２８】２．音楽ファイル送受信システム１の概要 音楽ファイル送受信システム１の概要を図２に示す。音
楽ファイル送受信システム１は、第１の通信装置である
端末コンピュータ２３および第２の通信装置である音楽
ファイルサーバ２５を有している。また、端末コンピュ
ータ２３と音楽ファイルサーバ２５とは、ネットワーク
であるインターネットを介して接続されている。

【００２９】ここでは、以下の状況下で、ユーザＸが
音楽ファイル送受信システム１を利用する場合について
説明する。ユーザＸが、あるコマーシャルにおいて使用
されている楽曲Ａが気に入り、楽曲Ａをインターネット
を利用してダウンロードしようと考えた。しかし、ユー
ザーＸは楽曲Ａのサビ部分は知っているが、その曲名や
歌手名が分からない。ユーザーＸは、インターネット検
索等を利用し、その結果、「前記サビ部分を有する楽曲
Ａの曲名が「xxx」であるらしい」という情報およびそ
の推測した楽曲のインターネット上の存在アドレスを入
手した。

【００３０】このような状況において、ユーザーＸは
端末コンピュータ２３を利用して、音楽ファイルサーバ
２５に対して曲名「xxx」の楽曲のサビファイルを送る
ように要求する。

【００３１】要求を受けた音楽ファイルサーバ２５
は、曲名「xxx」の楽曲の音楽ファイルからサビ部分の
みを抽出し当該楽曲のサビファイルを生成する。

【００３２】音楽ファイルサーバ２５は、生成したサ
ビファイルを端末コンピュータ２３へ送信する。

【００３３】端末コンピュータ２３で受信したサビフ
ァイルを再生する。

【００３４】これにより、ユーザーＸは曲名「xxx」
の楽曲が希望する楽曲であるか否かを容易に判断するこ
とができる。

【００３５】受信したサビファイルを再生した結果、
希望する楽曲であると確認できたときは、この楽曲の全
データを送信するように要求する。

【００３６】音楽ファイルサーバ２５は、曲名「xx
x」の楽曲の音楽ファイルを端末コンピュータ２３へ送
信する。

【００３７】このように、音楽ファイルサーバ２５が端
末コンピュータ２３に曲名「xxx」の楽曲の音楽ファイ
ルを全て送信する前に、曲名「xxx」の楽曲のサビファ
イルのみを送信して、ユーザーＸが当該サビ部分を確認
することによって、曲名「xxx」の楽曲の全データをダ
ウンロードすることなく、当該楽曲が所望の楽曲である
か否かを容易かつ正確に判断することができる。

【００３８】３．ハードウェア構成 次に、端末コンピュータ２３および音楽ファイルサーバ
２５のハードウェア構成を図３および図４に基づいて説
明する。

【００３９】図３に端末コンピュータ２３のハードウェ
ア構成を示す。端末コンピュータ２３は、ＣＰＵ２３
ａ、メモリ２３ｂ、ハードディスクドライブ２３ｃ（以
下、ＨＤＤ２３ｃとする。）、送受信回路２３ｄ、ＣＤ
−ＲＯＭドライブ２３ｅ、キーボード２３ｆ、マウス２
３ｇ、ディスプレイ２３ｈ、Ｄ／Ａ変換部２３ｉ、増幅
器２３ｊおよびスピーカ２３ｋを有している。

【００４０】ＣＰＵ２３ａは、ＨＤＤ２３ｃに記憶され
ている端末コンピュータ用プログラムに基づいて、各部
の動作を制御する。この端末コンピュータ用プログラム
は、ＣＤ−ＲＯＭドライブ２３ｅを介して、ＣＤ−ＲＯ
Ｍ等の記録媒体から端末コンピュータ２３へインストー
ルしたものである。なお、端末コンピュータ用プログラ
ムは、通信回線を用いてダウンロードし、端末コンピュ
ータ２３へインストールするようにしてもよい。

【００４１】図４に音楽ファイルサーバ２５のハードウ
ェア構成を示す。音楽ファイルサーバ２５は、ＣＰＵ２
５ａ、メモリ２５ｂ、ハードディスクドライブ２５ｃ
（以下、ＨＤＤ２５ｃとする。）、送受信回路２５ｄ、
ＣＤ−ＲＯＭドライブ２５ｅ、キーボード２５ｆ、マウ
ス２５ｇ、およびディスプレイ２５ｈを有している。

【００４２】ＣＰＵ２５ａは、ＨＤＤ２５ｃに記憶され
ている音楽ファイルサーバ用プログラムに基づいて、各
部の動作を制御する。この音楽ファイルサーバ用プログ
ラムは、ＣＤ−ＲＯＭドライブ２５ｅを介して、ＣＤ−
ＲＯＭ等の記録媒体から音楽ファイルサーバ２５へイン
ストールしたものである。なお、音楽ファイルサーバ用
プログラムは、通信回線を用いてダウンロードし、音楽
ファイルサーバ２５へインストールするようにしてもよ
い。

【００４３】本実施形態においては、端末コンピュータ
用プログラムおよび音楽ファイルサーバ用プログラムを
ＣＤ−ＲＯＭから端末コンピュータ２３および音楽ファ
イルサーバ２５へインストールするようにしている。し
かし、ＣＤ−ＲＯＭドライブ２３ｅ、２５ｅを介して、
ＣＤ−ＲＯＭから直接的に各プログラムを実行するよう
にしてもよい。

【００４４】なお、端末コンピュータ用プログラムおよ
び音楽ファイルサーバ用プログラムとしては、インスト
ール即実行可能な形式となっているもの、および、圧縮
等によって他の形式となっており実行可能な形式とする
には変換等の処理が必要なものを含む。また、各プログ
ラム単独で実行可能なもの、および、他のモジュールと
の連携によって実行可能となるものも含む。

【００４５】ＨＤＤ２５ｃには、音楽ファイルおよび音
楽ファイルサビ部分を特定するためのサビ部分特定情報
が記録されている。この音楽ファイルおよびサビ部分特
定情報について、以下において説明する。

【００４６】４．音楽ファイルおよびサビ部分特定情報 音楽ファイルのデータ構造を図５に示す。本実施形態に
おける音楽ファイルは、RIFFフォーマットのウェーブフ
ァイル（以下、WAVファイルとする。）とする。

【００４７】このWAVファイルは、ヘッダ部Ｈ１、音声
データ部Ｄ１およびフッタ部Ｆ１を有している。RIFFフ
ォーマットでは、ヘッダ部Ｈ１に４４バイトが必要であ
る。ヘッダ部Ｈ１には、WAVファイルの全データサイ
ズ、音声データの最後のアドレス等の情報が含まれてい
る。

【００４８】音声データ部Ｄ１には、音声データが記録
されている。WAVファイルの音声データをサンプリング
周波数４４．１ｋＨｚ、１６ｂｉｔのステレオＰＣＭ音
源であるとする。この場合、音声データの単位時間あた
りのデータ量は、４４．１k＊２ch＊２Byte＝１７６４
００Byte/secとなる。今、ある楽曲Ａの演奏時間が５分
であるとすると、この楽曲のWAVファイルにおける音声
データ量は、５２．９２Mバイト（５２９２００００バ
イト）となる。

【００４９】フッタ部Ｆ１は、通常のフッタ情報に加え
て、楽曲のサビ部分を特定するためのサビ部分特定情報
を有している。今、楽曲Ａのサビ部分が再生開始から１
分０秒（アドレス$A17FED）から１分１０秒（アドレス$
BC6A8C）までの１０秒間であったとする。この場合、サ
ビ部分特定情報には、サビ部分の開始アドレス（$A17FE
D）および終了アドレス（$BC6A8C）が含まれる。

【００５０】なお、サビ部分特定情報としては、３２バ
イトが割り当てられる。したがって、今、通常のフッタ
情報に１００バイトが割り当てられているとすると、フ
ッタ部Ｆ１には、１３２バイトが割り当てられることと
なる。

【００５１】したがって、楽曲ＡのWAVファイルの総デ
ータ量（ヘッダ部Ｈ１＋音声データ部Ｄ１＋フッタ部Ｆ
１）は、計５２９２０１７６バイトとなる。

【００５２】このように、本実施形態におけるWAVファ
イルは、フッタ部Ｆ１において、通常のフッタ情報にサ
ビ部分特定情報を付加しただけである。つまり、元々の
WAVファイルには何ら影響を与えることなく、サビ部分
特定情報を付加するだけで簡単に本実施形態におけるWA
Vファイルを生成することができる。

【００５３】次に、前記サビ部分特定情報に基づいて、
生成されるサビ抜きファイルのデータ構造を説明する。
図５におけるサビ部分（アドレス$A17FED〜アドレス$BC
6A8C）の音声データを有するサビ抜きファイルのデータ
構造を、図６に示す。サビ抜きファイルは、ヘッダ部Ｈ
３、サビ部分音声データ部Ｄ３およびフッタ部Ｆ３から
構成されている。

【００５４】ヘッダ部Ｈ３のデータ量は、図５における
音楽ファイルと同様に４４バイトである。図６における
サビ部分音声データ部Ｄ３は、図５におけるサビ部分
（アドレス$A17FED〜アドレス$BC6A8C）の音声データに
よって構成されている。したがって、当該サビ部分音声
データ部Ｄ３のデータ量は１７６４０００バイトとな
る。

【００５５】フッタ部Ｆ３は、サビ抜きファイルを生成
する元となったWAVファイル（以下、オリジナルファイ
ルという。）のインターネット上でのURLを有してい
る。また、オリジナルファイルのダウンロードの際の認
証および課金のためのカギ情報、オリジナルファイルの
ダウンロードの実行もしくは非実行を表すフラグ等の情
報も有している。このため、フッタ部Ｆ３のデータ量
は、２００バイトとしている。

【００５６】５．フローチャート 端末コンピュータ用プログラムおよび音楽ファイルサー
バ用プログラムによる処理を図７に示すフローチャート
に基づいて説明する。なお、以下においては、音声デー
タとして楽曲のサビ部分のみを有しているファイルをサ
ビ抜きファイルと、またサビ抜きファイルの元となった
音楽ファイルをオリジナルファイルと呼ぶこととする。

【００５７】5.1. サビ抜きファイルの要求 本実施形態においては、ユーザーは楽曲に関するオリジ
ナルファイルおよびサビ抜きファイルのダウンロードを
ウェブ上で行うことができる。この際、ユーザーは、端
末コンピュータ用プログラムを起動する。そして、ユー
ザーは、楽曲をダウンロードすることができるサイトの
ＵＲＬを指定する。これにより、端末コンピュータ２３
は、音楽ファイルサーバ２５にアクセス可能となる。

【００５８】音楽ファイルサーバ２５は、所定のデータ
を端末コンピュータ２３へ送信する。このデータを受信
した端末コンピュータ２３のＣＰＵ２３ａは、ディスプ
レイ２３ｈ上に、図８に示すような画面を表示する。

【００５９】ディスプレイには、ダウンロードすること
ができる楽曲名を表示する楽曲名表示部Ａ１、各楽曲の
オリジナルファイル全てをダウンロードすることができ
るまるごとボタンＢ１ａ、Ｂ１ｂ、Ｂ１ｃ・・・および
サビ部分のみによって構成されるサビ抜きファイルをダ
ウンロードすることができるサビボタンＢ３ａ、Ｂ３
ｂ、Ｂ３ｃ・・・が表示される。

【００６０】ここで、ユーザーは、各楽曲のオリジナル
ファイル全てのダウンロードを希望する場合には、各楽
曲に対応した「まるごとボタン」Ｂ１ａ、Ｂ１ｂ、Ｂ１
ｃを選択すればよい。一方、サビ部分のみのダウンロー
ドを希望する場合には、「サビボタン」Ｂ３ａ、Ｂ３
ｂ、Ｂ３ｃを選択すればよい。なお、各ボタンの選択に
は、キーボード２３ｆもしくはマウス２３ｇを使用す
る。

【００６１】端末コンピュータ２３のＣＰＵ２３ａは、
ユーザーからサビ抜きファイルのダウンロード指示があ
ったか否か、つまり「サビボタン」Ｂ３ａ、Ｂ３ｂ、Ｂ
３ｃが選択されたか否かを判断している（図７：Ｓ７０
１）。

【００６２】「サビボタン」Ｂ３ａ、Ｂ３ｂ、Ｂ３ｃの
いずれかが選択されれば、ＣＰＵ２３ａは、ユーザーか
らサビ抜きファイルのダウロード指示があったものと判
断し、サビ抜きファイル要求信号を、音楽ファイルサー
バ２５に対して送信する（Ｓ７０３）。

【００６３】一方、「まるごとボタン」Ｂ１ａ、Ｂ１
ｂ、Ｂ１ｃのいずれかが選択された場合には、ユーザー
からオリジナルファイルのダウロード指示があったもの
と判断し（Ｓ７０２）、通常通り、オリジナルファイル
の受信処理を行う（Ｓ７１７、Ｓ７１９、Ｓ７２１、Ｓ
７２３）。なお、オリジナルファイルの受信処理につい
ては、後述する。

【００６４】5.2. サビ抜きファイルの生成および送信 音楽ファイルサーバ２５は、サビ抜きファイル要求信号
を受信したか否かを判断している（Ｓ７０５）。サビ抜
きファイル要求信号を受信すると、オリジナルファイル
に基づいてサビ抜きファイルの生成を行う（Ｓ７０
７）。サビ抜きファイルの生成処理の詳細フローチャー
トを、図９に示す。

【００６５】音楽ファイルサーバ２５のＣＰＵ２５ａ
は、サビ抜きファイル要求信号を受けると、ＨＤＤ２５
ｃから楽曲Ａのオリジナルファイルを抽出する（図９Ｓ
９０１）。具体的には、楽曲Ａのオリジナルファイルを
メモリ２５ｂに記憶する。

【００６６】そして、ＣＰＵ２５ａは、オリジナルファ
イルのフッタ部Ｆ１をチェックし、サビ部分特定情報が
あるか否かを判断する（Ｓ９０３）。サビ部分特定情報
が存在すれば、ＣＰＵ２５ａはその内容を解析する（Ｓ
９０５）。そして、ＣＰＵ２５ａは、サビ部分特定情報
に基づいて、サビ抜きファイルのフッタ情報、データ情
報およびヘッダ情報を作成する。具体的には、ＣＰＵ２
５ａは、オリジナルファイルからサビ部分を抽出するこ
とにより、サビ部分音声データ部Ｄ３を生成する（Ｓ９
０６）。また、予めハードディスク２５ｃに記憶してい
るオリジナルファイルが存在するアドレスに関する情
報、および課金の際のカギ情報等をフッタ部Ｆ３に付加
することによって、フッタ部Ｆ３を生成する（Ｓ９０
７）。通常通りのヘッダ生成処理を行い、ヘッダ部Ｈ３
を生成する（Ｓ９０８）。

【００６７】そして、ＣＰＵ２５ａは、ヘッダ部Ｈ３、
サビ部分音声データ部Ｄ３およびフッタ部Ｆ３を統合し
て、サビ抜きファイルを生成する（Ｓ９０９）。

【００６８】なお、ステップＳ９０３において、サビ部
分特定情報が存在しなければ、サビ抜きファイルが生成
できない旨のエラーメッセージを表示するためのエラー
メッセージ信号を、ＣＰＵ２５ａは、端末コンピュータ
２３へ送信する処理を行う（Ｓ９１１）。端末コンピュ
ータ２３のＣＰＵ２３ａは、このエラーメッセージ信号
を受信すると、ディスプレイ２３ｈ上にエラーメッセー
ジを表示する。

【００６９】図７ステップＳ７０７の処理が終了する
と、ＣＰＵ２５ａは、生成したサビ抜きファイルを端末
コンピュータ２３へ送信する（図７Ｓ７０９）。

【００７０】端末コンピュータ２３のＣＰＵ２３ａは、
サビ抜きファイルを受信すると（Ｓ７１１）、自動的に
サビ抜きファイルの形式（本実施形態においては、WAV
ファイル）の音楽データを再生するアプリケーションプ
ログラムを起動して、サビ抜きファイルを再生する（Ｓ
７１３）。端末コンピュータ２３のユーザーは、この再
生されたサビを聞くことによって、楽曲Ａが自らが意図
するものであるか否かを判断することができる。

【００７１】5.3 オリジナルファイルのダウンロード サビの再生が終了すると、端末コンピュータ２３のＣＰ
Ｕ２３ａは、オリジナルファイルのダウンロードを行う
か否かの判断処理を行う（Ｓ７１５）。この時、ＣＰＵ
２３ａは、サビ抜きファイルのフッタ部Ｆ３が有する情
報またはプログラムに基づいて、ディスプレイ２３ｈに
図１０に示すような確認ボックスＣ１を表示する。

【００７２】確認ボックスＣ１は、再生したサビファイ
ルのオリジナルファイルのダウンロードを行うことを指
示する「はい」ボタンＢ５およびオリジナルファイルの
ダウンロードを行わないことを指示する「いいえ」ボタ
ンＢ７を有している。

【００７３】ユーザーがオリジナルファイルのダウンロ
ードを希望しない場合には、ユーザーは、キーボード２
３ｆもしくはマウス２３ｇを利用して、「いいえ」ボタ
ンＢ７を選択すればよい。一方、ユーザーがオリジナル
ファイルのダウンロードを希望する場合には、ユーザー
は、「はい」ボタンＢ５を選択すればよい。

【００７４】ＣＰＵ２３ａは、「いいえ」ボタンＢ７が
選択されたと判断した場合には、楽曲のダウンロード処
理を終了する。一方、ＣＰＵ２３ａは、「はい」ボタン
Ｂ５が選択されたと判断した場合には、サビ抜きファイ
ルのフッタ部Ｆ３に存在する課金プログラムにしたがっ
て、課金処理を開始する。

【００７５】この課金処理には、インターネットを介し
た通信販売で利用されているクレジットカードを用いた
代金支払方法を採用している。ＣＰＵ２３ａは、ユーザ
ー名、クレジットカードの番号等のユーザー情報を入力
するためのダイアログを開き、ユーザーから当該ユーザ
ー情報を獲得する。そして、ＣＰＵ２３ａは、これらの
情報に基づいて、課金処理を行う。

【００７６】なお、課金方法としては、一般的にインタ
ーネットで使用されているものであれば、どれを利用し
てもよい。事前に氏名やクレジットカードの番号等を登
録した後、ユーザーＩＤを付与し、課金の際にこのユー
ザーＩＤを利用するようにしてもよい。

【００７７】課金処理が終了すると、ＣＰＵ２３ａは、
オリジナルファイルのダウンロードを示すオリジナルフ
ァイル要求信号を送信する（図７Ｓ７１７）。音楽ファ
イルサーバ２５のＣＰＵ２５ａは、オリジナルファイル
要求信号を受信したか否かを判断している（Ｓ７１
９）。ＣＰＵ２５ａは、オリジナルファイル要求信号を
受信したと判断した場合には、オリジナルファイルの送
信を行う（Ｓ７２１）。

【００７８】端末コンピュータ２３は、オリジナルファ
イルを受信すると（Ｓ７２３）、ＨＤＤ２３ｃ等に保存
する（Ｓ７２５）。

【００７９】６．まとめ このような音楽ファイル送受信システムを利用すること
によって、以下に示すような効果を得ることができる。

【００８０】ネットワーク上から楽曲を検索する際に、
楽曲名やアーティスト名等の書誌的事項が分からず、サ
ビから受ける曲の感じや歌手の声の感じ等から、アーテ
ィスト名や楽曲名等を類推し、検索を行わなければなら
ない場合であっても、容易に目的とする楽曲であるか否
かを判断することができる。

【００８１】さらに、目的とする楽曲に対して自らが有
する情報がコマーシャルで聞いたサビだけである場合で
も、楽曲のサビ部分を聞くことができるので、楽曲が自
らの意図したものであるか否かを容易に判断することが
できる。

【００８２】さらに、サビ抜きファイルはサビ部分によ
って構成されているので、楽曲が自らが意図するもので
あるか否かを容易に判断することができる。

【００８３】特に、テレビ番組のコマーシャル等に使用
された楽曲がヒットする場合が少なくない。かかるコマ
ーシャルでは、楽曲の中で特に印象的な部分（いわゆる
サビ部分）が使用される。このような現状において、コ
マーシャルに使用されている楽曲を気に入った視聴者
は、コマーシャルで聞いたサビを頼りに楽曲を探さなけ
ればならない。このようにユーザが、サビ部分しか知ら
ない場合であっても、無駄なファイルをダウンロードす
ることなく、当該サビ部分を有する楽曲データをダウン
ロードすることができる。

【００８４】［第２の実施形態］ １．ストリームデータ再生システムの概要 前述の第１の実施形態においては、音楽ファイル送受信
システムについて説明したが、このシステムをストリー
ムデータ再生システムに適用することにより、ユーザー
は、サビ部分を聞きながら、気に入ったものがあれば、
その場で購入することができるストリームデータ再生シ
ステムを提供することができる。

【００８５】かかるストリームデータ再生システムの概
要を図１１に示す。サーバ１００およびストリームデー
タ再生装置１０００は、ネットワークを介して接続され
ている。ストリームデータ再生装置１０００のユーザー
は、自らの好みの楽曲等をサーバ１００に登録してお
く。サーバ１００は、ユーザーが登録した情報に基づい
て他のサーバから楽曲を収集し、ストリームデータ再生
装置１０００に対して配信する。

【００８６】２．ハードウェア構成 図１１に示すサーバ１００のハードウェア構成について
図１２を用いて説明する。図１２は、サーバ１００をＣ
ＰＵを用いて実現したハードウェア構成の一例である。

【００８７】サーバ１００は、ＣＰＵ２３０、メモリ２
７０、ハードディスク２６０、ＣＲＴ３００、ＣＤＤ
（ＣＤＲＯＭドライブ）２５０、キーボード２８０、マ
ウス３１０、通信ボード３２０およびバスライン２９０
を備えている。ＣＰＵ２３０は、ハードディスク２６０
に記憶されたプログラムにしたがいバスライン２９０を
介して、各部を制御する。

【００８８】これらのプログラムは、ＣＤＤ２５０を介
して、プログラムが記憶されたＣＤＲＯＭ２５０ａから
読み出されてハードディスク２６０にインストールされ
たものである。なお、ＣＤＲＯＭ以外に、フレキシブル
ディスク（ＦＤ）、ＩＣカード等のプログラムを実体的
に一体化したコンピュータ可読の記録媒体から、ハード
ディスクにインストールさせるようにしてもよい。さら
に、通信回線を用いてダウンロードするようにしてもよ
い。

【００８９】本実施形態においては、プログラムをＣＤ
ＲＯＭからハードディスク２６０にインストールさせる
ことにより、ＣＤＲＯＭに記憶させたプログラムを間接
的にコンピュータに実行させるようにしている。しか
し、これに限定されることなく、ＣＤＲＯＭに記憶させ
たプログラムをＣＤＤ２５０から直接的に実行するよう
にしてもよい。なお、コンピュータによって、実行可能
なプログラムとしては、そのままのインストールするだ
けで直接実行可能なものはもちろん、一旦他の形態等に
変換が必要なもの（例えば、データ圧縮されているもの
を、解凍する等）、さらには、他のモジュール部分と組
合して実行可能なものも含む。

【００９０】ハードディスク２６０には、プログラム記
憶部２６０p、ユーザ別収集条件記憶部２６０k、ユーザ
別ストリームデータ記憶部２６０uおよびストリームサ
ーバ記憶部２６０sを有する。

【００９１】ユーザ別収集条件記憶部２６０kには、各
ユーザが好みの曲をユーザ別ストリームデータ記憶部２
６０uに記憶させておくための選別条件が記憶されてい
る。ユーザ別収集条件記憶部２６０kのデータ構造を図
１４に示す。このように、各ユーザ毎に、カスタマイズ
カテゴリ名、優先順位重み、複数の検索条件（この場
合、検索条件１〜４）および検索処理式１、２が記憶さ
れている。

【００９２】ユーザ別ストリームデータ記憶部２６０u
は、ユーザ毎に所定の記憶容量が割り当てられており、
前記選別条件に合致するユーザ毎の音楽ファイルである
ストリームデータおよび管理データテーブルを記憶す
る。かかるストリームデータおよび管理データテーブル
について、図１５を用いて説明する。本実施形態におい
ては、ストリームデータとして音楽データを採用した。
なお、本実施形態においては、第１の実施形態と同様
に、図５に示す音楽ファイルをストリームデータとして
いる。

【００９３】一方、管理データテーブルは、前記ストリ
ームデータの管理をするデータであり、図１５に示すよ
うに、ファイル名、ファイル存在アドレス、データ量、
更新日時、カテゴリ情報、ファイル情報、配信日時、配
信ステータスが記憶される。

【００９４】なお、ストリームデータは、後述するよう
に、配信完了すると削除されるが、管理データテーブル
は、一旦配信したストリームデータについても記憶して
いる。かかる意義については後述する。

【００９５】なお、本実施形態においては、ユーザ毎の
所定の記憶容量を１ＧＢとした。

【００９６】また、ハードディスク２６０のストリーム
データサーバ記憶部２６０sには、図１６に示すよう
に、前記検索条件に基づいて、ストリームデータを収集
する対象サーバが記憶されている。かかる対象サーバ
は、例えば、ストリームデータの種類に応じて、検索エ
ンジン等で検索するようにすればよい。

【００９７】図１３にストリームデータ再生装置１００
０のハードウェア構成を示す。ストリームデータ再生装
置１０００は、ＣＰＵ１２３０、ＲＡＭ１２７０、ＲＯ
Ｍ１２５０、再生部１２８０、通信ボード１３２０、操
作部１３５０、液晶表示部１３００およびバスライン１
２９０を備えている。ＣＰＵ１２３０は、ＲＯＭ１２５
０に記憶されたプログラムにしたがいバスライン１２９
０を介して、各部を制御する。

【００９８】これらのプログラムは、あらかじめＲＯＭ
１２５０に記憶されているが、通信ボード１３２０を介
して、ＲＯＭ１２５０にダウンロードするようにしても
よい。

【００９９】再生部１２８０にはスピーカ１２９が接続
されており、再生されたストリームデータは音声信号と
してスピーカから出力される。操作部１３５０はストリ
ームデータの再生、スキップ、停止、音量調整などの命
令を入力する。

【０１００】ストリームデータの再生はＲＯＭ１２５０
に記憶された再生プログラム（図示せず）によってＣＰ
Ｕ１２３０によって、実行される。

【０１０１】ハードディスク１２６０には、サーバ１０
０から送信されたストリームデータを記録することがで
きる。

【０１０２】３．フローチャート 次に、サーバ１００のハードディスク２６０のプログラ
ム記憶部２６０pに記憶されている各種のプログラムに
よる処理について説明する。

【０１０３】まず、収集処理について図１７を用いて説
明する。ＣＰＵ２３０は、あるユーザについて、ユーザ
別ストリームデータ記憶部２６０uに所定容量以上の空
き容量があるか否か判断する（ステップＳ１００）。空
き容量がない場合は当該ユーザについての収集処理は終
了する。

【０１０４】一方、空き容量がある場合には、ＣＰＵ２
３０は、サーバ番号iを初期化し（ステップＳ２０
０）、当該ユーザの選別条件を読み出す（ステップＳ３
００）。ＣＰＵ２３０はサーバ番号i、この場合サーバ
番号１で特定されるサーバにアクセスする（ステップＳ
４００）。そして、合致するものがあるか否か判断する
（ステップＳ５００）。例えば、当該サーバに記憶され
ているストリームデータをオープンして、ヘッダ領域か
らフッタ領域に記憶された特性データを読み出し、ステ
ップＳ３００にて読み出した選別条件と合致するか否か
判断すればよい。

【０１０５】ＣＰＵ２３０は、選別条件に合致するスト
リームデータがあれば、既に当該ユーザのユーザ別スト
リームデータ記憶部２６０uの管理データテーブルに存
在するか否か判断する（ステップＳ６００）。既に前記
管理データテーブルに存在する場合には、当該ミュージ
ックサイトのうち、他のストリームデータについてステ
ップＳ５００の処理を繰り返す。当該ユーザの管理デー
タテーブルに存在しないストリームデータについては、
ユーザ別ストリームデータ記憶部２６０uに記憶する
（ステップＳ７００）。具体的には管理データテーブル
に追加されるとともに、ストリームデータを記憶すれば
よい。ここで記憶された各ストリームデータが、第１の
実施形態におけるオリジナルファイルに相当する。

【０１０６】そして、ステップＳ１００の判断を行い、
空き容量がなくなるまで、収集処理を行う。

【０１０７】なお、ステップＳ５００にて、選別条件に
合致するストリームデータがない場合には、ＣＰＵ２３
０は、図１６に示すアクセス対象の全サーバについて、
検討済みか否か判断する（図１７ステップＳ１１０
０）。全サーバについて、検討済みでない場合には、サ
ーバ番号iをインクリメントし、ステップＳ４００以下
の処理を実行する。

【０１０８】一方、全サーバについて検討済みである場
合には、ＣＰＵ２３０は、検索条件を変更する（ステッ
プＳ１５００）。例えば、検索処理式２の「配信ステー
タス『完了』のものは、記録しない」という選別条件を
「配信ステータス『完了』のものでも、配信から３日以
上経過していれば、記録する」というように変更すれば
よい。かかる検索処理式２としては、あらかじめ登録し
ておき、いずれかを選択するようにすればよい。例え
ば、他の「配信ステータス『完了』のものでも記録す
る」等である。

【０１０９】上記収集処理を全ユーザについて実行す
る。これにより、全ユーザについて、ユーザ別ストリー
ムデータ記憶部２６０uに所定容量のストリームデータ
が蓄積される。

【０１１０】次に、配信処理について図１８を用いて説
明する。ユーザは、ストリームデータ再生装置１０００
の操作部１３５０（図１３参照）から再生命令を与え
る。ストリームデータ再生装置１０００のＣＰＵ１２３
０は、ユーザより再生命令があるか否か判断しており
（図１８ステップＳ３１００）、再生命令が与えられる
と、ＣＰＵ１２３０は通信ボード１３２０（図１３参
照）を介して、サーバ１００に配信要求を送信する（ス
テップＳ３３００）。

【０１１１】サーバ１００のＣＰＵ２３０（図１２参
照）は配信要求があるか否か判断しており（ステップＳ
２１００）、配信要求があると、ユーザ別ストリームデ
ータ記憶部２６０uの管理データテーブル更新日時（図
１５参照）を参照して、記憶されているストリームデー
タのうち一番古いストリームデータから、サビ抜きファ
イルを生成する（ステップＳ２２００）。なお、サビ抜
きファイルの生成については、第１の実施形態と同様で
ある。

【０１１２】そして、生成したサビ抜きファイルをスト
リームデータとして配信する（図１８ステップＳ２３０
０）。

【０１１３】ストリームデータ再生装置１０００のＣＰ
Ｕ１２３０は、ストリームデータを受信するか否か判断
しており（ステップＳ３７００）、サーバ１００から配
信されたサビ部分のストリームデータ（サビ抜きファイ
ル）を受信すると、再生処理を行う（ステップＳ３７０
０）。

【０１１４】かかる再生処理は、配信されたストリーム
データを受信している間は継続される。このようにし
て、ストリームデータ再生装置にユーザ毎に定められた
選別条件に基づいてあらかじめ収集されたストリームデ
ータを、配信することにより、記憶容量の少ないストリ
ームデータ再生装置であっても、ユーザの好みのストリ
ームデータを再生することができる。

【０１１５】サビの再生が終了すると、オリジナルファ
イルのダウンロードを行うか否かの判断処理を行う（Ｓ
３９００）。なお、この判断処理は第１の実施形態と同
様である（図７：ステップＳ７１５参照）。

【０１１６】ユーザーがオリジナルファイルのダウンロ
ードを行うと判断した場合には、オリジナルファイルの
ダウンロードを示すオリジナルファイル要求信号を送信
する（Ｓ４１００）。この時、サーバ１００は、オリジ
ナルファイル要求信号を受信するか否かを判断している
（Ｓ２６００）。

【０１１７】サーバ１００がオリジナルファイル要求信
号を受信すれば、オリジナルファイルの送信を行い（Ｓ
２９００）、送信後オリジナルファイルに該当するスト
リームデータをユーザ別ストリームデータ記憶部２６０
uから削除する。具体的には、当該ストリームデータは
削除され、管理データテーブルの配信ステータスが
「未」から「完了」となる。一方、端末コンピュータ２
３は、オリジナルファイルを受信した後（Ｓ４３０
０）、ＨＤＤ２３ｃ等に保存する。なお、ステップＳ４
１００およびステップＳ４３００の処理は第１の実施形
態と同様である（図７：ステップＳ７１７、ステップＳ
７１９参照）。

【０１１８】ステップＳ２６００において、オリジナル
ファイル要求信号が一定時間内に受信されない場合には
（Ｓ２８００）、サーバ１００のＣＰＵ２３０は、前記
サビ抜きファイルに対応するストリームデータをユーザ
別ストリームデータ記憶部２６０uから削除する（ステ
ップＳ２９００）。

【０１１９】そして、ステップＳ２２００以下の処理を
繰り返す。これにより、ストリームデータの配信が継続
する限り、ストリームデータ再生装置１０００にて、ス
トリームデータの再生処理が継続する。

【０１２０】なお、ステップＳ２７００の削除処理によ
り、ユーザ別ストリームデータ記憶部２６０uに空き容
量が発生する。したがって、当該ユーザについて図１７
に示す収集処理が実行されて、ユーザ別ストリームデー
タ記憶部２６０uの当該ユーザ領域に、再度別のストリ
ームデータが蓄積される。

【０１２１】次に、図１９を用いて、配信中止の場合の
処理について説明する。配信を中止する場合には、ユー
ザは、ストリームデータ再生装置１０００の操作部１３
５０（図１３参照）から配信中止命令を与える。ストリ
ームデータ再生装置１０００のＣＰＵ１２３０は、ユー
ザより配信中止命令があるか否か判断しており（図１９
ステップＳ６３００）、配信中止命令が与えられると、
ＣＰＵ１２３０は再生処理を終了するとともに、通信ボ
ード１３２０を介して、図１２に示すサーバ１００に中
止要求を送信する（ステップＳ３３００）。

【０１２２】サーバ１００のＣＰＵ２３０は、中止要求
があるか否か判断しており（ステップＳ５１００）、中
止要求があると、中止確認メッセージを送信する（ステ
ップＳ５３００）。

【０１２３】ストリームデータ再生装置１０００のＣＰ
Ｕ１２３０は、中止確認メッセージを受信するか否か判
断しており（ステップＳ６７００）、中止確認メッセー
ジを受信すると、中止確認メッセージを液晶表示部１３
００に表示することにより、ユーザに報知する（ステッ
プＳ６９００）。ＣＰＵ１２３０は、ユーザより指示が
与えられるか否か判断しており（ステップＳ７１０
０）、指示が与えられると、指示内容をサーバ１００に
送信する（ステップＳ７３００）。

【０１２４】サーバ１００のＣＰＵ２３０はユーザから
の指示を受信するか否か判断しており（ステップＳ５５
００）、ユーザからの指示を受信すると、指示内容が消
去か否か判断する（ステップＳ５７００）。指示内容が
「消去」であれば再生が途中のストリームデータを削除
する（ステップＳ６１００）。一方、指示内容が「残
す」であれば再生が途中のストリームデータを残す（ス
テップＳ５９００）。

【０１２５】なお、配信中止処理はその都度ユーザに確
認するのではなく、あらかじめユーザ毎に設定を記憶し
ておき、配信中止命令が与えられると、再生途中のスト
リームデータを削除するか否かを当該設定に基づいて決
定するようにしてもよい。

【０１２６】なお、ストリームデータ再生装置１０００
のハードディスク１２６０に、配信されたストリームデ
ータを蓄積させることもできる。例えば、ＣＰＵ１２３
０には、前記再生処理前に、記録命令が与えられるか否
か判断し、与えられた場合は、前記ストリームデータを
再生してスピーカに出力するだけでなく、ハードディス
ク１２６０に記録するようにすればよい。

【０１２７】なお、ユーザが配信されたストリームデー
タを聞いてから、ストリームデータ再生装置１０００に
記録しておきたいと望む場合には、現在再生中のストリ
ームデータの配信を中止させて、記録命令を与えればよ
い。これにより、当該ストリームデータを記録すること
ができる。さらに、このような場合のために、ストリー
ムデータ毎に完全に再生が終了するまでは、これをスト
リームデータ再生装置のＲＡＭまたはハードディスクな
どの記録媒体に一時的に記憶しておくようにしてもよ
い。これにより、前記記録命令を再生処理中に受けた場
合も、再度最初から配信することなく、記録が可能とな
る。

【０１２８】［その他の実施形態］前述の第１の本実施
形態および第２の実施形態においては、音楽ファイルを
送信もしは配信する場合について説明したが、他のデー
タ、例えば、映像などの画像データ等を送信もしくは配
信するようにしてもよい。また、音楽ファイルのデータ
形式は、問わない。

【０１２９】さらに、前述の第１の本実施形態および第
２の実施形態においては、ストリームデータをファイル
単位でユーザに送信する場合について説明した。しか
し、あるファイルの全データを受け取ってから当該デー
タに基づいて再生するのではなく、受信したストリーム
データを、受け取った順に、データの解凍処理に要する
時間を除いてほぼリアルタイムで再生するストリームデ
ータであってもよい。例えば、RealPlayerや、RealAudi
o（RealNetworks社）、Windows Media Technologies（M
icrosoft社）、VDOLive（VDOnet社）等がある。

【０１３０】また、データ圧縮されたファイルとして、
MPEG、ＡＴＲＡＣ（登録商標）３、TwinVQ、ＤＯＬＢＹ
（登録商標） ＤＩＧＩＴＡＬ等のファイル形式のもの
であってもよい。

【０１３１】なお、リアルタイムで再生できないファイ
ル形式のデータをリアルタイムで再生できるように配信
するようにしてもよい。この場合、単に、リアルタイム
で再生できないファイル形式のデータをデコードしてか
ら、リアルタイムの方式に変換して配信するようにすれ
ばよい。

【０１３２】前述の第１の実施形態および第２の実施形
態においては、図２に示す音楽ファイルサーバおよび端
末コンピュータ２３、図１１に示すサーバおよびストリ
ームデータ再生装置を実現するために、それぞれＣＰＵ
を用い、ソフトウェアによってこれを実現している。し
かし、その一部もしくは全てを、ロジック回路等のハー
ドウェアによって実現してもよい。

【０１３３】また、プログラムの一部の処理をオペレー
ティングシステム（ＯＳ）にさせるようにしてもよい。

【０１３４】さらに、前述の第１の実施形態および第２
実施形態においては、オリジナルファイルからサビ抜き
ファイルを生成する際に、サビ部分を１カ所として示し
たが、（図５、６参照）これに限定されない。つまり、
サビ部分は、複数箇所あってもよい。

【０１３５】また、前述の第１の実施形態および第２の
実施形態においては、サビ部分の開始アドレスと終了ア
ドレスとを指定することによって、サビ部分の特定を行
ったが、サビ部分が特定できるものであれば、これに限
定されない。例えば、サビ部分の開始アドレスとサビ部
分の時間を指定するようにしもてもよい。

【０１３６】さらに、楽曲毎にサビ部分を特定するよう
にしたが、どの楽曲も一律に同じ部分をサビ部分とする
ようにしてもよい。例えば、全ての楽曲について、楽曲
の再生開始２分後から２分１５秒までをサビ部分とする
ようにしてもよい。

【０１３７】さらに、前述の第１の実施形態および第２
実施形態においては、端末コンピュータ２３およびスト
リームデータ再生装置１０００として、一般的なパーソ
ナルコンピュータを例示したが、これに限定されるもの
ではない。つまり、通信機能を有し。かつ、音楽ファイ
ルが再生できるものであればよい。例えば、音楽ファイ
ルを再生する機能を有する携帯電話やPDA等であっても
よい。また、通信機能を有するmp3再生装置等であって
もよい。

【０１３８】前述の第１の実施形態においては、音楽フ
ァイルとしてRIFFフォーマットのウェーブファイルを例
示したが、このファイルをストリームデータとして送信
するようにしてもよい。

【０１３９】また、前述の第１の実施形態においては、
１曲毎にサビ抜きファイルを送信することとしたが、複
数曲のサビ部分をまとめて１つのサビ抜きファイルを生
成し、送信するようにしてもよい。

【０１４０】さらに、前述の第１の実施形態において
は、ＣＰＵ２３ａは、端末コンピュータ用プログラムに
よって、図８に示すダウンロードページを表示するとし
たが、ダウンロードページを表示できるものであればこ
れに限定されない。例えば、いわゆるブラウザ・アプリ
ケーションによって、ダウンロードページを表示する用
にしてもよい。

【０１４１】第２の実施形態における図１１において
は、１のストリームデータ再生装置がネットワーク接続
されている場合について説明したが、多数のストリーム
データ再生装置を接続させるようにしてもよい。

【０１４２】また、ユーザは配信されたストリームデー
タが自分の好みに合わない場合もある。この場合には、
前記選択条件を変更する変更命令を与えればよい。

【０１４３】また、図１４に示すユーザ別収集条件記憶
部に、優先順位重みが記憶されている。これは、１のユ
ーザが複数の選別条件を登録した場合に、どの選別条件
をどの程度重視するかを決定する係数である。これによ
りユーザ別ストリームデータ記憶部２６０uの容量の容
量が限られている場合でも、複数の選別条件を登録して
自分の好みのストリームデータをどのような選別条件で
あらかじめ記録しておくかを決定することができる。例
えば、既存カテゴリ（例えば、今週のベストヒット１０
とか、ヒットＣＭ曲等）とユーザ独自のカテゴリの、複
数の選別条件を登録しておき、各選別条件に付与されて
いる優先順位重みの比率に基づいて、検索回数の割合を
変更するようにすればよい。

【０１４４】さらに、配信されたストリームデータだけ
が好みに合わないこともある。この場合には、以下のよ
うな処理によってスキップ処理が可能である。ユーザが
スキップ命令を操作部１３５０から与えればよい。ＣＰ
Ｕ１２３０はかかるスキップ命令を受けて、サーバ１０
０に現在配信中のストリームデータの配信を中止し、次
の順位のストリームデータを配信するためのスキップ要
求を送信する。サーバ１００のＣＰＵ２３０はかかるス
キップ要求を受けて、次の順位のストリームデータを配
信する。

【０１４５】なお、第２の実施形態においては、アクセ
ス対象として登録しているミュージックサーバの各ファ
イルについて、本システムにかかるサーバ１００が自ら
アクセスして、選択条件に合致するか否かを判断するよ
うにしたが、データベースを有するミュージックサーバ
に対しては、前記選択条件に合致するストリームデータ
を検索させるようにしてもよい。

【０１４６】なお、図１６に示す対象サーバについて、
アクセス時間を記憶しておき、前回のアクセス時間から
所定時間以上経過していなければ、アクセス対象から外
すようにしてもよい。

【０１４７】また、第２の実施形態におけるサーバ１０
０のユーザ別ストリームデータ記憶部に記憶されたスト
リームデータについては、所定期間以上配信要求がな
く、古くなったデータについては個別にＣＰＵ２３０が
更新日時に基づいて判断し、これを削除するようにして
もよい。また、前記削除は、当該ユーザのユーザ別スト
リームデータ記憶部に記憶された全ストリームデータに
対して実行するようにしてもよい。例えば、毎日一旦メ
モリを解放して、再収集するようにしてもよい。

【０１４８】なお、第２の実施形態においては、一旦配
信されたストリームデータは削除するようにしたが、所
定時間経過後に削除するようにしてもよい。これは、配
信後、ユーザから再配信要求がある可能性があるからで
ある。

【０１４９】また、第２の実施形態においては、同じス
トリームデータであっても、各ユーザ別ストリームデー
タ記憶部毎に、記憶している。あるユーザ別ストリーム
データ記憶部にあるストリームデータを記録する場合
に、既に別のユーザ別ストリームデータ記憶部に記憶さ
れている場合には、これらを共有するようにしてもよ
い。これにより、データ領域を全体として有効利用する
ことができる。

【０１５０】さらに、第２の実施形態にかかる他のミュ
ージックサーバからストリームデータを収集して、サー
バ１００に蓄積させておく場合において、データ形式が
ファイル単位でユーザ端末に記録されないと再生できな
い形式である場合には、これを受け取った順に再生する
データ形式に変換して、サーバ１００に蓄積するように
してもよい。さらに、前述の第２の実施形態において
は、１つのサビ抜きファイルを配信する毎に、オリジナ
ルファイルのダウンロードを行うか否かの判断すること
とした。しかし、複数のサビ抜きファイルを配信し、必
要な楽曲のみオリジナルファイルを配信するようにして
もよい。さらに、サビ抜きファイルの配信と平行して、
オリジナルファイルのダウンロードを行うようにしても
よい。

【図面の簡単な説明】

【図１】本発明にかかる音楽ファイル送受信システム１
の機能ブロック図である。

【図２】音楽ファイル送受信システムの概要を示した図
である。

【図３】図２に示す端末コンピュータ２３をＣＰＵを用
いて実現したハードウエア構成の一例を示す図である。

【図４】図２に示す音楽ファイルサーバ２５をＣＰＵを
用いて実現したハードウエア構成の一例を示す図であ
る。

【図５】本実施形態における音楽ファイルのデータ構造
を示した図である。

【図６】本実施形態におけるサビ抜きファイルのデータ
構造を示した図である。

【図７】端末コンピュータ２３のＣＰＵ２３ａおよび音
楽ファイルサーバ２５のＣＰＵ２５ａの動作を示すフロ
ーチャートである。

【図８】サビ抜きファイルをダウンロード際に、端末コ
ンピュータ２３のディスプレイ２３ｈに表示される画面
を示す図である。

【図９】オリジナルファイルからサビ抜きファイルの生
成に関する音楽ファイルサーバ２５のＣＰＵ２５ａの動
作を示すフローチャートである。

【図１０】オリジナルファイルのダウンロードを行うか
否かの判断処理の際に、ディスプレイ２３ｈ表示される
確認ボックスＣ１を示した図である。

【図１１】本発明にかかるストリームデータ再生システ
ムの概要を示した図である。

【図１２】図１１に示すサーバ１００をＣＰＵを用いて
実現したハードウエア構成の一例を示す図である。

【図１３】図１１に示すをストリームデータ再生装置１
０００をＣＰＵを用いて実現したハードウエア構成の一
例を示す図である。

【図１４】ユーザ別収集条件記憶部のデータ構造を示す
図である。

【図１５】ユーザ別ストリームデータ記憶部２６０uの
データ構造を示す図である。

【図１６】本システムが選別条件に合致するストリーム
データを検索する対象サーバ一覧を示す図である。

【図１７】収集処理のフローチャートである。

【図１８】配信処理のフローチャートである。

【図１９】配信中止処理のフローチャートである。

【符号の説明】

１・・・・・音楽ファイル送受信システム ３・・・・・第１の通信装置 ５・・・・・第２の通信装置 ２３・・・・・端末コンピュータ ２５・・・・・音楽ファイルサーバ

Claims (5)

【特許請求の範囲】
1. 【請求項１】ネットワークを介して接続された第１の通
   信装置と第２の通信装置との間で、時間の経過にともな
   う音の連続的な変化を記録した音楽ファイルのやりとり
   を行う音楽ファイル送受信システムにおいて、 第２の通信装置は、音楽ファイルと、音楽ファイルの一
   部であって、当該音楽ファイルの内容の特徴的部分であ
   る特徴音楽ファイルを音楽ファイルから特定する特定情
   報と、を有しており、 第１の通信装置が、特徴音楽ファイルを要求する要求信
   号を送信し、第２の通信装置が当該要求信号を受信する
   と、 第２の通信装置は、特定情報に基づいて、音楽ファイル
   から特徴音楽ファイルを生成し、第１の通信装置へ送信
   すること、 を特徴とする音楽ファイル送受信システム。
2. 【請求項２】請求項１にかかる音楽ファイル送受信シス
   テムにおいて、 前記特徴音楽ファイルは、音楽ファイルのサビ部分によ
   って構成されていること、 を特徴とする音楽ファイル送受信システム。
3. 【請求項３】ネットワークを介して接続された他の通信
   装置に対して、時間の経過にともなう音の連続的な変化
   を記録した音楽ファイルの送信を行う音楽ファイル送信
   装置において、 音楽ファイルと、音楽ファイルの一部であって、当該音
   楽ファイルの内容の特徴的部分である特徴音楽ファイル
   を音楽ファイルから特定する特定情報と、を有してお
   り、 他の通信装置からの特徴音楽ファイルを要求する要求信
   号を受信すると、 特定情報に基づいて、音楽ファイルから特徴音楽ファイ
   ルを生成し、他の通信装置へ送信すること、 を特徴とする音楽ファイル送信装置。
4. 【請求項４】他の通信装置から送られてきたデータを再
   生する処理をコンピュータに実行させるプログラムを記
   録した記録媒体であって、 当該プログラムは、 画面上に特徴音楽ファイル獲得ボタンを表示し、 特徴音楽ファイル獲得ボタンが選択されると、他の通信
   装置に対して要求信号を発信し、 当該要求信号に基づき他の通信装置から送られてきたデ
   ータを、音楽ファイルの一部であって、当該音楽ファイ
   ルの内容の特徴的部分である特徴音楽ファイルとして再
   生する処理をコンピュータに実行させるためのプログラ
   ムであること、を特徴とする記録媒体。
5. 【請求項５】人間の感覚で判断できる特徴量の大きさが
   時間の経過にともない連続して変化する時系データを記
   録したファイルを確認する時系データ簡易確認方法にお
   いて、 時系データと、時系データの一部であって、当該時系デ
   ータの内容の特徴的部分である特徴時系データを時系デ
   ータから特定する特定情報と、が記録されており、 特徴時系データを要求すると、 特定情報に基づいて、時系データから特徴時系データを
   生成し、 生成した特徴時系データを確認させるために出力するこ
   と、 を特徴とする時系データ簡易確認方法。