JP2004213353A - マルチメディアコンテンツの配信方法、再生方法、配信装置および再生装置 - Google Patents

Abstract

【課題】外部のデータを参照するマルチメディアコンテンツを、正しく再生できるように配信し、再生する。
【解決手段】コンテンツデータ保管部２は、ＵＲＬを用いて外部データを参照するマルチメディアコンテンツを保管する。基準ＵＲＬ管理部１は、外部データの適正な位置を示す絶対ＵＲＬを導出するための基準ＵＲＬを管理する。データ処理部３は、マルチメディアコンテンツの配信要求を受信すると、外部データのＵＲＬを計算するための基準ＵＲＬを含む情報を、データ送受信部４に返させる。
【選択図】 図６

Description

【０００１】
【発明の属する技術分野】
本発明はマルチメディアコンテンツの配信方法、再生方法、配信装置および再生装置に関し、例えば、外部データを参照するマルチメディアコンテンツの配信および再生に関する。
【０００２】
【従来の技術】
情報メディアの多様化に伴い、映像、音声、文書といったメディアコンテンツを単独に扱うのではなく、それらコンテンツを互いに関連付けて一つの複合コンテントとして扱い、各コンテントを連携させてパーソナルコンピュータなどで再生する、いわゆるマルチメディアコンテンツが一般化した。
【０００３】
また、近年のインターネットの普及により、マルチメディアコンテンツを、インターネットを介して、複数ないし不特定多数の視聴者に配布、配信するというニーズも存在する。現在の回線事情では、伝送可能な情報量や伝送品質などに関する制約があるものの、限られた範囲のサービスであればインターネットを経由した配布、配信が可能であり、実際にコンテンツ配信サービスを行うウェブサイトも現れている。
【０００４】
こういった時代の要求に対応すべく、メディアコンテンツの合成や連携といった操作が可能なマルチメディアコンテンツを、ネットワークを介して配信することが可能なディジタルデータとして表現するための様々な規格が検討され、策定されている。
【０００５】
前記の要求を充足する規格の代表例として、ＩＳＯ （Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ）によって規定される、マルチメディア符号化形式の国際標準規格であるＩＳＯ／ＩＥＣ １４４９６ （ＭＰＥＧ−４）が挙げられる。
【０００６】
ＭＰＥＧ−４は、映像（ビデオ）、音声（オーディオ）といった単一のメディアデータそれぞれをシーンを構成する物体（オブジェクト）として取り扱い個別に符号化する、オブジェクトベース符号化形式という特徴をもつ。
【０００７】
また、ＭＰＥＧ−４には、各オブジェクトを合成して一つのシーンを表現するために、シーン記述という考え方が導入されている。シーン記述は、オブジェクト自体の符号データとは別に、シーンを構成する各オブジェクトの相関やシーンにおけるオブジェクトの配置を示す空間的属性、および、オブジェクトが出現したり消滅したりするタイミングを示す時間的属性などを記述することで、オブジェクトの合成や連携を可能にするための手段として用いられる。
【０００８】
なお、ＭＰＥＧ−４は、シーン記述情報のデータ量を小さくして伝送効率をよくするために、Ｂｉｎａｒｙ Ｆｏｒｍａｔ ｆｏｒ Ｓｃｅｎｅ （ＢＩＦＳ）と呼ばれる二進データ符号化形式を規定し、シーン記述情報の記述はＢＩＦＳ形式にすることが標準的である。
【０００９】
このシーン記述情報に加えて、シーン記述情報で示されるオブジェクト情報と、オブジェクト自体の符号データとの関連付けを行う識別子（オブジェクトディスクリプタ）が記述されたオブジェクトディスクリプタ情報を、再生時に参照し解析することで、オブジェクトの属性が反映されたシーンの合成が可能になる。
【００１０】
図１はＭＰＥＧ−４においてシーンがどのように合成されるかを簡単に説明する図である。
【００１１】
シーンに含まれるビデオデータ、オーディオデータおよび絵文字などのグラフィックスデータは、ＭＰＥＧ−４では何れも「オブジェクト」として包括的に扱われる。さらに、これらのデータの配置や関連付けなどが記述されたシーン記述情報やオブジェクトディスクリプタ情報も、同様に、オブジェクトとして扱われる。
【００１２】
コンテンツ再生装置は、コンテンツに含まれるシーン記述情報およびオブジェクトディスクリプタ情報に基づき、各オブジェクトを空間的および時間的に再配置して、最終的に出力すべきシーンＳ０１を合成し、再生が行われる。
【００１３】
図２は、シーン記述情報およびオブジェクトディスクリプタ情報を用いて、どのようにオブジェクトの関連付けを行うかを簡単に説明する図である。
【００１４】
ＭＰＥＧ−４は、ビデオデータ、オーディオデータおよびシーン記述情報などが符号化された各ビット列を「エレメンタリストリーム （Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ， ＥＳ）」と呼ぶ。エレメンタリストリームには、各ストリームを一意に識別するために、エレメンタリストリームＩＤ （ＥＳ＿ＩＤ）と呼ばれる識別子が付与される。
【００１５】
オブジェクトディスクリプタは、シーンに出現するオブジェクトの特性情報を管理するために用いられる。すべてのオブジェクトおよびオブジェクトディスクリプタには、個々のオブジェクトを一意に識別するためのオブジェクトディスクリプタＩＤ （ＯＤ＿ＩＤ）と呼ばれる識別子が付与されている。ＯＤ＿ＩＤは、シーン記述情報に含まれるオブジェクトの時間的および空間的配置などの属性情報と、オブジェクトディスクリプタ情報とを一対一に対応付ける。また、オブジェクトディスクリプタ情報にはＥＳ＿ＩＤを保持可能であるから、オブジェクトディスクリプタ情報に関連するエレメンタリストリームをＥＳ＿ＩＤによって特定することができる。
【００１６】
つまり、シーンを構成するビデオオブジェクトやオーディオオブジェクトは、ＯＤ＿ＩＤおよびＥＳ＿ＩＤによって実際のデータを示すエレメンタリストリームを特定し、参照することができる。
【００１７】
なお、エレメンタリストリームは、必ずしも再生対象のコンテンツに含まれている必要はなく、外部のエレメンタリストリームを参照することも許されている。ＭＰＥＧ−４は、エレメンタリストリームを参照するために、ＥＳ＿ＩＤのほかに、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ （ＩＥＴＦ）によって業界標準として規定されているＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｅｒ （ＵＲＬ）を使用することができる。従って、データやデバイスのアドレス情報であるＵＲＬを上記の関連付けに用いれば、エレメンタリストリームのデータも外部参照することが可能である。
【００１８】
図３はＯＤ＿ＩＤおよびＵＲＬによるエレメンタリストリームの参照例を示す図である。
【００１９】
図３の例は、複数のオブジェクトから構成されるシーンＳ０２と、シーンＳ０２を構成するビデオオブジェクトのエレメンタリストリームのデータＶ０１が、コンテンツファイルＦ０１に記録されている。また、別のコンテンツファイルＦ０２にも、ビデオオブジェクトに対応するエレメンタリストリームのデータＶ０２が記録されている。
【００２０】
シーンＳ０２にエレメンタリストリームのデータＶ０１ビデオを表示させるには、エレメンタリストリームのデータＶ０１のＥＳ＿ＩＤをオブジェクトに関連付ける。一方、シーンＳ０２に、エレメンタリストリームのデータＶ０１に代わり、外部データであるエレメンタリストリームのデータＶ０２のビデオを表示させるには、ＥＳ＿ＩＤではなく、エレメンタリストリームのデータＶ０２の位置を特定し、参照するためのＵＲＬを関連付けに用いる。そのＵＲＬには、エレメンタリストリームのデータＶ０２を格納するコンテンツファイルＦ０２のファイルパスを示す文字列が指定される。
【００２１】
なお、図３の例では、コンテンツデータはファイルとして保存され、ＵＲＬは外部ファイルのパス名を指定するものと説明したが、規格上は、コンテンツの位置を特定可能なＵＲＬが指定される限り、どのような手段で参照されてもよい。従って、リモートマシン上のコンテンツデータを、前記のＩＥＴＦによって規格化されているＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ （ＨＴＴＰ）、Ｒｅａｌ−Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ （ＲＴＳＰ）やＲｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ （ＲＴＰ）といったネットワークプロトコルを用いて参照するように指定することも可能である。
【００２２】
ＭＰＥＧ−４は、前記の仕組みにより、複数のマルチメディアデータがハイパリンク状に結び付けられたマルチメディアコンテンツの作成を可能にする。
【００２３】
このように、ＭＰＥＧ−４は、（１） ＥＳ＿ＩＤによる内部参照、（２） ＵＲＬによる外部参照、という二種類のコンテンツデータの参照方法が利用可能である。
【００２４】
ＵＲＬによる外部参照を用いて作成されたマルチメディアコンテンツの場合、シーンを構成するデータはそれぞれ独立した実体として存在するから、編集作業などは、編集対象の実体に対してのみ操作を行うことができる。例えば、シーン記述データと、ビデオおよびオーディオオブジェクトのデータとが独立した実体として作成されている場合、シーン記述データの実体のみを編集することで、他のオブジェクトに対する処理を行うことなく、シーンを編集することができる。つまり、ＵＲＬによる外部参照を利用すれば、編集作業が効率的なコンテンツの作成が可能になるという利点がある。
【００２５】
その反面、参照するデータの位置を示すＵＲＬを常に正しい状態で保持しなければならない、という制約がある。いうまでもないが、ＵＲＬで示される位置と、実際のデータの位置とが異なる場合、コンテンツが正しく再生される保証はない。言い換えれば、ＵＲＬによる外部参照を用いる場合、コンテンツ作成時に、外部参照データの正しいＵＲＬを設定しなければならない。しかし、図４を用いて説明するように、コンテンツ作成時に、正しいＵＲＬを設定することができないケースもあり得る。
【００２６】
図４は典型的なコンテンツ配信システムの構成例を示す図である。
【００２７】
図４に示すコンテンツ配信システムは、コンテンツ作成者、コンテンツサーバＳおよびコンテンツ視聴者の三者から構成されるものとする。コンテンツ作成者は、その端末Ａを使用してコンテンツを作成し、コンテンツサーバＳに登録する。また、コンテンツ視聴者は、その端末Ｃを利用してコンテンツサーバＳにコンテンツの配信を要求し、配信要求を受けたコンテンツサーバＳは、端末Ｃにコンテンツを配信する。コンテンツサーバＳには「ｓ．ｃｏｍ」というホスト名が設定され、コンテンツ視聴者の端末ＣからＨＴＴＰによってアクセス可能である。
【００２８】
このようなコンテンツ配信システムにおいて、コンテンツ作成者が図３に示すようなコンテンツデータを作成し、コンテンツサーバＳに登録する場合を例として、考えられる問題点を以下に記述する。なお、説明に用いるコンテンツデータは、ファイル名「Ｃ．ｍｐ４」「Ｖ．ｍｐ４」で示される二つのファイルとし、Ｖ．ｍｐ４は、Ｃ．ｍｐ４からＵＲＬによって外部参照されるものとする。
【００２９】
ＵＲＬの仕様を示すＲＦＣ １７３８には、ＵＲＬとして「Ｖ．ｍｐ４」（あるいは「．／Ｖ．ｍｐ４」）といった相対ＵＲＬが指定された場合、そのＵＲＬの最後の「／」までを基準として、参照位置の再計算が行われる、と規定されている。この仕様により、コンテンツサーバＳ上の位置に関わらず、コンテンツの作成時に正しいＵＲＬを指定することができる。
【００３０】
図４の例において、コンテンツサーバＳの「／／ｓ．ｃｏｍ／」の位置にコンテンツファイルが登録されたとすると、コンテンツファイルＦ０１からコンテンツファイルＦ０２が参照される際に、コンテンツファイルＦ０１の位置を示す「／／ｓ．ｃｏｍ／Ｃ．ｍｐ４」からコンテンツファイルＦ０２の正確な位置を示す「／／ｓ．ｃｏｍ／Ｖ．ｍｐ４」が導かれ、正しい参照が可能になる。なお、コンテンツの配置に依存しない柔軟な外部参照を実現するため、コンテンツのＵＲＬ指定には、可能であれば、相対ＵＲＬを指定することが好ましい。
【００３１】
しかし、実際には、相対ＵＲＬを用いた外部参照が正しく行えないケースも存在する。現実のコンテンツ配信システムは、コンテンツ登録者のプライバシ保護や配信に対する課金などの観点から、図４に示すＵＲＬのように、誰でもアクセス可能な状態でコンテンツが登録されることは稀である。明示的に不特定多数の視聴者からの参照を認めない限り、コンテンツは外部から直接アクセスできない非公開のディレクトリに保管される。従って、非公開ディレクトリに格納されたコンテンツへの参照を可能にし、あるいは、ユーザ認証や、解像度などのコンテンツ属性の変換といった処理をコンテンツ要求と同時に行うため、コンテンツサーバＳ上の何らかのプログラムを経由してコンテンツを要求する必要が生じる。
【００３２】
図５はコンテンツが非公開の位置に保管されている場合のコンテンツ配信システムの構成例を示す図である。
【００３３】
図５において、コンテンツファイルＦ０１およびＦ０２は、コンテンツサーバＳ上に、非公開ファイルＦ０１’およびＦ０２’として保管される。コンテンツ視聴者のコンテンツの配信要求は、コンテンツサーバＳ上で動作するサーバプログラムＰを仲介して処理される。なお、サーバプログラムＰは、例えばＣＧＩ （Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）プログラムとして提供される。ＣＧＩプログラムは、要求するコンテンツ名「Ｃ．ｍｐ４」などを含むコンテンツ配信要求「ｈｔｔｐ：／／ｓ．ｃｏｍ／Ｐ．ｃｇｉ？Ｃ．ｍｐ４」のＵＲＬ指定を処理する。
【００３４】
図５のケースにおいて、ＲＦＣ １７３８の仕様に従えば、相対ＵＲＬの再計算の基準になる位置は「／／ｓ．ｃｏｍ／」になり、外部参照されるコンテンツファイルＦ０２’の再計算後の位置は「／／ｓ．ｃｏｍ／Ｖ．ｍｐ４」になる。しかし、非公開の位置に保管されているコンテンツファイルＦ０２’は「ｈｔｔｐ：／／ｓ．ｃｏｍ／Ｖ．ｍｐ４」では参照することができない。つまり、相対ＵＲＬによって外部参照されるコンテンツＦ０２’は、仕様上は正しいＵＲＬが指定されているにも関わらず、図５に示すようなコンテンツ配信システムにおいては正しく再生することができない。このような問題は、コンテンツ配信システムに対する信頼を失い、最終的には利用者が離れる、というシステムの運営者には最も避けたい事態を招きかねない。
【００３５】
この問題に対する第一の解決策として、外部から参照可能な公開ディレクトリにコンテンツファイルＦ０２を出力し、その出力先のＵＲＬをコンテンツ視聴者の端末Ｃに返し、配信が完了した時点で出力先のコンテンツファイルＦ０２を削除する方法が考えられる。公開ディレクトリの名称を複雑で、直感的には分かり難い名称にすれば、意図しない視聴者がコンテンツファイルＦ０２を参照する可能性は小さくなり、ある程度、プライバシ保護や課金などのセキュリティ上の問題を解決することができる。しかし、コンテンツファイルＦ０２’が不特定多数の視聴者から参照可能な位置に配置されている以上、セキュリティ問題を充分に解決しているとは言えず、セキュリティを考慮するコンテンツ配信システムには不向きである。
【００３６】
第二の解決策として、外部参照ＵＲＬとして、相対ＵＲＬではなく、コンテンツサーバＳ上でコンテンツファイルＦ０２の参照に用いる絶対ＵＲＬを指定したコンテンツを作成する方法が考えられる。この方法は、コンテンツファイルＦ０２がコンテンツサーバＳの絶対ＵＲＬに対応する位置に登録された状態で、初めて、コンテンツファイルＦ０２の参照可能になる。言い換えれば、絶対ＵＲＬが示す位置以外に配置したコンテンツファイルＦ０２は参照することができず、たとえコンテンツ作成者の端末Ａ上ですら、参照不可能である。つまり、この解決策は極めて柔軟性に欠け非現実的である。
【００３７】
第三の解決策として、コンテンツ作成時は外部参照ＵＲＬとして相対ＵＲＬを指定し、コンテンツサーバＳへ登録する際に、外部参照ＵＲＬを絶対ＵＲＬに書き換える方法が考えられる。この方法は、コンテンツ作成時は相対ＵＲＬで外部参照を行うため、第二の解決策のように、絶対ＵＲＬが示す位置へコンテンツファイルＦ０２を配置しない限り、コンテンツファイルＦ０２を参照することができないとう問題を回避することができる。しかし、コンテンツ登録後の、サーバ構成やドメイン名の変更に対応することができない。その際、コンテンツサーバＳの管理者は、外部参照ＵＲＬを正しいものに修正することは可能であるが「著作物を改竄する行為」「著作権の侵害」など、権利面のトラブルが発生する可能性がある。
【００３８】
第四の解決策として、外部参照ＵＲＬを相対ＵＲＬで指定したままの状態でコンテンツサーバＳに保管し、コンテンツ視聴者Ｃのコンテンツ配信要求を受けた時点で、動的に、外部参照ＵＲＬを絶対ＵＲＬに書き換えて配信する方法が考えられる。この方法によれば、コンテンツデータの実体は常に正しい状態で存在することになり、第二、第三の解決策のような問題は生じない。しかし、コンテンツサーバＳは、コンテンツの内容を解析して、発見した相対ＵＲＬを絶対ＵＲＬに変換するという処理を、コンテンツを配信しながら行うことになり、コンテンツサーバＳの処理負荷を増大させる。とくに、ＭＰＥＧ−４のようなコンテンツの場合、ＵＲＬを含むデータはＢＩＦＳ形式のような二進符号データとして記録されているため、テキスト形式のデータを扱う場合に比べると解析および変換処理が複雑になり、コンテンツサーバＳの処理負荷をさらに大きくする。
【００３９】
【発明が解決しようとする課題】
本発明は、上述の問題を個々にまたはまとめて解決するためのもので、外部のデータを参照するマルチメディアコンテンツを、正しく再生できるように配信し、再生することを目的とする。
【００４０】
【課題を解決するための手段】
本発明は、前記の目的を達成する一手段として、以下の構成を備える。
【００４１】
本発明にかかる配信方法は、マルチメディアコンテンツを配信する情報処理装置の配信方法であって、アドレス情報を用いて外部データを参照するマルチメディアコンテンツを保管し、前記外部データの適正な位置を示す絶対アドレス情報を導出するための基準アドレス情報を管理し、前記マルチメディアコンテンツの配信要求を受信すると、前記外部データのアドレス情報を計算するための前記基準アドレス情報を含む情報を返すことを特徴とする。
【００４２】
本発明にかかる再生方法は、マルチメディアコンテンツを再生する情報処理装置の再生方法であって、再生するマルチメディアコンテンツの配信を要求し、前記要求に対する応答に外部データのアドレス情報を計算するための基準アドレス情報が含まれる場合、前記基準アドレス情報に基づき、前記外部データの適正な位置を示す絶対アドレス情報を計算し、前記絶対アドレス情報に基づき、前記外部データを要求することを特徴とする。
【００４３】
本発明にかかる配信装置は、マルチメディアコンテンツを配信する配信装置であって、アドレス情報を用いて外部データを参照するマルチメディアコンテンツを保管する保管手段と、前記外部データの適正な位置を示す絶対アドレス情報を導出するための基準アドレス情報を管理する管理手段と、前記マルチメディアコンテンツの配信要求を受信して、前記外部データのアドレス情報を計算するための前記基準アドレス情報を含む情報を返す通信手段とを有することを特徴とする。
【００４４】
本発明にかかる再生装置は、マルチメディアコンテンツを再生する再生手段と、再生するマルチメディアコンテンツの配信要求に対する応答に、外部データのアドレス情報を計算するための基準アドレス情報が含まれる場合、前記基準アドレス情報に基づき、前記外部データの適正な位置を示す絶対アドレス情報を計算する計算手段と、前記配信要求および前記絶対アドレス情報に基づく外部データの要求を送信し、前記応答および前記外部データを受信する通信手段とを有することを特徴とする。
【００４５】
【発明の実施の形態】
以下、本発明にかかる実施形態のコンテンツ配信システムを図面を参照して詳細に説明する。
【００４６】
実施形態のコンテンツ配信システムは、外部のデータを参照するマルチメディアコンテンツを、正しく再生できるように、ネットワークを介して配信することを目的とする。
【００４７】
また、前述した第一の解決策の問題を考慮して、コンテンツ配信システムのセキュリティを損うことなく配信することを他の目的とする。
【００４８】
また、前述した第二の解決策の問題を考慮して、特定の実行環境に著しく依存するような相互運用性に欠けるコンテンツを用いなくとも正しいコンテンツの再生を可能にすることを他の目的とする。
【００４９】
また、前述した第三の解決策の問題を考慮して、実行環境の変更に対しても柔軟に対応でき、コンテンツの改変を不要にすることを他の目的とする。
【００５０】
さらに、前述した第四の解決策の問題を考慮して、コンテンツサーバに不要な負荷をかけることなく配信を可能にすることを他の目的とする。
【００５１】
なお、上述した解決策について、とくにＭＰＥＧ−４コンテンツを扱う場合を中心に、その問題を説明したが、このような問題はＭＰＥＧ−４に固有のものではなく、マルチメディアコンテンツを記述する類似の符号化方式に共通である。また、通信プロトコルとしてＨＴＴＰを扱う場合を例に説明したが、コンテンツの位置をＵＲＬで表現可能な他のすべてのプロトコルについても、上記の問題は共通である。さらに、外部データの参照にＵＲＬを使用する例を説明したが、上記の問題は、データやデバイスの所在（位置）を特定するアドレス情報に共通である。従って、マルチメディアコンテンツを取り扱う様々な符号化方式、通信プロトコル、アドレス情報に対して、本発明を適用することができる。
【００５２】
［構成］
図６は実施形態のコンテンツ配信システムの構成例を説明する図である。
【００５３】
図６において、コンテンツサーバＳは、コンテンツ視聴者の要求に応じてコンテンツデータを送出する機能を有する。コンテンツ視聴者の端末Ｃは、コンテンツサーバＳにコンテンツの配信を要求し、受信したコンテンツを再生する。なお、コンテンツサーバＳおよび端末Ｃは、インターネットなど何らかのネットワークや伝送路を介して、互いにコマンドやデータの送受信が可能な状態にある。また、コンテンツの配信要求は、端末ＣからコンテンツサーバＳに対して、配信を要求するコンテンツのＵＲＬを指定することによって行われる。
【００５４】
基準ＵＲＬ管理部１は、コンテンツ視聴者がコンテンツサーバＳ上のコンテンツデータを参照する際に、コンテンツデータの位置を再計算する基準になる絶対ＵＲＬ（以下「基準ＵＲＬ」と呼ぶ）を保持し、管理する。なお、基準ＵＲＬ管理部１による基準ＵＲＬの管理はどのような形態でもよい。例えば、基準ＵＲＬがデータファイルなどとして不揮発性のメモリに保存されていてもよいし、物理的に異なる装置から何らかの手段によって基準ＵＲＬが伝送されてくるような形態でもよい。
【００５５】
コンテンツデータ管理部２は、マルチメディアコンテンツの実体データを管理し、コンテンツのＵＲＬに基づき、管理するコンテンツの実体データを特定し、参照する。コンテンツデータ管理部２には、コンテンツおよび外部参照されるデータの実体の位置関係を正しく保持することが要求される。代表的な実装方法としては、ファイルシステム上に作成されたディレクトリツリーを用いて、コンテンツデータをファイルとして管理することが考えられるが、データの内容および位置関係が正しく管理できれば、どのような形態でもよい。
【００５６】
データ処理部３は、端末Ｃの要求内容を解析し、必要に応じて、基準ＵＲＬ管理部１およびコンテンツデータ管理部２から基準ＵＲＬおよびコンテンツデータを取得し、端末Ｃで処理可能な形式に整形する。基準ＵＲＬは、システムの仕様により、システムを通じて共通のＵＲＬである場合もあれば、システムにログインしているユーザよって異なるなど、実行時のコンテクストによって異なる基準ＵＲＬが用いられる場合も考えられる。後者の場合、データ処理部３は、ＵＲＬ管理部１から取得した基準ＵＲＬを、実行時のコンテクストに応じた適切な基準ＵＲＬに変換する必要がある。
【００５７】
データ送受信部４は、端末Ｃから受信したコマンドやデータをデータ処理部３に渡し、データ処理部３から受け取ったデータを端末Ｃへ送信する。つまり、データ送受信部４は、ネットワークや通信路を介して、様々なコンテンツ視聴者の端末と通信を行う通信機能を備える。
【００５８】
ＵＲＬ入力部５は、コンテンツサーバＳに要求するコンテンツのＵＲＬなど、ＵＲＬデータを入力するためのものである。ＵＲＬデータは、ユーザインタフェイスを介して、端末Ｃの利用者（コンテンツ視聴者）が入力するか、外部装置またはソフトウェアモジュールのデータ入力処理によって入力される。
【００５９】
ＵＲＬ処理部６は、ＵＲＬ入力部５から入力される、または、コンテンツサーバＳから受信したデータに含まれる基準ＵＲＬなどのＵＲＬデータに基づき、ＵＲＬの結合、編集、再計算処理を行い、絶対ＵＲＬを導き出す。なお、基準ＵＲＬなどのＵＲＬデータは、例えば要求したコンテンツの再生処理が終了するまでの間、ＵＲＬ処理部６に保持される。
【００６０】
データ送受信部７は、コンテンツサーバＳから受信したデータをＵＲＬ処理部６および／またはコンテンツ再生部８に渡し、ＵＲＬ処理部６および／またはコンテンツ再生部８から受け取ったコマンドやデータをコンテンツサーバＳへ送信する。つまり、データ送受信部７は、ネットワークや通信路を介して、コンテンツサーバＳと通信を行う通信機能を備える。
【００６１】
コンテンツ再生部８は、データ送受信部７を介して入力されるコンテンツデータを再生処理する。コンテンツ再生部８は、符号のデコード、シーン記述情報に基づくシーンの再構築およびシーンの表示機能を有する。また、シーン記述情報中のＵＲＬ情報を検出すると、データ送受信部７を呼び出して、ＵＲＬで指定されたコンテンツデータを取得する機能を備える。
【００６２】
［ＵＲＬの再計算］
本実施形態は、コンテンツが非公開の位置に保管されている場合、相対ＵＲＬが正しく再計算されない問題に対して、相対ＵＲＬの再計算処理を行う際の基準になる基準ＵＲＬをコンテンツ視聴者の端末Ｃに提示する。端末Ｃは、ＵＲＬの再計算にコンテンツのＵＲＬおよび基準ＵＲＬを使用することで、相対ＵＲＬから正しい絶対ＵＲＬを導き出することが可能になる。
【００６３】
下にＵＲＬ処理部６によるＵＲＬの再計算例を示す。

【００６４】
上記において、相対ＵＲＬで指定されたコンテンツのＵＲＬ「Ｃ．ｍｐ４」は、基準ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／Ｐ．ｃｇｉ？」に基づく再計算により、絶対ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／Ｐ．ｃｇｉ？Ｃ．ｍｐ４」に変換される。勿論、相対ＵＲＬの再計算は、ＲＦＣ １７３８の規定に従うことが要求されるから、相対ＵＲＬとして「．／Ｃ．ｍｐ４」が指定された場合も、同等の処理結果が得られる。
【００６５】
さらに、基準ＵＲＬのみでは、必要とされる絶対ＵＲＬを導き出すのに不充分な場合、基準ＵＲＬに不足する部分を補うため、一つないし複数の補完ＵＲＬを指定してもよい。補完ＵＲＬが指定された場合、ＵＲＬ処理部６は、再計算処理に加えて、システムで予め定められた位置に補完ＵＲＬのデータを埋め込み、最終的な絶対ＵＲＬを合成する。
【００６６】
下に補完ＵＲＬを用いたＵＲＬの再計算例を示す。

【００６７】
上記に示す補完ＵＲＬ「＆ｕｓｅｒ＝００１」は、コンテンツのＵＲＬの直後に付加されるものとして定義されていることにする。コンテンツのＵＲＬ「Ｃ．ｍｐ４」は、基準ＵＲＬを用いて絶対ＵＲＬに変換された後、その末尾に補完ＵＲＬが付加され、最終的に「ｈｔｔｐ：／／ｓ．ｃｏｍ／Ｐ．ｃｇｉ？ｆｉｌｅ＝Ｃ．ｍｐ４＆ｕｓｅｒ＝ｕ００１」という絶対ＵＲＬが合成される。勿論、補完ＵＲＬを埋め込む位置はＵＲＬの末尾には限らず、基準ＵＲＬとコンテンツのＵＲＬとの間など、任意の位置に埋め込むことができるが、補完ＵＲＬをどこへ埋め込むかはシステムの仕様として予め定めておく必要がある。
【００６８】
［処理］
図７は基準ＵＲＬの提示およびＵＲＬの再計算などの処理を説明する図である。
【００６９】
●ステップＳ１
コンテンツ視聴者の端末Ｃは、コンテンツ要求用ＵＲＬを用いて、コンテンツサーバＳにコンテンツを要求する。コンテンツ要求用のＵＲＬは、一連のコンテンツ要求を開始する際に用いられるＵＲＬで、何らかの手段で端末Ｃに予め提示されている。コンテンツ要求用のＵＲＬを提示する手段として、例えば、システムへのログイン時など、何れかのサーバからＨｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＨＴＭＬ）などの形式で記述されたコンテンツ情報と一緒に、コンテンツ要求用のＵＲＬが端末Ｃに送付される、などが挙げられる。
【００７０】
図８はＨＴＭＬデータを用いる場合のコンテンツ要求用のＵＲＬの送付サンプルを示す図で、「ｘｘｘさんのコンテンツ」一覧情報として送付されるＨＴＭＬデータに、コンテンツ要求用のＵＲＬを示すハイパリンクが記述されている。端末Ｃの利用者（コンテンツ視聴者）は、このＨＴＭＬデータに基づく画面の該当部分をクリックすることで、対応するコンテンツを要求する。
【００７１】
なお、端末Ｃのデータ送受信部７は、指定されたＵＲＬによってコンテンツサーバＳにコンテンツを要求するが、同時に、指定されたＵＲＬを現在視聴中のコンテンツのＵＲＬとしてＵＲＬ処理部６に渡す。このＵＲＬは、ＵＲＬ処理部６に保持され、後述するＵＲＬの再計算処理で使用される。
【００７２】
●ステップＳ２
コンテンツサーバＳのデータ送受信部４は、端末Ｃから受信したコンテンツ要求用のＵＲＬをデータ処理部３に渡す。コンテンツ要求用のＵＲＬに加えて、端末Ｃから受信したデータがある場合は、そのデータもデータ処理部３に渡す。データ処理部３は、基準ＵＲＬ管理部１から基準ＵＲＬを取得する。実行時のコンテクストに応じて異なる基準ＵＲＬを用いる場合、データ処理部３は、適切な基準ＵＲＬを選択する。図７は「ｈｔｔｐ：／／ｓ．ｃｏｍ／Ｐ．ｃｇｉ？」が基準ＵＲＬの例を示している。
【００７３】
さらに、データ処理部３は、データ送受信部４から渡されたコンテンツ要求用のＵＲＬ（およびその他のデータ）を基に、要求されたコンテンツを特定し、コンテンツデータ管理部２から該当するコンテンツデータを参照する。図７の例では、コンテンツ要求用のＵＲＬが「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｉｎｉ．ｃｇｉ？Ｃ．ｍｐ４」であり、「Ｃ．ｍｐ４」が要求コンテンツのファイル名である。この場合、データ処理部３は、ファイル名「Ｃ．ｍｐ４」に該当するコンテンツデータをコンテンツデータ管理部２に照会する。これに対して、コンテンツデータ管理部２は、該当するコンテンツデータ、または、該当するコンテンツデータのファイルパスのようなデータ処理部３が参照可能な位置情報を返す。
【００７４】
次に、データ処理部３は、前記の処理で取得した基準ＵＲＬおよびコンテンツデータなどを、端末Ｃが処理可能なデータ形式に整形する。例えば、端末Ｃが処理可能なデータ形式としてＥｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ （ＸＭＬ）のような構造化記述言語を想定すれば、基準ＵＲＬなどをＸＭＬのタグデータとして記述する処理などが行われる。なお、ここで整形されるデータには、少なくともコンテンツデータ管理部２から取得されたコンテンツデータが含まれている必要がある。データ処理部３は、取得したコンテンツデータを整形データに含めるか、あるいは、取得したコンテンツデータをリモート参照することが可能なＵＲＬを含めるかしなければならない。また、基準ＵＲＬを補完するための補完ＵＲＬが必要とされる場合、データ処理部３は、整形データに補完ＵＲＬを含める。
【００７５】
次に、データ送受信部４は、データ処理部３から渡されたデータを、コンテンツ要求に対する処理結果として端末Ｃに送信する。つまり、端末Ｃは、少なくとも、基準ＵＲＬ、および、コンテンツデータまたはコンテンツのＵＲＬを受信する。もし、コンテンツデータおよびコンテンツのＵＲＬの両方が同時に端末Ｃに送信されると、端末Ｃの挙動は不定になる。
【００７６】
●ステップＳ３
端末Ｃのデータ送受信部７は、コンテンツサーバＳから受信したデータを解析し、受信データに基準ＵＲＬが含まれる場合、基準ＵＲＬをＵＲＬ処理部６に渡す。この基準ＵＲＬは、例えば要求したコンテンツの再生処理が終了するまで、ＵＲＬ処理部６に保持される。また、受信データが基準ＵＲＬに加えて補完ＵＲＬを含む場合、基準ＵＲＬと同様に、補完ＵＲＬはＵＲＬ処理部６に渡される。
【００７７】
データ送受信部７は、受信データにコンテンツの実体データが含まれる場合、コンテンツの実体データを、順次、コンテンツ再生部８に渡す。その後、処理は後述するステップＳ７に移行する。また、受信データにコンテンツのＵＲＬが含まれる場合、次に説明するステップＳ４が実行される。
【００７８】
●ステップＳ４
ステップＳ４は、コンテンツサーバＳから再生対象のコンテンツのＵＲＬを受信した端末ＣのＵＲＬ処理部６によって実行される。従って、コンテンツの実体データが受信された場合、ステップＳ４は実行されない。なお、ＵＲＬ処理部６は、保持する基準ＵＲＬ（および補完ＵＲＬ）を基に、受信したＵＲＬを再計算して絶対ＵＲＬを導き出す。
【００７９】
図９はＵＲＬ処理部によるＵＲＬの再計算を示すフローチャートである。
【００８０】
まず、受信したＵＲＬの書式を解析し、相対ＵＲＬか否かを判定する（Ｓ１１）。相対ＵＲＬでなければ受信したＵＲＬを絶対ＵＲＬとし（Ｓ１４）、絶対ＵＲＬをデータ送受信部７に返す（Ｓ１８）。
【００８１】
受信したＵＲＬが相対ＵＲＬの場合は、基準ＵＲＬを保持しているか否かを判定する（Ｓ１２）。基準ＵＲＬを保持していない場合は、現在のコンテクストとしてコンテンツ再生部８が直前に再生したコンテンツの位置を示すＵＲＬを基準ＵＲＬとみなして、絶対ＵＲＬを導き出し（Ｓ１５）、得られた絶対ＵＲＬをデータ送受信部７に返す（Ｓ１８）。
【００８２】
受信したＵＲＬが相対ＵＲＬで、かつ、基準ＵＲＬを保持している場合は、補完ＵＲＬを保持しているか否かを判定する（Ｓ１３）。補完ＵＲＬを保持していない場合は、基準ＵＲＬに従ってＵＲＬを再計算し、絶対ＵＲＬを導き出し（Ｓ１６）、得られた絶対ＵＲＬをデータ送受信部７に返す（Ｓ１８）。
【００８３】
受信したＵＲＬが相対ＵＲＬで、かつ、基準ＵＲＬおよび補完ＵＲＬを保持している場合は、基準ＵＲＬに従ってＵＲＬを再計算し、さらに、然るべき位置に補完ＵＲＬを埋め込んだ絶対ＵＲＬを合成し（Ｓ１７）、得られた絶対ＵＲＬをデータ送受信部７に返す（Ｓ１８）。
【００８４】
●ステップＳ５、Ｓ６
ステップＳ５は、ステップＳ３において、再生対象のコンテンツを示すＵＲＬが受信された場合に実行される。もし、コンテンツの実体データが受信された場合、ステップＳ５は実行されない。
【００８５】
データ送受信部７は、ステップＳ５で、コンテンツサーバＳに対して、ＵＲＬ処理部６から返された絶対ＵＲＬを指定したコンテンツ要求処理を実行し、ステップＳ６で、コンテンツデータの受信処理を実行する。
【００８６】
●ステップＳ７、Ｓ８
ステップＳ７は、ステップＳ３およびＳ６において、再生対象のコンテンツの実体データが受信された場合に実行される。
【００８７】
コンテンツ再生部８は、データ送受信７から渡されたコンテンツデータの展開、復号などの処理を行い、コンテンツデータが外部のコンテンツデータを参照する外部参照ＵＲＬを含むか否かを判定する。外部参照ＵＲＬが含まれる場合、ステップＳ４のＵＲＬ再計算（ＵＲＬ処理部６）によって、外部参照ＵＲＬは絶対ＵＲＬに変換される。データ送受信部７は、ステップＳ７で、コンテンツサーバＳに対して、絶対ＵＲＬを指定した外部参照コンテンツ要求処理を実行し、ステップＳ８で、外部参照コンテンツデータの受信処理を実行する。
【００８８】
以降、ステップＳ４からＳ８までの処理が、コンテンツの再生終了まで繰り返される。
【００８９】
なお、図７に示す例において、「Ｖ．ｍｐ４」というコンテンツが相対ＵＲＬを用いて外部参照される場合、ステップＳ４のＵＲＬ再計算によって「ｈｔｔｐ：／／ｓ．ｃｏｍ／Ｐ．ｃｇｉ？Ｖ．ｍｐ４」という絶対ＵＲＬが得られる。
【００９０】
このように実施形態の配信方法は、マルチメディアコンテンツを配信する情報処理装置の配信方法であって、アドレス情報を用いて外部データを参照するマルチメディアコンテンツを保管し、外部データの適正な位置を示す絶対アドレス情報を導出するための基準アドレス情報を管理し、マルチメディアコンテンツの配信要求を受信すると、外部データのアドレス情報を計算するための基準アドレス情報を含む情報を返す。
【００９１】
上記の配信方法によって配信されるマルチメディアコンテンツを再生する場合は、再生するマルチメディアコンテンツの配信を要求し、要求に対する応答に外部データのアドレス情報を計算するための基準アドレス情報が含まれる場合、基準アドレス情報に基づき、外部データの適正な位置を示す絶対アドレス情報を計算し、絶対アドレス情報に基づき、外部データを要求する。
【００９２】
上記の配信方法を配信装置に適用する場合は、アドレス情報を用いて外部データを参照するマルチメディアコンテンツを保管する保管部と、外部データの適正な位置を示す絶対アドレス情報を導出するための基準アドレス情報を管理する管理部と、マルチメディアコンテンツの配信要求を受信して、外部データのアドレス情報を計算するための基準アドレス情報を含む情報を返す通信部とを備えればよい。
【００９３】
その場合、好ましくは、管理部は、基準アドレス情報を補完するための一つ以上の補完アドレス情報を管理し、通信部に基準アドレス情報および補完アドレス情報を返させる。また、通信部は、基準アドレス情報を、通信プロトコルによって規定される返信情報の拡張可能な領域に記述すればよい（詳細は後述する）。
【００９４】
上記の再生方法を再生装置に適用する場合は、マルチメディアコンテンツを再生する再生部と、再生するマルチメディアコンテンツの配信要求に対する応答に外部データのアドレス情報を計算するための基準アドレス情報が含まれる場合、基準アドレス情報に基づき、外部データの適正な位置を示す絶対アドレス情報を計算する計算部と、配信要求および絶対アドレス情報に基づく外部データの要求を送信し、応答および外部データを受信する通信部とを備えればよい。
【００９５】
その場合、好ましくは、計算手段は、基準アドレス情報および外部データの相対アドレス情報から絶対アドレス情報を計算すればよい。
【００９６】
次に、具体的な実施例を説明する。
【００９７】
【実施例１】
実施例１として、実施形態のコンテンツ配信システムが、ＨＴＴＰを使用するインターネットサーバと、ＨＴＴＰによる通信機能をもつマルチメディアプレーヤの二者間で実現される場合を説明する。
【００９８】
なお、以下の説明では、コンテンツサーバＳのデータ送受信部４はＡｐａｃｈｅ^（ＴＭ）などのＨＴＴＰサーバプログラムとして、データ処理部３はＣＧＩプログラムとしてそれぞれ実装されるものとする。また、コンテンツ視聴者の端末Ｃは、図１０に示すように、コンテンツのＵＲＬを入力するインタフェイスおよびコンテンツの表示領域をもつプレーヤとする。プレーヤはハードウェア装置であっても、コンピュータ上で動作するアプリケーションソフトウェアであってもよい。さらに、インターネットサーバに登録されたコンテンツは、外部から直接参照することができない位置に格納されていて、「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ」というＵＲＬで示されるＣＧＩプログラムを介して取得されることにする。
【００９９】
インターネットサーバは、プレーヤのコンテンツ要求に対し、図１１に示すようなＨＴＴＰ出力を返す。データの先頭から途中の空行までは、データ形式やデータサイズといったＨＴＴＰ出力データに付随する情報（いわゆるＨＴＴＰヘッダ情報）が記述されている。空行以降は、要求されたコンテンツの実体データが記述される。ＨＴＴＰ出力データの記述形式や、ＨＴＴＰヘッダ情報の詳細に関しては、ＨＴＴＰの仕様を示すＲＦＣ ２６１６に記述されているため、これ以上の説明は省略する。
【０１００】
ＲＦＣ ２６１６には、基準ＵＲＬを表現するための標準的なヘッダ項目は定義されていない。そこで、実施例１においては、ヘッダ項目「ｘ−Ｃｏｎｔｅｎｔ−Ｂａｓｅ：」定義して基準ＵＲＬをプレーヤに提供する。具体的には、図１１に示すＨＴＴＰ出力データの「ｘ−Ｃｏｎｔｅｎｔ−Ｂａｓｅ： ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？」が基準ＵＲＬを示す行で、基準ＵＲＬを表すヘッダ項目「ｘ−Ｃｏｎｔｅｎｔ−Ｂａｓｅ：」に続く値「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？」が基準ＵＲＬに相当する。
【０１０１】
なお、ＨＴＴＰ出力データ中にヘッダ項目「ｘ−Ｃｏｎｔｅｎｔ−Ｂａｓｅ：」がない場合、現在のコンテクストのディレクトリ位置を示すＵＲＬが基準ＵＲＬとみなされ、ＲＦＣ １７３８で規定されている標準的なＵＲＬ再計算が行われる。
【０１０２】
次に、実施例１における処理を、図７に示したステップＳ１からＳ８の処理に対応させて説明する。
【０１０３】
取得するコンテンツのＵＲＬとして「ｈｔｔｐ：／／ｓ．ｃｏｍ／Ｐ．ｃｇｉ？Ｃ．ｍｐ４」を利用者が入力すると、プレーヤは、このＵＲＬを含むコンテンツ要求をインターネットサーバに発行する（Ｓ１）。インターネットサーバは、受信したコンテンツ要求に対して、図１１に示すデータを生成してプレーヤに送信する（Ｓ２）。
【０１０４】
プレーヤは、受信したＨＴＴＰ出力データを解析して、ＨＴＴＰヘッダ領域に「ｘ−Ｃｏｎｔｅｎｔ−Ｂａｓｅ：」が含まれていれば、その値「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？」を基準ＵＲＬとして抽出し、ＵＲＬ処理部６に渡す（Ｓ３）。
【０１０５】
プレーヤは、コンテンツデータを再生中に外部参照ＵＲＬ「Ｖ．ｍｐ４」を検出すると、検出した外部参照ＵＲＬをＵＲＬ処理部６に渡してＵＲＬ再計算（Ｓ４）を実行させ、得られた絶対ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｖ．ｍｐ４」を含む外部参照コンテンツ要求をインターネットサーバに送信する（Ｓ７）。
【０１０６】
以上のような処理を実装することで、コンテンツ中に相対ＵＲＬを用いた外部参照が含まれている場合でも、外部参照コンテンツを不具合なく再生することが可能になる。
【０１０７】
なお、上記では、通信プロトコルとしてＨＴＴＰを用いる例を説明したが、ＨＴＴＰヘッダに相当する拡張可能なプロトコルヘッダ領域を用いて基準ＵＲＬを記述することが可能であれば、どのようなプロトコルを用いてもよい。
【０１０８】
【実施例２】
実施例２として、基準ＵＲＬなどのデータが、実施例１のようにプロトコルヘッダ領域に記述されるのではなく、通信されるデータ本体の一部として記述される場合を説明する。
【０１０９】
実施例１で説明した方法は、基準ＵＲＬなどのデータを記述するためにプロトコルヘッダ領域が拡張可能な通信方式を用いる場合には有効だが、それ以外の通信方式に対しては適用することができない。従って、通信されるデータ本体に基準ＵＲＬなどを記述する方が、より多くの通信方式に対応することができ、柔軟性が高い方法と考えられる。
【０１１０】
なお、実施例２の動作環境は、実施例１と同じとするが、コンテンツサーバＳに相当するインターネットサーバから返されるＨＴＴＰ出力は、図１２に示すようなデータとする。
【０１１１】
図１２に示すＨＴＴＰ出力は、先頭行から最初の空行までがＨＴＴＰヘッダ領域を、最初の空行以降がＨＴＴＰメッセージ本体を示している。また、最初の空行から二番目の空行までが、コンテンツの内容を示すデータや補助的な通信パラメータなどを記述するために付加されたデータ領域である。さらに、二番目の空行以降がコンテンツの内容を示すデータ領域である。すなわち、実施例２では、ＨＴＴＰメッセージ本体の先頭から空行が出現するまでの領域を付加データ領域として、任意のデータを記述できるようにする。
【０１１２】
付加データ領域に記述されるデータは、実施例２が前提とするシステムで独自に定義されたＸＭＬで記述され、コンテンツに関する情報を記述するタグ「ＳｔｒｅａｍＢｏｄｙ」の属性「Ｂａｓｅ」に基準ＵＲＬが記述されるものとする。すなわち、属性「Ｂａｓｅ」のデータ値「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？」が基準ＵＲＬに相当する。
【０１１３】
続いて、実施例２における処理を、図７に示したステップＳ１からＳ８の処理に対応させて説明する。
【０１１４】
コンテンツ取得ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４」が利用者から入力されると、プレーヤはこのコンテンツ取得ＵＲＬを用いて、インターネットサーバにコンテンツ取得要求を発行する（Ｓ１）。
【０１１５】
インターネットサーバは、コンテンツ取得要求に対する結果として、図１２に示すデータを生成し、プレーヤに送出する（Ｓ２）。
【０１１６】
プレーヤは、受信データに含まれる付加データ領域の構文を解析する。ＸＭＬ構文中にタグ「ＳｔｒｅａｍＢｏｄｙ」の属性「Ｂａｓｅ」が含まれていれば、基準ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？」を抽出し、ＵＲＬ処理部６に受け渡す（Ｓ３）。
【０１１７】
プレーヤは、受信データに含まれるデータ列を、タグ「ＳｔｒｅａｍＢｏｄｙ」の属性「ＭＩＭＥＴｙｐｅ」に記述された「ｖｉｄｅｏ／ｍｐ４」より、ＭＰＥＧ−４形式のコンテンツデータとみなして再生する。再生中にコンテンツに含まれる外部参照ＵＲＬ「Ｖ．ｍｐ４」を検出したら、ＵＲＬ処理部６に渡してＵＲＬ再計算処理（Ｓ４）を実行し、得られた絶対ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｖ．ｍｐ４」を用いて、インターネットサーバに外部参照コンテンツを要求する（Ｓ７）。
【０１１８】
以上のような方法で、使用するプロトコルがどのようなものであっても、実施例１で示されるような相対ＵＲＬを用いた外部参照を不具合なく行えるようになる。
【０１１９】
なお、実施例２では、付加データを記述するためのデータ形式として、定義の拡張が容易で運用時の柔軟性に富むＸＭＬを用いたが、基準ＵＲＬなどのデータを記述できればどのようなデータ形式が用いられてもよい。例を挙げれば、通信データ量の圧縮を図るのであれば、可変長のバイナリ形式で記述されてもよいし、既存の標準規格との親和性を考慮するのであれば、前記ＩＥＴＦによってＲＦＣ ２０４５として規定されているＭｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎ （ＭＩＭＥ）などの標準規格化された形式を用いてもよい。何れの形式であっても、本発明の基本原理には影響しない。
【０１２０】
【実施例３】
実施例３として、基準ＵＲＬに加えて、前述した補完ＵＲＬが用いられる場合を説明する。
【０１２１】
基準ＵＲＬおよび相対ＵＲＬではコンテンツの正しい位置を示すＵＲＬを合成するのに不充分な場合、一つ以上の補完ＵＲＬを指定することを許す。以下では、実施例２に示した例に、一つの補完ＵＲＬが指定された場合を例に説明する。従って、動作環境は実施例２と同じものが用いられる。ただし、インターネットサーバに対してコンテンツを要求するためのＵＲＬには「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４＆ｒａｔｅ＝３８４ｋ」といったパラメータが付加されたＵＲＬが用いられるものとする。
【０１２２】
図１３は、実施例３で用いられたＨＴＴＰ出力に、補完ＵＲＬを示すデータが追加された出力例を示す。この例では、最初の空行から始まる付加データ領域に記述されたＸＭＬデータ中の、タグ「ＳｔｒｅａｍＢｏｄｙ」の属性「Ｐａｒａｍ」に補完ＵＲＬが記述される。すなわち、属性「Ｐａｒａｍ」のデータ値「＆ｒａｔｅ＝３８４ｋ」が補完ＵＲＬに相当する。
【０１２３】
実施例３のシステムにおいて、補完ＵＲＬは合成されるＵＲＬの末尾に付加されるものと想定する。すなわち、ＵＲＬ再計算処理（Ｓ４）によって最終的に導出される絶対ＵＲＬは「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４＆ｒａｔｅ＝３８４ｋ」になる。
【０１２４】
補完ＵＲＬとして用いられるデータの内容は、実装されるシステムの仕様に依存するものであり、ここではとくに規定しない。実施例３における補完ＵＲＬ「＆ｒａｔｅ＝３８４ｋ」は、要求されるコンテンツのビットレートの選択機能を有するシステムにおいて、プレーヤからビットレート（この例では３８４Ｋｂｐｓ）を指定する例として示すが、当然、その内容はシステムによって異なるため、補完ＵＲＬは任意の目的で任意の値を用いることができる。
【０１２５】
また、補完ＵＲＬは複数指定されていてもよい。その場合、ＵＲＬ再計算処理（Ｓ４）において、複数の補完ＵＲＬがどのような順序で合成されるかといったルールは、システムの仕様に依存して定められるものであり、ここではとくに規定しない。
【０１２６】
引き続き、実施例３における処理を、図７に示したステップＳ１からＳ８の処理に対応させて説明する。
【０１２７】
コンテンツ取得ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４＆ｒａｔｅ＝３８４ｋ」が利用者から入力されると、プレーヤは、このコンテンツ取得ＵＲＬを用いて、インターネットサーバにコンテンツ取得要求を発行する（Ｓ１）。
【０１２８】
インターネットサーバは、コンテンツ取得要求に対する結果として、図１３で示されるデータを生成し、プレーヤに送出する（Ｓ２）。
【０１２９】
プレーヤは、受信データに含まれる付加データ領域の構文を解析する。ＸＭＬ構文中にタグ「ＳｔｒｅａｍＢｏｄｙ」の属性「Ｂａｓｅ」が含まれていれば、基準ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？」を抽出し、ＵＲＬ処理部６に渡す。さらに、属性「Ｐａｒａｍ」が含まれていれば、補完ＵＲＬ「＆ｒａｔｅ＝３８４ｋ」を抽出して、ＵＲＬ処理部６に渡す（Ｓ３）。
【０１３０】
プレーヤは、受信データに含まれるデータ列を、タグ「ＳｔｒｅａｍＢｏｄｙ」の属性「ＭＩＭＥＴｙｐｅ」で記述される「ｖｉｄｅｏ／ｍｐ４」より、ＭＰＥＧ−４形式のコンテンツデータとみなして再生する。再生中にコンテンツに含まれる外部参照ＵＲＬ「Ｖ．ｍｐ４」を検出したら、ＵＲＬ処理部６に渡してＵＲＬ再計算処理（Ｓ４）を実行し、得られた絶対ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｖ．ｍｐ４＆ｒａｔｅ＝３８４ｋ」を用いて、インターネットサーバに外部参照コンテンツを要求する（Ｓ７）。
【０１３１】
【実施例４】
実施例４として、視聴者からのコンテンツ要求に対して、コンテンツサーバがコンテンツ取得用のＵＲＬを返す場合を説明する。
【０１３２】
実施例１から３では、コンテンツ取得ＵＲＬが予め判っていて、端末の利用者がコンテンツ取得ＵＲＬを入力することを前提にして説明した。しかし、実際のケースでは、コンテンツ取得ＵＲＬが予め知られていることは非現実的である。通常は、何らかの形でコンテンツサーバからコンテンツ取得ＵＲＬが通知され、そのＵＲＬを用いてコンテンツデータの取得を行うことになると思われる。その場合の具体例を実施例４として説明する。
【０１３３】
実施例４では、コンテンツ要求の手段として、Ｍｉｃｒｏｓｏｆｔ（Ｒ）社、ＩＢＭ（Ｒ）社などによって提唱され、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ （Ｗ３Ｃ）によって規格化されたＸＭＬベースの分散処理プロトコルであるＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ （ＳＯＡＰ）を用いるとして説明する。なお、ＳＯＡＰによるメッセージ交換を行うための通信プロトコルは、前記の実施例と同様にＨＴＴＰとする。従って、コンテンツサーバは、ＳＯＡＰメッセージを処理することが可能なＨＴＴＰ通信機能をもつインターネットサーバであり、コンテンツ視聴者の端末は、同じくＳＯＡＰメッセージを処理できるＨＴＴＰ通信機能を備えるプレーヤである。
【０１３４】
実施例４では、プレーヤは、視聴するコンテンツを識別するために一意に割り当てられたコンテンツＩＤとして「０００１」というデータを指定してインターネットサーバにコンテンツを要求し、インターネットサーバは、コンテンツＩＤに該当するコンテンツのＵＲＬとして「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４」というデータを返すとする。ただし、このＵＲＬで示されるＣＧＩプログラム「ｐｌａｙ．ｃｇｉ」は、前記の実施例とは異なり、基準ＵＲＬなどの付加データは含まないコンテンツデータのみを返すものとする。また、コンテンツは、前記の実施例と同様に、図３に示すような内容を含むことにする。
【０１３５】
図１４は、プレーヤがコンテンツ要求を行う際にインターネットサーバに送信するＳＯＡＰリクエストメッセージを表す。メッセージ中のＸＭＬタグ ＜ｍ：ＧｅｔＣｏｎｔｅｎｔ＞ は、このメッセージがコンテンツの取得を要求するメッセージであることを示す。また、付随するタグ ＜ＣｏｎｔｅｎｔＩＤ＞ で、要求するコンテンツのコンテンツＩＤ「０００１」を指定する。
【０１３６】
このようなＳＯＡＰリクエストメッセージに対して、インターネットサーバは図１５で示されるようなＳＯＡＰレスポンスメッセージを返すとする。メッセージ中のＸＭＬタグ ＜ｍ：ＧｅｔＣｏｎｔｅｎｔＲｅｓｐｏｎｓｅ＞ は、コンテンツの取得要求に対するレスポンスであることを示している。また、付随するタグ ＜Ｓｒｃ＞ でコンテンツ取得ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４」が、タグ ＜Ｂａｓｅ＞ で基準ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？」が指定される。
【０１３７】
ＳＯＡＰレスポンスメッセージを受信したプレーヤは、タグ ＜Ｓｒｃ＞ で指定されたコンテンツ取得ＵＲＬを指定するこでによって、コンテンツデータの取得を行う。ちなみに、ＳＯＡＰに関する詳細については、ＳＯＡＰ仕様書（ｈｔｔｐ：／／ｗｗｗ．ｗ３ｃ．ｏｒｇ／ＴＲ／ＳＯＡＰ／）に正確な記述があるため、ここでは詳細な説明を省略する。
【０１３８】
引き続き、実施例４における処理を、図７に示したステップＳ１からＳ８の処理に対応させて説明する。
【０１３９】
コンテンツＩＤ「０００１」が利用者から入力されると、プレーヤはこのコンテンツＩＤから図１４で示されるＳＯＡＰリクエストメッセージを生成し、インターネットサーバに送出する（Ｓ１）。
【０１４０】
インターネットサーバは、ＳＯＡＰリクエストメッセージを解析して、コンテンツＩＤ「０００１」に該当するコンテンツのＵＲＬを表す「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４」および基準ＵＲＬを表す「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？」を含む、図１５に示されるＳＯＡＰレスポンスメッセージを生成し、プレーヤに送出する（Ｓ２）。
【０１４１】
プレーヤは、ＳＯＡＰレスポンスメッセージを受信後、その内容を解析し、タグ ＜ｍ：ＧｅｔＣｏｎｔｅｎｔＲｅｓｐｏｎｓｅ＞ 中にタグ ＜Ｓｒｃ＞ および ＜Ｂａｓｅ＞ 含まれていれば、データとして指定されたＵＲＬを抽出し、ＵＲＬ処理部６に渡す（Ｓ３）。
【０１４２】
プレーヤは、ＳＯＡＰレスポンスメッセージから抽出したＵＲＬを用いて、ＵＲＬ処理部６においてＵＲＬ再計算処理（Ｓ４）を行う。図１５の出力例では、コンテンツＵＲＬは絶対ＵＲＬとして指定されているため、再計算の結果として、同じ絶対ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４」が返される。
【０１４３】
プレーヤは、再計算処理（Ｓ４）によって得られた絶対ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４」を指定して、インターネットサーバにコンテンツを要求する（Ｓ５）。
【０１４４】
プレーヤは、受信したコンテンツデータを再生する。再生中にコンテンツに含まれる外部参照ＵＲＬ「Ｖ．ｍｐ４」を検出すると、ＵＲＬ処理部６に渡してＵＲＬ再計算処理（Ｓ４）を実行し、得られた絶対ＵＲＬ「ｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｖ．ｍｐ４」を用いて、インターネットサーバに外部参照コンテンツを要求する（Ｓ７）。
【０１４５】
以上のような手順で処理を行うことで、最初にコンテンツサーバにＵＲＬを問い合わせ、引き続き取得されたＵＲＬを用いてコンテンツデータを取得するといった、二段階のコンテンツ要求を行うことが可能である。
【０１４６】
なお、実施例４では、コンテンツ要求のためのプロトコルとしてＳＯＡＰを用いる例を説明したが、どのようなプロトコルが用いてもよい。ＳＯＡＰの実行環境を導入することが困難な場合は、実施例２で示したような独自定義のＸＭＬを用いてデータを記述してもよい。また、コンテンツをストリーミング配信する、いわゆるストリーミングサーバは、ＩＥＴＦによってＲＦＣ ２３２７として規定されるＳｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＤＰ）と呼ばれるデータ記述手段を用いてＵＲＬの指定を行う場合が多いが、そのような方法を用いてもよい。
【０１４７】
【実施例５】
実施例５では、コンテンツサーバが視聴者からのコンテンツ要求に対して、コンテンツ取得用のＵＲＬ、前記の基本ＵＲＬおよび補完ＵＲＬを返す場合を説明する。
【０１４８】
実施例５では、コンテンツ視聴者の端末は、ＩｎｔｅｒｎｅｔＥｘｐｌｏｒｅｒやＮｅｔｓｃａｐｅ（Ｒ） ＮａｖｉｇａｔｏｒのようなＷｅｂブラウザアプリケーション（以降「Ｗｅｂブラウザ」と呼ぶ）と、ＡｃｔｉｖｅＸコントロールやＮｅｔｓｃａｐｅ（Ｒ）プラグインなどのＷｅｂブラウザ連動プログラムとして実装されたソフトウェアコンポーネント（以降「プレーヤモジュール」と呼ぶ）との組み合わせを想定する。
【０１４９】
また、コンテンツは、前記の実施例と同様に、図３に示されるような内容を含み、コンテンツ取得ＵＲＬは実施例３と同様のＵＲＬ、コンテンツ要求ＵＲＬは「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？ＩＤ＝０００１」であるとする。コンテンツ要求ＵＲＬは、図８で示されるようなコンテンツ一覧ページなどから取得することができるものとする。
【０１５０】
コンテンツ要求ＵＲＬが利用者によって入力されると、Ｗｅｂブラウザは、コンテンツ要求ＵＲＬを解釈し、サーバにコンテンツを要求する。コンテンツ要求を受信したサーバは、図１６に示すＨＴＭＬデータを出力する。プレーヤモジュールがＡｃｔｉｖｅＸコントロール形式で作成されている場合、データ中のタグ ＜ＯＢＪＥＣＴ＞ をＷｅｂブラウザが解釈してプレーヤモジュールが起動される。プレーヤモジュールがＮｅｔｓｃａｐｅ（Ｒ）プラグイン形式で作成されている場合、データ中のタグ ＜ＥＭＢＥＤ＞ をＷｅｂブラウザが解釈してプレーヤモジュールが起動される。
【０１５１】
プレーヤモジュールがＡｃｔｉｖｅＸコントロールの場合、図１６に示すタグ ＜ＰＡＲＡＭＮＡＭＥ＝”ＳＲＣ” ＶＡＬＵＥ＝”ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４＆ｒａｔｅ＝３８４ｋ”＞ 中のパラメータＶＡＬＵＥで与えられる「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４＆ｒａｔｅ＝３８４ｋ」がコンテンツ取得ＵＲＬとして、タグ ＜ＰＡＲＡＭＮＡＭＥ＝”ＢａｓｅＵＲＬ” ＶＡＬＵＥ＝”ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？”＞ 中のパラメータＶＡＬＵＥで与えられる「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？」が基準ＵＲＬとして、タグ ＜ＰＡＲＡＭＮＡＭＥ＝”ＲｅｑｕｅｓｔＰＡＲＡＭ” ＶＡＬＵＥ＝”＆ｒａｔｅ＝３８４ｋ”＞ のパラメータＶＡＬＵＥで与えられる「＆ｒａｔｅ＝３８４ｋ」が補完ＵＲＬとして、それぞれ渡される。
【０１５２】
プレーヤモジュールがＮｅｔｓｃａｐｅ（Ｒ）プラグインの場合、図１６のタグＥＭＢＥＤ中のパラメタＳＲＣで指定される「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｃ．ｍｐ４」がコンテンツ取得ＵＲＬとして、パラメタＢａｓｅＵＲＬで指定される「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？」が基準ＵＲＬとして、パラメタＲｅｑｕｅｓｔＰＡＲＡＭで指定されている「＆ｒａｔｅ＝３８４ｋ」が補完ＵＲＬとして、それぞれ渡される。
【０１５３】
図１６に示すＨＴＭＬデータを受信したＷｅｂブラウザは、コンテンツ取得ＵＲＬを使ってコンテンツサーバにコンテンツを要求する。コンテンツサーバは、図１７に示すコンテンツデータを出力する。
【０１５４】
図１７に示すコンテンツデータは、ＨＴＴＰヘッダとコンテンツデータのみから構成される。図１７のデータは「ＨＴＴＰ／１．１ ２００ ＯＫ」から「Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： １７３２０５０」までの最初の三行がＨＴＴＰヘッダで、空行以下の「…」で示す部分がコンテンツデータである。Ｗｅｂブラウザは、このデータを受信してプレーヤモジュールに渡し、プレーヤモジュールに再生を開始させる。
【０１５５】
コンテンツ再生中に外部参照”Ｖ．ｍｐ４”を検出した場合、ＵＲＬ処理部６は基準ＵＲＬおよび補完ＵＲＬを用いてＵＲＬ再計算（Ｓ４）を行い、得られた「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｖ．ｍｐ４＆ｒａｔｅ＝３８４ｋ」をコンテンツサーバに要求する。
【０１５６】
引き続き、実施例５における処理を、図７に示したステップＳ１からＳ８の処理に対応させて説明する。
【０１５７】
コンテンツ要求ＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？ＩＤ＝０００１」が入力されると、Ｗｅｂブラウザは、コンテンツサーバにコンテンツを要求する（Ｓ１）。
【０１５８】
コンテンツサーバは、コンテンツの要求を受信すると、図１６に示すＨＴＭＬデータを生成し、Ｗｅｂブラウザに送出する（Ｓ２）。
【０１５９】
Ｗｅｂブラウザは、図１６に示すＨＴＭＬデータのタグ ＜ＯＢＪＥＣＴ＞ または ＜ＥＭＢＥＤ＞ を解釈してプレーヤモジュールを起動すると同時に、ＵＲＬ処理部６に基準ＵＲＬおよび補完ＵＲＬの情報を渡す（Ｓ３）。
【０１６０】
Ｗｅｂブラウザは、図１６のデータのコンテンツ要求ＵＲＬをコンテンツサーバに要求する。この要求に対してコンテンツサーバから送出されるデータは、データ送受信部７を通してプレーヤモジュールのコンテンツ再生部８に渡される（Ｓ６）。
【０１６１】
プレーヤモジュールは受信したコンテンツデータを再生し、その再生中にコンテンツに外部参照「Ｖ．ｍｐ４」を検出すると、ＵＲＬ処理部６に渡してＵＲＬ再計算（Ｓ４）を実行させ、得られたＵＲＬ「ｈｔｔｐ：／／ｓ．ｃｏｍ／ｐｌａｙ．ｃｇｉ？Ｖ．ｍｐ４＆ｒａｔｅ＝３８４ｋ」を用いてコンテンツサーバに外部参照コンテンツを要求する（Ｓ７）。
【０１６２】
このように、上記の各実施例によれば、特定の実行環境に依存せず、柔軟に運用することができ、かつ、コンテンツサーバの負荷を最小限に抑えながら、外部のデータを参照するマルチメディアコンテンツを正しく再生することができる。
【０１６３】
【他の実施形態】
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【０１６４】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１６５】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１６６】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【０１６７】
【発明の効果】
以上説明したように、本発明によれば、外部のデータを参照するマルチメディアコンテンツを、正しく再生できるように配信し、再生することができる。
【図面の簡単な説明】
【図１】ＭＰＥＧ−４においてシーンがどのように合成されるかを簡単に説明する図、
【図２】シーン記述情報およびオブジェクトディスクリプタ情報を用いて、どのようにオブジェクトの関連付けを行うかを簡単に説明する図、
【図３】ＯＤ＿ＩＤおよびＵＲＬによるエレメンタリストリームの参照例を示す図、
【図４】典型的なコンテンツ配信システムの構成例を示す図、
【図５】コンテンツが非公開の位置に保管されている場合のコンテンツ配信システムの構成例を示す図、
【図６】実施形態のコンテンツ配信システムの構成例を説明する図、
【図７】基準ＵＲＬの提示およびＵＲＬの再計算などの処理を説明する図、
【図８】ＨＴＭＬデータを用いる場合のコンテンツ要求用のＵＲＬの送付サンプルを示す図、
【図９】ＵＲＬ処理部によるＵＲＬの再計算を示すフローチャート、
【図１０】コンテンツのＵＲＬを入力するインタフェイスおよびコンテンツの表示領域をもつプレーヤの例を示す図、
【図１１】ＨＴＴＰ出力例を示す図、
【図１２】ＨＴＴＰ出力例を示す図、
【図１３】ＨＴＴＰ出力に、補完ＵＲＬを示すデータが追加された出力例を示す図、
【図１４】ＳＯＡＰリクエストメッセージを表す図、
【図１５】ＳＯＡＰレスポンスメッセージを表す図、
【図１６】ＨＴＭＬデータの出力例を示す図、
【図１７】コンテンツデータを出力例を示す図である。

Claims (9)

1. マルチメディアコンテンツを配信する情報処理装置の配信方法であって、
   アドレス情報を用いて外部データを参照するマルチメディアコンテンツを保管し、
   前記外部データの適正な位置を示す絶対アドレス情報を導出するための基準アドレス情報を管理し、
   前記マルチメディアコンテンツの配信要求を受信すると、前記外部データのアドレス情報を計算するための前記基準アドレス情報を含む情報を返すことを特徴とする配信方法。
2. 請求項１に記載された配信方法を実行するコンピュータプログラム。
3. マルチメディアコンテンツを再生する情報処理装置の再生方法であって、
   再生するマルチメディアコンテンツの配信を要求し、
   前記要求に対する応答に外部データのアドレス情報を計算するための基準アドレス情報が含まれる場合、前記基準アドレス情報に基づき、前記外部データの適正な位置を示す絶対アドレス情報を計算し、
   前記絶対アドレス情報に基づき、前記外部データを要求することを特徴とする再生方法。
4. 請求項３に記載された再生方法を実行するコンピュータプログラム。
5. マルチメディアコンテンツを配信する配信装置であって、
   アドレス情報を用いて外部データを参照するマルチメディアコンテンツを保管する保管手段と、
   前記外部データの適正な位置を示す絶対アドレス情報を導出するための基準アドレス情報を管理する管理手段と、
   前記マルチメディアコンテンツの配信要求を受信して、前記外部データのアドレス情報を計算するための前記基準アドレス情報を含む情報を返す通信手段とを有することを特徴とする配信装置。
6. 前記管理手段は、前記基準アドレス情報を補完するための一つ以上の補完アドレス情報を管理し、前記通信手段に前記基準アドレス情報および前記補完アドレス情報を返させることを特徴とする請求項５に記載された配信装置。
7. 前記通信手段は、前記基準アドレス情報を、通信プロトコルによって規定される返信情報の拡張可能な領域に記述することを特徴とする請求項５に記載された配信装置。
8. マルチメディアコンテンツを再生する再生手段と、
   再生するマルチメディアコンテンツの配信要求に対する応答に、外部データのアドレス情報を計算するための基準アドレス情報が含まれる場合、前記基準アドレス情報に基づき、前記外部データの適正な位置を示す絶対アドレス情報を計算する計算手段と、
   前記配信要求および前記絶対アドレス情報に基づく外部データの要求を送信し、前記応答および前記外部データを受信する通信手段とを有することを特徴とする再生装置。
9. 前記計算手段は、前記基準アドレス情報および前記外部データの相対アドレス情報から前記絶対アドレス情報を計算することを特徴とする請求項８に記載された再生装置。

Images