カラオケコンクールシステム
【課題】参加意欲を高めるカラオケイベントシステム等を提供する。
【解決手段】店舗サーバは、カラオケ装置より受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するか否かを検索し、前記他のイベントが存在する場合に、該イベントのイベント関連情報をカラオケ装置に送信する。また、前記カラオケ装置の制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する。また、店舗サーバは、他店舗の店舗サーバとの通信によって、該他店舗でのイベントに関する情報を取得する。
【解決手段】店舗サーバは、カラオケ装置より受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するか否かを検索し、前記他のイベントが存在する場合に、該イベントのイベント関連情報をカラオケ装置に送信する。また、前記カラオケ装置の制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する。また、店舗サーバは、他店舗の店舗サーバとの通信によって、該他店舗でのイベントに関する情報を取得する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多数のカラオケ装置の利用者間でカラオケコンクールを実施するシステム等に関するものである。
【背景技術】
【０００２】
採点技術及び通信技術を応用したカラオケコンクールが提案されている。例えば、下記特許文献１においては、課題曲の演奏に先立って当該課題曲の順位表を取得し、当該課題曲の演奏後に採点結果及び順位を表示する。また、採点結果を見た後でコンクールに参加するか否かを判断する点についても開示されている。
【０００３】
【特許文献１】特開２００７−１７１３３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したイベント（カラオケコンクール）は、カラオケ店舗（カラオケボックス店舗）ごとに独自に企画されることがある。このとき、店舗が独自に企画するイベントにおいては、該店舗で歌唱しなければならないという制約が想定される。例えば、Ａ店舗で歌唱するユーザは、Ａ店舗で企画されるイベントには参加できるが、Ｂ店舗で企画するイベントには参加できないという制約が想定される。このような制約は、イベントを企画するＡ店舗にとっては、自店舗への集客力の向上という観点においては好ましい。一方、ユーザは、他店舗でどのようなイベントが企画されているか把握したいという要望がある。しかしながら、Ａ店舗内において、他店舗で実施されている好条件のイベントについて告知することは、Ｂ店舗に顧客が流れてしまうというリスクを引き起こす可能性がある。
また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示したいという要望がある。
また、ユーザごとに条件の良し悪しの基準（すなわち、何をもって好条件とするのか）が異なるため、その基準をユーザごとに的確に推定することは困難である。
【０００５】
本発明は、上記問題点を解決するためになされたものであり、自店舗の集客力を低下させることなく特定のグループ（例えば、チェーン店）に属する他店舗におけるイベント情報を提示することができるカラオケコンクールシステム等を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一側面である請求項１に係る発明は、複数のカラオケ店舗間で通信可能であり、それぞれのカラオケ店舗間において独自にイベントが実施可能なカラオケコンクールシステムにおいて、それぞれのカラオケ店舗には、店舗サーバとカラオケ装置が設置され、前記店舗サーバは、イベント情報データベースと、順位表データベースと、サーバ制御手段を備え、（ａ）前記イベント情報データベースは、自店舗で実施されるイベントごとに、課題曲として歌唱可能な楽曲の楽曲ＩＤを、イベントＩＤ・企画者・実施期間・授賞要項の組を含むイベント関連情報に対応付けて格納し、（ｂ）前記順位表データベースは、前記イベント情報ごとに、歌唱者ＩＤと採点データとの組の集合を順位表として格納し、（ｃ）前記サーバ制御手段は、前記カラオケ装置からイベントＩＤ・歌唱者ＩＤ・採点データの組を受信した際、該当の順位表を更新し、（ｄ）前記サーバ制御手段は、前記イベント情報データベース中のあるイベントの実施期間が満了した際、そのイベントの授賞要項と順位表と歌唱者情報データベースに基づいて受賞者を決定し、前記カラオケ装置は、ユーザインタフェースと、演奏手段と、採点手段と、カラオケ制御手段を備え、（ｅ）前記ユーザインタフェースは、前記カラオケ制御手段の制御に従い利用者に情報を提示するとともに利用者入力を受け付け、（ｆ）前記演奏手段は、前記カラオケ制御手段の制御に従い指定されたカラオケ楽曲の伴奏音楽を音響出力し、（ｇ）採点手段は、前記カラオケ制御手段の制御に従い伴奏音楽に合わせて歌唱する歌声の巧拙を評価して採点データを出力し、（ｈ）前記カラオケ制御手段は、（ｈ−１）イベント閲覧要求の利用者入力があった際に当該要求の電文を自店舗の店舗サーバに送信し、（ｈ−２）自店舗の店舗サーバから受信したイベント情報データベースと順位表データベースの内容を記憶し、イベントに関する情報を利用者に提示させ、（ｈ−３）ユーザインタフェースによって利用者が選択したイベントＩＤ・楽曲ＩＤとこれに対応付けられた歌唱者ＩＤを取得し、（ｈ−４）取得した楽曲ＩＤの伴奏音楽の演奏に先立ち、取得したイベントＩＤを自店舗の店舗サーバに送信し、（ｈ−５）当該イベントの順位表を自店舗の店舗サーバより受信し、（ｈ−６）取得した楽曲ＩＤの伴奏音楽を前記演奏手段に演奏させ、（ｈ−７）演奏中に歌声を採点させるとともに、採点データを受信した順位表を参照して順位を求め、少なくとも歌唱区間の終了時に求めた順位を表示させ、（ｈ−８）出力された採点データと、イベントＩＤ・歌唱者ＩＤを対応付けして自店舗の店舗サーバに送信させる、ものであって、自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、他店舗のサーバ制御手段のＩＰアドレスを検索し、自店舗のサーバ制御手段は、検索したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせ、他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、他店舗のサーバ制御手段は、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信し、自店舗のサーバ制御手段は、受信したイベント情報を、前記カラオケ装置に送信し、前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する、ことを特徴とする。
【０００７】
上記カラオケコンクールシステムによれば、自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、他店舗のサーバ制御手段のＩＰアドレスを検索し、検索したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせる。他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信する。自店舗のサーバ制御手段は、受信したイベント情報を、前記カラオケ装置に送信し、前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する。これにより、イベントを企画する者にとっては、ユーザが自イベントに参加することなく他イベントへの参加変更することを防止することができる。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他者にとっては、該他者のイベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。
【０００８】
本発明の一側面である請求項２に係る発明は、複数のカラオケ店舗間で通信可能であり、それぞれのカラオケ店舗間において独自にイベントが実施可能なカラオケコンクールシステムにおいて、それぞれのカラオケ店舗には、店舗サーバとカラオケ装置が設置され、前記店舗サーバは、イベント情報データベースと、順位表データベースと、サーバ制御手段を備え、（ａ）前記イベント情報データベースは、自店舗で実施されるイベントごとに、課題曲として歌唱可能な楽曲の楽曲ＩＤを、イベントＩＤ・企画者・実施期間・授賞要項の組を含むイベント関連情報に対応付けて格納し、（ｂ）前記順位表データベースは、前記イベント情報ごとに、歌唱者ＩＤと採点データとの組の集合を順位表として格納し、（ｃ）前記サーバ制御手段は、前記カラオケ装置からイベントＩＤ・歌唱者ＩＤ・採点データの組を受信した際、該当の順位表を更新し、（ｄ）前記サーバ制御手段は、前記イベント情報データベース中のあるイベントの実施期間が満了した際、そのイベントの授賞要項と順位表と歌唱者情報データベースに基づいて受賞者を決定し、前記カラオケ装置は、ユーザインタフェースと、演奏手段と、採点手段と、カラオケ制御手段を備え、（ｅ）前記ユーザインタフェースは、前記カラオケ制御手段の制御に従い利用者に情報を提示するとともに利用者入力を受け付け、（ｆ）前記演奏手段は、前記カラオケ制御手段の制御に従い指定されたカラオケ楽曲の伴奏音楽を音響出力し、（ｇ）採点手段は、前記カラオケ制御手段の制御に従い伴奏音楽に合わせて歌唱する歌声の巧拙を評価して採点データを出力し、（ｈ）前記カラオケ制御手段は、（ｈ−１）イベント閲覧要求の利用者入力があった際に当該要求の電文を自店舗の店舗サーバに送信し、（ｈ−２）自店舗の店舗サーバから受信したイベント情報データベースと順位表データベースの内容を記憶し、イベントに関する情報を利用者に提示させ、（ｈ−３）ユーザインタフェースによって利用者が選択したイベントＩＤ・楽曲ＩＤとこれに対応付けられた歌唱者ＩＤを取得し、（ｈ−４）取得した楽曲ＩＤの伴奏音楽の演奏に先立ち、取得したイベントＩＤを自店舗の店舗サーバに送信し、（ｈ−５）当該イベントの順位表を自店舗の店舗サーバより受信し、（ｈ−６）取得した楽曲ＩＤの伴奏音楽を前記演奏手段に演奏させ、（ｈ−７）演奏中に歌声を採点させるとともに、採点データを受信した順位表を参照して順位を求め、少なくとも歌唱区間の終了時に求めた順位を表示させ、（ｈ−８）出力された採点データと、イベントＩＤ・歌唱者ＩＤを対応付けして自店舗の店舗サーバに送信させる、ものであって、自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、通信網を介して接続された検索サーバを用いて、前記受信したイベントＩＤに対応付けられている楽曲ＩＤ及びカラオケ店舗の属性情報をキーワードとして検索し、自店舗のサーバ制御手段は、他店舗のサーバ制御手段のＩＰアドレスを特定する情報を含む検索結果を取得し、自店舗のサーバ制御手段は、取得した検索結果に基き、他店舗の店舗サーバのＩＰアドレスを特定し、自店舗のサーバ制御手段は、特定したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせ、他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、他店舗のサーバ制御手段は、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信し、自店舗のサーバ制御手段は、受信したイベント情報を、前記カラオケ装置に送信し、前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示することを特徴とする。
【０００９】
上記カラオケコンクールシステムによれば、自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、通信網を介して接続された検索サーバを用いて、前記受信したイベントＩＤに対応付けられている楽曲ＩＤ及びカラオケ店舗の属性情報をキーワードとして検索し、他店舗のサーバ制御手段のＩＰアドレスを特定する情報を含む検索結果を取得し、取得した検索結果に基き、他店舗の店舗サーバのＩＰアドレスを特定し、自店舗のサーバ制御手段は、特定したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせる。他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信し、受信したイベント情報を、前記カラオケ装置に送信する。前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する。これにより、イベントを企画する者にとっては、ユーザが自イベントに参加することなく他イベントへの参加変更することを防止することができる。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他者にとっては、該他者のイベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。また、検索サーバを利用することにより、他店舗の店舗サーバのＩＰアドレスを取得することができる。
【００１０】
本発明の一側面である請求項３に係る発明は、請求項１または請求項２のカラオケコンクールシステムであって、前記サーバ制御手段は、ＮＧＮ通信網を介して楽曲データベースと通信可能であり、前記楽曲データベースとの通信に用いるプロトコルはＰＰＰｏＥであり、前記他店舗の店舗サーバとの通信に用いるプロトコルはＳＩＰであることを特徴とする。
【００１１】
上記カラオケコンクールシステムによれば、前記サーバ制御手段は、ＮＧＮ通信網を介して楽曲データベースと通信可能である。前記楽曲の配信に用いる通信プロトコルとイベント情報を取得に用いる通信プロトコルを異ならせることにより、受信するデータの内容に応じて、通信品質を変更させることができる。
【００１２】
本発明の一側面である請求項４に係る発明は、請求項２のカラオケコンクールシステムであって、前記ＩＰアドレスを特定する情報は暗号化されており、前記自店舗のサーバ制御手段は、前記取得した検索結果から前記ＩＰアドレスを特定する情報を抽出し、前記ＩＰアドレス特定する情報を復号化することにより、他店舗の店舗サーバのＩＰアドレスを特定することを特徴とする。
【００１３】
上記カラオケコンクールシステムによれば、ＩＰアドレスを特定する情報は暗号化されており、該情報を取得した自店舗の自店舗サーバは、受信した情報を復号化することにより、他店舗のＩＰアドレスを特定する。これにより、他店舗のＩＰアドレスが検索可能に公開されることを防ぐことができるので、ネットワーク・セキュリティを向上させることができる。
【００１４】
本発明の一側面である請求項５に係る発明は、請求項１乃至請求項４いずれかのカラオケコンクールシステムであって、前記有利な条件とは、（１）同一順位の賞品金額を比較したときに、前記参加確定されたイベント順位の賞品よりも高い金額である、（２）もしくは、前記参加確定されたイベントの賞品総額よりも高い賞品総額である、（３）もしくは、前記参加確定されたイベントよりも低い順位で賞品が存在することを特徴とする。
【００１５】
一般的にコンクールは、賞品金額が高額であるほど、または、賞品が最高の順位（優勝）から低い順位に渡り、より広範囲の順位に提供されるほど集客力が高い。上記カラオケコンクールシステムによれば、前記有利な条件として、同一順位の賞品金額を比較したときに、前記参加確定されたイベント順位の賞品よりも高い金額である、前記参加確定されたイベントの賞品総額よりも高い金額である、前記参加確定されたイベントよりも低い順位で賞品が存在する、のいずれかを用いる。これにより、イベントに関する集客力の向上を図ることができる。
【発明の効果】
【００１６】
本発明によれば、参加確定の指示を受け付けた後で、より好条件な他のイベントを提示するカラオケコンクールシステム等を提供することができる。これによって、自店舗の集客力を低下させることなく特定のグループ（例えば、チェーン店）に属する他店舗におけるイベント情報を提示することができ、カラオケコンクールをビジネスモデルとして成功させることができる。
【発明を実施するための最良の形態】
【００１７】
本発明を具体化した実施形態について、以下、図面を参照しつつ詳細に説明する。以下の説明においては、「自店舗」とは「歌唱に関する操作及びカラオケコンクールに関する操作が行われたカラオケ店舗」を意味し、「他店舗」とは「自店舗以外のカラオケ店舗」を意味するものとする。
【００１８】
［第１実施形態］
まず、本発明の一実施形態である第１実施形態について説明する。
【００１９】
（システム構成）
図１は、第１実施形態におけるカラオケシステムのネットワーク構成を示した図である。
本実施形態のカラオケシステムは、各地のカラオケ店舗等に設置されたカラオケ装置１００、店舗サーバ２００、通信網、管理サーバ３００、とから基本的に構成される。
カラオケ装置１００は、カラオケ店舗の客室ごとに設置されている。
店舗サーバ２００は、カラオケ店舗ごとに設置されている。
カラオケ装置１００と管理サーバ３００とは、例えば、カラオケ店舗内の店舗サーバ２００を介して、通信網によって接続される。また、自店舗の店舗サーバ２００は、他店舗の店舗サーバ２００と通信網によって接続される。
ここで、通信網としては、有線、無線、併用どのような形態でもよく、また、インターネットを利用したＶＰＮ（Virtual Private Network）であってもよい。また、ＮＧＮ（Next Generation Network）通信網を用いてもよい。
【００２０】
まず、管理サーバ３００について説明する。
管理サーバ３００は、コントローラ３０１、楽曲データベース３０２、歌唱者情報データベース３０３、とから基本的に構成される。
コントローラ３０１は、管理サーバ３００全体を制御するものであり、プロセッサ（例えば、ＣＰＵ）によって実現される。
【００２１】
楽曲データベース３０２には、カラオケ楽曲の演奏に用いられる種々のデータが記憶されている。
図２は、楽曲データベース３０２のデータ構造の一例を示した図である。図２に示すように、楽曲ＩＤをキーとして、楽音データ、背景データ、歌手名、歌詞、等が記憶されている。
「楽曲ＩＤ」は、カラオケ楽曲ごとに付されたユニークな識別符号である。
「楽音データ」は、カラオケ楽曲の生成起源となるデータである。例えば、ＭＩＤＩデータ、ＭＰＥＧデータとすることができるが、本発明においては、楽音データのフォーマットはどのようなものであってもよい。
「背景データ」は、カラオケ楽曲の演奏中に表示される背景画像（動画、静止画）の生成起源となるデータである。本発明においては、背景データのフォーマットはどのようなものであってもよい。
「歌手名」は、カラオケ楽曲原曲の歌手名である。カラオケ楽曲の再生開始時等に表示される。
「歌詞」は、カラオケ楽曲の演奏中に表示される。楽曲再生中の歌詞表示態様については公知の種々の技術を用いることができる。
【００２２】
楽曲データベース３０２は、適宜のタイミングで更新される。例えば、所定の時間間隔で更新（例えば、日単位）してもよく、新曲が作成されるごとに更新してもよい。
なお、図２で示したデータ構造は、単なる一例であり、本発明は、このデータ構造を用いるシステムに限定されないことはいうまでもない。
【００２３】
歌唱者情報データベース３０３には、歌唱者に関する種々の情報が記憶されている。
図３は、歌唱者情報データベース３０３のデータ構造の一例を示した図である。図３に示すように、歌唱者ＩＤをキーとして、ニックネーム、住所、性別、生年月日、等が記憶されている。
【００２４】
「歌唱者ＩＤ」は、歌唱者を識別するためのユニークな識別符号である。
「ニックネーム」は、例えば、カラオケ装置１００において、順位を表示する際に用いられる。ニックネームは、歌唱者自身が任意に決めることができる。
「住所」は、歌唱者の住所である。住所は、例えば、ダイレクトメールの発送の際に用いられることがある。
「性別」は、歌唱者の性別である。
「生年月日」は、歌唱者の生年月日である。
「趣味」は、歌唱者の趣味である。１人の歌唱者に、複数の趣味が対応付けられることがある。
【００２５】
歌唱者情報データベース３０３は、適宜のタイミングで更新される。例えば、新規登録があるごとに更新することができる。
なお、図３で示したデータ構造は、単なる一例であり、本発明は、このデータ構造を用いるシステムに限定されないことはいうまでもない。
【００２６】
また、歌唱者情報は、リモコンを用いて登録することができる。また、パソコンや携帯電話を用いて登録することができる。また、プロフィール、持ち歌、歌った曲の履歴、等のカラオケ楽曲に関する情報を保存することができる。また、歌唱者情報データベース３０３の歌唱者自身の情報については、パソコン、携帯を用いてアクセスできるよう構成してもよい。また、カラオケＳＮＳサービスと関連付けてもよい。また、本発明において実施されるイベント（カラオケコンクール）に参加するには、歌唱者情報データベース３０３に個人情報を登録する必要がある。
【００２７】
次に、店舗サーバ２００について説明する。
店舗サーバ２００は、他店舗の店舗サーバと通信可能である。また、他店舗の店舗サーバとの通信には、ＳＩＰ（Session Initiation Protocol）を用いることができる。
店舗サーバ２００は、図１に示すように、コントローラ２０１、イベント情報データベース２０２、順位表データベース２０３、ＩＰアドレスデータベース２０４、とから基本的に構成される。
コントローラ２０１は、店舗サーバ２００全体を制御するものであり、プロセッサ（例えば、ＣＰＵ）によって実現される。
【００２８】
図１に示した構成においては、店舗サーバ２００が、各客室のコマンダ１０２とは別体として構成されているが、カラオケ店舗内のいずれかのコマンダ１０２が、店舗サーバ２００が有する機能を備えるように構成してもよい。この場合、店舗サーバ２００の機能を備えるコマンダ１０２を「親コマンダ」、該機能を有していないコマンダ１０２を「子コマンダ」とすれば、「親コマンダ」と「子コマンダ」は、マスタ−スレーブの関係とみなすことができる。そして、「子コマンダ」は、「親コマンダ」に対し、所定の要求を出力する。「親コマンダ」は、「子コマンダ」から所定の要求を受信すると、該要求に応じた処理を行う。
また、「親コマンダ」は、自己に対し、所定の要求を出力する。「親コマンダ」は、自己の要求に応じた処理を行う。
【００２９】
イベント情報データベース２０２には、自店舗のイベント（カラオケコンクール）に関する種々の情報が記憶されている。
図４は、イベント情報データベース２０２のデータ構造の一例を示した図である。図４に示すように、イベントＩＤをキーとして、課題曲（楽曲ＩＤ）、企画者、実施期間、参加費、受賞者順位、賞品、等が記憶されている。換言すれば、イベント情報データベース２０２には、イベントごとに、課題曲として歌唱可能な楽曲の楽曲ＩＤが、イベントＩＤ、企画者、実施期間、受賞要項の組を含む情報に対応付けられている。
【００３０】
「イベントＩＤ」は、イベントごとに付されたユニークな識別符号である。
「課題曲（楽曲ＩＤ）」は、そのイベントで用いられる課題曲である。なお、１つのイベントで複数の課題曲が用いられることもある。また、楽曲ＩＤで定義されている。イベント情報データベース２０２及び楽曲データベース３０２における「楽曲ＩＤ」は共通である。
「企画者」は、そのイベントを企画した者（会社、団体等）である。また、スポンサーが企画者となることもある。この場合、企画者の情報は、スポンサー情報である。また、カラオケ店舗が企画者となることもある。すなわち、各カラオケ店舗において独自にイベントを企画することができる。この場合、該カラオケ店舗で歌唱をしないと該イベントに参加できないよう企画することができる。これにより、カラオケ店舗独自のイベントには、該カラオケ店舗への集客力の向上を図る効果がある。
【００３１】
「実施期間」は、そのイベントの実施期間である。例えば、開始日及び終了日で定義することができる。なお、日単位ではなく、時間単位（例えば、２００６年１０月１日１５：００〜２００６年１０月２１日１０：００等）で定義してもよいことはもちろんである。
「参加費」は、そのイベントに参加するために必要な費用である。すべてのイベントの参加費を一律となるように構成された場合は、参加費属性は設定する必要はない。
「受賞者順位」は、賞を授与することができる順位である。
「賞品」は、上記受賞者順位内に入賞した者に付与される賞品に関する情報である。
【００３２】
図５は、イベント情報データベース２０２（図４）の「賞品」属性の詳細なデータ構造を示している。図５に示すように、「賞品」属性は、順位、賞品名、賞品金額、画像、趣味の組を含む情報を有する。
「順位」は、賞が付与される順位である。
「賞品名」は、付与される賞品の名称である。なお、図５に示した内容は単なる一例である。例えば、「宿泊券」については、「場所、宿泊可能日時」等の詳細情報が「賞品名」に含まれる。また、「ＭＰ３プレイヤ」については、「メーカ名、型番」等の詳細情報が、「賞品名」に含まれる。また、「ディナー券」については、「場所、利用可能日時」等の詳細情報が「賞品名」に含まれる。
【００３３】
「賞品金額」は、付与される賞品の金額である。なお、図５における数値の単位は「円」である。
「画像」は、付与される賞品の画像情報である。記憶される画像は、静止画、動画、いずれでもよい。また、賞品によって、静止画、動画を使い分けてもよい。また、画像データベースを別に有しておき、イベント情報データベース２０２には、画像データベースへのリンク情報のみを有する構成にしてもよい。また、画像の重要性が低い賞品（例えば、図書カード等）については、画像を記憶しなくてもよい。
【００３４】
「趣味」は、付与される賞品のカテゴリを示すものである。図４に示すように、例えば、「宿泊券」には「旅行」が対応付けられる。また、「ＭＰ３プレイヤ」には「音楽」が対応付けられる。また、「ディナー券」には「飲食」が対応付けられる。「趣味」は、有利な条件のイベントを抽出する際に用いられる。詳細については後述する。また、１つの賞品に対し、複数の「趣味」属性が付与されることもある。
【００３５】
イベント情報データベース２０２は、適宜のタイミングで更新される。例えば、新規イベントが発生するごとに更新することができる。また、イベント情報データベース２０２の更新には、所定の権限が必要である。
なお、図４及び図５で示したデータ構造は、単なる一例であり、本発明は、このデータ構造を用いるシステムに限定されないことはいうまでもない。
【００３６】
順位表データベース２０３には、イベントごとの歌唱者順位に関する種々の情報が記憶されている。
図６は、順位表データベース２０３のデータ構造の一例を示した図である。図６に示すように、イベントＩＤをキーとして、歌唱者ＩＤ、採点値、登録日、順位、等が記憶されている。
【００３７】
「イベントＩＤ」は、イベント情報データベース２０２のイベントＩＤと共通である。
「歌唱者ＩＤ」は、歌唱者ごとに付されたユニークな識別符号である。「歌唱者ＩＤ」は、歌唱者データベース３０３の「歌唱者ＩＤ」と共通である。
「採点値」は、そのイベントの課題曲を歌唱したときの採点値である。採点値の満点は、例えば、１００点とすることができるが、１０００点満点でもよい。また、採点値の最小値は１点単位でもよく、また、小数点第１位または第２位まで算出するように構成してもよい。
「登録日」は、そのイベントに参加登録した日（すなわち、課題曲を歌唱した日）である。
「順位」は、そのイベントにおける現時点での順位である。
【００３８】
順位表データベース２０３は、適宜のタイミングで更新される。例えば、ユーザがイベントに参加するごとに更新することができる。
なお、図６で示したデータ構造は、単なる一例であり、本発明は、このデータ構造を用いるシステムに限定されないことはいうまでもない。
【００３９】
ＩＰアドレスデータベース２０４は、チェーン店に属する他店舗の店舗サーバのＩＰアドレスの一覧を有している。ＩＰアドレスデータベース２０４は、適宜のタイミングで更新される。例えば、チェーン店に属する店舗の追加及び削除があったときに更新することができる。また、ＩＰアドレスデータベース２０４の更新には、所定の権限が必要である。
【００４０】
また、店舗サーバ２００は、所定の楽曲データを、管理サーバ３００の楽曲データベース３０２からダウンロードする。また、コマンダ１０２からリクエストがあった楽曲は、リクエスト毎に管理サーバ３００からダウンロードしてもよく、また、店舗サーバ２００またはコマンダ１０２に一時的に記憶しておくように構成してもよい。また、一度ダウンロードした楽曲を所定時間のみ記憶するようにしてもよい。なお、店舗サーバ２００またはコマンダ１０２に記憶する場合は、所定の記憶手段を有しているものとする。
【００４１】
次に、カラオケ装置について説明する。
図７は、カラオケ装置１００のシステム構成の一例である。図７に示すように、カラオケ装置１００は、リモコン１０１とコマンダ１０２とから構成される。なお、複数のリモコン１０１が、コマンダ１０２と通信可能となるように構成してもよい。
【００４２】
リモコン１０１は、赤外線通信Ｉ／Ｆ１１１、電波通信Ｉ／Ｆ１１２、ＣＰＵ１１３、ＲＯＭ１１４、ＲＡＭ１１５、表示部１１６、操作部１１７、から基本的に構成される。
【００４３】
コマンダ１０２は、赤外線通信Ｉ／Ｆ１２１、電波通信Ｉ／Ｆ１２２、ＣＰＵ１２３、ＲＯＭ１２４、ＲＡＭ１２５、補助記憶手段１２６、映像音声再生手段１２７、から基本的に構成される。
【００４４】
赤外線通信Ｉ／Ｆ１１１及び赤外線Ｉ／Ｆ１２１は、リモコン１０１とコマンダ１０２とが赤外線を媒体とする無線通信（以下、「赤外線通信」という。）を行うためのインタフェースである。
電波通信Ｉ／Ｆ１１２及び電波Ｉ／Ｆ１２２は、リモコン１０１とコマンダ１０２とが電波を媒体とする無線通信（以下、「電波通信」という。）を行うためのインタフェースである。
また、電波通信Ｉ／Ｆ１１２及び電波通信Ｉ／Ｆ１２２を用いることにより、ホストとの間で種々の情報を送受信することも可能である。
また、コマンダとリモコンとは、アクセスポイントを介して無線通信を行ってもよい。
リモコンで受け付けた各種操作信号は、コマンダに送信される。また、種々の情報がコマンダからリモコンに送信される。ここで、赤外線通信と無線通信とは、送受信される情報の種類等に応じて適宜切り替えて用いることができる。
【００４５】
また、それぞれのリモコン１０１及びコマンダ１０２がイーサネット（登録商標）等で接続されている場合は、それぞれの機器に対して固有のＩＰアドレスが付されている。また、ＩＰアドレスは、それぞれの機器が有する識別番号及び所定の生成式に基いて算出することができる。
【００４６】
ＣＰＵ１１３及びＣＰＵ１２３は、本発明を実現するために必要なプログラムを含む種々のプログラムを実行する。ＲＯＭ１１４及びＲＯＭ１２４は、本発明を実現するために必要な情報を含む種々のデータを記憶する。ＲＡＭ１１５及びＲＡＭ１２５は、本発明を実現するために必要な情報を含む種々のデータを一時的に記憶する。
【００４７】
リモコン１０１には、表示部１１６が設けられている。表示部１１６には、本発明の実現するために必要な情報を含む種々の情報を表示する。リモコン１０１には、操作部１１７が設けられている。操作部１１７は、表示部１１６の表面にタッチパネルとして実現してもよい。
【００４８】
コマンダ１０２には、補助記憶手段１２６が設けられている。補助記憶手段１２６には、例えば、楽曲の再生に必要な音声データ及び映像データ等が記憶される。また、ゲーム等のアプリケーションデータが記憶される。これらのデータは、ダウンロードによって受信している。
【００４９】
コマンダ１０２には、映像音声再生手段１２７が設けられている。映像音声再生手段１２７は、楽曲の再生及び映像の再生を行う。また、店舗サーバ等から送信されたデータに基いてストリーミング再生を行うことも可能である。
【００５０】
また、図示しない音声入力手段（マイク等）、映像表示手段（ディスプレイ等）が、コマンダ１０２に接続されている。また、コマンダ１０２は、採点機能を有する。
【００５１】
また、コマンダ１０２が、上述した「親コマンダ」として機能する場合は、管理サーバ３００及び他店舗の店舗サーバ２００と接続するための手段を有する。
【００５２】
（カラオケコンクール処理において送受信される情報）
次に、カラオケコンクールに係る処理において、リモコン、コマンダ、店舗サーバとの間で送受信される情報を説明する。図８は、リモコン１０１、コマンダ１０２、店舗サーバ２００との間で送受信される情報の一例を示した図である。
【００５３】
リモコン１０１は、ユーザよりイベントに関する情報（イベント関連情報）を要求するための操作を受付けると（１）、コマンダ１０２に対し、イベント関連情報を要求するためのイベント関連情報要求信号を送信する（２）。
コマンダ１０２は、イベント関連情報要求信号を受信すると、店舗サーバ２００に対し、イベント関連情報要求信号を送信する（３）。このイベント関連情報要求信号には、送信元となるコマンダ１０２（カラオケ装置）を識別するための識別情報が含まれている。
【００５４】
店舗サーバ２００は、イベント情報要求信号を受信すると、該イベント関連情報要求信号を送信したコマンダ１０２に対し、現時点で実施されている参加可能なイベント関連情報を送信する（４）。イベント関連情報には、イベント情報データベース２０２の情報が含まれる。すなわち、自店舗で企画しているイベントに関する情報が送信される。
【００５５】
コマンダ１０２は、イベント関連情報を受信すると、リモコン１０１に対し、該イベント関連情報を送信する（５）。また、不図示のディスプレイに、該イベント関連情報を表示してもよい。
リモコン１０１は、受信したイベント関連情報を表示部１１６に表示する。また、参加を意図するイベントを選択させるためのメッセージを併せて表示する。また、リモコン１０１は、ユーザによる参加イベントの選択を受け付ける（６）。
【００５６】
リモコン１０１は、コマンダ１０２に対し、選択されたイベントを示すための選択情報（イベントＩＤ等）を送信する（７）。この選択情報には、課題曲として歌唱する楽曲の楽曲ＩＤが（楽曲のリクエスト信号として）含まれている。
【００５７】
コマンダ１０２は、選択情報を受信すると、店舗サーバ２００に対し、選択情報を送信する（８）。この選択情報には、送信元となるコマンダ１０２（カラオケ装置）を識別するための識別情報が含まれている。また、課題曲として歌唱する楽曲を再生するための楽音データ等の要求信号が含まれることもある。該課題曲の楽音データ等が、既にコマンダ１０２に蓄積されている場合は、該要求信号を含ませる必要はない。
【００５８】
店舗サーバ２００は、選択情報を受信すると、選択されたイベントの順位表情報を送信する（９）。この順位表情報には、歌唱者ごとの採点データが含まれる。すなわち、コマンダ１０２が順位を算出するために必要な情報が含まれる。楽音データ等の要求信号が含まれている場合は、該データについても送信する。このとき、要求された楽音データ等が店舗サーバ２００内に存在しない場合は、管理サーバ３００に該楽音データ等の要求信号を出力する。
【００５９】
コマンダ１０２は、順位表情報を受信すると、リモコン１０１から受信した選択情報に含まれる楽曲ＩＤで特定される楽曲の演奏を開始し、また、当該楽曲の歌唱を採点する（１０）。
【００６０】
店舗サーバ２００は、選択されたイベントの順位表情報を送信したあと、該イベントの課題曲を含む他店舗のイベント（同じ課題曲を有する他のイベント）を検索する（１１）。他店舗のイベントの検索についての詳細は後述する。
【００６１】
店舗サーバ２００は、同じ課題曲を有するイベントを取得した場合は、コマンダ１０２に対し、該イベントのイベント情報を送信する（１２）。
【００６２】
該楽曲の歌唱が終了すると、コマンダ１０２は、上記（６）で受け付けたイベントにおける順位を算出する（１３）。このとき、上記（９）で受信した順位表情報が用いられる。また、算出した順位、及び、受信した検索結果（他のイベント情報）に基づいて、より有利な条件のイベントを抽出する（１３）。より有利な条件のイベント抽出方法については後述する。また、算出した順位は、不図示のディスプレイに表示される（１３）。
【００６３】
コマンダ１０２は、リモコン１０１に対し、リモコン１０１上に表示させる表示内容信号を送信する（１４）。表示内容信号には、イベントへの参加確定を促す画面を表示させるための指示信号が含まれる。また、上記ディスプレイに表示した順位を示す情報を含ませてもよい。
【００６４】
リモコン１０１は、イベントへの参加確定を促す画面を表示し、また、参加確定指示を受け付ける（１５）。
【００６５】
参加確定指示を受け付けると、リモコン１０１は、コマンダ１０２に対し、参加確定信号を送信する（１６）。
コマンダ１０２は、参加確定信号を受信すると、他のイベントのイベント関連情報を、図示のディスプレイに表示する（１７）。また、リモコン１０１の表示部１１６にも同様に他のイベントのイベント関連情報を表示してもよい。他のイベントのイベント関連情報の表示レイアウト等については後述する。
【００６６】
イベントへの参加確定信号を受信したあとで他のイベントに関する情報を表示することにより、イベントへの参加を確実にしつつ、他のイベントの対する提示（告知）を行うことができる。また、ユーザは、他店舗でのイベントに関する情報を取得することができる。
【００６７】
コマンダ１０２は、参加確定信号を受信すると、店舗サーバ２００に対し、参加確定信号を送信する（１８）。この参加確定信号には、イベントＩＤ、歌唱者ＩＤ、採点データが含まれている。また、楽曲ＩＤを含ませてもよい。
【００６８】
店舗サーバ２００は、参加確定信号を受信すると、該参加確定信号に含まれるイベントＩＤ、歌唱者ＩＤ、採点データ等に基づいて、順位表データベースに登録する（１９）。これにより、順位表データベース２０３は更新されることになる。
【００６９】
（店舗サーバでの他店舗イベント検索処理）
次に、店舗サーバ２００での他店舗イベント検索処理（図８の（１１））について説明する。図９は、店舗サーバ２００での他店舗イベントの検索において、他店舗の店舗サーバとの間で送受信される情報を示している。図９においては、他店舗α及び他店舗βの店舗サーバ２００との間で送受信される情報について説明するが、本発明は、情報を送受信する他店舗の数は限定されない。
【００７０】
自店舗の店舗サーバ２００は、コマンダ１０２から選択情報を受信し（８）、順位表情報を送信した（９）あと、ＩＰアドレスデータベース２０４を検索し、チェーン店に属する他店舗のＩＰアドレスを取得する（Ａ）。図９においては、他店舗α及び他店舗βのＩＰアドレスを取得する。
【００７１】
自店舗の店舗サーバ２００は、他店舗α（のＩＰアドレス）に対し、上記（８）で受信した課題曲を含むイベントを行っているか否かについて問い合わせるための問い合わせ信号を送信する（Ｂ）。該問い合わせ信号には、該課題曲の楽曲ＩＤが含まれる。
他店舗αとＳＩＰで接続した場合には、前記（Ｂ）において、前記問い合わせ信号を、通話中の発呼側（自店舗の店舗サーバ２００）の音声データに代わるデータとして着呼側（他店舗αの店舗サーバ２００）へ送信する。
【００７２】
他店舗αの店舗サーバ２００は、上記問い合わせ信号を受信すると、該問い合わせ信号に含まれる課題曲と同じ課題曲を有する参加可能なイベントが存在するか否かを検索する（Ｃ）。このとき、他店舗αの店舗サーバ２００が有するイベント情報データベース２０２が用いられる。
【００７３】
他店舗αの店舗サーバ２００は、同じ課題曲を有する参加可能なイベント（自店舗側を基準とした場合の他店舗イベント）が存在する場合は、該イベントのイベント関連情報を回答信号として送信する（Ｄ）。また、存在しない場合は、その旨を示す回答信号を送信する。
他店舗αとＳＩＰで接続された場合には、前記（Ｄ）において、前記回答信号を、通話中の着呼側（他店舗αの店舗サーバ２００）からの音声データに代わるデータとして発呼側（自店舗の店舗サーバ２００）へ送信する。
【００７４】
自店舗の店舗サーバ２００は、他店舗β（のＩＰアドレス）に対し、上記（８）で受信した課題曲を含むイベントを行っているか否かについての問い合わせ信号を送信する（Ｅ）。該問い合わせ信号には、該課題曲の楽曲ＩＤが含まれる。
他店舗βとＳＩＰで接続した場合には、前記（Ｅ）において、前記問い合わせ信号を、通話中の発呼側（自店舗の店舗サーバ２００）の音声データに代わるデータとして着呼側（他店舗βの店舗サーバ２００）へ送信する。
【００７５】
他店舗βの店舗サーバ２００は、上記問い合わせ信号を受信すると、該問い合わせ信号に含まれる課題曲と同じ課題曲を有する参加可能なイベントが存在するか否かを検索する（Ｆ）。このとき、他店舗βの店舗サーバ２００が有するイベント情報データベース２０２が用いられる。
【００７６】
他店舗βの店舗サーバ２００は、同じ課題曲を有する参加可能なイベント（自店舗側を基準とした場合の他店舗イベント）が存在する場合は、該イベントのイベント関連情報を回答信号として送信する（Ｇ）。また、存在しない場合は、その旨を示す回答信号を送信する。
他店舗βとＳＩＰで接続された場合には、前記（Ｇ）において、前記回答信号を、通話中の着呼側（他店舗βの店舗サーバ２００）からの音声データに代わるデータとして発呼側（自店舗の店舗サーバ２００）へ送信する。
【００７７】
自店舗の店舗サーバ２００は、他店舗α及び他店舗βから受信した情報を統合し、コマンダ１０２に対し、検索結果として送信する（１２）。
【００７８】
図９における処理では、問い合わせ信号に課題曲ＩＤが含まれ、他店舗の店舗サーバ２００において、課題曲が一致する参加可能なイベントを抽出しているが、本発明は別の形態としても実現可能である。例えば、問い合わせ信号に課題曲ＩＤを含ませず、他店舗の店舗サーバ２００は、参加可能なイベントを全て自店舗の店舗サーバ２００に送信し、自店舗の店舗サーバ２００において課題曲が一致するイベントを抽出するように構成してもよい。
【００７９】
また、図９における処理において、自店舗サーバ２００におけるＳＩＰによる電話収容数が「１」である場合には、自店舗の店舗サーバ２００は、上記（Ｄ）の回答信号を受信したあと、他店舗αに対する呼を切断する。その後、他店舗βに対し呼接続を開始する。
また、自店舗の店舗サーバ２００におけるＳＩＰによる電話収容数が複数である場合には、他店舗αとの呼を接続したままで、他店舗βとの呼接続をも開始する。これにより、呼接続と切断を順次行いながら他店舗から回答信号を収集するよりも、回答信号を早く収集することができる。
【００８０】
また、図９における処理では、それぞれの他店舗に順に問い合わせを行ったが、他店舗との通信網がＩＰｖ６であり、マルチキャスト通信可能であれば、前記（Ｂ）の時点で、マルチキャスト通信を用いて、複数の他店舗に問い合わせ信号を送信することができる。そして、複数の他店舗から順次回答信号を受信する。
なお、この場合、他店舗の店舗サーバ２００は、マルチキャスト参加報告をＩＰｖ６の通信網のルータに事前に登録しているものとする（マルチキャスト参加報告は、例えば、ＲＦＣ３８１０で説明されるＭＬＤｖ２（Multicast Listener Discovery Version 2）Ｒｅｐｏｒｔなど）。
【００８１】
上述した処理によれば、イベントへの参加確定指示を受け付けたあとで他のイベント情報を提示するので、イベントを企画する者（自店舗等）にとっては、ユーザが自イベントに参加することなく他イベントへ参加変更することを防止することができる。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他店舗にとっては、イベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。
【００８２】
（リモコン側の処理の流れ）
次に、イベント関連情報要求操作を受け付けた後、イベント参加確定を受け付けるまでのリモコン側の処理の流れについて説明する。
図１０は、リモコン側の処理のフローチャートである。
【００８３】
まず、Ｓ１において、ユーザより、イベント関連情報要求の操作を受け付ける。このとき、例えば、リモコン１０１のタッチパネルが用いられる。
Ｓ２において、コマンダ１０２に対し、イベント関連情報要求信号を送信する。イベント関連情報要求信号を送信した後は、イベント関連情報を受信するまで処理が待機されることになる。
【００８４】
Ｓ３において、コマンダ１０２より送信されたイベント関連情報を受信する。イベント関連情報には、自店舗で企画されている参加可能なイベントに関する情報（イベント情報データベース２０２に記憶されている情報）が含まれる。なお、他店舗独自のイベントに関する情報については受信することができない。
【００８５】
Ｓ４において、受信したイベント関連情報に基いて、参加可能なイベントを関連情報（賞品、企画者等）とともに表示する。なお、参加可能なイベント及びその関連情報は、コマンダ１０２に接続されるディスプレイに表示するよう構成してもよい。また、参加するイベントを選択可能であることを示すメッセージについても表示する。なお、タッチパネル上の表示レイアウトは適宜設定可能である。
【００８６】
Ｓ５において、ユーザより、参加するイベントを受け付ける。このとき、ユーザはリモコン１０１を用いて参加のための操作を行うことができる。なお、本実施形態においては、Ｓ５における参加受付は「仮受付」であり、後述する「参加確定」指示を行わないと該イベントへの参加手続きが終了しないものとする。
【００８７】
Ｓ６において、受け付けたイベントを示すための選択情報（イベントＩＤ等）をコマンダ１０２に対し送信する。このとき、受け付けたイベントに対応する課題曲の楽曲ＩＤは、リクエスト情報として送信される。選択情報を送信した後、該楽曲ＩＤの楽曲演奏が終了し、該演奏の順位を受信するまで処理が待機されることになる。
【００８８】
Ｓ７において、コマンダ１０２により表示内容信号を受信する。また、表示内容信号に、歌唱順位が含まれていてもよい。
Ｓ８において、上記「仮受付」したイベントへの参加確定を促す画面を表示する。
【００８９】
Ｓ９において、イベントへの参加確定指示を受け付ける。このとき、例えば、リモコン１０１のタッチパネルが用いられる。また、イベントへの不参加指示を受け付け可能に構成してもよい。
Ｓ１０において、コマンダ１０２に対し、参加確定信号を送信する。
【００９０】
（コマンダ側の処理の流れ）
参加イベントに係る選択情報を受信し、イベント参加確定に係る参加確定信号を送信するまでのコマンダ側の処理の流れについて説明する。
図１１は、コマンダ側の処理のフローチャートである。
【００９１】
Ｓ１１において、リモコン１０１より送信された選択情報を受信する。
Ｓ１２において、店舗サーバ２００に対し、Ｓ１１で受信した選択情報を送信する。また、参加するイベントの課題曲の楽曲データ等が必要である場合は、その旨を示す情報が選択情報に含まれる。選択情報を送信した後、順位表情報を受信するまで処理が待機することになる。
【００９２】
Ｓ１３において、店舗サーバ２００から順位表情報（必要に応じ、楽曲データ等）を受信する。
Ｓ１４において、Ｓ１１で受信した選択情報に含まれる楽曲ＩＤの楽曲の演奏を開始する。そして、楽曲の演奏が終了するまで、処理はＳ１５で待機する。
楽曲の演奏が終了すると（Ｓ１５：ＹＥＳ）、Ｓ１６に移行する。
【００９３】
Ｓ１６において、検索結果を受信する。なお、楽曲の演奏中（すなわち、Ｓ１５での待機中）に検索結果を受信することもある。
【００９４】
Ｓ１７において、Ｓ１３で受信した順位表情報に基づいて順位を算出する。
Ｓ１８において、Ｓ１７で算出した順位を不図示のディスプレイに表示する。また、イベントへの参加確定を促す画面を表示してもよい。
【００９５】
Ｓ１９において、Ｓ１６で受信した検索結果に基づいて、より有利な条件のイベントを抽出する。より有利な条件のイベントの抽出方法については後述する。
Ｓ２０において、リモコン１０１上に表示させる表示内容信号を送信する。
【００９６】
表示内容信号を送信した後、参加確定信号を受信するまで、処理はＳ２０で待機する。
参加確定信号を受信すると（Ｓ２０：ＹＥＳ）、Ｓ２１に移行する。なお、Ｓ２０待機中に、リモコン１０１からイベントへの不参加を通知する信号を受信した場合は、コマンダ側の処理を終了する。
【００９７】
Ｓ２１において、Ｓ１９で抽出したより有利な条件の他のイベントに関する情報を表示する。
Ｓ２２において、店舗サーバ２００に対し、参加確定信号を送信する。
【００９８】
（店舗サーバ側の処理の流れ）
次に、店舗サーバ側の処理の流れについて説明する。図１２は、店舗サーバ側の処理のフローチャートである。図１２のフローチャートに示される処理は、所定のタイミングごとに繰り返し実行される。また、図１２に示すフローチャートに示される処理は、上述した図９における「自店舗の店舗サーバにおける処理」と「他店舗の店舗サーバにおける処理」が含まれる。
【００９９】
Ｓ３１において、自店舗のコマンダ１０２からイベント関連情報要求信号を受信したか否かを判断する。
イベント関連情報要求信号を受信していないと判断した場合は（Ｓ３１：ＮＯ）、Ｓ３３に移行する。一方、イベント関連情報要求信号を受信したと判断した場合は（Ｓ３１：ＹＥＳ）、Ｓ３２に移行する。
【０１００】
Ｓ３２において、Ｓ３１で受信したイベント関連情報要求信号を送信したコマンダ１０２に対し、イベント関連情報を送信する。送信するイベント関連情報は、イベント情報データベース２０２を参照して決定される。このとき、該イベント関連情報要求信号を受信した時刻を特定し、当該時刻が実施期間に含まれるイベントが抽出される。
【０１０１】
Ｓ３３において、自店舗のコマンダ１０２から選択情報を受信したか否かを判断する。
選択情報を受信していないと判断した場合は（Ｓ３３：ＮＯ）、Ｓ３７に移行する。一方、選択情報を受信したと判断した場合は（Ｓ３３：ＹＥＳ）、Ｓ３４に移行する。
【０１０２】
Ｓ３４において、Ｓ３３で受信した選択情報を送信したコマンダ１０２に対し、順位表情報を送信する。送信する順位表情報は、順位表データベース２０３を参照して決定される。具体的には、受信した選択情報に含まれるイベントＩＤで特定されるイベントにおける採点データ等が送信する順位表情報となる。
【０１０３】
Ｓ３５において、イベント検索処理を実行する。
図１３は、イベント検索処理のフローチャートである。
Ｓ５１において、ＩＰアドレスを取得する。このとき、ＩＰアドレスデータベース２０４が参照される。取得したＩＰアドレスは、所定の記憶手段に一時的に記憶される。
Ｓ５２において、問い合わせ信号（他店舗イベントが存在するか否かを問い合わせるもの）を他店舗の店舗サーバ２００に送信する。
【０１０４】
Ｓ５３において、問い合わせ信号を送信した他店舗の店舗サーバ２００から回答信号を受信する。受信した回答信号は、所定の記憶手段に一時的に記憶される。
Ｓ５４において、Ｓ５１で取得し全てのＩＰアドレス（他店舗）に対し、問い合わせ信号を送信したか否かを判断する。
問い合わせ信号を送信していないＩＰアドレスが存在すると判断した場合は（Ｓ５４：ＮＯ）、Ｓ５２に戻る。
一方、全てのＩＰアドレス（他店舗）に対し、問い合わせ信号を送信したと判断した場合は（Ｓ５４：ＹＥＳ）、イベント検索処理を終了する。
【０１０５】
図１２に説明を戻す。
Ｓ３６において、コマンダ１０２に対し、イベント検索処理での検索結果を送信する。
【０１０６】
Ｓ３７において、自店舗のコマンダ１０２から参加確定信号を受信したか否かを判断する。
参加確定信号を受信していないと判断した場合は（Ｓ３７：ＮＯ）Ｓ３９に移行する。一方、参加確定信号を受信したと判断した場合は（Ｓ３７：ＹＥＳ）、Ｓ３８に移行する。
【０１０７】
Ｓ３８において、Ｓ３７で受信した選択確定情報に基いて、順位表データベース２０３を更新する。すなわち、受信した選択確定情報に含まれる情報（歌唱者ＩＤ、採点データ）等が、順位表データベース２０３に登録される。
【０１０８】
Ｓ３９において、他店舗の店舗サーバ２００から問い合わせ信号を受信したか否かを判断する。
問い合わせ信号を受信していないと判断した場合は（Ｓ３９：ＮＯ）、店舗サーバ側の処理を終了する。
一方、問い合わせ信号を受信したと判断した場合は（Ｓ３９：ＹＥＳ）、Ｓ４０に移行する。Ｓ４０において、回答信号送信処理を行う。
【０１０９】
図１４は、回答信号送信処理のフローチャートである。回答信号送信処理は、図９の「他店舗の店舗サーバにおける処理」として実行されるものである。
Ｓ６１において、イベント（自店舗側を基準とした場合の他店舗イベント）を検索する。このとき、イベント情報データベース２０２が参照される。
【０１１０】
Ｓ６２において、回答信号を生成する。課題曲が一致する参加可能なイベントを抽出した場合は、該イベントのイベント関連情報が回答信号に含まれる。なお、将来的に参加可能なイベントであっても、現時刻とイベント開始日時（すなわち、参加可能開始日時）の差が所定内であれば抽出するよう構成してもよい。例えば、課題曲が一致するイベントＸの開催開始日時が「２００８年４月２０日」であり、現時刻が「２００８年４月１５日１０：００」である場合に、当該イベントＸを抽出するように構成してもよい。
また、課題曲が一致するイベントを抽出しなかった場合は、その旨を示す信号が回答信号に含まれる。
【０１１１】
Ｓ６３において、Ｓ６２で生成した回答信号を、Ｓ３９（図１２）の問い合わせ信号の送信元の店舗サーバ２００に送信する。
【０１１２】
（ＮＧＮ通信網を用いた場合の通信プロトコル）
本発明は、上述したとおり、管理サーバ３００及び他店舗の店舗サーバ２００との通信に用いる通信網として、ＮＧＮ通信網を用いることができる。このとき、管理サーバ３００から楽曲データをダウンロードする場合には、ＰＰＰｏＥ（PPP over Ethernet）プロトコルを用いることができる。また、他店舗の店舗サーバとの通信には、ＳＩＰ（Session Initiation Protocol）を用いることができる。
【０１１３】
他店舗の店舗サーバとの通信にＳＩＰを用いることにより、以下のような技術的効果を発揮させることができる。
他店舗イベント検索処理（図８の（１１））の処理において、マルチキャスト通信ができない場合、複数の他店舗に対し、それぞれ、他のイベントが存在するか否かを問い合わせる必要がある。すなわち、例えば１０店舗に問い合わせる場合は、「１番目の他店舗との通信」→「２番目の他店舗との通信」→・・・→「１０番目の他店舗との通信」を順に行う必要がある。
【０１１４】
ここで、他のイベント検索処理は、楽曲の演奏・採点処理の間に行う必要がある（図８参照）。そのため、他店舗との通信には高速性が求められる。通信を高速に行うためには、通信エラーが生じにくい（すなわち、データ再送信に基く通信遅延が生じにくい）高品質の通信を行う必要がある。
このとき、ＮＧＮ通信網においては、各店舗サーバから前記ＮＧＮ網への接続方法に関して、ＰＰＰｏＥなどの接続方法よりもＳＩＰの方が優先度が高くなるよう設定され、電話系のサービスは最優先とされている場合が多い。
よって、他のイベント検索処理するタイミングで、ＳＩＰによって他店舗との通信路を電話系サービスとしてＮＧＮ網に設定させる。前記設定された後の通信路において、音声データに代わり、他のイベントに関する情報を他店舗と通信することにより、ＳＩＰ以外の接続方法よりも高品質な通信を行うことができる。つまり、他店舗イベント検索処理を実行するタイミングで、他店舗との通信路をＳＩＰに設定させることで、通信エラーが生じにくくなり、その結果、他店舗との通信を高速に行うことができる。
【０１１５】
（有利な条件のイベントの抽出）
次に、有利な条件のイベントの抽出方法について説明する。図１５は、各店舗独自のイベントの内容を示した一例である。また、ユーザは、「Ａ店舗」において、「賞品総額：４５０００円」のイベントに参加し、歌唱順位が「３位」であり、その賞品金額が「３０００円」であり、ユーザの趣味が「スポーツ」であったとする。
【０１１６】
（その１：同一順位の賞品金額を用いる方法）
「同一順位の賞品金額を比較したときに、前記参加確定されたイベント順位の賞品よりも高い金額である」イベントを、有利な条件のイベントとすることができる。図１５の例では、ユーザの歌唱順位は「３位」であるため（賞品金額：３０００円）、各店舗イベントの「３位」の賞品金額に基づいて、有利な条件のイベントを抽出する。
【０１１７】
図１５においては、
Ｂ店舗イベントの３位の賞品金額：４０００円
Ｃ店舗イベントの３位の賞品金額：５０００円
Ｄ店舗イベントの３位の賞品金額：５０００円
Ｅ店舗イベントの３位の賞品金額：なし
である。
【０１１８】
したがって、「Ｂ店舗イベント」、「Ｃ店舗イベント」、「Ｄ店舗イベント」が、有利な条件のイベントとして抽出される。
【０１１９】
（その２：賞品総額を用いる方法）
「前記参加確定されたイベントの賞品総額よりも高い賞品総額である」イベントを、有利な条件のイベントとすることができる。図１５の例では、Ａ店舗イベントの賞品総額は「４５０００円」である。
【０１２０】
図１５においては、
Ｂ店舗イベントの賞品総額：５４０００円
Ｃ店舗イベントの賞品総額：４３０００円
Ｄ店舗イベントの賞品総額：６５０００円
Ｅ店舗イベントの賞品総額：３００００円
である。
【０１２１】
したがって、「Ｂ店舗イベント」、「Ｄ店舗イベント」が、有利な条件のイベントとして抽出される。
【０１２２】
（その３：賞品を獲得できる順位を用いる方法）
「前記参加確定されたイベントよりも低い順位で賞品が存在する」イベントを、有利な条件のイベントとすることができる。図１５の例では、ユーザの歌唱順位は「３位」である。
【０１２３】
図１５においては、
Ｂ店舗イベント：３位まで賞品獲得可能
Ｃ店舗イベント：３位まで賞品獲得可能
Ｄ店舗イベント：４位まで賞品獲得可能
Ｅ店舗イベント：２位まで賞品獲得可能
である。
【０１２４】
したがって、「Ｄ店舗イベント」が、有利な条件のイベントとして抽出される。
【０１２５】
（趣味情報を用いる方法）
趣味情報を用いて有利な条件のイベントを抽出する方法について説明する。以下においては、上述した「その１」の方法に適用した例を説明するが、「その２」及び「その３」の方法についても適用可能である。
【０１２６】
図１５の例では、ユーザの趣味は「スポーツ」である。上述したとおり、「その１」の方法においては、「Ｂ店舗イベント」、「Ｃ店舗イベント」、「Ｄ店舗イベント」が、有利な条件のイベントとして抽出されていた。
ここで、図１５においては、
Ｂ店舗イベントの趣味情報：スポーツ
Ｃ店舗イベントの趣味情報：読書
Ｄ店舗イベントの趣味情報：音楽
である。
【０１２７】
したがって、「Ｂ店舗イベント」のみが、有利な条件のイベントとして抽出される。これにより、ユーザの趣味情報に基いてイベントを抽出するので、ユーザの趣味を反映して他のイベントに関する情報を提示することができる。
【０１２８】
（抽出したイベントの関連情報の表示レイアウト）
図１６は、不図示のディスプレイ及びリモコン１０１の表示部１１６上での表示レイアウトの一例を示している。図１６に示すように、参加確定したイベントの関連情報と抽出されたイベントの関連情報とが、同じ画面に表示されている。これにより、ユーザは、参加済みのイベントと、他のイベントとを容易に比較することができ、他のイベントの内容を直感的に把握することができる。
【０１２９】
以上説明した本発明の第１実施形態によれば、イベントに対する参加確定指示を受け付けたあとで他のイベント情報を提示するので、イベントを企画する者（自店舗）にとっては、ユーザが自イベントに参加することなく他イベントへ参加変更することを防止することができる。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他店舗にとっては、イベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。これによって、カラオケコンクールへの参加機会が高まり、カラオケコンクールをビジネスモデルとして成功させることができる。
【０１３０】
［第２実施形態］
次に、本発明の一実施形態である第２実施形態について説明する。
上述した第１実施形態においては、ＩＰアドレスデータベース２０４を参照して、他店舗のＩＰアドレスを特定していた。以下に説明する第２実施形態においては、ＩＰアドレスデータベースを有さず、通信網によって接続される検索サーバを用いて他店舗のＩＰアドレスを特定する。
【０１３１】
図１７は、第２実施形態におけるカラオケシステムのネットワーク構成を示した図である。基本的な構成は上述した第１実施形態と同じであるが、店舗サーバ２００は、ＩＰアドレスデータベースを有していない。また、店舗サーバ２００は、通信網を介して、検索サーバ４００に接続することができる。
【０１３２】
また、本実施形態においては、それぞれのカラオケ店舗は、ＷｅｂＰａｇｅを有している。ＷｅｂＰａｇｅには、図示しない所定のＷｅｂサーバに記憶されているものとする。また、ＷｅｂＰａｇｅには、「チェーン店であることを示す情報」、「イベントが開催中であることを示す情報」、「イベントの課題曲を示す情報」、「その店舗のＩＰアドレスを特定する情報」がＨＴＭＬ文書として記載されているものとする。
【０１３３】
（店舗サーバでの他店舗イベント検索処理）
次に、第２実施形態における、店舗サーバ２００での他店舗イベント検索処理（図８の（１１））について説明する。図１８は、店舗サーバ２００での他店舗イベントの検索において、検索サーバ及び他店舗の店舗サーバとの間で送受信される情報を説明する。図１８においては、１つの他店舗の店舗サーバとの間で送受信される情報について説明するが、本発明は、情報を送受信する他店舗の数は限定されない。
【０１３４】
検索サーバ４００は、いわゆるサーチエンジンであり、例えば、ロボット検索を行ない、データベースにＷｅｂＰａｇｅの内容を保存する。
【０１３５】
自店舗の店舗サーバ２００は、コマンダ１０２から選択情報を受信し（８）、順位表情報を送信した（９）あと、検索サーバ４００に対し、キーワード信号を送信する（Ｈ）。キーワード信号には、上記（８）の選択情報に含まれる課題曲の楽曲ＩＤ、チェーン店名がキーワードとして含まれる。
【０１３６】
検索サーバ４００は、キーワード信号を受信すると、該キーワード信号に含まれるキーワードを用いてＷｅｂＰａｇｅの検索を行なう（Ｉ）。
検索サーバ４００は、ＷｅｂＰａｇｅの検索結果を店舗サーバ２００に送信する（Ｊ）。検索結果には、上述した「チェーン店であることを示す情報」、「イベントが開催中であることを示す情報」、「イベントの課題曲を示す情報」、「その店舗の電話番号」が含まれる。
【０１３７】
店舗サーバ２００は、受信した検索結果に基いて、ＩＰアドレスを特定する（Ｋ）。受信した「その店舗のＩＰアドレスを特定する情報」が、ＩＰアドレス自体であれば、該ＩＰアドレスが他店舗のＩＰアドレスとなる。また、「その店舗のＩＰアドレスを特定する情報」が、ＩＰ電話番号が含まれた情報であれば、所定のサーバ等を用いて、ＩＰアドレスに変換する（例えば、インターネット上に設置されたＳＩＰサーバを介してＩＰアドレスを取得したり、予め店舗サーバ、検索サーバなどに記憶されたＩＰ電話番号とＩＰアドレスとの対応表からＩＰアドレスを取得したりする。）。
【０１３８】
また、その店舗のＩＰアドレスを特定する情報が、検索サーバで一般利用者から検索可能に公開されると、ネットワーク・セキュリティ面から好ましくない場合は、前記特定する情報を予め暗号化し、キーワード信号が検索可能な情報と対応付けてＷｅｂｐａｇｅに記述すればよい。
つまり、各店の店舗サーバ２００には暗号化手段と復号化手段とが組み込まれ、その店舗のＩＰアドレスを特定する情報を、前記暗号化手段によって、暗号化してからキーワード信号と対応付け、また、受信した検索結果を復号手段で復号してからＩＰアドレスを特定する情報を抽出する。
【０１３９】
例えば、Ａ社による複数のカラオケ店舗を有するカラオケチェーンがあり、チェーン店の中には堀田店があるとする。また、堀田店の店舗サーバ２００のＩＰアドレスを１２３．＊＊＊．＊＊＊．７８９とする。また、堀田店の店舗サーバ２００は各店舗からのキーワード信号「Ａ社」、「カラオケチェーン」、「堀田店」によって検索サーバから堀田店の店舗サーバのＩＰアドレスを抽出可能にするために、堀田店の店舗サーバのＷｅｂｐａｇｅは「Ａ社・カラオケチェーン・堀田店」と店舗のＩＰアドレスを特定する情報とを含むｗｅｂｐａｇｅから構成されている。
【０１４０】
この場合、暗号化手段が、ＩＰアドレスを含む情報「１２３．＊＊＊．＊＊＊．７８９」を「別のテキスト」（例えば、「９８７．＃＃＃．＃＃＃．３２１」、「ＡＣＥＧＸＹＺ」等）に暗号化すれば、前記ＷｅｂｐａｐｅのＩＰアドレスを特定する情報は、前記「別のテキスト」となる。そして、自店舗の店舗サーバ２００が前記キーワード信号によって、堀田店のＩＰアドレスを特定する「別のテキスト」を検索抽出し、復号化手段に、当該「別のテキスト」を入力すれば、「１２３．＊＊＊．＊＊＊．７８９」と復号するので、自店舗の店舗サーバ２００は、堀田店のＩＰアドレスを特定することができる。
【０１４１】
これにより、暗号化、復号化手順を知らなければ、検索サーバの利用者はＡ社の各店舗名を検索抽出できても、そこから各店舗サーバのＩＰアドレスを特定することができない ので、ネットワーク・セキュリティを向上させることができる。
【０１４２】
店舗サーバ２００は、特定したＩＰアドレスに対し、上記（８）で受信した課題曲を含むイベントを行っているか否かについて問い合わせるための問い合わせ信号を送信する（Ｌ）。該問い合わせ信号には、該課題曲の楽曲ＩＤが含まれる。
【０１４３】
他店舗の店舗サーバ２００は、上記問い合わせ信号を受信すると、該問い合わせ信号に含まれる課題曲と同じ課題曲を有する参加可能なイベントが存在するか否かを検索する（Ｍ）。このとき、他店舗の店舗サーバ２００が有するイベント情報データベース２０２が用いられる。
【０１４４】
他店舗の店舗サーバ２００は、同じ課題曲を有する参加可能なイベント（自店舗側を基準とした場合の他店舗イベント）が存在する場合は、該イベントのイベント関連情報を回答信号として送信する（Ｎ）。また、存在しない場合は、その旨を示す回答信号を送信する。
【０１４５】
自店舗の店舗サーバ２００は、他店舗から受信した情報を統合し、コマンダ１０２に対し、検索結果を送信する（１２）。
【０１４６】
図１８における処理では、問い合わせ信号に課題曲ＩＤが含まれ、他店舗の店舗サーバ２００において、課題曲が一致するイベントを抽出しているが、本発明は別の形態としても実現可能である。例えば、問い合わせ信号に課題曲ＩＤを含ませず、他店舗の店舗サーバ２００は、参加可能なイベントを全て自店舗の店舗サーバ２００に送信し、自店舗の店舗サーバ２００において課題曲が一致するイベントを抽出するように構成してもよい。
【０１４７】
また、図１８における処理では、それぞれの他店舗に順に問い合わせを行ったが、マルチキャスト通信を用いて、上記問い合わせ信号を複数の他店舗に一斉に送っても良い。
【０１４８】
次に、第２実施形態における、店舗サーバの処理について説明する。図１９は、店舗サーバ側の処理のフローチャートである。図１９のフローチャートに示される処理は、所定のタイミングごとに繰り返し実行される。また、図１９に示すフローチャートに示される処理は、上述した図１８における「自店舗における処理」と「他店舗における処理」が含まれる。
【０１４９】
Ｓ７１〜Ｓ７４、Ｓ７６〜Ｓ８０の処理は、上述した第１実施形態の店舗サーバ側の処理のＳ３１〜Ｓ３４、Ｓ３６〜Ｓ４０（図１１参照）と同じであるので、説明を省略する。
Ｓ７５において、第２イベント検索処理を実行する。
図２０は、第２イベント検索処理のフローチャートである。
Ｓ９１において、キーワード信号を生成する。上述したとおり、キーワード信号には、上記図１８の（８）の選択情報に含まれる課題曲の楽曲ＩＤ、チェーン店名がキーワードとして含まれる。
【０１５０】
Ｓ９２において、Ｓ９１で生成したキーワード信号を、検索サーバ４００に送信する。
Ｓ９３において、検索サーバ４００から検索結果を受信する。
Ｓ９４において、受信した検索結果に基いて、ＩＰアドレスを特定する。
Ｓ９５〜Ｓ９７の処理は、上述した第１実施形態のイベント検索処理（図１３参照）のＳ５２〜Ｓ５４と同じであるので、説明を省略する。
【０１５１】
以上説明した本発明の第２実施形態によれば、イベントへの参加確定指示を受け付けたあとで他のイベント情報を提示するので、イベントを企画する者（自店舗）にとっては、ユーザが自イベントに参加することなく他イベントへの参加変更することを防止することができる。また、課題曲の歌唱のための指示とイベント参加確定のための指示を別々に行う必要がない。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他店舗にとっては、イベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。これによって、カラオケコンクールへの参加機会が高まり、カラオケコンクールをビジネスモデルとして成功させることができる。また、他店舗のＩＰアドレスを有しておく必要はなく、検索サーバを有効に用いることで該ＩＰアドレスを特定することができる。
【０１５２】
［その他の実施形態］
上述した第１実施形態及び第２実施形態は、課題曲の歌唱のための指示とイベント参加確定のための指示を別々に行う構成であった。本実施形態では、課題曲の歌唱のための指示がイベント参加確定のための指示を兼ねるように構成している。
図２１は、本実施形態における、リモコン１０１、コマンダ１０２、店舗サーバ２００との間で送受信される情報の一例を示した図である。
【０１５３】
図２１の（１）〜（１３）の処理は、図８の（１）〜（１３）の処理と基本的に同じであるが、（７）でリモコン１０１からコマンダ１０２に送信される選択情報には、イベントへの参加確定信号が含まれている。これにより、歌唱後に、イベントへの参加確定指示を受け付けるための処理を行う必要がない。
【０１５４】
したがって、（１３）で有利な条件のイベントを抽出したあと、（１４）で該抽出したイベントを表示することができる。
また、コマンダ１０２は、店舗サーバ２００に対し、採点結果を送信する（１５）。
店舗サーバ２００は、採点結果を受信すると、順位表データベース２０３に登録する（１９）。これにより、順位表データベース２０３は更新されることになる。
【０１５５】
（課金方法）
上述した各実施形態において、イベントに参加するためには、所定量の参加費が必要とする構成を採用することができる。このとき、該参加費を徴収するための課金処理が必要である。本発明においては、カラオケコンクール（イベント）に係る課金方法はどのようなものでもよい。
【０１５６】
例えば、参加するイベントを選択する時点（例えば、図８の（６）の時点）で課金することができる。また、参加するイベントを確定した時点（例えば、図８の（１５）の時点）で課金することができる。また、歌唱者情報データベース３０３に、歌唱者ごとの徴収予定金額属性を設け、所定の期間単位（例えば、１ヶ月）ごとに徴収するよう構成してもよい。この場合は、参加するイベントを選択した時点、または、参加するイベントを確定した時点ごとに、歌唱者情報データベース３０３の徴収予定金額属性の内容が更新されることになる。また、料金の支払いは、ＩＣカード（電子マネー）を用いてもよく、クレジット決済、コンビニ決済としてもよい。また、カラオケボックスの清算時に、徴収するよう構成してもよい。
【０１５７】
上述したとおり、本発明によれば、イベントへの参加確定指示を受け付けたあとで他のイベント情報を提示するので、イベントを企画する者（自店舗）にとっては、ユーザが自イベントに参加することなく他イベントへの参加変更することを防止することができる。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他店舗にとっては、イベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。これによって、カラオケコンクールへの参加機会が高まり、カラオケコンクールをビジネスモデルとして成功させることができる。
【０１５８】
本発明は上述した実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の改良、変形が可能であることはいうまでもない。
【０１５９】
また、上述した各フローチャートは単なる一例であり、該各フローチャートの処理と同等の結果を得ることできるものであれば、他のフローチャートによって処理を実現してもよい。
【０１６０】
また、上述したカラオケコンクールシステムにおけるリモコン、コマンダ、カラオケコンクールシステムに係る方法、該方法をコンピュータに実行させるためのプログラム、該プログラムを記録した記録媒体等としても本発明は実現可能である。
【図面の簡単な説明】
【０１６１】
【図１】カラオケシステムの構成の一例を示した図である。
【図２】楽曲データベースのデータ構造の一例を示した図である。
【図３】歌唱者情報データベースのデータ構造の一例を示した図である。
【図４】イベント情報データベースのデータ構造の一例を示した図である。
【図５】賞品属性のデータ構造の一例を示した図である。
【図６】順位表データベースのデータ構造の一例を示した図である。
【図７】カラオケ装置（リモコン及びコマンダ）の構成の一例を示した図である。
【図８】リモコン、コマンダ、店舗サーバの間で送受信される情報の一例を示した図である。
【図９】店舗サーバ間で送受信される情報の一例を示した図である。
【図１０】リモコン側処理のフローチャートの一例である。
【図１１】コマンダ側処理のフローチャートの一例である。
【図１２】店舗サーバ側処理のフローチャートの一例である。
【図１３】イベント検索処理のフローチャートである。
【図１４】回答信号送信処理のフローチャートである。
【図１５】各店舗のイベントの例を示した図である。
【図１６】表示レイアウトの一例である。
【図１７】カラオケシステムの構成の一例を示した図である。
【図１８】自店舗の店舗サーバ、検索サーバ、他店舗の検索サーバの間で送受信される情報の一例を示した図である。
【図１９】店舗サーバ側処理のフローチャートの一例である。
【図２０】第２イベント検索処理のフローチャートである。
【図２１】リモコン、コマンダ、店舗サーバの間で送受信される情報の一例を示した図である。
【符号の説明】
【０１６２】
１００ カラオケ装置
１０１ リモコン
１０２ コマンダ
２００ 店舗サーバ
２０１ コントローラ
２０２ イベント情報データベース
２０３ 順位表データベース
２０４ ＩＰアドレスデータベース
３００ 管理サーバ
３０１ コントローラ
３０２ 楽曲データベース
３０３ 歌唱者情報データベース
４００ 検索サーバ
【技術分野】
【０００１】
本発明は、多数のカラオケ装置の利用者間でカラオケコンクールを実施するシステム等に関するものである。
【背景技術】
【０００２】
採点技術及び通信技術を応用したカラオケコンクールが提案されている。例えば、下記特許文献１においては、課題曲の演奏に先立って当該課題曲の順位表を取得し、当該課題曲の演奏後に採点結果及び順位を表示する。また、採点結果を見た後でコンクールに参加するか否かを判断する点についても開示されている。
【０００３】
【特許文献１】特開２００７−１７１３３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したイベント（カラオケコンクール）は、カラオケ店舗（カラオケボックス店舗）ごとに独自に企画されることがある。このとき、店舗が独自に企画するイベントにおいては、該店舗で歌唱しなければならないという制約が想定される。例えば、Ａ店舗で歌唱するユーザは、Ａ店舗で企画されるイベントには参加できるが、Ｂ店舗で企画するイベントには参加できないという制約が想定される。このような制約は、イベントを企画するＡ店舗にとっては、自店舗への集客力の向上という観点においては好ましい。一方、ユーザは、他店舗でどのようなイベントが企画されているか把握したいという要望がある。しかしながら、Ａ店舗内において、他店舗で実施されている好条件のイベントについて告知することは、Ｂ店舗に顧客が流れてしまうというリスクを引き起こす可能性がある。
また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示したいという要望がある。
また、ユーザごとに条件の良し悪しの基準（すなわち、何をもって好条件とするのか）が異なるため、その基準をユーザごとに的確に推定することは困難である。
【０００５】
本発明は、上記問題点を解決するためになされたものであり、自店舗の集客力を低下させることなく特定のグループ（例えば、チェーン店）に属する他店舗におけるイベント情報を提示することができるカラオケコンクールシステム等を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一側面である請求項１に係る発明は、複数のカラオケ店舗間で通信可能であり、それぞれのカラオケ店舗間において独自にイベントが実施可能なカラオケコンクールシステムにおいて、それぞれのカラオケ店舗には、店舗サーバとカラオケ装置が設置され、前記店舗サーバは、イベント情報データベースと、順位表データベースと、サーバ制御手段を備え、（ａ）前記イベント情報データベースは、自店舗で実施されるイベントごとに、課題曲として歌唱可能な楽曲の楽曲ＩＤを、イベントＩＤ・企画者・実施期間・授賞要項の組を含むイベント関連情報に対応付けて格納し、（ｂ）前記順位表データベースは、前記イベント情報ごとに、歌唱者ＩＤと採点データとの組の集合を順位表として格納し、（ｃ）前記サーバ制御手段は、前記カラオケ装置からイベントＩＤ・歌唱者ＩＤ・採点データの組を受信した際、該当の順位表を更新し、（ｄ）前記サーバ制御手段は、前記イベント情報データベース中のあるイベントの実施期間が満了した際、そのイベントの授賞要項と順位表と歌唱者情報データベースに基づいて受賞者を決定し、前記カラオケ装置は、ユーザインタフェースと、演奏手段と、採点手段と、カラオケ制御手段を備え、（ｅ）前記ユーザインタフェースは、前記カラオケ制御手段の制御に従い利用者に情報を提示するとともに利用者入力を受け付け、（ｆ）前記演奏手段は、前記カラオケ制御手段の制御に従い指定されたカラオケ楽曲の伴奏音楽を音響出力し、（ｇ）採点手段は、前記カラオケ制御手段の制御に従い伴奏音楽に合わせて歌唱する歌声の巧拙を評価して採点データを出力し、（ｈ）前記カラオケ制御手段は、（ｈ−１）イベント閲覧要求の利用者入力があった際に当該要求の電文を自店舗の店舗サーバに送信し、（ｈ−２）自店舗の店舗サーバから受信したイベント情報データベースと順位表データベースの内容を記憶し、イベントに関する情報を利用者に提示させ、（ｈ−３）ユーザインタフェースによって利用者が選択したイベントＩＤ・楽曲ＩＤとこれに対応付けられた歌唱者ＩＤを取得し、（ｈ−４）取得した楽曲ＩＤの伴奏音楽の演奏に先立ち、取得したイベントＩＤを自店舗の店舗サーバに送信し、（ｈ−５）当該イベントの順位表を自店舗の店舗サーバより受信し、（ｈ−６）取得した楽曲ＩＤの伴奏音楽を前記演奏手段に演奏させ、（ｈ−７）演奏中に歌声を採点させるとともに、採点データを受信した順位表を参照して順位を求め、少なくとも歌唱区間の終了時に求めた順位を表示させ、（ｈ−８）出力された採点データと、イベントＩＤ・歌唱者ＩＤを対応付けして自店舗の店舗サーバに送信させる、ものであって、自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、他店舗のサーバ制御手段のＩＰアドレスを検索し、自店舗のサーバ制御手段は、検索したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせ、他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、他店舗のサーバ制御手段は、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信し、自店舗のサーバ制御手段は、受信したイベント情報を、前記カラオケ装置に送信し、前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する、ことを特徴とする。
【０００７】
上記カラオケコンクールシステムによれば、自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、他店舗のサーバ制御手段のＩＰアドレスを検索し、検索したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせる。他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信する。自店舗のサーバ制御手段は、受信したイベント情報を、前記カラオケ装置に送信し、前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する。これにより、イベントを企画する者にとっては、ユーザが自イベントに参加することなく他イベントへの参加変更することを防止することができる。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他者にとっては、該他者のイベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。
【０００８】
本発明の一側面である請求項２に係る発明は、複数のカラオケ店舗間で通信可能であり、それぞれのカラオケ店舗間において独自にイベントが実施可能なカラオケコンクールシステムにおいて、それぞれのカラオケ店舗には、店舗サーバとカラオケ装置が設置され、前記店舗サーバは、イベント情報データベースと、順位表データベースと、サーバ制御手段を備え、（ａ）前記イベント情報データベースは、自店舗で実施されるイベントごとに、課題曲として歌唱可能な楽曲の楽曲ＩＤを、イベントＩＤ・企画者・実施期間・授賞要項の組を含むイベント関連情報に対応付けて格納し、（ｂ）前記順位表データベースは、前記イベント情報ごとに、歌唱者ＩＤと採点データとの組の集合を順位表として格納し、（ｃ）前記サーバ制御手段は、前記カラオケ装置からイベントＩＤ・歌唱者ＩＤ・採点データの組を受信した際、該当の順位表を更新し、（ｄ）前記サーバ制御手段は、前記イベント情報データベース中のあるイベントの実施期間が満了した際、そのイベントの授賞要項と順位表と歌唱者情報データベースに基づいて受賞者を決定し、前記カラオケ装置は、ユーザインタフェースと、演奏手段と、採点手段と、カラオケ制御手段を備え、（ｅ）前記ユーザインタフェースは、前記カラオケ制御手段の制御に従い利用者に情報を提示するとともに利用者入力を受け付け、（ｆ）前記演奏手段は、前記カラオケ制御手段の制御に従い指定されたカラオケ楽曲の伴奏音楽を音響出力し、（ｇ）採点手段は、前記カラオケ制御手段の制御に従い伴奏音楽に合わせて歌唱する歌声の巧拙を評価して採点データを出力し、（ｈ）前記カラオケ制御手段は、（ｈ−１）イベント閲覧要求の利用者入力があった際に当該要求の電文を自店舗の店舗サーバに送信し、（ｈ−２）自店舗の店舗サーバから受信したイベント情報データベースと順位表データベースの内容を記憶し、イベントに関する情報を利用者に提示させ、（ｈ−３）ユーザインタフェースによって利用者が選択したイベントＩＤ・楽曲ＩＤとこれに対応付けられた歌唱者ＩＤを取得し、（ｈ−４）取得した楽曲ＩＤの伴奏音楽の演奏に先立ち、取得したイベントＩＤを自店舗の店舗サーバに送信し、（ｈ−５）当該イベントの順位表を自店舗の店舗サーバより受信し、（ｈ−６）取得した楽曲ＩＤの伴奏音楽を前記演奏手段に演奏させ、（ｈ−７）演奏中に歌声を採点させるとともに、採点データを受信した順位表を参照して順位を求め、少なくとも歌唱区間の終了時に求めた順位を表示させ、（ｈ−８）出力された採点データと、イベントＩＤ・歌唱者ＩＤを対応付けして自店舗の店舗サーバに送信させる、ものであって、自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、通信網を介して接続された検索サーバを用いて、前記受信したイベントＩＤに対応付けられている楽曲ＩＤ及びカラオケ店舗の属性情報をキーワードとして検索し、自店舗のサーバ制御手段は、他店舗のサーバ制御手段のＩＰアドレスを特定する情報を含む検索結果を取得し、自店舗のサーバ制御手段は、取得した検索結果に基き、他店舗の店舗サーバのＩＰアドレスを特定し、自店舗のサーバ制御手段は、特定したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせ、他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、他店舗のサーバ制御手段は、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信し、自店舗のサーバ制御手段は、受信したイベント情報を、前記カラオケ装置に送信し、前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示することを特徴とする。
【０００９】
上記カラオケコンクールシステムによれば、自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、通信網を介して接続された検索サーバを用いて、前記受信したイベントＩＤに対応付けられている楽曲ＩＤ及びカラオケ店舗の属性情報をキーワードとして検索し、他店舗のサーバ制御手段のＩＰアドレスを特定する情報を含む検索結果を取得し、取得した検索結果に基き、他店舗の店舗サーバのＩＰアドレスを特定し、自店舗のサーバ制御手段は、特定したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせる。他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信し、受信したイベント情報を、前記カラオケ装置に送信する。前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する。これにより、イベントを企画する者にとっては、ユーザが自イベントに参加することなく他イベントへの参加変更することを防止することができる。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他者にとっては、該他者のイベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。また、検索サーバを利用することにより、他店舗の店舗サーバのＩＰアドレスを取得することができる。
【００１０】
本発明の一側面である請求項３に係る発明は、請求項１または請求項２のカラオケコンクールシステムであって、前記サーバ制御手段は、ＮＧＮ通信網を介して楽曲データベースと通信可能であり、前記楽曲データベースとの通信に用いるプロトコルはＰＰＰｏＥであり、前記他店舗の店舗サーバとの通信に用いるプロトコルはＳＩＰであることを特徴とする。
【００１１】
上記カラオケコンクールシステムによれば、前記サーバ制御手段は、ＮＧＮ通信網を介して楽曲データベースと通信可能である。前記楽曲の配信に用いる通信プロトコルとイベント情報を取得に用いる通信プロトコルを異ならせることにより、受信するデータの内容に応じて、通信品質を変更させることができる。
【００１２】
本発明の一側面である請求項４に係る発明は、請求項２のカラオケコンクールシステムであって、前記ＩＰアドレスを特定する情報は暗号化されており、前記自店舗のサーバ制御手段は、前記取得した検索結果から前記ＩＰアドレスを特定する情報を抽出し、前記ＩＰアドレス特定する情報を復号化することにより、他店舗の店舗サーバのＩＰアドレスを特定することを特徴とする。
【００１３】
上記カラオケコンクールシステムによれば、ＩＰアドレスを特定する情報は暗号化されており、該情報を取得した自店舗の自店舗サーバは、受信した情報を復号化することにより、他店舗のＩＰアドレスを特定する。これにより、他店舗のＩＰアドレスが検索可能に公開されることを防ぐことができるので、ネットワーク・セキュリティを向上させることができる。
【００１４】
本発明の一側面である請求項５に係る発明は、請求項１乃至請求項４いずれかのカラオケコンクールシステムであって、前記有利な条件とは、（１）同一順位の賞品金額を比較したときに、前記参加確定されたイベント順位の賞品よりも高い金額である、（２）もしくは、前記参加確定されたイベントの賞品総額よりも高い賞品総額である、（３）もしくは、前記参加確定されたイベントよりも低い順位で賞品が存在することを特徴とする。
【００１５】
一般的にコンクールは、賞品金額が高額であるほど、または、賞品が最高の順位（優勝）から低い順位に渡り、より広範囲の順位に提供されるほど集客力が高い。上記カラオケコンクールシステムによれば、前記有利な条件として、同一順位の賞品金額を比較したときに、前記参加確定されたイベント順位の賞品よりも高い金額である、前記参加確定されたイベントの賞品総額よりも高い金額である、前記参加確定されたイベントよりも低い順位で賞品が存在する、のいずれかを用いる。これにより、イベントに関する集客力の向上を図ることができる。
【発明の効果】
【００１６】
本発明によれば、参加確定の指示を受け付けた後で、より好条件な他のイベントを提示するカラオケコンクールシステム等を提供することができる。これによって、自店舗の集客力を低下させることなく特定のグループ（例えば、チェーン店）に属する他店舗におけるイベント情報を提示することができ、カラオケコンクールをビジネスモデルとして成功させることができる。
【発明を実施するための最良の形態】
【００１７】
本発明を具体化した実施形態について、以下、図面を参照しつつ詳細に説明する。以下の説明においては、「自店舗」とは「歌唱に関する操作及びカラオケコンクールに関する操作が行われたカラオケ店舗」を意味し、「他店舗」とは「自店舗以外のカラオケ店舗」を意味するものとする。
【００１８】
［第１実施形態］
まず、本発明の一実施形態である第１実施形態について説明する。
【００１９】
（システム構成）
図１は、第１実施形態におけるカラオケシステムのネットワーク構成を示した図である。
本実施形態のカラオケシステムは、各地のカラオケ店舗等に設置されたカラオケ装置１００、店舗サーバ２００、通信網、管理サーバ３００、とから基本的に構成される。
カラオケ装置１００は、カラオケ店舗の客室ごとに設置されている。
店舗サーバ２００は、カラオケ店舗ごとに設置されている。
カラオケ装置１００と管理サーバ３００とは、例えば、カラオケ店舗内の店舗サーバ２００を介して、通信網によって接続される。また、自店舗の店舗サーバ２００は、他店舗の店舗サーバ２００と通信網によって接続される。
ここで、通信網としては、有線、無線、併用どのような形態でもよく、また、インターネットを利用したＶＰＮ（Virtual Private Network）であってもよい。また、ＮＧＮ（Next Generation Network）通信網を用いてもよい。
【００２０】
まず、管理サーバ３００について説明する。
管理サーバ３００は、コントローラ３０１、楽曲データベース３０２、歌唱者情報データベース３０３、とから基本的に構成される。
コントローラ３０１は、管理サーバ３００全体を制御するものであり、プロセッサ（例えば、ＣＰＵ）によって実現される。
【００２１】
楽曲データベース３０２には、カラオケ楽曲の演奏に用いられる種々のデータが記憶されている。
図２は、楽曲データベース３０２のデータ構造の一例を示した図である。図２に示すように、楽曲ＩＤをキーとして、楽音データ、背景データ、歌手名、歌詞、等が記憶されている。
「楽曲ＩＤ」は、カラオケ楽曲ごとに付されたユニークな識別符号である。
「楽音データ」は、カラオケ楽曲の生成起源となるデータである。例えば、ＭＩＤＩデータ、ＭＰＥＧデータとすることができるが、本発明においては、楽音データのフォーマットはどのようなものであってもよい。
「背景データ」は、カラオケ楽曲の演奏中に表示される背景画像（動画、静止画）の生成起源となるデータである。本発明においては、背景データのフォーマットはどのようなものであってもよい。
「歌手名」は、カラオケ楽曲原曲の歌手名である。カラオケ楽曲の再生開始時等に表示される。
「歌詞」は、カラオケ楽曲の演奏中に表示される。楽曲再生中の歌詞表示態様については公知の種々の技術を用いることができる。
【００２２】
楽曲データベース３０２は、適宜のタイミングで更新される。例えば、所定の時間間隔で更新（例えば、日単位）してもよく、新曲が作成されるごとに更新してもよい。
なお、図２で示したデータ構造は、単なる一例であり、本発明は、このデータ構造を用いるシステムに限定されないことはいうまでもない。
【００２３】
歌唱者情報データベース３０３には、歌唱者に関する種々の情報が記憶されている。
図３は、歌唱者情報データベース３０３のデータ構造の一例を示した図である。図３に示すように、歌唱者ＩＤをキーとして、ニックネーム、住所、性別、生年月日、等が記憶されている。
【００２４】
「歌唱者ＩＤ」は、歌唱者を識別するためのユニークな識別符号である。
「ニックネーム」は、例えば、カラオケ装置１００において、順位を表示する際に用いられる。ニックネームは、歌唱者自身が任意に決めることができる。
「住所」は、歌唱者の住所である。住所は、例えば、ダイレクトメールの発送の際に用いられることがある。
「性別」は、歌唱者の性別である。
「生年月日」は、歌唱者の生年月日である。
「趣味」は、歌唱者の趣味である。１人の歌唱者に、複数の趣味が対応付けられることがある。
【００２５】
歌唱者情報データベース３０３は、適宜のタイミングで更新される。例えば、新規登録があるごとに更新することができる。
なお、図３で示したデータ構造は、単なる一例であり、本発明は、このデータ構造を用いるシステムに限定されないことはいうまでもない。
【００２６】
また、歌唱者情報は、リモコンを用いて登録することができる。また、パソコンや携帯電話を用いて登録することができる。また、プロフィール、持ち歌、歌った曲の履歴、等のカラオケ楽曲に関する情報を保存することができる。また、歌唱者情報データベース３０３の歌唱者自身の情報については、パソコン、携帯を用いてアクセスできるよう構成してもよい。また、カラオケＳＮＳサービスと関連付けてもよい。また、本発明において実施されるイベント（カラオケコンクール）に参加するには、歌唱者情報データベース３０３に個人情報を登録する必要がある。
【００２７】
次に、店舗サーバ２００について説明する。
店舗サーバ２００は、他店舗の店舗サーバと通信可能である。また、他店舗の店舗サーバとの通信には、ＳＩＰ（Session Initiation Protocol）を用いることができる。
店舗サーバ２００は、図１に示すように、コントローラ２０１、イベント情報データベース２０２、順位表データベース２０３、ＩＰアドレスデータベース２０４、とから基本的に構成される。
コントローラ２０１は、店舗サーバ２００全体を制御するものであり、プロセッサ（例えば、ＣＰＵ）によって実現される。
【００２８】
図１に示した構成においては、店舗サーバ２００が、各客室のコマンダ１０２とは別体として構成されているが、カラオケ店舗内のいずれかのコマンダ１０２が、店舗サーバ２００が有する機能を備えるように構成してもよい。この場合、店舗サーバ２００の機能を備えるコマンダ１０２を「親コマンダ」、該機能を有していないコマンダ１０２を「子コマンダ」とすれば、「親コマンダ」と「子コマンダ」は、マスタ−スレーブの関係とみなすことができる。そして、「子コマンダ」は、「親コマンダ」に対し、所定の要求を出力する。「親コマンダ」は、「子コマンダ」から所定の要求を受信すると、該要求に応じた処理を行う。
また、「親コマンダ」は、自己に対し、所定の要求を出力する。「親コマンダ」は、自己の要求に応じた処理を行う。
【００２９】
イベント情報データベース２０２には、自店舗のイベント（カラオケコンクール）に関する種々の情報が記憶されている。
図４は、イベント情報データベース２０２のデータ構造の一例を示した図である。図４に示すように、イベントＩＤをキーとして、課題曲（楽曲ＩＤ）、企画者、実施期間、参加費、受賞者順位、賞品、等が記憶されている。換言すれば、イベント情報データベース２０２には、イベントごとに、課題曲として歌唱可能な楽曲の楽曲ＩＤが、イベントＩＤ、企画者、実施期間、受賞要項の組を含む情報に対応付けられている。
【００３０】
「イベントＩＤ」は、イベントごとに付されたユニークな識別符号である。
「課題曲（楽曲ＩＤ）」は、そのイベントで用いられる課題曲である。なお、１つのイベントで複数の課題曲が用いられることもある。また、楽曲ＩＤで定義されている。イベント情報データベース２０２及び楽曲データベース３０２における「楽曲ＩＤ」は共通である。
「企画者」は、そのイベントを企画した者（会社、団体等）である。また、スポンサーが企画者となることもある。この場合、企画者の情報は、スポンサー情報である。また、カラオケ店舗が企画者となることもある。すなわち、各カラオケ店舗において独自にイベントを企画することができる。この場合、該カラオケ店舗で歌唱をしないと該イベントに参加できないよう企画することができる。これにより、カラオケ店舗独自のイベントには、該カラオケ店舗への集客力の向上を図る効果がある。
【００３１】
「実施期間」は、そのイベントの実施期間である。例えば、開始日及び終了日で定義することができる。なお、日単位ではなく、時間単位（例えば、２００６年１０月１日１５：００〜２００６年１０月２１日１０：００等）で定義してもよいことはもちろんである。
「参加費」は、そのイベントに参加するために必要な費用である。すべてのイベントの参加費を一律となるように構成された場合は、参加費属性は設定する必要はない。
「受賞者順位」は、賞を授与することができる順位である。
「賞品」は、上記受賞者順位内に入賞した者に付与される賞品に関する情報である。
【００３２】
図５は、イベント情報データベース２０２（図４）の「賞品」属性の詳細なデータ構造を示している。図５に示すように、「賞品」属性は、順位、賞品名、賞品金額、画像、趣味の組を含む情報を有する。
「順位」は、賞が付与される順位である。
「賞品名」は、付与される賞品の名称である。なお、図５に示した内容は単なる一例である。例えば、「宿泊券」については、「場所、宿泊可能日時」等の詳細情報が「賞品名」に含まれる。また、「ＭＰ３プレイヤ」については、「メーカ名、型番」等の詳細情報が、「賞品名」に含まれる。また、「ディナー券」については、「場所、利用可能日時」等の詳細情報が「賞品名」に含まれる。
【００３３】
「賞品金額」は、付与される賞品の金額である。なお、図５における数値の単位は「円」である。
「画像」は、付与される賞品の画像情報である。記憶される画像は、静止画、動画、いずれでもよい。また、賞品によって、静止画、動画を使い分けてもよい。また、画像データベースを別に有しておき、イベント情報データベース２０２には、画像データベースへのリンク情報のみを有する構成にしてもよい。また、画像の重要性が低い賞品（例えば、図書カード等）については、画像を記憶しなくてもよい。
【００３４】
「趣味」は、付与される賞品のカテゴリを示すものである。図４に示すように、例えば、「宿泊券」には「旅行」が対応付けられる。また、「ＭＰ３プレイヤ」には「音楽」が対応付けられる。また、「ディナー券」には「飲食」が対応付けられる。「趣味」は、有利な条件のイベントを抽出する際に用いられる。詳細については後述する。また、１つの賞品に対し、複数の「趣味」属性が付与されることもある。
【００３５】
イベント情報データベース２０２は、適宜のタイミングで更新される。例えば、新規イベントが発生するごとに更新することができる。また、イベント情報データベース２０２の更新には、所定の権限が必要である。
なお、図４及び図５で示したデータ構造は、単なる一例であり、本発明は、このデータ構造を用いるシステムに限定されないことはいうまでもない。
【００３６】
順位表データベース２０３には、イベントごとの歌唱者順位に関する種々の情報が記憶されている。
図６は、順位表データベース２０３のデータ構造の一例を示した図である。図６に示すように、イベントＩＤをキーとして、歌唱者ＩＤ、採点値、登録日、順位、等が記憶されている。
【００３７】
「イベントＩＤ」は、イベント情報データベース２０２のイベントＩＤと共通である。
「歌唱者ＩＤ」は、歌唱者ごとに付されたユニークな識別符号である。「歌唱者ＩＤ」は、歌唱者データベース３０３の「歌唱者ＩＤ」と共通である。
「採点値」は、そのイベントの課題曲を歌唱したときの採点値である。採点値の満点は、例えば、１００点とすることができるが、１０００点満点でもよい。また、採点値の最小値は１点単位でもよく、また、小数点第１位または第２位まで算出するように構成してもよい。
「登録日」は、そのイベントに参加登録した日（すなわち、課題曲を歌唱した日）である。
「順位」は、そのイベントにおける現時点での順位である。
【００３８】
順位表データベース２０３は、適宜のタイミングで更新される。例えば、ユーザがイベントに参加するごとに更新することができる。
なお、図６で示したデータ構造は、単なる一例であり、本発明は、このデータ構造を用いるシステムに限定されないことはいうまでもない。
【００３９】
ＩＰアドレスデータベース２０４は、チェーン店に属する他店舗の店舗サーバのＩＰアドレスの一覧を有している。ＩＰアドレスデータベース２０４は、適宜のタイミングで更新される。例えば、チェーン店に属する店舗の追加及び削除があったときに更新することができる。また、ＩＰアドレスデータベース２０４の更新には、所定の権限が必要である。
【００４０】
また、店舗サーバ２００は、所定の楽曲データを、管理サーバ３００の楽曲データベース３０２からダウンロードする。また、コマンダ１０２からリクエストがあった楽曲は、リクエスト毎に管理サーバ３００からダウンロードしてもよく、また、店舗サーバ２００またはコマンダ１０２に一時的に記憶しておくように構成してもよい。また、一度ダウンロードした楽曲を所定時間のみ記憶するようにしてもよい。なお、店舗サーバ２００またはコマンダ１０２に記憶する場合は、所定の記憶手段を有しているものとする。
【００４１】
次に、カラオケ装置について説明する。
図７は、カラオケ装置１００のシステム構成の一例である。図７に示すように、カラオケ装置１００は、リモコン１０１とコマンダ１０２とから構成される。なお、複数のリモコン１０１が、コマンダ１０２と通信可能となるように構成してもよい。
【００４２】
リモコン１０１は、赤外線通信Ｉ／Ｆ１１１、電波通信Ｉ／Ｆ１１２、ＣＰＵ１１３、ＲＯＭ１１４、ＲＡＭ１１５、表示部１１６、操作部１１７、から基本的に構成される。
【００４３】
コマンダ１０２は、赤外線通信Ｉ／Ｆ１２１、電波通信Ｉ／Ｆ１２２、ＣＰＵ１２３、ＲＯＭ１２４、ＲＡＭ１２５、補助記憶手段１２６、映像音声再生手段１２７、から基本的に構成される。
【００４４】
赤外線通信Ｉ／Ｆ１１１及び赤外線Ｉ／Ｆ１２１は、リモコン１０１とコマンダ１０２とが赤外線を媒体とする無線通信（以下、「赤外線通信」という。）を行うためのインタフェースである。
電波通信Ｉ／Ｆ１１２及び電波Ｉ／Ｆ１２２は、リモコン１０１とコマンダ１０２とが電波を媒体とする無線通信（以下、「電波通信」という。）を行うためのインタフェースである。
また、電波通信Ｉ／Ｆ１１２及び電波通信Ｉ／Ｆ１２２を用いることにより、ホストとの間で種々の情報を送受信することも可能である。
また、コマンダとリモコンとは、アクセスポイントを介して無線通信を行ってもよい。
リモコンで受け付けた各種操作信号は、コマンダに送信される。また、種々の情報がコマンダからリモコンに送信される。ここで、赤外線通信と無線通信とは、送受信される情報の種類等に応じて適宜切り替えて用いることができる。
【００４５】
また、それぞれのリモコン１０１及びコマンダ１０２がイーサネット（登録商標）等で接続されている場合は、それぞれの機器に対して固有のＩＰアドレスが付されている。また、ＩＰアドレスは、それぞれの機器が有する識別番号及び所定の生成式に基いて算出することができる。
【００４６】
ＣＰＵ１１３及びＣＰＵ１２３は、本発明を実現するために必要なプログラムを含む種々のプログラムを実行する。ＲＯＭ１１４及びＲＯＭ１２４は、本発明を実現するために必要な情報を含む種々のデータを記憶する。ＲＡＭ１１５及びＲＡＭ１２５は、本発明を実現するために必要な情報を含む種々のデータを一時的に記憶する。
【００４７】
リモコン１０１には、表示部１１６が設けられている。表示部１１６には、本発明の実現するために必要な情報を含む種々の情報を表示する。リモコン１０１には、操作部１１７が設けられている。操作部１１７は、表示部１１６の表面にタッチパネルとして実現してもよい。
【００４８】
コマンダ１０２には、補助記憶手段１２６が設けられている。補助記憶手段１２６には、例えば、楽曲の再生に必要な音声データ及び映像データ等が記憶される。また、ゲーム等のアプリケーションデータが記憶される。これらのデータは、ダウンロードによって受信している。
【００４９】
コマンダ１０２には、映像音声再生手段１２７が設けられている。映像音声再生手段１２７は、楽曲の再生及び映像の再生を行う。また、店舗サーバ等から送信されたデータに基いてストリーミング再生を行うことも可能である。
【００５０】
また、図示しない音声入力手段（マイク等）、映像表示手段（ディスプレイ等）が、コマンダ１０２に接続されている。また、コマンダ１０２は、採点機能を有する。
【００５１】
また、コマンダ１０２が、上述した「親コマンダ」として機能する場合は、管理サーバ３００及び他店舗の店舗サーバ２００と接続するための手段を有する。
【００５２】
（カラオケコンクール処理において送受信される情報）
次に、カラオケコンクールに係る処理において、リモコン、コマンダ、店舗サーバとの間で送受信される情報を説明する。図８は、リモコン１０１、コマンダ１０２、店舗サーバ２００との間で送受信される情報の一例を示した図である。
【００５３】
リモコン１０１は、ユーザよりイベントに関する情報（イベント関連情報）を要求するための操作を受付けると（１）、コマンダ１０２に対し、イベント関連情報を要求するためのイベント関連情報要求信号を送信する（２）。
コマンダ１０２は、イベント関連情報要求信号を受信すると、店舗サーバ２００に対し、イベント関連情報要求信号を送信する（３）。このイベント関連情報要求信号には、送信元となるコマンダ１０２（カラオケ装置）を識別するための識別情報が含まれている。
【００５４】
店舗サーバ２００は、イベント情報要求信号を受信すると、該イベント関連情報要求信号を送信したコマンダ１０２に対し、現時点で実施されている参加可能なイベント関連情報を送信する（４）。イベント関連情報には、イベント情報データベース２０２の情報が含まれる。すなわち、自店舗で企画しているイベントに関する情報が送信される。
【００５５】
コマンダ１０２は、イベント関連情報を受信すると、リモコン１０１に対し、該イベント関連情報を送信する（５）。また、不図示のディスプレイに、該イベント関連情報を表示してもよい。
リモコン１０１は、受信したイベント関連情報を表示部１１６に表示する。また、参加を意図するイベントを選択させるためのメッセージを併せて表示する。また、リモコン１０１は、ユーザによる参加イベントの選択を受け付ける（６）。
【００５６】
リモコン１０１は、コマンダ１０２に対し、選択されたイベントを示すための選択情報（イベントＩＤ等）を送信する（７）。この選択情報には、課題曲として歌唱する楽曲の楽曲ＩＤが（楽曲のリクエスト信号として）含まれている。
【００５７】
コマンダ１０２は、選択情報を受信すると、店舗サーバ２００に対し、選択情報を送信する（８）。この選択情報には、送信元となるコマンダ１０２（カラオケ装置）を識別するための識別情報が含まれている。また、課題曲として歌唱する楽曲を再生するための楽音データ等の要求信号が含まれることもある。該課題曲の楽音データ等が、既にコマンダ１０２に蓄積されている場合は、該要求信号を含ませる必要はない。
【００５８】
店舗サーバ２００は、選択情報を受信すると、選択されたイベントの順位表情報を送信する（９）。この順位表情報には、歌唱者ごとの採点データが含まれる。すなわち、コマンダ１０２が順位を算出するために必要な情報が含まれる。楽音データ等の要求信号が含まれている場合は、該データについても送信する。このとき、要求された楽音データ等が店舗サーバ２００内に存在しない場合は、管理サーバ３００に該楽音データ等の要求信号を出力する。
【００５９】
コマンダ１０２は、順位表情報を受信すると、リモコン１０１から受信した選択情報に含まれる楽曲ＩＤで特定される楽曲の演奏を開始し、また、当該楽曲の歌唱を採点する（１０）。
【００６０】
店舗サーバ２００は、選択されたイベントの順位表情報を送信したあと、該イベントの課題曲を含む他店舗のイベント（同じ課題曲を有する他のイベント）を検索する（１１）。他店舗のイベントの検索についての詳細は後述する。
【００６１】
店舗サーバ２００は、同じ課題曲を有するイベントを取得した場合は、コマンダ１０２に対し、該イベントのイベント情報を送信する（１２）。
【００６２】
該楽曲の歌唱が終了すると、コマンダ１０２は、上記（６）で受け付けたイベントにおける順位を算出する（１３）。このとき、上記（９）で受信した順位表情報が用いられる。また、算出した順位、及び、受信した検索結果（他のイベント情報）に基づいて、より有利な条件のイベントを抽出する（１３）。より有利な条件のイベント抽出方法については後述する。また、算出した順位は、不図示のディスプレイに表示される（１３）。
【００６３】
コマンダ１０２は、リモコン１０１に対し、リモコン１０１上に表示させる表示内容信号を送信する（１４）。表示内容信号には、イベントへの参加確定を促す画面を表示させるための指示信号が含まれる。また、上記ディスプレイに表示した順位を示す情報を含ませてもよい。
【００６４】
リモコン１０１は、イベントへの参加確定を促す画面を表示し、また、参加確定指示を受け付ける（１５）。
【００６５】
参加確定指示を受け付けると、リモコン１０１は、コマンダ１０２に対し、参加確定信号を送信する（１６）。
コマンダ１０２は、参加確定信号を受信すると、他のイベントのイベント関連情報を、図示のディスプレイに表示する（１７）。また、リモコン１０１の表示部１１６にも同様に他のイベントのイベント関連情報を表示してもよい。他のイベントのイベント関連情報の表示レイアウト等については後述する。
【００６６】
イベントへの参加確定信号を受信したあとで他のイベントに関する情報を表示することにより、イベントへの参加を確実にしつつ、他のイベントの対する提示（告知）を行うことができる。また、ユーザは、他店舗でのイベントに関する情報を取得することができる。
【００６７】
コマンダ１０２は、参加確定信号を受信すると、店舗サーバ２００に対し、参加確定信号を送信する（１８）。この参加確定信号には、イベントＩＤ、歌唱者ＩＤ、採点データが含まれている。また、楽曲ＩＤを含ませてもよい。
【００６８】
店舗サーバ２００は、参加確定信号を受信すると、該参加確定信号に含まれるイベントＩＤ、歌唱者ＩＤ、採点データ等に基づいて、順位表データベースに登録する（１９）。これにより、順位表データベース２０３は更新されることになる。
【００６９】
（店舗サーバでの他店舗イベント検索処理）
次に、店舗サーバ２００での他店舗イベント検索処理（図８の（１１））について説明する。図９は、店舗サーバ２００での他店舗イベントの検索において、他店舗の店舗サーバとの間で送受信される情報を示している。図９においては、他店舗α及び他店舗βの店舗サーバ２００との間で送受信される情報について説明するが、本発明は、情報を送受信する他店舗の数は限定されない。
【００７０】
自店舗の店舗サーバ２００は、コマンダ１０２から選択情報を受信し（８）、順位表情報を送信した（９）あと、ＩＰアドレスデータベース２０４を検索し、チェーン店に属する他店舗のＩＰアドレスを取得する（Ａ）。図９においては、他店舗α及び他店舗βのＩＰアドレスを取得する。
【００７１】
自店舗の店舗サーバ２００は、他店舗α（のＩＰアドレス）に対し、上記（８）で受信した課題曲を含むイベントを行っているか否かについて問い合わせるための問い合わせ信号を送信する（Ｂ）。該問い合わせ信号には、該課題曲の楽曲ＩＤが含まれる。
他店舗αとＳＩＰで接続した場合には、前記（Ｂ）において、前記問い合わせ信号を、通話中の発呼側（自店舗の店舗サーバ２００）の音声データに代わるデータとして着呼側（他店舗αの店舗サーバ２００）へ送信する。
【００７２】
他店舗αの店舗サーバ２００は、上記問い合わせ信号を受信すると、該問い合わせ信号に含まれる課題曲と同じ課題曲を有する参加可能なイベントが存在するか否かを検索する（Ｃ）。このとき、他店舗αの店舗サーバ２００が有するイベント情報データベース２０２が用いられる。
【００７３】
他店舗αの店舗サーバ２００は、同じ課題曲を有する参加可能なイベント（自店舗側を基準とした場合の他店舗イベント）が存在する場合は、該イベントのイベント関連情報を回答信号として送信する（Ｄ）。また、存在しない場合は、その旨を示す回答信号を送信する。
他店舗αとＳＩＰで接続された場合には、前記（Ｄ）において、前記回答信号を、通話中の着呼側（他店舗αの店舗サーバ２００）からの音声データに代わるデータとして発呼側（自店舗の店舗サーバ２００）へ送信する。
【００７４】
自店舗の店舗サーバ２００は、他店舗β（のＩＰアドレス）に対し、上記（８）で受信した課題曲を含むイベントを行っているか否かについての問い合わせ信号を送信する（Ｅ）。該問い合わせ信号には、該課題曲の楽曲ＩＤが含まれる。
他店舗βとＳＩＰで接続した場合には、前記（Ｅ）において、前記問い合わせ信号を、通話中の発呼側（自店舗の店舗サーバ２００）の音声データに代わるデータとして着呼側（他店舗βの店舗サーバ２００）へ送信する。
【００７５】
他店舗βの店舗サーバ２００は、上記問い合わせ信号を受信すると、該問い合わせ信号に含まれる課題曲と同じ課題曲を有する参加可能なイベントが存在するか否かを検索する（Ｆ）。このとき、他店舗βの店舗サーバ２００が有するイベント情報データベース２０２が用いられる。
【００７６】
他店舗βの店舗サーバ２００は、同じ課題曲を有する参加可能なイベント（自店舗側を基準とした場合の他店舗イベント）が存在する場合は、該イベントのイベント関連情報を回答信号として送信する（Ｇ）。また、存在しない場合は、その旨を示す回答信号を送信する。
他店舗βとＳＩＰで接続された場合には、前記（Ｇ）において、前記回答信号を、通話中の着呼側（他店舗βの店舗サーバ２００）からの音声データに代わるデータとして発呼側（自店舗の店舗サーバ２００）へ送信する。
【００７７】
自店舗の店舗サーバ２００は、他店舗α及び他店舗βから受信した情報を統合し、コマンダ１０２に対し、検索結果として送信する（１２）。
【００７８】
図９における処理では、問い合わせ信号に課題曲ＩＤが含まれ、他店舗の店舗サーバ２００において、課題曲が一致する参加可能なイベントを抽出しているが、本発明は別の形態としても実現可能である。例えば、問い合わせ信号に課題曲ＩＤを含ませず、他店舗の店舗サーバ２００は、参加可能なイベントを全て自店舗の店舗サーバ２００に送信し、自店舗の店舗サーバ２００において課題曲が一致するイベントを抽出するように構成してもよい。
【００７９】
また、図９における処理において、自店舗サーバ２００におけるＳＩＰによる電話収容数が「１」である場合には、自店舗の店舗サーバ２００は、上記（Ｄ）の回答信号を受信したあと、他店舗αに対する呼を切断する。その後、他店舗βに対し呼接続を開始する。
また、自店舗の店舗サーバ２００におけるＳＩＰによる電話収容数が複数である場合には、他店舗αとの呼を接続したままで、他店舗βとの呼接続をも開始する。これにより、呼接続と切断を順次行いながら他店舗から回答信号を収集するよりも、回答信号を早く収集することができる。
【００８０】
また、図９における処理では、それぞれの他店舗に順に問い合わせを行ったが、他店舗との通信網がＩＰｖ６であり、マルチキャスト通信可能であれば、前記（Ｂ）の時点で、マルチキャスト通信を用いて、複数の他店舗に問い合わせ信号を送信することができる。そして、複数の他店舗から順次回答信号を受信する。
なお、この場合、他店舗の店舗サーバ２００は、マルチキャスト参加報告をＩＰｖ６の通信網のルータに事前に登録しているものとする（マルチキャスト参加報告は、例えば、ＲＦＣ３８１０で説明されるＭＬＤｖ２（Multicast Listener Discovery Version 2）Ｒｅｐｏｒｔなど）。
【００８１】
上述した処理によれば、イベントへの参加確定指示を受け付けたあとで他のイベント情報を提示するので、イベントを企画する者（自店舗等）にとっては、ユーザが自イベントに参加することなく他イベントへ参加変更することを防止することができる。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他店舗にとっては、イベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。
【００８２】
（リモコン側の処理の流れ）
次に、イベント関連情報要求操作を受け付けた後、イベント参加確定を受け付けるまでのリモコン側の処理の流れについて説明する。
図１０は、リモコン側の処理のフローチャートである。
【００８３】
まず、Ｓ１において、ユーザより、イベント関連情報要求の操作を受け付ける。このとき、例えば、リモコン１０１のタッチパネルが用いられる。
Ｓ２において、コマンダ１０２に対し、イベント関連情報要求信号を送信する。イベント関連情報要求信号を送信した後は、イベント関連情報を受信するまで処理が待機されることになる。
【００８４】
Ｓ３において、コマンダ１０２より送信されたイベント関連情報を受信する。イベント関連情報には、自店舗で企画されている参加可能なイベントに関する情報（イベント情報データベース２０２に記憶されている情報）が含まれる。なお、他店舗独自のイベントに関する情報については受信することができない。
【００８５】
Ｓ４において、受信したイベント関連情報に基いて、参加可能なイベントを関連情報（賞品、企画者等）とともに表示する。なお、参加可能なイベント及びその関連情報は、コマンダ１０２に接続されるディスプレイに表示するよう構成してもよい。また、参加するイベントを選択可能であることを示すメッセージについても表示する。なお、タッチパネル上の表示レイアウトは適宜設定可能である。
【００８６】
Ｓ５において、ユーザより、参加するイベントを受け付ける。このとき、ユーザはリモコン１０１を用いて参加のための操作を行うことができる。なお、本実施形態においては、Ｓ５における参加受付は「仮受付」であり、後述する「参加確定」指示を行わないと該イベントへの参加手続きが終了しないものとする。
【００８７】
Ｓ６において、受け付けたイベントを示すための選択情報（イベントＩＤ等）をコマンダ１０２に対し送信する。このとき、受け付けたイベントに対応する課題曲の楽曲ＩＤは、リクエスト情報として送信される。選択情報を送信した後、該楽曲ＩＤの楽曲演奏が終了し、該演奏の順位を受信するまで処理が待機されることになる。
【００８８】
Ｓ７において、コマンダ１０２により表示内容信号を受信する。また、表示内容信号に、歌唱順位が含まれていてもよい。
Ｓ８において、上記「仮受付」したイベントへの参加確定を促す画面を表示する。
【００８９】
Ｓ９において、イベントへの参加確定指示を受け付ける。このとき、例えば、リモコン１０１のタッチパネルが用いられる。また、イベントへの不参加指示を受け付け可能に構成してもよい。
Ｓ１０において、コマンダ１０２に対し、参加確定信号を送信する。
【００９０】
（コマンダ側の処理の流れ）
参加イベントに係る選択情報を受信し、イベント参加確定に係る参加確定信号を送信するまでのコマンダ側の処理の流れについて説明する。
図１１は、コマンダ側の処理のフローチャートである。
【００９１】
Ｓ１１において、リモコン１０１より送信された選択情報を受信する。
Ｓ１２において、店舗サーバ２００に対し、Ｓ１１で受信した選択情報を送信する。また、参加するイベントの課題曲の楽曲データ等が必要である場合は、その旨を示す情報が選択情報に含まれる。選択情報を送信した後、順位表情報を受信するまで処理が待機することになる。
【００９２】
Ｓ１３において、店舗サーバ２００から順位表情報（必要に応じ、楽曲データ等）を受信する。
Ｓ１４において、Ｓ１１で受信した選択情報に含まれる楽曲ＩＤの楽曲の演奏を開始する。そして、楽曲の演奏が終了するまで、処理はＳ１５で待機する。
楽曲の演奏が終了すると（Ｓ１５：ＹＥＳ）、Ｓ１６に移行する。
【００９３】
Ｓ１６において、検索結果を受信する。なお、楽曲の演奏中（すなわち、Ｓ１５での待機中）に検索結果を受信することもある。
【００９４】
Ｓ１７において、Ｓ１３で受信した順位表情報に基づいて順位を算出する。
Ｓ１８において、Ｓ１７で算出した順位を不図示のディスプレイに表示する。また、イベントへの参加確定を促す画面を表示してもよい。
【００９５】
Ｓ１９において、Ｓ１６で受信した検索結果に基づいて、より有利な条件のイベントを抽出する。より有利な条件のイベントの抽出方法については後述する。
Ｓ２０において、リモコン１０１上に表示させる表示内容信号を送信する。
【００９６】
表示内容信号を送信した後、参加確定信号を受信するまで、処理はＳ２０で待機する。
参加確定信号を受信すると（Ｓ２０：ＹＥＳ）、Ｓ２１に移行する。なお、Ｓ２０待機中に、リモコン１０１からイベントへの不参加を通知する信号を受信した場合は、コマンダ側の処理を終了する。
【００９７】
Ｓ２１において、Ｓ１９で抽出したより有利な条件の他のイベントに関する情報を表示する。
Ｓ２２において、店舗サーバ２００に対し、参加確定信号を送信する。
【００９８】
（店舗サーバ側の処理の流れ）
次に、店舗サーバ側の処理の流れについて説明する。図１２は、店舗サーバ側の処理のフローチャートである。図１２のフローチャートに示される処理は、所定のタイミングごとに繰り返し実行される。また、図１２に示すフローチャートに示される処理は、上述した図９における「自店舗の店舗サーバにおける処理」と「他店舗の店舗サーバにおける処理」が含まれる。
【００９９】
Ｓ３１において、自店舗のコマンダ１０２からイベント関連情報要求信号を受信したか否かを判断する。
イベント関連情報要求信号を受信していないと判断した場合は（Ｓ３１：ＮＯ）、Ｓ３３に移行する。一方、イベント関連情報要求信号を受信したと判断した場合は（Ｓ３１：ＹＥＳ）、Ｓ３２に移行する。
【０１００】
Ｓ３２において、Ｓ３１で受信したイベント関連情報要求信号を送信したコマンダ１０２に対し、イベント関連情報を送信する。送信するイベント関連情報は、イベント情報データベース２０２を参照して決定される。このとき、該イベント関連情報要求信号を受信した時刻を特定し、当該時刻が実施期間に含まれるイベントが抽出される。
【０１０１】
Ｓ３３において、自店舗のコマンダ１０２から選択情報を受信したか否かを判断する。
選択情報を受信していないと判断した場合は（Ｓ３３：ＮＯ）、Ｓ３７に移行する。一方、選択情報を受信したと判断した場合は（Ｓ３３：ＹＥＳ）、Ｓ３４に移行する。
【０１０２】
Ｓ３４において、Ｓ３３で受信した選択情報を送信したコマンダ１０２に対し、順位表情報を送信する。送信する順位表情報は、順位表データベース２０３を参照して決定される。具体的には、受信した選択情報に含まれるイベントＩＤで特定されるイベントにおける採点データ等が送信する順位表情報となる。
【０１０３】
Ｓ３５において、イベント検索処理を実行する。
図１３は、イベント検索処理のフローチャートである。
Ｓ５１において、ＩＰアドレスを取得する。このとき、ＩＰアドレスデータベース２０４が参照される。取得したＩＰアドレスは、所定の記憶手段に一時的に記憶される。
Ｓ５２において、問い合わせ信号（他店舗イベントが存在するか否かを問い合わせるもの）を他店舗の店舗サーバ２００に送信する。
【０１０４】
Ｓ５３において、問い合わせ信号を送信した他店舗の店舗サーバ２００から回答信号を受信する。受信した回答信号は、所定の記憶手段に一時的に記憶される。
Ｓ５４において、Ｓ５１で取得し全てのＩＰアドレス（他店舗）に対し、問い合わせ信号を送信したか否かを判断する。
問い合わせ信号を送信していないＩＰアドレスが存在すると判断した場合は（Ｓ５４：ＮＯ）、Ｓ５２に戻る。
一方、全てのＩＰアドレス（他店舗）に対し、問い合わせ信号を送信したと判断した場合は（Ｓ５４：ＹＥＳ）、イベント検索処理を終了する。
【０１０５】
図１２に説明を戻す。
Ｓ３６において、コマンダ１０２に対し、イベント検索処理での検索結果を送信する。
【０１０６】
Ｓ３７において、自店舗のコマンダ１０２から参加確定信号を受信したか否かを判断する。
参加確定信号を受信していないと判断した場合は（Ｓ３７：ＮＯ）Ｓ３９に移行する。一方、参加確定信号を受信したと判断した場合は（Ｓ３７：ＹＥＳ）、Ｓ３８に移行する。
【０１０７】
Ｓ３８において、Ｓ３７で受信した選択確定情報に基いて、順位表データベース２０３を更新する。すなわち、受信した選択確定情報に含まれる情報（歌唱者ＩＤ、採点データ）等が、順位表データベース２０３に登録される。
【０１０８】
Ｓ３９において、他店舗の店舗サーバ２００から問い合わせ信号を受信したか否かを判断する。
問い合わせ信号を受信していないと判断した場合は（Ｓ３９：ＮＯ）、店舗サーバ側の処理を終了する。
一方、問い合わせ信号を受信したと判断した場合は（Ｓ３９：ＹＥＳ）、Ｓ４０に移行する。Ｓ４０において、回答信号送信処理を行う。
【０１０９】
図１４は、回答信号送信処理のフローチャートである。回答信号送信処理は、図９の「他店舗の店舗サーバにおける処理」として実行されるものである。
Ｓ６１において、イベント（自店舗側を基準とした場合の他店舗イベント）を検索する。このとき、イベント情報データベース２０２が参照される。
【０１１０】
Ｓ６２において、回答信号を生成する。課題曲が一致する参加可能なイベントを抽出した場合は、該イベントのイベント関連情報が回答信号に含まれる。なお、将来的に参加可能なイベントであっても、現時刻とイベント開始日時（すなわち、参加可能開始日時）の差が所定内であれば抽出するよう構成してもよい。例えば、課題曲が一致するイベントＸの開催開始日時が「２００８年４月２０日」であり、現時刻が「２００８年４月１５日１０：００」である場合に、当該イベントＸを抽出するように構成してもよい。
また、課題曲が一致するイベントを抽出しなかった場合は、その旨を示す信号が回答信号に含まれる。
【０１１１】
Ｓ６３において、Ｓ６２で生成した回答信号を、Ｓ３９（図１２）の問い合わせ信号の送信元の店舗サーバ２００に送信する。
【０１１２】
（ＮＧＮ通信網を用いた場合の通信プロトコル）
本発明は、上述したとおり、管理サーバ３００及び他店舗の店舗サーバ２００との通信に用いる通信網として、ＮＧＮ通信網を用いることができる。このとき、管理サーバ３００から楽曲データをダウンロードする場合には、ＰＰＰｏＥ（PPP over Ethernet）プロトコルを用いることができる。また、他店舗の店舗サーバとの通信には、ＳＩＰ（Session Initiation Protocol）を用いることができる。
【０１１３】
他店舗の店舗サーバとの通信にＳＩＰを用いることにより、以下のような技術的効果を発揮させることができる。
他店舗イベント検索処理（図８の（１１））の処理において、マルチキャスト通信ができない場合、複数の他店舗に対し、それぞれ、他のイベントが存在するか否かを問い合わせる必要がある。すなわち、例えば１０店舗に問い合わせる場合は、「１番目の他店舗との通信」→「２番目の他店舗との通信」→・・・→「１０番目の他店舗との通信」を順に行う必要がある。
【０１１４】
ここで、他のイベント検索処理は、楽曲の演奏・採点処理の間に行う必要がある（図８参照）。そのため、他店舗との通信には高速性が求められる。通信を高速に行うためには、通信エラーが生じにくい（すなわち、データ再送信に基く通信遅延が生じにくい）高品質の通信を行う必要がある。
このとき、ＮＧＮ通信網においては、各店舗サーバから前記ＮＧＮ網への接続方法に関して、ＰＰＰｏＥなどの接続方法よりもＳＩＰの方が優先度が高くなるよう設定され、電話系のサービスは最優先とされている場合が多い。
よって、他のイベント検索処理するタイミングで、ＳＩＰによって他店舗との通信路を電話系サービスとしてＮＧＮ網に設定させる。前記設定された後の通信路において、音声データに代わり、他のイベントに関する情報を他店舗と通信することにより、ＳＩＰ以外の接続方法よりも高品質な通信を行うことができる。つまり、他店舗イベント検索処理を実行するタイミングで、他店舗との通信路をＳＩＰに設定させることで、通信エラーが生じにくくなり、その結果、他店舗との通信を高速に行うことができる。
【０１１５】
（有利な条件のイベントの抽出）
次に、有利な条件のイベントの抽出方法について説明する。図１５は、各店舗独自のイベントの内容を示した一例である。また、ユーザは、「Ａ店舗」において、「賞品総額：４５０００円」のイベントに参加し、歌唱順位が「３位」であり、その賞品金額が「３０００円」であり、ユーザの趣味が「スポーツ」であったとする。
【０１１６】
（その１：同一順位の賞品金額を用いる方法）
「同一順位の賞品金額を比較したときに、前記参加確定されたイベント順位の賞品よりも高い金額である」イベントを、有利な条件のイベントとすることができる。図１５の例では、ユーザの歌唱順位は「３位」であるため（賞品金額：３０００円）、各店舗イベントの「３位」の賞品金額に基づいて、有利な条件のイベントを抽出する。
【０１１７】
図１５においては、
Ｂ店舗イベントの３位の賞品金額：４０００円
Ｃ店舗イベントの３位の賞品金額：５０００円
Ｄ店舗イベントの３位の賞品金額：５０００円
Ｅ店舗イベントの３位の賞品金額：なし
である。
【０１１８】
したがって、「Ｂ店舗イベント」、「Ｃ店舗イベント」、「Ｄ店舗イベント」が、有利な条件のイベントとして抽出される。
【０１１９】
（その２：賞品総額を用いる方法）
「前記参加確定されたイベントの賞品総額よりも高い賞品総額である」イベントを、有利な条件のイベントとすることができる。図１５の例では、Ａ店舗イベントの賞品総額は「４５０００円」である。
【０１２０】
図１５においては、
Ｂ店舗イベントの賞品総額：５４０００円
Ｃ店舗イベントの賞品総額：４３０００円
Ｄ店舗イベントの賞品総額：６５０００円
Ｅ店舗イベントの賞品総額：３００００円
である。
【０１２１】
したがって、「Ｂ店舗イベント」、「Ｄ店舗イベント」が、有利な条件のイベントとして抽出される。
【０１２２】
（その３：賞品を獲得できる順位を用いる方法）
「前記参加確定されたイベントよりも低い順位で賞品が存在する」イベントを、有利な条件のイベントとすることができる。図１５の例では、ユーザの歌唱順位は「３位」である。
【０１２３】
図１５においては、
Ｂ店舗イベント：３位まで賞品獲得可能
Ｃ店舗イベント：３位まで賞品獲得可能
Ｄ店舗イベント：４位まで賞品獲得可能
Ｅ店舗イベント：２位まで賞品獲得可能
である。
【０１２４】
したがって、「Ｄ店舗イベント」が、有利な条件のイベントとして抽出される。
【０１２５】
（趣味情報を用いる方法）
趣味情報を用いて有利な条件のイベントを抽出する方法について説明する。以下においては、上述した「その１」の方法に適用した例を説明するが、「その２」及び「その３」の方法についても適用可能である。
【０１２６】
図１５の例では、ユーザの趣味は「スポーツ」である。上述したとおり、「その１」の方法においては、「Ｂ店舗イベント」、「Ｃ店舗イベント」、「Ｄ店舗イベント」が、有利な条件のイベントとして抽出されていた。
ここで、図１５においては、
Ｂ店舗イベントの趣味情報：スポーツ
Ｃ店舗イベントの趣味情報：読書
Ｄ店舗イベントの趣味情報：音楽
である。
【０１２７】
したがって、「Ｂ店舗イベント」のみが、有利な条件のイベントとして抽出される。これにより、ユーザの趣味情報に基いてイベントを抽出するので、ユーザの趣味を反映して他のイベントに関する情報を提示することができる。
【０１２８】
（抽出したイベントの関連情報の表示レイアウト）
図１６は、不図示のディスプレイ及びリモコン１０１の表示部１１６上での表示レイアウトの一例を示している。図１６に示すように、参加確定したイベントの関連情報と抽出されたイベントの関連情報とが、同じ画面に表示されている。これにより、ユーザは、参加済みのイベントと、他のイベントとを容易に比較することができ、他のイベントの内容を直感的に把握することができる。
【０１２９】
以上説明した本発明の第１実施形態によれば、イベントに対する参加確定指示を受け付けたあとで他のイベント情報を提示するので、イベントを企画する者（自店舗）にとっては、ユーザが自イベントに参加することなく他イベントへ参加変更することを防止することができる。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他店舗にとっては、イベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。これによって、カラオケコンクールへの参加機会が高まり、カラオケコンクールをビジネスモデルとして成功させることができる。
【０１３０】
［第２実施形態］
次に、本発明の一実施形態である第２実施形態について説明する。
上述した第１実施形態においては、ＩＰアドレスデータベース２０４を参照して、他店舗のＩＰアドレスを特定していた。以下に説明する第２実施形態においては、ＩＰアドレスデータベースを有さず、通信網によって接続される検索サーバを用いて他店舗のＩＰアドレスを特定する。
【０１３１】
図１７は、第２実施形態におけるカラオケシステムのネットワーク構成を示した図である。基本的な構成は上述した第１実施形態と同じであるが、店舗サーバ２００は、ＩＰアドレスデータベースを有していない。また、店舗サーバ２００は、通信網を介して、検索サーバ４００に接続することができる。
【０１３２】
また、本実施形態においては、それぞれのカラオケ店舗は、ＷｅｂＰａｇｅを有している。ＷｅｂＰａｇｅには、図示しない所定のＷｅｂサーバに記憶されているものとする。また、ＷｅｂＰａｇｅには、「チェーン店であることを示す情報」、「イベントが開催中であることを示す情報」、「イベントの課題曲を示す情報」、「その店舗のＩＰアドレスを特定する情報」がＨＴＭＬ文書として記載されているものとする。
【０１３３】
（店舗サーバでの他店舗イベント検索処理）
次に、第２実施形態における、店舗サーバ２００での他店舗イベント検索処理（図８の（１１））について説明する。図１８は、店舗サーバ２００での他店舗イベントの検索において、検索サーバ及び他店舗の店舗サーバとの間で送受信される情報を説明する。図１８においては、１つの他店舗の店舗サーバとの間で送受信される情報について説明するが、本発明は、情報を送受信する他店舗の数は限定されない。
【０１３４】
検索サーバ４００は、いわゆるサーチエンジンであり、例えば、ロボット検索を行ない、データベースにＷｅｂＰａｇｅの内容を保存する。
【０１３５】
自店舗の店舗サーバ２００は、コマンダ１０２から選択情報を受信し（８）、順位表情報を送信した（９）あと、検索サーバ４００に対し、キーワード信号を送信する（Ｈ）。キーワード信号には、上記（８）の選択情報に含まれる課題曲の楽曲ＩＤ、チェーン店名がキーワードとして含まれる。
【０１３６】
検索サーバ４００は、キーワード信号を受信すると、該キーワード信号に含まれるキーワードを用いてＷｅｂＰａｇｅの検索を行なう（Ｉ）。
検索サーバ４００は、ＷｅｂＰａｇｅの検索結果を店舗サーバ２００に送信する（Ｊ）。検索結果には、上述した「チェーン店であることを示す情報」、「イベントが開催中であることを示す情報」、「イベントの課題曲を示す情報」、「その店舗の電話番号」が含まれる。
【０１３７】
店舗サーバ２００は、受信した検索結果に基いて、ＩＰアドレスを特定する（Ｋ）。受信した「その店舗のＩＰアドレスを特定する情報」が、ＩＰアドレス自体であれば、該ＩＰアドレスが他店舗のＩＰアドレスとなる。また、「その店舗のＩＰアドレスを特定する情報」が、ＩＰ電話番号が含まれた情報であれば、所定のサーバ等を用いて、ＩＰアドレスに変換する（例えば、インターネット上に設置されたＳＩＰサーバを介してＩＰアドレスを取得したり、予め店舗サーバ、検索サーバなどに記憶されたＩＰ電話番号とＩＰアドレスとの対応表からＩＰアドレスを取得したりする。）。
【０１３８】
また、その店舗のＩＰアドレスを特定する情報が、検索サーバで一般利用者から検索可能に公開されると、ネットワーク・セキュリティ面から好ましくない場合は、前記特定する情報を予め暗号化し、キーワード信号が検索可能な情報と対応付けてＷｅｂｐａｇｅに記述すればよい。
つまり、各店の店舗サーバ２００には暗号化手段と復号化手段とが組み込まれ、その店舗のＩＰアドレスを特定する情報を、前記暗号化手段によって、暗号化してからキーワード信号と対応付け、また、受信した検索結果を復号手段で復号してからＩＰアドレスを特定する情報を抽出する。
【０１３９】
例えば、Ａ社による複数のカラオケ店舗を有するカラオケチェーンがあり、チェーン店の中には堀田店があるとする。また、堀田店の店舗サーバ２００のＩＰアドレスを１２３．＊＊＊．＊＊＊．７８９とする。また、堀田店の店舗サーバ２００は各店舗からのキーワード信号「Ａ社」、「カラオケチェーン」、「堀田店」によって検索サーバから堀田店の店舗サーバのＩＰアドレスを抽出可能にするために、堀田店の店舗サーバのＷｅｂｐａｇｅは「Ａ社・カラオケチェーン・堀田店」と店舗のＩＰアドレスを特定する情報とを含むｗｅｂｐａｇｅから構成されている。
【０１４０】
この場合、暗号化手段が、ＩＰアドレスを含む情報「１２３．＊＊＊．＊＊＊．７８９」を「別のテキスト」（例えば、「９８７．＃＃＃．＃＃＃．３２１」、「ＡＣＥＧＸＹＺ」等）に暗号化すれば、前記ＷｅｂｐａｐｅのＩＰアドレスを特定する情報は、前記「別のテキスト」となる。そして、自店舗の店舗サーバ２００が前記キーワード信号によって、堀田店のＩＰアドレスを特定する「別のテキスト」を検索抽出し、復号化手段に、当該「別のテキスト」を入力すれば、「１２３．＊＊＊．＊＊＊．７８９」と復号するので、自店舗の店舗サーバ２００は、堀田店のＩＰアドレスを特定することができる。
【０１４１】
これにより、暗号化、復号化手順を知らなければ、検索サーバの利用者はＡ社の各店舗名を検索抽出できても、そこから各店舗サーバのＩＰアドレスを特定することができない ので、ネットワーク・セキュリティを向上させることができる。
【０１４２】
店舗サーバ２００は、特定したＩＰアドレスに対し、上記（８）で受信した課題曲を含むイベントを行っているか否かについて問い合わせるための問い合わせ信号を送信する（Ｌ）。該問い合わせ信号には、該課題曲の楽曲ＩＤが含まれる。
【０１４３】
他店舗の店舗サーバ２００は、上記問い合わせ信号を受信すると、該問い合わせ信号に含まれる課題曲と同じ課題曲を有する参加可能なイベントが存在するか否かを検索する（Ｍ）。このとき、他店舗の店舗サーバ２００が有するイベント情報データベース２０２が用いられる。
【０１４４】
他店舗の店舗サーバ２００は、同じ課題曲を有する参加可能なイベント（自店舗側を基準とした場合の他店舗イベント）が存在する場合は、該イベントのイベント関連情報を回答信号として送信する（Ｎ）。また、存在しない場合は、その旨を示す回答信号を送信する。
【０１４５】
自店舗の店舗サーバ２００は、他店舗から受信した情報を統合し、コマンダ１０２に対し、検索結果を送信する（１２）。
【０１４６】
図１８における処理では、問い合わせ信号に課題曲ＩＤが含まれ、他店舗の店舗サーバ２００において、課題曲が一致するイベントを抽出しているが、本発明は別の形態としても実現可能である。例えば、問い合わせ信号に課題曲ＩＤを含ませず、他店舗の店舗サーバ２００は、参加可能なイベントを全て自店舗の店舗サーバ２００に送信し、自店舗の店舗サーバ２００において課題曲が一致するイベントを抽出するように構成してもよい。
【０１４７】
また、図１８における処理では、それぞれの他店舗に順に問い合わせを行ったが、マルチキャスト通信を用いて、上記問い合わせ信号を複数の他店舗に一斉に送っても良い。
【０１４８】
次に、第２実施形態における、店舗サーバの処理について説明する。図１９は、店舗サーバ側の処理のフローチャートである。図１９のフローチャートに示される処理は、所定のタイミングごとに繰り返し実行される。また、図１９に示すフローチャートに示される処理は、上述した図１８における「自店舗における処理」と「他店舗における処理」が含まれる。
【０１４９】
Ｓ７１〜Ｓ７４、Ｓ７６〜Ｓ８０の処理は、上述した第１実施形態の店舗サーバ側の処理のＳ３１〜Ｓ３４、Ｓ３６〜Ｓ４０（図１１参照）と同じであるので、説明を省略する。
Ｓ７５において、第２イベント検索処理を実行する。
図２０は、第２イベント検索処理のフローチャートである。
Ｓ９１において、キーワード信号を生成する。上述したとおり、キーワード信号には、上記図１８の（８）の選択情報に含まれる課題曲の楽曲ＩＤ、チェーン店名がキーワードとして含まれる。
【０１５０】
Ｓ９２において、Ｓ９１で生成したキーワード信号を、検索サーバ４００に送信する。
Ｓ９３において、検索サーバ４００から検索結果を受信する。
Ｓ９４において、受信した検索結果に基いて、ＩＰアドレスを特定する。
Ｓ９５〜Ｓ９７の処理は、上述した第１実施形態のイベント検索処理（図１３参照）のＳ５２〜Ｓ５４と同じであるので、説明を省略する。
【０１５１】
以上説明した本発明の第２実施形態によれば、イベントへの参加確定指示を受け付けたあとで他のイベント情報を提示するので、イベントを企画する者（自店舗）にとっては、ユーザが自イベントに参加することなく他イベントへの参加変更することを防止することができる。また、課題曲の歌唱のための指示とイベント参加確定のための指示を別々に行う必要がない。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他店舗にとっては、イベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。これによって、カラオケコンクールへの参加機会が高まり、カラオケコンクールをビジネスモデルとして成功させることができる。また、他店舗のＩＰアドレスを有しておく必要はなく、検索サーバを有効に用いることで該ＩＰアドレスを特定することができる。
【０１５２】
［その他の実施形態］
上述した第１実施形態及び第２実施形態は、課題曲の歌唱のための指示とイベント参加確定のための指示を別々に行う構成であった。本実施形態では、課題曲の歌唱のための指示がイベント参加確定のための指示を兼ねるように構成している。
図２１は、本実施形態における、リモコン１０１、コマンダ１０２、店舗サーバ２００との間で送受信される情報の一例を示した図である。
【０１５３】
図２１の（１）〜（１３）の処理は、図８の（１）〜（１３）の処理と基本的に同じであるが、（７）でリモコン１０１からコマンダ１０２に送信される選択情報には、イベントへの参加確定信号が含まれている。これにより、歌唱後に、イベントへの参加確定指示を受け付けるための処理を行う必要がない。
【０１５４】
したがって、（１３）で有利な条件のイベントを抽出したあと、（１４）で該抽出したイベントを表示することができる。
また、コマンダ１０２は、店舗サーバ２００に対し、採点結果を送信する（１５）。
店舗サーバ２００は、採点結果を受信すると、順位表データベース２０３に登録する（１９）。これにより、順位表データベース２０３は更新されることになる。
【０１５５】
（課金方法）
上述した各実施形態において、イベントに参加するためには、所定量の参加費が必要とする構成を採用することができる。このとき、該参加費を徴収するための課金処理が必要である。本発明においては、カラオケコンクール（イベント）に係る課金方法はどのようなものでもよい。
【０１５６】
例えば、参加するイベントを選択する時点（例えば、図８の（６）の時点）で課金することができる。また、参加するイベントを確定した時点（例えば、図８の（１５）の時点）で課金することができる。また、歌唱者情報データベース３０３に、歌唱者ごとの徴収予定金額属性を設け、所定の期間単位（例えば、１ヶ月）ごとに徴収するよう構成してもよい。この場合は、参加するイベントを選択した時点、または、参加するイベントを確定した時点ごとに、歌唱者情報データベース３０３の徴収予定金額属性の内容が更新されることになる。また、料金の支払いは、ＩＣカード（電子マネー）を用いてもよく、クレジット決済、コンビニ決済としてもよい。また、カラオケボックスの清算時に、徴収するよう構成してもよい。
【０１５７】
上述したとおり、本発明によれば、イベントへの参加確定指示を受け付けたあとで他のイベント情報を提示するので、イベントを企画する者（自店舗）にとっては、ユーザが自イベントに参加することなく他イベントへの参加変更することを防止することができる。また、ユーザにとっては、好条件な他のイベント情報を取得することができる。また、他のイベントを企画する他店舗にとっては、イベントへの広告効果が高まり、集客力を向上させることができる。また、カラオケ事業をチェーン展開する者においては、チェーン店における種々のイベントを効率良くユーザに提示することができる。これによって、カラオケコンクールへの参加機会が高まり、カラオケコンクールをビジネスモデルとして成功させることができる。
【０１５８】
本発明は上述した実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の改良、変形が可能であることはいうまでもない。
【０１５９】
また、上述した各フローチャートは単なる一例であり、該各フローチャートの処理と同等の結果を得ることできるものであれば、他のフローチャートによって処理を実現してもよい。
【０１６０】
また、上述したカラオケコンクールシステムにおけるリモコン、コマンダ、カラオケコンクールシステムに係る方法、該方法をコンピュータに実行させるためのプログラム、該プログラムを記録した記録媒体等としても本発明は実現可能である。
【図面の簡単な説明】
【０１６１】
【図１】カラオケシステムの構成の一例を示した図である。
【図２】楽曲データベースのデータ構造の一例を示した図である。
【図３】歌唱者情報データベースのデータ構造の一例を示した図である。
【図４】イベント情報データベースのデータ構造の一例を示した図である。
【図５】賞品属性のデータ構造の一例を示した図である。
【図６】順位表データベースのデータ構造の一例を示した図である。
【図７】カラオケ装置（リモコン及びコマンダ）の構成の一例を示した図である。
【図８】リモコン、コマンダ、店舗サーバの間で送受信される情報の一例を示した図である。
【図９】店舗サーバ間で送受信される情報の一例を示した図である。
【図１０】リモコン側処理のフローチャートの一例である。
【図１１】コマンダ側処理のフローチャートの一例である。
【図１２】店舗サーバ側処理のフローチャートの一例である。
【図１３】イベント検索処理のフローチャートである。
【図１４】回答信号送信処理のフローチャートである。
【図１５】各店舗のイベントの例を示した図である。
【図１６】表示レイアウトの一例である。
【図１７】カラオケシステムの構成の一例を示した図である。
【図１８】自店舗の店舗サーバ、検索サーバ、他店舗の検索サーバの間で送受信される情報の一例を示した図である。
【図１９】店舗サーバ側処理のフローチャートの一例である。
【図２０】第２イベント検索処理のフローチャートである。
【図２１】リモコン、コマンダ、店舗サーバの間で送受信される情報の一例を示した図である。
【符号の説明】
【０１６２】
１００ カラオケ装置
１０１ リモコン
１０２ コマンダ
２００ 店舗サーバ
２０１ コントローラ
２０２ イベント情報データベース
２０３ 順位表データベース
２０４ ＩＰアドレスデータベース
３００ 管理サーバ
３０１ コントローラ
３０２ 楽曲データベース
３０３ 歌唱者情報データベース
４００ 検索サーバ
【特許請求の範囲】
【請求項１】
複数のカラオケ店舗間で通信可能であり、それぞれのカラオケ店舗間において独自にイベントが実施可能なカラオケコンクールシステムにおいて、
それぞれのカラオケ店舗には、店舗サーバとカラオケ装置が設置され、
前記店舗サーバは、イベント情報データベースと、順位表データベースと、サーバ制御手段を備え、
（ａ）前記イベント情報データベースは、自店舗で実施されるイベントごとに、課題曲として歌唱可能な楽曲の楽曲ＩＤを、イベントＩＤ・企画者・実施期間・授賞要項の組を含むイベント関連情報に対応付けて格納し、
（ｂ）前記順位表データベースは、前記イベント情報ごとに、歌唱者ＩＤと採点データとの組の集合を順位表として格納し、
（ｃ）前記サーバ制御手段は、前記カラオケ装置からイベントＩＤ・歌唱者ＩＤ・採点データの組を受信した際、該当の順位表を更新し、
（ｄ）前記サーバ制御手段は、前記イベント情報データベース中のあるイベントの実施期間が満了した際、そのイベントの授賞要項と順位表と歌唱者情報データベースに基づいて受賞者を決定し、
前記カラオケ装置は、ユーザインタフェースと、演奏手段と、採点手段と、カラオケ制御手段を備え、
（ｅ）前記ユーザインタフェースは、前記カラオケ制御手段の制御に従い利用者に情報を提示するとともに利用者入力を受け付け、
（ｆ）前記演奏手段は、前記カラオケ制御手段の制御に従い指定されたカラオケ楽曲の伴奏音楽を音響出力し、
（ｇ）採点手段は、前記カラオケ制御手段の制御に従い伴奏音楽に合わせて歌唱する歌声の巧拙を評価して採点データを出力し、
（ｈ）前記カラオケ制御手段は、
（ｈ−１）イベント閲覧要求の利用者入力があった際に当該要求の電文を自店舗の店舗サーバに送信し、
（ｈ−２）自店舗の店舗サーバから受信したイベント情報データベースと順位表データベースの内容を記憶し、イベントに関する情報を利用者に提示させ、
（ｈ−３）ユーザインタフェースによって利用者が選択したイベントＩＤ・楽曲ＩＤとこれに対応付けられた歌唱者ＩＤを取得し、
（ｈ−４）取得した楽曲ＩＤの伴奏音楽の演奏に先立ち、取得したイベントＩＤを自店舗の店舗サーバに送信し、
（ｈ−５）当該イベントの順位表を自店舗の店舗サーバより受信し、
（ｈ−６）取得した楽曲ＩＤの伴奏音楽を前記演奏手段に演奏させ、
（ｈ−７）演奏中に歌声を採点させるとともに、採点データを受信した順位表を参照して順位を求め、少なくとも歌唱区間の終了時に求めた順位を表示させ、
（ｈ−８）出力された採点データと、イベントＩＤ・歌唱者ＩＤを対応付けして自店舗の店舗サーバに送信させる、
ものであって、
自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、他店舗のサーバ制御手段のＩＰアドレスを検索し、
自店舗のサーバ制御手段は、検索したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせ、
他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、
他店舗のサーバ制御手段は、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信し、
自店舗のサーバ制御手段は、受信したイベント情報を、前記カラオケ装置に送信し、
前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する、
ことを特徴とするカラオケコンクールシステム。
【請求項２】
複数のカラオケ店舗間で通信可能であり、それぞれのカラオケ店舗間において独自にイベントが実施可能なカラオケコンクールシステムにおいて、
それぞれのカラオケ店舗には、店舗サーバとカラオケ装置が設置され、
前記店舗サーバは、イベント情報データベースと、順位表データベースと、サーバ制御手段を備え、
（ａ）前記イベント情報データベースは、自店舗で実施されるイベントごとに、課題曲として歌唱可能な楽曲の楽曲ＩＤを、イベントＩＤ・企画者・実施期間・授賞要項の組を含むイベント関連情報に対応付けて格納し、
（ｂ）前記順位表データベースは、前記イベント情報ごとに、歌唱者ＩＤと採点データとの組の集合を順位表として格納し、
（ｃ）前記サーバ制御手段は、前記カラオケ装置からイベントＩＤ・歌唱者ＩＤ・採点データの組を受信した際、該当の順位表を更新し、
（ｄ）前記サーバ制御手段は、前記イベント情報データベース中のあるイベントの実施期間が満了した際、そのイベントの授賞要項と順位表と歌唱者情報データベースに基づいて受賞者を決定し、
前記カラオケ装置は、ユーザインタフェースと、演奏手段と、採点手段と、カラオケ制御手段を備え、
（ｅ）前記ユーザインタフェースは、前記カラオケ制御手段の制御に従い利用者に情報を提示するとともに利用者入力を受け付け、
（ｆ）前記演奏手段は、前記カラオケ制御手段の制御に従い指定されたカラオケ楽曲の伴奏音楽を音響出力し、
（ｇ）採点手段は、前記カラオケ制御手段の制御に従い伴奏音楽に合わせて歌唱する歌声の巧拙を評価して採点データを出力し、
（ｈ）前記カラオケ制御手段は、
（ｈ−１）イベント閲覧要求の利用者入力があった際に当該要求の電文を自店舗の店舗サーバに送信し、
（ｈ−２）自店舗の店舗サーバから受信したイベント情報データベースと順位表データベースの内容を記憶し、イベントに関する情報を利用者に提示させ、
（ｈ−３）ユーザインタフェースによって利用者が選択したイベントＩＤ・楽曲ＩＤとこれに対応付けられた歌唱者ＩＤを取得し、
（ｈ−４）取得した楽曲ＩＤの伴奏音楽の演奏に先立ち、取得したイベントＩＤを自店舗の店舗サーバに送信し、
（ｈ−５）当該イベントの順位表を自店舗の店舗サーバより受信し、
（ｈ−６）取得した楽曲ＩＤの伴奏音楽を前記演奏手段に演奏させ、
（ｈ−７）演奏中に歌声を採点させるとともに、採点データを受信した順位表を参照して順位を求め、少なくとも歌唱区間の終了時に求めた順位を表示させ、
（ｈ−８）出力された採点データと、イベントＩＤ・歌唱者ＩＤを対応付けして自店舗の店舗サーバに送信させる、
ものであって、
自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、通信網を介して接続された検索サーバを用いて、前記受信したイベントＩＤに対応付けられている楽曲ＩＤ及びカラオケ店舗の属性情報をキーワードとして検索し、
自店舗のサーバ制御手段は、他店舗のサーバ制御手段のＩＰアドレスを特定する情報を含む検索結果を取得し、
自店舗のサーバ制御手段は、取得した検索結果に基き、他店舗の店舗サーバのＩＰアドレスを特定し、
自店舗のサーバ制御手段は、特定したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせ、
他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、
他店舗のサーバ制御手段は、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信し、
自店舗のサーバ制御手段は、受信したイベント情報を、前記カラオケ装置に送信し、
前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する、
ことを特徴とするカラオケコンクールシステム。
【請求項３】
前記サーバ制御手段は、ＮＧＮ通信網を介して楽曲データベースと通信可能であり、
前記楽曲データベースとの通信に用いるプロトコルはＰＰＰｏＥであり、前記他店舗の店舗サーバとの通信に用いるプロトコルはＳＩＰである、
ことを特徴とする請求項１または２のカラオケコンクールシステム。
【請求項４】
前記ＩＰアドレスを特定する情報は暗号化されており、
前記自店舗のサーバ制御手段は、前記取得した検索結果から前記ＩＰアドレスを特定する情報を抽出し、前記ＩＰアドレス特定する情報を復号化することにより、他店舗の店舗サーバのＩＰアドレスを特定する、
ことを特徴とする請求項２のカラオケコンクールシステム。
【請求項５】
請求項１乃至請求項４いずれかのカラオケコンクールシステムにおいて、
前記有利な条件とは、
（１）同一順位の賞品金額を比較したときに、前記参加確定されたイベント順位の賞品よりも高い金額である、
（２）もしくは、前記参加確定されたイベントの賞品総額よりも高い賞品総額である、
（３）もしくは、前記参加確定されたイベントよりも低い順位で賞品が存在する、
ことを特徴とするカラオケコンクールシステム。
【請求項１】
複数のカラオケ店舗間で通信可能であり、それぞれのカラオケ店舗間において独自にイベントが実施可能なカラオケコンクールシステムにおいて、
それぞれのカラオケ店舗には、店舗サーバとカラオケ装置が設置され、
前記店舗サーバは、イベント情報データベースと、順位表データベースと、サーバ制御手段を備え、
（ａ）前記イベント情報データベースは、自店舗で実施されるイベントごとに、課題曲として歌唱可能な楽曲の楽曲ＩＤを、イベントＩＤ・企画者・実施期間・授賞要項の組を含むイベント関連情報に対応付けて格納し、
（ｂ）前記順位表データベースは、前記イベント情報ごとに、歌唱者ＩＤと採点データとの組の集合を順位表として格納し、
（ｃ）前記サーバ制御手段は、前記カラオケ装置からイベントＩＤ・歌唱者ＩＤ・採点データの組を受信した際、該当の順位表を更新し、
（ｄ）前記サーバ制御手段は、前記イベント情報データベース中のあるイベントの実施期間が満了した際、そのイベントの授賞要項と順位表と歌唱者情報データベースに基づいて受賞者を決定し、
前記カラオケ装置は、ユーザインタフェースと、演奏手段と、採点手段と、カラオケ制御手段を備え、
（ｅ）前記ユーザインタフェースは、前記カラオケ制御手段の制御に従い利用者に情報を提示するとともに利用者入力を受け付け、
（ｆ）前記演奏手段は、前記カラオケ制御手段の制御に従い指定されたカラオケ楽曲の伴奏音楽を音響出力し、
（ｇ）採点手段は、前記カラオケ制御手段の制御に従い伴奏音楽に合わせて歌唱する歌声の巧拙を評価して採点データを出力し、
（ｈ）前記カラオケ制御手段は、
（ｈ−１）イベント閲覧要求の利用者入力があった際に当該要求の電文を自店舗の店舗サーバに送信し、
（ｈ−２）自店舗の店舗サーバから受信したイベント情報データベースと順位表データベースの内容を記憶し、イベントに関する情報を利用者に提示させ、
（ｈ−３）ユーザインタフェースによって利用者が選択したイベントＩＤ・楽曲ＩＤとこれに対応付けられた歌唱者ＩＤを取得し、
（ｈ−４）取得した楽曲ＩＤの伴奏音楽の演奏に先立ち、取得したイベントＩＤを自店舗の店舗サーバに送信し、
（ｈ−５）当該イベントの順位表を自店舗の店舗サーバより受信し、
（ｈ−６）取得した楽曲ＩＤの伴奏音楽を前記演奏手段に演奏させ、
（ｈ−７）演奏中に歌声を採点させるとともに、採点データを受信した順位表を参照して順位を求め、少なくとも歌唱区間の終了時に求めた順位を表示させ、
（ｈ−８）出力された採点データと、イベントＩＤ・歌唱者ＩＤを対応付けして自店舗の店舗サーバに送信させる、
ものであって、
自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、他店舗のサーバ制御手段のＩＰアドレスを検索し、
自店舗のサーバ制御手段は、検索したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせ、
他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、
他店舗のサーバ制御手段は、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信し、
自店舗のサーバ制御手段は、受信したイベント情報を、前記カラオケ装置に送信し、
前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する、
ことを特徴とするカラオケコンクールシステム。
【請求項２】
複数のカラオケ店舗間で通信可能であり、それぞれのカラオケ店舗間において独自にイベントが実施可能なカラオケコンクールシステムにおいて、
それぞれのカラオケ店舗には、店舗サーバとカラオケ装置が設置され、
前記店舗サーバは、イベント情報データベースと、順位表データベースと、サーバ制御手段を備え、
（ａ）前記イベント情報データベースは、自店舗で実施されるイベントごとに、課題曲として歌唱可能な楽曲の楽曲ＩＤを、イベントＩＤ・企画者・実施期間・授賞要項の組を含むイベント関連情報に対応付けて格納し、
（ｂ）前記順位表データベースは、前記イベント情報ごとに、歌唱者ＩＤと採点データとの組の集合を順位表として格納し、
（ｃ）前記サーバ制御手段は、前記カラオケ装置からイベントＩＤ・歌唱者ＩＤ・採点データの組を受信した際、該当の順位表を更新し、
（ｄ）前記サーバ制御手段は、前記イベント情報データベース中のあるイベントの実施期間が満了した際、そのイベントの授賞要項と順位表と歌唱者情報データベースに基づいて受賞者を決定し、
前記カラオケ装置は、ユーザインタフェースと、演奏手段と、採点手段と、カラオケ制御手段を備え、
（ｅ）前記ユーザインタフェースは、前記カラオケ制御手段の制御に従い利用者に情報を提示するとともに利用者入力を受け付け、
（ｆ）前記演奏手段は、前記カラオケ制御手段の制御に従い指定されたカラオケ楽曲の伴奏音楽を音響出力し、
（ｇ）採点手段は、前記カラオケ制御手段の制御に従い伴奏音楽に合わせて歌唱する歌声の巧拙を評価して採点データを出力し、
（ｈ）前記カラオケ制御手段は、
（ｈ−１）イベント閲覧要求の利用者入力があった際に当該要求の電文を自店舗の店舗サーバに送信し、
（ｈ−２）自店舗の店舗サーバから受信したイベント情報データベースと順位表データベースの内容を記憶し、イベントに関する情報を利用者に提示させ、
（ｈ−３）ユーザインタフェースによって利用者が選択したイベントＩＤ・楽曲ＩＤとこれに対応付けられた歌唱者ＩＤを取得し、
（ｈ−４）取得した楽曲ＩＤの伴奏音楽の演奏に先立ち、取得したイベントＩＤを自店舗の店舗サーバに送信し、
（ｈ−５）当該イベントの順位表を自店舗の店舗サーバより受信し、
（ｈ−６）取得した楽曲ＩＤの伴奏音楽を前記演奏手段に演奏させ、
（ｈ−７）演奏中に歌声を採点させるとともに、採点データを受信した順位表を参照して順位を求め、少なくとも歌唱区間の終了時に求めた順位を表示させ、
（ｈ−８）出力された採点データと、イベントＩＤ・歌唱者ＩＤを対応付けして自店舗の店舗サーバに送信させる、
ものであって、
自店舗のサーバ制御手段は、前記カラオケ制御手段よりイベントＩＤを受信したときに、通信網を介して接続された検索サーバを用いて、前記受信したイベントＩＤに対応付けられている楽曲ＩＤ及びカラオケ店舗の属性情報をキーワードとして検索し、
自店舗のサーバ制御手段は、他店舗のサーバ制御手段のＩＰアドレスを特定する情報を含む検索結果を取得し、
自店舗のサーバ制御手段は、取得した検索結果に基き、他店舗の店舗サーバのＩＰアドレスを特定し、
自店舗のサーバ制御手段は、特定したＩＰアドレスに対し、前記受信したイベントＩＤに対応付けられている楽曲ＩＤを含む他のイベントが存在するかについて問い合わせ、
他店舗のサーバ制御手段は、前記問い合わせを受信したときに、該問い合わせに含まれる楽曲ＩＤを含む他のイベントが、該他店舗のイベント情報データベースに存在するか否かを検索し、
他店舗のサーバ制御手段は、他のイベントが存在する場合に、該イベントのイベント関連情報を、自店舗のサーバ制御手段に送信し、
自店舗のサーバ制御手段は、受信したイベント情報を、前記カラオケ装置に送信し、
前記カラオケ制御手段は、イベント参加確定の指示を受け付けた後に、前記他のイベントのうち、前記参加確定されたイベントよりもユーザによって有利な条件のイベントを抽出し、該抽出したイベントのイベント関連情報を提示する、
ことを特徴とするカラオケコンクールシステム。
【請求項３】
前記サーバ制御手段は、ＮＧＮ通信網を介して楽曲データベースと通信可能であり、
前記楽曲データベースとの通信に用いるプロトコルはＰＰＰｏＥであり、前記他店舗の店舗サーバとの通信に用いるプロトコルはＳＩＰである、
ことを特徴とする請求項１または２のカラオケコンクールシステム。
【請求項４】
前記ＩＰアドレスを特定する情報は暗号化されており、
前記自店舗のサーバ制御手段は、前記取得した検索結果から前記ＩＰアドレスを特定する情報を抽出し、前記ＩＰアドレス特定する情報を復号化することにより、他店舗の店舗サーバのＩＰアドレスを特定する、
ことを特徴とする請求項２のカラオケコンクールシステム。
【請求項５】
請求項１乃至請求項４いずれかのカラオケコンクールシステムにおいて、
前記有利な条件とは、
（１）同一順位の賞品金額を比較したときに、前記参加確定されたイベント順位の賞品よりも高い金額である、
（２）もしくは、前記参加確定されたイベントの賞品総額よりも高い賞品総額である、
（３）もしくは、前記参加確定されたイベントよりも低い順位で賞品が存在する、
ことを特徴とするカラオケコンクールシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２００９−２６５４５６（Ｐ２００９−２６５４５６Ａ）
【公開日】平成２１年１１月１２日（２００９．１１．１２）
【国際特許分類】
【出願番号】特願２００８−１１６６０３（Ｐ２００８−１１６６０３）
【出願日】平成２０年４月２８日（２００８．４．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＴＨＥＲＮＥＴ
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
【公開日】平成２１年１１月１２日（２００９．１１．１２）
【国際特許分類】
【出願日】平成２０年４月２８日（２００８．４．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＴＨＥＲＮＥＴ
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
[ Back to top ]