JP2004326923A - 情報処理装置、情報処理方法、プログラム、記憶媒体 - Google Patents
情報処理装置、情報処理方法、プログラム、記憶媒体 Download PDFInfo
- Publication number
- JP2004326923A JP2004326923A JP2003119948A JP2003119948A JP2004326923A JP 2004326923 A JP2004326923 A JP 2004326923A JP 2003119948 A JP2003119948 A JP 2003119948A JP 2003119948 A JP2003119948 A JP 2003119948A JP 2004326923 A JP2004326923 A JP 2004326923A
- Authority
- JP
- Japan
- Prior art keywords
- processing
- information
- data
- unit data
- hdcc
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Abstract
【課題】コンテンツデータを対象とするアプリケーションが起動して操作可能となるまでの時間を短縮する。
【解決手段】コンテンツデータ管理のためのデータベースファイルＦＬ１をＨＤＤ２１に記憶させておく。そのうえで、データベースを基として作成されたｈｄｃｃ処理対象データＦＬ２ａ（ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ）を保持しておく。アプリケーションは、このｈｄｃｃ処理対象データＦＬ２ａを利用して、コンテンツデータに関する所要の処理を実行する。そして、アプリケーションの処理結果に応じてデータベースについての登録処理が必要となったときには、必ず、ｈｄｃｃ処理対象データＦＬ２ａについての登録処理も実行するようにされる。これにより、ｈｄｃｃ処理対象データＦＬ２ａは、常にデータベースファイルＦＬ１と同期した状態が得られる。
【選択図】 図３
【解決手段】コンテンツデータ管理のためのデータベースファイルＦＬ１をＨＤＤ２１に記憶させておく。そのうえで、データベースを基として作成されたｈｄｃｃ処理対象データＦＬ２ａ（ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ）を保持しておく。アプリケーションは、このｈｄｃｃ処理対象データＦＬ２ａを利用して、コンテンツデータに関する所要の処理を実行する。そして、アプリケーションの処理結果に応じてデータベースについての登録処理が必要となったときには、必ず、ｈｄｃｃ処理対象データＦＬ２ａについての登録処理も実行するようにされる。これにより、ｈｄｃｃ処理対象データＦＬ２ａは、常にデータベースファイルＦＬ１と同期した状態が得られる。
【選択図】 図３
Description
【０００１】
【発明の属する技術分野】
本発明は、例えばコンテンツデータの再生等をはじめとした、コンテンツデータを対象とする各種の処理を実行可能な情報処理装置、及びその方法に関する。また、このような情報処理装置に実行させるプログラム、また、このプログラムが記憶された記憶媒体に関する。
【０００２】
【従来の技術】
近年、安価な大容量のハードディスク（ＨＤＤ）が普及してきている。これに伴って、例えばＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）などのメディアに記録されているオーディオデータをハードディスクに記録して保存する、いわゆるリッピングを行うことが広く普及している。このようなリッピングは、例えばＣＤを再生可能なディスクドライブと、ＨＤＤとを組み合わせたオーディオ機器を構成することで可能となる。また、例えばパーソナルコンピュータによっても行うことが可能とされる。
なお、ＣＤの音源をリッピングするのにあたっては、例えばＡＴＲＡＣ（Ａｄａｐｔｉｖｅ Ｔｒａｎｓｆｏｒｍ Ａｃｏｕｓｔｉｃ Ｃｏｄｉｎｇ）方式やＭＰ３（ＭＰＥＧ Ａｕｄｉｏ Ｌａｙｅｒ ＩＩＩ）方式などによりオーディオデータを圧縮して記録することが一般には行われる。
【０００３】
このようにして、リッピングにより、多数の楽曲などのオーディオデータをファイルとしてハードディスクに記憶させておくようにすれば、ユーザは、逐一自分が聴きたいアルバムのＣＤを交換して再生するような煩わしさから開放されることになり、これまでよりも充実した音楽リスニング環境を得ることができる。
なお、本明細書において、上記したオーディオデータをはじめとして、ＨＤＤ等の記憶媒体に記憶されるファイル単位のＡＶ（Ａｕｄｉｏ Ｖｉｄｅｏ）データについては、「コンテンツデータ」ともいうことにする。
【０００４】
そして、ＨＤＤに記録された多数のコンテンツデータを管理、再生するコンテンツ管理アプリケーションでは、コンテンツデータの管理、再生を効率的に行うために、データベースを利用するのが一般的である。
【０００５】
このようなデータベースも、上記コンテンツ管理アプリケーションにより作成され、ＨＤＤに記憶される。
そして、このデータベースによっては、コンテンツデータごとのＨＤＤにおけるディレクトリ（パス）が管理される。また、コンテンツデータごとについてのタイトル、アーティスト名、圧縮フォーマットなどをはじめとする各種の属性情報も管理される。さらに、コンテンツデータには、アルバムジャケットや歌詞カードとしての画像データなどに代表されるフリンジデータといわれる関連データも付随してＨＤＤに記録される場合があるが、このようなフリンジデータのパスを示すなど、フリンジデータについての管理も行うようになっている。
【０００６】
そして、例えば上記コンテンツ管理アプリケーションが起動されるときには、データベースから必要な情報を選択、抽出して収集し、これらの収集された情報を利用して、コンテンツ管理アプリケーションがコンテンツ管理、再生のために直接的に利用する、コンテンツ処理対象データを作成するようにされる。このコンテンツ処理対象データとしては、例えば、データベースに登録されているコンテンツをリストとして一覧表示させるのに必要なリストデータを挙げることができる。従って、このような場合のコンテンツ管理アプリケーションに対する操作は、上記コンテンツ処理対象データの作成が完了してリスト表示が行われた後にはじめて可能となる。
【０００７】
このようにして作成されたコンテンツ処理対象データは、ＨＤＤではなく、例えばＲＡＭなどによるキャッシュに展開される。コンテンツ管理アプリケーションは、このようにして、キャッシュ上に展開されたコンテンツ処理対象データを解釈して、例えば上記したようなリスト表示等を実行するようにされている。つまり、コンテンツ処理対象データをキャッシュに保持させた後は、ＨＤＤに記憶されるデータベースではなく、このキャッシュの領域にアクセスしてコンテンツ処理対象データを処理すればよいこととなり、効率的なコンテンツ管理、再生動作を得ることができる。例えば、このようなキャッシュを利用したデータリード／ライトのための技術としては、特許文献１に記載されたものが知られている。
なお、ここでいうキャッシュとは、あくまでもＲＡＭなどの揮発性のメモリ上においてコンテンツ処理対象データが展開される領域を指すものであり、例えば、いわゆるキャッシュメモリともいわれる、ＣＰＵとＲＡＭ、ＨＤＤなどの間に介在するメモリとは意味が異なる。
【０００８】
【特許文献１】
特開２００２−２７４１９号公報
【０００９】
【発明が解決しようとする課題】
しかしながら、上記したようなコンテンツ処理対象データの作成にあたり、データベースから必要な情報をフィルタリングして抽出する処理は比較的重いものであり、相応に時間を要する。
従って、現状においては、例えばリスト表示が完了するなど、コンテンツ管理アプリケーションが起動を完了して操作が可能となるまでには、或る程度の時間がかかってしまっている。これは、例えばユーザにとってはストレスとなるので好ましいことではない。特に、管理するコンテンツデータ数が増えるにしたがって、コンテンツ処理対象データを作成するのに要する時間も長くなるので、この場合には、上記した問題がさらに顕著となってしまう。
【００１０】
また、実際のシステムでは、コンテンツ処理対象データを作成するのに時間がかかることを考慮して、例えばリスト表示に関すれば、１画面分を表示するのに必要とされる情報のみによりコンテンツ処理対象データを作成するようにしている。そして、例えばリスト表示がスクロールされるのに応じて、リスト表示のためのデータが無くなるのに応じて、また、データベースにアクセスしてコンテンツ処理対象データを作成するようにしている。このようにして、現状では必要最小限のコンテンツ処理対象データを逐次作成するという処理アルゴリズムとしているのが一般的である。
【００１１】
このような処理アルゴリズムである場合、コンテンツ処理対象データを作成するごとに相応の処理時間を要するのであるから、例えばスクロールに応じたリスト表示もスムーズなものではなくなってしまい、この点でも、ユーザに対してストレスを与えることになる。
また、スクロール操作などに応じて不定期でデータベースへのアクセスが実行されることになるから、例えば、コンテンツデータについての再生など、実時間的処理を実行している他の処理の速度を遅くする要因にもなる。これにより、例えばコンテンツデータの安定した再生を阻害する可能性がある。また、同じ理由から、例えばライブ音源などのようにコンテンツデータ間での連続再生が要求されるような再生や、リピート再生及びランダム再生などの特殊再生を安定して実行することが困難となる可能性がある。
【００１２】
このようにして、現状におけるコンテンツ処理対象データの作成、及びキャッシュのための処理では、コンテンツ処理対象データを作成するのに相応の時間を要することから、コンテンツ管理アプリケーションの起動が開始されてから操作が可能となるまでの時間も相応に長いものとなっており、また、他の処理プロセスの安定性を阻害する可能性があるという問題を有している。
【００１３】
【課題を解決するための手段】
そこで、本発明は上記した課題を考慮して、情報処理装置として次のように構成する。
つまり、所定の記憶媒体に記憶されている１以上の単位データを管理するデータベースが記憶される第１の不揮発性記憶手段と、データベースに対する登録処理を実行する第１の登録手段と、データベースを形成する情報のうちから所定の情報を利用して作成されたものであり、単位データを対象とする所要の処理に利用される、単位データ処理用情報が保持される第１の情報保持手段と、単位データ処理用情報を利用して、単位データについての所要の処理を実行する単位データ対象処理手段と、単位データ処理用情報に対する登録処理を実行する第２の登録手段とを備える。
そして、上記第２の登録手段は、単位データ対象処理手段が実行した処理結果に応じて、第１の登録手段によるデータベースに対する登録処理が実行されるときには、上記処理結果に応じた単位データ処理用情報に対する登録処理を実行するように構成する。
【００１４】
また、情報処理方法としては、所定の記憶媒体に記憶されている１以上の単位データを管理する情報であり、不揮発性記憶領域に記憶されているデータベースに対する登録処理を実行する第１の登録処理と、データベースを形成する情報のうちから所定の情報を利用して作成され、単位データを対象とする所要の処理に利用される情報であり、情報保持領域に保持されるコンテンツ処理用情報を利用して、上記単位データについての所要の処理を実行する単位データ対象処理と、コンテンツ処理用情報に対する登録処理を実行する第２の登録処理とを実行するものとされる。
そして、上記第２の登録処理は、単位データ対象処理としての処理結果に応じて、第１の登録処理によるデータベースに対する登録処理が実行されるときには、上記処理結果に応じた単位データ処理用情報に対する登録処理を実行するように構成することとしている。
【００１５】
また、プログラムとしては、所定の記憶媒体に記憶されている１以上の単位データを管理する情報であり、不揮発性記憶領域に記憶されているデータベースに対する登録処理を実行する第１の登録処理と、データベースを形成する情報のうちから所定の情報を利用して作成され、単位データを対象とする所要の処理に利用される情報であり、情報保持領域に保持されるコンテンツ処理用情報を利用して、上記単位データについての所要の処理を実行する単位データ対象処理と、コンテンツ処理用情報に対する登録処理を実行する第２の登録処理とを情報処理装置に実行させるものとされる。
そして、上記第２の登録処理は、単位データ対象処理としての処理結果に応じて、第１の登録処理によるデータベースに対する登録処理が実行されるときには、上記処理結果に応じた単位データ処理用情報に対する登録処理を実行するように構成するものである。
【００１６】
また、上記プログラムを記憶して記憶媒体を構成することとした。
【００１７】
上記各構成によれば、第１の不揮発性手段（不揮発性領域）に記憶されているデータベースを基にして作成されたコンテンツ処理用情報が第１の情報保持手段（情報保持領域）に保持されていることになる。
そして、単位データを対象とした単位データ対応処理を実行するのにあたっては、上記第１の情報保持手段（情報保持領域）に保持されているコンテンツ処理用情報を利用するようにされる。
そして、単位データ対応処理の処理結果に応じて、データベースへの登録処理を行うときには、これと共に、同じ単位データ対応処理の処理結果に応じて、上記第１の情報保持手段（情報保持領域）に保持されているコンテンツ処理用情報についての登録処理も行うようにされる。
これにより、最初にデータベースを基にしてコンテンツ処理用情報を作成した後は、上記した登録処理によって、データベースとコンテンツ処理用情報との内容について同期している状態が常に得られていることになる。
【００１８】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。なお、以降の説明は次の順序で行う。
１．記録再生装置の構成
２．コンテンツデータのディレクトリ管理
３．コンテンツデータ管理のためのプログラム構成
４．ファイル構造
５．初期化処理
６．登録処理
７．終了処理
【００１９】
１．記録再生装置の構成
図１のブロック図は、本発明の実施の形態としての情報処理装置が適用される記録再生装置１の構成例を示している。
ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１は、起動されたプログラムに基づいて記録再生装置１の全体の制御、演算処理を行う。例えばネットワークを介した通信動作、ユーザーに対する入出力動作、メディアからのコンテンツ再生やリッピング、ＨＤＤ２１へのコンテンツ記憶やそのための管理などを行う。なお、以降の説明を単純なものとするために、本実施の形態の記録再生装置１が対応して記録再生可能なコンテンツデータとしては、オーディオのコンテンツデータであることとする。
ＣＰＵ１１はバス１２を介して各回路部との間で制御信号やデータのやりとりを行う。
【００２０】
ＲＯＭ１３は、ＣＰＵ１１が実行すべき動作プログラム、プログラムローダーや、各種演算係数、プログラムで用いるパラメータ等が記憶される。
また、ＲＡＭ２０には、ＣＰＵ１１が実行すべきプログラムが展開される。また、ＣＰＵ１１が各種処理を実行する際において必要となるデータ領域、タスク領域としても用いられる。
【００２１】
操作入力部１５は、記録再生装置１の筐体に設けられた操作キーやジョグダイヤル、タッチパネルなどの各種操作子などから成る部位である。なお、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）操作のためのキーボードやマウスが操作入力部１５として設けられてもよい。また、操作入力部１５としては、リモートコントローラとされてもよい。
操作入力部１５で入力された情報は入力処理部１４において所定の処理が施され、ＣＰＵ１１に対して操作コマンドとして伝送される。ＣＰＵ１１は入力された操作コマンドに応答した機器としての動作が得られるように、所要の演算や制御を行う。
【００２２】
ディスプレイモニタ１７としては、例えば液晶ディスプレイなどの表示デバイスが接続され、各種情報表示が行われる。
ＣＰＵ１１が各種動作状態や入力状態、通信状態に応じて表示情報を表示処理部１６に供給すると、表示処理部１６は供給された表示データに基づいてディスプレイモニタ１７に表示動作を実行させる。
例えば本実施の形態の場合であれば、リッピングされたオーディオファイルを再生管理するプログラムに従っては、オーディオファイルを管理、再生するためのＧＵＩ画面が表示される。
【００２３】
この場合のメディアドライブ１９は、所定のメディアに対応して少なくとも再生が可能なドライブとされる。もちろんのこと、所定メディアに対応して、再生だけではなく、記録が可能なドライブとされても良い。
また、この場合のメディアドライブ１９が対応するメディアとしては、特に限定されるべきものではないが、例えばＣＤ、ＤＶＤ、ミニディスクなどの各種光学ディスク状記録媒体とされても良い。あるいは、フラッシュメモリなどのメモリ素子により構成されたメディアとされてもよい。また、メディアドライブとしては、例えばこれらの各種メディアに対応した各種のドライブが個々に設けられてバス１２と接続される構成とされてもよいものである。
【００２４】
例えばユーザーが操作入力部１５に対する操作によって、メディアドライブ１９による再生指示を行った場合は、ＣＰＵ１１は、メディアドライブ１９に対してメディアに対する再生を指示する。これに応じて、メディアドライブ１９は、装填されているメディアから、指定されたデータにアクセスして読み出しを実行する。
【００２５】
このようにして読み出されたデータが、オーディオコンテンツである場合には、必要に応じてＣＰＵ１１の処理によってデコード処理等が施された後、オーディオ入出力処理部２４に転送される。オーディオ入出力処理部２４においては、イコライジング等の音場処理や音量調整、Ｄ／Ａ変換、増幅等の処理が施され、スピーカ部２５から出力される。
【００２６】
またメディアドライブ１９にて再生されたデータは、ＣＰＵ１１の制御によって、ＨＤＤ２１にオーディオデータファイルとして蓄積することもできる。つまり、いわゆるリッピングにより得たオーディオデータファイルをコンテンツデータとして記憶させることができる。
なお、このオーディオデータファイルの形式としては、ＣＤフォーマットにおけるサンプリング周波数４４．１ＫＨｚで１６ビット量子化のデジタルオーディオデータとされてもよいし、ＨＤＤ２１の容量を節約するために、所定方式にしたがって圧縮処理が施された形式の圧縮オーディオデータとされてもよい。また、圧縮方式としても限定されるものではないが、ＡＴＲＡＣ（Ａｄａｐｔｉｖｅ Ｔｒａｎｓｆｏｒｍ Ａｃｏｕｓｔｉｃ Ｃｏｄｉｎｇ）方式やＭＰ３（ＭＰＥＧ Ａｕｄｉｏ Ｌａｙｅｒ ＩＩＩ）方式などを採用することができる。
【００２７】
チューナ部２７は、例えばＡＭ・ＦＭラジオチューナとされ、ＣＰＵ１１の制御に基づいて、アンテナ２６で受信された放送信号を復調する。もちろんテレビチューナや衛星放送チューナ、デジタル放送チューナなどとしてのチューナでもよい。
復調された放送音声信号は、オーディオデータ処理部２４において所要の処理が施され、スピーカ部２５から放送音声として出力される。
【００２８】
通信処理部２２は、ＣＰＵ１１の制御に基づいて送信データのエンコード処理、受信データのデコード処理を行う。
ネットワークインターフェイス２３は、通信処理部２２でエンコードされた送信データをネットワークを介して所定の外部ネットワーク対応機器に送信する。またネットワークを介して外部ネットワーク対応機器から送信されてきた信号を通信処理部２２に受け渡す。
通信処理部２２は受信した情報をＣＰＵ１１に転送する。
【００２９】
なお、記録再生装置１の構成は、この図１の構成に限られるものではなく、更に多様に考えられる。
例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、ＩＥＥＥ１３９４、Ｂｌｕｅｔｏｏｔｈなどの通信方式による周辺機器とのインターフェースが設けられるようにしてもよい。
そして、上記ネットワークインターフェイス２３によりネットワークを介してダウンロードしたオーディオのコンテンツデータや、上記ＵＳＢ、ＩＥＥＥ１３９４などのインターフェイスを経由して転送されてきたオーディオのコンテンツデータについても、ＨＤＤ２１に対して記憶させることができる。
またマイクロホンや外部のヘッドホンの接続に用いられる端子や、ＤＶＤ再生時に対応するビデオ出力端子、ライン接続端子、光デジタル接続端子等が設けられてもよい。
またＰＣＭＣＩＡスロット、メモリカードスロットなどが形成され、外部の情報処理装置やオーディオ機器とデータのやりとりが可能とされてもよい。
【００３０】
２．コンテンツデータのディレクトリ管理
上記図１による説明から理解されるように、本実施の形態の記録再生装置１では、ＨＤＤ２１に対して、オーディオデータファイルとしてのコンテンツデータを記憶することができる。
このコンテンツデータは、ＨＤＤ２１上において、図２に示すようにして管理される。
先ず、ｒｏｏｔディレクトリの下層に対しては、規定範囲内での任意の数のｆｏｌｄｅｒを置くことができる。このｆｏｌｄｅｒは、例えばコンテンツデータが属するジャンル、または所有ユーザなどに対応して作成される。
そして、このｆｏｌｄｅｒの下層には、規定範囲内での任意の数のａｌｂｕｍを置くようにされている。ａｌｂｕｍは、例えば１つのアルバムタイトルごとに対応する。そして、このａｌｂｕｍのディレクトリ下において、そのａｌｂｕｍに属するとされる１以上のｔｒａｃｋを位置させるようにしている。このｔｒａｃｋごとの単位データが、１つのコンテンツデータとなるものである。
このようなコンテンツデータについてのディレクトリ管理は、ＨＤＤ２１に記憶されているデータベースファイルによって行われている。なお、データベースファイルについては後述する。
【００３１】
３．コンテンツデータ管理のためのプログラム構成
そして、本実施の形態では、コンテンツデータについての管理／再生を可能とするためのプログラムもＨＤＤ２１にインストールされるようにして記憶されている。
図３は、このようなコンテンツデータ管理／再生のためのプログラムの構成をブロック図として示している。なお、確認のために述べておくと、この図に示される各種プログラムは、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）上で動作するものである。
先ず、プログラムとして最上層に位置しているアプリケーション３１は、コンテンツデータに対応した所要の機能動作を実行可能なアプリケーションプログラムである。ここでは、アプリケーション３１は、ＨＤＤ２１に記憶されているオーディオデータファイルとしてのコンテンツについて管理、再生等が可能な、いわゆるコンテンツプレーヤとしての機能を有しているものとされる。
このアプリケーション３１は、例えばユーザによるアプリケーション３１に対する操作やプログラム動作の流れに従って、下位層に対してコマンド、イベント等の発行を行う。これにより、アプリケーション３１としての動作が実現される。
【００３２】
なお、この図に示すプログラム構成において、本実施の形態のデータベースキャッシュを利用しながら、コンテンツデータを対象とした処理を実行するアプリケーションとしては、上記コンテンツプレーヤとしてのアプリケーション３１以外のものであってもよい。また、このような本実施の形態のデータベースキャッシュを利用するアプリケーションが複数インストールされていてもよいものである。そして、このようなアプリケーションが複数インストールされている場合には、例えば、これらのアプリケーションを同時に起動させたうえで、これらのアプリケーションの間で、これより下層のプログラムによるデータベースキャッシュシステムを共用するようにすることも考えられる。
【００３３】
アプリケーション３１の下層にはハードディスクコンテンツコントローラ（ｈｄｃｃ）３２としてのプログラムが位置する。
このｈｄｃｃ３２は、アプリケーション３１から発行されるコマンド等を解釈することができる。そして、アプリケーション３１から発行されるコマンドに応じた処理として、下層のコンテンツデータアクセスモジュール３３に対する制御を実行する。
【００３４】
また、ｈｄｃｃ３２は、ＲＡＭ２０内のｈｄｃｃ−ｃａｃｈｅ領域２０Ａ（第１の情報保持手段）に保持される、ｈｄｃｃ処理対象データＦＬ２ａについての管理、処理を行う。
ｈｄｃｃ処理対象データＦＬ２ａは、最初は、データベースファイルＦＬ１を形成しているテーブル群から、アプリケーション３１がコンテンツ管理、再生を実行するのに必要とされる所要の情報を抽出して作成されるデータである。
アプリケーション３１の起動中においては、ＨＤＤ２１に記憶されているコンテンツのリストを、その属性情報（タイトル、アーティスト、属するアルバムタイトル等）、及びアルバムジャケットの画像データをはじめとしたコンテンツに関連するデータ（フリンジデータ）などと共に表示する。ｈｄｃｃ処理対象データＦＬ２ａは、例えばこのようなコンテンツデータのリスト表示に必要とされる属性情報、デコード処理後のフリンジデータなどを有して構築されている。
また、例えばコンテンツデータが記憶されるＨＤＤ２１上のパスなどの情報も有している。このコンテンツデータのパスの情報を参照することで、例えばファイルシステムを利用して再生対象のコンテンツデータをＨＤＤ２１から読み出して再生処理を実行することが可能となる。
【００３５】
つまり、ｈｄｃｃ処理対象データＦＬ２ａは、アプリケーション３１、又はｈｄｃｃ３２が、コンテンツデータを対象とした管理、再生などの所要の処理を実行するのに利用する情報となる。換言すれば、データベースファイルＦＬ１を、アプリケーション３１、又はｈｄｃｃ３２が処理可能な形式に再構築した情報である。
【００３６】
コンテンツデータアクセスモジュール（ｃｄａｍ）３３は、コンテンツデータに関連したデータの読み出し、書き込みのためのＨＤＤ２１へのアクセスを担当するプログラムである。このために、ｃｄａｍ３３の下層には、ＨＤＤ２１（第１の不揮発性記憶手段）に記憶されるデータベースファイルＦＬ１についての処理を実行するプログラムであるデータベースモジュール（ｄｂ）３４が位置する。また、ＨＤＤ２１からファイル単位での読み出し／書き込みを実行するファイルシステム（ｆｓｙｓ）３５が位置する。この図では、ＨＤＤ２１（第２，第３の不揮発性記憶手段）に記憶されるファイルであって、ファイルシステム（ｆｓｙｓ）３５により読み出し／書き込みされるべきファイルとして、コンテンツデータ管理に関連するｈｄｃｃ処理対象ファイルＦＬ２が示されている。なお、ｈｄｃｃ処理対象ファイルＦＬ２については図４により後述する。
【００３７】
また、ｃｄａｍ３３は、ＲＡＭ２０におけるｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂ（第２の情報保持手段）に保持されるｈｅａｄｅｒ情報ＦＬ３についての書き込み／読み出し処理を実行する。なお、このｈｅａｄｅｒ情報ＦＬ３についても図４により後述する。
【００３８】
このようにして、コンテンツデータを管理するプログラム構成としては、アプリケーション３１、ｈｄｃｃ３２、ｃｄａｍ３３、データベースモジュール３４３４、及びファイルシステム３５から成るものとされる。
そして、これらのプログラム構成の下で、コンテンツデータ管理のために利用する情報としては、データベースファイルＦＬ１、ｈｄｃｃ処理対象ファイルＦＬ２、ｈｄｃｃ処理対象データＦＬ２ａ、及びｈｅａｄｅｒ情報ＦＬ３とされている。
ここで、データベースファイルＦＬ１、ｈｄｃｃ処理対象ファイルＦＬ２は、不揮発性の記憶領域であるＨＤＤ２１に記憶されるデータであり、例えば電源供給が停止しても保存されるデータである。
これに対して、ｈｄｃｃ処理対象データＦＬ２ａ、ｈｅａｄｅｒ情報ＦＬ３は、揮発性の記憶領域であるＲＡＭ２０内において確保される記憶領域に対して保持されるものであり、例えば、アプリケーション３１の終了に伴って、消去されてもよい情報である。
【００３９】
４．ファイル構造
上記のようにして、本実施の形態において、コンテンツデータ管理のために利用する情報は、データベースファイルＦＬ１、ｈｄｃｃ処理対象ファイルＦＬ２、ｈｄｃｃ処理対象データＦＬ２ａ、及びｈｅａｄｅｒ情報ＦＬ３となる。これらの情報の説明のために、図４を参照して、データベースファイルＦＬ１及びｈｄｃｃ処理対象ファイルＦＬ２の構造について説明する。
【００４０】
図４（ａ）には、データベースファイルＦＬ１が示されている。
このデータベースファイルＦＬ１には、先に図２に示したようなコンテンツデータ間のディレクトリ構造を管理する情報が格納されている。
また、例えばコンテンツデータごとのＨＤＤ２１におけるディレクトリ（パス）が管理される。
また、コンテンツデータごとについてのタイトル、アーティスト名、圧縮フォーマットなどをはじめとする各種の属性情報も管理される。
さらに、コンテンツデータには、アルバムジャケットや歌詞カードとしての画像データなどに代表されるフリンジデータといわれる関連データも付随してＨＤＤ２１に記録される場合があるが、このようなフリンジデータのパスを示すなど、フリンジデータについての管理も行うようにされているものである。
【００４１】
そして、本実施の形態のデータベースファイルＦＬ１としては、上記したような各種所要の情報を、テーブル単位ごとに所定の構造により格納すると共に、図４（ａ）に示しているように、所定領域に対して、所定のデータサイズによるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを格納することとしている。
このＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、後述するようにして、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１と、同じくＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２との内容について、整合性確認を行う（同期状態を調べる）のに必要とされる情報である。本実施の形態では、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、データベースファイルＦＬ１に対して最後に登録（更新）が行われた日時を示す情報であることとしている。また、データエントリ数、やデータ構造を示す情報などをはじめ、データ内容を識別する所定のデータ内容識別情報とされてもよい。また、これら日時情報と所定のデータ内容識別情報との組み合わせとされてもよい。
【００４２】
図４（ｂ）には、ＨＤＤ２１に記憶される、ｈｄｃｃ処理対象ファイルＦＬ２の構造が示されている。
なお、後述するようにして、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持されるｈｄｃｃ処理対象データＦＬ２ａを初期化するのにあたっては、通常はデータベースファイルＦＬ１から再構築をするのではなく、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージをそのままｈｄｃｃ−ｃａｃｈｅ領域２０Ａに転送して保持させるようにしている。
つまり、ｈｄｃｃ処理対象ファイルＦＬ２は、データベースシステムにおけるキャッシュデータとしての意味を持つ。そこで、以降においては、このｈｄｃｃ処理対象ファイルＦＬ２について、ｃａｃｈｅ ｆｉｌｅともいう場合がある。
【００４３】
この図４（ｂ）に示すようにして、ｈｄｃｃ処理対象ファイルＦＬ２は、先頭に所定サイズのｈｅａｄｅｒ領域が配置され、これに続けて、ｈｄｃｃ処理対象ファイルＦＬ２としての実データである、データイメージが格納される。
そして、ｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域のデータが、ＲＡＭ２０のｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂ内に格納されるｈｅａｄｅｒ情報ＦＬ３となる。また、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージが、そのまま、ＲＡＭ２０内のｈｄｃｃ−ｃａｃｈｅ領域２０Ａに格納されるべき、ｈｄｃｃ処理対象データＦＬ２ａのデータ内容となる。
【００４４】
つまり、ＨＤＤ２１にアクセスして、ｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域のデータを取得し、このデータをｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに書き込んで保持させることで、ｈｅａｄｅｒ情報ＦＬ３が得られる。
同様にして、ＨＤＤ２１にアクセスして、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージを取得し、このデータイメージをｈｄｃｃ−ｃａｃｈｅ領域２０Ａに書き込んで保持させることで、ｈｄｃｃ処理対象データＦＬ２ａが得られる。
【００４５】
図４（ｃ）には、ｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域の構造が示されている。確認のために述べておくと、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂにて保持されるｈｅａｄｅｒ情報ＦＬ３も同様の構造を有する。
先ず、先頭の所定サイズの領域には、ファイル種別を識別するための識別情報が格納される。つまり、この領域に格納される値により、ファイル種別がｈｄｃｃ処理対象ファイルＦＬ２であることを示す。この場合には、例えば「Ｃ Ｄ Ｍ Ａ」との記述に対応したビットの値が格納される。
【００４６】
Ｅｄｉｔ Ｆｌａｇは、データ保護のために必要となる情報であり、このフラグの値を参照することで、ＨＤＤ２１への書き込みが正常に行われたか否かを推定することができる。
【００４７】
本実施の形態において、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）は、複数記憶される場合がある。ｃａｃｈｅ ＩＤは、このような場合に対応して、個々のｈｄｃｃ処理対象ファイルＦＬ２を識別するための識別子である。
Ｆｏｒｍａｔ Ｖｅｒｓｉｏｎには、ｈｄｃｃ処理対象ファイルＦＬ２としてのフォーマットのバージョンを示す値が格納される。
【００４８】
このｈｅａｄｅｒ領域におけるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、先に図４（ａ）により示したデータベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと同じ意義を有する。
つまり、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１と、同じくＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２との内容についての同期をとる（整合性を確認する）ために必要とされる情報であり、データベースファイルＦＬ１に対して最後に登録（更新）が行われた日時を示す。
【００４９】
ここで、上記したファイル種別識別情報（Ｃ Ｄ Ｍ Ａ）、Ｅｄｉｔ Ｆｌａｇ、ｃａｃｈｅ ＩＤ、Ｆｏｒｍａｔ Ｖｅｒｓｉｏｎ、及びＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが格納される領域は、ｃｄａｍ３３が解釈して処理する情報とされる。
これに対して、ｕｓｅｒ ａｒｅａの領域に対しては、ｈｄｃｃ３２が解釈して処理可能な任意の情報を格納することができることとされている。
【００５０】
例えば、ｃｄａｍ３３は、アプリケーション側の層にあるとされるプログラムではなく、ＯＳ側の層（システム側）にあるとされるプログラムであり、比較的プリミティブな処理を実行する。これに対して、ｃｄａｍ３３の上層にあるｈｄｃｃ３２は、アプリケーション側のプログラムであり、より高度な処理を実行する。例えば、コンテンツデータのディレクトリに関すれば、ｈｄｃｃ３２は、データベースの情報を参照して、例えば図２に示したディレクトリ構造全体におけるコンテンツデータの位置を認識することが可能である。これに対して、ｃｄａｍ３３は、１つのディレクトリを基準とした親又は子のディレクトリについての認識にとどまる。
そこで、必要に応じて、ｈｄｃｃ３２が対応して処理すべき所要のデータをｕｓｅｒ ａｒｅａに格納しておくようにすれば、ｈｄｃｃ処理対象ファイルＦＬ２を効率的に利用して、コンテンツ管理等に関しての高度な機能を付加することが可能になる。
【００５１】
５．初期化処理
これまでの説明を踏まえて、本実施の形態におけるコンテンツ対応のデータベースキャッシュのための処理動作について説明を行っていくこととし、先ず、初期化処理について説明することとする。
【００５２】
ところで、以降の説明から理解されることであるが、ｈｄｃｃ処理対象データＦＬ２ａは、元々は、データベースファイルＦＬ１を再構築して作成されたものである。しかしながら、本実施の形態では、ｈｄｃｃ処理対象データＦＬ２ａについて、ＨＤＤ２１に記憶させたｈｄｃｃ処理対象ファイルＦＬ２から取得したデータイメージを、そのままｈｄｃｃ処理対象データＦＬ２ａとしてｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持させるようにしている。つまり、データベースシステムにおいて、ｈｄｃｃ処理対象ファイルＦＬ２は、ｈｄｃｃ処理対象データＦＬ２ａを取得する際のキャッシュデータとして扱われる。ここでいうデータベースキャッシュとは、このようなシステム動作をいうものである。
また、ここでいう初期化処理とは、例えばアプリケーション３１が起動されることなどに応じて、これまでは空き領域であった、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに対して、ｈｄｃｃ処理対象データＦＬ２ａをマウント（保持）させるための処理である。
【００５３】
図５は、初期化処理の流れをフローチャートにより示している。なお、この図に示す処理は、例えば図４に示したプログラム構成の下で、ＣＰＵ１１がこれらのプログラム従って実行するものとされる。
例えば、アプリケーション３１が起動されるなどして初期化を実行するためのコマンドが発行されたとすると、ステップＳ１０１の処理を実行することになる。
ステップＳ１０１においては、ＨＤＤ２１に記憶されているデータベースファイルＦＬ１にアクセスして、データベースファイルＦＬ１を形成している各テーブルから、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得する。つまり、図４（ａ）にて説明したようにして、データベースファイルＦＬ１の各テーブルの構造内に格納されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅの読み込みを実行する。
【００５４】
次のステップＳ１０２においては、ＨＤＤ２１に記憶されているｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）にアクセスする。そして、ｈｅａｄｅｒ領域に格納されているＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得する。
【００５５】
上記ステップＳ１０１及びステップＳ１０２の処理によっては、データベースファイルＦＬ１及びｈｄｃｃ処理対象ファイルＦＬ２のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが取得されたことになる。そして、ステップＳ１０３においては、このデータベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと、ｈｄｃｃ処理対象ファイルＦＬ２のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとについて比較を行い、これらのＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅについて値が一致しているか否かについて判定する。
後述する登録処理及び終了処理が正常に行われれば、データベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと、ｈｄｃｃ処理対象ファイルＦＬ２のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとは一致していることになる。Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致している場合、データベースファイルＦＬ１の内容と、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージの内容とは同期している（整合性が得られている）ことを意味する。これに対して、一致していなければ、例えば何らかの要因によって、データベースファイルＦＬ１の内容と、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージの内容との間で整合が得られていない状態であることを示すことになる。つまり、ステップＳ１０３の処理は、データベースファイルＦＬ１とｈｄｃｃ処理対象ファイルＦＬ２のデータイメージとの間で同期が得られている状態にあるか否かを判定する処理である。
【００５６】
そして、ステップＳ１０３において、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致しているとして肯定結果が得られた場合には、ステップＳ１０４の処理に進む。Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致している場合、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータイメージの内容は、データベースファイルＦＬ１の登録内容と同期が得られている。つまり、現在のデータベースファイルＦＬ１の登録内容が正常に反映された内容を有しているということであり、このデータイメージを、そのままｈｄｃｃ処理対象データとして利用して良いということになる。
そこで、ステップＳ１０４の処理としては、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）にアクセスして、データイメージを読み込んで取得する。そして、この取得したデータイメージを、ｈｄｃｃ処理対象データＦＬ２ａとして、ＲＡＭ２０のｈｄｃｃ−ｃａｃｈｅ領域２０Ａに対して書き込んで展開させる。以降、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａには、ｈｄｃｃ処理対象データＦＬ２ａが保持された状態が得られる。
【００５７】
一方、ステップＳ１０３において、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致していないとして否定結果が得られた場合、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータイメージの内容は、データベースファイルＦＬ１の登録内容と整合していない、つまり、同期していないということになる。
ここで、ｈｄｃｃ処理対象ファイルＦＬ２のイメージデータは、あくまでもデータベースファイルＦＬ１を基として作成されるものである。つまり、データベースファイルＦＬ１の登録内容が基準となるものであり、従って、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータイメージと、データベースファイルＦＬ１とでは、データベースファイルＦＬ１の内容を信頼すべきこととなる。
このことに基づいて、ステップＳ１０５以降の処理は、データベースファイルＦＬ１を利用して新たに作成したｈｄｃｃ処理対象データＦＬ２ａを、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａにマウントするための処理となる。
【００５８】
つまり、ステップＳ１０５では、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１にアクセスして、ｈｄｃｃ処理対象データＦＬ２ａを構築するのに必要な情報を各テーブルから選択、抽出して収集する処理を実行する。
次のステップＳ１０６では、収集した情報によりｈｄｃｃ処理対象データＦＬ２ａを作成する。そして、この作成したｈｄｃｃ処理対象データＦＬ２ａを、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに転送して書き込み、ここに展開して保持させる。
上記ステップＳ１０４又はステップＳ１０６の処理が終了して以降においては、例えばアプリケーション３１、及びｈｄｃｃ３２は、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持されたｈｄｃｃ処理対象データＦＬ２ａを利用して、例えばリスト表示をはじめとした所要の処理を実行することができる。これは、ステップＳ１０４又はステップＳ１０６の処理の完了を以て、アプリケーション３１に対する操作が可能となることを意味する。
【００５９】
この図５に示した処理によると、初期化処理にあたって、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータイメージとデータベースファイルＦＬ１の登録内容とについて同期が得られている限りは、このデータイメージをそのままｈｄｃｃ処理対象データＦＬ２ａとして扱って、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに対してマウントすることになる。
本実施の形態の場合、例えば後述する登録処理及び終了処理等が正常に実行されていさえすれば、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータイメージとデータベースファイルＦＬ１の登録内容とについて同期が得られるようにされている。従って、通常の初期化処理としてはステップＳ１０４の処理が実行されるものである。
【００６０】
データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを構築する処理は、例えば、所定のフィルタ条件に応じてデータベースファイルＦＬ１から必要な情報を抽出する必要があるために相応に時間がかかるものであり、管理すべきコンテンツデータ数が増加すれば処理時間はさらに長くなってしまう。そして、従来においては、初期化処理が実行されるごとに、データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを構築することを行っていたものである。つまり、常にステップＳ１０５→Ｓ１０６の処理を実行することとしていた。
【００６１】
これに対して、本実施の形態では、通常の初期化処理としてはステップＳ１０４の処理を実行する。つまり、初期化処理ごとに、逐一、データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを構築することは行っていない。
ステップＳ１０４の処理は、ＨＤＤ２１上のｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）からデータイメージを読み込んで転送し、ＲＡＭ２０に書き込む処理となることから、短時間で終了することになる。つまり、通常の初期化処理としては非常に短時間で完了させることが可能になる。また、ステップＳ１０４の処理は、ＨＤＤ２１から読み出したデータをＲＡＭ２０に書き込むだけの軽い処理であるから、例えば同時に他のプロセスを実行していたとしても、この他のプロセスにはほとんど影響を与えない。例えば他のプロセスとして、コンテンツデータを再生しているような場合にも、その再生出力の連続性が保証されるなど、安定した再生出力を維持することができる。
【００６２】
また、従来の場合であれば、初期化時ごとに、データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを作成することになるから、処理時間を最小限とするために、例えば１画面分のコンテンツデータのリスト表示が可能なだけの情報により、ｈｄｃｃ処理対象データＦＬ２ａを作成していた。このために、リスト画面のスクロールなどに応じて、データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを作成する処理が比較的高い頻度で割り込むこととなっていた。これによっては、スクロール表示がスムーズに行えないことになる。また、例えば他のプロセスが影響を受ける頻度も高くなるため、例えばコンテンツデータの連続再生や、ランダム再生、リピート再生などの特殊再生などが安定して行えないなどの不都合が生じる場合があった。
これに対して、本実施の形態では、最初においてデータベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを作成しさえすれば、以降においては、このｈｄｃｃ処理対象データＦＬ２ａは、データベースファイルＦＬ１と同期が得られていることになる。
そこで、本実施の形態としては、最初にデータベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを作成するときには、データベースファイルＦＬ１全体の登録内容を利用して作成するようにされる。この場合、ｈｄｃｃ処理対象データＦＬ２ａの作成には相当の時間がかかるが、一旦作成してしまえば、以降においては、キャッシュファイルからの読み出しにより、ｈｄｃｃ処理対象データＦＬ２ａが得られることになるので、この場合にも短時間の軽い処理で済む。そして、この場合には、例えばリスト画面のスクロールが行われたときにも、ＲＡＭ２０のｈｄｃｃ−ｃａｃｈｅ領域２０Ａから、表示に必要なデータを読み出してくればよいので、スムーズなリスト画面のスクロール表示が得られる。
また、リスト画面のスクロールなどに応じて、データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを作成する処理が発生することはないから、例えば先に述べたコンテンツデータの連続再生や特殊再生などを安定して実行することも容易となる。
【００６３】
なお、この場合における、ステップＳ１０５→ステップＳ１０６の処理は、データベースファイルＦＬ１と、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データＦＬ２ａ）との間での同期が得られなくなったとされるエラー状態に対応して、再同期を図るための処理となる。
このステップＳ１０５→ステップＳ１０６の処理としては、上述もしているように、比較的時間がかかることとなってしまう。しかしながら、この処理は、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データＦＬ２ａ）との間で同期が得られるように回復を図るために必要な処理である。また、この処理は、高い頻度で実行されるものではないので、例えばユーザに与えるストレスは最小限で済む。
【００６４】
続いては、本実施の形態としての初期化処理を、図３に示したプログラム構成の基での処理シーケンスとして説明する。この説明には、図６及び図７のアローチャートを参照する。
図６には、データベースファイルＦＬ１と、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データＦＬ２ａ）との間での同期（整合性）が得られている場合に対応した初期化処理のシーケンスが示される。この図６に示す処理シーケンスは、先に図５に示したフローチャートにおいては、ステップＳ１０１→Ｓ１０２→Ｓ１０３→Ｓ１０４としての処理に相当する。
【００６５】
図６においては、先ず、ステップＳ２０１の処理として、アプリケーション３１からｈｄｃｃ３２に対して初期化（Ｉｎｉｔｉａｌｉｚｅ）のコマンドが発行される。このＩｎｉｔｉａｌｉｚｅのコマンドに応じて、ｈｄｃｃ３２は、ステップＳ２０２の処理として、ｃｄａｍ３３に対してキャッシュ初期化（Ｉｎｉｔ Ｃａｃｈｅ）のコマンドを発行する。ｃｄａｍ３３は、Ｉｎｉｔ Ｃａｃｈｅのコマンドに応じて、ステップＳ２０３の処理により、ファイルシステム３５を利用して、Ｇｅｔ Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとしての処理を実行する。つまり、ｃｄａｍ３３は、ＨＤＤ２１に記憶されているｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域に記憶されているＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得する。但し、この場合においては、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得するのにあたり、ｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域全体のデータを取得するようにされる。
【００６６】
そして、ｃｄａｍ３３は、上記のようにしてＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得すると、ステップＳ２０４のＰｕｔ Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとしての処理により、この取得したＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに対して書き込んで展開するための処理を実行する。なお、この場合においては、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに対して、ステップＳ２０３により取得したｈｅａｄｅｒ領域全体のデータを展開することを以て、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０ＢにＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを展開させたこととしている。
このステップＳ２０３→Ｓ２０４の処理を完了させると、ｃｄａｍ３３は、ステップＳ２０５の処理を実行する。つまり、ｈｄｃｃ３２に対して、Ｉｎｉｔ Ｃａｃｈｅのコマンドに対応した処理が完了したことを、例えばｃｏｍｐｌｅｔｅのレスポンスとして通知する。
【００６７】
ｃｏｍｐｌｅｔｅの通知を受けたｈｄｃｃ３２は、続いて、ステップＳ２０６により、Ｃｈｅｃｋ Ｃａｃｈｅのコマンドをｃｄａｍ３３に対して発行する。
これに応じて、ｃｄａｍ３３は、ステップＳ２０７の処理として、先のステップＳ２０４よりｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに対して展開されたＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得するための処理を実行する。
なお、図５のステップＳ１０２の処理としては、ＨＤＤ２１に記憶されているｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域から、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得することとしている。この点で、図６に示すステップＳ２０４、Ｓ２０７による得られる処理手順とは相違する。しかしながら、この図６におけるステップＳ２０４、Ｓ２０７の処理としても、取得されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとしては、ＨＤＤ２１に記憶されているｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域に格納されているものと実質的に同一となるものである。
また、ｃｄａｍ３３は、ステップＳ２０７に続くステップＳ２０８の処理によって、データベースモジュール３４にコマンドを発行して、データベースファイルＦＬ１から、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得する。
【００６８】
次のステップＳ２０９では、上記ステップＳ２０７，Ｓ２０８により取得したｈｄｃｃ処理対象ファイルＦＬ２とデータベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅについて比較を行う。これは、図５におけるステップＳ１０３の処理に相当する。この場合には、ｈｄｃｃ処理対象ファイルＦＬ２とデータベースファイルＦＬ１とは同期しているので、一致（ｏｋ）の比較結果が得られることになる。
このようにしてｏｋの比較結果が出力された場合、ｃｄａｍ３３は、ステップＳ２１０の処理により、Ｃｈｅｃｋ Ｃａｃｈｅの結果がｏｋであったことを、ｈｄｃｃ３２に対して、レスポンス（Ｃｈｅｃｋ Ｏｋ）の返信により通知する。
【００６９】
上記Ｃｈｅｃｋ Ｏｋの通知を受けたｈｄｃｃ３３は、ステップＳ２１１として、ｃｄａｍ３３に対してＧｅｔ Ｃａｃｈｅ Ｆｒｏｍ ｆｓｙｓのコマンドを発行する。ｃｄａｍ３３は、Ｇｅｔ Ｃａｃｈｅ Ｆｒｏｍ ｆｓｙｓのコマンドに応じて、ステップＳ２１２としての処理を実行する。ステップＳ２１２では、ファイルシステム３５にコマンドを発行することで、ＨＤＤ２１に記憶されているｈｄｃｃ処理対象ファイルＦＬ２からデータイメージを読み込ませる。そして、この読み込まれたデータイメージを取得する。
そして、次のステップＳ２１３としての処理により、ｈｄｃｃ３２は、ｃｄａｍ３３が取得したとされるデータイメージを、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに対して展開する処理を実行する（Ｓｅｔ Ｃａｃｈｅ）。ここまでのステップＳ２１１→Ｓ２１２→Ｓ２１３の処理が、図５におけるステップＳ１０４の処理に相当する。
ｈｄｃｃ３２は、このＳｅｔ Ｃａｃｈｅの処理を完了させると、次のステップＳ２１４としての処理として、アプリケーション３１から発行されたＩｎｉｔｉａｌｉｚｅのコマンド（Ｓ２０１）に応答した初期化処理が完了したことを、アプリケーション３１に対してＣｏｍｐｌｅｔｅのレスポンスにより通知する。この通知をアプリケーション３１が認識することで、初期化処理のシーケンスが完了したこととなる。
【００７０】
図７は、データベースファイルＦＬ１と、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データＦＬ２ａ）との間での同期（整合性）が得られていない場合に対応した初期化処理のシーケンスが示される。図５に示したフローチャートにおいては、ステップＳ１０１→Ｓ１０２→Ｓ１０３→Ｓ１０５→Ｓ１０６としての処理シーケンスに相当する。
【００７１】
図７において、ステップＳ３０１〜Ｓ３０８までの処理は、図６におけるステップＳ２０１〜Ｓ２０８までの処理と同様であることから、ここでの説明は省略する。
そして、この場合においては、ステップＳ３０９によるｈｄｃｃ処理対象ファイルＦＬ２とデータベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅについての比較結果として、一致していないというＮＧの結果が得られている。Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致していない場合、何らかの処理エラーなどによって、ｈｄｃｃ処理対象ファイルＦＬ２のイメージデータの内容は、データベースファイルＦＬ１の登録内容が反映されておらず、同期が得られていないということを意味する。
【００７２】
この場合、ｃｄａｍ３３は、ステップＳ３０１の処理により、ステップＳ３０９による比較の結果がＮＧであることを、ｈｄｃｃ３２からのＣｈｅｃｋ Ｃａｃｈｅのコマンドに応答したレスポンス（Ｃａｃｈｅ Ｎｇ）の返信により、通知する。
この通知を受けたｈｄｃｃ３２は、ステップＳ３１１の処理により、ｃｄａｍ３３に対して、Ｇｅｔ Ｄａｔａ Ｆｒｏｍ ｄｂのコマンドを発行する。このコマンドを受けたｃｄａｍ３３は、ステップＳ３１２の処理によって、データベースモジュール３４に対してコマンドを発行して、データベースファイルＦＬ１の読み出しを実行させる。
ｈｄｃｃ３２は、次のステップＳ３１３としての処理によって、上記ステップＳ３１２の処理によって読み出されたデータベースファイルＦＬ１から必要とされる情報を抽出して、ｈｄｃｃ処理対象データＦＬ２ａを作成する。そして、続くステップＳ３１４としての処理によって、この作成したｈｄｃｃ処理対象データＦＬ２ａを、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに対して転送して展開（保持）させる。そして、この処理の完了を以て、次のステップＳ３１５としての処理により、初期化処理が終了したことをアプリケーション３１に通知する。
【００７３】
この図７に示す処理において、ステップＳ３１１〜Ｓ３１４の処理シーケンスが、図５におけるステップＳ１０５→Ｓ１０６による処理に相当する。そして、ステップＳ３１１〜Ｓ３１４の処理シーケンスにおいて、ステップＳ３１２及びＳ３１３は、相応の時間を要する重い処理となる。これと比較して、例えば先に図６に示したステップＳ２１１〜Ｓ２１３の処理シーケンスにおいては、特に時間がかかる重い処理は無いものとされる。
【００７４】
６．登録処理
続いては、本実施の形態のデータベースキャッシュのための処理における登録処理について説明する。この登録処理は、コンテンツデータについての管理状態が変更されたのに応じて、この新たな管理状態を反映させるためにデータベースファイルＦＬ１の内容を変更する処理となる。
ここでの、コンテンツデータについての管理状態が変更される場合としては、例えば、コンテンツデータの追加、又は削除が行われた場合を挙げることができる。また、アプリケーションに対する操作などに応じて、既に登録されたコンテンツデータについての分割、連結などの編集が行われた場合にも登録処理が必要となる。さらには、コンテンツデータに対応付けられた属性情報が変更されたり、また、フリンジデータについての追加、削除、編集などが行われた場合も登録処理が必要となる。
【００７５】
図８は、登録処理の流れをフローチャートにより示している。
例えば上記のようにしてコンテンツデータについての管理状態が変更されることに応じては、登録処理の実行を指示するコマンドが発行される。このコマンドの発行に応じては、ステップＳ４０１としての処理により、今回のコンテンツデータについての管理状態の変更内容が反映されるようにして、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１に対して、データを登録するようにされる。なお、このデータ登録にあたっては、データベースファイルＦＬ１に格納されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅについての更新を伴う。この場合には、このステップＳ４０１としての処理によりデータ登録を行った日時情報をＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとしてセットする。
【００７６】
次のステップＳ４０２においては、同じく、今回の今回のコンテンツデータについての管理状態の変更内容が反映されるようにして、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに現在展開されている、ｈｄｃｃ処理対象データに対してデータ登録を実行する。
【００７７】
つまり、本実施の形態では、コンテンツデータについての管理状態が変更されることに応じて、データベースモジュール３４の登録処理を実行すべきときには、必ず、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持されるｈｄｃｃ処理対象データＦＬ２ａについても、その変更内容が反映されるようにして、データ登録を実行するようにしている。
これにより、ｈｄｃｃ処理対象データＦＬ２ａの情報内容と、データベースファイルＦＬ１の登録内容とについては、常に整合性が得られることになる。換言すれば、例えばデータベースファイルＦＬ１が変更されるのに応じてｈｄｃｃ処理対象データＦＬ２ａに整合性を与えるために、その都度、データベースファイルＦＬ１から情報収集をしてｈｄｃｃ処理対象データＦＬ２ａを作成する必要がないということになる。つまり、ｈｄｃｃ処理対象データＦＬ２ａと、データベースファイルＦＬ１との実質的な情報内容について同期を図るための処理（ステップＳ４０２）としても、短時間で軽いものとなっている。
【００７８】
そして、次のステップＳ４０３によっては、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに現在保持されているｈｅａｄｅｒ情報ＦＬ３のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを、先のステップＳ４０１による処理により更新した、データベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと同じ値となるように書き換える（登録する）。このステップＳ４０３の処理により、データベースファイルＦＬ１に格納されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂにおけるｈｅａｄｅｒ情報ＦＬ３に格納されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとは、同一の値を有することになる。
このステップＳ４０３の処理は、データベースファイルＦＬ１と、ｃａｃｈｅｆｉｌｅであるｈｄｃｃ処理対象ファイルＦＬ２との間で同期が得られていることを認識可能とするための準備的な処理となるものである。
【００７９】
また、図３に示したプログラム構成の基での上記登録処理のシーケンスは、図９に示すものとなる。
先ず、図９においては、ステップＳ５０１としての処理により、アプリケーション３１からｈｄｃｃ３２に対して、データベースファイルＦＬ１に対するデータ登録を指示するコマンド（Ｓｅｔ Ｄａｔａ）が発行される。ｈｄｃｃ３２は、このコマンドに応じて、ステップＳ５０２の処理として示すように、さらにｃｄａｍ３３に対して、データベースファイルＦＬ１に対するデータ登録を指示するコマンド（Ｓｅｔ Ｄａｔａ）を発行する。
このＳｅｔ Ｄａｔａのコマンドを受けたｃｄａｍ３３は、ステップＳ５０３の処理によって、データベースモジュール３４にコマンドを発行してコントロールすることで、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１に対して、データ登録を実行する。確認のために述べておくと、このときには今回の登録の日時を示すＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを登録することも行う。
そして、このステップＳ５０３としてのデータベースファイルＦＬ１対象のデータ登録の処理を完了させると、ステップＳ５０４として示すように、このデータ登録処理が完了したことを、ｈｄｃｃ３２に対して、ｃｏｍｐｌｅｔｅのレスポンスにより、通知する。
ここまでの処理が、図８におけるステップＳ４０１の処理となる。
【００８０】
上記ステップＳ５０４による通知を受けたｈｄｃｃ３２では、次に、ステップＳ５０５としての処理（Ｓｅｔ Ｄａｔａ）を実行する。
この処理としては、現在ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持されているｈｄｃｃ処理対象データＦＬ２ａを対象としてデータ登録を実行する。この処理が、図５におけるステップＳ４０２の処理に相当する。
【００８１】
そして、ステップＳ５０６以降の処理が、図５におけるステップＳ４０３に相当する処理となる。
ステップＳ５０６では、ｈｄｃｃ３２からｃｄａｍ３３に対して、Ｓｙｎｃ Ｃａｃｈｅのコマンドが送信される。このコマンドに応じた処理として、ｃｄａｍ３３は、先ず、ステップＳ５０７として示すように、ＨＤＤ２１に記憶されているデータベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅをデータベースモジュール３４により読み出させて取得するための処理を実行する。ここで取得されたＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、先のステップＳ５０３による登録処理時に対応した更新日時を示している、最新の値である。
そして、次のステップＳ５０８としての処理によって、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに保持されているｈｅａｄｅｒ情報ＦＬ３のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅの領域に対して、取得したＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅの値をセットするようにされる。これにより、先にも述べたようにして、データベースファイルＦＬと、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂのｈｅａｄｅｒ情報ＦＬ３のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとは、同一の値となる。
【００８２】
ステップＳ５０８の処理を完了させると、ｃｄａｍ３３は、ステップＳ５０９の処理として、ステップＳ５０６によるＳｙｎｃ Ｃａｃｈｅのコマンドに対するレスポンスとして、ｃｏｍｐｌｅｔｅを返す。つまり、Ｓｙｎｃ Ｃａｃｈｅのコマンドに応答した処理が完了したことを通知する。このｃｏｍｐｌｅｔｅのレスポンスを受けたｈｄｃｃ３２は、ステップＳ５１０の処理により、さらに、ステップＳ５０２によるＳｅｔ Ｄａｔａのコマンドに対するレスポンスとして、アプリケーション３１に対してｃｏｍｐｌｅｔｅを返す。
【００８３】
７．終了処理
次に、本実施の形態のデータベースキャッシュのための処理における終了処理について説明する。終了処理は、アプリケーション３１が終了するのに伴って実行される処理である。
ここでのアプリケーション３１が終了される場合としては、先ず、アプリケーション３１が起動されている状態でメイン電源をオフとすることで、アプリケーション３１が終了する場合を挙げることができる。また、メイン電源がオン状態であっても、ユーザ操作によって、アプリケーション３１の起動を終了が指示された場合、或いは、アプリケーション３１から他のアプリケーションをアクティブにするようにして、アプリケーションの切り換えが行われた場合なども、アプリケーションの終了となる。
【００８４】
図１０は、このような終了処理についての処理をフローチャートにより示している。アプリケーション３１が終了されることに伴って、終了を指示するコマンドが発行されると、この図に示す終了処理が開始される。
先ず、ステップＳ６０１により、現在、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに展開されているｈｅａｄｅｒ情報ＦＬ３を、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）における、ｈｅａｄｅｒ領域の情報として登録する。なお、この処理に伴い、これまでｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに展開されていたｈｅａｄｅｒ情報ＦＬ３はクリアしてもよい。
【００８５】
また、次のステップＳ６０２においては、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに展開されていたｈｄｃｃ処理対象データを、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）における、イメージデータとして登録する。なお、ステップＳ６０２の処理に伴っても、これまでｈｄｃｃ−ｃａｃｈｅ領域２０Ａに展開されていたｈｄｃｃ処理対象データをクリアするようにしてよい。
【００８６】
また、この終了処理を、図３に示したプログラム構成の下での処理シーケンスとして示した場合には、図１１に示すものとなる。
図１１においては、先ず、ステップＳ７０１としての処理により、アプリケーション３１から、終了処理の実行を指示するｔｅｒｍｉｎａｔｅのコマンドが、ｈｄｃｃ３２に対して発行される。
このｔｅｒｍｉｎａｔｅのコマンドに応答して、ｈｄｃｃ３２は、ステップＳ７０２としての処理によって、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａからｈｄｃｃ処理対象データＦＬ２ａを取得する。
そして、次のステップＳ７０３としての処理によっては、ｃｄａｍ３３に対して、ｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）の保存を指示するＳａｖｅ Ｃａｃｈｅのコマンドを発行する。
【００８７】
Ｓａｖｅ Ｃａｃｈｅのコマンドに応答して、ｃｄａｍ３３は、先ず、ステップＳ７０４としての処理によって、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに保持されているｈｅａｄｅｒ情報ＦＬ３を取得する。これにより、先のステップＳ７０３によるｈｄｃｃ処理対象データＦＬ２ａと、上記ｈｅａｄｅｒ情報ＦＬ３とが取得されたことになる。
そこで、ｃｄａｍ３３は、次のステップＳ７０５の処理によって、ファイルシステム３５に対して指示を行うことで、ｈｅａｄｅｒ情報ＦＬ３とｈｄｃｃ処理対象データＦＬ２ａとを、それぞれ、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域の情報、及びデータイメージとして登録するようにして保存処理を実行する。
【００８８】
上記ステップＳ７０５の処理が完了したとされると、ｃｄａｍ３３は、ステップＳ７０６としての処理によって、Ｓａｖｅ Ｃａｃｈｅの処理が終了したことを、ｃｏｍｐｌｅｔｅのレスポンスによって、ｈｄｃｃ３２に通知する。
この通知を受けたｈｄｃｃ３２は、ステップＳ７６０７の処理によって、さらに、アプリケーション３１に対して、ステップＳ７０１により発行されたｔｅｒｍｉｎａｔｅのコマンドに応答した処理が終了したことを、ｃｏｍｐｌｅｔｅのレスポンスにより通知する。
【００８９】
これら図１０及び図１１に示す処理によると、アプリケーション終了時においては、これまでｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持されていたｈｄｃｃ処理対象データＦＬ２ａと、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに保持されていたｈｅａｄｅｒ情報ＦＬ３とにより、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域の情報、及びデータイメージが更新されることになる。
【００９０】
なお、図１０においては、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂのｈｅａｄｅｒ情報ＦＬ３をｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）に登録し、次に、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａのｈｄｃｃ処理対象データＦＬ２ａを、ｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）に登録するようにされている。
これに対して、図１１に示す処理は、先ず、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａのｈｄｃｃ処理対象データＦＬ２ａ、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂのｈｅａｄｅｒ情報ＦＬ３の順に情報取得を行ったうえで、ステップＳ７０５の処理によって、これらの情報を一括的に、ｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）に登録することとしており、図１０とは若干処理手順が異なる。
しかしながら、本実施の形態としては、結果的に、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａのｈｄｃｃ処理対象データＦＬ２ａと、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂのｈｅａｄｅｒ情報ＦＬ３とにより、ｈｄｃｃ処理対象ファイルＦＬ２が更新されるのであれば、そのための処理手順は適宜変更されて構わない。この点については、先に説明した初期化処理及び登録処理についても同様である。
【００９１】
そして、上記のようにして終了処理によって更新されたＨＤＤ２１上のｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータ内容については、次のようなことが言える。
先ず、イメージデータについては、ｈｄｃｃ処理対象データＦＬ２ａにより更新されている。このｈｄｃｃ処理対象データＦＬ２ａは、先の登録処理が正常に実行されてさえいれば、データベースファイルＦＬ１の登録内容に常に同期した情報内容を有している。従って、終了処理後におけるイメージデータの内容も、データベースファイルＦＬ１の登録内容と同期していることになる。
また、ｈｅａｄｅｒ領域は、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂのｈｅａｄｅｒ情報ＦＬ３により更新されるが、ｈｅａｄｅｒ情報ＦＬ３に格納されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、先の登録処理の説明から理解されるように、常に、データベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと同じ値となるようにされている。従って、終了処理後において、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）に格納されているＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとしても、データベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと一致しているべきものであることになる。
【００９２】
つまり、終了処理後においてＨＤＤ２１に保存されているｈｄｃｃ処理対象ファイルＦＬ２は、データイメージ（ｈｄｃｃ処理対象データ）として、現在のデータベースファイルＦＬ１の登録内容に同期した内容を有していることになる。このことから、先に図５及び図６により説明したように、ｈｄｃｃ処理対象データＦＬ２ａを初期化するのにあたり、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージをそのまま利用しても良いことが理解される。
【００９３】
また、上記もしているように、データベースキャッシュのための各種処理（初期化処理、登録処理、終了処理等）が正常に実行されている限りは、終了処理後においてＨＤＤ２１に保存されているｈｄｃｃ処理対象ファイルＦＬ２のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと、データベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとは、一致していることになる。これは、両者のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致していることを以て、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データ）と、データベースファイルＦＬ１の登録内容との間で整合性が得られているとみなして良いということになる。
【００９４】
これに対して、両者のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致していない場合には、これまでのデータイメージキャッシュの処理が実行された過程において、何らかのエラーが発生するなどして、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データ）のデータ内容と、データベースファイルＦＬ１の登録内容との間で整合性が失われている可能性が高いことが推定できる。
先に図５〜図７により説明した初期化処理おいて、同期が得られているか否かの判定を行うのにあたり、これらのＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅの比較により行うこととしているのは、上記したことを根拠としているものである。
【００９５】
ところで、上記実施の形態における本発明としての動作を実現するのは、ＣＰＵ１１が実行すべきプログラムであるとして説明した。このようなプログラムは、例えばＨＤＤ２１、又はＲＯＭ１３にインストールされるようにして格納されるものである。
あるいは、プログラムは、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔ Ｏｐｔｉｃａｌ）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
例えば、本実施の形態であれば、メディアドライブ１９が対応するメディアなどにプログラムを記録し、パッケージソフトウェアとして提供することができる。これにより、記録再生装置１では、メディアドライブ１９によりメディアからプログラムを読み出し、ＨＤＤ２１やＲＯＭ１３に記憶させることでインストールできる。また、このようなパッケージソフトウェアとすることで、例えば汎用のパーソナルコンピュータにも、本発明が適用されたシステムのプログラムをインストールすることは可能になる。
また、プログラムは、上記のようなリムーバブルな記録媒体からインストールする他、プログラムを記憶しているサーバなどから、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワークを介してダウンロードすることもできる。
【００９６】
さらには、例えば本発明が適用された機能を後から追加するためのアップデートプログラムを構成し、このアップデートプログラムをパッケージメディアとして配布したり、ネットワーク上で配布するようにすることも考えられる。ユーザは、このアップデートプログラムを入手して、既存のシステムがインストールされている環境に対して、このアップデートプログラムをインストールすればよい。
【００９７】
なお、本発明としては、上記実施の形態として説明した構成に限定されるものではなく、各種変更が可能である。
例えば、実施の形態においては、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２に対して、同期情報であるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとを格納しているが、この同期情報としてのＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、ｈｄｃｃ処理対象ファイルＦＬ２とは独立したもう１つのデータファイルとして、ＨＤＤ２１上に保存するように構成することも考えられる。つまり、本発明としての第２の不揮発性記憶手段と、第３の不揮発性記憶手段は、ハードウェア的に個別であっても共通であってもよい。
但し、本実施の形態のようにして、第２、第３の不揮発性記憶手段は共通であることとして、ｈｄｃｃ処理対象ファイルＦＬ２に対して、同期情報であるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを格納した１つのデータファイルとすることのほうが、データ管理が簡易に成るなどのメリットが得られることになって好ましい。
【００９８】
また、ｈｄｃｃ処理対象データＦＬ２ａを格納するｈｄｃｃ−ｃａｃｈｅ領域２０Ａと、ｈｅａｄｅｒ情報ＦＬ３を格納するｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂは、ＲＡＭ２０に対して共通に設けられる領域であるが、これらについても、ハードウェア的には異なるメモリデバイスに各領域が設定されるようにしても良いし、ハードウェア的に共通とされるメモリ領域内に保持されるようにしても良い。
この点については、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１とｈｄｃｃ処理対象ファイルＦＬ２についても同様であり、互いにハードウェア的に異なる記憶装置となるＨＤＤに記憶されていてもよいものである。
つまり、本発明における第１、第２の情報保持手段は、それぞれ異なる記憶デバイスであってもよいし、共通のデバイスであってもよい。そして、本発明における第１〜第３の不揮発性記憶手段の関係としても、同様のことがいえる。
【００９９】
また、ｈｄｃｃ処理対象データＦＬ２ａを保持するｈｄｃｃ−ｃａｃｈｅ領域２０Ａと、ｈｅａｄｅｒ情報ＦＬ３を保持するｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂは、共に揮発性の記憶領域、即ちＲＡＭであることとしているが、不揮発性の領域であってもよい。つまり、例えば初期化処理時において、ｈｄｃｃ処理対象ファイルＦＬ２を形成するｈｅａｄｅｒ領域の情報、及びデータイメージにより、不揮発性領域に記憶されるｈｅａｄｅｒ情報ＦＬ３及びｈｄｃｃ処理対象データＦＬ２ａの上書きを行ってしまえば、これまでに説明した実施の形態と同じデータベースキャッシュのシステム動作が得られるものである。
【０１００】
また、コンテンツデータ及びデータベースファイルＦＬ１、及びｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）を保存することに関しても、ＨＤＤに限定されるべきものではなく、任意の不揮発性の記憶装置、記憶媒体とされてよいものである。
【０１０１】
また、本発明の下では、初期化時において実行される、同期が得られているか否かの検証を、アプリケーション３１が起動中においても実行できるように構成することも考えられる。この場合には、例えば図１０及び図１１として示した終了時の処理（つまり、ｈｄｃｃ処理対象データＦＬ２ａ及びｈｅａｄｅｒ情報ＦＬ３の登録によってｈｄｃｃ処理対象ファイルＦＬ２を更新する処理）を、アプリケーション３１が起動中における所定の機会、タイミングで実行させる。
そのうえで、これもアプリケーション３１が起動中における所定の機会、タイミングにより、例えば図５のステップＳ１０１→Ｓ１０２→Ｓ１０３の処理を実行すればよい。そして、ステップＳ１０３の処理として、肯定結果が得られたのであれば、特に処理は実行せずに、これまでのｈｄｃｃ処理対象データＦＬ２ａの保持を継続すればよい。これに対して、否定結果が得られたのであれば、ステップＳ１０５→Ｓ１０６の処理を所要の機会で実行することで、ｈｄｃｃ処理対象データＦＬ２ａと、データベースファイルＦＬ１との再同期を図るようにすればよい。
【０１０２】
また、実施の形態では、コンテンツ対応のアプリケーションが利用するｈｄｃｃ処理対象データＦＬ２ａとして、コンテンツのリスト表示に必要なリストデータであることとしているが、これに限定されるものではない。つまり、データベースファイルの情報を利用、又は参照することで得られる情報であり、コンテンツ管理、再生などのためにアプリケーションが利用できる情報でありさえすればよいものとされる。
【０１０３】
また、実施の形態では、本発明としての情報処理を、図１に示す構成の記録再生装置１により実行させることとしているが、このような記録再生装置の構成についても適宜変更されて構わない。例えば、パーソナルコンピュータなどにより本発明としての情報処理装置を実現することも可能である。
さらに、データベースの管理対象となるコンテンツデータは、オーディオデータファイルに限定される必要はなく、例えばビデオデータであっても良い。
【０１０４】
【発明の効果】
以上説明したように本発明は、コンテンツデータ（単位データ）管理のためのデータベースをＨＤＤ（不揮発性記憶手段／記憶領域）に記憶させておくようにしている。そのうえで、このデータベースを基として作成されたｈｄｃｃ処理対象データ（ｈｄｃｃ処理対象ファイルのデータイメージ：単位データ処理用情報）を保持しておくようにされる。アプリケーション（単位データ対象処理手段）は、このｈｄｃｃ処理対象データを利用して、コンテンツデータに関する所要の処理を実行するようにされる。
そして、例えば上記アプリケーションの処理結果に応じてデータベースについての登録処理が必要となったときには、必ず、ｈｄｃｃ処理対象データについての登録処理も実行するようにされる。
これにより、本発明としては、最初にデータベースを利用してｈｄｃｃ処理対象データを作成しさえすれば、以降は、データベースに同期したｈｄｃｃ処理対象データが得られていることになる。従って、例えばアプリケーションの起動時などに伴ってｈｄｃｃ処理対象データをマウントする必要が生じたときには、逐一、データベースの情報を利用して作成するのではなく、これまでのｈｄｃｃ処理対象データをそのままマウントして利用すればい良いことになる。
データベースの情報を利用してｈｄｃｃ処理対象データを作成する処理は、重い処理であり時間もかかる。これに対して、既に在るｈｄｃｃ処理対象データをマウントする処理は軽いものであり処理時間も短い。これにより、本発明によっては、例えばアプリケーションが起動して、ｈｄｃｃ処理対象データを処理可能となるまでの時間が大幅に短縮されることになる。つまり、アプリケーションが起動を完了して操作が可能となるまでの時間が短縮されるものである。また、このときの処理も軽いものであることから、他の処理プロセスの実行効率を阻害することもない。
【図面の簡単な説明】
【図１】本発明の実施の形態としての記録再生装置の構成例を示すブロック図である。
【図２】本実施の形態の記録再生装置のＨＤＤに記憶されるコンテンツデータのディレクトリ管理を示す説明図である。
【図３】コンテンツデータ管理／再生のためのプログラムの構成を示すブロック図である。
【図４】実施の形態のデータベースファイル、及びｈｄｃｃ処理対象ファイルの構造例を示す図である。
【図５】データベースキャッシュのための処理として、初期化処理を示すフローチャートである。
【図６】図２に示すプログラム構成のもとでの初期化処理のシーケンスを示すアローチャートである。
【図７】図３に示すプログラム構成のもとでの初期化処理のシーケンスを示すアローチャートである。
【図８】データベースキャッシュのための処理として、登録処理を示すフローチャートである。
【図９】図３に示すプログラム構成のもとでの登録処理のシーケンスを示すアローチャートである。
【図１０】データベースキャッシュのための処理として、終了処理を示すフローチャートである。
【図１１】図３に示すプログラム構成のもとでの終了処理のシーケンスを示すアローチャートである。
【符号の説明】
１ 記録再生装置、１１ ＣＰＵ、１２ バス、１３ ＲＯＭ、１４ 操作入力部、１５ 入力処理部、１６ 表示処理部、１７ ディスプレイモニタ、１８ＣＤドライブ制御部、１９ メディアドライブ、２０ ＲＡＭ、２１ ＨＤＤ、２２ 通信処理部、２３ ネットワークインターフェイス、２４ オーディオデータ処理部、２５ スピーカ、２６ アンテナ、２７ チューナ、３１ アプリケーション、３２ ｈｄｃｃ（ハードディスクコンテンツコントローラ）、３３ ｃｄａｍ（コンテンツデータアクセスモジュール）、３４ データベースモジュール、３５ ファイルシステム、２０Ａ ｈｄｃｃ−ｃａｃｈｅ領域、２０Ｂ ｈｅａｄｅｒ−ｃａｃｈｅ領域、ＦＬ１ データベースファイル、ＦＬ２ ｈｄｃｃ処理対象ファイル、ＦＬ２ａ ｈｄｃｃ処理対象データ、ＦＬ３ ｈｅａｄｅｒ情報
【発明の属する技術分野】
本発明は、例えばコンテンツデータの再生等をはじめとした、コンテンツデータを対象とする各種の処理を実行可能な情報処理装置、及びその方法に関する。また、このような情報処理装置に実行させるプログラム、また、このプログラムが記憶された記憶媒体に関する。
【０００２】
【従来の技術】
近年、安価な大容量のハードディスク（ＨＤＤ）が普及してきている。これに伴って、例えばＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）などのメディアに記録されているオーディオデータをハードディスクに記録して保存する、いわゆるリッピングを行うことが広く普及している。このようなリッピングは、例えばＣＤを再生可能なディスクドライブと、ＨＤＤとを組み合わせたオーディオ機器を構成することで可能となる。また、例えばパーソナルコンピュータによっても行うことが可能とされる。
なお、ＣＤの音源をリッピングするのにあたっては、例えばＡＴＲＡＣ（Ａｄａｐｔｉｖｅ Ｔｒａｎｓｆｏｒｍ Ａｃｏｕｓｔｉｃ Ｃｏｄｉｎｇ）方式やＭＰ３（ＭＰＥＧ Ａｕｄｉｏ Ｌａｙｅｒ ＩＩＩ）方式などによりオーディオデータを圧縮して記録することが一般には行われる。
【０００３】
このようにして、リッピングにより、多数の楽曲などのオーディオデータをファイルとしてハードディスクに記憶させておくようにすれば、ユーザは、逐一自分が聴きたいアルバムのＣＤを交換して再生するような煩わしさから開放されることになり、これまでよりも充実した音楽リスニング環境を得ることができる。
なお、本明細書において、上記したオーディオデータをはじめとして、ＨＤＤ等の記憶媒体に記憶されるファイル単位のＡＶ（Ａｕｄｉｏ Ｖｉｄｅｏ）データについては、「コンテンツデータ」ともいうことにする。
【０００４】
そして、ＨＤＤに記録された多数のコンテンツデータを管理、再生するコンテンツ管理アプリケーションでは、コンテンツデータの管理、再生を効率的に行うために、データベースを利用するのが一般的である。
【０００５】
このようなデータベースも、上記コンテンツ管理アプリケーションにより作成され、ＨＤＤに記憶される。
そして、このデータベースによっては、コンテンツデータごとのＨＤＤにおけるディレクトリ（パス）が管理される。また、コンテンツデータごとについてのタイトル、アーティスト名、圧縮フォーマットなどをはじめとする各種の属性情報も管理される。さらに、コンテンツデータには、アルバムジャケットや歌詞カードとしての画像データなどに代表されるフリンジデータといわれる関連データも付随してＨＤＤに記録される場合があるが、このようなフリンジデータのパスを示すなど、フリンジデータについての管理も行うようになっている。
【０００６】
そして、例えば上記コンテンツ管理アプリケーションが起動されるときには、データベースから必要な情報を選択、抽出して収集し、これらの収集された情報を利用して、コンテンツ管理アプリケーションがコンテンツ管理、再生のために直接的に利用する、コンテンツ処理対象データを作成するようにされる。このコンテンツ処理対象データとしては、例えば、データベースに登録されているコンテンツをリストとして一覧表示させるのに必要なリストデータを挙げることができる。従って、このような場合のコンテンツ管理アプリケーションに対する操作は、上記コンテンツ処理対象データの作成が完了してリスト表示が行われた後にはじめて可能となる。
【０００７】
このようにして作成されたコンテンツ処理対象データは、ＨＤＤではなく、例えばＲＡＭなどによるキャッシュに展開される。コンテンツ管理アプリケーションは、このようにして、キャッシュ上に展開されたコンテンツ処理対象データを解釈して、例えば上記したようなリスト表示等を実行するようにされている。つまり、コンテンツ処理対象データをキャッシュに保持させた後は、ＨＤＤに記憶されるデータベースではなく、このキャッシュの領域にアクセスしてコンテンツ処理対象データを処理すればよいこととなり、効率的なコンテンツ管理、再生動作を得ることができる。例えば、このようなキャッシュを利用したデータリード／ライトのための技術としては、特許文献１に記載されたものが知られている。
なお、ここでいうキャッシュとは、あくまでもＲＡＭなどの揮発性のメモリ上においてコンテンツ処理対象データが展開される領域を指すものであり、例えば、いわゆるキャッシュメモリともいわれる、ＣＰＵとＲＡＭ、ＨＤＤなどの間に介在するメモリとは意味が異なる。
【０００８】
【特許文献１】
特開２００２−２７４１９号公報
【０００９】
【発明が解決しようとする課題】
しかしながら、上記したようなコンテンツ処理対象データの作成にあたり、データベースから必要な情報をフィルタリングして抽出する処理は比較的重いものであり、相応に時間を要する。
従って、現状においては、例えばリスト表示が完了するなど、コンテンツ管理アプリケーションが起動を完了して操作が可能となるまでには、或る程度の時間がかかってしまっている。これは、例えばユーザにとってはストレスとなるので好ましいことではない。特に、管理するコンテンツデータ数が増えるにしたがって、コンテンツ処理対象データを作成するのに要する時間も長くなるので、この場合には、上記した問題がさらに顕著となってしまう。
【００１０】
また、実際のシステムでは、コンテンツ処理対象データを作成するのに時間がかかることを考慮して、例えばリスト表示に関すれば、１画面分を表示するのに必要とされる情報のみによりコンテンツ処理対象データを作成するようにしている。そして、例えばリスト表示がスクロールされるのに応じて、リスト表示のためのデータが無くなるのに応じて、また、データベースにアクセスしてコンテンツ処理対象データを作成するようにしている。このようにして、現状では必要最小限のコンテンツ処理対象データを逐次作成するという処理アルゴリズムとしているのが一般的である。
【００１１】
このような処理アルゴリズムである場合、コンテンツ処理対象データを作成するごとに相応の処理時間を要するのであるから、例えばスクロールに応じたリスト表示もスムーズなものではなくなってしまい、この点でも、ユーザに対してストレスを与えることになる。
また、スクロール操作などに応じて不定期でデータベースへのアクセスが実行されることになるから、例えば、コンテンツデータについての再生など、実時間的処理を実行している他の処理の速度を遅くする要因にもなる。これにより、例えばコンテンツデータの安定した再生を阻害する可能性がある。また、同じ理由から、例えばライブ音源などのようにコンテンツデータ間での連続再生が要求されるような再生や、リピート再生及びランダム再生などの特殊再生を安定して実行することが困難となる可能性がある。
【００１２】
このようにして、現状におけるコンテンツ処理対象データの作成、及びキャッシュのための処理では、コンテンツ処理対象データを作成するのに相応の時間を要することから、コンテンツ管理アプリケーションの起動が開始されてから操作が可能となるまでの時間も相応に長いものとなっており、また、他の処理プロセスの安定性を阻害する可能性があるという問題を有している。
【００１３】
【課題を解決するための手段】
そこで、本発明は上記した課題を考慮して、情報処理装置として次のように構成する。
つまり、所定の記憶媒体に記憶されている１以上の単位データを管理するデータベースが記憶される第１の不揮発性記憶手段と、データベースに対する登録処理を実行する第１の登録手段と、データベースを形成する情報のうちから所定の情報を利用して作成されたものであり、単位データを対象とする所要の処理に利用される、単位データ処理用情報が保持される第１の情報保持手段と、単位データ処理用情報を利用して、単位データについての所要の処理を実行する単位データ対象処理手段と、単位データ処理用情報に対する登録処理を実行する第２の登録手段とを備える。
そして、上記第２の登録手段は、単位データ対象処理手段が実行した処理結果に応じて、第１の登録手段によるデータベースに対する登録処理が実行されるときには、上記処理結果に応じた単位データ処理用情報に対する登録処理を実行するように構成する。
【００１４】
また、情報処理方法としては、所定の記憶媒体に記憶されている１以上の単位データを管理する情報であり、不揮発性記憶領域に記憶されているデータベースに対する登録処理を実行する第１の登録処理と、データベースを形成する情報のうちから所定の情報を利用して作成され、単位データを対象とする所要の処理に利用される情報であり、情報保持領域に保持されるコンテンツ処理用情報を利用して、上記単位データについての所要の処理を実行する単位データ対象処理と、コンテンツ処理用情報に対する登録処理を実行する第２の登録処理とを実行するものとされる。
そして、上記第２の登録処理は、単位データ対象処理としての処理結果に応じて、第１の登録処理によるデータベースに対する登録処理が実行されるときには、上記処理結果に応じた単位データ処理用情報に対する登録処理を実行するように構成することとしている。
【００１５】
また、プログラムとしては、所定の記憶媒体に記憶されている１以上の単位データを管理する情報であり、不揮発性記憶領域に記憶されているデータベースに対する登録処理を実行する第１の登録処理と、データベースを形成する情報のうちから所定の情報を利用して作成され、単位データを対象とする所要の処理に利用される情報であり、情報保持領域に保持されるコンテンツ処理用情報を利用して、上記単位データについての所要の処理を実行する単位データ対象処理と、コンテンツ処理用情報に対する登録処理を実行する第２の登録処理とを情報処理装置に実行させるものとされる。
そして、上記第２の登録処理は、単位データ対象処理としての処理結果に応じて、第１の登録処理によるデータベースに対する登録処理が実行されるときには、上記処理結果に応じた単位データ処理用情報に対する登録処理を実行するように構成するものである。
【００１６】
また、上記プログラムを記憶して記憶媒体を構成することとした。
【００１７】
上記各構成によれば、第１の不揮発性手段（不揮発性領域）に記憶されているデータベースを基にして作成されたコンテンツ処理用情報が第１の情報保持手段（情報保持領域）に保持されていることになる。
そして、単位データを対象とした単位データ対応処理を実行するのにあたっては、上記第１の情報保持手段（情報保持領域）に保持されているコンテンツ処理用情報を利用するようにされる。
そして、単位データ対応処理の処理結果に応じて、データベースへの登録処理を行うときには、これと共に、同じ単位データ対応処理の処理結果に応じて、上記第１の情報保持手段（情報保持領域）に保持されているコンテンツ処理用情報についての登録処理も行うようにされる。
これにより、最初にデータベースを基にしてコンテンツ処理用情報を作成した後は、上記した登録処理によって、データベースとコンテンツ処理用情報との内容について同期している状態が常に得られていることになる。
【００１８】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。なお、以降の説明は次の順序で行う。
１．記録再生装置の構成
２．コンテンツデータのディレクトリ管理
３．コンテンツデータ管理のためのプログラム構成
４．ファイル構造
５．初期化処理
６．登録処理
７．終了処理
【００１９】
１．記録再生装置の構成
図１のブロック図は、本発明の実施の形態としての情報処理装置が適用される記録再生装置１の構成例を示している。
ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１は、起動されたプログラムに基づいて記録再生装置１の全体の制御、演算処理を行う。例えばネットワークを介した通信動作、ユーザーに対する入出力動作、メディアからのコンテンツ再生やリッピング、ＨＤＤ２１へのコンテンツ記憶やそのための管理などを行う。なお、以降の説明を単純なものとするために、本実施の形態の記録再生装置１が対応して記録再生可能なコンテンツデータとしては、オーディオのコンテンツデータであることとする。
ＣＰＵ１１はバス１２を介して各回路部との間で制御信号やデータのやりとりを行う。
【００２０】
ＲＯＭ１３は、ＣＰＵ１１が実行すべき動作プログラム、プログラムローダーや、各種演算係数、プログラムで用いるパラメータ等が記憶される。
また、ＲＡＭ２０には、ＣＰＵ１１が実行すべきプログラムが展開される。また、ＣＰＵ１１が各種処理を実行する際において必要となるデータ領域、タスク領域としても用いられる。
【００２１】
操作入力部１５は、記録再生装置１の筐体に設けられた操作キーやジョグダイヤル、タッチパネルなどの各種操作子などから成る部位である。なお、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）操作のためのキーボードやマウスが操作入力部１５として設けられてもよい。また、操作入力部１５としては、リモートコントローラとされてもよい。
操作入力部１５で入力された情報は入力処理部１４において所定の処理が施され、ＣＰＵ１１に対して操作コマンドとして伝送される。ＣＰＵ１１は入力された操作コマンドに応答した機器としての動作が得られるように、所要の演算や制御を行う。
【００２２】
ディスプレイモニタ１７としては、例えば液晶ディスプレイなどの表示デバイスが接続され、各種情報表示が行われる。
ＣＰＵ１１が各種動作状態や入力状態、通信状態に応じて表示情報を表示処理部１６に供給すると、表示処理部１６は供給された表示データに基づいてディスプレイモニタ１７に表示動作を実行させる。
例えば本実施の形態の場合であれば、リッピングされたオーディオファイルを再生管理するプログラムに従っては、オーディオファイルを管理、再生するためのＧＵＩ画面が表示される。
【００２３】
この場合のメディアドライブ１９は、所定のメディアに対応して少なくとも再生が可能なドライブとされる。もちろんのこと、所定メディアに対応して、再生だけではなく、記録が可能なドライブとされても良い。
また、この場合のメディアドライブ１９が対応するメディアとしては、特に限定されるべきものではないが、例えばＣＤ、ＤＶＤ、ミニディスクなどの各種光学ディスク状記録媒体とされても良い。あるいは、フラッシュメモリなどのメモリ素子により構成されたメディアとされてもよい。また、メディアドライブとしては、例えばこれらの各種メディアに対応した各種のドライブが個々に設けられてバス１２と接続される構成とされてもよいものである。
【００２４】
例えばユーザーが操作入力部１５に対する操作によって、メディアドライブ１９による再生指示を行った場合は、ＣＰＵ１１は、メディアドライブ１９に対してメディアに対する再生を指示する。これに応じて、メディアドライブ１９は、装填されているメディアから、指定されたデータにアクセスして読み出しを実行する。
【００２５】
このようにして読み出されたデータが、オーディオコンテンツである場合には、必要に応じてＣＰＵ１１の処理によってデコード処理等が施された後、オーディオ入出力処理部２４に転送される。オーディオ入出力処理部２４においては、イコライジング等の音場処理や音量調整、Ｄ／Ａ変換、増幅等の処理が施され、スピーカ部２５から出力される。
【００２６】
またメディアドライブ１９にて再生されたデータは、ＣＰＵ１１の制御によって、ＨＤＤ２１にオーディオデータファイルとして蓄積することもできる。つまり、いわゆるリッピングにより得たオーディオデータファイルをコンテンツデータとして記憶させることができる。
なお、このオーディオデータファイルの形式としては、ＣＤフォーマットにおけるサンプリング周波数４４．１ＫＨｚで１６ビット量子化のデジタルオーディオデータとされてもよいし、ＨＤＤ２１の容量を節約するために、所定方式にしたがって圧縮処理が施された形式の圧縮オーディオデータとされてもよい。また、圧縮方式としても限定されるものではないが、ＡＴＲＡＣ（Ａｄａｐｔｉｖｅ Ｔｒａｎｓｆｏｒｍ Ａｃｏｕｓｔｉｃ Ｃｏｄｉｎｇ）方式やＭＰ３（ＭＰＥＧ Ａｕｄｉｏ Ｌａｙｅｒ ＩＩＩ）方式などを採用することができる。
【００２７】
チューナ部２７は、例えばＡＭ・ＦＭラジオチューナとされ、ＣＰＵ１１の制御に基づいて、アンテナ２６で受信された放送信号を復調する。もちろんテレビチューナや衛星放送チューナ、デジタル放送チューナなどとしてのチューナでもよい。
復調された放送音声信号は、オーディオデータ処理部２４において所要の処理が施され、スピーカ部２５から放送音声として出力される。
【００２８】
通信処理部２２は、ＣＰＵ１１の制御に基づいて送信データのエンコード処理、受信データのデコード処理を行う。
ネットワークインターフェイス２３は、通信処理部２２でエンコードされた送信データをネットワークを介して所定の外部ネットワーク対応機器に送信する。またネットワークを介して外部ネットワーク対応機器から送信されてきた信号を通信処理部２２に受け渡す。
通信処理部２２は受信した情報をＣＰＵ１１に転送する。
【００２９】
なお、記録再生装置１の構成は、この図１の構成に限られるものではなく、更に多様に考えられる。
例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、ＩＥＥＥ１３９４、Ｂｌｕｅｔｏｏｔｈなどの通信方式による周辺機器とのインターフェースが設けられるようにしてもよい。
そして、上記ネットワークインターフェイス２３によりネットワークを介してダウンロードしたオーディオのコンテンツデータや、上記ＵＳＢ、ＩＥＥＥ１３９４などのインターフェイスを経由して転送されてきたオーディオのコンテンツデータについても、ＨＤＤ２１に対して記憶させることができる。
またマイクロホンや外部のヘッドホンの接続に用いられる端子や、ＤＶＤ再生時に対応するビデオ出力端子、ライン接続端子、光デジタル接続端子等が設けられてもよい。
またＰＣＭＣＩＡスロット、メモリカードスロットなどが形成され、外部の情報処理装置やオーディオ機器とデータのやりとりが可能とされてもよい。
【００３０】
２．コンテンツデータのディレクトリ管理
上記図１による説明から理解されるように、本実施の形態の記録再生装置１では、ＨＤＤ２１に対して、オーディオデータファイルとしてのコンテンツデータを記憶することができる。
このコンテンツデータは、ＨＤＤ２１上において、図２に示すようにして管理される。
先ず、ｒｏｏｔディレクトリの下層に対しては、規定範囲内での任意の数のｆｏｌｄｅｒを置くことができる。このｆｏｌｄｅｒは、例えばコンテンツデータが属するジャンル、または所有ユーザなどに対応して作成される。
そして、このｆｏｌｄｅｒの下層には、規定範囲内での任意の数のａｌｂｕｍを置くようにされている。ａｌｂｕｍは、例えば１つのアルバムタイトルごとに対応する。そして、このａｌｂｕｍのディレクトリ下において、そのａｌｂｕｍに属するとされる１以上のｔｒａｃｋを位置させるようにしている。このｔｒａｃｋごとの単位データが、１つのコンテンツデータとなるものである。
このようなコンテンツデータについてのディレクトリ管理は、ＨＤＤ２１に記憶されているデータベースファイルによって行われている。なお、データベースファイルについては後述する。
【００３１】
３．コンテンツデータ管理のためのプログラム構成
そして、本実施の形態では、コンテンツデータについての管理／再生を可能とするためのプログラムもＨＤＤ２１にインストールされるようにして記憶されている。
図３は、このようなコンテンツデータ管理／再生のためのプログラムの構成をブロック図として示している。なお、確認のために述べておくと、この図に示される各種プログラムは、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）上で動作するものである。
先ず、プログラムとして最上層に位置しているアプリケーション３１は、コンテンツデータに対応した所要の機能動作を実行可能なアプリケーションプログラムである。ここでは、アプリケーション３１は、ＨＤＤ２１に記憶されているオーディオデータファイルとしてのコンテンツについて管理、再生等が可能な、いわゆるコンテンツプレーヤとしての機能を有しているものとされる。
このアプリケーション３１は、例えばユーザによるアプリケーション３１に対する操作やプログラム動作の流れに従って、下位層に対してコマンド、イベント等の発行を行う。これにより、アプリケーション３１としての動作が実現される。
【００３２】
なお、この図に示すプログラム構成において、本実施の形態のデータベースキャッシュを利用しながら、コンテンツデータを対象とした処理を実行するアプリケーションとしては、上記コンテンツプレーヤとしてのアプリケーション３１以外のものであってもよい。また、このような本実施の形態のデータベースキャッシュを利用するアプリケーションが複数インストールされていてもよいものである。そして、このようなアプリケーションが複数インストールされている場合には、例えば、これらのアプリケーションを同時に起動させたうえで、これらのアプリケーションの間で、これより下層のプログラムによるデータベースキャッシュシステムを共用するようにすることも考えられる。
【００３３】
アプリケーション３１の下層にはハードディスクコンテンツコントローラ（ｈｄｃｃ）３２としてのプログラムが位置する。
このｈｄｃｃ３２は、アプリケーション３１から発行されるコマンド等を解釈することができる。そして、アプリケーション３１から発行されるコマンドに応じた処理として、下層のコンテンツデータアクセスモジュール３３に対する制御を実行する。
【００３４】
また、ｈｄｃｃ３２は、ＲＡＭ２０内のｈｄｃｃ−ｃａｃｈｅ領域２０Ａ（第１の情報保持手段）に保持される、ｈｄｃｃ処理対象データＦＬ２ａについての管理、処理を行う。
ｈｄｃｃ処理対象データＦＬ２ａは、最初は、データベースファイルＦＬ１を形成しているテーブル群から、アプリケーション３１がコンテンツ管理、再生を実行するのに必要とされる所要の情報を抽出して作成されるデータである。
アプリケーション３１の起動中においては、ＨＤＤ２１に記憶されているコンテンツのリストを、その属性情報（タイトル、アーティスト、属するアルバムタイトル等）、及びアルバムジャケットの画像データをはじめとしたコンテンツに関連するデータ（フリンジデータ）などと共に表示する。ｈｄｃｃ処理対象データＦＬ２ａは、例えばこのようなコンテンツデータのリスト表示に必要とされる属性情報、デコード処理後のフリンジデータなどを有して構築されている。
また、例えばコンテンツデータが記憶されるＨＤＤ２１上のパスなどの情報も有している。このコンテンツデータのパスの情報を参照することで、例えばファイルシステムを利用して再生対象のコンテンツデータをＨＤＤ２１から読み出して再生処理を実行することが可能となる。
【００３５】
つまり、ｈｄｃｃ処理対象データＦＬ２ａは、アプリケーション３１、又はｈｄｃｃ３２が、コンテンツデータを対象とした管理、再生などの所要の処理を実行するのに利用する情報となる。換言すれば、データベースファイルＦＬ１を、アプリケーション３１、又はｈｄｃｃ３２が処理可能な形式に再構築した情報である。
【００３６】
コンテンツデータアクセスモジュール（ｃｄａｍ）３３は、コンテンツデータに関連したデータの読み出し、書き込みのためのＨＤＤ２１へのアクセスを担当するプログラムである。このために、ｃｄａｍ３３の下層には、ＨＤＤ２１（第１の不揮発性記憶手段）に記憶されるデータベースファイルＦＬ１についての処理を実行するプログラムであるデータベースモジュール（ｄｂ）３４が位置する。また、ＨＤＤ２１からファイル単位での読み出し／書き込みを実行するファイルシステム（ｆｓｙｓ）３５が位置する。この図では、ＨＤＤ２１（第２，第３の不揮発性記憶手段）に記憶されるファイルであって、ファイルシステム（ｆｓｙｓ）３５により読み出し／書き込みされるべきファイルとして、コンテンツデータ管理に関連するｈｄｃｃ処理対象ファイルＦＬ２が示されている。なお、ｈｄｃｃ処理対象ファイルＦＬ２については図４により後述する。
【００３７】
また、ｃｄａｍ３３は、ＲＡＭ２０におけるｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂ（第２の情報保持手段）に保持されるｈｅａｄｅｒ情報ＦＬ３についての書き込み／読み出し処理を実行する。なお、このｈｅａｄｅｒ情報ＦＬ３についても図４により後述する。
【００３８】
このようにして、コンテンツデータを管理するプログラム構成としては、アプリケーション３１、ｈｄｃｃ３２、ｃｄａｍ３３、データベースモジュール３４３４、及びファイルシステム３５から成るものとされる。
そして、これらのプログラム構成の下で、コンテンツデータ管理のために利用する情報としては、データベースファイルＦＬ１、ｈｄｃｃ処理対象ファイルＦＬ２、ｈｄｃｃ処理対象データＦＬ２ａ、及びｈｅａｄｅｒ情報ＦＬ３とされている。
ここで、データベースファイルＦＬ１、ｈｄｃｃ処理対象ファイルＦＬ２は、不揮発性の記憶領域であるＨＤＤ２１に記憶されるデータであり、例えば電源供給が停止しても保存されるデータである。
これに対して、ｈｄｃｃ処理対象データＦＬ２ａ、ｈｅａｄｅｒ情報ＦＬ３は、揮発性の記憶領域であるＲＡＭ２０内において確保される記憶領域に対して保持されるものであり、例えば、アプリケーション３１の終了に伴って、消去されてもよい情報である。
【００３９】
４．ファイル構造
上記のようにして、本実施の形態において、コンテンツデータ管理のために利用する情報は、データベースファイルＦＬ１、ｈｄｃｃ処理対象ファイルＦＬ２、ｈｄｃｃ処理対象データＦＬ２ａ、及びｈｅａｄｅｒ情報ＦＬ３となる。これらの情報の説明のために、図４を参照して、データベースファイルＦＬ１及びｈｄｃｃ処理対象ファイルＦＬ２の構造について説明する。
【００４０】
図４（ａ）には、データベースファイルＦＬ１が示されている。
このデータベースファイルＦＬ１には、先に図２に示したようなコンテンツデータ間のディレクトリ構造を管理する情報が格納されている。
また、例えばコンテンツデータごとのＨＤＤ２１におけるディレクトリ（パス）が管理される。
また、コンテンツデータごとについてのタイトル、アーティスト名、圧縮フォーマットなどをはじめとする各種の属性情報も管理される。
さらに、コンテンツデータには、アルバムジャケットや歌詞カードとしての画像データなどに代表されるフリンジデータといわれる関連データも付随してＨＤＤ２１に記録される場合があるが、このようなフリンジデータのパスを示すなど、フリンジデータについての管理も行うようにされているものである。
【００４１】
そして、本実施の形態のデータベースファイルＦＬ１としては、上記したような各種所要の情報を、テーブル単位ごとに所定の構造により格納すると共に、図４（ａ）に示しているように、所定領域に対して、所定のデータサイズによるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを格納することとしている。
このＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、後述するようにして、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１と、同じくＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２との内容について、整合性確認を行う（同期状態を調べる）のに必要とされる情報である。本実施の形態では、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、データベースファイルＦＬ１に対して最後に登録（更新）が行われた日時を示す情報であることとしている。また、データエントリ数、やデータ構造を示す情報などをはじめ、データ内容を識別する所定のデータ内容識別情報とされてもよい。また、これら日時情報と所定のデータ内容識別情報との組み合わせとされてもよい。
【００４２】
図４（ｂ）には、ＨＤＤ２１に記憶される、ｈｄｃｃ処理対象ファイルＦＬ２の構造が示されている。
なお、後述するようにして、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持されるｈｄｃｃ処理対象データＦＬ２ａを初期化するのにあたっては、通常はデータベースファイルＦＬ１から再構築をするのではなく、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージをそのままｈｄｃｃ−ｃａｃｈｅ領域２０Ａに転送して保持させるようにしている。
つまり、ｈｄｃｃ処理対象ファイルＦＬ２は、データベースシステムにおけるキャッシュデータとしての意味を持つ。そこで、以降においては、このｈｄｃｃ処理対象ファイルＦＬ２について、ｃａｃｈｅ ｆｉｌｅともいう場合がある。
【００４３】
この図４（ｂ）に示すようにして、ｈｄｃｃ処理対象ファイルＦＬ２は、先頭に所定サイズのｈｅａｄｅｒ領域が配置され、これに続けて、ｈｄｃｃ処理対象ファイルＦＬ２としての実データである、データイメージが格納される。
そして、ｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域のデータが、ＲＡＭ２０のｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂ内に格納されるｈｅａｄｅｒ情報ＦＬ３となる。また、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージが、そのまま、ＲＡＭ２０内のｈｄｃｃ−ｃａｃｈｅ領域２０Ａに格納されるべき、ｈｄｃｃ処理対象データＦＬ２ａのデータ内容となる。
【００４４】
つまり、ＨＤＤ２１にアクセスして、ｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域のデータを取得し、このデータをｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに書き込んで保持させることで、ｈｅａｄｅｒ情報ＦＬ３が得られる。
同様にして、ＨＤＤ２１にアクセスして、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージを取得し、このデータイメージをｈｄｃｃ−ｃａｃｈｅ領域２０Ａに書き込んで保持させることで、ｈｄｃｃ処理対象データＦＬ２ａが得られる。
【００４５】
図４（ｃ）には、ｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域の構造が示されている。確認のために述べておくと、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂにて保持されるｈｅａｄｅｒ情報ＦＬ３も同様の構造を有する。
先ず、先頭の所定サイズの領域には、ファイル種別を識別するための識別情報が格納される。つまり、この領域に格納される値により、ファイル種別がｈｄｃｃ処理対象ファイルＦＬ２であることを示す。この場合には、例えば「Ｃ Ｄ Ｍ Ａ」との記述に対応したビットの値が格納される。
【００４６】
Ｅｄｉｔ Ｆｌａｇは、データ保護のために必要となる情報であり、このフラグの値を参照することで、ＨＤＤ２１への書き込みが正常に行われたか否かを推定することができる。
【００４７】
本実施の形態において、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）は、複数記憶される場合がある。ｃａｃｈｅ ＩＤは、このような場合に対応して、個々のｈｄｃｃ処理対象ファイルＦＬ２を識別するための識別子である。
Ｆｏｒｍａｔ Ｖｅｒｓｉｏｎには、ｈｄｃｃ処理対象ファイルＦＬ２としてのフォーマットのバージョンを示す値が格納される。
【００４８】
このｈｅａｄｅｒ領域におけるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、先に図４（ａ）により示したデータベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと同じ意義を有する。
つまり、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１と、同じくＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２との内容についての同期をとる（整合性を確認する）ために必要とされる情報であり、データベースファイルＦＬ１に対して最後に登録（更新）が行われた日時を示す。
【００４９】
ここで、上記したファイル種別識別情報（Ｃ Ｄ Ｍ Ａ）、Ｅｄｉｔ Ｆｌａｇ、ｃａｃｈｅ ＩＤ、Ｆｏｒｍａｔ Ｖｅｒｓｉｏｎ、及びＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが格納される領域は、ｃｄａｍ３３が解釈して処理する情報とされる。
これに対して、ｕｓｅｒ ａｒｅａの領域に対しては、ｈｄｃｃ３２が解釈して処理可能な任意の情報を格納することができることとされている。
【００５０】
例えば、ｃｄａｍ３３は、アプリケーション側の層にあるとされるプログラムではなく、ＯＳ側の層（システム側）にあるとされるプログラムであり、比較的プリミティブな処理を実行する。これに対して、ｃｄａｍ３３の上層にあるｈｄｃｃ３２は、アプリケーション側のプログラムであり、より高度な処理を実行する。例えば、コンテンツデータのディレクトリに関すれば、ｈｄｃｃ３２は、データベースの情報を参照して、例えば図２に示したディレクトリ構造全体におけるコンテンツデータの位置を認識することが可能である。これに対して、ｃｄａｍ３３は、１つのディレクトリを基準とした親又は子のディレクトリについての認識にとどまる。
そこで、必要に応じて、ｈｄｃｃ３２が対応して処理すべき所要のデータをｕｓｅｒ ａｒｅａに格納しておくようにすれば、ｈｄｃｃ処理対象ファイルＦＬ２を効率的に利用して、コンテンツ管理等に関しての高度な機能を付加することが可能になる。
【００５１】
５．初期化処理
これまでの説明を踏まえて、本実施の形態におけるコンテンツ対応のデータベースキャッシュのための処理動作について説明を行っていくこととし、先ず、初期化処理について説明することとする。
【００５２】
ところで、以降の説明から理解されることであるが、ｈｄｃｃ処理対象データＦＬ２ａは、元々は、データベースファイルＦＬ１を再構築して作成されたものである。しかしながら、本実施の形態では、ｈｄｃｃ処理対象データＦＬ２ａについて、ＨＤＤ２１に記憶させたｈｄｃｃ処理対象ファイルＦＬ２から取得したデータイメージを、そのままｈｄｃｃ処理対象データＦＬ２ａとしてｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持させるようにしている。つまり、データベースシステムにおいて、ｈｄｃｃ処理対象ファイルＦＬ２は、ｈｄｃｃ処理対象データＦＬ２ａを取得する際のキャッシュデータとして扱われる。ここでいうデータベースキャッシュとは、このようなシステム動作をいうものである。
また、ここでいう初期化処理とは、例えばアプリケーション３１が起動されることなどに応じて、これまでは空き領域であった、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに対して、ｈｄｃｃ処理対象データＦＬ２ａをマウント（保持）させるための処理である。
【００５３】
図５は、初期化処理の流れをフローチャートにより示している。なお、この図に示す処理は、例えば図４に示したプログラム構成の下で、ＣＰＵ１１がこれらのプログラム従って実行するものとされる。
例えば、アプリケーション３１が起動されるなどして初期化を実行するためのコマンドが発行されたとすると、ステップＳ１０１の処理を実行することになる。
ステップＳ１０１においては、ＨＤＤ２１に記憶されているデータベースファイルＦＬ１にアクセスして、データベースファイルＦＬ１を形成している各テーブルから、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得する。つまり、図４（ａ）にて説明したようにして、データベースファイルＦＬ１の各テーブルの構造内に格納されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅの読み込みを実行する。
【００５４】
次のステップＳ１０２においては、ＨＤＤ２１に記憶されているｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）にアクセスする。そして、ｈｅａｄｅｒ領域に格納されているＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得する。
【００５５】
上記ステップＳ１０１及びステップＳ１０２の処理によっては、データベースファイルＦＬ１及びｈｄｃｃ処理対象ファイルＦＬ２のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが取得されたことになる。そして、ステップＳ１０３においては、このデータベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと、ｈｄｃｃ処理対象ファイルＦＬ２のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとについて比較を行い、これらのＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅについて値が一致しているか否かについて判定する。
後述する登録処理及び終了処理が正常に行われれば、データベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと、ｈｄｃｃ処理対象ファイルＦＬ２のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとは一致していることになる。Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致している場合、データベースファイルＦＬ１の内容と、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージの内容とは同期している（整合性が得られている）ことを意味する。これに対して、一致していなければ、例えば何らかの要因によって、データベースファイルＦＬ１の内容と、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージの内容との間で整合が得られていない状態であることを示すことになる。つまり、ステップＳ１０３の処理は、データベースファイルＦＬ１とｈｄｃｃ処理対象ファイルＦＬ２のデータイメージとの間で同期が得られている状態にあるか否かを判定する処理である。
【００５６】
そして、ステップＳ１０３において、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致しているとして肯定結果が得られた場合には、ステップＳ１０４の処理に進む。Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致している場合、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータイメージの内容は、データベースファイルＦＬ１の登録内容と同期が得られている。つまり、現在のデータベースファイルＦＬ１の登録内容が正常に反映された内容を有しているということであり、このデータイメージを、そのままｈｄｃｃ処理対象データとして利用して良いということになる。
そこで、ステップＳ１０４の処理としては、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）にアクセスして、データイメージを読み込んで取得する。そして、この取得したデータイメージを、ｈｄｃｃ処理対象データＦＬ２ａとして、ＲＡＭ２０のｈｄｃｃ−ｃａｃｈｅ領域２０Ａに対して書き込んで展開させる。以降、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａには、ｈｄｃｃ処理対象データＦＬ２ａが保持された状態が得られる。
【００５７】
一方、ステップＳ１０３において、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致していないとして否定結果が得られた場合、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータイメージの内容は、データベースファイルＦＬ１の登録内容と整合していない、つまり、同期していないということになる。
ここで、ｈｄｃｃ処理対象ファイルＦＬ２のイメージデータは、あくまでもデータベースファイルＦＬ１を基として作成されるものである。つまり、データベースファイルＦＬ１の登録内容が基準となるものであり、従って、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータイメージと、データベースファイルＦＬ１とでは、データベースファイルＦＬ１の内容を信頼すべきこととなる。
このことに基づいて、ステップＳ１０５以降の処理は、データベースファイルＦＬ１を利用して新たに作成したｈｄｃｃ処理対象データＦＬ２ａを、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａにマウントするための処理となる。
【００５８】
つまり、ステップＳ１０５では、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１にアクセスして、ｈｄｃｃ処理対象データＦＬ２ａを構築するのに必要な情報を各テーブルから選択、抽出して収集する処理を実行する。
次のステップＳ１０６では、収集した情報によりｈｄｃｃ処理対象データＦＬ２ａを作成する。そして、この作成したｈｄｃｃ処理対象データＦＬ２ａを、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに転送して書き込み、ここに展開して保持させる。
上記ステップＳ１０４又はステップＳ１０６の処理が終了して以降においては、例えばアプリケーション３１、及びｈｄｃｃ３２は、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持されたｈｄｃｃ処理対象データＦＬ２ａを利用して、例えばリスト表示をはじめとした所要の処理を実行することができる。これは、ステップＳ１０４又はステップＳ１０６の処理の完了を以て、アプリケーション３１に対する操作が可能となることを意味する。
【００５９】
この図５に示した処理によると、初期化処理にあたって、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータイメージとデータベースファイルＦＬ１の登録内容とについて同期が得られている限りは、このデータイメージをそのままｈｄｃｃ処理対象データＦＬ２ａとして扱って、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに対してマウントすることになる。
本実施の形態の場合、例えば後述する登録処理及び終了処理等が正常に実行されていさえすれば、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータイメージとデータベースファイルＦＬ１の登録内容とについて同期が得られるようにされている。従って、通常の初期化処理としてはステップＳ１０４の処理が実行されるものである。
【００６０】
データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを構築する処理は、例えば、所定のフィルタ条件に応じてデータベースファイルＦＬ１から必要な情報を抽出する必要があるために相応に時間がかかるものであり、管理すべきコンテンツデータ数が増加すれば処理時間はさらに長くなってしまう。そして、従来においては、初期化処理が実行されるごとに、データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを構築することを行っていたものである。つまり、常にステップＳ１０５→Ｓ１０６の処理を実行することとしていた。
【００６１】
これに対して、本実施の形態では、通常の初期化処理としてはステップＳ１０４の処理を実行する。つまり、初期化処理ごとに、逐一、データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを構築することは行っていない。
ステップＳ１０４の処理は、ＨＤＤ２１上のｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）からデータイメージを読み込んで転送し、ＲＡＭ２０に書き込む処理となることから、短時間で終了することになる。つまり、通常の初期化処理としては非常に短時間で完了させることが可能になる。また、ステップＳ１０４の処理は、ＨＤＤ２１から読み出したデータをＲＡＭ２０に書き込むだけの軽い処理であるから、例えば同時に他のプロセスを実行していたとしても、この他のプロセスにはほとんど影響を与えない。例えば他のプロセスとして、コンテンツデータを再生しているような場合にも、その再生出力の連続性が保証されるなど、安定した再生出力を維持することができる。
【００６２】
また、従来の場合であれば、初期化時ごとに、データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを作成することになるから、処理時間を最小限とするために、例えば１画面分のコンテンツデータのリスト表示が可能なだけの情報により、ｈｄｃｃ処理対象データＦＬ２ａを作成していた。このために、リスト画面のスクロールなどに応じて、データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを作成する処理が比較的高い頻度で割り込むこととなっていた。これによっては、スクロール表示がスムーズに行えないことになる。また、例えば他のプロセスが影響を受ける頻度も高くなるため、例えばコンテンツデータの連続再生や、ランダム再生、リピート再生などの特殊再生などが安定して行えないなどの不都合が生じる場合があった。
これに対して、本実施の形態では、最初においてデータベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを作成しさえすれば、以降においては、このｈｄｃｃ処理対象データＦＬ２ａは、データベースファイルＦＬ１と同期が得られていることになる。
そこで、本実施の形態としては、最初にデータベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを作成するときには、データベースファイルＦＬ１全体の登録内容を利用して作成するようにされる。この場合、ｈｄｃｃ処理対象データＦＬ２ａの作成には相当の時間がかかるが、一旦作成してしまえば、以降においては、キャッシュファイルからの読み出しにより、ｈｄｃｃ処理対象データＦＬ２ａが得られることになるので、この場合にも短時間の軽い処理で済む。そして、この場合には、例えばリスト画面のスクロールが行われたときにも、ＲＡＭ２０のｈｄｃｃ−ｃａｃｈｅ領域２０Ａから、表示に必要なデータを読み出してくればよいので、スムーズなリスト画面のスクロール表示が得られる。
また、リスト画面のスクロールなどに応じて、データベースファイルＦＬ１からｈｄｃｃ処理対象データＦＬ２ａを作成する処理が発生することはないから、例えば先に述べたコンテンツデータの連続再生や特殊再生などを安定して実行することも容易となる。
【００６３】
なお、この場合における、ステップＳ１０５→ステップＳ１０６の処理は、データベースファイルＦＬ１と、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データＦＬ２ａ）との間での同期が得られなくなったとされるエラー状態に対応して、再同期を図るための処理となる。
このステップＳ１０５→ステップＳ１０６の処理としては、上述もしているように、比較的時間がかかることとなってしまう。しかしながら、この処理は、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データＦＬ２ａ）との間で同期が得られるように回復を図るために必要な処理である。また、この処理は、高い頻度で実行されるものではないので、例えばユーザに与えるストレスは最小限で済む。
【００６４】
続いては、本実施の形態としての初期化処理を、図３に示したプログラム構成の基での処理シーケンスとして説明する。この説明には、図６及び図７のアローチャートを参照する。
図６には、データベースファイルＦＬ１と、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データＦＬ２ａ）との間での同期（整合性）が得られている場合に対応した初期化処理のシーケンスが示される。この図６に示す処理シーケンスは、先に図５に示したフローチャートにおいては、ステップＳ１０１→Ｓ１０２→Ｓ１０３→Ｓ１０４としての処理に相当する。
【００６５】
図６においては、先ず、ステップＳ２０１の処理として、アプリケーション３１からｈｄｃｃ３２に対して初期化（Ｉｎｉｔｉａｌｉｚｅ）のコマンドが発行される。このＩｎｉｔｉａｌｉｚｅのコマンドに応じて、ｈｄｃｃ３２は、ステップＳ２０２の処理として、ｃｄａｍ３３に対してキャッシュ初期化（Ｉｎｉｔ Ｃａｃｈｅ）のコマンドを発行する。ｃｄａｍ３３は、Ｉｎｉｔ Ｃａｃｈｅのコマンドに応じて、ステップＳ２０３の処理により、ファイルシステム３５を利用して、Ｇｅｔ Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとしての処理を実行する。つまり、ｃｄａｍ３３は、ＨＤＤ２１に記憶されているｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域に記憶されているＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得する。但し、この場合においては、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得するのにあたり、ｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域全体のデータを取得するようにされる。
【００６６】
そして、ｃｄａｍ３３は、上記のようにしてＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得すると、ステップＳ２０４のＰｕｔ Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとしての処理により、この取得したＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに対して書き込んで展開するための処理を実行する。なお、この場合においては、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに対して、ステップＳ２０３により取得したｈｅａｄｅｒ領域全体のデータを展開することを以て、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０ＢにＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを展開させたこととしている。
このステップＳ２０３→Ｓ２０４の処理を完了させると、ｃｄａｍ３３は、ステップＳ２０５の処理を実行する。つまり、ｈｄｃｃ３２に対して、Ｉｎｉｔ Ｃａｃｈｅのコマンドに対応した処理が完了したことを、例えばｃｏｍｐｌｅｔｅのレスポンスとして通知する。
【００６７】
ｃｏｍｐｌｅｔｅの通知を受けたｈｄｃｃ３２は、続いて、ステップＳ２０６により、Ｃｈｅｃｋ Ｃａｃｈｅのコマンドをｃｄａｍ３３に対して発行する。
これに応じて、ｃｄａｍ３３は、ステップＳ２０７の処理として、先のステップＳ２０４よりｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに対して展開されたＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得するための処理を実行する。
なお、図５のステップＳ１０２の処理としては、ＨＤＤ２１に記憶されているｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域から、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得することとしている。この点で、図６に示すステップＳ２０４、Ｓ２０７による得られる処理手順とは相違する。しかしながら、この図６におけるステップＳ２０４、Ｓ２０７の処理としても、取得されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとしては、ＨＤＤ２１に記憶されているｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域に格納されているものと実質的に同一となるものである。
また、ｃｄａｍ３３は、ステップＳ２０７に続くステップＳ２０８の処理によって、データベースモジュール３４にコマンドを発行して、データベースファイルＦＬ１から、Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを取得する。
【００６８】
次のステップＳ２０９では、上記ステップＳ２０７，Ｓ２０８により取得したｈｄｃｃ処理対象ファイルＦＬ２とデータベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅについて比較を行う。これは、図５におけるステップＳ１０３の処理に相当する。この場合には、ｈｄｃｃ処理対象ファイルＦＬ２とデータベースファイルＦＬ１とは同期しているので、一致（ｏｋ）の比較結果が得られることになる。
このようにしてｏｋの比較結果が出力された場合、ｃｄａｍ３３は、ステップＳ２１０の処理により、Ｃｈｅｃｋ Ｃａｃｈｅの結果がｏｋであったことを、ｈｄｃｃ３２に対して、レスポンス（Ｃｈｅｃｋ Ｏｋ）の返信により通知する。
【００６９】
上記Ｃｈｅｃｋ Ｏｋの通知を受けたｈｄｃｃ３３は、ステップＳ２１１として、ｃｄａｍ３３に対してＧｅｔ Ｃａｃｈｅ Ｆｒｏｍ ｆｓｙｓのコマンドを発行する。ｃｄａｍ３３は、Ｇｅｔ Ｃａｃｈｅ Ｆｒｏｍ ｆｓｙｓのコマンドに応じて、ステップＳ２１２としての処理を実行する。ステップＳ２１２では、ファイルシステム３５にコマンドを発行することで、ＨＤＤ２１に記憶されているｈｄｃｃ処理対象ファイルＦＬ２からデータイメージを読み込ませる。そして、この読み込まれたデータイメージを取得する。
そして、次のステップＳ２１３としての処理により、ｈｄｃｃ３２は、ｃｄａｍ３３が取得したとされるデータイメージを、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに対して展開する処理を実行する（Ｓｅｔ Ｃａｃｈｅ）。ここまでのステップＳ２１１→Ｓ２１２→Ｓ２１３の処理が、図５におけるステップＳ１０４の処理に相当する。
ｈｄｃｃ３２は、このＳｅｔ Ｃａｃｈｅの処理を完了させると、次のステップＳ２１４としての処理として、アプリケーション３１から発行されたＩｎｉｔｉａｌｉｚｅのコマンド（Ｓ２０１）に応答した初期化処理が完了したことを、アプリケーション３１に対してＣｏｍｐｌｅｔｅのレスポンスにより通知する。この通知をアプリケーション３１が認識することで、初期化処理のシーケンスが完了したこととなる。
【００７０】
図７は、データベースファイルＦＬ１と、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データＦＬ２ａ）との間での同期（整合性）が得られていない場合に対応した初期化処理のシーケンスが示される。図５に示したフローチャートにおいては、ステップＳ１０１→Ｓ１０２→Ｓ１０３→Ｓ１０５→Ｓ１０６としての処理シーケンスに相当する。
【００７１】
図７において、ステップＳ３０１〜Ｓ３０８までの処理は、図６におけるステップＳ２０１〜Ｓ２０８までの処理と同様であることから、ここでの説明は省略する。
そして、この場合においては、ステップＳ３０９によるｈｄｃｃ処理対象ファイルＦＬ２とデータベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅについての比較結果として、一致していないというＮＧの結果が得られている。Ｉｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致していない場合、何らかの処理エラーなどによって、ｈｄｃｃ処理対象ファイルＦＬ２のイメージデータの内容は、データベースファイルＦＬ１の登録内容が反映されておらず、同期が得られていないということを意味する。
【００７２】
この場合、ｃｄａｍ３３は、ステップＳ３０１の処理により、ステップＳ３０９による比較の結果がＮＧであることを、ｈｄｃｃ３２からのＣｈｅｃｋ Ｃａｃｈｅのコマンドに応答したレスポンス（Ｃａｃｈｅ Ｎｇ）の返信により、通知する。
この通知を受けたｈｄｃｃ３２は、ステップＳ３１１の処理により、ｃｄａｍ３３に対して、Ｇｅｔ Ｄａｔａ Ｆｒｏｍ ｄｂのコマンドを発行する。このコマンドを受けたｃｄａｍ３３は、ステップＳ３１２の処理によって、データベースモジュール３４に対してコマンドを発行して、データベースファイルＦＬ１の読み出しを実行させる。
ｈｄｃｃ３２は、次のステップＳ３１３としての処理によって、上記ステップＳ３１２の処理によって読み出されたデータベースファイルＦＬ１から必要とされる情報を抽出して、ｈｄｃｃ処理対象データＦＬ２ａを作成する。そして、続くステップＳ３１４としての処理によって、この作成したｈｄｃｃ処理対象データＦＬ２ａを、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに対して転送して展開（保持）させる。そして、この処理の完了を以て、次のステップＳ３１５としての処理により、初期化処理が終了したことをアプリケーション３１に通知する。
【００７３】
この図７に示す処理において、ステップＳ３１１〜Ｓ３１４の処理シーケンスが、図５におけるステップＳ１０５→Ｓ１０６による処理に相当する。そして、ステップＳ３１１〜Ｓ３１４の処理シーケンスにおいて、ステップＳ３１２及びＳ３１３は、相応の時間を要する重い処理となる。これと比較して、例えば先に図６に示したステップＳ２１１〜Ｓ２１３の処理シーケンスにおいては、特に時間がかかる重い処理は無いものとされる。
【００７４】
６．登録処理
続いては、本実施の形態のデータベースキャッシュのための処理における登録処理について説明する。この登録処理は、コンテンツデータについての管理状態が変更されたのに応じて、この新たな管理状態を反映させるためにデータベースファイルＦＬ１の内容を変更する処理となる。
ここでの、コンテンツデータについての管理状態が変更される場合としては、例えば、コンテンツデータの追加、又は削除が行われた場合を挙げることができる。また、アプリケーションに対する操作などに応じて、既に登録されたコンテンツデータについての分割、連結などの編集が行われた場合にも登録処理が必要となる。さらには、コンテンツデータに対応付けられた属性情報が変更されたり、また、フリンジデータについての追加、削除、編集などが行われた場合も登録処理が必要となる。
【００７５】
図８は、登録処理の流れをフローチャートにより示している。
例えば上記のようにしてコンテンツデータについての管理状態が変更されることに応じては、登録処理の実行を指示するコマンドが発行される。このコマンドの発行に応じては、ステップＳ４０１としての処理により、今回のコンテンツデータについての管理状態の変更内容が反映されるようにして、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１に対して、データを登録するようにされる。なお、このデータ登録にあたっては、データベースファイルＦＬ１に格納されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅについての更新を伴う。この場合には、このステップＳ４０１としての処理によりデータ登録を行った日時情報をＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとしてセットする。
【００７６】
次のステップＳ４０２においては、同じく、今回の今回のコンテンツデータについての管理状態の変更内容が反映されるようにして、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに現在展開されている、ｈｄｃｃ処理対象データに対してデータ登録を実行する。
【００７７】
つまり、本実施の形態では、コンテンツデータについての管理状態が変更されることに応じて、データベースモジュール３４の登録処理を実行すべきときには、必ず、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持されるｈｄｃｃ処理対象データＦＬ２ａについても、その変更内容が反映されるようにして、データ登録を実行するようにしている。
これにより、ｈｄｃｃ処理対象データＦＬ２ａの情報内容と、データベースファイルＦＬ１の登録内容とについては、常に整合性が得られることになる。換言すれば、例えばデータベースファイルＦＬ１が変更されるのに応じてｈｄｃｃ処理対象データＦＬ２ａに整合性を与えるために、その都度、データベースファイルＦＬ１から情報収集をしてｈｄｃｃ処理対象データＦＬ２ａを作成する必要がないということになる。つまり、ｈｄｃｃ処理対象データＦＬ２ａと、データベースファイルＦＬ１との実質的な情報内容について同期を図るための処理（ステップＳ４０２）としても、短時間で軽いものとなっている。
【００７８】
そして、次のステップＳ４０３によっては、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに現在保持されているｈｅａｄｅｒ情報ＦＬ３のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを、先のステップＳ４０１による処理により更新した、データベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと同じ値となるように書き換える（登録する）。このステップＳ４０３の処理により、データベースファイルＦＬ１に格納されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂにおけるｈｅａｄｅｒ情報ＦＬ３に格納されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとは、同一の値を有することになる。
このステップＳ４０３の処理は、データベースファイルＦＬ１と、ｃａｃｈｅｆｉｌｅであるｈｄｃｃ処理対象ファイルＦＬ２との間で同期が得られていることを認識可能とするための準備的な処理となるものである。
【００７９】
また、図３に示したプログラム構成の基での上記登録処理のシーケンスは、図９に示すものとなる。
先ず、図９においては、ステップＳ５０１としての処理により、アプリケーション３１からｈｄｃｃ３２に対して、データベースファイルＦＬ１に対するデータ登録を指示するコマンド（Ｓｅｔ Ｄａｔａ）が発行される。ｈｄｃｃ３２は、このコマンドに応じて、ステップＳ５０２の処理として示すように、さらにｃｄａｍ３３に対して、データベースファイルＦＬ１に対するデータ登録を指示するコマンド（Ｓｅｔ Ｄａｔａ）を発行する。
このＳｅｔ Ｄａｔａのコマンドを受けたｃｄａｍ３３は、ステップＳ５０３の処理によって、データベースモジュール３４にコマンドを発行してコントロールすることで、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１に対して、データ登録を実行する。確認のために述べておくと、このときには今回の登録の日時を示すＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを登録することも行う。
そして、このステップＳ５０３としてのデータベースファイルＦＬ１対象のデータ登録の処理を完了させると、ステップＳ５０４として示すように、このデータ登録処理が完了したことを、ｈｄｃｃ３２に対して、ｃｏｍｐｌｅｔｅのレスポンスにより、通知する。
ここまでの処理が、図８におけるステップＳ４０１の処理となる。
【００８０】
上記ステップＳ５０４による通知を受けたｈｄｃｃ３２では、次に、ステップＳ５０５としての処理（Ｓｅｔ Ｄａｔａ）を実行する。
この処理としては、現在ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持されているｈｄｃｃ処理対象データＦＬ２ａを対象としてデータ登録を実行する。この処理が、図５におけるステップＳ４０２の処理に相当する。
【００８１】
そして、ステップＳ５０６以降の処理が、図５におけるステップＳ４０３に相当する処理となる。
ステップＳ５０６では、ｈｄｃｃ３２からｃｄａｍ３３に対して、Ｓｙｎｃ Ｃａｃｈｅのコマンドが送信される。このコマンドに応じた処理として、ｃｄａｍ３３は、先ず、ステップＳ５０７として示すように、ＨＤＤ２１に記憶されているデータベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅをデータベースモジュール３４により読み出させて取得するための処理を実行する。ここで取得されたＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、先のステップＳ５０３による登録処理時に対応した更新日時を示している、最新の値である。
そして、次のステップＳ５０８としての処理によって、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに保持されているｈｅａｄｅｒ情報ＦＬ３のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅの領域に対して、取得したＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅの値をセットするようにされる。これにより、先にも述べたようにして、データベースファイルＦＬと、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂのｈｅａｄｅｒ情報ＦＬ３のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとは、同一の値となる。
【００８２】
ステップＳ５０８の処理を完了させると、ｃｄａｍ３３は、ステップＳ５０９の処理として、ステップＳ５０６によるＳｙｎｃ Ｃａｃｈｅのコマンドに対するレスポンスとして、ｃｏｍｐｌｅｔｅを返す。つまり、Ｓｙｎｃ Ｃａｃｈｅのコマンドに応答した処理が完了したことを通知する。このｃｏｍｐｌｅｔｅのレスポンスを受けたｈｄｃｃ３２は、ステップＳ５１０の処理により、さらに、ステップＳ５０２によるＳｅｔ Ｄａｔａのコマンドに対するレスポンスとして、アプリケーション３１に対してｃｏｍｐｌｅｔｅを返す。
【００８３】
７．終了処理
次に、本実施の形態のデータベースキャッシュのための処理における終了処理について説明する。終了処理は、アプリケーション３１が終了するのに伴って実行される処理である。
ここでのアプリケーション３１が終了される場合としては、先ず、アプリケーション３１が起動されている状態でメイン電源をオフとすることで、アプリケーション３１が終了する場合を挙げることができる。また、メイン電源がオン状態であっても、ユーザ操作によって、アプリケーション３１の起動を終了が指示された場合、或いは、アプリケーション３１から他のアプリケーションをアクティブにするようにして、アプリケーションの切り換えが行われた場合なども、アプリケーションの終了となる。
【００８４】
図１０は、このような終了処理についての処理をフローチャートにより示している。アプリケーション３１が終了されることに伴って、終了を指示するコマンドが発行されると、この図に示す終了処理が開始される。
先ず、ステップＳ６０１により、現在、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに展開されているｈｅａｄｅｒ情報ＦＬ３を、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）における、ｈｅａｄｅｒ領域の情報として登録する。なお、この処理に伴い、これまでｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに展開されていたｈｅａｄｅｒ情報ＦＬ３はクリアしてもよい。
【００８５】
また、次のステップＳ６０２においては、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａに展開されていたｈｄｃｃ処理対象データを、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）における、イメージデータとして登録する。なお、ステップＳ６０２の処理に伴っても、これまでｈｄｃｃ−ｃａｃｈｅ領域２０Ａに展開されていたｈｄｃｃ処理対象データをクリアするようにしてよい。
【００８６】
また、この終了処理を、図３に示したプログラム構成の下での処理シーケンスとして示した場合には、図１１に示すものとなる。
図１１においては、先ず、ステップＳ７０１としての処理により、アプリケーション３１から、終了処理の実行を指示するｔｅｒｍｉｎａｔｅのコマンドが、ｈｄｃｃ３２に対して発行される。
このｔｅｒｍｉｎａｔｅのコマンドに応答して、ｈｄｃｃ３２は、ステップＳ７０２としての処理によって、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａからｈｄｃｃ処理対象データＦＬ２ａを取得する。
そして、次のステップＳ７０３としての処理によっては、ｃｄａｍ３３に対して、ｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）の保存を指示するＳａｖｅ Ｃａｃｈｅのコマンドを発行する。
【００８７】
Ｓａｖｅ Ｃａｃｈｅのコマンドに応答して、ｃｄａｍ３３は、先ず、ステップＳ７０４としての処理によって、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに保持されているｈｅａｄｅｒ情報ＦＬ３を取得する。これにより、先のステップＳ７０３によるｈｄｃｃ処理対象データＦＬ２ａと、上記ｈｅａｄｅｒ情報ＦＬ３とが取得されたことになる。
そこで、ｃｄａｍ３３は、次のステップＳ７０５の処理によって、ファイルシステム３５に対して指示を行うことで、ｈｅａｄｅｒ情報ＦＬ３とｈｄｃｃ処理対象データＦＬ２ａとを、それぞれ、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域の情報、及びデータイメージとして登録するようにして保存処理を実行する。
【００８８】
上記ステップＳ７０５の処理が完了したとされると、ｃｄａｍ３３は、ステップＳ７０６としての処理によって、Ｓａｖｅ Ｃａｃｈｅの処理が終了したことを、ｃｏｍｐｌｅｔｅのレスポンスによって、ｈｄｃｃ３２に通知する。
この通知を受けたｈｄｃｃ３２は、ステップＳ７６０７の処理によって、さらに、アプリケーション３１に対して、ステップＳ７０１により発行されたｔｅｒｍｉｎａｔｅのコマンドに応答した処理が終了したことを、ｃｏｍｐｌｅｔｅのレスポンスにより通知する。
【００８９】
これら図１０及び図１１に示す処理によると、アプリケーション終了時においては、これまでｈｄｃｃ−ｃａｃｈｅ領域２０Ａに保持されていたｈｄｃｃ処理対象データＦＬ２ａと、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂに保持されていたｈｅａｄｅｒ情報ＦＬ３とにより、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２のｈｅａｄｅｒ領域の情報、及びデータイメージが更新されることになる。
【００９０】
なお、図１０においては、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂのｈｅａｄｅｒ情報ＦＬ３をｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）に登録し、次に、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａのｈｄｃｃ処理対象データＦＬ２ａを、ｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）に登録するようにされている。
これに対して、図１１に示す処理は、先ず、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａのｈｄｃｃ処理対象データＦＬ２ａ、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂのｈｅａｄｅｒ情報ＦＬ３の順に情報取得を行ったうえで、ステップＳ７０５の処理によって、これらの情報を一括的に、ｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）に登録することとしており、図１０とは若干処理手順が異なる。
しかしながら、本実施の形態としては、結果的に、ｈｄｃｃ−ｃａｃｈｅ領域２０Ａのｈｄｃｃ処理対象データＦＬ２ａと、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂのｈｅａｄｅｒ情報ＦＬ３とにより、ｈｄｃｃ処理対象ファイルＦＬ２が更新されるのであれば、そのための処理手順は適宜変更されて構わない。この点については、先に説明した初期化処理及び登録処理についても同様である。
【００９１】
そして、上記のようにして終了処理によって更新されたＨＤＤ２１上のｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）のデータ内容については、次のようなことが言える。
先ず、イメージデータについては、ｈｄｃｃ処理対象データＦＬ２ａにより更新されている。このｈｄｃｃ処理対象データＦＬ２ａは、先の登録処理が正常に実行されてさえいれば、データベースファイルＦＬ１の登録内容に常に同期した情報内容を有している。従って、終了処理後におけるイメージデータの内容も、データベースファイルＦＬ１の登録内容と同期していることになる。
また、ｈｅａｄｅｒ領域は、ｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂのｈｅａｄｅｒ情報ＦＬ３により更新されるが、ｈｅａｄｅｒ情報ＦＬ３に格納されるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、先の登録処理の説明から理解されるように、常に、データベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと同じ値となるようにされている。従って、終了処理後において、ｈｄｃｃ処理対象ファイルＦＬ２（ｃａｃｈｅ ｆｉｌｅ）に格納されているＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとしても、データベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと一致しているべきものであることになる。
【００９２】
つまり、終了処理後においてＨＤＤ２１に保存されているｈｄｃｃ処理対象ファイルＦＬ２は、データイメージ（ｈｄｃｃ処理対象データ）として、現在のデータベースファイルＦＬ１の登録内容に同期した内容を有していることになる。このことから、先に図５及び図６により説明したように、ｈｄｃｃ処理対象データＦＬ２ａを初期化するのにあたり、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージをそのまま利用しても良いことが理解される。
【００９３】
また、上記もしているように、データベースキャッシュのための各種処理（初期化処理、登録処理、終了処理等）が正常に実行されている限りは、終了処理後においてＨＤＤ２１に保存されているｈｄｃｃ処理対象ファイルＦＬ２のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅと、データベースファイルＦＬ１のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとは、一致していることになる。これは、両者のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致していることを以て、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データ）と、データベースファイルＦＬ１の登録内容との間で整合性が得られているとみなして良いということになる。
【００９４】
これに対して、両者のＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅが一致していない場合には、これまでのデータイメージキャッシュの処理が実行された過程において、何らかのエラーが発生するなどして、ｈｄｃｃ処理対象ファイルＦＬ２のデータイメージ（ｈｄｃｃ処理対象データ）のデータ内容と、データベースファイルＦＬ１の登録内容との間で整合性が失われている可能性が高いことが推定できる。
先に図５〜図７により説明した初期化処理おいて、同期が得られているか否かの判定を行うのにあたり、これらのＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅの比較により行うこととしているのは、上記したことを根拠としているものである。
【００９５】
ところで、上記実施の形態における本発明としての動作を実現するのは、ＣＰＵ１１が実行すべきプログラムであるとして説明した。このようなプログラムは、例えばＨＤＤ２１、又はＲＯＭ１３にインストールされるようにして格納されるものである。
あるいは、プログラムは、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔ Ｏｐｔｉｃａｌ）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
例えば、本実施の形態であれば、メディアドライブ１９が対応するメディアなどにプログラムを記録し、パッケージソフトウェアとして提供することができる。これにより、記録再生装置１では、メディアドライブ１９によりメディアからプログラムを読み出し、ＨＤＤ２１やＲＯＭ１３に記憶させることでインストールできる。また、このようなパッケージソフトウェアとすることで、例えば汎用のパーソナルコンピュータにも、本発明が適用されたシステムのプログラムをインストールすることは可能になる。
また、プログラムは、上記のようなリムーバブルな記録媒体からインストールする他、プログラムを記憶しているサーバなどから、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワークを介してダウンロードすることもできる。
【００９６】
さらには、例えば本発明が適用された機能を後から追加するためのアップデートプログラムを構成し、このアップデートプログラムをパッケージメディアとして配布したり、ネットワーク上で配布するようにすることも考えられる。ユーザは、このアップデートプログラムを入手して、既存のシステムがインストールされている環境に対して、このアップデートプログラムをインストールすればよい。
【００９７】
なお、本発明としては、上記実施の形態として説明した構成に限定されるものではなく、各種変更が可能である。
例えば、実施の形態においては、ＨＤＤ２１に記憶されるｈｄｃｃ処理対象ファイルＦＬ２に対して、同期情報であるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅとを格納しているが、この同期情報としてのＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅは、ｈｄｃｃ処理対象ファイルＦＬ２とは独立したもう１つのデータファイルとして、ＨＤＤ２１上に保存するように構成することも考えられる。つまり、本発明としての第２の不揮発性記憶手段と、第３の不揮発性記憶手段は、ハードウェア的に個別であっても共通であってもよい。
但し、本実施の形態のようにして、第２、第３の不揮発性記憶手段は共通であることとして、ｈｄｃｃ処理対象ファイルＦＬ２に対して、同期情報であるＩｄｅｎｔｉｆｉｅｒ Ｖａｌｕｅを格納した１つのデータファイルとすることのほうが、データ管理が簡易に成るなどのメリットが得られることになって好ましい。
【００９８】
また、ｈｄｃｃ処理対象データＦＬ２ａを格納するｈｄｃｃ−ｃａｃｈｅ領域２０Ａと、ｈｅａｄｅｒ情報ＦＬ３を格納するｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂは、ＲＡＭ２０に対して共通に設けられる領域であるが、これらについても、ハードウェア的には異なるメモリデバイスに各領域が設定されるようにしても良いし、ハードウェア的に共通とされるメモリ領域内に保持されるようにしても良い。
この点については、ＨＤＤ２１に記憶されるデータベースファイルＦＬ１とｈｄｃｃ処理対象ファイルＦＬ２についても同様であり、互いにハードウェア的に異なる記憶装置となるＨＤＤに記憶されていてもよいものである。
つまり、本発明における第１、第２の情報保持手段は、それぞれ異なる記憶デバイスであってもよいし、共通のデバイスであってもよい。そして、本発明における第１〜第３の不揮発性記憶手段の関係としても、同様のことがいえる。
【００９９】
また、ｈｄｃｃ処理対象データＦＬ２ａを保持するｈｄｃｃ−ｃａｃｈｅ領域２０Ａと、ｈｅａｄｅｒ情報ＦＬ３を保持するｈｅａｄｅｒ−ｃａｃｈｅ領域２０Ｂは、共に揮発性の記憶領域、即ちＲＡＭであることとしているが、不揮発性の領域であってもよい。つまり、例えば初期化処理時において、ｈｄｃｃ処理対象ファイルＦＬ２を形成するｈｅａｄｅｒ領域の情報、及びデータイメージにより、不揮発性領域に記憶されるｈｅａｄｅｒ情報ＦＬ３及びｈｄｃｃ処理対象データＦＬ２ａの上書きを行ってしまえば、これまでに説明した実施の形態と同じデータベースキャッシュのシステム動作が得られるものである。
【０１００】
また、コンテンツデータ及びデータベースファイルＦＬ１、及びｃａｃｈｅ ｆｉｌｅ（ｈｄｃｃ処理対象ファイルＦＬ２）を保存することに関しても、ＨＤＤに限定されるべきものではなく、任意の不揮発性の記憶装置、記憶媒体とされてよいものである。
【０１０１】
また、本発明の下では、初期化時において実行される、同期が得られているか否かの検証を、アプリケーション３１が起動中においても実行できるように構成することも考えられる。この場合には、例えば図１０及び図１１として示した終了時の処理（つまり、ｈｄｃｃ処理対象データＦＬ２ａ及びｈｅａｄｅｒ情報ＦＬ３の登録によってｈｄｃｃ処理対象ファイルＦＬ２を更新する処理）を、アプリケーション３１が起動中における所定の機会、タイミングで実行させる。
そのうえで、これもアプリケーション３１が起動中における所定の機会、タイミングにより、例えば図５のステップＳ１０１→Ｓ１０２→Ｓ１０３の処理を実行すればよい。そして、ステップＳ１０３の処理として、肯定結果が得られたのであれば、特に処理は実行せずに、これまでのｈｄｃｃ処理対象データＦＬ２ａの保持を継続すればよい。これに対して、否定結果が得られたのであれば、ステップＳ１０５→Ｓ１０６の処理を所要の機会で実行することで、ｈｄｃｃ処理対象データＦＬ２ａと、データベースファイルＦＬ１との再同期を図るようにすればよい。
【０１０２】
また、実施の形態では、コンテンツ対応のアプリケーションが利用するｈｄｃｃ処理対象データＦＬ２ａとして、コンテンツのリスト表示に必要なリストデータであることとしているが、これに限定されるものではない。つまり、データベースファイルの情報を利用、又は参照することで得られる情報であり、コンテンツ管理、再生などのためにアプリケーションが利用できる情報でありさえすればよいものとされる。
【０１０３】
また、実施の形態では、本発明としての情報処理を、図１に示す構成の記録再生装置１により実行させることとしているが、このような記録再生装置の構成についても適宜変更されて構わない。例えば、パーソナルコンピュータなどにより本発明としての情報処理装置を実現することも可能である。
さらに、データベースの管理対象となるコンテンツデータは、オーディオデータファイルに限定される必要はなく、例えばビデオデータであっても良い。
【０１０４】
【発明の効果】
以上説明したように本発明は、コンテンツデータ（単位データ）管理のためのデータベースをＨＤＤ（不揮発性記憶手段／記憶領域）に記憶させておくようにしている。そのうえで、このデータベースを基として作成されたｈｄｃｃ処理対象データ（ｈｄｃｃ処理対象ファイルのデータイメージ：単位データ処理用情報）を保持しておくようにされる。アプリケーション（単位データ対象処理手段）は、このｈｄｃｃ処理対象データを利用して、コンテンツデータに関する所要の処理を実行するようにされる。
そして、例えば上記アプリケーションの処理結果に応じてデータベースについての登録処理が必要となったときには、必ず、ｈｄｃｃ処理対象データについての登録処理も実行するようにされる。
これにより、本発明としては、最初にデータベースを利用してｈｄｃｃ処理対象データを作成しさえすれば、以降は、データベースに同期したｈｄｃｃ処理対象データが得られていることになる。従って、例えばアプリケーションの起動時などに伴ってｈｄｃｃ処理対象データをマウントする必要が生じたときには、逐一、データベースの情報を利用して作成するのではなく、これまでのｈｄｃｃ処理対象データをそのままマウントして利用すればい良いことになる。
データベースの情報を利用してｈｄｃｃ処理対象データを作成する処理は、重い処理であり時間もかかる。これに対して、既に在るｈｄｃｃ処理対象データをマウントする処理は軽いものであり処理時間も短い。これにより、本発明によっては、例えばアプリケーションが起動して、ｈｄｃｃ処理対象データを処理可能となるまでの時間が大幅に短縮されることになる。つまり、アプリケーションが起動を完了して操作が可能となるまでの時間が短縮されるものである。また、このときの処理も軽いものであることから、他の処理プロセスの実行効率を阻害することもない。
【図面の簡単な説明】
【図１】本発明の実施の形態としての記録再生装置の構成例を示すブロック図である。
【図２】本実施の形態の記録再生装置のＨＤＤに記憶されるコンテンツデータのディレクトリ管理を示す説明図である。
【図３】コンテンツデータ管理／再生のためのプログラムの構成を示すブロック図である。
【図４】実施の形態のデータベースファイル、及びｈｄｃｃ処理対象ファイルの構造例を示す図である。
【図５】データベースキャッシュのための処理として、初期化処理を示すフローチャートである。
【図６】図２に示すプログラム構成のもとでの初期化処理のシーケンスを示すアローチャートである。
【図７】図３に示すプログラム構成のもとでの初期化処理のシーケンスを示すアローチャートである。
【図８】データベースキャッシュのための処理として、登録処理を示すフローチャートである。
【図９】図３に示すプログラム構成のもとでの登録処理のシーケンスを示すアローチャートである。
【図１０】データベースキャッシュのための処理として、終了処理を示すフローチャートである。
【図１１】図３に示すプログラム構成のもとでの終了処理のシーケンスを示すアローチャートである。
【符号の説明】
１ 記録再生装置、１１ ＣＰＵ、１２ バス、１３ ＲＯＭ、１４ 操作入力部、１５ 入力処理部、１６ 表示処理部、１７ ディスプレイモニタ、１８ＣＤドライブ制御部、１９ メディアドライブ、２０ ＲＡＭ、２１ ＨＤＤ、２２ 通信処理部、２３ ネットワークインターフェイス、２４ オーディオデータ処理部、２５ スピーカ、２６ アンテナ、２７ チューナ、３１ アプリケーション、３２ ｈｄｃｃ（ハードディスクコンテンツコントローラ）、３３ ｃｄａｍ（コンテンツデータアクセスモジュール）、３４ データベースモジュール、３５ ファイルシステム、２０Ａ ｈｄｃｃ−ｃａｃｈｅ領域、２０Ｂ ｈｅａｄｅｒ−ｃａｃｈｅ領域、ＦＬ１ データベースファイル、ＦＬ２ ｈｄｃｃ処理対象ファイル、ＦＬ２ａ ｈｄｃｃ処理対象データ、ＦＬ３ ｈｅａｄｅｒ情報
Claims (10)
- 所定の記憶媒体に記憶されている１以上の単位データを管理するデータベースが記憶される第１の不揮発性記憶手段と、
上記データベースに対する登録処理を実行する第１の登録手段と、
上記データベースを形成する情報のうちから所定の情報を利用して作成されたものであり、上記単位データを対象とする所要の処理に利用される、単位データ処理用情報が保持される第１の情報保持手段と、
上記単位データ処理用情報を利用して、上記単位データについての所要の処理を実行する単位データ対象処理手段と、
上記単位データ処理用情報に対する登録処理を実行する第２の登録手段と、を備え、
上記第２の登録手段は、
上記単位データ対象処理手段が実行した処理結果に応じて、上記第１の登録手段による上記データベースに対する登録処理が実行されるときには、上記処理結果に応じた上記単位データ処理用情報に対する登録処理を実行するようにされている、
ことを特徴とする情報処理装置。 - 上記単位データ対象処理手段として起動された処理が終了されるのに応じて、上記第１の情報保持手段に保持されていた単位データ処理用情報を、第２の不揮発性記憶手段に対して記憶させる記憶制御手段、
をさらに備えることを特徴とする請求項１に記載の情報処理装置。 - 上記単位データ対象処理手段が実行した処理結果に応じて、上記第１の登録手段による上記データベースに対する登録処理、及び上記第２の登録手段による単位データ処理用情報に対する登録処理が実行される場合に、上記データベース及び上記単位データ処理用情報の登録内容が同期していることを示すための同期情報を、上記単位データに対して格納すると共に、第２の情報保持手段に保持させる同期情報対応処理手段をさらに備え、
上記記憶制御手段は、上記第２の情報保持手段に保持されている上記同期情報を、第３の不揮発性記憶手段に対して記憶させる、
ことを特徴とする請求項２に記載の情報処理装置。 - 上記第３の不揮発性記憶手段と、上記第２の不揮発性記憶手段は、同一記憶領域を有するものとされ、
上記記憶制御手段は、上記単位データ処理用情報及び上記同期情報を有して形成されるファイルが形成されるようにして、上記単位データ処理用情報及び上記同期情報を上記同一記憶領域に記憶させる、
ことを特徴とする請求項３に記載の情報処理装置。 - 上記第３の不揮発性記憶手段に記憶されている上記同期情報と、上記データベースに格納されている上記同期情報とに基づいて、上記第２の不揮発性記憶手段に記憶されている単位データ処理用情報と、上記データベースの登録内容が同期しているか否かについて判定する判定手段、
をさらに備えることを特徴とする請求項３に記載の情報処理装置。 - 上記単位データ処理用情報を初期化するときに、上記判定手段により同期しているとの判定結果が得られた場合には、上記第２の不揮発性記憶手段に記憶されている単位データ処理用情報を、上記第１の情報保持手段に保持させるようにされた初期化手段、
を備えることを特徴とする請求項５に記載の情報処理装置。 - 上記単位データ処理用情報を初期化するときに、上記判定手段により同期していないとの判定結果が得られた場合には、上記第１の不揮発性記憶手段に記憶されているデータベースを利用して、上記単位データ処理用情報を作成し、この作成された上記単位データ処理用情報を、上記第１の情報保持手段に保持させるようにされた初期化手段、
を備えることを特徴とする請求項５に記載の情報処理装置。 - 所定の記憶媒体に記憶されている１以上の単位データを管理する情報であり、不揮発性記憶領域に記憶されているデータベースに対する登録処理を実行する第１の登録処理と、
上記データベースを形成する情報のうちから所定の情報を利用して作成され、上記単位データを対象とする所要の処理に利用される情報であり、情報保持領域に保持されるコンテンツ処理用情報を利用して、上記単位データについての所要の処理を実行する単位データ対象処理と、
上記コンテンツ処理用情報に対する登録処理を実行する第２の登録処理と、を実行するものとされ、
上記第２の登録処理は、
上記単位データ対象処理としての処理結果に応じて、上記第１の登録処理による上記データベースに対する登録処理が実行されるときには、上記処理結果に応じた上記単位データ処理用情報に対する登録処理を実行するようにされている、
ことを特徴とする情報処理方法。 - 所定の記憶媒体に記憶されている１以上の単位データを管理する情報であり、不揮発性記憶領域に記憶されているデータベースに対する登録処理を実行する第１の登録処理と、
上記データベースを形成する情報のうちから所定の情報を利用して作成され、上記単位データを対象とする所要の処理に利用される情報であり、情報保持領域に保持されるコンテンツ処理用情報を利用して、上記単位データについての所要の処理を実行する単位データ対象処理と、
上記コンテンツ処理用情報に対する登録処理を実行する第２の登録処理と、を情報処理装置に実行させるものとされ、
上記第２の登録処理は、
上記単位データ対象処理としての処理結果に応じて、上記第１の登録処理による上記データベースに対する登録処理が実行されるときには、上記処理結果に応じた上記単位データ処理用情報に対する登録処理を実行するものである、
ことを特徴とするプログラム。 - 所定の記憶媒体に記憶されている１以上の単位データを管理する情報であり、不揮発性記憶領域に記憶されているデータベースに対する登録処理を実行する第１の登録処理と、
上記データベースを形成する情報のうちから所定の情報を利用して作成され、上記単位データを対象とする所要の処理に利用される情報であり、情報保持領域に保持されるコンテンツ処理用情報を利用して、上記単位データについての所要の処理を実行する単位データ対象処理と、
上記コンテンツ処理用情報に対する登録処理を実行する第２の登録処理と、を情報処理装置に実行させるものとされ、
上記第２の登録処理は、
上記単位データ対象処理としての処理結果に応じて、上記第１の登録処理による上記データベースに対する登録処理が実行されるときには、上記処理結果に応じた上記単位データ処理用情報に対する登録処理を実行するものとされるプログラム、
が記憶されることを特徴とする記憶媒体。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003119948A JP4100241B2 (ja) | 2003-04-24 | 2003-04-24 | 情報処理装置、情報処理方法、プログラム、記憶媒体 |
| US10/817,637 US7308461B2 (en) | 2003-04-24 | 2004-04-02 | Information processing method, apparatus, program and recording medium |
| KR1020040026228A KR20040092418A (ko) | 2003-04-24 | 2004-04-16 | 정보처리장치, 정보처리방법, 프로그램, 기억매체 |
| CNB2004100346985A CN100429642C (zh) | 2003-04-24 | 2004-04-23 | 信息处理方法、装置、程序和记录介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003119948A JP4100241B2 (ja) | 2003-04-24 | 2003-04-24 | 情報処理装置、情報処理方法、プログラム、記憶媒体 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004326923A true JP2004326923A (ja) | 2004-11-18 |
| JP2004326923A5 JP2004326923A5 (ja) | 2005-06-09 |
| JP4100241B2 JP4100241B2 (ja) | 2008-06-11 |
Family
ID=33447082
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003119948A Expired - Fee Related JP4100241B2 (ja) | 2003-04-24 | 2003-04-24 | 情報処理装置、情報処理方法、プログラム、記憶媒体 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7308461B2 (ja) |
| JP (1) | JP4100241B2 (ja) |
| KR (1) | KR20040092418A (ja) |
| CN (1) | CN100429642C (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105103232A (zh) * | 2013-03-28 | 2015-11-25 | 三菱电机株式会社 | 再现装置、控制方法以及程序 |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6221717B2 (ja) * | 2013-12-12 | 2017-11-01 | 富士通株式会社 | ストレージ装置、ストレージシステム及びデータ管理プログラム |
| US10671494B1 (en) * | 2017-11-01 | 2020-06-02 | Pure Storage, Inc. | Consistent selection of replicated datasets during storage system recovery |
| WO2020049746A1 (ja) * | 2018-09-07 | 2020-03-12 | 株式会社東芝 | データベース装置、プログラム、およびデータ処理方法 |
| US11078762B2 (en) | 2019-03-05 | 2021-08-03 | Swm International, Llc | Downhole perforating gun tube and components |
| US10689955B1 (en) | 2019-03-05 | 2020-06-23 | SWM International Inc. | Intelligent downhole perforating gun tube and components |
| US11268376B1 (en) | 2019-03-27 | 2022-03-08 | Acuity Technical Designs, LLC | Downhole safety switch and communication protocol |
| US11619119B1 (en) | 2020-04-10 | 2023-04-04 | Integrated Solutions, Inc. | Downhole gun tube extension |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5751672A (en) * | 1995-07-26 | 1998-05-12 | Sony Corporation | Compact disc changer utilizing disc database |
| US6829368B2 (en) * | 2000-01-26 | 2004-12-07 | Digimarc Corporation | Establishing and interacting with on-line media collections using identifiers in media signals |
| US6077084A (en) * | 1997-04-01 | 2000-06-20 | Daiichi Kosho, Co., Ltd. | Karaoke system and contents storage medium therefor |
| US6862689B2 (en) * | 2001-04-12 | 2005-03-01 | Stratus Technologies Bermuda Ltd. | Method and apparatus for managing session information |
| US6795834B2 (en) * | 2000-06-26 | 2004-09-21 | Fujitsu Limited | Apparatus, method, and storage medium for file management |
| JP2003030967A (ja) * | 2001-07-18 | 2003-01-31 | Sony Corp | 記録装置および方法、記録媒体、並びにプログラム |
| US7054888B2 (en) * | 2002-10-16 | 2006-05-30 | Microsoft Corporation | Optimizing media player memory during rendering |
| US7007049B2 (en) * | 2002-11-18 | 2006-02-28 | Innopath Software, Inc. | Device memory management during electronic file updating |
-
2003
- 2003-04-24 JP JP2003119948A patent/JP4100241B2/ja not_active Expired - Fee Related
-
2004
- 2004-04-02 US US10/817,637 patent/US7308461B2/en not_active Expired - Fee Related
- 2004-04-16 KR KR1020040026228A patent/KR20040092418A/ko not_active Application Discontinuation
- 2004-04-23 CN CNB2004100346985A patent/CN100429642C/zh not_active Expired - Fee Related
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105103232A (zh) * | 2013-03-28 | 2015-11-25 | 三菱电机株式会社 | 再现装置、控制方法以及程序 |
| US9661259B2 (en) | 2013-03-28 | 2017-05-23 | Mitsubishi Electric Corporation | Playback device, control method, and program |
| CN105103232B (zh) * | 2013-03-28 | 2017-09-22 | 三菱电机株式会社 | 再现装置、控制方法以及程序 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1540548A (zh) | 2004-10-27 |
| JP4100241B2 (ja) | 2008-06-11 |
| US7308461B2 (en) | 2007-12-11 |
| KR20040092418A (ko) | 2004-11-03 |
| US20040243625A1 (en) | 2004-12-02 |
| CN100429642C (zh) | 2008-10-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4204977B2 (ja) | メディアプレーヤーのためのインテリジェントなシンクロ操作 | |
| JP4321528B2 (ja) | 記録再生装置 | |
| JP4695653B2 (ja) | メディア・プレーヤとホスト・デバイスとの間のワイヤレス同期化 | |
| JP4022971B2 (ja) | 記憶装置およびデータ削除方法 | |
| WO1999044202A1 (fr) | Dispositif d'enregistrement/lecture et procede d'enregistrement/lecture | |
| JP2001110171A (ja) | 記録再生装置および方法、端末装置、送受信方法、ならびに、記憶媒体 | |
| JP2000339207A (ja) | 記録媒体、データ処理装置 | |
| JP2004038988A (ja) | 外部記憶媒体を用いたホスト処理装置 | |
| JP2007102168A (ja) | 音楽データのダビング方法 | |
| JP3945007B2 (ja) | 記録システムおよび記録方法 | |
| JP4100241B2 (ja) | 情報処理装置、情報処理方法、プログラム、記憶媒体 | |
| JP2003030015A (ja) | 記録装置および方法、記録媒体、並びにプログラム | |
| JP2000163858A (ja) | 電子機器 | |
| JP4581890B2 (ja) | 電子機器、記録制御方法、プログラムおよび記録媒体 | |
| JP2004326923A5 (ja) | ||
| JP2006202475A (ja) | ファイル転送システムおよびファイル転送方法 | |
| JP4055270B2 (ja) | 記録情報転送装置、情報転送方法、及び情報転送システム | |
| JP2001014805A (ja) | インタラクティブ光ディスク放送システム | |
| JP2004102701A (ja) | 情報処理装置、情報処理方法、プログラム、記憶媒体 | |
| JP4196998B2 (ja) | コンテンツデータ転送システム、転送方法、記憶装置、およびプログラム | |
| JP4211795B2 (ja) | 通信方法、通信システム、通信方法、およびサーバ | |
| JP4337914B2 (ja) | 情報通信システムおよび方法、ならびに、情報通信装置および方法 | |
| JP2007102995A (ja) | 音楽ｃｄ中の楽曲をｍｐ３プレィヤーにダビングする方法 | |
| JP4135689B2 (ja) | プログラム、電子機器、データ処理方法および再生装置 | |
| JP2007103005A (ja) | 記録再生装置、送受信方法および記憶媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040902 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040902 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071112 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071120 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080121 |
|
| 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: 20080226 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080310 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110328 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |