JP3646377B2 - コンピュータシステムおよびカラオケ装置 - Google Patents
コンピュータシステムおよびカラオケ装置 Download PDFInfo
- Publication number
- JP3646377B2 JP3646377B2 JP30177395A JP30177395A JP3646377B2 JP 3646377 B2 JP3646377 B2 JP 3646377B2 JP 30177395 A JP30177395 A JP 30177395A JP 30177395 A JP30177395 A JP 30177395A JP 3646377 B2 JP3646377 B2 JP 3646377B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- karaoke
- genre
- menu
- display
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
この発明は、実行すべきオブジェクトファイルが複数ある場合に、そのリストを自動的に作成することができるコンピュータシステムおよび前記コンピュータシステムを有したカラオケ装置に関する。
【０００２】
【従来の技術】
周知のように、センタ局のホストコンピュータからカラオケスナック等の各店舗に設置されたカラオケ端末にカラオケの演奏情報を通信回線を介して供給する通信カラオケシステムが広く普及している。特に、近年においては、曲の演奏の合間の時間を利用して、センタ局から供給されたＣＭ情報を再生しこれを放映する通信カラオケシステムが知られており、カラオケ演奏の合間に流されるＣＭによって新譜紹介やその他種々の情報が利用者に提供されるようになっている。
さらに、ＣＭに限らず、ゲームや旅行案内などの情報サービスを提供するカラオケシステムも考えられている。
【０００３】
【発明が解決しようとする課題】
以上のように、カラオケシステムにおいて提供する情報サービスの種類が多くなると、そのメニュー表示が必要になる。しかしながら、カラオケの各店舗において放映するＣＭや提供する情報サービスが異なることが多いため、各店舗毎にメニュー表示を作成しなければならず煩雑であった。さらに、ＣＭや情報サービスの内容は、季節や時間に応じて変化することがよりニーズに適合し、望ましいが、このようにすると、メニュー表示もその都度変更しなければならないという問題が生じた。
特に、カラオケを利用する各人の年齢、性別、好み等に応じたサービスが提供できれば理想的であるが、この場合には、メニュー表示を各個人別に用意しなければならず、実現が困難であった。また、このような問題は、カラオケ装置に限らず、多様な情報サービスを行うコンピュータシステムにおいても同様に発生する。
【０００４】
この発明は、このような背景の下になされたもので、コンピュータシステムやカラオケ装置において、利用者個人の状況に応じて、自動的にメニューを生成することができるコンピュータシステムおよびカラオケ装置を提供することを目的としている。
【０００５】
【課題を解決するための手段】
上述した課題を解決するために、請求項１記載の発明は、プログラムおよびジャンル情報を含むオブジェクトファイルを複数記憶する記憶手段を有し、前記記憶手段からオブジェクトファイルを選択するとともに、選択したオブジェクトファイル内のプログラムを実行するコンピュータシステムであって、利用者の個人情報を含むＩＤ情報を読み取るＩＤ情報読取手段と、前記ＩＤ情報読取手段が読み取った個人情報に対応した個人別ジャンルを判定するジャンル判定手段と、利用者の操作に応じて指定ジャンルを決定するジャンル決定手段と、前記ジャンル決定手段が決定した指定ジャンルおよび前記ジャンル判定手段が判定した個人別ジャンルの双方に合致するオブジェクトファイルを検索する検索手段と、前記検索手段によって検索されたオブジェクトファイルに対応したタイトルによって構成されるリストを生成するリスト生成手段と、前記リスト生成手段が生成したリストを表示する表示手段とを具備することを特徴とする。
【０００６】
また、請求項２に記載の発明にあっては、請求項１記載のコンピュータシステムにおいて、前記各オブジェクトファイルは、その内容に対応したタイトルを表示するためのタイトル情報を有し、前記リスト生成手段は前記検索手段によって検索されたオブジェクトファイル内のタイトル情報に基づいて前記リストを生成することを特徴とする。
【０００８】
また、請求項３に記載の発明にあっては、請求項１または２に記載のコンピュータシステムを有するとともに、前記記憶手段にカラオケの演奏情報を格納するカラオケ装置において、さらに、前記記憶手段からカラオケの演奏を読み出して楽音を合成し、この合成音とマイクから入力される音声とを混合して出力するカラオケ演奏手段と、前記オブジェクトファイルの実行と前記カラオケ演奏手段によるカラオケ演奏のいずれかを切り換える切換手段とを有することを特徴とする。
【０００９】
また、請求項４に記載の発明にあっては、請求項３記載のカラオケ装置において、前記オブジェクトファイルのプログラム中に前記カラオケ演奏手段によるカラオケ演奏が選択可能な命令として記述されていることを特徴とする。
【００１０】
また、請求項５に記載の発明にあっては、請求項３または４記載のカラオケ装置において、前記ＩＤ情報は、ＩＤカードに記憶され、前記ＩＤ情報読取手段は、ＩＤカード読取装置によって構成されていることを特徴とする。
【００１１】
【発明の実施の形態】
以下、図面を参照して、この発明の実施形態について説明する。
Ａ：実施形態の構成
（１）全体構成
図１はこの発明の一実施形態による通信カラオケシステムの構成を示すブロック図である。図１において、１はホストコンピュータであり、２，２，……はホストコンピュータ１と通信回線Ｎを介して接続される複数のカラオケ端末である。ホストコンピュータ１は、カラオケデータと情報ファイル（詳細は後述）を各カラオケ端末２，２，……に定期的に配信する。カラオケデータには、演奏データ（ＭＩＤＩデータ）、歌詞データ（演奏と歌詞とを同期させるデータを含む）および画像制御データ（カラオケ端末２側で用意している画像を選択するデータ）が含まれており、カラオケ端末２は、演奏データに基づく伴奏演奏、歌詞データに基づく歌詞表示および画像制御データに対応した画像表示を行うようになっている。
【００１２】
また、カラオケ端末２は、ホストコンピュータ１から供給される情報ファイルを実行することによって、操作者との対話形式で各種情報サービスを提供するようになっている。
【００１３】
（２）カラオケ端末の構成
次に、図２を参照し、カラオケ端末２の構成について説明する。
図２において、２１はモデムあるいはＩＳＤＮ（Integrated Sarvices Digital Network）等の通信インタフェースであり、ホストコンピュータ１と通信回線Ｎを介して接続されている。２２はＣＰＵ（中央処理装置）であり、ＲＯＭ２３に記憶されたシステムプログラムを実行し、バスＢＵＳを介して接続される装置各部を制御する。また、ＣＰＵ２２は、カラオケデータに基づく演奏や表示を行うとともに、情報ファイルを実行し、各種サービス処理を行う。
【００１４】
２４はハードディスクであり、ホストコンピュータ１から供給されるカラオケデータや情報ファイル群が格納される。また、２５はＲＡＭであり、ＣＰＵ２２のワークエリアとして用いられる。
【００１５】
また、２６は操作パネルであり、操作者による各種キースイッチ（スタートキー、取り消しキー、アップダウンキー、テンキー等）の押圧操作を検出し、該操作に対応した信号をＣＰＵ２２へ供給する。この操作パネル２６においては、選曲（すなわち曲番号の入力）、演奏の開始および中止、ボリューム等のカラオケの演奏のための指示操作の他、ディスプレイ３４に表示される情報選択メニューの選択等が行われる。
【００１６】
また、操作パネル２６には、図３に示すリモコンＲＭＣの送信信号を受信する受信部が設けられている。リモコンＲＭＣは、図３に示すように、スタートキーＳＴＫ、取り消しキーＣＬＫ、アップキーＵＰＫ、ダウンキーＤＷＫ、テンキーＴＫ、転送キーＴＸＫ、メモリセットキーＭＳＫおよび演奏中止キーＳＰＫを有している。このように、リモコンＲＭＣは、操作パネル２６に設けられている各種キーと同様のキーを有しており、操作パネル２６と同じ操作ができるように構成されている。
【００１７】
リモコンＲＭＣ内には、メモリ（図示略）が設けられており、テンキーＴＫについては、一旦メモリに記憶させた後に、操作パネル２６側に転送するようにしている。この場合、テンキーＴＫは、カラオケの曲番号を指定するために用いられ、例えば、曲番号が「１２３４５」である場合は、テンキーＴＫを▲１▼、▲２▼、▲３▼、▲４▼、▲５▼の順で押し、次に、メモリセットキーＭＳＫを押す。これによって、メモリ内に「１２３４５」の数値が一旦記憶される。そして、転送キーＴＸＫを押すと、メモリ内の数値に対応した送信信号が操作パネル２６に転送される。
【００１８】
また、リモコンＲＭＣ上の他のキーについては、当該キーを押せば、それに対応する送信信号が直ちに出力されるようになっている。なお、各キーの機能については後述する。
【００１９】
次に、図２に示す２７は楽音合成装置であり、ＣＰＵ２２によって逐次供給されるＭＩＤＩ情報（カラオケデータや情報ファイルに含まれるＭＩＤＩ情報）に対応した楽音信号を生成し、これをミキサ２８へ出力する。ミキサ２８は、楽音合成装置２７から供給される楽音信号とマイク２９より取り込まれる音声信号とを混合し、これをサウンドシステム３０へ出力する。ただし、ＢＧＭ演奏の場合、ミキサ２８は、楽音合成装置２７から供給される楽音信号をそのままサウンドシステム３０へ出力する。
【００２０】
また、３１は音声デコーダであり、ＣＰＵ２２によって情報ファイルから読み出されるＡＤＰＣＭ情報（音声による案内を行うサービスの際に用いられる）をアナログの音声信号に変換し、これをサウンドシステム３０へ出力する。サウンドシステム３０は、ミキサ２８から供給される楽音信号または音声デコーダから供給される音声信号を増幅し、これをスピーカＳＰより放音させる。
【００２１】
次に、３２は画像再生装置であり、再生指示されたカラオケデータ内の画像制御データに対応した画像情報をＣＤチェンジャー６０内のＣＤ−ＲＯＭ３３から読み出し、これを画像合成装置３４へ転送する。画像合成装置３４は、画像再生装置３２から供給される画像情報と、ＣＰＵ２２によって読み出されるカラオケデータ中の歌詞情報に対応したフォント情報（このフォント情報は、画像合成装置３４に記憶されている。）とを合成し、これをディスプレイ３５に表示させる。これにより、背景画像に歌詞がスパーインポーズされた表示となる。画像合成装置３４は、表示すべき画像を一旦ＶＲＡＭ（ビデオＲＡＭ）にドットマップで展開してから、ディスプレイ３５に出力する。
【００２２】
また、３６は画像デコーダであり、ＣＰＵ２２によって情報ファイルから読み出されるメニュー、アイコン等の静止画あるいは動画の圧縮画像情報（ＭＰＥＧ、ＪＰＥＧ等に準拠した画像情報）を解凍してアナログの映像信号に変換し、これをディスプレイ３５に表示させる。
【００２３】
次に、５０は、カラオケの利用者が硬貨や紙幣を投入する金銭入力装置であり、投入された硬貨や紙幣の真贋を判別するとともに、その額を検出する。金銭入力装置５０は、検出した額を示す信号をＣＰＵ２２に供給する。また、金銭入力装置５０は、ＣＰＵ２２の制御のもとに、つり銭を排出する機能を有している。
【００２４】
また、５５は本体前面に設けられているＬＥＤ表示装置であり、複数桁の７セグメントＬＥＤによって構成されている。このＬＥＤ表示装置５５は、ＣＰＵ２２によって点灯制御される。６０はＣＤチェンジャーであり、ＣＰＵ２２の制御の下にＣＤ（コンパクトディスク）またはＣＤ−ＲＯＭ３３を選択し、指示されたトラックの曲情報を読み出したり、前述のように画像情報を読み出して画像生成装置３３に送出する。７０は、ＩＤカードやクレジットカードを取り扱うカード端末であり、カードからの情報の読み取りや真偽判断を行う。
【００２５】
（３）情報ファイルの内容
本実施形態においては、通常のカラオケ演奏に加えて、情報ファイルに基づく各種情報サービスが行えるようになっているが、情報ファイルはスクリプトと呼ばれるプログラム部分と、リソースと呼ばれる参照データ部分（演奏データ、画像データ等からなる部分）とから構成されており、各種情報サービスは、ＣＰＵ２２がスクリプトを実行することにより提供される。
【００２６】
この場合、スクリプトは、所定の言語体系によって記述され、オブジェクトと呼ばれる処理単位の集合により構成される。また、各オブジェクトにおいては、リソースが適宜参照されるようになっている。この点は図１０を用いて後述する。ここで、図４は、この実施形態において表示される情報サービスメニュー画面の一例であり、この画面表示制御に対応するオブジェクトについて、図５を参照して説明する。
【００２７】
図５に示すオブジェクトは、ページオブジェクトと呼ばれ、一画面の表示を制御するオブジェクトの一例である。ところで、各オブジェクト（すなわち、スクリプトの一部分）は、前述のように、所定の言語によって記述されるが、以下においては、説明の都合上、言語の記述に対応する日本語表記により、そのプログラム上の機能を説明する。
【００２８】
まず、図５に示す「Ｎｅｗ」の欄は、オブジェクトが起動されたときに始めに参照される欄であり、そのオブジェクトの最初の制御内容が記述される。この図の例では、描画（ドロー）についての命令が種々記述されている。
この欄の第１行にある、「絵（＃１）ｏｂｊ」は、絵の表示制御を記述したオブジェクトを指示するものである。絵の表示制御を行うオブジェクトは、表示すべき絵に対応して種々記述されており、「絵（＃１）ｏｂｊ」、「絵（＃２）ｏｂｊ」、……というように、引数（＃１）、（＃２）……が設けられ、引数を指示することで所望のオブジェクトをコールすることができるようになっている。
【００２９】
図７は、「絵（＃１）ｏｂｊ」の記述例を示しており、使用するファイルを指示する行と、その描画位置を示す行の記述を含んでいる。ここで、ファイルとして指定される「＃１画像リソース」は、所定の画像データが記録された画像データファイルであり、前述したようにスクリプトからコールされて参照されるようになっている。この場合、画像リソースについても、オブジェクトと同様に（＃１）、（＃２）……の引数が設けられており、所望のリソースがコールできるようになっている。
【００３０】
この例における「＃１画像リソース」は、動物が自動車に乗っている絵の画像データとなっている。また、この画像データは、図７の第２行において指示された座標に表示される。これらの記述に従った制御（ＣＰＵ２２による制御）が行われることにより、図４（ａ）の部分ａに示すキャラクタ表示が行われる。
【００３１】
次に、図５の「Ｎｅｗ」の欄の第２行、第３行にある、「テキスト（＃１）ｏｂｊ」、「テキスト（＃３）ｏｂｊ」は、文字の表示制御を記述したオブジェクトを指示している。文字の表示制御を行うオブジェクトは、表示すべき文字に対応して種々記述されており、絵オブジェクトと同様に、引数（＃１）、（＃２）……が設けられ、引数を指示することで所望のオブジェクトをコールすることができるようになっている。
【００３２】
図８は、「テキスト（＃ｎ）ｏｂｊ」の記述例を示しており、図示のように、表示すべき文字を指示するｓｔｒｉｎｇ行と、その表示位置を示す行の記述とがある。ここで、テキストオブジェクトにおいては、ファイル指定はなく、ｓｔｒｉｎｇ行によって直接表示文字が指定される。また、テキストオブジェクトについても（＃１）、（＃２）……の引数が設けられており、所望のオブジェクトがコールできるようになっている。
【００３３】
ところで、図４（ａ）の部分ｂは、「ようこそインフォワールドへ！」となっており、また、部分ｃは「コンサート情報」となっている。したがって、これらの表示に対応するテキストオブジェクトのｓｔｒｉｎｇ行は、ｓｔｒｉｎｇ＝”ようこそインフォワールドへ！”およびｓｔｒｉｎｇ＝”コンサート情報”となる。また、テキストオブジェクトにおいては、表示文字のフォントを指示する行もあり（図示略）、これにより、種々のフォントによる表示が可能になっている。
【００３４】
また、図４（ａ）の他のメニュータイトル表示、すなわち、「映画情報」、「ステージ情報」……についても、上記と同様のテキストオブジェクトが、図５に示す「Ｎｅｗ」の欄に記述されている（図示省略）。
また、図４（ａ）の部分ｄ、ｅにおけるアイコン表示部分の図形と文字についても、上述の場合と同様にして絵オブジェクトおよびテキストオブジェクトが記述されている。
【００３５】
次に、図５に示す「Ｄｅｌａｙ」の欄は、同図に示すページオブジェクトが起動されてから所定時間後に行う動作（アクション）を規定する欄であり、図示の例では、５秒後にＢＧＭ（バックグランドミュージック）を演奏する旨が規定されている。すなわち、この欄の（５Ｓ）が５秒後を規定し、ＢＧＭ＝曲（＃１）ｏｂｊが曲オブジェクト（引数＃１）を実行してＢＧＭを演奏する旨を規定している。
【００３６】
ここで、図６は、曲オブジェクトの記述例を示す図である。この図において、第１行のＰｌａｙ＝ＣＤは、図２に示すＣＤチェンジャー６０内の音楽ＣＤ（図示せず）を駆動して演奏を行う命令である。なお、ＣＤチェンジャーに対する選択ディスク番号および演奏トラックなどの詳細を指定する記述もあるが、説明簡略化のため図示省略した。また、図６に示す第２行のＰｌａｙ＝＃１カラオケデータは、カラオケデータとしてハードディスク２４に記録されているもののうち曲番号＃１のものを読み出して演奏せよという命令である。この場合のカラオケデータは、リソースの一部である。
【００３７】
以上のようにして、各種演奏を規定する命令が記述されるが、それらの演奏が終わった際にどのようなアクションを行うかを規定する命令「ｅｎｄ」が記述される場合もある。この命令の内容としては、例えば、他のオブジェクトに処理を移行させたり、あるいは、自らを再度コールして動作を繰り返し、エンドレス演奏を行わせる内容などがある。
【００３８】
次に、図５に示す「Ｓｅｌｅｃｔｏｒ」の欄は、表示画面における各種のボタンに関する事項が記述される。この欄においては、まず、画面に表示されている各ボタンが登録される。図５の例では、ボタンＩＤ＃１、ＩＤ＃２……のようにして、各ボタンを特定する内容の記述が行われる。ここで、図４においては、「コンサート情報」から「カラオケの演奏」までの１１タイトルの各右側において黒丸表示がされているが、これらが上から順にボタンとして定義される。
【００３９】
また、図５の「Ｓｅｌｅｃｔｏｒ」の欄においては、各ボタンについて「ポイント」「アンポイント」「セレクト」の３つの状態におけるアクションが規定される。ここで、「ポイント」とは、そのボタン上にポインタが位置している場合をいい、「アンポイント」とはそのボタン上にポインタが位置していない場合をいい、そして、「セレクト」とはそのボタンが選択（当該ボタンに対応するサービスに入ることが指示された状態）された場合をいう。なお、ポインタの移動や各ボタンの選択は、操作パネル２６またはリモコンＲＭＣのボタン操作によって行うが、その操作案内は、図４のアイコンＩＣ１、ＩＣ２に示されている。
【００４０】
例えば、ポインタＰＰを上下させるには、アイコンＩＣ１の表示にしたがってアップキーＵＰＫ、ダウンキーＤＷＫ（図３参照）を操作し、ボタンを確定させるにはアイコンＩＣ２の表示にしたがってスタートキーＳＴＫ（図３参照）を押す。同様にして、図４に示すメニュー表示を終了する場合には、取り消しキー（ＣＬＫ）を押す。
【００４１】
さて、図５に示す「ポイント」において記述されることには、例えば、当該ボタンの位置にポインタＰＰ（図４参照）を表示させる命令がある。これはポインタＰＰを表示することによって、当該ボタンが選択対象になっていることを操作者に示すためである。また、必要によっては、そのボタンのタイトルに関連するＢＧＭを流すこともあり、この場合には、図５に示すように曲オブジェクト（曲（＃ｎ）ｏｂｊ）が記述される。
【００４２】
次に、「アンポイント」においては、ポインタＰＰの表示を消去させる命令等が記述される。ポインタＰＰの表示を以上のように制御することにより、選択されているボタンの位置だけにポインタＰＰが表示される。
また、「セレクト」においては、当該ボタンが確定選択されたときの実行内容が記述される。実行内容は、一般には、所定のオブジェクトをコールする内容で記述される。
【００４３】
例えば、「コンサート情報」のボタンが選択されたときは、図９（ａ）に示すようなコンサート情報のメニュー表示を制御するオブジェクトが実行され、さらに、図９（ａ）に示す画面のボタンのうち「沢田知可子」のボタンが選択された場合は、当該コンサートの案内画面を制御するオブジェクトが実行され、例えば、図９（ｂ）に示すような表示が行われる。
【００４４】
なお、図４（ａ）に示す画面の「カラオケ演奏」のボタンの下へポインタが移動指示された場合は、残りのメニュー項目を示す画面が表示される（同図（ｂ）参照）。すなわち、「カラオケ演奏」のボタンの下へポインタが移動した場合には、同図（ｂ）に示す画面を表示するためのオブジェクトが起動される。
以上、ページオブジェクを例にとってオブジェクトの記述例を説明したが、オブジェクトによっては、「Ｄｅｌａｙ」の欄の記載はない場合もある。また、上述した説明から明らかなように、小さなオブジェクトの集合によって、所定の目的（例えば、画面制御）を達成するオブジェクトが形成されている。
【００４５】
ところで、オブジェクトの集合がスクリプトであるが、スクリプトとリソースとは、ハードディスク２４内において分離して記憶されている。すなわち、プログラム部分であるスクリプトと、参照データであるリソースとが分離して記憶され、これにより、各オブジェクトにおいて任意のリソースが指定できるようになっている。ここで、図１０は、ハードディスク２４内のスクリプト（オブジェクト）とリソースの記憶状態を概念的に示したものである。そして、同図に示すように、幾つかのオブジェクトによって同一のリソースを共通使用することができ、これによって、ハードディスク２４の記憶エリアの節約およびホストコンピュータ１からのデータ伝送の効率化を図ることができる。
【００４６】
Ｂ：実施形態の動作
（１）情報サービス開始処理
次に、上記構成からなる通信カラオケシステムの動作を説明する。ただし、以下では、ホストコンピュータ１からカラオケ端末２に情報ファイル群およびカラオケデータが既に有る程度供給されていることを前提として説明を進める。
まず、カラオケ端末２に電源が投入されると、ＣＰＵ２２はＲＯＭ２３からシステムプログラムをロードし、これを実行する。これにより、ＣＰＵ２２は、カラオケ演奏待機状態（カラオケモード）に入り、曲番号の入力を待つ。
【００４７】
そして、操作者がリモコンＲＭＣまたは操作パネル２６を操作して曲番号を入力すると、その曲のカラオケデータがハードディスク２４から読み出されて、当該曲の演奏、背景表示および歌詞表示が行われる。利用者は、この演奏と表示に併せ、マイク２９で歌うことによりカラオケを楽しむことができる。
【００４８】
一方、所定の曲番号、例えば、「８０００」が入力されると、ＣＰＵ２２がこれを検知して、情報サービスへ移行する。すなわち、曲番号「８０００」が入力されると、予め用意されているメニュー表示（例えば、図４（ａ）に示すメニュー表示）のオブジェクトが実行される。
【００４９】
本実施形態におけるメニューのオブジェクトには、図１１に示すように、そのヘッダー部分に曲番号が記述されている。この場合のヘッダの記述は、ｓｔｒｉｎｇ行によるタイトルと、曲番号表示の２つが含まれている。また、メニューは図１２に示すように多層になっており、各層のメニューのオブジェクトにもヘッダー部分に曲番号の記述がある。ところで、メニュー階層としては、例えば、図４（ａ）、（ｂ）に示すメニューがトップメニューとすれば、この中の１タイトルである「コンサート情報」を選択確定した際に展開される図９（ａ）のメニューが下位層第１のメニューである。この場合、図４（ａ）、（ｂ）の表示を行うオブジェクトにも、図９の表示を行うオブジェクトにも、そのヘッダーに曲番号が記述されている。
【００５０】
また、サービス自体のオブジェクトのヘッダーにも曲番号の記述がある（図示略）。例えば、図９（ｂ）に示す画面は、コンサートの案内サービスであるが、この表示を行うオブジェクトにも曲番号の記述がある。
ところで、曲番号「８０００」が入力されたときに、既に演奏中のカラオケ曲や予約されたカラオケ曲が存在することがある。この場合の順番管理には以下のとおりである。
【００５１】
カラオケ曲のリクエストがあると、その曲の曲番号が図２に示すＲＡＭ２５内の所定エリアに「キュー」として登録される。そして、複数曲の予約が受け付けられた状態においては、ＲＡＭ２５内に登録されるキューは、例えば、図１３に示すようになる。図１３に示すキュー登録エリアＱＡは、矢印で示すポインタが示す曲番号が次の予約曲になっており、現在演奏中の曲が終了すると、このポインタが指示するアドレスから曲番号が読み出され、当該曲の演奏が開始される。そして、ポインタが移動し、次のアドレスを示す。そして、図１３に示す状態においては、４曲が予約されているが、５曲目が予約されると、４曲目の次のアドレスにその曲の曲番号が書き込まれる。また、図１３に示すキュー登録エリアＱＡは、リングバッファ構造になっており、最終アドレスに曲番号が書き込まれた後は、最初のアドレスに戻って書き込みが行われる。ただし、演奏が終了していないアドレスについては、新たな曲番号は書き込まないようになっているので、キュー登録エリアＱＡが満杯になっているときは、新たな予約を受け付けることができない。
【００５２】
さて、図１３に示す状態において、情報サービスメニューの曲番号が予約されると、情報サービスメニューの曲番号（例えば、８０００番）は、５曲目の予約曲としてキュー登録エリアＱＡに登録される。したがって、４曲目の予約曲の演奏が終了した後に、情報サービスメニューの曲番号が読み出され、トップメニューの表示が行われる。なお、情報サービスメニューの曲番号が予約された後に、通常のカラオケ曲の予約が行われると、その曲のキューは通常の予約処理と同様にして、サービスメニューの曲番号の次のアドレスに登録される。
【００５３】
ところで、本実施形態においては、もう一つのキュー管理モードがある。すなわち、予約曲の後に情報サービスメニューのキューを受け付けるのではなく、現在演奏中の曲が終了した直後に、割込み処理によって情報サービスメニューを開始させるキュー管理である。この場合は、例えば、図１４に示すように、割込み用のエリアＩＡをＲＡＭ２５内に設けておき、情報サービスメニューの曲番号が入力された場合に、これを検知してエリアＩＡに登録する。そして、現在演奏中のカラオケ曲があれば、その曲が終了した後に、エリアＩＡに書き込まれた曲番号の情報サービスメニューの表示処理を割り込んで行う。そして、情報サービスが終了した後に、割込み発生時に待機していた次のキューの処理（カラオケ演奏等）を行う。なお、エリアＩＡに書き込まれた情報サービスメニューの曲番号を、図１３に示すＲＡＭ２５のキュー登録エリアＱＡに割り込ませ、このエリアのキュー配列を書き換えるようにしてもよい。
【００５４】
一方、図１４に示すように、情報サービスメニューの割込みを受け付けるための割込み用リングバッファＩＲＢをＲＡＭ２５内に設定しておき、複数の割込みを順次受け付けるように構成してもよい。この場合においても、割込み用リングバッファＩＲＢ内に登録された全てのキューの実行が終了してから、キュー登録エリアＱＡの次のキューを処理するか、あるいは、割込み用リングバッファＩＲＢに登録されたキューを、キュー登録エリアＱＡに割り込ませるようにして、図１３に示すキュー配列を書き換えてもよい。
【００５５】
また、各層のメニューや情報サービス自体のオブジェクトにも各々曲番号が付されているから、これらを直接入力することにより、トップメニューを通らずに任意の層のメニューを直接展開させたり、所望サービスを直接開始させることができる。この場合のキューの処理については、上述のように、最終受付にするか、割込みにするかの２通りあるが、任意の方式を選択することができる。これについては、操作パネル２６の所定のボタンを操作することによって、ＣＰＵ２２の処理モードを選択すればよい。
【００５６】
（２）自動メニュー生成
ところで、上述したメニューは、各メニューにおける項目（タイトル）や、下位メニューの展開が固定的であったが、この実施形態においては、ＣＰＵ２２が所定のアルゴリズムにしたがって自動的にメニュー生成を行うモードが用意されている。以下においては、この自動メニュー生成処理について説明する。
【００５７】
始めに、各種情報サービスの配信について説明する。さて、本実施形態における情報サービスには、各種宣伝、ゲーム、インフォメーションなどが用意されており、それぞれがジャンル分けされている。また、「宣伝」、「ゲーム」等のジャンル内においても、大人用、子供用、女性用、男性用等の下位のジャンルが設定されている。ここで、情報サービス画面の一例を示すと、図１５は自動車宣伝用のサービス画面の一例であり、また、図１６は新譜照会用のサービス画面の一例である。
【００５８】
上述した宣伝、ゲームあるいはインフォメーション等の各サービス情報は、それらの製作会社によって制作されるが、スクリプトとリソースの組み合わせによって表現され、ＣＰＵ２２によって解読、実行可能な状態になっている。ここで、図１７は、宣伝制作会社によって制作された宣伝用の情報ファイルの配信形態を示す概略図である。図において、ＣＭ１，ＣＭ２，ＣＭ３は、各々広告会社によって制作された宣伝用情報ファイルであり、前述のスクリプトとリソースから成るものである。この宣伝用情報ファイルのヘッダー部分には、曲番号およびタイトルが記述されている。この場合、タイトルの記述は前述のｓｔｒｉｎｇ行による。
【００５９】
そして、図１７に示す情報ファイルは、センタＣＮＴ内のホストコンピュータ１に転送される。ホストコンピュータ１においては、全ての情報ファイルのジャンルを把握している。この場合、図示のように、情報ファイル内にジャンル情報を含ませてもよく、また、曲番号とジャンルとの対応テーブルをホストコンピュータ１に供給するようにしてもよい。さらに、ホストコンピュータ１において、各情報ファイルにジャンル設定することもできる。
【００６０】
次に、カラオケ端末２においては、２通りの方法により、情報ファイルの配信を受ける。第１の方法においては、カラオケ端末２側において、フラグ情報として、店舗情報（どのような種類の店舗（カラオケボックス、スナック……）かを示す情報）、ロケーション（店舗の場所）および所望のジャンルを示す情報をホストコンピュータ１に適宜送信する。これにより、ホストコンピュータ１は、カラオケ端末２に適した宣伝のジャンルを認識し、これに該当する情報ファイルだけをカラオケ端末２に配信する。この結果、カラオケ端末２においては、店舗の状況や顧客の傾向にあった情報ファイルだけを受け取ることができ、効率的な宣伝を行うことができる。
【００６１】
第２の方法においては、ホストコンピュータ１が全ての情報ファイルをカラオケ端末２に配信する。カラオケ端末２においては、時間（午前、午後、深夜など）や期間（季節、夏休み、正月など）を示す情報を入力し、配信された情報ファイルのうち、これらに対応したものだけを選択して使用する。この場合には、時間や期間に対してどのジャンルが適切であるかを示すテーブル等が予め記憶される。また、図１７に示すＩＤカード８０が使用された場合は、そのカードに記録されている個人情報に対応したジャンルの情報ファイルだけを利用可能にする。この場合、ＩＤカード８０には、性別、生年月日、好きな曲のジャンルなどの情報が書き込まれており、図２に示すカード端末装置７０がこの情報を読み取ってＣＰＵ２２に転送すると、ＣＰＵ２２はその利用者の年齢や性別を認識する。そして、この認識に基づいて適切なジャンルを選定し、これに対応する情報ファイルだけを利用可能にする。
【００６２】
以上の説明においては、宣伝用の情報ファイルを例にとって説明したが、ゲームやその他の情報ファイルについても同様の配信および選択処理を行う。
さて、上述のような配信や選択処理を行うと、カラオケ端末２に配信される情報ファイルあるいはカラオケ端末２において利用可能となる情報ファイルは種々変動する。したがって、展開されるメニュー表示もこれに追従することが必要になる。特に、ＩＤカード８０を用いた場合には、利用可能な情報ファイルが利用者毎に変動するので、メニューの追従が一層必要になる。
【００６３】
そこで、この実施形態においてはメニューを自動生成するようにしている。以下においては、ＩＤカード８０を用いた場合のメニュー自動生成を例にとって説明する。
【００６４】
まず、カラオケの利用者は、図２に示すカード端末７０にＩＤカード８０を挿入する。この結果、カード端末７０はＩＤカード８０からＩＤ情報を読み取ってＣＰＵ２２に供給する。次に、ＣＰＵ２２は、供給されたＩＤ情報から利用者の年齢、性別などを認識して対応するジャンルを選定する。例えば、利用者が未成年であった場合は、未成年者に適したジャンルを選定する。この場合の選定としては、例えば、大人用を省いたジャンル選定となる。
【００６５】
次に、利用者が情報サービスのメニューに対応した曲番号をリモコンＲＭＣから入力すると、これに対応したオブジェクトがハードディスク２４から読み出されて実行され、所定のトップメニューが表示される。図１８はトップメニューの一例であり、ここではメニュー項目として「ゲーム」、「トラベル」、「盛り場情報」が表示されている。
【００６６】
次に、いずれかの項目のボタンを選択すると、ＣＰＵ２２は、選定したジャンルに対応する情報ファイルをハードディスク２４から検索し、そのヘッダに記述されているｓｔｒｉｎｇ行のタイトルをメニュー項目として表示する。
今、「ゲーム」の項目のボタンを選択確定したとすると、図１８に示すゲームメニューＧＭ１が表示される。この場合、ゲームメニューのオブジェクトには、ジャンル分類がゲームとなっている情報ファイルのヘッダのｓｔｒｉｎｇ行の部分を表示させるスクリプトが記述されている。
【００６７】
ここで、ダウンキーＤＷＫ（図３参照）によって、次のページを選択すると、ゲームメニューＧＭ２が表示され、さらに、次のページを選択するとゲームメニューＧＭ３が表示される。すなわち、ゲームについては、ゲームメニューＧＭ１〜ＧＭ３が表示され、合計で２３タイトルが表示される。ここで、各ゲームのタイトルは、そのゲームの情報ファイルのヘッダーのｓｔｒｉｎｇ行に記載されているタイトルである。以上のように、ゲームについては、多くのタイトルが表示される。また、各メニュー画面を規定するオブジェクトにおいては、各メニュー項目のタイトルが固定的でなく、選択された情報ファイルのｓｔｒｉｎｇ行のタイトルを表示するような記述になっており、ＣＰＵ２２がこの記述にしたがった表示制御を行うことにより、図１８に示すメニューが自動生成される。
【００６８】
次に、利用者がトップメニュー内の「トラベル」のボタンを選択確定すると、ハードディスク２４内の情報ファイルのうち、トラベルジャンルの情報ファイルが選択され、さらにユーザーＩＤを考慮されることにより、大人用のジャンルが除外されて若人向けの情報ファイルだけが選択され、その情報ファイルのヘッダ部分に記憶されているｓｔｒｉｎｇ行が表示される。図示の例では、１２タイトルが選択されており、メニュー画面ＴＭ１とＴＭ２に分割されている。
【００６９】
また、利用者がトップメニュー内の「盛り場情報」のボタンを確定すると、これに関する情報ファイルは全て大人用のジャンルに分類されているため、選定される情報ファイルはない。このような場合には、図１８に示すように、サービスが選択されない旨の表示、例えば、「だめ！」という文字表示がなされる。このような制御は、「盛り場情報」のボタンが選択確定された際に起動されるオブジェクトにおいて、ＩＤ情報が未成年の場合には、所定のメッセージ表示を行うように記述することによって行われる。
なお、上記の例では大人用を除くジャンル選定を行ったが、大人用のみの選定や、子供用＋女性用という選定の仕方もある。
【００７０】
一方、ＩＤカードを用いない場合は、カラオケ端末２に配信された情報ファイルを全て用いてメニューを作成するが、この場合においても、配信される情報ファイルが適宜異なるので、上述の場合と同様の自動メニュー生成が行われる。
また、ジャンルを示すデータを個別に設けず、曲番号によってジャンル区分をしてもよい。例えば、１０００番台はゲーム、２０００番台はインフォメーションとうように決めてもよい。
さらに、ＩＤ情報によってトップメニューのボタン（各ジャンルのｓｔｒｉｎｇ行）の並べ方（順位）を変えても良い。すなわち、年代層や性別に応じて、選ばれる頻度の高い項目を上位に配置するよに制御してもよい。このような制御は、トップメニューのオブジェクトのボタン配置を、ＩＤ情報に応じて変動するようなスクリプト記述にすればよい。
【００７１】
また、ジャンルが生成されていない場合は、トップメニューの項目を削除してもよい。例えば、トラベルのジャンルに区分される情報ファイルが未だ配信されていない場合は、トップメニューのトラベルの項目を設けないようにしてもよい。
また、情報ファイルのうち、ロケーション（都道府県）にマッチしたものだけを予め抽出または配信し、その結果に対して上述のメニュー自動生成を行っても良い。このようにすることで、各地方に対応したきめ細かい情報サービスを提供することができる。
【００７２】
（３）情報サービスの一例
次に、情報サービスの一例について説明する。
▲１▼ヒット曲の案内とカラオケ演奏
このサービスは、最新のヒット曲２０位までのランキングをスクロール表示するサービスである。また、そのリストの中に歌いたい曲がある場合には、そのリクエストを受け付けるサービスも行う。
【００７３】
ここで、図１９に示す仮想空間ＴＴＡは、ＲＡＭ２５内に設定されるメモリ空間であり、この空間においては、トップ２０の曲番号（図示略）と曲名とが２０位からカウントダウン形式で１位まで展開されている。この展開は、メモリ空間上にビットマップで展開されている。このリストの生成は、スクリプトによって記述されたトップ２０のリストを示すオブジェクトを、ＣＰＵ２２が処理することによって行われる。
【００７４】
そして、同図に示す破線のエリアは、表示対象エリアＤＰＡであり、この表示対象エリアＤＰＡが図示の矢印Ａの方向にずれていく。そして、表示対象エリアＤＰＡ内のドットデータは、画像合成装置３４内のＶＲＡＭに転送され、これによってディスプレイ３５に表示される。したがって、ディスプレイ３５には、トップ２０のリストがスクロール表示される。
このトップ２０の表示を行うオブジェクトにおいては、スクロールスピード、スクロール開始位置、時間およびスクロール終了位置などが記述され、さらに、スクロール終了時の動作なども記述されいてる。したがって、ＣＰＵ２２は、オブジェクトに記述された事項に基づいて、図１９に示す表示対象エリアＤＰＡ（破線参照）の所期位置および移動速度を決定する。以上の動作により、利用者はトップ２０の曲名をスクロールリストによって知ることができる。
【００７５】
次に、この情報サービス（トップ２０曲のスクロール表示）においてカラオケ演奏を開始させる処理について説明する。
まず、曲の選択は、利用者がスクロール中の曲の曲番号を覚えておいてリモコンＲＭＣによって入力してもよく、また、スクロール中の各曲のボタンを選択してもよい。ボタン選択は、図４に示す画面の場合と同様の処理によって行われる。
一方、図２０に示すように、スクロール終了後において、アップキーＵＰＫやダウンキーＤＷＫを操作して、手動により上下に１行ずつスクロールするような制御を行うこともできる。このような場合には、この手動スクロール操作によって所望の曲を表示させた状態にして、その曲のボタンを選択確定すればよい。
【００７６】
以上のようにして、曲の選択がなされると、これらの曲のキューがＲＡＭ２５内の所定エリアＱＡＴ２０（図２０参照）に順次登録される。図２０に示すエリアＱＡＴ２０には、１９位、５位、２位の順で曲が予約されている。また、次の曲が予約されると、その曲のキューは２位の曲の次のアドレスに登録される。このエリアＱＡＴ２０はリングバッファ構造になっており、最終アドレスにキューが登録された後は先頭アドレスに戻って登録が行われる。また、図に示すポインタＰは、次に演奏される曲を示している。
【００７７】
そして、所定のキーを操作することで演奏が開始され、予約キューの演奏がすべて終了するとトップ２０のリストに戻る。また、演奏開始後において、取り消しキーＣＬＫを操作した場合もトップ２０のリスト表示に戻る。
以上のキュー管理は、トップ２０のリスト表示サービスの処理の一部として行われる。なお、これに代えて、情報サービスが終了した後に、エリアＱＡＴ２０に登録されたキューを、通常のカラオケモードにおいて使用されるキュー登録エリアＱＡに転送してもよい。この場合においては、まず、図２０に示す画面表示の案内にしたがって取り消しキーＣＬＫを押す。この結果、情報サービスが終了してカラオケモードに移行し、この際に、エリアＱＡＴ２０に登録されていたキューがキュー登録エリアＱＡに転送される。
【００７８】
ところで、トップ２０のリスト表示サービスが起動される前に、既にキュー登録エリアＱＡに予約曲のキューが登録されている場合は、エリアＱＡＴ２０から転送されるキューは、この予約曲の次のアドレスに登録される。図２０においては、予約曲が既に４曲登録されている状態において、エリアＱＡＴ２０から１９位、５位、２位の曲のキューが転送された場合を示している。
【００７９】
▲２▼動画表示処理
情報サービスの種類によっては、動画を表示させた方が効果的な場合がある。そこで、この実施形態においては、各種動画を表示するようにしている。ここで、ボールが旋回する動画を表示する場合を例にとって、一般的な動画表示制御について説明する。この場合には、ボールの旋回中の各姿態を示す画像データを複数用意し、それらをＶＲＡＭに順次転送して動画表示を行う。例えば、図２５に示すように、ハードディスク２４から旋回途中の姿態を示す画像データ（この例の場合は４つ）をＲＡＭ２５の所定のエリアに転送し、これらを順次切り換えるようにしてＶＲＡＭに転送する。この結果、ボールがあたかも回転しているように表示される（図では左旋回）。この場合、各画像データをハードディスク２４から直接ＶＲＡＭに書き込むこともできるが、ハードディスクからのデータ転送時間は、半導体メモリよりも遅いため、ＶＲＡＭの書換処理に時間がかかり、書換途中の状態が利用者に見えてしまう。このためスムーズな動画表示とならない。
【００８０】
ところで、図２１に示すように、動画の要素となる画像データを全てＲＡＭ２５に転送した後動画表示すると、動画表示はスムーズにいくものの、ＲＡＭ２５のエリアの多くを画像データが占有してしまい、メモリ使用効率が悪い。そこで、本実施形態においては、次のような処理を行っている。
【００８１】
まず、ハードディスク２４から、第１番目の画像データをＲＡＭ２５の所定領域に転送し、次いで、この画像データをＶＲＡＭに転送する。そして、第１番目の画像データが表示されている間に、第２番目の画像データをＲＡＭ２５の同一エリアに上書きする。次いで、第２番目の画像データを所定のタイミング（例えば、垂直ブランキング期間）においてＶＲＡＭに転送する。以後、第３、第４番目の画像データに対しても同様の処理を行い、第４番目の画像データをＶＲＡＭに転送した後は、再び、第１番目の画像データをＲＡＭ２５に転送する。上述した処理を繰り返すことにより、旋回するボールの表示がなされるが、ＲＡＭ２５の使用エリアは、１個の画像データに対応する領域だけであり、また、ＶＲＡＭへの書き込みは、ＲＡＭ２５から行われるため高速である。したがって、メモリ使用効率も高く、また、動画表示もスムーズに行われる。
【００８２】
本実施形態においては、上述のようにメモリの使用効率が高いため、空きエリアを他の用途に使用することができる。例えば、ＭＩＤＩデータや波形データをハードディスク２４から転送しておき、これらを適宜使用して自動演奏や楽音生成を行うことができる。この場合、ＲＡＭ２５からＭＩＤＩデータや波形データを読み出すと、アクセススピードが早いため、音の発生タイミングを高精度に制御することができる。一方、ハードディスクから、ＭＩＤＩデータや波形データを読み出す場合は、アクセススピードが遅いため、音の発生タイミング制御はややラフになる。この実施形態においては、ＲＡＭ２５からの読み出しと、ハードディスク２４からの読み出しの双方を用途に応じて切り換えて用いている。
【００８３】
例えば、スクリプトの記述において、「ＳＥ＝××……」とすればメモリ２５からの読み出しを意味し（この場合は、メモリ２５に予め音データをロードしておく）、「Ｓｏｕｎｄ＝○○……」とすればハードディスク２４からの直接読み出しを意味する。この場合「ＳＥ」は、同期の必要な音データを発生させるために用いられる。
【００８４】
▲３▼課金処理
次に、サービスに料金が必要な場合の課金処理について説明する。今、図２３に示すような階層メニューおよびサービスがあるうち、破線で囲んだ「サービス１」、「サービス２」および「サービス４」が有料サービスであったとする。有料か否かの区別は、課金が必要な情報サービスのスクリプト（オブジェクト）に課金である旨の記述をすることにより行われる。
【００８５】
次に、ＣＰＵ２２による課金チェック処理について説明する。この場合、ＣＰＵ２２は、例えば、図２４に示すフローチャートにしたがって課金チェック処理を行う。まず、ステップＳＰ１において、当該情報サービスが課金サービスか否かを判定する。これはオブジェクトの記述によって判断され、「ＮＯ」であればリターンし、課金チェック処理は行わない。一方、ステップＳＰ１の判定が「ＹＥＳ」であれば、ステップＳＰ２に進み正当なカード（クレジットカード）が使用されているか否かが判定される。この判定は、図２に示すカード端末７０からの検出信号に基づいて行われる。正当なカードが使用されている場合は、カードによる清算を行うため、図２４に示す課金チェック処理から抜ける。一方、カードが使用されていない場合は、ステップＳＰ３に進み現金が不足しているか否かが判定される。
【００８６】
すなわち、図２に示す金銭入力装置５０に投入された硬貨および紙幣の合計額が、これから行うサービスの課金以上であるか否かが判断される。投入金額が不足していない場合は、直ちにサービスに入り、課金チェック処理から抜ける。一方、投入金額が不足している場合は、ステップＳＰ４にでその旨を表示し、ステップＳＰ５に進む。ここで、図２５はステップＳＰ４における表示例である。すなわち、「○○○円不足です。」という案内表示を行う。利用者は、この表示を見て、投入金額が不足していることを知る。そして、利用者が不足金額を金銭入力装置５０に投入すると、金銭入力装置５０から検出信号が出力され、ＣＰＵ２２がこれを認識してステップＳＰ５の判定を「ＹＥＳ」とし、当該課金サービスに入る（ステップＳＰ６）。一方、利用者が図２５に示す案内表示を見て取り消しキーＣＬＫを押した場合、あるいは、一定時間入金がない場合は、ステップＳＰ５の判定が「ＮＯ」となり、当該課金サービスから抜けて、上位のメニュー表示に戻る（ステップＳＰ７）。なお、上位のメニュー表示に戻る代わりに、カラオケモードに戻っても良い。
【００８７】
ところで、課金サービスとしては、例えば、新譜照会サービスなどがある。このサービスにおいては、例えば、前述した図１６に示すような表示が行われ、曲のタイトル、アーティスト名、曲番号からなるテキスト情報が上下方向にスクロールして順次新譜が紹介される。また、この新譜情報とともに、スタートキーＳＴＫの押圧を案内するアイコンＩＣ５の他、紹介画面のタイトル、絵や写真等の画像情報が画面上の固定位置に表示される。
【００８８】
ここで、操作者がスタートキーＳＴＫを押圧すると、アイコンの左に表示されている新譜についての情報ファイルが実行され、その曲のカラオケの演奏またはＣＤ演奏（ＣＤを再生することによる歌入りの演奏）が開始される。この場合、該当するＣＤは、サービスマンによって予めＣＤチェンジャー６０にセットされている。そして、図２４に示す課金チェック処理は、スタートキーＳＴＫが押されたときに起動され、投入金額不足の場合には新譜の演奏は行われない。
【００８９】
また、新譜のカラオケ演奏が開始されて所定時間が経過した後は、取り消しキーＣＬＫの操作を無効にする。キー操作を無効にする制御情報は、オブジェクトに記述し、例えば、所定の条件が満たされたときに所定のキーの信号を無効にするように記述する。また、キーを無効にする手法としてオブジェクトのＤｅｌａｙの欄に記述してもよく、例えば、サービス画面に入ってから５秒後に所定のキーを無効にする、等の記述を行うこともできる。このような制御を行う他の例としては、有料インフォメーションをある時間継続して見たら、取り消しキーを無効にして強制的にそのサービスに入るようにする場合などがある。
【００９０】
ところで、課金サービスには次のような応用が可能である。例えば、その店舗（カラオケボックスなど）における飲み物、食事等の注文を曲番号の入力として受け付け、かつ、この受付サービスを課金サービスとする場合である。これによれば、利用者は、所望の食事等をリモコンで注文することができるとともに、その代金を金銭入力装置に投入することより、清算を済ませることができる。
【００９１】
また、カラオケボックスなどにおいては、部屋のレンタル時間に応じて課金するシステムの店舗があるが、この場合には、レンタル時間を計時するタイマを儲け、このタイマからの時間信号（割込み信号）をＣＰＵ２２が受け付けるようにする。これにより、ＣＰＵ２２は利用者の使用時間の累計を把握することができる。そして、利用者が投入した金額に対応するレンタル時間が満了した後は、図２４に示す課金チェック処理を起動させ、利用者に金額が不足していることを促す。この場合においては、レンタル料の自動清算が可能になる。
【００９２】
▲４▼ログの記録
図２６は、メニューおよび情報サービスのツリーを示している。図示のように１〜８までのメニューおよび情報サービスがある場合、どのメニューあるいは情報サービスがアクセスされたか（あるいは何回アクセスされたか）を記録しておくと、利用状況が把握できて便利である。
【００９３】
そこで、この実施形態においては、図２６に示すように、フラグレジスタＦＬを設け、アクセスのあったメニューおよび情報サービスに対応するビットに“１”を立てるようにしている。この場合、フラグレジスタＦＬの各ビットは、所定のメニューおよび情報サービスに対応しているので、フラグレジスタＦＬの内容をみれば、利用状況を把握することができる。
【００９４】
どのメニューまたはどの情報サービスがアクセスされたかは、どのオブジェクトが実行されたかが判れば把握できるから、ＣＰＵ２２がオブジェクトを実行した際にフラグレジスタＦＬの所定ビットに書き込みを行う。
一方、各メニューや情報サービスが、それぞれ何回アクセスされたかを記録するば、より的確に利用状況を把握することができ好適である。図２７は、このような制御を行う場合の構成の一例を示している。図においては、ＲＡＭ２５内の所定エリアの各アドレスに、各メニューや情報サービスのアクセス回数を記録するようにしている。すなわち、ＣＰＵ２２がオブジェクトを実行する際にどのメニューまたはどの情報サービスが実行されたかを認識し、対応するアドレスのアクセス回数をインクリメントさせる。
【００９５】
以上のような処理を行えば、ＲＡＭ２５内の所定のエリアを見ることにより、極めて詳細な利用状況を把握することができる。さらに、ホストコンピュータ１からの要請がある度、あるいは、所定時間毎に、ＲＡＭ２５内のアクセス回数情報を読み出し、通信インターフェイス２１を介してホストコンピュータ１に転送するように構成してもよい。この場合においては、ホストコンピュータ１において、どのような情報サービスが人気があるかなどの市場調査等も行うことができ、新たな情報サービスの制作などに活かすことができる。
【００９６】
また、ＣＰＵ２２において、アクセス回数の状態から、メニュー内の項目の順位を切り換える等の制御を行うこともできる（例えば、アクセス回数の多いメニューを上位に表示する）。この場合には、アクセス回数の状態から所定のオブジェクトの記述を一部変更し、項目の表示順序を変更する。
【００９７】
▲５▼ＬＥＤ表示
次に、本体の前面に設けられているＬＥＤ表示装置の制御について説明する。一般にカラオケ装置においては、ＬＥＤ表示装置が設けられることが多いが、通常は、予約する曲番号を表示するだけである。
この実施形態においては、単に予約曲の曲番表示だけでなく、さらに、多様な表示を可能にしている。すなわち、ＬＥＤ表示装置５５の制御情報を、各オブジェクトにおいて記述することにより、メニューや情報サービスの特徴に応じた制御を行うようにしている。
【００９８】
例えば、オブジェクトにおいて”ＬＥＤ＝……”という記述がある場合は、ＣＰＵ２２がこの記述内容に応じてＬＥＤ表示装置５５を制御する。例えば、図２８（ａ）は各桁の７セグメントＬＥＤの上部と下部を交互に点灯させ、同図（ｂ）は同図（ａ）の上部点灯と下部点灯を入れ換えている。そして、同図（ａ）と（ｂ）の点灯状態を交互に行うようにすれば、光が動いているようなイルミネーション効果を発揮させることができる。
このように、各オブジェクトによって個別にＬＥＤ表示装置５５の制御情報を記述することにより、メニューや情報サービス毎に変化に富んだＬＥＤ表示を行うことができる。この場合、オブジェクトにおいて、ディスプレイ３５のみの制御だけではなく、ＬＥＤ表示装置の制御までも記述できるような体系としているので、ＬＥＤ制御用の特別なプログラムを別途作成する必要はない。
【００９９】
Ｃ：その他
▲１▼上述した実施形態は、通信カラオケシステムにこの発明を適用した実施形態であったが、本発明は一般的なコンピュータシステムにも勿論適用することができる。例えば、自動メニュー生成処理は、一般的なコンピュータシステムにおいて実行すべきオブジェクトファイルが多数ある場合などは、ジャンル別のリストが自動生成されるので便利である。
【０１００】
【発明の効果】
以上説明したように、この発明によれば、利用者個人の状況に応じて、自動的にメニューを生成することができる。
【図面の簡単な説明】
【図１】 この発明の一実施形態による通信カラオケシステムの全体構成を示すブロック図である。
【図２】 同実施形態におけるカラオケ端末２の構成を示すブロック図である。
【図３】 同実施形態におけるリモコンＲＭＣの操作部を示す正面図である。
【図４】 実施形態において表示される情報サービスメニュー画面の一例である。
【図５】 同実施形態において用いるオブジェクトの内容を示す概念図である。
【図６】 同実施形態における曲オブジェクトの記述例を示す概念図である。
【図７】 同実施形態における「絵（＃１）ｏｂｊ」の記述例を示す概念図である。
【図８】 同実施形態における「テキスト（＃ｎ）ｏｂｊ」の記述例を示す概念図である。
【図９】 同実施形態において表示される情報サービス画面の一例を示す図である。
【図１０】 ハードディスク２４内のスクリプト（オブジェクト）とリソースの記憶状態を示す概念図である。
【図１１】 本実施形態におけるメニューオブジェクトのデータ構造を示す概念図である。
【図１２】 本実施形態における階層メニューの一例を示す説明図である。
【図１３】 本実施形態におけるキュー登録エリアＱＡを示す概念図である。
【図１４】 割込み用のエリアＩＡおよび割込み用リングバッファＩＲＢを示す概念図である。
【図１５】 自動車宣伝用のサービス画面の一例を示す図である。
【図１６】 新譜照会用のサービス画面の一例を示す図である。
【図１７】 宣伝制作会社によって制作された宣伝用の情報ファイルの配信形態を示す概略図である。
【図１８】 トップメニューの一例を示す図である。
【図１９】 ＲＡＭ２５内に設定される仮想空間ＴＴＡを示す概念図である。
【図２０】 スクロール表示終了後の表示画面の一例を示す図である。
【図２１】 一般的な動画表示制御を説明するための説明図である。
【図２２】 本実施形態における動画表示制御を説明するための説明図である
【図２３】 本実施形態における階層メニューの一例を示す図である。
【図２４】 課金チェック処理を示すフローチャートである。
【図２５】 図２４に示すステップＳＰ４における表示例を示す図である。
【図２６】 メニューおよび情報サービスのツリー構造を示す図である。
【図２７】 各情報サービスのアクセス回数記録を行う場合の構成例を示すブロック図である。
【図２８】 ＬＥＤ表示装置５５の表示制御例を示す説明図である。
【符号の説明】
１……ホストコンピュータ、２……カラオケ端末、２１……通信インタフェース、２２……ＣＰＵ、２３……ＲＯＭ、２４……ハードディスク、２５……ＲＯＭ、２６……操作パネル、２７……楽音合成装置、２８……ミキサ、２９……マイク、３０……サウンドシステム、３１……音声デコーダ、３２……画像再生装置、３３……ＣＤ−ＲＯＭ、３４……画像合成装置、３５……ディスプレイ、３６……画像デコーダ、ＢＵＳ……バス、Ｎ……通信回線、ＳＰ……スピーカ。
【発明の属する技術分野】
この発明は、実行すべきオブジェクトファイルが複数ある場合に、そのリストを自動的に作成することができるコンピュータシステムおよび前記コンピュータシステムを有したカラオケ装置に関する。
【０００２】
【従来の技術】
周知のように、センタ局のホストコンピュータからカラオケスナック等の各店舗に設置されたカラオケ端末にカラオケの演奏情報を通信回線を介して供給する通信カラオケシステムが広く普及している。特に、近年においては、曲の演奏の合間の時間を利用して、センタ局から供給されたＣＭ情報を再生しこれを放映する通信カラオケシステムが知られており、カラオケ演奏の合間に流されるＣＭによって新譜紹介やその他種々の情報が利用者に提供されるようになっている。
さらに、ＣＭに限らず、ゲームや旅行案内などの情報サービスを提供するカラオケシステムも考えられている。
【０００３】
【発明が解決しようとする課題】
以上のように、カラオケシステムにおいて提供する情報サービスの種類が多くなると、そのメニュー表示が必要になる。しかしながら、カラオケの各店舗において放映するＣＭや提供する情報サービスが異なることが多いため、各店舗毎にメニュー表示を作成しなければならず煩雑であった。さらに、ＣＭや情報サービスの内容は、季節や時間に応じて変化することがよりニーズに適合し、望ましいが、このようにすると、メニュー表示もその都度変更しなければならないという問題が生じた。
特に、カラオケを利用する各人の年齢、性別、好み等に応じたサービスが提供できれば理想的であるが、この場合には、メニュー表示を各個人別に用意しなければならず、実現が困難であった。また、このような問題は、カラオケ装置に限らず、多様な情報サービスを行うコンピュータシステムにおいても同様に発生する。
【０００４】
この発明は、このような背景の下になされたもので、コンピュータシステムやカラオケ装置において、利用者個人の状況に応じて、自動的にメニューを生成することができるコンピュータシステムおよびカラオケ装置を提供することを目的としている。
【０００５】
【課題を解決するための手段】
上述した課題を解決するために、請求項１記載の発明は、プログラムおよびジャンル情報を含むオブジェクトファイルを複数記憶する記憶手段を有し、前記記憶手段からオブジェクトファイルを選択するとともに、選択したオブジェクトファイル内のプログラムを実行するコンピュータシステムであって、利用者の個人情報を含むＩＤ情報を読み取るＩＤ情報読取手段と、前記ＩＤ情報読取手段が読み取った個人情報に対応した個人別ジャンルを判定するジャンル判定手段と、利用者の操作に応じて指定ジャンルを決定するジャンル決定手段と、前記ジャンル決定手段が決定した指定ジャンルおよび前記ジャンル判定手段が判定した個人別ジャンルの双方に合致するオブジェクトファイルを検索する検索手段と、前記検索手段によって検索されたオブジェクトファイルに対応したタイトルによって構成されるリストを生成するリスト生成手段と、前記リスト生成手段が生成したリストを表示する表示手段とを具備することを特徴とする。
【０００６】
また、請求項２に記載の発明にあっては、請求項１記載のコンピュータシステムにおいて、前記各オブジェクトファイルは、その内容に対応したタイトルを表示するためのタイトル情報を有し、前記リスト生成手段は前記検索手段によって検索されたオブジェクトファイル内のタイトル情報に基づいて前記リストを生成することを特徴とする。
【０００８】
また、請求項３に記載の発明にあっては、請求項１または２に記載のコンピュータシステムを有するとともに、前記記憶手段にカラオケの演奏情報を格納するカラオケ装置において、さらに、前記記憶手段からカラオケの演奏を読み出して楽音を合成し、この合成音とマイクから入力される音声とを混合して出力するカラオケ演奏手段と、前記オブジェクトファイルの実行と前記カラオケ演奏手段によるカラオケ演奏のいずれかを切り換える切換手段とを有することを特徴とする。
【０００９】
また、請求項４に記載の発明にあっては、請求項３記載のカラオケ装置において、前記オブジェクトファイルのプログラム中に前記カラオケ演奏手段によるカラオケ演奏が選択可能な命令として記述されていることを特徴とする。
【００１０】
また、請求項５に記載の発明にあっては、請求項３または４記載のカラオケ装置において、前記ＩＤ情報は、ＩＤカードに記憶され、前記ＩＤ情報読取手段は、ＩＤカード読取装置によって構成されていることを特徴とする。
【００１１】
【発明の実施の形態】
以下、図面を参照して、この発明の実施形態について説明する。
Ａ：実施形態の構成
（１）全体構成
図１はこの発明の一実施形態による通信カラオケシステムの構成を示すブロック図である。図１において、１はホストコンピュータであり、２，２，……はホストコンピュータ１と通信回線Ｎを介して接続される複数のカラオケ端末である。ホストコンピュータ１は、カラオケデータと情報ファイル（詳細は後述）を各カラオケ端末２，２，……に定期的に配信する。カラオケデータには、演奏データ（ＭＩＤＩデータ）、歌詞データ（演奏と歌詞とを同期させるデータを含む）および画像制御データ（カラオケ端末２側で用意している画像を選択するデータ）が含まれており、カラオケ端末２は、演奏データに基づく伴奏演奏、歌詞データに基づく歌詞表示および画像制御データに対応した画像表示を行うようになっている。
【００１２】
また、カラオケ端末２は、ホストコンピュータ１から供給される情報ファイルを実行することによって、操作者との対話形式で各種情報サービスを提供するようになっている。
【００１３】
（２）カラオケ端末の構成
次に、図２を参照し、カラオケ端末２の構成について説明する。
図２において、２１はモデムあるいはＩＳＤＮ（Integrated Sarvices Digital Network）等の通信インタフェースであり、ホストコンピュータ１と通信回線Ｎを介して接続されている。２２はＣＰＵ（中央処理装置）であり、ＲＯＭ２３に記憶されたシステムプログラムを実行し、バスＢＵＳを介して接続される装置各部を制御する。また、ＣＰＵ２２は、カラオケデータに基づく演奏や表示を行うとともに、情報ファイルを実行し、各種サービス処理を行う。
【００１４】
２４はハードディスクであり、ホストコンピュータ１から供給されるカラオケデータや情報ファイル群が格納される。また、２５はＲＡＭであり、ＣＰＵ２２のワークエリアとして用いられる。
【００１５】
また、２６は操作パネルであり、操作者による各種キースイッチ（スタートキー、取り消しキー、アップダウンキー、テンキー等）の押圧操作を検出し、該操作に対応した信号をＣＰＵ２２へ供給する。この操作パネル２６においては、選曲（すなわち曲番号の入力）、演奏の開始および中止、ボリューム等のカラオケの演奏のための指示操作の他、ディスプレイ３４に表示される情報選択メニューの選択等が行われる。
【００１６】
また、操作パネル２６には、図３に示すリモコンＲＭＣの送信信号を受信する受信部が設けられている。リモコンＲＭＣは、図３に示すように、スタートキーＳＴＫ、取り消しキーＣＬＫ、アップキーＵＰＫ、ダウンキーＤＷＫ、テンキーＴＫ、転送キーＴＸＫ、メモリセットキーＭＳＫおよび演奏中止キーＳＰＫを有している。このように、リモコンＲＭＣは、操作パネル２６に設けられている各種キーと同様のキーを有しており、操作パネル２６と同じ操作ができるように構成されている。
【００１７】
リモコンＲＭＣ内には、メモリ（図示略）が設けられており、テンキーＴＫについては、一旦メモリに記憶させた後に、操作パネル２６側に転送するようにしている。この場合、テンキーＴＫは、カラオケの曲番号を指定するために用いられ、例えば、曲番号が「１２３４５」である場合は、テンキーＴＫを▲１▼、▲２▼、▲３▼、▲４▼、▲５▼の順で押し、次に、メモリセットキーＭＳＫを押す。これによって、メモリ内に「１２３４５」の数値が一旦記憶される。そして、転送キーＴＸＫを押すと、メモリ内の数値に対応した送信信号が操作パネル２６に転送される。
【００１８】
また、リモコンＲＭＣ上の他のキーについては、当該キーを押せば、それに対応する送信信号が直ちに出力されるようになっている。なお、各キーの機能については後述する。
【００１９】
次に、図２に示す２７は楽音合成装置であり、ＣＰＵ２２によって逐次供給されるＭＩＤＩ情報（カラオケデータや情報ファイルに含まれるＭＩＤＩ情報）に対応した楽音信号を生成し、これをミキサ２８へ出力する。ミキサ２８は、楽音合成装置２７から供給される楽音信号とマイク２９より取り込まれる音声信号とを混合し、これをサウンドシステム３０へ出力する。ただし、ＢＧＭ演奏の場合、ミキサ２８は、楽音合成装置２７から供給される楽音信号をそのままサウンドシステム３０へ出力する。
【００２０】
また、３１は音声デコーダであり、ＣＰＵ２２によって情報ファイルから読み出されるＡＤＰＣＭ情報（音声による案内を行うサービスの際に用いられる）をアナログの音声信号に変換し、これをサウンドシステム３０へ出力する。サウンドシステム３０は、ミキサ２８から供給される楽音信号または音声デコーダから供給される音声信号を増幅し、これをスピーカＳＰより放音させる。
【００２１】
次に、３２は画像再生装置であり、再生指示されたカラオケデータ内の画像制御データに対応した画像情報をＣＤチェンジャー６０内のＣＤ−ＲＯＭ３３から読み出し、これを画像合成装置３４へ転送する。画像合成装置３４は、画像再生装置３２から供給される画像情報と、ＣＰＵ２２によって読み出されるカラオケデータ中の歌詞情報に対応したフォント情報（このフォント情報は、画像合成装置３４に記憶されている。）とを合成し、これをディスプレイ３５に表示させる。これにより、背景画像に歌詞がスパーインポーズされた表示となる。画像合成装置３４は、表示すべき画像を一旦ＶＲＡＭ（ビデオＲＡＭ）にドットマップで展開してから、ディスプレイ３５に出力する。
【００２２】
また、３６は画像デコーダであり、ＣＰＵ２２によって情報ファイルから読み出されるメニュー、アイコン等の静止画あるいは動画の圧縮画像情報（ＭＰＥＧ、ＪＰＥＧ等に準拠した画像情報）を解凍してアナログの映像信号に変換し、これをディスプレイ３５に表示させる。
【００２３】
次に、５０は、カラオケの利用者が硬貨や紙幣を投入する金銭入力装置であり、投入された硬貨や紙幣の真贋を判別するとともに、その額を検出する。金銭入力装置５０は、検出した額を示す信号をＣＰＵ２２に供給する。また、金銭入力装置５０は、ＣＰＵ２２の制御のもとに、つり銭を排出する機能を有している。
【００２４】
また、５５は本体前面に設けられているＬＥＤ表示装置であり、複数桁の７セグメントＬＥＤによって構成されている。このＬＥＤ表示装置５５は、ＣＰＵ２２によって点灯制御される。６０はＣＤチェンジャーであり、ＣＰＵ２２の制御の下にＣＤ（コンパクトディスク）またはＣＤ−ＲＯＭ３３を選択し、指示されたトラックの曲情報を読み出したり、前述のように画像情報を読み出して画像生成装置３３に送出する。７０は、ＩＤカードやクレジットカードを取り扱うカード端末であり、カードからの情報の読み取りや真偽判断を行う。
【００２５】
（３）情報ファイルの内容
本実施形態においては、通常のカラオケ演奏に加えて、情報ファイルに基づく各種情報サービスが行えるようになっているが、情報ファイルはスクリプトと呼ばれるプログラム部分と、リソースと呼ばれる参照データ部分（演奏データ、画像データ等からなる部分）とから構成されており、各種情報サービスは、ＣＰＵ２２がスクリプトを実行することにより提供される。
【００２６】
この場合、スクリプトは、所定の言語体系によって記述され、オブジェクトと呼ばれる処理単位の集合により構成される。また、各オブジェクトにおいては、リソースが適宜参照されるようになっている。この点は図１０を用いて後述する。ここで、図４は、この実施形態において表示される情報サービスメニュー画面の一例であり、この画面表示制御に対応するオブジェクトについて、図５を参照して説明する。
【００２７】
図５に示すオブジェクトは、ページオブジェクトと呼ばれ、一画面の表示を制御するオブジェクトの一例である。ところで、各オブジェクト（すなわち、スクリプトの一部分）は、前述のように、所定の言語によって記述されるが、以下においては、説明の都合上、言語の記述に対応する日本語表記により、そのプログラム上の機能を説明する。
【００２８】
まず、図５に示す「Ｎｅｗ」の欄は、オブジェクトが起動されたときに始めに参照される欄であり、そのオブジェクトの最初の制御内容が記述される。この図の例では、描画（ドロー）についての命令が種々記述されている。
この欄の第１行にある、「絵（＃１）ｏｂｊ」は、絵の表示制御を記述したオブジェクトを指示するものである。絵の表示制御を行うオブジェクトは、表示すべき絵に対応して種々記述されており、「絵（＃１）ｏｂｊ」、「絵（＃２）ｏｂｊ」、……というように、引数（＃１）、（＃２）……が設けられ、引数を指示することで所望のオブジェクトをコールすることができるようになっている。
【００２９】
図７は、「絵（＃１）ｏｂｊ」の記述例を示しており、使用するファイルを指示する行と、その描画位置を示す行の記述を含んでいる。ここで、ファイルとして指定される「＃１画像リソース」は、所定の画像データが記録された画像データファイルであり、前述したようにスクリプトからコールされて参照されるようになっている。この場合、画像リソースについても、オブジェクトと同様に（＃１）、（＃２）……の引数が設けられており、所望のリソースがコールできるようになっている。
【００３０】
この例における「＃１画像リソース」は、動物が自動車に乗っている絵の画像データとなっている。また、この画像データは、図７の第２行において指示された座標に表示される。これらの記述に従った制御（ＣＰＵ２２による制御）が行われることにより、図４（ａ）の部分ａに示すキャラクタ表示が行われる。
【００３１】
次に、図５の「Ｎｅｗ」の欄の第２行、第３行にある、「テキスト（＃１）ｏｂｊ」、「テキスト（＃３）ｏｂｊ」は、文字の表示制御を記述したオブジェクトを指示している。文字の表示制御を行うオブジェクトは、表示すべき文字に対応して種々記述されており、絵オブジェクトと同様に、引数（＃１）、（＃２）……が設けられ、引数を指示することで所望のオブジェクトをコールすることができるようになっている。
【００３２】
図８は、「テキスト（＃ｎ）ｏｂｊ」の記述例を示しており、図示のように、表示すべき文字を指示するｓｔｒｉｎｇ行と、その表示位置を示す行の記述とがある。ここで、テキストオブジェクトにおいては、ファイル指定はなく、ｓｔｒｉｎｇ行によって直接表示文字が指定される。また、テキストオブジェクトについても（＃１）、（＃２）……の引数が設けられており、所望のオブジェクトがコールできるようになっている。
【００３３】
ところで、図４（ａ）の部分ｂは、「ようこそインフォワールドへ！」となっており、また、部分ｃは「コンサート情報」となっている。したがって、これらの表示に対応するテキストオブジェクトのｓｔｒｉｎｇ行は、ｓｔｒｉｎｇ＝”ようこそインフォワールドへ！”およびｓｔｒｉｎｇ＝”コンサート情報”となる。また、テキストオブジェクトにおいては、表示文字のフォントを指示する行もあり（図示略）、これにより、種々のフォントによる表示が可能になっている。
【００３４】
また、図４（ａ）の他のメニュータイトル表示、すなわち、「映画情報」、「ステージ情報」……についても、上記と同様のテキストオブジェクトが、図５に示す「Ｎｅｗ」の欄に記述されている（図示省略）。
また、図４（ａ）の部分ｄ、ｅにおけるアイコン表示部分の図形と文字についても、上述の場合と同様にして絵オブジェクトおよびテキストオブジェクトが記述されている。
【００３５】
次に、図５に示す「Ｄｅｌａｙ」の欄は、同図に示すページオブジェクトが起動されてから所定時間後に行う動作（アクション）を規定する欄であり、図示の例では、５秒後にＢＧＭ（バックグランドミュージック）を演奏する旨が規定されている。すなわち、この欄の（５Ｓ）が５秒後を規定し、ＢＧＭ＝曲（＃１）ｏｂｊが曲オブジェクト（引数＃１）を実行してＢＧＭを演奏する旨を規定している。
【００３６】
ここで、図６は、曲オブジェクトの記述例を示す図である。この図において、第１行のＰｌａｙ＝ＣＤは、図２に示すＣＤチェンジャー６０内の音楽ＣＤ（図示せず）を駆動して演奏を行う命令である。なお、ＣＤチェンジャーに対する選択ディスク番号および演奏トラックなどの詳細を指定する記述もあるが、説明簡略化のため図示省略した。また、図６に示す第２行のＰｌａｙ＝＃１カラオケデータは、カラオケデータとしてハードディスク２４に記録されているもののうち曲番号＃１のものを読み出して演奏せよという命令である。この場合のカラオケデータは、リソースの一部である。
【００３７】
以上のようにして、各種演奏を規定する命令が記述されるが、それらの演奏が終わった際にどのようなアクションを行うかを規定する命令「ｅｎｄ」が記述される場合もある。この命令の内容としては、例えば、他のオブジェクトに処理を移行させたり、あるいは、自らを再度コールして動作を繰り返し、エンドレス演奏を行わせる内容などがある。
【００３８】
次に、図５に示す「Ｓｅｌｅｃｔｏｒ」の欄は、表示画面における各種のボタンに関する事項が記述される。この欄においては、まず、画面に表示されている各ボタンが登録される。図５の例では、ボタンＩＤ＃１、ＩＤ＃２……のようにして、各ボタンを特定する内容の記述が行われる。ここで、図４においては、「コンサート情報」から「カラオケの演奏」までの１１タイトルの各右側において黒丸表示がされているが、これらが上から順にボタンとして定義される。
【００３９】
また、図５の「Ｓｅｌｅｃｔｏｒ」の欄においては、各ボタンについて「ポイント」「アンポイント」「セレクト」の３つの状態におけるアクションが規定される。ここで、「ポイント」とは、そのボタン上にポインタが位置している場合をいい、「アンポイント」とはそのボタン上にポインタが位置していない場合をいい、そして、「セレクト」とはそのボタンが選択（当該ボタンに対応するサービスに入ることが指示された状態）された場合をいう。なお、ポインタの移動や各ボタンの選択は、操作パネル２６またはリモコンＲＭＣのボタン操作によって行うが、その操作案内は、図４のアイコンＩＣ１、ＩＣ２に示されている。
【００４０】
例えば、ポインタＰＰを上下させるには、アイコンＩＣ１の表示にしたがってアップキーＵＰＫ、ダウンキーＤＷＫ（図３参照）を操作し、ボタンを確定させるにはアイコンＩＣ２の表示にしたがってスタートキーＳＴＫ（図３参照）を押す。同様にして、図４に示すメニュー表示を終了する場合には、取り消しキー（ＣＬＫ）を押す。
【００４１】
さて、図５に示す「ポイント」において記述されることには、例えば、当該ボタンの位置にポインタＰＰ（図４参照）を表示させる命令がある。これはポインタＰＰを表示することによって、当該ボタンが選択対象になっていることを操作者に示すためである。また、必要によっては、そのボタンのタイトルに関連するＢＧＭを流すこともあり、この場合には、図５に示すように曲オブジェクト（曲（＃ｎ）ｏｂｊ）が記述される。
【００４２】
次に、「アンポイント」においては、ポインタＰＰの表示を消去させる命令等が記述される。ポインタＰＰの表示を以上のように制御することにより、選択されているボタンの位置だけにポインタＰＰが表示される。
また、「セレクト」においては、当該ボタンが確定選択されたときの実行内容が記述される。実行内容は、一般には、所定のオブジェクトをコールする内容で記述される。
【００４３】
例えば、「コンサート情報」のボタンが選択されたときは、図９（ａ）に示すようなコンサート情報のメニュー表示を制御するオブジェクトが実行され、さらに、図９（ａ）に示す画面のボタンのうち「沢田知可子」のボタンが選択された場合は、当該コンサートの案内画面を制御するオブジェクトが実行され、例えば、図９（ｂ）に示すような表示が行われる。
【００４４】
なお、図４（ａ）に示す画面の「カラオケ演奏」のボタンの下へポインタが移動指示された場合は、残りのメニュー項目を示す画面が表示される（同図（ｂ）参照）。すなわち、「カラオケ演奏」のボタンの下へポインタが移動した場合には、同図（ｂ）に示す画面を表示するためのオブジェクトが起動される。
以上、ページオブジェクを例にとってオブジェクトの記述例を説明したが、オブジェクトによっては、「Ｄｅｌａｙ」の欄の記載はない場合もある。また、上述した説明から明らかなように、小さなオブジェクトの集合によって、所定の目的（例えば、画面制御）を達成するオブジェクトが形成されている。
【００４５】
ところで、オブジェクトの集合がスクリプトであるが、スクリプトとリソースとは、ハードディスク２４内において分離して記憶されている。すなわち、プログラム部分であるスクリプトと、参照データであるリソースとが分離して記憶され、これにより、各オブジェクトにおいて任意のリソースが指定できるようになっている。ここで、図１０は、ハードディスク２４内のスクリプト（オブジェクト）とリソースの記憶状態を概念的に示したものである。そして、同図に示すように、幾つかのオブジェクトによって同一のリソースを共通使用することができ、これによって、ハードディスク２４の記憶エリアの節約およびホストコンピュータ１からのデータ伝送の効率化を図ることができる。
【００４６】
Ｂ：実施形態の動作
（１）情報サービス開始処理
次に、上記構成からなる通信カラオケシステムの動作を説明する。ただし、以下では、ホストコンピュータ１からカラオケ端末２に情報ファイル群およびカラオケデータが既に有る程度供給されていることを前提として説明を進める。
まず、カラオケ端末２に電源が投入されると、ＣＰＵ２２はＲＯＭ２３からシステムプログラムをロードし、これを実行する。これにより、ＣＰＵ２２は、カラオケ演奏待機状態（カラオケモード）に入り、曲番号の入力を待つ。
【００４７】
そして、操作者がリモコンＲＭＣまたは操作パネル２６を操作して曲番号を入力すると、その曲のカラオケデータがハードディスク２４から読み出されて、当該曲の演奏、背景表示および歌詞表示が行われる。利用者は、この演奏と表示に併せ、マイク２９で歌うことによりカラオケを楽しむことができる。
【００４８】
一方、所定の曲番号、例えば、「８０００」が入力されると、ＣＰＵ２２がこれを検知して、情報サービスへ移行する。すなわち、曲番号「８０００」が入力されると、予め用意されているメニュー表示（例えば、図４（ａ）に示すメニュー表示）のオブジェクトが実行される。
【００４９】
本実施形態におけるメニューのオブジェクトには、図１１に示すように、そのヘッダー部分に曲番号が記述されている。この場合のヘッダの記述は、ｓｔｒｉｎｇ行によるタイトルと、曲番号表示の２つが含まれている。また、メニューは図１２に示すように多層になっており、各層のメニューのオブジェクトにもヘッダー部分に曲番号の記述がある。ところで、メニュー階層としては、例えば、図４（ａ）、（ｂ）に示すメニューがトップメニューとすれば、この中の１タイトルである「コンサート情報」を選択確定した際に展開される図９（ａ）のメニューが下位層第１のメニューである。この場合、図４（ａ）、（ｂ）の表示を行うオブジェクトにも、図９の表示を行うオブジェクトにも、そのヘッダーに曲番号が記述されている。
【００５０】
また、サービス自体のオブジェクトのヘッダーにも曲番号の記述がある（図示略）。例えば、図９（ｂ）に示す画面は、コンサートの案内サービスであるが、この表示を行うオブジェクトにも曲番号の記述がある。
ところで、曲番号「８０００」が入力されたときに、既に演奏中のカラオケ曲や予約されたカラオケ曲が存在することがある。この場合の順番管理には以下のとおりである。
【００５１】
カラオケ曲のリクエストがあると、その曲の曲番号が図２に示すＲＡＭ２５内の所定エリアに「キュー」として登録される。そして、複数曲の予約が受け付けられた状態においては、ＲＡＭ２５内に登録されるキューは、例えば、図１３に示すようになる。図１３に示すキュー登録エリアＱＡは、矢印で示すポインタが示す曲番号が次の予約曲になっており、現在演奏中の曲が終了すると、このポインタが指示するアドレスから曲番号が読み出され、当該曲の演奏が開始される。そして、ポインタが移動し、次のアドレスを示す。そして、図１３に示す状態においては、４曲が予約されているが、５曲目が予約されると、４曲目の次のアドレスにその曲の曲番号が書き込まれる。また、図１３に示すキュー登録エリアＱＡは、リングバッファ構造になっており、最終アドレスに曲番号が書き込まれた後は、最初のアドレスに戻って書き込みが行われる。ただし、演奏が終了していないアドレスについては、新たな曲番号は書き込まないようになっているので、キュー登録エリアＱＡが満杯になっているときは、新たな予約を受け付けることができない。
【００５２】
さて、図１３に示す状態において、情報サービスメニューの曲番号が予約されると、情報サービスメニューの曲番号（例えば、８０００番）は、５曲目の予約曲としてキュー登録エリアＱＡに登録される。したがって、４曲目の予約曲の演奏が終了した後に、情報サービスメニューの曲番号が読み出され、トップメニューの表示が行われる。なお、情報サービスメニューの曲番号が予約された後に、通常のカラオケ曲の予約が行われると、その曲のキューは通常の予約処理と同様にして、サービスメニューの曲番号の次のアドレスに登録される。
【００５３】
ところで、本実施形態においては、もう一つのキュー管理モードがある。すなわち、予約曲の後に情報サービスメニューのキューを受け付けるのではなく、現在演奏中の曲が終了した直後に、割込み処理によって情報サービスメニューを開始させるキュー管理である。この場合は、例えば、図１４に示すように、割込み用のエリアＩＡをＲＡＭ２５内に設けておき、情報サービスメニューの曲番号が入力された場合に、これを検知してエリアＩＡに登録する。そして、現在演奏中のカラオケ曲があれば、その曲が終了した後に、エリアＩＡに書き込まれた曲番号の情報サービスメニューの表示処理を割り込んで行う。そして、情報サービスが終了した後に、割込み発生時に待機していた次のキューの処理（カラオケ演奏等）を行う。なお、エリアＩＡに書き込まれた情報サービスメニューの曲番号を、図１３に示すＲＡＭ２５のキュー登録エリアＱＡに割り込ませ、このエリアのキュー配列を書き換えるようにしてもよい。
【００５４】
一方、図１４に示すように、情報サービスメニューの割込みを受け付けるための割込み用リングバッファＩＲＢをＲＡＭ２５内に設定しておき、複数の割込みを順次受け付けるように構成してもよい。この場合においても、割込み用リングバッファＩＲＢ内に登録された全てのキューの実行が終了してから、キュー登録エリアＱＡの次のキューを処理するか、あるいは、割込み用リングバッファＩＲＢに登録されたキューを、キュー登録エリアＱＡに割り込ませるようにして、図１３に示すキュー配列を書き換えてもよい。
【００５５】
また、各層のメニューや情報サービス自体のオブジェクトにも各々曲番号が付されているから、これらを直接入力することにより、トップメニューを通らずに任意の層のメニューを直接展開させたり、所望サービスを直接開始させることができる。この場合のキューの処理については、上述のように、最終受付にするか、割込みにするかの２通りあるが、任意の方式を選択することができる。これについては、操作パネル２６の所定のボタンを操作することによって、ＣＰＵ２２の処理モードを選択すればよい。
【００５６】
（２）自動メニュー生成
ところで、上述したメニューは、各メニューにおける項目（タイトル）や、下位メニューの展開が固定的であったが、この実施形態においては、ＣＰＵ２２が所定のアルゴリズムにしたがって自動的にメニュー生成を行うモードが用意されている。以下においては、この自動メニュー生成処理について説明する。
【００５７】
始めに、各種情報サービスの配信について説明する。さて、本実施形態における情報サービスには、各種宣伝、ゲーム、インフォメーションなどが用意されており、それぞれがジャンル分けされている。また、「宣伝」、「ゲーム」等のジャンル内においても、大人用、子供用、女性用、男性用等の下位のジャンルが設定されている。ここで、情報サービス画面の一例を示すと、図１５は自動車宣伝用のサービス画面の一例であり、また、図１６は新譜照会用のサービス画面の一例である。
【００５８】
上述した宣伝、ゲームあるいはインフォメーション等の各サービス情報は、それらの製作会社によって制作されるが、スクリプトとリソースの組み合わせによって表現され、ＣＰＵ２２によって解読、実行可能な状態になっている。ここで、図１７は、宣伝制作会社によって制作された宣伝用の情報ファイルの配信形態を示す概略図である。図において、ＣＭ１，ＣＭ２，ＣＭ３は、各々広告会社によって制作された宣伝用情報ファイルであり、前述のスクリプトとリソースから成るものである。この宣伝用情報ファイルのヘッダー部分には、曲番号およびタイトルが記述されている。この場合、タイトルの記述は前述のｓｔｒｉｎｇ行による。
【００５９】
そして、図１７に示す情報ファイルは、センタＣＮＴ内のホストコンピュータ１に転送される。ホストコンピュータ１においては、全ての情報ファイルのジャンルを把握している。この場合、図示のように、情報ファイル内にジャンル情報を含ませてもよく、また、曲番号とジャンルとの対応テーブルをホストコンピュータ１に供給するようにしてもよい。さらに、ホストコンピュータ１において、各情報ファイルにジャンル設定することもできる。
【００６０】
次に、カラオケ端末２においては、２通りの方法により、情報ファイルの配信を受ける。第１の方法においては、カラオケ端末２側において、フラグ情報として、店舗情報（どのような種類の店舗（カラオケボックス、スナック……）かを示す情報）、ロケーション（店舗の場所）および所望のジャンルを示す情報をホストコンピュータ１に適宜送信する。これにより、ホストコンピュータ１は、カラオケ端末２に適した宣伝のジャンルを認識し、これに該当する情報ファイルだけをカラオケ端末２に配信する。この結果、カラオケ端末２においては、店舗の状況や顧客の傾向にあった情報ファイルだけを受け取ることができ、効率的な宣伝を行うことができる。
【００６１】
第２の方法においては、ホストコンピュータ１が全ての情報ファイルをカラオケ端末２に配信する。カラオケ端末２においては、時間（午前、午後、深夜など）や期間（季節、夏休み、正月など）を示す情報を入力し、配信された情報ファイルのうち、これらに対応したものだけを選択して使用する。この場合には、時間や期間に対してどのジャンルが適切であるかを示すテーブル等が予め記憶される。また、図１７に示すＩＤカード８０が使用された場合は、そのカードに記録されている個人情報に対応したジャンルの情報ファイルだけを利用可能にする。この場合、ＩＤカード８０には、性別、生年月日、好きな曲のジャンルなどの情報が書き込まれており、図２に示すカード端末装置７０がこの情報を読み取ってＣＰＵ２２に転送すると、ＣＰＵ２２はその利用者の年齢や性別を認識する。そして、この認識に基づいて適切なジャンルを選定し、これに対応する情報ファイルだけを利用可能にする。
【００６２】
以上の説明においては、宣伝用の情報ファイルを例にとって説明したが、ゲームやその他の情報ファイルについても同様の配信および選択処理を行う。
さて、上述のような配信や選択処理を行うと、カラオケ端末２に配信される情報ファイルあるいはカラオケ端末２において利用可能となる情報ファイルは種々変動する。したがって、展開されるメニュー表示もこれに追従することが必要になる。特に、ＩＤカード８０を用いた場合には、利用可能な情報ファイルが利用者毎に変動するので、メニューの追従が一層必要になる。
【００６３】
そこで、この実施形態においてはメニューを自動生成するようにしている。以下においては、ＩＤカード８０を用いた場合のメニュー自動生成を例にとって説明する。
【００６４】
まず、カラオケの利用者は、図２に示すカード端末７０にＩＤカード８０を挿入する。この結果、カード端末７０はＩＤカード８０からＩＤ情報を読み取ってＣＰＵ２２に供給する。次に、ＣＰＵ２２は、供給されたＩＤ情報から利用者の年齢、性別などを認識して対応するジャンルを選定する。例えば、利用者が未成年であった場合は、未成年者に適したジャンルを選定する。この場合の選定としては、例えば、大人用を省いたジャンル選定となる。
【００６５】
次に、利用者が情報サービスのメニューに対応した曲番号をリモコンＲＭＣから入力すると、これに対応したオブジェクトがハードディスク２４から読み出されて実行され、所定のトップメニューが表示される。図１８はトップメニューの一例であり、ここではメニュー項目として「ゲーム」、「トラベル」、「盛り場情報」が表示されている。
【００６６】
次に、いずれかの項目のボタンを選択すると、ＣＰＵ２２は、選定したジャンルに対応する情報ファイルをハードディスク２４から検索し、そのヘッダに記述されているｓｔｒｉｎｇ行のタイトルをメニュー項目として表示する。
今、「ゲーム」の項目のボタンを選択確定したとすると、図１８に示すゲームメニューＧＭ１が表示される。この場合、ゲームメニューのオブジェクトには、ジャンル分類がゲームとなっている情報ファイルのヘッダのｓｔｒｉｎｇ行の部分を表示させるスクリプトが記述されている。
【００６７】
ここで、ダウンキーＤＷＫ（図３参照）によって、次のページを選択すると、ゲームメニューＧＭ２が表示され、さらに、次のページを選択するとゲームメニューＧＭ３が表示される。すなわち、ゲームについては、ゲームメニューＧＭ１〜ＧＭ３が表示され、合計で２３タイトルが表示される。ここで、各ゲームのタイトルは、そのゲームの情報ファイルのヘッダーのｓｔｒｉｎｇ行に記載されているタイトルである。以上のように、ゲームについては、多くのタイトルが表示される。また、各メニュー画面を規定するオブジェクトにおいては、各メニュー項目のタイトルが固定的でなく、選択された情報ファイルのｓｔｒｉｎｇ行のタイトルを表示するような記述になっており、ＣＰＵ２２がこの記述にしたがった表示制御を行うことにより、図１８に示すメニューが自動生成される。
【００６８】
次に、利用者がトップメニュー内の「トラベル」のボタンを選択確定すると、ハードディスク２４内の情報ファイルのうち、トラベルジャンルの情報ファイルが選択され、さらにユーザーＩＤを考慮されることにより、大人用のジャンルが除外されて若人向けの情報ファイルだけが選択され、その情報ファイルのヘッダ部分に記憶されているｓｔｒｉｎｇ行が表示される。図示の例では、１２タイトルが選択されており、メニュー画面ＴＭ１とＴＭ２に分割されている。
【００６９】
また、利用者がトップメニュー内の「盛り場情報」のボタンを確定すると、これに関する情報ファイルは全て大人用のジャンルに分類されているため、選定される情報ファイルはない。このような場合には、図１８に示すように、サービスが選択されない旨の表示、例えば、「だめ！」という文字表示がなされる。このような制御は、「盛り場情報」のボタンが選択確定された際に起動されるオブジェクトにおいて、ＩＤ情報が未成年の場合には、所定のメッセージ表示を行うように記述することによって行われる。
なお、上記の例では大人用を除くジャンル選定を行ったが、大人用のみの選定や、子供用＋女性用という選定の仕方もある。
【００７０】
一方、ＩＤカードを用いない場合は、カラオケ端末２に配信された情報ファイルを全て用いてメニューを作成するが、この場合においても、配信される情報ファイルが適宜異なるので、上述の場合と同様の自動メニュー生成が行われる。
また、ジャンルを示すデータを個別に設けず、曲番号によってジャンル区分をしてもよい。例えば、１０００番台はゲーム、２０００番台はインフォメーションとうように決めてもよい。
さらに、ＩＤ情報によってトップメニューのボタン（各ジャンルのｓｔｒｉｎｇ行）の並べ方（順位）を変えても良い。すなわち、年代層や性別に応じて、選ばれる頻度の高い項目を上位に配置するよに制御してもよい。このような制御は、トップメニューのオブジェクトのボタン配置を、ＩＤ情報に応じて変動するようなスクリプト記述にすればよい。
【００７１】
また、ジャンルが生成されていない場合は、トップメニューの項目を削除してもよい。例えば、トラベルのジャンルに区分される情報ファイルが未だ配信されていない場合は、トップメニューのトラベルの項目を設けないようにしてもよい。
また、情報ファイルのうち、ロケーション（都道府県）にマッチしたものだけを予め抽出または配信し、その結果に対して上述のメニュー自動生成を行っても良い。このようにすることで、各地方に対応したきめ細かい情報サービスを提供することができる。
【００７２】
（３）情報サービスの一例
次に、情報サービスの一例について説明する。
▲１▼ヒット曲の案内とカラオケ演奏
このサービスは、最新のヒット曲２０位までのランキングをスクロール表示するサービスである。また、そのリストの中に歌いたい曲がある場合には、そのリクエストを受け付けるサービスも行う。
【００７３】
ここで、図１９に示す仮想空間ＴＴＡは、ＲＡＭ２５内に設定されるメモリ空間であり、この空間においては、トップ２０の曲番号（図示略）と曲名とが２０位からカウントダウン形式で１位まで展開されている。この展開は、メモリ空間上にビットマップで展開されている。このリストの生成は、スクリプトによって記述されたトップ２０のリストを示すオブジェクトを、ＣＰＵ２２が処理することによって行われる。
【００７４】
そして、同図に示す破線のエリアは、表示対象エリアＤＰＡであり、この表示対象エリアＤＰＡが図示の矢印Ａの方向にずれていく。そして、表示対象エリアＤＰＡ内のドットデータは、画像合成装置３４内のＶＲＡＭに転送され、これによってディスプレイ３５に表示される。したがって、ディスプレイ３５には、トップ２０のリストがスクロール表示される。
このトップ２０の表示を行うオブジェクトにおいては、スクロールスピード、スクロール開始位置、時間およびスクロール終了位置などが記述され、さらに、スクロール終了時の動作なども記述されいてる。したがって、ＣＰＵ２２は、オブジェクトに記述された事項に基づいて、図１９に示す表示対象エリアＤＰＡ（破線参照）の所期位置および移動速度を決定する。以上の動作により、利用者はトップ２０の曲名をスクロールリストによって知ることができる。
【００７５】
次に、この情報サービス（トップ２０曲のスクロール表示）においてカラオケ演奏を開始させる処理について説明する。
まず、曲の選択は、利用者がスクロール中の曲の曲番号を覚えておいてリモコンＲＭＣによって入力してもよく、また、スクロール中の各曲のボタンを選択してもよい。ボタン選択は、図４に示す画面の場合と同様の処理によって行われる。
一方、図２０に示すように、スクロール終了後において、アップキーＵＰＫやダウンキーＤＷＫを操作して、手動により上下に１行ずつスクロールするような制御を行うこともできる。このような場合には、この手動スクロール操作によって所望の曲を表示させた状態にして、その曲のボタンを選択確定すればよい。
【００７６】
以上のようにして、曲の選択がなされると、これらの曲のキューがＲＡＭ２５内の所定エリアＱＡＴ２０（図２０参照）に順次登録される。図２０に示すエリアＱＡＴ２０には、１９位、５位、２位の順で曲が予約されている。また、次の曲が予約されると、その曲のキューは２位の曲の次のアドレスに登録される。このエリアＱＡＴ２０はリングバッファ構造になっており、最終アドレスにキューが登録された後は先頭アドレスに戻って登録が行われる。また、図に示すポインタＰは、次に演奏される曲を示している。
【００７７】
そして、所定のキーを操作することで演奏が開始され、予約キューの演奏がすべて終了するとトップ２０のリストに戻る。また、演奏開始後において、取り消しキーＣＬＫを操作した場合もトップ２０のリスト表示に戻る。
以上のキュー管理は、トップ２０のリスト表示サービスの処理の一部として行われる。なお、これに代えて、情報サービスが終了した後に、エリアＱＡＴ２０に登録されたキューを、通常のカラオケモードにおいて使用されるキュー登録エリアＱＡに転送してもよい。この場合においては、まず、図２０に示す画面表示の案内にしたがって取り消しキーＣＬＫを押す。この結果、情報サービスが終了してカラオケモードに移行し、この際に、エリアＱＡＴ２０に登録されていたキューがキュー登録エリアＱＡに転送される。
【００７８】
ところで、トップ２０のリスト表示サービスが起動される前に、既にキュー登録エリアＱＡに予約曲のキューが登録されている場合は、エリアＱＡＴ２０から転送されるキューは、この予約曲の次のアドレスに登録される。図２０においては、予約曲が既に４曲登録されている状態において、エリアＱＡＴ２０から１９位、５位、２位の曲のキューが転送された場合を示している。
【００７９】
▲２▼動画表示処理
情報サービスの種類によっては、動画を表示させた方が効果的な場合がある。そこで、この実施形態においては、各種動画を表示するようにしている。ここで、ボールが旋回する動画を表示する場合を例にとって、一般的な動画表示制御について説明する。この場合には、ボールの旋回中の各姿態を示す画像データを複数用意し、それらをＶＲＡＭに順次転送して動画表示を行う。例えば、図２５に示すように、ハードディスク２４から旋回途中の姿態を示す画像データ（この例の場合は４つ）をＲＡＭ２５の所定のエリアに転送し、これらを順次切り換えるようにしてＶＲＡＭに転送する。この結果、ボールがあたかも回転しているように表示される（図では左旋回）。この場合、各画像データをハードディスク２４から直接ＶＲＡＭに書き込むこともできるが、ハードディスクからのデータ転送時間は、半導体メモリよりも遅いため、ＶＲＡＭの書換処理に時間がかかり、書換途中の状態が利用者に見えてしまう。このためスムーズな動画表示とならない。
【００８０】
ところで、図２１に示すように、動画の要素となる画像データを全てＲＡＭ２５に転送した後動画表示すると、動画表示はスムーズにいくものの、ＲＡＭ２５のエリアの多くを画像データが占有してしまい、メモリ使用効率が悪い。そこで、本実施形態においては、次のような処理を行っている。
【００８１】
まず、ハードディスク２４から、第１番目の画像データをＲＡＭ２５の所定領域に転送し、次いで、この画像データをＶＲＡＭに転送する。そして、第１番目の画像データが表示されている間に、第２番目の画像データをＲＡＭ２５の同一エリアに上書きする。次いで、第２番目の画像データを所定のタイミング（例えば、垂直ブランキング期間）においてＶＲＡＭに転送する。以後、第３、第４番目の画像データに対しても同様の処理を行い、第４番目の画像データをＶＲＡＭに転送した後は、再び、第１番目の画像データをＲＡＭ２５に転送する。上述した処理を繰り返すことにより、旋回するボールの表示がなされるが、ＲＡＭ２５の使用エリアは、１個の画像データに対応する領域だけであり、また、ＶＲＡＭへの書き込みは、ＲＡＭ２５から行われるため高速である。したがって、メモリ使用効率も高く、また、動画表示もスムーズに行われる。
【００８２】
本実施形態においては、上述のようにメモリの使用効率が高いため、空きエリアを他の用途に使用することができる。例えば、ＭＩＤＩデータや波形データをハードディスク２４から転送しておき、これらを適宜使用して自動演奏や楽音生成を行うことができる。この場合、ＲＡＭ２５からＭＩＤＩデータや波形データを読み出すと、アクセススピードが早いため、音の発生タイミングを高精度に制御することができる。一方、ハードディスクから、ＭＩＤＩデータや波形データを読み出す場合は、アクセススピードが遅いため、音の発生タイミング制御はややラフになる。この実施形態においては、ＲＡＭ２５からの読み出しと、ハードディスク２４からの読み出しの双方を用途に応じて切り換えて用いている。
【００８３】
例えば、スクリプトの記述において、「ＳＥ＝××……」とすればメモリ２５からの読み出しを意味し（この場合は、メモリ２５に予め音データをロードしておく）、「Ｓｏｕｎｄ＝○○……」とすればハードディスク２４からの直接読み出しを意味する。この場合「ＳＥ」は、同期の必要な音データを発生させるために用いられる。
【００８４】
▲３▼課金処理
次に、サービスに料金が必要な場合の課金処理について説明する。今、図２３に示すような階層メニューおよびサービスがあるうち、破線で囲んだ「サービス１」、「サービス２」および「サービス４」が有料サービスであったとする。有料か否かの区別は、課金が必要な情報サービスのスクリプト（オブジェクト）に課金である旨の記述をすることにより行われる。
【００８５】
次に、ＣＰＵ２２による課金チェック処理について説明する。この場合、ＣＰＵ２２は、例えば、図２４に示すフローチャートにしたがって課金チェック処理を行う。まず、ステップＳＰ１において、当該情報サービスが課金サービスか否かを判定する。これはオブジェクトの記述によって判断され、「ＮＯ」であればリターンし、課金チェック処理は行わない。一方、ステップＳＰ１の判定が「ＹＥＳ」であれば、ステップＳＰ２に進み正当なカード（クレジットカード）が使用されているか否かが判定される。この判定は、図２に示すカード端末７０からの検出信号に基づいて行われる。正当なカードが使用されている場合は、カードによる清算を行うため、図２４に示す課金チェック処理から抜ける。一方、カードが使用されていない場合は、ステップＳＰ３に進み現金が不足しているか否かが判定される。
【００８６】
すなわち、図２に示す金銭入力装置５０に投入された硬貨および紙幣の合計額が、これから行うサービスの課金以上であるか否かが判断される。投入金額が不足していない場合は、直ちにサービスに入り、課金チェック処理から抜ける。一方、投入金額が不足している場合は、ステップＳＰ４にでその旨を表示し、ステップＳＰ５に進む。ここで、図２５はステップＳＰ４における表示例である。すなわち、「○○○円不足です。」という案内表示を行う。利用者は、この表示を見て、投入金額が不足していることを知る。そして、利用者が不足金額を金銭入力装置５０に投入すると、金銭入力装置５０から検出信号が出力され、ＣＰＵ２２がこれを認識してステップＳＰ５の判定を「ＹＥＳ」とし、当該課金サービスに入る（ステップＳＰ６）。一方、利用者が図２５に示す案内表示を見て取り消しキーＣＬＫを押した場合、あるいは、一定時間入金がない場合は、ステップＳＰ５の判定が「ＮＯ」となり、当該課金サービスから抜けて、上位のメニュー表示に戻る（ステップＳＰ７）。なお、上位のメニュー表示に戻る代わりに、カラオケモードに戻っても良い。
【００８７】
ところで、課金サービスとしては、例えば、新譜照会サービスなどがある。このサービスにおいては、例えば、前述した図１６に示すような表示が行われ、曲のタイトル、アーティスト名、曲番号からなるテキスト情報が上下方向にスクロールして順次新譜が紹介される。また、この新譜情報とともに、スタートキーＳＴＫの押圧を案内するアイコンＩＣ５の他、紹介画面のタイトル、絵や写真等の画像情報が画面上の固定位置に表示される。
【００８８】
ここで、操作者がスタートキーＳＴＫを押圧すると、アイコンの左に表示されている新譜についての情報ファイルが実行され、その曲のカラオケの演奏またはＣＤ演奏（ＣＤを再生することによる歌入りの演奏）が開始される。この場合、該当するＣＤは、サービスマンによって予めＣＤチェンジャー６０にセットされている。そして、図２４に示す課金チェック処理は、スタートキーＳＴＫが押されたときに起動され、投入金額不足の場合には新譜の演奏は行われない。
【００８９】
また、新譜のカラオケ演奏が開始されて所定時間が経過した後は、取り消しキーＣＬＫの操作を無効にする。キー操作を無効にする制御情報は、オブジェクトに記述し、例えば、所定の条件が満たされたときに所定のキーの信号を無効にするように記述する。また、キーを無効にする手法としてオブジェクトのＤｅｌａｙの欄に記述してもよく、例えば、サービス画面に入ってから５秒後に所定のキーを無効にする、等の記述を行うこともできる。このような制御を行う他の例としては、有料インフォメーションをある時間継続して見たら、取り消しキーを無効にして強制的にそのサービスに入るようにする場合などがある。
【００９０】
ところで、課金サービスには次のような応用が可能である。例えば、その店舗（カラオケボックスなど）における飲み物、食事等の注文を曲番号の入力として受け付け、かつ、この受付サービスを課金サービスとする場合である。これによれば、利用者は、所望の食事等をリモコンで注文することができるとともに、その代金を金銭入力装置に投入することより、清算を済ませることができる。
【００９１】
また、カラオケボックスなどにおいては、部屋のレンタル時間に応じて課金するシステムの店舗があるが、この場合には、レンタル時間を計時するタイマを儲け、このタイマからの時間信号（割込み信号）をＣＰＵ２２が受け付けるようにする。これにより、ＣＰＵ２２は利用者の使用時間の累計を把握することができる。そして、利用者が投入した金額に対応するレンタル時間が満了した後は、図２４に示す課金チェック処理を起動させ、利用者に金額が不足していることを促す。この場合においては、レンタル料の自動清算が可能になる。
【００９２】
▲４▼ログの記録
図２６は、メニューおよび情報サービスのツリーを示している。図示のように１〜８までのメニューおよび情報サービスがある場合、どのメニューあるいは情報サービスがアクセスされたか（あるいは何回アクセスされたか）を記録しておくと、利用状況が把握できて便利である。
【００９３】
そこで、この実施形態においては、図２６に示すように、フラグレジスタＦＬを設け、アクセスのあったメニューおよび情報サービスに対応するビットに“１”を立てるようにしている。この場合、フラグレジスタＦＬの各ビットは、所定のメニューおよび情報サービスに対応しているので、フラグレジスタＦＬの内容をみれば、利用状況を把握することができる。
【００９４】
どのメニューまたはどの情報サービスがアクセスされたかは、どのオブジェクトが実行されたかが判れば把握できるから、ＣＰＵ２２がオブジェクトを実行した際にフラグレジスタＦＬの所定ビットに書き込みを行う。
一方、各メニューや情報サービスが、それぞれ何回アクセスされたかを記録するば、より的確に利用状況を把握することができ好適である。図２７は、このような制御を行う場合の構成の一例を示している。図においては、ＲＡＭ２５内の所定エリアの各アドレスに、各メニューや情報サービスのアクセス回数を記録するようにしている。すなわち、ＣＰＵ２２がオブジェクトを実行する際にどのメニューまたはどの情報サービスが実行されたかを認識し、対応するアドレスのアクセス回数をインクリメントさせる。
【００９５】
以上のような処理を行えば、ＲＡＭ２５内の所定のエリアを見ることにより、極めて詳細な利用状況を把握することができる。さらに、ホストコンピュータ１からの要請がある度、あるいは、所定時間毎に、ＲＡＭ２５内のアクセス回数情報を読み出し、通信インターフェイス２１を介してホストコンピュータ１に転送するように構成してもよい。この場合においては、ホストコンピュータ１において、どのような情報サービスが人気があるかなどの市場調査等も行うことができ、新たな情報サービスの制作などに活かすことができる。
【００９６】
また、ＣＰＵ２２において、アクセス回数の状態から、メニュー内の項目の順位を切り換える等の制御を行うこともできる（例えば、アクセス回数の多いメニューを上位に表示する）。この場合には、アクセス回数の状態から所定のオブジェクトの記述を一部変更し、項目の表示順序を変更する。
【００９７】
▲５▼ＬＥＤ表示
次に、本体の前面に設けられているＬＥＤ表示装置の制御について説明する。一般にカラオケ装置においては、ＬＥＤ表示装置が設けられることが多いが、通常は、予約する曲番号を表示するだけである。
この実施形態においては、単に予約曲の曲番表示だけでなく、さらに、多様な表示を可能にしている。すなわち、ＬＥＤ表示装置５５の制御情報を、各オブジェクトにおいて記述することにより、メニューや情報サービスの特徴に応じた制御を行うようにしている。
【００９８】
例えば、オブジェクトにおいて”ＬＥＤ＝……”という記述がある場合は、ＣＰＵ２２がこの記述内容に応じてＬＥＤ表示装置５５を制御する。例えば、図２８（ａ）は各桁の７セグメントＬＥＤの上部と下部を交互に点灯させ、同図（ｂ）は同図（ａ）の上部点灯と下部点灯を入れ換えている。そして、同図（ａ）と（ｂ）の点灯状態を交互に行うようにすれば、光が動いているようなイルミネーション効果を発揮させることができる。
このように、各オブジェクトによって個別にＬＥＤ表示装置５５の制御情報を記述することにより、メニューや情報サービス毎に変化に富んだＬＥＤ表示を行うことができる。この場合、オブジェクトにおいて、ディスプレイ３５のみの制御だけではなく、ＬＥＤ表示装置の制御までも記述できるような体系としているので、ＬＥＤ制御用の特別なプログラムを別途作成する必要はない。
【００９９】
Ｃ：その他
▲１▼上述した実施形態は、通信カラオケシステムにこの発明を適用した実施形態であったが、本発明は一般的なコンピュータシステムにも勿論適用することができる。例えば、自動メニュー生成処理は、一般的なコンピュータシステムにおいて実行すべきオブジェクトファイルが多数ある場合などは、ジャンル別のリストが自動生成されるので便利である。
【０１００】
【発明の効果】
以上説明したように、この発明によれば、利用者個人の状況に応じて、自動的にメニューを生成することができる。
【図面の簡単な説明】
【図１】 この発明の一実施形態による通信カラオケシステムの全体構成を示すブロック図である。
【図２】 同実施形態におけるカラオケ端末２の構成を示すブロック図である。
【図３】 同実施形態におけるリモコンＲＭＣの操作部を示す正面図である。
【図４】 実施形態において表示される情報サービスメニュー画面の一例である。
【図５】 同実施形態において用いるオブジェクトの内容を示す概念図である。
【図６】 同実施形態における曲オブジェクトの記述例を示す概念図である。
【図７】 同実施形態における「絵（＃１）ｏｂｊ」の記述例を示す概念図である。
【図８】 同実施形態における「テキスト（＃ｎ）ｏｂｊ」の記述例を示す概念図である。
【図９】 同実施形態において表示される情報サービス画面の一例を示す図である。
【図１０】 ハードディスク２４内のスクリプト（オブジェクト）とリソースの記憶状態を示す概念図である。
【図１１】 本実施形態におけるメニューオブジェクトのデータ構造を示す概念図である。
【図１２】 本実施形態における階層メニューの一例を示す説明図である。
【図１３】 本実施形態におけるキュー登録エリアＱＡを示す概念図である。
【図１４】 割込み用のエリアＩＡおよび割込み用リングバッファＩＲＢを示す概念図である。
【図１５】 自動車宣伝用のサービス画面の一例を示す図である。
【図１６】 新譜照会用のサービス画面の一例を示す図である。
【図１７】 宣伝制作会社によって制作された宣伝用の情報ファイルの配信形態を示す概略図である。
【図１８】 トップメニューの一例を示す図である。
【図１９】 ＲＡＭ２５内に設定される仮想空間ＴＴＡを示す概念図である。
【図２０】 スクロール表示終了後の表示画面の一例を示す図である。
【図２１】 一般的な動画表示制御を説明するための説明図である。
【図２２】 本実施形態における動画表示制御を説明するための説明図である
【図２３】 本実施形態における階層メニューの一例を示す図である。
【図２４】 課金チェック処理を示すフローチャートである。
【図２５】 図２４に示すステップＳＰ４における表示例を示す図である。
【図２６】 メニューおよび情報サービスのツリー構造を示す図である。
【図２７】 各情報サービスのアクセス回数記録を行う場合の構成例を示すブロック図である。
【図２８】 ＬＥＤ表示装置５５の表示制御例を示す説明図である。
【符号の説明】
１……ホストコンピュータ、２……カラオケ端末、２１……通信インタフェース、２２……ＣＰＵ、２３……ＲＯＭ、２４……ハードディスク、２５……ＲＯＭ、２６……操作パネル、２７……楽音合成装置、２８……ミキサ、２９……マイク、３０……サウンドシステム、３１……音声デコーダ、３２……画像再生装置、３３……ＣＤ−ＲＯＭ、３４……画像合成装置、３５……ディスプレイ、３６……画像デコーダ、ＢＵＳ……バス、Ｎ……通信回線、ＳＰ……スピーカ。
Claims (5)
- プログラムおよびジャンル情報を含むオブジェクトファイルを複数記憶する記憶手段を有し、前記記憶手段からオブジェクトファイルを選択するとともに、選択したオブジェクトファイル内のプログラムを実行するコンピュータシステムであって、
利用者の個人情報を含むＩＤ情報を読み取るＩＤ情報読取手段と、
前記ＩＤ情報読取手段が読み取った個人情報に対応した個人別ジャンルを判定するジャンル判定手段と、
利用者の操作に応じて指定ジャンルを決定するジャンル決定手段と、
前記ジャンル決定手段が決定した指定ジャンルおよび前記ジャンル判定手段が判定した個人別ジャンルの双方に合致するオブジェクトファイルを検索する検索手段と、
前記検索手段によって検索されたオブジェクトファイルに対応したタイトルによって構成されるリストを生成するリスト生成手段と、
前記リスト生成手段が生成したリストを表示する表示手段と
を具備することを特徴とするコンピュータシステム。 - 前記各オブジェクトファイルは、その内容に対応したタイトルを表示するためのタイトル情報を有し、
前記リスト生成手段は前記検索手段によって検索されたオブジェクトファイル内のタイトル情報に基づいて前記リストを生成することを特徴とする請求項１記載のコンピュータシステム。 - 請求項１または２に記載のコンピュータシステムを有するとともに、前記記憶手段にカラオケの演奏情報を格納し、さらに、
前記記憶手段からカラオケの演奏を読み出して楽音を合成し、この合成音とマイクから入力される音声とを混合して出力するカラオケ演奏手段と、
前記オブジェクトファイルの実行と前記カラオケ演奏手段によるカラオケ演奏のいずれかを切り換える切換手段と
を有することを特徴とするカラオケ装置。 - 前記オブジェクトファイルのプログラム中に前記カラオケ演奏手段によるカラオケ演奏が選択可能な命令として記述されていることを特徴とする請求項３記載のカラオケ装置。
- 前記ＩＤ情報は、ＩＤカードに記憶され、前記ＩＤ情報読取手段は、ＩＤカード読取装置によって構成されていることを特徴とする請求項３または４記載のカラオケ装置。
Priority Applications (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP30177395A JP3646377B2 (ja) | 1995-11-20 | 1995-11-20 | コンピュータシステムおよびカラオケ装置 |
| US08/753,066 US6231347B1 (en) | 1995-11-20 | 1996-11-19 | Computer system and karaoke system |
| CNB961234962A CN1184640C (zh) | 1995-11-20 | 1996-11-20 | 计算机系统和卡拉ok系统 |
| CNB2004100055180A CN1266580C (zh) | 1995-11-20 | 1996-11-20 | 从菜单中作出一个选择的方法和装置 |
| EP96118653A EP0775995B1 (en) | 1995-11-20 | 1996-11-20 | Computer system and karaoke system |
| DE69627453T DE69627453T2 (de) | 1995-11-20 | 1996-11-20 | Rechnersystem für Karaoke |
| CNA2004100055176A CN1538280A (zh) | 1995-11-20 | 1996-11-20 | 计算机系统和卡拉ok系统 |
| US09/645,290 US6572381B1 (en) | 1995-11-20 | 2000-08-24 | Computer system and karaoke system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP30177395A JP3646377B2 (ja) | 1995-11-20 | 1995-11-20 | コンピュータシステムおよびカラオケ装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH09146967A JPH09146967A (ja) | 1997-06-06 |
| JP3646377B2 true JP3646377B2 (ja) | 2005-05-11 |
Family
ID=17901004
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP30177395A Expired - Lifetime JP3646377B2 (ja) | 1995-11-20 | 1995-11-20 | コンピュータシステムおよびカラオケ装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3646377B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3633224B2 (ja) * | 1997-08-11 | 2005-03-30 | 三菱電機株式会社 | 情報検索システム |
| JP2000029595A (ja) * | 1998-07-15 | 2000-01-28 | Fujitsu Ltd | メニューインタフェースを有する電子処理装置 |
| JP4497309B2 (ja) * | 2004-06-24 | 2010-07-07 | 日本電気株式会社 | 情報提供装置、情報提供方法および情報提供用プログラム |
| JP2006268159A (ja) * | 2005-03-22 | 2006-10-05 | Nec Corp | 情報処理端末、データ表示方法、及びデータ表示プログラム |
| JP4399440B2 (ja) | 2006-06-30 | 2010-01-13 | 株式会社コナミデジタルエンタテインメント | 音楽ジャンル判別装置及びこれを備えたゲーム機 |
| JP5350308B2 (ja) * | 2010-03-31 | 2013-11-27 | ブラザー工業株式会社 | 楽曲再生システム及び楽曲再生方法 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2942803B2 (ja) * | 1986-10-08 | 1999-08-30 | 豊 塚本 | ユーザ情報提供システム |
| JPH0411288A (ja) * | 1990-04-27 | 1992-01-16 | Brother Ind Ltd | 楽曲検索機能付きカラオケ装置 |
| JPH06230793A (ja) * | 1993-01-28 | 1994-08-19 | Victor Co Of Japan Ltd | カラオケ装置 |
| US5583763A (en) * | 1993-09-09 | 1996-12-10 | Mni Interactive | Method and apparatus for recommending selections based on preferences in a multi-user system |
| JPH07104773A (ja) * | 1993-10-05 | 1995-04-21 | Matsushita Electric Ind Co Ltd | カラオケ設備の選曲装置 |
| JPH07182374A (ja) * | 1993-11-09 | 1995-07-21 | Sharp Corp | 情報出力装置 |
| JPH07191683A (ja) * | 1993-12-27 | 1995-07-28 | Citizen Watch Co Ltd | カラオケシステム |
-
1995
- 1995-11-20 JP JP30177395A patent/JP3646377B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH09146967A (ja) | 1997-06-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0775995B1 (en) | Computer system and karaoke system | |
| US5947746A (en) | Karaoke network system with commercial message selection system | |
| JP3997553B2 (ja) | コンピュータシステムおよびカラオケシステム | |
| JP2011100471A (ja) | インテリジェントデジタルオーディオビジュアル再生システム | |
| JP2002055679A (ja) | コンテンツ生成サービスシステム、方法及び記録媒体 | |
| JP2004301886A (ja) | 通信カラオケ端末装置の選曲予約システム | |
| JP3646377B2 (ja) | コンピュータシステムおよびカラオケ装置 | |
| JP3676457B2 (ja) | コンピュータシステムおよびカラオケ装置 | |
| JP3679476B2 (ja) | コンピュータシステムおよびカラオケ装置 | |
| JPH11219188A (ja) | 通信カラオケシステム、カラオケ演奏端末、および選曲装置 | |
| JP3463842B2 (ja) | カラオケ装置 | |
| JP4211392B2 (ja) | カラオケ選曲装置ならびにカラオケ装置 | |
| JPH09146754A (ja) | コンピュータシステムおよびカラオケ装置 | |
| JP2001521234A (ja) | マルチメディア関連情報のグローバル・アクセス・システム | |
| JPH09146570A (ja) | カラオケ装置 | |
| JP4223277B2 (ja) | キーワード検索により所定曲数以下に絞り込まれた複数楽曲の一部を連続再生させながら希望曲を選出可能な選曲装置、選曲用プログラム | |
| JP2004212588A (ja) | 音楽再生装置 | |
| JP4060996B2 (ja) | 通信カラオケシステム | |
| JP4123814B2 (ja) | コンテンツデータ配信システム及びコンテンツデータ配信再生方法 | |
| JPH09212181A (ja) | カラオケ装置 | |
| JP3602090B2 (ja) | 選曲と映像選択のユーザインタフェースに特徴を有するカラオケ装置 | |
| JP4257777B2 (ja) | マルチメディア関連情報のグローバル・アクセス・システム | |
| JP4257776B2 (ja) | マルチメディア関連情報のグローバル・アクセス・システム | |
| JP4429244B2 (ja) | カラオケ装置 | |
| JPH09319382A (ja) | カラオケ装置及びカラオケ用選曲装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040629 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040818 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050118 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050131 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313532 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080218 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090218 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090218 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100218 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110218 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120218 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130218 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140218 Year of fee payment: 9 |
|
| EXPY | Cancellation because of completion of term |