JP4096772B2 - 稼働実績情報処理方法、情報処理装置及びプログラム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、情報処理装置からホスト装置へアップロードする稼働実績情報の処理技術に関する。
【０００２】
【従来の技術】
従来、例えばいわゆる通信カラオケシステムの場合、カラオケ装置（端末）の多くは、利用者からの指定によってさまざまな楽曲の再生やコンテンツの再生を行っており、通信カラオケシステムの運営者は、利用者にいち早く新曲が歌えるよう定期的にカラオケ装置とホスト装置を電話回線やＩＳＤＮ回線などの通信回線を介して接続して楽曲データの更新やゲーム等のコンテンツ、新しい機能の実装のためのプログラム配信を行っている。このようなコンテンツ等はカラオケ装置内のハードディスク等の記憶メディアに記録されるが、そのハードディスク等の記憶メディアは長時間稼働していることから故障する可能性があり、またプログラムの不具合により稼働に支障を来す場合も考えられる。
【０００３】
そのため、カラオケ装置からホスト装置へ稼働実績情報をアップロードし、ホスト装置において、その収集した稼働実績情報を解析して異常を検知した場合、その異常を管理者に通知する対策が考えられている（例えば、特許文献１参照。）。
【０００４】
【特許文献１】
特開２０００−２４２８６４号公報
【０００５】
【解決しようとする課題】
このような稼動実績情報は、故障や不具合が発生した場合の早期発見や原因の早期解明の観点からすれば、できるだけ詳細なログを記録しておくことが望まれる。しかしながら、カラオケ装置の場合であればハードディスクは本来曲データ等のコンテンツを記憶するものであって記憶容量にも限りがある、また、各地に設置されたカラオケ装置からの稼働実績情報の集信時間や通信コストのことを考慮すると、全てのカラオケ装置から詳細な稼働実績情報を収集するのは現実的に困難であり、結局、異常が発生した場合の原因の究明に困難を来していた。
【０００６】
そこで本発明は、適切な稼働実績情報をアップロードできるようにする技術を提案することを目的とする。
【０００７】
【課題を解決するための手段及び発明の効果】
（イ）上述した問題点を解決するためになされた請求項１に係る発明は、ホスト装置との間で通信が可能であり、少なくとも稼働実績情報をそのホスト装置へアップロード可能な情報処理装置における稼働実績情報の処理方法であって、稼働実績情報については、その稼働内容を実績として収集する重要性の高低に応じた複数のレベルに分類されており、高レベル稼働実績情報については、その全てを記憶し、定期的に前記ホスト装置へアップロードした後で削除、もしくは削除可能な状態とし、一方、低レベル稼働実績情報については、古い情報から削除することで一定以下の情報量となるようにしながら記憶し、ホスト装置から低レベル稼働実績情報のアップロード要求があった場合にはホスト装置へアップロードした後で削除、もしくは削除可能な状態とする稼働実績情報の処理方法である。
【０００８】
このような稼働実績情報の処理方法を実行する情報処理装置としては、例えば請求項２に示す構成を採用することが考えられる。つまり、請求項２に係る情報処理装置は、稼働実績情報を記憶するための記憶手段、少なくとも稼働実績情報をホスト装置へアップロード可能な通信手段を備えている。そして、稼働実績情報については、その稼働内容を実績として収集する重要性の高低に応じた複数のレベルに分類されており、記憶手段は、高レベル稼働実績情報を記憶する第一の記憶領域と、低レベル稼働実績情報を記憶する第二の記憶領域とを有している。
【０００９】
そして、稼働実績情報記憶制御手段が次のような制御を実行する。つまり、高レベル実績情報については、その全てを第一の記憶領域に記憶しておき、ホスト装置へのアップロード後は第一の記憶領域から高レベル実績情報を削除、もしくは削除可能な状態とする。一方、低レベル稼働実績情報については、新規情報を記憶しようとした場合に第二の記憶領域の記憶容量を超えるのであれば、既に記憶されている古い情報を削除してから記憶し、ホスト装置へのアップロード後は第一の記憶領域から高レベル実績情報を削除、もしくは削除可能な状態とする。また、アップロード制御手段が次のような制御を実行する。つまり、第一の記憶領域に記憶された高レベル実績情報については定期的に、一方、第二の記憶領域に記憶された低レベル稼働実績情報については前記ホスト装置から低レベル稼働実績情報のアップロード要求があった場合に、それぞれ通信手段を介してホスト装置へアップロードする。
【００１０】
なお、「稼働実績情報を削除、もしくは削除可能な状態とする」とは、稼働実績情報を記憶手段から文字通り削除してもよいし、あるいは稼働実績情報自体は記憶手段に残っているが上書きしてもよい状態にすることを意味する。要は、新規に情報を記憶させようとした場合に、従前の稼働実績情報が存在することで記憶させることができないことを防ぐ目的であるため、情報自体が存在しなければ当然問題ない、また情報は存在しても、新規な情報を既存の情報上に上書きできるのであれば何ら問題ないからである。具体的には、削除してもよい情報であることを示す識別情報を付与したり、記憶手段上の削除しても良い情報が記憶されているエリアを管理することで、それらが上書き対象の情報であることを判断できるようにしておけばよい。
【００１１】
本発明による作用効果への理解を容易にするため、例えば通信カラオケシステムに用いられるカラオケ装置を情報処理装置の例として考えてみる。例えば稼働実績情報（以下、稼働ログとも称す。）について、その重要度等に基づいて１〜５の５段階のレベルを付与する。例えば明らかに異常を示す稼働ログについては最高レベルの１とし、例えば選曲キーが押された場合などの通常の操作を示す稼働ログについては最低レベルの５とする、といった具合である。
【００１２】
ここで、カラオケ装置はホスト装置へ定期的に（例えば毎日とか１〜２週間おき）アップロードするとし、その場合のアップロードする稼働ログはレベル３以上（レベル３，２，１）とする。その場合は、これらレベル３以上の稼働ログを第一の記憶領域に記憶しておき、定期的にアップロードする。
【００１３】
一方、第二の記憶領域には、例えば全ての稼働ログ（５，４，３，２，１）について記憶しておき、ホスト装置からの特別なアップロード要求があった場合に限ってアップロードする。具体的には、上述した定期的にアップロードする稼働ログをホスト装置側にてチェックした結果、異常の原因をさらに解明したい場合などにこのアップロード要求がなされる。つまり、上述例で言えば、選曲キーが押されたという稼働ログは、一般的には通常の動作を示してはいるが、何か異常が発生した場合には、このような低レベルの稼働ログ（つまり、詳細な稼働ログ）も合わせて判断することでより適切に原因を解明することができる。
【００１４】
しかしながら、このような詳細な稼働ログが必要になるの何らかの異常が発見された場合であり、恒常的にこのような詳細な稼働ログをアップロードすることは、アップロードに要する通信コストの増大、通信時間の増大、ホスト装置側での処理負荷の増大等を招来してしまう。特に、現状の通信カラオケシステムであっても１台のホスト装置にアップロードするカラオケ装置の数は膨大であり、これら各カラオケ装置からアップロードされる稼働ログが多いと、総量としては非常にデータ量が多くなり、処理負荷は相当なものとなる。
【００１５】
そこで、定期的にアップロードするのは高レベルの稼働ログだけにし、ホスト装置側で必要になった場合に限って低レベルの（つまり詳細な）稼働ログをアップロードするようホスト装置からカラオケ装置へ要求することで、上述の通信コスト・通信時間・ホスト装置側での処理負荷の増大等を防止できる。それでいて異常原因の解明のために必要な稼働ログもホスト装置側で容易に収集することができるのである。
【００１６】
但し、高レベルの稼働ログについては定期的にアップロードされ、アップロード後は稼働ログのデータが削除、もしくは削除可能な状態とされるため問題ないが、低レベルの稼働ログのアップロード要求はいつあるか分からないため、何ら対策を講じないと記憶手段（例えばハードディスク）の記憶領域を無制限に使ってしまうこととなる。そこで、本発明では、上述のように、低レベル稼働実績情報を新規に記憶しようとした場合に第二の記憶領域の記憶容量を超えるのであれば、既に記憶されている古い情報を削除してから記憶するようにしている。このようにすることで、カラオケ装置側の記憶手段の記憶領域を無制限に使ってしまうことがなくなり、例えば本来のサービスのために必要なカラオケ楽曲データ等の格納を妨げることがなくなる。そして、例えば高レベルの稼働ログに基づいて異常があると判断され、その原因を解明するために低レベルの稼働ログのアップロード要求があった場合、実際に必要な低レベルの稼働ログとしては、異常を発見した高レベルの稼働ログに対応する範囲のものである。例えば高レベルの稼働ログについて毎日アップロードとしているのであれば、その日１日分程度の範囲で低レベルの稼働ログについてもあればよいこととなる。したがって、そのような範囲の稼働ログが記憶できる記憶領域としておけば原因解明には寄与でき、さらにアップロードするデータ量も過大になることがないため、上述した通信コスト・通信時間・ホスト装置側での処理負荷の増大等の防止の観点でさらによい。
【００１７】
このように本発明では、適切なタイミングで適切な稼働実績情報をアップロードできるようになる。
（ロ）なお、アップロード制御手段が第一の記憶領域に記憶された高レベル実績情報をホスト装置へアップロードする場合には、ホスト装置から定期的に出されるアップロード要求に応じてアップロードしてもよいし（請求項３）、予め定められた時刻になった場合に自動的にアップロードするようにしてもよい（請求項４）。
【００１８】
（ハ）また、請求項２〜４の何れかに記載の情報処理装置における稼働実績情報記憶制御手段及びアップロード制御手段をコンピュータにて実現する場合、例えばコンピュータで実行するプログラムとして備えることができる。このようなプログラムは、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ハードディスク、ＲＯＭ、ＲＡＭ等のコンピュータ読み取り可能な記録媒体に記録し、必要に応じてコンピュータにロードして実行したり、ネットワークを介してロードして実行することにより、情報処理装置としての機能を実現できる。
【００１９】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうる。
【００２０】
図１は、実施例のカラオケ装置１の概略構成を示している。本実施例のカラオケ装置１は、カラオケ店舗に設置されており、例えばカラオケ店舗の各部屋にそれぞれ１台ずつ設置される。なお、これら複数台のカラオケ装置１は店舗内ネットワーク３０にて接続されている。そして、これら複数台のカラオケ装置１の内、何れか一つ（以上）のカラオケ装置１は、公衆回線を介して配信用ホスト装置５０に接続できるようになっており、この公衆回線４０を介して接続した配信用ホスト装置５０からカラオケに関する配信データ（音楽情報や画像情報、あるいは例えばカラオケ演奏処理を実行するためのアプリケーションプログラム（カラオケ演奏プログラム）等）を取得して、例えばハードディスク等の記憶装置１３へ記憶しておくことができる。そして、カラオケ装置１は、記憶装置１３に記憶されている配信データを、店舗内ネットワーク３０によって接続された他のカラオケ装置１へ送信することができる。そのため、公衆回線４０を介して配信用ホスト装置５０と接続する機能を持つカラオケ装置１がマスタ（親機）となり、他のカラオケ装置１がスレーブ（子機）となっている。
【００２１】
また、マスタは自装置の稼働実績情報（稼働ログ）、及び店舗内ネットワーク３０を介してスレーブから受け取った稼働ログを、公衆回線４０を介して配信用ホスト装置５０へアップロードできるように構成されている。図２に示すように、配信用ホスト装置５０は、多数のカラオケ装置１（この場合はマスタを意味する。）と接続可能となっており、これら多数のカラオケ装置１に対して配信データを送信したり、逆にアップロードされた稼働ログを受信する。配信用ホスト装置５０及び図２に示した監視装置６０については、後述する。
【００２２】
［カラオケ装置１の説明］
マスタまたはスレーブとして機能するカラオケ装置１の基本的な構成はいずれも同じであるが、上述のように、マスタのみが公衆回線４０を介して配信用ホスト装置５０に接続できるようになっている。それ以外の機能は基本的にいずれも同じである。したがって、以下の構成説明に関しては、図１に示す（マスタとして機能する）カラオケ装置１に関して行うこととする。
【００２３】
カラオケ装置１は、図１に示すように、カラオケ装置１を制御するための中央処理装置１１、ネットワークとしての店舗内ネットワーク３０を介して他のカラオケ装置（この場合はスレーブ）と接続したり、公衆回線４０を介して配信用ホスト装置５０と接続し、各種の情報を送受信する通信制御装置１２、各種データ等を記憶している記憶装置１３、曲の予約や電源のＯＮ・ＯＦＦなどを行うための操作パネル１４、操作パネル１４と同様に曲の予約等を行うためのリモコン送信機１５、リモコン送信機１５からの信号を受信するためのリモコン受信機１６、操作パネル１４やリモコン受信機１６からの信号を受け付けて処理する操作制御部１７、演奏の再生を行うシンセサイザ１８、音楽情報にかかる電気信号を増幅等するミキシングアンプ１９、ミキシングアンプ１９からの電気信号を入力して伴奏曲及び利用者の歌声等を流すスピーカ２０、利用者の歌声等をミキシングアンプ１９に入力するマイクロフォン２１、中央処理装置１１によって生成された歌詞情報を記憶するビデオＲＡＭ２２、画像情報等を映像化する映像再生装置２３、ビデオＲＡＭ２２からの歌詞情報や映像再生装置２３からの映像信号に基づき、歌詞及び歌詞の背景映像を出力する映像制御部２４、映像制御部２４から出力された歌詞及び歌詞の背景映像を表示する表示装置２５、現在の日付や日時を常にカウントしていて中央処理装置１１に通知するカレンダクロック２７を備えている。また、このうちの中央処理装置１１には、通信制御装置１２、ハードディスク１３、操作制御部１７、シンセサイザ１８、ビデオＲＡＭ２２、映像再生装置２３、映像制御部２４及びカレンダクロック２７が接続されており、中央処理装置１１は、これらを介してカラオケ装置１を制御する。
【００２４】
続いて各部の具体的な構成を説明する。
［中央処理装置１１および記憶装置１３の構成］
まず、中央処理装置１１は、ＣＰＵ、ＲＯＭ、ＲＡＭなどを備える周知の構成である。一方、記憶装置１３は、例えばハードディスク等から構成されており、中央処理装置１１がカラオケ装置１を制御するための各種プログラム、カラオケ演奏用のデータ等を記憶している。また、この記憶装置１３にはカラオケ装置１における稼働実績情報（稼働ログ）も記憶されるのであるが、図１に示すように、通常ログ記憶領域１３ａと詳細ログ記憶領域１３ｂが準備されており、後述する通常ログ、詳細ログがそれぞれこれら通常ログ記憶領域１３ａ、詳細ログ記憶領域１３ｂに記憶される。また、これら稼働ログにはログレベルが付与されているのであるが、この稼働ログがどのログレベルかを示すログテーブルもこの記憶装置１３に記憶されている。図３は、演奏タスクのログテーブルの一部を示している。
【００２５】
なお、カラオケ装置１の中央処理装置１１は、稼働実績情報記憶制御手段及びアップロード制御手段に相当する。
［通信制御装置１２の構成］
通信制御装置１２は、店舗内ネットワーク３０を介してカラオケ店舗内の他の部屋に設置されたカラオケ装置（この場合はスレーブ）に接続されており、これら他のカラオケ装置（この場合はスレーブ）との間で各種の情報を送受信する。また、カラオケ装置１の通信制御装置１２は、上述したように、公衆回線４０を介して配信用ホスト装置５０と接続し、この配信用ホスト装置５０との間で各種の情報を送受信する。
【００２６】
［操作制御部１７、操作パネル１４、リモコン送受信機１５，１６の構成］
操作制御部１７には、操作パネル１４およびリモコン受信機１６が接続されている。このうち、操作パネル１４は、利用者がカラオケ曲の選択や演奏アレンジの切り替えを行ったりするためのものであり、図２（ａ）にその外観を模式的に示すように、各種操作ボタンや選曲番号等の表示のためのＬＥＤ等を備えている。なお、この操作パネル１４は装置本体の正面側に設けられており、「ＨＭＩ部」に相当する。利用者がこの操作パネル１４を操作すると、その入力操作の信号が操作制御部１７および中央処理装置１１に送られて処理される。一方、リモコン受信機１６は、リモコン送信機１５からの信号を受信するためのものである。また、このリモコン送信機１５は、操作パネル１４と同様に、利用者がカラオケ曲の選択や演奏アレンジの切り替えを行ったりするためのものである。利用者がこのリモコン送信機１５を操作すると、その入力操作の信号がリモコン受信機１６を介して操作制御部１７および中央処理装置１１に送られて処理される。
【００２７】
［その他の構成］
また、シンセサイザ１８には、ミキシングアンプ１９が接続され、このミキシングアンプ１９にはスピーカ２０が接続されている。ハードディスク１３等から読み出され、中央処理装置１１から供給される音楽情報（ＭＩＤＩ形式のカラオケ演奏データ）に基づいてシンセサイザ１８から出力される楽音信号はミキシングアンプ１９で増幅されてスピーカ２０から出力される。また、ミキシングアンプ１９には利用者の歌唱音声を入力するためのマイクロフォン２１が接続されており、このマイクロフォン２１によって入力された音声信号もシンセサイザ１８からの楽音信号と共にスピーカ２０から出力される。
【００２８】
また、映像制御部２４には、ビデオＲＡＭ２２、映像再生装置２３および表示装置２５が接続されており、これらビデオＲＡＭ２２や映像再生装置２３から出力される映像信号と歌詞情報に基づき、歌詞を歌詞の背景映像にスーパーインポーズして出力し、表示装置２５に表示させる。
【００２９】
以上のような構成を有するカラオケ装置１では、操作パネル１４を介して入力、あるいはリモコン送信機１５から送信された選曲番号をリモコン受信機１６にて受信、という形で利用者からカラオケ演奏曲を選択するための選曲番号の入力がなされると、記憶装置１３から取得したカラオケ演奏用のデータを用いて、カラオケ演奏を実行する。そして、利用者が、表示装置２５に表示される歌詞を参照しながら、スピーカ２０より流れる演奏にあわせて、マイクロフォン２１を使って歌を歌うことができる、つまりカラオケを楽しむことができるようになっている。なお、上述のように、スレーブとして機能するカラオケ装置１は、公衆回線４０を介して配信用ホスト装置５０に接続する機能を有さないだけで他の構成は基本的にマスタとして機能するカラオケ装置１と同じであり、やはり記憶装置１３から取得したカラオケ演奏用のデータを用いてカラオケ演奏を実行する。
【００３０】
［配信用ホスト装置５０、監視装置６０の構成］
配信用ホスト装置５０は、図２に示すように、通信制御装置５１、中央処理装置５２及び記憶装置５３を備えている。通信制御装置５１は、公衆回線４０を介して多数のカラオケ装置１を接続し各種の情報を送受信したり、あるいは専用回線を介して監視装置６０と接続し各種の情報を送受信する。また、記憶装置５３は、カラオケ装置１へ配信するための配信データやカラオケ装置１からアップロードされた稼働ログ等を記憶するために用いられる。なお、記憶装置５３は例えばハードディスク等によって構成されており、配信データ蓄積用のハードディスクと稼働ログ蓄積用のハードディスクを別々に持つことも考えられる。そして、中央処理装置５２は、カラオケ装置１への配信制御やアップロード要求等を実行する。なお、中央処理装置５２は、ＣＰＵ，ＲＯＭ，ＲＡＭを備える周知の構成である。
【００３１】
一方、監視装置６０は、図２に示すように、通信制御装置６１、中央処理装置６２、記憶装置６３、表示制御部６４、表示装置６５、インターフェース（Ｉ／Ｆ）部６６、入力装置６７及びプリンタ６８を備えている。通信制御装置６１は、専用回線を介して配信用ホスト装置５０と接続し各種の情報を送受信する。中央処理装置６２は、配信用ホスト装置５０の記憶装置５３に記憶された稼働ログを解析して異常判断等を行い、その判断結果を表示制御部６４を介して表示装置６５へ表示させたり、あるいはＩ／Ｆ部６６を介してプリンタ６８に出力し、プリンタ６８にて印刷を実行させたりする。なお、これらの動作のための指示その他の操作入力は、入力装置６７を介してなされる。入力装置６７は例えばキーボード、マウス等である。
【００３２】
［カラオケ装置１の動作］
カラオケ端末１の動作についてを図４〜図７のフローチャートを参照しながら説明する。
電源が投入されると、図４に示すメインルーチンが実行開始される。
【００３３】
まず、最初のステップＳ１にて、通信制御装置１２のリセット等の装置全体の初期化を行う。次に、Ｓ２にて、カラオケ端末１の動作指定として、カラオケ演奏モードが指定されたか否かをチェックする。カラオケ装置１を設置した事業者（例えばカラオケ店舗の運営者）等によってカラオケ演奏モードの指定があればＳ３へ移行し、同指定がなければＳ４へ移行する。
【００３４】
Ｓ３では、カラオケ演奏処理を実行する。このカラオケ演奏処理の詳細は省略するが、稼働ログの書き込みに関連する部分のみ詳しく説明する。図５（ａ）は、カラオケ演奏中における稼働ログ書き込み例を示すフローチャートであり、カラオケ演奏処理中の選曲処理（Ｓ１０）において、上述のように操作パネル１４を介して入力、あるいはリモコン送信機１５から送信された選曲番号をリモコン受信機１６にて受信、という形で利用者から選曲番号の入力がなされると、記憶装置１３からカラオケ演奏用のデータを読み込む。その演奏用データの読み込みができた場合は（Ｓ２０：ＮＯ）、そのままカラオケ演奏を実行する。
【００３５】
一方、演奏用データの読み込みができなかった場合は（Ｓ２０：ＹＥＳ）、稼働ログ書き込みファンクションを実行する（Ｓ３０）。
このＳ３０にて実行される稼働ログ書き込みファンクションの詳細な内容を、図５（ｂ）のフローチャートを参照して説明する。
【００３６】
まず、通常ログレベル及び詳細ログレベルを取得する（Ｓ３１，Ｓ３２）。これら通常ログレベル及び詳細ログレベルは記憶装置１３に記憶されている。稼働ログにはログレベルが付与されており、この稼働ログがどのログレベルかを示すログテーブルが記憶装置１３に記憶されている点は上述した。演奏タスクのログテーブルの一部を示す図３を参照してさらに説明する。
【００３７】
図３に示すログテーブルは、ログ番号（ログＮＯ．）・ログレベル・ログ種別・発生場所及び記事からなっており。ここではログ種別がＥＲＲＯＲ（以上）の場合はログレベル１、ログ種別がＷＡＲ（警告）の場合はログレベル３、ログレベルがＮＯＲＭＡＬ（通常）の場合はログレベル５となっている。なお、ログレベル２，４についても存在する。このように本実施例ではログレベルが１〜５の５段階に分類されており、数字が少なくなるほど高レベルのログと考えている。つまり、ログレベル１が最も高レベルであり、ログレベル５が最も低レベルである。ここでいうレベルの高低は、異常を判断する上での高低であり、例えば図３に示すログレベル１の記事を見ると、「選演奏タスクステータス異常」「演奏管理テーブル異常」「＊＊＊＊ファイル読み込みエラー」というように異常そのものを示す内容である。なお、「＊＊＊＊ファイル読み込みエラー」における「＊＊＊＊」とは複数の対象の存在を想定している。例えば楽曲ファイルの読み込みエラーであったり映像ファイルの読み込みエラーであったりする。一方、ログレベル５の記事を見ると、「選曲キーが押された」「演奏停止キーが押された」といった通常の動作を示す内容である。但し、異常原因の解明には必要となる可能性があるため、異常を判断する上で全く関係ないわけではなく、レベルとしては低くしてある。
【００３８】
ここで、通常ログレベルは、定期的（例えば毎日とか１〜２週間おき）に配信用ホスト装置５０にアップロードする稼働ログのレベルを規定するものであり、例えば（ログレベル）３が付与される。なお、通常ログレベルが３ということは、それ以下のレベルの稼働ログ、つまりログレベル１，２，３の稼働ログが対象となる。一方、詳細ログレベルは、配信用ホスト装置５０から特別に詳細ログをアップロードせよという要求があった場合にのみアップロードするためのログレベルを規定するものであり、例えば（ログレベル）５が付与される。なお、詳細ログレベルが５ということは、それ以下のレベルの稼働ログ、つまりログレベル１，２，３，４，５（この場合は全てのログレベルが該当する）の稼働ログが対象となる。
【００３９】
なお、通常ログレベル及びログレベルは、カラオケ装置１を設置したときに設定してもよいし、配信用ホスト装置５０によって設定したり、あるいは設定されている値を変更するようにしてもよい。
次に、書き込みしようとしている稼働ログのレベルを、ログ番号（ログＮＯ．）から記憶装置１３に記憶されたログテーブルを参照し、取得する（Ｓ３３）。そして、書き込み（しようと）する稼働ログのログレベルがＳ３１にて取得した通常ログレベル以下か否かを判断する（Ｓ３４）。そして、通常ログレベル以下であれば（Ｓ３４：ＹＥＳ）、記憶装置１３内の通常ログ記憶領域１３ａのログファイル（通常ログファイル）に稼働ログを書き込む（Ｓ３５）。つまり、通常ログレベルを３とした場合には、ログレベル１，２，３の稼働ログであれば書き込まれ、ログレベル４，５の稼働ログは書き込まれない。
【００４０】
次に、書き込み（しようと）する稼働ログのログレベルがＳ３２にて取得した詳細ログレベル以下か否かを判断する（Ｓ３６）。そして、詳細ログレベル以下であれば（Ｓ３６：ＹＥＳ）、記憶装置１３内の詳細ログ記憶領域１３ｂのログファイル（詳細ログファイル）に書き込む（Ｓ３７）。つまり、詳細ログレベルを５とした場合には、全てのログレベル１〜５の稼働ログを書き込む。もちろん、詳細ログレベルは存在するログレベルの最低のもの（つまり、この場合は数字の最も大きな５）に設定しなくてはならないわけではなく、最低レベル以外のログレベルを詳細ログレベルとして設定した場合には、Ｓ３６にて否定判断となる場合も生じることとなる。
【００４１】
なお、Ｓ３５で通常ログファイルに書き込む稼働ログ及びＳ３７で詳細ログファイルに書き込む稼働ログ（詳細ログ）は、ログ番号（ログＮＯ．）・ログレベル・ログ種別・発生場所、発生日時及び記事からなっている。
ここでＳ３７における詳細ログファイルの書き込み処理について図６を参照して詳しく説明する。
【００４２】
なお、本実施例では、１個の詳細ログファイルには、稼働ログが１万レコード書き込まれる。また、詳細ログ記憶領域１３ｂに書き込み可能な稼働ログの総レコード数は１０万レコードである。この１個の詳細ログファイルに書き込み可能な稼働ログの設定レコード数や詳細ログ記憶領域１３ｂに書き込み可能な稼働ログの総レコード数は、任意に設定でき、この値に限定されるものではない。
【００４３】
まず、詳細ログ記憶領域１３ｂ内の詳細ログレコードの数が予め設定された総レコード数（１０万レコード）を超えたか否かを判断する（Ｓ３７１）。もしも総レコード数を超えている場合には（Ｓ３７１：ＹＥＳ）、詳細ログファイルのファイル情報を取得し（Ｓ３７２）、最も古い詳細ログファイルを詳細ログ記憶領域１３ｂ内から削除してから（Ｓ３７３）、Ｓ３７４へ移行する。このように、本実施例では、ファイル単位で稼働ログ（詳細ログ）を削除するので、ファイル管理が容易である。
【００４４】
一方、総レコード数を超えていない場合には（Ｓ３７１：ＮＯ）、Ｓ３７２，Ｓ３７３の処理は実行せずにＳ３７４へ移行する。
Ｓ３７４では、カレンダクロック２７（図１参照）から取り込んだ現在の日付を元にして、日付が変わっていないか否かを判断する。そして、日付が変わっていなければ（Ｓ３７４：ＹＥＳ）、最新のログファイルにおける詳細ログレコードの数が設定レコード数（上述のように１万レコード）を超えたか否かを判断する（Ｓ３７５）。もしも設定レコード数を超えている場合には（Ｓ３７５：ＹＥＳ）、日付＋シーケンシャル番号のファイル名を有するファイルを作成する（Ｓ３７６）。つまり、例えば、詳細ログファイルを作成する日付が2003.3.20であり、且つその日最初であれば、「LOG200303200001.DAT」というファイル名の詳細ログファイルを作成し、その後、１００００レコード書き込む毎に、「LOG200303200002.DAT」という風にファイル名を付して新たな詳細ログファイルを作成する。なお、最新の詳細ログファイルの１００００レコード書き込みが行われていなくても、新たな詳細ログファイルを作成する。
【００４５】
そして、詳細ログファイルのファイル名から最新の詳細ログファイルを開き（Ｓ３７７）、最新の詳細ログファイルの最終レコードまでシークする（Ｓ３７８）。そして、詳細ログファイルに詳細ログを書き込み（Ｓ３７９）、最新の詳細ログファイルを閉じた後（Ｓ３８０）、本処理を終了して図５（ｂ）の処理に戻る。
【００４６】
なお、Ｓ３７５にて否定判断、つまり最新のログファイルにおける詳細ログレコードの数が設定レコード数（１万レコード）を超えていない場合には、新規にファイルは作成せず、Ｓ３７７へ移行する。
また、Ｓ３７４にて否定判断、つまり、日付が変わっている場合には、Ｓ３７５の処理は実行せずにＳ３７６へ移行し、最新の詳細ログファイルの１００００レコード書き込みが行われていなくても、新たな詳細ログファイルを作成する。
【００４７】
図５（ｂ）のＳ３７の詳細ログファイル書き込み処理の内容は以上のようであった。つまり、詳細ログレコード数が設定レコード数を超える場合には古いものを削除して新規に書き込みを行っている。これに対して図５（ｂ）のＳ３５での通常ログファイルの書き込みの場合は、そのような通常ログファイルの削除といった対処をせずに、順次書き込んでいくだけである。
【００４８】
ここまでで図４のＳ３での処理説明まで終わったので、続いてＳ４の説明から再開する。なお、このＳ３はカラオケ演奏モードが解除されるまで利用客からのリクエスト待ちとカラオケ演奏の実行とを繰り返し行う。Ｓ３のステップは、カラオケ端末設置事業者によるカラオケ演奏モードの解除指定により終了し、Ｓ４へと移行する。
【００４９】
Ｓ４では、配信用ホスト装置５０からの接続要求が発生しているか否かをチェックする。発生していればＳ５へ移行し、そうでなければＳ２へ移行する。
Ｓ５では、配信用ホスト装置５０からの配信データ等を受信して記憶装置１３へセーブしたり、稼働ログを配信用ホスト装置５０へ送信したりする対応処理を行うためにサブルーチンをコールする。この対応処理を図７のフローチャートに基づいて説明する。
【００５０】
図７に示す対応処理の最初のステップＳ１１０では、配信用ホスト装置５０からの接続要求に応答して接続処理を行う。接続完了後、Ｓ１２０へ移行してデータ配信があるかどうかを判断する。もしデータ配信がある場合には（Ｓ１２：ＹＥＳ）、配信用ホスト装置５０からの配信データを受信し、その受信した配信データを記憶装置１３へセーブする（Ｓ１３０）。なお、上述した稼働ログの書き込みはカラオケ演奏の場合の一例を示しただけであり、例えばこのように配信データを受信した場合、その配信データを記憶装置１３へセーブした場合なども、その稼働ログが図５（ｂ）及び図６で説明した処理フローに従って、同様に記憶装置１３に書き込まれる。
【００５１】
一方、Ｓ１２０で否定判断、すなわちデータ配信がない場合には、Ｓ１３０の処理は実行せず、Ｓ１４０へ移行する。
Ｓ１４０では、配信用ホスト装置５０から詳細ログのアップロード要求がされているか否かを判断する。そして、アップロード要求がなければ（Ｓ１４０：ＮＯ）、記憶装置１３内の通常ログ記憶領域１３ａの通常ログファイルを配信用ホスト装置５０へ送信し（Ｓ１５０）、アップロード要求があれば（Ｓ１４０：ＹＥＳ）、記憶装置１３内の詳細ログ記憶領域１３ｂの詳細ログファイルを配信用ホスト装置５０へ送信する（Ｓ１６０）。また、このようなログファイルの送信を行った場合、その送信した通常ログファイル、詳細ログファイルについては、それぞれ通常ログ記憶領域１３ａ、詳細ログ記憶領域１３ｂから削除する（Ｓ１６０，Ｓ１８０）。なお、本実施例では、ログファイル自体を削除しているが、例えばログファイル自体は残っているが上書きしてもよい状態にすることで「削除可能な状態」にする対処であってもよい。要は、新規にログファイルを記憶させようとした場合に、従前のログファイルが存在することで記憶させることができないことを防げればよいからである。また、本実施例では、ログファイル単体で削除するようにしたが、稼働ログの１個のレコード単位で削除するようにしてもよい。
【００５２】
そして、このような配信データの受信・セーブやログファイルの送信処理が完了した後は、Ｓ１９０へ移行し、配信用ホスト装置５０との接続を解除する。同処理終了後、サブルーチンをリターンして、図４のフローチャートのＳ２のステップへ戻り、電源オフとされるまでの間、Ｓ２以下の処理を繰り返し実行する。
【００５３】
ここで図７のＳ１４０における詳細ログのアップロード要求について説明する。本実施例では、配信用ホスト装置５０が定期的に（例えば毎日所定の時刻になると）カラオケ装置１と接続し、例えば新曲データなど配信データがあればそれを送信する。そして、そのデータ配信の後、通常ログをカラオケ装置１からアップロードしてもらうようなシステムとして構築されている。もちろん、毎日配信データがあるとは限らないが、その場合であっても配信用ホスト装置５０はカラオケ装置１に毎日接続し、少なくとも通常ログはアップロードしてもらうようになっている。したがって、カラオケ装置１としては、毎日所定時刻に、配信データの受信＋通常ログのアップロードをするか、あるいは通常ログのアップロードをする。
【００５４】
そして、このようにアップロードされた通常ログファイルは配信用ホスト装置５０の記憶装置５３（図２参照）に蓄積されていく。監視装置６０（図２参照）は、専用回線を介して配信用ホスト装置５０と接続し、記憶装置５３に蓄積された通常ログを解析して異常判断等を行う。そして、その判断結果を表示制御部６４を介して表示装置６５に表示させたり、あるいはＩ／Ｆ部６６を介してプリンタ６８から印刷させたりする。なお、異常が発見された場合にのみ表示するようにしてもよい。このような表示を見たオペレータが例えば入力装置６７を介して操作することで、該当個所の通常ログファイルを配信用ホスト装置５０から読み出して表示装置６５に表示させ、その原因を調査する。通常ログファイルだけでは原因が不明な場合は詳細ログファイルも解析対象に加えるため、やはり、オペレータが例えば入力装置６７を介して操作することで、配信用ホスト装置５０から該当のカラオケ装置１に対して詳細ログのアップロード要求がなされることとなる。
【００５５】
なお、図５（ｂ）及び図６に示す処理等が稼働実績情報記憶制御手段としての処理の実行に相当し、図７のＳ１４０，Ｓ１５０，Ｓ１７０に示す処理がアップロード制御手段としての処理に相当する。
［本実施例の効果］
本実施例のカラオケ装置１では、ログレベルが３以下（レベル１，２，３）の稼働ログファイル（通常ログファイル）については通常ログ記憶領域１３ａに書き込み、配信用ホスト装置５０へ定期的に（例えば毎日）アップロードする。そして、アップロード後はその通常ログファイルは削除する。一方、全てのログレベル（レベル１〜５）の稼働ログファイル（詳細ログファイル）については詳細ログ記憶領域１３ｂに新しいものを優先して書き込み、配信用ホスト装置５０からの詳細ログのアップロード要求があればアップロードする。そして、アップロード後はその詳細ログファイルは削除する。
【００５６】
詳細ログファイルには、図３のログレベル５の記事に示すように、選曲キーが押されたといった、一般的には通常の動作を示すログもある。このような低レベルの稼働ログは、カラオケ装置の管理をするためには特別必要な情報ではないが、異常が発生した場合においては、これらの低レベルの稼働ログも合わせて判断することでより適切に原因を解明することができる。
【００５７】
しかしながら、このような詳細な稼働ログを恒常的に配信用ホスト装置５０にアップロードすることは、アップロードに要する通信コストの増大、通信時間の増大、配信用ホスト装置５０側での処理負荷の増大等を招来してしまう。特に、通信カラオケシステムの場合には、１台の配信用ホスト装置５０に対して各地に配置された膨大な数のカラオケ装置１がアップロードすることとなり、１台あたりのアップロードデータ量が増えると、、総量としては非常にデータ量が多くなり、処理負荷は相当なものとなる。
【００５８】
そこで、定期的にアップロードするのは通常ログファイルだけにし、配信用ホスト装置５０側で必要になった場合、つまり本実施例では監視装置６０からの指示があった限って配信用ホスト装置５０がカラオケ装置１に対して詳細ログのアップロード要求を出すようにした。これにより、上述の通信コスト・通信時間・ホスト装置側での処理負荷の増大等を防止できる。それでいて異常原因の解明のために必要な稼働ログもホスト装置側で容易に収集することができる。
【００５９】
但し、通常ログファイルについては定期的にアップロードされ、アップロード後はログファイルが削除（もしくは削除可能な状態とされる）ため問題ないが、詳細ログファイルのアップロード要求はいつあるか分からない。つまり、異常が発生しなければ相当長期間にわたってアップロードしない可能性もある。その場合に何ら対策を講じないと記憶装置１３の記憶領域を無制限に使ってしまうこととなる。そこで、本実施例では、図６を参照して説明したように、詳細ログを新規に記憶しようとした場合に詳細ログ記憶領域１３ｂの記憶容量を超える場合（本実施例では設定レコード数を判断基準としている）には、既に記憶されている古いログファイルを削除してから記憶するようにしている。このようにすることで、カラオケ装置１の記憶装置１３の記憶領域を無制限に使ってしまうことがなくなり、本来のサービスのために必要なカラオケ楽曲データ等の格納を妨げることがなくなる。
【００６０】
［その他の実施例］
（１）上記実施例では、配信用ホスト装置５０からの接続要求があって接続した後、通常ログをアップロードするようにしているが、例えばカラオケ装置１自らが、所定時刻になったことを判断して、自発的に配信用ホスト装置５０に接続要求を出し、接続した後に通常ログをアップロードしてもよい。もちろん、配信データの受信に関しては、カラオケ装置１側からアクセスしてもよよい。
【００６１】
（２）詳細ログファイルを複数種類に分類することも考えられる。例えばログレベルが１〜１０まで存在するような場合に、ログレベル５以下（１〜５）のログファイルを第１の詳細ログファイルとし、ログレベル１０以下（１〜１０）のログファイルを第２の詳細ログファイルとてそれぞれ第１の詳細ログ記憶領域、第２の詳細ログ記憶領域に記憶し、配信用ホスト装置５０から第１の詳細ログのアップロード要求があれば第１の詳細ログファイルをアップロードし、第２の詳細ログのアップロード要求があれば第２の詳細ログファイルをアップロードするようにしてもよい。なお、この場合は、第２の詳細ログファイルをアップロードした場合は、第１の詳細ログ記憶領域及び第２の詳細ログ記憶領域内のログファイルを両方共、削除する。つまり、より詳しい内容まで分かる第２の詳細ログファイルをアップロードした場合には、その中に第１の詳細ログファイルは全て含まれていることとなるため、あえて残しておく必要がないからである。逆に、第１の詳細ログファイルをアップロードした場合は、第１の詳細ログ記憶領域内のログファイルは削除してもよいが、第２の詳細ログファイルは残しておく必要があるため、第２の詳細ログ記憶領域内のログファイルは削除しない。
【００６２】
（３）上記実施例では、情報処理装置の一例としてカラオケ装置１を挙げたが、稼働ログをホスト装置にアップロードするシステムに用いられる情報処理装置であれば、どのようなものであっても同様に適用でき、同様の効果を得ることができる。
【図面の簡単な説明】
【図１】実施例のカラオケ装置の概略構成を示すブロック図である。
【図２】実施例の配信用ホスト装置及び監視装置の概略構成を示すブロック図である。
【図３】演奏タスクのログテーブルの一部を示す説明図である。
【図４】実施例のカラオケ装置にて実行されるメイン処理を示すフローチャートである。
【図５】（ａ）は図４のＳ３にて実行されるカラオケ曲演奏処理の一部を抜粋して示すフローチャート、（ｂ）は（ａ）のＳ３０にて実行される稼働ログ書き込みファンクションを示すフローチャートである。
【図６】図５（ｂ）のＳ３７にて実行される詳細ログの書き込み処理を示すフローチャートである。
【図７】図４のＳ５にて実行される対応処理を示すフローチャートである。
【符号の説明】
１…カラオケ装置、１０…ネットワークシステム、１１…中央処理装置、１２…通信制御装置、１３…記憶装置、１３ａ…通常ログ記憶領域、１３ｂ…詳細ログ記憶領域、１４…操作パネル、１５…リモコン送信機、１６…リモコン受信機、１７…操作制御部、１８…シンセサイザ、１９…ミキシングアンプ、２０…スピーカ、２１…マイクロフォン、２２…ビデオＲＡＭ、２３…映像再生装置、２４…映像制御部、２５…表示装置、２７…カレンダクロック、３０…店舗内ネットワーク、４０…公衆回線、５０…配信用ホスト装置、監視装置６０。

Claims (5)

1. ホスト装置との間で通信が可能であり、少なくとも稼働実績情報をそのホスト装置へアップロード可能な情報処理装置における稼働実績情報の処理方法であって、
   前記稼働実績情報については、その稼働内容を実績として収集する重要性の高低に応じた複数のレベルに分類されており、
   一定以上の高いレベルの稼働実績情報（以下、高レベル稼働実績情報と称す。）については、その全てを記憶し、定期的に前記ホスト装置へアップロードした後で削除、もしくは削除可能な状態とし、
   一方、相対的に低いレベルの稼働実績情報（以下、低レベル稼働実績情報と称す。）については、古い情報から削除することで一定以下の情報量となるようにしながら記憶し、前記ホスト装置から前記低レベル稼働実績情報のアップロード要求があった場合には前記ホスト装置へアップロードした後で削除、もしくは削除可能な状態とする
   稼働実績情報の処理方法。
2. 稼働実績情報を記憶するための記憶手段、
   少なくとも稼働実績情報をホスト装置へアップロード可能な通信手段、
   を備える情報処理装置であって、
   前記稼働実績情報については、その稼働内容を実績として収集する重要性の高低に応じた複数のレベルに分類されており、
   前記記憶手段は、一定以上の高いレベルの稼働実績情報（以下、高レベル稼働実績情報と称す。）を記憶する第一の記憶領域と、相対的に低いレベルの稼働実績情報（以下、低レベル稼働実績情報と称す。）を記憶する第二の記憶領域とを有し、
   さらに、
   前記高レベル実績情報については、その全てを前記第一の記憶領域に記憶しておき、前記ホスト装置へのアップロード後は前記第一の記憶領域から前記高レベル実績情報を削除し、一方、前記低レベル稼働実績情報については、新規情報を記憶しようとした場合に前記第二の記憶領域の記憶容量を超えるのであれば、既に記憶されている古い情報を削除してから記憶し、前記ホスト装置へのアップロード後は前記第一の記憶領域から前記高レベル実績情報を削除、もしくは削除可能な状態とする稼働実績情報記憶制御手段、
   前記第一の記憶領域に記憶された前記高レベル実績情報については定期的に、一方、前記第二の記憶領域に記憶された前記低レベル稼働実績情報については前記ホスト装置から前記低レベル稼働実績情報のアップロード要求があった場合に、それぞれ前記通信手段を介して前記ホスト装置へアップロードするアップロード制御手段、
   を備える情報処理装置。
3. 請求項２に記載の情報処理装置において、
   前記アップロード制御手段は、前記第一の記憶領域に記憶された前記高レベル実績情報については、前記ホスト装置から定期的に出されるアップロード要求に応じてアップロードする
   情報処理装置。
4. 請求項２に記載の情報処理装置において、
   前記アップロード制御手段は、前記第一の記憶領域に記憶された前記高レベル実績情報については、予め定められた時刻になった場合には自動的にアップロードする
   情報処理装置。
5. 請求項２〜４の何れかに記載の情報処理装置における前記稼働実績情報記憶制御手段及び前記アップロード制御手段としてコンピュータを機能させるためのプログラム。

Images