JP4013942B2 - ネットワーク型コンテンツ再生システム - Google Patents

ネットワーク型コンテンツ再生システム Download PDF

Info

Publication number
JP4013942B2
JP4013942B2 JP2004328958A JP2004328958A JP4013942B2 JP 4013942 B2 JP4013942 B2 JP 4013942B2 JP 2004328958 A JP2004328958 A JP 2004328958A JP 2004328958 A JP2004328958 A JP 2004328958A JP 4013942 B2 JP4013942 B2 JP 4013942B2
Authority
JP
Japan
Prior art keywords
client
firmware
content server
audio client
controller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004328958A
Other languages
English (en)
Other versions
JP2005182763A5 (ja
JP2005182763A6 (ja
JP2005182763A (ja
Inventor
泰 池田
進 竹村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Onkyo Corp
Original Assignee
Onkyo Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Onkyo Corp filed Critical Onkyo Corp
Priority to JP2004328958A priority Critical patent/JP4013942B2/ja
Publication of JP2005182763A publication Critical patent/JP2005182763A/ja
Publication of JP2005182763A5 publication Critical patent/JP2005182763A5/ja
Publication of JP2005182763A6 publication Critical patent/JP2005182763A6/ja
Application granted granted Critical
Publication of JP4013942B2 publication Critical patent/JP4013942B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)
  • Reverberation, Karaoke And Other Acoustics (AREA)

Description

本発明は、ネットワーク型コンテンツ再生システムに関し、さらに詳しくは、サーバとサーバに接続されたクライアントとサーバに接続されたコントローラとを備えたネットワーク型コンテンツ再生システムに関する。
従来の典型的なオーディオシステムは、媒体から音楽データを読み出し、その音楽データに基づいて音楽を再生するものである。このようなオーディオシステムは基本的に各部屋に１つずつ設置しなければならないため、全体として高価になる。これに対し、１箇所に全ての音楽データを蓄積しておき、各部屋で選択された音楽を再生することの可能な集中型オーディオシステムも提供されている。
しかし、上記集中型オーディオシステムでは、音楽信号用の配線や制御信号用の配線等、多数の配線を各部屋に敷かなければならない。また、１つの曲を各部屋で同時に再生することは可能であるが、ある曲をある部屋で再生している最中に、同じ曲を別の部屋で最初から再生することはできない。
また、汎用のパソコンに音楽再生用のアプリケーションプログラムをインストールすれば、インターネット上のサイトから音楽データを取得し、音楽を再生することは可能であるが、受信済みのデータについてしか、音楽ＣＤのように、曲を途中から再生したり、早送りしたり、早戻ししたりすることはできない。すなわち、未だ受信していなデータについては、特殊再生をすることができない。
本発明の目的は、クライアントに適したファームウェアを選択して更新することの可能なネットワーク型コンテンツ再生システムを提供することである。
課題を解決するための手段及び発明の効果
本発明によるネットワーク型コンテンツ再生システムは、サーバと、サーバに接続された少なくとも１つのクライアントとを備える。サーバは、複数のコンテンツを蓄積する蓄積手段と、複数のコンテンツの中から選択されたコンテンツをクライアントに送信するコンテンツ送信手段と、複数のファームウェアの情報を記憶するファームウェア情報記憶手段とを含む。ファームウェアの情報の各々は、当該ファームウェアが適用可能なクライアントのタイプを示すプロダクトＩＤを含む。クライアントは、サーバから送信されたコンテンツを再生する再生手段と、自身のプロダクトＩＤと、サーバから取得しようとする最初のファームウェアの情報を示す取得開始インデックスと、サーバから取得しようとするファームウェアの情報の数を示す取得個数とを含むファームウェアリスト要求コマンドを送信することにより、複数のファームウェアの情報を列挙したファームウェアリストの送信をサーバに要求するファームウェアリスト要求手段を含む。サーバはさらに、クライアントからのファームウェアリスト要求コマンドに応答して、ファームウェアリスト要求コマンドに含まれるプロダクトＩＤと同じプロダクトＩＤを含むファームウェアの情報をファームウェア情報記憶手段から読み出し、ファームウェアリスト要求コマンドに含まれる取得開始インデックスが示す最初のファームウェアの情報からファームウェアリスト要求コマンドに含まれる取得個数分のファームウェアの情報を含むファームウェアリストを作成し、クライアントに送信するファームウェアリスト送信手段とを含む。クライアントはさらに、サーバから送信されたファームウェアリストを受信する手段と、受信されたファームウェアリストの中から選択されたファームウェアの送信をサーバに要求するファームウェア要求手段とを含む。サーバはさらに、クライアントからの要求に応じて選択されたファームウェアをクライアントに返信してクライアントのファームウェアを更新するファームウェア更新手段を含む。
本発明によれば、クライアントから送信されて来たファームウェアリスト要求コマンドに含まれるプロダクトＩＤと同じプロダクトＩＤを含むファームウェアの情報をファームウェア記憶手段から読み出しているので、クライアントに適したファームウェアの情報のみを列挙したファームウェアリストを作成し、クライアントに送信する。その結果、クライアントに適したファームウェアを選択して更新することができる。
以下、本発明の実施の形態を図面を参照して詳しく説明する。図中同一又は相当部分には同一符号を付してその説明を援用する。
［目次］
１．好ましい実施の形態
１．１．構成
１．１．１．全体
１．１．２．コンテンツサーバ
１．１．３．オーディオクライアント
１．１．４．コントローラ
１．１．５．ＡＶレシーバ
１．２．動作
１．２．１．コンテンツサーバ及びオーディオクライアントの初期設定
１．２．１．１．オーディオクライアントの初期設定
１．２．１．１．１．コンテンツサーバ探索
１．２．１．１．２．コンテンツサーバとの接続
１．２．１．１．３．クライアント情報の送信
１．２．１．２．コンテンツサーバの初期設定
１．２．１．２．１．コンテンツサーバ探索に対する応答
１．２．１．２．２．コマンドポート接続受付
１．２．１．２．３．プッシュポート接続受付（その１）
１．２．１．２．４．プッシュポート接続受付（その２）
１．２．２．コンテンツサーバ及びオーディオクライアントのメイン動作
１．２．２．１．コマンド受付
１．２．２．１．１．コマンド振分処理
１．２．２．１．２．ステータス通知コマンド処理
１．２．２．１．３．サーバリクエスト発行コマンド処理
１．２．２．２．通常再生
１．２．２．２．１．曲リスト取得
１．２．２．２．２．曲の指定
１．２．２．２．３．曲の再生
１．２．２．３．特殊再生
１．２．２．３．１．早送り再生
１．２．２．３．２．早戻し再生
１．２．２．３．３．一時停止
１．２．２．３．４．スロー再生
１．２．３．コントローラの動作
１．２．３．１．コンテンツサーバとの接続
１．２．３．１．１．監視ハンドル及び制御ハンドルの取得
１．２．３．２．モニタ（監視）機能
１．２．３．３．制御機能
１．２．３．３．１．制御コマンド処理
１．２．３．３．２．再生制御
１．２．３．３．３．再生可能なフォーマットかを識別して再生
１．２．３．３．４．連続再生制御
１．２．３．３．５．リスト構築キーを用いた連続再生制御
１．２．３．３．６．優先順位を付けた連続再生制御
１．２．３．３．７．制御ハンドルを利用した連続再生制御
１．２．３．３．８．コンテンツサーバによる連続再生制御
１．２．３．３．９．オーディオクライアント自身による連続再生制御
１．２．３．３．１０．再生命令管理テーブルを利用した連続再生制御
１．２．４．ＡＶレシーバの制御
１．２．５．ファームウェアアップデート
２．他の実施の形態
２．１．コンセント内蔵型オーディオクライアント
２．２．インターネット上の音楽データを取得
２．３．取得データ長変更機能付き再生
２．４．スキップ再生
２．５．リピート再生
２．６．途中再生
２．７．自動接続回復機能付きクライアント
１．好ましい実施の形態
１．１．構成
１．１．１．全体
図１を参照して、本発明の実施の形態によるネットワーク型オーディオシステム１０は、多数の曲の音楽データを蓄積するための複数のコンテンツサーバＳ１〜Ｓｉと、コンテンツサーバＳ１〜Ｓｉからの音楽データに基づいて音楽を再生するための複数のオーディオクライアントＣ１〜Ｃｊと、オーディオクライアントＣ１〜Ｃｊを制御しかつモニタするための複数のコントローラＡ１〜Ａｋと、ＡＶ機器（例えば、スイッチャやアンプなどを含むＡＶレシーバ）ＡＶＲと、ＡＶレシーバＡＶＲを制御するためのＡＶＲクライアントＡＣとを備える。以下、コンテンツサーバのうち１つを挙げる場合はコンテンツサーバＳｉ、オーディオクライアントのうち１つを挙げる場合はオーディオクライアントＣｊ、コントローラのうち１つを挙げる場合はコントローラＡｋを用いる。
ここではコンテンツサーバＳｉには音楽データを蓄積しているが、これに代えて又はこれと共に映像データを蓄積していてもよく、その他、さまざまなデジタルコンテンツ(例えば、写真などの静止画等)を蓄積していてもよい。以下では、音楽データを例に説明する。また、コンテンツサーバＳｉ、オーディオクライアントＣｊ、コントローラＡｋは、それぞれ複数存在するが、コンテンツサーバやオーディオクライアントは少なくとも１つ存在すればよい。複数のコンテンツサーバＳ１〜Ｓｉが存在する場合、オーディオクライアントＣｊはいずれのコンテンツサーバＳ１〜Ｓｉから音楽データを取得してもよく、また、特定の１つのコンテンツサーバＳｉのみから音楽データを取得してもよい。また、コントローラＡｋは全くなくてもよい。また、ＡＶレシーバＡＶＲやＡＶＲクライアントＡＣは複数存在してもよいが、全くなくてもよい。
これらは、ＬＡＮ（ローカルエリアネットワーク）１２により相互に接続されるが、これに限定されることなく、ＵＳＢ、ＩＥＥＥ１３９４など、コンピュータネットワークを構築するのに適切なものを採用すればよい。ＬＡＮを採用する場合、ＰＣ（パーソナルコンピュータ）で標準的なＴＣＰ／ＩＰプロトコルを採用するのが好ましいが、ＵＤＰプロトコルなどを採用してもよく、プロトコルは特に限定されない。また、この図ではＬＡＮの基幹配線から枝分かれするようにコンテンツサーバやオーディオクライアントが接続されているが、たとえば１０ＢＡＳＥ−Ｔや１００ＢＡＳＥ−ＴＸの場合にはハブを中心にしてスター状に接続される。
１．１．２．コンテンツサーバ
図２を参照して、各コンテンツサーバＳｉは、圧縮デジタル音楽データを蓄積するためのＨＤＤ（ハードディスクドライブ）１４と、データベース管理部１６及びネットワークプロトコル処理部１８を含むＣＰＵ処理部２０と、本コンテンツサーバＳｉとＬＡＮ１２との間で信号を送受信するＬＡＮコントローラ２２とを備える。
１．１．３．オーディオクライアント
図３を参照して、各オーディオクライアントＣｊは、ネットワークプロトコル処理部２４及びシステム動作部２６を含むマイコン処理部２８と、フラッシュメモリ３０と、順次入力された圧縮デジタル音楽データ等を一時的に記憶して順次出力するメモリ３２と、圧縮デジタル音楽データをデコードして非圧縮デジタル音楽データを生成する音声処理部３４と、デジタル音楽データをアナログ音楽データに変換するＤ／Ａ変換器（ＤＡＣ）３６と、本オーディオクライアントＣｊとＬＡＮ１２との間で信号を送受信するＬＡＮコントローラ３８とを備える。オーディオクライアントＣｊは、コンテンツサーバＳｉと異なり、圧縮デジタル音楽データを蓄積するためのＨＤＤを備えていなくてもよい。
１．１．４．コントローラ
図４を参照して、各コントローラＡｋは、キーボード、マウス、タブレット、タッチパネル等の入力装置３０１と、液晶ディスプレイ、ＣＲＴ(Cathode Ray Tube)等の表示装置３０２と、インストールされたコンピュータプログラムに従って所定の処理を実行するＣＰＵ３０３と、本コントローラＡｋとＬＡＮ１２との間で信号を送受信するＬＡＮコントローラ３０４とを備える。コントローラＡ１〜ＡｋはオーディオクライアントＣ１〜Ｃｊと同様にコンテンツサーバＳ１〜Ｓｉに対してクライアントとして機能する。コントローラＡｋがオーディオクライアントＣｊと異なる点は、オーディオクライアントＣｊは再生機能を有するのに対し、コントローラＡｋは再生機能を有さず、主としてオーディオクライアントのモニタ及び制御機能を有する点である。
上記オーディオクライアントＣｊは主として再生機能を有するが、モニタ及び制御機能を有していてもよい。この場合、オーディオクライアントはコントローラとしても機能する。
１．１．５．ＡＶレシーバ
ＡＶレシーバＡＶＲは、特に限定されないが、たとえばＥＩＡ−２３２によりＡＶＲクライアントＡＣに接続される。ＡＶＲクライアントＡＣは、主としてＡＶレシーバＡＶＲと通信できる機能を有するが、オーディオクライアントＣｊと同様に再生機能を併せて有していてもよい。
１．２．動作
１．２．１．コンテンツサーバ及びオーディオクライアントの初期設定動作
図５を参照して、あるオーディオクライアントに電源が投入されると、そのオーディオクライアントはまずコンテンツサーバを探索する（Ｓ１１）。ＬＡＮ１２に接続されている複数のコンテンツサーバＳｉのうち稼働中のコンテンツサーバは、これに応答する（Ｓ２１）。
続いて、オーディオクライアントは、コンテンツサーバとデータの送受信を可能にするために、コンテンツサーバに対して接続要求を発行する（Ｓ１２）。コンテンツサーバは、この接続要求に応じてオーディオクライアントとの接続を確立する（Ｓ２２）。
最後に、オーディオクライアントは自身に関するさまざまなクライアント情報をコンテンツサーバに送信し（Ｓ１３）、コンテンツサーバはこれを受信する（Ｓ２３）。
上記初期設定動作が終了すると次の曲リスト取得動作に移るが、その説明の前に、オーディオクライアントの初期設定動作の詳細を説明する。
１．２．１．１．オーディオクライアントの初期設定動作
１．２．１．１．１．コンテンツサーバ探索
図６を参照して、オーディオクライアントは、まず、発見したコンテンツサーバのＩＰアドレス及びポート番号を記録するためのサーバリストをクリアする（Ｓ１１０１）。
続いて、オーディオクライアントは、特に限定されないが、たとえばＵＤＰプロトコルにより、コマンドポートで予め定められたマジックワードをＬＡＮ１２上にブロードキャストする（Ｓ１１０２）。ＬＡＮ１２に接続されている複数のコンテンツサーバＳｉの中に稼働中のコンテンツサーバが存在すれば、そのコンテンツサーバはブロードキャストされたマジックワードをサーチポートで受信し、そのマジックワードをブロードキャストしたオーディオクライアントに同じマジックワードを返信し、併せて自身を特定するためのサーバ特定情報（具体的にはＩＰアドレス及びポート番号）を送信する。
続いて、オーディオクライアントは、サーバ特定情報の受信経過時間を計測するためのタイマをリセットし（Ｓ１１０３）、その後、サーバ特定情報を受信したか否かを判別する（Ｓ１１０４）。
サーバ特定情報を受信した場合（コンテンツサーバを発見した場合）、オーディオクライアントは、そのサーバ特定情報をサーバリストに記録する（Ｓ１１０５）。そして、オーディオクライアントは、サーバリストが満杯になったか否かを判別し（Ｓ１１０６）、満杯になった場合は探索を完了し、未だ満杯になっていない場合はステップＳ１１０３に戻る。
一方、サーバ特定情報を受信しない場合（コンテンツサーバを発見しない場合）、オーディオクライアントは、サーバ特定情報の受信経過時間が所定時間、たとえば２秒を超えたか否かを判別し（Ｓ１１０７）、未だ超えていない場合はステップＳ１１０４に戻る。すなわち、オーディオクライアントは２秒間だけコンテンツサーバからの応答を待つ。
サーバ特定情報の受信経過時間が２秒を超えた場合、オーディオクライアントは、サーバリストが未だ空か否かを判別する（Ｓ１１０８）。サーバリストが空の場合、つまりサーバリストにサーバ特定情報が全く記録されていない場合、オーディオクライアントはステップＳ１１０２に戻ってマジックワードを再びブロードキャストする。一方、サーバリストが空でない場合、つまりサーバリストに少なくとも１つのコンテンツサーバのサーバ特定情報が記録されている場合、オーディオクライアントは探索を完了する。すなわち、オーディオクライアントは少なくとも１つのコンテンツサーバを発見するまで探索を続ける。
上記コンテンツサーバ探索の結果、サーバリストには１又は２以上のコンテンツサーバに対応するＩＰアドレス及びポート番号が付与される。
１．２．１．１．２．コンテンツサーバとの接続
図７を参照して、オーディオクライアントは、ユーザの操作に応じてサーバリストの中から１つのコンテンツサーバを選択し（Ｓ１２０１）、その選択したコンテンツサーバのＩＰアドレス及びポート番号を取得する（Ｓ１２０２）。
続いて、オーディオクライアントは、取得したＩＰアドレス及びコマンドポートでＴＣＰ(Transmission Control Protocol)ソケット（１）を生成し（Ｓ１２０３）、このＴＣＰソケット（１）でコンテンツサーバと接続する（Ｓ１２０４）。コマンドポートは、コンテンツサーバとオーディオクライアントとの間でコマンドを送受信するためのポートである。コンテンツサーバがコマンドポートでの接続を受け付け（Ｓ２２０１）、接続が成功した場合はステップＳ１２０６に進むが、そうでない場合は接続は失敗となる（Ｓ１２０５）。これによりオーディオクライアントは、コンテンツサーバとの間でコマンドを送受信するための接続を確立する。
続いて、オーディオクライアントはＴＣＰソケット（１）でクライアントインデックス要求コマンドをコンテンツサーバに送信する（Ｓ１２０６）。コンテンツサーバは、このクライアントインデックス要求コマンドに応答してＴＣＰソケット（１）からクライアントインデックスをオーディオクライアントに返信し（Ｓ２２０２）、オーディオクライアントはこれを受信する（Ｓ１２０７）。クライアントインデックスは、コンテンツサーバにより各オーディオクライアントに割り当てられる識別番号である。クライアントインデックス要求コマンドは、オーディオクライアントがコンテンツサーバにクライアントインデックスを要求するコマンドである。
続いて、オーディオクライアントは、コンテンツサーバのＩＰアドレス及びプッシュポートでＴＣＰソケット（２）を生成し（Ｓ１２０８）、このＴＣＰソケット（２）でコンテンツサーバと接続する（Ｓ１２０９）。プッシュポートは、コンテンツサーバからの自発的な要求又はコントローラからの要求に応じたコンテンツサーバからの要求（以下「サーバリクエスト」という）を常に受信可能な待機状態にあるポートである。コンテンツサーバがプッシュポートでの接続を受け付け（Ｓ２０９）、接続が成功した場合はステップＳ１２１１に進むが、そうでない場合は接続は失敗となる（Ｓ１２１０）。これによりオーディオクライアントは、サーバリクエストを受信するための接続を確立する。
この時点では、コンテンツサーバは未だ、プッシュポートに接続されているのはどのオーディオクライアントなのかわかっていない。そこで、オーディオクライアントはステップＳ１２０７で取得したクライアントインデックスをＴＣＰソケット（２）でコンテンツサーバに送信する（Ｓ１２１１）。コンテンツサーバは、このクライアントインデックスに基づいてプッシュポートに接続されているオーディオクライアントを特定する。以降、コンテンツサーバは、サーバリクエストをオーディオクライアントに送信するとき、このプッシュポートを使用する。
以上の結果、コマンドポート及びプッシュポートで２つの接続が確立する。これら２つの接続は、オーディオクライアントＣｊ及びコンテンツサーバＳｉの間だけでなく、後述するコントローラＡｋ及びコンテンツサーバＳｉの間、さらにＡＶＲクライアントＡＣ及びコンテンツサーバＳｉの間でも確立する。
一般に、サーバクライアントシステムでは、ＨＴＴＰプロトコルに見られるように、クライアントからの要求（ページ要求など）に対し、コンテンツサーバがレスポンス（ＨＴＭＬ文書など）を返すというものである。これは、アクションのトリガはクライアントのみが有し、コンテンツサーバが自発的にクライアントに対して働きかけることができないということを意味している。このため、コンテンツサーバがクライアントに対して何らかの要求、たとえばコンテンツサーバシャットダウン時にクライアントにその旨を通知するなど、自発的なアクションをする場合でも、クライアントからの要求がなければ通知を行うことはできない。
クライアントがサーバリクエストを受信するためには、一定時間ごとにコンテンツサーバに対してサーバリクエストがないかを確認するコマンドを発行する。コンテンツサーバはクライアントにより発行されたコマンドに応答してサーバリクエストをクライアントに送信し、クライアントはこれを受信する。
上記ＨＴＴＰプロトコルの場合も、動的に更新されるページに関しては一定時間ごとにページのリロードを行わなければならないということが知られている。この手法はクライアントからのポーリングによるサーバリクエストの取得と呼ぶことができるが、以下のような問題点がある。
（１）ポーリング間隔をある程度短くして、こまめにサーバリクエストがあるか否かを尋ねないと、コンテンツサーバが要求を生じた時間と実際にその要求をオーディオクライアントが受け取るまでの時間に差が生じる。
（２）上記のようにポーリング間隔を短くすると、ネットワークトラフィック及びサーバクライアントの負荷が増大してしまう。
（３）コンテンツサーバがサーバリクエストをクライアントに送信しなければならない頻度は通常のコマンドを送受信する頻度に比べて低いので、大概のポーリングは無駄になる。サーバリクエストがあるか否かを尋ねても、通常は何も要求はないと返答されるからである。
上記問題を解決するためには、クライアントからのポーリングではなく、コンテンツサーバからのインタラプトでサーバリクエストをクライアントに送信すればよい。これにより、上記（１）で問題となっているリアルタイム性の欠如、並びに上記（２）及び（３）のような無駄な負荷を排除することができる。
これを実現するために、上述したように２つの接続を確立している。１つは、オーディオクライアントＣｊがコマンドを発行し、コンテンツサーバＳｉがそれに応答するのに用いられるコマンドポートに形成される接続である。もう１つは、コンテンツサーバＳｉがサーバリクエストをオーディオクライアントＣｊに送りつけるのに用いられるプッシュポートに形成される接続である。これによりオーディオクライアントＣｊからのポーリングを用いずに、コンテンツサーバＳｉがサーバリクエストをオーディオクライアントＣｊに通知することができる。
以下、これら２つの接続を用いた動作の概要を説明する。
図８に示すように、コンテンツサーバＳｉは、シャットダウン時に、プッシュポートを通じて全てのオーディオクライアントＣｊにその旨を通知し、これによりオーディオクライアントＣｊに何らかの動作（電源を落とすなど）をさせる。
また、図９に示すように、コントローラＡｋは、オーディオクライアントＣｊを制御するとき（たとえば再生や停止など）、その制御内容を含むサーバリクエストの発行をコンテンツサーバＳｉに要求するコマンドをコマンドポートを通じてコンテンツサーバＳｉに送信する。コンテンツサーバＳｉはこのコマンドに応答してサーバリクエストをプッシュポートを通じてオーディオクライアントＣｊに送信する。その結果、コントローラＡｋはオーディオクライアントＣｊを制御することができる。
さらに、図１０に示すように、オーディオクライアントＣｊは、その動作状態が変化したときに、その動作状態の変化をコマンドポートを通じてコンテンツサーバＳｉに送信する。コンテンツサーバＳｉは、その動作状態の変化をプッシュポートを通じてオーディオクライアントＣｊの動作状態を監視しているコントローラＡｋに送信する。したがって、オーディオクライアントＣｊはその動作状態の変化をリアルタイムにコントローラＡｋに通知することができる。
以上により、本ネットワーク型オーディオシステムにおけるネットワークトラフィック並びにコンテンツサーバ及びオーディオクライアントの負荷を最小に抑えることができ、システム全体のパフォーマンスを増大させることができる。
１．２．１．１．３．クライアント情報の送信
図１１を参照して、オーディオクライアントは、自身の属性情報をコンテンツサーバに送信し（Ｓ１３０１〜Ｓ１３０３）、さらに自身の初期ステータスを送信する（Ｓ１３０４〜Ｓ１３０５）。
具体的には、オーディオクライアントは、ＴＣＰソケット（１）でオーディオクライアントタイプを送信する（Ｓ１３０１）。オーディオクライアントタイプには、再生可能な音楽フォーマットの種類、リモートコントローラ（リモコン）による操作の可否、ＥＩＡ−２３２ポートの有無等がある。
続いて、オーディオクライアントは、ＴＣＰソケット（１）でプロダクトＩＤを送信する（Ｓ１３０２）。プロダクトＩＤは、オーディオクライアントのタイプごとに付与される機種情報である。したがって、同じタイプのオーディオクライアントには同じプロダクトＩＤが付与される。
続いて、オーディオクライアントは、ＴＣＰソケット（１）でファームウェアＩＤを送信する（Ｓ１３０３）。ファームウェアＩＤは、オーディオクライアントにインストールされているファームウェアのバージョン情報である。
続いて、オーディオクライアントは、ＴＣＰソケット（１）でボリュームの初期値を送信する（Ｓ１３０４）。ボリュームの初期値は、オーディオクライアントで再生される音量の初期値である。
最後に、オーディオクライアントは、ＴＣＰソケット（１）でオーディオクライアントの初期ステータスを送信する（Ｓ１３０５）。オーディオクライアントの初期ステータスには、停止ステータス等がある。
コンテンツサーバは、クライアントから送信されたクライアント情報を受信し、クライアント情報データベース（図１３）に格納する。クライアント情報は、オーディオクライアントＣｊだけでなく、コントローラＡｋ及びＡＶＲクライアントＡＣからもコンテンツサーバＳｉに送信される。コンテンツサーバＳｉは、このクライアント情報に基づいて全てのクライアントを管理する。
１．２．１．２．コンテンツサーバの初期設定動作
次に、上記オーディオクライアントの初期設定動作に対応するコンテンツサーバの初期設定動作を説明する。
図１２を参照して、コンテンツサーバは、図１３に示すようなクライアント情報データベースのための格納領域を最大クライアント数分確保し、クリアする（Ｓ２０１）。各クライアント情報は、接続の有無を示すフラグと、クライアントタイプと、現在のステータスと、現在のボリューム値と、プロダクトＩＤと、ファームウェアＩＤと、クライアント名と、再生ファイル名と、リスト構築キーとを含む。
クライアントタイプには、オーディオクライアント、コントローラ、ＡＶＲクライアントといったクライアントのタイプと、再生可能なデータフォーマット（ＭＰ３、ＷＡＶなど）とが記録される。クライアントタイプにはさらに、リモコン制御の可否も記録される。たとえばリモコンにより制御可能なオーディオクライアントには、リモコン制御可能という情報が記録される。ステータスには、「再生」、「停止」、「ポーズ」、「完了」、「ファームウェアアップデート中」などのステータスが記録される。再生ファイル名には、現在再生中の曲のデータが格納されているＨＤＤ１４のフルパス名が記録される。また、再生ファイル名はフルパス名のようなファイル名そのものである必要はなく、そのファイルを特定可能な情報であればいかなる情報であってもよい。たとえばコンテンツサーバに所定の識別番号とファイル名とを対応つけたテーブルを記憶しておき、コンテンツサーバがこのテーブルを参照して識別番号をファイル名に変換するようにしてもよい。この場合、長いファイル名を送受信する必要がなくなる。また、ファイル名から直ちに曲のデータが格納されているファイルを特定することができないので、セキュリティが向上する。さらに、リスト構築キーは、コンテンツサーバがリストを作成するためのものであるが、詳細は後述する。
続いて、コンテンツサーバは、コマンドポートへの接続要求を受け付けるソケットと、プッシュポートへの接続要求を受け付けるソケットと、サーチポートへのサーバ探索要求を受け付けるソケットとを作成する（Ｓ２０２）。サーチポートは、コンテンツサーバ探索時に使うポートであり、このサーチポートにマジックワードが入力されたかどうかをコンテンツサーバは監視する。
続いて、コンテンツサーバは、図１４に示すようなコンテンツ情報データベースと、図１５に示すようなファームウェア情報データベースとを構築する（Ｓ２０３）。コンテンツ情報データベースは、コンテンツ情報を曲数分備える。各曲のコンテンツ情報は、ファイル名と、曲名と、アーティスト名と、アルバム名と、ジャンル名と、曲の長さ（時間）と、データフォーマットと、再生回数と、最終アクセス時間とを含む。このファイル名には、当該曲のデータが格納されているＨＤＤ１４のフルパス名が記録される。ファームウェア情報データベースは、ファーム情報をファームウェアのファイル数分備える。ファームウェア情報は、プロダクトＩＤと、ファームウェアＩＤと、ファイルサイズと、データフォーマットと、ファイル名とを含む。このファイル名には、当該ファームウェアが格納されているインターネット上のサイトを示すフルパス名が記録される。
コンテンツサーバは、サーチポートに書込があった場合（Ｓ２０４）、後述するコンテンツサーバ探索に対する応答処理を行う（Ｓ２０５）。コンテンツサーバはまた、コマンドポートに書込があった場合（Ｓ２０６）、後述するコマンドポート接続受付処理を行う（Ｓ２０７）。コンテンツサーバはまた、プッシュポートに書込があった場合（Ｓ２０８）、後述するプッシュポート接続受付処理（その１）を行う（Ｓ２０９）。コンテンツサーバはまた、未処理プッシュポートに書込があった場合（Ｓ２１０）、後述するプッシュポート接続受付処理（その２）を行う（Ｓ２１１）。
１．２．１．２．１．コンテンツサーバ探索に対する応答
図１６を参照して、サーチポートに書込があった場合、コンテンツサーバは、その書き込まれた内容を取得し（Ｓ２０５１）、その内容が正しいマジックワードか否かを判別する（Ｓ２０５２）。正しいマジックワードであれば、コンテンツサーバは同じマジックワードを送信元クライアントに返信し（Ｓ２０５３）、併せて自身のＩＰアドレス及びポート番号を返信する。
１．２．１．２．２．コマンドポート接続受付
図１７を参照して、コマンドポートにクライアントから接続の要求があった場合、コンテンツサーバは、現在接続されているクライアント数が最大クライアント数に達しているか否かを判別する（Ｓ２０７１）。最大クライアント数に達している場合、コンテンツサーバは、優先度の低いクライアントを探し、強制的に切断する（Ｓ２０７２）。クライアントの優先度は、現在再生を行っていないオーディオクライアント、一定時間通信を行っていないオーディオクライアント等ほど、低くなる。そして、コンテンツサーバは、強制的に切断したクライアントのクライアント情報をクリアする（Ｓ２０７３）。
なお、現在接続されているクライアント数が最大クライアント数に達している場合、上記に代えて、コンテンツサーバはこれ以上クライアントと接続しないようにしてもよい。
クライアントの接続可能なソケットに余裕がある場合、又は優先度の低いクライアントを切断して接続可能なソケットを確保した場合、コンテンツサーバは、クライアントからの接続要求の受付を開始する（Ｓ２０７４）。
受付が成功した場合（Ｓ２０７５）、コンテンツサーバは、クライアント情報データベースの空き領域を探す（Ｓ２０７６）。具体的には、フラグがＦＡＬＳＥになっているクライアント情報を探す。コンテンツサーバは、その探した領域を新しいクライアント情報格納領域に割り当て（Ｓ２０７７）、前のクライアント情報をクリアする（Ｓ２０７８）。
続いて、コンテンツサーバはフラグをＴＲＵＥに設定し（Ｓ２０７８）、受付の結果として得られたソケット情報をクライアント情報格納領域のソケットフィールドに格納する（Ｓ２０７９）。
１．２．１．２．３．プッシュポートへの接続受付処理（その１）
図１８を参照して、プッシュポートにクライアントから接続の要求があった場合、コンテンツサーバは、その受付を開始する（Ｓ２０９１）。受付が成功した場合（Ｓ２０９２）、受付の結果として得られたソケット情報を未処理プッシュポートのキューに格納する（Ｓ２０９３）。この時点では未だ、コンテンツサーバはプッシュポートに接続されたクライアントを特定できていない。このようなプッシュポートを未処理プッシュポートという。
１．２．１．２．４．プッシュポート接続受付処理（その２）
図１９を参照して、未処理プッシュポートにクライアントから接続の要求があった場合、コンテンツサーバは、そのプッシュポートに書き込まれたコマンドを取得する（Ｓ２１１１）。そのコマンドのサイズが０よりも大きく（Ｓ２１１２）、かつそのコマンドがクライアントインデックス通知コマンドであれば（Ｓ２１１３）、コンテンツサーバは、そのクライアントインデックスが示すクライアントは既にコマンドポートに接続されているか否かを判別する（Ｓ２１１４）。
未だ接続が完了していない場合、コンテンツサーバはエラーコードを−１（失敗）に設定し（Ｓ２１１５）、ステップＳ２１１９に進む。一方、既に接続が完了している場合、コンテンツサーバは、このプッシュポートをそのクライアント用のプッシュポートとして登録する（Ｓ２１１６）。コンテンツサーバはさらに、このプッシュポートを未処理プッシュポートのキューから削除し（Ｓ２１１７）、エラーコードを０（成功）に設定する（Ｓ２１１８）。そして、コンテンツサーバは、設定されたエラーコードをクライアントに返信する（Ｓ２１１９）。
１．２．２．コンテンツサーバ及びオーディオクライアントのメイン動作
１．２．２．１．コマンド受付
再び図１２を参照して、コンテンツサーバは、初期設定を完了した後、クライアントからのコマンドを受け付ける。すなわち、コンテンツサーバは、ステップＳ２１３〜Ｓ２１７を最大クライアント数分繰り返す（Ｓ２１２、Ｓ２１８、Ｓ２１９）。ｎは、クライアントに割り当てられる０から（最大クライアント数−１）までのクライアントインデックスである。
具体的には、コンテンツサーバは、クライアント情報データベースのフラグを参照し、ｎ番目のクライアントが既にコマンドポートに接続されているか否かを判別する（Ｓ２１３）。既に接続されている場合、コンテンツサーバはｎ番目のクライアント用のコマンドポートに書込があったか否かを判別する（Ｓ２１４）。書込があった場合、コンテンツサーバはその書き込まれたデータのサイズが０又は−１であるか否かを判別する（Ｓ２１５）。０又は−１の場合、クライアントが切り離されたか、又はソケットエラーが発生したかであるから、コンテンツサーバはｎ番目のクライアント情報をクリアする（Ｓ２１６）。一方、そうでない場合、コンテンツサーバは次のコマンド処理を行う（Ｓ２１７）。
１．２．２．１．１．コマンド振分処理
図２０を参照して、クライアントからコマンドポートへの書込があった場合、コンテンツサーバは、先頭４バイトに格納されたコマンドに応じて処理を分岐する（Ｓ２１７１）。すなわち、オーディオクライアントからコンテンツサーバにステータスの変動を通知するといったステータス通知コマンドであれば（Ｓ２１７２）、オーディオクライアントから通知されたステータスをコントローラに通知する（Ｓ２１７３）。詳細は後述する。また、コントローラからオーディオクライアントへのコンテンツサーバリクエスト発行コマンドであれば（Ｓ２１７４）、コントローラからの要求をオーディオクライアントに通知する（Ｓ２１７５）。詳細は後述する。その他、コンテンツサーバはコマンドに応答して所定の処理を行う。
１．２．２．１．２．ステータス通知コマンド処理
あるオーディオクライアント（以下「当該オーディオクライアント」という。）からのコマンドがステータス通知コマンドの場合、図２１を参照して、コンテンツサーバは、まず、そのコマンド中のパラメータに格納されたステータスやボリューム等のクライアント情報をクライアント情報データベースに格納する（Ｓ２１７３１）。したがって、コンテンツサーバは常に最新のクライアント情報を保持している。
次に、コンテンツサーバは、全てのクライアントの中からコントローラを探し出し、探し出したコントローラに当該オーディオクライアントのステータスを通知する。そのため、コンテンツサーバは、以下のステップＳ２１７３３〜Ｓ２１７３６を最大クライアント数分繰り返す（Ｓ２１７３２、Ｓ２１７３７、Ｓ２１７３８）。
具体的には、コンテンツサーバは、クライアント情報のクライアントタイプを参照して、ｎ番目のクライアントがコントローラか否かを判別する（Ｓ２１７３３）。したがって、当該オーディオクライアントのステータスをコントローラではない当該他のオーディオクライアントに通知することを防ぐことができる。コントローラであれば、コンテンツサーバは、そのコントローラが当該オーディオクライアントに対する監視ハンドルを取得しているか否かを判別する（Ｓ２１７３４）。監視ハンドルを取得していれば、コンテンツサーバは、そのコントローラがプッシュポートへの接続を完了しているか否かを判別する（Ｓ２１７３５）。
プッシュポートへの接続を完了していれば、コンテンツサーバは、そのコントローラのプッシュポートに当該オーディオクライアントのクライアント情報を書き込み、これにより当該オーディオクライアントのステータスをコントローラに通知する（Ｓ２１７３６）。
１．２．２．１．３．サーバリクエスト発行コマンド処理
コントローラからのコマンドがサーバリクエスト発行コマンドの場合、図２２を参照して、コンテンツサーバは、まず、そのコマンドに含まれる発行元コントローラ、送信先オーディオクライアント、要求内容等を取得する（Ｓ２１７５１）。
コンテンツサーバは、発行元コントローラが送信先オーディオクライアントの制御ハンドル（後述）を取得しているか否かを判別し（Ｓ２１７５２）、制御ハンドルを取得していなければエラーコードを−１に設定する（Ｓ２１７５３）。したがって、制御ハンドルを取得していないコントローラがオーディオクライアントを制御するのを防止することができる。
制御ハンドルを取得していれば、コンテンツサーバは、クライアント情報中のフラグを参照して送信先オーディオクライアントのコマンドポートで接続が確立しているか否かを判別し（Ｓ２１７５４）、確立していなければエラーコードを−２に設定する（Ｓ２１７５５）。したがって、制御不可能なオーディオクライアントにコマンドを送信するのを防止することができる。
送信先オーディオクライアントのコマンドポートで接続が確立していれば、コンテンツサーバは、送信先オーディオクライアントのプッシュポートで接続が確立しているか否かを判別し（Ｓ２１７５６）、確立していなければエラーコードを１に設定する（Ｓ２１７５７）。一方、確立していれば、コンテンツサーバは、送信先オーディオクライアントのプッシュポートにコントローラからの要求内容を送信し（Ｓ２１７５８）、エラーコードを０（エラーなし）に設定する（Ｓ２１７５９）。
最後に、コンテンツサーバは、発行元コントローラにエラーコードを返信する（Ｓ２１７６０）。
なお、送信先オーディオクライアントがプッシュポートに接続されていない場合は、送信先オーディオクライアントがポーリングで問い合わせをしてきたときに、コントローラからの要求内容を送信先オーディオクライアントに送信するようにしてもよい。
１．２．２．２．通常再生
次に、ユーザがオーディオクライアントＣｊに所望の曲を再生させる場合の動作を説明する。ここでは、ユーザは所望の曲を直ちに指定するのではなく、まず所望の曲リストを指定し、その曲リストの中から所望の曲を選択する。以下、詳述する。
図２３を参照して、オーディオクライアントは、ユーザの操作に応じて曲リスト要求コマンドをコンテンツサーバに送信する（Ｓ１４）。曲リスト要求コマンドは、オーディオクライアントがコンテンツサーバに対して所望の曲リストを要求するためのコマンドである。曲リストには、複数の曲名やアーティスト名などが列挙されている。コンテンツサーバはこの曲リスト要求コマンドに応じて曲リストを要求元のオーディオクライアントに送信し（Ｓ２４）、オーディオクライアントはこれを受信する（Ｓ１４）。
オーディオクライアントはユーザの操作に応じて曲リストに含まれる曲を指定し（Ｓ１５）、コンテンツサーバはこれに応じて指定された曲の配信を準備する（Ｓ２５）。
続いて、コンテンツサーバは指定された曲をオーディオクライアントに配信し（Ｓ２６）、オーディオクライアントは配信された曲を再生する（Ｓ１６）。そして、オーディオクライアントは、再生終了後又はユーザの操作に応じて曲の再生を停止する（Ｓ１７）。
以下、ステップＳ１４〜Ｓ１６の各々の詳細を説明する。
１．２．２．２．１．曲リスト取得
図２４を参照して、オーディオクライアントは、コンテンツサーバにプレイ名リストを要求するか否かを判別する（Ｓ１４０１）。プレイ名リストは、プレイリストのタイトルを列挙したものである。プレイリストは、ユーザにより選択された複数の曲を列挙した曲リストである。コンテンツサーバには、ユーザにより作成された複数のプレイリストが予め格納されている。
ユーザは、コンテンツサーバに格納されている複数のプレイリストの中から１つを選択しようとする場合、まずどのようなプレイリストが登録されているのかを確認するために、コンテンツサーバにプレイ名リストを要求する。オーディオクライアントはこのユーザの操作に応じてコンテンツサーバにプレイ名リストを要求し、コンテンツサーバからプレイ名リストを受信する（Ｓ１４０２）。
続いて、オーディオクライアントは、指定されたプレイリストを要求するか否かを判別する（Ｓ１４０３）。ユーザがプレイ名リストの中から所望のプレイリストを指定し、この操作に応じてオーディオクライアントが指定されたプレイリストを要求する場合はステップＳ１４１３に進み、要求しない場合はステップＳ１４０１又Ｓ１４０３に戻る（Ｓ１４０４）。
プレイ名リストを要求しない場合、オーディオクライアントは、コンテンツサーバにアーティストリストを要求するか否かを判別する（Ｓ１４０５）。アーティストリストには、複数のアーティスト名が列挙されている。アーティストリストはコンテンツサーバに予め用意されているのではなく、オーディオクライアントからの要求に応じて図１４に示したコンテンツ情報データベースからその都度作成される。
ユーザがアーティストリストを要求する場合、オーディオクライアントはユーザの操作に応じて所望のアーティストリストをコンテンツサーバに要求し、コンテンツサーバからアーティストリストを受信する（Ｓ１４０６）。
続いて、オーディオクライアントは、指定されたアーティストの曲リストを要求するか否かを判別する（Ｓ１４０７）。ユーザがアーティストリストの中から所望のアーティストを指定し、この操作に応じてオーディオクライアントが指定されたアーティストの曲リストを要求する場合はステップＳ１４１３に進み、要求しない場合はステップＳ１４０１又Ｓ１４０７に戻る（Ｓ１４０８）。この曲リストには指定されたアーティストの曲名などが列挙されているが、この曲リストも上記アーティストリストと同様にコンテンツサーバに予め用意されているのではなく、オーディオクライアントからの要求に応じて図１４に示したコンテンツ情報データベースからその都度作成される。
アーティストリストを要求しない場合、オーディオクライアントは、コンテンツサーバにジャンルリストを要求するか否かを判別する（Ｓ１４０９）。ジャンルリストには、複数のジャンル名が列挙されている。ジャンルリストも上記アーティストリストと同様にコンテンツサーバに予め用意されているのではなく、オーディオクライアントからの要求に応じて図１４に示したコンテンツ情報データベースからその都度作成される。
ユーザがジャンルリストを要求する場合、オーディオクライアントはユーザの操作に応じて所望のジャンルリストをコンテンツサーバに要求し、コンテンツサーバからジャンルリストを受信する（Ｓ１４１０）。
続いて、オーディオクライアントは、指定されたジャンルの曲リストを要求するか否かを判別する（Ｓ１４１１）。ユーザがジャンルリストの中から所望のジャンルを指定し、この操作に応じてオーディオクライアントが指定されたジャンルの曲リストを要求する場合はステップＳ１４１３に進み、要求しない場合はステップＳ１４０１又Ｓ１４１１に戻る（Ｓ１４１２）。この曲リストには指定されたジャンルの曲名などが列挙されているが、この曲リストも上記アーティストの曲リストと同様にコンテンツサーバに予め用意されているのではなく、オーディオクライアントからの要求に応じて図１４に示したコンテンツ情報データベースからその都度作成される。
上記の結果、曲リストを要求する場合、オーディオクライアントはコンテンツサーバに曲リストを要求し、コンテンツサーバから曲リストを受信する（Ｓ１４１３）。これにより曲リストの取得は終了する。
次に、図２５を参照して、ジャンルリストを取得し、その中から所望のジャンルとしてポップスを選択してポップスの曲リストを取得する場合の動作を説明する。
この場合、オーディオクライアントは、コンテンツサーバにジャンルリストを要求するためのリスト要求コマンドを送信する（Ｓ１４２１）。コンテンツサーバは、これに応答してジャンルリストを返信する（Ｓ２４０１）。オーディオクライアントは、コンテンツサーバからジャンルリストを受信し、図２６に示すようにメモリ３２に格納する（Ｓ１４２２）。
ジャンルリストは、予め作成してコンテンツサーバに保存しておいてもよいが、ここではそうではなく、オーディオクライアントから要求されるたびに、コンテンツサーバが図１４に示したコンテンツ情報データベースに基づいてジャンルリストを作成する。以下、ジャンルリストの作成方法を説明する。
図２７に示すように、コンテンツ情報データベースは、ｎ曲を保存している場合、ｎ個のレコードを有する。各レコードには、曲名、ジャンル、アーティスト名、アルバム名などが記録されている。
このようなコンテンツ情報データベースを用いてジャンルリストを作成する場合、図２８を参照して、まず、コンテンツサーバは、レコードの番号を示すインデックスを０に初期化する（Ｓ２４０１１）。
続いて、コンテンツサーバは、インデックスが示すレコードのジャンルが既にジャンルリストに存在するか否かを判別する（Ｓ２４０１２）。存在しない場合、コンテンツサーバはそのレコードのジャンルをジャンルリストに追加し（Ｓ２４０１３）、その後、インデックスをインクリメントする（Ｓ２４０１４）。一方、存在する場合、コンテンツサーバは、ステップＳ２４０１３をスキップし、直ちにインデックスをインクリメントする（Ｓ２４０１４）。
続いて、コンテンツサーバは、インデックスが示すレコードの番号が全レコード数ｎよりも小さいか否かを判別し（Ｓ２４０１５）、小さい場合はステップＳ２４０１２に戻り、一方、小さくない場合はジャンルリストの作成を完了する。
上記の処理により、コンテンツサーバは、コンテンツ情報データベースに蓄積されている全ての曲のジャンルを重複することなくピックアップし、ジャンルリストを作成する。このように、ジャンルリストは予めデータベース化されているのではなく、オーディオクライアントからの要求のたびに一時的に作成されるので、ジャンルリストを常に格納しておくためのメモリ領域は不要である。
再び図２５を参照して、作成されたジャンルリストはコンテンツサーバからオーディオクライアントに送信される（Ｓ２４０１，Ｓ１４２２）。ユーザは、このジャンルリストの中から所望のジャンル（この例ではポップス）を選択する。オーディオクライアントは、ユーザの操作に応じて選択されたジャンルの曲リストをコンテンツサーバに要求する（Ｓ１４２３）。コンテンツサーバは、オーディオクライアントからの要求に応じて選択されたジャンルの曲リストをコンテンツサーバに返信する（Ｓ２４０２）。オーディオクライアントは、コンテンツサーバから曲リストを受信し、図２９に示すようにメモリ３２に格納する（Ｓ１４２４）。
上記ジャンルリストと同様に、曲リストもコンテンツサーバに予め用意されているのではなく、図２７に示したコンテンツ情報データベースに基づいて作成される。すなわち、コンテンツサーバは、オーディオクライアントから曲リストを要求されるたびに、コンテンツ情報データベースに基づいて曲リストを作成する。以下、曲リストの作成方法を図３０を参照して説明する。
まず、コンテンツサーバは、図２７に示したコンテンツ情報データベースにおけるレコードの番号を示すインデックスを０に初期化する（Ｓ２４０２１）。
続いて、コンテンツサーバは、インデックスが示すレコードのジャンルを選択されたジャンル（この例ではポップス）と比較し、それらが一致するか否かを判別する（Ｓ２４０２２）。一致する場合、コンテンツサーバはそのレコードの曲名、アーティスト名、アルバム名などを曲リストに追加し（Ｓ２４０２３）、その後、インデックスをインクリメントする（Ｓ２４０２４）。一方、一致しない場合、コンテンツサーバは、ステップＳ２４０２３をスキップし、直ちにインデックスをインクリメントする（Ｓ２４０２４）。
続いて、コンテンツサーバは、インデックスが示すレコードの番号が全レコード数ｎよりも小さいか否かを判別し（Ｓ２４０２５）、小さい場合はステップＳ２４０２２に戻り、一方、小さくない場合は曲リストの作成を完了する。
上記の処理により、コンテンツサーバは、選択されたジャンルの曲だけをコンテンツ情報データベースからピックアップし、曲リストを作成する。このように、曲リストは予めデータベース化されているのではなく、オーディオクライアントからの要求のたびに一時的に作成されるので、曲リストを常に格納しておくためのメモリ領域は不要である。
なお、曲リストを作成する場合には、該当する全ての曲をピックアップするのではなく、再生不可能なデータフォーマットの曲についてはピックアップしないようにしてもよい。また、オーディオクライアントからの要求のたびに曲リストを作成するのではなく、一旦作成した曲リストはキャッシュしておくようにしてもよい。この場合、曲リストを格納しておくためのメモリ領域が必要になるが、コンテンツサーバはオーディオクライアントからの要求に応じて直ちに曲リストを返信することができる。
上記ジャンルリストと同様に、曲リストも全部が一度に送信されるのではなく、少しずつ順に送信される。すなわち、曲リストの要求（Ｓ１４２３，Ｓ１４２５）、曲リストの返信（Ｓ２４０２，Ｓ２４０３）及び曲リストの受信（Ｓ１４２４，Ｓ１４２６）の動作は繰り返し行われる。以下、この詳細を説明する。
オーディオクライアントは、図３１に示すようなリスト要求コマンドをコンテンツサーバに送信する（Ｓ１４２３）。リスト要求コマンドは、オーディオクライアントがコンテンツサーバにリストを要求するコマンドであり、この例では、取得開始インデックス、取得個数及びリスト構築キーを含む。取得開始インデックスは、選択されたジャンルリストに収録されている曲のうち、オーディオクライアントが取得しようとする先頭の曲を示すインデックスである。取得個数は、オーディオクライアントが取得しようとする曲の数である。リスト構築キーは、詳細は後述するが、コンテンツ情報データベースから曲を抽出するときに注目するカテゴリを示すフィルタの種類と、そのカテゴリに分類される具体的なキーワードとから構成される。特に限定されないが、この例では、取得開始インデックス＝０、取得個数＝５０に設定され、さらにリスト構築キーは「ジャンル（フィルタの種類）＝ポップス（キーワード）」に設定されている。
コンテンツサーバは、このリスト要求コマンドに応答して、図３２に示すような検索データをオーディオクライアントに返信する（Ｓ２４０２）。検索データは、曲リストの一部のほか、有効個数及び残り個数を含む。有効個数は、コンテンツサーバがオーディオクライアントに実際に返信した曲の数である。残り個数は、コンテンツサーバがオーディオクライアントに返信した曲リストよりも後に残っている曲の数である。ここでは、取得開始インデックス＝０、取得個数＝５０のリスト要求コマンドに応答するのであるから、コンテンツサーバは、作成した曲リストのうち最初の曲から５０曲目までをオーディオクライアントに返信する（Ｓ２４０２）。曲リストの全曲数＝１１０とすると、有効個数＝５０、残り個数＝６０（＝１１０−５０）に設定される。
続いて、オーディオクライアントは、コンテンツサーバに未だ６０曲が残っているから、再びリスト要求コマンドをコンテンツサーバに送信する（Ｓ１４２５）。ここでは、取得開始インデックス＝５１、取得個数＝５０に設定される。
コンテンツサーバは、このリスト要求コマンドに応答して、再び検索データをオーディオクライアントに返信する（Ｓ２４０３）。ここでは、有効個数＝５０、残り個数＝１０（＝１１０−（５０＋５０））に設定される。すなわち、コンテンツサーバは、再び曲リストを５０曲分だけオーディオクライアントに返信する（Ｓ２４０３）。オーディオクライアントは、この曲リストを受信し、メモリ３２に格納する（Ｓ１４２６）。
なお、上記の例では、曲リストの全曲数＝１１０、取得個数＝５０であるから、曲リストの一部である５０曲が返信されているが、曲リストの全曲数が取得個数よりも少ない場合、たとえば曲リストの全曲数＝４０、取得個数＝５０であれば、曲リストの全部である４０曲が返信されることになる。
また、上記の例では、取得開始インデックス＝０であるから、曲リストの最初から曲が返信されているが、たとえば取得開始インデックス＝１０とすれば、曲リストの１１曲目から曲が返信されることになる。また、この場合、曲リストの全曲数＝１１０であり、最初のリスト要求コマンドが取得開始インデックス＝１０、取得個数＝５０であれば、コンテンツサーバは、有効個数＝５０、残り個数＝５０（＝１１０−１０−５０）の検索データを返信することになる。
メモリ３２に格納可能な曲数が曲リストの全曲数よりも多ければ、オーディオクライアントは曲リストの全部を一度に格納することができる。しかし、メモリ３２の容量はコンテンツサーバに比べると非常に小さいため、通常、オーディオクライアントは曲リストの一部しかメモリ３２に格納することができない。
上記実施の形態によれば、オーディオクライアントはコンテンツサーバから曲リストを分割してダウンロードしているため、オーディオクライアントのメモリ３２に少なくとも５０曲分の領域を用意すれば、１１０曲全ての曲リストをダウンロードすることができる。そのため、メモリ３２の容量を小さく抑えることができる。
たとえば図３３Ａに示すように、オーディオクライアントがメモリ３２に５０曲分の曲リストを格納した後、ユーザが５１曲目以降の取得を希望した場合、図３３Ｂに示すように、オーディオクライアントは後半の曲リストをメモリ３２の前半に移動させる。そして、図３３Ｃに示すように、オーディオクライアントはメモリ３２の後半に５１曲目から２５曲分の曲リストを格納する。
オーディオクライアントは、上記動作を繰り返して曲リストの全部を受信するか、又はメモリ３２に格納可能な曲数だけ受信する。
図２５に示した例では、ジャンルを選択した後、直ちにそのジャンルから曲を選択するようにしているが、図３４に示したように、ジャンルを選択し、引き続きそのジャンルからアルバムを選択した後、そのアルバムから曲を選択するようにしてもよい。
この場合、オーディオクライアントは、ユーザの操作に応じて選択されたジャンルのアルバムリストをコンテンツサーバに要求する（Ｓ１４２７）。コンテンツサーバは、オーディオクライアントからの要求に応じて選択されたジャンルのアルバムリストをオーディオクライアントに返信する（Ｓ２４０４）。オーディオクライアントは、コンテンツサーバからアルバムリストを受信し、メモリ３２に格納する（Ｓ１４２８）。
続いて、オーディオクライアントは、ユーザの操作に応じて選択されたアルバムの曲リストをコンテンツサーバに要求する（Ｓ１４２９）。コンテンツサーバは、オーディオクライアントからの要求に応じて選択されたアルバムの曲リストをオーディオクライアントに返信する（Ｓ２４０５）。
１．２．２．２．２．曲の指定
図３５及び図３６を参照して、オーディオクライアントは指定された曲の情報をコンテンツサーバに要求し（Ｓ１５０１）、コンテンツサーバはこの要求に応じて指定された曲の情報をオーディオクライアントに返信し（Ｓ２５０１）、オーディオクライアントはこれを受信する（Ｓ１５０２）。
具体的には、オーディオクライアントは、図３７に示すような曲情報要求コマンドを送信する（Ｓ１５０１）。この曲情報要求コマンドは、指定された曲のファイル名を含む。コンテンツサーバは、この曲情報要求コマンドに応答して、図３８に示すような曲情報を返信する（Ｓ２５０１）。この曲情報は、指定された曲のデータオフセット及びデータサイズを含む。ＭＰ３等の音楽データは一般に、コンテンツ情報の前にヘッダ情報を有する。データオフセットは、このヘッダ情報をスキップし、曲の先頭アドレスを指定するためのものである。オフセットをコンテンツサーバが解析することにより、オーディオクライアントはオフセットを解析する必要がなくなる。一般的に、コンテンツサーバはオーディオクライアントよりも処理能力が高いので、システム全体として処理を高速化することができる。データサイズは、曲の終了時期を確認するためのものである。
続いて、オーディオクライアントは指定された曲の再生準備をコンテンツサーバに要求し（Ｓ１５０３）、コンテンツサーバはこの要求に応じて指定された曲のファイルをオープンし、その結果をオーディオクライアントに返信し（Ｓ２５０２）、オーディオクライアントはこれを受信する（Ｓ１５０４）。
具体的には、オーディオクライアントは、図３９に示すような曲再生準備コマンドを送信する（Ｓ１５０３）。この曲再生準備コマンドは、指定された曲のファイル名及び後述するリスト構築キーを含む。コンテンツサーバは、この曲再生準備コマンドに応答してファイルをオープンし、図４０に示すようなエラーコードを返信する（Ｓ２５０２）。このエラーコードは、ファイルが存在しないなど、ファイル転送の準備ができない場合はエラーありとなり、準備ができる場合はエラーなしとなる。クライアントは送信されたエラーコードを確認し、エラーがあれば所定のエラー処理を行う（Ｓ１５０４）。
１．２．２．２．３．曲の再生
続いて、オーディオクライアントは指定された曲の音楽データのうち指定範囲の音楽データの転送をコンテンツサーバに要求し（Ｓ１６０１）、コンテンツサーバはこの要求に応じて指定範囲の音楽データをオーディオクライアントに返信し（Ｓ２６０１）、オーディオクライアントはこれを受信し、メモリ３２に格納する（Ｓ１６０２）。
具体的には、オーディオクライアントは、図４１に示すような曲データ転送要求コマンドを送信する（Ｓ１６０１）。この曲データ転送要求コマンドは、転送すべき音楽データの取得開始アドレス及び取得データ長を含む。コンテンツサーバは、図４２に示すように、取得開始アドレスにより指定された先頭アドレスからその取得データ長分だけ音楽データを返信する（Ｓ２６０１）。１回に送信されるデータのサイズは、特に限定されないが、好ましくは１Ｋ〜３２Ｋバイトであり、さらに好ましくは４Ｋ〜１６Ｋバイトである。コンテンツサーバは一度に返信するデータ量が小さいほど負荷を小さくすることができ、クライアントは一度に受信するデータ量が大きいほど処理を早くすることができるが、１Ｋ〜３２Ｋバイト（特に、４Ｋ〜１６Ｋバイト）がコンテンツサーバとクライアントとの両方にとって、最適な値となるからである。このようなデータのサイズはオーディオクライアント側で予め設定される。
上記取得開始アドレスを転送した取得データ長分だけ順次加算していき、上記動作を繰り返すことにより（Ｓ１６０５、Ｓ２６０３、Ｓ１６０６、Ｓ１６０７、Ｓ２６０４、Ｓ１６０８）、音楽データを指定範囲ごとに順次転送することができる。
このように、オーディオクライアントは指定した範囲の音楽データをコンテンツサーバから取得することができるので、後述するように、曲を途中から再生できるほか、早送り再生、早戻し再生、スロー再生など、ユーザの操作に応じて音楽を自在に再生することができる。
メモリ３２は、複数（図４３に示した例では８つ）のバッファを含む。図４４に示すように、オーディオクライアントは曲データ転送要求コマンドで曲の先頭から１バッファ分の音楽データを取得して格納する。図４５に示すように、オーディオクライアントは同様にしてバッファが全て埋まるまで音楽データを取得して格納する。
ステップＳ１６０１〜Ｓ１６０８の間で上記のようにバッファが全て埋まったら、オーディオクライアントは、図４６に示すように先頭バッファから音楽データを音声処理部３４に出力し始める。
オーディオクライアントは、上記のように音楽データを出力して音楽の再生を開始したら、再生ステータスをコンテンツサーバに送信する（Ｓ１６０３）。コンテンツサーバはこれを受信し、エラーコードをオーディオクライアントに返信する（Ｓ２６０２）。オーディオクライアントはこのエラーコードを確認し、エラーがあれば所定のエラー処理を行う（Ｓ１６０４）。
上記のように音楽データを転送しながら音楽を再生していると、やがて図４７に示すように１バッファ分の空きが生じる。バッファに空きが生じると（Ｓ１６０９）、オーディオクライアント及びコンテンツサーバは再び上記転送動作を行う（Ｓ１６１０、Ｓ２６０５、Ｓ１６１１）。その結果、図４８に示すようにバッファの空きが埋まる。オーディオクライアント及びコンテンツサーバは、バッファに空きが生じるたびに上記転送動作を繰り返し行う（Ｓ１６１２〜Ｓ１６１６、Ｓ２６０６、Ｓ２６０７）。
なお、上記では、バッファが音楽データで全て埋まってから音楽データを出力し始めているが、全て埋まる前に出力し始めるようにしてもよい。
続いて、オーディオクライアントは、ステップＳ１５０２で取得したデータサイズに基づいて、指定された曲の音楽データを全て受信したか否かを判別する（Ｓ１６１７）。全て受信した場合、オーディオクライアントは、受信した音楽データに基づいて指定された曲を再生し終えたか否かを判別し（Ｓ１６１７１）、再生し終えた場合は停止又は完了ステータスをコンテンツサーバに送信する（Ｓ１６１８）。ユーザがオーディオクライアントを操作し、それに応じてオーディオクライアントが指定された曲を再生しその曲を再生し終えた場合、又はユーザがオーディオクライアントを操作し、それに応じてオーディオクライアントが曲の再生を途中で停止した場合、オーディオクライアントは停止ステータスを送信する。一方、ユーザがコントローラを操作し、それに応じてオーディオクライアントがコントローラから指定された曲を再生しその曲を再生し終えた場合、オーディオクライアントは完了ステータスを送信する。このように停止ステータスと完了ステータスとを区別する理由は後述する。
コンテンツサーバはこのステータスを受信し、エラーコードをオーディオクライアントに返信する（Ｓ２６０８）。オーディオクライアントはこのエラーコードを確認し、エラーがあれば所定のエラー処理を行う（Ｓ１６１９）。
以上のように、音楽データを分割し、コンテンツサーバからオーディオクライアントに断続的に転送しているため、バッファ容量が少なくても適切に音楽を再生することができる。
上記では音楽データをバイト単位で転送しているが、ＭＰ３の音楽データを転送する場合はフレーム単位で転送するのが好ましい。時間表示、早送り又は早戻し再生などの特殊再生（後述）で有利な点が多いからである。したがって、ＭＰ３の音楽データの場合、オーディオクライアントはフレーム単位で音楽データを要求するものとする。この要求に応答して、コンテンツサーバは指定されたファイルの中からＭＰ３のフレームヘッダを検索し、フレームの先頭から転送を行う。このヘッダの中にはデータ長を算出することができるパラメータが含まれているので、一度ヘッダを発見すれば、以降、フレームの先頭を発見するのは困難ではない。
１．２．２．３．特殊再生
また、早送り、早戻し、一時停止、スローなど、特殊再生を可能とするために、音楽データの転送要求、返信及び取得という一連の処理の前に、オーディオクライアントは以下のような処理を行う。
１．２．２．３．１．早送り再生
早送り再生の場合、図４９を参照して、オーディオクライアントは、キー入力を監視し（Ｓ１６２０）、早送り再生キーが押された場合はスキップ量を０よりも大きい値に設定し（Ｓ１６２１）、そうでない場合はスキップ量を０に設定する（Ｓ１６２２）。
バッファに空きが生じると（Ｓ１６０９）、オーディオクライアントは、音楽データの取得開始アドレスを次式により計算する（Ｓ１６２４）。
取得開始アドレス＝前回の取得開始アドレス＋取得データ長＋スキップ量
ステップＳ１６２０で早送り再生キーが押されなかった場合、ステップＳ１６２２でスキップ量は０に設定されるので、取得開始アドレスは取得データ長ずつ増加する。この場合、オーディオクライアントは音楽データを連続的に取得するので、通常の再生を行う。一方、ステップＳ１６２０で早送り再生キーが押された場合、ステップＳ１６２１でスキップ量は０よりも大きい値に設定されるので、オーディオクライアントは音楽データをそのスキップ量だけ飛んで取得する。その結果、オーディオクライアントは早送り再生を行う。この例では、スキップ量が取得データ長と同じに設定されているから、２倍速の早送り再生を行う。また、たとえばスキップ量を取得データ長の２倍とすることにより、３倍速の再生を行うことができる。
１．２．２．３．２．早戻し再生
早戻し再生の場合、オーディオクライアントは、上記ステップＳ１６２０に代えて早戻し再生キーが押されているかを判別し、上記ステップＳ１６２１に代えてスキップ量を０よりも小さく、かつ絶対値が前回の取得データ長よりも大きい値に設定する。スキップ量の絶対値が前回の取得データ長よりも小さいと、音楽データの取得範囲が重複するからである。毎回の取得データ長が一定であれば、絶対値を取得データ長の２倍にすれば、通常再生と同じ速度で戻し再生を行うことができる。
また、オーディオクライアントは、ステップＳ１６２４で計算した取得開始アドレスが音楽データの存在する範囲内か否かを判別する（Ｓ１６２５）。範囲内の場合、オーディオクライアントは次のステップＳ１６１０に進むが、範囲外の場合、オーディオクライアントは再生を停止する。通常再生の場合は音楽データの終わりを検知しているので、このような終了条件を入れる必要はないが、特に早戻し再生の場合は音楽データの始まりを検知する必要があるので、このような終了条件を入れている。ただし、このような終了条件を入れずに、次の曲のファイルをオープンして早送り再生を行ったり、前の曲のファイルをオープンして早戻し再生を行うようにしてもよい。
なお、ＭＰ３の音楽データの場合は、前述したように、フレームヘッダを読み取れば次のフレームヘッダの位置をほぼ確定することができる。したがって、ある一定分のフレームをスキップし、その後の数フレームのデータを再生し、再びフレームをスキップする、という動作を繰り返すことにより早送り再生を実現することができる。
１．２．２．３．３．一時停止
一時停止の場合、図５０を参照して、オーディオクライアントはキー入力を監視し（Ｓ１６２６，Ｓ１６２８）、一時停止キーが押された場合は動作ステータスを一時停止に設定し（Ｓ１６２７）、再生キーが押された場合は動作ステータスを再生に設定する（Ｓ１６２９）。
バッファに空きが生じると（Ｓ１６０９）、オーディオクライアントは動作ステータスが一時停止か否かを判定する（Ｓ１６３１）。一時停止の場合、オーディオクライアントはステップＳ１６２６に戻って次の音楽データの転送を開始しない。一方、一時停止でない場合、すなわち再生キーが押されて一時停止が解除され、動作ステータスが再生に変化した場合、オーディオクライアントはステップＳ１６１０に進んで次の音楽データの転送を開始する。
また、動作ステータスが一時停止になった場合、オーディオクライアントはバッファの読出動作を停止する。バッファには、以前に転送された音楽データが残っているからである。
１．２．２．３．４．スロー再生
音楽ではなく、動画の場合はスロー再生を行う必要がある。通常、動画ファイルはＭＰＥＧ−２のように圧縮形式であるから、オーディオクライアントはこれを再生するためにデコーダを備える。スロー再生の場合、デコーダにスロー再生を指示するコマンドが与えられると、バッファに蓄積されている映像データの減少速度が遅くなる。仮に通常再生の３０％の速度でスロー再生を行うのであれば、デコーダがバッファから読み出す映像データの単位時間当たりの量は３０％になる。そのため、上記ステップＳ１６０９でオーディオクライアントがバッファに空きが生じるのを待つ時間が長くなり、これによりスロー再生を実現することができる。
１．２．３．コントローラの動作
１．２．３．１．コンテンツサーバとの接続
コントローラＡｋもオーディオクライアントＣｊとほぼ同様に、まずコンテンツサーバＳｉとの接続を確立する。
図５１を参照して、コントローラＡｋに電源が投入されると、コントローラＡｋは、コンテンツサーバＳｉのコマンドポートに接続する（Ｓ３００１）。コントローラＡｋは、このコマンドポートを通じてクライアントインデックス要求コマンドを発行する（Ｓ３００２）。コンテンツサーバＳｉはこのコマンドに応答してクライアントインデックスをコントローラＡｋに返信し、コントローラＡｋはその取得したクライアントインデックスを保存する（Ｓ３００３）。
続いて、コントローラＡｋは、コンテンツサーバＳｉのプッシュポートに接続する（Ｓ３００４）。コントローラＡｋは、このプッシュポートを通じてクライアントインデックス通知コマンドを発行し、ステップＳ３００３で保存したクライアントインデックスをコンテンツサーバに送信する（Ｓ３００５）。これにより、プッシュポートが開通する（Ｓ３００６）。
続いて、コントローラＡｋは、クライアントタイプをコマンドポートを通じてコンテンツサーバＳｉに通知する（Ｓ３００７）。ここでは、上記オーディオクライアントＣｊと異なり、コントローラＡｋはクライアントタイプとして自身がコントローラであることを通知する。コンテンツサーバＳｉは、このクライアントタイプによりオーディオクライアントＣｊとコントローラＡｋとを区別することができる。
続いて、コントローラＡｋは、オーディオクライアントＣｊのクライアント情報をコンテンツサーバＳｉから取得し（Ｓ３００８）、その情報に含まれるステータスなどをモニタ上に表示する。
そして、コントローラＡｋは、クライアントタイプ及び取得したクライアントインデックスに基づいて、コンテンツサーバＳｉに接続されているオーディオクライアントＣｊの監視ハンドル及び制御ハンドルをコンテンツサーバＳｉに要求して取得する（Ｓ３００９）。
上記接続手順がオーディオクライアントＣｊと相違する点は、コントローラＡｋは、自身がコントローラであることを示すクライアントタイプをコンテンツサーバＳｉに通知する点である。また、もう１つの相違点は、コントローラＡｋが監視ハンドル及び制御ハンドルの両方又は一方を取得する点である。以下、詳述する。
１．２．３．１．１．監視ハンドル及び制御ハンドルの取得
図５２を参照して、コントローラＡｋは、コンテンツサーバＳｉに接続されている全オーディオクライアントＣｊのリストを表示する（Ｓ３００９１）。コントローラＡｋは、ユーザの操作に応じてリストの中から監視しようとするオーディオクライアントＣｊを選択する（Ｓ３００９２）。ユーザの操作に応じて監視しようとするオーディオクライアントＣｊを選択するのは本ネットワークオーディオシステムを最初に起動したときだけとし、２回目以降は、最初に選択したオーディオクライアントＣｊを登録しておき、その登録されたオーディオクライアントを自動的に選択するようにするのが好ましい。
続いて、コントローラＡｋは、その選択されたオーディオクライアントＣｊのクライアントインデックスをコンテンツサーバＳｉに送信し、その監視ハンドルを要求する（Ｓ３００９３）。コンテンツサーバＳｉは、送信元コントローラＡｋのクライアントインデックスと、受信したオーディオクライアントＣｊのクライアントインデックスとを対応づけて記憶し（Ｓ２０００１）、送信元コントローラＡｋに対して監視ハンドルを発行する（Ｓ２０００２）。その結果、コントローラＡｋは、選択されたオーディオクライアントＣｊの監視ハンドルを取得する（Ｓ３００９４）。
続いて、コントローラＡｋは、ユーザの操作に応じてリストの中から制御しようとするオーディオクライアントＣｊを選択する（Ｓ３００９５）。そして、コントローラＡｋは、その選択されたオーディオクライアントＣｊのクライアントインデックスをコンテンツサーバＳｉに送信し、その制御ハンドルを要求する（Ｓ３００９６）。コンテンツサーバＳｉは、送信元コントローラＡｋのクライアントインデックスと、受信したオーディオクライアントＣｊのクライアントインデックスとを対応づけて記憶し（Ｓ２０００３）、送信元コントローラＡｋに対して制御ハンドルを発行する（Ｓ２０００４）。その結果、コントローラＡｋは、選択されたオーディオクライアントＣｊの制御ハンドルを取得する（Ｓ３００９７）。
監視ハンドルは、コンテンツサーバＳｉからコントローラＡｋに与えられるオーディオクライアントＣｊを監視する権限である。これにより、オーディオクライアントＣｊのステータスが変化すると、変化後の新しいステータスがコンテンツサーバＳｉに通知される。コンテンツサーバＳｉはプッシュポートを通じてオーディオクライアントＣｊのクライアント情報をコントローラＡｋに随時送信し、これに応じてコントローラＡｋはオーディオクライアントＣｊのクライアント情報を更新する。
本ネットワーク型オーディオシステムでは、オーディオクライアントＣｊの数が多いほどＬＡＮ１２に負荷がかかる。また、コントローラＡｋのコマンドやオーディオクライアントＣｊのステータスなどの伝送はＬＡＮ１２上のトラフィックに影響を及ぼす。
図５３に示すように、複数のコントローラＡ１〜Ａ３が同じＬＡＮ１２上に存在する場合に、コンテンツサーバＳｉはオーディオクライアントＣ１〜Ｃ３のクライアント情報を全てのコントローラＡ１〜Ａ３に送信するようにすることも可能であるが、このようにすると、ネットワークトラフィック及びコンテンツサーバの負荷が増大する。
そこで図５４に示すように、コントローラＡ１がオーディオクライアントＣ１のみの監視ハンドルを取得し、コントローラＡ２がオーディオクライアントＣ２のみの監視ハンドルを取得するようにし、コンテンツサーバＳｉは、オーディオクライアントＣ１のクライアント情報をコントローラＡ１のみに送信し、オーディオクライアントＣ２のクライアント情報をコントローラＡ２のみに送信するようにする。
コンテンツサーバＳｉは、オーディオクライアントＣｊの監視ハンドルを取得しているコントローラＡｋだけにクライアント情報を送信するので、ネットワークトラフィック及びコンテンツサーバの負荷が軽減される。ただし、コントローラＡ３が全てのオーディオクライアントＣ１〜Ｃ３の監視ハンドルを取得し、コンテンツサーバＳｉが全てのコントローラＡ１〜Ａ３にクライアント情報を送信するようにしてもよい。
一方、制御ハンドルは、コンテンツサーバＳｉからコントローラＡｋに与えられるオーディオクライアントＣｊを制御する権限である。
本ネットワーク型オーディオシステムにおいて、コントローラＡｋが複数存在する場合、いずれのコントローラＡｋもオーディオクライアントＣｊを制御できるようにすると、あるコントローラＡｋからの命令に従ってオーディオクライアントＣｊが曲を再生している最中に、他のコントローラＡｋがそのオーディオクライアントＣｊに再生の停止を命令したり、別の曲の再生を命令するおそれがある。
そこで、本システムでは、オーディオクライアントＣｊの制御ハンドルを取得しているコントローラＡｋのみがそのオーディオクライアントＣｊを制御することができ、オーディオクライアントＣｊの制御ハンドルを取得していないコントローラＡｋはそのオーディオクライアントＣｊを制御することができないようにする。
コンテンツサーバが制御ハンドルを取得できるコントローラを制限すれば、オーディオクライアントとそれを制御できるコントローラの組み合わせを設定することができる。また、コントローラが制御ハンドル開放コマンドをコンテンツサーバに発行することにより、制御ハンドルを放棄できるようにする。
１．２．３．２．モニタ（監視）機能
コントローラＡｋは、上述したように監視ハンドルを取得することにより、オーディオクライアントＣｊを監視できるようになる。
図５５を参照して、コントローラＡｋはコンテンツサーバＳｉにクライアント情報を要求し（Ｓ３１）、コンテンツサーバＳｉはこれに応じてクライアント情報を返信し（Ｓ２７）、コントローラＡｋはこれを取得して記憶する（Ｓ３１）。又は、コンテンツサーバＳｉがオーディオクライアントＣｊからクライアント情報を受信した場合、コンテンツサーバＳｉはコントローラＡｋにプッシュポートにてクライアント情報を送信し、コントローラＡｋはこれを取得して記憶する。そして、コントローラＡｋは取得したクライアント情報を表示する（Ｓ３２）。以下、このコントローラによるモニタ機能を詳細に説明する。
図５６を参照して、コンテンツサーバＳｉはコントローラＡｋからの要求又はオーディオクライアントからのクライアント情報の受信に応じてクライアント情報を送信する（Ｓ２７０１）。コントローラＡｋはこのクライアント情報を受信すると、各情報に変更がないかを調べる。すなわち、最初にクライアントインデックスを確認し（Ｓ３１０１）、どのオーディオクライアントＣｊのクライアント情報かを記憶しておく。そして、記憶したオーディオクライアントのプロダクトＩＤ及びファームウェアＩＤを確認する（Ｓ３１０２、Ｓ３１０３）。
具体的には、プロダクトＩＤによってオーディオクライアントの種類を判別し、ファームウェアＩＤによってファームウェアのバージョンを判別する。もしそのオーディオクライアントに適用されているファームウェアのバージョンが古ければ、コントローラＡｋはインターネット上のカスタマーサービスにアクセスし、オーディオクライアントＣｊにファームウェアを配信して自動的に更新する。ファームウェア更新の詳細は後述する。
なお、コントローラＡｋは、受信したクライアント情報を解析してクライアントタイプを確認し、オーディオクライアントＣｊならそれ用の処理に分岐し、それ以外なら無視するようにする。
続いて、コントローラＡｋは、接続情報に変更がないかをチェックし（Ｓ３１０４）、変更があればオーディオクライアントＣｊの接続状態の表示を変更する（Ｓ３１０５）。
したがって、複数のオーディオクライアントＣｊに電源が入り、それらがコンテンツサーバＳｉに接続されているか否かをコントローラＡｋで常に監視することができる。
オーディオクライアントＣｊが接続されていたら、コントローラＡｋは、ボリューム値に変更がないかをチェックし（Ｓ３１０６）、変更があればボリューム値の表示を変更する（Ｓ３１０７）。
続いて、コントローラＡｋは、リスト構築キー（後述する）に変更がないかをチェックし（Ｓ３１０８）、変更があればリスト構築キーを用いてコンテンツサーバＳｉに曲リストを要求する（Ｓ３１０９）。コンテンツサーバＳｉはこの要求に応じて曲リストを返信し（Ｓ２７０２）、コントローラＡｋはこの曲リストを受信する（Ｓ３１１０）。
コントローラＡｋは、受信した曲リストをオーディオクライアントＣｊが再生中の曲リストとして記憶するとともに、現在再生中の曲が曲リストの何曲目かを調べてその番号を記憶する（Ｓ３１１１）。
続いて、コントローラＡｋは、再生中の曲に変更がないかをチェックし（Ｓ３１１２）、変更があれば曲のデータフォーマットを確認し（Ｓ３１１３）、再生中の曲名やアーティスト名の表示を変更し（Ｓ３１１４）、現在再生中の曲が曲リストの何曲目かを調べてその番号を記憶する（Ｓ３１１５）。
最後に、コントローラＡｋは、ステータスに変更がないかをチェックし（Ｓ３１１６）、変更があればステータスの表示を変更する（Ｓ３１１７）。オーディオクライアントＣｊがリモコンにより制御される場合も、コントローラＡｋはそのステータスを監視して表示する。オーディオクライアントＣｊのステータスが完了ステータスであれば（Ｓ３１１８）、コントローラＡｋはオーディオクライアントＣｊにその次の曲を続けて再生するよう命令する（Ｓ３１１９）。連続再生の詳細は後述する。
以上の処理は、コントローラが監視ハンドルを取得した全てのオーディオクライアントのうちいずれかのクライアント情報が変化するたびに繰り返される。
また、図示されていないが、コントローラＡｋは、各オーディオクライアントＣｊのクライアントタイプを監視する。また、コントローラＡｋは、再生可能なデータフォーマットを監視し、再生可能な曲名のみを表示する。
以上のように、コンテンツサーバがクライアントからクライアント情報を受信した際に、プッシュポートにて強制的にコントローラにクライアント情報を送信することにより、コントローラＡｋはオーディオクライアントＣｊを常に監視することができ、また、コンテンツサーバＳｉからコントローラＣＬには必要最低限の情報しか送信されない。そのため、コントローラＡｋにかかる処理の負担が軽減される。また、オーディオクライアントＣｊが複数あっても、コントローラＡｋはクライアントインデックスによりオーディオクライアントＣｊを区別し、各クライアント情報をリアルタイムで更新することができる。
１．２．３．３．制御機能
コントローラＡｋは、上述したように制御ハンドルを取得することにより、オーディオクライアントＣｊを制御できるようになる。
図５７を参照して、コントローラＡｋは制御コマンドをコンテンツサーバＳｉに送信し（Ｓ３３）、コンテンツサーバＳｉはこれを指定されたオーディオクライアントＣｊに送信する（Ｓ２８）。オーディオクライアントＣｊはこの制御コマンドに従って動作し、そのステータスを変更し（Ｓ１８）、その変更したステータスをコンテンツサーバＳｉに送信する（Ｓ１９）。コンテンツサーバＳｉはこのステータスをコントローラＡｋに送信し（Ｓ２９）、コントローラＡｋはこれに応じて記憶しているクライアント情報のステータスを変更する（Ｓ３４）。
１．２．３．３．１．制御コマンド処理
次に、図５８を参照して、オーディオクライアントＣｊがコントローラＡｋからコンテンツサーバＳｉを通じて受けた制御コマンドに従って行う処理を説明する。
オーディオクライアントＣｊは、プッシュポートに何らかのデータが書き込まれた場合（Ｓ３００１）、そのデータを受信して解析する（Ｓ３００２）。
受信したデータが再生コマンドであれば（Ｓ３００３）、オーディオクライアントＣｊは指定されたファイル名をコンテンツサーバＳｉから取得する（Ｓ３００４）。オーディオクライアントＣｊは、取得したファイル名から、曲名、アルバム、ジャンルなどを特定する。そして、オーディオクライアントＣｊは曲を指定しかつその曲の音楽データを転送するようコンテンツサーバＳｉに指令する（Ｓ３００５）。オーディオクライアントＣｊは転送された音楽データに基づいて再生を行う。
受信したデータが再生停止コマンドであれば（Ｓ３００６）、オーディオクライアントＣｊは曲データ転送要求コマンドの発行を停止することにより音楽データの転送を停止し（Ｓ３００７）、停止ステータスをコンテンツサーバＳｉに送信する（Ｓ３００８）。オーディオクライアントＣｊは、その他、ボリューム値セットコマンド、ポーズコマンド、ＡＶレシーバ制御コマンド、ファームウェアアップデートコマンドなどに応答して、所定の処理を行う（Ｓ３００９〜Ｓ３０１０）。
１．２．３．３．２．再生制御
ここで、コントローラＡｋが再生コマンドに従ってオーディオクライアントＣｊに所望のアーティストの所望の曲を再生させる動作を説明する。
図５９を参照して、コントローラＡｋはオーディオクライアントＣｊの接続を確認し（Ｓ３０１１）、接続があればオーディオクライアントＣｊのファームウェアＩＤ及びプロダクトＩＤを確認する（Ｓ３０１２、Ｓ３０１３）。
続いて、コントローラＡｋは、クライアントタイプに基づいてオーディオクライアントＣｊがオーディオクライアント又はＡＶＲクライアントであるか否かを判別する（Ｓ３０１４）。ここではオーディオクライアントＣｊであるから、コントローラＡｋは所望のアーティストの曲リストを既に取得しているか否かを判別する（Ｓ３０１５）。未だ取得していなければ、コントローラＡｋはコンテンツサーバＳｉから所望のアーティストの曲リストを取得する（Ｓ３０１６）。コントローラＡｋは、この曲リストを表示装置に表示する。
取得された曲リストの中にユーザが再生を希望する曲があれば（Ｓ３０１７）、コントローラＡｋは、ユーザの入力操作に応じてその曲を選択し、再生コマンドをコンテンツサーバＳｉに送信する（Ｓ３０１８）。この再生コマンドは、選択された曲のデータを格納しているファイル名と、曲を再生させようとするオーディオクライアントのクライアントインデックスとを含む。一方、希望する曲がなければ、コントローラＡｋは再び所望のアーティストの次の曲リストを取得する（Ｓ３０１６）。
コンテンツサーバＳｉは、コントローラＡｋから送信されたクライアントインデックスに基づいてオーディオクライアントＣｊを特定し、そのオーディオクライアントＣｊに選択された曲のファイル名を送信する（Ｓ２８）。
オーディオクライアントＣｊは、コントローラＡｋからコンテンツサーバＳｉを通じて送信されてきた再生コマンドに応答して所望の曲を再生し、ステータスを再生ステータスに変更する（Ｓ１８）。オーディオクライアントＣｊは再生ステータスをコンテンツサーバＳｉに送信し（Ｓ１９）、コンテンツサーバＳｉはその再生ステータスをコントローラＡｋに送信する（Ｓ２９）。コントローラＡｋはこれに応じてオーディオクライアントＣｊのステータスを再生ステータスに変更する（Ｓ３４）。
１．２．３．３．３．再生可能なフォーマットかを識別して再生
曲リストには、オーディオクライアントＣｊが再生可能なフォーマットか否かに関係なく、全てのフォーマットの曲が含まれる。そのため、ユーザが所望の曲を選択したときにコントローラＡｋがコンテンツサーバＳｉから取得した曲リストをそのままユーザに対して表示したとすると、次のような問題が生じる。
すなわち、ユーザがオーディオクライアントＣｊが再生できないフォーマットの曲を選択した場合でも、コントローラＡｋはユーザが選択した曲の再生をオーディオクライアントＣｊに命令するので、オーディオクライアントＣｊでは表示は再生状態になっているのに再生音は出ない。
そこで図６０に示すように、クライアント情報のクライアントタイプに再生可能なフォーマットに関する情報を追加する。よって、クライアントタイプは、クライアントのハードウェア構成に関する情報と、オーディオクライアントが再生可能なフォーマットに関する情報とから構成される。
ハードウェア構成に関する情報には、次のようなものがある。「オーディオクライアント(インテリジェントタイプ)」は、音楽を再生しかつリモコン信号を受信できるオーディオクライアントである。「オーディオクライアント(ノンインテリジェントタイプ)」は、音楽を再生できるが、リモコン信号を受信できないオーディオクライアントである。「コントローラ」は、コンテンツサーバを介してオーディオクライアントを監視しかつ制御できるクライアントである。「ＡＶＲクライアント」は、ＥＩＡ−２３２ポートを持ち、ＡＶレシーバと通信できるクライアントである。「ＡＶＲコントローラ」は、コンテンツサーバを介してＡＶＲクライアントを制御しかつ監視できるクライアントである。再生可能なフォーマットに関する情報には、ＭＰ３、ＷＡＶ、ＷＭＡなどがある。
１つのクライアントのクライアントタイプに、複数のハードウェア構成に関する情報が含まれている場合もあり、また、複数の再生可能なフォーマットに関する情報が含まれている場合もある。
次に、コントローラＡｋがユーザに対して曲リストを表示するときの処理手順を図６１を参照して説明する。
まずコントローラＡｋは、曲を再生させようとするオーディオクライアントＣｊがコンテンツサーバＳｉに接続されているか否かを判別する（Ｓ３５０１）。未接続の場合、オーディオクライアントＣｊは曲を再生できないので、曲リストの全ての曲を再生不可能な曲として表示するか、又は全ての曲を表示しない（Ｓ３５０２）。したがって、オーディオクライアントＣｊが再生不可能な曲をユーザが選択するのを防止することができる。
一方、既接続の場合、以下のステップＳ３５０５〜Ｓ３５０７を曲リストの曲数分繰り返す（Ｓ３５０３，Ｓ３５０４，Ｓ３５０８）。
すなわち、コントローラＡｋは、曲リスト中のｎ番目の曲のフォーマットがオーディオクライアントＣｊが再生可能なフォーマットか否かを判別する（Ｓ３５０５）。再生可能なフォーマットであれば、コントローラＡｋはその曲を再生可能な曲として表示し（Ｓ３５０６）、再生不可能なフォーマットであれば、再生不可能な曲として表示するか、又は表示しない（Ｓ３５０７）。
たとえばオーディオクライアントＣ１がＭＰ３もＷＡＶも再生できる場合、コントローラＡｋは、図６２に示すように、曲リスト（この例ではプレイリスト）中の全ての曲を表示する。しかし、オーディオクライアントＣ２がＭＰ３は再生できるが、ＷＡＶは再生できない場合は、図６３に示すように、曲リスト中のＭＰ３の曲は通常通り表示するが、ＷＡＶの曲は淡く表示する。また、曲を淡く表示するのではなく、全く表示しないようにしてもよい。したがって、オーディオクライアントＣ２が再生不可能なＷＡＶの曲をユーザが選択するのを防止することができる。
なお、オーディオクライアントＣｊの接続状態やクライアントタイプに変更があった場合、コントローラＡｋは曲リストを表示し直し、現在のオーディオクライアントのクライアント情報をリアルタイムで表示する。
次に、ユーザがコントローラＡｋを操作してオーディオクライアントＣｊに曲を再生させる場合のコントローラの動作を説明する。
図６４を参照して、ユーザが再生したい曲を選択すると、コントローラＡｋはその選択された曲のフォーマットがオーディオクライアントＣｊが再生可能なフォーマットか否かを判別する（Ｓ３５１１）。具体的には、コントローラＡｋは、その選択された曲のフォーマットをクライアントタイプ中の再生可能なフォーマットと比較する。
再生可能なフォーマットであれば、コントローラＡｋは、その選択された曲を再生するようオーディオクライアントＣｊに命令する（Ｓ３５１２）。一方、再生不可能なフォーマットであれば、オーディオクライアントＣｊはその選択された曲を再生できない旨をユーザに知らせる（Ｓ３５１３）。
以上のように、コントローラＡｋは、オーディオクライアントＣｊが再生できる曲がユーザにわかるように表示し、これにより、オーディオクライアントＣｊが再生できない曲の再生をユーザが要求しないようにすることができる。
１．２．３．３．４．連続再生制御
ユーザがオーディオクライアントＣｊを操作してそのオーディオクライアントＣｊで曲を再生している場合は、オーディオクライアントＣｊは曲リストを取得しているから、その曲リスト中の曲を連続して再生することが可能である。しかし、オーディオクライアントＣｊがコントローラＡｋにより指示された曲を再生している場合は、オーディオクライアントＣｊ自身は曲リストを取得していないから、オーディオクライアントＣｊが曲リスト中の曲を連続して再生するためには、コントローラＡｋがオーディオクライアントＣｊに次の曲を指示する必要がある。
また、ネットワーク上にコントローラが１つしか存在しない場合は問題とならないが、複数存在する場合は、オーディオクライアントが正常に連続再生を行うことができないという問題が生じる。たとえばオーディオクライアントから再生の完了を通知されたコンテンツサーバが全てのコントローラに再生の完了を通知したとすると、オーディオクライアントは複数のコントローラから連続再生の命令を受けてしまうからである。この問題はネットワーク上にコンテンツサーバが複数存在する場合はさらに複雑になる。したがって、ネットワーク型オーディオシステムにおいてコントローラによる連続再生を可能にするためには、どのコントローラがクライアントに連続再生を命令するのかを管理する必要がある。
本実施の形態では、オーディオクライアントＣｊは、コントローラＡｋからの命令に従って曲を再生し、その再生を終了したときは完了ステータスを送信するが、それ以外のとき、たとえばユーザの操作に応じてオーディオクライアントＣｊが自ら曲を再生し、その再生を終了したとき、又はユーザの操作に応じてオーディオクライアントＣｊが曲の再生を途中で停止したときなどは、完了ステータスとは異なる停止ステータスを送信する。コントローラは、完了ステータスを受信した場合に、連続再生処理すべきと判断し、曲リストの中から前に選択した曲の次の曲を選択し、オーディオクライアントに次の曲を再生するよう命令する。また、コントローラは、停止ステータスを受信した場合には、オーディオクライアントに次の曲を再生するよう命令しない。以上のように、オーディオクライントが状況に応じて完了ステータスと停止ステータスとを区別して送信することにより、コントローラは受信したステータスに基づいて、オーディオクライアントに次の曲の再生を命令すべきか否かを判断することができる。
したがって、オーディオクライアントＣｊがユーザの操作に応じて曲の再生を途中で停止した場合又はオーディオクライアントＣｊが自ら曲を選択し、その再生を終了した場合には、停止ステータスをコンテンツサーバに送信するので、コントローラが誤ってオーディオクライアントに次の曲を再生するよう命令することを防止できる。
さらにコントローラが複数ある場合には、オーディオクライアントから完了ステータスを受信したコンテンツサーバは、各コントローラに対して、完了ステータスと停止ステータスとを区別して送信する。すなわち、図６５を参照して、コントローラＡ１がオーディオクライアントＣ１に再生を命令する場合、コントローラＡ１はまずコンテンツサーバＳｉにオーディオクライアントＣ１に対する再生コマンドを送信する。コンテンツサーバＳｉはコントローラＡ１から再生コマンドを受信し、これをオーディオクライアントＣ１に送信する。オーディオクライアントＣ１はコンテンツサーバＳｉから再生コマンドを受信し、曲の再生を開始する。
図６６及び図６７を参照して、オーディオクライアントＣ１が曲の再生を終了すると、完了ステータスをコンテンツサーバに送信し（Ｓ１９０１）、コンテンツサーバＳｉはこれを受信する（Ｓ２９０１）。続いて、コンテンツサーバＳｉは、以下のステップＳ２９０３〜Ｓ２９０６をクライアント数だけ繰り返す（Ｓ２９０２，Ｓ２９０７）。
コンテンツサーバＳｉは、クライアントインデックスｎに基づいてｎ番目のクライアントがオーディオクライアントＣ１の監視ハンドルを取得しているコントローラか否かを判別する（Ｓ２９０３）。
監視ハンドルを取得しているコントローラの場合、コンテンツサーバＳｉは、ｎ番目のクライアント（コントローラ）がオーディオクライアントＣ１に再生を命令したコントローラＡ１か否かを判別する（Ｓ２９０４）。
オーディオクライアントＣ１に再生を命令したコントローラＡ１の場合、コンテンツサーバＳｉは、オーディオクライアントＣ１から受信した完了ステータスをコントローラＡ１に送信し（Ｓ２９０５）、コントローラＡ１はこれを受信する（Ｓ３４０１）。一方、オーディオクライアントＣ１に再生を命令したコントローラＡ１以外のコントローラＡ２の場合、コンテンツサーバＳｉは、オーディオクライアントＣ１から受信した完了ステータスに代えて、停止ステータスをコントローラＡ２に送信し（Ｓ２９０６）、コントローラＡ２はこれを受信する（Ｓ３４０２）。
図６８を参照して、完了ステータスを受信したコントローラＡ１は、曲リストの中から前に選択した曲の次の曲を選択し、その曲をオーディオクライアントＣ１に再生させるための再生コマンドをコンテンツサーバＳｉに送信する（Ｓ３４０３）。コンテンツサーバＳｉはこれを受信し、オーディオクライアントＣ１に送信する。オーディオクライアントＣ１は、コンテンツサーバＳｉから送信された再生コマンドに従って次の曲を再生する。
一方、停止ステータスを受信したコントローラＡ２は、オーディオクライアントＣ１は停止状態にあると判断し、コントローラＡ１のような連続再生処理を行わない。
オーディオクライアントＣｊは、ステータスが再生になると再生ステータスをコンテンツサーバＳｉに送信し、ステータスが一時停止になるとポーズステータスをコンテンツサーバＳｉに送信し、自らが指定した曲の再生が終了すると停止ステータスをコンテンツサーバＳｉに送信するが、上述したように、コントローラＡｋが指定した曲の再生が終了すると完了ステータスをコンテンツサーバＳｉに送信する。
以上のように、オーディオクライアントＣｊが曲の再生を終了したときにコンテンツサーバＳｉがコントローラＡｋに送信するステータスを停止ステータスと完了ステータスとに区別することにより、コントローラＡｋは自ら再生を命令したオーディオクライアントＣｊが曲の再生を終了したのか否かを判断することができる。その結果、コントローラＡｋはオーディオクライアントＣｊに連続再生を命令する必要があるのか、オーディオクライアントＣｊの停止ステータスを表示するだけでいいのかを判断することができる。
なお、オーディオクライアントＣｊが曲の再生を終了したとき、専用リモコンからの命令に従って曲を再生していた場合と、監視ハンドル及び制御ハンドルの両方を取得しているコントローラＡｋからの命令に従って曲を再生していた場合とで、コンテンツサーバＳｉに通知するステータスを区別するようにしてもよい。制御ハンドルしか取得していない専用リモコンはコンテンツサーバＳｉからステータスを受信することができないから、連続再生処理を行うことができないからである。
１．２．３．３．５．リスト構築キーを用いた連続再生制御
コントローラＡｋは、コンテンツサーバＳｉからさまざまな曲リストを取得してその中から曲を選択し、その曲をオーディオクライアントＣｊに再生させる。そして、コントローラＡｋは、オーディオクライアントＣｊのステータスを監視し、オーディオクライアントＣｊが選択された曲の再生を終了すると、取得している曲リストの中から次の曲を選択し、その曲をオーディオクライアントＣｊに再生させる。コントローラＡｋはこのようにしてオーディオクライアントＣｊに連続的に曲を再生させているが、次の曲の再生を命令するためには曲リストを記憶しておく必要がある。そのため、曲の再生を命令しているコントローラＡｋの電源は曲の再生中に切ることができない。
そこで、オーディオクライアントＣｊに再生を命令したコントローラＡｋの電源を途中で切っても、コントローラＡｋがオーディオクライアントＣｊに連続再生を命令できるように、以下のような方法を採用する。
ユーザがコンテンツ情報データベースの中から再生したい曲を選択するときには、あるアーティストの曲リストから選択したり、あるジャンルの曲リストから選択するなど、さまざまな曲リストを利用する。そこで、コンテンツ情報データベースから一意に曲リストを作成することができるように、リスト構築キーを定義する。そして、このリスト構築キーを、オーディオクライアントＣｊが再生中の曲リストを特定するための情報としてクライアント情報に付加する。
図６９を参照して、リスト構築キーは「フィルタの種類」と「キーワード」とから構成される。フィルタの種類は、コンテンツ情報データベース中のどのカテゴリに注目して曲リストを作成するかを指定するもので、図７０に示すようなものがある。フィルタの種類が"ＴＩＴＬＥ＝"、"ＧＥＮＲＥ＝"、"ＡＲＴＩＳＴ＝"、"ＡＬＢＵＭ＝"、又は"ＦＩＬＥＮＡＭＥ＝"であれば、コンテンツ情報データベースの中から、曲名、ジャンル名、アーティスト名、アルバム名、又はファイル名がキーワードと一致する曲を探し出して曲リストを作成する。フィルタの種類が"ＰＬＡＹＬＩＳＴ＝"であれば、プレイリストのファイル名がキーワードと一致するプレイリストに登録されている曲をコンテンツ情報データベースから探し出して曲リストを作成する。
たとえば、アーティスト名"ｘｘｘｘ"の曲リストの場合、フィルタの種類は"ＡＲＴＩＳＴ＝"、キーワードは"ｘｘｘｘ"となるから、リスト構築キーは"ＡＲＴＩＳＴ＝ｘｘｘｘ"となる。また、キーワードとして"＊"(アスタリスク)を指定すると、そのフィルタの種類に対して使用できるキーワードのリストが作成される。たとえばリスト構築キー"ＡＲＴＩＳＴ＝＊"から作成されるリストは、コンテンツ情報データベースに登録されている曲のアーティスト名のリストが作成される。
以下にコントローラが指定した曲の再生が終了したオーディオクライアントに対して、コントローラが連続再生処理を行う手順について説明する。
図７１を参照して、コントローラＡｋから再生するよう命令されたオーディオクライアントＣｊが曲の再生を終了すると、完了ステータスをコンテンツサーバＳｉに送信する。コンテンツサーバＳｉは、オーディオクライアントＣｊのステータスが変化したので、完了ステータス、再生していた曲のファイル名、リスト構築キーなどを含むクライアント情報をコントローラＡｋに送信する。
コントローラＡｋはクライアント情報を受信すると、図５６に示したクライアント情報表示処理を開始する。この処理は既に説明したので、ここでは主としてリスト構築キーを用いた連続再生制御に関する部分を説明する。
コントローラＡｋは、リスト構築キーに変更がないかチェックし（Ｓ３１０８）、変更があった場合はリスト構築キーを用いてオーディオクライアントＣｊが再生中の曲リストをコンテンツサーバＳｉから取得する（Ｓ３１１０）。詳細には、受信したリスト構築キーをコンテンツサーバに送信し、コンテンツサーバはこのリスト構築キーに基づいてリストを作成し、コントローラに送信する。電源が切られ、コントローラＡｋがオーディオクライアントＣｊが再生中の曲リストを記憶していない場合も、コンテンツサーバと接続した後に取得するリスト構築キーを用いて再生中の曲リストをコンテンツサーバＳｉから取得する。
ここでは、ステータスが完了ステータスに変化しているから、コントローラＡｋは完了処理を行う（Ｓ３１１９）。すなわち、コントローラＡｋは、オーディオクライアントＣｊが再生を終了した曲の次の曲を曲リストから選択し、その選択した曲を再生するようオーディオクライアントＣｊに命令する。
図７２を参照して、完了処理の詳細を説明する。コントローラＡｋは、図５６中のステップＳ３１１１で記憶した再生曲番号ｎをインクリメントし（Ｓ３１１９１）、次に再生すべき曲を指定する。続いて、コントローラＡｋは、再生曲番号ｎが曲リストの曲数以下か否かを判別する（Ｓ３１１９２）。再生曲番号ｎが曲リストの曲数を超えていれば、コントローラＡｋは、オーディオクライアントＣｊが曲リストの最後まで再生したと判断して再生曲番号ｎを１に設定し（Ｓ３１１９３）、次に再生すべき曲を曲リストの最初の曲に戻す。
再生曲番号ｎが曲リストの曲数以下であれば、コントローラＡｋは、ｎ番目の曲がオーディオクライアントＣｊで再生可能なフォーマットか否かをチェックし（Ｓ３１１９４）、再生可能なフォーマットであれば、曲リストのｎ番目の曲を再生するようオーディオクライアントＣｊに命令する（Ｓ３１１９５）。再生不可能なフォーマットであれば、さらに次の曲を再生するために再帰的にこの完了処理を行う。要するに、コントローラＡｋは、オーディオクライアントＣｊが再生不可能なフォーマットの曲を飛ばし、その次の曲を再生するようオーディオクライアントＣｊに命令する。
以上のように、オーディオクライアントＣｊに曲を再生するよう命令した後にコントローラＡｋの電源を切ると、コントローラＡｋはオーディオクライアントＣｊに再生を命令したときの曲リストを消失してしまう。しかし、電源を再投入し、コンテンツサーバとの接続が完了すると、図５１のＳ３００８にて説明した通り、コントローラＡｋはコンテンツサーバＳｉからオーディオクライアントＣｊのクライアント情報を取得する。このクライアント情報にはリスト構築キーが含まれているから、コントローラＡｋはこのリスト構築キーに基づいてクライアントＣＬが再生中の曲リストを再び取得することができる。したがって、コントローラＡｋがオーディオクライアントＣｊに曲を再生するよう命令した後にその電源が切られた場合であっても、オーディオクライアントＣｊが曲の再生を終了し、完了ステータスを送信し、この完了ステータスをコントローラＡｋが受信したときには、取得し直した曲リストに従ってその次の曲を再生するようオーディオクライアントＣｊに命じることができる。
なお、オーディオクライアントＣｊの再生動作を停止させるためには、コントローラＡｋは停止コマンドをコンテンツサーバＳｉを通じてオーディオクライアントＣｊに送信すればよい。この場合、停止ステータスがオーディオクライアントＣｊからコンテンツサーバＳｉを通じてコントローラＡｋに返信される。また、オーディオクライアントＣｊの再生動作を一時停止させるためには、コントローラＡｋは一時停止コマンドをコンテンツサーバＳｉを通じてオーディオクライアントＣｊに送信すればよい。この場合、ポーズステータスがオーディオクライアントＣｊからコンテンツサーバＳｉを通じてコントローラＡｋに返信される。
１．２．３．３．６．優先順位を付けた連続再生制御
本実施の形態をコンテンツサーバＳ１及びオーディオクライアントＣ１に着目して説明する。本実施の形態では、コンテンツサーバＳ１のＨＤＤ１４にコントローラ管理テーブルが格納されている。コントローラ管理テーブルの一例を次の表１に示す。コントローラ管理テーブルには、オーディオクライアントＣ１を制御する優先順位と、コントローラＡ１〜Ａｋに付与されたコントローラインデックスとが対応づけて記録される。
Figure 0004013942
本実施の形態では、コンテンツサーバＳ１〜Ｓｉ、オーディオクライアントＣ１〜Ｃｊ及びコントローラＡ１〜Ａｋには、図７３に示したステップを実行するためのコンピュータプログラムがそれぞれインストールされている。以下、本実施の形態によるネットワーク型オーディオシステム１０の動作を図７３に示したフロー図を参照して説明する。
最初に、コントローラＡ１がコンテンツサーバＳ１に接続を要求し、コンテンツサーバＳ１がこの要求を受け入れると、コントローラＡ１とコンテンツサーバＳ１との間で接続が確立する（Ｓ３０３０１）。
コントローラＡ１に続いて、コントローラＡ２がコンテンツサーバＳ１に接続を要求し、コンテンツサーバＳ１がこの要求を受け入れると、コントローラＡ２とコンテンツサーバＳ１との間で接続が確立する（Ｓ３０４０１）。
これに対し、コンテンツサーバＳ１は、コントローラ管理テーブルに、優先順位「第１位」に対応づけてコントローラＡ１のコントローラインデックスを記録し、さらに優先順位「第２位」に対応づけてコントローラＡ２のコントローラインデックスを記録する（Ｓ２０１０１）。その結果、上記表１に示したコントローラ管理テーブルが得られる。このコントローラ管理テーブルによれば、コントローラＡ１が最優先で連続再生処理の権限を有し、その次にコントローラＡ２が連続再生処理の権限を有する。
以下、コントローラＡ１がコンテンツサーバＳ１経由でオーディオクライアントＣ１に複数曲の連続再生を命令する場合の動作を説明する。
コントローラＡ１は、連続再生の対象となる曲リストをコンテンツサーバＳ１に要求する（Ｓ３０３０２）。具体的には、曲リストを作成するために必要なリスト構築キーをコンテンツサーバＳ１に送信する。
ユーザは、コンテンツサーバＳ１の中から再生したい曲を選択するとき、あるアーティストの曲リストから選択したり、あるジャンルの曲リストから選択したりするなど、さまざまな曲リストを利用する。リスト構築キーは、このような曲リストをコンテンツサーバＳ１の中から抽出して一意に作成するための検索キーでる。リスト構築キーは図６９に示したように、フィルタの種類及びキーワードという２つのパラメータから構成される。
フィルタの種類は、曲リストに入れるべき曲のカテゴリを指定するもので、具体的には図７０に示したとおりである。
コンテンツサーバＳ１は、コントローラＡ１から送信されたリスト構築キーに基づいて曲リストを作成し、コントローラＡ１に送信する（Ｓ２０１０２）。具体的には、フィルタの種類が"ＴＩＴＬＥ＝"、"ＧＥＮＲＥ＝"、"ＡＲＴＩＳＴ＝"、"ＡＬＢＵＭ＝"、又は"ＦＩＬＥＮＡＭＥ＝"であれば、曲名、ジャンル名、アーティスト名、アルバム名、又はファイル名がキーワードと一致する１又は２以上の曲を探し出し、その曲を列挙した曲リストを作成する。フィルタの種類が"ＰＬＡＹＬＩＳＴ＝"であれば、プレイリストのファイル名がキーワードと一致するプレイリストに登録されている曲を探し出し、その曲を列挙した曲リスト（プレイリスト）を作成する。また、コンテンツサーバＳ１は、オーディオクライアントＣ１のクライアント情報の１つとして、リスト構築キーをクライアントインデックス（オーディオクライアントＣ１の識別情報）に対応づけて登録する。
コントローラＡ１は、取得した曲リストの中からユーザの操作に応じて指定された曲の再生をコンテンツサーバＳ１経由でオーディオクライアントＣ１に命令する（Ｓ３０３０３）。オーディオクライアントＣ１は、コントローラＡ１からの再生命令に応じて、指定された曲の音楽コンテンツをコンテンツサーバＳ１に要求する（Ｓ１０２０１）。コンテンツサーバＳ１は、オーディオクライアントＣ１から要求された音楽コンテンツをオーディオクライアントＣ１に配信する（Ｓ２０１０３）。オーディオクライアントＣ１は、コンテンツサーバＳ１から送信された音楽コンテンツに基づいて曲の再生を開始する（Ｓ１０２０２）。
オーディオクライアントＣ１は指定された曲を最後まで再生し終えると、その旨を示す完了ステータスをコンテンツサーバＳ１に送信する（Ｓ１０２０３）。コンテンツサーバＳ１はオーディオクライアントＣ１から完了ステータスを受信すると、図７４に示すように、コントローラ管理テーブル１０４を参照し、最高順位のコントローラＡ１に完了ステータスをそのまま転送し、それよりも下位のコントローラＡ２に完了ステータスと異なる停止ステータスを送信する（Ｓ２０１０４）。
コントローラＡ１は、図７４に示すように、曲リストに従って次の曲を連続して再生するようにコンテンツサーバＳ１経由でオーディオクライアントＣ１に命令する（Ｓ３０３０４）。オーディオクライアントＣ１は、コントローラＡ１からの連続再生命令に応じてその次の曲を再生する。以後、オーディオクライアントＣ１は上記ステップＳ２０１以降の動作を繰り返す。他方、コントローラＡ２は、コンテンツサーバＳ１から停止ステータスを受信しても特に能動的なアクションを起こさず、単にオーディオクライアントＣ１の状態を監視する。
なお、コントローラＡ１〜ＡｋがコンテンツサーバＳ１から切断されると、コンテンツサーバＳ１はコントローラ管理テーブル１０４を更新する。具体的には、コンテンツサーバＳ１から切断されたコントローラのコントローラインデックスを削除し、それよりも下位のコントローラインデックスの優先順位を順次繰り上げる。たとえば図７５に示すように、優先順位が最高のコントローラＡ１がコンテンツサーバＳ１から切断されたときは、その次の優先順位のコントローラＡ２が繰り上がり、コントローラＡ１に代わって連続再生処理の権限を獲得する。
また、上述した例ではコントローラＡ１が最初に再生を命令し、再び同じコントローラＡ１が連続再生を命令しているが、コントローラＡ２が最初に再生を命令した場合であってもコントローラＡ１の優先順位が最高である限りコントローラＡ１が連続再生を命令する。この場合、コントローラＡ１はコンテンツサーバＳ１から完了ステータスを受信しても曲リストを有していないので、コンテンツサーバＳ１に登録されているオーディオクライアントＣ１のリスト構築キーを利用してコンテンツサーバＳ１から曲リストを取得し、これに従って次の曲を指定する。
また、曲リストに含まれる全ての曲が１つのコンテンツサーバＳ１に蓄積されているとは限らず、複数のコンテンツサーバＳ１，Ｓｉに分散して蓄積されている場合もある。この場合、オーディオクライアントＣ１はコンテンツサーバＳ１の曲を再生した後、引き続き別のコンテンツサーバＳｉの曲を再生する必要がある。そのため、コンテンツサーバＳ１の曲を再生し終えたオーディオクライアントＣ１はコンテンツサーバＳ１との接続を一旦解除し、コンテンツサーバＳｉに接続し直すというサーバ切換処理を行う。
コンテンツサーバＳｉに接続し直したオーディオクライアントＣ１は、コントローラＡ１からの再生命令に応じて、指定された曲の音楽コンテンツをコンテンツサーバＳｉに要求し、コンテンツサーバＳｉは要求された音楽コンテンツをオーディオクライアントＣ１に配信する。
オーディオクライアントＣ１はその曲を再生し終えると、完了ステータスをコンテンツサーバＳｉに送信する。コンテンツサーバＳｉは完了ステータスを受信すると、その内部にあるコントローラ管理テーブルを参照し、最高順位のコントローラに完了ステータスを転送し、それよりも下位のコントローラに停止ステータスを送信する。
ここで、コンテンツサーバＳｉにあるコントローラ管理テーブルはコンテンツサーバＳ１にあるコントローラ管理テーブルと同じであっても異なっていてもよい。複数のコンテンツサーバが同じコントローラ管理テーブルを使用するためには、たとえばあるコンテンツサーバがコントローラ管理テーブルの優先順位を決定し、そのコントローラ管理テーブルを他のコンテンツサーバに転送するようにすればよい。一方、複数のコンテンツサーバが異なるコントローラ管理テーブルを使用するためには、たとえば各コンテンツサーバが独自にコントローラ管理テーブルの優先順位を決定するようにすればよい。
以上のように本実施の形態によれば、コンテンツサーバＳ１がオーディオクライアントＣ１から完了ステータスを受信したとき、コントローラ管理テーブルを参照し、最優先のコントローラＡ１にのみ完了ステータスを送信し、他のコントローラＡ２には停止ステータスを送信しているため、最優先のコントローラＡ１のみが連続再生を命令し、他のコントローラＡ２が連続再生を命令することはない。したがって、連続再生命令の競合を排除し、正常に連続再生処理を実行することができる。
上記実施の形態では優先順位はコンテンツサーバＳ１との接続順で決定されているが、これに限定されることなく、たとえばオーディオクライアントＣ１に命令を出した順で決定されてもよい。また、コンテンツサーバは複数ある必要はなく、少なくとも１つあればよい。オーディオクライアントも複数ある必要はなく、少なくとも１つあればよい。
１．２．３．３．７．制御ハンドルを利用した連続再生制御
本実施の形態では、図７６に示したステップを実行するためのコンピュータプログラムがコンテンツサーバＳ１〜Ｓｉ、オーディオクライアントＣ１〜Ｃｊ及びコントローラＡ１〜Ａｋにそれぞれインストールされている。本実施の形態も上記実施の形態と同様に、複数のコントローラＡ１〜Ａｋを備えたネットワーク型オーディオシステムに適用可能で、コンテンツサーバ又はオーディオクライアントは少なくとも１つあればよい。
上記実施の形態と異なり本実施の形態では、コントローラＡ１〜Ａｋに制御ハンドル管理テーブルが格納されている。制御ハンドル管理テーブルの一例を次の表２に示す。制御ハンドル管理テーブルには、オーディオクライアントＣ１〜Ｃｊのクライアントインデックスと、オーディオクライアントＣ１〜Ｃｊの制御ハンドルを取得しているコントローラＡ１〜Ａｋのコントローラインデックスとが対応づけて記録される。制御ハンドルは、オーディオクライアントを制御する権限を示すものである。表２の例では、オーディオクライアントＣ１の制御ハンドルはコントローラＡ１により取得されているが、オーディオクライアントＣ２及びＣｊの制御ハンドルはいずれのコントローラにも取得されていない。
Figure 0004013942
以下、コンテンツサーバＳ１、オーディオクライアントＣ１及びコントローラＡ１に着目し、図７６に示したフロー図を参照して本実施の形態の動作を説明する。なお、図７６では上記第１の実施の形態で詳述した曲リストの取得ステップ（図７３中のＳ３０３０２，Ｓ２０１０２）は割愛されている。
コントローラＡ１は、オーディオクライアントＣ１に再生を命令する前に、オーディオクライアントＣ１を制御するために必要な制御ハンドルを取得する。具体的には、コントローラＡ１は制御ハンドル管理テーブルを参照し、オーディオクライアントＣ１の制御ハンドルがロックされているか否かを判断する（Ｓ３０３１１）。
オーディオクライアントＣ１の制御ハンドルが既に他のコントローラＡ２〜Ａｋのいずれかに取得されている場合、表２に示した制御ハンドル管理テーブルにおいて、オーディオクライアントＣ１のクライアントインデックスに対応して当該コントローラのコントローラインデックスが記録されている。このように制御ハンドルが既に取得されている状態を「制御ハンドルがロックされている」という。他方、オーディオクライアントＣ１の制御ハンドルが未だ他のコントローラＡ２〜Ａｋのいずれにも取得されていない場合、オーディオクライアントＣ１のクライアントインデックスに対応していずれのコントローラインデックスも記録されていない。このように制御ハンドルが未だ取得されていない状態を「制御ハンドルがロックされていない（アンロックされている）」という。たとえば表２に示した制御ハンドル管理テーブルでは、オーディオクライアントＣ２の制御ハンドルはロックされていない。
オーディオクライアントＣ１の制御ハンドルがロックされている場合、コントローラＡ１は制御ハンドルの取得に失敗する。他方、ロックされていない場合、コントローラＡ１はコンテンツサーバＳ１に制御ハンドルの取得を要求する（Ｓ３０３１２）。この要求に応じて、コンテンツサーバＳ１はコントローラＡ１に制御ハンドルの取得を許可する（Ｓ２０１１１）。これにより、コントローラＡ１は制御ハンドルを取得し、さらにこの制御ハンドルを他のコントローラＡ２〜Ａｋに取得されないようにロックする（Ｓ３０３１３）。具体的には、コントローラＡ１は制御ハンドル管理テーブルを更新し、これによりオーディオクライアントＣ１のクライアントインデックスに対応づけてコントローラＡ１のコントローラインデックスを記録する。コンテンツサーバＳ１は他のコントローラＡ２〜Ａｋの制御ハンドル管理テーブルもこれに同期するよう更新する。
制御ハンドルを取得したコントローラＡ１は、曲リストの中からユーザの操作に応じて指定された曲の再生をコンテンツサーバＳ１経由でオーディオクライアントＣ１に命令する（Ｓ３０３１４）。コンテンツサーバＳ１はこの再生命令をオーディオクライアントＣ１に転送する（Ｓ２０１１２）。オーディオクライアントＣ１はこの再生命令に応じて指定された曲の再生を開始する（Ｓ１０２１１）。
オーディクライアントＣ１はその曲を最後まで再生し終えると、図７７に示すように、完了ステータスをコンテンツサーバＳ１に送信する（Ｓ１０２１２）。コンテンツサーバＳ１はこの完了ステータスを全てのコントローラＡ１〜Ａｋに転送する（Ｓ２０１１３）。
コントローラＡ１は、自身が制御ハンドルを取得しているオーディオクライアントＣ１からの完了ステータスか否かを判断し（Ｓ３０３１５）、そうであれば連続再生処理を実行し（Ｓ３０３１６）、そうでなければ完了ステータスを無視し、単にオーディオクライアントＣ１の状態を監視する。本例では、コントローラＡ１はオーディオクライアントＣ１の制御ハンドルを取得しているから連続再生処理を実行し（Ｓ３０３１６）、曲リストに従って次の曲の再生を命令する（Ｓ３０３１４）。
一方、オーディオクライアントＣ１は、曲を最後まで再生することなく、曲の途中で再生を停止した場合、停止ステータスをコンテンツサーバＳ１に送信する（Ｓ１０２１３）。コンテンツサーバＳ１はこの停止ステータスを全てのコントローラＡ１〜Ａｋに転送する（Ｓ２０１１４）。
コントローラＡ１は、自身が制御ハンドルを取得しているオーディオクライアントＣ１からの停止ステータスか否かを判断し（Ｓ３０３１７）、そうであればオーディオクライアントＣ１の制御ハンドルを解除（アンロック）し（Ｓ３０３１８）、そうでなければ停止ステータスを無視する。
コントローラＡ１は上記のように自身が制御ハンドルを取得しているオーディオクライアントＣ１から停止ステータスを受信した場合のほか、コンテンツサーバＳ１から切断された場合にもその取得している制御ハンドルを解除する。オーディオクライアントＣ１の制御ハンドルが解除されると、コントローラＡ１〜Ａｋのいずれもこの制御ハンドルの取得が可能となる。
なお、曲リストに含まれる曲が複数のコンテンツサーバＳ１，Ｓｉに分散して蓄積されている場合、上記第１の実施の形態と同様に、オーディオクライアントＣ１は図７７に示すようにコンテンツサーバＳ１から別のコンテンツサーバＳｉに接続を切り換えることになる。コンテンツサーバＳｉはオーディオクライアントＣ１から完了ステータスを受信しても、オーディオクライアントＣ１がどのコントローラＡ１〜Ａｋから命令された曲を再生し終えたのか不明である。したがって、この場合もコンテンツサーバＳｉは全てのコントローラＡ１〜Ａｋに完了ステータスを転送するが、コントローラＡ１〜Ａｋは制御ハンドル管理テーブルを有しているため、自身が制御ハンドルを取得しているオーディオクライアントからの完了ステータスを受信したときのみ連続再生処理を実行する。本例では、コントローラＡ１がオーディオクライアントＣ１の制御ハンドルを取得しているから、このコントローラＡ１のみが連続再生処理を実行する。
以上のように本実施の形態によれば、コントローラＡ１〜Ａｋの各々が制御ハンドル管理テーブルを有しているため、オーディオクライアントＣ１から送信された完了ステータスをコンテンツサーバＳ１が全てのコントローラＡ１〜Ａｋに転送しても、コントローラＡ１〜Ａｋの各々は制御ハンドルを取得しているオーディオクライアントからの完了ステータスを受信したときのみ連続再生処理を実行する。したがって、連続再生命令の競合を排除し、正常に連続再生処理を実行することができる。
なお、本実施の形態では制御ハンドル管理テーブルはコントローラＡ１〜Ａｋに格納されているが、コンテンツサーバＳ１〜Ｓｉに格納されていてもよい。
また、制御ハンドルをロックするのではなく、最後に命令したコントローラが制御ハンドルを取得できるようにしても構わない。すなわち、あるコントローラＡ１があるクライアントＣ１の制御ハンドルを取得している際に、別のコントローラＡ２がクライアントＣ１に再生を命令した場合、コントローラＡ２が制御ハンドルを取得し、コントローラＡ１は制御ハンドルを失うようにしてもよい。
１．２．３．３．８．コンテンツサーバによる連続再生制御
最初に、コンテンツサーバ、オーディオクライアント及びコントローラをそれぞれ１つずつ備えた単純な例を図７８を参照して説明する。
上記実施の形態と同様に、コントローラＡ１は曲の再生をコンテンツサーバＳ１経由でオーディオクライアントＣ１に命令する。オーディオクライアントＣ１はこの命令に応じてその曲の音楽コンテンツをコンテンツサーバＳ１に要求し、コンテンツサーバＳ１はこの要求に応じてその音楽コンテンツをオーディオクライアントＣ１に配信する。オーディオクライアントＣ１は配信された音楽コンテンツに基づいて曲の再生を開始し、その曲を最後まで再生し終えると完了ステータスをコンテンツサーバＳ１に送信する。コンテンツサーバＳ１はこの完了ステータスを受信すると、上記実施の形態と異なり、次の曲の連続再生をオーディオクライアントＣ１に自ら命令するとともに、停止ステータスをコントローラＡ１に送信する。
以下、この詳細を図７９に示したフロー図を参照して説明する。本実施の形態では図７９に示したステップを実行するためのコンピュータプログラムがコンテンツサーバＳ１、オーディオクライアントＣ１及びコントローラＡ１にそれぞれインストールされている。図７９中のステップＳ３０３２３，Ｓ１０２２１，Ｓ２０１２３〜Ｓ２１１２５が図７３に示した実施の形態と異なるので、ここではこれらを中心に説明する。
コントローラＡ１は上記実施の形態と同様に曲の再生をオーディオクライアントＣ１に命令するが、上記実施の形態と異なり、さらにステップＳ３０３０２で曲リストを取得するために用いたリスト構築キーをオーディオクライアントＣ１に送信する（Ｓ３０３２３）。
オーディオクライアントＣ１は上記第１の実施の形態と同様に指定された曲の音楽コンテンツをコンテンツサーバＳ１に要求し、コントローラＡ１から送信されたリスト構築キーをコンテンツサーバＳ１に転送する（Ｓ１０２２１）。
コンテンツサーバＳ１は上記実施の形態と同様に指定された曲の音楽コンテンツをオーディオクライアントＣ１に配信するが、上記実施の形態と異なり、オーディオクライアントＣ１から転送されたリスト構築キーに基づいて曲リストを作成する（Ｓ２０１２３）。リスト構築キー及び曲リストは、クライアント情報として、オーディオクライアントＣ１のクライアントインデックスに対応づけて記録される。これによりコンテンツサーバＳ１は、オーディオクライアントＣ１がコントローラＡ１からの命令に応じて再生している曲リストを把握していることになる。
音楽の再生終了後、オーディオクライアントＣ１から完了ステータスを受信したコンテンツサーバＳ１は、上記実施の形態と異なり、停止ステータスをコントローラＡ１に送信する（Ｓ２０１２４）。そして、コンテンツサーバＳ１はステップＳ２０１２３で作成した曲リストに従って次の曲の再生をオーディオクライアントＣ１に命令する（Ｓ２０１２５）。
以上のように本実施の形態によれば、コンテンツサーバＳ１自らが連続再生を命令するため、コントローラからの連続再生命令が競合することはなく、正常に連続再生処理を実行することができる。
上記の例はオーディオクライアントが１つしかないが、２つ以上あってもよい。たとえば図８０に示した例では、オーディオクライアントＣ１及びＣ２がコンテンツサーバＳ１に接続されている。上記ステップＳ１２３と同様に、コンテンツサーバＳ１は、オーディオクライアントＣ１及びＣ２が再生中のリスト構築キー及び曲リストをそれぞれ記憶している。完了ステータスがオーディオクライアントＣ１からコンテンツサーバＳ１に送信されると、コンテンツサーバＳ１は記憶したオーディオクライアントＣ１の曲リストに従ってオーディオクライアントＣ１に連続再生を命令し、コントローラＡ１に停止ステータスを送信する。また、完了ステータスがオーディオクライアントＣ２からコンテンツサーバＳ１に送信されると、コンテンツサーバＳ１は記憶したオーディオクライアントＣ２の曲リストに従ってオーディオクライアントＣ２に連続再生を命令し、コントローラＡ１に停止ステータスを送信する。このようにコンテンツサーバＳ１はオーディオクライアントＣ１及びＣ２を区別して連続再生を命令しているから、連続再生命令が競合することはない。
また、オーディオクライアントだけでなく、コンテンツサーバも２つ以上あってもよい。たとえば図８１に示した例では、オーディオクライアントＣ１及びＣ２がコンテンツサーバＳ１に接続され、オーディオクライアントＣ３がコンテンツサーバＳ２に接続されている。この場合も、各クライアントに接続されているコンテンツサーバは１つであるから、オーディオクライアントは接続されているコンテンツサーバにのみ完了ステータスを送信する。上記と同様に、コンテンツサーバＳ１はオーディオクライアントＣ１から完了ステータスを受信するとオーディオクライアントＣ１に連続再生を命令し、オーディオクライアントＣ２から完了ステータスを受信するとオーディオクライアントＣ２に連続再生を命令する。さらにこの場合、コンテンツサーバＳ２はオーディオクライアントＣ３から完了ステータスを受信するとオーディオクライアントＣ３に連続再生を命令する。したがってこの場合も、オーディオクライアントに連続再生を命令するコンテンツサーバはネットワーク上で唯一でとなるから、連続再生命令が競合することはない。
また、図８１に示した場合において、コントローラＡ１がコンテンツサーバＳ２に蓄積されている曲の再生をコンテンツサーバＳ１経由でオーディオクライアントＣ２に命令したとき、図８２に示すようにオーディオクライアントＣ２はコンテンツサーバＳ１との接続を一旦解除し、コンテンツサーバＳ２に接続し直す。このとき、コンテンツサーバＳ２は、オーディオクライアントＣ２から送信されたリスト構築キーに基づいて曲リストを作成し、オーディオクライアントＣ２のクライアント情報としてこのリスト構築キー及び曲リストを記憶する。オーディオクライアントＣ２はコンテンツサーバＳ２から配信された曲の再生を終えると、コンテンツサーバＳ２に完了ステータスを送信する。コンテンツサーバＳ２はこの完了ステータスに応じてオーディオクライアントＣ２に連続再生を命令するとともに、停止ステータスをコントローラＡ１に送信する。したがってこの場合も、オーディオクライアントに連続再生を命令するコンテンツサーバはネットワーク上で唯一でとなるから、連続再生命令が競合することはない。
また、オーディオクライアント及びコンテンツサーバだけでなく、コントローラも２つ以上あってもよい。たとえば図８３に示した例ではコントローラＡ１及びＡ２がある。コンテンツサーバＳ１はオーディオクライアントＣ１又はＣ２から完了ステータスを受信したとき、コントローラＡ１だけでなくコントローラＡ２にも停止ステータスを送信する。コンテンツサーバＳ２もまたオーディオクライアントＣ３から完了ステータスを受信したとき、コントローラＡ１だけでなくコントローラＡ２にも停止ステータスを送信する。このようにコントローラＡ１及びＡ２は連続再生を命令する機能を有さず、単にオーディオクライアントＣ１〜Ｃ３の状態を監視する機能を有するだけであるから、何ら連続再生処理に影響を与えない。
１．２．３．３．９．オーディオクライアント自身による連続再生制御
本実施の形態では、図８４に示したステップを実行するためのコンピュータプログラムがコンテンツサーバＳ１〜Ｓｉ、オーディオクライアントＣ１〜Ｃｊ及びコントローラＡ１〜Ａｋにそれぞれインストールされている。図８４中のステップＳ１０２３３〜Ｓ１０２３５が図７９に示した実施の形態と異なるので、ここではこれらを中心に説明する。
図７９に示した実施の形態と同様に、コントローラＡ１は指定された曲の再生をオーディオクライアントＣ１に命令するとともに、リスト構築キーをオーディオクライアントＣ１に送信し（Ｓ３０３２３）、オーディオクライアントＣ１は指定された曲をコンテンツサーバＳ１に要求し、さらにこの要求に応じてコンテンツサーバＳ１から配信された曲の再生を開始する（Ｓ１０２０２）。このとき、オーディオクライアントＣ１はコントローラＡ１から送信されたリスト構築キーを記憶しておく。
続いて、オーディオクライアントＣ１は記憶したリスト構築キーをコンテンツサーバＳ１に送信し、コントローラＡ１で選曲に使用した曲リストと同じ曲リストをコンテンツサーバＳ１に要求する（Ｓ１０２３３）。コンテンツサーバＳ１は受信したリスト構築キーに基づいて曲リストを作成し、オーディオクライアントＣ１に送信する（Ｓ２０１３３）。オーディオクライアントＣ１は受信した曲リストを記憶するとともに、その曲リストの中から現在再生中の曲を特定する（Ｓ１０２３４）。
オーディオクライアントＣ１はその曲を最後まで再生し終えると、記憶した曲リストに従って次の曲を再生する（Ｓ１０２３５）。
なお、曲リストに含まれる曲が複数のコンテンツサーバに分散して蓄積されている場合、オーディオクライアントＣ１は上記と同様にサーバ切換処理を行う。
以上のように本実施の形態によれば、オーディオクライアントＣ１自身がリスト構築キーを保持し、それを利用して曲リストを取得しているため、自ら連続再生処理を実行することができる。したがって、オーディオクライアントＣ１がコントローラＡ１やコンテンツサーバＳ１から連続再生命令を受けることはなく、連続再生命令が競合することはない。
本実施の形態でオーディオクライアントＣ１がリスト構築キーを利用して曲リストを取得しているのは曲の再生中であるが、曲の再生終了後であってもよい。また、オーディオクライアントＣ１は取得した曲リストを記憶しているが、記憶しないで、連続再生処理を実行するたびにリスト構築キーを利用して曲リストを取得してもよい。
１．２．３．３．１０．再生命令管理テーブルを利用した連続再生制御
本実施の形態では、図８５に示したステップを実行するためのコンピュータプログラムがコンテンツサーバＳ１〜Ｓｉ、オーディオクライアントＣ１〜Ｃｊ及びコントローラＡ１〜Ａｋにそれぞれインストールされている。図８５中のステップＳ３０３４１〜Ｓ３０３４５，Ｓ２０１４１が図７６に示した実施の形態と異なるので、ここではこれらを中心に説明する。
本実施の形態におけるコンテンツサーバＳ１には、クライアントインデックスとコントローラインデックスとを対応づけた再生命令管理テーブルが記憶されている。このテーブルの一例を次の表３に示す。表３に示した再生命令管理テーブルには、オーディオクライアントＣ１に再生を命令した最新のコントローラＡ１のコントローラインデックスが記録されている。また、オーディオクライアントＣ２に再生を命令した最新のコントローラＡ２のコントローラインデックスが記録されている。
Figure 0004013942
次に、図８５に示したフロー図を参照し、本実施の形態の動作を説明する。
あるコントローラは、あるコンテンツサーバに蓄積されている曲の再生をあるオーディオクライアントに命令する（Ｓ３０３４１）。
まず図８６に示すように、コントローラＡ１がコンテンツサーバＳ１に蓄積されている曲の再生をコンテンツサーバＳ１経由でオーディオクライアントＣ１に命令する場合を説明する。この例では、オーディオクライアントＣ１及びＣ２並びにコントローラＡ１〜Ａ３がコンテンツサーバＳ１に接続されている。
コントローラＡ１は、コンテンツサーバＳ１にオーディオクライアントＣ１が接続されているか否かを判断する（Ｓ３０３４２）。この例ではオーディオクライアントＣ１はコンテンツサーバＳ１に接続されているので、ステップＳ３０３１４に進む。
コントローラＡ１は、曲リストの中から指定された曲の再生をコンテンツサーバＳ１経由でオーディオクライアントＣ１に命令する（Ｓ３０３１４）。コンテンツサーバＳ１は、この再生命令に応じて予め定められた再生命令管理処理を実行する（Ｓ２０１４１）。
具体的には図８７を参照して、コンテンツサーバＳ１は、再生命令管理テーブルにおけるオーディオクライアントＣ１のクライアントインデックスに対応づけて、コントローラＡ１のコントローラインデックスを記録する（Ｓ２０１４４１）。これによりコンテンツサーバＳ１は、コントローラＡ１がオーディオクライアントＣ１に最後に再生を命令したコントローラであることを記憶していることになる。コンテンツサーバＳ１は、コントローラＡ１からの再生命令をオーディオクライアントＣ１に転送する（Ｓ２０１４１２）。
オーディオクライアントＣ１はコントローラＡ１からの再生命令に応じて曲の再生を開始し（Ｓ１０２１１）、その再生を終えると、完了ステータスをコンテンツサーバＳ１に送信する（Ｓ１０２１２）。
コンテンツサーバＳ１はオーディオクライアントＣ１から完了ステータスを受信すると、再生命令管理テーブルを参照してオーディオクライアントＣ１に最後に再生を命令したコントローラＡ１を特定し、そのコントローラＡ１に完了ステータスを送信するとともに、他のコントローラＡ２及びＡ３に停止ステータスを送信する（Ｓ２０１４１３）。完了ステータスを受信したコントローラＡ１はオーディオクライアントＣ１に連続再生処理を実行する（Ｓ３０３１６）。他方、停止ステータスを受信したコントローラＡ２及びＡ３は何ら能動的なアクションを起こさず、単にオーディオクライアントＣ１の状態を監視する。
また、オーディオクライアントＣ１がコントローラＡ１からの命令に従って曲を再生している場合において、別のコントローラＡ２が同じオーディオクライアントＣ１に別の曲の再生を命令すると、オーディオクライアントＣ１は現在の曲の再生を中止し、コントローラＡ２からの命令に従って新たな曲の再生を開始する。このとき、コンテンツサーバＳ１は再生命令管理テーブルを更新し、次の表４に示すようにコントローラＡ１のコントローラインデックスをコントローラＡ２のコントローラインデックスに書き換える。
Figure 0004013942
次に図８８に示すように、コントローラＡ３がコンテンツサーバＳ１経由で別のコンテンツサーバＳ２に蓄積されている曲の再生をオーディオクライアントＣ１に命令する場合を説明する。
コントローラＡ３は、コンテンツサーバＳ２にオーディオクライアントＣ１が接続されているか否かを判断する（Ｓ３０３４２）。この例ではオーディオクライアントＣ１はコンテンツサーバＳ２に接続されていないので、コントローラＡ３は予め定められたサーバ切換処理を実行する（Ｓ３０３４３）。
具体的には図８９を参照して、コントローラＡ３はコンテンツサーバＳ１経由でオーディオクライアントＣ１にコンテンツサーバＳ１からコンテンツサーバＳ２への切換を命令する（Ｓ３０３４３１）。コンテンツサーバＳ１はこの切換命令をオーディオクライアントＣ１に転送する（Ｓ２０１４０１）。オーディオクライアントＣ１は現在接続中のコンテンツサーバＳ１を切断し（Ｓ１０２４０１）、切換命令に応じて新しいコンテンツサーバＳ２に接続を要求する（Ｓ１０２４０２）。コンテンツサーバＳ２はこの要求に応じてオーディオクライアントＣ１との接続を確立する（Ｓ２０１４０２）。コントローラＡ３はコンテンツサーバＳ２との接続を確認する（Ｓ３０３４４）。
続いて、コントローラＡ３はコンテンツサーバＳ２経由で曲の再生をオーディオクライアントＣ１に命令する（Ｓ３０３１４）。コンテンツサーバＳ２はこの再生命令に応じて、次の表５に示すように、再生命令管理テーブルにおけるオーディオクライアントＣ１のクライアントインデックスに対応づけて、コントローラＡ３のコントローラインデックスを記録する（Ｓ２０１４４１）。
Figure 0004013942
コンテンツサーバＳ２は、コントローラＡ３からの再生命令をオーディオクライアントＣ１に転送する（Ｓ２０１４１２）。
オーディオクライアントＣ１はコントローラＡ３からの再生命令に応じて曲の再生を開始し（Ｓ１０２１１）、その再生を終えると、完了ステータスをコンテンツサーバＳ２に送信する（Ｓ１０２１２）。コンテンツサーバＳ２はオーディオクライアントＣ１から完了ステータスを受信すると、再生命令管理テーブルを参照してオーディオクライアントＣ１に最後に再生を命令したコントローラＡ３を特定し、そのコントローラＡ３に完了ステータスを送信するとともに、他のコントローラＡ１及びＡ２に停止ステータスを送信する（Ｓ１４１３）。完了ステータスを受信したコントローラＡ３はオーディオクライアントＣ１に連続再生処理を実行する（Ｓ３０３１６）。他方、停止ステータスを受信したコントローラＡ１及びＡ２は何ら能動的なアクションを起こさず、単にオーディオクライアントＣ１の状態を監視する。
以上のように本実施の形態によれば、コンテンツサーバがオーディオクライアントに最後に再生を命令したコントローラを管理し、オーディオクライアントからの完了ステータスをそのコントローラにのみ転送しているため、そのコントローラのみが連続再生をオーディオクライアントに命令する。したがって、連続再生命令が競合することはなく、正常に連続再生処理を実行することができる。
１．２．４．ＡＶレシーバの制御
図９０に示すように、ＬＡＮ１２にはＡＶＲクライアントＡＣ１及びＡＣ２が接続される。ＡＶレシーバＡＶＲ１は、ＥＩＡ−２３２によりＡＶＲクライアントＡＣ１に接続される。ＡＶレシーバＡＶＲ２は、ＵＳＢによりＡＶＲクライアントＡＣ１に接続される。ＡＶレシーバＡＶＲ３は、メーカ特有のシリアルインターフェースによりＡＶＲクライアントＡＣ２に接続される。
ＡＶＲクライアントＡＣ１及びＡＣ２の各々は、コンテンツサーバとの接続が完了したとき、ＥＩＡ−２３２、ＵＳＢなどのインタフェイスに関する情報をコンテンツサーバＳｉに通知してもよい。
ＵＳＢの場合、ＡＶＲクライアントＡＣ１は、ＡＶレシーバＡＶＲ２が接続されたとき、ＡＶレシーバＡＶＲ２のベンダＩＤやプロダクトＩＤなどの機種情報を取得することができるので、それをコンテンツサーバＳｉに通知する。ＥＩＡ−２３２の場合、ＡＶＲクライアントＡＣ１がＡＶレシーバＡＶＲ１の機種情報を取得するのは通常は困難であるから、接続されるＡＶレシーバＡＶＲ１のベンダＩＤ及びプロダクトＩＤをＡＶＲクライアントＡＣ１に予め登録しておき、ＡＶＲクライアントＡＣ１がそれをコンテンツサーバＳｉに通知するようにする。
接続される可能性があるＡＶレシーバが複数ある場合は、ＡＶＲクライアントとの通信プロトコルを定めておき、ＡＶＲクライアントがＡＶレシーバの機種情報を取得するようにすればよい。たとえば、ＡＶＲクライアントは一定の通信条件（ビットレート、ビット長、パリティなど）で一定時間（たとえば１秒）ごとに機種情報を問い合わせるパケットを送信し、ＡＶレシーバはそれに応答して機種情報を含むパケットを返信するようにすればよい。これにより、ＡＶＲクライアントは接続されているＡＶレシーバを特定することができる。ＵＳＢの場合も含めてこのような場合、ＡＶＲクライアントはコンテンツサーバとの接続が確立した後にＡＶレシーバの機種情報を取得する可能性もあるので、ＡＶレシーバの機種情報を取得した時点でその機種情報の変更をコンテンツサーバＳｉに通知する。
その結果、コンテンツサーバＳｉは、ＡＶＲクライアントＡＣ１，ＡＣ２に接続された又は接続される予定の全ＡＶレシーバＡＶＲ１〜ＡＶＲ３の機種情報を取得することができる。機種情報はコンテンツサーバＳｉからコントローラＡｋにも通知されるため、コントローラＡｋも機種情報を取得することになる。
ＡＶレシーバＡＶＲは、図９１に示すように、ボリューム、入力切換スイッチ、音場制御用ＤＳＰなど、さまざまな被制御素子を有している。コントローラＡｋはこのような被制御素子を指定して制御コマンドを発行する。そのため、コントローラは、ＡＶレシーバＡＶＲがどのような被制御素子を有しているかという機種情報を持っている。
なお、機種情報はコンテンツサーバＳｉが持っているから、コントローラＡｋがＡＶレシーバＡＶＲのベンダＩＤ及びプロダクトＩＤをキーとしてコンテンツサーバＳｉに機種情報を要求してもよい。
制御コマンドは、コントローラＡｋから出力され、コンテンツサーバＳｉ及びＡＶＲクライアントＡＣを経てＡＶレシーバＡＶＲに伝えられる。ステータスは逆に、ＡＶレシーバＡＶＲから出力され、ＡＶＲクライアントＡＣ及びコンテンツサーバＳｉを経てコントローラＡｋに伝えられる。
ＡＶＲクライアントＡＣは、制御コマンドがＡＶレシーバＡＶＲ用であることを確認すると、ＡＶレシーバＡＶＲにその制御コマンドを出力する。制御コマンドがボリュームの値を制御するものであれば、コントローラＡｋが発行した制御コマンドは、コンテンツサーバＳｉ及びＡＶＲクライアントＡＣを経てＡＶレシーバＡＣＲに送られ、これによりボリュームが制御される。
図９２を参照して、コントローラＡｋは制御コマンドをコンテンツサーバＳｉに送信し（Ｓ３５）、コンテンツサーバＳｉはこれを指定されたＡＶＲクライアントＡＣに送信し（Ｓ２８）、さらにＡＶＲクライアントはこれをＡＶレシーバＡＶＲに送信する（Ｓ１０１）。ＡＶＲクライアントＡＣはＡＶレシーバＡＶＲからそのステータスを受信してコンテンツサーバＳｉに送信し（Ｓ１０２）、コンテンツサーバはＳＶこれをコントローラＡｋに送信し（Ｓ２９）、コントローラＡｋはこれに応じてＡＶレシーバＡＶＲのステータスを更新する（Ｓ３６）。
図９３に示すように、コンテンツサーバＳｉ、ＡＶＲクライアントＡＣ１〜ＡＣ３、及びＡＶレシーバＡＶＲ１１，ＡＶＲ１２，ＡＶＲ２１，ＡＶＲ３１，ＡＶＲ３２は、コンテンツサーバＳｉを根とした木のような形状をした経路で制御コマンドを伝達する。
図９４を参照して、コントローラＡｋは、制御対象たるＡＶレシーバＡＶＲ及び制御内容を決定し（Ｓ３５０１）、その制御内容に基づいてコマンド本体を生成する（Ｓ３５０２）。続いて、コントローラＡｋは、図９５Ａに示すように、コマンド本体に宛先情報を付加した制御コマンドをコンテンツサーバＳｉに送信する（Ｓ３５０３）。ここでの宛先情報は、制御対象たるＡＶレシーバＡＶＲを指定するＡＶレシーバ指定部と、そのＡＶレシーバＡＶＲに接続されたＡＶＲクライアントＡＣを指定するＡＶＲクライアント指定部とを含む。
コンテンツサーバＳｉはこの制御コマンドを受信し、図９５Ｂに示すように、受信した制御コマンドからＡＶＲクライアント指定部を取り出す（Ｓ２８０１）。コンテンツサーバＳｉは、このＡＶＲクライアント指定部に基づいて指定されたＡＶＲクライアントＡＣを判断する。続いて、コンテンツサーバＳｉは、ＡＶＲクライアント指定部を取り除いた制御コマンドを指定されたＡＶＲクライアントＡＣに送信する（Ｓ２８０２）。
ＡＶＲクライアントＡＣはこの制御コマンドを受信し、図９５Ｃに示すように、受信した制御コマンドからＡＶレシーバ指定部を取り出す（Ｓ１０１１）。ＡＶＲクライアントＡＣは、このＡＶレシーバ指定部に基づいて指定されたＡＶレシーバを判断する。続いて、ＡＶＲクライアントＡＣは、コマンド本体のみからなる制御コマンドを指定されたＡＶレシーバに送信する（Ｓ２８０２）。
このように不要な指定部を順次取り除いて制御コマンドを転送すれば、ネットワークトラフィックを軽減することができる。ただし、指定部を取り除くことなく、制御コマンドをそのまま転送するようにしてもよい。
各段階で、コマンド本体の文字列は全く同じである必要はなく、その意味が同じであればよい。すなわち、最終的にＡＶＲクライアントＡＣからＡＶレシーバＡＶＲに送信される制御コマンドがＡＶレシーバＡＶＲに理解可能な形式であればよい。
このようにして制御コマンドを受信したＡＶレシーバＡＶＲは、制御コマンドに従って被制御素子を制御する。その結果、被制御素子のステータスが変化すれば、ＡＶレシーバＡＶＲはそのステータスをＡＶＲクライアントＡＣに送信する。このステータスは、図９６Ａに示すように、ステータス本体のみからなる。
ＡＶＲクライアントＡＣは、ＡＶレシーバＡＶＲのステータスを受信して記憶するとともに（Ｓ１０２１）、図９６Ｂに示すように、受信したステータスに発信元情報を追加し、それをコンテンツサーバＳｉに送信する（Ｓ１０２２）。ここでの発信元情報は、ステータスを発信したＡＶレシーバＡＶＲを指定するＡＶレシーバ指定部を含む。
コンテンツサーバＳｉはＡＶＲクライアントＡＣからのステータスを受信し、図９６Ｃに示すように、受信したステータスにＡＶＲクライアント指定部をさらに追加し、それをコントローラＡｋに送信する（Ｓ２９０１）。
コントローラＡｋはコンテンツサーバＳｉからのステータスを受信し、受信したステータスからＡＶＲクライアント指定部及びＡＶレシーバ指定部を取り出し、ＡＶレシーバＡＶＲのステータスを更新する（Ｓ３６０１）。
なお、ステータスは、被制御素子のステータスだけでなく、コントローラＡｋでは制御不可能な要素のステータス（たとえば音声信号のレベル情報など）も存在し得る。このようなステータスもＡＶＲクライアントＡＣ及びコンテンツサーバＳｉを経由してコントローラＡｋに伝えられる。また、ステータスは、ＡＶレシーバＡＶＲの被制御素子が制御コマンドにより制御されたときだけでなく、そのステータスが変化したときにも送信される。すなわち、ＡＶＲクライアントＡＣとＡＶレシーバＡＶＲとの接続が確認されたときにも、ＡＶＲクライアントＡＣはＡＶレシーバＡＶＲのステータスを取得し、これをコンテンツサーバＳｉに送信する。
このようにして最終的にステータスを受信したコントローラＡｋは、各ＡＶレシーバＡＶＲのステータスを把握することができる。これにより、コントローラは制御の確認及びステータスの表示を行う。
なお、表示目的のステータスであって頻繁に変化する可能性のあるステータスは、ＡＶレシーバＡＶＲ又はＡＶＲクライアントＡＣがステータスの送出頻度を適宜低くしてもよい。頻繁に変化するステータスをそのまま表示しても認識しにくいし、送出頻度が高いとネットワークに無用なトラフィックが発生し、コンテンツサーバの負荷も増大するからである。
複雑な構成を有する被制御素子は、複数の被制御部を持つ場合がある。たとえば図９１中の音場制御用ＤＳＰは多くの係数データの設定を必要とするが、その設定はＤＳＰを制御するマイクロコントローラにより行われる。この設定を変更する場合、スタンドアロンのシステムでは、ＡＶレシーバ本体又はそれに接続された表示装置でステータス状態を表示しながら、ユーザのキー操作により行うことになる。この動作を行うのはマイクロコントローラのファームウェアであり、複雑な設定が可能で、かつ使い易い操作を実現しようとすると、プログラム容量の増大や高性能な表示装置が必要になったりと、製品単価や開発費用に影響が出る可能性がある。
このシステムでは、係数データの設定パターンをいくつもコンテンツサーバＳｉに持たせ、コントローラＡｋに表示された階層メニューからそのうち１つを選択し、ＡＶＲクライアントＡＣ経由で係数データを設定することも可能である。
また、同時に複数のＡＶレシーバＡＶＲをコントローラＡｋの支配下に置けることから、ＡＶレシーバＡＶＲの時刻合わせなどの設定を同時に行うことができる。さらに、これらＡＶレシーバＡＶＲのステータスをモニタすることにより、リレー録画などの連携動作も可能になる。
次に、ＡＶＲクライアントＡＣに接続されているＡＶレシーバＡＶＲのボリュームを上げる場合を説明する。
図９７を参照して、コントローラＡｋはクライアントの接続を確認し（Ｓ３０１１）、接続があれば、そのクライアントがＡＶＲクライアントＡＣか否かを判別し（Ｓ３０１４）、ＡＶＲクライアントＡＣであれば、ボリュームアップを示す制御コマンドをコンテンツサーバＳｉに送信する（Ｓ３５）。コンテンツサーバＳｉはこれをＡＶＲクライアントＡＣに送信し（Ｓ２８）、さらにＡＶＲクライアントＡＣはこれをＡＶレシーバＡＶＲに送信する（Ｓ１０１）。ＡＶＲクライアントＡＣはボリュームアップしたことを示すステータスをＡＶレシーバＡＶＲから受信し、これをコンテンツサーバＳｉに送信する（Ｓ１０２）。コンテンツサーバＳｉはこれをコントローラＡｋに送信し（Ｓ２９）、コントローラＡｋはこれに応じてＡＶレシーバＡＶＲのステータスを更新し、図３４に示したモニタを再開する（Ｓ３６）。
次に、ＡＶＲクライアントＡＣがＡＶレシーバＡＶＲのステータスをコンテンツサーバに転送する動作を図９８を参照して説明する。
ＡＶＲクライアントＡＣはＡＶレシーバＡＶＲからパケットデータを受信すると（Ｓ１０２１）、それがボリューム情報か否かを判別する（Ｓ１０２２）。ＡＶレシーバＡＶＲからデータがＥＩＡ−２３２の場合は、パケット受信はシリアル受信割り込みで行われ、データはキューに入れられる。キューは定時的に読み出され、以降の処理が行われる。
続いて、受信したデータがボリューム情報であれば、ＡＶＲクライアントＡＣはそのボリューム値を記憶する（Ｓ１０２３）。上記ボリューム情報か否かの判別（Ｓ１０２２）及びボリューム情報の記憶（Ｓ１０２３）は、データがキューに入れられる前に行われる。一方、受信したデータがボリューム情報でなければ、ＡＶＲクライアントＡＣは、ＡＶレシーバＡＶＲからのステータスであることを示すＡＶレシーバ指定部を、受信したパケットデータに追加してコンテンツサーバＳｉに送信する（Ｓ１０２４）。
ボリューム値を記憶した後、ボリューム情報の受信が初めてか否かを判別する（Ｓ１０２５）。初めての場合はステップＳ１０２８に進むが、初めてでない場合はＡＶＲクライアントＡＣはボリューム値をコンテンツサーバに送信してから２００ミリ秒以上経過しているか否かを判別する（Ｓ１０２６）。２００ミリ秒以上経過している場合、ＡＶＲクライアントＡＣは前回送信したボリューム値を記憶したボリューム値と比較し（Ｓ１０２７）、異なっている場合はＡＶレシーバＡＶＲからのステータスであることを示すＡＶレシーバ指定部をボリューム情報に追加してコンテンツサーバＳｉに送信する（Ｓ１０２８）。
ボリューム値のステータスは他のステータスと比較して短い間隔でやって来る場合があるので、コンテンツサーバＳｉやコントローラＡｋの負担になったり、ネットワークに無用なトラフィックの増大をもたらす可能性がある。ボリューム情報はコントローラＡｋでの表示に用いるだけなので、表示に支障のない間隔で送れば問題ない。そのため、ボリューム情報を受信すると、その値だけを記憶し、変化があったときだけ適当な間隔（ここでは２００ミリ秒）をおいてコンテンツサーバＳｉに送信するようにしている。
次に、ＡＶＲクライアントＡＣがコンテンツサーバＳｉからのコマンドをＡＶレシーバＡＶＲに転送する動作を図９９を参照して説明する。
ＡＶＲクライアントＡＣはＡＶレシーバＡＶＲ用の制御パケットを受信すると（Ｓ１０３１）、そのパケットからＡＶレシーバＡＶＲ用の制御コマンドを取り出す（Ｓ１０３２）。ＡＶＲクライアントＡＣは、その制御コマンドがボリューム値問い合わせコマンドか否かを判別する（Ｓ１０３３）。ボリューム値問い合わせコマンドの場合、ＡＶＲクライアントＡＣは記憶しておいたボリューム値（未受信の場合は適当な初期値）からボリューム情報を生成し（Ｓ１０３４）、ＡＶレシーバＡＶＲからのステータスであることを示すＡＶレシーバ指定部をボリューム情報に追加してコンテンツサーバＳｉに送信する（Ｓ１０３５）。
一方、ボリューム値問い合わせコマンドでない場合、そのＡＶレシーバＡＶＲ用の制御コマンドをＡＶレシーバＡＶＲに送信する（Ｓ１０３６）。ＡＶＲクライアントＡＣとＡＶレシーバＡＶＲとのインタフェイスがＥＩＡ−２３２の場合には、ＡＶＲクライアントＡＣからＡＶレシーバＡＶＲへの送出はバイト単位で割り込みによって行われる。コンテンツサーバＳｉからの制御コマンドは一旦キューに格納される。キューは定時的な割り込み又はシリアル送信のバッファエンプティの割り込みで読み出され、バイト単位で送出される。
上記の形態では、コンテンツサーバＳｉへのボリューム情報の送出は、初回を除いて変化があったときしか行われない。そのため、ＡＶレシーバＡＶＲがコンテンツサーバＳｉからのボリューム値問い合わせコマンドに応答してボリューム値を返したとしても、そのボリューム値に変化がなければＡＶＲクライアントＡＣはそのボリューム値をコンテンツサーバＳｉに返さない。この対策として、コンテンツサーバＳｉからのボリューム値問い合わせコマンドに対しては、ＡＶＲクライアントＡＣはＡＶレシーバＡＶＲを介さずに応答するようにしている。この形態は、ＡＶレシーバＡＶＲに電源が投入されたときは必ずＡＶレシーバＡＶＲはボリュームの初期値をステータスとしてＡＶＲクライアントＡＣに送信することが前提となっている。しかし、電源投入のタイミングによっては、ＡＶＲクライアントＡＣがこの初期値を受信できない可能性もある。
そこで、図１００に示すように、ＡＶＲクライアントＡＣは初回に限りＡＶレシーバＡＶＲ経由で応答を行うのが好ましい。すなわち、コンテンツサーバＳｉからの制御コマンドがボリューム値問い合わせコマンドの場合、ＡＶＲクライアントＡＣはボリューム値を未だ受信していないか否かを判別する（Ｓ１０３４）。未だ受信していない場合はステップＳ１０３６に進み、既に受信している場合はステップＳ１０３４に進む。
なお、複数種類のＡＶレシーバが存在する場合において、コントローラＡｋがこれらのＡＶレシーバを制御するときは、コントローラＡｋはＡＶレシーバの種類に応じて専用の制御コマンドを発行してもよいが、ＡＶレシーバの種類に関係なく汎用の制御コマンドを発行し、コンテンツサーバがこの汎用の制御コマンドを専用の制御コマンドに変換するようにしてもよい。
１．２．５．ファームウェアアップデート
コンテンツサーバは、後述するように、クライアントにインストールされているファームウェアをアップデートすることができる。ここでは、クライアントがコンテンツサーバにアップデートを要求する場合と、コンテンツサーバがクライアントに問い合わせをした上でアップデートする場合と、コンテンツサーバが強制的にアップデートする場合とがある。
まず、クライアントがコンテンツサーバにアップデートを要求する場合の概要を説明する。図１０１を参照して、クライアントはファームウェア情報をコンテンツサーバに要求し（Ｓ１０３）、コンテンツサーバはこれに応じてファームウェア情報をクライアントに返信し（Ｓ２０１）、クライアントはこれを受信する（Ｓ１０３）。続いて、クライアントはファームウェアを指定し（Ｓ１０４）、コンテンツサーバはこれに応じて指定されたファームウェアの転送を準備する（Ｓ２０２）。続いて、クライアントはファームウェアをコンテンツサーバに要求し（Ｓ１０５）、コンテンツサーバはこれに応じてファームウェアをクライアントに転送し（Ｓ２０３）、クライアントはこれを受信する（Ｓ１０５）。続いて、クライアントはファームウェアをアップデートし（Ｓ１０６）、アップデートを終えると終了ステータスをコンテンツサーバに送信し（Ｓ１０７）、コンテンツサーバはこれを受信する（Ｓ２０４）。
次に、ファームウェアアップデートの詳細を図１０２を参照して説明する。コンテンツサーバからアップデートを開始する場合は、ステップＳ２０１２から処理を開始する。クライアントからアップデートを開始する場合は、ステップＳ１０３３から処理を開始する。
コンテンツサーバは、まず、ファームウェア情報ファイルを読み込み、図１５に示したファームウェア情報データベースを作成しておく（Ｓ２０１１）。たとえば、コンテンツサーバがクライアントごとにアップデートに必要なファイルを読み込み、アップデート情報ファイルを作成する。したがって、この情報ファイルに基づき、クライアントのファームウェアの新旧を判断できる。クライアントは、起動時にプロダクトＩＤ及びファームウェアＩＤをコンテンツサーバに送信する（Ｓ１０３１）。
コンテンツサーバからアップデートを開始する場合、たとえばコンテンツサーバがクライアントのプロダクトＩＤ及びファームウェアＩＤに基づいてそのファームウェアが古いと判断した場合や、コンテンツサーバがインターネット上のサイトから新しいファームウェアを取得した場合などには、コンテンツサーバは、クライアントにファームウェアのアップデートを要求するためのファームウェアアップデート要求コマンドを発行し、必要に応じて、アップデートを推奨する新しいファームウェアの情報をクライアントに提示する（Ｓ２０１２）。ユーザが推奨されたファームウェアのアップデートを望まない場合、クライアントはコンテンツサーバからのアップデート要求を拒否し、この処理は直ちに終了する（Ｓ１０３２）。また、ユーザが推奨されたファームウェアのアップデートを保留する場合も、この処理は直ちに終了する（Ｓ１０３２）。ただし、この場合、クライアントはコンテンツサーバに所定時間経過後に再びアップデート要求をするように命令する。また、ユーザが推奨されたファームウェアのアップデートを受け入れる場合、クライアントはそのまま処理を継続する（Ｓ１０３２）。この場合において、コンテンツサーバがクライアントに具体的なファームウェアを提示しているときは、クライアントはステップＳ１０３５に進み、直ちにファームウェアのアップデートを開始する。また、コンテンツサーバがクライアントに具体的なファームウェアを提示することなく、単にアップデートを要求しているときは、クライアントはステップＳ１０３３に進み、ファームウェアリストを取得する。
なお、ファームウェアアップデート要求コマンドは、コントローラがサーバリクエストとして発行してもよい。この場合は、コントローラは後述するＳ１０３３〜Ｓ１０３４と同様にして、制御及び監視するクライアントに関するファームウェアリストをコンテンツサーバから取得し、ユーザが所望のファームウェアを選択する。コントローラにて選択されたファームウェアがアップデートを推奨するファームウェア情報としてクライアントに提示される。
アップデート要求を受け入れる場合、又はクライアントからアップデートを開始する場合、クライアントはファームウェアリストをコンテンツサーバに要求する（Ｓ１０３３）。ファームウェアリストは、特定クライアントに適用可能なファームウェアを列挙したものである。コンテンツサーバは、ファームウェアリストを常時持っているのではなく、クライアントからの要求に応じてその都度作成する。ファームウェアリストの作成方法は、上述した曲リストの作成方法と基本的に同じである。ただし、ファームウェアリストを作成するときには、コンテンツサーバは、図１５に示したファームウェア情報データベースを用いる。このデータベースには、ファームウェア情報がファームウェア数分だけ格納されている。以下、ファームウェアリストの作成方法を詳述する。
図１０３を参照して、まずコンテンツサーバは、ファームウェア情報データベースに格納されているファームウェア情報の番号を示すインデックスを０に初期化する（Ｓ２０１３１）。
続いて、コンテンツサーバは、インデックスが示すファームウェア情報のプロダクトＩＤがクライアントのプロダクトＩＤと一致するか否かを判別する（Ｓ２０１３２）。一致する場合、コンテンツサーバはそのファームウェア情報をファームウェアリストに追加し（Ｓ２０１３３）、その後、インデックスをインクリメントする（Ｓ２０１３４）。一方、一致しない場合、コンテンツサーバは、ステップＳ２０１３３をスキップし、直ちにインデックスをインクリメントする（Ｓ２０１３４）。
続いて、コンテンツサーバは、インデックスが示すファームウェア情報の番号が全ファームウェア情報の数ｎよりも小さいか否かを判別し（Ｓ２０１３５）、小さい場合はステップＳ２０１３２に戻り、一方、小さくない場合はファームウェアリストの作成を完了する。
上記の処理により、コンテンツサーバは、ファームウェア情報データベースの中からプロダクトＩＤが一致するファームウェア情報をピックアップし、ファームウェアリストを作成する。このように、ファームウェアリストは予めデータベース化されているのではなく、クライアントからの要求のたびに一時的に作成されるので、ファームウェアリストを常に格納しておくためのメモリ領域は不要である。
続いて、コンテンツサーバは、この作成したファームウェアリストを要求元クライアントに返信する（Ｓ２０１３）。このファームウェアリストも上記曲リストと同様に、コンテンツサーバからクライアントに分割されて送られる。
具体的には、図１０４を参照して、クライアントは、自身のプロダクトＩＤと、取得しようとする最初のファームウェア情報を示す取得開始インデックスと、取得しようとするファームウェア情報の数を示す取得個数とを含むファームウェアリスト要求コマンドをコンテンツサーバに送信する（Ｓ１０３３）。コンテンツサーバは、このファームウェアリスト要求コマンドに応答して、クライアントのプロダクトＩＤと同じプロダクトＩＤを有するファームウェア情報を抽出し、取得開始インデックスが示すファームウェア情報から取得個数が示す数だけファームウェア情報をクライアントに返信する（Ｓ２０３１）。このとき、コンテンツサーバは、送信するファームウェア情報の数を示す有効個数と、コンテンツサーバがクライアントに返信したファームウェアリストよりも後に残っているファームウェアの数を示す残り個数とを併せて送信する。クライアントは、このようなファームウェアリストの一部を受信してメモリに格納する（Ｓ１０３３１）。上記処理は、全ファームウェアリストがコンテンツサーバからクライアントに送られるまで繰り返される。
続いて、クライアントは、返信されたファームウェアリストの中にユーザがダウンロードしたいファームウェア（新しいバージョンなど）があれば処理を継続し、なければ処理を中止する（Ｓ１０３４）。
コンテンツサーバは、新旧を問わず、全てのバージョンのファームウェア情報を送信するので、不具合などにより、クライアントは、古いファームウェアに変更することもできる。
アップデートを行う場合、クライアントはアップデートセクションに移行したことを示すステータスをコンテンツサーバに通知する（Ｓ１０３５）。コンテンツサーバは、このステータスに応答してエラーの有無を示すエラーコードを返信する（Ｓ２０１４）。クライアントは、ダウンロードしようとするファームウェアのファイルを指定する（Ｓ１０３６）。具体的には、取得したファームウェア情報のリストに格納されているフルパス名を指定する。コンテンツサーバは、指定されたファイルを読み出し、バッファに格納しておく（Ｓ２０１５）。
続いて、クライアントは、取得開始アドレス及びデータサイズ（バイト数）を指定し、ファームウェアのデータを取得する（Ｓ１０３７）。コンテンツサーバは、指定された取得開始アドレスから指定されたバイト数分だけデータをバッファから読み出し、クライアントに送信する（Ｓ２０１６）。
クライアントは、ファームウェアのデータを最後まで取得したか否かを判別し（Ｓ１０３８）、取得していない場合はステップＳ１０３７に戻ってデータの取得を繰り返す。取得し終えた場合、クライアントはファームウェアを書き換え（Ｓ１０３９）、アップデートを終了する（Ｓ１０４０）。コンテンツサーバは、開いていたファームウェアのファイルを閉じ、バッファを解放する（Ｓ２０１７）。
さらに、クライアントがファームウェアの書き換えを完了したときは、不明ステータスをコンテンツサーバに送信する。クライアントは、コンテンツサーバとの接続を中断して、リセット（すなわち、更新されたファームウェアを起動）し、クライアント情報をコンテンツサーバに通知する。また、クライアントがファームウェアデータを取得失敗したときは、失敗ステータスを送信してもよい。失敗ステータスは、ファームウェアデータ再送信などに用いることができる。
なお、コンテンツサーバからアップデート要求を行う場合において、次の様に処理することもできる。すなわち、図１０２において、コンテンツサーバはアップデート要求の際に、必ずファームウェアの情報をクライアントに提示する（Ｓ２０１２）。コンテンツサーバが推奨するファームウェアをアップデートする場合にはＳ１０３５に進み、コンテンツサーバが推奨するファームウェアをアップデートするのではなく、ユーザがファームウェアリストから所望のファームウェアを選択する場合にはＳ１０３３に進むようにすることもできる。
以上のように、ファームウェアのデータがコンテンツサーバからＬＡＮ経由でオーディオクライアントに送信されるので、クライアントのファームウェアを短時間でアップデートすることができ、しかも複数のクライアントのファームウェアを同時にアップデートすることもできる。また、プロダクトＩＤを用いているため、クライアントに適したファームウェアを自動的に選択してアップデートすることがきる。また、ファームウェアＩＤを用いているため、最新バージョンのファームウェアを自動的に選択してアップデートすることがきる。
２．他の実施の形態
２．１．コンセント内蔵型オーディオクライアント
オーディオクライアントは、図１０５及び図１０６に示すように、コンセントボックス５０に内蔵されてもよい。コンセントボックス５０は一般に、壁５２に取り付けられる前面パネル５４と、前面パネル５４の裏面に取り付けられた筐体５６とを備える。この発明の実施の形態では、筐体５６の中に、図３に示したオーディオクライアント用の回路が設けられる。ＬＡＮケーブルは、このオーディオクライアント用の回路に接続される。また、前面パネル５４には、電源コンセント５８、電源スイッチ６０、モジュラージャック（図示せず）、テレビアンテナ用端子（図示せず）などに加えて、オーディオクライアントからのオーディオ信号を出力するためのオーディオ出力端子６２が設けられる。これらオーディオ出力端子６２はそれぞれ左右のスピーカ装置に接続される。
オーディオクライアントは、通常、曲リストを表示するためのディスプレイと、その表示された曲リストから所望の曲を選択するためのスイッチ類とを備えている。ディスプレイやスイッチ類はオーディオクライアントをモニタしかつ制御するために必要であるが、オーディオクライアントと同じＬＡＮ１２に接続されたコントローラを使用することにより、オーディオクライアントからディスプレイやスイッチ類を除去することができる。また、コントローラを使用する代わりに、オーディオクライアントと同じＬＡＮ１２に無線で接続された携帯型リモートコントローラを使用してもよい。
このようにオーディオクライアントを簡素化することにより、一般家庭のコンセントボックス５０に内蔵することができる。簡素化されたコンセント内蔵型オーディオクライアントは、ネットワークから音楽や映像を抽出して再生する機能のみを有し、表示機能や制御機能を有していない。
インターネットの普及、特にブロードバンド（高速・大容量）のインフラが整備されるに従い、一家に複数台のパソコンからインターネットに接続する要求が増えると予想されている。宅内で複数台のパソコンをインターネットに接続する最も一般的な方法は、宅内にＬＡＮを構築することであり、こうした宅内ＬＡＮを備えた世帯が増加することは時間の問題となっている。このＬＡＮを利用すれば、上述の音楽や映像を宅内の各所に配信することがケーブル１本で可能になる。また、１本のケーブルには音楽／映像信号の他にコントロール信号も併せて伝送することができるから、本システムの設置にはオーディオ／ビデオに関する専門的な知識が不要である。さらに、コスト面でも極めて有利であるため、業務用のみならず、家庭用としても普及しうる。
一般家庭において、新築時又はリフォーム時にインターネット接続の利便性を考慮して宅内ＬＡＮを敷設するケースが増大しているが、このときコンセントボックス５０にＬＡＮコネクタを設けるのが極めて一般的である。したがって、ＬＡＮの敷設工事と同時に複数のオーディオクライアントを容易に設置することができる。すなわち、スピーカ（パワードを含む）を接続するだけでオーディオクライアントを構築することができ、また、テレビなどの映像モニタを接続するだけでビデオクライアントを構築することができる。そのため、インテリア上も見栄えのよいオーディオクライアントをセットすることができる。さらに、商品開発の観点からも商品自体の華美なデザイン設計が不要となり、機能を重視した極めてシンプルな設計手法により商品開発コストの低減につながる。また、その構造がシンプル故にリサイクルのし易さの点でも有益である。
宅内ＬＡＮによる配信では、従来のオーディオ／ビデオ機器と異なり、ＣＤやテープといったコンテンツのメディアを必要としない。すなわち、コンテンツは一度コンテンツサーバに格納してしまえば、そのメディアの管理は不要となる。こうした宅内ネットワークによるサーバクライアントの構成によれば、オーディオクライアントにはメディアを挿入する機構や回転駆動装置など、機械系の装置を全く必要としない。したがって、装置の小型化を達成し、さらに高い信頼性とともに長寿命な商品を可能にする。
２．２．インターネット上の音楽データを取得
上記実施の形態では、オーディオクライアントは電源投入時にブロードキャストによりコンテンツサーバを探索している。しかし、ＬＡＮ１２上の全コンテンツサーバの電源が落ちていた場合、コンテンツサーバからの応答がないため、オーディオクライアントは永久にコンテンツサーバを探索し続けることになる。これを防止するためには、オーディオクライアントはタイムアウトエラーなどの処理を行えばよいが、タイムアウトエラーの場合、オーディオクライアントは音楽を再生するなどの動作を全く行うことができない。
これらの問題を解決するためには、オーディオクライアントがブロードキャストを所定回数繰り返してもコンテンツサーバを発見することができない場合は、インターネット上のＷＷＷサーバにアクセスし、このサーバと接続するようにすればよい。
この場合、ＬＡＮ１２は、図１０７に示すように、ゲートウェイ５０を通じてインターネット５２に接続される。インターネット５２上のＷＷＷ(World Wide Web)サーバ５４には、音楽配信サイト５６に置かれている曲のリストが予め登録されている。このリストには、曲名やアーティスト名など、曲情報の他、音楽データが置かれているＵＲＬ(Uniform Resource Locator)などが記録されている。
図１０８に示すように、サーバリストが空の場合、オーディオクライアントは、ステップＳ１１０２に戻ってブロードキャストをリトライする前に、そのリトライ回数が所定の回数、たとえば３回に達したか否かを判別する（Ｓ１１０９）。リトライ回数が３回に達していない場合、オーディオクライアントはリトライ回数をインクリメントし（Ｓ１１１０）、その後、ステップＳ１１０２に戻ってブロードキャストをリトライする。一方、リトライ回数が３回に達している場合、オーディオクライアントはインターネット５２上のＷＷＷサーバ５４にＨＴＴＰで接続する（Ｓ１１１１）。オーディオクライアントが接続に成功した場合は探索を完了するが（Ｓ１１１２）、接続に成功せず、タイムアウトになった場合はエラーとなる（Ｓ１１１３）。
オーディオクライアントはＷＷＷサーバ５２にアクセスすると、そこから曲情報やＵＲＬを受信して解析し、そのＵＲＬの音楽配信サイト５６から音楽データを受信する。
以上のように、コンテンツサーバがＬＡＮ１２上に存在しない場合又は存在しても稼動していない場合は、オーディオクライアントはインターネット５２上のサイト５６に自動的にアクセスして音楽データを取得するので、ＬＡＮ１２上のコンテンツサーバを永久に探索し続けることはない。
上記の例では、リトライ回数が所定回数に達したとき、オーディオクライアントはインターネット５２上のＷＷＷサーバ５４に接続するようにしているが、これに代えて、オーディオクライアントがマジックワードをブロードキャストして所定時間が経過したにもかかわらず、ＬＡＮ１２上のいずれのコンテンツサーバからも応答がない場合にインターネット５２上のＷＷＷサーバ５４に接続するようにしてもよい。
２．３．取得データ長変更機能付き再生
上記実施の形態では、オーディオクライアントＣｊがコンテンツサーバＳｉに曲データの転送を要求するとき、常に一定量の曲データを要求している。したがって、コンテンツサーバＳｉに曲データの転送を要求するオーディオクライアントＣｊの数が少ない場合は問題ないが、この数が多くなると、コンテンツサーバＳｉにかかる負荷が大きくなり、オーディオクライアントＣｊがコンテンツサーバＳｉに曲データの転送を要求してから実際に曲データが転送されるまでの時間が長くなるという問題が生じる。そこで、このコンテンツサーバＳｉにかかる負荷が均等になるように、オーディオクライアントＣｊが１回に要求する曲データの量をその都度変更するようにしてもよい。
以下、オーディオクライアントＣｊがコンテンツサーバＳｉに曲データの転送を要求してから実際に曲データが転送されるまでの時間に応じて、オーディオクライアントＣｊが１回に要求する曲データの量を変更する例を説明する。
図１０９を参照して、オーディオクライアントＣｊは、コンテンツサーバＳｉに曲データの転送を要求する曲データ転送コマンドを送信する（Ｓ１６０１）と同時に、タイマを動作させ、コンテンツサーバＳｉから曲データが転送されるまでの応答時間のカウントを開始する（Ｓ１６０１１）。なお、最初にオーディオクライアントＣｊが曲データ転送コマンドを発行するときには、１回に要求すべき適切な曲データの量は不明であるから、取得データ長は予め定められたものになる。
続いて、オーディオクライアントＣｊは曲データを受信し始めると（Ｓ１６０１２）、タイマを停止し、コンテンツサーバＳｉによる曲データの応答時間を取得する（Ｓ１６０１３）。
オーディオクライアントＣｊは、図１１０に示した対比テーブルを参照し、取得した応答時間に対応する取得データ長を決定する（Ｓ１６０２１）。この対比テーブルには、所定の応答時間と所定の取得データ長とが対応つけられている。ここでは、応答時間が長いほどコンテンツサーバＳｉにかかる負荷は大きいから、応答時間が長いほど取得データ長が短くなるように設定されている。たとえばオーディオクライアントＣｊが２０ｍｓｅｃの応答時間を取得した場合は、取得データ長を８ｋバイトと決定する。
オーディオクライアントＣｊは再び曲データの転送をコンテンツサーバＳｉに要求するが、ここでは上記で決定した取得データ長を送信する（Ｓ１６０５）。以降、上記と同様の動作を繰り返す（Ｓ１６０５１〜Ｓ１６０６１）。
以上のようにこの実施の形態によれば、オーディオクライアントＣｊがコンテンツサーバＳｉに要求する曲データの取得データ長を応答時間が長くなるにつれて短くしているため、コンテンツサーバＳｉに曲データの転送を要求するオーディオクライアントＣｊの数が増えても、コンテンツサーバＳｉがオーディオクライアントＣｊに１回に転送する曲データの量は少なくなる。その結果、各オーディオクライアントＣｊに対するコンテンツサーバＳｉの負荷は平均化され、コンテンツサーバＳｉは複数のオーディオクライアントＣｊに円滑に曲データを転送することができる。
上記の例では、コンテンツサーバの応答時間に応じて取得データ長を決定しているが、これに代えて、取得しようとする曲のデータフォーマットに応じて取得データ長を決定するようにしてもよい。すなわち、図３５において、曲データ転送要求（Ｓ１６０１）前に、図３２に示す検索データに基づいて、曲の音声フォーマットを取得する。そして、曲の音声フォーマットに基づいて、取得データ長を設定する。一般にＭＰ３形式のデータは圧縮されているためにサイズが小さいのに対し、ＷＡＶ形式のデータはサイズが大きい。そこで、取得しようとする曲のデータフォーマットがＭＰ３の場合には、１回にたとえば４Ｋバイトのデータを取得し、ＷＡＶの場合には、１回にたとえば１６Ｋバイトのデータを取得するようにしてもよい。
２．４．スキップ再生
上記実施の形態では、オーディオクライアントＣｊは曲リストの順序にしたがってコンテンツサーバＳｉに曲データの転送を要求している。しかしながら、ユーザが現在再生中の曲をはじめから聴きなおしたい場合がある。また、ユーザが現在再生中の曲をスキップして、他の曲を聴きたい場合もある。そこで、オーディオクライアントＣｊがこのようなユーザの要求に対応して曲データ転送の要求をできるようにしてもよい。
図１１１を参照して、オーディオクライアントＣｊが図１１２に示した曲リスト中の曲３の再生を行っている場合、オーディオクライアントＣｊは曲３の音楽データのうち指定範囲の音楽データの転送をコンテンツサーバＳｉに要求し（Ｓ１６０７）、コンテンツサーバＳｉはこの要求に応じて指定範囲の音楽データをオーディオクライアントＣｊに返信し（Ｓ２６０４）、オーディオクライアントＣｊはこれを受信し、メモリ３２に格納する（Ｓ１６０８）。この動作の繰り返しにより曲３は再生される。
曲３の再生中に、ユーザが曲３の再生を終了して、曲４を聴こうとした場合（図１１２における（１）のケース）、ユーザはオーディオクライアントＣｊに曲４へのスキップ要求を行う。オーディオクライアントＣｊはユーザからのスキップ要求を受け（Ｓ１６４０）、メモリ３２に格納された曲リスト内容を確認し、曲４のファイル名を取得する（Ｓ１６４１）。ユーザからのスキップ要求がない場合は、ステップＳ１６０７に戻って曲３のデータ転送の要求を行う。
以降のオーディオクライアントＣｊおよびコンテンツサーバＳｉの動作については図３５での動作と同じであるため、その説明は繰り返さない。
以上の動作により、オーディオクライアントＣｊは曲３の再生中に曲４へスキップ再生できる。
なお、オーディオクライアントＣｊが曲３を再生中において、ユーザが曲３を初めから再び聴こうとする場合（図１１２における（２）ケース）、ユーザが曲５を聴こうとする場合（図１１２における（３）ケース）、ユーザが曲２を聴こうとする場合（図１１２における（４）ケース）等についても同様の動作により、オーディオクライアントＣｊはスキップ再生できる。
以上のようにこの実施の形態によれば、オーディオクライアントＣｊはメモリ内に格納された曲リストを用いることで、現在再生中の曲から他の曲へスキップ再生できる。
２．５．リピート再生
また、ユーザが指定する第1アドレスと第２アドレスとの間で、データを繰り返して再生するA−Ｂ間リピート再生を行うことができる。まず、ユーザは１回目のA−B間リピート操作を行い、繰り返しの始まりを示す第１アドレスを指定する。すなわち、図１１３を参照して、オーディオクライアントは、曲データの転送要求（および曲データの取得）の際に（Ｓ１６０１）、ユーザからの操作があって（Ｓ１６４２）、ユーザからの操作がＡ−Ｂ間リピート要求であって（Ｓ１６４３）、１回目の要求であるので（S１６４４）、ユーザが指定したアドレスを第１アドレス（ａｄｄｒ１）として記憶する。そして、前回の取得開始アドレス（ａｄｄｒ）に取得データ長（ｓｉｚe）を加算して取得開始アドレス（ａｄｄｒ）を算出し（Ｓ１６４６）、S１６０１へと戻る。
次に、ユーザは２回目のA−B間リピート操作を行い、繰り返しの終わりを示す第２アドレスを指定し、リピート動作を開始させる。すなわち、S１６４４において、ユーザからのA−B間リピート要求が２回目の要求である（１回目の要求ではない）ので、ユーザが指定したアドレスを第２アドレス（ａｄｄｒ２）として記憶する（Ｓ１６４７）。
そして、オーディオクライアントは、A−B間リピートモードに入る（S１６４8）。すなわち、取得開始アドレスを第１アドレスに変更し（S１６４９）、曲データ転送要求（および曲データ取得）を行う（S１６０１）。ここで、オーディオクライアントは、A−B間リピート状態であると判断し（S１６５０）、取得開始アドレス（＝前回の取得開始アドレス＋取得データ長）が第２アドレスより大きくなるか否かを判別する（S１６５１）。取得開始アドレスが未だ第２アドレス以下であれば、曲データ転送要求を続ける（S１６４６およびS１６０１）。そして、S１６５１において、取得開始アドレスが第２アドレスより大きくなる場合には、取得開始アドレスを再び第１アドレスに変更し（Ｓ１６５２）、曲データ転送要求を行う（Ｓ１６０１）。従って、第１アドレスと第２アドレスとの間でリピート再生を行うことができる。また、ユーザはリピート解除操作を行うことにより、リピート状態を解除することができる（Ｓ１６４３、Ｓ１６５３およびＳ１６５４）。
２．６．途中再生
また、取得開始アドレスをユーザが指定する（例えば、開始時間を入力する）ことにより、指定アドレスからの曲の再生を行うことができる。すなわち、図１１４を参照して、例えば曲データの転送要求（および曲データの取得）の際に（Ｓ１６０１）、ユーザからの操作があって（Ｓ１６５６）、アドレスの指定である場合には（Ｓ１６５７）、オーディオクライアントはユーザから指定のあったアドレスを取得する（Ｓ１６５８）。例えば、曲の総再生時間とユーザが入力した開始時間からアドレスを算出する。そして、取得開始アドレスをユーザから指定のあったアドレスに変更して（Ｓ１６５９）、曲データ転送要求（および曲データ取得）を行う（Ｓ１６０１）。従って、ユーザが指定するアドレスからの曲の再生行うことができる。さらに、ユーザがアドレスを指定することができるのは、オーディオクライアントが再生状態のときに限らず、例えば、停止状態や一時停止状態のときであってもよい。
２．７．自動接続回復機能付きクライアント
ネットワークオーディオシステムでは、上述したように、オーディオクライアントがコンテンツサーバに接続され、コンテンツサーバから配信された音楽を再生しているが、配信中にコンテンツサーバの異常によりオーディオクライアントがコンテンツサーバから切り離された場合、オーディオクライアントはコンテンツサーバに再び接続されなければ音楽を再生することができない。入力装置を有する通常のオーディオクライアントの場合、その入力装置を操作することによりそのオーディオクライアントに図５に示したようにコンテンツサーバとの接続処理を再び実行させればよい。しかし、上述したコンセント内蔵型オーディオクライアントの場合、入力装置を備えていないため、一旦コンテンツサーバから切り離されるとそのまま放置されてしまう。したがって、オーディオクライアントは以下のような自動接続回復機能を備えているのが望ましい。
図１１５を参照して、オーディオクライアントＣｊはコンテンツサーバＳｉと接続してから所定期間が経過したか否かを判断する（Ｓ１１０）。所定期間経過後、オーディオクライアントＣｊはコンテンツサーバＳｉとの接続が維持されているか否かを判断する（Ｓ１１１，Ｓ１１２）。具体的には、オーディオクライアントＣｊは接続確認コマンドをコンテンツサーバＳｉに送信する（Ｓ１１１）。コンテンツサーバＳｉからオーディオクライアントＣｊに接続確認コマンドに対する返答がある場合（Ｓ１１２）、接続は維持されていると判断される。一方、返答がない場合や送信エラーが起きる場合（Ｓ１１２）、接続は切断されていると判断される。返答方法としては、たとえばコンテンツサーバＳｉが送信された接続確認コマンドと同じコマンドを返信する方法がある。
ステップＳ１１２で返答があった場合、オーディオクライアントＣｊは再びＳ１１０に戻って所定期間経過後に接続が維持されているか否かを判断する（Ｓ１１０〜Ｓ１１２）。これにより、オーディオクライアントＣｊは所定期間ごとにコンテンツサーバＳｉとの接続状態をチェックする。接続が切断されている場合、オーディオクライアントＣｊは同じコンテンツサーバＳｉに対して再接続を試みる（Ｓ１２）。
再接続を試みた結果、コンテンツサーバＳｉとの接続に成功した場合（Ｓ１１３）、オーディオクライアントＣｊは切断直前のクライアントステータスをコンテンツサーバＳｉに送信する（Ｓ１３）。クライアントステータスは例えば、「再生」、「停止」、「ポーズ」等の再生状態や、音量情報、リスト構築キーなどを含む。よって、オーディオクライアントＣｊはコンテンツサーバＳｉとの接続状態をもとどおりに回復できる。その結果、ユーザはオーディオクライアントＣｊがコンテンツサーバＳｉと接続し直したことを意識せずにオーディオクライアントＣｊを利用できる。
一方、再接続を試みた結果、コンテンツサーバＳｉとの接続に失敗した場合（Ｓ１１３）、オーディオクライアントＣｊは同じコンテンツサーバＳｉとの接続回復を断念し、他のコンテンツサーバＳｉとの接続処理を実行する（Ｓ１１〜Ｓ１３）。具体的には、オーディオクライアントＣｊはブロードキャストにより接続可能なコンテンツサーバＳｉを探索し（Ｓ１１）、探索したコンテンツサーバＳｉに対して接続を行う（Ｓ１２）。接続後、オーディオクライアントＣｊは切断直前のクライアントステータスをコンテンツサーバＳｉに送信する（Ｓ１３）。
オーディオクライアントＣｊは、図１１５に示した接続回復プログラムをインストールすることにより、上述した自動接続回復機能を備える。
以上の動作により、オーディオクライアントＣｊから所定期間ごとに接続状態を確認し、切断されていればオーディオクライアントＣｊ自身が再接続を実行する。そのため、コンテンツサーバＳｉの異常により接続が切断されても、オーディオクライアントＣｊがコンテンツサーバＳｉから切断されたまま放置されることはない。また、接続していたコンテンツサーバＳｉの異常によりそのコンテンツサーバＳｉと再接続ができない場合でも、オーディオクライアントＣｊは他のコンテンツサーバＳｉと接続する。その結果、ユーザは常にコントローラＡｋを用いてオーディオクライアントＣｊを制御することができる。
また、オーディオクライアントＣｊは接続先のコンテンツサーバＳｉに切断直前のクライアントステータスを送信しているため、オーディオクライアントＣｊは他のコンテンツサーバＳｉに接続されても切断直前と同じ状態にできる。その結果、ユーザはオーディオクライアントＣｊがコンテンツサーバＳｉと切断されたことを意識することなく、オーディオクライアントＣｊを利用できる。
本実施の形態では、オーディオクライアントＣｊが自動接続回復機能を備えているが、コントローラＡｋが自動接続回復機能を備えていてもよい。また、音楽再生機能及び制御機能を併有する能動的なクライアントよりはむしろ、音楽再生機能だけを有する受動的なクライアントが自動接続回復機能を備えているのが好ましい。制御機能を有さない受動的なオーディオクライアントＣｊは自らコンテンツサーバＳｉにコマンドを送信することがないため、一旦コンテンツサーバＳｉとの接続が切断されるとそのまま放置されてしまい、ユーザがそのオーディオクライアントＣｊを再起動しない限りコンテンツサーバＳｉとの接続を回復できないからである。
上述した全ての実施の形態における各ステップは、コンピュータに実行させるための動作プログラムを形成する。よって、この動作プログラムを、コンテンツサーバＳｉ、オーディオクライアント、コントローラ、及びＡＶＲクライアントにインストールすることにより、ネットワーク型オーディオシステムを構築することができる。また、この動作プログラムは、そのままインターネットなどの電気通信回線を通じて配信されてもよいが、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどのコンピュータ読み取り可能な記憶媒体に格納されて配布されてもよい。
以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。
本発明の実施の形態によるネットワーク型オーディオシステムの全体構成を示す機能ブロック図である。 図１中の各サーバの構成を示す機能ブロック図である。 図１中の各オーディオクライアントの構成を示す機能ブロック図である。 図１中の各コントローラの構成を示す機能ブロック図である。 図１〜図３に示したサーバ及びオーディオクライアントの初期接続フェーズにおける動作を示すフロー図である。 図５中のオーディオクライアントによるサーバ探索動作を示すフロー図である。 図５中のクライアント及びサーバによる接続動作を示すフロー図である。 図７に示した接続動作を終えたサーバによるプッシュ動作を示す図である。 図８に続いて、コントローラからサーバへのオーディオクライアントに対するサーバリクエスト動作を示す図である。 図９に続いて、オーディオクライアントからサーバを通じてコントローラにステータスを通知する動作を示す図である。 図５中のオーディオクライアントによるクライアント情報送信動作を示すフロー図である。 図１及び図２に示したサーバによる初期設定動作及びメイン動作を示すフロー図である。 図２に示したサーバに保存されるクライアント情報データベースを示す図である。 図２に示したサーバに保存されるコンテンツ情報データベースを示す図である。 図２に示したサーバに保存されるファームウェア情報データベースを示す図である。 図１２中のサーバ探索に対する応答のサブルーチンを示すフロー図である。 図１２中のコマンドポート接続受付処理のサブルーチンを示すフロー図である。 図１２中のプッシュポート接続受付処理（その１）のサブルーチンを示すフロー図である。 図１２中のプッシュポート接続受付処理（その２）のサブルーチンを示すフロー図である。 図１５中のコマンド処理のサブルーチンを示すフロー図である。 図２０中のステータス通知コマンド処理のサブルーチンを示すフロー図である。 図２０中のサーバリクエスト発行コマンド処理のサブルーチンを示すフロー図である。 図１〜図３に示したサーバ及びオーディオクライアントによる曲リスト取得及び再生動作を示すフロー図である。 図２３中のオーディオクライアントによる曲リスト取得動作を示すフロー図である。 図２４中のジャンルリスト及び曲リスト取得動作を示すフロー図である。 図２５で取得したジャンルリストを格納した領域を示す図である。 図１４に示したコンテンツ情報データベースのレコード構造を示す図である。 図２５中のサーバによるジャンルリスト作成動作を示すフロー図である。 図２５で取得した曲リストを格納した領域を示す図である。 図２５中のサーバによる曲リスト作成動作を示すフロー図である。 図２５中のリスト要求コマンドのフォーマットを示す図である。 図２５中の検索データのフォーマットを示す図である。 図２５中の曲リスト取得動作におけるバッファメモリの遷移状態を示す図である。 図２５に示したジャンルリスト及び曲リスト取得動作に加え、アルバムリスト取得動作を示すフロー図である。 図２３中のオーディオクライアントによる曲指定、再生及び停止、並びにサーバによる曲配信準備及び配信の動作を示すフロー図である。 図３５に続くフロー図である。 図３５中の曲情報要求コマンドを示す図である。 図３５中の曲情報を示す図である。 図３５中の曲再生準備コマンドを示す図である。 図３５中のエラーコードを示す図である。 図３５中の曲データ転送要求コマンドを示す図である。 図３５中の曲データを示す図である。 図４２に示した曲データを格納するためのバッファメモリの構成を示す図である。 図４３に示したバッファメモリにおいて、曲の先頭から１バッファ分の曲データを格納した状態を示す図である。 図４４に続き、全バッファ分の曲データを格納した状態を示す図である。 図４５に続き、先頭バッファから曲データを出力する状態を示す図である。 図４６に続き、１バッファ分の空きが生じた状態を示す図である。 図４７に続き、バッファの空きが埋まった状態を示す図である。 図１〜図３に示したクライアント及びサーバによる早送り再生動作を示すフロー図である。 図１〜図３に示したクライアント及びサーバによる一時停止動作を示すフロー図である。 図１中のコントローラによるサーバとの接続動作を示すフロー図である。 図５１中の監視ハンドル及び制御ハンドル取得動作を示すフロー図である。 サーバによる複数のオーディオクライアントから複数のコントローラへのステータス通知を示す図である。 図５４において、コントローラが監視ハンドルを取得した場合のステータス通知を示す図である。 図１中のコントローラによるオーディオクライアントのモニタ動作を示すフロー図である。 図５５に示したモニタ動作の詳細を示すフロー図である。 図１中のコントローラによるオーディオクライアントの制御動作を示すフロー図である。 図５７中のオーディオクライアントによる制御コマンド処理動作のサブルーチンを示すフロー図である。 図５８中の再生制御動作のサブルーチンを示す図である。 図１３に示したクライアント情報データベースに含まれるクライアントタイプの詳細を示す図である。 図５９に示した再生制御における曲リスト表示処理動作を示すフロー図である。 図６１中の曲リスト表示において、ＭＰ３及びＷＡＶの両方を再生可能なオーディオクライアントに関する曲リストの表示画面を示す図である。 図６１中の曲リスト表示において、ＭＰ３は再生可能であるが、ＷＡＶは再生不可能なオーディオクライアントに関する曲リストの表示画面を示す図である。 図５９に示した再生制御においてユーザからの再生命令処理動作を示すフロー図である。 図１中のコントローラによる連続再生制御において、再生コマンドの送信を示す図である。 図６５に続き、完了及び停止ステータスの送信を示す図である。 図６６に示した完了及び停止ステータスの送信動作を示すフロー図である。 図６６に続き、再生コマンドの送信を示す図である。 図６５〜図６８に示した連続再生制御で用いられるリスト構築キーの構成を示す図である。 図６９に示したリスト構築キーに含まれるフィルタの種類を示す図である。 図６９に示したリスト構築キーを用いた連続再生制御動作を示すシーケンス図である。 図５６及び図７１に示したコントローラによる完了処理動作を示すフロー図である。 優先順位を付けた連続再生処理の動作を示すフロー図である。 図７３に示した連続再生処理を示す機能ブロック図である。 図７３に示した連続再生処理において、優先順位が最高のコントローラが切断された場合の連続再生処理を示す機能ブロック図である。 制御ハンドルを利用した連続再生処理の動作を示すフロー図である。 図７６に示した連続再生処理を示す機能ブロック図である。 コンテンツサーバによる連続再生処理を示す機能ブロック図である。 図７８に示した連続再生処理の動作を示すフロー図である。 図７８に示した連続再生処理において、オーディオクライアントが複数ある場合の連続再生処理を示す機能ブロック図である。 図８０に示した連続再生処理において、コンテンツサーバも複数ある場合の連続再生処理を示す機能ブロック図である。 図８１に示した連続再生処理において、コンテンツサーバが切り換えられた場合の連続再生処理を示す機能ブロック図である。 図８１に示した連続再生処理において、コントローラも複数ある場合の連続再生処理を示す機能ブロック図である。 オーディオクライアント自身による連続再生処理の動作を示すフロー図である。 再生命令管理テーブルを利用した連続再生処理の動作を示すフロー図である。 図８５に示した連続再生処理を示す機能ブロック図である。 図８５中の再生命令管理処理の詳細を示すフロー図である。 図８５に示した連続再生処理において、コンテンツサーバが切り換えられた場合の連続再生処理を示す機能ブロック図である。 図８５中のサーバ切換処理の詳細を示すフロー図である。 サーバ、コントローラ、ＡＶＲクライアント、及びＡＶレシーバを含むネットワーク型オーディオシステムの構成を示す機能ブロック図である。 図９０に示したネットワーク型オーディオシステムにおいて、ステータス及びコマンドの流れを示す機能ブロック図である。 図９０及び図９１に示したネットワーク型オーディオシステムにおいて、コントローラによるＡＶレシーバの制御動作を示すフロー図である。 図９０に示したネットワーク型オーディオシステムにおいて、制御コマンド及びステータスの伝達経路を示す機能ブロック図である。 図９３に示したコマンド及びステータスの伝達動作を示すフロー図である。 図９４に示した各段階における制御コマンドを示す図である。 図９４に示した各段階におけるステータスを示す図である。 図９０〜図９６に示したネットワーク型オーディオシステムにおいて、コントローラがＡＶＲクライアントを通じてＡＶレシーバＡＶＲのボリュームを上げる動作を示すフロー図である。 図９０〜図９６に示したネットワーク型オーディオシステムにおいて、ＡＶレシーバのステータスをサーバに転送する場合におけるＡＶＲクライアントの動作を示すフロー図である。 図９０〜図９６に示したネットワーク型オーディオシステムにおいて、サーバからの制御コマンドをＡＶレシーバに転送する場合におけるＡＶＲクライアントの動作を示すフロー図である。 図９９に示した動作の改良例を示すフロー図である。 図１中のクライアント及びサーバによるファームウェアアップデート動作を示すフロー図である。 図１０１に示したファームウェアアップデート動作の詳細を示すフロー図である。 図１０２中のファームウェアリスト作成動作を示すフロー図である。 図１０２中のファームウェアリストの送信動作を示すフロー図である。 本発明の他の実施の形態によるオーディオクライアントの外観構成を示す正面図である。 図１０５に示したオーディオクライアントの側面図である。 本発明の他の実施の形態によるネットワーク型オーディオシステム及びインターネットの全体構成を示す機能ブロック図である。 図１０７に示したネットワーク型オーディオシステムにおけるサーバ探索動作を示すフロー図である。 本発明の他の実施の形態による曲データの転送動作を示すフロー図である。 図１０９中のＳ１６０２１，Ｓ１６０６１で参照される対比テーブルを示す図である。 本発明の他の実施の形態によるオーディオクライアントのスキップ再生動作を示すフロー図である。 図１１１に示したスキップ再生動作において、オーディオクライアントのメモリに格納された曲リストを示す図である。 本発明の他の実施の形態によるオーディオクライアントのリピート再生動作を示すフロー図である。 本発明の他の実施の形態によるオーディオクライアントの途中再生動作を示すフロー図である。 本発明の他の実施の形態によるオーディオクライアントの監視処理及び接続回復処理を示すフロー図である。

Claims (3)

  1. サーバと、前記サーバに接続された少なくとも１つのクライアントとを備えたネットワーク型コンテンツ再生システムであって、
    前記サーバは、
    複数のコンテンツを蓄積する蓄積手段と、
    前記複数のコンテンツの中から選択されたコンテンツを前記クライアントに送信するコンテンツ送信手段と、
    各々がファームウェアの適用可能なクライアントのタイプを示すプロダクトＩＤを含む複数のファームウェアの情報を記憶するファームウェア情報記憶手段とを含み、
    前記クライアントは、
    前記サーバから送信されたコンテンツを再生する再生手段と、
    自身のプロダクトＩＤと、前記サーバから取得しようとする最初のファームウェアの情報を示す取得開始インデックスと、前記サーバから取得しようとするファームウェアの情報の数を示す取得個数とを含むファームウェアリスト要求コマンドを送信することにより、複数のファームウェアの情報を列挙したファームウェアリストの送信を前記サーバに要求するファームウェアリスト要求手段を含み、
    前記サーバはさらに、
    前記クライアントからのファームウェアリスト要求コマンドに応答して、前記ファームウェアリスト要求コマンドに含まれるプロダクトＩＤと同じプロダクトＩＤを含むファームウェアの情報を前記ファームウェア情報記憶手段から読み出し、前記ファームウェアリスト要求コマンドに含まれる取得開始インデックスが示す最初のファームウェアの情報から前記ファームウェアリスト要求コマンドに含まれる取得個数分のファームウェアの情報を含むファームウェアリストを作成し、前記クライアントに送信するファームウェアリスト送信手段とを含み、
    前記クライアントはさらに、
    前記サーバから送信されたファームウェアリストを受信する手段と、
    前記受信されたファームウェアリストの中から選択されたファームウェアの送信を前記サーバに要求するファームウェア要求手段とを含み、
    前記サーバはさらに、
    前記クライアントからの要求に応じて前記選択されたファームウェアを前記クライアントに返信して前記クライアントのファームウェアを更新するファームウェア更新手段を含むことを特徴とするネットワーク型コンテンツ再生システム。
  2. クライアントに接続可能なサーバであって、
    複数のコンテンツを蓄積する蓄積手段と、
    前記複数のコンテンツの中から選択されたコンテンツを前記クライアントに送信するコンテンツ送信手段と、
    各々がファームウェアの適用可能なクライアントのタイプを示すプロダクトＩＤを含む複数のファームウェアの情報を記憶するファームウェア情報記憶手段と、
    前記クライアントから送信された、前記クライアントのプロダクトＩＤと、前記クライアントが前記サーバから取得しようとする最初のファームウェアの情報を示す取得開始インデックスと、前記クライアントが前記サーバから取得しようとするファームウェアの情報の数を示す取得個数とを含むファームウェアリスト要求コマンドに応答して、前記ファームウェアリスト要求コマンドに含まれるプロダクトＩＤと同じプロダクトＩＤを含むファームウェアの情報を前記ファームウェア情報記憶手段から読み出し、前記ファームウェアリスト要求コマンドに含まれる取得開始インデックスが示す最初のファームウェアの情報から前記ファームウェアリスト要求コマンドに含まれる取得個数分のファームウェアの情報を列挙したファームウェアリストを作成し、前記クライアントに送信するファームウェアリスト送信手段と、
    前記クライアントからの要求に応じて前記ファームウェアリストの中から選択されたファームウェアを前記クライアントに返信して前記クライアントのファームウェアを更新するファームウェア更新手段とを含むことを特徴とするサーバ。
  3. クライアントに接続可能なサーバに実行させるためのサーバ用プログラムであって、
    複数のコンテンツを蓄積手段に蓄積するステップと、
    前記複数のコンテンツの中から選択されたコンテンツを前記クライアントに送信するコンテンツ送信ステップと、
    各々がファームウェアの適用可能なクライアントのタイプを示すプロダクトＩＤを含む複数のファームウェアの情報をファームウェア情報記憶手段に記憶するステップと、
    前記クライアントから送信された、前記クライアントのプロダクトＩＤと、前記クライアントが前記サーバから取得しようとする最初のファームウェアの情報を示す取得開始インデックスと、前記クライアントが前記サーバから取得しようとするファームウェアの情報の数を示す取得個数とを含むファームウェアリスト要求コマンドに応答して、前記ファームウェアリスト要求コマンドに含まれるプロダクトＩＤと同じプロダクトＩＤを含むファームウェアの情報を前記ファームウェア情報記憶手段から読み出し、前記ファームウェアリスト要求コマンドに含まれる取得開始インデックスが示す最初のファームウェアの情報から前記ファームウェアリスト要求コマンドに含まれる取得個数分のファームウェアの情報を列挙したファームウェアリストを作成し、前記クライアントに送信するファームウェアリスト送信ステップと、
    前記クライアントからの要求に応じて前記ファームウェアリストの中から選択されたファームウェアを前記クライアントに返信して前記クライアントのファームウェアを更新するファームウェア更新ステップとを前記サーバに実行させるためのサーバ用プログラム。
JP2004328958A 2002-05-31 2004-11-12 ネットワーク型コンテンツ再生システム Expired - Fee Related JP4013942B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2004328958A JP4013942B2 (ja) 2002-05-31 2004-11-12 ネットワーク型コンテンツ再生システム

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
JP2002158753 2002-05-31
JP2002158753 2002-05-31
JP2002232749 2002-08-09
JP2002232749 2002-08-09
JP2003017931 2003-01-27
JP2003045432 2003-02-24
JP2003045432 2003-02-24
JP2004328958A JP4013942B2 (ja) 2002-05-31 2004-11-12 ネットワーク型コンテンツ再生システム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2004509922A Division JP4013949B2 (ja) 2002-05-31 2003-05-26 ネットワーク型コンテンツ再生システム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2006320287A Division JP4812604B2 (ja) 2002-05-31 2006-11-28 ネットワーク型コンテンツ再生システム

Publications (4)

Publication Number Publication Date
JP2005182763A JP2005182763A (ja) 2005-07-07
JP2005182763A5 JP2005182763A5 (ja) 2006-07-06
JP2005182763A6 JP2005182763A6 (ja) 2006-09-07
JP4013942B2 true JP4013942B2 (ja) 2007-11-28

Family

ID=34792660

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004328958A Expired - Fee Related JP4013942B2 (ja) 2002-05-31 2004-11-12 ネットワーク型コンテンツ再生システム

Country Status (1)

Country Link
JP (1) JP4013942B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4677839B2 (ja) * 2005-07-12 2011-04-27 株式会社ケンウッド 再生装置、復号化ソフトウェア配信サーバ、コンテンツ配信サーバ、復号化ソフトウェア配信システム、コンテンツ再生方法及び復号化ソフトウェア配信方法
JP4775843B2 (ja) * 2005-08-10 2011-09-21 株式会社日立製作所 ストレージシステム及び記憶制御方法
JP2016118610A (ja) * 2014-12-19 2016-06-30 ティアック株式会社 無線ｌａｎ機能を備えた再生装置及び共聴システム

Also Published As

Publication number Publication date
JP2005182763A (ja) 2005-07-07

Similar Documents

Publication Publication Date Title
JP5673588B2 (ja) ネットワーク型コンテンツ再生システム
JP3847764B2 (ja) ネットワーク型コンテンツ再生システム
RU2460119C2 (ru) Программируемый мультимедийный контроллер с программируемыми функциями
JP4889749B2 (ja) マルチメディア情報制御装置及び方法
US8572034B2 (en) Method of managing a distributed storage system
JP4812604B2 (ja) ネットワーク型コンテンツ再生システム
JP4155260B2 (ja) ネットワーク型コンテンツ再生システム
JP2005189827A6 (ja) ネットワーク型コンテンツ再生システム
JP4013942B2 (ja) ネットワーク型コンテンツ再生システム
JP2005182762A (ja) ネットワーク型コンテンツ再生システム
JP2005182763A6 (ja) ネットワーク型コンテンツ再生システム
JP4281792B2 (ja) ネットワーク型コンテンツ再生システム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060516

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20060516

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20060802

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061003

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20061128

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070320

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070518

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070821

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070903

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100921

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 4013942

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100921

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130921

Year of fee payment: 6

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees