JP2004151362A - 情報処理装置及びネットワークシステム - Google Patents

Abstract

【課題】ハードディスク等の情報記憶手段内の処理実行用情報が振動や電源の瞬断等によって破損した場合に、その破損した情報を検知する。
【解決手段】ハードディスクには（ａ）に示すように配信ファイル及び各配信ファイルのＣＲＣ値が関連付けされて格納されており、例えば１日１回電源投入時や所定時刻などにおいて、その格納されている配信データをＲＡＭに読み出しＣＲＣ値を算出する。その算出したＣＲＣ値が（ｂ）に示すようになったとすると、（ａ）に示すＣＲＣ値と異なるものを抽出して（ｃ）に示す再配信要求リストを作成する。そして、親機であれば、その再配信要求リスト内にある全ての配信データに関し、該当する配信データの再配信要求をホストコンピュータへ送信する。そして再配信された配信データ及びＣＲＣ値を受信して、それらを再度ハードディスクに格納する。一方、子機であれば親機から再配信してもらう。
【選択図】図４

Description

【０００１】
【発明の属する技術分野】
本発明は、情報処理装置が持つハードディスク等の情報記憶手段に格納された処理実行用情報が振動や電源の瞬断等によって破損した場合、その情報破損を検出するための技術に関する。
【０００２】
【従来の技術】
従来の通信カラオケシステム、即ち、配信用のホスト装置と複数のカラオケ装置が電話回線を介して通信を行うことによって楽音データ等の配信データを取得し、カラオケ装置は利用者からのリクエストにより楽音データを再生して演奏を行うシステムにおいて、通信費の削減及びリクエストに対するレスポンス等の問題から各カラオケ装置にハードディスク等の記憶装置を設け、一旦取得した配信データは当該記憶装置に記憶しておき、演奏の際には記憶装置からリクエストに対応した楽音データを読み出し再生する構成が知られている（例えば、特許文献１参照）。
【０００３】
また、上記のような構成の通信カラオケシステムでは、例えばある店舗において複数のカラオケルームが存在する場合、各カラオケルームに設置してあるカラオケ装置それぞれが電話回線と接続されており、各カラオケ装置が配信用のホスト装置と通信を行い配信データを取得する構成となる。この場合、データの配信をカラオケ装置毎に受信するため、カラオケ装置の台数分だけ電話料金がかかるという問題があった。これらの問題を解決するため、近年ではある店舗に設置された複数のカラオケ装置の内、少なくとも１つのカラオケ装置に電話回線を接続し、該カラオケ装置は上記同様に配信用のホスト装置より配信データを受信するが、その他の複数のカラオケ装置は、ＬＡＮ等の回線を介して、配信データを受信しているカラオケ装置からデータを受信する構成となっている（例えば、特許文献２参照）。
【０００４】
【特許文献１】
特開平８−４４３７９号公報
【特許文献２】
特開平１０−１８７１７６号公報
【０００５】
【発明が解決しようとする課題】
楽音データ等の配信データを受信した各カラオケ装置がその配信データを蓄積するために使用しているハードディスク等の記憶装置は、例えば振動や電源の瞬断等に弱く、記憶しているデータの破損を起こす可能性がある。楽音データが破損し、該当する曲が利用者よりリクエストされた場合には、歌えなくなったり演奏時に異常な音声が出力されたりするため、その対処としては、システムの提供者が早急に正常なハードディスクと交換するのが一般的である。
【０００６】
しかしながら、上記対処方法の場合、一旦破損したデータはシステムの提供者がハードディスクを交換するまで該当する曲が正常に演奏されないため、カラオケ利用者が不満を感じるといった問題がある。また、そのデータが破損していても実際に演奏等によりそのデータを使用しなければ破損したデータが分からないという問題があった。したがって、カラオケ利用者に対して適切でないサービスを提供してしまうこととなる。
【０００７】
なお、このような問題はカラオケ装置に限らず、ユーザからの要求等があった場合に、ハードディスク等の情報記憶手段に記憶している処理実行用情報を用いて処理を実行する装置であれば同様に生じ得る。
そこで本発明は、このような問題点を鑑み、通信によって外部装置から情報を取得可能な情報処理装置において、当該装置が持つハードディスク等の情報記憶手段内の処理実行用情報が振動や電源の瞬断等によって破損した場合に、その破損した処理実行用情報を検知することを第１の目的とする。そして、検知後の適切な対処も実行することを第２の目的とする。
【０００８】
【課題を解決するための手段及び発明の効果】
（１）請求項１に係る情報処理装置によれば、情報記憶手段が情報処理を実行するために用いるデータを記憶しており、エラー検出情報受信手段は、その情報記憶手段に記憶されている処理実行用情報に対するエラー検出を行うためのエラー検出情報を、外部装置から受信する。また、エラー検出情報記憶手段は、エラー検出情報受信手段によって受信したエラー検出情報を、対応する処理実行用情報と関連付けて記憶する。そして、比較情報算出手段は、エラー検出情報記憶手段に記憶されているエラー検出情報と比較するために、情報記憶手段に記憶されている、対応する処理実行用情報の比較情報を算出し、破損情報検出手段が、比較情報算出手段により算出された比較情報とエラー検出情報記憶手段に記憶されているエラー検出情報とを比較し、破損している処理実行用情報を検出する。
【０００９】
情報処理装置としては、通信カラオケ装置、音楽再生装置、情報提供装置、ゲーム装置などが考えられるが、例えば通信カラオケ装置を想定すれば、処理実行用情報は、例えば外部のホスト装置から配信されたカラオケ演奏用のデータであったり、当該カラオケ演奏処理をコンピュータに実行させるためのいわゆるアプリケーションプログラムであることが考えられる。なお、このエラー検出対象となる処理実行用情報は外部から配信を受け、情報記憶手段に記憶されたものでもよいし、予め情報記憶手段に記憶されたものであってもよい。
【００１０】
いずれにしても、通信によって情報を取得可能な情報処理装置において、当該装置が持つハードディスク等の情報記憶手段内の処理実行用情報が振動や電源の瞬断等によって破損した場合に、その破損した処理実行用情報を検知することができる。したがって、その検知結果に基づいて後述のデータ修復など適切な対処が可能となる。
【００１１】
（２）エラー検出の対象となる処理実行用情報は、情報記憶手段が記憶している全てのデータでなくてもよい。例えば請求項２に示すように、情報記憶手段に記憶されている処理実行用情報に対応してエラー検出の必要性の有無を記憶しておき、エラー検出の必要性が有ると記憶されている処理実行用情報に対してのみ、エラー検出を実行するようにしてもよい。
【００１２】
例えばカラオケ装置であれば、音楽情報の方が画像情報より重要である。つまり、画像情報は多少違和感があったとしてもカラオケを楽しむ上で特に問題にならないが、音楽情報の場合には、音飛び等が発生するだけで違和感が大きく、カラオケというサービス内容の品質低下を招く。このようにエラー検出の必要性は音楽情報が相対的に高いと言える。したがって、画像情報についてはエラー検出せず、音楽情報についてのみエラー検出することが考えられる。一般的に、画像情報のデータ量が楽音情報に比べて相当大きいため、検査のための処理負荷低減の観点でも有利である。
【００１３】
なお、例えばカラオケ演奏をするためのアプリケーションプログラムが破損している場合には、たとえ音楽情報等が正常であっても、カラオケ演奏処理自体が正常に実行されない。したがって、このようなアプリケーションプログラムをよりエラー検出の必要性が高い情報であるとすることも考えられる。さらには、いわゆる通信カラオケ装置であって、新譜曲の配信を受けるために自ら配信用のホスト装置へアクセスするシステムとなっている場合、そのアクセスするための情報（例えば電話番号等）がデータ破損によってエラーとなってしまうと問題となる。したがって、このようなアクセス用情報についてもエラー検出の必要性を高くしておくことが考えられる。
【００１４】
また、推定される使用頻度に応じた対応も考えられる。例えば、カラオケ装置であれば、新譜曲や歌われた回数の多い曲については、今後も利用される可能性が高いため、相対的にエラー検出の必要性が高いと考えられる。したがって、新譜曲や歌われた回数の多い曲については音楽情報だけでなく画像情報についてもエラー検出することも有効な対処である。また、過去に歌われた回数が多いということは、その曲に関する情報を情報記憶手段から読み出す機会が増えるということであり、それは情報読み出し時における各種原因でデータ破損が生じる可能性がより高いと言える。したがって、このような処理実行用情報に対してエラー検出を行うことは有効である。
【００１５】
（３）上述のように、処理実行用情報によってエラー検出を実行するかしないかを分けてもよいが、エラー検出の対象となっている場合であっても、処理実行用情報の内容に応じてエラー検出の実行頻度を変えても良い。例えば、請求項３に示すように、エラー検出の必要性が高いほどエラー検出に係る処理の実行頻度を高くするのである。例えば、カラオケ装置の場合であれば、カラオケ曲として利用される頻度が高いと思われる曲については、検査頻度を高くする。例えば新譜曲や歌われた回数の多い曲については、今後も利用される可能性が高いため、検査を充実した方が好ましいと考えられるからである。また、上述したように、歌われた回数が多いということは、その曲データをリードする機会が増えるということであり、それはリード時における各種原因でデータ破損が生じる可能性も多いため、その意味でも検査頻度を上げることは有効である。なお、このようにエラー検出の実行頻度を変える場合は、エラー検出対象となっている処理実行用情報に対応したエラー検出の必要性の高低をエラー検出必要度記憶手段に記憶しておき、そこに記憶されたエラー検出の必要性が高いほど、比較情報算出手段及び破損データ検出手段によるエラー検出に係る処理の実行頻度を高くすればよい。エラー検出の必要性の高低についての情報は、データ配信を実行する側で配信データに対応して設定してもよいし、情報処理装置側において、当該装置を管理する者が任意に設定したり、あるいは所定の処理を実行することで自動的に設定することが考えられる。
【００１６】
（４）データ破損を検出した場合の対処としては、請求項４に示すように人が認識可能なように報知することが考えられる。報知する場合には、音声でもよいがディスプレイ等に表示して人の視覚に訴える方が好ましい。
また、請求項５に示すように第２の外部装置から取得することが考えられる。例えばいわゆる通信カラオケシステムの場合であれば、この第２の外部装置は配信ホスト装置とすることが考えられる。
【００１７】
（５）なお、「エラー検出情報を送信可能な第１の外部装置」については、第２の外部装置とは別個の装置であってもよいが、請求項６に示すように同一の装置であってもよい。その場合は第２の通信手段も第１の通信手段と同一となる。また、例えばカラオケ店舗内においては、複数台のカラオケ装置がＬＡＮによって接続されており、その内の１台が配信用のホスト装置からカラオケデータの配信を受け、その配信されたカラオケデータを他のカラオケ装置に送信するようなシステムを構成している場合がある。そのようなカラオケシステムであれば、配信用のホスト装置からカラオケデータの配信を受けるカラオケ装置を第１の外部装置や第２の外部装置として機能させたりすることもできる。したがって、このようなカラオケシステムとして適用するものとしては、請求項７に示すようなネットワークが考えられる。もちろん、カラオケシステムだけでなく、複数の情報処理装置がデータ送受信可能に接続されたネットワークシステムであれば、同様に適用可能である。
【００１８】
なお、請求項２に関する説明において、例えば通信カラオケ装置であって、新譜曲の配信を受けるために自らホスト装置へアクセスするシステムとなっている場合、そのアクセスするための情報（例えば電話番号等）についてもエラー検出の必要性を高くしておくことが考えられる点を述べた。この場合、そのアクセス用情報にエラーが発生している場合、ホスト装置を第１の外部装置としてエラー検出用情報を送信してもらうことは不可能となる。したがって、このようなアクセス用情報についてのエラー検出情報を送信する第１の外部装置は、ネットワークシステム内の別のカラオケ装置が担当すればよい。
【００１９】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。
【００２０】
図１は、本実施例のネットワークシステムの構成を示すブロック図である。本実施例では、情報処理装置としての複数のカラオケ装置１ａ，１ｂ，１ｃ…がローカル・エリア・ネットワーク（ＬＡＮ）３０に接続されてカラオケシステムを構成している。基本的な構成はどのカラオケ装置も同じであるが、カラオケ装置１ａのみが通信ネットワーク３を介してホストコンピュータ２に接続できるようになっている。そして、カラオケ装置１ａは、この通信ネットワーク３を介して接続したホストコンピュータ２からカラオケに関する配信データ（処理実行用情報としての音楽情報や画像情報等）を取得して、情報記憶手段としてのハードディスク１３へ記憶しておくことができる。さらに、カラオケ装置１ａは、この配信データ同様、ホストコンピュータ２より各配信データに対してのエラー検出情報であるＣＲＣ値を取得してハードディスク１３に記憶しておくことができる。
【００２１】
そして、カラオケ装置１ａは、ＬＡＮ３０（例えばＥｔｈｅｒｎｅｔ（登録商標）ケーブル）によってカラオケ装置１ｂ，１ｃ…と互いに通信することが可能であるため、カラオケ装置１ａは、ハードディスク１３に記憶されている配信データ及びそれに対応したエラー検出情報であるＣＲＣ値を他のカラオケ装置１ｂ，１ｃ…に送信することや、逆にホストコンピュータ２ではなく、他のカラオケ装置１ｂ，１ｃ…から配信データ及びＣＲＣ値を取得してハードディスク１３に記憶することも可能である。
【００２２】
なお、ホスト装置としてのホストコンピュータ２は、公衆電話回線等の通信ネットワーク３を介してカラオケ装置１ａとアクセス可能であって、カラオケ装置１ａに対して、最新の流行曲等の曲データを発信したり、どのような曲が何回演奏されたかといったログデータを含む関連情報をカラオケ装置１ａから受信したりして管理することができるようになっている。なお、この場合の「どのような曲が何回演奏されたかといったログデータ」については、カラオケ装置１ａ単体でのログデータではなく、カラオケシステム全体のログデータを指す。つまり、他のカラオケ装置１ｂ，１ｃ…におけるログデータもカラオケ装置１ａに集められ、カラオケシステム全体のログデータが、カラオケ装置１ａからホストコンピュータ２へ送信される。
【００２３】
また、ホストコンピュータ２は、カラオケ装置１ａに配信するための曲データ等の配信データ及び各配信データに対応したＣＲＣ値を図示しない記憶手段としてのハードディスクに記憶しており、通信ネットワーク３を介してカラオケ装置１ａからの再配信要求を受信すると、該当する配信データ及びＣＲＣ値をハードディスクより読み出してカラオケ装置１ａに送信することができるようになっている。
【００２４】
次に、カラオケ装置１ａの構成について説明する。
このカラオケ装置１ａには、図１に示されるように、ホストコンピュータ２に通信ネットワーク３を介して接続し各種の情報を送受信する通信装置１９、曲の予約などを行う操作パネル１０、カラオケ装置１ａ全体の制御を司るＣＰＵ１４、各種情報を一時的に記憶するＲＡＭ１５、演奏の再生を行う音源再生装置１８、音楽情報にかかる電気信号を増幅等するアンプ２０、アンプ２０からの電気信号を入力して伴奏曲及び利用者の歌声等を流すスピーカ２２、利用者の歌声等をアンプ２０に入力するためのマイクロフォン（以下、単にマイクと称す。）２３、ＥＥＰＲＯＭ１２、カラオケ用の音楽情報や画像情報その他各種情報を記憶しているハードディスク１３、画像情報等を映像化するための映像再生装置２４、画像情報である背景画及び歌詞等を表示する表示装置２６、およびＬＡＮ３０に接続するためのネットワークインターフェース１７を備えている。この内、操作パネル１０、ＥＥＰＲＯＭ１２、ハードディスク１３、ＲＡＭ１５、ネットワークインターフェース１７、音源再生装置１８及び映像再生装置２４は、ＣＰＵ１４に接続されている。
【００２５】
なお、他のカラオケ装置１ｂ，１ｃ…は通信装置１９を備えないだけで、他の構成は備えているため、ここではカラオケ装置１ａのみの説明をし、他のカラオケ装置１ｂ，１ｃ…の構成についての説明は省略する。
上述した通信装置１９は、信号の変調および復調を行う変復調装置であり、ＣＰＵ１４の制御の下、通信ネットワーク３を通じてホストコンピュータ２にアクセス可能に構成されている。それによって、通信装置１９は、通信ネットワーク３を介してホストコンピュータ２から送られてくる曲データ等を受信したり、上記関連情報をホストコンピュータ２に伝送することができる。
【００２６】
また、操作パネル１０は、利用者によって操作されるものであり、任意の曲の選択、演奏音のキーの調整、演奏と歌との音量バランスの調整、その他エコー、音量、トーンなど各種調整を行うため操作部と例えば選択された曲番号等を表示するための表示部（図示せず）を備えている。利用者は、その操作部を操作することによって、再生する曲をカラオケ装置１ａに予約登録することができる。
【００２７】
また、ＥＥＰＲＯＭ１２にはシステムプログラムや各種の設定に必要な設定データなどが記憶されている。
また、ハードディスク１３には、処理実行用情報としての音楽情報や画像情報、ＣＰＵ１４にカラオケ演奏を実行処理させるための、プログラムとしての演奏プログラムなどの配信データ及び各配信データに対応したＣＲＣ値、あるいは演奏記録などのログデータなどが記憶されている。そして、操作パネル１０の操作部を介して曲が選択されると、ＣＰＵ１４は、歌詞データ、映像データからなる画像情報、および演奏データからなる音楽情報をハードディスク１３から呼び出して、映像再生装置２４および音源再生装置１８に同期させて出力するようになっている。なお、ハードディスク１３には、識別情報としての曲番号に対応して演奏データや歌詞データ等が記憶されている。
【００２８】
その後、ＣＰＵ１４から出力される演奏データは、音源再生装置１８において、アナログの演奏音信号に変換された後、アンプ２０へ送られて電気的に増幅される。このアンプ２０は、マイク２３を介して入力される利用者（歌唱者）の歌唱音信号と適度な割合でミキシングするもので、ミキシングされた歌唱音信号と演奏音信号は、アンプ２０からスピーカ２２に出力され、音声及び演奏音となってスピーカ２２から外部へ出力される。
【００２９】
一方、映像再生装置２４は、ＣＰＵ１４の制御の下、ハードディスク１３から読み出された画像情報に基づく画像の再生を行うものである。それにより、ＣＰＵ１４により出力される歌詞データは、映像再生装置２４において映像データと合成され、表示装置２６の画面に背景映像とともに歌詞テロップが表示されるようになっている。
【００３０】
このような構成のため、利用者は、表示装置２６に表示される歌詞テロップを参照しながら、スピーカ２２より流れるカラオケ演奏にあわせ、マイク２３を使って歌唱できるようになっている。
上述のように、カラオケ装置１ａと他のカラオケ装置１ｂ，１ｃ…とは通信装置１９を備えるか否かの違いがあるが、通信装置１９を備えるカラオケ装置１ａは、ホストコンピュータ２から配信データ及びＣＲＣ値を受信して自らの有するハードディスク１３にそれらを記憶すると共に、そのハードディスク１３に記憶されている配信データ及びそＣＲＣ値を他のカラオケ装置１ｂ，１ｃ…に送信することができるように構成されている。そこで、この通信装置１９を備えるカラオケ装置１ａを「親機」とも呼び、それ以外のカラオケ装置１ｂ，１ｃ…を「子機」とも呼ぶこととする。
【００３１】
なお、ハードディスク１３に記憶された演奏プログラムは、カラオケ装置１ａの電源投入時に、ハードディスク１３からＲＡＭ１５に読み出されてＣＰＵ１４が実行可能なように展開されている。図２及び図３に示す処理は、この演奏プログラムが実行されることによって実現される。
【００３２】
ここで、親機であるカラオケ装置１ａにおいて、実際にユーザによってリクエスト処理が行われた場合の演奏処理及び演奏前のエラーチェック・データ修復処理について図２のフロ−チャートを参照して説明する。
図２に示す処理は、ユーザによる操作パネル１０を介した数桁の数字と入力の完了を示す確定キーの入力がなされた場合に実行され、まず、最初のステップＳ１では、ユーザがリクエストした曲に対応した曲データをハードディスク１３から読み出してＲＡＭ１５に展開する。続くステップＳ２では、ステップＳ１で読み出した曲データに対応したＣＲＣ値をやはりハードディスク１３から読み出してＲＡＭ１５に展開する。
【００３３】
次のステップＳ３では、ステップＳ１にてハードディスク１３からＲＡＭ１５上に展開された曲データから、ステップＳ２にてやはりハードディスク１３からＲＡＭ上に読み出したＣＲＣ値と比較するためのＣＲＣ値を算出する。そして、この算出したＣＲＣ値とステップＳ２にてハードディスク１３から読み出したＣＲＣ値とが等しいか否かを判断する（Ｓ４）。これらのＣＲＣ値が等しい場合には（Ｓ４：ＹＥＳ）、曲データが破損していないと判断してステップＳ５へ移行し、カラオケ演奏を実行する。
【００３４】
一方、比較したＣＲＣ値が等しくない場合には（Ｓ４：ＮＯ）、曲データが破損していると判断し、通信装置１９により通信ネットワーク３を介してホストコンピュータ２に該当する配信データの再配信要求を送信する（Ｓ６）。ホストコンピュータ２から再配信された該配信データ及びＣＲＣ値を受信し（Ｓ７）、それらを再度ハードディスク１３に格納する（Ｓ８）。そして、再度ステップＳ１へ戻ってステップＳ１以下の処理を繰り返す。
【００３５】
次に、子機であるカラオケ装置１ｂ，１ｃ…において、実際にユーザによりリクエスト処理が行われた場合の演奏処理及び演奏前のエラーチェック・データ修復処理について図３のフロ−チャートを参照して説明する。
図３に示す処理は、ユーザによる操作パネル１０を介した数桁の数字と入力の完了を示す確定キーの入力がなされた場合に実行され、まず、最初のステップＳ１１では、ユーザがリクエストした曲に対応した曲データをハードディスク１３から読み出してＲＡＭ１５に展開する。続くステップＳ１２では、ステップＳ１１で読み出した曲データに対応したＣＲＣ値をやはりハードディスク１３から読み出してＲＡＭ１５に展開する。
【００３６】
次のステップＳ１３では、ステップＳ１にてハードディスク１３からＲＡＭ１５上に展開された曲データから、ステップＳ１２にてやはりハードディスク１３からＲＡＭ上に読み出したＣＲＣ値と比較するためのＣＲＣ値を算出する。そして、この算出したＣＲＣ値とステップＳ１２にてハードディスク１３から読み出したＣＲＣ値とが等しいか否かを判断する（Ｓ１４）。これらのＣＲＣ値が等しい場合には（Ｓ１４：ＹＥＳ）、曲データが破損していないと判断してステップＳ１５へ移行し、カラオケ演奏を実行する。
【００３７】
一方、比較したＣＲＣ値が等しくない場合には（Ｓ１４：ＮＯ）、曲データが破損していると判断し、ネットワークインターフェース１７によりＬＡＮ３０を介して親機であるカラオケ装置１ａに該当する配信データ及びＣＲＣ値の再配信要求を送信する（Ｓ１６）。親機であるカラオケ装置１ａから再配信された該配信データ及びＣＲＣ値を受信し（Ｓ１７）、それらを再度ハードディスク１３に格納する（Ｓ１８）。そして、再度ステップＳ１１へ戻ってステップＳ１１以下の処理を繰り返す。
【００３８】
図２、図３に示すフローチャートは、それぞれ親機、子機が、リクエストされた曲のカラオケ演奏を実行する前に当該演奏に用いる曲データについてエラーチェックする処理を示すものであった。しかし、親機、子機は、そのようなリクエストされた場合以外にも、例えば１日１回、例えば電源投入時や所定時刻などにおいて、自身のハードディスク１３に格納されている全ての配信データから破損データを検出し修復する機能を持っている。
【００３９】
その例を図４を参照して説明する。図４（ａ）は、各カラオケ装置１ａ，１ｂ，１ｃ…のハードディスク１３に格納されている配信データ群を示しており、ここで配信データとは、音楽情報、画像情報、バージョンアップされた演奏プログラムなどである。そして、配信ファイル及び各配信ファイルのＣＲＣ値が関連付けされて格納されている。カラオケ装置１ａ，１ｂ，１ｃ…は、１日１回電源投入時や所定時刻などにおいて自身の持つハードディスク１３内に格納されている配信データをＲＡＭ１５に読み出しＣＲＣ値を算出する。その算出したＣＲＣ値がハードディスク１３内に格納されている（該配信データと対応する）ＣＲＣ値と異なる場合には、データが破損していると判断し、再配信要求リストに該配信ファイル名を記憶する。この再配信要求リストはハードディスク１３に記憶されていくものとする。
【００４０】
例えば、ハードディスク１３内に格納されている全ての配信データについて算出したＣＲＣ値が図４（ｂ）に示すようになったとすると、図４（ａ）に示すＣＲＣ値と異なるものを抽出した再配信要求リストは図４（ｃ）に示すようになる。つまり、配信データＢ、配信デ−タＣ、配信データＥ、配信データＨについては、図４（ａ）に示すＣＲＣ値と図４（ｂ）に示すＣＲＣ値とが異なるため、その異なった配信データを抽出して再配信要求リストとするのである。
【００４１】
そして、図４（ｃ）に示す再配信要求リスト内にある全ての配信データに関して前述と同様の対処を行う。つまり、親機であれば、該当する配信データの再配信要求をホストコンピュータ２に送信し、ホストコンピュータ２から再配信された該配信データ及びＣＲＣ値を受信して、それらを再度ハードディスク１３に格納する。一方、子機であれば、該当する配信データの再配信要求を親機に送信し、親機から再配信された該配信データ及びＣＲＣ値を受信して、それらを再度ハードディスク１３に格納する。これによって、データ修復を完了する。
【００４２】
このように、本実施例のカラオケ装置１ａ，１ｂ，１ｃ…によれば、次のような効果が得られる。
（１）カラオケ装置１ａ，１ｂ，１ｃ…のハードディスク１３に格納される配信データが振動や電源の瞬断等によって破損した場合に、その破損したデータを検知することができ、さらに、その破損したデータについては、親機であればホストコンピュータ２から再配信を受け、子機であれば親機から再配信を受けてデータ修復することができる。
【００４３】
そして、図２、図３に示すように、カラオケ装置１ａ，１ｂ，１ｃ…では、リクエストされた曲のカラオケ演奏を実行する前にエラーチェックするため、破損したデータをそのまま使用してカラオケ利用者に対して適切でないサービスを提供してしまうという不都合を回避できる。
【００４４】
（２）また、本実施例では、カラオケ演奏実行前だけでなく、例えば電源投入時や所定時刻などにおいて、自身のハードディスク１３に格納されている全ての配信データから破損データを検出し修復するようにしている。確かにクエストされた曲のカラオケ演奏を実行する前にエラーチェック及びデータ修復をすれば、データ破損が発生した時期に関係なく適切なデータを用いたカラオケ演奏を実行できる。但し、再配信に要する時間待たなくてはならない。したがって、カラオケ演奏実行前だけではなく、上述のように電源投入時や所定時刻などにエラーチェック及びデータ修復をしておけば、そのエラーチェック時点以前にデータ破損が生じていたものについては、実際にそのデータを用いたカラオケ演奏の前に予めデータ修復しておくことができる。つまり、そのような事前チェック及びデータ修復の後、実際のカラオケ演奏までの間にデータ破損が生じなければ、カラオケ演奏前のデータ修復をしなくてよくなり、再配信の間カラオケ演奏を待つ必要もなくなる。
【００４５】
なお、本実施例においては、配信データが「処理実行用情報」に相当し、ＣＲＣ値が「エラー検出情報」に相当する。また、ハードディスク１３が「情報記憶手段」及び「エラー検出情報記憶手段」に相当し、ＣＰＵ１４が「比較情報算出手段」、「破損情報検出手段」、「エラー検出情報受信手段」及び「送信要求手段」に相当する。また、親機の場合は通信装置１９、子機の場合はネットワークインターフェース１７が、「第１の通信手段」及び「第２の通信手段」に相当する。
【００４６】
以上実施例について説明したが、本発明は上記実施例に限定されるものではなく、種々の態様で実施し得る。そのいくつかを説明する。
（１）上記実施例では、カラオケ演奏に使用する音楽情報や画像情報などの配信データをエラーチェック対象としたが、例えばカラオケ演奏処理をＣＰＵ１４が実行するためのアプリケーションプログラム（演奏プログラム）をエラーチェック対象としてもよい。また、それら以外の情報であっても当然よい。
【００４７】
（２）上記実施例では、ハードディスク１３に格納されている全ての配信データをエラーチェック対象としたが、全てのデータでなくてもよい。例えば配信データに対応してエラー検出の必要性の有無をハードディスク１３に記憶しておき、エラー検出の必要性が有ると記憶されている配信データに対してのみ、エラーチェック（及びデータ修復）を実行するようにしてもよい。
【００４８】
例えば、カラオケ演奏に際しては楽音情報の方が画像情報よりも重要であると考えられる。つまり、画像データは多少違和感があったとしてもカラオケを楽しむ上で特に問題にならないが、楽音データの場合には、音飛び等が発生するだけで違和感が大きく、カラオケというサービス内容の品質低下を招く。このようにエラー検出の必要性は楽音データが相対的に高いと言える。したがって、画像情報についてはエラー検出せず、楽音情報についてのみエラー検出することが考えられる。この場合は、画像情報のデータ量が楽音情報に比べて相当大きいため、エラーチェック及びデータ修復に要する処理負荷低減の観点でも有利である。
【００４９】
また、上記別実施例（１）において、エラーチェック対象としてカラオケ演奏をするためのアプリケーションプログラムデータも含めることを述べた。このアプリケーションプログラムデータが破損している場合には、たとえ楽音情報等が正常であっても、カラオケ演奏処理自体が正常に実行されない。したがって、このようなアプリケーションプログラムをエラー検出の必要性がより高い情報であるとすることも考えられる。
【００５０】
さらに、例えば上記実施例における親機が、ホストコンピュータ２から新譜曲の配信を受けるために自らホストコンピュータ２へアクセスするのであれば、そのアクセスするための情報（例えば電話番号等）がデータ破損によってエラーとなってしまうと重大な問題である。したがって、このようなアクセス用情報についてもエラー検出の必要性を高くしておくことが考えられる。但し、このアクセス情報自体にエラーが生じている場合、ホストコンピュータ２へアクセスすることができなければデータ修復はできない。そこで、子機にもこのアクセス用情報を記憶させておき、親機は子機から正しいデータを取得するよう構成することが考えられる。
【００５１】
（３）上記別実施例（２）では、データ種類に応じてエラーチェックの必要性の有無（高低）を検討したが、例えば同じデータ種類のものであってもエラーチェックの必要性の有無（高低）を異ならせることもできる。例えば配信データ同士においても、推定される使用頻度に応じた対応をする。具体的には、例えば通信カラオケ装置においては、新譜曲や歌われた回数の多い曲については、今後も利用される可能性が高いため、相対的にエラー検出の必要性が高いと考えられる。また、ゲーム装置であれば、よく利用されるゲームプログラムがエラー検出の必要性が高いと考えられる。したがって、新譜曲や歌われた回数の多い曲については楽音情報だけでなく画像情報についてもエラーチェック対象とすることも有効な対処である。
【００５２】
また、過去に歌われた回数や使用された回数が多いということは、その曲やゲームプログラムに関する配信データをハードディスク１３から読み出す機会が増えるということであり、それはデータ読み出し時における各種原因でデータ破損が生じる可能性がより高いと言える。したがって、このような配信データについてはエラーチェックの必要性がより高いと考え、エラーチェックの対象にすることが考えられる。
【００５３】
（４）また、エラーチェックの対象とするか否かではなく、エラーチェック（及び必要に応じてデータ修復）を実行する頻度を変えても良い。例えば、通信カラオケ装置において、カラオケ曲として利用される頻度が高いと思われる曲については、検査頻度を高くする。具体的には、一般的なエラーチェックの頻度を１日１回だとすれば、１日２回以上エラーチェックする。例えば新譜曲や歌われた回数の多い曲については、今後も利用される可能性が高いため、検査を充実した方が好ましいと考えられるからである。また、上述したように、歌われた回数が多いということは、その曲データをリードする機会が増えるということであり、それはリード時における各種原因でデータ破損が生じる可能性も多いため、その意味でも検査頻度を上げることは有効である。
【００５４】
（５）上記実施例では、データ破損を検出した場合に再度データ配信を受けて更新記憶するようにした。このようにすれば自動的にデータ修復されるため好ましいが、例えば単に人が認識可能なように表示装置２６等に表示するという対処も考えられる。この場合は、その表示内容を見たカラオケ装置１ａ，１ｂ，１ｃ…の管理者が、別途必要な対処をする。例えばマニュアル操作によってデータの再配信を要求するといったことである。もちろん、音声出力による報知であってもよい。
【００５５】
（６）上記実施例では複数台のカラオケ装置１ａ，１ｂ，１ｃ…がＬＡＮ３０によって互いに通信可能に構成されたネットワークシステムを前提としたが、例えば１台のカラオケ装置がホストコンピュータ２から配信データを受信するような構成であっても同様に実現できる。
【００５６】
また、カラオケ装置に限らず、他の情報処理装置であっても実現可能である。つまり、ユーザからの要求等があった場合に、ハードディスク等の情報記憶手段に記憶している処理実行用情報を用いて処理を実行するような装置であれば、破損データを用いた処理を実行してしまうとユーザに対して適切な情報提供ができないので、上述ようなエラーチェック及び必要に応じてデータ修復することは有効な対処となる。
【００５７】
（７）上記実施例ではエラー検出情報としてＣＲＣ値を採用したが、チェックサム等のサム値を使用するなど、その他のエラー検出に資することのできる情報であってもよい。
【図面の簡単な説明】
【図１】実施例のカラオケ装置の概略構成を示すブロック図である。
【図２】実施例のカラオケ装置（親機）において実行される演奏前のエラーチェック・データ修復処理を説明するフローチャートである。
【図３】実施例のカラオケ装置（子機）において実行される演奏前のエラーチェック・データ修復処理を説明するフローチャートである。
【図４】実施例のカラオケ装置において実行される事前のエラーチェック・データ修復処理の説明図である。
【符号の説明】
１ａ，１ｂ，１ｃ…カラオケ装置、２…ホストコンピュータ、３…通信ネットワーク、１０…入力装置、１２…ＥＥＰＲＯＭ、１３…ハードディスク、１４…ＣＰＵ、１５…ＲＡＭ、１７…ネットワークインターフェース、１８…音源再生装置、２０…アンプ、２２…スピーカ、２３…マイクロフォン、２４…映像再生装置、２６…表示装置。

Claims (7)

1. 情報処理を実行するために用いる情報を記憶しておく情報記憶手段、
   前記情報記憶手段に記憶されている処理実行用情報に対するエラー検出を行うためのエラー検出情報を送信可能な第１の外部装置と通信するための第１の通信手段、
   前記第１の通信手段を介して前記第１の外部装置から前記エラー検出情報を受信するエラー検出情報受信手段、
   前記エラー検出情報受信手段によって受信したエラー検出情報を、対応する処理実行用情報と関連付けて記憶するエラー検出情報記憶手段、
   前記エラー検出情報記憶手段に記憶されているエラー検出情報と比較するために、前記情報記憶手段に記憶されている、対応する処理実行用情報の比較情報を算出する比較情報算出手段、
   前記比較情報算出手段により算出された比較情報と前記エラー検出情報記憶手段に記憶されているエラー検出情報とを比較し、破損している処理実行用情報を検出する破損情報検出手段、
   を備える情報処理装置。
2. 請求項１に記載の情報処理装置において、
   さらに、前記情報記憶手段に記憶されている処理実行用情報に対応するエラー検出の必要性の有無を記憶しておくエラー検出必要有無記憶手段を備え、
   前記エラー検出必要有無記憶手段にエラー検出の必要性が有ると記憶されている処理実行用情報に対してのみ、前記比較情報算出手段及び破損情報検出手段によるエラー検出に係る処理を実行する情報処理装置。
3. 請求項１又は２に記載の情報処理装置において、
   さらに、前記情報記憶手段に記憶されておりエラー検出対象となっている処理実行用情報に対応するエラー検出の必要性の高低を記憶しておくエラー検出必要度記憶手段を備え、
   前記エラー検出必要度記憶手段に記憶されたエラー検出の必要性が高いほど、前記比較情報算出手段及び破損情報検出手段によるエラー検出に係る処理の実行頻度を高くする情報処理装置。
4. 請求項１〜３のいずれかに記載の情報処理装置において、
   さらに、
   前記破損情報検出手段によって破損している処理実行用情報を検出した場合には、その破損している処理実行用情報を人が認識可能なように報知する報知手段を備える情報処理装置。
5. 請求項１〜３のいずれかに記載の情報処理装置において、
   さらに、
   前記処理実行用情報を送信可能な第２の外部装置と通信するための第２の通信手段、
   前記破損情報検出手段によって破損している処理実行用情報を検出した場合には、その破損している処理実行用情報の送信を前記第２の通信手段を介して前記外部装置へ要求する送信要求手段、
   その送信要求手段による送信要求に応じて前記第２の外部装置から送信された処理実行用情報を前記情報記憶手段に更新記憶させる更新記憶制御手段を備える情報処理装置。
6. 請求項５に記載の情報処理装置において、
   前記第２の外部装置は前記第１の外部装置であり、前記第２の通信手段は前記第１の通信手段である情報処理装置。
7. 請求項１〜６のいずれかに記載の情報処理装置が複数台、情報送受信可能に接続されたネットワークシステムであって、
   前記複数台の情報処理装置の内のいずれかが、前記第１の外部装置及び存在する場合には前記第２の外部装置の少なくともいずれか一方としての機能も発揮するよう構成されているネットワークシステム。

Images