JP2011064974A - カラオケシステム、カラオケ装置、ノード装置、ルータ、カラオケプログラム、ノードプログラム、及びカラオケデータ送信方法 - Google Patents

Abstract

【課題】通信回線への負荷を抑制し、カラオケデータの取得の遅延を回避することが可能なカラオケシステム、カラオケ装置、ノード装置、ルータ、カラオケプログラム、ノードプログラム、及びカラオケデータ送信方法を提供する。
【解決手段】カラオケシステムＳにおいて、複数のコマンダＣｍ−ｎの中から決定された代表コマンダＭＣｍが代表してルータＲｍにカラオケデータを要求する。ルータＲｍは、要求に応じて、オーバーレイネットワークＯＮによる通信を利用して複数のルータＲｍの中の何れかのルータＲｍからカラオケデータを取得し、代表コマンダＭＣｍに送信する。そして、代表コマンダＭＣｍは、受信したカラオケデータを各コマンダＣｍ−ｎに送信する。
【選択図】図１

Description

本発明は、カラオケデータを再生する複数のカラオケ装置から構成されるカラオケシステムの技術分野に関する。

従来から、複数のコマンダと、各コマンダにカラオケデータを配信するサーバとを備えたカラオケシステムが知られている。なお、コマンダは、カラオケ装置の一例である。一般的に、コマンダとサーバとを接続する帯域の狭い通信回線で接続されている場合、複数のコマンダがサーバに一斉にアクセスするため、負荷集中により通信回線が所謂パンクする恐れがあった。例えば新曲配信時などは、通信回線がパンクする可能性が高い。そのため、従来のカラオケシステムでは、複数のコマンダの中の代表コマンダが、サーバからカラオケデータをダウンロードし他のコマンダに配信していた。

類似の技術として、特許文献１には、ホスト局が保有する曲データを電話回線を介して受信する複数のサーバと、前記サーバから曲データをダウンロードするコマンダとを備えたカラオケシステムが開示されている。このカラオケシステムにおいては、複数のサーバのうち電話回線に接続された一部のサーバがホスト局から曲データをダウンロードする。そして、ダウンロードしたサーバは、電話回線に接続されていないサーバに曲データを配信するようになっている。

特開平１０−１８７１７６号公報

ところで、例えば、複数の店舗を運営するカラオケチェーン店等では、一つの店舗に、上述した代表コマンダが例えば１台設けられている。しかし、店舗数が増えると、例えば新曲配信時など、各店舗に設置された代表コマンダがサーバに一斉にアクセスすることで負荷集中に至る可能性がある。このような負荷集中を回避するため、例えば、各店舗に設置された複数のコマンダがネットワークを介してピアツーピア通信を行うことを可能としたピアツーピア通信方式のカラオケシステムが考えられる。このようなピアツーピア通信方式のカラオケシステムでは、例えばある店舗に設置されたコマンダと、別の店舗に設置されたコマンダとの間でピアツーピア通信を行う。

しかしながら、上記ピアツーピア通信方式のカラオケシステムでは、ある店舗に設置された複数のコマンダが、一斉に、別の店舗に設置されたコマンダに対してカラオケデータのリクエストを行うと、ネットワークに接続される店舗の通信回線への負荷が増大し、ひいては、カラオケデータの取得が遅延する問題が生じる可能性がある。

そこで、本発明は、以上の点等に鑑みてなされたものである。本発明は、通信回線への負荷を抑制し、カラオケデータの取得の遅延を回避することが可能なカラオケシステム、カラオケ装置、ノード装置、ルータ、カラオケプログラム、ノードプログラム、及びカラオケデータ送信方法を提供すること等を課題とする。

上記課題を解決するために、請求項１に記載の発明は、複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続され、前記カラオケ装置は、前記代表カラオケ装置から送信された前記カラオケデータを受信する第１受信手段を備え、前記代表カラオケ装置は、前記内部ネットワークを介して前記ノード装置に、前記カラオケデータの要求を示す要求情報を送信する第１送信手段と、前記ノード装置から送信された前記カラオケデータを受信する受信手段と、前記内部ネットワークを介して前記カラオケ装置に、前記受信されたカラオケデータを送信する第２送信手段と、を備え、前記ノード装置は、各前記拠点の複数の前記ノード装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークによる通信を制御する通信制御手段と、前記代表カラオケ装置から送信された前記要求情報を受信する受信手段と、前記通信制御手段により前記複数のノード装置の中の何れかのノード装置から前記要求情報に対応するカラオケデータを取得する取得手段と、前記内部ネットワークを介して前記代表カラオケ装置に、前記取得されたカラオケデータを送信する送信手段と、を備えることを特徴とする。

請求項２に記載の発明は、請求項１に記載のカラオケシステムにおいて、前記複数のカラオケ装置の中から、前記代表カラオケ装置が動作不能になったとき前記代表カラオケ装置の動作を行うスレーブカラオケ装置と、前記代表カラオケ装置とが少なくとも１つ決定されることを特徴とする。

請求項３に記載の発明は、請求項１又は２に記載のカラオケシステムにおいて、前記カラオケ装置は、前記代表カラオケ装置の代表カラオケ装置情報であって、当該代表カラオケ装置から前記内部ネットワークを介して送信されてきた前記代表カラオケ装置情報を受信する第２受信手段と、前記受信された代表カラオケ装置情報と、前記代表カラオケ装置情報を受信したカラオケ装置自身のカラオケ装置情報とに基づいて、前記代表カラオケ装置を交代するための所定の条件を満たすか否かを判定する判定手段と、前記判定手段により前記条件を満たすと判定された場合には、前記内部ネットワークを介して前記代表カラオケ装置に、前記代表カラオケ装置の交代を要求する交代要求情報を送信する第１送信手段と、を更に備えることを特徴とする。

請求項４に記載の発明は、請求項３に記載のカラオケシステムにおいて、前記判定手段は、前記受信された代表カラオケ装置情報に示される番号と、前記代表カラオケ装置情報を受信したカラオケ装置自身のカラオケ装置情報に示される番号との大小を比較し、当該比較結果が前記条件を満たすか否かを判定することを特徴とする。

請求項５に記載の発明は、請求項３又は４に記載のカラオケシステムにおいて、前記カラオケ装置は、前記内部ネットワークを介して前記複数のカラオケ装置に、前記代表カラオケ装置の通知要求を示す代表カラオケ装置通知要求情報を、定期的に送信する第２送信手段と、を更に備え、前記第２受信手段は、前記代表カラオケ装置通知要求情報に応じて、前記代表カラオケ装置から送信されてきた前記代表カラオケ装置情報を受信することを特徴とする。

請求項６に記載の発明は、請求項１乃至５の何れか一項に記載のカラオケシステムにおいて、前記代表カラオケ装置は、前記内部ネットワークを介して前記カラオケ装置に、前記カラオケデータのコンテンツリストを送信する第３送信手段を更に備え、前記カラオケ装置は、前記カラオケデータを記憶する記憶手段と、前記代表カラオケ装置から送信された前記コンテンツリストを受信する第３受信手段と、前記コンテンツリストの中で、前記記憶手段に記憶されていないカラオケデータを決定する決定手段と、前記内部ネットワークを介して前記代表カラオケ装置に、前記決定されたカラオケデータの要求を示す要求情報を送信する第３送信手段と、を更に備えることを特徴とする。

請求項７に記載の発明は、請求項１乃至６の何れか一項に記載のカラオケシステムに含まれる代表カラオケ装置であって、前記内部ネットワークを介して前記ノード装置に、前記カラオケデータの要求を示す要求情報を送信する第１送信手段と、前記ノード装置から送信された前記カラオケデータを受信する受信手段と、前記内部ネットワークを介して前記カラオケ装置に、前記受信されたカラオケデータを送信する第２送信手段と、を備えることを特徴とする。

請求項８に記載の発明は、請求項１乃至６の何れか一項に記載のカラオケシステムに含まれるノード装置であって、各前記拠点の複数の前記ノード装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークによる通信を制御する通信制御手段と、前記代表カラオケ装置から送信された前記要求情報を受信する受信手段と、前記通信制御手段により前記複数のノード装置の中の何れかのノード装置から前記要求情報に対応するカラオケデータを取得する取得手段と、前記内部ネットワークを介して前記代表カラオケ装置に、前記取得されたカラオケデータを送信する送信手段と、を備えることを特徴とする。

請求項９に記載の発明は、請求項８に記載のノード装置の機能を備えることを特徴とする。

請求項１０に記載のカラオケプログラムの発明は、複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、各前記拠点の複数のノード装置との間で、外部ネットワークを介して形成されるオーバーレイネットワークにより情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは前記外部ネットワークに接続されるカラオケシステムの代表カラオケ装置に含まれるコンピュータに、前記内部ネットワークを介して前記ノード装置に、前記カラオケデータの要求を示す要求情報を送信する送信ステップと、前記ノード装置から送信された前記カラオケデータを受信する受信ステップと、前記内部ネットワークを介して前記カラオケ装置に、前記受信されたカラオケデータを送信する送信ステップと、を実行させる。

請求項１１に記載のノードプログラムの発明は、複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続されるカラオケシステムのノード装置に含まれるコンピュータに、前記代表カラオケ装置から送信された前記カラオケデータの要求を示す要求情報を受信する受信ステップと、各前記拠点の複数の前記ノード装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークによる通信を制御する通信制御ステップと、前記通信制御ステップにより前記複数のノード装置の中の何れかのノード装置から前記要求情報に対応するカラオケデータを取得する取得ステップと、前記内部ネットワークを介して前記代表カラオケ装置に、前記取得されたカラオケデータを送信する送信ステップと、を実行させる。

請求項１２に記載の発明は、カラオケデータ送信方法であって、複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続されており、前記カラオケデータ送信方法は、前記代表カラオケ装置が、前記内部ネットワークを介して前記ノード装置に、前記カラオケデータの要求を示す要求情報を送信する送信ステップと、前記ノード装置が、各前記拠点の複数の前記ノード装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークによる通信を制御する通信制御ステップと、前記ノード装置が、前記代表カラオケ装置から送信された前記要求情報を受信する受信ステップと、前記ノード装置が、前記通信制御ステップにより前記複数のノード装置の中の何れかのノード装置から前記要求情報に対応するカラオケデータを取得する取得ステップと、前記ノード装置が、前記内部ネットワークを介して前記代表カラオケ装置に、前記取得されたカラオケデータを送信する送信ステップと、前記代表カラオケ装置が、前記ノード装置から送信された前記カラオケデータを受信する受信ステップと、前記代表カラオケ装置が、前記内部ネットワークを介して前記カラオケ装置に、前記受信されたカラオケデータを送信する送信ステップと、を含むことを特徴とする。

請求項１、７、８、１０乃至１２に記載の発明によれば、複数のカラオケ装置の中から決定された代表カラオケ装置が代表してノード装置にカラオケデータを要求する。ノード装置は、要求に応じて、オーバーレイネットワークによる通信を利用して複数のノード装置の中の何れかのノード装置からカラオケデータを取得し、代表カラオケ装置に送信する。そして、代表カラオケ装置は、受信したカラオケデータを各カラオケ装置に送信する。従って、ある拠点に設置された複数のカラオケ装置が、一斉に、別の拠点に設置されたカラオケ装置に対してカラオケデータの要求を行うことを防止でき、ネットワークに接続される各拠点の通信回線への負荷を抑制し、カラオケデータの取得の遅延を回避することができる。

請求項２に記載の発明によれば、代表カラオケ装置が故障等により機能しなくなったときでも、スレーブにより代表カラオケ装置の機能を維持することができる。

請求項３、４に記載の発明によれば、動的に代表カラオケ装置を変更することができる。

請求項５に記載の発明によれば、代表カラオケ装置の交代が頻繁にあっても、各カラオケ装置は迅速に代表カラオケ装置を認識することができる。

請求項６に記載の発明によれば、カラオケ装置は、未だ取得していない新たなカラオケデータを、動的に取得することができる。

請求項９に記載の発明によれば、外部ネットワークと内部ネットワークとを繋ぐルータにノード装置の機能を搭載することで、ルータとノード装置とを別体として構成するよりも、機器設置スペースを節約することができ、なおかつ、オーバーレイネットワークによる通信処理の効率化を図ることができる。

本実施形態に係るカラオケシステムＳの概要構成例を示す図である。 （Ａ）は、コンテンツリスト一覧の一例を示す図である。（Ｂ）は、コンテンツリストの一例を示す図である。 コマンダＣｍ−ｎの概要構成例を示す図である。 ルータＲｍの概要構成例を示す図である。 コマンダＣｍ−ｎの制御部１におけるメイン処理を示すフローチャートである。 図５に示すステップＳ６における非代表コマンダのコンテンツ取得処理の詳細を示すフローチャートである。 図５に示すステップＳ１０における代表コマンダ動作の詳細を示すフローチャートである。 （Ａ）は、図７に示すステップＳ１０５における代表コマンダのコンテンツ取得処理の詳細を示すフローチャートである。（Ｂ）は、ルータＲｍのノード処理部１２におけるコンテンツ送信処理を示すフローチャートである。 （Ａ）は、センターサーバＣＳを利用する場合におけるコンテンツリスト取得処理の詳細を示すフローチャートである。（Ｂ）は、センターサーバＣＳにおけるコンテンツリスト一覧送信処理を示すフローチャートである。（Ｃ）は、ルータＲｍのノード処理部１２におけるコンテンツリスト送信処理を示すフローチャートである。 （Ａ）は、センターサーバＣＳを利用しない場合におけるコンテンツリスト取得処理の詳細を示すフローチャートである。（Ｂ）は、ルータＲｍのノード処理部１２におけるコンテンツリスト一覧送信処理を示すフローチャートである。（Ｃ）は、ルータＲｍのノード処理部１２におけるコンテンツリスト送信処理を示すフローチャートである。

以下、本発明の実施形態を図面に基づいて説明する。

［１．カラオケシステムの構成及び動作の概要］
始めに、図１を参照して、本発明の一実施形態に係るカラオケシステムの構成及び動作の概要について説明する。

図１は、本実施形態に係るカラオケシステムＳの概要構成例を示す図である。

本実施形態に係るカラオケシステムＳにおいて利用されるカラオケデータは、図１に示す配信センタＣにより管理される。

配信センタＣには、ディストリビュータＤＴ、サポータＳＰ、センターサーバＣＳ、及びファイアーウォールＦＷが設置される。そして、ディストリビュータＤＴ、サポータＳＰ、及びセンターサーバＣＳは、ファイアーウォールＦＷを介してネットワークＮＷに接続されている。ネットワークＮＷは、外部ネットワークの一例である。また、ネットワークＮＷは、例えば、インターネットやＷＡＮ（Wide Area Network）等のパブリックネットワークである。

ディストリビュータＤＴは、新規のカラオケデータをカラオケシステムＳ内に配信するための装置である。サポータＳＰは、後述するオーバーレイネットワークＯＮにノード装置が参加する場合に、ノード装置から送信された参加リクエストを処理する装置である。ノード装置とは、オーバーレイネットワークＯＮを介して他のノード装置との間で各種情報の送受信を行う装置である。以下、ノード装置を、「ノード」という。センターサーバＣＳは、コンテンツリスト一覧を管理する装置である。コンテンツリスト一覧は、コンテンツリストの一覧表である。また、コンテンツリストは、カラオケシステムＳにおいて利用可能なカラオケデータのコンテンツの一覧表である。なお、センターサーバＣＳは設けず、コンテンツリスト一覧の管理は各ノードが行うようにしても良い。

図２（Ａ）は、コンテンツリスト一覧の一例を示す図である。また、図２（Ｂ）は、コンテンツリストの一例を示す図である。

コンテンツリスト一覧には、図２（Ａ）に示すように、コンテンツリストのコンテンツリストリビジョンとコンテンツリストＩＤの組が複数記述される。コンテンツリストリビジョンは、例えばコンテンツリスト毎に付与されるシリアル番号である。また、コンテンツリストリビジョンは、例えば、コンテンツリストの発行時に付与される。また、コンテンツリストリビジョンは、例えば、コンテンツリストが発行される度に大きくなっていく。例えば、図２（Ａ）に示すコンテンツリスト一覧には、コンテンツリストリビジョンとして、「１」，「２」，「３」，「４」，「５」というシリアル番号が記述されている。この中で数値の最も大きいコンテンツリストリビジョン「５」が最新のコンテンツリストリビジョンである。そして、最新のコンテンツリストリビジョンが付与されたコンテンツリストが最新のコンテンツリストである。従って、コンテンツリストの新旧は、コンテンツリストリビジョンにより判断することができる。コンテンツリストＩＤは、コンテンツリスト毎に割り当てられる識別情報である。また、コンテンツリストＩＤは、例えば、コンテンツリストに係るデータを、所定のハッシュ関数によりハッシュ化した値である。ハッシュ関数としては、例えば、ＳＨＡ−１等が用いられる。或いは、例えば、システム管理者により、コンテンツリスト毎に一意のコンテンツリストＩＤが割り当てられるようにしても良い。

なお、コンテンツリストの発行は、新規のカラオケデータの配信時等の所定のタイミングで配信センタＣにより行われる。センターサーバＣＳ又はディストリビュータＤＴは、配信センタＣにより発行されたコンテンツリストをカラオケシステムＳ内に配信する。

コンテンツリストには、図２（Ｂ）に示すように、コンテンツのローカルファイル名とコンテンツＩＤの組が複数記述される。図２（Ｂ）に示すコンテンツリストには、コンテンツリストリビジョンとして「１」が付与されている。ローカルファイル名は、例えば、カラオケデータのコンテンツ毎に付与される曲番に相当する。コンテンツＩＤは、コンテンツ毎に割り当てられる識別情報である。また、コンテンツＩＤは、例えば、コンテンツ名＋任意の数値が、コンテンツリストＩＤを得るときと共通のハッシュ関数によりハッシュ化した値である。或いは、例えば、システム管理者により、コンテンツ毎に一意のコンテンツＩＤが割り当てられるようにしても良い。

また、カラオケシステムＳにおいては、図１に示すように、複数の店舗Ｐｍ（ｍ＝１，２，３・・・の何れか）毎に店舗ネットワークＮＬｍが構築されている。店舗Ｐｍは、拠点の一例である。店舗ネットワークＮＬｍは、内部ネットワークの一例である。また、店舗ネットワークＮＬｍは、例えば、ＬＡＮ（Local Area Network）等のプライベートネットワークである。なお、店舗ネットワークＮＬｍは、複数のＬＡＮが相互接続して構築されたＣＡＮ（Campus Area Network）等のネットワークであっても良い。

各店舗ネットワークＮＬｍには、複数のコマンダＣｍ−ｎ（ｎ＝１，２，３・・・の何れか）とルータＲｍとが接続されている。このように、カラオケシステムＳは、複数のコマンダＣｍ−ｎとルータＲｍとを店舗ネットワークＮＬｍ毎に備える。なお、本実施形態におけるコマンダは、カラオケ装置の一例である。コマンダＣｍ−ｎは、カラオケデータを再生する装置である。例えば、店舗Ｐｍ内の各部屋には１台のコマンダＣｍ−ｎが設置される。また、ルータＲｍは、複数のネットワーク間でＩＰ（Internet Protocol）パケットを中継する中継機器である。さらに、本実施形態において、ルータＲｍはノードの機能を備える。店舗ネットワークＮＬｍとネットワークＮＷとを繋ぐルータＲｍにノードの機能を搭載することで、機器設置スペースを節約することができ、なおかつ、オーバーレイネットワークＯＮによる通信処理の効率化を図ることができる。

そして、各店舗Ｐｍにおいて、複数のコマンダＣｍ−ｎの中からは、代表コマンダＭＣｍと、スレーブコマンダ（図示せず）と、が少なくとも１つ決定される。代表コマンダＭＣｍは、複数のコマンダＣｍ−ｎを代表して、店舗ネットワークＮＬｍを介してルータＲｍとの間で情報の送受信を行う。一方、スレーブコマンダは、代表コマンダＭＣｍが動作不能になったとき代表コマンダＭＣｍの動作を行う。これにより、代表コマンダＭＣｍが故障等により機能しなくなったときでも、スレーブコマンダにより代表コマンダの機能を維持することができる。

ここで、代表コマンダＭＣｍの処理概要について説明する。代表コマンダＭＣｍは、センターサーバＣＳにより管理されるコンテンツリスト一覧を取得する。次に、代表コマンダＭＣｍは、取得したコンテンツリスト一覧に記述されているコンテンツリストリビジョンが付与されたコンテンツリストをルータＲｍから取得する。次に、代表コマンダＭＣｍは、取得したコンテンツリストに記述されているローカルファイル名が付与されたカラオケデータのコンテンツをルータＲｍから取得する。このようにコンテンツの取得が行われたコンテンツリストのコンテンツリストリビジョンを、処理済コンテンツリビジョンという。なお、非代表のコマンダＣｍ−ｎは、代表コマンダＭＣｍと同様の流れでカラオケデータのコンテンツを取得することになる。しかし、非代表のコマンダＣｍ−ｎによる、コンテンツリスト一覧、コンテンツリスト、及びカラオケデータのコンテンツの取得先は、同じ店舗ネットワークＮＬｍに接続された代表コマンダＭＣｍになる。

また、各店舗ネットワークＮＬｍは、各ルータＲｍ及び各店舗の通信回線Ｋｍを介してネットワークＮＷに接続されている。各店舗ＰｍのルータＲｍは、他の店舗Ｐｍの複数のルータＲｍとの間で、ネットワークＮＷを介して形成されるオーバーレイネットワークＯＮによる通信を行う。つまり、オーバーレイネットワークＯＮを介して複数のルータＲｍ間でピアツーピア通信が行われる。オーバーレイネットワークＯＮとは、ネットワークＮＷを用いて形成される仮想的なリンクを構成する論理的なネットワークである。また、オーバーレイネットワークＯＮは、特定のアルゴリズム、例えば、ＤＨＴ（Distributed Hash Table）を利用したアルゴリズムにより実現される。

また、カラオケシステムＳにおいては、例えばディストリビュータＤＴにより配信された複数のカラオケデータが所定のファイル形式で複数のルータＲｍに分散されて保存されている。例えば、ルータＲ１には、コンテンツ名が「ＡＡＡ」の演奏曲のカラオケデータが保存されている。また、ルータＲ２には、コンテンツ名が「ＢＢＢ」の演奏曲のカラオケデータが保存されている。なお、ディストリビュータＤＴは、新規のカラオケデータをカラオケシステムＳに投入する場合、例えば１又は複数のルータＲｍを選択する。そして、ディストリビュータＤＴは、選択したルータＲｍにカラオケデータを配信する。これにより、ルータＲｍにはカラオケデータが保存されることになる。

さらに、例えばディストリビュータＤＴにより配信された複数のコンテンツリストが複数のルータＲｍに分散されて保存されている。例えば、ルータＲ３には、コンテンツリストリビジョンが「１」のコンテンツリストが保存されている。また、ルータＲ４には、コンテンツリストリビジョンが「２」のコンテンツリストが保存されている。

各ルータＲｍは、オーバーレイネットワークＯＮに参加することにより、他のルータＲｍからカラオケデータ及びコンテンツリストを取得可能になっている。

ここで、オーバーレイネットワークＯＮについて説明する。このオーバーレイネットワークＯＮの説明においては、オーバーレイネットワークＯＮにおけるルータＲｍを、適宜、「ノード」という。また、他のルータＲｍから取得可能なカラオケデータとコンテンツリストを総称して「保存コンテンツ」という。また、コンテンツＩＤとコンテンツリストＩＤを総称して「保存コンテンツＩＤ」という。

各ノードは、サポータＳＰに参加リクエストを送信することによりオーバーレイネットワークＯＮへ参加することができる。オーバーレイネットワークＯＮに参加している各ノードには、固有の識別情報であるノードＩＤが割り当てられている。ノードＩＤは、例えば、各ノードに個別に割り当てられたＩＰ（Internet Protocol）アドレス、製造番号、或いはＭＡＣアドレス（Media Access Control address）等を、保存コンテンツＩＤを得るときと共通のハッシュ関数によりハッシュ化した値である。或いは、例えば、システム管理者により、ノード毎に一意のノードＩＤが割り当てられるようにしても良い。なお、ノードＩＤと保存コンテンツＩＤは、ハッシュ関数の特性により、同一の桁数を有しており、同一のＩＤ空間にさほど偏りなく分散して配置される。

また、各ノードは、例えば、オーバーレイネットワークＯＮへの参加時に、ＤＨＴを用いたルーティングテーブルを生成する。このルーティングテーブルには、ノード情報が複数登録されている。ノード情報とは、ノードＩＤ、ＩＰアドレス及びポート番号を含む情報である。なお、ＤＨＴを用いたルーティングテーブルについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。

また、オーバーレイネットワークＯＮを介して取得可能な保存コンテンツの所在を示す情報は、インデックス情報として、保存コンテンツの所在を管理しているノードに記憶される。インデックス情報には、保存コンテンツを保存しているノードのノード情報と、保存コンテンツの保存コンテンツＩＤとの組が含まれる。以下、保存コンテンツの所在を管理しているノードを「ルートノード」又は「保存コンテンツのルートノード」という。また、保存コンテンツを保存しているノードを「コンテンツ保持ノード」という。ルートノードは、例えば、保存コンテンツＩＤと最も近いノードＩＤが割り当てられたノードであるように定められる。保存コンテンツＩＤと最も近いノードＩＤとは、例えば、ＩＤの上位桁が最も多く一致するノードＩＤである。

ところで、あるノードが保存コンテンツを取得する場合、このノードは保存コンテンツの所在をルートノードに問い合わせる。以下、保存コンテンツの所在を問い合わせるノードを「ユーザノード」という。具体的に、保存コンテンツの所在の問い合わせにおいては、ユーザノードは、先ず、コンテンツ所在問合せメッセージを生成する。コンテンツ所在問合せメッセージには、問い合わせ対象の保存コンテンツのコンテンツＩＤ、ユーザノードのＩＰアドレス及びポート番号等が含まれる。このように生成されたコンテンツ所在問合せメッセージは、ユーザノードが記憶しているＤＨＴを用いたルーティングテーブルに従って、ユーザノードから他のノードに送信される。これにより、コンテンツ所在問合せメッセージは、保存コンテンツＩＤをキーとするＤＨＴルーティングによって１又は複数のノードにより転送され、最終的にルートノードにより受信される。なお、ＤＨＴルーティングについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。

コンテンツ所在問合せメッセージを受信したルートノードは、コンテンツ所在問合せメッセージに含まれる保存コンテンツＩＤに対応するインデックス情報をインデックス情報キャッシュから取得する。そして、ルートノードは、取得したインデックス情報を、例えば、コンテンツ所在問合せメッセージの送信元であるユーザノードに返信する。こうして、インデックス情報を取得したユーザノードは、インデックス情報に含まれるコンテンツ保持ノードのＩＰアドレス及びポート番号に基づいて、コンテンツ保持ノードにアクセスする。そして、ユーザノードは、アクセスしたコンテンツ保持ノードから、保存コンテンツを取得することができる。なお、コンテンツ保持ノードにおいて例えばアクセス集中が発生していると、ユーザノードがコンテンツ保持ノードにアクセスしてもコンテンツ保持ノードから応答が帰って来ず、タイムアウトとなってしまう。従って、このような場合、ユーザノードは、ディストリビュータＤＴから保存コンテンツを取得することになる。

なお、ディストリビュータＤＴは、オーバーレイネットワークＯＮを介して送受信可能な各保存コンテンツのオリジナルを保持している。

こうして、ユーザノードは、コンテンツ保持ノード又はディストリビュータＤＴから保存コンテンツを取得して保存すると、パブリッシュメッセージを生成する。このパブリッシュメッセージは、保存コンテンツを保存したことをルートノードへ知らせるためのメッセージである。パブリッシュメッセージには、保存コンテンツＩＤ及びユーザノード自身のノード情報を含む。このように生成されたパブリッシュメッセージは、ユーザノードが記憶しているＤＨＴを用いたルーティングテーブルに従って、ユーザノードから他のノードに送信される。これにより、パブリッシュメッセージは、コンテンツ所在問合せメッセージと同じように、保存コンテンツＩＤをキーとするＤＨＴルーティングによって１又は複数のノードにより転送され、最終的にルートノードにより受信される。そして、ルートノードは、パブリッシュメッセージに含まれるノード情報及び保存コンテンツＩＤの組を含むインデックス情報をインデックス情報キャッシュ領域に記憶する。こうして、ユーザノードは、取得した保存コンテンツを保存するコンテンツ保持ノードとなる。

なお、ルータＲｍとノードを別体として構成しても良い。この場合、ルータＲｍが、例えばＵＰｎＰ（Universal Plug and Play）機能等を利用してポートフォワーディングの設定をする。そして、ポートフォワーディングの設定により、ルータに接続されるノードがオーバーレイネットワークＯＮを介して他のノードとの間で各種情報の送受信を行うことになる。

［２．コマンダＣｍ−ｎの構成及び機能等］
次に、図３を参照して、コマンダＣｍ−ｎの構成及び機能について説明する。

図３は、コマンダＣｍ−ｎの概要構成例を示す図である。

コマンダＣｍ−ｎは、図３に示すように、制御部１と、記憶部２と、通信部３と、入力部４と、バッファメモリ５と、デコーダ部６と、映像処理部７と、表示部８と、音声処理部９と、スピーカ９ａとを備えて構成される。制御部１、記憶部２、通信部３、入力部４、バッファメモリ５、及びデコーダ部６はバス９ｂを介して相互に接続されている。

なお、各コマンダＣｍ−ｎには、各店舗ネットワークＮＬｍにおいて固有のコマンダ番号が割り当てられている。コマンダ番号は、コマンダ情報の一例である。また、コマンダ番号は、例えばシリアル番号で構成される。また、各コマンダＣｍ−ｎには、ＩＰアドレスが割り当てられている。

制御部１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種設定データ及びプログラムを記憶するフラッシュメモリ等から構成される。制御部１は、第１乃至第３送信手段、第１乃至第３受信手段、判定手段、及び決定手段等の一例である。ＣＰＵは、コンピュータの一例である。プログラムには、ＣＰＵにコマンダとしての処理を実行させるためのカラオケプログラムが含まれる。なお、カラオケプログラムは、例えば、ネットワークＮＷに接続された所定のサーバからダウンロードされるようにしても良い。或いは、カラオケプログラムは、例えば、記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしても良い。

制御部１は、ＣＰＵがプログラムを読み出して実行することにより、カラオケデータの取得、保存、及び演奏等の制御を行う。なお、制御部１におけるフラッシュメモリには、この制御部１を備えるコマンダＣｍ−ｎ自身に割り当てられたコマンダ番号及びＩＰアドレス等が記憶される。

また、制御部１は、タイマ機能及び時計機能を有する。例えば、ＣＰＵが、計時機能を用いてタイマのカウントを行う。

記憶部２は、コンテンツリスト、及びカラオケデータ等を記憶するためのハードディスクドライブ等から構成される。カラオケデータは、曲番に相当するローカルファイル名が付与されたファイルとして記憶される。また、カラオケデータには、音声データ、字幕データ、及び映像データが含まれる。音声データは、演奏曲を音声出力するための例えばＭＩＤＩ（Musical Instrument Digital Interface）等のデータである。字幕データは、演奏曲の演奏中に歌詞を表示するためのデータである。映像データは、演奏曲の演奏中に背景映像を表示するためのデータである。

通信部３は、例えば固有のＭＡＣアドレスが割り当てられたイーサネット（登録商標）カード等から構成され、店舗ネットワークＮＬｍに接続されている。各コマンダＣｍ−ｎの通信部３は、店舗ネットワークＮＬｍを介した代表コマンダＭＣｍとの間の通信の制御を行う。また、代表コマンダＭＣｍの通信部３は、店舗ネットワークＮＬｍを介したルータＲｍとの間の通信の制御を行う。

入力部４は、例えば、ユーザが演奏曲を検索するための検索端末と無線通信により接続可能になっている。入力部４は、検索端末から演奏曲の再生指令を入力すると、この再生指令を制御部１に出力する。なお、再生指令には、例えば演奏曲の曲番が含まれる。

バッファメモリ５は、通信部３を介して受信されたカラオケデータ等を一時蓄積する。バッファメモリ５に蓄積されたカラオケデータは記憶部２に出力され、記憶保存される。

デコーダ部６、映像処理部７、表示部８、音声処理部９、及びスピーカ９ａは、制御部１による演奏制御の下、記憶部２に保存されたカラオケデータを再生出力するためのものである。なお、音声処理部９は、図示しない音源を有する。

デコーダ部６は、カラオケデータに含まれる音声データ、字幕データ、及び映像データの復号化等のデコード処理を行う。映像処理部７は、デコーダ部６によりデコードされた字幕データ及び映像データを映像信号として再生する。そして、表示部８は、映像処理部７により再生された映像信号に基づきディスプレイに字幕及び背景映像を表示する。一方、音声処理部９は、デコーダ部６によりデコードされた音声データを、音源により音声信号として再生する。そして、スピーカ９ａは、音声処理部９により再生された音声信号を音波として出力する。

なお、表示部８及びスピーカ９ａは、別装置に設けられるものであってもよい。この場合は、コマンダＣｍ−ｎは、再生した映像信号及び音声信号を別装置に供給することになる。

［３．ルータＲｍの構成及び機能等］
次に、図４を参照して、ルータＲｍの構成及び機能について説明する。

図４は、ルータＲｍの概要構成例を示す図である。

ルータＲｍは、図４に示すように、ＩＰパケット中継処理部１１と、ノード処理部１２と、記憶部１３と、通信部１４と、バッファメモリ１５と、を備えて構成される。ＩＰパケット中継処理部１１、ノード処理部１２、記憶部１３、通信部１４、及びバッファメモリ１５はバス１６を介して相互に接続されている。

なお、各ルータＲｍには、ＩＰアドレスが割り当てられている。

ＩＰパケット中継処理部１１は、ＯＳＩ（Open Systems Interconnection）参照モデルの第３層であるネットワーク層において、他のルータ又はホストからのＩＰパケットを中継する処理を行う。ＩＰパケット中継処理部１１は、ＩＰパケットを中継するために用いるルーティングテーブルを有する。なお、ＩＰパケット中継処理部１１の機能は、公知のルータ又はＬ３スイッチングハブと同様であるので、詳しい説明を省略する。

ノード処理部１２は、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種設定データ及びプログラムを記憶するフラッシュメモリ等から構成される。ノード処理部１２は、通信制御手段、受信手段、取得手段、及び送信手段等の一例である。プログラムには、ＣＰＵにノードとしての処理を実行させるためのノードプログラムが含まれる。そして、ノード処理部１２は、ＣＰＵがプログラムを読み出して実行することにより、代表コマンダＭＣｍからの要求に応じてカラオケデータの送信処理を行う。また、ノード処理部１２は、通信制御手段として、オーバーレイネットワークＯＮによる通信を制御する。そして、ノード処理部１２は、オーバーレイネットワークＯＮにおいて、ユーザノード、ルートノード、及びコンテンツ保持ノード等の少なくとも何れか一つのノードとしての処理を行う。

記憶部１３は、各種データ等を記憶するためのハードディスクドライブ等から構成される。具体的には、記憶部１３には、カラオケデータ、コンテンツリスト、及びインデックス情報が記憶されている。また、記憶部１３には、オーバーレイネットワークＯＮで使用されるＤＨＴを用いたルーティングテーブルが記憶されている。さらに、記憶部１３には、ディストリビュータＤＴのＩＰアドレスと、サポータＳＰのＩＰアドレスと、センターサーバＣＳのＩＰアドレス等とが記憶されている。

通信部１４は、例えば固有のＭＡＣアドレスが割り当てられたイーサネット（登録商標）カード等から構成され、店舗ネットワークＮＬｍ及びネットワークＮＷに接続されている。そして、通信部１４は、店舗ネットワークＮＬｍを介した代表コマンダＭＣｍとの間の通信の制御を行う。また、通信部１４は、ネットワークＮＷを介した他のルータＲｍ、ディストリビュータＤＴ、サポータＳＰ、又はセンターサーバＣＳとの間の通信の制御を行う。

バッファメモリ１５は、通信部１４を介して受信されたカラオケデータを一時蓄積する。バッファメモリ１５に蓄積されたカラオケデータは記憶部１３に出力され、記憶保存される。

［４．カラオケシステムＳの動作］
次に、図５乃至図１０を参照して、カラオケシステムＳの動作について説明する。

図５は、コマンダＣｍ−ｎの制御部１におけるメイン処理を示すフローチャートである。なお、以下の説明においては、店舗Ｐ１を一例として挙げ、店舗Ｐ１における店舗ネットワークＮＬ１に接続されたコマンダＣ１−１を例にとって説明する。

図５に示す処理は、例えばコマンダＣ１−１の起動により開始される。コマンダＣ１−１の制御部１は、先ず、代表コマンダの通知要求を示す代表コマンダ通知要求メッセージを店舗ネットワークＮＬ１内にマルチキャスト又はブロードキャストする（ステップＳ１）。つまり、代表コマンダ通知要求メッセージは、マルチキャスト又はブロードキャストにより、店舗ネットワークＮＬ１を介して複数のコマンダＣ１−２，３，４に送信される。代表コマンダ通知要求メッセージは、代表コマンダに対して、代表コマンダであること示す通知を要求するメッセージである。制御部１は、代表コマンダ通知要求メッセージを送信すると、代表コマンダ通知応答メッセージの受信を待機するための待機時間判定用のタイマのカウントを開始する。なお、代表コマンダ通知要求メッセージは、代表カラオケ装置通知要求情報の一例である。

次いで、コマンダＣ１−１の制御部１は、代表コマンダ通知応答メッセージを受信したか否かを判定する（ステップＳ２）。代表コマンダ通知応答メッセージは、代表コマンダの通知要求に応えるメッセージである。そして、制御部１は、代表コマンダ通知応答メッセージを受信していないと判定した場合には（ステップＳ２：ＮＯ）、ステップＳ３に進む。一方、制御部１は、代表コマンダ通知応答メッセージを受信したと判定した場合には（ステップＳ２：ＹＥＳ）、ステップＳ４に進む。なお、代表コマンダ通知応答メッセージには、代表コマンダＭＣ１のコマンダ番号が含まれている。

ステップＳ３では、コマンダＣ１−１の制御部１は、予め設定された待機時間が経過したか否かを、待機時間判定用のタイマがカウントアップしたかどうかより判定する。

そして、制御部１は、予め設定された待機時間が経過していないと判定した場合には（ステップＳ３：ＮＯ）、ステップＳ２に戻る。一方、制御部１は、予め設定された待機時間が経過したと判定した場合には（ステップＳ３：ＹＥＳ）、ステップＳ１０に進む。この場合、待機時間経過しても代表コマンダＭＣ１からの通知応答がないので、コマンダＣ１−１は、代表コマンダＭＣ１が動作不能になったと判断し、スレーブコマンダとして、代表コマンダ動作を行うことになる。

ステップＳ４では、コマンダＣ１−１の制御部１は、代表コマンダ通知応答メッセージに含まれるコマンダ番号と、代表コマンダ通知応答メッセージを受信したコマンダＣ１−１自身のコマンダ番号とに基づいて、代表コマンダを交代するための所定の条件を満たすか否かを判定する。

なお、代表コマンダ通知応答メッセージに含まれるコマンダ番号は、代表コマンダＭＣ１のコマンダ番号である。代表コマンダＭＣ１のコマンダ番号は、代表カラオケ装置情報の一例である。例えば、コマンダＣ１−１の制御部１は、代表コマンダＭＣ１のコマンダ番号と、コマンダＣ１−１自身のコマンダ番号との大小を比較する。この比較結果、制御部１は、コマンダＣ１−１自身のコマンダ番号より、代表コマンダＭＣ１のコマンダ番号の方が大きいか否かを判定する。ここでは、コマンダ番号が最も小さいコマンダが代表コマンダになるものとする。例えば店舗Ｐ１に新しく設置されるコマンダＣ１−ｍほど、コマンダ番号が大きい。これにより、最も古くから設置されているコマンダＣ１−ｍが代表コマンダになる。なお、コマンダ番号が最も大きいコマンダが代表コマンダになるように構成してもよい。この場合、最新のコマンダＣ１−ｍが代表コマンダになる。

そして、コマンダＣ１−１自身のコマンダ番号より、代表コマンダＭＣ１のコマンダ番号の方が小さい場合、コマンダＣ１−１の制御部１は、代表コマンダを交代するための所定の条件を満たさないと判定し（ステップＳ４：ＮＯ）、ステップＳ５に進む。一方、コマンダＣ１−１自身のコマンダ番号より、代表コマンダＭＣ１のコマンダ番号の方が大きい場合、制御部１は、代表コマンダを交代するための所定の条件を満たすと判定する（ステップＳ４：ＹＥＳ）。これにより、次の代表コマンダＭＣ１がコマンダＣ１−１に決定される。そして、処理はステップＳ９に進む。このように、コマンダ番号の大きさによって、代表コマンダＭＣ１が決定されるように構成すれば、代表コマンダを動的に変更することを、より迅速に行うことができる。

なお、コマンダＣ１−ｎが店舗Ｐ１内の部屋毎に設置されている場合、部屋の使用／非使用によって、代表コマンダＭＣ１が決定されるように構成しても良い。この場合、使用／非使用の状態は、例えば、店舗Ｐ１に設置された管理用コンピュータにより管理される。管理コンピュータは、店舗Ｐ１に例えば１台設けられており、全部屋の空き状況等を管理する。また、管理用コンピュータは、店舗ネットワークＮＬ１に接続される。各コマンダＣ１−ｍは、夫々が設置された部屋の使用／非使用の状態を示す情報を、管理用コンピュータから店舗ネットワークＮＬ１を介して受信する。そして、例えば、コマンダＣ１−１は、上記ステップＳ４において、コマンダＣ１−１が設置された部屋が使用であるか否かを判定する。コマンダＣ１−１が設置された部屋が使用である場合、コマンダＣ１−１の制御部１は、代表コマンダを交代するための所定の条件を満たさないと判定し（ステップＳ４：ＮＯ）、ステップＳ５に進む。一方、コマンダＣ１−１が設置された部屋が不使用である場合、制御部１は、代表コマンダを交代するための所定の条件を満たすと判定し（ステップＳ４：ＹＥＳ）、ステップＳ９に進む。このように、部屋の使用／非使用によって、代表コマンダＭＣ１が決定されるように構成すれば、カラオケ利用者に利用されていないコマンダを代表コマンダとすることができる。従って、代表コマンダの動作を円滑に実行することができる。 ステップＳ５では、コマンダＣ１−１の制御部１は、現在時刻が、カラオケデータのコンテンツ取得時刻になったか否かを判定する。コンテンツ取得時刻は、カラオケデータの取得を開始するために設定された時刻である。コンテンツ取得時刻は、例えば、コマンダＣ１−ｎ毎に時間をずらすように設定される。そして、制御部１は、コンテンツ取得時刻になったと判定した場合には（ステップＳ５：ＹＥＳ）、ステップＳ６に進む。一方、制御部１は、コンテンツ取得時刻がなっていないと判定した場合には（ステップＳ５：ＮＯ）、ステップＳ７に進む。

ステップＳ６では、コマンダＣ１−１の制御部１は、非代表コマンダのコンテンツ取得処理を実行する。

図６は、図５に示すステップＳ６における非代表コマンダのコンテンツ取得処理の詳細を示すフローチャートである。

図６に示すステップＳ６１では、コマンダＣ１−１の制御部１は、例えば記憶部２に記憶されている処理済コンテンツリストリビジョンを、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に送信する。このとき送信される処理済コンテンツリストリビジョンは、記憶されている処理済コンテンツリストリビジョンのうち、最新の処理済コンテンツリストリビジョンである。最新の処理済コンテンツリストリビジョンとは、番号が最も大きい処理済コンテンツリストリビジョンである。

なお、このとき、コマンダＣ１−１の制御部１は、代表コマンダＭＣ１を特定するために、ステップＳ１と同様、代表コマンダ通知要求メッセージを店舗ネットワークＮＬ１内にマルチキャスト又はブロードキャストしてもよい。これは、ステップＳ１で代表コマンダ通知応答メッセージが受信された後、代表コマンダが変わる場合があるためである。

ステップＳ６１で送信された処理済コンテンツリストリビジョンは、後述するステップＳ１０６で代表コマンダＭＣ１により受信される。そして、処理済コンテンツリストリビジョンの送信に対する応答としてコンテンツリスト一覧が、代表コマンダＭＣ１から送信されてくる。コマンダＣ１−１の制御部１は、代表コマンダＭＣ１から送信されたコンテンツリスト一覧を受信する（ステップＳ６２）。受信されたコンテンツリスト一覧は、制御部１のＲＡＭに記憶される。

次いで、コマンダＣ１−１の制御部１は、コンテンツリスト一覧に記述されたコンテンツリストリビジョンを一つ選択する（ステップＳ６３）。なお、ステップＳ６３の処理は、コンテンツリスト一覧に記述された全てのコンテンツリストリビションが選択されるまで繰り返される。また、例えば、番号が小さいコンテンツリストリビジョンから選択される。

次いで、コマンダＣ１−１の制御部１は、選択したコンテンツリストリビションに対応するコンテンツリストの要求を示すリスト要求メッセージを、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に送信する（ステップＳ６４）。リスト要求メッセージは、コンテンツリストを要求するメッセージである。次いで、コマンダＣ１−１の制御部１は、代表コマンダＭＣ１から送信されたコンテンツリストを受信する（ステップＳ６５）。受信されたコンテンツリストは、制御部１のＲＡＭに記憶される。なお、コンテンツリストには、コマンダＣ１−１の記憶部２に記憶されていないカラオケデータのコンテンツのローカルファイル名等が記述されている。

次いで、コマンダＣ１−１の制御部１は、コンテンツリスト一覧に記述された全てのコンテンツリストリビジョンを選択したか否かを判定する（ステップＳ６６）。そして、制御部１は、全てのコンテンツリストリビジョンを選択していないと判定した場合には（ステップＳ６６：ＮＯ）、ステップＳ６３に戻る。一方、制御部１は、全てのコンテンツリストリビジョンを選択したと判定した場合には（ステップＳ６６：ＹＥＳ）、ステップＳ６７に進む。

ステップＳ６７では、コマンダＣ１−１の制御部１は、ステップＳ６５で受信され、記憶されたコンテンツリストを一つ選択する。

次いで、コマンダＣ１−１の制御部１は、選択したコンテンツリストに記述されたローカルファイル名を一つ選択する（ステップＳ６８）。つまり、コマンダＣ１−１の記憶部２に記憶されていないカラオケデータが決定される。

次いで、コマンダＣ１−１の制御部１は、決定したカラオケデータのコンテンツの要求を示すコンテンツ要求メッセージを、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に送信する（ステップＳ６９）。コンテンツ要求メッセージは、カラオケデータのコンテンツを要求するメッセージである。なお、コンテンツ要求メッセージは、カラオケデータの要求を示す要求情報の一例である。また、コンテンツ要求メッセージには、ステップＳ６８で選択されたローカルファイル名が含まれる。

次いで、コマンダＣ１−１の制御部１は、代表コマンダＭＣ１から送信されたカラオケデータを受信する（ステップＳ７０）。こうして、コマンダＣ１−１は、未だ取得していない新たなカラオケデータを、動的に取得することができる。受信されたカラオケデータは、バッファメモリ５に蓄積された後、ローカルファイル名が付与されたファイルとして記憶部２に記憶される。

次いで、コマンダＣ１−１の制御部１は、ステップＳ６７で選択されたコンテンツリストに記述された全てのローカルファイル名を選択したか否かを判定する（ステップＳ７１）。そして、制御部１は、全てのローカルファイル名を選択していないと判定した場合には（ステップＳ７１：ＮＯ）、ステップＳ６８に戻る。ステップＳ６８に戻ると、制御部１は、コンテンツリストに記述されたローカルファイル名のうち未だ選択していないローカルファイル名を一つ選択することになる。一方、制御部１は、全てのローカルファイル名を選択したと判定した場合には（ステップＳ７１：ＹＥＳ）、ステップＳ７２に進む。

ステップＳ７２では、コマンダＣ１−１の制御部１は、ステップＳ６８〜ステップＳ７０で処理されたコンテンツリストのコンテンツリストリビジョンを処理済として記録する。例えば、このように処理済となったコンテンツリストリビジョンは、上述した処理済コンテンツリストリビジョンとして記憶部２に記憶される。

次いで、コマンダＣ１−１の制御部１は、ステップＳ６５で受信され、記憶された全てのコンテンツリストを選択したか否かを判定する（ステップＳ７３）。そして、制御部１は、全てのコンテンツリストを選択していないと判定した場合には（ステップＳ７３：ＮＯ）、ステップＳ６７に戻る。ステップＳ６７に戻ると、制御部１は、上記記憶されたコンテンツリストのうち未だ選択していないコンテンツリストを一つ選択することになる。一方、制御部１は、全てのコンテンツリストを選択したと判定した場合には（ステップＳ７３：ＹＥＳ）、図５に示す処理に戻る。

次いで、図５に示すステップＳ７では、コマンダＣ１−１の制御部１は、現在時刻が、代表コマンダの通知要求時刻になったか否かを判定する。この通知要求時刻は、代表コマンダへ通知を要求するために設定された時刻である。通知要求時刻は、例えば所定時間間隔で到来するように設定される。そして、制御部１は、代表コマンダの通知要求時刻になったと判定した場合には（ステップＳ７：ＹＥＳ）、ステップＳ１に移行する。ステップＳ１に戻ると、制御部１は、代表コマンダ通知要求メッセージを店舗ネットワークＮＬ１内にマルチキャスト又はブロードキャストする。このように、代表コマンダ通知要求メッセージの送信は、定期的に行われる。従って、代表コマンダＭＣ１の交代が頻繁にあっても、各コマンダＣ１−ｎは迅速に代表コマンダＭＣ１を認識することができる。そのため、各コマンダＣ１−ｎと代表コマンダＭＣ１との通信の効率を向上させることができる。

一方、コマンダＣ１−１の制御部１は、代表コマンダの通知要求時刻になっていないと判定した場合には（ステップＳ７：ＮＯ）、ステップＳ８に進む。

ステップＳ８に示すその他の処理では、例えば再生指令に応じてカラオケデータの再生処理等が行われ、ステップＳ５に戻る。

一方、ステップＳ９では、コマンダＣ１−１の制御部１は、代表コマンダの交代を要求する代表コマンダ交代要求メッセージを、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に送信する。代表コマンダ交代要求メッセージは、代表コマンダに交代を要求するメッセージである。なお、代表コマンダ交代要求メッセージは、交代要求情報の一例である。こうして、次の代表コマンダＭＣ１がコマンダＣ１−１に交代される。従って、動的に代表コマンダＭＣ１を変更することができる。そのため、カラオケシステムＳにおいて安定してカラオケデータをコマンダに供給することができる。

次いで、コマンダＣ１−１の制御部１は、代表コマンダ動作を実行する（ステップＳ１０）。

図７は、図５に示すステップＳ１０における代表コマンダ動作の詳細を示すフローチャートである。

代表コマンダ動作では、制御部１により、代表コマンダであることを示すフラグが“１”にセットされる。次いで、代表コマンダＭＣ１の制御部１は、代表コマンダ通知要求メッセージを受信したか否かを判定する（ステップＳ１０１）。そして、制御部１は、代表コマンダ通知要求メッセージを受信していないと判定した場合には（ステップＳ１０１：ＮＯ）、ステップＳ１０３に進む。一方、制御部１は、代表コマンダ通知要求メッセージを受信したと判定した場合には（ステップＳ１０１：ＹＥＳ）、ステップＳ１０２に進む。

ステップＳ１０２では、代表コマンダＭＣ１の制御部１は、代表コマンダ通知要求メッセージを送信したコマンダＣ１−ｎに、店舗ネットワークＮＬ１を介して代表コマンダ通知応答メッセージを返信する。

次いで、代表コマンダＭＣ１の制御部１は、代表コマンダ交代要求メッセージを受信したか否かを判定する（ステップＳ１０３）。そして、制御部１は、代表コマンダ交代要求メッセージを受信していないと判定した場合には（ステップＳ１０３：ＮＯ）、ステップＳ１０４に進む。一方、制御部１は、代表コマンダ交代要求メッセージを受信したと判定した場合には（ステップＳ１０３：ＹＥＳ）、代表コマンダであることを示すフラグを“０”にセットする。こうして、代表コマンダ動作が終了し、図５に示す処理に戻る。

ステップＳ１０４では、代表コマンダＭＣ１の制御部１は、現在時刻が、カラオケデータのコンテンツ取得時刻になったか否かを判定する。そして、制御部１は、コンテンツ取得時刻になったと判定した場合には（ステップＳ１０４：ＹＥＳ）、ステップＳ１０５に進む。なお、ステップＳ１０５に示す代表コマンダのコンテンツ取得処理については後述する。

一方、代表コマンダＭＣ１の制御部１は、コンテンツ取得時刻になっていないと判定した場合には（ステップＳ１０４：ＮＯ）、ステップＳ１０６に進む。

ステップＳ１０６では、代表コマンダＭＣ１の制御部１は、処理済コンテンツリストリビジョンを受信したか否かを判定する。そして、制御部１は、処理済コンテンツリストリビジョンを受信していないと判定した場合には（ステップＳ１０６：ＮＯ）、ステップＳ１１２に進む。一方、制御部１は、処理済コンテンツリストリビジョンを受信したと判定した場合には（ステップＳ１０６：ＹＥＳ）、ステップＳ１０７に進む。

ステップＳ１０７では、代表コマンダＭＣ１の制御部１は、記憶部２に記憶されているコンテンツリストを一つ選択する。

次いで、代表コマンダＭＣ１の制御部１は、選択したコンテンツリストのコンテンツリストリビジョンが、ステップＳ１０６で受信された処理済コンテンツリストリビジョンより新しいか否かを判定する（ステップＳ１０８）。そして、制御部１は、処理済コンテンツリストリビジョンより新しい、言い換えれば、番号が大きいと判定した場合には（ステップＳ１０８：ＹＥＳ）、ステップＳ１０９に進む。一方、制御部１は、処理済コンテンツリストリビジョンより新しくないと判定した場合には（ステップＳ１０８：ＮＯ）、ステップＳ１１０に進む。

ステップＳ１０９では、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧に、新しいと判定したコンテンツリストのコンテンツリストリビジョン及びコンテンツリストＩＤを記述する。

ステップＳ１１０では、代表コマンダＭＣ１の制御部１は、記憶部２に記憶された全てのコンテンツリストを選択したか否かを判定する。そして、制御部１は、全てのコンテンツリストを選択していないと判定した場合には（ステップＳ１１０：ＮＯ）、ステップＳ１０７に戻る。ステップＳ１０７に戻ると、制御部１は、上記記憶されたコンテンツリストのうち未だ選択していないコンテンツリストを一つ選択することになる。一方、制御部１は、全てのコンテンツリストを選択したと判定した場合には（ステップＳ１１０：ＹＥＳ）、ステップＳ１１１に進む。

ステップＳ１１１では、代表コマンダＭＣ１の制御部１は、処理済コンテンツリストリビジョンを送信したコマンダＣ１−ｎに、店舗ネットワークＮＬ１を介してコンテンツリスト一覧を返信する。このコンテンツリスト一覧には、ステップＳ１０９で記述されたコンテンツリストリビジョン及びコンテンツリストＩＤが記述されている。

ステップＳ１１２では、代表コマンダＭＣ１の制御部１は、リスト要求メッセージを受信したか否かを判定する。そして、制御部１は、リスト要求メッセージを受信していないと判定した場合には（ステップＳ１１２：ＮＯ）、ステップＳ１１５に進む。一方、制御部１は、リスト要求メッセージを受信したと判定した場合には（ステップＳ１１２：ＹＥＳ）、ステップＳ１１３に進む。

ステップＳ１１３では、代表コマンダＭＣ１の制御部１は、リスト要求メッセージに含まれるコンテンツリストリビションに対応するコンテンツリストを記憶部２から取得する。

次いで、代表コマンダＭＣ１の制御部１は、取得したコンテンツリストを、リスト要求メッセージを送信したコマンダＣ１−ｎに返信する（ステップＳ１１４）。

ステップＳ１１５では、代表コマンダＭＣ１の制御部１は、コンテンツ要求メッセージを受信したか否かを判定する。そして、制御部１は、コンテンツ要求メッセージを受信していないと判定した場合には（ステップＳ１１５：ＮＯ）、ステップＳ１１８に進む。一方、制御部１は、コンテンツ要求メッセージを受信したと判定した場合には（ステップＳ１１５：ＹＥＳ）、ステップＳ１１６に進む。

ステップＳ１１６では、代表コマンダＭＣ１の制御部１は、コンテンツ要求メッセージに含まれるローカルファイル名に対応するカラオケデータを記憶部２から取得する。

次いで、代表コマンダＭＣ１の制御部１は、取得したカラオケデータを、コンテンツ要求メッセージを送信したコマンダＣ１−ｎに返信する（ステップＳ１１７）。

ステップＳ１１８に示すその他の処理では、例えば再生指令に応じてカラオケデータの再生処理等が行われ、ステップＳ１０１に戻る。

一方、ステップＳ１０５では、代表コマンダのコンテンツ取得処理が実行される。

図８（Ａ）は、図７に示すステップＳ１０５における代表コマンダのコンテンツ取得処理の詳細を示すフローチャートである。図８（Ｂ）は、ルータＲｍのノード処理部１２におけるコンテンツ送信処理を示すフローチャートである。

図８（Ａ）に示すステップＳ１５１におけるコンテンツリスト取得処理は、センターサーバＣＳを利用する場合と、センターサーバＣＳを利用しない場合とがある。図９（Ａ）は、センターサーバＣＳを利用する場合におけるコンテンツリスト取得処理の詳細を示すフローチャートである。図１０（Ａ）は、センターサーバＣＳを利用しない場合におけるコンテンツリスト取得処理の詳細を示すフローチャートである。

先ず、図９（Ａ）乃至（Ｃ）を参照して、センターサーバＣＳを利用する場合について説明する。図９（Ｂ）は、センターサーバＣＳにおけるコンテンツリスト一覧送信処理を示すフローチャートである。図９（Ｃ）は、ルータＲｍのノード処理部１２におけるコンテンツリスト送信処理を示すフローチャートである。

なお、この場合、代表コマンダＭＣ１には、センターサーバＣＳのＩＰアドレス等が記憶されている。これにより、代表コマンダＭＣ１は、店舗ネットワークＮＬ１及びネットワークＮＷを介してセンターサーバＣＳにアクセス可能になっている。

図９（Ａ）に示すステップＳ１６１では、代表コマンダＭＣ１の制御部１は、例えば記憶部２に記憶されている処理済コンテンツリストリビジョンを、店舗ネットワークＮＬ１及びネットワークＮＷを介してセンターサーバＣＳに送信する。

センターサーバＣＳは、図９（Ｂ）に示すように、代表コマンダＭＣ１から送信された処理済コンテンツリストリビジョンを受信する（ステップＳ２０１）。

なお、ステップＳ２０２〜Ｓ２０５の処理は、図７に示すステップＳ１０７〜Ｓ１１０の処理と同様であるので、重複する説明を省略する。

図９（Ｂ）に示すステップＳ２０６では、センターサーバＣＳは、コンテンツリスト一覧を、ネットワークＮＷ及び店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に返信する。

代表コマンダＭＣ１の制御部１は、図９（Ａ）に示すように、センターサーバＣＳから送信されたコンテンツリスト一覧を受信する（ステップＳ１６２）。受信されたコンテンツリスト一覧は、制御部１のＲＡＭに記憶される。

次いで、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧に記述されたコンテンツリストＩＤを一つ選択する（ステップＳ１６３）。

次いで、代表コマンダＭＣ１の制御部１は、選択したコンテンツリストＩＤに対応するコンテンツリストの要求を示すリスト要求メッセージを、店舗ネットワークＮＬ１を介してルータＲ１に送信する（ステップＳ１６４）。なお、リスト要求メッセージには、要求するコンテンツリストのコンテンツリストＩＤが含まれる。

ルータＲ１は、図９（Ｃ）に示すように、代表コマンダＭＣ１から送信されたリスト要求メッセージを受信する（ステップＳ３０１）。

次いで、ルータＲ１のノード処理部１２は、受信されたリスト要求メッセージからコンテンツリストＩＤを取得する（ステップＳ３０２）。

次いで、ルータＲ１のノード処理部１２は、取得したコンテンツリストＩＤに対応するコンテンツリストを、オーバーレイネットワークＯＮによる通信により他のルータＲｍから取得する（ステップＳ３０３）。つまり、上述したように、ノード処理部１２は、取得したコンテンツリストＩＤに対応するコンテンツリストの所在をルートノードに問い合わせる。これにより、ノード処理部１２は、ルートノードからインデックス情報を取得する。そして、ノード処理部１２は、取得したインデックス情報に基づき、コンテンツ保持ノードにアクセスしてコンテンツリストを取得する。

次いで、ルータＲ１のノード処理部１２は、取得したコンテンツリストを、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に返信する（ステップＳ３０４）。

代表コマンダＭＣ１の制御部１は、図９（Ａ）に示すように、ルータＲ１から送信されたコンテンツリストを受信する（ステップＳ１６５）。受信されたコンテンツリストは、制御部１のＲＡＭに記憶される。

次いで、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧に記述された全てのコンテンツリストＩＤを選択したか否かを判定する（ステップＳ１６６）。そして、制御部１は、全てのコンテンツリストＩＤを選択していないと判定した場合には（ステップＳ１６６：ＮＯ）、ステップＳ１６３に戻る。一方、制御部１は、全てのコンテンツリストＩＤを選択したと判定した場合には（ステップＳ１６６：ＹＥＳ）、図８に示す処理に戻る。

次に、図１０（Ａ）乃至（Ｃ）を参照して、センターサーバＣＳを利用しない場合について説明する。図１０（Ｂ）は、ルータＲｍのノード処理部１２におけるコンテンツリスト一覧送信処理を示すフローチャートである。図１０（Ｃ）は、ルータＲｍのノード処理部１２におけるコンテンツリスト送信処理を示すフローチャートである。

なお、この場合、各ルータＲｍには、例えば配信センタＣ内の所定のサーバから定期的に配信されるコンテンツリスト一覧が記憶されている。

図１０（Ａ）に示すステップＳ１７１では、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧要求メッセージを、店舗ネットワークＮＬ１を介してルータＲ１に送信する。コンテンツリスト一覧要求メッセージは、コンテンツリスト一覧を要求するメッセージである。

ルータＲ１のノード処理部１２は、図１０（Ｂ）に示すように、代表コマンダＭＣ１から送信されたコンテンツリスト一覧要求メッセージを受信する（ステップＳ４０１）。

次いで、ルータＲ１のノード処理部１２は、記憶部１３からコンテンツリスト一覧を取得する（ステップＳ４０２）。

次いで、ルータＲ１のノード処理部１２は、取得したコンテンツリスト一覧を、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に返信する（ステップＳ４０３）。

代表コマンダＭＣ１の制御部１は、図１０（Ａ）に示すように、ルータＲ１から送信されたコンテンツリスト一覧を受信する（ステップＳ１７２）。受信されたコンテンツリスト一覧は、制御部１のＲＡＭに記憶される。

次いで、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧に記述されたコンテンツリビジョンを一つ選択する（ステップＳ１７３）。

次いで、代表コマンダＭＣ１の制御部１は、選択したコンテンツリストリビジョンが、記憶部２に記憶されている処理済コンテンツリストリビジョンより新しいか否かを判定する（ステップＳ１７４）。そして、制御部１は、処理済コンテンツリストリビジョンより新しいと判定した場合には（ステップＳ１７４：ＹＥＳ）、ステップＳ１７５に進む。一方、制御部１は、処理済コンテンツリストリビジョンより新しくないと判定した場合には（ステップＳ１７４：ＮＯ）、ステップＳ１７８に進む。

ステップＳ１７５では、代表コマンダＭＣ１の制御部１は、選択したコンテンツリストリビジョンに対応するコンテンツリストの要求を示すリスト要求メッセージを、店舗ネットワークＮＬ１を介してルータＲ１に送信する。リスト要求メッセージには、要求するコンテンツリストのコンテンツリストＩＤが含まれる。

代表コマンダＭＣ１の制御部１は、図１０（Ａ）に示すように、ルータＲ１から送信されたコンテンツリストを受信する（ステップＳ１７６）。

次いで、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧に記述された全てのコンテンツリストリビジョンを選択したか否かを判定する（ステップＳ１７７）。そして、制御部１は、全てのコンテンツリストリビジョンを選択していないと判定した場合には（ステップＳ１７７：ＮＯ）、ステップＳ１７３に戻る。一方、制御部１は、全てのコンテンツリストリビジョンを選択したと判定した場合には（ステップＳ１７７：ＹＥＳ）、図８に示す処理に戻る。

なお、図１０（Ｃ）に示すステップＳ５０１〜Ｓ５０４の処理は、図９（Ｃ）に示すステップＳ３０１〜Ｓ３０４の処理と同様であるので、重複する説明を省略する。

図８（Ａ）に戻り、代表コマンダＭＣ１の制御部１は、ステップＳ１５１で取得され、記憶されたコンテンツリストを一つ選択する（ステップＳ１５２）。

次いで、代表コマンダＭＣ１の制御部１は、選択したコンテンツリストに記述されたコンテンツＩＤを一つ選択する（ステップＳ１５３）。

次いで、コマンダＣ１−１の制御部１は、カラオケデータのコンテンツの要求を示すコンテンツ要求メッセージを、店舗ネットワークＮＬ１を介してルータＲ１に送信する（ステップＳ１５４）。このコンテンツ要求メッセージには、ステップＳ１５３で選択されたコンテンツＩＤが含まれる。

ルータＲ１は、図８（Ｂ）に示すように、代表コマンダＭＣ１から送信されたコンテンツ要求メッセージを受信する（ステップＳ６０１）。

次いで、ルータＲ１のノード処理部１２は、受信されたコンテンツ要求メッセージからコンテンツＩＤを取得する（ステップＳ６０２）。

次いで、ルータＲ１のノード処理部１２は、取得したコンテンツＩＤに対応するカラオケデータを、オーバーレイネットワークＯＮによる通信により他のルータＲｍから取得する（ステップＳ６０３）。なお、ステップＳ６０３の具体的な処理の流れは、上述したステップＳ３０３と同様である。

次いで、ルータＲ１のノード処理部１２は、取得したカラオケデータを、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に返信する（ステップＳ６０４）。

代表コマンダＭＣ１の制御部１は、図８（Ａ）に示すように、ルータＲ１から送信されたカラオケデータを受信する（ステップＳ１５５）。受信されたカラオケデータは、バッファメモリ５に蓄積された後、ローカルファイル名が付与されたファイルとして記憶部２に記憶される。

次いで、代表コマンダＭＣ１の制御部１は、ステップＳ１５２で選択されたコンテンツリストに記述された全てのコンテンツＩＤを選択したか否かを判定する（ステップＳ１５６）。そして、制御部１は、全てのコンテンツＩＤを選択していないと判定した場合には（ステップＳ１５６：ＮＯ）、ステップＳ１５３に戻る。ステップＳ１５３に戻ると、制御部１は、コンテンツリストに記述されたコンテンツＩＤのうち未だ選択していないコンテンツＩＤを一つ選択することになる。一方、制御部１は、全てのコンテンツＩＤを選択したと判定した場合には（ステップＳ１５６：ＹＥＳ）、ステップＳ１５７に進む。

ステップＳ１５７では、代表コマンダＭＣ１の制御部１は、ステップＳ１５３〜ステップＳ１５６で処理されたコンテンツリストのコンテンツリストリビジョンを処理済として記録する。

次いで、代表コマンダＭＣ１の制御部１は、ステップＳ１５１で取得され、記憶された全てのコンテンツリストを選択したか否かを判定する（ステップＳ１５８）。そして、制御部１は、全てのコンテンツリストを選択していないと判定した場合には（ステップＳ１５８：ＮＯ）、ステップＳ１５２に戻る。一方、制御部１は、全てのコンテンツリストを選択したと判定した場合には（ステップＳ１５８：ＹＥＳ）、図５に示す処理に戻る。

以上説明したように、上記実施形態によれば、複数のコマンダＣｍ−ｎの中から選択された代表コマンダＭＣｍが代表してルータＲｍにカラオケデータを要求する。ルータＲｍは、要求に応じて、オーバーレイネットワークＯＮによる通信を利用して複数のルータＲｍの中の何れかのルータＲｍからカラオケデータを取得し、代表コマンダＭＣｍに送信する。そして、代表コマンダＭＣｍは、受信したカラオケデータを各コマンダＣｍ−ｎに送信する。従って、ある店舗Ｐ１に設置された複数のコマンダＣ１−ｎが、一斉に、別の店舗２に設置されたコマンダＣ２−ｎに対してカラオケデータの要求を行うことを防止でき、ネットワークＮＷに接続される各店舗Ｐｍの通信回線Ｋｍへの負荷を抑制し、カラオケデータの取得の遅延を回避することができる。

なお、上記実施形態においては、各コマンダＣｍ−ｎは、取得したコンテンツリストに基づき、未だ取得していないカラオケデータの要求を動的に代表コマンダＭＣｍに行うようにした。別の例として、代表コマンダＭＣｍが、取得したカラオケデータを各コマンダＣｍ−ｎにＰＵＳＨ配信するように構成してもよい。この場合、例えば、図８（Ａ）に示すステップＳ１５５において、代表コマンダＭＣ１は、受信したカラオケデータを各コマンダＣ１−ｎに配信する。この構成によれば、各コマンダＣ１−ｎがコンテンツリストに基づきカラオケデータを代表コマンダＭＣ１に要求する処理を削減することができる。

また、上記実施形態において、オーバーレイネットワークＯＮは、ＤＨＴを利用したアルゴリズムにより形成されるように構成した。しかし、これに限定されるものではなく、その他のアルゴリズムによりオーバーレイネットワークＯＮが形成されるものであっても良い。つまり、ＤＨＴ以外のルーティングテーブルがノードに用いられるシステムであっても良い。

また、上記実施形態において、代表コマンダＭＣｍは、図７に示すステップＳ１０４においてコンテンツ取得時刻となった場合に、処理済として記録されていない新たなコンテンツリビジョンに対応するカラオケデータのコンテンツだけをルータＲｍに要求して取得するように構成した。別の例として、代表コマンダＭＣｍは、各コマンダＣｍ−ｎからコンテンツの要求を受け付けた場合に、この要求に対応するカラオケデータのコンテンツをルータＲｍに要求して取得するように構成しても良い。この場合、ルータＲｍは、代表コマンダＭＣｍから要求されたカラオケデータのコンテンツを、オーバーレイネットワークＯＮによる通信により他のルータＲｍから取得する。そして、ルータＲｍは、取得したカラオケデータのコンテンツを代表コマンダＭＣｍに送信することになる。

なお、本発明は、上述したコマンダに限定されるものではなく、カラオケ装置として機能するものであればその他の装置であっても適用可能である。

１ 制御部
２ 記憶部
３ 通信部
４ 入力部
５ バッファメモリ
６ デコーダ部
７ 映像処理部
８ 表示部
９ 音声処理部
９ａ スピーカ
９ｂ バス
１１ ＩＰパケット中継処理部
１２ ノード処理部
１３ 記憶部
１４ 通信部
１５ バッファメモリ
１６ バス
ＤＴ ディストリビュータ
ＳＰ サポータ
ＣＳ センターサーバ
Ｃｍ−ｎ コマンダ
ＭＣｍ 代表コマンダ
Ｒｍ ルータ
ＮＷ ネットワーク
ＮＬｍ 店舗ネットワーク
ＯＮ オーバーレイネットワーク
Ｓ カラオケシステム

Claims (12)

1. 複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続され、
   前記カラオケ装置は、前記代表カラオケ装置から送信された前記カラオケデータを受信する第１受信手段を備え、
   前記代表カラオケ装置は、
   前記内部ネットワークを介して前記ノード装置に、前記カラオケデータの要求を示す要求情報を送信する第１送信手段と、
   前記ノード装置から送信された前記カラオケデータを受信する受信手段と、
   前記内部ネットワークを介して前記カラオケ装置に、前記受信されたカラオケデータを送信する第２送信手段と、
   を備え、
   前記ノード装置は、
   各前記拠点の複数の前記ノード装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークによる通信を制御する通信制御手段と、
   前記代表カラオケ装置から送信された前記要求情報を受信する受信手段と、
   前記通信制御手段により前記複数のノード装置の中の何れかのノード装置から前記要求情報に対応するカラオケデータを取得する取得手段と、
   前記内部ネットワークを介して前記代表カラオケ装置に、前記取得されたカラオケデータを送信する送信手段と、
   を備えることを特徴とするカラオケシステム。
2. 前記複数のカラオケ装置の中から、前記代表カラオケ装置が動作不能になったとき前記代表カラオケ装置の動作を行うスレーブカラオケ装置と、前記代表カラオケ装置とが少なくとも１つ決定されることを特徴とする請求項１に記載のカラオケシステム。
3. 前記カラオケ装置は、
   前記代表カラオケ装置の代表カラオケ装置情報であって、当該代表カラオケ装置から前記内部ネットワークを介して送信されてきた前記代表カラオケ装置情報を受信する第２受信手段と、
   前記受信された代表カラオケ装置情報と、前記代表カラオケ装置情報を受信したカラオケ装置自身のカラオケ装置情報とに基づいて、前記代表カラオケ装置を交代するための所定の条件を満たすか否かを判定する判定手段と、
   前記判定手段により前記条件を満たすと判定された場合には、前記内部ネットワークを介して前記代表カラオケ装置に、前記代表カラオケ装置の交代を要求する交代要求情報を送信する第１送信手段と、
   を更に備えることを特徴とする請求項１又は２に記載のカラオケシステム。
4. 前記判定手段は、前記受信された代表カラオケ装置情報に示される番号と、前記代表カラオケ装置情報を受信したカラオケ装置自身のカラオケ装置情報に示される番号との大小を比較し、当該比較結果が前記条件を満たすか否かを判定することを特徴とする請求項３に記載のカラオケシステム。
5. 前記カラオケ装置は、前記内部ネットワークを介して前記複数のカラオケ装置に、前記代表カラオケ装置の通知要求を示す代表カラオケ装置通知要求情報を、定期的に送信する第２送信手段と、を更に備え、
   前記第２受信手段は、前記代表カラオケ装置通知要求情報に応じて、前記代表カラオケ装置から送信されてきた前記代表カラオケ装置情報を受信することを特徴とする請求項３又は４に記載のカラオケシステム。
6. 前記代表カラオケ装置は、前記内部ネットワークを介して前記カラオケ装置に、前記カラオケデータのコンテンツリストを送信する第３送信手段を更に備え、
   前記カラオケ装置は、
   前記カラオケデータを記憶する記憶手段と、
   前記代表カラオケ装置から送信された前記コンテンツリストを受信する第３受信手段と、
   前記コンテンツリストの中で、前記記憶手段に記憶されていないカラオケデータを決定する決定手段と、
   前記内部ネットワークを介して前記代表カラオケ装置に、前記決定されたカラオケデータの要求を示す要求情報を送信する第３送信手段と、
   を更に備えることを特徴とする請求項１乃至５の何れか一項に記載のカラオケシステム。
7. 請求項１乃至６の何れか一項に記載のカラオケシステムに含まれる代表カラオケ装置であって、
   前記内部ネットワークを介して前記ノード装置に、前記カラオケデータの要求を示す要求情報を送信する第１送信手段と、
   前記ノード装置から送信された前記カラオケデータを受信する受信手段と、
   前記内部ネットワークを介して前記カラオケ装置に、前記受信されたカラオケデータを送信する第２送信手段と、
   を備えることを特徴とするカラオケ装置。
8. 請求項１乃至６の何れか一項に記載のカラオケシステムに含まれるノード装置であって、
   各前記拠点の複数の前記ノード装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークによる通信の制御する通信制御手段と、
   前記代表カラオケ装置から送信された前記要求情報を受信する受信手段と、
   前記通信制御手段により前記複数のノード装置の中の何れかのノード装置から前記要求情報に対応するカラオケデータを取得する取得手段と、
   前記内部ネットワークを介して前記代表カラオケ装置に、前記取得されたカラオケデータを送信する送信手段と、
   を備えることを特徴とするノード装置。
9. 請求項８に記載のノード装置の機能を備えることを特徴とするルータ。
10. 複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、各前記拠点の複数のノード装置との間で、外部ネットワークを介して形成されるオーバーレイネットワークにより情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは前記外部ネットワークに接続されるカラオケシステムの代表カラオケ装置に含まれるコンピュータに、
    前記内部ネットワークを介して前記ノード装置に、前記カラオケデータの要求を示す要求情報を送信する送信ステップと、
    前記ノード装置から送信された前記カラオケデータを受信する受信ステップと、
    前記内部ネットワークを介して前記カラオケ装置に、前記受信されたカラオケデータを送信する送信ステップと、
    を実行させるためのカラオケプログラム。
11. 複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続されるカラオケシステムのノード装置に含まれるコンピュータに、
    前記代表カラオケ装置から送信された前記カラオケデータの要求を示す要求情報を受信する受信ステップと、
    各前記拠点の複数の前記ノード装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークによる通信を制御する通信制御ステップと、
    前記通信制御ステップにより前記複数のノード装置の中の何れかのノード装置から前記要求情報に対応するカラオケデータを取得する取得ステップと、
    前記内部ネットワークを介して前記代表カラオケ装置に、前記取得されたカラオケデータを送信する送信ステップと、
    を実行させるためのノードプログラム。
12. カラオケデータ送信方法であって、
    複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続されており、
    前記カラオケデータ送信方法は、
    前記代表カラオケ装置が、前記内部ネットワークを介して前記ノード装置に、前記カラオケデータの要求を示す要求情報を送信する送信ステップと、
    前記ノード装置が、各前記拠点の複数の前記ノード装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークによる通信を制御する通信制御ステップと、
    前記ノード装置が、前記代表カラオケ装置から送信された前記要求情報を受信する受信ステップと、
    前記ノード装置が、前記通信制御ステップにより前記複数のノード装置の中の何れかのノード装置から前記要求情報に対応するカラオケデータを取得する取得ステップと、
    前記ノード装置が、前記内部ネットワークを介して前記代表カラオケ装置に、前記取得されたカラオケデータを送信する送信ステップと、
    前記代表カラオケ装置が、前記ノード装置から送信された前記カラオケデータを受信する受信ステップと、
    前記代表カラオケ装置が、前記内部ネットワークを介して前記カラオケ装置に、前記受信されたカラオケデータを送信する送信ステップと、
    を含むことを特徴とするカラオケデータ送信方法。

Images