ブロードキャスト用クリップのスケジューラ
スケジューラは、放送網を介した送信のためにマルチメディアコンテンツファイルをスケジューリングする。マルチメディアコンテンツファイルは、スポーツビデオ、音楽ビデオ、ニュースクリップ、映画サウンドトラック等といったオーディオ／ビデオクリップのいずれの種類であってもよい。特に、スケジューラは、コンテンツファイルについての送信順序を決定して、静的部分及び動的部分を有する電子サービスガイドを生成する。動的部分において、スケジューリングされたコンテンツは電子サービスガイドの異なるバージョンにおいて異なる送信順序を有することができる。スケジュールタイミング情報及びメタデータ情報は、クリップとともに放送網を介して送信され、レシーバは好みのクリップを選択的に受信して、バッテリ電源及び記憶装置を節約することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、通信システムに関し、特に、地上波放送、セルラー方式、ワイヤレスフィデリティ（Ｗｉ−Ｆｉ）方式、衛星システムなどの無線システムに関する。
【背景技術】
【０００２】
今日、ＭＰ３プレーヤから携帯情報端末、携帯電話、モバイルテレビ（ＴＶ）まで、モバイル機器があふれている。残念なことに、モバイル機器には、通常、コンピュータ資源及び／または電力に制約がある。この点で、ＤＶＢ−Ｈ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ）システムによるインターネットプロトコル（ＩＰ）データ放送は、エンドツーエンドのブロードキャストシステムであってかかるデバイス用に最適化されたＩＰベースのメカニズムを用いてあらゆる種類のファイル及びサービスを配信する。例えば、非特許文献１、非特許文献２、非特許文献３、及び、非特許文献４を参照せよ。当該技術分野で周知のＤＶＢ−ＨシステムによるＩＰデータ放送の例が図１に示されている。図１において、ヘッドエンド１０（本明細書において「サーバ」とも称される）は、レシーバ９０で表示されているような、１つまたは複数の受信装置（本明細書において「クライアント」または「レシーバ」とも称される）に、アンテナ３５を介して、ＤＶＢ−Ｈ信号３６をブロードキャストする。ＤＶＢ−Ｈ信号３６は、ＩＰデータ放送をクライアントに伝達する。レシーバ９０は、アンテナ（図示せず）を介して、ＤＶＢ−Ｈ信号３６を受信し、ＩＰデータ放送のＤＶＢ−Ｈ信号３６をリカバリする。図１のシステムは、片方向ネットワークを表す。
【０００３】
上記のＩＰデータ放送は、例えば電子サービスガイド（ＥＳＧ）及びコンテンツファイルなどのファイルを配布することによってコンテンツベースのサービスを提供するために用いられる。図１の内容において、コンテンツベースのサービスは、テレビ（ＴＶ）番組などのリアルタイムコンテンツ、または通常のＴＶプログラムより短いショートフォームコンテンツなどのファイルベースのコンテンツであってもよい。ＥＳＧによって、ユーザがコンテンツベースのサービスを選択し、レシーバが選択されたコンテンツをリカバリできるようにする能力が提供される。この点で、ＥＳＧは、通常、コンテンツ（「コンテンツ」は、本明細書においてイベントとも称される）に関する記述データまたはメタデータを含む。このメタデータは、本明細書において「コンテンツメタデータ」と称され、「コンテンツメタデータ」は、例えばテレビ番組の名前、粗筋、俳優、ディレクタ等、及び放送開始時間、放送日、放送時間、及び放送チャネルを含む。レシーバ９０に付随するユーザは、ＥＳＧで識別される適当なチャネルにレシーバ９０を同調させることにより、ＥＳＧで参照されるコンテンツを受信することができる。ＴＶ放送などのリアルタイムコンテンツの場合には、ＥＳＧがセッション記述プロトコル（ＳＤＰ）ファイルを含むことに注意しなければならない（例えば、非特許文献５を参照する）。ＳＤＰファイルには、レシーバ９０が選択されたブロードキャストコンテンツを受信できるようにする追加の情報が含まれる。
【０００４】
ファイルベースのコンテンツについて、図１のヘッドエンド１０は、ＦＬＵＴＥ（ＦｉｌｅＤｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）プロトコル（例えば、非特許文献６を参照する）を用いてファイルを配布する。ＦＬＵＴＥプロトコルは、片方向ネットワークを介してファイルまたはデータを送信するために用いられ、マルチキャストファイル配信を提供する。また、この例では、ヘッドエンド１０は、ＦＬＵＴＥのための基本トランスポートとして、ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ）プロトコルを用いると考えられる（例えば、非特許文献７を参照する）。ＡＬＣプロトコルは、任意のバイナリオブジェクトの配信のために設計されている。ＡＬＣプロトコルは、大規模で拡張性のある片方向マルチキャスト配信に特に適している。
【０００５】
図２を、簡単に参照すると、ＦＬＵＴＥを用いたファイルベースのコンテンツの送信が、ＥＳＧをブロードキャストしているヘッドエンド１０の内容において示されている。他のファイルベースのコンテンツの送信は、同様であって、本明細書において説明されていない。ヘッドエンド１０は、ＥＳＧジェネレータ１５、ＦＬＵＴＥセンダ２０、ＩＰカプセル化装置２５、及びＤＶＢ−Ｈモジュレータ３０を含む。ＥＳＧジェネレータ１５は、ＦＬＵＴＥセンダ２０にＥＳＧに出力する。ＦＬＵＴＥセンダ２０は、ＡＬＣを介してＦＬＵＴＥによりＥＳＧをフォーマットし、ＩＰカプセル化装置２５へＦＬＵＴＥファイルを伝達する得られたＡＬＣパケットを出力して、当該技術分野で周知のようにＩＰパケット内でカプセル化する。得られたＩＰパケットは、図１に示したように、１つまたは複数の受信装置へ送信するためにＤＶＢ−Ｈモジュレータ３０に出力される。レシーバは、特定のＦＬＵＴＥチャネル（例えば、ＩＰアドレス及びポート番号）に同調されて、レシーバで用いるためにＥＳＧをリカバリする。
【０００６】
上で述べたように、レシーバは、バッテリの寿命などの電力の制約を有しているかもしれない。更に、放送網内のレシーバは、特定の時間に、特定のまたは選択されたファイルベースのコンテンツを受信しているだけかもしれない。その他の時間に、レシーバは、十分に電力を付与されているものの、放送網によって送信される他のあらゆるコンテンツを処理していない。このように、ＦＬＵＴＥセンダ（例えば、図２のヘッドエンド１０のＦＬＵＴＥセンダ２０）とＦＬＵＴＥレシーバ（例えば、図１のレシーバ９０のＦＬＵＴＥレシーバ部分（図示せず））とが時間同期されていて、選択された情報が受信されていない期間にレシーバが電力を抑えることができてレシーバのバッテリの寿命を延ばすことができたならば有益である。時間同期を実行する１つの方法が図３に示されている。特に、図３では、タイミング同期は、ネットワークタイムプロトコル（ＮＴＰ）サーバ４５を介してヘッドエンド１０とレシーバ９０との間で行なわれる。この場合、（ヘッドエンド１０の）ＦＬＵＴＥセンダ２０は、ＮＴＰサーバ４５からのＮＴＰタイムスタンプを含む日時表（ＴＤＴ）（例えば、上記で参照したＥＴＳＩ ＥＮ ３００ ４６８ Ｖ１．７．１を参照せよ）を提供する。ヘッドエンド１０は、ＤＶＢ−Ｈ信号３６内のＴＤＴをブロードキャストする。次に、レシーバ９０は、特定の時間に、ちょうど受信したＮＴＰ時間スタンプを用いて選択されたコンテンツを探す。あるいは、ヘッドエンド１０は、ライブサービスブロードキャストに含まれるＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）センダレポート内にレシーバ９０に対するＮＴＰタイムスタンプを出力することができる（例えば、非特許文献８を参照する）。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】ＥＴＳＩ ＥＮ ３０２ ３０４ Ｖ１．１．１（２００４−１１）の「デジタルビデオブロードキャスティング規格（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ）；ＤＶＢ−Ｈのための送信システム（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｓｙｓｔｅｍ ｆｏｒ Ｈａｎｄｈｅｌｄ Ｔｅｒｍｉｎａｌ）」
【非特許文献２】ＥＴＳＩ ＥＮ ３００ ４６８ Ｖ１．７．１（２００６−０５）「デジタルビデオブロードキャスティング規格（ＤＶＢ）；ＤＶＢシステムにおけるサービス情報（ＳＩ）のための仕様書」
【非特許文献３】ＥＴＳＩ ＴＳ １０２ ４７２ Ｖ１．１．１（２００６−０６）「デジタルビデオブロードキャスティング規格（ＤＶＢ）；ＤＶＢ−ＨによるＩＰデータ放送：コンテンツ配信プロトコル」
【非特許文献４】ＥＴＳＩ ＴＳ １０２ ４７１ Ｖ１．１．１（２００６−０４）「デジタルビデオブロードキャスティング規格（ＤＶＢ）；ＤＶＢ−ＨによるＩＰデータ放送：電子サービスガイド（ＥＳＧ）」
【非特許文献５】Ｍ．ハンドリ、Ｖ．ヤコブソン、「ＲＦＣ ２３２７−ＳＤＰ：セッション記述プロトコル」１９９８年４月
【非特許文献６】Ｔ．パイラ、Ｍ．ラビィ、Ｖ．ロカ、Ｒ．ウォルシュ、「ＲＦＣ ３９２６−ＦＬＵＴＥ−ＦｉｌｅＤｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ」２００４年１０月
【非特許文献７】ラビィ、Ｍ．ゲメル、Ｊ．ビチザーノ（Vicisano）、Ｌ．リッツォ、及びＬ．Ｊ．クロウクロフト、「ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ）プロトコルのインスタンス化」、ＲＦＣ ３４５０、２００２年１２月
【非特許文献８】オーディオ／ビデオトランスポートワーキンググループ、Ｈ．シュルツリン（ＧＭＤ Ｆｏｋｕｓ）、Ｓ．キャスナ（プリセプトソフトウェア社）、Ｒ．フレデリック（ゼロックス・パロアルト・リサーチセンター）、Ｖ．ヤコブソン、「ＲＦＣ １８８９ ＲＴＰ：リアルタイムアプリケーションのためのトランスポートプロトコル」１９９６年１月
【発明の概要】
【発明が解決しようとする課題】
【０００８】
（例えば、図１に示すような）片方向放送網は、マルチメディアまたはデータコンテンツの拡張可能なブロードキャスティングにとって最上の選択である。放送網は、特にマルチメディアコンテンツの送信及びストリーミングのために広く用いられている。しかし、この種のネットワークは、レシーバのためのポイントツーポイントサービスを行う機能を欠いており、レシーバの好みについてセンダに知らせるためのレシーバ用の何らかの逆チャネルも有していない。
【課題を解決するための手段】
【０００９】
放送網を介して機能するプッシュ型ビデオオンデマンド（ＶＯＤ）サービスを行うために、センダは、レシーバの好みのコンテンツを入手する際にできるだけ多くのレシーバを満足させなければならない。更に、コンテンツプロバイダ及びコンテンツオペレータも、自分たち自身の送信の優先順位を有している。「オペレータ」（サービスプロバイダとも称される）とは、ブロードキャストサービスを画定して、サービスのためのコンテンツを提供するエンティティである。「コンテンツプロバイダ」とは、特定のサービスまたは特定の一組のサービスのためのコンテンツを作るエンティティである。
【００１０】
従ってかつ本発明の原理によれば、サーバは、静的部分及び動的部分を有するプログラムガイドを決定し、該静的部分で示されるコンテンツの送信順序が、前回に決定したプログラムガイドにおける対応するコンテンツの送信順序から決定され、一方、該動的部分で示されるコンテンツの送信順序が、該前回に決定したプログラムガイドにおける対応するコンテンツの送信順序と異なっていてもよい。
【００１１】
本発明の例示的な実施形態において、ヘッドエンドはスケジューラを含み、該スケジューラは、コンテンツファイルについての送信順序を決定しかつ静的部分及び動的部分を有する電子サービスガイドを生成する。該動的部分においてスケジューリングされたコンテンツは、該電子サービスガイドの異なるバージョンにおいて異なる送信順序を有していてもよい。スケジュールタイミング情報及びメタデータ情報は、クリップとともに放送網を介して送信され、レシーバは、好みのクリップを選択的に受信して、バッテリ電源及び記憶装置を節約することができる。
【００１２】
上記を考慮してかつ詳細な説明を読むと明らかになるように、他の実施形態及び特徴も実行可能であり、本発明の原理の範囲に入る。
【図面の簡単な説明】
【００１３】
【図１】従来技術によるＤＶＢ−Ｈ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ）システムによるインターネットプロトコル（ＩＰ）データ放送を示す図である。
【図２】従来技術によるＤＶＢ−Ｈ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ）システムによるインターネットプロトコル（ＩＰ）データ放送を示す図である。
【図３】従来技術によるＤＶＢ−Ｈ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ）システムによるインターネットプロトコル（ＩＰ）データ放送を示す図である。
【図４】図１−３のシステムについてのファイルベースのコンテンツ送信及び付随するＥＳＧフラグメントを示す図である。
【図５】図１−３のシステムについてのファイルベースのコンテンツ送信及び付随するＥＳＧフラグメントを示す図である。
【図６】本発明の原理によるシステムの例示的な実施形態を示す図である。
【図７】本発明の原理による例示的なサーバを示す図である。
【図８】本発明の原理による例示的なスケジューリングメタデータを示す図である。
【図９】本発明の原理によるサーバ１５０で用いるための例示的なフローチャートを示す図である。
【図１０】本発明の原理による例示的なスケジュールを示す図である。
【図１１】本発明の原理によるサーバ１５０で用いるための他の例示的なフローチャートである。
【図１２】本発明の原理によるサーバ１５０で用いるための他の例示的なフローチャートである。
【図１３】本発明の原理による他の例示的なスケジュールを示す図である。
【図１４】本発明の原理によるレシーバの例示的な実施形態を示す図である。
【図１５】本発明の原理によるレシーバの例示的な実施形態を示す図である。
【図１６】本発明の原理によるレシーバで用いる例示的なフローチャートである。
【図１７】本発明の原理による別の例示的なサーバを示す図である。
【発明を実施するための形態】
【００１４】
本発明の概念による特徴を除いて、図に示された要素は、周知であって、詳述されない。例えば、本発明の概念による特徴を除いて、ＤＭＴ（Ｄｉｓｃｒｅｔｅ Ｍｕｌｔｉｔｏｎｅ）送信（直交頻度分割多重方式（ＯＦＤＭ）または符号化直交頻度分割多重方式（ＣＯＦＤＭ）とも称される）について精通していることが前提とされており、本明細書では説明されない。また、テレビ放送、レシーバ、及びビデオ符号化について精通していることが前提とされており、本明細書では詳述されない。例えば、本発明の概念による特徴を除いて、例えばＮＴＳＣ（全米テレビジョン放送方式標準化委員会）、ＰＡＬ（位相反転線、Ｐｈａｓｅ Ａｌｔｅｒｎａｔｉｏｎ Ｌｉｎｅｓ）、ＳＥＣＡＭ（順次式カラーメモリ、Ｓｅｑｕｅｎｔｉａｌ Ｃｏｕｌｅｕｒ Ａｖｅｃ Ｍｅｍｏｉｒｅ）及びＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ）（ＡＴＳＣ）、中国デジタルテレビジョンシステム（ＧＢ）２０６００−２００６などのＴＶ標準、並びにＤＶＢ−Ｈのための現在のレコメンデーション及び提案されているレコメンデーションについて精通していることが前提とされている。同様に、本発明の概念による特徴を除いて、８−ＶＳＢ（ｅｉｇｈｔ−ｌｅｖｅｌ ｖｅｓｔｉｇｉａｌ ｓｉｄｅｂａｎｄ）、直交振幅変調（ＱＡＭ）などの他の送信概念、並びに、例えば無線周波数（ＲＦ）フロントエンド（例えば、低ノイズブロック、チューナ、ダウンコンバータ等）、復調器、相関器、リーク積分器、及び平方器（squarers）などのレシーバ構成要素が前提とされている。更に、本発明の概念による特徴を除いて、例えば、ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）プロトコル、ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ）プロトコル、インターネットプロトコル（ＩＰ）、及びＩＰＥ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｅｎｃａｐｓｕｌａｔｏｒ）などのプロトコルに精通していることが前提とされており、これらは本明細書において説明されていない。同様に、本発明の概念による特徴を除いて、トランスポートビットストリームを生成するためのフォーマット及び符号化方法（例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）−２システム標準（ＩＳＯ／ＩＥＣ １３８１８−１））は周知であって、本明細書において説明されていない。また、プル型ＶＯＤサービス及びプッシュ型ＶＯＤサービスにも精通していることが前提とされている。プル型ＶＯＤサービスでは、ユーザは特定のビデオクリップを要求し、サーバは当該ビデオクリップをその特定のユーザに送信する。プッシュ型ＶＯＤサービスでは、ユーザの好みのビデオが、ユーザがビデオを積極的に要求することなしに、レシーバにプッシュ配信される。本発明の概念は、本明細書において説明していない従来のプログラム技術を用いて実施されてもよいことに注意しなければならない。最後に、図の同じ番号は、同様の要素を表す。
【００１５】
本発明の概念を説明する前に、図４は、従来技術によるＤＶＢ−Ｈのファイルベースのコンテンツ送信を示す。図４において、ＤＶＢ−Ｈのファイルベースのコンテンツ送信は、クリップ５０、５１、５２及び５３で表されるような多数のイベント（本明細書においてクリップとも称される）を含む。各クリップは、多数のパケットを含むことができるが、これは本発明の概念に関係がない。ＥＳＧは、各クリップを開始時刻、終了時刻に付随させ、対応するＦＬＵＴＥセッション内の付随するコンテンツファイルを識別する。このことは、クリップ５１に付随するＥＳＧのフラグメント６０（ＥＳＧフラグメント６０）として図４に示されている。簡単にするために、他のＥＳＧデータは示されていない。図４に示すように、ＥＳＧフラグメント６０は、ＣｏｎｔｅｎｔＬｏｃａｔｉｏｎパラメータ６５、ＰｕｂｌｉｓｈｅｄＳｔａｒｔＴｉｍｅパラメータ６１、及びクリップ５１に付随するＰｕｂｌｉｓｈｅｄＥｎｄＴｉｍｅパラメータ６２を含む。この例では、対応するＦＬＵＴＥセッション内の付随するコンテンツファイルは、「Ｃｌｉｐ１．ｍｐ４」である。ＰｕｂｌｉｓｈｅｄＳｔａｒｔＴｉｍｅ６３の実際の値及びＰｕｂｌｉｓｈｅｄＥｎｄＴｉｍｅ６４の実際の値は、協定世界時（ＵＴＣ）装置に存する。ＰｕｂｌｉｓｈｅｄＳｔａｒｔＴｉｍｅの値は、ＦＬＵＴＥセンダが実際にファイルの送信を開始する時刻である。即ち、クリップがＦＬＵＴＥセンダからシステムチェインにおける次のブロックに渡される時刻である。このことは、ＤＶＢ−Ｈシステムについての図５に更に示されている。即ち、ＰｕｂｌｉｓｈｅｄＳｔａｒｔＴｉｍｅの値は、ＦＬＵＴＥセンダ２０がＩＰカプセル化装置２５にクリップを渡す時刻である。
【００１６】
前に述べたように、放送網を介して機能するプッシュ型ビデオオンデマンド（ＶＯＤ）サービスを行うために、センダは、レシーバの好みのコンテンツを入手する際にできるだけ多くのレシーバを満足させなければならない。更に、コンテンツプロバイダ及びコンテンツオペレータも、自分たち自身の送信の優先順位を有している。「オペレータ」（サービスプロバイダとも称される）とは、ブロードキャストサービスを画定して、サービスのためのコンテンツを提供するエンティティである。「コンテンツプロバイダ」とは、特定のサービスまたは特定の一組のサービスのためのコンテンツを作るエンティティである。
【００１７】
上記を考えると、プッシュ型ＶＯＤサービスにおいて送信用のコンテンツを配給しかつスケジューリングすることに関して、多くの問題が見出される。例えば、コンテンツデータベースは、ある期間にわたって変化するかもしれず、オペレータの好みも、新しいクリップの追加とともに変化するかもしれない。従って、新しいクリップの追加によるオペレータの好みの変化が、あまり好まれないクリップがブロードキャストのためにずっとスケジューリングされるのを無期限に防ぐことになるので、新しいクリップが追加されるときに、クリップの送信についての優先順位ベースのスケジューリングを実行することができない。
【００１８】
更に、スケジュールの予測可能性は、別の重要な要因である。スケジュールは、クリップの追加及び除去によってあらゆる時点でまたは優先順位の変更があっても変化し得る。しかしながら、片方向ネットワーク環境において、レシーバ端末は、その好みのコンテンツをタイムリに受信するためにスケジュールに大きく依存している。スケジュールが予測できない場合、レシーバは常駐しなければならず、このことによって無駄に電力が浪費される。更に、片方向ネットワークにおいて、レシーバは、失われたファイルについてセンダに知らせる手段を備えていない。それゆえに、スケジュールの予測可能性は、レシーバの動作にとって非常に重要である。
【００１９】
また、レシーバにおける好みの設定は、ユーザの個人的な興味、レシーバの場所、受信時間等により異なってくる。例えば、マルチメディアクリップブロードキャストにおいて、視聴者は非常に好ましいクリップを何度も繰り返して入手するよりはむしろ新しいクリップを入手するのを必然的に好むということが報告されている。しかしながら、ブロードキャストプッシュ型ＶＯＤサービスにおいて、好みの設定に直ちに配慮することができる逆チャネルはない。この点で、マルチメディアクリップのための送信スケジュールを更新するときに、あらゆるスケジューリングは、かかる問題に対処しなければならない。
【００２０】
上記を考慮し、本発明の原理に従って、プッシュ型ＶＯＤサービスが上記の問題に対処できるようにするスケジューラが説明されている。従ってかつ本発明の原理により、ヘッドエンドは、動的優先順位の値の関数として、コンテンツファイルについての送信順序を決定する。動的優先順位の値の関数は、少なくともコンテンツファイル同士の間の相違の測定により決定される。ヘッドエンドは、決定された送信順序に従ってコンテンツファイルを送信する。
【００２１】
本発明の例示的な実施形態において、コンテンツファイルは、スポーツビデオ、音楽ビデオ、ニュースクリップ、映画サウンドトラック等のようないずれの種類のオーディオ／ビデオクリップであってもよく、「クリップメタデータ」は各クリップに付随している。ヘッドエンドはスケジューラを含み、該スケジューラは、動的優先順位の値の関数として、コンテンツファイルについての送信順序を決定する。動的優先順位の値の関数は、少なくともコンテンツファイル同士の間の相違の測定により決定される。コンテンツファイルの相違の測定は、各クリップに付随するクリップメタデータの関数として更に決定される。スケジュールタイミング情報及びメタデータ情報は、クリップとともに放送網を介して送信され、レシーバは、好みのクリップの選択的な受信を行って、バッテリ電源及び記憶装置を節約することができる。
【００２２】
ここで、図６を参照すると、本発明の原理による例示的なシステムが示されている。この例のために、図６に示したシステムは、本発明の概念による特徴を除いて、図１で説明したＤＶＢ−ＨシステムによるＩＰデータ放送と類似のＤＶＢ−ＨシステムによるＩＰデータ放送であると考えられる。本発明の原理により、ヘッドエンド１５０は、マルチメディアコンテンツファイルに付随する記述データを解析して該マルチメディアコンテンツファイルについての送信順序を決定する。更に、アンテナ１８５を介して、決定された送信順序に従ってマルチメディアコンテンツファイルを送信する。特に、ヘッドエンド１５０は、ラップトップコンピュータ１００−１、携帯情報端末（ＰＤＡ）１００−２、及び携帯電話１００−３のうちのいずれか１つで表されるような、１つまたは複数の受信装置（本明細書において「クライアント」または「レシーバ」とも称される）にＩＰデータ放送をブロードキャストするためのＤＶＢ−Ｈ信号１８６をブロードキャストする。その各々は、ＤＶＢ−Ｈ信号を受信して、リアルタイムコンテンツ及びファイルベースのコンテンツのためのブロードキャストＩＰデータ放送のＤＶＢ−Ｈ信号のリカバリをすると考えられる。図６のシステムは、片方向ネットワークを表すものである。しかしながら、本発明の概念は、そのようには限定されていない。
【００２３】
本発明の原理によるヘッドエンドまたはサーバ１５０の例示的な実施形態が図７に示されている。本発明の概念による特徴を除いて、図７に示された要素は周知であって、本明細書において説明されていない。ヘッドエンド１５０は、プロセッサベースのシステムであって、図７の破線のボックスの形で示されたプロセッサ１９０及びメモリ１９５で表されるような、１つまたは複数のプロセッサ及び付随するメモリを含む。この内容では、コンピュータプログラムまたはソフトウェアが、プロセッサ１９０による実行のためにメモリ１９５に格納されていて、例えばスケジューラ２４０を実行する。プロセッサ１９０は、１つまたは複数の蓄積プログラム制御プロセッサを表すものであり、これらは、スケジューリング機能専用に設けられなくてもよい。例えば、プロセッサ１９０がヘッドエンド１５０の他の機能も制御することができる。メモリ１９５は、例えば、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）等のあらゆる記憶装置を表すものである。メモリ１９５は、ヘッドエンド１５０に内臓されていてもよいしかつ／または外付けであってもよい。更に、メモリ１９５は、必要に応じて揮発性及び／または不揮発性である。
【００２４】
ヘッドエンド１５０は、ＥＳＧジェネレータ２１５、ＦＬＵＴＥセンダ２２０、ＩＰカプセル化装置２２５、ＤＶＢ−Ｈモジュレータ２３０、コンテンツデータベース２３５及びスケジューラ２４０を含む。ＥＳＧジェネレータ２１５、ＦＬＵＴＥセンダ２２０、ＩＰカプセル化装置２２５、及びＤＶＢ−Ｈモジュレータ２３０は、図２に示された対応する構成要素と同様であり、本明細書において、これ以上説明されない。本発明の概念による特徴を除いて、以下に説明されるＥＳＧジェネレータ２１５は、ＦＬＵＴＥセンダ２２０にＥＳＧを出力する。ＦＬＵＴＥセンダ２２０は、ＡＬＣを介してＦＬＵＴＥによりＥＳＧをフォーマットし、当該技術分野で周知であるように、ＩＰパケットにおけるカプセル化のためにＩＰカプセル化装置２２５へＦＬＵＴＥファイルを運ぶ得られるＡＬＣパケットを出力する。得られたＩＰパケットは、図６に示したように、１つまたは複数の受信装置に対する送信のためにＤＶＢ−Ｈモジュレータ２３０に出力される。レシーバ（例えば図６のレシーバ１００−２）は、特定のＦＬＵＴＥチャネル（例えばＩＰアドレス及びポート番号）に同調させて、レシーバにおける使用のためにＥＳＧをリカバリする。
【００２５】
図７に示さすように、ヘッドエンド１５０はまた、コンテンツデータベース２３５及びスケジューラ２４０を含む。コンテンツデータベース２３５は、コンテンツ、即ちマルチメディアコンテンツファイルを格納する。これらのマルチメディアコンテンツファイルは、スポーツビデオ、音楽ビデオ、ニュースクリップ、映画サウンドトラック等のようなあらゆる種類のオーディオ／ビデオクリップである。本発明の概念による特徴を除いて、これらのクリップは、信号２３８を介して、ＦＬＵＴＥセンダ２２０に出力され、図４に関して先に述べたようにＤＶＢ−Ｈにおいてファイルベースのコンテンツ送信として送信される。コンテンツメタデータは、各クリップに付随する。各クリップについてのコンテンツメタデータは、ＥＳＧジェネレータ２１５に出力され、本発明の原理により、信号２３６を介してスケジューラ２４０に出力される。スケジューラ２４０は、信号２３９を介して、コンテンツデータベース２３５を制御しかつモニタする。その結果、スケジューラ２４０は、例えば、クリップのコンテンツメタデータを変更することによる追加／削除または変更などの、コンテンツデータベース２３５に対する変更を検出する。
【００２６】
本発明の原理により、スケジューラ２４０は、コンテンツデータベース２３５に格納されたクリップに付随するコンテンツメタデータを解析して、マルチメディアコンテンツファイルについての送信順序を決定する。この点で、スケジューラ２４０は、制御信号２４２を介して、ＦＬＵＴＥセンダ２２０に対する送信順序を制御する。更に、スケジューラ２４０は、信号２４１を介して、レシーバに送信されるＥＳＧを生成する際に用いる追加のスケジューリング情報をＥＳＧジェネレータ２１５に出力する。この追加のスケジューリング情報は、本明細書において「スケジューリングメタデータ」と称される。特に、各クリップに付随するコンテンツメタデータに加えて、スケジューラ２４０は、図８に示すようなスケジューリングメタデータを追加する。スケジューリングメタデータ２００は、多数のフィールドを含む。即ち、動的優先順位２０１、送信数２０２、待ち時間２０３、及び、任意でキーワード２０４（点線の形で示されている）である。よって、各クリップについて、コンテンツメタデータ２１０に加えてスケジューリングメタデータ２００がある。これは、図８に示したようにクリップメタデータ全体２２０と本明細書において称される。コンテンツメタデータ２１０は、コンテンツデータベース２３５に格納される。コンテンツメタデータ２１０は、コンテンツＩＤ２１１、優先順位２１２、説明２１３、及び任意でキーワード２１４（点線形式で示された）を含む。例示として、ＸＭＬ（拡張マークアップ言語）が、メタデータを表すために用いられてもよい。
【００２７】
メタデータ２１０に関して、コンテンツＩＤ２１１は、コンテンツデータベース２３５の各クリップを識別するために一意の数で示される識別子である。優先順位２１２は、識別されたクリップについて優先レベルを表す数値である。説明２１３は、例えば、テレビ番組の名前、概要、俳優、ディレクタ、及びブロードキャストについての予定時刻、予定日、放送時間及びチャネルである。最後に、キーワード２１４は、識別されたクリップのコンテンツを簡単に説明している１つまたは複数のキーワードを表す文字数字の単語のリストである。
【００２８】
スケジューリングメタデータ２００に関して、動的優先順位２０１は、識別されたクリップをブロードキャストするかまたは送信するための実際の優先レベルを表す数値である。送信数２０２は、識別されたクリップがブロードキャストまたは送信された回数を表す数値である。待ち時間２０３は、識別されたクリップが最後にブロードキャストされた時から経過した秒数を表す数値である。最後に、キーワード２０４は、識別されたクリップのコンテンツを簡単に説明している１つまたは複数のキーワードを表す文字数字の単語のリストである。上記のように、キーワードは、スケジューリングメタデータ２００またはコンテンツメタデータ２１０のいずれかにあってもよい。スケジューリングメタデータ２００において、キーワード２０４は、説明２１３を解析しているスケジューラ２４０によって決定される。コンテンツメタデータ２１０において、キーワード２１４は、コンテンツメタデータ２１０の一部として、オペレータにより設定される。
【００２９】
ここで、図９のフローチャートに注意を向けなければならない。該フローチャートは、本発明の原理による例示的なスケジューリング方法を示す。ステップ３０５において、スケジューラ２４０は、スケジューリング頻度ｆｓ（３１６）及び、スケジュールの静的部分（後述される）を初期化しかつ決定する。スケジューリング頻度ｆｓ（３１６）は、スケジュールの静的部分であるように、演繹的に例示的に決定される。例えば、これらは、図７のメモリ１９５に格納される値である。これらの値は、また、（例えば、キーボード／コンソール（図示せず）を介して）信号２４３を介してオペレータにより設定されてもよい。スケジューリング頻度ｆｓ（３１６）は、スケジュールがどれくらいの頻度で生成されるかを決定する。ステップ３１０において、スケジューラ２４０は、コンテンツデータベース２３５に格納されたクリップについてのコンテンツメタデータを取り出す。
【００３０】
ステップ３１５において、スケジューラ２４０は、スケジュールを生成する時刻か否かをチェックする。それはスケジューリング頻度ｆｓ（３１６）により決定される。スケジュールを生成する時刻でない場合、ステップ３２５において、スケジューラ２４０は、（例えば、図７の信号２３９を介して）コンテンツデータベース２３５が更新されたかどうかをチェックする。コンテンツデータベース２３５が更新されていない場合、スケジューラ２４０は、ステップ３１５において、スケジュールを生成する時刻か否かを再びチェックする。しかしながら、コンテンツデータベース２３５が更新された場合、ステップ３１０において、スケジューラ２４０は、更新されたコンテンツを取り出す。この更新されたコンテンツは、変更されたコンテンツ、新しいコンテンツ、または削除されたコンテンツを表す。この点で、スケジューラ２４０は、必要に応じて、取り出されたコンテンツメタデータを生成、更新、または削除するために、ステップ３１０において必要な処理を行う。
【００３１】
ステップ３１５において、一旦スケジューラ２４０が、スケジュールを生成する時刻であると判断すると、ステップ３２０に実行を進める。そこで、スケジューラ２４０は、識別されたクリップ各々についてのスケジューリングメタデータ２００の値を決定するかまたは更新し、スケジュールを生成する。最初に、必要に応じて、スケジューラ２４０は、説明２１３を解析して、スケジューリングメタデータ２００のキーワード２０４フィールド用のキーワードを決定する。あるいは、スケジューラ２４０は、もしあればキーワード２１４を使用する。次に、スケジューラ２４０は、識別されたクリップ（コンテンツＩＤ２１１）についての実際の優先順位を表す値を決定して、この値を動的優先順位２０１（以下に詳述される）に格納する。スケジューラ２４０はまた、送信数２０２の値を更新して、識別されたクリップが送信された回数を表す。更に、識別されたクリップが最後にブロードキャストされたときから経過した秒数を表している待ち時間２０３の値を更新する。一旦識別されたクリップ各々についてのスケジューリングメタデータが決定されると、スケジューラ２４０は、（信号２４１を介して）ＥＳＧジェネレータ２１５及び（信号２４２を介して）ＦＬＵＴＥセンダ２２０が使用するためのスケジュールを生成する。ステップ３２５に実行は続く。簡単にするために、他の端末及び／またはエラー状態は、本明細書で説明されているフローチャートにおいて示されていないことにも注意しなければならない。
【００３２】
レシーバ側及びセンダ側の両方の不必要な実施の複雑さを避けるために、スケジューラ２４０は、ノンプリエンプティブなスケジューラとして例示的に設計されている。これは、各ビデオクリップまたは他のあらゆるコンテンツファイルを小なる部分に分割せず、異なるタイムスロットに及んで送信されないということを意味する。言い換えると、一旦コンテンツ送信が開始されると、該送信は、別のクリップを送信するためにスケジューラ２４０に最後まで割り込まれない。このことは、端末における受信完了までの所要時間を最小限にするのに役立つ。しかしながら、本発明の概念は、それに限定されておらず、プリエンプティブスケジューラにも適用できる。
【００３３】
上で述べたように、スケジューラ２４０はスケジュールを生成する。本発明の原理により、例示的なスケジュール４００が、図１０に示される。スケジュール４００は、静的部分４０１及び動的部分４１０を含む。静的部分４０１は、Ｊ個のクリップを含む。即ち、Ａ（４０１−１）、Ｃ（４０１−２）、・・・Ｆ(４０１−Ｊ)であり、ここでＪ≧０である。動的部分４１０は、Ｋ個のクリップを含む。即ち、Ｄ（４１０−１）・・・Ｅ（４１０−Ｋ）であり、ここでＫ≧０である。スケジュールの継続時間は、終了時刻から開始時刻を引いたものである（即ち、ｔE−ｔS）。図１０から分かるように、静的部分４０１は、開始時刻ｔSで始まり、時刻ｔDで終わる。時刻ｔDは、動的部分４１０の開始時刻である。動的部分４１０は、スケジュール終了時刻ｔEで終わる。図１０から分かるように、各クリップは、付随する継続時間を有する。例えば、クリップＣ（４０１−２）は、Ｄｃという付随する継続時間を有する。図１０は、静的部分及び動的部分を示すが、いずれかの部分のクリップの数がゼロであってもよい、即ち、ｔSはｔDに等しくてもよいことに注意しなければならない。
【００３４】
ここで図１１を参照すると、図９のステップ３２０において用いられる例示的なフローチャートが示されている。新しいスケジュールを生成する時刻である場合、スケジュール時刻ｔが初期化される。例えば、図１１のステップ３５０において、ｔＳ＝０である。ステップ３５５において、スケジューラ２４０は、前回のスケジュールが存在するかどうか調べる。前回のスケジュールが存在する場合、ステップ３６０において、スケジューラ２４０は前回のスケジュールをロードし、前回のスケジュールの動的部分の開始時刻に等しいｔをセットする。例えば、図１０のスケジュール４００についてｔ＝ｔDである。いずれの場合も、ステップ３６５において、スケジューラ２４０は、このスケジューリングセッション（下記に詳述される）のために取り出された各クリップまたはコンテンツの動的優先順位（Ｄｐ（ｔ））を決定する。ステップ３７０において、最も高い動的優先順位Ｄｐ（ｔ）を有するクリップ（ｉ）が、スケジュール時刻ｔで始まる新しいスケジュールに配される。このクリップ（ｉ）は、Ｄｉという付随する継続時間を有する。ステップ３７５において、スケジュール時刻ｔは、ｔ＝ｔ＋Ｄｉへ進む。ステップ３８０において、スケジュール時刻ｔは、スケジュール終了時刻ｔEと照合される。スケジュールの終了時刻に至っている場合、ステップ３８５において、スケジューラ２４０は新しいスケジュールに戻るかまたは新しいスケジュールを生成する。しかしながら、スケジュールの終了時刻に至っていない場合、スケジューラ２４０は、ステップ３６５において残りのクリップについての動的優先順位（Ｄｐ（ｔ））を再計算して、最も高い動的優先順位（Ｄｐ（ｔ））を備えたクリップを再び選択する。この処理は、スケジューラ２４０が全部のスケジュールを埋めるまで、繰り返される。フローチャートに示すように、前回のスケジュールがシステム内に存在する場合、開始時刻「t」は、動的優先順位の計算を行う前に調整される。この場合、前回のスケジュールの静的部分のイベントは、そのまま新しいスケジュールにコピーされる。これは、レシーバ（後述される）において、スケジュールをより予測可能にするために行われる。
【００３５】
特定の時間インスタントｔにスケジューリングされたクリップがそのインスタントにおけるクリップの動的優先順位により決定されるということが、図１１のフローチャートから分かる。図１１のステップ３６５の例示的な実施形態が、図１２に示される。ステップ４５０において、スケジューラ２４０は、現在のスケジュール時刻ｔ及び現在の継続時間Ｄｉをロードする。前回のスケジュールが存在せず、クリップがこのスケジューリングセッションにおいて現在のスケジューリングされていなければ、現在の継続時間Ｄiはゼロに等しい。前回のスケジュールが存在するが、クリップがこのスケジューリングセッションにおいて現在スケジューリングされていなければ、Ｄiは、動的部分の開始時刻ｔDと静的部分の開始時刻との間の差に等しい。一方、Ｄiは、スケジューリングされた最後のクリップの継続時間に等しい。ステップ４５５において、スケジューラ４５５は全てのクリップの送信数（例えば、図８の送信数２０２）を更新して、同様に全てのクリップの最後のブロードキャスト時間を更新する。ステップ４６０において、スケジューラ２４０は、現在の継続時間Ｄiの値をチェックする。現在の継続時間Ｄiの値がゼロに等しい場合、ステップ４７０において、各クリップについての待ち時間Ｗｔ（図８に示された待ち時間２０３としても示されている）が、
Ｗｔ＝クリップ（ｉ）の最終ブロードキャスト時刻−ｔ （１）
で計算される。それは、単に、そのクリップについての現在の時刻と最終のブロードキャスト時間との間の差である。しかしながら、現在の継続時間Ｄiの値がゼロに等しくない場合、ステップ４６５において、この継続時間は、各クリップについての待ち時間Ｗｔ（図８に示された待ち時間２０３としても示されている）に加えられて、
Ｗｔ＝Ｗｔ＋Ｄi （２）
で算出される。ここで、Ｄiは、前回にスケジューリングされたクリップの継続時間（またはスケジュールの静的部分の時間の継続時間）を表す。
【００３６】
ステップ４７５において、スケジューラ２４０は送信のためにまだスケジューリングされていないクリップの相違点を決定する。この点で、ブロードキャストを介したプッシュ型ＶＯＤのアプリケーションを実現する際に、フィードバックチャネルが不足していることに注意しなければならない。エンドユーザが自分たちの好みをセンダに知らせるための逆チャネルはない。プッシュ型ＶＯＤのアプリケーションにおいて、通常、その優先順位が互いに異なる様々なユーザ（レシーバ）がいる。この特定の問題に配慮しないスケジューラは、プッシュ型ＶＯＤのアプリケーションにとって理想的でない。例えば、熱狂的サッカーファンは、自分がサッカーのワールドカップハイライトを入手するためにニュース及び音楽ビデオの次の１０クリップの送信が終わるまで待たなければならないならば、プッシュ型ＶＯＤアプリケーションの類へ決して行かない。
【００３７】
様々な視聴者の好みの可能性を考慮するために、かつ本発明の原理により、図１２のステップ４７５において、スケジューラ２４０は、前回にスケジューリングされたクリップと比較してスケジュール用に利用可能なクリップの各々の相違について重み付けを与える。例えば、時刻ｔにおいて最も異なるクリップは、他のクリップより大きい異なる重み付け値を有する。次に、この異なる重み付け値は、クリップの動的優先順位を決定する際に引き続き用いられ、その結果（後述されるように、他の要因を考慮しない）、連続した送信のために類似のクリップの列を作る代わりに、異なるクリップが、互いに隣接して送信されるようにスケジューリングされる。スケジューリングされていないクリップはスケジューリングされたクリップと比較してどれだけ類似しているかを見出すために、スケジューラは、各クリップに付随するキーワードのデータ（図８のキーワード２０４）を例示的に使用する。上で述べたように、コンテンツプロバイダは、このキーワードデータを提供することができかつ／または、オペレータもコンテンツをよりよく分類するために追加のキーワードを指定することもできる。あるいは、上でも述べたように、スケジューラ２４０は、図８の説明２１３を解析して、説明２１３自体でキーワードを形成してキーワード２０４に格納することができる。特定のクリップについてのキーワード２０４またはキーワード２１４におけるキーワードの全リストは、類似性の測定を行うために他のクリップのそれぞれのキーワードと対照される。２組のキーワードの間で相関の割合を計算するいくつかの方法がある。例えば２つのベクトルのドット積をとることによって、２組のキーワードの間の相関が見つけられる。
【００３８】
例示的に、ステップ４７５において、スケジューラは、例えば、クリップＸで示されたスケジューリングされていないクリップ及びクリップＹで示された最後にスケジューリングされたクリップである、２つのクリップの間で以下の類似性の測定を行なう。
【００３９】
【数１】
【００４０】
ここで、Ｓ（ｘ，ｙ）は、クリップＸとクリップＹとの間の類似性の測定である。Ｎｓは、クリップＸ及びクリップＹの両方における類似のキーワードの総数である。Ｎ（ｘ）は、クリップＸのキーワードの総数であり、Ｎ（ｙ）は、クリップＹにおけるキーワードの総数である。方程式（３）において、Ｓ（ｘ，ｙ）の値は、０と１との間で変化し得る。１の値は完全に類似するクリップを表し、０の値は完全に異なるクリップを表す。それゆえに、相違の測定は、
Ｄｓ（ｘ，ｙ）＝１−Ｓ（ｘ，ｙ） （４）
になる。
【００４１】
次に、スケジューリングされていないクリップ各々の相違の測定Ｄｓ（ｘ，ｙ）が、クリップについての動的優先順位を決定する際にスケジューラ２４０によって用いられる。このプロセスにおいて、キーワードを特定したオペレータ／コンテンツプロバイダは、キーワードは、概要フィールド／要約フィールドを解析することによってスケジューラにより生成されるキーワードより大きく重み付けされる。
【００４２】
相違の測定は、前回のものと比較された場合に最も異なるクリップを識別するために行われるだけでなく、送信についての前回の履歴と比較された場合に最も異なるクリップを見出すために延長されてもよいことに注意しなければならない。これは、異なる測定を過去の相違の移動平均とすることによって実現される。このように、方程式（３）及び方程式（４）に加えて、スケジューラ２４０は、更に相違の測定を精緻化することもできる。特に、継続時間Δｔを有するクリップＸが時刻「ｔ−Δｔ」においてスケジューリングされると仮定する。次に、時刻「ｔ」における各クリップのＤｓを、同様に、
Ｄｓ（ｔ）＝（１−α）＊Ｄｓ（ｘ，ｉ）＋α＊Ｄｓ（ｔ−Δｔ） （５）
で計算することができる。ここで、Ｄｓ（ｘ，ｉ）は、（方程式（３）及び方程式（４）から）クリップＸに対するクリップ（ｉ）の相違であり、Ｄｓ（ｔ−Δｔ）は、時刻ｔ−Δｔにおいて、即ち、前回のスケジュール間隔で、とられたクリップ（ｉ）の相違値である。αは、その値が０と１との間の範囲にある定数である。αの値は、より大きい重み付けが、前回の履歴についてより最近スケジューリングされたクリップに対する相違に与えられるといった方法で選択される。
【００４３】
スケジューリングされていないクリップ各々のための相違値を決定した後に、ステップ４８０において、スケジューラ２４０は、全てのスケジューリングされていないクリップについて動的優先順位を決定する。例示として、時刻「t」における各クリップの動的優先順位は、
Ｄｐ（ｔ）＝ＫｐＰ＋ＫｄＤｓ（ｔ）＋ＫｗＷｔ−ＫｓＳｃ （６）
で与えられる。ここでＤｐ（ｔ）は、時刻ｔにおけるクリップの動的優先順位である。Ｐはクリップの優先順位（例えば図８の優先順位２１２）を与えられるオペレータ／コンテンツプロバイダである。Ｄｓ（ｔ）は、時刻ｔにおけるクリップについての上記の相違の測定である（あるいは、Ｄｓ（ｘ，ｙ）がＤｓ（ｔ）の代わりに用いられてもよい）。Ｗｔは、時刻ｔにおけるクリップの待ち時間である。Ｓｃは、クリップの送信数である。Ｋｐ、Ｋｄ、Ｋｗ、及びＫｓは、それぞれ、オペレータの優先順位、相違、経時、及び送信数についての関連する重み付けを決定する定数である。これらの定数を演繹的に設定することができると共に、これらの定数はまた、最適のスケジュールを得るために手作業で調整することができるかまたは視聴者から任意に集計フィードバックを利用することによってスケジューラにおいて調整することができる。集計フィードバックは、異なるインスタンスにおいてとられた視聴者からの一群のオフラインのフィードバックである。集計フィードバックは、ウェブポータルベースのもしくはＳＭＳ（ショートメッセージサービス）ベースのゲートウェイまたは他の類似の通信チャネルのいずれかを介して実現することできる。
【００４４】
動的優先順位が方程式（６）の内容において説明されたが、変数Ｐ、Ｄｓ（ｔ）、Ｗｔ及びＳｃのうちのいずれか１つ、２つ、または３つを、動的優先順位を決定するために用いることができるということに注意しなければならない。実際、追加のパラメータも、本発明の原理に従って動的優先順位を決定するためにこれらの４つに加えて定義することができる。
【００４５】
上で述べたように、例示として、送信数Ｓｃは、スケジューリングプロセスにおいて、クリップが送信された回数を考慮するために用いられる。例えば、ビデオクリップブロードキャストシステムにおいて、視聴者は常に、新しいクリップを探す。通常、視聴者は、古いクリップよりもむしろ新しいクリップを選択する。古いクリップがオペレータまたはコンテンツプロバイダによって高く評価されていたとしても時々この場合がある。それゆえに、スケジューラは、クリップが送信された回数を考慮して、それによってクリップをスケジューリングしなければならない。スケジューラは、Ｓｃを用いてこの問題を解決して、特定のクリップが送信された回数を計数する。全ての新しいクリップは、ゼロである送信数Ｓｃの値を有する。クリップの動的優先順位を決定する際に、スケジューラは送信数に正比例して優先順位を低くする。言い換えると、送信数が少なくなるほど、動的優先順位における順序が高くなる。
【００４６】
この点で、スケジューラは、古いクリップより高い優先順位のコンテンツを優先し、古いクリップより新しく追加されたクリップに配慮するので、新しいクリップを頻繁に追加することによって、低い優先順位のクリップを過去に送信されたことなしにデータベースにおいていつまでも保持する可能性がある。このことを補うために、方程式（６）のパラメータＷｔを介して、スケジューラはクリップの経時（aging）を説明する。このように、クリップの動的優先順位は、待ち時間が長くなるにつれて高くなる。
【００４７】
クリップについてオペレータ／コンテンツプロバイダの優先順位Ｐを上げることは、動的優先順位を直接上げることにつながることが方程式（６）からも分かる。それゆえに、オペレータ／コンテンツプロバイダの好みのクリップは、早期にスケジューリングされる可能性が高い。
【００４８】
ステップ４８５において、スケジューラ２４０は、送信のために時刻ｔにおいて最も高いかまたは最大の動的優先順位Ｄｐ（ｔ）を有するクリップを選択し、スケジュール内にこのクリップを配する。多数のクリップが同等の動的優先順位を有する場合、スケジューラ２４０は、クリップのうちの１つを選択することができるかまたは同等の動的優先順位のクリップの間でラウンドロビンスケジュールを実行することができることに注意しなければならない。例えば、一組のクリップの全ての優先順位の測定が同じ値を生じる場合、スケジューラは単に該一組のクリップを繰り返してスケジュールをつくり、それらの全てが送信されたということを確かめる。
【００４９】
ステップ４９０において、選択されたクリップは、その待ち時間をゼロに設定し（例えば、図８の待ち時間２０３）、Ｄｉは選択されたクリップの継続時間に等しく設定され、スケジューリングプロセスの次の繰り返しにおいて、（上述されたように）このＤｉの値がステップ４５０で用いられる。
【００５０】
上で述べたように、スケジュールの予測性は重要である。片方向ブロードキャスト環境において、レシーバは、コンテンツの選択的な受信を行えるようになるスケジュール及びメタデータ情報に大いに依存する。それで、レシーバが前もってスケジュールを受信しなければならないことは非常に重要である。更に、いずれかのスケジュールの変更が新しいコンテンツの追加によりまたは他の理由のためにサーバに生じる場合、最新のスケジュールは、全てのレシーバに送信される必要がある。スケジューラは、例えばＴ＝１／ｆｓごとにといった、周期的なスケジュール更新を送信することによってこれを行う。ｆｓは前に述べたスケジューリング頻度である。例えば、周期的なスケジュール更新は、新しくスケジューリングされたイベント及びスケジューリングされたコンテンツに付随する他のメタデータ等を含む。この情報を用いて、レシーバは、レシーバがコンテンツを受信する必要があるかどうか、かついつ同調させてコンテンツを得る必要があるかを決めることができる。よって、端末は電力及び記憶空間を節約することができる。
【００５１】
しかしながら、実際のシステムにおいて、スケジュールの更新及び端末でのスケジュール更新の即時の受信についての頻度は限定される。言い換えると、一旦スケジュール変更がサーバに生じると、レシーバが該スケジュール変更について知るのにある程度時間がかかる。この遅延を端末での最短スケジュール更新間隔とみなす。この最短スケジュール更新間隔及びそのため予測が不可能であることを説明するためにかつ本発明の原理に従って、スケジューラは別の概念、即ち、図１０において示したようにスケジュールを静的部分及び動的部分に分けることを取り入れる。
【００５２】
これは、図１３において更に示されている。この図は、連続する時間間隔を通してスケジューラ２４０による３つのＥＳＧ７０１、７０２、及び７０３の構成を示している。簡単にするために、ＥＳＧは１分ごとに形成されており、以前のスケジュールはなかったと仮定する。スケジューラ２４０によって、０分に形成された、第１のＥＳＧは、ＥＳＧ７０１である。ＥＳＧ７０１を形成する際に、スケジューラ２４０は、クリップＡ、Ｂ、Ｃ、Ｄ及びＥが送信に利用可能であることを決定して、図９、１１及び１２の上記のスケジューリングプロセスに従って図１３に示したように送信のためのそれらをスケジューリングする。図１３から分かるように、ＥＳＧ７０１において、クリップＡ、Ｂ、Ｄ及びＥの各々は１分の継続時間を有し、一方、クリップＣは２分の継続時間を有する。更に、静的部分４０１が２分の継続時間を有すると演繹的に画定され、ＥＳＧ４０１の残りの部分は、ＥＳＧの動的部分４１０として設計されていると考えられる。
【００５３】
次のスケジューリング間隔で、スケジューラ２４０は、クリップＢ、Ｃ、Ｄ、Ｅ及びＦは、送信に利用可能であると判断する（クリップＡは送信された）。更に、スケジューラ２４０は、前回のスケジュール（ＥＳＧ７０１）が存在したと判断して、静的部分４０１を決定する。先に述べたように、スケジューラ２４０は、ノンプリエンプティブなスケジューラとして例示的に設計されている。このことは、各ビデオクリップまたは他のいずれかのコンテンツファイルが小なる部分に分けられず、異なるタイムスロットに分散して送信されないことを意味する。よって、静的部分４０１は、２分の継続時間（クリップＣの中間部にあたる）を有すると画定されるが、静的部分４０１は、クリップＣ全体を含むように一時的に延長される。言い換えると、静的部分は、２分の最短の継続時間を有する。結果として、クリップＢ及びＣは、ＥＳＧ７０１において前回に決定されたように送信のためにスケジューリングされる。しかしながら、図１３から分かるように、動的部分４１０のクリップＤ、Ｅ及びＦの送信の動的優先順位を再計算する際に、クリップＦは、ここでクリップＤ及びＥより前に送信のためにスケジューリングされる。よって、例えばクリップＤは、ここで、ＥＳＧ７０１においてクリップＤが有した送信順序または優先順位以外の、異なる送信順序または優先順位をＥＳＧ７０２において有する。
【００５４】
最後に、次のスケジューリング間隔において、スケジューラ２４０は、クリップＣ、Ｄ、Ｅ、Ｆ及びＧが送信に利用可能であると判断する（クリップＢは送信された）。更に、スケジューラ２４０は、前回のスケジュール（ＥＳＧ７０２）が存在したと判断して、静的部分４０１を決定する。しかしながら、静的部分４０１はクリップＣを含むだけなので、ここで静的部分４０１は２分に戻される。よって、クリップＣは、ＥＳＧ７０２において前回に決定された様に、送信するようにスケジューリングされる。しかしながら、図１３から分かるように、動的部分４１０において、クリップＤ、Ｅ、Ｆ及びＧの送信の動的優先順位を再計算する際に、動的部分４１０において、クリップＧは、ここで、クリップＦ、Ｄ及びＥより先に送信するようにスケジューリングされる。よって、例えばクリップＦはここで、ＥＳＧ７０２においてクリップＦが有した送信順序または優先順位以外の異なる送信順序または優先順位、ＥＳＧ７０３を有する。
【００５５】
上記を考慮して、時間のあらゆる時点でスケジューラによって生成されるスケジュールは２つの部分を有する。現在のスケジュールの静的部分は、対応する時点において前回のスケジュールにあったイベントを有する。スケジュールの静的部分はまた、スケジュールが移動するにつれて、時間ライン上で前に進む。言い換えると、３０秒の静的継続時間がある場合、時間インスタンスｔにおいて作られたスケジュールは時間ｔから時間ｔ＋３０までの静的部分を有し、ｔ＋１秒につくられたスケジュールは、ｔ＋１からｔ＋３１の静的部分を有する。
【００５６】
再スケジュールが生じるときはいつも、新しい再スケジュール変更は、ｔ＋静的持続時間から始まるスケジュールの動的部分に進む。ここで、ｔは再スケジュールの時間インスタンスである。新しいスケジュールの静的部分は、前回のスケジュールから、ｔからｔ＋静的な継続時間の期間に対応するイベントを取り入れることによって作られる。固定された継続時間を静的部分（例えば３０秒）について構成することができたとしても、正確な静的部分は、図１３のＥＳＧ７０１、７０２及び７０３に関して、上記に示したように、静的部分におけるクリップの継続時間により変化し得る。
【００５７】
スケジュールの静的継続時間を、ある期間にわたって調整することができる。静的継続時間は、端末が必要とする最短スケジュール更新間隔に等しいことが理想的である。再スケジューリング間隔は、また、必要な場合、調整されて、新しいスケジュールを処理及び送信する際にあらゆるオーバヘッドを収容することができる。よって、あらゆるスケジュール変更は端末に送信され、一方、端末は、不変である静的部分に依存することができる。
【００５８】
ここで、図１４を参照すると、本発明の原理によるレシーバ１００の例示的な実施形態が示されている。レシーバ１００の本発明の概念に関係する部分だけが示されている。レシーバ１００は、例えばＰＣ、携帯情報端末（ＰＤＡ）、携帯電話、モバイルデジタルテレビ（ＤＴＶ）等のあらゆるプロセッサベースのプラットフォームを表すものである。この点で、レシーバ１００は、図１４の破線のボックスの形で示されているプロセッサ８９０及びメモリ８９５で表されるような、１つまたは複数のプロセッサ及び付随するメモリを含む。この内容において、コンピュータプログラム、またはソフトウェアは、プロセッサ８９０による実行のためにメモリ８９５に格納される。後者は１つまたは複数の蓄積プログラム制御プロセッサを表すものであり、これらは、レシーバ機能専用に設けられる必要はない。例えば、プロセッサ８９０が、レシーバ１００の他の機能を制御することもできる。メモリ８９５は、ランダムアクセスメモリ(ＲＡＭ)、リードオンリメモリ(ＲＯＭ)等のあらゆる記憶装置を表現するものであり、レシーバ１００に内臓であってもよいしかつ／または外付けであってもよい。更に、必要に応じて揮発性及び／または不揮発性である。レシーバ１００は、ＤＶＢ−Ｈレシーバ８１０、ＩＰ非カプセル化装置８１５及びＦＬＵＴＥレシーバ８２０を含む。これらの構成要素のいずれかまたは全ては、プロセッサ８９０及びメモリ８９５で表示されるように、ソフトウェアで実行されてもよい。ＤＶＢ−Ｈレシーバ８１０は、アンテナ８０５を介して（図６の）ＤＶＢ−Ｈ信号１８６を受信し、ＩＰ非カプセル化装置８１５に復調信号を出力する。後者は、ＦＬＵＴＥレシーバ８２０にＡＬＣパケットを出力し、ＦＬＵＴＥレシーバ８２０は、信号８２１で表示されるようにコンテンツをリカバリする。このコンテンツは、（楕円８３０で表示されるように）当該技術分野で周知のようにレシーバ１００で更に処理されてもよい。上記のようにかつ本発明の原理に従って、プロセッサ８９０は、選択されたクリップ（コンテンツ）を識別する際に用いるために静的部分及び動的部分を有するＥＳＧをリカバリする。この例では、ＦＬＵＴＥレシーバ８２０及びＤＶＢ−Ｈレシーバ８１０は、制御信号８０９及び８１９で表示されるようにプロセッサ８９０によって電源をオン／オフされ、少なくとも選択されていないコンテンツレシーバ１００の一部は減少した電力で動作する。このように、プロセッサ８９０は、少なくともＥＳＧの動的部分に対応して、受信したプログラムガイドで表される選択されたコンテンツの受信をスケジューリングする。
【００５９】
本発明の原理によるレシーバ９００の別の例示的な実施形態が、図１５に示されている。レシーバ９００の本発明の概念に関する部分だけが示されている。レシーバ９００は、ＤＶＢ−Ｈレシーバ９１０、変調器／復号器９１５、トランスポートプロセッサ９２０、コントローラ９５０及びメモリ９６０を含む。例えば、アナログ・デジタル変換器、フロントエンドフィルタ等のレシーバの他の構成要素は、簡単にするために示されていないことに注意しなければならない。トランスポートプロセッサ９２０及びコントローラ９５０の両方は、１つまたは複数のマイクロプロセッサ及び／またはデジタル信号プロセッサ（ＤＰＳ）を表すものであり、プログラムを実行しかつデータを格納するためのメモリを含むことができる。この点で、メモリ９６０は、レシーバ９００のメモリを表示するものであり、例えば、トランスポートプロセッサ９２０及び／またはコントローラ９５０のあらゆるメモリも含む。例示的な双方向性のデータ及び制御バス９０１は、示されるようにレシーバ９００の要素のうちの様々な要素を結合する。バス９０１は、例えば、（並列及び／または直列の形式で）個々の信号が、例えば、レシーバ９００の要素同士の間でデータ及び制御信号を運ぶために用いられてもよいといったことを単に表すものである。ＤＶＢ−Ｈレシーバ９１０は、ＤＶＢ−Ｈ信号９０９を受信して、復調器／復号器９１５にダウンコンバートしたＤＶＢ−Ｈ信号９１１を出力する。復調器／復号器９１５は信号９１１の復調及び復号を行って、トランスポートプロセッサ９２０に復号化信号９１６を出力する。トランスポートプロセッサ９２０は、パケットプロセッサであって、リアルタイムプロトコルスタック及びＦＬＵＴＥ／ＡＬＣプロトコルスタックの両方を実施して、ＤＶＢ−Ｈによるリアルタイムコンテンツまたはファイルベースのコンテンツのいずれかをリカバリする。トランスポートプロセッサ９２０は、コンテンツ信号９２１で表されるように、コンテンツを（楕円９９１で表示されるような）適当な次の回路に出力する。コントローラ９５０は、上記のフローチャートにより、バス９０１を介して、トランスポートプロセッサ９２０を制御し、メモリ９６０の記憶装置のために図１３のＥＳＧで示されるようにＥＳＧ情報をリカバリする。コントローラ９６０は、選択されたクリップ（コンテンツ）のために受信したＥＳＧの静的部分及び動的部分に応じて、制御信号９５１、９５２、及び９５３を用いて（バス９０１を介して）本発明の原理による、トランスポートプロセッサ９２０、ＤＶＢ−Ｈレシーバ９１０及び復調器／復号器９１５のパワーマネジメントを行なう。このように、コントローラ９６０は、ＥＳＧの少なくとも動的部分に対応して、受信したプログラムガイドにおいて示された選択されたコンテンツの受信をスケジューリングする。
【００６０】
レシーバ１００またはレシーバ９００のいずれかに用いられる例示的なフローチャートが、図１６に示されている。ステップ５０５において、レシーバは、静的部分及び動的部分を有するＥＳＧを受信する。静的部分において示されるコンテンツの送信順序は、前回に受信したプログラムガイドの対応するコンテンツの送信順序から決定され、一方、動的部分において示されるコンテンツの送信順序は、前回に受信したプログラムガイドの対応するコンテンツの送信順序と異なっていてもよい。例えば、レシーバは、図１３のＥＳＧ７０２を受信する。ＥＳＧ７０２において、静的部分４０１において示されるコンテンツの送信順序は、ＥＳＧ７０１から決定され、一方、動的部分４１０において示されるコンテンツの送信順序は、ＥＳＧ７０１で示されたように、前回に受信したプログラムガイドの対応するコンテンツの送信順序と異なっている。例えば、ＥＳＧ７０１（前回に受信したプログラムガイド）において、クリップＤ及びＥは、それぞれ、４分及び５分に送信するようにスケジューリングされていた。しかしながら、ＥＳＧ７０２において、送信順序は、クリップＤ及びＥがここでそれぞれ５分及び６分で送信されるようにスケジューリングされるように変更されたことが分かる。図１６に戻ると、ステップ５１０において、レシーバは、例えば、ＥＳＧの動的部分が前回に受信したＥＳＧから変更されたかどうかを、前回に受信したＥＳＧとの比較によって、またはＥＳＧのバージョン番号（図示せず）を用いて判断する。ＥＳＧの動的部分が変更された場合、レシーバは必要に応じてステップ５１５においてあらゆるパワーマネジメントスケジュールを更新する。例えば、クリップＤがレシーバにおいて選択されたコンテンツである場合、ＥＳＧ７０１を受信すると、レシーバは、ｔ＝４分において受信をスケジューリングする。しかしながら、ＥＳＧ７０２を受信した後に、レシーバは、プログラムガイドの動的部分における変更を検出し、ｔ＝５分においてクリップＤで示されるように選択されたコンテンツの受信をここでスケジューリングする。よって、レシーバは、受信したプログラムガイドの少なくとも動的部分における変更に対応して、受信したプログラムガイドにおいて示された選択されたコンテンツの受信をスケジューリングする。
【００６１】
便宜主義的な帯域幅環境（例えば可変ビットレート（ＶＢＲ））では、出力チャネルの帯域幅は一定でないことにも注意しなければならない。これは、スケジューラによって行われる全てのタイミング計算に影響を及ぼす。このことを説明するために、スケジューラは、帯域幅フィードバックインタフェースを備えていてもよい。このように、スケジューラ２４０は、各クリップの送信継続時間（継続時間＝クリップ／バンド幅の大きさ）を計算するために出力帯域幅をモニタする。該送信継続時間によって、スケジューラが次のクリップをスケジューリングすることができる時刻が決定される。このことは、図１７のサーバ１５０’で示される。サーバ１５０’は、ＦＬＵＴＥセンダ２２０からスケジューラ２４０までのフィードバック通信パス２４４を除いて、図７のサーバ１５０と類似している。結果として、ＦＬＵＴＥセンダ２２０がスケジューラ２４０にフィードバック通信パス２４４を介して送信の完了を通知した時から、スケジューラ２４０は、帯域幅の変化を常にモニタすることができて、該変化を統計的に予測することができる。それゆえに、長期的には、スケジューラがつくるタイミングの予測は、より高い精度を有する。更に、スケジューラは各コンテンツの送信の状態を更新することができる。このことは、ＶＢＲ環境において送信数の計算におけるエラーを最小にするのを助ける。
【００６２】
上記のように、発明の概念は、放送網を介して送信のためのマルチメディアコンテンツファイルをスケジューリングする際の多くの問題に対処している。例えば、本発明の概念は、コンテンツデータベースが、新しいクリップの追加及び／または削除などで、ある期間にわたって変化できるようにする。更に、個々のクリップに付随するオペレータの好みは、時間とともに変化してもよい。更に、スケジューラは、ＣＢＲ（固定ビットレート）またはＶＢＲ（可変ビットレート）出力チャネルに適用可能である。
【００６３】
本発明の概念は、ＤＶＢ−Ｈシステムの内容において説明されたが、本発明の概念はそれに限定されないことに注意しなければならない。更に、本発明の概念は、スケジューリングメタデータの特定の数の要素の内容において説明されたが、本発明の概念は、それに限定されず、追加のフィールド、または、より少ないフィールドがスケジューリングメタデータを含んでいてもよい。また、スケジューラがサーバまたはヘッドエンドの一部として示されたが、本発明はそれに限定されておらず、スケジューラは、サーバと別個であってＥＳＧ及び／またはＦＬＵＴＥセンダにスケジューリング情報を出力してもよい。
【００６４】
上記を考慮して、前述のことは、単に本発明の原理を示すだけであり、よって、当業者は、本明細書において明確に記載されていないが本発明の原理を具体化しかつその趣旨及び範囲内にある多数の代替装置を考案することができるということが認められるだろう。例えば、別個の機能要素についての内容において示されているが、これらの機能要素は１つまたは複数の集積回路（ＩＣ）で具体化されてもよい。同様に、別個の要素として示されているが、（例えば、図７の）いずれかのまたは全ての要素は、デジタル信号プロセッサなどの蓄積プログラム制御プロセッサにおいて実施されてもよい。蓄積プログラム制御プロセッサは、図９、１１及び１２などの１つまたは複数のステップに対応しているといった付随するソフトウェアを実行する。更に、本発明の原理は、衛星システム、ＷｉＦｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）方式、携帯電話等の他の種類の通信システムに適用できる。実際、本発明の概念は、固定型のレシーバまたはモバイルレシーバにも適用できる。従って、多数の変化形を例示的な実施形態について実施することができ、他の装置を本発明の趣旨及び範囲から逸脱することなく考案することができるということが理解されなければならない。
【技術分野】
【０００１】
本発明は、概して、通信システムに関し、特に、地上波放送、セルラー方式、ワイヤレスフィデリティ（Ｗｉ−Ｆｉ）方式、衛星システムなどの無線システムに関する。
【背景技術】
【０００２】
今日、ＭＰ３プレーヤから携帯情報端末、携帯電話、モバイルテレビ（ＴＶ）まで、モバイル機器があふれている。残念なことに、モバイル機器には、通常、コンピュータ資源及び／または電力に制約がある。この点で、ＤＶＢ−Ｈ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ）システムによるインターネットプロトコル（ＩＰ）データ放送は、エンドツーエンドのブロードキャストシステムであってかかるデバイス用に最適化されたＩＰベースのメカニズムを用いてあらゆる種類のファイル及びサービスを配信する。例えば、非特許文献１、非特許文献２、非特許文献３、及び、非特許文献４を参照せよ。当該技術分野で周知のＤＶＢ−ＨシステムによるＩＰデータ放送の例が図１に示されている。図１において、ヘッドエンド１０（本明細書において「サーバ」とも称される）は、レシーバ９０で表示されているような、１つまたは複数の受信装置（本明細書において「クライアント」または「レシーバ」とも称される）に、アンテナ３５を介して、ＤＶＢ−Ｈ信号３６をブロードキャストする。ＤＶＢ−Ｈ信号３６は、ＩＰデータ放送をクライアントに伝達する。レシーバ９０は、アンテナ（図示せず）を介して、ＤＶＢ−Ｈ信号３６を受信し、ＩＰデータ放送のＤＶＢ−Ｈ信号３６をリカバリする。図１のシステムは、片方向ネットワークを表す。
【０００３】
上記のＩＰデータ放送は、例えば電子サービスガイド（ＥＳＧ）及びコンテンツファイルなどのファイルを配布することによってコンテンツベースのサービスを提供するために用いられる。図１の内容において、コンテンツベースのサービスは、テレビ（ＴＶ）番組などのリアルタイムコンテンツ、または通常のＴＶプログラムより短いショートフォームコンテンツなどのファイルベースのコンテンツであってもよい。ＥＳＧによって、ユーザがコンテンツベースのサービスを選択し、レシーバが選択されたコンテンツをリカバリできるようにする能力が提供される。この点で、ＥＳＧは、通常、コンテンツ（「コンテンツ」は、本明細書においてイベントとも称される）に関する記述データまたはメタデータを含む。このメタデータは、本明細書において「コンテンツメタデータ」と称され、「コンテンツメタデータ」は、例えばテレビ番組の名前、粗筋、俳優、ディレクタ等、及び放送開始時間、放送日、放送時間、及び放送チャネルを含む。レシーバ９０に付随するユーザは、ＥＳＧで識別される適当なチャネルにレシーバ９０を同調させることにより、ＥＳＧで参照されるコンテンツを受信することができる。ＴＶ放送などのリアルタイムコンテンツの場合には、ＥＳＧがセッション記述プロトコル（ＳＤＰ）ファイルを含むことに注意しなければならない（例えば、非特許文献５を参照する）。ＳＤＰファイルには、レシーバ９０が選択されたブロードキャストコンテンツを受信できるようにする追加の情報が含まれる。
【０００４】
ファイルベースのコンテンツについて、図１のヘッドエンド１０は、ＦＬＵＴＥ（ＦｉｌｅＤｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）プロトコル（例えば、非特許文献６を参照する）を用いてファイルを配布する。ＦＬＵＴＥプロトコルは、片方向ネットワークを介してファイルまたはデータを送信するために用いられ、マルチキャストファイル配信を提供する。また、この例では、ヘッドエンド１０は、ＦＬＵＴＥのための基本トランスポートとして、ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ）プロトコルを用いると考えられる（例えば、非特許文献７を参照する）。ＡＬＣプロトコルは、任意のバイナリオブジェクトの配信のために設計されている。ＡＬＣプロトコルは、大規模で拡張性のある片方向マルチキャスト配信に特に適している。
【０００５】
図２を、簡単に参照すると、ＦＬＵＴＥを用いたファイルベースのコンテンツの送信が、ＥＳＧをブロードキャストしているヘッドエンド１０の内容において示されている。他のファイルベースのコンテンツの送信は、同様であって、本明細書において説明されていない。ヘッドエンド１０は、ＥＳＧジェネレータ１５、ＦＬＵＴＥセンダ２０、ＩＰカプセル化装置２５、及びＤＶＢ−Ｈモジュレータ３０を含む。ＥＳＧジェネレータ１５は、ＦＬＵＴＥセンダ２０にＥＳＧに出力する。ＦＬＵＴＥセンダ２０は、ＡＬＣを介してＦＬＵＴＥによりＥＳＧをフォーマットし、ＩＰカプセル化装置２５へＦＬＵＴＥファイルを伝達する得られたＡＬＣパケットを出力して、当該技術分野で周知のようにＩＰパケット内でカプセル化する。得られたＩＰパケットは、図１に示したように、１つまたは複数の受信装置へ送信するためにＤＶＢ−Ｈモジュレータ３０に出力される。レシーバは、特定のＦＬＵＴＥチャネル（例えば、ＩＰアドレス及びポート番号）に同調されて、レシーバで用いるためにＥＳＧをリカバリする。
【０００６】
上で述べたように、レシーバは、バッテリの寿命などの電力の制約を有しているかもしれない。更に、放送網内のレシーバは、特定の時間に、特定のまたは選択されたファイルベースのコンテンツを受信しているだけかもしれない。その他の時間に、レシーバは、十分に電力を付与されているものの、放送網によって送信される他のあらゆるコンテンツを処理していない。このように、ＦＬＵＴＥセンダ（例えば、図２のヘッドエンド１０のＦＬＵＴＥセンダ２０）とＦＬＵＴＥレシーバ（例えば、図１のレシーバ９０のＦＬＵＴＥレシーバ部分（図示せず））とが時間同期されていて、選択された情報が受信されていない期間にレシーバが電力を抑えることができてレシーバのバッテリの寿命を延ばすことができたならば有益である。時間同期を実行する１つの方法が図３に示されている。特に、図３では、タイミング同期は、ネットワークタイムプロトコル（ＮＴＰ）サーバ４５を介してヘッドエンド１０とレシーバ９０との間で行なわれる。この場合、（ヘッドエンド１０の）ＦＬＵＴＥセンダ２０は、ＮＴＰサーバ４５からのＮＴＰタイムスタンプを含む日時表（ＴＤＴ）（例えば、上記で参照したＥＴＳＩ ＥＮ ３００ ４６８ Ｖ１．７．１を参照せよ）を提供する。ヘッドエンド１０は、ＤＶＢ−Ｈ信号３６内のＴＤＴをブロードキャストする。次に、レシーバ９０は、特定の時間に、ちょうど受信したＮＴＰ時間スタンプを用いて選択されたコンテンツを探す。あるいは、ヘッドエンド１０は、ライブサービスブロードキャストに含まれるＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）センダレポート内にレシーバ９０に対するＮＴＰタイムスタンプを出力することができる（例えば、非特許文献８を参照する）。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】ＥＴＳＩ ＥＮ ３０２ ３０４ Ｖ１．１．１（２００４−１１）の「デジタルビデオブロードキャスティング規格（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ）；ＤＶＢ−Ｈのための送信システム（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｓｙｓｔｅｍ ｆｏｒ Ｈａｎｄｈｅｌｄ Ｔｅｒｍｉｎａｌ）」
【非特許文献２】ＥＴＳＩ ＥＮ ３００ ４６８ Ｖ１．７．１（２００６−０５）「デジタルビデオブロードキャスティング規格（ＤＶＢ）；ＤＶＢシステムにおけるサービス情報（ＳＩ）のための仕様書」
【非特許文献３】ＥＴＳＩ ＴＳ １０２ ４７２ Ｖ１．１．１（２００６−０６）「デジタルビデオブロードキャスティング規格（ＤＶＢ）；ＤＶＢ−ＨによるＩＰデータ放送：コンテンツ配信プロトコル」
【非特許文献４】ＥＴＳＩ ＴＳ １０２ ４７１ Ｖ１．１．１（２００６−０４）「デジタルビデオブロードキャスティング規格（ＤＶＢ）；ＤＶＢ−ＨによるＩＰデータ放送：電子サービスガイド（ＥＳＧ）」
【非特許文献５】Ｍ．ハンドリ、Ｖ．ヤコブソン、「ＲＦＣ ２３２７−ＳＤＰ：セッション記述プロトコル」１９９８年４月
【非特許文献６】Ｔ．パイラ、Ｍ．ラビィ、Ｖ．ロカ、Ｒ．ウォルシュ、「ＲＦＣ ３９２６−ＦＬＵＴＥ−ＦｉｌｅＤｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ」２００４年１０月
【非特許文献７】ラビィ、Ｍ．ゲメル、Ｊ．ビチザーノ（Vicisano）、Ｌ．リッツォ、及びＬ．Ｊ．クロウクロフト、「ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ）プロトコルのインスタンス化」、ＲＦＣ ３４５０、２００２年１２月
【非特許文献８】オーディオ／ビデオトランスポートワーキンググループ、Ｈ．シュルツリン（ＧＭＤ Ｆｏｋｕｓ）、Ｓ．キャスナ（プリセプトソフトウェア社）、Ｒ．フレデリック（ゼロックス・パロアルト・リサーチセンター）、Ｖ．ヤコブソン、「ＲＦＣ １８８９ ＲＴＰ：リアルタイムアプリケーションのためのトランスポートプロトコル」１９９６年１月
【発明の概要】
【発明が解決しようとする課題】
【０００８】
（例えば、図１に示すような）片方向放送網は、マルチメディアまたはデータコンテンツの拡張可能なブロードキャスティングにとって最上の選択である。放送網は、特にマルチメディアコンテンツの送信及びストリーミングのために広く用いられている。しかし、この種のネットワークは、レシーバのためのポイントツーポイントサービスを行う機能を欠いており、レシーバの好みについてセンダに知らせるためのレシーバ用の何らかの逆チャネルも有していない。
【課題を解決するための手段】
【０００９】
放送網を介して機能するプッシュ型ビデオオンデマンド（ＶＯＤ）サービスを行うために、センダは、レシーバの好みのコンテンツを入手する際にできるだけ多くのレシーバを満足させなければならない。更に、コンテンツプロバイダ及びコンテンツオペレータも、自分たち自身の送信の優先順位を有している。「オペレータ」（サービスプロバイダとも称される）とは、ブロードキャストサービスを画定して、サービスのためのコンテンツを提供するエンティティである。「コンテンツプロバイダ」とは、特定のサービスまたは特定の一組のサービスのためのコンテンツを作るエンティティである。
【００１０】
従ってかつ本発明の原理によれば、サーバは、静的部分及び動的部分を有するプログラムガイドを決定し、該静的部分で示されるコンテンツの送信順序が、前回に決定したプログラムガイドにおける対応するコンテンツの送信順序から決定され、一方、該動的部分で示されるコンテンツの送信順序が、該前回に決定したプログラムガイドにおける対応するコンテンツの送信順序と異なっていてもよい。
【００１１】
本発明の例示的な実施形態において、ヘッドエンドはスケジューラを含み、該スケジューラは、コンテンツファイルについての送信順序を決定しかつ静的部分及び動的部分を有する電子サービスガイドを生成する。該動的部分においてスケジューリングされたコンテンツは、該電子サービスガイドの異なるバージョンにおいて異なる送信順序を有していてもよい。スケジュールタイミング情報及びメタデータ情報は、クリップとともに放送網を介して送信され、レシーバは、好みのクリップを選択的に受信して、バッテリ電源及び記憶装置を節約することができる。
【００１２】
上記を考慮してかつ詳細な説明を読むと明らかになるように、他の実施形態及び特徴も実行可能であり、本発明の原理の範囲に入る。
【図面の簡単な説明】
【００１３】
【図１】従来技術によるＤＶＢ−Ｈ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ）システムによるインターネットプロトコル（ＩＰ）データ放送を示す図である。
【図２】従来技術によるＤＶＢ−Ｈ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ）システムによるインターネットプロトコル（ＩＰ）データ放送を示す図である。
【図３】従来技術によるＤＶＢ−Ｈ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ−Ｈａｎｄｈｅｌｄ）システムによるインターネットプロトコル（ＩＰ）データ放送を示す図である。
【図４】図１−３のシステムについてのファイルベースのコンテンツ送信及び付随するＥＳＧフラグメントを示す図である。
【図５】図１−３のシステムについてのファイルベースのコンテンツ送信及び付随するＥＳＧフラグメントを示す図である。
【図６】本発明の原理によるシステムの例示的な実施形態を示す図である。
【図７】本発明の原理による例示的なサーバを示す図である。
【図８】本発明の原理による例示的なスケジューリングメタデータを示す図である。
【図９】本発明の原理によるサーバ１５０で用いるための例示的なフローチャートを示す図である。
【図１０】本発明の原理による例示的なスケジュールを示す図である。
【図１１】本発明の原理によるサーバ１５０で用いるための他の例示的なフローチャートである。
【図１２】本発明の原理によるサーバ１５０で用いるための他の例示的なフローチャートである。
【図１３】本発明の原理による他の例示的なスケジュールを示す図である。
【図１４】本発明の原理によるレシーバの例示的な実施形態を示す図である。
【図１５】本発明の原理によるレシーバの例示的な実施形態を示す図である。
【図１６】本発明の原理によるレシーバで用いる例示的なフローチャートである。
【図１７】本発明の原理による別の例示的なサーバを示す図である。
【発明を実施するための形態】
【００１４】
本発明の概念による特徴を除いて、図に示された要素は、周知であって、詳述されない。例えば、本発明の概念による特徴を除いて、ＤＭＴ（Ｄｉｓｃｒｅｔｅ Ｍｕｌｔｉｔｏｎｅ）送信（直交頻度分割多重方式（ＯＦＤＭ）または符号化直交頻度分割多重方式（ＣＯＦＤＭ）とも称される）について精通していることが前提とされており、本明細書では説明されない。また、テレビ放送、レシーバ、及びビデオ符号化について精通していることが前提とされており、本明細書では詳述されない。例えば、本発明の概念による特徴を除いて、例えばＮＴＳＣ（全米テレビジョン放送方式標準化委員会）、ＰＡＬ（位相反転線、Ｐｈａｓｅ Ａｌｔｅｒｎａｔｉｏｎ Ｌｉｎｅｓ）、ＳＥＣＡＭ（順次式カラーメモリ、Ｓｅｑｕｅｎｔｉａｌ Ｃｏｕｌｅｕｒ Ａｖｅｃ Ｍｅｍｏｉｒｅ）及びＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ）（ＡＴＳＣ）、中国デジタルテレビジョンシステム（ＧＢ）２０６００−２００６などのＴＶ標準、並びにＤＶＢ−Ｈのための現在のレコメンデーション及び提案されているレコメンデーションについて精通していることが前提とされている。同様に、本発明の概念による特徴を除いて、８−ＶＳＢ（ｅｉｇｈｔ−ｌｅｖｅｌ ｖｅｓｔｉｇｉａｌ ｓｉｄｅｂａｎｄ）、直交振幅変調（ＱＡＭ）などの他の送信概念、並びに、例えば無線周波数（ＲＦ）フロントエンド（例えば、低ノイズブロック、チューナ、ダウンコンバータ等）、復調器、相関器、リーク積分器、及び平方器（squarers）などのレシーバ構成要素が前提とされている。更に、本発明の概念による特徴を除いて、例えば、ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）プロトコル、ＡＬＣ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ）プロトコル、インターネットプロトコル（ＩＰ）、及びＩＰＥ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｅｎｃａｐｓｕｌａｔｏｒ）などのプロトコルに精通していることが前提とされており、これらは本明細書において説明されていない。同様に、本発明の概念による特徴を除いて、トランスポートビットストリームを生成するためのフォーマット及び符号化方法（例えば、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）−２システム標準（ＩＳＯ／ＩＥＣ １３８１８−１））は周知であって、本明細書において説明されていない。また、プル型ＶＯＤサービス及びプッシュ型ＶＯＤサービスにも精通していることが前提とされている。プル型ＶＯＤサービスでは、ユーザは特定のビデオクリップを要求し、サーバは当該ビデオクリップをその特定のユーザに送信する。プッシュ型ＶＯＤサービスでは、ユーザの好みのビデオが、ユーザがビデオを積極的に要求することなしに、レシーバにプッシュ配信される。本発明の概念は、本明細書において説明していない従来のプログラム技術を用いて実施されてもよいことに注意しなければならない。最後に、図の同じ番号は、同様の要素を表す。
【００１５】
本発明の概念を説明する前に、図４は、従来技術によるＤＶＢ−Ｈのファイルベースのコンテンツ送信を示す。図４において、ＤＶＢ−Ｈのファイルベースのコンテンツ送信は、クリップ５０、５１、５２及び５３で表されるような多数のイベント（本明細書においてクリップとも称される）を含む。各クリップは、多数のパケットを含むことができるが、これは本発明の概念に関係がない。ＥＳＧは、各クリップを開始時刻、終了時刻に付随させ、対応するＦＬＵＴＥセッション内の付随するコンテンツファイルを識別する。このことは、クリップ５１に付随するＥＳＧのフラグメント６０（ＥＳＧフラグメント６０）として図４に示されている。簡単にするために、他のＥＳＧデータは示されていない。図４に示すように、ＥＳＧフラグメント６０は、ＣｏｎｔｅｎｔＬｏｃａｔｉｏｎパラメータ６５、ＰｕｂｌｉｓｈｅｄＳｔａｒｔＴｉｍｅパラメータ６１、及びクリップ５１に付随するＰｕｂｌｉｓｈｅｄＥｎｄＴｉｍｅパラメータ６２を含む。この例では、対応するＦＬＵＴＥセッション内の付随するコンテンツファイルは、「Ｃｌｉｐ１．ｍｐ４」である。ＰｕｂｌｉｓｈｅｄＳｔａｒｔＴｉｍｅ６３の実際の値及びＰｕｂｌｉｓｈｅｄＥｎｄＴｉｍｅ６４の実際の値は、協定世界時（ＵＴＣ）装置に存する。ＰｕｂｌｉｓｈｅｄＳｔａｒｔＴｉｍｅの値は、ＦＬＵＴＥセンダが実際にファイルの送信を開始する時刻である。即ち、クリップがＦＬＵＴＥセンダからシステムチェインにおける次のブロックに渡される時刻である。このことは、ＤＶＢ−Ｈシステムについての図５に更に示されている。即ち、ＰｕｂｌｉｓｈｅｄＳｔａｒｔＴｉｍｅの値は、ＦＬＵＴＥセンダ２０がＩＰカプセル化装置２５にクリップを渡す時刻である。
【００１６】
前に述べたように、放送網を介して機能するプッシュ型ビデオオンデマンド（ＶＯＤ）サービスを行うために、センダは、レシーバの好みのコンテンツを入手する際にできるだけ多くのレシーバを満足させなければならない。更に、コンテンツプロバイダ及びコンテンツオペレータも、自分たち自身の送信の優先順位を有している。「オペレータ」（サービスプロバイダとも称される）とは、ブロードキャストサービスを画定して、サービスのためのコンテンツを提供するエンティティである。「コンテンツプロバイダ」とは、特定のサービスまたは特定の一組のサービスのためのコンテンツを作るエンティティである。
【００１７】
上記を考えると、プッシュ型ＶＯＤサービスにおいて送信用のコンテンツを配給しかつスケジューリングすることに関して、多くの問題が見出される。例えば、コンテンツデータベースは、ある期間にわたって変化するかもしれず、オペレータの好みも、新しいクリップの追加とともに変化するかもしれない。従って、新しいクリップの追加によるオペレータの好みの変化が、あまり好まれないクリップがブロードキャストのためにずっとスケジューリングされるのを無期限に防ぐことになるので、新しいクリップが追加されるときに、クリップの送信についての優先順位ベースのスケジューリングを実行することができない。
【００１８】
更に、スケジュールの予測可能性は、別の重要な要因である。スケジュールは、クリップの追加及び除去によってあらゆる時点でまたは優先順位の変更があっても変化し得る。しかしながら、片方向ネットワーク環境において、レシーバ端末は、その好みのコンテンツをタイムリに受信するためにスケジュールに大きく依存している。スケジュールが予測できない場合、レシーバは常駐しなければならず、このことによって無駄に電力が浪費される。更に、片方向ネットワークにおいて、レシーバは、失われたファイルについてセンダに知らせる手段を備えていない。それゆえに、スケジュールの予測可能性は、レシーバの動作にとって非常に重要である。
【００１９】
また、レシーバにおける好みの設定は、ユーザの個人的な興味、レシーバの場所、受信時間等により異なってくる。例えば、マルチメディアクリップブロードキャストにおいて、視聴者は非常に好ましいクリップを何度も繰り返して入手するよりはむしろ新しいクリップを入手するのを必然的に好むということが報告されている。しかしながら、ブロードキャストプッシュ型ＶＯＤサービスにおいて、好みの設定に直ちに配慮することができる逆チャネルはない。この点で、マルチメディアクリップのための送信スケジュールを更新するときに、あらゆるスケジューリングは、かかる問題に対処しなければならない。
【００２０】
上記を考慮し、本発明の原理に従って、プッシュ型ＶＯＤサービスが上記の問題に対処できるようにするスケジューラが説明されている。従ってかつ本発明の原理により、ヘッドエンドは、動的優先順位の値の関数として、コンテンツファイルについての送信順序を決定する。動的優先順位の値の関数は、少なくともコンテンツファイル同士の間の相違の測定により決定される。ヘッドエンドは、決定された送信順序に従ってコンテンツファイルを送信する。
【００２１】
本発明の例示的な実施形態において、コンテンツファイルは、スポーツビデオ、音楽ビデオ、ニュースクリップ、映画サウンドトラック等のようないずれの種類のオーディオ／ビデオクリップであってもよく、「クリップメタデータ」は各クリップに付随している。ヘッドエンドはスケジューラを含み、該スケジューラは、動的優先順位の値の関数として、コンテンツファイルについての送信順序を決定する。動的優先順位の値の関数は、少なくともコンテンツファイル同士の間の相違の測定により決定される。コンテンツファイルの相違の測定は、各クリップに付随するクリップメタデータの関数として更に決定される。スケジュールタイミング情報及びメタデータ情報は、クリップとともに放送網を介して送信され、レシーバは、好みのクリップの選択的な受信を行って、バッテリ電源及び記憶装置を節約することができる。
【００２２】
ここで、図６を参照すると、本発明の原理による例示的なシステムが示されている。この例のために、図６に示したシステムは、本発明の概念による特徴を除いて、図１で説明したＤＶＢ−ＨシステムによるＩＰデータ放送と類似のＤＶＢ−ＨシステムによるＩＰデータ放送であると考えられる。本発明の原理により、ヘッドエンド１５０は、マルチメディアコンテンツファイルに付随する記述データを解析して該マルチメディアコンテンツファイルについての送信順序を決定する。更に、アンテナ１８５を介して、決定された送信順序に従ってマルチメディアコンテンツファイルを送信する。特に、ヘッドエンド１５０は、ラップトップコンピュータ１００−１、携帯情報端末（ＰＤＡ）１００−２、及び携帯電話１００−３のうちのいずれか１つで表されるような、１つまたは複数の受信装置（本明細書において「クライアント」または「レシーバ」とも称される）にＩＰデータ放送をブロードキャストするためのＤＶＢ−Ｈ信号１８６をブロードキャストする。その各々は、ＤＶＢ−Ｈ信号を受信して、リアルタイムコンテンツ及びファイルベースのコンテンツのためのブロードキャストＩＰデータ放送のＤＶＢ−Ｈ信号のリカバリをすると考えられる。図６のシステムは、片方向ネットワークを表すものである。しかしながら、本発明の概念は、そのようには限定されていない。
【００２３】
本発明の原理によるヘッドエンドまたはサーバ１５０の例示的な実施形態が図７に示されている。本発明の概念による特徴を除いて、図７に示された要素は周知であって、本明細書において説明されていない。ヘッドエンド１５０は、プロセッサベースのシステムであって、図７の破線のボックスの形で示されたプロセッサ１９０及びメモリ１９５で表されるような、１つまたは複数のプロセッサ及び付随するメモリを含む。この内容では、コンピュータプログラムまたはソフトウェアが、プロセッサ１９０による実行のためにメモリ１９５に格納されていて、例えばスケジューラ２４０を実行する。プロセッサ１９０は、１つまたは複数の蓄積プログラム制御プロセッサを表すものであり、これらは、スケジューリング機能専用に設けられなくてもよい。例えば、プロセッサ１９０がヘッドエンド１５０の他の機能も制御することができる。メモリ１９５は、例えば、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）等のあらゆる記憶装置を表すものである。メモリ１９５は、ヘッドエンド１５０に内臓されていてもよいしかつ／または外付けであってもよい。更に、メモリ１９５は、必要に応じて揮発性及び／または不揮発性である。
【００２４】
ヘッドエンド１５０は、ＥＳＧジェネレータ２１５、ＦＬＵＴＥセンダ２２０、ＩＰカプセル化装置２２５、ＤＶＢ−Ｈモジュレータ２３０、コンテンツデータベース２３５及びスケジューラ２４０を含む。ＥＳＧジェネレータ２１５、ＦＬＵＴＥセンダ２２０、ＩＰカプセル化装置２２５、及びＤＶＢ−Ｈモジュレータ２３０は、図２に示された対応する構成要素と同様であり、本明細書において、これ以上説明されない。本発明の概念による特徴を除いて、以下に説明されるＥＳＧジェネレータ２１５は、ＦＬＵＴＥセンダ２２０にＥＳＧを出力する。ＦＬＵＴＥセンダ２２０は、ＡＬＣを介してＦＬＵＴＥによりＥＳＧをフォーマットし、当該技術分野で周知であるように、ＩＰパケットにおけるカプセル化のためにＩＰカプセル化装置２２５へＦＬＵＴＥファイルを運ぶ得られるＡＬＣパケットを出力する。得られたＩＰパケットは、図６に示したように、１つまたは複数の受信装置に対する送信のためにＤＶＢ−Ｈモジュレータ２３０に出力される。レシーバ（例えば図６のレシーバ１００−２）は、特定のＦＬＵＴＥチャネル（例えばＩＰアドレス及びポート番号）に同調させて、レシーバにおける使用のためにＥＳＧをリカバリする。
【００２５】
図７に示さすように、ヘッドエンド１５０はまた、コンテンツデータベース２３５及びスケジューラ２４０を含む。コンテンツデータベース２３５は、コンテンツ、即ちマルチメディアコンテンツファイルを格納する。これらのマルチメディアコンテンツファイルは、スポーツビデオ、音楽ビデオ、ニュースクリップ、映画サウンドトラック等のようなあらゆる種類のオーディオ／ビデオクリップである。本発明の概念による特徴を除いて、これらのクリップは、信号２３８を介して、ＦＬＵＴＥセンダ２２０に出力され、図４に関して先に述べたようにＤＶＢ−Ｈにおいてファイルベースのコンテンツ送信として送信される。コンテンツメタデータは、各クリップに付随する。各クリップについてのコンテンツメタデータは、ＥＳＧジェネレータ２１５に出力され、本発明の原理により、信号２３６を介してスケジューラ２４０に出力される。スケジューラ２４０は、信号２３９を介して、コンテンツデータベース２３５を制御しかつモニタする。その結果、スケジューラ２４０は、例えば、クリップのコンテンツメタデータを変更することによる追加／削除または変更などの、コンテンツデータベース２３５に対する変更を検出する。
【００２６】
本発明の原理により、スケジューラ２４０は、コンテンツデータベース２３５に格納されたクリップに付随するコンテンツメタデータを解析して、マルチメディアコンテンツファイルについての送信順序を決定する。この点で、スケジューラ２４０は、制御信号２４２を介して、ＦＬＵＴＥセンダ２２０に対する送信順序を制御する。更に、スケジューラ２４０は、信号２４１を介して、レシーバに送信されるＥＳＧを生成する際に用いる追加のスケジューリング情報をＥＳＧジェネレータ２１５に出力する。この追加のスケジューリング情報は、本明細書において「スケジューリングメタデータ」と称される。特に、各クリップに付随するコンテンツメタデータに加えて、スケジューラ２４０は、図８に示すようなスケジューリングメタデータを追加する。スケジューリングメタデータ２００は、多数のフィールドを含む。即ち、動的優先順位２０１、送信数２０２、待ち時間２０３、及び、任意でキーワード２０４（点線の形で示されている）である。よって、各クリップについて、コンテンツメタデータ２１０に加えてスケジューリングメタデータ２００がある。これは、図８に示したようにクリップメタデータ全体２２０と本明細書において称される。コンテンツメタデータ２１０は、コンテンツデータベース２３５に格納される。コンテンツメタデータ２１０は、コンテンツＩＤ２１１、優先順位２１２、説明２１３、及び任意でキーワード２１４（点線形式で示された）を含む。例示として、ＸＭＬ（拡張マークアップ言語）が、メタデータを表すために用いられてもよい。
【００２７】
メタデータ２１０に関して、コンテンツＩＤ２１１は、コンテンツデータベース２３５の各クリップを識別するために一意の数で示される識別子である。優先順位２１２は、識別されたクリップについて優先レベルを表す数値である。説明２１３は、例えば、テレビ番組の名前、概要、俳優、ディレクタ、及びブロードキャストについての予定時刻、予定日、放送時間及びチャネルである。最後に、キーワード２１４は、識別されたクリップのコンテンツを簡単に説明している１つまたは複数のキーワードを表す文字数字の単語のリストである。
【００２８】
スケジューリングメタデータ２００に関して、動的優先順位２０１は、識別されたクリップをブロードキャストするかまたは送信するための実際の優先レベルを表す数値である。送信数２０２は、識別されたクリップがブロードキャストまたは送信された回数を表す数値である。待ち時間２０３は、識別されたクリップが最後にブロードキャストされた時から経過した秒数を表す数値である。最後に、キーワード２０４は、識別されたクリップのコンテンツを簡単に説明している１つまたは複数のキーワードを表す文字数字の単語のリストである。上記のように、キーワードは、スケジューリングメタデータ２００またはコンテンツメタデータ２１０のいずれかにあってもよい。スケジューリングメタデータ２００において、キーワード２０４は、説明２１３を解析しているスケジューラ２４０によって決定される。コンテンツメタデータ２１０において、キーワード２１４は、コンテンツメタデータ２１０の一部として、オペレータにより設定される。
【００２９】
ここで、図９のフローチャートに注意を向けなければならない。該フローチャートは、本発明の原理による例示的なスケジューリング方法を示す。ステップ３０５において、スケジューラ２４０は、スケジューリング頻度ｆｓ（３１６）及び、スケジュールの静的部分（後述される）を初期化しかつ決定する。スケジューリング頻度ｆｓ（３１６）は、スケジュールの静的部分であるように、演繹的に例示的に決定される。例えば、これらは、図７のメモリ１９５に格納される値である。これらの値は、また、（例えば、キーボード／コンソール（図示せず）を介して）信号２４３を介してオペレータにより設定されてもよい。スケジューリング頻度ｆｓ（３１６）は、スケジュールがどれくらいの頻度で生成されるかを決定する。ステップ３１０において、スケジューラ２４０は、コンテンツデータベース２３５に格納されたクリップについてのコンテンツメタデータを取り出す。
【００３０】
ステップ３１５において、スケジューラ２４０は、スケジュールを生成する時刻か否かをチェックする。それはスケジューリング頻度ｆｓ（３１６）により決定される。スケジュールを生成する時刻でない場合、ステップ３２５において、スケジューラ２４０は、（例えば、図７の信号２３９を介して）コンテンツデータベース２３５が更新されたかどうかをチェックする。コンテンツデータベース２３５が更新されていない場合、スケジューラ２４０は、ステップ３１５において、スケジュールを生成する時刻か否かを再びチェックする。しかしながら、コンテンツデータベース２３５が更新された場合、ステップ３１０において、スケジューラ２４０は、更新されたコンテンツを取り出す。この更新されたコンテンツは、変更されたコンテンツ、新しいコンテンツ、または削除されたコンテンツを表す。この点で、スケジューラ２４０は、必要に応じて、取り出されたコンテンツメタデータを生成、更新、または削除するために、ステップ３１０において必要な処理を行う。
【００３１】
ステップ３１５において、一旦スケジューラ２４０が、スケジュールを生成する時刻であると判断すると、ステップ３２０に実行を進める。そこで、スケジューラ２４０は、識別されたクリップ各々についてのスケジューリングメタデータ２００の値を決定するかまたは更新し、スケジュールを生成する。最初に、必要に応じて、スケジューラ２４０は、説明２１３を解析して、スケジューリングメタデータ２００のキーワード２０４フィールド用のキーワードを決定する。あるいは、スケジューラ２４０は、もしあればキーワード２１４を使用する。次に、スケジューラ２４０は、識別されたクリップ（コンテンツＩＤ２１１）についての実際の優先順位を表す値を決定して、この値を動的優先順位２０１（以下に詳述される）に格納する。スケジューラ２４０はまた、送信数２０２の値を更新して、識別されたクリップが送信された回数を表す。更に、識別されたクリップが最後にブロードキャストされたときから経過した秒数を表している待ち時間２０３の値を更新する。一旦識別されたクリップ各々についてのスケジューリングメタデータが決定されると、スケジューラ２４０は、（信号２４１を介して）ＥＳＧジェネレータ２１５及び（信号２４２を介して）ＦＬＵＴＥセンダ２２０が使用するためのスケジュールを生成する。ステップ３２５に実行は続く。簡単にするために、他の端末及び／またはエラー状態は、本明細書で説明されているフローチャートにおいて示されていないことにも注意しなければならない。
【００３２】
レシーバ側及びセンダ側の両方の不必要な実施の複雑さを避けるために、スケジューラ２４０は、ノンプリエンプティブなスケジューラとして例示的に設計されている。これは、各ビデオクリップまたは他のあらゆるコンテンツファイルを小なる部分に分割せず、異なるタイムスロットに及んで送信されないということを意味する。言い換えると、一旦コンテンツ送信が開始されると、該送信は、別のクリップを送信するためにスケジューラ２４０に最後まで割り込まれない。このことは、端末における受信完了までの所要時間を最小限にするのに役立つ。しかしながら、本発明の概念は、それに限定されておらず、プリエンプティブスケジューラにも適用できる。
【００３３】
上で述べたように、スケジューラ２４０はスケジュールを生成する。本発明の原理により、例示的なスケジュール４００が、図１０に示される。スケジュール４００は、静的部分４０１及び動的部分４１０を含む。静的部分４０１は、Ｊ個のクリップを含む。即ち、Ａ（４０１−１）、Ｃ（４０１−２）、・・・Ｆ(４０１−Ｊ)であり、ここでＪ≧０である。動的部分４１０は、Ｋ個のクリップを含む。即ち、Ｄ（４１０−１）・・・Ｅ（４１０−Ｋ）であり、ここでＫ≧０である。スケジュールの継続時間は、終了時刻から開始時刻を引いたものである（即ち、ｔE−ｔS）。図１０から分かるように、静的部分４０１は、開始時刻ｔSで始まり、時刻ｔDで終わる。時刻ｔDは、動的部分４１０の開始時刻である。動的部分４１０は、スケジュール終了時刻ｔEで終わる。図１０から分かるように、各クリップは、付随する継続時間を有する。例えば、クリップＣ（４０１−２）は、Ｄｃという付随する継続時間を有する。図１０は、静的部分及び動的部分を示すが、いずれかの部分のクリップの数がゼロであってもよい、即ち、ｔSはｔDに等しくてもよいことに注意しなければならない。
【００３４】
ここで図１１を参照すると、図９のステップ３２０において用いられる例示的なフローチャートが示されている。新しいスケジュールを生成する時刻である場合、スケジュール時刻ｔが初期化される。例えば、図１１のステップ３５０において、ｔＳ＝０である。ステップ３５５において、スケジューラ２４０は、前回のスケジュールが存在するかどうか調べる。前回のスケジュールが存在する場合、ステップ３６０において、スケジューラ２４０は前回のスケジュールをロードし、前回のスケジュールの動的部分の開始時刻に等しいｔをセットする。例えば、図１０のスケジュール４００についてｔ＝ｔDである。いずれの場合も、ステップ３６５において、スケジューラ２４０は、このスケジューリングセッション（下記に詳述される）のために取り出された各クリップまたはコンテンツの動的優先順位（Ｄｐ（ｔ））を決定する。ステップ３７０において、最も高い動的優先順位Ｄｐ（ｔ）を有するクリップ（ｉ）が、スケジュール時刻ｔで始まる新しいスケジュールに配される。このクリップ（ｉ）は、Ｄｉという付随する継続時間を有する。ステップ３７５において、スケジュール時刻ｔは、ｔ＝ｔ＋Ｄｉへ進む。ステップ３８０において、スケジュール時刻ｔは、スケジュール終了時刻ｔEと照合される。スケジュールの終了時刻に至っている場合、ステップ３８５において、スケジューラ２４０は新しいスケジュールに戻るかまたは新しいスケジュールを生成する。しかしながら、スケジュールの終了時刻に至っていない場合、スケジューラ２４０は、ステップ３６５において残りのクリップについての動的優先順位（Ｄｐ（ｔ））を再計算して、最も高い動的優先順位（Ｄｐ（ｔ））を備えたクリップを再び選択する。この処理は、スケジューラ２４０が全部のスケジュールを埋めるまで、繰り返される。フローチャートに示すように、前回のスケジュールがシステム内に存在する場合、開始時刻「t」は、動的優先順位の計算を行う前に調整される。この場合、前回のスケジュールの静的部分のイベントは、そのまま新しいスケジュールにコピーされる。これは、レシーバ（後述される）において、スケジュールをより予測可能にするために行われる。
【００３５】
特定の時間インスタントｔにスケジューリングされたクリップがそのインスタントにおけるクリップの動的優先順位により決定されるということが、図１１のフローチャートから分かる。図１１のステップ３６５の例示的な実施形態が、図１２に示される。ステップ４５０において、スケジューラ２４０は、現在のスケジュール時刻ｔ及び現在の継続時間Ｄｉをロードする。前回のスケジュールが存在せず、クリップがこのスケジューリングセッションにおいて現在のスケジューリングされていなければ、現在の継続時間Ｄiはゼロに等しい。前回のスケジュールが存在するが、クリップがこのスケジューリングセッションにおいて現在スケジューリングされていなければ、Ｄiは、動的部分の開始時刻ｔDと静的部分の開始時刻との間の差に等しい。一方、Ｄiは、スケジューリングされた最後のクリップの継続時間に等しい。ステップ４５５において、スケジューラ４５５は全てのクリップの送信数（例えば、図８の送信数２０２）を更新して、同様に全てのクリップの最後のブロードキャスト時間を更新する。ステップ４６０において、スケジューラ２４０は、現在の継続時間Ｄiの値をチェックする。現在の継続時間Ｄiの値がゼロに等しい場合、ステップ４７０において、各クリップについての待ち時間Ｗｔ（図８に示された待ち時間２０３としても示されている）が、
Ｗｔ＝クリップ（ｉ）の最終ブロードキャスト時刻−ｔ （１）
で計算される。それは、単に、そのクリップについての現在の時刻と最終のブロードキャスト時間との間の差である。しかしながら、現在の継続時間Ｄiの値がゼロに等しくない場合、ステップ４６５において、この継続時間は、各クリップについての待ち時間Ｗｔ（図８に示された待ち時間２０３としても示されている）に加えられて、
Ｗｔ＝Ｗｔ＋Ｄi （２）
で算出される。ここで、Ｄiは、前回にスケジューリングされたクリップの継続時間（またはスケジュールの静的部分の時間の継続時間）を表す。
【００３６】
ステップ４７５において、スケジューラ２４０は送信のためにまだスケジューリングされていないクリップの相違点を決定する。この点で、ブロードキャストを介したプッシュ型ＶＯＤのアプリケーションを実現する際に、フィードバックチャネルが不足していることに注意しなければならない。エンドユーザが自分たちの好みをセンダに知らせるための逆チャネルはない。プッシュ型ＶＯＤのアプリケーションにおいて、通常、その優先順位が互いに異なる様々なユーザ（レシーバ）がいる。この特定の問題に配慮しないスケジューラは、プッシュ型ＶＯＤのアプリケーションにとって理想的でない。例えば、熱狂的サッカーファンは、自分がサッカーのワールドカップハイライトを入手するためにニュース及び音楽ビデオの次の１０クリップの送信が終わるまで待たなければならないならば、プッシュ型ＶＯＤアプリケーションの類へ決して行かない。
【００３７】
様々な視聴者の好みの可能性を考慮するために、かつ本発明の原理により、図１２のステップ４７５において、スケジューラ２４０は、前回にスケジューリングされたクリップと比較してスケジュール用に利用可能なクリップの各々の相違について重み付けを与える。例えば、時刻ｔにおいて最も異なるクリップは、他のクリップより大きい異なる重み付け値を有する。次に、この異なる重み付け値は、クリップの動的優先順位を決定する際に引き続き用いられ、その結果（後述されるように、他の要因を考慮しない）、連続した送信のために類似のクリップの列を作る代わりに、異なるクリップが、互いに隣接して送信されるようにスケジューリングされる。スケジューリングされていないクリップはスケジューリングされたクリップと比較してどれだけ類似しているかを見出すために、スケジューラは、各クリップに付随するキーワードのデータ（図８のキーワード２０４）を例示的に使用する。上で述べたように、コンテンツプロバイダは、このキーワードデータを提供することができかつ／または、オペレータもコンテンツをよりよく分類するために追加のキーワードを指定することもできる。あるいは、上でも述べたように、スケジューラ２４０は、図８の説明２１３を解析して、説明２１３自体でキーワードを形成してキーワード２０４に格納することができる。特定のクリップについてのキーワード２０４またはキーワード２１４におけるキーワードの全リストは、類似性の測定を行うために他のクリップのそれぞれのキーワードと対照される。２組のキーワードの間で相関の割合を計算するいくつかの方法がある。例えば２つのベクトルのドット積をとることによって、２組のキーワードの間の相関が見つけられる。
【００３８】
例示的に、ステップ４７５において、スケジューラは、例えば、クリップＸで示されたスケジューリングされていないクリップ及びクリップＹで示された最後にスケジューリングされたクリップである、２つのクリップの間で以下の類似性の測定を行なう。
【００３９】
【数１】
【００４０】
ここで、Ｓ（ｘ，ｙ）は、クリップＸとクリップＹとの間の類似性の測定である。Ｎｓは、クリップＸ及びクリップＹの両方における類似のキーワードの総数である。Ｎ（ｘ）は、クリップＸのキーワードの総数であり、Ｎ（ｙ）は、クリップＹにおけるキーワードの総数である。方程式（３）において、Ｓ（ｘ，ｙ）の値は、０と１との間で変化し得る。１の値は完全に類似するクリップを表し、０の値は完全に異なるクリップを表す。それゆえに、相違の測定は、
Ｄｓ（ｘ，ｙ）＝１−Ｓ（ｘ，ｙ） （４）
になる。
【００４１】
次に、スケジューリングされていないクリップ各々の相違の測定Ｄｓ（ｘ，ｙ）が、クリップについての動的優先順位を決定する際にスケジューラ２４０によって用いられる。このプロセスにおいて、キーワードを特定したオペレータ／コンテンツプロバイダは、キーワードは、概要フィールド／要約フィールドを解析することによってスケジューラにより生成されるキーワードより大きく重み付けされる。
【００４２】
相違の測定は、前回のものと比較された場合に最も異なるクリップを識別するために行われるだけでなく、送信についての前回の履歴と比較された場合に最も異なるクリップを見出すために延長されてもよいことに注意しなければならない。これは、異なる測定を過去の相違の移動平均とすることによって実現される。このように、方程式（３）及び方程式（４）に加えて、スケジューラ２４０は、更に相違の測定を精緻化することもできる。特に、継続時間Δｔを有するクリップＸが時刻「ｔ−Δｔ」においてスケジューリングされると仮定する。次に、時刻「ｔ」における各クリップのＤｓを、同様に、
Ｄｓ（ｔ）＝（１−α）＊Ｄｓ（ｘ，ｉ）＋α＊Ｄｓ（ｔ−Δｔ） （５）
で計算することができる。ここで、Ｄｓ（ｘ，ｉ）は、（方程式（３）及び方程式（４）から）クリップＸに対するクリップ（ｉ）の相違であり、Ｄｓ（ｔ−Δｔ）は、時刻ｔ−Δｔにおいて、即ち、前回のスケジュール間隔で、とられたクリップ（ｉ）の相違値である。αは、その値が０と１との間の範囲にある定数である。αの値は、より大きい重み付けが、前回の履歴についてより最近スケジューリングされたクリップに対する相違に与えられるといった方法で選択される。
【００４３】
スケジューリングされていないクリップ各々のための相違値を決定した後に、ステップ４８０において、スケジューラ２４０は、全てのスケジューリングされていないクリップについて動的優先順位を決定する。例示として、時刻「t」における各クリップの動的優先順位は、
Ｄｐ（ｔ）＝ＫｐＰ＋ＫｄＤｓ（ｔ）＋ＫｗＷｔ−ＫｓＳｃ （６）
で与えられる。ここでＤｐ（ｔ）は、時刻ｔにおけるクリップの動的優先順位である。Ｐはクリップの優先順位（例えば図８の優先順位２１２）を与えられるオペレータ／コンテンツプロバイダである。Ｄｓ（ｔ）は、時刻ｔにおけるクリップについての上記の相違の測定である（あるいは、Ｄｓ（ｘ，ｙ）がＤｓ（ｔ）の代わりに用いられてもよい）。Ｗｔは、時刻ｔにおけるクリップの待ち時間である。Ｓｃは、クリップの送信数である。Ｋｐ、Ｋｄ、Ｋｗ、及びＫｓは、それぞれ、オペレータの優先順位、相違、経時、及び送信数についての関連する重み付けを決定する定数である。これらの定数を演繹的に設定することができると共に、これらの定数はまた、最適のスケジュールを得るために手作業で調整することができるかまたは視聴者から任意に集計フィードバックを利用することによってスケジューラにおいて調整することができる。集計フィードバックは、異なるインスタンスにおいてとられた視聴者からの一群のオフラインのフィードバックである。集計フィードバックは、ウェブポータルベースのもしくはＳＭＳ（ショートメッセージサービス）ベースのゲートウェイまたは他の類似の通信チャネルのいずれかを介して実現することできる。
【００４４】
動的優先順位が方程式（６）の内容において説明されたが、変数Ｐ、Ｄｓ（ｔ）、Ｗｔ及びＳｃのうちのいずれか１つ、２つ、または３つを、動的優先順位を決定するために用いることができるということに注意しなければならない。実際、追加のパラメータも、本発明の原理に従って動的優先順位を決定するためにこれらの４つに加えて定義することができる。
【００４５】
上で述べたように、例示として、送信数Ｓｃは、スケジューリングプロセスにおいて、クリップが送信された回数を考慮するために用いられる。例えば、ビデオクリップブロードキャストシステムにおいて、視聴者は常に、新しいクリップを探す。通常、視聴者は、古いクリップよりもむしろ新しいクリップを選択する。古いクリップがオペレータまたはコンテンツプロバイダによって高く評価されていたとしても時々この場合がある。それゆえに、スケジューラは、クリップが送信された回数を考慮して、それによってクリップをスケジューリングしなければならない。スケジューラは、Ｓｃを用いてこの問題を解決して、特定のクリップが送信された回数を計数する。全ての新しいクリップは、ゼロである送信数Ｓｃの値を有する。クリップの動的優先順位を決定する際に、スケジューラは送信数に正比例して優先順位を低くする。言い換えると、送信数が少なくなるほど、動的優先順位における順序が高くなる。
【００４６】
この点で、スケジューラは、古いクリップより高い優先順位のコンテンツを優先し、古いクリップより新しく追加されたクリップに配慮するので、新しいクリップを頻繁に追加することによって、低い優先順位のクリップを過去に送信されたことなしにデータベースにおいていつまでも保持する可能性がある。このことを補うために、方程式（６）のパラメータＷｔを介して、スケジューラはクリップの経時（aging）を説明する。このように、クリップの動的優先順位は、待ち時間が長くなるにつれて高くなる。
【００４７】
クリップについてオペレータ／コンテンツプロバイダの優先順位Ｐを上げることは、動的優先順位を直接上げることにつながることが方程式（６）からも分かる。それゆえに、オペレータ／コンテンツプロバイダの好みのクリップは、早期にスケジューリングされる可能性が高い。
【００４８】
ステップ４８５において、スケジューラ２４０は、送信のために時刻ｔにおいて最も高いかまたは最大の動的優先順位Ｄｐ（ｔ）を有するクリップを選択し、スケジュール内にこのクリップを配する。多数のクリップが同等の動的優先順位を有する場合、スケジューラ２４０は、クリップのうちの１つを選択することができるかまたは同等の動的優先順位のクリップの間でラウンドロビンスケジュールを実行することができることに注意しなければならない。例えば、一組のクリップの全ての優先順位の測定が同じ値を生じる場合、スケジューラは単に該一組のクリップを繰り返してスケジュールをつくり、それらの全てが送信されたということを確かめる。
【００４９】
ステップ４９０において、選択されたクリップは、その待ち時間をゼロに設定し（例えば、図８の待ち時間２０３）、Ｄｉは選択されたクリップの継続時間に等しく設定され、スケジューリングプロセスの次の繰り返しにおいて、（上述されたように）このＤｉの値がステップ４５０で用いられる。
【００５０】
上で述べたように、スケジュールの予測性は重要である。片方向ブロードキャスト環境において、レシーバは、コンテンツの選択的な受信を行えるようになるスケジュール及びメタデータ情報に大いに依存する。それで、レシーバが前もってスケジュールを受信しなければならないことは非常に重要である。更に、いずれかのスケジュールの変更が新しいコンテンツの追加によりまたは他の理由のためにサーバに生じる場合、最新のスケジュールは、全てのレシーバに送信される必要がある。スケジューラは、例えばＴ＝１／ｆｓごとにといった、周期的なスケジュール更新を送信することによってこれを行う。ｆｓは前に述べたスケジューリング頻度である。例えば、周期的なスケジュール更新は、新しくスケジューリングされたイベント及びスケジューリングされたコンテンツに付随する他のメタデータ等を含む。この情報を用いて、レシーバは、レシーバがコンテンツを受信する必要があるかどうか、かついつ同調させてコンテンツを得る必要があるかを決めることができる。よって、端末は電力及び記憶空間を節約することができる。
【００５１】
しかしながら、実際のシステムにおいて、スケジュールの更新及び端末でのスケジュール更新の即時の受信についての頻度は限定される。言い換えると、一旦スケジュール変更がサーバに生じると、レシーバが該スケジュール変更について知るのにある程度時間がかかる。この遅延を端末での最短スケジュール更新間隔とみなす。この最短スケジュール更新間隔及びそのため予測が不可能であることを説明するためにかつ本発明の原理に従って、スケジューラは別の概念、即ち、図１０において示したようにスケジュールを静的部分及び動的部分に分けることを取り入れる。
【００５２】
これは、図１３において更に示されている。この図は、連続する時間間隔を通してスケジューラ２４０による３つのＥＳＧ７０１、７０２、及び７０３の構成を示している。簡単にするために、ＥＳＧは１分ごとに形成されており、以前のスケジュールはなかったと仮定する。スケジューラ２４０によって、０分に形成された、第１のＥＳＧは、ＥＳＧ７０１である。ＥＳＧ７０１を形成する際に、スケジューラ２４０は、クリップＡ、Ｂ、Ｃ、Ｄ及びＥが送信に利用可能であることを決定して、図９、１１及び１２の上記のスケジューリングプロセスに従って図１３に示したように送信のためのそれらをスケジューリングする。図１３から分かるように、ＥＳＧ７０１において、クリップＡ、Ｂ、Ｄ及びＥの各々は１分の継続時間を有し、一方、クリップＣは２分の継続時間を有する。更に、静的部分４０１が２分の継続時間を有すると演繹的に画定され、ＥＳＧ４０１の残りの部分は、ＥＳＧの動的部分４１０として設計されていると考えられる。
【００５３】
次のスケジューリング間隔で、スケジューラ２４０は、クリップＢ、Ｃ、Ｄ、Ｅ及びＦは、送信に利用可能であると判断する（クリップＡは送信された）。更に、スケジューラ２４０は、前回のスケジュール（ＥＳＧ７０１）が存在したと判断して、静的部分４０１を決定する。先に述べたように、スケジューラ２４０は、ノンプリエンプティブなスケジューラとして例示的に設計されている。このことは、各ビデオクリップまたは他のいずれかのコンテンツファイルが小なる部分に分けられず、異なるタイムスロットに分散して送信されないことを意味する。よって、静的部分４０１は、２分の継続時間（クリップＣの中間部にあたる）を有すると画定されるが、静的部分４０１は、クリップＣ全体を含むように一時的に延長される。言い換えると、静的部分は、２分の最短の継続時間を有する。結果として、クリップＢ及びＣは、ＥＳＧ７０１において前回に決定されたように送信のためにスケジューリングされる。しかしながら、図１３から分かるように、動的部分４１０のクリップＤ、Ｅ及びＦの送信の動的優先順位を再計算する際に、クリップＦは、ここでクリップＤ及びＥより前に送信のためにスケジューリングされる。よって、例えばクリップＤは、ここで、ＥＳＧ７０１においてクリップＤが有した送信順序または優先順位以外の、異なる送信順序または優先順位をＥＳＧ７０２において有する。
【００５４】
最後に、次のスケジューリング間隔において、スケジューラ２４０は、クリップＣ、Ｄ、Ｅ、Ｆ及びＧが送信に利用可能であると判断する（クリップＢは送信された）。更に、スケジューラ２４０は、前回のスケジュール（ＥＳＧ７０２）が存在したと判断して、静的部分４０１を決定する。しかしながら、静的部分４０１はクリップＣを含むだけなので、ここで静的部分４０１は２分に戻される。よって、クリップＣは、ＥＳＧ７０２において前回に決定された様に、送信するようにスケジューリングされる。しかしながら、図１３から分かるように、動的部分４１０において、クリップＤ、Ｅ、Ｆ及びＧの送信の動的優先順位を再計算する際に、動的部分４１０において、クリップＧは、ここで、クリップＦ、Ｄ及びＥより先に送信するようにスケジューリングされる。よって、例えばクリップＦはここで、ＥＳＧ７０２においてクリップＦが有した送信順序または優先順位以外の異なる送信順序または優先順位、ＥＳＧ７０３を有する。
【００５５】
上記を考慮して、時間のあらゆる時点でスケジューラによって生成されるスケジュールは２つの部分を有する。現在のスケジュールの静的部分は、対応する時点において前回のスケジュールにあったイベントを有する。スケジュールの静的部分はまた、スケジュールが移動するにつれて、時間ライン上で前に進む。言い換えると、３０秒の静的継続時間がある場合、時間インスタンスｔにおいて作られたスケジュールは時間ｔから時間ｔ＋３０までの静的部分を有し、ｔ＋１秒につくられたスケジュールは、ｔ＋１からｔ＋３１の静的部分を有する。
【００５６】
再スケジュールが生じるときはいつも、新しい再スケジュール変更は、ｔ＋静的持続時間から始まるスケジュールの動的部分に進む。ここで、ｔは再スケジュールの時間インスタンスである。新しいスケジュールの静的部分は、前回のスケジュールから、ｔからｔ＋静的な継続時間の期間に対応するイベントを取り入れることによって作られる。固定された継続時間を静的部分（例えば３０秒）について構成することができたとしても、正確な静的部分は、図１３のＥＳＧ７０１、７０２及び７０３に関して、上記に示したように、静的部分におけるクリップの継続時間により変化し得る。
【００５７】
スケジュールの静的継続時間を、ある期間にわたって調整することができる。静的継続時間は、端末が必要とする最短スケジュール更新間隔に等しいことが理想的である。再スケジューリング間隔は、また、必要な場合、調整されて、新しいスケジュールを処理及び送信する際にあらゆるオーバヘッドを収容することができる。よって、あらゆるスケジュール変更は端末に送信され、一方、端末は、不変である静的部分に依存することができる。
【００５８】
ここで、図１４を参照すると、本発明の原理によるレシーバ１００の例示的な実施形態が示されている。レシーバ１００の本発明の概念に関係する部分だけが示されている。レシーバ１００は、例えばＰＣ、携帯情報端末（ＰＤＡ）、携帯電話、モバイルデジタルテレビ（ＤＴＶ）等のあらゆるプロセッサベースのプラットフォームを表すものである。この点で、レシーバ１００は、図１４の破線のボックスの形で示されているプロセッサ８９０及びメモリ８９５で表されるような、１つまたは複数のプロセッサ及び付随するメモリを含む。この内容において、コンピュータプログラム、またはソフトウェアは、プロセッサ８９０による実行のためにメモリ８９５に格納される。後者は１つまたは複数の蓄積プログラム制御プロセッサを表すものであり、これらは、レシーバ機能専用に設けられる必要はない。例えば、プロセッサ８９０が、レシーバ１００の他の機能を制御することもできる。メモリ８９５は、ランダムアクセスメモリ(ＲＡＭ)、リードオンリメモリ(ＲＯＭ)等のあらゆる記憶装置を表現するものであり、レシーバ１００に内臓であってもよいしかつ／または外付けであってもよい。更に、必要に応じて揮発性及び／または不揮発性である。レシーバ１００は、ＤＶＢ−Ｈレシーバ８１０、ＩＰ非カプセル化装置８１５及びＦＬＵＴＥレシーバ８２０を含む。これらの構成要素のいずれかまたは全ては、プロセッサ８９０及びメモリ８９５で表示されるように、ソフトウェアで実行されてもよい。ＤＶＢ−Ｈレシーバ８１０は、アンテナ８０５を介して（図６の）ＤＶＢ−Ｈ信号１８６を受信し、ＩＰ非カプセル化装置８１５に復調信号を出力する。後者は、ＦＬＵＴＥレシーバ８２０にＡＬＣパケットを出力し、ＦＬＵＴＥレシーバ８２０は、信号８２１で表示されるようにコンテンツをリカバリする。このコンテンツは、（楕円８３０で表示されるように）当該技術分野で周知のようにレシーバ１００で更に処理されてもよい。上記のようにかつ本発明の原理に従って、プロセッサ８９０は、選択されたクリップ（コンテンツ）を識別する際に用いるために静的部分及び動的部分を有するＥＳＧをリカバリする。この例では、ＦＬＵＴＥレシーバ８２０及びＤＶＢ−Ｈレシーバ８１０は、制御信号８０９及び８１９で表示されるようにプロセッサ８９０によって電源をオン／オフされ、少なくとも選択されていないコンテンツレシーバ１００の一部は減少した電力で動作する。このように、プロセッサ８９０は、少なくともＥＳＧの動的部分に対応して、受信したプログラムガイドで表される選択されたコンテンツの受信をスケジューリングする。
【００５９】
本発明の原理によるレシーバ９００の別の例示的な実施形態が、図１５に示されている。レシーバ９００の本発明の概念に関する部分だけが示されている。レシーバ９００は、ＤＶＢ−Ｈレシーバ９１０、変調器／復号器９１５、トランスポートプロセッサ９２０、コントローラ９５０及びメモリ９６０を含む。例えば、アナログ・デジタル変換器、フロントエンドフィルタ等のレシーバの他の構成要素は、簡単にするために示されていないことに注意しなければならない。トランスポートプロセッサ９２０及びコントローラ９５０の両方は、１つまたは複数のマイクロプロセッサ及び／またはデジタル信号プロセッサ（ＤＰＳ）を表すものであり、プログラムを実行しかつデータを格納するためのメモリを含むことができる。この点で、メモリ９６０は、レシーバ９００のメモリを表示するものであり、例えば、トランスポートプロセッサ９２０及び／またはコントローラ９５０のあらゆるメモリも含む。例示的な双方向性のデータ及び制御バス９０１は、示されるようにレシーバ９００の要素のうちの様々な要素を結合する。バス９０１は、例えば、（並列及び／または直列の形式で）個々の信号が、例えば、レシーバ９００の要素同士の間でデータ及び制御信号を運ぶために用いられてもよいといったことを単に表すものである。ＤＶＢ−Ｈレシーバ９１０は、ＤＶＢ−Ｈ信号９０９を受信して、復調器／復号器９１５にダウンコンバートしたＤＶＢ−Ｈ信号９１１を出力する。復調器／復号器９１５は信号９１１の復調及び復号を行って、トランスポートプロセッサ９２０に復号化信号９１６を出力する。トランスポートプロセッサ９２０は、パケットプロセッサであって、リアルタイムプロトコルスタック及びＦＬＵＴＥ／ＡＬＣプロトコルスタックの両方を実施して、ＤＶＢ−Ｈによるリアルタイムコンテンツまたはファイルベースのコンテンツのいずれかをリカバリする。トランスポートプロセッサ９２０は、コンテンツ信号９２１で表されるように、コンテンツを（楕円９９１で表示されるような）適当な次の回路に出力する。コントローラ９５０は、上記のフローチャートにより、バス９０１を介して、トランスポートプロセッサ９２０を制御し、メモリ９６０の記憶装置のために図１３のＥＳＧで示されるようにＥＳＧ情報をリカバリする。コントローラ９６０は、選択されたクリップ（コンテンツ）のために受信したＥＳＧの静的部分及び動的部分に応じて、制御信号９５１、９５２、及び９５３を用いて（バス９０１を介して）本発明の原理による、トランスポートプロセッサ９２０、ＤＶＢ−Ｈレシーバ９１０及び復調器／復号器９１５のパワーマネジメントを行なう。このように、コントローラ９６０は、ＥＳＧの少なくとも動的部分に対応して、受信したプログラムガイドにおいて示された選択されたコンテンツの受信をスケジューリングする。
【００６０】
レシーバ１００またはレシーバ９００のいずれかに用いられる例示的なフローチャートが、図１６に示されている。ステップ５０５において、レシーバは、静的部分及び動的部分を有するＥＳＧを受信する。静的部分において示されるコンテンツの送信順序は、前回に受信したプログラムガイドの対応するコンテンツの送信順序から決定され、一方、動的部分において示されるコンテンツの送信順序は、前回に受信したプログラムガイドの対応するコンテンツの送信順序と異なっていてもよい。例えば、レシーバは、図１３のＥＳＧ７０２を受信する。ＥＳＧ７０２において、静的部分４０１において示されるコンテンツの送信順序は、ＥＳＧ７０１から決定され、一方、動的部分４１０において示されるコンテンツの送信順序は、ＥＳＧ７０１で示されたように、前回に受信したプログラムガイドの対応するコンテンツの送信順序と異なっている。例えば、ＥＳＧ７０１（前回に受信したプログラムガイド）において、クリップＤ及びＥは、それぞれ、４分及び５分に送信するようにスケジューリングされていた。しかしながら、ＥＳＧ７０２において、送信順序は、クリップＤ及びＥがここでそれぞれ５分及び６分で送信されるようにスケジューリングされるように変更されたことが分かる。図１６に戻ると、ステップ５１０において、レシーバは、例えば、ＥＳＧの動的部分が前回に受信したＥＳＧから変更されたかどうかを、前回に受信したＥＳＧとの比較によって、またはＥＳＧのバージョン番号（図示せず）を用いて判断する。ＥＳＧの動的部分が変更された場合、レシーバは必要に応じてステップ５１５においてあらゆるパワーマネジメントスケジュールを更新する。例えば、クリップＤがレシーバにおいて選択されたコンテンツである場合、ＥＳＧ７０１を受信すると、レシーバは、ｔ＝４分において受信をスケジューリングする。しかしながら、ＥＳＧ７０２を受信した後に、レシーバは、プログラムガイドの動的部分における変更を検出し、ｔ＝５分においてクリップＤで示されるように選択されたコンテンツの受信をここでスケジューリングする。よって、レシーバは、受信したプログラムガイドの少なくとも動的部分における変更に対応して、受信したプログラムガイドにおいて示された選択されたコンテンツの受信をスケジューリングする。
【００６１】
便宜主義的な帯域幅環境（例えば可変ビットレート（ＶＢＲ））では、出力チャネルの帯域幅は一定でないことにも注意しなければならない。これは、スケジューラによって行われる全てのタイミング計算に影響を及ぼす。このことを説明するために、スケジューラは、帯域幅フィードバックインタフェースを備えていてもよい。このように、スケジューラ２４０は、各クリップの送信継続時間（継続時間＝クリップ／バンド幅の大きさ）を計算するために出力帯域幅をモニタする。該送信継続時間によって、スケジューラが次のクリップをスケジューリングすることができる時刻が決定される。このことは、図１７のサーバ１５０’で示される。サーバ１５０’は、ＦＬＵＴＥセンダ２２０からスケジューラ２４０までのフィードバック通信パス２４４を除いて、図７のサーバ１５０と類似している。結果として、ＦＬＵＴＥセンダ２２０がスケジューラ２４０にフィードバック通信パス２４４を介して送信の完了を通知した時から、スケジューラ２４０は、帯域幅の変化を常にモニタすることができて、該変化を統計的に予測することができる。それゆえに、長期的には、スケジューラがつくるタイミングの予測は、より高い精度を有する。更に、スケジューラは各コンテンツの送信の状態を更新することができる。このことは、ＶＢＲ環境において送信数の計算におけるエラーを最小にするのを助ける。
【００６２】
上記のように、発明の概念は、放送網を介して送信のためのマルチメディアコンテンツファイルをスケジューリングする際の多くの問題に対処している。例えば、本発明の概念は、コンテンツデータベースが、新しいクリップの追加及び／または削除などで、ある期間にわたって変化できるようにする。更に、個々のクリップに付随するオペレータの好みは、時間とともに変化してもよい。更に、スケジューラは、ＣＢＲ（固定ビットレート）またはＶＢＲ（可変ビットレート）出力チャネルに適用可能である。
【００６３】
本発明の概念は、ＤＶＢ−Ｈシステムの内容において説明されたが、本発明の概念はそれに限定されないことに注意しなければならない。更に、本発明の概念は、スケジューリングメタデータの特定の数の要素の内容において説明されたが、本発明の概念は、それに限定されず、追加のフィールド、または、より少ないフィールドがスケジューリングメタデータを含んでいてもよい。また、スケジューラがサーバまたはヘッドエンドの一部として示されたが、本発明はそれに限定されておらず、スケジューラは、サーバと別個であってＥＳＧ及び／またはＦＬＵＴＥセンダにスケジューリング情報を出力してもよい。
【００６４】
上記を考慮して、前述のことは、単に本発明の原理を示すだけであり、よって、当業者は、本明細書において明確に記載されていないが本発明の原理を具体化しかつその趣旨及び範囲内にある多数の代替装置を考案することができるということが認められるだろう。例えば、別個の機能要素についての内容において示されているが、これらの機能要素は１つまたは複数の集積回路（ＩＣ）で具体化されてもよい。同様に、別個の要素として示されているが、（例えば、図７の）いずれかのまたは全ての要素は、デジタル信号プロセッサなどの蓄積プログラム制御プロセッサにおいて実施されてもよい。蓄積プログラム制御プロセッサは、図９、１１及び１２などの１つまたは複数のステップに対応しているといった付随するソフトウェアを実行する。更に、本発明の原理は、衛星システム、ＷｉＦｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）方式、携帯電話等の他の種類の通信システムに適用できる。実際、本発明の概念は、固定型のレシーバまたはモバイルレシーバにも適用できる。従って、多数の変化形を例示的な実施形態について実施することができ、他の装置を本発明の趣旨及び範囲から逸脱することなく考案することができるということが理解されなければならない。
【特許請求の範囲】
【請求項１】
静的部分及び動的部分を有するプログラムを決定するステップと、
前記プログラムガイドを送信するステップと、
を含む方法であって、
前記静的部分に示されるコンテンツの送信順序は、前回に決定されたプログラムガイドにおける対応するコンテンツの送信順序から決定され、一方、前記動的部分に示されるコンテンツの送信順序は、前記前回に決定されたプログラムガイドにおける対応するコンテンツの前記送信順序と異なっていてもよいことを特徴とする方法。
【請求項２】
コンテンツがオーディオクリップまたはビデオクリップであることを特徴とする請求項１に記載の方法。
【請求項３】
前記プログラムガイドが電子サービスガイドであることを特徴とする請求項１に記載の方法。
【請求項４】
前記静的部分は、少なくとも最短の継続時間を有することを特徴とする請求項１に記載の方法。
【請求項５】
静的部分及び動的部分を有するプログラムガイドを決定するプロセッサを含む装置であって、
前記静的部分に示されるコンテンツの送信順序は、前回に決定されたプログラムガイドにおける対応するコンテンツの送信順序から決定され、一方、前記動的部分に示されるコンテンツの送信順序は、前記前回に決定されたプログラムガイドにおける対応するコンテンツの前記送信順序と異なっていてもよく、
前記装置は更に、
前記プログラムガイドを送信するモジュレータを含むことを特徴とする装置。
【請求項６】
コンテンツがオーディオクリップまたはビデオクリップであることを特徴とする請求項５に記載の装置。
【請求項７】
前記プログラムガイドが電子サービスガイドであることを特徴とする請求項５に記載の装置。
【請求項８】
前記静的部分は少なくとも最短の継続時間を有することを特徴とする請求項５に記載の装置。
【請求項９】
受信されたプログラムガイドを表す信号をリカバリする際に用いる復調器を含む装置であって、
前記受信されたプログラムガイドは、静的部分及び動的部分を有し、前記静的部分に示されるコンテンツの送信順序は、前回に受信されたプログラムガイドにおける対応するコンテンツの送信順序から決定し、一方、前記動的部分に示されるコンテンツの送信順序は、前記前回に受信されたプログラムガイドの対応するコンテンツの前記送信順序と異なっていてもよく、
前記装置は更に、
前記受信されたプログラムガイドの少なくとも前記動的部分における変更に対応して、前記受信されたプログラムガイドに示された選択されたコンテンツの受信をスケジューリングするプロセッサを含むことを特徴とする装置。
【請求項１０】
コンテンツがオーディオクリップまたはビデオクリップであることを特徴とする請求項９に記載の装置。
【請求項１１】
前記プログラムガイドが電子サービスガイドであることを特徴とする請求項９に記載の装置。
【請求項１２】
前記静的部分は少なくとも最短の継続時間を有することを特徴とする請求項９に記載の装置。
【請求項１３】
プログラムガイドを受信するステップを含む方法であって、
前記受信されたプログラムガイドは、静的部分及び動的部分を有し、
前記静的部分に示されるコンテンツの送信順序は、前回に受信されたプログラムガイドにおける対応するコンテンツの送信順序から決定され、一方、前記動的部分に示されるコンテンツの送信順序は、前記前回に受信されたプログラムガイドにおける対応するコンテンツの前記送信順序と異なっていてもよく、
前記方法は更に、
前記受信されたプログラムガイドの少なくとも前記動的部分における変更に適合して、前記受信されたプログラムガイドに示された選択されたコンテンツの受信をスケジューリングするステップを含むことを特徴とする方法。
【請求項１４】
コンテンツがオーディオクリップ、またはビデオクリップであることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記プログラムガイドが電子サービスガイドであることを特徴とする請求項１３に記載の方法。
【請求項１６】
前記静的部分は少なくとも最短の継続時間を有することを特徴とする請求項１３に記載の方法。
【請求項１】
静的部分及び動的部分を有するプログラムを決定するステップと、
前記プログラムガイドを送信するステップと、
を含む方法であって、
前記静的部分に示されるコンテンツの送信順序は、前回に決定されたプログラムガイドにおける対応するコンテンツの送信順序から決定され、一方、前記動的部分に示されるコンテンツの送信順序は、前記前回に決定されたプログラムガイドにおける対応するコンテンツの前記送信順序と異なっていてもよいことを特徴とする方法。
【請求項２】
コンテンツがオーディオクリップまたはビデオクリップであることを特徴とする請求項１に記載の方法。
【請求項３】
前記プログラムガイドが電子サービスガイドであることを特徴とする請求項１に記載の方法。
【請求項４】
前記静的部分は、少なくとも最短の継続時間を有することを特徴とする請求項１に記載の方法。
【請求項５】
静的部分及び動的部分を有するプログラムガイドを決定するプロセッサを含む装置であって、
前記静的部分に示されるコンテンツの送信順序は、前回に決定されたプログラムガイドにおける対応するコンテンツの送信順序から決定され、一方、前記動的部分に示されるコンテンツの送信順序は、前記前回に決定されたプログラムガイドにおける対応するコンテンツの前記送信順序と異なっていてもよく、
前記装置は更に、
前記プログラムガイドを送信するモジュレータを含むことを特徴とする装置。
【請求項６】
コンテンツがオーディオクリップまたはビデオクリップであることを特徴とする請求項５に記載の装置。
【請求項７】
前記プログラムガイドが電子サービスガイドであることを特徴とする請求項５に記載の装置。
【請求項８】
前記静的部分は少なくとも最短の継続時間を有することを特徴とする請求項５に記載の装置。
【請求項９】
受信されたプログラムガイドを表す信号をリカバリする際に用いる復調器を含む装置であって、
前記受信されたプログラムガイドは、静的部分及び動的部分を有し、前記静的部分に示されるコンテンツの送信順序は、前回に受信されたプログラムガイドにおける対応するコンテンツの送信順序から決定し、一方、前記動的部分に示されるコンテンツの送信順序は、前記前回に受信されたプログラムガイドの対応するコンテンツの前記送信順序と異なっていてもよく、
前記装置は更に、
前記受信されたプログラムガイドの少なくとも前記動的部分における変更に対応して、前記受信されたプログラムガイドに示された選択されたコンテンツの受信をスケジューリングするプロセッサを含むことを特徴とする装置。
【請求項１０】
コンテンツがオーディオクリップまたはビデオクリップであることを特徴とする請求項９に記載の装置。
【請求項１１】
前記プログラムガイドが電子サービスガイドであることを特徴とする請求項９に記載の装置。
【請求項１２】
前記静的部分は少なくとも最短の継続時間を有することを特徴とする請求項９に記載の装置。
【請求項１３】
プログラムガイドを受信するステップを含む方法であって、
前記受信されたプログラムガイドは、静的部分及び動的部分を有し、
前記静的部分に示されるコンテンツの送信順序は、前回に受信されたプログラムガイドにおける対応するコンテンツの送信順序から決定され、一方、前記動的部分に示されるコンテンツの送信順序は、前記前回に受信されたプログラムガイドにおける対応するコンテンツの前記送信順序と異なっていてもよく、
前記方法は更に、
前記受信されたプログラムガイドの少なくとも前記動的部分における変更に適合して、前記受信されたプログラムガイドに示された選択されたコンテンツの受信をスケジューリングするステップを含むことを特徴とする方法。
【請求項１４】
コンテンツがオーディオクリップ、またはビデオクリップであることを特徴とする請求項１３に記載の方法。
【請求項１５】
前記プログラムガイドが電子サービスガイドであることを特徴とする請求項１３に記載の方法。
【請求項１６】
前記静的部分は少なくとも最短の継続時間を有することを特徴とする請求項１３に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公表番号】特表２０１１−５０３９１７（Ｐ２０１１−５０３９１７Ａ）
【公表日】平成２３年１月２７日（２０１１．１．２７）
【国際特許分類】
【出願番号】特願２０１０−５１９９０４（Ｐ２０１０−５１９９０４）
【出願日】平成２０年６月１７日（２００８．６．１７）
【国際出願番号】ＰＣＴ／ＵＳ２００８／００７５３８
【国際公開番号】ＷＯ２００９／０２０４９２
【国際公開日】平成２１年２月１２日（２００９．２．１２）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公表日】平成２３年１月２７日（２０１１．１．２７）
【国際特許分類】
【出願日】平成２０年６月１７日（２００８．６．１７）
【国際出願番号】ＰＣＴ／ＵＳ２００８／００７５３８
【国際公開番号】ＷＯ２００９／０２０４９２
【国際公開日】平成２１年２月１２日（２００９．２．１２）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]