以下、添付の図面を参照しつつ、本発明の好適な実施例について詳細に説明する。図面中、同一の構成要素については可能な限り同一の参照番号及び符号を共通使用するものとする。
以下、本発明によるローカルストレージデータの削除方法及び装置を、添付の図面に基づいて説明する。
本発明で使用される用語は、可能なかぎり現在広く使用されている一般的な用語としたが、特定の場合では出願人が任意に選定した用語もあり、その場合には該当する発明の説明部分で詳細にその意味を定義しておいたので、用語が持つ単純な意味ではなくここで定義された固有の意味として本発明を把握すべきである。
本発明でいう“記録媒体”は、例えば、光ディスク、磁気テープなど、データ記録可能であるかデータが記録されている媒体であれば、記録方式に関ることなくいずれも含む。
以下の本発明では、説明の便宜上、記録媒体としてBDのような光ディスク(optical disc)を例にして説明するが、本発明の技術思想が他の記録媒体にも同一に適用可能であることは自明である。
本発明で“ローカルストレージ(local storage)”とは、光記録再生装置 (図1の10)に備えられた一種の保存手段で、必要な情報及びデータを使用者が任意に保存して活用できる要素のことを意味する。例えば、現在一般的に使用されるローカルストレージにはハードディスクドライブ(hard disc drive:HDD)があるが、必ずしもこれに本発明が限定されることはない。
特に、“ローカルストレージ(local storage)”は、BDのような記録媒体と関連したデータを保存する手段としも活用され、記録媒体と関連してローカルストレージ内に保存されるデータは、外部からダウンロード(download)されるのが一般的である。
ローカルストレージ(Local storage)内において、ダウンロードしたデータを保存するために形成されたディレクトリ部分をローカルストレージファイル構造と命名する。
なお、記録媒体から一部許容されたデータを直接読み取る、または、記録媒体の記録再生と関連したシステムデータ(例えば、メタデータ(metadata))を生成してローカルストレージ内に保存することも可能であることは自明である。
本発明で“バインディングユニット(binding unit)”とは、ローカルストレージ(local storage)内に保存された情報の一集合で、特に、特定記録媒体に関連付けられて該当の記録媒体内の情報に合成または追加され、記録媒体のデータをローカルストレージのデータと共に再生できるようにする情報の一集合を意味する。
本発明では説明の便宜上、記録媒体に記録されたデータを“オリジナルデータ(orginal data)”と命名し、ローカルストレージに保存されているか、保存されるべきデータの中で記録媒体と関連したデータを“付加データ(additional data)”と命名する。
図1は、本発明の概念的な理解を助けるために示す図で、光記録再生装置10と周辺機器間の統合的使用の一例を示している。
“光記録再生装置10”は、様々な規格の光ディスクへのデータ記録や再生を行うことができる機器で、必要によって、BDのような特定光ディスクのみへの特定データの記録/再生が可能であっても良く、記録は除いて再生のみ可能であっても良い。特に、本発明で解決しようとするブルーレイディスク(BD)と周辺機器との連携性を考慮し、以下ではブルーレイディスク(BD)を再生するプレーヤー(BD−Player)またはブルーレイディスク(BD)を記録/再生するレコーダ(BD−Recorder)を例にして説明する。周知の如く、“光記録再生装置10”はコンピュータなどに内蔵される“ドライブ(drive)”になりうる。
本発明の光記録再生装置10は、光ディスク30を記録/再生する機能の他にも、外部入力信号を受信してこれを信号処理した後に他の外部ディスプレイ20を通じて使用者に画面として伝達する機能を有する。この場合、入力可能な外部信号に特に制限はなく、例えば、デジタル放送(Digital multimedia broadcasting)及びインターネット(Internet)関連信号などが代表的なものとなる。特に、インターネットは現在誰でも容易にアクセスできる媒体で、光記録再生装置10を通じてインターネット上の特定データをダウンロード(download)して活用することができる。
なお、外部入力ソース(external source)としてコンデンツデータを提供する者を“コンデンツ提供者(CP;content provider)”と総称する。
例えば、マルチプレクスされた(multiplexed)AV(Audio/Video)ストリームがオリジナルデータとして光ディスクに記録され、インターネット上の付加データが、オリジナルデータのオーディオストリーム(例えば、韓国語)と異なるオーディオストリーム(例えば、英語)であると仮定する。この場合、使用者によっては、インターネット上の付加データであるオーディオストリーム(例えば、英語)をダウンロードして、オリジナルデータたるAVストリームと共に再生したい要求、または、付加データのみを再生したい要求がありうる。これを可能にするためには、オリジナルデータと付加データ間の連関性を規定し、これらのデータを使用者の要求に応じて管理/再生する体系化した方法が必要である。
上記で、説明の便宜上、ディスク内に記録された信号をオリジナルデータとし、ディスクの外部に存在する信号を付加データとしたが、これは、単にそれぞれのデータを取得する方法によって区分したもので、オリジナルデータと付加データが必ずしも特定のデータに限定されることはない。
一般に、オーディオ(Audio)、プレゼンテーショングラフィック(Presentation Graphic:PG)、インタラクティブグラフィック(Interactive Graphic:IG)、テキストサブタイトル(Text subTitle)等が付加データになりうるが、これに限定されず、これら列挙したデータとビデオとを含むマルチプレクスされた(multiplexed)AVストリームが付加データになっても良い。すなわち、光ディスクの外部に存在しながら、オリジナルデータと関連しているいかなる属性のデータも付加データになりうるわけである。
特に、光記録再生装置10内にローディングされた光ディスク30にはオリジナルデータ(original data)が記録されており、インターネット(Internet)のような光記録再生装置10の外部にオリジナルデータと関連した付加データ(additional data)が存在する場合、本発明は、オリジナルデータと付加データを共に再生するに当たり、不必要なファイルを削除してオリジナルデータにバインディングされるバインディングユニットを生成する、または、外部コンテンツプロバイダから新しいデータをダウンロードするためにローカルストレージを空にするに当たり、保存された付加データのファイルを削除する方法を提示する。
なお、使用者の要求、すなわち、オリジナルデータと付加データを共に再生することを実現するためには、オリジナルデータと付加データの相互間に関連したファイル構造を持つことが必須とされる。したがって、以下、図2及び図3を参照して、ブルーレイディスク(BD)で使用可能なファイル構造及びデータ記録構造について詳細に説明する。
まず、図2は、ディスク内に記録されたオリジナルデータを再生管理するためのファイル構造及び該ファイル構造によって特定タイトルが再生される関係を示す図である。
すなわち、本発明のファイル構造は、一つのルートディレクトリ(root directory)の下に、少なくとも一つのBDディレクトリ(BDMV)を含む。該BDMVディレクトリは、使用者とのインタラクティビティ(interactivity)を保証するための一般ファイル(上位ファイル)情報としてインデックスファイル(“index”)とオブジェクトファイル(“MovieObjet”)を含む。また、このファイル構造は、実際ディスク内に記録されたデータに関する情報とこれを再生する方法に関する情報を有するディレクトリ、例えば、プレイリストディレクトリ(PLAYLIST)、クリップインフォディレクトリ(CLIPINF)、ストリームディレクトリ(STREAM)、補助ディレクトリ(AUXDATA)、及びバックアップディレクトリ(BACKUP)を含む。以下、これらのディレクトリ及びディレクトリ内に含まれるファイルについて詳細に説明する。
補助データディレクトリ(AUXDATA)は、ディスク再生に必要な付加的なデータファイル、例えば、インタラクティブグラフィック(Interactive Graphic)の実行時にサウンドを提供する“Sound.bdmv”ファイルと、ディスク再生時にフォント(font)情報を提供する“11111.otf”ファイルとを含む。
ストリームディレクトリ(STREAM)は、ディスク内に特定フォーマットで記録されたAVストリームファイルを含み、それぞれのストリームは、現在広く知られたMPEG−2方式のトランスポートパケット(Transport packet)で記録される場合が最も一般的であり、ストリームファイル(01000.m2ts、02000.m2ts)の拡張名として“*.m2ts”を使用する。特に、ストリームのうち、ビデオ/オーディオ/グラフィック情報が全てマルチプレクスされたストリームをAVストリームといい、タイトル(Title)は少なくとも一つのAVストリームファイルで構成される。
クリップインフォディレクトリ(CLIPINF)は、それぞれのストリームファイル(“*.m2ts”)と一対一対応するクリップインフォファイル(01000.clpi、02000.clpi)で構成される。特に、このクリップインフォファイル(“*.clpi”)には、対応するストリームファイル(“*.m2ts”)の属性情報及びタイム情報(timing information)等が記録される。特に、ストリームファイル(“*.m2ts”)と該ストリームファイル(“*.m2ts”)に一対一対応するクリップインフォファイル(“*.clpi”)をまとめて“クリップ(clip)”と命名する。すなわち、“クリップ(clip)”は、ストリームファイル(“*.m2ts”)及びクリップインフォファイル(“*.clpi”)で構成されたデータを意味する。以下の本発明では、ディスク内に記録されたクリップ(clip)を“オリジナルクリップ(original clip)”と、ダウンロードされてローカルストレージ内に保存されたクリップ(clip)を“付加クリップ(additional clip)”と命名する。
プレイリストディレクトリ(PLAYLIST)は、プレイリストファイル(“*.mpls”)を含み、それぞれのプレイリストファイル(“*.mpls”)は、特定クリップが再生される時間(playing interval)を指定する少なくとも一つのプレイアイテム(PlayItem)及びサブプレイアイテム(SubPlayItem)を含む。このプレイアイテム(PlayItem)及びサブプレイアイテム(SubPlayItem)は、再生されるべき特定クリップの再生開始時間(IN−Time)と再生終了時間(OUT−Time)に関する情報を持っている。
プレイリストファイル内において少なくとも一つのプレイアイテム(PlayItem)による再生過程をメインパス(main path)といい、各サブプレイアイテム(SubPlayItem)による再生過程をサブパス(sub path)という。メインパスは、プレイリストファイル内に必ず存在しなければならなく、サブパスは、サブプレイアイテム(SubPlayItem)の存在によって少なくとも一つが必要に応じて存在すれば良い。
すなわち、プレイリストファイルは、少なくとも一つのプレイアイテム(PlayItem)の組み合わせによって所望のクリップの再生を行う全体再生/管理ファイル構造内の基本的再生/管理ファイル単位となる。
バックアップディレクトリ(BACKUP)は、上記ファイル構造上のデータのうち、特にディスク再生と関連した情報が記録されるインデックスファイル(“index”)、オブジェクトファイル(“MovieObject”)、プレイリストディレクトリ(PLAYLIST)内の全てのプレイリストファイル(“*.mpls”)及びクリップインフォディレクトリ(CLIPINF)内の全てのクリップインフォファイル(“*.clpi”)に対する複写本(copy)ファイルを保存する。すなわち、このバックアップディレクトリ(BACKUP)は、これらのファイルの損失がディスク再生に致命的であることを考慮し、バックアップ(backup)用として当該ファイルの複製ファイルを保存しておく機能を果たす。
図2にはまた、前述したディスクパッケージによって特定タイトルが再生される関係が示されている。
使用者がインデックスファイル(インデックステーブル(index table)ともいう。)によってタイトルに対してタイトル再生命令を入力すると、該タイトルの再生が始まる。これを詳細に説明すると、次の通りである。
インデックスファイル(index.bdmv)は、該当のディスクがロードされると、最初に再生される画面に対する情報である“First Playback”情報と、メニュー画面を提供する“Top Menu”情報と、少なくとも一つの“タイトル(Title #1〜Title #n)”情報を含む。
光ディスク30が光記録再生装置10にロードされると、インデックステーブルによるタイトルメニュー情報がディスプレイ20を介して使用者に提供される。使用者がメニュー画面内の特定タイトルまたは特定メニューを選択すると、ディスク製作者(author)があらかじめ定義しておいたシナリオによって再生が始まる。すなわち、使用者が特定タイトル(例えば、タイトル#1)の再生命令を下すと、再生/管理ファイル構造上のオブジェクトファイル(MovieObject)内に備えられたコマンド(command)に応じて特定プレイリストファイルが実行される。以降、当該プレイリストファイル情報に基づき、プレイリストファイル内の特定プレイアイテム及び/またはサブプレイアイテムによってタイトル#1を構成する一つ以上のクリップ(例えば、Clip #1〜Clip #3)が再生される。
図3は、本発明による記録媒体に記録されるデータ記録構造を示す図で、具体的には、ファイル構造と関連した情報のディスク記録構造を示している。図3に示すように、上記ディスク構造は、ディスク内周から順に、全体ファイルを管理するシステム情報として機能するファイルシステム情報領域(file system information area)と、記録されたAVストリーム(*.m2ts)を再生するためのプレイリストファイル及びクリップインフォファイルを記録するデータベース領域(database area)と、オーディオ/ビデオ/グラフィックなどで構成されたストリームが記録されるAVストリーム領域(AV stream area)とを含む。特に、ディスク内のAVストリーム領域(AV stream area)に記録されたデータがオリジナルデータになりうることは、前述の通りである。
本発明は、特に、ディスク内に記録されたオリジナルデータ(例えば、図2に示すファイル構造)とローカルストレージ内に保存された付加データを共に再生する前段階で、ローカルストレージにディスク外から付加データをダウンロードし、使用者の命令に応じてダウンロードしたデータから特定データを削除する方法及び装置を提供する。以下、本発明に係る様々な実施例について詳細に説明する。
図4Aは、本発明の光記録再生装置10を示すブロック図である。
図4Aを参照すると、光記録再生装置10は、ピックアップ11、サーボユニット14、信号処理部13、及びマイコン16を備える。ピックアップ11は、光ディスクに記録されたオリジナルデータ及び再生/管理ファイル情報を含む管理情報を再生する。サーボユニット14は、ピックアップ部11の動作を制御する。信号処理部13は、ピックアップ部11から受信した再生信号を所望の信号値に復元するか、または、記録されるべき信号を光ディスクに記録される信号に変調(modulation)して伝達する。マイコン16は、上記の構成要素の相互動作を制御する。
制御器12は、使用者から命令を受信し、光ディスクの外部に存在する付加データをダウンロード(download)してローカルストレージ15に保存するとともに、光ディスク内のオリジナルデータとローカルストレージ内の付加データを再生する仮想ファイルシステム(VFS:virtual file system)を形成し、仮想ファイルシステムを用いてオリジナルデータと関連した付加データを含む仮想ファイル構造(virtual package)を形成し、該生成された仮想ファイル構造を用いてオリジナルデータ及び/または付加データを使用者の要求に応じて再生する。
ここで、仮想ファイルシステム(VFS)は、ローカルストレージ15内のファイルシステムとロードされたディスクのファイルシステムとを統合して管理するための一種の仮想的に形成されたファイルシステムである。
また、仮想ファイルシステム(VFS)を用いて、ディスク内のオリジナルデータとローカルストレージ内の付加データを共に再生するための新しい仮想ファイル構造(Virtual package)を生成し、このバインディング動作(binding operation)によって生成される仮想ファイル構造(Virtual package)は、異なる領域にそれぞれ保存されているディスク内のオリジナルデータで構成されたオリジナルクリップとローカルストレージ内の付加データで構成された付加クリップを再生/管理するファイル構造となる。
ローカルストレージ15において、ローカルストレージファイル構造は、オリジナルデータと関連した付加データがディスク単位、タイトル単位またはコンテンツ単位のいずれかの方式で構成されたバインディングユニットを含み、したがって、このローカルストレージファイル構造に付加データが保存される。
また、制御部12は、ローカルストレージ15にローカルストレージファイル構造を生成して外部データをダウンロードすることを制御し、また、生成されたローカルストレージファイル構造にダウンロードしたデータを保存することと、ダウンロードして保存されたデータのうち使用者によって選択されたファイルを、ローカルストレージファイル構造から削除することを制御する。
デコーダ17は、制御部12の制御によって出力データ(オリジナルデータ及び/または付加データ)を最終的にデコーディングして使用者に提供する。
エンコーダ18は、光ディスクに信号を記録する機能を果たすために、制御部12の制御によって入力信号を特定フォーマットの信号、例えば、MPEG2トランスポートストリームに変換して信号処理部13に提供する。
上記で、新しく生成された仮想ファイル構造(Virtual package)を以降再利用するためにローカルストレージ15に保存しておいても良く、別のダイナミックメモリ(dynamic Memory)を用いて一時的に保存しておいても良い。
図4Bは、図4Aの光記録再生装置10の全体構成のうち、特に、ローカルストレージを用いる光ディスク再生装置を示す構成図である。
まず、ローカルストレージ15内に保存された情報について説明する。本発明に係るローカルストレージ15には、基本的に、ディスク識別情報別にディレクトリ及びファイルを持つファイル情報(Directory−File for disc_ID #n dependent)と、外部からダウンロードした付加クリップ(additional clips)が存在する。また、ローカルストレージ15のバインディングユニットを生成し、生成されたバインディングユニットをディスク内のファイル構造とバインディング(binding)するためのバインディングユニットマニフェスト情報(Binding Unit Manifest Information)が含まれたバインディングユニットマニフェストファイル(Binding Unit Manifest files)が構成されることができる。
特に、ローカルストレージ15内のファイル情報(Directory−File for disc_ID #n dependent)は、相異なる複数のディスクに対応するために複数個存在することができ、これを管理するためのファイルシステムが別途存在する。このファイルシステムを特にローカルストレージファイルシステム(Local storage file system)41といい、ローカルストレージファイルシステム41は、ローカルストレージ15内の全てのファイルを管理するシステムとなる。
したがって、特定ディスク識別情報(disc_ID)を持つ光ディスク(例えば、disc_ID #1)が光記録再生装置10内にローディングされると、光記録再生装置10内の制御部12は、ピックアップ11及び信号処理部13を介して当該ディスクの識別情報を確認し、ローカルストレージ15内に保存されたファイル情報があると、保存されたファイル情報のうち、ローディングされたディスク識別情報と一致するバインディングユニットファイル情報を読み取り、読み取られた情報をディスク内のファイル構造とバインディング(binding)するバインディング動作(Binding operation)によって仮想ファイル構造(Virtual package)を生成し、生成された仮想ファイル構造を用いてディスク内のオリジナルデータとローカルストレージ内の付加データを共に再生する。
ただし、以前に外部コンテンツプロバイダ(CP)からダウンロードしたデータがローカルストレージ15内のファイル構造に保存されていない場合、すなわち、ローカルストレージ15内に保存されたファイル情報がないと、外部入力ソースであるコンテンツプロバイダ(CP)から提供するデータをローカルストレージファイル構造にダウンロードしてバインディングユニットを生成し、バインディングユニットファイル情報を読み取り、読み取られた情報をディスク内のファイル構造とバインディングして仮想ファイル構造を生成する。
本発明は、外部コンテンツプロバイダ(CP)からダウンロードしたデータがディスク単位、タイトル単位またはコンテンツ単位のいずれか一つの単位に保存されている場合、使用者から削除命令を受信すると、ローカルストレージファイル構造からデータファイルを削除する方法及び装置を提供する。
以下、本発明のローカルストレージにダウンロードしたデータをローカルストレージファイル構造から削除(deleting)する方法を、ローカルストレージファイル構造のバインディングユニットがディスク単位、タイトル単位、コンテンツ単位にそれぞれ構成された各実施例に分けて、図5A乃至図7Bを参照して説明する。
図5A及び図5Bは、本発明のローカルストレージデータを削除する方法の第1実施例で、ローカルストレージ内のバインディングユニットがディスク単位(per Disc)に構成された場合である。
ローカルストレージ(Local storage)ファイル構造は、ルートディレクトリ(root)の下位に、バインディングユニットの含まれるディレクトリとしてバインディングユニットディレクトリ(Binding Unit Data)を備え、バインディングユニットディレクトリ(Binding Unit Data)の下位ディレクトリとして、ディスク製作者(Author)であるコンテンツプロバイダ(CP)を基準にして区別したディレクトリ(org_ID)と、コンテンツプロバイダ(CP)が共有するディレクトリが存在できる。また、特定コンテンツプロバイダディレクトリである“org_ID”ディレクトリの下位には、ディスク特有ディレクトリ(disc_ID)とディスク共有ディレクトリ(Shared)が存在できる。
次に、図5Bを参照して、本発明によるローカルストレージデータを削除する方法について詳細に説明する。
図5Bを参照すると、ディスクがローディングされると、外部コンテンツプロバイダ(CP)から付加データをダウンロードし、ディスク単位にローカルストレージファイル構造を形成してローカルストレージに保存する(S10)。
ローカルストレージが外部コンテンツプロバイダ(CP)からデータをダウンロードする時、光記録再生装置の制御部では、ダウンロードアプリケーション(Download application)であるBD−Jアプリケーションによってディスク単位にローカルストレージファイル構造であるバインディングユニットを形成し、付加データをダウンロードすることが好ましい。
ダウンロードしたデータが保存されたローカルストレージファイル構造は、各コンテンツプロバイダ(CP)を基準にして区別したディレクトリ(例えば、org_ID #1)の下位ディレクトリとして、ディスク特有ディレクトリ(disc_ID #1)と別のディスク特有ディレクトリ(disc_ID #2)がある。ディスク特有ディレクトリ(disc_ID #1)の下位には、バインディングユニット60を表すBDディレクトリ(BDMV)が位置する。
BDディレクトリ(BDMV)が表すバインディングユニット60は、ディスク単位に構成される。バインディングユニット60は、BDディレクトリ(BDMV)の下位に、使用者とのインタラクティビティ(interactivity)を保証するための一般ファイル(上位ファイル)情報であるインデックスファイル(Index.bdmv)61及びオブジェクトファイル(MovieObjet.bdmv)62と、プレイリストファイル(00000.mpls:63、00002.mpls:64)を含むプレイリストディレクトリ(PLAYLIST)と、クリップインフォファイル(01002.clpi:65)を含むクリップインフォディレクトリ(CLIPINF)と、ストリームファイル(01002.m2ts:66)を含むストリームディレクトリ(STREAM)とを備える。
上記段階(S10)後に、ダウンロードして保存された特定ディスク(disc #1)のファイルを削除する旨の命令があるかを判断する(S11)。
上記判断(S11)の結果、ダウンロードして保存された特定ディスク(disc #1)のファイルを削除する旨の命令がない場合、特定ディスク全体のファイルを削除しない(S12)。
上記判断(S11)の結果、ダウンロードして保存された特定ディスク(disc #1)のファイルを削除する旨の命令があれば、ローカルストレージファイル構造から特定ディスク全体のファイルを削除する(S13)。すなわち、バインディングユニット60を削除する。
上記段階(S13)の特定ディスクファイルの削除は、光記録再生装置制御部のレジデントアプリケーション(Resident application)によって行われることが好ましく、ディスクのためのバインディングユニットの全てのダウンロードされたコンテンツを削除することを意味する。
また、上記段階(S13)の削除は、バインディングユニット全体を削除するので、インデックスファイル(Index.bdmv)のインデックステーブル(Index table)及び/またはオブジェクトファイル(MovieObject.bdmv)のデータ構造を変更する必要がない。
したがって、上記段階(S13)によって削除されたローカルストレージファイル構造をみると、各コンテンツプロバイダ(CP)を基準にして区別したディレクトリ(例えば、org_ID #1)の下位ディレクトリにディスク特有ディレクトリ(disc_ID #2)のみが残される。
図6A及び図6Bは、本発明のローカルストレージデータを削除する方法の第2実施例で、ローカルストレージ内のバインディングユニットがタイトル単位(per Title)に構成された場合である。
図6Aのローカルストレージ基本ディレクトリ構造は、図5Aの実施例と略同様であり、ただし、図5の第1実施例と違い、ローカルストレージファイル構造のバインディングユニット70内の各ディレクトリ下位のファイルがタイトルによって異なってくる。以下、図6A及び図6Bを参照して詳細に説明する。
ディスクがローディングされると、外部コンテンツプロバイダ(CP)から付加データをダウンロードしてタイトル単位にローカルストレージファイル構造を形成し、ローカルストレージに保存する(S20)。
ローカルストレージが外部コンテンツプロバイダ(CP)からデータをダウンロードする時、光記録再生装置の制御部ではダウンロードアプリケーション(Download application)であるBD−Jアプリケーションによってタイトル単位にローカルストレージファイル構造であるバインディングユニットを形成し、付加データをダウンロードすることが好ましい。
また、ローカルストレージファイル構造内のバインディングユニット70のファイルが特定タイトルのファイルか否かを表す情報と関連して、ローカルストレージはデータをダウンロードする時に各タイトルに関するファイル情報も一緒にダウンロードする。この場合、ローカルストレージが、特定ファイル(00000.mpls:74、01002.clpi:76、01002.m2ts:77)がタイトル#1バインディングユニットに関するファイルという情報と、特定ファイル(00002.mpls:75)がタイトル#2バインディングユニットに関するファイルという情報を、外部コンテンツプロバイダ(CP)からデータをダウンロードする時に一緒にダウンロードすることは当業者にとっては自明である。
特に、ローカルストレージファイル構造内のバインディングユニット70のファイルが特定タイトルのファイルか否かを表す情報は、コンテンツプロバイダ(CP)からダウンロードしたバインディングユニットマニフェストファイル(Binding Unit Manifest files)の情報に含まれることができる。
ダウンロードしたデータが保存されたローカルストレージファイル構造は、各コンテンツプロバイダ(CP)を基準にして区別したディレクトリ(例えば、org_ID #1)の下位ディレクトリとして、ディスク特有ディレクトリ(disc_ID #1)及び別のディスク特有ディレクトリ(disc_ID #2)を含む。ディスク特有ディレクトリ(disc_ID #1)の下位には、バインディングユニット70を表すBDディレクトリ(BDMV)が存在する。
BDディレクトリ(BDMV)が表すバインディングユニット70は、そのファイル構造がタイトル単位に構成された場合を表示する。バインディングユニット70の構造は、BDディレクトリ(BDMV)の下位に、使用者とのインタラクティビティ(interactivity)を保証するための一般ファイル(上位ファイル)情報であるインデックスファイル(Index.bdmv)71と、タイトル#1のオブジェクトファイル(MovieObjet1.bdmv)72と、タイトル#2のオブジェクトファイル(MovieObjet2.bdmv)73と、プレイリストファイル(00000.mpls:74、00002.mpls:75)を含むプレイリストディレクトリ(PLAYLIST)と、クリップインフォファイル(01002.clpi:76)を含むクリップインフォディレクトリ(CLIPINF)と、ストリームファイル(01002.m2ts:77)を含むストリームディレクトリ(STREAM)と、を備える。
ここで、バインディングユニット70のファイルのうち、オブジェクトファイル(MovieObjet1.bdmv)72、プレイリストファイル(00000.mpls)74、クリップインフォファイル(01002.clpi)76、ストリームファイル(01002.m2ts)77は、タイトル#1のためのファイルであり、オブジェクトファイル(MovieObjet2.bdmv)73、プレイリストファイル(00002.mpls)75は、タイトル#2のためのファイルである。
上記段階(S20)後に、ダウンロードして保存された特定タイトル(Title #1)のファイルを削除する旨の命令があるか判断する(S21)。
上記判断(S21)の結果、ダウンロードして保存された特定タイトル(Title #1)のファイルを削除する旨の命令がなければ、特定タイトル(Title #1)のファイルを削除しない(S22)。
上記判断(S21)の結果、ダウンロードして保存された特定タイトル(Title #1)のファイルを削除する旨の命令があれば、ローカルストレージファイル構造で特定タイトル(Title #1)のファイルを削除する(S23)。
すなわち、バインディングユニット70から特定タイトル(Title #1)のファイルであるオブジェクトファイル(MovieObjet1.bdmv)72、プレイリストファイル(00000.mpls)74、クリップインフォファイル(01002.clpi)76、ストリームファイル(01002.m2ts)77を削除するわけである。
上記段階(S23)の特定タイトルファイルの削除は、光記録再生装置の制御部のレジデントアプリケーション(Resident application)によって行われることが好ましく、タイトルのためのバインディングユニットの全てのダウンロードされたファイルを削除することを意味する。
上記段階(S23)後に、ローカルストレージファイルの中から特定ファイルのデータベース構造を変更(modify)する(S24)。例えば、インデックスファイル(Index.bdmv)71−1のインデックステーブル(Index table)をデータベース構造の削除後にタイトルに合わせて変更する、または、オブジェクトファイル(MovieObjet2.bdmv)73のデータベース構造を変更することが好ましい。
したがって、上記の段階によってファイルが削除/変更された後のローカルストレージファイル構造によると、バインディングユニット70−1はBDディレクトリ(BDMV)の下位に、データベースファイル構造が変更されたインデックスファイル(Index.bdmv)71−1と、オブジェクトファイル(MovieObjet2.bdmv)73、タイトル#2のためのプレイリストファイル(00002.mpls)75を備えたプレイリストディレクトリ(PLAYLIST)と、ファイルを有しないクリップインフォディレクトリ(CLIPINF)と、ストリームディレクトリ(STREAM)を備える。
図7A及び図7Bは、本発明のローカルストレージデータを削除する方法の第3実施例で、ローカルストレージ内のバインディングユニットがコンテンツ単位(per Content)に構成された場合である。
ディスクがローディングされると、外部コンテンツプロバイダ(CP)から付加データをダウンロードしてコンテンツ単位にローカルストレージファイル構造を形成し、ローカルストレージに保存する(S30)。
ローカルストレージが外部コンテンツプロバイダ(CP)からデータをダウンロードする時に、光記録再生装置の制御部では、ダウンロードアプリケーション(Download application)であるBD−Jアプリケーションによってコンテンツ単位にローカルストレージファイル構造であるバインディングユニットを形成し、付加データをダウンロードすることが好ましい。
ダウンロードしたデータが保存されたローカルストレージファイル構造は、各コンテンツプロバイダ(CP)を基準にして区別したディレクトリ(例えば、org_ID #1)の下位ディレクトリとして、ディスク特有ディレクトリ(disc_ID #1)及び別のディスク特有ディレクトリ(disc_ID #2)を含む。ディスク特有ディレクトリ(disc_ID #1)の下位には、バインディングユニット80を表すBDディレクトリ(BDMV)が位置する。
BDディレクトリ(BDMV)が表すバインディングユニット80は、コンテンツ単位に構成される。バインディングユニット80は、BDディレクトリ(BDMV)の下位に、使用者とのインタラクティビティ(interactivity)を保証するための一般ファイル(上位ファイル)情報であるインデックスファイル(Index.bdmv)81と、オブジェクトファイル(MovieObjet.bdmv)82と、プレイリストファイル(00000.00.mpls:83、00000.01.mpls:84、00002.mpls:85)を含むプレイリストディレクトリ(PLAYLIST)と、クリップインフォファイル(01002.clpi:86、01003.clpi:87)を含むクリップインフォディレクトリ(CLIPINF)と、ストリームファイル(01002.m2ts:88、01003.m2ts:89)を含むストリームディレクトリ(STREAM)とを備える。
ここで、バインディングユニット80のファイルらのうち、プレイリストファイル(00000.00.mpls)83、クリップインフォファイル(01002.clpi)86、ストリームファイル(01002.m2ts)88はコンテンツ#1のためのファイルであり、プレイリストファイル(00000.01.mpls)84、クリップインフォファイル(01003.clpi)87、ストリームファイル(01003.m2ts)89はタイトル#2のためのファイルである。
上記段階(S30)後に、ダウンロードして保存された特定コンテンツ(Content #1)のファイルを削除する旨の命令があるか判断する(S31)。
上記判断(S31)の結果、ダウンロードして保存された特定コンテンツ(Content #1)のファイルを削除する旨の命令がなければ、特定コンテンツ(Content #1)のファイルを削除しない(S32)。
上記判断(S31)の結果、ダウンロードして保存された特定コンテンツ(Content #1)のファイルを削除する旨の命令があれば、ローカルストレージファイル構造から特定コンテンツ(Content #1)のファイルを削除する(S33)。
すなわち、バインディングユニット80から特定コンテンツ(Content #1)のファイルであるプレイリストファイル(00000.00.mpls)83、クリップインフォファイル(01002.clpi)86、ストリームファイル(01002.m2ts)88を削除するわけである。
上記段階(S33)の特定コンテンツファイルの削除は、光記録再生装置の制御部のレジデントアプリケーション(Resident application)によって行われることが好ましく、コンテンツのためのバインディングユニットの全てのダウンロードされたファイルを削除することを意味する。
上記段階(S33)後に、必要によってローカルストレージファイルの中から特定ファイルのデータベース構造を変更(modify)する(S34)。例えば、部分的なインデックスファイル(Index.bdmv)81−1のインデックステーブル(Index table)とオブジェクトファイル(MovieObjet.bdmv)82−1のデータベース構造を、削除後のコンテンツに合わせて変更することが好ましい。
したがって、上記段階によってファイルが削除/変更された後のローカルストレージファイル構造によると、バインディングユニット80−1は、BDディレクトリ(BDMV)の下位に、コンテンツ#2のためにデータベースファイル構造が変更されたインデックスファイル(Index.bdmv)81−1と、オブジェクトファイル(MovieObjet.bdmv)82−1と、コンテンツ#2のためのプレイリストファイル(00000.01.mpls)84とプレイリストファイル(00002.mpls:85)を含むプレイリストディレクトリ(PLAYLIST)と、クリップインフォファイル(01003.clpi)87を含むクリップインフォディレクトリ(CLIPINF)と、ストリームファイル(01003.m2ts:89)を含むストリームディレクトリ(STREAM)とを備える。
なお、コンテンツ単位に構成されたバインディングユニットが損傷または破損された場合には、上記のコンテンツ単位に削除(deleting)を行う方法では損傷または破損されたコンテンツのみを削除することができるが、ディスク単位に削除する時には全てのディスクファイルを削除し、タイトル単位に削除するときには全てのタイトルファイルを削除することが好ましい。
以上の本発明の実施例は、添付の特許請求の範囲に開示された本発明の技術的思想とその技術的範囲内で、様々に改良、変更、代替または付加できることは、当業者にとっては自明である。したがって、本発明は、特許請求の範囲及びその均等範囲内における本発明の改良及び変更された事項も含むことは自明である。