JP4281756B2 - カラオケシステム - Google Patents

Description

本発明は、カラオケ演奏を行うカラオケ装置と、ユーザによって操作される複数台のリクエスト装置と、を備えるカラオケシステムに関する。

従来、カラオケ演奏を行うカラオケ装置と、そのカラオケ装置におけるカラオケ演奏曲の予約をユーザが行うため、ユーザによって操作されるリクエスト装置と、を備えるカラオケシステムが知られている。

カラオケ装置は、予約リストを記憶しており、その予約リストにおける予約順に従ってカラオケ演奏を行う。この予約リストは早く予約されるほど予約順が早くなるのが原則である。ただし、予約後に、例えば間違って入力した予約を取り消したり、歌唱者の時間の都合で予約順序を入れ替えたいという要望をユーザが持つことがある。

このような演奏予約情報の編集自体は従来のカラオケ装置でも実現可能であったが、カラオケ装置はカラオケ演奏処理を実行している期間が多く、予約リストの一覧表示は困難であった。つまり、画面には歌詞テロップが表示されているため、その歌詞テロップを見ている歌唱者の邪魔にならないよう、例えば画面の端などにおいて１行だけ表示するという分かりにくいものであった。

そこで特許文献１に示されているように、リクエスト装置において予約リストを作成・記憶し、リクエスト装置が有する表示手段に一覧表示してユーザに知らせるようにする技術が知られている。そして、予約の取消なども、リクエスト装置において自由にできるようになっている。
特開２００３−１３１６７１号公報

１台のカラオケ装置に対して１台のリクエスト装置しか準備されていないと、多くのメンバーでカラオケを楽しもうとした場合に、ユーザがリクエスト装置を操作する順番を長く待つこととなってしまう。それに対して１台のカラオケ装置に対して複数台のリクエスト装置が準備されていれば、上記ユーザの順番待ちの時間が短くなり利便性が向上する。

しかしながら、特許文献１に開示されている技術においては、１台のカラオケ装置と１台のリクエスト装置とからなるカラオケシステムしか想定していない。そのため、１台のカラオケ装置に対して複数台のリクエスト装置が準備されるようなカラオケシステムに特許文献１の技術思想を適用すると、次のような問題がある。

つまり、例えばリクエスト装置Ａから曲番号１１→１２→１３の３曲が順番に予約されたとする。一方、リクエスト装置Ｂからは曲番号２１→２２→２３の３曲が順番に予約されたとする。カラオケ装置が予約を受け付けた順番が１１→２１→１２→２２→１３→２３であったとすると、カラオケ装置はこの順番で予約リストを記憶する。

しかし、特許文献１に開示された技術においては、リクエスト装置において作成した予約リストしか表示できない。つまり、リクエスト装置Ａでは曲番号１１→１２→１３の３曲による予約リストを表示し、リクエスト装置Ｂでは曲番号２１→２２→２３の３曲による予約リストを表示することとなる。そのため、例えば予約順番を移動させようとしても、全体として何番目の予約順番なのか不明なため、うまくいかない。

このように、１台のカラオケ装置に対して複数台のリクエスト装置が準備されていればユーザの利便性は向上するが、実態にあった予約リストの一覧表示をリクエスト装置にて行うことができず、したがって、予約順番の移動などの予約リストの編集も適切に行うことができない。

本発明は、１台のカラオケ装置に対して複数台のリクエスト装置を準備していながら、予約リストの一覧表示や編集を各リクエスト装置にて適切に行うことができるようにしたカラオケシステムを提供することを目的とする。

上記第１の目的を達成するためになされた請求項１に記載のカラオケシステムは、リクエスト装置からカラオケ演奏に関する指示を受け付け、その受け付けた指示に応じてカラオケ演奏に関する処理を行うカラオケアプリケーションから情報を取得し、その取得した情報をリクエスト装置に対して出力するＷｅｂサーバを備えるカラオケ装置（４：なお、この欄においては、発明に対する理解を容易にするため、必要に応じて「発明を実施するための最良の形態」欄において説明した構成要素を括弧内に示すが、この記載によって特許請求の範囲を限定することを意味するものではない。）と、カラオケ装置に対する操作入力をユーザから受け付ける複数台のリクエスト装置（５ａ，５ｂ，…）とがｈｔｔｐ通信によって通信可能に接続されている。

カラオケ装置は、一つ以上のカラオケ演奏曲を記憶する演奏曲記憶手段（１６）と、演奏順が区別可能なカラオケ演奏曲の予約リストを記憶可能な予約リスト記憶手段（４０）と、予約リスト記憶手段が記憶する前記予約リストに基づいて前記演奏曲記憶手段からカラオケ演奏曲を読み出してカラオケ演奏するカラオケ演奏手段（１２，２４）と、を備えている。

カラオケ装置が備えるＷｅｂサーバは、リクエスト装置からカラオケ演奏曲の予約に関する指示である予約関連指示や予約リスト取得要求と送信元のリクエスト装置のシリアルナンバーとを含むｈｔｔｐリクエストを受け付ける受付手段（１４）と、受付手段によって受け付けた予約リスト取得要求に応じて、予約リストをカラオケアプリケーションから取得し、その取得した予約リストをｈｔｔｐレスポンスとしてリクエスト装置へ閲覧可能に配信する一方、受付手段が受け付けた予約関連指示で示される予約リストの追加／編集処理をカラオケアプリケーションに実行させ、その追加／編集処理がなされた予約リストをｈｔｔｐレスポンスとしてリクエスト装置へ閲覧可能に配信する配信手段（１２，１４）と、を備えている。
カラオケ装置が備えるカラオケアプリケーションは、受付手段によって予約関連指示や予約リスト取得要求に関するｈｔｔｐリクエストを受け付けた場合、そのｈｔｔｐリクエストの送信元であるリクエスト装置のシリアルナンバーをメモリに登録する登録手段（１２）と、受付手段が受け付けた予約関連指示がカラオケ演奏曲の新規の予約指示であった場合には、予約リスト記憶手段が記憶する予約リストへ新規に予約情報を登録し、受付手段が受け付けた予約関連指示が予約曲の削除や予約順の移動などの編集指示であった場合には、予約リスト記憶手段が記憶する予約リストを編集し、カラオケ演奏手段による演奏対象となった場合には、該当するカラオケ演奏曲の予約情報を予約リスト記憶手段が記憶する予約リストから削除する予約リスト制御手段（１２）と、予約リスト記憶手段が記憶する予約リストの内容に変更が生じた場合、その旨をソケット通信によって各リクエスト装置へ通知する通知手段（１２，１４）と、を備えている。

一方、リクエスト装置は、ユーザによる予約関連指示や予約リスト取得要求を入力する入力手段（６０，６２）と、入力手段を介して入力された予約関連指示や予約リスト取得要求と自リクエスト装置のシリアルナンバーとを含むｈｔｔｐリクエストをカラオケ装置へ送信すると共に、カラオケ装置の配信手段によるｈｔｔｐレスポンスを受信するｈｔｔｐ通信手段（５２，６８）と、カラオケ装置との間でソケットコネクトを行うと共に、カラオケ装置の通知手段からのソケット通信による通知を受信するソケット通信手段（５２，６８）と、カラオケ装置の配信手段によってｈｔｔｐレスポンスとして配信された予約リストを、Ｗｅｂブラウザによって表示手段（５８）に表示させる表示制御手段（５４）と、ソケット通信手段を介してカラオケ装置の通知手段から予約リストの内容変更通知を受信した場合、ｈｔｔｐ通信手段を介して予約リスト取得要求をカラオケ装置へ送信させるリロード制御手段と（５２）とを備える。
そして、リクエスト装置が備えるソケット通信手段は、入力手段においてユーザによる予約リスト取得要求が入力されたときに、カラオケ装置との間でソケットコネクトを行い、ｈｔｔｐ通信手段は、カラオケ装置との間でソケットコネクトが行われた後に、予約リスト取得要求に関するｈｔｔｐリクエストをカラオケ装置へ送信する。
また、カラオケ装置が備える通知手段は、リクエスト装置との間にソケットコネクトがあり、かつ、予約リストの内容に変更が生じた場合、予約リストの内容に変更が生じた旨を、登録手段によってメモリに登録されているシリアルナンバーに該当の各リクエスト装置へ通知する。

このような構成を有するカラオケシステムによれば、複数台のリクエスト装置において自由にカラオケ演奏曲の予約がなされても、各リクエスト装置から予約リスト取得要求があれば、その時点でカラオケ装置が記憶している予約リストをリクエスト装置へ閲覧可能に配信することができる。したがって、各リクエスト装置は、自装置以外のリクエスト装置から予約された内容も含めた適切な予約リストを自装置にて表示することができる。

また、カラオケ演奏対象となったために該当するカラオケ演奏曲に予約情報が予約リストから削除されたり、リクエスト装置から予約リストの編集要求があって編集がなされ、予約リストの内容に変更が生じた場合には、その旨がカラオケ装置から各リクエスト装置へ通知される。その通知を受けた各リクエスト装置では、予約リスト取得要求をカラオケ装置へ送信するため、その結果として、変更後の予約リストを各リクエスト装置にて表示させることができる。

このように、１台のカラオケ装置に対して複数台のリクエスト装置を準備していながら、予約リストの一覧表示や編集を各リクエスト装置にて適切に行うことができるのである。

なお、カラオケ装置の通知手段は、予約リスト記憶手段が記憶する予約リストの内容に変更が生じた旨を、ソケット通信によって各リクエスト装置へ通知する。本カラオケシステムの場合、予約リストの内容に変更が生じた場合、変更後の予約リストを各リクエスト装置へ配信するのではなく、「予約リストの内容に変更が生じた旨」をソケット通信手段を介して各リクエスト装置へ通知している。その通知を受けた各リクエスト装置がｈｔｔｐ通信を介して個別にカラオケ装置へ予約リストの取得要求をし、その結果として取得した予約リストを各リクエスト装置にて表示するようにした。このようなシステムであるため、ソケット通信によって通知することが好ましい。

また、リクエスト装置からだけでなく、カラオケ装置においても予約や編集ができるようにしてもよい。その場合には、請求項２に示すように、カラオケ装置が、リクエスト装置を介さずにユーザからの操作によって予約関連指示を受け付ける操作受付手段（１８）を備える。そして、カラオケ装置の予約リスト制御手段は、操作受付手段が受け付けた予約関連指示についても、受付手段が受け付けた予約関連指示と同じ対応をする。

つまり、操作受付手段が受け付けた予約関連指示がカラオケ演奏曲の新規の予約指示であった場合には予約リストへ新規に予約情報を登録させ、操作受付手段が受け付けた予約関連指示が予約曲の削除や予約順の移動などの編集指示であった場合には予約リストを編集するのである。

このようにクエスト装置を介さずにユーザからの操作によってなされた予約関連指示に対応した予約リストに関しても各リクエスト装置にて、適切に表示することができる。

以下、本発明の一実施形態を図面に基づいて説明する。
［カラオケシステムの構成の説明］
図１はカラオケシステムの概略構成を示す説明図、図２はカラオケ装置４及びリクエスト装置５ａ，５ｂ…の内部構成を示すブロック図である。

［概略構成の説明］
図１及び図２に示すように、カラオケシステムは、カラオケ店等の各カラオケルームに設置されるカラオケ装置４と、そのカラオケ装置４におけるカラオケ演奏曲の予約をユーザが行うため、ユーザによって操作される複数台のリクエスト装置５ａ，５ｂ…を備えている。単にリクエスト装置と総称する場合にはリクエスト装置５ａ，５ｂ…と記載し、リクエスト装置同士を区別する場合には、リクエスト装置（Ａ）５ａ、リクエスト装置（Ｂ）５ｂ、…と記載する。

カラオケ装置４は、２種類のアプリケーション、すなわちカラオケアプリケーション処理機能とＷｅｂサーバ処理機能とを有している。一方、リクエスト装置５ａ，５ｂ…は、２種類のアプリケーション、すなわちカラオケアプリケーション処理機能とＷｅｂブラウザ処理機能とを有している。なお、以下の説明においては、カラオケアプリケーション処理機能の方を単に「アプリケーション（あるいはアプリ）」と称し、他方のアプリケーションであるＷｅｂサーバ処理機能、Ｗｅｂブラウザ処理機能については、「Ｗｅｂサーバ」、「Ｗｅｂブラウザ」と称すこととする。

アプリケーションは、カラオケ演奏に関する処理であり、カラオケ装置４側においては例えば新規の予約追加を受け付けて予約リストを作成したり、予約リストの編集指示（例えば予約曲の削除や予約順番の入れ替えなど）を受けて編集を行ったり、予約リストの予約順番に従ってカラオケ演奏を実行する処理などを行う。一方、リクエスト装置５ａ，５ｂ…でのアプリケーションは、ユーザからのリクエストを受け付けてカラオケ装置４へ送信したり、ユーザからの予約リストの編集指示を受け付けてカラオケ装置４へ編集指示を送信したりする処理などを行う。

また、カラオケ装置４のＷｅｂサーバは、リクエスト装置５ａ，５ｂ…からの要求に応じて、予約リストの配信・更新などの処理を行うためのものであり、一方、リクエスト装置５ａ，５ｂ…のＷｅｂブラウザは、カラオケ装置４から受信したＷｅｂページを閲覧するためのものである。

これらカラオケ装置４におけるアプリケーションとリクエスト装置５ａ，５ｂ…におけるアプリケーションとの間は、ソケット通信（以下、通信Ａとも記載することがある。）によって実行される。

また、カラオケ装置４におけるＷｅｂサーバとリクエスト装置５ａ，５ｂ…におけるＷｅｂブラウザとの間は、ｈｔｔｐ通信（以下、通信Ｂとも記載することがある。）によって実行される。リクエスト装置５ａ，５ｂ…におけるＷｅｂブラウザからカラオケ装置４におけるＷｅｂサーバへは「ｈｔｔｐリクエスト」が送信され、それに対する返信としてカラオケ装置４におけるＷｅｂサーバからリクエスト装置５ａ，５ｂ…におけるＷｅｂブラウザへは「ｈｔｔｐレスポンス」が送信される。

なお、図１ではアプリケーション間あるいはＷｅｂサーバとＷｅｂブラウザとの間に直接矢印を記載しているが、実際にはカラオケ装置４とリクエスト装置５ａ，５ｂ…とは直接通信はしていない。カラオケ装置４はカラオケ店側のＬＡＮ１００に接続されており、このＬＡＮ１００に無線ＬＡＮ用のアクセスポイント１１０も接続されている。リクエスト装置５ａ，５ｂ…はこのアクセスポイント１１０と通信可能に構成されており。アクセスポイント１１０及びＬＡＮ１００を介してカラオケ装置４とリクエスト装置５ａ，５ｂ…とが通信を行う。

また、これらカラオケ装置４におけるアプリケーションとＷｅｂサーバとの間、及びリクエスト装置５ａ，５ｂ…におけるアプリケーションとＷｅｂブラウザとの間は、ＣＧＩを用いたアプリケーション（タスク）間通信を行う。

［カラオケ装置４の構成の説明］
図２はカラオケ装置４及びリクエスト装置５ａ，５ｂ…のより具体的な構成を示すブロック図である。

カラオケ装置４は、カラオケを利用するユーザから指定された楽曲のカラオケ演奏を行うためのものであり、図２に示すように、カラオケ装置４全体の作動を制御する制御部１２、カラオケ装置４をＬＡＮ１００に接続するためのインタフェース部１４、演奏楽曲の伴奏内容及び歌詞を示す楽曲データや映像データ等のコンテンツデータ、カラオケ装置４が作動するためのプログラム等を記憶するハードディスク（ＨＤＤ）１６、複数のキー・スイッチからなり、各種入力操作を受け付けるための操作部１８、リクエスト装置５ａ，５ｂ…や携帯電話６等から送信された赤外線信号を、赤外線通信規格（ＩｒＤＡ（登録商標））又はリクエスト装置５ａ，５ｂ…とカラオケ装置４との二者間において予め設定された通信条件に従って受信するための赤外線通信部２０、操作部１８からの信号を処理する操作処理部２２、マイクロフォン２６、ＨＤＤ１６に記憶された演奏データ（ＭＩＤＩデータ）に基づく演奏再生を行うＭＩＤＩ音源３０、ＭＩＤＩ音源３０から出力されたデジタル信号から演奏楽曲のオーディオ信号（音響、音声に関する信号）を生成し、生成されたオーディオ信号及びマイクロフォン２６から入力されたオーディオ信号を増幅してスピーカ２８へ出力する音声制御部２４、画像データを一時的に記憶するビデオＲＡＭ３２、ビデオＲＡＭ３２に記憶された画像データに基づく映像の再生を制御する映像再生部３４、映像再生部３４により再生される映像のモニタ３６での表示を制御する映像制御部３８、半導体素子を利用した書き換え可能な記憶媒体であるメモリ４０などを備えている。

また、制御部１２は、上述したカラオケアプリケーション処理機能やＷｅｂサーバ処理機能を実行する。なお、これらの処理についての詳細な説明は後述する。
［リクエスト装置５ａ，５ｂ…の構成の説明］
リクエスト装置５ａ，５ｂ…は、カラオケルーム内で利用されるためのものであり、演奏楽曲の予約等をするための操作をユーザから受け付け、その操作信号をカラオケ装置４ヘ送信する機能を有する。また、リクエスト装置５ａ，５ｂ…は、アクセスポイント１１０経由でＬＡＮ１００を介してカラオケ装置４とｈｔｔｐ通信によってアクセスし、カラオケ装置４（のＷｅｂサーバ）から受信したデータに基づいてＷｅｂページの閲覧・更新するための機能も有する。

具体的にリクエスト装置５ａ，５ｂ…は、図２に示すように、リクエスト装置５ａ，５ｂ…全体の作動を制御する制御部５２、赤外線通信規格（ＩｒＤＡ）又はリクエスト装置５ａ，５ｂ…とカラオケ装置４との二者間において予め設定された通信条件に従ってカラオケ装置４に赤外線信号を送信する赤外線通信部５４、リクエスト装置５ａ，５ｂ…が作動するためのプログラム等の各種情報を記憶するメモリ５６、表示部５８の表示領域に沿って設置されるタッチパネル及び複数のキー・スイッチからなり、ユーザからの各種入力操作を受け付けるための操作部６０、操作部６０からの信号を処理する操作処理部６２、画像データを一時的に記憶するビデオＲＡＭ６４、ビデオＲＡＭ６４に記憶された画像データの表示部５８での表示を制御する映像制御部６６、ＬＡＮ１００に接続されたアクセスポイントとの間で無線ＬＡＮ規格（例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ規格，ＨｏｍｅＲＦ規格，Ｂｌｕｅｔｏｏｔｈ（登録商標）規格など）に従った無線通信を行うための無線ＬＡＮ通信部６８などを備えている。

このうち、制御部５２は、ユーザから曲の予約をするための操作入力を受け付け、選択された曲の曲番号に、予約者（即ち、歌唱する人）のユーザＩＤを付加した予約データをカラオケ装置４へ送信する処理を実行する。また、制御部５２は、アクセスポイント１１０経由でＬＡＮ１００を介してカラオケ装置４へアクセスし、カラオケ装置４から受信したデータに基づいてＷｅｂページの閲覧・更新を行うための各種処理を実行する。

［その他の構成の説明］
上述したようにＬＡＮ１００にはアクセスポイント１１０が接続されている。このアクセスポイント１１０は、無線通信で端末間を接続するための電波中継機であり、複数の端末と同時に通信を行う機能を有する。リクエスト装置５ａ，５ｂ…とカラオケ装置４とは、このアクセスポイント１１０を中継することによって、ＬＡＮ１００を介して互いにデータ通信を行うことができる。

このＬＡＮ１００にはルータ１２０が接続されており、外部のインターネット（図示せず）と接続されている。そのため、カラオケ装置４は、このルータ１２０、そしてインターネットを経由して外部の集配信センタ（図示せず）との通信を行うことができるよう構成されている。集配信センタは、カラオケ曲などのコンテンツやカラオケアプリケーションの更新データなどをカラオケ装置４へ配信したり、カラオケ装置４から稼働ログを収集したりする。

［カラオケシステムの作動等］
［作動の概要］
まず、カラオケシステムの作動の概要を説明する。

本実施形態では、カラオケサービス提供者（カラオケ店舗）側からユーザにリクエスト装置５ａ，５ｂ…が貸与され、リクエスト装置５ａ，５ｂ…とカラオケ装置４との通信が可能となった時からカラオケサービスの提供が開始され、リクエスト装置５ａ，５ｂ…とカラオケ装置４との通信が不可能となったときにカラオケサービスの提供が終了する。

なお、以下、「リクエスト装置５ａ，５ｂ…とカラオケ装置４とを通信可能にする」ことを「リクエスト装置５ａ，５ｂ…をカラオケ装置４に『くくりつける』又は単に『くくりつけ』」と称す。

リクエスト装置５ａ，５ｂ…がユーザに貸与されると、まず、ユーザは指定されたカラオケ装置４とリクエスト装置５ａ，５ｂ…との通信確認を行い、リクエスト装置５ａ，５ｂ…をそのカラオケ装置４にくくりつける。このとき、くくりつけを指示する旨のコマンド及びリクエスト装置５ａ，５ｂ…の製造番号（シリアルナンバー）情報が、リクエスト装置５ａ，５ｂ…からカラオケ装置４へ送信される。なお、このシリアルナンバーはメモリ５６に格納されている。カラオケ装置４は、くくりつけ済みのリクエスト装置５ａ，５ｂ…のシリアルナンバーの一覧をメモリ４０に記憶する。

一方、リクエスト装置５ａ，５ｂ…からの通信確認を受けたカラオケ装置４は、リクエスト装置５ａ，５ｂ…に対してくくりつけられたカラオケ装置４が提供することができるサービスの種別、及びそのカラオケ装置４の製造番号（シリアルナンバー）を、リクエスト装置５ａ，５ｂ…へ送信する。したがって、リクエスト装置５ａ，５ｂ…も、自装置がくくりつけられているカラオケ装置４のシリアルナンバーをメモリ５６に記憶する。

このようにカラオケ装置４とのくくりつけが済んだリクエスト装置５ａ，５ｂ…を用いてユーザは、曲の予約や、予約曲の一覧表示、予約曲の編集（予約曲の削除や予約順番の変更など）を行うことができる。

リクエスト装置５ａ，５ｂ…では、操作部６０を介してユーザから曲の予約をするための操作入力を受け付けた場合、選択された曲の曲番号に、予約者のユーザＩＤを付加した予約データをカラオケ装置４へ送信する。この予約追加に係る処理に関しては後述する。

一方、カラオケ装置４ではリクエスト装置５ａ，５ｂ…から送信された予約データを受信し、それをメモリ４０の予約リストテーブルに登録していく。その予約リストテーブルの具体例を図３（ｂ）に示す。予約リストテーブルは、予約された曲毎に、インデックス番号・曲番号・曲タイトル・予約ユーザＩＤから構成されている。カラオケ演奏はインデックス番号が若い順番に行っていく。

また、リクエスト装置５ａ，５ｂ…では、操作部６０を介してユーザから予約曲の一覧表示や予約曲の編集をするための操作入力を受け付けた場合、アクセスポイント１１０経由でＬＡＮ１００を介してカラオケ装置４へアクセスし、カラオケ装置４から受信したデータに基づいてＷｅｂページの閲覧・更新を行うための各種処理を実行する。

なお、カラオケ装置４は、予約リストを閲覧中のリクエスト装置５ａ，５ｂ…のシリアルナンバーの一覧を、図３（ａ）に示すようにメモリ４０に記憶する。
それでは、予約曲の一覧表示や予約曲の編集に関する処理の詳細に関して、図４〜図６のフローチャート及び図７の通信シーケンス図を参照して説明する。

なお、以下の説明においては、まず図４〜図６のフローチャートそれぞれを参照して各処理を説明し、その後、図７の通信シーケンス図を参照してカラオケ装置４とリクエスト装置５ａ，５ｂ…との間のやりとりを説明する。

［リクエスト装置５ａ，５ｂ…における処理説明］
図４は、リクエスト装置５ａ，５ｂ…の制御部５２にて実行される「予約曲の一覧表示や予約曲の編集に関する処理」の手順を示すフローチャートである。

操作部６０を介してユーザから予約リストを表示する要求があったか否か判断する（Ｓ１０）。要求がなければ（Ｓ１０：ＮＯ）、Ｓ１０の処理を繰り返し実行し、要求があれば（Ｓ１０：ＹＥＳ）、Ｓ２０へ移行してソケットを作成する。つまり、自装置がくくりつけられているカラオケ装置４との間でソケット通信を行うために、該当するカラオケ装置４のソケット（ＩＰアドレスとポート番号を組み合わせネットワークアドレス）を作成するものである。

そして、ソケットコネクト（ソケット接続、ソケット通信のオープン）を行う（Ｓ２０）。ソケットコネクトがＯＫでなければ（Ｓ４０：ＮＯ）、Ｓ１０へ戻るが、ＯＫならば（Ｓ４０：ＹＥＳ）、Ｓ５０へ移行する。

Ｓ５０では、メモリ５６に格納されている（自リクエスト装置の）シリアルナンバーを取得する。そして、カラオケ装置４に対して予約リストの取得を要求するためのｈｔｔｐリクエストを行う。この場合のｈｔｔｐリクエストをケース１と称し、例えば「ｈｔｔｐ：／／ｓｏｎｇ＿ｌｉｓｔ」といったパラメータに（自リクエスト装置の）シリアルナンバーをつけたものとなる。

続いて、カラオケ装置４からのｈｔｔｐレスポンスがあるか否か判断し（Ｓ７０）。のｈｔｔｐレスポンスがなければ（ＮＯ）、Ｓ１０へ戻るが、のｈｔｔｐレスポンスがあれば（Ｓ７０：ＹＥＳ）、Ｓ８０へ移行する。Ｓ８０では予約リストを表示部５８に表示する。この予約リストの表示は、Ｗｅｂブラウザによって行う。

次に、操作部６０を介してユーザから予約の追加、あるいは予約内容を編集する要求があったか否か判断する（Ｓ９０）。予約の追加とは、新規にカラオケ曲を予約することであり、予約内容の編集とは、例えば予約曲の削除や予約順番の入れ替えなどである。

予約追加／編集要求がなければ（Ｓ９０：ＮＯ）、Ｓ１００へ移行し、カラオケ装置４からの予約リスト変更通知があるか否か判断する。予約リスト変更通知がなければ（Ｓ１００：ＮＯ）、Ｓ１１０へ移行し、操作部６０を介してユーザから予約リスト表示の終了指示があるか否か判断する。予約リスト表示の終了指示がなければ（Ｓ１１０：ＮＯ）、Ｓ９０へ移行し、終了指示があれば（Ｓ１１０：ＹＥＳ）、Ｓ１０へ戻る。

一方、Ｓ９０にて肯定判断、つまり予約追加／編集要求があった場合には、Ｓ１２０へ移行し、カラオケ装置４に対して予約リストの追加／編集を要求するためのｈｔｔｐリクエストを行う。

例えば、予約リストからインデックス番号３番の曲を削除する場合のｈｔｔｐリクエストをケース２と称し、例えば「ｈｔｔｐ：／／ｓｏｎｇ＿ｌｉｓｔ？ｉｎｄｅｘ＝３＆ｊｏｂ＝０」といったパラメータに（自リクエスト装置の）シリアルナンバーをつけたものとなる。また、予約リストからインデックス番号４番の曲を１曲目に移動する場合のｈｔｔｐリクエストをケース３と称し、例えば「ｈｔｔｐ：／／ｓｏｎｇ＿ｌｉｓｔ？ｉｎｄｅｘ＝４＆ｊｏｂ＝１」といったパラメータに（自リクエスト装置の）シリアルナンバーをつけたものとなる。

また、Ｓ１００にて肯定判断、つまりカラオケ装置４からの予約リスト変更通知があれば、Ｓ６０へ移行して、カラオケ装置４に対して予約リストの取得を要求するためのｈｔｔｐリクエストを行う。これが、後述する予約リストのリロード制御に相当する。

［カラオケ装置４における処理説明］
図５及び図６は、カラオケ装置４のＣＰＵ１４にて実行される「予約曲の一覧表示や予約曲の編集に関する処理」の手順を示すフローチャートであり、図５はＷｅｂサーバ処理に関する処理を示しており、図６はカラオケアプリケーションに関する処理を示している。

まず、図５に示すＷｅｂサーバ処理について説明する。
Ｗｅｂサーバを起動し（Ｓ２１０）、リクエスト装置５ａ，５ｂ…からｈｔｔｐリクエストがあるか否か判断する（Ｓ２２０）。ｈｔｔｐリクエストがなければ（Ｓ２２０：ＮＯ）、Ｓ２２０の処理を繰り返し、ｈｔｔｐリクエストがあれば（Ｓ２２０：ＹＥＳ）、Ｓ２２５へ移行し、予約関連のリクエストか否か判断する。そして、予約関連のリクエスト装置であれば（Ｓ２２５：ＹＥＳ）、Ｓ２３０へ移行し、予約関連のＣＧＩ処理を実行する。

このＳ２３０での予約関連ＣＧＩ処理の詳細を、図５（ｂ）を参照して説明する。
まず、図５（ａ）のＳ２２０で肯定判断する原因となったｈｔｔｐリクエストの送信元であるリクエスト装置５ａ，５ｂ…のシリアルナンバーを登録する（Ｓ２３１）。そして、予約リストテーブルを読み込む（Ｓ２３２）。予約リストテーブルの具体例は、図３（ｂ）に示してある。

次に、ｈｔｔｐリクエストに追加／編集パラメータが含まれているか否か判断する（Ｓ２３３）。追加／編集パラメータが含まれていれば（Ｓ２３３：ＹＥＳ）、その追加／編集パラメータに応じて予約リストを追加／編集し（Ｓ２３４）、追加／編集後の予約リストをｈｔｍｌ形式に書き出す（Ｓ２３５）。一方、追加／編集パラメータが含まれていなければ（Ｓ２３３：ＮＯ）、Ｓ２３２で読み出した予約リストをｈｔｍｌ形式に書き出す（Ｓ２３５）。

ここで、Ｓ２３４での追加／編集に関してさらに説明する。例えば図３（ｂ）中の上段に示すように、４曲の予約がなされている一覧表示状態（ケース１）で、その予約リストからインデックス番号３番の曲を削除するｈｔｔｐリクエスト（ケース２）がなされたとする。その場合には、図３（ｂ）中の中段に示すようになる。また、同様に４曲の予約がなされている一覧表示状態（ケース１）で、その予約リストからインデックス番号４番の曲を１曲目に移動するｈｔｔｐリクエスト（ケース３）がなされたとする。その場合には、図３（ｂ）中の下段に示すようになる。

Ｓ２３５の処理後は、図５（ａ）のＳ２４０へ移行する。Ｓ２４０では、ｈｔｔｐレスポンスを返信する。その後は、Ｓ２２０へ戻る。
一方、Ｓ２２５で否定判断、つまり予約関連のリクエストでなかった場合には、Ｓ２５０へ移行し、ｈｔｔｐリクエストの送信元であるリクエスト装置５ａ，５ｂ…のシリアルナンバーが図３（ａ）の予約リスト閲覧中のリクエスト装置のシリアル一覧に存在するか否か判断する。そして、シリアル一覧に存在すれば（Ｓ２５０：ＹＥＳ）、そのシリアルナンバーを図３（ａ）のシリアル一覧から削除する（Ｓ２６０）。そして、Ｓ２７０へ移行し、要求（つまり、予約関連以外の要求）に対応する処理を行う。シリアル一覧に存在しなければ（Ｓ２５０：ＮＯ）、Ｓ２６０の処理を実行することなくＳ２７０へ移行する。Ｓ２７０の処理後は、Ｓ２４０へ移行する。

次に、図６に示すカラオケアプリケーション処理について説明する。
まず、ソケットを作成し（Ｓ３１０）、ソケットバインドを行う（Ｓ３２０）。このソケットバインドは、アプリケーションに対応したポートをソケットにバインドする処理である。

リクエスト装置５ａ，５ｂ…からソケット通信によるコネクトがあるか否か判断し（Ｓ３３０）、コネクトがあれば（Ｓ３３０：ＹＥＳ）、Ｓ３４０へ移行する。
Ｓ３４０では予約リストに変更があるか否か判断し、予約リストに変更があれば（Ｓ３４０：ＹＥＳ）、予約リストを閲覧中のリクエスト装置５ａ，５ｂ…のシリアルナンバーの一覧をメモリ４０から取得する（Ｓ３５０）。そして、シリアルカウンタを初期値１にセットし（Ｓ３６０）、そのシリアルカウンタの番号に対応するシリアルナンバーのリクエスト装置５ａ，５ｂ…へソケット通信で予約リストの変更通知を送信する（Ｓ３７０）。最後のシリアルナンバーまで処理したか否か判断し（Ｓ３８０）、処理していなければ（Ｓ３８０：ＮＯ）、シリアルカウンタをインクリメント（＋１）して（Ｓ３９０）、Ｓ３７０へ戻る。最後のシリアルナンバーまで処理したら（Ｓ３８０：ＹＥＳ）、本処理を終了する。

［カラオケ装置４とリクエスト装置５ａ，５ｂ…との間のやりとり］
図４〜図６のフローチャートを参照した説明は、リクエスト装置５ａ，５ｂ…及びカラオケ装置４それぞれで実行される処理であったが、両者間でどのようなやりとりがなされるかが重要である。そこで、図７の通信シーケンス図を参照して、その点を詳しく説明する。

ここでは、カラオケ装置２に対して２台のリクエスト装置（Ａ）５ａ及びリクエスト装置（Ｂ）５ｂがくくりつけられた状態で、まず、ユーザ（Ａ）がリクエスト装置（Ａ）５ａを用いて予約リストの表示要求をし、その後、ユーザ（Ｂ）がリクエスト装置（Ｂ）５ｂを用いて予約リストの表示要求をし、さらにユーザ（Ｂ）はリクエスト装置（Ｂ）５ｂを用いて、予約内容の編集を要求したケースを想定して話を進める。

（１）リクエスト装置（Ａ）５ａでの予約リスト表示要求操作に対応するやりとり
リクエスト装置（Ａ）５ａの操作部６０を介してユーザ（Ａ）から予約リストを表示する要求操作がなされると、リクエスト装置（Ａ）５ａのアプリケーションからカラオケ装置４のアプリケーションに対してソケット通信のコネクトが行われる。それに対してカラオケ装置４からリクエスト装置（Ａ）５ａに対してコネクトＯＫの返信がなされると、リクエスト装置（Ａ）５ａのアプリケーションはＷｅｂブラウザを起動する。これはＣＧＩ［通信Ｃ］によって行われる。

起動されたリクエスト装置（Ａ）５ａのＷｅｂブラウザは、カラオケ装置４のＷｅｂサーバに対して予約リストの取得要求を行う。これはｈｔｔｐ通信［通信Ｂ］によって行われる。

この予約リスト取得要求に対してカラオケ装置４では、Ｗｅｂサーバからアプリケーションへ予約リストの取得要求がなされ、アプリケーションからＷｅｂサーバへ予約リスト情報が渡される。これはＣＧＩ［通信Ｃ］によって行われ、図３（ｂ）に示すような予約リスト情報が渡される。そして、カラオケ装置４のＷｅｂサーバは、リクエスト装置（Ａ）５ａのＷｅｂブラウザに対してｈｔｍｌ形式で書き出した予約リストを送信する。

このようなやりとりによって、予約リストの表示を要求したリクエスト装置（Ａ）５ａのユーザは、リクエスト装置（Ａ）５ａの表示部５８に表示された予約リストを見ることができる。

（２）リクエスト装置（Ｂ）５ｂでの予約リスト表示要求操作に対応するやりとり
リクエスト装置（Ｂ）５ｂの操作部６０を介してユーザ（Ｂ）から予約リストを表示する要求操作がなされると、リクエスト装置（Ｂ）５ｂのアプリケーションからカラオケ装置４のアプリケーションに対してソケット通信のコネクトが行われる。それに対してカラオケ装置４からリクエスト装置（Ｂ）５ｂに対してコネクトＯＫの返信がなされると、リクエスト装置（Ｂ）５ｂのアプリケーションはＷｅｂブラウザを起動する。

起動されたリクエスト装置（Ｂ）５ＢのＷｅｂブラウザは、カラオケ装置４のＷｅｂサーバに対して予約リストの取得要求を行う。
この予約リスト取得要求に対してカラオケ装置４では、Ｗｅｂサーバからアプリケーションへ予約リストの取得要求がなされ、アプリケーションからＷｅｂサーバへ予約リスト情報が渡される。そして、カラオケ装置４のＷｅｂサーバは、リクエスト装置（Ｂ）５ｂのＷｅｂブラウザに対してｈｔｍｌ形式で書き出した予約リストを送信する。

このようなやりとりによって、予約リストの表示を要求したリクエスト装置（Ｂ）５ｂのユーザは、リクエスト装置（Ｂ）５ｂの表示部５８に表示された予約リストを見ることができる。

この時点で、カラオケ装置４のメモリ４０には、予約リスト閲覧中のリクエスト装置のシリアルナンバー一覧として、図３（ａ）に示すように、リクエスト装置（Ａ）５ａ及びリクエスト装置（Ｂ）５ｂの２台分のシリアルナンバーが記憶されている。

（３）リクエスト装置（Ｂ）５ｂで予約追加／編集操作に対応するやりとり
続いて、リクエスト装置（Ｂ）５ｂの操作部６０を介してユーザ（Ｂ）から予約追加や予約内容を編集する操作がなされると、リクエスト装置（Ｂ）５ｂのアプリケーションはＷｅｂブラウザに対して予約追加／編集要求を出す。これはＣＧＩ［通信Ｃ］によって行われる。そして、リクエスト装置（Ｂ）５ＢのＷｅｂブラウザは、カラオケ装置４のＷｅｂサーバに対して予約リストの追加／編集要求を行う。

この予約リスト追加／編集要求に対してカラオケ装置４では、Ｗｅｂサーバからアプリケーションへ予約リストの追加／編集を要求する。カラオケ装置４のアプリケーションは、予約リストの追加／編集処理を実行する。この追加／編集処理については上述したが、簡単に繰り返しておく。例えば図３（ｂ）中の上段に示すように、４曲の予約がなされている一覧表示状態（ケース１）で、その予約リストからインデックス番号３番の曲を削除する追加／編集要求があった場合には、図３（ｂ）中の中段に示すようになる。また、同様に４曲の予約がなされている一覧表示状態（ケース１）で、その予約リストからインデックス番号４番の曲を１曲目に移動する追加／編集要求があった場合には、図３（ｂ）中の下段に示すようになる。

このようにして追加／編集処理が完了すると、カラオケ装置４のアプリケーションは、リクエスト装置（Ａ）５ａ及びリクエスト装置（Ｂ）５ｂのアプリケーションに対して、ソケット通信［通信Ａ］によって予約リストの変更通知を行う。

（４）変更通知を受けたリクエスト装置（Ａ）５ａ及びリクエスト装置（Ｂ）５ｂとカラオケ装置４とのやりとり
予約リストの変更通知を受けたリクエスト装置（Ａ）５ａのアプリケーションは、Ｗｅｂブラウザに対して予約リストのリロード要求を出す。これはＣＧＩ［通信Ｃ］によって行われる。リロード要求を受けたリクエスト装置（Ａ）５ａのＷｅｂブラウザは、カラオケ装置４のＷｅｂサーバに対して予約リストの取得要求を行う。この予約リスト取得要求に対してカラオケ装置４では、Ｗｅｂサーバからアプリケーションへ予約リストの取得要求がなされ、アプリケーションからＷｅｂサーバへ予約リスト情報が渡される。そして、カラオケ装置４のＷｅｂサーバは、リクエスト装置（Ａ）５ａのＷｅｂブラウザに対してｈｔｍｌ形式で書き出した予約リストを送信する。

同様に、予約リストの変更通知を受けたリクエスト装置（Ｂ）５ｂのアプリケーションは、Ｗｅｂブラウザに対して予約リストのリロード要求を出し、リロード要求を受けたリクエスト装置（Ｂ）５ｂのＷｅｂブラウザは、カラオケ装置４のＷｅｂサーバに対して予約リストの取得要求を行う。カラオケ装置４では、Ｗｅｂサーバからアプリケーションへ予約リストの取得要求がなされ、アプリケーションからＷｅｂサーバへ予約リスト情報が渡される。そして、カラオケ装置４のＷｅｂサーバは、リクエスト装置（Ｂ）５ｂのＷｅｂブラウザに対してｈｔｍｌ形式で書き出した予約リストを送信する。

このようなやりとりによって、予約編集を要求したリクエスト装置（Ｂ）５ｂだけでなく、同じカラオケ装置４にくくりつけられているリクエスト装置（Ａ）５ａも含め、編集後の予約リストを表示することができる。

なお、例えばリクエスト装置（Ａ）５ａにおいて、ユーザから予約リスト関連以外の操作がなされた場合には、リクエスト装置（Ａ）５ａのアプリケーションは、Ｗｅｂブラウザに対して、「予約リスト関連以外の」要求を出す。その要求を受けたリクエスト装置（Ａ）５ａのＷｅｂブラウザは、カラオケ装置４のＷｅｂサーバに対して「予約リスト関連以外の」要求を行う。この予約リスト取得要求に対してカラオケ装置４では、対応する処理を行うと共に、Ｗｅｂサーバからアプリケーションへ削除要求を行う。アプリケーションにおいては、ｈｔｔｐリクエストの送信元であるリクエスト装置（Ａ）５ａのシリアルナンバーを、図３（ａ）の予約リスト閲覧中のリクエスト装置のシリアル一覧から削除する。

上記説明は、カラオケ装置２に対して２台のリクエスト装置（Ａ）５ａ及びリクエスト装置（Ｂ）５ｂがくくりつけられた状態を前提として説明したが、３台以上のリクエスト装置５ａ，５ｂ…がカラオケ装置４にくくりつけられた場合であっても同様のやりとりがなされる。

［効果］
上記実施形態のカラオケシステムによれば、次のような効果を奏する。
１台のカラオケ装置４に複数台のリクエスト装置５ａ，５ｂ…がくくりつけられている場合に、各リクエスト装置５ａ，５ｂ…において自由にカラオケ演奏曲の予約がなされても、各リクエスト装置５ａ，５ｂ…から予約リスト取得要求があれば、その時点でカラオケ装置４が記憶している予約リストを、各リクエスト装置５ａ，５ｂ…へ閲覧可能に配信することができる。したがって、各リクエスト装置５ａ，５ｂ…は、他のリクエスト装置５ａ，５ｂ…から予約された内容も含めた適切な予約リストを自装置にて表示することができる。

また、他のリクエスト装置５ａ，５ｂ…から新規に予約がなされたり、他のリクエスト装置５ａ，５ｂ…から予約リストの編集（例えば削除や予約順の変更など）がなされた場合には、予約リストの内容に変更が生じる。その場合には、変更された時点で、変更通知がカラオケ装置４から「予約リストを閲覧中の」各リクエスト装置５ａ，５ｂ…へ通知される。その通知を受けた各リクエスト装置５ａ，５ｂ…では、予約リスト取得要求をカラオケ装置４へ送信するため、その結果として、変更後の予約リストを遅滞なく各リクエスト装置５ａ，５ｂ…にて表示させることができる。

このように、１台のカラオケ装置４に対して複数台のリクエスト装置５ａ，５ｂ…を準備していながら、予約リストの一覧表示や編集を各リクエスト装置にて適切に行うことができる。

［その他］
以上、本発明の実施形態について説明したが、本発明の実施形態は上記の実施形態に何ら限定されるものではなく、本発明の技術的範囲に属する限り様々な態様にて実施することが可能である。

（１）上記実施形態では、リクエスト装置５ａ，５ｂ…からのみ予約あるいは予約編集を受け付けた場合を前提として説明した、しかし、カラオケ装置４の操作部１８を介しても予約や編集を受け付けることはできる。このように、リクエスト装置５ａ，５ｂ…からだけでなく、カラオケ装置４の操作部１８を介しても予約や編集を受け付けた場合であっても、上記実施形態と同様に、予約リストの内容に変更があれば、上記実施形態と同様の対処をすればよい。

つまり、操作部１８を介してユーザから受け付けた指示がカラオケ演奏曲の新規の予約指示であったり編集指示であった場合には予約リストの内容が変更される。したがって、その場合には、リクエスト装置５ａ，５ｂ…に対して予約リストの変更通知を送り、各リクエスト装置５ａ，５ｂ…から予約リストのリロード要求を出させるのである。

このようにすれば、リクエスト装置５ａ，５ｂ…を介さずにカラオケ装置４に対してユーザから新規予約や予約内容の編集がなされても、それに対応した予約リストを各リクエスト装置５ａ，５ｂ…にて、適切に表示させることができる。

（２）上記実施形態では、予約リストの編集だけでなく新規予約に関してもｈｔｔｐ通信［通信Ｂ］によって行ったが、新規予約に関してはソケット通信［通信Ａ］によって行っても良い。

ｈｔｔｐ通信の問題は基本的にリクエストがない限りレスポンスがないことである。 ソケット通信は双方向どちらからでも一方的に情報を任意のタイミングで送ることができる。つまり、ｈｔｔｐ通信と比較して応答が速いという効果がある。単に曲の予約だけを行うのであれば、ソケット通信の方がアプリケーションとしても軽いため、応答が速くなる。

一方、上記実施形態のように、新規予約に関してもｈｔｔｐ通信によって実現する場合には、予約後の予約リストをｈｔｍｌ形式の画面をリクエスト装置５ａ，５ｂ…へ返すことができる。また、ｈｔｔｐ通信はソケット通信に比べて伝送できる情報量が大きいので、予約時に曲番号だけでなく、拡張した情報（例えば曲の感想・評価などの文書を利用者が記述したもの）を曲番号に付随させてから、リクエスト装置５ａ，５ｂ…からカラオケ装置４へ送信することができる。つまり、ｈｔｔｐ通信はソケット通信を用いた場合よりも、利用者に対して「より高級なサービス」を提供できる、という効果がある。

（３）新規予約に関しては赤外線通信によって実現してもよい。つまり、リクエスト装置５ａ，５ｂ…において操作部６０を介してユーザから曲の予約をするための操作入力を受け付けた場合、選択された曲の曲番号に予約者のユーザＩＤを付加した予約データを、赤外線通信部５４を介してカラオケ装置４へ送信するのである。一方、カラオケ装置４では赤外線通信部２０を介してリクエスト装置５ａ，５ｂ…から送信された予約データを受信し、それをメモリ４０の予約リストテーブルに登録していく。

なお、ソケット通信との併用も考えられる。つまり、新規予約に関してはソケット通信によって行うことを原則とするが、ソケット通信が失敗した場合には、自動的に赤外線通信によって新規予約を行うようにしてもよい。
（４）上記実施形態では、予約リストの編集（例えば削除や予約順の変更など）がなされた場合に、変更通知がカラオケ装置４から「予約リストを閲覧中の」各リクエスト装置５ａ，５ｂ…へ通知され、その通知を受けた各リクエスト装置５ａ，５ｂ…から予約リストのリロード要求を出させるようにした。このような対応は、予約リストに関連する処理機能以外の機能に対応しても同様に実現可能であり、そのようにすることで、カラオケ装置４は、同じ機能を利用しているリクエスト装置５ａ，５ｂ…に対して最新の情報を提供することができる。

実施形態のカラオケシステムの概略構成を示すブロック図である。 カラオケ店等のカラオケルーム内に設置されているカラオケ装置４及びリクエスト装置５ａ，５ｂ…のより具体的な構成を示すブロック図である。 カラオケ装置のメモリ内に記憶される「予約リストを閲覧中のリクエスト装置の一覧」や「予約リストテーブル」の説明図である。 リクエスト装置にて実行される予約曲の一覧表示や予約曲の編集に関する処理を示すフローチャートである。 カラオケ装置にて実行されるＷｅｂサーバ処理を示すフローチャートである。 カラオケ装置にて実行されるカラオケアプリケーション処理を示すフローチャートである。 リクエスト装置とカラオケ装置との間で行われるやりとりを示す通信シーケンス図である。

４…カラオケ装置、５ａ，５ｂ…リクエスト装置、１２…制御部、１４…インタフェース部、１６…ハードディスク（ＨＤＤ）、１８…操作部、２０…赤外線通信部、２２…操作処理部、２４…音声制御部、２６…マイクロフォン、２８…スピーカ、３０…ＭＩＤＩ音源、３２…ビデオＲＡＭ、３４…映像再生部、３６…モニタ、３８…映像制御部、４０…メモリ、５２…制御部、５４…赤外線通信部、５６…メモリ、５８…表示部、６０…操作部、６２…操作処理部、６４…ビデオＲＡＭ、６６…映像制御部、６８…無線ＬＡＮ通信部、１００…ＬＡＮ、１１０…アクセスポイント、１２０…ルータ。

Claims (2)

1. リクエスト装置からカラオケ演奏に関する指示を受け付け、その受け付けた指示に応じてカラオケ演奏に関する処理を行うカラオケアプリケーションから情報を取得し、その取得した情報を前記リクエスト装置に対して出力するＷｅｂサーバを備えるカラオケ装置と、前記カラオケ装置に対する操作入力をユーザから受け付ける複数台のリクエスト装置と、がｈｔｔｐ通信によって通信可能に接続されたカラオケシステムであって、
   前記カラオケ装置は、
   一つ以上のカラオケ演奏曲を記憶する演奏曲記憶手段と、
   演奏順が区別可能なカラオケ演奏曲の予約リストを記憶可能な予約リスト記憶手段と、
   前記予約リスト記憶手段が記憶する前記予約リストに基づいて前記演奏曲記憶手段からカラオケ演奏曲を読み出してカラオケ演奏するカラオケ演奏手段と、
   を備え、
   前記カラオケ装置が備えるＷｅｂサーバは、
   前記リクエスト装置からカラオケ演奏曲の予約に関する指示である予約関連指示や予約リスト取得要求と送信元のリクエスト装置のシリアルナンバーとを含むｈｔｔｐリクエストを受け付ける受付手段と、
   前記受付手段によって受け付けた予約リスト取得要求に応じて、前記予約リストを前記カラオケアプリケーションから取得し、その取得した予約リストをｈｔｔｐレスポンスとして前記リクエスト装置へ閲覧可能に配信する一方、前記受付手段が受け付けた予約関連指示で示される前記予約リストの追加／編集処理を前記カラオケアプリケーションに実行させ、その追加／編集処理がなされた前記予約リストをｈｔｔｐレスポンスとして前記リクエスト装置へ閲覧可能に配信する配信手段と、
   を備え、
   前記カラオケ装置が備えるカラオケアプリケーションは、
   前記受付手段によって予約関連指示や予約リスト取得要求に関するｈｔｔｐリクエストを受け付けた場合、そのｈｔｔｐリクエストの送信元であるリクエスト装置のシリアルナンバーをメモリに登録する登録手段と、
   前記受付手段が受け付けた予約関連指示がカラオケ演奏曲の新規の予約指示であった場合には、前記予約リスト記憶手段が記憶する前記予約リストへ新規に予約情報を登録し、前記受付手段が受け付けた予約関連指示が予約曲の削除や予約順の移動などの編集指示であった場合には、前記予約リスト記憶手段が記憶する前記予約リストを編集し、前記カラオケ演奏手段による演奏対象となった場合には、該当するカラオケ演奏曲の予約情報を前記予約リスト記憶手段が記憶する前記予約リストから削除する予約リスト制御手段と、
   前記予約リスト記憶手段が記憶する前記予約リストの内容に変更が生じた場合、その旨をソケット通信によって前記各リクエスト装置へ通知する通知手段と、
   を備え、
   前記リクエスト装置は、
   ユーザによる前記予約関連指示や前記予約リスト取得要求を入力する入力手段と、
   前記入力手段を介して入力された前記予約関連指示や前記予約リスト取得要求と自リクエスト装置のシリアルナンバーとを含むｈｔｔｐリクエストを前記カラオケ装置へ送信すると共に、前記カラオケ装置の配信手段によるｈｔｔｐレスポンスを受信するｈｔｔｐ通信手段と、
   前記カラオケ装置との間でソケットコネクトを行うと共に、前記カラオケ装置の通知手段からのソケット通信による通知を受信するソケット通信手段と、
   前記カラオケ装置の配信手段によってｈｔｔｐレスポンスとして配信された予約リストを、Ｗｅｂブラウザによって表示手段に表示させる表示制御手段と、
   前記ソケット通信手段を介して前記カラオケ装置の通知手段から予約リストの内容変更通知を受信した場合、前記ｈｔｔｐ通信手段を介して前記予約リスト取得要求を前記カラオケ装置へ送信させるリロード制御手段と、
   を備え、
   前記リクエスト装置が備えるソケット通信手段は、前記入力手段においてユーザによる前記予約リスト取得要求が入力されたときに、前記カラオケ装置との間でソケットコネクトを行い、
   前記リクエスト装置が備えるｈｔｔｐ通信手段は、前記カラオケ装置との間でソケットコネクトが行われた後に、前記予約リスト取得要求に関するｈｔｔｐリクエストを前記カラオケ装置へ送信し、
   前記カラオケ装置が備える通知手段は、前記リクエスト装置との間にソケットコネクトがあり、かつ、前記予約リストの内容に変更が生じた場合、前記予約リストの内容に変更が生じた旨を、前記登録手段によってメモリに登録されているシリアルナンバーに該当の各リクエスト装置へ通知すること
   を特徴とするカラオケシステム。
2. 請求項１に記載のカラオケシステムにおいて、
   前記カラオケ装置は、前記リクエスト装置を介さずにユーザからの操作によって予約関連指示を受け付ける操作受付手段を備え、
   前記予約リスト制御手段は、前記操作受付手段が受け付けた予約関連指示についても、前記受付手段が受け付けた予約関連指示と同じ対応をすること
   を特徴とするカラオケシステム。