JP2001306737A

JP2001306737A - デジタルコンテンツ配信システム、デジタルコンテンツ配信方法、情報変換サーバ、情報処理装置、情報処理方法、記憶媒体及びプログラムソフトウェア

Info

Publication number: JP2001306737A
Application number: JP2001016999A
Authority: JP
Inventors: Yuji Inoue; 裕司井上; Yoshikazu Yokomizo; 良和横溝; Tsutomu Ando; 勉安藤
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2000-01-28
Filing date: 2001-01-25
Publication date: 2001-11-02

Abstract

(57)【要約】【課題】様々な知的財産保護システムを施されたデジ
タルコンテンツの再生をシン・クライアントで達成でき
るデジタルコンテンツ配信システムを提供する。【解決手段】クライアント、デジタルコンテンツサー
バ、ローミングサーバ及びこれらの間を接続するネット
ワークを有して構成されるデジタルコンテンツ配信シス
テムにおいて、前記ローミングサーバは、デジタルコン
テンツサーバから知的財産保護システムが施されたデジ
タルコンテンツを受信し、前記受信したデジタルコンテ
ンツの知的財産保護システムを他の種類の知的財産保護
システムに変換し、クライアントへ配信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、デジタルコンテン
ツ配信システム、デジタルコンテンツ配信方法、情報変
換サーバ、情報処理装置、情報処理方法、記憶媒体及び
プログラムソフトウェアに関し、具体的には知的財産権
保護システムが施されたデジタルコンテンツのローミン
グサービスに関するものである。

【０００２】

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

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

【０００４】受信クライアント２０側は、デジタル映像
データを復号する変換部２１を有し、この変換部２１に
より受信に係るデジタル映像信号を再生し、デジタル映
像記憶装置２２に記録又は不図示の表示装置に表示す
る。

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

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

【０００７】尚、図２は「ISO/IEC SC29 14496-1 Fig.1
-1」に基づいて記載されたものであり、その詳しい説明
については、「ISO/IEC SC29 14496-1」において述べら
れている。ここでは、その概略についてのみ説明する。

【０００８】ネットワーク等を介して転送（transmissi
on）されたＭＰＥＧ−４ビットストリームやＤＶＤ−
ＲＡＭ等の記録メディア（strage medium）から読み出
されたＭＰＥＧ−４ビットストリームは、「TransMux
Layer」において、転送／読み出しに相当する手順に従
って受け取られ（sessionの確立）、「FlexMux」部にお
いて、シーン記述データ、オブジェクトデータ、オブジ
ェクト記述データの各ストリームに分離し、復号し、再
生され、シーン記述データ（scene description infor
mation）に基づいて、シーンが再生或いはグラフィック
処理される。

【０００９】図２では個々のオブジェクトについて著作
権保護の目的で認証が必要な場合の仕様は省略されてい
る。

【００１０】図３は、図２を模式化、簡略化したもので
ある。ここで、個々のオブジェクトについて著作権保護
等の目的で認証が必要となる場合、シーン記述データと
複数のオブジェクトデータとを含むビットストリームに
「IP Data Set」（知的財産権（例えば著作権）情報
群）を含ませることが考えられる。

【００１１】しかしながら、転送ビットストリームに
「IP Data Set」（知的財産権情報群）を含ませた場合
でも、図２若しくは図３に示す構成では、仮に「Object
Descriptors」において「IP Data」が再生されたとし
ても、画像の再生処理の際に「IP Data」についての処
理がなされないため、「IP Protection」（知的財産権
保護）処理が実行されることがない。

【００１２】もちろん、再生側においてデコードされた
「IP Data Set」をアプリケーションが受け取って「IP
Protection」処理を実行することは可能であるが、この
場合の処理はそのアプリケーションに固有の処理であ
り、他のプレーヤーや他の機種において同様の処理が実
行されるとは限らない。

【００１３】また、図２若しくは図３に示す構成では、
個々のオブジェクトに対して認証処理を行った後に画像
を再生するため、動画シーンを再生する際に次々と新し
いオブジェクトが出現する場合には、その度に再生を一
時的に停止して認証を求める必要が合った。

【００１４】図４は、図２、３に対して知的財産権（例
えば著作権）保護システム（IPMP System）とオブジェ
クトデータ処理フロー制御部（IPMP Stream Flow Contr
ol）を加えたＭＰＥＧ−４プレーヤーの場合を示してい
る。

【００１５】知的財産権保護を要求する画像オブジェク
ト符号化データを含むＭＰＥＧ−４ビットストリームは
Demux Layer２１で各々のオブジェクトデータに分割さ
れ、Sync Layer２２符号化やビットストリーム作成時に
加えられた時間刻印情報に従ってプレーヤー内部時間に
変換・同期される。

【００１６】一方、IPMP System２６は、Demux Layer２
１で分離された著作権保護情報に基づき、個々に分離さ
れた知的財産権保護を要求するオブジェクトデータの認
証処理を行い、IPMP Stream Flow Control２３へ許可信
号を渡してオブジェクトデータ処理フロー制御を行い、
Compression Layer２４にて各オブジェクト毎のデコー
ダで復号され、復号されたシーン記述にしたがってComp
osition Layer２５にてシーン合成を行い、表示する。

【００１７】特にオブジェクトデータ処理フロー制御方
法に幾つかの方法が考えられ、ここでは例としてTest C
ondition #1, #2の２つを挙げて解決しようとする問題
の説明をする。

【００１８】表１は、IPMP System (IPMPS)とStram Flo
w Controlの関係を示す例として、４つのテストプラン
を示した図である。

【００１９】

【表１】

【００２０】まず表１では、Unprotected Text Object
Streamを"t" と表現し、ProtectedAudio Streamを "S
₁(Ca)" と表現し、Protected Video Streamを "S₂(C
v)"と表現している。

【００２１】そして、S₁(Ca)用IPMP Systemを "IPMPS
1" と表現し、オリジナルの符号化データとASCII code
"x"とのXORを掛けたものを"S₁(Ca)"としている。従っ
て解読"key"はASCII code "x"で、解読は"key"との"XO
R"となる。

【００２２】また、S₂(Cv)用IPMP Systemを "IPMPS2"
と表現し、オリジナルの符号化データとASCII code "
a"とのXORを掛けたものを"S₂(Cv)"としている。従って
解読"key"はASCII code "a"で、解読は"key"との"XOR"
となる。

【００２３】尚、"Graceful Error"とはthe protected
object streamを正常に"key"で解読できなかったために
起こるデコーダ以降でのエラーで、いわゆる"fatal err
or"ではなく、例えばthe protectedビデオオブジェクト
ストリームの場合の考えられる"Graceful Error"は「表
示されない」、「乱れた画面が表示される」等である。

【００２４】表２は、IPMPのVerificationテストのコン
ディションとパラメータを示した図である。

【００２５】

【表２】

【００２６】この表において、テスト２を実行する場
合、Test Condition #1では各オブジェクトストリーム
にとって正常な"key"があらかじめIPMP System（IPMPS
1, IPMPS2）に在り、入ってきたオブジェクトストリー
ムを直ちに「解読」して各デコーダに出力する。

【００２７】また、テスト２を実行する場合、Test Con
dition #2は各オブジェクトストリームにとって正常な"
key"はあらかじめIPMP System（IPMPS1, IPMPS2）にな
く、外部からのキー入力やスマートカード挿入等のユー
ザーインタラクティブな方法で正常な"key"を入力し、
入ってきたオブジェクトストリームを「解読」して各デ
コーダに出力する。

【００２８】図５は、MPEG-4 System Playerの一例の内
部機能ブロックダイヤグラムとデータの流れを示してい
る。図５では同期メカニズムの説明のために簡略化した
ものでIPMP Systemとオブジェクトデータ処理フロー制
御は省略してある。

【００２９】まず、アプリケーションから起動されるMP
EG-4 System Playerの入り口関数、Execute()は各機能
モジュールを呼び起こし、データ領域バッファ確保や各
機能関数へのメモリ割付などを行い、データ処理の準備
をする。

【００３０】入力されるMPEG-4ビットストリームはDMIF
layerのService module関数としてのFlexDemux３１で
ネットワークからのパケットデータやデータファイルは
一連のデータ群として受け取られALManager３２機能ブ
ロックへ渡される。

【００３１】ALManager３２内部ではデータ群から各オ
ブジェクトデータ、例えばビデオデータ、オーディオデ
ータ、シーン記述データ等のデータの分割され、各デー
タチャネルとなってシーン記述やオブジェクト関連情報
データはBIFSDecoder３３へ、ビデオ、オーディオデー
タはDecoder３４へ渡される。

【００３２】BIFSDecoder３３及びDecoder３４で復号さ
れたシーン記述情報とビットストリーム作成時に加えら
れた時間刻印情報に応じてPresenter３５やMedia Strea
mデータ処理部（不図示）で、各復号Media Object data
(Video, Audio data)の時間関係を調整し、同期を取
り、シーン合成する。

【００３３】図６は、上記した一連のデータ処理プロセ
スを簡略化して示したものである。

【００３４】図６において、FlexDemux３１は、ＭＰＥ
Ｇ−４ビットストリームを受け取り、各オブジェクトデ
ータ毎のelementary stream(ES)に分ける。そしてALMan
ager３２は、各オブジェクトデータ毎のESをデコード単
位に分割し、BIFSDecoder３３及びDecoder３４は、各オ
ブジェクト毎の復号処理を行なう。そして、各オブジェ
クトデータ毎の復号されたデータ郡Media Streamが生成
され、Presenter３５は、Media Stream dataを扱う"Med
iaStreamImp::Fetch()"関数を用いて、個々のオブジェ
クトデータの時間調整を行い、各オブジェクトデータを
１シーン毎に合成し、表示する。

【００３５】図７は時間調整のデータ処理例を示す図で
ある。この図７を用いて、Presenter３５における時間
調整処理について詳しく説明する。

【００３６】まず、ステップＳ７１において、System P
layerの現在時間に許容値を加え（→dwCurrentTime）、
ステップＳ７２において処理予定データ（AU:Access Un
it）を得る。ステップＳ７３において、処理予定データ
（AU）の刻印時間情報（TimeStamp）をSystem Player時
間に換算し（→dwTime）、ステップＳ７４において、現
在時間(dwCurrentTime)と処理予定データ（AU）の刻印
時間（dwTime）とを比較する。

【００３７】処理予定データ（AU）の刻印時間（dwTim
e）が現在時間（dwCurrentTime）より後であれば、ステ
ップＳ７６に進み、実際のシーン合成処理を行い、処理
予定データ（AU）の刻印時間（dwTime）が現在時間（dw
CurrentTime）より前であれば、シーン合成に不適（時
間的にシーン合成時間に間に合わないデータと判断）と
して、ステップＳ７５に進み、次のデータ処理ブロック
（AU）を処理対象にする。

【００３８】図８は、図７に示した時間調整処理につい
て、タイムチャートで時系列に示したものである。

【００３９】図８において、Object stream(AU₀)は、Ar
rival(AU₀)の時点で、BIFSDecoder３３もしくはDecoder
３４のDecoding Buffer８１へ届き、その後デコードさ
れて、エンコード時に附加された刻印時間DTS(AU₀)の時
点で、Presenter３５のComposition Memory８２へ送ら
れ、シーン合成時間CTS(CU₀)の時点から、シーン合成さ
れる。

【００４０】そして続くobject stream(AU₁)も同様に、
DTS(AU₁)の時点でDecoding Buffetr８１からCompositio
n Memory８２へ移され、CTS(CU₁)からシーン合成され
る。

【００４１】このように、図８によれば、図７において
Decoding Buffer８１におけるDTSが、実際の現在時点dw
CurrentTime以降として、Composition Memory８２にお
ける実際のシーン合成時間CTSへと調整されていること
が分かる。

【００４２】図９は、図６に示した処理フローにIPMP S
ystemでの処理を加えたものである。具体的には、以下
のような処理を行う。

【００４３】FlexDenux３１がＭＰＥＧ−４ビットスト
リームを受け取り、各オブジェクトデータ毎のElementa
ry Stream(ES)に分け、ALManger３２が各オブジェクト
データ毎のESをデコード単に分割するところまでは、図
６と同様である。

【００４４】そして、次に、ALManager３２で分けられ
たオブジェクトデータから、特にIPMP関連情報に基づい
て、protected streamの特定し、正常"key"の入力・認
証等のIPMP System処理を行う。そして、BIFSDecoder３
３及びDecoder３４が、各オブジェクトデータ毎のデコ
ードするデータ郡であるMedia Streamを復号処理して、
Presenter３５が、個々のオブジェクトの時間調整を行
い、１シーン毎に合成し表示する。

【００４５】ここで、一例として表２に示したテスト２
を実行した場合におけるTest Condition #1と #2のオブ
ジェクトデータ処理フロー制御について説明する。

【００４６】まず、Test Condition #1の方法では、"ke
y"解読の時間は各IPMP System毎に一定の遅延としてデ
コーダへ伝えられるので、図４のComposition Layer２
４や、図５のPresenter３５で吸収される範囲であるよ
うに全体の遅延を見込んでおけば、結果として同期の問
題は起こらない。

【００４７】一方、Test Condition #2の方法では、以
下のようになる。

【００４８】図１０は、テスト２のTest Condition #2
で実行する場合のIPMP Systemの処理を説明したフロー
チャートである。

【００４９】まず、ステップＳ１０１において、ALMana
ger３２でデコード単位に分割された各オブジェクト毎
のストリームを得る。そして、ステップＳ１０２におい
て、正常な"key"入力があったか否かを判別する。そし
て正常な"key"入力ではなかった場合は、ステップＳ１
０３に進み、protected streamの解読をしないで、ＨＯ
ＬＤする。また、正常な"key"入力があった場合は、ス
テップＳ１０４に進み、protected streamの解読を行
い、次の処理へと進む。

【００５０】テスト２をTest Condition #2で実行する
場合に、図１０に示したフロー制御が行なわれる場合に
は、正常な"key"入力があるまでのストリームはsuspend
され、一方、non-protected streamや他の既に正常な"k
ey"入力で認証・解読されたストリームは次のデコード
処理、シーン合成のための時間同期処理へと移行する。
この際、先のsuspended streamが正常な"key"入力で認
証・解読され、次の処理へ移行するまでの経過時間は、
各protected streamへのユーザーインタラクティブな操
作のため、各々は一定でなく、また処理再開時点ではす
でにdwTimeがdwCurrentTimeを過ぎていることも考えら
れる。

【００５１】この場合、図７、図８から明らかなよう
に、再開されたストリームは少なくとも再開以降のdwTi
meがdwCurrentTimeより後となるまでデコード処理され
ず、次の処理所定データ（AU）までスキップし（即ち、
データが間引かれ）、スキップされた部分については、
シーン合成されることはない。

【００５２】ＭＰＥＧ−４オブジェクトへのIPMP情報は
国際標準仕様ISO/IEC SC29 IS 14496-1(System) 8.3.2.
5 IPMP message syntax and semanticsと図１１に示す
各オブジェクト毎のIPMP streamを特定するIPMP_Descri
ptorを用い、IPMP Message構造を持つことになってい
る。

【００５３】ISO/IEC SC29 IS 14496-1(System) 8.3.2.
5 IPMP message syntax and semanticsには以下のよう
に記載されている。

【００５４】 8.3.2.5 IPMP message syntax and semantics 8.3.2.5.1 Syntax class IPMP_Message()extends ExpandableBaseClass { bit(16) IPMPS_Type; if (IMPMS_Type == 0){ bit(8) URLString[sizeOfClass-2]; }else{ bit(8) IPMP_data[sizeOfClass-2]; } } 8.3.2.5.2 Semantics The IPMP_Massage conveys control information for an IPMP System. IPMPS_Type-the type of the IPMP System. A zero value does not corr espond to an IPMP System, but indicates the presence of a URL. A Registr ation Authority as designated by the ISO shall assign valid values for t his field. URLString[]-contains a UTF-8[3]encoded URL that shall point to the location of a remote IPMP_Massage whose IPMP_data shall be used in plac e of locally provided data. IPMP_data-opaque data to control the IPMP System. ここで重要なことはISO標準準拠IPMP Systemを利用する
場合は使用するIPMP SystemはRegistration Authority
へ登録し、unique IDを持っている、ということであ
る。

【００５５】標準仕様ではID番号の０番は外部URL先のI
PMP Systemを示し、１〜２０００ｈ（１６進数）はISO
Reserve、２００１ｈ〜ｆｆｆｆｈがRegistration Auth
orityのID番号となる予定である。

【００５６】図１２(Case 1)では具体例としてクライア
ント・ユーザーＡがサーバーＢにあるIPMPS_Type 2001h
のIPMP情報を持つＭＰＥＧ−４コンテンツやオブジェク
トを入手し、再生する場合を示す。

【００５７】ユーザーの再生する装置があらかじめIPMP
S_Type 2001hを持つ場合は、すでに述べたようなユーザ
ー認証を経て、ユーザーの持つKey情報で暗号解除等が
行われ、正常に再生される。

【００５８】一方、図１３(Case 2)に見られるように、
ユーザーＡが更にサーバーＣからIPMPS_Type 2021hによ
るIPMP情報を持つＭＰＥＧ−４コンテンツやオブジェク
トを入手し、再生しようとした場合はIPMPS_Type 2021h
のIPMP Systemを入手し、再生する必要がある。このと
きの課題としては以下の３点がある。１．すでに持って
いるユーザーＡの装置（IPMPS_Type 2001hに対応する装
置）でIPMPS_Typeの異なるIPMP Systemを入手出来る
か。→IPMP Systemの共通プラットフォームが必要であ
る。２．一つのＭＰＥＧ−４コンテンツが異なるIPMPS_
TypeのIPMP System情報を持つマルチオブジェクト構成
だった場合、コンテンツ再生のためにはオブジェクト毎
に必要なIPMP Systemが必要となるが、装置のメモリー
量や処理速度などの物理条件が十分対応するか。→複数
の異なるIPMP Systemを動作できる装置かどうかをユー
ザーは知らなければならない。３．異なるIPMP System
毎へユーザー認証が必要なので場合によってはリアルタ
イム処理等のオブジェクト間の同期の問題が心配。→コ
ンテンツのオブジェクト構成と認証方法に依存するため
特定できない。

【００５９】図１３(Case 2)を想定し、特に上記課題１
を考慮しOPIMAという共通プラットフォームとAPI（アプ
リケーションインターフェース）仕様提案がコンソーシ
アムレベルで提案されている。

【００６０】異なる装置、アプリケーションシステムに
対するOPIMAカーネルの実装は２．及び３．の課題を持
ち、問題が残されている。例えば、携帯電話のような限
られたスペースでの実装メモリー量、バッテリー量、CP
Uパワーなどからコンテンツを構成するオブジェクト毎
に異なるIPMP Systemを複数同時に持ち、処理すること
は現実には困難である。

【００６１】一方、全てのIPMP Systemを一つに統一
し、標準化することはIPMPのようなセキュリティシステ
ムにおいては、ハッカー等の違法行為によりセキュリテ
ィを無効化された場合、content(or object) right hol
derの被る被害は大きく、新たな標準IPMP Systemを定め
るまでの時間とその新標準仕様準拠製品が出るまでの時
間は、世界標準的な仕様の策定の場合には各国代表投票
手順等もあり、会社レベルや業界レベルに比べ時間がか
かると予想される。

【００６２】上述したような背景から本願発明の一つの
目的は、様々な種類の知的財産権（例えば著作権）保護
システムが存在してもコンテンツの供給を受けるユーザ
ー側に対して複雑な手続処理を行わせることなく、また
コンテンツの知的財産権を守りながらコンテンツの再生
を可能にし、またコンテンツ供給側の知的財産権システ
ムのユーザーに対するinteroperabilityを得ることを可
能にするデジタルコンテンツ配信システム、デジタルコ
ンテンツ配信方法、情報変換サーバ、情報処理装置及び
情報処理方法を提供することを目的としている。

【００６３】

【課題を解決するための手段】上記目的を達成するため
の本発明によるデジタルコンテンツ配信システムは、ク
ライアント、デジタルコンテンツサーバ、情報変換サー
バ及びこれらの間を接続するネットワークを有して構成
されるデジタルコンテンツ配信システムにおいて、前記
情報変換サーバは、デジタルコンテンツサーバから知的
財産保護システムが施されたデジタルコンテンツを受信
する手段と、前記受信したデジタルコンテンツの知的財
産保護システムを他の種類の知的財産保護システムに変
換し、クライアントへ配信する手段とを有することを特
徴とする。

【００６４】また、上記目的を達成するために本発明の
他の態様によるデジタルコンテンツ配信システムは、ク
ライアント、情報変換サーバ及びこれらの間を接続する
ネットワークを有して構成されるデジタルコンテンツ配
信システムにおいて、前記情報変換サーバは、前記クラ
イアントから知的財産保護システムが施されたデジタル
コンテンツを受信する手段と、前記受信したデジタルコ
ンテンツの知的財産保護システムを他の種類の知的財産
保護システムに変換し、前記クライアントへ配信する手
段とを有することを特徴とする。

【００６５】また、上記目的を達成するために本発明の
他の態様による情報変換サーバは、クライアント、デジ
タルコンテンツサーバとネットワークを介して接続され
る情報変換サーバであって、前記デジタルコンテンツサ
ーバから知的財産保護システムが施されたデジタルコン
テンツを受信する受信手段と、前記受信したデジタルコ
ンテンツの知的財産保護システムを他の種類の知的財産
保護システムに変換する変換手段と、前記変換手段によ
り変換されたデジタルコンテンツを前記クライアントに
配信する配信手段とを有することを特徴とする。

【００６６】また、上記目的を達成するために本発明の
他の態様による情報変換サーバは、クライアントとネッ
トワークを介して接続される情報変換サーバであって、
前記クライアントから知的財産保護システムが施された
デジタルコンテンツを受信する受信手段と、前記受信し
たデジタルコンテンツの知的財産保護システムを他の種
類の知的財産保護システムに変換する変換手段と、前記
変換手段により変換されたデジタルコンテンツを前記ク
ライアントに配信する配信手段とを有することを特徴と
する。

【００６７】また、上記目的を達成するために本発明の
他の態様によるデジタルコンテンツ配信方法は、クライ
アント、デジタルコンテンツサーバ、情報変換サーバ及
びこれらの間を接続するネットワークを有して構成され
るシステムにおけるデジタルコンテンツ配信方法であっ
て、前記情報変換サーバは、デジタルコンテンツサーバ
から知的財産保護システムが施されたデジタルコンテン
ツを受信し、前記受信したデジタルコンテンツの知的財
産保護システムを他の種類の知的財産保護システムに変
換し、クライアントへ配信することを特徴とする。

【００６８】また、上記目的を達成するために本発明の
他の態様によるデジタルコンテンツ配信方法は、クライ
アント、情報変換サーバ及びこれらの間を接続するネッ
トワークを有して構成されるシステムにおけるデジタル
配信方法であって、前記情報変換サーバは、前記クライ
アントから知的財産保護システムが施されたデジタルコ
ンテンツを受信し、前記受信したデジタルコンテンツの
知的財産保護システムを他の種類の知的財産保護システ
ムに変換し、前記クライアントへ配信することを特徴と
する。

【００６９】また、上記目的を達成するために本発明の
他の態様によるデジタルコンテンツ配信方法は、クライ
アント、デジタルコンテンツサーバとネットワークを介
して接続される情報変換サーバのデジタルコンテンツ配
信方法であって、前記デジタルコンテンツサーバから所
定の知的財産保護システムが施されたデジタルコンテン
ツを受信し、前記受信したデジタルコンテンツの知的財
産保護システムを他の種類の知的財産保護システムに変
換し、前記変換されたデジタルコンテンツを前記クライ
アントに配信することを特徴とする。

【００７０】また、上記目的を達成するために本発明の
他の態様によるデジタルコンテンツ配信方法は、クライ
アントとネットワークを介して接続される情報変換サー
バのデジタルコンテンツ配信方法であって、前記クライ
アントから知的財産保護システムが施されたデジタルコ
ンテンツを受信し、前記受信したデジタルコンテンツの
知的財産保護システムを他の種類の知的財産保護システ
ムに変換し、前記変換されたデジタルコンテンツを前記
クライアントに配信することを有することを特徴とす
る。

【００７１】また、上記目的を達成するために本発明の
他の態様による情報処理装置は、ネットワークを介して
外部装置と接続可能な情報処理装置であって、本装置
が対応する知的財産保護システムの情報と本装置を特定
する特定情報とを前記外部装置へ前記ネットワークを介
して送信する送信手段と、前記知的財産保護システムが
施されたデジタルコンテンツを前記外部装置から前記ネ
ットワークを介して受信する受信手段とを有することを
特徴とする。

【００７２】また、上記目的を達成するために本発明の
他の態様による情報処理方法は、ネットワークを介して
外部装置と接続可能な情報処理装置の情報処理方法であ
って、前記情報処理装置が対応する知的財産保護シス
テムの情報と前記情報処理装置を特定する特定情報とを
前記外部装置へ前記ネットワークを介して送信し、前記
知的財産保護システムが施されたデジタルコンテンツを
前記外部装置から前記ネットワークを介して受信するこ
とを特徴とする。

【００７３】

【発明の実施の形態】＜実施例１＞図１４は、本発明に
かかわる実施例１のIPMP Systemのローミングシステム
を説明する図である。

【００７４】いわゆるオフライン処理に相当し、ユーザ
ーはコンテンツやオブジェクトデータを入手するため個
々のコンテンツ・オブジェクトデータ配信サーバーへ依
頼し、ユーザー認証等の正規手順後公開キー情報やパス
ワードパラメータ等とデータを入手した後、ユーザーＡ
が再生に必要なIPMP System情報変換をIPMP System Roa
ming Serviceプロバイダー（以下、Roaming Serviceプ
ロバイダーと称す）へ依頼する。以下に具体的に手順を
説明する。：ユーザーＡ(Type2001h IPMP System保有)がサーバ
ーＢ（Type2001h IPMPSystem）とサーバーＣ（Type2021
h IPMP System）からコンテンツやコンテンツのオブジ
ェクトデータを入手し、必要な金額を支払い、ユーザー
認証手続きを行って暗号解読の為のキーやパスワードパ
ラメータ等のIPMP情報を受け取る。：ユーザーＡの装置には再生に必要な暗号解除用Type
2021h IPMP Systemが無い為、再生できない。そこでユ
ーザーＡはRoaming ServiceプロバイダへIPMP System情
報変換を依頼する。：Roaming Serviceプロバイダー側で変換要求コンテ
ンツorオブジェクトIPMPSystem TypeをユーザーＡのIPM
P System Typeへ変換できる場合、ユーザーＡへ必要な
金額を要求し、双方の条件成立の後IPMP System情報をT
ype2001h用へ変換する。：Roaming Serviceプロバイダーは、IPMP System情報
が変換されたデータをユーザーＡに戻す。（通常再度こ
の時要求したユーザーであることの認証確認が行われ
る。）＜実施例２＞図１５は、本発明にかかわる実施例２のIP
MP Systemのローミングシステムを説明する図である。
本実施例ではユーザー認証の代行サービスも行う例を示
す。

【００７５】ユーザーＡはIPMP System Roaming Servic
eプロバイダー（以下、Roming Serviceプロバイダーと
称す）へ入手したいコンテンツ・オブジェクトの入手を
一括依頼する。Roaming Serviceプロバイダーはユーザ
ーを代行し、各コンテンツorオブジェクト配信サーバー
との認証・課金処理を行う。Roaming Serviceプロバイ
ダーはデータとキーやパスワードなどを入手した後、ユ
ーザーＡのIPMP System情報へ変換してユーザーＡへ提
供する。以下に具体的に手順を説明する。：ユーザーＡは、Roaming Serviceプロバイダーへ必
要なコンテンツやオブジェクトの入手とユーザーＡの持
つType2001h IPMP SystemへのIPMP情報変換を依頼す
る。：Roaming Serviceプロバイダーは、ユーザーＡから
の要求に従い、サーバーＢ（Type2001h IPMP System）
とサーバーＣ（Type2021h IPMP System）へ正規手順に
て必要な金額を支払ったり、ユーザー認証手続きを行
い、コンテンツやオブジェクトデータを入手し、暗号解
読の為のキーやパスワードパラメータ等を受け取る。：Roaming Serviceプロバイダーは、ユーザーＡのTyp
e2001h IPMP Systemでの再生に必要な暗号解除が可能と
なるようにIPMP情報変換を行う。：Roaming Serviceプロバイダーは依頼されたユーザ
ーＡとの認証を行う。：Roaming ServiceプロバイダーはユーザーＡにIPMP
情報変換したデータを渡す。

【００７６】図１６は、図１５におけるクライアント
（図１５のユーザーＡに相当）、コンテンツサーバ（図
１５のサーバーＢ或いはサーバーＣに相当）、Roaming
Serviceサーバ間でのデータ通信の工程を示した図であ
る。

【００７７】図１６において、まず、クライアントがRo
aming Serviceサーバにコンテンツ配信要求を発する
（ステップ１６０１）。

【００７８】次に、Roaming Serviceサーバ側がユーザ
の認証作業を行う（ステップ１６０２）。尚、ユーザ認
証の方式については特に言及しない。

【００７９】次に、コンテンツにかけられているセキュ
リティシステムのタイプ（IPMP System Type）をクライ
アントに送信する（ステップ１６０３）。このとき、セ
キュリティのタイプは、前述したRAによってすでに登録
されているものとする。

【００８０】次に、クライアントにて、コンテンツサー
バから送られてきたセキュリティシステムがクライアン
トのプレイヤーのセキュリティタイプと合致するか（プ
レイヤでセキュリティシステムが解除可能）を検査する
（ステップ１６０５）。

【００８１】もし、ステップ１６０５においてセキュリ
ティシステムタイプが合致した場合には、クライアント
からRoaming Serviceサーバに対してコンテンツ配信依
頼が発行される。依頼を受けたRoaming Serviceサーバ
は、コンテンツサーバに対してこの依頼を伝達する。こ
のとき同時に、ユーザの認証データと、Roaming Servic
eサーバ自身の正当性を認証するための電子証明書が発
行・伝送される（ステップ１６０４）。

【００８２】コンテンツサーバはRoaming Serviceサー
バの正当性を認証し（ステップ１６０８）、もし正当だ
と認証された場合は、コンテンツサーバからコンテンツ
を配信する（ステップ１６１３）。

【００８３】クライアントは、セキュリティを解除し適
宜圧縮されたメディアデータの復号動作などを行い（ス
テップ１６１５）、表示・再生を行う（ステップ１６１
６）。

【００８４】一方、セキュリティシステムタイプが合致
しない場合は、クライアントからローミングサーバに対
してクライアントのサポートしているセキュリティシス
テムのタイプを伝送する（ステップ１６０６）。

【００８５】次に、Roaming Serviceサーバは、しかる
べきコンテンツサーバに、Roaming Serviceサーバに対
してのコンテンツの１次配信を依頼する（ステップ１６
０７）。このとき電子証明書・ユーザの認証データなど
を添付する。依頼を受けたコンテンツサーバは、Roamin
g Serviceサーバの正当性を認証（ステップ１６０９）
したのち、Roaming Serviceサーバにコンテンツを配信
する（ステップ１６１０）。

【００８６】次に、Roaming Serviceサーバにおいて、
コンテンツを受信し、コンテンツプロバイダから供給さ
れたセキュリティ情報を用い、コンテンツのセキュリテ
ィを解除する。その後、セキュリティ方式の方式変換を
行う（ステップ１６１１）。

【００８７】この変換処理は、具体的には暗号などの手
法によってセキュリティがかけられているコンテンツに
おいて、コンテンツサーバからの情報によって暗号を解
読し、クライアントが利用可能な異なった暗号方式を採
用し再び暗号化したり、あるいは暗号解読後、透かし合
成等を行い知的財産権（例えば著作権）を提示するとい
った方法も考えられるが、具体的な処理については特記
しない。この処理後、Roaming Serviceサーバからクラ
イアントへの送信が行われる（ステップ１６１２）。

【００８８】クライアントでは、Roaming Serviceサー
バから送信されるコンテンツを受信後、Roaming Servic
eサーバから同時に送信されるセキュリティ解除情報を
使用して、コンテンツを解読する。あるいは、電子透か
しなどが付加されている場合は、それを除去する。ビデ
オなどのコンテンツは通常圧縮された形で伝送されるの
で、適宜復号化を行い（ステップ１６１５）、再生・表
示を行う（ステップ１６１６）。

【００８９】＜実施例３＞図１７は、本発明にかかわる
実施例３のIPMP Systemのローミングシステムを説明す
る図である。コンテンツプロバイダからRoaming Servic
eを要求する例である。：ユーザーＡはサーバーＢへコンテンツやオブジェク
トの入手を正規手続きで依頼する。：サーバーＢはユーザーの持つIPMP System Typeを確
認し、異なる場合にIPMPSystem Roaming Serviceプロバ
イダ（以下、Roaming Serviceプロバイダと称す）へ正
規手続きでIPMP情報交換を依頼し、必要なデータを渡
す。：Roaming ServiceプロバイダはサーバーＢからの変
換要求に応じて、ユーザーＡのType 2001h IPMP System
での再生に必要な暗号解除が可能となるようにIPMP情報
変換を行う。：IPMP情報変換したデータを渡す。

【００９０】図１８は、図１７におけるクライアント
（図１７のユーザーＡに相当）、コンテンツサーバ（図
１７のサーバーＢに相当）、Roaming Serviceサーバ間
でのデータ通信の工程を示した図である。

【００９１】本例では、図１６がRoaming Serviceサー
バに対してクライアントが要求を送信していたのに対し
て、コンテンツサーバに直に要求を送信したときの例で
ある。

【００９２】まずクライアントがコンテンツサーバにコ
ンテンツ配信要求を発する（ステップ１８０１）。

【００９３】次に、コンテンツサーバ側がユーザの認証
作業を行う（ステップ１８０２）。ユーザ認証の方式に
ついては特に言及しない。

【００９４】次に、コンテンツにかけられているセキュ
リティシステムのタイプ(IPMP System Type)をクライア
ントに送信する（ステップ１８０３）。

【００９５】このとき、セキュリティのタイプは、前述
したRAによってすでに登録されているものとする。次に
クライアントにて、コンテンツサーバから送られてきた
セキュリティシステムがクライアントのプレイヤのセキ
ュリティタイプと合致するか（プレイヤでセキュリティ
システムが解除可能）を検査する（ステップ１８０
５）。

【００９６】もし、ステップ１８０５でセキュリティタ
イプが合致した場合には、コンテンツサーバからコンテ
ンツを配信し（ステップ１８０４）、クライアントにて
セキュリティを解除し適宜圧縮されたメディアデータの
復号動作などを行い（ステップ１８１４）、表示・再生
を行う（ステップ１８１５）。

【００９７】一方、ステップ１８０５でセキュリティシ
ステムタイプが合致しない場合は、コンテンツサーバに
対してクライアントのサポートしているセキュリティシ
ステムのタイプを伝送する（ステップ１８０６）。

【００９８】次に、コンテンツサーバは、しかるべきRo
aming Serviceサーバに、セキュリティの変換作業を依
頼する（ステップ１８０７）。

【００９９】コンテンツサーバとRoaming Serviceサー
バ間では、その正当性を立証するための通信が行われ
る。ここでは電子証明書を用いた方式で説明する。

【０１００】依頼を受けたRoaming Serviceサーバは、
その正当性を示すために、あらかじめ取得しておいた電
子証明書をコンテンツサーバに対して送信する（ステッ
プ１８０８）。

【０１０１】上記電子証明書を受信したコンテンツサー
バは、証明書を確認しRoaming Serviceサーバの正当性
を検証（ステップ１８０９）したのち、コンテンツをRo
amingServiceサーバに送信する（ステップ１８１１）。

【０１０２】次に、Roaming Serviceサーバにおいて、
セキュリティ方式の変換（トランスコンバート）を行う
（ステップ１８１２）。具体的には、暗号などの手法に
よってセキュリティがかけられているコンテンツにおい
て、コンテンツサーバからの情報によって暗号を解読
し、クライアントが利用可能な異なった暗号方式を採用
し再び暗号化したり、あるいは暗号解読後、電子透かし
合成等を行い著作権を提示するといった方法も考えられ
るが、具体的な処理については特記しない。

【０１０３】処理後、Roaming Serviceサーバからクラ
イアントへコンテンツの送信が行われる（ステップ１８
１３）。クライアントでは、Roaming Serviceサーバか
ら送信されるコンテンツを受信後、Roaming Serviceサ
ーバから同時に送信されるセキュリティ解除情報を使用
して、コンテンツを解読する。あるいは、電子透かしな
どが付加されている場合は、それを除去する。ビデオな
どのコンテンツは通常圧縮された形で伝送されるので、
適宜復号化を行い（ステップ１８１４）、再生・表示を
行う（ステップ１８１５）。

【０１０４】＜実施例４＞図１９は、本発明にかかわる
実施例４のIPMP Systemのローミングシステムを説明す
る図である。本実施例では図１４、図１５などの例でユ
ーザーＡとRoaming Serviceプロバイダとの間で前述の
従来例で述べたOPIMA VMを持った場合の応用例である。

【０１０５】本実施例では互いにOPIMA VMにおいて異な
るIPMP System間で生じる問題（上記課題２、３）を解
消し、他の情報のやり取りなどの自動化などに有効利用
できるようになる。

【０１０６】図１９において、５１はIPMPS-Type 2000
のＭＰＥＧ−４コンテンツ・サーバー、５２はIPMPS-Ty
pe 2001のＭＰＥＧ−４コンテンツ・サーバー、５３はI
PMPS-Type 2002のＭＰＥＧ−４コンテンツ・サーバーで
ある。５４はネットワーク、５５はIPMP System Roamin
g Serviceサーバー（以下、Roaming Service サー
バ）、５６はＭＰＥＧ−４プレーヤーである。

【０１０７】ＭＰＥＧ−４プレーヤー５６と、Roaming
Serviceサーバ５５は、互いにOPIMAモデルのプロトコル
をサポートする。

【０１０８】いま、ＭＰＥＧ−４プレーヤー５６がRoam
ing Serviceサーバ５５に対してコンテンツの配信を要
求した場合、Roaming Serviceサーバ５５は、そのコン
テンツを保有するコンテンツ・サーバー５１、５２また
は５３にデーターのダウンロードを要求する。

【０１０９】例えばそのコンテンツはサーバー５２の中
にあったとする。

【０１１０】この場合、ユーザー認証はRoaming Servic
eサーバ５５とプレーヤー５６との間で成されるが、同
時にコンテンツ・サーバー５３とRoaming Serviceサー
バ５５との間でも行われても良い。

【０１１１】すると、コンテンツがサーバー５２からネ
ットワーク５４を介してRoaming Serviceサーバ５５に
ダウンロードされる。その手順は、上記の実施例で説明
した手順でも良く、また、OPIMA方式であっても良い。
ここでは、OPIMA方式でないものとする。

【０１１２】一方、Roaming Serviceサーバ５５とプレ
ーヤー５６との間は、OPIMA方式を採用する。ＭＰＥＧ
−4プレーヤーが、初め、 Type 2000のIPMP Systemしか
持っていなかった場合、プレーヤー５６は、Type 2001
のIPMP SystemのダウンロードをRoaming Serviceサーバ
５５に要求する。Roaming Serviceサーバ５５は、殆ど
全てのコンテンツ・サーバーのIPMP Systemを持ってい
るので、それをそのまま端末５６に伝送すれば良い。即
ち、Type 2001のIPMP Systemをダウンロードする。

【０１１３】Type 2001の IPMP Systemのダウンロード
が完了したら、プレーヤー５６はIPMP Systemを Type 2
000からType 2002に切り替え、互換性のあるS-Typeでエ
ンドツーエンドの通信ができる。

【０１１４】実施例４により、データ配信に遅延が発生
せず、リアルタイム性を維持できる。

【０１１５】＜上記実施例のサービスを実現する具体的
Service Request仕様例＞図２０では本件のサービスを
実行する場合のユーザーやコンテンツプロバイダがIPMP
情報交換サービス要求する際の基本的共通情報を例示し
ている。

【０１１６】コンテンツorオブジェクトがMPEG-4 IPMP
情報を持つ場合には図１２で示したように、図２０に図
示した国際標準仕様に記載された「IPMP Message」デー
タ構造を持っている。このデータの先頭にRegistration
Authority登録されたuniqueなIPMP System IDが含まれ
るので、ユーザーＡが入手したコンテンツorオブジェク
トデータのセキュリティがType何番のIPMP Systemかを
知ることが出来る。

【０１１７】一方、Roaming Serviceプロバイダは、１）変換要求したユーザーＡの持つIPMP System Typeを
知る必要があること２）変換後のデータを返す為にユーザーＡの持つ再生装
置を特定する必要があること（例えばユーザーＡの持つ
再生装置を特定する情報としてInternet Protocol addr
ess(IP_address)等を使用することができる）３）変換を要求されたデータ自身か又はデータの入手先
情報、の３点は最低限必要となる。

【０１１８】このようなRoaming Serviceに必要な事項
はIPMP System Typeによらず共通しており、ユーザーＡ
やRoaming Serviceプロバイダーに共通した情報であ
る。

【０１１９】そこでサービス要求時にRoaming Service
プロバイダーが異なってもサービスが受けられる為に、
図２０で図示・提案されているdata構造をback channel
経由で交換できれば、よりスムーズなRoaming Service
が世界標準的規模で得られることが可能となる。

【０１２０】Roaming Service Requestを図２０の提案
する(Roaming Service Syntax)データ構造で伝える手段
として、より標準的手法は通常使用ではdownstream処理
（MPEG-4 bitstreamを受け取りシーン再生処理する）の
Player側から図２０に示されるUpchannel information
としてRoaming Service Request情報をUpstream処理
（いわゆるMPEG-4でのback channel機能を使い、player
側からサーバー側へ情報を配信する機能）するためにプ
レイヤからストリームを返すためのフラブ仕様があり本
実施例ではこの機能を使って例示している。

【０１２１】ここで、本発明にかかわるback channel実
施の形態を図面を参照しながら説明する。

【０１２２】図２１は、本発明の好適な実施の形態に係
るＭＰＥＧ−４プレーヤーを含むシステムの概略構成を
示す図である。図２１に示すシステムは、「IP Data Se
t」を操作して「IP Protection 」を実現するシステム
である。図２１に示すシステムは、ＩＰＭＰＳ（Intell
ectual Property Management and Protection System）
２０７を有し、このＩＰＭＰＳ２０７により著作権認証
及び保護機能を実現する点で図３に示すシステムと異な
る。

【０１２３】図２２は、認証処理に関するクライアント
の動作を示すフローチャートである。以下、図２２を参
照しながら図２１に示すシステムの動作を説明する。

【０１２４】サーバー側では、マルチプレクサ２０１
が、各々異なるＵＲＬ（Uniform Resource Locator）と
してＵＲＬ_１、ＵＲＬ_２、ＵＲＬ_３を持つ複数のネット
ワーク・サイト２０１〜２０４から、夫々個々のオブジ
ェクトを受信してこれらの複数のオブジェクトで構成さ
れる動画データを生成する。この動画データは、クライ
アントからの要求に応じてＭＰＥＧ−４ビットストリー
ム２０５としてネットワークを介してクライアントに送
信される。

【０１２５】ステップＳ１では、クライアントは、サー
バーよりＭＰＥＧ−４ビットストリーム２０５を受信す
る。このＭＰＥＧ−４ビットストリームを構成する各オ
ブジェクトには、著作権の帰属先を示す情報（ここで
は、ＵＲＬの情報）が付随している。

【０１２６】ステップＳ２では、クライアントは、受信
に係るＭＰＥＧ−４ビートストリームをデマルチプレク
サ２０６により複数のオブジェクトやそれに付随する情
報（ＵＲＬの情報を含む）等の複数のストリームに分離
する。ここで、各オブジェクトに付随するＵＲＬの情報
は、「IP Data」のストリームである「IPMP Stream」の
一部としてＩＰＭＰＳ２０７に送られる。

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

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

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

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

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

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

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

【０１３４】以下、上述した認証処理について更に詳細
に説明する。

【０１３５】ＭＰＥＧ−４ビットストリームは、オブジ
ェクト単位のビットストリームである「Elementary Str
eam」（ES）の内容を記述する「ES_Descriptor」と、オ
ブジェクト自身を記述する「OD_Descriptor」を含む。
ここで、「ES_Descriptor」或いは「OD_Descriptor」
に、リモートアクセスのためのコマンドとアクセス先を
指定するＵＲＬの情報が含まれている場合は、図２３に
示すような手順でリモートアクセスが実行される。

【０１３６】図２３は、リモートアクセスを説明する簡
略図である。

【０１３７】図２３において、「DAI」は、「DMIF Appl
ication Interface」と呼ばれる、ＭＰＥＧ−４ビット
ストリームとネットワークとのインターフェース層であ
る。この詳細については、「ISO／IEC 14496-6 DMIFド
キュメントDMIF ApplicationInterface」の項に記載さ
れているため、ここでは省略する。

【０１３８】また、ＭＰＥＧ−４ビットストリームは、
「elementary stream」（ES）に対応したデコーダの種
類についての情報を示す「DecoderConfigDescriptor」
を含む。この「DecoderConfigDescriptor」は、幾つか
のデータ要素の構造体であり、その中の要素の一つにス
トリーム型を示す１ビットのupStreamパラメータがあ
る。この詳細については、「ISO/IEC 14496-1 FCD 8.3.
4DecoderConfigDescriptor」の項に記載されているた
め、ここでは省略する。

【０１３９】式１に、「DecoderConfigDescriptor」の
一例を挙げる。［式１：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[]; } ここで、ストリームの識別は、式１の「DecoderConfigD
escriptor」のクラス宣言中のデータ要素である「strea
mType」の値に基づいて行う。「streamType」の値は、
表３のように定義されている。

【０１４０】

【表３】

【０１４１】なお、表３は、「ISO/IEC 14496-1 FCD Ta
ble 0-1：streamType Values」に対して、この実施の形
態に固有の「IPMPStream」を識別するための値を追加し
たものである。表３において、各パラメータや用語は、
「ISO/IEC 14496-1 FCD」と同じであるので、ここでは
説明を省略する。

【０１４２】図２１に示すように、ストリームの向きを
示すフラグである「DecoderConfigDescriptor. upStrea
m」が ”１”の時は、システムは、クライアント側か
らサーバ側にストリームを転送する「upstream」の状態
になる。ここでは、この「upstream」の状態を利用した
転送機能を「back-channel 1」と呼ぶことにする。

【０１４３】通常の再生時は、「DecorderConfigDescri
ptor.upStream」が”０”であり、サーバ側からクライ
アント側にストリームを転送する「downstream」の状態
である。一方、オブジェクトに対するアクセスの許可を
求める場合は、「DecorderConfigDescriptor．upStrea
m」を”１”として、必要なデータをＵＲＬ先へ「upstr
eam」する所謂「back-channel 1」を用いることによ
り、「IPMP Management Data」（知的財産権権管理情
報）を「IPMPStream」としてサーバ側に送り、リモート
アクセスによりＵＲＬ先から応答データを転送させるこ
とになる。

【０１４４】表３に示す「IPMPStream」は、「IPMP_E
S」と「IPMP_D」の構成を有する。「IPMPS_ES」の各々
は一連の「IPMP_Messages」からなる。

【０１４５】式２は「IPMP_Messages」の記述例であ
る。 [式2: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]]; } } 式２において、「IPMPS_TypeCount」は、異なる「IPMPS
type」の数を表わす。これにより、異なるＩＰＭＰＳ
を存在させることが可能となるため、「IPMPmessages」
は複数のＩＰＭＰＳに対応可能である。

【０１４６】なお、ＵＲＬが指定されている場合は、
「IPMPS_TypeCount」は０を取り、その他は最低値であ
る１を取る。また、この場合、内部の「IPMP_Message」
の代わりに、外部に格納されている「IPMP_Message」を
参照して使用することになる。

【０１４７】また、「IPMPS_D」は、「IPMP Descripto
r」からなる。この「IPMP Descriptor」は、個々の「el
ementary streams」に対する詳細なＩＰＭＰ制御を行う
ためのデータ構造体である。そして、「IPMP Descripto
r Updates」は、オブジェクト・ディスクリプタ・ス
トリーム（Object Descriptor stream）の一部として実
行される。式３は、「IPMP Descriptor Updates」の記
述例を示す。 [式3: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]]; } } 式３において、「descriptorCount」は、更新される「I
PMP_Descriptors」の数を表わし、また、ｄ［ｉ］
は、ある一つの「IPMP_Descriptor」を表わす。

【０１４８】式４は、「IPMP_Descriptor」の記述例を
示す。 [式4: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]]; } } 式４において、「IPMP_Descriptor_ID」は、各「IPMP_D
escriptor」に固有の番号であり、「ES_Descriptors」
は、「IPMP_Descriptor_ID」を使って「IPMP_Descriptor
s」を参照する。また、「IPMPS_TypeCount」は、「IPMP_M
essage」で指定された異なるＩＰＭＰＳの数を表わす。

【０１４９】図２４は、ＵＲＬ先で更にＵＲＬ指定があ
る場合の階層構造の例を示す図である。なお、図２４に
２階層の場合の例であるが、もちろん、更なるＵＲＬ指
定がある場合、３階層になっても４階層になってもよ
い。また、図２４においては、「IPMPStream」を明示し
ていないが、リモート指定されるオブジェクト（Objec
t）に関する「IPMP_ES」か「IPMP_D」が、「SceneDescrip
tionStream」か「ObjectDescriptionStream」に呼応し
て、必要に応じデコードされ、リモートアクセスされる
ことは、先に説明した図２３の場合と同様である。

【０１５０】以上、ＭＰＥＧ−４のビットストリームの
「upstream」の状態、即ち、バックチャネル（back-cha
nnel）１を使用した認証処理について説明したが、この
ような「back-channel 1」を使用する認証処理は、リア
ルタイムのビットストリーム再生時における「upStrea
m」処理であるので、比較的データ量が少なく処理時間
の短い高速処理向けの場合を想定している。ここで、リ
アルタイム再生をしているシステムでは、「back-chann
el 1」によるリモートアクセス及び認証による遅延は極
力少ないことが望ましい。

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

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

【０１５３】まず、「back-channel 2」を使用した認証
処理を説明する前に、「back-channel 1」と「back-chan
nel 2」におけるデータ量と遅延時間の関係を考える。
「MPEG-4 Requirement Group」の報告では、リアルタイ
ム再生を妨げない「back-channel」の遅延許容時間は１
フレーム時間とあるので、これに基づいて「back-chann
el １」と「back-channel 2」における想定データ量と
転送レートの関係を求めると、表４のようになる。

【０１５４】

【表４】

【０１５５】ここで、認証のための高速ＩＰＭＰリモー
トアクセスでは、１００−５００bit/frame以内のデー
タ量を３K−５K/secの転送ラインで処理することが遅延
時間の限界となる。「IPMP_Message」データや「IPMP_D
escriptor」データとＵＲＬ指定による「back-channel」
による「remote content access」の結果としてのdelay
-bandwidthの関係を、表４と見ることができるので、実
際の認証のためのデータ量は限られたものになる。一
方、認証には、stream処理とは非同期に時間を要するこ
とが多い。

【０１５６】また、複数のオブジェクトの認証が一箇所
のサイトではなく、複数に跨ることも想定される。この
場合には、表４の条件は更に厳しくなり、実用に耐えな
くなる。そのため、stream処理と非同期で低速処理が可
能な認証手続きの場合には、「back-channel 2」を用い
た方が良い。

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

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

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

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

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

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

【０１６３】以上のように、２種類の異なる「back-cha
nnel」を設けることにより、柔軟性の高い認証処理を実
現することができる。

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

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

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

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

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

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

【０１７０】以上説明したように、本実施例ではクライ
アント・ユーザーとコンテンツ提供サーバー側との間に
おいて、入手しようとするコンテンツやオブジェクトデ
ータがセキュリティのための暗号化や電子透かし化とそ
れらを解除する為に必要な公開キーやパスワード等のpr
ivate IPMP dataが図１２に図示された相互互換性のあ
る国際標準仕様で構成されたMPEG-4データに付与されて
いる場合を例として、以下のセキュリティで保護された
デジタルコンテンツデータの配信サービスを提供するこ
とができる。１．ユーザーの再生しようとするコンテン
ツやオブジェクトのIPMP情報を、ユーザーの持つ再生装
置が有するIPMP System情報へ変換するサービスを行
う。この場合の入手コンテンツやオブジェクトデータは
変換後、国際標準仕様から構成された相互互換性のある
MPEG-4データ部分は変更されず、そのデータへのセキュ
リティのための暗号化や電子透かし化とその解除に必要
な公開キーやパスワードなどのprivate IPMP dataが対
象ユーザのIPMP System用に変換されるため、コンテン
ツやオブジェクトデータのセキュリティは保たれてい
る。２．１つのコンテンツが複数の異なるIPMP情報を持
つオブジェクトからなる場合の各IPMP Systemサーバー
側とのユーザー認証をユーザーからの要求等によって代
行するサービスを行う。

【０１７１】上述の課題で見たように、IPMP共通プラッ
トフォームを持つことも、一つの標準IPMP Systemを定
めることもそれぞれ問題を持つ。

【０１７２】そこで、上記１．、２．のサービスをもつ
中間的デジタルコンテンツ配信サービスプロバイバイダ
ーの存在によって、結果として以下のことが得られる。
すなわち、１）ユーザーは再生しようとする装置のIPMP Systemと
異なるIPMP System情報を持ったコンテンツや複数のオ
ブジェクトからなるコンテンツの再生が可能となる２）元々のコンテンツ・オブジェクトデータ配信側では
セキュリティを一般ユーザーへ開示する必要も無く、１
つの標準的なIPMP System仕様へ統一する必要も無いた
め、content(or object) right holderの要求に応じた
セキュリティシステムが構築できる３）ユーザーからみた操作性や異なるIPMP Systemから
の制約が解消し、コンテンツ・オブジェクトデータ供給
側のIPMP Systemのユーザーに対するinteroperability
が得られるです。

【０１７３】

【発明の効果】以上説明したように本実施例によれば、
ユーザーは再生しようとする装置の知的財産保護システ
ムと異なる保護システムを持ったコンテンツや複数のオ
ブジェクトからなるコンテンツの再生が可能となり、一
方、元々のコンテンツ・オブジェクトデータ配信側では
セキュリティを一般ユーザーへ開示する必要も無く、か
つ、１つの標準的な知的財産保護システム（例えば、IP
MP System）仕様へ統一する必要も無いため、content(o
r object) right holderの要求に応じたセキュリティシ
ステムが構築でき、ユーザーからみた操作性や異なる知
的財産保護システムからの制約が解消し、コンテンツ・
オブジェクトデータ供給側の知的財産保護システムのユ
ーザーに対するinteroperabilityが得られるという優れ
た効果を有する。

【図面の簡単な説明】

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

【図２】従来のMPEG−４プレーヤーの構成図である。

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

【図４】図３にIPMP System処理部を追加した図であ
る。

【図５】MPEG−4 プレーヤーの内部機能ブロックダイヤ
グラムとデータの流れを示している。

【図６】図５のデータ処理プロセスを簡略化して示した
図である。

【図７】MPEG−4オブジェクトアクセスデータユニット
の時間調整のデータ処理例を示すフローチャートであ
る。

【図８】Decoding BufferとComposition Memoryのデー
タ移動とタイミングを示す図である。

【図９】図６にIPMP System処理部を加えた場合のデー
タ処理プロセスを示す図である。

【図１０】図４のIPMP Systemの動作例を示すフローチ
ャートである。

【図１１】IPMPDescriptorとIPMPMessageを説明するた
めの図である。

【図１２】ユーザーが外部サ−バーからMPEG−４コンテ
ンツを入手し再生する例を示す図である。

【図１３】ユーザーが外部サ−バーからMPEG−４コンテ
ンツを入手し再生する他の例を示す図である。

【図１４】本発明にかかわる実施例１のIPMP Systemの
ローミングシステムを説明する図である。

【図１５】本発明にかかわる実施例２のIPMP Systemの
ローミングシステムを説明する図である。

【図１６】図１５における処理過程を説明する図であ
る。

【図１７】本発明にかかわる実施例３のIPMP Systemの
ローミングシステムを説明する図である。

【図１８】図１７における処理過程を説明する図であ
る。

【図１９】本発明にかかわる実施例４のIPMP Systemの
ローミングシステムを説明する図である。

【図２０】図２０は、本発明にかかわり実施例のローミ
ングサービスを実現するための具体的なService Reques
tの仕様を説明する図である。

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

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

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

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

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｇ０６Ｆ 13/00 ５４０Ｇ０６Ｆ 13/00 ５４０Ｓ 15/00 ３３０ 15/00 ３３０ＺＧ０９Ｃ 1/00 ６４０Ｇ０９Ｃ 1/00 ６４０ＺＨ０４Ｎ 7/24 Ｈ０４Ｎ 7/13 Ｚ

Claims

【特許請求の範囲】

【請求項１】クライアント、デジタルコンテンツサー
バ、情報変換サーバ及びこれらの間を接続するネットワ
ークを有して構成されるデジタルコンテンツ配信システ
ムにおいて、前記情報変換サーバは、デジタルコンテンツサーバから
知的財産保護システムが施されたデジタルコンテンツを
受信する手段と、前記受信したデジタルコンテンツの知的財産保護システ
ムを他の種類の知的財産保護システムに変換し、クライ
アントへ配信する手段とを有することを特徴とするデジ
タルコンテンツ配信システム。
【請求項２】前記クライアントは対応している知的財
産保護システムの情報を前記情報変換サーバに伝送する
手段を有することを特徴とする請求項１に記載のデジタ
ルコンテンツ配信システム。
【請求項３】前記情報変換サーバは、前記クライアン
トが対応している知的財産保護システムに変換すること
を特徴とする請求項１又は２に記載のデジタルコンテン
ツ配信システム。
【請求項４】前記クライアントは、対応している知的
財産保護システムの情報を前記デジタルコンテンツサー
バに伝送する手段を有することを特徴とする請求項１に
記載のデジタルコンテンツ配信システム。
【請求項５】前記情報変換サーバは、前記デジタルコ
ンテンツサーバから知的財産保護システムの変換依頼情
報を受信し、その情報に基づいて前記知的財産保護シス
テムの変換を行なうことを特徴とする請求項１〜４のい
ずれか１項に記載のデジタルコンテンツ配信システム。
【請求項６】前記情報変換サーバは、前記クライアン
トと前記デジタルコンテンツサーバとの認証を代行する
手段を有することを特徴とする請求項１〜５のいずれか
１項に記載のデジタルコンテンツ配信システム。
【請求項７】前記デジタルコンテンツはMPEG−４によ
り符号化されたデジタルデータであることを特徴とする
請求項１〜６のいずれか１項に記載のデジタルコンテン
ツ配信システム。
【請求項８】前記知的財産保護システムとは、IPMP S
ystemであることを特徴とする請求項７に記載のデジタ
ルコンテンツ配信システム。
【請求項９】前記IPMP Systemを特定するためにMPEG-
4 IS v.1仕様IPMP_Descriptor IPMP MessageにおけるIP
MPS_Typeを用いることを特徴とする請求項８に記載のデ
ジタルコンテンツ配信システム。
【請求項１０】前記クライアントは、前記情報変換サ
ーバに対応するIPMPS_Typeの情報を伝送する手段を有す
ることを特徴とする請求項９に記載のデジタルコンテン
ツ配信システム。
【請求項１１】前記クライアントは、前記クライアン
トを特定するためのIP_address情報を伝送する手段を有
することを特徴とする請求項１０に記載のデジタルコン
テンツ配信システム。
【請求項１２】前記クライアントは、前記デジタルコ
ンテンツを特定するURL情報を伝送する手段を有するこ
とを特徴とする請求項１０又は１１に記載のデジタルコ
ンテンツ配信システム。
【請求項１３】クライアント、情報変換サーバ及びこ
れらの間を接続するネットワークを有して構成されるデ
ジタルコンテンツ配信システムにおいて、前記情報変換
サーバは、前記クライアントから知的財産保護システム
が施されたデジタルコンテンツを受信する手段と、前記
受信したデジタルコンテンツの知的財産保護システムを
他の種類の知的財産保護システムに変換し、前記クライ
アントへ配信する手段とを有することを特徴とするデジ
タルコンテンツ配信システム。
【請求項１４】前記クライアントは対応している知的
財産保護システムの情報を前記情報変換サーバに伝送す
る手段を有することを特徴とする請求項１３に記載のデ
ジタルコンテンツ配信システム。
【請求項１５】前記情報変換サーバは、前記クライア
ントが対応している知的財産保護システムに変換するこ
とを特徴とする請求項１３又は１４に記載のデジタルコ
ンテンツ配信システム。
【請求項１６】前記デジタルコンテンツはMPEG−４に
より符号化されたデジタルデータであることを特徴とす
る請求項１３〜１５のいずれか１項に記載のデジタルコ
ンテンツ配信システム。
【請求項１７】前記知的財産保護システムとは、IPMP
Systemであることを特徴とする請求項１６に記載のデ
ジタルコンテンツ配信システム。
【請求項１８】前記IPMP Systemを特定するためにMPE
G-4 IS v.1仕様IPMP_Descriptor IPMP Messageにおける
IPMPS_Typeを用いることを特徴とする請求項１７に記載
のデジタルコンテンツ配信システム。
【請求項１９】前記クライアントは、前記情報変換サ
ーバに対応するIPMPS_Typeの情報を伝送する手段を有す
ることを特徴とする請求項１８に記載のデジタルコンテ
ンツ配信システム。
【請求項２０】前記クライアントは、前記クライアン
トを特定するためのIP_address情報を伝送する手段を有
することを特徴とする請求項１９に記載のデジタルコン
テンツ配信システム。
【請求項２１】前記クライアントは、前記デジタルコ
ンテンツを特定するURL情報を伝送する手段を有するこ
とを特徴とする請求項１９又は２０に記載のデジタルコ
ンテンツ配信システム。
【請求項２２】クライアント、デジタルコンテンツサ
ーバとネットワークを介して接続される情報変換サーバ
であって、前記デジタルコンテンツサーバから知的財産
保護システムが施されたデジタルコンテンツを受信する
受信手段と、前記受信したデジタルコンテンツの知的財
産保護システムを他の種類の知的財産保護システムに変
換する変換手段と、前記変換手段により変換されたデジ
タルコンテンツを前記クライアントに配信する配信手段
とを有することを特徴とする情報変換サーバ。
【請求項２３】前記クライアントから対応している知
的財産保護システムの情報を受信する保護システム情報
受信手段を有することを特徴とする請求項２２に記載の
情報変換サーバ。
【請求項２４】前記変換手段は、前記保護システム情
報受信手段によって受信された情報に基づいて変換処理
を行なうことを特徴とする請求項２３に記載の情報変換
サーバ。
【請求項２５】前記デジタルコンテンツサーバから知
的財産保護システムの変換依頼情報を受信する手段を有
し、前記変換手段は前記変換依頼情報に基づいて変換処
理を行なうことを特徴とする請求項２２に記載の情報変
換サーバ。
【請求項２６】前記クライアントと前記デジタルコン
テンツサーバとの認証を代行する手段を有することを特
徴とする請求項２２〜２５のいずれか１項に記載の情報
変換サーバ。
【請求項２７】前記デジタルコンテンツはMPEG−４に
より符号化されたデジタルデータであることを特徴とす
る請求項２２〜２６のいずれか１項に記載の情報変換サ
ーバ。
【請求項２８】前記知的財産保護システムとは、IPMP
Systemであることを特徴とする請求項２７に記載の情
報変換サーバ。
【請求項２９】前記IPMP Systemを特定するためにMPE
G-4 IS v.1仕様IPMP_Descriptor IPMP Messageにおける
IPMPS_Typeを用いることを特徴とする請求項２８に記載
の情報変換サーバ。
【請求項３０】前記クライアントの対応するIPMPS_Ty
peの情報を受信する手段を有することを特徴とする請求
項２９に記載の情報変換サーバ。
【請求項３１】前記クライアントを特定するためのIP
_address情報を受信する手段を有することを特徴とする
請求項３０に記載の情報変換サーバ。
【請求項３２】前記デジタルコンテンツを特定するUR
L情報を受信する手段を有することを特徴とする請求項
３０又は３１に記載の情報変換サーバ。
【請求項３３】クライアントとネットワークを介して
接続される情報変換サーバであって、前記クライアントから知的財産保護システムが施された
デジタルコンテンツを受信する受信手段と、前記受信したデジタルコンテンツの知的財産保護システ
ムを他の種類の知的財産保護システムに変換する変換手
段と、前記変換手段により変換されたデジタルコンテンツを前
記クライアントに配信する配信手段とを有することを特
徴とする情報変換サーバ。
【請求項３４】前記クライアントから対応している知
的財産保護システムの情報を受信する保護システム情報
受信手段を有することを特徴とする請求項３３に記載の
情報変換サーバ。
【請求項３５】前記変換手段は、前記保護システム情
報受信手段によって受信された情報に基づいて変換処理
を行なうことを特徴とする請求項３４に記載の情報変換
サーバ。
【請求項３６】前記デジタルコンテンツはMPEG−４に
より符号化されたデジタルデータであることを特徴とす
る請求項３３〜３５のいずれか１項に記載の情報変換サ
ーバ。
【請求項３７】前記知的財産保護システムとは、IPMP
Systemであることを特徴とする請求項３６に記載の情
報変換サーバ。
【請求項３８】前記IPMP Systemを特定するためにMPE
G-4 IS v.1仕様IPMP_Descriptor IPMP Messageにおける
IPMPS_Typeを用いることを特徴とする請求項３７に記載
の情報変換サーバ。
【請求項３９】前記クライアントの対応するIPMPS_Ty
peの情報を受信する手段を有することを特徴とする請求
項３８に記載の情報変換サーバ。
【請求項４０】前記クライアントを特定するためのIP
_address情報を受信する手段を有することを特徴とする
請求項３９に記載の情報変換サーバ。
【請求項４１】前記デジタルコンテンツを特定するUR
L情報を受信する手段を有することを特徴とする請求項
３９又は４０に記載の情報変換サーバ。
【請求項４２】クライアント、デジタルコンテンツサ
ーバ、情報変換サーバ及びこれらの間を接続するネット
ワークを有して構成されるシステムにおけるデジタルコ
ンテンツ配信方法であって、前記情報変換サーバは、デジタルコンテンツサーバから
知的財産保護システムが施されたデジタルコンテンツを
受信し、前記受信したデジタルコンテンツの知的財産保護システ
ムを他の種類の知的財産保護システムに変換し、クライ
アントへ配信することを特徴とするデジタルコンテンツ
配信方法。
【請求項４３】請求項４２に記載のデジタルコンテン
ツ配信方法のプログラムコードを記憶した記憶媒体。
【請求項４４】請求項４２に記載のデジタルコンテン
ツ配信方法を実行するためのプログラムソフトウェア。
【請求項４５】クライアント、情報変換サーバ及びこ
れらの間を接続するネットワークを有して構成されるシ
ステムにおけるデジタルコンテンツ配信方法であって、前記情報変換サーバは、前記クライアントから知的財産
保護システムが施されたデジタルコンテンツを受信し、前記受信したデジタルコンテンツの知的財産保護システ
ムを他の種類の知的財産保護システムに変換し、前記ク
ライアントへ配信することを特徴とするデジタルコンテ
ンツ配信方法。
【請求項４６】請求項４５のデジタルコンテンツ配信
方法のプログラムコードを記憶した記憶媒体。
【請求項４７】請求項４５に記載のデジタルコンテン
ツ配信方法を実行するためのプログラムソフトウェア。
【請求項４８】クライアント、デジタルコンテンツサ
ーバとネットワークを介して接続される情報変換サーバ
のデジタルコンテンツ配信方法であって、前記デジタル
コンテンツサーバから知的財産保護システムが施された
デジタルコンテンツを受信し、前記受信したデジタルコンテンツの知的財産保護システ
ムを他の種類の知的財産保護システムに変換し、前記変換されたデジタルコンテンツを前記クライアント
に配信することを特徴とするデジタルコンテンツ配信方
法。
【請求項４９】請求項４８に記載のデジタルコンテン
ツ配信方法のプログラムコードを記憶した記憶媒体。
【請求項５０】請求項４８に記載のデジタルコンテン
ツ配信方法を実行するためのプログラムソフトウェア。
【請求項５１】クライアントとネットワークを介して
接続される情報変換サーバのデジタルコンテンツ配信方
法であって、前記クライアントから知的財産保護システムが施された
デジタルコンテンツを受信し、前記受信したデジタルコンテンツの知的財産保護システ
ムを他の種類の知的財産保護システムに変換し、前記変換されたデジタルコンテンツを前記クライアント
に配信することを特徴とするデジタルコンテンツ配信方
法。
【請求項５２】請求項５１に記載のデジタルコンテン
ツ配信方法のプログラムコードを記憶した記憶媒体。
【請求項５３】請求項５１に記載のデジタルコンテン
ツ配信方法を実行するためのプログラムソフトウェア。
【請求項５４】ネットワークを介して外部装置と接続
可能な情報処理装置であって、本装置が対応する知的財産保護システムの情報と本装置
を特定する特定情報とを前記外部装置へ前記ネットワー
クを介して送信する送信手段と、前記知的財産保護システムが施されたデジタルコンテン
ツを前記外部装置から前記ネットワークを介して受信す
る受信手段とを有することを特徴とする情報処理装置。
【請求項５５】前記デジタルコンテンツはMPEG−４に
より符号化されたデジタルデータであることを特徴とす
る請求項５４に記載の情報処理装置。
【請求項５６】前記知的財産保護システムとは、IPMP
Systemであることを特徴とする請求項５５に記載の情
報処理装置。
【請求項５７】前記IPMP Systemを特定するためにMPE
G-4 IS v.1仕様IPMP_Descriptor IPMP Messageにおける
IPMPS_Typeを用いることを特徴とする請求項５６に記載
の情報処理装置。
【請求項５８】前記本装置を特定する情報としてIP_a
ddress(Internet Protocol address)情報を用いること
を特徴とする請求項５７に記載の情報処理装置。
【請求項５９】前記送信手段は本装置が備える知的財
産保護システムとは異なる知的財産保護システムが施さ
れた前記デジタルコンテンツを前記外部装置に送信する
ことを特徴とする請求項５４〜５８のいずれか１項に記
載の情報処理装置。
【請求項６０】前記送信手段は、前記デジタルコンテ
ンツが存在する場所を示す場所情報を前記外部装置に送
信することを特徴とする請求項５４〜５９のいずれか１
項に記載の情報処理装置。
【請求項６１】前記場所情報はURL(Uniform Resource
Locator)情報であることを特徴とする請求項６０に記
載の情報処理装置。
【請求項６２】ネットワークを介して外部装置と接続
可能な情報処理装置の情報処理方法であって、前記情報処理装置が対応する知的財産保護システムの情
報と前記情報処理装置を特定する特定情報とを前記外部
装置へ前記ネットワークを介して送信し、前記知的財産保護システムが施されたデジタルコンテン
ツを前記外部装置から前記ネットワークを介して受信す
ることを特徴とする情報処理方法。
【請求項６３】請求項６２に記載の情報処理方法のプ
ログラムコードを記憶した記憶媒体。
【請求項６４】請求項６２に記載の情報処理方法を実
行するためのプログラムソフトウェア。