"サーバと、前記サーバに接続された少なくとも1つのクライアントとを備えたネットワーク型コンテンツ再生システムであって、前記サーバは、複数のコンテンツを蓄積する蓄積手段と、前記複数のコンテンツの中から選択されたコンテンツを前記クライアントに送信するコンテンツ送信手段とを含み、前記クライアントは、前記サーバから送信されたコンテンツを再生する再生手段を含み、前記サーバはさらに、前記クライアントのファームウェアを更新するファームウェア更新手段と、前記クライアントに適した複数のファームウェアの情報を登録する手段と、前記登録された複数のファームウェアの情報を列挙したファームウェアリストを前記クライアントに送信するファームウェアリスト送信手段とを含み、前記クライアントはさらに、前記サーバから送信されたファームウェアリストを受信する手段と、前記受信されたファームウェアリストの中から選択されたファームウェアの送信を前記サーバに要求するファームウェア要求手段とを含み、前記ファームウェア更新手段は、前記クライアントからの要求に応じて前記選択されたファームウェアを前記クライアントに返信することを特徴とするネットワーク型コンテンツ再生システム。請求項1に記載のネットワーク型コンテンツ再生システムであって、前記クライアントはさらに、自身に関するクライアント情報を前記サーバに送信する手段を含み、前記サーバはさらに、前記クライアントから送信されたクライアント情報に基づいて前記ファームウェアリストを作成する手段を含むことを特徴とするネットワーク型コンテンツ再生システム。請求項1又は請求項2に記載のネットワーク型コンテンツ再生システムであって、前記クライアントはさらに、指定量のファームウェアリストを前記サーバに要求するファームウェアリスト要求手段を含み、前記ファームウェアリスト送信手段は、前記クライアントからの要求に応じて前記指定量のファームウェアリストを前記クライアントに送信することを特徴とするネットワーク型コンテンツ再生システム。請求項3に記載のネットワーク型コンテンツ再生システムであって、前記ファームウェアリスト要求手段は、前記クライアントが前記サーバから取得しようとする最初のファームウェアの情報を示す取得開始インデックスと、前記クライアントが前記サーバから取得しようとするファームウェアの情報の数を示す取得個数とを含むファームウェアリスト要求コマンドを送信し、前記ファームウェアリスト送信手段は、前記ファームウェアリスト要求コマンドに応答して、前記取得開始インデックスが示す最初のファームウェアの情報から前記取得個数分のファームウェアの情報を含むファームウェアリストを送信することを特徴とするネットワーク型コンテンツ再生システム。サーバと、前記サーバに接続された少なくとも1つのクライアントとを備えたネットワーク型コンテンツ再生システムであって、前記サーバは、複数のコンテンツを蓄積する蓄積手段と、前記複数のコンテンツの中から選択されたコンテンツを前記クライアントに送信するコンテンツ送信手段とを含み、前記クライアントは、前記サーバから送信されたコンテンツを再生する再生手段を含み、前記サーバはさらに、前記クライアントのファームウェアを更新するファームウェア更新手段を含み、前記クライアントはさらに、指定量のファームウェアを前記サーバに要求するファームウェア要求手段を含み、前記ファームウェア更新手段は、前記クライアントからの要求に応じて前記指定量のファームウェアを返信することを特徴とするネットワーク型コンテンツ再生システム。請求項5に記載のネットワーク型コンテンツ再生システムであって、前記ファームウェア要求手段は、前記クライアントが前記サーバから取得しようとするファームウェアが格納されている最初のアドレスを示す取得開始アドレスと、前記クライアントが前記サーバから取得しようとするファームウェアの長さを示す取得データ長とを送信し、前記ファームウェア更新手段は、前記クライアントからの要求に応じて、前記取得開始アドレスから前記取得データ長分のファームウェアを返信することを特徴とするネットワーク型コンテンツ再生システム。サーバと、前記サーバに接続された少なくとも1つのクライアントとを備えたネットワーク型コンテンツ再生システムであって、前記サーバは、複数のコンテンツを蓄積する蓄積手段と、前記複数のコンテンツの中から選択されたコンテンツを前記クライアントに送信するコンテンツ送信手段とを含み、前記クライアントは、前記サーバから送信されたコンテンツを再生する再生手段を含み、前記サーバはさらに、前記クライアントのファームウェアを更新するファームウェア更新手段と、前記クライアントにファームウェアを更新するように要求し、そのファームウェアに関する情報を前記クライアントに送信する手段とを含むことを特徴とするネットワーク型コンテンツ再生システム。サーバと、前記サーバに接続された少なくとも1つの第1のクライアントとを備えたネットワーク型コンテンツ再生システムであって、前記サーバは、複数のコンテンツを蓄積する蓄積手段と、前記複数のコンテンツの中から選択されたコンテンツを前記第1のクライアントに送信するコンテンツ送信手段とを含み、前記第1のクライアントは、前記サーバから送信されたコンテンツを再生する再生手段を含み、前記サーバはさらに、前記第1のクライアントのファームウェアを更新するファームウェア更新手段を含み、前記ネットワーク型コンテンツ再生システムはさらに、前記サーバに接続され、前記第1のクライアントを制御する第2のクライアントを備え、前記第2のクライアントは、前記第1のクライアントのファームウェアを更新するよう前記サーバに要求する手段を含むことを特徴とするネットワーク型コンテンツ再生システム。請求項1~請求項8のいずれか1項に記載のネットワーク型コンテンツ再生システムに使用されるサーバ。請求項1~請求項8のいずれか1項に記載の手段としてサーバを機能させるためのサーバ用プログラム。請求項1~請求項8のいずれか1項に記載のネットワーク型コンテンツ再生システムに使用されるクライアント。請求項1~請求項8のいずれか1項に記載の手段としてクライアントを機能させるためのクライアント用プログラム。クライアントに接続可能なサーバであって、複数のコンテンツを蓄積する蓄積手段と、前記複数のコンテンツの中から選択されたコンテンツを前記クライアントに送信するコンテンツ送信手段と、前記クライアントのファームウェアを更新するファームウェア更新手段と、前記クライアントに適した複数のファームウェアの情報を登録する手段と、前記登録された複数のファームウェアの情報を列挙したファームウェアリストを前記クライアントに送信するファームウェアリスト送信手段とを含み、前記ファームウェア更新手段は、前記クライアントからの要求に応じて前記ファームウェアリストの中から選択されたファームウェアを前記クライアントに返信することを特徴とするサーバ。請求項13に記載のサーバであってさらに、前記クライアントから送信された前記クライアントに関するクライアント情報に基づいて前記ファームウェアリストを作成する手段を含むことを特徴とするサーバ。請求項13又は請求項14に記載のサーバであって、前記ファームウェアリスト送信手段は、前記クライアントにより要求された指定量のファームウェアリストを前記クライアントに送信することを特徴とするサーバ。請求項15に記載のサーバであって、前記ファームウェアリスト送信手段は、前記クライアントが前記サーバから取得しようとする最初のファームウェア情報を示す取得開始インデックスと、前記クライアントが前記サーバから取得しようとするファームウェアの情報の数を示す取得個数とを含む、前記クライアントからのファームウェアリスト要求コマンドに応答して、前記取得開始インデックスが示す最初のファームウェア情報から前記取得個数分のファームウェア情報を含むファームウェアリストを前記クライアントに送信することを特徴とするサーバ。クライアントに接続可能なサーバであって、複数のコンテンツを蓄積する蓄積手段と、前記複数のコンテンツの中から選択されたコンテンツを前記クライアントに送信するコンテンツ送信手段と、前記クライアントのファームウェアを更新するファームウェア更新手段とを含み、前記ファームウェア更新手段は、前記クライアントにより要求された指定量のファームウェアを前記クライアントに送信することを特徴とするサーバ。請求項17に記載のサーバであって、前記ファームウェア更新手段は、前記クライアントが取得しようとするファームウェアが格納されている最初のアドレスを示す取得開始アドレスから前記クライアントが取得しようとするファームウェアの長さを示す取得データ長分のファームウェアを返信することを特徴とするサーバ。クライアントに接続可能なサーバに実行させるためのサーバ用プログラムであって、複数のコンテンツを蓄積手段に蓄積するステップと、前記複数のコンテンツの中から選択されたコンテンツを前記クライアントに送信するコンテンツ送信ステップと、前記クライアントのファームウェアを更新するファームウェア更新ステップと、前記クライアントに適した複数のファームウェアの情報を登録するステップと、前記登録された複数のファームウェアの情報を列挙したファームウェアリストを前記クライアントに送信するファームウェアリスト送信ステップとをサーバに実行させ、前記ファームウェア更新ステップは、前記クライアントからの要求に応じて前記ファームウェアリストの中から選択されたファームウェアを前記クライアントに返信することを特徴とするサーバ用プログラム。請求項19に記載のサーバ用プログラムであってさらに、前記クライアントから送信された前記クライアントに関するクライアント情報に基づいて前記ファームウェアリストを作成するステップをサーバに実行させるためのサーバ用プログラム。クライアントに接続可能なサーバに実行させるためのサーバ用プログラムであって、複数のコンテンツを蓄積手段に蓄積するステップと、前記複数のコンテンツの中から選択されたコンテンツを前記クライアントに送信するコンテンツ送信ステップと、前記クライアントのファームウェアを更新するファームウェア更新ステップとをサーバに実行させ、前記ファームウェア更新ステップは、前記クライアントにより要求された指定量のファームウェアを前記クライアントに送信することを特徴とするサーバ用プログラム。サーバに接続可能なクライアントであって、前記サーバから送信されたコンテンツを再生する再生手段と、前記サーバから送信されたファームウェアリストを受信する手段と、前記受信されたファームウェアリストの中からファームウェアを選択し、そのファームウエアの送信を要求するファームウェア要求手段とを含むことを特徴とするクライアント。請求項22に記載のクライアントであってさらに、自身に関するクライアント情報を前記サーバに送信する手段を含むことを特徴とするクライアント。請求項22又は請求項23に記載のクライアントであってさらに、指定量のファームウェアリストを前記サーバに要求するファームウェアリスト要求手段を含むことを特徴とするクライアント。請求項24に記載のクライアントであって、前記ファームウェアリスト要求手段は、前記サーバから取得しようとする最初のファームウェアの情報を示す取得開始インデックスと、前記サーバから取得しようとするファームウェアの情報の数を示す取得個数とを含むファームウェアリスト要求コマンドを送信することを特徴とするクライアント。サーバに接続可能なクライアントであって、前記サーバから送信されたコンテンツを再生する再生手段と、指定量のファームウェアの送信を前記サーバに要求するファームウェア要求手段とを含むことを特徴とするクライアント。請求項26に記載のクライアントであって、前記ファームウェア要求手段は、前記サーバから取得しようとするファームウェアが格納されている最初のアドレスを示す取得開始アドレスと、前記サーバから取得しようとするファームウェアの長さを示す取得データ長とを送信することを特徴とするクライアント。サーバに接続可能なクライアントに実行させるためのクライアント用プログラムであって、前記サーバから送信されたコンテンツを再生する再生ステップと、前記サーバから送信されたファームウェアリストを受信するステップと、前記受信されたファームウェアリストの中からファームウェアを選択し、そのファームウエアの送信を要求するファームウェア要求ステップとをクライアントに実行させるためのクライアント用プログラム。請求項28に記載のクライアント用プログラムであってさらに、自身に関するクライアント情報を前記サーバに送信するステップをクライアントに実行させるためのクライアント用プログラム。サーバに接続可能なクライアントに実行させるためのクライアント用プログラムであって、前記サーバから送信されたコンテンツを再生する再生ステップと、指定量のファームウェアの送信を前記サーバに要求するファームウェア要求ステップとをクライアントに実行させるためのクライアント用プログラム。本発明の1つの目的は、サーバに蓄積された音声や映像などのコンテンツをクライアントが自由に選択して再生することの可能なネットワーク型コンテンツ再生システムを提供することである。本発明のもう1つの目的は、クライアントが未だ受信していないデータについても、途中から再生するなど、ユーザが自在に再生することの可能なネットワーク型コンテンツ再生システムを提供することである。本発明のさらにもう1つの目的は、クライアントサーバ環境下においてクライアントによるコンテンツの連続再生を可能にしたネットワーク型コンテンツ再生システムを提供することである。本発明のさらにもう1つの目的は、クライアントへの連続再生命令の競合を排除したネットワーク型コンテンツ再生システムを提供することである。本発明のさらにもう1つの目的は、サーバとの接続が切断されても迅速に接続を回復することができる自動接続回復機能付きクライアントを提供することである。本発明によるネットワーク型コンテンツ再生システムは、サーバと、サーバに接続された少なくとも1つの第1のクライアントとを備える。サーバは、複数のコンテンツ音楽コンテンツ、映像コンテンツなどを蓄積する蓄積手段を含む。第1のクライアントは、複数のコンテンツの中から選択されたコンテンツをサーバに要求するコンテンツ要求手段を含む。サーバはさらに、第1のクライアントからの要求に応じて選択されたコンテンツを第1のクライアントに返信するコンテンツ返信手段を含む。第1のクライアントはさらに、サーバから返信されたコンテンツを再生する再生手段を含む。本ネットワーク型コンテンツ再生システムでは、サーバに蓄積された多数のコンテンツの中から所望のコンテンツがクライアントの要求に応じて選択される。選択されたコンテンツはサーバからクライアントに送信され、そのコンテンツが再生される。そのため、サーバに蓄積された複数のコンテンツをクライアントが自由に選択して再生することができる。上記コンテンツが音楽コンテンツの場合、サーバに蓄積された多数の曲の中から所望の曲が第1のクライアントの要求に応じて選択される。選択された曲のデータはサーバから第1のクライアントに送信され、そのデータに基づいて選択された曲が再生される。そのため、サーバに蓄積された複数の曲を第1のクライアントが自由に選択して再生することができる。好ましくは、第1のクライアントは、壁に埋設されるコンセントボックスに取り付けられる。この場合、ユーザは部屋の内部に第1のクライアントを設置しなくても、その部屋で音楽を聴いたり、映像を見たりすることができる。好ましくは、第1のクライアントはさらに、複数のコンテンツを列挙したコンテンツリストをサーバに要求するコンテンツリスト要求手段を含む。サーバはさらに、第1のクライアントからの要求に応じてコンテンツリストを返信するコンテンツリスト返信手段を含む。第1のクライアントはさらに、サーバから返信されたコンテンツリストを受信するコンテンツリスト受信手段を含む。コンテンツ要求手段は、要求すべきコンテンツをコンテンツリストの中から選択する。この場合、第1のクライアントは、サーバからコンテンツリストを取得し、その中から所望のコンテンツを選択して再生することができる。さらに好ましくは、コンテンツリスト要求手段は、指定量のコンテンツリスト、好ましくはコンテンツリストの一部をサーバに要求する。コンテンツリスト返信手段は、第1のクライアントからの要求に応じて、指定量のコンテンツリスト、好ましくはコンテンツリストの一部を返信する。この場合、コンテンツリストの一部しかサーバから第1のクライアントに送信されないので、第1のクライアントにおいてコンテンツリストを記憶しておくために必要なメモリ容量を小さくすることができる。さらに好ましくは、コンテンツリスト要求手段は、第1のクライアントがサーバから取得しようとする最初のコンテンツを示す取得開始インデックスと、第1のクライアントがサーバから取得しようとするコンテンツの数を示す取得個数とを含むリスト要求コマンドを送信する。コンテンツリスト返信手段は、リスト要求コマンドに応答して、取得開始インデックスが示す最初のコンテンツから取得個数分のコンテンツを含むコンテンツリストを返信する。さらに好ましくは、コンテンツリスト返信手段はさらに、返信するコンテンツリストに含まれるコンテンツ数と、コンテンツリスト以降の残りのコンテンツ数とを返信する。この場合、第1のクライアントは、未だ取得していないコンテンツリストの残りのコンテンツ数を認識することができるので、残りのコンテンツリストをサーバに要求することができる。好ましくは、第1のクライアントはさらに、複数のカテゴリを列挙したカテゴリリストをサーバに要求するカテゴリリスト要求手段を含む。サーバはさらに、第1のクライアントからの要求に応じてカテゴリリストを返信する手段を含む。第1のクライアントはさらに、サーバから返信されたカテゴリリストを受信する手段を含む。コンテンツリスト要求手段は、要求しようとするコンテンツリストのコンテンツが属するカテゴリを受信されたカテゴリリストの中から選択する。この場合、第1のクライアントは、サーバから最初にカテゴリリストを取得し、その中から所望のカテゴリを選択する。引き続き、第1のクライアントは、サーバからコンテンツリストを取得し、その中から所望のコンテンツを選択する。よって、多数のコンテンツの中から所望のコンテンツを徐々に絞り込んで選択することができる。好ましくは、コンテンツリスト要求手段は、コンテンツリストを作成するために必要なリスト構築キーをサーバに送信する。コンテンツリスト返信手段は、リスト構築キーに基づいてコンテンツリストを作成する。この場合、第1のクライアントは、コンテンツリストが必要なときにリスト構築キーをサーバに送信すればコンテンツリストを取得することができるので、取得したコンテンツリストを記憶しておく必要はない。好ましくは、コンテンツ要求手段は、予め定められた量のコンテンツをサーバに要求する。コンテンツ返信手段は、第1のクライアントからの要求に応じて、予め定められた量のコンテンツを返信する。コンテンツ要求手段は、コンテンツの全部を取得するまでコンテンツの要求を繰り返す。この場合、コンテンツの一部しかサーバから第1のクライアントに送信されないので、第1のクライアントにおいてコンテンツを記憶しておくために必要なメモリ容量を小さくすることができる。さらに好ましくは、コンテンツ要求手段は、予め定められた量のコンテンツの最初のアドレスを示す取得開始アドレスを算出してサーバに送信する。コンテンツ返信手段は、第1のクライアントから送信された取得開始アドレスから予め定められた量のコンテンツを返信する。さらに好ましくは、コンテンツ要求手段は、取得開始アドレスと、第1のクライアントがサーバから取得しようとするコンテンツの長さを示す取得データ長とを含むコンテンツ転送要求コマンドを送信する。コンテンツ返信手段は、コンテンツ転送要求コマンドに応答して、取得開始アドレスから取得データ長分のコンテンツを返信する。この場合、取得開始アドレスを任意に設定することによって、クライアントが未受信のコンテンツについても特殊再生をすることができる。さらに好ましくは、コンテンツ要求手段は、取得データ長を前の取得開始アドレスに加算して次の取得開始アドレスを算出する。さらに好ましくは、第1のクライアントはさらに、ユーザの操作に応じて第1及び第2のアドレスを設定する手段と、算出された取得開始アドレスが第2のアドレスを超えたとき、取得開始アドレスを第1のアドレスに設定する手段とを含む。この場合、第1のクライアントは第1のアドレスから第2のアドレスまでのコンテンツを繰り返し取得して再生することができる。あるいは、第1のクライアントはさらに、ユーザの操作に応じて所望のアドレスを設定する手段と、取得開始アドレスを所望のアドレスに設定する手段とを含む。この場合、第1のクライアントは所望のアドレスからコンテンツを取得して途中から再生することができる。好ましくは、第1のクライアントはさらに、ユーザの操作に応じて所定のスキップ量を設定する手段と、取得開始アドレスを設定されたスキップ量だけシフトする手段とを含む。この場合、第1のクライアントは、サーバからコンテンツを非連続的に取得し、これにより早送り再生や早戻し再生を行うことができる。好ましくは、第1のクライアントはさらに、選択されたコンテンツの識別情報をサーバに送信する手段を含む。サーバはさらに、第1のクライアントから送信された識別情報に応答して選択されたコンテンツのオフセットを第1のクライアントに返信する手段を含む。第1のクライアントはさらに、サーバから返信されたオフセットに基づいて選択されたコンテンツの始まりを検知する手段を含む。この場合、第1のクライアントは、サーバから送信されたコンテンツのオフセットに基づいてコンテンツの始まりを検知するので、コンテンツを直ちに再生することができる。好ましくは、第1のクライアントはさらに、選択されたコンテンツの識別情報をサーバに送信する手段を含む。サーバはさらに、第1のクライアントから送信された識別情報に応答して選択されたコンテンツのサイズを第1のクライアントに返信する手段を含む。第1のクライアントはさらに、サーバから返信されたサイズに基づいて選択されたコンテンツの終わりを検知する手段を含む。この場合、第1のクライアントは、サーバから送信されたコンテンツのサイズに基づいてコンテンツの終わりを検知するので、コンテンツの再生を直ちに終了することができる。好ましくは、コンテンツ要求手段は、指定量のコンテンツをサーバに要求する。コンテンツ返信手段は、第1のクライアントからの要求に応じて指定量のコンテンツを返信する。コンテンツ要求手段は、サーバに要求するコンテンツの指定量を変化させる。この場合、第1のクライアントは、サーバの負荷が大きいときはコンテンツの指定量を少なくし、サーバの負荷が小さいときはコンテンツの指定量を多くするなど、サーバの負荷に応じて取得するコンテンツの量を適切に調整することができる。さらに、サーバはクライアントが指定した曲データの一部のみを返信するので、クライアントは、指定する曲データの一部を任意に変更することにより、クライアントが未受信のデータについても、特殊再生例えば、早送り、早戻し、途中からの再生等をすることができる。さらに、サーバは曲データの一部しか送信しないので、クライアントが受信を失敗した場合等には、その失敗した部分のみを再びサーバから受信すればよく、受信失敗時の処理を早くすることができる。さらに、クライアントが要求する曲のフォーマットが圧縮データMP3等であれば、データの指定量を小さくすることにより、サーバの負荷を軽減することができる。圧縮データは、再生時にデコードされることによって、データ量が大きくなるからである。好ましくは、第1のクライアントはさらに、自身に関するクライアント情報が変化するたびにそのクライアント情報をサーバに送信する手段を含む。この場合、クライアント情報は第1のクライアントからサーバに常に送信されるのではなく、変化があったときだけ送信される。そのため、サーバは、ネットワークトラフィックを増大させることなく、第1のクライアントの最新のクライアント情報を管理することができる。好ましくは、ネットワーク型コンテンツ再生システムはさらに、サーバとネットワークを通じて接続され、第1のクライアントを監視する第2のクライアントを備える。この場合、ユーザは、第1のクライアントと異なる第2のクライアントで第1のクライアントの動作状態などを知ることができる。さらに好ましくは、第1のクライアントはさらに、自身に関するクライアント情報をサーバに送信する手段を含む。サーバは、第1のクライアントから送信されたクライアント情報を受信する手段と、受信したクライアント情報を第2のクライアントに送信する手段とを含む。第2のクライアントは、サーバからのクライアント情報を受信する手段を含む。この場合、ユーザは、第1のクライアントと異なる第2のクライアントで第1のクライアントに関する情報、たとえば、サーバとの接続状態、クライアントタイプ、現在の動作状態、現在の音量などを知ることができる。好ましくは、サーバは、第2のクライアントに要求を強制的に送信するためのプッシュポートを通じて、クライアント情報を第2のクライアントに送信する。この場合、サーバは、第2のクライアントから要求がなくても、クライアント情報を第2のクライアントに送信することができる。好ましくは、第2のクライアントはさらに、受信したクライアント情報を表示する手段と、受信したクライアント情報が変更されているとき、そのクライアント情報の表示を変更する手段とを含む。好ましくは、第2のクライアントはさらに、複数のコンテンツを列挙したコンテンツリストをサーバに要求するコンテンツリスト要求手段を含む。サーバはさらに、第2のクライアントからの要求に応じてコンテンツリストを返信するコンテンツリスト返信手段を含む。第2のクライアントはさらに、サーバから返信されたコンテンツリストを受信するコンテンツリスト受信手段を含む。好ましくは、クライアント情報はコンテンツリストを作成するために必要なリスト構築キーを含む。コンテンツリスト要求手段は、受信されたクライアント情報に含まれるリスト構築キーが変更されているとき、そのリスト構築キーをサーバに送信する。コンテンツリスト返信手段は、第2のクライアントから送信されたリスト構築キーに基づいてコンテンツリストを作成する。好ましくは、第2のクライアントは、サーバに接続されたとき、サーバから送信されたクライアント情報を受信する。この場合、第2のクライアントは、電源が投入されると、サーバに接続されるので、サーバから第1のクライアントに関するクライアント情報を取得することができる。さらに好ましくは、クライアント情報はコンテンツリストを作成するために必要なリスト構築キーを含む。コンテンツリスト要求手段は、受信されたクライアント情報に含まれるリスト構築キーをサーバに送信する。コンテンツリスト返信手段は、第2のクライアントから送信されたリスト構築キーに基づいてコンテンツリストを作成する。この場合、第2のクライアントは、仮に第1のクライアントにコンテンツの再生を命令した後に電源が切られ、再生中のコンテンツリストを消失したとしても、電源の再投入時にリスト構築キーを取得する。したがって、第2のクライアントはこの取得したリスト構築キーをサーバに送信すれば、サーバから失ったコンテンツリストを再び取得することができる。好ましくは、クライアント情報は、第1のクライアントにより再生可能なコンテンツのデータフォーマットの名称を含む。第2のクライアントは、受信されたクライアント情報に基づいて第1のクライアントにより再生可能なコンテンツのデータフォーマットの名称を表示する手段を含む。この場合、ユーザは、第1のクライアントと異なる第2のクライアントで、第1のクライアントで再生可能なデータフォーマットを知ることができる。さらに好ましくは、第2のクライアントはさらに、複数のコンテンツを列挙したコンテンツリストをサーバから取得する手段と、取得したコンテンツリストに含まれるコンテンツのうち、第1のクライアントにより再生可能なコンテンツを表示し、第1のクライアントにより再生不可能なコンテンツを表示しないか又は再生可能なコンテンツと異なる態様で表示する手段とを含む。この場合、第1のクライアントで再生不可能なコンテンツは表示されないので、ユーザがそのコンテンツを選択するのを防止することができる。好ましくは、第2のクライアントは、監視しようとするクライアントが第1のクライアントかを判別する手段を含む。この場合、第2のクライアントが監視しようとするクライアントが第1のクライアントでなければ監視しようとしないので、誤動作を防止することができる。好ましくは、第2のクライアントは、第1のクライアントを監視するために必要な監視ハンドルを取得する手段と、監視ハンドルを取得したとき第1のクライアントを監視する手段とを含む。この場合、監視ハンドルを取得していない第2のクライアントは第1のクライアントを監視しないので、ネットワークトラフィックを低減することができる。好ましくは、ネットワーク型コンテンツ再生システムはさらに、サーバとネットワークを通じて接続され、第1のクライアントを制御する第2のクライアントを備える。さらに好ましくは、第2のクライアントは、第1のクライアントを制御するようにサーバに要求するサーバリクエスト手段を含む。サーバはさらに、第2のクライアントからの要求に応じて第1のクライアントを制御する手段を含む。この場合、ユーザは、第1のクライアントと異なる第2のクライアントからサーバを通じて第1のクライアントを制御することができる。好ましくは、サーバリクエスト手段は、第1のクライアントを特定するための情報と、選択されたコンテンツを特定するための情報とをサーバに送信する。この場合、ユーザは、所望のコンテンツを第1のクライアントに再生させることができる。好ましくは、第2のクライアントは、制御しようとするクライアントが第1のクライアントかを判別する手段を含む。この場合、第2のクライアントが制御しようとするクライアントが第1のクライアントでなければ制御しようとしないので、誤動作を防止することができる。好ましくは、第2のクライアントは、選択されたコンテンツのデータフォーマットが第1のクライアントにより再生可能なコンテンツのデータフォーマットに一致するか否かを判別する手段と、データフォーマットが一致する場合、選択されたコンテンツのデータに基づいてコンテンツを再生するように第1のクライアントに命令する手段とを含む。この場合、第2のクライアントは、第1のクライアントで再生可能なコンテンツに限り、コンテンツの再生を命令するので、誤動作を防止することができる。好ましくは、第2のクライアントは、第1のクライアントを制御するために必要な制御ハンドルを取得する手段と、制御ハンドルを取得したとき第1のクライアントを制御する手段とを含む。この場合、制御ハンドルを取得していない第2のクライアントは第1のクライアントを制御しないので、ネットワークトラフィックを低減することができる。好ましくは、第1のクライアントはさらに、第2のクライアントにより命令されたコンテンツを再生し終えた場合、完了ステータスをサーバに送信し、自らが選択したコンテンツを再生し終えた場合、又はユーザの操作に応じてコンテンツの途中で再生を終えた場合、完了ステータスと異なる停止ステータスをサーバに送信する手段を含む。この場合、サーバは、完了ステータスと停止ステータスとを区別することにより、第1のクライアントが第2のクライアントにより命令されたコンテンツを再生し終えたのか、それとも自らが選択したコンテンツを再生し終えたか又はユーザの操作に応じてコンテンツの途中で再生を終えたのかを判別することができる。好ましくは、サーバは、第1のクライアントから送信された完了ステータスを受信し、第2のクライアントに送信する手段を含む。第2のクライアントは、サーバから送信された完了ステータスに応答して、再生し終えたコンテンツの次のコンテンツを再生するように第1のクライアントに命令する手段を含む。この場合、コンテンツの再生を終えた第1のクライアントは、そのコンテンツの再生を命令した第2のクライアントに完了ステータスを送信するので、第2のクライアントはコンテンツリストに従って第1のクライアントにコンテンツを連続的に再生させることができる。好ましくは、ネットワーク型コンテンツ再生システムはさらに、サーバとネットワークを通じて接続され、第1のクライアントを制御する複数の第2のクライアントを備える。第2のクライアントの各々は、コンテンツを再生するように第1のクライアントに命令する再生命令手段を含む。第1のクライアントのコンテンツ再生手段は、第2のクライアントからの命令に従ってコンテンツを再生する。第1のクライアントはさらに、コンテンツを再生し終えたとき完了ステータスをサーバに送信する手段を含む。サーバは、第1のクライアントから送信された完了ステータスを受信し、複数の第2のクライアントのうち、第1のクライアントに命令した第2のクライアントに完了ステータスを送信し、当該他の第2のクライアントに停止ステータスを送信する手段を含む。第2のクライアントの再生命令手段は、サーバから送信された完了ステータスに応答して、再生し終えたコンテンツの次のコンテンツを再生するように第1のクライアントに命令する。この場合、コンテンツの再生を終えた第1のクライアントは、そのコンテンツの再生を命令した当該第2のクライアントにサーバを通じて完了ステータスを送信するので、当該第2のクライアントは正しく第1のクライアントに連続再生を命令する。一方、サーバは当該他の第2のクライアントに停止ステータスを送信するので、当該他の第2のクライアントは第1のクライアントは動作停止状態と認識し、誤って第1のクライアントに連続再生を命令することはない。好ましくは、第1のクライアントはさらに、所定情報をブロードキャストするブロードキャスト手段を含む。サーバは、第1のクライアントからブロードキャストされた所定情報に応答して、自身を特定するためのサーバ特定情報を第1のクライアントに返信する手段を含む。第1のクライアントは、サーバから返信されたサーバ特定情報を受信してサーバリストに登録する手段とを含む。本ネットワーク型コンテンツ再生システムでは、クライアントが所定情報をネットワークにブロードキャストし、ネットワークに接続されているサーバが存在すれば、そのサーバがサーバ特定情報IPアドレス、ポート番号などをそのクライアントに知らせる。そのため、クライアントはネットワーク上に存在するサーバを探し出すことができる。好ましくは、第1のクライアントはさらに、サーバリストにサーバ特定情報が登録されているか否かを判別する手段を含む。判別の結果、サーバリストにサーバ特定情報が登録されていない場合、ブロードキャスト手段は所定情報を再びブロードキャストする。この場合、第1のクライアントは、サーバリストに1つもサーバ特定情報が登録されていなければ再びサーバを探し始めるので、少なくとも1つサーバを見つけるまで探し続ける。好ましくは、第1のクライアントはさらに、ブロードキャスト手段によるブロードキャストの回数が所定回数に達したとき、又はブロードキャスト手段によるブロードキャストの時間が所定時間に達したとき、インターネット上のサーバにアクセスする手段を含む。この場合、第1のクライアントは、ローカルのネットワーク上にサーバが全く存在しない場合にサーバを探し続けることはなく、その場合はインターネット上のサーバを探し出すことができる。好ましくは、第1のクライアントは、サーバと第1のクライアントとの間でコマンドを送受信するためのコマンドポートで接続を確立する手段と、サーバから第1のクライアントに要求を強制的に送信するためのプッシュポートで接続を確立する手段とを含む。本ネットワーク型コンテンツ再生システムでは、コマンドやステータスはコマンドポートでサーバ及びクライアントの間で送受信される。また、サーバからのコマンドはプッシュポートを通じて強制的にクライアントに送信される。好ましくは、第1のクライアントはさらに、自身を識別するために必要なクライアントインデックスを要求するクライアントインデックス要求コマンドをコマンドポートを通じてサーバに送信する手段を含む。サーバはさらに、第1のクライアントから送信されたクライアントインデックス要求コマンドに応答してクライアントインデックスをクライアントに返信する手段を含む。第1のクライアントはさらに、サーバから返信されたクライアントインデックスをプッシュポートを通じてサーバに送信する手段を含む。好ましくは、第1のクライアントは複数ある。サーバは、接続可能なクライアントの数を制限する接続制限手段を含む。好ましくは、接続制限手段は、未接続のクライアントが接続を試みてきたとき、所定の優先順位に従って既接続のクライアントとの接続を断つ。本発明によるさらにもう1つのネットワーク型コンテンツ再生システムは、サーバと、サーバにネットワークを通じて接続された第1のクライアントと、第1のクライアントに接続されたAV機器と、サーバにネットワークを通じて接続され、AV機器を制御する第2のクライアントとを備える。第2のクライアントは、AV機器を制御するための制御コマンドをサーバに送信する手段を含む。サーバは、第2のクライアントから送信された制御コマンドを第1のクライアントに送信する手段を含む。第1のクライアントは、サーバから送信された制御コマンドをAV機器に送信する手段を含む。AV機器はさらに、第1のクライアントから送信された制御コマンドに応答して制御される。この場合、制御コマンドは第2のクライアントからサーバを通じて第1のクライアントに送信される。AV機器はこの制御コマンドに応じて制御される。よって、第2のクライアントはAV機器を制御することができる。本発明によるさらにもう1つのネットワーク型コンテンツ再生システムは、サーバと、サーバに接続された第1のクライアントと、第1のクライアントに接続されたAV機器と、サーバにネットワークを通じて接続され、AV機器を監視する第2のクライアントとを備える。AV機器は、自身に関する情報を第1のクライアントに送信する手段を含む。第1のクライアントは、AV機器から送信された情報をサーバに送信するAV機器情報送信手段を含む。サーバは、第1のクライアントから送信された情報を第2のクライアントに送信する手段を含む。この場合、AV機器に関する情報は第1のクライアント及びサーバを通じて第2のクライアントに送信される。よって、第2のクライアントはこの情報に基づいてAV機器を監視することができる。好ましくは、第1のクライアントのAV機器情報送信手段は、頻繁に変化する情報を所定の時間間隔で送信する。この場合、ネットワークトラフィックを低減することができる。好ましくは、サーバはさらに、第1のクライアントのファームウェアを更新するファームウェア更新手段を含む。この場合、第1のクライアントのファームウェアはサーバにより自動的に更新される。好ましくは、サーバはさらに、第1のクライアントに適した複数のファームウェアの情報を登録する手段と、登録された複数のファームウェアの情報を列挙したファームウェアリストを第1のクライアントに送信するファームウェアリスト送信手段とを含む。第1のクライアントはさらに、サーバから送信されたファームウェアリストを受信する手段と、受信されたファームウェアリストの中から選択されたファームウェアの送信をサーバに要求するファームウェア要求手段とを含む。ファームウェア更新手段は、第1のクライアントからの要求に応じて選択されたファームウェアを第1のクライアントに返信する。この場合、第1のクライアントのファームウェアは必ずしも最新バージョンに更新されるのではなく、適宜選択されたバージョンに更新される。好ましくは、第1のクライアントはさらに、自身に関するクライアント情報をサーバに送信する手段を含む。サーバはさらに、第1のクライアントから送信されたクライアント情報に基づいてファームウェアリストを作成する手段を含む。この場合、第1のクライアントに対応したファームウェアの情報を列挙したファームウェアリストを作成できる。好ましくは、第1のクライアントは、指定量のファームウェア、好ましくはファームウェアの一部をサーバに要求する。ファームウェア更新手段は、第1のクライアントからの要求に応じて指定量のファームウェア、好ましくはファームウェアの一部を返信する。この場合、サーバは指定量のファームウェアしか送信しないので、クライアントが受信を失敗した場合等には、その失敗した部分のみを再びサーバから受信すればよく、受信失敗時の処理を早くすることができる。また、ファームウェアリストの一部しかサーバから第1のクライアントに送信されないので、第1のクライアントにおいてファームウェアリストを記憶しておくために必要なメモリ容量を小さくすることができる。本発明によるもう1つのネットワーク型コンテンツ再生システムは、サーバと、サーバに接続された第1のクライアントと、サーバに接続された複数の第2のクライアントとを備える。サーバは、複数のコンテンツを蓄積するコンテンツ蓄積手段を備える。第2のクライアントの各々は、複数のコンテンツの中からコンテンツを指定し、その指定したコンテンツの再生を第1のクライアントに命令する手段を備える。第1のクライアントは、第2のクライアントからの命令に応じて指定されたコンテンツを再生する手段と、コンテンツの再生を完了したとき完了ステータスをサーバに送信する手段とを備える。サーバはさらに、第1のクライアントから完了ステータスを受信したとき、複数の第2のクライアントのうち1つを選択し、その選択した第2のクライアントに完了ステータスを送信するステータス送信手段を備える。第2のクライアントの各々はさらに、サーバから完了ステータスを受信したとき、第1のクライアントが再生を完了したコンテンツの次のコンテンツを指定し、その指定したコンテンツの再生を第1のクライアントに命令する手段を備える。好ましくは、サーバはさらに、第1のクライアントを制御可能な第2のクライアントの優先順位を管理する手段を備える。ステータス送信手段は、完了ステータスを送信すべき第2のクライアントとして優先順位が最高の第2のクライアントを選択する。あるいは、サーバはさらに、再生を命令した第2のクライアントの識別情報を記憶する手段を備える。ステータス送信手段は、完了ステータスを送信すべき第2のクライアントとして記憶した第2のクライアントの識別情報に基づいて再生を命令した第2のクライアントを選択する。本システムでは、サーバがコンテンツの再生を完了した第1のクライアントから完了ステータスを受信すると、第2のクライアントを1つ選択し、その第2のクライアントに完了ステータスを送信する。したがって、唯一の第2のクライアントが連続再生を第1のクライアントに命令することになる。その結果、本システムは、第1のクライアントへの連続再生命令の競合を排除し、第1のクライアントによるコンテンツの連続再生を可能にすることができる。好ましくは、ステータス送信手段は、優先順位が最高の第2のクライアント以外の第2のクライアントに停止ステータスを送信する。この場合、優先順位が最高の第2のクライアント以外の第2のクライアントには完了ステータスではなく停止ステータスが送信されるので、当該他の第2のクライアントは何ら能動的なアクションを起こすことなく、単に第1のクライアントの状態を監視することができる。本発明によるもう1つのネットワーク型コンテンツ再生システムは、サーバと、サーバに接続された第1のクライアントと、サーバに接続された複数の第2のクライアントとを備える。サーバは、複数のコンテンツを蓄積するコンテンツ蓄積手段を備える。第2のクライアントの各々は、第1のクライアントを制御するために必要な制御ハンドルを取得する制御ハンドル取得手段と、制御ハンドルの取得後、複数のコンテンツの中からコンテンツを指定し、その指定したコンテンツの再生を第1のクライアントに命令する手段とを備える。第1のクライアントは、第2のクライアントからの命令に応じて指定されたコンテンツを再生する手段と、コンテンツの再生を完了したとき完了ステータスをサーバに送信する手段とを備える。サーバはさらに、第1のクライアントから送信された完了ステータスを第2のクライアントの各々に転送する手段を備える。第2のクライアントの各々はさらに、制御ハンドルを取得している第1のクライアントからの完了ステータスを受信したとき、第1のクライアントが再生を完了したコンテンツの次のコンテンツを指定し、その指定したコンテンツの再生を第1のクライアントに命令する手段を備える。本システムでは、第2のクライアントはクライアントを制御するために必要な制御ハンドルを取得したうえでコンテンツの再生を第1のクライアントに命令する。第1のクライアントはコンテンツの再生を完了すると完了ステータスを送信する。第2のクライアントは制御ハンドルを取得している第1のクライアントから完了ステータスを受信したとき、連続再生を第1のクライアントに命令する。その結果、本システムは、第1のクライアントへの連続再生命令の競合を排除し、第1のクライアントによるコンテンツの連続再生を可能にすることができる。好ましくは、制御ハンドル取得手段は、制御ハンドルを取得したとき当該他の第2のクライアントによる制御ハンドルの取得を禁止する。この場合、複数の第2のクライアントが同時に1つの第1のクライアントの制御ハンドルを取得することはできないので、第1のクライアントへの再生命令の競合を完全に排除することができる。さらに好ましくは、第1のクライアントはさらに、コンテンツの再生を途中で停止したとき停止ステータスをサーバに送信する手段を備える。サーバはさらに、第1のクライアントから送信された停止ステータスを第2のクライアントの各々に転送する手段を備える。第2のクライアントの各々はさらに、制御ハンドルを取得している第1のクライアントからの停止ステータスを受信したとき、制御ハンドルの取得禁止を解除する手段を備える。この場合、コンテンツの再生を途中で停止した第1のクライアントは停止ステータスを全ての第2のクライアントに送信し、制御ハンドルを取得している第1のクライアントから停止ステータスを受信した第2のクライアントは制御ハンドルを解放する。したがって、いずれの第2のクライアントもこの第1のクライアントの制御ハンドルを取得することができることになる。本発明によるさらにもう1つのネットワーク型コンテンツ再生システムは、サーバと、サーバに接続された第1のクライアントと、サーバに接続された第2のクライアントとを備える。サーバは、複数のコンテンツを蓄積するコンテンツ蓄積手段を備える。第2のクライアントは、複数のコンテンツの中からコンテンツを指定し、その指定したコンテンツの再生を第1のクライアントに命令する手段を備える。第1のクライアントは、第2のクライアントからの命令に応じて指定されたコンテンツを再生する手段と、コンテンツの再生を完了したとき完了ステータスをサーバに送信する手段とを備える。サーバはさらに、第1のクライアントから完了ステータスを受信したとき、第1のクライアントが再生を完了したコンテンツの次のコンテンツを指定し、その指定したコンテンツの再生を第1のクライアントに命令する連続再生命令手段を備える。本システムでは、コンテンツの再生を完了した第1のクライアントが完了ステータスをサーバに送信すると、サーバ自らが連続再生を第1のクライアントに命令する。その結果、本システムは、第1のクライアントへの連続再生命令の競合を排除し、第1のクライアントによるコンテンツの連続再生を可能にすることができる。好ましくは、サーバはさらに、第1のクライアントにより再生されるべきコンテンツを列挙したコンテンツリストを作成するために必要なリスト構築キーを記憶する手段と、リスト構築キーに基づいてコンテンツリストを作成する手段とを備える。連続再生命令手段は、コンテンツリストに従ってコンテンツの再生を第1のクライアントに命令する。この場合、サーバはリスト構築キーを記憶しておき、そのリスト構築キーに基づいてコンテンツリストを作成するので、次に再生すべきコンテンツを特定することができる。本発明によるさらにもう1つのネットワーク型コンテンツ再生システムは、サーバと、サーバに接続された第1のクライアントと、サーバに接続された第2のクライアントとを備える。サーバは、複数のコンテンツを蓄積するコンテンツ蓄積手段を備え、第2のクライアントは、複数のコンテンツの中からコンテンツを指定し、その指定したコンテンツの再生を第1のクライアントに命令する手段と、第1のクライアントにより再生されるべきコンテンツリストを作成するために必要なリスト構築キーを第1のクライアントに送信する手段とを備える。第1のクライアントは、第2のクライアントからの命令に応じて指定されたコンテンツを再生する手段と、第2のクライアントから送信されたリスト構築キーをサーバに送信する手段とを備える。サーバはさらに、第1のクライアントから送信されたリスト構築キーに基づいてコンテンツリストを作成し、第1のクライアントに送信する手段を備える。第1のクライアントはさらに、サーバから送信されたコンテンツリストに従って第1のクライアントが再生を完了したコンテンツの次のコンテンツを再生する手段を備える。本システムでは、サーバがリスト構築キーに基づいて作成したコンテンツリストを第1のクライアントに送信する。第1のクライアントはこのコンテンツリストに従って自ら連続再生を行う。その結果、本システムは、第1のクライアントへの連続再生命令の競合を排除し、第1のクライアントによるコンテンツの連続再生を可能にすることができる。本発明によるネットワーク型コンテンツ再生システムにおけるクライアントは、サーバに蓄積された複数のデジタルコンテンツの中から選択されたデジタルコンテンツをサーバに要求するコンテンツ要求手段と、要求に応じてサーバから返信されたデジタルコンテンツを再生する再生手段とを含む。サーバは複数ある。クライアントはさらに、接続手段と判断手段とを備える。接続手段は複数のサーバのいずれかと接続を行う。判断手段は接続手段によるサーバとの接続が維持されているか否かを所定期間ごとに判断する。判断手段がサーバとの接続が切断されたと判断した場合に、接続手段はサーバとの再接続を実行する。本クライアントは所定期間ごとにサーバとの接続状態をチェックする。サーバとの接続が切断された場合、クライアントはサーバとの再接続を実行する。そのため、サーバに異常が発生するなどして接続が切断された場合でも、クライアントは自ら迅速に接続を回復できる。好ましくは、接続手段は、サーバとの再接続ができない場合に、他のサーバとの接続を実行する。この場合、接続していたサーバとの再接続ができなくても、クライアントは他のサーバと迅速に接続を実行する。その結果、クライアントはサーバとの接続が切断されたまま放置されることはない。好ましくは、接続手段は接続が切断される前のクライアントステータスを再接続したサーバに送信する。この場合、クライアントは切断前のクライアントステータスを再接続したサーバに送信するため、クライアントはサーバとの接続状態をもとどおりに回復できる。その結果、ユーザはクライアントがサーバと再接続したことを意識することなくクライアントを利用できる。以下、本発明の実施の形態を図面を参照して詳しく説明する。図中同一又は相当部分には同一符号を付してその説明を援用する。[目次]1.好ましい実施の形態1.1.構成1.1.1.全体1.1.2.コンテンツサーバ1.1.3.オーディオクライアント1.1.4.コントローラ1.1.5.AVレシーバ1.2.動作1.2.1.コンテンツサーバ及びオーディオクライアントの初期設定1.2.1.1.オーディオクライアントの初期設定1.2.1.1.1.コンテンツサーバ探索1.2.1.1.2.コンテンツサーバとの接続1.2.1.1.3.クライアント情報の送信1.2.1.2.コンテンツサーバの初期設定1.2.1.2.1.コンテンツサーバ探索に対する応答1.2.1.2.2.コマンドポート接続受付1.2.1.2.3.プッシュポート接続受付その11.2.1.2.4.プッシュポート接続受付その21.2.2.コンテンツサーバ及びオーディオクライアントのメイン動作1.2.2.1.コマンド受付1.2.2.1.1.コマンド振分処理1.2.2.1.2.ステータス通知コマンド処理1.2.2.1.3.サーバリクエスト発行コマンド処理1.2.2.2.通常再生1.2.2.2.1.曲リスト取得1.2.2.2.2.曲の指定1.2.2.2.3.曲の再生1.2.2.3.特殊再生1.2.2.3.1.早送り再生1.2.2.3.2.早戻し再生1.2.2.3.3.一時停止1.2.2.3.4.スロー再生1.2.3.コントローラの動作1.2.3.1.コンテンツサーバとの接続1.2.3.1.1.監視ハンドル及び制御ハンドルの取得1.2.3.2.モニタ監視機能1.2.3.3.制御機能1.2.3.3.1.制御コマンド処理1.2.3.3.2.再生制御1.2.3.3.3.再生可能なフォーマットかを識別して再生1.2.3.3.4.連続再生制御1.2.3.3.5.リスト構築キーを用いた連続再生制御1.2.3.3.6.優先順位を付けた連続再生制御1.2.3.3.7.制御ハンドルを利用した連続再生制御1.2.3.3.8.コンテンツサーバによる連続再生制御1.2.3.3.9.オーディオクライアント自身による連続再生制御1.2.3.3.10.再生命令管理テーブルを利用した連続再生制御1.2.4.AVレシーバの制御1.2.5.ファームウェアアップデート2.他の実施の形態2.1.コンセント内蔵型オーディオクライアント2.2.インターネット上の音楽データを取得2.3.取得データ長変更機能付き再生2.4.スキップ再生2.5.リピート再生2.6.途中再生2.7.自動接続回復機能付きクライアント1.好ましい実施の形態1.1.構成1.1.1.全体図1を参照して、本発明の実施の形態によるネットワーク型オーディオシステム10は、多数の曲の音楽データを蓄積するための複数のコンテンツサーバS1~Siと、コンテンツサーバS1~Siからの音楽データに基づいて音楽を再生するための複数のオーディオクライアントC1~Cjと、オーディオクライアントC1~Cjを制御しかつモニタするための複数のコントローラA1~Akと、AV機器例えば、スイッチャやアンプなどを含むAVレシーバAVRと、AVレシーバAVRを制御するためのAVRクライアントACとを備える。以下、コンテンツサーバのうち1つを挙げる場合はコンテンツサーバSi、オーディオクライアントのうち1つを挙げる場合はオーディオクライアントCj、コントローラのうち1つを挙げる場合はコントローラAkを用いる。ここではコンテンツサーバSiには音楽データを蓄積しているが、これに代えて又はこれと共に映像データを蓄積していてもよく、その他、さまざまなデジタルコンテンツを蓄積していてもよい。以下では、音楽データを例に説明する。また、コンテンツサーバSi、オーディオクライアントCj、コントローラAkは、それぞれ複数存在するが、コンテンツサーバやオーディオクライアントは少なくとも1つ存在すればよい。複数のコンテンツサーバS1~Siが存在する場合、オーディオクライアントCjはいずれのコンテンツサーバS1~Siから音楽データを取得してもよく、また、特定の1つのコンテンツサーバSiのみから音楽データを取得してもよい。また、コントローラAkは全くなくてもよい。また、AVレシーバAVRやAVRクライアントACは複数存在してもよいが、全くなくてもよい。これらは、LANローカルエリアネットワーク12により相互に接続されるが、これに限定されることなく、USB、IEEE1394など、コンピュータネットワークを構築するのに適切なものを採用すればよい。LANを採用する場合、PCパーソナルコンピュータで標準的なTCP/IPプロトコルを採用するのが好ましいが、UDPプロトコルなどを採用してもよく、プロトコルは特に限定されない。また、この図ではLANの基幹配線から枝分かれするようにコンテンツサーバやオーディオクライアントが接続されているが、たとえば10BASE-Tや100BASE-TXの場合にはハブを中心にしてスター状に接続される。1.1.2.コンテンツサーバ図2を参照して、各コンテンツサーバSiは、圧縮デジタル音楽データを蓄積するためのHDDハードディスクドライブ14と、データベース管理部16及びネットワークプロトコル処理部18を含むCPU処理部20と、本コンテンツサーバSiとLAN12との間で信号を送受信するLANコントローラ22とを備える。1.1.3.オーディオクライアント図3を参照して、各オーディオクライアントCjは、ネットワークプロトコル処理部24及びシステム動作部26を含むマイコン処理部28と、フラッシュメモリ30と、順次入力された圧縮デジタル音楽データ等を一時的に記憶して順次出力するメモリ32と、圧縮デジタル音楽データをデコードして非圧縮デジタル音楽データを生成する音声処理部34と、デジタル音楽データをアナログ音楽データに変換するD/A変換器DAC36と、本オーディオクライアントCjとLAN12との間で信号を送受信するLANコントローラ38とを備える。オーディオクライアントCjは、コンテンツサーバSiと異なり、圧縮デジタル音楽データを蓄積するためのHDDを備えていなくてもよい。1.1.4.コントローラ図4を参照して、各コントローラAkは、キーボード、マウス、タブレット、タッチパネル等の入力装置301と、液晶ディスプレイ、CRT等の表示装置302と、インストールされたコンピュータプログラムに従って所定の処理を実行するCPU303と、本コントローラAkとLAN12との間で信号を送受信するLANコントローラ304とを備える。コントローラA1~AkはオーディオクライアントC1~Cjと同様にコンテンツサーバS1~Siに対してクライアントとして機能する。コントローラAkがオーディオクライアントCjと異なる点は、オーディオクライアントCjは再生機能を有するのに対し、コントローラAkは再生機能を有さず、主としてオーディオクライアントのモニタ及び制御機能を有する点である。上記オーディオクライアントCjは主として再生機能を有するが、モニタ及び制御機能を有していてもよい。この場合、オーディオクライアントはコントローラとしても機能する。1.1.5.AVレシーバAVレシーバAVRは、特に限定されないが、たとえばEIA-232によりAVRクライアントACに接続される。AVRクライアントACは、主としてAVレシーバAVRと通信できる機能を有するが、オーディオクライアントCjと同様に再生機能を併せて有していてもよい。1.2.動作1.2.1.コンテンツサーバ及びオーディオクライアントの初期設定動作図5を参照して、あるオーディオクライアントに電源が投入されると、そのオーディオクライアントはまずコンテンツサーバを探索するS11。LAN12に接続されている複数のコンテンツサーバSiのうち稼働中のコンテンツサーバは、これに応答するS21。続いて、オーディオクライアントは、コンテンツサーバとデータの送受信を可能にするために、コンテンツサーバに対して接続要求を発行するS12。コンテンツサーバは、この接続要求に応じてオーディオクライアントとの接続を確立するS22。最後に、オーディオクライアントは自身に関するさまざまなクライアント情報をコンテンツサーバに送信しS13、コンテンツサーバはこれを受信するS23。上記初期設定動作が終了すると次の曲リスト取得動作に移るが、その説明の前に、オーディオクライアントの初期設定動作の詳細を説明する。1.2.1.1.オーディオクライアントの初期設定動作1.2.1.1.1.コンテンツサーバ探索図6を参照して、オーディオクライアントは、まず、発見したコンテンツサーバのIPアドレス及びポート番号を記録するためのサーバリストをクリアするS1101。続いて、オーディオクライアントは、特に限定されないが、たとえばUDPプロトコルにより、コマンドポートで予め定められたマジックワードをLAN12上にブロードキャストするS1102。LAN12に接続されている複数のコンテンツサーバSiの中に稼働中のコンテンツサーバが存在すれば、そのコンテンツサーバはブロードキャストされたマジックワードをサーチポートで受信し、そのマジックワードをブロードキャストしたオーディオクライアントに同じマジックワードを返信し、併せて自身を特定するためのサーバ特定情報具体的にはIPアドレス及びポート番号を送信する。続いて、オーディオクライアントは、サーバ特定情報の受信経過時間を計測するためのタイマをリセットしS1103、その後、サーバ特定情報を受信したか否かを判別するS1104。サーバ特定情報を受信した場合コンテンツサーバを発見した場合、オーディオクライアントは、そのサーバ特定情報をサーバリストに記録するS1105。そして、オーディオクライアントは、サーバリストが満杯になったか否かを判別しS1106、満杯になった場合は探索を完了し、未だ満杯になっていない場合はステップS1103に戻る。一方、サーバ特定情報を受信しない場合コンテンツサーバを発見しない場合、オーディオクライアントは、サーバ特定情報の受信経過時間が所定時間、たとえば2秒を超えたか否かを判別しS1107、未だ超えていない場合はステップS1104に戻る。すなわち、オーディオクライアントは2秒間だけコンテンツサーバからの応答を待つ。サーバ特定情報の受信経過時間が2秒を超えた場合、オーディオクライアントは、サーバリストが未だ空か否かを判別するS1108。サーバリストが空の場合、つまりサーバリストにサーバ特定情報が全く記録されていない場合、オーディオクライアントはステップS1102に戻ってマジックワードを再びブロードキャストする。一方、サーバリストが空でない場合、つまりサーバリストに少なくとも1つのコンテンツサーバのサーバ特定情報が記録されている場合、オーディオクライアントは探索を完了する。すなわち、オーディオクライアントは少なくとも1つのコンテンツサーバを発見するまで探索を続ける。上記コンテンツサーバ探索の結果、サーバリストには1又は2以上のコンテンツサーバに対応するIPアドレス及びポート番号が付与される。1.2.1.1.2.コンテンツサーバとの接続図7を参照して、オーディオクライアントは、ユーザの操作に応じてサーバリストの中から1つのコンテンツサーバを選択しS1201、その選択したコンテンツサーバのIPアドレス及びポート番号を取得するS1202。続いて、オーディオクライアントは、取得したIPアドレス及びコマンドポートでTCPソケット1を生成しS1203、このTCPソケット1でコンテンツサーバと接続するS1204。コマンドポートは、コンテンツサーバとオーディオクライアントとの間でコマンドを送受信するためのポートである。コンテンツサーバがコマンドポートでの接続を受け付けS2201、接続が成功した場合はステップS1206に進むが、そうでない場合は接続は失敗となるS1205。これによりオーディオクライアントは、コンテンツサーバとの間でコマンドを送受信するための接続を確立する。続いて、オーディオクライアントはTCPソケット1でクライアントインデックス要求コマンドをコンテンツサーバに送信するS1206。コンテンツサーバは、このクライアントインデックス要求コマンドに応答してTCPソケット1からクライアントインデックスをオーディオクライアントに返信しS2202、オーディオクライアントはこれを受信するS1207。クライアントインデックスは、コンテンツサーバにより各オーディオクライアントに割り当てられる識別番号である。クライアントインデックス要求コマンドは、オーディオクライアントがコンテンツサーバにクライアントインデックスを要求するコマンドである。続いて、オーディオクライアントは、コンテンツサーバのIPアドレス及びプッシュポートでTCPソケット2を生成しS1208、このTCPソケット2でコンテンツサーバと接続するS1209。プッシュポートは、コンテンツサーバからの自発的な要求又はコントローラからの要求に応じたコンテンツサーバからの要求以下サーバリクエストというを常に受信可能な待機状態にあるポートである。コンテンツサーバがプッシュポートでの接続を受け付けS209、接続が成功した場合はステップS1211に進むが、そうでない場合は接続は失敗となるS1210。これによりオーディオクライアントは、サーバリクエストを受信するための接続を確立する。この時点では、コンテンツサーバは未だ、プッシュポートに接続されているのはどのオーディオクライアントなのかわかっていない。そこで、オーディオクライアントはステップS1207で取得したクライアントインデックスをTCPソケット2でコンテンツサーバに送信するS1211。コンテンツサーバは、このクライアントインデックスに基づいてプッシュポートに接続されているオーディオクライアントを特定する。以降、コンテンツサーバは、サーバリクエストをオーディオクライアントに送信するとき、このプッシュポートを使用する。以上の結果、コマンドポート及びプッシュポートで2つの接続が確立する。これら2つの接続は、オーディオクライアントCj及びコンテンツサーバSiの間だけでなく、後述するコントローラAk及びコンテンツサーバSiの間、さらにAVRクライアントAC及びコンテンツサーバSiの間でも確立する。一般に、サーバクライアントシステムでは、HTTPプロトコルに見られるように、クライアントからの要求ページ要求などに対し、コンテンツサーバがレスポンスHTML文書などを返すというものである。これは、アクションのトリガはクライアントのみが有し、コンテンツサーバが自発的にクライアントに対して働きかけることができないということを意味している。このため、コンテンツサーバがクライアントに対して何らかの要求、たとえばコンテンツサーバシャットダウン時にクライアントにその旨を通知するなど、自発的なアクションをする場合でも、クライアントからの要求がなければ通知を行うことはできない。クライアントがサーバリクエストを受信するためには、一定時間ごとにコンテンツサーバに対してサーバリクエストがないかを確認するコマンドを発行する。コンテンツサーバはクライアントにより発行されたコマンドに応答してサーバリクエストをクライアントに送信し、クライアントはこれを受信する。上記HTTPプロトコルの場合も、動的に更新されるページに関しては一定時間ごとにページのリロードを行わなければならないということが知られている。この手法はクライアントからのポーリングによるサーバリクエストの取得と呼ぶことができるが、以下のような問題点がある。1ポーリング間隔をある程度短くして、こまめにサーバリクエストがあるか否かを尋ねないと、コンテンツサーバが要求を生じた時間と実際にその要求をオーディオクライアントが受け取るまでの時間に差が生じる。2上記のようにポーリング間隔を短くすると、ネットワークトラフィック及びサーバクライアントの負荷が増大してしまう。3コンテンツサーバがサーバリクエストをクライアントに送信しなければならない頻度は通常のコマンドを送受信する頻度に比べて低いので、大概のポーリングは無駄になる。サーバリクエストがあるか否かを尋ねても、通常は何も要求はないと返答されるからである。上記問題を解決するためには、クライアントからのポーリングではなく、コンテンツサーバからのインタラプトでサーバリクエストをクライアントに送信すればよい。これにより、上記1で問題となっているリアルタイム性の欠如、並びに上記2及び3のような無駄な負荷を排除することができる。これを実現するために、上述したように2つの接続を確立している。1つは、オーディオクライアントCjがコマンドを発行し、コンテンツサーバSiがそれに応答するのに用いられるコマンドポートに形成される接続である。もう1つは、コンテンツサーバSiがサーバリクエストをオーディオクライアントCjに送りつけるのに用いられるプッシュポートに形成される接続である。これによりオーディオクライアントCjからのポーリングを用いずに、コンテンツサーバSiがサーバリクエストをオーディオクライアントCjに通知することができる。以下、これら2つの接続を用いた動作の概要を説明する。図8に示すように、コンテンツサーバSiは、シャットダウン時に、プッシュポートを通じて全てのオーディオクライアントCjにその旨を通知し、これによりオーディオクライアントCjに何らかの動作電源を落とすなどをさせる。また、図9に示すように、コントローラAkは、オーディオクライアントCjを制御するときたとえば再生や停止など、その制御内容を含むサーバリクエストの発行をコンテンツサーバSiに要求するコマンドをコマンドポートを通じてコンテンツサーバSiに送信する。コンテンツサーバSiはこのコマンドに応答してサーバリクエストをプッシュポートを通じてオーディオクライアントCjに送信する。その結果、コントローラAkはオーディオクライアントCjを制御することができる。さらに、図10に示すように、オーディオクライアントCjは、その動作状態が変化したときに、その動作状態の変化をコマンドポートを通じてコンテンツサーバSiに送信する。コンテンツサーバSiは、その動作状態の変化をプッシュポートを通じてオーディオクライアントCjの動作状態を監視しているコントローラAkに送信する。したがって、オーディオクライアントCjはその動作状態の変化をリアルタイムにコントローラAkに通知することができる。以上により、本ネットワーク型オーディオシステムにおけるネットワークトラフィック並びにコンテンツサーバ及びオーディオクライアントの負荷を最小に抑えることができ、システム全体のパフォーマンスを増大させることができる。1.2.1.1.3.クライアント情報の送信図11を参照して、オーディオクライアントは、自身の属性情報をコンテンツサーバに送信しS1301~S1303、さらに自身の初期ステータスを送信するS1304~S1305。具体的には、オーディオクライアントは、TCPソケット1でオーディオクライアントタイプを送信するS1301。オーディオクライアントタイプには、再生可能な音楽フォーマットの種類、リモートコントローラリモコンによる操作の可否、EIA-232ポートの有無等がある。続いて、オーディオクライアントは、TCPソケット1でプロダクトIDを送信するS1302。プロダクトIDは、オーディオクライアントのタイプごとに付与される機種情報である。したがって、同じタイプのオーディオクライアントには同じプロダクトIDが付与される。続いて、オーディオクライアントは、TCPソケット1でファームウェアIDを送信するS1303。ファームウェアIDは、オーディオクライアントにインストールされているファームウェアのバージョン情報である。続いて、オーディオクライアントは、TCPソケット1でボリュームの初期値を送信するS1304。ボリュームの初期値は、オーディオクライアントで再生される音量の初期値である。最後に、オーディオクライアントは、TCPソケット1でオーディオクライアントの初期ステータスを送信するS1305。オーディオクライアントの初期ステータスには、停止ステータス等がある。コンテンツサーバは、クライアントから送信されたクライアント情報を受信し、クライアント情報データベース図13に格納する。クライアント情報は、オーディオクライアントCjだけでなく、コントローラAk及びAVRクライアントACからもコンテンツサーバSiに送信される。コンテンツサーバSiは、このクライアント情報に基づいて全てのクライアントを管理する。1.2.1.2.コンテンツサーバの初期設定動作次に、上記オーディオクライアントの初期設定動作に対応するコンテンツサーバの初期設定動作を説明する。図12を参照して、コンテンツサーバは、図13に示すようなクライアント情報データベースのための格納領域を最大クライアント数分確保し、クリアするS201。各クライアント情報は、接続の有無を示すフラグと、クライアントタイプと、現在のステータスと、現在のボリューム値と、プロダクトIDと、ファームウェアIDと、クライアント名と、再生ファイル名と、リスト構築キーとを含む。クライアントタイプには、オーディオクライアント、コントローラ、AVRクライアントといったクライアントのタイプと、再生可能なデータフォーマットMP3、WAVなどとが記録される。クライアントタイプにはさらに、リモコン制御の可否も記録される。たとえばリモコンにより制御可能なオーディオクライアントには、リモコン制御可能という情報が記録される。ステータスには、再生、停止、ポーズ、完了、ファームウェアアップデート中などのステータスが記録される。再生ファイル名には、現在再生中の曲のデータが格納されているHDD14のフルパス名が記録される。また、再生ファイル名はフルパス名のようなファイル名そのものである必要はなく、そのファイルを特定可能な情報であればいかなる情報であってもよい。たとえばコンテンツサーバに所定の識別番号とファイル名とを対応つけたテーブルを記憶しておき、コンテンツサーバがこのテーブルを参照して識別番号をファイル名に変換するようにしてもよい。この場合、長いファイル名を送受信する必要がなくなる。また、ファイル名から直ちに曲のデータが格納されているファイルを特定することができないので、セキュリティが向上する。さらに、リスト構築キーは、コンテンツサーバがリストを作成するためのものであるが、詳細は後述する。続いて、コンテンツサーバは、コマンドポートへの接続要求を受け付けるソケットと、プッシュポートへの接続要求を受け付けるソケットと、サーチポートへのサーバ探索要求を受け付けるソケットとを作成するS202。サーチポートは、コンテンツサーバ探索時に使うポートであり、このサーチポートにマジックワードが入力されたかどうかをコンテンツサーバは監視する。続いて、コンテンツサーバは、図14に示すようなコンテンツ情報データベースと、図15に示すようなファームウェア情報データベースとを構築するS203。コンテンツ情報データベースは、コンテンツ情報を曲数分備える。各曲のコンテンツ情報は、ファイル名と、曲名と、アーティスト名と、アルバム名と、ジャンル名と、曲の長さ時間と、データフォーマットと、再生回数と、最終アクセス時間とを含む。このファイル名には、当該曲のデータが格納されているHDD14のフルパス名が記録される。ファームウェア情報データベースは、ファーム情報をファームウェアのファイル数分備える。ファームウェア情報は、プロダクトIDと、ファームウェアIDと、ファイルサイズと、データフォーマットと、ファイル名とを含む。このファイル名には、当該ファームウェアが格納されているインターネット上のサイトを示すフルパス名が記録される。コンテンツサーバは、サーチポートに書込があった場合S204、後述するコンテンツサーバ探索に対する応答処理を行うS205。コンテンツサーバはまた、コマンドポートに書込があった場合S206、後述するコマンドポート接続受付処理を行うS207。コンテンツサーバはまた、プッシュポートに書込があった場合S208、後述するプッシュポート接続受付処理その1を行うS209。コンテンツサーバはまた、未処理プッシュポートに書込があった場合S210、後述するプッシュポート接続受付処理その2を行うS211。1.2.1.2.1.コンテンツサーバ探索に対する応答図16を参照して、サーチポートに書込があった場合、コンテンツサーバは、その書き込まれた内容を取得しS2051、その内容が正しいマジックワードか否かを判別するS2052。正しいマジックワードであれば、コンテンツサーバは同じマジックワードを送信元クライアントに返信しS2053、併せて自身のIPアドレス及びポート番号を返信する。1.2.1.2.2.コマンドポート接続受付図17を参照して、コマンドポートにクライアントから接続の要求があった場合、コンテンツサーバは、現在接続されているクライアント数が最大クライアント数に達しているか否かを判別するS2071。最大クライアント数に達している場合、コンテンツサーバは、優先度の低いクライアントを探し、強制的に切断するS2072。クライアントの優先度は、現在再生を行っていないオーディオクライアント、一定時間通信を行っていないオーディオクライアント等ほど、低くなる。そして、コンテンツサーバは、強制的に切断したクライアントのクライアント情報をクリアするS2073。なお、現在接続されているクライアント数が最大クライアント数に達している場合、上記に代えて、コンテンツサーバはこれ以上クライアントと接続しないようにしてもよい。クライアントの接続可能なソケットに余裕がある場合、又は優先度の低いクライアントを切断して接続可能なソケットを確保した場合、コンテンツサーバは、クライアントからの接続要求の受付を開始するS2074。受付が成功した場合S2075、コンテンツサーバは、クライアント情報データベースの空き領域を探すS2076。具体的には、フラグがFALSEになっているクライアント情報を探す。コンテンツサーバは、その探した領域を新しいクライアント情報格納領域に割り当てS2077、前のクライアント情報をクリアするS2078。続いて、コンテンツサーバはフラグをTRUEに設定しS2078、受付の結果として得られたソケット情報をクライアント情報格納領域のソケットフィールドに格納するS2079。1.2.1.2.3.プッシュポートへの接続受付処理その1図18を参照して、プッシュポートにクライアントから接続の要求があった場合、コンテンツサーバは、その受付を開始するS2091。受付が成功した場合S2092、受付の結果として得られたソケット情報を未処理プッシュポートのキューに格納するS2093。この時点では未だ、コンテンツサーバはプッシュポートに接続されたクライアントを特定できていない。このようなプッシュポートを未処理プッシュポートという。1.2.1.2.4.プッシュポート接続受付処理その2図19を参照して、未処理プッシュポートにクライアントから接続の要求があった場合、コンテンツサーバは、そのプッシュポートに書き込まれたコマンドを取得するS2111。そのコマンドのサイズが0よりも大きくS2112、かつそのコマンドがクライアントインデックス通知コマンドであればS2113、コンテンツサーバは、そのクライアントインデックスが示すクライアントは既にコマンドポートに接続されているか否かを判別するS2114。未だ接続が完了していない場合、コンテンツサーバはエラーコードを-1失敗に設定しS2115、ステップS2119に進む。一方、既に接続が完了している場合、コンテンツサーバは、このプッシュポートをそのクライアント用のプッシュポートとして登録するS2116。コンテンツサーバはさらに、このプッシュポートを未処理プッシュポートのキューから削除しS2117、エラーコードを0成功に設定するS2118。そして、コンテンツサーバは、設定されたエラーコードをクライアントに返信するS2119。1.2.2.コンテンツサーバ及びオーディオクライアントのメイン動作1.2.2.1.コマンド受付再び図12を参照して、コンテンツサーバは、初期設定を完了した後、クライアントからのコマンドを受け付ける。すなわち、コンテンツサーバは、ステップS213~S217を最大クライアント数分繰り返すS212、S218、S219。nは、クライアントに割り当てられる0から最大クライアント数-1までのクライアントインデックスである。具体的には、コンテンツサーバは、クライアント情報データベースのフラグを参照し、n番目のクライアントが既にコマンドポートに接続されているか否かを判別するS213。既に接続されている場合、コンテンツサーバはn番目のクライアント用のコマンドポートに書込があったか否かを判別するS214。書込があった場合、コンテンツサーバはその書き込まれたデータのサイズが0又は-1であるか否かを判別するS215。0又は-1の場合、クライアントが切り離されたか、又はソケットエラーが発生したかであるから、コンテンツサーバはn番目のクライアント情報をクリアするS216。一方、そうでない場合、コンテンツサーバは次のコマンド処理を行うS217。1.2.2.1.1.コマンド振分処理図20を参照して、クライアントからコマンドポートへの書込があった場合、コンテンツサーバは、先頭4バイトに格納されたコマンドに応じて処理を分岐するS2171。すなわち、オーディオクライアントからコンテンツサーバにステータスの変動を通知するといったステータス通知コマンドであればS2172、オーディオクライアントから通知されたステータスをコントローラに通知するS2173。詳細は後述する。また、コントローラからオーディオクライアントへのコンテンツサーバリクエスト発行コマンドであればS2174、コントローラからの要求をオーディオクライアントに通知するS2175。詳細は後述する。その他、コンテンツサーバはコマンドに応答して所定の処理を行う。1.2.2.1.2.ステータス通知コマンド処理あるオーディオクライアント以下当該オーディオクライアントという。からのコマンドがステータス通知コマンドの場合、図21を参照して、コンテンツサーバは、まず、そのコマンド中のパラメータに格納されたステータスやボリューム等のクライアント情報をクライアント情報データベースに格納するS21731。したがって、コンテンツサーバは常に最新のクライアント情報を保持している。次に、コンテンツサーバは、全てのクライアントの中からコントローラを探し出し、探し出したコントローラに当該オーディオクライアントのステータスを通知する。そのため、コンテンツサーバは、以下のステップS21733~S21736を最大クライアント数分繰り返すS21732、S21737、S21738。具体的には、コンテンツサーバは、クライアント情報のクライアントタイプを参照して、n番目のクライアントがコントローラか否かを判別するS21733。したがって、当該オーディオクライアントのステータスをコントローラではない当該他のオーディオクライアントに通知することを防ぐことができる。コントローラであれば、コンテンツサーバは、そのコントローラが当該オーディオクライアントに対する監視ハンドルを取得しているか否かを判別するS21734。監視ハンドルを取得していれば、コンテンツサーバは、そのコントローラがプッシュポートへの接続を完了しているか否かを判別するS21735。プッシュポートへの接続を完了していれば、コンテンツサーバは、そのコントローラのプッシュポートに当該オーディオクライアントのクライアント情報を書き込み、これにより当該オーディオクライアントのステータスをコントローラに通知するS21736。1.2.2.1.3.サーバリクエスト発行コマンド処理コントローラからのコマンドがサーバリクエスト発行コマンドの場合、図22を参照して、コンテンツサーバは、まず、そのコマンドに含まれる発行元コントローラ、送信先オーディオクライアント、要求内容等を取得するS21751。コンテンツサーバは、発行元コントローラが送信先オーディオクライアントの制御ハンドル後述を取得しているか否かを判別しS21752、制御ハンドルを取得していなければエラーコードを-1に設定するS21753。したがって、制御ハンドルを取得していないコントローラがオーディオクライアントを制御するのを防止することができる。制御ハンドルを取得していれば、コンテンツサーバは、クライアント情報中のフラグを参照して送信先オーディオクライアントのコマンドポートで接続が確立しているか否かを判別しS21754、確立していなければエラーコードを-2に設定するS21755。したがって、制御不可能なオーディオクライアントにコマンドを送信するのを防止することができる。送信先オーディオクライアントのコマンドポートで接続が確立していれば、コンテンツサーバは、送信先オーディオクライアントのプッシュポートで接続が確立しているか否かを判別しS21756、確立していなければエラーコードを1に設定するS21757。一方、確立していれば、コンテンツサーバは、送信先オーディオクライアントのプッシュポートにコントローラからの要求内容を送信しS21758、エラーコードを0エラーなしに設定するS21759。最後に、コンテンツサーバは、発行元コントローラにエラーコードを返信するS21760。なお、送信先オーディオクライアントがプッシュポートに接続されていない場合は、送信先オーディオクライアントがポーリングで問い合わせをしてきたときに、コントローラからの要求内容を送信先オーディオクライアントに送信するようにしてもよい。1.2.2.2.通常再生次に、ユーザがオーディオクライアントCjに所望の曲を再生させる場合の動作を説明する。ここでは、ユーザは所望の曲を直ちに指定するのではなく、まず所望の曲リストを指定し、その曲リストの中から所望の曲を選択する。以下、詳述する。図23を参照して、オーディオクライアントは、ユーザの操作に応じて曲リスト要求コマンドをコンテンツサーバに送信するS14。曲リスト要求コマンドは、オーディオクライアントがコンテンツサーバに対して所望の曲リストを要求するためのコマンドである。曲リストには、複数の曲名やアーティスト名などが列挙されている。コンテンツサーバはこの曲リスト要求コマンドに応じて曲リストを要求元のオーディオクライアントに送信しS24、オーディオクライアントはこれを受信するS14。オーディオクライアントはユーザの操作に応じて曲リストに含まれる曲を指定しS15、コンテンツサーバはこれに応じて指定された曲の配信を準備するS25。続いて、コンテンツサーバは指定された曲をオーディオクライアントに配信しS26、オーディオクライアントは配信された曲を再生するS16。そして、オーディオクライアントは、再生終了後又はユーザの操作に応じて曲の再生を停止するS17。以下、ステップS14~S16の各々の詳細を説明する。1.2.2.2.1.曲リスト取得図24を参照して、オーディオクライアントは、コンテンツサーバにプレイ名リストを要求するか否かを判別するS1401。プレイ名リストは、プレイリストのタイトルを列挙したものである。プレイリストは、ユーザにより選択された複数の曲を列挙した曲リストである。コンテンツサーバには、ユーザにより作成された複数のプレイリストが予め格納されている。ユーザは、コンテンツサーバに格納されている複数のプレイリストの中から1つを選択しようとする場合、まずどのようなプレイリストが登録されているのかを確認するために、コンテンツサーバにプレイ名リストを要求する。オーディオクライアントはこのユーザの操作に応じてコンテンツサーバにプレイ名リストを要求し、コンテンツサーバからプレイ名リストを受信するS1402。続いて、オーディオクライアントは、指定されたプレイリストを要求するか否かを判別するS1403。ユーザがプレイ名リストの中から所望のプレイリストを指定し、この操作に応じてオーディオクライアントが指定されたプレイリストを要求する場合はステップS1413に進み、要求しない場合はステップS1401又S1403に戻るS1404。プレイ名リストを要求しない場合、オーディオクライアントは、コンテンツサーバにアーティストリストを要求するか否かを判別するS1405。アーティストリストには、複数のアーティスト名が列挙されている。アーティストリストはコンテンツサーバに予め用意されているのではなく、オーディオクライアントからの要求に応じて図14に示したコンテンツ情報データベースからその都度作成される。ユーザがアーティストリストを要求する場合、オーディオクライアントはユーザの操作に応じて所望のアーティストリストをコンテンツサーバに要求し、コンテンツサーバからアーティストリストを受信するS1406。続いて、オーディオクライアントは、指定されたアーティストの曲リストを要求するか否かを判別するS1407。ユーザがアーティストリストの中から所望のアーティストを指定し、この操作に応じてオーディオクライアントが指定されたアーティストの曲リストを要求する場合はステップS1413に進み、要求しない場合はステップS1401又S1407に戻るS1408。この曲リストには指定されたアーティストの曲名などが列挙されているが、この曲リストも上記アーティストリストと同様にコンテンツサーバに予め用意されているのではなく、オーディオクライアントからの要求に応じて図14に示したコンテンツ情報データベースからその都度作成される。アーティストリストを要求しない場合、オーディオクライアントは、コンテンツサーバにジャンルリストを要求するか否かを判別するS1409。ジャンルリストには、複数のジャンル名が列挙されている。ジャンルリストも上記アーティストリストと同様にコンテンツサーバに予め用意されているのではなく、オーディオクライアントからの要求に応じて図14に示したコンテンツ情報データベースからその都度作成される。ユーザがジャンルリストを要求する場合、オーディオクライアントはユーザの操作に応じて所望のジャンルリストをコンテンツサーバに要求し、コンテンツサーバからジャンルリストを受信するS1410。続いて、オーディオクライアントは、指定されたジャンルの曲リストを要求するか否かを判別するS1411。ユーザがジャンルリストの中から所望のジャンルを指定し、この操作に応じてオーディオクライアントが指定されたジャンルの曲リストを要求する場合はステップS1413に進み、要求しない場合はステップS1401又S1411に戻るS1412。この曲リストには指定されたジャンルの曲名などが列挙されているが、この曲リストも上記アーティストの曲リストと同様にコンテンツサーバに予め用意されているのではなく、オーディオクライアントからの要求に応じて図14に示したコンテンツ情報データベースからその都度作成される。上記の結果、曲リストを要求する場合、オーディオクライアントはコンテンツサーバに曲リストを要求し、コンテンツサーバから曲リストを受信するS1413。これにより曲リストの取得は終了する。次に、図25を参照して、ジャンルリストを取得し、その中から所望のジャンルとしてポップスを選択してポップスの曲リストを取得する場合の動作を説明する。この場合、オーディオクライアントは、コンテンツサーバにジャンルリストを要求するためのリスト要求コマンドを送信するS1421。コンテンツサーバは、これに応答してジャンルリストを返信するS2401。オーディオクライアントは、コンテンツサーバからジャンルリストを受信し、図26に示すようにメモリ32に格納するS1422。ジャンルリストは、予め作成してコンテンツサーバに保存しておいてもよいが、ここではそうではなく、オーディオクライアントから要求されるたびに、コンテンツサーバが図14に示したコンテンツ情報データベースに基づいてジャンルリストを作成する。以下、ジャンルリストの作成方法を説明する。図27に示すように、コンテンツ情報データベースは、n曲を保存している場合、n個のレコードを有する。各レコードには、曲名、ジャンル、アーティスト名、アルバム名などが記録されている。このようなコンテンツ情報データベースを用いてジャンルリストを作成する場合、図28を参照して、まず、コンテンツサーバは、レコードの番号を示すインデックスを0に初期化するS24011。続いて、コンテンツサーバは、インデックスが示すレコードのジャンルが既にジャンルリストに存在するか否かを判別するS24012。存在しない場合、コンテンツサーバはそのレコードのジャンルをジャンルリストに追加しS24013、その後、インデックスをインクリメントするS24014。一方、存在する場合、コンテンツサーバは、ステップS24013をスキップし、直ちにインデックスをインクリメントするS24014。続いて、コンテンツサーバは、インデックスが示すレコードの番号が全レコード数nよりも小さいか否かを判別しS24015、小さい場合はステップS24012に戻り、一方、小さくない場合はジャンルリストの作成を完了する。上記の処理により、コンテンツサーバは、コンテンツ情報データベースに蓄積されている全ての曲のジャンルを重複することなくピックアップし、ジャンルリストを作成する。このように、ジャンルリストは予めデータベース化されているのではなく、オーディオクライアントからの要求のたびに一時的に作成されるので、ジャンルリストを常に格納しておくためのメモリ領域は不要である。再び図25を参照して、作成されたジャンルリストはコンテンツサーバからオーディオクライアントに送信されるS2401,S1422。ユーザは、このジャンルリストの中から所望のジャンルこの例ではポップスを選択する。オーディオクライアントは、ユーザの操作に応じて選択されたジャンルの曲リストをコンテンツサーバに要求するS1423。コンテンツサーバは、オーディオクライアントからの要求に応じて選択されたジャンルの曲リストをコンテンツサーバに返信するS2402。オーディオクライアントは、コンテンツサーバから曲リストを受信し、図29に示すようにメモリ32に格納するS1424。上記ジャンルリストと同様に、曲リストもコンテンツサーバに予め用意されているのではなく、図27に示したコンテンツ情報データベースに基づいて作成される。すなわち、コンテンツサーバは、オーディオクライアントから曲リストを要求されるたびに、コンテンツ情報データベースに基づいて曲リストを作成する。以下、曲リストの作成方法を図30を参照して説明する。まず、コンテンツサーバは、図27に示したコンテンツ情報データベースにおけるレコードの番号を示すインデックスを0に初期化するS24021。続いて、コンテンツサーバは、インデックスが示すレコードのジャンルを選択されたジャンルこの例ではポップスと比較し、それらが一致するか否かを判別するS24022。一致する場合、コンテンツサーバはそのレコードの曲名、アーティスト名、アルバム名などを曲リストに追加しS24023、その後、インデックスをインクリメントするS24024。一方、一致しない場合、コンテンツサーバは、ステップS24023をスキップし、直ちにインデックスをインクリメントするS24024。続いて、コンテンツサーバは、インデックスが示すレコードの番号が全レコード数nよりも小さいか否かを判別しS24025、小さい場合はステップS24022に戻り、一方、小さくない場合は曲リストの作成を完了する。上記の処理により、コンテンツサーバは、選択されたジャンルの曲だけをコンテンツ情報データベースからピックアップし、曲リストを作成する。このように、曲リストは予めデータベース化されているのではなく、オーディオクライアントからの要求のたびに一時的に作成されるので、曲リストを常に格納しておくためのメモリ領域は不要である。なお、曲リストを作成する場合には、該当する全ての曲をピックアップするのではなく、再生不可能なデータフォーマットの曲についてはピックアップしないようにしてもよい。また、オーディオクライアントからの要求のたびに曲リストを作成するのではなく、一旦作成した曲リストはキャッシュしておくようにしてもよい。この場合、曲リストを格納しておくためのメモリ領域が必要になるが、コンテンツサーバはオーディオクライアントからの要求に応じて直ちに曲リストを返信することができる。上記ジャンルリストと同様に、曲リストも全部が一度に送信されるのではなく、少しずつ順に送信される。すなわち、曲リストの要求S1423,S1425、曲リストの返信S2402,S2403及び曲リストの受信S1424,S1426の動作は繰り返し行われる。以下、この詳細を説明する。オーディオクライアントは、図31に示すようなリスト要求コマンドをコンテンツサーバに送信するS1423。リスト要求コマンドは、オーディオクライアントがコンテンツサーバにリストを要求するコマンドであり、この例では、取得開始インデックス、取得個数及びリスト構築キーを含む。取得開始インデックスは、選択されたジャンルリストに収録されている曲のうち、オーディオクライアントが取得しようとする先頭の曲を示すインデックスである。取得個数は、オーディオクライアントが取得しようとする曲の数である。リスト構築キーは、詳細は後述するが、コンテンツ情報データベースから曲を抽出するときに注目するカテゴリを示すフィルタの種類と、そのカテゴリに分類される具体的なキーワードとから構成される。特に限定されないが、この例では、取得開始インデックス=0、取得個数=50に設定され、さらにリスト構築キーはジャンルフィルタの種類=ポップスキーワードに設定されている。コンテンツサーバは、このリスト要求コマンドに応答して、図32に示すような検索データをオーディオクライアントに返信するS2402。検索データは、曲リストの一部のほか、有効個数及び残り個数を含む。有効個数は、コンテンツサーバがオーディオクライアントに実際に返信した曲の数である。残り個数は、コンテンツサーバがオーディオクライアントに返信した曲リストよりも後に残っている曲の数である。ここでは、取得開始インデックス=0、取得個数=50のリスト要求コマンドに応答するのであるから、コンテンツサーバは、作成した曲リストのうち最初の曲から50曲目までをオーディオクライアントに返信するS2402。曲リストの全曲数=110とすると、有効個数=50、残り個数=60=110-50に設定される。続いて、オーディオクライアントは、コンテンツサーバに未だ60曲が残っているから、再びリスト要求コマンドをコンテンツサーバに送信するS1425。ここでは、取得開始インデックス=51、取得個数=50に設定される。コンテンツサーバは、このリスト要求コマンドに応答して、再び検索データをオーディオクライアントに返信するS2403。ここでは、有効個数=50、残り個数=10=110-5050に設定される。すなわち、コンテンツサーバは、再び曲リストを50曲分だけオーディオクライアントに返信するS2403。オーディオクライアントは、この曲リストを受信し、メモリ32に格納するS1426。なお、上記の例では、曲リストの全曲数=110、取得個数=50であるから、曲リストの一部である50曲が返信されているが、曲リストの全曲数が取得個数よりも少ない場合、たとえば曲リストの全曲数=40、取得個数=50であれば、曲リストの全部である40曲が返信されることになる。また、上記の例では、取得開始インデックス=0であるから、曲リストの最初から曲が返信されているが、たとえば取得開始インデックス=10とすれば、曲リストの11曲目から曲が返信されることになる。また、この場合、曲リストの全曲数=110であり、最初のリスト要求コマンドが取得開始インデックス=10、取得個数=50であれば、コンテンツサーバは、有効個数=50、残り個数=50=110-10-50の検索データを返信することになる。メモリ32に格納可能な曲数が曲リストの全曲数よりも多ければ、オーディオクライアントは曲リストの全部を一度に格納することができる。しかし、メモリ32の容量はコンテンツサーバに比べると非常に小さいため、通常、オーディオクライアントは曲リストの一部しかメモリ32に格納することができない。上記実施の形態によれば、オーディオクライアントはコンテンツサーバから曲リストを分割してダウンロードしているため、オーディオクライアントのメモリ32に少なくとも50曲分の領域を用意すれば、110曲全ての曲リストをダウンロードすることができる。そのため、メモリ32の容量を小さく抑えることができる。たとえば図33Aに示すように、オーディオクライアントがメモリ32に50曲分の曲リストを格納した後、ユーザが51曲目以降の取得を希望した場合、図33Bに示すように、オーディオクライアントは後半の曲リストをメモリ32の前半に移動させる。そして、図33Cに示すように、オーディオクライアントはメモリ32の後半に51曲目から25曲分の曲リストを格納する。オーディオクライアントは、上記動作を繰り返して曲リストの全部を受信するか、又はメモリ32に格納可能な曲数だけ受信する。図25に示した例では、ジャンルを選択した後、直ちにそのジャンルから曲を選択するようにしているが、図34に示したように、ジャンルを選択し、引き続きそのジャンルからアルバムを選択した後、そのアルバムから曲を選択するようにしてもよい。この場合、オーディオクライアントは、ユーザの操作に応じて選択されたジャンルのアルバムリストをコンテンツサーバに要求するS1427。コンテンツサーバは、オーディオクライアントからの要求に応じて選択されたジャンルのアルバムリストをオーディオクライアントに返信するS2404。オーディオクライアントは、コンテンツサーバからアルバムリストを受信し、メモリ32に格納するS1428。続いて、オーディオクライアントは、ユーザの操作に応じて選択されたアルバムの曲リストをコンテンツサーバに要求するS1429。コンテンツサーバは、オーディオクライアントからの要求に応じて選択されたアルバムの曲リストをオーディオクライアントに返信するS2405。1.2.2.2.2.曲の指定図35及び図36を参照して、オーディオクライアントは指定された曲の情報をコンテンツサーバに要求しS1501、コンテンツサーバはこの要求に応じて指定された曲の情報をオーディオクライアントに返信しS2501、オーディオクライアントはこれを受信するS1502。具体的には、オーディオクライアントは、図37に示すような曲情報要求コマンドを送信するS1501。この曲情報要求コマンドは、指定された曲のファイル名を含む。コンテンツサーバは、この曲情報要求コマンドに応答して、図38に示すような曲情報を返信するS2501。この曲情報は、指定された曲のデータオフセット及びデータサイズを含む。MP3等の音楽データは一般に、コンテンツ情報の前にヘッダ情報を有する。データオフセットは、このヘッダ情報をスキップし、曲の先頭アドレスを指定するためのものである。オフセットをコンテンツサーバが解析することにより、オーディオクライアントはオフセットを解析する必要がなくなる。一般的に、コンテンツサーバはオーディオクライアントよりも処理能力が高いので、システム全体として処理を高速化することができる。データサイズは、曲の終了時期を確認するためのものである。続いて、オーディオクライアントは指定された曲の再生準備をコンテンツサーバに要求しS1503、コンテンツサーバはこの要求に応じて指定された曲のファイルをオープンし、その結果をオーディオクライアントに返信しS2502、オーディオクライアントはこれを受信するS1504。具体的には、オーディオクライアントは、図39に示すような曲再生準備コマンドを送信するS1503。この曲再生準備コマンドは、指定された曲のファイル名及び後述するリスト構築キーを含む。コンテンツサーバは、この曲再生準備コマンドに応答してファイルをオープンし、図40に示すようなエラーコードを返信するS2502。このエラーコードは、ファイルが存在しないなど、ファイル転送の準備ができない場合はエラーありとなり、準備ができる場合はエラーなしとなる。クライアントは送信されたエラーコードを確認し、エラーがあれば所定のエラー処理を行うS1504。1.2.2.2.3.曲の再生続いて、オーディオクライアントは指定された曲の音楽データのうち指定範囲の音楽データの転送をコンテンツサーバに要求しS1601、コンテンツサーバはこの要求に応じて指定範囲の音楽データをオーディオクライアントに返信しS2601、オーディオクライアントはこれを受信し、メモリ32に格納するS1602。具体的には、オーディオクライアントは、図41に示すような曲データ転送要求コマンドを送信するS1601。この曲データ転送要求コマンドは、転送すべき音楽データの取得開始アドレス及び取得データ長を含む。コンテンツサーバは、図42に示すように、取得開始アドレスにより指定された先頭アドレスからその取得データ長分だけ音楽データを返信するS2601。1回に送信されるデータのサイズは、特に限定されないが、好ましくは1K~32Kバイトであり、さらに好ましくは4K~16Kバイトである。コンテンツサーバは一度に返信するデータ量が小さいほど負荷を小さくすることができ、クライアントは一度に受信するデータ量が大きいほど処理を早くすることができるが、1K~32Kバイト特に、4K~16Kバイトがコンテンツサーバとクライアントとの両方にとって、最適な値となるからである。このようなデータのサイズはオーディオクライアント側で予め設定される。上記取得開始アドレスを転送した取得データ長分だけ順次加算していき、上記動作を繰り返すことによりS1605、S2603、S1606、S1607、S2604、S1608、音楽データを指定範囲ごとに順次転送することができる。このように、オーディオクライアントは指定した範囲の音楽データをコンテンツサーバから取得することができるので、後述するように、曲を途中から再生できるほか、早送り再生、早戻し再生、スロー再生など、ユーザの操作に応じて音楽を自在に再生することができる。メモリ32は、複数図43に示した例では8つのバッファを含む。図44に示すように、オーディオクライアントは曲データ転送要求コマンドで曲の先頭から1バッファ分の音楽データを取得して格納する。図45に示すように、オーディオクライアントは同様にしてバッファが全て埋まるまで音楽データを取得して格納する。ステップS1601~S1608の間で上記のようにバッファが全て埋まったら、オーディオクライアントは、図46に示すように先頭バッファから音楽データを音声処理部34に出力し始める。オーディオクライアントは、上記のように音楽データを出力して音楽の再生を開始したら、再生ステータスをコンテンツサーバに送信するS1603。コンテンツサーバはこれを受信し、エラーコードをオーディオクライアントに返信するS2602。オーディオクライアントはこのエラーコードを確認し、エラーがあれば所定のエラー処理を行うS1604。上記のように音楽データを転送しながら音楽を再生していると、やがて図47に示すように1バッファ分の空きが生じる。バッファに空きが生じるとS1609、オーディオクライアント及びコンテンツサーバは再び上記転送動作を行うS1610、S2605、S1611。その結果、図48に示すようにバッファの空きが埋まる。オーディオクライアント及びコンテンツサーバは、バッファに空きが生じるたびに上記転送動作を繰り返し行うS1612~S1616、S2606、S2607。なお、上記では、バッファが音楽データで全て埋まってから音楽データを出力し始めているが、全て埋まる前に出力し始めるようにしてもよい。続いて、オーディオクライアントは、ステップS1502で取得したデータサイズに基づいて、指定された曲の音楽データを全て受信したか否かを判別するS1617。全て受信した場合、オーディオクライアントは、受信した音楽データに基づいて指定された曲を再生し終えたか否かを判別しS16171、再生し終えた場合は停止又は完了ステータスをコンテンツサーバに送信するS1618。ユーザがオーディオクライアントを操作し、それに応じてオーディオクライアントが指定された曲を再生しその曲を再生し終えた場合、又はユーザがオーディオクライアントを操作し、それに応じてオーディオクライアントが曲の再生を途中で停止した場合、オーディオクライアントは停止ステータスを送信する。一方、ユーザがコントローラを操作し、それに応じてオーディオクライアントがコントローラから指定された曲を再生しその曲を再生し終えた場合、オーディオクライアントは完了ステータスを送信する。このように停止ステータスと完了ステータスとを区別する理由は後述する。コンテンツサーバはこのステータスを受信し、エラーコードをオーディオクライアントに返信するS2608。オーディオクライアントはこのエラーコードを確認し、エラーがあれば所定のエラー処理を行うS1619。以上のように、音楽データを分割し、コンテンツサーバからオーディオクライアントに断続的に転送しているため、バッファ容量が少なくても適切に音楽を再生することができる。上記では音楽データをバイト単位で転送しているが、MP3の音楽データを転送する場合はフレーム単位で転送するのが好ましい。時間表示、早送り又は早戻し再生などの特殊再生後述で有利な点が多いからである。したがって、MP3の音楽データの場合、オーディオクライアントはフレーム単位で音楽データを要求するものとする。この要求に応答して、コンテンツサーバは指定されたファイルの中からMP3のフレームヘッダを検索し、フレームの先頭から転送を行う。このヘッダの中にはデータ長を算出することができるパラメータが含まれているので、一度ヘッダを発見すれば、以降、フレームの先頭を発見するのは困難ではない。1.2.2.3.特殊再生また、早送り、早戻し、一時停止、スローなど、特殊再生を可能とするために、音楽データの転送要求、返信及び取得という一連の処理の前に、オーディオクライアントは以下のような処理を行う。1.2.2.3.1.早送り再生早送り再生の場合、図49を参照して、オーディオクライアントは、キー入力を監視しS1620、早送り再生キーが押された場合はスキップ量を0よりも大きい値に設定しS1621、そうでない場合はスキップ量を0に設定するS1622。バッファに空きが生じるとS1609、オーディオクライアントは、音楽データの取得開始アドレスを次式により計算するS1624。取得開始アドレス=前回の取得開始アドレス取得データ長スキップ量ステップS1620で早送り再生キーが押されなかった場合、ステップS1622でスキップ量は0に設定されるので、取得開始アドレスは取得データ長ずつ増加する。この場合、オーディオクライアントは音楽データを連続的に取得するので、通常の再生を行う。一方、ステップS1620で早送り再生キーが押された場合、ステップS1621でスキップ量は0よりも大きい値に設定されるので、オーディオクライアントは音楽データをそのスキップ量だけ飛んで取得する。その結果、オーディオクライアントは早送り再生を行う。この例では、スキップ量が取得データ長と同じに設定されているから、2倍速の早送り再生を行う。また、たとえばスキップ量を取得データ長の2倍とすることにより、3倍速の再生を行うことができる。1.2.2.3.2.早戻し再生早戻し再生の場合、オーディオクライアントは、上記ステップS1620に代えて早戻し再生キーが押されているかを判別し、上記ステップS1621に代えてスキップ量を0よりも小さく、かつ絶対値が前回の取得データ長よりも大きい値に設定する。スキップ量の絶対値が前回の取得データ長よりも小さいと、音楽データの取得範囲が重複するからである。毎回の取得データ長が一定であれば、絶対値を取得データ長の2倍にすれば、通常再生と同じ速度で戻し再生を行うことができる。また、オーディオクライアントは、ステップS1624で計算した取得開始アドレスが音楽データの存在する範囲内か否かを判別するS1625。範囲内の場合、オーディオクライアントは次のステップS1610に進むが、範囲外の場合、オーディオクライアントは再生を停止する。通常再生の場合は音楽データの終わりを検知しているので、このような終了条件を入れる必要はないが、特に早戻し再生の場合は音楽データの始まりを検知する必要があるので、このような終了条件を入れている。ただし、このような終了条件を入れずに、次の曲のファイルをオープンして早送り再生を行ったり、前の曲のファイルをオープンして早戻し再生を行うようにしてもよい。なお、MP3の音楽データの場合は、前述したように、フレームヘッダを読み取れば次のフレームヘッダの位置をほぼ確定することができる。したがって、ある一定分のフレームをスキップし、その後の数フレームのデータを再生し、再びフレームをスキップする、という動作を繰り返すことにより早送り再生を実現することができる。1.2.2.3.3.一時停止一時停止の場合、図50を参照して、オーディオクライアントはキー入力を監視しS1626,S1628、一時停止キーが押された場合は動作ステータスを一時停止に設定しS1627、再生キーが押された場合は動作ステータスを再生に設定するS1629。バッファに空きが生じるとS1609、オーディオクライアントは動作ステータスが一時停止か否かを判定するS1631。一時停止の場合、オーディオクライアントはステップS1626に戻って次の音楽データの転送を開始しない。一方、一時停止でない場合、すなわち再生キーが押されて一時停止が解除され、動作ステータスが再生に変化した場合、オーディオクライアントはステップS1610に進んで次の音楽データの転送を開始する。また、動作ステータスが一時停止になった場合、オーディオクライアントはバッファの読出動作を停止する。バッファには、以前に転送された音楽データが残っているからである。1.2.2.3.4.スロー再生音楽ではなく、動画の場合はスロー再生を行う必要がある。通常、動画ファイルはMPEG-2のように圧縮形式であるから、オーディオクライアントはこれを再生するためにデコーダを備える。スロー再生の場合、デコーダにスロー再生を指示するコマンドが与えられると、バッファに蓄積されている映像データの減少速度が遅くなる。仮に通常再生の30の速度でスロー再生を行うのであれば、デコーダがバッファから読み出す映像データの単位時間当たりの量は30になる。そのため、上記ステップS1609でオーディオクライアントがバッファに空きが生じるのを待つ時間が長くなり、これによりスロー再生を実現することができる。1.2.3.コントローラの動作1.2.3.1.コンテンツサーバとの接続コントローラAkもオーディオクライアントCjとほぼ同様に、まずコンテンツサーバSiとの接続を確立する。図51を参照して、コントローラAkに電源が投入されると、コントローラAkは、コンテンツサーバSiのコマンドポートに接続するS3001。コントローラAkは、このコマンドポートを通じてクライアントインデックス要求コマンドを発行するS3002。コンテンツサーバSiはこのコマンドに応答してクライアントインデックスをコントローラAkに返信し、コントローラAkはその取得したクライアントインデックスを保存するS3003。続いて、コントローラAkは、コンテンツサーバSiのプッシュポートに接続するS3004。コントローラAkは、このプッシュポートを通じてクライアントインデックス通知コマンドを発行し、ステップS3003で保存したクライアントインデックスをコンテンツサーバに送信するS3005。これにより、プッシュポートが開通するS3006。続いて、コントローラAkは、クライアントタイプをコマンドポートを通じてコンテンツサーバSiに通知するS3007。ここでは、上記オーディオクライアントCjと異なり、コントローラAkはクライアントタイプとして自身がコントローラであることを通知する。コンテンツサーバSiは、このクライアントタイプによりオーディオクライアントCjとコントローラAkとを区別することができる。続いて、コントローラAkは、オーディオクライアントCjのクライアント情報をコンテンツサーバSiから取得しS3008、その情報に含まれるステータスなどをモニタ上に表示する。そして、コントローラAkは、クライアントタイプ及び取得したクライアントインデックスに基づいて、コンテンツサーバSiに接続されているオーディオクライアントCjの監視ハンドル及び制御ハンドルをコンテンツサーバSiに要求して取得するS3009。上記接続手順がオーディオクライアントCjと相違する点は、コントローラAkは、自身がコントローラであることを示すクライアントタイプをコンテンツサーバSiに通知する点である。また、もう1つの相違点は、コントローラAkが監視ハンドル及び制御ハンドルの両方又は一方を取得する点である。以下、詳述する。1.2.3.1.1.監視ハンドル及び制御ハンドルの取得図52を参照して、コントローラAkは、コンテンツサーバSiに接続されている全オーディオクライアントCjのリストを表示するS30091。コントローラAkは、ユーザの操作に応じてリストの中から監視しようとするオーディオクライアントCjを選択するS30092。ユーザの操作に応じて監視しようとするオーディオクライアントCjを選択するのは本ネットワークオーディオシステムを最初に起動したときだけとし、2回目以降は、最初に選択したオーディオクライアントCjを登録しておき、その登録されたオーディオクライアントを自動的に選択するようにするのが好ましい。続いて、コントローラAkは、その選択されたオーディオクライアントCjのクライアントインデックスをコンテンツサーバSiに送信し、その監視ハンドルを要求するS30093。コンテンツサーバSiは、送信元コントローラAkのクライアントインデックスと、受信したオーディオクライアントCjのクライアントインデックスとを対応づけて記憶しS20001、送信元コントローラAkに対して監視ハンドルを発行するS20002。その結果、コントローラAkは、選択されたオーディオクライアントCjの監視ハンドルを取得するS30094。続いて、コントローラAkは、ユーザの操作に応じてリストの中から制御しようとするオーディオクライアントCjを選択するS30095。そして、コントローラAkは、その選択されたオーディオクライアントCjのクライアントインデックスをコンテンツサーバSiに送信し、その制御ハンドルを要求するS30096。コンテンツサーバSiは、送信元コントローラAkのクライアントインデックスと、受信したオーディオクライアントCjのクライアントインデックスとを対応づけて記憶しS20003、送信元コントローラAkに対して制御ハンドルを発行するS20004。その結果、コントローラAkは、選択されたオーディオクライアントCjの制御ハンドルを取得するS30097。監視ハンドルは、コンテンツサーバSiからコントローラAkに与えられるオーディオクライアントCjを監視する権限である。これにより、オーディオクライアントCjのステータスが変化すると、変化後の新しいステータスがコンテンツサーバSiに通知される。コンテンツサーバSiはプッシュポートを通じてオーディオクライアントCjのクライアント情報をコントローラAkに随時送信し、これに応じてコントローラAkはオーディオクライアントCjのクライアント情報を更新する。本ネットワーク型オーディオシステムでは、オーディオクライアントCjの数が多いほどLAN12に負荷がかかる。また、コントローラAkのコマンドやオーディオクライアントCjのステータスなどの伝送はLAN12上のトラフィックに影響を及ぼす。図53に示すように、複数のコントローラA1~A3が同じLAN12上に存在する場合に、コンテンツサーバSiはオーディオクライアントC1~C3のクライアント情報を全てのコントローラA1~A3に送信するようにすることも可能であるが、このようにすると、ネットワークトラフィック及びコンテンツサーバの負荷が増大する。そこで図54に示すように、コントローラA1がオーディオクライアントC1のみの監視ハンドルを取得し、コントローラA2がオーディオクライアントC2のみの監視ハンドルを取得するようにし、コンテンツサーバSiは、オーディオクライアントC1のクライアント情報をコントローラA1のみに送信し、オーディオクライアントC2のクライアント情報をコントローラA2のみに送信するようにする。コンテンツサーバSiは、オーディオクライアントCjの監視ハンドルを取得しているコントローラAkだけにクライアント情報を送信するので、ネットワークトラフィック及びコンテンツサーバの負荷が軽減される。ただし、コントローラA3が全てのオーディオクライアントC1~C3の監視ハンドルを取得し、コンテンツサーバSiが全てのコントローラA1~A3にクライアント情報を送信するようにしてもよい。一方、制御ハンドルは、コンテンツサーバSiからコントローラAkに与えられるオーディオクライアントCjを制御する権限である。本ネットワーク型オーディオシステムにおいて、コントローラAkが複数存在する場合、いずれのコントローラAkもオーディオクライアントCjを制御できるようにすると、あるコントローラAkからの命令に従ってオーディオクライアントCjが曲を再生している最中に、他のコントローラAkがそのオーディオクライアントCjに再生の停止を命令したり、別の曲の再生を命令するおそれがある。そこで、本システムでは、オーディオクライアントCjの制御ハンドルを取得しているコントローラAkのみがそのオーディオクライアントCjを制御することができ、オーディオクライアントCjの制御ハンドルを取得していないコントローラAkはそのオーディオクライアントCjを制御することができないようにする。コンテンツサーバが制御ハンドルを取得できるコントローラを制限すれば、オーディオクライアントとそれを制御できるコントローラの組み合わせを設定することができる。また、コントローラが制御ハンドル開放コマンドをコンテンツサーバに発行することにより、制御ハンドルを放棄できるようにする。1.2.3.2.モニタ監視機能コントローラAkは、上述したように監視ハンドルを取得することにより、オーディオクライアントCjを監視できるようになる。図55を参照して、コントローラAkはコンテンツサーバSiにクライアント情報を要求しS31、コンテンツサーバSiはこれに応じてクライアント情報を返信しS27、コントローラAkはこれを取得して記憶するS31。又は、コンテンツサーバSiがオーディオクライアントCjからクライアント情報を受信した場合、コンテンツサーバSiはコントローラAkにプッシュポートにてクライアント情報を送信し、コントローラAkはこれを取得して記憶する。そして、コントローラAkは取得したクライアント情報を表示するS32。以下、このコントローラによるモニタ機能を詳細に説明する。図56を参照して、コンテンツサーバSiはコントローラAkからの要求又はオーディオクライアントからのクライアント情報の受信に応じてクライアント情報を送信するS2701。コントローラAkはこのクライアント情報を受信すると、各情報に変更がないかを調べる。すなわち、最初にクライアントインデックスを確認しS3101、どのオーディオクライアントCjのクライアント情報かを記憶しておく。そして、記憶したオーディオクライアントのプロダクトID及びファームウェアIDを確認するS3102、S3103。具体的には、プロダクトIDによってオーディオクライアントの種類を判別し、ファームウェアIDによってファームウェアのバージョンを判別する。もしそのオーディオクライアントに適用されているファームウェアのバージョンが古ければ、コントローラAkはインターネット上のカスタマーサービスにアクセスし、オーディオクライアントCjにファームウェアを配信して自動的に更新する。ファームウェア更新の詳細は後述する。なお、コントローラAkは、受信したクライアント情報を解析してクライアントタイプを確認し、オーディオクライアントCjならそれ用の処理に分岐し、それ以外なら無視するようにする。続いて、コントローラAkは、接続情報に変更がないかをチェックしS3104、変更があればオーディオクライアントCjの接続状態の表示を変更するS3105。したがって、複数のオーディオクライアントCjに電源が入り、それらがコンテンツサーバSiに接続されているか否かをコントローラAkで常に監視することができる。オーディオクライアントCjが接続されていたら、コントローラAkは、ボリューム値に変更がないかをチェックしS3106、変更があればボリューム値の表示を変更するS3107。続いて、コントローラAkは、リスト構築キー後述するに変更がないかをチェックしS3108、変更があればリスト構築キーを用いてコンテンツサーバSiに曲リストを要求するS3109。コンテンツサーバSiはこの要求に応じて曲リストを返信しS2702、コントローラAkはこの曲リストを受信するS3110。コントローラAkは、受信した曲リストをオーディオクライアントCjが再生中の曲リストとして記憶するとともに、現在再生中の曲が曲リストの何曲目かを調べてその番号を記憶するS3111。続いて、コントローラAkは、再生中の曲に変更がないかをチェックしS3112、変更があれば曲のデータフォーマットを確認しS3113、再生中の曲名やアーティスト名の表示を変更しS3114、現在再生中の曲が曲リストの何曲目かを調べてその番号を記憶するS3115。最後に、コントローラAkは、ステータスに変更がないかをチェックしS3116、変更があればステータスの表示を変更するS3117。オーディオクライアントCjがリモコンにより制御される場合も、コントローラAkはそのステータスを監視して表示する。オーディオクライアントCjのステータスが完了ステータスであればS3118、コントローラAkはオーディオクライアントCjにその次の曲を続けて再生するよう命令するS3119。連続再生の詳細は後述する。以上の処理は、コントローラが監視ハンドルを取得した全てのオーディオクライアントのうちいずれかのクライアント情報が変化するたびに繰り返される。また、図示されていないが、コントローラAkは、各オーディオクライアントCjのクライアントタイプを監視する。また、コントローラAkは、再生可能なデータフォーマットを監視し、再生可能な曲名のみを表示する。以上のように、コンテンツサーバがクライアントからクライアント情報を受信した際に、プッシュポートにて強制的にコントローラにクライアント情報を送信することにより、コントローラAkはオーディオクライアントCjを常に監視することができ、また、コンテンツサーバSiからコントローラCLには必要最低限の情報しか送信されない。そのため、コントローラAkにかかる処理の負担が軽減される。また、オーディオクライアントCjが複数あっても、コントローラAkはクライアントインデックスによりオーディオクライアントCjを区別し、各クライアント情報をリアルタイムで更新することができる。1.2.3.3.制御機能コントローラAkは、上述したように制御ハンドルを取得することにより、オーディオクライアントCjを制御できるようになる。図57を参照して、コントローラAkは制御コマンドをコンテンツサーバSiに送信しS33、コンテンツサーバSiはこれを指定されたオーディオクライアントCjに送信するS28。オーディオクライアントCjはこの制御コマンドに従って動作し、そのステータスを変更しS18、その変更したステータスをコンテンツサーバSiに送信するS19。コンテンツサーバSiはこのステータスをコントローラAkに送信しS29、コントローラAkはこれに応じて記憶しているクライアント情報のステータスを変更するS34。1.2.3.3.1.制御コマンド処理次に、図58を参照して、オーディオクライアントCjがコントローラAkからコンテンツサーバSiを通じて受けた制御コマンドに従って行う処理を説明する。オーディオクライアントCjは、プッシュポートに何らかのデータが書き込まれた場合S3001、そのデータを受信して解析するS3002。受信したデータが再生コマンドであればS3003、オーディオクライアントCjは指定されたファイル名をコンテンツサーバSiから取得するS3004。オーディオクライアントCjは、取得したファイル名から、曲名、アルバム、ジャンルなどを特定する。そして、オーディオクライアントCjは曲を指定しかつその曲の音楽データを転送するようコンテンツサーバSiに指令するS3005。オーディオクライアントCjは転送された音楽データに基づいて再生を行う。受信したデータが再生停止コマンドであればS3006、オーディオクライアントCjは曲データ転送要求コマンドの発行を停止することにより音楽データの転送を停止しS3007、停止ステータスをコンテンツサーバSiに送信するS3008。オーディオクライアントCjは、その他、ボリューム値セットコマンド、ポーズコマンド、AVレシーバ制御コマンド、ファームウェアアップデートコマンドなどに応答して、所定の処理を行うS3009~S3010。1.2.3.3.2.再生制御ここで、コントローラAkが再生コマンドに従ってオーディオクライアントCjに所望のアーティストの所望の曲を再生させる動作を説明する。図59を参照して、コントローラAkはオーディオクライアントCjの接続を確認しS3011、接続があればオーディオクライアントCjのファームウェアID及びプロダクトIDを確認するS3012、S3013。続いて、コントローラAkは、クライアントタイプに基づいてオーディオクライアントCjがオーディオクライアント又はAVRクライアントであるか否かを判別するS3014。ここではオーディオクライアントCjであるから、コントローラAkは所望のアーティストの曲リストを既に取得しているか否かを判別するS3015。未だ取得していなければ、コントローラAkはコンテンツサーバSiから所望のアーティストの曲リストを取得するS3016。コントローラAkは、この曲リストを表示装置に表示する。取得された曲リストの中にユーザが再生を希望する曲があればS3017、コントローラAkは、ユーザの入力操作に応じてその曲を選択し、再生コマンドをコンテンツサーバSiに送信するS3018。この再生コマンドは、選択された曲のデータを格納しているファイル名と、曲を再生させようとするオーディオクライアントのクライアントインデックスとを含む。一方、希望する曲がなければ、コントローラAkは再び所望のアーティストの次の曲リストを取得するS3016。コンテンツサーバSiは、コントローラAkから送信されたクライアントインデックスに基づいてオーディオクライアントCjを特定し、そのオーディオクライアントCjに選択された曲のファイル名を送信するS28。オーディオクライアントCjは、コントローラAkからコンテンツサーバSiを通じて送信されてきた再生コマンドに応答して所望の曲を再生し、ステータスを再生ステータスに変更するS18。オーディオクライアントCjは再生ステータスをコンテンツサーバSiに送信しS19、コンテンツサーバSiはその再生ステータスをコントローラAkに送信するS29。コントローラAkはこれに応じてオーディオクライアントCjのステータスを再生ステータスに変更するS34。1.2.3.3.3.再生可能なフォーマットかを識別して再生曲リストには、オーディオクライアントCjが再生可能なフォーマットか否かに関係なく、全てのフォーマットの曲が含まれる。そのため、ユーザが所望の曲を選択したときにコントローラAkがコンテンツサーバSiから取得した曲リストをそのままユーザに対して表示したとすると、次のような問題が生じる。すなわち、ユーザがオーディオクライアントCjが再生できないフォーマットの曲を選択した場合でも、コントローラAkはユーザが選択した曲の再生をオーディオクライアントCjに命令するので、オーディオクライアントCjでは表示は再生状態になっているのに再生音は出ない。そこで図60に示すように、クライアント情報のクライアントタイプに再生可能なフォーマットに関する情報を追加する。よって、クライアントタイプは、クライアントのハードウェア構成に関する情報と、オーディオクライアントが再生可能なフォーマットに関する情報とから構成される。ハードウェア構成に関する情報には、次のようなものがある。オーディオクライアントは、音楽を再生しかつリモコン信号を受信できるオーディオクライアントである。オーディオクライアントは、音楽を再生できるが、リモコン信号を受信できないオーディオクライアントである。コントローラは、コンテンツサーバを介してオーディオクライアントを監視しかつ制御できるクライアントである。AVRクライアントは、EIA-232ポートを持ち、AVレシーバと通信できるクライアントである。AVRコントローラは、コンテンツサーバを介してAVRクライアントを制御しかつ監視できるクライアントである。再生可能なフォーマットに関する情報には、MP3、WAV、WMAなどがある。1つのクライアントのクライアントタイプに、複数のハードウェア構成に関する情報が含まれている場合もあり、また、複数の再生可能なフォーマットに関する情報が含まれている場合もある。次に、コントローラAkがユーザに対して曲リストを表示するときの処理手順を図61を参照して説明する。まずコントローラAkは、曲を再生させようとするオーディオクライアントCjがコンテンツサーバSiに接続されているか否かを判別するS3501。未接続の場合、オーディオクライアントCjは曲を再生できないので、曲リストの全ての曲を再生不可能な曲として表示するか、又は全ての曲を表示しないS3502。したがって、オーディオクライアントCjが再生不可能な曲をユーザが選択するのを防止することができる。一方、既接続の場合、以下のステップS3505~S3507を曲リストの曲数分繰り返すS3503,S3504,S3508。すなわち、コントローラAkは、曲リスト中のn番目の曲のフォーマットがオーディオクライアントCjが再生可能なフォーマットか否かを判別するS3505。再生可能なフォーマットであれば、コントローラAkはその曲を再生可能な曲として表示しS3506、再生不可能なフォーマットであれば、再生不可能な曲として表示するか、又は表示しないS3507。たとえばオーディオクライアントC1がMP3もWAVも再生できる場合、コントローラAkは、図62に示すように、曲リストこの例ではプレイリスト中の全ての曲を表示する。しかし、オーディオクライアントC2がMP3は再生できるが、WAVは再生できない場合は、図63に示すように、曲リスト中のMP3の曲は通常通り表示するが、WAVの曲は淡く表示する。また、曲を淡く表示するのではなく、全く表示しないようにしてもよい。したがって、オーディオクライアントC2が再生不可能なWAVの曲をユーザが選択するのを防止することができる。なお、オーディオクライアントCjの接続状態やクライアントタイプに変更があった場合、コントローラAkは曲リストを表示し直し、現在のオーディオクライアントのクライアント情報をリアルタイムで表示する。次に、ユーザがコントローラAkを操作してオーディオクライアントCjに曲を再生させる場合のコントローラの動作を説明する。図64を参照して、ユーザが再生したい曲を選択すると、コントローラAkはその選択された曲のフォーマットがオーディオクライアントCjが再生可能なフォーマットか否かを判別するS3511。具体的には、コントローラAkは、その選択された曲のフォーマットをクライアントタイプ中の再生可能なフォーマットと比較する。再生可能なフォーマットであれば、コントローラAkは、その選択された曲を再生するようオーディオクライアントCjに命令するS3512。一方、再生不可能なフォーマットであれば、オーディオクライアントCjはその選択された曲を再生できない旨をユーザに知らせるS3513。以上のように、コントローラAkは、オーディオクライアントCjが再生できる曲がユーザにわかるように表示し、これにより、オーディオクライアントCjが再生できない曲の再生をユーザが要求しないようにすることができる。1.2.3.3.4.連続再生制御ユーザがオーディオクライアントCjを操作してそのオーディオクライアントCjで曲を再生している場合は、オーディオクライアントCjは曲リストを取得しているから、その曲リスト中の曲を連続して再生することが可能である。しかし、オーディオクライアントCjがコントローラAkにより指示された曲を再生している場合は、オーディオクライアントCj自身は曲リストを取得していないから、オーディオクライアントCjが曲リスト中の曲を連続して再生するためには、コントローラAkがオーディオクライアントCjに次の曲を指示する必要がある。また、ネットワーク上にコントローラが1つしか存在しない場合は問題とならないが、複数存在する場合は、オーディオクライアントが正常に連続再生を行うことができないという問題が生じる。たとえばオーディオクライアントから再生の完了を通知されたコンテンツサーバが全てのコントローラに再生の完了を通知したとすると、オーディオクライアントは複数のコントローラから連続再生の命令を受けてしまうからである。この問題はネットワーク上にコンテンツサーバが複数存在する場合はさらに複雑になる。したがって、ネットワーク型オーディオシステムにおいてコントローラによる連続再生を可能にするためには、どのコントローラがクライアントに連続再生を命令するのかを管理する必要がある。本実施の形態では、オーディオクライアントCjは、コントローラAkからの命令に従って曲を再生し、その再生を終了したときは完了ステータスを送信するが、それ以外のとき、たとえばユーザの操作に応じてオーディオクライアントCjが自ら曲を再生し、その再生を終了したとき、又はユーザの操作に応じてオーディオクライアントCjが曲の再生を途中で停止したときなどは、完了ステータスとは異なる停止ステータスを送信する。コントローラは、完了ステータスを受信した場合に、連続再生処理すべきと判断し、曲リストの中から前に選択した曲の次の曲を選択し、オーディオクライアントに次の曲を再生するよう命令する。また、コントローラは、停止ステータスを受信した場合には、オーディオクライアントに次の曲を再生するよう命令しない。以上のように、オーディオクライントが状況に応じて完了ステータスと停止ステータスとを区別して送信することにより、コントローラは受信したステータスに基づいて、オーディオクライアントに次の曲の再生を命令すべきか否かを判断することができる。したがって、オーディオクライアントCjがユーザの操作に応じて曲の再生を途中で停止した場合又はオーディオクライアントCjが自ら曲を選択し、その再生を終了した場合には、停止ステータスをコンテンツサーバに送信するので、コントローラが誤ってオーディオクライアントに次の曲を再生するよう命令することを防止できる。さらにコントローラが複数ある場合には、オーディオクライアントから完了ステータスを受信したコンテンツサーバは、各コントローラに対して、完了ステータスと停止ステータスとを区別して送信する。すなわち、図65を参照して、コントローラA1がオーディオクライアントC1に再生を命令する場合、コントローラA1はまずコンテンツサーバSiにオーディオクライアントC1に対する再生コマンドを送信する。コンテンツサーバSiはコントローラA1から再生コマンドを受信し、これをオーディオクライアントC1に送信する。オーディオクライアントC1はコンテンツサーバSiから再生コマンドを受信し、曲の再生を開始する。図66及び図67を参照して、オーディオクライアントC1が曲の再生を終了すると、完了ステータスをコンテンツサーバに送信しS1901、コンテンツサーバSiはこれを受信するS2901。続いて、コンテンツサーバSiは、以下のステップS2903~S2906をクライアント数だけ繰り返すS2902,S2907。コンテンツサーバSiは、クライアントインデックスnに基づいてn番目のクライアントがオーディオクライアントC1の監視ハンドルを取得しているコントローラか否かを判別するS2903。監視ハンドルを取得しているコントローラの場合、コンテンツサーバSiは、n番目のクライアントコントローラがオーディオクライアントC1に再生を命令したコントローラA1か否かを判別するS2904。オーディオクライアントC1に再生を命令したコントローラA1の場合、コンテンツサーバSiは、オーディオクライアントC1から受信した完了ステータスをコントローラA1に送信しS2905、コントローラA1はこれを受信するS3401。一方、オーディオクライアントC1に再生を命令したコントローラA1以外のコントローラA2の場合、コンテンツサーバSiは、オーディオクライアントC1から受信した完了ステータスに代えて、停止ステータスをコントローラA2に送信しS2906、コントローラA2はこれを受信するS3402。図68を参照して、完了ステータスを受信したコントローラA1は、曲リストの中から前に選択した曲の次の曲を選択し、その曲をオーディオクライアントC1に再生させるための再生コマンドをコンテンツサーバSiに送信するS3403。コンテンツサーバSiはこれを受信し、オーディオクライアントC1に送信する。オーディオクライアントC1は、コンテンツサーバSiから送信された再生コマンドに従って次の曲を再生する。一方、停止ステータスを受信したコントローラA2は、オーディオクライアントC1は停止状態にあると判断し、コントローラA1のような連続再生処理を行わない。オーディオクライアントCjは、ステータスが再生になると再生ステータスをコンテンツサーバSiに送信し、ステータスが一時停止になるとポーズステータスをコンテンツサーバSiに送信し、自らが指定した曲の再生が終了すると停止ステータスをコンテンツサーバSiに送信するが、上述したように、コントローラAkが指定した曲の再生が終了すると完了ステータスをコンテンツサーバSiに送信する。以上のように、オーディオクライアントCjが曲の再生を終了したときにコンテンツサーバSiがコントローラAkに送信するステータスを停止ステータスと完了ステータスとに区別することにより、コントローラAkは自ら再生を命令したオーディオクライアントCjが曲の再生を終了したのか否かを判断することができる。その結果、コントローラAkはオーディオクライアントCjに連続再生を命令する必要があるのか、オーディオクライアントCjの停止ステータスを表示するだけでいいのかを判断することができる。なお、オーディオクライアントCjが曲の再生を終了したとき、専用リモコンからの命令に従って曲を再生していた場合と、監視ハンドル及び制御ハンドルの両方を取得しているコントローラAkからの命令に従って曲を再生していた場合とで、コンテンツサーバSiに通知するステータスを区別するようにしてもよい。制御ハンドルしか取得していない専用リモコンはコンテンツサーバSiからステータスを受信することができないから、連続再生処理を行うことができないからである。1.2.3.3.5.リスト構築キーを用いた連続再生制御コントローラAkは、コンテンツサーバSiからさまざまな曲リストを取得してその中から曲を選択し、その曲をオーディオクライアントCjに再生させる。そして、コントローラAkは、オーディオクライアントCjのステータスを監視し、オーディオクライアントCjが選択された曲の再生を終了すると、取得している曲リストの中から次の曲を選択し、その曲をオーディオクライアントCjに再生させる。コントローラAkはこのようにしてオーディオクライアントCjに連続的に曲を再生させているが、次の曲の再生を命令するためには曲リストを記憶しておく必要がある。そのため、曲の再生を命令しているコントローラAkの電源は曲の再生中に切ることができない。そこで、オーディオクライアントCjに再生を命令したコントローラAkの電源を途中で切っても、コントローラAkがオーディオクライアントCjに連続再生を命令できるように、以下のような方法を採用する。ユーザがコンテンツ情報データベースの中から再生したい曲を選択するときには、あるアーティストの曲リストから選択したり、あるジャンルの曲リストから選択するなど、さまざまな曲リストを利用する。そこで、コンテンツ情報データベースから一意に曲リストを作成することができるように、リスト構築キーを定義する。そして、このリスト構築キーを、オーディオクライアントCjが再生中の曲リストを特定するための情報としてクライアント情報に付加する。図69を参照して、リスト構築キーはフィルタの種類とキーワードとから構成される。フィルタの種類は、コンテンツ情報データベース中のどのカテゴリに注目して曲リストを作成するかを指定するもので、図70に示すようなものがある。フィルタの種類がTITLE=、GENRE=、ARTIST=、ALBUM=、又はFILENAME=であれば、コンテンツ情報データベースの中から、曲名、ジャンル名、アーティスト名、アルバム名、又はファイル名がキーワードと一致する曲を探し出して曲リストを作成する。フィルタの種類がPLAYLIST=であれば、プレイリストのファイル名がキーワードと一致するプレイリストに登録されている曲をコンテンツ情報データベースから探し出して曲リストを作成する。たとえば、アーティスト名xxxxの曲リストの場合、フィルタの種類はARTIST=、キーワードはxxxxとなるから、リスト構築キーはARTIST=xxxxとなる。また、キーワードとしてを指定すると、そのフィルタの種類に対して使用できるキーワードのリストが作成される。たとえばリスト構築キーARTIST=から作成されるリストは、コンテンツ情報データベースに登録されている曲のアーティスト名のリストが作成される。以下にコントローラが指定した曲の再生が終了したオーディオクライアントに対して、コントローラが連続再生処理を行う手順について説明する。図71を参照して、コントローラAkから再生するよう命令されたオーディオクライアントCjが曲の再生を終了すると、完了ステータスをコンテンツサーバSiに送信する。コンテンツサーバSiは、オーディオクライアントCjのステータスが変化したので、完了ステータス、再生していた曲のファイル名、リスト構築キーなどを含むクライアント情報をコントローラAkに送信する。コントローラAkはクライアント情報を受信すると、図56に示したクライアント情報表示処理を開始する。この処理は既に説明したので、ここでは主としてリスト構築キーを用いた連続再生制御に関する部分を説明する。コントローラAkは、リスト構築キーに変更がないかチェックしS3108、変更があった場合はリスト構築キーを用いてオーディオクライアントCjが再生中の曲リストをコンテンツサーバSiから取得するS3110。詳細には、受信したリスト構築キーをコンテンツサーバに送信し、コンテンツサーバはこのリスト構築キーに基づいてリストを作成し、コントローラに送信する。電源が切られ、コントローラAkがオーディオクライアントCjが再生中の曲リストを記憶していない場合も、コンテンツサーバと接続した後に取得するリスト構築キーを用いて再生中の曲リストをコンテンツサーバSiから取得する。ここでは、ステータスが完了ステータスに変化しているから、コントローラAkは完了処理を行うS3119。すなわち、コントローラAkは、オーディオクライアントCjが再生を終了した曲の次の曲を曲リストから選択し、その選択した曲を再生するようオーディオクライアントCjに命令する。図72を参照して、完了処理の詳細を説明する。コントローラAkは、図56中のステップS3111で記憶した再生曲番号nをインクリメントしS31191、次に再生すべき曲を指定する。続いて、コントローラAkは、再生曲番号nが曲リストの曲数以下か否かを判別するS31192。再生曲番号nが曲リストの曲数を超えていれば、コントローラAkは、オーディオクライアントCjが曲リストの最後まで再生したと判断して再生曲番号nを1に設定しS31193、次に再生すべき曲を曲リストの最初の曲に戻す。再生曲番号nが曲リストの曲数以下であれば、コントローラAkは、n番目の曲がオーディオクライアントCjで再生可能なフォーマットか否かをチェックしS31194、再生可能なフォーマットであれば、曲リストのn番目の曲を再生するようオーディオクライアントCjに命令するS31195。再生不可能なフォーマットであれば、さらに次の曲を再生するために再帰的にこの完了処理を行う。要するに、コントローラAkは、オーディオクライアントCjが再生不可能なフォーマットの曲を飛ばし、その次の曲を再生するようオーディオクライアントCjに命令する。以上のように、オーディオクライアントCjに曲を再生するよう命令した後にコントローラAkの電源を切ると、コントローラAkはオーディオクライアントCjに再生を命令したときの曲リストを消失してしまう。しかし、電源を再投入し、コンテンツサーバとの接続が完了すると、図51のS3008にて説明した通り、コントローラAkはコンテンツサーバSiからオーディオクライアントCjのクライアント情報を取得する。このクライアント情報にはリスト構築キーが含まれているから、コントローラAkはこのリスト構築キーに基づいてクライアントCLが再生中の曲リストを再び取得することができる。したがって、コントローラAkがオーディオクライアントCjに曲を再生するよう命令した後にその電源が切られた場合であっても、オーディオクライアントCjが曲の再生を終了し、完了ステータスを送信し、この完了ステータスをコントローラAkが受信したときには、取得し直した曲リストに従ってその次の曲を再生するようオーディオクライアントCjに命じることができる。なお、オーディオクライアントCjの再生動作を停止させるためには、コントローラAkは停止コマンドをコンテンツサーバSiを通じてオーディオクライアントCjに送信すればよい。この場合、停止ステータスがオーディオクライアントCjからコンテンツサーバSiを通じてコントローラAkに返信される。また、オーディオクライアントCjの再生動作を一時停止させるためには、コントローラAkは一時停止コマンドをコンテンツサーバSiを通じてオーディオクライアントCjに送信すればよい。この場合、ポーズステータスがオーディオクライアントCjからコンテンツサーバSiを通じてコントローラAkに返信される。1.2.3.3.6.優先順位を付けた連続再生制御本実施の形態をコンテンツサーバS1及びオーディオクライアントC1に着目して説明する。本実施の形態では、コンテンツサーバS1のHDD14にコントローラ管理テーブルが格納されている。コントローラ管理テーブルの一例を次の表1に示す。コントローラ管理テーブルには、オーディオクライアントC1を制御する優先順位と、コントローラA1~Akに付与されたコントローラインデックスとが対応づけて記録される。本実施の形態では、コンテンツサーバS1~Si、オーディオクライアントC1~Cj及びコントローラA1~Akには、図73に示したステップを実行するためのコンピュータプログラムがそれぞれインストールされている。以下、本実施の形態によるネットワーク型オーディオシステム10の動作を図73に示したフロー図を参照して説明する。最初に、コントローラA1がコンテンツサーバS1に接続を要求し、コンテンツサーバS1がこの要求を受け入れると、コントローラA1とコンテンツサーバS1との間で接続が確立するS30301。コントローラA1に続いて、コントローラA2がコンテンツサーバS1に接続を要求し、コンテンツサーバS1がこの要求を受け入れると、コントローラA2とコンテンツサーバS1との間で接続が確立するS30401。これに対し、コンテンツサーバS1は、コントローラ管理テーブルに、優先順位第1位に対応づけてコントローラA1のコントローラインデックスを記録し、さらに優先順位第2位に対応づけてコントローラA2のコントローラインデックスを記録するS20101。その結果、上記表1に示したコントローラ管理テーブルが得られる。このコントローラ管理テーブルによれば、コントローラA1が最優先で連続再生処理の権限を有し、その次にコントローラA2が連続再生処理の権限を有する。以下、コントローラA1がコンテンツサーバS1経由でオーディオクライアントC1に複数曲の連続再生を命令する場合の動作を説明する。コントローラA1は、連続再生の対象となる曲リストをコンテンツサーバS1に要求するS30302。具体的には、曲リストを作成するために必要なリスト構築キーをコンテンツサーバS1に送信する。ユーザは、コンテンツサーバS1の中から再生したい曲を選択するとき、あるアーティストの曲リストから選択したり、あるジャンルの曲リストから選択したりするなど、さまざまな曲リストを利用する。リスト構築キーは、このような曲リストをコンテンツサーバS1の中から抽出して一意に作成するための検索キーでる。リスト構築キーは図69に示したように、フィルタの種類及びキーワードという2つのパラメータから構成される。フィルタの種類は、曲リストに入れるべき曲のカテゴリを指定するもので、具体的には図70に示したとおりである。コンテンツサーバS1は、コントローラA1から送信されたリスト構築キーに基づいて曲リストを作成し、コントローラA1に送信するS20102。具体的には、フィルタの種類がTITLE=、GENRE=、ARTIST=、ALBUM=、又はFILENAME=であれば、曲名、ジャンル名、アーティスト名、アルバム名、又はファイル名がキーワードと一致する1又は2以上の曲を探し出し、その曲を列挙した曲リストを作成する。フィルタの種類がPLAYLIST=であれば、プレイリストのファイル名がキーワードと一致するプレイリストに登録されている曲を探し出し、その曲を列挙した曲リストプレイリストを作成する。また、コンテンツサーバS1は、オーディオクライアントC1のクライアント情報の1つとして、リスト構築キーをクライアントインデックスオーディオクライアントC1の識別情報に対応づけて登録する。コントローラA1は、取得した曲リストの中からユーザの操作に応じて指定された曲の再生をコンテンツサーバS1経由でオーディオクライアントC1に命令するS30303。オーディオクライアントC1は、コントローラA1からの再生命令に応じて、指定された曲の音楽コンテンツをコンテンツサーバS1に要求するS10201。コンテンツサーバS1は、オーディオクライアントC1から要求された音楽コンテンツをオーディオクライアントC1に配信するS20103。オーディオクライアントC1は、コンテンツサーバS1から送信された音楽コンテンツに基づいて曲の再生を開始するS10202。オーディオクライアントC1は指定された曲を最後まで再生し終えると、その旨を示す完了ステータスをコンテンツサーバS1に送信するS10203。コンテンツサーバS1はオーディオクライアントC1から完了ステータスを受信すると、図74に示すように、コントローラ管理テーブル104を参照し、最高順位のコントローラA1に完了ステータスをそのまま転送し、それよりも下位のコントローラA2に完了ステータスと異なる停止ステータスを送信するS20104。コントローラA1は、図74に示すように、曲リストに従って次の曲を連続して再生するようにコンテンツサーバS1経由でオーディオクライアントC1に命令するS30304。オーディオクライアントC1は、コントローラA1からの連続再生命令に応じてその次の曲を再生する。以後、オーディオクライアントC1は上記ステップS201以降の動作を繰り返す。他方、コントローラA2は、コンテンツサーバS1から停止ステータスを受信しても特に能動的なアクションを起こさず、単にオーディオクライアントC1の状態を監視する。なお、コントローラA1~AkがコンテンツサーバS1から切断されると、コンテンツサーバS1はコントローラ管理テーブル104を更新する。具体的には、コンテンツサーバS1から切断されたコントローラのコントローラインデックスを削除し、それよりも下位のコントローラインデックスの優先順位を順次繰り上げる。たとえば図75に示すように、優先順位が最高のコントローラA1がコンテンツサーバS1から切断されたときは、その次の優先順位のコントローラA2が繰り上がり、コントローラA1に代わって連続再生処理の権限を獲得する。また、上述した例ではコントローラA1が最初に再生を命令し、再び同じコントローラA1が連続再生を命令しているが、コントローラA2が最初に再生を命令した場合であってもコントローラA1の優先順位が最高である限りコントローラA1が連続再生を命令する。この場合、コントローラA1はコンテンツサーバS1から完了ステータスを受信しても曲リストを有していないので、コンテンツサーバS1に登録されているオーディオクライアントC1のリスト構築キーを利用してコンテンツサーバS1から曲リストを取得し、これに従って次の曲を指定する。また、曲リストに含まれる全ての曲が1つのコンテンツサーバS1に蓄積されているとは限らず、複数のコンテンツサーバS1,Siに分散して蓄積されている場合もある。この場合、オーディオクライアントC1はコンテンツサーバS1の曲を再生した後、引き続き別のコンテンツサーバSiの曲を再生する必要がある。そのため、コンテンツサーバS1の曲を再生し終えたオーディオクライアントC1はコンテンツサーバS1との接続を一旦解除し、コンテンツサーバSiに接続し直すというサーバ切換処理を行う。コンテンツサーバSiに接続し直したオーディオクライアントC1は、コントローラA1からの再生命令に応じて、指定された曲の音楽コンテンツをコンテンツサーバSiに要求し、コンテンツサーバSiは要求された音楽コンテンツをオーディオクライアントC1に配信する。オーディオクライアントC1はその曲を再生し終えると、完了ステータスをコンテンツサーバSiに送信する。コンテンツサーバSiは完了ステータスを受信すると、その内部にあるコントローラ管理テーブルを参照し、最高順位のコントローラに完了ステータスを転送し、それよりも下位のコントローラに停止ステータスを送信する。ここで、コンテンツサーバSiにあるコントローラ管理テーブルはコンテンツサーバS1にあるコントローラ管理テーブルと同じであっても異なっていてもよい。複数のコンテンツサーバが同じコントローラ管理テーブルを使用するためには、たとえばあるコンテンツサーバがコントローラ管理テーブルの優先順位を決定し、そのコントローラ管理テーブルを他のコンテンツサーバに転送するようにすればよい。一方、複数のコンテンツサーバが異なるコントローラ管理テーブルを使用するためには、たとえば各コンテンツサーバが独自にコントローラ管理テーブルの優先順位を決定するようにすればよい。以上のように本実施の形態によれば、コンテンツサーバS1がオーディオクライアントC1から完了ステータスを受信したとき、コントローラ管理テーブルを参照し、最優先のコントローラA1にのみ完了ステータスを送信し、他のコントローラA2には停止ステータスを送信しているため、最優先のコントローラA1のみが連続再生を命令し、他のコントローラA2が連続再生を命令することはない。したがって、連続再生命令の競合を排除し、正常に連続再生処理を実行することができる。上記実施の形態では優先順位はコンテンツサーバS1との接続順で決定されているが、これに限定されることなく、たとえばオーディオクライアントC1に命令を出した順で決定されてもよい。また、コンテンツサーバは複数ある必要はなく、少なくとも1つあればよい。オーディオクライアントも複数ある必要はなく、少なくとも1つあればよい。1.2.3.3.7.制御ハンドルを利用した連続再生制御本実施の形態では、図76に示したステップを実行するためのコンピュータプログラムがコンテンツサーバS1~Si、オーディオクライアントC1~Cj及びコントローラA1~Akにそれぞれインストールされている。本実施の形態も上記実施の形態と同様に、複数のコントローラA1~Akを備えたネットワーク型オーディオシステムに適用可能で、コンテンツサーバ又はオーディオクライアントは少なくとも1つあればよい。上記実施の形態と異なり本実施の形態では、コントローラA1~Akに制御ハンドル管理テーブルが格納されている。制御ハンドル管理テーブルの一例を次の表2に示す。制御ハンドル管理テーブルには、オーディオクライアントC1~Cjのクライアントインデックスと、オーディオクライアントC1~Cjの制御ハンドルを取得しているコントローラA1~Akのコントローラインデックスとが対応づけて記録される。制御ハンドルは、オーディオクライアントを制御する権限を示すものである。表2の例では、オーディオクライアントC1の制御ハンドルはコントローラA1により取得されているが、オーディオクライアントC2及びCjの制御ハンドルはいずれのコントローラにも取得されていない。以下、コンテンツサーバS1、オーディオクライアントC1及びコントローラA1に着目し、図76に示したフロー図を参照して本実施の形態の動作を説明する。なお、図76では上記第1の実施の形態で詳述した曲リストの取得ステップ図73中のS30302,S20102は割愛されている。コントローラA1は、オーディオクライアントC1に再生を命令する前に、オーディオクライアントC1を制御するために必要な制御ハンドルを取得する。具体的には、コントローラA1は制御ハンドル管理テーブルを参照し、オーディオクライアントC1の制御ハンドルがロックされているか否かを判断するS30311。オーディオクライアントC1の制御ハンドルが既に他のコントローラA2~Akのいずれかに取得されている場合、表2に示した制御ハンドル管理テーブルにおいて、オーディオクライアントC1のクライアントインデックスに対応して当該コントローラのコントローラインデックスが記録されている。このように制御ハンドルが既に取得されている状態を制御ハンドルがロックされているという。他方、オーディオクライアントC1の制御ハンドルが未だ他のコントローラA2~Akのいずれにも取得されていない場合、オーディオクライアントC1のクライアントインデックスに対応していずれのコントローラインデックスも記録されていない。このように制御ハンドルが未だ取得されていない状態を制御ハンドルがロックされていないアンロックされているという。たとえば表2に示した制御ハンドル管理テーブルでは、オーディオクライアントC2の制御ハンドルはロックされていない。オーディオクライアントC1の制御ハンドルがロックされている場合、コントローラA1は制御ハンドルの取得に失敗する。他方、ロックされていない場合、コントローラA1はコンテンツサーバS1に制御ハンドルの取得を要求するS30312。この要求に応じて、コンテンツサーバS1はコントローラA1に制御ハンドルの取得を許可するS20111。これにより、コントローラA1は制御ハンドルを取得し、さらにこの制御ハンドルを他のコントローラA2~Akに取得されないようにロックするS30313。具体的には、コントローラA1は制御ハンドル管理テーブルを更新し、これによりオーディオクライアントC1のクライアントインデックスに対応づけてコントローラA1のコントローラインデックスを記録する。コンテンツサーバS1は他のコントローラA2~Akの制御ハンドル管理テーブルもこれに同期するよう更新する。制御ハンドルを取得したコントローラA1は、曲リストの中からユーザの操作に応じて指定された曲の再生をコンテンツサーバS1経由でオーディオクライアントC1に命令するS30314。コンテンツサーバS1はこの再生命令をオーディオクライアントC1に転送するS20112。オーディオクライアントC1はこの再生命令に応じて指定された曲の再生を開始するS10211。オーディクライアントC1はその曲を最後まで再生し終えると、図77に示すように、完了ステータスをコンテンツサーバS1に送信するS10212。コンテンツサーバS1はこの完了ステータスを全てのコントローラA1~Akに転送するS20113。コントローラA1は、自身が制御ハンドルを取得しているオーディオクライアントC1からの完了ステータスか否かを判断しS30315、そうであれば連続再生処理を実行しS30316、そうでなければ完了ステータスを無視し、単にオーディオクライアントC1の状態を監視する。本例では、コントローラA1はオーディオクライアントC1の制御ハンドルを取得しているから連続再生処理を実行しS30316、曲リストに従って次の曲の再生を命令するS30314。一方、オーディオクライアントC1は、曲を最後まで再生することなく、曲の途中で再生を停止した場合、停止ステータスをコンテンツサーバS1に送信するS10213。コンテンツサーバS1はこの停止ステータスを全てのコントローラA1~Akに転送するS20114。コントローラA1は、自身が制御ハンドルを取得しているオーディオクライアントC1からの停止ステータスか否かを判断しS30317、そうであればオーディオクライアントC1の制御ハンドルを解除アンロックしS30318、そうでなければ停止ステータスを無視する。コントローラA1は上記のように自身が制御ハンドルを取得しているオーディオクライアントC1から停止ステータスを受信した場合のほか、コンテンツサーバS1から切断された場合にもその取得している制御ハンドルを解除する。オーディオクライアントC1の制御ハンドルが解除されると、コントローラA1~Akのいずれもこの制御ハンドルの取得が可能となる。なお、曲リストに含まれる曲が複数のコンテンツサーバS1,Siに分散して蓄積されている場合、上記第1の実施の形態と同様に、オーディオクライアントC1は図77に示すようにコンテンツサーバS1から別のコンテンツサーバSiに接続を切り換えることになる。コンテンツサーバSiはオーディオクライアントC1から完了ステータスを受信しても、オーディオクライアントC1がどのコントローラA1~Akから命令された曲を再生し終えたのか不明である。したがって、この場合もコンテンツサーバSiは全てのコントローラA1~Akに完了ステータスを転送するが、コントローラA1~Akは制御ハンドル管理テーブルを有しているため、自身が制御ハンドルを取得しているオーディオクライアントからの完了ステータスを受信したときのみ連続再生処理を実行する。本例では、コントローラA1がオーディオクライアントC1の制御ハンドルを取得しているから、このコントローラA1のみが連続再生処理を実行する。以上のように本実施の形態によれば、コントローラA1~Akの各々が制御ハンドル管理テーブルを有しているため、オーディオクライアントC1から送信された完了ステータスをコンテンツサーバS1が全てのコントローラA1~Akに転送しても、コントローラA1~Akの各々は制御ハンドルを取得しているオーディオクライアントからの完了ステータスを受信したときのみ連続再生処理を実行する。したがって、連続再生命令の競合を排除し、正常に連続再生処理を実行することができる。なお、本実施の形態では制御ハンドル管理テーブルはコントローラA1~Akに格納されているが、コンテンツサーバS1~Siに格納されていてもよい。また、制御ハンドルをロックするのではなく、最後に命令したコントローラが制御ハンドルを取得できるようにしても構わない。すなわち、あるコントローラA1があるクライアントC1の制御ハンドルを取得している際に、別のコントローラA2がクライアントC1に再生を命令した場合、コントローラA2が制御ハンドルを取得し、コントローラA1は制御ハンドルを失うようにしてもよい。1.2.3.3.8.コンテンツサーバによる連続再生制御最初に、コンテンツサーバ、オーディオクライアント及びコントローラをそれぞれ1つずつ備えた単純な例を図78を参照して説明する。上記実施の形態と同様に、コントローラA1は曲の再生をコンテンツサーバS1経由でオーディオクライアントC1に命令する。オーディオクライアントC1はこの命令に応じてその曲の音楽コンテンツをコンテンツサーバS1に要求し、コンテンツサーバS1はこの要求に応じてその音楽コンテンツをオーディオクライアントC1に配信する。オーディオクライアントC1は配信された音楽コンテンツに基づいて曲の再生を開始し、その曲を最後まで再生し終えると完了ステータスをコンテンツサーバS1に送信する。コンテンツサーバS1はこの完了ステータスを受信すると、上記実施の形態と異なり、次の曲の連続再生をオーディオクライアントC1に自ら命令するとともに、停止ステータスをコントローラA1に送信する。以下、この詳細を図79に示したフロー図を参照して説明する。本実施の形態では図79に示したステップを実行するためのコンピュータプログラムがコンテンツサーバS1、オーディオクライアントC1及びコントローラA1にそれぞれインストールされている。図79中のステップS30323,S10221,S20123~S21125が図73に示した実施の形態と異なるので、ここではこれらを中心に説明する。コントローラA1は上記実施の形態と同様に曲の再生をオーディオクライアントC1に命令するが、上記実施の形態と異なり、さらにステップS30302で曲リストを取得するために用いたリスト構築キーをオーディオクライアントC1に送信するS30323。オーディオクライアントC1は上記第1の実施の形態と同様に指定された曲の音楽コンテンツをコンテンツサーバS1に要求し、コントローラA1から送信されたリスト構築キーをコンテンツサーバS1に転送するS10221。コンテンツサーバS1は上記実施の形態と同様に指定された曲の音楽コンテンツをオーディオクライアントC1に配信するが、上記実施の形態と異なり、オーディオクライアントC1から転送されたリスト構築キーに基づいて曲リストを作成するS20123。リスト構築キー及び曲リストは、クライアント情報として、オーディオクライアントC1のクライアントインデックスに対応づけて記録される。これによりコンテンツサーバS1は、オーディオクライアントC1がコントローラA1からの命令に応じて再生している曲リストを把握していることになる。音楽の再生終了後、オーディオクライアントC1から完了ステータスを受信したコンテンツサーバS1は、上記実施の形態と異なり、停止ステータスをコントローラA1に送信するS20124。そして、コンテンツサーバS1はステップS20123で作成した曲リストに従って次の曲の再生をオーディオクライアントC1に命令するS20125。以上のように本実施の形態によれば、コンテンツサーバS1自らが連続再生を命令するため、コントローラからの連続再生命令が競合することはなく、正常に連続再生処理を実行することができる。上記の例はオーディオクライアントが1つしかないが、2つ以上あってもよい。たとえば図80に示した例では、オーディオクライアントC1及びC2がコンテンツサーバS1に接続されている。上記ステップS123と同様に、コンテンツサーバS1は、オーディオクライアントC1及びC2が再生中のリスト構築キー及び曲リストをそれぞれ記憶している。完了ステータスがオーディオクライアントC1からコンテンツサーバS1に送信されると、コンテンツサーバS1は記憶したオーディオクライアントC1の曲リストに従ってオーディオクライアントC1に連続再生を命令し、コントローラA1に停止ステータスを送信する。また、完了ステータスがオーディオクライアントC2からコンテンツサーバS1に送信されると、コンテンツサーバS1は記憶したオーディオクライアントC2の曲リストに従ってオーディオクライアントC2に連続再生を命令し、コントローラA1に停止ステータスを送信する。このようにコンテンツサーバS1はオーディオクライアントC1及びC2を区別して連続再生を命令しているから、連続再生命令が競合することはない。また、オーディオクライアントだけでなく、コンテンツサーバも2つ以上あってもよい。たとえば図81に示した例では、オーディオクライアントC1及びC2がコンテンツサーバS1に接続され、オーディオクライアントC3がコンテンツサーバS2に接続されている。この場合も、各クライアントに接続されているコンテンツサーバは1つであるから、オーディオクライアントは接続されているコンテンツサーバにのみ完了ステータスを送信する。上記と同様に、コンテンツサーバS1はオーディオクライアントC1から完了ステータスを受信するとオーディオクライアントC1に連続再生を命令し、オーディオクライアントC2から完了ステータスを受信するとオーディオクライアントC2に連続再生を命令する。さらにこの場合、コンテンツサーバS2はオーディオクライアントC3から完了ステータスを受信するとオーディオクライアントC3に連続再生を命令する。したがってこの場合も、オーディオクライアントに連続再生を命令するコンテンツサーバはネットワーク上で唯一でとなるから、連続再生命令が競合することはない。また、図81に示した場合において、コントローラA1がコンテンツサーバS2に蓄積されている曲の再生をコンテンツサーバS1経由でオーディオクライアントC2に命令したとき、図82に示すようにオーディオクライアントC2はコンテンツサーバS1との接続を一旦解除し、コンテンツサーバS2に接続し直す。このとき、コンテンツサーバS2は、オーディオクライアントC2から送信されたリスト構築キーに基づいて曲リストを作成し、オーディオクライアントC2のクライアント情報としてこのリスト構築キー及び曲リストを記憶する。オーディオクライアントC2はコンテンツサーバS2から配信された曲の再生を終えると、コンテンツサーバS2に完了ステータスを送信する。コンテンツサーバS2はこの完了ステータスに応じてオーディオクライアントC2に連続再生を命令するとともに、停止ステータスをコントローラA1に送信する。したがってこの場合も、オーディオクライアントに連続再生を命令するコンテンツサーバはネットワーク上で唯一でとなるから、連続再生命令が競合することはない。また、オーディオクライアント及びコンテンツサーバだけでなく、コントローラも2つ以上あってもよい。たとえば図83に示した例ではコントローラA1及びA2がある。コンテンツサーバS1はオーディオクライアントC1又はC2から完了ステータスを受信したとき、コントローラA1だけでなくコントローラA2にも停止ステータスを送信する。コンテンツサーバS2もまたオーディオクライアントC3から完了ステータスを受信したとき、コントローラA1だけでなくコントローラA2にも停止ステータスを送信する。このようにコントローラA1及びA2は連続再生を命令する機能を有さず、単にオーディオクライアントC1~C3の状態を監視する機能を有するだけであるから、何ら連続再生処理に影響を与えない。1.2.3.3.9.オーディオクライアント自身による連続再生制御本実施の形態では、図84に示したステップを実行するためのコンピュータプログラムがコンテンツサーバS1~Si、オーディオクライアントC1~Cj及びコントローラA1~Akにそれぞれインストールされている。図84中のステップS10233~S10235が図79に示した実施の形態と異なるので、ここではこれらを中心に説明する。図79に示した実施の形態と同様に、コントローラA1は指定された曲の再生をオーディオクライアントC1に命令するとともに、リスト構築キーをオーディオクライアントC1に送信しS30323、オーディオクライアントC1は指定された曲をコンテンツサーバS1に要求し、さらにこの要求に応じてコンテンツサーバS1から配信された曲の再生を開始するS10202。このとき、オーディオクライアントC1はコントローラA1から送信されたリスト構築キーを記憶しておく。続いて、オーディオクライアントC1は記憶したリスト構築キーをコンテンツサーバS1に送信し、コントローラA1で選曲に使用した曲リストと同じ曲リストをコンテンツサーバS1に要求するS10233。コンテンツサーバS1は受信したリスト構築キーに基づいて曲リストを作成し、オーディオクライアントC1に送信するS20133。オーディオクライアントC1は受信した曲リストを記憶するとともに、その曲リストの中から現在再生中の曲を特定するS10234。オーディオクライアントC1はその曲を最後まで再生し終えると、記憶した曲リストに従って次の曲を再生するS10235。なお、曲リストに含まれる曲が複数のコンテンツサーバに分散して蓄積されている場合、オーディオクライアントC1は上記と同様にサーバ切換処理を行う。以上のように本実施の形態によれば、オーディオクライアントC1自身がリスト構築キーを保持し、それを利用して曲リストを取得しているため、自ら連続再生処理を実行することができる。したがって、オーディオクライアントC1がコントローラA1やコンテンツサーバS1から連続再生命令を受けることはなく、連続再生命令が競合することはない。本実施の形態でオーディオクライアントC1がリスト構築キーを利用して曲リストを取得しているのは曲の再生中であるが、曲の再生終了後であってもよい。また、オーディオクライアントC1は取得した曲リストを記憶しているが、記憶しないで、連続再生処理を実行するたびにリスト構築キーを利用して曲リストを取得してもよい。1.2.3.3.10.再生命令管理テーブルを利用した連続再生制御本実施の形態では、図85に示したステップを実行するためのコンピュータプログラムがコンテンツサーバS1~Si、オーディオクライアントC1~Cj及びコントローラA1~Akにそれぞれインストールされている。図85中のステップS30341~S30345,S20141が図76に示した実施の形態と異なるので、ここではこれらを中心に説明する。本実施の形態におけるコンテンツサーバS1には、クライアントインデックスとコントローラインデックスとを対応づけた再生命令管理テーブルが記憶されている。このテーブルの一例を次の表3に示す。表3に示した再生命令管理テーブルには、オーディオクライアントC1に再生を命令した最新のコントローラA1のコントローラインデックスが記録されている。また、オーディオクライアントC2に再生を命令した最新のコントローラA2のコントローラインデックスが記録されている。次に、図85に示したフロー図を参照し、本実施の形態の動作を説明する。あるコントローラは、あるコンテンツサーバに蓄積されている曲の再生をあるオーディオクライアントに命令するS30341。まず図86に示すように、コントローラA1がコンテンツサーバS1に蓄積されている曲の再生をコンテンツサーバS1経由でオーディオクライアントC1に命令する場合を説明する。この例では、オーディオクライアントC1及びC2並びにコントローラA1~A3がコンテンツサーバS1に接続されている。コントローラA1は、コンテンツサーバS1にオーディオクライアントC1が接続されているか否かを判断するS30342。この例ではオーディオクライアントC1はコンテンツサーバS1に接続されているので、ステップS30314に進む。コントローラA1は、曲リストの中から指定された曲の再生をコンテンツサーバS1経由でオーディオクライアントC1に命令するS30314。コンテンツサーバS1は、この再生命令に応じて予め定められた再生命令管理処理を実行するS20141。具体的には図87を参照して、コンテンツサーバS1は、再生命令管理テーブルにおけるオーディオクライアントC1のクライアントインデックスに対応づけて、コントローラA1のコントローラインデックスを記録するS201441。これによりコンテンツサーバS1は、コントローラA1がオーディオクライアントC1に最後に再生を命令したコントローラであることを記憶していることになる。コンテンツサーバS1は、コントローラA1からの再生命令をオーディオクライアントC1に転送するS201412。オーディオクライアントC1はコントローラA1からの再生命令に応じて曲の再生を開始しS10211、その再生を終えると、完了ステータスをコンテンツサーバS1に送信するS10212。コンテンツサーバS1はオーディオクライアントC1から完了ステータスを受信すると、再生命令管理テーブルを参照してオーディオクライアントC1に最後に再生を命令したコントローラA1を特定し、そのコントローラA1に完了ステータスを送信するとともに、他のコントローラA2及びA3に停止ステータスを送信するS201413。完了ステータスを受信したコントローラA1はオーディオクライアントC1に連続再生処理を実行するS30316。他方、停止ステータスを受信したコントローラA2及びA3は何ら能動的なアクションを起こさず、単にオーディオクライアントC1の状態を監視する。また、オーディオクライアントC1がコントローラA1からの命令に従って曲を再生している場合において、別のコントローラA2が同じオーディオクライアントC1に別の曲の再生を命令すると、オーディオクライアントC1は現在の曲の再生を中止し、コントローラA2からの命令に従って新たな曲の再生を開始する。このとき、コンテンツサーバS1は再生命令管理テーブルを更新し、次の表4に示すようにコントローラA1のコントローラインデックスをコントローラA2のコントローラインデックスに書き換える。次に図88に示すように、コントローラA3がコンテンツサーバS1経由で別のコンテンツサーバS2に蓄積されている曲の再生をオーディオクライアントC1に命令する場合を説明する。コントローラA3は、コンテンツサーバS2にオーディオクライアントC1が接続されているか否かを判断するS30342。この例ではオーディオクライアントC1はコンテンツサーバS2に接続されていないので、コントローラA3は予め定められたサーバ切換処理を実行するS30343。具体的には図89を参照して、コントローラA3はコンテンツサーバS1経由でオーディオクライアントC1にコンテンツサーバS1からコンテンツサーバS2への切換を命令するS303431。コンテンツサーバS1はこの切換命令をオーディオクライアントC1に転送するS201401。オーディオクライアントC1は現在接続中のコンテンツサーバS1を切断しS102401、切換命令に応じて新しいコンテンツサーバS2に接続を要求するS102402。コンテンツサーバS2はこの要求に応じてオーディオクライアントC1との接続を確立するS201402。コントローラA3はコンテンツサーバS2との接続を確認するS30344。続いて、コントローラA3はコンテンツサーバS2経由で曲の再生をオーディオクライアントC1に命令するS30314。コンテンツサーバS2はこの再生命令に応じて、次の表5に示すように、再生命令管理テーブルにおけるオーディオクライアントC1のクライアントインデックスに対応づけて、コントローラA3のコントローラインデックスを記録するS201441。コンテンツサーバS2は、コントローラA3からの再生命令をオーディオクライアントC1に転送するS201412。オーディオクライアントC1はコントローラA3からの再生命令に応じて曲の再生を開始しS10211、その再生を終えると、完了ステータスをコンテンツサーバS2に送信するS10212。コンテンツサーバS2はオーディオクライアントC1から完了ステータスを受信すると、再生命令管理テーブルを参照してオーディオクライアントC1に最後に再生を命令したコントローラA3を特定し、そのコントローラA3に完了ステータスを送信するとともに、他のコントローラA1及びA2に停止ステータスを送信するS1413。完了ステータスを受信したコントローラA3はオーディオクライアントC1に連続再生処理を実行するS30316。他方、停止ステータスを受信したコントローラA1及びA2は何ら能動的なアクションを起こさず、単にオーディオクライアントC1の状態を監視する。以上のように本実施の形態によれば、コンテンツサーバがオーディオクライアントに最後に再生を命令したコントローラを管理し、オーディオクライアントからの完了ステータスをそのコントローラにのみ転送しているため、そのコントローラのみが連続再生をオーディオクライアントに命令する。したがって、連続再生命令が競合することはなく、正常に連続再生処理を実行することができる。1.2.4.AVレシーバの制御図90に示すように、LAN12にはAVRクライアントAC1及びAC2が接続される。AVレシーバAVR1は、EIA-232によりAVRクライアントAC1に接続される。AVレシーバAVR2は、USBによりAVRクライアントAC1に接続される。AVレシーバAVR3は、メーカ特有のシリアルインターフェースによりAVRクライアントAC2に接続される。AVRクライアントAC1及びAC2の各々は、コンテンツサーバとの接続が完了したとき、EIA-232、USBなどのインタフェイスに関する情報をコンテンツサーバSiに通知してもよい。USBの場合、AVRクライアントAC1は、AVレシーバAVR2が接続されたとき、AVレシーバAVR2のベンダIDやプロダクトIDなどの機種情報を取得することができるので、それをコンテンツサーバSiに通知する。EIA-232の場合、AVRクライアントAC1がAVレシーバAVR1の機種情報を取得するのは通常は困難であるから、接続されるAVレシーバAVR1のベンダID及びプロダクトIDをAVRクライアントAC1に予め登録しておき、AVRクライアントAC1がそれをコンテンツサーバSiに通知するようにする。接続される可能性があるAVレシーバが複数ある場合は、AVRクライアントとの通信プロトコルを定めておき、AVRクライアントがAVレシーバの機種情報を取得するようにすればよい。たとえば、AVRクライアントは一定の通信条件ビットレート、ビット長、パリティなどで一定時間たとえば1秒ごとに機種情報を問い合わせるパケットを送信し、AVレシーバはそれに応答して機種情報を含むパケットを返信するようにすればよい。これにより、AVRクライアントは接続されているAVレシーバを特定することができる。USBの場合も含めてこのような場合、AVRクライアントはコンテンツサーバとの接続が確立した後にAVレシーバの機種情報を取得する可能性もあるので、AVレシーバの機種情報を取得した時点でその機種情報の変更をコンテンツサーバSiに通知する。その結果、コンテンツサーバSiは、AVRクライアントAC1,AC2に接続された又は接続される予定の全AVレシーバAVR1~AVR3の機種情報を取得することができる。機種情報はコンテンツサーバSiからコントローラAkにも通知されるため、コントローラAkも機種情報を取得することになる。AVレシーバAVRは、図91に示すように、ボリューム、入力切換スイッチ、音場制御用DSPなど、さまざまな被制御素子を有している。コントローラAkはこのような被制御素子を指定して制御コマンドを発行する。そのため、コントローラは、AVレシーバAVRがどのような被制御素子を有しているかという機種情報を持っている。なお、機種情報はコンテンツサーバSiが持っているから、コントローラAkがAVレシーバAVRのベンダID及びプロダクトIDをキーとしてコンテンツサーバSiに機種情報を要求してもよい。制御コマンドは、コントローラAkから出力され、コンテンツサーバSi及びAVRクライアントACを経てAVレシーバAVRに伝えられる。ステータスは逆に、AVレシーバAVRから出力され、AVRクライアントAC及びコンテンツサーバSiを経てコントローラAkに伝えられる。AVRクライアントACは、制御コマンドがAVレシーバAVR用であることを確認すると、AVレシーバAVRにその制御コマンドを出力する。制御コマンドがボリュームの値を制御するものであれば、コントローラAkが発行した制御コマンドは、コンテンツサーバSi及びAVRクライアントACを経てAVレシーバACRに送られ、これによりボリュームが制御される。図92を参照して、コントローラAkは制御コマンドをコンテンツサーバSiに送信しS35、コンテンツサーバSiはこれを指定されたAVRクライアントACに送信しS28、さらにAVRクライアントはこれをAVレシーバAVRに送信するS101。AVRクライアントACはAVレシーバAVRからそのステータスを受信してコンテンツサーバSiに送信しS102、コンテンツサーバはSVこれをコントローラAkに送信しS29、コントローラAkはこれに応じてAVレシーバAVRのステータスを更新するS36。図93に示すように、コンテンツサーバSi、AVRクライアントAC1~AC3、及びAVレシーバAVR11,AVR12,AVR21,AVR31,AVR32は、コンテンツサーバSiを根とした木のような形状をした経路で制御コマンドを伝達する。図94を参照して、コントローラAkは、制御対象たるAVレシーバAVR及び制御内容を決定しS3501、その制御内容に基づいてコマンド本体を生成するS3502。続いて、コントローラAkは、図95Aに示すように、コマンド本体に宛先情報を付加した制御コマンドをコンテンツサーバSiに送信するS3503。ここでの宛先情報は、制御対象たるAVレシーバAVRを指定するAVレシーバ指定部と、そのAVレシーバAVRに接続されたAVRクライアントACを指定するAVRクライアント指定部とを含む。コンテンツサーバSiはこの制御コマンドを受信し、図95Bに示すように、受信した制御コマンドからAVRクライアント指定部を取り出すS2801。コンテンツサーバSiは、このAVRクライアント指定部に基づいて指定されたAVRクライアントACを判断する。続いて、コンテンツサーバSiは、AVRクライアント指定部を取り除いた制御コマンドを指定されたAVRクライアントACに送信するS2802。AVRクライアントACはこの制御コマンドを受信し、図95Cに示すように、受信した制御コマンドからAVレシーバ指定部を取り出すS1011。AVRクライアントACは、このAVレシーバ指定部に基づいて指定されたAVレシーバを判断する。続いて、AVRクライアントACは、コマンド本体のみからなる制御コマンドを指定されたAVレシーバに送信するS2802。このように不要な指定部を順次取り除いて制御コマンドを転送すれば、ネットワークトラフィックを軽減することができる。ただし、指定部を取り除くことなく、制御コマンドをそのまま転送するようにしてもよい。各段階で、コマンド本体の文字列は全く同じである必要はなく、その意味が同じであればよい。すなわち、最終的にAVRクライアントACからAVレシーバAVRに送信される制御コマンドがAVレシーバAVRに理解可能な形式であればよい。このようにして制御コマンドを受信したAVレシーバAVRは、制御コマンドに従って被制御素子を制御する。その結果、被制御素子のステータスが変化すれば、AVレシーバAVRはそのステータスをAVRクライアントACに送信する。このステータスは、図96Aに示すように、ステータス本体のみからなる。AVRクライアントACは、AVレシーバAVRのステータスを受信して記憶するとともにS1021、図96Bに示すように、受信したステータスに発信元情報を追加し、それをコンテンツサーバSiに送信するS1022。ここでの発信元情報は、ステータスを発信したAVレシーバAVRを指定するAVレシーバ指定部を含む。コンテンツサーバSiはAVRクライアントACからのステータスを受信し、図96Cに示すように、受信したステータスにAVRクライアント指定部をさらに追加し、それをコントローラAkに送信するS2901。コントローラAkはコンテンツサーバSiからのステータスを受信し、受信したステータスからAVRクライアント指定部及びAVレシーバ指定部を取り出し、AVレシーバAVRのステータスを更新するS3601。なお、ステータスは、被制御素子のステータスだけでなく、コントローラAkでは制御不可能な要素のステータスたとえば音声信号のレベル情報なども存在し得る。このようなステータスもAVRクライアントAC及びコンテンツサーバSiを経由してコントローラAkに伝えられる。また、ステータスは、AVレシーバAVRの被制御素子が制御コマンドにより制御されたときだけでなく、そのステータスが変化したときにも送信される。すなわち、AVRクライアントACとAVレシーバAVRとの接続が確認されたときにも、AVRクライアントACはAVレシーバAVRのステータスを取得し、これをコンテンツサーバSiに送信する。このようにして最終的にステータスを受信したコントローラAkは、各AVレシーバAVRのステータスを把握することができる。これにより、コントローラは制御の確認及びステータスの表示を行う。なお、表示目的のステータスであって頻繁に変化する可能性のあるステータスは、AVレシーバAVR又はAVRクライアントACがステータスの送出頻度を適宜低くしてもよい。頻繁に変化するステータスをそのまま表示しても認識しにくいし、送出頻度が高いとネットワークに無用なトラフィックが発生し、コンテンツサーバの負荷も増大するからである。複雑な構成を有する被制御素子は、複数の被制御部を持つ場合がある。たとえば図91中の音場制御用DSPは多くの係数データの設定を必要とするが、その設定はDSPを制御するマイクロコントローラにより行われる。この設定を変更する場合、スタンドアロンのシステムでは、AVレシーバ本体又はそれに接続された表示装置でステータス状態を表示しながら、ユーザのキー操作により行うことになる。この動作を行うのはマイクロコントローラのファームウェアであり、複雑な設定が可能で、かつ使い易い操作を実現しようとすると、プログラム容量の増大や高性能な表示装置が必要になったりと、製品単価や開発費用に影響が出る可能性がある。このシステムでは、係数データの設定パターンをいくつもコンテンツサーバSiに持たせ、コントローラAkに表示された階層メニューからそのうち1つを選択し、AVRクライアントAC経由で係数データを設定することも可能である。また、同時に複数のAVレシーバAVRをコントローラAkの支配下に置けることから、AVレシーバAVRの時刻合わせなどの設定を同時に行うことができる。さらに、これらAVレシーバAVRのステータスをモニタすることにより、リレー録画などの連携動作も可能になる。次に、AVRクライアントACに接続されているAVレシーバAVRのボリュームを上げる場合を説明する。図97を参照して、コントローラAkはクライアントの接続を確認しS3011、接続があれば、そのクライアントがAVRクライアントACか否かを判別しS3014、AVRクライアントACであれば、ボリュームアップを示す制御コマンドをコンテンツサーバSiに送信するS35。コンテンツサーバSiはこれをAVRクライアントACに送信しS28、さらにAVRクライアントACはこれをAVレシーバAVRに送信するS101。AVRクライアントACはボリュームアップしたことを示すステータスをAVレシーバAVRから受信し、これをコンテンツサーバSiに送信するS102。コンテンツサーバSiはこれをコントローラAkに送信しS29、コントローラAkはこれに応じてAVレシーバAVRのステータスを更新し、図34に示したモニタを再開するS36。次に、AVRクライアントACがAVレシーバAVRのステータスをコンテンツサーバに転送する動作を図98を参照して説明する。AVRクライアントACはAVレシーバAVRからパケットデータを受信するとS1021、それがボリューム情報か否かを判別するS1022。AVレシーバAVRからデータがEIA-232の場合は、パケット受信はシリアル受信割り込みで行われ、データはキューに入れられる。キューは定時的に読み出され、以降の処理が行われる。続いて、受信したデータがボリューム情報であれば、AVRクライアントACはそのボリューム値を記憶するS1023。上記ボリューム情報か否かの判別S1022及びボリューム情報の記憶S1023は、データがキューに入れられる前に行われる。一方、受信したデータがボリューム情報でなければ、AVRクライアントACは、AVレシーバAVRからのステータスであることを示すAVレシーバ指定部を、受信したパケットデータに追加してコンテンツサーバSiに送信するS1024。ボリューム値を記憶した後、ボリューム情報の受信が初めてか否かを判別するS1025。初めての場合はステップS1028に進むが、初めてでない場合はAVRクライアントACはボリューム値をコンテンツサーバに送信してから200ミリ秒以上経過しているか否かを判別するS1026。200ミリ秒以上経過している場合、AVRクライアントACは前回送信したボリューム値を記憶したボリューム値と比較しS1027、異なっている場合はAVレシーバAVRからのステータスであることを示すAVレシーバ指定部をボリューム情報に追加してコンテンツサーバSiに送信するS1028。ボリューム値のステータスは他のステータスと比較して短い間隔でやって来る場合があるので、コンテンツサーバSiやコントローラAkの負担になったり、ネットワークに無用なトラフィックの増大をもたらす可能性がある。ボリューム情報はコントローラAkでの表示に用いるだけなので、表示に支障のない間隔で送れば問題ない。そのため、ボリューム情報を受信すると、その値だけを記憶し、変化があったときだけ適当な間隔ここでは200ミリ秒をおいてコンテンツサーバSiに送信するようにしている。次に、AVRクライアントACがコンテンツサーバSiからのコマンドをAVレシーバAVRに転送する動作を図99を参照して説明する。AVRクライアントACはAVレシーバAVR用の制御パケットを受信するとS1031、そのパケットからAVレシーバAVR用の制御コマンドを取り出すS1032。AVRクライアントACは、その制御コマンドがボリューム値問い合わせコマンドか否かを判別するS1033。ボリューム値問い合わせコマンドの場合、AVRクライアントACは記憶しておいたボリューム値未受信の場合は適当な初期値からボリューム情報を生成しS1034、AVレシーバAVRからのステータスであることを示すAVレシーバ指定部をボリューム情報に追加してコンテンツサーバSiに送信するS1035。一方、ボリューム値問い合わせコマンドでない場合、そのAVレシーバAVR用の制御コマンドをAVレシーバAVRに送信するS1036。AVRクライアントACとAVレシーバAVRとのインタフェイスがEIA-232の場合には、AVRクライアントACからAVレシーバAVRへの送出はバイト単位で割り込みによって行われる。コンテンツサーバSiからの制御コマンドは一旦キューに格納される。キューは定時的な割り込み又はシリアル送信のバッファエンプティの割り込みで読み出され、バイト単位で送出される。上記の形態では、コンテンツサーバSiへのボリューム情報の送出は、初回を除いて変化があったときしか行われない。そのため、AVレシーバAVRがコンテンツサーバSiからのボリューム値問い合わせコマンドに応答してボリューム値を返したとしても、そのボリューム値に変化がなければAVRクライアントACはそのボリューム値をコンテンツサーバSiに返さない。この対策として、コンテンツサーバSiからのボリューム値問い合わせコマンドに対しては、AVRクライアントACはAVレシーバAVRを介さずに応答するようにしている。この形態は、AVレシーバAVRに電源が投入されたときは必ずAVレシーバAVRはボリュームの初期値をステータスとしてAVRクライアントACに送信することが前提となっている。しかし、電源投入のタイミングによっては、AVRクライアントACがこの初期値を受信できない可能性もある。そこで、図100に示すように、AVRクライアントACは初回に限りAVレシーバAVR経由で応答を行うのが好ましい。すなわち、コンテンツサーバSiからの制御コマンドがボリューム値問い合わせコマンドの場合、AVRクライアントACはボリューム値を未だ受信していないか否かを判別するS1034。未だ受信していない場合はステップS1036に進み、既に受信している場合はステップS1034に進む。なお、複数種類のAVレシーバが存在する場合において、コントローラAkがこれらのAVレシーバを制御するときは、コントローラAkはAVレシーバの種類に応じて専用の制御コマンドを発行してもよいが、AVレシーバの種類に関係なく汎用の制御コマンドを発行し、コンテンツサーバがこの汎用の制御コマンドを専用の制御コマンドに変換するようにしてもよい。1.2.5.ファームウェアアップデートコンテンツサーバは、後述するように、クライアントにインストールされているファームウェアをアップデートすることができる。ここでは、クライアントがコンテンツサーバにアップデートを要求する場合と、コンテンツサーバがクライアントに問い合わせをした上でアップデートする場合と、コンテンツサーバが強制的にアップデートする場合とがある。まず、クライアントがコンテンツサーバにアップデートを要求する場合の概要を説明する。図101を参照して、クライアントはファームウェア情報をコンテンツサーバに要求しS103、コンテンツサーバはこれに応じてファームウェア情報をクライアントに返信しS201、クライアントはこれを受信するS103。続いて、クライアントはファームウェアを指定しS104、コンテンツサーバはこれに応じて指定されたファームウェアの転送を準備するS202。続いて、クライアントはファームウェアをコンテンツサーバに要求しS105、コンテンツサーバはこれに応じてファームウェアをクライアントに転送しS203、クライアントはこれを受信するS105。続いて、クライアントはファームウェアをアップデートしS106、アップデートを終えると終了ステータスをコンテンツサーバに送信しS107、コンテンツサーバはこれを受信するS204。次に、ファームウェアアップデートの詳細を図102を参照して説明する。コンテンツサーバからアップデートを開始する場合は、ステップS2012から処理を開始する。クライアントからアップデートを開始する場合は、ステップS1033から処理を開始する。コンテンツサーバは、まず、ファームウェア情報ファイルを読み込み、図15に示したファームウェア情報データベースを作成しておくS2011。たとえば、コンテンツサーバがクライアントごとにアップデートに必要なファイルを読み込み、アップデート情報ファイルを作成する。したがって、この情報ファイルに基づき、クライアントのファームウェアの新旧を判断できる。クライアントは、起動時にプロダクトID及びファームウェアIDをコンテンツサーバに送信するS1031。コンテンツサーバからアップデートを開始する場合、たとえばコンテンツサーバがクライアントのプロダクトID及びファームウェアIDに基づいてそのファームウェアが古いと判断した場合や、コンテンツサーバがインターネット上のサイトから新しいファームウェアを取得した場合などには、コンテンツサーバは、クライアントにファームウェアのアップデートを要求するためのファームウェアアップデート要求コマンドを発行し、必要に応じて、アップデートを推奨する新しいファームウェアの情報をクライアントに提示するS2012。ユーザが推奨されたファームウェアのアップデートを望まない場合、クライアントはコンテンツサーバからのアップデート要求を拒否し、この処理は直ちに終了するS1032。また、ユーザが推奨されたファームウェアのアップデートを保留する場合も、この処理は直ちに終了するS1032。ただし、この場合、クライアントはコンテンツサーバに所定時間経過後に再びアップデート要求をするように命令する。また、ユーザが推奨されたファームウェアのアップデートを受け入れる場合、クライアントはそのまま処理を継続するS1032。この場合において、コンテンツサーバがクライアントに具体的なファームウェアを提示しているときは、クライアントはステップS1035に進み、直ちにファームウェアのアップデートを開始する。また、コンテンツサーバがクライアントに具体的なファームウェアを提示することなく、単にアップデートを要求しているときは、クライアントはステップS1033に進み、ファームウェアリストを取得する。なお、ファームウェアアップデート要求コマンドは、コントローラがサーバリクエストとして発行してもよい。この場合は、コントローラは後述するS1033~S1034と同様にして、制御及び監視するクライアントに関するファームウェアリストをコンテンツサーバから取得し、ユーザが所望のファームウェアを選択する。コントローラにて選択されたファームウェアがアップデートを推奨するファームウェア情報としてクライアントに提示される。アップデート要求を受け入れる場合、又はクライアントからアップデートを開始する場合、クライアントはファームウェアリストをコンテンツサーバに要求するS1033。ファームウェアリストは、特定クライアントに適用可能なファームウェアを列挙したものである。コンテンツサーバは、ファームウェアリストを常時持っているのではなく、クライアントからの要求に応じてその都度作成する。ファームウェアリストの作成方法は、上述した曲リストの作成方法と基本的に同じである。ただし、ファームウェアリストを作成するときには、コンテンツサーバは、図15に示したファームウェア情報データベースを用いる。このデータベースには、ファームウェア情報がファームウェア数分だけ格納されている。以下、ファームウェアリストの作成方法を詳述する。図103を参照して、まずコンテンツサーバは、ファームウェア情報データベースに格納されているファームウェア情報の番号を示すインデックスを0に初期化するS20131。続いて、コンテンツサーバは、インデックスが示すファームウェア情報のプロダクトIDがクライアントのプロダクトIDと一致するか否かを判別するS20132。一致する場合、コンテンツサーバはそのファームウェア情報をファームウェアリストに追加しS20133、その後、インデックスをインクリメントするS20134。一方、一致しない場合、コンテンツサーバは、ステップS20133をスキップし、直ちにインデックスをインクリメントするS20134。続いて、コンテンツサーバは、インデックスが示すファームウェア情報の番号が全ファームウェア情報の数nよりも小さいか否かを判別しS20135、小さい場合はステップS20132に戻り、一方、小さくない場合はファームウェアリストの作成を完了する。上記の処理により、コンテンツサーバは、ファームウェア情報データベースの中からプロダクトIDが一致するファームウェア情報をピックアップし、ファームウェアリストを作成する。このように、ファームウェアリストは予めデータベース化されているのではなく、クライアントからの要求のたびに一時的に作成されるので、ファームウェアリストを常に格納しておくためのメモリ領域は不要である。続いて、コンテンツサーバは、この作成したファームウェアリストを要求元クライアントに返信するS2013。このファームウェアリストも上記曲リストと同様に、コンテンツサーバからクライアントに分割されて送られる。具体的には、図104を参照して、クライアントは、自身のプロダクトIDと、取得しようとする最初のファームウェア情報を示す取得開始インデックスと、取得しようとするファームウェア情報の数を示す取得個数とを含むファームウェアリスト要求コマンドをコンテンツサーバに送信するS1033。コンテンツサーバは、このファームウェアリスト要求コマンドに応答して、クライアントのプロダクトIDと同じプロダクトIDを有するファームウェア情報を抽出し、取得開始インデックスが示すファームウェア情報から取得個数が示す数だけファームウェア情報をクライアントに返信するS2031。このとき、コンテンツサーバは、送信するファームウェア情報の数を示す有効個数と、コンテンツサーバがクライアントに返信したファームウェアリストよりも後に残っているファームウェアの数を示す残り個数とを併せて送信する。クライアントは、このようなファームウェアリストの一部を受信してメモリに格納するS10331。上記処理は、全ファームウェアリストがコンテンツサーバからクライアントに送られるまで繰り返される。続いて、クライアントは、返信されたファームウェアリストの中にユーザがダウンロードしたいファームウェア新しいバージョンなどがあれば処理を継続し、なければ処理を中止するS1034。コンテンツサーバは、新旧を問わず、全てのバージョンのファームウェア情報を送信するので、不具合などにより、クライアントは、古いファームウェアに変更することもできる。アップデートを行う場合、クライアントはアップデートセクションに移行したことを示すステータスをコンテンツサーバに通知するS1035。コンテンツサーバは、このステータスに応答してエラーの有無を示すエラーコードを返信するS2014。クライアントは、ダウンロードしようとするファームウェアのファイルを指定するS1036。具体的には、取得したファームウェア情報のリストに格納されているフルパス名を指定する。コンテンツサーバは、指定されたファイルを読み出し、バッファに格納しておくS2015。続いて、クライアントは、取得開始アドレス及びデータサイズバイト数を指定し、ファームウェアのデータを取得するS1037。コンテンツサーバは、指定された取得開始アドレスから指定されたバイト数分だけデータをバッファから読み出し、クライアントに送信するS2016。クライアントは、ファームウェアのデータを最後まで取得したか否かを判別しS1038、取得していない場合はステップS1037に戻ってデータの取得を繰り返す。取得し終えた場合、クライアントはファームウェアを書き換えS1039、アップデートを終了するS1040。コンテンツサーバは、開いていたファームウェアのファイルを閉じ、バッファを解放するS2017。さらに、クライアントがファームウェアの書き換えを完了したときは、不明ステータスをコンテンツサーバに送信する。クライアントは、コンテンツサーバとの接続を中断して、リセットすなわち、更新されたファームウェアを起動し、クライアント情報をコンテンツサーバに通知する。また、クライアントがファームウェアデータを取得失敗したときは、失敗ステータスを送信してもよい。失敗ステータスは、ファームウェアデータ再送信などに用いることができる。なお、コンテンツサーバからアップデート要求を行う場合において、次の様に処理することもできる。すなわち、図102において、コンテンツサーバはアップデート要求の際に、必ずファームウェアの情報をクライアントに提示するS2012。コンテンツサーバが推奨するファームウェアをアップデートする場合にはS1035に進み、コンテンツサーバが推奨するファームウェアをアップデートするのではなく、ユーザがファームウェアリストから所望のファームウェアを選択する場合にはS1033に進むようにすることもできる。以上のように、ファームウェアのデータがコンテンツサーバからLAN経由でオーディオクライアントに送信されるので、クライアントのファームウェアを短時間でアップデートすることができ、しかも複数のクライアントのファームウェアを同時にアップデートすることもできる。また、プロダクトIDを用いているため、クライアントに適したファームウェアを自動的に選択してアップデートすることがきる。また、ファームウェアIDを用いているため、最新バージョンのファームウェアを自動的に選択してアップデートすることがきる。2.他の実施の形態2.1.コンセント内蔵型オーディオクライアントオーディオクライアントは、図105及び図106に示すように、コンセントボックス50に内蔵されてもよい。コンセントボックス50は一般に、壁52に取り付けられる前面パネル54と、前面パネル54の裏面に取り付けられた筐体56とを備える。この発明の実施の形態では、筐体56の中に、図3に示したオーディオクライアント用の回路が設けられる。LANケーブルは、このオーディオクライアント用の回路に接続される。また、前面パネル54には、電源コンセント58、電源スイッチ60、モジュラージャック図示せず、テレビアンテナ用端子図示せずなどに加えて、オーディオクライアントからのオーディオ信号を出力するためのオーディオ出力端子62が設けられる。これらオーディオ出力端子62はそれぞれ左右のスピーカ装置に接続される。オーディオクライアントは、通常、曲リストを表示するためのディスプレイと、その表示された曲リストから所望の曲を選択するためのスイッチ類とを備えている。ディスプレイやスイッチ類はオーディオクライアントをモニタしかつ制御するために必要であるが、オーディオクライアントと同じLAN12に接続されたコントローラを使用することにより、オーディオクライアントからディスプレイやスイッチ類を除去することができる。また、コントローラを使用する代わりに、オーディオクライアントと同じLAN12に無線で接続された携帯型リモートコントローラを使用してもよい。このようにオーディオクライアントを簡素化することにより、一般家庭のコンセントボックス50に内蔵することができる。簡素化されたコンセント内蔵型オーディオクライアントは、ネットワークから音楽や映像を抽出して再生する機能のみを有し、表示機能や制御機能を有していない。インターネットの普及、特にブロードバンド高速大容量のインフラが整備されるに従い、一家に複数台のパソコンからインターネットに接続する要求が増えると予想されている。宅内で複数台のパソコンをインターネットに接続する最も一般的な方法は、宅内にLANを構築することであり、こうした宅内LANを備えた世帯が増加することは時間の問題となっている。このLANを利用すれば、上述の音楽や映像を宅内の各所に配信することがケーブル1本で可能になる。また、1本のケーブルには音楽/映像信号の他にコントロール信号も併せて伝送することができるから、本システムの設置にはオーディオ/ビデオに関する専門的な知識が不要である。さらに、コスト面でも極めて有利であるため、業務用のみならず、家庭用としても普及しうる。一般家庭において、新築時又はリフォーム時にインターネット接続の利便性を考慮して宅内LANを敷設するケースが増大しているが、このときコンセントボックス50にLANコネクタを設けるのが極めて一般的である。したがって、LANの敷設工事と同時に複数のオーディオクライアントを容易に設置することができる。すなわち、スピーカパワードを含むを接続するだけでオーディオクライアントを構築することができ、また、テレビなどの映像モニタを接続するだけでビデオクライアントを構築することができる。そのため、インテリア上も見栄えのよいオーディオクライアントをセットすることができる。さらに、商品開発の観点からも商品自体の華美なデザイン設計が不要となり、機能を重視した極めてシンプルな設計手法により商品開発コストの低減につながる。また、その構造がシンプル故にリサイクルのし易さの点でも有益である。宅内LANによる配信では、従来のオーディオ/ビデオ機器と異なり、CDやテープといったコンテンツのメディアを必要としない。すなわち、コンテンツは一度コンテンツサーバに格納してしまえば、そのメディアの管理は不要となる。こうした宅内ネットワークによるサーバクライアントの構成によれば、オーディオクライアントにはメディアを挿入する機構や回転駆動装置など、機械系の装置を全く必要としない。したがって、装置の小型化を達成し、さらに高い信頼性とともに長寿命な商品を可能にする。2.2.インターネット上の音楽データを取得上記実施の形態では、オーディオクライアントは電源投入時にブロードキャストによりコンテンツサーバを探索している。しかし、LAN12上の全コンテンツサーバの電源が落ちていた場合、コンテンツサーバからの応答がないため、オーディオクライアントは永久にコンテンツサーバを探索し続けることになる。これを防止するためには、オーディオクライアントはタイムアウトエラーなどの処理を行えばよいが、タイムアウトエラーの場合、オーディオクライアントは音楽を再生するなどの動作を全く行うことができない。これらの問題を解決するためには、オーディオクライアントがブロードキャストを所定回数繰り返してもコンテンツサーバを発見することができない場合は、インターネット上のWWWサーバにアクセスし、このサーバと接続するようにすればよい。この場合、LAN12は、図107に示すように、ゲートウェイ50を通じてインターネット52に接続される。インターネット52上のWWWサーバ54には、音楽配信サイト56に置かれている曲のリストが予め登録されている。このリストには、曲名やアーティスト名など、曲情報の他、音楽データが置かれているURLなどが記録されている。図108に示すように、サーバリストが空の場合、オーディオクライアントは、ステップS1102に戻ってブロードキャストをリトライする前に、そのリトライ回数が所定の回数、たとえば3回に達したか否かを判別するS1109。リトライ回数が3回に達していない場合、オーディオクライアントはリトライ回数をインクリメントしS1110、その後、ステップS1102に戻ってブロードキャストをリトライする。一方、リトライ回数が3回に達している場合、オーディオクライアントはインターネット52上のWWWサーバ54にHTTPで接続するS1111。オーディオクライアントが接続に成功した場合は探索を完了するがS1112、接続に成功せず、タイムアウトになった場合はエラーとなるS1113。オーディオクライアントはWWWサーバ52にアクセスすると、そこから曲情報やURLを受信して解析し、そのURLの音楽配信サイト56から音楽データを受信する。以上のように、コンテンツサーバがLAN12上に存在しない場合又は存在しても稼動していない場合は、オーディオクライアントはインターネット52上のサイト56に自動的にアクセスして音楽データを取得するので、LAN12上のコンテンツサーバを永久に探索し続けることはない。上記の例では、リトライ回数が所定回数に達したとき、オーディオクライアントはインターネット52上のWWWサーバ54に接続するようにしているが、これに代えて、オーディオクライアントがマジックワードをブロードキャストして所定時間が経過したにもかかわらず、LAN12上のいずれのコンテンツサーバからも応答がない場合にインターネット52上のWWWサーバ54に接続するようにしてもよい。2.3.取得データ長変更機能付き再生上記実施の形態では、オーディオクライアントCjがコンテンツサーバSiに曲データの転送を要求するとき、常に一定量の曲データを要求している。したがって、コンテンツサーバSiに曲データの転送を要求するオーディオクライアントCjの数が少ない場合は問題ないが、この数が多くなると、コンテンツサーバSiにかかる負荷が大きくなり、オーディオクライアントCjがコンテンツサーバSiに曲データの転送を要求してから実際に曲データが転送されるまでの時間が長くなるという問題が生じる。そこで、このコンテンツサーバSiにかかる負荷が均等になるように、オーディオクライアントCjが1回に要求する曲データの量をその都度変更するようにしてもよい。以下、オーディオクライアントCjがコンテンツサーバSiに曲データの転送を要求してから実際に曲データが転送されるまでの時間に応じて、オーディオクライアントCjが1回に要求する曲データの量を変更する例を説明する。図109を参照して、オーディオクライアントCjは、コンテンツサーバSiに曲データの転送を要求する曲データ転送コマンドを送信するS1601と同時に、タイマを動作させ、コンテンツサーバSiから曲データが転送されるまでの応答時間のカウントを開始するS16011。なお、最初にオーディオクライアントCjが曲データ転送コマンドを発行するときには、1回に要求すべき適切な曲データの量は不明であるから、取得データ長は予め定められたものになる。続いて、オーディオクライアントCjは曲データを受信し始めるとS16012、タイマを停止し、コンテンツサーバSiによる曲データの応答時間を取得するS16013。オーディオクライアントCjは、図110に示した対比テーブルを参照し、取得した応答時間に対応する取得データ長を決定するS16021。この対比テーブルには、所定の応答時間と所定の取得データ長とが対応つけられている。ここでは、応答時間が長いほどコンテンツサーバSiにかかる負荷は大きいから、応答時間が長いほど取得データ長が短くなるように設定されている。たとえばオーディオクライアントCjが20msecの応答時間を取得した場合は、取得データ長を8kバイトと決定する。オーディオクライアントCjは再び曲データの転送をコンテンツサーバSiに要求するが、ここでは上記で決定した取得データ長を送信するS1605。以降、上記と同様の動作を繰り返すS16051~S16061。以上のようにこの実施の形態によれば、オーディオクライアントCjがコンテンツサーバSiに要求する曲データの取得データ長を応答時間が長くなるにつれて短くしているため、コンテンツサーバSiに曲データの転送を要求するオーディオクライアントCjの数が増えても、コンテンツサーバSiがオーディオクライアントCjに1回に転送する曲データの量は少なくなる。その結果、各オーディオクライアントCjに対するコンテンツサーバSiの負荷は平均化され、コンテンツサーバSiは複数のオーディオクライアントCjに円滑に曲データを転送することができる。上記の例では、コンテンツサーバの応答時間に応じて取得データ長を決定しているが、これに代えて、取得しようとする曲のデータフォーマットに応じて取得データ長を決定するようにしてもよい。すなわち、図35において、曲データ転送要求S1601前に、図32に示す検索データに基づいて、曲の音声フォーマットを取得する。そして、曲の音声フォーマットに基づいて、取得データ長を設定する。一般にMP3形式のデータは圧縮されているためにサイズが小さいのに対し、WAV形式のデータはサイズが大きい。そこで、取得しようとする曲のデータフォーマットがMP3の場合には、1回にたとえば4Kバイトのデータを取得し、WAVの場合には、1回にたとえば16Kバイトのデータを取得するようにしてもよい。2.4.スキップ再生上記実施の形態では、オーディオクライアントCjは曲リストの順序にしたがってコンテンツサーバSiに曲データの転送を要求している。しかしながら、ユーザが現在再生中の曲をはじめから聴きなおしたい場合がある。また、ユーザが現在再生中の曲をスキップして、他の曲を聴きたい場合もある。そこで、オーディオクライアントCjがこのようなユーザの要求に対応して曲データ転送の要求をできるようにしてもよい。図111を参照して、オーディオクライアントCjが図112に示した曲リスト中の曲3の再生を行っている場合、オーディオクライアントCjは曲3の音楽データのうち指定範囲の音楽データの転送をコンテンツサーバSiに要求しS1607、コンテンツサーバSiはこの要求に応じて指定範囲の音楽データをオーディオクライアントCjに返信しS2604、オーディオクライアントCjはこれを受信し、メモリ32に格納するS1608。この動作の繰り返しにより曲3は再生される。曲3の再生中に、ユーザが曲3の再生を終了して、曲4を聴こうとした場合図112における1のケース、ユーザはオーディオクライアントCjに曲4へのスキップ要求を行う。オーディオクライアントCjはユーザからのスキップ要求を受けS1640、メモリ32に格納された曲リスト内容を確認し、曲4のファイル名を取得するS1641。ユーザからのスキップ要求がない場合は、ステップS1607に戻って曲3のデータ転送の要求を行う。以降のオーディオクライアントCjおよびコンテンツサーバSiの動作については図35での動作と同じであるため、その説明は繰り返さない。以上の動作により、オーディオクライアントCjは曲3の再生中に曲4へスキップ再生できる。なお、オーディオクライアントCjが曲3を再生中において、ユーザが曲3を初めから再び聴こうとする場合図112における2ケース、ユーザが曲5を聴こうとする場合図112における3ケース、ユーザが曲2を聴こうとする場合図112における4ケース等についても同様の動作により、オーディオクライアントCjはスキップ再生できる。以上のようにこの実施の形態によれば、オーディオクライアントCjはメモリ内に格納された曲リストを用いることで、現在再生中の曲から他の曲へスキップ再生できる。2.5.リピート再生また、ユーザが指定する第1アドレスと第2アドレスとの間で、データを繰り返して再生するA-B間リピート再生を行うことができる。まず、ユーザは1回目のA-B間リピート操作を行い、繰り返しの始まりを示す第1アドレスを指定する。すなわち、図113を参照して、オーディオクライアントは、曲データの転送要求および曲データの取得の際にS1601、ユーザからの操作があってS1642、ユーザからの操作がA-B間リピート要求であってS1643、1回目の要求であるのでS1644、ユーザが指定したアドレスを第1アドレスaddr1として記憶する。そして、前回の取得開始アドレスaddrに取得データ長sizeを加算して取得開始アドレスaddrを算出しS1646、S1601へと戻る。次に、ユーザは2回目のA-B間リピート操作を行い、繰り返しの終わりを示す第2アドレスを指定し、リピート動作を開始させる。すなわち、S1644において、ユーザからのA-B間リピート要求が2回目の要求である1回目の要求ではないので、ユーザが指定したアドレスを第2アドレスaddr2として記憶するS1647。そして、オーディオクライアントは、A-B間リピートモードに入るS1648。すなわち、取得開始アドレスを第1アドレスに変更しS1649、曲データ転送要求および曲データ取得を行うS1601。ここで、オーディオクライアントは、A-B間リピート状態であると判断しS1650、取得開始アドレス=前回の取得開始アドレス取得データ長が第2アドレスより大きくなるか否かを判別するS1651。取得開始アドレスが未だ第2アドレス以下であれば、曲データ転送要求を続けるS1646およびS1601。そして、S1651において、取得開始アドレスが第2アドレスより大きくなる場合には、取得開始アドレスを再び第1アドレスに変更しS1652、曲データ転送要求を行うS1601。従って、第1アドレスと第2アドレスとの間でリピート再生を行うことができる。また、ユーザはリピート解除操作を行うことにより、リピート状態を解除することができるS1643、S1653およびS1654。2.6.途中再生また、取得開始アドレスをユーザが指定する例えば、開始時間を入力することにより、指定アドレスからの曲の再生を行うことができる。すなわち、図114を参照して、例えば曲データの転送要求および曲データの取得の際にS1601、ユーザからの操作があってS1656、アドレスの指定である場合にはS1657、オーディオクライアントはユーザから指定のあったアドレスを取得するS1658。例えば、曲の総再生時間とユーザが入力した開始時間からアドレスを算出する。そして、取得開始アドレスをユーザから指定のあったアドレスに変更してS1659、曲データ転送要求および曲データ取得を行うS1601。従って、ユーザが指定するアドレスからの曲の再生行うことができる。さらに、ユーザがアドレスを指定することができるのは、オーディオクライアントが再生状態のときに限らず、例えば、停止状態や一時停止状態のときであってもよい。2.7.自動接続回復機能付きクライアントネットワークオーディオシステムでは、上述したように、オーディオクライアントがコンテンツサーバに接続され、コンテンツサーバから配信された音楽を再生しているが、配信中にコンテンツサーバの異常によりオーディオクライアントがコンテンツサーバから切り離された場合、オーディオクライアントはコンテンツサーバに再び接続されなければ音楽を再生することができない。入力装置を有する通常のオーディオクライアントの場合、その入力装置を操作することによりそのオーディオクライアントに図5に示したようにコンテンツサーバとの接続処理を再び実行させればよい。しかし、上述したコンセント内蔵型オーディオクライアントの場合、入力装置を備えていないため、一旦コンテンツサーバから切り離されるとそのまま放置されてしまう。したがって、オーディオクライアントは以下のような自動接続回復機能を備えているのが望ましい。図115を参照して、オーディオクライアントCjはコンテンツサーバSiと接続してから所定期間が経過したか否かを判断するS110。所定期間経過後、オーディオクライアントCjはコンテンツサーバSiとの接続が維持されているか否かを判断するS111,S112。具体的には、オーディオクライアントCjは接続確認コマンドをコンテンツサーバSiに送信するS111。コンテンツサーバSiからオーディオクライアントCjに接続確認コマンドに対する返答がある場合S112、接続は維持されていると判断される。一方、返答がない場合や送信エラーが起きる場合S112、接続は切断されていると判断される。返答方法としては、たとえばコンテンツサーバSiが送信された接続確認コマンドと同じコマンドを返信する方法がある。ステップS112で返答があった場合、オーディオクライアントCjは再びS110に戻って所定期間経過後に接続が維持されているか否かを判断するS110~S112。これにより、オーディオクライアントCjは所定期間ごとにコンテンツサーバSiとの接続状態をチェックする。接続が切断されている場合、オーディオクライアントCjは同じコンテンツサーバSiに対して再接続を試みるS12。再接続を試みた結果、コンテンツサーバSiとの接続に成功した場合S113、オーディオクライアントCjは切断直前のクライアントステータスをコンテンツサーバSiに送信するS13。クライアントステータスは例えば、再生、停止、ポーズ等の再生状態や、音量情報、リスト構築キーなどを含む。よって、オーディオクライアントCjはコンテンツサーバSiとの接続状態をもとどおりに回復できる。その結果、ユーザはオーディオクライアントCjがコンテンツサーバSiと接続し直したことを意識せずにオーディオクライアントCjを利用できる。一方、再接続を試みた結果、コンテンツサーバSiとの接続に失敗した場合S113、オーディオクライアントCjは同じコンテンツサーバSiとの接続回復を断念し、他のコンテンツサーバSiとの接続処理を実行するS11~S13。具体的には、オーディオクライアントCjはブロードキャストにより接続可能なコンテンツサーバSiを探索しS11、探索したコンテンツサーバSiに対して接続を行うS12。接続後、オーディオクライアントCjは切断直前のクライアントステータスをコンテンツサーバSiに送信するS13。オーディオクライアントCjは、図115に示した接続回復プログラムをインストールすることにより、上述した自動接続回復機能を備える。以上の動作により、オーディオクライアントCjから所定期間ごとに接続状態を確認し、切断されていればオーディオクライアントCj自身が再接続を実行する。そのため、コンテンツサーバSiの異常により接続が切断されても、オーディオクライアントCjがコンテンツサーバSiから切断されたまま放置されることはない。また、接続していたコンテンツサーバSiの異常によりそのコンテンツサーバSiと再接続ができない場合でも、オーディオクライアントCjは他のコンテンツサーバSiと接続する。その結果、ユーザは常にコントローラAkを用いてオーディオクライアントCjを制御することができる。また、オーディオクライアントCjは接続先のコンテンツサーバSiに切断直前のクライアントステータスを送信しているため、オーディオクライアントCjは他のコンテンツサーバSiに接続されても切断直前と同じ状態にできる。その結果、ユーザはオーディオクライアントCjがコンテンツサーバSiと切断されたことを意識することなく、オーディオクライアントCjを利用できる。本実施の形態では、オーディオクライアントCjが自動接続回復機能を備えているが、コントローラAkが自動接続回復機能を備えていてもよい。また、音楽再生機能及び制御機能を併有する能動的なクライアントよりはむしろ、音楽再生機能だけを有する受動的なクライアントが自動接続回復機能を備えているのが好ましい。制御機能を有さない受動的なオーディオクライアントCjは自らコンテンツサーバSiにコマンドを送信することがないため、一旦コンテンツサーバSiとの接続が切断されるとそのまま放置されてしまい、ユーザがそのオーディオクライアントCjを再起動しない限りコンテンツサーバSiとの接続を回復できないからである。上述した全ての実施の形態における各ステップは、コンピュータに実行させるための動作プログラムを形成する。よって、この動作プログラムを、コンテンツサーバSi、オーディオクライアント、コントローラ、及びAVRクライアントにインストールすることにより、ネットワーク型オーディオシステムを構築することができる。また、この動作プログラムは、そのままインターネットなどの電気通信回線を通じて配信されてもよいが、CD-ROM、DVD-ROMなどのコンピュータ読み取り可能な記憶媒体に格納されて配布されてもよい。以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。"