JP4072260B2

JP4072260B2 - 情報処理装置、情報処理方法及びコンテンツ配信サーバ並びにその制御方法

Info

Publication number: JP4072260B2
Application number: JP29593698A
Authority: JP
Inventors: 裕司井上; 利之中川
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1998-06-29
Filing date: 1998-10-16
Publication date: 2008-04-09
Anticipated expiration: 2018-10-16
Also published as: JP2000083233A

Description

【０００１】
【発明の属する技術分野】
本発明は、例えば、動画を再生する際に個々のオブジェクトに関して著作権保護等の目的で認証が必要となる場合に好適な、情報処理装置、情報処理方法及びコンテンツ配信サーバ並びにその制御方法に関するものである。
【０００２】
【従来の技術】
図１は、従来のデジタル映像データの送受信システムを示す図である。図１に示すように、デジタル映像データの配信サーバー１０は、それに付随したハードディスク等のデジタル映像データの記憶装置１２に予め記録されているデジタル映像データを、デジタル映像データの受信クライアント２０からの要求に応じてインターネット等のネットワーク網３０を介して受信クライアント２０にダウンロードする。ここで、配信サーバー１０は、デジタル映像データを符号化する変換部１１を有し、この変換部１１によりデジタル映像データを符号化してデータ量を削減し、これをＴＣＰ／ＩＰプロトコル等の手順に従って受信クライアント２０に配信する。受信クライアント２０側は、デジタル映像データを復号する変換部２１を有し、この変換部２１により受信に係るデジタル映像信号を再生し、表示、記録又は編集に供する。
【０００３】
１つの動画シーンを複数のオブジェクトで構成し、配信サーバー１０の変換部１１において各々のオブジェクトを符号化して圧縮し、これを受信クライアント２０に転送し、受信クライアント２０において、これらを復号し、再構成して動画シーンを再生するシステムの一例としてＭＰＥＧ−４プレーヤーがある。
【０００４】
図２は、従来のＭＰＥＧ−４プレーヤーの構成図である。図２は、「ＩＳＯ／ＩＥＣＦＣＤ１４４９６−１Ｆｉｇ．１−１」に基づいて記載されたものであり、その詳しい説明については、「ＩＳＯ／ＩＥＣＦＣＤ１４４９６−１」において述べられている。ここでは、その概略についてのみ説明する。
【０００５】
ネットワーク等を介して転送（ｔｒａｎｓｍｉｓｓｉｏｎ）されたＭＰＥＧ−４ビットストリームやＤＶＤ−ＲＡＭ等の記録メディア（ｓｔｒａｇｅｍｅｄｉｕｍ）から読み出されたＭＰＥＧ−４ビットストリームは、「ＴｒａｎｓＭｕｘＬａｙｅｒ」において、転送／読み出しに相当する手順に従って受け取られ（ｓｅｓｓｉｏｎの確立）、「ＦｌｅｘＭｕｘ」部において、シーン記述データ、オブジェクトデータ、オブジェクト記述データの各ストリームに分離し、復号し、再生され、シーン記述データ（ｓｃｅｎｅｄｅｓｃｒｉｐｔｉｏｎｉｎｆｏｒｍａｔｉｏｎ）に基づいて、シーンが再生或いはグラフィック処理される。
【０００６】
なお、図３は、図２を模式化、簡略化したものである。ここで、個々のオブジェクトについて著作権保護等の目的で認証が必要となる場合、シーン記述データを含む複数のオブジェクトデータを含むビットストリームに「ＩＰＤａｔａＳｅｔ」（著作権情報群）を含ませることが考えられる。
【０００７】
【発明が解決しようとする課題】
しかしながら、転送ビットストリームに「ＩＰＤａｔａＳｅｔ」（著作権情報群）を含ませた場合でも、図２若しくは図３に示す構成では、仮に「ＯｂｊｅｃｔＤｅｓｃｒｉｐｔｏｒｓ」において「ＩＰＤａｔａ」が再生されたとしても、画像の再生処理の際に「ＩＰＤａｔａ」についての処理がなされないため、「ＩＰＰｒｏｔｅｃｔｉｏｎ」（著作権保護）処理が実行されることがない。
【０００８】
もちろん、この場合でもデコードされた「ＩＰＤａｔａＳｅｔ」をアプリケーションが受け取って「ＩＰＰｒｏｔｅｃｔｉｏｎ」処理を実行することは可能であるが、この場合の処理はそのアプリケーションに固有の処理であり、他のプレーヤーや他の機種において同様の処理が実行されるとは限らない。
【０００９】
また、図２若しくは図３に示す構成では、個々のオブジェクトに対して認証処理を行った後に画像を再生するため、動画シーンを再生する際に次々と新しいオブジェクトが出現する場合には、その度に再生を一時的に停止して認証を求める必要があった。
さらに、認証処理を行う際に、再生を停止しないでおくと、当然のことながら、認証処理にかかった時間分だけ、再生される映像が欠落してしまうという問題があった。
【００１０】
本発明は、上記の背景に鑑みてなされたものであり、例えば、認証処理を効率化し、著作権等の有効な保護と著作物の有効な利用を図るとともに、認証処理に関わる遅延時間により再生映像が欠落する問題を解消することを目的とする。
【００１１】
【課題を解決するための手段】
本発明の第１の側面に係る情報処理方法は、ａ）複数のオブジェクトデータとオブジェクトデータの知的財産管理データとが多重化されたＭＰＥＧ−４符号化方式に準拠した情報データストリームをコンテンツ配信サーバから受信するステップと、ｂ）受信した知的財産管理データに基づいて、オブジェクトデータの認証を行うステップと、ｃ）認証の結果を示すデータと、情報データストリームの最初からの再送を要求する再送要求データと、情報データストリームに多重化されたオブジェクトデータの著作権の帰属先を示す情報とを、ＭＰＥＧ−４ビットストリームのアップストリームを使用してコンテンツ配信サーバへ送信するステップと、ｄ）コンテンツ配信サーバから再送された情報データストリームを受信するステップと、ｅ）再送された情報データストリームを再生するステップ、とを有することを特徴とする。
【００１９】
本発明の第２の側面に係るコンテンツ配信サーバの制御方法は、ａ）複数のオブジェクトデータとオブジェクトデータの知的財産管理データとが多重化されたＭＰＥＧ−４符号化方式に準拠した情報データストリームを、クライアントに送信するステップと、ｂ）ＭＰＥＧ−４ビットストリームのアップストリームを使用して送信される、オブジェクトデータの認証結果を示すデータと、情報データストリームの再送を要求する再送要求データと、情報データストリームに多重化されたオブジェクトデータの著作権の帰属先を示す情報とを、クライアントから受信するステップと、ｃ）認証結果を示すデータと、再送要求データとに基づいて、情報データストリームを最初から再送するステップ、とを有することを特徴とする。
【００２１】
本発明の第３の側面に係る情報処理装置は、ａ）複数のオブジェクトデータとオブジェクトデータの知的財産管理データとが多重化されたＭＰＥＧ−４符号化方式に準拠した情報データストリームをコンテンツ配信サーバから受信する手段と、ｂ）受信した知的財産管理データに基づいて、オブジェクトデータの認証を行う手段と、ｃ）認証の結果を示すデータと、情報データストリームの最初からの再送を要求する再送要求データと、情報データストリームに多重化されたオブジェクトデータの著作権の帰属先を示す情報とを、ＭＰＥＧ−４ビットストリームのアップストリームを使用してコンテンツ配信サーバへ送信する手段と、ｄ）コンテンツ配信サーバから再送された情報データストリームを受信する手段と、ｅ）再送された情報データストリームを再生する手段、とを有することを特徴とする。
【００２８】
本発明の第４の側面に係るコンテンツ配信サーバは、ａ）複数のオブジェクトデータとオブジェクトデータの知的財産管理データとが多重化されたＭＰＥＧ−４符号化方式に準拠した情報データストリームを、クライアントに送信する手段と、ｂ）ＭＰＥＧ−４ビットストリームのアップストリームを使用して送信される、オブジェクトデータの認証結果を示すデータと、情報データストリームの再送を要求する再送要求データと、情報データストリームに多重化されたオブジェクトデータの著作権の帰属先を示す情報とを、クライアントから受信する手段と、ｃ）認証結果を示すデータと、再送要求データとに基づいて、情報データストリームを最初から再送する手段、とを有することを特徴とする。
【００４２】
【発明の実施の形態】
以下、添付図面を参照しながら本発明の好適な実施の形態を説明する。以下の実施の形態は、所謂「ｂａｃｋ−ｃｈａｎｎｅｌ」を利用して認証処理を効率化したシステムに関する。
【００４３】
（第１の実施形態）
図４は、本発明の好適な実施の形態に係るＭＰＥＧ−４プレーヤーを含むシステムの概略構成を示す図である。図４に示すシステムは、「ＩＰＤａｔａＳｅｔ」を操作して「ＩＰＰｒｏｔｅｃｔｉｏｎ」を実現するシステムである。図４に示すシステムは、ＩＰＭＰＳ（ＩｎｔｅｌｌｅｃｔｕａｌＰｒｏｐｅｒｔｙＭａｎａｇｅｍｅｎｔａｎｄＰｒｏｔｅｃｔｉｏｎＳｙｓｔｅｍ）２０７を有し、このＩＰＭＰＳ２０７により著作権認証及び保護機能を実現する点で図３に示すシステムと異なる。
【００４４】
図７は、認証処理に関するクライアントの動作を示すフローチャートである。以下、図７を参照しながら図４に示すシステムの動作を説明する。サーバー側では、マルチプレクサ２０１が、各々異なるＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）としてＵＲＬ１、ＵＲＬ２、ＵＲＬ３を持つ複数のネットワーク・サイト２０２〜２０４から、夫々個々のオブジェクトを受信してこれらの複数のオブジェクトで構成される動画データを生成する。この動画データは、クライアントからの要求に応じてＭＰＥＧ−４ビットストリーム２０５としてネットワークを介してクライアントに送信される。
【００４５】
ステップＳ１では、クライアントは、サーバーよりＭＰＥＧ−４ビットストリーム２０５を受信する。このＭＰＥＧ−４ビットストリームを構成する各オブジェクトには、著作権の帰属先を示す情報（ここでは、ＵＲＬの情報）が付随している。ステップＳ２では、クライアントは、受信に係るＭＰＥＧ−４ビットストリームをデマルチプレクサ２０６により複数のオブジェクトやそれに付随する情報（ＵＲＬの情報を含む）等の複数のストリームに分離する。ここで、各オブジェクトに付随するＵＲＬの情報は、「ＩＰＤａｔａ」のストリームである「ＩＰＭＰＳＳｔｒｅａｍ」の一部としてＩＰＭＰＳ２０７に送られる。
【００４６】
ステップＳ３では、ＩＰＭＰＳ２０７に送られた１又は複数のＵＲＬの情報の中から、いずれか１つのＵＲＬの情報を選択する。これは、例えば、操作者が指定するものであっても構わないし、所定の順序に従ってＩＰＭＰＳ２０７が選択しても構わない。
【００４７】
ステップＳ４では、選択したＵＲＬの情報に基づいて、ネットワーク上に接続された１又は複数のサーバのうち対応するＵＲＬを持つサーバ２０１に対して認証依頼信号を送信する。この場合、その送信には、後述するバックチャネル（ｂａｃｋ−ｃｈａｎｎｅｌ）１又はバックチャネル（ｂａｃｋ−ｃｈａｎｎｅｌ）２が使用される。
【００４８】
ステップＳ５では、認証依頼信号を受け取ったサーバ２０１からアクセス許可信号が送信されてくるのを待ち、アクセス許可信号を受信した場合はステップＳ６に進み、所定時間内にアクセス許可信号を受信しなかった場合はステップＳ７に進む。
【００４９】
ステップＳ６では、アクセス許可信号の受信によりアクセス許可（認証）が得られたオブジェクトに対するアクセスを可能にする。具体的には、アクセスコントロールポイントを制御する制御信号２１２を許可状態にすることにより、シーン・ディスクリプタ２０８、オーディオ・ビジュアル・デコーダ２０９、オブジェクトディスクリプタ２１０がデマルチプレクサ２０６の該当するストリーム（即ち、アクセス許可信号によりアクセスを許可されたオブジェクトのストリーム）にアクセスすることを可能にする。
【００５０】
一方、ステップＳ７では、アクセスコントロールポイントを制御する制御信号２１２を禁止状態にすることにより、シーン・ディスクリプタ２０８、オーディオ・ビジュアル・デコーダ２０９、オブジェクトディスクリプタ２１０がデマルチプレクサ２０６の該当するストリーム（即ち、認証を依頼したがアクセス許可が得られなかったオブジェクトのストリーム）にアクセスすることを禁止する。
【００５１】
ステップＳ８では、他のオブジェクトに付随するＵＲＬの情報があるか否かを確認し、当該ＵＲＬの情報があればステップＳ３に戻り、なければ一連の処理を終了する。
【００５２】
シーン合成・グラフィック処理部２１１は、シーン・ディスクリプタ２０８、オーディオ・ビジュアル・デコーダ２０９、オブジェクトディスクリプタ２１０から供給されるデータに基づいて、シーン合成及びグラフィック処理を行う。この際、アクセス許可が得られたオブジェクトのみを再生の際の合成の対象としても良いし、１つでもアクセス許可が得られなかったオブジェクトがある場合に、一切の再生を行わないようにしても良い。
【００５３】
以下、上述した認証処理について更に詳細に説明する。
【００５４】
ＭＰＥＧ−４ビットストリームは、オブジェクト単位のビットストリームである「ＥｌｅｍｅｎｔａｒｙＳｔｒｅａｍ」（ＥＳ）の内容を記述する「ＥＳ＿Ｄｅｓｃｒｉｐｔｏｒ」と、オブジェクト自身を記述する「ＯＤ＿Ｄｅｓｃｒｉｐｔｏｒ」を含む。ここで、「ＥＳ＿Ｄｅｓｃｒｉｐｔｏｒ」或いは「ＯＤ＿Ｄｅｓｃｒｉｐｔｏｒ」に、リモートアクセスのためのコマンドとアクセス先を指定するＵＲＬの情報が含まれている場合は、図５に示すような手順でリモートアクセスが実行される。
【００５５】
図５は、リモートアクセスを説明する簡略図である。図５において、「ＤＡＩ」は、「ＤＭＩＦＡｐｐｌｉｃａｔｉｏｎＩｎｔｅｒｆａｃｅ」と呼ばれる、ＭＰＥＧ−４ビットストリームとネットワークとのインターフェース層である。この詳細については、「ＩＳＯ／ＩＥＣ１４４９６−６ＤＭＩＦドキュメントＤＭＩＦＡｐｐｌｉｃａｔｉｏｎＩｎｔｅｒｆａｃｅ」の項に記載されているため、ここでは省略する。
【００５６】
また、ＭＰＥＧ−４ビットストリームは、「ｅｌｅｍｅｎｔａｒｙｓｔｒｅａｍ」（ＥＳ）に対応したデコーダの種類についての情報を示す「ＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ」を含む。この「ＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ」は、幾つかのデータ要素の構造体であり、その中の要素の一つにストリーム型を示す１ビットのｕｐＳｔｒｅａｍパラメータがある。この詳細については、「ＩＳＯ／ＩＥＣ１４４９６−１ＦＣＤ８．３．４ＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ」の項に記載されているため、ここでは省略する。
【００５７】
式１に、「ＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ」の一例を挙げる。
【００５８】

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

【００６１】
なお、表１は、「ＩＳＯ／ＩＥＣ１４４９６−１ＦＣＤＴａｂｌｅ０−１：ｓｔｒｅａｍＴｙｐｅＶａｌｕｅｓ」に対して、この実施の形態に固有の「ＩＰＭＰＳｔｒｅａｍ」を識別するための値を追加したものである。表１において、各パラメータや用語は、「ＩＳＯ／ＩＥＣ１４４９６−１ＦＣＤ」と同じであるので、ここでは説明を省略する。
【００６２】
図４に示すように、ストリームの向きを示すフラグである「ＤｅｃｏｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ．ｕｐＳｔｒｅａｍ」が ”１”の時は、システムは、クライアント側からサーバ側にストリームを転送する「ｕｐｓｔｒｅａｍ」の状態になる。ここでは、この「ｕｐｓｔｒｅａｍ」の状態を利用した転送機能を「ｂａｃｋ−ｃｈａｎｎｅｌ１」と呼ぶことにする。
【００６３】
通常の再生時は、「ＤｅｃｏｒｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ．ｕｐＳｔｒｅａｍ」が”０”であり、サーバ側からクライアント側にストリームを転送する「ｄｏｗｎｓｔｒｅａｍ」の状態である。一方、オブジェクトに対するアクセスの許可を求める場合は、「ＤｅｃｏｒｄｅｒＣｏｎｆｉｇＤｅｓｃｒｉｐｔｏｒ．ｕｐＳｔｒｅａｍ」を”１”として、必要なデータをＵＲＬ先へ「ｕｐｓｔｒｅａｍ」する所謂「ｂａｃｋ−ｃｈａｎｎｅｌ１」を用いることにより、「ＩＰＭＰＭａｎａｇｅｍｅｎｔＤａｔａ」（著作権管理情報）を「ＩＰＭＰＳｔｒｅａｍ」としてサーバ側に送り、リモートアクセスによりＵＲＬ先から応答データを転送させることになる。
【００６４】
表１に示す「ＩＰＭＰＳｔｒｅａｍ」は、「ＩＰＭＰ＿ＥＳ」と「ＩＰＭＰ＿Ｄ」の構成を有する。「ＩＰＭＰＳ＿ＥＳ」の各々は一連の「ＩＰＭＰ＿Ｍｅｓｓａｇｅｓ」からなる。式２は「ＩＰＭＰ＿Ｍｅｓｓａｇｅｓ」の記述例である。
【００６５】

【００６６】
式２において、「ＩＰＭＰＳ＿ＴｙｐｅＣｏｕｎｔ」は、異なる「ＩＰＭＰＳｔｙｐｅ」の数を表わす。これにより、異なるＩＰＭＰＳを存在させることが可能となるため、「ＩＰＭＰｍｅｓｓａｇｅｓ」は複数のＩＰＭＰＳに対応可能である。
【００６７】
なお、ＵＲＬが指定されている場合は、「ＩＰＭＰＳ＿ＴｙｐｅＣｏｕｎｔ」は０を取り、その他は最低値である１を取る。また、この場合、内部の「ＩＰＭＰ＿Ｍｅｓｓａｇｅ」の代わりに、外部に格納されている「ＩＰＭＰ＿Ｍｅｓｓａｇｅ」を参照して使用することになる。
【００６８】
また、「ＩＰＭＰＳ＿Ｄ」は、「ＩＰＭＰＤｅｓｃｒｉｐｔｏｒ」からなる。この「ＩＰＭＰＤｅｓｃｒｉｐｔｏｒ」は、個々の「ｅｌｅｍｅｎｔａｒｙｓｔｒｅａｍｓ」に対する詳細なＩＰＭＰ制御を行うためのデータ構造体である。そして、「ＩＰＭＰＤｅｓｃｒｉｐｔｏｒＵｐｄａｔｅｓ」は、オブジェクト・ディスクリプタ・ストリーム（ＯｂｊｅｃｔＤｅｓｃｒｉｐｔｏｒｓｔｒｅａｍ）の一部として実行される。式３は、「ＩＰＭＰＤｅｓｃｒｉｐｔｏｒＵｐｄａｔｅｓ」の記述例を示す。
【００６９】

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

【００７２】
式４において、「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔｏｒ＿ＩＤ」は、各「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔｏｒ」に固有の番号であり、「ＥＳ＿Ｄｅｓｃｒｉｐｔｏｒｓ」は、「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔｏｒ＿ＩＤ」を使って「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔｏｒｓ」を参照する。また、「ＩＰＭＰＳ＿ＴｙｐｅＣｏｕｎｔ」は、「ＩＰＭＰ＿Ｍｅｓｓａｇｅ」で指定された異なるＩＰＭＰＳの数を表わす。
【００７３】
図６は、ＵＲＬ先で更にＵＲＬ指定がある場合の階層構造の例を示す図である。なお、図６は２階層の場合の例であるが、もちろん、更なるＵＲＬ指定がある場合、３階層になっても４階層になってもよい。また、図６においては、「ＩＰＭＰＳｔｒｅａｍ」を明示していないが、リモート指定されるオブジェクト（Ｏｂｊｅｃｔ）に関する「ＩＰＭＰ＿ＥＳ」か「ＩＰＭＰ＿Ｄ」が、「ＳｃｅｎｅＤｅｓｃｒｉｐｔｉｏｎＳｔｒｅａｍ」か「ＯｂｊｅｃｔＤｅｓｃｒｉｐｔｉｏｎＳｔｒｅａｍ」に呼応して、必要に応じデコードされ、リモートアクセスされることは、先に説明した図５の場合と同様である。
【００７４】
以上、ＭＰＥＧ−４のビットストリームの「ｕｐｓｔｒｅａｍ」の状態、即ち、バックチャネル（ｂａｃｋ−ｃｈａｎｎｅｌ）１を使用した認証処理について説明したが、このような「ｂａｃｋ−ｃｈａｎｎｅｌ１」を使用する認証処理は、リアルタイムのビットストリーム再生時における「ｕｐＳｔｒｅａｍ」処理であるので、比較的データ量が少なく処理時間の短い高速処理向けの場合を想定している。ここで、リアルタイム再生をしているシステムでは、「ｂａｃｋ−ｃｈａｎｎｅｌ１」によるリモートアクセス及び認証による遅延は極力少ないことが望ましい。
【００７５】
しかしながら、データ量が少ない場合であっても認証に相応の時間を要することがあり、その場合、「ｂａｃｋ−ｃｈａｎｎｅｌ１」における遅延が問題となる。この場合、許容遅延時間の点、また、インタラクティブな操作性を必要とする点から考えると、第２の「ｂａｃｋ−ｃｈａｎｎｅｌ」を設けることが好ましい。
【００７６】
そこで、この実施の形態では、ＭＰＥＧ−４のビットストリームを伝送するのとは異なるＩ／Ｏ（機器間入出力）インターフェースが設けられている。これを以下では「ｂａｃｋ−ｃｈａｎｎｅｌ２」と呼ぶことにする。
【００７７】
まず、「ｂａｃｋ−ｃｈａｎｎｅｌ２」を使用した認証処理を説明する前に、「ｂａｃｋ−ｃｈａｎｎｅｌ１」と「ｂａｃｋ−ｃｈａｎｎｅｌ２」におけるデータ量と遅延時間の関係を考える。「ＭＰＥＧ−４ＲｅｑｕｉｒｅｍｅｎｔＧｒｏｕｐ」の報告では、リアルタイム再生を妨げない「ｂａｃｋ−ｃｈａｎｎｅｌ」の遅延許容時間は１フレーム時間とあるので、これに基づいて「ｂａｃｋ−ｃｈａｎｎｅｌ１」と「ｂａｃｋ−ｃｈａｎｎｅｌ２」における想定データ量と転送レートの関係を求めると、表２のようになる。
【００７８】
【表２】

【００７９】
ここで、認証のための高速ＩＰＭＰリモートアクセスでは、１００−５００ｂｉｔ／Ｆｒａｍｅ以内のデータ量を３Ｋ−５Ｋ／ｓｅｃの転送ラインで処理することが遅延時間の限界となる。「ＩＰＭＰ＿Ｍｅｓｓａｇｅ」データや「ＩＰＭＰ＿Ｄｅｓｃｒｉｐｔｏｒ」データとＵＲＬ指定による「ｂａｃｋ−ｃｈａｎｎｅｌ」による「ｒｅｍｏｔｅｃｏｎｔｅｎｔａｃｃｅｓｓ」の結果としてのｄｅｌａｙ−ｂａｎｄｗｉｄｔｈの関係を、表４と見ることができるので、実際の認証のためのデータ量は限られたものになる。一方、認証には、ｓｔｒｅａｍ処理とは非同期に時間を要することが多い。
【００８０】
また、複数のオブジェクトの認証が一箇所のサイトではなく、複数に跨ることも想定される。この場合には、表２の条件は更に厳しくなり、実用に耐えなくなる。そのため、ｓｔｒｅａｍ処理と非同期で低速処理が可能な認証手続きの場合には、「ｂａｃｋ−ｃｈａｎｎｅｌ２」を用いた方が良い。
【００８１】
以下、「ｂａｃｋ−ｃｈａｎｎｅｌ２」を使用した場合の処理について説明する。認証のための低速ＩＰＭＰ入出力アクセスのための「ｂａｃｋ−ｃｈａｎｎｅｌ２」は、図４に示すように、基本的にはＭＰＥＧ−４ビットストリームを伝送するものとは異なるＩ／Ｏ（機器間入出力）インターフェースを対象としたものになる。
【００８２】
ここで、「ｂａｃｋ−ｃｈａｎｎｅｌ２」の先に、キーボードとディスプレイとモデムを有するコンピュータ端末２１４を用意し、電話回線とＩＰＭＰＳ２０７とに接続する。この構成において、コンピュータ端末２１４は、認証の必要なストリーム中のオブジェクトとその認証先の情報をＩＰＭＰＳ２０７から受け取り、その情報をディスプレイに表示する。操作者は、その表示を参照して、認証の必要なストリーム中のオブジェクトを選択する。コンピュータ端末２１４は、認証先に電話をかけて、認証方法やアクセスコードを該認証先から受け取り、その内容をディスプレイに表示する。操作者が、受け取った情報をキーボードを使って入力すると、その入力情報がＩＰＭＰＳ２０７に通知され、必要なオブジェクトに対するアクセスを許可状態にする。
【００８３】
ここでは、電話回線を利用する場合を例として挙げたが、この代わりに、例えば、ＣＡＴＶのケーブルや無線通信路を利用しても良い。
【００８４】
また、場合によっては、予め認証先との契約において入手したアクセス認証に必要な情報を格納したＰＣＣａｒｄをコンピュータ端末２１４内のＰＣＭＣＩＡインターフェースに差し込んで、アクセス認証に必要な情報をＩＰＭＰＳ２０７に通知して、オブジェクトに対するアクセスを許可状態にしてもよい。
【００８５】
なお、操作時間や認証時間がある程度長くなる認証処理の場合は、ストリーム再生の開始時やシーンチェンジ時等、リアルタイムでない場合に有効である。
【００８６】
このように、この実施の形態によれば、用途に応じて「ｂａｃｋ−ｃｈａｎｎｅｌ１」又は「ｂａｃｋ−ｃｈａｎｎｅｌ２」を選択して使用することができる。この選択は、操作者が行うことができるように構成してもよいし、システム内部で遅延時間限界等を考慮して最適な方を選択するようにしてもよい。
【００８７】
以上のように、２種類の異なる「ｂａｃｋ−ｃｈａｎｎｅｌ」を設けることにより、柔軟性の高い認証処理を実現することができる。
【００８８】
（第２の実施形態）
以上説明したように、第１の実施形態においては、当該ＭＰＥＧ−４プレーヤーが、ネットワーク上の接続された１又は複数のサーバのうち対応するＵＲＬを持つサーバに対して認証依頼信号を送信する際に、「ｂａｃｋ−ｃｈａｎｎｅｌ」を用いる手法について説明したが、本第２の実施形態においては、「ｂａｃｋ−ｃｈａｎｎｅｌ」の他の利用方法について説明することにする。
【００８９】
図８は、図２、３に対して、著作権保護システム(ＩＰＭＰＳｙｓｔｅｍ８６）とオブジェクトデータ処理フロー制御部（ＩＰＭＰＳｔｒｅａｍＦｌｏｗＣｏｎｔｒｏｌ８３）とを加えたＭＰＥＧ−４プレーヤーの概略図を示している。
【００９０】
図８は、図４における「アクセスコントロールポイント」におけるストリームの制御の内容を、より具体的に開示したものである。
この図８において、著作権保護を要求する画像オブジェクト符号化データを含むＭＰＥＧ−４ビットストリームはＤｅｍｕｘＬａｙｅｒ８１で各々のオブジェクトデータに分割され、ＳｙｎｃＬａｙｅｒ８２で符号化やビットストリーム作成時に加えられた時間刻印情報に従ってプレーヤー内部時間に変換・同期される。
【００９１】
一方、ＩＰＭＰＳｙｓｔｅｍ８６は、ＤｅｍｕｘＬａｙｅｒ８１で分離された著作権保護情報に基づき、個々に分離された著作権保護を要求するオブジェクトデータの認証処理を行い、ＩＰＭＰＳｔｅａｍＦｌｏｗＣｏｎｔｒｏｌ８３へ許可信号を渡してオブジェクトデータ処理フロー制御を行い、ＣｏｍｐｒｅｓｓｉｏｎＬａｙｅｒ８４にて、各オブジェクトデータは各オブジェクトデータ毎のデコーダで復号され、ＣｏｍｐｏｓｉｔｉｏｎＬａｙｅｒ８５にて、復号されたシーン記述にしたがってシーン合成を行い、表示する。
【００９２】
特に、オブジェクトデータ処理フロー制御の方法には、幾つかの方法が考えられ、ここでは例として、ＴｅｓｔＣｏｎｄｉｔｉｏｎ＃１と＃２の２つを挙げて、解決しようとする問題の説明をする。
【００９３】
表３は、ＩＰＭＰＳｙｓｔｅｍ（ＩＰＭＰＳ）とＳｔｒｅａｍＦｌｏｗＣｏｎｔｒｏｌの関係を示す例として、４つのテストプランを示した図である。
【００９４】
【表３】

【００９５】
この表３において、テスト１は、ＩＰＭＰＳｙｓｔｅｍが存在しない場合、テスト２は、ＩＰＭＰＳ１だけが存在する場合、テスト３は、ＩＰＭＰＳ２だけが存在する場合、テスト４は、ＩＰＭＰＳ１とＩＰＭＰＳ２の両方が存在する場合を示している。
【００９６】
次に、各テストにおいて入出力する信号、及び、ＩＰＭＰＳ１とＩＰＭＰＳ２の役割の違いについて説明する。
まず、表３では、ＵｎｐｒｏｔｅｃｔｅｄＴｅｘｔＯｂｊｅｃｔＳｔｒｅａｍを”ｔ”と表現し、ＰｒｏｔｅｃｔｅｄＡｕｄｉｏＳｔｒｅａｍを”Ｓ１（Ｃａ）”と表現し、ＰｒｏｔｅｃｔｅｄＶｉｄｅｏＳｔｒｅａｍを”Ｓ２（Ｃｖ）”と表現している。
そして、Ｓ１（Ｃａ）用ＩＰＭＰＳｙｓｔｅｍを”ＩＰＭＰＳ１”と表現し、オリジナルの符号化データとＡＳＣＩＩｃｏｄｅ ”ｘ”とのＸＯＲ（論理的排他和）の結果を”Ｓ１（Ｃａ）としている。従って解読キーはＡＳＣＩＩｃｏｄｅ ”ｘ”で、出力は、オリジナルの符号化データと”ｘ”との”ＸＯＲ”となる。
【００９７】
また、Ｓ２（Ｃｖ）用ＩＰＭＰＳｙｓｔｅｍを”ＩＰＭＰＳ２”と表現し、オリジナルの符号化データとＡＳＣＩＩｃｏｄｅ ”ａ”とのＸＯＲの結果を”Ｓ２（Ｃｖ）としている。従って解読キーはＡＳＣＩＩｃｏｄｅ ”ａ”で、出力は、オリジナルの符号化データと”ａ”との”ＸＯＲ”となる。
なお、”ＧｒａｃｅｆｕｌＥｒｒｏｒ”とは、ｐｒｏｔｅｃｔｅｄｏｂｊｅｃｔｓｔｒｅａｍを正常にキーで解読できなかったために起こるデコーダ以降でのエラーで、いわゆる”ｆａｔａｌｅｒｒｏｒ（致命的システムエラー）”ではなく、例えば、ＰｒｏｔｅｃｔｅｄＶｉｄｅｏＳｔｒｅａｍの場合の考えられる”ＧｒａｃｅｆｕｌＥｒｒｏｒ”は、「表示されない」、若しくは、「乱れた画面が表示される」等のエラーである。テスト４の場合のみ、”ＧｒａｃｅｆｕｌＥｒｒｏｒ”が発生しない。
【００９８】
表４は、ＩＰＭＰのＶｅｒｉｆｉｃａｔｉｏｎテストのコンディションとパラメータを示した図である。
【００９９】
【表４】

【０１００】
この表４において、テスト２を実行する場合、ＴｅｓｔＣｏｎｄｉｔｉｏｎ＃１では、各オブジェクトストリームにとって正常なキーが、あらかじめＩＰＭＰＳｙｓｔｅｍ（ＩＰＭＰＳ１，ＩＰＭＰＳ２）に在り、入ってきたオブジェクトストリームを直ちに（また、一定の遅延時間で）「解読」して各デコーダに出力する。
【０１０１】
また、テスト２を実行する場合、ＴｅｓｔＣｏｎｄｉｔｉｏｎ＃２では、各オブジェクトストリームにとって正常なキーが、あらかじめＩＰＭＰＳｙｓｔｅｍ（ＩＰＭＰＳ１，ＩＰＭＰＳ２）にはなく、外部からのキー入力やスマートカード挿入等のユーザーインタラクティブな方法によって正常なキーを入力し、入ってきたオブジェクトストリームを「解読」して各デコーダに出力する。そのため、遅延時間は一定ではない。
【０１０２】
図９は、ＭＰＥＧ−４ＳｙｓｔｅｍＰｌａｙｅｒの一例の内部機能ブロックダイヤグラムとデータの流れを示した図である。
この図９は、同期メカニズムの説明のために、実際のシステムを簡略化して示したものであり、ＩＰＭＰＳｙｓｔｅｍとオブジェクトデータ処理フロー制御は省略してある。
【０１０３】
まず、アプリケーションから起動されるＭＰＥＧ−４ＳｙｓｔｅｍＰｌａｙｅｒの入り口関数、Ｅｘｅｃｕｔｅ（）は、各機能モジュールを呼び起こし、データ領域バッファ確保や各機能関数へのメモリ割付などを行い、データ処理の準備をする。
ＤＭＩＦｌａｙｅｒのＳｅｒｖｉｃｅｍｏｄｕｌｅ関数としてのＦｌｅｘＤｅｍｕｘ９１によって、入力されるＭＰＥＧ−４ビットストリーム、即ち、ネットワークからのパケットデータやデータファイルは、一連のデータ群として受け取られ、ＡＬＭａｎａｇｅｒ９２へと渡される。
【０１０４】
次に、ＡＬＭａｎａｇｅｒ９２内部で、データ群から各オブジェクトデータ、例えば、ビデオデータ、オーディオデータ、シーン記述データ等のデータの分割され、各データチャネルとなってシーン記述やオブジェクト関連情報データは、ＢＩＦＳＤｅｃｏｄｅｒ９３へ、ビデオ、オーディオデータはＤｅｃｏｄｅｒ９４へ渡される。
【０１０５】
ＢＩＦＳＤｅｃｏｄｅｒ９３及びＤｅｃｏｄｅｒ９４で復号されたシーン記述情報と、ビットストリーム作成時に加えられた時間刻印情報に応じて、Ｐｒｅｓｅｎｔｅｒ９５やＭｅｄｉａＳｔｒｅａｍデータ処理部（不図示）で、各復号ＭｅｄｉａＯｂｊｅｃｔｄａｔａ（Ｖｉｄｅｏ，Ａｕｄｉｏｄａｔａ）の時間関係を調整し、同期を取り、シーン合成する。
【０１０６】
図１０は、上記一連のデータ処理プロセスを簡略化したものである。
この図１０において、ＦｌｅｘＤｅｍｕｘ９１は、ＭＰＥＧ−４ビットストリームを受け取り、各オブジェクトデータ毎のｅｌｅｍｅｎｔａｒｙｓｔｒｅａｍ（ＥＳ）に分ける。そして、ＡＬＭＡｎａｇｅｒ９２は、各オブジェクトデータ毎のＥＳをデコード単位に分割し、ＢＩＦＳＤｅｃｏｄｅｒ９３及びＤｅｃｏｄｅｒ９４は、各オブジェクト毎の復号処理を行う。そして、各オブジェクトデータ毎の復号されたデータ群ＭｅｄｉａＳｔｒｅａｍが生成され、Ｐｒｅｓｅｎｔｅｒ９５は、ＭｅｄｉａＳｔｒｅａｍデータを扱う”ＭｅｄｉａＳｔｒｅａｍＩｍｐ：：Ｆｅｔｃｈ（）”関数を用いて、個々のオブジェクトデータの時間調整を行い、各オブジェクトデータを１シーン毎に合成し、表示する。
【０１０７】
図１１は、時間調整のデータ処理例を示す図である。この図１１を用いて、Ｐｒｅｓｅｎｔｅｒ９５における時間調整処理について詳しく説明する。
まず、ステップＳ１１０１において、ＳｙｓｔｅｍＰｌａｙｅｒの現在時間に許容値を加え（→ｄｗＣｕｒｒｅｎｔＴｉｍｅ）、その値に基づいて、ステップＳ１１０２において、処理予定データ（ＡＵ）の刻印時間（ＴｉｍｅＳｔａｍｐ）をＳｙｓｔｅｍＰｌａｙｅｒ時間に換算し（→ｄｗＴｉｍｅ）、ステップＳ１１０４において、現在時間（ｄｗＣｕｒｒｅｎｔＴｉｍｅ）と処理予定データ（ＡＵ）の刻印時間（ｄｗＴｉｍｅ）とを比較する。処理予定データ（ＡＵ）の刻印時間（ｄｗＴｉｍｅ）が現在時間（ｄｗＣｕｒｒｅｎｔＴｉｍｅ）より後であれば、ステップＳ１１０６に進み、実際のシーン合成処理を行い、処理予定データ（ＡＵ）の刻印時間（ｄｗＴｉｍｅ）が現在時間（ｄｗＣｕｒｒｅｎｔＴｉｍｅ）より前であれば、シーン合成に不適（時間的にシーン合成時間に間に合わないデータと判断）として、ステップＳ１１０５に進み、次のデータ処理ブロック（ＡＵ）を処理対象にする。
【０１０８】
図１２は、図１１に示した時間調整処理について、タイムチャートで時系列に示したものである。
この図１２において、Ｏｂｊｅｃｔｓｔｒｅａｍ（ＡＵ０）は、Ａｒｒｉｖａｌ（ＡＵ０）の時点で、ＢＩＦＳＤｅｃｏｄｅｒ９３若しくはＤｅｃｏｄｅｒ９４のＤｅｃｏｄｉｎｇＢｕｆｆｅｒ１２０１へ届き、その後デコードされて、エンコード時に付加された刻印時間ＤＴＳ（ＡＵ０）の時点で、Ｐｒｅｓｅｎｔｅｒ９５のＣｏｍｐｏｓｉｔｉｏｎＭｅｍｏｒｙ１２０２へ送られ、シーン合成時間ＣＴＳ（ＣＵ０）の時点から、シーン合成される。そして、続くＯｂｊｅｃｔｓｔｒｅａｍ（ＡＵ１）も同様に、ＤＴＳ（ＡＵ１）の時点でＤｅｃｏｄｉｎｇＢｕｆｆｅｒ１２０１からＣｏｍｐｏｓｉｔｉｏｎＭｅｍｏｒｙ１２０２へと移され、ＣＴＳ（ＣＵ１）からシーン合成される。
【０１０９】
このように、図１２を見れば、図１１において、ＤｅｃｏｄｉｎｇＢｕｆｆｅｒ１２０１における時間ＤＴＳが、実際の現在時点ｄｗＣｕｒｒｅｎｔＴｉｍｅ以降として、ＣｏｍｐｏｔｓｉｔｉｏｎＭｅｍｏｒｙ１２０２における実際のシーン合成時間ＣＴＳへと調整されていることが分かる。
【０１１０】
図１３は、図１０に示した処理フローにＩＰＭＰＳｙｓｔｅｍでの処理を加えたものである。具体的には、以下のような処理を行う。
ＦｌｅｘＤｅｍｕｘ９１がＭＰＥＧ−４ビットストリームを受け取り、各オブジェクトデータ毎のＥｌｅｍｅｎｔａｒｙＳｔｒｅａｍ（ＥＳ）に分け、ＡＬＭａｎａｇｅｒ９２が各オブジェクトデータ毎のＥＳをデコード単位に分割するところまでは、図１０と同様である。そして、次に、ＡＬＭａｎａｇｅｒ９２で分けられたオブジェクトデータから、特にＩＰＭＰ関連情報に基づいて、ｐｒｏｔｅｃｔｅｄｓｔｒｅａｍを特定し、正常キーの入力・認証等のＩＰＭＰＳｙｓｔｅｍ処理を行う。そして、ＢＩＦＳＤｅｃｏｄｅｒ９３及びＤｅｃｏｄｅｒ９４が、各オブジェクトデータ毎のデコードするデータ群であるＭｅｄｉａＳｔｒｅａｍを復号処理して、Ｐｒｅｓｅｎｔｅｒ９５が、個々のオブジェクトの時間調整を行い、１シーン毎に合成し表示する。
【０１１１】
ここで、一例として、表４に示したテスト２を実行した場合におけるＴｅｓｔＣｏｎｄｉｔｉｏｎ＃１と＃２のオブジェクトデータ処理フロー制御について説明する。
まず、ＴｅｓｔＣｏｎｄｉｔｉｏｎ＃１の方法では、キー解読の時間は各ＩＰＭＰＳｙｓｔｅｍ毎に一定の遅延としてデコーダへ伝えられるので、図８のＣｏｍｐｏｓｉｔｉｏｎＬａｙｅｒ８４や、図９のＰｒｅｓｅｎｔｅｒ９５で吸収される範囲であるように全体の遅延を見込んでおけば、結果として同期の問題は起こらない。
【０１１２】
一方、ＴｅｓｔＣｏｎｄｉｔｉｏｎ＃２の方法では、以下のようになる。
図１４は、テスト２をＴｅｓｔＣｏｎｄｉｔｉｏｎ＃２で実行する場合のＩＰＭＰＳｙｓｔｅｍの処理を説明したフローチャートである。
まず、ステップＳ１４０１において、ＡＬＭａｎａｇｅｒ９２でデコード単位に分割された各オブジェクト毎のストリームを得る。そして、ステップＳ１４０２において、正当なキー入力があったか否かを判別する。そして、正当なキー入力ではなかった場合は、ステップＳ１４０３に進み、ｐｒｏｔｅｃｔｅｄｓｔｒｅａｍの解読をしないで、ＨＯＬＤする。また、正当なキー入力があった場合は、ステップＳ１４０４に進み、ｐｒｏｔｅｃｔｅｄｓｔｒｅａｍの解読を行い、次の処理へと進む。
【０１１３】
テスト２をＴｅｓｔＣｏｎｄｉｔｉｏｎ＃２で実行する場合に、図１４に示したフロー制御が行われる場合には、正常なキー入力があるまでのストリームはｓｕｓｐｅｎｄされ、一方、ｎｏｎ−ｐｒｏｔｅｃｔｅｄｓｔｒｅａｍや他の既に正常なキー入力によって認証・解読されたストリームは次のデコーダ処理、シーン合成のための時間同期処理へと移行する。この際、先のｓｕｓｐｅｎｄｅｄｓｔｒｅａｍが正常なキー入力で認証・解読され、次の処理へ移行するまでの経過時間は、各ｐｒｏｔｅｃｔｅｄｓｔｒｅａｍへのユーザーインタラクティブな操作のために、各々一定ではなく、また処理再開時点では、すでにｄｗＴｉｍｅがｄｗＣｕｒｒｅｎｔＴｉｍｅを過ぎていることも考えられる。
【０１１４】
この場合、図１１及び図１２から明らかなように、再開されたストリームは少なくとも再開以降のｄｗＴｉｍｅがｄｗＣｕｒｒｅｎｔＴｉｍｅより後となるまでデコードされず、次の処理予定データ（ＡＵ）までスキップし（即ち、データが間引かれ）、スキップされた部分については、シーン合成されることはない。このように、ＴｅｓｔＣｏｎｄｉｔｉｏｎ＃２の方法では、一部のデータが間引かれてしまい、連続するコンテンツを最初から得ることができなくなる。
【０１１５】
もちろん、有料放送のような”ｐｕｓｈ”型のデータ配信では、基本的に時間帯に応じた片方向データ配信で、セットトップボックス等の認証機能付き受像システムでデータを受けるので、ＴｅｓｔＣｏｎｄｉｔｉｏｎ＃１で十分対応できるため問題はない。
【０１１６】
しかしながら、例えば、視聴者が、インターネット上ホームページの、ある映画などの映像の初めの数分間のコマーシャルデモコンテンツ群を見て、その中から１つのコンテンツを選択して、課金認証後に、その映像を初めから入手・鑑賞したいような場合は、ＴｅｓｔＣｏｎｄｉｔｉｏｎ＃１では無論対応できないし、ＴｅｓｔＣｏｎｄｉｔｉｏｎ＃２では選択・認証後に再生を再開するため、視聴者は、それ迄に流れてしまったコンテンツを得ることができない。
【０１１７】
また、ＭＰＥＧ−４では、ビデオオブジェクト毎の選択・再生が可能なので、先のコマーシャルデモコンテンツにおいては、認証処理されていない状態でも、人物や背景など、一部のオブジェクトだけをｐｒｏｔｅｃｔｅｄｓｔｒｅａｍとしてｇｒａｃｅｆｕｌｅｒｒｏｒとして再生させ続けることが可能であるが、この場合でも、ＴｅｓｔＣｏｎｄｉｔｉｏｎ＃２では、選択・認証後に再生を再開するため、視聴者は、それ迄に流れてしまった正常かつ完全なフルコンテンツを得ることができない。
このように、視聴者が、最初から完全なコンテンツを見たいと思った場合には、コンテンツ配信側のサーバに、最初から映像を再送するように指示する必要がある。
【０１１８】
一般的な解決方法の一つは、選択・認証後の映像再生の再開時に、クライアント（ユーザ）側からサーバ（コンテンツ配信）側へとフルコンテンツの再送要求をすることであるが、通常、この要求を行うためには、サーバ側がクライアント側からの要求を受け取るために、サーバ側がクライアント側へ予めアプリケーションを提供しておく必要がある。
【０１１９】
しかしながら、ＭＰＥＧ−４などのように複数のビデオオブジェクトコンテンツやオーディオオブジェクトコンテンツを各々異なるＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）先から得てシーン合成する場合では、複数のコンテンツ配信のサーバの夫々に対するアプリケーションと認証・再送方法が必要となるので、プログラム管理が煩雑となり、方法としては現実的ではない。
【０１２０】
そこで、本第２の実施形態では、そのような、最初から映像を再送するように指示する信号を、その要求先のサーバのＵＲＬの情報と、認証結果を示す情報とともに、第１の実施形態で説明した「ｂａｃｋ−ｃｈａｎｎｅｌ」（「ｂａｃｋ−ｃｈａｎｎｅｌ１」または「ｂａｃｋ−ｃｈａｎｎｅｌ２」）を使用して、コンテンツ配信元のサーバへと送信するのである。
【０１２１】
より具体的には、本第２の実施形態においては、通常の使用ではＭＰＥＧ−４ビットストリームを受け取ってシーン再生処理する（ｄｏｗｎｓｔｒｅａｍ処理する）プレーヤー側から、ＭＰＥＧ−４でのｂａｃｋｃｈａｎｎｅｌ機能を使って、プレーヤー側からサーバ側へと情報を配信する（即ち、図１に示したようなＵｐｃｈａｎｎｅｌｉｎｆｏｒｍａｔｉｏｎで、認証・再送情報をＵｐｓｔｒｅａｍ処理する）ことで、各コンテンツ配信元サーバ側では、認証・再送情報の通信に関する部分を、ＩＰＭＰＳｙｓｔｅｍＩｎｔｅｒｆａｃｅと共に共有することとなり、プログラム管理の煩雑さを軽減することができる。
【０１２２】
このように、第２の実施形態によれば、認証処理後に、ネットワークを介して著作物の再送要求を行うことが容易にできるので、認証処理に関わる遅延時間によって、再生される映像が欠落するといったことがなくなる。
【０１２３】
なお、第２の実施形態においては、認証処理の方法については、特に問わない。即ち、第１の実施形態のように、ネットワークを介して各コンテンツ配信サーバに対して認証依頼信号を送って、該各コンテンツ配信サーバからアクセス許可をもらうのでもよいし、また、ＭＰＥＧ−４プレーヤーの方に、予め正当なキーが記憶されていて、視聴者がローカルに認証作業を行うようにするのでも構わない。
【０１２４】
なお、本発明は、複数の機器から構成されるシステムに適用しても、一つの機器からなる装置に適用してもよい。
【０１２５】
また、上記の実施の形態に係る装置又は方法を構成する構成要素の全体のうち一部の構成要素で構成される装置又は方法も、本件出願に係る発明者が意図した発明である。
【０１２６】
また、上記の実施の形態に係る装置の機能は、プログラムコードを記録した記憶媒体をシステム或いは装置に固定的又は一時的に組み込み、そのシステム或いは装置のコンピュータ（又はＣＰＵ若しくはＭＰＵ）が該記憶媒体に格納されたプログラムコードを読み出して実行することによっても達成される。ここで、該記憶媒体から読み出されたプログラムコード自体或いは該記憶媒体自体が法上の発明を構成する。
【０１２７】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等が好適であるが、他のデバイスを採用することもできる。
【０１２８】
また、コンピュータが記憶媒体から読み出したプログラムコードを実行することにより本発明の特有の機能が実現される場合のみならず、そのプログラムコードによる指示に基づいて、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部又は全部を負担する実施の態様も本発明の技術的範囲に属する。
【０１２９】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備えられたメモリに書込まれた後に、そのプログラムコードの指示に基づいて、その機能拡張ボードや機能拡張ユニットに備えられたＣＰＵ等が実際の処理の一部又は全部を負担する実施の態様も本発明の技術的範囲に属する。
【０１３０】
【発明の効果】
以上説明したように、本発明によれば、認証処理を効率化し、著作権等を有効に保護すると共に著作物等を有効に利用することができる。
さらに本発明によれば、認証処理後に、ネットワークを介して著作物の再送要求を行うようにしたことにより、認証処理に関わる遅延時間による再生映像の欠落がなくなり、そのことにより、多くの認証処理方法が可能となる効果がある。
【０１３１】
【図面の簡単な説明】
【図１】従来のデジタル映像データの送受信システムを示す図である。
【図２】従来のＭＰＥＧ−４プレーヤーの構成図である。
【図３】図２を模式化・簡略化した図である。
【図４】本発明の好適な実施の形態に係るback channelを行うＭＰＥＧ−４プレーヤーの構成図である。
【図５】リモートアクセスを説明するための簡略図である。
【図６】ＵＲＬ先で更にＵＲＬ指定がある場合の階層構造の例を示す図である。
【図７】認証処理に関するクライアントの動作を示すフローチャートである。
【図８】図３の構成にIPMP System処理部を追加した構成を示す図である。
【図９】 MPEG-4 プレーヤーの内部機能ブロックダイヤグラムとデータの流れを示す図である。
【図１０】図５におけるデータ処理プロセスを簡略化して示した図である。
【図１１】 MPEG-4オブジェクトアクセスデータユニットの時間調整動作例を示すフローチャートである。
【図１２】 Decoding BufferとComposition Memroyのデータ移動とタイミングを示す図である。
【図１３】図６にIPMP System処理部を加えた場合のデータ処理プロセスを示す図である。
【図１４】図８のIPMP Systemの動作例をしめすフローチャートである。
【符号の説明】
１０デジタル映像データ配信サーバー
１１、２１変換部
１２、２２デジタル映像データ記憶装置１２
２０デジタル映像データ受信クライアント
３０ネットワーク網
２０１マルチプレクサ
２０２〜２０４ネットワーク・サイト
２０６デマルチプレクサ
２０８シーン・ディスクリプタ
２０９オーディオ・ビジュアル・デコーダ
２１０オブジェクトディスクリプタ

Claims

ａ）複数のオブジェクトデータと前記オブジェクトデータの知的財産管理データとが多重化されたＭＰＥＧ−４符号化方式に準拠した情報データストリームをコンテンツ配信サーバから受信するステップと、
ｂ）前記受信した前記知的財産管理データに基づいて、前記オブジェクトデータの認証を行うステップと、
ｃ）前記認証の結果を示すデータと、前記情報データストリームの最初からの再送を要求する再送要求データと、前記情報データストリームに多重化されたオブジェクトデータの著作権の帰属先を示す情報とを、ＭＰＥＧ−４ビットストリームのアップストリームを使用して前記コンテンツ配信サーバへ送信するステップと、
ｄ）前記コンテンツ配信サーバから再送された前記情報データストリームを受信するステップと、
ｅ）前記再送された情報データストリームを再生するステップ、
とを有することを特徴とする情報処理方法。
ａ）複数のオブジェクトデータと前記オブジェクトデータの知的財産管理データとが多重化されたＭＰＥＧ−４符号化方式に準拠した情報データストリームを、クライアントに送信するステップと、
ｂ）ＭＰＥＧ−４ビットストリームのアップストリームを使用して送信される、前記オブジェクトデータの認証結果を示すデータと、前記情報データストリームの再送を要求する再送要求データと、前記情報データストリームに多重化されたオブジェクトデータの著作権の帰属先を示す情報とを、前記クライアントから受信するステップと、
ｃ）前記認証結果を示すデータと、前記再送要求データとに基づいて、前記情報データストリームを最初から再送するステップ、
とを有することを特徴とする、コンテンツ配信サーバの制御方法。
ａ）複数のオブジェクトデータと前記オブジェクトデータの知的財産管理データとが多重化されたＭＰＥＧ−４符号化方式に準拠した情報データストリームをコンテンツ配信サーバから受信する手段と、
ｂ）前記受信した前記知的財産管理データに基づいて、前記オブジェクトデータの認証を行う手段と、
ｃ）前記認証の結果を示すデータと、前記情報データストリームの最初からの再送を要求する再送要求データと、前記情報データストリームに多重化されたオブジェクトデータの著作権の帰属先を示す情報とを、ＭＰＥＧ−４ビットストリームのアップストリームを使用して前記コンテンツ配信サーバへ送信する手段と、
ｄ）前記コンテンツ配信サーバから再送された前記情報データストリームを受信する手段と、
ｅ）前記再送された情報データストリームを再生する手段、
とを有することを特徴とする情報処理装置。
ａ）複数のオブジェクトデータと前記オブジェクトデータの知的財産管理データとが多重化されたＭＰＥＧ−４符号化方式に準拠した情報データストリームを、クライアントに送信する手段と、
ｂ）ＭＰＥＧ−４ビットストリームのアップストリームを使用して送信される、前記オブジェクトデータの認証結果を示すデータと、前記情報データストリームの再送を要求する再送要求データと、前記情報データストリームに多重化されたオブジェクトデータの著作権の帰属先を示す情報とを、前記クライアントから受信する手段と、
ｃ）前記認証結果を示すデータと、前記再送要求データとに基づいて、前記情報データストリームを最初から再送する手段、
とを有することを特徴とする、コンテンツ配信サーバ。