(57)【要約】【課題】応募者がデュエット通信中に予想される歌唱映像の表示態様の推移を参照して募集者を選択決定する。【解決手段】募集側のカラオケ装置４から、映像モードとの設定を含む募集申請情報をサーバ２に登録する募集手続き処理と、応募側のカラオケ装置４から、楽曲のメロディブロック単位での映像モードとを設定してサーバ２に登録されている同じ楽曲の募集申請情報を閲覧する応募手続き処理と、応募側カラオケ装置４と募集側カラオケ装置４との間のネットワークＮＷ上における時系列トラフィック推移をメロディブロック単位で推定する処理と、時系列トラフィック推移に基づいて映像モードの実行可能性を示すモード実行確度をメロディブロック単位で応募側カラオケ装置４に一覧表示する処理と、応募側カラオケ装置において相手の募集側カラオケ装置４を決定する処理と、を有する。【選択図】図１０
2015143762.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して相互に情報送受可能なサーバ及び複数のカラオケ装置を有し、デュエット通信を実行させる２つのカラオケ装置の組合せを決定するカラオケシステムであって、
募集側のカラオケ装置から、デュエット通信する対象の楽曲と、デュエット通信中における相互の歌唱中映像の表示態様である映像モードとの設定を含む募集申請情報を前記サーバに登録する募集手続手段と、
応募側のカラオケ装置から、デュエット通信する対象の楽曲と、この楽曲のメロディブロック単位での映像モードとを設定して前記サーバに登録されている同じ楽曲の募集申請情報を閲覧する第１応募手続手段と、
前記応募側カラオケ装置と、前記第１応募手続手段で閲覧する募集申請情報に対応する募集側カラオケ装置との間の前記ネットワーク上における時系列トラフィック推移をメロディブロック単位で推定するトラフィック推定手段と、
前記第１応募手続手段で閲覧する募集申請情報について、前記募集手続手段で設定した映像モードと前記時系列トラフィック推移とに基づいて、前記第１応募手続手段で設定した映像モードの実行可能性を示すモード実行確度をメロディブロック単位で前記応募側カラオケ装置に一覧表示する第１確度表示手段と、
前記応募側カラオケ装置においてデュエット通信する相手の募集側カラオケ装置を決定する第１相手装置決定手段と、
を有することを特徴とするカラオケシステム。
【請求項２】
ネットワークを介してサーバ及び複数の募集側のカラオケ装置と相互に情報送受可能であり、デュエット通信する相手のカラオケ装置を決定する応募側のカラオケ装置であって、
デュエット通信する対象の楽曲と、この楽曲のメロディブロック単位でデュエット通信中における相互の歌唱中映像の表示態様である映像モードとを設定し、募集側カラオケ装置から前記サーバに登録されている同じ楽曲の募集申請情報を閲覧する第２応募手続手段と、
前記第２応募手続手段で閲覧する募集申請情報について、前記募集側カラオケ装置で設定された当該募集申請情報に含まれる映像モードと、前記サーバによりメロディブロック単位で推定された当該応募側カラオケ装置と前記第２応募手続手段で閲覧する募集申請情報に対応する募集側カラオケ装置との間の前記ネットワーク上における時系列トラフィック推移とに基づいて、前記第２応募手続手段で設定した映像モードの実行可能性を示すモード実行確度をメロディブロック単位で一覧表示する第２確度表示手段と、
デュエット通信する相手の募集側カラオケ装置を決定する第２相手装置決定手段と、
を有することを特徴とするカラオケ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して２つのカラオケ装置間でデュエット通信を行うカラオケシステム、及びカラオケ装置に関する。
【背景技術】
【０００２】
例えば、特許文献１に開示されているように、ネットワークを介して相互に情報送受可能な複数のカラオケ装置の間で同じ楽曲を同期して演奏させるとともに、それぞれの歌唱中の音声データと映像データを相互に送受して発音、表示させるデュエット通信の技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−７７４８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
デュエット通信中において双方のユーザが互いに歌唱中の動画をリアルタイムに送受して表示し合う場合、そのデータ伝送量は非常に大きくなる。しかしながら、例えばインターネットなどの広域インフラネットワークを介して映像データを送受する場合には、その伝送に許容可能なデータ量、つまりトラフィックが時々刻々と変化してタイミングによっては映像データを十分に送受できない場合がある。そしてそのトラフィックの状況は、デュエット通信する２つのカラオケ装置の組み合わせによって大きく相違する場合がある。
【０００５】
一方、デュエット通信を実行する２つのカラオケ装置の組み合わせを決定する方式としては、事前にデュエット通信の相手を募集する募集者側からの情報が複数登録されている中から、応募者が任意に選んで決定する方式がある。従来ではこのような応募者による募集者の選択決定時に、相互のトラフィック状況による歌唱映像の表示態様の違いを考慮した募集者の選択を行えないといった不便があった。
【０００６】
本発明の目的は、応募者がデュエット通信中に予想される歌唱映像の表示態様の推移を参照して募集者を選択決定できるカラオケシステム及びカラオケ装置を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するために、第１の発明は、ネットワークを介して相互に情報送受可能なサーバ及び複数のカラオケ装置を有し、デュエット通信を実行させる２つのカラオケ装置の組合せを決定するカラオケシステムであって、募集側のカラオケ装置から、デュエット通信する対象の楽曲と、デュエット通信中における相互の歌唱中映像の表示態様である映像モードとの設定を含む募集申請情報を前記サーバに登録する募集手続手段と、応募側のカラオケ装置から、デュエット通信する対象の楽曲と、この楽曲のメロディブロック単位での映像モードとを設定して前記サーバに登録されている同じ楽曲の募集申請情報を閲覧する第１応募手続手段と、前記応募側カラオケ装置と、前記第１応募手続手段で閲覧する募集申請情報に対応する募集側カラオケ装置との間の前記ネットワーク上における時系列トラフィック推移をメロディブロック単位で推定するトラフィック推定手段と、前記第１応募手続手段で閲覧する募集申請情報について、前記募集手続手段で設定した映像モードと前記時系列トラフィック推移とに基づいて、前記第１応募手続手段で設定した映像モードの実行可能性を示すモード実行確度をメロディブロック単位で前記応募側カラオケ装置に一覧表示する第１確度表示手段と、前記応募側カラオケ装置においてデュエット通信する相手の募集側カラオケ装置を決定する第１相手装置決定手段と、を有することを特徴とする。
【０００８】
本発明は、ネットワークを介して相互に情報送受可能な複数のカラオケ装置のうちデュエット通信を実行させる２つのカラオケ装置の組み合わせを決定する。このデュエット通信では、２つのカラオケ装置の間で同じ楽曲を同期して演奏させるとともに、それぞれの歌唱中の音声データと映像データを相互に送受して発音、表示させる。最初に募集者が利用するカラオケ装置で、歌唱対象の楽曲を設定した募集申請情報をサーバに登録する募集手続きを行う。その後に他の応募者が利用するカラオケ装置で、歌唱対象の楽曲を設定してそれまでにサーバに登録されている同じ楽曲の募集申請情報を閲覧する応募手続きを行う。この応募手続きでは、同じ楽曲の募集申請情報が複数登録されている場合もあり、応募者がいずれかの募集申請情報を選択してデュエット通信を行う相手の募集側カラオケ装置を決定する。
【０００９】
一方、デュエット通信中において双方のユーザが互いに歌唱中の動画をリアルタイムに送受して表示し合う場合、そのデータ伝送量は非常に大きくなる。しかしながら、例えばインターネットなどの広域インフラネットワークを介して映像データを送受する場合には、その伝送に許容可能なデータ量、つまりトラフィックが時々刻々と変化してタイミングによっては映像データを十分に送受できない場合がある。そしてそのトラフィックの状況は、デュエット通信する２つのカラオケ装置の組み合わせによって大きく相違する場合がある。
【００１０】
そこで本発明では、デュエット通信中における相互の歌唱中映像の表示態様を複数段階の映像モードで設定可能とする。例えば、全身の動画映像を送受して表示し合う最もデータ伝送量の高い映像モードの他に、例えばそれぞれの顔だけの動画（もしくは静止画）に加えて他の部分をいわゆるアバターなどの抽象映像に置き換えることでデータ伝送量を抑えた映像モードや、全身をアバターに置き換えて表示し合う最もデータ伝送量の低い映像モードなどを用意する。なお、デュエット通信時には、双方同じ映像モードで表示し合うことを前提とする。
【００１１】
募集者側の募集手続きでは、募集申請情報に楽曲全体を通した映像モードの設定を行う。また応募者側の応募手続きでは、楽曲のメロディブロック単位で映像モードの設定を行い、各募集申請情報の閲覧時に自分で設定した映像モードの実行可能性を示すモード実行確度をメロディブロック単位で一覧表示する。このモード実行確度は、募集手続きで設定した楽曲全体での映像モードと、応募手続きで設定したメロディブロック単位での映像モードとのマッチング、及び、応募側カラオケ装置と、閲覧している募集申請情報に対応する募集側カラオケ装置との間のネットワーク上におけるメロディブロック単位で推定される時系列トラフィック推移、に基づいて特定、表示される。
【００１２】
応募者は、それぞれの募集申請情報を閲覧する際に、対応する募集側カラオケ装置とデュエット通信した場合のモード実行確度をメロディブロック単位で確認することができ、それを参照した上でデュエット通信する募集者を選択決定できる。
【００１３】
このようにして本発明では、応募者に対して希望する歌唱中映像の表示態様の実行可能性に関する情報を募集申請情報ごとにメロディブロック単位で提示することができ、応募者はそれを参照して募集者を選択決定できるといった利便性を提供できる。
【００１４】
また上記目的を達成するために、第２の発明は、ネットワークを介してサーバ及び複数の募集側のカラオケ装置と相互に情報送受可能であり、デュエット通信する相手のカラオケ装置を決定する応募側のカラオケ装置であって、デュエット通信する対象の楽曲と、この楽曲のメロディブロック単位でデュエット通信中における相互の歌唱中映像の表示態様である映像モードとを設定し、募集側カラオケ装置から前記サーバに登録されている同じ楽曲の募集申請情報を閲覧する第２応募手続手段と、前記第２応募手続手段で閲覧する募集申請情報について、前記募集側カラオケ装置で設定された当該募集申請情報に含まれる映像モードと、前記サーバによりメロディブロック単位で推定された当該応募側カラオケ装置と前記第２応募手続手段で閲覧する募集申請情報に対応する募集側カラオケ装置との間の前記ネットワーク上における時系列トラフィック推移とに基づいて、前記第２応募手続手段で設定した映像モードの実行可能性を示すモード実行確度をメロディブロック単位で一覧表示する第２確度表示手段と、デュエット通信する相手の募集側カラオケ装置を決定する第２相手装置決定手段と、を有することを特徴とする。
【発明の効果】
【００１５】
本発明によれば、応募者がデュエット通信中に予想される歌唱映像の表示態様の推移を参照して募集者を選択決定できる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態に係わるカラオケシステムの全体構成を示す図である。
【図２】カラオケ装置の制御系の主要構成を示す機能ブロック図である。
【図３】３つの映像モードの例を示す図である。
【図４】募集側カラオケ装置に表示される募集手続き用画面の一例を示す図である。
【図５】サーバが記憶する募集申請情報データベースを模式的に示す図である。
【図６】応募側カラオケ装置に表示される応募手続き用画面の一例を示す図である。
【図７】メロディブロックの構成例を示す図である。
【図８】応募側カラオケ装置に表示される募集申請情報一覧画面の一例を示す図である。
【図９】希望映像モードの一致度を特定する演算式の一例を示す図である。
【図１０】応募側カラオケ装置に表示される募集申請情報詳細画面の一例を示す図である。
【図１１】サーバが記憶するトラフィック履歴データベースを模式的に示す図である。
【図１２】一方のルータにおける時系列トラフィック推移の第１の例を示す図である。
【図１３】一方のルータにおける時系列トラフィック推移の第２の例を示す図である。
【図１４】デュエット通信の組み合わせを決定する行程で各装置間が送受する情報の詳細をまとめたシーケンスチャートである。
【図１５】サーバのＣＰＵにより実行される処理内容を示すフローチャートである。
【図１６】募集側カラオケ装置のＣＰＵにより実行される処理内容を示すフローチャートである。
【図１７】応募側カラオケ装置のＣＰＵにより実行される処理内容を示すフローチャートである。
【図１８】ルータのＣＰＵにより実行される処理内容を示すフローチャートである。
【発明を実施するための形態】
【００１７】
以下、本発明の一実施の形態について、図面を参照しつつ説明する。
【００１８】
＜カラオケシステムの全体構成＞
本実施形態に係わるカラオケシステムの全体構成を図１に示す。カラオケシステム１は、サーバ２と、店舗などの複数の拠点Ｑ，Ｒにそれぞれ設けられたルータ３と、各拠点Ｑ，Ｒでルータ３に接続する複数のカラオケ装置４とを有している。サーバ２と複数のルータ３はインターネットなどの広域インフラネットワークＮＷを介して情報送受可能に接続されており、各拠点Ｑ，Ｒ内では複数のカラオケ装置４とルータ３がＬＡＮなどの構内ネットワークを介して情報送受可能に接続されている。各カラオケ装置４は少なくともマイク１１と、スピーカ１２と、カメラ１３と、モニタ１４を備えている。なお、図示を簡略化するために２つの拠点Ｑ，Ｒ（２つのルータ３）しか図示していないが、他にも多数の拠点（多数のルータ３）がネットワークＮＷに接続しているとする。また特に図示していないが、各拠点で１つのルータ３に１つのカラオケ装置４が接続してもよい。
【００１９】
図示する例では、拠点Ｑが有するカラオケ装置４Ｂと、拠点Ｒが有するカラオケ装置４Ｆとがデュエット通信を実行している。このデュエット通信では、２つのカラオケ装置４Ｂ，４Ｆの間で同じ楽曲を同期して演奏させるとともに、それぞれの歌唱中の音声データと映像データを相互に送受して相手側に発音、表示させる。このデュエット通信により、各カラオケ装置４Ｂ，４Ｆのユーザ（図中のＸ，Ｙ）は離れた拠点間にいながら、互いの歌唱中の挙動や音声を認識しつつ同じ楽曲を同時にデュエット歌唱（合唱）できる。
【００２０】
＜カラオケ装置の主要構成＞
上記デュエット通信を実現可能なカラオケ装置４の制御系の主要構成を示す機能ブロック図を図２に示す。カラオケ装置４は、本体装置２０と、歌唱者の歌唱音声を入力するマイク１１と、マイク１１から入力される音声信号及び曲の再生信号のミキシングを行うミキシング回路１５を内部に備えたアンプ１６と、このアンプ１６から出力される増幅信号を音として再生するスピーカ１２と、歌詞テロップや後述するデュエット相手映像、もしくは各種の操作画面などをＣＲＴに表示するモニタ１４と、歌唱者を撮影するカメラ１３と、処理要求情報を含む赤外線信号を介して本体装置２０を遠隔操作するリモコン１７とを備えている。
【００２１】
本体装置２０は、その装置筺体２１に、有線ＬＡＮ回線１８を接続する通信端子２２と、アンプ１６を接続する音声入出力端子２３と、モニタ１４を接続する映像出力端子２４と、カメラ１３を接続する映像入力端子２５と、リモコン１７からの赤外線信号を受光する受光部２６と、本体装置２０の作動状態を表示する表示部として機能するＬＥＤ２７と、操作部として機能するテンキーや選曲ボタン等で構成するボタン・キー２８とを備えている。
【００２２】
この本体装置２０には、制御プログラムにしたがって各種制御を実行するＣＰＵ３１が設けられている。ＣＰＵ３１には、リモコン１７から送信される処理要求情報に関するデータなどを一時保存するためのＲＡＭ３２と、ＣＰＵ３１により実行されるプログラム及び必要なデータテーブルなどが記憶されたＲＯＭ３３とが接続されている。また、ＣＰＵ３１には、モニタ１４に歌詞テロップや各種メッセージ映像を表示するための文字映像データが記憶されたビデオＲＡＭ３４と、外部のサーバ２から送信される楽曲データ、歌詞データ、及び映像データなどの各種データをインターネット等のネットワークＮＷ、ルータ３、有線ＬＡＮ回線１８、及び通信端子２２を介して受信するためのネットワーク制御部３５と、このネットワーク制御部３５により受信される楽曲データ及び動画データ等を保存するためのＨＤＤ３６とが接続されている。ＨＤＤ３６には、背景映像を示す背景映像データの他に、後述するアバタ映像データや各種データベースも保存（記憶）されている。
【００２３】
さらに、ＣＰＵ３１には、ＨＤＤ３６から読み出された曲データに含まれるＭＩＤＩデータを入力するとともに、その入力されたＭＩＤＩデータにより指定される音源から音源信号を出力するＭＩＤＩ音源ボード３７が接続されている。また、ＣＰＵ３１には、上記出力された音源信号を入力してアンプ１６により増幅可能な信号に変換する音声制御回路３８が接続されている。また、ＣＰＵ３１には、サーバ２から受信した上記動画データ等を映像出力端子２４を介してモニタ１４に表示するための映像制御を行う映像制御回路３９が接続されている。
【００２４】
さらに、ＣＰＵ３１には、カメラ１３からの撮影信号を入力する入力回路４０と、受光部２６により受光されたリモコン１７からの赤外線信号をデジタル信号に変換する変換回路４１と、装置筺体２１に設けられた上記各種ボタン、キー２８を押したときに点灯するＬＥＤ２７へ表示信号を出力する表示回路４２と、上記各種ボタン、キー２８を押したときに発生するスイッチング信号を入力する入力回路４３とが接続されている。
【００２５】
＜本実施形態の特徴＞
本実施形態のカラオケシステムは、ネットワークＮＷを介して相互に情報送受可能な複数のカラオケ装置４のうちデュエット通信を実行させる２つのカラオケ装置４の組み合わせを決定する行程に特徴がある（後述の図１４も併せて参照）。この行程としては、最初に募集者が利用するカラオケ装置で、歌唱対象の楽曲を設定した募集申請情報をサーバ２に登録する募集手続きを行う。その後に他の応募者が利用するカラオケ装置で、歌唱対象の楽曲を設定してそれまでにサーバ２に登録されている同じ楽曲の募集申請情報を閲覧する応募手続きを行う。この応募手続きでは、同じ楽曲の募集申請情報が複数登録されている場合もあり、応募者がいずれかの募集申請情報を選択してデュエット通信を行う相手の募集側カラオケ装置を決定する。
【００２６】
一方、デュエット通信中において双方のユーザが互いに歌唱中の動画をリアルタイムに送受して表示し合う場合、そのデータ伝送量は非常に大きくなる。しかしながら、例えばインターネットなどの広域インフラネットワークＮＷを介して映像データを送受する場合、その伝送に許容可能なデータ量、つまりトラフィックが時々刻々と大きく変化するため、トラフィックが低いタイミングでは音声データの送受を優先して映像データを十分に送受できずに表示が乱れる場合がある。そしてそのトラフィックの状況は、デュエット通信する２つのカラオケ装置の組み合わせによって大きく相違する場合がある。
【００２７】
そこで本実施形態では、デュエット通信中における相互の歌唱中映像の表示態様を複数段階の映像モードで設定可能とする。例えば、図３（ａ）に示すように歌唱者全身（つまりカメラ１３で撮影した分の映像全体）の動画映像を送受して表示し合う映像モードを用意する。これは撮像領域が最も広いだけでなく、歌唱者の周囲の動きも含まれる可能性があるため最も映像データの容量が大きく、ネットワークＮＷに最も高いデータ伝送量が要求される映像モードとなる。以下、この映像モードを「全身」モードという。
【００２８】
この他に、例えば図３（ｂ）に示すように、それぞれの顔だけの動画（もしくは静止画）に加えて他の身体部分をいわゆるアバタなどの抽象映像に置き換える映像モードを用意する。これは、カメラ１３の撮像領域の一部を抽出するため映像データの容量を抑えることができ、またアバタ自体のデータは各カラオケ装置が共通にＨＤＤで保存しているものをＩＤで指定するだけでよいため、上記全身モードと比較してデータ伝送量を大幅に抑えることができる。なお、顔部分の抽出は、公知の映像認識技術を用いた映像処理により抽出すればよく、アバタは予め複数種類用意されているものからユーザが任意に選択すればよい。以下、この映像モードを「顔＋パーツアバタ」モードという。
【００２９】
その他に、例えば図３（ｃ）に示すように、歌唱者の全身（顔＋身体）を全てアバタに置き換えて表示し合う最もデータ伝送量の低い映像モードを用意する。以下、この映像モードを「フルアバタ」モードという。
【００３０】
なお、本実施形態では上記３つの映像モードを用意するが、これら以外にもカメラ撮像領域の露出度とデータ伝送量を調整した他のモードを用意してもよい。例えば、カメラ撮像領域のうち歌唱者の顔だけの動画を抽出してそれだけを拡大表示する映像モードなどが考えられる。また本実施形態では、デュエット通信時には、双方同じ映像モードで表示し合うことを前提とする。
【００３１】
そして、募集者側の募集手続きでは、募集申請情報に楽曲全体を通した映像モードの設定を行う。また応募者側の応募手続きでは、楽曲の後述するメロディブロック単位で映像モードの設定を行い、各募集申請情報の閲覧時に自分で設定した映像モードの実行可能性を示すモード実行確度をメロディブロック単位で一覧表示する。このモード実行確度は、募集手続きで設定した楽曲全体での映像モードと、応募手続きで設定したメロディブロック単位での映像モードとのマッチング、及び、当該応募側カラオケ装置と、閲覧している募集申請情報に対応する募集側カラオケ装置との間のネットワークＮＷ上におけるメロディブロック単位で推定される時系列トラフィック推移、に基づいて決定、表示される（後に図１０等で詳述）。
【００３２】
応募者は、それぞれの募集申請情報を閲覧する際に、対応する募集側カラオケ装置とデュエット通信した場合のモード実行確度をメロディブロック単位で確認することができ、それを参照した上でデュエット通信する募集者を選択決定できる。以下に、上述した行程の具体例を順次説明する。
【００３３】
＜募集手続きの具体例＞
募集者がカラオケ装置に対して募集手続きを行う指示操作を行った場合、図４に示す例の募集手続き用画面がモニタ１４に表示される。この募集手続き用画面（図中では「デュエットエントリ画面」と表示）には、紹介映像Ｉと、ユーザ名Ｊ１と、うた年齢Ｊ２と、楽曲入力欄Ｊ３と、歌唱パターン設定欄Ｊ４と、ユーザ属性設定欄Ｊ５と、映像モード設定欄Ｊ６が表示される。
【００３４】
紹介映像Ｉは、予めカメラ１３で募集者自身を撮影した映像である。ユーザ名Ｊ１（図中に示す例では「ユーザＣ」と表示）は、募集者を特定する名称であり、例えば予め募集者自身が任意に設定したハンドルネームなどを表示する。うた年齢Ｊ２は、予め公知の技術により当該募集者の歌唱スキルを評価した指標である。
【００３５】
この募集手続き用画面上で行う募集手続きにおいて、募集者は、デュエット通信で歌唱を希望する楽曲名を楽曲入力欄Ｊ３に入力し、その楽曲で歌唱を希望するコーラス数を歌唱パターン設定欄Ｊ４で設定する。またユーザ設定欄Ｊ５では、募集者自身の性別（男性か女性か）と実際の年齢（図示する例では１０代以下、２０代、３０代、４０代以上のいずれか）を設定する。また映像モード設定欄Ｊ６では、デュエット通信する楽曲の全体を通して相手と相互に歌唱中映像を表示する際の希望する映像モード（本実施形態の例の全身モード、顔＋パーツアバタモード、フルアバタモードのいずれか）を設定する。
【００３６】
以上の募集手続きを行った際には、その内容に基づいて募集者側のカラオケ装置が募集申請情報を生成し、その募集申請情報を含む募集申請情報登録要求をネットワークＮＷを介してサーバ２に送信する。サーバ２は、受信した募集申請情報を図５に示すような募集申請情報データベースに登録する。図５に示す例の募集申請情報データベースでは、募集申請情報としてユーザＩＤ、ユーザ名、性別、年齢、希望映像モード、デュエット楽曲名、歌唱パターン、及び拠点ＩＤを対応付けて記憶する。
【００３７】
ユーザＩＤは、募集者個人に割り当てられた識別情報であり、予めシステム会員としてサーバ２に別途登録した際に付与されたものでもよいし、もしくは募集手続き毎にサーバ２が付与したものでもよい。拠点ＩＤは、当該募集申請情報の送信元の拠点に属するルータ３の識別情報であり、送信元のカラオケ装置のＩＤやＩＰアドレスなどを含めてもよい。なお、募集申請情報としては、他にも募集者の紹介映像Ｉの映像データを含めてもよい。
【００３８】
＜応募手続きの具体例＞
一方、応募者がカラオケ装置に対して応募手続きを行う指示操作を行った場合、図６に示す例の応募手続き用画面がモニタ１４に表示される。この応募手続き用画面（図中では「デュエット検索画面」と表示）には、楽曲入力欄Ｋ１と、ユーザ属性設定欄Ｋ２と、映像モード設定欄Ｋ３が表示される。
【００３９】
この応募手続き用画面上で行う応募手続きにおいて、応募者は、デュエット通信で歌唱を希望する楽曲名を楽曲入力欄Ｋ１に入力する。またユーザ設定欄Ｋ２では、当該応募者がデュエット歌唱の相手として希望する募集者の性別（男性か女性か）と実際の年齢（図示する例では１０代以下、２０代、３０代、４０代以上のいずれか）を設定する。また映像モード設定欄Ｋ３では、デュエット通信する楽曲のメロディブロック単位で相手と相互に歌唱中映像を表示する際の希望する映像モード（本実施形態の例の全身モード、顔＋パーツアバタモード、フルアバタモードのいずれか）を設定する。
【００４０】
ここで上記のメロディブロックについて説明する。一般的な楽曲は、いわゆるイントロ、Ａメロ、Ｂメロ、サビ、アウトロなどといった複数のメロディブロックを時系列的に展開するよう構成されている。例えば図７に示す例では、同じ楽曲でも１コーラスでの歌唱パターンと、フルコーラスでの歌唱パターンではメロディブロックの構成が異なる。この例では単純に楽曲の１番と２番のコーラス数の違いだけではなく、サビの繰り返し数なども異なる場合がある。また特に図示しないが、楽曲によってはＣメロや間奏が存在する場合や、歌唱パターンによってはサビが省略されるコーラスが存在する場合もある。このようにメロディブロックの構成は楽曲とその歌唱パターンによって多様に変化するが、ユーザによってはメロディブロックの種別に応じて相手の歌唱映像を表示する映像モードの変化にこだわる場合も多い。
【００４１】
本実施形態では、応募手続きにおいて応募者が希望する映像モードをメロディブロックの種別（区分的にはメロディブロックの単位）ごとに設定可能としている。なお、図６に示す例では、ＡメロとＢメロをまとめて同じ映像モードで設定している。
【００４２】
以上の応募手続きを行った際には、応募者側のカラオケ装置が上記の各設定内容を検索条件として含む募集申請情報検索要求をサーバ２に送信する。サーバ２は、受信した検索条件で募集申請情報データベースを検索し、検索条件に適合する順で募集申請情報を一覧表示する募集申請情報一覧画面を生成して応募側カラオケ装置に返信する。図８は、募集申請情報一覧画面の一例を示している。この図８において、募集申請情報一覧画面（図中では「デュエット募集一覧画面」と表示）では、検索された募集者の紹介映像Ｉが検索条件の適合度順で一覧表示されている。なお、募集申請情報一覧画面で表示する紹介映像Ｉは、例えばサーバ２が一覧画面を生成する際に別途登録されている会員データベースからユーザＩＤでひも付けして入手してもよいし、一覧画面を生成する度に各募集側カラオケ装置から入手してもよい。
【００４３】
ここで上記の適合度について説明する。本実施形態における適合度とは、複数の条件からなる検索条件に対して各募集申請情報がそれぞれ総合的にどれだけ適合するかの度合いを示す指標を意味する。本実施形態の例では、上述したように募集申請情報検索要求に含まれる検索条件として、デュエット楽曲、希望ユーザ属性、及び希望映像モードがある。デュエット楽曲と希望ユーザ属性については、そのまま検索条件として募集申請情報の絞り込みを行えばよい。
【００４４】
しかし、希望映像モードについては、募集者側が楽曲全体を通して単一の映像モードを設定しているのに対し、応募者側はメロディブロックの種別（メロディブロック単位）で映像モードを設定しているため、それらの間のマッチングの度合いを考慮する必要がある。またデュエット通信中における確実な歌唱映像の送受を確保するために、各募集申請情報に対応する募集者側のカラオケ装置と、当該応募者側のカラオケ装置との間でデュエット通信を行った場合に予想されるネットワークトラフィック状況の変化も考慮する必要がある。これら映像モードのマッチングとネットワークトラフィックに基づいて、各メロディブロックにおける希望映像モードの実行可能性をモード実行確度として特定する。なお、このモード実行確度の特定手法については後に詳述する。
【００４５】
上述した適合度のうち希望映像モードの一致度については、例えば図９に示すような演算式を用いて具体的に特定できる。この演算式は、選択された各映像モードと各メロディブロック種別の全ての組み合わせでそれぞれの重要度とモード実行確度の積を累積した値を演算する。なお、演算式中のＦｓｃｏｒｅがモード一致度を示し、Ｗ［Ｖｉ］が映像モードＶｉのユーザにおける重要度（Ｗ［全身］＞Ｗ［顔＋パーツアバタ］＞Ｗ［フルアバタ］）を示し、Ｐ［Ｖｉ・Ｂｊ］がメロディブロックＢｊにおける映像モードＶｉのモード実行確度を示し、Ｏ［Ｂｊ］が応募手続き画面上で設定した各メロディブロックＢｊの選択状態（１：選択、０：非選択）を示している。
【００４６】
例えば上記図６の応募手続き画面で示した設定例では、デュエット楽曲が「○○○○○○○○○」、希望ユーザ属性が「１０代以下または２０代の女性」、希望映像モードが全メロディブロックで全身モードを希望するよう設定されている。これに対応して図８の募集申請情報一覧画面では、デュエット楽曲とユーザ属性が一致する募集申請情報の中から、希望映像モードとのモード一致度の高い順で募集申請情報（紹介映像Ｉ）が配置されている。つまり、応募者が最も多く希望する全身モードを募集手続きで設定した募集申請情報の紹介映像（図中の１、２、３）が上位に配置され、続いて一致する顔＋パーツアバタモードを設定した募集申請情報の紹介映像（図中の４、５）が配置され、続いて最も一致しないフルアバタモードを設定した募集申請情報の紹介映像（図中の６、７、８）が配置されている。このように検索条件に適合する順で募集申請情報の紹介映像Ｉを配置することで、応募者は希望条件に基づく募集申請情報の比較が容易となる。
【００４７】
応募者が募集申請情報一覧画面上でいずれかの紹介映像Ｉを選択操作した際には、応募者側のカラオケ装置がその募集申請情報の詳細画面を要求する募集申請情報詳細要求をサーバ２に送信する。サーバ２は、受信した要求に対応する募集申請情報詳細画面を生成して応募側カラオケ装置に返信する。図１０は、上記図８中の３番目に配置されたＣさんの募集申請情報詳細画面であり、これは上記図４で示した募集手続き用画面の募集申請情報に対応する。
【００４８】
この図１０において、募集申請情報詳細画面には、Ｃさんの紹介映像Ｉと、ユーザ属性Ｌ１と、デュエット楽曲Ｌ２と、歌唱パターンＬ３と、この歌唱パターンに基づくメロディブロック構成Ｌ４と、各メロディブロックに対応した予想映像モードＬ５と、各予想映像モードに対応したモード実行確度Ｌ６が表示される。応募者は、この募集申請情報の募集者とデュエット歌唱を希望する場合には、画面表示中に所定の確定操作（図示する例では「決定ボタン」の押下）を行うことで、当該募集者とのデュエット通信を開始できる。
【００４９】
＜モード実行確度について＞
ここで、上記の予想映像モードとモード実行確度について説明する。モード実行確度は、上述したように、募集者と応募者との間の希望映像モードのマッチングの度合いと、デュエット通信中に予想されるネットワークトラフィック状況に基づいて、各メロディブロックにおける希望映像モードの実行可能性を示す指標である。
【００５０】
本実施形態の例では、各拠点のルータ３が自身を経由するインバウンド・トラフィックとアウトバウンド・トラフィックに対し例えば１分間当たりの平均トラフィック量を計測してその履歴を記憶する。各ルータ３は、このネットワークトラフィック情報を例えば５分毎にサーバ２へ送信し、サーバ２は例えば図１１に示すようなトラフィック履歴データベースに記録する。図１１に示す例のトラフィック履歴データベースでは、拠点ＩＤ、ルータ種別、ＩＰ、稼動モード、及び過去の定時間隔でのネットワークトラフィック情報（上り／下り）を対応付けて記録する。なお、図示の煩雑を避けるためネットワークトラフィック情報は５つのサンプル数で示しているが、実際にはもっと多くの情報をもっと多様な時間間隔で記録する。
【００５１】
サーバ２は、このトラフィック履歴データベースの内容に基づいて、募集側と応募側それぞれの拠点（ルータ３）における将来のトラフィック状況を予想する。例えば、図１２に示す第１の例のタイムチャートのように、現在時刻（１８：００）から通常の操作を行ってデュエット通信の開始が予想される１８：０３から楽曲の終了が予想される１８：０８までの一方のルータ３におけるトラフィックの変化を図中の太実線のように推定したとする。このように推定されたトラフィックの変化を、以下において時系列トラフィック推移という。なお、この推定手法については、毎日同じ時間のトラフィックの変化傾向や、過去直近のトラフィックの変化傾向を参照するなどにより推定する。
【００５２】
この例では、全身モードで歌唱映像を相互に送受するために約２６Ｍｂｐｓ以上のトラフィックが必要と想定している。また、顔＋パーツアバタモードで送受するためには約１７Ｍｂｐｓ以上必要と想定している。また、フルアバタモードは約１７Ｍｂｐｓ未満でも可能と想定している。
【００５３】
１コーラスの歌唱パターンを想定した図１２に示す例では、イントロのメロディブロックにおける時間帯で、時系列トラフィック推移がおよそ８Ｍｂｐｓから９Ｍｂｐｓへ単調に増加するよう推定されている。この場合、当該時間帯では、フルアバタモード（図中では「アバタ」と略記）が１００％のモード実行確度で実行されると特定される。なお、このときのモード実行確度の特定では、応募者側の希望映像モード（全身モードを想定）を上限として応募者側が当該イントロブロックに対して設定した希望映像モード（全身モードを想定）の実行確度、つまりマッチングも考慮して特定する。
【００５４】
また、例えばアウトロのメロディブロックにおける時間帯では、時系列トラフィック推移がおよそ２３Ｍｂｐｓから３５Ｍｂｐｓへ単調に増加するよう推定されている。この場合、当該時間帯では、それぞれの時間占有率に基づいて顔＋パーツアバタモード（図中では「顔」と略記）が３０％、全身モードが７０％のモード実行確度で実行されると特定される。
【００５５】
図１２で示す例の時系列トラフィック推移は、全体的に時間の経過とともに５Ｍｂｐｓから３５Ｍｂｐｓ以上まで単調に増加する傾向にあり、イントロ及びＡメロではフルアバタモードが１００％、Ｂメロではフルアバタモードが８０％で顔＋パーツアバタモードが２０％、サビでは顔＋パーツアバタモードが１００％、アウトロでは顔＋パーツアバタモードが３０％で全身モードが７０％のモード実行確度がそれぞれ特定される。
【００５６】
他にも図１３に示す第２の例の時系列トラフィック推移は、全体的に時間の経過とともに４５Ｍｂｐｓから５Ｍｂｐｓまで単調に減少する傾向にあり、イントロ及びＡメロでは全身モードが１００％、Ｂメロでは全身モードが２０％で顔＋パーツアバタモードが８０％、サビでは顔＋パーツアバタモードが５０％でフルアバタモードが５０％、アウトロではフルアバタモードが１００％のモード実行確度がそれぞれ特定される。
【００５７】
上記図１０の募集申請情報詳細画面では、各メロディブロックごとに最も高く特定されたモード実行確度を表示し、そのモード実行確度に対応する映像モードを予想映像モードとして表示する。これにより応募者は、それぞれの募集申請情報を閲覧する際に、対応する募集側カラオケ装置とデュエット通信した場合の予想映像モードとモード実行確度をメロディブロック単位で確認することができ、それを参照した上でデュエット通信する相手の募集者を選択決定できる。
【００５８】
＜組み合わせ決定行程における各種情報の送受＞
以上のようにデュエット通信の組み合わせを決定する行程で、各装置間が送受する情報の詳細を図１４のシーケンスチャートにまとめて示す。この図１４において、まず各拠点のルータ３が所定時間間隔でネットワークに対する上りと下りのトラフィックを計測し、履歴を記録する。またルータ３は、所定時間間隔でその履歴情報をネットワークトラフィック情報としてサーバ２に送信し、サーバ２は受信した情報をトラフィック履歴データベース（上記図１１参照）に記録する（ステップＳＴ１、ＳＴ１１）。なお、全てのルータ３が同時にネットワークトラフィック情報を送信するのではなく、互いに時間をずらして送信するのが望ましい。
【００５９】
そして募集者が募集側カラオケ装置を操作してデュエット募集手続き（上記図４参照）を行うことで、楽曲、自己のユーザ属性、及び楽曲全体を通した希望映像モードを含む募集申請情報の登録要求をサーバ２に送信する。サーバ２は受信した募集申請情報を募集申請情報データベース（上記図５参照）に登録する（ステップＳＴ２）。なお、このステップＳＴ２における募集側カラオケ装置とサーバ２の処理が、各請求項記載の募集手続き手段に相当する。
【００６０】
一方、応募者は、応募側カラオケ装置を操作してデュエット応募手続き（上記図６参照）を行うことで、楽曲、希望相手のユーザ属性、及びメロディブロック単位の希望映像モードを含む検索条件で募集申請情報の検索要求をサーバ２に送信する（ステップＳＴ３）。サーバ２は受信した検索条件で募集申請情報を検索し、適合度の高い順で紹介映像Ｉを配置した募集申請情報一覧画面（上記図８参照）を生成し、応募側カラオケ装置に返信する（ステップＳＴ４）。応募側カラオケ装置は、受信した募集申請情報一覧画面をモニタ１４に表示する。なお、以上のステップＳＴ３、ＳＴ４における応募側カラオケ装置とサーバ２の処理が各請求項記載の第１応募手続き手段に相当する。
【００６１】
応募側カラオケ装置は、受信した募集申請情報一覧画面を表示し、応募者が選択した募集申請情報の詳細をサーバ２に要求する（ステップＳＴ５）。受信したサーバ２は、募集申請情報詳細要求に対応する募集側カラオケ装置と要求元の応募側カラオケ装置がそれぞれ存在する拠点のルータ３のネットワークトラフィック情報に基づいて、それら装置間における時系列トラフィック推移を推定する。そして、この時系列トラフィック推移と双方の希望映像モードとのマッチングに基づいてメロディブロック単位でのモード実行確度と予想映像モードを特定し、それらを反映した募集申請情報詳細画面（上記図１０参照）を生成して要求元の応募側カラオケ装置に返信する（ステップＳＴ６）。応募側カラオケ装置は、受信した募集申請情報詳細画面をモニタ１４に表示する。なお、このステップＳＴ６とステップＳＴ１、ＳＴ１１におけるサーバ２とルータ３の処理が、各請求項記載のトラフィック推定手段に相当する。また、このステップＳＴ６における応募側カラオケ装置とサーバ２の処理が、各請求項記載の第１確度表示手段に相当する。
【００６２】
必要に応じて上記ステップＳ５とステップＳＴ６を繰り返し、最終的に応募者がデュエット歌唱の相手として希望する募集者を確定した際にサーバ２にその確定通知を送信する（ステップＳ７）。なお、このステップＳＴ７における応募側カラオケ装置の処理が、各請求項記載の第１相手装置決定手段に相当する。
【００６３】
サーバ２は受信した確定通知が指定する募集申請情報を募集申請情報データベースから削除するとともに、対応する募集者と応募者の双方のカラオケ装置に対してデュエット通信の開始を通知する（ステップＳＴ８）。このとき、双方のカラオケ装置に対してそれぞれ相手のＩＰアドレス等の接続先情報も含めて通知する。以降は、サーバ２を介さずに、募集者側カラオケ装置と応募者側カラオケ装置が直接相手とデュエット通信を行う（ステップＳＴ９、ＳＴ１０）。
【００６４】
＜各装置の制御フロー＞
【００６５】
上記手法を実現するために各装置のＣＰＵにより実行される処理内容をフローチャートで説明する。まず、サーバ２のＣＰＵ（特に図示せず）により実行される処理内容を、図１５のフローにより説明する。図１５において、例えばサーバ２の電源がオンにされることによって、このフローが開始される。
【００６６】
まず、ステップＳＳ５において、サーバ２のＣＰＵは、ネットワークＮＷを介していずれかのルータ３またはカラオケ装置から何らかの情報又は要求を受信したか否かを判定する。何も受信していない場合、判定は満たされず（ＳＳ５：ＮＯ）、ステップＳＳ１０に移る。
【００６７】
ステップＳＳ１０では、サーバ２のＣＰＵは、ユーザから処理の終了を指示する操作が入力されたか否かを判定する。終了操作が入力されていない場合、判定は満たされず（ＳＳ１０：ＮＯ）、ステップＳＳ５に戻って同様の手順を繰り返す。
【００６８】
一方、終了操作が入力されていた場合、判定が満たされ（ＳＳ１０：ＹＥＳ）、このフローを終了する。
【００６９】
また一方、上記ステップＳＳ５の判定において、サーバ２がネットワークＮＷを介して何らかの情報又は要求を受信した場合、判定が満たされ（ＳＳ５：ＹＥＳ）、ステップＳＳ１５に移る。
【００７０】
ステップＳＳ１５では、サーバ２のＣＰＵは、上記ステップＳＳ５で受信を判定した情報又は要求の内容を判定する。内容が各拠点のルータ３から受信したネットワークトラフィック情報である場合、ステップＳＳ２０に移る。
【００７１】
ステップＳＳ２０では、サーバ２のＣＰＵは、受信したネットワークトラフィック情報を、その送信元のルータ３に対応付けてトラフィック履歴データベース（上記図１１参照）に記録する。そしてステップＳＳ５に戻り、同様の手順を繰り返す。
【００７２】
一方、上記ステップＳＳ１５の判定において、受信した内容がカラオケ装置から受信した募集申請情報登録要求である場合、ステップＳＳ２５に移る。
【００７３】
ステップＳＳ２５では、サーバ２のＣＰＵは、受信した募集申請情報を、送信元のカラオケ装置又はユーザＩＤに対応付けて募集申請情報データベース（上記図５参照）に登録する。そしてステップＳＳ５に戻り、同様の手順を繰り返す。
【００７４】
また一方、上記ステップＳＳ１５の判定において、受信した内容がカラオケ装置から受信した募集申請情報詳細要求である場合、ステップＳＳ３０に移る。
【００７５】
ステップＳＳ３０では、サーバ２のＣＰＵは、受信した募集申請情報詳細要求に含まれる検索条件（楽曲、希望ユーザ属性）で募集申請情報データベースを検索する。さらに、検索した募集申請情報のそれぞれの適合度を特定し、その適合度の降順で募集申請情報の順位付けを行う。その後、ステップＳＳ３５に移る。
【００７６】
ステップＳＳ３５では、サーバ２のＣＰＵは、適合度の降順で募集申請情報（紹介映像Ｉ）を配置した一覧画面（上記図８参照）を生成し、募集申請情報詳細要求の送信元の応募側カラオケ装置に返信する。その後、ステップＳＳ４０に移る。
【００７７】
ステップＳＳ４０では、サーバ２のＣＰＵは、応募側カラオケ装置から募集申請情報詳細要求を受信したか否かを判定する。募集申請情報詳細要求を受信していない場合、判定は満たされず（ＳＳ４０：ＮＯ）、ステップＳＳ５５に移る。
【００７８】
一方、募集申請情報詳細要求を受信した場合、判定が満たされ（ＳＳ４０：ＹＥＳ）、ステップＳＳ４５に移る。
【００７９】
ステップＳＳ４５では、サーバ２のＣＰＵは、詳細要求された募集申請情報に対応する募集側カラオケ装置と要求元の応募側カラオケ装置がそれぞれ存在する拠点のルータ３のネットワークトラフィック情報に基づいて、それら装置間における時系列トラフィック推移を推定する。そして、この時系列トラフィック推移と双方の希望映像モードとのマッチングに基づいてモード実行確度と予想映像モードをメロディブロック単位で特定する。その後、ステップＳＳ５０に移る。
【００８０】
ステップＳＳ５０では、サーバ２のＣＰＵは、上記ステップＳＳ４５で特定したモード実行確度と予想映像モードを反映した募集申請情報詳細画面（上記図１０参照）を生成して要求元の応募側カラオケ装置に返信する。その後、ステップＳＳ５５に移る。
【００８１】
ステップＳＳ５５では、サーバ２のＣＰＵは、応募側カラオケ装置からデュエット相手確定通知を受信したか否かを判定する。デュエット相手確定通知を受信していない場合、判定は満たされず（ＳＳ５５：ＮＯ）、ステップＳＳ４０に戻り同様の手順を繰り返す。
【００８２】
一方、デュエット相手確定通知を受信した場合、判定が満たされ（ＳＳ５５：ＹＥＳ）、ステップＳＳ６０に移る。
【００８３】
ステップＳＳ６０では、サーバ２のＣＰＵは、応募側カラオケ装置と、選択された募集側カラオケ装置のそれぞれに接続先情報も含めたデュエット開始通知を送信する。その後、ステップＳＳ５に戻り同様の手順を繰り返す。
【００８４】
次に、募集側カラオケ装置のＣＰＵにより実行される処理内容を、図１６のフローにより説明する。図１６において、例えば募集側カラオケ装置の電源がオンにされることによって、このフローが開始される。
【００８５】
まず、ステップＳＳ１０５において、募集側カラオケ装置のＣＰＵ３１は、ユーザから募集手続きを指示する操作が入力されたか否かを判定する。募集手続き操作が入力されていない場合、判定は満たされず（ＳＳ１０５：ＮＯ）、ステップＳＳ１１０に移る。
【００８６】
ステップＳＳ１１０では、募集側カラオケ装置のＣＰＵ３１は、ネットワークＮＷを介してサーバ２からデュエット開始通知を受信したか否かを判定する。デュエット開始通知を受信していない場合、判定は満たされず（ＳＳ１１０：ＮＯ）、ステップＳＳ１１５へ移る。
【００８７】
ステップＳＳ１１５では、募集側カラオケ装置のＣＰＵ３１は、ユーザから処理の終了を指示する操作が入力されたか否かを判定する。終了操作が入力されていない場合、判定は満たされず（ＳＳ１１５：ＮＯ）、ステップＳＳ１０５に戻って同様の手順を繰り返す。
【００８８】
一方、終了操作が入力されていた場合、判定が満たされ（ＳＳ１１５：ＹＥＳ）、このフローを終了する。
【００８９】
また一方、上記ステップＳＳ１０５の判定において、募集手続き操作が入力されていた場合、判定が満たされ（ＳＳ１０５：ＹＥＳ）、ステップＳＳ１２０に移る。
【００９０】
ステップＳＳ１２０では、募集側カラオケ装置のＣＰＵ３１は、募集手続き用画面（上記図４参照）をモニタ１４に表示する。なお、この募集手続き用画面は、募集側カラオケ装置の要求に応じてサーバ２が生成した画面を送受、表示してもよい。その後、ステップＳＳ１２５に移る。
【００９１】
ステップＳＳ１２５では、募集側カラオケ装置のＣＰＵ３１は、募集手続き用画面上でユーザが入力、設定した内容に基づいて募集申請情報を生成する。その後、ステップＳＳ１３０に移る。
【００９２】
ステップＳＳ１３０では、募集側カラオケ装置のＣＰＵ３１は、上記ステップＳＳ１２５で生成した募集申請情報とその登録要求をサーバ２に送信する。その後、ステップＳＳ１０５に戻り同様の手順を繰り返す。
【００９３】
また一方、上記ステップＳＳ１１０の判定において、デュエット開始通知を受信した場合には、判定が満たされ（ＳＳ１１０：ＹＥＳ）、ステップＳＳ１３５へ移る。
【００９４】
ステップＳＳ１３５では、募集側カラオケ装置のＣＰＵ３１は、受信したデュエット開始通知に含まれる相手の応募者側カラオケ装置の接続先に直接アクセスし、デュエット通信を実行する。その終了後には、ステップＳＳ１０５に戻り同様の手順を繰り返す。
【００９５】
次に、応募側カラオケ装置のＣＰＵ３１により実行される処理内容を、図１７のフローにより説明する。図１７において、例えば応募側カラオケ装置の電源がオンにされることによって、このフローが開始される。
【００９６】
まず、ステップＳＳ２０５において、応募側カラオケ装置のＣＰＵ３１は、ユーザから応募手続きを指示する操作が入力されたか否かを判定する。応募手続き操作が入力されていない場合、判定は満たされず（ＳＳ２０５：ＮＯ）、ステップＳＳ２１０に移る。
【００９７】
ステップＳＳ２１０では、応募側カラオケ装置のＣＰＵ３１は、ネットワークＮＷを介してサーバ２からデュエット開始通知を受信したか否かを判定する。デュエット開始通知を受信していない場合、判定は満たされず（ＳＳ２１０：ＮＯ）、ステップＳＳ２１５へ移る。
【００９８】
ステップＳＳ２１５では、応募側カラオケ装置のＣＰＵ３１は、ユーザから処理の終了を指示する操作が入力されたか否かを判定する。終了操作が入力されていない場合、判定は満たされず（ＳＳ２１５：ＮＯ）、ステップＳＳ２０５に戻って同様の手順を繰り返す。
【００９９】
一方、終了操作が入力されていた場合、判定が満たされ（ＳＳ２１５：ＹＥＳ）、このフローを終了する。
【０１００】
また一方、上記ステップＳＳ２０５の判定において、応募手続き操作が入力されていた場合、判定が満たされ（ＳＳ２０５：ＹＥＳ）、ステップＳＳ２２０に移る。
【０１０１】
ステップＳＳ２２０では、応募側カラオケ装置のＣＰＵ３１は、応募手続き用画面（上記図６参照）をモニタ１４に表示する。なお、この応募手続き用画面は、応募側カラオケ装置の要求に応じてサーバ２が生成した画面を送受、表示してもよい。その後、ステップＳＳ２２５に移る。
【０１０２】
ステップＳＳ２２５では、応募側カラオケ装置のＣＰＵ３１は、応募手続き用画面上でユーザが入力、設定した内容に基づく検索条件で募集申請情報検索要求をサーバ２へ送信する。その後、ステップＳＳ２３０に移る。
【０１０３】
ステップＳＳ２３０では、応募側カラオケ装置のＣＰＵ３１は、サーバ２から返信された募集申請情報一覧画面（上記図８参照）を受信し、モニタ１４に表示する。その後、ステップＳ２３５へ移る。
【０１０４】
ステップＳＳ２３５では、応募側カラオケ装置のＣＰＵ３１は、ユーザからいずれかの募集申請情報を選択する操作が入力さるまでループ待機する。いずれかの募集申請情報が選択された場合、ステップＳＳ２４０に移る。
【０１０５】
ステップＳＳ２４０では、応募側カラオケ装置のＣＰＵ３１は、上記ステップＳＳ２３５で選択された募集申請情報の詳細要求をサーバ２に送信する。その後に、ステップＳＳ２４５に移る。
【０１０６】
ステップＳＳ２４５では、応募側カラオケ装置のＣＰＵ３１は、サーバ２から返信された募集申請情報詳細画面（上記図１０参照））を受信し、モニタ１４に表示する。その後、ステップＳ２５０へ移る。
【０１０７】
ステップＳＳ２５０では、応募側カラオケ装置のＣＰＵ３１は、ユーザからデュエット相手を確定する操作が入力されたか否かを判定する。デュエット相手の確定操作が入力されていない場合、判定は満たされず（ＳＳ２５０：ＮＯ）、ステップＳＳ２３５に戻り同様の手順を繰り返す。
【０１０８】
一方、デュエット相手の確定操作が入力された場合、判定が満たされ（ＳＳ２５０：ＹＥＳ）、ステップＳＳ２５５に移る。
【０１０９】
ステップＳＳ２５５では、応募側カラオケ装置のＣＰＵ３１は、その時点で表示されている募集申請情報詳細画面の募集者をデュエット通信の相手として確定する通知をサーバ２に送信する。その後、ステップＳＳ２０５に戻り同様の手順を繰り返す。
【０１１０】
また一方、上記ステップＳＳ２１０の判定において、デュエット開始通知を受信した場合には、判定が満たされ（ＳＳ２１０：ＹＥＳ）、ステップＳＳ２６０へ移る。
【０１１１】
ステップＳＳ２６０では、応募側カラオケ装置のＣＰＵ３１は、受信したデュエット開始通知に含まれる相手の募集者側カラオケ装置の接続先に直接アクセスし、デュエット通信を実行する。その終了後には、ステップＳＳ２０５に戻り同様の手順を繰り返す。
【０１１２】
なお、以上の応募側カラオケ装置の処理において、ステップＳＳ２２０、ＳＳ２２５、ＳＳ２３０の手順が各請求項記載の第２応募手続手段に相当し、ステップＳＳ２４５の手順が各請求項記載の第２確度表示手段に相当し、ステップＳＳ２５０、ＳＳ２５５の手順が各請求項記載の第２相手装置決定手段に相当する。
【０１１３】
次に、ルータ３のＣＰＵ（特に図示せず）により実行される処理内容を、図１８のフローにより説明する。図１８において、例えばルータ３の電源がオンにされることによって、このフローが開始される。
【０１１４】
まず、ステップＳＳ３０５において、ルータ３のＣＰＵは、当該ルータ３自身を経由するインバウンド・トラフィックとアウトバウンド・トラフィックに対し例えば１分間当たりの平均トラフィック量を計測してその履歴を記憶する。その後に、ステップＳＳ３１０に移る。
【０１１５】
ステップＳＳ３１０では、ルータ３のＣＰＵは、サーバ２にネットワークトラフィック情報を送信する所定時間間隔のタイミングに到達したか否かを判定する。サーバ２への送信タイミングに到達していない場合、判定は満たされず（ＳＳ３１０：ＮＯ）、ステップＳＳ３２０に移る。
【０１１６】
一方、サーバ２への送信タイミングに到達した場合、判定が満たされ（ＳＳ３１０：ＹＥＳ）、ステップＳＳ３１５に移る。
【０１１７】
ステップＳＳ３１５では、ルータ３のＣＰＵは、過去直近で記録したトラフィックの履歴をネットワークトラフィック情報としてサーバ２に送信する。その後に、ステップＳＳ３２０に移る。
【０１１８】
ステップＳＳ３２０では、ルータ３のＣＰＵは、ユーザから処理の終了を指示する操作が入力されたか否かを判定する。終了操作が入力されていない場合、判定は満たされず（ＳＳ３２０：ＮＯ）、ステップＳＳ３０５に戻って同様の手順を繰り返す。
【０１１９】
一方、終了操作が入力されていた場合、判定が満たされ（ＳＳ３２０：ＹＥＳ）、このフローを終了する。
【０１２０】
＜本実施形態により得られる効果＞
以上説明したように、本実施形態においては、応募者が募集申請情報の詳細を閲覧する際に、対応する募集側カラオケ装置とデュエット通信した場合の時系列トラフィック推移に基づくモード実行確度をメロディブロック単位で確認することができ、それを参照した上でデュエット通信する募集者を選択決定できる。
【０１２１】
このようにして本実施形態では、応募者に対して希望する歌唱中映像の表示態様の実行可能性に関する情報を募集申請情報ごとにメロディブロック単位で提示することができ、応募者はそれを参照して募集者を選択決定できるといった利便性を提供できる。
【０１２２】
なお、上記実施形態では、インターネット介して接続する２つのルータ３間で推定された時系列トラフィック推移を２つのカラオケ装置間（募集側と応募側の間）の時系列トラフィック推移に代用してモード実行確度を特定したが、本発明はこれに限られない。他にも、ＬＡＮなどの構内ネットワークを介した２つのカラオケ装置間で直接的に時系列トラフィック推移を推定し、これに基づくモード実行確度を特定してもよい。
【０１２３】
また、以上既に述べた以外にも、上記実施形態や各変形例による手法を適宜組み合わせて利用してもよい。
【０１２４】
その他、一々例示はしないが、本発明は、その趣旨を逸脱しない範囲内において、種々の変更が加えられて実施されるものである。
【符号の説明】
【０１２５】
１                カラオケシステム
２                サーバ
３                ルータ
４                カラオケ装置
１１              マイク
１２              スピーカ
１３              カメラ
１４              モニタ
ＮＷ              広域インフラネットワーク（ネットワーク）
【図１】
2015143762.tif 000003
【図２】
2015143762.tif 000004
【図３】
2015143762.tif 000005
【図４】
2015143762.tif 000006
【図５】
2015143762.tif 000007
【図６】
2015143762.tif 000008
【図７】
2015143762.tif 000009
【図８】
2015143762.tif 000010
【図９】
2015143762.tif 000011
【図１０】
2015143762.tif 000012
【図１１】
2015143762.tif 000013
【図１２】
2015143762.tif 000014
【図１３】
2015143762.tif 000015
【図１４】
2015143762.tif 000016
【図１５】
2015143762.tif 000017
【図１６】
2015143762.tif 000018
【図１７】
2015143762.tif 000019
【図１８】
2015143762.tif 000020