JP2010005159A - 保存データ移行方法 - Google Patents

Abstract

【課題】ＢＤ−ＲＯＭ端末本体に保存されたデータから携帯端末へ移行するアプリケーションと関連付けられたデータのみを移行でき、かつ、ＢＤ−ＲＯＭ端末本体に保存されたアプリケーション途中状態を他の携帯端末上で実行したアプリケーションによって読み出す。
【解決手段】異なるアプリケーションのデータが混在する中、ディスク上のデータと記憶領域に予め設定されているアプリケーション関連付け情報及びアプリケーション認証で計算されたデータを基に移行対象のアプリケーションと関連するアプリケーション保存データのみを抽出する工程と、抽出した保存データを外部の読み書き可能なリムーバブルメディアに書き込む工程と、保存データの移行対象の属性情報が記載されたアプリ変換情報を基に前記抽出した保存データを移行先のファイル形式に変換する工程と、変換した保存データを外部の読み書き可能なリムーバブルメディアに書き込む工程とを備える。
【選択図】図１

Description

本発明は、端末内にあるアプリケーションデータの保存領域にある保存データを読み書き可能な記録媒体を通して他の端末に移行する技術に関し、特に、移行対象のアプリケーションプログラムに関連する保存データのみを抽出し、さらには異なる再生機器のフォーマットに変換し、変換したデータを異なる再生機器で再生する技術に関する。

近年、ＢＤ−ＲＯＭ再生機を代表としたＡＶストリームを再生する家電機器に向けて、再生コンテンツとしてＡＶストリームのみでなく、インタラクティブ性の向上を目的としたアプリケーションプログラム（以下、「アプリケーション」という。）を同時に付加するコンテンツ提供方法が主流となってきている。

このような機器では、アプリケーションが自由に読み書きできるハードディスク等の読み書き可能な記録媒体（以下、「ローカルストレージ」という）を兼ね備え、アプリケーションの途中状態や再生機の設定などのデータを、ローカルストレージに保存することが可能である。例えば、ＡＶストリームを再生しながら、その画面にオーバーレイして、コンテンツに関連するシューティングゲームを実現するアプリケーションでは、ゲームのハイスコアをローカルストレージに保存することが出来る。また他の例として、ユーザのお気に入り場面を登録できるアプリケーションを用いて、ストリームの頭出し情報をローカルストレージに記録する等といったユースケースが考えられる。

ところで、近年ＡＶストリームを再生する端末として、ＢＤ−ＲＯＭ再生機を代表とするセットトップボックス型の端末だけでなく、携帯端末も処理能力やディスプレイ技術の向上により、年々増している光景にある。前記前提を踏まえ、例えばＢＤ−ＲＯＭ上に携帯端末用のＡＶストリームを配置し、携帯端末にコピー(例えばManaged Copy)して再生させるサービスが今後盛んになることを想定することは容易である。また、携帯端末はアプリケーションを実行する機能を兼ね備えるものも少なくはない。ＢＤ−ＲＯＭ上に配置されたアプリケーションプログラムを携帯端末にコピーし、携帯端末上で実行させることにより、ＢＤ−ＲＯＭと同様のインタラクティブ性を与えることも可能となることも同時に想定される。

前述したＡＶストリームやアプリケーションの複製に加え、ユーザは例えばＢＤ−ＲＯＭ上で実行したアプリケーションの途中状態を携帯端末で継続して再開できれば利便性が向上するというのは言うまでもないであろう。

同種類の技術として、特許文献１に記載されているものがある。特許文献１に記載のものでは、ゲーム機（親機）にささっているアプリケーションが起動可能なメモリーカード上（子機）にゲーム機に挿入されたディスク上からゲームとゲームデータをコピーし、メモリーカード間でデータを共有する方法が示されている。
特開平１１−２７１１６４号公報

ＢＤ−ＲＯＭディスク上で実行されるアプリケーションの場合、保存するデータは機器内の記憶領域に出力されるのが主流である。すなわち、携帯端末にアプリケーションの途中状態を移行する場合には機器内の記憶領域を一旦記憶媒体に移動させ、記憶媒体から携帯端末で前記途中情報を読ませるのが主流となるであろう。

ＢＤ−ＲＯＭ機器上では様々なディスクからの異なるアプリケーションが実行されることがあるが、アプリケーションがデータを保存する領域は共有されている。アプリケーションとその関連するデータを移行する場合には特許文献１のようにゲームと記憶媒体が1対1の関係の場合はアプリケーションとそのアプリケーションのデータを関連付けることは容易である。様々なアプリケーションの途中状態が共通の記憶領域に混在するＢＤ−ＲＯＭ機器では前記記憶領域ごと移行することは容易である。しかし、データ転送の速度向上、及び移行するデータ容量を制限するためにはアプリケーションに関連するデータのみを移行したいはずである（第１の課題）。

また、ＢＤ−ＲＯＭ上に配置されたアプリケーションプログラムとＢＤ−ＲＯＭ規格にそっていない携帯端末で実行させるアプリケーションではアクセスできる保存領域が異なるし、アクセスするデータの形式も異なる（第２の課題）。

本発明はかかる問題に鑑み、ＢＤ−ＲＯＭ端末本体に保存されたデータから携帯端末へ移行するアプリケーションと関連付けられたデータのみを移行でき、かつ、ＢＤ−ＲＯＭ端末本体に保存されたアプリケーション途中状態を他の携帯端末上で実行したアプリケーションによって読み出すことが可能となる保存データ移行方法を提供することを目的とする。

上記目的を達成するために、本発明の保存データ移行方法は、読み書き可能な記録媒体において、デジタル証明書に基づいて正当性が証明されたアプリケーションプログラム以外によるアクセスが制限され、アプリケーションプログラム毎にアクセスが許可されるディレクトリが異なる制限領域に、アプリケーションプログラムの実行により記録されたデータを移行するデータ移行方法であって、再生装置の記憶領域に保存された様々なアプリケーションの保存データから、ディスク上のデータと記憶領域にあらかじめ設定されているアプリケーション関連付け情報、およびアプリケーション認証で計算されたデータを基に移行対象のアプリケーションと関連するアプリケーション保存データのみを抽出する工程と、前記抽出した保存データを外部の読み書き可能なリムーバブルメディアに書き込む工程と、保存データの移行対象の属性情報が記載されたアプリ変換情報を基に前記抽出した保存データを移行先のファイル形式に変換する工程と、前記変換した保存データを外部の読み書き可能なリムーバブルメディアに書き込む工程とを備える。

また、本発明は、前記アプリケーション保存データのみを抽出する工程で利用するアプリケーション関連付け情報としてアプリケーションによるファイル書き込み時に別途設定された保存データ作成者の識別子、及び権限を利用する。

また、本発明は、前記アプリケーション保存データのみを抽出する工程で利用するアプリケーション関連付け情報としてアプリケーション認証の際に利用するアプリケーションの権限が記載されるパーミッションファイルの共有情報の検証結果を利用する。

また、本発明は、前記保存データの移行対象の属性情報として、データ移行先がｘｌｅｔ放送規格端末と判定した場合、保存データの書き込む工程の際に、ファイル情報管理テーブルのファイル名からルート証明書のダイジェスト長の文字列分を削除したファイル名を用いてデータ移行を行う。

また、本発明は、前記保存データの移行対象の属性情報として、データ移行先が携帯電話規格端末と判定した場合、保存データの書き込む工程の際に、移行対象の保存データファイル全てを移行対象のアプリケーションアーカイブに含める。

また、本発明は、前記保存データの移行対象の属性情報として、データ移行先が携帯電話規格端末と判定した場合、保存データの書き込む工程の際に、移行対象の保存データファイル全てを繋ぎ合わせ、移行対象の属性情報であるマウントパス情報を用いて変換したファイル名でデータ移行を行う。

また、本発明は、前記保存データの移行対象の属性情報として、データ移行先が携帯電話規格端末と判定した場合、保存データの書き込む工程の際に、移行対象の保存データファイル全てをアーカイブし、移行対象の属性情報であるマウントパス情報を用いて変換したファイル名でデータ移行を行う。

上述の構成により本発明に係る保存データ移行方法では、ＢＤ−ＲＯＭ端末本体に保存されたデータから携帯端末へ移行するアプリケーションと関連付けられたデータのみを移行することによって、リムーバブルメディアにコピーが必要なデータ容量を削減でき、より多くのデータ量を保存できるようになる。

さらに、ＢＤ−ＲＯＭ端末本体に保存されたデータから携帯端末へ移行するアプリケーションと関連付けられたデータのみを移行することによって、移行するデータ量が削減し、コピーにかかる時間が削減される効果もある。

また、保存データの移行対象の属性情報が記載されたアプリ変換情報を基に前記抽出した保存データを移行先のファイル形式に変換することによって、保存形式のことなる端末でもＢＤ−ＲＯＭ端末本体に保存されたデータを用いて継続利用できるようになる。

（第１の実施形態）
以降、本発明に係るデータ移行方法の実施形態について説明する。先ず始めに、本発明に係るデータ移行方法の実施行為のうち、使用行為についての形態を説明する。

図１は、本発明に係るデータ移行方法の、使用行為についての形態を示す図である。図１において、本発明に係るデータ移行装置は、再生装置２００（親機）、および携帯端末６００（子機）である。この再生装置２００は、リモコン３００、テレビ４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。記憶媒体５００は再生装置２００、及び携帯端末６００ともに読み書きが可能な媒体である。

以上が本発明に係るデータ移行方法の使用形態についての説明である。続いて再生装置２００が再生の対象としている、記録媒体について説明する。再生装置２００により、再生されるのは、ＢＤ−ＲＯＭ１００である。図２は、ＢＤ−ＲＯＭ１００の内部構成を示す図である。

本図の第４段目にＢＤ−ＲＯＭを示し、第３段目にＢＤ−ＲＯＭ上のトラックを示す。本図のトラックは、ＢＤ−ＲＯＭの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。また、リードインの内側にはＢＣＡ（Ｂｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。

本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもち、ボリューム領域には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは、ＵＤＦやＩＳＯ９６６０などのことであり、通常のＰＣと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっており、２５５文字のファイル名、ディレクトリ名を読み出すことが可能である。ディレクトリ構造を用いてＢＤ−ＲＯＭの応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第１段目のようになる。この第1段目においてＢＤ−ＲＯＭには、Ｒｏｏｔディレクトリの下に、ＣＥＲＴＩＦＩＣＡＴＥディレクトリ、及びＢＤＭＶディレクトリがある。

ＣＥＲＴＩＦＩＣＡＴＥディレクトリの配下には、ディスクのルート証明書のファイル(ａｐｐ．ｄｉｓｃｒｏｏｔ．ｃｅｒｔ)が存在する。ａｐｐ．ｄｉｓｃｒｏｏｔ．ｃｅｒｔはＪａｖａ（登録商標）仮想マシンを用いて動的なシナリオ制御を行うＪａｖａ（登録商標）アプリケーションのプログラムを実行する際に、アプリケーションが改竄されていないか、及びアプリケーションの身元確認を行なうプロセス（以下、署名検証という）に用いられるデジタル証明書である。

ＢＤＭＶディレクトリはＢＤ−ＲＯＭで扱うＡＶコンテンツや管理情報などのデータが記録されているディレクトリであり、ＢＤＭＶディレクトリの配下には、ＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリ、ＢＤＪＯディレクトリ、ＪＡＲディレクトリ、ＭＥＴＡディレクトリと呼ばれる６つのサブディレクトリが存在し、ＩＮＤＥＸ．ＢＤＭＶとＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖの２種類のファイルが配置されている。

ＳＴＲＥＡＭディレクトリには、いわばデジタルストリーム本体となるファイルを格納しているディレクトリであり、拡張子“ｍ２ｔｓ”が付与されたファイル(０００００１. ｍ２ｔｓ)が存在する。

ＰＬＡＹＬＩＳＴディレクトリには、拡張子“ｍｐｌｓ”が付与されたファイル(０００００１.ｍｐｌｓ)が存在する。

ＣＬＩＰＩＮＦディレクトリには、拡張子“ｃｌｐｉ”が付与されたファイル(０００００１.ｃｌｐｉ)が存在する。

ＢＤＪＯディレクトリには、拡張子“ｂｄｊｏ”付与されたファイル(ＸＸＸＸＸ．ｂｄｊｏ)が存在する。

ＪＡＲディレクトリには、拡張子“ｊａｒ”が付与されたファイル(ＹＹＹＹＹ.ｊａｒ)が存在する。

ＭＥＴＡディレクトリには、ＸＭＬファイル(ＺＺＺＺＺ.ｘｍｌ)が存在する。

以下、これらのファイルについて説明する。

＜ＡＶＣｌｉｐ＞
先ず初めに、拡張子“ｍ２ｔｓ”が付与されたファイルについて説明する。拡張子“ｍ２ｔｓ”が付与されたファイルは、ＭＰＥＧ−ＴＳ(ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ)形式のデジタルＡＶストリームであり、ビデオストリーム、1つ以上のオーディオストリーム、グラフィクスストリーム、テキスト字幕ストリーム等を多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分をそれぞれ示している。

＜ＰｌａｙＬｉｓｔ情報＞
拡張子“ｍｐｌｓ”が付与されたファイルは、ＰｌａｙＬｉｓｔ(ＰＬ)情報を格納したファイルである。ＰＬ情報は、ＡＶＣｌｉｐを参照してプレイリストを定義する情報である。

＜Ｃｌｉｐ情報＞
拡張子“ｃｌｐｉ”が付与されたファイルは、ＡＶＣｌｉｐのそれぞれに1対1に対応するClip情報である。管理情報故に、Ｃｌｉｐ情報は、ＡＶＣｌｉｐにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、ＧＯＰの先頭位置を示すＥＰ＿ｍａｐをもっている。以上のＣｌｉｐ情報及びＰＬ情報は、“静的シナリオ”に分類される。

＜ＢＤ−Ｊオブジェクト＞
続いて、拡張子ＢＤＪＯを付したファイルについて説明する。拡張子ＢＤＪＯを付したファイルは、ＢＤ−Ｊオブジェクトを格納したファイルである。ＢＤ−Ｊオブジェクトは、ＰｌａｙＬｉｓｔ情報により定義されるＡＶＣｌｉｐ列と、アプリケーションとの関連付けにより、タイトルを定義する情報である。図３は、ＢＤ−Ｊオブジェクトの内部構成を示す図である。本図に示すように、ＢＤ−Ｊオブジェクトは、“アプリケーション管理テーブル”と、“ＰｌａｙＬｉｓｔ情報に対する参照値”とを示す。“ＰｌａｙＬｉｓｔ情報に対する参照値”は、このタイトルの開始時に、同時に再生すべきＰｌａｙＬｉｓｔ情報を示す。アプリケーション管理テーブルは、破線の矢印ａｉ１に示すように、このタイトルを生存区間とするアプリケーションを指定する情報を羅列したものである。アプリケーション管理テーブルにおけるアプリケーションの指定には、破線の矢印ａｉ２に示すようにアプリケーション特定情報とアプリケーション詳細情報とが含まれる。アプリケーション特定情報としては、アプリケーションの作成者のＩＤ（ＯｒｇａｎｉｚａｔｉｏｎＩＤ）とアプリケーションの識別子(アプリケーションＩＤ)とそのアプリケーションを構成するＪａｖａ（登録商標）アーカイブファイルのＩＤとが用いられる。つまり、一つのアプリケーションは一つ以上のＪａｖａ（登録商標）アーカイブファイルで構成される。

また、アプリケーション管理テーブルには、破線の矢印ａｉ４に示すように、アプリケーション詳細情報として、アプリケーションの名称を示す文字列と、アプリケーションに対応づけるアイコンの所在を指し示すアイコンロケータとを、アプリケーション毎にさせて格納している。アイコンロケータは、Ｊａｖａ（登録商標）アーカイブファイル内に含まれるアイコンをアドレスにより指し示す。

以上が拡張子ＢＤＪＯを付したファイルについての説明である。

続いて“動的なシナリオ”について説明する。“動的に”というのは、再生装置２００における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。ＢＤ−ＲＯＭでは、Ｊａｖａ（登録商標）アプリケーションと同様の記述により、この再生制御を記述することができる。つまりＢＤ−ＲＯＭでは、Ｊａｖａ（登録商標）アプリケーションが、動的シナリオとしての役割を担うことになる。

Ｊａｖａ（登録商標）アプリケーションについて説明する。Ｊａｖａ（登録商標）アプリケーションは、仮想マシンのヒープ領域(ワークメモリとも呼ばれる)にロードされた1つ以上のｘｌｅｔプログラムからなる。このワークメモリにロードされたｘｌｅｔプログラム、及び、データから、アプリケーションは構成されることになる。以上がＪａｖａ（登録商標）アプリケーションの構成である。

このＪａｖａ（登録商標）アプリケーションの実体にあたるのが、図２におけるＢＤＭＶディレクトリ配下のＪＡＲディレクトリに格納されたＪａｖａ（登録商標）アーカイブファイル(ＹＹＹＹＹ．ｊａｒ)である。以降、Ｊａｖａ（登録商標）アーカイブファイルについて、図４を参照しながら説明する。

＜Ｊａｖａ（登録商標）アーカイブファイル＞
Ｊａｖａ（登録商標）アーカイブファイル(図２のＹＹＹＹＹ．ｊａｒ)は、1つ以上のクラスファイル、1つ以上のデータファイル等を1つにまとめることで得られるファイルである。図４は、アーカイブファイルにより収められているプログラム、データの一例を示す図である。本図におけるデータは、枠内に示すディレクトリ構造が配置された複数ファイルを、Ｊａｖａ（登録商標）アーカイバでまとめたものである。枠内に示すディレクトリ構造は、Ｒｏｏｔディレクトリ、ｊａｖａ（登録商標）ディレクトリ、ｉｍａｇｅディレクトリ、ＭＥＴＡ−ＩＮＦディレクトリとからなり、Ｊａｖａ（登録商標）アーカイブファイルは、これらをＪａｖａ（登録商標）アーカイバでまとめることで得られる。

ＲｏｏｔディレクトリにＣｏｐｙディレクトリが、ｊａｖａ（登録商標）ディレクトリにクラスファイル(ａａａ．ｃｌａｓｓ)とセキュリティに用いられるパーミッションファイル（ａａａ．ｐｅｒｍ）が、ｉｍａｇｅディレクトリに、ｍｅｎｕ．ｊｐｇ、ＹＹＹＹＹ．ＩＣＯ等のファイルが配置されている。かかるクラスファイル及びデータは、ＢＤ−ＲＯＭからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Ｊａｖａ（登録商標）アーカイブファイルのファイル名における“ＹＹＹＹＹ”という5桁の数値は、Ｊａｖａ（登録商標）アーカイブファイルのＩＤを示し、ＢＤ−Ｊオブジェクトは、この値を用いてＪａｖａ（登録商標）アーカイブファイルを参照する。

本図における“ＹＹＹＹＹ．ＩＣＯ”はアイコンファイルであり、ＢＤ−Ｊオブジェクトのアイコンロケータにおいて、Ｊａｖａ（登録商標）アーカイブファイルのファイル名からの相対アドレスにより、“ＹＹＹＹＹ／ｉｍａｇｅ／ＹＹＹＹＹ．ＩＣＯ”のように指定される。

本図におけるクラスファイル(図中のａａａ．ｃｌａｓｓ)は、上述したｘｌｅｔプログラムに対応するクラスファイルである。Ｊａｖａ（登録商標）動作環境による動作モード(ＢＤ−Ｊモード)における再生手順は、このクラスファイルのインスタンスにあたるｘｌｅｔプログラムにより規定される。ｘｌｅｔプログラムとは、ＪＭＦ(Ｊａｖａ（登録商標） Ｍｅｄｉａ Ｆｒａｍｅｗｏｒｋ)方式のインターフェイスを利用することができるＪａｖａ（登録商標）プログラムであり、JMF等の方式に従って、キーイベントに基づきプレイリスト再生処理を行う。

更にｘｌｅｔプログラムは、ＷＷＷサイトをアクセスしてコンテンツをダウンロードするという手順を実行することもできる。これによりダウンロードコンテンツと、プレイリスト再生とを交えた斬新な作品を再生させることができる。

またＪａｖａ（登録商標）アーカイブファイルのＭＥＴＡ−ＩＮＦディレクトリには、アプリケーションプログラムのアーカイブの情報を記載したマニフェストファイル（ＹＹＹＹＹ．ＭＦ）、署名ファイル（ＹＹＹＹＹ．ＳＦ）、署名ブロックファイル（ＹＹＹＹＹ．ＲＳＡ）が含まれている。

＜メタファイル＞
ＭＥＴＡディレクトリに格納されたメタファイル（ＺＺＺＺＺ．ｘｍｌ）には、ディスクに入っている映像作品に関する様々な情報が格納されている。メタファイルに格納されている情報としては、ディスクのディスク名及び画像、ディスクが誰によって作成されたかの情報、各タイトルに関わるタイトル名等がある。以上がＢＤ−ＲＯＭ１００についての説明である。メタファイルは、必須のファイルではなく、このファイルが格納されていないＢＤ−ＲＯＭもある。

以上がＢＤ−ＲＯＭについての説明である。

以上説明した各ファイルに基づいて、ＢＤ−ＲＯＭの映画作品は再生装置において再生制御がなされる。図５は再生制御のレイヤモデルを示した図である。図５の第１層は、物理層であり、処理対象たるストリーム本体の供給制御である。この第１層に示すように、処理対象たるストリームは、ＢＤ−ＲＯＭだけではなく、ＨＤＤ（ハードディスクドライブ）などの再生装置に予め組み込まれた記録媒体であるローカルストレージやリムーバブルメディア、ネットワークといったあらゆる記録媒体、通信媒体を供給源としている。これらローカルストレージ、リムーバブルメディア、ネットワークといった供給源に対する制御（ディスクアクセス、カードアクセス、ネットワーク通信）が第１層の制御である。

第２層は、ＡＶデータのレイアである。第１層で供給されたストリームを、どのような復号化方式を用いて復号するのかを規定しているのがこの第２層である。

第３層（ＢＤ管理データ）は、ストリームの静的なシナリオを規定するレイアである。静的なシナリオとは、ディスク制作者によって予め規定された再生経路情報、ストリーム管理情報であり、これらに基づく再生制御を規定しているのがこの第３層である。

第４層（ＢＤ再生プログラム）は、ストリームにおける動的なシナリオを実現するレイヤである。動的なシナリオは、ＡＶストリームの再生手順、及び、その再生に関する制御手順のうち少なくとも一方を実行するプログラムである。動的なシナリオによる再生制御は、装置に対するユーザ操作に応じて変化するものであり、プログラム的な性質をもつ。ここでの動的な再生制御には、２つのモードがある。２つのモードのうち１つは、ＡＶ機器特有の再生環境で、ＢＤ−ＲＯＭに記録された動画データを再生するモード（ＨＤＭＶモード）であり、もう１つはＢＤ−ＲＯＭに記録された動画データの付加価値を高めるモード（ＢＤ−Ｊモード）である。図５において第４層には、ＨＤＭＶモードとＢＤ−Ｊモードの２つのモードが記述されている。ＨＤＭＶモードは、ＤＶＤライクな再生環境での再生モードであり、再生進行を動的に変化させるためのシナリオが記述されたシナリオプログラムが動作する。もう一つのＢＤ−Ｊモードは、Ｊａｖａ（登録商標）仮想マシンを主体とした再生モードであり、Ｊａｖａ（登録商標）アプリケーションから再生制御を行う。

図６は、２つのモードの動的な再生制御にて作成される映画作品を示す図である。図６（ａ）は、ＨＤＭＶモードで動的な再生制御を定義することにより、作成される映画作品の一場面を示す図である。ＨＤＭＶモードはＤＶＤ再生装置が解釈可能なコマンドと良く似たコマンドで再生制御を記述することができるので、ＤＶＤと同じような再生制御、つまり、メニューに対する選択により再生が進行するような再生制御を定義することができる。

図６（ｂ）は、ＢＤ−Ｊモードで動的な再生制御を定義することにより、作成される映画作品である。ＢＤ−ＪモードはＪａｖａ（登録商標）仮想マシンが解釈可能なＪａｖａ（登録商標）言語で制御手順を記述することができる。この再生制御がコンピュ−タ・グラフィックス（ＣＧ）の動作を制御するものなら、ＢＤ−Ｊモードにあっては、動画を表示した画面の横でＣＧ（図中のカンガルーの絵）が動きまわっているような再生制御を定義することができる。

次に本実施形態に係る再生装置２００の詳細について説明する。

図７は、再生装置の内部構成を示すブロック図である。図９に示すように、再生装置は、ＢＤ−ＲＯＭドライブ１、トラックバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、オーディオデコーダ６、イメージメモリ７、グラフィックプレーン９、グラフィックデコーダ８、加算器１０、静的シナリオメモリ１１、動的シナリオメモリ１２、ＨＤＭＶモジュール１４、ＢＤ−Ｊモジュール１５、ＵＯ探知モジュール２１、モード管理モジュール１６、ディスパッチャ１７、ＡＶ再生ライブラリ１８、アプリデータ関連付けモジュール１９、ネットワークインターフェース２３、ローカルストレージ２４、ＢＤファイルシステム２５、リムーバブルメディア２７から構成される。

ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行する。

トラックバッファ２は、ＦＩＦＯメモリであり、ＢＤ−ＲＯＭから読み出されたＡＣＣＥＳＳ ＵＮＩＴが先入れ先出し式に格納される。

デマルチプレクサ３は、ＢＤ−ＲＯＭドライブ１にローディングされているＢＤ−ＲＯＭ、またはローカルストレージ２４上に保存されているトランスポートストリームの多重分離を行い、ＧＯＰを構成するビデオフレームと、オーディオフレームとを得てビデオフレームをビデオデコーダ４に出力し、オーディオフレームをオーディオデコーダ６に出力する。グラフィックストリームはイメージメモリ７に格納し、Ｎａｖｉｇａｔｉｏｎ Ｂｕｔｔｏｎ情報は動的シナリオメモリ１２に格納する。デマルチプレクサ３による多重分離は、ＴＳパケットをＰＥＳパケットに変換するという変換処理を含む。

ビデオデコーダ４は、デマルチプレクサ３から出力されたビデオフレームを復号して非圧縮形式のピクチャをビデオプレーン５に書き込む。

ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのメモリである。

オーディオデコーダ６は、デマルチプレクサ３から出力されたオーディオフレームを復号して、非圧縮形式のオーディオデータを出力する。

イメージメモリ７は、デマルチプレクサ３から読み出されたグラフィックストリーム、Ｎａｖｉｇａｔｉｏｎ Ｂｕｔｔｏｎ情報内のＰＮＧデータ、あるいは、ＢＤファイルシステム２５を介してＢＤ−ＲＯＭまたはローカルストレージ２４から読み出された画像ファイルを格納しておくバッファである。

グラフィックデコーダ８は、イメージメモリ７に格納されたグラフィックストリーム等をデコードしてグラフィックプレーン９に書き込む。グラフィックストリームのデコードにより、字幕が画面上に現れることになる。

加算器１０は、ビデオプレーン５に格納された非圧縮形式のピクチャデータに、グラフィックプレーン９に展開されたイメージを合成して出力する。図６（ｂ）に示した画面（動画を表示した画面の横でＣＧ（図中のカンガルーの絵）が動きまわっているような画面）は、この加算器１０が、グラフィックプレーン９内のイメージと、ビデオプレーン５内のピクチャとを合成することで出力される。

静的シナリオメモリ１１は、カレントのＰＬやカレントのストリーム管理情報を格納しておくためのメモリである。カレントＰＬとは、ＢＤ−ＲＯＭまたはローカルストレージ２４に記録されている複数ＰＬのうち、現在処理対象になっているものをいう。カレントストリーム管理情報とは、ＢＤ−ＲＯＭまたはローカルストレージ２４に記録されている複数ストリーム管理情報のうち、現在処理対象になっているものをいう。

動的シナリオメモリ１２は、カレント動的シナリオを格納しておき、ＨＤＭＶモジュール１４、ＢＤ−Ｊモジュール１５による処理に供されるメモリである。カレント動的シナリオとは、ＢＤ−ＲＯＭまたはローカルストレージ２４に記録されている複数シナリオのうち、現在実行対象になっているものをいう。

制御部１３は、ＲＯＭ、ＲＡＭ、ＣＰＵからなるマイコンシステムであり、ＲＯＭには再生装置を制御するプログラムが記録されており、ＲＯＭ内のプログラムがＣＰＵに読み込まれ、プログラムとハードウェア資源とが協動することにより、ＨＤＭＶモジュール１４、ＢＤ−Ｊモジュール１５、モード管理モジュール１６、ディスパッチャ１７、ＡＶ再生ライブラリ１８、アプリデータ関連付けモジュール１９の機能を実現する。

ＨＤＭＶモジュール１４は、ＨＤＭＶモードの実行主体となるＤＶＤ仮想プレーヤであり、動的シナリオメモリ１２に読み出されたカレントのシナリオプログラムを実行する。

ＢＤ−Ｊモジュール１５は、Ｊａｖａ（登録商標）プラットフォームであり、Ｊａｖａ（登録商標）仮想マシン、コンフィグレーション、プロファイルからなる。ＢＤ−Ｊモジュール１５は、動的シナリオメモリ１２に読み出されたＪａｖａ（登録商標）クラスファイルからカレントのＪａｖａ（登録商標）オブジェクトを生成し、実行する。Ｊａｖａ（登録商標）仮想マシンは、Ｊａｖａ（登録商標）言語で記述されたＪａｖａ（登録商標）オブジェクトを、再生装置におけるＣＰＵのネィティブコードに変換して、ＣＰＵに実行させる。

モード管理モジュール１６は、ＢＤ−ＲＯＭまたはローカルストレージ２４から読み出されたモード管理テーブルを保持して、モード管理及び分岐制御を行う。モード管理モジュール１６によるモード管理とは、動的シナリオをどのＨＤＭＶモジュール１４、ＢＤ−Ｊモジュール１５に実行させるかという、モジュールの割り当てである。

ディスパッチャ１７は、ＵＯから、現在の再生装置におけるモードに適切なＵＯのみを選んで、そのモードを実行するモジュールに受け渡す。例えばＨＤＭＶモードの実行中に、上下左右、アクティベートといったＵＯを受け付けた場合、ＨＤＭＶモードのモジュールにこれらのＵＯを出力するというのがディスパッチャ１７の処理である。

ＡＶ再生ライブラリ１８はＨＤＭＶモジュール１４、ＢＤ−Ｊモジュール１５からの関数呼び出しに応じて、ＡＶ再生機能、プレイリストの再生機能を実行する。ＡＶ再生機能とは、ＤＶＤプレーヤ、ＣＤプレーヤから踏襲した機能群であり、再生開始、再生停止、一時停止、一時停止の解除、静止画機能の解除、再生速度を即値で指定した早送り、再生速度を即値で指定した巻戻し、音声切り替え、副映像切り替え、アングル切り替えといった処理である。プレイリスト再生機能とは、このＡＶ再生機能のうち、再生開始や再生停止をプレイリスト情報に従って行うことをいう。

アプリデータ関連付けモジュール１９は、ＢＤ−ＲＯＭディスク上の情報と、機器内で計算した結果、及びアプリケーションが設定する属性情報を元に、ローカルストレージ２４内からアプリケーションに関連する情報を保存するアプリケーション関連付け情報を生成、及び更新する機能を有している。

ネットワークインターフェース２３は、インターネット上に公開されたＢＤ−ＲＯＭ追加コンテンツのダウンロードに用いられる。ＢＤ−ＲＯＭ追加コンテンツとは、オリジナルのＢＤ−ＲＯＭにないコンテンツで、例えば追加の副音声、字幕、特典映像、アプリケーションなどである。ＢＤ−Ｊモジュール１５からネットワークインターフェース２３を制御することができ、インターネット上に公開された追加コンテンツをローカルストレージ２４にダウンロードすることができる。

ローカルストレージ２４は、再生装置に内蔵されているハードディスク等の磁気記録装置である。リムーバブルメディア２５は外部スロットから挿入される記憶媒体であり、フラッシュ、磁気が代表される。

図８は、ローカルストレージ２４におけるディレクトリ構造を示す図である。Ｒｏｏｔディレクトリの下に、ＡＤＡディレクトリ、ＳＹＳディレクトリ及びＢＵＤＡディレクトリがある。ＡＤＡディレクトリは、アプリケーションが使うデータなどの保存に用いられ、配下ディレクトリにアプリケーション毎にアクセスできるディレクトリが存在する。

本図のディレクトリ構造においてＡＤＡディレクトリは、正当性が証明されたＳｉｇｎｅｄアプリケーション以外によるアクセスが制限される制限領域であり、ＡＤＡディレクトリ配下には、「ＣｅｒｔＩＤディレクトリ」というサブディレクトリがあり、その配下に、「ＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリ」、さらにその配下に「ＡｐｐＩＤディレクトリ」というサブディレクトリがある。

ＣｅｒｔＩＤディレクトリはＢＤ−ＲＯＭ上のディスクルート証明書(ａｐｐ．ｄｉｓｃｒｏｏｔ．ｃｅｒｔ)から導き出されるＩＤを名前に持つディレクトリで、ディスクルート証明書のＳＨＡ−１ダイジェスト値からディレクトリ名前が導かれる。

ＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリは、ＢＤ−ＲＯＭ上のＢＤ−Ｊオブジェクトに記載されている、アプリケーションを作成した組織を特定する３２ｂｉｔの識別子(ＯｒｇａｎｉｚａｔｉｏｎＩＤ)を１６進表記で表した８文字の名前のディレクトリである。

ＡｐｐＩＤディレクトリは、ＢＤ−ＲＯＭ上のＢＤ−Ｊオブジェクトに記載されている、アプリケーションを識別する１６ｂｉｔの識別子(アプリケーションＩＤ)を１６進表記で表した４文字の名前のディレクトリである。アプリケーション識別子の値が０ｘ３ＦＦＦまでであればアプリケーションは署名のないアプリケーションである。

ＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリ、及びＡｐｐＩＤディレクトリの配下には、ＢＤ−Ｊオブジェクトに記載されているアプリケーションが属するＩＤのディレクトリ以下のみアクセスできるようになっている。つまり、“５６７８９ａｂｃ”のＯｒｇａｎｉｚａｔｉｏｎＩＤ、“４００３”のアプリケーションＩＤを持つアプリケーションは、“５６７８９ａｂｃ”ＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリのサブディレクトリである“４００３”ＡｐｐＩＤディレクトリの配下のデータファイルにアクセスできるが、“５６７８９ａａａ”ＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリのサブディレクトリの１つに“４００３”というディレクトリ（図示せず）が存在したとしても、この“５６７８９ａａａ”ＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリの配下であって、“４００３”ＡｐｐＩＤディレクトリの配下のデータファイルにはアクセスできない。また、“５６７８９ａｂｃ”以下のファイルであっても、“４００１”のＡｐｐＩＤディレクトリ以下をアクセスすることはできない。

また、ローカルストレージ２４に保存されたデータファイルには、どのようなアプリケーションでもアクセスできるわけではなく、ローカルストレージ２４は信用された特殊なアプリケーションのみアクセスできる。具体的には、コンテンツ提供者の秘密鍵により署名されたアプリケーションである（以下、Ｓｉｇｎｅｄアプリケーションという）。

ｓｉｇｎｅｄアプリケーションによりアクセスするローカルストレージは秘密鍵と対応する公開鍵を用いて有効性の確認（署名検証）が成功した場合のみ、利用可能になる。公開鍵は、Ｘ．５０９の規格に準拠した証明書という形式で、アプリケーションに含まれる。Ｘ．５０９の詳細な仕様は、国際電信電話諮問委員会より発行されている、ＣＣＩＴＴ Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｘ．５０９（１９８８）、“Ｔｈｅ Ｄｉｒｅｃｔｏｒｙ − Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ”に記載されている。また、アプリケーションの署名検証時においては、リーフ証明書の組織名の末尾に示されるＯｒｇａｎｉｚａｔｉｏｎＩＤがＢＤ−ＲＯＭ上のＢＤ−Ｊオブジェクトに記載されているＯｒｇａｎｉｚａｔｉｏｎＩＤと同一でないと、署名検証は失敗となる。

以上が再生装置の内部構成である。

本実施の形態では、図３、図４に示されたＢＤ−ＲＯＭディスク上の情報と、機器内で計算した結果、及びアプリケーションが設定する属性情報を元に、ローカルストレージ２４内からアプリケーションに関連する情報のみを吸出し、リムーバルメディア２７へとコピーする。また、リムーバルメディア２７へコピーする際にはＢＤ−ＲＯＭアプリケーションが読みこもるデータ形式のみではなく、図１の６００で示す携帯端末がアクセス可能な形式に合わせたものも保存する。このような処理を実現するには大きく２つの工程で再現できる。アプリケーション関連付け情報を生成しローカルストレージ２４へ保存する工程と、アプリケーション関連付け情報を用いてリムーバブルメディアへとコピーする工程である。さらには、リムーバブルメディアにコピーする際に再生装置内の変換先情報を用いて携帯端末で読み込めるデータを生成する工程も有する。以下にこれらの工程を制御するＢＤ−Ｊモジュールの詳細について説明する。

図９は図７に示すＢＤ−Ｊモジュールのより具体的な構成を示す図である。ＢＤ−Ｊモジュール１５はメディア再生モジュール３１、アプリケーションマネージャ３２、アプリケーション認証モジュール３３、ファイルＩ／Ｏモジュール３４から構成される。

メディア再生モジュール３１はＪａｖａ（登録商標）アプリケーション３０に対し、メディア再生制御のためのＡＰＩを提供している。Ｊａｖａ（登録商標）アプリケーション３０がメディア再生制御ＡＰＩを呼び出すと、メディア再生モジュールは対応するＡＶ再生ライブラリ１８の関数を呼び出し、ＡＶ再生制御を行う。

アプリケーションマネージャ３２は、ＢＤ−ＲＯＭ上に記録された図３のＢＤ−Ｊオブジェクトのアプリケーション管理テーブルを基づいてＪａｖａ（登録商標）アプリケーションの起動・終了を管理する。また、アプリケーションマネージャがディスパッチャ１７から受け取ったＵＯイベントを、現在動作中のＪａｖａ（登録商標）アプリケーション３０に渡すといった処理も行う。

アプリケーション認証モジュール３３は、検証手段としてアプリケーションプログラムの署名検証処理を実行する。

具体的には、アプリケーションマネージャ３２により起動されたアプリケーションがＳｉｇｎｅｄアプリケーションか否かを判定し、Ｓｉｇｎｅｄアプリケーションであった場合は、アプリケーション内に含まれたデジタル証明書、署名ファイル、署名ブロックファイルを用いてアプリケーション認証を行なう。

ファイルＩ／Ｏモジュール３４はＪａｖａ（登録商標）アプリケーション３０からのローカルストレージへのアクセス要求の処理を行う。Ｊａｖａ（登録商標）アプリケーション３０はファイルＩ／Ｏモジュールを用いて、コンテンツデータをローカルストレージ上の適切な位置に配置することが出来る。また、Ｊａｖａ（登録商標）アプリケーション３０はローカルストレージ上にあるデータをリムーバブルメディア２７へコピーするよう要求を行え、その際はローカルストレージ上の適切なコンテンツデータがファイルＩ／Ｏモジュール３４を通してコピーされる。

以下にアプリケーション関連付け情報を生成し、Ｊａｖａ（登録商標）アプリケーション３０からローカルストレージ上にあるデータをリムーバブルメディア２７へのコピー要求があった際にローカルストレージ２４からアプリケーションに関連付けられた情報のみコピーする処理の詳細について説明する。

図１０は、本実施形態１に係るアプリケーション関連付け処理を伴うアプリケーション起動の流れを示すフローチャートである。ＢＤ−Ｊモード用のタイトルが再生され、アプリケーションマネージャによってＪａｖａ（登録商標）アプリケーション起動要求がアプリケーション認証モジュールに対して発行される（Ｓ１０１）。アプリケーション起動要求にはアプリケーション管理情報から取得した、起動するアプリケーションのアプリケーションＩＤとＯｒｇａｎｉｚａｔｉｏｎＩＤが含まれる。アプリケーション起動要求を受け取ったアプリケーション認証モジュール３３は受け取ったアプリケーションＩＤを基にＳｉｇｎｅｄか否かを判定する（Ｓ１０２）。Ｓｉｇｎｅｄか否かの判定は、例えば、アプリケーションＩＤの値が、０ｘ０００から０ｘ３ＦＦＦの範囲であれば、Ｓｉｇｎｅｄアプリケーションでなく、０ｘ４０００から０ｘ７ＦＦＦであればＳｉｇｎｅｄアプリケーションである。

アプリケーション認証モジュール３３がＳ１０２でＳｉｇｎｅｄアプリケーションと判定しなかった場合はアプリケーション認証を行わず、アプリケーションはそのまま起動される。しかし、アプリケーション認証を通さないアプリケーショはローカルストレージへのアクセスは不可能となる。ここでアプリ関連付け情報の構成、及びこの時点でどのような情報が入っているかを説明する。

図１１はＳ１０２が完了した時点のアプリ関連付け情報の一例を示す図である。図１１で示されるとおり、アプリ関連付け情報はローカルストレージのシステム領域の一部である。具体的にはシステム領域はアプリ関連付け情報１２０１とアプリ変換情報１２０２を含む。アプリ変換情報１２０２の詳細な説明は後述する。アプリ関連付け情報は起動対象のアプリケーションの情報を含んだ自アプリ情報管理テーブル１２１１と、現状アプリデータ領域に入っているファイルとそのアクセス情報が含まれるファイル情報管理テーブル１２１２からなる。自アプリ情報管理テーブルにはルート証明書のハッシュ１２２１と、ＯｒｇＩＤ１２２２と、ＡｐｐＩＤ１２２３からなる。ファイル情報管理テーブル１２１２はファイルが移行対象か否かのフラグ１２２４、ファイル名１２２５、ファイル名に記載されているファイルの作成したアプリケーションのＯｒｇａｎｉｚａｔｉｏｎＩＤ１２２６、ファイル名に記載されているファイルの作成したアプリケーションのＡｐｐＩＤ１２２７、ファイル名に記載されているファイルのアクセス権限１２２８からなる。図１１を参照のとおり、自アプリ情報管理テーブルに１２１１にはまだ何も情報が入っていないことと、ファイル情報管理テーブル１２１２は図８に示すアプリデータ領域の情報が入っていることがわかる。ファイル名１２２５にはＣｅｒｔＩＤディレクトリ、Ｏｒｇａｎｉｚａｔｉｏｎディレクトリ、ＡｐｐＩＤディレクトリとデータファイルを“／”を挟んで全部繋ぎあわせたものが入る。また、権限１２２８は例えば、アプリ権限とＯｒｇａｎｉｚａｔｉｏｎ権限とからなり、作成者以外のアプリケーションＩＤ、またはＯｒｇａｎｉｚａｔｉｏｎＩＤにアクセス権限を与えるかいなかを指定できる。例えば、両方がなしの場合は０、他アプリケーションＩＤとの共有のみＯＫの場合は１、他ＯｒｇａｎｉｚａｔｉｏｎＩＤとの共有のみＯＫの場合は２、他アプリケーションＩＤ、及び他ＯｒｇａｎｉｚａｔｉｏｎＩＤとの共有がＯＫの場合は３などとしてもよい。

図１０に戻り、アプリケーション認証モジュール３３がＳ１０２でＳｉｇｎｅｄアプリケーションと判定した場合は、アプリケーション認証処理を実行する。アプリケーション認証処理を施すことによって、アプリケーションが改竄されていないことと、アプリケーションの身元確認が行なえる。Ｓｉｇｎｅｄアプリケーションは例えば、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ Ｉｎｃが規定した”Ｓｉｇｎｅｄ Ｊａｒ”形式であり、アプリケーションに各ファイルに対するダイジェストを記載したＭａｎｉｆｅｓｔファイル、及びＳｉｇｎａｔｕｒｅファイル（署名ファイル）を含む。また、Ｓｉｇｎｅｄ Ｊａｒファイルはこれらの２つのファイルに加え、Ｓｉｇｎａｔｕｒｅファイルの署名と、署名を検証する証明書チェーン等の情報をＰＫＣＳ ＃７の形式記述されたＳｉｇｎａｔｕｒｅ Ｂｌｏｃｋファイル（署名ブロックファイル）と認証が成功すれば、ども含む。

上記アプリケーション認証処理は、アプリケーション認証モジュール３３によりアプリケーションのＳｉｇｎａｔｕｒｅ Ｂｌｏｃｋファイルに含まれた証明書チェーンのリーフ証明書から公開鍵を抽出し、Ｓｉｇｎａｔｕｒｅ Ｂｌｏｃｋファイルに含まれるアプリケーション自体から得られた署名値を検証する（Ｓ１０３）。検証が失敗した場合は、アプリケーションは不正であるとみなされ、起動されない（Ｅｎｄ）。署名の検証が成功した場合は、アプリケーションは改竄されていないことが保証されていることを意味する。

次にアプリケーションの身元確認のため、証明書チェーンの検証を行なう。アプリケーション認証モジュール３３はＳｉｇｎａｔｕｒｅ Ｂｌｏｃｋファイルの証明書チェーンからアプリルート証明書を抽出し、検証を行なう（Ｓ１０４）。具体的にはアプリルート証明書の検証は、アプリルート証明書に記載されている有効期限が有効であることを確認するプロセスと、アプリルート証明書がディスク上のＣＥＲＴＩＦＩＣＡＴＥディレクトリ以下に配置されているディスクルート証明書と同一であることを確認するプロセスを含む。アプリルート証明書の検証が失敗であった場合（Ｓ１０４：Ｎｏ）は、アプリケーションは不正であるとみなされ、起動されない（Ｅｎｄ）。

ここでアプリルート証明書の検証が成功であった場合（Ｓ１０４：Ｙｅｓ）は、アプリデータ関連付けモジュール１９にこのことが通知され、アプリデータ関連付けモジュール１９が、アプリルート証明書のＳＨＡ−１ダイジェスト値の計算を行う。アプリルートの証明書のダイジェスト値は、アプリ関連付け情報の自アプリ情報管理テーブルのルートハッシュとして保存される（Ｓ１０５）。

次にアプリデータ関連付けモジュール１９は、Ｓ１０１で受け取ったアプリケーションIDとＯｒｇａｎｉｚａｔｉｏｎＩＤをＳ１０５のルート証明書のダイジェストと関連付けて、自アプリ管理テーブルに登録する（Ｓ１０６）。

図１２はＳ１０６が完了した時点のアプリ関連付け情報の一例を示す図である。図１１で示されるとおり、左にルート証明書のダイジェスト値と右にＯｒｇａｎｉｚａｔｉｏｎＩＤ、及びアプリケーションIDが連携づけて登録されている。

次に、この時点での移行対象を判定するために、アプリデータ関連付けモジュール１９は、アプリ対象付け処理を行う（Ｓ１０７）。アプリ対象付け処理Ｓ１０７の詳細を図１３に示す。

まずは自アプリ情報管理テーブル１２１１にあるルートハッシュ１２２１、ＯｒｇＩＤ１２２２、ＡｐｐＩＤ１２２３の情報は“／”の文字列を挟んで繋げ合わせる（Ｓ２０１）。今回の例の場合は０８１ａ２４ｅｄ／５６７８９ａｂｃ／４０００となる。

次に、ファイル情報管理テーブル１２１２にある行からファイル名１２２５を抽出し、S201で生成した情報から始まるかを比較する（Ｓ２０２）。ここで比較結果が一致した場合（Ｓ２０２：Ｙｅｓ）は、そのファイルは移行対象とみなし、ファイル情報管理テーブル１２１２の前記ファイルに対する対象フラグ１２２４を“Ｙ”にする（Ｓ２０３）。

Ｓ２０２で比較結果が一致しなかった場合（Ｓ２０２：Ｎｏ）は、Ｓ２０１で生成した文字列から、ＡｐｐＩＤと”/”の情報を削り、再度ファイル名１２２５との比較を行う（Ｓ２０４）。ここで比較結果が一致しなかった場合（Ｓ２０４：Ｎｏ）は、そのファイルは移行対象ではないとみなし、ファイルに対する対象付け処理を終了する。

Ｓ２０４で比較結果が一致した場合（Ｓ２０４：Ｙｅｓ）、次にファイル情報管理テーブル１２０２にある行から作成者ＯｒｇＩＤ１２２６と作成者ＡｐｐＩＤ１２２７を抽出し、自アプリ情報管理テーブル１２１１のＯｒｇＩＤ１２２２が作成者ＯｒｇＩＤ１２２６、ＡｐｐＩＤが作成者ＡｐｐＩＤと一致しているかを比較する（Ｓ２０５）。ここで比較結果が一致した場合（Ｓ２０５：Ｙｅｓ）は、そのファイルは移行対象とみなし、ファイル情報管理テーブル１２０２の前記ファイルに対する対象フラグ１２２４を”Y”にする（Ｓ２０３）。

Ｓ２０５で比較結果が一致しなかった場合（Ｓ２０５：Ｎｏ）は、ファイル情報管理テーブル１２０２の権限１２２８を参照し、“０”になっていないこと、つまり共有フラグが立っていないことを確認する（Ｓ２０６）。Ｓ２０６が０だった場合は、そのファイルは移行対象ではないとみなし、ファイルに対する対象付け処理を終了する。Ｓ２０６が０以外だった場合は、そのファイルは移行対象とみなし、ファイル情報管理テーブル１２０２の前記ファイルに対する対象フラグ１２２４を“Ｙ”にする（Ｓ２０３）。Ｓ２０１〜Ｓ２０６ｎｏ処理はファイル情報管理テーブル１２０２に存在するファイル全てに対して行われる。以上が、アプリ対象付け処理の詳細である。

図１４はアプリ対象付け処理Ｓ１０７が完了した時点の不アプリ関連付け情報を示す図である。１、２、５行目が移行対象となったことがわかる。

次に、アプリデータ関連付けモジュール１９はアプリケーションのＪＡＲファイルから、パーミッションファイルを抽出する（Ｓ１０８）。パーミッションファイルは図４に示すとおり、ここでは．ｐｅｒｍの拡張子がついたファイルであり、Ｓｉｇｎｅｄアプリケーションに対し、機器内のどのリソースにアクセスできるかが記載されているメタファイルである。

図１５はパーミッションファイルの一例を示す図である。図１５に示されるとおり、パーミッションファイルは例えば図５で示されるＨＤＤ（ローカルストレージ）やネットワーク等の機器内にあるリソースに加え、アプリケーションによるタイトルの選択が行えるか否かを設定できる。ローカルストレージアクセスが有の場合はアプリケーションが起動した後にローカルストレージ２４のＡＤＡ領域のＢＤ−Ｊオブジェクトに記載されているアプリケーションが属するＩＤのディレクトリ以下の領域に、データの読み書きが可能となる。それ以外のＡＤＡ領域をアクセスするにはクレデンシャルが必要である。

クレデンシャルは例えば他ディスクのＢＤ−ＲＯＭ上のアプリケーションとファイルを共有できる仕組である。クレデンシャルは自アプリケーションが属する以外のＯｒｇａｎｉｚａｔｉｏｎＩＤである、提供元ＯＲＧＩＤ、その提供元が許した提供先のＩＤを示す提供先アプリＩＤと提供先ＯＲＧＩＤ、共有するファイル郡が有効な有効期限、共有するファイル名、前記情報提供元の秘密鍵によりSignした署名、前記署名を復号する際に必要な公開鍵を含む利用証明書からなる。

アプリデータ関連付けモジュール１９はＳ１０８で抽出したパーミッションファイルの中からクレデンシャルの要素が有か無かを確認する（Ｓ１０９）。クレデンシャルが無かった場合（Ｓ１０９：Ｎｏ）は、アプリ関連付け情報を更新せず、そのままアプリケーションを起動する（Ｅｎｄ）。

クレデンシャルが有りの場合（Ｓ１０９：Ｙｅｓ）はまず、署名に記載されている情報を利用証明書内の公開鍵を用いて復号し、署名より上の部分と一致しているかを検証し（Ｓ１１１）、検証結果を確認する（Ｓ１１２）。クレデンシャル検証が成功の失敗の場合（Ｓ１１１：Ｎｏ）は、アプリ関連付け情報を更新せず、そのままアプリケーションを起動する（End）。

クレデンシャル検証が成功の場合（Ｓ１１１：Ｙｅｓ）は、パーミッションファイルの提供先のアプリＩＤとＯｒｇａｎｉｚａｔｉｏｎＩＤがアプリケーション起動要求で受け取ったアプリＩＤとＯｒｇａｎｉｚａｔｉｏｎＩＤと一致しているかを比較する（Ｓ１１２）。一致していない場合（Ｓ１１２：Ｎｏ）は、アプリ関連付けを更新せず、そのままアプリケーションを起動する（Ｅｎｄ）。一致している場合（Ｓ１１２：Ｙｅｓ）は検証に成功したクレデンシャルの情報を元にアプリ関連付け情報を更新する（Ｓ１１３）。まず、パーミッションファイルの利用証明書のＳＨＡ−１ダイジェストの値を計算し、それに“／”の文字列を挟み、パーミッションファイルのファイル名情報を関連付ける。生成した情報はファイル情報管理テーブル１２０２のファイル名と比較を行い、一致した場合にその一致したファイルに対する対象フラグ１２２４が“Ｙ”が設定される。以上が、アプリ起動時におけるアプリ関連付け処理の詳細である。

図１６はクレデンシャルの検証が成功した場合のアプリ関連付け情報の一例を示す図である。図１６で示されるとおり、１、２、５行目に加え、８行目がさらに移行対象となったことがわかる。

図１０の処理が完了した後にはアプリケーション認証モジュール３３がアプリケーションマネージャ３２にアプリケーション認証成功の旨を通達し、アプリケーションマネージャはＳ１０１で発行した起動要求のあったアプリケーションを起動する。

起動したアプリケーションはローカルストレージ２４のＡＤＡ領域のＢＤ−Ｊオブジェクトに記載されているアプリケーションが属するIDのディレクトリ以下の領域に、データの読み書きが可能となる。

次に、起動したアプリがファイルアクセスを行った場合のアプリ関連付け情報の処理を説明する。起動したアプリケーションはアプリデータ領域の属するＯｒｇａｎｉｚａｔｉｏｎＩＤディレクトリとＡｐｐＩＤディレクトリにファイルを作成、及び存在するファイルの削除を行える。存在するファイルを削除した場合は連携して、アプリデータ関連付けモジュール１９はファイル情報管理テーブル１２０２の関連するファイルの行を削除する。またファイルが新たに生成された場合はファイル情報管理テーブル１２０２に行が新たに追加され、対象フラグ１２２４は“Ｙ”、ファイル名１２２５には作成したファイル名、作成者ＯｒｇＩＤ１２２６には自アプリ情報管理テーブル１２１１のＯｒｇＩＤ１２２２の値、作成者ＡｐｐＩＤ１２２７には自アプリ情報管理テーブル１２１２のＡｐｐＩＤ１２２３の値、権限情報１２２８には０が設定される。

さらに、権限情報１２２８はアプリケーションによって直接変更可能であり、権限情報変更ＡＰＩが呼ばれた場合はその値が設定される。

起動中のアプリケーションは次にリムーバブルメディアへの保存データの書き出し要求を行う。アプリケーションがリムーバブルメディアへ書き出す対象として、他端末用に実行する同一コンテキストのアプリケーションそのものをコピーしてもよい。これは例えば図４に示すCopyディレクトリ配下にｘｌｅｔのＪＡＲファイルを配置し、書き出し要求があった際は前記ＪＡＲファイルをリムーバブルメディアへとコピーする。また、前記コピー対象のアプリケーションのアプリケーション保存データを書き出すには機器のローカルストレージにあるアプリデータ領域とシステム領域のアプリ関連付け情報を利用する。

まず、リムーバブルメディアへの保存データの書き出し要求があった際にはアプリ関連付け情報のファイル情報管理テーブルを参照し、各ファイルに対し対象フラグ１２２４が“Ｙ”になっているか否かを参照する。“Ｙ”になっているファイル名と同一のファイルをアプリデータ領域から抽出し、リムーバブルメディアへとコピーを行う。

図１７は書き出し要求の結果、アプリケーション及び関連する保存データがリムーバブルメディア５００に移行した後の一例を示す図である。Ｒｏｏｔ直下にｘｌｅｔにＪＡＲファイル形式でアプリケーションが保存されている。また、図１６のファイル情報管理テーブル１２０２で“Ｙ”と示されたファイルのみコピーされていることがわかる。

ＢＤ−ＲＯＭ端末本体に保存されたデータから携帯端末へ移行するアプリケーションと関連付けられたデータのみを移行でき、結果として移行するデータ量が削減し、コピーにかかる時間が削減される効果がある。

尚、本実施の形態では、再生装置２００以外の端末でデータを利用する方法も加えて提供する。

まず、図１を参照し、リモートの携帯端末６００が再生装置２００と同一データ保存領域形式を持っている場合である。その場合は携帯端末６００がインポート機能を有する必要がある。前記インポートとはリムーバブルメディアのADAディレクトリ以下のファイル全てを携帯端末６００のローカルストレージのアプリデータ領域の同一の場所にコピーすればよい。また、携帯端末６００のＢＤファイルシステムモジュールにより、機器内のアプリデータ領域を参照せず、直接リムーバブルメディアのＡＤＡディレクトリを参照するようにしてもよい。

次に、再生装置２００と同一データ保存領域形式を持っていない端末へのデータ移行方法を提供する。再生装置２００と同一データ保存領域形式を持っていない端末へのデータ移行を行う場合は図１１で示されるローカルストレージのシステム領域内にあるアプリ変換情報１２０２を用いる。

アプリ変換情報１２０２はあらかじめ、再生装置２００が所有している情報で、各データ移行先の情報を持っている。図１８はアプリ変換情報１２０２一例を示す図である。

図１８で示されるとおり、アプリ変換情報はローカルストレージのシステム領域の一部である。アプリ関変換情報はユーザからのアプリ変換要求があった際にどの端末の情報を変換するかの対象かを示すアプリ変換対象フラグ１３０１と、変換先の端末の識別子１３０２と、変換先の端末の規格を示す端末タイプ１３０３と、変換先の端末の会社名１３０４と、変換先の端末の端末名１３０５と、アプリ保存情報を変換先へとマッピングする際に必要な変換パス１３０６からなる。

アプリ変換情報１２０２に示される各情報は端末にあらかじめ設定されていることを想定するが、外部メモリや、ネットワークを用いて変更、追加、削除するようにしてもよい。また、アプリ変換対象フラグ１３０１はユーザによりあらかじめ対象か非対象を変更できる。また変換パス１３０６は、マッピングする端末に必要な変換パス、つまり文字列としたが、文字列ではなく、リモートの携帯端末６００へ変換を行う際に必要なロジック（コールバック）を登録しておくようにしてもよい。

上記で述べたアプリ変換情報は全て必要でない場合があるが、実装に応じて省くことも可能である。例えば、本実施の形態では変換先の端末の識別子１３０２と、変換先の端末の会社名１３０４と、変換先の端末の端末名１３０５は利用されない。

次に、再生装置２００から、リモートの携帯端末６００に保存データを移行する場合に、リモート端末先の保存領域にＣｅｒｔＩＤディレクトリがない、図１９を用いて放送受信端末の場合の例を記載する。

起動中のＢＤ−Ｊアプリケーションはリムーバブルメディアへの保存データの書き出し要求を行う（Ｓ３０１）。

保存データの書き出し要求を受けたアプリデータ関連付けモジュール１９は、アプリ変換情報１２０２から変換先端末規格タイプ１３０５を抽出する（Ｓ３０２）。変換先端末規格タイプ１３０５が放送受信端末ではない場合は（Ｓ３０２：Ｎｏ）、他の端末用の変換処理を実施する（Ｓ３０７）。Ｓ３０２で変換先端末規格タイプ１３０５が放送受信端末である場合は（Ｓ３０２：Ｙｅｓ）、次にアプリデータ関連付けモジュール１９は、ファイル情報管理テーブル１２０２の各行に対し、対象フラグ１２２４に”Ｙ“が設定されているか否かを判別する（Ｓ３０３）。対象フラグ１２２４に”Ｙ“が設定されていない行（Ｓ３０２：Ｎｏ）についてはなにも行わない（Ｅｎｄ）。一方、対象フラグ１２２４に”Ｙ“が設定されていない行が存在すれば、アプリデータ関連付けモジュール１９は、ファイル情報管理テーブル１２０２の”Ｙ“となっている関連する行から、ファイル名１２２５を抽出する（Ｓ３０４）。

次に、アプリデータ関連付けモジュール１９は、Ｓ３０４で取得したファイル名に対し、アプリ変換情報１２０２の変換パス１３０６に書いているロジックを実行する。変換先端末規格タイプ１３０５が放送受信端末である場合は、例えばロジックに次のＳ３０５，Ｓ３０６の処理を実行する。

まず、ファイル名１２２５に設定されている文字列を先頭からルートハッシュの文字列数＋１を削除する（Ｓ３０５）。ファイル情報管理テーブル１２０２が図１６の情報が入っていたとすると、最上段の行のファイル名は５６７８９ａｂｃ／４０００／Ｓｃｏｒｅｓ．ｔｘｔとなる。次に、ファイル名１２２５に設定されている文字列で示されるファイルを再生装置２００のアプリデータ領域から抽出し、Ｓ３０５の文字列としてリムーバブルメディアへと保存する（Ｓ３０６）。

上記図１９の処理により構成したリムーバブルメディアのデータを、リモートの携帯端末６００にインポートすることにより、保存領域にＣｅｒｔＩＤディレクトリがない放送受信端末でも、アプリケーションの保存データが移行可能となる。

図２０は、図１６の情報を保存領域にＣｅｒｔＩＤディレクトリがない放送受信端末用に保存データをリムーバブルメディアに移行した場合のファイル構成を示す図である。図１６と比べ、ＣｅｒｔＩＤディレクトリがないことがわかる。

次に、再生装置２００から、リモートの携帯端末６００に保存データを移行する対象が、保存形式の全く異なる携帯電話の場合の例を図２１を用いて記載する。

起動中のＢＤ−Ｊアプリケーションはリムーバブルメディアへの保存データの書き出し要求を行う（Ｓ４０１）。

保存データの書き出し要求を受けたアプリデータ関連付けモジュール１９は、アプリ変換情報１２０２から変換先端末規格タイプ１３０５を抽出する（Ｓ４０２）。変換先端末規格タイプ１３０５が携帯端末規格ではない場合は（Ｓ４０２：Ｎｏ）、他の端末用の変換処理を実施する（Ｓ４０８）。Ｓ４０２で変換先端末規格タイプ１３０５が携帯端末規格である場合は（Ｓ４０２：Ｙｅｓ）、次にアプリデータ関連付けモジュール１９は、ファイル情報管理テーブル１２０２の各行に対し、対象フラグ１２２４に“Ｙ”が設定されているか否かを判別する（Ｓ４０３）。対象フラグ１２２４に“Ｙ”が設定されていない行（Ｓ４０２：Ｎｏ）についてはなにも行わない（Ｅｎｄ）。一方、対象フラグ１２２４に“Ｙ”が設定されていない行が存在すれば、アプリデータ関連付けモジュール１９は、ファイル情報管理テーブル１２０２の“Ｙ”となっている関連する行から、ファイル名１２２５を抽出する（Ｓ４０４）。

次に、アプリデータ関連付けモジュール１９は、Ｓ４０４で取得したファイル名と関連付けられたアプリ変換情報１２０２の変換パス１３０６に書いているロジックを実行する。変換先端末規格タイプ１３０５が携帯端末規格である場合は、例えばロジックに次のＳ４０５〜Ｓ４０７の処理を実行する。

まず、リモートの携帯端末６００で実行されるコピー対象のアプリケーションをＢＤディスクから抽出する（Ｓ４０５）。コピー対象アプリケーションは例えば、図４に示すように、再生装置２００が実行するアプリケーションの中に保存しているものであり、図のようにＣｏｐｙ／ｘｘｘｘｘ．ｊａｒのようにあらかじめディスク上に配置しておく。

次に、アプリデータ関連付けモジュール１９は、Ｓ４０５で抽出したＪＡＲ内にＳ４０４で示されるファイル名と対象のファイルを再生装置２００のアプリデータ領域から抽出し、保存する（Ｓ４０６）。

最後に、Ｓ４０６で更新した携帯端末６００用アプリケーションＪＡＲファイルそのものをリムーバブルメディアへと保存する（Ｓ４０７）。

上記図２１の処理により構成した携帯端末６００用アプリケーションＪＡＲファイルを携帯端末６００で実行し、前記携帯端末６００用アプリケーションでデータファイルを利用、あるいは端末内の保存領域にコピーすることにより、携帯規格端末でも、アプリケーションの保存データが移行可能となる。

また、以下に携帯端末６００用アプリケーションＪＡＲファイルに保存データを埋め込む方法の他に、マウントパスを利用する方法を利用する方法も図２２を用いて記載する。

起動中のＢＤ−Ｊアプリケーションはリムーバブルメディアへの保存データの書き出し要求を行う（Ｓ５０１）。

保存データの書き出し要求を受けたアプリデータ関連付けモジュール１９は、アプリ変換情報１２０２から変換先端末規格タイプ１３０５を抽出する（Ｓ５０２）。変換先端末規格タイプ１３０５が携帯端末規格ではない場合は（Ｓ５０２：Ｎｏ）、他の端末用の変換処理を実施する（Ｓ５０９）。Ｓ５０２で変換先端末規格タイプ１３０５が携帯端末規格である場合は（Ｓ５０２：Ｙｅｓ）、次にアプリデータ関連付けモジュール１９は、ファイル情報管理テーブル１２０２の行に対し、対象フラグ１２２４に”Ｙ“が設定されているか否かを判別する（Ｓ５０３）。対象フラグ１２２４に”Ｙ“が設定されていない行（Ｓ５０２：Ｎｏ）についてはなにも行わない。一方、対象フラグ１２２４に”Ｙ“が設定されていない行が存在すれば、アプリデータ関連付けモジュール１９は、ファイル情報管理テーブル１２０２の”Ｙ“となっている関連する行から、ファイル名１２２５を抽出する（Ｓ５０４）。

次に、アプリデータ関連付けモジュール１９は、Ｓ５０４で取得したファイル名のファイルをコピー対象として保存しておく（Ｓ５０５）。もし、Ｓ５０５が２回目以降なら、Ｓ５０４で取得したデータはコピー対象データの尾に付加する（Ａｐｐｅｎｄする）。

次にアプリデータ関連付けモジュール１９は、ファイル情報管理テーブル１２０２の次の行が存在するかを確認する（Ｓ５０６）。行が存在した場合は、Ｓ５０３へ移行する（Ｓ５０２：Ｙｅｓ）（Ｓ５０７）。行が存在しなかった場合はアプリデータ関連付けモジュール１９は、ファイル名と関連するマウントパス１３０６をアプリ変換情報１２０２から取得し、アプリ保存データをマウントパス１３０６に書かれているファイル名でリムーバブルメディアに保存する（Ｓ５０８）。前記マウントパスは、携帯端末６００のアプリケーションの保存データのデフォルトのアクセス先である。

上記図２２の処理により保存されたデータを携帯端末６００用にインポートすることにより、アプリケーションはデフォルトのアクセスポイントをアクセスすることで移行した保存データが利用できることになる。

なお、Ｓ５０５で保存データをつなげ合わせるときに、繋ぎ合わせる対象の区切りのデータサイズをメタ情報として保存対象ファイルに付け加えておいてもよい。

なお、Ｓ５０５は保存データをつなげ合わせるとしたが、一つのアーカイブファイルとしてアーカイブしてもよい。

尚、本実施の形態はアプリケーションに関連する情報のみを抽出してリムーバブルメディアへのコピーを行っていたが、リムーバブルメディアの容量が大量に有った場合、あるいはコピー速度は意識しない実装が有った場合は、アプリケーションに関連する情報のみではなく、ＡＤＡの情報を全てリモート端末６００の形式に変換し、移行することも許される。

（変形例）
尚、本発明を上記の実施形態に基づいて説明してきたが、本発明は、上記の実施形態に限定されないのはもちろんである。以下のような場合も本発明に含まれる。

本発明は、各実施形態で説明したフローチャートの処理手順が開示する関連付けを行う装置であるとしてもよい。また、前記処理手順でコンピュータを動作させるプログラムコードを含むコンピュータプログラムであるとしてもよいし、前記コンピュータプログラムからなるデジタル信号であるとしてもよい。

また、本発明は、前記コンピュータプログラム又は前記デジタル信号をコンピュータ読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）、半導体メモリなど、に記録したものとしてもよい。

また、本発明は、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク等を経由して伝送するものとしてもよい。

また、前記コンピュータプログラム又は前記デジタル信号を前記記録媒体に記録して移送することにより、又は前記コンピュータプログラム又は前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。

本発明は、上記実施の形態に記載のデータ管理装置を制御するＬＳＩとしても実施可能である。機能ブロックは、個別に１チップ化されても良いし、一部または全てを含むように１チップ化されてもよい。

ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または、汎用プロセッサで実現してもよい。ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロック及び部材の集積化を行ってもよい。このような技術には、バイオ技術の適用等が可能性としてありえる。

保存データの移行対象たる読み書き可能な記録媒体として、第１、第２実施形態では、記録媒体（例えばＳＤカードやコンパクトフラッシュ（登録商標）などの半導体メモリ）を用いたが、本発明の特徴は、記録媒体の物理的特性に依存するものではなく、本発明は、他の読み書き可能な記録媒体にも適用できる。例えば、外付けハードディスクなどにデータが記録された場合においても上述と同様の効果を奏することはもちろんのことである。

第１の実施形態では、ＢＤ−ＲＯＭを再生する再生機能を有する再生装置について説明したが、本発明は、再生機能のみを有するものではなく記録機能をも有する再生装置にも適用できることはもちろんのことである。

上記実施形態、及び上記変形例をそれぞれ組み合わせるとしてもよい。

本発明に係るアプリケーション、及びプログラム保存データ移行方法は、再生装置上のアプリケーションが保存したデータを他の端末で継続して利用する技術として有用であり、ＢＤ−ＲＯＭの再生機器等の装置に適用しうる。

本発明に係るデータ移行方法の使用形態を示す図 ＢＤ−ＲＯＭにおけるファイル・ディレクトリ構成を示す図 ＢＤ−Ｊオブジェクトの構成を示す図 Ｊａｖａ（登録商標）アーカイブファイルに収められているプログラム、データを示す図 再生装置２００におけるソフトウェアのレイヤモデルを示す図 再生装置２００における２つのモードの動的な再生制御にて作成される映画作品を示す図 本実施の形態１に係る再生装置１００の内部構成を示す図 ローカルストレージ２４のアプリデータ領域のディレクトリ構成を示す図 本実施形態１におけるＢＤ−Ｊモジュールの詳細な構成、及び関連モジュールの構成を示す図 本実施形態１に係る保存データ関連付け処理を伴うアプリケーション起動の流れを示すフローチャート ローカルストレージ２４のシステム領域のアプリ関連付け情報の構成の一例を示す図 自アプリ情報管理テーブル１２１１の情報が埋め込まれ状態のアプリ関連付け情報の一例を示す図 アプリ対象付けの詳細な処理の流れを示すフローチャート アプリ起動が完了した時点でのローカルストレージ２４のシステム領域のアプリ関連付け情報の一例を示す図 パーミッションファイル、およびクレデンシャルの詳細な構成の一例を示す図 クレデンシャルの処理結果を反映したローカルストレージ２４のシステム領域のアプリ関連付け情報の一例を示す図 保存データ関連付け処理が完了した時点でのリムーバブルメディアのディレクトリ構成の一例を示す図 アプリ変換情報１２０２の構成の一例を示す図 アプリケーション保存データ領域にＣｅｒｔＩＤディレクトリがない放送規格端末へ保存データ移行を行う場合の詳細な処理の流れを示すフローチャート 図１９で示す保存データ関連付け処理が完了した時点でのリムーバブルメディアのディレクトリ構成の一例を示す図 携帯電話規格端末へ保存データ移行を行う場合の詳細な処理の流れを示すフローチャート 携帯電話規格端末へ保存データ移行を行う場合の詳細な処理の流れを示すフローチャート

符号の説明

１ ＢＤ−ＲＯＭドライブ
２ トラックバッファ
３ デマルチプレクサ
４ ビデオデコーダ
５ ビデオプレーン
６ オーディオデコーダ
７ イメージメモリ
８ グラフィックデコーダ
９ グラフィックプレーン
１０ 加算器
１１ 静的シナリオメモリ
１２ 動的シナリオメモリ
１３ 制御部
１４ ＨＤＭＶモジュール
１５ ＢＤ−Ｊモジュール
１６ モード管理モジュール
１７ ディスパッチャ
１８ ＡＶ再生ライブラリ
１９ アプリデータ関連付けモジュール
２３ ネットワークインターフェース
２４ ローカルストレージ
２５ ＢＤファイルシステム
２６ リムーバブルメディア検知モジュール
２７ リムーバブルメディア
３０ アプリケーション
３１ メディア再生モジュール
３２ アプリケーションマネージャ
３３ アプリケーション認証モジュール
３４ ファイルＩ／Ｏモジュール
１００ 再生装置
２００ 再生装置
３００ リモコン
４００ テレビ
５００ 記憶媒体（リムーバブルメディア）
６００ 携帯端末
１２０１ アプリ関連付け情報
１２０２ アプリ変換情報
１２１１ 自アプリ情報管理テーブル
１２１２ ファイル情報管理テーブル
１２２１ ルートハッシュ
１２２２ ＯｒｇＩＤ
１２２３ ＡｐｐＩＤ
１２２４ 対象フラグ
１２２５ ファイル名
１２２６ 作成者ＯｒｇＩＤ
１２２７ 作成者ＡｐｐＩＤ
１２２８ 権限
１３０１ 対象
１３０２ 端末識別子
１３０３ 端末タイプ
１３０４ 会社名
１３０５ 端末名
１３０６ 変換パス

Claims (7)

1. 読み書き可能な記録媒体において、デジタル証明書に基づいて正当性が証明されたアプリケーションプログラム以外によるアクセスが制限され、アプリケーションプログラム毎にアクセスが許可されるディレクトリが異なる制限領域に、アプリケーションプログラムの実行により記録されたデータを移行する保存データ移行方法であって、
   再生装置の記憶領域に保存された様々なアプリケーションの保存データから、ディスク上のデータと記憶領域にあらかじめ設定されているアプリケーション関連付け情報、およびアプリケーション認証で計算されたデータを基に移行対象のアプリケーションと関連するアプリケーション保存データのみを抽出する工程と、
   前記抽出した保存データを外部の読み書き可能なリムーバブルメディアに書き込む工程と、
   保存データの移行対象の属性情報が記載されたアプリ変換情報を基に前記抽出した保存データを移行先のファイル形式に変換する工程と、
   前記変換した保存データを外部の読み書き可能なリムーバブルメディアに書き込む工程とを備えることを特徴とする保存データ移行方法。
2. 前記アプリケーション保存データのみを抽出する工程で利用するアプリケーション関連付け情報としてアプリケーションによるファイル書き込み時に別途設定された保存データ作成者の識別子、及び権限を利用することを特徴とする請求項１の保存データ移行方法。
3. 前記アプリケーション保存データのみを抽出する工程で利用するアプリケーション関連付け情報としてアプリケーション認証の際に利用するアプリケーションの権限が記載されるパーミッションファイルの共有情報の検証結果を利用することを特徴とする請求項１のアプリケーション及びプログラム保存データ移行方法。
4. 前記保存データの移行対象の属性情報として、データ移行先がｘｌｅｔ放送規格端末と判定した場合、保存データの書き込む工程の際に、ファイル情報管理テーブルのファイル名からルート証明書のダイジェスト長の文字列分を削除したファイル名を用いてデータ移行を行うことを特徴とする請求項１の保存データ移行方法。
5. 前記保存データの移行対象の属性情報として、データ移行先が携帯電話規格端末と判定した場合、保存データの書き込む工程の際に、移行対象の保存データファイル全てを移行対象のアプリケーションアーカイブに含めることを特徴とする請求項１のアプリケーション、及びプログラム保存データ移行方法。
6. 前記保存データの移行対象の属性情報として、データ移行先が携帯電話規格端末と判定した場合、保存データの書き込む工程の際に、移行対象の保存データファイル全てを繋ぎ合わせ、移行対象の属性情報であるマウントパス情報を用いて変換したファイル名でデータ移行を行うことを特徴とする請求項１の保存データ移行方法。
7. 前記保存データの移行対象の属性情報として、データ移行先が携帯電話規格端末と判定した場合、保存データの書き込む工程の際に、移行対象の保存データファイル全てをアーカイブし、移行対象の属性情報であるマウントパス情報を用いて変換したファイル名でデータ移行を行うことを特徴とする請求項１の保存データ移行方法。

Images