JP4096772B2 - 稼働実績情報処理方法、情報処理装置及びプログラム - Google Patents
稼働実績情報処理方法、情報処理装置及びプログラム Download PDFInfo
- Publication number
- JP4096772B2 JP4096772B2 JP2003078103A JP2003078103A JP4096772B2 JP 4096772 B2 JP4096772 B2 JP 4096772B2 JP 2003078103 A JP2003078103 A JP 2003078103A JP 2003078103 A JP2003078103 A JP 2003078103A JP 4096772 B2 JP4096772 B2 JP 4096772B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- level
- log
- operation result
- host device
- 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
Landscapes
- Reverberation, Karaoke And Other Acoustics (AREA)
Description
【発明の属する技術分野】
本発明は、情報処理装置からホスト装置へアップロードする稼働実績情報の処理技術に関する。
【0002】
【従来の技術】
従来、例えばいわゆる通信カラオケシステムの場合、カラオケ装置(端末)の多くは、利用者からの指定によってさまざまな楽曲の再生やコンテンツの再生を行っており、通信カラオケシステムの運営者は、利用者にいち早く新曲が歌えるよう定期的にカラオケ装置とホスト装置を電話回線やISDN回線などの通信回線を介して接続して楽曲データの更新やゲーム等のコンテンツ、新しい機能の実装のためのプログラム配信を行っている。このようなコンテンツ等はカラオケ装置内のハードディスク等の記憶メディアに記録されるが、そのハードディスク等の記憶メディアは長時間稼働していることから故障する可能性があり、またプログラムの不具合により稼働に支障を来す場合も考えられる。
【0003】
そのため、カラオケ装置からホスト装置へ稼働実績情報をアップロードし、ホスト装置において、その収集した稼働実績情報を解析して異常を検知した場合、その異常を管理者に通知する対策が考えられている(例えば、特許文献1参照。)。
【0004】
【特許文献1】
特開2000−242864号公報
【0005】
【解決しようとする課題】
このような稼動実績情報は、故障や不具合が発生した場合の早期発見や原因の早期解明の観点からすれば、できるだけ詳細なログを記録しておくことが望まれる。しかしながら、カラオケ装置の場合であればハードディスクは本来曲データ等のコンテンツを記憶するものであって記憶容量にも限りがある、また、各地に設置されたカラオケ装置からの稼働実績情報の集信時間や通信コストのことを考慮すると、全てのカラオケ装置から詳細な稼働実績情報を収集するのは現実的に困難であり、結局、異常が発生した場合の原因の究明に困難を来していた。
【0006】
そこで本発明は、適切な稼働実績情報をアップロードできるようにする技術を提案することを目的とする。
【0007】
【課題を解決するための手段及び発明の効果】
(イ)上述した問題点を解決するためになされた請求項1に係る発明は、ホスト装置との間で通信が可能であり、少なくとも稼働実績情報をそのホスト装置へアップロード可能な情報処理装置における稼働実績情報の処理方法であって、稼働実績情報については、その稼働内容を実績として収集する重要性の高低に応じた複数のレベルに分類されており、高レベル稼働実績情報については、その全てを記憶し、定期的に前記ホスト装置へアップロードした後で削除、もしくは削除可能な状態とし、一方、低レベル稼働実績情報については、古い情報から削除することで一定以下の情報量となるようにしながら記憶し、ホスト装置から低レベル稼働実績情報のアップロード要求があった場合にはホスト装置へアップロードした後で削除、もしくは削除可能な状態とする稼働実績情報の処理方法である。
【0008】
このような稼働実績情報の処理方法を実行する情報処理装置としては、例えば請求項2に示す構成を採用することが考えられる。つまり、請求項2に係る情報処理装置は、稼働実績情報を記憶するための記憶手段、少なくとも稼働実績情報をホスト装置へアップロード可能な通信手段を備えている。そして、稼働実績情報については、その稼働内容を実績として収集する重要性の高低に応じた複数のレベルに分類されており、記憶手段は、高レベル稼働実績情報を記憶する第一の記憶領域と、低レベル稼働実績情報を記憶する第二の記憶領域とを有している。
【0009】
そして、稼働実績情報記憶制御手段が次のような制御を実行する。つまり、高レベル実績情報については、その全てを第一の記憶領域に記憶しておき、ホスト装置へのアップロード後は第一の記憶領域から高レベル実績情報を削除、もしくは削除可能な状態とする。一方、低レベル稼働実績情報については、新規情報を記憶しようとした場合に第二の記憶領域の記憶容量を超えるのであれば、既に記憶されている古い情報を削除してから記憶し、ホスト装置へのアップロード後は第一の記憶領域から高レベル実績情報を削除、もしくは削除可能な状態とする。また、アップロード制御手段が次のような制御を実行する。つまり、第一の記憶領域に記憶された高レベル実績情報については定期的に、一方、第二の記憶領域に記憶された低レベル稼働実績情報については前記ホスト装置から低レベル稼働実績情報のアップロード要求があった場合に、それぞれ通信手段を介してホスト装置へアップロードする。
【0010】
なお、「稼働実績情報を削除、もしくは削除可能な状態とする」とは、稼働実績情報を記憶手段から文字通り削除してもよいし、あるいは稼働実績情報自体は記憶手段に残っているが上書きしてもよい状態にすることを意味する。要は、新規に情報を記憶させようとした場合に、従前の稼働実績情報が存在することで記憶させることができないことを防ぐ目的であるため、情報自体が存在しなければ当然問題ない、また情報は存在しても、新規な情報を既存の情報上に上書きできるのであれば何ら問題ないからである。具体的には、削除してもよい情報であることを示す識別情報を付与したり、記憶手段上の削除しても良い情報が記憶されているエリアを管理することで、それらが上書き対象の情報であることを判断できるようにしておけばよい。
【0011】
本発明による作用効果への理解を容易にするため、例えば通信カラオケシステムに用いられるカラオケ装置を情報処理装置の例として考えてみる。例えば稼働実績情報(以下、稼働ログとも称す。)について、その重要度等に基づいて1〜5の5段階のレベルを付与する。例えば明らかに異常を示す稼働ログについては最高レベルの1とし、例えば選曲キーが押された場合などの通常の操作を示す稼働ログについては最低レベルの5とする、といった具合である。
【0012】
ここで、カラオケ装置はホスト装置へ定期的に(例えば毎日とか1〜2週間おき)アップロードするとし、その場合のアップロードする稼働ログはレベル3以上(レベル3,2,1)とする。その場合は、これらレベル3以上の稼働ログを第一の記憶領域に記憶しておき、定期的にアップロードする。
【0013】
一方、第二の記憶領域には、例えば全ての稼働ログ(5,4,3,2,1)について記憶しておき、ホスト装置からの特別なアップロード要求があった場合に限ってアップロードする。具体的には、上述した定期的にアップロードする稼働ログをホスト装置側にてチェックした結果、異常の原因をさらに解明したい場合などにこのアップロード要求がなされる。つまり、上述例で言えば、選曲キーが押されたという稼働ログは、一般的には通常の動作を示してはいるが、何か異常が発生した場合には、このような低レベルの稼働ログ(つまり、詳細な稼働ログ)も合わせて判断することでより適切に原因を解明することができる。
【0014】
しかしながら、このような詳細な稼働ログが必要になるの何らかの異常が発見された場合であり、恒常的にこのような詳細な稼働ログをアップロードすることは、アップロードに要する通信コストの増大、通信時間の増大、ホスト装置側での処理負荷の増大等を招来してしまう。特に、現状の通信カラオケシステムであっても1台のホスト装置にアップロードするカラオケ装置の数は膨大であり、これら各カラオケ装置からアップロードされる稼働ログが多いと、総量としては非常にデータ量が多くなり、処理負荷は相当なものとなる。
【0015】
そこで、定期的にアップロードするのは高レベルの稼働ログだけにし、ホスト装置側で必要になった場合に限って低レベルの(つまり詳細な)稼働ログをアップロードするようホスト装置からカラオケ装置へ要求することで、上述の通信コスト・通信時間・ホスト装置側での処理負荷の増大等を防止できる。それでいて異常原因の解明のために必要な稼働ログもホスト装置側で容易に収集することができるのである。
【0016】
但し、高レベルの稼働ログについては定期的にアップロードされ、アップロード後は稼働ログのデータが削除、もしくは削除可能な状態とされるため問題ないが、低レベルの稼働ログのアップロード要求はいつあるか分からないため、何ら対策を講じないと記憶手段(例えばハードディスク)の記憶領域を無制限に使ってしまうこととなる。そこで、本発明では、上述のように、低レベル稼働実績情報を新規に記憶しようとした場合に第二の記憶領域の記憶容量を超えるのであれば、既に記憶されている古い情報を削除してから記憶するようにしている。このようにすることで、カラオケ装置側の記憶手段の記憶領域を無制限に使ってしまうことがなくなり、例えば本来のサービスのために必要なカラオケ楽曲データ等の格納を妨げることがなくなる。そして、例えば高レベルの稼働ログに基づいて異常があると判断され、その原因を解明するために低レベルの稼働ログのアップロード要求があった場合、実際に必要な低レベルの稼働ログとしては、異常を発見した高レベルの稼働ログに対応する範囲のものである。例えば高レベルの稼働ログについて毎日アップロードとしているのであれば、その日1日分程度の範囲で低レベルの稼働ログについてもあればよいこととなる。したがって、そのような範囲の稼働ログが記憶できる記憶領域としておけば原因解明には寄与でき、さらにアップロードするデータ量も過大になることがないため、上述した通信コスト・通信時間・ホスト装置側での処理負荷の増大等の防止の観点でさらによい。
【0017】
このように本発明では、適切なタイミングで適切な稼働実績情報をアップロードできるようになる。
(ロ)なお、アップロード制御手段が第一の記憶領域に記憶された高レベル実績情報をホスト装置へアップロードする場合には、ホスト装置から定期的に出されるアップロード要求に応じてアップロードしてもよいし(請求項3)、予め定められた時刻になった場合に自動的にアップロードするようにしてもよい(請求項4)。
【0018】
(ハ)また、請求項2〜4の何れかに記載の情報処理装置における稼働実績情報記憶制御手段及びアップロード制御手段をコンピュータにて実現する場合、例えばコンピュータで実行するプログラムとして備えることができる。このようなプログラムは、例えばフレキシブルディスク、光磁気ディスク、CD−ROM、ハードディスク、ROM、RAM等のコンピュータ読み取り可能な記録媒体に記録し、必要に応じてコンピュータにロードして実行したり、ネットワークを介してロードして実行することにより、情報処理装置としての機能を実現できる。
【0019】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうる。
【0020】
図1は、実施例のカラオケ装置1の概略構成を示している。本実施例のカラオケ装置1は、カラオケ店舗に設置されており、例えばカラオケ店舗の各部屋にそれぞれ1台ずつ設置される。なお、これら複数台のカラオケ装置1は店舗内ネットワーク30にて接続されている。そして、これら複数台のカラオケ装置1の内、何れか一つ(以上)のカラオケ装置1は、公衆回線を介して配信用ホスト装置50に接続できるようになっており、この公衆回線40を介して接続した配信用ホスト装置50からカラオケに関する配信データ(音楽情報や画像情報、あるいは例えばカラオケ演奏処理を実行するためのアプリケーションプログラム(カラオケ演奏プログラム)等)を取得して、例えばハードディスク等の記憶装置13へ記憶しておくことができる。そして、カラオケ装置1は、記憶装置13に記憶されている配信データを、店舗内ネットワーク30によって接続された他のカラオケ装置1へ送信することができる。そのため、公衆回線40を介して配信用ホスト装置50と接続する機能を持つカラオケ装置1がマスタ(親機)となり、他のカラオケ装置1がスレーブ(子機)となっている。
【0021】
また、マスタは自装置の稼働実績情報(稼働ログ)、及び店舗内ネットワーク30を介してスレーブから受け取った稼働ログを、公衆回線40を介して配信用ホスト装置50へアップロードできるように構成されている。図2に示すように、配信用ホスト装置50は、多数のカラオケ装置1(この場合はマスタを意味する。)と接続可能となっており、これら多数のカラオケ装置1に対して配信データを送信したり、逆にアップロードされた稼働ログを受信する。配信用ホスト装置50及び図2に示した監視装置60については、後述する。
【0022】
[カラオケ装置1の説明]
マスタまたはスレーブとして機能するカラオケ装置1の基本的な構成はいずれも同じであるが、上述のように、マスタのみが公衆回線40を介して配信用ホスト装置50に接続できるようになっている。それ以外の機能は基本的にいずれも同じである。したがって、以下の構成説明に関しては、図1に示す(マスタとして機能する)カラオケ装置1に関して行うこととする。
【0023】
カラオケ装置1は、図1に示すように、カラオケ装置1を制御するための中央処理装置11、ネットワークとしての店舗内ネットワーク30を介して他のカラオケ装置(この場合はスレーブ)と接続したり、公衆回線40を介して配信用ホスト装置50と接続し、各種の情報を送受信する通信制御装置12、各種データ等を記憶している記憶装置13、曲の予約や電源のON・OFFなどを行うための操作パネル14、操作パネル14と同様に曲の予約等を行うためのリモコン送信機15、リモコン送信機15からの信号を受信するためのリモコン受信機16、操作パネル14やリモコン受信機16からの信号を受け付けて処理する操作制御部17、演奏の再生を行うシンセサイザ18、音楽情報にかかる電気信号を増幅等するミキシングアンプ19、ミキシングアンプ19からの電気信号を入力して伴奏曲及び利用者の歌声等を流すスピーカ20、利用者の歌声等をミキシングアンプ19に入力するマイクロフォン21、中央処理装置11によって生成された歌詞情報を記憶するビデオRAM22、画像情報等を映像化する映像再生装置23、ビデオRAM22からの歌詞情報や映像再生装置23からの映像信号に基づき、歌詞及び歌詞の背景映像を出力する映像制御部24、映像制御部24から出力された歌詞及び歌詞の背景映像を表示する表示装置25、現在の日付や日時を常にカウントしていて中央処理装置11に通知するカレンダクロック27を備えている。また、このうちの中央処理装置11には、通信制御装置12、ハードディスク13、操作制御部17、シンセサイザ18、ビデオRAM22、映像再生装置23、映像制御部24及びカレンダクロック27が接続されており、中央処理装置11は、これらを介してカラオケ装置1を制御する。
【0024】
続いて各部の具体的な構成を説明する。
[中央処理装置11および記憶装置13の構成]
まず、中央処理装置11は、CPU、ROM、RAMなどを備える周知の構成である。一方、記憶装置13は、例えばハードディスク等から構成されており、中央処理装置11がカラオケ装置1を制御するための各種プログラム、カラオケ演奏用のデータ等を記憶している。また、この記憶装置13にはカラオケ装置1における稼働実績情報(稼働ログ)も記憶されるのであるが、図1に示すように、通常ログ記憶領域13aと詳細ログ記憶領域13bが準備されており、後述する通常ログ、詳細ログがそれぞれこれら通常ログ記憶領域13a、詳細ログ記憶領域13bに記憶される。また、これら稼働ログにはログレベルが付与されているのであるが、この稼働ログがどのログレベルかを示すログテーブルもこの記憶装置13に記憶されている。図3は、演奏タスクのログテーブルの一部を示している。
【0025】
なお、カラオケ装置1の中央処理装置11は、稼働実績情報記憶制御手段及びアップロード制御手段に相当する。
[通信制御装置12の構成]
通信制御装置12は、店舗内ネットワーク30を介してカラオケ店舗内の他の部屋に設置されたカラオケ装置(この場合はスレーブ)に接続されており、これら他のカラオケ装置(この場合はスレーブ)との間で各種の情報を送受信する。また、カラオケ装置1の通信制御装置12は、上述したように、公衆回線40を介して配信用ホスト装置50と接続し、この配信用ホスト装置50との間で各種の情報を送受信する。
【0026】
[操作制御部17、操作パネル14、リモコン送受信機15,16の構成]
操作制御部17には、操作パネル14およびリモコン受信機16が接続されている。このうち、操作パネル14は、利用者がカラオケ曲の選択や演奏アレンジの切り替えを行ったりするためのものであり、図2(a)にその外観を模式的に示すように、各種操作ボタンや選曲番号等の表示のためのLED等を備えている。なお、この操作パネル14は装置本体の正面側に設けられており、「HMI部」に相当する。利用者がこの操作パネル14を操作すると、その入力操作の信号が操作制御部17および中央処理装置11に送られて処理される。一方、リモコン受信機16は、リモコン送信機15からの信号を受信するためのものである。また、このリモコン送信機15は、操作パネル14と同様に、利用者がカラオケ曲の選択や演奏アレンジの切り替えを行ったりするためのものである。利用者がこのリモコン送信機15を操作すると、その入力操作の信号がリモコン受信機16を介して操作制御部17および中央処理装置11に送られて処理される。
【0027】
[その他の構成]
また、シンセサイザ18には、ミキシングアンプ19が接続され、このミキシングアンプ19にはスピーカ20が接続されている。ハードディスク13等から読み出され、中央処理装置11から供給される音楽情報(MIDI形式のカラオケ演奏データ)に基づいてシンセサイザ18から出力される楽音信号はミキシングアンプ19で増幅されてスピーカ20から出力される。また、ミキシングアンプ19には利用者の歌唱音声を入力するためのマイクロフォン21が接続されており、このマイクロフォン21によって入力された音声信号もシンセサイザ18からの楽音信号と共にスピーカ20から出力される。
【0028】
また、映像制御部24には、ビデオRAM22、映像再生装置23および表示装置25が接続されており、これらビデオRAM22や映像再生装置23から出力される映像信号と歌詞情報に基づき、歌詞を歌詞の背景映像にスーパーインポーズして出力し、表示装置25に表示させる。
【0029】
以上のような構成を有するカラオケ装置1では、操作パネル14を介して入力、あるいはリモコン送信機15から送信された選曲番号をリモコン受信機16にて受信、という形で利用者からカラオケ演奏曲を選択するための選曲番号の入力がなされると、記憶装置13から取得したカラオケ演奏用のデータを用いて、カラオケ演奏を実行する。そして、利用者が、表示装置25に表示される歌詞を参照しながら、スピーカ20より流れる演奏にあわせて、マイクロフォン21を使って歌を歌うことができる、つまりカラオケを楽しむことができるようになっている。なお、上述のように、スレーブとして機能するカラオケ装置1は、公衆回線40を介して配信用ホスト装置50に接続する機能を有さないだけで他の構成は基本的にマスタとして機能するカラオケ装置1と同じであり、やはり記憶装置13から取得したカラオケ演奏用のデータを用いてカラオケ演奏を実行する。
【0030】
[配信用ホスト装置50、監視装置60の構成]
配信用ホスト装置50は、図2に示すように、通信制御装置51、中央処理装置52及び記憶装置53を備えている。通信制御装置51は、公衆回線40を介して多数のカラオケ装置1を接続し各種の情報を送受信したり、あるいは専用回線を介して監視装置60と接続し各種の情報を送受信する。また、記憶装置53は、カラオケ装置1へ配信するための配信データやカラオケ装置1からアップロードされた稼働ログ等を記憶するために用いられる。なお、記憶装置53は例えばハードディスク等によって構成されており、配信データ蓄積用のハードディスクと稼働ログ蓄積用のハードディスクを別々に持つことも考えられる。そして、中央処理装置52は、カラオケ装置1への配信制御やアップロード要求等を実行する。なお、中央処理装置52は、CPU,ROM,RAMを備える周知の構成である。
【0031】
一方、監視装置60は、図2に示すように、通信制御装置61、中央処理装置62、記憶装置63、表示制御部64、表示装置65、インターフェース(I/F)部66、入力装置67及びプリンタ68を備えている。通信制御装置61は、専用回線を介して配信用ホスト装置50と接続し各種の情報を送受信する。中央処理装置62は、配信用ホスト装置50の記憶装置53に記憶された稼働ログを解析して異常判断等を行い、その判断結果を表示制御部64を介して表示装置65へ表示させたり、あるいはI/F部66を介してプリンタ68に出力し、プリンタ68にて印刷を実行させたりする。なお、これらの動作のための指示その他の操作入力は、入力装置67を介してなされる。入力装置67は例えばキーボード、マウス等である。
【0032】
[カラオケ装置1の動作]
カラオケ端末1の動作についてを図4〜図7のフローチャートを参照しながら説明する。
電源が投入されると、図4に示すメインルーチンが実行開始される。
【0033】
まず、最初のステップS1にて、通信制御装置12のリセット等の装置全体の初期化を行う。次に、S2にて、カラオケ端末1の動作指定として、カラオケ演奏モードが指定されたか否かをチェックする。カラオケ装置1を設置した事業者(例えばカラオケ店舗の運営者)等によってカラオケ演奏モードの指定があればS3へ移行し、同指定がなければS4へ移行する。
【0034】
S3では、カラオケ演奏処理を実行する。このカラオケ演奏処理の詳細は省略するが、稼働ログの書き込みに関連する部分のみ詳しく説明する。図5(a)は、カラオケ演奏中における稼働ログ書き込み例を示すフローチャートであり、カラオケ演奏処理中の選曲処理(S10)において、上述のように操作パネル14を介して入力、あるいはリモコン送信機15から送信された選曲番号をリモコン受信機16にて受信、という形で利用者から選曲番号の入力がなされると、記憶装置13からカラオケ演奏用のデータを読み込む。その演奏用データの読み込みができた場合は(S20:NO)、そのままカラオケ演奏を実行する。
【0035】
一方、演奏用データの読み込みができなかった場合は(S20:YES)、稼働ログ書き込みファンクションを実行する(S30)。
このS30にて実行される稼働ログ書き込みファンクションの詳細な内容を、図5(b)のフローチャートを参照して説明する。
【0036】
まず、通常ログレベル及び詳細ログレベルを取得する(S31,S32)。これら通常ログレベル及び詳細ログレベルは記憶装置13に記憶されている。稼働ログにはログレベルが付与されており、この稼働ログがどのログレベルかを示すログテーブルが記憶装置13に記憶されている点は上述した。演奏タスクのログテーブルの一部を示す図3を参照してさらに説明する。
【0037】
図3に示すログテーブルは、ログ番号(ログNO.)・ログレベル・ログ種別・発生場所及び記事からなっており。ここではログ種別がERROR(以上)の場合はログレベル1、ログ種別がWAR(警告)の場合はログレベル3、ログレベルがNORMAL(通常)の場合はログレベル5となっている。なお、ログレベル2,4についても存在する。このように本実施例ではログレベルが1〜5の5段階に分類されており、数字が少なくなるほど高レベルのログと考えている。つまり、ログレベル1が最も高レベルであり、ログレベル5が最も低レベルである。ここでいうレベルの高低は、異常を判断する上での高低であり、例えば図3に示すログレベル1の記事を見ると、「選演奏タスクステータス異常」「演奏管理テーブル異常」「****ファイル読み込みエラー」というように異常そのものを示す内容である。なお、「****ファイル読み込みエラー」における「****」とは複数の対象の存在を想定している。例えば楽曲ファイルの読み込みエラーであったり映像ファイルの読み込みエラーであったりする。一方、ログレベル5の記事を見ると、「選曲キーが押された」「演奏停止キーが押された」といった通常の動作を示す内容である。但し、異常原因の解明には必要となる可能性があるため、異常を判断する上で全く関係ないわけではなく、レベルとしては低くしてある。
【0038】
ここで、通常ログレベルは、定期的(例えば毎日とか1〜2週間おき)に配信用ホスト装置50にアップロードする稼働ログのレベルを規定するものであり、例えば(ログレベル)3が付与される。なお、通常ログレベルが3ということは、それ以下のレベルの稼働ログ、つまりログレベル1,2,3の稼働ログが対象となる。一方、詳細ログレベルは、配信用ホスト装置50から特別に詳細ログをアップロードせよという要求があった場合にのみアップロードするためのログレベルを規定するものであり、例えば(ログレベル)5が付与される。なお、詳細ログレベルが5ということは、それ以下のレベルの稼働ログ、つまりログレベル1,2,3,4,5(この場合は全てのログレベルが該当する)の稼働ログが対象となる。
【0039】
なお、通常ログレベル及びログレベルは、カラオケ装置1を設置したときに設定してもよいし、配信用ホスト装置50によって設定したり、あるいは設定されている値を変更するようにしてもよい。
次に、書き込みしようとしている稼働ログのレベルを、ログ番号(ログNO.)から記憶装置13に記憶されたログテーブルを参照し、取得する(S33)。そして、書き込み(しようと)する稼働ログのログレベルがS31にて取得した通常ログレベル以下か否かを判断する(S34)。そして、通常ログレベル以下であれば(S34:YES)、記憶装置13内の通常ログ記憶領域13aのログファイル(通常ログファイル)に稼働ログを書き込む(S35)。つまり、通常ログレベルを3とした場合には、ログレベル1,2,3の稼働ログであれば書き込まれ、ログレベル4,5の稼働ログは書き込まれない。
【0040】
次に、書き込み(しようと)する稼働ログのログレベルがS32にて取得した詳細ログレベル以下か否かを判断する(S36)。そして、詳細ログレベル以下であれば(S36:YES)、記憶装置13内の詳細ログ記憶領域13bのログファイル(詳細ログファイル)に書き込む(S37)。つまり、詳細ログレベルを5とした場合には、全てのログレベル1〜5の稼働ログを書き込む。もちろん、詳細ログレベルは存在するログレベルの最低のもの(つまり、この場合は数字の最も大きな5)に設定しなくてはならないわけではなく、最低レベル以外のログレベルを詳細ログレベルとして設定した場合には、S36にて否定判断となる場合も生じることとなる。
【0041】
なお、S35で通常ログファイルに書き込む稼働ログ及びS37で詳細ログファイルに書き込む稼働ログ(詳細ログ)は、ログ番号(ログNO.)・ログレベル・ログ種別・発生場所、発生日時及び記事からなっている。
ここでS37における詳細ログファイルの書き込み処理について図6を参照して詳しく説明する。
【0042】
なお、本実施例では、1個の詳細ログファイルには、稼働ログが1万レコード書き込まれる。また、詳細ログ記憶領域13bに書き込み可能な稼働ログの総レコード数は10万レコードである。この1個の詳細ログファイルに書き込み可能な稼働ログの設定レコード数や詳細ログ記憶領域13bに書き込み可能な稼働ログの総レコード数は、任意に設定でき、この値に限定されるものではない。
【0043】
まず、詳細ログ記憶領域13b内の詳細ログレコードの数が予め設定された総レコード数(10万レコード)を超えたか否かを判断する(S371)。もしも総レコード数を超えている場合には(S371:YES)、詳細ログファイルのファイル情報を取得し(S372)、最も古い詳細ログファイルを詳細ログ記憶領域13b内から削除してから(S373)、S374へ移行する。このように、本実施例では、ファイル単位で稼働ログ(詳細ログ)を削除するので、ファイル管理が容易である。
【0044】
一方、総レコード数を超えていない場合には(S371:NO)、S372,S373の処理は実行せずにS374へ移行する。
S374では、カレンダクロック27(図1参照)から取り込んだ現在の日付を元にして、日付が変わっていないか否かを判断する。そして、日付が変わっていなければ(S374:YES)、最新のログファイルにおける詳細ログレコードの数が設定レコード数(上述のように1万レコード)を超えたか否かを判断する(S375)。もしも設定レコード数を超えている場合には(S375:YES)、日付+シーケンシャル番号のファイル名を有するファイルを作成する(S376)。つまり、例えば、詳細ログファイルを作成する日付が2003.3.20であり、且つその日最初であれば、「LOG200303200001.DAT」というファイル名の詳細ログファイルを作成し、その後、10000レコード書き込む毎に、「LOG200303200002.DAT」という風にファイル名を付して新たな詳細ログファイルを作成する。なお、最新の詳細ログファイルの10000レコード書き込みが行われていなくても、新たな詳細ログファイルを作成する。
【0045】
そして、詳細ログファイルのファイル名から最新の詳細ログファイルを開き(S377)、最新の詳細ログファイルの最終レコードまでシークする(S378)。そして、詳細ログファイルに詳細ログを書き込み(S379)、最新の詳細ログファイルを閉じた後(S380)、本処理を終了して図5(b)の処理に戻る。
【0046】
なお、S375にて否定判断、つまり最新のログファイルにおける詳細ログレコードの数が設定レコード数(1万レコード)を超えていない場合には、新規にファイルは作成せず、S377へ移行する。
また、S374にて否定判断、つまり、日付が変わっている場合には、S375の処理は実行せずにS376へ移行し、最新の詳細ログファイルの10000レコード書き込みが行われていなくても、新たな詳細ログファイルを作成する。
【0047】
図5(b)のS37の詳細ログファイル書き込み処理の内容は以上のようであった。つまり、詳細ログレコード数が設定レコード数を超える場合には古いものを削除して新規に書き込みを行っている。これに対して図5(b)のS35での通常ログファイルの書き込みの場合は、そのような通常ログファイルの削除といった対処をせずに、順次書き込んでいくだけである。
【0048】
ここまでで図4のS3での処理説明まで終わったので、続いてS4の説明から再開する。なお、このS3はカラオケ演奏モードが解除されるまで利用客からのリクエスト待ちとカラオケ演奏の実行とを繰り返し行う。S3のステップは、カラオケ端末設置事業者によるカラオケ演奏モードの解除指定により終了し、S4へと移行する。
【0049】
S4では、配信用ホスト装置50からの接続要求が発生しているか否かをチェックする。発生していればS5へ移行し、そうでなければS2へ移行する。
S5では、配信用ホスト装置50からの配信データ等を受信して記憶装置13へセーブしたり、稼働ログを配信用ホスト装置50へ送信したりする対応処理を行うためにサブルーチンをコールする。この対応処理を図7のフローチャートに基づいて説明する。
【0050】
図7に示す対応処理の最初のステップS110では、配信用ホスト装置50からの接続要求に応答して接続処理を行う。接続完了後、S120へ移行してデータ配信があるかどうかを判断する。もしデータ配信がある場合には(S12:YES)、配信用ホスト装置50からの配信データを受信し、その受信した配信データを記憶装置13へセーブする(S130)。なお、上述した稼働ログの書き込みはカラオケ演奏の場合の一例を示しただけであり、例えばこのように配信データを受信した場合、その配信データを記憶装置13へセーブした場合なども、その稼働ログが図5(b)及び図6で説明した処理フローに従って、同様に記憶装置13に書き込まれる。
【0051】
一方、S120で否定判断、すなわちデータ配信がない場合には、S130の処理は実行せず、S140へ移行する。
S140では、配信用ホスト装置50から詳細ログのアップロード要求がされているか否かを判断する。そして、アップロード要求がなければ(S140:NO)、記憶装置13内の通常ログ記憶領域13aの通常ログファイルを配信用ホスト装置50へ送信し(S150)、アップロード要求があれば(S140:YES)、記憶装置13内の詳細ログ記憶領域13bの詳細ログファイルを配信用ホスト装置50へ送信する(S160)。また、このようなログファイルの送信を行った場合、その送信した通常ログファイル、詳細ログファイルについては、それぞれ通常ログ記憶領域13a、詳細ログ記憶領域13bから削除する(S160,S180)。なお、本実施例では、ログファイル自体を削除しているが、例えばログファイル自体は残っているが上書きしてもよい状態にすることで「削除可能な状態」にする対処であってもよい。要は、新規にログファイルを記憶させようとした場合に、従前のログファイルが存在することで記憶させることができないことを防げればよいからである。また、本実施例では、ログファイル単体で削除するようにしたが、稼働ログの1個のレコード単位で削除するようにしてもよい。
【0052】
そして、このような配信データの受信・セーブやログファイルの送信処理が完了した後は、S190へ移行し、配信用ホスト装置50との接続を解除する。同処理終了後、サブルーチンをリターンして、図4のフローチャートのS2のステップへ戻り、電源オフとされるまでの間、S2以下の処理を繰り返し実行する。
【0053】
ここで図7のS140における詳細ログのアップロード要求について説明する。本実施例では、配信用ホスト装置50が定期的に(例えば毎日所定の時刻になると)カラオケ装置1と接続し、例えば新曲データなど配信データがあればそれを送信する。そして、そのデータ配信の後、通常ログをカラオケ装置1からアップロードしてもらうようなシステムとして構築されている。もちろん、毎日配信データがあるとは限らないが、その場合であっても配信用ホスト装置50はカラオケ装置1に毎日接続し、少なくとも通常ログはアップロードしてもらうようになっている。したがって、カラオケ装置1としては、毎日所定時刻に、配信データの受信+通常ログのアップロードをするか、あるいは通常ログのアップロードをする。
【0054】
そして、このようにアップロードされた通常ログファイルは配信用ホスト装置50の記憶装置53(図2参照)に蓄積されていく。監視装置60(図2参照)は、専用回線を介して配信用ホスト装置50と接続し、記憶装置53に蓄積された通常ログを解析して異常判断等を行う。そして、その判断結果を表示制御部64を介して表示装置65に表示させたり、あるいはI/F部66を介してプリンタ68から印刷させたりする。なお、異常が発見された場合にのみ表示するようにしてもよい。このような表示を見たオペレータが例えば入力装置67を介して操作することで、該当個所の通常ログファイルを配信用ホスト装置50から読み出して表示装置65に表示させ、その原因を調査する。通常ログファイルだけでは原因が不明な場合は詳細ログファイルも解析対象に加えるため、やはり、オペレータが例えば入力装置67を介して操作することで、配信用ホスト装置50から該当のカラオケ装置1に対して詳細ログのアップロード要求がなされることとなる。
【0055】
なお、図5(b)及び図6に示す処理等が稼働実績情報記憶制御手段としての処理の実行に相当し、図7のS140,S150,S170に示す処理がアップロード制御手段としての処理に相当する。
[本実施例の効果]
本実施例のカラオケ装置1では、ログレベルが3以下(レベル1,2,3)の稼働ログファイル(通常ログファイル)については通常ログ記憶領域13aに書き込み、配信用ホスト装置50へ定期的に(例えば毎日)アップロードする。そして、アップロード後はその通常ログファイルは削除する。一方、全てのログレベル(レベル1〜5)の稼働ログファイル(詳細ログファイル)については詳細ログ記憶領域13bに新しいものを優先して書き込み、配信用ホスト装置50からの詳細ログのアップロード要求があればアップロードする。そして、アップロード後はその詳細ログファイルは削除する。
【0056】
詳細ログファイルには、図3のログレベル5の記事に示すように、選曲キーが押されたといった、一般的には通常の動作を示すログもある。このような低レベルの稼働ログは、カラオケ装置の管理をするためには特別必要な情報ではないが、異常が発生した場合においては、これらの低レベルの稼働ログも合わせて判断することでより適切に原因を解明することができる。
【0057】
しかしながら、このような詳細な稼働ログを恒常的に配信用ホスト装置50にアップロードすることは、アップロードに要する通信コストの増大、通信時間の増大、配信用ホスト装置50側での処理負荷の増大等を招来してしまう。特に、通信カラオケシステムの場合には、1台の配信用ホスト装置50に対して各地に配置された膨大な数のカラオケ装置1がアップロードすることとなり、1台あたりのアップロードデータ量が増えると、、総量としては非常にデータ量が多くなり、処理負荷は相当なものとなる。
【0058】
そこで、定期的にアップロードするのは通常ログファイルだけにし、配信用ホスト装置50側で必要になった場合、つまり本実施例では監視装置60からの指示があった限って配信用ホスト装置50がカラオケ装置1に対して詳細ログのアップロード要求を出すようにした。これにより、上述の通信コスト・通信時間・ホスト装置側での処理負荷の増大等を防止できる。それでいて異常原因の解明のために必要な稼働ログもホスト装置側で容易に収集することができる。
【0059】
但し、通常ログファイルについては定期的にアップロードされ、アップロード後はログファイルが削除(もしくは削除可能な状態とされる)ため問題ないが、詳細ログファイルのアップロード要求はいつあるか分からない。つまり、異常が発生しなければ相当長期間にわたってアップロードしない可能性もある。その場合に何ら対策を講じないと記憶装置13の記憶領域を無制限に使ってしまうこととなる。そこで、本実施例では、図6を参照して説明したように、詳細ログを新規に記憶しようとした場合に詳細ログ記憶領域13bの記憶容量を超える場合(本実施例では設定レコード数を判断基準としている)には、既に記憶されている古いログファイルを削除してから記憶するようにしている。このようにすることで、カラオケ装置1の記憶装置13の記憶領域を無制限に使ってしまうことがなくなり、本来のサービスのために必要なカラオケ楽曲データ等の格納を妨げることがなくなる。
【0060】
[その他の実施例]
(1)上記実施例では、配信用ホスト装置50からの接続要求があって接続した後、通常ログをアップロードするようにしているが、例えばカラオケ装置1自らが、所定時刻になったことを判断して、自発的に配信用ホスト装置50に接続要求を出し、接続した後に通常ログをアップロードしてもよい。もちろん、配信データの受信に関しては、カラオケ装置1側からアクセスしてもよよい。
【0061】
(2)詳細ログファイルを複数種類に分類することも考えられる。例えばログレベルが1〜10まで存在するような場合に、ログレベル5以下(1〜5)のログファイルを第1の詳細ログファイルとし、ログレベル10以下(1〜10)のログファイルを第2の詳細ログファイルとてそれぞれ第1の詳細ログ記憶領域、第2の詳細ログ記憶領域に記憶し、配信用ホスト装置50から第1の詳細ログのアップロード要求があれば第1の詳細ログファイルをアップロードし、第2の詳細ログのアップロード要求があれば第2の詳細ログファイルをアップロードするようにしてもよい。なお、この場合は、第2の詳細ログファイルをアップロードした場合は、第1の詳細ログ記憶領域及び第2の詳細ログ記憶領域内のログファイルを両方共、削除する。つまり、より詳しい内容まで分かる第2の詳細ログファイルをアップロードした場合には、その中に第1の詳細ログファイルは全て含まれていることとなるため、あえて残しておく必要がないからである。逆に、第1の詳細ログファイルをアップロードした場合は、第1の詳細ログ記憶領域内のログファイルは削除してもよいが、第2の詳細ログファイルは残しておく必要があるため、第2の詳細ログ記憶領域内のログファイルは削除しない。
【0062】
(3)上記実施例では、情報処理装置の一例としてカラオケ装置1を挙げたが、稼働ログをホスト装置にアップロードするシステムに用いられる情報処理装置であれば、どのようなものであっても同様に適用でき、同様の効果を得ることができる。
【図面の簡単な説明】
【図1】実施例のカラオケ装置の概略構成を示すブロック図である。
【図2】実施例の配信用ホスト装置及び監視装置の概略構成を示すブロック図である。
【図3】演奏タスクのログテーブルの一部を示す説明図である。
【図4】実施例のカラオケ装置にて実行されるメイン処理を示すフローチャートである。
【図5】(a)は図4のS3にて実行されるカラオケ曲演奏処理の一部を抜粋して示すフローチャート、(b)は(a)のS30にて実行される稼働ログ書き込みファンクションを示すフローチャートである。
【図6】図5(b)のS37にて実行される詳細ログの書き込み処理を示すフローチャートである。
【図7】図4のS5にて実行される対応処理を示すフローチャートである。
【符号の説明】
1…カラオケ装置、10…ネットワークシステム、11…中央処理装置、12…通信制御装置、13…記憶装置、13a…通常ログ記憶領域、13b…詳細ログ記憶領域、14…操作パネル、15…リモコン送信機、16…リモコン受信機、17…操作制御部、18…シンセサイザ、19…ミキシングアンプ、20…スピーカ、21…マイクロフォン、22…ビデオRAM、23…映像再生装置、24…映像制御部、25…表示装置、27…カレンダクロック、30…店舗内ネットワーク、40…公衆回線、50…配信用ホスト装置、監視装置60。
Claims (5)
- ホスト装置との間で通信が可能であり、少なくとも稼働実績情報をそのホスト装置へアップロード可能な情報処理装置における稼働実績情報の処理方法であって、
前記稼働実績情報については、その稼働内容を実績として収集する重要性の高低に応じた複数のレベルに分類されており、
一定以上の高いレベルの稼働実績情報(以下、高レベル稼働実績情報と称す。)については、その全てを記憶し、定期的に前記ホスト装置へアップロードした後で削除、もしくは削除可能な状態とし、
一方、相対的に低いレベルの稼働実績情報(以下、低レベル稼働実績情報と称す。)については、古い情報から削除することで一定以下の情報量となるようにしながら記憶し、前記ホスト装置から前記低レベル稼働実績情報のアップロード要求があった場合には前記ホスト装置へアップロードした後で削除、もしくは削除可能な状態とする
稼働実績情報の処理方法。 - 稼働実績情報を記憶するための記憶手段、
少なくとも稼働実績情報をホスト装置へアップロード可能な通信手段、
を備える情報処理装置であって、
前記稼働実績情報については、その稼働内容を実績として収集する重要性の高低に応じた複数のレベルに分類されており、
前記記憶手段は、一定以上の高いレベルの稼働実績情報(以下、高レベル稼働実績情報と称す。)を記憶する第一の記憶領域と、相対的に低いレベルの稼働実績情報(以下、低レベル稼働実績情報と称す。)を記憶する第二の記憶領域とを有し、
さらに、
前記高レベル実績情報については、その全てを前記第一の記憶領域に記憶しておき、前記ホスト装置へのアップロード後は前記第一の記憶領域から前記高レベル実績情報を削除し、一方、前記低レベル稼働実績情報については、新規情報を記憶しようとした場合に前記第二の記憶領域の記憶容量を超えるのであれば、既に記憶されている古い情報を削除してから記憶し、前記ホスト装置へのアップロード後は前記第一の記憶領域から前記高レベル実績情報を削除、もしくは削除可能な状態とする稼働実績情報記憶制御手段、
前記第一の記憶領域に記憶された前記高レベル実績情報については定期的に、一方、前記第二の記憶領域に記憶された前記低レベル稼働実績情報については前記ホスト装置から前記低レベル稼働実績情報のアップロード要求があった場合に、それぞれ前記通信手段を介して前記ホスト装置へアップロードするアップロード制御手段、
を備える情報処理装置。 - 請求項2に記載の情報処理装置において、
前記アップロード制御手段は、前記第一の記憶領域に記憶された前記高レベル実績情報については、前記ホスト装置から定期的に出されるアップロード要求に応じてアップロードする
情報処理装置。 - 請求項2に記載の情報処理装置において、
前記アップロード制御手段は、前記第一の記憶領域に記憶された前記高レベル実績情報については、予め定められた時刻になった場合には自動的にアップロードする
情報処理装置。 - 請求項2〜4の何れかに記載の情報処理装置における前記稼働実績情報記憶制御手段及び前記アップロード制御手段としてコンピュータを機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003078103A JP4096772B2 (ja) | 2003-03-20 | 2003-03-20 | 稼働実績情報処理方法、情報処理装置及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003078103A JP4096772B2 (ja) | 2003-03-20 | 2003-03-20 | 稼働実績情報処理方法、情報処理装置及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004287018A JP2004287018A (ja) | 2004-10-14 |
JP4096772B2 true JP4096772B2 (ja) | 2008-06-04 |
Family
ID=33292682
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003078103A Expired - Lifetime JP4096772B2 (ja) | 2003-03-20 | 2003-03-20 | 稼働実績情報処理方法、情報処理装置及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4096772B2 (ja) |
-
2003
- 2003-03-20 JP JP2003078103A patent/JP4096772B2/ja not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
JP2004287018A (ja) | 2004-10-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101046953B (zh) | 音乐处理设备及其管理方法 | |
JP2861855B2 (ja) | 通信カラオケシステム | |
JP2000315215A (ja) | コンテンツ配信装置及び方法 | |
JPH09127964A (ja) | 通信カラオケ装置のダウンロード管理方法および通信カラオケシステム | |
CN100382046C (zh) | 记录及重现装置、信息传送及管理方法以及记录介质 | |
EP1693850A1 (en) | Data processing method, reproduction apparatus and information processing apparatus | |
US20020085456A1 (en) | Music piece data managing apparatus and in-vehicle audio information reproduction control system | |
JP2007293312A (ja) | 音楽処理装置 | |
JP4096772B2 (ja) | 稼働実績情報処理方法、情報処理装置及びプログラム | |
CN101320580B (zh) | 数据录制器 | |
JP4178605B2 (ja) | カラオケ装置およびカラオケ装置の操作再現システム | |
JP4299947B2 (ja) | 通信カラオケシステム | |
JP4134691B2 (ja) | 情報複製方法、ネットワークシステム及び情報処理装置 | |
JP4186760B2 (ja) | コンピュータシステム、通信カラオケシステム、プログラム | |
JP5545770B2 (ja) | 電話システム、電話端末、及び電話システムの制御方法 | |
JP4957324B2 (ja) | 音楽処理装置 | |
JP3892513B2 (ja) | 通信式カラオケシステム | |
JP4935879B2 (ja) | カラオケネットワークシステム | |
JP4100174B2 (ja) | 音楽記録再生装置及び方法 | |
JP3717237B2 (ja) | 通信期限警告を行うカラオケ端末装置 | |
JPH09311690A (ja) | 通信型楽曲演奏装置およびシステム | |
JP2002182668A (ja) | カラオケ録音装置およびその使用方法 | |
JPH10240271A (ja) | カラオケ装置の保守装置 | |
JP2005056245A (ja) | ファイルアクセス管理方法、ファイルアクセス管理システム、プログラム | |
JPH10254734A (ja) | 稼働実績情報の作成方法及び端末装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060303 |
|
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: 20080219 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080303 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 4096772 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110321 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120321 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120321 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130321 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130321 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140321 Year of fee payment: 6 |
|
EXPY | Cancellation because of completion of term |