WO2003102919A1

WO2003102919A1 - Network type content reproduction system

Info

Publication number: WO2003102919A1
Application number: PCT/JP2003/006552
Authority: WO
Inventors: Fumiaki Kawamura; Youichi Kudoh; Susumu Takemura; Yasushi Ikeda; Toshinobu Sano; Hiroko Yoshizaki; Takahiro Chiba
Original assignee: Onkyo Corporation
Priority date: 2002-05-31
Filing date: 2003-05-26
Publication date: 2003-12-11
Also published as: US20050203991A1; CN1659623A; US7634532B2; CN100515076C; EP1508892B1; US20100049796A1; US8005928B2; CA2486671A1; JP2012190462A; EP1508892A4; AU2003241772A1; JP5673588B2; US8037177B2; US20110137985A1; US20120041999A1; JPWO2003102919A1; US7908370B2; EP1508892A1; JP4013949B2; US8516042B2

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のクライアントは、

前記サーバはさらに、

前記第 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のクライアントは、

前記サーバはさらに、

前記第 1のクライアントから完了ステータスを受信したとき、前記第 1のクライアントが再生を完了したコンテンッの次のコンテンッを指定し、その指定したコンテンツの再生を前記第 1のクライアントに命令する連続再生命令手段を備えたことを特^ ¾とするネットワーク型コンテンツ再生システム。

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

前記第 1のクライアントにより再生されるべきコンテンツを列挙したコンテンッリストを作成するために必要なリスト構築キーを記憶する手段と、前記リスト構築キーに基づいて前記コンテンツリストを作成する手段とを備え、前記連続再生命令手段は、前記コンテンツリストに従って前記コンテンツの再生を前記第 1のクライアントに命令することを特徴とするネットワーク型コンテンッ再生システム。

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

前記サーバは、

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

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

前記複数のコンテンツの中からコンテンツを指定し、その指定したコンテンツの再生を前記第 1のクライアントに命令する手段と、

前記第 1のクライアントにより再生されるべきコンテンツリストを作成するために必要なリスト構築キーを前記第 1のクライアントに送信する手段とを備え、前記第 1のクライアントは、

前記第 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に記載の監視クライアント動作プログラムを記憶したコンピュータ読み取り可能な記憶媒体。