(57)【特許請求の範囲】
【請求項１】
予め設定された演奏禁止条件に基づいて演奏処理を禁止する演奏禁止手段と、
前記演奏禁止手段により演奏処理が禁止されている場合において、一時解除命令が入力されたとき、予め設定された制限付解除条件に従って前記禁止を一時的に解除する演奏禁止制限解除手段と
を備えるとともに、
前記制限付解除条件は、前記演奏禁止制限解除手段によって前記禁止を解除してから、再び演奏処理を禁止するまでの期間を示す解除可能期間についての条件であり、
前記演奏禁止制限解除手段によって前記禁止が解除されてから、前記解除可能期間が経過したか否かを判別する経過期間判別手段を備える
ことを特徴とするカラオケ装置。
【請求項２】
予め設定された演奏禁止条件に基づいて演奏処理を禁止する演奏禁止手段と、
前記演奏禁止手段により演奏処理が禁止されている場合において、一時解除命令が入力されたとき、予め設定された制限付解除条件に従って前記禁止を一時的に解除する演奏禁止制限解除手段と
を備えるとともに、
前記制限付解除条件は、前記演奏禁止制限解除手段によって解除することが可能な解除可能回数についての条件であり、
前記演奏禁止制限解除手段によって前記禁止が解除された回数が前記解除可能回数に達したか否かを判別する解除回数判別手段を備える
ことを特徴とするカラオケ装置。
【請求項３】
予め設定された演奏禁止条件に基づいて演奏処理を禁止する演奏禁止手段と、
前記演奏禁止手段により演奏処理が禁止されている場合において、一時解除命令が入力されたとき、予め設定された制限付解除条件に従って前記禁止を一時的に解除する演奏禁止制限解除手段と
を備えるとともに、
前記制限付解除条件は、前記演奏禁止制限解除手段によって前記禁止を解除した後に演奏処理が可能な曲数を示す演奏可能曲数についての条件であり、
前記演奏禁止制限解除手段によって前記禁止が解除されてから演奏処理が行われた曲数が前記演奏可能曲数に達したか否かを判別する演奏曲数判別手段を備える
ことを特徴とするカラオケ装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、特にボックスタイプのカラオケシステムに用いて好適な、予め設定された演奏禁止条件に基づいて演奏処理を禁止する演奏ロック機能を備えたカラオケ装置に関する。
【０００２】
【従来の技術】
従来より、曲の配信や保守（メンテナンス）を通信回線も介して行う（オンライン運用）通信カラオケにおいて、演奏ロックという機能を備えたカラオケシステムが用いられている。
演奏ロック機能とは、システム運用者が定期的なメンテナンス処理を実行した後に、各カラオケ端末において所定の期間が経過した場合や、所定の曲数の演奏が行われた場合などのように、予め設定された演奏禁止条件に基づいて演奏処理を禁止する機能である。
このような演奏ロック機能を各カラオケ端末に備えておけば、例えばカラオケ端末が盗難された場合でも、所定の期間が経過したり、所定曲数を演奏した後は演奏をすることができないのでカラオケ装置としての目的を果たすことができず、盗難された場合の不正運用を防止することが可能となる。
このため、各端末の使用者が演奏ロックによる演奏禁止を自由に解除することはできず、システム運用者側から演奏ロックを解除するコマンドを受信しなければ演奏ロックを解除できないように設定されていた。
ところで、演奏ロック機能を有するカラオケシステムの中には、通信機器を具備しないカラオケ端末装置を使用している場合がある。そして、このような通信機器を具備しないカラオケ端末装置の保守を行う場合には、通信回線を介して保守を行うことができないので、システム運用者は定期的に各カラオケ端末装置の保守を行うための巡回を行う（オフライン運用）。すなわち、携帯の保守端末を各カラオケ端末装置に接続して保守を行う。
このような保守は、通常は演奏ロックが発生する前に定期的に行われるようになっている（定期保守）。
【０００３】
【発明が解決しようとする課題】
しかしながら、このような演奏ロック機能を備える場合には保守が遅れた場合に不具合が生じる。例えば、システム運用者側の曲制作の遅れなどのトラブルによって保守が遅れ前回の保守が行われた後に定期保守がなされないまま一定期間が経過してしまうと、演奏ロック状態に移行して、各カラオケ端末装置を保有する業者であっても営業することができないという問題が生じる。
このように、従来の演奏ロック機能を備えるカラオケシステムにおいては、システム運用者側の問題のために、各カラオケ端末装置の保有者がカラオケ端末装置を円滑に使用できない場合が生じるという問題があった。
【０００４】
本発明は、上述した課題を解決するためになされたものであり、不正な使用を防止しつつ、円滑に使用することが可能なカラオケ装置を提供することを目的としている。
【０００５】
【課題を解決するための手段】
上述した課題を解決するために、請求項１に記載の発明は、予め設定された演奏禁止条件に基づいて演奏処理を禁止する演奏禁止手段と、前記演奏禁止手段により演奏処理が禁止されている場合において、一時解除命令が入力されたとき、予め設定された制限付解除条件に従って前記禁止を一時的に解除する演奏禁止制限解除手段とを備えるとともに、前記制限付解除条件は、前記演奏禁止制限解除手段によって前記禁止を解除してから、再び演奏処理を禁止するまでの期間を示す解除可能期間についての条件であり、前記演奏禁止制限解除手段によって前記禁止が解除されてから、前記解除可能期間が経過したか否かを判別する経過期間判別手段を備えることを特徴とする。
また、請求項２に記載の発明は、予め設定された演奏禁止条件に基づいて演奏処理を禁止する演奏禁止手段と、前記演奏禁止手段により演奏処理が禁止されている場合において、一時解除命令が入力されたとき、予め設定された制限付解除条件に従って前記禁止を一時的に解除する演奏禁止制限解除手段とを備えるとともに、前記制限付解除条件は、前記演奏禁止制限解除手段によって解除することが可能な解除可能回数についての条件であり、前記演奏禁止制限解除手段によって前記禁止が解除された回数が前記解除可能回数に達したか否かを判別する解除回数判別手段を備えることを特徴とする。
また、請求項３に記載の発明は、予め設定された演奏禁止条件に基づいて演奏処理を禁止する演奏禁止手段と、前記演奏禁止手段により演奏処理が禁止されている場合において、一時解除命令が入力されたとき、予め設定された制限付解除条件に従って前記禁止を一時的に解除する演奏禁止制限解除手段とを備えるとともに、前記制限付解除条件は、前記演奏禁止制限解除手段によって前記禁止を解除した後に演奏処理が可能な曲数を示す演奏可能曲数についての条件であり、前記演奏禁止制限解除手段によって前記禁止が解除されてから演奏処理が行われた曲数が前記演奏可能曲数に達したか否かを判別する演奏曲数判別手段を備えることを特徴とする。
【０００６】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態について説明する。
【０００７】
１．実施形態の構成
図１は、実施形態の構成を示す機能ブロック図である。実施形態は、本発明を適用したカラオケシステムである。なお、本実施形態は、オフライン運用の場合のシステム構成を示しており、カラオケ装置１００、保守端末２００および、カラオケ装置１００と保守端末２００とを接続するケーブル３００を備えて構成されている。
本実施形態では、システム運用者の問題によって保守が遅れた場合には、カラオケ装置１００の操作において、予め設定された制限付解除条件に基づいて禁止を制限的に解除する「短期延長」を行うことができるように構成されている。
【０００８】
カラオケ装置１００は、制御部１０１、タイマ１０２、演奏曲数カウンタ１０３、延長回数カウンタ１０４、演奏ロック設定ファイル記憶部１０５、演奏部１０６、ユーザインターフェイス１０７、および保守端末インターフェイス１０８を備えて構成されている。
制御部１０１は、例えばＲＯＭに記憶されたプログラムに従って動作するＣＰＵであり、上記各部とはバスを介して接続されている。
タイマ１０２は、後に説明するように、保守が行われてからの経過時間や、延長が実行されてからの経過時間を計時するものである。
演奏曲数カウンタ１０３は、演奏部１０６において演奏が行われたのべ曲数を計数するカウンタであり、延長回数カウンタ１０４は、延長が実行された回数を計数するカウンタである。
また、演奏ロック設定ファイル記憶部１０５は、予め設定された制限付解除条件（後述する演奏ロック設定ファイル）を記憶するものであり、例えば、不揮発性のメモリやハードディスクなどが用いられる。
演奏部１０６は、曲データを再生して発音処理を行うものであり、曲データを記憶するメモリや、音源、サウンドシステムなどを具備している。
ユーザインターフェイス１０７は、短期延長の指示やリクエストなどを入力するための操作子や各種情報を表示するディスプレイなどを具備している。
そして、保守端末インターフェイス１０８は、保守端末２００と接続するためのインターフェイスである。
【０００９】
また、保守端末２００は、システム運用者が携帯する保守のための装置であり、カラオケ装置２００のデータを更新したり演奏ロックを解除するために用いられる。カラオケ装置１００と保守端末２００とは、ケーブル３００によって接続されており、保守のためのコマンドや曲データなどの各種データを送受信することができるようになっている。ケーブル３００には、例えばシリアルケーブルなどが用いられる。
【００１０】
ここで、演奏ロック設定ファイル記憶部１０５に記憶されている演奏ロック設定ファイルについて説明する。図２は、演奏ロック設定ファイルの構成を示す図である。
演奏ロック設定ファイルは、制限付解除条件を示すデータを含んで構成されたファイルであり、本実施形態では、演奏ロック設定ファイルが示すデータに基づいて、演奏ロックを制限的に解除する「短期延長」が行われるようになっている。
ここで図２に示すように、演奏ロック設定ファイルは、演奏ロックが発生するための演奏禁止条件である演奏ロックしきい値を示すデータと、演奏ロックを制限的に解除して「短期延長」を行う場合の延長の制限（期間および回数）を示す制限付解除条件である延長しきい値を示すデータとを備えて構成されている。
なお、「短期延長」の期間および回数が制限されているのは、演奏ロック機能が盗難や不正運用を防止するための機能であるから、無制限に延長を認めることが妥当ではないからである。
【００１１】
まず、演奏ロックしきい値は、演奏ロックが発生する条件となる数値であり、前回保守が行われてからの経過日数および演奏曲数の二つのしきい値がある。なお、以下の説明において、経過日数を示すしきい値をＲＮと、演奏曲数を示すしきい値をＲＫとする。
また、延長しきい値は、延長を行うことができる上限を示す数値であり、延長日数のしきい値をＥＮとし、延長回数しきい値をＥＫとする。
図２に示した例では、保守後３０日間あるいは、保守後演奏曲数が３０００曲を超えた場合は、演奏ロックが行われることを示している。
また、演奏ロックが行われた後に短期延長を実行した後１０日が経過すると再び演奏ロックが行われ、延長の上限は２回であることを示している。
このようなしきい値を示すデータは、保守端末２００によって更新できるようになっており、システム運用者は、通常保守において次回の保守予定に応じてしきい値を設定したり、カラオケ端末１００の各保有者の使用状況などに応じて容易に設定を変更することができるようになっている。
【００１２】
２．実施形態の動作
次に、本実施形態の動作について説明する。
【００１３】
２−１．制御部１０１の動作
まず、図３を参照して制御部１０１の動作について説明する。
次に、図３のステップＳに示した保守処理について説明する。まず、制御部１０１は、保守端末２００によって保守が行われるか否かについて判別し（Ｓ１０１）、保守を行うと判別した場合は（Ｓ１０１；ＹＥＳ）、保守処理を実行する（Ｓ２００）。
より具体的には、図４に示す保守処理のサブルーチンに基づく処理を行う。
【００１４】
図４を参照すると、まず制御部１０１は、保守端末２００からデータを入力する（Ｓ２０１）。ここで入力するデータは、演奏ロック設定ファイルや曲データの更新や、演奏ロックを解除するためのコマンドやデータなどである。
次に、制御部１０１は、入力したデータに基づいて演奏ロック設定ファイルや曲データなどのデータ更新処理を行う（Ｓ２０２）。
そして、演奏曲数カウンタ１０３（Ｓ２０３）およびタイマ１０２をリセットする（Ｓ２０４）。すなわち、演奏ロックファイル中の演奏しきい値と比較して演奏ロックを行うか否かを判断するための値を初期化する処理を行う。
また、延長回数カウンタ１０４もリセットし（Ｓ２０５）、演奏ロックがまだ一度も行われていない状態に戻す処理を行う。
【００１５】
次に、現在演奏ロックがされているか否かを判別し（Ｓ２０６）、演奏ロックがされていると判別した場合には（Ｓ２０６；ＹＥＳ）、制御部１０１は演奏ロックを解除する処理を行った後（Ｓ２０７）、保守処理を終了してメインルーチンに戻る。演奏ロック解除処理は、具体的には、図３のステップＳ１０５において行う、演奏ロック表示の解除や演奏ロック中であることを示すレジスタの値をクリアする処理などが該当する。
一方、ステップＳ２０６の判別において、演奏ロックが行われていないと判別した場合は、保守処理を終了してメインルーチンに戻る。
【００１６】
説明を再び図３に示すフローチャートに戻す。
ステップ１０１判別において、保守なしと判別した場合は（Ｓ１０１；ＮＯ）、次に制御部１０１は、延長回数カウンタ１０４のカウント値が０であるか否かを判別する（Ｓ１０２）。
ステップＳ１０２の判別において、延長回数カウンタ１０４のカウンタ値が０であると判別した場合は（Ｓ１０２；ＹＥＳ）、保守が行われた後にまだ延長が一度も行われていないので、制御部１０１は演奏ロック設定ファイルの演奏ロックしきい値を参照して、演奏ロックを行うか否かを判別する。
すなわち、まず、タイマ１０２の値がしきい値ＲＮを超えているか否かを判別し（Ｓ１０３）、しきい値ＲＮを超えていないと判別した場合は（Ｓ１０３；ＮＯ）、次に演奏曲数カウンタ１０３のカウント値がしきい値ＲＫを超えているか否かを判別する（Ｓ１０４）。
ステップＳ１０３あるいはステップＳ１０４の判別において、しきい値を超えていると判別した場合は（Ｓ１０３；ＹＥＳあるいはＳ１０４；ＹＥＳ）、演奏ロックの条件を満たしているので、制御部１０１は演奏ロック処理を行う（Ｓ１０５）。演奏ロック処理とは、例えばユーザインターフェイス１０７のディスプレイに演奏ロック中である旨の表示をするとともに、使用者がユーザインターフェイス１０７を介してリクエストデータを入力しても演奏処理を実行しない処理などが該当する。
【００１７】
演奏ロック処理（Ｓ１０５）を実行した後、制御部１０１は、次に延長を行うか否かを判別する（Ｓ１０６）。ここでは、ユーザインターフェイス１０７を介して、延長を行うことを指示するデータが入力された場合には、延長を行うと判別する。
しかし、延長を行わないことを指示するデータが入力された場合や、延長回数カウンタ１０４のカウント値がしきい値であるＲＫに達している場合は、延長を行わないと判別する。
ステップＳ１０６の判別において、延長を行わないと判別した場合は（Ｓ１０６；ＮＯ）、処理をステップＳ１０１に移行して、再度保守を行うか否かを判別する（Ｓ１０１）。
【００１８】
一方、ステップＳ１０６の判別において、延長を行うと判別した場合は（Ｓ１０６；ＹＥＳ）、制御部１０１は演奏ロックを解除する（Ｓ１０７）。ここでは、制御部１０１は、延長回数カウンタ１０４のカウント値を１アップカウントし、ユーザインターフェイス１０７のディスプレイに表示した演奏ロック中を示す表示を消去し、操作子からリクエストデータの入力を受け付ける。
次に、制御部１０１は、タイマ１０２をリセットして（Ｓ１０８）、延長を実行してからの経過時間の計数を開始する。
そして、ステップＳ１０８の処理が終了した後、あるいは、ステップＳ１０４の判別において、演奏曲数カウンタ１０３のカウント値がしきい値ＲＫを超えていないと判別した場合は（Ｓ１０４；ＮＯ）、制御部１０１は、演奏処理を実行する（Ｓ１０９）。演奏処理においては、ユーザインターフェイス１０７を介して入力されるリクエストデータに基づいて、演奏部１０６を制御して楽音生成処理を実行する。
演奏処理が終了すると、制御部１０１は、次に演奏回数カウンタ１０４のカウント値を１アップカウントして（Ｓ１１０）、処理をＳ１０１に移行させる。
【００１９】
ところで、ステップＳ１０２の判別において、延長回数カウンタのカウント値が０ではないと判別した場合は（Ｓ１０２；ＮＯ）、すでに延長が実行されているので、制御部１０１は、演奏ロック設定ファイルの延長しきい値を参照して、さらに演奏ロックを実行するか演奏処理を実行するかを判別する。具体的には、タイマ１０２の値がしきい値ＥＮを超えているか否かを判別し（Ｓ１１１）、しきい値ＥＮを超えていると判別した場合は（Ｓ１１１；ＹＥＳ）、延長可能日数に達しているので、処理をステップＳ１０５に移行させて、演奏ロック処理を実行する。
一方、ステップＳ１１１の判別において、しきい値ＥＮを超えていないと判別した場合は（Ｓ１１１；ＮＯ）、まだ延長可能日数の上限に達していないので、処理をステップＳ１０９に移行させて、演奏処理を実行する。
【００２０】
２−２．実施形態の具体的動作
次に、図３および図５を参照して、実施形態の具体的動作について説明する。図５は、ｔ１〜ｔ７の各時点におけるタイマ１０２、演奏曲数カウンタ１０３、および延長回数カウンタ１０４の値と制御部１０１の処理の内容を示すタイムチャートである。
【００２１】
まず、ｔ１において保守処理が実行されると、タイマ１０２、演奏曲数カウンタ１０３、および延長回数カウンタ１０４の値は、リセットされていずれも”０”になる（図４に示す保守処理参照）。
そして、ｔ１から２０日経過したｔ２の時点で３０００曲演奏されたとすると、タイマ１０２の値は”２０”であり図３のステップＳ１０３では演奏ロックと判別されないが、演奏曲数カウンタ１０３の値が”３０００”であるので、図３ステップＳ１０４において演奏ロックと判別される。
演奏ロック処理が行われた後、ステップＳ１０６において延長ありと判別されると、延長処理が実行されるとともにタイマ１０２がリセットされて（図３Ｓ１０７、Ｓ１０８）、タイマ１０２の値が”０”になる。また、延長に際して延長回数カウンタ１０４が１アップカウントされるので（図３：Ｓ１０７）、ｔ３の時点においては、タイマ１０２の値は”０”に、延長回数カウンタ１０４の値は”１”になる。
【００２２】
その後、図３のフローチャートを循環する過程において、ステップＳ１０２の判別では延長回数カウンタ１０４の値は”０”ではないと判別して（Ｓ１０２；ＮＯ）、その後はタイマ１０２の値を参照して演奏ロックを行うか否かを判別する。
そして、ｔ４においてはタイマ１０２の値が”１０”を超えているので、図３のステップＳ１１１においてＹＥＳと判別して演奏ロック処理が実行される（図３：Ｓ１０５）。ここで再度延長と判別すると、延長回数カウンタが１アップカウントされて、ｔ５の時点では、タイマ１０２の値が”０”に戻り、延長回数カウンタ１０４の値が”２”となる。
【００２３】
しかし、演奏ロック設定ファイル中の延長回数しきい値ＥＫ＝２であるので（図２参照）、ｔ６の時点においてタイマ１０２の値が”１０”となって演奏ロック処理が実行されても、図３ステップＳ１０６の判別においては延長しないと判別する。
そして、ｔ７の時点において、保守処理を実行した場合は、タイマ１０２、演奏曲数カウンタ１０３、および延長回数カウンタ１０４の値は、いずれもリセットされて”０”になる（図４に示す保守処理参照）。
【００２４】
このように、システム運用者による保守が行われないまま、経過日数が演奏ロックしきい値ＲＮに達した場合でも、カラオケ装置１００の操作において短期延長を実行することができるので、カラオケ装置１００の保有者は通常通り使用を継続することが可能となる。
また、システム運用者にとっても、短期延長を行う場合の日数や延長回数を制限することができ、また、演奏ロックが発生する条件も容易に設定を変更することができるので、短期延長によって生じる不正運用なども防止することができる。
【００２５】
３．変形例
なお、本発明は既述した実施形態に限定されるものではなく、以下のような各種の変形が可能である。
【００２６】
上記実施形態においては、延長実行後は、タイマ１０２の値で演奏ロックを行うか否かを判別したが、演奏曲数で判別するようにしてもよい。この場合は、演奏ロック設定ファイルの延長しきい値には演奏可能曲数を記憶しておけばよい。また、演奏曲数と経過日時とを組み合わせた条件としてもよいのは勿論である。
【００２７】
また、上記実施形態では、タイマ１０２、演奏曲数カウンタ１０３、および延長回数カウンタを設けて経過日数を計時しているが、これに限らず、例えばログファイルを作成して、ログの記録に基づいて判別を行うようにしてもよい。例えば、保守を実行した日時や延長を実行した時のログの日時と、現在時との差を算出して経過日時を判別すればよい。また、ログに記録された演奏曲の記録に基づいて曲数を判別してもよい。
【００２８】
また、保守端末（オフライン）に限らず、オンライン運用においても本発明を適用してもよい。
この場合は、図６に示すように、カラオケ装置１００には、センタ４００と通信回線５００を介してデータやコマンドを送受信するための通信インターフェイス１１０を設ければよい。
【００２９】
【発明の効果】
以上説明したように、本発明によれば、不正な使用を防止しつつ、円滑に使用することが可能となる。
【図面の簡単な説明】
【図１】  実施形態の構成を示すブロック図である。
【図２】  演奏ロック設定ファイルの構成を示す図である。
【図３】  実施形態の動作を示すフローチャートである。
【図４】  保守処理のサブルーチンを示すフローチャートである。
【図５】  実施形態の具体的動作を示すタイムチャートである。
【図６】  実施形態の変形例の構成を示すブロック図である。
【符号の説明】
１００……カラオケ装置
１０１……制御部
１０２……タイマ
１０３……演奏曲数カウンタ
１０４……延長回数カウンタ
１０５……演奏ロック設定ファイル記憶部
１０６……演奏部
１０７……ユーザインターフェイス
１０８……保守端末インターフェイス
２００……保守端末
３００……ケーブル
【図１】
0004123581.tif 000002
【図２】
0004123581.tif 000003
【図３】
0004123581.tif 000004
【図４】
0004123581.tif 000005
【図５】
0004123581.tif 000006
【図６】
0004123581.tif 000007