JP2011008867A - 光ディスク再生装置 - Google Patents

Abstract

【課題】 バインディングユニットデータエリアとしてのリムーバブルメディアにユーザが保存したデータが存在するときに、ＢＤ−Ｊアプリケーションによるバインディングユニットデータエリアへのデータ書き込みを制御するし、リムーバブルメディアのデータを保護することが可能な光ディスク再生装置を提供すること。
【解決手段】 第一の記録媒体及び第二の記録媒体上のアプリケーションとデジタルストリームを連動させながら再生する光ディスク再生装置であって、第一の記録媒体と第二の記録媒体のいずれか一方は、光ディスク再生装置から取り外し可能なリムーバブルメディアであり、仮想パッケージの構築および再生を制御するＢＤ−Ｊアプリケーション部と、リムーバブルメディアにユーザデータを確認すると、ＢＤ−Ｊアプリケーション部へリムーバブルメディアへの書き込みを制限する通知を行うレジデントアプリケーション部と、を有する。
【選択図】 図３

Description

本発明は、ブルーレイディスク再生装置など仮想パッケージを再生する光ディスク再生装置に取り付けられるリムーバブルメディアのデータ保護に関するものである。

近年、高画質、高音質で高度なインタラクティブ機能を有する情報を記録した大容量の光ディスクを再生する光ディスク再生装置が一般家庭にも普及している。

その中の代表的な光ディスク再生装置であるブルーレイディスク（ＢＤ：Ｂｌｕ−ｒａｙ Ｄｉｓｃ）には、ＢＤ−ＲＯＭ等の記録媒体に記録されている映像データと、当該記録媒体以外の他の記録媒体に記録されている映像等のデータとを動的に組み合わせてなる一つのパッケージ(以下、「仮想パッケージ」と言う。)を再生する技術がある。

ＢＤ再生装置は、仮想パッケージを構築するためにバインディングユニットデータエリア（Ｂｉｎｄｉｎｇ Ｕｎｉｔ Ｄａｔａ Ａｒｅａ）が必要であり、ＢＤ−ＲＯＭに記録されているデータとバインディングユニットデータエリアに記録されているデータとを動的に組み合わせて、仮想的なパッケージを構築することによって、ＢＤ−ＲＯＭのデータに付加的な情報をつけて再生する。なお、ＢＤ再生装置は、バインディングユニットデータエリアにデータを書き込む事が規格上必須機能とされている。

バインディングユニットデータエリアに用いられる記録媒体は、ハードディスクドライブのように光ディスク再生装置と一体化された構成もあるが、リムーバブルメディアであるＳＤメモリカードやＵＳＢフラッシュメモリといった光ディスク再生装置に外付けで利用する構成も存在している。

一方、リムーバブルメディアに保存されるデータは、仮想パッケージに使用されるデータ以外にも、ユーザによりパソコンなどで作成されたＡＶファイル、デジタルカメラやビデオカメラで撮影したデータが保存可能であり、これらのデータはＢＤ再生装置で再生することも可能である。

なお、バインディングユニットデータエリアにはハードディスクドライブなど光ディスク再生装置と一体化されたものを用いた場合、書き込み途中にシステムが停止しても、復帰後にファイルシステムのジャーナリング機能を利用してデータを復帰する事が可能である。しかし、光ディスク再生装置のコスト面を考えると、バインディングユニットデータエリアに光ディスク再生装置と一体化された記録媒体を用いたものと、リムーバブルメディアをユーザに用意してもらうものを比較すると、明らかに後者のほうがより少ないコストで造ることが可能となる。そのため、バインディングユニットデータエリアにはリムーバブルメディアを使用する光ディスク再生装置の形態が一般的になると予想されている。

仮想パッケージについての先行技術としては、以下の特許文献１、２に記載されているものがある。

特開２００６−１０９４９４号公報 特開２００７−２０２１１号公報

一般的に、メモリ媒体内のファイルはファイルシステムによって管理されており、メモリ媒体内に何らかのデータを記録する場合、同時にメモリ媒体内のファイル管理領域も更新される。しかしながら、ＳＤメモリカードやＵＳＢフラッシュメモリなどのリムーバブルメディアは、ファイルシステムにジャーナリング機能がないため、メモリ媒体内のデータの操作中にシステムの異常停止や停電などが発生した場合、メモリ媒体内のファイルシステムのメタデータが損なわれ、すべてのファイルが参照できなくなるという不具合がある。

メモリ媒体内の一貫性が崩れたとき、メモリを初期化することによって再び利用することが可能となるが、仮想パッケージを再生する光ディスク再生装置以外で保存したデータがメモリ媒体に存在するときはこれらのデータも同時に消去される問題がある。

主に一般家庭で使用されている据置の再生機器の使用形態であれば、停電などで光ディスク再生装置の電力供給が突然止まる現象が発生する可能性は低いが、車載用の再生機器では電源が突然ＯＦＦになる場合がある。例えば、バッテリー電圧の低下によるものや、イグニッションキーを回したときが想定される。

本発明は、従来の問題を解決するためになされたもので、リムーバブルメディアに書き込まれているユーザーのデータを保護することのできる仮想パッケージを再生する光ディスク再生装置を提供することを目的とする。

上記課題を解決するために、本発明の第１の局面は、
第一の記録媒体及び第二の記録媒体上のアプリケーションとデジタルストリームを連動させながら再生する光ディスク再生装置であって、第一の記録媒体と第二の記録媒体のいずれか一方は、光ディスク再生装置から取り外し可能なリムーバブルメディアであり、仮想パッケージの構築および再生を制御するＢＤ−Ｊアプリケーション部と、リムーバブルメディアにユーザデータを確認すると、ＢＤ−Ｊアプリケーション部へリムーバブルメディアへの書き込みを制限する通知を行うレジデントアプリケーション部と、を有することを特徴とする。

この構成によれば、リムーバブルメディアにおけるユーザのデータの有無を判定する機能を設けることにより、ユーザのデータを保護することが可能なリムーバブルメディアを用いた光ディスク再生装置を提供することができる。

また、レジデントアプリケーション部は、前記ＢＤ−Ｊアプリケーション部から前記リムーバブルメディアへの書き込み要求がある度に、前記ＢＤ−Ｊアプリケーション部へ前記リムーバブルメディアへの書き込み制限の有無を通知することを特徴とする。

この構成によれば、一度構築した仮想パッケージを再生する際には書き込み要求を行わないので、ユーザのデータがリムーバブルメディアに存在していたとしても以前に構築した仮想パッケージの再生をすることが可能となる。

また、レジデントアプリケーション部は、ユーザの初期設定または、ＢＤ−Ｊアプリケーション部からリムーバブルメディアへの書き込み要求がある度にユーザの選択によりリムーバブルメディアへの書き込み制限の有無を決定することを特徴とする。

この構成によれば、リムーバブルメディアへのデータの書き込みをユーザが選択できる
。よって、リムーバブルメディアにユーザのデータが存在していても、ユーザの選択により仮想パッケージを構築し再生することができる。

本発明の第２の局面は、レジデントアプリケーション部は、ＢＤ−Ｊアプリケーション部からのストレージレベルの確認要求がされたときに、ＢＤ−Ｊアプリケーション部へリムーバブルメディアへの書き込み制限の有無を通知することを特徴とする。

この構成によれば、仮想パッケージを構築する前にリムーバブルメディアの交換が可能であり、仮想パッケージを構築する直前にリムーバブルメディアにユーザのデータが存在することが判明し、仮想パッケージが再生できないという事態を回避することができる。

また、レジデントアプリケーション部は、リムーバブルメディアにユーザデータが存在することを確認すると、ユーザにリムーバブルメディアの交換を促す報知をし、その後一定時間ユーザからの応答がない場合、ＢＤ−Ｊアプリケーション部へリムーバブルメディアへの書き込みを制限する通知を行うことを特徴とする。

この構成によれば、車載環境では運転中に運転者が画面操作を行うことが禁止されていることが多い。しかし、そのような時に何も再生されない状態を解除し、仮想パッケージではなく通常のコンテンツを再生することができる。

本発明は、バインディングユニットデータエリアとしてリムーバブルメディアを利用したときに、リムーバブルメディアにおけるユーザのデータの有無を判定する機能を設けることにより、ユーザのデータを保護することが可能な仮想パッケージを再生する光ディスク再生装置を提供することができる。

本発明の第１の実施形態に係るシステム図 本発明の第１の実施形態に係る光ディスク再生装置のブロック図 本発明の第１の実施形態に係るソフトウェアのブロック図 本発明の第１の実施形態に係るＢＤ−Ｊアプリケーションの仮想パッケージ構築の処理を示フローチャート 本発明の第１の実施形態に係るレジデントアプリケーションのリムーバブルメディア１２が装填されたときの手順を説明するフローチャート 本発明の第１の実施形態に係るレジデントアプリケーションのリムーバブルメディア１２が装填されたときのフローチャート 本発明の第１の実施形態に係るＢＤ−Ｊモジュールの書き込み制御を示すフローチャート 本発明の第１の実施形態に係るレジデントアプリケーションの書き込み制御を示すフローチャート 本発明の第１の実施形態に係る書き込み要求の通知例を示す図 本発明の第１の実施形態に係る書き込み制御後の通知例を示す図 本発明の第１の実施形態に係る書き込み制御の通知例を示す図 本発明の第２の実施形態に係るＢＤ−Ｊモジュールの書き込み制御を示すフローチャート 本発明の第３の実施形態に係るＢＤ−Ｊモジュールの書き込み制御を示すフローチャート 本発明の第３の実施形態に係るレジデントアプリケーションの書き込み制御を示すフローチャート 本発明の第３の実施形態に係る書き込み要求の通知例を示す図 本発明の第３の実施形態に係るリムーバブルメディア１２の交換通知例を示す図 本発明の第３の実施形態に係る書き込み制御の通知例を示す図

（第１の実施形態）
本発明の第１の実施形態を図面を用いて説明する。

図１は、第１の実施形態に係る光ディスク再生装置１０の使用形態の一例を示す図である。例えば、光ディスク再生装置１０は、ＢＤ−ＲＯＭ１１、リムーバブルメディア１２、テレビ１３、ＷＷＷサーバ１４を備える。

続いて、第１の実施形態に係る光ディスク再生装置１０により再生される光記録媒体であるＢＤ−ＲＯＭ１１について説明する。

ＢＤ−ＲＯＭ１１は、映画作品やライブ映像などのＡＶコンテンツが記録された記録媒体である。

リムーバブルメディア１２は、ＳＤメモリカード、メモリスティック、コンパクトフラッシュ（登録商標）、スマートメディア、マルチメディアカード等に代表されるデータの書き換えが自由に行える可搬型の記録媒体である。そして、リムーバブルメディア１２は、光ディスク再生装置１０に装着され、ＷＷＷサーバ１４からダウンロードしたデータを保存する。これらのデータ以外にも、ユーザによりパソコンで保存されたＡＶファイル、デジタルカメラやビデオカメラで撮影したデータが保存可能で、これらのデータは光ディスク再生装置１０で再生することが可能である。

また、ＷＷＷサーバ１４からダウンロードしたデータとＢＤ−ＲＯＭ１１に記録されたコンテンツは、組み合わせて再生することが可能である。さらに、ＢＤ−ＲＯＭ１１からリムーバブルメディア１２にデータを保存すれば、光ディスク再生装置１０においてＢＤ−ＲＯＭ１１に対して頻繁にシーク動作を行うことなく、ＢＤ−ＲＯＭ１１のデータとリムーバブルメディア１２のデータの同時再生が可能となる。

テレビ１３は、映像を表示する装置であり、ユーザに対して操作メニューを表示する機能も有する。よって、ユーザは視覚的に光ディスク再生装置１０を操作することができる。

ＷＷＷサーバ１４は、ＢＤ−ＲＯＭ１１に記録されたコンテンツの補助的なデータをインターネットなどを介してユーザに提供する装置である。

ここで、ＢＤ−ＲＯＭ１１等の記録媒体に記録されている映像データと、当該記録媒体以外の他の記録媒体（第１の実施形態では、リムーバブルメディア１２）に記録されている映像等のデータとを動的に組み合わせてなる一つのパッケージ(以下、「仮想パッケージ」と言う。)を再生する技術に関して説明する。

仮想パッケージとは、ＢＤ−ＲＯＭ１１等の読み出し専用記録媒体と、リムーバブルメディア１２等の読み書き可能な記録媒体との記録内容を一体的に示すパッケージ情報を生成し、これらの記録媒体に記録されているデジタルストリームやアプリケーションプログラム（以下、「アプリケーション」という。）を、あたかも仮想的な一つのパッケージに記録されているかのごとく再生や実行に供する技術である。このような技術では、書き換え可能なリムーバブルメディア１２に記録しているデータを更新することで、ＢＤ−ＲＯ
Ｍ１１を頒布した後も仮想パッケージ全体としての作品内容を変更することができる。例えば、映画作品のプロバイダは、作品本編を記録したＢＤ−ＲＯＭ１１を頒布した後も、公開前の他の作品の予告編デジタルストリームをネットワークを介して提供することで、ＢＤ−ＲＯＭ１１の頒布時期にかかわらず、ユーザに対して常に最新の作品を宣伝することが出来る。

続いて、本発明に係わる光ディスク再生装置１０のブロック図である図２を用いて再生制御について説明する。

光ディスク再生装置１０は、ピックアップ２１、サーボ２２、ローカルストレージ２３、ネットワークインターフェース２４、信号処理手段２５、再生手段２６から構成される。

ピックアップ２１は、ディスク２０からデータを取得する手段である。なお、ディスク２０は、図１に示すＢＤ−ＲＯＭ１１が代表的であるが、ＤＶＤ−ＲＯＭやその他の記録媒体であってもよい。

サーボ２２は、ピックアップ２１を制御する装置である。ピックアップ２１をシークさせたり、フォーカスを調整する事によって所望のデータをディスク２０から取得する。ディスク２０から取得されたデータは信号処理手段２５に送られる。

信号処理手段２５で処理されるデータは、ディスク２０のものだけではなく、ローカルストレージ２３に保存されているデータや、ネットワークインターフェース２４を経由してネットワーク上からダウンロードされたデータも含まれる。信号処理手段２５は、これらのデータを処理をして、再生手段２６が再生をできるようにするための手段である。

次に、信号処理手段２５におけるソフトウェアの詳細なブロック図を図３に示す。

ＢＤ−ＲＯＭプレーヤモデル層３０は、ディスク３８、バインディングユニットデータエリア３６、ネットワーク３７から提供されるＡＶストリームをどのようにして復号をするのか規定している。また、ＢＤ−ＲＯＭアプリケーション環境層３１からディスク３８、バインディングユニットデータエリア３６、ネットワーク３７にアクセスをすることがあるが、ＢＤ−ＲＯＭプレーヤモデル層３０は、このための手段も提供している。

ＢＤ-ＲＯＭアプリケーション環境層３１は、ＡＶストリームの再生手順、そのストリームの制御手順を実行するところである。ＢＤ−ＲＯＭアプリケーション環境層３１には、ＨＤＭＶモジュール３２とＢＤ−Ｊモジュール３３があり、それぞれのモジュールが別々の手法で再生手順、制御手順を実現させる。

ＨＤＭＶモジュール３２は、再生を動的に変化させるためのシナリオが記述されたシナリオプログラムを動作させることによって制御されるＨＤＭＶタイトルを構成する。

ＢＤ−Ｊモジュール３３は、Ｊａｖａ（登録商標）仮想マシンを利用してＢＤ−Ｊアプリケーション３９が制御をすることによって再生されるＢＤ−Ｊタイトルを構成する。

ＢＤ−ＲＯＭレジデントシステムソフトウェア層３４は、レジデントアプリケーション３５からユーザ操作の内容を受け、その操作が受け付け可能かどうか、受付可能な場合は、再生中のタイトルの種別によって、ＨＤＭＶモジュール３２かＢＤ−Ｊモジュール３３のどちらに通知をするのかを判定する。

レジデントアプリケーション３５は、グラフィックインターフェースなどを提供してユーザの操作を受け取り、ＢＤ−ＲＯＭレジデントシステムソフトウェア層３４に通知する。

バインディングユニットデータエリア３６は、ＢＤ−Ｊアプリケーション３９がＪａｖａ（登録商標）ＩＯパッケージを使用してアクセスする事が可能である。したがって、バインディングユニットデータエリア３６にデータを書き込むのはＢＤ−Ｊタイトルモードのときになる。

次に、ＢＤ−Ｊアプリケーション３９が仮想パッケージを構築するときの一般的なシーケンスを図４を用いて説明する。

光ディスク再生装置１０にＢＤ-ＲＯＭディスク（図３では、ディスク３８）を挿入すると、ファーストプレイタイトルが再生される。ファーストプレイタイトルの再生開始後、ＢＤ−Ｊモジュール３３が光ディスク再生装置１０のＢＤ−ＲＯＭ Ｐｒｏｆｉｌｅを確認し（ステップＳ１０）、仮想パッケージ構築対象のＰｒｏｆｉｌｅであれば、次のステップＳ１１に進む。仮想パッケージを構築しないＰｒｏｆｉｌｅ １ Ｖｅｒｓｉｏｎ１．０の場合は、ディスクパッケージでタイトルを再生する。

ステップＳ１１では、現在のパッケージの種別を判定し、すでに仮想パッケージであれば、再度仮想パッケージを構築する必要はないので、そのままタイトルを再生する。ディスクパッケージの際は、ステップＳ１２へ進む。

ステップＳ１２では、ＢＤ−Ｊモジュール３３がバインディングユニットデータエリア３６のレベルを確認する。このレベルとは、バインディングユニットデータエリアの読み出し速度を表すが、リムーバブルメディア１２が光ディスク再生装置１０に装填されていない状態、すなわちバインディングユニットデータエリア３６が存在しないということを想定したレベルも存在する。バインディングユニットデータエリア３６の読み出し速度が十分でないときや、バインディングユニットデータエリア３６が存在していない場合、ＢＤ−Ｊアプリケーション３９はユーザに対してエラー表示を行い、ディスクパッケージでタイトルの再生を行う。

ステップＳ１２で適切なレベルと判定された場合、バインディングユニットデータエリア３６にすでに仮想パッケージで再生するために必要なデータが存在しているかどうかを判定する（ステップＳ１３）。すでに、所望のデータがバインディングユニットデータエリア３６にあるときは、仮想パッケージを構築して、仮想パッケージとして再生を行う（ステップＳ１８）。バインディングユニットデータエリア３６に所望のデータがないときはステップＳ１４に移行する。

ステップＳ１４では、バインディングユニットデータエリア３６の容量を確認し、これから書き込もうとするデータの容量と空き容量を比較して、十分に足りているかの判断をする。空き容量が十分ではないと判断された場合は、ユーザに対してエラー表示を行い、ディスクパッケージとして再生を行う。空き容量が足りているときは、ステップＳ１５でバインディングユニットデータエリア３６にデータを書き込む。

前記のように、バインディングユニットデータエリア３６に書き込まれるデータはＷＷＷサーバ１４からダウンロードしたものや、ディスク３８内のデータが有りうる。ステップＳ１６ではバインディングユニットデータエリア３６に対してデータの書き込みが成功したか、そうでないかを確認する。成功した場合は仮想パッケージを構築し（ステップＳ１８）、仮想パッケージとして再生を行う。失敗した場合は書き込みに失敗したというエ
ラー表示をユーザに対して行い（ステップＳ１７）、ディスクパッケージで再生する。以上が仮想パッケージを構築する処理の流れである。

次に、リムーバブルメディア１２が光ディスク再生装置１０に装填されたときの従来の処理について説明する。

図３のレジデントアプリケーション３５は、図４のステップＳ１２でＢＤ−Ｊアプリケーション３９が確認するストレージレベルをＢＤ−Ｊモジュール３３に通知しておく必要がある。家庭内で使用されるＢＤ再生装置など通常の場合のシーケンスを図５に示す。ステップＳ５０でＢＤ−Ｊモジュール３３に対して光ディスク再生装置１０に装填されたリムーバブルメディア１２の読み出し性能を通知する。

第１の実施形態では、光ディスク再生装置１０に装填されたリムーバブルメディア１２に仮想パッケージを構築するために必要なデータ以外、すなわち、リムーバブルメディア１２の使用者が独自に書き込んだデータがあるかどうかを確認する。そのとき、図５のシーケンスは図６のように変わる。

リムーバブルメディア１２が光ディスク再生装置１０に装填された後、ステップＳ６０でレジデントアプリケーション３５は、リムーバブルメディア１２の内容を確認する。仮想パッケージ構築に必要なデータは特定のディレクトリ内に書き込まれるため、これ以外のディレクトリ、もしくはこの特定ディレクトリ以外にファイルがリムーバブルメディア１２に存在しているとき、ユーザが独自に書き込んだデータがあると判定する。リムーバブルメディア１２に利用者が保存したデータが存在しないと判定した場合は、ステップＳ６１に移る。これは図５のステップＳ５０と同じ処理である。

リムーバブルメディア１２に利用者が保存したデータが存在する場合は、ステップＳ６０からステップＳ６２に移り、レジデントアプリケーション３５は、ＢＤ−Ｊモジュール３３にストレージレベルを通知するだけでなく、ＢＤ−Ｊアプリケーション３９によるバインディングユニットデータエリア３６へのデータ書き込みを制限するように要求する。なお、ＢＤ−Ｊモジュール３３はこの通知内容によって図４のシーケンスでＢＤ−Ｊアプリケーション３９から書き込みの要求があった場合に、レジデントアプリケーション３５にバインディングユニットデータエリア３６への書き込みが行われることを通知するようにしてもよい。この書き込みとは、実際にファイルを書き込む動作だけではなく、ファイル作成やディレクトリ作成、ファイル名の変更など、ファイル情報の作成、変更、更新に関わるすべての動作が当てはまる。このように書き込み要求毎にバインディングユニットデータエリア３６への書き込み制御を行うことにより、一度構築した仮想パッケージを再生する際には書き込み要求を行わないので、ユーザのデータがリムーバブルメディア１２に存在していたとしても以前に構築した仮想パッケージの再生は可能である。

また、第１の実施形態では、ＢＤ−ＲＯＭ１１を再生するとき、ＢＤ−Ｊアプリケーション３９の要求をＢＤ−Ｊモジュール３３が判別し、レジデントアプリケーション３５にその内容を通知し、レジデントアプリケーション３５の応答によってＢＤ−Ｊアプリケーション３９の制御を行う。ユーザの判断結果を用いて、ＢＤ−Ｊアプリケーション３９の動作を制御するという点でも画期的であり、ユーザに対して利便性がある。

次に、図４のステップＳ１５でＢＤ−Ｊアプリケーション３９はバインディングユニットデータエリア３６にデータを書き込むが、この命令はＢＤ−Ｊモジュール３３を経由して行われる。このときのＢＤ−Ｊモジュール３３の動作のシーケンスを図７に示す。

ＢＤ−Ｊモジュール３３は、図６のステップＳ６２でレジデントアプリケーション３５
によってバインディングユニットデータエリア３６への書き込みの制限を受けたとき、ステップＳ７０でレジデントアプリケーション３５から書き込み制限の通知があったかどうかを判定する。レジデントアプリケーション３５が書き込み制限をしているとき、ステップＳ７１でＢＤ−Ｊアプリケーション３９から書き込みの要求があったことを通知する。

ステップＳ７２では、レジデントアプリケーション３５からの応答を受けて、書き込みが許可された場合はステップＳ７４でバインディングユニットデータエリア３６にデータの書き込みを行う。レジデントアプリケーション３５が書き込みを許可しない応答をした場合は、ステップＳ７３でＢＤ−Ｊアプリケーション３９に対して書き込みの要求をエラーにして応答を行う。

図７のステップＳ７１でＢＤ−Ｊモジュール３３からレジデントアプリケーション３５に書き込みの通知を行うが、レジデントアプリケーション３５では図８のような動作をする。

書き込みの通知を受けて、ステップＳ８０では、リムーバブルメディア１２に書き込みが行われることによって、リムーバブルメディア１２のデータが消える可能性があることをユーザに対して通知する。

このときの通知例は図９のようになる。図９の書き込み要求通知例ではＳＤカードと記してあるが、これはすべてのリムーバブルメディア１２に適用される。ユーザが書き込みを許可するかどうかを選択し、ステップＳ８１でこの選択を確認する。書き込みが許可された場合はレジデントアプリケーション３５からＢＤ−Ｊモジュール３３へ書き込み許可の通知を行う。書き込みが許可されなかった場合はＢＤ−Ｊモジュール３３へ書き込み抑制を通知し、図１０のような表示をしてユーザにリムーバブルメディア１２に書き込みをさせなかったことをステップＳ８４で通知する。

なお、車載環境では運転者が運転中に画面操作をすることが禁止されているので、図９の書き込み要求通知例の通知パネルが表示されたまま再生が行われないことが想定される。そこで、ステップＳ８０とステップＳ８１の処理を飛ばし、ステップＳ８３の書き込み抑制をＢＤ−Ｊモジュール３３へ通知することも可能である。また、必ず抑制されてしまうと仮想パッケージによる再生を実施する事ができなくなるため、ユーザが行う初期設定などによってＢＤ−Ｊモジュール３３へ書き込みを抑制するか、許可するかをレジデントアプリケーション３５が判定するという機能でも実現可能である。

ＢＤ−Ｊモジュール３３へ書き込みの抑制を通知することは、図４のステップＳ１６で書き込みに失敗した場合にあたり、ステップＳ１７で書き込みに失敗した旨のエラーメッセージがＢＤ−Ｊアプリケーション３９によって表示される。図９の書き込み要求通知例の表示が行われない場合、ＢＤ−Ｊアプリケーション３９が表示する書き込みに失敗したことを知らせるメッセージだけでは、ユーザの混乱を招く事に成りかねないので、図８のステップＳ８３はリムーバブルメディア１２にユーザのデータが存在していて、そのデータが消えてしまう可能性があるために、書き込みを制限したという事が伝わるような表示をする。その一例としては図１１のようになる。

（第２の実施形態）
ＢＤ−Ｊアプリケーション３９からバインディングユニットデータエリア３６への書き込みを図４のステップＳ１５で抑制する方法が第１の実施形態であった。第２の実施形態は、ステップＳ１４で書き込みを抑止する方法である。

レジデントアプリケーション３５は、リムーバブルメディア１２が装填されたときにリ
ムーバブルメディア１２にユーザが独自に書き込んだデータが存在するかを確認する。これは第１の実施形態と同様で図６のシーケンスで表される。

ＢＤ−Ｊアプリケーション３９からバインディングユニットデータエリア３６にデータを書き込むためにバインディングユニットデータエリア３６の容量を確認したときに、書き込みを抑制するためのＢＤ−Ｊモジュール３３のシーケンスは図１２になる。ＢＤ−Ｊアプリケーション３９が図４のステップＳ１４でバインディングユニットデータエリア３６の空き容量を確認したとき、ＢＤ−Ｊモジュール３３はレジデントアプリケーション３５が書き込み制限をしているかどうかをステップＳ１２０で確認する。

制限されている場合、ステップＳ１２１でレジデントアプリケーション３５に対してＢＤ−Ｊアプリケーション３９からバインディングユニットデータエリア３６の容量確認が行われたことを通知する。

レジデントアプリケーション３５はこの通知を受けたとき、第１の実施形態と同じの図８のシーケンスを踏み、ユーザに書き込みを許可するかどうかの問い合わせを行う。ユーザが書き込みを抑制したら、ステップＳ１２３でＢＤ−Ｊモジュール３３はＢＤ−Ｊアプリケーション３９に対し、バインディングユニットデータエリア３６の容量がないことを通知する。反対に、ユーザが書き込みを許可したら、ＢＤ−Ｊアプリケーション３９へバインディングユニットデータエリア３６の空き容量を通知する。これは、仮想パッケージを構築して再生するときの通常動作と同じ図４のシーケンスになる。同様に、書き込み制限がされていない場合はステップＳ１２０からステップＳ１２４へ移行し、リムーバブルメディア１２の空き容量をＢＤ−Ｊアプリケーション３９へ通知する。これも仮想パッケージを構築して再生をするときの通常の動作と同機能となる。

このように、図４のステップＳ１４のＢＤ−Ｊアプリケーション３９からバインディングユニットデータエリア３６の空き容量を確認してきた場合にも、リムーバブルメディア１２へのデータの書き込みを回避する方法も実現可能である。しかし、バインディングユニットデータエリア３６の容量確認の直後にＢＤ−Ｊアプリケーション３９が必ずしもデータを書き込むわけではない。したがって、書き込みのみを防ぐという点では、第１の実施形態のほうが望ましいが、第２の実施形態においても、ユーザデータの消失を防ぐことが可能である。

（第３の実施形態）
第３の実施形態は図４でＢＤ−Ｊアプリケーション３９がストレージレベルを確認するステップＳ１２でバインディングユニットデータエリア３６への書き込みを制御する形態である。

第１の実施形態と同様にレジデントアプリケーション３５はリムーバブルメディア１２が装填されたときに、リムーバブルメディア１２にユーザが記録したデータが存在していないかを確認し、ＢＤ−Ｊモジュール３３に通知する。これは図６のシーケンスである。

第３の実施形態では、ＢＤ−Ｊアプリケーション３９からストレージレベルの確認要求がＢＤ−Ｊモジュール３３にされたとき、ＢＤ−Ｊモジュール３３は図１３のシーケンス処理を行う。図６のステップＳ６１、ステップＳ６２でレジデントアプリケーション３５が書き込み抑制をしているかどうかをステップＳ１３０で判別する。書き込み制限が要求されていた場合は、ステップＳ１３１でＢＤ−Ｊアプリケーション３９からストレージレベルの確認要求が行われていることをレジデントアプリケーション３５に通知する。このときのレジデントアプリケーション３５の動作は後述で詳しく説明する図１４である。レジデントアプリケーション３５が書き込みを抑制する場合、ステップＳ１３２からステッ
プＳ１３３に移行する。バインディングユニットデータエリア３６がリムーバブルメディア１２で存在しているにも関わらず、ＢＤ−Ｊアプリケーション３９にはストレージがないものとして通知するという点が画期的な内容になる。そうすることで、図４のシーケンスのステップＳ１２で不適切なレベルとして扱われる事になり、バインディングユニットデータエリア３６への書き込みを抑制する事ができる。

ステップＳ１３０でレジデントアプリケーション３５から書き込み抑制が要求されていない場合や、ステップＳ１３２でレジデントアプリケーション３５が書き込みを許可した場合、ステップＳ１３４でＢＤ−Ｊモジュール３３は通常のストレージレベルを通知して、図４の書き込みシーケンスを継続する。

図１４はレジデントアプリケーション３５がＢＤ−Ｊモジュール３３からストレージレベルの確認がなされているという通知を受けたときのシーケンスを示す図である。ステップＳ１４０でユーザへリムーバブルメディア１２にデータの書き込みが行われることを通知する。このときの表示例は図１５に示すようなものになる。図１５は第１の実施形態の図８のステップＳ８０の表示例である図９とほとんど同じであるが、図１５ではリムーバブルメディア１２の交換ができるユーザインターフェースを提供している。仮に、第３の実施形態でリムーバブルメディア１２を交換したとき、図４のシーケンスに戻ったとき、その後、ＢＤ−Ｊアプリケーション３９が空き容量など確認の処理を行うことになるが、第１の実施形態では書き込み直前にリムーバブルメディア１２の交換を許可しても、ＢＤ−Ｊアプリケーション３９が空き容量など確認を行えないため、容量が不足した場合に予期せぬエラーになる可能性がある。そのために、第１の実施形態ではリムーバブルメディア１２の交換をしない。第１の実施形態でもＢＤ−Ｊモジュール３３に対してＢＤ−Ｊアプリケーション３９から空き容量などの仮想パッケージを構築するために必要十分なバインディングユニットデータエリア３６の構成を通知される機能があれば、リムーバブルメディア１２の交換の実施を行うことも可能になる。

ステップＳ１４１でユーザが書き込みを選択した場合、ステップＳ１４２でＢＤ−Ｊモジュール３３へ書き込み許可を通知する。また、ステップＳ１４１でユーザが書き込み抑制を選んだときは、ＢＤ−Ｊモジュール３３に対して書き込み抑制を通知し、書き込みを抑制した事をユーザーに表示して通知する。このときのユーザに対する表示例は第１の実施形態で示した図１０と同等である。

ステップＳ１４１でユーザがリムーバブルメディア１２の交換を選択したとき、ステップＳ１４５でリムーバブルメディア１２の交換を促す表示をユーザに対して行う。このときの表示例は図１６になる。ステップＳ１４６でレジデントアプリケーション３５がリムーバブルメディア１２の抜き差しを検知したら、ステップＳ１４５でユーザに対して表示していた通知を消去し、ステップＳ１４７に移行してリムーバブルメディア１２にユーザが独自に書き込んだデータが存在していないかを確認する。存在していない場合はステップＳ１４２でＢＤ−Ｊモジュール３３に対して書き込みの許可を通知する。交換されたリムーバブルメディア１２にユーザのデータが存在している場合は、ステップＳ１４０に戻り、再度書き込みを行って良いかどうかの判定をユーザに仰ぐ。

ステップＳ１４６でリムーバブルメディア１２の交換が検知されない場合を考慮する。ユーザが交換をキャンセルしたときや、一定時間交換を検知しないときがありえるが、これらの場合は書き込みを抑制したものとして判定し、ステップＳ１４３に移行してＢＤ−Ｊモジュール３３に対して書き込みを抑制した事を通知する。その後、ステップＳ１４４では交換が行われなかったことを意味する図１７のような表示をユーザに対して行い、リムーバブルメディア１２に書き込みを行わせないということを知らせる。

第１の実施形態と同様に、車載環境では運転中に運転者が画面操作を行うことが禁止されている。そのため、リムーバブルメディア１２にユーザが独自に書き込んだデータが存在しているときは、書き込みを行わせるか抑制するかの初期設定項目を作り、その設定にしたがって動作させることも容易に実施できる。

以上のように、本発明にかかる光ディスク再生装置は、リムーバブルメディアに書き込みを抑制する効果を有し、ブルーレイディスク再生装置として有用である。

１０ 光ディスク再生装置
１１ ＢＤ−ＲＯＭ
１２ リムーバブルメディア
１３ テレビ
１４ ＷＷＷサーバ
２０ ディスク
２１ ピックアップ
２２ サーボ
２３ ローカルストレージ
２４ ネットワークインターフェース
２５ 信号処理手段
２６ 再生手段
３０ ＢＤ−ＲＯＭプレーヤモデル層
３１ ＢＤ−ＲＯＭアプリケーション環境層
３２ ＨＤＭＶモジュール
３３ ＢＤ−Ｊモジュール
３４ ＢＤ−ＲＯＭレジデントシステムソフトウェア層
３５ レジデントアプリケーション
３６ バインディングユニットデータエリア
３７ ネットワーク
３８ ディスク

Claims (5)

1. 第一の記録媒体及び第二の記録媒体上のアプリケーションとデジタルストリームを連動させながら再生する光ディスク再生装置であって、
   前記第一の記録媒体と前記第二の記録媒体のいずれか一方は、前記光ディスク再生装置から取り外し可能なリムーバブルメディアであり、
   仮想パッケージの構築および再生を制御するＢＤ−Ｊアプリケーション部と、
   前記リムーバブルメディアにユーザデータを確認すると、前記ＢＤ−Ｊアプリケーション部へ前記リムーバブルメディアへの書き込みを制限する通知を行うレジデントアプリケーション部と、
   を有する光ディスク再生装置。
2. 前記レジデントアプリケーション部は、前記ＢＤ−Ｊアプリケーション部から前記リムーバブルメディアへの書き込み要求がある度に、前記ＢＤ−Ｊアプリケーション部へ前記リムーバブルメディアへの書き込み制限の有無を通知することを特徴とする請求項１に記載の光ディスク再生装置。
3. 前記レジデントアプリケーション部は、ユーザの初期設定または、前記ＢＤ−Ｊアプリケーション部から前記リムーバブルメディアへの書き込み要求がある度にユーザの選択により前記リムーバブルメディアへの書き込み制限の有無を決定することを特徴とする請求項１に記載の光ディスク再生装置。
4. 前記レジデントアプリケーション部は、前記ＢＤ−Ｊアプリケーション部からのストレージレベルの確認要求がされたときに、前記ＢＤ−Ｊアプリケーション部へ前記リムーバブルメディアへの書き込み制限の有無を通知することを特徴とする請求項１に記載の光ディスク再生装置。
5. 前記レジデントアプリケーション部は、リムーバブルメディアにユーザデータが存在することを確認すると、ユーザにリムーバブルメディアの交換を促す報知をし、その後一定時間ユーザからの応答がない場合、前記ＢＤ−Ｊアプリケーション部へ前記リムーバブルメディアへの書き込みを制限する通知を行うことを特徴とする請求項１に記載の光ディスク再生装置。

Images