特許 6567064 関連マルチメディアコンテンツのカスタマイズ表示の実現方法およびその応用

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6567064

(24)【登録日】2019年8月9日

(45)【発行日】2019年8月28日

(54)【発明の名称】関連マルチメディアコンテンツのカスタマイズ表示の実現方法およびその応用

(51)【国際特許分類】

   H04N 21/2668 20110101AFI20190819BHJP

   H04N 21/235 20110101ALI20190819BHJP

【ＦＩ】

   H04N21/2668

   H04N21/235

【請求項の数】31

【全頁数】37

(21)【出願番号】特願2017-541331(P2017-541331)

(86)(22)【出願日】2016年2月2日

(65)【公表番号】特表2018-509065(P2018-509065A)

(43)【公表日】2018年3月29日

(86)【国際出願番号】CN2016073167

(87)【国際公開番号】WO2016127862

(87)【国際公開日】20160818

【審査請求日】2017年9月28日

(31)【優先権主張番号】201510080011.X

(32)【優先日】2015年2月13日

(33)【優先権主張国】CN

(31)【優先権主張番号】201510080580.4

(32)【優先日】2015年2月13日

(33)【優先権主張国】CN

(31)【優先権主張番号】201510401550.9

(32)【優先日】2015年7月9日

(33)【優先権主張国】CN

(31)【優先権主張番号】201510955611.6

(32)【優先日】2015年12月17日

(33)【優先権主張国】CN

(31)【優先権主張番号】201610031034.6

(32)【優先日】2016年1月18日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】507190994

【氏名又は名称】上海交通大学

【氏名又は名称原語表記】ＳＨＡＮＧＨＡＩ ＪＩＡＯ ＴＯＮＧ ＵＮＩＶＥＲＳＩＴＹ

(74)【代理人】

【識別番号】100205936

【弁理士】

【氏名又は名称】崔 海龍

(74)【代理人】

【識別番号】100132805

【弁理士】

【氏名又は名称】河合 貴之

(72)【発明者】

【氏名】徐 異凌

(72)【発明者】

【氏名】張 文軍

(72)【発明者】

【氏名】朱 文▲しょう▼

(72)【発明者】

【氏名】張 良慧

(72)【発明者】

【氏名】陳 浩

(72)【発明者】

【氏名】李 博

(72)【発明者】

【氏名】孫 軍

(72)【発明者】

【氏名】柳 寧

【審査官】 冨田 高史

(56)【参考文献】

【文献】 特開２０１１−０２９９４８（ＪＰ，Ａ）

【文献】 特開２０００−３５０１８２（ＪＰ，Ａ）

【文献】 特開２０１３−０９０２９５（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／０１２５７８７（ＵＳ，Ａ１）

【文献】 特開２０１０−２２５００３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００ − ２１／８５８

(57)【特許請求の範囲】

【請求項1】

マルチメディアコンテンツプロバイダーによりマルチメディアファイルを制作する際、完成されたファイルコンテンツをまとまって制作するとともに、コンテンツの重要度および／または関連度合いに基づいてＭＰＤファイルに＠ｓｃａｌｅＩＤの属性を追加することよって標識を行う方法により完成されたファイルコンテンツにおけるセグメントに対してレベル分けすることによって、異なるバージョンのマルチメディアファイルを生成することと、
ユーザーは異なるバージョンのマルチメディアファイルを選択的にプレビューおよび／または再生を行うことと、
を含む、関連マルチメディアコンテンツのカスタマイズ表示の実現方法。

【請求項2】

コンテンツプロバイダーはマルチメディアファイルの表示インターフェースにおいてセグメントのレベル分けに関連するバージョン情報を提供することにより、ユーザーによるコンテンツの選択および消費に供する、請求項１に記載の関連マルチメディアコンテンツのカスタマイズ表示の実現方法。

【請求項3】

コンテンツをレベル分けしたバージョンに対する管理を通じて、マルチメディアファイルを複数のバージョンに分けるステップ１と、
バージョンに関連する差異化ＭＰＤファイルの生成し、該ＭＰＤファイルは、前記マルチメディアファイルの複数のバージョンに基づいて、コンテンツのレベル分けに対応するＭＰＤファイルであって、コンテンツレベル分けのバージョン管理タブであるステップ２と、
ユーザーが自らの必要に応じて異なるバージョンのマルチメディアファイルコンテンツをリクエストし、サーバーはまとまったＭＰＤファイルを伝送し、クライアント側はＭＰＤを解析してから自身のネットワーク環境、設備能力およびリクエストしたバージョンの状況に基づいて、サーバーに対応するメディアセグメントのコンテンツをリクエストするステップ３と、
を含む、請求項１または２に記載の関連マルチメディアコンテンツのカスタマイズ表示の実現方法。

【請求項4】

前記マルチメディアファイルの複数のバージョンはＭＰＤにおけるｓｅｇｍｅｎｔリストに対応しており、これらのｓｅｇｍｅｎｔを生成する際、マッチングするコンテンツバージョンのＭＰＤファイルが自動的に生成され、ＭＰＤ要素において該ＭＰＤファイルによって説明されるコンテンツレベル分けのレベルを定義するための＠ｓｃａｌｅＩＤの属性が追加され、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素のＳｅｇｍｅｎｔＬｉｓｔサブ要素におけるｓｅｇｍｅｎｔリストは単なるすべてのセグメントのリストではなく、ＭＰＤ＠ｓｃａｌｅＩＤに対応する特定のクリップリストである、請求項３に記載の関連マルチメディアコンテンツのカスタマイズ表示の実現方法。

【請求項5】

コンテンツをレベル分けしたバージョンに対する管理を通じて、マルチメディアファイルを複数のバージョンに分けるステップ１と、
複数のバージョンに対して対応するＭＰＤファイルは１つのみ生成され、ＭＰＤファイルのｓｅｇｍｅｎｔ説明には、コンテンツレベル分けのバージョン管理タグである＠ｓｃａｌｅＩＤの属性が追加されるステップ２と、
ユーザーが自らの必要に応じて異なるバージョンのマルチメディアファイルコンテンツをリクエストし、サーバーはまとまったＭＰＤファイルを伝送し、クライアント側はＭＰＤを解析してから自身のネットワーク環境、設備能力およびリクエストしたバージョンの状況に基づいて、サーバーに対応するメディアセグメントのコンテンツをリクエストするステップ３と、
を含むことを特徴とする、請求項１または２に記載の関連マルチメディアコンテンツのカスタマイズ表示の実現方法。

【請求項6】

前記異なるバージョンのマルチメディアファイルはＭＰＤファイルのｓｅｇｍｅｎｔリストに対応しており、これらのｓｅｇｍｅｎｔが生成する際、ＭＰＤファイルに含まれているＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素のＳｅｇｍｅｎｔＬｉｓｔサブ要素におけるｓｅｇｍｅｎｔごとに該ｓｅｇｍｅｎｔの最低バージョンレベルを使用することを表示するための＠ｓｃａｌｅＩＤの属性が提供される、請求項１に記載の関連マルチメディアコンテンツのカスタマイズ表示の実現方法。

【請求項7】

マルチメディアファイルを制作する際、マルチメディアコンテンツの重要なセグメントに対して標識を行い、マルチメディアファイルコンテンツの重要度に応じて各セグメントを異なるレベルに分けることと、
ユーザーにより再生する際、盲目的にランダムに選択するのではなく、これらのレベルに基づいてマルチメディアコンテンツを選択的に再生することと、
マルチメディアファイルと異なるバージョンのコンテンツと、ｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒというＭＰＵにおける標識フィールドと、異なるバージョンのビデオと一対一の対応関係を有するｌｅｖｅｌ＿ｌｉｓｔというｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒの集合との間の対応関係を説明するためのＭＵＲ情報ファイルを新たに定義することと、
を含む、マルチメディアコンテンツのレベル分け技術の実現方法。

【請求項8】

あるマルチメディアコンテンツを複数のＭＰＵセグメントに分け、異なるバージョンにレベル分けしてからｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒと対応関係を持たせることと、
マルチメディアファイルと異なるバージョンのコンテンツ、ｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒ、ｌｅｖｅｌ＿ｌｉｓｔとの間の対応関係を説明するためのＭＵＲ情報ファイルを新たに定義し、ｌｅｖｅｌ＿ｌｉｓｔ配列と異なるバージョンのコンテンツ時間との対応規則が異なることに応じて、異なるバージョンのコンテンツとｌｅｖｅｌ＿ｌｉｓｔとは一対一に対応するタイプ１と、異なるバージョンのコンテンツは異なるｌｅｖｅｌ＿ｌｉｓｔの組み合わせであるタイプ２と、の二つのタイプに分けることと、
タイプ１およびタイプ２におけるＭＵＲ情報ファイルに基づいてマルチメディアファイル対して差異化伝送を行うことと、
を含む、請求項７に記載のマルチメディアコンテンツのレベル分け技術の実現方法。

【請求項9】

前記タイプ１において、ｌｅｖｅｌ＿ｌｉｓｔは異なるＭＰＵにより組み合わせられ、異なるバージョンのビデオとは一対一に対応しており、ユーザーがより多くのクリップをリクエストする際、ｓｅｒｖｅｒはユーザーの欠如しているＭＰＵのみを伝送し、
前記タイプ２において、ｌｅｖｅｌ＿ｌｉｓｔは異なるＭＰＵにより組合せられ、各ｌｅｖｅｌ＿ｌｉｓｔ［ ］の間には重畳するＭＰＵが現れることなく、異なるバージョンは異なるｌｅｖｅｌ＿ｌｉｓｔにより組み合わせられ、ユーザーがカットバージョンのビデオを再生した後、さらに完全バージョンのビデオを再生しようとする場合、特定のｌｅｖｅｌ＿ｌｉｓｔ［ ］に含まれているＭＰＵセグメントの差異化伝送のみを行う、請求項８に記載のマルチメディアコンテンツのレベル分け技術の実現方法。

【請求項10】

前記ＭＵＲ情報ファイルにはコンテンツレベル分けの重要情報が含まれており、これらの重要情報はシグナリング情報にＭＵＲ情報を追加することにより伝送される、請求項７〜９のいずれか一項に記載のマルチメディアコンテンツのレベル分け技術の実現方法。

【請求項11】

前記シグナリング情報にＭＵＲ情報を追加する方法は、ＭＵＲ情報を現在のＣＩファイルに追加すること、シグナリング情報にＭＵＲ情報を説明するためのＭＵＲファイルを追加すること、ＭＵＲ情報を説明するためのｄｅｓｃｒｉｐｔｏｒというＭＭＴにおけるシグナリング部分が一部のフィールドまたは機能を定義するための説明的な情報を追加すること、またはＭＵＲ情報を説明するためのシグナリングテーブルを追加すること、である、請求項１０に記載のマルチメディアコンテンツのレベル分け技術の実現方法。

【請求項12】

請求項１〜１１のいずれか一項に記載の方法を利用するスマートホームの制御方法であって、
ビデオにおける主要フレームの画像の主な色調および／またはシーンのシナリオ特徴に基づいてビデオセグメントに対して標識を行う、またはオーディオデータの特徴に基づいて標識を行い、対応するタブを追加し、これらのマルチメディアコンテンツを再生するたび、標識されたタブはスマートホームの設備が動作するように駆動する、スマートホームの制御方法。

【請求項13】

前記ビデオにおける主要フレームの画像の主な色調に基づいてビデオセグメントに対して標識を行うことは、ビデオＭＰＵにおける主要フレームの画像の主な色調を抽出して標識を行い、ＭＰＵＢｏｘにおいて予備されているｒｅｓｅｒｖｅｄフィールドを用いてｃｏｌｏｒ＿ｔａｇを定義することであり、異なる色には異なるｃｏｌｏｒ＿ｔａｇを使用できる、請求項１２に記載のスマートホームの制御方法。

【請求項14】

ビデオＭＰＵにおける主要フレームの画像の主な色調を分析することによりｃｏｌｏｒ＿ｔａｇに値を付与する、またはアルゴリズムによってＭＰＵにおける主要フレームの画像の主な色調を抽出して値を付与することを自動に行う、請求項１３に記載のスマートホームの制御方法。

【請求項15】

ＭＰＵＢｏｘにおけるｒｅｓｅｒｖｅｄフィールドの７ｂｉｔをｃｏｌｏｒ＿ｔａｇに使用し、該ｂｉｔ桁は必要に応じて拡張可能である、請求項１３に記載のスマートホームの制御方法。

【請求項16】

前記ビデオにおけるシーンのシナリオ特徴に基づいてビデオセグメントに対して標識を行うことは、ビデオにおけるあるシーンのパターンを抽出し、ＭＰＵに対して標識を行い、ＭＰＵＢｏｘにおけるｒｅｓｅｒｖｅｄフィールドをｓｃｅｎｅ＿ｔａｇに定義する、ことである、請求項１２〜１５のいずれか一項に記載のスマートホームの制御方法。

【請求項17】

前記オーディオデータの特徴に基づいて標識を行うことは、オーディオＭＰＵにおけるトーン特徴を抽出し、ＭＰＵに対して標識を行い、ＭＰＵＢｏｘにおけるｒｅｓｅｒｖｅｄフィールドをｔｏｎｅ＿ｔａｇに定義する、ことである、請求項１２〜１５のいずれか一項に記載のスマートホームの制御方法。

【請求項18】

請求項１または７に記載の実現方法において、レベル分けした後のコンテンツを伝送するための関連マルチメディアコンテンツのカスタマイズ表示情報の説明方法であって、
メディアリソースの関連マルチメディアコンテンツは異なるｅｄｉｔ ｌｉｓｔ（編集リスト）により表示され、異なるｅｄｉｔ ｌｉｓｔに含まれているメディアデータユニットの間は補充関係または包含関係であることと、
メディアリソースの分類および説明情報の対応関係をユーザーに表示するため、伝送する情報においてメディアリソースの特徴情報または関連情報の説明としてマルチメディアコンテンツに対する説明情報が含まれているｄｅｓｃｒｉｐｔｏｒシグナリング情報を追加することにより、カスタマイズ表示のメカニズムを実現することと、
を含む、関連マルチメディアコンテンツのカスタマイズ表示情報の説明方法。

【請求項19】

前記マルチメディアコンテンツの特徴情報または関連情報の説明は、既に含まれているＣＩ（Ｃｏｍｐｏｓｉｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）要素のＭｅｄｉａＳｙｎｃにおいて、ｄｅｓｃｒｉｐｔｏｒの属性を新規追加することであり、ｄｅｓｃｒｉｐｔｉｏｎはメディアソースに対応するコンテンツの説明情報の説明に用いられる、請求項１８に記載の関連マルチメディアコンテンツのカスタマイズ表示情報の説明方法。

【請求項20】

前記マルチメディアコンテンツの特徴情報または関連情報の説明は、ＣＩファイルにおいて新たにＥｄｉｔＤｅｓｐ要素を追加して、メディアリソースにおける異なる関連コンテンツの説明情報の説明に用いることである、請求項１８に記載の関連マルチメディアコンテンツのカスタマイズ表示情報の説明方法。

【請求項21】

マルチメディアコンテンツの情報はＭｅｄｉａＳｙｎｃに保存され、ＣＩにおいてＭｅｄｉａＳｙｎｃと同じレベルのＥｄｉｔＤｅｓｐ要素を追加し、異なるレベルのメディアリソースの説明情報を指し示すために専用することと、
ｅｄｉｔ要素はＥｄｉｔＤｅｓｐ要素のサブ要素であり、各ｅｄｉｔ要素は一つのレベルのカスタマイズ表示の説明情報表すことと、
ｅｄｉｔ要素のもと、ｅｄｉｔ＿ｉｄの属性とｄｅｓｃｒｉｐｔｉｏｎの属性を新規追加し、ｅｄｉｔ＿ｉｄの属性はあるレベルまたはある部分のメディアリソースの標識に用いられ、ｄｅｓｃｒｉｐｔｉｏｎの属性はメディアリソースにおける異なるコンテンツの説明情報の説明に用いられることと、
を含む、請求項２０に記載の関連マルチメディアコンテンツのカスタマイズ表示情報の説明方法。

【請求項22】

前記マルチメディアコンテンツの特徴情報または関連情報の説明は、シグナリングにおいてｄｅｓｃｒｉｐｔｏｒの説明を追加し、ｄｅｓｃｒｉｐｔｉｏｎはメディアリソースにおける異なる関連コンテンツの説明情報の説明に用いられる、請求項１８に記載の関連マルチメディアコンテンツのカスタマイズ表示情報の説明方法。

【請求項23】

ＭＭＴプロトコルにおいて定義されたシグナリング情報において、新たにｄｅｓｃｒｉｐｔｏｒを定義し、該ｄｅｓｃｒｉｐｔｏｒは関連マルチメディアコンテンツに対応する説明情報を提供し、ＭＰ ｔａｂｌｅにはａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが含まれており、ユーザーがある番組コンテンツの説明情報を確認しようとする場合、該ｄｅｓｃｒｉｐｔｏｒをａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓに追加することにより実現する、請求項１８に記載の関連マルチメディアコンテンツのカスタマイズ表示情報の説明方法。

【請求項24】

同一メディアリソースに含まれているメディアデータユニットの標識または対応する説明情報を定義し、伝送されるメディアリソースにおける各種のマルチメディアコンテンツに対する説明情報が含まれているｄｅｓｃｒｉｐｔｏｒシグナリング情報を作成するステップと、
クライアント側においてｄｅｓｃｒｉｐｔｏｒシグナリング情報を解析し、ユーザーは必要に応じて対応する標識または情報表示を有するマルチメディアコンテンツを選択し、対応するメディアデータユニットをリクエストして対応するｅｄｉｔ ｌｉｓｔに組み合わせるステップと、
サーバー側はユーザーからのリクエストを解析してから対応するメディアデータユニットに送信し、クライアント側において情報を解析してからカスタマイズ表示を実現するステップと、
を含む、請求項１８〜２３のいずれか一項に記載の関連マルチメディアコンテンツのカスタマイズ表示情報の説明方法。

【請求項25】

請求項１または７に記載の実現方法において、マルチメディアコンテンツのカスタマイズ表示に使用されるタイムラインの制御方法であって、
マルチメディアリソースの表示中に、メディアデータユニットの持続期間情報および表示の初期時間に基づいて関連コンテンツの表示時間を制御し、異なるメディアリソースまたは同一メディアリソースにおける異なる関連バージョンに対応する表示タイムラインを与える、マルチメディアコンテンツのカスタマイズ表示に使用されるタイムラインの制御方法。

【請求項26】

ユーザーにより選択されるメディアリソースの関連コンテンツバージョンに含まれているメディアデータユニットに基づいて、各メディアデータユニットに対してそれに対応する持続期間情報を取得するステップＳ１と、
ＶｏＤにおいては、ユーザーによりメディアリソースを選択する際の時間に基づいて再生開始時間を確定し、ブロードキャストサービスにおいては、サービスプロバイダーによって再生開始時間を確定し、シグナリング情報において再生開始時間の標識を行うステップＳ２と、
ステップＳ２における再生開始時間と、対応する関連コンテンツバージョンにおけるメディアデータユニットの持続時間とを加算することにより取得される対応するメディアデータユニットの絶対表示時間に基づいて、対応する表示タイムラインを維持して、メディアコンテンツの表示を指導するステップＳ３と、
を含む、請求項２５に記載のマルチメディアコンテンツのカスタマイズ表示に使用されるタイムラインの制御方法。

【請求項27】

ステップＳ１において、前記関連コンテンツバージョンは、ユーザーの必要に応じてメディアリソースに対して標識を行い、標識されたｅｄｉｔ ｉｄに基づいて異なる関連バージョンのコンテンツを生成し、異なるｅｄｉｔ ｌｉｓｔとして請求項９に記載のｌｅｖｅｌ ｌｉｓｔに対応させることを指す、請求項２６に記載のマルチメディアコンテンツのカスタマイズ表示に使用されるタイムラインの制御方法。

【請求項28】

前記の表示タイムラインは、選択されたメディアコンテンツに含まれているメディアデータユニットの絶対表示時間情報の組み合わせを指す、請求項２５に記載のマルチメディアコンテンツのカスタマイズ表示に使用されるタイムラインの制御方法。

【請求項29】

ＭＭＴにおいて定義されたＭＰＵ ｔｉｍｅｓｔａｍｐ ｄｅｓｃｒｉｐｔｏｒを利用し、ｄｅｓｃｒｉｐｔｏｒにはＭＰＵのメディアリソースにおける対応する番号ｍｐｕ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒおよび対応するＵＴＣ絶対表示時間が標識されていることと、
ユーザーがあるメディアリソースの関連コンテンツバージョンを消費する場合、サーバーはユーザーがリクエストした関連バージョンに基づいて、該バージョンに含まれているメディアデータユニットの番号および対応する持続期間情報を取得し、対応するｄｅｓｃｒｉｐｔｏｒを生成することと、
を含む請求項２５〜２８のいずれか一項に記載のマルチメディアコンテンツのカスタマイズ表示に使用されるタイムラインの制御方法。

【請求項30】

ＭＰＵ ｔｉｍｅｓｔａｍｐ ｄｅｓｃｒｉｐｔｏｒを定義し、同一メディアリソースの関連コンテンツおよびそれに対応するＭＰＵの集合に基づいてｅｄｉｔ ｌｉｓｔを定義して、各バージョンの関連コンテンツに対して独自のｅｄｉｔ ｉｄを付与し、ｄｅｓｃｒｉｐｔｏｒにおいて各ｅｄｉｔ ｌｉｓｔに含まれているすべてのＭＰＵのｍｐｕ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒおよび対応する表示時間情報を説明することと、
ユーザーがあるバージョンの関連コンテンツを選択した場合、対応するｅｄｉｔ＿ｉｄに基づいてそれに含まれているメディアデータユニットおよび対応する絶対表示時間ｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅを解析し、対応するバージョンのタイムラインを生成して表示を制御することと、
を含む、請求項２５〜２８のいずれか一項に記載のマルチメディアコンテンツのカスタマイズ表示に使用されるタイムラインの制御方法。

【請求項31】

シグナリングにおいてあるメディアリソースにおける各ＭＰＵの持続時間を説明し、シグナリング情報から該メディアリソースの開始時間を取得し、演算により各ＭＰＵのＵＴＣ絶対表示時間を取得することと、
メディアコンテンツの伝送過程において、ユーザーにより選択されたメディアコンテンツに基づいて、対応するメディアデータユニットＭＰＵを選択し、その持続時間情報ｄｕｒａｔｉｏｎを解析するとともに指導表示情報であるＭＰＵの番号ｍｐｕ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒおよび対応するｄｕｒａｔｉｏｎ情報を生成することと、
を含む、請求項２５〜２８のいずれか一項に記載のマルチメディアコンテンツのカスタマイズ表示に使用されるタイムラインの制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はインターネット（Ｉｎｔｅｒｎｅｔ）オンデマンド（Ｏｎ Ｄｅｍａｎｄ）システムにおけるマルチメディアの構成、保存および伝送の新たな方法に関し、より具体的には、関連マルチメディアコンテンツのカスタマイズ表示の実現方法およびその応用に関する。

【背景技術】

【0002】

マルチメディア技術の高速発展につれ、インターネットにおけるマルチメディアコンテンツは爆発的に激増している。特に高精細、高解像度のビデオ（動画）業務が幅広く深まっており、マルチメディアサービスによるネットワーク帯域幅への圧力はますます引き立っている。一方、ユーザーカスタマイズ趣味の差異とネットワーク環境の時間的変動により、現在のマルチメディアサービスは統合式特徴を表し、マルチメディアコンテンツは分散化の傾向を表している。既存のマルチメディアプロトコルは、ほとんどがネットワーク伝送過程におけるデータの完全性および安全性に目を向けており、ネットワークの品質（ＱｏＳ）を保証することによりマルチメディアサービスの品質を保証している。しかしながら、マルチメディアコンテンツの統合およびユーザーの主観満足度については考慮することが極めて少ない。

【0003】

現在のマルチメディアプロトコルは、基本的にはシグナリング情報を通じてデータの転送および表示を説明し制御しており、マルチメディアコンテンツの構成レベルに触れておらず、コンテンツの構成と保存、伝送とのマッチングおよびマルチメディアシステム全体のデータ最適化を考慮していない。その結果、マルチメディアの製作者がまとまって完成されたコンテンツの番組を制作したにも関わらず、カッティングなどの後期制作を経て、番組の発行者とプロバイダー（提供者）とでは元の番組を異なるバージョンに分けている。各々のバージョンは互いに独立しており、独自のメディアコンテンツを成している。これは、番組コンテンツを豊かにしているようにみえるが、実際はメディアシステム全体の運行環境を破壊し、重畳するデータを大量に生み出している。これらのデータは、メディアコンテンツの天然の関連体系を破壊し、メディアコンテンツの管理に不利であり、保存コストを引き上げ、莫大なリソースロスをもたらしてしまう。さらに、ロジック上コンテンツが同一のデータユニットをネットワークにおいて重複して伝送する必要があり、データ伝送の効率を大幅に低下させる。また、異なるバージョンの番組コンテンツが重畳して独立存在することは、元々豊かなメディアリソースを膨大化、混乱化させ、デジタルメディアコンテンツに対する監督管理の難易度を引き上げ、多くの海賊版で権利侵害となるメディアコンテンツがデジタルメディア市場へ進出しやすくしてしまい、番組プロバイダーと消費者に被害をもたらしている。

【0004】

一方、メディアリソースの豊かさは、ある程度ユーザーによるデジタルメディア消費の負担を増加させ、ユーザーはより多くの精力をメディア消費の選択に使わなければならない。従来の方法では、コンテンツプロバイダーによっていろんなタイプの映画リソースなど豊かなメディア番組を提供するが、これらの番組は通常はフルバージョン（完全版）であるため、ユーザーは通常、あるフルバージョンのメディア番組をオンデマンドするしかない。このような状況において、自分がすきな番組を選択して再生しようとする場合、ユーザーは複数の番組をプレビューしなければならない。このようなメカニズムにおけるデータバッファリングの効率が低いため、ユーザーは長い時間を待つ必要があり、ユーザーエクスペリエンスが非常に悪い。

【0005】

より好ましい方法では、番組の発行者とプロバイダーは、ロジック上においてのみ元の番組を異なるバージョンに分ける。メディアコンテンツの分散化ユニットが幅広く応用されているため、元の番組は物理的には依然としてまとまられている天然の整体である。メディアコンテンツのサーバーにおいて、メディアのフルバージョンのみを保存し、メディアの異なるバージョンに対応するデータユニットを説明するためのシグナリングファイルを提供する。このようにすれば、ユーザーは自らの必要に応じて関連バージョンのメディアデータをリクエストし、サーバーはシグナリング情報におけるメディアバージョンとデータユニットとのマッチングに基づいて、対応するデータのみをユーザーに伝送する。例えば、ある映画をプレビューしたいだけのユーザーは、プレビューバージョンのみをリクエストすればよい。サーバーはプレビューバージョンの映画データユニットのみをクライアント側のデコードおよび表示用に伝送し、ユーザーは映画全体のバッファリングを待たなくてもよいため、より良いユーザーエクスペリエンスが得られる。しかしながら、システムは異なるバージョンの間におけるメディアユニットの対応関係を判明しがたく、関連のシグナリングメカニズムによる指導も欠けていること、メディアごとに長さの異なる複数のバージョンが存在し得ること、が難しいところである。これらのバージョンをいかに区別、管理することも、早急に解決しなければならない問題である。

【0006】

なお、現在のマルチメディアシステムはコンテンツについて初歩的なレベル分けが可能であるが、ユーザーはマルチメディアコンテンツに対応する説明を取得するのができないため、自主的に選択することができない。さらに、同一の番組に対しても、ユーザーは異なる選択をする必要がある。マルチメディアコンテンツのカスタマイズ表示を実現し、メディアネットワークにおけるメディアリソースの伝送をより効率化するためには、マルチメディアコンテンツのカスタマイズ表示のメカニズムが必要である。サーバーは、マルチメディアコンテンツとメディア説明とのマッチングテーブルをユーザーに伝送し、即ち関連するマルチメディアコンテンツの選択肢をユーザーに提供する。ユーザーは、自らの必要に応じて同一コンテンツの異なるバージョン、もしくはあるメディアリソースの関連コンテンツなどの各種の表示形式をリクエストして、かつ自らの必要に応じてカスタマイズできる。

【0007】

しかしながら、このようなマルチメディアコンテンツのカスタマイズ表示のメカニズムは、新たな要求を提出している。関連するメディアリソースが異なるｅｄｉｔ ｌｉｓｔ（編集リスト）により表示されるため、異なるｅｄｉｔ ｌｉｓｔには異なるメディアデータユニットが含まれている。さらに、異なるマルチメディアコンテンツに対して、ユーザーは異なる選択基準を持っており、例えば、同じソワレに対し、ユーザーは多視野角のビデオを見ることと、異なる歌手の演出を見ることとを選択できる。このため、ｅｄｉｔ ｌｉｓｔもユーザーの必要と番組種類などに基づいてカスタマイズに作成される場合が
ある。カスタマイズ伝送を実現するためには、マルチメディアコンテンツの説明情報とｅｄｉｔ ｌｉｓｔとの間のマッチング関係を、メディアリソースを受信するクライアント側に伝送するためのメカニズムが必要である。

【発明の概要】

【発明が解決しようとする課題】

【0008】

本発明は、既存技術における問題に鑑みてなされたものであり、関連マルチメディアコンテンツのカスタマイズ表示の実現方法、インターネットオンデマンドシステムにおいてフレキシブルで高効率的且つ拡張可能な構成、保存、伝送の方法を提供することを目的とし、既存のマルチメディアプロトコルにおいて欠けているメディアコンテンツにフレキシブルな構成メカニズムを増やし、既存のマルチメディアシステムにおける伝送効率の低下、保存リソースのロス、ユーザーエクスペリエンスが悪いとの問題を解決する。

【課題を解決するための手段】

【0009】

本発明の第一の目的によれば、関連マルチメディアコンテンツのカスタマイズ表示の実現方法であって、マルチメディアコンテンツプロバイダーによりマルチメディアファイルを制作する際、完成されたファイルコンテンツをまとまって制作するとともに、コンテンツの重要度および／または関連度合いに基づいて標識を行う方法により完成されたファイルコンテンツにおけるセグメントに対してレベル分けすることによって、異なるバージョンのマルチメディアファイルを生成することと、ユーザーは異なるバージョンのマルチメディアファイルを選択的にプレビューおよび／または再生を行うことと、を含む。

【0010】

前記方法はさらに、 コンテンツをレベル分けしたバージョンに対する管理を通じて、マルチメディアファイルを複数のバージョンに分けるステップ１と、
バージョンに関連する差異化ＭＰＤファイルを生成し、該ＭＰＤファイルは、前記マルチメディアファイルの複数のバージョンに基づいて、コンテンツのレベル分けに対応するＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルであって、コンテンツレベル分けのバージョン管理タブであるステップ２と、
ユーザーが自らの必要に応じて異なるバージョンのマルチメディアコンテンツをリクエストし、サーバーはまとまったＭＰＤファイルを伝送し、クライアント側はＭＰＤを解析してから自身のネットワーク環境、設備能力およびリクエストしたバージョンの状況に基づいて、サーバーに対応するメディアセグメントのコンテンツをリクエストするステップ３と、を含む。

【0011】

前記関連マルチメディアコンテンツのカスタマイズ表示の実現方法は、さらに、
コンテンツのレベル分けしたバージョンに対する管理を通じて、マルチメディアファイルを複数のバージョンに分けるステップ１と、
複数のバージョンに対して対応するＭＰＤファイルは１つのみ生成され、ＭＰＤファイルのｓｅｇｍｅｎｔ説明には、コンテンツレベル分けのバージョン管理タグである＠ｓｃａｌｅＩＤの属性が追加されるステップ２と、
ユーザーが自らの必要に応じて異なるバージョンのマルチメディアファイルコンテンツをリクエストし、サーバーはまとまったＭＰＤファイルを伝送し、クライアント側はＭＰＤを解析してから自身のネットワーク環境、設備能力およびリクエストしたバージョンの状況に基づいて、サーバーに対応するメディアセグメントのコンテンツをリクエストするステップ３と、を含む。

【0012】

本発明に係る関連マルチメディアコンテンツのカスタマイズ表示の実現方法によれば、既存のメディアコンテンツにおけるフレキシブルな管理のメカニズムが乏しいことが原因で、マルチメディアシステムの低伝送効率、保存リソースのロス、ユーザーエクスペリエンスが悪いなどの問題を引き起こしている現状について、メディアコンテンツに関する拡張可能でフレキシブルな構成、保存、伝送方法を増やすことにより、インターネットにおけるメディアコンテンツに対する最適化と統合、ロジック上同一メディアリソースに対する一括保存を実現でき、またユーザーのメディアバージョンに対するニーズに基づいて差異化伝送を行い、クライアントにおいて特定のメディアユニットバッファリングとデコードの表示を実現できる。これにより、豊かなメディアリソースを一括最適化し、マルチメディアのコンテンツを監視制御しやすくすると同時に、ネットワークにおけるマルチメディアデータ全体の伝送効率を向上し、保存スペースのロスを低減し、ユーザーによりよいサービスエクスペリエンスを提供する。

【0013】

本発明の第二の目的によれば、既存のマルチメディアのコンテンツのレベル分けが細分化できず、低伝送効率、保存スペースのロスという問題を解決すするため、マルチメディアコンテンツのレベル分け技術の実現方法を提供し、該方法は、マルチメディアファイルを制作する際、マルチメディアコンテンツにおける重要なセグメントに対して標識を行い、マルチメディアファイルコンテンツの重要度に応じて各セグメントを異なるレベルに分けることと、ユーザーにより再生する際、盲目的にランダムに選択するのではなく、これらのレベルに基づいてマルチメディアコンテンツを選択的に再生することと、マルチメディアファイルと異なるバージョンのコンテンツと、ｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒというＭＰＵにおける標識フィールドと、異なるバージョンのビデオと一対一対応関係を有するｌｅｖｅｌ＿ｌｉｓｔというｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒの集合との間の対応関係を説明するためのＭＵＲ情報ファイルを新たに定義することと、を含む。

【0014】

好ましくは、あるマルチメディアコンテンツを複数のＭＰＵセグメントに分け、異なるバージョンにレベル分けしてからｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒと対応関係を持たせることと、マルチメディアファイルと異なるバージョンのコンテンツ、ｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒ、ｌｅｖｅｌ＿ｌｉｓｔとの間の対応関係を説明するためのＭＵＲ情報ファイルを新たに定義し、ｌｅｖｅｌ＿ｌｉｓｔ配列と異なるバージョンのコンテンツ時間との対応規則が異なることに応じて、対応関係を下記の二つのタイプに分ける。

【0015】

異なるバージョンのコンテンツとｌｅｖｅｌ＿ｌｉｓｔとは一対一に対応するタイプ１と、
異なるバージョンのコンテンツは異なるｌｅｖｅｌ＿ｌｉｓｔの組み合わせであるタイプ２と、の二つのタイプに分けることと、
タイプ１およびタイプ２におけるＭＵＲ情報ファイルに基づいてマルチメディアファイルに対して差異化伝送を行うことと、を含む。

【0016】

既存のマルチメディアプロトコルにおけるマルチメディアコンテンツに対するレベル分け技術の空白が原因で、メディアコンテンツの低伝送効率、保存スペースのロスという問題を引き起こしている現状について、本発明に係るマルチメディアコンテンツのレベル分け技術によれば、メディアコンテンツに関する拡張可能な伝送、保存と表示メカニズムを増やすことにより、インターネットにおける異なるバージョンのメディアコンテンツ間の関連分類を実現し、マルチメディアサービスに対する管理制御が強化できるととともに、マルチメディアデータの伝送効率を向上し、保存スペースのロスを低減できる。またユーザーにより多くのメディアバージョンを自主的に選択できる権利を与えることにより、ユーザーエクスペリエンスを向上させるとともに、ネットワーク事業者にもよりよいマルチメディアコンテンツに対するレベル分け、伝送と保存の方法を提供できる。

【0017】

本発明の第三の目的によれば、前記関連マルチメディアコンテンツのカスタマイズ表示の実現方法を利用するコンテンツ駆動のスマートホームの制御方法であって、ビデオにおける主要フレームの画像の主な色調および／またはシーンのシナリオ特徴に基づいてビデオセグメントに対して標識を行う、またはオーディオデータの特徴に基づいて標識を行い、対応するタブを追加し、これらのマルチメディアのコンテンツを再生するたび、標識されたタブはスマートホームの設備が動作するように駆動する。

【0018】

好ましくは、ビデオにおける主要フレームの画像の主な色調に基づいてビデオセグメントに対して標識を行うことは、ビデオＭＰＵにおける主要フレームの主な色調を抽出して標識を行い、ＭＰＵＢｏｘにおいて予備されているｒｅｓｅｒｖｅｄフィールドを用いてｃｏｌｏｒ＿ｔａｇを定義することであり、異なる色には異なるｃｏｌｏｒ＿ｔａｇを利用できる。

【0019】

コンテンツ駆動によるスマートホームを制御する本発明に係る方法によれば、マルチメディアコンテンツによりスマートホーム制御システムを自動的駆動できる。現在、マルチメディアコンテンツを人為的に評価してから手動でスマートシステムを制御する仕組みとなっているが、本発明のコンテンツ駆動によるスマートホームシステムの制御を介して、人による制御の煩わしい過程を大いに簡略化でき、また本発明は制御システムをよりフレキシブルにすることができる。

【0020】

本発明の第四の目的によれば、プロバイダーは、メディアコンテンツの種類または重要度によりメディアコンテンツに対して標識した後、同一標識のメディアデータユニットを組み合わせて異なるｅｄｉｔ ｌｉｓｔにする。ユーザーリクエストのカスタマイズに対応するサービスを提供できるようにするため、メディアコンテンツの標識情報に適合した説明が必要である。これにより、ユーザーに各ｅｄｉｔ ｌｉｓｔの詳しい内容を理解させ、差異化の伝送と表示を実現し、正しいサービスを提供する。ユーザーがサーバーからの関連マルチメディアコンテンツを選択できないという問題を解決し、異なるユーザーのリクエストに対応できるカスタマイズのメディア表示を実現するため、本発明に係る関連マルチメディアコンテンツのカスタマイズ表示情報の説明方法は、メディアリソースの関連マルチメディアコンテンツは異なるｅｄｉｔ ｌｉｓｔ（編集リスト）により表示され、異なるｅｄｉｔ ｌｉｓｔに含まれているメディアデータユニットの間は補充関係または包含関係であることと、メディアリソースの分類および説明情報の対応関係をユーザーに表示するため、伝送する情報においてメディアリソースの特徴情報または関連情報の説明を追加することにより、カスタマイズ表示のメカニズムを実現する。

【0021】

さらに、関連マルチメディアコンテンツのカスタマイズ表示情報の実現手順は、
同一メディアリソースに含まれているメディアデータユニットの標識または対応する説明情報を定義し、伝送されるメディアリソースにおける各種のマルチメディアコンテンツに対する説明情報が含まれているｄｅｓｃｒｉｐｔｏｒシグナリング情報を作成するステップと、
クライアント側においてｄｅｓｃｒｉｐｔｏｒシグナリング情報を解析し、ユーザーは必要に応じて対応する標識または情報表示を有するマルチメディアコンテンツを選択し、対応するメディアデータユニットをリクエストして対応するｅｄｉｔ ｌｉｓｔに組み合わせるステップと、
サーバー側はユーザーからのリクエストを解析してから対応するメディアデータユニットに送信し、クライアント側において情報を解析してからカスタマイズ表示を実現するステップと、を含む。

【0022】

本発明の第五の目的によれば、既存のマルチメディアプロトコルにおける表示メカニズムの不備について、ユーザーの意思決定に基づくオンデマンドサービスにおける表示メカニズムとラジオ、リアルタイム生放送サービスのプッシュ型配信メカニズム、および関連内容の表示サービスを考慮に入れて、マルチメディアコンテンツのカスタマイズ表示に使用されるタイムラインの制御方法を提供し、該方法、マルチメディアリソースの表示中に、メディアデータユニットの持続期間情報および表示の初期時間に基づいて関連コンテンツの表示時間を制御し、異なるメディアリソースまたは同一メディアリソースにおける異なる関連バージョンに対応する表示タイムラインを与える。

【0023】

前記方法はさらに、
ユーザーにより選択されるメディアリソースの関連コンテンツバージョンに含まれているメディアデータユニットに基づいて、各メディアデータユニットに対してそれに対応する持続期間情報を取得するステップＳ１と、
ＶｏＤにおいては、ユーザーによりメディアリソースを選択する際の時間に基づいて再生開始時間を確定し、ブロードキャストサービスにおいては、サービスプロバイダーによって再生開始時間を確定し、シグナリング情報において再生開始時間の標識を行うステップＳ２と、
ステップＳ２における再生開始時間と、対応する関連コンテンツバージョンにおけるメディアデータユニットの持続時間とを加算することにより取得される対応するメディアデータユニットの絶対表示時間に基づいて、対応する表示タイムラインを維持して、メディアコンテンツの表示を指導するステップＳ３と、を含む。

【0024】

マルチメディアコンテンツのカスタマイズ表示に関するタイムラインをコントロールする本発明の前記方法は、ユーザーカスタマイズのニーズを満たすと同時に、同じ特性の番組の関連性を利用して、保存スペースを節約するもとに、ユーザーに順調な楽しみ体験を保証できる。メディアの表示ライムライン情報はシグナリング情報に基づいて柔軟に送信するため、メディアリソースを消費する途中に出た遅延とパケットロスによるユーザーエクスペリエンスの低下について、表示時間前にパケットロス事件を発見する場合、メディアリソースの再接続を待つことや、前のメディアデータユニットコンテンツを繰り返し表示することにより再生故障を避けてユーザーエクスペリエンスを保証できる。タイムラインの指示に従って引き続き表示する場合は、その実現対策は同規定に含まれていない。

【発明の効果】

【0025】

本発明に係る上記技術解決手段によれば、既存のマルチメディアプロトコルにおけるマルチメディアコンテンツに関連する情報説明の空白が原因で、ユーザーがサーバーからのメディアリソースを理解できないという問題について、マルチメディアコンテンツの特徴情報または関連情報に対する説明を増やすことにより、ユーザーが直感的且つ多方面から該マルチメディアを理解できるようにし、カスタマイズのマッピング関係を説明することにより関連するメディアサービスを提供し、できるだけユーザーが一番適応するマルチメディアコンテンツを選択できるように保証する。本発明に係る方法は、サーバーから提供されるマルチメディアコンテンツに対する説明に限らず、複数のソースまたは各種の分類方法などのマルチメディアリソースに対する説明にも適用でき、さらにはユーザーが自ら定義したタブで説明を生成することもできる。本発明は、ユーザーがサーバーから提供される関連マルチメディアコンテンツを選択できないという問題を解決し、異なるユーザーのニーズに対するカスタマイズのメディア表示を実現した。

【図面の簡単な説明】

【0026】

以下、図面を参照しながら、本発明の実施例について詳細に説明することによって、本発明の他の特徴、目的及び利点をより明らかにする。なお、これらの実施例は、本発明を限定するものではない。

【0027】

【図1】実施例１、２、５におけるメディアバージョンとメディアデータユニットとの間のマッピング関係の一例を示す図である。

【図2】本発明の実施例１におけるレベル分けメカニズム−モデル１を示す図である。

【図3】本発明の実施例１におけるレベル分けメカニズムのシステム構成ブロック−モデル２を示す図である。

【図4】本発明の実施例３、４、５における実現方法のフローチャートである。

【図5】本発明の実施例３におけるＭＰＵによるｈｕｅシステムのコントロールを説明するための図である。

【図6】本発明の実施例５おける設備電量不足の場合における差異化表示を説明するための図である。

【図7】本発明の実施例５における多視野角リアルタイム生放送を説明するための図である。

【図8】本発明の実施例５における関連内容の異なるバージョンの表示タイムラインを示す図である。

【発明を実施するための形態】

【0028】

以下、具体的な実施形態を例示しながら、本発明について詳しく説明する。以下の実施形態は、いわゆる当業者が本発明をより理解しやすくするための例示であり、いかなる形式で本発明を限定するものではない。また、いわゆる当業者であれば、本発明の要旨から逸脱しない範囲内において、様々な変形や改良を行うことができ、これらも本発明の保護範囲に属することには注意されたい。

【0029】

〔実施例１〕
現在、ビデオコンテンツの数は爆発的な成長を遂げており、人々により支配可能な時間も断片化しつつある。ユーザーは、一連の新しいビデオに触れるとき、往々にはその完全なコンテンツを直接オンデマンドして再生するのではなく、希望としてまずはこれらのビデオをプレビューしてから、ユーザー自らの好みと現在支配可能な時間に合わせてどのビデオを選択して再生するか、または完全なビデオコンテンツを再生するか否かを決めようとする。

【0030】

この問題に対し、以下の方法により効率的に解決し、ユーザーエクスペリエンスを向上できる。コンテンツプロバイダーは、ビデオを制作する際、完成されたビデオコンテンツをまとまって制作するとともに、コンテンツの重要度および／または関連度合いに基づいて標識を行う方法により完成されたビデオコンテンツにおけるセグメントに対してレベル分けすることによって、異なるバージョンのビデオを生成できる。当然ながら、ユーザーがコンテンツを選択して消費しやすくするために、表示インターフェースにおいてレベル分けに関連するバージョン情報を提供すべきである。これにより、ユーザーはビデオを再生する際、盲目的でランダムに選択することなく、これらのバージョンに基づいて選択的にプレビューし、再生できる。

【0031】

ビデオコンテンツを例にすると、コンテンツ制作者は完全な番組コンテンツさえ完成すればよく、その後は配布者側がコンテンツについてレベル分けしたバージョンの管理によりビデオを複数のバージョンに分けて、メディアサービスプロバイダーに提供できる。第一のバージョンのビデオはプレビュー版（簡略版ともいう）であって、再生時間の長さが５分間であり、コンテンツにはビデオにおけるハイライトシーンのみ含む。第二のバージョンのビデオはカッティング版（カット版ともいう）であって、再生時間の長さが３０分間であり、コンテンツにはビデオにおける物語の主なストーリーと重要なシーンのみ含む。第三のバージョンのビデオは完全版であって、再生時間の長さが１２０分間であり、コンテンツにはビデオにおける物語の完全なストーリーを含む。第四のバージョンは強化版（拡張版、補充版ともいう）であって、再生時間の長さが１５０分間であり、物語の完全なストーリーを含むほか、メイキングなどの補充コンテンツも含む。

【0032】

以下、ＭＰＥＧ−ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）規格を例にして、コンテンツについてレベル分けされたバージョンの管理メカニズムについて説明する。当然ながら、該メカニズムはＤＡＳＨ規格だけでなく、その他の規格および方法にも応用できる。ＤＡＳＨは、動的適応型ＨＴＴＰストリーミング（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）の略称であり、国際標準グループＭＰＥＧにより作成され、ＨＴＴＰプロトコルを介してメディアを自己適応、漸進式、ダウンロードまたはストリーミングの方法によりコンテンツの割り当てを行うことができ、異なるネットワークの状況において、複数の機能の異なる端末における適応型メディア消費をサポートする。コンテンツの構成においてＤＡＳＨは多種のセグメント対策を有し、またそのセグメントの詳細を指示するための対応するシグナリングファイルも有する。以下、汎用性を考えながら、二つのモデルに基づいてそれぞれ説明する。

【0033】

（モデル１）バージョンに関連する差異化ＭＰＤファイルを生成する
ＤＡＳＨ ｓｅｇｍｅｎｔを生成する際、上記ビデオ番組における四つのバージョンに基づいて、コンテンツのレベル分けに対応するＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルを生成できる。より明瞭に説明するため、ＭＰＤにおけるｓｅｇｍｅｎｔ ｌｉｓｔの説明状況のみを記載し、その他はｓｅｇｍｅｎｔ ｔｅｍｐｌａｔｅの場合における処理方法と類似する。

【0034】

上記ビデオ番組における四つのバージョンに対応するｓｅｇｍｅｎｔリストは、図１に示すとおりである。これらのｓｅｇｍｅｎｔを生成する際、コンテンツバージョンにマッチングする四つのＭＰＤファイルを自動的に生成する。ここで、ＭＰＤ要素について＠ｓｃａｌｅＩＤの属性を増加し、該属性により該ＭＰＤファイルにおいて説明されるコンテンツのレベル分けを定義する。コンテンツのレベル分けに対応する表は以下の表１に示されるとおりである。さらに、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素におけるＳｅｇｍｅｎｔＬｉｓｔサブ要素（子要素）に含まれるｓｅｇｍｅｎｔリストは、単なるすべてのセグメントのリストだけではなく、ＭＰＤ＠ｓｃａｌｅＩＤに対応する特定のセグメントリストである。

【0035】

【表1】

【0036】

図２に示すとおり、レベル分けメカニズム全体の構成ブロック図は、従来のＤＡＳＨの構成とほぼ同じで、メディアの準備段階におけるメディアセグメント（ｓｅｇｍｅｎｔ）の生成メカニズムは変わらない一方、異なるレベル分けのバージョンに対応する四つのＭＰＤファイルが生成されている。ＤＡＳＨクライアント側において、ユーザーが自らの必要に応じて異なるバージョンのビデオコンテンツをリクエストする際、サーバーは関連するＭＰＤファイルさえ伝送すればよく、クライアント側において解析をしてから再度サーバーに対して対応するメディアのセグメントのコンテンツをリクエストする。

【0037】

例えば、ユーザーがプレビュー版の映画番組を選択して再生する場合、サーバーはＭＰＤ＠ｓｃａｌｅＩＤが０であるＭＰＤファイルを送信し、クライアント側において解析した後、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素におけるＳｅｇｍｅｎｔＬｉｓｔサブ要素にリストされているセグメント、即ちｃｈａｎｎｅｌ１ｉｎｉｔ．ｍｐ４、ｃｈａｎｎｅｌ１１．ｍ４ｓ、ｃｈａｎｎｅｌ１４．ｍ４ｓ、ｃｈａｎｎｅｌ１７．ｍ４ｓ、ｃｈａｎｎｅｌ１９．ｍ４ｓをリクエストする。該ＭＰＤファイルに関する実例は以下の表２に示されるとおりである（新規追加したパラメータはｓａｓｃｌｅＩＤで、異なる新しい応用を有しうる）。

【0038】

【表2】

【0039】

（モデル２）既存のＤＡＳＨメカニズムに従って、一つのＭＰＤのみを生成し、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素において各セグメントの＠ｓｃａｌｅＩＤ属性を加える
ＤＡＳＨ ｓｅｇｍｅｎｔを生成する際、四つのコンテンツレベル分けしたバージョンに基づいて区分でき、区分の指示は同時に生成されるＭＰＤ表において表示される。より明瞭に説明するため、ＭＰＤにおけるｓｅｇｍｅｎｔ ｌｉｓｔの説明状況のみを記載し、その他はｓｅｇｍｅｎｔ ｔｅｍｐｌａｔｅの場合における処理方法と類似する。

【0040】

上記ビデオ番組における四つのバージョンに対応するｓｅｇｍｅｎｔリスト（図１に示すとおり）に基づいて、これらのｓｅｇｍｅｎｔを生成する際、ＭＰＤファイルにおけるＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素のＳｅｇｍｅｎｔＬｉｓｔサブ要素に含まれる各ｓｅｇｍｅｎｔに＠ｓｃａｌｅＩＤの属性を提供し、該属性はバージョンが最も低いレベルの該ｓｅｇｍｅｎｔを利用することを標識する。コンテンツレベル分けしたバージョンの対応表は、モデル１と同じである。たとえば、ｓｅｇｍｅｎｔ：ｃｈａｎｎｅｌ１３．ｍ４ｓの＠ｓｃａｌｅＩＤが２である場合、該ｓｅｇｍｅｎｔはユーザーが完全版のビデオをリクエストする場合のみ、サーバーから伝送され、クライアント側において消費される。

【0041】

図３に示すとおり、レベル分けメカニズム全体のシステム構成ブロック図は、既存のＤＡＳＨの構成とほぼ同じで、メディアの準備段階におけるメディアセグメント（ｓｅｇｍｅｎｔ）の生成メカニズムは変わらないと同時に、対応するＭＰＤファイルは一つのみ生成される。しかし、ＭＰＤファイルのｓｅｇｍｅｎｔの説明にコンテンツレベル分けのバージョン管理タブという＠ｓｃａｌｅＩＤの属性が増加されている。ＤＡＳＨクライアント側において、ユーザーが自らの必要に応じて異なるバージョンのビデオコンテンツをリクエストする際、サーバーはまとまったＭＰＤファイルを伝送し、クライエント側においてＭＰＤを解析してから自身のネットワーク状態、設備機能およびリクエストしたバージョンの詳細に基づいて、サーバーに対して対応するメディアセグメントのコンテンツをリクエストする。

【0042】

例えば、ユーザーが完全版の映画番組を選択して再生する場合、サーバーはまとまったＭＰＤファイルを送信し、クライアント側において解析した後、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素におけるＳｅｇｍｅｎｔＬｉｓｔサブ要素にリストされている＠ｓｃａｌｅＩＤの属性の値が２以下のメディアセグメント、即ちｃｈａｎｎｅｌ１ｉｎｉｔ．ｍｐ４、ｃｈａｎｎｅｌ１１．ｍ４ｓ、ｃｈａｎｎｅｌ１２．ｍ４ｓ、ｃｈａｎｎｅｌ１３．ｍ４ｓ、ｃｈａｎｎｅｌ１４．ｍ４ｓ、ｃｈａｎｎｅｌ１５．ｍ４ｓ、ｃｈａｎｎｅｌ１６．ｍ４ｓ、ｃｈａｎｎｅｌ１７．ｍ４ｓ、ｃｈａｎｎｅｌ１８．ｍ４ｓ、ｃｈａｎｎｅｌ１９．ｍ４ｓ、ｃｈａｎｎｅｌ１１０．ｍ４ｓをリクエストする。サーバーはこれらのセグメントコンテンツを送信し、クライアント側においてデコードして、ユーザーに表示する。該ＭＰＤファイルに関する実例は以下の表３に示されるとおりである。

【0043】

【表3】

【0044】

上記実施例はインターネットオンデマンドシステムにおけるフレキシブルで高効率的且つ拡張可能な構成、保存および伝送の方法であるため、既存のマルチメディアプロトコルにおいて欠けているメディアコンテンツを柔軟に構成するメカニズムが増加され、既存のマルチメディアシステムにおける低伝送効率、保存リソースのロス、ユーザーエクスペリエンスが悪いという問題を解決できる。

【0045】

〔実施例２〕
ユーザーがビデオを再生する際、往々にはビデオ全体を直接連続的に再生するのではなく、ほとんどの場合は該ビデオを早送りまたはジャンプ式でざっと見てから、自らの好みまたは受け入れられるビデオ時間の長さに応じて完全に再生するか否かを決める。ユーザーがジャンプ式でビデオを再生する場合、ランダムに選択したジャンプ時間点が不適切であることにより、ビデオコンテンツにおける重要な部分を見逃してしまう可能性が極めて高い。

【0046】

この問題に対し、以下の方法により効率的に解決して、ユーザーのエクスペリエンスを向上できる。コンテンツプロバイダーがビデオを制作する際、所定手段でビデオコンテンツにおける重要なセグメントに対して標識を付け、またはビデオコンテンツの重要度に応じて各々のビデオセグメントを異なるレベルに分けることができる。これにより、ユーザーはビデオを再生する際、盲目的でランダムに選択することがなくなり、これらのレベルに基づいて選択的に再生できる。

【0047】

例えば、ある映画番組に対して、制作者はバージョンが異なる複数のビデオを提供できる。ビデオの構造に応じて、簡略版、カット版、完全版と拡張版など、再生時間の長さが異なるビデオバージョンに分けることができる（実施例１を参照）。

【0048】

あるマルチメディアリソースをａｓｓｅｔ１であると仮設して、複数のＭＰＵ（ｍｅｄｉａ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔｓ）セグメントにカットし、コンテンツのレベル分けが異なるバージョンに分けると、ｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒとの対応関係は図１に示すとおりである。図１に示されるとおり、ｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒはＭＰＵにおける標識フィールドであり、あるビデオをｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒが０から１１までのＭＰＵセグメントに分ける場合、異なるｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒ序列はバージョンが異なるビデオに組み合わせられ、例えば、簡略版のビデオはｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒが１と９のＭＰＵから構成されている。

【0049】

フレキシブルに伝送と表示の差異化を達成するために、ＭＵＲ（Ｍｅｄｉａ Ｕｎｉｔ Ｒｅｌａｔｉｏｎｓｈｉｐ）情報ファイルを一つ新しく定義し、メディアリソースと異なるバージョンのビデオ、ｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒ、ｌｅｖｅｌ＿ｌｉｓｔなどとの対応関係を説明することに用いる。ここで、ｌｅｖｅｌ＿ｌｉｓｔ配列とバージョンが異なるビデオの再生時間との対応規則が異なることに基づいて、対応関係をさらに二つのタイプに分けることができる。タイプ１において、バージョンが異なるビデオとｌｅｖｅｌ＿ｌｉｓｔとの間は一対一の対応であり、タイプ２において、バージョンが異なるビデオは異なるｌｅｖｅｌ＿ｌｉｓｔの組み合わせである。

【0050】

上記の例示に基づいて、以下ではタイプ１とタイプ２におけるＭＵＲ情報ファイルの内容、差異化伝送を行う方法、及びクライアント側においていかにＣＩファイルにおけるｍｅｄｉａＳｒｃの属性を利用してバージョンが異なるビデオに対してフレキシブルに表示する手段について別々に説明する。

【0051】

（タイプ１）
ｌｅｖｅｌ＿ｌｉｓｔは異なるｍｐｕの組み合わせにより成され、異なるビデオバージョンとは一対一対応しており、その対応規則は表４に示されるとおりである。

【0052】

【表4】

【0053】

該対応規則は図１と完全に対応しており、図１は一つの実例である。異なる実例に対して、対応規則も変化する可能性がある。次のタイプ２においても同じである。

【0054】

伝送効率を向上させるために、ユーザーがより多くのビデオセグメントを必要とする場合、ｓｅｒｖｅｒ（サーバー）はユーザーが欠如しているＭＰＵのみ伝送すればよい。例えば、ユーザーがｌｅｖｅｌ＿ｌｉｓｔ［ｉ］に対応するビデオをオンデマンドし最後まで見終わってから、さらにｌｅｖｅｌ＿ｌｉｓｔ［ｊ］に対応するビデオを見ようとする場合があり、ここで０≦ｉ＜ｊ≦３である。この場合、ユーザーのローカルには既にｌｅｖｅｌ＿ｌｉｓｔ［ｉ］に含まれるすべてのＭＰＵが保存されているため、ｓｅｒｖｅｒは引き続きΔ_ｉｊ＝ｌｅｖｅｌ＿ｌｉｓｔ［ｊ］−ｌｅｖｅｌ＿ｌｉｓｔ［ｉ］に含まれるＭＰＵを送信すればよい。

【0055】

クライアント側において、ユーザーはローカルにおけるｌｅｖｅｌ＿ｌｉｓｔ［ｉ］および受信したΔ_ｉｊに基づいて、新しくｌｅｖｅｌ＿ｌｉｓｔ［ｊ］に組み合わせる。このため、ＣＩファイルにおけるバージョンが異なるビデオのｍｅｉａＳｒｃの属性の値は、表５に示されるとおりである。

【0056】

【表5】

【0057】

（タイプ２）
タイプ１とは異なり、ｌｅｖｅｌ＿ｌｉｓｔは異なるＭＰＵの組み合わせにより構成され、且つ各ｌｅｖｅｌ＿ｌｉｓｔ［］の間には互いに重畳するＭＰＵが存在しない。異なるビデオバージョンは異なるｌｅｖｅｌ＿ｌｉｓｔの組み合わせにより構成され、その対応規則は表６に示されるとおりである。

【0058】

【表6】

【0059】

上記表６に示すとおり、簡略版のビデオはｌｅｖｅｌ＿ｌｉｓｔ［０］により構成され、カット版のビデオはｌｅｖｅｌ＿ｌｉｓｔ［０］とｌｅｖｅｌ＿ｌｉｓｔ［１］により構成され、ｌｅｖｅｌ＿ｌｉｓｔ［２］は完全版のビデオとカット版のビデオの差分値であり、補充版は四つのｌｅｖｅｌ＿ｌｉｓｔにより構成されている。このため、ユーザーがカット版のビデオを最後まで見終わって、完全版のビデオを見ようとする場合、ｌｅｖｅｌ＿ｌｉｓｔ［２］に含まれるＭＰＵセグメントのみ差異化伝送すればよい。タイプ２のＣＩファイルにおけるバージョンが異なるビデオのｍｅｉａＳｒｃの属性の値は、表７に示されるとおりである。

【0060】

【表7】

【0061】

上記のとおり、ＭＵＲ情報ファイルにはコンテンツのレベル分けに関する重要な情報が含まれている。これらの重要な情報をいかに伝送するかについては、異なる方法があり、たとえば、新しいシグナリングユニット、シグナリングファイル、シグナリング情報、ｄｅｓｃｒｉｐｔｏｒを定義したり、または伝送パケットのヘッダー情報を加えたりする。また、異なる実現方法に基づいて、異なる方式および方法によりＭＵＲが説明した情報を伝送し利用できる。ＭＵＲ情報ファイルの伝送方法について、例示として四つの方法を提出する。ＭＵＲ情報をシグナリング情報に加える方法は、以下に示すいくつかの方法を含むが、これらに限定されない。

【0062】

＜方法１＞ ＭＵＲ情報を既存のＣＩファイルに加える
ＣＩファイルの機能はメディアリソースの表示を指導することであり、ｌｅｖｅｌ＿ｌｉｓｔもリソースに関する情報を解析するものであるため、ｌｅｖｅｌ＿ｌｉｓｔの内容を従来のＣＩファイルに追加できる。受信側はＣＩファイルを解析する場合、ｌｅｖｅｌ＿ｌｉｓｔ情報の解析をサポートすべきである。

【0063】

＜方法２＞ シグナリング情報にＭＵＲ情報を説明するＭＵＲファイルを追加する
方法１と同様の考え方に従い、ＣＩファイルと類似するＭＵＲ情報を説明するファイルを定義できる。このような方法の優れた点は、既存のプロトコルにおけるＣＩを修正する必要がないところである。生成されたＭＵＲファイルは、ＣＩおよびＨＴＭＬファイルと並列して伝送できる。プロトコルにおけるＣＩファイルの伝送方法に従い、ＭＵＲファイルに適切な伝送方法は、ＭＰＩ ｔａｂｌｅにおいてシグナリング情報の一部として伝送することである。

【0064】

【表8】

【0065】

ＭＵＲファイルをＭＰＩ ｔａｂｌｅに加えて、修正すべき部分はＰＩ＿ｃｏｎｔｅｎｔの説明部分である。ＰＩ＿ｃｏｎｔｅｎｔ＿ｃｏｕｎｔの値に１を足し、ＰＩ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅフィールドはＭＵＲファイルのタイプを説明する。実際の状況に基づいてＭＵＲ情報の説明に適合なファイルフォーマットを選択でき、ＰＩ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅ＿ｌｅｎｇｔｈの値はファイルタイプの長さであり、ＰＩ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅ＿ｌｅｎｇｔｈ＿ｂｙｔｅの値はＭＵＲファイルのタイプである。ＰＩ＿ｃｏｎｔｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈの値はＭＵＲファイルのｎａｍｅの長さであり、ＰＩ＿ｃｏｎｔｅｎｔ＿ｎａｍｅ＿ｂｙｔｅの値はＭＵＲファイルのｎａｍｅの値である。ＰＩ＿ｃｏｎｔｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒｅｓ＿ｌｅｎｇｔｈとＰＩ＿ｃｏｎｔｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒｓ＿ｂｙｔｅは、それぞれＭＵＲファイルの説明情報の長さと内容であり、まずは空（ＦＡＬＳＥ）にしておき、後で拡充できるようにしてよい。ＰＩ＿ｃｏｎｔｅｎｔ＿ｌｅｎｇｔｈとＰＩ＿ｃｏｎｔｅｎｔ＿ｂｙｔｅは、それぞれＭＵＲファイルの長さと内容である。

【0066】

上記の説明に従ってＭＵＲファイルをＭＰＩ ｔａｂｌｅに書き込んだ後、ＭＵＲ情報を伝送できる。

【0067】

＜方法３＞ ＭＵＲ情報を説明するｄｅｓｃｒｉｐｔｏｒを増加する
既存のＭＭＴプロトコルにおいて定義されるシグナリング情報には、一部説明的なｄｅｓｃｒｉｐｔｏｒが定義され、ｄｅｓｃｒｉｐｔｏｒはＭＭＴにおいてシグナリング部分が一部のフィールドまたは機能を定義する際に用いる説明的な情報であって、例えば、ｄｅｐｅｎｄｅｎｃｙ ｄｅｓｃｒｉｐｔｏｒとＭＰＵ＿ｔｉｍｅｓｔａｍｐ＿ｄｅｓｃｒｉｐｔｏｒである。このため、ＭＵＲ情報を説明するｄｅｓｃｒｉｐｔｏｒを定義でき、ｄｅｓｃｒｉｐｔｏｒにおいてｍｐｕのｌｅｖｅｌ情報を説明できる。また、ＭＰ ｔａｂｌｅにはａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドが含まれ、必要に応じてａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓにおいて関連するｄｅｓｃｒｉｐｔｏｒを加えることもできる。シグナリングにおいてｍｐｕのｌｅｖｅｌ情報を説明する必要がある場合、該ｄｅｓｃｒｉｐｔｏｒをａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓに加えることによって実現できる。

【0068】

＜方法４＞ ＭＵＲ情報を説明するシグナリングを追加する
上記の考え方に従い、シグナリング情報において、既存のシグナリングの他、さらにＭＵＲ情報の説明に専用される一つのｔａｂｌｅを増やしてもよい。ＭＵＲ情報を説明するｔａｂｌｅを生成した後、特定のヘッダー部を加えればＭＵＲ情報を説明するｍｅｓｓａｇｅが生成される。該ｍｅｓｓａｇｅは、ＰＡ ｍｅｓｓａｇｅ、ＭＰＩ ｍｅｓｓａｇｅ、ＭＰ ｍｅｓｓａｅ、ＣＲＩ ｍｅｓｓａｇｅ等と一緒に新しいシグナリング情報を構成して伝送される。受信側は、シグナリング情報を受信した後に解析すれば、関連するｌｅｖｅｌ＿ｌｉｓｔ情報が得られる。

【0069】

本発明において提供される実現方法をより明瞭に説明するため、図４に示すように、上記のタイプ１において説明した方法に従ってＭＵＲファイルを構築し、また上記の方法２によってＭＵＲファイルを伝送して、一つの具体的な実現方法のフローチャートを例示しながら説明する。図４に示されるように、受信側がＶｏＤサービスにログインする場合、送信側はシグナリング情報を送信し、受信側はＭＰＩ ｔａｂｅｌにおけるＰＩ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅ＿ｌｅｎｇｔｈ＿ｂｙｔｅフィールドを判断することでＭＵＲ、ＣＩおよびＨＴＭＬファイルを受信するとともに、ローカル保護のＭＰＵ保存データベースＭｙＳＱＬを更新し生成する。ユーザーが簡略版のビデオをリクエストする場合、受信側はＭＵＲファイルを検査することによって簡略版とｌｅｖｅｌ＿ｌｉｓｔ［０］との対応を見つけ出して、対応するｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒが１，９であることを見つけ出す。この場合、クライアント側がこれらのＭＰＵをリクエストしかつローカルに保存してユーザーに放送し、さらにローカルのデータベースを更新する。ユーザーが引き続いてカット版のビデオをリクエストする場合、ＭＵＲファイルおよびローカルのデータベースを検査することによって、送信側からローカルに保存されていないＭＰＵを取得する。これらのＭＰＵはｌｅｖｅｌ＿ｌｉｓｔ［１］− ｌｅｖｅｌ＿ｌｉｓｔ［０］により得たＭＰＵであり、ｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒは４，６である。受信側は４，６を受信した後にローカルに保存されている１，９と一緒にカット版のビデオに組み換える。

【0070】

上記の実施例ではＭＭＴを例にして、提出された解決方案について釈明しているが、これらの方案は同様に他のファイルのパッケージング、伝送システムおよびプロトコルにも用いられる。

【0071】

〔実施例３〕
上記の実施例１、２の技術に基づく応用の一つとして、本実施例では、コンテンツ駆動のスマートホームのコントロール方法を提供する。

【0072】

現在、スマートホーム設備は各家庭において現れつつある。フィリップス（Ｐｈｉｌｉｐｓ）会社が発表した「世の中で最もスマートなＬＥＤライト」と言われるＰｈｉｌｉｐｓ ｈｕｅという製品を例にして、いかにビデオおよびオーディオデータに対して標識することによりｈｕｅシステムを駆動する方法を示す。

【0073】

１． フィリップスｈｕｅについて
フィリップスｈｕｅは、見た目上普通の電球と同じであるが、ブリッジ接続方式により家のルータと接続してユーザーに更なるカスタマイズされた照明のコントロールをできるようにする。フィリップスｈｕｅにはＬＥＤ照明技術とワイヤレス相互接続技術が応用され、ＬＥＤ照明を提供するうえ、照明がより多く方面において人間の生活を便利にさせる。たとえば、携帯の位置決め機能によれば、帰宅または外出する際に、ｈｕｅにより自動的に電灯をつけたり、消したりまたは照明の色を変えたりすることができる。また、定時通知の機能によれば、ｈｕｅは毎日の生活がさらに規則正しくさせる。例えば、早朝は部屋内の照明を徐々に明るくさせ、夜は照明により入眠を通知する。フィリップスｈｕｅは「暖色のトーンから寒色のトーンまで、深さが異なる白いトーン」を提供できるとともに、事前にプログラムによって１６００万種類の色彩選択（赤緑青の組み合せ）を設置でき、リラックス、閲読、集中および活力を含む四種類の異なる事前プログラムも提供する。特定な雰囲気のために照明シーンを特定すること、遠距離に制御することおよび家の照明状況を監視すること、タイムスイッチを設置して日常に照明への要求を管理すること、照明によって睡眠を補助することまたは家族を目覚ますことなど、これらの全てについてフィリップスｈｕｅが完成できる。その他、ユーザーは設備中のある写真をパレットとして色を取り、一日の特定な時間に特定な色を活性化することを設置するということさえもできる。

【0074】

ｈｕｅの機能は絶えずに豊富され、あるネットワークプラットフォームでは開発者たちに向けてＡＰＩインターフェースとソフトウェア開発ツールキットＳＤＫにオープンして、新しい応用方法が次々に現れ、ユーザーも該プラットフォームを介して自らカスタマイズされた照明方案を共有でき、既に４０以上の新しいアプリケーションプログラムが開発されている。これらのプログラムは、ｈｕｅをより多くの設備およびアプリケーションプログラムと関連づけさせている。たとえば、あるものは照明の変化によって心拍を表示でき、あるものは人々が音により照明を制御できるようにし、あるものはテレビ画面の変化と同期することもできる。

【0075】

本実施例では、たとえば、上述したマルチメディアコンテンツにより自動的にフィリップスｈｕｅのようなスマートホームの制御システムを駆動する。使用しているマルチメディアコンテンツに対応するタブを追加し、これらのマルチメディアコンテンツを再生する度、これらのタブはスマート設備を駆動する。具体的な説明は図５に示される通りである。

【0076】

２． メディアデータのフラグメント（断片）に対してマークする
異種ネットワーク伝送プロトコルＭｐｅｇ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ（ＭＭＴ）において、すべてのメディアデータに対してフラグメンテーションＭＰＵのフォーマットによりパッケージングして、各ＭＰＵの時間長さは約０．５秒である。また、マルチメディアのオーディオデータとビデオデータにおけるビデオｖｉｄｅｏとオーディオａｕｄｉｏとを分けてパッケージングする。このようなメディアデータのパッケージングフォーマットに基づいて、以下に示すようないくつかの方法に従ってＭＰＵに対して標識できる。

【0077】

ａ） ビデオＭＰＵを主なフレームのメインカラーで標識する
フィリップスｈｕｅシステムにおいて、写真の色によって電球の色の変更を制御できるため、ビデオＭＰＵにおける主なフレームのメインカラーを抽出して標識することができ、ＭＰＵＢｏｘにおける予備されたｒｅｓｅｒｖｅｄフィールド７ｂｉｔによりｃｏｌｏｒ＿ｔａｇを定義し、異なる色に対しては異なるｃｏｌｏｒ＿ｔａｇを利用できる。たとえば、表９に示される通りである。

【0078】

【表9】

【0079】

ｃｏｌｏｒ＿ｔａｇの値は、ビデオＭＰＵにおける主なフレームのメインカラーの解析を介してｃｏｌｏｒ＿ｔａｇに対して値をつけることができ、ＭＰＵＢｏｘには必要な新しいプロパティが加えられる。またはアルゴリズムによって自動的にＭＰＵにおける主なフレームのメインカラーを抽出して値をつけることもできる。現在、本発明の一部の実施例ではｒｅｓｅｒｖｅｄの７番目のｂｉｔをｃｏｌｏｒ＿ｔａｇに用い、さらに多くのｂｉｔ桁が必要ならば、増やして拡張することもできる。

【0080】

ｂ） ビデオＭＰＵについてはシーンに応じて標識する
フィリップスｈｕｅシステムにおいて、生活における異なる雰囲気に応じて異なる照明パターンを表示できるため、本実施例ではビデオにおけるあるシーンのパターンを抽出できる。例えば、ロマンチックまたは激しいなどのパターンに属するか否かと判断し、ＭＰＵについて標識する。上の表にならって、ＭＰＵＢｏｘにおけるｒｅｓｅｒｖｅｄフィールドをｓｃｅｎｅ＿ｔａｇに定義でき、異なるアルゴリズムによってシーンにおけるパターンを抽出できる。

【0081】

【表10】

【0082】

ｃ） オーディオＭＰＵについて調子に応じて標識する
フィリップスｈｕｅシステムにおいて、音楽の調子の高さを利用して照明のパターンを制御できる。このため、本発明の一部の実施例では、オーディオＭＰＵにおける調子の特徴を抽出することにより、ＭＰＵを標識できる。上の表にならって、ＭＰＵＢｏｘにおけるｒｅｓｅｒｖｅｄフィールドをｔｏｎｅ＿ｔａｇに定義でき、異なるアルゴリズムを用いてオーディオデータの調子を抽出できる。

【0083】

メディアコンテンツの中に対応するｓｃｅｎｅ＿ｔａｇ，ｔｏｎｇ＿ｔａｇを加えているため、メディアコンテンツが正常に再生されている際、対応する新しい属性が設備に読み込まれると、該属性情報は照明の制御設備のインターフェースに伝送される。この場合、照明設備は受信した属性情報に基づいて、照明システムを制御するコマンドとパラメータを解析する。従って、メディアコンテンツの再生につれて照明がリアルタイムに調節されて変化することが実現される。

【0084】

以上においてはＭＰＵＢｏｘを例にして、いかに新しい属性を加えることにより、メディアコンテンツと照明とが連結されて表示することを実現することについて説明している。しかしながら、実際の応用において、新しい属性は実際の必要に応じてその他のコマンド位置に加えられてもよい。本発明の上記の実施例は照明を例にして、従来のマルチメディアとスマートホームとの連結方法について説明している。本発明の技術的思想および方法を応用して、その他のスマートホーム、さらにはスマート都市のシステムにも拡張して応用できる。

【0085】

〔実施例４〕
ユーザーがメディアコンテンツを再生する場合、往々には全部の番組内容について興味を持つことは少なく、番組における特定人物または特定シーンについてのみ興味を持っている可能性がある。スマートメディア伝送システムは、マルチメディアコンテンツを様々異なる角度から分類でき、即ち異なるタブをつけて、ユーザーのカスタマイズなニーズの実現に可能性を与える。サービスプロバイダーは異なるタブに応じて、異なるマルチメディアコンテンツのバージョンと異なるｅｄｉｔ ｌｉｓｔとを対応づけ、対応するタブはｅｄｉｔ ｉｄである。サービスにより提供されるｅｄｉｔ ｌｉｓｔに応じる内容をユーザーに識別させるため、対応する説明情報を伝送する必要があり、ユーザーのカスタマイズなニーズを保証する。

【0086】

同じコンテンツのレベル分け表示を例にして、ある映画番組について、ａｓｓｅｔ１であると仮定する。制作者側は多数の異なるバージョンのビデオを提供でき、ビデオの構成に従って、簡略版、カット版、完全版と拡張版などの再生時間の長さが異なるビデオバージョンを分けることができる。

【0087】

マルチメディアコンテンツのレベル分け情報およびその説明情報の対応関係をユーザーに表示し、ユーザーが選択しやすくなるようにするため、本発明の一部の実施例では、伝送する情報に説明情報（マルチメディアコンテンツの特徴情報または同一メディアリソースの各バージョンに関連づける情報）を追加するなどの方法によってカスタマイズ表示を実現する。以下の三つの方法を例にしながら、説明する。

【0088】

＜方法一＞ 既存のＣＩ（Ｃｏｍｐｏｓｉｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）情報のＭｅｄｉａＳｙｎｃ要素にｄｅｓｃｒｉｐｔｉｏｎの属性を新規追加して、異なるバージョンのコンテンツの説明情報の説明に用いる。たとえば、以下の表１１に示される通りである。

【0089】

【表11】

【0090】

ＣＩ情報には主にｖｉｅｗ要素、ａｒｅａ要素、ＭｅｄｉａＳｙｎｃ要素およびＯｐｔｉｏｎ要素が含まれている。ここで、ｖｉｅｗ要素は視覚領域に対して配置を変更する時間領域の制御情報を提供するし、ａｒｅａ要素はｖｉｅｗ要素のサブ要素で、即ち視覚ｖｉｅｗの一部分であって、ＣＩと組み合わせされているＨＴＭＬ５ファイルのあるｄｉｖ要素に対応する。ＭｅｄｉａＳｙｎｃ要素はＣＩと組み合わせされているＨＴＭＬ５ファイルのあるメディアリソースを指し示すために用いられ、Ｏｐｔｉｏｎ要素は該部分のＣＩが選択できることを示すために用いられる。

【0091】

各ＣＩ要素は、異なる属性を持つことができる。上記の表における属性の中、ｉｄ属性は該要素の識別子であり、ｓｔｙｌｅ属性は該要素のＣＣＳ様式を指定するために用いられる。ｂｅｇｉｎ属性は該ＣＩ指令の働き開始時間を示し、ｅｎｄ属性は該ＣＩ指令の働き終了時間を示す。ｒｅｆＤｉｖ属性は該要素の対応するＨＴＭＬ５ファイルにおけるｄｉｖ要素の識別子を指し示し、ｒｅｆＩｄ属性は該要素の対応するＨＴＭＬ５ファイルにおけるある要素の識別子を指し示す。ｍｅｄｉａＳｒｃ属性はメディアリソースのアドレスを指し示す。なお、ｄｅｓｃｒｉｐｔｉｏｎ属性は新たに追加した属性である。

【0092】

ＣＩファイルの機能は、メディアリソースの表示を指導することであり、ｅｄｉｔ ｌｉｓｔはリソース解析に関連する情報である。このため、ｅｄｉｔ ｌｉｓｔの内容を既存のＣＩファイルに追加できる。受信側は、ＣＩファイルを解析する場合、ｅｄｉｔ ｌｉｓｔ情報の解析をサポートする必要がある。ＣＩファイルにおけるＭｅｄｉａＳｙｎｃ要素は、メディアリソースの指定に用いられる。そこで、メディアリソースを指定するとともに、メディアリソースに説明情報も追加できる。したがって、ＭｅｄｉａＳｙｎｃ要素の下にｄｅｓｃｒｉｐｔｉｏｎの属性を追加して、メディアリソースに対応するコンテンツの説明情報を説明するために用いる。

【0093】

上記プログラムにおけるメディアリソースは、ビデオおよび音声を含み、それぞれａｓｓｅｔ１およびａｓｓｅｔ２である。サーバーは、ａｓｓｅｔにおけるメディアデータユニットの識別子を識別し、異なるｅｄｉｔ ｌｉｓｔに分類する。各ｅｄｉｔ ｌｉｓｔは、対応するｅｄｉｔ ｉｄによって識別され、伝送されるｅｄｉｔ ｌｉｓｔおよび対応するメディア説明情報ｄｅｓｃｒｉｐｔｉｏｎが含まれている対応するＣＩファイルが生成される。クライアント側は、受信したＣＩファイルを解析し、ユーザーのニーズに基づいて対応するｄｅｓｃｒｉｐｔｉｏｎを選択し、ｅｄｉｔ ｉｄ情報を解析して対応するメディアデータユニットをリクエストする。

【0094】

（方法二）ＣＩファイルにおいて新しいＥｄｉｔＤｅｓｐ要素を追加して説明する

【0095】

【表12】

【0096】

メディアリソースの情報は、ＭｅｄｉａＳｙｎｃに置かれている。ＣＩにおいて、ＭｅｄｉａＳｙｎｃと同じレベルの新しい要素であるＥｄｉｔＤｅｓｐを新規追加し、メディアリソースにおけるあらゆる関連コンテンツの説明情報を指し示すために用いる。ｅｄｉｔ要素はＥｄｉｔＤｅｓｐ要素のサブ要素であって、一つのｅｄｉｔ要素は一種類のカスタマイズ表示の説明情報を特徴付ける。ｅｄｉｔ要素において、ｅｄｉｔ＿ｉｄ属性およびｄｅｓｃｒｉｐｔｉｏｎ属性を新規追加する。ｅｄｉｔ＿ｉｄ属性は、あるレベルまたはある部分のメディアリソースの識別に用いられ、ｄｅｓｃｒｉｐｔｉｏｎ属性は、メディアリソースのコンテンツの説明情報の説明に用いられる。

【0097】

上記プログラムにおけるＥｄｉｔＤｅｓｐ要素において、メディアリソースにおける四つの関連するコンテンツの説明を定義し、対応するｅｄｉｔ＿ｉｄに書き込む。クライアント側は、受信したＣＩファイルを解析し、ユーザーのニーズに基づいて対応するｄｅｓｃｒｉｐｔｉｏｎを選択し、ｅｄｉｔ ｉｄ情報を解析して対応するメディアデータユニットをリクエストする。サーバー側は、同一のメディアリソースに対して同じかつ完全なＣＩファイルを生成し、ユーザーのカスタマイズのニーズを満たすとともに、サーバーが関連する説明および対応するｅｄｉｔ ｉｄを重複して生成することを低減する。

【0098】

（方法三）シグナリングにおいてｄｅｓｃｒｉｐｔｏｒの説明を追加する

【0099】

【表13】

【0100】

上記表に含まれる対応する要素の意味は以下の通りである。
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ − 該ｄｅｓｃｒｉｐｔｏｒタイプを定義するタグである。
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ − 該ｄｅｓｃｒｉｐｔｏｒの長さを定義する。
ｅｄｉｔ＿ｌｉｓｔ＿ｎｕｍｂｅｒ − メディアリソースに関連するコンテンツを定義し、Ｎ１は関連するコンテンツの数を示す。
ｅｄｉｔ＿ｉｄ − メディアリソースに関連するコンテンツの各バージョンの番号を定義する。
ｅｄｉｔ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｌｅｎｇｔｈ − メディアリソースレベルにおいて説明される情報の長さであり、単位はバイトとする。
ｅｄｉｔ＿ｄｅｓｃｒｉｐｔｉｏｎ＿ｂｙｔｅ − 具体的な説明情報における一バイトである。

【0101】

サーバー側は、メディアリソースにおけるメディアデータユニットの識別子を識別し、また異なるｅｄｉｔ ｌｉｓｔに分類する。各ｅｄｉｔ ｌｉｓｔは、対応するｅｄｉｔ ｉｄによって識別される。ユーザーとシステムとの間のコミュニケーションを実現するため、伝送されるメディアリソースを識別し、またニーズに応じて対応するコンテンツを選択して表示するため、システムは伝送されるｅｄｉｔ ｌｉｓｔおよび対応するメディアの説明情報ｄｅｓｃｒｉｐｔｉｏｎが含まれているｄｅｓｃｒｉｐｔｏｒシグナリングを生成する。クライアント側は、受信したシグナリング情報を解析し、ユーザーのニーズに基づいて対応するｄｅｓｃｒｉｐｔｉｏｎを選択し、ｅｄｉｔ ｉｄ情報を解析して対応するメディアデータユニットをリクエストする。コンテンツに関連する説明情報の場合、該ｄｅｓｃｒｉｐｔｏｒをａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓに加えることによって実現できる。

【0102】

以上のとおり、実施例１、２は、カスタマイズ表示のＤＡＳＨとＭＭＴとの二つの伝送プロトコルにおける異なる実現方法であって、メディアコンテンツを異なるｌｅｖｅｌに分けて（即ち本実施例におけるｅｄｉｔ ｌｉｓｔ）伝送を行う。一方、実施例３は異なるｌｅｖｅｌの具体的な応用である。ユーザーとしては、異なるｅｄｉｔ ｌｉｓｔを区別しない。ユーザーは、それに対応する説明情報のみを理解できる。例えば、異なるｅｄｉｔ ｌｉｓｔが異なるビデオバージョンに対応することなどである。これ点は、本実施例が上記実施例との区別である。

【0103】

本発明が提供する実現方法をより明瞭に説明するために、図４に示されるように、上記方法二の説明方法に従ってＣＩファイルを構成し、例示しながら具体的な実現プロセスについて説明する。図４に示されるように、受信側がＶｏＤサービスにログインする場合、送信側はシグナリング情報を送信し、受信側はＭＰＩテーブルにおけるＰＩ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅ＿ｌｅｎｇｔｈ＿ｂｙｔｅフィールドを判断することによってＣＩとＨＴＭＬ５ファイルを受信するとともに、ローカル保護のＭＰＵ保存データベースＭｙＳＱＬを更新して生成し、またＣＩとＨＴＭＬ５ファイルを解析する。そして、ＣＩにおける制御情報および新規追加のマルチメディアコンテンツの説明情報ｄｅｓｃｒｉｐｔｉｏｎに基づいて、ユーザーにカスタマイズ表示のレベル分け情報を提供する。ユーザーがレベル分け情報に基づいて簡略版のビデオをリクエストする場合、受信側はＣＩファイルを通じて簡略版とｅｄｉｔ＿ｌｉｓｔ［０］との対応を見つけ出し、また対応するｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒメディアデータの識別子が１，９であることを見つけ出す。この場合、クライアント側は、これらのＭＰＵをリクエストしてローカルに保存し、ユーザーに再生し、さらにローカルのデータベースを更新する。ユーザーが引続きカット版のビデオをリクエストする場合、ＣＩファイルとローカルデータベースを検査することによって、送信側からローカルに保存されていないＭＰＵを取得する。これらのＭＰＵは、ｅｄｉｔ＿ｌｉｓｔ［１］に対応するＭＰＵであり、ｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒメディアデータ識別子は４，６である。受信側は、４，６を受信した後、ローカルに保存されている１，９と一緒にカット版のビデオに組み換える。

【0104】

〔実施例５〕
本実施例は、実施例１、２を前提にして、既存のマルチメディアプロトコルにおける表示メカニズムの不備について、ユーザーの意思決定に基づくオンデマンドサービスにおける表示メカニズム、ラジオ、リアルタイム生放送サービスのプッシュ型配信メカニズム、および関連するコンテンツの表示サービスを真剣に考慮する。同一メディアリソースに関連するコンテンツバージョンにおいて、各メディアデータユニットの表示時間は同じではない。メディアデータユニットの持続期間を抽出することによって、ユーザーが選択するバージョンおよび再生過程における異なる操作に基づいて、シグナリング情報における開始時間のもとにメディアデータユニットの持続期間を累加して対応するバージョンのメディアコンテンツの表示タイムラインを生成する。あるいは、シグナリングを生成する同時にメディアデータユニットの絶対表示時間を生成し、ユーザーの選択に基づいて、対応する表示タイムライン情報を生成する。

【0105】

具体的には、サーバーは、メディアコンテンツとメディア説明のマッピングテーブルをユーザーに伝送すること、即ち関連するメディアコンテンツの選択肢をユーザーに提供する。ユーザーは、自らの必要に応じて同一コンテンツの異なるバージョンをリクエストしたり、もしくはあるメディアリソースの関連コンテンツなどの各種の表示形式をリクエストしたりできる。保存リソースを節約し、差異化伝送を実現するため、同一メディアリソースの異なるバージョンには共用のデータユニットが含まれている。しかしながら、既存のシステムは異なるバージョンのコンテンツの表示時間を制御できないため、メディアを再生するときに、空きセグメントを生じさせる可能性があり、ユーザーエクスペリエンスに影響を与える。既存のシステムを利用して各データユニットの持続期間の情報を提供し、異なる伝送ネットワークの特性を配慮している。例えば、ＶｏＤ（Ｖｉｄｅｏ ｏｎ Ｄｅｍａｎｄ）はユーザーにより選択される番組の時間に基づいてメディアリソースの初期表示時間を決める一方、ラジオおよびリアルタイム生放送は所定の時間に各設備に同期的に表示する、ということを配慮する。しかしながら、ランダムアクセスの問題およびリアルタイム生放送における実用性を考える必要がある。したがって、本実施例では三つの状況においての伝送ネットワークを例にして、異なるカスタマイズ表示タイムラインの制御メカニズムについて説明する。

【0106】

（応用一） ＶｏＤ
ＶｏＤサービスにおいて、ユーザーがあるマルチメディアコンテンツを選択すると、サーバーはこのような要求に応答し、ユーザーが選択するバージョンに基づいて対応するメディアデータユニットの持続時間を読み込み、対応する指導表示情報ファイルとシグナリング情報を生成する。

【0107】

同じコンテンツのレベル分け表示を例にして、ある映画番組について、ａｓｓｅｔ１と仮定する。図１に示されるように、第一のバージョンのビデオは簡略版の予告編であって、再生時間の長さは５分であり、映画中のハイライトのみが含まれている。第二のバージョンのビデオはカット版であって、再生時間の長さは３０分であり、映画の物語の主なストーリーと重要なシーンのみが含まれている。第三のバージョンのビデオは完全版であって、再生時間の長さは１２０分であり、映画の物語の完全なストーリーが含まれている。第四のバージョンは拡張版であって、再生時間の長さは１５０分であり、完全な物語のストーリーが含まれている他、メイキングなどの補充コンテンツも含まれている。

【0108】

（応用二） ラジオ番組
ラジオサービスにおいて、サーバーは予め定められる番組リストにしたがってメディアデータストリームを伝送する。ユーザーのランダムアクセスの問題に配慮して、サーバーは表示に関連する情報を交互に再生する必要がある。ユーザーは、アクセスする際に受信した現在の表示タイムラインに基づいてメディアコンテンツを見ることができる。同時に、視聴設備の状況、例えばバッテリー残量レベルなどの指標に基づいてリアスタイムに視聴のモードを切替え、設備状況に適応する上、より良いユーザーエクスペリエンスを提供する。

【0109】

ラジオにより伝送される球技試合の番組を例にすると、ユーザーがモバイル設備にて球技試合を見る場合、設備のバッテリー残量を考える必要がある。メディアデータユニットを生成する際、メディアデータユニットの重要性に応じて分類する。例えば、ハイライトとゴールなどの場面は該番組における異なる関連コンテンツであり、図６に示すように、それぞれ異なる識別子を付ける。ユーザーのバッテリー状況は、大体に充分、中等と不足というレベルに分けられる。

【0110】

設備のバッテリー残量が対応するレベルになると、対応するリクエストをサーバーに送信し、サーバーは、自動的に送信するビデオメディアコンテンツおよび完全な音声コンテンツを切替え、伝送のタイムラインに基づいてメディアコンテンツの同期を制御する。なお、一部のビデオメディアコンテンツを伝送する場合、ビデオデータユニット内部の時間情報を解析することができない。したがって、対応するタイムラインに関連するシグナリングを解析することによって時間の情報を取得し、設備状況に適応する番組表示を実現する。

【0111】

（応用三） リアルタイム生放送
リアルタイム生放送のサービスにおいて、メディアデータを記録処理した後は直接にクライアント側に伝送する。このため、リアルタイム性に対する要求は非常に高い。リアルタイム生放送におけるユーザーのカスタマイズニーズの実現を満たすため、メディアリソースの関連コンテンツに対してはすべて迅速に独立したタイムラインを生成し制御する必要がある。

【0112】

例えば、リアルタイム生放送を見るとき、ほとんどのユーザーは、図７に示すように、多視野角のサービスによって番組内容を見たがる。ネットワークの帯域幅を節約しながら安定にリアルタイムの多視野角のサービスを提供するため、サービスより提供される内容は、いずれも放送ネットワークを介してユーザーに伝送されるとともに、該メディアリソースの全ての関連コンテンツの表示タイムライン情報も伝送される。各関連コンテンツのトータル時間とコンテンツを構成したメディアデータユニットの表示時間が異なるため、異なる複数のタイムラインを生成し表示を制御する必要がある。

【0113】

本発明ではメディアリソースを独立に解析可能なメディアユニットに分け、メディアユニットの関連関係を利用し、ユーザーにより選択される異なるビデオバージョンに基づいて、自動的に対応する表示タイムラインを生成する。従って、本発明における表示メカニズムは、既存技術と比べ、よりフレキシブルである。

【0114】

以下、本発明の一部の具体的な実施例について詳しく説明する。
ユーザーがメディアコンテンツを再生する場合、往々には番組内容の全部について興味を持つことが稀で、番組における特定人物または特定シーンについてのみ興味を持っていることがある。スマートメディア伝送システムは、メディアコンテンツを異なる角度から分類でき、即ち異なるタブを付け、ユーザーのカスタマイズニーズの実現のために可能性を与える。カスタマイズ表示の場合、異なるバージョンの関連コンテンツは共用のメディアデータユニット含むが、これらのデータユニットの各バージョンにおける表示時間が異なるため、各バージョンに対して異なるタイムラインを生成し、再生を制御する必要がある。

【0115】

上記の例において、各バージョンにおけるＭＰＵ（ｍｅｄｉａ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔｓ）メディアデータユニットの表示時間は、図８に示される通りである。ここで、ｄｕｒｉは第ｉ個のＭＰＵの持続期間を表示する。図に示されるように、一つのメディアリソースにおいて、同じＭＰＵの表示時間は異なっている。従って、同一メディアリソースの異なる関連バージョンは、いずれも独立したタイムラインで表示を指導する必要がある。

【0116】

カスタマイズサービスにおけるユーザーエクスペリエンスを保証するため、メディアコンテンツがタイムライン応じて順番にユーザーが選択したコンテンツを表示できるよう、異なるメディアリソース、または同一メディアリソースの異なるバージョンのコンテンツに対して対応する表示タイムラインを提供する。本発明では、新しいｄｅｓｃｒｉｐｔｏｒ、またはその他の指導情報、例えばｍｅｓｓａｇｅ、ｔａｂｌｅのようなシグナリング情報を新規追加することを介して、表示タイムラインの伝送を実現している。以下では、三つの方法を例にして説明する。

【0117】

（方法一）
ＭＭＴにおいて定義したＭＰＵ ｔｉｍｅｓｔａｍｐ ｄｅｓｃｒｉｐｔｏｒを採用する。該ｄｅｓｃｒｉｐｔｏｒには、ＭＰＵが一つのメディアリソースにおいて対応するラベルｍｐｕ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒおよび対応するＵＴＣ絶対表示時間が標識つけられている。該ｄｅｓｃｒｉｐｔｏｒのシンタクチック構造は表１４に示される通りである。

【0118】

【表14】

【0119】

ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ − 該ｄｅｓｃｒｉｐｔｏｒタイプを定義するタグである。
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ − 該ｄｅｓｃｒｉｐｔｏｒの長さを定義する。
ｍｐｕ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ − 順番にしたがって対応するメディアリソースに含まれる全てのＭＰＵのラベルをリストし、ＮはＭＰＵの数を示している。
ｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ − 該ｄｅｓｃｒｉｐｔｏｒに対応するメディアリソースに含まれる全てのＭＰＵのＵＴＣ絶対表示時間をリストする。

【0120】

メディアコンテンツを伝送する過程において、ユーザーにより選択されるメディアコンテンツに基づいて、対応するメディアデータユニットＭＰＵを選択して、その持続期間情報ｄｕｒａｔｉｏｎを解析する。メディアリソースの関連コンテンツを選択する場合、各関連コンテンツのバージョンに含まれるＭＰＵは重複することがあり、即ち同一ＭＰＵは異なる関連コンテンツバージョンにおいて異なる絶対表示時間を持つ可能性があり、サーバーはユーザーにより選択されるバージョンに応じて対応するＭＰＵの持続期間情報を取得する。ユーザーにより選択されるメディア再生時間、またはシステムにより決められるメディア再生時間にあわせて、指定されるＭＰＵよりも前の全てのＭＰＵの持続期間を累加することにより、各ＭＰＵに対応するＵＴＣ絶対表示時間、即ちｄｅｓｃｒｉｐｔｏｒにおけるｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅを計算する。

【0121】

既存のＭＭＴプロトコルが定義したシグナリング情報においては、説明的なｄｅｓｃｒｉｐｔｏｒ、例えばｄｅｐｅｎｄｅｎｃｙ ｄｅｓｃｒｉｐｔｏｒとＭＰＵ＿ｔｉｍｅｓｔａｍｐ＿ｄｅｓｃｒｉｐｔｏｒが定義されている。このため、メディアコンテンツと対応する表示関連の時間情報を提供できるｄｅｓｃｒｉｐｔｏｒを定義できる。ＭＰ ｔａｂｌｅにおいてはａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓフィールドがあり、必要に応じてａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓにおいて関連するｄｅｓｃｒｉｐｔｏｒを加えることができる。マルチメディアサービスを使用する際、該ｄｅｓｃｒｉｐｔｏｒをａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓに加えることにより表示を実現できる。

【0122】

しかし、オーデマンドサービスはユーザーにより主導されるため、ユーザーが見る過程において操作、例えば一時停止や早送りなどを行うことを考慮する必要がある。このような場合、サーバーが対応する各ＭＰＵのＵＴＣ絶対表示時間のみを提供すると、正確に再生を継続することができなくなり、サーバーにより表示タイムラインを新たに生成して伝送する必要があるため、膨大な計算負担および冗長性を生じさせるだけでなく、一定の遅延も生じさせてしまい、ユーザーエクスペリエンスに影響を与える。選ばれたメディアコンテンツが生放送サービスにおける放送時間が固定であるため、放送サービスにおいてＵＴＣ絶対表示時間、即ちｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅを採用することは便利な方法である。ユーザーがメディアリソースを受信し、それに関連するサービスを選択するのとともに、対応するＭＰＵ＿ｔｉｍｅｓｔａｍｐ＿ｄｅｓｃｒｉｐｔｏｒも受信する。各関連部分のコンテンツのメディアデータユニットは、記述子における時間情報に基づいて固定の時間に表示すればよい。

【0123】

（方法二）
ＭＰＵ ｔｉｍｅｓｔａｍｐ ｄｅｓｃｒｉｐｔｏｒを定義する。同一メディアリソースの関連内容およびそれに対応するＭＰＵの集合によってｅｄｉｔ ｌｉｓｔを定義し、各バージョンの関連コンテンツに独立したｅｄｉｔ ｉｄを付与する。ｄｅｓｃｒｉｐｔｏｒにおいて各ｅｄｉｔ ｌｉｓｔに含まれている全てのＭＰＵのｍｐｕ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒと対応する表示時間情報を説明する。該ｄｅｓｃｒｉｐｔｏｒのシンタクチック構造は表１５に示される通りである。

【0124】

【表15】

【0125】

ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ − 該ｄｅｓｃｒｉｐｔｏｒタイプを定義するタグである。
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ − 該ｄｅｓｃｒｉｐｔｏｒの長さを定義する。
ｅｄｉｔ＿ｌｉｓｔ＿ｎｕｍｂｅｒ − メディアリソースの関連コンテンツを定義し、Ｎ１はその数を示す。
ｅｄｉｔ＿ｉｄ − メディアリソースの関連コンテンツの各バージョンの番号を定義する。
ｍｐｕ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ − 順番にしたがって対応するメディアリソースに含まれる全てのＭＰＵのラベルをリストし、ＮはＭＰＵの数を示している。
ｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ − 該ｄｅｓｃｒｉｐｔｏｒに対応するメディアリソースに含まれる全てのＭＰＵのＵＴＣ絶対表示時間をリストする。

【0126】

メディアコンテンツを伝送する過程において、ユーザーにより選択されるメディアコンテンツに基づいて、選ばれたメディアリソースの全ての関連コンテンツのＵＴＣ絶対表示時間ｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅを全部該ｄｅｓｃｒｉｐｔｏｒに書き込む（時間情報を取得する方法は方法一を参照）。メディアコンテンツを消費する過程において、サーバーはシグナリング情報により上記のｄｅｓｃｒｉｐｔｏｒをクライアント側に送信する。ユーザーはあるバージョンの関連コンテンツを選択し、それに対応するｅｄｉｔ＿ｉｄに基づいてメディアデータユニットＭＰＵと対応する絶対表示時間ｍｐｕ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅを解析し、バージョンに対応するタイムラインを生成して表示を制御する。このような方法によれば、便利に各関連バージョンのメディアコンテンツの表示時間を取得でき、ユーザのカスタマイズニーズはいずれも同じｄｅｓｃｒｉｐｔｏｒ情報を介して指導を受けて表示するため、制御しやすい。

【0127】

（方法三）
シグナリングにおいてあるメディアリソースにおける各ＭＰＵの持続期間を説明し、ＣＩ（Ｃｏｍｐｏｓｉｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）において該メディアリソースの開始時間を知り、計算により各ＭＰＵのＵＴＣ絶対表示時間を得ることができる。

【0128】

【表16】

【0129】

ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ − 該ｄｅｓｃｒｉｐｔｏｒタイプを定義するタグである。
ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ − 該ｄｅｓｃｒｉｐｔｏｒの長さを定義する。
ｍｐｕ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒ − 順番にしたがって対応するメディアリソースに含まれる全てのＭＰＵのラベルをリストし、ＮはＭＰＵの数を示している。
ｍｐｕ＿ｄｕｒａｔｉｏｎ − 該ｄｅｓｃｒｉｐｔｏｒに対応するメディアリソースに含まれる全てのＭＰＵのＵＴＣ絶対表示時間をリストする。

【0130】

メディアコンテンツを伝送する過程において、ユーザーにより選択されるメディアコンテンツに基づいて、それに対応するメディアデータユニットＭＰＵを選択し、その持続期間情報ｄｕｒａｔｉｏｎを解析するのとともに、指導の表示情報、即ちＭＰＵのラベルｍｐｕ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒと対応するｄｕｒａｔｉｏｎ情報を生成する。

【0131】

異なる伝送ネットワークの状況を考えれば、このような方法は、メディアデータユニットを生成してパッケージングするとともに、それに対応する持続期間ｄｕｒａｔｉｏｎ情報を取得できる。このため、よりリアルタイム性のニーズ、即ちリアルタイム生放送の応用ニーズを満たすことができる。絶対表示時間の代わりにｄｕｒａｔｉｏｎ情報を伝送することにより、クライアント側はよりフレキシブルにメディアコンテンツを自ら構築できる。それとともに、ブロードバンドオンデマンドの業務においても、ユーザーがいつでも入力操作が可能で、ユーザーのカスタマイズニーズを満たしている。

【0132】

上記の三つの方法は、ブロードバンドネットワークおよび放送ネットワーク、ひいては異種ネットワークなどを含む多数のマルチメディア伝送システムをカバーできる。さらに、表示指導ファイルＣＩにおいて、またはシグナリング情報を伝送するその他の位置において対応する表示タイムラインを加えることによっても、同様にカスタマイズ表示サービスを実現できる。

【0133】

表示を制御する過程において、放送およびリアルタイム生放送は、いずれもユーザーの現在のアクセス時間から再生するため、帯域幅リソースおよびクライアント側の保存リソース並びに計算の消費を節約するため、上記のｄｅｓｃｒｉｐｔｏｒにおいては消費されていないＭＰＵの表示時間情報またはｄｕｒａｔｉｏｎ情報（以下、この二種類の時間情報を関連時間情報とも通称する）のみ書き込み、メディアリソースに対応する全てのＭＰＵの関連時間を書き込まない。このような方法によれば、シグナリング情報を生成する難易度が増やされるが、伝送ネットワークの帯域幅およびクライアント側の有限な計算能力を大幅に節約できる。さらに、オンデマンドサービスにはランダムにアクセスされる問題がないため、ユーザーがサービスを開始する際、限られた数のＭＰＵの関連時間情報を伝送でき、ユーザーの再生進捗に応じて後続のＭＰＵ関連時間情報を伝送する。観賞の順調性を保証するため、観賞しているユーザーの操作にタイムリーに応答し、関連時間情報を伝送し、表示タイムラインを更新する必要がある。

【0134】

本発明に係る実現方法をより分かりやすく説明するため、以下では、上記の方法三において説明した方法に従ってＭＰＵ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒを生成し、ＶｏＤサービスにおけるカスタマイズ表示タイムラインメカニズムを構築し、具体的な実現プロセスを例示しながら説明する。

【0135】

図４に示すように、上記の方法三を例にして説明する。図４は、マルチメディアコンテンツのカスタマイズ表示のタイムラインの制御方法を説明するための図であり、その具体的なプロセスは次のとおりである。
受信側がＶｏＤサービスをリクエストする場合、送信側はシグナリング情報を送信し、受信側はＭＰＩ表におけるＰＩ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅ＿ｌｅｎｇｔｈ＿ｂｙｔｅフィールドを判断することによりＭＵＲ、ＣＩとＨＴＭＬファイルを受信するとともに、ローカル保守のＭＰＵ保存データベースＭｙＳＱＬを更新し生成する。ユーザーが簡略版のビデオをリクエストする場合、受信側は関連メディアコンテンツのｅｄｉｔ＿ｌｉｓｔシグナリング情報を検索することにより簡略版のビデオに対応するｅｄｉｔ＿ｌｉｓｔのラベルｅｄｉｔ＿ｉｄ＝００、およりそれに含まれるメディアユニットのｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒが１、９であることを取得する。この場合、受信側はｅｄｉｔ＿ｉｄ＝００のメディアコンテンツをリクエストする。送信側はリクエストを解析して対応するｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒを取得し、メディアデータユニットＭＰＵを解析して対応する持続時間ｄｕｒａｔｉｏｎ情報を取得し、ＭＰＵ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒシグナリングを生成する。受信側は、対応するシグナリングを受信し、ＭＰＵ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒとＣＩにおける開始時間に基づいて各ＭＰＵの絶対表示時間を生成し、表示タイムラインを保守する。それとともにメディアデータを受信し、ローカルに保存してユーザーに再生し、ローカルデータベースを更新する。ユーザーが引き続いてカット版のビデオをリクエストするならば、カット版のビデオではｅｄｉｔ＿ｉｄ＝００Ｕ０１である。関連メディアコンテンツのｅｄｉｔ＿ｌｉｓｔシグナリングとローカルデータベースにおける既存のＭＰＵをチェックすることにより、送信側にｅｄｉｔ＿ｉｄ＝０１のメディアリソースをリクエストする。受信側は、シグナリングとメディアデータを受信した後、解析してリソースにおけるメディアデータユニットｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒを取得し、ＭＰＵ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒシグナリングにおけるｄｕｒａｔｉｏｎ情報に基づいてカット版のビデオに含まれるＭＰＵの表示時間を新たに計算し、表示タイムラインを更新する。それとともに、ｍｐｕ＿ｓｅｑ＿ｎｕｍｂｅｒが４、６のＭＰＵを受信し、ローカルに保存する。

【0136】

本実施例では、ユーザーのカスタマイズニーズを満たすとともに、同じ特性の番組の関連性を利用して、保存スペースを節約するうえ、ユーザーの順調な楽しみ体験を保障できる。メディアの表示ライムライン情報がシグナリング情報に応じて柔軟に発送されるため、メディアリソースを消費する過程において表される遅延とパケットロスによるユーザーエクスペリエンスの低下について、表示時間の前にパケットロスを発見する場合、メディアリソースを新たに取得することを待つか、一つ前のメディアデータユニットの内容を繰り返し表示することにより再生故障を避けてユーザーエクスペリエンスを保証できる。

【0137】

上記の本発明に係る実施例においてはＭＭＴを例にして、解決方法を釈明しているが、これらの方法はその他のファイルのパッケージング、伝送システムおよびプロトコルにも用いられる。

【0138】

以上、本発明の具体的な実施例について説明した。ただし，本発明は上記特定の実施形態に限定されず，いわゆる当業者であれば特許請求の範囲内において様々な変形や改良を行うことができるが，これらは本発明の実質的な内容に影響を及ぼさないことに理解すべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】