"記録媒体に記録されたコンテンツを再生すると共に、当該コンテンツに対する機能を実行する再生装置であって、前記コンテンツに対する機能には、標準化された再生制御機能と、機器固有の機器固有機能とがあり、記録媒体からバイトコードアプリケーションを読み出して、動作させるプラットフォーム部と、再生制御機能を実行する再生制御部と、機器固有機能を実行する固有機能制御部とを備え、前記再生装置のプラットフォーム部は、バイトコードアプリケーションが利用可能なプログラミングインターフェイスを有し、前記バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含み、前記バイトコードアプリケーションは、再生制御用プログラミングインターフェイスをコールすることで、再生制御部に再生制御を命じ、通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、固有機能制御部に機器固有の制御を命じることを特徴とする再生装置。前記記録媒体は第1記録媒体であり、第1記録媒体には、ルートディレクトリの配下に第1ディレクトリと、第2ディレクトリとが存在し、第1ディレクトリは、本編コンテンツが記録されているディレクトリであり、前記バイトコードアプリケーションは、第1ディレクトリに記録されており、第2ディレクトリは、持出し視聴用コンテンツが記録されており、当該持出し視聴用コンテンツは、本編コンテンツとは異なるフォーマットのコンテンツであって、機器固有機能の対象となるものであり、前記機器固有機能とは、持出し視聴用コンテンツを構成するファイルを、第1記録媒体から第2記録媒体へと、コピーするというメディア間コピーであることを特徴とする請求項1記載の再生装置。前記第2ディレクトリの配下には、複数のコピーソース格納ディレクトリが存在し、前記持出し視聴用コンテンツは、何れか1つのコピーソース格納ディレクトリに記録されており、前記バイトコードアプリケーションは、何れかのコピーソース格納ディレクトリのファイルパスを、カレントのソースロケーションとして固有機能制御部に設定することを命じ、前記固有機能制御部は、何れか1つのコピーソース格納ディレクトリがカレントソースロケーションとして設定されれば、コピーソース格納ディレクトリから持出し視聴用コンテンツを読み出して、第2記録媒体に書き込むことで、機器固有機能を実行することを特徴とする請求項2記載の再生装置。前記第1記録媒体の第1ディレクトリには、機器固有機能のためのオンメディアライブラリが記録されており、オンメディアライブラリは、第1ディレクトリに記録された他のバイトコードアプリケーションに、機器固有機能実行のためのプログラミングインターフェイスを提供するものであり、前記オンメディアライブラリは、他のバイトコードアプリケーションから、機器固有機能実行用プログラミングインターフェイスのコールがなされた場合、当該プログラミングインターフェイスのコールをソケットコマンドに変換した上で固有機能制御部に出力し、固有機能制御部からのレスポンスを戻り値又はイベントに変換して、コールを行った他のバイトコードアプリケーションに返し、前記ソケット接続は、前記ソケットコマンド及びレスポンスを伝送するための通信路を構成することを特徴とする請求項2記載の再生装置。前記第1記録媒体には、持出し視聴用コンテンツを識別するためのコンテンツIDが記録されており、コンテンツIDの一部をなすビットは、持出し視聴用コンテンツの供給源であるコンテンツプロバイダを識別するためのものであり、バイトコードアプリケーションは、固有機能制御部に、コンテンツIDと、シリアル番号とを含むコマンドを送信し、固有機能制御部は、コンテンツIDと、シリアル番号との組みをサーバに送信して、持出し視聴用コンテンツの供給源であるコンテンツプロバイダが、固有機能制御を利用する正当権限を有しているかどうかをサーバに判断させ、正当権限を有しているとサーバが判断した場合は、機器固有機能を実行するが、正当権限を有していないと判断した場合、機器固有機能を実行しないことを特徴とする請求項2記載の再生装置。前記持出し視聴用コンテンツに含まれるデジタルストリームは、暗号化されて前記第1記録媒体上に記録されており、前記固有機能制御部は更に、前記第2記録媒体に記録すべき持出し視聴用コンテンツに含まれるデジタルストリームを第2記録媒体に書き込む際、前記第一記録媒体に属するシリアルIDと、前記デジタルストリームのコンテンツ識別子と、前記第2記録媒体の媒体識別子及び暗号キーと、を前記外部サーバに送信し、前記第2記録媒体固有の保護方式とは、前記シリアルID、コンテンツ識別子、媒体識別子及び暗号キーに対応した復号鍵をサーバから取得して、前記第2記録媒体の保護された領域に記録することである、請求項4に記載の再生装置。前記再生装置はさらに、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルの正当性を検証する検証部を備え、前記検証部は、再生装置内に組み込まれた認証鍵を元に、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルのハッシュ値を算出し、前記算出されたハッシュ値が、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルに含まれるデジタル署名の値と一致していれば、バイトコードアプリケーションは、正当であると判断し、前記検証部がデジタル署名ファイルが正当でないと判断した場合、前記固有機能制御部はバイトコードアプリケーションから前記再生制御とは異なる機器固有の機能に関連したコマンドを受け取っても、前記再生制御とは異なる機器固有機能の実行を拒否する、請求項4に記載の再生装置。再生装置は、通信管理部を備え、前記ソケット通信のためのプログラミングインターフェイスは、通信管理部によって供給され、バイトコードアプリケーションからのネットワーク接続要求を検知すると、通信管理部は、再生装置が保有するデジタル証明書をバイトコードアプリケーションに送信し、デジタル証明書に付与された署名が正当であると判断した場合に、バイトコードアプリケーションは、通信管理部から通信鍵を受け取り、機器固有機能に関するコマンドを前記通信鍵を用いて暗号化して通信管理部へ送る、請求項2に記載の再生装置。記録媒体であって、コンテンツと、バイトコードアプリケーションとが記録されており、前記コンテンツに対する機能には、標準化された再生制御機能と、機器固有の機器固有機能とがあり、再生装置のプラットフォーム部は、バイトコードアプリケーションが利用可能なプログラミングインターフェイスを有し、前記バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含み、前記バイトコードアプリケーションは、再生制御用プログラミングインターフェイスをコールすることで、再生装置内の再生制御部に再生制御を命じ、通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、再生装置内の固有機能制御部に機器固有の制御を命じることを特徴とする記録媒体。前記記録媒体は第1記録媒体であり、第1記録媒体には、ルートディレクトリの配下に第1ディレクトリと、第2ディレクトリとが存在し、第1ディレクトリは、本編コンテンツが記録されているディレクトリであり、前記バイトコードアプリケーションは、第1ディレクトリに記録されており、第2ディレクトリは、持出し視聴用コンテンツが記録されており、持出し視聴用コンテンツは、本編コンテンツとは異なるフォーマットのコンテンツであって、機器固有機能の対象となるものであり、機器固有機能とは、持出し視聴用コンテンツを構成するディレクトリ及びファイルを、第1記録媒体から第2記録媒体へと、コピーするというメディア間コピーであることを特徴とする請求項9記載の記録媒体。第2ディレクトリの配下には、複数のコピーソース格納ディレクトリが存在し、前記持出し視聴用コンテンツは、何れか1つのコピーソース格納ディレクトリに記録されており、バイトコードアプリケーションは、何れかのコピーソース格納ディレクトリのファイルパスを、カレントのソースロケーションとして固有機能制御部に設定することを命じ、固有機能制御部は、何れか1つのコピーソース格納ディレクトリがカレントソースロケーションとして設定されれば、カレントコピーソース格納ディレクトリから持出し視聴用コンテンツを読み出して、第2記録媒体に書き込むことで、機器固有機能を実行することを特徴とする請求項10記載の記録媒体。前記第1記録媒体の第1ディレクトリには、機器固有機能のためのオンメディアライブラリが記録されており、オンメディアライブラリは、第1ディレクトリに記録された他のバイトコードアプリケーションに、機器固有機能実行のためのプログラミングインターフェイスを提供するものであり、前記オンメディアライブラリは、バイトコードアプリケーションから、機器固有機能実行用プログラミングインターフェイスのコールがなされた場合、当該プログラミングインターフェイスのコールをソケットコマンドに変換した上で固有機能制御部に出力し、固有機能制御部からのレスポンスを戻り値又はイベントに変換して、コールを行ったバイトコードアプリケーションに返し、前記ソケット接続は、前記ソケットコマンド及びレスポンスを伝送するための通信路を構成することを特徴とする請求項10記載の記録媒体。記録媒体に記録されたコンテンツを再生すると共に、当該コンテンツに対する機能を実行する再生方法であって、コンテンツに対する機能には、標準化された再生制御機能と、機器固有の機器固有機能とがあり、記録媒体からバイトコードアプリケーションを読み出して、コンピュータのプラットフォーム部に動作させる第1ステップと、バイトコードアプリケーションからの要求に従い、コンテンツに対する機能をコンピュータ内の固有機能制御部に実行させる第2ステップとを有し、前記コンピュータのプラットフォーム部において、バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含み、前記バイトコードアプリケーションは、再生制御用プログラミングインターフェイスをコールすることで、再生制御部に再生制御を命じ、通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、固有機能制御部に機器固有の制御を命じることを特徴とする再生方法。記録媒体に記録されたコンテンツを再生すると共に、当該コンテンツに対する機能を実行するコンピュータが読み取り可能なプログラムであって、コンテンツに対する機能には、標準化された再生制御機能と、機器固有の機器固有機能とがあり、記録媒体からバイトコードアプリケーションを読み出して、コンピュータのプラットフォーム部に動作させる第1ステップと、バイトコードアプリケーションからの要求に従い、コンテンツに対する機能をコンピュータ内の固有機能制御部に実行させる第2ステップとを有し、前記コンピュータのプラットフォーム部において、バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含み、前記バイトコードアプリケーションは、再生制御用プログラミングインターフェイスをコールすることで、再生制御部に再生制御を命じ、通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、固有機能制御部に機器固有の制御を命じるようにコンピュータを動作させることを特徴とするコンピュータが読み取り可能なプログラム。記録媒体に記録されたバイトコードアプリケーションおよびオンメディアライブラリを読み出して、動作させるプラットフォーム部と、前記記録媒体に記録されたコンテンツに対し、標準化された再生制御機能を実行する再生制御部と、前記記録媒体に記録されたコンテンツに対し、機器固有の機器固有機能を実行する固有機能制御部とを備え、プラットフォーム部は、バイトコードアプリケーションが利用可能なプログラミングインターフェイスを有し、前記バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含むコンピュータが読取り可能なプログラムであって、前記バイトコードアプリケーションが、再生制御用プログラミングインターフェイスをコールすると、再生制御部に再生制御を命じるステップ、バイトコードアプリケーションが、オンメディアライブラリをコールすると、オンメディアライブラリが通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、固有機能制御部に機器固有の制御を命じるステップをコンピュータに実行させるコンピュータが読取り可能なプログラム。バイトコードアプリケーションはオンメディアライブラリを含む請求項15に記載のコンピュータが読取り可能なプログラム。ところで、あるメーカーが、コンテンツを対象とした特殊な機能の開発に成功した場合、その機能を機器固有機能として実装するのがよいのか、標準化機能として実装するのがよいのかの選択に悩むことが多い。機器固有機能として実装する場合、装置設定のためのセットアップメニュー等の、装置固有のユーザインターフェイスを通じて、起動できるようにするのが一般的である。しかし、特殊機能を機器固有機能として実装しようとすると、特殊機能を起動するためのユーザインターフェイスは、メーカーが作成したものに制限されるので、コンテンツプロバイダが作成したユーザインターフェイスに比べて貧弱感が否めない。よって、特殊機能の使い方が判りにくいものになり、ユーザメリットが低い。これに対して特殊機能を標準化機能として実装する場合、そのような標準化機能を利用した多くのアプリケーションが様々なコンテンツプロバイダによって開発され、市場に投入されると予想される。特殊機能を起動するためのユーザインターフェイスが多種多様なものになり、ユーザは、より判りやすく親しみ易いユーザインターフェイスを通じて、特殊機能を利用することができる。しかし、特殊機能のためのAPIを策定して公開すると、後発メーカーは、何等、研究開発費を投じることなく、同様の機能を具備した製品を開発して市場に投入することができる。先行メーカーは、後発メーカーの激しい追いあげを受けることで、市場での販売シェア獲得競争に敗北してしまうばかりか、研究開発費を回収できず、苦境に立たされるという由々しき事態も考えられる。以上の二通りの実装の仕方のそれぞれには、ユーザに対する判りやすさが犠牲になるか、後発メーカーの台頭を許すかというデメリットが存在し、最適解が見出せない。本発明の目的は、特殊機能を機器固有機能として再生装置に実装しつつも、当該機器固有機能を利用したアプリケーションを、様々なコンテンツプロバイダに開発させることができる再生装置を提供することである。上記目的を達成することができる再生装置は、記録媒体に記録されたコンテンツを再生すると共に、当該コンテンツに対する機能を実行する再生装置であって、前記コンテンツに対する機能には、標準化された再生制御機能と、機器固有の機器固有機能とがあり、記録媒体からバイトコードアプリケーションを読み出して、動作させるプラットフォーム部と、再生制御機能を実行する再生制御部と、機器固有機能を実行する固有機能制御部とを備え、前記再生装置のプラットフォーム部は、バイトコードアプリケーションが利用可能なプログラミングインターフェイスを有し、前記バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含み、前記バイトコードアプリケーションは、再生制御用プログラミングインターフェイスをコールすることで、再生制御部に再生制御を命じ、通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、固有機能制御部に機器固有の制御を命じることを特徴とする。ソケット接続のためのプログラミングインターフェイスは、ネイティブAPIとしてサポートされている機能であるから、機器固有機能制御部に対してソケット接続を行うことで、機器固有機能の実行を機器固有機能制御部に要求すれば、既に標準化されているデジタルストリーム再生制御のためのAPIに対して、追加/改変を加えることなく、アプリケーションに機器固有機能を使用させることができる。既存の再生制御のためのAPIに追加/改変を加えることなく、機器固有機能を使用させるので、特殊機能を利用したアプリケーションが様々なコンテンツプロバイダが開発され、市場に投入されると予想される。その結果、特殊機能を起動するためのユーザインターフェイスが多種多様なものになり、ユーザは、より判りやすく親しみ易いユーザインターフェイスを通じて、特殊機能を利用することができる。機器固有機能として実装する限り、後発メーカーの追従を避けることができるから、特殊機能を機器固有機能として実装した製品により、市場を寡占することができる。先行メーカーが、コンテンツプロバイダに特殊機能を利用させ、その独自開発に成功したメーカーのみが、ライセンスを、コンテンツプロバイダから得るというもの新たな収益スタイルの確立が容易になり、メーカーによる研究開発に弾みを付けることができる。以上が、解決しようとする課題欄で述べた技術的課題の解決を図る技術的思想の創作である。つまり任意的ではあるが、上記再生装置は、以下のような追加的な技術的課題の解決を図るものであってもよい。特殊機能を標準化機能として実装するにあたって、既に標準化されているAPIの拡張は難しいため、コンテンツ提供者が先行してオリジナリティのある新しいサービスを提供したい場合、再生装置上での独自サービス提供はあきらめる傾向が強い。代替策として、パソコンにインストールして実行するアプリケーションを映画本編とは別のディスクに記録しておき、ユーザにそのディスクをパソコンで実行してもらうことで、独自サービスを提供するという方法が主流になっている。実際に行われているサービス例としては、携帯端末向けデジタルストリームとパソコン用アプリケーションを本編ディスクとは別ディスクの中に記録しておき、そのディスクをパソコン上で実行し、ディスクに記録されている携帯端末向けデジタルストリームをパソコンに接続中の携帯端末にコピーすることで、携帯端末上での映画持ち出し視聴を可能にするサービス通称デジタルコピーが普及している。だが、上記のようなサービス提供方法では、1コンテンツ提供者はパソコン上での実行用ディスクを本編とは別に用意しなければならない、2映画視聴にパソコンを利用していないユーザでも、サービス実行のためには、わざわざパソコンを利用しなければならない、3サービス提供がパソコンを介して行われることになるため、機器メーカーは、再生装置の機能アピールができない、など課題が多くあり、コンテンツ提供者、ユーザ、機器メーカーのそれぞれにデメリットがあった。本発明の他の目的は、リードオンリーメディア上のアプリケーションプログラムと再生装置の独自機能を連携させたサービスを、他の再生装置との互換性を維持しつつ、かつパソコン等の第三の機器を介することなく提供することである。かかる目的を達成するための再生装置は以下のものである。即ち、前記記録媒体は第1記録媒体であり、第1記録媒体には、ルートディレクトリの配下に第1ディレクトリと、第2ディレクトリとが存在し、第1ディレクトリは、本編コンテンツが記録されているディレクトリであり、前記バイトコードアプリケーションは、第1ディレクトリに記録されており、第2ディレクトリは、持出し視聴用コンテンツが記録されており、当該持出し視聴用コンテンツは、本編コンテンツとは異なるフォーマットのコンテンツであって、機器固有機能の対象となるものであり、前記機器固有機能とは、持出し視聴用コンテンツを構成するファイルを、第1記録媒体から第2記録媒体へと、コピーするというメディア間コピーであることを特徴とする。第1ディレクトリに記録された映画本編と、第2ディレクトリに記録された携帯端末向け保護コンテンツを1枚のディスクにまとめることができ、かつディスク上のアプリケーションから、携帯端末向け保護コンテンツの転送を制御できるので、パソコン不要であり再生装置だけで持ち出し視聴サービスを実現することができる。更に、任意的ではあるが、上記再生装置は、以下のような追加的な技術的課題の解決を図るものであってもよい。追加的技術的課題その2新規に開発した特殊機能を標準出力関数として実装するために、プレーヤモデルの標準出力関数に新たなAPIを追加するとなると、追加されたAPIを保持していない再生装置では、追加APIを利用するアプリケーションを正常に起動させることができなくなるという下位互換の問題が当然に発生する。具体的には、アプリケーションを起動する段階において、再生装置はアプリケーションが利用するAPIと再生装置が実装しているAPIのリンク処理が行われるが、再生装置が保持していないAPIをアプリケーションが利用していた場合、リンクエラーとなり、アプリケーションの起動自体に失敗するという問題がある。上記問題に対する一つの回避策は、既存APIのみを使うアプリケーションと、追加APIを使うアプリケーションを分けて用意しておき、再生装置のバージョン等を確認して、起動するアプリケーションを変えるという方法である。しかしながら、今後多種多様の機能が追加され、それら機能毎に各再生装置がAPIを拡張していくとなると、どの範囲までのAPIが安全に使え、どの範囲から別アプリケーションにすべきか管理が煩雑になり、異なるメーカ間の再生装置におけるアプリケーション互換性確保が極めて難しくなる。そのため、新機能を追加する際は、標準化団体等で互換性問題が起こらぬよう慎重にAPIを定義し、追加したAPIを機器メーカ、アプリケーション開発者に公開することで、どの範囲までのAPIが安全に使え、どの範囲から別アプリケーションにすべきかを明確にし、新しい機能が追加された機器を過去機種で再生させた場合でも、問題なく再生できるよう配慮がなされている。しかしながら、新機能追加の際、常にこのようなプロセスが必要となると、追加APIの定義には慎重にならざるを得ないために、確定するまでに時間がかかり、再生装置とアプリケーションがもたらすサービス進化が滞るという問題が起こる。本発明の別の目的は、APIの標準化を図ることなく、バイトコードアプリケーションの安定的な起動を実現することができる、再生装置を提供することである。上記目的を達成するための再生装置は、以下のもの図である。即ち、前記第1記録媒体の第1ディレクトリには、機器固有機能のためのオンメディアライブラリが記録されており、オンメディアライブラリは、第1ディレクトリに記録された他のバイトコードアプリケーションに、機器固有機能実行のためのプログラミングインターフェイスを提供するものであり、前記オンメディアライブラリは、他のバイトコードアプリケーションから、機器固有機能実行用プログラミングインターフェイスのコールがなされた場合、当該プログラミングインターフェイスのコールをソケットコマンドに変換した上で固有機能制御部に出力し、固有機能制御部からのレスポンスを戻り値又はイベントに変換して、コールを行った他のバイトコードアプリケーションに返し、前記ソケット接続は、前記ソケットコマンド及びレスポンスを伝送するための通信路を構成することを特徴とする。第1記録媒体に記録されたオンメディアライブラリは、機器固有機能の利用に際して、ソケット接続のためのAPIを利用するので、アプリケーションを起動する段階には、第1記録媒体に記録されたオンメディアライブラリが利用するAPIと、ソケット通信のための再生装置内のネイティブAPIとのリンクが成功する確率が高く、アプリケーションの起動自体に失敗することはない。また、ソケット通信のためのプログラミングインターフェイスを利用する限り、既存APIのみを使うアプリケーションと、追加APIを使うアプリケーションとを分けて用意することも不要であり、異なるメーカ間の再生装置におけるアプリケーション互換性確保が難航することはない。新機能追加の際、追加API定義のための慎重な配慮は不要となるので、再生装置とアプリケーションがもたらすサービス進化が滞ることはない。アプリケーションと再生装置間で行われる機器固有機能に関する通信データのプロトコル解析をライブラリで一元管理することが可能となり、アプリケーション本体でプロトコル解析を行う必要がなくなるため、アプリケーションの生産性を向上させることができる。任意的であるが、前記再生装置はさらに、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルの正当性を検証する検証部を備え、前記検証部は、再生装置内に組み込まれた認証鍵を元に、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルのハッシュ値を算出し、前記算出されたハッシュ値が、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルに含まれるデジタル署名の値と一致していれば、バイトコードアプリケーションは、正当であると判断し、前記検証部がデジタル署名ファイルが正当でないと判断した場合、前記固有機能制御部はバイトコードアプリケーションから前記再生制御とは異なる機器固有の機能に関連したコマンドを受け取っても、前記再生制御とは異なる機器固有機能の実行を拒否してもよい。アプリケーションと再生装置間の通信データの内容を暗号化することができるため、通信データの内容を不正にモニタリングし、得られた再生装置の固有機能に関する情報を悪用するという行為を防ぐことができる。以下本発明の実施の形態について、図面を参照しながら説明する。上記課題解決手段を具備した再生装置の発明は、パッケージ媒体を再生するためのプレーヤ機器として実施することができ、集積回路の発明は、当該プレーヤ機器に組込まれるシステムLSIとして実施することができる。再生方法の発明は、このプレーヤ機器で実現される時系列手順として実施することができる。プログラムの発明は、コンピュータ読み取り可能な記録媒体に記録され、プレーヤ機器にインストールされる実行形式プログラムとして実施することができる。第1実施形態第1実施形態は、機器固有機能を実現するための再生装置内外の通信についての改良に関する。先ず始めに、本発明に係る再生装置の実施行為のうち、使用行為についての形態を説明する。図1は、本発明に係る再生装置の、使用行為についての形態の一例を示す図である。図1において、本発明に係る再生装置は、再生装置101である。この再生装置101は、リモコン102、テレビ103、セキュアなメモリカード104、リードオンリーメディア105、携帯端末106、セキュアなメモリカード107と共に、ホームシアターシステムを形成する。再生装置101はSDメモリーカード、メモリースティック、コンパクトフラッシュ登録商標、スマートメディア、マルチメディアカード等のリムーバブルメディア104を挿入するための挿入口を備える。加えて携帯端末106と接続するためのUSB等の挿入口も備える。リモコン102は、再生装置102の付属物であり、再生装置102に対する操作をユーザから受け付けて、操作に応じた指示信号を再生装置102に送信する。再生装置に対する操作としては、リードオンリーメディアの再生制御を再生装置に実行させるための操作、機器固有機能を再生装置に行わせるための操作がある。また再生装置101は、ネットワーク通信機能を有し、外部サーバとの通信を行うことができる。テレビ103は、映画作品の再生映像を表示したり、メニュー等を表示することで、対話的な操作環境をユーザに提供する。セキュアなメモリカード104は、再生装置で機器固有機能を実行するにあたって、機器固有機能によりコピーされた携帯端末向け保護コンテンツの受け皿として用いられる記録媒体であり、例えば、microSDカード、SDHCカードが該当する。このセキュアなメモリカード104には、保護領域、システム領域が存在しており、保護領域には暗号化された復号鍵が存在する。システム領域には、復号鍵を復号するためのメディアID、メディアキーブロックが存在する。リードオンリーメディア105は、ホームシアターシステムに、映画作品を供給するための記録媒体である。携帯端末106は、セキュアなメモリカード104の装填が可能であり、セキュアなメモリカード104に書き込まれた携帯端末向け保護コンテンツを利用することができる。この場合、セキュアなメモリカード104の保護領域に書き込まれた暗号化復号鍵をコピー先のメディアのシステム領域に記録されたMKBを用いて復号し、復号鍵に含まれるキー情報タイトルキーを取り出し、取り出したキー情報を用いて、携帯端末向け保護コンテンツに含まる暗号化されたデジタルストリームを必要に応じて復号して利用する。ここでの利用とは、持出し視聴用コンテンツに復号して再生することをいう。以上が、ホームシアターシステムについての説明である。続いて記録媒体の詳細について説明する。図2aは、第1実施形態に係る記録媒体における内部構成を示す。本図aに示すように、第1実施形態に係る記録媒体には、本編コンテンツ、携帯端末向け保護コンテンツが記録されている。本編コンテンツは、リードオンリーメディア105の記録方式や保護方式で格納されたコンテンツであり、ストリームファイル201、ストリーム情報ファイル202、プレイリスト情報ファイル203、インデックステーブル204、アーカイブファイル205、動作モードオブジェクト206から構成されている。ストリームファイル201は、ビデオストリーム、1つ以上のオーディオストリーム、グラフィクスストリームを多重化することで得られたトランスポートストリーム形式のデジタルストリームを格納している。ストリーム情報ファイル202は、ストリームファイルにおけるトランスポートストリーム内の任意のソースパケットに対するランダムアクセスや、他のトランスポートストリームとの途切れ無き再生を保障する。このストリーム情報ファイルを通じることにより、ストリームファイルはAVクリップとして管理されることになる。ストリーム情報ファイルは、AVクリップにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、GOPの先頭位置のソースパケット番号を、フレーム期間のプレゼンテーションタイムスタンプと対応付けて示すエントリーマップをもっているので、ストリームファイルのアクセスに先立ち、このストリーム情報ファイルをメモリにロードしておけば、アクセスしようとするストリームファイル中のトランスポートストリームがどのようなものであるのかを把握することができるので、ランダムアクセスの実行を保障することができる。プレイリスト情報ファイル203は、再生装置にプレイリストを再生させるための情報を格納したファイルである。プレイリストとは、トランスポートストリームの時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、TSのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもつ。プレイリスト情報は、かかるプレイリストの型を定義する。プレイリスト情報によって定義される再生経路は、いわゆるマルチパスである。マルチパスとは、主となるTSに対して定義された再生経路と、従となるTSに対して定義された再生経路とを束ねたものである。インデックステーブル204は、再生装置におけるタイトル番号レジスタに格納され得る複数のタイトル番号と、動作モードを規定する動作モードオブジェクトとの対応付けを規定する。記録媒体に記録されているタイトルとは、タイトル番号によって特定される動作モードオブジェクトと、この動作モードオブジェクトから再生されるプレイリストとの組みをいう。ここで、タイトル番号レジスタにおけるタイトル番号は、0、1~999、不定値という番号がある。タイトル番号0は、トップメニュータイトルのタイトル番号である。トップメニュータイトルとは、ユーザによるメニューコール操作によって呼び出すことができるタイトルである。不定値のタイトル番号は、ファーストプレイタイトルのタイトル番号である。ファーストプレイタイトルとは、記録媒体の装填直後に、視聴者への警告やコンテンツプロバイダによるロゴ表示等を行うタイトルである。インデックステーブル204は、各タイトル番号のそれぞれに対応したエントリーを有し、個々のタイトルインデックスに、動作モードを規定する動作モードオブジェクトを記述することで、各々のタイトルが、どのような動作モードで動作するのかを詳細に規定する。アーカイブファイル205は、バイトコードアプリケーションのクラス構造体のファイルを、デジタル証明書マニフェストファイル、ディスク署名シグネチャファイル、ディスク署名暗号鍵ファイル、パーミッションリクエストファイルとひとまとめにしてアーカイブしたファイルである。アプリケーションのロードは、このアーカイブファイルをひとまとめにしてなされ、クラスロード時に、デジタル証明書、ディスク署名、ディスク署名暗号鍵を用いたアプリケーションの正当性の検証ができるようになっている。またパーミッションリクエストファイルが存在するので、アプリケーションによる動作を、一定の権限が与えられたのものに限定することができる。動作モードオブジェクト206は、インデックステーブルにおいて何れかのタイトル番に対応付けられている制御単位であり、対応するタイトル番号がカレントタイトルとしてタイトル番号レジスタに設定された際、そのタイトル番号に対応するタイトルをどのように動作させるかを示す。図2bは、動作モードオブジェクトの内部構成を示す。本図に示すように、動作モードオブジェクトは、アプリケーション管理テーブル、端末管理テーブル、アプリケーションキャッシュ情報、プレイリストアクセス情報、キー割当テーブルから構成される。アプリケーション管理テーブルは、タイトルをバウンダリィとしたクラスロードやアプリケーションシグナリングをアプリケーションマネージャやクラスローダに指示する制御テーブルであり、端末管理テーブルは、GUIを実現するためのHAViデバイスコンフィグレーションやGUIに用いるフォント、ユーザ操作のマスクの有無をマルチディアホームプラットフォームに指示する管理テーブルである。アプリケーションキャッシュ情報は、タイトル選択時のアーカイブファイルのキャッシュイン/キャッシュアウトをキャッシュマネージャに指示する制御テーブルであり、プレイリストアクセス情報タイトル選択時におけるプレイリストアクセスの指定を再生制御部に指示する制御テーブルである。キー割当テーブルは、キーと、イベントとの対応付けをイベントマネージャに指示する制御テーブルである。クラスロードとは、アーカイブファイルにアーカイブされているクラスファイルのインスタンスを、プラットフォームのヒープ領域に生成する処理であり、ヒープ領域に生成したインスタンスが存在する間は、ヒープ領域に生成したインスタンスであるアプリケーションが実行可能となる。アプリケーションシグナリングは、クラスファイルのインスタンスであるアプリケーションを自動起動させるか否か、又は、アプリケーションが実行可能となる生存区間をタイトルバウンダリーとするかディスクバウンダリーとするかを規定する制御である。タイトルバウンダリーとは、タイトルの開始からタイトルの終了までのある時点において、アーカイブファイルにアーカイブされているクラスファイルのインスタンスを、プラットフォームのヒープ領域に生成し、タイトルの終了と同時にアプリケーションであるインスタンスをヒープ領域から消滅させるという管理である。ディスクバウンダリーとは、ディスクを挿入してからディスクをイジェクトするまでのある時点において、アーカイブファイルにアーカイブされているクラスファイルのインスタンスを、プラットフォームのヒープ領域に生成し、ディスクイジェクトと同時にアプリケーションであるインスタンスをヒープ領域から消滅させる管理である。逆にディスクイジェクトがされてもインスタンスをヒープ領域から削除しない制御をディスクアンバウンダリーという。HAViデバイスコンフィグレーションは、アプリケーションがGUI処理を実行するにあたってのグラフィクスプレーンの解像度や文字表示に用いるフォント等を規定するものである。プレイリストアクセスとは、起動されたアプリケーションが再生を命じることができるプレイリストやタイトル選択時に自動的に再生すべきプレイリストの指定である。アーカイブファイルのキャッシュインとは、クラスロードの対象となるアーカイブファイルをキャッシュに先読みするとの処理であり、アーカイブファイルのキャッシュアウトとは、キャッシュに存在するアーカイブファイルをキャッシュから削除するとの処理である。キーと、イベントとの対応付けは、ユーザが操作可能なキーに、アプリケーションのイベントリスナに登録されているイベントを割り当てるというものである。動作モードオブジェクトには、他にもナビゲーションコマンドを用いて再生装置を動作させるための動作モードオブジェクトが存在する。以上が本編コンテンツについての説明である。続いて、携帯端末向け保護コンテンツの詳細について説明する。携帯端末向け保護コンテンツは、本編コンテンツと同一性を有しつつも、格納方式および保護方式のフォーマットが本編コンテンツの格納方式および保護方式のフォーマットとは異なる持出視聴用コンテンツであり、ストリームファイル207、プログラム情報ファイル208、管理情報ファイル209、コピー情報格納ファイル210から構成される。これらストリームファイル207、プログラム情報ファイル208、管理情報ファイル209は、本編コンテンツを構成するストリームファイル201、ストリーム情報ファイル202、プレイリスト情報ファイル203に対応する管理情報である。しかし、コピー情報格納ファイル210は、携帯端末向け保護コンテンツ特有のものである。コピー情報格納ファイル210は、コピー情報を格納しているファイルであり、そのコピー情報の1つとして、コンテンツIDが存在する。コンテンツIDは、携帯端末向け保護コンテンツのそれぞれを識別するためコンテンツプロバイダが供給するコンテンツに対して割り当てた128bitの識別子である。携帯端末向け保護コンテンツのうち、機器固有機能の対象になっているもののコンテンツIDは、サーバのデータベースにおいて管理されている。コンテンツIDは、携帯端末向けコンテンツをそれぞれ一意に識別するために割り当てられている。この識別子のうち、上位の所定ビットは、コンテンツプロバイダを識別するためのものである。以上が、本発明に係る記録媒体についての説明である。続いて本発明に係る再生装置の内部構成について説明する。図3は、再生装置の内部構成を示す。本図に示すように、再生装置は、ドライブデバイス1、デマルチプレクサ2、ビデオデコーダ3、プレーンセット4、ビデオプレーン4a、グラフィクスプレーン4b、レンダリングエンジン5、合成部6、オーディオデコーダ7、機器インターフェイス8、ホストマイコン9、再生制御部10、ユーザインターフェイス11、レジスタセット12から構成される。ドライブデバイス1には、リードオンリーメディア105のドライブ、セキュアなメモリカード104のドライブがある。リードオンリーメディア105のドライブは、リードオンリーメディア105を装填して、当該記録媒体に記録されたデジタルストリームを構成するソースパケット系列を、バッファを介して読み出す。セキュアなメモリカード104のドライブは、セキュアなメモリカード104やその他の記録媒体を装填して、アクセスする。USBケーブル等を介して、再生装置に接続されている携帯端末106にセキュアなメモリカード104が装填されている場合、この携帯端末106のドライブにもスロット番号が割り当てられ、ドライブとして管理されることになる。これらのセキュアなメモリカード104のドライブは、スロットという単位で管理される。複数のスロット番号のそれぞれに対応付ける形式で、ドライブに装填されたリードオンリーメディア105、セキュアなメモリカード104の状態を示すデバイスリストを、デバイスデバイスリストという。デマルチプレクサ2は、リードオンリーメディア105から読み出されたソースパケット系列に対して多重分離を行い、PESパケットを得て、該当するデコーダに出力する。ビデオデコーダ3は、読み出されたビデオストリームを復号して非圧縮形式のピクチャをプレーンセット4に書き込む。プレーンセット4は、複数のプレーンメモリから構成される。プレーンメモリとは、一画面分の画素データをライン単位で格納しておき、水平同期信号、垂直同期信号に沿ってこれらの画素データを出力するためのメモリである。個々のプレーンメモリは、ビデオ、字幕、GUI、背景画像のデコードによって得られた1画面分の画素データを格納する。これらのプレーンメモリは、レイヤモデルを構成しており、個々のプレーンメモリの格納内容は、レイヤ合成に供される。このレイヤ合成は、プレーンメモリのレイヤモデルにおいて、2つの階層のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける2つの階層の全ての組合せに対して実行することでなされる。ビデオプレーン4aは、プレーンセットの1つであり、1920×1080の解像度をもつ非圧縮のピクチャデータを格納する。グラフィクスプレーン4bは、プレーンセットのうちの1つであり、ビデオプレーンの上の重畳させるべきグラフィクスを非圧縮形式で格納する。ここでのグラフィクスとは、これらグラフィクスプレーンに格納されたARGB形式の画素データによって表現される表示内容のことであり、フォントを用いてテキストコードを展開することにより得られた文字、記号のビットマップや、GIFJPEGPNGデータをデコードすることで得られるGIFJPEGPNGイメージを含む。レンダリングエンジン5は、Java2D,OPENGLといった基盤ソフトウェアを備え、バイトコードアプリケーションから要求に従ってJPEGデータ/PNGデータのデコードを行い、イメージやウィジェットを得て、グラフィクスプレーンに書き込む。JPEGデータをデコードすることにより得られる画像データは、GUIの壁紙になるものである。PNGデータをデコードすることにより得られる画素データは、グラフィクスプレーンに書き込まれて、アニメーションを伴うボタン表示を実現することができる。これらJPEGデータ/PNGデータをデコードすることで得られたイメージやウィジェットは、バイトコードアプリケーションが、タイトル選択や字幕選択、音声選択を受け付けるためのメニューを表示したり、ストリーム再生連動型のゲームを動作させるにあたって、GUI部品を構成するために使われる。その他、バイトコードアプリケーションがWWWサイトをアクセスする際、そのWWWサイトのブラウザ画面を構成するために用いられる。合成部6は、複数のプレーンメモリのレイヤ合成を行う。オーディオデコーダ7は、多重分離で得られたPESパケットのうち、オーディオストリームを構成するものをデコードする。機器インターフェイス部8は、ホームシアターシステムにおける他の機器とインターフェイスを介して接続された際、相互認証フェーズと、ネゴシエーションフェーズを経てータ伝送フェーズに移行し、データ伝送を行う。このネゴシエーションフェーズは、相手側機器のケーパビリティを把握して、プレーヤ設定レジスタに設定しておき、以降の伝送のための伝送方式を定めるものである。これらの相互認証フェーズ、ネゴシエーションフェーズを経て、レイヤ合成がなされたピクチャデータにおける一ライン分の非圧縮平文形式の画素データを、表示装置における水平同期期間に従い表示装置に高い転送レートで転送する。一方、表示装置における水平帰線期間、及び、垂直帰線期間において、再生装置と接続された他の装置に、非圧縮平文形式のオーディオデータを転送する。こうすることで、表示装置、アンプ、スピーカといった機器は、非圧縮平文形式のピクチャデータ、非圧縮平文形式のオーディオデータを受け取ることができ、再生出力を実現することができる。また、相手側機器にデコード能力が存在する場合、ビデオストリーム、オーディオストリームのパススルー伝送が可能になる。パススルー伝送では、ビデオストリーム、オーディオストリームを圧縮暗号化形式のまま伝送することができる。ホストマイコン9は、MPUROMRAMから構成され、アーカイブファイルをロードすることで得られるバイトコードアプリケーションを間隔し、実行する。再生制御部10は、ドライブデバイス1を制御して、インデックステーブル、動作モードオブジェクト、プレイリスト情報ファイル、ストリーム情報ファイル、ストリームファイルをリードオンリーメディア105から読み出すとともに、記録媒体から読み出されたプレイリスト情報、ストリーム情報に基づく再生制御を実行する。ストリームファイルの読み出しにあたっては、時間軸の任意の時点に相当するソースパケットを、ストリームファイルから読み出すというランダムアクセスを実現することができる。ユーザインターフェイス11は、操作装置102に対する操作を受け付ける。レジスタセット12は、複数のプレーヤ状態レジスタ、複数のプレーヤ設定レジスタから構成される。プレーヤ状態レジスタは、再生装置のMPUが算術演算やビット演算を行う際、その被演算子となる数値を格納しておくためのハードウェア資源であり、光ディスクが装填された際に初期値が設定され、またカレントタイトル番号やカレントプレイリスト番号の変更等、再生装置の状態が変化した際に、その格納値の有効性が判定されるレジスタである。この格納値としては、カレントタイトル番号、プレイリスト番号、カレントの再生時点等がある。リードオンリーメディア105の装填時に初期値が格納されるので、この格納値は一時的なものでありリードオンリーメディア105がイジェクトされたり、また再生装置の電源が断たれれば、この格納値は有効性を失う。プレーヤ設定レジスタは、電源対策が施されている点がプレーヤ状態レジスタとは異なる。電源対策が施されているので、再生装置の電源遮断時において、その格納値が不揮発性のメモリに退避され、再生装置の電源投入時において、その格納値が復帰される。再生装置の製造主体が再生装置の出荷時に定めた再生装置の各種コンフィグレーションや、ユーザがセットアップ手順に従い設定した各種コンフィグレーション、そして、再生装置がTVシステムやステレオ、アンプ等のホームシアターシステムの機器と接続された際、接続相手となる機器とのネゴシエーションにより判明した相手側機器のケーパビリティがプレーヤ設定レジスタに設定される。以上が再生装置の内部構成についての説明である。続いて、再生装置におけるソフトウェアのレイヤ構成の詳細について説明する。図4は、再生装置におけるソフトウェアレイヤ構成を示す。基本的なレイヤ構成は、ファイルシステム13、リアルタイムOS14が存在し、この上に、コマンド処理モジュール15及びバイトコード処理モジュール16が同じレイヤに併存していて、コマンド処理モジュール15及びバイトコード処理モジュール16の共通の上位レイヤに、モジュールマネージャ17が存在するというものである。ファイルシステム13は、ディレクトリファイルといった単位で、リードオンリーメディア105やセキュアなメモリカード104のアクセスを行わせる。リアルタイムOS14は、組込みソフトウェアのためのオペレーティングシステムであり、当該オペレーティングシステムのカーネル、基本入出力部から構成される。コマンド処理モジュール15は、コマンドインタプリタを含み、ナビゲーションコマンドを解読して実行し、この実行結果に応じて、再生すべきプレイリストを選択するものである。ナビゲーションコマンドは、DVDVideoと似たようなシンタックスで記述されているため、かかるナビゲーションコマンドを実行することにより、再生装置は、DVDVideoライクな再生制御を実現することができる。例えば、BDROMの再生装置である場合、バイトコード処理モジュール16は、HDMVモジュールに該当する。バイトコード処理モジュール16は、リードオンリーメディア105105に記録されたアーカイブファイル内のクラス構造体のインスタンスを動作させるプラットフォーム部20である。例えば、BDROMの再生装置である場合、バイトコード処理モジュール16は、BDJモジュールに該当する。モジュールマネージャ17は、リードオンリーメディア105から読み出されたインデックステーブルを保持して、モード管理及び分岐制御を行う。モジュールマネージャ17によるモード管理とは、動的シナリオをどのコマンド処理モジュール15、バイトコード処理モジュール16の何れかに実行させるかという、モジュールの割り当てである。以上のレイヤ構成において、リアルタイムOS14と、バイトコード処理モジュール16とは、バイトコードアプリケーションのプラットフォーム部20を構成する。このプラットフォーム部20は、バイトコードアプリケーションが利用可能なプログラミングインターフェイスを有する。バイトコードアプリケーションが利用可能なプログラミングインターフェイスには、プレイリスト情報を用いたデジタルストリームの再生制御のために標準化されている再生制御用プログラミングインターフェイスと、通信のために標準化されている通信用プログラミングインターフェイスがある。次に、バイトコード処理モジュール16の内部構成について説明する。バイトコード処理モジュール16は、クラスローダ21、アプリケーションマネージャ22、ヒープメモリ23、バイトコードインタプリタ24、組込ライブラリ25、再生制御API26から構成される。クラスローダ21は、システムアプリケーションの1つであり、アーカイブファイルに存在するクラスファイルからバイトコードを読み出して、ヒープメモリ31に格納することにより、バイトコードアプリケーションのロードを行う。アプリケーションマネージャ22は、システムアプリケーションの1つであり、動作モードオブジェクト内のアプリケーション管理テーブルに基づき、バイトコードアプリケーションを起動したりバイトコードアプリケーションを終了したりする等、バイトコードアプリケーションのアプリケーションシグナリングを行う。ヒープメモリ23は、システムアプリケーションや組込みライブラリのバイトコード、アプリケーションシグナリングの対象となる一般的なアプリケーションのバイトコード、これらのバイトコードアプリケーションが利用するパラメータが配置されるスタック領域である。バイトコードインタプリタ24は、ヒープメモリ31に格納されているバイトコードをネィティブコードに変換して、MPUに実行させる。組込みライブラリ25は、バイトコードアプリケーションのためのAV再生機能、ネットワーク通信機能、媒体アクセス機能を提供する。これらのAV再生機能、ネットワーク通信機能、媒体アクセス機能は、標準化団体によって標準化されたものである。再生制御API26は、標準化されている再生制御用プログラミングインターフェイスであり、組込ライブラリ25を介した再生制御機能を、バイトコードアプリケーションに提供するためのプログラミングインターフェイスである。以上がバイトコード処理モジュール16についての説明である。続いて、リアルタイムOS14及びファイルシステム13の内部構成について説明する。リアルタイムOS14はネイティブAPI27を含み、ファイルシステム13は、読出制御部31、書込制御部32、機器固有機能制御部33を含む。ネィティブAPI27は、リアルタイムOS14の基本的機能を、バイトコードアプリケーションに提供するためのプログラミングインターフェイスであり、OSI参照モデルにおける通信用プログラミングインターフェイスである。リアルタイムOS14の基本的機能を利用させるためのAPIは、システム関数とも呼ばれる。かかるネィティブAPI27は通信用の基本的なAPIを含み、TCPIP及びUDPIPをサポートすることができる。読出制御部31は、本編コンテンツを構成するファイル、携帯端末向け保護コンテンツを構成するファイルを、リードオンリーメディア105から読み出して、バイトコード処理モジュール16に供給するようなファイル読み出しを制御する。書込制御部32は、携帯端末向け保護コンテンツを構成するファイルを、読出制御部31から受け取ってセキュアなメモリカード104に書き込むようなファイル書き込みを制御する。機器固有機能制御部33は、機器固有の機能を実現する。本明細書における機器固有機能とは、再生装置を開発したメーカーによって製造されたプレーヤ機器のみ実行が可能であり、他のメーカーによって製造されたプレーヤ機器では実行することができない機能をいう。機器固有機能としては様々なものがある。例えば、ゲーム機器としての機能を具備している再生装置であるなら、そのゲーム機器固有の操作装置に特化した機能が機器固有機能として挙げられる。人が把持して振り回すことで、ユーザによる操作を検出したり、人の動きを検出してユーザによる操作を検出するような操作装置であるなら、その操作装置に特化して、当該ゲーム機器固有となる機能が、機器固有機能となる。他、そのゲーム機器固有のオンライン機能を機器固有機能とすることもできる。これら様々な種類の機器固有機能を、対象にしようとすると説明が煩雑になる。よって、以降の説明では、特許文献1に記載されたようなコピー機能、つまり、図2に記載された持出し視聴用コンテンツを対象としたコピー機能が、機器固有機能であるとして説明を進める。機器固有機能は、バイトコードアプリケーションによる利用が制限されている。よって、様々なコンテンツプロバイダのうち、機器固有機能の利用が許可されているものの作成に係るバイトコードアプリケーションのみが、機器固有機能を利用することができる。機器固有機能の利用が許可されていないコンテンツプロバイダの作成に係るバイトコードアプリケーションは、機器固有機能を利用することはできない。コンテンツプロバイダの利用権限をチェックするにあたって、機器固有機能制御部は、コンテンツIDと、シリアル番号との組みを外部サーバに送信して、本編コンテンツの供給源であるコンテンツプロバイダが、機器固有機能の正当なライセンシーがどうかをサーバに判断させる。正当なライセンシーであるとサーバが判断した場合は、機器固有機能を実行するが、正当なライセンシーではないと判断した場合、機器固有機能を実行しない。以上のレイヤ構成で、機器固有機能を用いた処理を実現するバイトコードアプリケーションについて説明する。本実施形態のバイトコードアプリケーションは、ソケットプロトコルによる端末内ローカル通信を通じて、機器固有機能制御部33とのコマンドレスポンス型の通信を行う点に特徴がある。ソケットとは、予め定められたポート番号の何れかと、ローカルホストのIPアドレスとをバインドしたものであり、オンメディアライブラリはソケット通信を通じて、機器固有機能制御部に対するコマンドの送信と、機器固有機能制御部からのレスポンスの受信とを行う。ソケットプロトコルは、リクエストを受け付けるというソケット作成行程、サーバーのアドレス情報であるIPアドレス及びポート番号をソケットに結び付けるというバインド行程、リクエストの接続待ちキューを設定して接続要求を準備するというリスニング行程、接続待ちのリクエストを受付けてソケット接続を確立し、新しいソケット接続を作成するというアクセプト行程という4つの過程を経て、このソケット接続を介してコマンド、レスポンスの送受信の行程を行う。これらの行程において、ソケット作成行程、バインド行程、リスニング行程、アクセプト行程、送受信行程は、Socket関数bind関数listen関数accept関数send関数recv関数closesocket関数といったシステム関数を用いてなされる。また、ソケットへのIPアドレス及びポート番号の結び付けは、SOCKADDRIN構造体でなされる。これらの関数や構造体は、リアルタイムOS14のネイティブAPI27によって提供されるものである。端末内ローカル通信を用いたソケットプロトコルは、使用されるポートが特殊であることを除けば、リアルタイムOS14のネイティブAPIによって提供されるものであるだから、バイトコードアプリケーションは、バイトコード処理モジュール16内の組込ライブラリ25によるまでもなく、リアルタイムOS14のネイティブAPI27を利用しさえすれば、機器固有機能を利用することができる。端末内ローカル通信のためのIPアドレスとしては、ローカルホストのIPアドレスを用いる。ローカルホストとは、現在使用しているシステムを指し、TCPIPが必要に応じて自身と通信するために使用される。例えば、IPv4におけるローカルホストのIPアドレスは127001に、例えば、IPv6におけるローカルホストのIPアドレスは、1に割り当てられたループバックデバイスとなる。ソケットプロトコルはコピーヤーズソケットポートと呼ばれるポートを占有する。そのため、デジタルコピープロセスのためのポート番号は、独立して実装される。プロセスに使用されるポート番号を通知するために、バイトコードアプリケーションは、プロセス処理に使用されるポート番号をセットにする必要がある。機器固有機能を用いた処理を実現するバイトコードアプリケーションには、機器固有機能を利用するためのプログラミングインターフェイスを他のバイトコードアプリケーションに提供するオンメディアライブラリ、機器固有機能用のプログラミングインターフェイスを用いた対話制御を実現するバイトコードアプリケーション、これらのオンメディアライブラリ及びバイトコードアプリケーションの機能を一体化した統合バイトコードアプリケーションというからまでの3種のタイプが存在する。以下、機器固有機能を利用するためのプログラミングインターフェイスを提供するオンメディアライブラリについて説明する。図5は、オンメディアライブラリ28と、再生装置における機器固有機能制御部33と、外部サーバ29とを示す図である。以下、オンメディアライブラリ28、外部サーバ29について説明する。オンメディアライブラリ28は、ローカルネットワークアクセスを用いた機器固有機能制御部33とのデータ送受信を、その他のバイトコードアプリケーションとは分離し、ライブラリ化して、リードオンリーメディア105から供給できるようにしたものである。組込ライブラリ25が再生装置内に組込まれているのに対して、オンメディアライブラリ28はリードオンリーメディア105から供給される点が組込ライブラリ25との違いである。機器固有機能制御部33とのデータ送受信に用いるプロトコルは、個々のバイトコードアプリケーションに依存したものではなく、共通のプロトコルとして定義されている。オンメディアライブラリ28と機器固有機能制御部33との間でなされるローカルネットワークアクセスを用いた、デジタルコピーのためのプロトコルをデジタルコピーソケットプロトコルという。デジタルコピーソケットプロトコルは、バイトコードアプリケーションに対してオンメディアライブラリ28が提供しているAPIを、デジタルコピーソケットプロトコル上のコマンドデジタルコピーソケットコマンドというに変換し、ソケット通信により機器固有機能制御部33へのコマンド送信、及び、機器固有機能制御部33からのレスポンス受信という送受信を行うことである。外部サーバ29は、機器固有機能を利用することができる再生装置や機器固有機能の対象となるコンテンツを管理しており、機器固有機能制御部33からの要求に応じて、機器固有機能の利用履歴の更新と、機器固有機能の利用許諾とを行う。以上のオンメディアライブラリ28、機器固有機能制御部33、外部サーバ29間におけるデータの流れについて、図5を参照しながら説明する。図5では、下側にリードオンリーメディア105と、セキュアなメモリカード104とを描き、更にその上に再生装置とサーバ、更にその上にオンメディアライブラリ28を描いている。パイプcm2は、オンメディアライブラリ28と、機器固有機能制御部33との通信を模式的に示す。この通信は、同一端末内のローカル通信であり、ネイティブAPI27を通じてなされる。矢印cp1は、リードオンリーメディア105からセキュアなメモリカード104へのコピーを模式的に示す。このコピーは、機器固有機能を利用するための、管理情報の書き込みであり、端末内ローカル通信を通じたオンメディアライブラリ28による指示でなされる。パイプcm1は、機器固有機能制御部33と外部サーバ29との通信を模式的に示す。この通信は、端末間のグローバル通信である。セキュアなメモリカード104へのダウンロードは、このグローバルネットワークを介した、機器固有機能制御部33による通信要求でなされる。前述したように、本実施の形態においては、従来のネットワークAPIであるソケット通信APIを端末内部に向けることで、バイトコード処理モジュールのAPIとしては規定されていない端末固有の機能を呼び出すことが可能となる。従来のBDROMにおけるBDJアプリケーション等のバイトコードアプリケーションにおけるネットワークAPIの利用方法は、主に外部サーバとの接続に用いられ、特典映像や追加字幕アプリケーションなどの追加コンテンツのダウンロード用として使われてきた。これらのネットワークAPIを拡張するとなく同一端末間のローカル通信を形成することで、バイトコードアプリケーションから見れば、現在実行中の再生端末がまるでサーバのようにアクセスすることが可能となり、規定のAPIにとらわれない様々な機能を呼び出すことが可能となる。以上が機器固有機能制御部33についての説明である。続いて、機器固有機能を実行するためのバイトコードアプリケーションの処理手順について説明する。図6は、バイトコードアプリケーションが機器固有機能を利用するための、バイトコードアプリケーションの処理手順を示すフローチャートである。まず、バイトコードアプリケーションは、再生装置がデジタルコピーに対応しているかどうかの判断を行う。バイトコードアプリケーションからオンメディアライブラィ28に対し、再生装置のデジタルコピー対応確認が要求されると、オンメディアライブラィ28は、デジタルコピーに割り当てられた通信ポートを示すシステムプロパティdigitalcopyportが存在するかどうかを確認するステップS501。ステップS501でシステムプロパティが存在しなければ、予め決められた固定ポートへ接続しステップS502、システムプロパティが存在する場合は、システムプロパティが示すポートへ接続するステップS503。次に通信ポートへの接続に成功したかどうかを確認しステップS504、通信ポートへの接続が失敗すれば、現在の再生装置ではデジタルコピーに対応していないと判断するステップS508。ステップS504で通信ポートへの接続に成功した場合、デジタルコピーライブラリは、その通信ポートを経由して機器固有機能制御部33に初期化を要求するステップS505。そして、ステップS505の初期化要求に対する機器固有機能制御部33からの応答を接続中の通信ポートで受け取るステップS506。ステップS506で、初期化成功との応答を受け取った場合、現在の再生装置で機器固有機能の実行は可能であるから、機器固有機能を実行するステップS507。機器固有機能制御部33からの応答がない、もしくは初期化失敗との応答を受け取った場合は、現在の再生装置では機器固有機能の実行は不可であり、機器固有機能を実行せずにリターンするステップS508。このようにバイトコードアプリケーションは、ポート接続が成功したかどうか、機器固有機能制御部33の初期化に成功したかどうかで、機器固有機能の実行可能性を判断する。以上のように本実施形態によれば、ネイティブAPIとしてサポートされているソケット機能を用いて、機器固有機能をバイトコードアプリケーションに提供するので、既に標準化されているデジタルストリーム再生制御のためのAPIに対して、追加/改変を加えることなく、アプリケーションに機器固有機能を使用させることができる。追加/改変を加えることなく、アプリケーションに機器固有機能を使用させるので、特殊機能を利用したアプリケーションが様々なコンテンツプロバイダが開発され、市場に投入されると予想される。その結果、特殊機能を起動するためのユーザインターフェイスが多種多様なものになり、ユーザは、より判りやすく親しみ易いユーザインターフェイスを通じて、あるメーカーが独自開発した特殊機能を利用することができる。機器固有機能として実装する限り、後発メーカーの追従を避けることができるから、一メーカーが開発した特殊機能を機器固有機能として実装した製品により、市場を寡占することができる。第1実施形態では、機器固有機能の内容を具体的に特定していなかったが、本実施形態では、機器固有機能がデジタルコピーであるとして説明する。本実施形態におけるデジタルコピーとは、携帯端末での視聴のために、リードオンリーメディア105からセキュアなメモリカード104へと持出し視聴用コンテンツをコピーする機能、つまりメディア間コピーのことである。そして、外部サーバによる管理の下、再生装置がメディア間コピーを実行することによって、リードオンリーメディア105におけるコンテンツを、携帯端末に持ち出させるサービスを、emoveサービスという。emoveサービスの対象であり、持ち出しを前提にしたコンテンツを、emoveコンテンツという。emoveサービスを、既存の類似の機能やサービスと対比した場合、長所は以下の通りである。既存の類似機能にはAACSにおけるマネージドコピーがあり、類似のサービスには、Apple社のデジタルコピーがある。AACSにおけるマネージドコピーは、トランスコードを必要とし、例えば、2時間のAVストリームであるなら、そのトランスコードに、2時間長の処理時間が必要となる。これに対し、emoveサービスでは、リードオンリーメディア105に記録されているコンテンツをセキュアなメモリカード104に書き込む処理で足りるから、その処理時間は短くて済む。Apple社のデジタルコピーは、BDROMとは別に、DVDVideoディスクやコピーのためのコンテンツが記録されたDVDROMディスクがセットパッケージに同梱されていて、そのDVDROMディスクをパソコンに装填して、記録されているプログラムをパソコンで動作させることによりメモリカードへのコピーを行う。BDROM、DVDVideo、DVDROMが同梱されているため、価格が高く、ユーザにとって望ましくない。このデジタルコピーと比較すると、emoveサービスでは、リードオンリーメディア105に記録されたバイトコードアプリケーションに直接、持ち出し視聴のためのコピーを行わせるので、パソコンにデジタルコピーを実行させるためのDVDROMは不要である。以上がemoveサービスについての説明である。続いて、メディア間コピーの詳細について説明する。携帯端末向け保護コンテンツは、外部サーバによる権利管理の下、私的利用のためのコピーが認められる。よって、機器固有機能制御部33によるデジタルコピーは、外部サーバの1つである、デジタルコピーサーバによる権利管理の下でなされる必要がある。以下、権利管理のためのデジタルコピーモジュール35及びデジタルコピーサーバ36について説明する。図7は、デジタルコピーにおける、再生装置内外のデータの流れを示す。かかるデジタルコピーを実現するため、機器固有機能制御部33はデジタルコピーモジュール35を具備しており、また外部サーバ29は、デジタルコピーサーバ36に置き換えられている。デジタルコピーモジュール35は、リードオンリーメディア105からの携帯端末向け保護コンテンツを構成するファイルの読み出しと、セキュアなメモリカード104への書き込みとを行うことで、携帯端末向け保護コンテンツを構成するファイルのコピーを行う。デジタルコピーモジュール35には、ファイル読み出し/書き込みのための複数のパラメータが予め設定されており、これらのパラメータに基づき、コピーの前処理、後処理を行う。ここで、複数のパラメータには、カレントシリアルID、カレントソースロケーション、カレントサーバURL、カレント出力デバイス、カレントレジューム位置といったものがある。そして、デジタルコピーモジュール35による前処理とは、対象となる携帯端末向け保護コンテンツの残りコピー回数をサーバから取得するというものである。具体的には、カレントソースロケーションを示すファイルパスによって特定されるリードオンリーメディア105のディレクトリ配下のコピー情報ファイルからコンテンツIDを取り出し、カレント出力デバイスによって特定されるドライブに装填されたセキュアなメモリカード104からメディアIDを取り出す。これらのコンテンツIDと、メディアIDと、カレントのシリアルIDとの組合せを、カレントサーバURLで指示されたサーバに送信することで、データベースの検索をサーバに行わせ、これらの組合せにヒットする残りコピー回数を取り出させてバイトコードアプリケーションに返す。後処理とは、いわゆる復号鍵のダウンロードであり、コンテンツIDと、シリアルIDと、メディアIDと、カレント出力デバイスのMKBとの組合せを、サーバに送信することで、データベースの検索をサーバに行わせ、これらの組合せにヒットするタイトルキーを取り出させ、復号鍵を生成させて、セキュアなメモリカード104にダウンロードするというものである。デジタルコピーサーバ36は、携帯端末向け保護コンテンツの権利管理を行う複数のシリアルIDについてのタイトルキーのデータベースを有している。このデータベースでは、複数のシリアルIDのそれぞれに対応付けて、タイトルキーを管理しており、コンテンツID、シリアルID、メディアID、MKBの組合せをキーワードとした検索要求が機器固有機能制御部33からなされば、このキーワードにおけるシリアルIDを用いてデータベースを検索して、当該組合せにヒットしたタイトルキーをデータベースから読み出し、コンテンツID、シリアルID、メディアID、MKBを用いてこのタイトルキーを暗号化した上で復号鍵を得て、検索要求の要求元のデジタルコピーモジュール35に復号鍵をダウンロードする。またデジタルコピーサーバ36は、コンテンツID、メディアID、シリアルIDの組みに対応付けて、複数のコピーチケットを管理している。コピーチケットとは、コンテンツID、メディアID、シリアルIDの組合せのそれぞれについて、何回の私的コピーが認められているかを管理する権利管理情報であり、本実施形態では、デジタルコピーの運営業者が定めた残コピー回数によって、私的コピーの回数を管理している。デジタルコピーが一回なされる度に、残コピー回数は、1回ずつ減じられることになる。そして、コンテンツID、シリアルID、メディアIDをキーワードとした検索要求がデジタルコピーモジュール35からなされれば、データベースにおける複数のコピーチケットの中から、これらコンテンツID、シリアルID、メディアIDの組合せ条件にヒットする残コピー回数をデータベースから読み出して、要求元のデジタルコピーモジュール35に返す。ここで、コンテンツID、シリアルID、メディアID、MKBの組合せを含む検索要求がデジタルコピーモジュール35からなされて、タイトルキーのダウンロードがなされれば、残コピー回数を一回減じる。こうすることで、デジタルコピーは、デジタルコピーサーバ36で管理されている残りコピー回数以下に制限されることになる。以下、図7を参照して、デジタルコピープロセスにおけるデータの流れを説明する。図7では、中段に再生装置を描き、その下側にセキュアなメモリカード104を描き、上側にリードオンリーメディア105と、デジタルコピーサーバ36とを描いている。デジタルコピープロセスにおいて扱う主なデータは、シリアルID,コンテンツID,メディアIDMID、メディアキーブロック,携帯端末向け保護コンテンツ、及び復号鍵である。リードオンリーメディア105には、コンテンツIDを格納したファイル、携帯端末向け保護コンテンツ、バイトコードアプリケーション、オンメディアライブラリ28が存在する。シリアルIDは、個々のリードオンリーメディア105のそれぞれを識別するための識別情報であり、市場に流通するリードオンリーメディア105のうち、機器固有機能の対象になっているもののシリアルIDは、デジタルコピーサーバ36のデータベースにおいて、管理されている。シリアルIDとしては、BCABurstCuttingAreaに記録されているPMSNPrerecordedMediaSerialNumberを利用することができるが、これ以外の値として、パッケージに同梱されている紙に記載されたクーポンIDをユーザに手入力させた値を代替することも可能である。PMSNを利用すれば、ユーザに手入力させる必要もなく自動で認証を行うことが可能であるが、一方でレンタルディスク等の場合にPMSNを利用するとなると、最初に借りたユーザだけが、このサービスの実施権が与えられることになり、二番目以降に借りるユーザに不公平となる。レンタルディスクの場合はクーポンIDの手入力が望ましく、市販ディスクの場合はPMSNの利用が望ましい。メディアIDはコピー先メディアのシステム領域に記載されている値である。図7の動作例においてコピーされるのは携帯端末向け保護コンテンツであり、ダウンロードされるのは、復号鍵である。このダウンロードにあたって、セキュアなメモリカード104からはMKBが読み出され、コンテンツID、シリアルIDと共に、デジタルコピーサーバ36に送信される。シリアルIDの流れを追ってみると、バイトコードアプリケーションがシリアルIDを取得した際、バイトコードアプリケーションは直接、シリアルIDをデジタルコピーモジュール35に引き渡すのではなく、オンメディアライブラリ28にシリアルIDを引き渡して、オンメディアライブラリ28を通じて、シリアルIDをデジタルコピーサーバ36に引き渡す。シリアルIDはバイトコードアプリケーションが指定したものが、矢印sd1sd2sd3に示すように、デジタルコピーライブラリに渡され、それがソケット通信APIを通じて、デジタルコピーモジュール35を通じてデジタルコピーサーバ36に引き渡される。コンテンツIDの流れを負ってみると、コンテンツIDは読み出され、サーバに送信される。コンテンツIDに関しては、バイトコードアプリケーションが指定したディスク上のコピー情報ファイルから、矢印cd1に示すようにデジタルコピーモジュール35によって読み取られる。メディアID,MKBに関しては、バイトコードアプリケーションが指定したコピー先のセキュアなメモリカード104のシステム領域から、矢印md1に示すように、デジタルコピーモジュール35によって読み取られる。こうして得られたシリアルID,コンテンツID,メディアIDMID、MKBは、矢印sd3cd2md2に示すように、デジタルコピーサーバ36へ送られ、これらと引き換えに、デジタルコピーサーバ36から矢印dk1に示すように復号鍵は送信される。これがサーバからのダウンロードであり、デジタルコピーモジュール35は、矢印dk2に示すようにその復号鍵をコピー先メディアの保護領域に書き込む。以上がデジタルコピープロセスにおいて扱う主なデータの流れである。また、コピー先のメディアの保護領域に書き込まれる復号鍵は、携帯端末向け保護コンテンツ内の暗号化データを復号するためのキー情報タイトルキーを含む。復号鍵は、コピー先のメディアのシステム領域に記録されたMKBを用いて復号できるように暗号化されている。以上が、デジタルコピーモジュール35、デジタルコピーサーバ36、バイトコードアプリケーション、セキュアなメモリカード104間のデータの流れである。続いて、バイトコードアプリケーションと、機器固有機能制御部33との間でなされる通信の詳細について説明する。図8は、バイトコードアプリケーション、デジタルコピーモジュール35、及びデジタルコピーサーバ36とのデータ送受信を示すシーケンス図である。本図は、システムの通信シーケンスを示すシーケンス図である。本図の横方向には、バイトコードアプリケーション、オンメディアライブラリ28、デジタルコピーモジュール35、デジタルコピーサーバ36が、それぞれ配置されている。縦方向には、複数の時間軸を描いている。これらの時間軸は、装置が具備しているクロックにより管理されるものである。時間軸上の各時点が、API呼出しのタイミングとなる。バイトコードアプリケーションとオンメディアライブラィ28との間では、通信経路が確立されず、通常のアプリケーション内API呼び出しが行われるに過ぎない。しかし、オンメディアライブラリ28と、デジタルコピーモジュール35との間は、同一端末内のソケット通信である。デジタルコピーモジュール35とデジタルコピーサーバ36との間は、別端末間のグローバルソケット通信が形成される。本図におけるシーケンスは、a機器確認フェーズ、b初期化フェーズ、dパラメータセットフェーズ、e残コピー回数確認フェーズ、fコピー開始フェーズ、gコピー進捗確認フェーズ、h鍵書込みフェーズからなる。以下、これらのフェーズについて説明する。a機能確認フェーズは、オンメディアライブラィ28に対して機能確認を行い、オンメディアライブラィ28からデジタルコピーの可否を受けとるという、オンメディアライブラィ28を介したデジタルコピーモジュール35とのやりとりで構成される。b初期化フェーズは、オンメディアライブラィ28に対して初期化を行い、オンメディアライブラィ28から初期化の可否を受けとるという、オンメディアライブラィ28を介したデジタルコピーモジュール35とのやりとりで構成される。dパラメータセットフェーズは、オンメディアライブラィ28に対してコピーパラメータをセットするとの設定処理を行い、オンメディアライブラィ28からパラメータセットの可否を受け取るというオンメディアライブラィ28を介したデジタルコピーモジュール35とのやりとりで構成される。つまりバイトコードアプリケーションはデジタルコピー可能であるという通知を受け取ると、続いてデジタルコピーに必要なパラメータをデジタルコピーライブラリ経由で、デジタルコピーモジュール35へセットする。デジタルコピーライブラリはこれらのパラメータがバイトコードアプリケーションから指定されると、接続中の通信ポートを用いてデジタルコピーモジュール35へ指定されたパラメータを送信する。e残コピー回数確認フェーズは、オンメディアライブラィ28に対して残コピー回数を確認するとの処理を行い、オンメディアライブラィ28から残りコピー回数を受け取るというオンメディアライブラィ28、デジタルコピーモジュール35を介したサーバとのやりとりで構成される。バイトコードアプリケーションは次に残コピー回数の確認を行う。残コピー回数の確認も、パラメータのセットと同様、デジタルコピーライブラリを経由し、接続中の通信ポートを用いてデジタルコピーモジュール35へ問い合わせを行う。残コピー回数は、デジタルコピーサーバ36で管理されているため、デジタルコピーモジュール35は残コピー回数の確認要求を受け取ると、矢印に示すように、現在セットされているパラメータから、コンテンツID,シリアルID,メディアIDを取り出しデジタルコピーサーバ36へ、これら3つの値を送る。バイトコードアプリケーション、オンメディアライブラィ28及びデジタルコピーモジュール35の間は端末内ローカル通信であり、外部インターネット接続不要であったが、デジタルコピーモジュール35とデジタルコピーサーバ36との間はグローバルなインターネット接続が必要となる。デジタルコピーサーバ36は、受け取った値を元に残コピー回数を割り出し、デジタルコピーモジュール35へ残コピー回数の値を返信する。デジタルコピーモジュール35は、この残コピー回数をデジタルコピーライブラリ経由でバイトコードアプリケーションに通知する。fコピー開始フェーズは、オンメディアライブラィ28に対してコピー開始を要求するとの処理を行い、オンメディアライブラィ28から、コピー開始の成功/失敗、及び、コピー完了通知の何れかを受け取るというオンメディアライブラィ28を介したデジタルコピーモジュール35とのやりとりで構成される。バイトコードアプリケーションは、コピー回数が1回以上残っていることが判明した場合、コピー開始の要求を行う。このコピー開始要求も、これまでと同様、デジタルコピーライブラリを経由し、通信ポートを用いてデジタルコピーモジュール35へ伝えられる。デジタルコピーモジュール35はコピー開始要求を受け取ると、コピーを開始し、その間、バイトコードアプリケーションからの要求に応じてコピー進捗状況を随時通知する。g進捗確認フェーズは、オンメディアライブラィ28に対して進捗確認を要求するとの処理を行い、オンメディアライブラィ28から進捗状況を受け取るというオンメディアライブラィ28を介したデジタルコピーモジュール35とのやりとりで構成される。h鍵書込みフェーズは、オンメディアライブラィ28に対して鍵書き込みを要求するとの処理を行い、オンメディアライブラィ28から復号鍵書き込みの完了通知を受け取るというオンメディアライブラィ28、デジタルコピーモジュール35を介したサーバとのやりとりで構成される。具体的にいうと、コピー完了通知を受け取った際、バイトコードアプリケーションは、復号鍵の書込みをデジタルコピーモジュール35へ要求する。デジタルコピーモジュール35は復号鍵の書込み要求を受け取ると、現在セットされているパラメータから、コンテンツID,シリアルID,メディアID,MKBを取り出しデジタルコピーサーバ36へ、これら4つの値を送る。デジタルコピーサーバ36は、受け取った値を元に復号鍵を生成し、デジタルコピーモジュール35へ復号鍵を返信する。デジタルコピーモジュール35は、デジタルコピーサーバ36から受け取った復号鍵をコピー先メディアに書き込み、書き込みが完了すると、デジタルコピーライブラリを経由してバイトコードアプリケーションに書き込み完了を通知する。以上が、機器固有機能のために、再生装置内でなされる、3つの通信についての説明である。続いて、デジタルコピーを実現するにあたっての処理手順の詳細について説明する。デジタルコピーの実行が可能である場合、バイトコードアプリケーションは、オンメディアライブラリ28とのアプリケーション間通信を通じて、デジタルコピーのプロセスを実行する。オンメディアライブラリ28によるデジタルコピープロセスの処理手順は、図10に示すものとなる。以上が通信シーケンスの詳細についての説明である。続いて、デジタルコピーモジュール35の内部構成について説明する。図9は、デジタルコピーモジュール35を詳細化した図である。デジタルコピーモジュール35は、通信管理部601、鍵情報読込部602、メディア状態管理部603、コピー実行部604、コピー状態通知部605、コピー進捗管理部606、鍵情報書込部608、コマンド処理部609、空き容量判定部610で構成される。通信管理部601は、再生装置内の通信ポートの一つをデジタルコピー制御のために割り当て、このデジタルコピー通信ポートを用いて、バイトコード処理モジュールとのプロトコル通信を行う。具体的には、サーバソケットとしてデジタルコピー通信ポートを開いて、バイトコード処理モジュールからの要求が来るのを待ち、デジタルコピー通信ポートに対してデータが送られてくると、送られてきたデータを解析し、そのデータに対応する処理を行う。処理結果も同様にデジタルコピー通信ポートを介してバイトコード処理モジュールに送り返す。加えて、通信管理部601はデジタルコピーサーバ36とのデータ通信管理も行う。具体的には、暗号化された携帯端末向けデジタルストリームを復号するために必要な復号鍵をデジタルコピーサーバ36から取得するために必要な通信処理を行う。鍵情報読込部602は、復号鍵生成に必要な情報をコピー元のリードオンリーメディア105、及び、コピー先のセキュアなメモリカード104から読出す。具体的には、コピー元からはリードオンリーメディア105上の特殊領域であるBCABurstCuttingAreaに記録されている記録媒体の物理的なシリアルIDを示すPMSNPrerecordedMediaSerialNumberを、コピー先のリードオンリーメディア105からはコピー先のメディアに記録されている、メディア毎にユニークに設定されるメディア固有の情報メディアID、及び復号鍵生成に必要な鍵情報が記録されたメディアキーブロックMKBの読出しを行う。メディア状態管理部603は、再生装置が現在コピー先として利用できるメディアの種類一覧を管理する。例えば、再生装置がSDカードスロットと、USBメモリスロットを備え、現在、SDカードのみが挿入されているのであれば、SDカードが現在のコピー先の対象と判断する。SDカードとUSBメモリもしくはUSB接続されている携帯端末の両方が挿入されていれば、コピー先としてSDカード、USBメモリの両方が可能と判断する。加えて、コピー先メディアの空き容量管理も行う。コピー実行部604は、バイトコードアプリケーションから指示されたリードオンリーメディア105上の携帯端末向け保護コンテンツを別メディアへコピーする処理を行う。バイトコードアプリケーションからの指示はオンメディアライブラィ28を経由し、デジタルコピー通信ポート上で行われる。なおコピー実行部604によるデータコピーだけでは、コピー先で携帯端末向け保護コンテンツを再生することはできない。後述の復号鍵書込部608によってコピー先へ復号鍵の書込みが完了した後にコピー先にて再生が可能となる。コピー状態通知部605はコピーの開始正常終了エラー終了等の状態遷移を管理し、デジタルコピー通信ポートを通じてデジタルコピーモジュール35とローカル通信接続中のバイトコードアプリケーションに状態遷移を通知する。コピー進捗管理部606はコピー対象となっている残りバイト数、コピー済みバイト数の管理を行い、デジタルコピー通信ポートを介したバイトコードアプリケーションからの要求に応じて、現在の進捗情報を通知する。復号鍵書込部608は、鍵情報読込部602が取得したリードオンリーメディア105のシリアルID、コピー先メディアのメディアID、及びMKBから生成される復号鍵の書込みを行う。復号鍵の生成は、デジタルコピーサーバ36にある秘密鍵を元に行われるため、デジタルコピーモジュール35は鍵情報読込部602が、リードオンリーメディア105のシリアルID、コピー先メディアのメディアID、及びMKBを取得した後、通信管理部601を経由してデジタルコピーサーバ36にこれらの値と、コピー対象コンテンツのコンテンツIDを送信する。デジタルコピーサーバ36は受け取った値とデジタルコピーサーバ36が保持する秘密鍵から復号鍵を生成し、通信管理部601へ復号鍵を送信する。生成される復号鍵はコピー先メディアのMKBにより復号できるような暗号化がなされている。通信管理部601が復号鍵を受け取ると鍵情報書込部608はコピー先の保護領域に復号鍵の書込みを行う。復号鍵はキー情報タイトルキーを含んでおり、キー情報が暗号化された携帯端末向け保護コンテンツの復号に用いられる。このキー情報を含む復号鍵がなければ、たとえ、無断でコピー元の携帯端末向け保護コンテンツのみを別のメディアにコピーしたとしても再生することはできない。コマンド解釈部609は、オンメディアライブラリ28が発行したコマンドを解釈し、コマンドのオペランドを用いて、上記通信管理部601~コマンド処理部609を制御することにより、オンメディアライブラリ28が発行したコマンドのオペコードに応じた制御内容を実行する。空き容量判定部610は、コピー先メディアの空き残量及びコピー元コンテンツをもとにコピーに必要な空き容量がコピー先に存在するかを判定する。デジタルコピーモジュール35は以上の構成を持ち、これらの操作はデジタルコピー通信ポートにローカル通信接続を行っているバイトコードアプリケーションから制御できる。これらの制御を操作できる直接のAPIはバイトコード処理モジュールに存在しないため、デジタルコピー通信ポートに接続できていないバイトコードアプリケーションからは制御ができないということになる。図10は、デジタルコピーモジュール35におけるデジタルコピープロセスのフローチャートである。デジタルコピーモジュール35は、まず再生装置に挿入されているリードオンリーメディア105上に携帯端末向け保護コンテンツが存在するかどうかを確認するステップS101。携帯端末向け保護コンテンツが、ディスク上のルートディレクトリ直下のEMOVEディレクトリの配下に記録されるとのルールが存在する場合、デジタルコピーモジュール35は、このEMOVEディレクトリが存在するかどうかで、ディスク上に携帯端末向け保護コンテンツが存在するかどうかを判断する。EMOVEディレクトリとは、emoveサービスの対象となるファイル一式を格納するためのディレクトリである。ステップS101で携帯端末向け保護コンテンツが存在しなかった場合は、デジタルコピープロセスを中断し、携帯端末向け保護コンテンツが存在する場合、デジタルコピーモジュール35はデジタルコピーソケットコマンド用通信ポートを指定してサーバソケットを作成し、デジタルコピーソケットコマンド用通信ポートに対するバイトコードアプリケーションからの接続を待つステップS102。携帯端末向け保護コンテンツが存在する場合のみサーバソケットを作成する理由は、常にサーバソケットを開いた状態にしておくと、無駄にポートを空けている時間が長くなり、不必要なリソースを消費するということと不正アプリケーションからの攻撃の恐れがあるということから、ポートを開いている時間は極力短時間にするのが望ましい。そのため、ステップS101で携帯端末向け保護コンテンツが存在する場合のみ、サーバソケットを作成し、ポートを開く。ポートを開く時間を極小化する他の方法としては、バイトコードアプリケーション動作中のみすなわち、バイトコードアプリケーションを連動したタイトル再生中のみ、サーバソケットを作成しポートを開く、もしくはバイトコードアプリケーションからポートオープンの命令を受け取ってからポートを開く等が考えられる。ポートオープン命令はポートが閉じられた状態で行われることになるので、バイトコードアプリケーションからポートオープンの命令を受け取るには、ポート通信以外の方法で受け取らなければならない。そのためにAPIを追加するというのであれば、互換性維持のため一切のAPI追加を行わないという本願の趣旨に反することになるため、APIの追加なしで命令を受け取る必要がある。ポートオープンの命令を示す案としては、例えば、汎用のシステムプロパティAPIを用い、バイトコードアプリケーションから、予め決められたプロパティにある値がセットされたとき、もしくはレジスタセットの中の汎用レジスタの中から、ある一つに対して予め決められた値がセットされたときに、ポートオープンの要求がなされたとみなすことができる。システムプロパティAPIを用いる場合は例えば、digitalcopyportstatusというプロパティ名を用意しておき、そのプロパティ名の示す値にOPENを設定すると、ポートを開くという手段が考えられる。ステップS102でサーバソケットを作成し、デジタルコピーソケットコマンド用通信ポートを開くと、そのポートに対してバイトコードアプリケーションデジタルコピーライブラリを含むが接続してくるのを待つステップS103。バイトコードアプリケーションからの接続要求は予め決められたコマンド文字列もしくはバイナリデータでも良いをデジタルコピーモジュール35とバイトコードアプリケーションデジタルコピーライブラリ間で相互に交換し、お互いが送り合うデータが期待値と一致しているかどうかを相互確認することで実現するのが望ましい。当然ながら、お互いが送り合うデータが期待値と一致していなかった場合は、不正とみなし、以後の処理を中断するステップS104。ステップS104でデジタルコピーモジュール35はバイトコードアプリケーションとの接続に成功したと判断した場合、次にバイトコードアプリケーションからデジタルコピーのコピー先候補のリスト再生装置がサポートしているコピー先メディア一覧を要求してくるのを待ち、通信ポートを介してその要求を受け取ると、この再生装置において携帯端末向け保護コンテンツのコピー先としてサポートしているメディアの確認を行うステップS105。携帯端末向け保護コンテンツのコピー先としてサポートしているメディアがなければデジタルコピーを中断し、サポートしているメディアがあれば、そのメディアのリストを同じく通信ポートを介してバイトコードアプリケーションに送信するステップS106。デジタルコピーモジュール35はこの時点で空き容量が不足しているかどうかを先行して判断することができるが、ステップS106で返すメディアのリストには空き容量が不足しているメディア及びまだ挿入されていないメディアも含めてバイトコードアプリケーションに渡す。理由は、空き容量が不足しているものを除いて渡してしまうと、再生装置がサポートしていないから、リストにないのか空き容量が不足しているからリストにないのかの判断がつかないためである。再生装置はサポートしているが、空き容量が不足している場合はユーザがそのメディア上の不要ファイルを削除するなどして空き容量を確保するという選択を取ることができるため、ステップS106で返すリストには空き容量が不足しているものも含めるのが望ましい。同様の理由でリストには未挿入メディアも含めておけば、メディアの挿入し忘れをユーザに通知することができる。次に、バイトコードアプリケーションは得られたコピー先候補のリストをユーザに提示し、ユーザが選んだメディアをデジタルコピーモジュール35に通知するステップS107。デジタルコピーモジュール35は選択されたメディアにコピーを行うための十分な空き容量があるかどうか、及び残コピー回数が残っているかどうかを確認しステップS108、空き容量がない、もしくは残コピー回数が残っていなければバイトコードアプリケーションに容量不足もしくは残コピー回数がない旨を通知する。残コピー回数の確認はデジタルコピーサーバ36への問い合わせが必要となる。バイトコードアプリケーションは容量不足の通知をデジタルコピーモジュール35から受け取った場合は、再度ステップS107に戻り、別のメディアの選択を行わせるか、ユーザに不要ファイルの削除を促す、もしくは同一種類のメディアでより容量の大きいものに交換する等のメッセージを表示する。ステップS108での空き容量確認は、コピー先メディアのユーザ領域だけでなく、保護領域の空き容量の確認をも含む。保護領域にすでに他のコンテンツ復号鍵が書き込まれており、復号鍵を追加で書き込む余地がなければ、ユーザ領域に空きがあったとしても、容量不足の通知をバイトコードアプリケーションに通知する必要がある。万一、保護領域の空き容量チェックを怠った場合は、デジタルコピープロセスの最後のステップである復号鍵の書き込み時点で失敗することになり、ユーザにとっては時間のロスとなるばかりか、デジタルコピーサーバ36から復号鍵のダウンロードが完了しているために最悪の場合コピー権利を無駄に一つ消費してしまうことになりかねない。よって、ステップS108の空き容量確認は、ユーザ領域だけでなく保護領域の空き容量チェックも不可欠である。ステップS108で残コピー回数が残っており、かつコピー先のメディアに十分な空き容量があると判断できれば、デジタルコピーモジュール35はディスク上の携帯端末向け保護コンテンツを指定されたメディアへコピーするステップS109。この間、バイトコードアプリケーションはデジタルコピーモジュール35にコピーの進捗を問い合わせることで、現在のコピー進捗を把握することができ、コピー進捗状況をユーザに表示することができる。携帯端末向け保護コンテンツのデータコピーが完了すると、デジタルコピーモジュール35は携帯端末向け保護コンテンツを復号するための復号鍵をデジタルコピーサーバ36から取得するステップS110。復号鍵の取得は、シリアルID,コンテンツID,メディアID,MKBの4つのデータをネットワークIFを介してデジタルコピーサーバ36に送信し、デジタルコピーサーバ36が持つ秘密鍵を元にコピー先メディアで携帯端末向け保護コンテンツを復号するための復号鍵をデジタルコピーサーバ36側で作成し、デジタルコピーモジュール35はデジタルコピーサーバ36側で作成された復号鍵を受け取り、コピー先の保護領域に復号鍵の書込みを行うステップS111。以上のように本実施形態によれば、オンメディアライブラリ28及びデジタルコピーモジュール35は、端末内ローカル通信によって、リードオンリーメディア105に予め記録されている携帯端末向け保護コンテンツを、セキュアなメモリカード104にコピーさせるので、再生装置のメーカーは、そのようなメディア間コピー機能の利用を、特定したコンテンツプロバイダに利用させることができる。これにより、メディア間コピー機能を利用したコンテンツの作成に弾みを付け、コンテンツの充実化を図ることができる。第1実施形態は、デジタルコピーのコピーソースとなるリードオンリーメディア105が、動作モードオブジェクト、バイトコードアプリケーションを記録したリードオンリーメディア105であるとして説明をした。本実施形態では、この記録媒体が、BDROMであるとして説明を行う。図11は、BDROM形式のデジタルAVストリームであり、ビデオストリーム、1つ以上のオーディオストリーム、1つ以上の副映像ストリームを多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分を、副映像ストリームは、映画の字幕をそれぞれ示している。拡張子clpiが付与されたファイルは、デジタルAVストリームのそれぞれに1対1に対応するストリーム管理情報である。ストリーム管理情報は、デジタルAVストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、GOPの先頭位置を示すエントリーマップをもっている。拡張子mplsが付与されたファイルは、プレイリスト情報を格納したファイルであり、ストリームの再生区間InTimeOutTimeが記録されている。拡張子jarが付与されたファイルは、Javaアーカイブファイルであり、BDJオブジェクトを用いて動的なシナリオ制御を行うバイトコードアプリケーションのプログラムが記述されている。BDROM上のコンテンツの再生単位を示す各タイトルの再生をBDJアプリケーションから制御したい場合は、このファイルを必要とする。このアーカイブファイルは、パーミッションリクエストファイルを含み、パーミッションリクエストファイルは、バイトコードアプリケーションと、ローカルホストとの間のソケット通信を許可している拡張子bdjoが付与されたファイルは、BDJモードの動作モードオブジェクトを格納したファイルである。indexbdmvファイル名固定は、BDROM全体に関するインデックステーブルであり、映画作品のプロバイダを特定する識別子であるorganizationID32bitや、プロバイダが提供するBDROMのそれぞれに割り当てられた識別子であるdiscID128bit等の情報を持ち、再生装置へのディスク挿入後に、indexbdmvが最初に読み出されることで、再生装置においてディスクが一意に認識される。加えて、indexbdmvにはBDROMにおいて再生可能となる複数のタイトルと、個々のタイトルを規定するBDJオブジェクトとを対応付けて示すテーブルが含まれる。MovieObjectbdmvファイル名固定は、ナビゲーションコマンドを格納したファイルであり、プレイリストの選択やプレーヤ状態レジスタ、プレーヤ設定レジスタの読み出し/書き込みを行わせる。以上が、BDMVディレクトリについて説明である。つづいて、EMOVEディレクトリについて説明する。EMOVEディレクトリの配下には、BDROMに記録されているコンテンツと、内容的に同一となるコンテンツを携帯端末で視聴するためのAVデジタルストリームや管理情報が記録されており、複数のコピーソース格納ディレクトリが作成される。図中のDATA01DATA02DATAxxは、それぞれがコピーソース格納ディレクトリである。コピーソース格納ディレクトリとは、デジタルコピーの対象となる単位であり、一個のBDROMにおいて、コピーの対象が、4つ存在するなら、EMOVEディレクトリの配下には、DATA01ディレクトリ、DATA02ディレクトリ、DATA03ディレクトリ、DATA04ディレクトリという4つのコピーソース格納ディレクトリが記録されることになる。コピーソース格納ディレクトリは、様々な個数だけ作成することができるから、ストリーム形式が異なる複数の携帯端末向け保護コンテンツや、再生内容のバリエーションが異なる複数の携帯端末向け保護コンテンツ等、デジタルコピーの需要が高い携帯端末向け保護コンテンツを、オーサリング時に予め作成しておくことができる。以上がBDROMのディレクトリ構成、ファイル構成についての説明である。またコピーソース格納ディレクトリに格納されている一式のファイルは、デジタルコピーの対象となる。コピーソース格納ディレクトリに格納されることでデジタルコピーの対象となる一式のファイルを、コピーソースユニットという。図12は、ストリーム形式が異なる、複数の携帯端末向け保護コンテンツが記録されているBDROMのディレクトリ構成の一例を示す。この一例は、携帯端末向け保護コンテンツにVGA形式のもの、ワンセグ形式のものという2つのバージョンが存在することを前提にしており、これら2つのバージョンのそれぞれに対応する携帯端末向け保護コンテンツを、別個のコピーソースユニットとして扱い、DATA01ディレクトリ、DATA02ディレクトリに記録している。本図におけるDATA01ディレクトリは、VGA形式の携帯端末向け保護コンテンツに対応するコピーソース格納ディレクトリである。DATA01ディレクトリの配下にはEMOVINF、MGRDATA、PRGMGR、PRG001PGI、MOV001SD1の5つのファイルが存在する。EMOVINFは、コピー情報ファイルであり、携帯端末向けコンテンツをそれぞれ一意に識別するために割り当てられたコンテンツID以降、CIDと称する場合もあるが記録されている。EMOVINFは、個々のコピーソース格納ディレクトリ毎に存在するので、個々のコピーソース格納ディレクトリ毎にコンテンツIDを変えることが可能であるし、また、コンテンツIDを同一にすることも可能である。コンテンツIDをコピーソース格納ディレクトリ毎に変化させれば、デジタルコピーサーバ36では、複数のコンテンツIDに配置された個々の携帯端末向け保護コンテンツを、別々のコンテンツとして扱って管理することができる。一方、コンテンツIDを複数のコピーソース格納ディレクトリ間で同一にすれば、デジタルコピーサーバ36では、複数のコンテンツIDに配置された個々の携帯端末向け保護コンテンツを、1つのコンテンツとして扱うことができる。MOV001SD1は、暗号化されたMPEG4形式のビデオストリームであり、個々のピクチャデータの解像度は640×480である。ビデオストリームの内部には、ランダムアクセスのための情報が含まれている。デジタルストリームに対応するMOV001SD1は例えば所定の暗号化方式例えば、CPRM方式で暗号化される。所定の暗号化方式例えば、CPRM方式で暗号化されたデジタルストリームを復号するためのキー情報タイトルキーはBDROM内には記録されていないので、不正に再生できないよう保護されている。PRG001PGIは、プレイリスト情報に該当する情報であり、MOV001SD1の再生順序を示すと共に、ビデオストリーム、オーディオストリームの符号化方式や携帯端末向けコンテンツのタイトル名を示す。BDROMにおける本編コンテンツのプレイリストは、複数のAVストリームの再生順序を定義することで構成され、本編コンテンツにおけるプレイリストと、AVストリームとの比率は、1対多である。これに対して、携帯端末向け保護コンテンツにおけるプレイリストと、AVストリームとの比率は、1対1である。これは、携帯端末向け保護コンテンツには、対話的な再生制御が予定されず、単に携帯機器でAVストリームを視聴するだけの単純な再生制御に制約されていることを意味する。MGRDATAには、携帯端末向けコンテンツのレジューム位置が記録されている。PRGMGRは、携帯端末向けコンテンツのトータルの再生時間が記録されている。DATA02ディレクトリは、ワンセグ形式の携帯端末向け保護コンテンツに対応するコピーソース格納ディレクトリである。このDATA02ディレクトリにおいて、EMOVINF、MGRDATA、PRGMGRPGR001PG1が存在する点は、DATA01ディレクトリと同じである。一方、MOV001SD1の代わりにMOV001Sx1が存在し、DATA01ディレクトリにはないMOV001MAI、MOV001が存在する点は、DATA01ディレクトリとの差異である。MOV001Sx1は、MPEG4AVC形式のデジタルストリームを格納したストリームファイルであり、個々のピクチャデータの解像度は320×240である。MOIファイルは、EntryPESPacketNumテーブルを含む。EntryPESPacketNumテーブルは、MPEG4AVCのIDRピクチャを包含していると判定されたPESパケットの先頭から、次のPESパケットの先頭までに存在するTSパケットの個数を示す。MAIファイルは、MPEG4AVCのデジタルストリームを構成するTSパケット不連続期間の開始時刻、終了時刻、位置情報、時刻オフセットを示す。DATA01ディレクトリにおけるMOV001SD1には、その内部にランダムアクセスのための情報が存在する。これに対して、MOV001Sx1には、そのようなランダムアクセスのための情報は存在しない。その代わりに、MOV001Sx1には、MOV001MAI、MOV001MOIが対応付けられている。つまり、ワンセグ形式の携帯端末向け保護コンテンツは、ストリーム毎の管理情報が追加された形式になっている。このようにBDROMには、様々なストリーム形式に対応した携帯端末向け保護コンテンツが、複数のコピーソース格納ディレクトリに予め記録されているので、デジタルコピーにあたっては、つまりMPEG4形式、MPEG4AVC形式のうち、所望のストリーム形式に合致した携帯端末向け保護コンテンツを選択することができる。トランコードを行うことなく、所望のストリーム形式のコンテンツを持ち出しに供することができるので、BDROMに複数のコピーソース格納ディレクトリが存在することの意義は大きい。本図におけるDATA03ディレクトリ、DATA04ディレクトリは、その他の格納形式、例えば、QuickTimeの形式やWindows登録商標MediaPlayerの形式で、持ち出し視聴用ためのコピーソースユニットを格納してもよい。しかし、これらの形式まで言及すると説明が煩雑になるので、これらの形式については説明を省略する。続いて、このリードオンリーメディア105におけるアプリケーションの管理の仕方について説明する。図13aは、indexbdmvファイルとタイトルの関係の一例を示す図である。タイトルとはアプリケーションとAVストリームを組にした再生単位であり、indexbdmvファイルにはディスク上のタイトル構成が記載されており、ディスク上の各タイトルと、対応するアプリケーションBDJモードタイトルであればBDJアプリケーション、HDMVモードタイトルであればシナリオプログラムの参照関係を管理している。図13aの一例では、FirstPlay、TopMenu、Title1、Title2、Title3が存在する。TopMenuはリモコンのメニューキーを押したときやタイトル再生が終了したときに再生されるタイトルであり、主にタイトルの選択や、字幕音声の言語選択を行うことに用いられる。このタイトルの選択がなされるとBDJオブジェクト99999bdjoに含まれるアプリケーション管理テーブルに従い、アーカイブファイルにて定義されメニュー表示BDJアプリケーションの起動が、再生装置に命じられる。FirstPlayはBD起動時に自動的に再生されるタイトルであり、主にBDの利用規約表示などに用いられる。Title1は、例えば本編映像のタイトルであり、このタイトルの選択がなされるとBDJオブジェクト00001bdjoに含まれるプレイリストアクセス情報に従い、プレイリスト情報ファイルを用いてデジタルストリームの再生が行われる。BDJオブジェクト00001bdjoに含まれるアプリケーション管理テーブルに従い、アーカイブファイルにて定義される本編再生BDJアプリケーションの起動が、再生装置に命じられる。Title2は、例えば特典映像のタイトルであり、このタイトルの選択がなされるとBDJオブジェクト00002bdjoに含まれるプレイリストアクセス情報に従い、プレイリスト情報ファイルを用いてデジタルストリームの再生が行われる。Title3は、例えばデジタルコピーに対応するタイトルであり、このタイトルの選択が行われると、デジタルコピーのGUI等を管理するデジタルコピー管理BDJアプリケーションのアーカイブファイルと、オンメディアライブラリのアーカイブファイルとがロードされる。このオンメディアライブラリのアーカイブファイルの中には、eMoveLibraryclassというクラスファイルが存在し、デジタルコピー管理BDJアプリケーションには、このクラスファイルを取り込む旨の宣言文ClassPass=eMoveLibraryが存在する。この宣言によって、デジタルコピー管理BDJアプリケーション内のAPIコールと、オンメディアライブラリ内のAPIとのリンクがなされる。ここで、Title3を構成するデジタルコピー管理BDJアプリケーションとオンメディアライブラリ28とは、別々のアーカイブファイルに分けて記録しても良いし、1つのJARファイルにまとめて記録しても良い。上述に示す例は単なる一例である。例えばTitle1に対応付けられたBDJオブジェクトに含まれるプレイリストアクセス情報にプレイリストが示されなければ、デジタルストリームの再生は行われない。また、Title3に対応付けられたBDJオブジェクトに含まれるプレイリストアクセス情報に再生可能なプレイリストを示せば、アプリケーション管理テーブルに示されるBDJアプリおよびオンメディアライブラリ28の実行と並行して、BDJオブジェクトに含まれるプレイリストアクセス情報に従うプレイリスト再生が再生装置で行われることになる。図13bは、各タイトルのBDJオブジェクトにおけるアプリケーション管理テーブルの内容、プレイリストアクセス情報の内容を示す。TopMenuに対応するBDJオブジェクト99999bdjoに含まれるアプリケーション管理テーブルには、メニュー表示BDJアプリケーションの識別番号である99999が記載されている。よって、TopMenuの選択がなされるとBDJオブジェクト99999bdjoに含まれるアプリケーション管理テーブルに従い、アーカイブファイルにて定義されるメニュー表示BDJアプリケーションの起動が再生装置に命じられる。Title1に対応するBDJオブジェクト00001bdjoに含まれるアプリケーション管理テーブルには、本編再生BDJアプリケーションの識別番号である00001が記載されている。よって、Title1の選択がなされるとBDJオブジェクト00001bdjoに含まれるアプリケーション管理テーブルに従い、アーカイブファイルにて定義される本編再生BDJアプリケーションの起動が再生装置に命じられる。また、BDJオブジェクト00001bdjoに含まれるプレイリストアクセス情報には、プレイリスト情報ファイルの識別番号である00001が記載されている。よって、Title1の選択がなされると、プレイリスト情報ファイルを用いたストリームファイルの再生が再生装置に命じられる。Title2に対応するBDJオブジェクト00002bdjoに含まれるアプリケーション管理テーブルには、特典映像BDJアプリケーションの識別番号である00002が記載されている。よって、Title3の選択がなされるとBDJオブジェクト00002bdjoに含まれるアプリケーション管理テーブルに従い、アーカイブファイルにて定義される特典映像BDJアプリケーションの起動が再生装置に命じられる。また、BDJオブジェクト00002bdjoに含まれるプレイリストアクセス情報には、プレイリスト情報ファイルの識別番号である00002が記載されている。よって、Title1の選択がなされると、プレイリスト情報ファイルを用いたストリームファイルの再生が再生装置に命じられる。Title3に対応するBDJオブジェクト88888bdjoに含まれるアプリケーション管理テーブルには、デジタルコピー管理BDJアプリの識別番号であると、オンメディアライブラリ28の識別番号である11111とが記載されている。よって、Title3の選択がなされるとBDJオブジェクト88888bdjoに含まれるアプリケーション管理テーブルに従い、アーカイブファイルにて定義されるデジタルコピー管理BDJアプリケーションの起動と、アーカイブファイルにて定義されるオンメディアライブラリ28の起動とが再生装置に命じられる。以上の具体例においてオンメディアライブラリ28及びデジタルコピー管理BDJアプリケーションは、Title3にのみ存在し、Title3のBDJオブジェクトにおけるアプリケーション管理テーブルに、これらオンメディアライブラリ28及びデジタルコピー管理BDJアプリケーションは記載されている。よって、Title3のタイトル番号がタイトル番号レジスタに設定され、Title3がカレントタイトルになった際、オンメディアライブラリ28及びデジタルコピー管理BDJアプリケーションについて、クラスロードがなされ、オンメディアライブラリ28及びデジタルコピー管理BDJアプリケーションは、バイトコードインタプリタによる実行に供される。一方、オンメディアライブラリ28、デジタルコピー管理BDJアプリケーションは、Title1、Title2の構成要素ではなく、Title1、Title2のアプリケーション管理テーブルには記述されていないので、Title3の再生が終了して、Title1又はTitle2の再生が開始した際、オンメディアライブラリ28及びデジタルコピー管理BDJアプリケーションの動作は終了する。以上のように、オンメディアライブラリ28及びデジタルコピー管理BDJアプリケーションは、タイトルを生存区間としたアプリケーションシグナリングに供されることになる。このように、オンメディアライブラリ28の生存区間を、デジタルコピー管理BDJアプリケーションの生存区間と同じとするこの例では、Title3の開始時点から終了時点までの間がオンメディアライブラリ28およびデジタルコピー管理BDJアプリケーションの実行可能な生存区間とすることで、オンメディアライブラリ28の生存区間と異なる生存区間のBDJアプリケーションこの例では、Title3とは異なるTitle1、またはTitle2のアプリケーション管理テーブルにのみ記載されるBDJアプリケーションがオンメディアライブラリ28を利用することを制限することができる。以上のように本実施形態によれば、機器固有機能制御部33を制御するためのオンメディアライブラリ28やこのオンメディアライブラリ28を用いて機器固有機能を実行するデジタルコピー管理BDJアプリケーション、機器固有機能の対象となるSDVideoコンテンツがBDROMに記録されてユーザに供給されるので、ユーザは、パソコンを利用することなく、BDROMが再生装置に装填されている状態のまま、デジタルコピーを実行することができる。本実施形態では、機器固有機能制御部33のコマンド処理部609が解釈可能なコマンドの種別について説明する。コマンド処理部609が解釈可能なコマンドとしては、以下のものがある。1初期化要求コマンド初期化要求コマンドは、デジタルコピーモジュール35を初期化し、他のソケットコマンドを使用可能な状態にする。もし一旦初期化がなされれば、幾つかのパラメータはリセットされる。コマンドが再度実行され、その実行に成功した際、これらのパラメータは、リセットされる。このコマンドは、転送中、転送後、ファイナライジングの何れかの状態において有効となる。このコマンドのレスポンスには、OKレスポンス、フェータルエラーレスポンスがある。OKレスポンスは、デジタルコピーモジュール35の初期化及びアクティベートを示す。フェータルエラーは、フェータルエラーのために初期化が失敗したことを示す。2チェックチケットコマンドチェックチケットコマンドは、コピーチケットを、コピーのためにパラメータ設定コマンドで設定されたパラメータを用いてデジタルコピーサーバ36にコピーチケットをチェックさせることを要求する。このコマンドがコールされる前に、プロセスで必要な全てのパラメータは、設定コマンドで設定されねばならない。コピーチケットをチェックした後、オンメディアライブラリ28は、コピーコマンドでデータ転送の実行を要求することができる。このコマンドは、デジタルコピーモジュール35が初期化状態、レディ状態にある際に発行することができる。このコマンドには引数はない。レスポンスには、OKレスポンス、インバリッドエラーレスポンス、接続エラーレスポンスがある。ビジーエラーレスポンスがある。OKレスポンスは、コピーチケットのチェックが受け入れられたことと、デジタルコピーモジュール35がチケットレスポンスの受信に成功したことを示す。インバリッドエラーレスポンスは、プロセスのためのパラメータのうち、幾つかが未設定であり、チェックチケットに失敗したことを示す。接続エラーレスポンスは、レスポンスがデジタルコピーサーバ36に到達しないか、又は、デジタルコピーサーバ36から正しい応答を受け取っていないことを示す。ビジーエラーレスポンスは、BDROMがAV再生プロセスのためにロックされていて、デジタルコピーモジュール35がBDROMをアクセスすることができないことを示す。このエラーは、BDROM再生プロセスとは異なるプロセスで、デジタルコピーモジュール35が実行されている際、発生する。このエラーコードがリターンした際、オンメディアライブラリ28はこのコマンドの代わりにチェックチケットバイデータフィード要求を試みねばならない。フェータルエラーレスポンスは、フェータルエラーのために、チケット要求が失敗したことを示す。3チェックチケットバイデータフィードコマンドチェックチケットバイデータフィードコマンドは、コピーチケットを、コピーのためにパラメータ設定コマンドで設定されたパラメータを用いてデジタルコピーサーバ36にチェックさせることを要求する。このコマンドがコールされる前に、プロセスで必要な全てのパラメータは、設定コマンドで設定されねばならない。チケットをチェックした後、オンメディアライブラリ28は、コピーコマンドでデータ転送の実行を要求することができる。このコマンドは、デジタルコピーモジュール35が初期化状態、レディ状態にある際に発行することができる。このコマンドがコールされた際、設定コマンドで設定されたソースロケーションは無視され、このコマンドで特定されたバイナリデータを、ターゲット情報ファイルとして用いて、特定されたバイナリデータを使用する。このコマンドは、チェックチケット要求がビジーエラーで返る場合のみコールされる。よって、チェックチケット要求がビジーエラーで返る可能性がない場合、デジタルコピーモジュール35はこのコマンドを実装にする必要はない。引数は、情報ファイルの長さ、情報ファイルである。レスポンスとしては、OKレスポンス、インバリッドエラーレスポンス、接続エラーレスポンス、フェータルエラーレスポンスがある。OKレスポンスは、状態番号、残りコピー回数である。OKレスポンスは、コピーチケットのチェックが受け入れられたことと、デジタルコピーモジュール35がチケットレスポンスの受信に成功したことを示す。インバリッドエラーレスポンスは、プロセスのためのパラメータのうち、幾つかが未設定であり、コピーチケットのチェックに失敗したことを示す。接続エラーレスポンスは、レスポンスがデジタルコピーサーバ36に到達しないか、又は、デジタルコピーサーバ36から正しい応答を受け取っていないことを示す。ノーサポートレスポンスは、デジタルコピーモジュール35がこのコマンドをサポートしていないことを示す。チケットチェック要求がビジーで返る可能性がない場合、デジタルコピーモジュール35はこのコマンドを実装にする必要はなく、ノーサポートエラーレスポンスを返す。チケットチェック要求がビジーでリターンする可能性がある場合、デジタルコピーモジュール35はこのコマンドを実装して、ノーサポートレスポンスを返すべきではない。フェータルエラーレスポンスは、フェータルエラーのために、チケット要求が失敗したことを示す。4コピー要求コマンドコピー要求コマンドは、出力装置設定コマンドで設定されたセキュアなメモリカード104にコンテンツを出力する。このコマンドは非同期であり、オンメディアライブラリ28は、進捗取得コマンドを通じてこの転送プロセスをチェックすることができる。転送プロセス中にAV再生が実行された場合、AV再生が終わるまで、コピー速度が減じられ、データ転送プロセスは一時停止する。コピープロセスは、キャンセル要求がインボークされた場合、クローズ要求がインボークされた場合、BDROMがイジェクトされた場合、キャンセルされる。キャンセル後に、部分的にコピーされたデータをクリアするかどうかは実装マターとなる。このコマンドがコールされる前に、チェックチケット要求コマンドによってコピーチケットのチェックがなされねばならない。このコマンドは、レディ状態で有効になる。このコマンドのレスポンスには、OKレスポンス、フェータルエラーレスポンスがある。OKレスポンスは、コピー要求が受け入れられ、デジタルコピーモジュール35がコンテンツのコピーを開始した際に発行される。フェータルエラーレスポンスは、デジタルコピーモジュール35がコピーに失敗した旨を示す。5コピーバイデータフィード要求コマンドコピーバイデータフィード要求コマンドは、出力装置設定コマンドで特定されたセキュアなメモリカード104に、コンテンツを出力する。このコマンドは、非同期であり、オンメディアライブラリ28は、プロセス取得コマンドを介してコピー進捗をチェックすることができる。転送中にAV再生が実行された場合、AV再生が終了するまで、コピー速度は減少するか停止する。このコピープロセスは、キャンセル要求がインボークされた場合、クローズ要求がインボークされた場合、BDROMがイジェクトされた場合、キャンセルされる。キャンセル後、部分的にコピーされたデータをクリアするかどうかは実装マターである。このコマンドがコールされる前に、チェックチケットコマンドのチェックがなされなければならない。このコマンドは、デジタルコピーモジュール35がレディ状態にある場合のみ有効となる。このコマンドがコールされた場合、ソースロケーションコマンドで設定されたソースロケーションは無視され、データフィード要求コマンドで特定されたバイナリデータをターゲットコンテンツとして用いる。このコマンドはコピー要求がビジーでリターンした場合のみコールされる。よって、このコマンドは、コピー要求がビジーエラーでリターンする可能性はない。デジタルコピーモジュール35はこのコマンドを実装にする必要はない。引数としては、管理データファイル、プログラム管理ファイル、プログラムファイル、ムービーファイルがある。このコマンドに対するレスポンスには、OKレスポンス、ノーサポートレスポンス、フェータルエラーレスポンスがある。OKレスポンスは、コピー要求が受け入れられ、コンテンツのコピーをデジタルコピーモジュール35に開始させることを示す。ノーサポートレスポンスは、デジタルコピーモジュール35がこのコマンドをサポートしていないことを示す。コピー要求がビジーエラーでリターンする可能性がない場合、デジタルコピーモジュール35はこのコマンドを実装にする必要はなく、ノーサポートエラーをリターンすればよい。デジタルコピーモジュール35は、このコマンドを実装して、ノーサポートエラーをリターンしなくてもよい。フェータルエラーレスポンスは、フェータルエラーによって、コピーを開始させることはできないことを示す。6データフィード要求コマンドデータフィード要求コマンドは、コピーのために特定されたデータブロックのコピーを開始させる。オンメディアライブラリ28は、このコマンドを、コピーバイデータフィード要求が成功した場合のみ、コールすることができる。同じファイル名のファイルが連続して特定された場合、オンメディアライブラリ28は、特定したファイルにデータを追加する。オンメディアライブラリ28は、複数のファイルのコピーを連続して要求せねばならない。カレントファイルのコピーを完了する前に、他のファイルを特定すべきではない。データブロックのサイズは、64Kバイト以下でなければならない。ファイルの終わりに到達すれば、データブロックの長さを0とする。引数となるのは、BDROMに記録されたファイルのファイル名、データブロック長、データブロックのバイナリデータである。OKレスポンスは、データブロックのコピーがサクセスした旨を示す。ノーサポートレスポンスは、デジタルコピーモジュール35がこのコマンドをサポートしていない旨を示す。フェータルエラーレスポンスは、デジタルコピーモジュール35がコピーに失敗した旨を示す。転送状態でこのエラーが発生した場合、デジタルコピーモジュール35は停止状態に移行せねばならない。7キャンセル要求コマンドキャンセル要求コマンドは、カレントのプロセスのキャンセルを要求する。もしカレントのプロセスのキャンセルに成功した場合、部分的にコピーされたデータは、セキュアなメモリカード104から削除される。このコマンドは、デジタルコピーモジュール35が転送中/転送後状態にある場合のみ有効になる。8ファイナライズ要求コマンドファイナライズ要求コマンドは、キーダウンロードと、プロセスのファイナライズとをデジタルコピーモジュール35に要求する。デジタルコピーモジュール35が一旦ファイナライズを開始すれば、オンメディアライブラリ28はファイナライズをキャンセルすることはできない。レスポンスとしては、OKレスポンス、接続エラーレスポンス、フェータルエラーレスポンスがある。OKレスポンスは、デジタルコピーサーバ36がキーダウンロード要求を受け入れ、デジタルコピーモジュール35がキーダウンロードレスポンスの受け入れに成功したことを示す。接続エラーレスポンスは、デジタルコピーモジュール35がデジタルコピーサーバ36に到達できないこと、正しいレスポンスがデジタルコピーサーバ36からのレスポンスではなかったことを示す。フェータルエラーレスポンスは、フェータルエラーのためにキーダウンロード要求が失敗したことを示す。9クローズ要求コマンドクローズ要求コマンドは、クローズ操作を完了した後、デジタルコピーモジュール35をクローズし、プロセスのためのリソースを開放して、デジタルコピーモジュール35は非初期化状態に戻ることをデジタルコピーモジュール35に命じるコマンドである。このコマンドは、どのステートでもコールされる。最終状態でこのコマンドがコールされた場合、最終プロセスが完了するまで、クローズ操作はブロックされる。転送中又は転送後状態でこのコマンドがコールされた場合、キャンセル操作が実行され、クローズ操作が開始する。レスポンスとしては、クローズが成功した旨を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すFATALレスポンスがある。10サーバURL設定コマンドサーバURL設定コマンドは、コピープロセスのために接続すべきデジタルコピーサーバ36のURLを設定する。このコマンドが成功完了した際、直前のサーバURLは、新たなサーバURLによって上書きされる。レスポンスとしては、プロセスにおいてサーバURLの設定が成功した旨を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すフェータルレスポンスがある。空白文字が特定された場合、以前設定したURLが有効になる。11ソースロケーション設定コマンドソースロケーション設定コマンドは、コピーすべきコンテンツのソースロケーションを設定する。このソースロケーションは、リードオンリーメディア105上に存在せねばならない。このコマンドが成功完了した際、直前のソースロケーションは、新たなソースロケーションによって上書きされる。引数は、インサートされたリードオンリーメディア105におけるディレクトリを示す絶対パスである。ソースロケーション設定のためのパス名は、mntbdromEMOVEDATA01にエンクローズされねばならない。特定されたファイルパスは、有効なコンテンツを含む必要がある。レスポンスとしては、コピープロセスにおいてソースロケーションの設定が成功した旨を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すフェータルエラーレスポンス、インバリッドレスポンスの何れかがある。OKレスポンスは、プロセスのために設定に成功した位置を示す。インバリッドレスポンスは、特定されたパス名が実在するディレクトリを特定していない、特定されたディレクトリがBDROMに位置していない、特定されたディレクトリが有効なコンテンツを有していないという理由で発生する。12シリアルID設定コマンドシリアルID設定コマンドは、このコピープロセスのために特定されたシリアルIDを設定する。シリアルIDが設定済みである場合、このコマンドが成功完了した際、直前のシリアルIDは、新たなシリアルIDによって上書きされる。レスポンスとしては、プロセスにおいてシリアルIDの設定が成功した旨を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すレスポンスの何れかがある。13出力装置設定コマンド出力デバイス設定コマンドは、コピープロセスのためのドライブデバイスのスロットを設定する。スロットが設定済みである場合、このコマンドが成功完了した際、直前のターゲットスロットは、新たなスロットによって上書きされる。レスポンスとしては、プロセスにおいて成功設定した出力装置を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すレスポンスの何れかがある。14レジューム設定コマンドレジューム設定コマンドは、プロセスのためのレジューム点を特定する。このコマンドによってレジューム点が特定された場合、デジタルコピーモジュール35は、プロセスの完了後にセキュアなメモリカード104の管理データファイルを更新する。これは、レジューム点からSZDATAVコンテンツを再生するためである。レジューム点が設定されれば、このコマンドが成功完了した際、直前のレジューム点が新たなレジューム点によって上書きされる。レジューム点は、完了状態においてのみ、ターゲットのセキュアなメモリカード104に反映される。完了状態において、このコマンドがコールされれば、即座に、ターゲットセキュアなメモリカード104に反映される。引数としては、秒単位のオフセットを指定することができる。レスポンスとしては、プロセスにおいて成功設定したレジューム点を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すレスポンスの何れかがある。15リボケーションリスト設定コマンドリボケーションリスト設定コマンドは、デバイスリスト長と、リボケーションリストデバイスリストとをオペランドで指定する。このコマンドは、デジタルコピーモジュール35にリボケーションリストを設定する。リボケーションリストとは、過去に不正なコピー行為をしたとして、マークされている不正再生装置のリストであり、セキュアなメモリカード104に実装されている認証回路との処理認証で使用される。これは、リボケーションリストに示されている不正再生装置に、デジタルコピーを実行させないためである。チェックチケット要求コマンドをコールする前に、オンメディアライブラリ28は、リボケーションリストをデジタルコピーモジュール35にセットしなければならない。リボケーションリストが既に設定されている場合、前のリボケーションリストは、上記コマンドがサクセスした際、新たなリボケーションリストによって上書きされる。レスポンスとしては、プロセスのためにリボケーションリスト設定が成功したことを示すOKレスポンス、知名エラーのためにコマンドが失敗したことを示すFATALレスポンスがある。16デバイスデバイスリスト取得コマンドデバイスデバイスリスト取得コマンドは、プロセスのために再生装置によってサポートされているセキュアなメモリカード104スロットのデバイスリストを取得する。このコマンドのレスポンスは、以下の形式であり、Xに番号付けされたカードスロット、USB接続を通じてXに番号付けされたカードスロット、Xに番号付けされたその他の装置を羅列したものである。レスポンスは、コマンドが成功完了したことを示す。複数のスロットの1つとして位置付けられているローカルストレージは、その名称が、レスポンスメッセージの終わりで指示される。17デバイス情報取得コマンドデバイス情報取得コマンドは、特定されたスロットにインサートされたセキュアなメモリカード104の総容量/有効容量を取得する。このスロット名は、デバイスデバイスリスト取得コマンドで取得したものの1つであり、レスポンスとしては、総スペース、フリースペース、プログラム数がある。デバイス情報取得コマンドがサクセスした場合、ターゲットセキュアなメモリカード104がインサートされ、有効である場合、レスポンスされたメッセージは、総容量/有効容量、プログラム数を含む。18進捗取得コマンド進捗取得コマンドは、データ転送の進捗状況情報を取得する。レスポンスとしては、残りサイズ/総サイズとなる。未転送であれば、単にOKのみを返す。転送完了であれば、0/総サイズが返される。転送プロセスが停止又はキャンセルされれば、コピーされた総サイズが返される。19状態取得コマンド状態取得コマンドは、未初期化、初期化、レディ、転送中、転送後、ファイナライジング、完了、キャンセル、ストップの何れかを示す。20パラメータ取得コマンドパラメータ取得コマンドは、カレントステート、カレントソースロケーション、カレント出力デバイス、カレントサーバURL、カレントシリアルID、カレントレジューム点を取得するためのコマンドである。幾つかのパラメータが存在しない場合、空白文字列が返ることになる。その他、コマンド送信とは関係なく、非同期に、オンメディアライブラリ28に出力されるイベントには、以下の非同期イベントがある。ここでの非同期イベントには、セキュアなメモリカード104が装填されたことを示す非同期デバイス状態インサートイベント、セキュアなメモリカード104がイジェクトされたことを示す非同期装置状態イジェクトイベント、非同期状態変化イベントがある。非同期状態変化イベントは、セキュアなメモリカード104の容量無し、セキュアなメモリカード104のライトプロテクト、セキュアなメモリカード104のIOエラーの発生を通知する。非同期状態変化イベントは、以下のiiiに該当する場合を除き、デジタルコピーモジュール35の状態が変化した際に発生する。iデジタルコピーモジュール35の状態は変化していないのにデジタルコピーモジュール35が初期化されてサクセス非同期状態変化イベントが初期化状態を示す場合。iiデジタルコピーモジュール35の状態が変化していないのにデジタルコピーモジュール35がレディ状態となってチェックチケット要求コマンドがサクセスし、レディ状態を示す非同期状態変化イベントが発生した場合。以上のコマンドを用いてデジタルコピーを実現するための具体的な通信シーケンスについて説明する。図14は、アプリ内API呼出しの詳細を示すシーケンス図である。このシーケンスは、オンメディアライブラリ28APIを用いて記述されている。本図の横方向には、デジタルコピー管理BDJアプリ、オンメディアライブラリ28、デジタルコピーモジュール35が、それぞれ配置されている。縦方向には、複数の時間軸を描いている。時間軸上の各時点が、メッセージの送受信のタイミングとなる。本図におけるシーケンスは、a機器確認フェーズ、b初期化フェーズ、cコピー先状態確認フェーズ、dパラメータセットフェーズ、e残コピー回数確認フェーズ、fコピー開始フェーズ、gコピー進捗確認フェーズ、h鍵書込みフェーズからなる。a機能確認フェーズは、BDJアプリケーションがBCManagergetInstanceAPIを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥというアプリケーション間通信によって構成される。BCManagergetInstanceAPIは、デジタルコピーモジュール35を制御するための各種メソッドを持つBCManagerクラスのインスタンスを取得する。再生装置がデジタルコピーに対応していなかった場合はUnsupportedOperationExceptionをスローする。b初期化フェーズは、BDJアプリケーションがBCManageraddBCStatusChangeListenerAPIを呼び出すAPIコール、BCManagerinitialBCを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるBCManagerInitialEventイベントのスロゥというアプリケーション間通信によって構成される。BCManageraddBCStatusChangeListenerAPIは、デジタルコピーモジュール35の状態変化をモニタリングするためのAPIである。デジタルコピーモジュール35の状態変化を検知すると、変化した状態をBDJアプリケーションへ通知する。BCManagerinitializeBCAPIは、デジタルコピーモジュール35の初期化を行うためのAPIである。このAPIが呼ばれると、オンメディアライブラリ28は、デジタルコピーモジュール35との接続を行う。接続に失敗した場合は、UnsupportedOperationExceptionをスローする。初期化が成功すれば、BCInitializedEventをBDJアプリケーションに通知する。cコピー先状態確認フェーズは、BDJアプリケーションがBCManagergetDeviceListAPIを呼び出すAPIコール、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥ、BDJアプリケーションがBCOutputDevicegetFreeSpaceAPIを呼び出すAPIコール、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥというアプリケーション間通信によって構成される。BCManagergetDeviceListAPIは、再生装置がコピー先としてサポートしているメディア一覧SDカード、USBメモリを取得するためのAPIである。それぞれのメディアはBCOutputDeviceクラスのインスタンスとして表現される。BCOutputDeviceクラスはインスタンスが示すメディアの種類と番号SD1、USB1を取得するメソッド、空き容量を取得するメソッドBCOutputDevicegetFreeSpace、及びトータル容量を取得するメソッドBCOutputDevicegetTotalSpaceを持つ。図14では、空き容量を取得するメソッドBCOutputDevicegetFreeSpaceの呼び出しに対する応答として、空き容量の一例として10737418240byteを返している。dパラメータセットフェーズは、BCManagersetServerURLAPIを呼び出すAPIコール、BCManagersetSourceLocationAPIを呼び出すAPIコール、BCManagersetOutputDeviceAPIを呼び出すAPIコール、BCManagersetSerialIdAPIを呼び出すAPIコールから構成される。dパラメータセットフェーズでセットされるパラメータは、具体的には、シリアルID,コピー元のコンテンツの位置、デジタルコピーサーバ36のURL、コピー先のメディアである。コンテンツIDはコピー対象の携帯端末向け保護コンテンツのEMOVINFファイルに記載されている値をもちいる。コピー元のコンテンツの位置は、携帯端末向けコンテンツが記録されているディレクトリまでの絶対パスで示される。例えば、mntbdromEMOVEDATA01等である。この場合、mntbdromはBDROMメディアのマウントポイントに当たる。デジタルコピーサーバ36のURLは、グローバルネットワーク上のサーバを示すURLが指定される。例えばhttpxxxyyyzzz等である。コピー先メディアは、再生装置がサポートしているコピー先メディア一覧の中から指定される。BDJアプリケーションはデジタルコピーモジュール35に対し、現在の再生装置でサポートしているメディア一覧を要求すると、<メディアの種類><番号>の形のリストが送られてくる。例えば、再生装置がSDカードスロットとUSBメモリスロットの両方をそれぞれ、1つずつサポートしていた場合、SD1USB1というリストが送られてくる。SDカードスロットなし、USBメモリスロットが2つ持つ場合はUSB1USB2というリストが送られることとなる。コピー先一覧を受け取ったBDJアプリケーションは、それらの一覧をユーザに提示し、どのメディアにコピーするか、ユーザの指示を受け、ユーザが選択したメディアを、コピー先メディアとして指定することになる。BCManagersetServerURLAPIは、デジタルコピーモジュール35へデジタルコピーサーバ36のURLをセットするするためのAPIである。BCManagersetSourceLocationは、デジタルコピーモジュール35へコピー元のコンテンツ位置をセットするためのAPIである。コンテンツ位置は、携帯端末向けコンテンツが記録されているディレクトリまでの絶対パスで示されるmntbdromEMOVEDATA01等。BCManagersetOutputDeviceは、デジタルコピーモジュール35へコピー先メディアをセットするためのAPIである。コピー先メディアはBCManagergetDeviceListで取得できたメディアリストの中から選択される。BCManagersetSerialIdは、デジタルコピーモジュール35へシリアルIDをセットするためのAPIである。e残コピー回数確認フェーズは、BDJアプリケーションがBCManagercheckTicketを呼び出すAPIコール、及び、その呼び出しに対するイベントスロゥというアプリケーション間通信によって構成される。BCManagercheckTicketAPIは、残コピー回数確認をデジタルコピーモジュール35へ要求するためのAPIである。デジタルコピーモジュール35は残コピー回数の確認が要求されると、現在セットされているパラメータを用いてデジタルコピーサーバ36へ残コピー回数の問い合わせを行う。得られた残コピー回数はBCCheckResponseクラスのインスタンスとしてBDJアプリケーションにリターンされる。BDJアプリケーションはBCCheckResponseremainingTimesOfCopyを呼び出すことで残コピー回数を確認することができる。また、残コピー回数が1回以上残っていれば、BCReadyEventがBDJアプリケーションに通知される。fコピー開始フェーズは、BDJアプリケーションがBCManagermakeCopyAPIを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥというアプリケーション間通信によって構成される。BCManagermakeCopyAPIは、デジタルコピーモジュール35へコピー開始を要求するためのAPIである。オンメディアライブラリ28はデジタルコピーモジュール35へコピー開始を要求した後、BDJアプリケーションには進捗状況を示すBCProgressインスタンスをリターンし、コピー処理はデジタルコピーモジュール35において非同期で行われる。gコピー進捗確認フェーズは、BDJアプリケーションがBCProgressremainingAPIを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥ、BDJアプリケーションがBCProgresstotalAPIを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥ、というアプリケーション間通信によって構成される。BCProgresstotalは、これまでコピーしたトータルのコピーバイト数を取得するためのAPIである。BCProgressremainingは、残りのコピーバイト数を取得するためのAPIである図14では、BCProgressremainingの呼び出しに対する応答としての残りのコピーバイト数の一例として524288000byteを返している。コピー処理が完了するとBCTransferredEventがBDJアプリケーションに通知される。h鍵書込みフェーズは、BDJアプリケーションがBCManagerfinalizeBCAPIを呼び出すAPIコール、及び、その呼び出しに対するイベントスロゥというアプリケーション間通信、BDJアプリケーションがBCManagercancelCopyを呼び出すAPIコール、及び、その呼び出しに対するイベントスロゥ、BDJアプリケーションがBCManagercloseAPIを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるBCManager又はUnsupportedOperationExceptionをスローするというイベントスロゥというアプリケーション間通信によって構成される。BCManagerfinalizeBCは、デジタルコピーモジュール35へ復号鍵の書込みを要求するためのAPIである。復号鍵の書込みが完了するとBCCompleteEventがBDJアプリケーションに通知される。BCManagercancelCopyは、デジタルコピーモジュール35のコピー処理をキャンセルするためのAPIである。キャンセルに成功するとBCCancelEventがBDJアプリケーションに通知される。BCManagercloseは、デジタルコピーモジュール35が確保しているリソースを開放し、デジタルコピープロセスを終了するためのAPIである。以上が、オンメディアライブラリ28、デジタルコピーモジュール35、デジタルコピーサーバ36間の通信シーケンスについての説明である。続いて、の詳細について、図15は、デジタルコピーモジュール35の状態遷移を示す図である。デジタルコピーモジュール35はデジタルコピープロセスの進捗に応じて以下9個の状態を遷移する。本図における丸枠は、デジタルコピーモジュール35が取りうる状態を模式的に示し、矢印は、状態遷移のトリガとなるべき事象を意味する。この矢印に付された注釈が、状態遷移のトリガになる事象の具体的な名称である。本図に示された機器固有機能制御部33の各状態について説明する。NOTINIT:この状態はデジタルコピーモジュール35がまだ初期化されていないことを示す。この状態はBDROMがロードされた時点でのデジタルコピーモジュール35の初期状態である。他の状態においてBDJアプリケーションがBCManagercloseを呼び出し、デジタルコピープロセスを終了した場合、デジタルコピーモジュール35は再びNOTINIT状態に戻る。この状態でBCManagerinitializeBCが呼ばれると、INITIALIZED状態に遷移し、BDJアプリケーションへはBCInitializedEventが通知される。INITIALIZED:この状態はデジタルコピーモジュール35が初期化され、BDJアプリケーションからデジタルコピープロセスの機能を呼び出せる状態であることを示す。この状態で、BDJアプリケーションが必要パラメータ例えば、BCManagersetServerURLの呼び出しにより設定されるデジタルコピーサーバ36のURL、BCManagersetSourceLocationの呼び出しにより設定されるコピー元のソースロケーション、BCManagersetOutputDeviceの呼び出しにより設定されるコピー先メディア、BCManagersetSerialIdにより設定されるシリアルIDをセットし、BCManagercheckTicketを呼び出して残コピー回数が1回以上残っていた場合はREADY状態に遷移し、BDJアプリケーションへはBCReadyEventが通知される。残コピー回数が残っていなかった場合は、READY状態には遷移せず、INITIALIZED状態のままとなる。デジタルコピープロセス実行後、READY,CANCELED,STOPPED,もしくはCOMPLETED状態においてBDJアプリケーションからBCManagerinitializeBCが呼ばれると、再びINITIALIZED状態に遷移し、BDJアプリケーションへはBCInitializedEventが通知される。READY:この状態はデジタルコピープロセスに必要なパラメータが全てセットされ、かつそれらが有効であり、デジタルコピーモジュール35のコピー準備が整ったことを示す。この状態でBCManagermakeCopyが呼ばれると、TRANSFERRING状態へ遷移する。TRANSFERRING:この状態は携帯端末向け保護コンテンツのデータコピーが開始されたことを示す。携帯端末向け保護コンテンツのデータコピーが完了するとTRANSFERRED状態へ遷移し、BDJアプリケーションへはBCTransferredEventが通知される。また、データコピー完了前にBCManagercancelCopyが呼ばれると、データコピーはキャンセルされ、CANCELED状態に遷移し、BDJアプリケーションへはBCCancelEventが通知される。データコピー中にコピー先メディアが取り出される等により、エラーが発生した場合はSTOPPED状態に遷移し、BDJアプリケーションへはBCStopByErrorEventが通知される。TRANSFERRED:この状態は携帯端末向け保護コンテンツのデータコピーが完了し、デジタルコピーモジュール35において復号鍵書込み準備が整ったことを示す。この状態でBCManagerfinalizeBCが呼ばれると、デジタルコピーモジュール35はFINALIZING状態へ遷移する。また、この状態でBCManagercancelCopyが呼ばれると、CANCELED状態に遷移し、BDJアプリケーションへはBCCancelEventが通知される。FINALIZING:この状態は、デジタルコピーサーバ36から復号鍵の取得、及びコピー先メディアへ取得した復号鍵の書込み処理が行われていることを示す。一旦この状態に入ると、BDJアプリケーションはBCManagercancelCopyを呼んでもキャンセルできず、キャンセル要求は拒否されることになる。復号鍵書込み中にコピー先メディアが取り出される等により、エラーが発生した場合はSTOPPED状態に遷移し、BDJアプリケーションへはBCStopByErrorEventが通知される。復号鍵の書込みが完了すると、デジタルコピーモジュール35はCOMPLETED状態へ遷移し、BDJアプリケーションへはBCCompleteEventが通知される。COMPLETED:この状態は、携帯端末向け保護コンテンツのデータコピー及び対応する復号鍵の書込みが完了し、デジタルコピープロセスが成功したことを示す。この状態で、BCManagerinitializeBCが呼ばれると、再びINITIALIZED状態に遷移し、BDJアプリケーションへはBCInitializedEventが通知される。CANCELED:この状態は、携帯端末向け保護コンテンツのデータコピーが途中でキャンセルされたことを示す。途中までコピー済みのデータは、CANCELED状態への遷移時にクリアされる。STOPPED:この状態は、エラー発生により、データコピーもしくは復号鍵書込みが失敗したことを示す。エラー発生の原因としては、空き容量不足、コピー先メディアが書き込み保護されているため、書込みできない、コピー先メディアが途中で取り出された、コピー先メディアが破損しておりIOエラーが発生した等が考えられる。どの原因でコピーに失敗したかは、STOPPED状態遷移時に発生するBCStopByErrorEventインスタンスに詳細情報が記録されており、BDJアプリケーションはBCStopByErrorEventを通してエラー原因を把握することができる。以上がデジタルコピー実行の際に、BDJアプリケーションとオンメディアライブラリ28間でやり取りされるAPI呼び出しの内容である。各フェーズのAPI呼出しのそれぞれに対応して、モジュールには、デジタルコピーソケットコマンドが送信される。このコマンドを用いれば、図8における端末内ローカル通信は、図16のシーケンス図のように詳細化される。図16は、端末内ローカル通信の詳細を示すシーケンス図であり、オンメディアライブラリ28とデジタルコピーモジュール35間でやり取りを行うデジタルコピーソケットプロトコルの一例を示す。このシーケンスは、デジタルコピーソケットコマンドを用いて記述されている。本図の横方向には、オンメディアライブラリ28、デジタルコピーモジュール35が、それぞれ配置されている。縦方向には、複数の時間軸を描いている。時間軸上の各時点が、コマンド及びレスポンスの送受信のタイミングとなる。本図に示したコマンド及びレスポンスは、これらの時間軸間を行き来する。このシーケンスは、b初期化フェーズ、cコピー先状態確認フェーズ、dパラメータセットフェーズ、e残コピー回数確認フェーズ、fコピー開始フェーズ、gコピー進捗確認フェーズ、h鍵書込みフェーズからなる。図16では、例えば再生装置がSDカードスロットのみをサポートするような構成である場合を例に説明を行う。b初期化フェーズは、REQUESTINITIALIZEコマンドの送信と、レスポンスの受信というコマンドレスポンス型通信、GETASYNCPORTコマンドの送信と、レスポンスの受信というコマンドレスポンス型通信から構成される。REQUESTINITIALIZEコマンドは、BDJアプリケーションからBCManagerinitializeBCが呼び出された際、発行されるソケットコマンドである。デジタルコピーモジュール35の初期化要求が行われて、デジタルコピーモジュール35との通信に使うポート番が特定されれば、そのポートに対して、このコマンドが送信される。デジタルコピーモジュール35はオープン中のポートを通じ、REQUESTINITIALIZEという文字列を受信すると、初期化要求が行われたと判断し、パラメータ例えば、以前に設定されたデジタルコピーサーバ36のURL、コピー元のソースロケーション、コピー先メディアの出力デバイス、シリアルIDのクリアと状態遷移通知のための非同期イベント用ポートを新規にオープンした後、初期化が完了したという旨を知らせるため、ソケットコマンドを受け取ったポートを通じて、OKという文字列を送信する。オンメディアライブラリ28は、ソケットコマンドを送ったポートから、OKという文字列を受け取ると初期化が完了したとみなす。GETASYNCPORTコマンドは、状態遷移通知のための非同期通知用に開かれたポート番号を取得するためのコマンドであり、デジタルコピーソケットプロトコルは2種類のポートで構成され、1つはデジタルコピーソケットコマンド用同期コマンド、もう一つはデジタルコピーモジュール35の状態遷移通知用非同期イベントである。デジタルコピーソケットコマンド用のポートは、オンメディアライブラリ28からデジタルコピーモジュール35へコマンドを投げる形でやり取りが行われるが、状態遷移通知用のポートはデジタルコピーモジュール35からオンメディアライブラリ28へ一方的にイベントが通知される形となる。BDJアプリケーションからBCManageraddBCStateChangeListnerが呼ばれると、オンメディアライブラリ28は状態遷移通知用ポートのモニタリングを開始し、デジタルコピーモジュール35から送られている状態遷移通知をオンメディアライブラリ28APIのイベントに変換し、BDJアプリケーションに状態遷移を通知することになる。cコピー先状態確認フェーズは、GETDEVICELISTコマンドの送信と、レスポンスの受信というコマンドレスポンス型通信、GETDEVICEINFOSDコマンドの送信と、レスポンスの受信というコマンドレスポンス型通信から構成される。GETDEVICELISTコマンドは、デジタルコピーモジュール35へサポートしているメディアのリストを要求するためのコマンドであり、BDJアプリケーションから、BCManagergetDeviceListが呼ばれ再生装置がコピー先としてサポートしているメディアのリストが要求された際、オンメディアライブラリ28に対して、本コマンドが送信される。GETDEVICELISTコマンドに対するレスポンスは、サポートしているメディアのリストであり、ソケットコマンド用のポートを通じて返す。サポートしているメディアのリストは、<メディアの種類><番号>という形で返され、複数メディアをサポートしている場合は、それぞれ空白文字で区切られる例:SD1<sp>USB1、<sp>は空白文字。図16では、再生装置が例えばSDカードスロットのみをサポートしている場合にはSD1が応答として返される例を示している。GETDEVICEINFOコマンドは、その引数にメディアの種類の指定が可能であり、その指定された種類のメディアのトータル容量、空き容量をレスポンスとして変える。BDJアプリケーションからBCOutputDevicegetTotalSpaceもしくはBCOutputDevicegetFreeSpaceが呼ばれ、トータル容量、空き容量の情報提供が要求されると、オンメディアライブラリ28はGETDEVICEINFOコマンドをソケットコマンド用ポートを通じてデジタルコピーモジュール35へ送り、トータル容量、空き容量の情報を受け取る。コマンド名と引数の間には空白文字を設ける。例えば、SD1種類:SDカード、番号:1の情報を要求する場合は、GETDEVICEINFO<sp>SD1という文字列をソケットコマンド用ポートを通じてデジタルコピーモジュール35へ送ることになる。dパラメータセットフェーズは、SETSERVERURLコマンドの送信と、レスポンスの受信というコマンドレスポンス型通信、SETSRCLOCATIONコマンドの送信と、レスポンスの受信というコマンドレスポンス型通信、SETOUTPUTDEVICEコマンドの送信と、レスポンスの受信というコマンドレスポンス型通信、SETSERIALIDコマンドの送信と、レスポンスの受信というコマンドレスポンス型通信から構成される。デジタルコピーに必要なパラメータをセットする場合も同様に、デジタルコピーソケットコマンドを通じてオンメディアライブラリ28からデジタルコピーモジュール35へ値が伝わり、デジタルコピーモジュール35内にパラメータがセットされる。コマンド名と引数は空白文字で区切る。e残コピー回数確認フェーズは、REQUESTCHECKTICKETコマンドの送信と、OK<remainingtimesofcopy>レスポンスの受信というコマンドレスポンス型通信から構成される。REQUESTCHECKTICKETコマンドは、コピーの残りを問合せるためのコマンドであり、レスポンスとしてその残りコピー回数が通知される。必要なパラメータのセットが完了し、BDJアプリケーションからBCManagercheckTicketが呼ばれると、オンメディアライブラリ28は、デジタルコピーモジュール35へREQUESTCHECKTICKETコマンドを送る。デジタルコピーモジュール35は、REQUESTCHECKTICKETコマンドを受け取ると、セットされたパラメータを元に、コンテンツID,シリアルID及びメディアIDを取り出し、デジタルコピーサーバ36へこれら3つの値を送って残コピー回数を確認する。デジタルコピーサーバ36から得られた残コピー回数は、REQUESTCHECKTICKETコマンドの戻り値として、オンメディアライブラリ28へ渡す。fコピー開始フェーズは、REQUESTCOPYコマンドの送信と、TRANSFERREDレスポンスの受信というコマンドレスポンス型通信から構成される。REQUESTCOPYコマンドは、SDVideoコンテンツのコピー開始を命じるコマンドであり、BDJアプリケーションからBCManagermakeCopyが呼ばれると、オンメディアライブラリ28は、デジタルコピーモジュール35へREQUESTCOPYコマンドを送り、コピー開始を要求する。デジタルコピーモジュール35は、残コピー回数が1回以上残っていることが確認できれば、データコピーを開始し、REQUESTCOPYコマンドの戻り値としてOKを返す。gコピー進捗確認フェーズは、GETPROGRESSコマンドの送信と、TRANSFERREDレスポンスの受信というコマンドレスポンス型通信から構成される。GETPROGRESSコマンドは、トータルのコピーバイト数と残りバイト数を取得するためのコマンドである。データコピー中にBCProgressremaining、もしくはBCProgresstotalがBDJアプリケーションから呼び出されると、オンメディアライブラリ28はGETPROGRESSコマンドをデジタルコピーモジュール35に送り、デジタルコピーモジュール35から、トータルのコピーバイト数と残りバイト数を得て、BDJアプリケーションへその値を返す。データコピーが完了すると、デジタルコピーモジュール35はTRANSFERREDに遷移し、非同期イベント用のポートを通じて、オンメディアライブラリ28へTRANSFERREDに遷移したことが通知される。h鍵書込みフェーズは、REQUESTFINALIZEコマンドの送信と、OKレスポンス、FINALIZINGレスポンス、COMPLETEDレスポンスの受信というコマンドレスポンス型通信から構成される。REQUESTFINALIZEコマンドは、コンテンツID,シリアルID、メディアID及びMKBを取り出し、デジタルコピーサーバ36へこれら4つの値を送って復号鍵を得るためのコマンドである。データコピー完了後、BDJアプリケーションからBCManagerfinalizeBCが呼ばれると、オンメディアライブラリ28は、デジタルコピーモジュール35へREQUESTFINALIZEコマンドを送る。デジタルコピーモジュール35は、REQUESTFINALIZEコマンドを受け取ると、セットされたパラメータを元に、コンテンツID,シリアルID、メディアID及びMKBを取り出し、デジタルコピーサーバ36へこれら4つの値を送って復号鍵を得る。デジタルコピーモジュール35は、得られた復号鍵をコピー先メディアであるセキュアなメモリカード104の保護領域へ書き込み、書き込み処理が完了すると、非同期イベント用のポートを通じて、オンメディアライブラリ28へCOMPLETEDに遷移したことを通知する。以上がオンメディアライブラリ28とデジタルコピーモジュール35間でやり取りされるデジタルコピーソケットプロトコルの内容である。上述したように、オンメディアライブラリ28とデジタルコピーモジュール35間でやり取りされるコマンド、イベント通知は全て再生装置内のローカル通信ポートを用いたソケット通信で行われる。残コピー回数の確認及び復号鍵の取得に関しては、デジタルコピーモジュール35とデジタルコピーサーバ36間でグローバル通信が行われる。図17は、BDJアプリケーションによる機能確認から初期化までの処理手順を示すフローチャートである。ステップS1では、システムプロパティdigitalcopyportが存在するか否かを判定し、存在する場合、システムプロパティdigitalcopyportに示されるポートを用いてソケット接続を行う。システムプロパティdigitalcopyportが存在しない場合、プライベートポート又はフリーポートを用いてソケット接続を行う。その後、BCManagergetINstanceAPIをコールし、ステップS5で、BCManagerがリターンされたか否かを判定する。リターンされた場合、BCManageraddBCStateChangeListnerAPIをコールし、BCManagerinitializeをコールする。BCInitializedイベントがスローされたかどうかを判定する。ステップS5及びステップS8がYesであるなら、デジタルコピー可能であると判定する。ステップS5、ステップS8のどちらかがNoであるならデジタルコピー不可能であると判定する。図18は、コピー先状態確認からパラメータセットまでの処理手順を示す。BCManagergerdeviceListAPIをコールし、デバイスリストであるAArrayofSupporteddevicesがリターンされるのを待つ。リターンされれば、サポートデバイスの中に、セキュアなメモリカード104が存在するか否かを判定し、セキュアなメモリカード104が存在しない場合、処理を中断する。存在する場合、セキュアなメモリカード104のスロットを一覧表示し、ユーザによるスロットの選択を待つ。スロットiが選択されれば、ステップS36において、スロットiを引数で指定したBCOutputDevicegetFreeSpaceAPIをコールし、ステップS37において、残りサイズのリターン待ちを行う。リターンされれば、ステップS38において、残りサイズが、SDVIDEOディレクトリの予想サイズよりも大きいかどうかを判定する。小さければステップS35に移行して再度の選択を促す。ステップS38がYesであれば、ステップS39においてシリアルIDの入力を促すGUIを表示し、ステップS40において、シリアルIDの入力待ちを行い、ステップS41においてコピーソース格納ディレクトリの選択を行う。入力されれば、BCManagersetServerURLAPIBCManagerSourceLocationAPIBCManagersetOutputDeviceAPI、BCManagersetSerialIDAPIのコールを行い、これらのAPIコールに対してサクセスが返されるかどうかを判定する。図19は、コピーソース格納ディレクトリの選択手順の詳細を示すサブフローチャートである。BDROMのEMOVEディレクトリの配下にある複数のコピーソース格納ディレクトリに対応するストリーム形式を一覧表示し、何れのストリーム形式を選択するかという操作を、ユーザから受け付ける。そしてそのような選択がなされれば、選択されたストリーム形式xxに対応するコピーソース格納ディレクトリxxのファイルパスであるmntbdromEMOVEDATAxxを特定する。そうして、特定したファイルパスであるmntbdromEMOVEDATAxxを引数としたBCManagerSetServerURLのコールを生成する。ファイルパスmntbdromEMOVEDATAxxで指示されたコピーソース格納ディレクトリxxの配下にある、コピー情報格納ディレクトリxxには、そのコピーソース格納ディレクトリxx固有のコンテンツIDxxが存在するので、機器固有機能制御部33は、このコンテンツIDxxと、シリアルIDと、メディアIDyとをサーバに送信することで、携帯端末向け保護コンテンツのコピーの残りコピー回数の確認を行い、また、この復号鍵の取得にあたっては、このコンテンツIDxxと、シリアルIDと、メディアIDyとの組合せをサーバに送信する。以上のフローチャートでは、デジタルコピーにあたって、デジタルコピーの対象を、VGA形式及びワンセグ形式というように様々な形式の携帯端末向け保護コンテンツの何れかの中から任意に選択することができる。このように、形式が異なる様々な携帯端末向け保護コンテンツをリードオンリーメディア105に予め記録しておき、デジタルコピーに供することで、トランスコードを行うことなく、任意のストリーム形式の携帯端末向け保護コンテンツを、セキュアなメモリカード104にコピーすることができる。図20は、BDJアプリケーションによる残りコピー回数の確認から鍵書き込みまでの処理手順を示すフローチャートである。BCManagercheckTicketAPIをコールし、BCReadyイベントが発行されたか、レスポンスがなされたかを判定する。ステップS14では、コピーの残りコピー回数が1つ以上であるか判定し、1以上であるなら、BCManagerMAKEをコールし、BCProgressがリターンされるのを待つ。以降、ステップS25において、進捗グラフを表示してから、ステップS18~ステップS21のループを行う。このループは、BCProgressremaingAPIをコールし、残りバイト数の受信をして、残りバイト数が0になったかどうかを判定し、その残りバイト数に応じて、進捗バーを更新するという処理を、ステップS20がYesと判定されるまで繰り返すものである。ステップS22は、BCtransferredEventを受信したかどうかの受信待ちであり、受信されれば、BCManagerfinalizeBCAPIをコールして、BCCompleteイベントの受信待ちを行う。受信されれば、処理を終了する。以上のフローチャートの処理で表示される、表示画面について説明する。図21は、デジタルコピーの過程で、表示される表示画面の一例を示す図である。図21aは、セキュアなメモリカード104スロットの一覧表示の一例を示す。スロット1~3のそれぞれに対応するボタンから構成される。図21bは、シリアルIDの数値入力及びストリーム形式の選択のための入力画面を示す。図21cは、コピー進捗を表示するためのGUIを示す。図21aからcまでのメニューは、コピー管理BDJアプリケーションによって表示されるものであり、本編コンテンツに含まれるビデオストリームの再生を伴うものなので、本編コンテンツに登場するキャラクターや本編コンテンツに関連するグッズを用いて、華やかな画面演出を行うことができる。図22は、デジタルコピーモジュール35の処理手順を示すフローチャートである。ステップS61において、REQUESTINITIALIZEの受信待ちを行い、REQUESTINITIALIZEを受信すれば、設定済みのカレントシリアルID、ソースロケーション、カレントサーバURL、出力デバイス、レジューム位置をリセットする。そしてGETDEVICELISTの受信待ちを行い、受信すれば、再生装置で有効になっているドライブのステータスをセンスする。そして、各スロット番号に対応付けて、ドライブの状態を示すデバイスリストを生成してレスポンスとして返す。ステップS65は、カレントURL、ソースロケーションのファイルパス、出力デバイス、シリアルIDについてのセットパラメータの受信待ちであり、ステップS66では、セットパラメータコマンドのオペランドをカレントサーバURL、ソースロケーション、出力デバイス、シリアルIDとして設定する。ステップS67は、CHECKCOPYREQUESTの受信待ちであり、ステップS68では、カレントソースロケーションであるmntbdromEMOVEDATAxxのEMOVINFからコンテンツIDxxを取り出す。一方、カレント出力デバイスyに装填されたセキュアなメモリカード104からMIDyを取り出し、コンテンツIDxxと、MIDyと、シリアルIDzとをサーバに設定して、残りコピー回数の検索を要求する。その後、残りコピー回数の受信待ちとなり、残りコピー回数を受信すれば、残りコピー回数をレスポンスとして返す。ステップS73は、COPYREQUESTの受信待ちであり、COPYREQUESTを受信すれば、セキュアなメモリカード104にSDVIDEOディレクトリ、MNGINFOディレクトリ、PRG001ディレクトリを作成し、DATAxxディレクトリのMGRDATA、PRGMGRを読み出してMNGINFOディレクトリに書き込むよう指示し、DATAxxディレクトリのPRG001PGIと、これに関連するストリームファイルとを読み出して、PRG001ディレクトリに書き込む。図23は、図22のフローチャートの続きである。ステップS77、ステップS78のループは、COPYPROGRESSを受信したか、書き込みが完了したかの受信待ちを構成する。COPYPROGRESSを受信すれば、総サイズ/残サイズをレスポンスとして返す。書き込みが完了すれば、ステップS79でREQUESTFINALIZEの受信待ちを行い、REQUESTFINALIZEを受信すれば、カレント出力デバイスyに装填されたセキュアなメモリカード104からMKByを読み出し、コンテンツIDxxメディアIDy、MKBy、シリアルIDzとをサーバに送信して、タイトルキーの検索を要求する。ステップS82は、復号鍵の受信待ちであり、復号鍵を受信すれば、ステップS83においてセキュアなメモリカード104と相互認証を行った後、ステップS84においてセキュアなメモリカード104のプロテクト領域に復号鍵を格納したVIDEO001KEYを書き込む。以上のように本実施形態によれば、対話画面を通じて、シリアルIDの入力やストリーム形式の選択をユーザに行わせ、これに応じて、予めBDROMに記録されているストリーム形式固有の携帯端末向け保護コンテンツを、セキュアなメモリカード104に書き込むので、早期に希望のストリーム形式の携帯端末向け保護コンテンツをセキュアなメモリカード104に記録して、屋外に持ち出すことができる。これまでの実施形態では、組込みラィブラィの内容を明確にしていなかったが、本実施形態では、組込みラィブラィ25を詳細に説明する。組込ライブラリ25は、Java2Micro_EditionPersonalBasisProfileと、GloballyExecutableMHPspecificationforpackagemediatargetsといった基本パッケージと、エクステンションパッケージとから構成される。これらのパッケージのAPIを利用すれば、ネットワーク処理のためのjavanet、GUI処理のためのjavaawt、言語処理のためのjavalang、記録媒体に対するIO処理のためのjavaio、ユーティリティであるjavautil、メディアフレームワークのためのjavaxmediaといったクラスのメソッド、コンストラクタ、インターフェイス、イベントを用いた構造化プログラミングで、BDJアプリケーションを記述することができる。エクステンションパッケージは以下のライブラリから構成される。複数のデジタルストリームを用いたマルチアングル再生、複数のビデオストリームを用いたピクチャインピクチャ再生、複数のオーディオストリームを用いたオーディオミキシング再生、複数のグラフィクスストリームを用いたメニュー再生や字幕再生等、JavaMediaFrameWorkにはない、マルチパス型のプレイリスト情報を用いた独特の機能を実現するためのorgbluraymedia、デジタル放送サービスのホームプラットフォームで実現されている、サービスに基づくアプリケーションシグナリングを、タイトルにマップして動作させるためのorgblurayti、アプリケーションの生存区間を管理するためのorgblurayapplication、キーイベントのための定数を定義し、映像再生との同期を実現するためのorgblurayui、BDROMに記録されていないLocalStorage上のコンテンツを、BDROMに記録されたコンテンツにマウントさせるためのorgblurayvfsこれらのライブラリは、javanet、javaawt、javalang、javaio、javautil、javaxmediaクラスのメソッドからのインへリッドメソッドを含み、これらのクラスのインターフェイスをエンベデッドインターフェイス、スーパーインターフェイスとして、BDROM再生のための再生制御を規定する。このBDJエクステンションのAPIを用いれば、javanet、javaawt、javalang、javaio、javautil、javaxmediaクラスを用いたプログラミング技法の延長線上で、BDJタイトルを作成することができる。BDJエクステンションによって定義される機能的な構成要素を、模式的に描いたのが、図24である。図24は、図4に示したプラットフォーム部20における組込ライブラリ25のより具体的な構成を示す図である。本図に示すように、プラットフォーム部20における組込ライブラリ25のBDJエクステンションは、マージ管理モジュール41、メディア再生モジュール42、ファイルIOモジュール43、ネットワークモジュール44から構成される。なお、本図における再生制御部10、機器固有機能制御部33は、図4に示したものと同一であり、説明のために便宜的に記載している。マージ管理モジュール41は、BDROMと、ローカルストレージとを1つの仮想ファイルシステムとして統合する。仮想ファイルシステムは、ローカルストレージの個々の記録媒体におけるファイルシステム上のファイルに対して、別名アクセスのためのファイルパスを割り当て、別名アクセス用のファイルパスをロケータとして用いたファイルアクセスを、アプリケーションに実行させる。ここで、ローカルストレージファイルに対する別名アクセス用のファイルパスの割り当ては、マウント規則ファイルを引数で指定した上で、アプリケーションが仮想パッケージのクリエイトAPIをコールして、仮想パッケージを仮想ファイルシステムに生成させることでなされる。かかるコールによって作成される仮想パッケージとは、BDROM上のファイル以外の別のファイルが追加されたファイル構成、BDROM上のファイルの何れかが別のファイルに置き換えられたファイル構成を示す。そして、この仮想パッケージの実体は、上記ファイル追加後のファイル構成、及び/又は、上記ファイル置換後のファイル構成を示すファイル管理情報であり、BDROMからメモリに読み出されたファイル管理情報に新たなファイルエントリーを追加するか、又は、メモリに読み出されたファイル管理情報における一部のファイルエントリーを別のものに置き換えることで得られる。ここでマウント規則ファイルとは、ローカルストレージにおけるファイルパスと、別名アクセスのためのファイルパスとの対応付けをマークアップ言語のタグで記述したものである。そして、ローカルストレージ上のファイルに与えられる別名アクセス用のファイルパスは、BDROMにおけるBDMVディレクトリと、CLIPINFディレクトリ、PLAYLISTディレクトリ、STREAMディレクトリの何れかとを組合せたものである。アプリケーションのAPIコールによって、仮想パッケージが作成されれば、仮想パッケージ上のファイルをBDROMに対するロケータによって指定することができ、ローカルストレージ上のファイルは、あたかも、BDROMに記録されているかの如く扱うことができる。メディア再生モジュール42はバイトコードアプリケーションに対し、メディア再生制御のためのAPIを提供している。バイトコードアプリケーションがメディア再生制御APIを呼び出すと、メディア再生モジュールは対応するAV再生ライブラリ関数を呼び出し、AV再生制御を行う。ファイルIOモジュール43は、バイトコードアプリケーションからのBDROM、ローカルストレージ、記録型BDドライブ等の各メディアへのファイルアクセス要求の処理を行う。ネットワークIOモジュール44は、バイトコードアプリケーションに対し、ネットワーク制御のためのAPIを提供している。バイトコードアプリケーションからのネットワーク制御要求に従い、ネットワークIOモジュール44を使って、ネットワーク接続を行う。ネットワークIOモジュール44は、インターネットにおけるサーバとの接続を実現する。TCPIP及びUDPIPのうち、どちらかのプロトコルスタックがサポートされ、HTTPプロトコルを使用できることはネットワークIOモジュールの要件となる。物理的な接続は、Ethernet登録商標電話のそれぞれで違ってもよい。プラットフォームは、ネットワーク接続を利用する前に、認証されねばならず、またネットワーク接続のための適切なPermissionを得なければならない。以上が、組込ライブラリ25におけるBDJエクステンションについて説明である。つづいて、この組込ライブラリ25のBDJエクステンションを前提にした、オンメディアライブラリ28の特徴について説明する。本実施形態におけるオンメディアライブラリ28は、プロトコル解析専用のデジタルコピーライブラリであり、バイトコードアプリケーションに対し、あたかも再生制御APIであるBDJAPIを拡張したかのようなAPIデジタルコピーライブラリAPIを提供する。デジタルコピーモジュール35とのデータ送受信に用いるプロトコルは、個々のバイトコードアプリケーションに依存したものではなく、その詳細がデジタルコピーライブラリ内に隠蔽されたものになり、複数のバイトコードアプリケーションについて共通のプロトコルとして定義されている。このように構成することで、バイトコードアプリケーションはデジタルコピーモジュール35とのデータ送受信に用いるプロトコルを解析する必要がなくなり、プロトコル解析をライブラリで一元管理することが可能となるため、バイトコードアプリケーションの生産性を向上させることができる。オンメディアライブラリ28は、アーカイブファイルによって定義されるが、デジタルコピーライブラリにおけるパーミッションリクエストファイルは、バイトコードアプリケーションと、ローカルホストとの間のソケット通信を許可している。以上が組込ライブラリ25についての説明である。続いて、仮想ファイルシステムの作成に利用されるローカルストレージの詳細について説明する。かかるローカルストレージには、セキュアなメモリカード104を使用することができる。図25は、ローカルストレージとして使用されたセキュアなメモリカード104におけるディレクトリ構成を示す図である。ローカルストレージには大きく3種類の領域が存在し、1つはユーザから自由に読み書きできユーザにとって可視である領域ユーザ領域、もう一つはユーザからは読み書き不可能で、ユーザにとって不可視であり、著作権保護に対応したシステムのみ読み書きが許される保護された領域保護領域、最後に、ユーザからは読み書き不可能、システムからも書き込み不可能で、システムによる読み込みのみが許される領域システム領域である。ユーザ領域は、さらに追加コンテンツ領域とSDビデオ領域の2種類に分けられる。追加コンテンツ領域はBDROM再生時に補助的用いられるコンテンツが格納され、SDビデオ領域には主に携帯端末での再生を目的としたSDビデオ準拠のコンテンツステップSDビデオコンテンツが格納される。追加コンテンツ領域とSDビデオ領域は共にローカルストレージのユーザ領域上のルートディレクトリ直下に存在する。追加コンテンツ領域を示すディレクトリ名配布媒体文字以内の固定値BUDAである。このBUDAディレクトリ以下サブディレクトリとそれ以下のファイルも含むに、アプリケーションはサーバからダウンロードしてきた追加ファイル等、任意のファイルを格納することが可能である。BUDAディレクトリ以下にはさらにOrganizationIDディレクトリとDiscIDディレクトリが存在し、特定のプロバイダOrganizationに対応するディレクトリに、各BDROMに対応するディレクトリを設けることにより、各BDROMについてのダウンロードデータが個別に格納される。一方SDビデオ領域を示すディレクトリ名はSDVIDEOであり、追加コンテンツ領域と同様、ユーザ領域上のルートディレクトリ直下に存在する。SDVIDEOディレクトリ以下にはさらにSDビデオコンテンツ毎に分かれたSDビデオコンテンツディレクトリPRGxxx、xxxは可変とSDビデオ領域全体の管理ファイルが格納されたSDビデオ管理ディレクトリMGRINFOが存在する。SDビデオコンテンツディレクトリには、上述のPRG001PGI及びMOV001SD1が記録され、SDビデオ管理ディレクトリには、上述のMGRDATA及びPRGMGRが記録される。ユーザからはアクセスできない保護領域上には、暗号化された携帯端末向け保護コンテンツを復号するための復号鍵VIDEO001KEYが記録される。復号鍵へのアクセスは著作権保護に対応したシステムのみが可能である。ユーザからはアクセスできず、システムからも読み込みのみ許されるシステム領域には、前述の復号鍵生成に必要な鍵情報が記録されたメディアキーブロックMKBと、ローカルストレージに割り当てられているSDメモリーカード等の媒体を、媒体毎に一意に特定するための識別子であるメディアIDMIDが記録されている。メディアIDは同じ種類のメディアでも媒体毎に異なる値が割り振られている。セキュアなメモリカード104のうち、ローカルストレージとして使用されているものは、デバイスリストにおける表記が、BDJstorage<devicename>というものになる。これは、ローカルストレージとして利用されているセキュアなメモリカード104と、そうでないセキュアなメモリカード104とを区別するためである。即ち、ローカルストレージとして利用されているセキュアなメモリカード104は、BDROMとの組合せで仮想ファイルシステムを形成していることが多い。かかるセキュアなメモリカード104に対してコンテンツが書き込れて、セキュアなメモリカード104がイジェクトされると、構築された仮想ファイルシステムが、破壊されることになり望ましくない。そこで、デジタルコピーモジュール35は、コピー先状態確認フェーズにおいて、各デバイスの状態確認が求められた際、デバイスリストとして、ローカルストレージとして利用されているセキュアなメモリカード104であるか否かという種別を、レスポンスとして返す。こうすることで、コピー管理を行うデジタルコピー管理BDJアプリは、セキュアなメモリカード104がローカルストレージとして使用されている場合、仮想ファイルシステムの構築中はセキュアなメモリカード104をイジェクトしないよう、具体的にいうと、仮想ファイルシステムにより構築された仮想パッケージ中のタイトルの再生中は、セキュアなメモリカード104をイジェクトしないよう警告表示を行うことができる。以上のように本実施形態によれば、仮想ファイルシステムが破壊されないような配慮を払いつつも、ローカルストレージとして利用されているセキュアなメモリカード104を、携帯端末向け保護コンテンツのコピー先として選ぶことができるので、記録媒体の利用効率が高まる。第6実施形態これまでの実施形態では、規定のAPIにとらわれない様々な機能を呼び出すことを可能にする構成について述べたが、ディスク上のアプリケーションが制御できる範囲が拡大するとセキュリティの懸念が生まれてくる。第6実施形態では、よりセキュリティを強化した実施の形態の変形例について説明する。第6実施形態では前述の第1実施形態と同様の部分は省略し、これまでの実施形態との変更点のみを記載している点には注意されたい。記載していない部分はこれまでの実施形態と同様と捉えてよい。図26は従来におけるアプリケーションの署名検証を示す図である。バイトコードアプリケーションが正当かどうかの検証は、バイトコードアプリケーションを構成するアーカイブファイル内に記録されたデジタル署名とディスク上のルート証明書を元に署名検証を行うことで成される。具体的にはアーカイブファイル内のデジタル署名をルート証明書を元に復号して得られるハッシュ値と、アーカイブファイルを構成する個々のクラスファイルのハッシュ値が一致しているかどうかを確認し、一致していればアーカイブファイルは正当であり、一致していなければ何らかの不正があったとみなされる。しかしながら、この検証方法では、ルート証明書とアーカイブファイル内のデジタル署名の両方が対になっていれば、検証にパスするので、正当なルート証明書を保有するコンテンツ提供者が不正にアーカイブファイルを作成した場合は、それを検知する術はなく、第1実施形態で述べたように、再生装置の固有機能を開放してしまうと、正当なルート証明書を保有する全てのコンテンツ提供者は自由に再生装置の固有機能を利用できてしまうことになる。図27は、再生装置が保有するデジタル証明書をベースとした署名検証を示す図である。バイトコードアプリケーションを構成するJarファイル内にディスク上のルート証明書をベースとしたデジタル署名に加え、再生装置固有のデジタル証明書をベースとしたデジタル署名も付与する。具体的にはJarファイル内に格納された個々のクラスファイルのハッシュ値がリスト化されたマニフェストファイルMANIFIESTMFのハッシュ値を、再生装置固有のデジタル証明書に対応した秘密鍵で暗号化した値を再生装置固有のデジタル署名としてJarファイル内に記録する。再生装置側では、従来のルート証明書をベースとした署名検証に加え、再生装置固有の証明書をベースとした署名検証も実施する。図28は、署名検証の結果に応じた機能制限を示す図である。再生装置固有の機能をバイトコードアプリケーションから呼び出すためには、従来のルート証明書をベースとしたデジタル署名だけでは不十分であり、加えて再生装置固有のデジタル署名を用意しなければならない。再生装置固有のデジタル署名は、再生装置固有の証明書に対応した秘密鍵がなければ作成できないため、第三者が不正に再生装置固有のデジタル署名を用意して、再生装置固有の機能を悪用するということを防ぐことができる。しかも、たとえ再生装置固有のデジタル署名検証に失敗したとしても、従来の共通機能の呼び出しに関しては何ら影響を与えることはないので、共通機能部分に関しては互換性を保つことができる。図29は、装置固有機能を利用するため接続要求時における処理のフローチャートである。本フローチャートは第1実施形態におけるステップS103に対応しており、セキュリティ面で強化されている点が異なる。まず、デジタルコピーモジュール35は接続要求を行っているバイトコードアプリケーションに装置固有のデジタル署名が付与されているかどうかを判断するステップS201。装置固有のデジタル署名が付与されていなければ、接続要求を拒否し、以降の通信ポートを介した要求には再生装置は何も応じない、もしくはポートを閉じて一切の通信を拒否してもよい。ステップS201で装置固有のデジタル署名が付与されていると判断できた場合、再生装置は各クラスファイルのハッシュ値の取得を行うステップS202。各クラスファイルのハッシュ値はJarファイルのマニフェストファイルに記載されているため、それらのハッシュ値がリスト化されているマニフェストファイルのハッシュ値を計算するだけでも良い。次に再生装置が持つ固有のデジタル証明書を用いて、バイトコードアプリケーションに付与された装置固有のデジタル署名を復号し、デジタル署名に記されたハッシュ値を導き出すステップS203。そして、ステップS202とステップS203で取得されたハッシュ値が一致していれば、デジタル署名は正しく付与されていると判断し、一致していなければ、不正なデジタル署名であると判断するステップS204。不正なデジタル署名と判断した場合、ステップS201でデジタル署名が付与されていなかった場合と同様、以降は通信ポートを介した再生装置固有の機能呼び出しには全く応じないことになる。デジタル署名が正しいと判断すると、暗号化通信路の生成を行うステップS205。具体的には、再生装置が持つデジタル証明書をバイトコードアプリケーション側に送り、バイトコードアプリケーションは送られてきたデジタル証明書で暗号化通信ソケットSSLソケットを作成する。通常のソケット例えばソケットコマンドおよびその応答は暗号化されず非暗号でデータがやりとりされるが、SSLソケットは送られてきたデジタル証明書で暗号化してデータをやりとりすることになる。すなわち、通信ポートを介した再生装置とバイトコードアプリケーション間の相互にやりとりするデータは通信路上は全て暗号化されることになる。以上、再生装置側はバイトコードアプリケーションに付与されたデジタル署名を、バイトコードアプリケーション側は再生装置から送られてくるサーバ証明書を検証し、かつ、通信ポートを介したデータのやりとりはSSLによる暗号化が施されるため、不正なバイトコードアプリケーション、不正な再生装置を排除し、かつ通信路上のデータを不正取得利用とするハッカーからの攻撃を防ぐことができる。第7実施形態これまでの実施形態では、再生装置固有の機能としてデジタルコピーを例に、規定のAPIにとらわれない様々な機能をセキュリティを確保しつつ呼び出すことを可能にする構成について述べたが、本実施形態は、このデジタルコピーについて、より使い勝手を向上させた実施の形態の変形例である。第7実施形態では、これまでの実施形態と同様の部分は省略し、変更点のみを記載している点に注意されたい。記載していない部分はこれまでの実施形態と同様と捉えてよい。図30は再生装置にて途中までコンテンツを視聴し、途中から携帯端末で視聴する一例を示す図である。自宅等で据え置きの再生装置とテレビで視聴して楽しんでいたコンテンツを、外出時にも楽しみたいというケースを想定した場合、携帯端末で再生したときに、また最初から再生が開始するのではなく、続きから再生が開始されるのが望ましい。この場合、デジタルコピー実施時にコンテンツをコピーするだけでなく、再生位置情報も加えてコピーする必要がある。SDメモリーカード上に記録されるSDビデオフォーマットでは、SDビデオ管理ファイルMGRDATAにレジューム位置を示す再生位置情報を記録することができるため、据え置きの再生装置で途中まで再生していた再生時刻をデジタルコピー時にSDビデオ管理ファイルに記録することで、本ユースケースを実現することができる。図31は、第7実施形態におけるデータコピーのフローチャートである。携帯端末向け保護コンテンツを指定されたコピー先メディアにコピーを行う際、再生位置情報の記録についての指定があるかどうかを判断するステップS301。再生位置情報の記録指定はバイトコードアプリケーションからデジタルコピーソケットコマンド用通信ポートを介してデジタルコピーモジュール35に通知することで成される。図30では、バイトコードアプリケーションによる再生位置情報のコピーをユーザに問い合わせたが、常に再生位置情報の記録を指定してもよい。いずれにしても、デジタルコピーモジュール35はデータコピー時に事前にバイトコードアプリケーションから再生位置情報の記録指定があるかどうかを判断し、再生位置情報の記録指定がなければ、SDビデオ管理ファイルに手を加えずに、そのままデータコピーを行う。ステップS301において再生位置情報の記録指定が行われていると判断した場合、バイトコードアプリケーションから記録する再生時刻の指定があるかどうかを判断するステップS302。例えば、再生装置にてすでに30分視聴していた場合は、引き渡されるべき値は1800000になる。再生時刻の指定があり、かつその値が有効であれば、SDビデオ管理ファイルに、指定された時刻を書き込むステップS303。ステップS301において再生位置情報の記録指定を受け取っていると判断したが、ステップS302において時刻の指定がされていないと判断した場合、プレーヤレジスタに再生時刻が記録されているかどうかを判断するステップS304。再生装置は複数のレジスタを持っており、その内の一つがレジューム再生用に割り当てられているため、レジューム再生に割り当てられているレジスタの値を確認する。レジューム再生用のレジスタに有効な再生時刻が記録されていれば、その値をSDビデオ管理ファイルに書き込むステップS305。もし、再生位置情報の記録指定を受け取っているにもかかわらず、バイトコードアプリケーションから有効な時刻指定がなく、かつレジスタにも有効な再生時刻が記録されていなかった場合は、SDビデオ管理ファイルには何も手を加えずに、そのままデータコピーを行うことになるステップS306。以上の構成により、単なるデータコピーだけでなく、再生位置情報も加えてコピーすることが可能となり、デジタルコピー後に携帯端末で再生させたときに据え置きの再生装置で途中まで再生していた地点から続き視聴ができるため、デジタルコピーの使い勝手をより向上させることができる。第8実施形態これまでの実施形態では、コピー元とコピー先の記録媒体が異なるケースについてデジタルコピーを実施するための構成について述べたが、本実施形態では、コピー元とコピー先の記録媒体が同一の場合における実施の形態について説明する。本実施形態ではこれまでの実施形態と同様の部分は省略し、これまでの実施形態との変更点のみを記載している点に注意されたい。記載していない部分はこれまでの実施形態と同様と捉えてよい。図32はコピー元とコピー先が同一記録媒体におけるデジタルコピーを示す図である。コピー元とコピー先が同一になるケースの一つとして、対象となる携帯端末向け保護コンテンツがBDROM上に存在せず、バイトコードアプリケーションが外部ネットワークを経由してサーバから携帯端末向け保護コンテンツをダウンロードすることが考えられる。しかしながら、図6で示したように、追加コンテンツ領域とビデオコンテンツ領域は分けられているため、バイトコードアプリケーションは直接ビデオコンテンツ領域にダウンロードすることはできない。バイトコードアプリケーションが自由にアクセスできる領域はアプリケーションが属するOrganizationと同一のOrganizationディレクトリ以下のみとなる。このようにアクセス範囲が決められているのは別のOrganizationのコンテンツを勝手に抜き取ったり削除したりすることを防ぐためである。したがって、バイトコードアプリケーションは追加で携帯端末向け保護コンテンツをダウンロードする場合、まずはOrganizationディレクトリ以下に一旦格納する。そして、Organizationディレクトリに格納されたデジタルコピーコンテンツを、端末内ローカル通信を介して端末固有機能を呼び出し、ビデオコンテンツ領域に移動させるという手順となる。図33はコピー元とコピー先が同一記録媒体におけるデジタルコピーに対応したフローチャートである。コピー元とコピー先が同一記録媒体となるデジタルコピーにおいては、ステップS101で行っていた、挿入されているディスク上に携帯端末向け保護コンテンツが存在するかどうかを確認するステップは不要となる。なぜならば、ディスク上に携帯端末向け保護コンテンツが存在しなくても対象となる携帯端末向け保護コンテンツがローカルストレージ上に記録されている可能性があるためである。本実施の形態においてポート開放時間を極小化する場合は、携帯端末向け保護コンテンツが存在するかどうかではなく、第1実施形態でも述べたようにバイトコードアプリケーション動作中のみすなわち、BDJタイトル再生中のみポートを開放する、もしくはバイトコードアプリケーションからポート開放の命令を受け取ってから開放する等の処理を行うことになる。ステップS104においてバイトコードアプリケーションとの接続に成功した場合、デジタルコピーモジュール35は次にバイトコードアプリケーションからコピー対象となる携帯端末向け保護コンテンツの格納位置が指定されるのを待つステップS401。コピー対象となる携帯端末向け保護コンテンツの格納位置は、メディアの種類を含んだ絶対パスとなる。例えばBDROM上であれば、指定される絶対パスはmntbdromEMOVEDATA01等になり、ローカルストレージセキュアなメモリカード104等上であればmntsdcardBUDA081A24ED12345ABCEMOVEDATA01等になる。この場合、mntbdromはBDROMメディアのマウントポイントに当たり、mntsdcardはセキュアなメモリカード104のマウントポイントに当たる。すなわち、バイトコードアプリケーションより指定されるファイルパス情報の中にメディアのマウントポイントを含めることで、デジタルコピーモジュール35はコピー対象の携帯端末向け保護コンテンツがどのメディア上にあるのか判断することができる。ステップS401で取得したコピー対象の位置情報、及びその位置情報から判断できるメディアの種類は、ステップS107において選択されたメディアの種類との比較に用いるステップS402。ステップS401で指定されたメディアすなわちコピー元のメディアとステップS107で指定されたメディアすなわちコピー先のメディアが同一でなければ、ステップS108で残コピー回数及び空き容量の確認を行い、同一の場合は空き容量の確認をスキップして残コピー回数の確認のみ行うステップS403。デジタルコピーモジュール35はステップS403で残コピー回数が残っていると判断した場合、ステップS401で指定されたコピー対象を、同一メディア内のビデオ領域にムーブするステップS404。同一メディア内のムーブの場合、実際のデータコピーは不要であり、ファイルの管理情報書き換えだけで済むため、短時間で処理が終わる。そのため、バイトコードアプリケーションによるユーザへの進捗表示はスキップしてもよい。以上の構成によれば、BDROM上に予め携帯端末向け保護コンテンツが記録されていなくとも、追加で携帯端末向け保護コンテンツをダウンロードし、かつデジタルコピー処理プロセスの中でコンテンツのムーブを行うことで、デジタルコピーを実施することが可能となる。また、ダウンロードした先とデジタルコピーのコピー先が同一メディアの場合は、不必要に容量を消費せず、かつコピー自体を高速に行うことができる。第9実施形態本実施形態では、これまでの実施形態に示した記録媒体の作り方、つまり、記録方法の形態について説明する。本実施形態に係る記録方法は、ストリームファイルであるAVファイル、ストリームファイル以外のファイルである非AVファイルをリアルタイムに作成して、記録媒体におけるAVデータ記録領域、非AVデータ記録領域にダイレクトに書き込むというリアルタイムレコーディングとして実現することができる。それだけではなく、ボリューム領域に記録すべきビットストリームの全体像を事前に作成して、このビットストリームを元に原盤ディスクを作成し、この原盤ディスクをプレスすることで、光ディスクを量産するというプレフォーマットレコーディングも含む。本実施形態に係る記録媒体は、リアルタイムレコーディングによる記録方法、及び、プレフォーマットレコーディングによる記録方法によっても特定されるものでもある。ここで、プレフォーマットレコーディングによる記録方法は、BDROMオーサリング、著作権保護、プレス、プレスで得られたBDROMのパッケージングという過程で構成される。この過程において、BDROMオーサリングの完了後、著作権保護の実行前に、デジタルコピー対応メニューの制作という行程が存在する点が、従来の記録方法と異なる。デジタルコピー対応メニューの制作行程が存在するのは、BDROMの全体メニュー、又は、タイトルメニューから、デジタルコピーのための対話制御メニューを表示させるためである。更にBDROMオーサリングから著作権保護までの過程に並行して、携帯端末向け保護コンテンツを構成するデジタルストリームを生成するためのエンコードと、当該エンコードで得られたデジタルストリームを暗号化するための著作権保行程とが存在する。そして、パッケージングの際封入されるシリアルID、又は、ディスクのプレス行程で、ディスクに書き込まれるシリアルIDの何れかをサーバに登録する行程が存在する。<備考>以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。<機器固有機能のバリエーション>本実施の形態では、再生装置固有の機能としてデジタルコピーを例に述べたが、録画機能や配信サービスと記録媒体上のアプリケーションとの連携も考えられる。すなわち、本発明は再生装置固有の機能としてデジタルコピーに限定されるものではない。例えば、記録媒体上のアプリケーションから録画予約を行う、もしくは配信サービスと連携してダウンロードを行うといったサービスにも応用可能である。<再生装置のバリエーション>上記実施形態では、記録媒体を再生する再生機能のみを持つ再生装置について説明したが、それに限らない。例えば、録画機能を持つ録画再生装置であっても良い。<プログラミング言語のバリエーション>上記実施形態では、アプリケーションのプログラミング言語としてJava登録商標を利用したが、Java登録商標ではなく、UNIX登録商標OSなどで使われているBShellや、PerlScript、ECMAScriptなど他のプログラミング言語であっても良い。<記録媒体のバリエーション>また、上述の実施の形態ではBDROMを再生する再生装置について説明をしたが、書き込み可能な光記録媒体に上述の実施の形態にて説明をしたBDROM上の必要なデータが記録されていた場合においても上述と同様の効果を奏することはもちろんのことである。また、上述の形態ではコピー元の記録媒体として、BDROMまたは書き込み可能な光記録媒体を例に説明をしているが、これに限定をされる必要は無く、例えばSDメモリーカード、メモリースティック、コンパクトフラッシュ、スマートメディア、マルチメディアカード等の可搬性の記録媒体に相当するリムーバブルメディアを用いても構わない。コピー元の記録媒体としてリムーバブルメディアを用いる場合、このコピー元に用いるリムーバブルメディアには、例えば図11に示すボリューム領域に記録されているディレクトリ構造を有するデータに相当するものを記録する領域ユーザ領域、図25で説明をした保護領域およびシステム領域を有する構造である。この場合ではコピー元のリムーバブルメディアに記録された携帯端末向けコンテンツがコピー先のリムーバブルメディアへコピーされることになる。当然のことながら、コピー元のリムーバブルメディアとコピー先のリムーバブルメディアとは別である。コピー元の記録媒体にBDROMを用いた場合では、上述の実施の形態の説明において、例えば鍵情報生成部602では、コピー元からはBDROM上の特殊領域であるBCABurstCuttingAreaに記録されている記録媒体の物理的なシリアルIDを示すPMSNPrerecordedMediaSerialNumberを、読み出す構成である。これに対し、コピー元の記録媒体にリムーバブルメディアを用いる場合には、PMSNを読み出す代りに、コピー元のリムーバブルメディア固有の情報メディアIDを読み出す構成とすればよい。このように上述の実施の形態の説明および図面において、コピー元の記録媒体であるBDROMをリムーバブルメディアと読み替えるとともに、コピー元の記録媒体であるBDROMのシリアルIDをリムーバブルメディアの固有の情報メディアIDと読み替えれば、コピー元の記録媒体にリムーバブルメディアを用いたときの動作の説明となる。また、コピー元の記録媒体としてリムーバブルメディア用いた場合、BDROMのボリューム領域に記録されているディレクトリ構造を有するデータに相当するものを記録する領域ユーザ領域に記録されるデータのうちの一部のデータ例えばストリームデータは、暗号化なされている。コピー元の記録媒体としてリムーバブルメディア用いた場合、ユーザ領域に記録されるデータというのはリムーバブルメディアを頒布時に予め記録されていても良い。この場合、リムーバブルメディアの頒布時において、ユーザ領域に記録されるデータの一部のデータが暗号化されている場合には、暗号化されたデータを復号するためのキー情報タイトルキーを含む復号鍵がコピー元の記録媒体の保護領域に予め記録されている。このとき、復号鍵は、コピー元の記録媒体のシステム領域のMKBを用いて復号ができるように暗号化がなされているものとする。または、コピー元の記録媒体としてリムーバブルメディア用いた場合、このリムーバブルメディアの頒布時にはユーザ領域にデータが記録されていないものの、頒布後、ダウンロード等の要求により、ユーザ領域に、BDROMのボリューム領域に記録されているディレクトリ構造を有するデータに相当ものを記録するようにしても良い。ダウンロード要求を行う装置というのは本実施の形態で説明をした再生装置を用いて行っても良いし、本実施の形態とは別のダウンロードを行うための端末装置を用いて行っても良い。この場合にはまず、ダウンロード要求を行う装置に頒布されたリムーバブルメディアを装填し電気的に接続をされた状態で、データのダウンロードの要求とともに、リムーバブルメディアのメディアIDおよびMKBを読み出して配信サーバへ送る。配信サーバにおいて、リムーバブルメディアのメディアIDおよびMKBを用いて生成される復号鍵と対応するデータをダウンロードの要求を行った装置へ送る。ダウンロードの要求を行った装置では、受信した対応するデータをリムーバブルメディアのユーザ領域へ記録し、受信した公開鍵ファイルをリムーバブルメディアの保護領域に記録する。ユーザ領域に記録されるデータの一部のデータが暗号化されている場合には、暗号化されたデータを復号するためのキー情報タイトルキーを含む復号鍵がコピー元の記録媒体の保護領域に記録されることになる。このとき、復号鍵は、コピー元の記録媒体のシステム領域のMKBを用いて復号ができるに暗号化がなされているものとする。以上のように構成をすれば、リムーバブルメディアをコピー元の記録媒体とすることができる。このようにすれば、ユーザ領域に記録される携帯端末向けコンテンツのみを本実施の形態とは異なる手法で別のリムーバブルメディアへ記録したとしても、別のリムーバブルメディアには復号鍵に関する情報が無いため、不正なコピーによる再生を抑止することができる。万が一にも、別のリムーバブルメディアに復号鍵をも記録できたとしても、別のリムーバブルメディアのMKBはコピー元のリムーバブルメディアのMKBと異なるため、暗号化された復号鍵の復号が行えないため、コピー元のリムーバブルメディアのユーザ領域に記録されたデータの不正な利用を抑止することができる。<コピー中の警告>コピー中はIO処理がデジタルコピー実行部604に占有されるため、BDROM上のコンテンツを正常に再生することができなく恐れがある。そのため、しばらくの間は、再生ができないということ、ディスクを取り出してはいけないということ、及び電源を落としてはいけないということを事前にユーザに通知しておくことが望ましい。とは言え、ユーザが誤ってディスクを取り出したり、電源を落としたりすることは大いに有り得る。しかしながら、復号鍵書込の処理は、この時点では完了しておらず、残コピー回数は減っていないため、ここでデータコピーに失敗しても残コピー回数が減るということはない。デジタルコピーサーバ36側で管理している残コピー回数は、次のステップで復号鍵をデジタルコピーサーバ36からダウンロードした時点で減ることになる。<携帯端末向け保護コンテンツが存在するかどうかの判断>EMOVEディレクトリの有無で判断するのではなく、他に携帯端末向け保護コンテンツの存在を示すファイルを予め決めておき、そのファイルの有無でディスク上に携帯端末向け保護コンテンツが存在するかどうかを判断してもよい。<メディアの一覧表示>メディアの一覧表示時において、空き容量が不足している、もしくはメディアが未挿入であると予め判断できたメディアには、空き容量が不足している、もしくはメディアが未挿入であるというマークもしくはフラグをつけてもよい。<デジタルコピーサーバ36への接続URL>デジタルコピーサーバ36への接続URLは再生装置が保有する固定のものを利用してもよいし、バイトコードアプリケーションから指定されたURLを用いても良い。デジタルコピーサーバ36はコンテンツ提供者毎、地域毎に異なるサーバになる可能性がある。よって、バイトコードアプリケーションから通信ポートを介して指定されたURLを使ってデジタルコピーサーバ36へ接続するのが望ましい。<サーバ証明書>サーバ証明書、つまり、SSLソケット作成用に再生装置がバイトコードアプリケーションに送るデジタル証明書は、装置固有機能を利用するために用いられるデジタル証明書とは別にしてもよい。この場合、再生装置は暗号化通信用と固有機能用の2種類のデジタル証明書を用意する。加えて、再生装置の不正を防ぐために、バイトコードアプリケーション側で再生装置から送られてくるサーバ証明書の正当性を検証してもよい。例えば、無秩序にコピー可能な再生装置が出回る恐れもあるため、バイトコードアプリケーション側でも再生装置の正当性を検証するのが望ましい。再生装置から送られてくるサーバ証明書を検証し、もしそのサーバ証明書がブラックリストに載っていれば、その再生装置ではデジタルコピー等の実施をバイトコードアプリケーション側で止めることができる。<処理のバリエーション>第8実施形態では、同一メディアにおけるデジタルコピーについては、不必要にメディア容量を消費しない、かつデータコピーを短時間で終えることができるという観点からムーブを前提に記載したが、十分な空き容量が存在する場合、またはコピー対象となるコンテンツのサイズが小さい場合は、元となるファイルを残してコピーを行っても良い。<コピーソースユニットのバリエーション>本編コンテンツに、4つのバリエーションが存在していて、本編コンテンツ再生時に、これら、4つのバージョンのうち、任意のものを再生することができる場合、これら4つのバージョンのそれぞれに対応する携帯端末向け保護コンテンツを、DATA01ディレクトリ、DATA02ディレクトリ、DATA03ディレクトリ、DATA04ディレクトリに記録しておいてもよい。こうすることで、視聴することができる様々なバリエーションの本編コンテンツを、任意にコピーすることができる。<バイトコード>これまでの実施形態で説明に使用したバイトコードは、例えば、オペランドスタック、ローカル変数、オブジェクト配列に対する操作をJava仮想マシンに実行させる語長が2バイト以下のコードを想定している。オペランドスタック、ローカル変数、オブジェクト配列に対する操作には、オペランドスタックからの取り出し、オペランドスタックへの蓄積、オブジェクト配列からのオブジェクト参照の取り出し、オブジェクト配列へのオブジェクト参照の格納、メソッド終了及び呼出元へのリターン、値の型変換、比較、オペランドスタックに対する加算/減算/乗算/剰余算、符号反転、語挿入を伴うコピーがある。このような特性をもち、バイトコードと技術的に同視することができるプログラムコードであるなら、アプリケーションの作成にそのようなプログラムコードを用いてもよい。<クラスファイル>バイトコードアプリケーションは、クラスファイルのインスタンスである。ここでクラスファイルは、例えば、幾つかのブロックから構成され、そのブロックが細部構造をもっていて、様々なデータの階層管理が可能なデータ構造をもつ構造体ファイルをいう。この細部構造とは、複数のコンスタントプール、複数のフィールドインフォ、複数のメソッドインフォ、複数のアトリビュートインフォが存在するというものである。アトリビュートインフォは、抽象クラスであり、そのサブクラスがクラスファイル、フィールドインフォ、メソッドインフォの下位構造となる。例えば、アトリビュートインフォのうちコード属性は、メソッドインフォの属性となる。このメソッドインフォにより、バイトコードアプリケーションのプログラム的性質が規定される。このような特性をもち、かかるクラスファイルの内部構成と技術的に同視することができるデータ構造であるなら、バイトコードアプリケーションの作成に、そのようなデータ構造を用いてもよい。<集積回路の実施形態>本発明にかかる集積回路は、システムLSIであり、再生装置のハードウェア構成のうち、記録媒体のドライブ部や、外部とのコネクタ等、機構的な部分を排除して、論理回路や記憶素子に該当する部分、つまり、論理回路の中核部分を内蔵したものである。システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものはマルチチップモジュールと呼ばれるが、このようなものに、システムLSIに含まれる。ここでパッケージの種別に着目するとシステムLSIには、QFP、PGAという種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。これらのピンは、電源供給やグランド、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置の中核としての役割を果たす。図34は、集積回路のアーキテクチャを示す図である。本図に示すように、システムLSIである集積回路70のアーキテクチャは、フロントエンド部71と、信号処理部72と、バックエンド部73と、メディアIO74と、メモリコントローラ75と、ホストマイコン76とから構成され、メディアIO74、メモリコントローラ75を通じて、再生装置におけるドライブやメモリ、送受信部と接続されている。再生装置におけるドライブには、BDROMのドライブ、ローカルストレージのドライブ、リムーバブルメディアのドライブ等がある。フロントエンド処理部71は、プリプログラムされたDMAマスタ回路やIOプロセッサ等から構成され、パケット処理全般を実行する。このパケット処理には、デマルチプレクサによるソースパケットデパケッタイザの処理、PIDフィルタの処理が該当する。再生装置のメモリに確保された、トラックバッファ、各種プレーンメモリ、各種バッファ間でDMA転送を実現することにより、上述したようなパケット処理を実現する。信号処理部72は、信号処理プロセッサやSIMDプロセッサ等から構成され、信号処理全般を実行する。信号処理には、ビデオデコーダによるデコードやオーディオデコーダによるデコードがある。バックエンド部73は、加算器、フィルタから構成され、AV出力処理全般を行う。AV出力処理には画素処理があり、かかる画素処理によってレイヤ合成のための画像重畳、リサイズ、画像フォーマット変換がなされる。また、デジタル/アナログ変換等を併せて実行する。メディアIO74は、ドライブ、ネットワークとのインターフェイスである。メモリコントローラ75は、メモリアクセスのためのスレーブ回路であり、フロントエンド部、信号処理部、バックエンド部の要求に応じて、パケットやピクチャデータのメモリの読み書きを実現する。このメモリコントローラ75を通じたメモリの読み書きによって、メモリは、トラックバッファやビデオプレーン、グラフィクスプレーン、ビデオデコーダにおける各種バッファとして機能することになる。ホストマイコン76は、MPUROMRAMから構成され、メディアインターフェイス、フロントエンド部、信号処理部、バックエンド部に対して、全体制御を実行する。この全体制御には、再生制御部、バイトコード処理モジュール、コマンド処理モジュール、モード管理モジュールとしての制御がある。このホストマイコンにおけるCPUは、命令フェッチ部、デコーダ、実行ユニット、レジスタファイル、プログラムカウンタを有している。そして、これまでの実施形態で述べた各種処理を実行するプログラムは、組込プログラムとして、基本入出力システム、様々なミドルウェアと共に、このホストマイコンにおけるマイコン内のROMに記憶されている。よって再生装置の主たる機能は、このシステムLSI内に組込んでおくことができる。<プログラムの実施形態>各実施形態に示したプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVAバイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを1つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムを非一時的なコンピュータプログラムとしてコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。"