JP2010272184A - 記録方法、記録装置 - Google Patents

Abstract

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

Description

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

DVD(Digital Versatile Disc)やBD（Blu-ray Disc(登録商標)）などの光ディスクに、インターネット上のサーバからコンテンツをダウンロードして記録するサービスがある。例えば、特許文献１（特開2006-33067）には、
「簡単に、データ記録媒体に記録されているコンテンツに対して、新たなコンテンツを追加したり、コンテンツを更新して、コンテンツを再生できるようする。」という課題に対し、
「プレイリスト更新部３６は、サーバから取得したコンテンツパッケージに含まれるアップデートファイルに基づいて、アップデートファイルのoperation_typeにより指定される方法で、光ディスクに記録されているPlayListを更新する。再生制御部３１は、更新されたPlayListを再生することにより、光ディスクに記録されているAVストリームの再生に同期させて、コンテンツパッケージに含まれる追加用または更新用のコンテンツを再生させる。本発明は、再生装置に適用できる。」という解決手段を用いることが記載されている。

特開2006-33067（要約参照）

1枚のディスクに複数コンテンツをダウンロードする場合、いくつかの実現方法が考えられる。例えば、パーティションを切り、1パーティション1コンテンツとする方法や、サブフォルダを作成し、１サブフォルダに１コンテンツを格納していく方法などである。

しかし、いずれもすでに市場に普及している既存のＢＤプレーヤでは再生できない互換性の無い構造となってしまうという問題がある。できれば、従来のＢＤプレーヤとの互換性を保つことで、既存プレーヤのファームウェア更新のコストを下げる要求がある。

その場合、既存のＢＤ規格で規定されている、１ボリューム、1パーティション、しかも同一のフォルダ構造が必要となる。

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

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

このようにファイル番号が重複することは、別々の記録媒体として扱う場合は問題ないが、これらのコンテンツを１つの記録媒体にて１つのコンテンツとして管理する場合に同ファイル番号のファイルを上書きしてしまう問題が発生する。この問題はダウンロード記録の場合も同様である。特にダウンロード記録は、ダウンロード時間がかかる問題もあることから、データ量が比較的小さいコンテンツ、すなわち、短編映画や連続ドラマなどのコンテンツに適しており、これらを１枚の記録媒体に追加記録するニーズは高い。

ここで、前記特許文献１（特開2006-33067）では、既に映画等が記録されたディスク販売後にそのディスク販売者がその映画の他言語字幕等を追加するための更新用コンテンツパッケージをサーバから配信することについて着目している。そのため、特許文献１（特開2006-33067）では、販売されたディスクに記録されているファイル番号を把握しているディスク販売者が、そのファイル番号と重複しないファイル番号を用いて更新用コンテンツパッケージを作成して配信すればよく、ドライブ側がサーバから複数のコンテンツをダウンロードする際にファイル番号の重複を回避しなければならない点については考慮されていなかった。

そのため、本発明では上記課題を解決し、従来BDプレーヤとの互換性を保ちつつ、複数コンテンツを1枚のディスクに適切にダウンロード記録することを目的とする。

本発明によれば、例えば特許請求の範囲記載の構成により前記課題を解決する。

より具体的には、例えば、記録媒体に記録済みの最大ファイル番号をサーバに通知し、ファイル番号が重複しないようにファイル名等が更新されたコンテンツをダウンロードし、記録媒体に記録する。

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

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

以下、本発明の好適な実施例について図面を用いて説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プレイリストファイル２１０、クリップ情報ファイル２１１、ＡＶストリームファイル２１２の、ファイル拡張子は、それぞれmpls、clpi、m2tsである。

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

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

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

次に、ＳＴＲＥＡＭフォルダもしくはＣＬＩＰＩＮＦフォルダ内のファイルをファイル名でソートすることで、最大ファイル番号を取得する（Ｓ３０２）。

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

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

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

このように、ダウンロードをする際、記録装置からサーバへ、Ｍ２ＴＳファイルとＣＬＰＩファイルそれぞれのファイル名の共通ファイル番号（第１ファイル番号とする）のうち最大の値（最大第１ファイル番号とする）を通知し、前記最大第１ファイル番号に基づいてファイル名が更新されたＭ２ＴＳファイルおよびＣＬＰＩファイルを前記サーバからダウンロードする。また、サーバからダウンロードされる前記Ｍ２ＴＳファイルおよび前記ＣＬＰＩファイルのファイル名は、前記最大第１ファイル番号より大きいファイル番号に基づいて更新される。なお、更新をする際、最大第１ファイル番号より大きい例で説明をしたが、大きい番号に限られず、小さい番号であってもファイル番号が重複しない番号であれば、用いてもよい。この方が管理が容易になる場合もあるからである。このようにして、ファイル番号の重複を回避し、適切にダウンロード記録をすることが可能となる。

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

このとき、ダウンロード要求を発行するきっかとしては、記録装置に接続されたディスプレイモニタ画面上に表示されるメニューの中から、ユーザがダウンロードを選択してもよいし、記録媒体に記録されたプログラムが、ロード時の自動実行処理の中で実行されることにより、ダウンロード処理を開始するという方法でもよい。多様なユーザニーズに対応するためである。

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

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

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

上記（１）〜（６）以外は、変更されていない。よって、必要最小限のファイルのみを更新もしくは追加することで、所望の目的を達成することができる。
特に、あらかじめ記録されていたクリップ情報ファイルやＡＶストリームファイルを変更する必要がなく、変更処理や変更データ量を少なく抑えることができ、処理時間の短縮に効果がある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図６と同一のものは、説明を省略する。

前述の図３や後述の図１０とも関連するが、ダウンロードをする際、記録装置からサーバへ、Ｍ２ＴＳファイルとＣＬＰＩファイルそれぞれのファイル名の共通ファイル番号（前述の通り、第１ファイル番号。図７ではＭ２ＴＳファイルのファイル名“0000.clpi”とＣＬＰＩファイルのファイル名“0000.m2ts”に共通する“0000”に相当する。）のうち最大の値（前述の通り、最大第１ファイル番号。図７ではダウンロード前のディスク（図６記載）に記録されているファイル番号のうち最大の“0003”に相当する。）を通知し、前記最大第１ファイル番号に基づいてファイル名が更新されたＭ２ＴＳファイルおよびＣＬＰＩファイル（図７では“0004.clpi”〜“0006.clpi”、“0004.m2ts”〜“0006.m2ts”に相当する。）を前記サーバからダウンロードする。また、サーバからダウンロードされる前記Ｍ２ＴＳファイルおよび前記ＣＬＰＩファイルのファイル名は、前記最大第１ファイル番号より大きいファイル番号に基づいて更新される。

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

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

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

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

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

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

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

前述の図３や後述の図１０とも関連するが、ダウンロードをする際、記録装置からサーバへ、ＭＰＬＳファイルのファイル名（第２ファイル番号とする。図８ではＭＰＬＳファイルのファイル名“＃0”や“＃1”に相当する。）のうち最大の値（最大第2ファイル番号とする。図8ではダウンロード前のディスク（図６記載）に記録されているファイル番号のうち最大の“＃0”に相当する。）を通知し、前記最大第2ファイル番号より大きいファイル番号に基づいてファイル名が更新されたＭＰＬＳファイルを前記サーバからダウンロードし前記記録媒体に記録する（図8では“プレイリストファイル＃１”に相当する。）。

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

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

このようにして、サーバに通知するファイル番号として、クリップのファイル番号（ＣＬＰＩファイルおよびＭ２ＴＳファイルのファイル番号）以外にも、プレイリストファイル（ＭＰＬＳファイル）のファイル番号についても最大値を通知することにより、新しくプレイリストファイルを記録媒体に追加記録するような場合にも対応可能である。この場合には、クリップのファイル番号の最大値とあわせて、プレイリストのファイル番号の最大値も通知することにより、クリップファイルの場合と同様に、プレイリストファイルの番号重複という問題を解決することができる。

図６と図８を例に取ると、ダウンロード前はプレイリストファイル６０２が1つだけ記録されており（図６）、その番号は＃０である。よって、クリップファイル番号の最大値を通知するのと同時に、もしくはその前後のタイミングで、プレイリストファイルの番号の最大値（＃０）を通知することで、サーバ側ではダウンロードするプレイリストファイル８０４の番号を、通知された番号（＃０）に１を足した番号（＃１）に設定することができる。

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

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

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

前述の図３や後述の図１０とも関連するが、ダウンロードをする際、記録装置からサーバへ、タイトル情報のタイトル情報名（第3ファイル番号とする。図9ではタイトル情報のタイトル情報名“＃1”や“＃2”に相当する。）のうち最大の値（最大第3ファイル番号とする。図9ではダウンロード前のディスク（図６記載）に記録されているタイトル情報名のうち最大の“＃1”に相当する。）を通知し、前記最大第3ファイル番号より大きいファイル番号に基づいてタイトル情報名が更新されたタイトル情報を前記サーバからダウンロードし前記記録媒体に記録する（図9では“タイトル＃2”に相当する。）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (8)

1. サーバから記録装置に情報をダウンロードし、記録媒体に記録する記録方法であって、
   前記記録媒体は階層構造のフォルダ構成を有し、
   前記フォルダ構成には、
   映像音声データが記録されているＭ２ＴＳファイルを格納するＳＴＲＥＡＭフォルダと、
   管理情報が記録されているＣＬＰＩファイルを格納するＣＬＩＰＩＮＦフォルダが含まれ、
   前記Ｍ２ＴＳファイルとＣＬＰＩファイルが対になって１つのクリップを構成し、該１つのクリップを構成するＭ２ＴＳファイルとＣＬＰＩファイルそれぞれのファイル名は、共通のファイル番号である第１ファイル番号に基づいて記述されており、
   前記ダウンロードをする際、前記記録装置から前記サーバへ、前記第１ファイル番号のうち最大の値である最大第１ファイル番号を通知し、
   前記最大第１ファイル番号に基づいてファイル名が更新されたＭ２ＴＳファイルおよびＣＬＰＩファイルを前記サーバからダウンロードし前記記録媒体に記録することを特徴とする記録方法。
2. 請求項１記載の記録方法であって、
   前記サーバからダウンロードされた前記Ｍ２ＴＳファイルおよび前記ＣＬＰＩファイルのファイル名は、前記最大第１ファイル番号より大きいファイル番号に基づいて更新されていることを特徴とする記録方法。
3. 請求項１または２いずれか一項記載の記録方法であって、
   前記フォルダ構成にはさらに、再生情報が記録されているＭＰＬＳファイルを格納するＰＬＡＹＬＩＳＴフォルダが含まれ、
   前記ＭＰＬＳファイルのファイル名は第２ファイル番号に基づいて記述されており、
   前記ダウンロードをする際、前記記録装置から前記サーバへ、前記第２ファイル番号のうち最大の値である最大第２ファイル番号を通知し、
   前記最大第２ファイル番号より大きいファイル番号に基づいてファイル名が更新されたＭＰＬＳファイルを前記サーバからダウンロードし前記記録媒体に記録することを特徴とする記録方法。
4. 請求項１から３いずれか一項記載の記録方法であって、
   前記フォルダ構成にはさらに、タイトル情報が記録されているインデックスファイルが含まれ、
   前記タイトル情報のタイトル情報名は第３ファイル番号に基づいて記述されており、
   前記ダウンロードをする際、前記記録装置から前記サーバへ、前記第３ファイル番号のうち最大の値である最大第３ファイル番号を通知し、
   前記最大第３ファイル番号より大きいファイル番号に基づいてタイトル情報名が更新されたタイトル情報を前記サーバからダウンロードし前記記録媒体に記録することを特徴とする記録方法。
5. サーバから映像音声データをダウンロードし、記録媒体に記録する記録装置であって、
   通信部と記録部と、該通信部と該記録部を制御する制御部とを有し、
   前記記録媒体は階層構造のフォルダ構成を有し、
   前記フォルダ構成には、
   映像音声データが記録されているＭ２ＴＳファイルを格納するＳＴＲＥＡＭフォルダと、
   管理情報が記録されているＣＬＰＩファイルを格納するＣＬＩＰＩＮＦフォルダが含まれ、
   前記Ｍ２ＴＳファイルとＣＬＰＩファイルが対になって１つのクリップを構成し、該１つのクリップを構成するＭ２ＴＳファイルとＣＬＰＩファイルそれぞれのファイル名は、共通のファイル番号である第１ファイル番号に基づいて記述されており、
   前記ダウンロードをする際、前記通信部から前記サーバへ、前記第１ファイル番号のうち最大の値である最大第１ファイル番号が通知され、
   前記最大第１ファイル番号に基づいてファイル名が更新されたＭ２ＴＳファイルおよびＣＬＰＩファイルが前記サーバからダウンロードされ、該Ｍ２ＴＳファイルおよび該ＣＬＰＩファイルが前記記録部によって前記記録媒体に記録されることを特徴とする記録装置。
6. 請求項５記載の記録装置であって、
   前記サーバからダウンロードされた前記Ｍ２ＴＳファイルおよび前記ＣＬＰＩファイルのファイル名は、前記最大第１ファイル番号より大きいファイル番号に基づいて更新されていることを特徴とする記録装置。
7. 請求項５または６いずれか一項記載の記録装置であって、
   前記フォルダ構成にはさらに、再生情報が記録されているＭＰＬＳファイルを格納するＰＬＡＹＬＩＳＴフォルダが含まれ、
   前記ＭＰＬＳファイルのファイル名は第２ファイル番号に基づいて記述されており、
   前記ダウンロードをする際、前記通信部から前記サーバへ、前記第２ファイル番号のうち最大の値である最大第２ファイル番号が通知され、
   前記最大第２ファイル番号より大きいファイル番号に基づいてファイル名が更新されたＭＰＬＳファイルが前記サーバからダウンロードされ、該ＭＰＬＳファイルが前記記録部によって前記記録媒体に記録されることを特徴とする記録装置。
8. 請求項５から７いずれか一項記載の記録装置であって、
   前記フォルダ構成にはさらに、タイトル情報が記録されているインデックスファイルが含まれ、
   前記タイトル情報のタイトル情報名は第３ファイル番号に基づいて記述されており、
   前記ダウンロードをする際、前記通信部から前記サーバへ、前記第３ファイル番号のうち最大の値である最大第３ファイル番号が通知され、
   前記最大第３ファイル番号より大きいファイル番号に基づいてタイトル情報名が更新されたタイトル情報が前記サーバからダウンロードされ、該タイトル情報が前記記録部によって前記記録媒体に記録されることを特徴とする記録装置。

Images