JP2011059191A - カラオケ装置 - Google Patents

Abstract

【課題】カラオケ装置が有する記憶装置を効率的に利用しつつ、ネットワーク負荷を低減することができるカラオケ装置を提供すること。
【解決手段】カラオケ装置は、サーバからカラオケ演奏に用いるカラオケデータを受信し、記憶部に記憶する。そして、カラオケデータが最後に用いられた時刻と現時刻とを比較し、その時間差が参照時間よりも長く、かつ、カラオケデータを用いるカラオケ楽曲が予約テーブルに記憶されていない場合に、そのカラオケデータを記憶部から削除する。
【選択図】図６

Description

本発明は、カラオケ演奏に用いられるカラオケデータをサーバから受信し、当該カラオケデータを用いてカラオケ演奏を行うカラオケ装置（いわゆる通信カラオケ装置）に関する。

通信カラオケ装置では、自装置に記憶できる容量に制限があるという問題を解決すべく、所定の条件を満たしたカラオケデータを削除することが一般的に行われている（例えば、特許文献１）。

特開平６−２５０６８２号公報

この問題は、記憶容量が増加することにより解決できるものと考えられていた。しかしながら、配信曲数が爆発的に増加したこと、ブロードバンド化により背景画等に用いられる動画の配信が可能となったこと等の理由により、記憶容量が大幅に増加した現在においてもこの問題は解決していない。また、最近では、ユーザの歌唱音声や歌唱動画をサーバにアップロード（投稿）し、他のカラオケ装置でこれらの情報を再生可能とした投稿システムが提案されている。このような投稿システムにおいては、カラオケ楽曲ごとに多くの歌唱音声や歌唱動画がサーバ上に記憶されることになり、このような情報を全てカラオケ装置に記憶しておくことは実用上不可能である。また、ネットワーク負荷を低減させるためには、記憶されているカラオケデータのうち、再使用される可能性が低いカラオケデータを選択的に削除する必要がある。

上記目的を達成するために、請求項１に係る発明は、サーバからカラオケ演奏に用いられるカラオケデータを受信し、当該カラオケデータを用いてカラオケ演奏を行うカラオケ装置において、前記受信したカラオケデータと、当該カラオケデータが最後に用いられた時刻を示す最終参照時刻とを記憶するデータ記憶手段と、前記カラオケデータが用いられるごとに、当該カラオケデータの最終参照時刻を更新する時刻更新手段と、演奏するカラオケ楽曲の予約を受け付ける予約受付手段と、予約を受け付けたカラオケ楽曲の識別情報を記憶する予約記憶手段と、前記予約を受け付けたカラオケ楽曲のカラオケ演奏時に、当該カラオケ楽曲の識別情報を前記予約記憶手段から削除する予約管理手段と、前記カラオケデータの最終参照時刻と現時刻とを比較し、その時間差が参照時間よりも長く、かつ、当該カラオケデータの識別情報が前記予約記憶手段に記憶されていない場合に、当該カラオケデータ及び識別情報を前記データ記憶手段から削除するデータ削除手段と、を有するものである。

請求項１に係る発明では、設定時間以上カラオケ演奏に用いられておらず、かつ、演奏予約もなされていないカラオケデータは、カラオケ装置から削除される。これにより、再使用の可能性が低いカラオケデータを選択的に削除することができるので、カラオケ装置の記憶容量を有効に活用しつつ、ネットワーク負荷を低減することができる。なお、請求項１における「よりも長い」には「以上」の概念を含む。また、請求項１における「カラオケ演奏時」には、「カラオケ演奏開始時」、「カラオケ演奏中」、「カラオケ演奏終了後」の概念を含む。

また、請求項２に係る発明は、請求項１のカラオケ装置において、自装置へのログイン状態を判別するログイン状態判断手段と、前記参照時間を調整する参照時間調整手段と、をさらに有し、前記参照時間調整手段は、前記ログイン状態判断手段が少なくとも１人のユーザがログインしていると判断した場合には、前記参照時間を第１の設定時間とし、前記ログイン状態判断手段がいずれのユーザもログインしていないと判断した場合には、前記参照時間を前記第１の設定時間よりも短い第２の設定時間とするものである。

請求項２に係る発明では、カラオケ装置にログインしているユーザがいる場合の上記設定時間と、カラオケ装置にログインしているユーザがいない場合の上記設定時間とが異なる。より詳しくは、カラオケ装置にログインしているユーザがいる場合の上記設定時間の方が長い。ユーザ（または、グループ）は、ログインしている間、同じカラオケ楽曲を複数回歌唱する傾向がある。そのため、上記設定時間を長くすることにより、一度歌唱されたカラオケ楽曲のカラオケデータをデータ記憶手段に長期間記憶しておくことにより、当該カラオケデータをサーバからダウンロードする回数を削減することで、ネットワーク負荷を低減することができる。一方、カラオケ装置にログインしているユーザがいない場合には、ログインしているユーザがいる場合に比べて上記設定時間が短い。カラオケ装置にログインしているユーザがいない場合についても、他のカラオケ装置（コマンダ）が、このカラオケ装置のデータ記憶手段の記憶領域を用いることがある。例えば、カラオケデータの転送にＰ２Ｐ技術などを採用している場合、このカラオケ装置のデータ記憶装置が他のカラオケ装置（コマンダ）へのデータ転送中継のための一時記憶手段として用いられることがある。そのため、ログインしているユーザいない（すなわち、このカラオケ装置が使用されていない）場合であっても、できるだけデータ記憶手段の空き容量を大きくしておいた方が好ましい。したがって、請求項２に係る発明のように構成することで、カラオケ装置のデータ記憶手段を有効に活用することができる。

また、請求項３に係る発明は、請求項１または請求項２のカラオケ装置において、ダウンロード制御手段、をさらに有し、前記ダウンロード制御手段は、前記予約受付手段がカラオケ楽曲の予約を受け付けたときに、当該カラオケ楽曲のカラオケデータが前記データ記憶手段に記憶されておらず、かつ、ダウンロード中でもない場合に、当該カラオケデータを前記サーバに要求するものである。

請求項３に係る発明では、カラオケ楽曲の予約を受け付けたとき、当該カラオケ楽曲のカラオケデータが既にデータ記憶手段に記憶されている場合、または、ダウンロード中である場合には、当該カラオケデータのダウンロードを行わず、予約を受け付けたカラオケ楽曲のカラオケ演奏時には、既にデータ記憶手段に記憶されているカラオケデータ、または、ダウンロード中であるカラオケデータを用いる。これにより、同じカラオケデータが重複してデータ記憶手段に記憶されたり、ダウンロードされたりすることがないため、カラオケ装置の記憶容量を有効に活用しつつ、ネットワーク負荷を低減することができる。

本発明によれば、カラオケ装置が有するカラオケ装置を効率的に利用しつつ、ネットワーク負荷を低減することができるカラオケ装置を提供することができる。

カラオケシステムの全体構成図である。 予約受付処理のフローチャートである。 予約テーブルのデータ構造を示した図である。 演奏処理のフローチャートである。 時刻テーブルのデータ構造を示した図である。 記憶部管理処理のフローチャートである。

［カラオケシステムの概要］
本発明の実施形態に係るカラオケシステムについて図１を参照しつつ説明する。図１に示すように、本実施形態に係るカラオケシステムＳは、各店舗に設置されたカラオケ装置１０と、サーバ１１とから構成されている。サーバ１１には、カラオケ演奏に用いられる種々のカラオケデータが記憶されている。このカラオケデータには、サーバ１１の運営者（すなわち、カラオケシステムの事業者）が提供する通常の楽曲データ（音声、背景画、歌詞等を含む。以下、「既成カラオケデータ」という）と、歌唱者自身の歌唱音声や歌唱動画からなる投稿データ（後述）が含まれる。また、各ユーザの個人情報（ユーザＩＤ、ログイン名、パスワード等）についても、サーバ１１に記憶されている。ここで、サーバ１１は、Ｐ２Ｐ技術を利用したコンテンツ配信システム（例えば、Einy（登録商標））として実現してもよい。サーバ１１は、カラオケ装置１０からの要求に応じて、カラオケデータを送信し、また、個人情報を更新する。

また、各カラオケ装置１０は、後述の構成を有することにより、カラオケ演奏時に、歌唱者の歌唱音声及び歌唱動画を取得し、投稿データとしてサーバ１１にアップロード（投稿）することができる。また、カラオケ装置１０は、サーバ１１に記憶されている投稿データをダウンロード（取得）することができる。取得されたデータは、カラオケ演奏時に、バックコーラスや背景画として用いられる。

例えば、図１に示すように、カラオケ装置１０Ａは、取得した歌唱音声及び歌唱動画を、投稿データＸとしてサーバ１１にアップロードする（１）。
サーバ１１は、受信した投稿データを、新たなカラオケデータとしてデータベース（不図示）に記憶する（２）。
カラオケ装置１０Ｂは、ユーザからのダウンロード指示（演奏予約）に基いて、投稿データＸのダウンロードを、サーバ１１にリクエストする（３）。
サーバ１１は、そのリクエストに応じて、投稿データＸをカラオケ装置１０Ｂに送信する（４）。
これにより、カラオケ装置１０Ｂでは、カラオケ装置１０Ａで取得した投稿データを用いて、カラオケ演奏を行うことができる。

ただし、カラオケ装置１０Ｂは、ダウンロード指示を受け付けた投稿データが既にカラオケ装置１０Ｂ内部に記憶されている場合は、カラオケ演奏時にはその投稿データを用いるため、サーバ１１へのリクエストを行わない。これにより、ネットワークの負荷を低減させることができる。また、カラオケ装置１０Ｂが有する記憶装置は、容量に制限があるためダウンロードした全てのカラオケデータを記憶し続けることはできず、一部のカラオケデータを削除する必要がある。
本実施形態では、後述するように、各カラオケ装置１０は、自装置に記憶しているカラオケデータのうち、再使用される可能性が低いカラオケデータを選択的に削除するように構成している。これにより、カラオケ装置が有する記憶装置を効率的に利用することができる。

［カラオケ装置１０の構成］
次に、カラオケ装置１０の具体的な構成について説明する。なお、以下の説明は、カラオケ装置１０の構成を、図１に示すカラオケ装置１０Ｂに基いて行うが、カラオケ装置１０Ａについても基本的に同じ構成を有している。図１に示すように、カラオケ装置１０は、コマンダ１と、外部との通信に用いられるルータ２と、背景画等を表示するモニタ３と、カラオケ演奏中のカラオケ楽曲及び歌唱音声等を音声出力するスピーカ４と、歌唱中の歌唱者を撮影するビデオカメラ５と、歌唱者の歌唱音声を入力するマイク６と、コマンダ１の操作に用いられるリモコン７と、から基本的に構成される。なお、コマンダ１を除くその他の要素は公知のものを採用することができ、また、本発明の理解には関係のない部分であるので詳細な説明を省略する。

コマンダ１は、現時刻を取得するために用いられるタイマ８と記憶部９を備えている。記憶部９は、例えば、１ＴＢ程度のＨＤＤ（Hard Disk Drive）やフラッシュＲＯＭ等を組み合わせて構成することができる。記憶部９には、演奏予約を受け付けたカラオケ楽曲を管理するための予約テーブル（後述）が記憶されている。さらに、記憶部９には、各カラオケデータが最後に用いられた時刻を管理するための時刻テーブル（後述）が記憶されている。また、記憶部９には、サーバ１１からダウンロードしたカラオケデータが記憶されている。
また、コマンダ１は、公知のログイン機能を有している。そして、コマンダ１は、自装置ログインしているユーザの数（ログイン人数）を取得することができ、ログイン人数は後述の処理において用いられる。すなわち、コマンダ１は、自装置へのログイン状態を判別することができる。

［カラオケ装置１０の動作］
次に、上述のように構成されたカラオケ装置１０の動作について説明する。カラオケ装置１０は、起動中、大きく分けて以下の３つの処理を並列して実行する。
（１）ユーザから演奏予約を受け付け、受け付けた演奏予約に係るカラオケデータを準備するための「予約受付処理」
（２）カラオケ演奏を行うための「カラオケ演奏処理」
（３）記憶部９の記憶内容を制御するための「記憶部管理処理」
これらの処理は、コマンダ１が有する制御部（不図示）によって実行される。なお、制御部の具体的な構成は公知であるので、説明を省略する。
以下、それぞれの処理について具体的に説明する。

［予約受付処理］
まず、予約受付処理について、図２のフローチャートを参照して具体的に説明する。予約受付処理は、リモコン７から予約信号を受信することにより、処理が開始される。したがって、複数の演奏予約が行われた場合は、複数の予約信号を受信することになり、それぞれの予約信号ごとに、予約受付処理のプロセスが実行されることになる。また、予約信号には、例えば、カラオケ楽曲の曲番号、ユーザＩＤ、カラオケ演奏に用いる投稿データの識別番号等が含まれる。なお、リモコン７における投稿データの選択方法の詳細については説明を省略する。また、予約受付処理では、記憶部９に記憶されている予約テーブルを用いて処理を行う。予約テーブルについて、図３を参照して説明する。

図３に示すように、予約テーブルには、「予約順序」、「曲番号」、「ユーザＩＤ」、「ファイル（１）」、「ダウンロードステータス（１）」、「ファイル（２）」、「ダウンロードステータス（２）」等の項目を有している。
「予約順序」はカラオケの演奏順序を示しており、「曲番号」は演奏するカラオケ楽曲の選曲番号を示しており、「ユーザＩＤ」は演奏予約を行ったユーザの識別情報を示している。なお、図３（Ａ）の予約順序「３」の欄に示されるように、ログインしていないユーザからのリクエストについては「ユーザＩＤ」の項目には情報が入力されていない。

「ファイル（１）」はカラオケ演奏に必要なカラオケデータのファイル名を示している。カラオケ演奏に必要なカラオケデータの数が２つである場合には、「ファイル（１）」と「ファイル（２）」の項目に、それぞれ情報が入力される。なお、図３（Ａ）の予約順序「２」に示されるように、１つのカラオケデータのみを用いてカラオケ演奏を行うように指示されている場合（例えば、１つの既成カラオケデータに、音声、動画、歌詞等の全てのデータがまとめられている場合）には、「ファイル（２）」の項目には情報が入力されていない。また、カラオケ演奏に３つ以上のカラオケデータが必要となる場合には、予約テーブルには、ファイル（３）等が新たに作成される。なお、以下の説明において、「ファイル（１）」，…，「ファイル（ｎ)」を総称して、単に「ファイル」ということがある。また、以下の説明において、「ダウンロードステータス（１）」，…，「ダウンロードステータス（ｎ）」を総称して、単に「ダウンロードステータス」ということがある。

「ダウンロードステータス（１）」は、「ファイル（１）」のファイルのダウンロード状態を示している。「済」は、ダウンロードが完了している、すなわち、記憶部９に既にデータが記憶されている状態を示し、「途中」は、ダウンロードの途中であることを示している。なお、「ダウンロードステータス（２）」は、「ファイル（２）」のファイルのダウンロード状態を示している。

予約受付処理の詳細について、以下説明する。
図２のＳ１１において、コマンダ１は、予約テーブルを更新する。具体的には、予約テーブルに新たな行を作成し、「曲番号」、「ユーザＩＤ」、「ファイル」の項目を入力する。
図３（Ｂ）は、予約順序「５」として新たな演奏予約を受け付けたときの予約テーブルの内容を示している。同図に示されるように、「曲番号」として「９５６」が入力され、「ユーザＩＤ」として「１１１」が入力され、「ファイル（１）」として「ｈｈｈｈ」が入力され、「ファイル（２）」として「ｃｃｃｃ」が入力されている。ただし、この時点では、「ダウンロードステータス」の項目には情報が入力されていない。

説明を図２に戻す。
コマンダ１は、以下のＳ１２〜Ｓ１５の各処理を、予約テーブルに新たに追加したファイル名ごとに行う。
Ｓ１２において、コマンダ１は、新たに追加したファイル名が、予約テーブルに既に存在するか否かを判断する。予約テーブルに存在すると判断した場合は（Ｓ１２：ＹＥＳ）、コマンダ１は、処理をＳ１３に移行させる。
Ｓ１３において、コマンダ１は、予約テーブルを更新する。具体的には、コマンダ１は、予約テーブルに既に記憶されている同じファイル名に対応付けられている「ダウンロードステータス」の内容を抽出し、当該抽出した内容を新たに追加したファイル名に対応する「ダウンロードステータス」の項目に書き込む。すなわち、既に記憶されている同じファイル名の「ダウンロードステータス」の内容をコピーする。また、Ｓ１３では、新たに追加したファイル名に対応するカラオケデータのダウンロード要求を行わないため、ネットワーク負荷を低減させることができる。

一方、Ｓ１２において、予約テーブルに同じファイル名が存在しないと判断した場合は（Ｓ１２：ＮＯ）、コマンダ１は、処理をＳ１４に移行させ、このファイル名のカラオケデータのダウンロードを要求するために、サーバ１１にダウンロード要求信号を送信する。ダウンロード要求信号には、ダウンロードを要求するカラオケデータのファイル名（または識別番号）及びコマンダ１の識別番号が含まれる。

その後、Ｓ１５において、コマンダ１は、予約テーブルを更新する。具体的には、コマンダ１は、新たに追加したファイル名に対応する「ダウンロードステータス」を「途中」とする。

図３（Ｃ）は、予約順序「５」として新たな演奏予約を受け付け、図２における「Ａ」の時点での予約テーブルの内容を示している。同図に示されるように、ファイル（１）に記憶されているファイル名「ｈｈｈｈ」は、予約順序「１」〜「４」のいずれの欄にも存在せず、新たにダウンロードを行っている段階であるので、「ダウンロードステータス（１）」には「途中」が書き込まれている。一方、ファイル（２）に記憶されているファイル名「ｃｃｃｃ」は、予約順序「２」の「ファイル（１）」のファイル名と同じであるので、予約順序「２」の「ダウンロードステータス（１）」の内容である「済」が書き込まれている。なお、予約順序「５」に係る予約受付処理では、ファイル名「ｃｃｃｃ」のカラオケデータのダウンロードは行われない。

説明を図２に戻す。
予約受付処理では、予約テーブルに新たに追加したファイル名ごとに、上述したＳ１２〜Ｓ１５の処理を行ったあと、サーバ１１からダウンロードの完了を示す完了信号を受信するまで、図２における「Ａ」の時点で待機する。完了信号には、ダウンロードが完了したファイル名が含まれている。

そして、Ｓ１４で送信したダウンロード要求信号に対応する完了信号を受信すると、以下のＳ１６の処理が実行される。なお、複数のファイル名に対してダウンロード要求信号を送信した場合は、Ｓ１６の処理が、ダウンロード要求信号の数だけ繰り返し実行される。

コマンダ１は、Ｓ１６において、予約テーブルを更新する。具体的には、受信した完了信号からダウンロードが完了したファイル名を抽出し、抽出したファイル名に対応する「ダウンロードステータス」を「済」に変更する。

図３（Ｄ）は、予約順序「５」として新たな演奏予約を受け付け、ファイル名「ｈｈｈｈ」に対応する完了信号を受信した後の予約テーブルの内容を示している。同図に示されるように、演奏順序「５」のファイル名「ｈｈｈｈ」は、「済」に変更されている。なお、同図では、予約順序「３」及び「４」のカラオケ演奏に係るカラオケデータはダウンロード中であることを示している。

以上説明した予約受付処理により、ダウンロード動作を制御することで、同じカラオケデータを重複してサーバ１１からダウンロードしないので、ネットワーク負荷を低減させることができる。

［カラオケ演奏処理］
次に、カラオケ演奏処理について、図４のフローチャートを参照して具体的に説明する。カラオケ演奏処理は、予約テーブルの演奏順序「１」のカラオケ楽曲をカラオケ演奏するために実行される。また、カラオケ演奏処理では、記憶部９に記憶されている時刻テーブルを用いて処理を行う。時刻テーブルについて、図５を参照して説明する。

図５に示すように、時刻テーブルには、「ファイル」及び「最終参照時刻」の項目を有している。「ファイル」は、記憶部９に記憶されているカラオケデータのファイル名を示しており、「最終参照時刻」は、当該カラオケデータが最後に用いられた時刻を示している。

カラオケ演奏処理の詳細について、以下説明する。
図４のＳ２１において、コマンダ１は、演奏順序「１」のカラオケ楽曲のカラオケ演奏に用いられる全てのカラオケデータがダウンロード済みか否かを判断する。この判断は、予約テーブルの「ダウンロードステータス」を参照することにより行われる。カラオケ演奏に用いられるカラオケデータにダウンロード済ではないものが存在すると判断した場合は（Ｓ２１：ＮＯ）、コマンダ１は、Ｓ２１で処理を待機する。一方、カラオケ演奏に用いられる全てのカラオケデータがダウンロード済みであると判断した場合は（Ｓ２１：ＹＥＳ）、コマンダ１は、処理をＳ２２に移行させる。

Ｓ２２において、コマンダ１は、記憶部９に記憶されているカラオケデータを用いてカラオケ演奏を行う。カラオケ演奏自体は、公知であるので詳細な説明を省略する。
カラオケ演奏が終了すると、コマンダ１は、Ｓ２３において、時刻テーブルの最終参照時刻を更新する。具体的には、コマンダ１は、タイマ８を参照して現時刻を取得し、カラオケ演奏に用いたカラオケデータのファイル名に対応付けられている「最終参照時刻」の項目に、取得した現時刻を書き込む。なお、このＳ２３の処理は、カラオケ演奏の開始直後に行ってもよく、また、カラオケ演奏中に行ってもよい。

Ｓ２４において、コマンダ１は、予約テーブルを更新する。具体的には、コマンダ１は、演奏順序「１」の行を削除し、また、それぞれの演奏順序を１つずつ繰り上げる。例えば、演奏順序「２」の行は、演奏順序「１」の行として更新される。

以上説明したカラオケ演奏処理により、カラオケ演奏が行われるごとに、当該カラオケ演奏に用いられたカラオケデータの最終参照時刻が更新される。なお、この最終参照時刻は、記憶部管理処理で用いられる。

［記憶部管理処理］
次に、記憶部管理処理について、図６のフローチャートを参照して説明する。
まず、Ｓ３１において、コマンダ１は、タイマ８を参照して現時刻を取得する。
Ｓ３２において、コマンダ１は、現時刻が指定した時刻であるか否かを判断する。指定した時刻でないと判断した場合は（Ｓ３２：ＮＯ）、コマンダ１は、処理をＳ３１に移行させ、指定した時刻であると判断した場合は（Ｓ３２：ＹＥＳ）、コマンダ１は、処理をＳ３３に移行させる。すなわち、現時刻が所定時刻となるまで、Ｓ３１及びＳ３２の処理が繰り返される。ここで、指定した時刻として、毎時００分とすることができる。すなわち、１時間ごとに、以下の示すＳ３３〜Ｓ４３の処理が実行される。

Ｓ３３において、コマンダ１は、時刻テーブルを参照して、ファイル名を１つ抽出する。
Ｓ３４において、コマンダ１は、時刻テーブルを参照して、Ｓ３３で取得したファイル名の最終参照時刻を取得する。
Ｓ３５において、コマンダ１は、自装置にログインしているユーザの人数（ログイン人数）を取得する。
Ｓ３６において、ログイン人数が０人（すなわち、コマンダ１にログインしているユーザがいない）と判断した場合は、コマンダ１は、Ｓ３７において、参照時間を「第２の設定時間」とする。ここで、第２の設定時間を、例えば、「１時間」とすることができる。
Ｓ３８において、コマンダ１は、現時刻と最終参照時刻に基いて算出した「最終参照時刻からの経過時間」が参照時間（第２の設定時間）よりも長いか否かを判断する。なお、このＳ３８において、当該経過時間が参照時間以上か否かを判断してもよい。なお、このＳ３８の処理は、最終参照時刻と現時刻との時間差を求め、その時間差と参照時間とを比較する処理である。
経過時間が参照時間よりも長いと判断した場合は（Ｓ３８：ＹＥＳ）、コマンダ１は、処理をＳ３９に移行させる。Ｓ３９において、コマンダ１は、Ｓ３３で抽出したファイル名に対応するカラオケデータを、記憶部９から削除する。また、当該ファイル名及び最終参照時刻を、時刻テーブルから削除する。一方、Ｓ３８において、経過時間が参照時間（第２の設定時間）以下であると判断した場合は（Ｓ３８：ＮＯ）、コマンダ１は、処理をＳ４３に移行させる。すなわち、Ｓ３３で抽出したファイル名のカラオケデータは記憶部９から削除しない。

一方、Ｓ３６において、ログイン人数が１人以上であると判断した場合は、コマンダ１は、Ｓ４０において、参照時間を「第１の設定時間」とする。ここで、第１の設定時間を、例えば、「２時間」とすることができる。すなわち、第２の設定時間は、第１の設定時間よりも短い。
本実施形態では、Ｓ３６の条件判断処理により、ログイン状態によって参照時間を調整している。

Ｓ４１において、コマンダ１は、現時刻と最終参照時刻に基いて算出した「最終参照時刻からの経過時間」が参照時間（第１の設定時間）よりも長いか否かを判断する。なお、このＳ４１において、当該経過時間が参照時間以上か否かを判断してもよい。
経過時間が参照時間（第１の参照時間）以下であると判断した場合は（Ｓ４１：ＮＯ）、コマンダ１は、処理をＳ４３に移行させる。すなわち、Ｓ３３で抽出したファイル名のカラオケデータは記憶部９から削除しない。一方、経過時間が参照時間よりも長いと判断した場合は（Ｓ４１：ＹＥＳ）、コマンダ１は、処理をＳ４２に移行させる。

Ｓ４２において、コマンダ１は、Ｓ３３で抽出したファイル名が、予約テーブルに記憶されているか否かを判断する。すなわち、Ｓ３３で抽出したファイル名のカラオケデータを用いたカラオケ演奏が今後行われるか否かを判断する。予約テーブルに記憶されていると判断すると（Ｓ４２：ＹＥＳ）、コマンダ１は、処理をＳ４３に移行させる。一方、予約テーブルに記憶されていないと判断すると（Ｓ４２：ＮＯ）、コマンダ１は、処理をＳ３９に移行させる。すなわち、Ｓ３３で抽出したファイル名に対応するカラオケデータを記憶部９から削除し、当該ファイル名及び最終参照時刻を時刻テーブルから削除する。
Ｓ４３において、コマンダ１は、時刻テーブルに記憶されている全てのファイル名を抽出したか否かを判断する。抽出していないファイル名が存在すると判断した場合は（Ｓ４３：ＮＯ）、コマンダ１は、処理をＳ３３に移行させる。一方、全てのファイル名を抽出したと判断した場合は（Ｓ４３：ＹＥＳ）、コマンダ１は、記憶部管理処理を終了する。

本実施形態では、カラオケ装置１０にログインしているユーザがいない場合には、ログインしているユーザがいる場合に比べて設定時間を短くしている。カラオケ装置１０にログインしているユーザがいない場合についても、他のカラオケ装置が、このカラオケ装置１０の記憶部９の記憶領域を用いることがある。例えば、カラオケデータの転送にＰ２Ｐ技術などを採用している場合、このカラオケ装置１０の記憶部９が他のカラオケ装置（コマンダ）へのデータ転送中継のための一時記憶手段として用いられることがある。そのため、ログインしているユーザいない（すなわち、このカラオケ装置１０が使用されていない）場合であっても、できるだけ記憶部９の空き容量を大きくしておいた方が好ましい。したがって、本実施形態のように構成することで、カラオケ装置１０の記憶部９を有効に活用することができる。

以上説明した記憶部管理処理により、再使用の可能性が低いカラオケデータを選択的に削除することができるので、カラオケ装置が有する記憶装置（記憶部９）を有効に活用することができる。

以上説明したカラオケシステムＳによれば、カラオケ装置の記憶容量を有効に活用しつつ、ネットワーク負荷を低減することができる。

本発明は上述した実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の改良、変形が可能であることはいうまでもない。

例えば、上述した実施形態によれば、ログイン人数によって参照時間を変更していたが、ログイン人数に関係なく、上記参照時間を等しくしてもよい。すなわち、参照時間を調整する処理を行わなくてもよい。その場合、図６のフローチャートにおいて、Ｓ３６〜Ｓ３８の処理を行わず、Ｓ３５の処理の次にＳ４０の処理を行う。なお、この場合、Ｓ４０における第１の設定時間は適宜設定可能である。

なお、上述した各フローチャートは単なる一例であり、該各フローチャートの処理と同等の結果を得ることができるものであれば、他のフローチャートによって処理を実現してもよい。また、上述したカラオケ装置及び投稿サーバに係る各方法、当該方法をコンピュータに実行させるためのプログラム、当該プログラムを記録した記録媒体等としても本発明は実現可能である。

Ｓ カラオケシステム
１ コマンダ
９ 記憶部
１０ カラオケ装置

Claims (3)

1. サーバからカラオケ演奏に用いられるカラオケデータを受信し、当該カラオケデータを用いてカラオケ演奏を行うカラオケ装置において、
   前記受信したカラオケデータと、当該カラオケデータが最後に用いられた時刻を示す最終参照時刻とを記憶するデータ記憶手段と、
   前記カラオケデータが用いられるごとに、当該カラオケデータの最終参照時刻を更新する時刻更新手段と、
   演奏するカラオケ楽曲の予約を受け付ける予約受付手段と、
   予約を受け付けたカラオケ楽曲の識別情報を記憶する予約記憶手段と、
   前記予約を受け付けたカラオケ楽曲のカラオケ演奏時に、当該カラオケ楽曲の識別情報を前記予約記憶手段から削除する予約管理手段と、
   前記カラオケデータの最終参照時刻と現時刻とを比較し、その時間差が参照時間よりも長く、かつ、当該カラオケデータの識別情報が前記予約記憶手段に記憶されていない場合に、当該カラオケデータ及び識別情報を前記データ記憶手段から削除するデータ削除手段と、
   を有するカラオケ装置。
2. 自装置へのログイン状態を判別するログイン状態判断手段と、前記参照時間を調整する参照時間調整手段と、をさらに有し、
   前記参照時間調整手段は、
   前記ログイン状態判断手段が少なくとも１人のユーザがログインしていると判断した場合には、前記参照時間を第１の設定時間とし、
   前記ログイン状態判断手段がいずれのユーザもログインしていないと判断した場合には、前記参照時間を前記第１の設定時間よりも短い第２の設定時間とする、
   請求項１のカラオケ装置。
3. ダウンロード制御手段、をさらに有し、
   前記ダウンロード制御手段は、前記予約受付手段がカラオケ楽曲の予約を受け付けたときに、当該カラオケ楽曲のカラオケデータが前記データ記憶手段に記憶されておらず、かつ、ダウンロード中でもない場合に、当該カラオケデータを前記サーバに要求する、
   請求項１または請求項２のカラオケ装置。

Images