[実施例1]
 図1は、本発明の実施例1におけるシステム� �体を示す構成図である。

 図1において、本システムは、コンテンツ を配信するサーバ装置1と、コンテンツを受� �し再生する端末装置2とがネットワーク3を介 して接続されている。端末装置2は1つでも複� ��あっても良い。また、本実施例においては� ��コンテンツが音楽である場合を説明するが� ��これに限定するものではなく、映画、TV番� �等の映像(動画)データや、写真などの静止画 データ等、他の種類のデータであっても良い 。

 図2は、図1に示す実施例1のサーバ装置1の 構成例を示すブロック図である。

 図2において、サーバ装置1は、プレイリ� �ト格納部10と、プレイリスト構造データ格納 部11と、送受信部12と、制御部13とを有してい る。また、サーバ装置1には、サーバ装置1の� ��理者が操作を行うためのキーボードやマウ� ��等の入力装置20と、ディスプレイ等の表示� �置21が接続されている。なお、サーバ装置1� �、CPU、RAM、ROM、ハードディスクドライブ等� �より構成される一般的なコンピュータを用� �て、CPUがROMやハードディスクドライブ等に� �納されたコンピュータプログラムを実行す� �ソフトウェア処理で実現することも可能で� �る。このことは、後述する他の実施例のサ� �バ装置でも同様である。また、本実施例に� �いては、プレイリスト格納部10と、プレイリ スト構造データ格納部11とを同じサーバ装置1 内に配置しているが、これらを別々のサーバ 装置に配置することも可能である。

 図3は、プレイリスト格納部10が格納する� ��ータの一例を示す図である。図3に示すよう に、プレイリスト格納部10には複数(P個、P≧2 )のプレイリストが格納されている。各々の� �レイリストは、プレイリストIDと、コンテン ツの再生順序と、コンテンツのタイトルと、 制作者(アーティスト)と、コンテンツの取得� ��報とが関連付けられたデータである。また� ��々のプレイリストには1つ以上のコンテンツ が関連付けられている。プレイリストIDは、� ��レイリストを一意に識別できる数値または� ��キストデータである。コンテンツの取得情� ��は、図3に示した例では、コンテンツ(配信� �ァイル)の所在を示すURL(Uniform Resource Locator) 等である。なお、本発明の実施例1~実施例4に おいて、コンテンツを格納する装置と、コン テンツを利用(取得)する装置が同一の装置で� ��る場合は、必ずしもURL等を用いる必要はな� ��、コンテンツを一意に識別する識別子(コン テンツID)やコンテンツ含むファイルのパス名 などをコンテンツの取得情報として用いるこ とができる。例えば後述するように、サーバ 装置1がコンテンツを格納しており、そのコ� �テンツを取得して配信する場合には、プレ� �リストに記述された取得情報として、コン� �ンツが格納されたファイルのパス名や、コ� �テンツを格納するデータベースにおけるコ� �テンツIDなどを用いても良い。

 コンテンツは、サーバ装置1のコンテンツ 格納手段(図2では不図示)に格納されていても 良いし、端末装置2からアクセス可能なサー� �装置1とは別の装置に格納されていても良い� ��また、制作年、ジャンル、再生に適した状� ��・場所などの情報がプレイリストに含まれ� ��いても良い。また、コンテンツのタイトル� ��制作者の情報を省略しても良い。

 実施例1においてプレイリストは、サーバ の運営者や管理者により作成されているもの とするが、端末装置2を使用する利用者にプ� �イリストを作成させたり、利用者にプレイ� �ストの内容の一部を変更させても良い。本� �施例においてプレイリストは、コンテンツ� �ジャンル、制作年代、コンテンツの持つ雰� �気、コンテンツを再生するのに適する状況/� ��所、などの情報を用いて作成されている。

 図4は、プレイリスト構造データ格納部11� ��格納するデータの一例を示す図である。

 すなわち、プレイリスト構造データ格納� ��11は、図4に示すような形式で、プレイリス� ��構造データIDと、複数のプレイリスト間の� �係性を示すプレイリスト構造データと、遷� �コマンドデータと、説明データとを関連付� �て格納し、さらに最優先構造データIDとを格 納している。プレイリスト構造データIDは、� ��数のプレイリスト構造データを一意に識別� ��るためのIDである。最優先構造データIDは、 最も優先して使用するプレイリスト構造デー タIDである。図4の例では、M個の各データが� �納されている(M≧1)。プレイリスト構造デー� ��を複数種類ではなく、1つだけ格納するよう にしても良い。1つだけ格納する場合、プレ� �リスト構造データIDと、最優先構造データID� ��を省略することも可能である。また後述す� ��ように、遷移コマンドデータと説明データ� ��省略することも可能である。各々のプレイ� ��スト構造データは、プレイリスト格納部10� �格納されたプレイリストの内の一部または� �部のプレイリストと、共通するプレイリス� �IDを用いて関連付けられている。1つのプレ� �リスト構造データに関連するプレイリスト� �数は、プレイリスト構造データ毎に異なっ� �いて良い。各プレイリスト構造データには� �以下に説明する形式でデータが格納されて� �る。

 実施例1では、プレイリスト構造データの 基本的な形式として、以下の図5~図7の3つの� �式を用いる。いずれの形式においても、プ� �イリスト構造データは、複数のプレイリス� �(プレイリストID)間の関係を示す数値で構成� ��れている。

 図5は、プレイリスト構造データの第1形� �の例を示している。

 第1形式は、図5(A)に示すように、複数(N個 、N≧2)のプレイリストのプレイリストIDと、� ��れらを所定の基準に従って順位付けた場合� ��順位1~Nとを対応させたものである。

 図5(B)は、音楽ジャンル別にプレイリスト を作成した場合のプレイリスト構造データの 第1形式の一例を示している。図5(B)では、「C lassic」、「Easy Listening」、 「Folk」、 「Rock 」、 「Heavy Metal」の5個のジャンルを用い、 各々のジャンルに対応する5個のプレイリス� �を作成している。この例における順位は、� �のジャンルの典型的な楽曲の音圧の強さや� �ートの強さ、あるいは主観的な「激しさ」� �程度などを基準に決められており、「1」が� ��も弱く、「5」が最も強いことを表わしてい る。

 図6は、プレイリスト構造データの第2形� �の例を示している。

 第2形式は、図6(A)に示すように、複数(N個 、N≧2)のプレイリストのプレイリストIDと、� ��れらを所定の座標系に配置した場合の座標� ��とを対応させたものである。座標の次元数� ��L(L≧1)としている。

 図6(B)は、図5(B)と同様に、音楽ジャンル� �にプレイリストを作成した場合のプレイリ� �ト構造データの第2形式の一例を示している� ��この例では、座標の次元数は1であり、座標 値として、そのジャンルの典型的な楽曲の音 圧の強さやビートの強さ、あるいは主観的な 「激しさ」の程度などを示す数値を座標値と して用いている。

 図7は、プレイリスト構造データの第3形� �の例を示している。

 第3形式は、図7(A)のように、N個(N≧2)のプ レイリストの内の任意の2つのプレイリスト� �の類似度を行列形式で表現したものである� �行および列はプレイリストIDで構成されてい る。行列の要素は、2つのプレイリスト間の� �似度を表わしており、例えば、図7(A)の「類� ��度13」は、「プレイリスト1」と「プレイリ� ��ト3」との類似度を表わしている。

 図7(B)は、図5(B)、図6(B)と同様に、音楽ジ� ��ンル別にプレイリストを作成した場合のプ� ��イリスト構造データの第3形式の一例を示し ている。この例において、行列の要素は、「 0.0」~「1.0」の数値であり、「1.0」は最も類� �度が高く、「0.0」は最も類似度が低いこと� �示している。行列の対角要素は、同一のプ� �イリスト間の類似度になるので、全て「1.0� �である。この例のように対称行列になる場� �は、同じ値となる対称要素を省略しても良� �。

 以上がプレイリスト構造データの基本的� ��形式の説明であるが、プレイリストを複数� ��階層にすることも可能である。

 図8は、プレイリストを複数の階層にした プレイリスト構造データの一例を示す図であ る。

 図8では、音楽ジャンルと制作年代を組み 合わせてプレイリストを作成しており、階層 1(上位プレイリスト)がジャンル、階層2(下位� ��レイリスト)が年代に対応した、2階層の構� �を持っている。上位プレイリストは1つ以上� ��下位プレイリストに対応しており、下位プ� ��イリストは1つの上位プレイリストに対応し ている。各々の上位プレイリストおよび各々 の下位プレイリストには、上述したような順 位が対応付けられている。例えば図8におい� �、階層2が「バロック」であるプレイリスト� ��、ジャンルが「Classic」で、かつ年代が「バ ロック」であるコンテンツを集めたプレイリ ストである。また、3つ以上の階層構造を用� �ることも可能である。図4に示した例では、M 個のプレイリスト構造データが、上述した形 式のいずれかの形式で格納されている。M個� �プレイリスト構造データは、全て同じ形式� �あっても良いし、プレイリスト構造データ� �に異なる形式であっても良い。

 次に、プレイリスト構造データ格納部11� �格納される遷移コマンドデータ(図4参照)に� �いて説明する。

 遷移コマンドデータは、後述するように� ��端末装置2においてプレイリストを変更する 際に使用するデータである。

 図9は、遷移コマンドデータの一例を示し ている。

 図9に示した例では、K個の遷移コマンド� �格納されており、各々の遷移コマンドは、� �移コマンドIDと、方向と、変化量と、表示メ ッセージとが対応付けられたデータである。 遷移コマンドIDは、遷移コマンドを一意に識� ��するための数値またはテキストデータであ� ��。

 実施例1では、遷移コマンドデータの方向 と変化量は、端末装置2において、コンテン� �再生に用いるプレイリストを変更、すなわ� �切り替える際に使われる情報である。これ� �の使われ方については、端末装置2の再生処� ��を説明する際に詳しく説明する。

 図9において、方向は、「0」、「+」、「- 」の3種類のいずれかである。「0」は方向性� ��無いことを表わし、「+」は上述した順位お よび座標値の数値が大きくなる方向の変化を 表わし、「-」は順位および座標値の数値が� �さくなる方向の変化を表わしている。

 変化量は、プレイリスト構造データの格� ��形式(第1形式~第3形式)に応じた形式で格納� �れている。

 図9(A)の例は、プレイリスト構造データの 第1形式として説明した順位を用いた場合で� �り、「3」は3つ順位が異なるプレイリストに 変更することを示し、「1」は1つ順位が異な� ��プレイリストに変更することを示している� ��

 また、図9(B)の例は、プレイリスト構造デ ータとして、図6に示す第2形式の座標値を用� ��る場合である。この変化量の項目は、座標� ��の次元数(L個)だけ変化量を並べて格納する� ��式になる。これらの数値は、各々の次元の� ��標値に加算または減算するための数値であ� ��。次元数が1である場合は、変化量の項目は 1つになる。

 また、図9(C)の例は、プレイリスト構造デ ータとして、図7に示す第3形式の類似度を用� ��る場合である。変化量の数値は、その値に� ��い類似度を持つプレイリストに変更するこ� ��を示しており、「0.1」といったような1つの 数値になる。類似度を単独で用いる場合は、 方向が「0」のコマンドしか格納できない。� �だし、図10に示すように、プレイリスト構造 データとして類似度と順位を合わせて格納し 、端末装置2において方向の判定に順位を使� �、変化量として類似度を使用することによ� �、類似度を用いてなおかつ方向性のあるコ� �ンドを利用することも可能である。また、� �似度と座標値を合わせて格納し、端末装置2� ��おいて方向の判定に座標値を使い、変化量� ��して類似度を使用しても良い。なお、実施� ��1においては上述したように、遷移コマンド データの方向と変化量を分けて扱っているが 、変化量に符号を加えることにより、方向を 省略することも可能である。

 また、遷移コマンドデータの表示メッセ� ��ジは、端末装置2が出力装置41に表示するた� ��のテキストデータである。なお、表示メッ� ��ージは、遷移コマンドデータの方向と変化� ��とに基づいて、端末装置2側で作成されるよ うにしても良い。この場合には、表示メッセ ージの格納は省略できる。

 図11は、プレイリスト構造データが複数� �階層を持つ場合の遷移コマンドデータの一� �を示している。

 図11では、図9の遷移コマンドデータに対� ��「階層」が追加されている。これはプレイ� ��ストの複数の階層のうち最上位の階層から� ��えて何番目の階層を対象とするかを示す情� ��である。その他は、図9に示す遷移コマンド データと同じである。

 図4に戻り、プレイリスト構造データ格納 部11に格納される説明データは、端末装置2を 使う利用者に各プレイリスト構造データの特 徴を伝えるためのもので、利用者が複数のプ レイリスト構造データの中から1つを選択す� �際に使用するデータである。

 図12は、図1に示す端末装置2の構成例を示 すブロック図である。

 図12において、端末装置2は、プレイリス� ��記憶部30と、プレイリスト構造データ記憶� �31と、コンテンツ取得部32と、再生部33と、� �受信部34と、制御部35と、状態記憶部36とを� �しており、入力装置40と、表示装置41と、音� ��出力装置42とが接続されている。

 入力装置40は、利用者からの操作指示を� �け付けるためのキーボード、マウス、リモ� �ン、タッチパネル等である。また、表示装� �41は、コンテンツの再生および情報を表示す るためのディスプレイ等である。音声出力装 置42は、コンテンツの再生に必要なスピーカ� ��、ヘッドホン等である。なお、端末装置2も 、CPU、RAM、ROM、ハードディスクドライブ等に より構成される一般的なコンピュータを用い て、コンテンツ再生用プログラムの実行によ るソフトウェア処理として実現することも可 能である。このことは、後述する他の実施例 の端末装置や再生装置等でも同様である。

 図13は、電源投入直後に端末装置2の制御� ��35が表示装置41に表示するメニュー画面の一 例を示している。

 図13において、メニュー画面131には、「� �御用データのダウンロード」と「コンテン� �の再生」の2種類の選択メニューが表示され� ��いる。左側の矢印はカーソル132の位置を表� ��している。利用者が入力装置40を使って所� �のメニュー項目にカーソル132を合わせ、決� �ボタン133を押すことにより、各メニュー項� �に対応した処理が開始される。

 次に、メニュー画面131から2種類の選択メ ニューが選択された場合の端末装置2および� �ーバ装置1の動作を、フローチャートを参照� ��て説明する。

 図14は、図13に示すメニュー画面131から利 用者が「1:制御用データのダウンロード」の� ��ニュー項目を選択した場合の端末装置2およ びサーバ装置1における制御用データのダウ� �ロード処理を示すフローチャートである。

 まず、端末装置2側にて、利用者が図13に� ��すメニュー画面131から「制御用データのダ� ��ンロード」のメニュー項目を選択すると、� ��末装置2の制御部35が送受信部34を介してサ� �バ装置1に対して制御用データを要求するメ� ��セージを送信する(S100)。

 すると、サーバ装置1側では、制御部13が� ��受信部12を介して制御用データ要求のメッ� �ージを受信し(S110)、プレイリスト構造デー� �格納部11の中の最優先構造データIDを参照し� ��それに該当するプレイリスト構造データID� �持つプレイリスト構造データと、遷移コマ� �ドデータとを制御用データとして読み出す(S 120)。プレイリスト構造データ格納部11に1種� �しかデータが格納されていない場合は、そ� �を読み出す。なお、実施例1においてはサー� ��装置1から端末装置2に遷移コマンドデータ� �送信するものとしているが、端末装置2が予� ��遷移コマンドデータを格納しておくことに� ��り、サーバ装置1のプレイリスト構造データ 11に遷移コマンドデータを格納することを省� ��し、S120でプレイリスト構造データのみを制 御用データとして読み出すようにすることも 可能である。

 次に、サーバ装置1の制御部13は、S120で読 み出したプレイリスト構造データに含まれる プレイリストIDを取得し、プレイリスト格納� ��10を参照しながら、取得したプレイリストID に該当する全てのプレイリストを読み出す(S1 30)。

 そして、サーバ装置1の制御部13は、S120で 読み出した制御用データと、S130で読み出し� �プレイリストとを送受信部12を介して端末装 置2に送信する(S140)。

 端末装置2の制御部35は、送受信部34を介� �サーバ装置1から制御用データであるプレイ� ��スト構造データおよび遷移コマンドデータ� ��、プレイリストとを受信すると、制御用デ� ��タをプレイリスト構造データ記憶部31に記� �する一方、プレイリストをプレイリスト記� �部30に記憶する(S150)。

 以上の制御用データのダウンロード処理� ��よれば、利用者が条件を選択する等の操作� ��不要なため、端末装置3の操作を簡単にした い場合に適している。なお、端末装置2のプ� �イリスト記憶部30にあらかじめプレイリスト 構造データに対応したプレイリストを記憶さ せておくことにより、S130と、S140におけるプ� ��イリストの送信を省略することも可能であ� ��。

 次に制御用データのダウンロード処理の� ��の例を、図15のフローチャートを用いて説� �する。

 この処理では、サーバ装置1のプレイリス ト構造データ格納部11に説明データが格納さ� ��ている必要があり、この処理を行わない場� ��は、説明データは省略可能である。

 この場合、まず、端末装置2の制御部35が� ��受信部34を介してサーバ装置1に、プレイリ� ��ト構造データの一覧であるプレイリスト構� ��データリストを要求するメッセージを送信� ��る(S200)。

 すると、サーバ装置1側では、制御部13が� ��受信部12を介してプレイリスト構造データ� �スト要求のメッセージを受信し(S210)、プレ� �リスト構造データ格納部11からデータを読み 出してプレイリスト構造データリストを作成 する(S220)。具体的には、プレイリスト構造デ ータ格納部11に格納されている全てのプレイ� ��スト構造データIDと、説明データとを対応� �けて読み出し、これらをプレイリスト構造� �ータリストとする。

 次に、制御部13は、作成したプレイリス� �構造データリストを、送受信部12を介して端 末装置2に送信する(S230)。

 端末装置2では、制御部35が送受信部34を� �してサーバ装置1からプレイリスト構造デー� ��リストを受信し、表示装置41にプレイリス� �構造データリストを表示する(S240)。

 図16は、表示装置41に表示されるプレイリ スト構造データリストの一例を示す図である 。

 図16に示すプレイリスト構造データリス� �161では、プレイリスト構造データIDと、説明 データとを対応させて表示している。しかし 、説明データのみ表示するようにしても良い 。左側の矢印はカーソル162の位置を表わして いる。利用者は、説明データを読んで所望の プレイリスト構造データを決めた後、入力装 置40を使って所望のメニュー項目にカーソル1 62を合わせ、決定ボタン163を押すことにより� ��プレイリスト構造データが選択される。

 図15に戻り、表示装置41に表示されたプレ イリスト構造データリスト161にて利用者が所 望のプレイリスト構造データを選択すると、 制御部35は、入力装置40を介して利用者から� �指示を受け付け、その指示に該当するプレ� �リスト構造データIDを、送受信部34を介して� ��ーバ装置1に送信する(S250)。

 サーバ装置1では、制御部13が送受信部12� �介して端末装置2からプレイリスト構造デー� ��IDを受信し(S260)、受信したプレイリスト構� �データIDに対応するプレイリスト構造データ と遷移コマンドデータとを制御用データとし てプレイリスト構造データ格納部11から読み� ��す(S270)。

 次に制御部13は、S270で読み出したプレイ� ��スト構造データに含まれるプレイリストID� �取得し、プレイリスト格納部10を参照して、 取得したプレイリストIDに該当する全てのプ� ��イリストを読み出し(S280)、S270にて読み出し た制御用データと、S280にて読み出したプレ� �リストとを送受信部12を介して端末装置2に� �信する(S290)。

 端末装置2では、制御部35が送受信部34を� �してサーバ装置1から制御用データとプレイ� ��ストとを受信し、制御用データをプレイリ� ��ト構造データ記憶部31に記憶する一方、プ� �イリストをプレイリスト記憶部30に記憶する (S300)。

 以上の制御用データダウンロード処理に� ��れば、利用者が複数種類のプレイリスト構� ��データの中から好きなものを選択すること� ��できるので、利用者の満足度をより高める� ��とができる。

 実施例1では、図14または図15のどちらの� �御用データダウンロード処理を用いても良� �。また上記の説明では、利用者のメニュー� �択により処理が開始される場合を説明した� �、これ以外に、所定の時間毎に端末装置2か� ��サーバ装置1に対し制御用データの要求メッ セージを送信するようにしても良い。また、 利用者から「コンテンツ再生」の指示を受け た時に、プレイリストと制御用データの有無 を確認し、それらが無い場合にはコンテンツ 再生に先立って、それらをダウンロードする 処理を自動的に行っても良い。また、サーバ 装置1から端末装置2にプレイリストの一覧情� ��を送信して表示装置41に表示し、利用者に� �ウンロードするプレイリストを選択させた� �で、選択されたプレイリストおよびその再� �に必要な制御用データをサーバ装置1から端� ��装置2にダウンロードするようにしても良い 。更に、プレイリストと制御用データとを予 め端末装置2に記憶しておいても良い。

 図17は、図13に示すメニュー画面131から「 2:コンテンツの再生」のメニュー項目が選択� ��れた場合のコンテンツ再生処理を示すフロ� ��チャートである。

 まず、端末装置2の制御部35が、プレイリ� ��ト構造データ記憶部31を参照し、そこに格� �されているプレイリスト構造データに記述� �れた複数のプレイリストIDの中から再生に使 用するプレイリストのプレイリストIDを1つ初 期値として選択して、それを状態記憶部36に� ��憶する(S600)。プレイリスト構造データが複� ��の階層で構成されている場合は、例えば、� ��下位の階層のプレイリストのプレイリストI Dを選択する。プレイリストIDの選択方法とし ては、以下の3つを用いることができる。

 第1の方法は、ランダムにプレイリストID� ��選択する方法である。乱数を利用するなど� ��て選択すれば良い。

 また、第2の方法は、前回使用したプレイ リストIDを選択する方法である。状態記憶部3 6を不揮発性メモリで構成し、前回使用した� �レイリストIDが保存されている場合は、それ を用いても良い。

 また、第3の方法は、利用者に所望のプレ イリストのプレイリストIDを選択させる方法� ��ある。この場合、制御部35はプレイリスト� �憶部30からプレイリストを読み出し、プレイ リストの一覧を作成して表示装置41に表示さ� ��る。利用者は入力装置40を用いて、表示装� �41に表示されたプレイリスト一覧の中から1� �のプレイリストを選択させ、そのプレイリ� �トIDを状態記憶部36に記憶する。なお、第3の 方法として上記の他に、制御部35がプレイリ� ��ト構造データ記憶部31からプレイリストIDを 読み出し、プレイリストIDの一覧を作成して� ��示装置41に表示させ、利用者にプレイリス� �IDを選択させても良い。

 プレイリストIDが選択されると、コンテ� �ツ取得部32は、状態記憶部36に記憶されたプ� ��イリストIDを読み出し、それに対応するプ� �イリストに従って順次コンテンツを取得す� �(S610)。具体的には、コンテンツ取得部32は、 状態記憶部36に記憶されたプレイリストIDに� �応するプレイリストをプレイリスト記憶部30 から読み出し、そのプレイリストに記述され ている再生順序に従って、コンテンツの取得 情報を読み出し、送受信手段34を介してコン� ��ンツである配信ファイルを取得し、コンテ� ��ツ取得部32に一時的に記憶する。実施例1で� ��、コンテンツは、サーバ装置1、あるいは端 末装置2からアクセス可能な他の装置に配信� �ァイルとして配置されているものとして説� �するが、端末装置2にコンテンツ記憶部を設� ��て、予めそこに記憶させておいても良い。

 次に、再生部33がコンテンツ取得部32に記 憶されているコンテンツを読み出して、デコ ード等の必要な処理を行った後に表示装置41� ��よび音声出力装置42に出力することにより� �コンテンツを再生する(S620)。

 次に、制御部35は、再生中のコンテンツ� �情報およびコンテンツ再生に用いるプレイ� �ストを変更するための遷移コマンドを表示� �置41に表示する(S630)。つまり、制御部35は、� ��レイリスト構造データ記憶部31から遷移コ� �ンドデータの表示メッセージ(図9、図11等参� ��)を読み出したり、または方向と変化量とに 基づいて表示メッセージを作成すると共に、 再生中のコンテンツのタイトルや制作者など の情報をプレイリスト格納部30から読み出し� ��、それらを表示装置41に表示する。

 図18は、S630により表示装置41に表示され� �表示画面の一例を示している。

 この例では、画面上部にコンテンツのタ� ��トル211と、制作者212とを表示しており、画� ��下部に遷移コマンドの表示メッセージ213を� ��示している。左側の矢印は、カーソル214の� ��置を表わしている。利用者が入力装置40を� �って所望の遷移コマンドの表示メッセージ21 3にカーソル214を合わせ、決定ボタン215を押� �ことにより、コンテンツ再生に用いるプレ� �リストを変更することができる。なおここ� �、現在使用できない状態にある遷移コマン� �の表示メッセージ213を表示しない処理を行� �ても良い。例えば、「1」~「5」の順位があ� �プレイリスト構造データが使われており、� �在「5」の順位のプレイリストが選択されて� ��る場合は、それ以上順位の数値を増やすこ� ��は出来ないので、順位の数値を増やす遷移� ��マンドの表示メッセージ213を表示しないよ� ��にしても良い。

 また、再生中止ボタン216があり、利用者� ��このボタン216を押すと、再生中止コマンド� ��して制御部35に検知される。遷移コマンド� �再生中止コマンドを合わせて、以下ではコ� �ンドと表記する。また、画面中央部にはコ� �テンツ再生領域217があるが、コンテンツの� �類によっては省略しても良い。また、タイ� �ル211、制作者212、遷移コマンド等の情報を� �ンテンツ再生領域217にオーバーラップして� �示するようにしても良い。

 図17の説明に戻り、制御部35は、コンテン ツの再生が終了したか否かを判定し(S640)、再 生が終了した場合(S640“YES”)、S610に戻り、� �ンテンツ取得部32に現在使用中のプレイリス ト内で次の再生順序のコンテンツを取得させ る。

 これに対し、コンテンツの再生が終了し� ��いない場合(S640“NO”)、制御部35は、利用者 によりコマンド入力があるか否かを判断し(S6 50)、コマンド入力がない場合(S650“NO”)、S640 に戻り処理を繰り返す。

 その一方、コマンド入力がある場合(S650� �YES”)、制御部35は、入力されたコマンドが� �生中止コマンドであるか否かを判断し(S660)� �再生中止コマンドの場合(S660“YES”)、コン� �ンツ再生処理を終了する。

 これに対し、再生終了コマンドでない場� ��(S660“NO”)、制御部35は、プレイリスト構造 データおよび入力された遷移コマンドに基づ いてコンテンツ再生に用いる一のプレイリス トを変更し、新たなプレイリストIDを状態記� ��部36に記憶し(S670)、S610の処理に戻り、S610以 降の処理の処理を繰り返す。

 なお、プレイリスト記憶部30または状態� �憶部36に、各プレイリスト毎に再生したコン テンツの情報を記憶し、ステップS610におい� �、該当するプレイリストの先頭のコンテン� �からではなく、該当するプレイリストで前� �再生したコンテンツの次の再生順序を持つ� �ンテンツから取得するようにしても良い。� �のような処理を行うことで、プレイリスト� �切り替えた時に、同じコンテンツが頻繁に� �生されることを防ぐことが可能になり、利� �者が飽きにくいという効果が得られる。ま� �、必ずしもプレイリストに記述された再生� �序通りにコンテンツを再生する必要はなく� �再生順序をランダムに決めたり、再生順序� �変更して再生しても良い。

 図19は、図17のS670のプレイリスト変更処� �を詳細に示すフローチャートである。

 図17のS670のプレイリスト変更処理では、� ��ず、制御部35は、入力された遷移コマンド� �対応する遷移コマンドデータの「方向」お� �び「変化量」をプレイリスト構造データ記� �部31から読み出す(S800)。その際、プレイリス トが複数の階層で構成されていて、図11に示� ��たように遷移コマンドデータに「階層」が� ��まれている場合は、「階層」も読み出す。� ��下の処理は、ここで読み出した「階層」を� ��象にして行う。

 次に、制御部35は、プレイリスト構造デ� �タ記憶部31に記憶されているプレイリスト構 造データの中から、状態記憶部36に記憶され� ��いる使用中のプレイリストのプレイリストI Dに該当する数値を読み出し、その数値とS800� ��読み出した方向および変化量とを用いて、� ��たなプレイリストのプレイリストIDを選出� �(S810)、状態記憶部36に記憶する(S820)。このS81 0の処理の詳細は、プレイリスト構造データ� �格納形式によって異なる。

 次に、図19におけるS810の処理の詳細につ� ��て、プレイリスト構造データの形式別に説� ��する。

 まず、プレイリスト構造データが図5に示 す「順位」を用いた第1形式、または図6に示� ��「座標値」を用いた第2形式である場合につ いて説明する。この場合は、プレイリスト構 造データの内から、状態記憶部36に記憶され� ��いる使用中のプレイリストのプレイリストI Dに該当する数値である順位または座標値を� �み出し、その数値とS800で読み出した方向お� ��び変化量を用いて加算や減算等の数値演算� ��行い、数値演算の結果に基づき新たなプレ� ��リストのプレイリストIDを選出する。

 図20は、プレイリスト構造データが図5に� ��す「順位」を用いた第1形式、または図6に� �す「座標値」を用いた第2形式である場合のS 810の詳細な処理を示すフローチャートである 。

 まず、制御部35は、S800で読み出した「方� ��」が「0」であるか「+」であるか「-」であ� ��かを判定し(S900)、「0」である場合はS910に� �む一方、「+」である場合はS930に進み、「-� �である場合はS940に進む。

 S910では、制御部35は、「+」か「-」の方� �を、乱数を用いてランダムに決定し、続くS9 20により、S910で決定された方向が「+」であ� �か判定し、「+」である場合はS930に進み、「 -」である場合はS940に進む。

 次にS930では、制御部35は、使用中のプレ� ��リスト、すなわち状態記憶部36に格納され� �いるプレイリストIDに対応するプレイリスト の「順位」または「座標値」をプレイリスト 構造データ記憶部31から読み出し、この値にS 800で読み出した「変化量」を加算した値を算 出する。複数の次元を持つ座標値の場合は、 次元毎に加算する。そしてS950に進む。

 一方、S940では、制御部35は、使用中のプ� ��イリストの「順位」または「座標値」をプ� ��イリスト構造データ記憶部31から読み出し� �この値からS800で読み出した「変化量」を減� ��した値を算出し、S950に進む。

 そして、S950では、制御部35は、プレイリ� ��ト構造データ記憶部31を参照しながら、S930� ��たはS940で算出した値に最も近い、すなわち 差が小さい「順位」または「座標値」を持つ プレイリストのプレイリストIDを選定する。� ��の時に、現在使用中のプレイリストである� ��態記憶部36に記憶されているプレイリストID に対応するプレイリストを除外して選定する ようにし、プレイリストの変更が必ず行われ るようにする。

 以上がプレイリスト構造データに「順位� ��または「座標値」が用いられている場合のS 810の処理の詳細である。上述した処理におい て、遷移コマンドデータの方向および変化量 は、変更前のプレイリストである使用中のプ レイリストと、変更後のプレイリストである 新たなプレイリストとのプレイリスト構造デ ータ内の数値の違い、すなわち順位または座 標値の差に関する目標値であると言える。遷 移コマンドデータの方向および変化量に完全 に一致するようにプレイリストの変更が行わ れるとは限らないが、それに近い条件のプレ イリストが新たに選出される。

 ここで、図5(B)および図9(A)に示した「順� �」を用いた一例における具体的な数値例を� �す。状態記憶部36に格納されているプレイリ ストIDが「Classic」(順位「1」)であり、図9(A)� �「コマンド3」(方向「+」、変化量「1」)が選 択された場合、S930において「1+1=2」という演 算が行われ、S950において、順位「2」に相当� ��る(最も近い)プレイリストIDである「Easy Lis tening」が選定される。

 次に、図6(B)および図9(B)に示した「座標� �」を用いた一例における具体的な数値例を� �す。ただし、座標系の次元数は1であり、図9 (B)の次元1に相当する数値のみ格納されてい� �ものとする。状態記憶部36に格納されている プレイリストIDが「Easy Listening」(座標値「0.6 」)であり、図9(B)の「コマンド3」(方向「+」� ��変化量「0.2」が選択された場合、S930におい て「0.6+0.2=0.8」という演算が行われ、S950にお いて、座標値「0.8」に相当する(最も近い)プ� ��イリストIDである「Folk」(座標値「0.8」)が� �定される。この例の場合は、演算の結果得� �れた目標座標値と、プレイリスト構造デー� �にあるプレイリストの座標値が完全に一致� �るが、もちろん一致しない場合もある。

 次に、プレイリスト構造データが、図7に 示す「類似度」を用いた形式である場合のS81 0の処理について説明する。この場合は、プ� �イリスト構造データの中から、状態記憶部36 に記憶されているプレイリストIDである使用� ��のプレイリストに関連する全ての数値(類似 度)を読み出し、それらの数値とS800で読み出� ��た変化量との比較演算を行い、比較演算の� ��果に基づき新たなプレイリストのプレイリ� ��トIDを選出する。この処理の詳細について� �図21に示すフローチャートを用いて説明する 。

 まず、制御部35は、プレイリスト構造デ� �タである類似度の行列データの中から状態� �憶部36に記憶されているプレイリストIDに該� ��する列を読み出す(S1500)。

 次に制御部35は、この列のデータの中か� �S800で読み出した「変化量」との差が最も少� ��い値を持つ要素を選択する(S1510)。「変化量 」との差が同じ要素が複数ある場合は、その うちのどれか1つを、乱数などを用いて適当� �選べば良い。

 そして制御部35は、S1510で選択された要素 に該当するプレイリストのプレイリストIDを� ��択し(S1520)、S810を終了する。

 ここで、図7(B)および図9(C)に示した「類� �度」を用いた一例における具体的な数値例� �示す。状態記憶部36に格納されているプレイ リストIDが「Easy Listening」であり、図9(C)の「 コマンド2」(変化量「0.4」)が選択された場合 、S1500において、図7(B)の行列データから「Eas y Listening」の列(「0.8」、「1.0」、「0.7」、� �0.3」、「0.1」)が読み出される。S1510では、� �れらの数値の中から変化量「0.4」に最も近� �値を持つ要素「0.3」を選択する。そしてS1520 で、それに該当するプレイリストIDである「R ock」を選定する。

 類似度を用いたプレイリスト構造データ� ��場合でも同様に、遷移コマンドデータの変� ��量は、変更前のプレイリストである使用中� ��プレイリストと、変更後のプレイリストで� ��る新たなプレイリストとの類似度に関する� ��標値であると言える。「類似度」と「違い� ��度合」は、対をなす概念であるので、遷移� ��マンドデータの変化量は、変更前のプレイ� ��ストと変更後のプレイリストの違いの度合� ��関する目標値であるとも言える。

 以上がコンテンツ再生処理の説明である� ��上述したコンテンツ再生処理により、プレ� ��リストの名称を表示装置41に表示して利用� �に選択させる方法に比べて、より直感的な� �作が可能になる。

 なお、実施例1では、図17に示したフロー� ��ャートのS600において、再生に使用するプレ イリストの初期設定を行っているが、これに 限定される訳ではなく、このステップを別の 方法に変えることも可能である。例えば、コ ンテンツ再生処理の最初において、利用者に 所望のコンテンツを選択させ、そのコンテン ツを含むプレイリストをプレイリストの初期 値として用いても良い。

 上述した方法において利用者は、現在再� ��中のコンテンツを基準にした相対的な変化� ��意識して遷移コマンドを選択すればよい。� ��般的に、現在再生中のコンテンツを基準に� ��て相対的な変化を予想することは容易であ� ��。その一方、プレイリストの名称等を表示� ��置に表示して利用者に選択させる方法では� ��利用者は再生中のコンテンツとは関係なく� ��文字情報だけを頼りに各々のプレイリスト� ��内容を予想する必要があり、直感的な操作� ��やり難い。例えば、「刺激が非常に強い」� ��「刺激がやや強い」、「刺激がやや弱い」� ��「刺激が非常に弱い」等々の名称のプレイ� ��ストがあった場合、それらの名称を見るこ� ��だけで、各プレイリストの刺激の絶対的な� ��度を予想し、それらに対応するコンテンツ� ��事前に(再生前に)予想することは、かなり� �しい。一方で、現在再生中のコンテンツを� �準にして、「少し刺激を強く」あるいは「� �し刺激を弱く」といった相対的な変化を示� �選択肢を選択することは、再生中のコンテ� �ツという具体的な判断基準があることと、� �字情報だけでなく、コンテンツに関わる聴� �情報/視覚情報などの手掛かりを使って判断� ��きるため、利用者にとって直感的であり、� ��較的容易である。

 このように、本実施例によれば、サーバ� ��置1は、複数のプレイリスト間の関係を数値 で表したプレイリスト構造データを、ネット ワーク3を介し端末装置2に対し送信し、端末� ��置2ではそのプレイリスト構造データを受信 して、コンテンツ再生の際、プレイリスト構 造データに基づいてコンテンツのプレイリス トを変更して、変更したプレイリストのコン テンツを再生するようにしたので、大量のコ ンテンツの中から、その時々の利用者の気分 に合ったコンテンツを簡単な操作で再生でき る。

 また、実施例1では、プレイリスト構造デ ータ毎に、対応する複数のプレイリスト間の 変更する方向と変化量とを示す遷移コマンド と、その遷移コマンドの変化量に応じた表示 メッセージとが付加されているので、端末装 置2では、その表示メッセージを表示して利� �者に選択させることにより、再生コンテン� �をプレイリストを基準にして、それとの相� �的な変化を指定する方法で、別のプレイリ� �トに切り替えてコンテンツ再生することが� �きる。

 そのため、事前に複数の印象の遷移を指� ��したプレイリストを作成する手間が不要で� ��り、様々なプレイリストを直感的な操作で� ��り替えながらコンテンツを再生できる。そ� ��結果、コンテンツ購入前にサーバ装置1の提 供する大量のコンテンツを試聴させる用途な どにも好適である。

 更に、実施例1によれば、端末装置2の利� �者は、複数のプレイリスト構造データの中� �ら好みのものをサーバ装置1に対し要求し送� ��させて使用することができるので、プレイ� ��ストの変化の仕方を自分の好みに合わせて� ��定することができる。そのため、利用者の� ��みに応じてプレイリスト構造データを変更� ��ることにより、利用者が既に使用している� ��ンテンツについても、プレイリストの変化� ��仕方が新しいものになるので、利用者が飽� ��にくく、利用者のコンテンツや配信サービ� ��に対する興味や関心を維持し易い。また、� ��用者は、既に知っている馴染みのコンテン� ��を再生する場合でも、プレイリスト構造デ� ��タにより、再生コンテンツのプレイリスト� ��変更しながらコンテンツを再生するので、� ��ンテンツ同士の意外な類似性/共通性を発見 する等のチャンスが増え、多面的にコンテン ツを楽しむことができる。

[実施例2]
 次に本発明の実施例2を説明する。実施例2� �システム全体の構成は、図1と同様であるが� ��サーバ装置1の代わりにサーバ装置1aがネッ� ��ワーク3を介して端末装置2と接続されてい� �。実施例2における端末装置2の構成および処 理動作は、実施例1と同じであるので、サー� �装置1aについてのみ説明する。

 図22は、実施例2のサーバ装置1aの構成例� �示している。

 実施例2のサーバ装置1aでは、実施例1のサ ーバ装置1の構成と比べて、音響分析部14と、 コンテンツ格納部15と、プレイリスト作成部1 6とが追加されている他、制御部13aが若干異� �る。他の構成要素は実施例1と同じである。� ��お、本実施例2では、サーバ装置1aにコンテ� ��ツ格納部15を設けているが、コンテンツを� �ーバ装置1aとは別の装置に格納し、コンテン ツ取得手段をサーバ装置1aに設けるようにし� ��も良い。

 実施例2においては、コンテンツであるオ ーディオデータ、ないしはコンテンツに付随 または含まれるオーディオデータを音響分析 部14で分析することにより、コンテンツの音� ��ジャンルおよびコンテンツの持つ雰囲気を� ��動的に判別して利用する。本実施例におけ� ��コンテンツは、例えば、音楽オーディオデ� ��タ、ミュージックビデオ等の音声付映像デ� ��タ、静止画と音楽オーディオデータを合わ� ��たスライドショーのデータなどである。

 コンテンツ格納部15は、プレイリスト格� �部10に格納されたプレイリストに記述されて いるコンテンツを含む配信ファイルを格納し ている。

 図23は、実施例2においてコンテンツ格納� ��15に格納される配信ファイルの格納形式の� �例を示している。各々の配信ファイルは、� �23に示すように、ヘッダ61とコンテンツ本体6 2とで構成されている。ヘッダ61aには、コン� �ンツのタイトル、制作者(アーティスト)、ジ ャンル、制作年代等のコンテンツの属性情報 と、音響分析フラグと、分類カテゴリが含ま れている。

 図24は、実施例2の音響分析部14の音響分� �処理を示すフローチャートである。

 この音響分析処理は、制御部13aがコンテ� ��ツ格納部15に新しい配信ファイルが追加さ� �たことを検出し、音響処理部14に指示を与え ることにより開始される。また、サーバ装置 1aの管理者が入力装置20を介してサーバ装置1a に音響分析処理の開始を指示しても良い。

 つまり、音響分析部14は、コンテンツ格� �部15からまだ音響分析処理を行っていない未 処理のコンテンツを探す(S1000)。音響分析処� �を行った配信ファイルのヘッダ61aには、後� �するように音響分析済みを示すフラグが記� �されることになっており、これを調べるこ� �により、音響分析処理の有無を確認するこ� �ができる。

 次に、音響分析部14は、音響分析処理が� �処理の配信ファイルが有るか否かを判断し(S 1010)、未処理の配信ファイルが無い場合は(S10 10“NO”)、処理を終了する一方、未処理の配� ��ファイルがある場合は(S1010“YES”)、配信フ ァイルのコンテンツ本体62に含まれるオーデ� ��オデータを読み出し、音響特徴量を抽出す� ��(S1020)。

 音響特徴量を抽出する方法としては、例� ��ば、特開2007-322598号公報に開示されている� �術を用いることができる。またこの他に、� �ーディオ信号の強度、周波数分布、テンポ� �ビート強度などを検出して音響特徴量とし� �も良い。更に、オーディオデータを分析し� �オーディオデータの中で音楽が記録されて� �ると推定できる区間を特定した後、その区� �を対象にして音響特徴量を抽出するように� �ても良い。

 次に、音響分析部14は、音響特徴量を用� �てコンテンツを所定の分類カテゴリに対応� �せる(S1030)。音響特徴量を分類カテゴリに対� ��させる方法としても、特開2007-322598号公報� �開示されている技術を用いることができる� �分類カテゴリとしては、「クラシック」、� �ロック」、「ジャズ」などの音楽ジャンル� �用いることができる。また「静か」、「力� �い」、「ノリの良い」といったコンテンツ� �持つ雰囲気を分類カテゴリとすることもで� �る。

 次に、音響分析部14は、S1030の処理の結果 得られた分類カテゴリを配信ファイルに記録 し、コンテンツ格納部15に格納し(S1040)、S1000� ��処理に戻る。

 コンテンツが作成された段階では、音響� ��析フラグは「0」にセットされている。S1040� ��おいて分類カテゴリを記録すると同時に、� ��響分析フラグを「1」に変更する。以上が音 響分析処理の説明である。なお、S1030におい� ��、1つのコンテンツを複数の分類カテゴリに 対応させ、S1040において、1つのコンテンツの 配信ファイルに複数の分類カテゴリを記録し ても良い。

 プレイリスト構造データ格納部11は、実� �例1と同様であるが、プレイリストIDとして� �上述した分類カテゴリに対応するものが記� �されている。

 次に、プレイリスト作成部16におけるプ� �イリスト作成処理について、図25のフローチ ャートを用いて説明する。

 まずプレイリスト作成部16が、コンテン� �格納部15から配信ファイルを順次読み出して 、分類カテゴリ別のコンテンツ集合を作成す る(S1500)。

 次にプレイリスト作成部16は、S1500で作成 されたコンテンツ集合毎にコンテンツの再生 順序を決定する(S1510)。再生順序は配信ファ� �ルのヘッダ情報を用いて決めることができ� �。例えば、制作年代の古い順にしたり、タ� �トルや制作者の表記で順序を決めれば良い� �なお、1つのコンテンツ集合に含まれるコン� ��ンツ全てをプレイリストに入れる必要はな� ��、1つのプレイリストに入れるコンテンツ数 を制限しても良い。また、コンテンツ集合に 含まれるコンテンツの再生順序を、サーバ装 置1の運営者または端末装置2の利用者に決め� ��せても良い。

 次にプレイリスト作成部16は、再生順序� �、コンテンツの取得情報を関連付けてコン� �ンツ集合毎のプレイリストを作成し、プレ� �リスト格納部10に格納する(S1520)。プレイリ� �ト格納部10におけるプレイリストIDは、プレ� ��リスト構造データ格納部11におけるプレイ� �ストIDと同じであり、音響分析部14で用いた� ��類カテゴリに対応したものである。以上が� ��レイリスト作成処理である。

 従って、実施例1のサーバ装置1では、コ� �テンツ制作者またはサーバ装置1の運営者や� ��理者がプレイリストを作成する必要があっ� ��が、実施例2のサーバ装置1aによれば、音響� ��析部14やプレイリスト作成部16等により、人 手を介することなく、自動的にプレイリスト を作成することができる。

 このように、実施例2によれば、実施例1� �効果に加え、さらに、コンテンツ配信に関� �る工数やコストを大幅に削減することがで� �る。また、実施例1と実施例2を合わせること により、人手により作成されたプレイリスト と、音響分析により自動的に作成されたプレ イリストを併用することも可能であり、より 多様で多面的なプレイリストを提供すること が可能になる。

[実施例3]
 次に本発明の実施例3を説明する。

 図26は、実施例3のシステム全体の構成を� ��すブロック図である。

 実施例3におけるサーバ装置として、図2� �示す実施例1のサーバ装置1と、図22に示す実� ��例2のサーバ装置1aのどちらでも用いること� ��できるが、説明の簡略化のため、以下では� ��ーバ装置1と記述する。また、サーバ装置の 動作は、実施例1または実施例2と同じである� ��で、説明を省略する。

 実施例3では、ネットワーク3を介してサ� �バ装置1に接続されている端末装置2aに、再� �装置4がインタフェース5を介して接続されて いる。端末装置2aと再生装置4との接続は、随 時切り離すことが可能になっている。インタ フェース5としては、有線/無線LANや、USB、IEEE 1394等の各種インタフェースを用いることが� �きる。またメモリカード等を用いて端末装� �2aと再生装置4とのデータ交換を行って、イ� �タフェース5の代わりとしても良い。

 図27は、端末装置2aの構成例を示すブロッ ク図である。

 図27において、端末装置2aは、プレイリス ト記憶部30と、プレイリスト構造データ記憶� ��31と、コンテンツ取得部32aと、送受信部34と 、制御部35aと、インタフェース制御部38と、� ��ンテンツ記憶部50とを有しており、入力装� �40と、表示装置41が接続されている。

 図28は、再生装置4の構成例を示すブロッ� ��図である。

 図28において、再生装置4は、プレイリス� ��記憶部30bと、プレイリスト構造データ記憶� ��31bと、コンテンツ取得部32bと、再生部33bと� ��制御部35bと、状態記憶部36bと、インタフェ� ��ス制御部38bと、コンテンツ記憶部50bを有し� ��おり、入力装置40bと、表示装置41bと、音声� ��力装置42bが接続されている。なお、再生装� ��4と、入力装置40bおよび表示装置41bおよび音 声出力装置42bとを1つの装置として構成し、� �帯型の再生装置としても良い。

 図29は、電源投入直後に、端末装置2aの制 御部35aが表示装置41に表示するメニュー画面2 91の一例を示している。

 図29に示すメニュー画面291では、「制御� �データのダウンロード」と、「コンテンツ� �ダウンロード」と、「再生装置への転送」� �3種類のメニューを表示している。左側の矢� ��は、カーソル292の位置を表わしている。利� ��者が入力装置40を使って所望のメニュー項� �にカーソル292を合わせ、決定ボタン293を押� �ことにより、各メニュー項目に対応した処� �が開始される。

 ここで、利用者が「1:制御用データのダ� �ンロード」のメニュー項目を選択した場合� �端末装置2aおよびサーバ装置1の動作は、実� �例1と同様である。

 図30は、利用者が図29に示すメニュー画面 131から「2:コンテンツのダウンロード」のメ� ��ュー項目を選択した場合の端末装置2および サーバ装置1におけるコンテンツのダウンロ� �ド処理を示すフローチャートである。

 まず、端末装置2aの制御部35aが、プレイ� �スト格納部30を読み出して、コンテンツダウ ンロード処理を行っていない未処理のプレイ リストがあるか否か判定する(S1600)。プレイ� �スト格納部30には、プレイリスト毎にダウン ロード処理を行ったか否かを示すフラグが記 録されている。

 次に、端末装置2aの制御部35aが、未処理� �プレイリストを1つ選択する(S1610)。

 そして、端末装置2aのコンテンツ取得部32 aが、S1610で選択されたプレイリストに従って コンテンツを順次取得し、コンテンツ記憶部 50に記憶する(S1620)。具体的には、プレイリス ト格納部30を参照しながら、該当するプレイ� ��ストに記述されている再生順序に従って、� ��ンテンツの取得情報を読み出し、送受信手� ��34を介してコンテンツを取得し、コンテン� �記憶部50に記憶する。コンテンツの配信ファ イルは、サーバ装置1、あるいは端末装置2か� ��アクセス可能な他の装置に配置されている� ��

 次に、端末装置2aのコンテンツ取得部32a� �、S1610で選択されたプレイリストに記述され ている全てのコンテンツを取得したか否かを 判定する(S1630)。全て取得した場合はS1640に進 み、そうでない場合はS1620に戻り、次のコン� ��ンツを取得する。

 S1640では、端末装置2aの制御部35aが、プレ イリスト格納部30に記録されているダウンロ� ��ド処理済みを示すフラグを設定する。そし� ��、S1600に戻って以上の処理を繰り返す。以� �がコンテンツのダウンロード処理である。� �お、端末装置2のコンテンツ記憶部50にあら� �じめコンテンツを記憶させておけば、コン� �ンツのダウンロード処理を省略しても良い� �

 図31は、利用者が図29に示すメニュー画面 131から「3:再生装置へ転送」のメニュー項目� ��選択した場合の端末装置2aおよび再生装置4� ��動作を示すフローチャートである。

 まず、端末装置2aのインタフェース制御� �38は、インタフェース5を介して再生装置4と� ��続され、データを受信できる状態にあるか� ��かチェックする(S1100)。データ受信不可状態 であれば(S1100“YES”)、警告メッセージ等を� �示装置41に表示し(S1110)、その後の処理を終� �する。

 これに対し、データ受信可能あれば(S1100� ��YES”)、インタフェース制御部38は、プレイ� ��スト構造データ記憶部31からプレイリスト� �造データを読み出すと共に、プレイリスト� �憶部30からプレイリストを読み出し、インタ フェース5を介して再生装置4に送信する(S1120) 。

 すると、再生装置4では、インタフェース 制御部38bが、端末装置2aからのプレイリスト� ��造データを受信し、プレイリスト構造デー� ��記憶部31bに記憶する一方、プレイリストを� ��信してプレイリスト記憶部30bに記憶する(S11 30)。この際、必要あれば、インタフェース制 御部38bまたは制御部35bは、プレイリストに記 述されているコンテンツの取得情報によりコ ンテンツ記憶部50bに記憶されているコンテン ツを参照できるように、コンテンツの取得情 報を変更する。なお、図28に示す場合、取得� ��報は、再生装置4のコンテンツ取得部32bが同 一装置のコンテンツ記憶部50bからコンテンツ を読み出すための情報なので、必ずしもURL等 を使う必要はなく、再生装置4でコンテンツ� �一意に識別できるコンテンツIDやファイルの パス名などを用いても良い。

 次に、端末装置2aのインタフェース制御� �38は、コンテンツ記憶部50に格納されている� ��ンテンツをインタフェース5を介して再生装 置4に送信する(S1140)。

 すると、再生装置4では、インタフェース 制御部38bがそのデータを受信し、再生装置4� �コンテンツ記憶部50bに記憶し(S1150)、次いで� ��末装置2に転送完了メッセージを送信する(S1 160)。

 端末装置2aでは、再生装置4からの転送完� ��メッセージを受信すると(S1170)、処理を終了 する。

 以上が端末装置2aから再生装置4への転送� ��理である。転送処理が完了すると、利用者� ��適宜、再生装置4をインタフェース5から切� �離して再生動作を開始できる。

 再生装置4の再生動作は、図17のフローチ� ��ートに示した実施例1における端末装置2の� �生動作と同様である。すなわち、再生装置4� ��プレイリスト記憶部30bと端末装置2のプレイ リスト記憶部30、再生装置4のプレイリスト構 造データ記憶部31bと端末装置2のプレイリス� �構造データ記憶部31、再生装置4のコンテン� �取得部32bと端末装置2のコンテンツ取得部32� �再生装置4の再生部33bと端末装置2の再生部33� ��再生装置4の制御部35bと端末装置2の制御部35 、再生装置4の状態記憶部36bと端末装置2の状� ��記憶部36は、各々同じ動作を行う。ただし� �再生装置4のコンテンツ取得部32bの動作は、� ��末装置2のコンテンツ取得部32の動作と異な� ��、再生時に使用するコンテンツは既にコン� ��ンツ記憶部50bに記憶されているので、コン� ��ンツ記憶部50bからコンテンツを取得すれば� ��い。サーバ装置1やネットワーク3上の他の� �置からコンテンツを取得する必要はない。

 このように、実施例3によれば、ネットワ ーク3を介してサーバ装置1と直接接続できな� ��再生装置4においても、通信機能を有する端 末装置2aを介してサーバ装置1と接続して、プ レイリスト構造データ、プレイリスト、コン テンツなどをダウンロードすることにより、 複数のプレイリストを簡単に切り替えながら コンテンツの再生ができるので、利用者のそ の時々の気分に合ったコンテンツを再生でき る。

[実施例4]
 次に、本発明の実施例4を説明する。

 図32は、実施例4のサーバ装置1cの構成例� �示すブロック図である。

 実施例4のサーバ装置1cは、プレイリスト� ��納部10と、プレイリスト構造データ格納部11 と、送受信部12と、制御部13cと、コンテンツ� ��得部32cと、状態記憶部36cとを有しており、� ��力装置20と、表示装置21が接続されている。 ここで、プレイリスト格納部10、プレイリス� ��構造データ格納部11および送受信部12は、実 施例1のものと同じ動作である。また、コン� �ンツ取得部32cおよび状態記憶部36cは、各々� �施例1における端末装置2のコンテンツ取得部 32および状態記憶部36と同様な動作を行う。� �た、本実施例4では省略するが、実施例2と同 様にサーバ装置1cが音響分析部14、プレイリ� �ト作成部16を持つようにしても良い。また、 実施例2と同様に、サーバ装置1cがコンテンツ を格納するコンテンツ格納手段を備えていて も良い。

 図33は、実施例4の端末装置2cの構成例を� �すブロック図である。

 実施例4の端末装置2cは、再生部33と、送� �信部34と、制御部35cと、遷移コマンドデータ 記憶部39とを有しており、入力装置40と、表� �装置41と、音声出力装置42が接続されている� ��本実施例4においては、端末装置2cは、プレ� ��リストと、プレイリスト構造データを記憶� ��なくても良い。

 遷移コマンドデータ記憶部39には、図9ま� ��は図11に示すような遷移コマンドデータが� �憶されている。また、遷移コマンドデータ� �憶部39には、遷移コマンドデータに対応する プレイリスト構造データIDが記憶されている� ��これらのデータは、実施例1のプレイリスト ダウンロード処理と同様に、所定のメニュー 選択によりサーバ装置1cから端末装置2cに送� �するようにしても良いし、再生処理に先立� �てこれらのデータをサーバ装置1cから送信す るようにしても良い。ただし、実施例1とは� �なり、プレイリストおよびプレイリスト構� �データは送信する必要はなく、遷移コマン� �データとプレイリスト構造データIDを制御用 データとしてサーバ装置1cから端末装置2cに� �信すれば良い。また、あらかじめ端末装置2c に遷移コマンドデータとプレイリスト構造デ ータIDを記憶させておいても良い。更に、サ� ��バ装置1cのプレイリスト構造データ格納部11 において、1種類のプレイリスト構造データ� �み格納されている場合は、遷移コマンドデ� �タ記憶部39にプレイリスト構造データIDを記� ��させること、および後述するS1200における� �レイリスト構造データIDの送信を省略しても 良い。

 次に動作を説明する。

 図34は、実施例4のサーバ装置1cおよび端� �装置2cにおけるコンテンツ再生処理を示すフ ローチャートである。

 再生処理は、利用者が入力装置40を介し� �端末装置2cに所定の指示を与えることにより 開始される。

 まず、端末装置2cの制御部35cは、遷移コ� �ンドデータ記憶部39からプレイリスト構造デ ータIDを読み出し、これを再生開始メッセー� ��に含めて、送受信部34を介してサーバ装置1c に送信する(S1200)。

 すると、サーバ装置1cでは、制御部13cが� �受信部12を介して再生開始メッセージを受信 して(ステップS1210)、再生開始メッセージに� �まれるプレイリスト構造データIDを状態記憶 部36cに記憶する。

 次に、制御部13cは、プレイリスト構造デ� ��タ格納部11から、状態記憶部36cに記憶され� �いるプレイリスト構造データIDに対応するプ レイリスト構造データを読み出し、そのプレ イリスト構造データに含まれるプレイリスト IDの中から再生に使用するプレイリストIDを1� ��、初期値として選択して、それを状態記憶� ��36cに記憶する(S1220)。プレイリスト構造デー タが複数の階層で構成されている場合は、例 えば最下位の階層のプレイリストIDを選択す� ��。

 次に、コンテンツ取得部32cが、状態記憶� ��36cに記憶されているプレイリストIDのプレ� �リストに従って、コンテンツを取得する(S123 0)。具体的には、プレイリスト格納部10を参� �しながら、該当するプレイリストに記述さ� �ている再生順序に従って、コンテンツの取� �情報を読み出し、送受信手段12を介してコン テンツを取得し、コンテンツ取得部32cに一時 的に記憶する。コンテンツは、サーバ装置1c� ��コンテンツ格納手段(図32には不図示)または サーバ装置1からアクセス可能な他の装置に� �置されている。なお、サーバ装置1cがコンテ ンツ格納手段を持つ場合には、この取得情報 は必ずしもURL等である必要はなく、コンテン ツ格納手段内でコンテンツを一意に識別でき るコンテンツIDまたはファイルのパス名など� ��取得情報として用いても良い。

 次に、制御部13cは、コンテンツ取得部32c� ��記憶されているコンテンツを読み出し、配� ��ファイル等として送受信部12を介して端末� �置2cにストリーミング送信する(S1240)。コン� �ンツには、コンテンツの情報が記述された� �ッダ61とコンテンツ本体62とが含まれている� ��

 すると、端末装置2cでは、制御部35cが送� �信部34を介してコンテンツを受信し、再生部 33がデコード等の必要な処理を行った後に、� ��示装置41および音声出力装置42に出力してコ ンテンツを再生する(S1250)。サーバ装置1cはス トリーミング送信しているので、端末装置2c� ��配信ファイル全体を受信しなくてもコンテ� ��ツの再生を開始することが可能である。

 次に、制御部35cは、受信したコンテンツ� ��ヘッダ61に含まれるコンテンツの情報を表� �装置41に表示すると共に、遷移コマンドデー タ記憶部39を読み出して、プレイリストを変� ��するための遷移コマンドを表示装置41に表� �する(S1260)。遷移コマンドデータ記憶部39に� �図9または図11に示すような形式で遷移コマ� �ドデータが格納されているので、コマンド1~ コマンドKに対応した表示メッセージを読み� �して表示する。表示画面は、上述した図18と 同様であり、この表示画面を使用しての利用 者の操作も図18の場合と同じであるので省略� ��る。

 次に、制御部35cは、状態変化があったか� ��かを判定する(S1270)。状態変化とは、1つの� �ンテンツの再生が終了したか、遷移コマン� �が入力されたか、再生中止コマンドが入力� �れたかのいずれかである。

 そして、状態変化があった場合のみ(S1270� ��YES”)、制御部35cは、状態変化の種類に応じ た状態変化メッセージ、すなわち、再生終了 メッセージ、再生中止メッセージ、遷移メッ セージのいずれかを送受信部34を介してサー� ��装置1cに送信する(S1280)。遷移メッセージの� ��合は、入力された遷移コマンドに対応した� ��階層、方向、変化量の情報もあわせて送信� ��る。

 すると、サーバ装置1cでは、制御部13cが� �送受信部12を介して状態変化メッセージを受 信し(S1290)、受信した状態変化メッセージが� �再生終了メッセージであるか否かを判定す� �(S1300)。再生終了メッセージの場合(S1300“YES� ��)、S1230の処理に戻り、コンテンツ取得部32c� ��次のコンテンツを取得させる。

 これに対し、再生終了メッセージでない� ��合(S1300“NO”)、制御部13cは、再生中止メッ� ��ージであるか否かを判定し(S1310)、再生中止 メッセージの場合は(S1310“YES”)、コンテン� �再生処理を終了する。

 一方、再生中止メッセージでない場合は( S1310“NO”)、遷移メッセージの場合であるの� ��、制御部13cは、遷移メッセージに含まれる� ��階層」、「方向」、「変化量」の情報と、S 1210の処理によりサーバ装置1cの状態記憶部36c に記憶されたプレイリスト構造データIDに対� ��するプレイリスト構造データに基づいてプ� ��イリストを変更し(S1320)、変更した新たなプ レイリストのプレイリストIDを状態記憶部36c� ��記憶し、S1230に戻り、以上の処理を繰り返� �。なお、S1280で遷移メッセージを送信する際 に、階層、方向、変化量の情報を送信する代 わりに、遷移コマンドID(コマンド1~コマンドK のいずれか)を送信し、S1320においてサーバ装 置1cのプレイリスト構造データ格納部11に格� �されている遷移コマンドデータと送信され� �遷移コマンドIDを照合し、階層、方向、変化 量の情報を特定した上で、プレイリストを変 更するようにしても良い。

 ここで、S1210でサーバ装置1cの状態記憶部 36cに記憶されたプレイリスト構造データIDに� ��応するプレイリスト構造データが、図5に示 した「順位」を用いた形式、または図6に示� �た「座標値」を用いた形式である場合、S1320 における遷移メッセージに応じたプレイリス トの変更処理は、図20に示す実施例1の処理と ほぼ同じで、図20に示すS900~S950の処理を行っ� ��後、選定したプレイリストのプレイリストI Dを状態記憶部36cに記憶する。ただし実施例1� ��は異なり、端末装置2(2c)ではなく、サーバ� �置1cの各部により処理が行われる。

 プレイリスト構造データが、図7に示す「 類似度」を用いた形式である場合のS1320の詳� ��も、図21に示す実施例1の処理とほぼ同じで� ��り、図21に示すS1500~S1520の処理を行った後、 選定したプレイリストのプレイリストIDを状� ��記憶部36cに記憶する。この場合も実施例1と は異なり、端末装置2(2c)ではなく、サーバ装� ��1cの各部により処理が行われる。

 その他の処理は、実施例1~3と同様である� ��

 このように、実施例4によれば、サーバ装 置1cがストリームでコンテンツを配信する場� ��、端末装置2cではプレイリストおよびプレ� �リスト構造データを格納したり、プレイリ� �トに従ってコンテンツを取得する必要がな� �ので、安価なコストで端末装置2cを実現する ことができる。また、サーバ装置1cまたはネ� ��トワーク3上の他の装置に格納されたコンテ ンツを対象にして、様々なプレイリストを直 感的な操作で切り替えながらコンテンツを再 生できるので、コンテンツ購入前にサーバ装 置またはネットワーク3上の他の装置の提供� �る大量のコンテンツを試聴させる用途など� �も適している。

 なお、実施例4では、端末装置2cにプレイ� ��スト構造データ記憶部31を設けず、サーバ� �置1cからは端末装置2cにプレイリスト構造デ� ��タを送信していないが、本発明ではこれに� ��定するものではない。例えば、実施例1と同 様に、履歴コマンドデータ記憶部39に代えて� ��レイリスト構造データ記憶部31を端末装置2c に設け、サーバ装置1cから端末装置2cにプレ� �リスト構造データと遷移コマンドデータを� �信した上で、実施例1と同様にS1220およびS1320 に相当する処理を端末装置2cで行うと共に、S 1230のコンテンツ選出処理をサーバ装置1cで行 うようにしても良い。すなわち、端末装置2c� ��おいて、プレイリスト構造データ記憶部31� �記憶されたプレイリスト構造データに基づ� �選出したプレイリストIDを、端末装置2cから� ��ーバ装置1cに送信すると共に、サーバ装置1c において、プレイリスト格納部10を参照しな� ��ら、受信したプレイリストIDに対応するプ� �イリストに従ってコンテンツを取得し、そ� �を端末装置2cに送信するようにしても良い。

 以上、実施例1~4によれば、利用者のその� ��々の気分に合ったコンテンツを、プレイリ� ��トを用いて簡単な操作で再生できる。また� ��利用者は、再生中のプレイリストを基準に� ��て、それとの相対的な変化を指定する方法� ��、別のプレイリストに切り替えてコンテン� ��再生することができるので、直感的に操作� ��きる。

 また、様々なプレイリストを直感的な操� ��で切り替えながらコンテンツを再生できる� ��で、コンテンツ購入前にサーバ装置が提供� ��る大量のコンテンツを試聴させる用途など� ��も好適である。

 更に、利用者は複数のプレイリスト構造� ��ータの中から好みのものを選択して使用す� ��ことができるので、プレイリストの変化の� ��方を自分の好みに合わせて設定できる。プ� ��イリスト構造データを変更することにより� ��利用者が既に使用しているコンテンツにつ� ��ても、プレイリストの変化の仕方が新しい� ��のになるので、利用者が飽きにくく、利用� ��のコンテンツや配信サービスに対する興味� ��関心を維持し易い。

 なお、実施例1~4では、サーバ装置1または ネットワーク3上の他の装置が、コンテンツ� �配信ファイルとして配信するように説明し� �が、本発明では、これに限らず、コンテン� �はCDやDVD、BD等の光ディスク等のメディアに� ��って端末装置に提供するようにしても、さ� ��に、放送装置によって放送によって提供し� ��も勿論よい。このことは後述する実施例5~8� ��も同様である。

[実施例5]
 次に、本発明の実施例5~8を説明する。実施� ��1~4では、複数のプレイリスト間の関係を数� ��で表したプレイリスト構造データにより、� ��々なプレイリストを切替える例を説明した� ��、以下に説明する実施例5~8では、コンテン� ��をカテゴリにより分類した場合の複数の分� ��カテゴリ間の関係を数値で表した分類構造� ��ータにより、様々分類カテゴリのコンテン� ��を切替えるようにした例である。

 図35は、実施例5のサーバ装置1’の構成例 を示すブロック図である。

 図35において、図2に示す実施例1のサーバ 装置1との相違点は、プレイリスト格納部10の 代わりにコンテンツ格納部10’、プレイリス� ��構造データ格納部11の代わりに分類構造デ� �タ格納部11’を有しており、この点で制御部 13’も若干機能が変更されている。その他の� ��成要素は、図2と同じであるので、同一符号 を付して説明を省略する。なお、実施例5に� �いては、コンテンツ格納部10’と、分類構造 データ格納部11’とを同じサーバ装置1’内に 配置しているが、これらを別々のサーバ装置 に配置することも可能である。なお、実施例 5のサーバ装置1’も、図1に示すように端末装 置2’と接続される。なお、実施例5の端末装� ��2’の構成については、図43にて説明する。

 図36は、実施例5のサーバ装置1’から端末 装置2’に送信されるコンテンツの構造例を� �している。

 図36に示すように、配信ファイルである� �ンテンツは、ヘッダ61’と、コンテンツ本体 62とで構成されている。そして本実施例5のヘ ッダ61’には、コンテンツのタイトル、制作� ��(アーティスト)等のコンテンツの属性情報� �、分類カテゴリとが含まれている。

 分類カテゴリとは、ある基準に基づいて� ��ンテンツを複数のカテゴリに分類した結果� ��示す数値またはテキスト形式のデータであ� ��。例えば、コンテンツのジャンル、コンテ� ��ツの制作年代、コンテンツの持つ雰囲気、� ��ンテンツを再生するのに適する状況/場所、 などを分類カテゴリとして用いることができ る。1つの配信ファイルには1つの分類カテゴ� ��が含まれていても良いし、図36の例のよう� �複数の分類カテゴリ(分類カテゴリA、分類カ テゴリB)が含まれていても良い。

 なお、実施例5においては、サーバ装置1� �は、分類カテゴリがヘッダ61’に記録されて いるコンテンツを端末装置2’に対し送信す� �ものとして説明するが、これに限定される� �のでなく、コンテンツの配信ファイルに分� �カテゴリを含めず、分類カテゴリをコンテ� �ツと別に端末装置2’に送信するようにして� ��よいし、分類カテゴリ付きのコンテンツを� ��ーバ装置1’からでなく、DVD等により端末装 置2’に転送するようにしても良い。

 図37は、分類構造データ格納部11’が格納 するデータの一例を示す図である。実施例1� �図4に対応する。

 つまり、分類構造データ格納部11’は、� �37に示すような形式で、分類構造データIDと� ��複数の分類カテゴリ間の関係性を示す分類� ��造データと、遷移コマンドデータと、説明� ��ータとを関連付けて格納し、さらに最優先� ��造データIDを格納している。分類構造デー� �IDは、複数の分類構造データを一意に識別す るためのIDである。最優先構造データIDは、� �も優先して使用する分類構造データIDである 。図37の例では、M個の各データが格納されて いる(M≧1)。分類構造データは、複数ではな� �、1つだけ格納するようにしても良い。1つだ け格納する場合、分類構造データIDと、最優� ��構造データIDとを省略することも可能であ� �。また後述するように、遷移コマンドデー� �と説明データを省略することも可能である� �

 ここで、実施例5では、分類構造データの 基本的な形式として、以下の図38~図40の3つの 形式を用いる。

 図38は、分類構造データの第1形式の例を� ��している。実施例1の図5に対応する。

 図38(A)は、複数の分類カテゴリであるカ� �ゴリ1~カテゴリNと、それらを所定の基準に� �って順位付けた場合の順位1~Nとを対応させ� �もの、図38(B)は、分類カテゴリとして音楽ジ ャンルを用いた場合の分類構造データの第1� �式の一例である。実施例1の図5とは、“プレ イリストID”を“分類カテゴリ”に置き換え� ��けの違いであるので、説明を省略する。

 図39は、分類構造データの第2形式の例を� ��している。実施例1の図6に対応する。

 図39(A)は、複数の分類カテゴリであるカ� �ゴリ1~カテゴリNと、それらを所定の座標系� �配置した場合の座標値とを対応させたもの� �図39(B)は、分類カテゴリとして音楽ジャンル を用いた場合の分類構造データの第2形式の� �例である。実施例1の図6とは、“プレイリス トID”を“分類カテゴリ”に置き換えだけの� ��いであるので、説明を省略する。

 図40は、分類構造データの第3形式の例を� ��している。実施例1の図7に対応する。

 図40(A)は、複数の分類カテゴリであるカ� �ゴリ1~カテゴリN中の任意の2つのカテゴリ間� ��類似度を行列形式で表現したもの、図40(B)� �、分類カテゴリとして音楽ジャンルを用い� �場合の分類構造データの第3形式の一例であ� ��。実施例1の図7とは、“プレイリストID”を “分類カテゴリ”に置き換えだけの違いであ る。

 以上説明した図38~図40が、実施例5におけ� ��分類構造データの基本的な形式の一例であ� ��が、分類カテゴリを複数の階層にすること� ��可能である。

 図41は、分類カテゴリを複数の階層にし� �分類構造データの一例を示す図である。実� �例1の図8に対応する。

 図41では、実施例1の図8にける、“階層1(� ��位プレイリスト)”と、“階層2(下位プレイ� ��スト)”を、それぞれ、分類構造データの“ 階層1(上位カテゴリ)”と、“階層2(下位カテ� ��リ)”に置き換えだけの違いであるので、説 明は省略する。

 次に、分類構造データ格納部11’に格納� �れる遷移コマンドデータ(図37参照)について� ��明する。

 遷移コマンドデータは、後述するように� ��端末装置2’において分類カテゴリを変更す る際に使用するデータであり、実施例1の図9� ��図11等に示す遷移コマンドデータと同様で� �る。

 ただし、実施例5では、図42に示すように� ��分類構造データとして、類似度と順位を合� ��せて格納し、端末装置2’では、方向の判定 に順位を使い、変化量として類似度を使用す ることにより、類似度を用いても、方向性の あるコマンドを利用することも可能である。 また、類似度と座標値を合わせて格納し、端 末装置2’において方向の判定に座標値を使� �、変化量として類似度を使用しても良い。

 図43は、実施例5の端末装置2’の構成例を 示すブロック図である。

 図43において、端末装置2’は、図12に示� �実施例1の端末装置2’とは、プレイリスト記 憶部30の代わりにコンテンツ記憶部30’、プ� �イリスト構造データ記憶部31の代わりに分類 構造データ記憶部31’、コンテンツ取得部32� �代わりにコンテンツ選出部32’を有しており 、この点で制御部35’の機能も若干異なって� ��る。その他の構成要素は、同じである。

 図44は、電源投入直後に端末装置2’の制� ��部35’が表示装置41に表示するメニュー画面 の一例を示している。

 図44において、メニュー画面131’には、� �1:制御用データのダウンロード」、「2:コン� ��ンツのダウンロード」、「3:コンテンツの� �生」の3種類の選択メニューが表示されてい� ��。図13に示す実施例1のメニュー画面131に対� ��、「3:コンテンツのダウンロード」の選択� �ニューが追加されている。矢印132、決定ボ� �ン133は、図13に示すものと同じである。

 次に、メニュー画面131’から3種類の選択 メニューが選択された場合の端末装置2’お� �びサーバ装置1’の動作を、フローチャート� ��参照して説明する。

 図45は、利用者が図44に示すメニュー画面 131’から「1:制御用データのダウンロード」� ��メニュー項目を選択した場合の端末装置2’ およびサーバ装置1’における制御用データ� �ダウンロード処理を示すフローチャートで� �る。実施例1の図14に対応する。

 実施例5では、プレイリストを用いないの で、実施例1の図14と異なる点は、サーバ装置 1’の制御部13’は、読み出した制御用データ である分類構造データと遷移コマンドデータ とを送受信部12を介して端末装置2’に送信し (S130’)、端末装置2’の制御部35’では、送受 信部34を介してサーバ装置1’から制御用デー タである分類構造データと遷移コマンドデー タとを受信し、それを分類構造データ記憶部 31’に記憶する(S140’)。

 以上の制御用データのダウンロード処理� ��よれば、利用者が条件を選択する等の操作� ��不要なため、端末装置2’の操作を簡単にし たい場合に適している。

 次に制御用データのダウンロード処理の� ��の例を、図46のフローチャートを用いて説� �する。

 この処理では、サーバ装置1’の分類構造 データ格納部11’に説明データが格納されて� ��る必要があり、この処理を行わない場合は� ��説明データは省略可能である。

 この場合、まず、端末装置2’の制御部35� ��が送受信部34を介してサーバ装置1’に分類� ��造データリスト、すなわち分類構造データ� ��一覧を要求するメッセージを送信する(S200� �)。

 すると、サーバ装置1’側では、制御部13� ��が送受信部12を介して端末装置2’からの分� ��構造データリスト要求のメッセージを受信� ��(S210’)、その要求に基づいて分類構造デー� ��格納部11’からデータを読み出し分類構造� �ータリストを作成する(S220’)。具体的には� �分類構造データ格納部11’に格納されている 全ての分類構造データIDと、説明データとを� ��応づけて読み出し、これらを分類構造デー� ��リストとする。

 次に、制御部13’は、作成した分類構造� �ータリストを、送受信部12を介して端末装置 2’に送信する(S230’)。

 端末装置2’では、制御部35’が送受信部3 4を介してサーバ装置1’から分類構造データ� ��ストを受信し、表示装置41に分類構造デー� �リストを表示する(S240’)。

 図47は、表示装置41に表示される分類構造 データリストの一例を示す図である。実施例 1の図16が対応する。

 図47に示す分類構造データリスト161’で� �、分類構造データIDと、説明データとを対応 させて表示しているが、説明データのみ表示 するようにしても良い。矢印162と決定ボタン 163は、図16と同じである。

 図46に戻り、表示装置41に表示された分類 構造データリスト161’にて利用者が分類構造 データを選択すると、制御部35’は、入力装� ��40を介して利用者からの指示を受け付け、� �の指示に該当する分類構造データIDを、送受 信部34を介してサーバ装置1’に送信する(S250� ��)。

 サーバ装置1’では、制御部13’が送受信� ��12を介して端末装置2’から分類構造データI Dを受信し(S260’)、受信した分類構造データID に対応する分類構造データと遷移コマンドデ ータとを分類構造データ格納部11’から読み� ��し、制御用データとして送受信部12を介し� �端末装置2’に送信する(S270’)。

 端末装置2’では、制御部35’が送受信部3 4を介してサーバ装置1’から制御用データを� ��信し、それを分類構造データ記憶部31’に� �憶する(S280’)。

 以上の制御用データのダウンロード処理� ��よれば、利用者が複数の分類構造データの� ��から好きなものを選択することができるの� ��、利用者の満足度をより高めることができ� ��。

 なお、実施例5では、以上の図45または図4 6のどちらの制御用データダウンロード処理� �用いても良い。また上記の説明では、利用� �のメニュー選択により処理が開始される場� �を説明したが、これ以外に、所定の時間毎� �端末装置2’からサーバ装置1’に分類構造デ ータの要求メッセージを送信するようにして も良い。更に、制御用データをあらかじめ端 末装置2’に記憶しておいても良い。

 図48は、利用者が図44に示すメニュー画面 131’から「2:コンテンツのダウンロード」の� ��ニュー項目を選択した場合の端末装置2’お よびサーバ装置1’におけるコンテンツのダ� �ンロード処理を示すフローチャートである� �

 まず、端末装置2’では、制御部35’が、� ��えば、図49に示すような検索条件入力画面� �表示装置41に表示する(S400’)。利用者はこの 画面を見ながら入力装置40を操作することに� ��り、所望のコンテンツについての検索条件� ��入力する。図49の例では、検索条件をテキ� �トボックス181に入力するが、この他にも、� �ャンル、年代、雰囲気、再生に適した状況� �どを選択できるようにしても良い。また複� �の検索条件をAND条件やOR条件で組み合わせて 検索できるようにしても良い。なお、図49の� ��では、テキストボックス181に何も入力せず� ��送信ボタン182を押した場合は、何も条件を� ��定しないという意味に解釈され、サーバ装� ��1’に格納されている全てのコンテンツが対 象となる。

 送信ボタン182が押されると、制御部35’� �、テキストボックス181に入力された検索条� �を、送受信部34を介してサーバ装置1’に送� �する(S410’)。

 すると、サーバ装置1’では、制御部13’� ��送受信部12を介して検索条件を受信して(S420 ’)、コンテンツ格納部10’を参照しながら検 索条件に合致するコンテンツの配信ファイル を選択する(S430’)。具体的には、制御部13’� ��、検索条件にキーワードが指定されている� ��合は、配信ファイルのヘッダ61’に記録さ� �ている文字列と一致するか否かチェックす� �。検索条件が全く指定されていない場合は� �全てのコンテンツを選択対象とする。

 次に、制御部13’は、S430’で選択された� ��ンテンツのヘッダ61’を読み出すと共に、� �ッダ61’の情報にコンテンツを一意に識別で きるコンテンツIDを付与して、検索結果リス� ��を作成し、送受信部12を介して検索結果リ� �トを端末装置2’に送信する(S440’)。コンテ� ��ツIDとしては、例えばコンテンツの配信フ� �イルのパス名を用いることができる。検索� �果リストには、コンテンツのタイトル、制� �者などの情報が含まれている。なお配信フ� �イルのヘッダ61’を事前にデータベースに登 録しておき、S430’およびS440’において、配� ��ファイルのヘッダ61’を直接読み出す代わ� �に、データベースを読み出して処理を行う� �うにしても良い。

 端末装置2’では、制御部35’が送受信部3 4を介して検索結果リストを受信すると、表� �装置41に表示する(S450’)。

 図50は、制御部35’の表示装置41における� ��索結果リストの表示例を示す図である。

 この例では、検索結果リスト191として、� ��ンテンツのタイトル、制作者、ジャンルが� ��示されているが、これに限定されるもので� ��ない。またコンテンツIDは表示されていな� �が、表示されたコンテンツのタイトル等と� �コンテンツIDとは関連付けられている。利用 者は、ダウンロードしたいコンテンツのタイ トルの左側に表示されているチェックボック ス192をONにしてコンテンツを選択し、決定ボ� ��ン193を押すことによりコンテンツのダウン� ��ードを指示する。チェックボックス192を複� ��ONにすることにより、複数のコンテンツの� �ウンロードを指示することも可能である。

 このようにしてダウンロードすべきコン� ��ンツが選択されると、制御部35’は、利用� �により選択されたコンテンツのコンテンツID を送受信部34を介してサーバ装置1’に送信す る(S460’)。

 サーバ装置1’では、制御部13’が送受信� ��12を介してコンテンツIDを受信すると(S470’) 、コンテンツIDに対応するコンテンツの配信� ��ァイルをコンテンツ格納部10’から読み出� �、送受信部12を介して端末装置2’に送信す� �(S480’)。なお、複数のコンテンツIDを受信し た場合は、それらに対応する全ての配信ファ イルを送信する。

 端末装置2’では、制御部35’が送受信部3 4を介して配信ファイルを受信すると、受信� �た配信ファイルをコンテンツ記憶部30’に記 憶する(S490’)。以上がコンテンツのダウンロ ード処理である。

 図51は、メニュー画面131’から「コンテ� �ツの再生」のメニュー項目が選択された場� �のコンテンツ再生処理を示すフローチャー� �である。実施例1の図17に対応する。

 図51は、実施例1の図17が対応する。図17の S600、S610およびS670における“プレイリスト” を、図51のS600’、S610’およびS670’では、“� ��類カテゴリ”に変更しただけで、それ以外� ��、図17と同じであるので、説明は省略する� �

 図52は、図51のS670’の分類カテゴリ変更� �理を詳細に示すフローチャートである。

 図52は、実施例1の図19が対応する。図19の S810’およびS820における“プレイリストID”� �、図52のS810’およびS820’では、“分類カテ� ��リ”に変更しただけで、それ以外は、図19� �同じであるので、説明は省略する。

 次に、図52におけるS810’の処理の詳細に� ��いて、分類構造データの形式別に説明する� ��

 図53は、分類構造データが図38に示す「順 位」を用いた第1形式、または図39に示す「座 標値」を用いた第2形式である場合のS810’の� ��細な処理を示すフローチャートである。

 図53は、実施例1の図20が対応する。図20の S950における“プレイリスト”を、図53のS950� �では、“分類カテゴリ”に変更しただけで� �それ以外は、図20と同じであるので、S950’� �け説明する。

 つまり、S950’により、本実施例2の制御� �35’は、分類構造データ記憶部31’を参照し� ��がら、S930またはS940で算出した値に最も近� �「順位」または「座標値」を持つ分類カテ� �リを選定する。この時に、元々状態記憶部36 に記憶されている分類カテゴリを除外して選 定するようにし、分類カテゴリの変更が必ず 生じるようにする。

 以上が分類構造データに「順位」または� ��座標値」が用いられている場合のS810’の処 理の詳細である。

 次に、分類構造データが、図40に示す「� �似度」を用いた場合のS810’の処理の詳細に� ��いて、図54に示すフローチャートを用いて� �明する。

 図54は、実施例1の図21が対応する。図21の S1500および1520における“プレイリスト”を、 図54のS1500’および1520’では、“分類カテゴ� ��”に変更しただけで、それ以外は、図20と� �じであるので、説明を省略する。

 以上が実施例5の端末装置2‘におけるコ� �テンツ再生処理の説明である。上述したコ� �テンツ再生処理により、実施例2では、分類� ��テゴリの名称を表示装置41に表示して利用� �に選択させる方法に比べて、より直感的な� �作が可能になる。

 このように、実施例5によれば、サーバ装 置1’は、コンテンツをカテゴリにより分類� �た場合の複数の分類カテゴリ間の関係を数� �で表した分類構造データを、ネットワーク3� ��介し端末装置2’に対し送信し、端末装置2� �ではその分類構造データを受信して、コン� �ンツ再生の際、分類構造データに基づいて� �ンテンツの分類カテゴリを変更して、変更� �た分類カテゴリのコンテンツを再生するよ� �にしたので、プレイリストを利用した実施� �1と同様に、大量のコンテンツを格納してい� ��も、その時々の利用者の気分に合ったコン� ��ンツを簡単な操作で再生できる。

 また、実施例5では、分類構造データ毎に 、対応する複数の分類カテゴリ間の変更する 方向と変化量とを示す遷移コマンドと、その 遷移コマンドの変化量に応じた表示メッセー ジとが付加されているので、端末装置2’で� �、その表示メッセージを表示して利用者に� �択させることにより、再生コンテンツを分� �カテゴリを基準にして、それとの相対的な� �化を指定する方法で、別の分類カテゴリに� �り替えてコンテンツ再生することができる� �

 そのため、実施例5によれば、事前に印象 の遷移を指定したプレイリストを作成する手 間が不要であり、様々な分類カテゴリを直感 的な操作で切り替えながらコンテンツを再生 できる。その結果、実施例1と同様に、コン� �ンツ購入前にサーバ装置1’の提供する大量� ��コンテンツを試聴させる用途などにも好適� ��ある。

 また、実施例5では、サーバ装置1’から� �末装置2’に分類構造データを送信し、端末� ��置2’の分類構造データを更新することが可 能なので、新しい分類カテゴリを追加し易い という効果もある。

 更に、実施例5によれば、端末装置2’の� �用者は、複数の分類構造データの中から好� �のものをサーバ装置1’に対し要求し送信さ� ��て使用することができるので、分類カテゴ� ��の変化の仕方を自分の好みに合わせて設定� ��ることができる。そのため、利用者の好み� ��応じて分類構造データを変更することによ� ��、利用者が既に使用しているコンテンツに� ��いても、分類カテゴリの変化の仕方が新し� ��ものになるので、利用者が飽きにくく、利� ��者のコンテンツや配信サービスに対する興� ��や関心を維持し易い。また、利用者は、既� ��知っている馴染みのコンテンツを再生する� ��合でも、分類構造データにより、再生コン� ��ンツの分類カテゴリを変更しながらコンテ� ��ツを再生するので、コンテンツ同士の意外� ��類似性を発見する等のチャンスが増え、多� ��的にコンテンツを楽しむことができる。

[実施例6]
 次に、本発明の実施例6を説明する。実施例 6のシステム全体の構成は、実施例1の図1と同 様であるが、実施例6では、サーバ装置1a’が ネットワーク3を介して端末装置2’と接続さ� ��ている。実施例6における端末装置2’の構� �および処理動作は、実施例5と同じであるの� ��、サーバ装置1a’についてのみ説明する。

 図55は、実施例6のサーバ装置1a’の構成� �を示している。

 実施例6のサーバ装置1a’では、実施例5の サーバ装置1’の構成と比べて、音響分析部14 が追加されている他、コンテンツ格納部10a’ と制御部13a’の機能が若干異なる。他の構成 要素は実施例5と同じである。つまり、図22に 示す実施例2のサーバ装置1aのプレイリスト構 造データ格納部11を、分類構造データ格納部1 1’に置き換えたもので、音響分析部14は図22� ��示す実施例2のものと同じである。

 図56は、実施例6における配信ファイルの� ��納形式の一例を示している。

 図56に示す実施例6の配信ファイルが、図2 3に示す実施例2の配信ファイルと異なるのは� ��ヘッダ61a’に分類カテゴリが付与されてい� ��点である。また、図36に示す実施例5の配信� ��ァイルと異なるのは、ヘッダ61a’に音響分� ��フラグが追加されている点である。実施例5 でも説明したように、実施例6でも、1つのコ� ��テンツに複数の分類カテゴリを記録するこ� ��が可能である。従って、音響分析により得� ��れた分類カテゴリに加えて他の分類カテゴ� ��を記録しておくことも可能である。コンテ� ��ツが作成された段階では、音響分析フラグ� ��「0」にセットされている。S1040において分� ��カテゴリを記録すると同時に、音響分析フ� ��グを「1」に変更する。以上が音響分析処理 の説明である。

 このため、実施例5のサーバ装置1’では� �コンテンツ制作者またはサーバ装置1’の運� ��者や管理者が分類カテゴリをコンテンツに� ��与しておく必要があったが、実施例6のサー バ装置1a’によれば、端末装置側では、実施� ��2と同様に配信ファイルのヘッダ61a’に音響 分析フラグが付与されているので、人手を介 することなく、自動的にコンテンツに分類カ テゴリを付与できる。

 従って、実施例6によれば、実施例5の効� �に加え、さらに、コンテンツ配信に関わる� �数やコストを大幅に削減することができる� �また、実施例6においては、人手により付与� ��れた分類カテゴリと、音響分析による分類� ��テゴリを併用することにより、より多様で� ��面的なコンテンツの分類が可能になる。

[実施例7]
 次に、本発明の実施例7を説明する。

 実施例7は、図26に示す実施例3が相当する 。ただし、図26における端末装置2aは、分類� �造データを利用する実施例7の端末装置2a’� �置き換え、図26における再生装置4も、本分� �構造データを利用する実施例7の再生装置4’ に置き換える。

 なお、実施例7におけるサーバ装置は、図 35に示す実施例5のサーバ装置1’と、図55に示 す実施例6のサーバ装置1a’のどちらでも用い ることができるが、説明の簡略化のため、以 下ではサーバ装置1’と記述する。また、サ� �バ装置の動作は、実施例5または実施例6と同 じであるので、説明を省略する。

 図57は、実施例7の端末装置2a’の構成例� �示すブロック図である。

 図57において、端末装置2a’は、コンテン ツ記憶部30’と、分類構造データ記憶部31’� �、送受信部34と、制御部35a’と、インタフェ ース制御部38とを有している。また、端末装� ��2a’には、入力装置40と、表示装置41が接続� ��れている。

 実施例7では、ネットワーク3を介してサ� �バ装置1’に接続されている端末装置2a’に� �再生装置4’が実施例3と同様のインタフェー ス5を介して接続されている。端末装置2a’と 再生装置4’との接続は、随時切り離すこと� �可能になっている。

 図58は、実施例7の再生装置4’の構成例を 示すブロック図である。

 図58において、再生装置4’は、コンテン� ��記憶部30b’と、分類構造データ記憶部31b’� ��、コンテンツ選出部32bと、再生部33bと、制� ��部35b’と、状態記憶部36bと、インタフェー� ��制御部38bとを有しており、入力装置40bと、� ��示装置41bと、音声出力装置42bが接続されて� ��る。なお、再生装置4’と、入力装置40bおよ び表示装置41bおよび音声出力装置42bとを1つ� �装置として構成し、携帯型の再生装置とし� �も良い。

 実施例7でも、実施例3と同様に、電源投� �直後は、端末装置2a’の表示装置41に、図29� �示すようなメニュー画面が表示される。こ� �で、利用者が「1:制御用データのダウンロー ド」と、「2:コンテンツのダウンロード」の� ��ニュー項目を選択した場合の端末装置2a’� �よびサーバ装置1’の動作は、実施例5と同様 である。

 図59は、図29に示すメニュー画面において 利用者が「3:再生装置へ転送」のメニュー項� ��を選択した場合の実施例7の端末装置2a’お� ��び再生装置4’の動作を示すフローチャート である。

 図59は、実施例3の図31が対応する。図31の S1120およびS1130における“プレイリスト”に� �づく実施例3の処理を、実施例7の図59のS1120� �およびS1130’では、“分類カテゴリ”に基づ き処理しており、それ以外は、図31と同じで� ��る。

 つまり、実施例7の端末装置2a’のインタ� ��ェース制御部38は、まず、再生装置4’とデ� ��タを受信できる状態にあるか否かチェック� ��(S1100)、データ受信可能あれば(S1100“YES”)� �分類構造データ記憶部31’から分類構造デー タを読み出してインタフェース5を介して再� �装置4’に送信する(S1120’)。

 すると、実施例7の再生装置4’では、イ� �タフェース制御部38bが端末装置2a’からの分 類構造データを受信し、分類構造データ記憶 部31b’に記憶する(S1130’)。なお、これ以降� �処理は、図31に示す実施例3と同様であるの� �省略する。

 以上が実施例7の端末装置2a’から再生装� ��4’への分類構造データとコンテンツの転送 処理である。なお、実施例3と同様、転送処� �が完了すると、利用者は適宜、再生装置4’� ��インタフェース5から切り離して再生動作を 開始することができる。

 実施例7の再生装置4’の再生動作は、図51 に示す実施例5における端末装置2’の再生動� ��と同様である。すなわち、再生装置4’のコ ンテンツ記憶部40bと端末装置2’のコンテン� �記憶部40、再生装置4’の分類構造データ記� �部31b’と端末装置2’の分類構造データ記憶� ��31’、再生装置4’のコンテンツ選出部32bと� ��末装置2’のコンテンツ選出部32、再生装置4 ’の再生部33bと端末装置2’の再生部33、再生 装置4’の制御部35b’と端末装置2’の制御部3 5’、再生装置4’の状態記憶部36bと端末装置2 ’の状態記憶部36は、各々同じ動作を行う。

 従って、実施例7によれば、サーバ装置1� �と直接接続できない再生装置4’においても� ��通信機能を有する端末装置2a’を介してサ� �バ装置1’と接続して分類構造データやコン� ��ンツをダウンロードすることにより、複数� ��分類カテゴリを簡単に切り替えながらコン� ��ンツの再生ができるので、利用者のその時� ��の気分に合ったコンテンツを再生できる。

[実施例8]
 次に、本発明の実施例8を説明する。実施例 8においては、実施例4と同様に、コンテンツ� ��端末装置に記憶させずに、サーバ装置から� ��末装置にストリーミング送信するようにし� ��ものである。

 図60は、実施例8のサーバ装置1c’の構成� �を示すブロック図である。

 実施例8のサーバ装置1c’は、コンテンツ� ��納部10’と、分類構造データ格納部11’と、 送受信部12と、制御部13c’と、コンテンツ選� ��部32cと、状態記憶部36cとを有しており、入� ��装置20と、表示装置21が接続されている。こ こで、コンテンツ格納部10’、分類構造デー� ��格納部11’および送受信部12は、実施例5の� �のと同じ動作である。また、コンテンツ選� �部32cおよび状態記憶部36cは、各々実施例5に� ��ける端末装置2’のコンテンツ選出部32およ� ��状態記憶部36と同様な動作を行う。また、� �施例5では省略するが、実施例6と同様にサー バ装置1c’が音響分析部14を持つようにして� �良い。

 なお、実施例8の端末装置は、図33に示す� ��施例4の端末装置2c’と同じであるので、図3 3の構成を参照して説明する。ただし、実施� �5とは異なり、分類構造データは送信する必� ��がなく、遷移コマンドデータのみを制御用� ��ータとしてサーバ装置1c’から端末装置2c’ に送信すれば良い。また、利用者からコンテ ンツ再生処理の開始を指示された後、コンテ ンツ再生処理に先立って、サーバ装置1c’か� ��端末装置2c’に遷移コマンドデータを送信� �るようにしても良い。また、遷移コマンド� �ータ記憶部39には、遷移コマンドデータに対 応する分類構造データIDが記憶されている。

 次に動作を説明する。

 図61は、実施例8のサーバ装置1c’および� �末装置2c’におけるコンテンツ再生処理を示 すフローチャートである。

 図61は、実施例4の図34が対応する。図34の S1220、S1230およびS1320における“プレイリスト ”に基づく実施例4の処理を、実施例8の図61� �S1220’、S1230’およびS1320’では、“分類カ� �ゴリ”に基づき処理しており、それ以外は� �図34と同じである。

 つまり、端末装置2c’の制御部35c’は、� �移コマンドデータ記憶部39から分類構造デー タIDを読み出し、これを再生開始メッセージ� ��含めて、送受信部34を介してサーバ装置1c’ に送信すると(S1200)、サーバ装置1c’では、制 御部13c’が送受信部12を介して再生開始メッ� ��ージを受信して(ステップS1210’)、再生開始 メッセージに含まれる分類構造データIDを状� ��記憶部36cに記憶する。

 次に、制御部13c’は、分類構造データ格� ��部11’を参照し、そこに格納されている分� �カテゴリの中から再生に使用する分類カテ� �リを1つ初期値として選択して、状態記憶部3 6cに記憶する(S1220’)。分類構造データが複数 の階層で構成されている場合は、最下位の階 層の分類カテゴリを選択する。

 次に、コンテンツ選出部32cが、状態記憶� ��36cに記憶されている分類カテゴリに該当す� ��コンテンツをコンテンツ格納部10’から1つ� ��出する(S1230’)。具体的には、コンテンツ格 納部10’に記憶されている各配信ファイルを� ��象にして、ヘッダ61’内の分類カテゴリを� �み出し、状態記憶部36cに記憶されている分� �カテゴリに合致するコンテンツの集合を作� �した後、この集合から1つのコンテンツを選� ��する。この時、コンテンツ再生動作が開始� ��れてから再生されていないコンテンツを優� ��的に選出するようにしても良いし、またコ� ��テンツ格納部10’にコンテンツ毎の再生回� �を記憶させておき、再生回数が多いコンテ� �ツを優先的に選出しても良い。また逆に再� �回数の少ないコンテンツを優先的に選出し� �も良い。またコンテンツの制作年代などの� �ッダ情報を用いて選出するようにしても良� �。そして選出したコンテンツのファイルの� �ス名を状態記憶部36cに記憶する。

 そして、次のS1240からS1310までの処理は、 図34に示す実施例4の処理と同様である。ただ し、S1260では、制御部35c’は、受信した配信� ��ァイルのヘッダ61’に含まれるコンテンツ� �情報を表示装置41に表示すると共に、遷移コ マンドデータ記憶部39から分類カテゴリを変� ��するための遷移コマンドを読み出して表示� ��置41に表示する。

 そして、制御部35c’は、再生中止メッセ� ��ジでないと判断した場合は(S1310“NO”)、遷� ��メッセージの場合であるので、制御部13c’� ��、遷移メッセージに含まれる「階層」、「� ��向」、「変化量」の情報に基づいて分類カ� ��ゴリを変更し(S1320’)、新たな分類カテゴリ を状態記憶部36cに記憶し、S1230’の処理に戻� ��、以上の処理を繰り返す。なお、S1300にて� �生終了メッセージであると判断した場合も(S 1300“YES”)、S1230’の処理に戻る。

 ここで、S1210でサーバ装置1c’の状態記憶 部36cに記憶された分類構造データIDに対応す� ��分類構造データが、図5に示した「順位」を 用いた形式または図6に示した「座標値」を� �いた形式である場合、S1320における遷移メッ セージに応じた分類カテゴリの変更処理は、 図56に示す実施例5の処理とほぼ同じで、図56� ��示すS900~S950の処理を行った後、選定した分� ��カテゴリを状態記憶部36cに記憶する。ただ� ��実施例5とは異なり、端末装置2’(2c’)では� ��く、サーバ装置1c’の各部により処理が行� �れる。

 分類構造データが、図40に示す「類似度� �を用いた形式である場合のS1320の詳細も、図 57に示す実施例5の処理とほぼ同じであり、図 57に示すS1500~S1520の処理を行った後、選定し� �分類カテゴリを状態記憶部36cに記憶する。� �の場合も実施例5とは異なり、端末装置2’(2c ’)ではなく、サーバ装置1c’の各部により処 理が行われる。

 その他の処理は、実施例3~5と同様である� ��

 従って、実施例8によれば、サーバ装置1c� ��がストリームでコンテンツを配信する場合� ��端末装置2c’ではコンテンツを格納したり� �分類カテゴリに対応したコンテンツを選出� �る必要がないので、安価なコストで端末装� �2c’を実現することができる。また、サーバ 装置1c’に格納されたコンテンツを対象にし� ��、様々な分類カテゴリを直感的な操作で切� ��替えながらコンテンツを再生できるので、� ��ンテンツ購入前にサーバ装置の提供する大� ��のコンテンツを試聴させる用途などにも適� ��ている。

 なお、実施例8では、端末装置2c’に分類� ��造データ記憶31を設けず、サーバ装置1c’か らは端末装置2c’に分類構造データを送信し� ��いないが、本発明ではこれに限定するもの� ��はない。例えば、実施例5と同様に、履歴コ マンドデータ記憶部39に代えて分類構造デー� ��記憶部31’を端末装置2c’に設け、サーバ装 置1c’から端末装置2c’に分類構造データを� �信した上で、実施例5と同様にS1220およびS1320 に相当する処理を端末装置2c’で行うと共に� ��S1230のコンテンツ選出処理をサーバ装置1c’ で行うようにしても良い。すなわち、端末装 置2c’において分類構造データに基づき選出� ��た分類カテゴリを、端末装置2c’からサー� �装置1c’に送信し、サーバ装置1c’において� ��の分類カテゴリに対応するコンテンツを選� ��し、それを端末装置2c’に送信するように� �ても良い。

 また、実施例5~8では、サーバ装置が分類� ��造データだけでなく、コンテンツも配信フ� ��イルとして配信するように説明したが、本� ��明では、これに限らず、コンテンツはCDやDV D、BD等の光ディスク等のメディアによって端 末装置に提供するようにしても、さらに、放 送装置によって放送によって提供したり、さ らには、ネットワークを介し配信する場合で も、コンテンツを配信するサーバ装置と、分 類構造データを配信するサーバ装置が別々の サーバ装置であっても勿論よい。

 以上で説明したように、実施例5~8によれ� ��、サーバ装置の提供する大量のコンテンツ� ��対象として、コンテンツの分類カテゴリを� ��用することにより、その時々の利用者の気� ��に合ったコンテンツを簡単な操作で再生で� ��る。利用者は、再生中のコンテンツの分類� ��テゴリを基準にして、それとの相対的な変� ��を指定する方法で、別の分類カテゴリに切� ��替えてコンテンツ再生することができるの� ��、直感的に操作できる。

 また、実施例5~8では、事前にプレイリス� ��を作成する手間が不要であり、様々な分類� ��テゴリを直感的な操作で切り替えながらコ� ��テンツを再生できるので、コンテンツ購入� ��にサーバ装置が提供する大量のコンテンツ� ��試聴させる用途などにも好適である。

 また、サーバ装置から端末装置等に分類� ��造データを送信し、端末装置等における分� ��構造データを更新することが可能なので、� ��しい分類カテゴリを追加し易い。

 更に、利用者は複数の分類構造データの中� ��ら好みのものを選択して使用することがで� ��るので、分類カテゴリの変化の仕方を自分� ��好みに合わせて設定できる。分類構造デー� ��を変更することにより、利用者が既に使用� ��ているコンテンツについても、分類カテゴ� ��の変化の仕方が新しいものになるので、利� ��者が飽きにくく、利用者のコンテンツや配� ��サービスに対する興味や関心を維持し易い� ��