WO2011155098A1

WO2011155098A1 - 再生装置、記録媒体、再生方法、プログラム

Info

Publication number: WO2011155098A1
Application number: PCT/JP2011/000496
Authority: WO
Inventors: 田中　敬一; 大戸　英隆
Original assignee: パナソニック株式会社
Priority date: 2010-06-10
Filing date: 2011-01-28
Publication date: 2011-12-15
Also published as: EP2581908A4; CN102369577A; JP2012018672A; EP2581908A1; US20110305435A1; US8588580B2; JPWO2011155098A1; JP5416172B2; CN102369577B; JP4814407B1

Abstract

　再生装置におけるバイトコード処理部は、プラットフォーム部２０であり、リードオンリーメディア１０５からバイトコードアプリケーションを読み出して動作させる。再生装置は、デジタルストリームによるAV再生を制御する再生制御部１０、コンテンツに対する制御機能であって、機器固有のものを実行する機器固有機能制御部３３を具備している。バイトコードアプリケーションが利用することができるAPIには、再生制御機能のためのAPIと、ソケット通信のためのAPIとがある。バイトコードアプリケーションは、再生制御の実行を再生制御部１０に要求する場合、再生制御APIをコールすることで、再生装置の再生制御部に処理を命じる。再生装置の機器固有機能の実行を要求する場合、ソケット通信APIにおける関数のコールを通じて機器固有機能制御部に処理を命じる。

Description

再生装置、記録媒体、再生方法、プログラム

　本発明は、バイトコードアプリケーションの制御技術の技術分野に属する。

　バイトコードアプリケーションとは、オブジェクト指向プログラミング言語のソースコードを用いて記述されたクラス構造体をコンパイルすることで得られた実行形式のプログラムであり、機器に依存しないコード(バイトコード)によって構成されるものをいう。近年の再生装置では、コンテンツ再生のための再生制御のみならず、その他の対話的な制御、追加的な制御を、このバイトコードアプリケーションに実行させることにより、再生装置やコンテンツの付加価値を高めることに成功している。

　こうしたバイトコードアプリケーションに利用させる機能の1つとして、再生装置に実装すべき機能には、以下の特許文献に記載されたコンテンツのコピー機能がある。

特開２０１０-９４０７号

　ところで、あるメーカーが、コンテンツを対象とした特殊な機能の開発に成功した場合、その機能を機器固有機能として実装するのがよいのか、標準化機能として実装するのがよいのかの選択に悩むことが多い。

　機器固有機能として実装する場合、装置設定のためのセットアップメニュー等の、装置固有のユーザインターフェイスを通じて、起動できるようにするのが一般的である。しかし、特殊機能を機器固有機能として実装しようとすると、特殊機能を起動するためのユーザインターフェイスは、メーカーが作成したものに制限されるので、コンテンツプロバイダが作成したユーザインターフェイスに比べて貧弱感が否めない。よって、特殊機能の使い方が判りにくいものになり、ユーザメリットが低い。

　これに対して特殊機能を標準化機能として実装する場合、そのような標準化機能を利用した多くのアプリケーションが様々なコンテンツプロバイダによって開発され、市場に投入されると予想される。特殊機能を起動するためのユーザインターフェイスが多種多様なものになり、ユーザは、より判りやすく親しみ易いユーザインターフェイスを通じて、特殊機能を利用することができる。しかし、特殊機能のためのAPIを策定して公開すると、後発メーカーは、何等、研究開発費を投じることなく、同様の機能を具備した製品を開発して市場に投入することができる。先行メーカーは、後発メーカーの激しい追いあげを受けることで、市場での販売シェア獲得競争に敗北してしまうばかりか、研究開発費を回収できず、苦境に立たされるという由々しき事態も考えられる。

　以上の二通りの実装の仕方のそれぞれには、ユーザに対する判りやすさが犠牲になるか、後発メーカーの台頭を許すかというデメリットが存在し、最適解が見出せない。

　本発明の目的は、特殊機能を機器固有機能として再生装置に実装しつつも、当該機器固有機能を利用したアプリケーションを、様々なコンテンツプロバイダに開発させることができる再生装置を提供することである。

　上記目的を達成することができる再生装置は、記録媒体に記録されたコンテンツを再生すると共に、当該コンテンツに対する機能を実行する再生装置であって、
　前記コンテンツに対する機能には、標準化された再生制御機能と、機器固有の機器固有機能とがあり、
　記録媒体からバイトコードアプリケーションを読み出して、動作させるプラットフォーム部と、
　再生制御機能を実行する再生制御部と、
　機器固有機能を実行する固有機能制御部とを備え、
　前記再生装置のプラットフォーム部は、バイトコードアプリケーションが利用可能なプログラミングインターフェイスを有し、前記バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含み、
　前記バイトコードアプリケーションは、再生制御用プログラミングインターフェイスをコールすることで、再生制御部に再生制御を命じ、
　通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、固有機能制御部に機器固有の制御を命じる
　ことを特徴とする。

　ソケット接続のためのプログラミングインターフェイスは、ネイティブAPIとしてサポートされている機能であるから、機器固有機能制御部に対してソケット接続を行うことで、機器固有機能の実行を機器固有機能制御部に要求すれば、既に標準化されているデジタルストリーム再生制御のためのAPIに対して、追加／改変を加えることなく、アプリケーションに機器固有機能を使用させることができる。既存の再生制御のためのAPIに追加／改変を加えることなく、機器固有機能を使用させるので、特殊機能を利用したアプリケーションが様々なコンテンツプロバイダが開発され、市場に投入されると予想される。その結果、特殊機能を起動するためのユーザインターフェイスが多種多様なものになり、ユーザは、より判りやすく親しみ易いユーザインターフェイスを通じて、特殊機能を利用することができる。

　機器固有機能として実装する限り、後発メーカーの追従を避けることができるから、特殊機能を機器固有機能として実装した製品により、市場を寡占することができる。

　先行メーカーが、コンテンツプロバイダに特殊機能を利用させ、その独自開発に成功したメーカーのみが、ライセンスを、コンテンツプロバイダから得るというもの新たな収益スタイルの確立が容易になり、メーカーによる研究開発に弾みを付けることができる。

　以上が、解決しようとする課題欄で述べた技術的課題の解決を図る技術的思想の創作である。つまり任意的ではあるが、上記再生装置は、以下のような追加的な技術的課題の解決を図るものであってもよい。

　(追加的技術的課題その１)
　特殊機能を標準化機能として実装するにあたって、既に標準化されているAPIの拡張は難しいため、コンテンツ提供者が先行してオリジナリティのある新しいサービスを提供したい場合、再生装置上での独自サービス提供はあきらめる傾向が強い。代替策として、パソコンにインストールして実行するアプリケーションを映画本編とは別のディスクに記録しておき、ユーザにそのディスクをパソコンで実行してもらうことで、独自サービスを提供するという方法が主流になっている。実際に行われているサービス例としては、携帯端末向けデジタルストリームとパソコン用アプリケーションを本編ディスクとは別ディスクの中に記録しておき、そのディスクをパソコン上で実行し、ディスクに記録されている携帯端末向けデジタルストリームをパソコンに接続中の携帯端末にコピーすることで、携帯端末上での映画持ち出し視聴を可能にするサービス（通称「デジタルコピー」）が普及している。だが、上記のようなサービス提供方法では、１.コンテンツ提供者はパソコン上での実行用ディスクを本編とは別に用意しなければならない、２.映画視聴にパソコンを利用していないユーザでも、サービス実行のためには、わざわざパソコンを利用しなければならない、３.サービス提供がパソコンを介して行われることになるため、機器メーカーは、再生装置の機能アピールができない、など課題が多くあり、コンテンツ提供者、ユーザ、機器メーカーのそれぞれにデメリットがあった。

　本発明の他の目的は、リードオンリーメディア上のアプリケーションプログラムと再生装置の独自機能を連携させたサービスを、他の再生装置との互換性を維持しつつ、かつパソコン等の第三の機器を介することなく提供することである。

　かかる目的を達成するための再生装置は以下のものである。

　即ち、前記記録媒体は第１記録媒体であり、第１記録媒体には、ルートディレクトリの配下に第１ディレクトリと、第２ディレクトリとが存在し、
　第１ディレクトリは、本編コンテンツが記録されているディレクトリであり、前記バイトコードアプリケーションは、第１ディレクトリに記録されており、
　第２ディレクトリは、持出し視聴用コンテンツが記録されており、当該持出し視聴用コンテンツは、本編コンテンツとは異なるフォーマットのコンテンツであって、機器固有機能の対象となるものであり、
　前記機器固有機能とは、持出し視聴用コンテンツを構成するファイルを、第１記録媒体から第２記録媒体へと、コピーするというメディア間コピーである
　ことを特徴とする。

　第１ディレクトリに記録された映画本編と、第２ディレクトリに記録された携帯端末向け保護コンテンツを１枚のディスクにまとめることができ、かつディスク上のアプリケーションから、携帯端末向け保護コンテンツの転送を制御できるので、パソコン不要であり再生装置だけで持ち出し視聴サービスを実現することができる。

　更に、任意的ではあるが、上記再生装置は、以下のような追加的な技術的課題の解決を図るものであってもよい。

　(追加的技術的課題その２）
　新規に開発した特殊機能を標準出力関数として実装するために、プレーヤモデルの標準出力関数に新たなAPIを追加するとなると、追加されたAPIを保持していない再生装置では、追加APIを利用するアプリケーションを正常に起動させることができなくなるという下位互換の問題が当然に発生する。具体的には、アプリケーションを起動する段階において、再生装置はアプリケーションが利用するAPIと再生装置が実装しているAPIのリンク処理が行われるが、再生装置が保持していないAPIをアプリケーションが利用していた場合、リンクエラーとなり、アプリケーションの起動自体に失敗するという問題がある。上記問題に対する一つの回避策は、既存APIのみを使うアプリケーションと、追加APIを使うアプリケーションを分けて用意しておき、再生装置のバージョン等を確認して、起動するアプリケーションを変えるという方法である。しかしながら、今後多種多様の機能が追加され、それら機能毎に各再生装置がAPIを拡張していくとなると、どの範囲までのAPIが安全に使え、どの範囲から別アプリケーションにすべきか管理が煩雑になり、異なるメーカ間の再生装置におけるアプリケーション互換性確保が極めて難しくなる。そのため、新機能を追加する際は、標準化団体等で互換性問題が起こらぬよう慎重にAPIを定義し、追加したAPIを機器メーカ、アプリケーション開発者に公開することで、どの範囲までのAPIが安全に使え、どの範囲から別アプリケーションにすべきかを明確にし、新しい機能が追加された機器を過去機種で再生させた場合でも、問題なく再生できるよう配慮がなされている。しかしながら、新機能追加の際、常にこのようなプロセスが必要となると、追加APIの定義には慎重にならざるを得ないために、確定するまでに時間がかかり、再生装置とアプリケーションがもたらすサービス進化が滞るという問題が起こる。

　本発明の別の目的は、APIの標準化を図ることなく、バイトコードアプリケーションの安定的な起動を実現することができる、再生装置を提供することである。

　上記目的を達成するための再生装置は、以下のもの図である。即ち、
　前記第１記録媒体の第１ディレクトリには、機器固有機能のためのオンメディアライブラリが記録されており、オンメディアライブラリは、第１ディレクトリに記録された他のバイトコードアプリケーションに、機器固有機能実行のためのプログラミングインターフェイスを提供するものであり、
　前記オンメディアライブラリは、
　他のバイトコードアプリケーションから、機器固有機能実行用プログラミングインターフェイスのコールがなされた場合、当該プログラミングインターフェイスのコールをソケットコマンドに変換した上で固有機能制御部に出力し、固有機能制御部からのレスポンスを戻り値又はイベントに変換して、コールを行った他のバイトコードアプリケーションに返し、
　前記ソケット接続は、前記ソケットコマンド及びレスポンスを伝送するための通信路を構成する
　ことを特徴とする。

　第１記録媒体に記録されたオンメディアライブラリは、機器固有機能の利用に際して、ソケット接続のためのAPIを利用するので、アプリケーションを起動する段階には、第１記録媒体に記録されたオンメディアライブラリが利用するAPIと、ソケット通信のための再生装置内のネイティブAPIとのリンクが成功する確率が高く、アプリケーションの起動自体に失敗することはない。

　また、ソケット通信のためのプログラミングインターフェイスを利用する限り、既存APIのみを使うアプリケーションと、追加APIを使うアプリケーションとを分けて用意することも不要であり、異なるメーカ間の再生装置におけるアプリケーション互換性確保が難航することはない。

　新機能追加の際、追加API定義のための慎重な配慮は不要となるので、再生装置とアプリケーションがもたらすサービス進化が滞ることはない。アプリケーションと再生装置間で行われる機器固有機能に関する通信データのプロトコル解析をライブラリで一元管理することが可能となり、アプリケーション本体でプロトコル解析を行う必要がなくなるため、アプリケーションの生産性を向上させることができる。　

　任意的であるが、前記再生装置はさらに、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルの正当性を検証する検証部を備え、
　前記検証部は、再生装置内に組み込まれた認証鍵を元に、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルのハッシュ値を算出し、
　前記算出されたハッシュ値が、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルに含まれるデジタル署名の値と一致していれば、バイトコードアプリケーションは、正当であると判断し、
　前記検証部がデジタル署名ファイルが正当でないと判断した場合、前記固有機能制御部はバイトコードアプリケーションから前記再生制御とは異なる機器固有の機能に関連したコマンドを受け取っても、前記再生制御とは異なる機器固有機能の実行を拒否してもよい。

　アプリケーションと再生装置間の通信データの内容を暗号化することができるため、通信データの内容を不正にモニタリングし、得られた再生装置の固有機能に関する情報を悪用するという行為を防ぐことができる。

本発明に係る再生装置の、使用行為についての形態の一例を示す図である。第１実施形態に係る記録媒体における内部構成と、動作モードオブジェクトの内部構成とを示す。再生装置の内部構成を示す。再生装置におけるソフトウェアレイヤ構成を示す。外部サーバ３４と、再生装置における機器固有機能制御部３３とを示す図である。バイトコードアプリケーションが機器固有機能を利用するための、バイトコードアプリケーションの処理手順を示すフローチャートである。デジタルコピーにおける、再生装置内外のデータの流れを示す。バイトコードアプリケーション、デジタルコピーモジュール３５、及びデジタルコピーサーバ３６とのデータ送受信を示すシーケンス図である。デジタルコピーモジュール３５を詳細化した図である。デジタルコピーモジュール３５におけるデジタルコピープロセスのフローチャートである。 BD-ROMの構成を示した図である。ストリーム形式が異なる、複数の携帯端末向け保護コンテンツが記録されているBD-ROMのディレクトリ構成の一例を示す。 index.bdmvファイルとタイトルの関係の一例と、各タイトルのBD-Jオブジェクトにおけるアプリケーション管理テーブルの内容、プレイリストアクセス情報の内容とを示す。アプリ内API呼出しの詳細を示すシーケンス図である。デジタルコピーモジュール３５の状態遷移を示す図である。端末内ローカル通信の詳細を示すシーケンス図である。 BD-Jアプリケーションによる機能確認から初期化までの処理手順を示すフローチャートである。コピー先状態確認からパラメータセットまでの処理手順を示す。コピーソース格納ディレクトリの選択手順の詳細を示すサブフローチャートである。 BD-Jアプリケーションによる残りコピー回数の確認から鍵書き込みまでの処理手順を示すフローチャートである。デジタルコピーの過程で、表示される表示画面の一例を示す図である。デジタルコピーモジュールの処理手順を示すフローチャートである。図２２のフローチャートの続きである。図４に示したバイトコード処理モジュールであるプラットフォーム部２０のより具体的な構成を示す図である。ローカルストレージとして使用されたセキュアなメモリカードにおけるディレクトリ構成を示す図である。従来におけるアプリケーションの署名検証を示す図である。再生装置が保有するデジタル証明書をベースとした署名検証を示す図である。署名検証の結果に応じた機能制限を示す図である。装置固有機能を利用するため接続要求時における処理のフローチャートである。再生装置にて途中までコンテンツを視聴し、途中から携帯端末で視聴する一例を示す図である。第７実施形態におけるデータコピーのフローチャートである。コピー元とコピー先が同一記録媒体におけるデジタルコピーを示す図である。コピー元とコピー先が同一記録媒体におけるデジタルコピーに対応したフローチャートである。本発明にかかる集積回路のアーキテクチャを示す図である。

　以下本発明の実施の形態について、図面を参照しながら説明する。

　上記課題解決手段を具備した再生装置の発明は、パッケージ媒体を再生するためのプレーヤ機器として実施することができ、集積回路の発明は、当該プレーヤ機器に組込まれるシステムLSIとして実施することができる。再生方法の発明は、このプレーヤ機器で実現される時系列手順として実施することができる。プログラムの発明は、コンピュータ読み取り可能な記録媒体に記録され、プレーヤ機器にインストールされる実行形式プログラムとして実施することができる。

　（第１実施形態）
　第１実施形態は、機器固有機能を実現するための再生装置内外の通信についての改良に関する。

　先ず始めに、本発明に係る再生装置の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る再生装置の、使用行為についての形態の一例を示す図である。図１において、本発明に係る再生装置は、再生装置１０１である。この再生装置１０１は、リモコン１０２、テレビ１０３、セキュアなメモリカード１０４、リードオンリーメディア１０５、携帯端末１０６、セキュアなメモリカード１０７と共に、ホームシアターシステムを形成する。

　再生装置１０１はSDメモリーカード、メモリースティック、コンパクトフラッシュ（登録商標）、スマートメディア、マルチメディアカード等のリムーバブルメディア１０４を挿入するための挿入口を備える。加えて携帯端末１０６と接続するためのUSB等の挿入口も備える。

　リモコン１０２は、再生装置１０２の付属物であり、再生装置１０２に対する操作をユーザから受け付けて、操作に応じた指示信号を再生装置１０２に送信する。再生装置に対する操作としては、リードオンリーメディアの再生制御を再生装置に実行させるための操作、機器固有機能を再生装置に行わせるための操作がある。また再生装置１０１は、ネットワーク通信機能を有し、外部サーバとの通信を行うことができる。

　テレビ１０３は、映画作品の再生映像を表示したり、メニュー等を表示することで、対話的な操作環境をユーザに提供する。

　セキュアなメモリカード１０４は、再生装置で機器固有機能を実行するにあたって、機器固有機能によりコピーされた携帯端末向け保護コンテンツの受け皿として用いられる記録媒体であり、例えば、microSDカード、SDHCカードが該当する。このセキュアなメモリカード１０４には、保護領域、システム領域が存在しており、保護領域には暗号化された復号鍵が存在する。システム領域には、復号鍵を復号するためのメディアID(MID)、メディアキーブロック(MKB)が存在する。

　リードオンリーメディア１０５は、ホームシアターシステムに、映画作品を供給するための記録媒体である。

　携帯端末１０６は、セキュアなメモリカード１０４の装填が可能であり、セキュアなメモリカード１０４に書き込まれた携帯端末向け保護コンテンツを利用することができる。この場合、セキュアなメモリカード１０４の保護領域に書き込まれた暗号化復号鍵をコピー先のメディアのシステム領域に記録されたMKBを用いて復号し、復号鍵に含まれるキー情報（タイトルキー）を取り出し、取り出したキー情報を用いて、携帯端末向け保護コンテンツに含まる暗号化されたデジタルストリームを必要に応じて復号して利用する。ここでの利用とは、持出し視聴用コンテンツに復号して再生することをいう。

　以上が、ホームシアターシステムについての説明である。続いて記録媒体の詳細について説明する。

　図２（ａ）は、第１実施形態に係る記録媒体における内部構成を示す。本図（ａ）に示すように、第１実施形態に係る記録媒体には、本編コンテンツ、携帯端末向け保護コンテンツが記録されている。

　本編コンテンツは、リードオンリーメディア１０５の記録方式や保護方式で格納されたコンテンツであり、ストリームファイル２０１、ストリーム情報ファイル２０２、プレイリスト情報ファイル２０３、インデックステーブル２０４、アーカイブファイル２０５、動作モードオブジェクト２０６から構成されている。

　ストリームファイル２０１は、ビデオストリーム、１つ以上のオーディオストリーム、グラフィクスストリームを多重化することで得られたトランスポートストリーム形式のデジタルストリームを格納している。

　ストリーム情報ファイル２０２は、ストリームファイルにおけるトランスポートストリーム内の任意のソースパケットに対するランダムアクセスや、他のトランスポートストリームとの途切れ無き再生を保障する。このストリーム情報ファイルを通じることにより、ストリームファイルは「AVクリップ」として管理されることになる。ストリーム情報ファイルは、AVクリップにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、GOPの先頭位置のソースパケット番号を、フレーム期間のプレゼンテーションタイムスタンプと対応付けて示すエントリーマップをもっているので、ストリームファイルのアクセスに先立ち、このストリーム情報ファイルをメモリにロードしておけば、アクセスしようとするストリームファイル中のトランスポートストリームがどのようなものであるのかを把握することができるので、ランダムアクセスの実行を保障することができる。

　プレイリスト情報ファイル２０３は、再生装置にプレイリストを再生させるための情報を格納したファイルである。“プレイリスト”とは、トランスポートストリーム(TS)の時間軸上で再生区間を規定するとともに、この再生区間同士の再生順序を論理的に指定することで規定される再生経路であり、TSのうち、どれをどの部分だけ再生して、どのような順序でシーン展開してゆくかを規定する役割をもつ。プレイリスト情報は、かかるプレイリストの「型」を定義する。プレイリスト情報によって定義される再生経路は、いわゆる「マルチパス」である。マルチパスとは、主となるTSに対して定義された再生経路(メインパス)と、従となるTSに対して定義された再生経路(サブパス)とを束ねたものである。

　インデックステーブル２０４は、再生装置におけるタイトル番号レジスタに格納され得る複数のタイトル番号と、動作モードを規定する動作モードオブジェクトとの対応付けを規定する。記録媒体に記録されているタイトルとは、タイトル番号によって特定される動作モードオブジェクトと、この動作モードオブジェクトから再生されるプレイリストとの組みをいう。ここで、タイトル番号レジスタにおけるタイトル番号は、０、１～９９９、不定値(0xFFFF)という番号がある。タイトル番号０は、トップメニュータイトルのタイトル番号である。トップメニュータイトルとは、ユーザによるメニューコール操作によって呼び出すことができるタイトルである。不定値(0xFFFF)のタイトル番号は、ファーストプレイタイトルのタイトル番号である。ファーストプレイタイトルとは、記録媒体の装填直後に、視聴者への警告やコンテンツプロバイダによるロゴ表示等を行うタイトルである。インデックステーブル２０４は、各タイトル番号のそれぞれに対応したエントリー(タイトルインデックス)を有し、個々のタイトルインデックスに、動作モードを規定する動作モードオブジェクトを記述することで、各々のタイトルが、どのような動作モードで動作するのかを詳細に規定する。

　アーカイブファイル２０５は、バイトコードアプリケーションのクラス構造体のファイル(クラスファイル)を、デジタル証明書マニフェストファイル、ディスク署名シグネチャファイル、ディスク署名暗号鍵ファイル、パーミッションリクエストファイルとひとまとめにしてアーカイブしたファイルである。アプリケーションのロードは、このアーカイブファイルをひとまとめにしてなされ、クラスロード時に、デジタル証明書、ディスク署名、ディスク署名暗号鍵を用いたアプリケーションの正当性の検証ができるようになっている。またパーミッションリクエストファイルが存在するので、アプリケーションによる動作を、一定の権限が与えられたのものに限定することができる。

　動作モードオブジェクト２０６は、インデックステーブルにおいて何れかのタイトル番に対応付けられている制御単位であり、対応するタイトル番号がカレントタイトルとしてタイトル番号レジスタに設定された際、そのタイトル番号に対応するタイトルをどのように動作させるかを示す。

　図２（ｂ）は、動作モードオブジェクトの内部構成を示す。本図に示すように、動作モードオブジェクトは、「アプリケーション管理テーブル」、「端末管理テーブル」、「アプリケーションキャッシュ情報」、「プレイリストアクセス情報」、「キー割当テーブル」から構成される。
「アプリケーション管理テーブル」は、タイトルをバウンダリィとしたクラスロードやアプリケーションシグナリングをアプリケーションマネージャやクラスローダに指示する制御テーブルであり、「端末管理テーブル」は、GUIを実現するためのHAViデバイスコンフィグレーションやGUIに用いるフォント、ユーザ操作のマスクの有無をマルチディアホームプラットフォーム(MHP)に指示する管理テーブルである。「アプリケーションキャッシュ情報」は、タイトル選択時のアーカイブファイルのキャッシュイン／キャッシュアウトをキャッシュマネージャに指示する制御テーブルであり、「プレイリストアクセス情報」タイトル選択時におけるプレイリストアクセスの指定を再生制御部に指示する制御テーブルである。「キー割当テーブル」は、キーと、イベントとの対応付けをイベントマネージャに指示する制御テーブルである。

　「クラスロード」とは、アーカイブファイルにアーカイブされているクラスファイルのインスタンスを、プラットフォームのヒープ領域に生成する処理であり、ヒープ領域に生成したインスタンスが存在する間は、ヒープ領域に生成したインスタンスであるアプリケーションが実行可能となる。「アプリケーションシグナリング」は、クラスファイルのインスタンスであるアプリケーションを自動起動させるか否か、又は、アプリケーションが実行可能となる生存区間をタイトルバウンダリーとするかディスクバウンダリーとするかを規定する制御である。タイトルバウンダリーとは、タイトルの開始からタイトルの終了までのある時点において、アーカイブファイルにアーカイブされているクラスファイルのインスタンスを、プラットフォームのヒープ領域に生成し、タイトルの終了と同時にアプリケーションであるインスタンスをヒープ領域から消滅させるという管理である。ディスクバウンダリーとは、ディスクを挿入してからディスクをイジェクトするまでのある時点において、アーカイブファイルにアーカイブされているクラスファイルのインスタンスを、プラットフォームのヒープ領域に生成し、ディスクイジェクトと同時にアプリケーションであるインスタンスをヒープ領域から消滅させる管理である。逆にディスクイジェクトがされてもインスタンスをヒープ領域から削除しない制御を「ディスクアンバウンダリー」という。「HAViデバイスコンフィグレーション」は、アプリケーションがGUI処理を実行するにあたってのグラフィクスプレーンの解像度や文字表示に用いるフォント等を規定するものである。

　「プレイリストアクセス」とは、起動されたアプリケーションが再生を命じることができるプレイリストやタイトル選択時に自動的に再生すべきプレイリストの指定である。

　「アーカイブファイルのキャッシュイン」とは、クラスロードの対象となるアーカイブファイルをキャッシュに先読みするとの処理であり、「アーカイブファイルのキャッシュアウト」とは、キャッシュに存在するアーカイブファイルをキャッシュから削除するとの処理である。「キーと、イベントとの対応付け」は、ユーザが操作可能なキーに、アプリケーションのイベントリスナに登録されているイベントを割り当てるというものである。動作モードオブジェクトには、他にもナビゲーションコマンドを用いて再生装置を動作させるための動作モードオブジェクトが存在する。

　以上が本編コンテンツについての説明である。続いて、携帯端末向け保護コンテンツの詳細について説明する。

　携帯端末向け保護コンテンツは、本編コンテンツと同一性を有しつつも、格納方式および保護方式のフォーマットが本編コンテンツの格納方式および保護方式のフォーマットとは異なる持出視聴用コンテンツであり、ストリームファイル２０７、プログラム情報ファイル２０８、管理情報ファイル２０９、コピー情報格納ファイル２１０から構成される。これらストリームファイル２０７、プログラム情報ファイル２０８、管理情報ファイル２０９は、本編コンテンツを構成するストリームファイル２０１、ストリーム情報ファイル２０２、プレイリスト情報ファイル２０３に対応する管理情報である。しかし、コピー情報格納ファイル２１０は、携帯端末向け保護コンテンツ特有のものである。

　コピー情報格納ファイル２１０は、コピー情報を格納しているファイルであり、そのコピー情報の1つとして、コンテンツIDが存在する。コンテンツIDは、携帯端末向け保護コンテンツのそれぞれを識別するためコンテンツプロバイダが供給するコンテンツに対して割り当てた128bitの識別子である。携帯端末向け保護コンテンツのうち、機器固有機能の対象になっているもののコンテンツIDは、サーバのデータベースにおいて管理されている。コンテンツIDは、携帯端末向けコンテンツをそれぞれ一意に識別するために割り当てられている。この識別子のうち、上位の所定ビットは、コンテンツプロバイダを識別するためのものである。

　以上が、本発明に係る記録媒体についての説明である。続いて本発明に係る再生装置の内部構成について説明する。

　図３は、再生装置の内部構成を示す。本図に示すように、再生装置は、ドライブデバイス１、デマルチプレクサ２、ビデオデコーダ３、プレーンセット４、ビデオプレーン４ａ、グラフィクスプレーン４ｂ、レンダリングエンジン５、合成部６、オーディオデコーダ７、機器インターフェイス８、ホストマイコン９、再生制御部１０、ユーザインターフェイス１１、レジスタセット１２から構成される。

　ドライブデバイス１には、リードオンリーメディア１０５のドライブ、セキュアなメモリカード１０４のドライブがある。リードオンリーメディア１０５のドライブは、リードオンリーメディア１０５を装填して、当該記録媒体に記録されたデジタルストリームを構成するソースパケット系列を、バッファを介して読み出す。セキュアなメモリカード１０４のドライブは、セキュアなメモリカード１０４やその他の記録媒体を装填して、アクセスする。USBケーブル等を介して、再生装置に接続されている携帯端末１０６にセキュアなメモリカード１０４が装填されている場合、この携帯端末１０６のドライブにもスロット番号が割り当てられ、“ドライブ”として管理されることになる。これらのセキュアなメモリカード１０４のドライブは、“スロット”という単位で管理される。複数のスロット番号のそれぞれに対応付ける形式で、ドライブに装填されたリードオンリーメディア１０５、セキュアなメモリカード１０４の状態を示すデバイスリストを、“デバイスデバイスリスト”という。

　デマルチプレクサ２は、リードオンリーメディア１０５から読み出されたソースパケット系列に対して多重分離を行い、PESパケットを得て、該当するデコーダに出力する。

　ビデオデコーダ３は、読み出されたビデオストリームを復号して非圧縮形式のピクチャをプレーンセット４に書き込む。

　プレーンセット４は、複数のプレーンメモリから構成される。プレーンメモリとは、一画面分の画素データをライン単位で格納しておき、水平同期信号、垂直同期信号に沿ってこれらの画素データを出力するためのメモリである。個々のプレーンメモリは、ビデオ、字幕、GUI、背景画像のデコードによって得られた1画面分の画素データを格納する。

　これらのプレーンメモリは、レイヤモデルを構成しており、個々のプレーンメモリの格納内容は、レイヤ合成に供される。このレイヤ合成は、プレーンメモリのレイヤモデルにおいて、2つの階層のプレーンメモリに格納されている画素データの画素値を重畳させるという処理を、レイヤモデルにおける2つの階層の全ての組合せに対して実行することでなされる。

　ビデオプレーン４aは、プレーンセットの1つであり、1920×1080の解像度をもつ非圧縮のピクチャデータを格納する。

　グラフィクスプレーン４bは、プレーンセットのうちの1つであり、ビデオプレーンの上の重畳させるべきグラフィクスを非圧縮形式で格納する。ここでの“グラフィクス”とは、これらグラフィクスプレーンに格納されたARGB形式の画素データによって表現される表示内容のことであり、フォントを用いてテキストコードを展開することにより得られた文字、記号のビットマップや、GIF/JPEG/PNGデータをデコードすることで得られるGIF/JPEG/PNGイメージ(“描画イメージ”という)を含む。

　レンダリングエンジン５は、Java2D，OPEN-GLといった基盤ソフトウェアを備え、バイトコードアプリケーションから要求に従ってJPEGデータ／PNGデータのデコードを行い、イメージやウィジェットを得て、グラフィクスプレーンに書き込む。JPEGデータをデコードすることにより得られる画像データは、GUIの壁紙になるものである。PNGデータをデコードすることにより得られる画素データは、グラフィクスプレーンに書き込まれて、アニメーションを伴うボタン表示を実現することができる。これらJPEGデータ／PNGデータをデコードすることで得られたイメージやウィジェットは、バイトコードアプリケーションが、タイトル選択や字幕選択、音声選択を受け付けるためのメニューを表示したり、ストリーム再生連動型のゲームを動作させるにあたって、GUI部品を構成するために使われる。その他、バイトコードアプリケーションがWWWサイトをアクセスする際、そのWWWサイトのブラウザ画面を構成するために用いられる。

　合成部６は、複数のプレーンメモリのレイヤ合成を行う。

　オーディオデコーダ７は、多重分離で得られたPESパケットのうち、オーディオストリームを構成するものをデコードする。

　機器インターフェイス部８は、ホームシアターシステムにおける他の機器とインターフェイスを介して接続された際、相互認証フェーズと、ネゴシエーションフェーズを経てータ伝送フェーズに移行し、データ伝送を行う。このネゴシエーションフェーズは、相手側機器のケーパビリティ(デコード能力、再生能力、表示周波数を含む)を把握して、プレーヤ設定レジスタに設定しておき、以降の伝送のための伝送方式を定めるものである。これらの相互認証フェーズ、ネゴシエーションフェーズを経て、レイヤ合成がなされたピクチャデータにおける一ライン分の非圧縮・平文形式の画素データを、表示装置における水平同期期間に従い表示装置に高い転送レートで転送する。一方、表示装置における水平帰線期間、及び、垂直帰線期間において、再生装置と接続された他の装置(表示装置のみならずアンプ、スピーカを含む)に、非圧縮・平文形式のオーディオデータを転送する。こうすることで、表示装置、アンプ、スピーカといった機器は、非圧縮・平文形式のピクチャデータ、非圧縮・平文形式のオーディオデータを受け取ることができ、再生出力を実現することができる。また、相手側機器にデコード能力が存在する場合、ビデオストリーム、オーディオストリームのパススルー伝送が可能になる。パススルー伝送では、ビデオストリーム、オーディオストリームを圧縮・暗号化形式のまま伝送することができる。

　ホストマイコン９は、MPU,ROM,RAMから構成され、アーカイブファイルをロードすることで得られるバイトコードアプリケーションを間隔し、実行する。

　再生制御部１０は、ドライブデバイス１を制御して、インデックステーブル、動作モードオブジェクト、プレイリスト情報ファイル、ストリーム情報ファイル、ストリームファイルをリードオンリーメディア１０５から読み出すとともに、記録媒体から読み出されたプレイリスト情報、ストリーム情報に基づく再生制御を実行する。ストリームファイルの読み出しにあたっては、時間軸の任意の時点に相当するソースパケットを、ストリームファイルから読み出すというランダムアクセスを実現することができる。

　ユーザインターフェイス１１は、操作装置１０２に対する操作を受け付ける。

　レジスタセット１２は、複数のプレーヤ状態レジスタ、複数のプレーヤ設定レジスタから構成される。プレーヤ状態レジスタは、再生装置のMPUが算術演算やビット演算を行う際、その被演算子となる数値を格納しておくためのハードウェア資源であり、光ディスクが装填された際に初期値が設定され、またカレントタイトル番号やカレントプレイリスト番号の変更等、再生装置の状態が変化した際に、その格納値の有効性が判定されるレジスタである。この格納値としては、カレントタイトル番号、プレイリスト番号、カレントの再生時点等がある。リードオンリーメディア１０５の装填時に初期値が格納されるので、この格納値は一時的なものでありリードオンリーメディア１０５がイジェクトされたり、また再生装置の電源が断たれれば、この格納値は有効性を失う。

　プレーヤ設定レジスタは、電源対策が施されている点がプレーヤ状態レジスタとは異なる。電源対策が施されているので、再生装置の電源遮断時において、その格納値が不揮発性のメモリに退避され、再生装置の電源投入時において、その格納値が復帰される。再生装置の製造主体(マニフャクチャ)が再生装置の出荷時に定めた再生装置の各種コンフィグレーションや、ユーザがセットアップ手順に従い設定した各種コンフィグレーション、そして、再生装置がTVシステムやステレオ、アンプ等のホームシアターシステムの機器と接続された際、接続相手となる機器とのネゴシエーションにより判明した相手側機器のケーパビリティがプレーヤ設定レジスタに設定される。

　以上が再生装置の内部構成についての説明である。続いて、再生装置におけるソフトウェアのレイヤ構成の詳細について説明する。

　図４は、再生装置におけるソフトウェアレイヤ構成を示す。

　基本的なレイヤ構成は、ファイルシステム１３、リアルタイムＯＳ１４が存在し、この上に、コマンド処理モジュール１５及びバイトコード処理モジュール１６が同じレイヤに併存していて、コマンド処理モジュール１５及びバイトコード処理モジュール１６の共通の上位レイヤに、モジュールマネージャ１７が存在するというものである。

　ファイルシステム１３は、ディレクトリ・ファイルといった単位で、リードオンリーメディア１０５やセキュアなメモリカード１０４のアクセスを行わせる。

　リアルタイムOS１４は、組込みソフトウェアのためのオペレーティングシステム(例えば、Linux)であり、当該オペレーティングシステムのカーネル、基本入出力部から構成される。

　コマンド処理モジュール１５は、コマンドインタプリタを含み、ナビゲーションコマンドを解読して実行し、この実行結果に応じて、再生すべきプレイリストを選択するものである。ナビゲーションコマンドは、DVD-Videoと似たようなシンタックスで記述されているため、かかるナビゲーションコマンドを実行することにより、再生装置は、DVD-Videoライクな再生制御を実現することができる。例えば、BD-ROMの再生装置である場合、バイトコード処理モジュール１６は、HDMVモジュールに該当する。

　バイトコード処理モジュール１６は、リードオンリーメディア１０５１０５に記録されたアーカイブファイル内のクラス構造体のインスタンスを動作させるプラットフォーム部２０である。例えば、BD-ROMの再生装置である場合、バイトコード処理モジュール１６は、BD-Jモジュールに該当する。

　モジュールマネージャ１７は、リードオンリーメディア１０５から読み出されたインデックステーブルを保持して、モード管理及び分岐制御を行う。モジュールマネージャ１７によるモード管理とは、動的シナリオをどのコマンド処理モジュール１５、バイトコード処理モジュール１６の何れかに実行させるかという、モジュールの割り当てである。

　以上のレイヤ構成において、リアルタイムOS１４と、バイトコード処理モジュール１６とは、バイトコードアプリケーションのプラットフォーム部２０を構成する。このプラットフォーム部２０は、バイトコードアプリケーションが利用可能なプログラミングインターフェイスを有する。バイトコードアプリケーションが利用可能なプログラミングインターフェイスには、プレイリスト情報を用いたデジタルストリームの再生制御のために標準化されている再生制御用プログラミングインターフェイスと、通信のために標準化されている通信用プログラミングインターフェイスがある。

　次に、バイトコード処理モジュール１６の内部構成について説明する。バイトコード処理モジュール１６は、クラスローダ２１、アプリケーションマネージャ２２、ヒープメモリ２３、バイトコードインタプリタ２４、組込ライブラリ２５、再生制御API２６から構成される。

　クラスローダ２１は、システムアプリケーションの1つであり、アーカイブファイルに存在するクラスファイルからバイトコードを読み出して、ヒープメモリ３１に格納することにより、バイトコードアプリケーションのロードを行う。

　アプリケーションマネージャ２２は、システムアプリケーションの1つであり、動作モードオブジェクト内のアプリケーション管理テーブルに基づき、バイトコードアプリケーションを起動したりバイトコードアプリケーションを終了したりする等、バイトコードアプリケーションのアプリケーションシグナリングを行う。

　ヒープメモリ２３は、システムアプリケーションや組込みライブラリのバイトコード、アプリケーションシグナリングの対象となる一般的なアプリケーションのバイトコード、これらのバイトコードアプリケーションが利用するパラメータが配置されるスタック領域である。

　バイトコードインタプリタ２４は、ヒープメモリ３１に格納されているバイトコードをネィティブコードに変換して、MPUに実行させる。

　組込みライブラリ２５は、バイトコードアプリケーションのためのAV再生機能、ネットワーク通信機能、媒体アクセス機能を提供する。これらのAV再生機能、ネットワーク通信機能、媒体アクセス機能は、標準化団体によって標準化されたものである。

　再生制御API２６は、標準化されている再生制御用プログラミングインターフェイスであり、組込ライブラリ２５を介した再生制御機能を、バイトコードアプリケーションに提供するためのプログラミングインターフェイスである。

　以上がバイトコード処理モジュール１６についての説明である。続いて、リアルタイムOS１４及びファイルシステム１３の内部構成について説明する。リアルタイムOS１４はネイティブAPI２７を含み、ファイルシステム１３は、読出制御部３１、書込制御部３２、機器固有機能制御部３３を含む。

　ネィティブAPI２７は、リアルタイムOS１４の基本的機能を、バイトコードアプリケーションに提供するためのプログラミングインターフェイスであり、OSI参照モデルにおける通信用プログラミングインターフェイスである。リアルタイムOS１４の基本的機能を利用させるためのAPIは、“システム関数”とも呼ばれる。かかるネィティブAPI２７は通信用の基本的なAPIを含み、TCP/IP及びUDP/IPをサポートすることができる。

　読出制御部３１は、本編コンテンツを構成するファイル、携帯端末向け保護コンテンツを構成するファイルを、リードオンリーメディア１０５から読み出して、バイトコード処理モジュール１６に供給するようなファイル読み出しを制御する。

　書込制御部３２は、携帯端末向け保護コンテンツを構成するファイルを、読出制御部３１から受け取ってセキュアなメモリカード１０４に書き込むようなファイル書き込みを制御する。

　機器固有機能制御部３３は、機器固有の機能を実現する。本明細書における機器固有機能とは、再生装置を開発したメーカーによって製造されたプレーヤ機器のみ実行が可能であり、他のメーカーによって製造されたプレーヤ機器では実行することができない機能をいう。

　機器固有機能としては様々なものがある。例えば、ゲーム機器としての機能を具備している再生装置であるなら、そのゲーム機器固有の操作装置に特化した機能が機器固有機能として挙げられる。人が把持して振り回すことで、ユーザによる操作を検出したり、人の動きを検出してユーザによる操作を検出するような操作装置であるなら、その操作装置に特化して、当該ゲーム機器固有となる機能が、機器固有機能となる。他、そのゲーム機器固有のオンライン機能を機器固有機能とすることもできる。これら様々な種類の機器固有機能を、対象にしようとすると説明が煩雑になる。よって、以降の説明では、特許文献１に記載されたようなコピー機能、つまり、図２に記載された持出し視聴用コンテンツを対象としたコピー機能が、機器固有機能であるとして説明を進める。

　機器固有機能は、バイトコードアプリケーションによる利用が制限されている。よって、様々なコンテンツプロバイダのうち、機器固有機能の利用が許可されているものの作成に係るバイトコードアプリケーションのみが、機器固有機能を利用することができる。機器固有機能の利用が許可されていないコンテンツプロバイダの作成に係るバイトコードアプリケーションは、機器固有機能を利用することはできない。コンテンツプロバイダの利用権限をチェックするにあたって、機器固有機能制御部は、コンテンツIDと、シリアル番号との組みを外部サーバに送信して、本編コンテンツの供給源であるコンテンツプロバイダが、機器固有機能の正当なライセンシー(利用許諾者)がどうかをサーバに判断させる。正当なライセンシーであるとサーバが判断した場合は、機器固有機能を実行するが、正当なライセンシーではないと判断した場合、機器固有機能を実行しない。

　以上のレイヤ構成で、機器固有機能を用いた処理を実現するバイトコードアプリケーションについて説明する。

　本実施形態のバイトコードアプリケーションは、ソケットプロトコルによる端末内ローカル通信を通じて、機器固有機能制御部３３とのコマンド・レスポンス型の通信を行う点に特徴がある。

　“ソケット”とは、予め定められたポート番号の何れかと、ローカルホストのIPアドレスとをバインドしたものであり、オンメディアライブラリはソケット通信を通じて、機器固有機能制御部に対するコマンドの送信と、機器固有機能制御部からのレスポンスの受信とを行う。

　ソケットプロトコルは、リクエストを受け付けるというソケット作成行程、サーバーのアドレス情報であるIPアドレス及びポート番号をソケットに結び付けるというバインド行程、リクエストの接続待ちキューを設定して接続要求を準備するというリスニング行程、接続待ちのリクエストを受付けてソケット接続を確立し、新しいソケット接続を作成するというアクセプト行程という4つの過程を経て、このソケット接続を介してコマンド、レスポンスの送受信の行程を行う。

　これらの行程において、ソケット作成行程、バインド行程、リスニング行程、アクセプト行程、送受信行程は、Socket関数,bind関数,listen関数,accept関数,send関数,recv関数,closesocket関数といったシステム関数を用いてなされる。また、ソケットへのIPアドレス及びポート番号の結び付けは、SOCKADDR_IN構造体でなされる。これらの関数や構造体は、リアルタイムOS１４のネイティブAPI２７によって提供されるものである。端末内ローカル通信を用いたソケットプロトコルは、使用されるポートが特殊であることを除けば、リアルタイムOS１４のネイティブAPIによって提供されるものであるだから、バイトコードアプリケーションは、バイトコード処理モジュール１６内の組込ライブラリ２５によるまでもなく、リアルタイムOS１４のネイティブAPI２７を利用しさえすれば、機器固有機能を利用することができる。

　端末内ローカル通信のためのIPアドレスとしては、ローカルホストのIPアドレスを用いる。ローカルホストとは、現在使用しているシステムを指し、TCP/IPが必要に応じて自身と通信するために使用される。例えば、IPv4におけるローカルホストのIPアドレスは127.0.0.1に、例えば、IPv6におけるローカルホストのIPアドレスは、“::1”に割り当てられたループバックデバイスとなる。

　ソケットプロトコルはコピーヤーズソケットポートと呼ばれるポートを占有する。そのため、デジタルコピープロセスのためのポート番号は、独立して実装される。プロセスに使用されるポート番号を通知するために、バイトコードアプリケーションは、プロセス処理に使用されるポート番号をセットにする必要がある。

　機器固有機能を用いた処理を実現するバイトコードアプリケーションには、機器固有機能を利用するためのプログラミングインターフェイスを他のバイトコードアプリケーションに提供するオンメディアライブラリ(1)、機器固有機能用のプログラミングインターフェイスを用いた対話制御を実現するバイトコードアプリケーション(2)、これらのオンメディアライブラリ及びバイトコードアプリケーションの機能を一体化した統合バイトコードアプリケーション(3)という(1)から(3)までの３種のタイプが存在する。

　以下、機器固有機能を利用するためのプログラミングインターフェイスを提供するオンメディアライブラリについて説明する。

　図５は、オンメディアライブラリ２８と、再生装置における機器固有機能制御部３３と、外部サーバ２９とを示す図である。以下、オンメディアライブラリ２８、外部サーバ２９について説明する。

　オンメディアライブラリ２８は、ローカルネットワークアクセスを用いた機器固有機能制御部３３とのデータ送受信を、その他のバイトコードアプリケーションとは分離し、ライブラリ化して、リードオンリーメディア１０５から供給できるようにしたものである。組込ライブラリ２５が再生装置内に組込まれているのに対して、オンメディアライブラリ２８はリードオンリーメディア１０５から供給される点が組込ライブラリ２５との違いである。機器固有機能制御部３３とのデータ送受信に用いるプロトコルは、個々のバイトコードアプリケーションに依存したものではなく、共通のプロトコルとして定義されている。オンメディアライブラリ２８と機器固有機能制御部３３との間でなされるローカルネットワークアクセスを用いた、デジタルコピーのためのプロトコルを“デジタルコピーソケットプロトコル”という。デジタルコピーソケットプロトコルは、バイトコードアプリケーションに対してオンメディアライブラリ２８が提供しているAPIを、デジタルコピーソケットプロトコル上のコマンド（デジタルコピーソケットコマンドという）に変換し、ソケット通信により機器固有機能制御部３３へのコマンド送信、及び、機器固有機能制御部３３からのレスポンス受信という送受信を行うことである。

　外部サーバ２９は、機器固有機能を利用することができる再生装置や機器固有機能の対象となるコンテンツを管理しており、機器固有機能制御部３３からの要求に応じて、機器固有機能の利用履歴の更新と、機器固有機能の利用許諾とを行う。

　以上のオンメディアライブラリ２８、機器固有機能制御部３３、外部サーバ２９間におけるデータの流れについて、図５を参照しながら説明する。図５では、下側にリードオンリーメディア１０５と、セキュアなメモリカード１０４とを描き、更にその上に再生装置とサーバ、更にその上にオンメディアライブラリ２８を描いている。パイプcm2は、オンメディアライブラリ２８と、機器固有機能制御部３３との通信を模式的に示す。この通信は、同一端末内のローカル通信であり、ネイティブAPI２７を通じてなされる。矢印cp1は、リードオンリーメディア１０５からセキュアなメモリカード１０４へのコピーを模式的に示す。このコピーは、機器固有機能を利用するための、管理情報の書き込みであり、端末内ローカル通信を通じたオンメディアライブラリ２８による指示でなされる。

　パイプcm1は、機器固有機能制御部３３と外部サーバ２９との通信を模式的に示す。この通信は、端末間のグローバル通信である。セキュアなメモリカード１０４へのダウンロードは、このグローバルネットワークを介した、機器固有機能制御部３３による通信要求でなされる。前述したように、本実施の形態においては、従来のネットワークAPIであるソケット通信APIを端末内部に向けることで、バイトコード処理モジュールのAPIとしては規定されていない端末固有の機能を呼び出すことが可能となる。従来のBD-ROMにおけるBD-Jアプリケーション等のバイトコードアプリケーションにおけるネットワークAPIの利用方法は、主に外部サーバとの接続に用いられ、特典映像や追加字幕・アプリケーションなどの追加コンテンツのダウンロード用として使われてきた。これらのネットワークAPIを拡張するとなく同一端末間のローカル通信を形成することで、バイトコードアプリケーションから見れば、現在実行中の再生端末がまるでサーバのようにアクセスすることが可能となり、規定のAPIにとらわれない様々な機能を呼び出すことが可能となる。

　以上が機器固有機能制御部３３についての説明である。続いて、機器固有機能を実行するためのバイトコードアプリケーションの処理手順について説明する。

　図６は、バイトコードアプリケーションが機器固有機能を利用するための、バイトコードアプリケーションの処理手順を示すフローチャートである。

　まず、バイトコードアプリケーションは、再生装置がデジタルコピーに対応しているかどうかの判断を行う。バイトコードアプリケーションからオンメディアライブラィ２８に対し、再生装置のデジタルコピー対応確認が要求されると、オンメディアライブラィ２８は、デジタルコピーに割り当てられた通信ポートを示すシステムプロパティ（"digitalcopy.port"）が存在するかどうかを確認する（ステップＳ５０１）。

　ステップＳ５０１でシステムプロパティが存在しなければ、予め決められた固定ポートへ接続し（ステップＳ５０２）、システムプロパティが存在する場合は、システムプロパティが示すポートへ接続する（ステップＳ５０３）。次に通信ポートへの接続に成功したかどうかを確認し（ステップＳ５０４）、通信ポートへの接続が失敗すれば、現在の再生装置ではデジタルコピーに対応していないと判断する（ステップＳ５０８）。

　ステップＳ５０４で通信ポートへの接続に成功した場合、デジタルコピーライブラリは、その通信ポートを経由して機器固有機能制御部３３に初期化を要求する（ステップＳ５０５）。そして、ステップＳ５０５の初期化要求に対する機器固有機能制御部３３からの応答を接続中の通信ポートで受け取る（ステップＳ５０６）。ステップＳ５０６で、初期化成功との応答を受け取った場合、現在の再生装置で機器固有機能の実行は可能であるから、機器固有機能を実行する（ステップＳ５０７）。機器固有機能制御部３３からの応答がない、もしくは初期化失敗との応答を受け取った場合は、現在の再生装置では機器固有機能の実行は不可であり、機器固有機能を実行せずにリターンする（ステップＳ５０８）。このようにバイトコードアプリケーションは、ポート接続が成功したかどうか、機器固有機能制御部３３の初期化に成功したかどうかで、機器固有機能の実行可能性を判断する。

　以上のように本実施形態によれば、ネイティブAPIとしてサポートされているソケット機能を用いて、機器固有機能をバイトコードアプリケーションに提供するので、既に標準化されているデジタルストリーム再生制御のためのAPIに対して、追加／改変を加えることなく、アプリケーションに機器固有機能を使用させることができる。追加／改変を加えることなく、アプリケーションに機器固有機能を使用させるので、特殊機能を利用したアプリケーションが様々なコンテンツプロバイダが開発され、市場に投入されると予想される。その結果、特殊機能を起動するためのユーザインターフェイスが多種多様なものになり、ユーザは、より判りやすく親しみ易いユーザインターフェイスを通じて、あるメーカーが独自開発した特殊機能を利用することができる。

　機器固有機能として実装する限り、後発メーカーの追従を避けることができるから、一メーカーが開発した特殊機能を機器固有機能として実装した製品により、市場を寡占することができる。

　(第２実施形態)
　第１実施形態では、機器固有機能の内容を具体的に特定していなかったが、本実施形態では、機器固有機能がデジタルコピーであるとして説明する。本実施形態におけるデジタルコピーとは、携帯端末での視聴のために、リードオンリーメディア１０５からセキュアなメモリカード１０４へと持出し視聴用コンテンツをコピーする機能、つまりメディア間コピーのことである。そして、外部サーバによる管理の下、再生装置がメディア間コピーを実行することによって、リードオンリーメディア１０５におけるコンテンツを、携帯端末に持ち出させるサービスを、“e-moveサービス”という。e-moveサービスの対象であり、持ち出しを前提にしたコンテンツ(持出し視聴用コンテンツのこと)を、“e-moveコンテンツ”という。

　e-moveサービスを、既存の類似の機能やサービスと対比した場合、長所は以下の通りである。

　既存の類似機能にはAACSにおけるマネージドコピーがあり、類似のサービスには、Apple社のデジタルコピーがある。

　AACSにおけるマネージドコピーは、トランスコードを必要とし、例えば、２時間のAVストリームであるなら、そのトランスコードに、２時間長の処理時間が必要となる。これに対し、e-moveサービスでは、リードオンリーメディア１０５に記録されているコンテンツをセキュアなメモリカード１０４に書き込む処理で足りるから、その処理時間は短くて済む。

　Apple社のデジタルコピーは、BD-ROMとは別に、DVD-Videoディスクやコピーのためのコンテンツが記録されたDVD-ROMディスクがセットパッケージに同梱されていて、そのDVD-ROMディスクをパソコンに装填して、記録されているプログラムをパソコンで動作させることによりメモリカードへのコピーを行う。BD-ROM、DVD-Video、DVD-ROMが同梱されているため、価格が高く、ユーザにとって望ましくない。

　このデジタルコピーと比較すると、e-moveサービスでは、リードオンリーメディア１０５に記録されたバイトコードアプリケーションに直接、持ち出し視聴のためのコピーを行わせるので、パソコンにデジタルコピーを実行させるためのDVD-ROMは不要である。

　以上がe-moveサービスについての説明である。続いて、メディア間コピーの詳細について説明する。

　携帯端末向け保護コンテンツは、外部サーバによる権利管理の下、私的利用のためのコピーが認められる。よって、機器固有機能制御部３３によるデジタルコピーは、外部サーバの1つである、デジタルコピーサーバによる権利管理の下でなされる必要がある。

　以下、権利管理のためのデジタルコピーモジュール３５及びデジタルコピーサーバ３６について説明する。

　図７は、デジタルコピーにおける、再生装置内外のデータの流れを示す。かかるデジタルコピーを実現するため、機器固有機能制御部３３はデジタルコピーモジュール３５を具備しており、また外部サーバ２９は、デジタルコピーサーバ３６に置き換えられている。

　デジタルコピーモジュール３５は、リードオンリーメディア１０５からの携帯端末向け保護コンテンツを構成するファイルの読み出しと、セキュアなメモリカード１０４への書き込みとを行うことで、携帯端末向け保護コンテンツを構成するファイルのコピーを行う。デジタルコピーモジュール３５には、ファイル読み出し／書き込みのための複数のパラメータが予め設定されており、これらのパラメータに基づき、コピーの前処理、後処理を行う。

　ここで、複数のパラメータには、カレントシリアルID、カレントソースロケーション、カレントサーバURL、カレント出力デバイス、カレントレジューム位置といったものがある。そして、デジタルコピーモジュール３５による前処理とは、対象となる携帯端末向け保護コンテンツの残りコピー回数をサーバから取得するというものである。具体的には、カレントソースロケーションを示すファイルパスによって特定されるリードオンリーメディア１０５のディレクトリ配下のコピー情報ファイルからコンテンツIDを取り出し、カレント出力デバイスによって特定されるドライブに装填されたセキュアなメモリカード１０４からメディアIDを取り出す。これらのコンテンツIDと、メディアIDと、カレントのシリアルIDとの組合せを、カレントサーバURLで指示されたサーバに送信することで、データベースの検索をサーバに行わせ、これらの組合せにヒットする残りコピー回数を取り出させてバイトコードアプリケーションに返す。

　後処理とは、いわゆる復号鍵のダウンロードであり、コンテンツIDと、シリアルIDと、メディアIDと、カレント出力デバイスのMKBとの組合せを、サーバに送信することで、データベースの検索をサーバに行わせ、これらの組合せにヒットするタイトルキーを取り出させ、復号鍵を生成させて、セキュアなメモリカード１０４にダウンロードするというものである。

　デジタルコピーサーバ３６は、携帯端末向け保護コンテンツの権利管理を行う複数のシリアルIDについてのタイトルキーのデータベースを有している。このデータベースでは、複数のシリアルIDのそれぞれに対応付けて、タイトルキーを管理しており、コンテンツID、シリアルID、メディアID、MKBの組合せをキーワードとした検索要求が機器固有機能制御部３３からなされば、このキーワードにおけるシリアルIDを用いてデータベースを検索して、当該組合せにヒットしたタイトルキーをデータベースから読み出し、コンテンツID、シリアルID、メディアID、MKBを用いてこのタイトルキーを暗号化した上で復号鍵を得て、検索要求の要求元のデジタルコピーモジュール３５に復号鍵をダウンロードする。

　またデジタルコピーサーバ３６は、コンテンツID、メディアID、シリアルIDの組みに対応付けて、複数のコピーチケットを管理している。コピーチケットとは、コンテンツID、メディアID、シリアルIDの組合せのそれぞれについて、何回の私的コピーが認められているかを管理する権利管理情報であり、本実施形態では、デジタルコピーの運営業者が定めた残コピー回数によって、私的コピーの回数を管理している。デジタルコピーが一回なされる度に、残コピー回数は、１回ずつ減じられることになる。そして、コンテンツID、シリアルID、メディアIDをキーワードとした検索要求がデジタルコピーモジュール３５からなされれば、データベースにおける複数のコピーチケットの中から、これらコンテンツID、シリアルID、メディアIDの組合せ条件にヒットする残コピー回数をデータベースから読み出して、要求元のデジタルコピーモジュール３５に返す。ここで、コンテンツID、シリアルID、メディアID、MKBの組合せを含む検索要求がデジタルコピーモジュール３５からなされて、タイトルキーのダウンロードがなされれば、残コピー回数を一回減じる。こうすることで、デジタルコピーは、デジタルコピーサーバ３６で管理されている残りコピー回数以下に制限されることになる。

　以下、図７を参照して、デジタルコピープロセスにおけるデータの流れを説明する。図７では、中段に再生装置を描き、その下側にセキュアなメモリカード１０４を描き、上側にリードオンリーメディア１０５と、デジタルコピーサーバ３６とを描いている。

　デジタルコピープロセスにおいて扱う主なデータは、シリアルID，コンテンツID，メディアID（MID）、メディアキーブロック(MKB)，携帯端末向け保護コンテンツ、及び復号鍵である。リードオンリーメディア１０５には、コンテンツIDを格納したファイル、携帯端末向け保護コンテンツ、バイトコードアプリケーション、オンメディアライブラリ２８が存在する。

　シリアルIDは、個々のリードオンリーメディア１０５のそれぞれを識別するための識別情報であり、市場に流通するリードオンリーメディア１０５のうち、機器固有機能の対象になっているもののシリアルIDは、デジタルコピーサーバ３６のデータベースにおいて、管理されている。シリアルIDとしては、BCA（Burst　Cutting　Area）に記録されているPMSN（Pre-recorded　Media　Serial　Number）を利用することができるが、これ以外の値として、パッケージに同梱されている紙に記載されたクーポンIDをユーザに手入力させた値を代替することも可能である。PMSNを利用すれば、ユーザに手入力させる必要もなく自動で認証を行うことが可能であるが、一方でレンタルディスク等の場合にPMSNを利用するとなると、最初に借りたユーザだけが、このサービスの実施権が与えられることになり、二番目以降に借りるユーザに不公平となる。レンタルディスクの場合はクーポンIDの手入力が望ましく、市販ディスクの場合はPMSNの利用が望ましい。

　メディアID(MID)はコピー先メディアのシステム領域に記載されている値である。

　図７の動作例においてコピーされるのは携帯端末向け保護コンテンツであり、ダウンロードされるのは、復号鍵である。このダウンロードにあたって、セキュアなメモリカード１０４からはMKBが読み出され、コンテンツID、シリアルIDと共に、デジタルコピーサーバ３６に送信される。

　シリアルIDの流れを追ってみると、バイトコードアプリケーションがシリアルIDを取得した際、バイトコードアプリケーションは直接、シリアルIDをデジタルコピーモジュール３５に引き渡すのではなく、オンメディアライブラリ２８にシリアルIDを引き渡して、オンメディアライブラリ２８を通じて、シリアルIDをデジタルコピーサーバ３６に引き渡す。シリアルIDはバイトコードアプリケーションが指定したものが、矢印sd1,sd2,sd3に示すように、デジタルコピーライブラリに渡され、それがソケット通信APIを通じて、デジタルコピーモジュール３５を通じてデジタルコピーサーバ３６に引き渡される。

　コンテンツIDの流れを負ってみると、コンテンツIDは読み出され、サーバに送信される。コンテンツIDに関しては、バイトコードアプリケーションが指定したディスク上のコピー情報ファイルから、矢印cd1に示すようにデジタルコピーモジュール３５によって読み取られる。

　メディアID，MKBに関しては、バイトコードアプリケーションが指定したコピー先のセキュアなメモリカード１０４のシステム領域から、矢印md1に示すように、デジタルコピーモジュール３５によって読み取られる。

　こうして得られたシリアルID，コンテンツID，メディアID（MID）、MKBは、矢印sd3,cd2,md2に示すように、デジタルコピーサーバ３６へ送られ、これらと引き換えに、デジタルコピーサーバ３６から矢印dk1に示すように復号鍵は送信される。これがサーバからのダウンロードであり、デジタルコピーモジュール３５は、矢印dk2に示すようにその復号鍵をコピー先メディアの保護領域に書き込む。以上がデジタルコピープロセスにおいて扱う主なデータの流れである。

　また、コピー先のメディアの保護領域に書き込まれる復号鍵は、携帯端末向け保護コンテンツ内の暗号化データを復号するためのキー情報（タイトルキー）を含む。復号鍵は、コピー先のメディアのシステム領域に記録されたMKBを用いて復号できるように暗号化されている。

　以上が、デジタルコピーモジュール３５、デジタルコピーサーバ３６、バイトコードアプリケーション、セキュアなメモリカード１０４間のデータの流れである。続いて、バイトコードアプリケーションと、機器固有機能制御部３３との間でなされる通信の詳細について説明する。

　図８は、バイトコードアプリケーション、デジタルコピーモジュール３５、及びデジタルコピーサーバ３６とのデータ送受信を示すシーケンス図である。本図は、システムの通信シーケンスを示すシーケンス図である。本図の横方向には、バイトコードアプリケーション、オンメディアライブラリ２８、デジタルコピーモジュール３５、デジタルコピーサーバ３６が、それぞれ配置されている。縦方向には、複数の時間軸を描いている。これらの時間軸は、装置が具備しているクロックにより管理されるものである。時間軸上の各時点が、API呼出しのタイミングとなる。

　バイトコードアプリケーションとオンメディアライブラィ２８との間では、通信経路が確立されず、通常のアプリケーション内API呼び出しが行われるに過ぎない。しかし、オンメディアライブラリ２８と、デジタルコピーモジュール３５との間は、同一端末内のソケット通信である。デジタルコピーモジュール３５とデジタルコピーサーバ３６との間は、別端末間のグローバルソケット通信が形成される。本図におけるシーケンスは、ａ.機器確認フェーズ、ｂ.初期化フェーズ、ｄ.パラメータセットフェーズ、ｅ.残コピー回数確認フェーズ、ｆ.コピー開始フェーズ、ｇ.コピー進捗確認フェーズ、ｈ.鍵書込みフェーズからなる。以下、これらのフェーズについて説明する。

　「ａ.機能確認フェーズ」は、オンメディアライブラィ２８に対して機能確認を行い、オンメディアライブラィ２８からデジタルコピーの可否を受けとるという、オンメディアライブラィ２８を介したデジタルコピーモジュール３５とのやりとりで構成される。

　「ｂ.初期化フェーズ」は、オンメディアライブラィ２８に対して初期化を行い、オンメディアライブラィ２８から初期化の可否を受けとるという、オンメディアライブラィ２８を介したデジタルコピーモジュール３５とのやりとりで構成される。

　
　「ｄ.パラメータセットフェーズ」は、オンメディアライブラィ２８に対してコピーパラメータをセットするとの設定処理を行い、オンメディアライブラィ２８からパラメータセットの可否を受け取るというオンメディアライブラィ２８を介したデジタルコピーモジュール３５とのやりとりで構成される。つまりバイトコードアプリケーションはデジタルコピー可能であるという通知を受け取ると、続いてデジタルコピーに必要なパラメータをデジタルコピーライブラリ経由で、デジタルコピーモジュール３５へセットする。

　デジタルコピーライブラリはこれらのパラメータがバイトコードアプリケーションから指定されると、接続中の通信ポートを用いてデジタルコピーモジュール３５へ指定されたパラメータを送信する。

　「ｅ.残コピー回数確認フェーズ」は、オンメディアライブラィ２８に対して残コピー回数を確認するとの処理を行い、オンメディアライブラィ２８から残りコピー回数を受け取るというオンメディアライブラィ２８、デジタルコピーモジュール３５を介したサーバとのやりとりで構成される。バイトコードアプリケーションは次に残コピー回数の確認を行う。残コピー回数の確認も、パラメータのセットと同様、デジタルコピーライブラリを経由し、接続中の通信ポートを用いてデジタルコピーモジュール３５へ問い合わせを行う。残コピー回数は、デジタルコピーサーバ３６で管理されているため、デジタルコピーモジュール３５は残コピー回数の確認要求を受け取ると、矢印に示すように、現在セットされているパラメータから、コンテンツID，シリアルID，メディアIDを取り出しデジタルコピーサーバ３６へ、これら３つの値を送る。バイトコードアプリケーション、オンメディアライブラィ２８及びデジタルコピーモジュール３５の間は端末内ローカル通信であり、外部インターネット接続不要であったが、デジタルコピーモジュール３５とデジタルコピーサーバ３６との間はグローバルなインターネット接続が必要となる。デジタルコピーサーバ３６は、受け取った値を元に残コピー回数を割り出し、デジタルコピーモジュール３５へ残コピー回数の値を返信する。デジタルコピーモジュール３５は、この残コピー回数をデジタルコピーライブラリ経由でバイトコードアプリケーションに通知する。

　「ｆ.コピー開始フェーズ」は、オンメディアライブラィ２８に対してコピー開始を要求するとの処理を行い、オンメディアライブラィ２８から、コピー開始の成功／失敗、及び、コピー完了通知の何れかを受け取るというオンメディアライブラィ２８を介したデジタルコピーモジュール３５とのやりとりで構成される。バイトコードアプリケーションは、コピー回数が1回以上残っていることが判明した場合、コピー開始の要求を行う。このコピー開始要求も、これまでと同様、デジタルコピーライブラリを経由し、通信ポートを用いてデジタルコピーモジュール３５へ伝えられる。デジタルコピーモジュール３５はコピー開始要求を受け取ると、コピーを開始し、その間、バイトコードアプリケーションからの要求に応じてコピー進捗状況を随時通知する。

　「ｇ.進捗確認フェーズ」は、オンメディアライブラィ２８に対して進捗確認を要求するとの処理を行い、オンメディアライブラィ２８から進捗状況を受け取るというオンメディアライブラィ２８を介したデジタルコピーモジュール３５とのやりとりで構成される。

　「ｈ.鍵書込みフェーズ」は、オンメディアライブラィ２８に対して鍵書き込みを要求するとの処理を行い、オンメディアライブラィ２８から復号鍵書き込みの完了通知を受け取るというオンメディアライブラィ２８、デジタルコピーモジュール３５を介したサーバとのやりとりで構成される。具体的にいうと、コピー完了通知を受け取った際、バイトコードアプリケーションは、復号鍵の書込みをデジタルコピーモジュール３５へ要求する。デジタルコピーモジュール３５は復号鍵の書込み要求を受け取ると、現在セットされているパラメータから、コンテンツID，シリアルID，メディアID，MKBを取り出しデジタルコピーサーバ３６へ、これら４つの値を送る。

　デジタルコピーサーバ３６は、受け取った値を元に復号鍵を生成し、デジタルコピーモジュール３５へ復号鍵を返信する。デジタルコピーモジュール３５は、デジタルコピーサーバ３６から受け取った復号鍵をコピー先メディアに書き込み、書き込みが完了すると、デジタルコピーライブラリを経由してバイトコードアプリケーションに書き込み完了を通知する。

　以上が、機器固有機能のために、再生装置内でなされる、3つの通信についての説明である。続いて、デジタルコピーを実現するにあたっての処理手順の詳細について説明する。

　デジタルコピーの実行が可能である場合、バイトコードアプリケーションは、オンメディアライブラリ２８とのアプリケーション間通信を通じて、デジタルコピーのプロセスを実行する。オンメディアライブラリ２８によるデジタルコピープロセスの処理手順は、図１０に示すものとなる。

　以上が通信シーケンスの詳細についての説明である。続いて、デジタルコピーモジュール３５の内部構成について説明する。

　図９は、デジタルコピーモジュール３５を詳細化した図である。デジタルコピーモジュール３５は、通信管理部６０１、鍵情報読込部６０２、メディア状態管理部６０３、コピー実行部６０４、コピー状態通知部６０５、コピー進捗管理部６０６、鍵情報書込部６０８、コマンド処理部６０９、空き容量判定部６１０で構成される。

　通信管理部６０１は、再生装置内の通信ポートの一つをデジタルコピー制御のために割り当て、このデジタルコピー通信ポートを用いて、バイトコード処理モジュールとのプロトコル通信を行う。具体的には、サーバソケットとしてデジタルコピー通信ポートを開いて、バイトコード処理モジュールからの要求が来るのを待ち、デジタルコピー通信ポートに対してデータが送られてくると、送られてきたデータを解析し、そのデータに対応する処理を行う。処理結果も同様にデジタルコピー通信ポートを介してバイトコード処理モジュールに送り返す。加えて、通信管理部６０１はデジタルコピーサーバ３６とのデータ通信管理も行う。具体的には、暗号化された携帯端末向けデジタルストリームを復号するために必要な復号鍵をデジタルコピーサーバ３６から取得するために必要な通信処理を行う。

　鍵情報読込部６０２は、復号鍵生成に必要な情報をコピー元のリードオンリーメディア１０５、及び、コピー先のセキュアなメモリカード１０４から読出す。具体的には、コピー元からはリードオンリーメディア１０５上の特殊領域であるBCA（Burst　Cutting　Area）に記録されている記録媒体の物理的なシリアルIDを示すPMSN（Pre-recorded　Media　Serial　Number）を、コピー先のリードオンリーメディア１０５からはコピー先のメディアに記録されている、メディア毎にユニークに設定されるメディア固有の情報（メディアID）、及び復号鍵生成に必要な鍵情報が記録されたメディアキーブロック（MKB）の読出しを行う。

　メディア状態管理部６０３は、再生装置が現在コピー先として利用できるメディアの種類一覧を管理する。例えば、再生装置がSDカードスロットと、USBメモリスロットを備え、現在、SDカードのみが挿入されているのであれば、SDカードが現在のコピー先の対象と判断する。SDカードとUSBメモリ（もしくはUSB接続されている携帯端末）の両方が挿入されていれば、コピー先としてSDカード、USBメモリの両方が可能と判断する。加えて、コピー先メディアの空き容量管理も行う。

　コピー実行部６０４は、バイトコードアプリケーションから指示されたリードオンリーメディア１０５上の携帯端末向け保護コンテンツを別メディアへコピーする処理を行う。バイトコードアプリケーションからの指示はオンメディアライブラィ２８を経由し、デジタルコピー通信ポート上で行われる。なおコピー実行部６０４によるデータコピーだけでは、コピー先で携帯端末向け保護コンテンツを再生することはできない。後述の復号鍵書込部６０８によってコピー先へ復号鍵の書込みが完了した後にコピー先にて再生が可能となる。

　コピー状態通知部６０５はコピーの開始・正常終了・エラー終了等の状態遷移を管理し、デジタルコピー通信ポートを通じてデジタルコピーモジュール３５とローカル通信接続中のバイトコードアプリケーションに状態遷移を通知する。

　コピー進捗管理部６０６はコピー対象となっている残りバイト数、コピー済みバイト数の管理を行い、デジタルコピー通信ポートを介したバイトコードアプリケーションからの要求に応じて、現在の進捗情報を通知する。

　復号鍵書込部６０８は、鍵情報読込部６０２が取得したリードオンリーメディア１０５のシリアルID、コピー先メディアのメディアID、及びMKBから生成される復号鍵の書込みを行う。復号鍵の生成は、デジタルコピーサーバ３６にある秘密鍵を元に行われるため、デジタルコピーモジュール３５は鍵情報読込部６０２が、リードオンリーメディア１０５のシリアルID、コピー先メディアのメディアID、及びMKBを取得した後、通信管理部６０１を経由してデジタルコピーサーバ３６にこれらの値と、コピー対象コンテンツのコンテンツIDを送信する。デジタルコピーサーバ３６は受け取った値とデジタルコピーサーバ３６が保持する秘密鍵から復号鍵を生成し、通信管理部６０１へ復号鍵を送信する。生成される復号鍵はコピー先メディアのMKBにより復号できるような暗号化がなされている。通信管理部６０１が復号鍵を受け取ると鍵情報書込部６０８はコピー先の保護領域に復号鍵の書込みを行う。復号鍵はキー情報（タイトルキー）を含んでおり、キー情報が暗号化された携帯端末向け保護コンテンツの復号に用いられる。

　このキー情報を含む復号鍵がなければ、たとえ、無断でコピー元の携帯端末向け保護コンテンツのみを別のメディアにコピーしたとしても再生することはできない。

　コマンド解釈部６０９は、オンメディアライブラリ２８が発行したコマンドを解釈し、コマンドのオペランドを用いて、上記通信管理部６０１～コマンド処理部６０９を制御することにより、オンメディアライブラリ２８が発行したコマンドのオペコードに応じた制御内容を実行する。

　空き容量判定部６１０は、コピー先メディアの空き残量及びコピー元コンテンツをもとにコピーに必要な空き容量がコピー先に存在するかを判定する。

　デジタルコピーモジュール３５は以上の構成を持ち、これらの操作はデジタルコピー通信ポートにローカル通信接続を行っているバイトコードアプリケーションから制御できる。これらの制御を操作できる直接のAPIはバイトコード処理モジュールに存在しないため、デジタルコピー通信ポートに接続できていないバイトコードアプリケーションからは制御ができないということになる。

　図１０は、デジタルコピーモジュール３５におけるデジタルコピープロセスのフローチャートである。デジタルコピーモジュール３５は、まず再生装置に挿入されているリードオンリーメディア１０５上に携帯端末向け保護コンテンツが存在するかどうかを確認する（ステップＳ１０１）。携帯端末向け保護コンテンツが、ディスク上のルートディレクトリ直下の“EMOVE”ディレクトリの配下に記録されるとのルールが存在する場合、デジタルコピーモジュール３５は、この“EMOVE”ディレクトリが存在するかどうかで、ディスク上に携帯端末向け保護コンテンツが存在するかどうかを判断する。EMOVEディレクトリとは、e-moveサービスの対象となるファイル一式を格納するためのディレクトリである。

　ステップＳ１０１で携帯端末向け保護コンテンツが存在しなかった場合は、デジタルコピープロセスを中断し、携帯端末向け保護コンテンツが存在する場合、デジタルコピーモジュール３５はデジタルコピーソケットコマンド用通信ポートを指定してサーバソケットを作成し、デジタルコピーソケットコマンド用通信ポートに対するバイトコードアプリケーションからの接続を待つ（ステップＳ１０２）。

　携帯端末向け保護コンテンツが存在する場合のみサーバソケットを作成する理由は、常にサーバソケットを開いた状態にしておくと、無駄にポートを空けている時間が長くなり、不必要なリソースを消費するということと不正アプリケーションからの攻撃の恐れがあるということから、ポートを開いている時間は極力短時間にするのが望ましい。そのため、ステップＳ１０１で携帯端末向け保護コンテンツが存在する場合のみ、サーバソケットを作成し、ポートを開く。ポートを開く時間を極小化する他の方法としては、バイトコードアプリケーション動作中のみ（すなわち、バイトコードアプリケーションを連動したタイトル再生中のみ）、サーバソケットを作成しポートを開く、もしくはバイトコードアプリケーションからポートオープンの命令を受け取ってからポートを開く等が考えられる。

　ポートオープン命令はポートが閉じられた状態で行われることになるので、バイトコードアプリケーションからポートオープンの命令を受け取るには、ポート通信以外の方法で受け取らなければならない。そのためにAPIを追加するというのであれば、互換性維持のため一切のAPI追加を行わないという本願の趣旨に反することになるため、APIの追加なしで命令を受け取る必要がある。ポートオープンの命令を示す案としては、例えば、汎用のシステムプロパティAPIを用い、バイトコードアプリケーションから、予め決められたプロパティにある値がセットされたとき、もしくはレジスタセットの中の汎用レジスタの中から、ある一つに対して予め決められた値がセットされたときに、ポートオープンの要求がなされたとみなすことができる。システムプロパティAPIを用いる場合は例えば、“digitalcopy.portstatus”というプロパティ名を用意しておき、そのプロパティ名の示す値に"OPEN"を設定すると、ポートを開くという手段が考えられる。ステップＳ１０２でサーバソケットを作成し、デジタルコピーソケットコマンド用通信ポートを開くと、そのポートに対してバイトコードアプリケーション（デジタルコピーライブラリを含む）が接続してくるのを待つ（ステップＳ１０３）。バイトコードアプリケーションからの接続要求は予め決められたコマンド文字列（もしくはバイナリデータでも良い）をデジタルコピーモジュール３５とバイトコードアプリケーション（デジタルコピーライブラリ）間で相互に交換し、お互いが送り合うデータが期待値と一致しているかどうかを相互確認することで実現するのが望ましい。当然ながら、お互いが送り合うデータが期待値と一致していなかった場合は、不正とみなし、以後の処理を中断する（ステップＳ１０４）。

　ステップＳ１０４でデジタルコピーモジュール３５はバイトコードアプリケーションとの接続に成功したと判断した場合、次にバイトコードアプリケーションからデジタルコピーのコピー先候補のリスト（再生装置がサポートしているコピー先メディア一覧）を要求してくるのを待ち、通信ポートを介してその要求を受け取ると、この再生装置において携帯端末向け保護コンテンツのコピー先としてサポートしているメディアの確認を行う（ステップＳ１０５）。携帯端末向け保護コンテンツのコピー先としてサポートしているメディアがなければデジタルコピーを中断し、サポートしているメディアがあれば、そのメディアのリストを同じく通信ポートを介してバイトコードアプリケーションに送信する（ステップＳ１０６）。デジタルコピーモジュール３５はこの時点で空き容量が不足しているかどうかを先行して判断することができるが、ステップＳ１０６で返すメディアのリストには空き容量が不足しているメディア及びまだ挿入されていないメディアも含めてバイトコードアプリケーションに渡す。理由は、空き容量が不足しているものを除いて渡してしまうと、再生装置がサポートしていないから、リストにないのか空き容量が不足しているからリストにないのかの判断がつかないためである。再生装置はサポートしているが、空き容量が不足している場合はユーザがそのメディア上の不要ファイルを削除するなどして空き容量を確保するという選択を取ることができるため、ステップＳ１０６で返すリストには空き容量が不足しているものも含めるのが望ましい。同様の理由でリストには未挿入メディアも含めておけば、メディアの挿入し忘れをユーザに通知することができる。

　次に、バイトコードアプリケーションは得られたコピー先候補のリストをユーザに提示し、ユーザが選んだメディアをデジタルコピーモジュール３５に通知する（ステップＳ１０７）。デジタルコピーモジュール３５は選択されたメディアにコピーを行うための十分な空き容量があるかどうか、及び残コピー回数が残っているかどうかを確認し（ステップＳ１０８）、空き容量がない、もしくは残コピー回数が残っていなければバイトコードアプリケーションに容量不足もしくは残コピー回数がない旨を通知する。残コピー回数の確認はデジタルコピーサーバ３６への問い合わせが必要となる。バイトコードアプリケーションは容量不足の通知をデジタルコピーモジュール３５から受け取った場合は、再度ステップＳ１０７に戻り、別のメディアの選択を行わせるか、ユーザに不要ファイルの削除を促す、もしくは同一種類のメディアでより容量の大きいものに交換する等のメッセージを表示する。ステップＳ１０８での空き容量確認は、コピー先メディアのユーザ領域だけでなく、保護領域の空き容量の確認をも含む。

　保護領域にすでに他のコンテンツ復号鍵が書き込まれており、復号鍵を追加で書き込む余地がなければ、ユーザ領域に空きがあったとしても、容量不足の通知をバイトコードアプリケーションに通知する必要がある。万一、保護領域の空き容量チェックを怠った場合は、デジタルコピープロセスの最後のステップである復号鍵の書き込み時点で失敗することになり、ユーザにとっては時間のロスとなるばかりか、デジタルコピーサーバ３６から復号鍵のダウンロードが完了しているために最悪の場合コピー権利を無駄に一つ消費してしまうことになりかねない。よって、ステップＳ１０８の空き容量確認は、ユーザ領域だけでなく保護領域の空き容量チェックも不可欠である。ステップＳ１０８で残コピー回数が残っており、かつコピー先のメディアに十分な空き容量があると判断できれば、デジタルコピーモジュール３５はディスク上の携帯端末向け保護コンテンツを指定されたメディアへコピーする（ステップＳ１０９）。この間、バイトコードアプリケーションはデジタルコピーモジュール３５にコピーの進捗を問い合わせることで、現在のコピー進捗を把握することができ、コピー進捗状況をユーザに表示することができる。携帯端末向け保護コンテンツのデータコピーが完了すると、デジタルコピーモジュール３５は携帯端末向け保護コンテンツを復号するための復号鍵をデジタルコピーサーバ３６から取得する（ステップＳ１１０）。復号鍵の取得は、シリアルID，コンテンツID，メディアID，MKBの４つのデータをネットワークI/Fを介してデジタルコピーサーバ３６に送信し、デジタルコピーサーバ３６が持つ秘密鍵を元にコピー先メディアで携帯端末向け保護コンテンツを復号するための復号鍵をデジタルコピーサーバ３６側で作成し、デジタルコピーモジュール３５はデジタルコピーサーバ３６側で作成された復号鍵を受け取り、コピー先の保護領域に復号鍵の書込みを行う（ステップＳ１１１）。　

　以上のように本実施形態によれば、オンメディアライブラリ２８及びデジタルコピーモジュール３５は、端末内ローカル通信によって、リードオンリーメディア１０５に予め記録されている携帯端末向け保護コンテンツを、セキュアなメモリカード１０４にコピーさせるので、再生装置のメーカーは、そのようなメディア間コピー機能の利用を、特定したコンテンツプロバイダに利用させることができる。これにより、メディア間コピー機能を利用したコンテンツの作成に弾みを付け、コンテンツの充実化を図ることができる。

　(第３実施形態)
　第１実施形態は、デジタルコピーのコピーソースとなるリードオンリーメディア１０５が、動作モードオブジェクト、バイトコードアプリケーションを記録したリードオンリーメディア１０５であるとして説明をした。本実施形態では、この記録媒体が、“BD-ROM”であるとして説明を行う。図１１は、BD-ROM(以降、“BD”と称する場合もある）の構成を示した図である。本実施形態においては、映画等のAVコンテンツを再生するためのAVアプリケーションを主眼においてBD-ROMを説明するが、BD-ROMをCD-ROMやDVD-ROMのようにコンピュータ用途の記録媒体として利用することも当然ながら可能である。BD-ROMは、他の光ディスク、例えばDVDやCDなどと同様にその内周から外周に向けて螺旋状に記録領域を持ち、内周のリード・インと外周のリード・アウトの間に論理データを記録できる論理アドレス空間を有している。また、リード・インの内側にはBCA（Burst　Cutting　Area）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、著作権保護技術などに利用され、記録媒体の物理的なシリアルIDを示すPMSN（Pre-recorded　Media　Serial　Number）が記録されている。

　論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは、UDFやISO９６６０などのことであり、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっており、２５５文字のファイル名、ディレクトリ名を読み出すことが可能である。

　本実施の形態の場合、BD-ROM上のディレクトリ、ファイル構造は、ルートディレクトリ（ROOT）直下にBDMVディレクトリ、CERTIFICATEディレクトリ及びEMOVEディレクトリが置かれている。BDMVディレクトリはBD-ROMで扱うAVコンテンツや管理情報などのデータが記録されているディレクトリであり、CERTIFICATEディレクトリは配下にdiscroot.crt（ファイル名固定）ファイルが存在し、アプリケーションの署名検証に用いられる証明書が記録されている。

　例えば、BDMVディレクトリ配下のデータが本編コンテンツに対応する。例えば本編コンテンツに含まれるデジタルAVストリームのフォーマットにおける格納方式は、BD-Video方式であり、保護方式は、AACS方式である。

　EMOVEディレクトリには携帯端末視聴用のAVコンテンツや管理情報が記録されている。

　例えば、EMOVEディレクトリ配下のデータが携帯端末向け保護コンテンツに対応する。図１１に示す例では、例えばDATA1ディレクトリ、DATA2ディレクトリ、DATA3ディレクトリにそれぞれ異なる携帯端末向け保護コンテンツが記録されている。

　例えば携帯端末向け保護コンテンツに含まれるデジタルAVストリームのフォーマットにおける格納方式は、SD-Video方式であり、保護方式は、CPRM方式である。

　BDMVディレクトリの配下には、PLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDJOディレクトリ、JARディレクトリと呼ばれる５つのサブディレクトリが存在し、BDMVディレクトリには、index.bdmv，MovieObject.bdmvの２種類のファイルが配置されている。STREAMディレクトリには、いわばデジタルストリーム本体となるファイルを格納しているディレクトリであり、拡張子m２tsが付与されたファイル（xxx.m２ts［“xxx”は可変、拡張子”m２ts”は固定］）が存在する。PLAYLISTディレクトリには、拡張子mplsが付与されたファイル（xxx.mpls［“xxx”は可変、拡張子”mpls”は固定］）が存在する。CLIPINFディレクトリには、拡張子clpiが付与されたファイル（xxx.clpi　［“xxx”は可変、拡張子”clpi”は固定］）が存在する。JARディレクトリには、拡張子jarが付与されたファイル（xxx.jar［“xxx”は可変、拡張子”jar”は固定］）が存在する。BDJOディレクトリには、拡張子bdjoが付与されたファイル（xxx.bdjo［“xxx”は可変、拡張子”bdjo”は固定］）が存在する。

　拡張子”m２ts”が付与されたファイルは、MPEG-TS(TransportStream)形式のデジタルAVストリームであり、ビデオストリーム、１つ以上のオーディオストリーム、１つ以上の副映像ストリームを多重化することで得られる。ビデオストリームは映画の動画部分を、オーディオストリームは映画の音声部分を、副映像ストリームは、映画の字幕をそれぞれ示している。

　拡張子”clpi”が付与されたファイルは、デジタルAVストリームのそれぞれに１対１に対応するストリーム管理情報である。ストリーム管理情報は、デジタルAVストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、GOPの先頭位置を示すエントリーマップ(EP_map)をもっている。

　拡張子”mpls”が付与されたファイルは、プレイリスト情報を格納したファイルであり、ストリームの再生区間（「In　Time/Out　Time」）が記録されている。

　拡張子”jar”が付与されたファイルは、Javaアーカイブファイルであり、BD-Jオブジェクトを用いて動的なシナリオ制御を行うバイトコードアプリケーション(BD-Jアプリケーション)のプログラムが記述されている。BD-ROM上のコンテンツの再生単位を示す各タイトルの再生をBD-Jアプリケーションから制御したい場合は、このファイルを必要とする。このアーカイブファイルは、パーミッションリクエストファイルを含み、パーミッションリクエストファイルは、バイトコードアプリケーションと、ローカルホストとの間のソケット通信を許可している
　拡張子“bdjo”が付与されたファイルは、BD-Jモードの動作モードオブジェクトを格納したファイルである。

　index.bdmv（ファイル名固定）は、BD-ROM全体に関するインデックステーブルであり、映画作品のプロバイダを特定する識別子であるorganizationID（32bit）や、プロバイダが提供するBD-ROMのそれぞれに割り当てられた識別子であるdiscID（128bit）等の情報を持ち、再生装置へのディスク挿入後に、index.bdmvが最初に読み出されることで、再生装置においてディスクが一意に認識される。加えて、index.bdmv　にはBD-ROMにおいて再生可能となる複数のタイトルと、個々のタイトルを規定するBD-Jオブジェクトとを対応付けて示すテーブルが含まれる。

　MovieObject.bdmv（ファイル名固定）は、ナビゲーションコマンドを格納したファイルであり、プレイリストの選択やプレーヤ状態レジスタ、プレーヤ設定レジスタの読み出し／書き込みを行わせる。以上が、BDMVディレクトリについて説明である。つづいて、EMOVEディレクトリについて説明する。

　EMOVEディレクトリの配下には、BD-ROMに記録されているコンテンツと、内容的に同一となるコンテンツを携帯端末で視聴するためのAVデジタルストリームや管理情報が記録されており、複数のコピーソース格納ディレクトリが作成される。図中のDATA01,DATA02・・・・DATAxxは、それぞれがコピーソース格納ディレクトリである。コピーソース格納ディレクトリとは、デジタルコピーの対象となる単位であり、一個のBD-ROMにおいて、コピーの対象が、４つ存在するなら、EMOVEディレクトリの配下には、DATA01ディレクトリ、DATA02ディレクトリ、DATA03ディレクトリ、DATA04ディレクトリという4つのコピーソース格納ディレクトリが記録されることになる。

　コピーソース格納ディレクトリは、様々な個数だけ作成することができるから、ストリーム形式が異なる複数の携帯端末向け保護コンテンツや、再生内容のバリエーションが異なる複数の携帯端末向け保護コンテンツ等、デジタルコピーの需要が高い携帯端末向け保護コンテンツを、オーサリング時に予め作成しておくことができる。以上がBD-ROMのディレクトリ構成、ファイル構成についての説明である。またコピーソース格納ディレクトリに格納されている一式のファイルは、デジタルコピーの対象となる。コピーソース格納ディレクトリに格納されることでデジタルコピーの対象となる一式のファイルを、“コピーソースユニット”という。

　図１２は、ストリーム形式が異なる、複数の携帯端末向け保護コンテンツが記録されているBD-ROMのディレクトリ構成の一例を示す。この一例は、携帯端末向け保護コンテンツにVGA(Video Graphics Array)形式のもの、ワンセグ形式のものという2つのバージョンが存在することを前提にしており、これら2つのバージョンのそれぞれに対応する携帯端末向け保護コンテンツを、別個のコピーソースユニットとして扱い、DATA01ディレクトリ、DATA02ディレクトリに記録している。

　本図におけるDATA01ディレクトリは、VGA形式の携帯端末向け保護コンテンツに対応するコピーソース格納ディレクトリである。DATA01ディレクトリの配下にはEMOV_INF、MGR_DATA、PRG_MGR、PRG001.PGI、MOV001.SD1の５つのファイルが存在する。EMOV_INFは、コピー情報ファイルであり、携帯端末向けコンテンツをそれぞれ一意に識別するために割り当てられたコンテンツID（以降、「CID」と称する場合もある）が記録されている。EMOV_INFは、個々のコピーソース格納ディレクトリ毎に存在するので、個々のコピーソース格納ディレクトリ毎にコンテンツIDを変えることが可能であるし、また、コンテンツIDを同一にすることも可能である。コンテンツIDをコピーソース格納ディレクトリ毎に変化させれば、デジタルコピーサーバ３６では、複数のコンテンツIDに配置された個々の携帯端末向け保護コンテンツを、別々のコンテンツとして扱って管理することができる。一方、コンテンツIDを複数のコピーソース格納ディレクトリ間で同一にすれば、デジタルコピーサーバ３６では、複数のコンテンツIDに配置された個々の携帯端末向け保護コンテンツを、1つのコンテンツとして扱うことができる。

　MOV001.SD1は、暗号化されたMPEG4形式のビデオストリームであり、個々のピクチャデータの解像度は640×480である。ビデオストリームの内部には、ランダムアクセスのための情報が含まれている。デジタルストリームに対応するMOV001.SD1は例えば所定の暗号化方式（例えば、CPRM方式）で暗号化される。所定の暗号化方式（例えば、CPRM方式）で暗号化されたデジタルストリームを復号するためのキー情報（タイトルキー）はBD-ROM内には記録されていないので、不正に再生できないよう保護されている。

　PRG001.PGIは、プレイリスト情報に該当する情報であり、MOV001.SD1の再生順序を示すと共に、ビデオストリーム、オーディオストリームの符号化方式や携帯端末向けコンテンツのタイトル名を示す。BD-ROMにおける本編コンテンツのプレイリストは、複数のAVストリームの再生順序を定義することで構成され、本編コンテンツにおけるプレイリストと、AVストリームとの比率は、１対多である。これに対して、携帯端末向け保護コンテンツにおけるプレイリストと、AVストリームとの比率は、１対１である。これは、携帯端末向け保護コンテンツには、対話的な再生制御が予定されず、単に携帯機器でAVストリームを視聴するだけの単純な再生制御に制約されていることを意味する。

　MGR_DATAには、携帯端末向けコンテンツのレジューム位置が記録されている。

　PRG_MGRは、携帯端末向けコンテンツのトータルの再生時間が記録されている。　

　DATA02ディレクトリは、ワンセグ形式の携帯端末向け保護コンテンツに対応するコピーソース格納ディレクトリである。このDATA02ディレクトリにおいて、EMOV_INF、MGR_DATA、PRG_MGR,PGR001.PG1が存在する点は、DATA01ディレクトリと同じである。一方、MOV001.SD1の代わりにMOV001.Sx1が存在し、DATA01ディレクトリにはないMOV001.MAI、MOV001が存在する点は、DATA01ディレクトリとの差異である。

　MOV001.Sx1は、MPEG4-AVC形式のデジタルストリームを格納したストリームファイルであり、個々のピクチャデータの解像度は320×240である。

　MOI(Media Object Information)ファイルは、EntryPESPacketNumテーブルを含む。EntryPESPacketNumテーブルは、MPEG4-AVCのIDRピクチャを包含していると判定されたPESパケットの先頭から、次のPESパケットの先頭までに存在するTSパケットの個数を示す。

　MAI(Media Attribute Information)ファイルは、MPEG4-AVCのデジタルストリームを構成するTSパケット不連続期間の開始時刻、終了時刻、位置情報、時刻オフセットを示す。

　DATA01ディレクトリにおけるMOV001.SD1には、その内部にランダムアクセスのための情報が存在する。これに対して、MOV001.Sx1には、そのようなランダムアクセスのための情報は存在しない。その代わりに、MOV001.Sx1には、MOV001.MAI、MOV001.MOIが対応付けられている。つまり、ワンセグ形式の携帯端末向け保護コンテンツは、ストリーム毎の管理情報が追加された形式になっている。このようにBD-ROMには、様々なストリーム形式に対応した携帯端末向け保護コンテンツが、複数のコピーソース格納ディレクトリに予め記録されているので、デジタルコピーにあたっては、つまりMPEG4形式、MPEG4-AVC形式のうち、所望のストリーム形式に合致した携帯端末向け保護コンテンツを選択することができる。トランコードを行うことなく、所望のストリーム形式のコンテンツを持ち出しに供することができるので、BD-ROMに複数のコピーソース格納ディレクトリが存在することの意義は大きい。本図におけるDATA03ディレクトリ、DATA04ディレクトリは、その他の格納形式、例えば、QuickTimeの形式やWindows（登録商標） Media Playerの形式で、持ち出し視聴用ためのコピーソースユニットを格納してもよい。しかし、これらの形式まで言及すると説明が煩雑になるので、これらの形式については説明を省略する。

　続いて、このリードオンリーメディア１０５におけるアプリケーションの管理の仕方について説明する。

　図１３（ａ）は、index.bdmvファイルとタイトルの関係の一例を示す図である。タイトルとはアプリケーションとAVストリームを組にした再生単位であり、index.bdmvファイルにはディスク上のタイトル構成が記載されており、ディスク上の各タイトルと、対応するアプリケーション（BD-JモードタイトルであればBD-Jアプリケーション、HDMVモードタイトルであればシナリオプログラム）の参照関係を管理している。

　図１３（ａ）の一例では、「First Play」、「TopMenu」、「Title＃1」、「Title#2」、「Title#3」が存在する。

　「Top Menu」はリモコンのメニューキーを押したときやタイトル再生が終了したときに再生されるタイトルであり、主にタイトルの選択や、字幕/音声の言語選択を行うことに用いられる。このタイトルの選択がなされるとBD-Jオブジェクト（99999.bdjo）に含まれるアプリケーション管理テーブルに従い、アーカイブファイル(99999.jar)にて定義されメニュー表示BD-Jアプリケーションの起動が、再生装置に命じられる。

　「First Play」はBD起動時に自動的に再生されるタイトルであり、主にBDの利用規約表示などに用いられる。

　「Title＃1」は、例えば本編映像のタイトルであり、このタイトルの選択がなされるとBD-Jオブジェクト（00001.bdjo）に含まれるプレイリストアクセス情報に従い、プレイリスト情報ファイル(00001.mpls)を用いてデジタルストリーム(00001.m2ts)の再生が行われる。BD-Jオブジェクト（00001.bdjo）に含まれるアプリケーション管理テーブルに従い、アーカイブファイル(00001.jar)にて定義される本編再生BD-Jアプリケーションの起動が、再生装置に命じられる。

　「Title＃2」は、例えば特典映像のタイトルであり、このタイトルの選択がなされるとBD-Jオブジェクト（00002.bdjo）に含まれるプレイリストアクセス情報に従い、プレイリスト情報ファイル(00002.mpls)を用いてデジタルストリーム(00002.m2ts)の再生が行われる。

　「Title#3」は、例えばデジタルコピーに対応するタイトルであり、このタイトルの選択が行われると、デジタルコピーのGUI等を管理するデジタルコピー管理BD-Jアプリケーションのアーカイブファイル(88888.bdjo)と、オンメディアライブラリのアーカイブファイル(11111.jar)とがロードされる。このオンメディアライブラリのアーカイブファイルの中には、e-MoveLibrary.classというクラスファイルが存在し、デジタルコピー管理BD-Jアプリケーションには、このクラスファイルを取り込む旨の宣言文“ClassPass＝e-MoveLibrary”が存在する。この宣言によって、デジタルコピー管理BD-Jアプリケーション内のAPIコールと、オンメディアライブラリ内のAPIとのリンクがなされる。

　ここで、Title#3を構成するデジタルコピー管理BD-Jアプリケーションとオンメディアライブラリ２８とは、別々のアーカイブファイルに分けて記録しても良いし、１つのJARファイルにまとめて記録しても良い。

　上述に示す例は単なる一例である。例えば「Title＃1」に対応付けられたBD-Jオブジェクトに含まれるプレイリストアクセス情報にプレイリストが示されなければ、デジタルストリームの再生は行われない。

　また、「Title#3」に対応付けられたBD-Jオブジェクトに含まれるプレイリストアクセス情報に再生可能なプレイリストを示せば、アプリケーション管理テーブルに示されるBD-Jアプリおよびオンメディアライブラリ２８の実行と並行して、BD-Jオブジェクトに含まれるプレイリストアクセス情報に従うプレイリスト再生が再生装置で行われることになる。

　図１３（ｂ）は、各タイトルのBD-Jオブジェクトにおけるアプリケーション管理テーブルの内容、プレイリストアクセス情報の内容を示す。

　Top Menuに対応するBD-Jオブジェクト（99999.bdjo）に含まれるアプリケーション管理テーブルには、メニュー表示BD-Jアプリケーションの識別番号である99999が記載されている。よって、Top Menuの選択がなされるとBD-Jオブジェクト（99999.bdjo）に含まれるアプリケーション管理テーブルに従い、アーカイブファイル(99999.jar)にて定義されるメニュー表示BD-Jアプリケーションの起動が再生装置に命じられる。

　Title＃1に対応するBD-Jオブジェクト（00001.bdjo）に含まれるアプリケーション管理テーブルには、本編再生BD-Jアプリケーションの識別番号である00001が記載されている。よって、Title＃1の選択がなされるとBD-Jオブジェクト（00001.bdjo）に含まれるアプリケーション管理テーブルに従い、アーカイブファイル(00001.jar)にて定義される本編再生BD-Jアプリケーションの起動が再生装置に命じられる。

　また、BD-Jオブジェクト（00001.bdjo）に含まれるプレイリストアクセス情報には、プレイリスト情報ファイル(00001.mpls)の識別番号である00001が記載されている。よって、Title＃1の選択がなされると、プレイリスト情報ファイル(00001.mpls)を用いたストリームファイル(00001.m2ts)の再生が再生装置に命じられる。

　Title＃2に対応するBD-Jオブジェクト（00002.bdjo）に含まれるアプリケーション管理テーブルには、特典映像BD-Jアプリケーションの識別番号である00002が記載されている。よって、Title#3の選択がなされるとBD-Jオブジェクト（00002.bdjo）に含まれるアプリケーション管理テーブルに従い、アーカイブファイル(00002.jar)にて定義される特典映像BD-Jアプリケーションの起動が再生装置に命じられる。

　また、BD-Jオブジェクト（00002.bdjo）に含まれるプレイリストアクセス情報には、プレイリスト情報ファイル(00002.mpls)の識別番号である00002が記載されている。よって、Title＃1の選択がなされると、プレイリスト情報ファイル(00002.mpls)を用いたストリームファイル(00002.m2ts)の再生が再生装置に命じられる。

　Title#3に対応するBD-Jオブジェクト（88888.bdjo）に含まれるアプリケーション管理テーブルには、デジタルコピー管理BD-Jアプリの識別番号である(88888)と、オンメディアライブラリ２８の識別番号である11111とが記載されている。よって、Title#3の選択がなされるとBD-Jオブジェクト（88888.bdjo）に含まれるアプリケーション管理テーブルに従い、アーカイブファイル(88888.jar)にて定義されるデジタルコピー管理BD-Jアプリケーションの起動と、アーカイブファイル(11111.jar)にて定義されるオンメディアライブラリ２８の起動とが再生装置に命じられる。

　以上の具体例においてオンメディアライブラリ２８及びデジタルコピー管理BD-Jアプリケーションは、Title#3にのみ存在し、Title#3のBD-Jオブジェクトにおけるアプリケーション管理テーブルに、これらオンメディアライブラリ２８及びデジタルコピー管理BD-Jアプリケーションは記載されている。よって、Title#3のタイトル番号がタイトル番号レジスタに設定され、Title#3がカレントタイトルになった際、オンメディアライブラリ２８及びデジタルコピー管理BD-Jアプリケーションについて、クラスロードがなされ、オンメディアライブラリ２８及びデジタルコピー管理BD-Jアプリケーションは、バイトコードインタプリタによる実行に供される。

　一方、オンメディアライブラリ２８、デジタルコピー管理BD-Jアプリケーションは、Title＃1、Title＃2の構成要素ではなく、Title＃1、Title＃2のアプリケーション管理テーブルには記述されていないので、Title#3の再生が終了して、Title＃1又はTitle＃2の再生が開始した際、オンメディアライブラリ２８及びデジタルコピー管理BD-Jアプリケーションの動作は終了する。以上のように、オンメディアライブラリ２８及びデジタルコピー管理BD-Jアプリケーションは、タイトルを生存区間としたアプリケーションシグナリングに供されることになる。
このように、オンメディアライブラリ２８の生存区間を、デジタルコピー管理BD-Jアプリケーションの生存区間と同じとする（この例では、Title#3の開始時点から終了時点までの間がオンメディアライブラリ２８およびデジタルコピー管理BD-Jアプリケーションの実行可能な生存区間とする）ことで、オンメディアライブラリ２８の生存区間と異なる生存区間のBD-Jアプリケーション（この例では、Title#3とは異なるTitle＃1、またはTitle＃2のアプリケーション管理テーブルにのみ記載されるBD-Jアプリケーション）がオンメディアライブラリ２８を利用することを制限することができる。

　以上のように本実施形態によれば、機器固有機能制御部３３を制御するためのオンメディアライブラリ２８やこのオンメディアライブラリ２８を用いて機器固有機能を実行するデジタルコピー管理BD-Jアプリケーション、機器固有機能の対象となるSD_VideoコンテンツがBD-ROMに記録されてユーザに供給されるので、ユーザは、パソコンを利用することなく、BD-ROMが再生装置に装填されている状態のまま、デジタルコピーを実行することができる。

　(第４実施形態)
　本実施形態では、機器固有機能制御部３３のコマンド処理部６０９が解釈可能なコマンドの種別について説明する。コマンド処理部６０９が解釈可能なコマンドとしては、以下のものがある。

　１.初期化要求コマンド(REQUEST_INITIALIZE)
　初期化要求コマンドは、デジタルコピーモジュール３５を初期化し、他のソケットコマンドを使用可能な状態にする。もし一旦初期化がなされれば、幾つかのパラメータ(シリアルID、ソースロケーション、サーバURL、セキュアなメモリカード１０４スロット、レジューム点)はリセットされる。コマンドが再度実行され、その実行に成功した際、これらのパラメータは、リセットされる。

　このコマンドは、転送中、転送後、ファイナライジングの何れかの状態において有効となる。このコマンドのレスポンスには、OKレスポンス、フェータルエラーレスポンスがある。OKレスポンスは、デジタルコピーモジュール３５の初期化及びアクティベートを示す。フェータルエラーは、フェータルエラーのために初期化が失敗したことを示す。

　２.チェックチケットコマンド(REQUEST_CHECKTICKET)
　チェックチケットコマンドは、コピーチケットを、コピーのためにパラメータ設定コマンドで設定されたパラメータを用いてデジタルコピーサーバ３６にコピーチケットをチェックさせることを要求する。このコマンドがコールされる前に、プロセスで必要な全てのパラメータは、設定コマンドで設定されねばならない。コピーチケットをチェックした後、オンメディアライブラリ２８は、コピーコマンドでデータ転送の実行を要求することができる。このコマンドは、デジタルコピーモジュール３５が初期化状態、レディ状態にある際に発行することができる。このコマンドには引数はない。レスポンスには、OKレスポンス、インバリッドエラーレスポンス、接続エラーレスポンスがある。ビジーエラーレスポンスがある。

　OKレスポンスは、コピーチケットのチェックが受け入れられたことと、デジタルコピーモジュール３５がチケットレスポンスの受信に成功したことを示す。インバリッドエラーレスポンスは、プロセスのためのパラメータのうち、幾つかが未設定であり、チェックチケットに失敗したことを示す。接続エラーレスポンスは、レスポンスがデジタルコピーサーバ３６に到達しないか、又は、デジタルコピーサーバ３６から正しい応答を受け取っていないことを示す。

　ビジーエラーレスポンスは、BD-ROMがAV再生プロセスのためにロックされていて、デジタルコピーモジュール３５がBD-ROMをアクセスすることができないことを示す。このエラーは、BD-ROM再生プロセスとは異なるプロセスで、デジタルコピーモジュール３５が実行されている際、発生する。このエラーコードがリターンした際、オンメディアライブラリ２８はこのコマンドの代わりにチェックチケットバイデータフィード要求を試みねばならない。

　フェータルエラーレスポンスは、フェータルエラーのために、チケット要求が失敗したことを示す。

　３.チェックチケットバイデータフィードコマンド(REQUEST_CHECKTICKET_BYDATAFEED)
　チェックチケットバイデータフィードコマンドは、コピーチケットを、コピーのためにパラメータ設定コマンドで設定されたパラメータを用いてデジタルコピーサーバ３６にチェックさせることを要求する。このコマンドがコールされる前に、プロセスで必要な全てのパラメータは、設定コマンドで設定されねばならない。チケットをチェックした後、オンメディアライブラリ２８は、コピーコマンドでデータ転送の実行を要求することができる。このコマンドは、デジタルコピーモジュール３５が初期化状態、レディ状態にある際に発行することができる。このコマンドがコールされた際、設定コマンドで設定されたソースロケーションは無視され、このコマンドで特定されたバイナリデータを、ターゲット情報ファイルとして用いて、特定されたバイナリデータを使用する。

　このコマンドは、チェックチケット要求がビジーエラーで返る場合のみコールされる。よって、チェックチケット要求がビジーエラーで返る可能性がない場合、デジタルコピーモジュール３５はこのコマンドを実装にする必要はない。

　引数は、情報ファイルの長さ、情報ファイルである。レスポンスとしては、OKレスポンス、インバリッドエラーレスポンス、接続エラーレスポンス、フェータルエラーレスポンスがある。OKレスポンスは、状態番号、残りコピー回数である。OKレスポンスは、コピーチケットのチェックが受け入れられたことと、デジタルコピーモジュール３５がチケットレスポンスの受信に成功したことを示す。インバリッドエラーレスポンスは、プロセスのためのパラメータのうち、幾つかが未設定であり、コピーチケットのチェックに失敗したことを示す。接続エラーレスポンスは、レスポンスがデジタルコピーサーバ３６に到達しないか、又は、デジタルコピーサーバ３６から正しい応答を受け取っていないことを示す。

　ノーサポートレスポンスは、デジタルコピーモジュール３５がこのコマンドをサポートしていないことを示す。チケットチェック要求がビジーで返る可能性がない場合、デジタルコピーモジュール３５はこのコマンドを実装にする必要はなく、ノーサポートエラーレスポンスを返す。チケットチェック要求がビジーでリターンする可能性がある場合、デジタルコピーモジュール３５はこのコマンドを実装して、ノーサポートレスポンスを返すべきではない。フェータルエラーレスポンスは、フェータルエラーのために、チケット要求が失敗したことを示す。

　
　４.コピー要求コマンド(REQUEST_COPYコマンド)
　コピー要求コマンドは、出力装置設定コマンドで設定されたセキュアなメモリカード１０４にコンテンツを出力する。このコマンドは非同期であり、オンメディアライブラリ２８は、進捗取得コマンドを通じてこの転送プロセスをチェックすることができる。転送プロセス中にAV再生が実行された場合、AV再生が終わるまで、コピー速度が減じられ、データ転送プロセスは一時停止する。コピープロセスは、キャンセル要求がインボークされた場合、クローズ要求がインボークされた場合、BD-ROMがイジェクトされた場合、キャンセルされる。

　キャンセル後に、部分的にコピーされたデータをクリアするかどうかは実装マターとなる。このコマンドがコールされる前に、チェックチケット要求コマンドによってコピーチケットのチェックがなされねばならない。このコマンドは、レディ状態で有効になる。このコマンドのレスポンスには、OKレスポンス、フェータルエラーレスポンスがある。OKレスポンスは、コピー要求が受け入れられ、デジタルコピーモジュール３５がコンテンツのコピーを開始した際に発行される。フェータルエラーレスポンスは、デジタルコピーモジュール３５がコピーに失敗した旨を示す。

　
　５.コピーバイデータフィード要求コマンド(REQUEST_COPY_BYDATAFEEDコマンド)
　コピーバイデータフィード要求コマンドは、出力装置設定コマンドで特定されたセキュアなメモリカード１０４に、コンテンツを出力する。このコマンドは、非同期であり、オンメディアライブラリ２８は、プロセス取得コマンドを介してコピー進捗をチェックすることができる。転送中にAV再生が実行された場合、AV再生が終了するまで、コピー速度は減少するか停止する。このコピープロセスは、キャンセル要求がインボークされた場合、クローズ要求がインボークされた場合、BD-ROMがイジェクトされた場合、キャンセルされる。キャンセル後、部分的にコピーされたデータをクリアするかどうかは実装マターである。このコマンドがコールされる前に、チェックチケットコマンドのチェックがなされなければならない。このコマンドは、デジタルコピーモジュール３５がレディ状態にある場合のみ有効となる。このコマンドがコールされた場合、ソースロケーションコマンドで設定されたソースロケーションは無視され、データフィード要求コマンドで特定されたバイナリデータをターゲットコンテンツとして用いる。このコマンドはコピー要求がビジーでリターンした場合のみコールされる。よって、このコマンドは、コピー要求がビジーエラーでリターンする可能性はない。デジタルコピーモジュール３５はこのコマンドを実装にする必要はない。引数としては、管理データファイル、プログラム管理ファイル、プログラムファイル、ムービーファイルがある。このコマンドに対するレスポンスには、OKレスポンス、ノーサポートレスポンス、フェータルエラーレスポンスがある。OKレスポンスは、コピー要求が受け入れられ、コンテンツのコピーをデジタルコピーモジュール３５に開始させることを示す。

　ノーサポートレスポンスは、デジタルコピーモジュール３５がこのコマンドをサポートしていないことを示す。コピー要求がビジーエラーでリターンする可能性がない場合、デジタルコピーモジュール３５はこのコマンドを実装にする必要はなく、ノーサポートエラーをリターンすればよい。デジタルコピーモジュール３５は、このコマンドを実装して、ノーサポートエラーをリターンしなくてもよい。

　フェータルエラーレスポンスは、フェータルエラーによって、コピーを開始させることはできないことを示す。

　６.データフィード要求コマンド(REQUEST_DATAFEEDコマンド)
　データフィード要求コマンドは、コピーのために特定されたデータブロックのコピーを開始させる。オンメディアライブラリ２８は、このコマンドを、コピーバイデータフィード要求が成功した場合のみ、コールすることができる。同じファイル名のファイルが連続して特定された場合、オンメディアライブラリ２８は、特定したファイルにデータを追加する。オンメディアライブラリ２８は、複数のファイルのコピーを連続して要求せねばならない。カレントファイルのコピーを完了する前に、他のファイルを特定すべきではない。データブロックのサイズは、６４Ｋバイト以下でなければならない。ファイルの終わりに到達すれば、データブロックの長さを“0”とする。

　引数となるのは、BD-ROMに記録されたファイルのファイル名、データブロック長、データブロックのバイナリデータである。OKレスポンスは、データブロックのコピーがサクセスした旨を示す。ノーサポートレスポンスは、デジタルコピーモジュール３５がこのコマンドをサポートしていない旨を示す。フェータルエラーレスポンスは、デジタルコピーモジュール３５がコピーに失敗した旨を示す。転送状態でこのエラーが発生した場合、デジタルコピーモジュール３５は停止状態に移行せねばならない。

　７.キャンセル要求コマンド(REQUEST_CANCELコマンド)
　キャンセル要求コマンドは、カレントのプロセスのキャンセルを要求する。もしカレントのプロセスのキャンセルに成功した場合、部分的にコピーされたデータは、セキュアなメモリカード１０４から削除される。このコマンドは、デジタルコピーモジュール３５が転送中／転送後状態にある場合のみ有効になる。

　８.ファイナライズ要求コマンド(REQUEST_FINALIZEコマンド)
　ファイナライズ要求コマンドは、キーダウンロードと、プロセスのファイナライズとをデジタルコピーモジュール３５に要求する。デジタルコピーモジュール３５が一旦ファイナライズを開始すれば、オンメディアライブラリ２８はファイナライズをキャンセルすることはできない。レスポンスとしては、OKレスポンス、接続エラーレスポンス、フェータルエラーレスポンスがある。OKレスポンスは、デジタルコピーサーバ３６がキーダウンロード要求を受け入れ、デジタルコピーモジュール３５がキーダウンロードレスポンスの受け入れに成功したことを示す。接続エラーレスポンスは、デジタルコピーモジュール３５がデジタルコピーサーバ３６に到達できないこと、正しいレスポンスがデジタルコピーサーバ３６からのレスポンスではなかったことを示す。フェータルエラーレスポンスは、フェータルエラーのためにキーダウンロード要求が失敗したことを示す。

　９.クローズ要求コマンド(REQUEST_CLOSEコマンド)
　クローズ要求コマンドは、クローズ操作を完了した後、デジタルコピーモジュール３５をクローズし、プロセスのためのリソースを開放して、デジタルコピーモジュール３５は非初期化状態に戻ることをデジタルコピーモジュール３５に命じるコマンドである。このコマンドは、どのステートでもコールされる。最終状態でこのコマンドがコールされた場合、最終プロセスが完了するまで、クローズ操作はブロックされる。転送中又は転送後状態でこのコマンドがコールされた場合、キャンセル操作が実行され、クローズ操作が開始する。レスポンスとしては、クローズが成功した旨を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すFATALレスポンスがある。

　１０.サーバURL設定コマンド(SET_SERVERURL)
　サーバURL設定コマンドは、コピープロセスのために接続すべきデジタルコピーサーバ３６のURLを設定する。このコマンドが成功完了した際、直前のサーバURLは、新たなサーバURLによって上書きされる。レスポンスとしては、プロセスにおいてサーバURLの設定が成功した旨を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すフェータルレスポンスがある。空白文字が特定された場合、以前設定したURLが有効になる。

　１１.ソースロケーション設定コマンド(SET_SRCLOCATION)
　ソースロケーション設定コマンドは、コピーすべきコンテンツのソースロケーションを設定する。このソースロケーションは、リードオンリーメディア１０５上に存在せねばならない。このコマンドが成功完了した際、直前のソースロケーションは、新たなソースロケーションによって上書きされる。引数は、インサートされたリードオンリーメディア１０５におけるディレクトリを示す絶対パスである。ソースロケーション設定のためのパス名は、/mnt/bdrom/EMOVE/DATA01にエンクローズされねばならない。特定されたファイルパスは、有効なコンテンツを含む必要がある。

　レスポンスとしては、コピープロセスにおいてソースロケーションの設定が成功した旨を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すフェータルエラーレスポンス、インバリッドレスポンスの何れかがある。OKレスポンスは、プロセスのために設定に成功した位置を示す。インバリッドレスポンスは、特定されたパス名が実在するディレクトリを特定していない、特定されたディレクトリがBD-ROMに位置していない、特定されたディレクトリが有効なコンテンツを有していないという理由で発生する。

　１２.シリアルID設定コマンド(SET_SERIALID)
　シリアルID設定コマンドは、このコピープロセスのために特定されたシリアルIDを設定する。シリアルIDが設定済みである場合、このコマンドが成功完了した際、直前のシリアルIDは、新たなシリアルIDによって上書きされる。レスポンスとしては、プロセスにおいてシリアルIDの設定が成功した旨を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すレスポンスの何れかがある。

　
　１３.出力装置設定コマンド(SET_OUTPUTDEVICE)
　出力デバイス設定コマンドは、コピープロセスのためのドライブデバイスのスロットを設定する。スロットが設定済みである場合、このコマンドが成功完了した際、直前のターゲットスロットは、新たなスロットによって上書きされる。レスポンスとしては、プロセスにおいて成功設定した出力装置を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すレスポンスの何れかがある。

　１４.レジューム設定コマンド(SET_RESUME)
　レジューム設定コマンドは、プロセスのためのレジューム点を特定する。このコマンドによってレジューム点が特定された場合、デジタルコピーモジュール３５は、プロセスの完了後にセキュアなメモリカード１０４の管理データファイルを更新する。これは、レジューム点からSZ_DATAＶコンテンツを再生するためである。レジューム点が設定されれば、このコマンドが成功完了した際、直前のレジューム点が新たなレジューム点によって上書きされる。レジューム点は、完了状態においてのみ、ターゲットのセキュアなメモリカード１０４に反映される。完了状態において、このコマンドがコールされれば、即座に、ターゲットセキュアなメモリカード１０４に反映される。引数としては、秒単位のオフセットを指定することができる。レスポンスとしては、プロセスにおいて成功設定したレジューム点を示すOKレスポンス、フェータルエラーのためにコマンドが失敗したことを示すレスポンスの何れかがある。

　１５.リボケーションリスト設定コマンド(SET_REVOCATIONLIST)
　リボケーションリスト設定コマンドは、デバイスリスト長と、リボケーションリストデバイスリストとをオペランドで指定する。このコマンドは、デジタルコピーモジュール３５にリボケーションリストを設定する。リボケーションリストとは、過去に不正なコピー行為をしたとして、マークされている不正再生装置のリストであり、セキュアなメモリカード１０４に実装されている認証回路との処理認証で使用される。これは、リボケーションリストに示されている不正再生装置に、デジタルコピーを実行させないためである。チェックチケット要求コマンドをコールする前に、オンメディアライブラリ２８は、リボケーションリストをデジタルコピーモジュール３５にセットしなければならない。リボケーションリストが既に設定されている場合、前のリボケーションリストは、上記コマンドがサクセスした際、新たなリボケーションリストによって上書きされる。レスポンスとしては、プロセスのためにリボケーションリスト設定が成功したことを示すOKレスポンス、知名エラーのためにコマンドが失敗したことを示すFATALレスポンスがある。

　１６.デバイスデバイスリスト取得コマンド(GET_DEVICELIST)
　デバイスデバイスリスト取得コマンドは、プロセスのために再生装置によってサポートされているセキュアなメモリカード１０４スロットのデバイスリストを取得する。このコマンドのレスポンスは、以下の形式であり、Xに番号付けされたカードスロット、USB接続を通じてXに番号付けされたカードスロット、Xに番号付けされたその他の装置を羅列したものである。レスポンスは、コマンドが成功完了したことを示す。複数のスロットの1つとして位置付けられているローカルストレージは、その名称が、レスポンスメッセージの終わりで指示される。

　１７.デバイス情報取得コマンド(GET_DEVICEINFO)
　デバイス情報取得コマンドは、特定されたスロットにインサートされたセキュアなメモリカード１０４の総容量／有効容量を取得する。このスロット名は、デバイスデバイスリスト取得コマンドで取得したものの1つであり、レスポンスとしては、総スペース、フリースペース、プログラム数がある。デバイス情報取得コマンドがサクセスした場合、ターゲットセキュアなメモリカード１０４がインサートされ、有効である場合、レスポンスされたメッセージは、総容量／有効容量、プログラム数を含む。

　１８.進捗取得コマンド(GET_PROGRESS)
　進捗取得コマンドは、データ転送の進捗状況情報を取得する。レスポンスとしては、残りサイズ／総サイズとなる。未転送であれば、単にOKのみを返す。転送完了であれば(デジタルコピーモジュール３５が転送後、ファイナラリジング、完了)、（０／総サイズ）が返される。転送プロセスが停止又はキャンセルされれば(停止、キャンセル)、コピーされた総サイズが返される。

　１９.状態取得コマンド(GET_STATE)
　状態取得コマンドは、未初期化、初期化、レディ、転送中、転送後、ファイナライジング、完了、キャンセル、ストップの何れかを示す。

　２０.パラメータ取得コマンド(GET_PARAMETER)
　パラメータ取得コマンドは、カレントステート、カレントソースロケーション、カレント出力デバイス、カレントサーバURL、カレントシリアルID、カレントレジューム点を取得するためのコマンドである。幾つかのパラメータが存在しない場合、空白文字列が返ることになる。

　その他、コマンド送信とは関係なく、非同期に、オンメディアライブラリ２８に出力されるイベントには、以下の非同期イベントがある。ここでの非同期イベントには、セキュアなメモリカード１０４が装填されたことを示す非同期デバイス状態インサートイベント、セキュアなメモリカード１０４がイジェクトされたことを示す非同期装置状態イジェクトイベント、非同期状態変化イベントがある。非同期状態変化イベントは、セキュアなメモリカード１０４の容量無し、セキュアなメモリカード１０４のライトプロテクト、セキュアなメモリカード１０４のI/Oエラーの発生を通知する。

　非同期状態変化イベントは、以下のi),ii)に該当する場合を除き、デジタルコピーモジュール３５の状態が変化した際に発生する。

　i)デジタルコピーモジュール３５の状態は変化していないのにデジタルコピーモジュール３５が初期化されてサクセス非同期状態変化イベントが初期化状態を示す場合。

　ii)デジタルコピーモジュール３５の状態が変化していないのにデジタルコピーモジュール３５がレディ状態となってチェックチケット要求コマンドがサクセスし、レディ状態を示す非同期状態変化イベントが発生した場合。

　以上のコマンドを用いてデジタルコピーを実現するための具体的な通信シーケンスについて説明する。

　図１４は、アプリ内API呼出しの詳細を示すシーケンス図である。このシーケンスは、オンメディアライブラリ２８APIを用いて記述されている。本図の横方向には、デジタルコピー管理BD-Jアプリ、オンメディアライブラリ２８、デジタルコピーモジュール３５が、それぞれ配置されている。縦方向には、複数の時間軸を描いている。時間軸上の各時点が、メッセージの送受信のタイミングとなる。本図におけるシーケンスは、ａ.機器確認フェーズ、ｂ.初期化フェーズ、ｃ.コピー先状態確認フェーズ、ｄ.パラメータセットフェーズ、ｅ.残コピー回数確認フェーズ、ｆ.コピー開始フェーズ、ｇ.コピー進捗確認フェーズ、ｈ.鍵書込みフェーズからなる。

　ａ.機能確認フェーズは、BD-JアプリケーションがBCManager＃getInstanceAPIを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥ(BCManager又はUnsupportedOperationExceptionのスロゥ)というアプリケーション間通信によって構成される。

　BCManager＃getInstanceAPIは、デジタルコピーモジュール３５を制御するための各種メソッドを持つBCManagerクラスのインスタンスを取得する。再生装置がデジタルコピーに対応していなかった場合はUnsupportedOperationExceptionをスローする。

　ｂ.初期化フェーズは、BD-JアプリケーションがBCManager＃addBCStatusChangeListenerAPIを呼び出すAPIコール、BCManager＃initialBCを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるBCManagerInitialEventイベントのスロゥというアプリケーション間通信によって構成される。

　BCManager＃addBCStatusChangeListenerAPIは、デジタルコピーモジュール３５の状態変化をモニタリングするためのAPIである。デジタルコピーモジュール３５の状態変化を検知すると、変化した状態をBD-Jアプリケーションへ通知する。

　BCManager＃initializeBCAPIは、デジタルコピーモジュール３５の初期化を行うためのAPIである。このAPIが呼ばれると、オンメディアライブラリ２８は、デジタルコピーモジュール３５との接続を行う。接続に失敗した場合は、UnsupportedOperationExceptionをスローする。初期化が成功すれば、BCInitializedEventをBD-Jアプリケーションに通知する。

　ｃ.コピー先状態確認フェーズは、BD-JアプリケーションがBCManager＃getDeviceListAPIを呼び出すAPIコール、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥ、BD-JアプリケーションがBCOutputDevice＃getFreeSpaceAPIを呼び出すAPIコール、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥというアプリケーション間通信によって構成される。

　BCManager＃getDeviceListAPIは、再生装置がコピー先としてサポートしているメディア一覧（SDカード、USBメモリ）を取得するためのAPIである。それぞれのメディアはBCOutputDeviceクラスのインスタンスとして表現される。BCOutputDeviceクラスはインスタンスが示すメディアの種類と番号（SD_１、USB_１）を取得するメソッド(BCOutputDevice＃getName)、空き容量を取得するメソッド（BCOutputDevice＃getFreeSpace）、及びトータル容量を取得するメソッド（BCOutputDevice＃getTotalSpace）を持つ。図１４では、空き容量を取得するメソッド（BCOutputDevice＃getFreeSpace）の呼び出しに対する応答として、空き容量の一例として10737418240（byte）を返している。

　ｄ.パラメータセットフェーズは、BCManager＃setServerURLAPIを呼び出すAPIコール、BCManager＃setSourceLocationAPIを呼び出すAPIコール、BCManager＃setOutputDeviceAPIを呼び出すAPIコール、BCManager＃setSerialIdAPIを呼び出すAPIコールから構成される。ｄ.パラメータセットフェーズでセットされるパラメータは、具体的には、シリアルID，コピー元のコンテンツの位置、デジタルコピーサーバ３６のURL、コピー先のメディアである。コンテンツIDはコピー対象の携帯端末向け保護コンテンツのEMOV_INFファイルに記載されている値をもちいる。

　コピー元のコンテンツの位置は、携帯端末向けコンテンツが記録されているディレクトリまでの絶対パスで示される。例えば、"/mnt/bdrom/EMOVE/DATA01"等である。この場合、"/mnt/bdrom"はBD-ROMメディアのマウントポイントに当たる。

　デジタルコピーサーバ３６のURLは、グローバルネットワーク上のサーバを示すURLが指定される。例えば"http://xxx.yyy.zzz"等である。

　コピー先メディアは、再生装置がサポートしているコピー先メディア一覧の中から指定される。BD-Jアプリケーションはデジタルコピーモジュール３５に対し、現在の再生装置でサポートしているメディア一覧を要求すると、「＜メディアの種類＞_＜番号＞」の形のリストが送られてくる。例えば、再生装置がSDカードスロットとUSBメモリスロットの両方をそれぞれ、１つずつサポートしていた場合、「SD_１　USB_１」というリストが送られてくる。SDカードスロットなし、USBメモリスロットが２つ持つ場合は「USB_１　USB_２」というリストが送られることとなる。コピー先一覧を受け取ったBD-Jアプリケーションは、それらの一覧をユーザに提示し、どのメディアにコピーするか、ユーザの指示を受け、ユーザが選択したメディアを、コピー先メディアとして指定することになる。

　BCManager＃setServerURL(URL)APIは、デジタルコピーモジュール３５へデジタルコピーサーバ３６のURLをセットするするためのAPIである。

　BCManager＃setSourceLocation(File srcdir)は、デジタルコピーモジュール３５へコピー元のコンテンツ位置をセットするためのAPIである。コンテンツ位置は、携帯端末向けコンテンツが記録されているディレクトリまでの絶対パスで示される（"/mnt/bdrom/EMOVE/DATA01"等）。

　BCManager＃setOutputDevice(device)は、デジタルコピーモジュール３５へコピー先メディアをセットするためのAPIである。コピー先メディアはBCManager＃getDeviceList()で取得できたメディアリストの中から選択される。

　BCManager＃setSerialId(byte[])は、デジタルコピーモジュール３５へシリアルIDをセットするためのAPIである。

　ｅ.残コピー回数確認フェーズは、BD-JアプリケーションがBCManager＃checkTicketを呼び出すAPIコール、及び、その呼び出しに対するイベントスロゥというアプリケーション間通信によって構成される。

　BCManager＃checkTicketAPIは、残コピー回数確認をデジタルコピーモジュール３５へ要求するためのAPIである。デジタルコピーモジュール３５は残コピー回数の確認が要求されると、現在セットされているパラメータを用いてデジタルコピーサーバ３６へ残コピー回数の問い合わせを行う。得られた残コピー回数はBCCheckResponseクラスのインスタンスとしてBD-Jアプリケーションにリターンされる。BD-JアプリケーションはBCCheckResponse＃remainingTimesOfCopy()を呼び出すことで残コピー回数を確認することができる。また、残コピー回数が1回以上残っていれば、BCReadyEventがBD-Jアプリケーションに通知される。

　ｆ.コピー開始フェーズは、BD-JアプリケーションがBCManager＃makeCopyAPIを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥというアプリケーション間通信によって構成される。

　BCManager＃makeCopyAPIは、デジタルコピーモジュール３５へコピー開始を要求するためのAPIである。オンメディアライブラリ２８はデジタルコピーモジュール３５へコピー開始を要求した後、BD-Jアプリケーションには進捗状況を示すBCProgressインスタンスをリターンし、コピー処理はデジタルコピーモジュール３５において非同期で行われる。

　ｇ.コピー進捗確認フェーズは、BD-JアプリケーションがBCProgress＃remainingAPIを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥ、BD-JアプリケーションがBCProgress＃totalAPIを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるイベントスロゥ、というアプリケーション間通信によって構成される。

　BCProgress＃total()は、これまでコピーしたトータルのコピーバイト数を取得するためのAPIである。

　BCProgress＃remaining()は、残りのコピーバイト数を取得するためのAPIである（図１４では、BCProgress＃remaining()の呼び出しに対する応答としての残りのコピーバイト数の一例として524288000（byte）を返している）。コピー処理が完了するとBCTransferredEventがBD-Jアプリケーションに通知される。

　ｈ.鍵書込みフェーズは、BD-JアプリケーションがBCManager＃finalizeBCAPIを呼び出すAPIコール、及び、その呼び出しに対するイベントスロゥというアプリケーション間通信、BD-JアプリケーションがBCManager＃cancelCopyを呼び出すAPIコール、及び、その呼び出しに対するイベントスロゥ、BD-JアプリケーションがBCManager＃closeAPIを呼び出すAPIコール、及び、その呼び出しに対するデジタルコピーライブラリによるBCManager又はUnsupportedOperationExceptionをスローするというイベントスロゥというアプリケーション間通信によって構成される。

　BCManager＃finalizeBC()は、デジタルコピーモジュール３５へ復号鍵の書込みを要求するためのAPIである。復号鍵の書込みが完了するとBCCompleteEventがBD-Jアプリケーションに通知される。

　BCManager＃cancelCopy()は、デジタルコピーモジュール３５のコピー処理をキャンセルするためのAPIである。キャンセルに成功するとBCCancelEventがBD-Jアプリケーションに通知される。

　BCManager＃close()は、デジタルコピーモジュール３５が確保しているリソースを開放し、デジタルコピープロセスを終了するためのAPIである。

　以上が、オンメディアライブラリ２８、デジタルコピーモジュール３５、デジタルコピーサーバ３６間の通信シーケンスについての説明である。続いて、の詳細について、
　図１５は、デジタルコピーモジュール３５の状態遷移を示す図である。デジタルコピーモジュール３５はデジタルコピープロセスの進捗に応じて以下９個の状態を遷移する。本図における丸枠は、デジタルコピーモジュール３５が取りうる状態を模式的に示し、矢印は、状態遷移のトリガとなるべき事象を意味する。この矢印に付された注釈が、状態遷移のトリガになる事象の具体的な名称である。

　本図に示された機器固有機能制御部３３の各状態について説明する。

　NOT_INIT：この状態はデジタルコピーモジュール３５がまだ初期化されていないことを示す。この状態はBD-ROMがロードされた時点でのデジタルコピーモジュール３５の初期状態である。他の状態においてBD-JアプリケーションがBCManager＃close()を呼び出し、デジタルコピープロセスを終了した場合、デジタルコピーモジュール３５は再びNOT_INIT状態に戻る。この状態でBCManager＃initializeBC()が呼ばれると、INITIALIZED状態に遷移し、BD-JアプリケーションへはBCInitializedEventが通知される。

　INITIALIZED：この状態はデジタルコピーモジュール３５が初期化され、BD-Jアプリケーションからデジタルコピープロセスの機能を呼び出せる状態であることを示す。この状態で、BD-Jアプリケーションが必要パラメータ（例えば、BCManager＃setServerURL(URL)の呼び出しにより設定されるデジタルコピーサーバ３６のURL、BCManager＃setSourceLocation(File srcdir) の呼び出しにより設定されるコピー元のソースロケーション、BCManager＃setOutputDevice(device) の呼び出しにより設定されるコピー先メディア、BCManager＃setSerialId(byte[])により設定されるシリアルID）をセットし、BCManager＃checkTicket()を呼び出して残コピー回数が１回以上残っていた場合はREADY状態に遷移し、BD-JアプリケーションへはBCReadyEventが通知される。残コピー回数が残っていなかった場合は、READY状態には遷移せず、INITIALIZED状態のままとなる。デジタルコピープロセス実行後、READY，CANCELED，STOPPED，もしくはCOMPLETED状態においてBD-JアプリケーションからBCManager＃initializeBC()が呼ばれると、再びINITIALIZED状態に遷移し、BD-JアプリケーションへはBCInitializedEventが通知される。

　READY：この状態はデジタルコピープロセスに必要なパラメータが全てセットされ、かつそれらが有効であり、デジタルコピーモジュール３５のコピー準備が整ったことを示す。この状態でBCManager＃makeCopy()が呼ばれると、TRANSFERRING状態へ遷移する。

　TRANSFERRING：この状態は携帯端末向け保護コンテンツのデータコピーが開始されたことを示す。携帯端末向け保護コンテンツのデータコピーが完了するとTRANSFERRED状態へ遷移し、BD-JアプリケーションへはBCTransferredEventが通知される。また、データコピー完了前にBCManager＃cancelCopy()が呼ばれると、データコピーはキャンセルされ、CANCELED状態に遷移し、BD-JアプリケーションへはBCCancelEventが通知される。データコピー中にコピー先メディアが取り出される等により、エラーが発生した場合はSTOPPED状態に遷移し、BD-JアプリケーションへはBCStopByErrorEventが通知される。
TRANSFERRED：この状態は携帯端末向け保護コンテンツのデータコピーが完了し、デジタルコピーモジュール３５において復号鍵書込み準備が整ったことを示す。この状態でBCManager＃finalizeBC()が呼ばれると、デジタルコピーモジュール３５はFINALIZING状態へ遷移する。また、この状態でBCManager＃cancelCopy()が呼ばれると、CANCELED状態に遷移し、BD-JアプリケーションへはBCCancelEventが通知される。

　FINALIZING：この状態は、デジタルコピーサーバ３６から復号鍵の取得、及びコピー先メディアへ取得した復号鍵の書込み処理が行われていることを示す。一旦この状態に入ると、BD-JアプリケーションはBCManager＃cancelCopy()を呼んでもキャンセルできず、キャンセル要求は拒否されることになる。復号鍵書込み中にコピー先メディアが取り出される等により、エラーが発生した場合はSTOPPED状態に遷移し、BD-JアプリケーションへはBCStopByErrorEventが通知される。復号鍵の書込みが完了すると、デジタルコピーモジュール３５はCOMPLETED状態へ遷移し、BD-JアプリケーションへはBCCompleteEventが通知される。

　COMPLETED：この状態は、携帯端末向け保護コンテンツのデータコピー及び対応する復号鍵の書込みが完了し、デジタルコピープロセスが成功したことを示す。この状態で、BCManager＃initializeBC()が呼ばれると、再びINITIALIZED状態に遷移し、BD-JアプリケーションへはBCInitializedEventが通知される。
CANCELED：この状態は、携帯端末向け保護コンテンツのデータコピーが途中でキャンセルされたことを示す。途中までコピー済みのデータは、CANCELED状態への遷移時にクリアされる。

　STOPPED：この状態は、エラー発生により、データコピーもしくは復号鍵書込みが失敗したことを示す。エラー発生の原因としては、空き容量不足、コピー先メディアが書き込み保護されているため、書込みできない、コピー先メディアが途中で取り出された、コピー先メディアが破損しておりI/Oエラーが発生した等が考えられる。どの原因でコピーに失敗したかは、STOPPED状態遷移時に発生するBCStopByErrorEventインスタンスに詳細情報が記録されており、BD-JアプリケーションはBCStopByErrorEventを通してエラー原因を把握することができる。以上がデジタルコピー実行の際に、BD-Jアプリケーションとオンメディアライブラリ２８間でやり取りされるAPI呼び出しの内容である。

　各フェーズのAPI呼出しのそれぞれに対応して、モジュールには、デジタルコピーソケットコマンドが送信される。このコマンドを用いれば、図８における端末内ローカル通信は、図１６のシーケンス図のように詳細化される。

　図１６は、端末内ローカル通信の詳細を示すシーケンス図であり、オンメディアライブラリ２８とデジタルコピーモジュール３５間でやり取りを行うデジタルコピーソケットプロトコルの一例を示す。このシーケンスは、デジタルコピーソケットコマンドを用いて記述されている。本図の横方向には、オンメディアライブラリ２８、デジタルコピーモジュール３５が、それぞれ配置されている。縦方向には、複数の時間軸を描いている。時間軸上の各時点が、コマンド及びレスポンスの送受信のタイミングとなる。本図に示したコマンド及びレスポンスは、これらの時間軸間を行き来する。このシーケンスは、ｂ.初期化フェーズ、ｃ.コピー先状態確認フェーズ、ｄ.パラメータセットフェーズ、ｅ.残コピー回数確認フェーズ、ｆ.コピー開始フェーズ、ｇ.コピー進捗確認フェーズ、ｈ.鍵書込みフェーズからなる。

　図１６では、例えば再生装置がSDカードスロットのみをサポートするような構成である場合を例に説明を行う。

　ｂ.初期化フェーズは、REQUEST_INITIALIZEコマンドの送信と、レスポンス(SD_1)の受信というコマンド・レスポンス型通信、GET_ASYNCPORTコマンドの送信と、レスポンスの受信というコマンド・レスポンス型通信から構成される。

　REQUEST_INITIALIZEコマンドは、BD-JアプリケーションからBCManager＃initializeBCが呼び出された際、発行されるソケットコマンドである。デジタルコピーモジュール３５の初期化要求が行われて、デジタルコピーモジュール３５との通信に使うポート番が特定されれば、そのポートに対して、このコマンドが送信される。

　デジタルコピーモジュール３５はオープン中のポートを通じ、REQUEST_INITIALIZEという文字列を受信すると、初期化要求が行われたと判断し、パラメータ（例えば、以前に設定されたデジタルコピーサーバ３６のURL、コピー元のソースロケーション、コピー先メディアの出力デバイス、シリアルID）のクリアと状態遷移通知のための非同期イベント用ポートを新規にオープンした後、初期化が完了したという旨を知らせるため、ソケットコマンドを受け取ったポートを通じて、OKという文字列を送信する。オンメディアライブラリ２８は、ソケットコマンドを送ったポートから、OKという文字列を受け取ると初期化が完了したとみなす。

　GET_ASYNCPORTコマンドは、状態遷移通知のための非同期通知用に開かれたポート番号を取得するためのコマンドであり、デジタルコピーソケットプロトコルは2種類のポートで構成され、１つはデジタルコピーソケットコマンド用（同期コマンド）、もう一つはデジタルコピーモジュール３５の状態遷移通知用（非同期イベント）である。デジタルコピーソケットコマンド用のポートは、オンメディアライブラリ２８からデジタルコピーモジュール３５へコマンドを投げる形でやり取りが行われるが、状態遷移通知用のポートはデジタルコピーモジュール３５からオンメディアライブラリ２８へ一方的にイベントが通知される形となる。BD-JアプリケーションからBCManager＃addBCStateChangeListnerが呼ばれると、オンメディアライブラリ２８は状態遷移通知用ポートのモニタリングを開始し、デジタルコピーモジュール３５から送られている状態遷移通知をオンメディアライブラリ２８APIのイベントに変換し、BD-Jアプリケーションに状態遷移を通知することになる。

　ｃ.コピー先状態確認フェーズは、GET_DEVICELISTコマンドの送信と、レスポンス(SD_1)の受信というコマンド・レスポンス型通信、GET_DEVICEINFO_SDコマンドの送信と、レスポンス(＜total space＞＜free space＞)の受信というコマンド・レスポンス型通信から構成される。

　GET_DEVICELISTコマンドは、デジタルコピーモジュール３５へサポートしているメディアのリストを要求するためのコマンドであり、BD-Jアプリケーションから、BCManager＃getDeviceListが呼ばれ再生装置がコピー先としてサポートしているメディアのリストが要求された際、オンメディアライブラリ２８に対して、本コマンドが送信される。

　GET_DEVICELISTコマンドに対するレスポンスは、サポートしているメディアのリストであり、ソケットコマンド用のポートを通じて返す。サポートしているメディアのリストは、＜メディアの種類＞_＜番号＞という形で返され、複数メディアをサポートしている場合は、それぞれ空白文字で区切られる（例：SD_1＜sp＞USB_1、＜sp＞は空白文字）。図１６では、再生装置が例えばSDカードスロットのみをサポートしている場合にはSD_1が応答として返される例を示している。

　GET_DEVICEINFOコマンドは、その引数にメディアの種類の指定が可能であり、その指定された種類のメディアのトータル容量、空き容量をレスポンスとして変える。BD-JアプリケーションからBCOutputDevice＃getTotalSpaceもしくは BCOutputDevice＃getFreeSpaceが呼ばれ、トータル容量、空き容量の情報提供が要求されると、オンメディアライブラリ２８はGET_DEVICEINFOコマンドをソケットコマンド用ポートを通じてデジタルコピーモジュール３５へ送り、トータル容量、空き容量の情報を受け取る。コマンド名と引数の間には空白文字を設ける。例えば、SD_1（種類：SDカード、番号：１）の情報を要求する場合は、GET_DEVICEINFO＜sp＞SD_1という文字列をソケットコマンド用ポートを通じてデジタルコピーモジュール３５へ送ることになる。

　ｄ.パラメータセットフェーズは、SET_SERVERURLコマンドの送信と、レスポンス(OK)の受信というコマンド・レスポンス型通信、SET_SRCLOCATIONコマンドの送信と、レスポンス(OK)の受信というコマンド・レスポンス型通信、SET_OUTPUTDEVICEコマンドの送信と、レスポンスの受信というコマンド・レスポンス型通信、SET_SERIALIDコマンドの送信と、レスポンスの受信というコマンド・レスポンス型通信から構成される。デジタルコピーに必要なパラメータをセットする場合も同様に、デジタルコピーソケットコマンドを通じてオンメディアライブラリ２８からデジタルコピーモジュール３５へ値が伝わり、デジタルコピーモジュール３５内にパラメータがセットされる。コマンド名と引数は空白文字で区切る。

　ｅ.残コピー回数確認フェーズは、REQUEST_CHECKTICKETコマンドの送信と、OK＜remaining times of copy＞レスポンスの受信というコマンド・レスポンス型通信から構成される。

　REQUEST_CHECKTICKETコマンドは、コピーの残りを問合せるためのコマンドであり、レスポンスとしてその残りコピー回数が通知される。必要なパラメータのセットが完了し、BD-JアプリケーションからBCManager＃checkTicket()が呼ばれると、オンメディアライブラリ２８は、デジタルコピーモジュール３５へREQUEST_CHECKTICKETコマンドを送る。デジタルコピーモジュール３５は、REQUEST_CHECKTICKETコマンドを受け取ると、セットされたパラメータを元に、コンテンツID，シリアルID及びメディアIDを取り出し、デジタルコピーサーバ３６へこれら３つの値を送って残コピー回数を確認する。デジタルコピーサーバ３６から得られた残コピー回数は、REQUEST_CHECKTICKETコマンドの戻り値として、オンメディアライブラリ２８へ渡す。

　ｆ.コピー開始フェーズは、REQUEST_COPYコマンドの送信と、TRANSFERREDレスポンスの受信というコマンド・レスポンス型通信から構成される。

　REQUEST_COPYコマンドは、SD-Videoコンテンツのコピー開始を命じるコマンドであり、BD-JアプリケーションからBCManager＃makeCopy()が呼ばれると、オンメディアライブラリ２８は、デジタルコピーモジュール３５へREQUEST_COPYコマンドを送り、コピー開始を要求する。デジタルコピーモジュール３５は、残コピー回数が１回以上残っていることが確認できれば、データコピーを開始し、REQUEST_COPYコマンドの戻り値としてOKを返す。

　ｇ.コピー進捗確認フェーズは、GET_PROGRESSコマンドの送信と、TRANSFERREDレスポンスの受信というコマンド・レスポンス型通信から構成される。

　GET_PROGRESSコマンドは、トータルのコピーバイト数と残りバイト数を取得するためのコマンドである。データコピー中にBCProgress＃remaining()、もしくはBCProgress＃total()がBD-Jアプリケーションから呼び出されると、オンメディアライブラリ２８はGET_PROGRESSコマンドをデジタルコピーモジュール３５に送り、デジタルコピーモジュール３５から、トータルのコピーバイト数と残りバイト数を得て、BD-Jアプリケーションへその値を返す。データコピーが完了すると、デジタルコピーモジュール３５はTRANSFERREDに遷移し、非同期イベント用のポートを通じて、オンメディアライブラリ２８へTRANSFERREDに遷移したことが通知される。

　ｈ.鍵書込みフェーズは、REQUEST_FINALIZEコマンドの送信と、OKレスポンス、FINALIZINGレスポンス、COMPLETEDレスポンスの受信というコマンド・レスポンス型通信から構成される。

　REQUEST_FINALIZEコマンドは、コンテンツID，シリアルID、メディアID及びMKBを取り出し、デジタルコピーサーバ３６へこれら４つの値を送って復号鍵を得るためのコマンドである。データコピー完了後、BD-JアプリケーションからBCManager＃finalizeBC()が呼ばれると、オンメディアライブラリ２８は、デジタルコピーモジュール３５へREQUEST_FINALIZEコマンドを送る。デジタルコピーモジュール３５は、REQUEST_FINALIZEコマンドを受け取ると、セットされたパラメータを元に、コンテンツID，シリアルID、メディアID及びMKBを取り出し、デジタルコピーサーバ３６へこれら４つの値を送って復号鍵を得る。デジタルコピーモジュール３５は、得られた復号鍵をコピー先メディアであるセキュアなメモリカード１０４の保護領域へ書き込み、書き込み処理が完了すると、非同期イベント用のポートを通じて、オンメディアライブラリ２８へCOMPLETEDに遷移したことを通知する。

　以上がオンメディアライブラリ２８とデジタルコピーモジュール３５間でやり取りされるデジタルコピーソケットプロトコルの内容である。上述したように、オンメディアライブラリ２８とデジタルコピーモジュール３５間でやり取りされるコマンド、イベント通知は全て再生装置内のローカル通信（ポートを用いたソケット通信）で行われる。残コピー回数の確認及び復号鍵の取得に関しては、デジタルコピーモジュール３５とデジタルコピーサーバ３６間でグローバル通信が行われる。

　図１７は、BD-Jアプリケーションによる機能確認から初期化までの処理手順を示すフローチャートである。ステップＳ１では、システムプロパティ“digitalcopy.port”が存在するか否かを判定し、存在する場合、システムプロパティ“digitalcopy.port”に示されるポートを用いてソケット接続を行う(ステップＳ２)。

　システムプロパティ“digitalcopy.port”が存在しない場合、プライベートポート又はフリーポートを用いてソケット接続を行う(ステップＳ３)。その後、BCManager＃getINstanceAPIをコールし(ステップＳ４)、ステップＳ５で、BCManagerがリターンされたか否かを判定する。リターンされた場合、BCManager＃addBCStateChangeListnerAPIをコールし(ステップＳ６)、BCManagerinitializeをコールする(ステップＳ７)。BCInitializedイベントがスローされたかどうかを判定する(ステップＳ８)。ステップＳ５及びステップＳ８がYesであるなら、デジタルコピー可能であると判定する。ステップＳ５、ステップＳ８のどちらかがNoであるならデジタルコピー不可能であると判定する。

　図１８は、コピー先状態確認からパラメータセットまでの処理手順を示す。BCManagergerdeviceListAPIをコールし(ステップＳ３１)、デバイスリストである“A Array of Supported devices”がリターンされるのを待つ(ステップＳ３２)。リターンされれば、サポートデバイスの中に、セキュアなメモリカード１０４が存在するか否かを判定し(ステップＳ３３)、セキュアなメモリカード１０４が存在しない場合、処理を中断する。存在する場合、セキュアなメモリカード１０４のスロットを一覧表示し(ステップＳ３４)、ユーザによるスロットの選択を待つ(ステップＳ３５)。スロットiが選択されれば、ステップＳ３６において、スロットiを引数で指定したBCOutputDevice＃getFreeSpaceAPIをコールし(ステップＳ３６)、ステップＳ３７において、残りサイズのリターン待ちを行う。リターンされれば、ステップＳ３８において、残りサイズが、SD_VIDEOディレクトリの予想サイズよりも大きいかどうかを判定する。小さければステップＳ３５に移行して再度の選択を促す。ステップＳ３８がYesであれば、ステップＳ３９においてシリアルIDの入力を促すGUIを表示し、ステップＳ４０において、シリアルIDの入力待ちを行い、ステップＳ４１においてコピーソース格納ディレクトリの選択を行う。入力されれば、BCManagersetServerURLAPI,BCManagerSourceLocationAPI,BCManagersetOutputDeviceAPI、BCManagersetSerialIDAPIのコールを行い(ステップＳ４２)、これらのAPIコールに対してサクセスが返されるかどうかを判定する。

　図１９は、コピーソース格納ディレクトリの選択手順の詳細を示すサブフローチャートである。BD-ROMのEMOVEディレクトリの配下にある複数のコピーソース格納ディレクトリに対応するストリーム形式を一覧表示し(ステップＳ５１)、何れのストリーム形式を選択するかという操作を、ユーザから受け付ける(ステップＳ５２)。そしてそのような選択がなされれば、選択されたストリーム形式xxに対応するコピーソース格納ディレクトリxxのファイルパスである/mnt/bdrom/EMOVE/DATAxxを特定する(ステップＳ５３)。そうして、特定したファイルパスである/mnt/bdrom/EMOVE/DATAxxを引数としたBCManager SetServerURLのコールを生成する(ステップＳ５４)。

　ファイルパス/mnt/bdrom/EMOVE/DATAxxで指示されたコピーソース格納ディレクトリxxの配下にある、コピー情報格納ディレクトリxxには、そのコピーソース格納ディレクトリxx固有のコンテンツIDxxが存在するので、機器固有機能制御部３３は、このコンテンツIDxxと、シリアルIDと、メディアIDyとをサーバに送信することで、携帯端末向け保護コンテンツのコピーの残りコピー回数の確認を行い、また、この復号鍵の取得にあたっては、このコンテンツIDxxと、シリアルIDと、メディアIDyとの組合せをサーバに送信する。

　以上のフローチャートでは、デジタルコピーにあたって、デジタルコピーの対象を、VGA形式及びワンセグ形式というように様々な形式の携帯端末向け保護コンテンツの何れかの中から任意に選択することができる。このように、形式が異なる様々な携帯端末向け保護コンテンツをリードオンリーメディア１０５に予め記録しておき、デジタルコピーに供することで、トランスコードを行うことなく、任意のストリーム形式の携帯端末向け保護コンテンツを、セキュアなメモリカード１０４にコピーすることができる。

　図２０は、BD-Jアプリケーションによる残りコピー回数の確認から鍵書き込みまでの処理手順を示すフローチャートである。BCManagercheckTicketAPIをコールし(ステップＳ１１)、BCReadyイベントが発行されたか(ステップＳ１２)、レスポンスがなされたか(ステップＳ１３)を判定する。ステップＳ１４では、コピーの残りコピー回数が1つ以上であるか判定し、1以上であるなら、BCManagerMAKEをコールし(ステップＳ１５)、BCProgressがリターンされるのを待つ(ステップＳ１７)。以降、ステップＳ２５において、進捗グラフを表示してから(ステップＳ２５)、ステップＳ１８～ステップＳ２１のループを行う。このループは、BCProgress＃remaingAPIをコールし(ステップＳ１８)、残りバイト数の受信をして(ステップＳ１９)、残りバイト数が0になったかどうかを判定し(ステップＳ２０)、その残りバイト数に応じて、進捗バーを更新する(ステップＳ２１)という処理を、ステップＳ２０がYesと判定されるまで繰り返すものである。

　ステップＳ２２は、BCtransferredEventを受信したかどうかの受信待ちであり、受信されれば、BCManagerfinalizeBCAPIをコールして(ステップＳ２３)、BCCompleteイベントの受信待ちを行う。受信されれば、処理を終了する。

　以上のフローチャートの処理で表示される、表示画面について説明する。図２１は、デジタルコピーの過程で、表示される表示画面の一例を示す図である。

　図２１（ａ）は、セキュアなメモリカード１０４スロットの一覧表示の一例を示す。スロット１～３のそれぞれに対応するボタンから構成される。図２１（ｂ）は、シリアルIDの数値入力及びストリーム形式の選択のための入力画面を示す。図２１（ｃ）は、コピー進捗を表示するためのGUIを示す。図２１（ａ）から（ｃ）までのメニューは、コピー管理BD-Jアプリケーションによって表示されるものであり、本編コンテンツに含まれるビデオストリームの再生を伴うものなので、本編コンテンツに登場するキャラクターや本編コンテンツに関連するグッズを用いて、華やかな画面演出を行うことができる。

　図２２は、デジタルコピーモジュール３５の処理手順を示すフローチャートである。ステップＳ６１において、REQUEST_INITIALIZEの受信待ちを行い(ステップＳ６０)、REQUEST_INITIALIZEを受信すれば(ステップＳ６１)、設定済みのカレントシリアルID、ソースロケーション、カレントサーバURL、出力デバイス、レジューム位置をリセットする。そしてGET_DEVICELISTの受信待ちを行い(ステップＳ６２)、受信すれば、再生装置で有効になっているドライブのステータスをセンスする(ステップＳ６３)。そして、各スロット番号に対応付けて、ドライブの状態を示すデバイスリストを生成してレスポンスとして返す(ステップＳ６４)。ステップＳ６５は、カレントURL、ソースロケーションのファイルパス、出力デバイス、シリアルIDについてのセットパラメータの受信待ちであり、ステップＳ６６では、セットパラメータコマンドのオペランドをカレントサーバURL、ソースロケーション、出力デバイス、シリアルIDとして設定する。ステップＳ６７は、CHECK_COPY_REQUESTの受信待ちであり、ステップＳ６８では、カレントソースロケーションである/mnt/bdrom/EMOVE/DATAxxのEMOV_INFからコンテンツIDxxを取り出す。一方、カレント出力デバイスyに装填されたセキュアなメモリカード１０４からMIDyを取り出し(ステップＳ６９)、コンテンツIDxxと、MIDyと、シリアルIDzとをサーバに設定して、残りコピー回数の検索を要求する(ステップＳ７０)。その後、残りコピー回数の受信待ちとなり(ステップＳ７１)、残りコピー回数を受信すれば、残りコピー回数をレスポンスとして返す(ステップＳ７２)。ステップＳ７３は、COPY_REQUESTの受信待ちであり、COPY_REQUESTを受信すれば、セキュアなメモリカード１０４にSD_VIDEOディレクトリ、MNG_INFOディレクトリ、PRG001ディレクトリを作成し(ステップＳ７４)、DATAxxディレクトリのMGR_DATA、PRG_MGRを読み出してMNG_INFOディレクトリに書き込むよう指示し(ステップＳ７５)、DATAxxディレクトリのPRG001,PGIと、これに関連するストリームファイルとを読み出して、PRG001ディレクトリに書き込む(ステップＳ７６)。

　図２３は、図２２のフローチャートの続きである。ステップＳ７７、ステップＳ７８のループは、COPY_PROGRESSを受信したか(ステップＳ７８)、書き込みが完了したか(ステップＳ７９)の受信待ちを構成する。COPY_PROGRESSを受信すれば、総サイズ／残サイズをレスポンスとして返す(ステップＳ８５)。書き込みが完了すれば、ステップＳ７９でREQUEST_FINALIZEの受信待ちを行い、REQUEST_FINALIZEを受信すれば、カレント出力デバイスyに装填されたセキュアなメモリカード１０４からMKByを読み出し(ステップＳ８０)、コンテンツIDxx,メディアIDy、MKBy、シリアルIDzとをサーバに送信して、タイトルキーの検索を要求する(ステップＳ８１)。ステップＳ８２は、復号鍵の受信待ちであり、復号鍵を受信すれば、ステップＳ８３においてセキュアなメモリカード１０４と相互認証を行った後、ステップＳ８４においてセキュアなメモリカード１０４のプロテクト領域に復号鍵を格納したVIDEO001.KEYを書き込む。

　以上のように本実施形態によれば、対話画面を通じて、シリアルIDの入力やストリーム形式の選択をユーザに行わせ、これに応じて、予めBD-ROMに記録されているストリーム形式固有の携帯端末向け保護コンテンツを、セキュアなメモリカード１０４に書き込むので、早期に希望のストリーム形式の携帯端末向け保護コンテンツをセキュアなメモリカード１０４に記録して、屋外に持ち出すことができる。

　(第５実施形態)
　これまでの実施形態では、組込みラィブラィの内容を明確にしていなかったが、本実施形態では、組込みラィブラィ２５を詳細に説明する。

　組込ライブラリ２５は、Java2Micro＿Edition(J2ME) Personal Basis Profile(PBP 1.0)と、Globally Executable MHP specification(GEM1.0.2)for package media targetsといった基本パッケージと、エクステンションパッケージとから構成される。これらのパッケージのAPIを利用すれば、ネットワーク処理のためのjava.net、GUI処理のためのjava.awt、言語処理のためのjava.lang、記録媒体に対するI/O処理のためのjava.io、ユーティリティであるjava.util、メディアフレームワークのためのjavax.mediaといったクラスのメソッド、コンストラクタ、インターフェイス、イベントを用いた構造化プログラミングで、BD-Jアプリケーションを記述することができる。

　エクステンションパッケージ(BD-Jエクステンションと呼ばれる)は以下のライブラリから構成される。

　複数のデジタルストリームを用いたマルチアングル再生、複数のビデオストリームを用いたピクチャインピクチャ再生、複数のオーディオストリームを用いたオーディオミキシング再生、複数のグラフィクスストリームを用いたメニュー再生や字幕再生等、Java(TM) Media FrameWorkにはない、マルチパス型のプレイリスト情報を用いた独特の機能を実現するための「org.bluray.media」、
　・デジタル放送サービスのホームプラットフォームで実現されている、"サービス"に基づくアプリケーションシグナリングを、"タイトル"にマップして動作させるための「org.bluray.ti」、アプリケーションの生存区間を管理するための「org.bluray.application」、
　・キーイベントのための定数を定義し、映像再生との同期を実現するための「org.bluray.ui」、
　・BD-ROMに記録されていないLocal Storage上のコンテンツ(off-discコンテンツ)を、BD-ROMに記録されたコンテンツ(on-discコンテンツ)にマウントさせるための「org.bluray.vfs」
　これらのライブラリは、java.net、java.awt、java.lang、java.io、java.util、javax.mediaクラスのメソッドからのインへリッドメソッドを含み、これらのクラスのインターフェイスをエンベデッドインターフェイス、スーパーインターフェイスとして、BD-ROM再生のための再生制御を規定する。このBD-JエクステンションのAPIを用いれば、java.net、java.awt、java.lang、java.io、java.util、javax.mediaクラスを用いたプログラミング技法の延長線上で、BD-Jタイトルを作成することができる。

　BD-Jエクステンションによって定義される機能的な構成要素を、模式的に描いたのが、図２４である。図２４は、図４に示したプラットフォーム部２０における組込ライブラリ２５のより具体的な構成を示す図である。本図に示すように、プラットフォーム部２０における組込ライブラリ２５のBD-Jエクステンションは、マージ管理モジュール４１、メディア再生モジュール４２、ファイルI/Oモジュール４３、ネットワークモジュール４４から構成される。なお、本図における再生制御部１０、機器固有機能制御部３３は、図４に示したものと同一であり、説明のために便宜的に記載している。

　マージ管理モジュール４１は、BD-ROMと、ローカルストレージとを1つの仮想ファイルシステムとして統合する。仮想ファイルシステムは、ローカルストレージの個々の記録媒体におけるファイルシステム上のファイルに対して、別名アクセスのためのファイルパスを割り当て、別名アクセス用のファイルパスをロケータとして用いたファイルアクセスを、アプリケーションに実行させる。ここで、ローカルストレージファイルに対する別名アクセス用のファイルパスの割り当ては、マウント規則ファイルを引数で指定した上で、アプリケーションが仮想パッケージのクリエイトAPIをコールして、仮想パッケージを仮想ファイルシステムに生成させることでなされる。

　かかるコールによって作成される仮想パッケージとは、BD-ROM上のファイル以外の別のファイルが追加されたファイル構成、BD-ROM上のファイルの何れかが別のファイルに置き換えられたファイル構成を示す。そして、この仮想パッケージの実体は、上記ファイル追加後のファイル構成、及び／又は、上記ファイル置換後のファイル構成を示すファイル管理情報であり、BD-ROMからメモリに読み出されたファイル管理情報に新たなファイルエントリーを追加するか、又は、メモリに読み出されたファイル管理情報における一部のファイルエントリーを別のものに置き換えることで得られる。

　ここでマウント規則ファイルとは、ローカルストレージにおけるファイルパスと、別名アクセスのためのファイルパスとの対応付けをマークアップ言語のタグで記述したものである。そして、ローカルストレージ上のファイルに与えられる別名アクセス用のファイルパスは、BD-ROMにおけるBDMVディレクトリと、CLIPINFディレクトリ、PLAYLISTディレクトリ、STREAMディレクトリの何れかとを組合せたものである。

　アプリケーションのAPIコールによって、仮想パッケージが作成されれば、仮想パッケージ上のファイルをBD-ROMに対するロケータによって指定することができ、ローカルストレージ上のファイルは、あたかも、BD-ROMに記録されているかの如く扱うことができる。

　メディア再生モジュール４２はバイトコードアプリケーションに対し、メディア再生制御のためのAPIを提供している。バイトコードアプリケーションがメディア再生制御APIを呼び出すと、メディア再生モジュールは対応するAV再生ライブラリ関数を呼び出し、AV再生制御を行う。

　ファイルI/Oモジュール４３は、バイトコードアプリケーションからのBD-ROM、ローカルストレージ、記録型BDドライブ等の各メディアへのファイルアクセス要求の処理を行う。ネットワークI/Oモジュール４４は、バイトコードアプリケーションに対し、ネットワーク制御のためのAPIを提供している。バイトコードアプリケーションからのネットワーク制御要求に従い、ネットワークI/Oモジュール４４を使って、ネットワーク接続を行う。

　ネットワークI/Oモジュール４４は、インターネットにおけるサーバとの接続を実現する。TCP/IP及びUDP/IPのうち、どちらかのプロトコルスタックがサポートされ、HTTPプロトコルを使用できることはネットワークI/Oモジュールの要件となる。物理的な接続は、Ethernet（登録商標）,電話のそれぞれで違ってもよい。プラットフォームは、ネットワーク接続を利用する前に、認証されねばならず、またネットワーク接続のための適切なPermissionを得なければならない。以上が、組込ライブラリ２５におけるBD-Jエクステンションについて説明である。つづいて、この組込ライブラリ２５のBD-Jエクステンションを前提にした、オンメディアライブラリ２８の特徴について説明する。

　本実施形態におけるオンメディアライブラリ２８は、プロトコル解析専用の“デジタルコピーライブラリ”であり、バイトコードアプリケーションに対し、あたかも再生制御APIであるBD-JAPIを拡張したかのようなAPI（デジタルコピーライブラリAPI）を提供する。デジタルコピーモジュール３５とのデータ送受信に用いるプロトコルは、個々のバイトコードアプリケーションに依存したものではなく、その詳細がデジタルコピーライブラリ内に隠蔽されたものになり、複数のバイトコードアプリケーションについて共通のプロトコルとして定義されている。このように構成することで、バイトコードアプリケーションはデジタルコピーモジュール３５とのデータ送受信に用いるプロトコルを解析する必要がなくなり、プロトコル解析をライブラリで一元管理することが可能となるため、バイトコードアプリケーションの生産性を向上させることができる。オンメディアライブラリ２８は、アーカイブファイルによって定義されるが、デジタルコピーライブラリにおけるパーミッションリクエストファイルは、バイトコードアプリケーションと、ローカルホストとの間のソケット通信を許可している。

　以上が組込ライブラリ２５についての説明である。続いて、仮想ファイルシステムの作成に利用されるローカルストレージの詳細について説明する。かかるローカルストレージには、セキュアなメモリカード１０４を使用することができる。

　図２５は、ローカルストレージとして使用されたセキュアなメモリカード１０４におけるディレクトリ構成を示す図である。ローカルストレージには大きく3種類の領域が存在し、１つはユーザから自由に読み書きできユーザにとって可視である領域「ユーザ領域」、もう一つはユーザからは読み書き不可能で、ユーザにとって不可視であり、著作権保護に対応したシステムのみ読み書きが許される保護された領域「保護領域」、最後に、ユーザからは読み書き不可能、システムからも書き込み不可能で、システムによる読み込みのみが許される領域「システム領域」である。ユーザ領域は、さらに追加コンテンツ領域とSDビデオ領域の２種類に分けられる。追加コンテンツ領域はBD-ROM再生時に補助的用いられるコンテンツが格納され、SDビデオ領域には主に携帯端末での再生を目的としたSDビデオ準拠のコンテンツ（ステップＳDビデオコンテンツ）が格納される。追加コンテンツ領域とSDビデオ領域は共にローカルストレージのユーザ領域上のルートディレクトリ直下に存在する。追加コンテンツ領域を示すディレクトリ名配布媒体文字以内の固定値（BUDA）である。このBUDAディレクトリ以下（サブディレクトリとそれ以下のファイルも含む）に、アプリケーションはサーバからダウンロードしてきた追加ファイル等、任意のファイルを格納することが可能である。

　BUDAディレクトリ以下にはさらにOrganizationIDディレクトリとDiscIDディレクトリが存在し、特定のプロバイダ（Organization）に対応するディレクトリに、各BD-ROMに対応するディレクトリを設けることにより、各BD-ROMについてのダウンロードデータが個別に格納される。

　一方SDビデオ領域を示すディレクトリ名はSD_VIDEOであり、追加コンテンツ領域と同様、ユーザ領域上のルートディレクトリ直下に存在する。SD_VIDEOディレクトリ以下にはさらにSDビデオコンテンツ毎に分かれたSDビデオコンテンツディレクトリ（「PRGxxx」、“xxx”は可変）とSDビデオ領域全体の管理ファイルが格納されたSDビデオ管理ディレクトリ（「MGR_INFO」）が存在する。SDビデオコンテンツディレクトリには、上述のPRG001.PGI及びMOV001.SD1が記録され、SDビデオ管理ディレクトリには、上述のMGR_DATA及びPRG_MGRが記録される。

　ユーザからはアクセスできない保護領域上には、暗号化された携帯端末向け保護コンテンツを復号するための復号鍵（VIDEO001.KEY）が記録される。復号鍵へのアクセスは著作権保護に対応したシステムのみが可能である。

　ユーザからはアクセスできず、システムからも読み込みのみ許されるシステム領域には、前述の復号鍵生成に必要な鍵情報が記録されたメディアキーブロック（MKB）と、ローカルストレージに割り当てられているSDメモリーカード等の媒体を、媒体毎に一意に特定するための識別子であるメディアID（MID）が記録されている。メディアIDは同じ種類のメディアでも媒体毎に異なる値が割り振られている。

　セキュアなメモリカード１０４のうち、ローカルストレージとして使用されているものは、デバイスリストにおける表記が、BDJstorage=＜devicename＞というものになる。これは、ローカルストレージとして利用されているセキュアなメモリカード１０４と、そうでないセキュアなメモリカード１０４とを区別するためである。即ち、ローカルストレージとして利用されているセキュアなメモリカード１０４は、BD-ROMとの組合せで仮想ファイルシステムを形成していることが多い。かかるセキュアなメモリカード１０４に対してコンテンツが書き込れて、セキュアなメモリカード１０４がイジェクトされると、構築された仮想ファイルシステムが、破壊されることになり望ましくない。

　そこで、デジタルコピーモジュール３５は、コピー先状態確認フェーズにおいて、各デバイスの状態確認が求められた際、デバイスリストとして、ローカルストレージとして利用されているセキュアなメモリカード１０４であるか否かという種別を、レスポンスとして返す。こうすることで、コピー管理を行うデジタルコピー管理BD-Jアプリは、セキュアなメモリカード１０４がローカルストレージとして使用されている場合、仮想ファイルシステムの構築中はセキュアなメモリカード１０４をイジェクトしないよう、具体的にいうと、仮想ファイルシステムにより構築された仮想パッケージ中のタイトルの再生中は、セキュアなメモリカード１０４をイジェクトしないよう警告表示を行うことができる。

　以上のように本実施形態によれば、仮想ファイルシステムが破壊されないような配慮を払いつつも、ローカルストレージとして利用されているセキュアなメモリカード１０４を、携帯端末向け保護コンテンツのコピー先として選ぶことができるので、記録媒体の利用効率が高まる。　

　（第６実施形態）
　これまでの実施形態では、規定のAPIにとらわれない様々な機能を呼び出すことを可能にする構成について述べたが、ディスク上のアプリケーションが制御できる範囲が拡大するとセキュリティの懸念が生まれてくる。第６実施形態では、よりセキュリティを強化した実施の形態の変形例について説明する。第６実施形態では前述の第１実施形態と同様の部分は省略し、これまでの実施形態との変更点のみを記載している点には注意されたい。記載していない部分はこれまでの実施形態と同様と捉えてよい。

　図２６は従来におけるアプリケーションの署名検証を示す図である。バイトコードアプリケーションが正当かどうかの検証は、バイトコードアプリケーションを構成するアーカイブファイル内に記録されたデジタル署名とディスク上のルート証明書(discroot.crt)を元に署名検証を行うことで成される。具体的にはアーカイブファイル内のデジタル署名をルート証明書を元に復号して得られるハッシュ値と、アーカイブファイルを構成する個々のクラスファイルのハッシュ値が一致しているかどうかを確認し、一致していればアーカイブファイルは正当であり、一致していなければ何らかの不正があったとみなされる。しかしながら、この検証方法では、ルート証明書とアーカイブファイル内のデジタル署名の両方が対になっていれば、検証にパスするので、正当なルート証明書を保有するコンテンツ提供者が不正にアーカイブファイルを作成した場合は、それを検知する術はなく、第１実施形態で述べたように、再生装置の固有機能を開放してしまうと、正当なルート証明書を保有する全てのコンテンツ提供者は自由に再生装置の固有機能を利用できてしまうことになる。

　図２７は、再生装置が保有するデジタル証明書をベースとした署名検証を示す図である。バイトコードアプリケーションを構成するJarファイル内にディスク上のルート証明書をベースとしたデジタル署名に加え、再生装置固有のデジタル証明書をベースとしたデジタル署名も付与する。具体的にはJarファイル内に格納された個々のクラスファイルのハッシュ値がリスト化されたマニフェストファイル（MANIFIEST.MF）のハッシュ値を、再生装置固有のデジタル証明書に対応した秘密鍵で暗号化した値を再生装置固有のデジタル署名としてJarファイル内に記録する。再生装置側では、従来のルート証明書をベースとした署名検証に加え、再生装置固有の証明書をベースとした署名検証も実施する。

　図２８は、署名検証の結果に応じた機能制限を示す図である。再生装置固有の機能をバイトコードアプリケーションから呼び出すためには、従来のルート証明書をベースとしたデジタル署名だけでは不十分であり、加えて再生装置固有のデジタル署名を用意しなければならない。再生装置固有のデジタル署名は、再生装置固有の証明書に対応した秘密鍵がなければ作成できないため、第三者が不正に再生装置固有のデジタル署名を用意して、再生装置固有の機能を悪用するということを防ぐことができる。しかも、たとえ再生装置固有のデジタル署名検証に失敗したとしても、従来の共通機能の呼び出しに関しては何ら影響を与えることはないので、共通機能部分に関しては互換性を保つことができる。

　図２９は、装置固有機能を利用するため接続要求時における処理のフローチャートである。本フローチャートは第１実施形態におけるステップＳ１０３に対応しており、セキュリティ面で強化されている点が異なる。まず、デジタルコピーモジュール３５は接続要求を行っているバイトコードアプリケーションに装置固有のデジタル署名が付与されているかどうかを判断する（ステップＳ２０１）。装置固有のデジタル署名が付与されていなければ、接続要求を拒否し、以降の通信ポートを介した要求には再生装置は何も応じない、もしくはポートを閉じて一切の通信を拒否してもよい。ステップＳ２０１で装置固有のデジタル署名が付与されていると判断できた場合、再生装置は各クラスファイルのハッシュ値の取得を行う（ステップＳ２０２）。各クラスファイルのハッシュ値はJarファイルのマニフェストファイルに記載されているため、それらのハッシュ値がリスト化されているマニフェストファイルのハッシュ値を計算するだけでも良い。次に再生装置が持つ固有のデジタル証明書を用いて、バイトコードアプリケーションに付与された装置固有のデジタル署名を復号し、デジタル署名に記されたハッシュ値を導き出す（ステップＳ２０３）。そして、ステップＳ２０２とステップＳ２０３で取得されたハッシュ値が一致していれば、デジタル署名は正しく付与されていると判断し、一致していなければ、不正なデジタル署名であると判断する（ステップＳ２０４）。不正なデジタル署名と判断した場合、ステップＳ２０１でデジタル署名が付与されていなかった場合と同様、以降は通信ポートを介した再生装置固有の機能呼び出しには全く応じないことになる。デジタル署名が正しいと判断すると、暗号化通信路の生成を行う（ステップＳ２０５）。具体的には、再生装置が持つデジタル証明書をバイトコードアプリケーション側に送り、バイトコードアプリケーションは送られてきたデジタル証明書で暗号化通信ソケット（SSLソケット）を作成する。通常のソケット（例えばソケットコマンドおよびその応答）は暗号化されず非暗号でデータがやりとりされるが、SSLソケットは送られてきたデジタル証明書で暗号化してデータをやりとりすることになる。すなわち、通信ポートを介した再生装置とバイトコードアプリケーション間の相互にやりとりするデータは通信路上は全て暗号化されることになる。

　以上、再生装置側はバイトコードアプリケーションに付与されたデジタル署名を、バイトコードアプリケーション側は再生装置から送られてくるサーバ証明書を検証し、かつ、通信ポートを介したデータのやりとりはSSLによる暗号化が施されるため、不正なバイトコードアプリケーション、不正な再生装置を排除し、かつ通信路上のデータを不正取得・利用とするハッカーからの攻撃を防ぐことができる。

　（第７実施形態）
　これまでの実施形態では、再生装置固有の機能としてデジタルコピーを例に、規定のAPIにとらわれない様々な機能をセキュリティを確保しつつ呼び出すことを可能にする構成について述べたが、本実施形態は、このデジタルコピーについて、より使い勝手を向上させた実施の形態の変形例である。第７実施形態では、これまでの実施形態と同様の部分は省略し、変更点のみを記載している点に注意されたい。記載していない部分はこれまでの実施形態と同様と捉えてよい。

　図３０は再生装置にて途中までコンテンツを視聴し、途中から携帯端末で視聴する一例を示す図である。自宅等で据え置きの再生装置とテレビで視聴して楽しんでいたコンテンツを、外出時にも楽しみたいというケースを想定した場合、携帯端末で再生したときに、また最初から再生が開始するのではなく、続きから再生が開始されるのが望ましい。この場合、デジタルコピー実施時にコンテンツをコピーするだけでなく、再生位置情報も加えてコピーする必要がある。SDメモリーカード上に記録されるSDビデオフォーマットでは、SDビデオ管理ファイル“MGR_DATA”にレジューム位置を示す再生位置情報を記録することができるため、据え置きの再生装置で途中まで再生していた再生時刻をデジタルコピー時にSDビデオ管理ファイルに記録することで、本ユースケースを実現することができる。

　図３１は、第７実施形態におけるデータコピーのフローチャートである。携帯端末向け保護コンテンツを指定されたコピー先メディアにコピーを行う際、再生位置情報の記録についての指定があるかどうかを判断する（ステップＳ３０１）。再生位置情報の記録指定はバイトコードアプリケーションからデジタルコピーソケットコマンド用通信ポートを介してデジタルコピーモジュール３５に通知することで成される。

　図３０では、バイトコードアプリケーションによる再生位置情報のコピーをユーザに問い合わせたが、常に再生位置情報の記録を指定してもよい。いずれにしても、デジタルコピーモジュール３５はデータコピー時に事前にバイトコードアプリケーションから再生位置情報の記録指定があるかどうかを判断し、再生位置情報の記録指定がなければ、SDビデオ管理ファイルに手を加えずに、そのままデータコピーを行う。ステップＳ３０１において再生位置情報の記録指定が行われていると判断した場合、バイトコードアプリケーションから記録する再生時刻の指定があるかどうかを判断する（ステップＳ３０２）。例えば、再生装置にてすでに３０分視聴していた場合は、引き渡されるべき値は1,800,000(msec)になる。再生時刻の指定があり、かつその値が有効であれば、SDビデオ管理ファイルに、指定された時刻を書き込む（ステップＳ３０３）。ステップＳ３０１において再生位置情報の記録指定を受け取っていると判断したが、ステップＳ３０２において時刻の指定がされていないと判断した場合、プレーヤレジスタに再生時刻が記録されているかどうかを判断する（ステップＳ３０４）。再生装置は複数のレジスタを持っており、その内の一つがレジューム再生用に割り当てられているため、レジューム再生に割り当てられているレジスタの値を確認する。レジューム再生用のレジスタに有効な再生時刻が記録されていれば、その値をSDビデオ管理ファイルに書き込む（ステップＳ３０５）。もし、再生位置情報の記録指定を受け取っているにもかかわらず、バイトコードアプリケーションから有効な時刻指定がなく、かつレジスタにも有効な再生時刻が記録されていなかった場合は、SDビデオ管理ファイルには何も手を加えずに、そのままデータコピーを行うことになる（ステップＳ３０６）。以上の構成により、単なるデータコピーだけでなく、再生位置情報も加えてコピーすることが可能となり、デジタルコピー後に携帯端末で再生させたときに据え置きの再生装置で途中まで再生していた地点から続き視聴ができるため、デジタルコピーの使い勝手をより向上させることができる。

　（第８実施形態）
　これまでの実施形態では、コピー元とコピー先の記録媒体が異なるケースについてデジタルコピーを実施するための構成について述べたが、本実施形態では、コピー元とコピー先の記録媒体が同一の場合における実施の形態について説明する。

　本実施形態ではこれまでの実施形態と同様の部分は省略し、これまでの実施形態との変更点のみを記載している点に注意されたい。記載していない部分はこれまでの実施形態と同様と捉えてよい。

　図３２はコピー元とコピー先が同一記録媒体におけるデジタルコピーを示す図である。コピー元とコピー先が同一になるケースの一つとして、対象となる携帯端末向け保護コンテンツがBD-ROM上に存在せず、バイトコードアプリケーションが外部ネットワークを経由してサーバから携帯端末向け保護コンテンツをダウンロードすることが考えられる。しかしながら、図６で示したように、追加コンテンツ領域とビデオコンテンツ領域は分けられているため、バイトコードアプリケーションは直接ビデオコンテンツ領域にダウンロードすることはできない。バイトコードアプリケーションが自由にアクセスできる領域はアプリケーションが属するOrganizationと同一のOrganizationディレクトリ以下のみとなる。このようにアクセス範囲が決められているのは別のOrganizationのコンテンツを勝手に抜き取ったり削除したりすることを防ぐためである。したがって、バイトコードアプリケーションは追加で携帯端末向け保護コンテンツをダウンロードする場合、まずはOrganizationディレクトリ以下に一旦格納する。そして、Organizationディレクトリに格納されたデジタルコピーコンテンツを、端末内ローカル通信を介して端末固有機能を呼び出し、ビデオコンテンツ領域に移動させるという手順となる。

　図３３はコピー元とコピー先が同一記録媒体におけるデジタルコピーに対応したフローチャートである。

　コピー元とコピー先が同一記録媒体となるデジタルコピーにおいては、ステップＳ１０１で行っていた、挿入されているディスク上に携帯端末向け保護コンテンツが存在するかどうかを確認するステップは不要となる。

　なぜならば、ディスク上に携帯端末向け保護コンテンツが存在しなくても対象となる携帯端末向け保護コンテンツがローカルストレージ上に記録されている可能性があるためである。本実施の形態においてポート開放時間を極小化する場合は、携帯端末向け保護コンテンツが存在するかどうかではなく、第１実施形態でも述べたようにバイトコードアプリケーション動作中のみ（すなわち、BD-Jタイトル再生中のみ）ポートを開放する、もしくはバイトコードアプリケーションからポート開放の命令を受け取ってから開放する等の処理を行うことになる。ステップＳ１０４においてバイトコードアプリケーションとの接続に成功した場合、デジタルコピーモジュール３５は次にバイトコードアプリケーションからコピー対象となる携帯端末向け保護コンテンツの格納位置が指定されるのを待つ（ステップＳ４０１）。

　コピー対象となる携帯端末向け保護コンテンツの格納位置は、メディアの種類を含んだ絶対パスとなる。例えばBD-ROM上であれば、指定される絶対パスは"/mnt/bdrom/EMOVE/DATA01"等になり、ローカルストレージ（セキュアなメモリカード１０４等）上であれば“/mnt/sdcard/BUDA/081A24ED/12345ABC/EMOVE/DATA01”等になる。この場合、"/mnt/bdrom"はBD-ROMメディアのマウントポイントに当たり、"/mnt/sdcard"はセキュアなメモリカード１０４のマウントポイントに当たる。すなわち、バイトコードアプリケーションより指定されるファイルパス情報の中にメディアのマウントポイントを含めることで、デジタルコピーモジュール３５はコピー対象の携帯端末向け保護コンテンツがどのメディア上にあるのか判断することができる。ステップＳ４０１で取得したコピー対象の位置情報、及びその位置情報から判断できるメディアの種類は、ステップＳ１０７において選択されたメディアの種類との比較に用いる（ステップＳ４０２）。

　ステップＳ４０１で指定されたメディア（すなわちコピー元のメディア）とステップＳ１０７で指定されたメディア（すなわちコピー先のメディア）が同一でなければ、ステップＳ１０８で残コピー回数及び空き容量の確認を行い、同一の場合は空き容量の確認をスキップして残コピー回数の確認のみ行う（ステップＳ４０３）。デジタルコピーモジュール３５はステップＳ４０３で残コピー回数が残っていると判断した場合、ステップＳ４０１で指定されたコピー対象を、同一メディア内のビデオ領域にムーブする（ステップＳ４０４）。同一メディア内のムーブの場合、実際のデータコピーは不要であり、ファイルの管理情報書き換えだけで済むため、短時間で処理が終わる。そのため、バイトコードアプリケーションによるユーザへの進捗表示はスキップしてもよい。

　以上の構成によれば、BD-ROM上に予め携帯端末向け保護コンテンツが記録されていなくとも、追加で携帯端末向け保護コンテンツをダウンロードし、かつデジタルコピー処理プロセスの中でコンテンツのムーブを行うことで、デジタルコピーを実施することが可能となる。また、ダウンロードした先とデジタルコピーのコピー先が同一メディアの場合は、不必要に容量を消費せず、かつコピー自体を高速に行うことができる。

　（第９実施形態）
　本実施形態では、これまでの実施形態に示した記録媒体の作り方、つまり、記録方法の形態について説明する。

　本実施形態に係る記録方法は、ストリームファイルであるAVファイル、ストリームファイル以外のファイルである非AVファイルをリアルタイムに作成して、記録媒体におけるAVデータ記録領域、非AVデータ記録領域にダイレクトに書き込むというリアルタイムレコーディングとして実現することができる。それだけではなく、ボリューム領域に記録すべきビットストリームの全体像を事前に作成して、このビットストリームを元に原盤ディスクを作成し、この原盤ディスクをプレスすることで、光ディスクを量産するというプレフォーマットレコーディングも含む。本実施形態に係る記録媒体は、リアルタイムレコーディングによる記録方法、及び、プレフォーマットレコーディングによる記録方法によっても特定されるものでもある。ここで、プレフォーマットレコーディングによる記録方法は、BD-ROMオーサリング(1)、著作権保護(2)、プレス(3)、プレスで得られたBD-ROMのパッケージング(4)という過程で構成される。

　この過程において、BD-ROMオーサリング(1)の完了後、著作権保護(2)の実行前に、デジタルコピー対応メニューの制作(1-1)という行程が存在する点が、従来の記録方法と異なる。

　デジタルコピー対応メニューの制作行程が存在するのは、BD-ROMの全体メニュー、又は、タイトルメニューから、デジタルコピーのための対話制御メニューを表示させるためである。更にBD-ROMオーサリング(1)から著作権保護(2)までの過程に並行して、携帯端末向け保護コンテンツを構成するデジタルストリームを生成するためのエンコードと、当該エンコードで得られたデジタルストリームを暗号化するための著作権保行程とが存在する。

　そして、パッケージングの際封入されるシリアルID、又は、ディスクのプレス行程で、ディスクに書き込まれるシリアルIDの何れかをサーバに登録する行程が存在する。

　＜備考＞
　以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の主観によることは留意されたい。

　＜機器固有機能のバリエーション＞
　本実施の形態では、再生装置固有の機能としてデジタルコピーを例に述べたが、録画機能や配信サービスと記録媒体上のアプリケーションとの連携も考えられる。すなわち、本発明は再生装置固有の機能としてデジタルコピーに限定されるものではない。例えば、記録媒体上のアプリケーションから録画予約を行う、もしくは配信サービスと連携してダウンロードを行うといったサービスにも応用可能である。

　＜再生装置のバリエーション＞
　上記実施形態では、記録媒体を再生する再生機能のみを持つ再生装置について説明したが、それに限らない。例えば、録画機能を持つ録画再生装置であっても良い。

　＜プログラミング言語のバリエーション＞
　上記実施形態では、アプリケーションのプログラミング言語としてJava(TM)（登録商標）を利用したが、Java(TM)（登録商標）ではなく、UNIX（登録商標）　OSなどで使われているB-Shellや、Perl　Script、ECMA　Scriptなど他のプログラミング言語であっても良い。

　＜記録媒体のバリエーション＞
　また、上述の実施の形態ではBD-ROMを再生する再生装置について説明をしたが、書き込み可能な光記録媒体に上述の実施の形態にて説明をしたBD-ROM上の必要なデータが記録されていた場合においても上述と同様の効果を奏することはもちろんのことである。

　また、上述の形態ではコピー元の記録媒体として、BD-ROMまたは書き込み可能な光記録媒体を例に説明をしているが、これに限定をされる必要は無く、例えばSDメモリーカード、メモリースティック、コンパクトフラッシュ、スマートメディア、マルチメディアカード等の可搬性の記録媒体に相当するリムーバブルメディアを用いても構わない。

　コピー元の記録媒体としてリムーバブルメディアを用いる場合、このコピー元に用いるリムーバブルメディアには、例えば図１１に示すボリューム領域に記録されているディレクトリ構造を有するデータに相当するものを記録する領域（ユーザ領域）、図２５で説明をした保護領域およびシステム領域を有する構造である。

　この場合ではコピー元のリムーバブルメディアに記録された携帯端末向けコンテンツがコピー先のリムーバブルメディアへコピーされることになる。当然のことながら、コピー元のリムーバブルメディアとコピー先のリムーバブルメディアとは別である。

　コピー元の記録媒体にBD-ROMを用いた場合では、上述の実施の形態の説明において、例えば鍵情報生成部６０２では、コピー元からはBD-ROM上の特殊領域であるBCA（Burst　Cutting　Area）に記録されている記録媒体の物理的なシリアルIDを示すPMSN（Pre-recorded　Media　Serial　Number）を、読み出す構成である。これに対し、コピー元の記録媒体にリムーバブルメディアを用いる場合には、PMSNを読み出す代りに、コピー元のリムーバブルメディア固有の情報（メディアID）を読み出す構成とすればよい。

　このように上述の実施の形態の説明および図面において、コピー元の記録媒体であるBD-ROMをリムーバブルメディアと読み替えるとともに、コピー元の記録媒体であるBD-ROMのシリアルIDをリムーバブルメディアの固有の情報（メディアID）と読み替えれば、コピー元の記録媒体にリムーバブルメディアを用いたときの動作の説明となる。

　また、コピー元の記録媒体としてリムーバブルメディア用いた場合、BD-ROMのボリューム領域に記録されているディレクトリ構造を有するデータに相当するものを記録する領域（ユーザ領域）に記録されるデータのうちの一部のデータ（例えばストリームデータ）は、暗号化なされている。

　コピー元の記録媒体としてリムーバブルメディア用いた場合、（ユーザ領域）に記録されるデータというのはリムーバブルメディアを頒布時に予め記録されていても良い。この場合、リムーバブルメディアの頒布時において、ユーザ領域に記録されるデータの一部のデータが暗号化されている場合には、暗号化されたデータを復号するためのキー情報（タイトルキー）を含む復号鍵がコピー元の記録媒体の保護領域に予め記録されている。このとき、復号鍵は、コピー元の記録媒体のシステム領域のMKBを用いて復号ができるように暗号化がなされているものとする。

　または、コピー元の記録媒体としてリムーバブルメディア用いた場合、このリムーバブルメディアの頒布時にはユーザ領域にデータが記録されていないものの、頒布後、ダウンロード等の要求により、ユーザ領域に、BD-ROMのボリューム領域に記録されているディレクトリ構造を有するデータに相当ものを記録するようにしても良い。ダウンロード要求を行う装置というのは本実施の形態で説明をした再生装置を用いて行っても良いし、本実施の形態とは別のダウンロードを行うための端末装置を用いて行っても良い。この場合にはまず、ダウンロード要求を行う装置に頒布されたリムーバブルメディアを装填し電気的に接続をされた状態で、データのダウンロードの要求とともに、リムーバブルメディアのメディアIDおよびMKBを読み出して配信サーバへ送る。配信サーバにおいて、リムーバブルメディアのメディアIDおよびMKBを用いて生成される復号鍵と対応するデータをダウンロードの要求を行った装置へ送る。ダウンロードの要求を行った装置では、受信した対応するデータをリムーバブルメディアのユーザ領域へ記録し、受信した公開鍵ファイルをリムーバブルメディアの保護領域に記録する。ユーザ領域に記録されるデータの一部のデータが暗号化されている場合には、暗号化されたデータを復号するためのキー情報（タイトルキー）を含む復号鍵がコピー元の記録媒体の保護領域に記録されることになる。このとき、復号鍵は、コピー元の記録媒体のシステム領域のMKBを用いて復号ができるに暗号化がなされているものとする。

　以上のように構成をすれば、リムーバブルメディアをコピー元の記録媒体とすることができる。

　このようにすれば、ユーザ領域に記録される携帯端末向けコンテンツのみを本実施の形態とは異なる手法で別のリムーバブルメディアへ記録したとしても、別のリムーバブルメディアには復号鍵に関する情報が無いため、不正なコピーによる再生を抑止することができる。

　万が一にも、別のリムーバブルメディアに復号鍵をも記録できたとしても、別のリムーバブルメディアのMKBはコピー元のリムーバブルメディアのMKBと異なるため、暗号化された復号鍵の復号が行えないため、コピー元のリムーバブルメディアのユーザ領域に記録されたデータの不正な利用を抑止することができる。

　＜コピー中の警告＞
　コピー中はI/O処理がデジタルコピー実行部６０４に占有されるため、BD-ROM上のコンテンツを正常に再生することができなく恐れがある。そのため、しばらくの間は、再生ができないということ、ディスクを取り出してはいけないということ、及び電源を落としてはいけないということを事前にユーザに通知しておくことが望ましい。とは言え、ユーザが誤ってディスクを取り出したり、電源を落としたりすることは大いに有り得る。しかしながら、復号鍵書込の処理は、この時点では完了しておらず、残コピー回数は減っていないため、ここでデータコピーに失敗しても残コピー回数が減るということはない。デジタルコピーサーバ３６側で管理している残コピー回数は、次のステップで復号鍵をデジタルコピーサーバ３６からダウンロードした時点で減ることになる。

　＜携帯端末向け保護コンテンツが存在するかどうかの判断＞
　"EMOVE"ディレクトリの有無で判断するのではなく、他に携帯端末向け保護コンテンツの存在を示すファイルを予め決めておき、そのファイルの有無でディスク上に携帯端末向け保護コンテンツが存在するかどうかを判断してもよい。

　＜メディアの一覧表示＞
　メディアの一覧表示時において、空き容量が不足している、もしくはメディアが未挿入であると予め判断できたメディアには、空き容量が不足している、もしくはメディアが未挿入であるというマーク（もしくはフラグ）をつけてもよい。

　＜デジタルコピーサーバ３６への接続URL＞
　デジタルコピーサーバ３６への接続URLは再生装置が保有する固定のものを利用してもよいし、バイトコードアプリケーションから指定されたURLを用いても良い。デジタルコピーサーバ３６はコンテンツ提供者毎、地域毎に異なるサーバになる可能性がある。よって、バイトコードアプリケーションから通信ポートを介して指定されたURLを使ってデジタルコピーサーバ３６へ接続するのが望ましい。

　＜サーバ証明書＞
　サーバ証明書、つまり、SSLソケット作成用に再生装置がバイトコードアプリケーションに送るデジタル証明書は、装置固有機能を利用するために用いられるデジタル証明書とは別にしてもよい。この場合、再生装置は暗号化通信用と固有機能用の２種類のデジタル証明書を用意する。加えて、再生装置の不正を防ぐために、バイトコードアプリケーション側で再生装置から送られてくるサーバ証明書の正当性を検証してもよい。例えば、無秩序にコピー可能な再生装置が出回る恐れもあるため、バイトコードアプリケーション側でも再生装置の正当性を検証するのが望ましい。再生装置から送られてくるサーバ証明書を検証し、もしそのサーバ証明書がブラックリストに載っていれば、その再生装置ではデジタルコピー等の実施をバイトコードアプリケーション側で止めることができる。　

　＜処理のバリエーション＞
　第８実施形態では、同一メディアにおけるデジタルコピーについては、不必要にメディア容量を消費しない、かつデータコピーを短時間で終えることができるという観点からムーブを前提に記載したが、十分な空き容量が存在する場合、またはコピー対象となるコンテンツのサイズが小さい場合は、元となるファイルを残してコピーを行っても良い。　

　＜コピーソースユニットのバリエーション＞
　本編コンテンツに、４つのバリエーションが存在していて、本編コンテンツ再生時に、これら、４つのバージョンのうち、任意のものを再生することができる場合、これら4つのバージョンのそれぞれに対応する携帯端末向け保護コンテンツを、DATA01ディレクトリ、DATA02ディレクトリ、DATA03ディレクトリ、DATA04ディレクトリに記録しておいてもよい。こうすることで、視聴することができる様々なバリエーションの本編コンテンツを、任意にコピーすることができる。

　＜バイトコード＞
　これまでの実施形態で説明に使用した“バイトコード”は、例えば、オペランドスタック、ローカル変数、オブジェクト配列に対する操作をJava仮想マシンに実行させる語長が2バイト以下のコードを想定している。オペランドスタック、ローカル変数、オブジェクト配列に対する操作には、オペランドスタックからの取り出し、オペランドスタックへの蓄積、オブジェクト配列からのオブジェクト参照の取り出し、オブジェクト配列へのオブジェクト参照の格納、メソッド終了及び呼出元へのリターン、値の型変換、比較、オペランドスタックに対する加算／減算／乗算／剰余算、符号反転、語挿入を伴うコピーがある。このような特性をもち、バイトコードと技術的に同視することができるプログラムコードであるなら、アプリケーションの作成にそのようなプログラムコードを用いてもよい。　　　

　＜クラスファイル＞
　バイトコードアプリケーションは、クラスファイルのインスタンスである。ここでクラスファイルは、例えば、幾つかのブロックから構成され、そのブロックが細部構造をもっていて、様々なデータの階層管理が可能なデータ構造をもつ構造体ファイルをいう。この細部構造とは、複数のコンスタントプール、複数のフィールドインフォ、複数のメソッドインフォ、複数のアトリビュートインフォが存在するというものである。アトリビュートインフォは、抽象クラスであり、そのサブクラスがクラスファイル、フィールドインフォ、メソッドインフォの下位構造となる。例えば、アトリビュートインフォのうちコード属性は、メソッドインフォの属性となる。このメソッドインフォにより、バイトコードアプリケーションのプログラム的性質が規定される。このような特性をもち、かかるクラスファイルの内部構成と技術的に同視することができるデータ構造であるなら、バイトコードアプリケーションの作成に、そのようなデータ構造を用いてもよい。

　＜集積回路の実施形態＞
　本発明にかかる集積回路は、システムLSIであり、再生装置のハードウェア構成のうち、記録媒体のドライブ部や、外部とのコネクタ等、機構的な部分を排除して、論理回路や記憶素子に該当する部分、つまり、論理回路の中核部分を内蔵したものである。システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものはマルチチップモジュールと呼ばれるが、このようなものに、システムLSIに含まれる。

　ここでパッケージの種別に着目するとシステムLSIには、QFP(クッドフラッドアレイ)、PGA(ピングリッドアレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。

　これらのピンは、電源供給やグランド、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置の中核としての役割を果たす。

　図３４は、集積回路のアーキテクチャを示す図である。本図に示すように、システムLSIである集積回路７０のアーキテクチャは、フロントエンド部７１と、信号処理部７２と、バックエンド部７３と、メディアI/O７４と、メモリコントローラ７５と、ホストマイコン７６とから構成され、メディアI/O７４、メモリコントローラ７５を通じて、再生装置におけるドライブやメモリ、送受信部と接続されている。再生装置におけるドライブには、BD-ROMのドライブ、ローカルストレージのドライブ、リムーバブルメディアのドライブ等がある。

　フロントエンド処理部７１は、プリプログラムされたDMAマスタ回路やI/Oプロセッサ等から構成され、パケット処理全般を実行する。このパケット処理には、デマルチプレクサによるソースパケットデパケッタイザの処理、PIDフィルタの処理が該当する。再生装置のメモリに確保された、トラックバッファ、各種プレーンメモリ、各種バッファ間でDMA転送を実現することにより、上述したようなパケット処理を実現する。

　信号処理部７２は、信号処理プロセッサやSIMDプロセッサ等から構成され、信号処理全般を実行する。信号処理には、ビデオデコーダによるデコードやオーディオデコーダによるデコードがある。

　バックエンド部７３は、加算器、フィルタから構成され、AV出力処理全般を行う。AV出力処理には画素処理があり、かかる画素処理によってレイヤ合成のための画像重畳、リサイズ、画像フォーマット変換がなされる。また、デジタル／アナログ変換等を併せて実行する。

　メディアI/O７４は、ドライブ、ネットワークとのインターフェイスである。　

　メモリコントローラ７５は、メモリアクセスのためのスレーブ回路であり、フロントエンド部、信号処理部、バックエンド部の要求に応じて、パケットやピクチャデータのメモリの読み書きを実現する。このメモリコントローラ７５を通じたメモリの読み書きによって、メモリは、トラックバッファやビデオプレーン、グラフィクスプレーン、ビデオデコーダにおける各種バッファとして機能することになる。

　ホストマイコン７６は、MPU,ROM,RAMから構成され、メディアインターフェイス、フロントエンド部、信号処理部、バックエンド部に対して、全体制御を実行する。この全体制御には、再生制御部、バイトコード処理モジュール、コマンド処理モジュール、モード管理モジュールとしての制御がある。このホストマイコンにおけるCPUは、命令フェッチ部、デコーダ、実行ユニット、レジスタファイル、プログラムカウンタを有している。そして、これまでの実施形態で述べた各種処理を実行するプログラムは、組込プログラムとして、基本入出力システム(BIOS)、様々なミドルウェア(オペレーションシステム)と共に、このホストマイコンにおけるマイコン内のROMに記憶されている。よって再生装置の主たる機能は、このシステムLSI内に組込んでおくことができる。

　＜プログラムの実施形態＞
　各実施形態に示したプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。

　記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。

　コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。

　ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVAバイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。

　オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。かかるプログラムを非一時的なコンピュータプログラムとしてコンピュータ読取可能な記録媒体に記録してユーザに提供してよい。

　本発明を構成する再生装置は、当該記録媒体上のアプリケーションプログラムと再生装置の独自機能を連携させたサービスを提供することが可能となる。特に、映像コンテンツの制作に携わる映画産業・民生機器産業において利用できる。

　１０１　再生装置
　１０２　リモコン
　１０３　表示装置
　１０５　リードオンリーメディア１０５
　１０６　携帯装置
　　２８　オンメディアライブラリ
　　２９　外部サーバ
　　３１　読出制御部
　　３２　書込制御部
　　３３　機器固有機能制御部
　　３５　デジタルコピーモジュール
　　３６　デジタルコピーサーバ

Claims

　記録媒体に記録されたコンテンツを再生すると共に、当該コンテンツに対する機能を実行する再生装置であって、
　前記コンテンツに対する機能には、標準化された再生制御機能と、機器固有の機器固有機能とがあり、
　記録媒体からバイトコードアプリケーションを読み出して、動作させるプラットフォーム部と、
　再生制御機能を実行する再生制御部と、
　機器固有機能を実行する固有機能制御部とを備え、
　前記再生装置のプラットフォーム部は、バイトコードアプリケーションが利用可能なプログラミングインターフェイスを有し、前記バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含み、
　前記バイトコードアプリケーションは、再生制御用プログラミングインターフェイスをコールすることで、再生制御部に再生制御を命じ、
　通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、固有機能制御部に機器固有の制御を命じる
　ことを特徴とする再生装置。
　前記記録媒体は第１記録媒体であり、第１記録媒体には、ルートディレクトリの配下に第１ディレクトリと、第２ディレクトリとが存在し、
　第１ディレクトリは、本編コンテンツが記録されているディレクトリであり、前記バイトコードアプリケーションは、第１ディレクトリに記録されており、
　第２ディレクトリは、持出し視聴用コンテンツが記録されており、当該持出し視聴用コンテンツは、本編コンテンツとは異なるフォーマットのコンテンツであって、機器固有機能の対象となるものであり、
　前記機器固有機能とは、持出し視聴用コンテンツを構成するファイルを、第１記録媒体から第２記録媒体へと、コピーするというメディア間コピーである
　ことを特徴とする請求項１記載の再生装置。
前記第２ディレクトリの配下には、複数のコピーソース格納ディレクトリが存在し、
　前記持出し視聴用コンテンツは、何れか1つのコピーソース格納ディレクトリに記録されており、
　前記バイトコードアプリケーションは、何れかのコピーソース格納ディレクトリのファイルパスを、カレントのソースロケーションとして固有機能制御部に設定することを命じ、
　前記固有機能制御部は、何れか1つのコピーソース格納ディレクトリがカレントソースロケーションとして設定されれば、コピーソース格納ディレクトリから持出し視聴用コンテンツを読み出して、第２記録媒体に書き込むことで、機器固有機能を実行する
　ことを特徴とする請求項２記載の再生装置。
前記第１記録媒体の第１ディレクトリには、機器固有機能のためのオンメディアライブラリが記録されており、オンメディアライブラリは、第１ディレクトリに記録された他のバイトコードアプリケーションに、機器固有機能実行のためのプログラミングインターフェイスを提供するものであり、
　前記オンメディアライブラリは、
　他のバイトコードアプリケーションから、機器固有機能実行用プログラミングインターフェイスのコールがなされた場合、当該プログラミングインターフェイスのコールをソケットコマンドに変換した上で固有機能制御部に出力し、固有機能制御部からのレスポンスを戻り値又はイベントに変換して、コールを行った他のバイトコードアプリケーションに返し、
　前記ソケット接続は、前記ソケットコマンド及びレスポンスを伝送するための通信路を構成する
　ことを特徴とする請求項２記載の再生装置。
　前記第１記録媒体には、持出し視聴用コンテンツを識別するためのコンテンツIDが記録されており、
　コンテンツIDの一部をなすビットは、持出し視聴用コンテンツの供給源であるコンテンツプロバイダを識別するためのものであり、
　バイトコードアプリケーションは、固有機能制御部に、コンテンツIDと、シリアル番号とを含むコマンドを送信し、
　固有機能制御部は、コンテンツIDと、シリアル番号との組みをサーバに送信して、持出し視聴用コンテンツの供給源であるコンテンツプロバイダが、固有機能制御を利用する正当権限を有しているかどうかをサーバに判断させ、正当権限を有しているとサーバが判断した場合は、機器固有機能を実行するが、正当権限を有していないと判断した場合、機器固有機能を実行しない
　ことを特徴とする請求項２記載の再生装置。
　前記持出し視聴用コンテンツに含まれるデジタルストリームは、暗号化されて前記第１記録媒体上に記録されており、
　前記固有機能制御部は更に、前記第２記録媒体に記録すべき持出し視聴用コンテンツに含まれるデジタルストリームを第２記録媒体に書き込む際、前記第一記録媒体に属するシリアルIDと、前記デジタルストリームのコンテンツ識別子と、前記第２記録媒体の媒体識別子及び暗号キーと、を前記外部サーバに送信し、
　前記第２記録媒体固有の保護方式とは、
　前記シリアルID、コンテンツ識別子、媒体識別子及び暗号キーに対応した復号鍵をサーバから取得して、前記第２記録媒体の保護された領域に記録することである、請求項４に記載の再生装置。
　前記再生装置はさらに、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルの正当性を検証する検証部を備え、
　前記検証部は、再生装置内に組み込まれた認証鍵を元に、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルのハッシュ値を算出し、
　前記算出されたハッシュ値が、前記オンメディアライブラリのアーカイブファイル内のデジタル署名ファイルに含まれるデジタル署名の値と一致していれば、バイトコードアプリケーションは、正当であると判断し、
　前記検証部がデジタル署名ファイルが正当でないと判断した場合、前記固有機能制御部はバイトコードアプリケーションから前記再生制御とは異なる機器固有の機能に関連したコマンドを受け取っても、前記再生制御とは異なる機器固有機能の実行を拒否する、請求項４に記載の再生装置。
　再生装置は、通信管理部を備え、
　前記ソケット通信のためのプログラミングインターフェイスは、通信管理部によって供給され、バイトコードアプリケーションからのネットワーク接続要求を検知すると、通信管理部は、再生装置が保有するデジタル証明書をバイトコードアプリケーションに送信し、
　デジタル証明書に付与された署名が正当であると判断した場合に、バイトコードアプリケーションは、通信管理部から通信鍵を受け取り、機器固有機能に関するコマンドを前記通信鍵を用いて暗号化して通信管理部へ送る、請求項２に記載の再生装置。
　記録媒体であって、
　コンテンツと、バイトコードアプリケーションとが記録されており、
　前記コンテンツに対する機能には、標準化された再生制御機能と、機器固有の機器固有機能とがあり、
　再生装置のプラットフォーム部は、バイトコードアプリケーションが利用可能なプログラミングインターフェイスを有し、前記バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含み、
　前記バイトコードアプリケーションは、再生制御用プログラミングインターフェイスをコールすることで、再生装置内の再生制御部に再生制御を命じ、
　通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、再生装置内の固有機能制御部に機器固有の制御を命じる
　ことを特徴とする記録媒体。
　前記記録媒体は第１記録媒体であり、第１記録媒体には、ルートディレクトリの配下に第１ディレクトリと、第２ディレクトリとが存在し、
　第１ディレクトリは、本編コンテンツが記録されているディレクトリであり、前記バイトコードアプリケーションは、第１ディレクトリに記録されており、
　第２ディレクトリは、持出し視聴用コンテンツが記録されており、持出し視聴用コンテンツは、本編コンテンツとは異なるフォーマットのコンテンツであって、機器固有機能の対象となるものであり、
　機器固有機能とは、持出し視聴用コンテンツを構成するディレクトリ及びファイルを、第１記録媒体から第２記録媒体へと、コピーするというメディア間コピーである
　ことを特徴とする請求項９記載の記録媒体。
第２ディレクトリの配下には、複数のコピーソース格納ディレクトリが存在し、
　前記持出し視聴用コンテンツは、何れか1つのコピーソース格納ディレクトリに記録されており、
　　バイトコードアプリケーションは、何れかのコピーソース格納ディレクトリのファイルパスを、カレントのソースロケーションとして固有機能制御部に設定することを命じ、
　固有機能制御部は、何れか1つのコピーソース格納ディレクトリがカレントソースロケーションとして設定されれば、カレントコピーソース格納ディレクトリから持出し視聴用コンテンツを読み出して、第２記録媒体に書き込むことで、機器固有機能を実行する
　ことを特徴とする請求項１０記載の記録媒体。
前記第１記録媒体の第１ディレクトリには、機器固有機能のためのオンメディアライブラリが記録されており、オンメディアライブラリは、第１ディレクトリに記録された他のバイトコードアプリケーションに、機器固有機能実行のためのプログラミングインターフェイスを提供するものであり、
　前記オンメディアライブラリは、
　バイトコードアプリケーションから、機器固有機能実行用プログラミングインターフェイスのコールがなされた場合、当該プログラミングインターフェイスのコールをソケットコマンドに変換した上で固有機能制御部に出力し、固有機能制御部からのレスポンスを戻り値又はイベントに変換して、コールを行ったバイトコードアプリケーションに返し、
　前記ソケット接続は、前記ソケットコマンド及びレスポンスを伝送するための通信路を構成する
　ことを特徴とする請求項１０記載の記録媒体。
記録媒体に記録されたコンテンツを再生すると共に、当該コンテンツに対する機能を実行する再生方法であって、
　コンテンツに対する機能には、標準化された再生制御機能と、機器固有の機器固有機能とがあり、
　記録媒体からバイトコードアプリケーションを読み出して、コンピュータのプラットフォーム部に動作させる第１ステップと、
　バイトコードアプリケーションからの要求に従い、コンテンツに対する機能をコンピュータ内の固有機能制御部に実行させる第２ステップとを有し、
　前記コンピュータのプラットフォーム部において、バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含み、
　前記バイトコードアプリケーションは、再生制御用プログラミングインターフェイスをコールすることで、再生制御部に再生制御を命じ、
　通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、固有機能制御部に機器固有の制御を命じる
　ことを特徴とする再生方法。
記録媒体に記録されたコンテンツを再生すると共に、当該コンテンツに対する機能を実行するコンピュータが読み取り可能なプログラムであって、
　コンテンツに対する機能には、標準化された再生制御機能と、機器固有の機器固有機能とがあり、
　記録媒体からバイトコードアプリケーションを読み出して、コンピュータのプラットフォーム部に動作させる第１ステップと、
　バイトコードアプリケーションからの要求に従い、コンテンツに対する機能をコンピュータ内の固有機能制御部に実行させる第２ステップとを有し、
　前記コンピュータのプラットフォーム部において、バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含み、
　前記バイトコードアプリケーションは、再生制御用プログラミングインターフェイスをコールすることで、再生制御部に再生制御を命じ、
　通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、固有機能制御部に機器固有の制御を命じるようにコンピュータを動作させる
　ことを特徴とするコンピュータが読み取り可能なプログラム。
　記録媒体に記録されたバイトコードアプリケーションおよびオンメディアライブラリを読み出して、動作させるプラットフォーム部と、
　前記記録媒体に記録されたコンテンツに対し、標準化された再生制御機能を実行する再生制御部と、
　前記記録媒体に記録されたコンテンツに対し、機器固有の機器固有機能を実行する固有機能制御部とを備え、
　プラットフォーム部は、バイトコードアプリケーションが利用可能なプログラミングインターフェイスを有し、前記バイトコードアプリケーションが利用可能なプログラミングインターフェイスは、再生制御用プログラミングインターフェイスと、通信用プログラミングインターフェイスとを含むコンピュータが読取り可能なプログラムであって、
　前記バイトコードアプリケーションが、再生制御用プログラミングインターフェイスをコールすると、再生制御部に再生制御を命じるステップ、
　バイトコードアプリケーションが、オンメディアライブラリをコールすると、オンメディアライブラリが通信用プログラミングインターフェイスを用いて固有機能制御部を相手側としたソケット接続を行い、当該ソケット接続を通じて、固有機能制御部に機器固有の制御を命じるステップをコンピュータに実行させるコンピュータが読取り可能なプログラム。
　バイトコードアプリケーションはオンメディアライブラリを含む請求項１５に記載のコンピュータが読取り可能なプログラム。