WO2003102919A1 - Network type content reproduction system - Google Patents

Description

ネットワーク型コンテンツ再生システム 技術分野

本発明は、 ネットワーク型コンテンツ再生システムに関し、 さらに詳しくは、 サーバとサーバに接続されたクライアントとサーバに接続されたコントローラと を備えたネットワーク型コンテンツ再生システムに関する。 背景技術

従来の典型的なオーディオシステムは、 媒体から音楽データを読み出し、 その 音楽データに基づいて音楽を再生するものである。 このようなオーディオシステ ムは基本的に各部屋に 1つずつ設置しなければならないため、 全体として高価に なる。 これに対し、 1箇所に全ての音楽データを蓄積しておき、 各部屋で選択さ れた音楽を再生することの可能な集中型オーディオシステムも提供されている。 し力 し、 上記集中型オーディオシステムでは、 音楽信号用の配線や制御信号用 の配線等、 多数の配線を各部屋に敷かなければならない。 また、 1つの曲を各部 屋で同時に再生することは可能であるが、 ある曲をある部屋で再生している最中 に、 同じ曲を別の部屋で最初から再生することはできない。

また、 汎用のパソコンに音楽再生用のアプリケーションプログラムをインスト ールすれば、 インターネット上のサイトから音楽データを取得し、 音楽を再生す ることは可能であるが、 受信済みのデータについてしか、 音楽 C Dのように、 曲 を途中から再生したり、 早送りしたり、 早戻ししたりすることはできない。 すな わち、 未だ受信していなデータについては、 特殊再生をすることができない。 発明の開示

本発明の 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のクライアントは、 サーバの負荷が大きいときはコンテンツの 指定量を少なくし、 サーバの負荷が小さいときはコンテンツの指定量を多くする など、 サーバの負荷に応じて取得するコンテンツの量を適切に調整することがで さる。

さらに、 サーバはクライアントが指定した 「曲データの一部」 のみを返信する ので、 クライアントは、 指定する 「曲データの一部」 を任意に変更することによ り、 クライアントが未受信のデータについても、 特殊再生 （例えば、 早送り、 早 戻し、 途中からの再生等） をすることができる。 さらに、 サーバは 「曲データの 一部」 しか送信しないので、 クライアントが受信を失敗した場合等には、 その失 敗した部分のみを再びサーバから受信すればよく、 受信失敗時の処理を早くする ことができる。

さらに、 クライアントが要求する曲のフォーマットが圧縮データ （MP 3等） であれば、 データの指定量を小さくすることにより、 サーバの負荷を軽減するこ とができる。 圧縮データは、 再生時にデコードされることによって、 データ量が 大きくなるからである。

好ましくは、 第 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のクライアントは、 サーバから返信さ れたサーバ特定情報を受信してサーバリストに登録する手段とを含む。

本ネットワーク型コンテンツ再生システムでは、 クライアントが所定情報をネ ットワークにブロードキャストし、 ネットワークに接続されているサーバが存在 すれば、 そのサーバがサーバ特定情報 （I Pアドレス、 ポート番号など） をその クライアントに知らせる。 そのため、 クライアントはネットワーク上に存在する サーバを探し出すことができる。

好ましくは、 第 1のクライアントはさらに、 サーバリストにサーバ特定情報が 登録されている力否かを判別する手段を含む。 判別の結果、 サーバリストにサー バ特定情報が登録されていない場合、 ブロードキャスト手段は所定情報を再びブ ロードキャストする。

この場合、 第 1のクライアントは、 サーバリストに 1つもサーバ特定情報が登 録されていなければ再びサーバを探し始めるので、 少なくとも 1つサーバを見つ けるまで探し続ける。

好ましくは、 第 1のクライアントはさらに、 ブロードキャスト手段によるプロ ードキャストの回数が所定回数に達したとき、 又はブロードキャスト手段による ブロードキャストの時間が所定時間に達したとき、 インターネット上のサーバに アクセスする手段を含む。

この場合、 第 1のクライアントは、 ローカルのネットワーク上にサーバが全く 存在しない場合にサーバを探し続けることはなく、 その場合はインターネット上 のサーバを探し出すことができる。

好ましくは、 第 1のクライアントは、 サーバと第 1のクライアントとの間でコ マンドを送受信するためのコマンドポートで接続を確立する手段と、 サーバから 第 1のクライアントに要求を強制的に送信するためのプッシュポートで接続を確 立する手段とを含む。

本ネットワーク型コンテンツ再生システムでは、 コマンドやステータスはコマ ンドポートでサーバ及ぴクライアントの間で送受信される。 また、 サーバからの コマンドはプッシュポートを通じて強制的にクライアントに送信される。

好ましくは、 第 1のクライアントはさらに、 自身を識別するために必要なクラ イアントインデックスを要求するクライアントインデックス要求コマンドをコマ ンドポートを通じてサーバに送信する手段を含む。 サーバはさらに、 第 1のクラ イアントから送信されたクライアントインデックス要求コマンドに応答してクラ イアントインデックスをクライアントに返信する手段を含む。 第 1のクライアン トはさらに、 サーバから返信されたクライアントインデックスをプッシュポート を通じてサーバに送信する手段を含む。

好ましくは、 第 1のクライアントは複数ある。 サーバは、 接続可能なクライア ントの数を制限する接続制限手段を含む。

好ましくは、 接続制限手段は、 未接続のクライアントが接続を試みてきたとき、 所定の優先順位に従って既接続のクライアントとの接続を断つ。

本発明によるさらにもう 1つのネットワーク型コンテンツ再生システムは、 サ ーバと、 サーバにネットワークを通じて接続された第 1のクライアントと、 第 1 のクライアントに接続された A V機器と、 サーバにネットワークを通じて接続さ れ、 AV機器を制御する第 2のクライアントとを備える。 第 2のクライアントは、 AV機器を制御するための制御コマンドをサーバに送信する手段を含む。 サーバ は、 第 2のクライアントから送信された制御コマンドを第 1のクライアントに送 信する手段を含む。 第 1のクライアントは、 サーバから送信された制御コマンド を AV機器に送信する手段を含む。 AV機器はさらに、 第 1のクライアントから 送信された制御コマンドに応答して制御される。

この場合、 制御コマンドは第 2のクライアントからサーバを通じて第 1のクラ イアントに送信される。 AV機器はこの制御コマンドに応じて制御される。 よつ て、 第 2のクライアントは A V機器を制御することができる。

本発明によるさらにもう 1つのネットワーク型コンテンツ再生システムは、 サ ーパと、 サーバに接続された第 1のクライアントと、 第 1のクライアントに接続 された AV機器と、 サーバにネットワークを通じて接続され、 AV機器を監視す る第 2のクライアントとを備える。 AV機器は、 自身に関する情報を第 1のクラ イアントに送信する手段を含む。 第 1のクライアントは、 AV機器から送信され た情報をサーバに送信する AV機器情報送信手段を含む。 サーバは、 第 1のクラ イアントから送信された情報を第 2のクライアントに送信する手段を含む。

この場合、 AV機器に関する情報は第 1のクライアント及ぴサーバを通じて第 2のクライアントに送信される。 よって、 第 2のクライアントはこの情報に基づ いて A V機器を監視することができる。 好ましくは、 第 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は、 本発明の実施の形態によるネットワーク型オーディオシステムの全体 構成を示す機能プロック図である。

図 2は、 図 1中の各サーバの構成を示す機能ブロック図である。 図 3は、 図 1中の各オーディオクライアントの構成を示す機能プロック図であ る。

図 4は、 図 1中の各コントローラの構成を示す機能プロック図である。

図 5は、 図 1〜図 3に示したサーバ及びオーディオクライアントの初期接続フ エーズにおける動作を示すフロー図である。

図 6は、 図 5中のオーディオクライアントによるサーバ探索動作を示すフロー 図である。

図 7は、 図 5中のクライアント及ぴサーバによる接続動作を示すフロー図であ る。

図 8は、 図 7に示した接続動作を終えたサーバによるプッシュ動作を示す図で ある。

図 9は、 図 8に続いて、 コントローラからサーバへのオーディオクライアント に対するサーバリクエスト動作を示す図である。 ―

図 1 0は、 図 9に続いて、 オーディオクライアントからサーバを通じてコント ローラにステータスを通知する動作を示す図である。

図 1 1は、 図 5中のオーディオクライアントによるクライアント情報送信動作 を示すフロー図である。

図 1 2は、 図 1及び図 2に示したサーバによる初期設定動作及びメイン動作を 示すフロー図である。

図 1 3は、 図 2に示したサーバに保存されるクライアント情報データベースを 示す図である。

図 1 4は、 図 2に示したサーバに保存されるコンテンツ情報データベースを示 す図である。

図 1 5は、 図 2に示したサーバに保存されるファームウェア情報データベース を示す図である。

図 1 6は、 図 1 2中のサーバ探索に対する応答のサブルーチンを示すフロー図 である。

図 1 7は、 図 1 2中のコマンドポート接続受付処理のサブルーチンを示すフロ 一図である。 図 1 8は、 図 1 2中のプッシュポート接続受付処理 （その 1 ) のサブルーチン を示すフロー図である。

図 1 9は、 図 1 2中のプッシュポート接続受付処理 （その 2 ) のサブルーチン を示すフロー図である。

図 2 0は、 図 1 5中のコマンド処理のサフ レーチンを示すフロー図である。 図 2 1は、 図 2 0中のステータス通知コマンド処理のサブルーチンを示すプロ 一図である。

図 2 2は、 図 2 0中のサーバリクエスト発行コマンド処理のサブルーチンを示 すフロー図である。

図 2 3は、 図 1〜図 3に示したサーバ及ぴオーディオクライアントによる曲リ スト取得及び再生動作を示すフロー図である。

図 2 4は、 図 2 3中のオーディオクライアントによる曲リスト取得動作を示す フロー図である。

図 2 5は、 図 2 4中のジャンルリスト及び曲リスト取得動作を示すフロー図で ある。

図 2 6は、 図 2 5で取得したジャンルリストを格納した領域を示す図である。 図 2 7は、 図 1 4に示したコンテンツ情報データベースのレコード構造を示す 図である。

図 2 8は、 図 2 5中のサーバによるジャンルリスト作成動作を示すフロー図で ある。

図 2 9は、 図 2 5で取得した曲リストを格納した領域を示す図である。

図 3 0は、 図 2 5中のサーバによる曲リスト作成動作を示すフロー図である。 図 3 1は、 図 2 5中のリスト要求コマンドのフォーマツトを示す図である。 図 3 2は、 図 2 5中の検索データのフォーマツトを示す図である。

図 3 3は、 図 2 5中の曲リスト取得動作におけるバッファメモリの遷移状態を 示す図である。

図 3 4は、 図 2 5に示したジャンルリスト及ぴ曲リスト取得動作に加え、 アル バムリスト取得動作を示すフロー図である。

図 3 5は、 図 2 3中のオーディオクライアントによる曲指定、 再生及び停止、 並びにサーバによる曲配信準備及ぴ配信の動作を示すフロー図である。

図 3 6は、 図 3 5に続くフロー図である。

図 3 7は、 図 3 5中の曲情報要求コマンドを示す図である。

図 3 8は、 図 3 5中の曲情報を示す図である。

図 3 9は、 図 3 5中の曲再生準備コマンドを示す図である。

図 4 0は、 図 3 5中のエラーコードを示す図である。

図 4 1は、 図 3 5中の曲データ転送要求コマンドを示す図である。

図 4 2は、 図 3 5中の曲データを示す図である。

図 4 3は、 図 4 2に示した曲データを格納するためのバッファメモリの構成を 示す図である。

図 4 4は、 図 4 3に示したバッファメモリにおいて、 曲の先頭から 1バッファ 分の曲データを格納した状態を示す図である。

図 4 5は、 図 4 4に続き、 全バッファ分の曲データを格納した状態を示す図で あ 。

図 4 6は、 図 4 5に続き、 先頭バッファから曲データを出力する状態を示す図 である。

図 4 7は、 図 4 6に続き、 1バッファ分の空きが生じた状態を示す図である。 図 4 8は、 図 4 7に続き、 バッファの空きが埋まった状態を示す図である。 図 4 9は、 図 1〜図 3に示したクライアント及びサーバによる早送り再生動作 を示すフロー図である。

図 5 0は、 図 1〜図 3に示したクライアント及ぴサーバによる一時停止動作を 示すフロー図である。

図 5 1は、 図 1中のコントローラによるサーバとの接続動作を示すフロー図で あ 。

図 5 2は、 図 5 1中の監視ハンドル及び制御ハンドル取得動作を示すフ口一図 である。

図 5 3は、 サーバによる複数のオーディオクライアントから複数のコントロー ラへのステータス通知を示す図である。

図 5 4は、 図 5 4において、 コントローラが監視ハンドルを取得した場合のス テータス通知を示す図である。

図 5 5は、 図 1中のコントローラによるオーディオクライアントのモニタ動作 を示すフロー図である。

図 5 6は、 図 5 5に示したモニタ動作の詳細を示すフロー図である。

図 5 7は、 図 1中のコントローラによるオーディオクライアントの制御動作を 示すフロー図である。

図 5 8は、 図 5 7中のオーディオクライアントによる制御コマンド処理動作の サブルーチンを示すフロー図である。

図 5 9は、 図 5 8中の再生制御動作のサブルーチンを示す図である。

図 6 0は、 図 1 3に示したクライアント情報データベースに含まれるクライア ントタイプの詳細を示す図である。

図 6 1は、 図 5 9に示した再生制御における曲リスト表示処理動作を示すフロ 一図である。

図 6 2は、 図 6 1中の曲リスト表示において、 MP 3及び WAVの両方を再生 可能なオーディオクライアントに関する曲リストの表示画面を示す図である。 図 6 3は、 図 6 1中の曲リスト表示において、 MP 3は再生可能であるが、 W A Vは再生不可能なオーディオクライアントに関する曲リストの表示画面を示す 図である。

図 6 4は、 図 5 9に示した再生制御においてユーザからの再生命令処理動作を 示すフロー図である。

図 6 5は、 図 1中のコントローラによる連続再生制御において、 再生コマンド の送信を示す図である。

図 6 6は、 図 6 5に続き、 完了及び停止ステータスの送信を示す図である。 図 6 7は、 図 6 6に示した完了及び停止ステータスの送信動作を示すフロー図 である。

図 6 8は、 図 6 6に続き、 再生コマンドの送信を示す図である。

図 6 9は、 図 6 5〜図 6 8に示した連続再生制御で用いられるリスト構築キー の構成を示す図である。

図 7 0は、 図 6 9に示したリスト構築キーに含まれるフィルタの種類を示す図 である。

図 7 1は、 図 6 9に示したリスト構築キーを用いた連続再生制御動作を示すシ 一ケンス図である。

図 7 2は、 図 5 6及ぴ図 7 1に示したコントローラによる完了処理動作を示す フロー図である。

図 7 3は、 優先順位を付けた連続再生処理の動作を示すフロー図である。

図 7 4は、 図 7 3に示した連続再生処理を示す機能プロック図である。

図 7 5は、 図 7 3に示した連続再生処理において、 優先順位が最高のコント口 ーラが切断された場合の連続再生処理を示す機能ブロック図である。

図 7 6は、 制御ハンドルを利用した連続再生処理の動作を示すフロー図である。 図 7 7は、 図 7 6に示した連続再生処理を示す機能プロック図である。

図 7 8は、 コンテンツサーバによる連続再生処理を示す機能プロック図である。 図 7 9は、 図 7 8に示した連続再生処理の動作を示すフロー図である。

図 8 0は、 図 7 8に示した連続再生処理において、 オーディオクライアントが 複数ある場合の連続再生処理を示す機能プロック図である。

図 8 1は、 図 8 0に示した連続再生処理において、 コンテンツサーバも複数あ る場合の連続再生処理を示す機能プロック図である。

図 8 2は、 図 8 1に示した連続再生処理において、 コンテンツサーバが切り換 えられた場合の連続再生処理を示す機能ブロック図である。

図 8 3は、 図 8 1に示した連続再生処理において、 コントローラも複数ある場 合の連続再生処理を示す機能プロック図である。

図 8 4は、 オーディオクライアント自身による連続再生処理の動作を示すフロ 一図である。

図 8 5は、 再生命令管理テーブルを利用した連続再生処理の動作を示すフロー 図である。

図 8 6は、 図 8 5に示した連続再生処理を示す機能ブロック図である。

図 8 7は、 図 8 5中の再生命令管理処理の詳細を示すフロー図である。

図 8 8は、 図 8 5に示した連続再生処理において、 コンテンツサーバが切り換 えられた場合の連続再生処理を示す機能プロック図である。 図 8 9は、 図 8 5中のサーバ切換処理の詳細を示すフロー図である。

図 9 0は、 サーバ、 コントローラ、 AV Rクライアント、 及び A Vレシーバを 含むネットワーク型オーディォシステムの構成を示す機能プロック図である。 図 9 1は、 図 9 0に示したネットワーク型オーディオシステムにおいて、 ステ 一タス及びコマンドの流れを示す機能ブロック図である。

図 9 2は、 図 9 0及び図 9 1に示したネットワーク型オーディオシステムにお いて、 コントローラによる AVレシーバの制御動作を示すフロー図である。 図 9 3は、 図 9 0に示したネットワーク型オーディオシステムにおいて、 制御 コマンド及びステータスの伝達経路を示す機能プロック図である。

図 9 4は、 図 9 3に示したコマンド及ぴステータスの伝達動作を示すフロー図 である。

図 9 5は、 図 9 4に示した各段階における制御コマンドを示す図である。 図 9 6は、 図 9 4に示した各段階におけるステータスを示す図である。

図 9 7は、 図 9 0〜図 9 6に示したネットワーク型オーディオシステムにおい て、 コントローラが AVRクライアントを通じて AVレシーバ AV Rのボリユー ムを上げる動作を示すフロー図である。

図 9 8は、 図 9 0〜図 9 6に示したネットワーク型オーディオシステムにおい て、 AVレシーバのステータスをサーバに転送する場合における AV Rクライア ントの動作を示すフロー図である。

図 9 9は、 図 9 0〜図 9 6に示したネットワーク型オーディオシステムにおい て、 サーバからの制御コマンドを AVレシーバに転送する場合における AV Rク ライアントの動作を示すフ口一図である。

図 1 0 0は、 図 9 9に示した動作の改良例を示すフロー図である。

図 1 0 1は、 図 1中のクライアント及びサーバによるファームウェアアップデ ート動作を示すフロー図である。

図 1◦ 2は、 図 1 0 1に示したファームウェアアップデート動作の詳細を示す フロー図である。

図 1 0 3は、 図 1 0 2中のファームウェアリスト作成動作を示すフロー図であ る。 図 1 0 4は、 図 1 0 2中のファームウェアリス卜の送信動作を示すフロー図で める。

図 1 0 5は、 本発明の他の実施の形態によるオーディオクライアントの外観構 成を示す正面図である。

図 1 0 6は、 図 1 0 5に示したオーディオクライアントの側面図である。 図 1 0 7は、 本発明の他の実施の形態によるネットワーク型オーディオシステ ム及びィンターネットの全体構成を示す機能プロック図である。

図 1 0 8は、 図 1 0 7に示したネットワーク型オーディオシステムにおけるサ ーパ探索動作を示すフロー図である。

図 1 0 9は、 本発明の他の実施の形態による曲データの転送動作を示すフロー 図である。

図 1 1 0は、 図 1 0 9中の S 1 6 0 2 1 , S 1 6 0 6 1で参照される対比テー ブルを示す図である。

図 1 1 1は、 本発明の他の実施の形態によるオーディオクライアントのスキッ プ再生動作を示すフロー図である。

図 1 1 2は、 図 1 1 1に示したスキップ再生動作において、 オーディオクライ アントのメモリに格納された曲リストを示す図である。

図 1 1 3は、 本発明の他の実施の形態によるオーディオクライアントのリビー ト再生動作を示すフロー図である。

図 1 1 4は、 本発明の他の実施の形態によるオーディオクライアントの途中再 生動作を示すフロー図である。

図 1 1 5は、 本発明の他の実施の形態によるオーディオクライアントの監視処 理及び接続回復処理を示すフロー図である。 発明を実施するための最良の形態

以下、 本発明の実施の形態を図面を参照して詳しく説明する。 図中同一又は相 当部分には同一符号を付してその説明を援用する。

[目次]

1 . 好ましい実施の形態 構成

1. 1. 全体

1. 1. 2. コンテンツサーバ

1. 1. 3. オーディオクライアント

1. 1. 4. コントローラ

1. 1. 5. A Vレシーバ

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. プッシュポート接続受付 （その 1)

1. 2. 1. 2. 4. プッシュポート接続受付 (その 2)

1. 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. 早戻し再生 2. 2. 3. 3. —時停止

2 2. 3. 4. スロー再生

2 3. コントローラの動作

2 3 ーパとの接続

2 3 1. 1. 監視ハンドル及び制御ハンドルの取得

2 3 2. モニタ （監視） 機能

2, 3 3. 制御機能

2, 3 3. 1. 制御コマンド処理

2, 3 3. 2. 再生制御

2. 3 3. 3. 再生可能なフォーマットかを識別して再生 2, 3 3. 4. 連続再生制御

2. 3, 3. 5. リスト構築キーを用いた連続再生制御

2. 3 3. 6. 優先順位を付げた連続再生制御

2. 3, 3. 7. 制御ハンドルを利用した連続再生制御

2. 3, 3. 8. コンテンツサーバによる連続再生制御

2. 3. 3. 9. オーディオクライアント自身による連続再生制御 2. 3, 3. 10. 再生命令管理テーブルを利用した連続再生制御 2. 4. A Vレシーバの制御

2. 5. ファームウェアアップデート

の実施の形態

1. コンセント内蔵型オーディオクライアント

2. インターネット上の音楽データを取得

3. 取得データ長変更機能付き再生

4. スキップ再生

5. リピート再生

6. 途中再生

7. 自動接続回復機能付き

ましい実施の形態

1. 構成 1. 1. 1. 全体

図 1を参照して、 本発明の実施の形態によるネットワーク型オーディオシステ ム 10は、 多数の曲の音楽データを蓄積するための複数のコンテンツサーバ S 1 〜S iと、 コンテンツサーバ S I〜S iからの音楽データに基づいて音楽を再生 するための複数のオーディオクライアント C 1〜C j と、 オーディオクライアン ト C 1〜C jを制御しかつモニタするための複数のコントローラ A 1〜Akと、 AV機器 （例えば、 スィッチャゃアンプなどを含む AVレシーバ） AVRと、 A Vレシーバ AVRを制御するための AVRクライアント ACとを備える。 以下、 コンテンツサーバのうち 1つを挙げる場合はコンテンツサーバ S i、 オーディオ クライアントのうち 1つを挙げる場合はオーディオクライアント C j、 コント口 ーラのうち 1つを挙げる場合はコントローラ A kを用いる。

ここではコンテンツサーバ S iには音楽データを蓄積しているが、 これに代え て又はこれと共に映像データを蓄積していてもよく、 その他、 さまざまなデジタ ルコンテンツ（例えば、 写真などの静止画等）を蓄積していてもよい。 以下では、 音楽データを例に説明する。 また、 コンテンツサーバ S i、 オーディオクライア ント C j、 コントローラ Akは、 それぞれ複数存在するが、 コンテンツサーバや オーディオクライアントは少な'くとも 1つ存在すればよい。 複数のコンテンツサ ーバ S 1〜S iが存在する場合、 オーディオクライアント C jはいずれのコンテ ンッサーバ S 1〜S iから音楽データを取得してもよく、 また、 特定の 1つのコ ンテンッサーバ S iのみから音楽データを取得してもよい。 また、 コントローラ Akは全くなくてもよい。 また、 AVレシーバ AVRや AVRクライアント AC は複数存在してもよいが、 全くなくてもよい。

これらは、 LAN (ローカルエリアネットワーク） 12により相互に接続され るが、 これに限定されることなく、 USB、 I EEE 1394など、 コンビユー タネットワークを構築するのに適切なものを採用すればよい。 LANを採用する 場合、 PC (パーソナルコンピュータ） で標準的な TCPZl Pプロ トコルを採 用するのが好ましいが、 UDPプロトコルなどを採用してもよく、 プロ トコルは 特に限定されない。 また、 この図では LANの基幹配線から枝分かれするように コンテンツサーバやオーディオクライアントが接続されているが、 たとえば 10 BASE— T 100 B AS E— TXの場合にはハブを中心にしてスター状に接 続される。

1. 1. 2. コンテンツサーバ

図 2を参照して、 各コンテンツサーバ S iは、 圧縮デジタル音楽データを蓄積 するための HDD (ハードディスクドライブ） 14と、 データベース管理部 16 及ぴネットワークプロトコル処理部 18を含む CPU処理部 20と、 本コンテン ッサーバ S iと LAN12との間で信号を送受信する LANコントローラ 22と を備える。

1. 1. 3. オーディオクライアント

図 3を参照して、 各オーディオクライアント C jは、 ネットワークプロ トコル 処理部 24及びシステム動作部 26を含むマイコン処理部 28と、 フラッシュメ モリ 30と、 順次入力された圧縮デジタル音楽データ等を一時的に記憶して順次 出力するメモリ 32と、 圧縮デジタル音楽データをデコードして非圧縮デジタル 音楽データを生成する音声処理部 34と、 デジタル音楽データをアナログ音楽デ ータに変換する D/A変換器 （DAC) 36と、 本オーディオクライアント C j と LAN12との間で信号を送受信する LANコントローラ 38とを備える。 ォ 一ディオクライアント C jは、 コンテンツサーバ S iと異なり、 圧縮デジタル音 楽データを蓄積するための HDDを備えていなくてもよい。

1. 1. 4. コントローラ

図 4を参照して、 各コントローラ Akは、 キーボード、 マウス、 タブレット、 タツチパネル等の入力装置 301と、 液晶ディスプレイ、 CRT (Cathode Ray Tube)等の表示装置 302と、 インストールされたコンピュータプログラムに従 つて所定の処理を実行する CPU303と、 本コントローラ Akと LAN12と の間で信号を送受信する LANコントローラ 304とを備える。 コントローラ A l〜Akはオーディオクライアント C 1〜C j と同様にコンテンツサーバ S 1〜 S iに対してクライアントとして機能する。 コントローラ A kがオーディオクラ イアント C j と異なる点は、 オーディオクライアント C jは再生機能を有するの に対し、 コントローラ A kは再生機能を有さず、 主としてオーディオクライアン トのモニタ及ぴ制御機能を有する点である。 上記オーディオクライアント C jは主として再生機能を有するが、 モニタ及び 制御機能を有していてもよい。 この場合、 オーディオクライアントはコントロー ラとしても機能する。

1. 1. 5. AVレシーバ

AVレシーバ AVRは、 特に限定されないが、 たとえば E I A— 232により

AVRクライアント ACに接続される。 AVRクライアント ACは、 主として A Vレシーバ AVRと通信できる機能を有するが、 オーディオクライアント C j と 同様に再生機能を併せて有していてもよい。

1. 2. 動作

1. 2. 1. コンテンツサーバ及びオーディオクライアントの初期設定動作 図 5を参照して、 あるオーディオクライアントに電源が投入されると、 そのォ 一ディオクライアントはまずコンテンツサーバを探索する (S 11)。 LAN 1 2に接続されている複数のコンテンツサーバ S iのうち稼働中のコンテンツサー バは、 これに応答する （S 21)。

続いて、 オーディオクライアントは、 コンテンツサーバとデータの送受信を可 能にするために、 コンテンツサーバに対して接続要求を発行する （S 12) 。 コ ンテンッサーバは、 この接続要求に応じてオーディオクライアントとの接続を確 立する （S 22) 。

最後に、 オーディオクライアントは自身に関するさまざまなクライアント情報 をコンテンツサーバに送信し (S 13) 、 コンテンツサーバはこれを受信する (S 23) 。

上記初期設定動作が終了すると次の曲リスト取得動作に移るが、 その説明の前 に、 オーディオクライアントの初期設定動作の詳細を説明する。

1. 2. 1. 1. オーディオクライアントの初期設定動作

1. 2. 1. 1. 1. コンテンツサーバ探索

図 6を参照して、 オーディオクライアントは、 まず、 発見したコンテンツサー パの I Pアドレス及ぴポート番号を記録するためのサーバリストをクリァする (S 1101) 。

続いて、 オーディオクライアントは、 特に限定されないが、 たとえば UDPプ 口トコルにより、 コマンドポートで予め定められたマジックヮードを L AN 1 2 上にブロードキャストする （S 1 1 0 2 ) 。 L AN 1 2に接続されている複数の コンテンツサーバ S iの中に稼働中のコンテンツサーバが存在すれば、 そのコン テンッサーバはブロードキャストされたマジックヮードをサーチポートで受信し、 そのマジックヮードをブロードキャストしたオーディオクライアントに同じマジ ックワードを返信し、 併せて自身を特定するためのサーバ特定情報 （具体的には I Pアドレス及びポート番号） を送信する。

続いて、 オーディオクライアントは、 サーバ特定情報の受信経過時間を計測す るためのタイマをリセットし （S 1 1 0 3 ) 、 その後、 サーバ特定情報を受信し たか否かを判別する （S 1 1 0 4 )。

サーバ特定情報を受信した場合 （コンテンツサーバを発見した場合） 、 オーデ ィォクライアントは、 そのサーバ特定情報をサーバリストに記録する （S 1 1 0 5 ) 。 そして、 オーディオクライアントは、 サーパリストが満杯になったか否か を判別し （S 1 1 0 6 ) 、 満杯になった場合は探索を完了し、 未だ満杯になって いない場合はステップ S 1 1 0 3に戻る。

一方、 サーバ特定情報を受信しない場合 （コンテンツサーバを発見しない場 合） 、 オーディオクライアントは、 サーバ特定情報の受信経過時間が所定時間、 たとえば 2秒を超えたか否かを判別し （S 1 1 0 7 ) 、 未だ超えていない場合は ステップ S 1 1 0 4に戻る。 すなわち、 オーディオクライアントは 2秒間だけコ ンテンッサーバからの応答を待つ。

サーバ特定情報の受信経過時間が 2秒を超えた場合、 オーディオクライアント は、 サーバリストが未だ空か否かを判別する （S 1 1 0 8 ) 。 サーバリストが空 の場合、 つまりサーバリストにサーバ特定情報が全く記録されていない場合、 ォ —ディオタライアントはステップ S 1 1 0 2に戻ってマジックヮードを再ぴブロ ードキャストする。 一方、 サーバリストが空でない場合、 つまりサーバリストに 少なくとも 1つのコンテンツサーバのサーバ特定情報が記録されている場合、 ォ 一ディオクライアントは探索を完了する。 すなわち、 オーディオクライアントは 少なくとも 1つのコンテンツサーバを発見するまで探索を続ける。

上記コンテンツサーバ探索の結果、 サーバリストには 1又は 2以上のコンテン ッサーバに対応する I pアドレス及ぴポート番号が付与される。

1. 2. 1. 1. 2. コンテンッサーバとの接続

図 7を参照して、 オーディオクライアントは、 ユーザの操作に応じてサーバリ ストの中から 1つのコンテンツサーバを選択し （S 1201) 、 その選択したコ ンテンッサーバの I Pアドレス及ぴポート番号を取得する （S 1202) 。 続いて、 オーディオクライアントは、 取得した I Pアドレス及びコマンドポー トで T C P (Transmission Control Protocol)ソケット （1) を生成し （S 1 2 03) 、 この TCPソケット （1) でコンテンツサーバと接続する (S 1 20 4) 。 コマンドポートは、 コンテンツサーバとオーディオクライアントとの間で コマンドを送受信するためのポートである。 コンテンツサーバがコマンドポート での接続を受け付け （S 2201) 、 接続が成功した場合はステップ S 1206 に進むが、 そうでない場合は接続は失敗となる （S 1205) 。 これによりォー ディオクライアントは、 コンテンツサーバとの間でコマンドを送受信するための 接続を確立する。

続いて、 オーディオクライアントは TCPソケット (1) でクライアントイン デッタス要求コマンドをコンテンツサーバに送信する (S 1206) 。 コンテン ッサーバは、 このクライアントインデックス要求コマンドに応答して TCPソケ ット (1) からクライアントインデックスをオーディオクライアントに返信し (S 2202) 、 オーディオクライアントはこれを受信する (S 1207) 。 ク ライアントインデックスは、 コンテンツサーバにより各オーディオクライアント に割り当てられる識別番号である。 クライアントインデックス要求コマンドは、 オーディォクライアントがコンテンツサーバにクライアントインデックスを要求 するコマンドである。

続いて、 オーディオクライアントは、 コンテンツサーバの I Pアドレス及ぴプ ッシュポートで TCPソケット (2) を生成し (S 1208) 、 この TCPソケ ット (2) でコンテンツサーバと接続する (S 1209) 。 プッシュポートは、 コンテンツサーバからの自発的な要求又はコントローラからの要求に応じたコン テンッサーバからの要求 （以下 「サーバリクエスト」 という） を常に受信可能な 待機状態にあるポートである。 コンテンツサーバがプッシュポートでの接続を受 け付け （S 2 0 9 ) 、 接続が成功した場合はステップ S 1 2 1 1に進むが、 そう でない場合は接続は失敗となる （S 1 2 1 0 ) 。 これによりオーディオクライァ ントは、 サーバリクエストを受信するための接続を確立する。

この時点では、 コンテンツサーバは未だ、 プッシュポートに接続されているの はどのオーディオクライアントなのかわかっていない。 そこで、 オーディオクラ イアントはステップ S 1 2 0 7で取得したクライアントインデックスを T C Pソ ケット ( 2 ) でコンテンツサーバに送信する ( S 1 2 1 1 ) 。 コンテンツサーバ は、 このクライアントインデックスに基づいてプッシュポートに接続されている オーディオクライアントを特定する （S 2 2 0 4 ) 。 以降、 コンテンツサーバは、 サーバリクエストをオーディオクライアントに送信するとき、 このプッシュポー トを使用する。

以上の結果、 コマンドポート及びプッシュポートで 2つの接続が確立する。 こ れら 2つの接続は、 オーディオクライアント C j及ぴコンテンツサーバ S iの間 だけでなく、 後述するコントローラ A k及びコンテンツサーバ S iの間、 さらに AV Rクライアント A C及びコンテンツサーバ S iの間でも確立する。

一般に、 サーバクライアントシステムでは、 HT T Pプロトコルに見られるよ うに、 クライアントからの要求 （ページ要求など） に対し、 コンテンツサーバが レスポンス （HTML文書など） を返すというものである。 これは、 アクション のトリガはクライアントのみが有し、 コンテンツサーバが自発的にクライアント に対して働きかけることができないということを意味している。 このため、 コン テンッサーバがクライアントに対して何らかの要求、 たとえばコンテンッサーバ シャツトダウン時にクライアントにその旨を通知するなど、 自発的なァクション をする場合でも、 クライアントからの要求がなければ通知を行うことはできない。 クライアントがサーバリクエストを受信するためには、 一定時間ごとにコンテ ンッサーバに対してサーバリクエストがないかを確認するコマンドを発行する。 コンテンツサーバはクライアントにより発行されたコマンドに応答してサーバリ クエストをクライアントに送信し、 クライアントはこれを受信する。

上記 HT T Pプロトコルの場合も、 動的に更新されるページに関しては一定時 間ごとにページのリロードを行わなければならないということが知られている。 この手法はクライアントからのポーリングによるサーバリクエストの取得と呼ぶ ことができるが、 以下のような問題点がある。

( 1 ) ポーリング間隔をある程度短くして、 こまめにサーバリクエストがある か否かを尋ねないと、 コンテンッサーバが要求を生じた時間と実際にその要求を オーディオクライアントが受け取るまでの時間に差が生じる。

( 2 ) 上記のようにポーリング間隔を短くすると、 ネットワークトラフィック 及びサーバクライアントの負荷が増大してしまう。

( 3 ) コンテンツサーバがサーバリクエストをクライアントに送信しなければ ならない頻度は通常のコマンドを送受信する頻度に比べて低いので、 大概のポー リングは無駄になる。 サーバリクエストがあるか否かを尋ねても、 通常は何も要 求はないと返答されるからである。

上記問題を解決するためには、 クライアントからのポーリングではなく、 コン テンッサーバからのインタラプトでサーバリクエストをクライアントに送信すれ ばよい。 これにより、 上記 （1 ) で問題となっているリアルタイム性の欠如、 並 ぴに上記 （2 ) 及び （3 ) のような無駄な負荷を排除することができる。

これを実現するために、 上述したように 2つの接続を確立している。 1つは、 オーディオクライアント C jがコマンドを発行し、 コンテンツサーバ S iがそれ に応答するのに用いられるコマンドポートに形成される接続である。 もう 1つは、 コンテンツサーバ S iがサーバリクエストをオーディオクライアント C jに送り つけるのに用いられるプッシュポートに形成される接続である。 これによりォー ディオクライアント C jからのポーリングを用いずに、 コンテンツサーバ S iが サーバリクエストをオーディオクライアント C jに通知することができる。

以下、 これら 2つの接続を用いた動作の概要を説明する。

図 8に示すように、 コンテンツサーバ S iは、 シャットダウン時に、 プッシュ ポートを通じて全てのオーディオクライアント C jにその旨を通知し、 これによ りオーディオクライアント C jに何らかの動作 （電源を落とすなど） をさせる。 また、 図 9に示すように、 コントローラ A kは、 オーディオクライアント C j を制御するとき （たとえば再生や停止など） 、 その制御内容を含むサーバリクェ ストの発行をコンテンツサーバ S iに要求するコマンドをコマンドポートを通じ てコンテンツサーバ S iに送信する。 コンテンツサーバ S iはこのコマンドに応 答してサーバリクエストをプッシュポートを通じてオーディオクライアント C j に送信する。 その結果、 コントローラ Akはオーディオクライアント C jを制御 することができる。

さらに、 図 10に示すように、 オーディオクライアント C〗は、 その動作状態 が変化したときに、 その動作状態の変化をコマンドポートを通じてコンテンッサ ーバ S iに送信する。 コンテンツサーバ S iは、 その動作状態の変化をプッシュ ポートを通じてオーディオクライアント C jの動作状態を監視しているコント口 ーラ Akに送信する。 したがって、 オーディオクライアント C jはその動作状態 の変化をリアルタイムにコントローラ Akに通知することができる。

以上により、 本ネットワーク型オーディオシステムにおけるネットワークトラ フィック並びにコンテンツサーバ及びオーディオクライアントの負荷を最小に抑 えることができ、 システム全体のパフォーマンスを増大させることができる。

1. 2. 1. 1. 3. クライアント情報の送信

図 11を参照して、 オーディオクライアントは、 自身の属性情報をコンテンツ サーバに送信し （S 1301〜S 1303) 、 さらに自身の初期ステータスを送 信する （S 1304〜S 1305) 。

具体的には、 オーディオクライアントは、 TCPソケット （1) でオーディオ クライアントタイプを送信する (S 1301) 。 オーディオクライアントタイプ には、 再生可能な音楽フォーマットの種類、 リモートコントローラ （リモコン） による操作の可否、 E I A— 232ポートの有無等がある。

続いて、 オーディオクライアントは、 TCPソケット （1) でプロダクト ID を送信する （S 1302) 。 プロダクト I Dは、 オーディオクライアントのタイ プごとに付与される機種情報である。 したがって、 同じタイプのオーディオクラ イアントには同じプロダクト I Dが付与される。

続いて、 オーディオクライアントは、 TCPソケット （1) でファームウェア IDを送信する （S 1303) 。 ファームウェア I Dは、 オーディオクライアン トにインストールされているファームウェアのバージョン情報である。

続いて、 オーディオクライアントは、 TCPソケット (1) でポリュームの初 期値を送信する （S 1 304) 。 ボリュームの初期値は、 オーディオクライアン トで再生される音量の初期値である。

最後に、 オーディオクライアントは、 TCPソケット （1) でオーディオクラ イアントの初期ステータスを送信する （S 1 30 5) 。 オーディオクライアント の初期ステータスには、 停止ステータス等がある。

コンテンツサーバは、 クライアントから送信されたクライアント情報を受信し、 クライアント情報データベース （図 1 3) に格納する。 クライアント情報は、 ォ 一ディオクライアント C jだけでなく、 コントローラ A k及ぴ A VRクライアン ト ACからもコンテンツサーバ S iに送信される。 コンテンツサーバ S iは、 こ のクライアント情報に基づいて全てのクライアントを管理する。

1. 2. 1. 2. コンテンツサーバの初期設定動作

次に、 上記オーディオクライアントの初期設定動作に対応するコンテンッサー パの初期設定動作を説明する。

図 1 2を参照して、 コンテンツサーバは、 図 1 3に示すようなクライアント情 報データベースのための格納領域を最大クライアント数分確保し、 クリァする (S 20 1) 。 各クライアント情報は、 接続の有無を示すフラグと、 クライアン トタイプと、 現在のステータスと、 現在のボリューム値と、 プロダクト I Dと、 ファームウェア I Dと、 クライアント名と、 再生ファイル名と、 リスト構築キー とを含む。

クライアントタイプには、 オーディオクライアント、 コントローラ、 AVRク ライアントといったクライアントのタイプと、 再生可能なデータフォーマツト (MP 3、 WAVなど） とが記録される。 クライアントタイプにはさらに、 リモ コン制御の可否も記録される。 たとえばリモコンにより制御可能なオーディォク ライアン卜には、 リモコン制御可能という情報が記録される。 ステータスには、 「再生」 、 「停止」 、 「ポーズ」 、 「完了」 、 「ファームウェアアップデート 中」 などのステータスが記録される。 再生フアイノレ名には、 現在再生中の曲のデ ータが格納されている HDD 14のフルパス名が記録される。 また、 再生フアイ ル名はフルパス名のようなファイル名そのものである必要はなく、 そのファイル を特定可能な情報であればいかなる情報であつてもよい。 たとえばコンテンッサ ーパに所定の識別番号とファイル名とを対応つけたテーブルを記憶しておき、 コ ンテンッサーバがこのテーブルを参照して識別番号をファイル名に変換するよう にしてもよい。 この場合、 長いファイル名を送受信する必要がなくなる。 また、 ファイル名から直ちに曲のデータが格納されているファイルを特定することがで きないので、 セキュリティが向上する。 さらに、 リスト構築キーは、 コンテンツ サーバがリストを作成するためのものであるが、 詳細は後述する。

続いて、 コンテンツサーバは、 コマンドポートへの接続要求を受け付けるソケ ットと、 プッシュポートへの接続要求を受け付けるソケットと、 サーチポートへ のサーバ探索要求を受け付けるソケットとを作成する （S 2 0 2 ) 。 サーチポー トは、 コンテンツサーバ探索時に使うポートであり、 このサーチポートにマジッ クワードが入力されたかどうかをコンテンツサーバは監視する。

続いて、 コンテンツサーバは、 図 1 4に示すようなコンテンツ情報データべ一 スと、 図 1 5に示すようなファームウェア情報データベースとを構築する （S 2 0 3 ) 。 コンテンツ情報データベースは、 コンテンツ情報を曲数分備える。 各曲 のコンテンツ情報は、 ファイル名と、 曲名と、 アーティスト名と、 アルバム名と、 ジャンル名と、 曲の長さ （時間） と、 データフォーマットと、 再生回数と、 最終 アクセス時間とを含む。 このファイル名には、 当該曲のデータが格納されている HD D 1 4のフルパス名が記録される。 ファームウェア情報データベースは、 フ アーム情報をファームウェアのファイル数分備える。 ファームウェア情報は、 プ 口ダクト I Dと、 ファームウェア I Dと、 ファイルサイズと、 データフォーマツ トと、 ファイル名とを含む。 このファイル名には、 当該ファームウェアが格納さ れているインターネット上のサイトを示すフルパス名が記録される。

コンテンツサーバは、 サーチポートに書込があった場合 ( S 2 0 4 ) 、 後述す るコンテンツサーバ探索に対する応答処理を行う ( S 2 0 5 ) 。 コンテンツサー パはまた、 コマンドポートに書込があった場合 （S 2 0 6 ) 、 後述するコマンド ポート接続受付処理を行う （S 2 0 7 ) 。 コンテンツサーバはまた、 プッシュポ 一トに書込があった場合 （S 2 0 8 ) 、 後述するプッシュポート接続受付処理 (その 1 ) を行う （S 2 0 9 ) 。 コンテンツサーバはまた、 未処理プッシュポー トに書込があった場合 （S 2 1 0 ) 、 後述するプッシュポート接続受付処理 （そ の 2) を行う （S 21 1) 。

1. 2. 1. 2. 1. コンテンッサーバ探索に対する応答

図 16を参照して、 サーチポートに書込があった場合、 コンテンツサーバは、 その書き込まれた内容を取得し （S 2051) 、 その内容が正しいマジックヮー ドか否かを判別する (S 2052) 。 正しいマジックヮードであれば、 コンテン ッサーバは同じマジックワードを送信元クライアントに返信し （S 2053) 、 併せて自身の I Pアドレス及びポート番号を返信する。

1. 2. 1. 2. 2. コマンドポート接続受付

図 1 7を参照して、 コマンドポートにクライアントから接続の要求があった場 合、 コンテンツサーバは、 現在接続されているクライアント数が最大クライアン ト数に達しているか否かを判別する （S 2071) 。 最大クライアント数に達し ている場合、 コンテンツサーバは、 優先度の低いクライアントを探し、 強制的に 切断する （S 2072) 。 クライアントの優先度は、 現在再生を行っていないォ 一ディオクライアント、 一定時間通信を行っていないオーディオクライアント等 ほど、 低くなる。 そして、 コンテンツサーバは、 強制的に切断したクライアント のクライアント情報をクリアする （S 2073)。

なお、 現在接続されているクライアント数が最大クライアント数に達している 場合、 上記に代えて、 コンテンツサーバはこれ以上クライアントと接続しないよ うにしてもよい。

クライアントの接続可能なソケットに余裕がある場合、 又は優先度の低いクラ イアントを切断して接続可能なソケットを確保した場合、 コンテンツサーバは、 クライアントからの接続要求の受付を開始する （S 2074)。

受付が成功した場合 (S 2075) 、 コンテンツサ一バは、 クライアント情報 データベースの空き領域を探す （_S 2076) 。 具体的には、 フラグが FALS Eになっているクライアント情報を探す。 コンテンツサーバは、 その探した領域 を新しいクライアント情報格納領域に割り当て （S 2077) 、 前のクライアン ト情報をクリアする （S 2078) 。

続いて、 コンテンツサーバはフラグを TRUEに設定し （S 2078) 、 受付 の結果として得られたソケット情報をクライアント情報格納領域のソケットフィ ールドに格納する （S 2079) 。

1. 2. 1. 2. 3. プッシュポートへの接続受付処理 （その 1)

図 18を参照して、 プッシュポートにクライアントから接続の要求があった場 合、 コンテンツサーバは、 その受付を開始する （S 2091) 。 受付が成功した 場合 （S 2092) 、 受付の結果として得られたソケット情報を未処理プッシュ ポートのキューに格納する （S 2093) 。 この時点では未だ、 コンテンツサー バはプッシュポートに接続されたクライアントを特定できていない。 このような プッシュポートを未処理プッシュポートとレ、う。

1. 2. 1. 2. 4. プッシュポート接続受付処理 （その 2)

図 1 9を参照して、 未処理プッシュポートにクライアントから接続の要求があ つた場合、 コンテンツサーバは、 そのプッシュポートに書き込まれたコマンドを 取得する （S 21 1 1) 。 そのコマンドのサイズが 0よりも大きく （S 2 1 1 2) 、 かつそのコマンドがクライアントインデックス通知コマンドであれば (S 21 13) 、 コンテンツサーバは、 そのクライアントインデックスが示すクライ アントは既にコマンドポートに接続されているか否かを判別する (S 21 14) 。 未だ接続が完了していない場合、 コンテンツサーバはエラーコードをー 1 (失 敗） に設定し （S 21 15) 、 ステップ S 2119に進む。 一方、 既に接続が完 了している場合、 コンテンツサーバは、 このプッシュポートをそのクライアント 用のプッシュポートとして登録する （S 21 16) 。 コンテンツサーバはさらに、 このプッシュポートを未処理プッシュポートのキューから削除し （S 21 1 7) 、 エラーコードを 0 (成功) に設定する (S 21 18) 。 そして、 コンテンツサー バは、 設定されたエラーコードをクライアントに返信する （S 21 1 9) 。

1. 2. 2. コンテンッサーバ及ぴオーディオクライアントのメイン動作 1. 2. 2. 1. コマンド受付

再ぴ図 12を参照して、 コンテンツサーバは、 初期設定を完了した後、 クライ アントからのコマンドを受け付ける。 すなわち、 コンテンツサーバは、 ステップ S 213〜S 217を最大クライアント数分繰り返す （S 212、 S 218、 S 219) 。 nは、 クライアントに割り当てられる 0から （最大クライアント数一 具体的には、 コンテンツサーバは、 クライアント情報データベースのフラグを 参照し、 n番目のクライアントが既にコマンドポートに接続されているか否かを 判別する （S 213) 。 既に接続されている場合、 コンテンツサーバは n番目の クライアント用のコマンドポートに書込があつたか否かを判別する （S 214) 。 書込があった場合、 コンテンツサーバはその書き込まれたデータのサイズが 0又 は一 1であるか否かを判別する （S 215) 。 0又は一 1の場合、 クライアント が切り離されたか、 又はソケットエラーが発生したかであるから、 コンテンツサ ーパは n番目のクライアント情報をクリアする （S 216) 。 一方、 そうでない 場合、 コンテンツサーバは次のコマンド処理を行う （S 217) 。

1. 2. 2. 1. 1. コマンド振分処理

図 20を参照して、 クライアントからコマンドポートへの書込があった場合、 コンテンツサーバは、 先頭 4バイトに格納されたコマンドに応じて処理を分岐す る (S 2171) 。 すなわち、 オーディオクライアントからコンテンツサーバに ステータスの変動を通知するといつたステータス通知コマンドであれば （S 21 72) 、 オーディオクライアントから通知されたステータスをコントローラに通 知する （S 2173) 。 詳細は後述する。 また、 コントローラからオーディオク ライアントへのコンテンツサーバリクエスト発行コマンドであれば (S 21 7

4) 、 コントローラからの要求をオーディオクライアントに通知する (S 21 7

5) 。 詳細は後述する。 その他、 コンテンツサーバはコマンドに応答して所定の 処理を行う。

1. 2. 2. 1. 2. ステータス通知コマンド処理

あるオーディオクライアント （以下 Γ当該オーディオクライアント」 とい う。 ） からのコマンドがステータス通知コマンドの場合、 図 21を参照して、 コ ンテンッサーバは、 まず、 そのコマンド中のパラメータに格納されたステータス ゃポリューム等のクライアント情報をクライアント情報データベースに格納する (S 21 731) 。 したがって、 コンテンツサーバは常に最新のクライアント情 報を保持している。

次に、 コンテンツサーバは、 全てのクライアントの中からコントローラを探し 出し、 探し出したコントローラに当該オーディオクライアントのステータスを通 知する。 そのため、 コンテンツサーバは、 以下のステップ S 21 733〜S 21 736を最大クライアント数分繰り返す （S 21732、 S 21737, S 21 738) 。

具体的には、 コンテンツサーバは、 クライアント情報のクライアントタイプを 参照して、 n番目のクライアントがコントローラか否かを判別する （S 2173 3) 。 したがって、 当該オーディオクライアントのステータスをコントローラで はない当該他のオーディオクライアントに通知することを防ぐことができる。 コ ントローラであれば、 コンテンツサーバは、 そのコントローラが当該オーディオ クライアントに対する監視ハンドルを取得しているか否かを判別する （S 217 34) 。 監視ハンドルを取得していれば、 コンテンツサーバは、 そのコントロー ラがプッシュポートへの接続を完了しているか否かを判別する （S 21 735) 。 プッシュポートへの接続を完了していれば、 コンテンツサーバは、 そのコント ローラのプッシュポートに当該オーディオクライアントのクライアント情報を書 き込み、 これにより当該オーディオクライアントのステータスをコントローラに 通知する （S 21736) 。

1. 2. 2. 1. 3. サーバリクエスト発行コマンド処理

コントローラからのコマンドがサーバリクエスト発行コマンドの場合、 図 22 を参照して、 コンテンツサーバは、 まず、 そのコマンドに含まれる発行元コント ローラ、 送信先オーディオクライアント、 要求内容等を取得する （S 21 75 1) ₀

コンテンツサーバは、 発行元コントローラが送信先オーディオクライアン卜の 制御ハンドル （後述） を取得しているか否かを判別し （S 21 752) 、 制御ハ ンドルを取得していなければエラーコードをー 1に設定する （S 21753) 。 したがって、 制御ハンドルを取得していないコントローラがオーディオクライァ ントを制御するのを防止することができる。

制御ハンドルを取得していれば、 コンテンツサーバは、 クライアント情報中の フラグを参照して送信先オーディオクライアントのコマンドポートで接続が確立 しているか否かを判別し （S 21 754) 、 確立していなければエラーコードを —2に設定する （S 21755) 。 したがって、 制御不可能なオーディオクライ アントにコマンドを送信するのを防止することができる。

送信先オーディオクライアントのコマンドポートで接続が確立していれば、 コ ンテンッサーバは、 送信先オーディオクライアントのプッシュポートで接続が確 立しているか否かを判別し （S 21756) 、 確立していなければエラ コード を 1に設定する （S 21757) 。 一方、 確立していれば、 コンテンツサーバは、 送信先オーディオクライアントのプッシュポートにコントローラからの要求内容 を送信し （S 21758) 、 エラーコードを 0 (エラーなし） に設定する （S 2 1759) 。

最後に、 コンテンツサーバは、 発行元コントローラにエラーコードを返信する (S 21760) 。

なお、 送信先オーディオクライアントがプッシュポートに接続されていない場 合は、 送信先オーディオクライアントがポーリングで問い合わせをしてきたとき に、 コントローラからの要求内容を送信先オーディオクライアントに送信するよ うにしてもよい。

1. 2. 2. 2. 通常再生

次に、 ユーザがオーディオクライアント C jに所望の曲を再生させる場合の動 作を説明する。 ここでは、 ユーザは所望の曲を直ちに指定するのではなく、 まず 所望の曲リストを指定し、 その曲リストの中から所望の曲を選択する。 以下、 詳 述する。

図 23を参照して、 オーディオクライアントは、 ユーザの操作に応じて曲リス . ト要求コマンドをコンテンツサーバに送信する （S 14) 。 曲リスト要求コマン ドは、 オーディオクライアントがコンテンツサーバに対して所望の曲リストを要 求するためのコマンドである。 曲リストには、 複数の曲名やアーティスト名など が列挙されている。 コンテンツサーバはこの曲リスト要求コマンドに応じて曲リ ストを要求元のオーディオクライアントに送信し (S 24) 、 オーディオクライ アントはこれを受信する （S 14) 。

オーディオクライアントはユーザの操作に応じて曲リストに含まれる曲を指定 し （S 15) 、 コンテンツサーバはこれに応じて指定された曲の配信を準備する (S 25) 。 続いて、 コンテンツサーバは指定された曲をオーディオクライアントに配信し

(S 26) 、 オーディオクライアントは配信された曲を再生する （S 16) 。 そ して、 オーディオクライアントは、 再生終了後又はユーザの操作に応じて曲の再 生を停止する （S 17) 。

以下、 ステップ S 14〜S 16の各々の詳細を説明する。

1. 2. 2. 2. 1. 曲リスト取得

図 24を参照して、 オーディオクライアントは、 コンテンツサーバにプレイ名 リストを要求するか否かを判別する （S 1401) 。 プレイ名リストは、 プレイ リストのタイ トルを列挙したものである。 プレイリストは、 ユーザにより選択さ れた複数の曲を列挙した曲リストである。 コンテンツサーバには、 ユーザにより 作成された複数のプレイリストが予め格納されている。

ユーザは、 コンテンツサーバに格納されている複数のプレイリストの中から 1 つを選択しょうとする場合、 まずどのようなプレイリストが登録されているのか を確認するために、 コンテンツサーバにプレイ名リストを要求する。 オーディオ クライアントはこのユーザの操作に応じてコンテンツサーバにプレイ名リストを 要求し、 コンテンツサーバからプレイ名リストを受信する （S 1402) 。 続いて、 オーディオクライアントは、 指定されたプレイリストを要求するか否 かを判別する （S 1403) 。 ユーザがプレイ名リストの中から所望のプレイリ ストを指定し、 この操作に応じてオーディオクライアントが指定されたプレイリ ストを要求する場合はステップ S 1413に進み、 要求しない場合はステップ S

1401又 S 1403に戻る （S 1404) 。

プレイ名リストを要求しない場合、 オーディオクライアントは、 コンテンツサ ーパにアーティストリストを要求するか否かを判別する （S 1405) 。 ァーテ イストリストには、 複数のアーティスト名が列挙されている。 アーティストリス トはコンテンツサーバに予め用意されているのではなく、 オーディオクライアン トからの要求に応じて図 14に示したコンテンッ情報データベースからその都度 作成される。

ユーザがアーティストリストを要求する場合、 オーディオクライアントはユー ザの操作に応じて所望のアーティストリストをコンテンツサーバに要求し、 コン テンッサーバからアーティストリストを受信する （_{S 1} 4 0 6 ) 。

続いて、 オーディオクライアントは、 指定されたアーティストの曲リストを要 求するか否かを判別する （S 1 4 0 7 ) 。 ユーザがアーティストリストの中から 所望のアーティストを指定し、 この操作に応じてオーディオクライアントが指定 されたアーティストの曲リストを要求する場合はステップ S 1 4 1 3に進み、 要 求しない場合はステップ S 1 4 0 1又 S 1 4 0 7に戻る （S 1 4 0 8 ) 。 この曲 リスト ίこは指定されたアーティストの曲名などが列挙されているが、 この曲リス トも上記アーティストリストと同様にコンテンツサーバに予め用意されているの ではなく、 オーディオクライアントからの要求に応じて図 1 4に示したコンテン ッ情報データベースからその都度作成される。

アーティストリストを要求しない場合、 オーディオクライアントは、 コンテン ッサーバにジャンルリストを要求するか否かを判別する （S 1 4 0 9 ) 。 ジヤン ルリストには、 複数のジャンル名が列挙されている。 ジャンルリストも上記ァー テイストリストと同様にコンテンツサーバに予め用意されているのではなく、 ォ 一ディオクライアントからの要求に応じて図 1 4に示したコンテンツ情報データ ベースからその都度作成される。

ユーザがジャンルリストを要求する場合、 オーディオクライアントはユーザの 操作に応じて所望のジャンルリストをコンテンツサーバに要求し、 コンテンツサ ーバからジャンルリストを受信する （S 1 4 1 0 ) 。

続いて、 オーディオクライアントは、 指定されたジャンルの曲リストを要求す るか否かを判別する （S 1 4 1 1 ) 。 ユーザがジャンルリストの中から所望のジ ャンルを指定し、 この操作に応じてオーディオクライアントが指定されたジャン ルの曲リストを要求する場合はステップ S 1 4 1 3に進み、 要求しない場合はス テツプ S 1 4 0 1又 S 1 4 1 1に戻る （S 1 4 1 2 ) 。 この曲リストには指定さ れたジャンルの曲名などが列挙されているが、 この曲リストも上記アーティスト の曲リストと同様にコンテンツサーバに予め用意されているのではなく、 オーデ ィォクライアントからの要求に応じて図 1 4に示したコンテンツ情報データべ一 スからその都度作成される。

上記の結果、 曲リストを要求する場合、 オーディオクライアントはコンテンツ サーバに曲リス トを要求し、 コンテンツサーバから曲リス トを受信する （S 1 4 1 3 ) 。 これにより曲リストの取得は終了する。

次に、 図 2 5を参照して、 ジャンルリス トを取得し、 その中から所望のジヤン ルとしてポップスを選択してポップスの曲リストを取得する場合の動作を説明す る。

この場合、 オーディオクライアントは、 コンテンツサーバにジャンルリストを 要求するためのリスト要求コマンドを送信する （S 1 4 2 1 ) 。 コンテンツサー パは、 これに応答してジャンルリストを返信する ( S 2 4 0 1 ) 。 オーディオク ライアントは、 コンテンツサーバからジャンルリストを受信し、 図 2 6に示すよ うにメモリ 3 2に格納する （S 1 4 2 2 ) 。

ジャンルリストは、 予め作成してコンテンツサーバに保存しておいてもよいが、 ここではそうではなく、 オーディオクライアントから要求されるたびに、 コンテ ンッサーバが図 1 4に示したコンテンツ情報データベースに基づいてジャンルリ ストを作成する。 以下、 ジャンルリストの作成方法を説明する。

図 2 7に示すように、 コンテンツ情報データベースは、 n曲を保存している場 合、 n個のレコードを有する。 各レコードには、 曲名、 ジャンル、 アーティスト 名、 アルバム名などが記録されている。

このようなコンテンツ情報データベースを用いてジャンルリストを作成する場 合、 図 2 8を参照して、 まず、 コンテンツサーバは、 レコードの番号を示すイン デッタスを 0に初期化する （S 2 4 0 1 1 ) 。

続いて、 コンテンツサーバは、 インデックスが示すレコードのジャンルが既に ジャンルリストに存在する力否かを判別する （S 2 4 0 1 2 ) 。 存在しない場合、 コンテンツサーバはそのレコードのジャンルをジャンルリストに追加し ( S 2 4 0 1 3 ) 、 その後、 インデックスをインクリメントする ( S 2 4 0 1 4 ) 。 一方、 存在する場合、 コンテンツサーバは、 ステップ S 2 4 0 1 3をスキップし、 直ち にインデックスをインクリメントする （S 2 4 0 1 4 ) 。

続いて、 コンテンツサーバは、 インデックスが示すレコードの番号が全レコー ド数 nよりも小さいか否かを判別し （S 2 4 0 1 5 ) 、 小さい場合はステップ S 2 4 0 1 2に戻り、 一方、 小さくない場合はジャンルリストの作成を完了する。 上記の処理により、 コンテンツサーバは、 コンテンツ情報データベースに蓄積 されている全ての曲のジャンルを重複することなくピックアップし、 ジャンルリ ストを作成する。 このように、 ジャンルリストは予めデータベース化されている のではなく、 オーディオクライアントからの要求のたびに一時的に作成されるの で、 ジャンルリストを常に格納しておくためのメモリ領域は不要である。

再び図 2 5を参照して、 作成されたジャンルリストはコンテンツサーバからォ 一ディオクライアントに送信される ( S 2 4 0 1 , S 1 4 2 2 ) 。 ユーザは、 こ のジャンルリストの中から所望のジャンル （この例ではポップス） を選択する。 オーディォクライアントは、 ユーザの操作に応じて選択されたジャンルの曲リス トをコンテンツサーバに要求する （S 1 4 2 3 ) 。 コンテンツサーバは、 オーデ ィオクライアントからの要求に応じて選択されたジャンルの曲リストをコンテン ッサーバに返信する ( S 2 4 0 2 ) 。 オーディオクライアントは、 コンテンツサ ーバから曲リストを受信し、 図 2 9に示すようにメモリ 3 2に格納する （S 1 4 2 4 ) 。

上記ジャンルリストと同様に、 曲リストもコンテンツサーバに予め用意されて いるのではなく、 図 2 7に示したコンテンツ情報データベースに基づいて作成さ れる。 すなわち、 コンテンツサーバは、 オーディオクライアントから曲リストを 要求されるたびに、 コンテンツ情報データベースに基づいて曲リストを作成する。 以下、 曲リストの作成方法を図 3 0を参照して説明する。

まず、 コンテンツサーバは、 図 2 7に示したコンテンツ情報データベースにお けるレコードの番号を示すインデックスを 0に初期化する （S 2 4 0 2 1 ) 。 続いて、 コンテンツサーバは、 インデックスが示すレコードのジャンルを選択 されたジャンル (この例ではポップス) と比較し、 それらが一致するか否かを判 別する （S 2 4 0 2 2 ) 。 一致する場合、 コンテンツサーバはそのレコードの曲 名、 アーティスト名、 アルバム名などを曲リストに追加し （S 2 4 0 2 3 ) 、 そ の後、 インデックスをインクリメントする ( S 2 4 0 2 4 ) 。 一方、 一致しない 場合、 コンテンツサーバは、 ステップ S 2 4 0 2 3をスキップし、 直ちにインデ ックスをインクリメントする ( S 2 4 0 2 4 ) 。

続いて、 コンテンツサーバは、 インデックスが示すレコードの番号が全レコー ド数 nよりも小さいか否かを判別し （S 2 4 0 2 5 ) 、 小さい場合はステップ S 2 4 0 2 2に戻り、 一方、 小さくない場合は曲リストの作成を完了する。

上記の処理により、 コンテンツサーバは、 選択されたジャンルの曲だけをコン テンッ情報データベースからピックアップし、 曲リストを作成する。 このように、 曲リストは予めデータベース化されているのではなく、 オーディオクライアント からの要求のたびに一時的に作成されるので、 曲リストを常に格納しておくため のメモリ領域は不要である。

なお、 曲リストを作成する場合には、 該当する全ての曲をピックアップするの ではなく、 再生不可能なデータフォーマツトの曲についてはピックアップしない ようにしてもよい。 また、 オーディオクライアントからの要求のたびに曲リスト を作成するのではなく、 一且作成した曲リストはキヤッシュしておくようにして もよレ、。 この場合、 曲リストを格納しておくためのメモリ領域が必要になるが、 コンテンツサーバはオーディオクライアントからの要求に応じて直ちに曲リスト を返信することができる。

上記ジャンルリストと同様に、 曲リストも全部が一度に送信されるのではなく、 少しずつ順に送信される。 すなわち、 曲リス トの要求 （S 1 4 2 3 , S 1 4 2 5 ) 、 曲リストの返信 ( S 2 4 0 2 , S 2 4 0 3 ) 及ぴ曲リストの受信 （ S 1 4 2 4， S 1 4 2 6 ) の動作は繰り返し行われる。 以下、 この詳細を説明する。 オーディオクライアントは、 図 3 1に示すようなリスト要求コマンドをコンテ ンッサーバに送信する ( S 1 4 2 3 ) 。 Vスト要求コマンドは、 オーディオクラ イアントがコンテンツサーバにリストを要求するコマンドであり、 この例では、 取得開始ィンデッタス、 取得個数及ぴリスト構築キーを含む。 取得開始ィンデッ クスは、 選択されたジャンルリストに収録されている曲のうち、 オーディオクラ イアントが取得しょうとする先頭の曲を示すインデックスである。 取得個数は、 オーディオクライアントが取得しょうとする曲の数である。 リスト構築キーは、 詳細は後述するが、 コンテンツ情報データベースから曲を抽出するときに注目す るカテゴリを示すフィルタの種類と、 そのカテゴリに分類される具体的なキーヮ ードとから構成される。 特に限定されないが、 この例では、 取得開始インデック ス = 0、 取得個数 = 5 0に設定され、 さらにリスト構築キーは 「ジャンル （フィ ルタの種類） =ポップス （キーワード） 」 に設定されている。

コンテンツサーバは、 このリスト要求コマンドに応答して、 図 32に示すよう な検索データをオーディオクライアントに返信する （S 2402) 。 検索データ は、 曲リストの一部のほか、 有効個数及び残り個数を含む。 有効個数は、 コンテ ンッサーバがオーディオクライアントに実際に返信した曲の数である。 残り個数 は、 コンテンツサーバがオーディオクライアントに返信した曲リストよりも後に 残っている曲の数である。 ここでは、 取得開始インデックス =0、 取得個数 =5 0のリスト要求コマンドに応答するのであるから、 コンテンツサーバは、 作成し た曲リストのうち最初の曲から 50曲目までをオーディオクライアントに返信す る （S 1432) 。 曲リストの全曲数 =1 10とすると、 有効個数 =50、 残り 個数 =60 (=110— 50) に設定される。

続いて、 オーディオクライアントは、 コンテンツサーバに未だ 60曲が残って いるから、 再びリス ト要求コマンドをコンテンツサーバに送信する （S 142 5) 。 ここでは、 取得開始インデックス =51、 取得個数 =50に設定される。 コンテンツサーバは、 このリスト要求コマンドに応答して、 再び検索データを オーディオクライアントに返信する （S 2403) 。 ここでは、 有効個数 =50、 残り個数 =10 (=1 10- (5ひ +50) ) に設定される。 すなわち、 コンテ ンッサーバは、 再ぴ曲リストを 50曲分だけオーディオクライアントに返信する (S 2403) 。 オーディオクライアントは、 この曲リストを受信し、 メモリ 3 2に格納する （S 1426) 。

なお、 上記の例では、 曲リストの全曲数 =110、 取得個数 =50であるから、 曲リストの一部である 50曲が返信されているが、 曲リストの全曲数が取得個数 よりも少ない場合、 たとえば曲リストの全曲数 = 40、 取得個数 = 50であれば、 曲リストの全部である 40曲が返信されることになる。

また、 上記の例では、 取得開始インデックス =0であるから、 曲リストの最初 から曲が返信されているが、 たとえば取得開始インデックス = 10とすれば、 曲 リストの 11曲目から曲が返信されることになる。 また、 この場合、 曲リストの 全曲数- 110であり、 最初のリスト要求コマンドが取得開始ィンデッタス = 1 0、 取得個数 =50であれば、 コンテンツサーバは、 有効個数 =50、 残り個数 = 5 0 (= 1 1 0— 1 0— 5 0 ) の検索データを返信することになる。

メモリ 3 2に格納可能な曲数が曲リストの全曲数よりも多ければ、 オーディオ クライアントは曲リス トの全部を一度に格納することができる。 し力 し、 メモリ 3 2の容量はコンテンツサーバに比べると非常に小さいため、 通常、 オーディオ クライアントは曲リストの一部しかメモリ 3 2に格納することができない。 上記実施の形態によれば、 オーディォクライアントはコンテンツサーバから曲 リストを分割してダウンロードしているため、 オーディオクライアントのメモリ 3 2に少なくとも 5 0曲分の領域を用意すれば、 1 1 0曲全ての曲リストをダウ ンロードすることができる。 そのため、 メモリ 3 2の容量を小さく抑えることが できる。

たとえば図 3 3 Aに示すように、 オーディオクライアントがメモリ 3 2に 5 0 曲分の曲リストを格納した後、 ユーザが 5 1曲目以降の取得を希望した場合、 図 3 3 Bに示すように、 オーディオクライアントは後半の曲リストをメモリ 3 2の 前半に移動させる。 そして、 図 3 3 Cに示すように、 オーディオクライアントは メモリ 3 2の後半に 5 1曲目から 2 5曲分の曲リストを格納する。

オーディオクライアントは、 上記動作を繰り返して曲リストの全部を受信する 力 又はメモリ 3 2に格納可能な曲数だけ受信する。

図 2 5に示した例では、 ジャンルを選択した後、 直ちにそのジャンルから曲を 選択するようにしているが、 図 3 4に示したように、 ジャンルを選択し、 引き続 きそのジャンルからアルバムを選択した後、 そのアルバムから曲を選択するよう にしてもよい。

この場合、 オーディオクライアントは、 ユーザの操作に応じて選択されたジャ ンルのアルバムリストをコンテンツサーバに要求する ( S 1 4 2 7 ) 。 コンテン ッサーバは、 オーディオクライアントからの要求に応じて選択されたジャンルの アルバムリストをコンテンツサーバに返信する （S 2 4 0 4 ) 。 オーディオクラ イアントは、 コンテンツサーバからアルバムリストを受信し、 メモリ 3 2に格納 する （S 1 4 2 8 ) 。

続いて、 オーディオクライアントは、 ユーザの操作に応じて選択されたァルバ ムの曲リストをコンテンツサーバに要求する （S 1 4 2 9 ) 。 コンテンツサーバ は、 オーディオクライアントからの要求に応じて選択されたアルバムの曲リスト をコンテンツサーバに返信する （S 2 4 0 5 ) 。

1 . 2 . 2 . 2 . 2 . 曲の指定

図 3 5及び図 3 6を参照して、 オーディオクライアントは指定された曲の情報 をコンテンツサーバに要求し （S 1 5 0 1 ) 、 コンテンツサーバはこの要求に応 じて指定された曲の情報をオーディオクライアントに返信し （S 2 5 0 1 ) 、 ォ 一ディオクライアントはこれを受信する （S 1 5 0 2 ) 。

具体的には、 オーディオクライアントは、 図 3 7に示すような曲情報要求コマ ンドを送信する （S 1 5 0 1 ) 。 この曲情報要求コマンドは、 指定された曲のフ アイル名を含む。 コンテンツサーバは、 この曲情報要求コマンドに応答して、 図 3 8に示すような曲情報を返信する （S 2 5 0 1 ) 。 この曲情報は、 指定された 曲のデータオフセット及ぴデータサイズを含む。 M P 3等の音楽データは一般に、 コンテンツ情報の前にヘッダ情報を有する。 データオフセットは、 このヘッダ情 報をスキップし、 曲の先頭アドレスを指定するためのものである。 オフセットを コンテンツサーバが解析することにより、 オーディオクライアントはオフセット を解析する必要がなくなる。 一般的に、 コンテンツサーバはオーディオクライァ ントよりも処理能力が高いので、 システム全体として処理を高速化することがで きる。 データサイズは、 曲の終了時期を確認するためのものである。

続いて、 オーディオクライアントは指定された曲の再生準備をコンテンツサー バに要求し （S 1 5 0 3 ) 、 コンテンツサーバはこの要求に応じて指定された曲 のファイルをオープンし、 その結果をオーディオクライアントに返信し ( S 2 5 0 2 ) 、 オーディオクライアントはこれを受信する （S 1 5 0 4 ) 。

具体的には、 オーディオクライアントは、 図 3 9に示すような曲再生準備コマ ンドを送信する （S 1 5 0 3 ) 。 この曲再生準備コマンドは、 指定された曲のフ アイル名及び後述するリスト構築キーを含む。 コンテンツサーバは、 この曲再生 準備コマンドに応答してファイルをオープンし、 図 4 0に示すようなエラーコー ドを返信する （S 2 5 0 2 ) 。 このエラーコードは、 ファイルが存在しないなど、 ファイル転送の準備ができない場合はエラーありとなり、 準備ができる場合はェ ラーなしとなる。 クライアントは送信されたエラーコードを確認し、 エラーがあ れば所定のエラー処理を行う （S 1504) 。

1. 2. 2. 2. 3. 曲の再生

続いて、 オーディオクライアントは指定された曲の音楽データのうち指定範囲 の音楽データの転送をコンテンツサーバに要求し （S 1601) 、 コンテンツサ ーバはこの要求に応じて指定範囲の音楽データをオーディオクライアントに返信 し （S 2601) 、 オーディオクライアントはこれを受信し、 メモリ 32に格納 する （S 1602) 。

具体的には、 オーディオクライアントは、 図 41に示すような曲データ転送要 求コマンドを送信する （S 1601) 。 この曲データ転送要求コマンドは、 転送 すべき音楽データの取得開始アドレス及ぴ取得データ長を含む。 コンテンツサー パは、 図 42に示すように、 取得開始アドレスにより指定された先頭アドレスか らその取得データ長分だけ音楽データを返信する （S 2601) 。 1回に送信さ れるデータのサイズは、 特に限定されないが、 好ましくは 1 K〜32Kバイトで あり、 さらに好ましくは 4Κ〜16Κバイトである。 コンテンツサーバは一度に 返信するデータ量が小さいほど負荷を小さくすることができ、 クライアントは一 度に受信するデータ量が大きいほど処理を早くすることができるが、 1Κ〜32 Κバイト （特に、 4Κ〜 16 Κパイト) がコンテンツサーバとクライアントとの 両方にとって、 最適な値となるからである。 このようなデータのサイズはオーデ ィォクライアント側で予め設定される。

上記取得開始ァドレスを転送した取得データ長分だけ順次加算していき、 上記 動作を繰り返すことにより （S 1605、 S 2603、 S 1606、 S 1607、 S 2604、 S 1608) 、 音楽データを指定範囲ごとに順次転送することがで きる。

このように、 オーディオクライアントは指定した範囲の音楽データをコンテン ッサーバから取得することができるので、 後述するように、 曲を途中から再生で きるほか、 早送り再生、 早戻し再生、 スロー再生など、 ユーザの操作に応じて音 楽を自在に再生することができる。

メモリ 32は、 複数 （図 43に示した例では 8つ） のバッファを含む。 図 44 に示すように、 オーディオクライアントは曲データ転送要求コマンドで曲の先頭 から 1バッファ分の音楽データを取得して格納する。 図 45に示すように、 ォー ディオクライアントは同様にしてバッファが全て埋まるまで音楽データを取得し て格納する。

ステップ S 1601〜S 1608の間で上記のようにバッファが全て埋まった ら、 オーディオクライアントは、 図 46に示すように先頭バッファから音楽デー タを音声処理部 34に出力し始める。

オーディオクライアントは、 上記のように音楽データを出力して音楽の再生を 開始したら、 再生ステータスをコンテンツサーバに送信する （S 1603) 。 コ ンテンッサーバはこれを受信し、 エラーコードをオーディォクライアントに返信 する （S 2602) 。 オーディオクライアントはこのエラーコードを確認し、 ェ ラーがあれば所定のエラー処理を行う （S 1604) 。

上記のように音楽データを転送しながら音楽を再生していると、 やがて図 47 に示すように 1バッファ分の空きが生じる。 バッファに空きが生じると （S 16 09) 、 オーディオクライアント及びコンテンツサーバは再び上記転送動作を行 う （S 1610、 S 2605、 S 1611) 。 その結果、 図 48に示すようにバ ッファの空きが埋まる。 オーディオクライアント及ぴコンテンツサーバは、 バッ ファに空きが生じるたびに上記転送動作を繰り返し行う （S 1612〜S 161 6、 S 2606, S 2607) 。

なお、 上記では、 バッファが音楽データで全て埋まってから音楽データを出力 し始めているが、 全て埋まる前に出力し始めるようにしてもよい。

続いて、 オーディオクライアントは、 ステップ S 1502で取得したデータサ ィズに基づいて、 指定された曲の音楽データを全て受信したか否かを判別する (S 161 7) 。 全て受信した場合、 オーディオクライアントは、 受信した音楽 データに基づいて指定された曲を再生し終えた力否かを判別し （S 16 1 71) 、 再生し終えた場合は停止又は完了ステータスをコンテンツサーバに送信する (S 16 18) 。 ユーザがオーディオクライアントを操作し、 それに応じてオーディ オクライアントが指定された曲を再生しその曲を再生し終えた場合、 又はユーザ がオーディオクライアントを操作し、 それに応じてオーディオクライアントが曲 の再生を途中で停止した場合、 オーディオクライアントは停止ステータスを送信 する。 一方、 ユーザがコントローラを操作し、 それに応じてオーディオクライア ントがコントローラから指定された曲を再生しその曲を再生し終えた場合、 ォー ディオクライアントは完了ステータスを送信する。 このように停止ステータスと 完了ステータスとを区別する理由は後述する。

コンテンツサーバはこのステータスを受信し、 エラーコードをオーディオクラ イアントに返信する （S 2 6 0 8 ) 。 オーディオクライアントはこのエラーコー ドを確認し、 エラーがあれば所定のエラー処理を行う （S 1 6 1 9 ) 。

以上のように、 音楽データを分割し、 コンテンツサーバからオーディオクライ アントに断続的に転送しているため、 バッファ容量が少なくても適切に音楽を再 生することができる。

上記では音楽データをパイト単位で転送しているが、 MP 3の音楽データを転 送する場合はフレーム単位で転送するのが好ましい。 時間表示、 早送り又は早戻 し再生などの特殊再生 （後述） で有利な点が多いからである。 したがって、 MP 3の音楽データの場合、 オーディオクライアントはフレーム単位で音楽データを 要求するものとする。 この要求に応答して、 コンテンツサーバは指定されたファ ィルの中から MP 3のフレームヘッダを検索し、 フレームの先頭から転送を行う。 このヘッダの中にはデータ長を算出することができるパラメータが含まれている ので、 一度ヘッダを発見すれば、 以降、 フレームの先頭を発見するのは困難では ない。

1 . 2 . 2 . 3 . 特殊再生

また、 早送り、 早戻し、 一時停止、 スローなど、 特殊再生を可能とするために、 音楽データの転送要求、 返信及び取得という一連の処理の前に、 オーディオクラ イアントは以下のような処理を行う。

1 . 2 . 2 . 3 . 1 . 早送り再生

早送り再生の場合、 図 4 9を参照して、 オーディオクライアントは、 キー入力 を監視し （S 1 6 2 0 ) 、 早送り再生キーが押された場合はスキップ量を 0より も大きい値に設定し （S 1 6 2 1 ) 、 そうでない場合はスキップ量を 0に設定す る （S 1 6 2 2 ) 。

バッファに空きが生じると （S 1 6 0 9 ) 、 オーディオクライアントは、 音楽 データの取得開始アドレスを次式により計算する （S 1 6 2 4 ) 。

取得開始ァドレス =前回の取得開始ァドレス +取得データ長 +スキップ量 ステップ S 1 6 2 0で早送り再生キーが押されなかった場合、 ステップ S 1 6 2 2でスキップ量は 0に設定されるので、 取得開始アドレスは取得データ長ずつ 増加する。 この場合、 オーディオクライアントは音楽データを連続的に取得する ので、 通常の再生を行う。 一方、 ステップ S 1 6 2 0で早送り再生キーが押され た場合、 ステップ S 1 6 2 1でスキップ量は 0よりも大きい値に設定されるので、 オーディオクライアントは音楽データをそのスキップ量だけ飛んで取得する。 そ の結果、 オーディオクライアントは早送り再生を行う。 この例では、 スキップ量 が取得データ長と同じに設定されているから、 2倍速の早送り再生を行う。 また、 たとえばスキップ量を取得データ長の 2倍とすることにより、 3倍速の再生を行 うことができる。

1 . 2 . 2 . 3 . 2 . 早戻し再生

早戻し再生の場合、 オーディオクライアントは、 上記ステップ S 1 6 2 0に代 えて早戻し再生キーが押されているかを判別し、 上記ステップ S 1 6 2 1に代え てスキップ量を 0よりも小さく、 かつ絶対値が前回の取得データ長よりも大きい 値に設定する。 スキップ量の絶対値が前回の取得データ長よりも小さいと、 音楽 データの取得範囲が重複するからである。 毎回の取得データ長が一定であれば、 絶対値を取得データ長の 2倍にすれば、 通常再生と同じ速度で戻し再生を行うこ とができる。

また、 オーディオクライアントは、 ステップ S 1 6 2 4で計算した取得開始ァ ドレスが音楽データの存在する範囲内か否かを判別する （S 1 6 2 5 ) 。 範囲内 の場合、 オーディオクライアントは次のステップ S 1 6 1 0に進むが、 範囲外の 場合、 オーディオクライアントは再生を停止する。 通常再生の場合は音楽データ の終わりを検知しているので、 このような終了条件を入れる必要はないが、 特に 早戻し再生の場合は音楽データの始まりを検知する必要があるので、 このような 終了条件を入れている。 ただし、 このような終了条件を入れずに、 次の曲のファ ィルをオープンして早送り再生を行ったり、 前の曲のファイルをオープンして早 戻し再生を行うようにしてもよレ、。 なお、 MP 3の音楽データの場合は、 前述したように、 フレームヘッダを読み 取れば次のフレームヘッダの位置をほぼ確定することができる。 したがって、 あ る一定分のフレームをスキップし、 その後の数フレームのデータを再生し、 再び フレームをスキップする、 という動作を繰り返すことにより早送り再生を実現す ることができる。

1. 2. 2. 3. 3. —時停止

一時停止の場合、 図 50を参照して、 オーディオクライアントはキー入力を監 視し （S 1626， S 1628) 、 一時停止キーが押された場合は動作ステータ スを一時停止に設定し （S 1627) 、 再生キーが押された場合は動作ステータ スを再生に設定する （S 1629) 。

バッファに空きが生じると （S 1609) 、 オーディオクライアントは動作ス テータスが一時停止か否かを判定する （S 1631) 。 一時停止の場合、 オーデ ィォクライアントはステップ S 1626に戻って次の音楽データの転送を開始し ない。 一方、 一時停止でない場合、 すなわち再生キーが押されて一時停止が解除 され、 動作ステータスが再生に変化した場合、 オーディオクライアントはステツ プ S 1610に進んで次の音楽データの転送を開始する。

また、 動作ステータスが一時停止になった場合、 オーディオクライアントはパ ッファの読出動作を停止する。 バッファには、 以前に転送された音楽データが残 つているからである。

1. 2. 2. 3. 4. スロー再生

音楽ではなく、 動画の場合はスロー再生を行う必要がある。 通常、 動画フアイ ルは MP EG— 2のように圧縮形式であるから、 オーディオクライアントはこれ を再生するためにデコーダを備える。 スロー再生の場合、 デコーダにスロー再生 を指示するコマンドが与えられると、 バッファに蓄積されている映像データの減 少速度が遅くなる。 仮に通常再生の 30%の速度でスロー再生を行うのであれば、 デコーダがパッファから読み出す映像データの単位時間当たりの量は 30 %にな る。 そのため、 上記ステップ S 1609でオーディオクライアントがバッファに 空きが生じるのを待つ時間が長くなり、 これによりスロー再生を実現することが できる。 1. 2. 3. コントローラの動作

1. 2. 3. 1. コンテンツサーバとの接続

コントローラ A kもオーディオクライアント C j とほぼ同様に、 まずコンテン ッサーバ S iとの接続を確立する。

図 51を参照して、 コントローラ Akに電源が投入されると、 コントローラ A kは、 コンテンツサーバ S iのコマンドポートに接続する （S 3001) 。 コン トローラ Akは、 このコマンドポートを通じてクライアントインデックス要求コ マンドを発行する （S 3002) 。 コンテンツサーバ S iはこのコマンドに応答 してクライアントインデックスをコントローラ A kに返信し、 コントローラ Ak はその取得したクライアントインデックスを保存する （S 3003)。

続いて、 コントローラ Akは、 コンテンツサーバ S iのプッシュポートに接続 する （S 3004) 。 コントローラ Akは、 このプッシュポートを通じてクライ アントインデックス通知コマンドを発行し、 ステップ S 3003で保存したクラ イアントインデックスをコンテンツサーバに送信する (S 3005) 。 これによ り、 プッシュポートが開通する （S 3006) 。

続いて、 コントローラ Akは、 クライアントタイプをコマンドポートを通じて コンテンツサーバ S iに通知する （S 3007) 。 ここでは、 上記オーディオク ライアント C j と異なり、 コントローラ Akはクライアントタイプとして自身が コントローラであることを通知する。 コンテンツサーバ S iは、 このクライアン トタイプによりオーディオクライアント C j とコントローラ Akとを区別するこ とができる。

続いて、 コントローラ Akは、 オーディオクライアント C jのクライアント情 報をコンテンツサーバ S iから取得し （S 3008) 、 その情報に含まれるステ 一タスなどをモニタ上に表示する。

そして、 コントローラ Akは、 クライアントタイプ及ぴ取得したクライアント インデックスに基づいて、 コンテンツサーバ S iに接続されているオーディオク ライアント C jの監視ハンドル及ぴ制御ハンドルをコンテンッサーバ S iに要求 して取得する （S 3009)。

上記接続手順がオーディオクライアント C j と相違する点は、 コントローラ A kは、 自身がコントローラであることを示すクライアントタイプをコンテンツサ ーパ S iに通知する点である。 また、 もう 1つの相違点は、 コントローラ Akが 監視ハンドル及ぴ制御ハンドルの両方又は一方を取得する点である。 以下、 詳述 する。

1. 2. 3. 1. 1. 監視ハンドル及び制御ハンドルの取得

図 52を参照して、 コントローラ Akは、 コンテンツサーバ S iに接続されて いる全オーディオクライアント C jのリストを表示する (S 30091) 。 コン トローラ A kは、 ユーザの操作に応じてリストの中から監視しようとするオーデ ィォクライアント C j を選択する （S 30092) 。 ユーザの操作に応じて監視 しょうとするオーディオクライアント C j を選択するのは本ネットワークオーデ ィォシステムを最初に起動したときだけとし、 2回目以降は、 最初に選択したォ 一ディオクライアント C jを登録しておき、 その登録されたオーディオクライア ントを自動的に選択するようにするのが好ましい。 .

続いて、 コントローラ A kは、 その選択されたオーディオクライアント C jの クライアントインデックスをコンテンツサーバ S iに送信し、 その監視ハンドル を要求する （S 30093) 。 コンテンツサーバ S iは、 送信元コントローラ A ィオクライアント C jのクラ

0001 ) 、 送信元コント口 ーラ Akに対して監視ハンドルを発行する （S 20002) 。 その結果、 コント ローラ Akは、 選択されたオーディオクライアント C jの監視ハンドルを取得す る （S 30094) 。

続いて、 コントローラ Akは、 ユーザの操作に応じてリストの中から制御しよ うとするオーディオクライアント C jを選択する (S 30095) 。 そして、 コ ントローラ Akは、 その選択されたオーディオクライアント C jのクライアント インデックスをコンテンツサーバ S iに送信し、 その制御ハンドルを要求する (S 30096) 。 コンテンツサーバ S iは、 送信元コントローラ Akのクライ アントインデックスと、 受信したオーディオクライアント C jのクライアントイ ンデッタスとを対応づけて記憶し （S 20003) 、 送信元コントローラ Akに 対して制御ハンドルを発行する （S 20004) 。 その結果、 コントローラ Ak は、 選択されたオーディオクライアント C jの制御ハンドルを取得する （S 3 0 0 9 7 ) o

監視ハンドルは、 コンテンツサーバ S iからコントローラ A kに与えられるォ 一ディオクライアント C j を監視する権限である。 これにより、 オーディオクラ イアン 〗のステータスが変化すると、 変化後の新しいステータスがコンテン ッサーバ S iに通知される。 コンテンツサーバ S iはプッシュポートを通じてォ ーデ、ィォクライアント C jのクライアント情報をコントローラ A kに随時送信し、 これに応じてコントローラ A kはオーディオクライアント C jのクライアント情 報を更新する。

本ネットワーク型オーディオシステムでは、 オーディオクライアント C jの数 が多いほど L AN 1 2に負荷がかかる。 また、 コントローラ A kのコマンドゃォ 一ディオクライアント C jのステータスなどの伝送は L AN 1 2上のトラフィッ クに影響を及ぼす。

図 5 3に示すように、 複数のコントローラ A 1〜A 3が同じ L AN 1 2上に存 在する場合に、 コンテンツサーバ S iはオーディオクライアント C 1〜C 3のク ライアント情報を全てのコントローラ A 1〜A 3に送信するようにすることも可 能であるが、 このようにすると、 ネットワークトラフィック及びコンテンツサー バの負荷が増大する。

そこで図 5 4に示すように、 コントローラ A 1がオーディオクライアント C 1 のみの監視ハンドルを取得し、 コントローラ A 2がオーディオクライアント C 2 のみの監視ハンドルを取得するようにし、 コンテンツサーバ S iは、 オーディオ クライアント C 1のクライアント情報をコントローラ A 1のみに送信し、 オーデ ィォクライアント C 2のクライアント情報をコントローラ A 2のみに送信するよ うにする。

コンテンツサーバ S iは、 オーディオクライアント C jの監視ハンドルを取得 しているコントローラ A kだけにクライアント情報を送信するので、 ネットヮー クトラフィック及ぴコンテンツサーバの負荷が軽減される。 ただし、 コントロー ラ C 3が全てのオーディオクライアント C 1〜C 3の監視ハンドルを取得し、 コ ンテンッサーバ S iが全てのコントローラ A 1〜A 3にクライアント情報を送信 するようにしてもよレ、。

一方、 制御ハンドルは、 コンテンツサーバ S iからコントローラ A kに与えら れるオーディオクライアント C jを制御する権限である。

本ネットワーク型オーディオシステムにおいて、 コントローラ A kが複数存在 する場合、 いずれのコントローラ A kもオーディオクライアント C jを制御でき るようにすると、 あるコントローラ A kからの命令に従ってオーディオクライア ント C jが曲を再生している最中に、 他のコントローラ A kがそのオーディオク ライアント C jに再生の停止を命令したり、 別の曲の再生を命令するおそれがあ る。

そこで、 本システムでは、 オーディオクライアント C jの制御ハンドルを取得 しているコントローラ A kのみがそのオーディオクライアント C jを制御するこ とができ、 オーディオクライアント C jの制御ハンドルを取得していないコント ローラ A kはそのオーディオクライアント C jを制御することができないように する。

コンテンッサーバが制御ハンドルを取得できるコントローラを制限すれば、 ォ 一ディオクライアントとそれを制御できるコントローラの組み合わせを設定する ことができる。 また、 コントローラが制御ハンドル開放コマンドをコンテンツサ ーバに発行することにより、 制御ハンドルを放棄できるようにする。

1 . 2 . 3 . 2 . モニタ （監視） 機能

コントローラ A kは、 上述したように監視ハンドルを取得することにより、 ォ 一ディオクライアント C jを監視できるようになる。

図 5 5を参照して、 コントローラ A kはコンテンツサーバ S iにクライアント 情報を要求し （S 3 1 ) 、 コンテンツサーバ S iはこれに応じてクライアント情 報を返信し （S 2 7 ) 、 コントローラ A kはこれを取得して記憶する （S 3 1 )。 又は、 コンテンツサーバ S iがオーディオクライアント C jからクライアント情 報を受信した場合、 コンテンツサーバ S iはコントローラ A kにプッシュポート にてクライアント情報を送信し、 コントローラ A kはこれを取得して記憶する。 そして、 コントローラ A kは取得したクライアント情報を表示する （S 3 2 ) 。 以下、 このコントローラによるモニタ機能を詳細に説明する。 図 56を参照して、 コンテンツサーバ S iはコントローラ A kからの要求又は オーディオクライアントからのクライアント情報の受信に応じてクライアント情 報を送信する （S 2701) 。 コントローラ Akはこのクライアント情報を受信 すると、 各情報に変更がないかを調べる。 すなわち、 最初にクライアントインデ ックスを確認し （S 3101) 、 どのオーディオクライアント C jのクライアン ト情報かを記憶しておく。 そして、 記憶したオーディオクライアントのプロダク ト I D及ぴファームウェア I Dを確認する （S 3102、 S 3103) 。

具体的には、 プロダクト I Dによってオーディオクライアントの種類を判別し、 ファームウェア I Dによってファームウェアのバージョンを判別する。 もしその オーディオクライアントに適用されているファームウェアのバージョンが古けれ ば、 コントローラ Akはィンターネット上のカスタマ一サービスにアクセスし、 オーディオクライアント C jにファームウェアを配信して自動的に更新する。 フ アームウェア更新の詳細は後述する。

なお、 コントローラ Akは、 受信したクライアント情報を解析してクライアン トタイプを確認し、 オーディオクライアント C jならそれ用の処理に分岐し、 そ れ以外なら無視するようにする。

続いて、 コントローラ Akは、 接続情報に変更がないかをチェックし （S 31 04) 、 変更があればオーディオクライアント C jの接続状態の表示を変更する (S 3105) 。

したがって、 複数のオーディオクライアント C jに電源が入り、 それらがコン テンッサーバ S iに接続されている力否かをコントローラ Akで常に監視するこ とができる。

オーディオクライアント C jが接続されていたら、 コントローラ Akは、 ポリ ユーム値に変更がないかをチェックし （S 3106) 、 変更があればボリューム 値の表示を変更する （S 3107) 。

続いて、 コントローラ Akは、 リスト構築キー （後述する） に変更がないかを チェックし （S 3108) 、 変更があればリスト構築キーを用いてコンテンツサ ーバ S iに曲リストを要求する （S 3109) 。 コンテンツサーバ S iはこの要 求に応じて曲リストを返信し （S 2702) 、 コントローラ Akはこの曲リスト を受信する （S 3 1 1 0) 。

コントローラ Akは、 受信した曲リストをオーディオクライアント C jが再生 中の曲リストとして記憶するとともに、 現在再生中の曲が曲リストの何曲目かを 調べてその番号を記憶する （S 3 1 1 1) 。

続いて、 コントローラ A kは、 再生中の曲に変更がないかをチェックし （S 3

1 1 2) 、 変更があれば曲のデータフォーマツトを確認し （S 3 1 1 3) 、 再生 中の曲名やアーティスト名の表示を変更し （S 31 14) 、 現在再生中の曲が曲 リストの何曲目かを調べてその番号を記憶する （S 3 1 1 5) 。

最後に、 コントローラ A kは、 ステータスに変更がないかをチェックし （S 3 1 1 6) 、 変更があればステータスの表示を変更する （S 3 1 1 7) 。 オーディ オクライアント C jがリモコンにより制御される場合も、 コントローラ Akはそ のステータスを監視して表示する。 オーディオクライアント C jのステータスが 完了ステータスであれば （S 3 1 1 8) 、 コントローラ A kはオーディオクライ アント C jにその次の曲を続けて再生するよう命令する （S 3 1 1 9) 。 連続再 生の詳細は後述する。

以上の処理は、 コントローラが監視ハンドルを取得した全てのオーディオクラ イアントのうちレ、ずれかのクライアント情報が変化するたびに繰り返される。 また、 図示されていないが、 コントローラ A kは、 各オーディオクライアント C jのクライアントタイプを監視する。 また、 コントローラ A kは、 再生可能な データフォーマットを監視し、 再生可能な曲名のみを表示する。

以上のように、 コンテンッサーバがクライアントからクライアント情報を受信 した際に、 プッシュポートにて強制的にコントローラにクライアント情報を送信 することにより、 コントローラ A kはオーディオクライアント C jを常に監視す ることができ、 また、 コンテンツサーバ S iからコントローラ CLには必要最低 限の情報しか送信されない。 そのため、 コントローラ Akにかかる処理の負担が 軽減される。 また、 オーディオクライアント C ]·が複数あっても、 コントローラ A kはクライアントインデックスによりオーディオクライアント C jを区別し、 各クライアント情報をリアルタィムで更新することができる。

1. 2. 3. 3. 制御機能 コントローラ Akは、 上述したように制御ハンドルを取得することにより、 オーディオクライアント C jを制御できるようになる。

図 57を参照して、 コントローラ Akは制御コマンドをコンテンツサーバ S i に送信し （S 33) 、 コンテンツサーバ S iはこれを指定されたオーディオクラ イアント C jに送信する （S 28) 。 オーディオクライアント C jはこの制御コ マンドに従って動作し、 そのステータスを変更し （S 18) 、 その変更したステ 一タスをコンテンツサーバ S iに送信する （S 19) 。 コンテンツサーバ S iは このステータスをコントローラ Akに送信し （S 29) 、 コントローラ Akはこ れに応じて記憶しているクライアント情報のステータスを変更する （S 34) 。

1. 2. 3. 3. 1. 制御コマンド処理

次に、 図 58を参照して、 オーディオクライアント C jがコントローラ A k力、 らコンテンツサーバ S iを通じて受けた制御コマンドに従って行う処理を説明す る。

オーディオクライアント C jは、 プッシュポートに何らかのデータが書き込ま れた場合 （S 3001) 、 そのデータを受信して解析する （S 3002) 。

受信したデータが再生コマンドであれば （S 3003) 、 オーディオクライァ ント C jは指定されたファイル名をコンテンツサーバ S iから取得する （S 30 04) 。 オーディオクライアント C jは、 取得したフアイノレ名から、 曲名、 アル バム、 ジャンルなどを特定する。 そして、 オーディオクライアント C jは曲を指 定しかつその曲の音楽データを転送するようコンテンツサーバ S iに指令する (S 3005) 。 オーディオクライアント C jは転送された音楽データに基づい て再生を行う。

受信したデータが再生停止コマンドであれば （S 3006) 、 オーディオクラ イアント C jは曲データ転送要求コマンドの発行を停止することにより音楽デー タの転送を停止し （S 3007) 、 停止ステータスをコンテンツサーバ S iに送 信する （S 3008) 。 オーディオクライアント C jは、 その他、 ボリューム値 セットコマンド、 ポーズコマンド、 A Vレシーバ制御コマンド、 ファームウェア アップデートコマンドなどに応答して、 所定の処理を行う （S 3009〜S 30 10) 。 1. 2. 3. 3. 2. 再生制御

ここで、 コントローラ A kが再生コマンドに従ってオーディオクライアント C jに所望のアーティストの所望の曲を再生させる動作を説明する。

図 59を参照して、 コントローラ A kはオーディオクライアント C jの接続を 確認し （S 301 1) 、 接続があればオーディオクライアント C jのファームゥ エア I D及ぴプロダクト I Dを確認する （S 3012、 S 3013) 。

続いて、 コントローラ Akは、 クライアントタイプに基づいてオーディオクラ 判別する （S 3014) 。 ここではオーディオクライアント C jであるから、 コ ントローラ A kは所望のアーティストの曲リストを既に取得しているか否かを判 別する （S 301 5) 。 未だ取得していなければ、 コントローラ Akはコンテン ッサーバ S iから所望のアーティストの曲リストを取得する （S 3016) 。 コ ントローラ Akは、 この曲リストを表示装置に表示する。

取得された曲リストの中にユーザが再生を希望する曲があれば （S 3017) 、 コントローラ Akは、 ユーザの入力操作に応じてその曲を選択し、 再生コマンド をコンテンツサーバ S iに送信する （S 3018) 。 この再生コマンドは、 選択 された曲のデータを格納しているファイル名と、 曲を再生させようとするオーデ ィォクライアントのクライアントインデックスとを含む。 一方、 希望する曲がな ければ、 コントローラ Akは再び所望のアーティストの次の曲リストを取得する (S 3016) 。

コンテンツサーバ S iは、 コントローラ A kから送信されたクライアントイン デックスに基づいてオーディオクライアント C jを特定し、 そのオーディオクラ イアント C jに選択された曲のファイル名を送信する （S 28) 。

オーディオクライアント C jは、 コントローラ Akからコンテンツサーバ S i を通じて送信されてきた再生コマンドに応答して所望の曲を再生し、 ステータス を再生ステータスに変更する （S 18) 。 オーディオクライアント C jは再生ス テータスをコンテンツサーバ S iに送信し (S 1 9) 、 コンテンツサーバ S iは その再生ステータスをコントローラ Akに送信する （S 29) 。 コントローラ A kはこれに応じてオーディオクライアント C jのステータスを再生ステータスに 変更する （S 3 4 ) 。

1 . 2 . 3 . 3 . 3 . 再生可能なフォーマットかを識別して再生

曲リストには、 オーディオクライアント C jが再生可能なフォーマツトか否か に関係なく、 全てのフォーマットの曲が含まれる。 そのため、 ユーザが所望の曲 を選択したときにコントローラ A kがコンテンツサーバ S iから取得した曲リス トをそのままユーザに対して表示したとすると、 次のような問題が生じる。 すなわち、 ユーザがオーディオクライアント C jが再生できないフォーマツト の曲を選択した場合でも、 コントローラ A kはユーザが選択した曲の再生をォー ディオクライアント C jに命令するので、 オーディオクライアント C jでは表示 は再生状態になっているのに再生音は出ない。

そこで図 6 0に示すように、 クライアント情報のクライアントタイプに再生可 能なフォーマットに関する情報を追加する。 よって、 クライアントタイプは、 ク ライアントのハードゥエァ構成に関する情報と、 オーディオクライアントが再生 可能なフォーマツトに関する情報とから構成される。

ハードウェア構成に関する情報には、 次のようなものがある。 「オーディオク ライアント（インテリジェントタイプ)」 は、 音楽を再生しかつリモコン信号を受 信できるオーディオクライアントである。 「オーディオクライアント（ノンイン テリジェントタイ.プ）」 は、 音楽を再生できるが、 リモコン信号を受信できない オーディオクライアントである。 「コントローラ」 は、 コンテンツサーバを介し てオーディオクライアントを監視しかつ制御できるクライアントである。 「AV Rクライアント」 は、 E I A— 2 3 2ポートを持ち、 AVレシーバと通信できる クライアントである。 「AV Rコントローラ」 は、 コンテンツサーバを介して A V Rクライアントを制御しかつ監視できるクライアントである。 再生可能なフォ 一マットに関する情報には、 MP 3、 WAV, WMAなどがある。

1つのクライアントのクライアントタイプに、 複数のハードウェア構成に関す る情報が含まれている場合もあり、 また、 複数の再生可能なフォーマットに関す る情報が含まれている場合もある。

次に、 コントローラ A kがユーザに対して曲リストを表示するときの処理手 J頃 を図 6 1を参照して説明する。 まずコントローラ Akは、 曲を再生させようとするオーディオクライアント C jがコンテンツサーバ S iに接続されているか否かを判別する （S 3501) 。 未接続の場合、 オーディオクライアント C jは曲を再生できないので、 曲リスト の全ての曲を再生不可能な曲として表示するか、 又は全ての曲を表示しない （S 3502) 。 したがって、 オーディオクライアント C jが再生不可能な曲をユー ザが選択するのを防止することができる。

一方、 既接続の場合、 以下のステップ S 3505〜S 3507を曲リストの曲 数分繰り返す （S 3503， S 3504, S 3508) 。

すなわち、 コントローラ Akは、 曲リスト中の n番目の曲のフォーマットがォ 一ディオクライアント C jが再生可能なフォーマツトか否かを判別する （S 35 05) 。 再生可能なフォーマットであれば、 コントローラ Akはその曲を再生可 能な曲として表示し （S 3506) 、 再生不可能なフォーマットであれば、 再生 不可能な曲として表示するか、 又は表示しない （S 3507) 。

たとえばオーディオクライアント C 1が MP 3も WAVも再生できる場合、 コ ントローラ Akは、 図 62に示すように、 曲リスト （この例ではプレイリスト） 中の全ての曲を表示する。 し力し、 オーディオクライアント C 2が MP 3は再生 できるが、 WAVは再生できない場合は、 図 63に示すように、 曲リスト中の M P 3の曲は通常通り表示するが、 WAVの曲は淡く表示する。 また、 曲を淡く表 示するのではなく、 全く表示しないようにしてもよい。 したがって、 オーディオ クライアント C 2が再生不可能な WAVの曲をユーザが選択するのを防止するこ とができる。

なお、 オーディオクライアント C jの接続状態やクライアントタイプに変更が あった場合、 コントローラ A kは曲リストを表示し直し、 現在のオーディオクラ イアントのクライアント情報をリアルタイムで表示する。

次に、 ユーザがコントローラ Akを操作してオーディオクライアント C jに曲 を再生させる場合のコントローラの動作を説明する。

図 64を参照して、 ユーザが再生したい曲を選択すると、 コントローラ Akは その選択された曲のフォーマツトがオーディオクライアント C jが再生可能なフ ォーマット力否かを判別する （S 351 1) 。 具体的には、 コントローラ Akは、 その選択された曲のフォーマツトをクライアントタイプ中の再生可能なフォーマ ットと比較する。

再生可能なフォーマットであれば、 コントローラ A kは、 その選択された曲を 再生するようオーディオクライアント C jに命令する （S 3 5 1 2 ) 。 一方、 再 生不可能なフォーマツトであれば、 オーディオクライアント C jはその選択され た曲を再生できない旨をユーザに知らせる （S 3 5 1 3 ) 。

以上のように、 コントローラ A kは、 オーディオクライアント C jが再生でき る曲がユーザにわかるように表示し、 これにより、 オーディオクライアント C j が再生できない曲の再生をユーザが要求しないようにすることができる。

1 . 2 . 3 . 3 . 4 . 連続再生制御

ユーザがオーディオクライアント C jを操作してそのオーディオクライアント C jで曲を再生している場合は、 オーディオクライアント C jは曲リストを取得 しているから、 その曲リスト中の曲を連続して再生することが可能である。 しか し、 オーディオクライアント C jがコントローラ A kにより指示された曲を再生 している場合は、 オーディオクライアント C j 自身は曲リストを取得していない から、 オーディオクライアント C jが曲リスト中の曲を連続して再生するために は、 コントローラ A kがオーディオクライアント C jに次の曲を指示する必要が ある。

また、 ネットワーク上にコントローラが 1つしか存在しない場合は問題となら ないが、 複数存在する場合は、 オーディオクライアントが正常に連続再生を行う ことができないという問題が生じる。 たとえばオーディオクライアントから再生 の完了を通知されたコンテンッサーバが全てのコントローラに再生の完了を通知 したとすると、 オーディオクライアントは複数のコントローラから連続再生の命 令を受けてしまうからである。 この問題はネットワーク上にコンテンツサーバが 複数存在する場合はさらに複雑になる。 したがって、 ネットワーク型オーディオ システムにおいてコントローラによる連続再生を可能にするためには、 どのコン トローラがクライアントに連続再生を命令するのかを管理する必要がある。 本実施の形態では、 オーディオクライアント C jは、 コントローラ A kからの 命令に従って曲を再生し、 その再生を終了したときは完了ステータスを送信する 力 s、 それ以外のとき、 たとえばユーザの操作に応じてオーディオクライアント C jが自ら曲を再生し、 その再生を終了したとき、 又はユーザの操作に応じてォー ディオクライアント C jが曲の再生を途中で停止したときなどは、 完了ステータ スとは異なる停止ステータスを送信する。 コントローラは、 完了ステータスを受 信した場合に、 連続再生処理すべきと判断し、 曲リストの中から前に選択した曲 の次の曲を選択し、 オーディオクライアントに次の曲を再生するよう命令する。 また、 コントローラは、 停止ステータスを受信した場合には、 オーディオクライ アントに次の曲を再生するよう命令しない。 以上のように、 オーディオクライン トが状況に応じて完了ステータスと停止ステータスとを区別して送信することに より、 コントローラは受信したステータスに基づいて、 オーディオクライアント に次の曲の再生を命令すベきか否かを判断することができる。

したがって、 オーディオクライアント C jがユーザの操作に応じて曲の再生を 途中で停止した場合又はオーディオクライアント C jが自ら曲を選択し、 その再 生を終了した場合には、 停止ステータスをコンテンツサーバに送信するので、 コ ントローラが誤ってオーディオクライアントに次の曲を再生するよう命令するこ とを防止できる。

さらにコントローラが複数ある場合には、 オーディオクライアントから完了ス テータスを受信したコンテンツサーバは、 各コントローラに対して、 完了ステー タスと停止ステータスとを区別して送信する。 すなわち、 図 6 5を参照して、 コ ントローラ A 1がオーディオクライアント C 1に再生を命令する場合、 コント口 ーラ A 1はまずコンテンツサーバ S iにオーディオクライアント C 1に対する再 生コマンドを送信する。 コンテンツサーバ S iはコントローラ A 1から再生コマ ンドを受信し、 これをオーディオクライアント C 1に送信する。 オーディオクラ イアント C 1はコンテンツサーバ S iから再生コマンドを受信し、 曲の再生を開 始する。

図 6 6及び図 6 7を参照して、 オーディオクライアント C 1が曲の再生を終了 すると、 完了ステータスをコンテンツサーバに送信し ( S 1 9 0 1 ) 、 コンテン ッサーバ S iはこれを受信する （S 1 9 0 2 ) 。 続いて、 コンテンツサーバ S i は、 以下のステップ S 2 9 0 3〜S 2 9 0 6をクライアント数だけ繰り返す （S 2 9 0 2 , S 2 9 0 7 ) 。

コンテンツサーバ S iは、 クライアントインデックス nに基づいて n番目のク ライアントがオーディオクライアント C 1の監視ハンドルを取得しているコント ローラか否かを判別する （S 2 9 0 3 ) 。

監視ハンドルを取得しているコントローラの場合、 コンテンツサーバ S iは、 n番目のクライアント （コントローラ） がオーディオクライアント C 1に再生を 命令したコントローラ A 1か否かを判別する （S 2 9 0 4 ) 。

オーディオクライアント C 1に再生を命令したコントローラ A 1の場合、 コン テンッサーバ S iは、 オーディオクライアント C 1から受信した完了ステータス をコントローラ A 1に送信し （S 2 9 0 5 ) 、 コントローラ A 1はこれを受信す る （S 3 4 0 1 ) 。 一方、 オーディオクライアント C 1に再生を命令したコント ローラ A 1以外のコントローラ A 2の場合、 コンテンツサーバ S iは、 オーディ オクライアント C 1から受信した完了ステータスに代えて、 停止ステータスをコ ントローラ A 2に送信し （S 2 9 0 6 ) 、 コントローラ A 2はこれを受信する ( S 3 4 0 2 ) 。

図 6 8を参照して、 完了ステータスを受信したコントローラ A 1は、 曲リスト の中から前に選択した曲の次の曲を選択し、 その曲をオーディオクライアント C 1に再生させるための再生コマンドをコンテンツサーバ S iに送信する （S 3 4 0 3 ) 。 コンテンツサーバ S iはこれを受信し、 オーディオクライアント C 1に 送信する。 オーディオクライアント C 1は、 コンテンツサーバ S iから送信され た再生コマンドに従って次の曲を再生する。

一方、 停止ステータスを受信したコントローラ A 2は、 オーディオクライアン ト C 1は停止状態にあると判断し、 コントローラ A 1のような連続再生処理を行 わない。

オーディオクライアント C jは、 ステータスが再生になると再生ステータスを コンテンツサーバ S iに送信し、 ステータスが一時停止になるとポ ズステータ スをコンテンツサーバ S iに送信し、 自らが指定した曲の再生が終了すると停止 ステータスをコンテンツサーバ S iに送信するが、 上述したように、 コントロー ラ A kが指定した曲の再生が終了すると完了ステータスをコンテンッサーバ S ί に送信する。

以上のように、 オーディオクライアント C jが曲の再生を終了したときにコン テンッサーバ S iがコントローラ A kに送信するステータスを停止ステータスと 完了ステータスとに区別することにより、 コントローラ A kは自ら再生を命令し たオーディオクライアント C jが曲の再生を終了したのか否かを判断することが できる。 その結果、 コントローラ A kはオーディオクライアント C jに連続再生 を命令する必要があるのか、 オーディオクライアント C jの停止ステータスを表 示するだけでいいのかを判断することができる。

なお、 オーディオクライアント C jが曲の再生を終了したとき、 専用リモコン からの命令に従って曲を再生していた場合と、 監視ハンドル及び制御ハンドルの 両方を取得しているコントローラ A kからの命令に従って曲を再生していた場合 とで、 コンテンツサーバ S iに通知するステータスを区別するようにしてもよい。 制御ハンドルしか取得していない専用リモコンはコンテンツサーバ S iからステ 一タスを受信することができないから、 連続再生処理を行うことができないから である。

1 . 2 . 3. 3 . 5 . リスト構築キーを用いた連続再生制御

コントローラ A kは、 コンテンツサーバ S iからさまざまな曲リストを取得し てその中から曲を選択し、 その曲をオーディオクライアント C jに再生させる。 そして、 コントローラ A kは、 オーディオクライアント C jのステータスを監視 し、 オーディオクライアント C jが選択された曲の再生を終了すると、 取得して いる曲リストの中から次の曲を選択し、 その曲をオーディオクライアント C jに 再生させる。 コントローラ A kはこのようにしてオーディオクライアント C jに 連続的に曲を再生させているが、 次の曲の再生を命令するためには曲リストを記 憶しておく必要がある。 そのため、 曲の再生を命令しているコントローラ A kの 電源は曲の再生中に切ることができない。

そこで、 オーディオクライアント C jに再生を命令したコントローラ A kの電 源を途中で切っても、 コントローラ A kがオーディオクライアント C jに連続再 生を命令できるように、 以下のような方法を採用する。

ユーザがコンテンツ情報データベースの中から再生したい曲を選択するときに は、 あるアーティストの曲リストから選択したり、 あるジャンルの曲リストから 選択するなど、 さまざまな曲リストを利用する。 そこで、 コンテンツ情報データ ベースから一意に曲リストを作成することができるように、 リスト構築キーを定 義する。 そして、 このリスト構築キーを、 オーディオクライアント C jが再生中 の曲リストを特定するための情報としてクライアント情報に付加する。

図 69を参照して、 リスト構築キーは 「フィルタの種類」 と 「キーワード」 と から構成される。 フィルタの種類は、 コンテンツ情報データベース中のどのカテ ゴリに注目して曲リストを作成するかを指定するもので、 図 70に示すようなも のがある。 フィルタの種類が " T I TLE二" 、 "GENRE-" 、 "ART I ST=" 、 "ALBUM=" 、 又は "F I LENAME-" であれば、 コンテン ッ情報データベースの中から、 曲名、 ジャンル名、 アーティスト名、 アルバム名、 又はフアイノレ名がキーワードと一致する曲を探し出して曲リストを作成する。 フ ィルタの種類が "PLAYL I ST-" であれば、 プレイリストのファイル名が キーヮードと一致するプレイリストに登録されている曲をコンテンツ情報データ ベースから探し出して曲リストを作成する。

たとえば、 アーティスト名 "X X X X" の曲リストの場合、 フィルタの種類は "ART I ST = " 、 キーワードは " X X X X" となるから、 リスト構築キーは "A T I S T - X X X X " となる。 また、 キーワードとして "氺" （ァスタリ スク）を指定すると、 そのフィルタの種類に対して使用できるキーヮードのリス トが作成される。 たとえばリスト構築キー "ART I ST=*，， から作成される リストは、 コンテンツ情報データベースに登録されている曲のアーティスト名の リストが作成される。

以下にコントローラが指定した曲の再生が終了したオーディオクライアントに 対して、 コントローラが連続再生処理を行う手順について説明する。

図 71を参照して、 コントローラ Akから再生するよう命令されたオーディオ クライアント C jが曲の再生を終了すると、 完了ステータスをコンテンツサーバ S iに送信する。 コンテンツサーバ S iは、 オーディオクライアント C jのステ 一タスが変化したので、 完了ステータス、 再生していた曲のファイル名、 リスト 構築キーなどを含むクライアント情報をコントローラ Akに送信する。 コントローラ Akはクライアント情報を受信すると、 図 56に示したクライア ント情報表示処理を開始する。 この処理は既に説明したので、 ここでは主として リスト構築キーを用いた連続再生制御に関する部分を説明する。

コントローラ Akは、 リスト構築キーに変更がないかチェックし （S 310 8) 、 変更があった場合はリスト構築キーを用いてオーディオクライアント C j が再生中の曲リストをコンテンツサーバ S iから取得する （S 31 10) 。 詳細 には、 受信したリスト構築キーをコンテンツサーバに送信し、 コンテンツサーバ はこのリスト構築キーに基づいてリストを作成し、 コントローラに送信する。 電 源が切られ、 コントローラ A kがオーディオクライアント C jが再生中の曲リス トを記憶していない場合も、 コンテンツサ パと接続した後に取得するリスト構 築キーを用いて再生中の曲リストをコンテンツサーバ S iから取得する。

ここでは、 ステータスが完了ステータスに変化しているから、 コントローラ A kは完了処理を行う （S 31 19) 。 すなわち、 コントローラ Akは、 オーディ オクライアント C jが再生を終了した曲の次の曲を曲リストから選択し、 その選 択した曲を再生するようオーディオクライアント C jに命令する。

図 72を参照して、 完了処理の詳細を説明する。 コントローラ A kは、 図 56 中のステップ S 3111で記憶した再生曲番号 nをインクリメントし （S 311 91) 、 次に再生すべき曲を指定する。 続いて、 コントローラ Akは、 再生曲番 号 nが曲リストの曲数以下力否かを判別する （S 31192) 。 再生曲番号 nが 曲リストの曲数を超えていれば、 コントローラ Akは、 オーディオクライアント C jが曲リストの最後まで再生したと判断して再生曲番号 nを 1に設定し （S 3 1193) 、 次に再生すべき曲を曲リストの最初の曲に戻す。

再生曲番号 nが曲リストの曲数以下であれば、 コントローラ A kは、 n番目の 曲がオーディオクライアント C jで再生可能なフォーマツトか否かをチェックし (S 31194) 、 再生可能なフォーマットであれば、 曲リストの n番目の曲を 再生するようオーディオクライアント C jに命令する （S 31 195) 。 再生不 可能なフォーマツトであれば、 さらに次の曲を再生するために再帰的にこの完了 処理を行う。 要するに、 コントローラ Akは、 オーディオクライアント C jが再 生不可能なフォーマツトの曲を飛ばし、 その次の曲を再生するようオーディオク ライアント C jに命令する。

以上のように、 オーディオクライアント C jに曲を再生するよう命令した後に コントローラ A kの電源を切ると、 コントローラ A kはオーディオクライアント C jに再生を命令したときの曲リストを消失してしまう。 し力 し、 電源を再投入 し、 コンテンツサーバとの接続が完了すると、 図 5 1の S 3 0 0 8にて説明した 通り、 コントローラ A kはコンテンツサーバ S iからオーディオクライアント C jのクライアント情報を取得する。 このクライアント情報にはリスト構築キーが 含まれているから、 コントローラ A kはこのリスト構築キーに基づいてクライア ント C Lが再生中の曲リストを再び取得することができる。 したがって、 コント ローラ A kがオーディオクライアント C jに曲を再生するよう命令した後にその 電源が切られた場合であっても、 オーディオクライアント C jが曲の再生を終了 し、 完了ステータスを送信し、 この完了ステータスをコントローラ A kが受信し たときには、 取得し直した曲リストに従ってその次の曲を再生するようオーディ 才クライアント C jに命じることができる。

なお、 オーディオクライアント C〗の再生動作を停止させるためには、 コント ローラ A kは停止コマンドをコンテンツサーバ S ίを通じてオーディオクライァ ント C jに送信すればよい。 この場合、 停止ステータスがオーディオクライアン ト C jからコンテンツサーバ S iを通じてコントローラ A kに返信される。 また、 オーディオクライアント C j の再生動作を一時停止させるためには、 コントロー ラ A kは一時停止コマンドをコンテンツサーバ S iを通じてオーディオクライァ ント C jに送信すればよい。 この場合、 ポーズステータスがオーディオクライア ント C jからコンテンツサーバ S iを通じてコントローラ A kに返信される。

1 . 2 . 3 . 3 . 6 . 優先順位を付けた連続再生制御

本実施の形態をコンテンツサーバ S 1及びオーディオクライアント C 1に着目 して説明する。 本実施の形態では、 コンテンツサーバ S 1の HD D 1 4にコント ローラ管理テーブルが格納されている。 コントローラ管理テーブルの一例を次の. 表 1に示す。 コントローラ管理テーブルには、 オーディオクライアント C 1を制 御する優先順位と、 コントローラ A 1〜A kに付与されたコントローラインデッ タスとが対応づけて記録される。 表 1 ： コントローラ管理テーブル

本実施の形態では、 コンテンツサーバ S 1〜S i、 オーディオクライアント C 1〜C j及ぴコントローラ A l〜A kには、 図 7 3に示したステップを実行する ためのコンピュータプログラムがそれぞれィンストールされている。 以下、 本実 施の形態によるネットワーク型オーディオシステム 1 0の動作を図 7 3に示した フロー図を参照して説明する。

最初に、 コントローラ A 1がコンテンツサーバ S 1に接続を要求し、 コンテン ッサーバ S 1がこの要求を受け入れると、 コントローラ A 1とコンテンツサーバ S 1との間で接続が確立する （S 3 0 3 0 1 ) 。

コントローラ A 1に続いて、 コントローラ A 2がコンテンツサーバ S 1に接続 を要求し、 コンテンツサーバ S 1がこの要求を受け入れると、 コントローラ A 2 とコンテンツサーバ S 1との間で接続が確立する （S 3 0 4 0 1 ) 。

これに対し、 コンテンツサーバ S 1は、 コントローラ管理テーブルに、 優先順 位 「第 1位」 に対応づけてコントローラ A 1のコントローラインデックスを記録 し、 さらに優先順位 「第 2位」 に対応づけてコントローラ A 2のコントローライ ンデッタスを記録する （S 2 0 1 0 1 ) 。 その結果、 上記表 1に示したコント口 ーラ管理テーブルが得られる。 このコントローラ管理テーブルによれば、 コント ローラ A 1が最優先で連続再生処理の権限を有し、 その次にコントローラ A 2が 連続再生処理の権限を有する。

以下、 コントローラ A 1がコンテンツサーバ S 1経由でオーディオクライアン ト C 1に複数曲の連続再生を命令する場合の動作を説明する。

コントローラ A 1は、 連続再生の対象となる曲リストをコンテンッサーバ S 1 に要求する （S 3 0 3 0 2 ) 。 具体的には、 曲リストを作成するために必要なリ スト構築キーをコンテンツサーバ S 1に送信する。

ユーザは、 コンテンツサーバ S 1の中から再生したい曲を選択するとき、 ある アーティストの曲リストから選択したり、 あるジャンルの曲リストから選択した りするなど、 さまざまな曲リストを利用する。 リスト構築キーは、 このような曲 リストをコンテンツサーバ S 1の中から抽出して一意に作成するための検索キー でる。 リスト構築キーは図 69に示したように、 フィルタの種類及ぴキーワード という 2つのパラメータから構成される。 - - フィルタの種類は、 曲リストに入れるべき曲のカテゴリを指定するもので、 具 体的には図 70に示したとおりである。

コンテンツサーバ S 1は、 コントローラ A 1から送信されたリスト構築キーに 基づいて曲リストを作成し、 コントローラ A1に送信する （S 20102) 。 具 体的には、 フィルタの種類が " T I TLE=，， 、 "GENRE ，， 、 "ART I ST=" 、 "ALBUM-" 、 又は "F I LENAME=" であれば、 曲名、 ジ ヤンル名、 アーティスト名、 アルバム名、 又はファイル名がキーワードと一致す る 1又は 2以上の曲を探し出し、 その曲を列挙した曲リストを作成する。 フィル タの種類が "PLAYL I ST-" であれば、 プレイリストのファイル名がキー ワードと一致するプレイリストに登録されている曲を探し出し、 その曲を列挙し た曲リスト （プレイリスト） を作成する。 また、 コンテンツサーバ S 1は、 ォー ディオクライアント C 1のクライアント情報の 1つとして、 リスト構築キーをク ライアントインデックス （オーディオクライアント C 1の識別情報） に対応づけ て登録する。

コントローラ A 1は、 取得した曲リストの中からユーザの操作に応じて指定さ れた曲の再生をコンテンツサーバ S 1経由でオーディオクライアント C 1に命令 する （S 30303) 。 オーディオクライアント C 1は、 コントローラ A1から の再生命令に応じて、 指定された曲の音楽コンテンツをコンテンツサーバ S 1に 要求する （S 10201) 。 コンテンツサーバ S 1は、 オーディオクライアント C 1から要求された音楽コンテンツをオーディオクライアント C 1に配信する (S 20103) 。 オーディオクライアント C 1は、 コンテンツサーバ S 1から 送信された音楽コンテンツに基づいて曲の再生を開始する （S 10202) 。 オーディオクライアント C 1は指定された曲を最後まで再生し終えると、 その 旨を示す完了ステータスをコンテンツサーバ S 1に送信する （S 1 0 2 0 3 ) 。 コンテンツサーバ S 1はオーディオクライアント C 1から完了ステータスを受信 すると、 図 7 4に示すように、 コントローラ管理テーブル 1 0 4を参照し、 最高 順位のコントローラ A 1に完了ステータスをそのまま転送し、 それよりも下位の コントローラ A 2に完了ステータスと異なる停止ステータスを送信する （S 2 0 1 0 4 ) 。

コントローラ A 1は、 図 7 4に示すように、 曲リストに従って次の曲を連続し て再生するようにコンテンツサーバ S 1経由でオーディオクライアント C 1に命 令する （S 3 0 3 0 4 ) 。 オーディオクライアント C 1は、 コントローラ A 1か らの連続再生命令に応じてその次の曲を再生する。 以後、 オーディオクライアン ト C 1は上記ステップ S 2 0 1以降の動作を繰り返す。 他方、 コントローラ A 2 は、 コンテンツサーバ S 1から停止ステータスを受信しても特に能動的なァクシ ョンを起こさず、 単にオーディオクライアント C 1の状態を監視する。

なお、 コントローラ A l〜A kがコンテンツサーバ S 1から切断されると、 コ ンテンッサーバ S 1はコントローラ管理テープル 1 0 4を更新する。 具体的には、 コンテンツサーバ S 1から切断されたコントローラのコントローラインデックス を削除し、 それよりも下位のコントローラインデックスの優先順位を順次繰り上 げる。 たとえば図 7 5に示すように、 優先順位が最高のコントローラ A 1がコン テンッサーバ S 1から切断されたときは、 その次の優先順位のコントローラ A 2 が繰り上がり、 コントローラ A 1に代わって連続再生処理の権限を獲得する。 また、 上述した例ではコントローラ A 1が最初に再生を命令し、 再ぴ同じコン トローラ A 1が連続再生を命令しているが、 コントローラ A 2が最初に再生を命 令した場合であってもコントローラ A 1の優先順位が最高である限りコントロー ラ A 1が連続再生を命令する。 この場合、 コントローラ A 1はコンテンツサーバ S 1から完了ステータスを受信しても曲リストを有していないので、 コンテンツ サーバ S 1に登録されているオーディオクライアント C 1のリスト構築キーを利 用してコンテンツサーバ S 1力 ら曲リストを取得し、 これに従って次の曲を指定 する。 また、 曲リストに含まれる全ての曲が 1つのコンテンツサーバ S 1に蓄積され ているとは限らず、 複数のコンテンツサーバ S 1， S iに分散して蓄積されてい る場合もある。 この場合、 オーディオクライアント C 1はコンテンツサーバ S 1 の曲を再生した後、 引き続き別のコンテンツサーバ S iの曲を再生する必要があ る。 そのため、 コンテンツサーバ S 1の曲を再生し終えたオーディオクライアン ト C 1はコンテンツサーバ S 1との接続をー且解除し、 コンテンツサーバ S iに 接続し直すというサーバ切換処理を行う。

コンテンツサーバ S iに接続し直したオーディオクライアント C 1は、 コント ローラ A 1からの再生命令に応じて、 指定された曲の音楽コンテンツをコンテン ッサーバ S iに要求し、 コンテンツサーバ S iは要求された音楽コンテンツをォ 一ディオクライアント C 1に配信する。

オーディオクライアント C 1はその曲を再生し終えると、 完了ステータスをコ ンテンッサーバ S iに送信する。 コンテンツサーバ S iは完了ステータスを受信 すると、 その内部にあるコントローラ管理テーブルを参照し、 最高順位のコント ローラに完了ステータスを転送し、 それよりも下位のコントローラに停止ステー タスを送信する。

ここで、 コンテンツサーバ S iにあるコントローラ管理テーブルはコンテンツ サーバ S 1にあるコントローラ管理テーブルと同じであっても異なっていてもよ い。 複数のコンテンツサーバが同じコントローラ管理テーブルを使用するために は、 たとえばあるコンテンツサーバがコントローラ管理テーブルの優先順位を決 定し、 そのコントローラ管理テーブルを他のコンテンツサーバに転送するように すればよい。 一方、 複数のコンテンツサーバが異なるコントローラ管理テーブル を使用するためには、 たとえば各コンテンツサーバが独自にコントローラ管理テ 一ブルの優先順位を決定するようにすればよい。

以上のように本実施の形態によれば、 コンテンツサーバ S 1がオーディオクラ イアント C 1から完了ステータスを受信したとき、 コントローラ管理テーブルを 参照し、 最優先のコントローラ A 1にのみ完了ステータスを送信し、 他のコント ローラ A 2には停止ステータスを送信しているため、 最優先のコントローラ A 1 のみが連続再生を命令し、 他のコントローラ A 2が連続再生を命令することはな い。 したがって、 連続再生命令の競合を排除し、 正常に連続再生処理を実行する ことができる。

上記実施の形態では優先順位はコンテンツサーバ S 1との接続順で決定されて いるが、 これに限定されることなく、 たとえばオーディオクライアント C 1に命 令を出した順で決定されてもよい。 また、 コンテンツサーバは複数ある必要はな く、 少なくとも 1つあればよい。 オーディオクライアントも複数ある必要はなく、 少なくとも 1つあればよい。

1 . 2 . 3 . 3 . 7 . 制御ハンドルを利用した連続再生制御

本実施の形態では、 図 7 6に示したステップを実行するためのコンピュータプ ログラムがコンテンツサーバ S 1〜S i、 オーディオクライアント C 1〜C j及 びコントローラ A l〜A kにそれぞれインストールされている。 本実施の形態も 上記実施の形態と同様に、 複数のコントローラ A l〜A kを備えたネットワーク 型オーディォシステムに適用可能で、 コンテンッサーバ又はオーディオクライア ントは少なくとも 1つあればよい。

上記実施の形態と異なり本実施の形態では、 コントローラ A l〜A kに制御ハ ンドル管理テーブルが格納されている。 制御ハンドル管理テーブルの一例を次の 表 2に示す。 制御ハンドル管理テーブルには、 オーディオクライアント C 1〜C jのクライアントインデックスと、 オーディオクライアント C 1〜C jの制御ハ ンドルを取得しているコントローラ A l〜A kのコントローラインデックスとが 対応づけて記録される。 制御ハンドルは、 オーディオクライアントを制御する権 限を示すものである。 表 2の例では、 オーディオクライアント C 1の制御ハンド ルはコントローラ A 1により取得されているが、 オーディオクライアント C 2及 ぴ C jの制御ハンドルはいずれのコントローラにも取得されていない。

(以下余白） 表 2 ：制御ハンドル管理テーブル

以下、 コンテンツサーバ S l、 オーディオクライアント C 1及びコントローラ

A 1に着目し、 図 7 6に示したフロー図を参照して本実施の形態の動作を説明す る。 なお、 図 7 6では上記第 1の実施の形態で詳述した曲リストの取得ステップ

(図 7 3中の S 3 0 2， S 2 0 1 0 2 ) は割愛されている。

コントローラ A 1は、 コンテンツサーバ S 1との接続又はオーディオクライア ント C 1に再生を命令する前に、 オーディオクライアント C 1を制御するために 必要な制御ハンドルを取得する。 具体的には、 コントローラ A 1は制御ハンドル 管理テーブルを参照し、 オーディオクライアント C 1の制御ハンドルがロックさ れているか否かを判断する （S 3 0 3 1 1 ) 。

オーディオクライアント C 1の制御ハンドルが既に他のコントローラ A 2〜A kのいずれかに取得されている場合、 表 4に示した制御ハンドル管理テーブルに おいて、 オーディオクライアント C 1のクライアントインデックスに対応して当 該コントローラのコントローラインデックスが記録されている。 このように制御 ハンドルが既に取得されている状態を 「制御ハンドルがロックされている」 とい う。 他方、 オーディオクライアント C 1の制御ハンドルが未だ他のコントローラ

A 2 ~A kのいずれにも取得されていない場合、 オーディオクライアント C 1の クライアントインデックスに対応していずれのコントローラインデックスも記録 されていない。 このように制御ハンドルが未だ取得されていない状態を 「制御ハ ンドルがロックされていない （アンロックされている） 」 という。 たとえば表 4 に示した制御ハンドル管理テーブルでは、 オーディオクライアント C 2の制御ハ ンドノレはロックされていない。

オーディオクライアント C 1の制御ハンドルがロックされている場合、 コント ローラ A 1は制御ハンドルの取得に失敗する。 他方、 口ックされていない場合、 コントローラ A 1はコンテンツサーバ S 1に制御ハンドルの取得を要求する （S 30312) 。 この要求に応じて、 コンテンツサーバ S 1はコントローラ A 1に 制御ハンドルの取得を許可する （S 201 1 1) 。 これにより、 コントローラ A 1は制御ハンドルを取得し、 さらにこの制御ハンドルを他のコントローラ A2〜 A kに取得されないようにロックする （S 30313) 。 具体的には、 コント口 ーラ A 1は制御ハンドル管理テーブルを更新し、 これによりオーディオクライァ ント C 1のクライアントインデックスに対応づけてコントローラ A 1のコント口 ーラインデックスを記録する。 コンテンツサーバ S 1は他のコントローラ A2〜 A kの制御ハンドル管理テーブルもこれに同期するよう更新する。

制御ハンドルを取得したコントローラ A1は、 曲リストの中からユーザの操作 に応じて指定された曲の再生をコンテンツサーバ S 1経由でオーディオクライァ ント C1に命令する （S 30314) 。 コンテンツサーバ S 1はこの再生命令を オーディオクライアント C 1に転送する (S 201 12) 。 オーディオクライァ ント C 1はこの再生命令に応じて指定された曲の再生を開始する （S 1021 1) 。

オーディクライアント C1はその曲を最後まで再生し終えると、 図 77に示す ように、 完了ステータスをコンテンツサーバ S 1に送信する （S 10212) 。 コンテンツサーバ S 1はこの完了ステータスを全てのコントローラ Al〜Akに 転送する （S 201 13) 。

コントローラ A 1は、 自身が制御ハンドルを取得しているオーディオクライア ント C 1からの完了ステータスか否かを判断し (S 30315) 、 そうであれば 連続再生処理を実行し （S 30316) 、 そうでなければ完了ステータスを無視 し、 単にオーディオクライアント C 1の状態を監視する。 本例では、 コントロー ラ A 1はオーディオクライアント C 1の制御ハンドルを取得しているから連続再 生処理を実行し （S 30316) 、 曲リス トに従って次の曲の再生を命令する (S 30314) 。 一方、 オーディオクライアント C 1は、 曲を最後まで再生することなく、 曲の 途中で再生を停止した場合、 停止ステータスをコンテンツサーバ S 1に送信する (S 10213) 。 コンテンツサーバ S 1はこの停止ステータスを全てのコント ローラ Al〜Akに転送する （S 20114) 。

コントローラ A1は、 自身が制御ハンドルを取得しているオーディオクライァ ント C 1からの停止ステータスか否かを判断し （S 30317) 、 そうであれば オーディオクライアント C 1の制御ハンドルを解除 （アンロック） し （S 303 18) 、 そうでなければ停止ステータスを無視する。

コントローラ A1は上記のように自身が制御ハンドルを取得しているオーディ オクライアント C 1から停止ステータスを受信した場合のほか、 コンテンツサー バ S 1から切断された場合にもその取得している制御ハンドルを解除する。 ォー ディオクライアント C 1の制御ハンドルが解除されると、 コントローラ A1〜A kのいずれもこの制御ハンドルの取得が可能となる。

なお、 曲リストに含まれる曲が複数のコンテンツサーバ S 1， S iに分散して 蓄積されている場合、 上記第 1の実施の形態と同様に、 オーディオクライアント C 1は図 77に示すようにコンテンツサーバ S 1から別のコンテンツサーバ S i に接続を切り換えることになる。 コンテンツサーバ S iはオーディオクライアン ト C 1から完了ステータスを受信しても、 オーディオクライアント C 1がどのコ ントローラ A l〜Akから命令された曲を再生し終えたのか不明である。 したが つて、 この場合もコンテンツサーバ S iは全てのコントローラ A l〜Akに完了 ステータスを転送するが、 コントローラ Al〜Akは制御ハンドル管理テ一ブル を有しているため、 自身が制御ハンドルを取得しているオーディオクライアント からの完了ステータスを受信したときのみ連続再生処理を実行する。 本例では、 コントローラ A1がオーディオクライアント C 1の制御ハンドルを取得している から、 このコントローラ A 1のみが連続再生処理を実行する。

以上のように本実施の形態によれば、 コントローラ A l〜Akの各々が制御ハ ンドル管理テーブルを有しているため、 オーディオクライアント C 1から送信さ れた完了ステータスをコンテンツサーバ S 1が全てのコントローラ Al〜Akに 転送しても、 コントローラ Al〜Akの各々は制御ハンドルを取得しているォー ディオクライアントからの完了ステータスを受信したときのみ連続再生処理を実 行する。 したがって、 連続再生命令の競合を排除し、 正常に連続再生処理を実行 することができる。

なお、 本実施の形態では制御ハンドル管理テーブルはコントローラ A l〜A k に格納されているが、 コンテンツサーバ S 1〜S iに格納されていてもよい。 また、 制御ハンドルをロックするのではなく、 最後に命令したコントローラが 制御ハンドルを取得できるようにしても構わない。 すなわち、 あるコントローラ A 1があるクライアント C 1の制御ハンドルを取得している際に、 別のコント口 ーラ A 2がクライアント C 1に再生を命令した場合、 コントローラ A 2が制御ハ ンドルを取得し、 コントローラ A 1は制御ハンドルを失うようにしてもよい。

1 . 2 . 3 . 3 . 8 . コンテンツサーバによる連続再生制御

最初に、 コンテンツサーバ、 オーディオクライアント及びコントローラをそれ ぞれ 1つずつ備えた単純な例を図 7 8を参照して説明する。

上記実施の形態と同様に、 コントローラ A 1は曲の再生をコンテンツサーバ S 1経由でオーディオクライアント C 1に命令する。 オーディオクライアント C 1 はこの命令に応じてその曲の音楽コンテンツをコンテンツサーバ S 1に要求し、 コンテンツサーバ S 1はこの要求に応じてその音楽コンテンツをオーディオクラ イアント C 1に配信する。 オーディオクライアント C 1は酉 3信された音楽コンテ ンッに基づいて曲の再生を開始し、 その曲を最後まで再生し終えると完了ステー タスをコンテンツサーバ S 1に送信する。 コンテンツサーバ S 1はこの完了ステ 一タスを受信すると、 上記実施の形態と異なり、 次の曲の連続再生をオーディオ クライアント C 1に自ら命令するとともに、 停止ステータスをコントローラ A 1 に送信する。

以下、 この詳細を図 7 9に示したフロー図を参照して説明する。 本実施の形態 では図 7 9に示したステップを実行するためのコンピュータプログラムがコンテ ンッサーバ S 1、 オーディオクライアント C 1及びコントローラ A 1にそれぞれ インストールされている。 図 7 9中のステップ S 2 0 3 2 3， S 1 0 2 2 1 , S 2 0 1 2 3〜S 2 1 1 2 5が図 7 3に示した実施の形態と異なるので、 ここでは これらを中心に説明する。 コントローラ A 1は上記実施の形態と同様に曲の再生をオーディオクライアン ト C 1に命令するが、 上記実施の形態と異なり、 さらにステップ S 3 0 2で曲リ ストを取得するために用いたリスト構築キーをオーディオクライアント C 1に送 信する （S 3 0 3 2 3 ) 。

オーディオクライアント C 1は上記第 1の実施の形態と同様に指定された曲の 音楽コンテンツをコンテンツサーバ S 1に要求し、 コントローラ A 1から送信さ れたリスト構築キーをコンテンツサーバ S 1に転送する （S 1 0 2 2 1 ) 。

コンテンツサーバ S 1は上記実施の形態と同様に指定された曲の音楽コンテン ッをオーディオクライアント C 1に配信するが、 上記実施の形態と異なり、 ォー ディオクライアント C 1から転送されたリスト構築キーに基づいて曲リストを作 成する （S 2 0 1 2 3 ) 。 リスト構築キー及び曲リストは、 クライアント情報と して、 オーディオクライアント C 1のクライアントインデックスに対応づけて記 録される。 これによりコンテンツサーバ S 1は、 オーディオクライアント C 1が コントローラ A 1からの命令に応じて再生している曲リストを把握していること になる。

音楽の再生終了後、 オーディオクライアント C 1から完了ステータスを受信し たコンテンツサーバ S 1は、 上記実施の形態と異なり、 停止ステータスをコント ローラ A 1に送信する （S 2 0 1 2 4 ) 。 そして、 コンテンツサーバ S 1はステ ップ S 1 2 3で作成した曲リストに従って次の曲の再生をォ ディオクライアン ト C 1に命令する （ S 2 0 1 2 5 ) 。

以上のように本実施の形態によれば、 コンテンツサーバ S 1自らが連続再生を 命令するため、 コントローラからの連続再生命令が競合することはなく、 正常に 連続再生処理を実行することができる。

上記の例はオーディオクライアントが 1つしかないが、 2つ以上あってもよい。 たとえば図 8 0に示した例では、 オーディオクライアント C 1及ぴ C 2がコンテ ンッサーバ S 1に接続されている。 上記ステップ S 1 2 3と同様に、 コンテンツ サーバ S 1は、 オーディオクライアント C 1及ぴ C 2が再生中のリスト構築キー 及び曲リストをそれぞれ記憶している。 完了ステータスがオーディオクライアン ト C 1からコンテンツサーバ S 1に送信されると、 コンテンツサーバ S 1は記憶 したオーディオクライアント C 1の曲リストに従ってオーディオクライアント C 1に連続再生を命令し、 コントローラ A 1に停止ステータスを送信する。 また、 完了ステータスがオーディオクライアント C 2からコンテンツサーバ S 1に送信 されると、 コンテンツサーバ S 1は記憶したオーディオクライアント C 2の曲リ ストに従ってオーディオクライアント C 2に連続再生を命令し、 コントローラ A 1に停止ステータスを送信する。 このようにコンテンツサーバ S 1はオーディオ クライアント C 1及び C 2を区別して連続再生を命令しているから、 連続再生命 令が競合することはない。

また、 オーディオクライアントだけでなく、 コンテンツサーバも 2つ以上あつ てもよい。 たとえば図 8 1に示した例では、 オーディオクライアント C 1及ぴ C 2がコンテンツサーバ S 1に接続され、 オーディオクライアント C 3がコンテン ッサーバ S 2に接続されている。 この場合も、 各クライアントに接続されている コンテンツサーバは 1つであるから、 オーディオクライアントは接続されている コンテンツサーバにのみ完了ステータスを送信する。 上記と同様に、 コンテンツ サーバ S 1はオーディオクライアント C 1から完了ステータスを受信するとォー ディオクライアント C 1に連続再生を命令し、 オーディオクライアント C 2から 完了ステータスを受信するとオーディオクライアント C 2に連続再生を命令する。 さらにこの場合、 コンテンツサーバ S 2はオーディオクライアント C 3から完了 ステータスを受信するとオーディオクライアント C 3に連続再生を命令する。 し たがってこの場合も、 オーディオクライアントに連続再生を命令するコンテンツ サーバはネットワーク上で唯一でとなるから、 連続再生命令が競合することはな レ、。

また、 図 8 1に示した場合において、 コントローラ A 1がコンテンツサーバ S 2に蓄積されている曲の再生をコンテンツサーバ S 1経由でオーディオクライァ ント C 2に命令したとき、 図 8 2に示すようにオーディオクライアント C 2はコ ンテンッサーバ S 1との接続をー且解除し、 コンテンツサーバ S 2に接続し直す。 このとき、 コンテンツサーバ S 2は、 オーディオクライアント C 2から送信され たリスト構築キーに基づいて曲リストを作成し、 オーディオクライアント C 2の クライアント情報としてこのリスト構築キー及び曲リストを記憶する。 オーディ オクライアント C 2はコンテンツサーバ S 2から配信された曲の再生を終えると、 コンテンツサーバ S 2に完了ステータスを送信する。 コンテンツサーバ S 2はこ の完了ステータスに応じてオーディオクライアント C 2に連続再生を命令すると ともに、 停止ステータスをコントローラ A 1に送信する。 したがってこの場合も、 オーディオクライアントに連続再生を命令するコンテンツサーバはネットワーク 上で唯一でとなるから、 連続再生命令が競合することはない。

また、 オーディオクライアント及びコンテンツサーバだけでなく、 コントロー ラも 2つ以上あってもよい。 たとえば図 8 3に示した例ではコントローラ A 1及 ぴ A 2がある。 コンテンツサーバ S 1はオーディオクライアント C 1又は C 2か ら完了ステータスを受信したとき、 コントローラ A 1だけでなくコントローラ A 2にも停止ステータスを送信する。 コンテンツサーバ S 2もまたオーディオクラ イアント C 3から完了ステータスを受信したとき、 コントローラ A 1だけでなく コントローラ A 2にも停止ステータスを送信する。 このようにコントローラ A 1 及び A 2は連続再生を命令する機能を有さず、 単にオーディオクライアント C 1 〜C 3の状態を監視する機能を有するだけであるから、 何ら連続再生処理に影響 を与えない。

1 . 2 . 3 . 3 . 9 . オーディオクライアント自身による連続再生制御 本実施の形態では、 図 8 4に示したステップを実行するためのコンピュータプ ログラムがコンテンツサーバ S 1〜S i、 オーディオクライアント C 1〜C j及 びコントローラ A l〜A kにそれぞれインストールされている。 図 8 4中のステ ップ S 1 0 2 3 3〜S 1 0 2 3 5が図 7 9に示した実施の形態と異なるので、 こ こではこれらを中心に説明する。

図 7 9に示した実施の形態と同様に、 コントローラ A 1は指定された曲の再生 をオーディオクライアント C 1に命令するとともに、 リスト構築キーをオーディ オクライアント C 1に送信し ( S 3 0 3 2 3 ) 、 オーディオクライアント C 1は 指定された曲をコンテンツサーバ S 1に要求し、 さらにこの要求に応じてコンテ ンッサーバ S 1から配信された曲の再生を開始する （S 1 0 2 0 2 ) 。 このとき、 オーディオクライアント C 1はコントローラ A 1から送信されたリスト構築キー を記憶しておく。 続いて、 オーディオクライアント C 1は記憶したリスト構築キーをコンテンツ サーバ S 1に送信し、 コントローラ A 1で選曲に使用した曲リストと同じ曲リス トをコンテンツサーバ S 1に要求する （S 10233) 。 コンテンツサーバ S 1 は受信したリス ト構築キーに基づいて曲リス トを作成し、 オーディオクライアン ト C 1に送信する （S 20133) 。 オーディオクライアント C1は受信した曲 リストを記憶するとともに、 その曲リストの中から現在再生中の曲を特定する (S 10234) 。

オーディオクライアント C 1はその曲を最後まで再生し終えると、 記憶した曲 リストに従って次の曲を再生する （S 10235) 。

なお、 曲リストに含まれる曲が複数のコンテンツサーバに分散して蓄積されて いる場合、 オーディオクライアント C1は上記と同様にサーバ切換処理を行う。 以上のように本実施の形態によれば、 オーディオクライアント C 1自身がリス ト構築キーを保持し、 それを利用して曲リス トを取得しているため、 自ら連続再 生処理を実行することができる。 したがって、 オーディオクライアント C 1がコ ントローラ A 1やコンテンツサーバ S 1から連続再生命令を受けることはなく、 連続再生命令が競合することはない。

本実施の形態でオーディオクライアント C 1がリス ト構築キーを利用して曲リ ストを取得しているのは曲の再生中であるが、 曲の再生終了後であってもよい。 また、 オーディオクライアント C1は取得した曲リストを記憶しているが、 記憶 しないで、 連続再生処理を実行するたぴにリスト構築キーを利用して曲リストを 取得してもよい。

1. 2. 3. 3. 10. 再生命令管理テーブルを利用した連続再生制御 本実施の形態では、 図 85に示したステップを実行するためのコンピュータプ ログラムがコンテンツサーバ S 1〜S i、 オーディオクライアント C 1〜C j及 ぴコントローラ A l〜Akにそれぞれインストールされている。 図 85中のステ ップ S 30341〜S 30345， S 20141が図 76に示した実施の形態と 異なるので、 ここではこれらを中心に説明する。

本実施の形態におけるコンテンツサーバ S 1には、 クライアントインデックス とコントローラインデックスとを対応づけた再生命令管理テーブルが記憶されて いる。 このテーブ^/の一例を次の表 3に示す 表 3に示した再生命令管理テープ ルには、 オーディオクライアント C 1に再生を命令した最新のコントローラ A 1 のコントローラインデックスが記録されている。 また、 オーディオクライアント

C 2に再生を命令した最新のコントローラ A 2のコントローラインデックスが記 録されている。

表 3 ：再生命令管理テーブル

次に、 図 85に示したフロー図を参照し、 本実施の形態の動作を説明する。 あるコントローラは、 あるコンテンツサーバに蓄積されている曲の再生をある オーディオクライアントに命令する （S 30341) 。

まず図 86に示すように、 コントローラ A 1がコンテンツサーバ S 1に蓄積さ れている曲の再生をコンテンツサーバ S 1経由でオーディオクライアント C 1に 命令する場合を説明する。 この例では、 オーディオクライアント C 1及び C 2並 びにコントローラ A 1〜A 3がコンテンツサーバ S 1に接続されている。

コントローラ A 1は、 コンテンツサーバ S 1にオーディオクライアント C 1が 接続されているか否かを判断する （S 30342) 。 この例ではオーディオクラ イアント C 1はコンテンツサーバ S 1に接続されているので、 ステップ S 314 に進む。

コントローラ A1は、 曲リストの中から指定された曲の再生をコンテンツサー バ S 1経由でオーディオクライアント C 1に命令する （S 30314) 。 コンテ ンッサーバ S 1は、 この再生命令に応じて予め定められた再生命令管理処理を実 行する （S 20141) 。

具体的には図 87を参照して、 コンテンツサーバ S 1は、 再生命令管理テープ ルにおけるオーディオクライアント C 1のクライアントインデックスに対応づけ て、 コントローラ A1のコントローラインデックスを記録する （S 20144 1) 。 これによりコンテンツサーバ S 1は、 コントローラ A1がオーディオクラ イアント C 1に最後に再生を命令したコントローラであることを記憶しているこ とになる。 コンテンツサーバ S 1は、 コントローラ A 1からの再生命令をオーデ ィォクライアント C 1に転送する （S 201412) 。

オーディオクライアント C 1はコントローラ A 1からの再生命令に応じて曲の 再生を開始し （S 10211) 、 その再生を終えると、 完了ステータスをコンテ ンッサーバ S 1に送信する （S 10212) 。

コンテンツサーバ S 1はオーディオクライアント C 1から完了ステータスを受 信すると、 再生命令管理テーブルを参照してオーディオクライアント C 1に最後 に再生を命令したコントローラ A1を特定し、 そのコントローラ A1に完了ステ 一タスを送信するとともに、 他のコントローラ A 2及び A 3に停止ステータスを 送信する （S 201413) 。 完了ステータスを受信したコントローラ A 1はォ 一ディオクライアント C1に連続再生処理を実行する （S 30316) 。 他方、 停止ステータスを受信したコントローラ A2及び A3は何ら能動的なァクション を起こさず、 単にオーディオクライアント C 1の状態を監視する。

また、 オーディオクライアント C 1がコントローラ A 1からの命令に従って曲 を再生している場合において、 別のコントローラ A2が同じオーディオクライァ ント C 1に別の曲の再生を命令すると、 オーディオクライアント C1は現在の曲 の再生を中止し、 コントローラ A2からの命令に従って新たな曲の再生を開始す る。 このとき、 コンテンツサーバ S 1は再生命令管理テーブルを更新し、 次の表 4に示すようにコントローラ A 1のコントローラインデックスをコントローラ A 2のコントローラインデックスに書き換える。

表 4 ：再生命令管理テーブル

次に図 88に示すように、 コントローラ A3がコンテンツサーバ S 1経由で別 のコンテンツサーバ S 2に蓄積されている曲の再生をオーディオクライアント C 1に命令する場合を説明する。 コントローラ A3は、 コンテンツサーバ S 2にオーディオクライアント C 1が 接続されている力否かを判断する （S 30342) 。 この例ではオーディオクラ イアント C 1はコンテンツサーバ S 2に接続されていないので、 コントローラ A 3は予め定められたサーバ切換処理を実行する （S 30343) 。

具体的には図 89を参照して、 コントローラ A 3はコンテンツサーバ S 1経由 でオーディオクライアント C 1にコンテンツサーバ S 1からコンテンツサーバ S 2への切換を命令する （S 303431) 。 コンテンツサーバ S 1はこの切換命 令をオーディオクライアント C 1に転送する (S 201401) 。 オーディオク ライアント C 1は現在接続中のコンテンツサーバ S 1を切断し （S 10240 1) 、 切換命令に応じて新しいコンテンツサーバ S 2に接続を要求する （S 10 2402) 。 コンテンツサーバ S 2はこの要求に応じてオーディオクライアント C1との接続を確立する （S 201402) 。 コントローラ A3はコンテンツサ ーバ S 2との接続を確認する （S 30344) 。

続いて、 コントローラ A3はコンテンツサーバ S 2経由で曲の再生をオーディ オクライアント C 1に命令する (S 30314) 。 コンテンツサーバ S 2はこの 再生命令に応じて、 次の表 5に示すように、 再生命令管理テーブルにおけるォー ディオクライアント C 1のクライアントインデックスに対応づけて、 コントロー ラ A 3のコントローラインデックスを記録する （S 201441) 。

表 5 ：再生命令管理テーブル

コンテンツサーバ S 2は、 コントローラ A 3からの再生命令をオーディオクラ イアント C 1に転送する （ S 20141 2 ) 。

オーディオクライアント C 1はコントローラ A 3からの再生命令に応じて曲の 再生を開始し （S 1021 1) 、 その再生を終えると、 完了ステータスをコンテ ンッサーバ S 2に送信する (S 1021 2) 。 コンテンツサーバ S 2はコント口 ーラ A 3から完了ステータスを受信すると、 再生命令管理テーブルを参照してォ 一ディオクライアント C 1に最後に再生を命令したコントローラ A3を特定し、 そのコントローラ A 3に完了ステータスを送信するとともに、 他のコントローラ A 1及び A 2に停止ステータスを送信する （S 1413) 。 完了ステータスを受 信したコントローラ A3はオーディオクライアント C1に連続再生処理を実行す る （S 30316) 。 他方、 停止ステータスを受信したコントローラ A1及び A 2は何ら能動的なアクションを起こさず、 単にオーディオクライアント C 1の状 態を監視する。

以上のように本実施の形態によれば、 コンテンツサーバがオーディオクライァ ントに最後に再生を命令したコントローラを管理し、 オーディオクライアントか らの完了ステータスをそのコントローラにのみ転送しているため、 そのコント口 ーラのみが連続再生をオーディオクライアントに命令する。 したがって、 連続再 生命令が競合することはなく、 正常に連続再生処理を実行することができる。

1. 2. 4. A Vレシーバの制御

図 90に示すように、 LAN12には AVRクライアント AC 1及び AC2が 接続される。 AVレシーバ AVR1は、 E I A— 232により AVRクライアン ト AC 1に接続される。 AVレシーバ AVR2は、 U S Bにより AVRクライア ント AC 1に接続される。 AVレシーバ AVR3は、 メーカ特有のシリアルイン ターフェースにより A VRクライアント AC 2に接続される。

AVRクライアント AC 1及び AC 2の各々は、 コンテンツサーバとの接続が 完了したとき、 E IA—232、 US Bなどのインタフェイスに関する情報をコ ンテンッサーバ S iに通知してもよい。

US Bの場合、 AVRクライアント AC 1は、 AVレシーバ AVR 2が接続さ れたとき、 AVレシーバ AVR 2のベンダ I Dやプロダクト IDなどの機種情報 を取得することができるので、 それをコンテンツサーバ S iに通知する。 E IA — 232の場合、 AVRクライアント AC1が AVレシーバ AVR1の機種情報 を取得するのは通常は困難であるから、 接続される A Vレシーバ A VR 1のベン ダ I D及びプロダクト I Dを AVRクライアント AC 1に予め登録しておき、 A VRクライアント AC 1がそれをコンテンツサーバ S iに通知するようにする。 接続される可能性がある A Vレシーバが複数ある場合は、 AVRクライアント との通信プロトコルを定めておき、 AVRクライアントが AVレシーバの機種情 報を取得するようにすればよい。 たとえば、 AVRクライアントは一定の通信条 件 （ビットレート、 ビット長、 パリティなど） で一定時間 （たとえば 1秒） ごと に機種情報を問い合わせるパケットを送信し、 AVレシーバはそれに応答して機 種情報を含むパケットを返信するようにすればよい。 これにより、 AVRクライ アントは接続されている AVレシーバを特定することができる。 USBの場合も 含めてこのような場合、 AVRクライアントはコンテンツサーバとの接続が確立 した後に AVレシーバの機種情報を取得する可能性もあるので、 AVレシーバの 機種情報を取得した時点でその機種情報の変更をコンテンツサーバ S iに通知す る。

その結果、 コンテンツサーバ S iは、 AVRクライアント AC 1， AC2に接 続された又は接続される予定の全 AVレシーバ AVR 1〜AVR 3の機種情報を 取得することができる。 機種情報はコンテンツサーバ S iからコントローラ Ak にも通知されるため、 コントローラ Akも機種情報を取得することになる。

AVレシーバ AVRは、 図 91に示すように、 ボリューム、 入力切換スィッチ、 音場制御用 DSPなど、 さまざまな被制御素子を有している。 コントローラ Ak はこのような被制御素子を指定して制御コマンドを発行する。 そのため、 コント ローラは、 A Vレシーバ A V Rがどのような被制御素子を有しているかという機 種情報を持っている。

なお、 機種情報はコンテンツサーバ S iが持っているから、 コントローラ Ak が AVレシーバ AVRのベンダ I D及びプロダク ト I Dをキーとしてコンテンツ サーバ S iに機種情報を要求してもよい。

制御コマンドは、 コントローラ Akから出力され、 コンテンツサーバ S i及び AVRクライアント ACを経て AVレシーバ AVRに伝えられる。 ステータスは 逆に、 AVレシーバ AVRから出力され、 AVRクライアント AC及びコンテン ッサーバ S iを経てコントローラ A kに伝えられる。

AVRクライアント ACは、 制御コマンドが A Vレシーバ A V R用であること を確認すると、 AVレシーバ AVRにその制御コマンドを出力する。 制御コマン ドがポリュームの値を制御するものであれば、 コントローラ Akが発行した制御 コマンドは、 コンテンツサーバ S i及び AVRクライアント ACを経て AVレシ ーバ AC Rに送られ、 これによりボリュームが制御される。

図 92を参照して、 コントローラ Akは制御コマンドをコンテンツサーバ S i に送信し （S 35) 、 コンテンツサーバ S iはこれを指定された AVRクライア ント ACに送信し （S 28) 、 さらに AVRクライアントはこれを AVレシ一バ AVRに送信する （S 101) 。 AVRクライアント ACは AVレシーバ AVR からそのステータスを受信してコントローラ Akに送信し （S 102) 、 コンテ ンッサーバは SVこれをコントローラ Akに送信し （S 29) 、 コントローラ A kはこれに応じて AVレシーバ AVRのステータスを更新する （S36) 。

図 93に示すように、 コンテンツサーバ S i、 AVRクライアント AC 1〜A

C3、 及ぴ A Vレシ一バ AVR 11, AVR 12, AVR 21, AVR31, A VR 32は、 コンテンツサーバ S iを根とした木のような形状をした経路で制御 コマンドを伝達する。

図 94を参照して、 コントローラ Akは、 制御対象たる A Vレシーバ A VR及 び制御内容を決定し （S 3501) 、 その制御内容に基づいてコマンド本体を生 成する （S 3502) 。 続いて、 コントローラ Akは、 図 95Aに示すように、 コマンド本体に宛先情報を付加した制御コマンドをコンテンッサーバ S iに送信 する （S 3503) 。 ここでの宛先情報は、 制御対象たる AVレシーバ AVRを 指定する A Vレシーバ指定部と、 その A Vレシーバ A V Rに接続された A V Rク ライアント ACを指定する AVRクライアント指定部とを含む。

コンテンツサーバ S iはこの制御コマンドを受信し、 図 95 Bに示すように、 受信した制御コマンドから AVRクライアント指定部を取り出す （S 2801) 。 コンテンツサーバ S iは、 この AVRクライアント指定部に基づいて指定された AVRクライアント ACを判断する。 続いて、 コンテンツサーバ S iは、 AVR クライアント指定部を取り除いた制御コマンドを指定された AVRクライアント ACに送信する （S 2802) 。

AVRクライアント ACはこの制御コマンドを受信し、 図 95 Cに示すように、 受信した制御コマンドから A Vレシーバ指定部を取り出す （S 1011) 。 AV Rクライアント ACは、 この AVレシーバ指定部に基づいて指定された AVレシ ーバを判断する。 続いて、 AVRクライアント ACは、 コマンド本体のみからな る制御コマンドを指定された AVレシーバに送信する （S 2802) 。

このように不要な指定部を順次取り除いて制御コマンドを転送すれば、 ネット ワークトラフィックを軽減することができる。 ただし、 指定部を取り除くことな く、 制御コマンドをそのまま転送するようにしてもよい。

各段階で、 コマンド本体の文字列は全く同じである必要はなく、 その意味が同 じであればよい。 すなわち、 最終的に AVRクライアント ACから AVレシーバ AVRに送信される制御コマンドが A Vレシーバ A V Rに理解可能な形式であれ ばよい。

このようにして制御コマンドを受信した A Vレシーバ A VRは、 制御コマンド に従って被制御素子を制御する。 その結果、 被制御素子のステータスが変化すれ ば、 AVレシーバ AVRはそのステータスを AVRクライアント ACに送信する。 このステータスは、 図 96Aに示すように、 ステータス本体のみからなる。

AVRクライアント ACは、 AVレシーバ AVRのステータスを受信して記憶 するとともに （S 1021) 、 図 96 Bに示すように、 受信したステータスに発 信元情報を追加し、 それをコンテンツサーバ S iに送信する (S 1022) 。 こ こでの発信元情報は、 ステータスを発信した A Vレシーバ A VRを指定する A V レシーバ指定部を含む。

コンテンツサーバ S iは AVRクライアント ACからのステータスを受信し、 図 96 Cに示すように、 受信したステータスに AVRクライアント指定部をさら に追カ卩し、 それをコントローラ Akに送信する （S 2901) 。

コントローラ Akはコンテンツサーバ S iからのステータスを受信し、 受信し たステータスから AVRクライアント指定部及ぴ AVレシーバ指定部を取り出し、 AVレシーバ AVRのステータスを更新する （S 3601) 。

なお、 ステータスは、 被制御素子のステータスだけでなく、 コントローラ Ak では制御不可能な要素のステータス （たとえば音声信号のレベル情報など） も存 在し得る。 このようなステータスも AVRクライアント AC及びコンテンツサー バ S iを経由してコントローラ Akに伝えられる。 また、 ステータスは、 AVレ シーバ AVRの被制御素子が制御コマンドにより制御されたときだけでなく、 そ のステータスが変化したときにも送信される。 すなわち、 AV Rクライアント A Cと A Vレシーバ A V Rとの接続が確認されたときにも、 AV Rクライアント A Cは AVレシーバ AV Rのステータスを取得し、 これをコンテンツサーバ S に 送信する。

このようにして最終的にステータスを受信したコントローラ A kは、 各 AVレ シーパ AV Rのステータスを把握することができる。 これにより、 コントローラ は制御の確認及びステータスの表示を行う。

なお、 表示目的のステータスであって頻繁に変化する可能性のあるステータス は、 AVレシーバ AV R又は AV Rクライアント A Cがステータスの送出頻度を 適宜低くしてもよい。 頻繁に変化するステータスをそのまま表示しても認識しに くいし、 送出頻度が高いとネットワークに無用なトラフィックが発生し、 コンテ ンッサーバの負荷も増大するからである。

複雑な #成を有する被制御素子は、 複数の被制御部を持つ場合がある。 たとえ ば図 9 1中の音場制御用 D S Pは多くの係数データの設定を必要とするが、 その 設定は D S Pを制御するマイクロコントローラにより行われる。 この設定を変更 する場合、 スタンドアロンのシステムでは、 A Vレシーバ本体又はそれに接続さ れた表示装置でステータス状態を表示しながら、 ユーザのキー操作により行うこ とになる。 この動作を行うのはマイクロコントローラのファームウェアであり、 複雑な設定が可能で、 かつ使い易い操作を実現しょうとすると、 プログラム容量 の増大や高性能な表示装置が必要になったりと、 製品単価や開発費用に影響が出 る可能性がある。

このシステムでは、 係数データの設定パターンをいくつもコンテンッサーバ S iに持たせ、 コントローラ A kに表示された階層メニューからそのうち 1つを選 択し、 A VRクライアント A C経由で係数データを設定することも可能である。 また、 同時に複数の AVレシーバ AV Rをコントローラ A kの支配下に置ける ことから、 A Vレシーバ A V Rの時刻合わせなどの設定を同時に行うことができ る。 さらに、 これら AVレシーバ AV Rのステータスをモニタすることにより、 リレー録画などの連携動作も可能になる。

次に、 AV Rクライアント A Cに接続されている AVレシーバ AV Rのボリュ ームを上げる場合を説明する。

図 97を参照して、 コントローラ Akはクライアントの接続を確認し （S 30 別し （S 3014) 、 AVRクライアント ACであれば、 ボリュームアップを示 す制御コマンドをコンテンツサーバ S iに送信する （S 35) 。 コンテンツサー ノ S iはこれを AVRクライアント ACに送信し （S 28) 、 さらに AVRクラ イアント ACはこれを AVレシーバ AVRに送信する （S 101) 。 AVRクラ イアント ACはポリユームアップしたことを示すステータスを AVレシーバ AV Rから受信し、 これをコンテンツサーバ S iに送信する （S 102) 。 コンテン ッサーバ S iはこれをコントローラ Akに送信し （S 29) 、 コントローラ Ak はこれに応じて A Vレシーバ AVRのステータスを更新し、 図 34に示したモニ タを再開する （S 36) 。

次に、 AVRクライアント ACが AVレシーバ A VRのステータスをコンテン ッサーバに転送する動作を図 98を参照して説明する。

AVRクライアント ACは AVレシーバ AVRからバケツトデータを受信する と （S 1021) 、 それがボリューム情報か否かを判別する （S 1022) 。 A Vレシーバ AVRからデータが E I A— 232の場合は、 バケツト受信はシリア ル受信割り込みで行われ、 データはキューに入れられる。 キューは定時的に読み 出され、 以降の処理が行われる。

続いて、 受信したデータがボリューム情報であれば、 AVRクライアント AC はそのボリューム値を記憶する （S 1023) 。 上記ボリューム情報か否かの判 別 (S 1022) 及びボリューム情報の記憶 （S 1023) は、 データがキュー に入れられる前に行われる。 一方、 受信したデータがボリューム情報でなければ、 AVRクライアント ACは、 AVレシーバ A VRからのステータスであることを 示す AVレシーバ指定部を、 受信したパケットデータに追カ卩してコンテンツサー パ S iに送信する （S 1024) 。

ボリューム値を記憶した後、 ボリューム情報の受信が初めてか否かを判別する (S 1025) 。 初めての場合はステップ S 1028に進むが、 初めてでない場 合は AVRクライアント ACはポリユーム値をコンテンツサーバに送信してから 20ミリ秒以上経過しているか否かを判別する （S 1026) 。 20ミリ秒以上 経過している場合、 AVRクライアント ACは前回送信したボリューム値を記憶 したボリューム値と比較し （S 1027) 、 異なっている場合は AVレシーバ A VRからのステータスであることを示す A Vレシーバ指定部をポリューム情報に 追加してコンテンツサーバ S iに送信する （S 1028) 。

ボリユーム値のステータスは他のステータスと比較して短い間隔でやって来る 場合があるので、 コンテンツサーバ S iやコントローラ Akの負担になったり、 ネットワークに無用なトラフィックの増大をもたらす可能性がある。 ボリューム 情報はコントローラ A kでの表示に用いるだけなので、 表示に支障のない間隔で 送れば問題ない。 そのため、 ボリューム情報を受信すると、 その値だけを記憶し、 変化があつたときだけ適当な間隔 （ここでは 20ミリ秒） をおいてコンテンツサ ーパ S iに送信するようにしている。

次に、 A VRクライアント ACがコンテンツサーバ S iからのコマンドを AV レシーバ A VRに転送する動作を図 99を参照して説明する。

AVRクライアント ACは AVレシーバ A VR用の制御バケツトを受信すると

(S 1031) 、 そのバケツトから A Vレシーバ A VR用の制御コマンドを取り 出す （S 1032) 。 AVRクライアント ACは、 その制御コマンドがポリユー ム値問い合わせコマンドか否かを判別する （S 1033) 。 ボリューム値問い合 わせコマンドの場合、 AVRクライアント ACは記憶しておいたボリユーム値 (未受信の場合は適当な初期値） からボリューム情報を生成し （S 1034) 、 A Vレシーバ A VRからのステータスであることを示す A Vレシーバ指定部をポ リユーム情報に追加してコンテンツサーバ S iに送信する （S 1035) 。

一方、 ポリューム値問い合わせコマンドでない場合、 その AVレシーバ AVR 用の制御コマンドを AVレシーバ AVRに送信する （S 1036) 。 AVRクラ イアント ACと AVレシーバ AVRとのインタフェイスが E I A— 232の場合 には、 AVRクライアント ACから AVレシーバ AVRへの送出はバイト単位で 割り込みによって行われる。 コンテンツサーバ S iからの制御コマンドはー且キ ユーに格納される。 キユーは定時的な割り込み又はシリアル送信のバッファェン プティの割り込みで読み出され、 パイト単位で送出される。 上記の形態では、 コンテンツサーバ S iへのボリューム情報の送出は、 初回を 除いて変化があつたときしか行われない。 そのため、 AVレシーバ AV Rがコン テンッサーバ S iからのボリューム値問い合わせコマンドに応答してボリューム 値を返したとしても、 そのボリューム値に変化がなければ A V Rクライアント A Cはそのボリューム値をコンテンツサーバ S iに返さない。 この対策として、 コ ンテンッサーバ S iからのボリューム値問い合わせコマンドに対しては、 AV R クライアント A Cは AVレシーバ AVRを介さずに応答するようにしている。 こ の形態は、 AVレシーバ AV Rに電源が投入されたときは必ず A Vレシーバ AV Rはボリュームの初期値をステータスとして AV Rクライアント A Cに送信する ことが前提となっている。 し力 し、 電源投入のタイミングによっては、 AV Rク ライアント A Cがこの初期値を受信できない可能性もある。

そこで、 図 1 0 0に示すように、 AV Rクライアント A Cは初回に限り AVレ シーバ AV R経由で応答を行うのが好ましい。 すなわち、 コンテンツサーバ S i からの制御コマンドがポリューム値間い合わせコマンドの場合、 A V Rクライア ント A Cはボリューム値を未だ受信していないか否かを判別する （S 1 0 3 4 ) 。 未だ受信していない場合はステップ S 1 0 3 6に進み、 既に受信している場合は ステップ S 1 0 3 4に進む。

なお、 複数種類の A Vレシーバが存在する場合において、 コントローラ A kが これらの AVレシーバを制御するときは、 コントローラ A kは AVレシーバの種 類に応じて専用の制御コマンドを発行してもよいが、 AVレシーバの種類に関係 なく汎用の制御コマンドを発行し、 コンテンッサーバがこの汎用の制御コマンド を専用の制御コマンドに変換するようにしてもよい。

1 . 2 . 5 . ファームウェアアップデート

コンテンツサーバは、 後述するように、 クライアントにインストールされてい るファームウェアをアップデートすることができる。 ここでは、 クライアントが コンテンツサーバにアップデートを要求する場合と、 コンテンツサーバがクライ アントに問い合わせをした上でァップデ トする場合と、 コンテンッサーバが強 制的にアップデートする場合とがある。

まず、 クライアントがコンテンツサーバにアップデートを要求する場合の概要 を説明する。 図 1 0 1を参照して、 クライアントはファームウェア情報をコンテ ンッサーバに要求し （S 1 03) 、 コンテンツサーバはこれに応じてファームゥ エア情報をクライアントに返信し （S 20 1) 、 クライアントはこれを受信する (S 1 0 3) 。 続いて、 クライアントはファームウェアを指定し （S 1 04) 、 コンテンツサーバはこれに応じて指定されたファームウェアの転送を準備する (S 202) 。 続いて、 クライアントはファームウェアをコンテンツサーバに要 求し （S 1 05) 、 コンテンツサーバはこれに応じてファームウェアをクライア ントに転送し （S 203) 、 クライアントはこれを受信する （S 1 05) 。 続い て、 クライアントはファームウェアをアップデートし （S 1 06) 、 アップデー トを終えると終了ステータスをコンテンツサーバに送信し （S 1 07) 、 コンテ ンッサーバはこれを受信する （S 204) 。

次に、 ファームウェアアップデートの詳細を図 1 02を参照して説明する。 コ ンテンッサーバからアップデートを開始する場合は、 ステップ S 20 1 2から処 理を開始する。 クライアントからアップデートを開始する場合は、 ステップ S 1 033から処理を開始する。

コンテンツサーバは、 まず、 ファームゥヱァ情報ファイルを読み込み、 図 1 5 に示したファームウェア情報データベースを作成しておく （S 201 1) 。 たと えば、 コンテンツサーバがクライアントごとにアツプデートに必要なファイルを 読み込み、 アップデート情報ファイルを作成する。 したがって、 この情報フアイ ノレに基づき、 クライアントのファームウェアの新旧を判断できる。 クライアント は、 起動時にプロダク ト I D及びファームウェア I Dをコンテンツサーバに送信 する （S 1 03 1) 。

コンテンツサーバからアップデートを開始する場合、 たとえばコンテンツサー バがクライアントのプロダクト I D及びファームウェア I Dに基づいてそのファ ームウェアが古いと判断した場合や、 コンテンツサーバがインターネット上のサ ィトから新しいファームウェアを取得した場合などには、 コンテンツサーバは、 クライアントにファームウェアのアップデートを要求するためのファームウェア アップデート要求コマンドを発行し、 必要に応じて、 アップデートを推奨する新 しいファームウェアの情報をクライアントに提示する （S 20 1 2) 。 ユーザが 推奨されたファームウェアのアップデートを望まない場合、 クライアントはコン テンッサーバからのアップデート要求を拒否し、 この処理は直ちに終了する （S 1 0 3 2 ) 。 また、 ユーザが推奨されたファームウェアのアップデートを保留す る場合も、 この処理は直ちに終了する （S 1 0 3 2 ) 。 ただし、 この場合、 クラ イアントはコンテンッサーバに所定時間経過後に再びァップデ一ト要求をするよ うに命令する。 また、 ユーザが推奨されたファームウェアのアップデートを受け 入れる場合、 クライアントはそのまま処理を継続する （S 1 0 3 2 ) 。 この場合 において、 コンテンツサーバがクライアントに具体的なファームウェアを提示し ているときは、 クライアントはステップ S 1 0 3 5に進み、 直ちにファームゥェ ァのアップデートを開始する。 また、 コンテンツサーバがクライアントに具体的 なファームウェアを提示することなく、 単にアップデートを要求しているときは、 クライアントはステップ S 1 0 3 3に進み、 ファームウェアリストを取得する。 なお、 ファームウェアアップデート要求コマンドは、 コントローラがサーパリ タエストとして発行してもよい。 この場合は、 コントローラは後述する S 1 0 3 3〜S 1 0 3 4と同様にして、 制御及ぴ監視するクライアントに関するファーム ウェアリストをコンテンツサーバから取得し、 ユーザが所望のファームウェアを 選択する。 コントローラにて選択されたファームウェアがアップデートを推奨す るファームウェア情報としてクライアントに提示される。

ァップデート要求を受け入れる場合、 又はクライアントからアツプデートを開 始する場合、 クライアントはファームウェアリストをコンテンツサーバに要求す る （S 1 0 3 3 ) 。 ファームウェアリストは、 特定クライアントに適用可能なフ アームウェアを列挙したものである。 コンテンツサーバは、 ファームウェアリス トを常時持っているのではなぐ、 クライアントからの要求に応じてその都度作成 する。 ファームウェアリストの作成方法は、 上述した曲リストの作成方法と基本 的に同じである。 ただし、 ファームウェアリストを作成するときには、 コンテン ッサーバは、 図 1 5に示したファームウェア情報データベースを用いる。 このデ ータベースには、 ファームウェア情報がファームウェア数分だけ格納されている。 以下、 ファームウェアリストの作成方法を詳述する。

図 1 0 3を参照して、 まずコンテンツサーバは、 ファームゥヱァ情報データべ ースに格納されているファームウェア情報の番号を示すィンデックスを 0に初期 化する （S 2 0 1 3 1 ) 。

続いて、 コンテンツサーバは、 インデックスが示すファームウェア情報のプロ ダクト I Dがクライアントのプロダクト I Dと一致するか否かを判別する （S 2 0 1 3 2 ) 。 一致する場合、 コンテンツサーバはそのファームウェア情報をファ ームウェアリストに追加し （S 2 0 1 3 3 ) 、 その後、 インデックスをインクリ メントする （S 2 0 1 3 4 ) 。 一方、 一致しない場合、 コンテンツサーバは、 ス テツプ S 2 0 1 3 3をスキップし、 直ちにインデックスをインクリメントする ( S 2 0 1 3 4 ) 。

続いて、 コンテンツサーバは、 インデックスが示すファームゥヱァ情報の番号 が全ファームウェア情報の数 nよりも小さいか否かを判別し （S 2 0 1 3 5 ) 、 小さい場合はステップ S 2 0 1 3 2に戻り、 一方、 小さくない場合はファームゥ エアリストの作成を完了する。

上記の処理により、 コンテンツサーバは、 ファームウェア情報データベースの 中からプロダクト I Dがー致するファームウェア情報をピックアップし、 ファー ムウェアリストを作成する。 このように、 ファームウエアリストは予めデータべ ース化されているのではなく、 クライアントからの要求のたびに一時的に作成さ れるので、 ファームウェアリストを常に格納しておくためのメモリ領域は不要で ある。

続いて、 コンテンツサーバは、 この作成したファームウェアリストを要求元ク ライアントに返信する （S 2 0 1 3 ) 。 このファームウェアリストも上記曲リス トと同様に、 コンテンツサーバからクライアントに分割されて送られる。

具体的には、 図 1 0 4を参照して、 クライアントは、 自身のプロダクト I Dと、 取得しょうとする最初のファームゥェァ情報を示す取得開始ィンデッタスと、 取 得しようとするファームウェア情報の数を示す取得個数とを含むファームウェア リスト要求コマンドをコンテンツサーバに送信する （S 1 0 3 3 ) 。 コンテンツ サーバは、 このファームウェアリスト要求コマンドに応答して、 クライアントの プロダクト I Dと同じプロダクト I Dを有するファームウェア情報を抽出し、 取 得開始ィンデックスが示すフアームゥヱァ情報から取得個数が示す数だけファー ムウェア情報をクライアントに返信する （S 2031) 。 このとき、 コンテンツ サーバは、 送信するファームウェア情報の数を示す有効個数と、 コンテンツサー バがクライアントに返信したファームウェアリストよりも後に残っているファー ムウェアの数を示す残り個数とを併せて送信する。 クライアントは、 このような ファームウェアリストの一部を受信してメモリに格納する （S 10331) 。 上 記処理は、 全ファームウェアリストがコンテンツサーバからクライアントに送ら れるまで繰り返される。

続いて、 クライアントは、 返信されたファームウェアリストの中にユーザがダ ゥンロードしたいファームウェア （新しいパージヨンなど） があれば処理を継続 し、 なければ処理を中止する （S 1034) 。

コンテンツサーバは、 新旧を問わず、 全てのバージョンのファームウェア情報 を送信するので、 不具合などにより、 クライアントは、 古いファームウェアに変 更することもできる。

ァップデ一トを行う場合、 クライアントはアツプデートセクションに移行した ことを示すステータスをコンテンッサーバに通知する (S 1034) 。 コンテン ッサーバは、 このステータスに応答してエラーの有無を示すエラーコードを返信 する （S 2014) 。 クライアントは、 ダウンロードしょうとするファームゥェ ァのファイルを指定する （S 1036) 。 具体的には、 取得したファームウェア 情報のリストに格納されているフルパス名を指定する。 コンテンツサーバは、 指 定されたファイルを読み出し、 ノ ッファに格納しておく （S 2015) 。

続いて、 クライアントは、 取得開始アドレス及ぴデータサイズ （バイト数） を 指定し、 ファームウェアのデータを取得する （S 1037) 。 コンテンツサーバ は、 指定された取得開始アドレスから指定されたバイト数分だけデータをバッフ ァから読み出し、 クライアントに送信する （S 2016) 。

クライアントは、 ファームウェアのデータを最後まで取得したか否かを判別し (S 1038) 、 取得していない場合はステップ S 1037に戻ってデータの取 得を繰り返す。 取得し終えた場合、 クライアントはファームウエアを書き換え (S 1039) 、 アップデートを終了する （S 1040) 。 コンテンツサーバは、 開いていたファームウェアのファイルを閉じ、 バッファを解放する （S 201 7 ) 。

さらに、 クライアントがファームウェアの書き換えを完了したときは、 不明ス テータスをコンテンツサーバに送信する。 クライアントは、 コンテンツサーバと の接続を中断して、 リセット （すなわち、 更新されたファームゥヱァを起動） し、 クライアント情報をコンテンツサーバに通知する。 また、 クライアントがファー ムウェアデータを取得失敗したときは、 失敗ステータスを送信してもよい。 失敗 ステータスは、 ファームウェアデータ再送信などに用いることができる。

なお、 コンテンツサーバからアップデート要求を行う場合において、 次の様に 処理することもできる。 すなわち、 図 1 0 2において、 コンテンツサーバはアツ プデート要求の際に、 必ずファームウェアの情報をクライアントに提示する （S 2 0 1 2 ) 。 コンテンツサーバが推奨するファームウェアをアップデートする場 合には S 1 0 3 5に進み、 コンテンツサーバが推奨するファームウェアをアップ デートするのではなく、 ユーザがファームゥヱァリストから所望のファームゥェ ァを選択する場合には S 1 0 3 3に進むようにすることもできる。

以上のように、 ファームウェアのデータがコンテンッサーバから L AN経由で オーディオクライアントに送信されるので、 クライアントのファームゥヱァを短 時間でアップデートすることができ、 しかも複数のクライアントのファームゥェ ァを同時にアップデートすることもできる。 また、 プロダクト I Dを用いている ため、 クライアントに適したファームウェアを自動的に選択してアップデートす ることがきる。 また、 ファームゥヱァ I Dを用いているため、 最新バージョンの ファームウェアを自動的に選択してアップデートすることがきる。

2 . 他の実施の形態

2 . 1 . コンセント内蔵型オーディオクライアント

オーディオクライアントは、 図 1 0 5及ぴ図 1 0 6に示すように、 コンセント ボックス 5 0に內蔵されてもよい。 コンセントボックス 5 0は一般に、 壁 5 2に 取り付けられる前面パネル 5 4と、 前面パネル 5 4の裏面に取り付けられた筐体 5 6とを備える。 この発明の実施の形態では、 筐体 5 6の中に、 図 3に示したォ 一ディオクライアント用の回路が設けられる。 L ANケーブルは、 このオーディ オクライアント用の回路に接続される。 また、 前面パネル 5 4には、 電源コンセ ント 5 8、 電源スィッチ 6 0、 モジュラージャック （図示せず） 、 テレビアンテ ナ用端子 （図示せず） などに加えて、 オーディオクライアントからのオーディオ 信号を出力するためのオーディオ出力端子 6 2が設けられる。 これらオーディオ 出力端子 6 2はそれぞれ左右のスピーカ装置に接続される。

オーディオクライアントは、 通常、 曲リストを表示するためのディスプレイと、 その表示された曲リストから所望の曲を選択するためのスィツチ類とを備えてい る。 ディスプレイゃスィツチ類はオーディオクライアントをモニタしかつ制御す るために必要であるが、 オーディオクライアントと同じ L AN 1 2に接続された コントローラを使用することにより、 オーディオクライアントからディスプレイ やスィッチ類を除去することができる。 また、 コントローラを使用する代わりに、 オーディオクライアントと同じ L AN 1 2に無線で接続された携帯型リモートコ ントローラを使用してもよい。

このようにオーディォクライアントを簡素化することにより、 一般家庭のコン セントボックス 5 0に内蔵することができる。 簡素化されたコンセント内蔵型ォ 一ディオクライアントは、 ネットワークから音楽や映像を抽出して再生する機能 のみを有し、 表示機能や制御機能を有していない。

インターネットの普及、 特にブロードパンド （高速'大容量） のインフラが整 備されるに従い、 一家に複数台のパソコンからインターネットに接続する要求が 增ぇると予想されている。 宅内で複数台のパソコンをインターネットに接続する 最も一般的な方法は、 宅内に L ANを構築することであり、 こうした宅内 L AN を備えた世帯が増加することは時間の問題となっている。 この L ANを利用すれ ば、 上述の音楽や映像を宅内の各所に配信することがケーブル 1本で可能になる。 また、 1本のケーブルには音楽ノ映像信号の他にコントロール信号も併せて伝送 することができるから、 本システムの設置にはオーディオ Zビデオに関する専門 的な知識が不要である。 さらに、 コスト面でも極めて有利であるため、 業務用の みならず、 家庭用としても普及しうる。

—般家庭において、 新築時又はリフォーム時にインターネット接続の利便性を 考慮して宅内 L ANを敷設するケースが増大しているが、 このときコンセントポ ックス 5 0に L ANコネクタを設けるのが極めて一般的である。 したがって、 L ANの敷設工事と同時に複数のオーディオクライアントを容易に設置することが できる。 すなわち、 スピーカ （パワードを含む） を接続するだけでオーディオク ライアントを構築することができ、 また、 テレビなどの映像モニタを接続するだ けでビデオクライアントを構築することができる。 そのため、 インテリア上も見 栄えのよいオーディオクライアントをセットすることができる。 さらに、 商品開 発の観点からも商品自体の華美なデザィン設計が不要となり、 機能を重視した極 めてシンプルな設計手法により商品開発コストの低減につながる。 また、 その構 造がシンプル故にリサイクルのし易さの点でも有益である。

宅内 L ANによる配信では、 従来のオーディオ/ビデオ機器と異なり、 C Dや テープといったコンテンツのメディアを必要としない。 すなわち、 コンテンツは

—度コンテンッサーバに格納してしまえば、 そのメディァの管理は不要となる。 こうした宅內ネットワークによるサーバクライアントの構成によれば、 オーディ オクライアントにはメディアを揷入する機構や回転駆動装置など、 機械系の装置 を全く必要としない。 したがって、 装置の小型化を達成し、 さらに高い信頼性と ともに長寿命な商品を可能にする。

2 . 2 . インターネット上の音楽データを取得

上記実施の形態では、 オーディオクライアントは電 投入時にブロードキャス トによりコンテンツサーバを探索している。 しかし、 L AN 1 2上の全コンテン ッサーバの電源が落ちていた場合、 コンテンツサーバからの応答がないため、 ォ 一ディオクライアントは永久にコンテンツサーバを探索し続けることになる。 こ れを防止するためには、 オーディオクライアントはタイムァゥトエラーなどの処 理を行えばよいが、 タイムアウトエラーの場合、 オーディオクライアントは音楽 を再生するなどの動作を全く行うことができない。

これらの問題を解決するためには、 オーディオクライアントがブロードキャス トを所定回数繰り返してもコンテンッサーバを発見することができない場合は、 インターネット上の WWWサーバにアクセスし、 このサーバと接続するようにす ればよい。

この場合、 L AN 1 2は、 図 1 0 7に示すように、 ゲートウェイ 5 0を通じて インターネット 5 2に接続される。 インターネット 5 2上の WWW (World Wide Web)サーバ 54には、 音楽配信サイト 56に置かれている曲のリストが予め登録 されている。 このリストには、 曲名やアーティスト名など、 曲情報の他、 音楽デ ータが置かれている URL (Un:iform Resource Locator)などが記録されている。 図 108に示すように、 サーバリストが空の場合、 オーディオクライアントは、 ステップ S 1102に戻ってブロードキャストをリ トライする前に、 そのリ トラ ィ回数が所定の回数、 たとえば 3回に達したか否かを判別する （S 1109) 。 リ トライ回数が 3回に達していない場合、 オーディオクライアントはリ トライ回 数をインクリメントし （S 1110) 、 その後、 ステップ S 1102に戻ってプ ロードキャストをリ トライする。 一方、 リ トライ回数が 3回に達している場合、 オーディオクライアントはインターネット 52上の WWWサーバ 54に HTTP で接続する （S 1111) 。 オーディオクライアントが接続に成功した場合は探 索を完了するが （S 1112) 、 接続に成功せず、 タイムァゥトになった場合は エラーとなる （S 1113) 。

オーディオクライアントは WWWサーバ 52にアクセスすると、 そこから曲情 報や URLを受信して解析し、 その URLの音楽酉己信サイト 56から音楽データ を受信する。

以上のように、 コンテンツサーバが LAN 12上に存在しない場合又は存在し ても稼動していない場合は、 オーディオクライアントはインターネット 52上の サイト 56に自動的にアクセスして音楽データを取得するので、 LAN12上の コンテンツサーバを永久に探索し続けることはない。

上記の例では、 リ トライ回数が所定回数に達したとき、 オーディオクライアン トはインターネット 52上の WWWサーバ 54に接続するようにしているが、 こ れに代えて、 オーディオクライアントがマジックヮードをブロードキャストして 所定時間が経過したにもかかわらず、 LAN12上のいずれのコンテンツサーバ からも応答がない場合にインターネット 52上の WWWサーバ 54に接続するよ うにしてもよい。

2. 3. 取得データ長変更機能付き再生

上記実施の形態では、 オーディオクライアント C jがコンテンツサーバ S iに 曲データの転送を要求するとき、 常に一定量の曲データを要求している。 したが つて、 コンテンツサーバ S iに曲データの転送を要求するオーディオクライアン ト C jの数が少ない場合は問題ないが、 この数が多くなると、 コンテンツサーバ S iにかかる負荷が大きくなり、 オーディオクライアント C jがコンテンツサー パ S iに曲データの転送を要求してから実際に曲データが転送されるまでの時間 が長くなるという問題が生じる。 そこで、 このコンテンツサーバ S iにかかる負 荷が均等になるように、 オーディオクライアント C jが 1回に要求する曲データ の量をその都度変更するようにしてもよい。

以下、 オーディオクライアント C jがコンテンツサーバ S iに曲データの転送 を要求してから実際に曲データが転送されるまでの時間に応じて、 オーディオク ライアント C jが 1回に要求する曲データの量を変更する例を説明する。

H1 1 0 9を参照して、 オーディオクライアント C jは、 コンテンツサーバ S i に曲データの転送を要求する曲データ転送コマンドを送信する （S 1 6 0 1 ) と 同時に、 タイマを動作させ、 コンテンツサーバ S iから曲データが転送されるま での応答時間のカウントを開始する （S 1 6 0 1 1 ) 。 なお、 最初にオーディオ クライアント C jが曲データ転送コマンドを発行するときには、 1回に要求すベ き適切な曲データの量は不明であるから、 取得データ長は予め定められたものに なる。

続いて、 オーディオクライアント C jは曲データを受信し始めると （S 1 6 0 1 2 ) 、 タイマを停止し、 コンテンツサーバ S iによる曲データの応答時間を取 得する （S 1 6 0 1 3 ) 。

オーディ才クライアント C jは、 図 1 1 0に示した対比テーブルを参照し、 取 得した応答時間に対応する取得データ長を決定する （S 1 6 0 2 1 ) 。 この対比 テーブルには、 所定の応答時間と所定の取得データ長とが対応つけられている。 ここでは、 応答時間が長いほどコンテンツサーバ S iにかかる負荷は大きいから、 応答時間が長いほど取得データ長が短くなるように設定されている。 たとえばォ 一ディオクライアント C jが 2 0 m s e cの応答時間を取得した場合は、 取得デ 一タ長を 8 kバイトと決定する。

オーディオクライアント C jは再ぴ曲データの転送をコンテンツサーバ S iに 要求するが、 ここでは上記で決定した取得データ長を送信する （S 1 6 0 5 )。 以降、 上記と同様の動作を繰り返す （S 1 6 0 5 1〜S 1 6 0 6 1 )。

以上のようにこの実施の形態によれば、 オーディオクライアント C jがコンテ ンッサーバ S iに要求する曲データの取得データ長を応答時間が長くなるにつれ て短くしているため、 コンテンツサーバ S iに曲データの転送を要求するオーデ ィォクライアント C ] 'の数が増えても、 コンテンツサーバ S iがオーディオクラ イアント C jに 1回に転送する曲データの量は少なくなる。 その結果、 各オーデ ィォクライアント C jに対するコンテンツサーバ S iの負荷は平均化され、 コン テンッサーバ S iは複数のオーディオクライアント C jに円滑に曲データを転送 することができる。

上記の例では、 コンテンツサーバの応答時間に応じて取得データ長を決定して いるが、 これに代えて、 取得しょうとする曲のデータフォーマットに応じて取得 データ長を決定するようにしてもよい。 すなわち、 図 3 5において、 曲データ転 送要求 （S 1 6 0 1 ) 前に、 図 3 2に示す検索データに基づいて、 曲の音声フォ 一マットを取得する。 そして、 曲の音声フォーマットに基づいて、 取得データ長 を設定する。 一般に M P 3形式のデータは圧縮されているためにサイズが小さい のに対し、 WA V形式のデータはサイズが大きい。 そこで、 取得しょうとする曲 のデータフォーマットが M P 3の場合には、 1回にたとえば 4 Kパイトのデータ を取得し、 WA Vの場合には、 1回にたとえば 1 6 Kバイトのデータを取得する ようにしてもよい。

2 . 4 . スキップ再生

上記実施の形態では、 オーディオクライアント C jは曲リストの順序にしたが つてコンテンツサーバ S iに曲データの転送を要求している。 しかしながら、 ュ 一ザが現在再生中の曲をはじめから聴きなおしたい場合がある。 また、 ユーザが 現在再生中の曲をスキップして、 他の曲を聴きたい場合もある。 そこで、 オーデ ィォクライアント C jがこのようなユーザの要求に対応して曲データ転送の要求 をできるようにしてもよい。

図 1 1 1を参照して、 オーディオクライアント C jが図 1 1 2に示した曲リス ト中の曲 3の再生を行っている場合、 オーディオクライアント C jは曲 3の音楽 データのうち指定範囲の音楽データの転送をコンテンツサーバ S iに要求し （S 1 6 0 7 ) 、 コンテンツサーバ S iはこの要求に応じて指定範囲の音楽データを オーディオクライアント C jに返信し （S 2 6 0 4 ) 、 オーディオクライアント C jはこれを受信し、 メモリ 3 2に格納する （S 1 6 0 8 ) 。 この動作の繰り返 しにより曲 3は再生される。

曲 3の再生中に、 ユーザが曲 3の再生を終了して、 曲 4を聴こうとした場合 (図 1 1 2における①のケース） 、 ユーザはオーディオクライアント C jに曲 4 へのスキップ要求を行う。 オーディオクライアント C jはユーザからのスキップ 要求を受け （S 1 6 4 0 ) 、 メモリ 3 2に格納された曲リスト内容を確認し、 曲 4のファイル名を敢得する （S 1 6 4 1 ) 。 ユーザからのスキップ要求がない場 合は、 ステップ S 1 6 0 7に戻って曲 3のデータ転送の要求を行う。

以降のオーディオクライアント C jおよびコンテンツサーバ S iの動作につい ては図 3 5での動作と同じであるため、 その説明は繰り返さない。

以上の動作により、 オーディオクライアント C jは曲 3の再生中に曲 4ヘスキ ップ再生できる。

なお、 オーディオクライアント C jが曲 3を再生中において、 ユーザが曲 3を 初めから再ぴ聴こうとする場合 （図 1 1 2における②ケース） 、 ユーザが曲 5を 聴こうとする場合 （図 1 1 2における③ケース） 、 ユーザが曲 2を聴こうとする 場合 （図 1 1 2における④ケース） 等についても同様の動作により、 オーディオ クライアント C jはスキップ再生できる。

以上のようにこの実施の形態によれば、 オーディオクライアント C jはメモリ 内に格納された曲リストを用いることで、 現在再生中の曲から他の曲へスキップ 再生できる。

2 . 5 . リピート再生

また、 ユーザが指定する第 1アドレスと第 2アドレスとの間で、 データを繰り 返して再生する A— B間リピート再生を行うことができる。 まず、 ユーザは 1回 目の A— B 間リピート操作を行い、 繰り返しの始まりを示す第 1アドレスを指定 する。 すなわち、 図 1 1 3を参照して、 オーディオクライアントは、 曲データの 転送要求 （および曲データの取得） の際に （S 1 6 0 1 ) 、 ユーザからの操作が あって （S 1 6 4 2 ) 、 ユーザからの操作が A— B間リピート要求であって （S 1643) 、 1回目の要求であるので （SI 644) 、 ユーザが指定したァドレ スを第 1アドレス （a d d r l) として記憶する。 そして、 前回の取得開始アド レス （a d d r) に取得データ長 （s i ze) を加算して取得開始アドレス （a d d r) を算出し （S 1646) 、 SI 601へと戻る。

次に、 ユーザは 2回目の A— B 閬リピート操作を行い、 繰り返しの終わりを示 す第 2アドレスを指定し、 リピート動作を開始させる。 すなわち、 S1 644に おいて、 ユーザからの A— B 間リピート要求が 2回目の要求である （1回目の要 求ではない） ので、 ユーザが指定したアドレスを第 2アドレス （a d d r 2) と して記憶する （S 1647) 。

そして、 オ^"ディオクライアントは、 A— B間リピートモードに入る （S164

8) 。 すなわち、 取得開始アドレスを第 1アドレスに変更し （S1649) 、 曲デ ータ転送要求 （および曲データ取得） を行う （S1 601) 。 ここで、 オーディ 才クライアントは、 A— B 間リピート状態であると判断し （S1650) 、 取得開 始アドレス （=前回の取得開始アドレス +取得データ長） が第 2アドレスより大 きくなるか否かを判別する （S 1 651 ) 。 取得開始ァドレスが未だ第 2ァドレ ス以下であれば、 曲データ転送要求を続ける （S1646および S1601) 。 そして、 S1 651において、 取得開始アドレスが第 2アドレスより大きくなる 場合には、 取得開始アドレスを再び第 1アドレスに変更し （S 1652) 、 曲デ ータ転送要求を行う （S 1601) 。 従って、 第 1アドレスと第 2アドレスとの 間でリピート再生を行うことができる。 また、 ユーザはリピート解除操作を行う ことにより、 リピート状態を解除することができる （S 1643、 S 1653お ょぴ S 1 654) 。

2. 6. 途中再生

また、 取得開始アドレスをユーザが指定する （例えば、 開始時間を入力する） ことにより、 指定アドレスからの曲の再生を行うことができる。 すなわち、 図 1 14を参照して、 例えば曲データの転送要求 （および曲データの取得） の際に (S 1601) 、 ユーザからの操作があって （S 1656) 、 アドレスの指定で ある場合には （S 1657) 、 オーディオクライアントはユーザから指定のあつ たアドレスを取得する （S 1658) 。 例えば、 曲の総再生時間とユーザが入力 した開始時間からアドレスを算出する。 そして、 取得開始アドレスをユーザから 指定のあったアドレスに変更して （S 1 6 5 9 ) 、 曲データ転送要求 （および曲 データ取得） を行う （S 1 6 0 1 ) 。 従って、 ユーザが指定するアドレスからの 曲の再生行うことができる。 さらに、 ユーザがアドレスを指定することができる のは、 オーディオクライアントが再生状態のときに限らず、 例えば、 停止状態や 一時停止状態のときであってもよい。

2 . 7 . 自動接続回復機能付きクライアント

ネットワークオーディオシステムでは、 上述したように、 オーディオクライア ントがコンテンツサーバに接続され、 コンテンツサーバから配信された音楽を再 生しているが、 配信中にコンテンツサーバの異常によりオーディオクライアント がコンテンツサーバから切り離された場合、 オーディオクライアントはコンテン ッサーバに再び接続されなければ音楽を再生することができない。 入力装置を有 する通常のオーディオクライアントの場合、 その入力装置を操作することにより そのオーディオクライアントに図 5に示したようにコンテンツサーバとの接続処 理を再び実行させればよい。 しかし、 上述したコンセント内蔵型オーディオクラ イアントの場合、 入力装置を備えていないため、 一旦コンテンツサーバから切り 離されるとそのまま放置されてしまう。 したがって、 オーディオクライアントは 以下のような自動接続回復機能を備えているのが望ましい。

図 1 1 5を参照して、 オーディオクライアント C jはコンテンツサーバ S iと 接続してから所定期間が経過したか否かを判断する （S 1 1 0 ) 。 所定期間経過 後、 オーディオクライアント C jはコンテンツサーバ S iとの接続が維持されて いるか否かを判断する （S i l l , S 1 1 2 ) 。 具体的には、 オーディオクライ アント C jは接続確認コマンドをコンテンツサーバ S iに送信する （S 1 1 1 ) 。 コンテンツサーバ S iからオーディオクライアント C jに接続確認コマンドに対 する返答がある場合 ( S 1 1 2 ) 、 接続は維持されていると判断される。 一方、 返答がない場合や送信エラーが起きる場合 ( S 1 1 2 ) 、 接続は切断されている と判断される。 返答方法としては、 たとえばコンテンツサーバ S iが送信された 接続確認コマンドと同じコマンドを返信する方法がある。

ステップ S I 1 2で返答があった場合、 オーディオクライアント C jは再び S 1 10に戻って所定期間経過後に接続が維持されているか否かを判断する （S 1 10〜S 112) 。 これにより、 オーディオクライアント C jは所定期間ごとに コンテンツサーバ S iとの接続状態をチヱックする。 接続が切断されている場合、 オーディオクライアント C jは同じコンテンツサーバ S iに対して再接続を試み る （S 12) 。

再接続を試みた結果、 コンテンツサーバ s iとの接続に成功した場合 （si 1

3) 、 オーディオクライアント C jは切断直前のクライアントステータスをコン テンッサーバ S iに送信する （S 13) 。 クライアントステータスは例えば、 「再生」 、 「停止」、 「ポーズ」 等の再生状態や、 音量情報、 リスト構築キーなど を含む。 よって、 オーディオクライアント C jはコンテンツサーバ S iとの接続 状態をもとどおりに回復できる。 その結果、 ユーザはオーディオクライアント C jがコンテンツサーバ S iと接続し直したことを意識せずにオーディオクライァ ント C jを利用できる。

一方、 再接続を試みた結果、 コンテンツサーバ S i との接続に失敗した場合 (S 1 13) 、 オーディオクライアント C jは同じコンテンツサーバ S iとの接 続回復を断念し、 他のコンテンツサーバ S iとの接続処理を実行する （S 11〜 S 13) 。 具体的には、 オーディオクライアント C jはブロードキャストにより 接続可能なコンテンツサーバ S iを探索し (S 1 1) 、 探索したコンテンツサー バ S iに対して接続を行う （S 12) 。 接続後、 オーディオクライアント C ま 切断直前のクライアントステータスをコンテンツサーバ S iに送信する (S 1 3) 。

オーディオクライアント C jは、 図 1 15に示した接続回復プログラムをイン ストールすることにより、 上述した自動接続回復機能を備える。

以上の動作により、 オーディオクライアント C jから所定期間ごとに接続状態 を確認し、 切断されていればオーディオクライアント C j 自身が再接続を実行す る。 そのため、 コンテンツサーバ S iの異常により接続が切断されても、 オーデ ィォクライアント C jがコンテンツサーバ s iから切断されたまま放置されるこ とはない。 また、 接続していたコンテンツサーバ S iの異常によりそのコンテン ッサーバ S iと再接続ができない場合でも、 オーディオクライアント C jは他の コンテンツサーバ S i と接続する。 その結果、 ユーザは常にコントローラ A kを 用いてオーディオクライアント C jを制御することができる。

また、 オーディオクライアント C jは接続先のコンテンツサーバ S iに切断直 前のクライアントステータスを送信しているため、 オーディオクライアント C j は他のコンテンツサーバ S iに接続されても切断直前と同じ状態にできる。 その 結果、 ユーザはオーディオクライアント C jがコンテンツサーバ S iと切断され たことを意識することなく、 オーディオクライアント C jを利用できる。

本実施の形態では、 オーディオクライアント C jが自動接続回復機能を備えて いるが、 コントローラ A kが自動接続回復機能を備えていてもよレ、。 また、 音楽 再生機能及び制御機能を併有する能動的なクライアントよりはむしろ、 音楽再生 機能だけを有する受動的なクライアントが自動接続回復機能を備えているのが好 ましい。 制御機能を有さない受動的なオーディオクライアント C jは自らコンテ ンッサーバ S iにコマンドを送信することがないため、 ー且コンテンツサーバ S iとの接続が切断されるとそのまま放置されてしまレ、、 ユーザがそのオーディオ クライアント C jを再起動しない限りコンテンツサーバ S iとの接続を回復でき ないからである。

上述した全ての実施の形態における各ステップは、 コンピュータに実行させる ための動作プログラムを形成する。 よって、 この動作プログラムを、 コンテンツ サーバ S i、 オーディオクライアント、 コントローラ、 及ぴ AV Rクライアント にインストールすることにより、 ネットワーク型オーディオシステムを構築する ことができる。 また、 この動作プログラムは、 そのままインターネットなどの電 気通信回線を通じて配信されてもよいが、 C D _ R OM、 D VD— R OMなどの コンピュータ読み取り可能な記憶媒体に格納されて配布されてもよい。

以上、 本発明の実施の形態を説明したが、 上述した実施の形態は本発明を実施 するための例示に過ぎない。 よって、 本発明は上述した実施の形態に限定される ことなく、 その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実 施することが可能である。

Claims

請求の範囲

1 . サーバと、 前記サーバに接続された少なくとも 1つの第 1のクライアントと を備えたネットワーク型コンテンツ再生システムであって、

前記サーバは、

複数のコンテンツを蓄積する蓄積手段を含み、

前記第 1のクライアントは、

前記複数のコンテンツの中から選択されたコンテンツを前記サーバに要求する コンテンッ要求手段を含み、

前記サーバはさらに、

前記第 1のクライアントからの要求に応じて前記選択されたコンテンツを前記 第 1のクライアントに返信するコンテンッ返信手段を含み、

前記第 1のクライアントはさらに、

前記サーバから返信されたコンテンツを再生する再生手段を含むことを特徴と するネットワーク型コンテンツ再生システム。

2 . 請求項 1に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアントはさらに、

複数のコンテンツを列挙したコンテンツリストを前記サーバに要求するコンテ ンッリスト要求手段を含み、

前記サーバはさらに、

前記第 1のクライアントからの要求に応じて前記コンテンツリストを返信する コンテンツリスト返信手段を含み、

前記第 1のクライアントはさらに、

前記サーバから返信されたコンテンツリストを受信するコンテンツリスト受信 手段を含み、

前記コンテンツ要求手段は、 前記要求すべきコンテンッを前記コンテンッリス トの中から選択することを特徴とするネットワーク型コンテンツ再生システム。

3 . 請求項 2に記載のネットワーク型コンテンツ再生システムであって、 前記コンテンツリスト要求手段は、 指定量のコンテンツリストを前記サーバに 要求し、

前記コンテンツリスト返信手段は、 前記第 1のクライアントからの要求に応じ て前記指定量のコンテンツリストを返信することを特徴とするネットワーク型コ ンテンッ再生システム。

4 . 請求項 3に記載のネットワーク型コンテンツ再生システムであって、 前記コンテンツリスト要求手段は、 前記第 1のクライアントが前記サーバから 取得しょうとする最初のコンテンツを示す取得開始ィンデッタスと、 前記第 1の クライアントが前記サーバから取得しようとするコンテンツの数を示す取得個数 とを含むリスト要求コマンドを送信し、

前記コンテンツリスト返信手段は、 前記リスト要求コマンドに応答して、 前記 取得開始ィンデックスが示す最初のコンテンッから前記取得個数分のコンテンツ を含むコンテンツリストを返信することを特徴とするネットワーク型コンテンツ 再生システム。

5 . 請求項 4に記載のネットワーク型コンテンツ再生システムであって、 前記コンテンツリスト返信手段はさらに、 前記返信するコンテンツリストに含 まれるコンテンツ数と、 前記返信するコンテンツリスト以降の残りのコンテンツ 数とを返信することを特徴とするネットワーク型コンテンツ再生システム。

6 . 請求項 2〜請求項 5のいずれか 1項に記載のネットワーク型コンテンツ再生 システムであって、

前記第 1のクライアントはさらに、

複数のカテゴリを列挙したカテゴリリストを前記サーバに要求するカテゴリリ スト要求手段を含み、

前記サーバはさらに、

前記第 1のクライアントからの要求に応じて前記カテゴリリストを返信する手 段を含み、

前記第 1のクライアントはさらに、

前記サーバから返信されたカテゴリ リストを受信する手段を含み、

前記コンテンツリスト要求手段は、 要求しようとするコンテンツリストのコン テンッが属するカテゴリを前記受信されたカテゴリリストの中から選択すること を特徴とするネッ トワーク型コンテンツ再生システム。

7 . 請求項 2〜請求項 6のいずれか 1項に記載のネットワーク型コンテンツ再生 システムであって、

前記コンテンツリスト要求手段は、 前記コンテンツリストを作成するために必 要なリスト構築キーを前記サーバに送信し、

前記コンテンツリスト返信手段は、 前記第 1のクライアントから送信されたリ スト構築キーに基づいて前記コンテンツリストを作成することを特徴とするネッ トワーク型コンテンツ再生システム。

8 . 請求項 1〜請求項 7のいずれか 1項に記載のネットワーク型コンテンツ再生 システムであって、

前記コンテンツ要求手段は、 予め定められた量のコンテンッを前記サーバに要 求し、

前記コンテンツ返信手段は、 前記第 1のクライアントからの要求に応じて前記 予め定められた量のコンテンツを返信し、

前記コンテンツ要求手段は、 前記コンテンツの全部を取得するまで前記コンテ ンッの要求を繰り返すことを特徴とするネットワーク型コンテンツ再生システム。

9 . 請求項 8に記載のネットワーク型コンテンツ再生システムであって、

前記第 1のクライアントはさらに、

前記サーバから返信されたコンテンツを蓄積するバッファメモリを備え、 前記コンテンツ要求手段は、 前記バッファメモリに所定量の空きが生じたとき 前記予め定められた量のコンテンツを前記サーバに要求することを特徴とするネ ットワーク型コンテンツ再生システム。

1 0 . 請求項 8又は請求項 9に記載のネットワーク型コンテンツ再生システムで あって、

前記コンテンツ要求手段は、 前記予め定められた量のコンテンツの最初のアド レスを示す取得開始アドレスを算出し、 当該取得開始アドレスと、 前記第 1のク ライアントが前記サーバから取得しょうとするコンテンツの長さを示す取得デー タ長とを含むコンテンツ転送要求コマンドを送信し、

前記コンテンツ返信手段は、 前記コンテンツ転送要求コマンドに応答して、 前 記取得開始ァドレスから前記取得データ長分のコンテンッを返信することを特徴 とするネットワーク型コンテンツ再生システム。

1 1 . 請求項 1 0に記載のネットワーク型コンテンツ再生システムであって、 前記コンテンツ要求手段は、 前記取得データ長を前の取得開始ァドレスに加算 して次の取得開始ァドレスを算出することを特徴とするネットワーク型コンテン ッ再生システム。 ，

1 2 . 請求項 1 1に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアントはさらに、

ユーザの操作に応じて第 1及ぴ第 2のアドレスを設定する手段と、

前記算出された取得開始アドレスが前記第 2のアドレスを超えたとき、 前記取 得開始ァドレスを前記第 1のアドレスに設定する手段とを含むことを特徴とする ネットワーク型コンテンツ再生システム。

1 3 . 請求項 1 1に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアントはさらに、

ユーザの操作に応じて所望のァドレスを設定する手段と、

前記取得開始ァドレスを前記所望のァドレスに設定する手段とを含むことを特 徴とするネットワーク型コンテンツ再生システム。

1 4 . 請求項 1 0又は請求項 1 1に記載のネットワーク型コンテンツ再生システ ムであって、

前記第 1のクライアントはさらに、

ユーザの操作に応じて所定のスキップ量を設定する手段と、

前記取得開始ァドレスを前記設定されたスキップ量だけシフトする手段とを含 むことを特徴とするネットワーク型コンテンツ再生システム。

1 5 . 請求項 8〜請求項 1 4のいずれか 1項に記載のネットワーク型コンテンツ 再生システムであって、

前記第 1のクライアントはさらに、

前記選択されたコンテンツの識別情報を前記サーバに送信する手段を含み、 前記サーバはさらに、

前記第 1のクライアントから送信された識別情報に応答して前記選択されたコ ンテンッのオフセットを前記第 1のクライアントに返信する手段を含み、 前記第 1のクライアントはさらに、

前記サーバから返信されたオフセッ トに基づいて前記選択されたコンテンツの 始まりを検知する手段を含むことを特徴とするネットワーク型コンテンツ再生シ ステム。

1 6 . 請求項 8〜請求項 1 5のいずれか 1項に記載のネットワーク型コンテンツ 再生システムであって、

前記第 1のクライアントはさらに、

前記選択されたコンテンツの識別情報を前記サーバに送信する手段を含み、 前記サーバはさらに、

前記第 1のクライアントから送信された識別情報に応答して前記選択されたコ ンテンッのサイズを前記第 1のクライアントに返信する手段を含み、

前記第 1のクライアントはさらに、

前記サーバから返信されたサイズに基づいて前記選択されたコンテンツの終わ りを検知する手段を含むことを特徴とするネットワーク型コンテンツ再生システ ム。

1 7 . 請求項 1〜請求項 7のいずれか 1項に記載のネットワーク型コンテンツ再 生システムであって、

前記コンテンツ要求手段は、 要求するコンテンツの最初のァドレスを示す取得 開始アドレスを算出して前記サーバに送信し、

前記コンテンッ返信手段は、 前記第 1のクライアントから送信された取得開始 ァドレスからコンテンッを返信することを特徴とするネットワーク型コンテンツ 再生システム。

1 8 . 請求項 1〜請求項 7のいずれか 1項に記載のネットワーク型コンテンツ再 生システムであって、

前記コンテンッ要求手段は、 指定量のコンテンッを前記サーバに要求し、 前曾己コンテンツ返信手段は、 前記第 1のクライアントからの要求に応じて前記 指定量のコンテンツを返信し、

前記コンテンツ要求手段は、 前記サーバに要求するコンテンッの指定量を変化 させることを特徴とするネットワーク型コンテンツ再生システム。

1 9 . 請求項 1 8に記載のネットワーク型コンテンツ再生システムであって、 前記コンテンツ要求手段は、 前記サーバにコンテンツを要求してから前記サー パから前記要求したコンテンッが転送されるまでの時間に応じて、 前記サーバに 要求するコンテンツの指定量を変化させることを特徴とするネットワーク型コン テンッ再生システム。

2 0 . 請求項 1 8に記載のネットワーク型コンテンツ再生システムであって、 前記コンテンツ要求手段は、 前記サーバに要求するコンテンツのデータフォー マツトに応じて、 前記サーバに要求するコンテンツの指定量を変化させることを 特徴とするネットワーク型コンテンツ再生システム。

2 1 . 請求項 1〜請求項 2 0のいずれか 1項に記載のネットワーク型コンテンツ 再生システムであって、

前記第 1のクライアントはさらに、

自身に関するクライアント情報が変化するたびにそのクライアント情報を前記 サーバに送信する手段を含むことを特徴とするネットワーク型コンテンツ再生シ ステム。

2 2 . 請求項 1〜請求項 2 1に記載のネットワーク型コンテンツ再生システムで あってさらに、

前記サーバに接続され、 前記第 1のクライアントを監視する第 2のクライアン トを備えることを特徵とするネットワーク型コンテンツ再生システム。

2 3 . 請求項 2 2に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアントはさらに、

自身に関するクライアント情報を前記サーバに送信する手段を含み、 前記サーバは、

前記第 1のクライアントから送信されたクライアント情報を受信する手段と、 前記受信したクライアント情報を前記第 2のクライアントに送信する手段とを 含み、

前記第 2のクライアントは、

前記サーバから送信されたクライアント情報を受信する手段を含むことを特徴 とするネットワーク型コンテンツ再生システム。

2 4 . 請求項 2 3に記載のネットワーク型コンテンツ再生システムであって、 前記サーバは、 前記第 2のクライアントに要求を強制的に送信するためのプッ シュポートを通じて、 前記クライアント情報を前記第 2のクライアントに送信す ることを特徴とするネットワーク型コンテンツ再生システム。

2 5 . 請求項 2 3又は請求項 2 4に記載のネットワーク型コンテンツ再生システ ムであって、

前記第 2のクライアントはさらに、

前記受信したクライアント情報を表示する手段と、

前記受信したクライアント情報が変更されているとき、 そのクライアント情報 の表示を変更する手段とを含むことを特徴とするネットワーク型コンテンツ再生 システム。

2 6 . 請求項 2 3〜請求項 2 5のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 2のクライアントはさらに、

複数のコンテンツを列挙したコンテンツリストを前記サーバに要求するコンテ ンッリスト要求手段を含み、

前記サーバはさらに、

前記第 2のクライアントからの要求に応じて前記コンテンツリストを返信する コンテンツリスト返信手段を含み、

前記第 2のクライアントはさらに、

前記サーバから返信されたコンテンツリス トを受信するコンテンツリスト受信 手段を含むことを特徴とするネットワーク型コンテンツ再生システム。

2 7 . 請求項 2 6に記載のネットワーク型コンテンツ再生システムであって、 前記クライアント情報は前記コンテンツリストを作成するために必要なリスト 構築キーを含み、

前記コンテンツリスト要求手段は、 前記受信されたクライアント情報に含まれ るリスト構築キーが変更されているとき、 そのリスト構築キーを前記サーバに送 信し、 前記コンテンツリスト返信手段は、 前記第 2のクライアントから送信されたリ スト構築キーに基づ 、て前記コンテンッリストを作成することを特徴とするネッ トワーク型コンテンツ再生システム。

2 8 . 請求項 2 3〜請求項 2 7のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 2のクライアントは、 前記サーバに接続されたとき、 前記サーバから送 信されたクライアント情報を受信することを特徴とするネットワーク型コンテン ッ再生システム。

2 9 . 請求項 2 8に記載のネットワーク型コンテンツ再生システムであって、 前記クライアント情報は前記コンテンツリストを作成するために必要なリスト 構築キーを含み、

前記コンテンツリスト要求手段は、 前記受信されたクライアント情報に含まれ るリスト構築キーを前記サーバに送信し、

前記コンテンツリスト返信手段は、 前記第 2のクライアントから送信されたリ スト構築キーに基づいて前記コンテンツリストを作成することを特徴とするネッ トワーク型コンテンツ再生システム。

3 0 . 請求項 2 3〜請求項 2 9のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記クライアント情報は、 前記第 1のクライアントにより再生可能なコンテン ッのデータフォーマツトの名称を含み、

前記第 2のクライアントは、

前記受信されたクライアント情報に基づいて前記データフォーマツトの名称を 表示する手段を含むことを特徴とするネットワーク型コンテンツ再生システム。 3 1 . 請求項 3 0に記載のネットワーク型コンテンツ再生システムであって、 前記第 2のクライアントはさらに、

複数のコンテンツを列挙したコンテンツリストを前記サーバから取得する手段 と、

前記取得したコンテンツリストに含まれるコンテンツのうち、 前記第 1のクラ イアントにより再生可能なコンテンッを表示し、 前記第 1のクライアントにより 再生不可能なコンテンツを表示しないか又は前記再生可能なコンテンツと異なる 態様で表示する手段とを含むことを特徴とするネットワーク型コンテンツ再生シ ステム。

3 2 . 請求項 2 2〜請求項 3 1のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 2のクライアントは、

監視しょうとするクライアントが前記第 1のクライアントかを判別する手段を 含むことを特徴とするネットワーク型コンテンッ再生システム。

3 3 . 請求項 2 2〜請求項 3 2のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 2のクライアントは、

前記第 1のクライアントを監視するために必要な監視ハンドルを取得する手段 と、

前記監視ハンドルを取得したとき前記第 1のクライアントを監視する手段とを 含むことを特徴とするネットワーク型コンテンツ再生システム。

3 4 . 請求項 3 3に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアントはさらに、

自身に関するクライアント情報を前記サーバに送信する手段を含み、 前記サーバは、

前記第 1のクライアントから送信されたクライアント情報を受信する手段と、 前記第 2のクライアントが前記監視ハンドルを取得しているか否かを判別する 手段と、

前記判別の結果、 前記第 2のクライアントが前記監視ハンドルを取得している とき、 前記受信したクライアント情報を前記第 2のクライアントに送信する手段 とを含み、

前記第 2のクライアントは、

前記サーバから送信されたクライアント情報を受信する手段を含むことを特徴 とするネットワーク型コンテンツ再生システム。

3 5 . 請求項 2 2〜請求項 3 4のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 2のクライアントはさらに、 前記第 1のクライアントを制御することを 特徴とするネットワーク型コンテンツ再生システム。

3 6 . 請求項 1〜請求項 2 1のいずれか 1項に記載のネットワーク型コンテンツ 再生システムであってさらに、

前記サーバに接続され、 前記第 1のクライアントを制御する第 2のクライアン トを備えることを特徴とするネットワーク型コンテンツ再生システム。

3 7 . 請求項 3 6に記載のネットワーク型コンテンツ再生システムであって、 前記第 2のクライアントは、

前記第 1のクライアントを制御するように前記サーバに要求するサーバリクェ スト手段を含み、

前記サーバはさらに、

前記第 2のクライアントからの要求に応じて前記第 1のクライアントを制御す る手段を含むことを特徴とするネットワーク型コンテンッ再生システム。

3 8 . 請求項 3 6又は請求項 3 7に記載のネットワーク型コンテンツ再生システ ムであって、

前記サーバは、 前記第 1のクライアントに要求を強制的に送信するためのプッ シュポートを通じて前記第 1のクライアントを制御することを特徴とするネット ワーク型コンテンツ再生システム。

3 9 . 請求項 3 7に記載のネットワーク型コンテンツ再生システムであって、 前記サーバリクエスト手段は、 前記第 1のクライアントを特定するための情報 と、 前記選択されたコンテンツを特定するための情報とを前記サーバに送信する ことを特徴とするネットワーク型コンテンツ再生システム。

4 0 . 請求項 3 6〜請求項 3 9のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 2のクライアントは、

制御しょうとするクライアントが前記第 1のクライアントかを判別する手段を 含むことを特徴とするネットワーク型コンテンツ再生システム。

4 1 . 請求項 3 6〜請求項 4 0のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 2のクライアントは、

前記選択されたコンテンツのデータフォーマツトが前記第 1のクライアントに より再生可能なコンテンツのデータフォーマットに一致するか否かを判別する手 段と、

前記データフォーマツトが一致する場合、 前記選択されたコンテンツに基づい て前記コンテンツを再生するように前記第 1のクライアントに命令する手段とを 含むことを特徴とするネットワーク型コンテンツ再生システム。

4 2 . 請求項 3 6〜請求項 4 1のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 2のクライアントは、

前記第 1のクライアントを制御するために必要な制御ハンドルを取得する手段 と、

前記制御ハンドルを取得したとき前記第 1のクライアントを制御する手段とを 含むことを特徴とするネットワーク型コンテンツ再生システム。

4 3 . 請求項 4 2に記載のネットワーク型コンテンツ再生システムであって、 前記第 2のクライアントはさらに、

前記第 1のクライアントに対してサーバリクエストを発行するよう前記サーバ に要求する手段を含み、

前記サーバは、

前記第 2のクライアントが前記サーバリクエストを発行するよう要求したとき、 前記第 2のクライアントが前記制御ハンドルを取得しているか否かを判別する手 段と、

前記判別の結果、 前記第 2のクライアントが前記制御ハンドルを取得している とき、 前記サーバリクエストを前記第 1のクライアントに送信する手段とを含む ことを特徴とするネットワーク型コンテンツ再生システム。

4 4 . 請求項 3 6〜請求項 4 3のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 1のクライアントはさらに、 前記第 2のクライアントにより命令されたコンテンツを再生し終えた場合、 完 了ステータスを前記サーバに送信し、 自らが選択したコンテンツを再生し終えた 場合、 又はユーザの操作に応じてコンテンツの途中で再生を終えた場合、 前記完 了ステータスと異なる停止ステータスを前記サーバに送信する手段を含むことを 特徴とするネットワーク型コンテンツ再生システム。

4 5 . 請求項 3 6〜請求項 4 4のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記サーバは、

前記第 1のクライアントから送信された完了ステータスを受信し、 前記第 2の クライアントに送信する手段を含み、

前記第 2のクライアントは、

前記サーバから送信された完了ステータスに応答して、 前記再生し終えたコン テンッの次のコンテンツを再生するように前記第 1のクライアントに命令する手 段を含むことを特徴とするネットワーク型コンテンツ再生システム。

4 6 . 請求項 3 6〜請求項 4 5のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 2のクライアントはさらに、 前記第 1のクライアントを監視することを 特徴とするネットワーク型コンテンツ再生システム。

4 7 . 請求項 1〜請求項 4 6のいずれか 1項に記載のネットワーク型コンテンツ 再生システムであって、

前記第 1のクライアントはさらに、

所定情報をブロードキャストするブロードキャスト手段を含み、

前記サーバは、

前記第 1のクライアントからブロードキャストされた所定情報に応答して、 自 身を特定するためのサーバ特定情報を前記第 1のクライアントに返信する手段を 含み、

前記第 1のクライアントは、

前記サーバから返信されたサーバ特定情報を受信してサーバリストに登録する 手段とを含むことを特徴とするネットワーク型コンテンツ再生システム。

4 8 . 請求項 4 7に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアントはさらに、

前記サーバリストに前記サーバ特定情報が登録されているか否かを判別する手 段を含み、

前記判別の結果、 前記サーバリストに前記サーバ特定情報が登録されていない 場合、 前記ブロードキャスト手段は前記所定情報を再ぴプロードキャストするこ とを特徴とするネットワーク型コンテンツ再生システム。

4 9 . 請求項 4 8に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアントはさらに、

前記ブロードキャスト手段によるブロードキャストの回数が所定回数に達した とき、 又は前記ブロードキャスト手段によるブロードキャストの時間が所定時間 に達したとき、 インターネット上のサーバにアクセスする手段を含むことを特徴 とするネットワーク型コンテンツ再生システム。

5 0 . 請求項 1〜請求項 4 9のいずれか 1項に記載のネットワーク型コンテンツ 再生システムであって、

前記第 1のクライアントはさらに、

前記サーバと前記第 1のクライアントとの間でコマンドを送受信するためのコ マンドポートで接続を確立する手段と、

前記サーバから前記第 1のクライアントに要求を強制的に送信するためのプッ シュポートで接続を確立する手段とを含むことを特徴とするネットワーク型コン テンッ再生システム。

5 1 . 請求項 5 0に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアン卜はさらに、

自身を識別するために必要なクライアントインデックスを要求するクライアン トインデックス要求コマンドを前記コマンドポートを通じて前記サーバに送信す る手段を含み、

前記サーバはさらに、

前記第 1のクライアントから送信されたクライアントインデックス要求コマン ドに応答して前記クライアントインデックスを前記クライアントに返信する手段 を含み、

前記第 1のクライアントはさらに、

前記サーバから返信されたクライアントインデックスを前記プッシュポートを 通じて前記サーバに送信する手段を含むことを特徴とするネットワーク型コンテ ンッ再生システム。

5 2 . 請求項 5 0又は請求項 5 1に記載のネットワーク型コンテンツ再生システ ムであって、

前記第 1のクライアントは複数あり、

前記サーバは、

接続可能なクライアントの数を制限する接続制限手段を含むことを特徴とする ネットワーク型コンテンツ再生システム。

5 3 . 請求項 5 2に記載のネットワーク型コンテンツ再生システムであって、 前記接続制限手段は、 未接続の第 1のクライアントが接続を試みてきたとき、 所定の優先順位に従って既接続の第 1のクライアントとの接続を断つことを特徴 とするネットワーク型コンテンツ再生システム。

5 4. サーバと、

前記サーバに接続された第 1のクライアントと、

前記第 1のクライアントに接続された A V機器と、

前記サーバに接続され、 前記 AV機器を制御する第 2のクライアントとを備え、 前記第 2のクライアントは、

前記 A V機器を制御するための制御コマンドを前記サーバに送信する手段を含 み、

前記サーバは、

前記第 2のクライアントから送信された制御コマンドを前記第 1のクライアン トに送信する手段を含み、

前記第 1のクライアントは

前記サーバから送信された制御コマンドを前記 A V機器に送信する手段を含み、 前記 A V機器は、 前記第 1のクライアントから送信された制御コマンドに応答 して制御されることを特徴とするネットワーク型コンテンツ再生システム。

5 5 . 請求項 5 4に記載のネットワーク型コンテンツ再生システムであって、 前記 AV機器は、

制御可能な素子と、

前記第 1のクライアントから送信された制御コマンドに応答して前記素子を制 御する手段とを含むことを特徴とするネットワーク型コンテンツ再生システム。 5 6 . 請求項 1〜請求項 5 3のいずれか 1項に記載のネットワーク型コンテンツ 再生システムであってさらに、

前記第 1のクライアントに接続された AV機器を備え、

前記コンテンッ再生手段は、 前記サーバから返信されたコンテンツデータを前 記 A V機器に送信し、

前記 A V機器は、 前記第 1のクライアントから送信されたコンテンツデータに 基づいて前記コンテンツを再生することを特徴とするネットワーク型コンテンツ 再生システム。

5 7 . サーバと、

前記サーバに接続された第 1のクライアントと、

前記第 1のクライアントに接続きれた AV機器と、

前記サーバに接続され、 前記 A V機器を監視する第 2のクライアントとを備え、 前記 A V機器は、

自身に関する情報を前記第 1のクライアントに送信する手段を含み、

前記第 1のクライアントは、

前記 A V機器から送信された情報を前記サーバに送信する A V機器情報送信手 ΰみヽ ·

前記サーバは、

前記第 1のクライアントから送信された情報を前記第 2のクライアントに送信 する手段を含むことを特徴とするネットワーク型コンテンツ再生システム。

5 8 . 請求項 5 7に記載のネットワーク型コンテンツ再生システムであって、 前記情報は頻繁に変化する情報であり、

前記第 1のクライアントの AV機器情報送信手段は、 前記情報を所定の時間間 隔で送信することを特徴とするネットワーク型コンテンッ再生システム。

5 9 . 請求項 1〜請求項 5 8のいずれか 1項に記載のネットワーク型コンテンツ 再生システムであって、

前記サーバはさらに、

前記第 1のクライアントのファームゥヱァを更新するファームウェア更新手段 を含むことを特徴とするネットワーク型コンテンツ再生システム。

6 0 . 請求項 5 9に記載のネットワーク型コンテンツ再生システムであって、 前記サーバはさらに、

前記第 1のクライアントに適した複数のファームゥェァの情報を登録する手段 と、

前記登録された複数のファームウェアの情報を列挙したファームゥヱアリスト を前記第 1のクライアントに送信するファームウェアリスト送信手段とを含み、 前記第 1のクライアントはさらに、

前記サーバから送信されたファームウェアリストを受信する手段と、 前記受信されたファームウェアリストの中から選択されたファームウェアの送 信を前記サーバに要求するファームゥェァ要求手段とを含み、

前記ファームゥヱァ更新手段は、 前記第 1のクライアントからの要求に応じて 前記選択されたファームウェアを前記第 1のクライアントに返信することを特徴 とするネットワーク型コンテンツ再生システム。

6 1 . 請求項 6 0に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアントはさらに、

自身に関するクライアント情報を前記サーバに送信する手段を含み、 前記サーバはさらに、

前記第 1のクライアントから送信されたクライアント情報に基づいて前記ファ ームウェアリストを作成する手段を含むことを特徴とするネットワーク型コンテ ンッ再生システム。

6 2 . 請求項 5 9〜請求項 6 1のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記第 1のクライアントは、 指定量のファームウェアを前記サーバに要求し、 前記ファームゥエア更新手段は、 前記第 1のクライアントからの要求に応じて 前記指定量のファームウェアを返信することを特徴とするネットワーク型コンテ ンッ再生システム。

6 3 . 請求項 6 2に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアントは、 前記第 1のクライアントが前記サーバから取得し ようとするファームゥ-ァが格納されている最初のアドレスを示す取得開始アド レスと、 前記第 1のクライアントが前記サーバから取得しようとするファームゥ エアの長さを示す取得データ長とを送信し、

前記ファームウェア更新手段は、 前記第 1のクライアントからの要求に応じて、 前記取得開始ァドレスから前記取得データ長分のファームウェアを返信すること を特徴とするネットワーク型コンテンツ再生システム。

6 4 . 請求項 5 9〜請求項 6 3のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、

前記サーバはさらに、

前記第 1のクライアントにファームウェアを更新するように要求し、 そのファ ームウェアに関する情報を前記第 1のクライアントに送信する手段を含むことを 特徴とするネットワーク型コンテンツ再生システム。

6 5 . 請求項 6 0〜請求項 6 4のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであって、 '

前記第 1のクライアントはさらに、

指定量のファームゥヱアリストを前記サーバに要求するファームウェアリスト 要求手段を含み、

前記ファームウェアリスト送信手段は、 前記第 1のクライアントからの要求に 応じて前記指定量のファームウェアリストを前記第 1のクライアントに送信する ことを特徴とするネットワーク型コンテンツ再生システム。

6 6 . 請求項 6 5に記載のネットワーク型コンテンツ再生システムであって、 前記ファームウェアリスト要求手段は、 前記第 1のクライアントが前記サーバ から取得しようとする最初のファームウェアの情報を示す取得開始ィンデックス と、 前記第 1のクライアントが前記サーバから取得しょうとするファームウェア の情報の数を示す取得個数とを含むファームウェアリスト要求コマンドを送信し、 前記ファームゥヱァリス ト送信手段は、 前記ファームゥヱアリスト要求コ' ドに応答して、 前記取得開始ィンデックスが示す最初のファームゥ ァの情報か ら前記取得個数分のファームゥェァの情報を含むファームウェアリス卜を送信す ることを特^ [とするネットワーク型コンテンツ再生システム。

6 7 . 請求項 5 9〜請求項 6 6のいずれか 1項に記載のネットワーク型コンテン ッ再生システムであってさらに、

前記サーバに接続され、 前記第 1のクライアントを制御する第 2のクライアン トを備え、

前記第 2のクライアントは、

前記第 1のクライアントのファームウェアを更新するよう前記サーバに要求す る手段を含むことを特徴とするネットワーク型コンテンツ再生システム。

6 8 . サーバと、 前記サーバに接続された第 1のクライアントと、 前記サーバに 接続された複数の第 2のクライアントとを備えたネットワーク型コンテンッ再生 システムであって、

前記サーバは、

複数のコンテンツを蓄積するコンテンツ蓄積手段を備え、

前記第 2のクライアントの各々は、

前記複数のコンテンツの中からコンテンツを指定し、 その指定したコンテンツ の再生を前記第 1のクライアントに命令する手段を備え、

前記第 1のクライアントは、

前記第 2のクライアントからの命令に応じて前記指定されたコンテンツを再生 する手段と、

前記コンテンツの再生を完了したとき完了ステータスを前記サーバに送信する 手段とを備え、

前記サーバはさらに、

前記第 1のクライアントから完了ステータスを受信したとき、 前記複数の第 2 のクライアントのうち 1つを選択し、 その選択した第 2のクライアントに完了ス テータスを送信するステータス送信手段を備え、

前記第 2のクライアントの各々はさらに、 前記サーバから完了ステータスを受信したとき、 前記第 1のクライアントが再 生を完了したコンテンツの次のコンテンツを指定し、 その指定したコンテンッの 再生を前記第 1のクライアントに命令する手段を備えたことを特徴とするネット ワーク型コンテンツ再生システム。

6 9 . 請求項 6 8に記載のネットワーク型コンテンツ再生システムであって、 前記サーバはさらに、

前記第 1のクライアントを制御可能な第 2のクライアントの優先順位を管理す る手段を備え、

前記ステータス送信手段は、 前記完了ステータスを送信すべき第 2のクライア ントとして前記優先順位が最高の第 2のクライアントを選択することを特徴とす るネットワーク型コンテンツ再生システム。

7 0 . 請求項 6 9に記載のネットワーク型コンテンツ再生システムであって、 前記ステータス送信手段は、 前記優先順位が最高の第 2のクライアント以外の 第 2のクライアントに停止ステータスを送信することを特徴とするネットワーク 型コンテンツ再生システム。

7 1 . 請求項 6 8に記載のネットワーク型コンテンツ再生システムであって、 前記サーバはさらに、

前記再生を命令した第 2のクライアントの識別情報を記憶する手段を備え、 前記ステータス送信手段は、 前記完了ステータスを送信すべき第 2のクライア ントとして前記記憶した第 2のクライアントの識別情報に基づいて前記再生を命 令した第 2のクライアントを選択することを特徴とするネットワーク型コンテン ッ再生システム。

7 2 . 請求項 7 1に記載のネットワーク型コンテンツ再生システムであって、 前記ステータス送信手段は、 前記選択した第 2のクライアント以外の第 2のク ライアントに停止ステータスを送信することを特徴とするネットワーク型コンテ ンッ再生システム。

7 3 . サーバと、 前記サーバに接続された第 1のクライアントと、 前記サーバに 接続された複数の第 2のクライアントとを備えたネットワーク型コンテンツ再生 システムであって、 前記サーバは、

複数のコンテンッを蓄積するコンテンッ蓄積手段を備え、

前記第 2のクライアントの各々は、

前記第 1のクライアントを制御するために必要な制御ハンドルを取得する制御 ハンドル取得手段と、

前記制御ハンドルの取得後、 前記複数のコンテンツの中からコンテンツを指定 し、 その指定したコンテンツの再生を前記第 1のクライアントに命令する手段と を備え、

前記第 1のクライアントは、

前記第 2のクライアントからの命令に応じて前記指定されたコンテンツを再生 する手段と、

前記コンテンツの再生を完了したとき完了ステータスを前記サーバに送信する 手段とを備え、

前記サーバはさらに、

前記第 1のクライアントから送信された完了ステータスを前記第 2のクライア ントの各々に転送する手段を備え、

前記第 2のクライアントの各々はさらに、

前記制御ハンドルを取得している第 1のクライアントからの完了ステータスを 受信したとき、 前記第 1のクライアントが再生を完了したコンテンツの次のコン テンッを指定し、 その指定したコンテンツの再生を前記第 1のクライアントに命 令する手段を備えることを特徴とするネットワーク型コンテンッ再生システム。 7 4 . 請求項 7 3に記載のネットワーク型コンテンツ再生システムであって、 前記制御ハンドル取得手段は、 前記制御ハンドルを取得したとき当該他の第 2 のクライアントによる前記制御ハンドルの取得を禁止することを特徴とするネッ トワーク型コンテンツ再生システム。

7 5 . 請求項 7 4に記載のネットワーク型コンテンツ再生システムであって、 前記第 1のクライアントはさらに、

前記コンテンツの再生を途中で停止したとき停止ステータスを前記サーバに送 信する手段を備え、 前記サーバはさらに、

前記第 1のクライアントから送信された停止ステータスを前記第 2のクライア ントの各々に転送する手段を備え、

前記第 2のクライアントの各々はさらに、

前記制御ハンドルを取得している第 1のクライアントからの停止ステータスを 受信したとき、 前記制御ハンドルの取得禁止を解除する手段を備えたことを特徴 とするネットワーク型コンテンツ再生システム。

7 6 . サーバと、 前記サーバに接続された第 1のクライアントと、 前記サーバに 接続された第 2のクライアントとを備えたネットワーク型コンテンツ再生システ ムであって、

前記サーバは、

複数のコンテンツを蓄積するコンテンツ蓄積手段を備え、

前記第 2のクライアントは、

前記複数のコンテンツの中からコンテンツを指定し、 その指定したコンテンツ の再生を前記第 1のクライアントに命令する手段を備え、 ,

前記第 1のクライアントは、

前記第 2のクライアントからの命令に応じて前記指定されたコンテンツを再生 する手段と、

前記コンテンツの再生を完了したとき完了ステータスを前記サーバに送信する 手段とを備え、

前記サーバはさらに、

前記第 1のクライアントから完了ステータスを受信したとき、 前記第 1のクラ イアントが再生を完了したコンテンッの次のコンテンッを指定し、 その指定した コンテンツの再生を前記第 1のクライアントに命令する連続再生命令手段を備え たことを特^ ¾とするネットワーク型コンテンツ再生システム。

7 7. 請求項 7 6に記載のネットワーク型コンテンツ再生システムであって、 前記サーバはさらに、

前記第 1のクライアントにより再生されるべきコンテンツを列挙したコンテン ッリストを作成するために必要なリスト構築キーを記憶する手段と、 前記リスト構築キーに基づいて前記コンテンツリストを作成する手段とを備え、 前記連続再生命令手段は、 前記コンテンツリストに従って前記コンテンツの再 生を前記第 1のクライアントに命令することを特徴とするネットワーク型コンテ ンッ再生システム。

7 8 . サーバと、 前記サーバに接続された第 1のクライアントと、 前記サーバに 接続された第 2のクライアントとを備えたネットワーク型コンテンツ再生システ ムであって、

前記サーバは、

複数のコンテンツを蓄積するコンテンッ蓄積手段を備え、

前記第 2のクライアントは、

前記複数のコンテンツの中からコンテンツを指定し、 その指定したコンテンツ の再生を前記第 1のクライアントに命令する手段と、

前記第 1のクライアントにより再生されるべきコンテンツリストを作成するた めに必要なリスト構築キーを前記第 1のクライアントに送信する手段とを備え、 前記第 1のクライアントは、

前記第 2のクライアントからの命令に応じて前記指定されたコンテンツを再生 する手段と、

前記第 2のクライアントから送信されたリスト構築キーを前記サーバに送信す る手段とを備え、

前記サーバはさらに、

前記第 2のクライアントから送信されたリスト構築キーに基づいて前記コンテ ンッリストを作成し、 前記第 1のクライアントに送信する手段を備え、

前記第 1のクライアントはさらに、

前記サーバから送信されたコンテンツリストに従つて前記第 1のクライアント が再生を完了したコンテンツの次のコンテンツを再生する手段を備えたことを特 徴とするネットワーク型コンテンツ再生システム。

7 9 . 請求項 1〜請求項 7 8のいずれか 1項に記載のネットワーク型コンテンツ 再生システムであって、

前記コンテンッが音声及び/又は映像のデータであることを特徴とするネット ワーク型コンテンツ再生システム。

8 0 . 請求項 1〜請求項 7 9のいずれか 1項に記載のネットワーク型コンテンツ 再生システムを動作させるネットワーク型コンテンツ再生システム動作方法。 8 1 . 請求項 1〜請求項 7 9のいずれか 1項に記載の手段をコンピュータに実現 させるためのネットワーク型コンテンツ再生システム動作プログラム。

8 2 . 請求項 8 1に記載のネットワーク型コンテンツ再生システム動作プログラ ムを記憶したコンピュータ読み取り可能な記憶媒体。

8 3 . サーバと、 前記サーバに接続された少なくとも 1つの第 1のクライアント とを備えたネッ トワーク型コンテンッ再生システムにおける前記サーバであって、 複数のコンテンツを蓄積する蓄積手段と、

前記第 1のクライアントからの要求に応じて前記複数のコンテンツの中から選 択されたコンテンツを前記第 1のクライアントに返信するコンテンッ返信手段と を含むことを特徴とするネットワーク型コンテンツ再生システムにおけるサーバ。

8 4. 請求項 8 3に記載のサーバであってさらに、

前記第 1のクライアントからの要求に応じて複数のコンテンツを列挙したコン テンッリストを返信するコンテンツリスト返信手段を含むことを特徴とするネッ トワーク型コンテンッ再生システムにおけるサーバ。

8 5 . 請求項 8 4に記載のサーバであって、

前記コンテンツリスト返信手段は、 前記第 1のクライアントからの要求に応じ て指定量のコンテンツリストを返信することを特徴とするネットワーク型コンテ ンッ再生システムにおけるサーバ。

8 6 . 請求項 8 5に記載のサーバであって、

前記コンテンツリスト返信手段は、 前記第 1のクライアントが前記サーバから 取得しようとする最初のコンテンツを示す取得開始ィンデッタスと、 前記第 1の クライアントが前記サーバから取得しようとするコンテンツの数を示す取得個数 とを含む、 前記第 1のクライアントからのリスト要求コマンドに応答して、 前記 取得開始ィンデックスが示す最初のコンテンッから前記取得個数分のコンテンツ を含むコンテンツリストを返信することを特徴とするネットワーク型コンテンツ 再生システムにおけるサーバ。

8 7 . 請求項 8 6に記載のサーバであって、

前記コンテンツリスト返信手段はさらに、 前記返信するコンテンツリストに含 まれるコンテンツ数と、 前記返信するコンテンツリスト以降の残りのコンテンツ 数とを返信することを特徴とするネットワーク型コンテンッ再生システムにおけ るサーバ。

8 8 . 請求項 8 4〜請求項 8 7のいずれか 1項に記載のサーバであってさらに、 前記第 1のクライアントからの要求に応じて複数のカテゴリを列挙したカテゴ リリストを返信する手段を含むことを特徴とするネットワーク型コンテンツ再生 システムにおけるサーバ。

8 9 . 請求項 8 4〜請求項 8 8のいずれか 1項に記載のサーバであって、 前記コンテンツリスト返信手段は、 前記第 1のクライアントから送信されたリ スト構築キーに基づいて前記コンテンツリストを作成することを特徴とするネッ トワーク型コンテンツ再生システムにおけるサーバ。

9 0 . 請求項 8 3〜請求項 8 9のいずれか 1項に記載のサーバであって、 前記コンテンツ返信手段は、 前記第 1のクライアントからの要求に応じて予め 定められた量のコンテンツを繰り返し返信することにより前記コンテンツの全部 を返信することを特徴とするネットワーク型コンテンツ再生システムにおけるサ 一

9 1 . 請求項 9 0に記載のサーバであって、

前記コンテンツ返信手段は、 前記第 1のクライアントから送信された、 前記第 1のクライアントが前記サーバから取得しようとするコンテンツが格納されてい る最初のァドレスを示す取得開始ァドレスと、 前記第 1のクライアントが前記サ ーバから取得しようとするコンテンツの長さを示す取得データ長とを含むコンテ ンッ転送要求コマンドに応答して、 前記取得開始ァドレスから前記取得データ長 分のコンテンツを返信することを特徴とするネットワーク型コンテンツ再生シス テムにおけるサーバ。

9 2 . 請求項 9 0又は請求項 9 1に記載のサーバであってさらに、

前記第 1のクライアントから送信された、 前記選択されたコンテンツの識別情 報に応答して前記選択されたコンテンツのオフセットを前記第 1のクライアント に返信する手段を含むことを特徴とするネットワーク型コンテンツ再生システム におけるサーバ。

9 3 . 請求項 9 0〜請求項 9 2のいずれか 1項に記載のサーバであってさらに、 前記第 1のクライアントから送信された、 前記選択されたコンテンツの識別情 報に応答して前記選択されたコンテンツのサイズを前記第 1のクライアントに返 信する手段を含むことを特徴とするネットワーク型コンテンッ再生システムにお けるサーバ。

9 4 . 請求項 8 3〜請求項 9 3のいずれか 1項に記載のサーバであって、 前記ネ ットワーク型コンテンツ再生システムはさらに、 前記サーバに接続され、 前記第 1のクライアントを制御する第 2のクライアントを備え、

前記サーバはさらに、

前記第 2のクライアントからの要求に応じて前記第 1のクライアントを制御す る手段を含むことを特徴とするネットワーク型コンテンツ再生システムにおける サーバ。

9 5 . 請求項 8 3〜請求項 9 4のいずれか 1項に記載のサーバはさらに、

前記第 1のクライアントのファームウェアを更新するファームウェア更新手段 を含むことを特徴とするネットワーク型コンテンツ再生システムにおけるサーバ。 9 6 . 請求項 9 5に記載のサーバはさらに、

前記第 1のクライアントに適した複数のファームウェアの情報を登録する手段 と、

前記登録された複数のファームウェアの情報を列挙したファームゥヱァリスト を前記第 1のクライアントに送信するファームウェアリスト送信手段とを含み、 前記フアームウェア更新手段は、 前記第 1のクライアントからの要求に応じて 前記ファームゥヱアリストの中から選択されたファームウェアを前記第 1のクラ イアントに返信することを特徴とするネットワーク型コンテンツ再生システムに おけるサーバ。

9 7 . 請求項 9 5又は請求項 9 6に記載のサーバであって、

前記ファームゥェァ更新手段は、 前記第 1のクライアントにより要求された指 定量のファームウェアを前記第 1のクライアントに送信することを特徴とするネ ットワーク型コンテンツ再生システムにおけるサーバ。

9 8 . 請求項 9 7に記載のサーバであって、

前記ファームウェア更新手段は、 前記第 1のクライアントが取得しょうとする ファームウェアが格納されている最初のァドレスを示す取得開始ァドレス力 ら前 記第 1のクライアントが取得しょうとするファームゥヱァの長さを示す取得デー タ長分のファームウェアを返信することを特徴とするネットワーク型コンテンツ 再生システムにおけるサーバ。

9 9 . 請求項 9 6〜請求項 9 8のいずれか 1項に記載のサーバであって、

前記ファームウェアリスト送信手段は、 前記第 1のクライアントにより要求さ れた指定量のファームウェアリストを前記第 1のクライアントに送信することを 特徴とするネットワーク型コンテンツ再生システムにおけるサーバ。

1 0 0 . 請求項 9 9に記載のサーバであって、

前記ファームウェアリスト送信手段は、 前記第 1のクライアントが前記サーバ 力 ら取得しょうとする最初のフアームゥエア情報を示す取得開始ィンデッタスと、 前記第 1のクライアントが前記サーバから取得しようとするファームウェアの情 報の数を示す取得個数とを含む、 前記第 1のクライアントからのファームウェア リスト要求コマンドに応答して、 前記取得開始インデックスが示す最初のファー ムゥェァ情報から前記取得個数分のファームゥェァ情報を含むフアームウェアリ ストを前記第 1のクライアントに送信することを特徴とするネットワーク型コン テンッ再生システムにおけるサーバ。

1 0 1 . 請求項 8 3〜請求項 1 0 0のいずれか 1項に記載のネットワーク型コン テンッ再生システムにおけるサーバを動作させるサーバ動作方法。

1 0 2 . 請求項 8 3〜1 0 0のいずれか 1項に記載の手段をコンピュータに実現 させるためのサーバ動作プログラム。

1 0 3 . 請求項 1 0 2に記載のサーバ動作プログラムを記憶したコンピュータ読 み取り可能な記憶媒体。

1 0 4 . サーバと、 前記サーバに接続されたクライアントとを備えたネットヮー ク型コンテンツ再生システムにおける前記クライアントであって、

前記サーバに蓄積された複数のコンテンツの中から選択されたコンテンツを前 記サーバに要求するコンテンッ要求手段と、

前記要求に応じて前記サーバから返信されたコンテンッを再生する再生手段と を含むことを特徴とするネットワーク型コンテンッ再生システムにおけるクライ アント。

1 0 5 . 請求項 1 0 4に記載のクライアントであって、

壁に埋設されるコンセントボックスに取り付けられていることを特徴とするネ ットワーク型コンテンツ再生システムにおけるクライアント。

1 0 6 . 請求項 1 0 4又は請求項 1 0 5に記載のクライアントであってさらに、 複数のコンテンツを列挙したコンテンツリストを前記サーバに要求するコンテ ンッリスト要求手段と、

前記要求に応じて前記サーバから返信されたコンテンツリストを受信するコン テンッリスト受信手段とを含み、

前記コンテンツ要求手段は、 前記要求すべきコンテンツを前記コンテンツリス トの中から選択することを特徴とするネットワーク型コンテンツ再生システムに おけるクライアント。

1 0 7. 請求項 1 0 6に記載のクライアントであって、

前記コンテンツリスト要求手段は、 指定量のコンテンツリストを前記サーバに 要求することを特徴とするネットワーク型コンテンツ再生システムにおけるクラ

1 0 8 . 請求項 1 0 7に記載のクライアントであって、

前記コンテンツリスト要求手段は、 前記クライアントが前記サーバから取得し ようとする最初のコンテンツを示す取得開始ィンデッタスと、 前記クライアント が前記サーバから取得しようとするコンテンツの数を示す取得個数とを含むリス ト要求コマンドを送信し、

前記コンテンツリスト受信手段は、 前記リスト要求コマンドに応答して前記サ ーバから返信された、 前記取得開始ィンデックスが示す最初のコンテンツから前 記取得個数分のコンテンツを含むコンテンツリストを受信することを特徴とする ネットワーク型コンテンツ再生システムにおけるクライアント。

1 0 9 . 請求項 1 0 6〜請求項 1 0 8のいずれか 1項に記載のクライアントであ つてさらに、

複数のカテゴリを列挙したカテゴリリストを前記サーバに要求するカテゴリリ スト要求手段と、

前記要求に応じて前記サーバから返信されたカテゴリリストを受信する手段と を含み、

前記コンテンッリスト要求手段は、 要求しょうとするコンテンツリストのコン テンッが属するカテゴリを前記受信されたカテゴリリストの中から選択すること を特徴とするネットワーク型コンテンツ再生システムにおけるクライアント。

1 1 0 . 請求項 1 0 6〜請求項 1 0 9のいずれか 1項に記載のクライアントであ つてさらに、

前記コンテンツリスト要求手段は、 前記コンテンツリストを作成するために必 要なリスト構築キーを前記サーバに送信することを特徴とするネットワーク型コ ンテンッ再生システムにおけるクライアント。

1 1 1 . 請求項 1 0 4〜請求項 1 1 0のいずれか 1項に記載のクライアントであ つてさらに、

前記コンテンツ要求手段は、 予め定められた量のコンテンツを前記サーバに要 求し、 前記コンテンツの全部を取得するまで前記コンテンツの要求を繰り返すこ とを特徴とするネットワーク型コンテンツ再生システムにおけるクライアント。

1 1 2 . 請求項 1 1 1に記載のクライアントであってさらに、

前記サーバから返信されたコンテンッを蓄積するバッファメモリを備え、 前記コンテンツ要求手段は、 前記バッファメモリに所定量の空きが生じたとき 前記予め定められた量のコンテンツを前記サーバに要求することを特徴とするネ ットワーク型コンテンツ再生システムにおけるクライアント。

1 1 3 . 請求項 1 1 1又は請求項 1 1 2に記載のクライアントであって、 前記コンテンツ要求手段は、 前記予め定められた量のコンテンツの最初のアド レスを示す取得開始アドレスを算出し、 当該取得開始アドレスと、 前記クライァ ントが前記サーバから取得しょうとするコンテンツの長さを示す取得データ長と を含むコンテンッ転送要求コマンドを送信することを特徴とするネットワーク型 コンテンツ再生システムにおけるクライアント。

1 1 4 . 請求項 1 1 3に記載のクライアントであって、

前記コンテンツ要求手段は、 前記取得データ長を前の取得開始ァドレスに加算 して次の取得開始ァドレスを算出することを特徴とするネットワーク型コンテン ッ再生システムにおけるクライアント。

1 1 5 . 請求項 1 1 4に記載のクライアントであってさらに、

ユーザの操作に応じて第 1及び第 2のアドレスを設定する手段と、

前記算出された取得開始ァドレスが前記第 2のァドレスを超えたとき、 前記取 得開始ァドレスを前記第 1のアドレスに設定する手段とを含むことを特徴とする ネットワーク型コンテンツ再生システムにおけるクライアント。

1 1 6 . 請求項 1 1 4に記載のクライアントであってさらに、

ユーザの操作に応じて所望のァドレスを設定する手段と、

前記取得開始ァドレスを前記所望のァドレスに設定する手段とを含むことを特 徴とするネットワーク型コンテンツ再生システムにおけるクライアント。

1 1 7 . 請求項 1 1 3又は請求項 1 1 4に記載のクライアントであってさらに、 ユーザの操作に応じて所定のスキップ量を設定する手段と、

前記取得開始ァドレスを前記設定されたスキップ量だけシフトする手段とを含 むことを特徴とするネットワーク型コンテンツ再生システムにおけるクライアン

1 1 8 . 請求項 1 1 1〜請求項 1 1 7のいずれか 1項に記載のクライアントであ つてさらに、

前記選択されたコンテンツの識別情報を前記サーバに送信する手段と、 前記識別情報に応答して前記サーバから返信された、 前記選択されたコンテン ッのオフセットに基づいて前記選択されたコンテンツの始まりを検知する手段と を含むことを特徴とするネットワーク型コンテンツ再生システムにおけるクライ アント。

1 1 9 . 請求項 1 1 1〜請求項 1 1 8のいずれか 1項に記載のクライアントであ つてさらに、

前記選択されたコンテンツの識別情報を前記サーバに送信する手段と、 前記識別情報に応答して前記サーバから返信された、 前記選択されたコンテン ッのサイズに基づいて前記選択されたコンテンッの終わりを検知する手段とを含 むことを特徴とするネットワーク型コンテンツ再生システムにおけるクライアン h o

1 2 0 . 請求項 1 0 4〜請求項 1 1 0のいずれか 1項に記載のクライアントであ つて、

前記コンテンツ要求手段は、 要求するコンテンツの最初のァドレスを示す取得 開始ァドレスを算出して前記サーバに送信することを特徴とするネットワーク型 コンテンツ再生システムにおけるクライアント。

1 2 1 . 請求項 1 0 4〜請求項 1 1 0のいずれか 1項に記載のクライアントであ つて、

前記コンテンツ要求手段は、 指定量のコンテンツを前記サーバに要求し、 前記 指定量を変化させることを特徴とするネットワーク型コンテンツ再生システムに おけるクライアント。 1 2 2 . 請求項 1 0 4〜請求項 1 2 1のいずれか 1項に記 載のクライアントであってさらに、

自身に関するクライアント情報が変化するたびにそのクライアント情報を前記 サーバに送信する手段を含むことを特徴とするネットワーク型コンテンツ再生シ ステムにおけるクライアント。

1 2 3 . 請求項 1 0 4〜請求項 1 2 2に記載のいずれか 1項に記載のクライアン トであってさらに、

ファームゥエアの送信を前記サーバに要求するファームゥェァ要求手段とを含 むことを特徴とするネットワーク型コンテンツ再生システムにおけるクライアン

- o

1 2 4 . 請求項 1 2 3に記載のクライアントであってさらに、

前記サーバから送信されたファームウェアリストを受信する手段を含み、 前記ファームウェア要求手段は、 送信するファームウェアを前記受信されたフ アームゥヱアリストの中から選択することを特徴とするネットワーク型コンテン ッ再生システムにおけるクライアント。

1 2 5 . 請求項 1 2 3に記載のクライアントであって、

前記ファームウェア要求手段は、 指定量のファームウェアを前記サーバに要求 することを特徴とするネットワーク型コンテンツ再生システムにおけるクライア ント。

1 2 6 . 請求項 1 2 5に記載のクライアントであって、

前記ファームウェア要求手段は、 前記サーバから取得しょうとするファームゥ エアが格納されている最初のァドレスを示す取得開始ァドレスと、 前記サーバか ら取得しょうとするファームウェアの長さを示す取得データ長とを送信すること を特徴とするネットワーク型コンテンツ再生システムにおけるクライアント。 1 2 7 . 請求項 1 2 3〜請求項 1 2 6のいずれか 1項に記載のクライアントはさ らに、

指定量のファームウェアリストを前記サーバに要求するファームウェアリスト 要求手段を含むことを特徴とするネットワーク型コンテンツ再生システムにおけ

1 2 8 . 請求項 1 2 7に記載のクライアントであって、

前記ファームウェアリスト要求手段は、 前記サーバから取得しようとする最初 のファームゥエアの情報を示す取得開始ィンデッタスと、 前記サーバから取得し ようとするファームウェアの情報の数を示す取得個数とを含むファームウェアリ スト要求コマンドを送信することを特徴とするネットワーク型コンテンツ再生シ ステムにおけるクライアント。

1 2 9 . 請求項 1 0 4に記載のクライアントであって、 前記サーバは複数あり、 前記クライアントはさらに、

前記複数のサーバのいずれかと接続を行う接続手段と、

前記接続手段によるサーバとの接続が維持されているか否かを所定期間ごとに 判断する判断手段とを含み、

前記判断手段が前記サーバとの接続が切断されたと判断した場合に、 前記接続 手段は前記サーバとの再接続を実行することを特徴とするネットワーク型コンテ ンッ再生システムにおけるクライアント。

1 3 0 . 請求項 1 2 9に記載のクライアントであって、

前記接続手段は、 前記サーバとの再接続ができない場合に、 他のサーバとの接 続を実行することを特徴とするネットワーク型コンテンツ再生システムにおける

1 3 1 . 請求項 1 2 9又は請求項 1 3 0に記載のクライアントであって、 前記接続手段は接続が切断される前のクライアントステータスを接続したサー パに送信することを特徴とするネットワーク型コンテンツ再生システムにおける

1 3 2 . 請求項 1 0 4〜請求項 1 3 1のいずれか 1項に記載のネットワーク型コ ンテンッ再生システムにおけるクライアントを動作させるクライアント動作方法。 1 3 3 . 請求項 1 0 4〜請求項 1 3 1のいずれか 1項に記載の手段をコンビユー タに実現させるためのクライアント動作プログラム。

1 3 4 . 請求項 1 3 3に記載のクライアント動作プログラムを記憶したコンビュ ータ読み取り可能な記憶媒体。

1 3 5 . サーバと、 前記サーバに接続され、 前記サーバから取得したコンテンツ に基づいて前記コンテンツを再生する再生クライアントと、 前記サーバに接続さ れ、 前記再生クライアントを監視する監視クライアントとを備えたネットワーク 型コンテンツ再生システムにおける前記監視クライアントであって、

前記サーバから送信された前記再生クライアントのクライアント情報を受信す る手段と、

前記受信されたクライアント情報を表示する手段とを含むことを特徴とするネ ットワーク型コンテンツ再生システムにおける監視クライアント。

1 3 6 . 請求項 1 3 5に記載の監視クライアントであってさらに、

前記受信したクライアント情報が変更されているとき、 そのクライアント情報 の表示を変更する手段を含むことを特徴とするネットワーク型コンテンツ再生シ ステムにおける監視クライアント。

1 3 7 . 請求項 1 3 5又は請求項 1 3 6に記載の監視クライアントであって、 前記クライアント情報は、 前記再生クライアントにより再生可能なコンテンツ のデータフォーマツトの名称を含み、

前記監視クライアントはさらに、

前記受信されたクライアント情報に基づレ、て前記データフォーマットの名称を 表示する手段を含むことを特徴とするネットワーク型コンテンツ再生システムに おける監視クライアント。

1 3 8 . 請求項 1 3 7に記載の監視クライアントであってさらに、

複数のコンテンツを列挙したコンテンツリストを前記サーバから取得する手段 と、

前記取得したコンテンツリストに含まれるコンテンツのうち、 前記再生クライ アントにより再生可能なコンテンッを表示し、 前記再生クライアントにより再生 不可能なコンテンツを表示しないか又は前記再生可能なコンテンツと異なる態様 で表示する手段とを含むことを特徴とするネットワーク型コンテンツ再生システ ムにおける監視クライアント。

1 3 9 . 請求項 1 3 5〜請求項 1 3 8のいずれか 1項に記載の監視クライアント であってさらに、

監視しょうとするクライアントが前記再生クライアントかを判別する手段を含 むことを特徴とするネットワーク型コンテンツ再生システムにおける監視クライ アント。

1 4 0 . 請求項 1 3 5に記載の監視クライアントであってさらに、

前記再生クライアントを監視するために必要な監視ハンドルを取得する手段と、 前記監視ハンドルを取得したとき前記再生クライアントを監視する手段とを含 むことを特徴とするネットワーク型コンテンツ再生システムにおける監視クライ アント。

1 4 1 . 請求項 1 3 5〜請求項 1 4 0のいずれか 1項に記載のネットワーク型コ ンテンッ再生システムにおける監視クライアントを動作させる監視クライアント 動作方法。

1 4 2 . 請求項 1 3 5〜請求項 1 4 0のいずれか 1項に記載の手段をコンビユー タに実現させるための監視クライアント動作プログラム。

1 4 3 . 請求項 1 4 2に記載の監視クライアント動作プログラムを記憶したコン ピュータ読み取り可能な記憶媒体。