JP2012022727A

JP2012022727A - データ記録方法、データ記録装置、およびデータ記録媒体

Info

Publication number: JP2012022727A
Application number: JP2010157420A
Authority: JP
Inventors: Akinobu Watanabe; 昭信渡邊
Original assignee: Hitachi Consumer Electronics Co Ltd
Current assignee: Hitachi Consumer Electronics Co Ltd
Priority date: 2010-07-12
Filing date: 2010-07-12
Publication date: 2012-02-02
Also published as: CN102332283A; US20120008919A1

Abstract

【課題】
既存プレーヤでの再生互換性を保ったまま、複数コンテンツをダウンロードして同一の記録媒体に追加記録する。
【解決手段】
記録媒体に記録済みのファイル番号以外の未使用の番号をサーバに通知し、ファイル番号が重複しないように管理情報を変更した上で、追加コンテンツをダウンロードする。
【選択図】図１

Description

本発明は、データ記録方法、データ記録装置、およびデータ記録媒体に係り、特に記録媒体にダウンロード記録を行う場合のデータ記録方法、データ記録装置、およびデータ記録媒体に関する。

DVD(Digiral Versatile Disc)やBD（Blu-ray Disc）などの光ディスクに、インターネット上のサーバからAVコンテンツをダウンロードして記録するサービスがある。例えば、KDDI(株)が提供する「DVD Burning」に対応したDVDレコーダやパソコンソフトでは、CPRM技術を用いてコンテンツ保護を行い、記録型DVDにダウンロード記録できる。

一方、BDへのダウンロードは、規格化が検討されている段階であるが、例えば特許文献１に開示されている方法により、BD-RやBD-REなどの記録型BDメディアに、複数のコンテンツを追加でダウンロード記録することが可能となる。

また、BD-RやBD-REなどの記録型BDメディアに、再生専用メディアであるBD-ROMで主に使用されているBDMVフォーマットで記録する方法が、特許文献２に開示されている。

BDMVフォーマットでは、各シーンがクリップと呼ばれる単位で別々のファイルに分かれており、クリップのファイル名命名規則としては、５桁の整数による連番を用いている。（非特許文献１）
例えば、１０個のシーンからなる映画のＡＶコンテンツが、ファイル名０００００．Ｍ２ＴＳから、００００９．Ｍ２ＴＳまでの１０個のストリームファイルからなる構成が考えられる。

特開２００８−１５９２３３特開２００７−１７９６７１

White Pater Blu-ray Disc Format 2.B Audio Visual Application Format Specifications for BD-ROM March 2005

1枚のディスクに、複数コンテンツをダウンロードする場合、いくつかの実現方法が考えられる。

例えば、パーティションを切り、1パーティション1コンテンツとする方法や、サブフォルダを作成し、１サブフォルダに１コンテンツを格納していく方法などである。

しかし、いずれも、すでに市場に普及している既存のＢＤプレーヤでは再生できない、互換性の無い構造となってしまうという問題がある。できれば、従来のＢＤプレーヤとの互換性を保つことで、既存プレーヤのファームウェア更新のコストを下げる要求がある。
その場合、既存のＢＤ規格で規定されている、１ボリューム、1パーティション、しかも、同一のフォルダ構造が必要となる。

従来のＢＤ規格では、各コンテンツ内で、０００００から９９９９９までのユニークなファイル番号を、各クリップ（＝ＡＶストリームファイルとその管理情報を組にしたもの）に１つずつ割り当てて、クリップを特定できるような規定となっているが、異なるコンテンツの間では、ファイル番号のつけ方には決まりはなく、もともと異なるコンテンツを１つのコンテンツとしてまとめて管理する場合には、ファイル番号が重複するという問題が発生する。

例えば、市販のBDコンテンツの場合、ある映画会社AのBD（１）では、クリップ０００００から０００５０までのファイル番号が使用され、別のBD（２）でも、クリップ０００００から０００４０までのファイル番号が使用されているとする。また、別の映画会社BのBD（３）でも、クリップ０００００から０００８０までのファイル番号が使用されているとする。このような場合、０００００から０００４０まで、もしくは、０００００から０００５０までのファイル番号が重複していることにある。

別々の記録媒体として扱う場合は、問題ないが、これらのコンテンツを１つの記録媒体にて、１つのコンテンツとして管理する場合に、問題となり、ダウンロード記録の場合も同様である。

特に、ダウンロード記録は、ダウンロード時間がかかる問題もあることから、データ量が比較的小さいコンンツ、すなわち、短編映画や連続ドラマなどのコンテンツに適しており、これらを１枚の記録媒体に追加記録するニーズは高い。

よって、従来BDプレーヤとの互換性を保ちつつ、複数コンテンツを1枚のディスクにダウンロード記録するためには、コンテンツ間でのクリップのファイル番号の重複を回避する必要がある。

本発明によれば、上記課題は例えば特許請求の範囲記載の構成を用いて解決される。

この発明によれば、従来BDプレーヤとの互換性を保ちつつ、複数コンテンツを1枚のディスクにダウンロード記録することができるという効果がある。

さらに、未使用の番号が飛び飛びの値にフラグメンテーションしている場合でも、それらの値を寄せ集めることで、必要な個数の番号を使用できるため、記録が可能となるという効果がある。

サーバ、レコーダ、ディスクの構成図である。 BDMVフォーマットの、もとのフォルダ／ファイル構成図である。ダウンロード記録時の処理フローである。ダウンロード記録後のフォルダ／ファイル構成図である。再生時のメニューの模式図である。ダウンロード前の論理データ構造図である。ダウンロード後の論理データ構造図その１である。ダウンロード後の論理データ構造図その２である。ダウンロード後の論理データ構造図その３である。サーバでの管理情報生成の模式図である。

以下、本発明のデータ記録方法、記録装置および記録媒体の実施例について図面を用いて詳細に説明する。

図１は、本発明の第1の実施例の構成を示した図である。

１０１は、ダウンロードするコンテンツを格納した、サーバである。例えば、映画会社が提供する専用のコンテンツサーバである。ＢＤＭＶ形式のコンテンツを提供する場合が考えられる。

１０２は、サーバ１０１や記録装置１０３が接続したネットワークである。例えば、インターネット（ＷｏｒｌｄＷｉｄｅＷｅｂ）である。

１０３は、コンテンツをダウンロードし記録する、記録装置である。例えば、ＢＤドライブ内蔵のＢＤレコーダが使用できる。その他に、ＢＤドライブやＳＤＨＣカードライタを内蔵もしくは外付けしたパソコンや、駅等の公共施設内や、ＤＶＤ／ＢＤレンタルショップやコンビニエンスストア内に設置された、ダウンロード販売専用のキオスク端末という構成も考えられる。

１０４は、ダウンロードしたコンテンツを記録する、記録媒体である。例えば、Ｂｌｕ−ｒａｙＤｉｓｃのうち、書き換え可能なＢＤ−ＲＥを使用することができる。その他に、半導体メモリを記録媒体としたＳＤＨＣカードや、金属製の円盤に磁性体を塗布したＨＤＤ（ＨａｒｄＤｉｓｃＤｒｉｖｅ）に著作権保護回路を実装したｉＶＤＲなども使用できる。

１０５は、記録媒体１０４にコンテンツを記録し再生する、ドライブである。例えば、ＢＤ−ＲＥに記録可能なＢＤドライブを使用することができる。その他にも、記録媒体に応じて、ＳＤＨＣカードライタや、ｉＶＤＲアダプタなどが使用できる。

１０６は、ドライブ１０５が記録媒体１０４に記録するコンテンツを一時的に格納しておくメモリである。例えば、ＳＤ−ＲＡＭを使用することができる。その他に、記録装置に内蔵されたＨＤＤの一部を利用することができる。

１０７は、通信部１０８を介してコンテンツをダウンロードする処理を制御し、ダウンロードしたコンテンツをメモリ１０６を経由して記録媒体１０４に記録するようドライブ１０５を制御する、ＣＰＵである。ＣＰＵがメモリ１０６を内蔵する構成も考えられる。また、その他の部分を集積回路化した、ＳｏＣ（ＳｙｓｔｅｍｏｎＣｈｉｐ）も考えられる。

１０８は、インターネットを介してサーバ１０１にアクセスし、コンテンツをダウンロードする通信部である。例えば、ネットワーク通信機能を集積回路化したネットワークチップが使用できる。その他に、イーサネット(登録商標)カードが使用できる。

図２は、本発明の第1の実施例の記録媒体のフォルダ構成、ファイル構成を示した図である。ＢＤ規格の一つである、ＢＤＭＶ形式の構成を示している。

２０１は、最上位のルートフォルダであり、全データがルートフォルダ以下、もしくはサブフォルダ以下に、ファイルとして含まれる。

２０２はＢＤＭＶフォルダであり、ＢＤＭＶ規格で定義されたサブフォルダやファイルがＢＤＭＶフォルダ以下に格納される。

２０３は、インデックスファイルであり、記録媒体に含まれるコンテンツ全体の情報を格納したファイルである。

２０４は、ムービーオブジェクトファイルであり、再生シーケンスなどの情報を格納したファイルである。

２０５は、プレイリストフォルダであり、シーンの再生順序を定義するプレイリストファイルを格納するフォルダである。

２０６は、クリップ情報フォルダであり、ＡＶストリームファイルの情報を格納したクリップファイルを格納するフォルダである。

２０７は、ストリームフォルダであり、ＡＶストリームファイル自体を格納するフォルダである。

２０８は、外部データフォルダであり、追加したフォントデータなどのデータを格納するフォルダである。

２０９は、バックアップフォルダであり、インデックスファイル２０３やムービーオブジェクトファイル２０４やプレイリストフォルダ２０５やクリップ情報フォルダ２０６やプレイリストファイル２１０やクリップファイル２１１の、コピーを格納するフォルダである。コピーは、コピー元と同じ名前のファイル名もしくはフォルダ名となる。

２１０は、プレイリストファイルであり、シーンの再生順序を定義したファイルである。

２１１は、クリップ情報ファイルであり、ＡＶストリームファイルの情報を格納したファイルである。

２１２は、ＡＶストリームファイルであり、ＭＰＥＧ２−ＴＳ形式でエンコードされたストリームデータのファイルである。

プレイリストファイル２１０、クリップ情報ファイル２１１、ＡＶストリームファイル２１２の、ファイル拡張子は、それぞれＭＰＬＳ, ＣＬＰＩ, Ｍ２ＴＳである。

また、プレイリストファイル２１０の、ファイル名は、０００００から９９９９９までの整数である。

また、クリップ情報ファイル２１１、ＡＶストリームファイル２１２の、ファイル名は、０００００から９９９９９までの整数であり、これがファイル番号となっている。

図３は、本発明の第1の実施例の記録装置１０３およびサーバ１０１のダウンロード処理のフローを示した図である。

まず、記録装置１０３に記録媒体１０４を挿入すると、記録装置１０３では記録媒体１０４にアクセスする指示をＣＰＵ１０７が発し、それを受けてドライブ１０５が記録媒体１０４から記録媒体に記録された情報を読み出す（Ｓ３０１）。このとき読み出す情報には、記録媒体のＩＤ情報やＭＫＢ（ＭｅｄｉａＫｅｙＢｌｏｃｋ）情報、インデックスファイルやムービーオブジェクトの情報などがある。

次に、ＳＴＲＥＡＭフォルダもしくはＣＬＩＰＩＮＦフォルダ内のファイルをファイル名でソートすることで、未使用のファイル番号を取得する（Ｓ３０２）。このとき、未使用のファイル番号は、一連の続き番号となっているとは限らず、とびとびの範囲の番号群が複数存在する場合もある。

そして、コンテンツのダウンロードをサーバ１０１へ要求する（Ｓ３０３）。

ダウンロード要求を受信したサーバは（Ｓ３０４）、要求されたコンテンツの総クリップ数、総プレイリスト数を記録装置へ通知するとともに、クリップ情報ファイルやＡＶストリームファイルのファイル名に使用されている最大ファイル番号や、プレイリストファイルやムービーオブジェクトファイルおよびインデックスファイルなどの管理情報ファイルに記録されている情報など、記録媒体の論理記録状態を送信するよう記録装置へ要求し（Ｓ３０５）、その要求を受信した記録装置は（Ｓ３０６）、Ｓ３０２で取得した未使用のファイル番号のうち、小さい値から必要な個数だけを集めた番号群をサーバに通知する（Ｓ３０７）。

未使用のファイル番号と記録状態通知を受信したサーバは（Ｓ３０８）、受信した未使用のファイル番号等の記録状態情報をもとに、管理情報を生成したり、各ファイルのファイル名を変更するような処理を行う（Ｓ３０９）。その後、サーバはコンテンツのダウンロードを開始し（Ｓ３１０）、記録装置はダウンロードされたコンテンツを受信し（Ｓ３１１）、記録媒体に記録する（Ｓ３１２）。

なお、ステップＳ３０２で、ソート処理により未使用のファイル番号を取得する方法以外にも、例えば、プレイリストファイルやインデックスファイルなどの管理ファイルに、未使用のファイル番号を記録するフィールドを設け、追加記録前にそのフィールドから未使用のファイル番号を読み出してステップＳ３０２の代替処理とし、追加記録後に未使用ファイル番号フィールドを更新するステップを追加することにより、所望の目的を達成し、かつ、ソート処理の負荷を軽減することができるという副次的な効果を得ることができる。

このとき、ダウンロード要求を発行するきっかけとしては、記録装置に接続されたディスプレイモニタ画面上に表示されるメニューの中から、ユーザがダウンロードを選択してもよいし、記録媒体に記録されたプログラムが、ロード時の自動実行処理の中で実行されることにより、ダウンロード処理を開始するという方法でもよい。
[プレイリスト最大数通知]
また、後述する図６と図８のように、サーバに通知するファイル番号として、クリップのファイル番号（ＣＬＰＩファイルおよびＭ２ＴＳファイルのファイル番号）以外にも、プレイリストファイル（ＭＰＬＳファイル）のファイル番号についても、最大値を通知する必要が生じる場合がある。すなわち、新しくプレイリストファイルを記録媒体に追加記録するような場合である。

この場合には、クリップの未使用ファイル番号とあわせて、プレイリストの未使用ファイル番号も通知することにより、クリップファイルの場合と同様に、プレイリストファイルの番号重複という問題を解決することができる。

図６と図８を例に取ると、ダウンロード前はプレイリストファイル６０２が1つだけ記録されており（図６）、その番号は＃０である。よって、クリップファイル番号の未使用番号を通知するのと同時に、もしくはその前後のタイミングで、プレイリストファイルの未使用番号の範囲が＃１以上であることから、＃１から＃９９９９９という番号範囲を通知することで、サーバ側ではダウンロードするプレイリストファイル８０４の番号を、通知された未使用番号の範囲の先頭の番号（＃１）に設定することができる。
[ムービーオブジェクト最大数通知]
さらに、後述する図６と図９のように、サーバに通知する情報として、ムービーオブジェクトの情報についても、通知する必要が生じる場合がある。すなわち、ダウンロードするコンテンツを、記録媒体に記録済みのタイトルと独立のタイトルとして、記録媒体に追加記録するような場合である。

この場合には、クリップの未使用ファイル番号やプレイリストの未使用ファイル番号とあわせて、ムービーオブジェクト番号の未使用番号やタイトルの未使用番号を通知することにより、クリップファイルの場合と同様に、ムービーオブジェクト番号の重複や、タイトル番号の重複といった問題を解決することができる。

図６と図９を例に取ると、ダウンロード前はムービーオブジェクトファイル６０１には、ムービーオブジェクト＃１のみが記録されており、また、インデックスファイル６００には、タイトル＃１のみが記録されている。よって、クリップファイル番号の未使用番号を通知するのと同時に、もしくはその前後のタイミングで、ムービーオブジェクトの未使用番号の範囲が＃２以上であることから、＃２から＃９９９９９という番号範囲とタイトル番号の未使用番号の範囲が＃４以上であることから、＃４から＃９９９９９という番号範囲を通知することで、サーバ側ではムービーオブジェクトファイル９０１に追加するムービーオブジェクトの番号を、通知された未使用ファイル番号の最小値である番号（＃２）に設定することができる。
[ムービーオブジェクトの種類別に最大数を通知]
さらに、ムービーオブジェクトファイルに含まれるオブジェクトとして、ムービーオブジェクトだけでなく、後述するＢＤ−Ｊオブジェクトが含まれる場合や、ＢＤ−Ｊオブジェクトのみが含まれる場合も考えられるが、そういった場合にはそれぞれの種類ごとのオブジェクト番号の未使用番号を別個に通知することで、ダウンロードするタイトルのオブジェクト番号をより正確に指定できるという効果がある。

つまり、ダウンロードするタイトルがムービーオブジェクトである場合は、通知された未使用のムービーオブジェクト番号の最小値を、オブジェクト番号に設定すればよいし、ダウンロードするタイトルがＢＤ−Ｊオブジェクトである場合は、通知された未使用のＢＤ−Ｊオブジェクト番号の最小値を、オブジェクト番号に設定すればよい。
[管理ファイルを丸ごと送信]
ところで、クリップのファイル番号の未使用番号のみならず、プレイリストファイルの未使用ファイル番号やムービーオブジェクト、ＢＤ−Ｊオブジェクトの数といった複数の情報をサーバに通知する必要が生じる場合があることも考慮すると、次のような情報を通知する仕組みも考えられる。

すなわち、未使用番号を通知するのではなく、プレイリストファイルやムービーオブジェクトファイルやインデックスファイルといった管理ファイルの記述内容を、全てサーバに送信する方法である。

これにより、サーバに転送するデータ量としては、最大値のみを送付する場合に比べて、多くなるため、転送時間などがより多く必要になってしまうデメリットがあるものの、レコーダ側で空き番号の範囲を探索する処理を省くことができるため、レコーダの処理を軽減できるという効果やその処理を実装するためのコストを削減できるという効果がある。

転送するデータ量が大きい場合は、圧縮したデータを送信することで、転送量を削減でき、処理時間を短縮できる効果がある。

さらに、ファイル番号に無関係なデータの未から構成される管理ファイルは、送信対象から削除することで、同様の効果がある。

図４は、本発明の第1の実施例のダウンロード記録後の記録媒体のフォルダ構成、ファイル構成を示した図である。

図２で示した構成の記録媒体に対して、ダウンロードしたコンテンツを追加記録した場合を示している。図２と同一のものは、説明を割愛する。

図２から変更されているのは、以下の点である。
（１）インデックスファイル４０３が更新されている。
（２）ムービーオブジェクトファイル４０４が更新されている。
（３）プレイリストファイル４２１が追加されている。
（４）プレイリストファイル４１０が更新されている。
（５）クリップ情報ファイル４１１が追加されている。
（６）ＡＶストリームファイル４１２が追加されている。
（７）バックアップフォルダ以下の管理ファイルのうち、上記（１）〜（５）に対応するファイルが、更新もしくは追加されている。

上記（１）〜（７）以外は、変更されていない。よって、必要最小限のファイルのみを更新もしくは追加することで、所望の目的を達成することができる。

特に、あらかじめ記録されていたクリップ情報ファイルやＡＶストリームファイルを変更する必要がなく、変更処理や変更データ量を少なく抑えることができ、処理時間の短縮に効果がある。

さらに、後述する図７で示す例では、（１）（２）は不要となるため、また、後述する図８で示す例では、（１）が不要となるため、変更箇所がさらに少なくなるという効果がある。

図５は、従来BDプレーヤでの再生処理として、メニューでタイトルが選択できることを示す図である。

５００は、ダウンロード前のメニュー画面である。５０１は、記録媒体に含まれるタイトル（作品）の一覧を示し、５０２は１番目のタイトルとして、「映画１」が含まれていることを示すアイコンである。

ダウンロード前のメニュー画面５００で選択できるタイトルは、５０２しかなく、アイコン５０２がカーソルで選択されている状態である。

５１０は、ダウンロード後のメニュー画面である。５１１は、記録媒体に含まれるタイトル（作品）の一覧を示し、５１２は１番目のタイトルとして「映画１」が含まれていることを示すアイコンである。５１３は２番目のタイトルとして「映画２」が含まれていることを示すアイコンである。

ダウンロード後のメニュー画面５１０で選択できるタイトルは、５０１と５０２の２つであり、アイコン５１３がカーソルで選択されている状態である。

メニュー画面で、アイコンを選択し決定すると、該当するムービーオブジェクトに記載されたコマンドが実行され、再生コマンドで指示されたプレイリストが再生される。

図６は、ダウンロード前の記録媒体の論理データ構造を示した図である。

６００は、インデックスファイルであり、記録媒体に含まれるファーストプレイタイトルやトップメニュータイトル、その他の一般タイトルについての情報が含まれている。例えば、タイトル＃１に該当するムービーオブジェクトがどれか、といった情報が含まれる。

６０１は、ムービーオブジェクトファイルであり、ひとつまたは複数のムービーオブジェクト情報が含まれる。例えば、タイトル＃１から参照されるムービーオブジェクト＃１の情報が含まれており、そのなかには、「プレイリスト＃０を再生する」「再生後にメニューに戻る」といったコマンドが記述されている。

６０２は、プレイリストファイル＃０であり、プレイリストを構成するひとつまたは複数のクリップ情報が含まれる。例えば、ムービーオブジェクト＃１で再生されるプレイリスト＃０は、クリップ＃０からクリップ＃３までの４つのクリップで構成されている。

６０３は、クリップに相当するファイル群であり、ファイル名が０００００から００００３までのＣＬＰＩファイルおよびＭ２ＴＳファイルが列挙されている。例えば、クリップ＃０は０００００．ＣＬＰＩファイルと０００００．Ｍ２ＴＳファイルを指す。ＣＬＰＩファイルおよびＭ２ＴＳファイルは、それぞれＣＬＩＰＩＮＦフォルダ、ＳＴＲＥＡＭフォルダに格納される。

以上で示したように、ダウンロード前の記録媒体には、ファイル番号０００００から００００３までのクリップ４つと、プレイリスト番号０００００のプレイリスト１つが含まれる。

再生時の動作としては、タイトル＃１の再生が指示されると、ムービーオブジェクト＃１に記述されたコマンドに従って、プレイリスト＃０が再生される。つまり、クリップ＃０、クリップ＃１、クリップ＃２、クリップ＃３の順に再生され、その後、メニューが表示される、という動作となる。

以下、図７、図８、図９を用いて、ダウンロード記録後の記録媒体の論理データ構造の例を、３通り示す。

図７は、ダウンロード記録後の記録媒体の論理データ構造の第一の例である。

図６と同一のものは、説明を割愛する。

７０２は、プレイリストファイル＃０であり、６０２からの変更点は、クリップ＃４からクリップ＃６が、クリップ＃３の後に追加されている点である。よって、ムービーオブジェクト＃１に記載されたコマンドによりプレイリスト＃０が再生されると、クリップ＃０からクリップ＃６までの７つのクリップが順次再生される。

７０３は、クリップに相当するファイル群であり、ファイル名が０００００から００００６までのＣＬＰＩファイルおよびＭ２ＴＳファイルが列挙されている。６０３からの変更点は、ファイル名が００００４から００００６までのＣＬＰＩファイルおよびＭ２ＴＳファイルが追加されている点である。

以上より、インデックスファイル６００やムービーオブジェクトファイル６０１には変更を発生させず、プレイリストファイル７０２の変更およびクリップ７０３のファイル追加のみの変更に抑えられているため、サーバの変更処理が軽減され、ネットワーク転送量も軽減されるため、ダウンロードに要する時間が短縮されるという効果が得られる。

図８は、ダウンロード記録後の記録媒体の論理データ構造の第二の例である。

図６、図７と同一のものは、説明を割愛する。

８０１は、ムービーオブジェクトファイルであり、６０１からの変更点は、プレイリスト＃１を再生するコマンドが追加された点である。

８０４は、プレイリストファイル＃１であり、クリップ＃４からクリップ＃６で構成されている。よって、ムービーオブジェクト＃１に記載されたコマンドによりプレイリスト＃１が再生されると、クリップ＃４からクリップ＃６までの３つのクリップが順次再生される。

以上より、インデックスファイル６００やプレイリストファイル６０２には変更を発生させず、ムービーオブジェクトファイル８０１の変更およびプレイリストファイル８０４の追加およびクリップ７０３のファイル追加のみの変更に抑えられているため、サーバの変更処理が軽減され、ネットワーク転送量も軽減されるため、ダウンロードに要する時間が短縮されるという効果が得られる。

また、ステップＳ３０７で通知する記録状態通知の転送サイズが、最大ファイル番号と、ムービーオブジェクトファイルの情報に限られるため、さらにネットワーク転送量の軽減効果が期待できる。特に、プレイリストファイルのサイズが大きい場合に、効果的である。

図９は、ダウンロード記録後の記録媒体の論理データ構造の第三の例である。

図６、図７、図８と同一のものは、説明を割愛する。

９００は、インデックスファイルであり、６００からの変更点は、タイトル＃２が追加されている点である。

以上より、プレイリストファイル６０２には変更を発生させず、インデックスファイル９００およびムービーオブジェクトファイル９０１の変更およびプレイリストファイル８０４の追加およびクリップ７０３のファイル追加のみの変更に抑えられているため、サーバの変更処理が軽減され、ネットワーク転送量も軽減されるため、ダウンロードに要する時間が短縮されるという効果が得られる。

また、タイトル＃１とタイトル＃２のデータ構造が論理的に独立しているため、タイトル＃２を追加する際に、タイトル＃１のデータ構造の変更が不要であるため、タイトル＃１の再生動作に弊害を及ぼすリスクが軽減できるという効果がある。特に、記録済みのタイトル＃１と追加記録するタイトル＃２が異なる映画会社提供のものである場合などは、ムービーオブジェクトの記述方法や種類（後述するＢＤ−Ｊオブジェクトの場合）が異なる場合があるため、ひとつのムービーオブジェクトにまとめて記述することが困難であり、本方式が適している。それ以外にも、タイトルとしての独立性が高い場合には、記録済みタイトルからの影響を受けにくい本方式が効果的である。

次に、図１０は、図３のステップＳ３０９で行う、サーバ上での管理情報ファイル生成およびファイル名変更を説明する図である。

図１０は、図７で示すダウンロード前の記録媒体に対して、ダウンロード記録を行い、図９で示す構成にするために必要な処理の例を説明している。

図１０の上半分に記載したのは、ダウンロードされるコンテンツの、変更前の状態であり、この状態で１つのボリュームとしてＢＤパッケージとして販売し再生可能な構成である。

サーバ上では、この状態でコンテンツを保管し、ダウンロード時には、ダウンロード先の記録媒体の記録状態に応じて必要な変更を加えて、ダウンロードする。

図１０の下半分に記載したのは、図９で示す構成にするために変更を加えた状態である。これらのファイルを、図７で示すファイル群にマージおよび追加することで、図９の状態にすることができる。

１０００は、インデックスファイルであり、タイトル＃１が含まれている。

１００１は、ムービーオブジェクトファイルであり、ムービーオブジェクト＃１が含まれている。

１００２は、プレイリストファイル＃０であり、クリップ＃０、１、２で構成される。

１００３は、クリップ群であり、ファイル番号が０００００から００００２までのＣＬＰＩファイルおよびＭ２ＴＳファイルからなる。

図１０のクリップ群のファイル番号（０００００から００００２まで）が、図７のクリップ群のファイル番号（０００００から００００３まで）と重複しているため、ファイル名を変更せずにダウンロード記録すると、ファイル名の衝突が発生し、上書きなどの問題が発生してしまう。

よって、そのようなファイル名の重複を避けるために、図３で示すような未使用ファイル番号通知を行うことにより、サーバ側でファイル名を変更し、それに伴いプレイリストファイル中に記述されたファイル番号を変更することが有効となる。

また、プレイリストファイルのファイル名も重複しているため、プレイリストファイルの番号を０００００から００００１に変更し、併せてムービーオブジェクトの記述も変更することで、同様に、ファイル名重複の問題を回避できる。

なお、ムービーオブジェクトは、ＨＤＭＶオブジェクトとＢＤ−Ｊオブジェクトの２種類があるが、上記はＨＤＭＶオブジェクトで説明した。

ＢＤ−Ｊオブジェクトの場合は、ムービーオブジェクトファイル中に、ムービーオブジェクトの代わりにＢＤ−Ｊオブジェクトが存在し、コマンドの代わりにＪＡＶＡ（Ｒ）プログラムを格納したＪＡＲファイル（図示せず）を実行することで、必要なプレイリストファイルを呼び出し、一連のクリップを順次再生させる。

よって、ダウンロード時に行われる処理で、ＨＤＭＶの場合と異なるのは、ムービーオブジェクトファイルの変更処理と、ＪＡＲファイルの追加であり、本発明で得られる効果を、ＢＤ−Ｊオブジェクトの場合でも同様に得ることができる。

図２では、簡単のために、ファイル番号０００００の各ファイルを1つずつだけ示しているが、映画のような長時間収録のコンテンツは、複数のシーンに分けて構成されている場合が多く、各シーンを１つ１つのファイルに割り当てるオーサリング例が多いが、例えばＮ個のファイルが格納されている場合でも、Ｎ＋１個め以降のファイルをダウンロードして追記することで、同様の効果が適用できる。

同様に、複数コンテンツをまとめてダウンロードの場合は、各コンテンツごとに、上記と同様の処理を行えば、同様の効果を得ることができる。

本発明によれば、ダウンロード記録に対応したレコーダで、１枚の記録媒体に、異なるコンテンツの追加記録を実現でき、その記録媒体を既存のプレーヤで再生できる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１０１サーバ
１０２ネットワーク
１０３記録装置
１０４記録媒体
１０５ドライブ
１０６メモリ
１０７ＣＰＵ
１０８通信部

Claims

映像音声データを記録媒体にダウンロード記録する記録方法であり、
記録媒体は階層構造のフォルダ構成を持ち、
映像音声データが記録されたＭ２ＴＳファイルを保持するＳＴＲＥＡＭフォルダと、
管理情報が記録されたＣＬＰＩファイルを保持するＣＬＩＰＩＮＦフォルダと、
再生情報が記録されたＭＰＬＳファイルを保持するＰＬＡＹＬＩＳＴフォルダを持ち、
前記Ｍ２ＴＳファイルのファイル名が、第1のファイル番号となっており、
前記ＣＬＰＩファイルのファイル名が、第2のファイル番号となっており、
前記第１のファイル番号と前記第２のファイル番号とが１対１に対応した、共通ファイル番号であり、
前記ＭＰＬＳファイルのファイル名が、第3のファイル番号となっており、
再生順序を記述したムービーオブジェクトファイルを持ち、
前記ＭＰＬＳファイルでは、前記共通ファイル番号で再生情報を記述しており、
前記ムービーオブジェクトファイルでは、前記第3のファイル番号で再生順序を記述しており、
このような条件を備えた記録媒体に記録する方法において、
前記ＭＰＬＳファイルのファイル名として使用可能なファイル番号のうち、前記第3のファイル番号に使用されている番号を除いた未使用番号を通知し、
前記未使用番号から第4のファイル番号を選択し、前記第4のファイル番号のファイル名のＭＰＬＳファイルと、前記第4のファイル番号で再生情報が記述されたムービーオブジェクトファイルを、コンテンツ送出サーバからダウンロードして記録することを特徴とする、記録方法。
映像音声データを記録媒体にダウンロード記録する記録装置であり、
記録媒体は階層構造のフォルダ構成を持ち、
映像音声データが記録されたＭ２ＴＳファイルを保持するＳＴＲＥＡＭフォルダと、
管理情報が記録されたＣＬＰＩファイルを保持するＣＬＩＰＩＮＦフォルダと、
再生情報が記録されたＭＰＬＳファイルを保持するＰＬＡＹＬＩＳＴフォルダを持ち、
前記Ｍ２ＴＳファイルのファイル名が、第1のファイル番号となっており、
前記ＣＬＰＩファイルのファイル名が、第2のファイル番号となっており、
前記第１のファイル番号と前記第２のファイル番号とが１対１に対応した、共通ファイル番号であり、
前記ＭＰＬＳファイルのファイル名が、第3のファイル番号となっており、
再生順序を記述したムービーオブジェクトファイルを持ち、
前記ＭＰＬＳファイルでは、前記共通ファイル番号で再生情報を記述しており、
前記ムービーオブジェクトファイルでは、前記第3のファイル番号で再生順序を記述しており、
このような条件を備えた記録媒体に記録する記録装置において、
前記ＭＰＬＳファイルのファイル名として使用可能なファイル番号のうち、前記第3のファイル番号に使用されている番号を除いた未使用番号を通知し、
前記未使用番号から第4のファイル番号を選択し、前記第4のファイル番号のファイル名のＭＰＬＳファイルと、前記第4のファイル番号で再生情報が記述されたムービーオブジェクトファイルを、コンテンツ送出サーバからダウンロードして記録することを特徴とする、記録装置。
映像音声データをダウンロード記録する記録媒体であり、
記録媒体は階層構造のフォルダ構成を持ち、
映像音声データが記録されたＭ２ＴＳファイルを保持するＳＴＲＥＡＭフォルダと、
管理情報が記録されたＣＬＰＩファイルを保持するＣＬＩＰＩＮＦフォルダと、
再生情報が記録されたＭＰＬＳファイルを保持するＰＬＡＹＬＩＳＴフォルダを持ち、
前記Ｍ２ＴＳファイルのファイル名が、第1のファイル番号となっており、
前記ＣＬＰＩファイルのファイル名が、第2のファイル番号となっており、
前記第１のファイル番号と前記第２のファイル番号とが１対１に対応した、共通ファイル番号であり、
前記ＭＰＬＳファイルのファイル名が、第3のファイル番号となっており、
再生順序を記述したムービーオブジェクトファイルを持ち、
前記ＭＰＬＳファイルでは、前記共通ファイル番号で再生情報を記述しており、
前記ムービーオブジェクトファイルでは、前記第3のファイル番号で再生順序を記述しており、
このような条件を備えた記録媒体において、
前記ＭＰＬＳファイルのファイル名として使用可能なファイル番号のうち、前記第3のファイル番号に使用されている番号を除いた未使用番号を通知し、
前記未使用番号から第4のファイル番号を選択し、前記第4のファイル番号のファイル名のＭＰＬＳファイルと、前記第4のファイル番号で再生情報が記述されたムービーオブジェクトファイルが、コンテンツ送出サーバからダウンロードされ記録されることを特徴とする、記録媒体。