JP2004295182A - ファイルアクセス管理装置 - Google Patents
ファイルアクセス管理装置 Download PDFInfo
- Publication number
- JP2004295182A JP2004295182A JP2003082882A JP2003082882A JP2004295182A JP 2004295182 A JP2004295182 A JP 2004295182A JP 2003082882 A JP2003082882 A JP 2003082882A JP 2003082882 A JP2003082882 A JP 2003082882A JP 2004295182 A JP2004295182 A JP 2004295182A
- Authority
- JP
- Japan
- Prior art keywords
- information
- file
- directory
- cache
- stored
- 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.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】情報提供装置におけるハードディスク等の記憶手段に記憶された提供情報ファイルへのアクセスレスポンスを向上させる。
【解決手段】装置起動時にｃａｃｈｅ．ｌｓｔファイルがＨＤＤから読み出され、そのファイル中にリストされたファイル又はディレクトリ名に対応するインデックスブロックがＨＤＤ中で予め検索され、その検索結果が第一キャッシュに記録される。そのため、この状態で、選曲番号１の曲が選曲されると、第一キャッシュから／ｍｕｓｉｃ／０のインデックスブロックＬＢＡを得ることができ、いまだキャッシュされていない楽曲ファイル／ｍｕｓｉｃ／０／０００１．ＭＩＤを検索する（Ｑ１）のみで所望の楽曲ファイルを読み出すことができる。また、背景映像の割り当てについても、／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘファイルは第一キャッシュに予めキャッシュされているため、ＨＤＤへのアクセス無しにそのインデックスブロックにアクセスが可能である。
【選択図】図１０
【解決手段】装置起動時にｃａｃｈｅ．ｌｓｔファイルがＨＤＤから読み出され、そのファイル中にリストされたファイル又はディレクトリ名に対応するインデックスブロックがＨＤＤ中で予め検索され、その検索結果が第一キャッシュに記録される。そのため、この状態で、選曲番号１の曲が選曲されると、第一キャッシュから／ｍｕｓｉｃ／０のインデックスブロックＬＢＡを得ることができ、いまだキャッシュされていない楽曲ファイル／ｍｕｓｉｃ／０／０００１．ＭＩＤを検索する（Ｑ１）のみで所望の楽曲ファイルを読み出すことができる。また、背景映像の割り当てについても、／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘファイルは第一キャッシュに予めキャッシュされているため、ＨＤＤへのアクセス無しにそのインデックスブロックにアクセスが可能である。
【選択図】図１０
Description
【０００１】
【発明の属する技術分野】
本発明は、情報提供装置におけるファイルアクセス管理方法等に関する。
【０００２】
【従来の技術】
従来より、例えば映像や音声、文字情報などから構成される提供情報を複数蓄積し、利用者の要求に応じてこれら蓄積された提供情報から一部を選択した上で再生等して利用者に提供する情報提供装置が知られている。そして、このような提供情報は例えばハードディスク等に記憶されるのであるが、このハードディスク内において、任意に設定されたファイル単位で管理されることが多い。このようなファイルを管理する仕組みはファイルシステムと称され、このようなファイルシステムにおいては、各種の情報をファイルとして記憶するのみでなく、ディレクトリと呼ばれる仮想的な階層構造を作成し、ファイルの検索の高速化や設計の容易化を図るものが一般的である。
【０００３】
また、ファイル又はディレクトリは、その実データをハードディスク等の記憶装置に記憶すると同時に、ファイルシステムでの管理のため、実データの記憶装置上での記憶位置やそのアクセス許可属性など付加的な情報（インデックス情報）を同時に記憶する。通常これらのインデックス情報は実データとは別に記憶され、その上でファイルシステムはアプリケーションプログラムからファイル又はディレクトリ名称による検索要求を受けて、その名称を元にインデックス情報を記憶装置から検索し、発見したインデックス情報を読み出した上で、アプリケーションプログラムにファイルデータへのアクセスを行う。
【０００４】
ここで、インデックス情報の検索成功時に、その検索結果、すなわちファイル名と対応するインデックス情報の記憶装置上での位置情報（以下、単に位置情報と称す。）の組、又はディレクトリ名と位置情報との組、若しくはファイル名及び所属するディレクトリ名と位置情報との組を、ハードディスク等の記憶装置よりも高速読み出しが可能な、例えばＲＡＭのような、ハードディスクに対して高速アクセス可能なメモリに一時記憶しておくこと（キャッシング）が一般的に行われている（例えば、特許文献１参照。）。すなわち、ある名称でインデックス情報を検索した後に、再度同一の名称での検索が必要な場合には、実際にハードディスク等の記憶装置上で検索を行うのではなく、キャッシングされた情報（キャッシュ情報＝検索結果）をＲＡＭから読み出して見掛け上の検索処理時間を短縮するものである。
【０００５】
さらに、キャッシュ情報が無限に増大してしまうことを防ぐために、キャッシングするキャッシュ情報の総数に上限を設定し、この上限を超えてキャッシュ情報を記憶する必要が発生した場合には、例えばＬＲＵ（Ｌｅａｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ）アルゴリズムなどの手法で一部のキャッシュ情報を選択して消去（キャッシュアウト）した上で、その消去によって空いた記憶領域に新規のキャッシュ情報を記憶することも行われている。
【０００６】
【特許文献１】
特開平５−１０８４８０号公報
【０００７】
【発明が解決しようとする課題】
しかしながら、上記のようなキャッシング手法では、実検索が１度行われた時点でキャッシングが行われるため、装置起動直後には利用者の指示を受けてから必ずインデックス情報の実検索が行われる。すなわち、装置起動直後は装置が起動してある程度の時間を経た時点と比較して、全体的にファイルアクセスのレスポンスが遅い。
【０００８】
また、上記のようなキャッシング手法では、キャッシュアウトに際して各ファイル又はディレクトリのシステム全体から見た意味的な重みは一切考慮されず、すべてが同等なものとして扱われている。そのため、例えばめったに使用しないファイル又はディレクトリを使用した際に、使用頻度のより高いファイル又はディレクトリに関するキャッシュ情報がキャッシュアウトされてしまう。そのため、その後にキャッシュアウトされたファイル又はディレクトリにアクセスする際には、再度ハードディスク等の記憶装置上での実検索が必要となり、結果としてシステムの応答時間を低下させてしまうことがある。
【０００９】
これは、汎用的な情報処理装置ではなく、例えばカラオケ装置等のように、例えば提供情報としての音楽情報や映像情報等を用いて所定の情報提供を実行する装置の場合には、顕著になる。例えばカラオケ装置の場合であれば、音楽情報や映像情報は、カラオケ演奏という情報提供毎に毎回アクセスされる対象であり、このような情報に対応するファイル又はディレクトリに関するキャッシュ情報がキャッシュアウトされてしまうことは、カラオケ演奏処理についての応答時間を悪くする要因となる。そして、このようなキャッシュアウトがカラオケ演奏毎に生じると、カラオケ演奏毎にハードディスク等の記憶装置上での実検索を行うこととなって、アクセスレスポンスが低下してしまう。
【００１０】
なお、このような問題は、カラオケ装置の場合に限らず、ビデオサーバやゲーム装置等であっても同様である。ハードディスク等の記憶手段に蓄積された多数の提供情報中から要求に応じたものを選択する場合には、上述したファイルアクセス時の問題が同様に生じるからである。
【００１１】
本発明は、上述した問題点を解決するためになされたものであり、情報提供装置におけるハードディスク等の記憶手段に記憶された提供情報ファイルへのアクセスレスポンスを向上させる技術を提供することを目的とする。
【００１２】
【課題を解決するための手段及び発明の効果】
（１）本発明のファイルアクセス管理装置は、少なくとも複数の提供情報を任意に設定されたファイル単位で記憶しておくための第一の記憶手段（実施例ではハードディスク１３）、第一の記憶手段よりも高速に読み書きが可能な第二の記憶手段（実施例ではＲＡＭ１１ａ）、提供情報の提供要求を受け付ける要求受付手段、要求受付手段によって受け付けた情報提供要求に応じた提供情報を用いて情報提供を実行する情報提供実行手段、を備える情報提供装置における第一の記憶手段に記憶された提供情報をアクセスするための管理装置である。
【００１３】
ここで、第一の記憶手段に記憶される提供情報については、当該提供情報に対応するファイル名又はディレクトリ構成で管理すると共に、ファイル名又は所属ディレクトリ名とファイル名を指定することによって該当する提供情報に対するアクセスを可能とするインデックス情報（実施例ではインデックスブロック）が、ファイル又はディレクトリ毎に記憶されている。また、第一の記憶手段内のファイル又はディレクトリを、アクセスレスポンスの向上の必要性の高低に基づいて予め２つ以上のグループに分けると共に、アクセスレスポンスの向上の必要性が高い第一のグループに属するファイル又はディレクトリを特定可能な特定情報（実施例ではｃａｃｈｅ．ｌｓｔファイル）を第一の記憶手段に記憶している。
【００１４】
そして、第一のキャッシュ処理手段が次のような処理を実行する。つまり、情報提供装置の起動時に前記特定情報を読み出し、その読み出した特定情報によって特定されるファイル又はディレクトリのインデックス情報（実施例ではインデックスブロック）が記憶されている第一の記憶手段内の位置情報（実施例ではインデックスブロックＬＢＡ）について予め検索し、その検索結果を前記第二の記憶手段内の第一の記憶領域（実施例では第一キャッシュ）に記憶する。
【００１５】
一方、第二のキャッシュ処理手段は次のような処理を実行する。つまり、第一のグループ以外のグループに属するファイル又はディレクトリのインデックス情報が記憶されている第一の記憶手段内の位置情報については、提供要求が生じた場合に検索し、その検索結果を第二の記憶手段内の第二の記憶領域（実施例では第二キャッシュ）に記憶する。
【００１６】
そして、ファイルアクセス実行手段は 提供要求が生じた場合には、当該提供要求に対応するインデックス情報を第二の記憶手段内の第一の記憶領域及び第二の記憶領域から検索し、検索できた場合にはそのインデックス情報に基づいてファイルアクセスを実行する。
【００１７】
このようなファイルアクセスの管理をすることで、アクセスレスポンスの向上の必要性が高い第一のグループに属するファイル又はディレクトリについては、情報提供装置の起動直後にインデックス情報の位置情報が検索されてキャッシュされており、その位置情報を用いてアクセスできるため、ファイルアクセスのレスポンスが向上する。
【００１８】
なお、第一のキャッシュ処理手段は、提供情報をファイル名で管理する場合にはファイル名と位置情報の組を検索結果として記憶し、提供情報をディレクトリ構成で管理する場合には、ディレクトリ名と位置情報の組、又はファイル名と所属ディレクトリ名と位置情報の組を検索結果として記憶する（請求項２）。
【００１９】
（２）また、第一のキャッシュ処理手段によって第二の記憶手段内の第一の記憶領域に記憶された検索結果は、情報提供装置が稼働している間中、第二の記憶手段内の第一の記憶領域に保持し続けようにし、第二のキャッシュ処理手段は、検索結果に新規に記憶させようとした場合に、第二の記憶手段内の第二の記憶領域の記憶容量を超えるのであれば、既に記憶されている検索結果を削除してから記憶させるようにしてもよい（請求項３）。
【００２０】
このようにすれば、アクセスレスポンスの向上の必要性が高い第一のグループに属するファイル又はディレクトリに対応する検索結果を第二の記憶手段内に常駐させておくことができ、情報提供装置が稼働している間は常に、これら第一のグループに属するファイル、又は第一のグループに属するディレクトリに対するアクセスレスポンス、ひいては該ディレクトリに所属するファイルに対するアクセスレスポンスを向上させることができる。
一方、上述の第二のキャッシュ処理手段は、第二の記憶手段内の第二の記憶領域を所定の記憶容量内に保ちながら、新規な検索結果について記憶させることができるため、最近使用したファイルに対するアクセスレスポンスはやはり向上する。
【００２１】
（３）なお、アクセスレスポンスの向上の必要性の高低については、例えば請求項４に示すように、少なくとも第一の記憶手段内のファイル又はディレクトリのアクセス頻度の高低に基づいて決定することが考えられる。例えば請求項６に示すように、情報提供装置としてカラオケ装置を想定し、提供情報としてのカラオケ演奏データを用いてカラオケ演奏を実行する場合を考える。この場合であれば、例えば特定情報に、カラオケ演奏データに対応するファイル又はディレクトリを特定可能な情報を含めておく。例えば請求項７に示すように、カラオケ演奏データに楽曲データと背景画データとが含まれている場合には、特定情報には、楽曲データと背景画データそれぞれに対応するファイル又はディレクトリを特定可能な情報を含めておくことが考えられる。このようにすれば、楽曲データと背景画データに対応するファイル又はディレクトリに関する検索結果が常駐することとなって、キャッシュアウトされてしまうことがない。これらのデータはカラオケ演奏の度に毎回アクセスされるため、アクセスレスポンスが向上することは、非常に有効である。
【００２２】
もちろん、アクセスレスポンスの向上の必要性の高低については、他の観点を加味することもできる。例えば緊急性という観点を加味してもよい。例えば利用者に対して「ただいま検索中」とか、「少しお待ち下さい」といったガイダンスを表示等によって報知する場合、このようなガイダンスが早めに出ないと利用者としては故障なのか何なのかが分からないため、極力早いほうがよい。このようなガイダンスは、たとえ使用頻度が相対的に低くても、アクセスレスポンスの向上が希求されるものである。
【００２３】
（４）また、請求項５に示すように、情報提供装置が外部のホスト装置と通信するための通信手段を備え、通信手段を介してホスト装置から特定情報を受信可能に構成されているのであれば、その受信した特定情報を第一の記憶手段に記憶しておき、その第一の記憶手段に記憶された特定情報に基づいて第一のキャッシュ処理手段が検索等の処理を実行することが考えられる。このようにすれば、ホスト装置から送信する特定情報によって、第二の記憶手段の第一の記憶領域に常駐させておく検索結果を適宜更新することができる。例えばいわゆる通信カラオケシステムの場合には、ホスト装置からカラオケ装置に対して新曲データその他の情報を配信することとなるが、例えば配信する情報内容次第では、特定情報自体を変更した方がよい場合も想定される。その際、カラオケ装置（情報提供装置）側で逐次変更するのは不便である。また、どのような特定情報の内容にした方がよいのかは、提供情報を配信する側が最もよく知っていると思われる。したがって、配信側において配信内容等に基づいて最適と思われる特定情報をカラオケ装置（情報提供装置）に送信し、その送信された特定情報に基づいて、第一のキャッシュ処理手段が第二の記憶手段の第一の記憶領域に検索結果を記憶させれば、状況の変化に対応した最適な状態にすることが可能となり、情報提供装置全体としてのアクセスレスポンスの向上に寄与できる。
【００２４】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうる。
【００２５】
本実施例では、ファイルアクセス管理装置を備えた情報提供装置の一例としてのカラオケ装置について説明する。
［カラオケ装置１の説明］
図１は、実施例のカラオケ装置１の概略構成を示している。本実施例のカラオケ装置１は、カラオケ店舗に設置されており、例えばカラオケ店舗の各部屋にそれぞれ１台ずつ設置される。なお、これら複数台のカラオケ装置１は店舗内ネットワーク３０にて接続することによってネットワークシステムを構成している。そして、これら複数台のカラオケ装置１の内、何れか一つ（以上）のカラオケ装置１は、公衆回線を介して配信用ホスト装置５０に接続できるようになっており、この公衆回線４０を介して接続した配信用ホスト装置５０からカラオケに関する配信データ（「提供情報」としての音楽情報（楽曲データ）や画像情報（背景画データ）、あるいは例えばカラオケ演奏処理を実行するためのアプリケーションプログラム（カラオケ演奏プログラム）等）を取得して、「第一の記憶手段」としてのハードディスク１３へ記憶しておくことができる。このカラオケ装置１は、ハードディスク１３に記憶されている配信データを、店舗内ネットワーク３０によって接続された他のカラオケ装置１へ送信することができる。そのため、公衆回線４０を介して配信用ホスト装置５０と接続する機能を持つカラオケ装置１がマスタ（親機）となり、他のカラオケ装置１がスレーブ（子機）となっている。
【００２６】
マスタまたはスレーブとして機能するカラオケ装置１の基本的な構成はいずれも同じであるが、上述のように、マスタのみが公衆回線４０を介して配信用ホスト装置５０に接続できるようになっている。それ以外の機能は基本的にいずれも同じである。したがって、以下の構成説明に関しては、図１に示す（マスタとして機能する）カラオケ装置１に関して行うこととする。
【００２７】
カラオケ装置１は、図１に示すように、カラオケ装置１を制御するための中央処理装置１１、ネットワークとしての店舗内ネットワーク３０を介して他のカラオケ装置（この場合はスレーブ）と接続したり、公衆回線４０を介して配信用ホスト装置５０と接続し、各種の情報を送受信する通信制御装置１２、各種データ等を記憶しているハードディスク１３、曲の予約や電源のＯＮ・ＯＦＦなどを行うための操作パネル１４、操作パネル１４と同様に曲の予約等を行うためのリモコン送信機１５、リモコン送信機１５からの信号を受信するためのリモコン受信機１６、操作パネル１４やリモコン受信機１６からの信号を受け付けて処理する操作制御部１７、演奏の再生を行うシンセサイザ１８、音楽情報にかかる電気信号を増幅等するミキシングアンプ１９、ミキシングアンプ１９からの電気信号を入力して伴奏曲及び利用者の歌声等を流すスピーカ２０、利用者の歌声等をミキシングアンプ１９に入力するマイクロフォン２１、中央処理装置１１によって生成された歌詞情報を記憶するビデオＲＡＭ２２、画像情報等を再生する映像再生装置２３、ビデオＲＡＭ２２からの歌詞情報と映像再生装置２３からの映像信号とに基づき、歌詞及び歌詞の背景映像を出力する映像制御部２４、映像制御部２４から出力された歌詞及び歌詞の背景映像を表示する表示装置２５を備えている。また、このうちの中央処理装置１１には、通信制御装置１２、ハードディスク１３、操作制御部１７、シンセサイザ１８、ビデオＲＡＭ２２、映像再生装置２３及び映像制御部２４が接続されており、中央処理装置１１は、これらを介してカラオケ装置１を制御する。
【００２８】
続いて各部の具体的な構成を説明する。
まず、中央処理装置１１は、ＣＰＵ、ＲＯＭ（いずれも図示せず）、ＲＡＭ１１ａなどを備える周知の構成である。一方、ハードディスク１３は、中央処理装置１１がカラオケ装置１を制御するための各種プログラムを格納している。中央処理装置１１の備えるＣＰＵによって実行される複数のプログラムはＲＯＭ及びハードディスク１３に格納されており、ＣＰＵは該プログラムをＲＡＭ１１ａに展開しプログラムを実行することとなる。また、このＲＡＭ１１ａは、「第二の記憶手段」に相当し、いわゆる「キャッシュ」として機能する領域を有している。これらハードディスク１３におけるデータの記憶、及びＲＡＭ１１ａ内のキャッシュ領域におけるデータの記憶については後述する。なお、カラオケ装置１の中央処理装置１１は、情報提供実行手段、第一のキャッシュ処理手段、第二のキャッシュ処理手段、ファイルアクセス実行手段に相当する。
【００２９】
通信制御装置１２は、店舗内ネットワーク３０を介してカラオケ店舗内の他の部屋に設置されたカラオケ装置（この場合はスレーブ）に接続されており、これら他のカラオケ装置（この場合はスレーブ）との間で各種の情報を送受信する。また、カラオケ装置１の通信制御装置１２は、上述したように、公衆回線４０を介して配信用ホスト装置５０と接続し、この配信用ホスト装置５０との間で各種の情報を送受信する。
【００３０】
操作制御部１７には、操作パネル１４およびリモコン受信機１６が接続されている。このうち、操作パネル１４は、利用者がカラオケ曲の選択や演奏アレンジの切り替えを行ったりするためのものであり、「要求受付手段」に相当する。
利用者がこの操作パネル１４を操作すると、その入力操作の信号が操作制御部１７および中央処理装置１１に送られて処理される。一方、リモコン受信機１６は、リモコン送信機１５からの信号を受信するためのものである。また、このリモコン送信機１５は、操作パネル１４と同様に、利用者がカラオケ曲の選択や演奏アレンジの切り替えを行ったりするためのものである。利用者がこのリモコン送信機１５を操作すると、その入力操作の信号がリモコン受信機１６を介して操作制御部１７および中央処理装置１１に送られて処理される。
【００３１】
また、シンセサイザ１８には、ミキシングアンプ１９が接続され、このミキシングアンプ１９にはスピーカ２０が接続されている。ハードディスク１３等から読み出され、中央処理装置１１から供給される音楽情報（ＭＩＤＩ形式のカラオケ演奏データ）に基づいてシンセサイザ１８から出力される楽音信号はミキシングアンプ１９で増幅されてスピーカ２０から出力される。また、ミキシングアンプ１９には利用者の歌唱音声を入力するためのマイクロフォン２１が接続されており、このマイクロフォン２１によって入力された音声信号もシンセサイザ１８からの楽音信号と共にスピーカ２０から出力される。
【００３２】
また、映像制御部２４には、ビデオＲＡＭ２２、映像再生装置２３および表示装置２５が接続されており、これらビデオＲＡＭ２２や映像再生装置２３から出力される映像信号と歌詞情報に基づき、歌詞を歌詞の背景映像にスーパーインポーズして出力し、表示装置２５に表示させる。
【００３３】
以上のように構成されているカラオケ装置１においては、操作パネル１４を介して入力、あるいはリモコン送信機１５から送信された選曲番号をリモコン受信機１６にて受信、という形で利用者からカラオケ演奏曲を選択するための選曲番号の入力がなされると、ハードディスク１３から取得したカラオケ演奏用のデータを用いて、カラオケ演奏を実行する。そして、利用者が、表示装置２５に表示される歌詞を参照しながら、スピーカ２０より流れる演奏にあわせて、マイクロフォン２１を使って歌を歌うことができる、つまりカラオケを楽しむことができるようになっている。なお、上述のように、スレーブとして機能するカラオケ装置１は、公衆回線４０を介して配信用ホスト装置５０に接続する機能を有さないだけで他の構成は基本的にマスタとして機能するカラオケ装置１と同じである。
【００３４】
［ハードディスク１３におけるデータの記憶について］
ハードディスク１３内には、上述のように「提供情報」としての音楽情報や画像情報やカラオケ演奏プログラム等が記憶されているが、この中にはカラオケ演奏用の楽曲データと背景画データが存在し、これらは、図５に示すような階層構造で記憶されている。
【００３５】
ハードディスク１３内部は、固定サイズのブロックとして分割されており、各ブロックには論理ブロックアドレス（ＬＢＡ）と呼ばれるアドレスを指定することによって読み出し、書き込みのアクセスが可能となっている。これらのブロックの集合は、図２に示すような５つの領域に分割されている。具体的には、ファイル又はディレクトリの実データを記憶する実データ領域、実データ領域内のブロックの使用／未使用状況を管理する実データブロック管理領域、実データブロック内に記憶されたデータをファイル名と連結するインデックスブロック領域、実データブロックと同様にインデックスブロック領域内のブロックの使用／未使用状況を管理するインデックスブロック管理領域、ディスク内の全ファイルへのアクセスの起点としてのルートディレクトリインデックスブロックの５つの領域である。そして、これら５つの領域に分割してハードディスク１３内のデータの読み出し、書き込みアクセスを実現する。
【００３６】
ここで、インデックスブロックは図３に示すような構成となっており、各インデックスブロックは、そのインデックスブロックが管理する実データがディレクトリであるのか、ファイルであるのかを示す種別、実データのサイズ、実データが分割されている実データブロック群の総数、実データブロック群の先頭ＬＢＡと連続するブロック数をそれぞれ記憶するものでる。
【００３７】
ルートディレクトリを含むすべてのディレクトリは、図４に示すような構成の特殊なファイルとして保持される。ディレクトリ内部にはディレクトリに含まれるファイル及びサブディレクトリの名称と、それらを管理するインデックスブロックのＬＢＡのリストが記憶され、ファイルアクセス管理においては、アプリケーションプログラムからのファイルアクセス要求があった際に、ルートディレクトリから指定されたファイル等に向かって、順に検索を行い、読み出したインデックスブロックＬＢＡを元に再起的に検索を繰り返すことによって指定されたファイル等に対応するインデックスブロックＬＢＡを読み出した上で、実データへのアクセスを実現する。なお、このインデックスブロックが「インデックス情報」に相当し、インデックスブロックＬＢＡが「位置情報」に相当する。
【００３８】
図５はハードディスク１３に記憶されているファイルのディレクトリ構成を示したものであり、ルートディレクトリ下にｍｕｓｉｃ，ｖｉｄｅｏ，ｐｒｏｇｒａｍの３つのディレクトリが存在し、それぞれ楽曲データ、背景動画データ、カラオケ装置駆動用のプログラムファイルが記憶されている。
【００３９】
まず、ｍｕｓｉｃディレクトリ下には、０，１０００，２０００の３つのディレクトリが存在し、それぞれ選曲番号０番から９９９番までの楽曲データ、１０００番から１９９９番までの楽曲データ、２０００番から２９９９番までの楽曲データが分割して記憶されている。このように分割するのは単一ディレクトリ下のファイル数を減らし、ディレクトリから各ファイルを検索する際のスピードを向上することを目的としている。
【００４０】
また、ｖｉｄｅｏディレクトリも同様に、０，１０００の２つのディレクトリに分割されている。これらのディレクトリと同時に各楽曲に対してどの背景動画ファイルを再生するべきかを記録したｖｉｄｅｏ．ｉｄｘファイルも記憶されており、カラオケ演奏時にはカラオケ装置１はまず楽曲データを読み出し、次にｖｉｄｅｏ．ｉｄｘを読み出して、選曲番号に対応する背景動画ファイル名を検索して、検索の結果選択された背景動画ファイルを再生する。
【００４１】
また、ｐｒｏｇｒａｍディレクトリには、カラオケ装置１駆動用のプログラムファイルａｐｐｌｉ．ｅｘｅが記憶されており、カラオケ装置１は、起動時に自動的にこのファイルを読み出し、機器としての動作を開始する。
ここで、まず従来のキャッシュ手法によってキャッシュを実現した際の動作を説明する。
【００４２】
ＲＡＭ１１ａ上にキャッシュ領域として固定領域を確保し、「検索結果」としてのキャッシュ情報を記憶することによってキャッシュを実現する。このキャッシュ情報は、ファイル名とインデックスブロックＬＢＡ、ディレクトリ名とインデックスブロックＬＢＡ、ファイル名と所属ディレクトリ名とインデックスブロックＬＢＡのいずれかの組である。
【００４３】
図１１は、ファイル又はディレクトリへのアクセスが要求された際の動作を示すフローチャートである。
まず、キャッシュ上から要求されたファイル又はディレクトリに最も近い（最も深い階層の）ディレクトリのインデックス情報を検索する（Ｓ１１０）。そして、キャッシュ上にアクセスを指示されたファイル又はディレクトリに対応するインデックスブロックＬＢＡが記憶されていれば（Ｓ１２０：はい）、そのアドレスからインデックスブロックを読み出してファイル又はディレクトリのアクセスを開始する（Ｓ１５０）。このとき、インデックスブロックを読み出すまでにハードディスク１３に対するアクセスは行われず、一般にＲＡＭ１１ａはハードディスク１３に対してアクセス速度が十分早いため、ファイルアクセス開始までの時間は非常に短いものとなる。
【００４４】
一方、指示されたファイル又はディレクトリに対応するインデックスブロックＬＢＡがキャッシュから得られなかった場合には（Ｓ１２０：いいえ）、キャッシュ検索で得られた最も深いディレクトリのインデックスブロックを読み出し、その中に記憶されているファイル又はディレクトリを再帰的に検索することで目的のファイル又はディレクトリを検索し（Ｓ１３０）、目的のファイル又はディレクトリが見つかれば（Ｓ１４０：はい）、インデックスブロックを読み出して実アクセスを開始する（Ｓ１５０）。この場合もキャッシュ上に一部のディレクトリのインデックス情報が存在していればそこまでのハードディスク１３に対するアクセスが省略できるため、ファイルアクセス開始までの時間を短縮することが可能である。
【００４５】
なお、ハードディスク１３の検索（Ｓ１３０）の結果、指示されたファイル又はディレクトリが発見できなければ（Ｓ１４０：いいえ）、指示されたファイル又はディレクトリは存在しないものとしてエラー終了する（Ｓ１６０）。
図１２はキャッシュ内の検索の手順を示すフローチャートである。
【００４６】
キャッシュ内において、指示されたファイル又はディレクトリ名をインクリメンタルに検索し（Ｓ２１０，Ｓ２４０）、キャッシュ上に該当するファイル又はディレクトリ名が存在すれば（Ｓ２１０：はい）、該当するキャッシュ情報を最も新規に参照したキャッシュ情報として登録し直し（Ｓ２２０）、その発見したファイル又はディレクトリ名と、それに対応するインデックスブロックＬＢＡを（図１１に示された呼び出し元ルーチンへ）返す（Ｓ２３０）。
【００４７】
一方、指示されたファイル又はディレクトリ名がキャッシュ上に存在しなければ（Ｓ２４０：はい）、その親ディレクトリに対して同様の処理を再帰的に繰り返し（Ｓ２６０）、キャッシュ上に情報が存在すればその時点で発見したファイル又はディレクトリ名と、それに対応するＬＢＡを返す（Ｓ２３０）。
【００４８】
そして、ルートディレクトリ直下のファイル又はディレクトリに対して検索を行ったにもかかわらずキャッシュ情報が発見できなければ（Ｓ２５０：はい）、キャッシュ検索に失敗したものとして、ルートディレクトリ名とそれに対応するインデックスブロックＬＢＡを返す（Ｓ２７０）。
【００４９】
図１３は、ハードディスク１３上のディレクトリに対して実際にファイル又はサブディレクトリを検索する手順を示すフローチャートである。
まず、キャッシュの検索によって得られたディレクトリ内の実データを読み出し、検索対象のファイル又はディレクトリ名を検索し、その結果、発見できれば、ファイル又はディレクトリ名とインデックスブロックＬＢＡを最も新規に参照した情報としてキャッシュに登録する動作を、最終的に指示されたファイルのインデックスブロックＬＢＡが発見できるまで繰り返す（Ｓ３１０〜Ｓ３４０）。最終的に指示されたファイルのインデックスブロックＬＢＡが発見できた場合には（Ｓ３３０：はい）、その発見したファイル又はディレクトリ名とインデックスブロックＬＢＡを返す（Ｓ３５０）。一方、ディレクトリ末尾まで検索したにもかかわらず、検索対象のファイル又はディレクトリ、またはその親ディレクトリが存在しない場合には（Ｓ３６０：はい）、指定されたファイル又はディレクトリが存在しないものとして終了する（Ｓ３７０）。
【００５０】
図１４はキャッシュに情報を追加する際の手順を示すフローチャートである。
キャッシュに新規にキャッシュ情報（検索結果）を登録しようとした場合にキャッシュが一杯であれば、キャッシュ内において最も長い時間参照されていないキャッシュ情報を削除した上で、新規にキャッシュ情報を記録する。
【００５１】
これらの手法を採った際のキャッシュの内部状態の遷移を図６〜図９を参照して説明する。ここでは、一例として、カラオケ装置１で選曲番号１、２、３、１０００の順に楽曲を演奏した場合を考える。これらの楽曲にはそれぞれ、映像番号０、１、２、１０００の背景映像が割り当てられているものとする。
【００５２】
まずは図６の遷移状態について説明する。
利用者から選曲番号１の曲がリクエストされる（Ｐ１）と、カラオケ装置１は選曲番号から楽曲ファイル名に変換し、／ｍｕｓｉｃ／０／０００１．ＭＩＤを読み出そうとする。このときキャッシュが空であるものと仮定すると、キャッシュ上からは何ら情報は得られず、ルートディレクトリから順に検索することになる。ここでルートディレクトリのインデックスブロックを読み出し、その内容からｍｕｓｉｃディレクトリを検索する。その結果、ルートディレクトリからｍｕｓｉｃディレクトリが発見され（Ｐ２）、キャッシュ上に／ｍｕｓｉｃの情報が記録される。同様に／ｍｕｓｉｃ／０（Ｐ３），／ｍｕｓｉｃ／０／０００１．ＭＩＤ（Ｐ４）に対して再帰的に検索が行われ、その結果がキャッシュに格納されていく。
【００５３】
楽曲ファイルが読み出せると、カラオケ装置１は／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘを読み出し、選曲番号１の曲に割り当てられた背景動画の映像番号を取得する。このとき、キャッシュには有効なデータが存在しないので、ルートディレクトリから再帰的に／ｖｉｄｅｏ（Ｐ５），／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘ（Ｐ６）が検索され、楽曲ファイルの検索と同様にキャッシュが更新されていく。
【００５４】
この／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘを読み出した結果、選曲番号１の楽曲には映像番号０の背景動画が割り当てられていることが判明し、カラオケ装置１は続いて／ｖｉｄｅｏ／００００．ＭＰ２を読み出そうとする。このとき、／ｖｉｄｅｏディレクトリに対するインデックスブロックＬＢＡはすでにＰ５でキャッシュされているため、このキャッシュ情報が最も新規に参照された情報として移動する（Ｐ７）。一方、／ｖｉｄｅｏ／０（Ｐ８），／ｖｉｄｅｏ／０／００００．ＭＰ２（Ｐ９）はキャッシュに存在しないため、既出のようにキャッシュが更新されていく。
【００５５】
次に図７の遷移状態について説明する。
これは図６を参照して説明した選曲番号１の曲の演奏が終了し、選曲番号２の曲が選曲された時の動作を示す。
選曲番号２に対応する楽曲ファイル／ｍｕｓｉｃ／０／０００２．ＭＩＤを読み出す際においては、すでに／ｍｕｓｉｃ／０ディレクトリのインデックスブロックＬＢＡはキャッシュされている（キャッシュヒット）ため、楽曲ファイル／ｍｕｓｉｃ／０／０００２．ＭＩＤに対する検索が行われた時点（Ｐ１１）で、図６に示すＰ７で／ｖｉｄｅｏディレクトリに対して処理したのと同様に、／ｍｕｓｉｃ／０ディレクトリのキャッシュ情報が最も新規に参照したものとなる。続いて楽曲ファイル／ｍｕｓｉｃ／０／０００２．ＭＩＤを／ｍｕｓｉｃ／０ディレクトリから検索し（Ｐ１２）、この情報がキャッシュに追加される。続いて／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘ（Ｐ１３）及び／ｖｉｄｅｏ／０（Ｐ１４）がキャッシュヒットする。実際にディレクトリを読み出して検索する（キャッシュミス）のは、／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘを読み出した結果、選曲番号２の楽曲に割り当てられていることが判明した映像番号１の背景動画ファイル／ｖｉｄｅｏ／０／０００１．ＭＰ２のインデックスブロックＬＢＡだけ（Ｐ１５）である。
【００５６】
次に図８の遷移状態について説明する。
これは図７を参照して説明した選曲番号２の曲の演奏が終了し、選曲番号３の曲が選曲された時の動作を示す。
選曲番号３番の曲がリクエストされた場合には、同様に／ｍｕｓｉｃ／０（Ｐ２１）、／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘ（Ｐ２３）、／ｖｉｄｅｏ／０（Ｐ２４）でキャッシュヒット、／ｍｕｓｉｃ／０／０００３．ＭＩＤ（Ｐ２２）、／ｖｉｄｅｏ／０／０００２．ＭＰ２（Ｐ２５）でキャッシュミスが起こる。ここで、Ｐ２５でキャッシュミスが起こったとき、新規にキャッシュ情報の追加が発生するが、この時点ですでにキャッシュ領域は一杯であるため、最も長い間参照されていない／ｍｕｓｉｃのキャッシュ情報が削除される（キャッシュアウト）。
【００５７】
図９は、図８に示した／ｍｕｓｉｃのキャッシュ情報の削除（キャッシュアウト）によって、次に選曲番号１０００が選曲された場合のファイルアクセス効率が低下する様子を示したものである。
カラオケ装置１は選曲番号１０００のリクエストを受けると、キャッシュの中を検索するしかし、図８に示すＰ２５において／ｍｕｓｉｃがキャッシュアウトされてしまったため、キャッシュ内に有効な情報を発見できず、ルートディレクトリから／ｍｕｓｉｃを検索することから開始しなければならない（Ｐ３１）。また、その／ｍｕｓｉｃに続いて／ｍｕｓｉｃ／１０００を検索した時点（Ｐ３２）でキャッシュに保存されたうちで最も長い間参照されていない／ｖｉｄｅｏがキャッシュアウトする。この直後に／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘはキャッシュヒット（Ｐ３４）するが、選曲番号１０００の曲に割り当てられた背景動画／ｖｉｄｅｏ／１０００／１０００．ＭＰ２を検索する際（Ｐ３５）に、Ｐ３２の時点で／ｖｉｄｅｏがキャッシュアウトしてしまったため、やはり再度ルートディレクトリから／ｖｉｄｅｏを検索することから始めなければならない。
【００５８】
上述のように、選曲番号１の曲を演奏する際にはキャッシュが空であるため、また選曲番号１０００の曲を演奏する際には／ｖｉｄｅｏ，／ｍｕｓｉｃがキャッシュアウトしてしまったため、それぞれ楽曲の再生開始のレスポンスが低下していることがわかる。これは従来技術の問題点として挙げたように、一般的なキャッシュでは、実検索が１度行われた時点でキャッシングが行われるため、装置起動直後には利用者の指示を受けてから必ずインデックス情報の実検索が行われることと、キャッシュアウトに際して各ファイル又はディレクトリのシステム全体から見た意味的な重みは一切考慮されず、すべてが同等なものとして扱われていることが原因である。
【００５９】
このような問題を解決するために本実施例では、以下のようなキャッシングを行う。
本実施例におけるキャッシュ手法においては、まず、キャッシュとして機能する「第二の記憶手段」としてのＲＡＭ１１ａを第一の記憶領域と第二の記憶領域に２分割し、第一の記憶領域（以下、第一キャッシュと称す。）には、アクセスレスポンスの向上の必要性が高いと予想されるファイル又はディレクトリのインデックスブロックＬＢＡを、カラオケ装置１の起動時に予め固定的に記憶させる。そして、第二の記憶領域（以下、第二一キャッシュと称す。）については従来のキャッシュと同様の役割を与え、上記アクセスレスポンスの向上の必要性が高いと予想されるファイル又はディレクトリ以外のファイル又はディレクトリのインデックスブロックＬＢＡについて、図１２を参照して説明した従来手法と同様の手法によってキャッシュする。
【００６０】
まず、カラオケ装置１の起動時において、ハードディスク１３内の／ｐｒｏｇｒａｍディレクトリ内に記憶されている「特定情報」としてのｃａｃｈｅ．ｌｓｔファイルを読み出し、そのファイル中にリストされたファイル又はディレクトリ名（図１６参照）に対応するインデックスブロックを予め検索し、第一キャッシュにその検索結果、すなわちファイル又はディレクトリ名とインデックスブロックＬＢＡとの組を記録しておく。
【００６１】
そして、その後の処理においては、図１１〜図１４を参照して説明した処理の内、図１２のフローチャートに示す処理に代えて図１５のフローチャートに示すキャッシュ検索処理を実行する。
キャッシュ検索処理が開始すると、まず、第二キャッシュ内において、指示されたファイル又はディレクトリ名をインクリメンタルに検索し（Ｓ１２１０，Ｓ１２４０）、キャッシュ上に該当するファイル又はディレクトリ名が存在すれば（Ｓ１２１０：はい）、該当するキャッシュ情報を最も新規に参照したキャッシュ情報として第二キャッシュに登録し直し（Ｓ１２２０）、その発見したファイル又はディレクトリ名と、それに対応するインデックスブロックＬＢＡを返す（Ｓ１２３０）。ここまでの処理は、図１２で説明した従来のキャッシュ検索処理と同様である。
【００６２】
一方、指示されたファイル又はディレクトリ名が第二キャッシュ上に存在しなければ（Ｓ１２４０：はい）、第一キャッシュに対して同様の検索、すなわち指示されたファイル又はディレクトリ名をインクリメンタルに検索し（Ｓ１２５０，Ｓ１２６０）、この検索によって第一キャッシュ上に該当するファイル又はディレクトリ名が存在すれば（Ｓ１２５０：はい）、その発見したファイル又はディレクトリ名と、それに対応するインデックスブロックＬＢＡを返す（Ｓ１２３０）。しかし、上記第二キャッシュに対して行ったようなキャッシュ情報の更新（Ｓ１２２０）は実行しない。
【００６３】
そして、指示されたファイル又はディレクトリ名が第一キャッシュ上にも存在しなければ（Ｓ１２６０：はい）、ルートディレクトリ直下のファイル又はディレクトリに対する検索か否か判断し（Ｓ１２７０）、そうでなければ（Ｓ１２７０：いいえ）、その親ディレクトリに対して同様の処理を再帰的に繰り返す（Ｓ２８０）。
【００６４】
第一キャッシュ上に情報が存在すればその時点で発見したファイル又はディレクトリ名と、それに対応するＬＢＡを返す（Ｓ１２３０）。
そして、ルートディレクトリ直下のファイル又はディレクトリに対して検索を行ったにもかかわらずキャッシュ情報が発見できなければ（Ｓ１２７０：はい）、キャッシュ検索に失敗したものとして、ルートディレクトリ名とそれに対応するインデックスブロックＬＢＡを返す（Ｓ１２９０）。
【００６５】
このように、第一キャッシュに対しては、アクセスレスポンスの向上の必要性が高いと予想されるファイル又はディレクトリのインデックスブロックＬＢＡを、カラオケ装置１の起動時に予め固定的に記憶させておき、装置起動中はキャッシュ情報の更新を行わない。一方、第二キャッシュに関しては、従来通りキャッシュ情報の更新を行いながらキャッシングしていく。そして、図１５に示すようなキャッシュ検索を実行することによって、ファイルアクセスのレスポンスが向上する。この点を、具体例を参照して説明する。
【００６６】
上述例と同様、カラオケ装置１で選曲番号１、２、３、１０００の順に楽曲を演奏した場合のキャッシュ（第一キャッシュ及び第二キャッシュ）の内部状態の遷移を図１０を参照して説明する。
カラオケ装置１の起動時において、ハードディスク１３内の／ｐｒｏｇｒａｍディレクトリ内に記憶されているｃａｃｈｅ．ｌｓｔファイルが読み出され、そのファイル中にリストされたファイル又はディレクトリ名（図１６参照）に対応するインデックスブロックが予め検索され、図１０の左上に示すように、本実施例の第一キャッシュには、その検索結果、すなわちファイル又はディレクトリ名とインデックスブロックＬＢＡとの組が記録される。また、第二キャッシュには、第一キャッシュへのキャッシュ情報を検索する際に得られた／ｍｕｓｉｃと／ｖｉｄｅｏがキャッシュされている。
【００６７】
この状態で、選曲番号１の曲が選曲されると、第一キャッシュから／ｍｕｓｉｃ／０のインデックスブロックＬＢＡを得ることができ、いまだキャッシュされていない楽曲ファイル／ｍｕｓｉｃ／０／０００１．ＭＩＤを検索する（Ｑ１）のみで所望の楽曲ファイルを読み出すことができる。また、背景映像の割り当てについても、／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘファイルは第一キャッシュに予めキャッシュされているため、ハードディスク１３へのアクセス無しにそのインデックスブロックにアクセスが可能である。その後、選曲番号１の曲に割り当てられた背景動画ファイル／ｖｉｄｅｏ／０／００００．ＭＰ２を読み出す際にも、やはり第一キャッシュに／ｖｉｄｅｏ／０のインデックスブロックＬＢＡがキャッシュされているため、背景動画ファイル／ｖｉｄｅｏ／０／００００．ＭＰ２を／ｖｉｄｅｏ／０ディレクトリから検索する（Ｑ２）のみで背景動画ファイルにアクセスすることができる。
【００６８】
以下同様に、第一キャッシュの情報を利用して、楽曲ファイル、背景動画ファイルを直接検索するのみで楽曲の再生が可能となる。
本実施例のカラオケ装置１によれば次のような効果が得られる。
（ａ）カラオケ装置１の起動時において、ハードディスク１３内の／ｐｒｏｇｒａｍディレクトリ内に記憶されているｃａｃｈｅ．ｌｓｔファイルが読み出され、そのファイル中にリストされたファイル又はディレクトリ名（図１６参照）に対応するインデックスブロックが予め検索され、第一キャッシュにその検索結果、すなわちファイル又はディレクトリ名とインデックスブロックＬＢＡとの組が記録される。そのため、該当するファイル又はディレクトリにアクセスする際のレスポンスが向上する。例えば図９を参照して説明したように、従来のキャッシュ手法によるとキャッシュアウトによってレスポンスの遅延していた選曲番号１０００の楽曲の演奏においても、本実施例のキャッシュ手法であれば、図１０に示すように、楽曲ファイルの検索（Ｑ７）、背景動画ファイルの検索（Ｑ８）のみで演奏が実現でき、従来手法よりも安定して高速に楽曲の演奏が開始できることがわかる。なお、従来手法では図８に示すように例えば／ｍｕｓｉｃがキャッシュアウトされてしまっているが、カラオケ装置１においてはリクエストされたカラオケ曲を演奏する処理の度にこのディレクトリ／ｍｕｓｉｃはアクセスしなくてはならない。したがって、このようなディレクトリがキャッシュアウトされてしまうことはアクセスレスポンス向上の点で非常にデメリットとなる。そして、逆に本実施例ではカラオケ演奏の度にアクセスされるファイルの所属するディレクトリに関しては第一キャッシュに常駐しているため、非常に効果的である。
【００６９】
そして、この第一キャッシュ内のキャッシュ情報は、カラオケ装置１が稼働している間中保持され続けるため、上述したアクセスレスポンスの向上という効果が継続して得られる。
また、第二キャッシュには、従来通り、例えばＬＲＵ（Ｌｅａｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ）アルゴリズムなどの手法でキャッシュアウトした上で、その消去によって空いた記憶領域に新規のキャッシュ情報を記憶している。そのため、新規なキャッシュ情報（検索結果）については従来通りキャッシュしておくことができ、最近使用したファイルに対するアクセスレスポンスはやはり向上する。
【００７０】
（ｂ）本実施例では、第一キャッシュに常駐させておくキャッシュ情報を、ハードディスク１３内に記憶された／ｐｒｏｇｒａｍ／ｃａｃｈｅ．ｌｓｔファイルに基づいて決定している。したがって、例えばこのファイルの更新情報を公衆回線４０を経由して配信用ホスト装置５０から送信し、それに基づいて書き換えることによって、第一キャッシュに常駐させておくキャッシュ情報を変更することも可能である。例えば、使用頻度の高い楽曲のみの背景動画割り当て情報を記録したインデックスファイル／ｖｉｄｅｏ／ｖｉｄｅｏ＿ｈｉｇｈ．ｉｄｘを用いて楽曲番号から背景動画の検索を高速化するような場合には、前記ファイルを配信用ホスト装置５０にて新規に作成してカラオケ装置１に配信し、／ｐｒｏｇｒａｍ／ｃａｃｈｅ．ｌｓｔを上書きすればよい。
【００７１】
例えばカラオケ装置１の機種によっては提供できる機能が違っていたり、あるいは同じ機種であっても利用者層が違ったりして、アクセスレスポンスの向上の必要性が高いファイル又はディレクトリには違いがある可能性ある。したがって、このように配信用ホスト装置５０からの配信情報に基づいて／ｐｒｏｇｒａｍ／ｃａｃｈｅ．ｌｓｔの内容を変更できるようにすれば、第一キャッシュ内のキャッシュ情報をカラオケ装置１毎の状況に応じた適切なものとすることが可能である。
【００７２】
［その他の実施例］
（１）上記実施例では、アクセスレスポンスの向上の必要性の高低について、ハードディスク１３内のァイル又はディレクトリのアクセス頻度の高低に基づいて決定した例を説明した。図１６に示すようなファイル又はディレクトリはそのような観点で決定したものである。しかし、アクセスレスポンスの向上の必要性の高低については、他の観点を加味することもできる。例えば緊急性という観点を加味してもよい。例えばカラオケ装置１の利用者に対して「ただいま検索中」とか、「少しお待ち下さい」といったガイダンスを表示するような場合、このガイダンスが早めに出ないと利用者としては故障なのか何なのかが分からないため、極力早いほうがよいからである。このようなガイダンスは、たとえ使用頻度が相対的に低くても、アクセスレスポンスの向上の必要性は高い。
【００７３】
（２）上記実施例では、カラオケ装置１での実現例を示しているが、例えばビデオサーバのように、自身で情報を解釈再生する機能を持たず、ネットワーク上で接続されたクライアントからの要求に応じて情報ファイルをネットワーク経由で送信（出力）するようなものであってもよい。
【図面の簡単な説明】
【図１】実施例のカラオケ装置の概略構成を示すブロック図である。
【図２】実施例のカラオケ装置におけるハードディスク内部の構成を示す概念図である。
【図３】インデックスブロックの構成を示す概念図である。
【図４】ディレクトリのデータ構造を示す概念図である。
【図５】実施例のハードディスク内のディレクトリ構成を示す概念図である。
【図６】実施例のカラオケ装置において楽曲の演奏が行われた際に、従来のキャッシュ手法によるキャッシュの状態の変化を示す遷移図である。
【図７】実施例のカラオケ装置において楽曲の演奏が行われた際に、従来のキャッシュ手法によるキャッシュの状態の変化を示す遷移図である。
【図８】実施例のカラオケ装置において楽曲の演奏が行われた際に、従来のキャッシュ手法によるキャッシュの状態の変化を示す遷移図である。
【図９】実施例のカラオケ装置において楽曲の演奏が行われた際に、従来のキャッシュ手法によるキャッシュの状態の変化を示す遷移図である。
【図１０】実施例のカラオケ装置において楽曲の演奏が行われた際に、本実施例のキャッシュ手法による第一キャッシュ及び第二キャッシュの状態の変化を示す遷移図である。
【図１１】実施例のカラオケ装置においてファイルの検索を行う手順を示すフローチャートである。
【図１２】従来のキャッシュ手法によってキャッシュ内から情報を読み出す手順を示すフローチャートである。
【図１３】実施例のカラオケ装置においてハードディスク上のディレクトリ内からインデックスブロック情報を検索する手順を示すフローチャートである。
【図１４】実施例のカラオケ装置においてキャッシュに情報を挿入する手順を示すフローチャートである。
【図１５】実施例のカラオケ装置において第一キャッシュ及び第二キャッシュから情報を読み出す手順を示すフローチャートである。
【図１６】実施例のカラオケ装置１の第一キャッシュに予めキャッシュするファイル又はディレクトリのリストである／ｐｒｏｇｒａｍ／ｃａｃｈｅ．ｌｓｔファイルの構成を示す概念図である。
【符号の説明】
１…カラオケ装置、１１…中央処理装置、１１ａ…ＲＡＭ、１２…通信制御装置、１３…ハードディスク、１４…操作パネル、１５…リモコン送信機、１６…リモコン受信機、１７…操作制御部、１８…シンセサイザ、１９…ミキシングアンプ、２０…スピーカ、２１…マイクロフォン、２２…ビデオＲＡＭ、２３…映像再生装置、２４…映像制御部、２５…表示装置、３０…店舗内ネットワーク、４０…公衆回線、５０…配信用ホスト装置。
【発明の属する技術分野】
本発明は、情報提供装置におけるファイルアクセス管理方法等に関する。
【０００２】
【従来の技術】
従来より、例えば映像や音声、文字情報などから構成される提供情報を複数蓄積し、利用者の要求に応じてこれら蓄積された提供情報から一部を選択した上で再生等して利用者に提供する情報提供装置が知られている。そして、このような提供情報は例えばハードディスク等に記憶されるのであるが、このハードディスク内において、任意に設定されたファイル単位で管理されることが多い。このようなファイルを管理する仕組みはファイルシステムと称され、このようなファイルシステムにおいては、各種の情報をファイルとして記憶するのみでなく、ディレクトリと呼ばれる仮想的な階層構造を作成し、ファイルの検索の高速化や設計の容易化を図るものが一般的である。
【０００３】
また、ファイル又はディレクトリは、その実データをハードディスク等の記憶装置に記憶すると同時に、ファイルシステムでの管理のため、実データの記憶装置上での記憶位置やそのアクセス許可属性など付加的な情報（インデックス情報）を同時に記憶する。通常これらのインデックス情報は実データとは別に記憶され、その上でファイルシステムはアプリケーションプログラムからファイル又はディレクトリ名称による検索要求を受けて、その名称を元にインデックス情報を記憶装置から検索し、発見したインデックス情報を読み出した上で、アプリケーションプログラムにファイルデータへのアクセスを行う。
【０００４】
ここで、インデックス情報の検索成功時に、その検索結果、すなわちファイル名と対応するインデックス情報の記憶装置上での位置情報（以下、単に位置情報と称す。）の組、又はディレクトリ名と位置情報との組、若しくはファイル名及び所属するディレクトリ名と位置情報との組を、ハードディスク等の記憶装置よりも高速読み出しが可能な、例えばＲＡＭのような、ハードディスクに対して高速アクセス可能なメモリに一時記憶しておくこと（キャッシング）が一般的に行われている（例えば、特許文献１参照。）。すなわち、ある名称でインデックス情報を検索した後に、再度同一の名称での検索が必要な場合には、実際にハードディスク等の記憶装置上で検索を行うのではなく、キャッシングされた情報（キャッシュ情報＝検索結果）をＲＡＭから読み出して見掛け上の検索処理時間を短縮するものである。
【０００５】
さらに、キャッシュ情報が無限に増大してしまうことを防ぐために、キャッシングするキャッシュ情報の総数に上限を設定し、この上限を超えてキャッシュ情報を記憶する必要が発生した場合には、例えばＬＲＵ（Ｌｅａｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ）アルゴリズムなどの手法で一部のキャッシュ情報を選択して消去（キャッシュアウト）した上で、その消去によって空いた記憶領域に新規のキャッシュ情報を記憶することも行われている。
【０００６】
【特許文献１】
特開平５−１０８４８０号公報
【０００７】
【発明が解決しようとする課題】
しかしながら、上記のようなキャッシング手法では、実検索が１度行われた時点でキャッシングが行われるため、装置起動直後には利用者の指示を受けてから必ずインデックス情報の実検索が行われる。すなわち、装置起動直後は装置が起動してある程度の時間を経た時点と比較して、全体的にファイルアクセスのレスポンスが遅い。
【０００８】
また、上記のようなキャッシング手法では、キャッシュアウトに際して各ファイル又はディレクトリのシステム全体から見た意味的な重みは一切考慮されず、すべてが同等なものとして扱われている。そのため、例えばめったに使用しないファイル又はディレクトリを使用した際に、使用頻度のより高いファイル又はディレクトリに関するキャッシュ情報がキャッシュアウトされてしまう。そのため、その後にキャッシュアウトされたファイル又はディレクトリにアクセスする際には、再度ハードディスク等の記憶装置上での実検索が必要となり、結果としてシステムの応答時間を低下させてしまうことがある。
【０００９】
これは、汎用的な情報処理装置ではなく、例えばカラオケ装置等のように、例えば提供情報としての音楽情報や映像情報等を用いて所定の情報提供を実行する装置の場合には、顕著になる。例えばカラオケ装置の場合であれば、音楽情報や映像情報は、カラオケ演奏という情報提供毎に毎回アクセスされる対象であり、このような情報に対応するファイル又はディレクトリに関するキャッシュ情報がキャッシュアウトされてしまうことは、カラオケ演奏処理についての応答時間を悪くする要因となる。そして、このようなキャッシュアウトがカラオケ演奏毎に生じると、カラオケ演奏毎にハードディスク等の記憶装置上での実検索を行うこととなって、アクセスレスポンスが低下してしまう。
【００１０】
なお、このような問題は、カラオケ装置の場合に限らず、ビデオサーバやゲーム装置等であっても同様である。ハードディスク等の記憶手段に蓄積された多数の提供情報中から要求に応じたものを選択する場合には、上述したファイルアクセス時の問題が同様に生じるからである。
【００１１】
本発明は、上述した問題点を解決するためになされたものであり、情報提供装置におけるハードディスク等の記憶手段に記憶された提供情報ファイルへのアクセスレスポンスを向上させる技術を提供することを目的とする。
【００１２】
【課題を解決するための手段及び発明の効果】
（１）本発明のファイルアクセス管理装置は、少なくとも複数の提供情報を任意に設定されたファイル単位で記憶しておくための第一の記憶手段（実施例ではハードディスク１３）、第一の記憶手段よりも高速に読み書きが可能な第二の記憶手段（実施例ではＲＡＭ１１ａ）、提供情報の提供要求を受け付ける要求受付手段、要求受付手段によって受け付けた情報提供要求に応じた提供情報を用いて情報提供を実行する情報提供実行手段、を備える情報提供装置における第一の記憶手段に記憶された提供情報をアクセスするための管理装置である。
【００１３】
ここで、第一の記憶手段に記憶される提供情報については、当該提供情報に対応するファイル名又はディレクトリ構成で管理すると共に、ファイル名又は所属ディレクトリ名とファイル名を指定することによって該当する提供情報に対するアクセスを可能とするインデックス情報（実施例ではインデックスブロック）が、ファイル又はディレクトリ毎に記憶されている。また、第一の記憶手段内のファイル又はディレクトリを、アクセスレスポンスの向上の必要性の高低に基づいて予め２つ以上のグループに分けると共に、アクセスレスポンスの向上の必要性が高い第一のグループに属するファイル又はディレクトリを特定可能な特定情報（実施例ではｃａｃｈｅ．ｌｓｔファイル）を第一の記憶手段に記憶している。
【００１４】
そして、第一のキャッシュ処理手段が次のような処理を実行する。つまり、情報提供装置の起動時に前記特定情報を読み出し、その読み出した特定情報によって特定されるファイル又はディレクトリのインデックス情報（実施例ではインデックスブロック）が記憶されている第一の記憶手段内の位置情報（実施例ではインデックスブロックＬＢＡ）について予め検索し、その検索結果を前記第二の記憶手段内の第一の記憶領域（実施例では第一キャッシュ）に記憶する。
【００１５】
一方、第二のキャッシュ処理手段は次のような処理を実行する。つまり、第一のグループ以外のグループに属するファイル又はディレクトリのインデックス情報が記憶されている第一の記憶手段内の位置情報については、提供要求が生じた場合に検索し、その検索結果を第二の記憶手段内の第二の記憶領域（実施例では第二キャッシュ）に記憶する。
【００１６】
そして、ファイルアクセス実行手段は 提供要求が生じた場合には、当該提供要求に対応するインデックス情報を第二の記憶手段内の第一の記憶領域及び第二の記憶領域から検索し、検索できた場合にはそのインデックス情報に基づいてファイルアクセスを実行する。
【００１７】
このようなファイルアクセスの管理をすることで、アクセスレスポンスの向上の必要性が高い第一のグループに属するファイル又はディレクトリについては、情報提供装置の起動直後にインデックス情報の位置情報が検索されてキャッシュされており、その位置情報を用いてアクセスできるため、ファイルアクセスのレスポンスが向上する。
【００１８】
なお、第一のキャッシュ処理手段は、提供情報をファイル名で管理する場合にはファイル名と位置情報の組を検索結果として記憶し、提供情報をディレクトリ構成で管理する場合には、ディレクトリ名と位置情報の組、又はファイル名と所属ディレクトリ名と位置情報の組を検索結果として記憶する（請求項２）。
【００１９】
（２）また、第一のキャッシュ処理手段によって第二の記憶手段内の第一の記憶領域に記憶された検索結果は、情報提供装置が稼働している間中、第二の記憶手段内の第一の記憶領域に保持し続けようにし、第二のキャッシュ処理手段は、検索結果に新規に記憶させようとした場合に、第二の記憶手段内の第二の記憶領域の記憶容量を超えるのであれば、既に記憶されている検索結果を削除してから記憶させるようにしてもよい（請求項３）。
【００２０】
このようにすれば、アクセスレスポンスの向上の必要性が高い第一のグループに属するファイル又はディレクトリに対応する検索結果を第二の記憶手段内に常駐させておくことができ、情報提供装置が稼働している間は常に、これら第一のグループに属するファイル、又は第一のグループに属するディレクトリに対するアクセスレスポンス、ひいては該ディレクトリに所属するファイルに対するアクセスレスポンスを向上させることができる。
一方、上述の第二のキャッシュ処理手段は、第二の記憶手段内の第二の記憶領域を所定の記憶容量内に保ちながら、新規な検索結果について記憶させることができるため、最近使用したファイルに対するアクセスレスポンスはやはり向上する。
【００２１】
（３）なお、アクセスレスポンスの向上の必要性の高低については、例えば請求項４に示すように、少なくとも第一の記憶手段内のファイル又はディレクトリのアクセス頻度の高低に基づいて決定することが考えられる。例えば請求項６に示すように、情報提供装置としてカラオケ装置を想定し、提供情報としてのカラオケ演奏データを用いてカラオケ演奏を実行する場合を考える。この場合であれば、例えば特定情報に、カラオケ演奏データに対応するファイル又はディレクトリを特定可能な情報を含めておく。例えば請求項７に示すように、カラオケ演奏データに楽曲データと背景画データとが含まれている場合には、特定情報には、楽曲データと背景画データそれぞれに対応するファイル又はディレクトリを特定可能な情報を含めておくことが考えられる。このようにすれば、楽曲データと背景画データに対応するファイル又はディレクトリに関する検索結果が常駐することとなって、キャッシュアウトされてしまうことがない。これらのデータはカラオケ演奏の度に毎回アクセスされるため、アクセスレスポンスが向上することは、非常に有効である。
【００２２】
もちろん、アクセスレスポンスの向上の必要性の高低については、他の観点を加味することもできる。例えば緊急性という観点を加味してもよい。例えば利用者に対して「ただいま検索中」とか、「少しお待ち下さい」といったガイダンスを表示等によって報知する場合、このようなガイダンスが早めに出ないと利用者としては故障なのか何なのかが分からないため、極力早いほうがよい。このようなガイダンスは、たとえ使用頻度が相対的に低くても、アクセスレスポンスの向上が希求されるものである。
【００２３】
（４）また、請求項５に示すように、情報提供装置が外部のホスト装置と通信するための通信手段を備え、通信手段を介してホスト装置から特定情報を受信可能に構成されているのであれば、その受信した特定情報を第一の記憶手段に記憶しておき、その第一の記憶手段に記憶された特定情報に基づいて第一のキャッシュ処理手段が検索等の処理を実行することが考えられる。このようにすれば、ホスト装置から送信する特定情報によって、第二の記憶手段の第一の記憶領域に常駐させておく検索結果を適宜更新することができる。例えばいわゆる通信カラオケシステムの場合には、ホスト装置からカラオケ装置に対して新曲データその他の情報を配信することとなるが、例えば配信する情報内容次第では、特定情報自体を変更した方がよい場合も想定される。その際、カラオケ装置（情報提供装置）側で逐次変更するのは不便である。また、どのような特定情報の内容にした方がよいのかは、提供情報を配信する側が最もよく知っていると思われる。したがって、配信側において配信内容等に基づいて最適と思われる特定情報をカラオケ装置（情報提供装置）に送信し、その送信された特定情報に基づいて、第一のキャッシュ処理手段が第二の記憶手段の第一の記憶領域に検索結果を記憶させれば、状況の変化に対応した最適な状態にすることが可能となり、情報提供装置全体としてのアクセスレスポンスの向上に寄与できる。
【００２４】
【発明の実施の形態】
以下、本発明が適用された実施例について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施例に何ら限定されることなく、本発明の技術的範囲に属する限り種々の形態を採りうる。
【００２５】
本実施例では、ファイルアクセス管理装置を備えた情報提供装置の一例としてのカラオケ装置について説明する。
［カラオケ装置１の説明］
図１は、実施例のカラオケ装置１の概略構成を示している。本実施例のカラオケ装置１は、カラオケ店舗に設置されており、例えばカラオケ店舗の各部屋にそれぞれ１台ずつ設置される。なお、これら複数台のカラオケ装置１は店舗内ネットワーク３０にて接続することによってネットワークシステムを構成している。そして、これら複数台のカラオケ装置１の内、何れか一つ（以上）のカラオケ装置１は、公衆回線を介して配信用ホスト装置５０に接続できるようになっており、この公衆回線４０を介して接続した配信用ホスト装置５０からカラオケに関する配信データ（「提供情報」としての音楽情報（楽曲データ）や画像情報（背景画データ）、あるいは例えばカラオケ演奏処理を実行するためのアプリケーションプログラム（カラオケ演奏プログラム）等）を取得して、「第一の記憶手段」としてのハードディスク１３へ記憶しておくことができる。このカラオケ装置１は、ハードディスク１３に記憶されている配信データを、店舗内ネットワーク３０によって接続された他のカラオケ装置１へ送信することができる。そのため、公衆回線４０を介して配信用ホスト装置５０と接続する機能を持つカラオケ装置１がマスタ（親機）となり、他のカラオケ装置１がスレーブ（子機）となっている。
【００２６】
マスタまたはスレーブとして機能するカラオケ装置１の基本的な構成はいずれも同じであるが、上述のように、マスタのみが公衆回線４０を介して配信用ホスト装置５０に接続できるようになっている。それ以外の機能は基本的にいずれも同じである。したがって、以下の構成説明に関しては、図１に示す（マスタとして機能する）カラオケ装置１に関して行うこととする。
【００２７】
カラオケ装置１は、図１に示すように、カラオケ装置１を制御するための中央処理装置１１、ネットワークとしての店舗内ネットワーク３０を介して他のカラオケ装置（この場合はスレーブ）と接続したり、公衆回線４０を介して配信用ホスト装置５０と接続し、各種の情報を送受信する通信制御装置１２、各種データ等を記憶しているハードディスク１３、曲の予約や電源のＯＮ・ＯＦＦなどを行うための操作パネル１４、操作パネル１４と同様に曲の予約等を行うためのリモコン送信機１５、リモコン送信機１５からの信号を受信するためのリモコン受信機１６、操作パネル１４やリモコン受信機１６からの信号を受け付けて処理する操作制御部１７、演奏の再生を行うシンセサイザ１８、音楽情報にかかる電気信号を増幅等するミキシングアンプ１９、ミキシングアンプ１９からの電気信号を入力して伴奏曲及び利用者の歌声等を流すスピーカ２０、利用者の歌声等をミキシングアンプ１９に入力するマイクロフォン２１、中央処理装置１１によって生成された歌詞情報を記憶するビデオＲＡＭ２２、画像情報等を再生する映像再生装置２３、ビデオＲＡＭ２２からの歌詞情報と映像再生装置２３からの映像信号とに基づき、歌詞及び歌詞の背景映像を出力する映像制御部２４、映像制御部２４から出力された歌詞及び歌詞の背景映像を表示する表示装置２５を備えている。また、このうちの中央処理装置１１には、通信制御装置１２、ハードディスク１３、操作制御部１７、シンセサイザ１８、ビデオＲＡＭ２２、映像再生装置２３及び映像制御部２４が接続されており、中央処理装置１１は、これらを介してカラオケ装置１を制御する。
【００２８】
続いて各部の具体的な構成を説明する。
まず、中央処理装置１１は、ＣＰＵ、ＲＯＭ（いずれも図示せず）、ＲＡＭ１１ａなどを備える周知の構成である。一方、ハードディスク１３は、中央処理装置１１がカラオケ装置１を制御するための各種プログラムを格納している。中央処理装置１１の備えるＣＰＵによって実行される複数のプログラムはＲＯＭ及びハードディスク１３に格納されており、ＣＰＵは該プログラムをＲＡＭ１１ａに展開しプログラムを実行することとなる。また、このＲＡＭ１１ａは、「第二の記憶手段」に相当し、いわゆる「キャッシュ」として機能する領域を有している。これらハードディスク１３におけるデータの記憶、及びＲＡＭ１１ａ内のキャッシュ領域におけるデータの記憶については後述する。なお、カラオケ装置１の中央処理装置１１は、情報提供実行手段、第一のキャッシュ処理手段、第二のキャッシュ処理手段、ファイルアクセス実行手段に相当する。
【００２９】
通信制御装置１２は、店舗内ネットワーク３０を介してカラオケ店舗内の他の部屋に設置されたカラオケ装置（この場合はスレーブ）に接続されており、これら他のカラオケ装置（この場合はスレーブ）との間で各種の情報を送受信する。また、カラオケ装置１の通信制御装置１２は、上述したように、公衆回線４０を介して配信用ホスト装置５０と接続し、この配信用ホスト装置５０との間で各種の情報を送受信する。
【００３０】
操作制御部１７には、操作パネル１４およびリモコン受信機１６が接続されている。このうち、操作パネル１４は、利用者がカラオケ曲の選択や演奏アレンジの切り替えを行ったりするためのものであり、「要求受付手段」に相当する。
利用者がこの操作パネル１４を操作すると、その入力操作の信号が操作制御部１７および中央処理装置１１に送られて処理される。一方、リモコン受信機１６は、リモコン送信機１５からの信号を受信するためのものである。また、このリモコン送信機１５は、操作パネル１４と同様に、利用者がカラオケ曲の選択や演奏アレンジの切り替えを行ったりするためのものである。利用者がこのリモコン送信機１５を操作すると、その入力操作の信号がリモコン受信機１６を介して操作制御部１７および中央処理装置１１に送られて処理される。
【００３１】
また、シンセサイザ１８には、ミキシングアンプ１９が接続され、このミキシングアンプ１９にはスピーカ２０が接続されている。ハードディスク１３等から読み出され、中央処理装置１１から供給される音楽情報（ＭＩＤＩ形式のカラオケ演奏データ）に基づいてシンセサイザ１８から出力される楽音信号はミキシングアンプ１９で増幅されてスピーカ２０から出力される。また、ミキシングアンプ１９には利用者の歌唱音声を入力するためのマイクロフォン２１が接続されており、このマイクロフォン２１によって入力された音声信号もシンセサイザ１８からの楽音信号と共にスピーカ２０から出力される。
【００３２】
また、映像制御部２４には、ビデオＲＡＭ２２、映像再生装置２３および表示装置２５が接続されており、これらビデオＲＡＭ２２や映像再生装置２３から出力される映像信号と歌詞情報に基づき、歌詞を歌詞の背景映像にスーパーインポーズして出力し、表示装置２５に表示させる。
【００３３】
以上のように構成されているカラオケ装置１においては、操作パネル１４を介して入力、あるいはリモコン送信機１５から送信された選曲番号をリモコン受信機１６にて受信、という形で利用者からカラオケ演奏曲を選択するための選曲番号の入力がなされると、ハードディスク１３から取得したカラオケ演奏用のデータを用いて、カラオケ演奏を実行する。そして、利用者が、表示装置２５に表示される歌詞を参照しながら、スピーカ２０より流れる演奏にあわせて、マイクロフォン２１を使って歌を歌うことができる、つまりカラオケを楽しむことができるようになっている。なお、上述のように、スレーブとして機能するカラオケ装置１は、公衆回線４０を介して配信用ホスト装置５０に接続する機能を有さないだけで他の構成は基本的にマスタとして機能するカラオケ装置１と同じである。
【００３４】
［ハードディスク１３におけるデータの記憶について］
ハードディスク１３内には、上述のように「提供情報」としての音楽情報や画像情報やカラオケ演奏プログラム等が記憶されているが、この中にはカラオケ演奏用の楽曲データと背景画データが存在し、これらは、図５に示すような階層構造で記憶されている。
【００３５】
ハードディスク１３内部は、固定サイズのブロックとして分割されており、各ブロックには論理ブロックアドレス（ＬＢＡ）と呼ばれるアドレスを指定することによって読み出し、書き込みのアクセスが可能となっている。これらのブロックの集合は、図２に示すような５つの領域に分割されている。具体的には、ファイル又はディレクトリの実データを記憶する実データ領域、実データ領域内のブロックの使用／未使用状況を管理する実データブロック管理領域、実データブロック内に記憶されたデータをファイル名と連結するインデックスブロック領域、実データブロックと同様にインデックスブロック領域内のブロックの使用／未使用状況を管理するインデックスブロック管理領域、ディスク内の全ファイルへのアクセスの起点としてのルートディレクトリインデックスブロックの５つの領域である。そして、これら５つの領域に分割してハードディスク１３内のデータの読み出し、書き込みアクセスを実現する。
【００３６】
ここで、インデックスブロックは図３に示すような構成となっており、各インデックスブロックは、そのインデックスブロックが管理する実データがディレクトリであるのか、ファイルであるのかを示す種別、実データのサイズ、実データが分割されている実データブロック群の総数、実データブロック群の先頭ＬＢＡと連続するブロック数をそれぞれ記憶するものでる。
【００３７】
ルートディレクトリを含むすべてのディレクトリは、図４に示すような構成の特殊なファイルとして保持される。ディレクトリ内部にはディレクトリに含まれるファイル及びサブディレクトリの名称と、それらを管理するインデックスブロックのＬＢＡのリストが記憶され、ファイルアクセス管理においては、アプリケーションプログラムからのファイルアクセス要求があった際に、ルートディレクトリから指定されたファイル等に向かって、順に検索を行い、読み出したインデックスブロックＬＢＡを元に再起的に検索を繰り返すことによって指定されたファイル等に対応するインデックスブロックＬＢＡを読み出した上で、実データへのアクセスを実現する。なお、このインデックスブロックが「インデックス情報」に相当し、インデックスブロックＬＢＡが「位置情報」に相当する。
【００３８】
図５はハードディスク１３に記憶されているファイルのディレクトリ構成を示したものであり、ルートディレクトリ下にｍｕｓｉｃ，ｖｉｄｅｏ，ｐｒｏｇｒａｍの３つのディレクトリが存在し、それぞれ楽曲データ、背景動画データ、カラオケ装置駆動用のプログラムファイルが記憶されている。
【００３９】
まず、ｍｕｓｉｃディレクトリ下には、０，１０００，２０００の３つのディレクトリが存在し、それぞれ選曲番号０番から９９９番までの楽曲データ、１０００番から１９９９番までの楽曲データ、２０００番から２９９９番までの楽曲データが分割して記憶されている。このように分割するのは単一ディレクトリ下のファイル数を減らし、ディレクトリから各ファイルを検索する際のスピードを向上することを目的としている。
【００４０】
また、ｖｉｄｅｏディレクトリも同様に、０，１０００の２つのディレクトリに分割されている。これらのディレクトリと同時に各楽曲に対してどの背景動画ファイルを再生するべきかを記録したｖｉｄｅｏ．ｉｄｘファイルも記憶されており、カラオケ演奏時にはカラオケ装置１はまず楽曲データを読み出し、次にｖｉｄｅｏ．ｉｄｘを読み出して、選曲番号に対応する背景動画ファイル名を検索して、検索の結果選択された背景動画ファイルを再生する。
【００４１】
また、ｐｒｏｇｒａｍディレクトリには、カラオケ装置１駆動用のプログラムファイルａｐｐｌｉ．ｅｘｅが記憶されており、カラオケ装置１は、起動時に自動的にこのファイルを読み出し、機器としての動作を開始する。
ここで、まず従来のキャッシュ手法によってキャッシュを実現した際の動作を説明する。
【００４２】
ＲＡＭ１１ａ上にキャッシュ領域として固定領域を確保し、「検索結果」としてのキャッシュ情報を記憶することによってキャッシュを実現する。このキャッシュ情報は、ファイル名とインデックスブロックＬＢＡ、ディレクトリ名とインデックスブロックＬＢＡ、ファイル名と所属ディレクトリ名とインデックスブロックＬＢＡのいずれかの組である。
【００４３】
図１１は、ファイル又はディレクトリへのアクセスが要求された際の動作を示すフローチャートである。
まず、キャッシュ上から要求されたファイル又はディレクトリに最も近い（最も深い階層の）ディレクトリのインデックス情報を検索する（Ｓ１１０）。そして、キャッシュ上にアクセスを指示されたファイル又はディレクトリに対応するインデックスブロックＬＢＡが記憶されていれば（Ｓ１２０：はい）、そのアドレスからインデックスブロックを読み出してファイル又はディレクトリのアクセスを開始する（Ｓ１５０）。このとき、インデックスブロックを読み出すまでにハードディスク１３に対するアクセスは行われず、一般にＲＡＭ１１ａはハードディスク１３に対してアクセス速度が十分早いため、ファイルアクセス開始までの時間は非常に短いものとなる。
【００４４】
一方、指示されたファイル又はディレクトリに対応するインデックスブロックＬＢＡがキャッシュから得られなかった場合には（Ｓ１２０：いいえ）、キャッシュ検索で得られた最も深いディレクトリのインデックスブロックを読み出し、その中に記憶されているファイル又はディレクトリを再帰的に検索することで目的のファイル又はディレクトリを検索し（Ｓ１３０）、目的のファイル又はディレクトリが見つかれば（Ｓ１４０：はい）、インデックスブロックを読み出して実アクセスを開始する（Ｓ１５０）。この場合もキャッシュ上に一部のディレクトリのインデックス情報が存在していればそこまでのハードディスク１３に対するアクセスが省略できるため、ファイルアクセス開始までの時間を短縮することが可能である。
【００４５】
なお、ハードディスク１３の検索（Ｓ１３０）の結果、指示されたファイル又はディレクトリが発見できなければ（Ｓ１４０：いいえ）、指示されたファイル又はディレクトリは存在しないものとしてエラー終了する（Ｓ１６０）。
図１２はキャッシュ内の検索の手順を示すフローチャートである。
【００４６】
キャッシュ内において、指示されたファイル又はディレクトリ名をインクリメンタルに検索し（Ｓ２１０，Ｓ２４０）、キャッシュ上に該当するファイル又はディレクトリ名が存在すれば（Ｓ２１０：はい）、該当するキャッシュ情報を最も新規に参照したキャッシュ情報として登録し直し（Ｓ２２０）、その発見したファイル又はディレクトリ名と、それに対応するインデックスブロックＬＢＡを（図１１に示された呼び出し元ルーチンへ）返す（Ｓ２３０）。
【００４７】
一方、指示されたファイル又はディレクトリ名がキャッシュ上に存在しなければ（Ｓ２４０：はい）、その親ディレクトリに対して同様の処理を再帰的に繰り返し（Ｓ２６０）、キャッシュ上に情報が存在すればその時点で発見したファイル又はディレクトリ名と、それに対応するＬＢＡを返す（Ｓ２３０）。
【００４８】
そして、ルートディレクトリ直下のファイル又はディレクトリに対して検索を行ったにもかかわらずキャッシュ情報が発見できなければ（Ｓ２５０：はい）、キャッシュ検索に失敗したものとして、ルートディレクトリ名とそれに対応するインデックスブロックＬＢＡを返す（Ｓ２７０）。
【００４９】
図１３は、ハードディスク１３上のディレクトリに対して実際にファイル又はサブディレクトリを検索する手順を示すフローチャートである。
まず、キャッシュの検索によって得られたディレクトリ内の実データを読み出し、検索対象のファイル又はディレクトリ名を検索し、その結果、発見できれば、ファイル又はディレクトリ名とインデックスブロックＬＢＡを最も新規に参照した情報としてキャッシュに登録する動作を、最終的に指示されたファイルのインデックスブロックＬＢＡが発見できるまで繰り返す（Ｓ３１０〜Ｓ３４０）。最終的に指示されたファイルのインデックスブロックＬＢＡが発見できた場合には（Ｓ３３０：はい）、その発見したファイル又はディレクトリ名とインデックスブロックＬＢＡを返す（Ｓ３５０）。一方、ディレクトリ末尾まで検索したにもかかわらず、検索対象のファイル又はディレクトリ、またはその親ディレクトリが存在しない場合には（Ｓ３６０：はい）、指定されたファイル又はディレクトリが存在しないものとして終了する（Ｓ３７０）。
【００５０】
図１４はキャッシュに情報を追加する際の手順を示すフローチャートである。
キャッシュに新規にキャッシュ情報（検索結果）を登録しようとした場合にキャッシュが一杯であれば、キャッシュ内において最も長い時間参照されていないキャッシュ情報を削除した上で、新規にキャッシュ情報を記録する。
【００５１】
これらの手法を採った際のキャッシュの内部状態の遷移を図６〜図９を参照して説明する。ここでは、一例として、カラオケ装置１で選曲番号１、２、３、１０００の順に楽曲を演奏した場合を考える。これらの楽曲にはそれぞれ、映像番号０、１、２、１０００の背景映像が割り当てられているものとする。
【００５２】
まずは図６の遷移状態について説明する。
利用者から選曲番号１の曲がリクエストされる（Ｐ１）と、カラオケ装置１は選曲番号から楽曲ファイル名に変換し、／ｍｕｓｉｃ／０／０００１．ＭＩＤを読み出そうとする。このときキャッシュが空であるものと仮定すると、キャッシュ上からは何ら情報は得られず、ルートディレクトリから順に検索することになる。ここでルートディレクトリのインデックスブロックを読み出し、その内容からｍｕｓｉｃディレクトリを検索する。その結果、ルートディレクトリからｍｕｓｉｃディレクトリが発見され（Ｐ２）、キャッシュ上に／ｍｕｓｉｃの情報が記録される。同様に／ｍｕｓｉｃ／０（Ｐ３），／ｍｕｓｉｃ／０／０００１．ＭＩＤ（Ｐ４）に対して再帰的に検索が行われ、その結果がキャッシュに格納されていく。
【００５３】
楽曲ファイルが読み出せると、カラオケ装置１は／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘを読み出し、選曲番号１の曲に割り当てられた背景動画の映像番号を取得する。このとき、キャッシュには有効なデータが存在しないので、ルートディレクトリから再帰的に／ｖｉｄｅｏ（Ｐ５），／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘ（Ｐ６）が検索され、楽曲ファイルの検索と同様にキャッシュが更新されていく。
【００５４】
この／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘを読み出した結果、選曲番号１の楽曲には映像番号０の背景動画が割り当てられていることが判明し、カラオケ装置１は続いて／ｖｉｄｅｏ／００００．ＭＰ２を読み出そうとする。このとき、／ｖｉｄｅｏディレクトリに対するインデックスブロックＬＢＡはすでにＰ５でキャッシュされているため、このキャッシュ情報が最も新規に参照された情報として移動する（Ｐ７）。一方、／ｖｉｄｅｏ／０（Ｐ８），／ｖｉｄｅｏ／０／００００．ＭＰ２（Ｐ９）はキャッシュに存在しないため、既出のようにキャッシュが更新されていく。
【００５５】
次に図７の遷移状態について説明する。
これは図６を参照して説明した選曲番号１の曲の演奏が終了し、選曲番号２の曲が選曲された時の動作を示す。
選曲番号２に対応する楽曲ファイル／ｍｕｓｉｃ／０／０００２．ＭＩＤを読み出す際においては、すでに／ｍｕｓｉｃ／０ディレクトリのインデックスブロックＬＢＡはキャッシュされている（キャッシュヒット）ため、楽曲ファイル／ｍｕｓｉｃ／０／０００２．ＭＩＤに対する検索が行われた時点（Ｐ１１）で、図６に示すＰ７で／ｖｉｄｅｏディレクトリに対して処理したのと同様に、／ｍｕｓｉｃ／０ディレクトリのキャッシュ情報が最も新規に参照したものとなる。続いて楽曲ファイル／ｍｕｓｉｃ／０／０００２．ＭＩＤを／ｍｕｓｉｃ／０ディレクトリから検索し（Ｐ１２）、この情報がキャッシュに追加される。続いて／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘ（Ｐ１３）及び／ｖｉｄｅｏ／０（Ｐ１４）がキャッシュヒットする。実際にディレクトリを読み出して検索する（キャッシュミス）のは、／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘを読み出した結果、選曲番号２の楽曲に割り当てられていることが判明した映像番号１の背景動画ファイル／ｖｉｄｅｏ／０／０００１．ＭＰ２のインデックスブロックＬＢＡだけ（Ｐ１５）である。
【００５６】
次に図８の遷移状態について説明する。
これは図７を参照して説明した選曲番号２の曲の演奏が終了し、選曲番号３の曲が選曲された時の動作を示す。
選曲番号３番の曲がリクエストされた場合には、同様に／ｍｕｓｉｃ／０（Ｐ２１）、／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘ（Ｐ２３）、／ｖｉｄｅｏ／０（Ｐ２４）でキャッシュヒット、／ｍｕｓｉｃ／０／０００３．ＭＩＤ（Ｐ２２）、／ｖｉｄｅｏ／０／０００２．ＭＰ２（Ｐ２５）でキャッシュミスが起こる。ここで、Ｐ２５でキャッシュミスが起こったとき、新規にキャッシュ情報の追加が発生するが、この時点ですでにキャッシュ領域は一杯であるため、最も長い間参照されていない／ｍｕｓｉｃのキャッシュ情報が削除される（キャッシュアウト）。
【００５７】
図９は、図８に示した／ｍｕｓｉｃのキャッシュ情報の削除（キャッシュアウト）によって、次に選曲番号１０００が選曲された場合のファイルアクセス効率が低下する様子を示したものである。
カラオケ装置１は選曲番号１０００のリクエストを受けると、キャッシュの中を検索するしかし、図８に示すＰ２５において／ｍｕｓｉｃがキャッシュアウトされてしまったため、キャッシュ内に有効な情報を発見できず、ルートディレクトリから／ｍｕｓｉｃを検索することから開始しなければならない（Ｐ３１）。また、その／ｍｕｓｉｃに続いて／ｍｕｓｉｃ／１０００を検索した時点（Ｐ３２）でキャッシュに保存されたうちで最も長い間参照されていない／ｖｉｄｅｏがキャッシュアウトする。この直後に／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘはキャッシュヒット（Ｐ３４）するが、選曲番号１０００の曲に割り当てられた背景動画／ｖｉｄｅｏ／１０００／１０００．ＭＰ２を検索する際（Ｐ３５）に、Ｐ３２の時点で／ｖｉｄｅｏがキャッシュアウトしてしまったため、やはり再度ルートディレクトリから／ｖｉｄｅｏを検索することから始めなければならない。
【００５８】
上述のように、選曲番号１の曲を演奏する際にはキャッシュが空であるため、また選曲番号１０００の曲を演奏する際には／ｖｉｄｅｏ，／ｍｕｓｉｃがキャッシュアウトしてしまったため、それぞれ楽曲の再生開始のレスポンスが低下していることがわかる。これは従来技術の問題点として挙げたように、一般的なキャッシュでは、実検索が１度行われた時点でキャッシングが行われるため、装置起動直後には利用者の指示を受けてから必ずインデックス情報の実検索が行われることと、キャッシュアウトに際して各ファイル又はディレクトリのシステム全体から見た意味的な重みは一切考慮されず、すべてが同等なものとして扱われていることが原因である。
【００５９】
このような問題を解決するために本実施例では、以下のようなキャッシングを行う。
本実施例におけるキャッシュ手法においては、まず、キャッシュとして機能する「第二の記憶手段」としてのＲＡＭ１１ａを第一の記憶領域と第二の記憶領域に２分割し、第一の記憶領域（以下、第一キャッシュと称す。）には、アクセスレスポンスの向上の必要性が高いと予想されるファイル又はディレクトリのインデックスブロックＬＢＡを、カラオケ装置１の起動時に予め固定的に記憶させる。そして、第二の記憶領域（以下、第二一キャッシュと称す。）については従来のキャッシュと同様の役割を与え、上記アクセスレスポンスの向上の必要性が高いと予想されるファイル又はディレクトリ以外のファイル又はディレクトリのインデックスブロックＬＢＡについて、図１２を参照して説明した従来手法と同様の手法によってキャッシュする。
【００６０】
まず、カラオケ装置１の起動時において、ハードディスク１３内の／ｐｒｏｇｒａｍディレクトリ内に記憶されている「特定情報」としてのｃａｃｈｅ．ｌｓｔファイルを読み出し、そのファイル中にリストされたファイル又はディレクトリ名（図１６参照）に対応するインデックスブロックを予め検索し、第一キャッシュにその検索結果、すなわちファイル又はディレクトリ名とインデックスブロックＬＢＡとの組を記録しておく。
【００６１】
そして、その後の処理においては、図１１〜図１４を参照して説明した処理の内、図１２のフローチャートに示す処理に代えて図１５のフローチャートに示すキャッシュ検索処理を実行する。
キャッシュ検索処理が開始すると、まず、第二キャッシュ内において、指示されたファイル又はディレクトリ名をインクリメンタルに検索し（Ｓ１２１０，Ｓ１２４０）、キャッシュ上に該当するファイル又はディレクトリ名が存在すれば（Ｓ１２１０：はい）、該当するキャッシュ情報を最も新規に参照したキャッシュ情報として第二キャッシュに登録し直し（Ｓ１２２０）、その発見したファイル又はディレクトリ名と、それに対応するインデックスブロックＬＢＡを返す（Ｓ１２３０）。ここまでの処理は、図１２で説明した従来のキャッシュ検索処理と同様である。
【００６２】
一方、指示されたファイル又はディレクトリ名が第二キャッシュ上に存在しなければ（Ｓ１２４０：はい）、第一キャッシュに対して同様の検索、すなわち指示されたファイル又はディレクトリ名をインクリメンタルに検索し（Ｓ１２５０，Ｓ１２６０）、この検索によって第一キャッシュ上に該当するファイル又はディレクトリ名が存在すれば（Ｓ１２５０：はい）、その発見したファイル又はディレクトリ名と、それに対応するインデックスブロックＬＢＡを返す（Ｓ１２３０）。しかし、上記第二キャッシュに対して行ったようなキャッシュ情報の更新（Ｓ１２２０）は実行しない。
【００６３】
そして、指示されたファイル又はディレクトリ名が第一キャッシュ上にも存在しなければ（Ｓ１２６０：はい）、ルートディレクトリ直下のファイル又はディレクトリに対する検索か否か判断し（Ｓ１２７０）、そうでなければ（Ｓ１２７０：いいえ）、その親ディレクトリに対して同様の処理を再帰的に繰り返す（Ｓ２８０）。
【００６４】
第一キャッシュ上に情報が存在すればその時点で発見したファイル又はディレクトリ名と、それに対応するＬＢＡを返す（Ｓ１２３０）。
そして、ルートディレクトリ直下のファイル又はディレクトリに対して検索を行ったにもかかわらずキャッシュ情報が発見できなければ（Ｓ１２７０：はい）、キャッシュ検索に失敗したものとして、ルートディレクトリ名とそれに対応するインデックスブロックＬＢＡを返す（Ｓ１２９０）。
【００６５】
このように、第一キャッシュに対しては、アクセスレスポンスの向上の必要性が高いと予想されるファイル又はディレクトリのインデックスブロックＬＢＡを、カラオケ装置１の起動時に予め固定的に記憶させておき、装置起動中はキャッシュ情報の更新を行わない。一方、第二キャッシュに関しては、従来通りキャッシュ情報の更新を行いながらキャッシングしていく。そして、図１５に示すようなキャッシュ検索を実行することによって、ファイルアクセスのレスポンスが向上する。この点を、具体例を参照して説明する。
【００６６】
上述例と同様、カラオケ装置１で選曲番号１、２、３、１０００の順に楽曲を演奏した場合のキャッシュ（第一キャッシュ及び第二キャッシュ）の内部状態の遷移を図１０を参照して説明する。
カラオケ装置１の起動時において、ハードディスク１３内の／ｐｒｏｇｒａｍディレクトリ内に記憶されているｃａｃｈｅ．ｌｓｔファイルが読み出され、そのファイル中にリストされたファイル又はディレクトリ名（図１６参照）に対応するインデックスブロックが予め検索され、図１０の左上に示すように、本実施例の第一キャッシュには、その検索結果、すなわちファイル又はディレクトリ名とインデックスブロックＬＢＡとの組が記録される。また、第二キャッシュには、第一キャッシュへのキャッシュ情報を検索する際に得られた／ｍｕｓｉｃと／ｖｉｄｅｏがキャッシュされている。
【００６７】
この状態で、選曲番号１の曲が選曲されると、第一キャッシュから／ｍｕｓｉｃ／０のインデックスブロックＬＢＡを得ることができ、いまだキャッシュされていない楽曲ファイル／ｍｕｓｉｃ／０／０００１．ＭＩＤを検索する（Ｑ１）のみで所望の楽曲ファイルを読み出すことができる。また、背景映像の割り当てについても、／ｖｉｄｅｏ／ｖｉｄｅｏ．ｉｄｘファイルは第一キャッシュに予めキャッシュされているため、ハードディスク１３へのアクセス無しにそのインデックスブロックにアクセスが可能である。その後、選曲番号１の曲に割り当てられた背景動画ファイル／ｖｉｄｅｏ／０／００００．ＭＰ２を読み出す際にも、やはり第一キャッシュに／ｖｉｄｅｏ／０のインデックスブロックＬＢＡがキャッシュされているため、背景動画ファイル／ｖｉｄｅｏ／０／００００．ＭＰ２を／ｖｉｄｅｏ／０ディレクトリから検索する（Ｑ２）のみで背景動画ファイルにアクセスすることができる。
【００６８】
以下同様に、第一キャッシュの情報を利用して、楽曲ファイル、背景動画ファイルを直接検索するのみで楽曲の再生が可能となる。
本実施例のカラオケ装置１によれば次のような効果が得られる。
（ａ）カラオケ装置１の起動時において、ハードディスク１３内の／ｐｒｏｇｒａｍディレクトリ内に記憶されているｃａｃｈｅ．ｌｓｔファイルが読み出され、そのファイル中にリストされたファイル又はディレクトリ名（図１６参照）に対応するインデックスブロックが予め検索され、第一キャッシュにその検索結果、すなわちファイル又はディレクトリ名とインデックスブロックＬＢＡとの組が記録される。そのため、該当するファイル又はディレクトリにアクセスする際のレスポンスが向上する。例えば図９を参照して説明したように、従来のキャッシュ手法によるとキャッシュアウトによってレスポンスの遅延していた選曲番号１０００の楽曲の演奏においても、本実施例のキャッシュ手法であれば、図１０に示すように、楽曲ファイルの検索（Ｑ７）、背景動画ファイルの検索（Ｑ８）のみで演奏が実現でき、従来手法よりも安定して高速に楽曲の演奏が開始できることがわかる。なお、従来手法では図８に示すように例えば／ｍｕｓｉｃがキャッシュアウトされてしまっているが、カラオケ装置１においてはリクエストされたカラオケ曲を演奏する処理の度にこのディレクトリ／ｍｕｓｉｃはアクセスしなくてはならない。したがって、このようなディレクトリがキャッシュアウトされてしまうことはアクセスレスポンス向上の点で非常にデメリットとなる。そして、逆に本実施例ではカラオケ演奏の度にアクセスされるファイルの所属するディレクトリに関しては第一キャッシュに常駐しているため、非常に効果的である。
【００６９】
そして、この第一キャッシュ内のキャッシュ情報は、カラオケ装置１が稼働している間中保持され続けるため、上述したアクセスレスポンスの向上という効果が継続して得られる。
また、第二キャッシュには、従来通り、例えばＬＲＵ（Ｌｅａｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ）アルゴリズムなどの手法でキャッシュアウトした上で、その消去によって空いた記憶領域に新規のキャッシュ情報を記憶している。そのため、新規なキャッシュ情報（検索結果）については従来通りキャッシュしておくことができ、最近使用したファイルに対するアクセスレスポンスはやはり向上する。
【００７０】
（ｂ）本実施例では、第一キャッシュに常駐させておくキャッシュ情報を、ハードディスク１３内に記憶された／ｐｒｏｇｒａｍ／ｃａｃｈｅ．ｌｓｔファイルに基づいて決定している。したがって、例えばこのファイルの更新情報を公衆回線４０を経由して配信用ホスト装置５０から送信し、それに基づいて書き換えることによって、第一キャッシュに常駐させておくキャッシュ情報を変更することも可能である。例えば、使用頻度の高い楽曲のみの背景動画割り当て情報を記録したインデックスファイル／ｖｉｄｅｏ／ｖｉｄｅｏ＿ｈｉｇｈ．ｉｄｘを用いて楽曲番号から背景動画の検索を高速化するような場合には、前記ファイルを配信用ホスト装置５０にて新規に作成してカラオケ装置１に配信し、／ｐｒｏｇｒａｍ／ｃａｃｈｅ．ｌｓｔを上書きすればよい。
【００７１】
例えばカラオケ装置１の機種によっては提供できる機能が違っていたり、あるいは同じ機種であっても利用者層が違ったりして、アクセスレスポンスの向上の必要性が高いファイル又はディレクトリには違いがある可能性ある。したがって、このように配信用ホスト装置５０からの配信情報に基づいて／ｐｒｏｇｒａｍ／ｃａｃｈｅ．ｌｓｔの内容を変更できるようにすれば、第一キャッシュ内のキャッシュ情報をカラオケ装置１毎の状況に応じた適切なものとすることが可能である。
【００７２】
［その他の実施例］
（１）上記実施例では、アクセスレスポンスの向上の必要性の高低について、ハードディスク１３内のァイル又はディレクトリのアクセス頻度の高低に基づいて決定した例を説明した。図１６に示すようなファイル又はディレクトリはそのような観点で決定したものである。しかし、アクセスレスポンスの向上の必要性の高低については、他の観点を加味することもできる。例えば緊急性という観点を加味してもよい。例えばカラオケ装置１の利用者に対して「ただいま検索中」とか、「少しお待ち下さい」といったガイダンスを表示するような場合、このガイダンスが早めに出ないと利用者としては故障なのか何なのかが分からないため、極力早いほうがよいからである。このようなガイダンスは、たとえ使用頻度が相対的に低くても、アクセスレスポンスの向上の必要性は高い。
【００７３】
（２）上記実施例では、カラオケ装置１での実現例を示しているが、例えばビデオサーバのように、自身で情報を解釈再生する機能を持たず、ネットワーク上で接続されたクライアントからの要求に応じて情報ファイルをネットワーク経由で送信（出力）するようなものであってもよい。
【図面の簡単な説明】
【図１】実施例のカラオケ装置の概略構成を示すブロック図である。
【図２】実施例のカラオケ装置におけるハードディスク内部の構成を示す概念図である。
【図３】インデックスブロックの構成を示す概念図である。
【図４】ディレクトリのデータ構造を示す概念図である。
【図５】実施例のハードディスク内のディレクトリ構成を示す概念図である。
【図６】実施例のカラオケ装置において楽曲の演奏が行われた際に、従来のキャッシュ手法によるキャッシュの状態の変化を示す遷移図である。
【図７】実施例のカラオケ装置において楽曲の演奏が行われた際に、従来のキャッシュ手法によるキャッシュの状態の変化を示す遷移図である。
【図８】実施例のカラオケ装置において楽曲の演奏が行われた際に、従来のキャッシュ手法によるキャッシュの状態の変化を示す遷移図である。
【図９】実施例のカラオケ装置において楽曲の演奏が行われた際に、従来のキャッシュ手法によるキャッシュの状態の変化を示す遷移図である。
【図１０】実施例のカラオケ装置において楽曲の演奏が行われた際に、本実施例のキャッシュ手法による第一キャッシュ及び第二キャッシュの状態の変化を示す遷移図である。
【図１１】実施例のカラオケ装置においてファイルの検索を行う手順を示すフローチャートである。
【図１２】従来のキャッシュ手法によってキャッシュ内から情報を読み出す手順を示すフローチャートである。
【図１３】実施例のカラオケ装置においてハードディスク上のディレクトリ内からインデックスブロック情報を検索する手順を示すフローチャートである。
【図１４】実施例のカラオケ装置においてキャッシュに情報を挿入する手順を示すフローチャートである。
【図１５】実施例のカラオケ装置において第一キャッシュ及び第二キャッシュから情報を読み出す手順を示すフローチャートである。
【図１６】実施例のカラオケ装置１の第一キャッシュに予めキャッシュするファイル又はディレクトリのリストである／ｐｒｏｇｒａｍ／ｃａｃｈｅ．ｌｓｔファイルの構成を示す概念図である。
【符号の説明】
１…カラオケ装置、１１…中央処理装置、１１ａ…ＲＡＭ、１２…通信制御装置、１３…ハードディスク、１４…操作パネル、１５…リモコン送信機、１６…リモコン受信機、１７…操作制御部、１８…シンセサイザ、１９…ミキシングアンプ、２０…スピーカ、２１…マイクロフォン、２２…ビデオＲＡＭ、２３…映像再生装置、２４…映像制御部、２５…表示装置、３０…店舗内ネットワーク、４０…公衆回線、５０…配信用ホスト装置。
Claims (7)
- 少なくとも複数の提供情報を任意に設定されたファイル単位で記憶しておくための第一の記憶手段と、
前記第一の記憶手段よりも高速に読み書きが可能な第二の記憶手段と、
前記提供情報の提供要求を受け付ける要求受付手段と、
前記要求受付手段によって受け付けた情報提供要求に応じた提供情報を用いて情報提供を実行する情報提供実行手段と、
を備える情報提供装置における前記第一の記憶手段に記憶された提供情報をアクセスするための管理装置であって、
前記第一の記憶手段に記憶される前記提供情報を、当該提供情報に対応するファイル名又はディレクトリ構成で管理すると共に、ファイル名又は所属ディレクトリ名とファイル名を指定することによって該当する提供情報に対するアクセスを可能とするインデックス情報を、ファイル又はディレクトリ毎に記憶し、
前記第一の記憶手段内のファイル又はディレクトリを、アクセスレスポンスの向上の必要性の高低に基づいて予め２つ以上のグループに分けると共に、前記アクセスレスポンスの向上の必要性が高い第一のグループに属するファイル又はディレクトリを特定可能な特定情報を前記第一の記憶手段に記憶しており、
さらに、
前記情報提供装置の起動時に前記特定情報を読み出し、その読み出した特定情報によって特定されるファイル又はディレクトリのインデックス情報が記憶されている前記第一の記憶手段内の位置情報について予め検索し、その検索結果を前記第二の記憶手段内の第一の記憶領域に記憶する第一のキャッシュ処理手段と、
前記第一のグループ以外のグループに属するファイル又はディレクトリのインデックス情報が記憶されている前記第一の記憶手段内の位置情報については、前記提供要求が生じた場合に検索し、その検索結果を前記第二の記憶手段内の第二の記憶領域に記憶する第二のキャッシュ処理手段と、
前記提供要求が生じた場合には、当該提供要求に対応する前記インデックス情報を前記第二の記憶手段内の前記第一の記憶領域及び第二の記憶領域から検索し、検索できた場合にはそのインデックス情報に基づいてファイルアクセスを実行するファイルアクセス実行手段と
を備えるファイルアクセス管理装置。 - 請求項１に記載のファイルアクセス管理装置において、
前記第一のキャッシュ処理手段は、前記検索結果として、ファイル名と位置情報、ディレクトリ名と位置情報、ファイル名と所属ディレクトリ名と位置情報のいずれかの組を記憶する
ファイルアクセス管理装置。 - 請求項１又は２に記載のファイルアクセス管理装置において、
前記第一のキャッシュ処理手段によって前記第二の記憶手段内の第一の記憶領域に記憶された前記検索結果は、前記情報提供装置が稼働している間中、前記第二の記憶手段内の第一の記憶領域に保持し続け、
前記第二のキャッシュ処理手段は、前記検索結果を新規に記憶させようとした場合に、前記記憶手段内の第二の記憶領域の記憶容量を超えるのであれば、既に記憶されている検索結果を削除してから記憶させる
ファイルアクセス管理装置。 - 請求項１又は２に記載のファイルアクセス管理装置において、
前記アクセスレスポンスの向上の必要性の高低は、少なくとも前記第一の記憶装置内のファイル又はディレクトリのアクセス頻度の高低に基づいて決定されている
ファイルアクセス管理装置。 - 請求項１〜４の何れかに記載のファイルアクセス管理装置において、
前記情報提供装置は、外部のホスト装置と通信するための通信手段を備え、前記通信手段を介して前記ホスト装置から前記特定情報を受信可能に構成され、その受信した特定情報は前記第一の記憶手段に記憶されており、
前記第一のキャッシュ処理手段は、前記第一の記憶手段に記憶された特定情報に基づいて前記検索等の処理を実行する
ファイルアクセス管理装置。 - 請求項１〜５の何れかに記載のファイルアクセス管理装置において、
前記情報提供装置は、提供情報としてのカラオケ演奏データを用いてカラオケ演奏を実行し、前記特定情報には、前記カラオケ演奏データに対応するファイル又はディレクトリを特定可能な情報が含まれている
ファイルアクセス管理装置。 - 請求項６に記載のファイルアクセス管理装置において、
前記カラオケ演奏データには、楽曲データと背景画データとが含まれており、前記特定情報には、前記楽曲データと背景画データそれぞれに対応するファイル又はディレクトリを特定可能な情報が含まれている
ファイルアクセス管理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003082882A JP4380193B2 (ja) | 2003-03-25 | 2003-03-25 | ファイルアクセス管理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003082882A JP4380193B2 (ja) | 2003-03-25 | 2003-03-25 | ファイルアクセス管理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004295182A true JP2004295182A (ja) | 2004-10-21 |
| JP4380193B2 JP4380193B2 (ja) | 2009-12-09 |
Family
ID=33398523
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003082882A Expired - Fee Related JP4380193B2 (ja) | 2003-03-25 | 2003-03-25 | ファイルアクセス管理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4380193B2 (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006221615A (ja) * | 2005-01-10 | 2006-08-24 | Thomson Licensing | 記憶媒体の内容の走査方法および走査装置 |
| JP2007109181A (ja) * | 2005-10-17 | 2007-04-26 | Canon Inc | データ処理装置及びその制御方法、コンピュータプログラム、及び記憶媒体 |
| JP2008077433A (ja) * | 2006-09-21 | 2008-04-03 | Sony Computer Entertainment Inc | データベース生成方法および情報処理装置 |
| JP2013508810A (ja) * | 2009-10-16 | 2013-03-07 | シマンテック コーポレーション | 効率的なファイル保存のための複数のインデックスを有する重複排除ストレージシステム |
| JP2013101579A (ja) * | 2011-10-21 | 2013-05-23 | Canon Inc | 情報処理装置およびその制御方法、並びにプログラム |
| JP2014106726A (ja) * | 2012-11-27 | 2014-06-09 | Canon Inc | ファイル管理装置、その制御方法及びプログラム |
-
2003
- 2003-03-25 JP JP2003082882A patent/JP4380193B2/ja not_active Expired - Fee Related
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006221615A (ja) * | 2005-01-10 | 2006-08-24 | Thomson Licensing | 記憶媒体の内容の走査方法および走査装置 |
| KR101218013B1 (ko) * | 2005-01-10 | 2013-01-02 | 톰슨 라이센싱 | 저장 매체의 내용 스캐닝 방법 및 장치 |
| JP2007109181A (ja) * | 2005-10-17 | 2007-04-26 | Canon Inc | データ処理装置及びその制御方法、コンピュータプログラム、及び記憶媒体 |
| JP2008077433A (ja) * | 2006-09-21 | 2008-04-03 | Sony Computer Entertainment Inc | データベース生成方法および情報処理装置 |
| JP4578454B2 (ja) * | 2006-09-21 | 2010-11-10 | 株式会社ソニー・コンピュータエンタテインメント | データベース生成方法および情報処理装置 |
| JP2013508810A (ja) * | 2009-10-16 | 2013-03-07 | シマンテック コーポレーション | 効率的なファイル保存のための複数のインデックスを有する重複排除ストレージシステム |
| JP2013101579A (ja) * | 2011-10-21 | 2013-05-23 | Canon Inc | 情報処理装置およびその制御方法、並びにプログラム |
| JP2014106726A (ja) * | 2012-11-27 | 2014-06-09 | Canon Inc | ファイル管理装置、その制御方法及びプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4380193B2 (ja) | 2009-12-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4855714B2 (ja) | コンピュータオペレーティングシステムに渡ってコンピュータファイルへのアクセスを行うシステムおよび方法 | |
| US9529725B2 (en) | Information processing device and method for managing file | |
| US7987190B2 (en) | Filesystem having a filename cache | |
| WO2002035358A1 (fr) | Procede de creation et procede de suppression de partitions | |
| JP4279452B2 (ja) | １つの記憶媒体の名称空間を別の記憶媒体の名称空間に移植する場合に既定のアクションを実行するシステムおよび方法 | |
| US20150126288A1 (en) | Information processing device, program, and recording medium | |
| US10166467B2 (en) | Information processing device, data structure of game data, and recording medium | |
| JP5343793B2 (ja) | 情報生成装置、情報生成プログラム、情報生成方法、ノード装置、ノードプログラム及び検索方法 | |
| US20070226219A1 (en) | Method of managing data of file system using database management | |
| KR20140114040A (ko) | 위치 독립적 파일 | |
| US10052555B2 (en) | Information processing device, data structure of game data, and recording medium | |
| TWI353549B (ja) | ||
| JP2005148868A (ja) | ストレージ装置におけるデータのプリフェッチ | |
| CN110032543A (zh) | 一种存储文件系统的管理方法 | |
| JPH11316709A (ja) | ディスク制御装置及び方法 | |
| JP4380193B2 (ja) | ファイルアクセス管理装置 | |
| JP2002073397A (ja) | 光ディスクメディアに記録されるように選択されたデータファイルを効率的にホスト処理する方法 | |
| JP2015088144A (ja) | 情報処理装置およびゲームデータのデータ構造 | |
| JPH11259627A (ja) | 画像管理装置およびその方法、画像管理システム、記憶媒体 | |
| JP3541718B2 (ja) | 楽音生成装置 | |
| JP3918817B2 (ja) | 楽音生成装置 | |
| US11586353B2 (en) | Optimized access to high-speed storage device | |
| JP2003006026A (ja) | コンテンツ管理装置及びコンテンツ処理装置 | |
| JP2004030305A (ja) | ファイルシステム | |
| JPH10214217A (ja) | ネットワークキャッシュ装置およびネットワークキャッシュ方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060303 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090106 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090309 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090421 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090609 |
|
| 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: 20090901 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090914 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121002 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4380193 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131002 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |