ネットワークAVシステム
【課題】サーバがデータベースを更新したときのサーバとクライアントとの通信量を減らすことのできるネットワークAVシステムを提供する。
【解決手段】アップローダULは初めに登録要求を開始する旨の要求開始通知をサーバSVに送信し(1)、続いて、曲データM10〜M1nの複数の登録要求をサーバSVに送信する(2)。サーバSVはアップローダULからの複数の登録要求を受け、曲データM10〜M1nをHDD14内のデータベースDBに登録する(3)。アップローダULは全ての登録要求を送信した後、登録要求を完了した旨の要求完了通知をサーバSVに送信する(4)。サーバSVは、要求完了通知を受けた後、オーディオクライアントCLに更新通知を送信する(5)。
【解決手段】アップローダULは初めに登録要求を開始する旨の要求開始通知をサーバSVに送信し(1)、続いて、曲データM10〜M1nの複数の登録要求をサーバSVに送信する(2)。サーバSVはアップローダULからの複数の登録要求を受け、曲データM10〜M1nをHDD14内のデータベースDBに登録する(3)。アップローダULは全ての登録要求を送信した後、登録要求を完了した旨の要求完了通知をサーバSVに送信する(4)。サーバSVは、要求完了通知を受けた後、オーディオクライアントCLに更新通知を送信する(5)。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、音声又は映像の再生が可能なネットワークAV(Audio/Video)システムに関し、さらに詳しくは、サーバと、サーバに接続可能なクライアントと、サーバに接続可能なアップローダとを備えたネットワークAVシステムに関する。
【背景技術】
【0002】
最近、クライアントサーバシステムを利用したネットワークAVシステムが提供されている。下記の先行出願1及び2は、多数の曲データを蓄積したデータベースを有するサーバと、LAN(Local Area Network)経由で接続されたオーディオクライアントとを備えたネットワークAVシステムを開示する。オーディオクライアントは所望の曲データをサーバに要求し、これに応じてサーバは要求された曲データをオーディオクライアントに配信する。オーディオクライアントはサーバから配信された曲データを再生する。
【0003】
ネットワークAVシステムでは、アップローダによりサーバに新たな曲データを登録する。アップローダとは、サーバに曲データを登録させる機能を有する装置である。アップローダは、ネットワークを介してサーバと接続される。サーバに曲データを登録する場合、アップローダはサーバに登録要求を送信し、さらに登録する曲データを送信する。サーバは登録要求を受け、送信された曲データをデータベースに登録する。アップローダは単体で存在する場合もあるし、サーバ等の他の装置に含まれる場合もある。アップローダから送信された曲データを登録したサーバは、データベースが更新された旨(以下、更新通知と称する)をオーディオクライアントに送信する。
【0004】
オーディオクライアントは更新通知を受けると、サーバが蓄積する曲データに関する曲情報を取得する。ここで、曲情報とは曲名やアーティスト名といった曲データを特定するための情報であり、曲データ自体は含まれない。オーディオクライアントは曲情報を取得し、曲情報に基づいてサーバに所望の曲データを要求する。
【0005】
従来、アップローダにより複数の曲データをサーバに登録する場合、サーバは1曲登録するごとにオーディオクライアントに更新通知を送信していた。すなわち、サーバは登録する曲データの数と同じ更新通知をオーディオクライアントに送信していた。そのため、オーディオクライアントとサーバとの間で通信量が多くなっていた。
【0006】
また、サーバが複数の曲データを登録することで、オーディオクライアントが複数の更新通知を受けた場合、オーディオクライアントは、更新通知に応じて曲情報を取得している最中に、新たな更新通知を受けることになる。この場合、オーディオクライアントは、曲情報の取得を中断して、改めて曲情報を再取得しなければならず、このことも通信量の増加を助長していた。
【0007】
【特許文献1】特開2000−115165号公報
【0008】
[先行出願1]PCT/JP03/06552
[先行出願2]特願2003−290384号
【発明の開示】
【発明が解決しようとする課題】
【0009】
本発明の目的は、サーバがデータベースを更新したときのサーバとクライアントとの通信量を減らすことのできるネットワークAVシステムを提供することである。
【課題を解決するための手段】
【0010】
本発明によるネットワークAVシステムは、複数のコンテンツが蓄積されたデータベースを有するサーバと、サーバにネットワーク経由で接続され、データベースをサーバに更新させるアップローダと、サーバにネットワーク経由で接続され、複数のコンテンツの中から選択されたコンテンツをサーバから受け、選択されたコンテンツを再生するクライアントとを備える。アップローダは更新要求手段と完了通知手段とを備える。更新要求手段は、サーバにデータベースを更新させるための1又は複数の更新要求をサーバに送信する。完了通知手段は、更新要求手段が1又は複数の更新要求を送信した後、要求完了通知をサーバに送信する。サーバは更新手段と更新通知手段とを備える。更新手段は、1又は複数の更新要求に応じてデータベースを更新する。更新通知手段は、要求完了通知を受けた後、データベースが更新された旨の更新通知をクライアントに送信する。ここで、更新とは、データベースに新たなコンテンツを登録したり、データベース内のコンテンツの内容を変更したり、データベース内のコンテンツを削除したりすることをいう。
【0011】
本発明によるネットワークAVシステムのサーバは、更新手段がデータベースを更新しても、アップローダから要求完了通知を受けるまでは、更新通知をクライアントに送信しない。よって、データベースを更新するごとに更新通知を送信していた従来のネットワークAVシステムと比較して、更新処理時のサーバとクライアントとの間での通信量を少なくできる。また、アップローダは1又は複数の更新要求を送信した後に要求完了通知を送信する。そのため、サーバは連続してデータベースを更新した場合であっても、すべて更新した後に更新通知をクライアントに送信できる。
【0012】
好ましくは、クライアントは取得手段と要求手段とを備える。取得手段は、更新通知を受けたとき選択されたコンテンツに関する情報をサーバから取得する。要求手段は、取得した情報に基づいて、選択されたコンテンツをサーバに要求する。ここで、コンテンツに関する情報とは、コンテンツ自体ではなく、コンテンツを特定するための情報である。たとえば、コンテンツが曲データの場合は、曲名やアーティスト名がコンテンツに関する情報となる。
【0013】
サーバが連続してデータベースを更新する場合、従来は、クライアントは更新通知に応じてコンテンツに関する情報を取得している最中に、新たな更新通知を受ける。そのため、クライアントは情報の取得を中断して、改めて情報を取得しなければならなかった。本発明によるクライアントは、サーバがデータベースを更新し終えた後に、サーバから更新通知を受けるため、情報を取得している最中に新たに更新通知を受けることはない。その結果、通信量を少なくすることができる。
【0014】
好ましくは、アップローダはさらに、開始通知手段を備える。開始通知手段は、更新要求手段が複数の更新要求を送信する前に、要求開始通知をサーバに送信する。更新通知手段は、要求開始通知を受けた場合、要求完了通知を受けた後に更新通知を送信し、要求開始通知を受けることなく更新要求を受けた場合、更新手段が更新要求に応じてデータベースを更新した後に更新通知を送信する。
【0015】
アップローダが更新要求を1回だけサーバに送信する場合、たとえば、新たなコンテンツを1つだけサーバに登録するような場合、アップローダが要求開始通知や要求完了通知を送信したならば、かえって通信量が増加してしまう。そこで、アップローダが更新要求を1回だけサーバに送信する場合は、アップローダが要求開始通知を送信しなくてもサーバは更新要求に応じて更新通知を送信できる。
【0016】
好ましくは、サーバはさらに判断手段を備える。判断手段は、データベースが更新されたか否かを判断する。更新通知手段は、データベースが更新されたと判断手段が判断したとき、更新通知を送信する。
【0017】
この場合、サーバは仮に要求完了通知を受けても、データベースが更新されていない場合は更新通知を送信しない。よって、アップローダが誤動作等により、更新を要求することなく要求完了通知を送信しても、サーバは更新通知を送信しない。
【0018】
本発明によるサーバは、複数のコンテンツが蓄積されたデータベースを有するサーバと、サーバにネットワーク経由で接続され、データベースをサーバに更新させるアップローダと、サーバにネットワーク経由で接続され、複数のコンテンツの中から選択されたコンテンツをサーバから受け、選択されたコンテンツを再生するクライアントとを備えるネットワークAVシステムにおけるサーバであって、更新手段と、更新通知手段とを備える。更新手段は、アップローダから送信されるデータベースの更新要求に応じてデータベースを更新する。更新通知手段は、アップローダから更新要求を完了する旨の要求完了通知を受けた後、データベースが更新された旨の更新通知をクライアントに送信する。
【0019】
好ましくは、更新通知手段は、アップローダから更新要求を開始する旨の要求開始通知を受けた場合、要求完了通知を受けた後に更新通知を送信し、要求開始通知を受けることなく更新要求を受けた場合、更新手段が更新要求に応じてデータベースを更新した後に更新通知を送信する。
【0020】
本発明によるサーバは、要求開始通知や要求完了通知を送信しない従来のアップローダにも対応できる。具体的には、要求開始通知を受けることなく更新要求を受けた場合、サーバは更新要求を受けた後に更新通知をクライアントに送信する。よって、この場合、要求完了通知を受けなくても更新通知を送信できる。
【発明を実施するための最良の形態】
【0021】
以下、図面を参照し、本発明の実施の形態を詳しく説明する。図中同一又は相当部分には同一符号を付してその説明は繰り返さない。
【0022】
1.ネットワークシステムの構成
図1を参照して、ネットワークAVシステム1は、サーバSVと、オーディオクライアントCLと、アップローダULとを備える。
【0023】
サーバSVは複数の曲データM1〜Mn(Nは自然数)を蓄積したデータベースDBを有する。サーバSVはオーディオクライアントCLの求めに応じて、データベースDB内の複数の曲データM1〜Mnのうち、オーディオクライアントCLのユーザが選択した曲データをオーディオクライアントCLに配信する。
【0024】
オーディオクライアントCLはサーバSVから配信される曲データを再生する。オーディオクライアントCLはLAN10を経由してサーバSVと接続される。
【0025】
アップローダULはサーバSVに新たな曲データを登録させたり、データベースDB内の曲データMnの内容をサーバSVに変更させたり、データベースDB内の曲データMnをサーバSVに削除させたりする。アップローダULはLAN10を経由してサーバSVと接続される。
【0026】
図1では、サーバSVとオーディオクライアントCLとアップローダULとはそれぞれ1つずつ示したが、それぞれがネットワーク10上に複数存在していてもよい。
【0027】
1.2.サーバの構成
図2を参照して、サーバSV1は、HDD(ハードディスクドライブ)14と、データベース管理部16及びネットワークプロトコル処理部18を含むCPU処理部20と、サーバSVとLAN10との間で信号を送受信するLANコントローラ22とを備える。HDD14は、データベースDBを保存する。データベースDBは複数の圧縮デジタル曲データM1〜Mnを蓄積する。データベース管理部16は、HDD14を管理する。具体的には、オーディオクライアントCLからの要求に応じ、HDD14から所望の曲データMnを選択する。また、アップローダULからの要求に応じ、新たな曲データをHDD14に登録したり、後述するHDD14内の曲データMnの曲情報を変更したり、曲データMnを削除したりする。ネットワークプロトコル処理部18は入出力されるデータをプロトコル処理する。
【0028】
HDD14には表1に示す曲リスト(Music List)MLが格納される。
【表1】
【0029】
表1を参照して、曲リストMLは、複数の曲情報I1〜Inを含む。曲情報I1〜Inは、HDD14内のデータベースDBに蓄積された複数の曲データM1〜Mnに関する情報である。表2に曲情報Inの詳細を示す。
【表2】
【0030】
表2を参照して、曲情報Inはファイル名と、曲名と、アーティスト名と、アルバム名と、ジャンル名と、曲の長さ(時間)と、ファイルフォーマットと、曲IDとを含む。ファイル名には、当該曲データMnが格納されているHDD14のフルパス名が記録される。
【0031】
サーバSVはさらに、HDD14に表3に示すクライアント情報CLI(Client Information)を格納する。クライアント情報CLIはクライアント装置(オーディオクライアントCL及びアップローダUL)に関する情報である。
【表3】
【0032】
表3を参照して、クライアント情報CLI中の「flag」は、サーバSVとの接続の有無を示す。接続がある場合、「flag」はセットされ、接続がない場合、「flag」はリセットされる。「type」はクライアントCLやアップローダULといったクライアントタイプを示す。「status」は、再生、停止、完了、一時停止、早送り、巻き戻しなど、現在のステータス(動作状態)である。「停止」は、オーディオクライアントCL自身での操作に応じて、選択された曲の再生を途中で止めた状態である。「完了」は、選択された曲を最後まで再生し終えた状態である。「volume」は現在のボリューム値(音量)を示す。「productid」は、クライアントタイプごとに付与されたプロダクトID(機種情報)である。同じタイプのクライアントCLには同じプロダクトIDが付与される。たとえば、オーディオクライアントCLには「1」、アップローダULには「2」が付与される。「firmwareid」は、クライアント装置にインストールされているファームウェアのバージョンを示すファームウェアIDである。「hostname」は、クライアント装置に付与されたクライアント名である。「songID」は、再生中の曲を識別するための曲IDである。「curKey」は、再生中の曲リストであるプレイリストPLを作成するために必要なリスト構築キーである。プレイリストPLについては後述する。
【0033】
リスト構築キーは、フィルタの種類と、キーワードとを含む。フィルタの種類には、タイトル名、ジャンル名、アーティスト名、アルバム名、ファイル名などがある。たとえばフィルタの種類がアーティスト名の場合、キーワードには所望のアーティストの名称が記録される。リスト構築キーでHDD14を検索することにより所望の曲リストMLを作成することができる。詳細は前述した先行出願1に開示されている。
【0034】
なお、クライアント装置がアップローダULの場合、表3中の「status」,「volume」,「songID」,「curKey」は登録されない。
【0035】
1.3.オーディオクライアントの構成
図3を参照して、オーディオクライアントCLは、ネットワークプロトコル処理部24及びシステム動作部26を含むマイコン処理部28と、フラッシュメモリ30と、順次入力された圧縮デジタル曲データを一時的に記憶して順次出力するメモリ32と、圧縮デジタル曲データをデコードして非圧縮デジタル曲データを生成する音声処理部34と、デジタル曲データをアナログ曲データに変換するD/A変換器(DAC)36と、本オーディオクライアントCLとLAN10との間で信号を送受信するLANコントローラ38とを備える。システム動作部26はオーディオクライアントCL全体を制御する。
【0036】
オーディオクライアントCLは、サーバSVと異なり、曲データMnを蓄積するためのHDDを備えていない。
【0037】
1.4.アップローダの構成
図4を参照して、アップローダULは、要求作成部41とネットワークプロトコル処理部42とを含むCPU処理部40と、サーバSVに送信する1又は複数の曲データを記憶するHDD44と、本アップローダULとLAN10との間で信号を送受信するLANコントローラ43とを備える。要求作成部41は、曲データの登録、変更、削除といった更新要求と、後述する要求開始通知及び要求完了通知とを作成する。なお、HDD44はメモリであってもよい。
【0038】
2.ネットワークAVシステムの動作
2.1.アップローダが複数の曲データをサーバに登録させる場合
図5を参照して、本実施の形態によるネットワークAVシステム1で、アップローダULが複数の曲データM10〜M1nをサーバSVに登録させる場合、アップローダULは初めに登録要求を開始する旨の要求開始通知をサーバSVに送信する(図中(1))。続いて、アップローダULは複数の曲データM10〜M1nの登録要求をサーバSVに送信する(図中(2))。このとき、アップローダULは登録要求を曲データごとに送信する。サーバSVはアップローダULからの複数の登録要求を受け、曲データM10〜M1nをHDD14内のデータベースDBに登録する(図中(3))。
【0039】
アップローダULは登録すべき曲データM10〜M1nの全ての登録要求を送信した後、登録要求を完了した旨の要求完了通知をサーバSVに送信する(図中(4))。サーバSVは、アップローダULからの要求完了通知を受け、オーディオクライアントCLに更新通知を送信する(図中(5))。
【0040】
複数の曲データM10〜M1nを連続してサーバSVに登録する場合、従来のサーバSVは1つの曲データM1nが登録されるごとにオーディオクライアントCLに更新通知を送信していた。具体的には、サーバSVは曲データM10を登録した後に更新通知を出し、曲データM11を登録した後に更新通知を出し、曲データM1nを登録した後に更新通知を出していた。本実施の形態によるネットワークAVシステムのサーバSVは、全ての曲データM10〜M1nを登録した後に、1回だけ更新通知をオーディオクライアントCLに送信する。このため、サーバSVとオーディオクライアントCLとの間の通信量は減少する。以下、詳細を説明する。
【0041】
2.1.1.サーバとの接続動作
アップローダULがサーバSVに曲データM10〜M1nを登録させる場合、初めにアップローダULはサーバSVと接続を確立する。以下、アップローダULによるサーバSVとの接続処理を説明するが、オーディオクライアントCLによるサーバSVとの接続処理も同じである。
【0042】
図6を参照して、アップローダULは、TCP(Transmission Control Protocol)に従い、サーバSVのIP(Internet Protocol)アドレス及びコマンドポートでソケットを生成し、このソケットでサーバSVに接続を要求する(S101)。コマンドポートは、アップローダULからサーバSVへのコマンドを受信し、かつサーバSVからアップローダULへの応答を送信するためのポートである。サーバSVはコマンドポートでの接続を受け付け(S251)、接続に成功した場合はステップS103に進む(S102)。これによりアップローダULはサーバSVのコマンドポートに接続を確立する。
【0043】
続いて、アップローダULはコマンドポートにクライアントインデックス要求コマンドを送信する(S103)。サーバSVはクライアントインデックス要求コマンドに応答してコマンドポートからクライアントインデックスをアップローダULに返信し(S252)、アップローダULはこれを受信する(S104)。クライアントインデックス要求コマンドは、アップローダULがサーバSVにクライアントインデックスを要求するコマンドである。クライアントインデックスは、サーバSVからアップローダULに割り当てられる識別子(ID)である。
【0044】
続いて、アップローダULは、TCPに従い、サーバSVのIPアドレス及びプッシュポートでソケットを生成し、このソケットでサーバSVに接続を要求する(S105)。プッシュポートは、サーバSVからアップローダULへの要求を送信するためのポートである。サーバSVはプッシュポートでの接続を受け付け(S253)、接続が成功した場合はステップS107に進む(S106)。これによりアップローダULはサーバSVのプッシュポートに接続を確立する。ただし、この時点ではまだ、サーバSVはプッシュポートに接続された装置がアップローダULなのかオーディオクライアントCLなのか特定できていない。そのため、アップローダULはステップS104で受信したクライアントインデックスをサーバSVのプッシュポートに送信する(S107)。サーバSVはクライアントインデックスを受信し(S254)、これによりプッシュポートに接続された装置をアップローダULと特定する。
【0045】
2.1.2.曲データ更新動作
図7を参照して、アップローダULが曲データM10〜M1nをサーバSVに登録させる場合、初めにアップローダULはサーバSVに要求開始通知を送信する(S201)。サーバSVは要求開始通知を受け、開始通知受信処理を行う(S202)。開始通知受信処理とは、サーバSVがアップローダULから要求開始通知を受けたことを確認するための処理である。
【0046】
アップローダULは要求開始通知を送信した後、曲データM10〜M1nの登録をサーバSVに要求する(S20)。このとき、アップローダULは曲データM10〜M1nごとに更新要求を行う(S203)。具体的には、曲データM10〜M1nをサーバSVに登録させるために、アップローダULはサーバSVに対してn回更新要求を行う(S20,S203)。サーバSVはアップローダULから更新要求を受けるごとに更新処理を実行する(S204)。更新処理とは、ここでは、サーバSVが曲データM1nをHDD14内データベースDBに登録する処理をいう。
【0047】
アップローダULは曲データM10〜M1nの登録を要求した後(S20)、要求完了通知をサーバSVに送信する(S205)。サーバSVは要求完了通知を受けた後、完了通知受信処理を実行する(S206)。具体的には、サーバSVは要求完了通知を受けたとき、アップローダULからの更新要求が完了したと判断し、データベースDBが更新された旨の通知(更新通知)をオーディオクライアントCL及びアップローダULに送信する(S206)。オーディオクライアントCL及びアップローダULはそれぞれ更新通知を受信する(S207、S208)。以下、ステップS202の開始通知受信処理、ステップS203の更新要求処理、ステップS204の更新処理、ステップS206の完了通知受信処理について詳細を説明する。
【0048】
[開始通知受信処理]
ステップS202では、アップローダULからの要求開始通知を受け、サーバSVが要求開始通知を受けた状態であることを記憶する。具体的には、サーバSVはHDD14に格納された更新ステータステーブルを更新する。
【表4】
【0049】
表4を参照して、更新ステータステーブルのステータス値が「0」のとき、サーバSVはアップローダULから要求開始通知を受けていない状態である。ステータス値が「1」のとき、サーバSVはアップローダULから要求開始通知を受けているが、データベースDBが未だ更新されていない状態である。ステータス値が「2」のとき、サーバSVは要求開始通知を受け、かつデータベースDBが更新された状態である。
【0050】
図8を参照して、アップローダULから要求開始通知を受けたとき、サーバSVは更新ステータステーブル内のステータス値が「0」であるか否かを判断する(S2021)。ステータス値が「0」の場合は、ステータス値を「1」に変更する(S2022)。これにより、サーバSVは自身が要求開始通知を受けていると判断できる。なお、ステップS2021での判断の結果、更新ステータスが「0」以外の場合、サーバSVはステータス値を変更せず、そのまま開始通知受信処理を終了する。
【0051】
[更新要求処理及び更新処理]
図9を参照して、アップローダは曲データM1nの登録を要求する旨の更新要求をサーバSVに送信する(S2031)。このとき、アップローダULは曲データM1nの曲情報I1nを更新要求に付加して送信する。
【0052】
サーバSVは更新要求を受信し(S2041)、曲データM1nを格納するためにデータベースDB内に新規曲IDを登録する(S2042)。サーバSVは新規曲IDをアップローダULに送信する(S2043)。アップローダULは新規曲IDを受信し(S2032)、受信した新規曲IDを付与した曲データM1nをサーバSVに送信する(S2033)。サーバSVは曲データM1nを受信し、データベースDB内の新規曲IDの領域に曲データM1nを登録する(S2044)。
【0053】
曲データM1nを登録後、サーバSVは全曲データM1〜Mnの曲リストMLを更新する(S2045)。具体的にはサーバSVは曲リストMLに曲データM1nの曲情報I1nを登録する。
【0054】
曲リストMLを更新後、サーバSVは更新ステータステーブルの更新を行う(S2046〜S2049)。初めに、サーバSVは更新ステータステーブル内のステータス値が「0」である否かを判断する(S2046)。判断の結果、ステータス値が「0」でない場合、サーバSVはステータス値が「1」であるか否かを判断する(S2048)。本実施の形態では、サーバSVはアップローダULから要求開始通知を受けているため(ステップS202)、ステータス値は通常「1」である。ステータス値が「1」である場合、サーバSVはステータス値を「2」に変更する(S2049)。つまり、サーバSVは自身が要求開始通知を受け、かつ曲データM1nの登録も行った状態であることを記憶する。
【0055】
なお、サーバSVが2曲目以降の曲データM11〜M1nを登録するときは、更新ステータステーブルのステータス値は既に「2」になっている。そのため、ステップS2048での判断の結果、ステータス値は「2」であるため、サーバSVはステータス値を変更することなく、そのまま更新処理を終了する。
【0056】
[完了通知処理]
ステップS20で複数の曲データM10〜M1nがサーバSVのデータベースDBに登録された後、サーバSVは更新通知をオーディオクライアントCL及びアップローダULに送信する(S206)。図10を参照して、サーバSVは更新ステータステーブル内のステータス値が「2」であるか否かを判断する(S2061)。判断の結果、ステータス値が「2」である場合、サーバSVはオーディオクライアントCL及びアップローダULに更新通知を送信する(S2062)。更新通知を送信後、サーバSVはステータス値を「0」に戻し(S2064)、完了通知処理を終了する。
【0057】
一方、ステップS2061での判断の結果、ステータス値が「2」でない場合、サーバSVはさらにステータス値が「1」であるか否かを判断する(S2063)。判断の結果、ステータス値が「1」である場合、アップローダULから要求開始通知を受けたものの、曲データM1nの登録がなかったことになる。よってこの場合は更新通知を送信せず、ステータス値を「0」に戻す(S2064)。なお、ステップS2063で判断の結果、更新ステータスが「1」でない場合、更新ステータス値は「0」であるため、サーバSVはそのまま完了通知処理を終了する。
【0058】
以上の動作により、サーバSVはアップローダULから要求完了通知を受けた後、つまり、複数の曲データM10〜M1nを登録した後に更新通知を送信する。そのため、曲データM1nを登録するごとに更新通知を送信していた従来のネットワークAVシステムと比較して、サーバSVとオーディオクライアントCLとの間の通信量を減少させることができる。
【0059】
さらに、サーバSVは更新ステータステーブルで、自身の状態を確認できる。具体的には、サーバSVが要求開始通知を受けたか否か、データベースDBを更新したか否かを更新ステータステーブルにより判断できる。その結果、要求開始通知を受けたものの、データベースDBが更新されてないといった場合に、要求完了通知が来ても、更新通知を送信しない。これにより、無駄な通信が発生するのを防止できる。
【0060】
2.1.3.再生動作
図11を参照して、サーバSVから更新通知を受けたオーディオクライアントCLは(S207)、プレイリストPLをサーバSVに要求する(S210)。プレイリストPLとは、サーバSVに登録されている曲リストMLの曲情報I1〜Inのうち、オーディオクライアントCLのユーザがリスト構築キーにより選択した1又は複数の曲情報Inをリストにしたものである。たとえば、オーディオクライアントCLのユーザがアーティストPの曲を再生したい場合、ステップS210でオーディオクライアントCLは表5に示すリスト要求コマンドを送信する。
【表5】
【0061】
リスト要求コマンドは、リスト構築キーのフィルタ種類とキーワードとを含む。サーバSVはオーディオクライアントCLからのリスト要求コマンドを受け(S211)、リスト構築キーに基づいてプレイリストPLを作成する。具体的には、サーバSVはアーティスト名「P」の曲情報Inを曲リストMLから選択し、選択された1又は複数の曲情報Inに基づいてプレイリストPLを作成する。作成されたプレイリストPLはオーディオクライアントCLに送信される(S212)。なお、受信したリスト構築キーはサーバSV内のクライアント情報CLIに登録される。
【0062】
オーディオクライアントCLはプレイリストPLを受信し(S213)、プレイリストPLに基づいて、曲データMnを再生する曲再生処理を実行する(S300)。このとき、サーバSVはオーディオクライアントCLからの要求に応じ、曲データMnをオーディオクライアントCLに配信する曲配信処理を実行する(S310)。以下、曲再生処理及び曲配信処理について詳細を説明する。
【0063】
図12を参照して、オーディオクライアントはコマンドポートを介して表6に示す曲データ転送要求コマンドを送信する(S301)。
【表6】
【0064】
この曲データ転送要求コマンドは、転送すべき曲データMnの取得開始アドレス及び取得データ長を含む。なお、曲データMnはたとえばプレイリストPLのリスト順に転送要求される。
【0065】
サーバSVは曲データMnの転送要求コマンドに応答して、取得開始アドレスにより指定された先頭アドレスからその取得データ長分だけ曲データMnのデータをオーディオクライアントCLに配信する(S311)。オーディオクライアントCLは配信された曲データMnのデータをメモリ32に格納する。メモリ32は複数のバッファを含む。オーディオクライアントCLは曲データ転送要求コマンドで曲の先頭から1バッファ分(=取得データ長)の曲データを取得して格納する(S302)。格納後、オーディオクライアントCLはメモリ32のバッファが全て曲データで埋まったか判断し(S303)、バッファが全て埋まるまで曲データを取得して格納する。
【0066】
ステップS301〜S303を繰り返し、バッファが曲データで全て埋まったら、オーディオクライアントCLは再生を開始する(S304)。具体的には、メモリ32内の先頭バッファから曲データを音声処理部34に出力し始める。曲データを出力して再生していると、やがて1バッファ分の空きが生じる。メモリ32に空きが生じると(S305)、オーディオクライアントCLは再び曲データ転送要求をサーバSVに送信し(S306)、サーバSVは要求分の曲データを配信する(S312)。オーディオクライアントCLは配信された曲データをメモリ32の空いたバッファに格納する(S307)。格納後、オーディオクライアントCLは曲データMnを全て受信したか否か確認する(S308)。曲データMnを全て受信していない場合、すなわち、サーバSVが曲データMnの全データを未だオーディオクライアントCLに送信していない場合、オーディオクライアントCL及びサーバSVは再生によりメモリ32に空きが生じるたびにステップS306、S312、S307を繰り返す。なお、上記では、バッファが曲データで全て埋まってから再生を開始しているが、全て埋まる前に再生し始めてもよい。
【0067】
オーディオクライアントCLがサーバSVから曲データMnを全て受信した場合(S308)、オーディオクライアントCLは曲データMnを全て再生するまで再生動作を継続する(S309)。なお、曲データMnの再生が完了したら、オーディオクライアントCLはプレイリストPLに基づいて、次の曲データMnの転送要求をサーバSVに送信する。
【0068】
2.2.アップローダが曲データを1つだけサーバに登録させる場合
再び図7を参照して、アップローダULが曲データM10だけをサーバSVに登録させる場合、ステップS20での更新要求処理(S203)を1回だけ実行する。さらに、このとき、アップローダULはステップS201の要求開始通知の送信を行わない。つまり、アップローダULはステップS203の動作から開始する。そのため、サーバSVはステップS202の開始通知受信処理を行わず、更新ステータステーブルのステータス値は「0」のままとなる。このときのサーバSVの更新処理(S204)について説明する。
【0069】
図9を参照して、サーバSVがアップローダULから更新要求を受け、曲リストMLを更新するまでの動作(S2041〜S2045)は上記2.1.2.の場合(複数の曲データM10〜M1nをサーバSVに登録させる場合)と同じである。
【0070】
曲リストMLを更新後、サーバSVは更新ステータステーブルのステータス値が「0」であるか否かを判断する(S2046)。このとき、ステータス値は「0」であるため、サーバSVは更新通知をクライアントCLに送信する(S2047)。つまり、アップローダULが1曲だけ曲データM1nを登録要求する場合、サーバSVは要求完了通知を受けなくても曲データM1nを登録すれば、更新通知を送信する。なお、このとき、アップローダULは要求完了通知(S205)も送信しない。
【0071】
1曲だけ曲データM1nを登録する場合にも、アップローダULが要求開始通知や要求完了通知を送信したならば、かえってLAN10上の通信量が増加してしまう。そこで、本実施の形態によるネットワークSVシステムでは、1曲だけ曲データM1nを登録する場合は、アップローダULが要求開始通知や要求完了通知を送信しなくてもサーバSVが更新通知を送信できるようにすることで、通信量の増加を防ぐ。
【0072】
なお、本実施の形態によるサーバSVは従来のアップローダにも対応できる。すなわち、従来のアップローダは要求開始通知や要求完了通知をサーバSVに送信しない。よって、サーバSVは従来のアップローダから複数の曲データM10〜M1nの登録要求を受けた場合、1曲登録するごとに更新通知を送信する。
【0073】
本実施の形態によるネットワークAVシステム1では、曲データM1nを登録する場合について説明したが、曲データMnの曲情報Inを変更する場合、曲データMnを削除する場合についても同様の動作を行う。なお、曲データMnを削除する場合の動作では、削除すべき曲データMnを特定すれば足りるので、アップローダULは更新要求処理(S203)で曲データMn自体を送ることはない。また、曲データMnの曲情報Inの変更の場合も、アップローダULは曲データMn自体を送信せず、要求開始通知を送信するときに(S201)、変更する曲情報Inを添付して送信する。
【0074】
また、本実施の形態では、コンテンツを曲データとしたが、映像データであっても同じである。
【0075】
以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。
【図面の簡単な説明】
【0076】
【図1】本発明の実施の形態によるネットワークAVシステムの構成を示す機能ブロック図である。
【図2】図1中のサーバの構成を示す機能ブロック図である。
【図3】図1中のオーディオクライアントCLの構成を示す機能ブロック図である。
【図4】図1中のアップローダの構成を示す機能ブロック図である。
【図5】図1のネットワークAVシステムの動作を説明するための概略図である。
【図6】図1中のアップローダのサーバへの接続動作を示すフロー図である。
【図7】図1中のネットワークAVシステムの曲データ更新動作を示すフロー図である。
【図8】図7中のステップS202の動作の詳細を示すフロー図である。
【図9】図7中のS210の動作の詳細を示すフロー図である。
【図10】図7中のステップS206の動作の詳細を示すフロー図である。
【図11】図1中のネットワークAVシステムの再生動作を示すフロー図である。
【図12】図11中のステップS300及びS310の動作の詳細を示すフロー図である。
【符号の説明】
【0077】
1 ネットワークAVシステム
10 LAN
14 HDD
16 データベース管理部
20,40 CPU処理部
22,38,43 LANコントローラ
28 マイコン処理部
41 要求作成部
CL オーディオクライアント
ML 曲リスト
Mn 曲データ
PL プレイリスト
UL アップローダ
【技術分野】
【0001】
本発明は、音声又は映像の再生が可能なネットワークAV(Audio/Video)システムに関し、さらに詳しくは、サーバと、サーバに接続可能なクライアントと、サーバに接続可能なアップローダとを備えたネットワークAVシステムに関する。
【背景技術】
【0002】
最近、クライアントサーバシステムを利用したネットワークAVシステムが提供されている。下記の先行出願1及び2は、多数の曲データを蓄積したデータベースを有するサーバと、LAN(Local Area Network)経由で接続されたオーディオクライアントとを備えたネットワークAVシステムを開示する。オーディオクライアントは所望の曲データをサーバに要求し、これに応じてサーバは要求された曲データをオーディオクライアントに配信する。オーディオクライアントはサーバから配信された曲データを再生する。
【0003】
ネットワークAVシステムでは、アップローダによりサーバに新たな曲データを登録する。アップローダとは、サーバに曲データを登録させる機能を有する装置である。アップローダは、ネットワークを介してサーバと接続される。サーバに曲データを登録する場合、アップローダはサーバに登録要求を送信し、さらに登録する曲データを送信する。サーバは登録要求を受け、送信された曲データをデータベースに登録する。アップローダは単体で存在する場合もあるし、サーバ等の他の装置に含まれる場合もある。アップローダから送信された曲データを登録したサーバは、データベースが更新された旨(以下、更新通知と称する)をオーディオクライアントに送信する。
【0004】
オーディオクライアントは更新通知を受けると、サーバが蓄積する曲データに関する曲情報を取得する。ここで、曲情報とは曲名やアーティスト名といった曲データを特定するための情報であり、曲データ自体は含まれない。オーディオクライアントは曲情報を取得し、曲情報に基づいてサーバに所望の曲データを要求する。
【0005】
従来、アップローダにより複数の曲データをサーバに登録する場合、サーバは1曲登録するごとにオーディオクライアントに更新通知を送信していた。すなわち、サーバは登録する曲データの数と同じ更新通知をオーディオクライアントに送信していた。そのため、オーディオクライアントとサーバとの間で通信量が多くなっていた。
【0006】
また、サーバが複数の曲データを登録することで、オーディオクライアントが複数の更新通知を受けた場合、オーディオクライアントは、更新通知に応じて曲情報を取得している最中に、新たな更新通知を受けることになる。この場合、オーディオクライアントは、曲情報の取得を中断して、改めて曲情報を再取得しなければならず、このことも通信量の増加を助長していた。
【0007】
【特許文献1】特開2000−115165号公報
【0008】
[先行出願1]PCT/JP03/06552
[先行出願2]特願2003−290384号
【発明の開示】
【発明が解決しようとする課題】
【0009】
本発明の目的は、サーバがデータベースを更新したときのサーバとクライアントとの通信量を減らすことのできるネットワークAVシステムを提供することである。
【課題を解決するための手段】
【0010】
本発明によるネットワークAVシステムは、複数のコンテンツが蓄積されたデータベースを有するサーバと、サーバにネットワーク経由で接続され、データベースをサーバに更新させるアップローダと、サーバにネットワーク経由で接続され、複数のコンテンツの中から選択されたコンテンツをサーバから受け、選択されたコンテンツを再生するクライアントとを備える。アップローダは更新要求手段と完了通知手段とを備える。更新要求手段は、サーバにデータベースを更新させるための1又は複数の更新要求をサーバに送信する。完了通知手段は、更新要求手段が1又は複数の更新要求を送信した後、要求完了通知をサーバに送信する。サーバは更新手段と更新通知手段とを備える。更新手段は、1又は複数の更新要求に応じてデータベースを更新する。更新通知手段は、要求完了通知を受けた後、データベースが更新された旨の更新通知をクライアントに送信する。ここで、更新とは、データベースに新たなコンテンツを登録したり、データベース内のコンテンツの内容を変更したり、データベース内のコンテンツを削除したりすることをいう。
【0011】
本発明によるネットワークAVシステムのサーバは、更新手段がデータベースを更新しても、アップローダから要求完了通知を受けるまでは、更新通知をクライアントに送信しない。よって、データベースを更新するごとに更新通知を送信していた従来のネットワークAVシステムと比較して、更新処理時のサーバとクライアントとの間での通信量を少なくできる。また、アップローダは1又は複数の更新要求を送信した後に要求完了通知を送信する。そのため、サーバは連続してデータベースを更新した場合であっても、すべて更新した後に更新通知をクライアントに送信できる。
【0012】
好ましくは、クライアントは取得手段と要求手段とを備える。取得手段は、更新通知を受けたとき選択されたコンテンツに関する情報をサーバから取得する。要求手段は、取得した情報に基づいて、選択されたコンテンツをサーバに要求する。ここで、コンテンツに関する情報とは、コンテンツ自体ではなく、コンテンツを特定するための情報である。たとえば、コンテンツが曲データの場合は、曲名やアーティスト名がコンテンツに関する情報となる。
【0013】
サーバが連続してデータベースを更新する場合、従来は、クライアントは更新通知に応じてコンテンツに関する情報を取得している最中に、新たな更新通知を受ける。そのため、クライアントは情報の取得を中断して、改めて情報を取得しなければならなかった。本発明によるクライアントは、サーバがデータベースを更新し終えた後に、サーバから更新通知を受けるため、情報を取得している最中に新たに更新通知を受けることはない。その結果、通信量を少なくすることができる。
【0014】
好ましくは、アップローダはさらに、開始通知手段を備える。開始通知手段は、更新要求手段が複数の更新要求を送信する前に、要求開始通知をサーバに送信する。更新通知手段は、要求開始通知を受けた場合、要求完了通知を受けた後に更新通知を送信し、要求開始通知を受けることなく更新要求を受けた場合、更新手段が更新要求に応じてデータベースを更新した後に更新通知を送信する。
【0015】
アップローダが更新要求を1回だけサーバに送信する場合、たとえば、新たなコンテンツを1つだけサーバに登録するような場合、アップローダが要求開始通知や要求完了通知を送信したならば、かえって通信量が増加してしまう。そこで、アップローダが更新要求を1回だけサーバに送信する場合は、アップローダが要求開始通知を送信しなくてもサーバは更新要求に応じて更新通知を送信できる。
【0016】
好ましくは、サーバはさらに判断手段を備える。判断手段は、データベースが更新されたか否かを判断する。更新通知手段は、データベースが更新されたと判断手段が判断したとき、更新通知を送信する。
【0017】
この場合、サーバは仮に要求完了通知を受けても、データベースが更新されていない場合は更新通知を送信しない。よって、アップローダが誤動作等により、更新を要求することなく要求完了通知を送信しても、サーバは更新通知を送信しない。
【0018】
本発明によるサーバは、複数のコンテンツが蓄積されたデータベースを有するサーバと、サーバにネットワーク経由で接続され、データベースをサーバに更新させるアップローダと、サーバにネットワーク経由で接続され、複数のコンテンツの中から選択されたコンテンツをサーバから受け、選択されたコンテンツを再生するクライアントとを備えるネットワークAVシステムにおけるサーバであって、更新手段と、更新通知手段とを備える。更新手段は、アップローダから送信されるデータベースの更新要求に応じてデータベースを更新する。更新通知手段は、アップローダから更新要求を完了する旨の要求完了通知を受けた後、データベースが更新された旨の更新通知をクライアントに送信する。
【0019】
好ましくは、更新通知手段は、アップローダから更新要求を開始する旨の要求開始通知を受けた場合、要求完了通知を受けた後に更新通知を送信し、要求開始通知を受けることなく更新要求を受けた場合、更新手段が更新要求に応じてデータベースを更新した後に更新通知を送信する。
【0020】
本発明によるサーバは、要求開始通知や要求完了通知を送信しない従来のアップローダにも対応できる。具体的には、要求開始通知を受けることなく更新要求を受けた場合、サーバは更新要求を受けた後に更新通知をクライアントに送信する。よって、この場合、要求完了通知を受けなくても更新通知を送信できる。
【発明を実施するための最良の形態】
【0021】
以下、図面を参照し、本発明の実施の形態を詳しく説明する。図中同一又は相当部分には同一符号を付してその説明は繰り返さない。
【0022】
1.ネットワークシステムの構成
図1を参照して、ネットワークAVシステム1は、サーバSVと、オーディオクライアントCLと、アップローダULとを備える。
【0023】
サーバSVは複数の曲データM1〜Mn(Nは自然数)を蓄積したデータベースDBを有する。サーバSVはオーディオクライアントCLの求めに応じて、データベースDB内の複数の曲データM1〜Mnのうち、オーディオクライアントCLのユーザが選択した曲データをオーディオクライアントCLに配信する。
【0024】
オーディオクライアントCLはサーバSVから配信される曲データを再生する。オーディオクライアントCLはLAN10を経由してサーバSVと接続される。
【0025】
アップローダULはサーバSVに新たな曲データを登録させたり、データベースDB内の曲データMnの内容をサーバSVに変更させたり、データベースDB内の曲データMnをサーバSVに削除させたりする。アップローダULはLAN10を経由してサーバSVと接続される。
【0026】
図1では、サーバSVとオーディオクライアントCLとアップローダULとはそれぞれ1つずつ示したが、それぞれがネットワーク10上に複数存在していてもよい。
【0027】
1.2.サーバの構成
図2を参照して、サーバSV1は、HDD(ハードディスクドライブ)14と、データベース管理部16及びネットワークプロトコル処理部18を含むCPU処理部20と、サーバSVとLAN10との間で信号を送受信するLANコントローラ22とを備える。HDD14は、データベースDBを保存する。データベースDBは複数の圧縮デジタル曲データM1〜Mnを蓄積する。データベース管理部16は、HDD14を管理する。具体的には、オーディオクライアントCLからの要求に応じ、HDD14から所望の曲データMnを選択する。また、アップローダULからの要求に応じ、新たな曲データをHDD14に登録したり、後述するHDD14内の曲データMnの曲情報を変更したり、曲データMnを削除したりする。ネットワークプロトコル処理部18は入出力されるデータをプロトコル処理する。
【0028】
HDD14には表1に示す曲リスト(Music List)MLが格納される。
【表1】
【0029】
表1を参照して、曲リストMLは、複数の曲情報I1〜Inを含む。曲情報I1〜Inは、HDD14内のデータベースDBに蓄積された複数の曲データM1〜Mnに関する情報である。表2に曲情報Inの詳細を示す。
【表2】
【0030】
表2を参照して、曲情報Inはファイル名と、曲名と、アーティスト名と、アルバム名と、ジャンル名と、曲の長さ(時間)と、ファイルフォーマットと、曲IDとを含む。ファイル名には、当該曲データMnが格納されているHDD14のフルパス名が記録される。
【0031】
サーバSVはさらに、HDD14に表3に示すクライアント情報CLI(Client Information)を格納する。クライアント情報CLIはクライアント装置(オーディオクライアントCL及びアップローダUL)に関する情報である。
【表3】
【0032】
表3を参照して、クライアント情報CLI中の「flag」は、サーバSVとの接続の有無を示す。接続がある場合、「flag」はセットされ、接続がない場合、「flag」はリセットされる。「type」はクライアントCLやアップローダULといったクライアントタイプを示す。「status」は、再生、停止、完了、一時停止、早送り、巻き戻しなど、現在のステータス(動作状態)である。「停止」は、オーディオクライアントCL自身での操作に応じて、選択された曲の再生を途中で止めた状態である。「完了」は、選択された曲を最後まで再生し終えた状態である。「volume」は現在のボリューム値(音量)を示す。「productid」は、クライアントタイプごとに付与されたプロダクトID(機種情報)である。同じタイプのクライアントCLには同じプロダクトIDが付与される。たとえば、オーディオクライアントCLには「1」、アップローダULには「2」が付与される。「firmwareid」は、クライアント装置にインストールされているファームウェアのバージョンを示すファームウェアIDである。「hostname」は、クライアント装置に付与されたクライアント名である。「songID」は、再生中の曲を識別するための曲IDである。「curKey」は、再生中の曲リストであるプレイリストPLを作成するために必要なリスト構築キーである。プレイリストPLについては後述する。
【0033】
リスト構築キーは、フィルタの種類と、キーワードとを含む。フィルタの種類には、タイトル名、ジャンル名、アーティスト名、アルバム名、ファイル名などがある。たとえばフィルタの種類がアーティスト名の場合、キーワードには所望のアーティストの名称が記録される。リスト構築キーでHDD14を検索することにより所望の曲リストMLを作成することができる。詳細は前述した先行出願1に開示されている。
【0034】
なお、クライアント装置がアップローダULの場合、表3中の「status」,「volume」,「songID」,「curKey」は登録されない。
【0035】
1.3.オーディオクライアントの構成
図3を参照して、オーディオクライアントCLは、ネットワークプロトコル処理部24及びシステム動作部26を含むマイコン処理部28と、フラッシュメモリ30と、順次入力された圧縮デジタル曲データを一時的に記憶して順次出力するメモリ32と、圧縮デジタル曲データをデコードして非圧縮デジタル曲データを生成する音声処理部34と、デジタル曲データをアナログ曲データに変換するD/A変換器(DAC)36と、本オーディオクライアントCLとLAN10との間で信号を送受信するLANコントローラ38とを備える。システム動作部26はオーディオクライアントCL全体を制御する。
【0036】
オーディオクライアントCLは、サーバSVと異なり、曲データMnを蓄積するためのHDDを備えていない。
【0037】
1.4.アップローダの構成
図4を参照して、アップローダULは、要求作成部41とネットワークプロトコル処理部42とを含むCPU処理部40と、サーバSVに送信する1又は複数の曲データを記憶するHDD44と、本アップローダULとLAN10との間で信号を送受信するLANコントローラ43とを備える。要求作成部41は、曲データの登録、変更、削除といった更新要求と、後述する要求開始通知及び要求完了通知とを作成する。なお、HDD44はメモリであってもよい。
【0038】
2.ネットワークAVシステムの動作
2.1.アップローダが複数の曲データをサーバに登録させる場合
図5を参照して、本実施の形態によるネットワークAVシステム1で、アップローダULが複数の曲データM10〜M1nをサーバSVに登録させる場合、アップローダULは初めに登録要求を開始する旨の要求開始通知をサーバSVに送信する(図中(1))。続いて、アップローダULは複数の曲データM10〜M1nの登録要求をサーバSVに送信する(図中(2))。このとき、アップローダULは登録要求を曲データごとに送信する。サーバSVはアップローダULからの複数の登録要求を受け、曲データM10〜M1nをHDD14内のデータベースDBに登録する(図中(3))。
【0039】
アップローダULは登録すべき曲データM10〜M1nの全ての登録要求を送信した後、登録要求を完了した旨の要求完了通知をサーバSVに送信する(図中(4))。サーバSVは、アップローダULからの要求完了通知を受け、オーディオクライアントCLに更新通知を送信する(図中(5))。
【0040】
複数の曲データM10〜M1nを連続してサーバSVに登録する場合、従来のサーバSVは1つの曲データM1nが登録されるごとにオーディオクライアントCLに更新通知を送信していた。具体的には、サーバSVは曲データM10を登録した後に更新通知を出し、曲データM11を登録した後に更新通知を出し、曲データM1nを登録した後に更新通知を出していた。本実施の形態によるネットワークAVシステムのサーバSVは、全ての曲データM10〜M1nを登録した後に、1回だけ更新通知をオーディオクライアントCLに送信する。このため、サーバSVとオーディオクライアントCLとの間の通信量は減少する。以下、詳細を説明する。
【0041】
2.1.1.サーバとの接続動作
アップローダULがサーバSVに曲データM10〜M1nを登録させる場合、初めにアップローダULはサーバSVと接続を確立する。以下、アップローダULによるサーバSVとの接続処理を説明するが、オーディオクライアントCLによるサーバSVとの接続処理も同じである。
【0042】
図6を参照して、アップローダULは、TCP(Transmission Control Protocol)に従い、サーバSVのIP(Internet Protocol)アドレス及びコマンドポートでソケットを生成し、このソケットでサーバSVに接続を要求する(S101)。コマンドポートは、アップローダULからサーバSVへのコマンドを受信し、かつサーバSVからアップローダULへの応答を送信するためのポートである。サーバSVはコマンドポートでの接続を受け付け(S251)、接続に成功した場合はステップS103に進む(S102)。これによりアップローダULはサーバSVのコマンドポートに接続を確立する。
【0043】
続いて、アップローダULはコマンドポートにクライアントインデックス要求コマンドを送信する(S103)。サーバSVはクライアントインデックス要求コマンドに応答してコマンドポートからクライアントインデックスをアップローダULに返信し(S252)、アップローダULはこれを受信する(S104)。クライアントインデックス要求コマンドは、アップローダULがサーバSVにクライアントインデックスを要求するコマンドである。クライアントインデックスは、サーバSVからアップローダULに割り当てられる識別子(ID)である。
【0044】
続いて、アップローダULは、TCPに従い、サーバSVのIPアドレス及びプッシュポートでソケットを生成し、このソケットでサーバSVに接続を要求する(S105)。プッシュポートは、サーバSVからアップローダULへの要求を送信するためのポートである。サーバSVはプッシュポートでの接続を受け付け(S253)、接続が成功した場合はステップS107に進む(S106)。これによりアップローダULはサーバSVのプッシュポートに接続を確立する。ただし、この時点ではまだ、サーバSVはプッシュポートに接続された装置がアップローダULなのかオーディオクライアントCLなのか特定できていない。そのため、アップローダULはステップS104で受信したクライアントインデックスをサーバSVのプッシュポートに送信する(S107)。サーバSVはクライアントインデックスを受信し(S254)、これによりプッシュポートに接続された装置をアップローダULと特定する。
【0045】
2.1.2.曲データ更新動作
図7を参照して、アップローダULが曲データM10〜M1nをサーバSVに登録させる場合、初めにアップローダULはサーバSVに要求開始通知を送信する(S201)。サーバSVは要求開始通知を受け、開始通知受信処理を行う(S202)。開始通知受信処理とは、サーバSVがアップローダULから要求開始通知を受けたことを確認するための処理である。
【0046】
アップローダULは要求開始通知を送信した後、曲データM10〜M1nの登録をサーバSVに要求する(S20)。このとき、アップローダULは曲データM10〜M1nごとに更新要求を行う(S203)。具体的には、曲データM10〜M1nをサーバSVに登録させるために、アップローダULはサーバSVに対してn回更新要求を行う(S20,S203)。サーバSVはアップローダULから更新要求を受けるごとに更新処理を実行する(S204)。更新処理とは、ここでは、サーバSVが曲データM1nをHDD14内データベースDBに登録する処理をいう。
【0047】
アップローダULは曲データM10〜M1nの登録を要求した後(S20)、要求完了通知をサーバSVに送信する(S205)。サーバSVは要求完了通知を受けた後、完了通知受信処理を実行する(S206)。具体的には、サーバSVは要求完了通知を受けたとき、アップローダULからの更新要求が完了したと判断し、データベースDBが更新された旨の通知(更新通知)をオーディオクライアントCL及びアップローダULに送信する(S206)。オーディオクライアントCL及びアップローダULはそれぞれ更新通知を受信する(S207、S208)。以下、ステップS202の開始通知受信処理、ステップS203の更新要求処理、ステップS204の更新処理、ステップS206の完了通知受信処理について詳細を説明する。
【0048】
[開始通知受信処理]
ステップS202では、アップローダULからの要求開始通知を受け、サーバSVが要求開始通知を受けた状態であることを記憶する。具体的には、サーバSVはHDD14に格納された更新ステータステーブルを更新する。
【表4】
【0049】
表4を参照して、更新ステータステーブルのステータス値が「0」のとき、サーバSVはアップローダULから要求開始通知を受けていない状態である。ステータス値が「1」のとき、サーバSVはアップローダULから要求開始通知を受けているが、データベースDBが未だ更新されていない状態である。ステータス値が「2」のとき、サーバSVは要求開始通知を受け、かつデータベースDBが更新された状態である。
【0050】
図8を参照して、アップローダULから要求開始通知を受けたとき、サーバSVは更新ステータステーブル内のステータス値が「0」であるか否かを判断する(S2021)。ステータス値が「0」の場合は、ステータス値を「1」に変更する(S2022)。これにより、サーバSVは自身が要求開始通知を受けていると判断できる。なお、ステップS2021での判断の結果、更新ステータスが「0」以外の場合、サーバSVはステータス値を変更せず、そのまま開始通知受信処理を終了する。
【0051】
[更新要求処理及び更新処理]
図9を参照して、アップローダは曲データM1nの登録を要求する旨の更新要求をサーバSVに送信する(S2031)。このとき、アップローダULは曲データM1nの曲情報I1nを更新要求に付加して送信する。
【0052】
サーバSVは更新要求を受信し(S2041)、曲データM1nを格納するためにデータベースDB内に新規曲IDを登録する(S2042)。サーバSVは新規曲IDをアップローダULに送信する(S2043)。アップローダULは新規曲IDを受信し(S2032)、受信した新規曲IDを付与した曲データM1nをサーバSVに送信する(S2033)。サーバSVは曲データM1nを受信し、データベースDB内の新規曲IDの領域に曲データM1nを登録する(S2044)。
【0053】
曲データM1nを登録後、サーバSVは全曲データM1〜Mnの曲リストMLを更新する(S2045)。具体的にはサーバSVは曲リストMLに曲データM1nの曲情報I1nを登録する。
【0054】
曲リストMLを更新後、サーバSVは更新ステータステーブルの更新を行う(S2046〜S2049)。初めに、サーバSVは更新ステータステーブル内のステータス値が「0」である否かを判断する(S2046)。判断の結果、ステータス値が「0」でない場合、サーバSVはステータス値が「1」であるか否かを判断する(S2048)。本実施の形態では、サーバSVはアップローダULから要求開始通知を受けているため(ステップS202)、ステータス値は通常「1」である。ステータス値が「1」である場合、サーバSVはステータス値を「2」に変更する(S2049)。つまり、サーバSVは自身が要求開始通知を受け、かつ曲データM1nの登録も行った状態であることを記憶する。
【0055】
なお、サーバSVが2曲目以降の曲データM11〜M1nを登録するときは、更新ステータステーブルのステータス値は既に「2」になっている。そのため、ステップS2048での判断の結果、ステータス値は「2」であるため、サーバSVはステータス値を変更することなく、そのまま更新処理を終了する。
【0056】
[完了通知処理]
ステップS20で複数の曲データM10〜M1nがサーバSVのデータベースDBに登録された後、サーバSVは更新通知をオーディオクライアントCL及びアップローダULに送信する(S206)。図10を参照して、サーバSVは更新ステータステーブル内のステータス値が「2」であるか否かを判断する(S2061)。判断の結果、ステータス値が「2」である場合、サーバSVはオーディオクライアントCL及びアップローダULに更新通知を送信する(S2062)。更新通知を送信後、サーバSVはステータス値を「0」に戻し(S2064)、完了通知処理を終了する。
【0057】
一方、ステップS2061での判断の結果、ステータス値が「2」でない場合、サーバSVはさらにステータス値が「1」であるか否かを判断する(S2063)。判断の結果、ステータス値が「1」である場合、アップローダULから要求開始通知を受けたものの、曲データM1nの登録がなかったことになる。よってこの場合は更新通知を送信せず、ステータス値を「0」に戻す(S2064)。なお、ステップS2063で判断の結果、更新ステータスが「1」でない場合、更新ステータス値は「0」であるため、サーバSVはそのまま完了通知処理を終了する。
【0058】
以上の動作により、サーバSVはアップローダULから要求完了通知を受けた後、つまり、複数の曲データM10〜M1nを登録した後に更新通知を送信する。そのため、曲データM1nを登録するごとに更新通知を送信していた従来のネットワークAVシステムと比較して、サーバSVとオーディオクライアントCLとの間の通信量を減少させることができる。
【0059】
さらに、サーバSVは更新ステータステーブルで、自身の状態を確認できる。具体的には、サーバSVが要求開始通知を受けたか否か、データベースDBを更新したか否かを更新ステータステーブルにより判断できる。その結果、要求開始通知を受けたものの、データベースDBが更新されてないといった場合に、要求完了通知が来ても、更新通知を送信しない。これにより、無駄な通信が発生するのを防止できる。
【0060】
2.1.3.再生動作
図11を参照して、サーバSVから更新通知を受けたオーディオクライアントCLは(S207)、プレイリストPLをサーバSVに要求する(S210)。プレイリストPLとは、サーバSVに登録されている曲リストMLの曲情報I1〜Inのうち、オーディオクライアントCLのユーザがリスト構築キーにより選択した1又は複数の曲情報Inをリストにしたものである。たとえば、オーディオクライアントCLのユーザがアーティストPの曲を再生したい場合、ステップS210でオーディオクライアントCLは表5に示すリスト要求コマンドを送信する。
【表5】
【0061】
リスト要求コマンドは、リスト構築キーのフィルタ種類とキーワードとを含む。サーバSVはオーディオクライアントCLからのリスト要求コマンドを受け(S211)、リスト構築キーに基づいてプレイリストPLを作成する。具体的には、サーバSVはアーティスト名「P」の曲情報Inを曲リストMLから選択し、選択された1又は複数の曲情報Inに基づいてプレイリストPLを作成する。作成されたプレイリストPLはオーディオクライアントCLに送信される(S212)。なお、受信したリスト構築キーはサーバSV内のクライアント情報CLIに登録される。
【0062】
オーディオクライアントCLはプレイリストPLを受信し(S213)、プレイリストPLに基づいて、曲データMnを再生する曲再生処理を実行する(S300)。このとき、サーバSVはオーディオクライアントCLからの要求に応じ、曲データMnをオーディオクライアントCLに配信する曲配信処理を実行する(S310)。以下、曲再生処理及び曲配信処理について詳細を説明する。
【0063】
図12を参照して、オーディオクライアントはコマンドポートを介して表6に示す曲データ転送要求コマンドを送信する(S301)。
【表6】
【0064】
この曲データ転送要求コマンドは、転送すべき曲データMnの取得開始アドレス及び取得データ長を含む。なお、曲データMnはたとえばプレイリストPLのリスト順に転送要求される。
【0065】
サーバSVは曲データMnの転送要求コマンドに応答して、取得開始アドレスにより指定された先頭アドレスからその取得データ長分だけ曲データMnのデータをオーディオクライアントCLに配信する(S311)。オーディオクライアントCLは配信された曲データMnのデータをメモリ32に格納する。メモリ32は複数のバッファを含む。オーディオクライアントCLは曲データ転送要求コマンドで曲の先頭から1バッファ分(=取得データ長)の曲データを取得して格納する(S302)。格納後、オーディオクライアントCLはメモリ32のバッファが全て曲データで埋まったか判断し(S303)、バッファが全て埋まるまで曲データを取得して格納する。
【0066】
ステップS301〜S303を繰り返し、バッファが曲データで全て埋まったら、オーディオクライアントCLは再生を開始する(S304)。具体的には、メモリ32内の先頭バッファから曲データを音声処理部34に出力し始める。曲データを出力して再生していると、やがて1バッファ分の空きが生じる。メモリ32に空きが生じると(S305)、オーディオクライアントCLは再び曲データ転送要求をサーバSVに送信し(S306)、サーバSVは要求分の曲データを配信する(S312)。オーディオクライアントCLは配信された曲データをメモリ32の空いたバッファに格納する(S307)。格納後、オーディオクライアントCLは曲データMnを全て受信したか否か確認する(S308)。曲データMnを全て受信していない場合、すなわち、サーバSVが曲データMnの全データを未だオーディオクライアントCLに送信していない場合、オーディオクライアントCL及びサーバSVは再生によりメモリ32に空きが生じるたびにステップS306、S312、S307を繰り返す。なお、上記では、バッファが曲データで全て埋まってから再生を開始しているが、全て埋まる前に再生し始めてもよい。
【0067】
オーディオクライアントCLがサーバSVから曲データMnを全て受信した場合(S308)、オーディオクライアントCLは曲データMnを全て再生するまで再生動作を継続する(S309)。なお、曲データMnの再生が完了したら、オーディオクライアントCLはプレイリストPLに基づいて、次の曲データMnの転送要求をサーバSVに送信する。
【0068】
2.2.アップローダが曲データを1つだけサーバに登録させる場合
再び図7を参照して、アップローダULが曲データM10だけをサーバSVに登録させる場合、ステップS20での更新要求処理(S203)を1回だけ実行する。さらに、このとき、アップローダULはステップS201の要求開始通知の送信を行わない。つまり、アップローダULはステップS203の動作から開始する。そのため、サーバSVはステップS202の開始通知受信処理を行わず、更新ステータステーブルのステータス値は「0」のままとなる。このときのサーバSVの更新処理(S204)について説明する。
【0069】
図9を参照して、サーバSVがアップローダULから更新要求を受け、曲リストMLを更新するまでの動作(S2041〜S2045)は上記2.1.2.の場合(複数の曲データM10〜M1nをサーバSVに登録させる場合)と同じである。
【0070】
曲リストMLを更新後、サーバSVは更新ステータステーブルのステータス値が「0」であるか否かを判断する(S2046)。このとき、ステータス値は「0」であるため、サーバSVは更新通知をクライアントCLに送信する(S2047)。つまり、アップローダULが1曲だけ曲データM1nを登録要求する場合、サーバSVは要求完了通知を受けなくても曲データM1nを登録すれば、更新通知を送信する。なお、このとき、アップローダULは要求完了通知(S205)も送信しない。
【0071】
1曲だけ曲データM1nを登録する場合にも、アップローダULが要求開始通知や要求完了通知を送信したならば、かえってLAN10上の通信量が増加してしまう。そこで、本実施の形態によるネットワークSVシステムでは、1曲だけ曲データM1nを登録する場合は、アップローダULが要求開始通知や要求完了通知を送信しなくてもサーバSVが更新通知を送信できるようにすることで、通信量の増加を防ぐ。
【0072】
なお、本実施の形態によるサーバSVは従来のアップローダにも対応できる。すなわち、従来のアップローダは要求開始通知や要求完了通知をサーバSVに送信しない。よって、サーバSVは従来のアップローダから複数の曲データM10〜M1nの登録要求を受けた場合、1曲登録するごとに更新通知を送信する。
【0073】
本実施の形態によるネットワークAVシステム1では、曲データM1nを登録する場合について説明したが、曲データMnの曲情報Inを変更する場合、曲データMnを削除する場合についても同様の動作を行う。なお、曲データMnを削除する場合の動作では、削除すべき曲データMnを特定すれば足りるので、アップローダULは更新要求処理(S203)で曲データMn自体を送ることはない。また、曲データMnの曲情報Inの変更の場合も、アップローダULは曲データMn自体を送信せず、要求開始通知を送信するときに(S201)、変更する曲情報Inを添付して送信する。
【0074】
また、本実施の形態では、コンテンツを曲データとしたが、映像データであっても同じである。
【0075】
以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。
【図面の簡単な説明】
【0076】
【図1】本発明の実施の形態によるネットワークAVシステムの構成を示す機能ブロック図である。
【図2】図1中のサーバの構成を示す機能ブロック図である。
【図3】図1中のオーディオクライアントCLの構成を示す機能ブロック図である。
【図4】図1中のアップローダの構成を示す機能ブロック図である。
【図5】図1のネットワークAVシステムの動作を説明するための概略図である。
【図6】図1中のアップローダのサーバへの接続動作を示すフロー図である。
【図7】図1中のネットワークAVシステムの曲データ更新動作を示すフロー図である。
【図8】図7中のステップS202の動作の詳細を示すフロー図である。
【図9】図7中のS210の動作の詳細を示すフロー図である。
【図10】図7中のステップS206の動作の詳細を示すフロー図である。
【図11】図1中のネットワークAVシステムの再生動作を示すフロー図である。
【図12】図11中のステップS300及びS310の動作の詳細を示すフロー図である。
【符号の説明】
【0077】
1 ネットワークAVシステム
10 LAN
14 HDD
16 データベース管理部
20,40 CPU処理部
22,38,43 LANコントローラ
28 マイコン処理部
41 要求作成部
CL オーディオクライアント
ML 曲リスト
Mn 曲データ
PL プレイリスト
UL アップローダ
【特許請求の範囲】
【請求項1】
複数のコンテンツが蓄積されたデータベースを有するサーバと、
前記サーバにネットワーク経由で接続され、前記データベースを前記サーバに更新させるアップローダと、
前記サーバにネットワーク経由で接続され、前記複数のコンテンツの中から選択されたコンテンツを前記サーバから受け、前記選択されたコンテンツを再生するクライアントとを備え、
前記アップローダは、
前記サーバに前記データベースを更新させるための1又は複数の更新要求を前記サーバに送信する更新要求手段と、
前記更新要求手段が前記1又は複数の更新要求を送信した後、要求完了通知を前記サーバに送信する完了通知手段とを備え、
前記サーバは、
前記1又は複数の更新要求に応じて前記データベースを更新する更新手段と、
前記要求完了通知を受けた後、前記データベースが更新された旨の更新通知を前記クライアントに送信する更新通知手段とを備えることを特徴とするネットワークAVシステム。
【請求項2】
請求項1に記載のネットワークAVシステムであって、
前記クライアントは、
前記更新通知を受けたとき、前記選択されたコンテンツに関する情報を前記サーバから取得する取得手段と、
前記情報に基づいて、前記選択されたコンテンツを前記サーバに要求する要求手段とを備えることを特徴とするネットワークAVシステム。
【請求項3】
請求項1又は請求項2に記載のネットワークAVシステムであって、
前記アップローダはさらに、
前記更新要求手段が前記複数の更新要求を送信する前に、要求開始通知を前記サーバに送信する開始通知手段を備え、
前記更新通知手段は、前記要求開始通知を受けた場合、前記要求完了通知を受けた後に前記更新通知を送信し、前記要求開始通知を受けることなく前記更新要求を受けた場合、前記更新手段が前記更新要求に応じて前記データベースを更新した後に前記更新通知を送信することを特徴とするネットワークAVシステム。
【請求項4】
請求項1〜請求項3のいずれか1項に記載のネットワークAVシステムであって、
前記サーバはさらに、
前記データベースが更新されたか否かを判断する判断手段を備え、
前記更新通知手段は、前記データベースが更新されたと前記判断手段が判断したとき、前記更新通知を送信することを特徴とするネットワークAVシステム。
【請求項5】
請求項1〜請求項4のいずれか1項に記載の手段をコンピュータに実行させるためのネットワークAVプログラム。
【請求項6】
複数のコンテンツが蓄積されたデータベースを有するサーバと、前記サーバにネットワーク経由で接続され、前記データベースを前記サーバに更新させるアップローダと、前記サーバにネットワーク経由で接続され、前記複数のコンテンツの中から選択されたコンテンツを前記サーバから受け、前記選択されたコンテンツを再生するクライアントとを備えるネットワークAVシステムにおける前記サーバであって、
前記アップローダから送信される前記データベースの更新要求に応じて前記データベースを更新する更新手段と、
前記アップローダから前記更新要求を完了する旨の要求完了通知を受けた後、前記データベースが更新された旨の更新通知を前記クライアントに送信する更新通知手段とを備えることを特徴とするサーバ。
【請求項7】
請求項6に記載のサーバであって、
前記更新通知手段は、前記アップローダから更新要求を開始する旨の要求開始通知を受けた場合、前記要求完了通知を受けた後に前記更新通知を送信し、前記要求開始通知を受けることなく前記更新要求を受けた場合、前記更新手段が前記更新要求に応じて前記データベースを更新した後に前記更新通知を送信することを特徴とするサーバ。
【請求項8】
複数のコンテンツが蓄積されたデータベースを有するサーバと、前記サーバにネットワーク経由で接続され、前記データベースを前記サーバに更新させるアップローダとを備えるネットワークAVシステムにおける前記アップローダであって、
前記データベースを前記サーバに更新させるための1又は複数の更新要求を前記サーバに送信する更新要求手段と、
前記更新要求手段が前記1又は複数の更新要求を送信した後、要求完了通知を前記サーバに送信する完了通知手段とを備えることを特徴とするアップローダ。
【請求項9】
請求項8に記載のアップローダであってさらに、
前記更新要求手段が前記複数の更新要求を送信する前に、要求開始通知を前記サーバに送信する開始通知手段を備えることを特徴とするアップローダ。
【請求項1】
複数のコンテンツが蓄積されたデータベースを有するサーバと、
前記サーバにネットワーク経由で接続され、前記データベースを前記サーバに更新させるアップローダと、
前記サーバにネットワーク経由で接続され、前記複数のコンテンツの中から選択されたコンテンツを前記サーバから受け、前記選択されたコンテンツを再生するクライアントとを備え、
前記アップローダは、
前記サーバに前記データベースを更新させるための1又は複数の更新要求を前記サーバに送信する更新要求手段と、
前記更新要求手段が前記1又は複数の更新要求を送信した後、要求完了通知を前記サーバに送信する完了通知手段とを備え、
前記サーバは、
前記1又は複数の更新要求に応じて前記データベースを更新する更新手段と、
前記要求完了通知を受けた後、前記データベースが更新された旨の更新通知を前記クライアントに送信する更新通知手段とを備えることを特徴とするネットワークAVシステム。
【請求項2】
請求項1に記載のネットワークAVシステムであって、
前記クライアントは、
前記更新通知を受けたとき、前記選択されたコンテンツに関する情報を前記サーバから取得する取得手段と、
前記情報に基づいて、前記選択されたコンテンツを前記サーバに要求する要求手段とを備えることを特徴とするネットワークAVシステム。
【請求項3】
請求項1又は請求項2に記載のネットワークAVシステムであって、
前記アップローダはさらに、
前記更新要求手段が前記複数の更新要求を送信する前に、要求開始通知を前記サーバに送信する開始通知手段を備え、
前記更新通知手段は、前記要求開始通知を受けた場合、前記要求完了通知を受けた後に前記更新通知を送信し、前記要求開始通知を受けることなく前記更新要求を受けた場合、前記更新手段が前記更新要求に応じて前記データベースを更新した後に前記更新通知を送信することを特徴とするネットワークAVシステム。
【請求項4】
請求項1〜請求項3のいずれか1項に記載のネットワークAVシステムであって、
前記サーバはさらに、
前記データベースが更新されたか否かを判断する判断手段を備え、
前記更新通知手段は、前記データベースが更新されたと前記判断手段が判断したとき、前記更新通知を送信することを特徴とするネットワークAVシステム。
【請求項5】
請求項1〜請求項4のいずれか1項に記載の手段をコンピュータに実行させるためのネットワークAVプログラム。
【請求項6】
複数のコンテンツが蓄積されたデータベースを有するサーバと、前記サーバにネットワーク経由で接続され、前記データベースを前記サーバに更新させるアップローダと、前記サーバにネットワーク経由で接続され、前記複数のコンテンツの中から選択されたコンテンツを前記サーバから受け、前記選択されたコンテンツを再生するクライアントとを備えるネットワークAVシステムにおける前記サーバであって、
前記アップローダから送信される前記データベースの更新要求に応じて前記データベースを更新する更新手段と、
前記アップローダから前記更新要求を完了する旨の要求完了通知を受けた後、前記データベースが更新された旨の更新通知を前記クライアントに送信する更新通知手段とを備えることを特徴とするサーバ。
【請求項7】
請求項6に記載のサーバであって、
前記更新通知手段は、前記アップローダから更新要求を開始する旨の要求開始通知を受けた場合、前記要求完了通知を受けた後に前記更新通知を送信し、前記要求開始通知を受けることなく前記更新要求を受けた場合、前記更新手段が前記更新要求に応じて前記データベースを更新した後に前記更新通知を送信することを特徴とするサーバ。
【請求項8】
複数のコンテンツが蓄積されたデータベースを有するサーバと、前記サーバにネットワーク経由で接続され、前記データベースを前記サーバに更新させるアップローダとを備えるネットワークAVシステムにおける前記アップローダであって、
前記データベースを前記サーバに更新させるための1又は複数の更新要求を前記サーバに送信する更新要求手段と、
前記更新要求手段が前記1又は複数の更新要求を送信した後、要求完了通知を前記サーバに送信する完了通知手段とを備えることを特徴とするアップローダ。
【請求項9】
請求項8に記載のアップローダであってさらに、
前記更新要求手段が前記複数の更新要求を送信する前に、要求開始通知を前記サーバに送信する開始通知手段を備えることを特徴とするアップローダ。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2006−146900(P2006−146900A)
【公開日】平成18年6月8日(2006.6.8)
【国際特許分類】
【出願番号】特願2005−316064(P2005−316064)
【出願日】平成17年10月31日(2005.10.31)
【分割の表示】特願2003−354522(P2003−354522)の分割
【原出願日】平成15年10月15日(2003.10.15)
【出願人】(000000273)オンキヨー株式会社 (502)
【Fターム(参考)】
【公開日】平成18年6月8日(2006.6.8)
【国際特許分類】
【出願日】平成17年10月31日(2005.10.31)
【分割の表示】特願2003−354522(P2003−354522)の分割
【原出願日】平成15年10月15日(2003.10.15)
【出願人】(000000273)オンキヨー株式会社 (502)
【Fターム(参考)】
[ Back to top ]