(57)【特許請求の範囲】
【請求項１】
ホスト装置と複数のカラオケ演奏端末とが通信手段を介して接続される通信カラオケシステムであって、
前記カラオケ演奏端末の各々は、
前記ホスト装置から配信された楽曲データを記憶する読み書き可能な記憶手段と、
リクエストされた曲目に対応する前記楽曲データを前記記憶手段から読み出し、当該楽曲データに基づく前記曲目の演奏を実行するとともに、前記記憶手段に記憶されている全曲目に関する演奏履歴情報を作成し、当該演奏履歴情報を前記ホスト装置に送信する制御手段とを有しており、
前記ホスト装置は、
前記演奏履歴情報に基づいて、前記曲目に関する演奏頻度の調査を実行するとともに、当該演奏頻度が所定の基準に達しない曲目を不要曲目と認定し、当該不要曲目に関する消去指令を前記カラオケ演奏端末に配信し、
前記制御手段は、前記消去指令に基づいて、前記不要曲目に対応する楽曲データを前記記憶手段より消去する処理を実行し、さらに当該消去された曲目に関するリクエスト履歴情報を作成し、当該リクエスト履歴情報を前記ホスト装置に送信し、
前記ホスト装置は、
前記リクエスト履歴情報に基づいて、前記消去された曲目に対するリクエスト回数頻度の調査を実行するとともに、当該リクエスト回数頻度が所定の基準に達した曲目を復元曲目として認定し、さらに前記復元曲目を配信することにより前記制御手段を介して前記記憶手段に再度記憶させることを特徴とする通信カラオケシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信カラオケシステムに関するものである。
【０００２】
【従来の技術】
通信カラオケシステムは、ホスト装置から複数のカラオケ演奏端末に対し、通信網を介して楽曲データをダウンロードし、これを当該端末の各々において演奏・再生するシステムとして一般的によく知られるに至っている。ここに、楽曲データの「演奏・再生」には、伴奏音楽とミキシングされた歌唱音声の音声出力、この音声出力の進行に合わせたディスプレイ上における歌詞画像等の映像出力が含まれる。
【０００３】
ところで、このような通信カラオケシステムは、一般に、発表間もない「新曲」に対し迅速に対応することが可能なことをその大きな特長とするものとして知られている。というのも、以前のカラオケ装置において、新たな曲目を演奏可能とするためには、楽曲データが記録された音楽テープやＣＤ-ＲＯＭ等を別途調達しなければならなかったところ、通信カラオケシステムでは、カラオケ演奏端末を通信網に接続するだけで、随時、新曲に関する楽曲データが配信されるから、その演奏を難なく実行することが可能だからである。
【０００４】
【発明が解決しようとする課題】
しかしながら、日に日に発表される新曲数は極めて膨大であり、これを一々配信していたのでは、やがてカラオケ演奏端末における記憶手段容量の限界を迎えることが目に見えている。だからといって、安易に曲目を削除するわけにもいかない。なぜなら、端末使用者の趣向は様々であり、これに対し一定の対応を行うためには、どの曲目が不要で、どの曲目が必要であるかが、容易には判定し難いからである。
【０００５】
そこで、このような不具合に対処するため、カラオケ演奏端末に新たな記憶手段、例えばＤＶＤ-ＲＯＭ等を設置して容量拡大を図ることも考えられる。しかし、このような措置は単なる対症療法に過ぎず、結局いつかはオーバーフローすることが不可避であるから、上記と同様な問題を抱えることとなるのが明白である。
【０００６】
また、別の解決手段としては、特許第2953115号公報に記載されているようなものが提案されている。この公報によれば、比較的小容量となる記憶手段、例えばハードディスクに対し、配信される楽曲データを随時記録するとともに、当該記憶手段の容量限界に達したら、前記記憶手段とは別の大容量記憶手段、例えばＣＤ-ＲＯＭに対し、従前までにおいて前記記憶手段に記憶されていた楽曲データのすべてを転載しこれを配布する運用方法が開示されている。そして、このことにより、新曲に対応可能でありつつ、オーバーフローするといった問題を回避し得るとされている。
【０００７】
しかしながら、上記公報に記載されている手段によっても、やはり原理的に、カラオケ装置端末「全体」から見た「オーバーフロー」は回避されていない。というのも、大容量記憶手段を収納するスペースは、所詮有限であるからである。また、上記したように、記憶手段から大容量記憶手段への一律的な転載を行うのでは、一見して非効率的である。
【０００８】
本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、随時発表される新曲に対応可能でありつつも、端末におけるオーバーフローを生じさせない通信カラオケシステム及びその運用方法を提供することにある。
【０００９】
【課題を解決するための手段】
本発明は上記課題を解決するために以下の手段をとった。
【００１０】
すなわち、請求項１記載の通信カラオケシステムは、ホスト装置と複数のカラオケ演奏端末とが通信手段を介して接続される通信カラオケシステムであって、前記カラオケ演奏端末の各々は、前記ホスト装置から配信された楽曲データを記憶する読み書き可能な記憶手段と、リクエストされた曲目に対応する前記楽曲データを前記記憶手段から読み出し、当該楽曲データに基づく前記曲目の演奏を実行するとともに、前記記憶手段に記憶されている全曲目に関する演奏履歴情報を作成し、当該演奏履歴情報を前記ホスト装置に送信する制御手段とを有しており、前記ホスト装置は、前記演奏履歴情報に基づいて、前記曲目に関する演奏頻度の調査を実行するとともに、当該演奏頻度が所定の基準に達しない曲目を不要曲目と認定し、当該不要曲目に関する消去指令を前記カラオケ演奏端末に配信し、前記制御手段は、前記消去指令に基づいて、前記不要曲目に対応する楽曲データを前記記憶手段より消去する処理を実行し、さらに当該消去された曲目に関するリクエスト履歴情報を作成し、当該リクエスト履歴情報を前記ホスト装置に送信し、前記ホスト装置は、前記リクエスト履歴情報に基づいて、前記消去された曲目に対するリクエスト回数頻度の調査を実行するとともに、当該リクエスト回数頻度が所定の基準に達した曲目を復元曲目として認定し、さらに前記復元曲目を配信することにより前記制御手段を介して前記記憶手段に再度記憶させることを特徴とするものである。
【００１９】
【発明の実施の形態】
以下では、本発明の実施の形態について図を参照しつつ説明する。図１は、本実施形態における通信カラオケシステムの構成例を示す概要図である。この図において、通信カラオケシステムは、ホスト装置１、多数のカラオケ演奏端末２（以下、「端末」と略す）、そして、ホスト装置１と端末２間における通信を可能とする通信網３から構成されている。
【００２０】
ホスト装置１は高速・大容量のコンピュータであり、図１に示すように、大容量記憶装置１１が備えられている。この大容量記憶装置１１には、端末２に対してダウンロードする多数の楽曲データが記憶されている。楽曲データは、本実施形態において、少なくとも曲目の楽曲ＩＤデータ、音楽生成データ及び歌詞描出データから構成されている。
【００２１】
なお、上記音楽生成データは、ＭＩＤＩ規格に沿ったものとすることができる。また、場合によっては、上記楽曲データを、その作成時期毎に、リリースファイルとしてまとめて記憶しておくような形態とするとよい。
【００２２】
端末２は、図２に示すように、ハードディスク装置（記憶手段）２１、CD-ROMチェンジャ装置（記憶媒体収納手段）２２、ディスプレイ２３、スピーカ２４及びマイクロホン２５、そして操作制御部２６、通信制御部２７及び中央制御部（制御手段）２Ｃの各々を主要な構成要素として備えている。そして、これら各要素は、図において概念的に示されているように、適当なデータバス２Ｂ等を介して接続されており、互いに連携して機能するようになっている。
【００２３】
ハードディスク装置２１は、通信制御部２７を介してホスト装置１から送信されてくる楽曲データ等を記録する。CD-ROMチェンジャ装置２２は、その一枚一枚が多数の楽曲データ又は／及び映像データを記憶している複数のCD-ROM（記憶媒体）を収納する。これら複数のCD-ROMは、当該CD-ROMチェンジャ装置２２に対し、任意に挿脱することが可能である。また、中央制御部２Ｃからの指令により、当該複数のCD-ROMから読み出し対象となるものを適宜選択することが可能な構成を備えている。ちなみに、CD-ROMに記憶されている前記楽曲データ等は、通常、再生専用として記憶されており、新たなデータの書き込みはできないようになっている。
【００２４】
ディスプレイ２３は、前記CD-ROMに由来し映像制御部２３１を介して送られてくる映像データ、ないしは前記楽曲データ内の歌詞描出データをビデオＲＡＭ２３２において展開処理し、これを映像制御部２３１を介して送出した歌詞映像データ等に基づき、これらの映像を表示する。なお、映像制御部２３１は、映像データに基づく映像を、歌詞映像データに基づく映像の背景映像となるようなスーパーインポーズ処理を実行し、これをディスプレイ２３上に表示する。
【００２５】
スピーカ２４は、前記楽曲データを構成する音楽生成データについて、これをシンセサイザ２４１で伴奏音楽の音声信号となるよう処理したものを、ミキシングアンプ２４２を介して音響出力する。また、このとき、ミキシングアンプ２４２は、接続されたマイクロホン２５から入力される歌唱音声信号を同時に音響出力する。したがって、スピーカ２４からは、伴奏音楽の音声信号と歌唱音声信号が同時再生される。
【００２６】
ちなみに、先に述べたディスプレイ２３における映像出力と、いま述べたスピーカ２４からの音響出力とは、その進行具合が中央制御部２Cにより同期されるようになっている。
【００２７】
他方、操作制御部２６は、操作パネル２６１及びリモコン受信部２６２を備えている。端末２の使用者は、操作パネル２６１を操作することにより、あるいはリモコン送信器２６２aを操作してリモコン受信部２６２に信号を送出することにより、リクエストする曲目に関する演奏指令を発することが可能となっている。この演奏指令を受けた操作制御部２６は、中央制御部２Cにその旨を伝達する。中央制御部２Cはこれを受けて、上記ハードディスク装置２１又はCD-ROMから、当該リクエストされた曲目に対応する楽曲データ又は／及び映像データを読み出すとともに、ディスプレイ２３、スピーカ２４等の各要素を上述したように動作させて演奏を開始する。
【００２８】
通信制御部２７は、前記ホスト装置１からの楽曲データ等の配信を受信するコネクタ２７１を有している。このコネクタ２７１の具体的構成としては、例えばモデム若しくはＤＳＵ・ターミナルアダプタ等を採用すればよい。そして、受信したデータが例えば楽曲データであれば、中央制御部２Cの監督の下、上述したように、これをハードディスク装置２１に送出し記憶させる。また、通信制御部２７は、端末２からホスト装置１への信号送信を行うことも可能であり、上記コネクタ２７１は、その際における送信ポートともなる。
【００２９】
最後に、中央制御部２Cは、上記までの記載からも明らかなように、端末２を構成する各要素を統括的に制御する。その構成としては、図２に示されるように、中央演算処理装置（CPU）２C1、読み出し専用メモリ（以下、「ＲＯＭ」という）２C2、随時読み書き用メモリ（RAM）２C3等を備えており、中央制御部２Ｃは、これらを利用しつつ上記したような制御を適宜実施する。また、中央制御部２Ｃは、以下に詳しく述べる、本発明に特徴的な作用ないし運用方法に関する機能をも統括的に司る。
【００３０】
また、本実施形態においては特に、上記ＲＯＭ２C2において、多数の端末２の各々に固有な端末ＩＤデータが記録されている。この「端末ＩＤデータ」としては、例えば、各々の端末２製造時に付したシリアル番号を該当させるようにすればよい。
【００３１】
そして、上記ホスト装置１と端末２とは、上述したように、通信網３を介して接続されている。通信網３としては、具体的に例えば、ＩＳＤＮ回線、一般公衆回線、ＷＡＮやＶＡＮ等の専用回線、衛星通信回線等その他ホスト装置１と端末２間における通信（例えば、ホスト装置１から端末２への楽曲データの配信等）を可能とする手段であれば、どのようなものを採用してもよい。
【００３２】
また、この通信網３を介したホスト装置１及び端末２の具体的設置状況は、例えばホスト装置１を然るべきセンターに設置するとともに、多数の端末２を種々の店舗に分散配置させるようなものとなる。ここで、「種々の店舗」とは、例えば主に年輩層を対象としたクラブ形態の店舗（いわゆる、「ナイト系」の店舗）や、主に若輩層を対象とした、いわゆるカラオケボックス形態の店舗等が該当する。また、これらの他にバーや宴会場等を備えたホテル等に、端末２を配置することは当然に可能である。通信網３は、このように分散配置された多数の端末２とホスト装置１を通信可能に接続する。
【００３３】
以下では、上記構成となる通信カラオケシステムの作用効果、特にその運用方法とその効果について説明する。
【００３４】
まず、その前提として、上記したような「種々の店舗」の一において、ある一台の端末２を設置する場合における、当該端末２のホスト装置１に対する登録処理に関する説明を行う。
【００３５】
これは、次のように行われる。まず、図３ステップＳ１に示すように、上記ある一台の端末２を、ある店舗に設置するとともに、当該端末２を通信網３に接続する。次に、図３ステップＳ２に示すように、当該端末２からホスト装置１に対する発呼信号を送信する。この際、端末２は、中央制御部２ＣにおけるＲＯＭ２C2に記憶されている、自身に固有な「端末ＩＤデータ」と当該店舗の「電話番号」を同時に送信する。なお、これらの情報に加え、必要に応じて、当該店舗の名称や住所等、その他明らかとされていれば端末２の運用上便宜な情報を、同時に送信するようにしてもよい。
【００３６】
ホスト装置１は、図３ステップＳ３に示すように、上記発呼信号に応じつつ、送信された「端末ＩＤデータ」及び「電話番号」を認識し、これらを対応付けしつつ、大容量記憶装置１１における所定のアドレスに記憶する。以上により、新たに配置された端末２のホスト装置１における登録処理は完了する。そして、この登録処理以降、ホスト装置１は、当該端末２を、以下に述べる新曲配信等の運用サービスの対象とみなすことになる。
【００３７】
なお、このような登録処理は端末２の設置毎に実施され、上記した具体的設置状況となる「通信カラオケシステム」は構築されていくことになる。
【００３８】
さて、このような通信カラオケシステムにおいては、具体的に、次のような運用がなされることになる。
【００３９】
まず、ホスト装置１は、逐次発表される新曲に関する楽曲データを、大容量記憶装置１１に記憶していく。この記憶作業は、ホスト装置管理者の入力作業による。ちなみに、これらの楽曲データには、上記したように、曲目の各々に対応する楽曲ＩＤデータが含まれる。そしてホスト装置１は、これら新曲を各々の端末２において演奏可能とするため、当該新曲に関する楽曲データを、定期的に、通信網３を介して端末２へと配信（ダウンロード）する。端末２では、このダウンロードされた楽曲データを通信制御部２７において受け取り、これらをハードディスク装置２１に記憶する。
【００４０】
一方、端末２においては、ハードディスク装置２１又はCD-ROMチェンジャ装置２２に収納されたCD-ROM、に記憶されている楽曲データが、端末使用者の要望に応じて適宜に読み出され、この読み出された楽曲データに基づき、様々な曲目の演奏が実施される。ちなみに、端末使用者が好みの曲目を選択する際には、よく知られているように、上記新曲のダウンロード時、従来の曲目のリストに当該新曲のリストを新たに加えて発行される曲目リスト（以下、「目次本」という）が利用される。
【００４１】
このとき、本実施形態においては、ハードディスク装置２１又はＣＤ-ＲＯＭに記憶されている全曲目に関しその演奏履歴が作成されることになる。すなわち、中央制御部２Ｃは、ある曲目が演奏される度毎に、当該曲目の楽曲ＩＤデータ、演奏日時データ及び格納日時データから構成される演奏履歴を、ハードディスク装置２１上に更新・作成していく。ここに、「格納日時データ」とは、当該曲目に関する楽曲データが、端末２上にダウンロードされた日時のことである。
【００４２】
例えば、図４に示すように、端末２において曲目Ａに関する演奏が実施された場合には、曲目Ａを表象する楽曲ＩＤデータ「Ａ００００１」及び格納日時データ（図４では、「１９９９．４．２３」）とともに、演奏実施毎に、その演奏日時データ（図４では、演奏日時「２０００．１．１９」及び「２０００．３．３」）が記録されていく。以下、端末２が有する全ての曲目に関し、上記したような演奏履歴が記録されていくことになる。ちなみに、図４においては、曲目Ａ及び曲目Ｂに関する演奏が、それぞれ通算で、２度及び４度実施されていることがわかり、曲目Ｃについては１度も演奏されていないことがわかる。
【００４３】
なお、このような演奏履歴に係る情報（以下、「演奏履歴情報」という）の作成・記録は、当該曲目に関する楽曲データが、ハードディスク装置２１から読み出されたものであるか、ＣＤ-ＲＯＭから読み出されたものであるか、を区別して作成する。以下では、特段の指定がない限り、単に「演奏履歴情報」とあるものについては、便宜上、前者（ハードディスク装置２１）に関する演奏履歴情報を指示する用語として使用されている。
【００４４】
また、端末２は、このような演奏履歴情報を、定期的に、通信制御部２７を介してホスト装置１へと配信（アップロード）し、ホスト装置１は、このアップロードされた演奏履歴情報を大容量記憶装置１１の所定のアドレスに記憶していく。
【００４５】
なお、ここで述べた「定期的に」とは、例えば上記した新曲の楽曲データ配信時における「定期的に」ということ、同一の期間と考えてよい。つまり、楽曲データのダウンロード時期と演奏履歴情報のアップロード時期を、例えば２週間毎や４週間毎など、同一期間を経過した同じ機会とすればよい。以下の説明では、このような両方向配信が同時に行われる形態を前提とした説明を行うこととする。ただし、本発明においては、当該ダウンロードと当該アップロードとの時期を必ずしも一致させる必要はない。
【００４６】
また、演奏履歴情報を構成するデータとして、上記楽曲ＩＤデータ等の他、例えば当該曲目を選択した歌唱者に関するデータを加えるようにしてもよい。さらに、図４において示した「楽曲ＩＤデータ」の具体的形態は単なる一例示に過ぎず、この他如何なる形態としてもよいことは言うまでもない。
【００４７】
以上のようにして、ホスト装置１には、各端末２から、演奏履歴情報が定期的に集計されることになるが、当該ホスト装置１は、これら全端末２に関する演奏履歴情報に基づき、所定の基準に則って、演奏曲目ランキングを作成（演奏頻度の調査を実行）する。例えば図４に示した限りの演奏履歴情報によれば、演奏回数４回の曲目Ｂがランキング１位、同回数２回の曲目Ａが同２位、そして同回数が“０”の曲目Ｃが同３位ということになる。
【００４８】
ところで、本実施形態においては、この演奏曲目ランキングの作成を、様々な「所定の基準」に基づき行い得る。以下ではまず、その中でも典型的な演奏曲目ランキング作成処理、及びそれに続くランキング下位の曲目の消去処理等に係る実施形態ついて説明し、その後、これに関する変形実施例についての説明を行うこととする。
【００４９】
（典型的実施例）
この典型的実施例では、ホスト装置１は、通信網３を介して接続されている全ての端末２を対象とし、かつ、最も直近にダウンロードした曲目に関する演奏曲目ランキングを作成する。
【００５０】
具体的には次のようになる。まず、上記した新曲の楽曲データ・ダウンロードが、例えば２週間毎に行われているとするならば、図５ステップＴ１に示すように、ホスト装置１は前回行われたダウンロードから２週間経過し、新たなダウンロードを各端末２に対して実施するとともに、当該各端末２からはホスト装置１に対して新たな演奏履歴情報がアップロードされる。これは本実施形態において通常に想定されている両方向配信動作である。
【００５１】
次に、ホスト装置１は、図５ステップＴ２に示すように、新たにアップロードされた演奏履歴情報における「格納日時データ」を参照し、これが前回のダウンロード時以降のものをピックアップする。つまり、現時点が、例えば「平成１２年３月２日」ならば、「同年２月１７日」以降の格納日時データを有する曲目がピックアップされる。なお、いまの場合においては、ダウンロード及びアップロードは同時に行われるのが前提とされているから、ピックアップされた曲目が有する格納日時データは、すべて「平成１２年２月１７日」となるのが通常である。しかし、当該２週間という期間中に、例外的ではあるが、臨時に新曲が配信されている等の事情が存在すれば、当該新曲がピックアップされる可能性はある。
【００５２】
そして次に、ホスト装置１は、図５ステップＴ３に示すように、全端末２に関する演奏履歴情報を統合し、かつ、上記ピックアップされた曲目に関し、当該全端末２における演奏実施回数に基づいた演奏曲目ランキングを作成する。
【００５３】
続いてホスト装置１は、図５ステップＴ４に示すように、この演奏曲目ランキングにおいて演奏実施回数が“０”である曲目を選定する。つまり、図４に示した限りの演奏履歴情報によれば、曲目Ｃがそれに該当する。このとき、もし演奏実施回数が“０”である曲目が存在しないならば、図５ステップＴ５に示すように、演奏曲目ランキングにおける下位に位置する曲目、例えば下位１０位内に存在する曲目を抽出する。
【００５４】
このように選定ないし抽出された曲目は、すなわち、直近のダウンロード以降、全端末２において演奏実施頻度が極めて小さいものである。つまり、俗に言えば「人気がない」曲目であり、これ以降各端末２において演奏要請（リクエスト）される可能性は一般に低いものと考えられる。そして、ホスト装置１は、このような不人気の曲目を「不要曲」と認定することになる（図５ステップＴ６参照）。
【００５５】
次に、ホスト装置１は、図５ステップＴ７に示すように、上記不要曲と認定された曲目に関する楽曲データを、全端末２におけるハードディスク装置２１から消去する指令（以下、「消去指令」という）を、当該全端末２に対して発信する。この「消去指令」の具体的実態は、例えば不要曲と認定された楽曲ＩＤデータリストを記述したファイル情報とすればよい。
【００５６】
この消去指令を受信した全端末２は、図５ステップＴ８に示すように、それら端末２各々において、中央制御部２Ｃが上記ファイルを開き、かつ、そこに記載されている楽曲ＩＤデータリストを読み取って、当該楽曲ＩＤデータに該当する楽曲データをハードディスク装置２１から消去する。なお、このとき、消去日時を記録しておく。
【００５７】
このように、全端末２のハードディスク装置２１からは、全国的に見て「不人気」である曲目に関する楽曲データが、一斉に消去されることになる。したがって、ハードディスク装置２１に関し、これ以上楽曲データを書き込むことが不能となるオーバーフローが生じることはない。また、消去される曲目は、上記演奏曲目ランキングに基づいて、適切に「不要曲」と認定されたものに限られるから、特段の不都合が生じることはない。
【００５８】
なお、上記においては、演奏曲目ランキングの作成が、前回のダウンロード時以降のものをピックアップした曲目に関して行われていたが、本発明はこのような形態に限定されるものではない。例えば、そのようなピックアップに係る限定をせずに、端末２が送信した演奏履歴情報に含まれる全ての曲目について、いわばより広い範囲の「演奏曲目ランキング」を作成するような場合も、当然に本発明の範囲内にある。
【００５９】
また、上記では、演奏履歴情報は、端末２側においてハードディスク装置２１に関するものと、ＣＤ-ＲＯＭに関するものとを区別していたが、本発明はこのような形態に限定されるものではない。例えば、当該区別をホスト装置1側において実施する形態も本発明の範囲内にある。このような場合においては例えば、最も直近にダウンロードした楽曲データをホスト装置１側に記憶させ、これに基づいて、上記区別されることなくアップロードされてくる演奏履歴情報を、ハードディスク装置２１に由来する演奏履歴情報と、ＣＤ-ＲＯＭに由来する演奏履歴情報とに区別するようにすればよい。
【００６０】
さて、上記演奏曲目ランキングに基づく不要曲の消去は、上記したように、ハードディスク装置２１の負担を軽くするには有効である。しかしながら、すでに述べたように、新曲のダウンロード時においては、当該新曲のリストを掲載した「目次本」が新刷・発行されており、ハードディスク装置２１から「不要曲」が消去された後にも、当該目次本においては当該「不要曲」が選択可能な体裁で残置される。したがって、このような場合においては、端末使用者からの要望ないしリクエストに対し、それに応えられない状況が発生し得ることは否定できない。
【００６１】
また、一旦「不要曲」として消去されたとしても、何らかの事情により、当該曲目の「人気」が後日回復し、端末使用者の要望が高まる場合がある。この場合においても、上記した状態においては、もはや全端末２においてその曲目の演奏を実施することは不可能である。
【００６２】
このような不具合を解消するため、本実施形態においては、以下の処置を施す。
【００６３】
すなわち、ある特定の端末２において、図５ステップＴ８で消去された曲目（以下、「消去曲」という）がリクエストされた場合には、図６ステップＵ１に示すように、当該特定の端末２における操作パネル２６１又はディスプレイ２３において、例えば「都合によりこの曲は演奏できません」等といった演奏不可メッセージを表示する。
【００６４】
そしてこれに続き、図６ステップＵ２に示すように、当該消去曲に関しリクエストがあった旨が、当該曲目の楽曲ＩＤデータ、リクエストがあった日時及び消去日時から構成される「リクエスト履歴情報」として作成され、当該特定の端末２におけるハードディスク装置２１上に記録される。ちなみに、全くリクエストされない「消去曲」に関する「リクエスト履歴情報」については、その曲に対するリクエストがあるまで、「リクエスト回数０」なる情報がその属性として付されて規定される。つまり、ハードディスク装置２１上には、消去曲全てに関する「リクエスト履歴情報」が存在する。
【００６５】
次に、ホスト装置１は、例えば上記したように定期的に実施される同時配信時（図５ステップＴ１参照）等その他の通信機会を適宜利用して、図６ステップＵ３に示すように、前記特定の端末２を含む全端末２から、上記したような「リクエスト履歴情報」を集信し、さらに、集信した全端末２に関する「リクエスト履歴情報」を統合して、消去曲に対するリクエスト回数ランキング（以下、「消去曲ランキング」という）を作成（消去された曲目に対するリクエスト回数頻度の調査を実行）する。
【００６６】
続いてホスト装置１は、図６ステップＵ４に示すように、この消去曲ランキングにおける上位に位置する曲目、例えば上位１０位内に存在する曲目を抽出する。また、このような抽出方法に代えて、例えば予めリクエスト回数に関する「規定数」を定めておき、この規定数を上回るリクエスト履歴情報を有する消去曲を抽出するような方法としてもよい。
【００６７】
いずれにしても、上記のように抽出された曲目は、例えば上記したように「人気」が回復した等の事情により、全端末２においてリクエストされる機会が、残余の消去曲に比べて多かった消去曲である、と考えることができる。
【００６８】
以下では、ホスト装置１内及び端末２内における作業を離れ、図６ステップＵ５に示すように、ホスト装置管理者が上記抽出された消去曲を確認し、当該消去曲に関する楽曲データをＣＤ-ＲＯＭに記録させる作業を行うとともに、このCD-ROMを、そこに記録した楽曲データに対応する消去曲の曲目リストとともに、全端末２の所有者に対して配布する。
【００６９】
そして端末２側では、図６ステップＵ６に示すように、その配布されたＣＤ-ＲＯＭを、ＣＤ-ＲＯＭチェンジャ装置２２に収納する。ただし、この収納が何らの問題もなく可能であるためには、ＣＤ-ＲＯＭチェンジャ装置２２に、余分な収納スペースが残存する場合である。
【００７０】
また、現在収納されているＣＤ‐ＲＯＭの１枚に未記録のスペースが残存する場合も問題なく収納可能である。この場合においては、そのＣＤ‐ＲＯＭに記録されていた情報に消去曲を追加記録した内容のＣＤ‐ＲＯＭを作成し、差し替え（追記）を行うＣＤ‐ＲＯＭを指定して配布することになる。
【００７１】
またこのとき、もし、上記したような収納スペース等が存在しないのであれば、所有者は、現在収納されているＣＤ-ＲＯＭと上記配布されたＣＤ-ＲＯＭとの差し替え（挿脱）作業を行う。
【００７２】
ただし、この差し替え作業を行うか否かは、全端末２各々の所有者の判断に委ねればよい。そして、この判断に際して所有者は、例えば上記した消去曲の曲目リストを参考にすることができる。つまり、各所有者は、配布されてきたＣＤ-ＲＯＭに自らが演奏の必要性があると思う消去曲が含まれていると考える場合には、上記差し替え作業を実行し、そう考えないのであれば必ずしも実行する必要はないのである。
【００７３】
このような処置を実施することで、上記した不具合は殆ど解消され得ることが明らかである。というのも、「人気」のある「消去曲」は、上記のように改めて配布されたＣＤ-ＲＯＭに記憶されている楽曲データに基づき、演奏可能となるからである。
【００７４】
また、このような運用方法は、従来の技術の項で述べた運用方法、すなわちハードディスク装置２１に記憶されていた楽曲データ全てをＣＤ-ＲＯＭに転載しこれを配布するような運用方法とは異なり、次に述べるような特有の効果を有するものである。
【００７５】
すなわち、本実施形態においては、演奏曲目ランキングに基づく「不要曲」の選別と消去曲ランキングに基づく「消去曲」の復活、なる二段の抽出により、実質的に不要と考えられる曲目は徹底的に排除されることになる。一方、ホスト装置１が配信等で扱う曲目や、端末２が記憶する曲目に関しては、通常、著作権料等の付随コストが発生することを鑑みるに、従来の運用方法では、配布されるＣＤ-ＲＯＭは全ての楽曲データを記憶するから、全く演奏される可能性のない曲目に関しても、その著作権料等が徴収されることとなって非常に不経済であるのに対し、本実施形態における運用方法によれば、無駄な著作権料等を支払う必要がないのである。
【００７６】
なお、消去曲に対するリクエストが急激に増加している等の特別の事情がある場合には、上記したＣＤ-ＲＯＭの配布による手段をとらず、当該消去曲を、新曲のダウンロードと同様に、通信網３を介した配信を実施することにより、再びハードディスク装置２１に記憶させるような処置をとってもよい。このような処置によれば、より迅速な対応が可能となることは言うまでもない。
【００７７】
（上記典型的実施例に関する変形実施例）
以上までにおいて、本発明の主要な技術的思想に関する実施形態については説明したが、以下では、上記典型的実施例に基づく、さらに効果的な運用方法について説明する。
【００７８】
この運用方法は、上記典型的実施例における演奏曲目ランキングの作成、これに基づく不要曲の抽出及びその消去、あるいは消去曲ランキングの作成、これに基づく消去曲の復活の各作業が、全端末２を対象として行われていたところ、これを各端末２が固有に有する「端末所在区分情報」に基づいて実施することに関する。
【００７９】
ここに、「端末所在区分情報」とは、ある特定の端末２が、東京、大阪、北海道等、どのような地域に設置されているか（地域情報）、あるいは上記したような「種々の店舗」種の中で当該特定の端末２が具体的にどのような店舗に設置されているか（店舗情報）等、全端末２を所定の基準で区分することができ、これら全端末２の各々が固有に有し得る情報のことである。
【００８０】
ここで、前者の地域情報に関しては、各端末２設置段階における上記登録処理中において、ホスト装置１に「端末ＩＤデータ」と当該店舗の「電話番号」が対応付けられて登録されていたから、各端末２が如何なる地域に設置されているかは、この電話番号における市外局番を調べることにより、簡単に割り出すことができる。そして、この割り出した「地域」を当該端末２の「端末所在区分情報」として認識し、これをデータベース化しておけばよい。なおこの他、より直接的に、端末２が「住所（ないしは郵便番号）」を登録処理時に送信することにより、上記認識を実施するようにしてもよい。
【００８１】
また、後者の店舗情報に関しては、上記登録処理時、「端末ＩＤデータ」及び「電話番号」を端末２が送信するのに加え、予め定めた「店舗種コード」を同時に送信するようにしておけばよい。例えば、上で「種々の店舗」の例として述べたように、これらには▲１▼ナイト系店舗、▲２▼カラオケボックス、▲３▼ホテル、▲４▼その他等の区別を設けることができるが、これらの別に応じ、固有の「店舗種コード」を定めておけばよい。後は、上記と同様にして、その送信された「店舗種コード」から認められる「店舗」を、当該端末２の「端末所在区分情報」として認識し、これをデータベース化しておけばよい。
【００８２】
そして、このような端末所在区分情報に基づき、上記典型的実施例と同様な運用を実施すれば、次に記すような特有の効果を享受することできる。以下では、上記「地域情報」を例とした説明を行う。
【００８３】
まず、上記典型的実施例においては、演奏曲目ランキングを作成する際に、各端末２からアップロードされた演奏履歴情報を「全端末２」に関し「統合」し、全国的な演奏曲目ランキングを「一つ」作成していたが、本運用方法において、ホスト装置１は、上記地域情報の別に応じた演奏曲目ランキングを作成する（図５ステップＴ３に該当）。
【００８４】
具体的には、例えば図７に示すようになり、この図においては、東京、大阪及び北海道の各地域別に演奏曲目ランキングが作成されている。また、この図によれば、東京及び大阪地域における演奏曲目ランキングでは、「曲目Ａ」が第１位であるが、北海道地域における演奏曲目ランキングでは、「曲目Ｃ」が第１位となっている。また、最下位（第ｎ位）は、東京及び大阪地域では「曲目δ」、北海道地域では「曲目β」、がそれぞれ該当している。また特に、大阪地域における演奏曲目ランキングでは、東京及び北海道地域では上位にランクされている「曲目Ｂ」が、第n-3位（最下位から４番目）に位置していることがわかる。
【００８５】
そして、ホスト装置１は、本運用方法における「不要曲」の認定（図５ステップＴ４乃至Ｔ６に該当）を、これら地域情報別各々の演奏曲目ランキングに基づいて実施する。またさらに、上記した消去ランキングの作成、そしてこれに基づく消去曲の復活も、地域情報別に応じて実施するのである（図６参照）。
【００８６】
以上の記載から、もはや容易に推測されるように、本運用方法によれば、各地域の特性に応じた、より木目細かな対応をなすことができる。例えば、図７に関し、図５ステップＴ５に示すような処理を実施すると、東京及び北海道地域を除く大阪地域では、曲目Ｂが「不要曲」認定を受けることになり、大阪地域に設置された端末２において、当該曲目Ｂは消去されることになる。ちなみに、このような場合では、各地域における端末２が収納するＣＤ-ＲＯＭの構成は必然的に異なることになる。
【００８７】
なお、演奏曲目ランキングの作成、これに基づく不要曲認定及びその消去に係る作業は、上記した典型的実施例のように全国区で実施する一方、消去曲ランキング及びこれに基づく消去曲の復活は、いま述べた地域情報に基づく対応を行うような形態も本発明の範囲内である。このような場合においては、全国的には「不人気」ではあるが、ある地域においては頻繁にリクエストされるといった曲目に関し、適切な処理を行うことができる。
【００８８】
例えば、全国区の演奏曲目ランキングでは、「恋の街札幌」（＝曲目）が「不人気」曲として認定され、全国的に消去されているが、北海道地域では根強い人気が存在する場合において、当該「恋の街札幌」は、北海道地域のみで上記ＣＤ-ＲＯＭの配布を実施するといった対応がとられることになる。
【００８９】
このような、いわゆる「御当地ソング」に関する対応は、本運用方法において比較的重要であり、例えば地方色豊かな曲目や、ある地域では欠かすことのできない曲目等は、大凡どのような地域においても存在する。このような曲目が、単に全国的に「不人気」であるからということを理由として消去されたままでは、極めて不都合である。このようなことを鑑みるに、上記運用方法は、非常に有効なものであることが認識されよう。
【００９０】
なおまた、演奏曲目ランキング作成及び消去曲ランキング作成の双方を地域情報別に対応して実施する最初の例においても、上記「御当地ソング」に関する問題が生じる場合があるが、これについては、地域情報を可能な限り細かく区分することによって、有効に対応することができる。例えば、上記では「北海道地域」と区分されていたのを、「札幌地域」その他等と細分化することにより、「恋の街札幌」が、当該「札幌地域」においては、そもそも不要曲認定されないことになるからである。
【００９１】
また、店舗情報の別に応じ演奏曲目ランキング作成等を実施する場合にも、上記地域情報を例とした説明から、もはや詳細な説明をまつまでもなく、その有効性は明らかに認識することができよう。例えば、上記▲１▼ナイト系店舗では演歌系の曲目が好んでリクエストされ、▲２▼カラオケボックスではポップス系の曲目が好まれる、といような場合を想定すれば、上記と同様な効果を享受することができることは明らかである。
【００９２】
なお、上記地域情報と店舗情報による二重の選別による、「端末所在地区分情報」を、各端末２に関し認識するような形態も当然に本発明の範囲にある。このような場合においては例えば、ある特定の端末２について、「大阪地域・カラオケボックス」なる「端末所在区分情報」が、その固有な属性として認識されることになる。
【００９３】
なお、各々の端末２を、端末所在地区分情報によって、具体的に幾つに細分化して認識するかは、本発明において基本的に任意である。極端に言えば、全端末２の各々について、全く個別に対応することも原理的には可能である。しかしながら、消去曲の復活に関しては、上記したように、ＣＤ-ＲＯＭの配布によって対応することになるから、例えば上記地域情報があまりに細分化されると、当該対応をとることが極めて困難となる。
【００９４】
したがって、端末所在区分情報の設定は、いま述べた事情や、上記「御当地ソング」に関する問題、あるいは各端末２のメンテナンス等を目的として全国に設置される代理店数等、を総合的に勘案した上で、より実際的に決定することが好ましいといえよう。
【００９５】
【発明の効果】
以上説明したように、本発明の通信カラオケシステム及びカラオケ演奏端末並びに同システムの運用方法によれば、随時発表される新曲に対応可能でありつつも、端末におけるオーバーフローが生じない。
【００９６】
また特に、不要曲目の認定に関する演奏頻度の調査や消去された曲目に関するリクエスト回数頻度の調査を、前記端末が設置される地域に基づく地域情報や前記端末が設置される店舗種に基づく店舗情報等からなる端末所在区分情報の別に応じて実施することとすれば、より木目細かな対応を実施することができる。
【図面の簡単な説明】
【図１】  本実施形態に係る通信カラオケシステムの構成例を示す概要図である。
【図２】  図１に示す通信カラオケシステムを構成するカラオケ演奏端末の構成例を示すブロック図である。
【図３】  設置端末のホスト装置への登録処理の作業流れを示すフローチャートである。
【図４】  ある端末における演奏履歴情報を概念的に示す説明図である。
【図５】  演奏曲目ランキングの作成並びにこれに基づく不要曲認定及びその消去の作業流れを示すフローチャートである。
【図６】  消去曲ランキングの作成及びこれに基づく消去曲の復活の作業流れを示すフローチャートである。
【図７】  地域情報別毎に作成された演奏曲目ランキングの一例を示す説明図である。
【符号の説明】
１  ホスト装置
２  カラオケ演奏端末
２１  ハードディスク装置（記憶手段）
２２  ＣＤ-ＲＯＭチェンジャ装置（記憶媒体収納手段）
２３  ディスプレイ
２４  スピーカ
２５  マイクロホン
２６  操作制御部
２７  通信制御部
２Ｃ  中央制御部（制御手段）
３  通信網
【図１】
0004299947.tif 000002
【図２】
0004299947.tif 000003
【図３】
0004299947.tif 000004
【図４】
0004299947.tif 000005
【図５】
0004299947.tif 000006
【図６】
0004299947.tif 000007
【図７】
0004299947.tif 000008