JP2000083022A - 認証装置及び認証方法及び認証システム並びに記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 オブジェクトの集合で構成される動画を再生
するシステムにおいて、各オブジェクトの認証を効率的
に行う。 【解決手段】 ＵＲＬの情報を含むオブジェクトデータ
で構成される画像データを複数のオブジェクトデータと
各オブジェクトデータに対応するＵＲＬの情報とに分離
し（Ｓ２）、各ＵＲＬの情報に基づいてサーバに対して
各オブジェクトをアクセスするための認証を依頼し（Ｓ
４）、サーバからアクセス許可信号を受信したオブジェ
クトデータに対するアクセスのみを許可する（Ｓ５〜Ｓ
７）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、認証装置及び認証
方法及び認証システム並びに記憶媒体に係り、例えば、
動画を再生する際に個々のオブジェクトに関して著作権
保護等の目的で認証が必要となる場合に好適な認証装置
及び認証方法及び認証システム並びに記憶媒体に関する
ものである。

【０００２】

【従来の技術】図１は、従来のデジタル映像データの送
受信システムを示す図である。図１に示すように、デジ
タル映像データの配信サーバー１０は、それに付随した
ハードディスク等のデジタル映像データの記憶装置１２
に予め記録されているデジタル映像データを、デジタル
映像データの受信クライアント２０からの要求に応じて
インターネット等のネットワーク網３０を介して受信ク
ライアント２０にダウンロードする。ここで、配信サー
バー１０は、デジタル映像データを符号化する変換部１
１を有し、この変換部１１によりデジタル映像データを
符号化してデータ量を削減し、これをＴＣＰ／ＩＰプロ
トコル等の手順に従って受信クライアント２０に配信す
る。受信クライアント２０側は、デジタル映像データを
復号する変換部２１を有し、この変換部２１により受信
に係るデジタル映像信号を再生し、表示、記録又は編集
に供する。

【０００３】１つの動画シーンを複数のオブジェクトで
構成し、配信サーバー１０の変換部１１において各々の
オブジェクトを符号化して圧縮し、これを受信クライア
ント２０に転送し、受信クライアント２０において、こ
れらを復号し、再構成して動画シーンを再生するシステ
ムの一例としてＭＰＥＧ−４プレーヤーがある。

【０００４】図２は、従来のＭＰＥＧ−４プレーヤーの
構成図である。図２は、「ＩＳＯ／ＩＥＣ ＦＣＤ １
４４９６−１ Ｆｉｇ．１−１」に基づいて記載された
ものであり、その詳しい説明については、「ＩＳＯ／Ｉ
ＥＣ ＦＣＤ １４４９６−１」において述べられてい
る。ここでは、その概略についてのみ説明する。

【０００５】ネットワーク等を介して転送（ｔｒａｎｓ
ｍｉｓｓｉｏｎ）されたＭＰＥＧ−４ ビットストリー
ムやＤＶＤ−ＲＡＭ等の記録メディア（ｓｔｒａｇｅ
ｍｅｄｉｕｍ）から読み出されたＭＰＥＧ−４ビットス
トリームは、「ＴｒａｎｓＭｕｘ Ｌａｙｅｒ」におい
て、転送／読み出しに相当する手順に従って受け取られ
（ｓｅｓｓｉｏｎの確立）、「ＦｌｅｘＭｕｘ」部にお
いて、シーン記述データ、オブジェクトデータ、オブジ
ェクト記述データの各ストリームに分離し、復号し、再
生され、シーン記述データ（ｓｃｅｎｅ ｄｅｓｃｒｉ
ｐｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）に基づいて、シ
ーンが再生或いはグラフィック処理される。

【０００６】なお、図３は、図２を模式化、簡略化した
ものである。ここで、個々のオブジェクトについて著作
権保護等の目的で認証が必要となる場合、シーン記述デ
ータを含む複数のオブジェクトデータを含むビットスト
リームの他に、「ＩＰ Ｄａｔａ Ｓｅｔ」（著作権情
報群）のストリームを加えることが考えられる。

【０００７】

【発明が解決しようとする課題】しかしながら、転送ビ
ットストリームの他に、「ＩＰ Ｄａｔａ Ｓｅｔ」
（著作権情報群）のストリームを加えた場合でも、図２
若しくは図３に示す構成では、「Ｏｂｊｅｃｔ Ｄｅｓ
ｃｒｉｐｔｏｒｓ」において「ＩＰ Ｄａｔａ」が再生
されるとは限らないし、仮に「Ｏｂｊｅｃｔ Ｄｅｓｃ
ｒｉｐｔｏｒｓ」において「ＩＰ Ｄａｔａ」が再生さ
れたとしても、画像の再生処理の際に「ＩＰＤａｔａ」
についての処理がなされないため、「ＩＰ Ｐｒｏｔｅ
ｃｔｉｏｎ」（著作権保護）処理が実行されることがな
い。

【０００８】本発明は、上記の背景に鑑みてなされたも
のであり、認証処理を効率化し、著作権等の有効な保護
と著作物等の有効な利用を図ることを目的とする。

【０００９】

【課題を解決するための手段】本発明の第１の側面にか
かる認証装置は、画像データを構成するオブジェクトデ
ータのストリームと、該オブジェクトデータの出所情報
のストリームとを、同一のストリームとして符号化する
符号化手段と、符号化手段により符号化された複数のス
トリームから復号ストリームを生成する生成手段と、生
成手段により生成された復号ストリームを、該復号スト
リームに含まれる複数のオブジェクトデータの各々のス
トリームと、該複数のオブジェクトデータの各々の出所
情報のストリームとに分離する分離手段と、オブジェク
トデータの出所情報を管理する管理手段と、分離手段に
より分離された複数の出所情報のストリームを管理手段
に送信する送信手段とを具備したことを特徴とする。

【００１０】上記の認証装置において、出所情報は、Ｕ
ＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔ
ｏｒ）の情報であることが好ましい。

【００１１】上記の認証装置において、複数のオブジェ
クトデータから構成される画像データは、圧縮符号化さ
れた動画データであることが好ましい。

【００１２】上記の認識装置において、例えば、符号化
手段により符号化される各ストリームの型を指定する指
定手段を更に具備することが好ましく、更に分離手段に
より分離された各ストリームの型を識別する識別手段
と、識別手段により識別された型に基づいて、各ストリ
ームを適切なデコーダへ送出する送出手段とを具備する
ことがより好ましい。

【００１３】本発明の第２の側面にかかる認証方法は、
画像データを構成するオブジェクトデータのストリーム
と、該オブジェクトデータの出所情報のストリームと
を、同一のストリームとして符号化する符号化ステップ
と、符号化ステップにより符号化された複数のストリー
ムから復号ストリームを生成する生成ステップと、生成
ステップにより生成された復号ストリームを、該復号ス
トリームに含まれる複数のオブジェクトデータの各々の
ストリームと、該複数のオブジェクトデータの各々の出
所情報のストリームとに分離する分離ステップと、オブ
ジェクトデータの出所情報を管理する管理ステップと、
分離ステップにより分離された複数の出所情報のストリ
ームを管理ステップに送信する送信ステップとを具備し
たことを特徴とする。

【００１４】上記の認証方法において、出所情報は、Ｕ
ＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔ
ｏｒ）の情報であることが好ましい。

【００１５】上記の認証方法において、複数のオブジェ
クトデータから構成される画像データは、圧縮符号化さ
れた動画データであることが好ましい。

【００１６】上記の認識方法において、例えば、符号化
ステップにより符号化される各ストリームの型を指定す
る指定ステップを更に具備することが好ましく、更に分
離ステップにより分離された各ストリームの型を識別す
る識別ステップと、識別ステップにより識別された型に
基づいて、各ストリームを適切なデコーダへ送出する送
出ステップとを具備することがより好ましい。

【００１７】本発明の第３の側面に係る認証システム
は、送信装置と受信装置とからなる認証システムであっ
て、送信装置は、画像データを構成するオブジェクトデ
ータのストリームと、該オブジェクトデータの出所情報
のストリームとを、同一のストリームとして符号化する
符号化手段と、符号化手段により符号化された複数のス
トリームから復号ストリームを生成する生成手段と、生
成手段により生成された復号ストリームを受信装置に送
信する送信手段とを有し、受信装置は、送信装置から送
信された復号ストリームを、該復号ストリームに含まれ
る複数のオブジェクトデータの各々のストリームと、該
複数のオブジェクトデータの各々の出所情報のストリー
ムとに分離する分離手段と、オブジェクトデータの出所
情報を管理する管理手段と、分離手段により分離された
複数の出所情報のストリームを管理手段に送出する送出
手段とを有することを特徴とする。

【００１８】本発明の第４の側面に係る記憶媒体は、装
置が実行可能なプログラムを格納する記憶媒体であっ
て、プログラムを実行する装置を、画像データを構成す
るオブジェクトデータのストリームと、該オブジェクト
データの出所情報のストリームとを、同一のストリーム
として符号化する符号化手段と、符号化手段により符号
化された複数のストリームから復号ストリームを生成す
る生成手段と、生成手段により生成された復号ストリー
ムを、該復号ストリームに含まれる複数のオブジェクト
データの各々のストリームと、該複数のオブジェクトデ
ータの各々の出所情報のストリームとに分離する分離手
段と、オブジェクトデータの出所情報を管理する管理手
段と、分離手段により分離された複数の出所情報のスト
リームを管理手段に送信する送信手段とを具備する装置
として動作させることを特徴とする。

【００１９】

【発明の実施の形態】以下、添付図面を参照しながら本
発明の好適な実施の形態を説明する。以下の実施の形態
は、所謂「ｂａｃｋ−ｃｈａｎｎｅｌ」を利用して認証
処理を効率化したシステムに関する。

【００２０】図４は、本発明の好適な実施の形態に係る
ＭＰＥＧ−４プレーヤーを含むシステムの概略構成を示
す図である。図４に示すシステムは、「ＩＰ Ｄａｔａ
Ｓｅｔ」を操作して「ＩＰ Ｐｒｏｔｅｃｔｉｏｎ」
を実現するシステムである。図４に示すシステムは、Ｉ
ＰＭＰＳ （Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒ
ｔｙ Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｐｒｏｔｅｃｔ
ｉｏｎ Ｓｙｓｔｅｍ）２０７を有し、このＩＰＭＰＳ
２０７により著作権認証及び保護機能を実現する点で図
３に示すシステムと異なる。

【００２１】図７は、認証処理に関するクライアントの
動作を示すフローチャートである。以下、図７を参照し
ながら図４に示すシステムの動作を説明する。サーバー
側では、マルチプレクサ２０１が、各々異なるＵＲＬ
（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏ
ｒ）としてＵＲＬ１、ＵＲＬ２、ＵＲＬ３を持つ複数の
ネットワーク・サイト２０２〜２０４から、夫々個々の
オブジェクトを受信してこれらの複数のオブジェクトで
構成される動画データを生成する。この動画データは、
クライアントからの要求に応じてＭＰＥＧ−４ビットス
トリーム２０５としてネットワークを介してクライアン
トに送信される。

【００２２】ステップＳ１では、クライアントは、サー
バーよりＭＰＥＧ−４ビットストリーム２０５を受信す
る。このＭＰＥＧ−４ビットストリームを構成する各オ
ブジェクトには、著作権の帰属先を示す情報（ここで
は、ＵＲＬの情報）が付随している。ステップＳ２で
は、クライアントは、受信に係るＭＰＥＧ−４ビットス
トリームをデマルチプレクサ２０６により複数のオブジ
ェクトやそれに付随する情報（ＵＲＬの情報を含む）等
の複数のストリームに分離する。ここで、各オブジェク
トに付随するＵＲＬの情報は、「ＩＰ Ｄａｔａ」のス
トリームである「ＩＰＭＰＳ Ｓｔｒｅａｍ」の一部と
してＩＰＭＰＳ２０７に送られる。

【００２３】ステップＳ３では、ＩＰＭＰＳ２０７に送
られた１又は複数のＵＲＬの情報の中から、いずれか１
つのＵＲＬの情報を選択する。これは、例えば、操作者
が指定するものであっても構わないし、所定の順序に従
ってＩＰＭＰＳ２０７が選択しても構わない。

【００２４】ステップＳ４では、選択したＵＲＬの情報
に基づいて、ネットワーク上に接続された１又は複数の
サーバのうち対応するＵＲＬを持つサーバ２０１に対し
て認証依頼信号を送信する。この場合、その送信には、
後述するバックチャネル（ｂａｃｋ−ｃｈａｎｎｅｌ）
１又はバックチャネル（ｂａｃｋ−ｃｈａｎｎｅｌ）２
が使用される。

【００２５】ステップＳ５では、認証依頼信号を受け取
ったサーバ２０１からアクセス許可信号が送信されてく
るのを待ち、アクセス許可信号を受信した場合はステッ
プＳ６に進み、所定時間内にアクセス許可信号を受信し
なかった場合はステップＳ７に進む。

【００２６】ステップＳ６では、アクセス許可信号の受
信によりアクセス許可（認証）が得られたオブジェクト
に対するアクセスを可能にする。具体的には、アクセス
コントロールポイントを制御する制御信号２１２を許可
状態にすることにより、シーン・ディスクリプタ２０
８、オーディオ・ビジュアル・デコーダ２０９、オブジ
ェクトディスクリプタ２１０がデマルチプレクサ２０６
の該当するストリーム（即ち、アクセス許可信号により
アクセスを許可されたオブジェクトのストリーム）にア
クセスすることを可能にする。

【００２７】一方、ステップＳ７では、アクセスコント
ロールポイントを制御する制御信号２１２を禁止状態に
することにより、シーン・ディスクリプタ２０８、オー
ディオ・ビジュアル・デコーダ２０９、オブジェクトデ
ィスクリプタ２１０がデマルチプレクサ２０６の該当す
るストリーム（即ち、認証を依頼したがアクセス許可が
得られなかったオブジェクトのストリーム）にアクセス
することを禁止する。

【００２８】ステップＳ８では、他のオブジェクトに付
随するＵＲＬの情報があるか否かを確認し、当該ＵＲＬ
の情報があればステップＳ３に戻り、なければ一連の処
理を終了する。

【００２９】シーン合成・グラフィック処理部２１１
は、シーン・ディスクリプタ２０８、オーディオ・ビジ
ュアル・デコーダ２０９、オブジェクトディスクリプタ
２１０から供給されるデータに基づいて、シーン合成及
びグラフィック処理を行う。この際、アクセス許可が得
られたオブジェクトのみを再生の際の合成の対象として
も良いし、１つでもアクセス許可が得られなかったオブ
ジェクトがある場合に、一切の再生を行わないようにし
ても良い。

【００３０】以下、上述した認証処理について更に詳細
に説明する。ＭＰＥＧ−４ビットストリームは、オブジ
ェクト単位のビットストリームである「Ｅｌｅｍｅｎｔ
ａｒｙ Ｓｔｒｅａｍ」（ＥＳ）の内容を記述する「Ｅ
Ｓ＿Ｄｅｓｃｒｉｐｔｏｒ」と、オブジェクト自身を記
述する「ＯＤ＿Ｄｅｓｃｒｉｐｔｏｒ」を含む。ここ
で、「ＥＳ＿Ｄｅｓｃｒｉｐｔｏｒ」或いは「ＯＤ＿Ｄ
ｅｓｃｒｉｐｔｏｒ」に、リモートアクセスのためのコ
マンドとアクセス先を指定するＵＲＬの情報が含まれて
いる場合は、図５に示すような手順でリモートアクセス
が実行される。

【００３１】図５は、リモートアクセスを説明する簡略
図である。図５において、「ＤＡＩ」は、「ＤＭＩＦ
Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ」と呼ば
れる、ＭＰＥＧ−４ビットストリームとネットワークと
のインターフェース層である。この詳細については、
「ＩＳＯ／ＩＥＣ １４４９６−６ ＤＭＩＦドキュメ
ントＤＭＩＦ Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｔｅｒｆ
ａｃｅ」の項に記載されているため、ここでは省略す
る。

【００３２】また、ＭＰＥＧ−４ビットストリームは、
「ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ」（ＥＳ）に対
応したデコーダの種類についての情報を示す「Ｄｅｃｏ
ｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ」を含む。こ
の「ＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏ
ｒ」は、幾つかのデータ要素の構造体であり、その中の
要素の一つにストリーム型を示す１ビットのｕｐＳｔｒ
ｅａｍパラメータがある。この詳細については、「ＩＳ
Ｏ／ＩＥＣ １４４９６−１ ＦＣＤ ８．３．４ Ｄ
ｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ」の項
に記載されているため、ここでは省略する。

【００３３】式１に、「ＤｅｃｏｄｅｒＣｏｎｆｉｇＤ
ｅｓｃｒｉｐｔｏｒ」の一例を挙げる。

【００３４】 ［式１：DecoderConfigDescriptor] aligned(8) class DecoderConfigDescriptor : bit(8) tag=DecoderConfigDescrTag { bit(8) length; bit(8) objectProfileIndication; bit(6) streamType; bit(1) upStream; const bit(1) reserved=1; bit(24) bufferSizeDB; bit(32) maxBitrate; bit(32) avgBitrate; DecoderSpecificInfo decSpecificInfo[]; }

【００３５】ここで、ストリームの識別は、式１の「Ｄ
ｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ」のク
ラス宣言中のデータ要素である「ｓｔｒｅａｍＴｙｐ
ｅ」の値に基づいて行う。「ｓｔｒｅａｍＴｙｐｅ」の
値は、表１のように定義されている。

【００３６】

【表１】

【００３７】なお、表１は、「ＩＳＯ／ＩＥＣ １４４
９６−１ ＦＣＤ Ｔａｂｌｅ ０−１： ｓｔｒｅａ
ｍＴｙｐｅ Ｖａｌｕｅｓ」に対して、この実施の形態
に固有の「ＩＰＭＰＳｔｒｅａｍ」を識別するための値
を追加したものである。表１において、各パラメータや
用語は、「ＩＳＯ／ＩＥＣ １４４９６−１ ＦＣＤ」
と同じであるので、ここでは説明を省略する。

【００３８】このように、表１においては、この実施の
形態に固有の「IPMP Stream」を識別するための値を追
加したが、この「IPMP Stream」は、そもそも、MPEG-4
ビットストリームを生成するマルチプレクサ２０１用の
ソースコードに含まれているものである。このマルチプ
レクサ２０１用のソースコードにおいて、「IPMP Strea
m」は、以下の式２（※）のように定義されている。

【００３９】 ［式２：Mux用ソース］ { objectDescriptorID 0 es_descriptor [ { es_Number 1 fileName Inline.od streamType BIFS streamPriority 5 decConfigDescr { streamType 2 //OD Stream bufferSizeDB 200 } alConigDescr { useAccessUnitStartFlag TRUE useAccessUnitEndFlag TRUE useRandomAccessPointFlag TRUE useTimeStampsFlag TRUE timeStampResolution l000 timeStampLength 14 } } { es_Number 2 streamType BIFS streamPriority 5 f1leName Inline.bif decConfigDescr { streamType 4 //BIFS Stream bufferSizeDB 1000 } alConfigDescr { useAccessUnitStartFlag TRUE useAccessUnitEndFlag TRUE useRandomAccessPointFlag TRUE useTimeStampsFlag TRUE timeStampResolution 100 timeStampLength 14 0CR_ES_Id 1 } } ] } { objectDescriptorID 33 es_descriptor [ { es_Number 1 fileName t2 streamType G723 streamPriority 4 decConfigDescr { streamType 6 //AudioStream profileAndLevelIndication0xc1 //G7 23 bufferSizeDB 300 } alConfigDescr { timeStampResolution 1000 compositionUnitRate 30 } extensionDescriptor IPMP_DescriptorPointer { IPMP_Descriptor_ID 69 } } { es_Number 2 fileName t1 streamType H263 decConfigDescr { streamType 8 // IPMPStream ※ bufferSizeDB 1600 } alConfigDescr { useAccessUnitStartFlag TRUE useAccessUnitEndFlag TRUE useRandomAccessPointFlag TRUE useTimeStampsFlag TRUE timeStampResolution 1000 timeStampLength 10 PDU_seqNumLength 3 AU_seqNumLength 8 0CR_ES_Id 2113 } } ] } { objectDescriptorID 32 es_descriptor { es_Number 1 fileName t1 streamType H263 decConfigDescr { streamType 5 //VisualStream profileAndLevelIndication0xC2 //H263 bufferSizeDB 1600 } alConfigDescr { useAccessUnitStartFlag TRUE useAccessUnitEndFlag TRUE useRandomAccessPointFlag TRUE useTimeStampsFlag TRUE timeStampResolution 1000 timeStampLength 10 PDU_seqNumLength 3 AU_seqNumLength 8 OCR_ES_Id 2113 } } }

【００４０】この式２においては、「objectDescriptor
ID」が「３３」の場合に、「IPMP Stream」が定義され
ている。これは、「IPMP Stream」によってプロテクト
されたオブジェクトのストリームを示す部分が、「obje
ctDescriptorID ３３」に含まれているということであ
る。また、その際の「IPMP Stream」のストリーム型
が、「streamType8」と定義されているが、これは、表
１の「IPMP Stream」のストリーム型指定値として定義
されている「0x0B」と意味的には同じものである。そし
て、本実施の形態においては、このようなソースコード
が、マルチプレクサ２０１で集められ、複数のオブジェ
クトのストリームに「IPMP Stream」を加えて、同じ一
つのストリームに符号化したMPEG-4ビットストリームが
生成されている。そして、前述した「DecoderConfigDes
criptor」によりストリームの識別を行うことにより、
同一のストリームの中から「IPMP Stream」の他、各オ
ブジェクトのストリームを分離することができる。

【００４１】図４に示すように、ストリームの向きを示
すフラグである「ＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃ
ｒｉｐｔｏｒ．ｕｐＳｔｒｅａｍ」が ”１”の時は、
システムは、クライアント側からサーバ側にストリーム
を転送する「ｕｐｓｔｒｅａｍ」の状態になる。ここで
は、この「ｕｐｓｔｒｅａｍ」の状態を利用した転送機
能を「ｂａｃｋ−ｃｈａｎｎｅｌ１」と呼ぶことにす
る。

【００４２】通常の再生時は、「ＤｅｃｏｒｄｅｒＣｏ
ｎｆｉｇＤｅｓｃｒｉｐｔｏｒ．ｕｐＳｔｒｅａｍ」
が”０”であり、サーバ側からクライアント側にストリ
ームを転送する「ｄｏｗｎｓｔｒｅａｍ」の状態であ
る。一方、オブジェクトに対するアクセスの許可を求め
る場合は、「ＤｅｃｏｒｄｅｒＣｏｎｆｉｇＤｅｓｃｒ
ｉｐｔｏｒ．ｕｐＳｔｒｅａｍ」を”１”として、必要
なデータをＵＲＬ先へ「ｕｐｓｔｒｅａｍ」する所謂
「ｂａｃｋ−ｃｈａｎｎｅｌ１」を用いることにより、
「ＩＰＭＰ Ｍａｎａｇｅｍｅｎｔ Ｄａｔａ」（著作
権管理情報）を「ＩＰＭＰＳｔｒｅａｍ」としてサーバ
側に送り、リモートアクセスによりＵＲＬ先から応答デ
ータを転送させることになる。

【００４３】表１に示す「ＩＰＭＰＳｔｒｅａｍ」は、
「ＩＰＭＰ＿ＥＳ」と「ＩＰＭＰ＿Ｄ」の構成を有す
る。「ＩＰＭＰＳ＿ＥＳ」の各々は一連の「ＩＰＭＰ＿
Ｍｅｓｓａｇｅｓ」からなる。 式３は「ＩＰＭＰ＿Ｍ
ｅｓｓａｇｅｓ」の記述例である。

【００４４】 [式3:IPMP_Message] class IPMP_Message () { unsigned int(8) IPMPS_TypeCount; bit(1) hasURL; int i; for (i = 0; i < IPMPS_TypeCount; i++) { unsigned int(16) IPMPS_Type[[i]]; unsigned int(32) offset[[i]]; unsigned int(16) length[[i]]; } if (hasURL) { unsigned int(5) lengthOfURLbits; bit(3) reserved=0b111; unsigned int(lengthOfURLbits) lengthOfURL; char(8) URLString[lengthOfURL]; } for (i = 0; i < IPMPS_TypeCount; i++) { char(8) IPMP_data[length[i]]; } }

【００４５】式３において、「ＩＰＭＰＳ＿ＴｙｐｅＣ
ｏｕｎｔ」は、異なる「ＩＰＭＰＳｔｙｐｅ」の数を表
わす。これにより、異なるＩＰＭＰＳを存在させること
が可能となるため、「ＩＰＭＰ ｍｅｓｓａｇｅｓ」は
複数のＩＰＭＰＳに対応可能である。

【００４６】なお、ＵＲＬが指定されている場合は、
「ＩＰＭＰＳ＿ＴｙｐｅＣｏｕｎｔ」は０を取り、その
他は最低値である１を取る。また、この場合、内部の
「ＩＰＭＰ＿Ｍｅｓｓａｇｅ」の代わりに、外部に格納
されている「ＩＰＭＰ＿Ｍｅｓｓａｇｅ」を参照して使
用することになる。

【００４７】また、「ＩＰＭＰＳ＿Ｄ」は、「ＩＰＭＰ
Ｄｅｓｃｒｉｐｔｏｒ」からなる。この「ＩＰＭＰ
Ｄｅｓｃｒｉｐｔｏｒ」 は、個々の「ｅｌｅｍｅｎｔ
ａｒｙ ｓｔｒｅａｍｓ」に対する詳細なＩＰＭＰ制御
を行うためのデータ構造体である。そして、「ＩＰＭＰ
Ｄｅｓｃｒｉｐｔｏｒ Ｕｐｄａｔｅｓ」 は、オブ
ジェクト・ディスクリプタ・ストリーム（Ｏｂｊｅｃｔ
Ｄｅｓｃｒｉｐｔｏｒ ｓｔｒｅａｍ）の一部として
実行される。式４は、「ＩＰＭＰ Ｄｅｓｃｒｉｐｔｏ
ｒ Ｕｐｄａｔｅｓ」の記述例を示す。

【００４８】 [式4:IPMP_DescriptorUpdate] aligned(8) class IPMP_DescriptorUpdate : uint(8) IPMP_DescriptorUpdateTa g { unsigned int(8) descriptorCount; int i; for (i = 0; i < descriptorCount; i++) { IPMP_Descriptor d[[i]]; } }

【００４９】式４において、「ｄｅｓｃｒｉｐｔｏｒＣ
ｏｕｎｔ」は、更新される「ＩＰＭＰ＿Ｄｅｓｃｒｉｐ
ｔｏｒｓ」の数を表わし、また、ｄ［ｉ］ は、ある一
つの「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔｏｒ」を表わす。式
５は、「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔｏｒ」の記述例を
示す。

【００５０】 [式5:IPMP_Descriptor] class IPMP_Descriptor () { bit(8) IPMP_Descriptor_ID; unsigned int(8) IPMPS_TypeCount; bit(1) hasURL; int i; for (i = 0; i < IPMPS_TypeCount; i++) { unsigned int(16) IPMPS_Type[[i]]; unsigned int(32) offset[[i]]; unsigned int(16) length[[i]]; } if (hasURL) { unsigned int(5) lengthOfURLbits; bit(3) reserved=0b111; unsigned int(lengthOfURLbits) lengthOfURL; char(8) URLString[lengthOfURL]; } for (i = 0; i < IPMPS_TypeCount; i++) { char(8) IPMP_data[length[i]]; } }

【００５１】式５において、「ＩＰＭＰ＿Ｄｅｓｃｒｉ
ｐｔｏｒ＿ＩＤ」は、各「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔ
ｏｒ」に固有の番号であり、「ＥＳ＿Ｄｅｓｃｒｉｐｔ
ｏｒｓ」は、「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔｏｒ＿Ｉ
Ｄ」を使って「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔｏｒｓ」を
参照する。 また、「ＩＰＭＰＳ＿ＴｙｐｅＣｏｕｎ
ｔ」は、「ＩＰＭＰ＿Ｍｅｓｓａｇｅ」で指定された異
なるＩＰＭＰＳの数を表わす。

【００５２】図６は、ＵＲＬ先で更にＵＲＬ指定がある
場合の階層構造の例を示す図である。なお、図６は２階
層の場合の例であるが、もちろん、更なるＵＲＬ指定が
ある場合、３階層になっても４階層になってもよい。ま
た、図６においては、「ＩＰＭＰＳｔｒｅａｍ」を明示
していないが、リモート指定されるオブジェクト（Ｏｂ
ｊｅｃｔ）に関する「ＩＰＭＰ＿ＥＳ」か「ＩＰＭＰ＿
Ｄ」が、「ＳｃｅｎｅＤｅｓｃｒｉｐｔｉｏｎＳｔｒｅ
ａｍ」か「ＯｂｊｅｃｔＤｅｓｃｒｉｐｔｉｏｎＳｔｒ
ｅａｍ」に呼応して、必要に応じデコードされ、リモー
トアクセスされることは、先に説明した図５の場合と同
様である。

【００５３】以上、ＭＰＥＧ−４のビットストリームの
「ｕｐｓｔｒｅａｍ」の状態、即ち、バックチャネル
（ｂａｃｋ−ｃｈａｎｎｅｌ）１を使用した認証処理に
ついて説明したが、このような「ｂａｃｋ−ｃｈａｎｎ
ｅｌ１」を使用する認証処理は、リアルタイムのビット
ストリーム再生時における「ｕｐＳｔｒｅａｍ」処理で
あるので、比較的データ量が少なく処理時間の短い高速
処理向けの場合を想定している。ここで、リアルタイム
再生をしているシステムでは、「ｂａｃｋ−ｃｈａｎｎ
ｅｌ１」によるリモートアクセス及び認証による遅延は
極力少ないことが望ましい。

【００５４】しかしながら、データ量が少ない場合であ
っても認証に相応の時間を要することがあり、その場
合、「ｂａｃｋ−ｃｈａｎｎｅｌ１」における遅延が問
題となる。この場合、許容遅延時間の点、また、インタ
ラクティブな操作性を必要とする点から考えると、第２
の「ｂａｃｋ−ｃｈａｎｎｅｌ」を設けることが好まし
い。

【００５５】そこで、この実施の形態では、ＭＰＥＧ−
４のビットストリームを伝送するのとは異なるＩ／Ｏ
（機器間入出力）インターフェースが設けられている。
これを以下では「ｂａｃｋ−ｃｈａｎｎｅｌ２」と呼ぶ
ことにする。

【００５６】まず、「ｂａｃｋ−ｃｈａｎｎｅｌ２」を
使用した認証処理を説明する前に、「ｂａｃｋ−ｃｈａ
ｎｎｅｌ１」と「ｂａｃｋ−ｃｈａｎｎｅｌ２」におけ
るデータ量と遅延時間の関係を考える。「ＭＰＥＧ−４
ＲｅｑｕｉｒｅｍｅｎｔＧｒｏｕｐ」の報告では、リ
アルタイム再生を妨げない「ｂａｃｋ−ｃｈａｎｎｅ
ｌ」の遅延許容時間は１フレーム時間とあるので、これ
に基づいて「ｂａｃｋ−ｃｈａｎｎｅｌ１」と「ｂａｃ
ｋ−ｃｈａｎｎｅｌ２」における想定データ量と転送レ
ートの関係を求めると、表２のようになる。

【００５７】

【表２】

【００５８】ここで、認証のための高速ＩＰＭＰリモー
トアクセスでは、１００−５００ｂｉｔ／Ｆｒａｍｅ以
内のデータ量を３Ｋ−５Ｋ／ｓｅｃの転送ラインで処理
することが遅延時間の限界となる。「ＩＰＭＰ＿Ｍｅｓ
ｓａｇｅ」データや「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔｏ
ｒ」データとＵＲＬ指定による「ｂａｃｋ−ｃｈａｎｎ
ｅｌ」による「ｒｅｍｏｔｅ ｃｏｎｔｅｎｔ ａｃｃ
ｅｓｓ」の結果としてのｄｅｌａｙ−ｂａｎｄｗｉｄｔ
ｈの関係を、表２と見ることができるので、実際の認証
のためのデータ量は限られたものになる。一方、認証に
は、ｓｔｒｅａｍ処理とは非同期に時間を要することが
多い。

【００５９】また、複数のオブジェクトの認証が一箇所
のサイトではなく、複数に跨ることも想定される。この
場合には、表２の条件は更に厳しくなり、実用に耐えな
くなる。そのため、ｓｔｒｅａｍ処理と非同期で低速処
理が可能な認証手続きの場合には、「ｂａｃｋ−ｃｈａ
ｎｎｅｌ ２」を用いた方が良い。

【００６０】以下、「ｂａｃｋ−ｃｈａｎｎｅｌ ２」
を使用した場合の処理について説明する。認証のための
低速ＩＰＭＰ入出力アクセスのための「ｂａｃｋ−ｃｈ
ａｎｎｅｌ２」は、図４に示すように、基本的にはＭＰ
ＥＧ−４ビットストリームを伝送するものとは異なるＩ
／Ｏ（機器間入出力）インターフェースを対象としたも
のになる。

【００６１】ここで、「ｂａｃｋ−ｃｈａｎｎｅｌ２」
の先に、キーボードとディスプレイとモデムを有するコ
ンピュータ端末２１４を用意し、電話回線とＩＰＭＰＳ
２０７とに接続する。この構成において、コンピュータ
端末２１４は、認証の必要なストリーム中のオブジェク
トとその認証先の情報をＩＰＭＰＳ２０７から受け取
り、その情報をディスプレイに表示する。操作者は、そ
の表示を参照して、認証の必要なストリーム中のオブジ
ェクトを選択する。コンピュータ端末２１４は、認証先
に電話をかけて、認証方法やアクセスコードを該認証先
から受け取り、その内容をディスプレイに表示する。操
作者が、受け取った情報をキーボードを使って入力する
と、その入力情報がＩＰＭＰＳ２０７に通知され、必要
なオブジェクトに対するアクセスを許可状態にする。

【００６２】ここでは、電話回線を利用する場合を例と
して挙げたが、この代わりに、例えば、ＣＡＴＶのケー
ブルや無線通信路を利用しても良い。

【００６３】また、場合によっては、予め認証先との契
約において入手したアクセス認証に必要な情報を格納し
たＰＣ Ｃａｒｄをコンピュータ端末２１４内のＰＣＭ
ＣＩＡインターフェースに差し込んで、アクセス認証に
必要な情報をＩＰＭＰＳ２０７に通知して、オブジェク
トに対するアクセスを許可状態にしてもよい。

【００６４】なお、操作時間や認証時間がある程度長く
なる認証処理の場合は、ストリーム再生の開始時やシー
ンチェンジ時等、リアルタイムでない場合に有効であ
る。

【００６５】このように、この実施の形態によれば、用
途に応じて「ｂａｃｋ−ｃｈａｎｎｅｌ１」又は「ｂａ
ｃｋ−ｃｈａｎｎｅｌ２」を選択して使用することがで
きる。この選択は、操作者が行うことができるように構
成してもよいし、システム内部で遅延時間限界等を考慮
して最適な方を選択するようにしてもよい。

【００６６】以上のように、２種類の異なる「ｂａｃｋ
−ｃｈａｎｎｅｌ」を設けることにより、柔軟性の高い
認証処理を実現することができる。

【００６７】なお、本発明は、複数の機器から構成され
るシステムに適用しても、一つの機器からなる装置に適
用してもよい。

【００６８】また、上記の実施の形態に係る装置又は方
法を構成する構成要素の全体のうち一部の構成要素で構
成される装置又は方法も、本件出願に係る発明者が意図
した発明である。

【００６９】また、上記の実施の形態に係る装置の機能
は、プログラムコードを記録した記憶媒体をシステム或
いは装置に固定的又は一時的に組み込み、そのシステム
或いは装置のコンピュータ（又はＣＰＵ若しくはＭＰ
Ｕ）が該記憶媒体に格納されたプログラムコードを読み
出して実行することによっても達成される。ここで、該
記憶媒体から読み出されたプログラムコード自体或いは
該記憶媒体自体が法上の発明を構成する。

【００７０】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピディスク、ハードディス
ク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ
−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等
が好適であるが、他のデバイスを採用することもでき
る。

【００７１】また、コンピュータが記憶媒体から読み出
したプログラムコードを実行することにより本発明の特
有の機能が実現される場合のみならず、そのプログラム
コードによる指示に基づいて、コンピュータ上で稼働し
ているＯＳ（オペレーティングシステム）等が実際の処
理の一部又は全部を負担する実施の態様も本発明の技術
的範囲に属する。

【００７２】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された機能拡張ボー
ドやコンピュータに接続された機能拡張ユニットに備え
られたメモリに書込まれた後に、そのプログラムコード
の指示に基づいて、その機能拡張ボードや機能拡張ユニ
ットに備えられたＣＰＵ等が実際の処理の一部又は全部
を負担する実施の態様も本発明の技術的範囲に属する。

【００７３】

【発明の効果】本発明によれば、複数のオブジェクトの
ストリームと著作権情報に関するストリームとを同一の
ストリームとして送信し、受信側で著作権情報に関する
ストリームを分離して取り出せるようにしたことによ
り、認証処理を効率化し、著作権等を有効に保護すると
共に著作物等を有効に利用することができる。

【００７４】

【図面の簡単な説明】

【図１】従来のデジタル映像データの送受信システムを
示す図である。

【図２】従来のＭＰＥＧ−４プレーヤーの構成図であ
る。

【図３】図２を模式化・簡略化した図である。

【図４】本発明の好適な実施の形態に係るback channel
を行うＭＰＥＧ−４プレーヤーの構成図である。

【図５】リモートアクセスを説明するための簡略図であ
る。

【図６】ＵＲＬ先で更にＵＲＬ指定がある場合の階層構
造の例を示す図である。

【図７】認証処理に関するクライアントの動作を示すフ
ローチャートである。

【符号の説明】

１０ デジタル映像データ配信サーバー １１、２１ 変換部 １２、２２ デジタル映像データ記憶装置１２ ２０ デジタル映像データ受信クライアント ３０ ネットワーク網 ２０１ マルチプレクサ ２０２〜２０４ ネットワーク・サイト ２０６ デマルチプレクサ ２０８ シーン・ディスクリプタ ２０９ オーディオ・ビジュアル・デコーダ ２１０ オブジェクトディスクリプタ

Claims (12)

【特許請求の範囲】
1. 【請求項１】 画像データを構成するオブジェクトデー
   タのストリームと、該オブジェクトデータの出所情報の
   ストリームとを、同一のストリームとして符号化する符
   号化手段と、 前記符号化手段により符号化された複数のストリームか
   ら復号ストリームを生成する生成手段と、 前記生成手段により生成された復号ストリームを、該復
   号ストリームに含まれる複数のオブジェクトデータの各
   々のストリームと、該複数のオブジェクトデータの各々
   の出所情報のストリームとに分離する分離手段と、 オブジェクトデータの出所情報を管理する管理手段と、 前記分離手段により分離された複数の出所情報のストリ
   ームを前記管理手段に送信する送信手段とを具備したこ
   とを特徴とする認証装置。
2. 【請求項２】 前記出所情報は、ＵＲＬ（Ｕｎｉｆｏｒ
   ｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）の情報である
   ことを特徴とする請求項１に記載の認証装置。
3. 【請求項３】 前記複数のオブジェクトデータから構成
   される画像データは、圧縮符号化された動画データであ
   ることを特徴とする請求項１に記載の認証装置。
4. 【請求項４】 前記符号化手段により符号化される各ス
   トリームの型を指定する指定手段を具備したことを特徴
   とする請求項１に記載の認証装置。
5. 【請求項５】 前記分離手段により分離された各ストリ
   ームの型を識別する識別手段と、 前記識別手段により識別された型に基づいて、前記各ス
   トリームを適切なデコーダへ送出する送出手段とを具備
   したことを特徴とする請求項４に記載の認証装置。
6. 【請求項６】 画像データを構成するオブジェクトデー
   タのストリームと、該オブジェクトデータの出所情報の
   ストリームとを、同一のストリームとして符号化する符
   号化ステップと、 前記符号化ステップにより符号化された複数のストリー
   ムから復号ストリームを生成する生成ステップと、 前記生成ステップにより生成された復号ストリームを、
   該復号ストリームに含まれる複数のオブジェクトデータ
   の各々のストリームと、該複数のオブジェクトデータの
   各々の出所情報のストリームとに分離する分離ステップ
   と、 オブジェクトデータの出所情報を管理する管理ステップ
   と、 前記分離ステップにより分離された複数の出所情報のス
   トリームを前記管理ステップに送信する送信ステップと
   を具備したことを特徴とする認証方法。
7. 【請求項７】 前記出所情報は、ＵＲＬ（Ｕｎｉｆｏｒ
   ｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）の情報である
   ことを特徴とする請求項６に記載の認証方法。
8. 【請求項８】 前記複数のオブジェクトデータから構成
   される画像データは、圧縮符号化された動画データであ
   ることを特徴とする請求項６に記載の認証方法。
9. 【請求項９】 前記符号化ステップにより符号化される
   各ストリームの型を指定する指定ステップを具備したこ
   とを特徴とする請求項６に記載の認証方法。
10. 【請求項１０】 前記分離ステップにより分離された各
    ストリームの型を識別する識別ステップと、 前記識別ステップにより識別された型に基づいて、前記
    各ストリームを適切なデコーダへ送出する送出ステップ
    とを具備したことを特徴とする請求項９に記載の認証方
    法。
11. 【請求項１１】 送信装置と受信装置とからなる認証シ
    ステムであって、 前記送信装置は、 画像データを構成するオブジェクトデータのストリーム
    と、該オブジェクトデータの出所情報のストリームと
    を、同一のストリームとして符号化する符号化手段と、 前記符号化手段により符号化された複数のストリームか
    ら復号ストリームを生成する生成手段と、 前記生成手段により生成された復号ストリームを前記受
    信装置に送信する送信手段とを有し、 前記受信装置は、 前記送信装置から送信された復号ストリームを、該復号
    ストリームに含まれる複数のオブジェクトデータの各々
    のストリームと、該複数のオブジェクトデータの各々の
    出所情報のストリームとに分離する分離手段と、 オブジェクトデータの出所情報を管理する管理手段と、 前記分離手段により分離された複数の出所情報のストリ
    ームを前記管理手段に送出する送出手段とを有すること
    を特徴とする認証システム。
12. 【請求項１２】 装置が実行可能なプログラムを格納す
    る記憶媒体であって、前記プログラムを実行する装置
    を、 画像データを構成するオブジェクトデータのストリーム
    と、該オブジェクトデータの出所情報のストリームと
    を、同一のストリームとして符号化する符号化手段と、 前記符号化手段により符号化された複数のストリームか
    ら復号ストリームを生成する生成手段と、 前記生成手段により生成された復号ストリームを、該復
    号ストリームに含まれる複数のオブジェクトデータの各
    々のストリームと、該複数のオブジェクトデータの各々
    の出所情報のストリームとに分離する分離手段と、 オブジェクトデータの出所情報を管理する管理手段と、 前記分離手段により分離された複数の出所情報のストリ
    ームを前記管理手段に送信する送信手段とを具備する装
    置として動作させることを特徴とする記憶媒体。