JP3865139B2

JP3865139B2 - ネットワークａｖシステム

Info

Publication number: JP3865139B2
Application number: JP2003354522A
Authority: JP
Inventors: 年伸佐野; 進竹村; 泰池田
Original assignee: Onkyo Corp
Current assignee: Onkyo Corp
Priority date: 2003-10-15
Filing date: 2003-10-15
Publication date: 2007-01-10
Anticipated expiration: 2023-10-15
Also published as: DE602004008720D1; JP2005122335A; US20050086284A1; EP1524609B1; US7167879B2; DE602004008720T2; EP1524609A1

Description

本発明は、音声又は映像の再生が可能なネットワークＡＶ（Audio/Video）システムに関し、さらに詳しくは、サーバと、サーバに接続可能なクライアントと、サーバに接続可能なアップローダとを備えたネットワークＡＶシステムに関する。

最近、クライアントサーバシステムを利用したネットワークＡＶシステムが提供されている。下記の先行出願１及び２は、多数の曲データを蓄積したデータベースを有するサーバと、ＬＡＮ（Local Area Network）経由で接続されたオーディオクライアントとを備えたネットワークＡＶシステムを開示する。オーディオクライアントは所望の曲データをサーバに要求し、これに応じてサーバは要求された曲データをオーディオクライアントに配信する。オーディオクライアントはサーバから配信された曲データを再生する。

ネットワークＡＶシステムでは、アップローダによりサーバに新たな曲データを登録する。アップローダとは、サーバに曲データを登録させる機能を有する装置である。アップローダは、ネットワークを介してサーバと接続される。サーバに曲データを登録する場合、アップローダはサーバに登録要求を送信し、さらに登録する曲データを送信する。サーバは登録要求を受け、送信された曲データをデータベースに登録する。アップローダは単体で存在する場合もあるし、サーバ等の他の装置に含まれる場合もある。アップローダから送信された曲データを登録したサーバは、データベースが更新された旨（以下、更新通知と称する）をオーディオクライアントに送信する。

オーディオクライアントは更新通知を受けると、サーバが蓄積する曲データに関する曲情報を取得する。ここで、曲情報とは曲名やアーティスト名といった曲データを特定するための情報であり、曲データ自体は含まれない。オーディオクライアントは曲情報を取得し、曲情報に基づいてサーバに所望の曲データを要求する。

従来、アップローダにより複数の曲データをサーバに登録する場合、サーバは１曲登録するごとにオーディオクライアントに更新通知を送信していた。すなわち、サーバは登録する曲データの数と同じ更新通知をオーディオクライアントに送信していた。そのため、オーディオクライアントとサーバとの間で通信量が多くなっていた。

また、サーバが複数の曲データを登録することで、オーディオクライアントが複数の更新通知を受けた場合、オーディオクライアントは、更新通知に応じて曲情報を取得している最中に、新たな更新通知を受けることになる。この場合、オーディオクライアントは、曲情報の取得を中断して、改めて曲情報を再取得しなければならず、このことも通信量の増加を助長していた。

特開２０００−１１５１６５号公報

［先行出願１］ＰＣＴ／ＪＰ０３／０６５５２
［先行出願２］特願２００３−２９０３８４号

本発明の目的は、サーバがデータベースを更新したときのサーバとクライアントとの通信量を減らすことのできるネットワークＡＶシステムを提供することである。

本発明によるネットワークＡＶシステムは、複数のコンテンツを蓄積可能なデータベースを有するサーバと、サーバに接続可能であり、データベースをサーバに更新させるアップローダと、サーバに接続可能であり、複数のコンテンツの中から選択されたコンテンツをサーバから受け、選択されたコンテンツを再生するクライアントとを備える。アップローダは開始通知手段と更新要求手段と完了通知手段とを備える。開始通知手段は、要求開始通知をサーバに送信する。更新要求手段は、開始通知手段が要求開始通知を送信した後、サーバにデータベースを更新させるための複数の更新要求をサーバに送信する。完了通知手段は、更新要求手段が複数の更新要求を送信した後、要求完了通知をサーバに送信する。サーバは更新手段と更新通知手段とを備える。更新手段は、複数の更新要求を受け、各更新要求ごとにデータベースを更新する。更新通知手段は、要求開始通知を受けた場合、要求完了通知を受けて初めて、データベースが更新された旨の更新通知をクライアントに送信する。ここで、更新とは、データベースに新たなコンテンツを登録したり、データベース内のコンテンツの内容を変更したり、データベース内のコンテンツを削除したりすることをいう。

本発明によるネットワークＡＶシステムのサーバは、更新手段がデータベースを更新しても、アップローダから要求完了通知を受けるまでは、更新通知をクライアントに送信しない。よって、データベースを更新するごとに更新通知を送信していた従来のネットワークＡＶシステムと比較して、更新処理時のサーバとクライアントとの間での通信量を少なくできる。また、アップローダは複数の更新要求を送信した後に要求完了通知を送信する。そのため、サーバは連続してデータベースを更新した場合であっても、すべて更新した後に更新通知をクライアントに送信できる。

好ましくは、クライアントは取得手段と要求手段とを備える。取得手段は、更新通知を受けたとき選択されたコンテンツに関する情報をサーバから取得する。要求手段は、取得した情報に基づいて、選択されたコンテンツをサーバに要求する。ここで、コンテンツに関する情報とは、コンテンツ自体ではなく、コンテンツを特定するための情報である。たとえば、コンテンツが曲データの場合は、曲名やアーティスト名がコンテンツに関する情報となる。

サーバが連続してデータベースを更新する場合、従来は、クライアントは更新通知に応じてコンテンツに関する情報を取得している最中に、新たな更新通知を受ける。そのため、クライアントは情報の取得を中断して、改めて情報を取得しなければならなかった。本発明によるクライアントは、サーバがデータベースを更新し終えた後に、サーバから更新通知を受けるため、情報を取得している最中に新たに更新通知を受けることはない。その結果、通信量を少なくすることができる。

好ましくは、サーバはさらに判断手段を備える。判断手段は、データベースが更新されたか否かを判断する。更新通知手段は、データベースが更新されたと判断手段が判断したとき、更新通知を送信する。

この場合、サーバは仮に要求完了通知を受けても、データベースが更新されていない場合は更新通知を送信しない。よって、アップローダが誤動作等により、更新を要求することなく要求完了通知を送信しても、サーバは更新通知を送信しない。

本発明によるサーバは、複数のコンテンツを蓄積可能なデータベースを有するサーバと、サーバに接続可能であり、データベースをサーバに更新させるアップローダと、サーバに接続可能であり、複数のコンテンツの中から選択されたコンテンツをサーバから受け、選択されたコンテンツを再生するクライアントとを備えるネットワークＡＶシステムにおけるサーバであって、アップローダから要求開始通知を受ける手段と、更新手段と、アップローダから更新要求を完了する旨の要求完了通知を受ける手段と、更新通知手段とを備える。更新手段は、要求開始通知を受けた後、アップローダから送信される複数の更新要求を受け、各更新要求ごとにデータベースを更新する。更新通知手段は、要求開始通知を受けた場合、要求完了通知を受けて初めて、データベースが更新された旨の更新通知をクライアントに送信する。

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

１．ネットワークシステムの構成
図１を参照して、ネットワークＡＶシステム１は、サーバＳＶと、オーディオクライアントＣＬと、アップローダＵＬとを備える。

サーバＳＶは複数の曲データＭ１〜Ｍｎ（Ｎは自然数）を蓄積したデータベースＤＢを有する。サーバＳＶはオーディオクライアントＣＬの求めに応じて、データベースＤＢ内の複数の曲データＭ１〜Ｍｎのうち、オーディオクライアントＣＬのユーザが選択した曲データをオーディオクライアントＣＬに配信する。

オーディオクライアントＣＬはサーバＳＶから配信される曲データを再生する。オーディオクライアントＣＬはＬＡＮ１０を経由してサーバＳＶと接続される。

アップローダＵＬはサーバＳＶに新たな曲データを登録させたり、データベースＤＢ内の曲データＭｎの内容をサーバＳＶに変更させたり、データベースＤＢ内の曲データＭｎをサーバＳＶに削除させたりする。アップローダＵＬはＬＡＮ１０を経由してサーバＳＶと接続される。

図１では、サーバＳＶとオーディオクライアントＣＬとアップローダＵＬとはそれぞれ１つずつ示したが、それぞれがネットワーク１０上に複数存在していてもよい。

１．２．サーバの構成
図２を参照して、サーバＳＶ１は、ＨＤＤ（ハードディスクドライブ）１４と、データベース管理部１６及びネットワークプロトコル処理部１８を含むＣＰＵ処理部２０と、サーバＳＶとＬＡＮ１０との間で信号を送受信するＬＡＮコントローラ２２とを備える。ＨＤＤ１４は、データベースＤＢを保存する。データベースＤＢは複数の圧縮デジタル曲データＭ１〜Ｍｎを蓄積する。データベース管理部１６は、ＨＤＤ１４を管理する。具体的には、オーディオクライアントＣＬからの要求に応じ、ＨＤＤ１４から所望の曲データＭｎを選択する。また、アップローダＵＬからの要求に応じ、新たな曲データをＨＤＤ１４に登録したり、後述するＨＤＤ１４内の曲データＭｎの曲情報を変更したり、曲データＭｎを削除したりする。ネットワークプロトコル処理部１８は入出力されるデータをプロトコル処理する。

ＨＤＤ１４には表１に示す曲リスト（Music List）ＭＬが格納される。

表１を参照して、曲リストＭＬは、複数の曲情報Ｉ１〜Ｉｎを含む。曲情報Ｉ１〜Ｉｎは、ＨＤＤ１４内のデータベースＤＢに蓄積された複数の曲データＭ１〜Ｍｎに関する情報である。表２に曲情報Ｉｎの詳細を示す。

表２を参照して、曲情報Ｉｎはファイル名と、曲名と、アーティスト名と、アルバム名と、ジャンル名と、曲の長さ（時間）と、ファイルフォーマットと、曲ＩＤとを含む。ファイル名には、当該曲データＭｎが格納されているＨＤＤ１４のフルパス名が記録される。

サーバＳＶはさらに、ＨＤＤ１４に表３に示すクライアント情報ＣＬＩ（Client Information）を格納する。クライアント情報ＣＬＩはクライアント装置（オーディオクライアントＣＬ及びアップローダＵＬ）に関する情報である。

表３を参照して、クライアント情報ＣＬＩ中の「flag」は、サーバＳＶとの接続の有無を示す。接続がある場合、「flag」はセットされ、接続がない場合、「flag」はリセットされる。「type」はクライアントＣＬやアップローダＵＬといったクライアントタイプを示す。「status」は、再生、停止、完了、一時停止、早送り、巻き戻しなど、現在のステータス（動作状態）である。「停止」は、オーディオクライアントＣＬ自身での操作に応じて、選択された曲の再生を途中で止めた状態である。「完了」は、選択された曲を最後まで再生し終えた状態である。「volume」は現在のボリューム値（音量）を示す。「productid」は、クライアントタイプごとに付与されたプロダクトＩＤ（機種情報）である。同じタイプのクライアントＣＬには同じプロダクトＩＤが付与される。たとえば、オーディオクライアントＣＬには「１」、アップローダＵＬには「２」が付与される。「firmwareid」は、クライアント装置にインストールされているファームウェアのバージョンを示すファームウェアＩＤである。「hostname」は、クライアント装置に付与されたクライアント名である。「songID」は、再生中の曲を識別するための曲ＩＤである。「curKey」は、再生中の曲リストであるプレイリストＰＬを作成するために必要なリスト構築キーである。プレイリストＰＬについては後述する。

リスト構築キーは、フィルタの種類と、キーワードとを含む。フィルタの種類には、タイトル名、ジャンル名、アーティスト名、アルバム名、ファイル名などがある。たとえばフィルタの種類がアーティスト名の場合、キーワードには所望のアーティストの名称が記録される。リスト構築キーでＨＤＤ１４を検索することにより所望の曲リストＭＬを作成することができる。詳細は前述した先行出願１に開示されている。

なお、クライアント装置がアップローダＵＬの場合、表３中の「status」，「volume」，「songID」，「curKey」は登録されない。

１．３．オーディオクライアントの構成
図３を参照して、オーディオクライアントＣＬは、ネットワークプロトコル処理部２４及びシステム動作部２６を含むマイコン処理部２８と、フラッシュメモリ３０と、順次入力された圧縮デジタル曲データを一時的に記憶して順次出力するメモリ３２と、圧縮デジタル曲データをデコードして非圧縮デジタル曲データを生成する音声処理部３４と、デジタル曲データをアナログ曲データに変換するＤ／Ａ変換器（ＤＡＣ）３６と、本オーディオクライアントＣＬとＬＡＮ１０との間で信号を送受信するＬＡＮコントローラ３８とを備える。システム動作部２６はオーディオクライアントＣＬ全体を制御する。

オーディオクライアントＣＬは、サーバＳＶと異なり、曲データＭｎを蓄積するためのＨＤＤを備えていない。

１．４．アップローダの構成
図４を参照して、アップローダＵＬは、要求作成部４１とネットワークプロトコル処理部４２とを含むＣＰＵ処理部４０と、サーバＳＶに送信する１又は複数の曲データを記憶するＨＤＤ４４と、本アップローダＵＬとＬＡＮ１０との間で信号を送受信するＬＡＮコントローラ４３とを備える。要求作成部４１は、曲データの登録、変更、削除といった更新要求と、後述する要求開始通知及び要求完了通知とを作成する。なお、ＨＤＤ４４はメモリであってもよい。

２．ネットワークＡＶシステムの動作
２．１．アップローダが複数の曲データをサーバに登録させる場合
図５を参照して、本実施の形態によるネットワークＡＶシステム１で、アップローダＵＬが複数の曲データＭ１０〜Ｍ１ｎをサーバＳＶに登録させる場合、アップローダＵＬは初めに登録要求を開始する旨の要求開始通知をサーバＳＶに送信する（図中（１））。続いて、アップローダＵＬは複数の曲データＭ１０〜Ｍ１ｎの登録要求をサーバＳＶに送信する（図中（２））。このとき、アップローダＵＬは登録要求を曲データごとに送信する。サーバＳＶはアップローダＵＬからの複数の登録要求を受け、曲データＭ１０〜Ｍ１ｎをＨＤＤ１４内のデータベースＤＢに登録する（図中（３））。

アップローダＵＬは登録すべき曲データＭ１０〜Ｍ１ｎの全ての登録要求を送信した後、登録要求を完了した旨の要求完了通知をサーバＳＶに送信する（図中（４））。サーバＳＶは、アップローダＵＬからの要求完了通知を受け、オーディオクライアントＣＬに更新通知を送信する（図中（５））。

複数の曲データＭ１０〜Ｍ１ｎを連続してサーバＳＶに登録する場合、従来のサーバＳＶは１つの曲データＭ１ｎが登録されるごとにオーディオクライアントＣＬに更新通知を送信していた。具体的には、サーバＳＶは曲データＭ１０を登録した後に更新通知を出し、曲データＭ１１を登録した後に更新通知を出し、曲データＭ１ｎを登録した後に更新通知を出していた。本実施の形態によるネットワークＡＶシステムのサーバＳＶは、全ての曲データＭ１０〜Ｍ１ｎを登録した後に、１回だけ更新通知をオーディオクライアントＣＬに送信する。このため、サーバＳＶとオーディオクライアントＣＬとの間の通信量は減少する。以下、詳細を説明する。

２．１．１．サーバとの接続動作
アップローダＵＬがサーバＳＶに曲データＭ１０〜Ｍ１ｎを登録させる場合、初めにアップローダＵＬはサーバＳＶと接続を確立する。以下、アップローダＵＬによるサーバＳＶとの接続処理を説明するが、オーディオクライアントＣＬによるサーバＳＶとの接続処理も同じである。

図６を参照して、アップローダＵＬは、ＴＣＰ(Transmission Control Protocol)に従い、サーバＳＶのＩＰ（Internet Protocol）アドレス及びコマンドポートでソケットを生成し、このソケットでサーバＳＶに接続を要求する（Ｓ１０１）。コマンドポートは、アップローダＵＬからサーバＳＶへのコマンドを受信し、かつサーバＳＶからアップローダＵＬへの応答を送信するためのポートである。サーバＳＶはコマンドポートでの接続を受け付け（Ｓ２５１）、接続に成功した場合はステップＳ１０３に進む（Ｓ１０２）。これによりアップローダＵＬはサーバＳＶのコマンドポートに接続を確立する。

続いて、アップローダＵＬはコマンドポートにクライアントインデックス要求コマンドを送信する（Ｓ１０３）。サーバＳＶはクライアントインデックス要求コマンドに応答してコマンドポートからクライアントインデックスをアップローダＵＬに返信し（Ｓ２５２）、アップローダＵＬはこれを受信する（Ｓ１０４）。クライアントインデックス要求コマンドは、アップローダＵＬがサーバＳＶにクライアントインデックスを要求するコマンドである。クライアントインデックスは、サーバＳＶからアップローダＵＬに割り当てられる識別子（ＩＤ）である。

続いて、アップローダＵＬは、ＴＣＰに従い、サーバＳＶのＩＰアドレス及びプッシュポートでソケットを生成し、このソケットでサーバＳＶに接続を要求する（Ｓ１０５）。プッシュポートは、サーバＳＶからアップローダＵＬへの要求を送信するためのポートである。サーバＳＶはプッシュポートでの接続を受け付け（Ｓ２５３）、接続が成功した場合はステップＳ１０７に進む（Ｓ１０６）。これによりアップローダＵＬはサーバＳＶのプッシュポートに接続を確立する。ただし、この時点ではまだ、サーバＳＶはプッシュポートに接続された装置がアップローダＵＬなのかオーディオクライアントＣＬなのか特定できていない。そのため、アップローダＵＬはステップＳ１０４で受信したクライアントインデックスをサーバＳＶのプッシュポートに送信する（Ｓ１０７）。サーバＳＶはクライアントインデックスを受信し（Ｓ２５４）、これによりプッシュポートに接続された装置をアップローダＵＬと特定する。

２．１．２．曲データ更新動作
図７を参照して、アップローダＵＬが曲データＭ１０〜Ｍ１ｎをサーバＳＶに登録させる場合、初めにアップローダＵＬはサーバＳＶに要求開始通知を送信する（Ｓ２０１）。サーバＳＶは要求開始通知を受け、開始通知受信処理を行う（Ｓ２０２）。開始通知受信処理とは、サーバＳＶがアップローダＵＬから要求開始通知を受けたことを確認するための処理である。

アップローダＵＬは要求開始通知を送信した後、曲データＭ１０〜Ｍ１ｎの登録をサーバＳＶに要求する（Ｓ２０）。このとき、アップローダＵＬは曲データＭ１０〜Ｍ１ｎごとに更新要求を行う（Ｓ２０３）。具体的には、曲データＭ１０〜Ｍ１ｎをサーバＳＶに登録させるために、アップローダＵＬはサーバＳＶに対してｎ回更新要求を行う（Ｓ２０，Ｓ２０３）。サーバＳＶはアップローダＵＬから更新要求を受けるごとに更新処理を実行する（Ｓ２０４）。更新処理とは、ここでは、サーバＳＶが曲データＭ１ｎをＨＤＤ１４内データベースＤＢに登録する処理をいう。

アップローダＵＬは曲データＭ１０〜Ｍ１ｎの登録を要求した後（Ｓ２０）、要求完了通知をサーバＳＶに送信する（Ｓ２０５）。サーバＳＶは要求完了通知を受けた後、完了通知受信処理を実行する（Ｓ２０６）。具体的には、サーバＳＶは要求完了通知を受けたとき、アップローダＵＬからの更新要求が完了したと判断し、データベースＤＢが更新された旨の通知（更新通知）をオーディオクライアントＣＬ及びアップローダＵＬに送信する（Ｓ２０６）。オーディオクライアントＣＬ及びアップローダＵＬはそれぞれ更新通知を受信する（Ｓ２０７、Ｓ２０８）。以下、ステップＳ２０２の開始通知受信処理、ステップＳ２０３の更新要求処理、ステップＳ２０４の更新処理、ステップＳ２０６の完了通知受信処理について詳細を説明する。

［開始通知受信処理］
ステップＳ２０２では、アップローダＵＬからの要求開始通知を受け、サーバＳＶが要求開始通知を受けた状態であることを記憶する。具体的には、サーバＳＶはＨＤＤ１４に格納された更新ステータステーブルを更新する。

表４を参照して、更新ステータステーブルのステータス値が「０」のとき、サーバＳＶはアップローダＵＬから要求開始通知を受けていない状態である。ステータス値が「１」のとき、サーバＳＶはアップローダＵＬから要求開始通知を受けているが、データベースＤＢが未だ更新されていない状態である。ステータス値が「２」のとき、サーバＳＶは要求開始通知を受け、かつデータベースＤＢが更新された状態である。

図８を参照して、アップローダＵＬから要求開始通知を受けたとき、サーバＳＶは更新ステータステーブル内のステータス値が「０」であるか否かを判断する（Ｓ２０２１）。ステータス値が「０」の場合は、ステータス値を「１」に変更する（Ｓ２０２２）。これにより、サーバＳＶは自身が要求開始通知を受けていると判断できる。なお、ステップＳ２０２１での判断の結果、更新ステータスが「０」以外の場合、サーバＳＶはステータス値を変更せず、そのまま開始通知受信処理を終了する。

［更新要求処理及び更新処理］
図９を参照して、アップローダは曲データＭ１ｎの登録を要求する旨の更新要求をサーバＳＶに送信する（Ｓ２０３１）。このとき、アップローダＵＬは曲データＭ１ｎの曲情報Ｉ１ｎを更新要求に付加して送信する。

サーバＳＶは更新要求を受信し（Ｓ２０４１）、曲データＭ１ｎを格納するためにデータベースＤＢ内に新規曲ＩＤを登録する（Ｓ２０４２）。サーバＳＶは新規曲ＩＤをアップローダＵＬに送信する（Ｓ２０４３）。アップローダＵＬは新規曲ＩＤを受信し（Ｓ２０３２）、受信した新規曲ＩＤを付与した曲データＭ１ｎをサーバＳＶに送信する（Ｓ２０３３）。サーバＳＶは曲データＭ１ｎを受信し、データベースＤＢ内の新規曲ＩＤの領域に曲データＭ１ｎを登録する（Ｓ２０４４）。

曲データＭ１ｎを登録後、サーバＳＶは全曲データＭ１〜Ｍｎの曲リストＭＬを更新する（Ｓ２０４５）。具体的にはサーバＳＶは曲リストＭＬに曲データＭ１ｎの曲情報Ｉ１ｎを登録する。

曲リストＭＬを更新後、サーバＳＶは更新ステータステーブルの更新を行う（Ｓ２０４６〜Ｓ２０４９）。初めに、サーバＳＶは更新ステータステーブル内のステータス値が「０」である否かを判断する（Ｓ２０４６）。判断の結果、ステータス値が「０」でない場合、サーバＳＶはステータス値が「１」であるか否かを判断する（Ｓ２０４８）。本実施の形態では、サーバＳＶはアップローダＵＬから要求開始通知を受けているため（ステップＳ２０２）、ステータス値は通常「１」である。ステータス値が「１」である場合、サーバＳＶはステータス値を「２」に変更する（Ｓ２０４９）。つまり、サーバＳＶは自身が要求開始通知を受け、かつ曲データＭ１ｎの登録も行った状態であることを記憶する。

なお、サーバＳＶが２曲目以降の曲データＭ１１〜Ｍ１ｎを登録するときは、更新ステータステーブルのステータス値は既に「２」になっている。そのため、ステップＳ２０４８での判断の結果、ステータス値は「２」であるため、サーバＳＶはステータス値を変更することなく、そのまま更新処理を終了する。

［完了通知処理］
ステップＳ２０で複数の曲データＭ１０〜Ｍ１ｎがサーバＳＶのデータベースＤＢに登録された後、サーバＳＶは更新通知をオーディオクライアントＣＬ及びアップローダＵＬに送信する（Ｓ２０６）。図１０を参照して、サーバＳＶは更新ステータステーブル内のステータス値が「２」であるか否かを判断する（Ｓ２０６１）。判断の結果、ステータス値が「２」である場合、サーバＳＶはオーディオクライアントＣＬ及びアップローダＵＬに更新通知を送信する（Ｓ２０６２）。更新通知を送信後、サーバＳＶはステータス値を「０」に戻し（Ｓ２０６４）、完了通知処理を終了する。

一方、ステップＳ２０６１での判断の結果、ステータス値が「２」でない場合、サーバＳＶはさらにステータス値が「１」であるか否かを判断する（Ｓ２０６３）。判断の結果、ステータス値が「１」である場合、アップローダＵＬから要求開始通知を受けたものの、曲データＭ１ｎの登録がなかったことになる。よってこの場合は更新通知を送信せず、ステータス値を「０」に戻す（Ｓ２０６４）。なお、ステップＳ２０６３で判断の結果、更新ステータスが「１」でない場合、更新ステータス値は「０」であるため、サーバＳＶはそのまま完了通知処理を終了する。

以上の動作により、サーバＳＶはアップローダＵＬから要求完了通知を受けた後、つまり、複数の曲データＭ１０〜Ｍ１ｎを登録した後に更新通知を送信する。そのため、曲データＭ１ｎを登録するごとに更新通知を送信していた従来のネットワークＡＶシステムと比較して、サーバＳＶとオーディオクライアントＣＬとの間の通信量を減少させることができる。

さらに、サーバＳＶは更新ステータステーブルで、自身の状態を確認できる。具体的には、サーバＳＶが要求開始通知を受けたか否か、データベースＤＢを更新したか否かを更新ステータステーブルにより判断できる。その結果、要求開始通知を受けたものの、データベースＤＢが更新されてないといった場合に、要求完了通知が来ても、更新通知を送信しない。これにより、無駄な通信が発生するのを防止できる。

２．１．３．再生動作
図１１を参照して、サーバＳＶから更新通知を受けたオーディオクライアントＣＬは（Ｓ２０７）、プレイリストＰＬをサーバＳＶに要求する（Ｓ２１０）。プレイリストＰＬとは、サーバＳＶに登録されている曲リストＭＬの曲情報Ｉ１〜Ｉｎのうち、オーディオクライアントＣＬのユーザがリスト構築キーにより選択した１又は複数の曲情報Ｉｎをリストにしたものである。たとえば、オーディオクライアントＣＬのユーザがアーティストＰの曲を再生したい場合、ステップＳ２１０でオーディオクライアントＣＬは表５に示すリスト要求コマンドを送信する。

リスト要求コマンドは、リスト構築キーのフィルタ種類とキーワードとを含む。サーバＳＶはオーディオクライアントＣＬからのリスト要求コマンドを受け（Ｓ２１１）、リスト構築キーに基づいてプレイリストＰＬを作成する。具体的には、サーバＳＶはアーティスト名「Ｐ」の曲情報Ｉｎを曲リストＭＬから選択し、選択された１又は複数の曲情報Ｉｎに基づいてプレイリストＰＬを作成する。作成されたプレイリストＰＬはオーディオクライアントＣＬに送信される（Ｓ２１２）。なお、受信したリスト構築キーはサーバＳＶ内のクライアント情報ＣＬＩに登録される。

オーディオクライアントＣＬはプレイリストＰＬを受信し（Ｓ２１３）、プレイリストＰＬに基づいて、曲データＭｎを再生する曲再生処理を実行する（Ｓ３００）。このとき、サーバＳＶはオーディオクライアントＣＬからの要求に応じ、曲データＭｎをオーディオクライアントＣＬに配信する曲配信処理を実行する（Ｓ３１０）。以下、曲再生処理及び曲配信処理について詳細を説明する。

図１２を参照して、オーディオクライアントはコマンドポートを介して表６に示す曲データ転送要求コマンドを送信する（Ｓ３０１）。

この曲データ転送要求コマンドは、転送すべき曲データＭｎの取得開始アドレス及び取得データ長を含む。なお、曲データＭｎはたとえばプレイリストＰＬのリスト順に転送要求される。

サーバＳＶは曲データＭｎの転送要求コマンドに応答して、取得開始アドレスにより指定された先頭アドレスからその取得データ長分だけ曲データＭｎのデータをオーディオクライアントＣＬに配信する（Ｓ３１１）。オーディオクライアントＣＬは配信された曲データＭｎのデータをメモリ３２に格納する。メモリ３２は複数のバッファを含む。オーディオクライアントＣＬは曲データ転送要求コマンドで曲の先頭から１バッファ分（＝取得データ長）の曲データを取得して格納する（Ｓ３０２）。格納後、オーディオクライアントＣＬはメモリ３２のバッファが全て曲データで埋まったか判断し（Ｓ３０３）、バッファが全て埋まるまで曲データを取得して格納する。

ステップＳ３０１〜Ｓ３０３を繰り返し、バッファが曲データで全て埋まったら、オーディオクライアントＣＬは再生を開始する（Ｓ３０４）。具体的には、メモリ３２内の先頭バッファから曲データを音声処理部３４に出力し始める。曲データを出力して再生していると、やがて１バッファ分の空きが生じる。メモリ３２に空きが生じると（Ｓ３０５）、オーディオクライアントＣＬは再び曲データ転送要求をサーバＳＶに送信し（Ｓ３０６）、サーバＳＶは要求分の曲データを配信する（Ｓ３１２）。オーディオクライアントＣＬは配信された曲データをメモリ３２の空いたバッファに格納する（Ｓ３０７）。格納後、オーディオクライアントＣＬは曲データＭｎを全て受信したか否か確認する（Ｓ３０８）。曲データＭｎを全て受信していない場合、すなわち、サーバＳＶが曲データＭｎの全データを未だオーディオクライアントＣＬに送信していない場合、オーディオクライアントＣＬ及びサーバＳＶは再生によりメモリ３２に空きが生じるたびにステップＳ３０６、Ｓ３１２、Ｓ３０７を繰り返す。なお、上記では、バッファが曲データで全て埋まってから再生を開始しているが、全て埋まる前に再生し始めてもよい。

オーディオクライアントＣＬがサーバＳＶから曲データＭｎを全て受信した場合（Ｓ３０８）、オーディオクライアントＣＬは曲データＭｎを全て再生するまで再生動作を継続する（Ｓ３０９）。なお、曲データＭｎの再生が完了したら、オーディオクライアントＣＬはプレイリストＰＬに基づいて、次の曲データＭｎの転送要求をサーバＳＶに送信する。

２．２．アップローダが曲データを１つだけサーバに登録させる場合
再び図７を参照して、アップローダＵＬが曲データＭ１０だけをサーバＳＶに登録させる場合、ステップＳ２０での更新要求処理（Ｓ２０３）を１回だけ実行する。さらに、このとき、アップローダＵＬはステップＳ２０１の要求開始通知の送信を行わない。つまり、アップローダＵＬはステップＳ２０３の動作から開始する。そのため、サーバＳＶはステップＳ２０２の開始通知受信処理を行わず、更新ステータステーブルのステータス値は「０」のままとなる。このときのサーバＳＶの更新処理（Ｓ２０４）について説明する。

図９を参照して、サーバＳＶがアップローダＵＬから更新要求を受け、曲リストＭＬを更新するまでの動作（Ｓ２０４１〜Ｓ２０４５）は上記２．１．２．の場合（複数の曲データＭ１０〜Ｍ１ｎをサーバＳＶに登録させる場合）と同じである。

曲リストＭＬを更新後、サーバＳＶは更新ステータステーブルのステータス値が「０」であるか否かを判断する（Ｓ２０４６）。このとき、ステータス値は「０」であるため、サーバＳＶは更新通知をクライアントＣＬに送信する（Ｓ２０４７）。つまり、アップローダＵＬが１曲だけ曲データＭ１ｎを登録要求する場合、サーバＳＶは要求完了通知を受けなくても曲データＭ１ｎを登録すれば、更新通知を送信する。なお、このとき、アップローダＵＬは要求完了通知（Ｓ２０５）も送信しない。

１曲だけ曲データＭ１ｎを登録する場合にも、アップローダＵＬが要求開始通知や要求完了通知を送信したならば、かえってＬＡＮ１０上の通信量が増加してしまう。そこで、本実施の形態によるネットワークＳＶシステムでは、１曲だけ曲データＭ１ｎを登録する場合は、アップローダＵＬが要求開始通知や要求完了通知を送信しなくてもサーバＳＶが更新通知を送信できるようにすることで、通信量の増加を防ぐ。

なお、本実施の形態によるサーバＳＶは従来のアップローダにも対応できる。すなわち、従来のアップローダは要求開始通知や要求完了通知をサーバＳＶに送信しない。よって、サーバＳＶは従来のアップローダから複数の曲データＭ１０〜Ｍ１ｎの登録要求を受けた場合、１曲登録するごとに更新通知を送信する。

本実施の形態によるネットワークＡＶシステム１では、曲データＭ１ｎを登録する場合について説明したが、曲データＭｎの曲情報Ｉｎを変更する場合、曲データＭｎを削除する場合についても同様の動作を行う。なお、曲データＭｎを削除する場合の動作では、削除すべき曲データＭｎを特定すれば足りるので、アップローダＵＬは更新要求処理（Ｓ２０３）で曲データＭｎ自体を送ることはない。また、曲データＭｎの曲情報Ｉｎの変更の場合も、アップローダＵＬは曲データＭｎ自体を送信せず、要求開始通知を送信するときに（Ｓ２０１）、変更する曲情報Ｉｎを添付して送信する。

また、本実施の形態では、コンテンツを曲データとしたが、映像データであっても同じである。

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

本発明の実施の形態によるネットワークＡＶシステムの構成を示す機能ブロック図である。図１中のサーバの構成を示す機能ブロック図である。図１中のオーディオクライアントＣＬの構成を示す機能ブロック図である。図１中のアップローダの構成を示す機能ブロック図である。図１のネットワークＡＶシステムの動作を説明するための概略図である。図１中のアップローダのサーバへの接続動作を示すフロー図である。図１中のネットワークＡＶシステムの曲データ更新動作を示すフロー図である。図７中のステップＳ２０２の動作の詳細を示すフロー図である。図７中のＳ２１０の動作の詳細を示すフロー図である。図７中のステップＳ２０６の動作の詳細を示すフロー図である。図１中のネットワークＡＶシステムの再生動作を示すフロー図である。図１１中のステップＳ３００及びＳ３１０の動作の詳細を示すフロー図である。

符号の説明

１ネットワークＡＶシステム
１０ＬＡＮ
１４ＨＤＤ
１６データベース管理部
２０，４０ＣＰＵ処理部
２２，３８，４３ＬＡＮコントローラ
２８マイコン処理部
４１要求作成部
ＣＬオーディオクライアント
ＭＬ曲リスト
Ｍｎ曲データ
ＰＬプレイリスト
ＵＬアップローダ

Claims

複数のコンテンツを蓄積可能なデータベースを有するサーバと、
前記サーバに接続可能であり、前記データベースを前記サーバに更新させるアップローダと、
前記サーバに接続可能であり、前記複数のコンテンツの中から選択されたコンテンツを前記サーバから受け、前記選択されたコンテンツを再生するクライアントとを備え、
前記アップローダは、
要求開始通知を前記サーバに送信する開始通知手段と、
前記開始通知手段が要求開始通知を送信した後、前記サーバに前記データベースを更新させるための複数の更新要求を前記サーバに送信する更新要求手段と、
前記更新要求手段が前記複数の更新要求を送信した後、要求完了通知を前記サーバに送信する完了通知手段とを備え、
前記サーバは、
前記複数の更新要求を受け、各更新要求ごとに前記データベースを更新する更新手段と、
前記要求開始通知を受けた場合、前記要求完了通知を受けて初めて、前記データベースが更新された旨の更新通知を前記クライアントに送信する更新通知手段とを備えることを特徴とするネットワークＡＶシステム。
請求項１に記載のネットワークＡＶシステムであって、
前記クライアントは、
前記更新通知を受けたとき、前記選択されたコンテンツに関する情報を前記サーバから取得する取得手段と、
前記情報に基づいて、前記選択されたコンテンツを前記サーバに要求する要求手段とを備えることを特徴とするネットワークＡＶシステム。
請求項１又は請求項２に記載のネットワークＡＶシステムであって、
前記サーバはさらに、
前記データベースが更新されたか否かを判断する判断手段を備え、
前記更新通知手段は、前記データベースが更新されたと前記判断手段が判断したとき、前記更新通知を送信することを特徴とするネットワークＡＶシステム。
複数のコンテンツを蓄積可能なデータベースを有するサーバと、前記サーバに接続可能であり、前記データベースを前記サーバに更新させるアップローダと、前記サーバに接続可能であり、前記複数のコンテンツの中から選択されたコンテンツを前記サーバから受け、前記選択されたコンテンツを再生するクライアントとを備えるネットワークＡＶシステムにおける前記サーバであって、
前記アップローダから要求開始通知を受ける手段と、
前記要求開始通知を受けた後、前記アップローダから送信される複数の更新要求を受け、各更新要求ごとに前記データベースを更新する更新手段と、
前記アップローダから前記更新要求を完了する旨の要求完了通知を受ける手段と、
前記要求開始通知を受けた場合、前記要求完了通知を受けて初めて、前記データベースが更新された旨の更新通知を前記クライアントに送信する更新通知手段とを備えることを特徴とするサーバ。
請求項４に記載のサーバであってさらに、
前記データベースが更新されたか否かを判断する判断手段を備え、
前記更新通知手段は、前記データベースが更新されたと前記判断手段が判断したとき、前記更新通知を送信することを特徴とするサーバ。
請求項４又は請求項５に記載の手段をコンピュータに実行させるためのサーバプログラム。