(57)【要約】有線または無線通信のための方法、装置、システム、およびソフトウェアアプリケーションである。DRM（デジタル権利管理）メディアコンテンツのためのファイルフォーマットを提供する。該ファイルフォーマットは、メディアコンテンツのコンテンツロケーション情報を示すためのテキストコンテンツロケーションヘッダを有する。【選択図】図3
2007525759.tif 000002
【特許請求の範囲】
【請求項１】
通信方法であって、
メディアコンテンツのためのファイルフォーマットを準備するステップと、
前記ファイルフォーマットを用いて、前記メディアコンテンツのコンテンツロケーション情報を示すステップとを含む、通信方法。
【請求項２】
前記ファイルフォーマットは、前記メディアコンテンツのコンテンツロケーション情報を前記ファイルフォーマット内に格納するように構成される、請求項1に記載の方法。
【請求項３】
前記メディアコンテンツは前記ファイルフォーマットを有するファイルに含まれ、前記ファイルフォーマットは、前記ファイル内の該メディアコンテンツが取り出されるべきターゲットロケーション、またはそれが適切に消費されるべきかどうかを示す、請求項1に記載の方法。
【請求項４】
前記フォーマットはファイルヘッダを含み、そのすぐ後ろにコンテナボックスが続き、前記コンテナボックスは共通のヘッダボックスを有し、前記共通のヘッダボックスは前記コンテンツロケーション情報を格納するためのテキストヘッダを備える、請求項1に記載の方法。
【請求項５】
前記方法は、1つ以上のメディアコンテンツを有する単一のファイル内に仮想ファイルツリーを構築するステップを含む、請求項1に記載の方法。
【請求項６】
前記ファイルフォーマットは、ヘッダフィールドなどの、前記コンテンツロケーション情報を示すメタデータを含む、請求項1に記載の方法。
【請求項７】
前記ファイルフォーマットは、送信機と受信機との間で通信される、請求項1に記載の方法。
【請求項８】
前記ファイルフォーマットは、各ファイルに含まれるように、「ファイルベース」である、請求項1に記載の方法。
【請求項９】
前記ファイルフォーマットは、メディアオブジェクトが暗号化され、暗号鍵を含んだ権利が前記メディアオブジェクトから離れた装置に配信される配信方法のためのものである、請求項1に記載の方法。
【請求項１０】
前記ファイルフォーマットは、ISOベースのメディアファイルフォーマットに基づいたボックス構造を有し、前記ファイルフォーマットはDCF v2.0または同等物である、請求項1に記載の方法。
【請求項１１】
前記ファイルフォーマットは、前記メディアコンテンツのパスを示すコンテンツロケーションヘッダを含む、請求項1に記載の方法。
【請求項１２】
前記パスは、URI（Uniform Resource Indicator；ユニフォームリソースインジケータ）として示される、請求項11に記載の方法。
【請求項１３】
前記ファイルフォーマットは、前記メディアコンテンツのファイル名を示す、請求項1に記載の方法。
【請求項１４】
通信用の送信機であって、
メディアコンテンツのためのファイルフォーマットを生成するための手段と、
前記ファイルフォーマットを受信機に送信するための手段とを含み、前記ファイルフォーマットは、前記メディアコンテンツのコンテンツロケーション情報を示す、送信機。
【請求項１５】
前記ファイルフォーマットは、前記メディアコンテンツのコンテンツロケーション情報を前記ファイルフォーマット内に格納するように構成される、請求項14に記載の送信機。
【請求項１６】
前記フォーマットはファイルヘッダを含み、そのすぐ後ろにコンテナボックスが続き、前記コンテナボックスは共通のヘッダボックスを有し、前記共通のヘッダボックスは前記コンテンツロケーション情報を格納するためのテキストヘッダを備える、請求項14に記載の送信機。
【請求項１７】
前記ファイルフォーマットは、1つ以上のメディアコンテンツを有する単一のファイル内に仮想ファイルツリーを構築するように構成される、請求項14に記載の送信機。
【請求項１８】
前記ファイルフォーマットは、前記メディアコンテンツのパスを示すコンテンツロケーションヘッダを含む、請求項14に記載の送信機。
【請求項１９】
前記ファイルフォーマットは、前記メディアコンテンツのファイル名を示す、請求項14に記載の送信機。
【請求項２０】
前記送信機は、サーバーまたはウェブサーバーのようなネットワーク要素である、請求項14に記載の送信機。
【請求項２１】
通信用の受信機であって、
メディアコンテンツのためのファイルフォーマットを受信するための手段と、
前記ファイルフォーマットを使用するための手段とを含み、前記ファイルフォーマットは、前記メディアコンテンツのコンテンツロケーション情報を示す、受信機。
【請求項２２】
前記ファイルフォーマットは、前記メディアコンテンツのコンテンツロケーション情報を前記ファイルフォーマット内に格納するように構成される、請求項21に記載の受信機。
【請求項２３】
前記フォーマットはファイルヘッダを含み、そのすぐ後ろにコンテナボックスが続き、前記コンテナボックスは共通のヘッダボックスを有し、前記共通のヘッダボックスは前記コンテンツロケーション情報を格納するためのテキストヘッダを備える、請求項21に記載の受信機。
【請求項２４】
前記ファイルフォーマットは、1つ以上のメディアコンテンツを有する単一のファイル内に仮想ファイルツリーを構築するように構成される、請求項21に記載の受信機。
【請求項２５】
前記ファイルフォーマットは、前記メディアコンテンツのパスを示すコンテンツロケーションヘッダを含む、請求項21に記載の受信機。
【請求項２６】
前記ファイルフォーマットは、前記メディアコンテンツのファイル名を示す、請求項21に記載の受信機。
【請求項２７】
前記受信機は、固定端末またはモバイル端末である、請求項21に記載の受信機。
【請求項２８】
請求項14に記載の送信機と、ネットワークと、請求項21に記載の受信機とを備えるシステムであって、請求項1に記載の方法を使用するように構成されるシステム。
【請求項２９】
前記ファイルフォーマットは、前記ネットワークを通じて前記送信機と前記受信機との間で通信される、請求項28に記載のシステム。
【請求項３０】
前記ネットワークは、少なくとも部分的に無線である、請求項28に記載のシステム。
【請求項３１】
送信機で実行可能なソフトウェアアプリケーションであって、
メディアコンテンツのためのファイルフォーマットを生成するためのプログラムコードと、
前記送信機が前記ファイルを受信機に送信するためのプログラムコードとを含み、前記ファイルフォーマットは、前記メディアコンテンツのコンテンツロケーション情報を示す、ソフトウェアアプリケーション。
【請求項３２】
受信機で実行可能なソフトウェアアプリケーションであって、
メディアコンテンツのためのファイルフォーマットを受信するためのプログラムコードと、
前記ファイルフォーマットを翻訳するためのプログラムコードとを含み、前記ファイルフォーマットは、前記メディアコンテンツのコンテンツロケーション情報を示す、ソフトウェアアプリケーション。
【請求項３３】
メディアコンテンツのためのファイルフォーマットであって、前記ファイルフォーマットは、前記メディアコンテンツのコンテンツロケーション情報を前記ファイルフォーマット内に格納するように構成される、メディアコンテンツのためのファイルフォーマット。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概ねファイルフォーマットに関する。特に、本発明の特定の実施態様は、DCFファイルフォーマット（例、DCF v2.0ファイルフォーマット）または類似物の提供に関する。
【背景技術】
【０００２】
OMA DRM  リリース2は、DCF（DRM  Content  Format（DRMコンテンツフォーマット））v2.0ファイルフォーマットを、OMA DRM対応サービスの一部として使用するように標準化している（OMAはOpen  Mobile  Alliance（オープンモバイルアライアンス）を表し、DRMはDigital  Rights  Management（デジタル権利管理）を表す）。それに応じて、標準仕様：Open  Mobile  Alliance、DRM  Content  Format、Draft  Version  2.0−16，January−2004が立案されたが、この文書の内容は参照することにより本願明細書に組み込まれる。その目的は、DRM保護暗号化メディアオブジェクトおよび関連するメタデータのためのコンテンツフォーマットを定義することである。このコンテンツフォーマット（またはファイルフォーマット）は、他の多くの種類のコンテンツのコンテンツラッパーとしても使用することができる。例えば、SMILプレゼンテーションの全てのコンポーネントは、明確に定義されたプレースホルダおよびコンテンツ定義メタデータ構造の単一のファイルに「パッケージ」することができる。このファイルフォーマットは、DRM保護の有無に関わらず、業界によりマルチメディアコンテンツの配信および格納に広く使用されると期待される。
【０００３】
3GPPパケット交換ストリーミング（PSS、パケット交換ストリーミングサービス）リリース6では現在、3GPPファイルフォーマットを「ラッパー」ファイルフォーマット（すなわち、コンテナファイルフォーマット）にできるよう、その範囲を拡大するための新たな技術の導入に取り組んでいる。DCF v2.0ファイルフォーマットを使用するのか、またはファイルフォーマットの拡張子を使用するのかは、現在3GPP  SA4において検討中であり、新しいMPEG  ISO  Base  Media  File  Format  Amendment−1  Specification（ISO／IEC  14496−12：2003｜15444−12：2003：”ISO  base  media  file  format”Amendment−1）から継承されることになる。
【０００４】
DCF v2.0ファイルフォーマットは、マルチメディアプレゼンテーション（SMILファイルで表される）の全てのコンポーネントを収容するための、または静的もしくは動的なコンテンツに関わらず一群のマルチメディアコンテンツを単にアーカイブするための、単一のコンテナとして使用することができる。SMILプレゼンテーションに関しては、SMILプレゼンテーションをDCF v2.0ファイルに「パッケージング」した後に変更しないように、プレゼンテーションのメディアコンポーネントのディレクトリ構造（ファイルツリー構造とも呼ばれる）の情報を格納できることが望ましい。
【０００５】
現在、DCF v2.0ファイル内にそのような情報を格納するための、明確に定義された或いは標準的な方法は存在しない。したがって、ユーザーがSMILプレゼンテーションのパッケージ化を望む場合、そのユーザーは、SMILファイルを変更してパスを含まないようにしなければならない（または全てのメディアコンポーネントがSMILファイルとしてルートディレクトリレベルになければならない）。これは次のような影響を及ぼす。
1．ユーザーは、SMILファイルを変更するDRMの権利を持つことができない。
2．ファイル名の衝突が生じる可能性がある。
3．SMILプレゼンテーションの変更において、さらに複雑性が増し、メモリを消費するようになる。
4．メディアコンポーネントを異なるディレクトリに保存する傾向があるターゲット側では、ディレクトリ構造が失われる場合がある（例、＼Imageディレクトリ内の画像、＼3GPディレクトリ内の3GPファイルなど。ユーザーまたはOSが提供するメディアギャラリアプリケーションによって定義されるメディア格納構造に依存する）。
【０００６】
ZIPには、ディレクトリ構造格納機能がある。ZIPは、「アーカイブ」ファイルフォーマットとみなすことができるが、ZIPではプレゼンテーションの「マエストロ（maestro）」ファイル（例えば、プレゼンテーション全体のレイアウトおよび構造を実際に定義するSMILファイル）を識別することができない。
【０００７】
エリクソン社は、2003年のMPEG会議において、更なるメタデータとしてファイルフォーマット内に「ファイルツリー」構造および静的なメディアコンテンツを収容するためのISOベースのメディアファイルフォーマットの拡張子を提案した。詳細は、非特許文献３及び４を参照されたい。両文書のコンテンツは、参照することにより本願明細書に組み込まれる。提示された提案によって問題が部分的に解決されるかもしれないが、単純にこの新しいファイルフォーマットを利用しないDCF v2.0ファイルに関連する問題は解決されない。
【非特許文献１】OpenMobile Alliance, DRM Content Format, Draft Version 2.0-16 January-2004
【非特許文献２】ISO/IEC14496-12 : 2003 I 15444-12 : 2003 :"ISO base media file format"Amendment-1
【非特許文献３】Ericsson,3GPfile format extensions - container format, 3GPP TSG-SA WG4 Meeting #30, Malaga,Spain, 23-27 February 2004
【非特許文献４】Ericsson,Per Frojdh, Presentation and file-tree extensions to the ISO base media fileformat, ISO/IEC JTC1/SC29/WG11, MPEG2003/M10406, December 2003, Waikoloa, USA
【発明の開示】
【０００８】
本発明の第1の側面によれば、通信方法であって、
メディアコンテンツのためのファイルフォーマットを準備するステップと、
前記ファイルフォーマットを用いて、メディアコンテンツのコンテンツロケーション情報を示すステップとを含む、通信方法が提供される。
【０００９】
該方法は、無線および有線通信に適用可能である。
【００１０】
本発明の実施態様によれば、DCF  v2.0ファイルフォーマットに新しいヘッダが定義され、その内部にはメディアコンテンツのコンテンツロケーション情報が格納される。このようなヘッダを定義することによって、ファイル内の各メディアコンテンツは、その適切なターゲットロケーションで取り出されるか、または単一のファイル内に仮想ファイルツリーを構築することによって「所定の位置で」消費されることができる。したがって、「パッケージング」前と同じディレクトリ構造が保存される。これはまた、プレゼンテーションレイアウトファイル（例、SMIL）が、ディレクトリ構造を「フラット化」したり、重複するファイル名を「改名」したりするために、変更される必要のないことを意味する。
【００１１】
本発明の実施態様を用いることによって、（例えば、承認されたアーティストによって編集された）読み取り専用の著作権保護されたSMILプレゼンテーションを所有することが可能であり、後にユーザーが作成したコンテンツ（例、個人の画像、ビデオ）とともに、高品位のマルチメディアプレゼンテーションを構成するために使用される。
【００１２】
本発明の更なる実施態様によれば、本発明の第1の側面の方法とともに使用するように構成された、送信機、受信機、システム、ソフトウェアアプリケーション、およびファイルフォーマットが提供される。
【００１３】
送信機は、ネットワーク要素であってよい。ネットワーク要素は、インターネットまたはモバイルネットワークなどのネットワーク内のサーバーであってよい。サーバーは、ストリーミングサーバーまたは（マルチ）メディアのダウンロードまたはファイルのダウンロード、あるいはファイルまたはコンテンツの配信に使用するあらゆるサーバーであってよい。あるいは、モバイルまたは固定端末装置であってよい。
【００１４】
受信機は、例えば、モバイルクライアントまたは固定クライアント装置であってよい。
【００１５】
ソフトウェアアプリケーションは、メモリなどのメディアに格納される、プログラムコードを含むコンピュータプログラム製品であってよい。
【００１６】
従属請求項は、本発明の実施態様に関する。本発明の特定の側面に関する従属請求項に含まれる内容は、本発明の他の側面にも適用可能である。
【詳細な説明】
【００１７】
以下、添付図面を参照して本発明の実施態様について一例として説明する。この特許出願書の導入部に含まれる内容は、詳細な説明を補助するために用いることが可能である。以下、本発明がDCF v2.0のみに関係することに限定はしないが、DCF v2.0を一例として使用する。以下に記載される方法のうちのいずれかを、可能かつ機能的に好適なあらゆる組み合わせにおいて使用することもできる。
【００１８】
「背景技術」に記載した標準規格（Open Mobile Alliance, DRM Content Format, Draft Version 2.0-16
January-2004）によれば、ＯＭＡ  ＤＲＭは、メディアオブジェクトが暗号化され、暗号鍵を含んだ権利がメディアオブジェクトから離れた装置に配信される、配信方法を規定する。
【００１９】
該規格の目標は、メディアオブジェクトの暗号化に加えて、以下のようなメタデータに対応するコンテンツフォーマットを定義することである。
−    メディアオブジェクトの元のコンテンツタイプ。
−    DRM保護メディアオブジェクトを権利と関連付けるための、このDRM保護メディアオブジェクトの一意の識別子。
−    暗号化の詳細に関する情報。
−    このDRM保護メディアオブジェクトのためのサービスを発行する権利に関する情報。
−    拡張子および他のメディアタイプに依存するメタデータ。
【００２０】
該標準規格は、コンテンツフォーマットに2つのプロファイルを提案している。その1つ、すなわちDCFは、離散的メディア（例えば、静止画像、着信音、アプリケーションなど）で使用することを意図するものである。このプロファイルは、離散的メディアをパッケージおよび保護するために使用される。離散的メディアプロファイルによって、エンベロープ（DCF）内のあらゆるコンテンツを包むことができるようになる。次いでそのコンテンツは、コンテンツの内部構造およびレイアウトを選ばない単一のオブジェクトとして暗号化される。
【００２１】
もう1つの提案されたプロファイル、すなわちPDCFは、連続的メディア（例、音楽などのオーディオおよびビデオ）で使用することを意図するものである。PDCFは、連続的（パケット化）メディアを保護するために使用される。標準規格では、連続的メディアがパケット化されているために、それが独立したフォーマットで保護されることを提案している。連続的メディアの読み込みおよび解析を行うアプリケーションは、パケット毎の基準でファイルを処理することを意図したものである。保護された連続的メディアの再生を容易にするために、格納フォーマットは、パケットが個々に保護されるように構成される必要がある。このような構造が意識されたパケット化は、連続的メディアを流すためにも必要である。OMA DRM準拠のストリーミングサーバーは、保護フォーマットを解するクライアントに配信できるヘッダとパケットとにコンテンツを分割するために、コンテンツフォーマットの構造を解することができる。
【００２２】
標準規格によれば、両プロファイルは、コンポーネントを再利用するためのデータ構造を共有する。さらに両プロファイルは、広く受け入れられ普及した標準フォーマットであるISOベースのメディアファイルフォーマット（ISO14496−12）に基づいているが、離散的メディアのプロファイルは、ISO規格のメディアファイルとの完全な互換性を目的としたものではなく、汎用のフォーマットとすることを意図したものである。標準規格によれば、コンテンツ発行者は、それらのコンテンツに対してどのプロファイルを使用するのかを決定することができるが、一般的に、連続的メディアのプロファイルは、調和のとれたユーザーエクスペリエンスを生成するために、連続的メディアコンテンツに使用されなければならない。離散的メディアプロファイルは、他のタイプのコンテンツに使用されなければならない。ユーザーに対して、DCFはDRM保護ファイルのように見えるが、PDCFファイルは外部へのメディアファイルのように見え、機能するという点で異なる。
【００２３】
上述の規格の5.1節には、ISOベースのメディアファイルフォーマット、および提案されたコンテンツフォーマットとの一般的な関係が記載されている。
【００２４】
ISOベースのメディアファイルフォーマットは、オブジェクト指向デザインのボックスの周辺に構築される。提案されたDCF v2ファイルフォーマットはまた、ISOベースのフォーマットに基づいたボックス構造も有する。あらゆるメディアタイプを「包み込む」するために使用することができる。このフォーマットはコンテンツオブジェクトごとにヘッダセクションを含む。コンテンツオブジェクトは、暗号化されていても、されていなくてもよい。第1のコンテンツオブジェクトは、メディアタイプが外部で可視であること（例、SMIL）を判断する。他のコンテンツオブジェクトは、CID機構によって参照することができる。必須のボックスの後ろには、専用の拡張子が与えられる。該拡張子は、埋め込みファイルアイコン、プレビューなどにも対応する
【００２５】
図1は、離散的メディアプロファイル（DCF）の構造の高次の概略図を示す。図1中の長さを示す数字はオクテットを表す。
【００２６】
DCFファイルは、少なくとも1つのOMA DRMコンテナボックス10を含む。OMA DRMコンテナボックス10は、単一のコンテンツオブジェクトおよびその関連するヘッダのコンテナである。
【００２７】
より詳しくは、このフォーマットはファイルヘッダ（固定DCFヘッダ）を含み、そのすぐ後ろにOMA DRMコンテナボックス10が続く。OMA DRMコンテナボックス10は、DCFヘッダボックス11および保護コンテンツボックス12を含む。フォーマットに対するデザインの原則には、DCFヘッダボックス11が、ファイルの最初から固定オフセットして位置させることが含まれる。OMA DRMコンテナボックス10は、ファイルヘッダの後ろの第1のボックスであり、DCFヘッダボックス11は、OMA DRMコンテナ10内の第1のボックスである。
【００２８】
OMA DRMコンテナボックス10は、OMA DRM共通のヘッダボックス13、および選択的に（ISO）ユーザーデータボックス14を含む。マルチパートの場合には、第1のOMA DRMコンテナボックス10の後ろに、第2のOMA DRMコンテナボックス20が続く。
【００２９】
PDCFプロファイル（またはフォーマット）は、幾分DCFフォーマットと異なる。しかし、PDCF内には、類似した共通のヘッダボックスも現れる。
【００３０】
標準規格（DCF v2.0）では、テキストヘッダフィールドと共通のヘッダを使用して、ファイルフォーマットのメタデータ構造を拡張する方法を定義している。すなわち、共通のヘッダボックス14は、コンテンツの更なる情報を含んだテキストヘッダフィールドを含むことができる。構文を以下に示す。
2007525759.tif 000003
【００３１】
本発明の実施態様によれば、上述の構文を使用して、新しいカスタムヘッダが以下のように定義される。
2007525759.tif 000004
【００３２】
いくつかの例を以下に示す。
2007525759.tif 000005
【００３３】
ヘッダ名「Content−Location」は、一例であり、なお同じ概念に対応する異なる規格（または技術的仕様）では異なって称される場合がある。
【００３４】
図2は、DCF v2.0ファイルフォーマットの別の図を示す。通常、DCFは、高価値の個別メディアオブジェクトの保護に使用されるようにデザインされる。DCFは、MIMEタイプの含有メディアオブジェクトを含む。共通DRMヘッダは、権利が購入されたなどの場合に、例えば暗号化アルゴリズムを示すために使用される。
【００３５】
3GPP資産情報（3GPP asset information）は、3GPファイルフォーマットで定義されているように使用されることができる。メディアオブジェクトは、それに従って暗号化され、元のファイルフォーマットを備えたままラッパーフォーマット（メディアオブジェクトを包含するフォーマット）に挿入される。
【００３６】
図3は、コンテンツロケーション情報を有するDCF v2.0ファイルフォーマットを提供するための別の実施態様を示す。DCFフォーマットは、マルチパートマルチメディアプレゼンテーションをホストするために使用することができる。第1のコンテンツオブジェクトはメディアタイプ関連を判断するので、ファイルとSMILプレーヤとを関連付ける第1のオブジェクトとしてSMIL文書31を有する。SMIL文書は、次いでファイル内の他のオブジェクト32乃至34を参照することが可能である。SMIL文書は、パスおよびファイル名を示す一連のコンテンツロケーションフィールドを含む。さらに、各参照ファイルは、コンテンツのパスを提供するコンテンツロケーションフィールドを含むことが可能である。
【００３７】
本発明の一実施態様によれば、ファイルレベルのインターリービングは無効にされる。ファイルレベルのインターリービングは、不必要な複雑さをもたらす場合が多くなる。
【００３８】
本発明の一実施態様によれば、各メディアデータは、「ファイル」内にカプセル化される。一方、従来技術の解決策では、主3GPファイルレベルに少なくとも1つのメディアトラックが存在し、コンテナファイルといくつかの未加工のメディアデータのビットストリームとを物理的に結びつける。本発明の一実施態様によれば、各ファイルは、コンテンツロケーションヘッダを有する。それは、例えば各ファイルの始めに存在することが可能である。
【００３９】
本発明の実施態様によって、次のような利点が得られる。
−    コンテンツは、例えばSMILファイルおよびコンテンツロケーションヘッダを用いて容易にマッピングされることができる。ディレクトリ構造は、コンテンツのパッケージング動作の後も保存され、さらに、行われうるコンテンツの抽出の後に復元される。
−    コンテンツは、例えばファイルからブロックごとに読み込むなどして、ファイルシステムに取り出さずに、ファイルから「適切に」再生することができ、したがって、スペースを節約することができる。それでもなお、ファイルのコンテンツのファイルツリータイプのプレゼンテーションを可能にする。
−    漸進的なダウンロードアプリケーションは、これが取り込むべき正しいコンテンツであるかどうかを理解するために、このフィールドを使用することができる。
−    例えばSMILファイルが変更された場合の生成および変更が容易である。
−    各ファイルエンティティは、それ自体のコンテンツロケーション情報を含むので、コンテナファイルの他の部分に影響を及ぼさない追加または削除が容易である。
−    高価値で著作権があり保護された作品と、ユーザー生成の個人用コンテンツとの混合が可能になる。
【００４０】
いくつかの実施形態では、パーサー／コンポーザーは、変更が行われた際に更新しなければならなくなるように、ヘッダを認識しなければならない、または認識すべきである。
【００４１】
著作権のある（保護）コンテンツと、ユーザー生成のコンテンツとを混合するために、追加的レベルのパッケージング（DCF内のDCF）を行うことができる。
【００４２】
公開国際特許出願WO03／028293A1には、本発明の実施態様を適合させるための一般的な環境が示されている。該出願の内容は、参照することにより本願明細書に組み込まれる。特にその出願の図2は、マルチメディアコンテンツのストリーミングのための送信システムを示している。システムは、エディタとも称される符号器であって、一般的に複数のメディアソースMSから送信するためのメディアコンテンツデータを準備する符号器ECと、符号化したマルチメディアファイルをネットワークNWを通じて送信するストリーミングサーバーSSと、そのファイルを受信する複数のクライアントCとを備える。コンテンツは、ビデオカメラなどのライブのプレゼンテーションを記録したレコーダからのものであるか、またはビデオテープ、CD、DVD、ハードディスクなどの記憶装置にすでに保存されたものであってよい。コンテンツは、例えば、ビデオ、オーディオ、静止画像であってよく、またデータファイルを含んでもよい。符号器ECからのマルチメディアファイルは、サーバーSSに送信される。サーバーSSは、複数のクライアントCを扱うことができ、ユニキャストまたはマルチキャストパスを使用して、サーバーデータベースから、または直ちに符号器ECからマルチメディアファイルを送信することによって、クライアントのリクエストに応答することができる。ネットワークNWは、例えば、モバイル通信ネットワーク、ローカルエリアネットワーク、放送網、またはゲートウェイで分割される複数の異なるネットワークであってよい。
【００４３】
さらに、添付図4頁（図4）は、本発明の一実施態様による通信システムを示す。システムは、IPネットワーク（インターネットプロトコル）104に接続された（ストリーミング）サーバー111を備える。IPネットワーク104は、例えば、インターネットまたはサービスプロバイダオペレータのイントラネット（オペレータのドメインに属するイントラネットネットワーク）であってよい。IPネットワーク104は、モバイル通信ネットワークのコアネットワーク103に接続される。該接続は、Giインターフェースを通じて行うことが可能である。モバイル通信ネットワークは、例えば、「第2.5世代」のGPRSまたはEGPRSネットワーク、または第3世代、あるいはそれ以降の世代のセルラーモバイル通信ネットワークであってよい。モバイル通信ネットワークはまた、コアネットワーク103に接続された無線アクセスネットワーク（RAN）102も備える。無線アクセスネットワーク102は、モバイルクライアント装置101にエアインターフェースを通じたモバイル通信ネットワークへのアクセスを提供する。上述のアクセスは、回路交換手段（例、回路交換データ通話）またはパケット交換手段（例、GPRS（汎用パケット無線システム））によって提供することが可能である。したがって、これらの技術は、無線インターフェース部分を通じたメディアストリームパケットの搬送に使用することが可能である。
【００４４】
添付図5頁の図5は、サーバー111の説明図を示す。サーバー111は、処理ユニット151、第1のメモリ153、ネットワークインターフェース155、および第2のメモリ152を備える。第1のメモリ153、ネットワークインターフェース155、および第2のメモリ152は、処理ユニット151に接続される。
【００４５】
処理ユニット151は、第1のメモリ153に格納されたコンピュータソフトウェア154に基づいて、ファイルフォーマットの処理、および第2のメモリ（ディスク）152などに格納された適切なコンテンツのネットワークインターフェース155を通じたクライアント101への送信などの、サーバー111の動作を制御する。
【００４６】
ソフトウェア154は、好適な階層化プロトコルスタックを実現するためのプログラムコードを含む。
【００４７】
添付図5頁の図6は、クライアント装置101の説明図を示す。本実施態様では、クライアント101は、例えば、セルラー無線電話ネットワークの移動局であってよい。なお、クライアントは、代わりに固定端末であってもよい。
【００４８】
クライアント101は、処理ユニット171、無線周波数部175、およびユーザーインターフェース109を備える。無線周波数部175およびユーザーインターフェース109は、処理ユニット171に接続される。ユーザーインターフェース109は、一般的に、ユーザーがそれらを用いてクライアント装置101を使用することができる、ディスプレイ、スピーカ、およびキーボード（図示せず）を備える。
【００４９】
処理ユニット171は、プロセッサ（図示せず）、メモリ173、およびメモリ173に格納されたコンピュータソフトウェア174を備える。プロセッサは、ソフトウェアに従って、ファイルフォーマットの処理、サーバー111からのストリーミングメディアまたはメディアファイルの受信、および受信したストリーミングデータのユーザーインターフェース109へのプレゼンテーションを制御する。
【００５０】
ソフトウェア174は、好適な階層化プロトコルスタックを実現するためのプログラムコードを含む。
【００５１】
ファイルフォーマットに関するプロシージャは、ソフトウェアによって実行することができる。受信機101に格納され、プロセッサ171内で実行されるプログラムコードを含むコンピュータプログラムは、送信セッションの受信終了時にプロシージャを実行するために使用することができ、一方で、送信機111に格納され、プロセッサ151内で実行されるプログラムコードを含むコンピュータプログラムは、送信終了時にプロシージャを実行するために使用することができる。
【００５２】
本発明の特定の実現例および実施態様を記載した。本発明が、上述の実施態様の詳細に制限されないことは、当業者には明らかである。さらに、当業者は、本発明に組み込める多数の追加的な方法があり、限定された一部の実施例のうちの1つに示されていないが、それらの方法は本発明の範囲内であるということを認識している。特に、本発明は、あらゆるプロトコルまたはパラメータの特定の名前、またはフィールド名に制限されてはならない。本発明は、本発明の特性から逸脱せずに、同等の手段を使用して他の実施態様において実施することができる。本発明の範囲は、添付の特許請求の範囲によってのみ限定される。
【図面の簡単な説明】
【００５３】
【図１】本発明の実施態様の案内又は図示
【図２】本発明の実施態様の案内又は図示
【図３】本発明の実施態様の案内又は図示
【図４】本発明の実施態様の案内又は図示
【図５】本発明の実施態様の案内又は図示
【図６】本発明の実施態様の案内又は図示
【図１】
2007525759.tif 000006
【図２】
2007525759.tif 000007
【図３】
2007525759.tif 000008
【図４】
2007525759.tif 000009
【図５】
2007525759.tif 000010
【図６】
2007525759.tif 000011
【国際調査報告】
2007525759.tif 000012
2007525759.tif 000013