(57)【要約】【課題】通信回線への負荷を抑制し、カラオケデータの取得の遅延を回避することが可能なカラオケシステム、カラオケ装置、カラオケプログラム、及びカラオケデータ送信方法を提供する。【解決手段】複数のコマンダＣｍ−ｎの中から決定された代表コマンダＭＣｍが、オーバーレイネットワークＯＮに参加する。オーバーレイネットワークＯＮに参加した代表コマンダＭＣｍは、オーバーレイネットワークＯＮに参加する複数の代表コマンダＭＣｍの中の何れかの代表コマンダＭＣｍからカラオケデータを取得する。そして、代表コマンダＭＣｍは、取得したカラオケデータを同じ店舗ネットワークＮＬｍに接続された各コマンダＣｍ−ｎに送信する。【選択図】図１
2011064975.tif 000002
【特許請求の範囲】
【請求項１】
複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続され、
前記カラオケ装置は、前記代表カラオケ装置から送信された前記カラオケデータを受信する第１受信手段を備え、
前記代表カラオケ装置は、
各前記拠点の前記内部ネットワークに接続された複数の代表カラオケ装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークに参加する参加処理を実行する制御手段と、
前記オーバーレイネットワークに参加する前記複数の代表カラオケ装置の中の何れかの代表カラオケ装置から前記カラオケデータを取得する取得手段と、
前記内部ネットワークを介して前記カラオケ装置に、前記取得されたカラオケデータを送信する第１送信手段と、
を備えることを特徴とするカラオケシステム。
【請求項２】
前記カラオケ装置は、
前記内部ネットワークを介して前記代表カラオケ装置に、前記カラオケデータの要求を示す要求情報を送信する第２送信手段を備え、
前記代表カラオケ装置は、
前記カラオケ装置から送信された前記要求情報を受信する第２受信手段を備え、
前記代表カラオケ装置の取得手段は、前記オーバーレイネットワークに参加する前記複数の代表カラオケ装置の中の何れかの代表カラオケ装置から前記要求情報に対応する前記カラオケデータを取得することを特徴とする請求項１に記載のカラオケシステム。
【請求項３】
前記カラオケシステムは、
前記複数のカラオケ装置の中から前記代表カラオケ装置を決定する管理カラオケ装置を備え、
前記管理カラオケ装置は、
各前記カラオケ装置から前記カラオケデータの再生に関する再生情報を取得する取得手段と、
前記取得された前記カラオケデータの再生情報に基づいて、前記代表カラオケ装置を決定する決定手段と、
を備えることを特徴とする請求項１又は２に記載のカラオケシステム。
【請求項４】
前記管理カラオケ装置の取得手段は、
前記各カラオケ装置から、最後にカラオケデータを再生してから再生待機状態にある待機時間を含む前記再生情報を取得し、
前記決定手段は、前記待機時間が最も長いカラオケ装置を前記代表カラオケ装置として決定することを特徴とする請求項３に記載のカラオケシステム。
【請求項５】
前記管理カラオケ装置の取得手段は、動作中の代表カラオケ装置が他の代表カラオケ装置との間で所定の情報の送信中又は受信中であるか否かを示す情報を取得し、
前記決定手段は、前記動作中の代表カラオケ装置が他の代表カラオケ装置との間で所定の情報の送信中又は受信中である場合には、前記代表カラオケ装置の決定を所定時間遅延させることを特徴とする請求項３又は４に記載のカラオケシステム。
【請求項６】
前記管理カラオケ装置は、
前記代表カラオケ装置として決定されたカラオケ装置と、動作中の代表カラオケ装置とが同一であるか否かを判定する判定手段と、
前記判定手段により前記代表カラオケ装置として決定されたカラオケ装置と動作中の代表カラオケ装置とが同一でないと判定された場合には、前記内部ネットワークを介して前記代表カラオケ装置として決定されたカラオケ装置に代表カラオケ装置としての動作を開始する要求を示す動作要求情報を送信する第３送信手段と、
前記判定手段により前記代表カラオケ装置として決定されたカラオケ装置と動作中の代表カラオケ装置とが同一でないと判定された場合には、前記動作中の代表カラオケ装置に代表カラオケ装置の交代を要求する交代要求情報を送信する第４送信手段と、
を備えることを特徴とする請求項３乃至５の何れか一項に記載のカラオケシステム。
【請求項７】
前記カラオケ装置は、
前記管理カラオケ装置に対応する管理カラオケ装置情報であって、当該管理カラオケ装置から前記内部ネットワークを介して送信されてきた前記管理カラオケ装置情報を受信する第３受信手段と、
前記受信された管理カラオケ装置情報と、前記管理カラオケ装置情報を受信したカラオケ装置自身のカラオケ装置情報とに基づいて、前記管理カラオケ装置を交代するための所定の条件を満たすか否かを判定する判定手段と、
前記判定手段により前記条件を満たすと判定された場合には、前記内部ネットワークを介して前記管理カラオケ装置に、前記管理カラオケ装置の交代を要求する交代要求情報を送信する第５送信手段と、
を更に備えることを特徴とする請求項３に記載のカラオケシステム。
【請求項８】
前記判定手段は、前記受信された管理カラオケ装置情報に示される番号と、前記管理カラオケ装置情報を受信したカラオケ装置自身のカラオケ装置情報に示される番号との大小を比較し、当該比較結果が前記条件を満たすか否かを判定することを特徴とする請求項７に記載のカラオケシステム。
【請求項９】
請求項１に記載のカラオケシステムに含まれる代表カラオケ装置であって、
各前記拠点の前記内部ネットワークに接続された複数の代表カラオケ装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークに参加する参加処理を実行する制御手段と、
前記オーバーレイネットワークに参加する前記複数の代表カラオケ装置の中の何れかの代表カラオケ装置から前記カラオケデータを取得する取得手段と、
前記内部ネットワークを介して前記カラオケ装置に、前記取得されたカラオケデータを送信する送信手段と、
を備えることを特徴とするカラオケ装置。
【請求項１０】
請求項６に記載のカラオケシステムに含まれる代表カラオケ装置であって、
前記管理カラオケ装置から送信された前記交代要求情報を受信する第３受信手段と、
前記交代要求情報を受信した場合には、前記オーバーレイネットワークから脱退する脱退処理を実行する制御手段と、
を備えることを特徴とするカラオケ装置。
【請求項１１】
請求項６に記載のカラオケシステムに含まれるカラオケ装置であって、
前記管理カラオケ装置から送信された前記動作要求情報を受信する第４受信手段と、
前記動作要求情報を受信した場合には、前記オーバーレイネットワークに参加する参加処理を実行する制御手段と、
を備えることを特徴とするカラオケ装置。
【請求項１２】
複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続されるカラオケシステムの代表カラオケ装置に含まれるコンピュータに、
各前記拠点の前記内部ネットワークに接続された複数の代表カラオケ装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークに参加する参加処理を実行する制御ステップと、
前記オーバーレイネットワークに参加する前記複数の代表カラオケ装置の中の何れかの代表カラオケ装置から前記カラオケデータを取得する取得ステップと、
前記内部ネットワークを介して前記カラオケ装置に、前記取得されたカラオケデータを送信する送信ステップと、
を実行させるためのカラオケプログラム。
【請求項１３】
カラオケデータ送信方法であって、
複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続されており、
前記カラオケデータ送信方法は、
前記代表カラオケ装置が、各前記拠点の前記内部ネットワークに接続された複数の代表カラオケ装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークに参加する参加処理を実行する制御ステップと、
前記代表カラオケ装置が、前記オーバーレイネットワークに参加する前記複数の代表カラオケ装置の中の何れかの代表カラオケ装置から前記カラオケデータを取得する取得ステップと、
前記代表カラオケ装置が、前記内部ネットワークを介して前記カラオケ装置に、前記取得されたカラオケデータを送信する送信ステップと、
を含むことを特徴とするカラオケデータ送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、カラオケデータを再生する複数のカラオケ装置から構成されるカラオケシステムの技術分野に関する。
【背景技術】
【０００２】
従来から、複数のコマンダと、各コマンダにカラオケデータを配信するサーバとを備えたカラオケシステムが知られている。なお、コマンダは、カラオケ装置の一例である。一般的に、コマンダとサーバとを接続する帯域の狭い通信回線で接続されている場合、複数のコマンダがサーバに一斉にアクセスするため、負荷集中により通信回線が所謂パンクする恐れがあった。例えば新曲配信時などは、通信回線がパンクする可能性が高い。そのため、従来のカラオケシステムでは、複数のコマンダの中の代表コマンダが、サーバからカラオケデータをダウンロードし他のコマンダに配信していた。
【０００３】
類似の技術として、特許文献１には、ホスト局が保有する曲データを電話回線を介して受信する複数のサーバと、前記サーバから曲データをダウンロードするコマンダとを備えたカラオケシステムが開示されている。このカラオケシステムにおいては、複数のサーバのうち電話回線に接続された一部のサーバがホスト局から曲データをダウンロードする。そして、ダウンロードしたサーバは、電話回線に接続されていないサーバに曲データを配信するようになっている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１０−１８７１７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、例えば、複数の店舗を運営するカラオケチェーン店等では、一つの店舗に、上述した代表コマンダが例えば１台設けられている。しかし、店舗数が増えると、例えば新曲配信時など、各店舗に設置された代表コマンダがサーバに一斉にアクセスすることで負荷集中に至る可能性がある。このような負荷集中を回避するため、例えば、各店舗に設置された複数のコマンダがネットワークを介してピアツーピア通信を行うことを可能としたピアツーピア通信方式のカラオケシステムが考えられる。このようなピアツーピア通信方式のカラオケシステムでは、例えばある店舗に設置されたコマンダと、別の店舗に設置されたコマンダとの間でピアツーピア通信を行う。
【０００６】
しかしながら、上記ピアツーピア通信方式のカラオケシステムでは、ある店舗に設置された複数のコマンダが、一斉に、別の店舗に設置されたコマンダに対してカラオケデータのリクエストを行うと、ネットワークに接続される店舗の通信回線への負荷が増大し、ひいては、カラオケデータの取得が遅延する問題が生じる可能性がある。
【０００７】
そこで、本発明は、以上の点等に鑑みてなされたものである。本発明は、通信回線への負荷を抑制し、カラオケデータの取得の遅延を回避することが可能なカラオケシステム、カラオケ装置、カラオケプログラム、及びカラオケデータ送信方法を提供すること等を課題とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、請求項１に記載の発明は、複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続され、前記カラオケ装置は、前記代表カラオケ装置から送信された前記カラオケデータを受信する第１受信手段を備え、前記代表カラオケ装置は、各前記拠点の前記内部ネットワークに接続された複数の代表カラオケ装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークに参加する参加処理を実行する制御手段と、前記オーバーレイネットワークに参加する前記複数の代表カラオケ装置の中の何れかの代表カラオケ装置から前記カラオケデータを取得する取得手段と、前記内部ネットワークを介して前記カラオケ装置に、前記取得されたカラオケデータを送信する第１送信手段と、を備えることを特徴とする。
【０００９】
請求項２に記載の発明は、請求項１に記載のカラオケシステムにおいて、前記カラオケ装置は、前記内部ネットワークを介して前記代表カラオケ装置に、前記カラオケデータの要求を示す要求情報を送信する第２送信手段を備え、前記代表カラオケ装置は、前記カラオケ装置から送信された前記要求情報を受信する第２受信手段を備え、前記代表カラオケ装置の取得手段は、前記オーバーレイネットワークに参加する前記複数の代表カラオケ装置の中の何れかの代表カラオケ装置から前記要求情報に対応する前記カラオケデータを取得することを特徴とする。
【００１０】
請求項３に記載の発明は、請求項１又は２に記載のカラオケシステムにおいて、前記カラオケシステムは、前記複数のカラオケ装置の中から前記代表カラオケ装置を決定する管理カラオケ装置を備え、前記管理カラオケ装置は、各前記カラオケ装置から前記カラオケデータの再生に関する再生情報を取得する取得手段と、前記取得された前記カラオケデータの再生情報に基づいて、前記代表カラオケ装置を決定する決定手段と、を備えることを特徴とする。
【００１１】
請求項４に記載の発明は、請求項３に記載のカラオケシステムにおいて、前記管理カラオケ装置の取得手段は、前記各カラオケ装置から、最後にカラオケデータを再生してから再生待機状態にある待機時間を含む前記再生情報を取得し、前記決定手段は、前記待機時間が最も長いカラオケ装置を前記代表カラオケ装置として決定することを特徴とする。
【００１２】
請求項５に記載の発明は、請求項３又は４に記載のカラオケシステムにおいて、前記管理カラオケ装置の取得手段は、動作中の代表カラオケ装置が他の代表カラオケ装置との間で所定の情報の送信中又は受信中であるか否かを示す情報を取得し、前記決定手段は、前記動作中の代表カラオケ装置が他の代表カラオケ装置との間で所定の情報の送信中又は受信中である場合には、前記代表カラオケ装置の決定を所定時間遅延させることを特徴とする。
【００１３】
請求項６に記載の発明は、請求項３乃至５の何れか一項に記載のカラオケシステムにおいて、前記管理カラオケ装置は、前記代表カラオケ装置として決定されたカラオケ装置と、動作中の代表カラオケ装置とが同一であるか否かを判定する判定手段と、前記判定手段により前記代表カラオケ装置として決定されたカラオケ装置と動作中の代表カラオケ装置とが同一でないと判定された場合には、前記内部ネットワークを介して前記代表カラオケ装置として決定されたカラオケ装置に代表カラオケ装置としての動作を開始する要求を示す動作要求情報を送信する第３送信手段と、前記判定手段により前記代表カラオケ装置として決定されたカラオケ装置と動作中の代表カラオケ装置とが同一でないと判定された場合には、前記動作中の代表カラオケ装置に代表カラオケ装置の交代を要求する交代要求情報を送信する第４送信手段と、を備えることを特徴とする。
【００１４】
請求項７に記載の発明は、請求項３に記載のカラオケシステムにおいて、前記カラオケ装置は、前記管理カラオケ装置に対応する管理カラオケ装置情報であって、当該管理カラオケ装置から前記内部ネットワークを介して送信されてきた前記管理カラオケ装置情報を受信する第３受信手段と、前記受信された管理カラオケ装置情報と、前記管理カラオケ装置情報を受信したカラオケ装置自身のカラオケ装置情報とに基づいて、前記管理カラオケ装置を交代するための所定の条件を満たすか否かを判定する判定手段と、前記判定手段により前記条件を満たすと判定された場合には、前記内部ネットワークを介して前記管理カラオケ装置に、前記管理カラオケ装置の交代を要求する交代要求情報を送信する第５送信手段と、を更に備えることを特徴とする。
【００１５】
請求項８に記載の発明は、請求項７に記載のカラオケシステムにおいて、前記判定手段は、前記受信された管理カラオケ装置情報に示される番号と、前記管理カラオケ装置情報を受信したカラオケ装置自身のカラオケ装置情報に示される番号との大小を比較し、当該比較結果が前記条件を満たすか否かを判定することを特徴とする。
【００１６】
請求項９に記載の発明は、請求項１に記載のカラオケシステムに含まれる代表カラオケ装置であって、各前記拠点の前記内部ネットワークに接続された複数の代表カラオケ装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークに参加する参加処理を実行する制御手段と、前記オーバーレイネットワークに参加する前記複数の代表カラオケ装置の中の何れかの代表カラオケ装置から前記カラオケデータを取得する取得手段と、前記内部ネットワークを介して前記カラオケ装置に、前記取得されたカラオケデータを送信する送信手段と、を備えることを特徴とする。
【００１７】
請求項１０に記載の発明は、請求項６に記載のカラオケシステムに含まれる代表カラオケ装置であって、前記管理カラオケ装置から送信された前記交代要求情報を受信する受信手段と、前記交代要求情報を受信した場合には、前記オーバーレイネットワークから脱退する脱退処理を実行する制御手段と、を備えることを特徴とする。
【００１８】
請求項１１に記載の発明は、請求項６に記載のカラオケシステムに含まれるカラオケ装置であって、前記管理カラオケ装置から送信された前記動作要求情報を受信する受信手段と、前記動作要求情報を受信した場合には、前記オーバーレイネットワークに参加する参加処理を実行する制御手段と、を備えることを特徴とする。
【００１９】
請求項１２に記載の発明は、複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続されるカラオケシステムの代表カラオケ装置に含まれるコンピュータに、各前記拠点の前記内部ネットワークに接続された複数の代表カラオケ装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークに参加する参加処理を実行する制御ステップと、前記オーバーレイネットワークに参加する前記複数の代表カラオケ装置の中の何れかの代表カラオケ装置から前記カラオケデータを取得する取得ステップと、前記内部ネットワークを介して前記カラオケ装置に、前記取得されたカラオケデータを送信する送信ステップと、を実行させるためのカラオケプログラムである。
【００２０】
請求項１３に記載の発明は、カラオケデータ送信方法であって、複数の拠点毎に構築される各内部ネットワークに接続され、カラオケデータを再生する複数のカラオケ装置と、前記複数のカラオケ装置の中から決定された代表カラオケ装置と、前記代表カラオケ装置との間で情報の送受信を行うノード装置とを前記内部ネットワーク毎に備え、前記各内部ネットワークは外部ネットワークに接続されており、前記カラオケデータ送信方法は、前記代表カラオケ装置が、各前記拠点の前記内部ネットワークに接続された複数の代表カラオケ装置との間で、前記外部ネットワークを介して形成されるオーバーレイネットワークに参加する参加処理を実行する制御ステップと、前記代表カラオケ装置が、前記オーバーレイネットワークに参加する前記複数の代表カラオケ装置の中の何れかの代表カラオケ装置から前記カラオケデータを取得する取得ステップと、前記代表カラオケ装置が、前記内部ネットワークを介して前記カラオケ装置に、前記取得されたカラオケデータを送信する送信ステップと、を含むことを特徴とする。
【発明の効果】
【００２１】
請求項１、９乃至１２に記載の発明によれば、複数のカラオケ装置の中から決定された代表カラオケ装置が、オーバーレイネットワークに参加する。オーバーレイネットワークに参加した代表カラオケ装置は、オーバーレイネットワークに参加する複数の代表カラオケ装置の中の何れかの代表カラオケ装置からカラオケデータを取得する。そして、代表カラオケ装置は、取得したカラオケデータを各カラオケ装置に送信する。従って、ある拠点に設置された複数のカラオケ装置が、一斉に、別の拠点に設置されたカラオケ装置に対してカラオケデータの要求を行うことを防止でき、ネットワークに接続される各拠点の通信回線への負荷を抑制し、カラオケデータの取得の遅延を回避することができる。
【００２２】
請求項２に記載の発明によれば、代表カラオケ装置は、同じ内部ネットワークに接続された各カラオケ装置からの要求に応じて、迅速にカラオケデータを送信することができる。
【００２３】
請求項３に記載の発明によれば、動的に代表カラオケ装置を決定することができる。
【００２４】
請求項４に記載の発明によれば、ユーザにより最も使用されていないカラオケ装置を代表カラオケ装置とすることができる。
【００２５】
請求項５に記載の発明によれば、代表カラオケ装置間の通信に支障をきたすことを回避することができる。
【００２６】
請求項６に記載の発明によれば、動的に代表カラオケ装置を変更することができる。
【００２７】
請求項７、８に記載の発明によれば、動的に管理カラオケ装置を変更することができる。
【図面の簡単な説明】
【００２８】
【図１】本実施形態に係るカラオケシステムＳの概要構成例を示す図である。
【図２】（Ａ）は、コンテンツリスト一覧の一例を示す図である。（Ｂ）は、コンテンツリストの一例を示す図である。
【図３】コマンダＣｍ−ｎの概要構成例を示す図である。
【図４】コマンダＣｍ−ｎの制御部１におけるメイン処理を示すフローチャートである。
【図５】図４に示すステップＳ６における管理コマンダ動作の詳細を示すフローチャートである。
【図６】図５に示すステップＳ６５におけるコマンダ状態取得処理の詳細を示すフローチャートである。
【図７】図４に示すステップＳ８における非代表コマンダのコンテンツ取得処理の詳細を示すフローチャートである。
【図８】図４に示すステップＳ１３における代表コマンダ動作の詳細を示すフローチャートである。
【図９】図８に示すステップＳ１３７における代表コマンダのコンテンツ取得処理の詳細を示すフローチャートである。
【図１０】（Ａ）は、センターサーバＣＳを利用する場合におけるコンテンツリスト取得処理の詳細を示すフローチャートである。（Ｂ）は、センターサーバＣＳにおけるコンテンツリスト一覧送信処理を示すフローチャートである。
【図１１】センターサーバＣＳを利用しない場合におけるコンテンツリスト取得処理の詳細を示すフローチャートである。
【図１２】変形形態において、コマンダＣｍ−ｎの制御部１におけるメイン処理を示すフローチャートである。
【発明を実施するための形態】
【００２９】
以下、本発明の実施形態を図面に基づいて説明する。
【００３０】
［１．カラオケシステムの構成及び動作の概要］
始めに、図１を参照して、本発明の一実施形態に係るカラオケシステムの構成及び動作の概要について説明する。
【００３１】
図１は、本実施形態に係るカラオケシステムＳの概要構成例を示す図である。
【００３２】
本実施形態に係るカラオケシステムＳにおいて利用されるカラオケデータは、図１に示す配信センタＣにより管理される。
【００３３】
配信センタＣには、ディストリビュータＤＴ、サポータＳＰ、センターサーバＣＳ、及びファイアーウォールＦＷが設置される。そして、ディストリビュータＤＴ、サポータＳＰ、及びセンターサーバＣＳは、ファイアーウォールＦＷを介してネットワークＮＷに接続されている。ネットワークＮＷは、外部ネットワークの一例である。また、ネットワークＮＷは、例えば、インターネットやＷＡＮ（Wide Area Network）等のパブリックネットワークである。
【００３４】
ディストリビュータＤＴは、新規のカラオケデータをカラオケシステムＳ内に配信するための装置である。サポータＳＰは、後述するオーバーレイネットワークＯＮにノード装置が参加する場合に、ノード装置から送信された参加リクエストを処理する装置である。ノード装置とは、オーバーレイネットワークＯＮを介して他のノード装置との間で各種情報の送受信を行う装置である。以下、ノード装置を、「ノード」という。センターサーバＣＳは、コンテンツリスト一覧を管理する装置である。コンテンツリスト一覧は、コンテンツリストの一覧表である。また、コンテンツリストは、カラオケシステムＳにおいて利用可能なカラオケデータのコンテンツの一覧表である。なお、センターサーバＣＳは設けず、コンテンツリスト一覧の管理はオーバーレイネットワークＯＮに参加しているノードが行うようにしても良い。
【００３５】
図２（Ａ）は、コンテンツリスト一覧の一例を示す図である。また、図２（Ｂ）は、コンテンツリストの一例を示す図である。
【００３６】
コンテンツリスト一覧には、図２（Ａ）に示すように、コンテンツリストのコンテンツリストリビジョンとコンテンツリストＩＤの組が複数記述される。コンテンツリストリビジョンは、例えばコンテンツリスト毎に付与されるシリアル番号である。また、コンテンツリストリビジョンは、例えば、コンテンツリストの発行時に付与される。また、コンテンツリストリビジョンは、例えば、コンテンツリストが発行される度に大きくなっていく。例えば、図２（Ａ）に示すコンテンツリスト一覧には、コンテンツリストリビジョンとして、「１」，「２」，「３」，「４」，「５」というシリアル番号が記述されている。この中で数値の最も大きいコンテンツリストリビジョン「５」が最新のコンテンツリストリビジョンである。そして、最新のコンテンツリストリビジョンが付与されたコンテンツリストが最新のコンテンツリストである。従って、コンテンツリストの新旧は、コンテンツリストリビジョンにより判断することができる。コンテンツリストＩＤは、コンテンツリスト毎に割り当てられる識別情報である。また、コンテンツリストＩＤは、例えば、コンテンツリストに係るデータを、所定のハッシュ関数によりハッシュ化した値である。ハッシュ関数としては、例えば、ＳＨＡ−１等が用いられる。或いは、例えば、システム管理者により、コンテンツリスト毎に一意のコンテンツリストＩＤが割り当てられるようにしても良い。
【００３７】
なお、コンテンツリストの発行は、新規のカラオケデータの配信時等の所定のタイミングで配信センタＣにより行われる。センターサーバＣＳ又はディストリビュータＤＴは、配信センタＣにより発行されたコンテンツリストをカラオケシステムＳ内に配信する。
【００３８】
コンテンツリストには、図２（Ｂ）に示すように、コンテンツのローカルファイル名とコンテンツＩＤの組が複数記述される。図２（Ｂ）に示すコンテンツリストには、コンテンツリストリビジョンとして「１」が付与されている。ローカルファイル名は、例えば、カラオケデータのコンテンツ毎に付与される曲番に相当する。コンテンツＩＤは、コンテンツ毎に割り当てられる識別情報である。また、コンテンツＩＤは、例えば、コンテンツ名＋任意の数値が、コンテンツリストＩＤを得るときと共通のハッシュ関数によりハッシュ化した値である。或いは、例えば、システム管理者により、コンテンツ毎に一意のコンテンツＩＤが割り当てられるようにしても良い。
【００３９】
また、カラオケシステムＳにおいては、図１に示すように、複数の店舗Ｐｍ（ｍ＝１，２，３・・・の何れか）毎に店舗ネットワークＮＬｍが構築されている。店舗Ｐｍは、拠点の一例である。店舗ネットワークＮＬｍは、内部ネットワークの一例である。また、店舗ネットワークＮＬｍは、例えば、ＬＡＮ（Local Area Network）等のプライベートネットワークである。なお、店舗ネットワークＮＬｍは、複数のＬＡＮが相互接続して構築されたＣＡＮ（Campus Area Network）等のネットワークであっても良い。
【００４０】
各店舗ネットワークＮＬｍには、複数のコマンダＣｍ−ｎ（ｎ＝１，２，３・・・の何れか）とルータＲｍとが接続されている。このように、カラオケシステムＳは、複数のコマンダＣｍ−ｎを店舗ネットワークＮＬｍ毎に備える。なお、本実施形態におけるコマンダは、カラオケ装置の一例である。コマンダＣｍ−ｎは、カラオケデータを再生する装置である。例えば、店舗Ｐｍ内の各部屋には１台のコマンダＣｍ−ｎが設置される。また、ルータＲｍは、複数のネットワーク間でＩＰ（Internet Protocol）パケットを中継する中継機器である。
【００４１】
そして、各店舗Ｐｍにおいて、複数のコマンダＣｍ−ｎの中からは、管理コマンダＫＣｍと、代表コマンダＭＣｍと、スレーブコマンダ（図示せず）と、が少なくとも１つ決定される。管理コマンダＫＣｍは、複数のコマンダＣｍ−ｎの中から代表コマンダＭＣｍを決定する。代表コマンダＭＣｍは、複数のコマンダＣｍ−ｎを代表して、後述するオーバーレイネットワークＯＮに参加する。すなわち、代表コマンダＭＣｍは、ノードの機能を備える。一方、スレーブコマンダは、代表コマンダＭＣｍが動作不能になったとき代表コマンダＭＣｍの動作を行う。これにより、代表コマンダＭＣｍが故障等により機能しなくなったときでも、スレーブコマンダにより代表コマンダの機能を維持することができる。
【００４２】
ここで、代表コマンダＭＣｍの処理概要について説明する。代表コマンダＭＣｍは、センターサーバＣＳにより管理されるコンテンツリスト一覧を取得する。次に、代表コマンダＭＣｍは、取得したコンテンツリスト一覧に記述されているコンテンツリストリビジョンが付与されたコンテンツリストを、オーバーレイネットワークＯＮを介して他の代表コマンダＭＣｍから取得する。次に、代表コマンダＭＣｍは、取得したコンテンツリストに記述されているローカルファイル名が付与されたカラオケデータのコンテンツを、オーバーレイネットワークＯＮを介して他の代表コマンダＭＣｍから取得する。このようにコンテンツの取得が行われたコンテンツリストのコンテンツリストリビジョンを、処理済コンテンツリビジョンという。なお、非代表のコマンダＣｍ−ｎは、代表コマンダＭＣｍと同様の流れでカラオケデータのコンテンツを取得することになる。しかし、非代表のコマンダＣｍ−ｎによる、コンテンツリスト一覧、コンテンツリスト、及びカラオケデータのコンテンツの取得先は、同じ店舗ネットワークＮＬｍに接続された代表コマンダＭＣｍになる。
【００４３】
また、各店舗ネットワークＮＬｍは、各ルータＲｍ及び各店舗の通信回線Ｋｍを介してネットワークＮＷに接続されている。各店舗Ｐｍの代表コマンダＭＣｍは、他の店舗Ｐｍの複数の代表コマンダＭＣｍとの間で、ネットワークＮＷを介して形成されるオーバーレイネットワークＯＮによる通信を行う。つまり、オーバーレイネットワークＯＮを介して複数の代表コマンダＭＣｍ間でピアツーピア通信が行われる。オーバーレイネットワークＯＮとは、ネットワークＮＷを用いて形成される仮想的なリンクを構成する論理的なネットワークである。また、オーバーレイネットワークＯＮは、特定のアルゴリズム、例えば、ＤＨＴ（Distributed Hash Table）を利用したアルゴリズムにより実現される。
【００４４】
また、カラオケシステムＳにおいては、例えばディストリビュータＤＴにより配信された複数のカラオケデータが所定のファイル形式で複数の代表コマンダＭＣｍに分散されて保存されている。例えば、代表コマンダＭＣ１には、コンテンツ名が「ＡＡＡ」の演奏曲のカラオケデータが保存されている。また、代表コマンダＭＣ２には、コンテンツ名が「ＢＢＢ」の演奏曲のカラオケデータが保存されている。なお、ディストリビュータＤＴは、新規のカラオケデータをカラオケシステムＳに投入する場合、例えば１又は複数の代表コマンダＭＣｍを選択する。そして、ディストリビュータＤＴは、選択した代表コマンダＭＣｍにカラオケデータを配信する。これにより、代表コマンダＭＣｍにはカラオケデータが保存されることになる。
【００４５】
さらに、例えばディストリビュータＤＴにより配信された複数のコンテンツリストが複数の代表コマンダＭＣｍに分散されて保存されている。例えば、代表コマンダＭＣ３には、コンテンツリストリビジョンが「１」のコンテンツリストが保存されている。また、代表コマンダＭＣ４には、コンテンツリストリビジョンが「２」のコンテンツリストが保存されている。
【００４６】
各代表コマンダＭＣｍは、オーバーレイネットワークＯＮに参加することにより、他の代表コマンダＭＣｍからカラオケデータ及びコンテンツリストを取得可能になっている。
【００４７】
ここで、オーバーレイネットワークＯＮについて説明する。このオーバーレイネットワークＯＮの説明においては、オーバーレイネットワークＯＮにおける代表コマンダＭＣｍを、適宜、「ノード」という。また、他の代表コマンダＭＣｍから取得可能なカラオケデータとコンテンツリストを総称して「保存コンテンツ」という。また、コンテンツＩＤとコンテンツリストＩＤを総称して「保存コンテンツＩＤ」という。
【００４８】
各ノードは、サポータＳＰに参加リクエストを送信することによりオーバーレイネットワークＯＮへ参加することができる。オーバーレイネットワークＯＮに参加している各ノードには、固有の識別情報であるノードＩＤが割り当てられている。ノードＩＤは、例えば、各ノードに個別に割り当てられたＩＰ（Internet Protocol）アドレス、製造番号、或いはＭＡＣアドレス（Media Access Control address）等を、保存コンテンツＩＤを得るときと共通のハッシュ関数によりハッシュ化した値である。或いは、例えば、システム管理者により、ノード毎に一意のノードＩＤが割り当てられるようにしても良い。なお、ノードＩＤと保存コンテンツＩＤは、ハッシュ関数の特性により、同一の桁数を有しており、同一のＩＤ空間にさほど偏りなく分散して配置される。
【００４９】
また、各ノードは、例えば、オーバーレイネットワークＯＮへの参加時に、ＤＨＴを用いたルーティングテーブルを生成する。このルーティングテーブルには、ノード情報が複数登録されている。ノード情報とは、ノードＩＤ、ＩＰアドレス及びポート番号を含む情報である。なお、ＤＨＴを用いたルーティングテーブルについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。
【００５０】
また、オーバーレイネットワークＯＮを介して取得可能な保存コンテンツの所在を示す情報は、インデックス情報として、保存コンテンツの所在を管理しているノードに記憶される。インデックス情報には、保存コンテンツを保存しているノードのノード情報と、保存コンテンツの保存コンテンツＩＤとの組が含まれる。以下、保存コンテンツの所在を管理しているノードを「ルートノード」又は「保存コンテンツのルートノード」という。また、保存コンテンツを保存しているノードを「コンテンツ保持ノード」という。ルートノードは、例えば、保存コンテンツＩＤと最も近いノードＩＤが割り当てられたノードであるように定められる。保存コンテンツＩＤと最も近いノードＩＤとは、例えば、ＩＤの上位桁が最も多く一致するノードＩＤである。
【００５１】
ところで、あるノードが保存コンテンツを取得する場合、このノードは保存コンテンツの所在をルートノードに問い合わせる。以下、保存コンテンツの所在を問い合わせるノードを「ユーザノード」という。具体的に、保存コンテンツの所在の問い合わせにおいては、ユーザノードは、先ず、コンテンツ所在問合せメッセージを生成する。コンテンツ所在問合せメッセージには、問い合わせ対象の保存コンテンツのコンテンツＩＤ、ユーザノードのＩＰアドレス及びポート番号等が含まれる。このように生成されたコンテンツ所在問合せメッセージは、ユーザノードが記憶しているＤＨＴを用いたルーティングテーブルに従って、ユーザノードから他のノードに送信される。これにより、コンテンツ所在問合せメッセージは、保存コンテンツＩＤをキーとするＤＨＴルーティングによって１又は複数のノードにより転送され、最終的にルートノードにより受信される。なお、ＤＨＴルーティングについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。
【００５２】
コンテンツ所在問合せメッセージを受信したルートノードは、コンテンツ所在問合せメッセージに含まれる保存コンテンツＩＤに対応するインデックス情報をインデックス情報キャッシュから取得する。そして、ルートノードは、取得したインデックス情報を、例えば、コンテンツ所在問合せメッセージの送信元であるユーザノードに返信する。こうして、インデックス情報を取得したユーザノードは、インデックス情報に含まれるコンテンツ保持ノードのＩＰアドレス及びポート番号に基づいて、コンテンツ保持ノードにアクセスする。そして、ユーザノードは、アクセスしたコンテンツ保持ノードから、保存コンテンツを取得することができる。なお、コンテンツ保持ノードにおいて例えばアクセス集中が発生していると、ユーザノードがコンテンツ保持ノードにアクセスしてもコンテンツ保持ノードから応答が帰って来ず、タイムアウトとなってしまう。従って、このような場合、ユーザノードは、ディストリビュータＤＴから保存コンテンツを取得することになる。
【００５３】
なお、ディストリビュータＤＴは、オーバーレイネットワークＯＮを介して送受信可能な各保存コンテンツのオリジナルを保持している。
【００５４】
こうして、ユーザノードは、コンテンツ保持ノード又はディストリビュータＤＴから保存コンテンツを取得して保存すると、パブリッシュメッセージを生成する。このパブリッシュメッセージは、保存コンテンツを保存したことをルートノードへ知らせるためのメッセージである。パブリッシュメッセージには、保存コンテンツＩＤ及びユーザノード自身のノード情報を含む。このように生成されたパブリッシュメッセージは、ユーザノードが記憶しているＤＨＴを用いたルーティングテーブルに従って、ユーザノードから他のノードに送信される。これにより、パブリッシュメッセージは、コンテンツ所在問合せメッセージと同じように、保存コンテンツＩＤをキーとするＤＨＴルーティングによって１又は複数のノードにより転送され、最終的にルートノードにより受信される。そして、ルートノードは、パブリッシュメッセージに含まれるノード情報及び保存コンテンツＩＤの組を含むインデックス情報をインデックス情報キャッシュ領域に記憶する。こうして、ユーザノードは、取得した保存コンテンツを保存するコンテンツ保持ノードとなる。
【００５５】
［２．コマンダＣｍ−ｎの構成及び機能等］
次に、図３を参照して、コマンダＣｍ−ｎの構成及び機能について説明する。
【００５６】
図３は、コマンダＣｍ−ｎの概要構成例を示す図である。
【００５７】
コマンダＣｍ−ｎは、図３に示すように、制御部１と、記憶部２と、通信部３と、入力部４と、バッファメモリ５と、デコーダ部６と、映像処理部７と、表示部８と、音声処理部９と、スピーカ９ａとを備えて構成される。制御部１、記憶部２、通信部３、入力部４、バッファメモリ５、及びデコーダ部６はバス９ｂを介して相互に接続されている。
【００５８】
なお、各コマンダＣｍ−ｎには、各店舗ネットワークＮＬｍにおいて固有のコマンダ番号が割り当てられている。コマンダ番号は、カラオケ装置情報の一例である。また、コマンダ番号は、例えばシリアル番号で構成される。また、各コマンダＣｍ−ｎには、ＩＰアドレスが割り当てられている。
【００５９】
制御部１は、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種設定データ及びプログラムを記憶するフラッシュメモリ等から構成される。制御部１は、制御手段、第１乃至第５送信手段、第１乃至第３受信手段、取得手段、判定手段、及び決定手段等の一例である。ＣＰＵは、コンピュータの一例である。プログラムには、ＣＰＵにコマンダとしての処理を実行させるためのカラオケプログラムが含まれる。なお、カラオケプログラムは、例えば、ネットワークＮＷに接続された所定のサーバからダウンロードされるようにしても良い。或いは、カラオケプログラムは、例えば、記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしても良い。
【００６０】
制御部１は、ＣＰＵがプログラムを読み出して実行することにより、カラオケデータの取得、保存、及び演奏等の制御を行う。また、制御部１は、カラオケデータの再生に関する再生情報を記憶部３に記憶する。再生情報の例としては、カラオケデータに係る演奏曲の演奏待機時間、演奏頻度等が挙げられる。演奏待機時間とは、最後にカラオケデータを再生してから再生待機状態にある待機時間をいう。演奏頻度とは、所定期間内にカラオケデータが再生された割合をいう。
【００６１】
また、制御部１は、タイマ機能及び時計機能を有する。例えば、ＣＰＵが、計時機能を用いてタイマのカウントを行う。
【００６２】
また、管理コマンダＫＣｍの制御部１は、同じ店舗ネットワークＮＬｍに接続されている各コマンダＣｍ−ｎから収集したカラオケデータの再生情報に基づいて、代表コマンダＭＣｍを決定する。例えば、演奏待機時間が最も長いコマンダが代表コマンダとして決定される。或いは、演奏頻度が最も低いコマンダが代表コマンダとして決定される。
【００６３】
また、コマンダＣｍ−ｎが店舗Ｐｍ内の部屋毎に設置されている場合、部屋の使用／非使用によって、代表コマンダＭＣｍが決定されるように構成しても良い。例えば、非使用の部屋に設置されたコマンダＣｍ−ｎが、優先されて代表コマンダＭＣｍに決定されるように構成すると良い。
【００６４】
また、代表コマンダＭＣｍの制御部１は、オーバーレイネットワークＯＮに参加する参加処理を実行する。制御部１は、参加したオーバーレイネットワークＯＮにおいて、ユーザノード、ルートノード、及びコンテンツ保持ノード等の少なくとも何れか一つのノードとしての処理を行う。そして、代表コマンダＭＣｍの制御部１は、保存コンテンツＩＤをキーとするＤＨＴルーティングによって、オーバーレイネットワークＯＮに参加する複数の代表コマンダＭＣｍの中の何れかの代表コマンダＭＣｍから保存コンテンツを取得する。こうして取得された保存コンテンツは、代表コマンダＭＣｍ以外のコマンダＣｍ−ｎに提供される。
【００６５】
なお、制御部１におけるフラッシュメモリには、この制御部１を備えるコマンダＣｍ−ｎ自身に割り当てられたコマンダ番号及びＩＰアドレス等が記憶される。
【００６６】
記憶部３は、各種データ等を記憶するためのハードディスクドライブ等から構成される。具体的には、記憶部３には、カラオケデータ、及びコンテンツリスト等が記憶される。カラオケデータは、曲番に相当するローカルファイル名が付与されたファイルとして記憶される。また、カラオケデータには、音声データと、字幕データと、映像データとが含まれる。音声データは、演奏曲を音声出力するための例えばＭＩＤＩ（Musical Instrument Digital Interface）等のデータである。字幕データは、演奏曲の演奏中に歌詞を表示するためのデータである。映像データは、演奏曲の演奏中に背景映像を表示するためのデータである。さらに、記憶部３には、ディストリビュータＤＴのＩＰアドレスと、サポータＳＰのＩＰアドレスと、センターサーバＣＳのＩＰアドレス等とが記憶されている。
【００６７】
通信部３は、例えば固有のＭＡＣアドレスが割り当てられたイーサネット（登録商標）カード等から構成され、店舗ネットワークＮＬｍに接続されている。各コマンダＣｍ−ｎの通信部３は、店舗ネットワークＮＬｍを介した代表コマンダＭＣｍとの間の通信の制御を行う。また、代表コマンダＭＣｍの通信部３は、店舗ネットワークＮＬｍ及びネットワークＮＷを介した他の店舗Ｐｍの代表コマンダＭＣｍとの間の通信の制御を行う。
【００６８】
入力部４は、例えば、ユーザが演奏曲を検索するための検索端末と無線通信により接続可能になっている。入力部４は、検索端末から演奏曲の再生指令を入力すると、この再生指令を制御部１に出力する。なお、再生指令には、例えば演奏曲の曲番が含まれる。
【００６９】
バッファメモリ５は、通信部３を介して受信されたカラオケデータ等を一時蓄積する。バッファメモリ５に蓄積されたカラオケデータは記憶部２に出力され、記憶保存される。
【００７０】
デコーダ部６、映像処理部７、表示部８、音声処理部９、及びスピーカ９ａは、制御部１による演奏制御の下、記憶部２に保存されたカラオケデータを再生出力するためのものである。なお、音声処理部９は、図示しない音源を有する。
【００７１】
デコーダ部６は、カラオケデータに含まれる音声データ、字幕データ、及び映像データの復号化等のデコード処理を行う。映像処理部７は、デコーダ部６によりデコードされた字幕データ及び映像データを映像信号として再生する。そして、表示部８は、映像処理部７により再生された映像信号に基づきディスプレイに字幕及び背景映像を表示する。一方、音声処理部９は、デコーダ部６によりデコードされた音声データを、音源により音声信号として再生する。そして、スピーカ９ａは、音声処理部９により再生された音声信号を音波として出力する。
【００７２】
なお、表示部８及びスピーカ９ａは、別装置に設けられるものであってもよい。この場合は、コマンダＣｍ−ｎは、再生した映像信号及び音声信号を別装置に供給することになる。
【００７３】
［３．カラオケシステムＳの動作］
次に、図４乃至図１１を参照して、カラオケシステムＳの動作について説明する。
【００７４】
図４は、コマンダＣｍ−ｎの制御部１におけるメイン処理を示すフローチャートである。なお、以下の説明においては、店舗Ｐ１を一例として挙げ、店舗Ｐ１における店舗ネットワークＮＬ１に接続されたコマンダＣ１−１を例にとって説明する。
【００７５】
図４に示す処理は、例えばコマンダＣ１−１の起動により開始される。コマンダＣ１−１の制御部１は、先ず、管理コマンダの通知要求を示す管理コマンダ通知要求メッセージを店舗ネットワークＮＬ１内にマルチキャスト又はブロードキャストする（ステップＳ１）。つまり、管理コマンダ通知要求メッセージは、マルチキャスト又はブロードキャストにより、店舗ネットワークＮＬ１を介して複数のコマンダＣ１−２，Ｃ１−４，ＫＣ１及びＭＣ１に送信される。管理コマンダ通知要求メッセージは、管理コマンダに対して、管理コマンダであることを示す通知を要求するメッセージである。制御部１は、管理コマンダ通知要求メッセージを送信すると、管理コマンダ通知応答メッセージの受信を待機するための待機時間判定用のタイマのカウントを開始する。
【００７６】
次いで、コマンダＣ１−１の制御部１は、管理コマンダ通知応答メッセージを受信したか否かを判定する（ステップＳ２）。管理コマンダ通知応答メッセージは、管理コマンダの通知要求に応えるメッセージである。そして、制御部１は、管理コマンダ通知応答メッセージを受信していないと判定した場合には（ステップＳ２：ＮＯ）、ステップＳ３に進む。一方、制御部１は、管理コマンダ通知応答メッセージを受信したと判定した場合には（ステップＳ２：ＹＥＳ）、ステップＳ４に進む。なお、管理コマンダ通知応答メッセージには、管理コマンダＫＣ１のコマンダ番号が含まれている。
【００７７】
ステップＳ３では、コマンダＣ１−１の制御部１は、予め設定された待機時間が経過したか否かを、待機時間判定用のタイマがカウントアップしたかどうかより判定する。そして、制御部１は、予め設定された待機時間が経過していないと判定した場合には（ステップＳ３：ＮＯ）、ステップＳ２に戻る。一方、制御部１は、予め設定された待機時間が経過したと判定した場合には（ステップＳ３：ＹＥＳ）、ステップＳ６に進む。この場合、待機時間経過しても管理コマンダＫＣ１からの通知応答がないので、コマンダＣ１−１は、管理コマンダＫＣ１が動作不能になったと判断し、管理コマンダ動作を行うことになる。
【００７８】
ステップＳ４では、コマンダＣ１−１の制御部１は、管理コマンダ通知応答メッセージに含まれるコマンダ番号と、管理コマンダ通知応答メッセージを受信したコマンダＣ１−１自身のコマンダ番号とに基づいて、管理コマンダを交代するための所定の条件を満たすか否かを判定する。なお、管理コマンダ通知応答メッセージに含まれるコマンダ番号は、管理コマンダＫＣ１のコマンダ番号である。管理コマンダＫＣ１のコマンダ番号は、管理カラオケ装置情報の一例である。
【００７９】
例えば、コマンダＣ１−１の制御部１は、管理コマンダＫＣ１のコマンダ番号と、コマンダＣ１−１自身のコマンダ番号との大小を比較する。この比較結果、制御部１は、コマンダＣ１−１自身のコマンダ番号より、管理コマンダＫＣ１のコマンダ番号の方が大きいか否かを判定する。ここでは、コマンダ番号が最も小さいコマンダが管理コマンダになるものとする。
【００８０】
例えば店舗Ｐ１に新しく設置されるコマンダＣ１−ｍほど、コマンダ番号が大きい。これにより、最も古くから設置されているコマンダＣ１−ｍが管理コマンダになる。なお、コマンダ番号が最も大きいコマンダが管理コマンダになるように構成してもよい。この場合、最新のコマンダＣ１−ｍが管理コマンダになる。
【００８１】
そして、コマンダＣ１−１自身のコマンダ番号より、管理コマンダＭＣ１のコマンダ番号の方が小さい場合、コマンダＣ１−１の制御部１は、管理コマンダを交代するための所定の条件を満たさないと判定し（ステップＳ４：ＮＯ）、ステップＳ７に進む。一方、コマンダＣ１−１自身のコマンダ番号より、管理コマンダＭＣ１のコマンダ番号の方が大きい場合、制御部１は、管理コマンダを交代するための所定の条件を満たすと判定し（ステップＳ４：ＹＥＳ）、ステップＳ５に進む。このように、コマンダ番号の大きさによって、管理コマンダＫＣ１が決定されるように構成すれば、管理コマンダを動的に変更することを、より迅速に行うことができる。
【００８２】
なお、コマンダＣ１−ｎが店舗Ｐ１内の部屋毎に設置されている場合、部屋の使用／非使用によって、管理コマンダＫＣ１が決定されるように構成しても良い。この場合、使用／非使用の状態は、例えば、店舗Ｐ１に設置された管理用コンピュータにより管理される。管理コンピュータは、店舗Ｐ１に例えば１台設けられており、全部屋の空き状況等を管理する。また、管理用コンピュータは、店舗ネットワークＮＬ１に接続される。各コマンダＣ１−ｍは、夫々が設置された部屋の使用／非使用の状態を示す情報を、管理用コンピュータから店舗ネットワークＮＬ１を介して受信する。
【００８３】
そして、例えば、コマンダＣ１−１は、上記ステップＳ４において、コマンダＣ１−１が設置された部屋が使用であるか否かを判定する。コマンダＣ１−１が設置された部屋が使用である場合、コマンダＣ１−１の制御部１は、管理コマンダを交代するための所定の条件を満たさないと判定し（ステップＳ４：ＮＯ）、ステップＳ７に進む。一方、コマンダＣ１−１が設置された部屋が不使用である場合、制御部１は、管理コマンダを交代するための所定の条件を満たすと判定し（ステップＳ４：ＹＥＳ）、ステップＳ５に進む。このように、部屋の使用／非使用によって、管理コマンダＭＣ１が決定されるように構成すれば、カラオケ利用者に利用されていないコマンダを管理コマンダとすることができる。従って、管理コマンダの動作を円滑に実行することができる。
【００８４】
ステップＳ５では、コマンダＣ１−１の制御部１は、管理コマンダの交代を要求する管理コマンダ交代要求メッセージを、店舗ネットワークＮＬ１を介して管理コマンダＫＣ１に送信する。管理コマンダ交代要求メッセージは、管理コマンダに交代を要求するメッセージである。なお、管理コマンダ交代要求メッセージは、交代要求情報の一例である。こうして、管理コマンダＫＣ１がコマンダＣ１−１に交代される。従って、動的に管理コマンダＫＣ１を変更することができる。そのため、カラオケシステムＳにおいて安定して代表コマンダを管理することができる。
【００８５】
次いで、コマンダＣ１−１の制御部１は、管理コマンダ動作を実行する（ステップＳ６）。
【００８６】
図５は、図４に示すステップＳ６における管理コマンダ動作の詳細を示すフローチャートである。
【００８７】
管理コマンダ動作では、制御部１により、管理コマンダであることを示すフラグが“１”にセットされる。
【００８８】
管理コマンダＫＣ１の制御部１は、管理コマンダ通知要求メッセージを受信したか否かを判定する（ステップＳ６１）。そして、制御部１は、管理コマンダ通知要求メッセージを受信していないと判定した場合には（ステップＳ６１：ＮＯ）、ステップＳ６３に進む。一方、制御部１は、管理コマンダ通知要求メッセージを受信したと判定した場合には（ステップＳ６１：ＹＥＳ）、ステップＳ６２に進む。
【００８９】
ステップＳ６２では、管理コマンダＫＣ１の制御部１は、管理コマンダ通知要求メッセージを送信したコマンダＣ１−ｎに、店舗ネットワークＮＬ１を介して管理コマンダ通知応答メッセージを返信する。
【００９０】
次いで、管理コマンダＫＣ１の制御部１は、管理コマンダ交代要求メッセージを受信したか否かを判定する（ステップＳ６３）。そして、制御部１は、管理コマンダ交代要求メッセージを受信していないと判定した場合には（ステップＳ６３：ＮＯ）、ステップＳ６４に進む。一方、制御部１は、管理コマンダ交代要求メッセージを受信したと判定した場合には（ステップＳ６３：ＹＥＳ）、管理コマンダであることを示すフラグを“０”にセットする。こうして、管理コマンダ動作が終了し、図４に示す処理に戻る。
【００９１】
ステップＳ６４では、管理コマンダＫＣ１の制御部１は、現在時刻が、コマンダ状態取得時刻になったか否かを判定する。コマンダ状態取得時刻は、各コマンダＣ１−ｎから、コマンダ状態情報の取得を開始するために設定された時刻である。コマンダ状態情報には、例えば、上述したカラオケデータの再生に関する再生情報、及びコマンダの動作状態を示す情報等が含まれる。ただし、コマンダの動作状態を示す情報は、代表コマンダだけがコマンダ状態情報に含めて送信すれば良い。コマンダの動作状態を示す情報には、例えば、動作中の代表コマンダＭＣ１が、オーバーレイネットワークＯＮを介して他の代表コマンダＭＣｍとの間で所定の情報の送信中又は受信中であるか否かを示す情報が含まれる。所定の情報の例としては、カラオケデータ、コンテンツリスト、コンテンツリスト一覧、各種メッセージ等が挙げられる。
【００９２】
そして、制御部１は、コマンダ状態取得時刻になったと判定した場合には（ステップＳ６４：ＹＥＳ）、ステップＳ６５に進む。一方、制御部１は、コマンダ状態取得時刻になっていないと判定した場合には（ステップＳ６４：ＮＯ）、ステップＳ６６に進む。
【００９３】
ステップＳ６６では、管理コマンダＫＣ１の制御部１は、ステップＳ６１〜Ｓ６５の処理を規定回数繰り返したか否かを判定する。この規定回数は、任意の回数に予め設定される。そして、制御部１は、規定回数繰り返していないと判定した場合には（ステップＳ６６：ＮＯ）、ステップＳ６１に戻る。一方、制御部１は、規定回数繰り返したと判定した場合には（ステップＳ６６：ＹＥＳ）、管理コマンダ動作を終了し、図４に示す処理に戻る。
【００９４】
なお、管理コマンダＫＣ１の制御部１は、ステップＳ６６で、管理コマンダ動作を開始してから所定時間が経過したか否かを判定するように構成しても良い。所定時間が経過したかは、管理コマンダ動作用のタイマがカウントアップしたか否かにより判定される。そして、制御部１は、所定時間が経過していないと判定した場合には（ステップＳ６６：ＮＯ）、ステップＳ６１に戻る。一方、制御部１は、所定時間が経過したと判定した場合には（ステップＳ６６：ＹＥＳ）、管理コマンダ動作を終了し、図４に示す処理に戻る。
【００９５】
ステップＳ６５では、管理コマンダＫＣ１の制御部１は、コマンダ状態取得処理を実行する。
【００９６】
図６は、図５に示すステップＳ６５におけるコマンダ状態取得処理の詳細を示すフローチャートである。
【００９７】
図６に示すステップＳ６５１では、管理コマンダＫＣ１の制御部１は、コマンダ状態情報の通知要求を示すコマンダ状態通知要求メッセージを店舗ネットワークＮＬ１内にマルチキャスト又はブロードキャストする。コマンダ状態通知要求メッセージは、各コマンダＣ１−ｎへコマンダ状態情報の通知を要求するメッセージである。  次いで、管理コマンダＫＣ１の制御部１は、ＲＡＭの所定領域に記憶された最大演奏待機時間を初期化する（ステップＳ６５２）。
【００９８】
次いで、管理コマンダＫＣ１の制御部１は、コマンダ状態通知応答メッセージを受信したか否かを判定する（ステップＳ６５３）。コマンダ状態通知応答メッセージは、コマンダ状態情報の通知要求に応えるメッセージである。コマンダ状態通知応答メッセージには、上述したコマンダ状態情報と、このメッセージの送信元のコマンダのコマンダ番号が含まれる。
【００９９】
そして、管理コマンダＫＣ１の制御部１は、コマンダ状態通知応答メッセージを受信したと判定した場合には（ステップＳ６５３：ＹＥＳ）、ステップＳ６５４に進む。一方、制御部１は、コマンダ状態通知応答メッセージを受信していないと判定した場合には（ステップＳ６５３：ＮＯ）、ステップＳ６５７に進む。
【０１００】
ステップＳ６５４では、管理コマンダＫＣ１の制御部１は、代表コマンダＭＣ１からの応答であるか否かを判別する。つまり、コマンダ状態通知応答メッセージを送信したコマンダＣ１−ｎが代表コマンダＭＣ１であるか否かが判定される。そして、制御部１は、代表コマンダＭＣ１からの応答であると判定した場合には（ステップＳ６５４：ＹＥＳ）、ステップＳ６５５に進む。一方、制御部１は、代表コマンダＭＣ１からの応答でないと判定した場合には（ステップＳ６５４：ＮＯ）、ステップＳ６５７に進む。
【０１０１】
ステップＳ６５５では、管理コマンダＫＣ１の制御部１は、受信されたコマンダ状態通知応答メッセージに含まれるコマンダの動作状態を示す情報に基づいて、応答した代表コマンダＭＣ１が、他の代表コマンダとの間で情報の送信中又は受信中であるか否かを判定する。そして、制御部１は、他の代表コマンダとの間で情報の送信中又は受信中であると判定した場合（ステップＳ６５５：ＹＥＳ）、応答した代表コマンダＭＣ１を代表コマンダ候補に決定し（ステップＳ６５６）、ステップＳ６６１に進む。例えば、代表コマンダＭＣ１がオーバーレイネットワークＯＮを介して他の代表コマンダＭＣｍからカラオケデータをダウンロード中である場合に、他の代表コマンダとの間で情報の送信中又は受信中であるかと判定するように構成すると良い。この場合、応答した代表コマンダＭＣ１を代表コマンダ候補とするのは、応答した代表コマンダＭＣ１が、カラオケデータのダウンロード中に代表コマンダを交代させることを防ぐためである。つまり、代表コマンダがコンテンツ取得中である場合（ステップＳ６５５：ＹＥＳ）、ステップＳ６６１に移行させることで、代表コマンダの決定を、次回のコマンダ状態取得時刻までの所定時間遅延させるようにしている。これにより、カラオケデータの取得に支障をきたすことを回避することができる。
【０１０２】
なお、上記ステップＳ６５５において、代表コマンダＭＣ１が他の代表コマンダＭＣｍからコンテンツリスト又はコンテンツリスト一覧がダウンロード中である場合に、他の代表コマンダとの間で情報の送信中又は受信中であるかと判定するように構成しても良い。ただし、コンテンツリスト及びコンテンツリスト一覧は、カラオケデータよりはデータ容量が小さいので、このダウンロード中に代表コマンダを交代させても大きな影響はないと考えられる。
【０１０３】
一方、制御部１は、コンテンツ取得中でないと判定した場合（ステップＳ６５５：ＮＯ）、ステップＳ６５７に進む。
【０１０４】
ステップＳ６５７では、管理コマンダＫＣ１の制御部１は、受信されたコマンダ状態通知応答メッセージに含まれる演奏待機時間が、最大演奏待機時間より長いか否かを判定する。そして、制御部１は、演奏待機時間が、最大演奏待機時間より長いと判定した場合には（ステップＳ６５７：ＹＥＳ）、ステップＳ６５８に進む。一方、制御部１は、演奏待機時間が、最大演奏待機時間より長くないと判定した場合には（ステップＳ６５７：ＮＯ）、ステップＳ６６０に進む。
【０１０５】
ステップＳ６５８では、管理コマンダＫＣ１の制御部１は、応答したコマンダを代表コマンダ候補に決定する。つまり、この時点で、演奏待機時間が最も長いコマンダが代表コマンダ候補として決定される。従って、前回の処理で既に代表コマンダ候補が決定されていた場合、前回の処理で代表コマンダ候補として決定されていたコマンダは、代表コマンダ候補から除外される。
【０１０６】
次いで、管理コマンダＫＣ１の制御部１は、最大演奏待機時間を更新する（ステップＳ６５９）。つまり、ＲＡＭの所定領域に記憶された最大演奏待機時間が、ステップＳ６５７で長いと判定された演奏待機時間に上書きされる。
【０１０７】
次いで、管理コマンダＫＣ１の制御部１は、例えば最大演奏待機時間の初期化から所定時間が経過したか否かを判定する（ステップＳ６６０）。所定時間が経過したか否かは、コマンダ状態取得用のタイマがカウントアップしたか否かにより判定される。この所定期間は、任意の時間に予め設定される。そして、制御部１は、所定時間が経過していないと判定した場合には（ステップＳ６６０：ＮＯ）、ステップＳ６５３に戻る。一方、制御部１は、所定時間が経過したと判定した場合には（ステップＳ６６０：ＹＥＳ）、ステップＳ６６１に進む。上記ステップＳ６５３〜Ｓ６５９の処理により、店舗ネットワークＮＬ１に接続されている各コマンダＣ１−ｎから取得された演奏待機時間に基づいて代表コマンダとなるべき代表コマンダ候補が決定される。これにより、最終的に、演奏待機時間が最も長いコマンダが代表コマンダとして決定されるので、ユーザにより最も使用されていないコマンダを代表コマンダとすることができる。従って、店舗においてカラオケデータの再生に支障をきたすことを低減することができる。
【０１０８】
なお、コマンダＣ１−ｎが店舗Ｐ１内の部屋毎に設置されている場合、部屋の使用／非使用によって、代表コマンダＭＣ１が決定されるように構成しても良い。この場合、例えば、各コマンダＣ１−ｎから返信されたコマンダ状態通知応答メッセージに含まれるコマンダ状態情報には、コマンダＣ１−ｎが設置された部屋の使用／非使用の状態を示す情報が含まれる。そして、管理コマンダＫＣ１の制御部１は、上記ステップＳ６５７において、コマンダ状態通知応答メッセージに含まれる使用／非使用の状態を示す情報に基づいて、応答したコマンダが設置された部屋が使用であるか否かを判定する。応答したコマンダが設置された部屋が使用である場合、管理コマンダＫＣ１の制御部１は、ステップＳ６６０に移行する。一方、応答したコマンダが設置された部屋が非使用である場合、管理コマンダＫＣ１の制御部１は、応答したコマンダを代表コマンダ候補に決定し（ステップＳ６５８）、ステップＳ６６１に進む。このように、部屋の使用／非使用によって、代表コマンダＭＣ１が決定されるように構成すれば、カラオケ利用者に利用されていないコマンダを代表コマンダとすることができる。従って、代表コマンダの動作を円滑に実行することができる。
【０１０９】
ステップＳ６６１では、管理コマンダＫＣ１の制御部１は、上記決定された代表コマンダ候補と、現在動作中の代表コマンダとが同一であるか否かを判定する（ステップＳ６６０）。同一であるか否かの判定は、双方のコマンダのコマンダ番号が比較されて行われる。  そして、制御部１は、上記決定された代表コマンダ候補と、現在動作中の代表コマンダとが同一でないと判定した場合には（ステップＳ６６１：ＮＯ）、ステップＳ６６２に進む。一方、制御部１は、上記決定された代表コマンダ候補と、現在動作中の代表コマンダとが同一であると判定した場合には（ステップＳ６６１：ＹＥＳ）、図５に示す処理に戻る。
【０１１０】
ステップＳ６６２では、管理コマンダＫＣ１の制御部１は、代表コマンダ候補を、新たな代表コマンダとして決定する。決定された新たな代表コマンダのコマンダ番号は、代表コマンダのコマンダ番号として例えばＲＡＭに記憶される。
【０１１１】
ステップＳ６６３では、管理コマンダＫＣ１の制御部１は、代表コマンダの交代を要求する代表コマンダ交代要求メッセージを、店舗ネットワークＮＬ１を介して動作中の代表コマンダＭＣ１に送信する。代表コマンダ交代要求メッセージは、代表コマンダに交代を要求するメッセージである。なお、代表コマンダ交代要求メッセージは、交代要求情報の一例である。代表コマンダ交代要求メッセージを受信した代表コマンダは、後述するＳステップＳ１３３でオーバーレイネットワークＯＮから脱退することになる。
【０１１２】
次いで、管理コマンダＫＣ１の制御部１は、代表コマンダとしての動作を開始する要求を示す代表コマンダ動作開始要求メッセージを、店舗ネットワークＮＬ１を介して、新たに決定した代表コマンダに送信し（ステップＳ６６４）、図５に示す処理に戻る。代表コマンダ動作開始要求メッセージは、非代表のコマンダに代表コマンダとして動作開始を要求するメッセージである。この代表コマンダ動作開始要求メッセージを受信したコマンダは、ステップＳ１３で代表コマンダ動作を実行することになる。なお、代表コマンダ動作開始要求メッセージは、動作要求情報の一例である。
【０１１３】
こうして、代表コマンダＭＣ１が交代される。従って、動的に代表コマンダＭＣ１を変更することができる。そのため、カラオケシステムＳにおいて安定してカラオケデータをコマンダに供給することができる。
【０１１４】
図４に戻り、ステップＳ７では、コマンダＣ１−１の制御部１は、現在時刻が、カラオケデータのコンテンツ取得時刻になったか否かを判定する。コンテンツ取得時刻は、カラオケデータの取得を開始するために設定された時刻である。コンテンツ取得時刻は、例えば、コマンダＣ１−ｎ毎に時間をずらすように設定される。そして、制御部１は、コンテンツ取得時刻になったと判定した場合には（ステップＳ７：ＹＥＳ）、ステップＳ８に進む。一方、制御部１は、コンテンツ取得時刻がなっていないと判定した場合には（ステップＳ７：ＮＯ）、ステップＳ９に進む。
【０１１５】
ステップＳ８では、コマンダＣ１−１の制御部１は、非代表コマンダのコンテンツ取得処理を実行する。
【０１１６】
図７は、図４に示すステップＳ８における非代表コマンダのコンテンツ取得処理の詳細を示すフローチャートである。非代表コマンダのコンテンツ取得処理では、先ず、コマンダＣ１−１の制御部１は、代表コマンダの通知要求を示す代表コマンダ通知要求メッセージを店舗ネットワークＮＬ１内にマルチキャスト又はブロードキャストする（ステップＳ８１）。代表コマンダ通知要求メッセージは、代表コマンダに対して、代表コマンダであることを示す通知を要求するメッセージである。
【０１１７】
これにより、代表コマンダＭＣ１から返信された代表コマンダ通知応答メッセージを、コマンダＣ１−１の制御部１は受信する（ステップＳ８２）。代表コマンダ通知応答メッセージは、代表コマンダの通知要求に応えるメッセージである。
【０１１８】
次いで、コマンダＣ１−１の制御部１は、例えば記憶部２に記憶されている処理済コンテンツリストリビジョンを、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に送信する（ステップＳ８３）。このとき送信される処理済コンテンツリストリビジョンは、記憶されている処理済コンテンツリストリビジョンのうち、最新の処理済コンテンツリストリビジョンである。最新の処理済コンテンツリストリビジョンとは、番号が最も大きい処理済コンテンツリストリビジョンである。
【０１１９】
ステップＳ８３で送信された処理済コンテンツリストリビジョンは、後述するステップＳ１３８で代表コマンダＭＣ１により受信される。そして、処理済コンテンツリストリビジョンの送信に対する応答としてコンテンツリスト一覧が、代表コマンダＭＣ１から送信されてくる。
【０１２０】
次いで、コマンダＣ１−１の制御部１は、代表コマンダＭＣ１から送信されたコンテンツリスト一覧を受信する（ステップＳ８４）。受信されたコンテンツリスト一覧は、制御部１のＲＡＭに記憶される。
【０１２１】
次いで、コマンダＣ１−１の制御部１は、コンテンツリスト一覧に記述されたコンテンツリストリビジョンを一つ選択する（ステップＳ８５）。なお、ステップＳ８５の処理は、コンテンツリスト一覧に記述された全てのコンテンツリストリビションが選択されるまで繰り返される。また、例えば、番号が小さいコンテンツリストリビジョンから選択される。
【０１２２】
次いで、コマンダＣ１−１の制御部１は、選択したコンテンツリストリビションに対応するコンテンツリストの要求を示すリスト要求メッセージを、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に送信する（ステップＳ８６）。リスト要求メッセージは、コンテンツリストを要求するメッセージである。
【０１２３】
次いで、コマンダＣ１−１の制御部１は、代表コマンダＭＣ１から送信されたコンテンツリストを受信する（ステップＳ８７）。受信されたコンテンツリストは、制御部１のＲＡＭに記憶される。なお、コンテンツリストには、コマンダＣ１−１の記憶部２に記憶されていないカラオケデータのコンテンツのローカルファイル名等が記述されている。
【０１２４】
次いで、コマンダＣ１−１の制御部１は、コンテンツリスト一覧に記述された全てのコンテンツリストリビジョンを選択したか否かを判定する（ステップＳ８８）。そして、制御部１は、全てのコンテンツリストリビジョンを選択していないと判定した場合には（ステップＳ８８：ＮＯ）、ステップＳ８５に戻る。一方、制御部１は、全てのコンテンツリストリビジョンを選択したと判定した場合には（ステップＳ８８：ＹＥＳ）、ステップＳ８９に進む。
【０１２５】
ステップＳ８９では、コマンダＣ１−１の制御部１は、ステップＳ８７で受信され、記憶されたコンテンツリストを一つ選択する。
【０１２６】
次いで、コマンダＣ１−１の制御部１は、選択したコンテンツリストに記述されたローカルファイル名を一つ選択する（ステップＳ９０）。つまり、コマンダＣ１−１の記憶部２に記憶されていないカラオケデータが決定される。
【０１２７】
次いで、コマンダＣ１−１の制御部１は、決定したカラオケデータのコンテンツの要求を示すコンテンツ要求メッセージを、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に送信する（ステップＳ９１）。コンテンツ要求メッセージは、カラオケデータのコンテンツを要求するメッセージである。なお、コンテンツ要求メッセージは、カラオケデータの要求を示す要求情報の一例である。また、コンテンツ要求メッセージには、ステップＳ９０で選択されたローカルファイル名が含まれる。
【０１２８】
次いで、コマンダＣ１−１の制御部１は、代表コマンダＭＣ１から送信されたカラオケデータを受信する（ステップＳ９２）。こうして、コマンダＣ１−１は、未だ取得していない新たなカラオケデータを、動的に取得することができる。受信されたカラオケデータは、バッファメモリ５に蓄積された後、ローカルファイル名が付与されたファイルとして記憶部２に記憶される。
【０１２９】
次いで、コマンダＣ１−１の制御部１は、ステップＳ８９で選択されたコンテンツリストに記述された全てのローカルファイル名を選択したか否かを判定する（ステップＳ９３）。そして、制御部１は、全てのローカルファイル名を選択していないと判定した場合には（ステップＳ９３：ＮＯ）、ステップＳ９０に戻る。ステップＳ９０に戻ると、制御部１は、コンテンツリストに記述されたローカルファイル名のうち未だ選択していないローカルファイル名を一つ選択することになる。一方、制御部１は、全てのローカルファイル名を選択したと判定した場合には（ステップＳ９３：ＹＥＳ）、ステップＳ９４に進む。
【０１３０】
ステップＳ９４では、コマンダＣ１−１の制御部１は、ステップＳ９０〜ステップＳ９２で処理されたコンテンツリストのコンテンツリストリビジョンを処理済として記録する。例えば、このように処理済となったコンテンツリストリビジョンは、上述した処理済コンテンツリストリビジョンとして記憶部２に記憶される。
【０１３１】
次いで、コマンダＣ１−１の制御部１は、ステップＳ８７で受信され、記憶された全てのコンテンツリストを選択したか否かを判定する（ステップＳ９５）。そして、制御部１は、全てのコンテンツリストを選択していないと判定した場合には（ステップＳ９５：ＮＯ）、ステップＳ８９に戻る。ステップＳ８９に戻ると、制御部１は、上記記憶されたコンテンツリストのうち未だ選択していないコンテンツリストを一つ選択することになる。一方、制御部１は、全てのコンテンツリストを選択したと判定した場合には（ステップＳ９５：ＹＥＳ）、図４に示す処理に戻る。
【０１３２】
次いで、図４に示すステップＳ９では、コマンダＣ１−１の制御部１は、現在時刻が、管理コマンダの通知要求時刻になったか否かを判定する。この通知要求時刻は、管理コマンダへ通知を要求するために設定された時刻である。通知要求時刻は、例えば所定時間間隔で到来するように設定される。そして、制御部１は、管理コマンダの通知要求時刻になったと判定した場合には（ステップＳ９：ＹＥＳ）、ステップＳ１に移行する。ステップＳ１に戻ると、制御部１は、管理コマンダ通知要求メッセージを店舗ネットワークＮＬ１内にマルチキャスト又はブロードキャストする。このように、管理コマンダ通知要求メッセージの送信は、定期的に行われる。従って、管理コマンダＫＣ１の交代が頻繁にあっても、各コマンダＣ１−ｎは迅速に管理コマンダＫＣ１を認識することができる。そのため、各コマンダＣ１−ｎと管理コマンダＫＣ１との通信の効率を向上させることができる。
【０１３３】
一方、コマンダＣ１−１の制御部１は、管理コマンダの通知要求時刻になっていないと判定した場合には（ステップＳ９：ＮＯ）、ステップＳ１０に進む。
【０１３４】
ステップＳ１０では、コマンダＣ１−１の制御部１は、コマンダ状態通知要求メッセージを受信したか否かを判定する。そして、制御部１は、コマンダ状態通知要求メッセージを受信していないと判定した場合には（ステップＳ１０：ＮＯ）、ステップＳ１２に進む。一方、制御部１は、コマンダ状態通知要求メッセージを受信したと判定した場合には（ステップＳ１０：ＹＥＳ）、記憶部２から演奏待機時間を示す情報を取得し、ステップＳ１１に進む。
【０１３５】
ステップＳ１１では、コマンダＣ１−１の制御部１は、取得した演奏待機時間を示す情報等を含むコマンダ状態通知応答メッセージを、店舗ネットワークＮＬ１を介して管理コマンダＫＣ１に返信する（ステップＳ１１）。
【０１３６】
ステップＳ１２では、コマンダＣ１−１の制御部１は、代表コマンダ動作開始要求メッセージを受信したか否かを判定する。そして、制御部１は、代表コマンダ動作開始要求メッセージを受信していないと判定した場合には（ステップＳ１２：ＮＯ）、ステップＳ１４に進む。ステップＳ１４に示すその他の処理では、例えば再生指令に応じてカラオケデータの再生処理等が行われ、ステップＳ７に戻る。一方、制御部１は、代表コマンダ動作開始要求メッセージを受信したと判定した場合には（ステップＳ１２：ＹＥＳ）、ステップＳ１３に進む。コマンダＣ１−１は代表コマンダＭＣ１となる。
【０１３７】
ステップＳ１３では、代表コマンダＭＣ１の制御部１は、代表コマンダ動作を実行する。
【０１３８】
図８は、図４に示すステップＳ１３における代表コマンダ動作の詳細を示すフローチャートである。
【０１３９】
代表コマンダ動作では、制御部１により、代表コマンダであることを示すフラグが“１”にセットされる。
【０１４０】
次いで、代表コマンダＭＣ１の制御部１は、オーバーレイネットワークＯＮに参加する参加処理を実行する（ステップＳ１３１）。この参加処理において、代表コマンダＭＣ１の制御部１は、サポータＳＰに参加リクエストを送信する。これにより、既にオーバーレイネットワークＯＮへ参加している複数の代表コマンダＭｍ−ｎのノード情報が、サポータＳＰ等から代表コマンダＭＣ１に送信される。代表コマンダＭＣ１の制御部１は、送信されたノード情報を取得する。そして、代表コマンダＭＣ１の制御部１は、取得したノード情報に基づき、ＤＨＴを用いたルーティングテーブルを生成する。こうして、代表コマンダＭＣ１は、オーバーレイネットワークＯＮへ参加することになる。
【０１４１】
次いで、代表コマンダＭＣ１の制御部１は、代表コマンダ交代要求メッセージを受信したか否かを判定する（ステップＳ１３２）。そして、制御部１は、代表コマンダ交代要求メッセージを受信したと判定した場合には（ステップＳ１３２：ＹＥＳ）、オーバーレイネットワークＯＮから脱退する脱退処理を実行する。この脱退処理において、代表コマンダＭＣ１の制御部１は、サポータＳＰに脱退リクエストを送信する。これにより、サポータＳＰから他の代表コマンダＭＣｍ−ｎに、代表コマンダＭＣ１が脱退した旨が伝えられる。こうして、代表コマンダＭＣ１は、オーバーレイネットワークＯＮから脱退することになる。そして、代表コマンダＭＣ１の制御部１は、代表コマンダであることを示すフラグを“０”にセットする。こうして、代表コマンダ動作が終了し、図４に示す処理に戻る。
【０１４２】
一方、代表コマンダＭＣ１の制御部１は、代表コマンダ交代要求メッセージを受信していないと判定した場合には（ステップＳ１３２：ＮＯ）、ステップＳ１３４に進む。
【０１４３】
ステップＳ１３４では、代表コマンダＭＣ１の制御部１は、コマンダ状態通知要求メッセージを受信したか否かを判定する。そして、制御部１は、コマンダ状態通知要求メッセージを受信していないと判定した場合には（ステップＳ１３４：ＮＯ）、ステップＳ１３６に進む。一方、制御部１は、コマンダ状態通知要求メッセージを受信したと判定した場合には（ステップＳ１３４：ＹＥＳ）、例えば、記憶部２から演奏待機時間を示す情報をカラオケデータの再生に関する再生情報として取得し、ステップＳ１３５に進む。
【０１４４】
ステップＳ１３５では、代表コマンダＭＣ１の制御部１は、コマンダ状態情報を含むコマンダ状態通知応答メッセージを、店舗ネットワークＮＬ１を介して管理コマンダＫＣ１に返信する。なお、コマンダ状態情報には、記憶部２から取得されたカラオケデータの再生に関する再生情報及びコマンダの動作状態等が含まれる。
【０１４５】
また、部屋の使用／非使用によって、代表コマンダＭＣ１を決定する構成の場合、コマンダ状態通知応答メッセージに含まれるコマンダ状態情報には、コマンダ状態通知応答メッセージを送信するコマンダＣ１−ｎが設置された部屋の使用／非使用の状態を示す情報が含まれる。なお、この場合、各コマンダＣ１−ｍは、夫々が設置された部屋の使用／非使用の状態を示す情報を、上述した管理用コンピュータから店舗ネットワークＮＬ１を介して取得する。
【０１４６】
ステップＳ１３６では、代表コマンダＭＣ１の制御部１は、現在時刻が、カラオケデータのコンテンツ取得時刻になったか否かを判定する。そして、制御部１は、コンテンツ取得時刻になったと判定した場合には（ステップＳ１３６：ＹＥＳ）、ステップＳ１３７に進む。なお、ステップＳ１３７に示す代表コマンダのコンテンツ取得処理については後述する。
【０１４７】
一方、代表コマンダＭＣ１の制御部１は、コンテンツ取得時刻になっていないと判定した場合には（ステップＳ１３６：ＮＯ）、ステップＳ１３８に進む。
【０１４８】
ステップＳ１３８では、代表コマンダＭＣ１の制御部１は、処理済コンテンツリストリビジョンを受信したか否かを判定する。そして、制御部１は、処理済コンテンツリストリビジョンを受信していないと判定した場合には（ステップＳ１３８：ＮＯ）、ステップＳ１４４に進む。一方、制御部１は、処理済コンテンツリストリビジョンを受信したと判定した場合には（ステップＳ１３８：ＹＥＳ）、ステップＳ１３９に進む。
【０１４９】
ステップＳ１３９では、代表コマンダＭＣ１の制御部１は、記憶部２に記憶されているコンテンツリストを一つ選択する。
【０１５０】
次いで、代表コマンダＭＣ１の制御部１は、選択したコンテンツリストのコンテンツリストリビジョンが、ステップＳ１３８で受信された処理済コンテンツリストリビジョンより新しいか否かを判定する（ステップＳ１４０）。そして、制御部１は、処理済コンテンツリストリビジョンより新しい、言い換えれば、番号が大きいと判定した場合には（ステップＳ１４０：ＹＥＳ）、ステップＳ１４１に進む。一方、制御部１は、処理済コンテンツリストリビジョンより新しくないと判定した場合には（ステップＳ１４０：ＮＯ）、ステップＳ１４２に進む。
【０１５１】
ステップＳ１４１では、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧に、新しいと判定したコンテンツリストのコンテンツリストリビジョン及びコンテンツリストＩＤを記述する。
【０１５２】
ステップＳ１４２では、代表コマンダＭＣ１の制御部１は、記憶部２に記憶された全てのコンテンツリストを選択したか否かを判定する。そして、制御部１は、全てのコンテンツリストを選択していないと判定した場合には（ステップＳ１４２：ＮＯ）、ステップＳ１３９に戻る。ステップＳ１３９に戻ると、制御部１は、上記記憶されたコンテンツリストのうち未だ選択していないコンテンツリストを一つ選択することになる。一方、制御部１は、全てのコンテンツリストを選択したと判定した場合には（ステップＳ１４２：ＹＥＳ）、ステップＳ１４３に進む。
【０１５３】
ステップＳ１４３では、代表コマンダＭＣ１の制御部１は、処理済コンテンツリストリビジョンを送信したコマンダＣ１−ｎに、店舗ネットワークＮＬ１を介してコンテンツリスト一覧を返信する。このコンテンツリスト一覧には、ステップＳ１４１で記述されたコンテンツリストリビジョン及びコンテンツリストＩＤが記述されている。
【０１５４】
ステップＳ１４４では、代表コマンダＭＣ１の制御部１は、リスト要求メッセージを受信したか否かを判定する。そして、制御部１は、リスト要求メッセージを受信していないと判定した場合には（ステップＳ１４４：ＮＯ）、ステップＳ１４７に進む。一方、制御部１は、リスト要求メッセージを受信したと判定した場合には（ステップＳ１４４：ＹＥＳ）、ステップＳ１４５に進む。
【０１５５】
ステップＳ１４５では、代表コマンダＭＣ１の制御部１は、リスト要求メッセージに含まれるコンテンツリストリビションに対応するコンテンツリストを記憶部２から取得する。
【０１５６】
次いで、代表コマンダＭＣ１の制御部１は、取得したコンテンツリストを、リスト要求メッセージを送信したコマンダＣ１−ｎに返信する（ステップＳ１４６）。
【０１５７】
ステップＳ１４７では、代表コマンダＭＣ１の制御部１は、コンテンツ要求メッセージを受信したか否かを判定する。そして、制御部１は、コンテンツ要求メッセージを受信していないと判定した場合には（ステップＳ１４７：ＮＯ）、ステップＳ１５０に進む。一方、制御部１は、コンテンツ要求メッセージを受信したと判定した場合には（ステップＳ１４７：ＹＥＳ）、ステップＳ１４８に進む。
【０１５８】
ステップＳ１４８では、代表コマンダＭＣ１の制御部１は、コンテンツ要求メッセージに含まれるローカルファイル名に対応するカラオケデータを記憶部２から取得する。
【０１５９】
次いで、代表コマンダＭＣ１の制御部１は、取得したカラオケデータを、コンテンツ要求メッセージを送信したコマンダＣ１−ｎに返信する（ステップＳ１４９）。
【０１６０】
ステップＳ１５０に示すその他の処理では、例えば再生指令に応じてカラオケデータの再生処理等が行われ、ステップＳ１３２に戻る。
【０１６１】
一方、ステップＳ１３７では、代表コマンダのコンテンツ取得処理が実行される。
【０１６２】
図９は、図８に示すステップＳ１３７における代表コマンダのコンテンツ取得処理の詳細を示すフローチャートである。
【０１６３】
図９に示すステップＳ１５１におけるコンテンツリスト取得処理は、センターサーバＣＳを利用する場合と、センターサーバＣＳを利用しない場合とがある。図１０（Ａ）は、センターサーバＣＳを利用する場合におけるコンテンツリスト取得処理の詳細を示すフローチャートである。図１１は、センターサーバＣＳを利用しない場合におけるコンテンツリスト取得処理の詳細を示すフローチャートである。
【０１６４】
先ず、図１０（Ａ）及び（Ｂ）を参照して、センターサーバＣＳを利用する場合について説明する。図１０（Ｂ）は、センターサーバＣＳにおけるコンテンツリスト一覧送信処理を示すフローチャートである。
【０１６５】
なお、この場合、代表コマンダＭＣ１には、センターサーバＣＳのＩＰアドレス等が記憶されている。これにより、代表コマンダＭＣ１は、店舗ネットワークＮＬ１及びネットワークＮＷを介してセンターサーバＣＳにアクセス可能になっている。
【０１６６】
図１０（Ａ）に示すステップＳ１６１では、代表コマンダＭＣ１の制御部１は、例えば記憶部２に記憶されている処理済コンテンツリストリビジョンを、店舗ネットワークＮＬ１及びネットワークＮＷを介してセンターサーバＣＳに送信する。
【０１６７】
センターサーバＣＳは、図１０（Ｂ）に示すように、代表コマンダＭＣ１から送信された処理済コンテンツリストリビジョンを受信する（ステップＳ２０１）。
【０１６８】
なお、ステップＳ２０２〜Ｓ２０５の処理は、図８に示すステップＳ１３９〜Ｓ１４２の処理と同様であるので、重複する説明を省略する。
【０１６９】
図１０（Ｂ）に示すステップＳ２０６では、センターサーバＣＳは、コンテンツリスト一覧を、ネットワークＮＷ及び店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に返信する。
【０１７０】
代表コマンダＭＣ１の制御部１は、図１０（Ａ）に示すように、センターサーバＣＳから送信されたコンテンツリスト一覧を受信する（ステップＳ１６２）。受信されたコンテンツリスト一覧は、制御部１のＲＡＭに記憶される。
【０１７１】
次いで、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧に記述されたコンテンツリストＩＤを一つ選択する（ステップＳ１６３）。
【０１７２】
次いで、代表コマンダＭＣ１の制御部１は、選択したコンテンツリストＩＤに対応するコンテンツリストを、オーバーレイネットワークＯＮに参加する複数の代表コマンダＭＣｍの中の何れかの代表コマンダＭＣｍから取得する（ステップＳ１６４）。つまり、代表コマンダＭＣ１の制御部１は、取得したコンテンツリストＩＤに対応するコンテンツリストの所在をルートノードに問い合わせる。これにより、代表コマンダＭＣ１の制御部１は、ルートノードからインデックス情報を取得する。そして、代表コマンダＭＣ１の制御部１は、取得したインデックス情報に基づき、コンテンツ保持ノードにアクセスしてコンテンツリストを取得する。取得されたコンテンツリストは、制御部１のＲＡＭに記憶される。
【０１７３】
次いで、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧に記述された全てのコンテンツリストＩＤを選択したか否かを判定する（ステップＳ１６５）。そして、制御部１は、全てのコンテンツリストＩＤを選択していないと判定した場合には（ステップＳ１６５：ＮＯ）、ステップＳ１６３に戻る。一方、制御部１は、全てのコンテンツリストＩＤを選択したと判定した場合には（ステップＳ１６５：ＹＥＳ）、図９に示す処理に戻る。
【０１７４】
次に、図１１を参照して、センターサーバＣＳを利用しない場合について説明する。
【０１７５】
なお、この場合、各代表コマンダＭＣｍには、コンテンツリスト一覧が分散保存されている。
【０１７６】
図１１に示すステップＳ１７１では、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧を、オーバーレイネットワークＯＮに参加する複数の代表コマンダＭＣｍの中の何れかの代表コマンダＭＣｍから取得する（ステップＳ１７１）。取得されたコンテンツリスト一覧は、制御部１のＲＡＭに記憶される。
【０１７７】
次いで、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧に記述されたコンテンツリビジョンを一つ選択する（ステップＳ１７２）。
【０１７８】
次いで、代表コマンダＭＣ１の制御部１は、選択したコンテンツリストリビジョンが、記憶部２に記憶されている処理済コンテンツリストリビジョンより新しいか否かを判定する（ステップＳ１７３）。そして、制御部１は、処理済コンテンツリストリビジョンより新しいと判定した場合には（ステップＳ１７３：ＹＥＳ）、ステップＳ１７４に進む。一方、制御部１は、処理済コンテンツリストリビジョンより新しくないと判定した場合には（ステップＳ１７３：ＮＯ）、ステップＳ１７５に進む。
【０１７９】
ステップＳ１７４では、代表コマンダＭＣ１の制御部１は、選択したコンテンツリストリビジョンに対応するコンテンツリストを、オーバーレイネットワークＯＮに参加する複数の代表コマンダＭＣｍの中の何れかの代表コマンダＭＣｍから取得する。
【０１８０】
ステップＳ１７５では、代表コマンダＭＣ１の制御部１は、コンテンツリスト一覧に記述された全てのコンテンツリストリビジョンを選択したか否かを判定する。そして、制御部１は、全てのコンテンツリストリビジョンを選択していないと判定した場合には（ステップＳ１７５：ＮＯ）、ステップＳ１７２に戻る。一方、制御部１は、全てのコンテンツリストリビジョンを選択したと判定した場合には（ステップＳ１７５：ＹＥＳ）、図９に示す処理に戻る。
【０１８１】
図９に戻り、代表コマンダＭＣ１の制御部１は、ステップＳ１５１で取得され、記憶されたコンテンツリストを一つ選択する（ステップＳ１５２）。
【０１８２】
次いで、代表コマンダＭＣ１の制御部１は、選択したコンテンツリストに記述されたコンテンツＩＤを一つ選択する（ステップＳ１５３）。
【０１８３】
次いで、代表コマンダＭＣ１の制御部１は、選択したコンテンツＩＤに対応するカラオケデータを、オーバーレイネットワークＯＮに参加する複数の代表コマンダＭＣｍの中の何れかの代表コマンダＭＣｍから取得する（ステップＳ１５４）。つまり、代表コマンダＭＣ１の制御部１は、取得したコンテンツＩＤに対応するカラオケデータの所在をルートノードに問い合わせる。これにより、代表コマンダＭＣ１の制御部１は、ルートノードからインデックス情報を取得する。そして、代表コマンダＭＣ１の制御部１は、取得したインデックス情報に基づき、コンテンツ保持ノードにアクセスしてカラオケデータを取得する。取得されたカラオケデータは、バッファメモリ５に蓄積された後、ローカルファイル名が付与されたファイルとして記憶部２に記憶される。
【０１８４】
次いで、代表コマンダＭＣ１の制御部１は、ステップＳ１５２で選択されたコンテンツリストに記述された全てのコンテンツＩＤを選択したか否かを判定する（ステップＳ１５５）。そして、制御部１は、全てのコンテンツＩＤを選択していないと判定した場合には（ステップＳ１５５：ＮＯ）、ステップＳ１５３に戻る。ステップＳ１５３に戻ると、制御部１は、コンテンツリストに記述されたコンテンツＩＤのうち未だ選択していないコンテンツＩＤを一つ選択することになる。一方、制御部１は、全てのコンテンツＩＤを選択したと判定した場合には（ステップＳ１５５：ＹＥＳ）、ステップＳ１５６に進む。
【０１８５】
ステップＳ１５６では、代表コマンダＭＣ１の制御部１は、ステップＳ１５３〜ステップＳ１５５で処理されたコンテンツリストのコンテンツリストリビジョンを処理済として記録する。例えば、このように処理済となったコンテンツリストリビジョンは、上述した処理済コンテンツリストリビジョンとして記憶部２に記憶される。
【０１８６】
次いで、代表コマンダＭＣ１の制御部１は、ステップＳ１５１で取得され、記憶された全てのコンテンツリストを選択したか否かを判定する（ステップＳ１５７）。そして、制御部１は、全てのコンテンツリストを選択していないと判定した場合には（ステップＳ１５７：ＮＯ）、ステップＳ１５２に戻る。一方、制御部１は、全てのコンテンツリストを選択したと判定した場合には（ステップＳ１５７：ＹＥＳ）、図８に示す処理に戻る。
【０１８７】
以上説明したように、上記実施形態によれば、複数のコマンダＣｍ−ｎの中から決定された代表コマンダＭＣｍが、オーバーレイネットワークＯＮに参加する。オーバーレイネットワークＯＮに参加した代表コマンダＭＣｍは、オーバーレイネットワークＯＮに参加する複数の代表コマンダＭＣｍの中の何れかの代表コマンダＭＣｍからカラオケデータを取得する。そして、代表コマンダＭＣｍは、取得したカラオケデータを同じ店舗ネットワークＮＬｍに接続された各コマンダＣｍ−ｎに送信する。従って、ある店舗Ｐ１に設置された複数のコマンダＣ１−ｎが、一斉に、別の店舗２に設置されたコマンダＣ２−ｎに対してカラオケデータの要求を行うことを防止でき、ネットワークＮＷに接続される各店舗Ｐｍの通信回線Ｋｍへの負荷を抑制し、カラオケデータの取得の遅延を回避することができる。
【０１８８】
なお、上記実施形態においては、各コマンダＣｍ−ｎは、取得したコンテンツリストに基づき、未だ取得していないカラオケデータの要求を動的に代表コマンダＭＣｍに行うようにした。別の例として、代表コマンダＭＣｍが、取得したカラオケデータを各コマンダＣｍ−ｎにＰＵＳＨ配信するように構成してもよい。この場合、例えば、図９に示すステップＳ１５４において、代表コマンダＭＣ１は、取得したカラオケデータを各コマンダＣ１−ｎに配信する。この構成によれば、各コマンダＣ１−ｎがコンテンツリストに基づきカラオケデータを代表コマンダＭＣ１に要求する処理を削減することができる。
【０１８９】
また、上記実施形態において、オーバーレイネットワークＯＮは、ＤＨＴを利用したアルゴリズムにより形成されるように構成した。しかし、これに限定されるものではなく、その他のアルゴリズムによりオーバーレイネットワークＯＮが形成されるものであっても良い。つまり、ＤＨＴ以外のルーティングテーブルがノードに用いられるシステムであっても良い。
【０１９０】
また、上記実施形態において、代表コマンダＭＣｍは、図８に示すステップＳ１３６においてコンテンツ取得時刻となった場合に、処理済として記録されていない新たなコンテンツリビジョンに対応するカラオケデータのコンテンツだけを、オーバーレイネットワークＯＮを介して他の代表コマンダＭＣｍから取得するように構成した。しかし、代表コマンダＭＣｍは、各コマンダＣｍ−ｎからコンテンツの要求を受け付けた場合に、コンテンツ要求に対応するカラオケデータのコンテンツを、オーバーレイネットワークＯＮを介して他の代表コマンダＭＣｍから取得するように構成しても良い。コンテンツの要求には、コンテンツＩＤが含まれることになる。
【０１９１】
（変形形態）  
上記実施形態においては、管理コマンダが代表コマンダを決定するように構成した。しかし、管理コマンダを設けずに、代表コマンダが自律的に決定されるように構成してもよい。この変形形態の場合、図４乃至図６に代えて、図１２に示す処理が行われる。なお、変形形態の場合、コマンダ状態通知要求メッセージの送受信は実行されない。
【０１９２】
図１２は、変形形態において、コマンダＣｍ−ｎの制御部１におけるメイン処理を示すフローチャートである。
【０１９３】
図１２に示す処理は、例えばコマンダＣ１−１の起動により開始される。コマンダＣ１−１の制御部１は、代表コマンダ通知要求メッセージを店舗ネットワークＮＬ１内にマルチキャスト又はブロードキャストする（ステップＳ３０１）。次いで、コマンダＣ１−１の制御部１は、代表コマンダ通知応答メッセージを受信したか否かを判定する（ステップＳ３０２）。そして、制御部１は、代表コマンダ通知応答メッセージを受信していないと判定した場合には（ステップＳ３０２：ＮＯ）、ステップＳ３０３に進む。一方、制御部１は、代表コマンダ通知応答メッセージを受信したと判定した場合には（ステップＳ３０２：ＹＥＳ）、ステップＳ３０４に進む。
【０１９４】
ステップＳ３０３では、コマンダＣ１−１の制御部１は、予め設定された待機時間が経過したか否かを、上記ステップＳ３と同じように判定する。そして、制御部１は、待機時間が経過していないと判定した場合には（ステップＳ３０３：ＮＯ）、ステップＳ３０２に戻る。一方、制御部１は、待機時間が経過したと判定した場合には（ステップＳ３０３：ＹＥＳ）、ステップＳ３１０に進む。この場合、待機時間経過しても代表コマンダＭＣ１からの通知応答がないので、コマンダＣ１−１は、代表コマンダＭＣ１が動作不能になったと判断し、スレーブコマンダとして、代表コマンダ動作を行うことになる。
【０１９５】
ステップＳ３０４では、コマンダＣ１−１の制御部１は、代表コマンダ通知応答メッセージに含まれるコマンダ番号と、代表コマンダ通知応答メッセージを受信したコマンダＣ１−１自身のコマンダ番号とに基づいて、代表コマンダを交代するための所定の条件を満たすか否かを判定する。なお、代表コマンダ通知応答メッセージに含まれるコマンダ番号は、代表コマンダＭＣ１のコマンダ番号である。代表コマンダＭＣ１のコマンダ番号は、代表カラオケ装置情報の一例である。
【０１９６】
例えば、コマンダＣ１−１の制御部１は、代表コマンダＭＣ１のコマンダ番号と、コマンダＣ１−１自身のコマンダ番号との大小を比較する。この比較結果、制御部１は、コマンダＣ１−１自身のコマンダ番号より、代表コマンダＭＣ１のコマンダ番号の方が大きいか否かを判定する。ここでは、コマンダ番号が最も小さいコマンダが代表コマンダになるものとする。例えば店舗Ｐ１に新しく設置されるコマンダＣ１−ｍほど、コマンダ番号が大きい。これにより、最も古くから設置されているコマンダＣ１−ｍが代表コマンダになる。なお、コマンダ番号が最も大きいコマンダが代表コマンダになるように構成してもよい。この場合、最新のコマンダＣ１−ｍが代表コマンダになる。
【０１９７】
そして、コマンダＣ１−１自身のコマンダ番号より、代表コマンダＭＣ１のコマンダ番号の方が小さい場合、コマンダＣ１−１の制御部１は、代表コマンダを交代するための所定の条件を満たさないと判定し（ステップＳ３０４：ＮＯ）、ステップＳ３０５に進む。一方、コマンダＣ１−１自身のコマンダ番号より、代表コマンダＭＣ１のコマンダ番号の方が大きい場合、制御部１は、代表コマンダを交代するための所定の条件を満たすと判定する（ステップＳ３０４：ＹＥＳ）。そして、処理はステップＳ３０９に進む。
【０１９８】
なお、ステップＳ３０５及びＳ３０６の処理は、図４に示すステップＳ７及びＳ８の処理と同様であるので、重複する説明を省略する。
【０１９９】
ステップ３０７では、コマンダＣ１−１の制御部１は、現在時刻が、代表コマンダの通知要求時刻になったか否かを判定する。そして、制御部１は、代表コマンダの通知要求時刻になったと判定した場合には（ステップＳ３０７：ＹＥＳ）、ステップＳ３０１に移行する。このように、代表コマンダ通知要求メッセージの送信は、定期的に行われる。
【０２００】
ステップＳ３０９では、コマンダＣ１−１の制御部１は、代表コマンダの交代を要求する代表コマンダ交代要求メッセージを、店舗ネットワークＮＬ１を介して代表コマンダＭＣ１に送信する。なお、ステップＳ３１０の処理は、図４に示すステップＳ１３の処理と同様であるので、重複する説明を省略する。
【０２０１】
この変形形態によれば、管理コマンダを決定せずとも、代表コマンダを自律的に変更することができる。また、コマンダ番号の大きさによって、代表コマンダＭＣ１が決定されるように構成すれば、代表コマンダを動的に変更することを、より迅速に行うことができる。
【０２０２】
なお、コマンダＣ１−ｎが店舗Ｐ１内の部屋毎に設置されている場合、部屋の使用／非使用によって、代表コマンダＭＣ１が決定されるように構成しても良い。この場合、各コマンダＣ１−ｍは、夫々が設置された部屋の使用／非使用の状態を示す情報を、上述した管理用コンピュータから店舗ネットワークＮＬ１を介して受信する。そして、例えば、コマンダＣ１−１は、上記ステップＳ３０４において、コマンダＣ１−１が設置された部屋が使用であるか否かを判定する。コマンダＣ１−１が設置された部屋が使用である場合、コマンダＣ１−１の制御部１は、代表コマンダを交代するための所定の条件を満たさないと判定し（ステップＳ３０４：ＮＯ）、ステップＳ３０５に進む。一方、コマンダＣ１−１が設置された部屋が不使用である場合、制御部１は、代表コマンダを交代するための所定の条件を満たすと判定し（ステップＳ３０４：ＹＥＳ）、ステップＳ３０９に進む。このように、部屋の使用／非使用によって、代表コマンダＭＣ１が決定されるように構成すれば、カラオケ利用者に利用されていないコマンダを代表コマンダとすることができる。従って、代表コマンダの動作を円滑に実行することができる。
【０２０３】
なお、本発明は、上述したコマンダに限定されるものではなく、カラオケ装置として機能するものであればその他の装置であっても適用可能である。
【符号の説明】
【０２０４】
１  制御部
２  記憶部
３  通信部
４  入力部
５  バッファメモリ
６  デコーダ部
７  映像処理部
８  表示部
９  音声処理部
９ａ  スピーカ
９ｂ  バス
ＤＴ  ディストリビュータ
ＳＰ  サポータ
ＣＳ  センターサーバ
Ｃｍ−ｎ  コマンダ
ＫＣｍ  管理コマンダ
ＭＣｍ  代表コマンダ
Ｒｍ  ルータ
ＮＷ  ネットワーク
ＮＬｍ  店舗ネットワーク
ＯＮ  オーバーレイネットワーク
Ｓ  カラオケシステム
【図１】
2011064975.tif 000003
【図２】
2011064975.tif 000004
【図３】
2011064975.tif 000005
【図４】
2011064975.tif 000006
【図５】
2011064975.tif 000007
【図６】
2011064975.tif 000008
【図７】
2011064975.tif 000009
【図８】
2011064975.tif 000010
【図９】
2011064975.tif 000011
【図１０】
2011064975.tif 000012
【図１１】
2011064975.tif 000013
【図１２】
2011064975.tif 000014