JP2010536238A - 通信システムにおける方法及び装置 - Google Patents

Abstract

スケジューラは、ブロードキャストネットワークを介して送信するマルチメディアコンテンツファイルのスケジュールを立てる。マルチメディアコンテンツファイルは、如何なる種類のオーディオ／ビデオクリップでもよく、例えば、スポーツビデオ、音楽ビデオ、ニュースクリップ、映画サウンドトラック等である。特に、スケジューラは、コンテンツファイルの送信順序を動的な優先度の関数として決定し、その優先度は、コンテンツファイル同士の相違度合いに少なくともしたがって決定され、マルチメディアコンテンツファイルの相違度合いは、クリップ各々に関連するクリップメタデータの関数としてさらに決定される。スケジュール時間情報及びメタデータ情報が、クリップとともにブロードキャストネットワークを介して伝送され、受信機は、各自の好みのクリップを選択的に受信し、バッテリ電力及びストレージを節約できる。

Description

本発明は、一般に通信システムに関連し、特に、地上放送、セルラ、ワイヤレスフィデリティ（Wi−Fi）、衛星等を使用するような無線システムに関連する。

今日、移動装置は、MP3プレ−ヤからパ−ソナルディジタルアシスタント、セルラ電話、モバイルテレビジョン（TV）等に至るまで、様々な場所に存在する。不都合なことに、通常、移動装置は演算リソ−ス及び／又はパワ−に関して制約を有する。携帯機向けディジタルビデオ放送（DVB−H）システムにおけるインタ−ネットプロトコル（IP）デ−タキャストは、そのような装置に最適なIPベ−スの仕組みを利用して、如何なるタイプのファイルやサ−ビスをも配信するエンドトゥエンドのブロ−ドキャストシステムである。これについては、例えば、非特許文献１ないし４に記載されている。

図１には、当該技術分野で既知のDVB−HシステムにおけるIPデ−タキャストの例が示されている。図１では、ヘッドエンド10（「サ−バ」とも言及される）が、アンテナ35を介して、受信機90として表現されているような１つ以上の受信装置（「クライアント」又は「受信機」とも言及される。）へ、DVB−H信号36をブロ−ドキャストしている。DVB−H信号36は、クライアントへのIPデ−タキャストを運ぶ。受信機90は、（不図示の）アンテナを介してDVB−H信号36を受信し、それによりIPデ−タキャストを復元する。図１のシステムは、片方向（unidirectional）のネットワ−クを表す。

上記のIPデ−タキャストは、電子サ−ビスガイド（ESG）及びコンテンツファイルのようなファイルを配信することで、コンテンツベ−スのサ−ビスを提供するのに使用される。図１の場合、コンテンツベ−スのサ−ビスは、例えばテレビジョン（TV）番組のようなリアルタイムのコンテンツとすることもできるし、あるいは典型的にはTV番組より短いショ−トフォ−ム（short−form）コンテンツのようなファイル形式のコンテンツとすることもできる。ESGは、コンテンツ形式のサ−ビスを選択し、選択したコンテンツを受信機が復元することを可能にする能力をユ−ザに与える。この点に関し、ESGは、通常、コンテンツに関する説明のようなデ−タ又はメタデ−タを含む（「コンテンツ」はイベント（event）としても言及される。）。このメタデ−タは「コンテンツメタデ−タ」のように言及され、これは例えば、TV番組名、概要（粗筋）、俳優、ディレクタ等を予定日時、持続時間及び放送のチャネルとともに含んでいる。ESGが指定する適切なチャネルに受信機90を同調することで、受信機90のユ−ザは、ESGで参照されているコンテンツを受信することができる。例えば、TV放送のようなリアルタイムコンテンツの場合、ESGは、セッション記述プロトコル（SDP）ファイルを含む留意を要する（これについては、非特許文献５に記載されている。）。SDPファイルは、選択されたブロ−ドキャストコンテンツに受信機90が同調することを可能にする付加的な情報を含む。

ファイル形式のコンテンツの場合、図１のヘッドエンド10は、FLUTE（File Delivery over Unidirectional Transport）プロトコルを用いてファイルを配信する（これについては、例えば、非特許文献６に記載されている。）。FLUTEプロトコルは、ファイルやデ−タを片方向ネットワ−クを介して伝送し、マルチキャストファイル配信機能を発揮するために使用される。この場合、ヘッドエンド10は、FLUTEの基本的な通信として、非同期階層化コ−ディング（ALC: Asynchronous Layered Coding）プロトコルを利用することが、仮定されている（この点については、非特許文献７に記載されている。）。ALCプロトコルは、任意のバイナリオブジェクトを配信するように設計されている。これは、大量のスケ−ラブルな片方向のマルチキャスト配信に特に適している。

図２を概観するに、FLUTEを使用するファイル形式のコンテンツ伝送の様子が示されており、ヘッドエンド10がESGをブロ−ドキャストしている。他のファイル形式のコンテンツの伝送も同様であるが、ここでは図示されていない。ヘッドエンド10は、ESG生成部15、FLUTE送信部20、IPカプセル化部25及びDVB−Hモジュレ−タ30を有する。当該技術分野で既知であるように、ESG生成部15は、ESGをFLUTE送信部20に与え、FLUTE送信部20はALCを使用するFLUTEにしたがってESGをフォ−マットし、その結果のFLUTEファイルを運ぶALCパケットをIPカプセル下部25に与え、IPカプセル化部はIPパケットによるカプセル化を行う。結果のIPパケットは、DVB−Hモジュレ−タに与えられ、図１に示されるような１つ以上の受信機への送信に備える。受信機は、特定のFLUTEチャネル（例えば、IPアドレス及びポ−ト番号）に同調し、受信機で使用するESGを復元する。

上述したように、受信機には例えばバッテリ寿命のような電力の制約がある。さらに、ブロ−ドキャストネットワ−クにおける受信機は、特定の又は選択されたファイル形式のコンテンツを特定の時点で受信するだけかもしれない。その他の時点では、受信機は、完全に起動しているが、ブロ−ドキャストネットワ−クから送信された他の如何なるコンテンツも処理しない。したがって、FLUTE送信機（例えば、図２のヘッドエンド10のFLUTE送信部20）及びFLUTE受信機（図１の受信機90のFLUTE受信部（図示せず））が時間的に同期し、選択された情報が受信されていない期間の間、受信機がパワ−を節約し、受信機のバッテリ寿命を延ばすことが有益である。図３は、時間的な同期をとる１つの方法を示す。特に、図３の場合、ネットワ−ク時間プロトコル（NTP: Network Time Protocol）サ−バ45によりヘッドエンド10及び受信機90間の時間的な同期をとっている。この場合、（ヘッドエンド10の）FLUTE送信部20は、時間及び日付テ−ブル（TDT）を用意し（これについては、上記の非特許文献２に説明されている。）、そのTDTはNTPサ−バ45からのNTPタイムスタンプを含んでいる。ヘッドエンド10は、TDTをDVB−H信号36によりブロ−ドキャストする。そして、受信機90は受信したそのNTPタイムスタンプを使用して、特定の時点における選択されたコンテンツを探す。あるいは、ヘッドエンド10は、ライブサ−ビスブロ−ドキャストに含まれているリアルタイムトランスポ−トコントロ−ルプロトコル（RTCP）センダ−レポ−トによりNTPタイムスタンプを受信機90に提供してもよい（この点については、例えば非特許文献８に記載されている。）。

ETSI EN 302 304 V1.1.1 （2004−11） "Digital Video Broadcasting （DVB）; Transmission System for Handheld Terminals （DVB−H）" ETSI EN 300 468 V1.7.1 （2006−05） "Digital Video Broadcasting （DVB）; Specification for Service Information （SI） in DVB systems" ETSI TS 102 472 V1.1.1 （2006−06） "Digital Video Broadcasting （DVB）; IP Datacast over DVB−H: Content Delivery Protocols" ETSI EN 102 471 V1.1.1 （2006−04） "Digital Video Broadcasting （DVB）; IP Datacast over DVB−H: Electronic Service Guide （ESG）" M.Handley, V.Jacobson, April 1998 − "RFC 2327 − SDP: Session Description Protocol" T. Paila, M. Luby, V. Roca, R. Walsh,"RFC 3926 − FLUTE − File Delivery over Unidirectional Transport," October 2004 Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. Crowcroft, "Asynchronous Layered Coding （ALC） Protocol Instantiation", RFC 3450, December 2002 Audio−Video Transport Working Group, H. Schulzrinne, GMD Fokus S. Casner, Precept Software, Inc., R. Frederick, Xerox Palo Alto Research Center, V. Jacobson, January 1996 − "RFC 1889 RTP: A Transport Protocol for Real − Time Applications"

（図１に示されるような）片方向ブロードキャストネットワークは、マルチメディア又はデータコンテンツのスケーラブルブロードキャストにとって理想的な選択肢である。ブロードキャストネットワークは、マルチメディアコンテンツ伝送及びストリーミングに特に広く使用されている。しかしながら、この種のネットワークには、受信機に１対１サービスを提供する機能が不足しており、受信機の好みの情報を送信機に通知するような受信機のりバースチャネルが一切備わっていない。

ブロードキャストネトワークで機能するプッシュビデオオンデマンド（VOD： Video On Demand）のような種類のサービスを提供するため、送信機は、最大数の受信機がそれらの好みのコンテンツを取得するようにしなければならない。さらに、コンテンツプロバイダ及びオペレータは、送信の際に彼ら自身の優先度を有するであろう。「オペレータ」（サービスプロバイダとも言及される）は、ブロードキャストサービスを決定し、サービスのコンテンツを提供する存在又はエンティティである。「コンテンツプロバイダ」は、特定のサービス又はサービス群についてコンテンツを生成する存在又はエンティティである。

したがって、本発明の原理によれば、ヘッドエンドは、コンテンツファイルの送信順序を動的な優先度の関数として決定し、その優先度は、コンテンツファイル同士の相違度合いに少なくともしたがって決定され、ヘッドエンドは、決定された送信順序にしたがってコンテンツファイルを送信する。

本発明の代替例では、コンテンツファイルは、如何なる種類のオーディオ／ビデオクリップでもよく、例えば、スポーツビデオ、音楽ビデオ、ニュースクリップ、映画サウンドトラック等であり、「クリップメタデータ」が各々のクリップに関連付けられる。ヘッドエンドは、コンテンツファイルの送信順序を動的な優先度の関数として決定するスケジューラを含み、その優先度は、コンテンツファイル同士の相違度合いに少なくともしたがって決定され、コンテンツファイルの相違度合いは、クリップ各々に関連するクリップメタデータの関数としてさらに決定される。スケジュール時間情報及びメタデータ情報が、クリップとともにブロードキャストネットワークを介して伝送され、受信機は、各自の好みのクリップを選択的に受信し、バッテリ電力及びストレージを節約できる。

上記に関し、詳細な説明を理解することでさらに明らかになるように、他の実施例や特徴も可能であり、それらも本発明に包含される。

DVB−Hシステムにおける従来のインターネットプロトコル（IP）データキャストを示す図。 DVB−Hシステムにおける従来のインターネットプロトコル（IP）データキャストを示す図。 DVB−Hシステムにおける従来のインターネットプロトコル（IP）データキャストを示す図。 図１ないし３のシステムにおけるファイル形式のコンテンツ伝送及びESGの関連するフラグメントを示す図。 図１ないし３のシステムにおけるファイル形式のコンテンツ伝送及びESGの関連するフラグメントを示す図。 本発明原理によるシステム例を示す図。 本発明原理によるサーバ例を示す図。 本発明原理によるスケジューリングメタデータ例を示す図。 サーバ50において使用する本発明原理による例示的なフローチャート。 本発明原理によるスケジュール例を示す図。 サーバ50において使用する本発明原理による他の例示的なフローチャート。 サーバ50において使用する本発明原理による他の例示的なフローチャート。 本発明原理による他のスケジュール例を示す図。 本発明原理による受信機の例を示す図。 本発明原理による受信機の例を示す図。 受信機において使用する本発明原理による例示的なフローチャート。 本発明原理による他のサーバの例を示す図。

発明概念以外の図中に示される要素は既に知られており、詳細には説明されない。例えば、発明概念以外の周知のディスクリートマルチトーン（DMT）伝送（直交周波数分割多重化（OFDM）又は符号化直交周波数分割多重（COFDM））が想定されているが、ここでは説明されない。テレビジョン放送、受信機及びビデオエンコーディング等の周知事項が想定されているが、ここでは説明されない。例えば、発明概念とは別の周知の現在及び提案中のTV標準仕様に関する推奨（例えば、NTSC（National Television Systems Committee）、PAL（Phase Alternation Lines）、SECAM（Sequential Couleur Avec Memorie）及びATSC（Advanced Television System Committee））が仮定されている。同様に、発明概念とは別に、他の伝送方式（例えば、８レベル残留側波帯（8−VSB））、直交振幅変調（QAM）、無線周波数（RF）フロントエンド（例えば、低雑音ブロック、チューナ、ダウンコンバータ等）、復調部、相関部、リークインテグレータ（leak integrator）及び二乗部等のような受信要素が想定されている。さらに、発明概念とは別に、FLUTEプロトコル、非同期階層化コーディング（ALC）プロトコル、インターネットプロトコル（IP）及びインターネットプロトコル円キャプスレータ（IPE）等のような周知のプロトコルが想定されているが、ここでは説明されない。同様に、発明概念とは別に、送信ビットストリームを生成するためのフォーマット化及び符号化方法（例えば、MPEG-2システム標準仕様（ISO/IEC13818−1）も周知であり、ここでは説明されない。周知のPull-VOD及びPush-VODサービスも想定されている。Pull-VODサービスの場合、ユーザは特定のビデオクリップを要求し、サーバがそれをその特定のユーザに送信する。Push-VODサービスの場合、ユーザの好みのビデオは、ユーザが能動的にビデオを要求することなしに、受信機の中に押し込まれる（保存される）。本発明概念は従来のプログラミング技法（すなわち、本願では説明されないプログラミング技法）を用いて実現されてもよい。そして、図中、同様な番号は同様な要素を表す。

本発明概念を説明する前に、DBV−Hにおける従来のファイル形式のコンテンツ伝送の様子を図４に示す。図４おいて、DVB−Hにおけるファイル形式のコンテンツ送信信号は、クリップ50、51、52及び53により表されているような複数のイベント（本願ではクリップとして言及される）を有する。クリップの各々は複数のパケットを含むが、そのこと自体は本発明概念に関連していない。ESGは、各クリップを開始時間及び終了時間に関連付け、対応するFLUTEセッションにおける関連するコンテンツファイルを特定する。クリップ51に関するESG（ESGフラグメント60）のフラグメントが、図４に示されている。簡明化のため、他のESGデータは図示されていない。図４に示されているように、ESGフラグメント60は、コンテンツロケーション（ContentLocation）パラメータ65及び公表開始時間（PublishedStartTime）パラメータ61、公表終了時間（PublishedEndTime）パラメータ62をクリップ51に関して含んでいる。この例の場合、対応するFLUTEセッションにおける関連するコンテンツファイルは、「Clip1.mp4」である。PublishedStartTime63及びPublishedEndTime64それぞれに対する実際の値は、協定世界時間（UTC）で表現される。PublishedStartTimeの値は、FLUTE送信機がファイルを実際に送信し始める時間であり、すなわち、クリップがシステム内の経路の中でFLUTE送信機から次のブロックに渡される時間である。DVB−Hシステムに関し、この様子が図５にさらに示されており、PublishedStartTimeの値は、FLUTE送信部20がクリップをIPカプセル化部25に渡す（ハンドオフする）時間である。

上述したように、ブロードキャストネットワークで動作するプッシュVODサービスを行うため、送信部は、最大数の受信機が各自の好みのコンテンツを取得するようにする必要がある。さらに、コンテンツプロバイダ及びオペレータは、送信に関して彼ら自身の優先度も有する。「オペレータ」（サービスプロバイダとも言及される）は、ブロードキャストサービスを決定し、サービスのコンテンツを提供する存在又はエンティティである。「コンテンツプロバイダ」は、特定のサービス又はサービス群についてコンテンツを生成する存在又はエンティティである。

このように、プッシュVODサービスにより送信するコンテンツを提供及びスケジューリングすることに関し、多くの問題又は検討事項がある。例えば、コンテンツデータベースは時間とともに変化する可能性があり、オペレータの好みについても新たなクリップの追加とともに変わる可能性がある。したがって、優先度に基づくクリップ送信のスケジューリングは、ブロードキャストするようになされたスケジューリングから興味の少ないクリップを漠然とブロックする（妨げる）ので、新たなクリップが追加されると適切には実行できない。

さらに、スケジュールの予測可能性は別の重要事項である。クリップの追加や削除に起因して、あるいは優先度の変更でさえそれに起因して、スケジュールはどの時点においても変わる可能性がある。しかしながら、片方向ネットワーク環境の場合、受信端末は、好みのコンテンツが時間どおりに受信されるスケジュールを非常に当てにしている。スケジュールが予測可能でなかった場合、受信機は常にその状態のままでいなければならず、不要な電力を消費してしまう。さらに、片方向ネットワークの場合、受信機は欠落したファイルについて送信部に通知する手段を一切持っていない。したがって、スケジュールの予測可能性は受信機の動作にとって非常に重要である。

さらに、受信機における好みの設定は、ユーザの個人的な興味、受信機の場所、受信する時間等により変わる可能性がある。例えば、マルチメディアクリップのブロードキャストの場合、視聴者は、非常に好ましいクリップを何度も取得するよりも、新しいクリップを取得することの方を好んでいることが見受けられる。しかしながら、ブロードキャストプッシュVODサービスの場合、好みの設定を速やかに考慮に入れることが可能なリバースチャネルは存在しない。このため、マルチメディアクリップの送信スケジュールを更新する場合、何らかのスケジューリングがそのような問題に対処すべきである。

上記の問題に関し、本発明原理によるスケジューラが以下に説明され、それはプッシュサービスが上記の問題に対処できるようにする。したがって、本発明の原理によれば、ヘッドエンドは、コンテンツファイルの送信順序を動的な優先度の関数として決定し、その優先度は、コンテンツファイル同士の相違度合いに少なくともしたがって決定され、ヘッドエンドは、決定された送信順序にしたがってコンテンツファイルを送信する。

本発明の代替例では、コンテンツファイルは、如何なる種類のオーディオ／ビデオクリップでもよく、例えば、スポーツビデオ、音楽ビデオ、ニュースクリップ、映画サウンドトラック等であり、「クリップメタデータ」が各々のクリップに関連付けられる。ヘッドエンドは、コンテンツファイルの送信順序を動的な優先度の関数として決定するスケジューラを含み、その優先度は、コンテンツファイル同士の相違度合いに少なくともしたがって決定され、コンテンツファイルの相違度合いは、クリップ各々に関連するクリップメタデータの関数としてさらに決定される。スケジュール時間情報及びメタデータ情報が、クリップとともにブロードキャストネットワークを介して伝送され、受信機は、各自の好みのクリップを選択的に受信し、バッテリ電力及びストレージを節約できる。

図６を参照するに、本発明原理によるシステム例が示されている。この例に関し、本発明原理とは別に、図６に示されているシステムは、図１に示されているのと同様なDVB−HシステムにおけるIPデータキャストを行う。本発明原理によれば、ヘッドエンド150は、マルチメディアコンテンツファイルに関連する説明データ（記述データ）を分析し、そのマルチメディアコンテンツファイルの送信順序を決定し；決定した送信順序に従って、アンテナ185を介してマルチメディアコンテンツファイルを送信する。特に、ヘッドエンド150は、IPデータキャストをブロードキャストするためのDVB−H信号186を、１つ以上の受信装置（「クライアント」又は「受信機」とも言及される）にブロードキャストし、受信装置は、ラップトップコンピュータ100−1、パーソナルディジタルアシスタント（PDA）100−2及びセルラ電話100−3の何れかにより示され、これら各々は、DVB−H信号を受信し、そのブロードキャストIPデータキャストからリアルタイムのコンテンツ及びファイル形式のコンテンツを復元するように構築されているものとする。図６のシステムは、片方向ネットワークを表している。しかしながら、本発明概念はそれに限定されない。

図７には、本発明原理によるヘッドエンド又はサーバ150の例が示されている。図7に示されているようその内、発明概念以外のものについては周知であり、ここでは説明しない。ヘッドエンド150は、プロセッサを使用するシステムであり、１つ以上のプロセッサ及び関連するメモリを含み、これらは図７の破線枠内に示されているプロセッサ190及びメモリ195により示されている。この場合において、プロセッサ190による実行に備えて、例えばスケジューラ240を実現するために、コンピュータプログラム又はソフトウエアがメモリ195内に格納されている。プロセッサ190は、１つ以上の格納済みのプログラムによる制御プロセッサを表し、これらはスケジューリングの機能に専用である必要はなく、例えばプロセッサ190はヘッドエンド150の他の機能を制御してもよい。メモリ195は、例えばランダムアクセスメモリ（RAM）やリードオンリメモリ（ROM）等のような何らかのストレージデバイスを表現しており、ヘッドエンド150の内部にあっても外部にあってもよく、必要に応じて揮発性でも不揮発性でもよい。

ヘッドエンド150は、ESG生成部215、FLUTE送信部220、IPカプセル化部225、DVB−Hモジュレータ230、コンテンツデータベース235及びスケジューラ240を有する。ESG生成部215、FLUTE送信部220、IPカプセル化部225及びDVB−Hモジュレータ230については、図２に示される対応する要素と同様であり、ここで更には説明しない。本発明概念とは別に、後述するように、当該技術分野で知られているように、ESG生成部215はESGをFLUTE送信部220に提供し、FLUTE送信部はALCにおけるFLUTEにしたがってESGのフォーマットを整え、FLUTEファイルを搬送する結果のALCパケットを、IPパケットにカプセル化するためにIPカプセル化部225に提供する。結果のIPパケットは、DVB−Hモジュレータ230に提供され、図６に示されている１つ以上の受信装置への送信に備える。受信機（例えば、図６の受信機100−2）は、特定のFLUTEチャネル（例えば、IPアドレス及びポート番号）に同調し、受信機で使用するESGを復元する。

図７に示されているように、ヘッドエンド150はコンテンツデータベース及びスケジューラ240も有する。コンテンツデータベース235は、コンテンツ（すなわち、マルチメディアコンテンツファイル）を格納している。これらのマルチメディアコンテンツファイルは、如何なる種類のオーディオ／ビデオクリップでもよく、例えば、スポーツビデオ、音楽ビデオ、ニュースクリップ、映画サウンドトラック等でもよい。本発明概念とは別に、これらのクリップは、信号238によりFLUTE送信部220に提供され、図４に関して説明したようにDVB−Hにおけるファイル形式のコンテンツ送信信号として送信される。クリップ各々にはコンテンツメタデータが関連付けられる。各クリップのコンテンツメタデータは、ESG生成部215に与えられ、かつ本発明原理にしたがって、信号236を介してスケジューラ240に与えられる。スケジューラ240は信号239によりコンテンツデータベース235を制御及び管理する。これにより、スケジューラ240はコンテンツデータベース235に関する変化を検出する、例えば、クリップのコンテンツメタデータを変更することによる追加／削除又は変更を検出する。

本発明原理によれば、スケジューラ240は、コンテンツデータベース235に格納されているクリップに関連するコンテンツメタデータを分析し、マルチメディアコンテンツファイルの送信順序を決定する。この点に関し、スケジューラ240は、制御信号242によりFLUTE送信部220に対して送信順序を制御する。さらに、スケジューラ240は、信号241により、追加的なスケジューリング情報をESG生成部215に提供し、そのスケジューリング情報は受信機に送信されるESGを形成するのに使用される。この追加的なスケジューリング情報は、「スケジューリングメタデータ」として言及される。特に、図８に示されるように、クリップ各々に付随するコンテンツメタデータに加えて、スケジューラ240はスケジューリングメタデータを加える。スケジューリングメタデータ200は、いくつものフィールドを有する（動的な優先度（ダイナミックプライオリティ）201、送信回数202、待ち時間203及び選択的なキーワード204（図中、破線で示されている））。かくて、クリップ各々について、コンテンツメタデータ210に加えてスケジューリングメタデータが存在する。図８に示されているように、これはクリップメタデータ全体220として言及されている。コンテンツメタデータ210は、コンテンツデータベース235に格納される。コンテンツメタデータ210は、コンテンツID211、優先度212、記述（説明）213及び選択的なキーワード214（図中、破線枠で示されている）を有する。一例として、メタデータを表現するために、XML（拡張可能マークアップ言語）が使用されてもよい。コンテンツメタデータ210に関し、コンテンツID211は、コンテンツデータベース235の中でクリップ各々を特定する固有の数的な識別子である。優先度212は、特定のクリップの優先度を表す数値である。記述（説明）213は、例えば、予定されている放送時間、放送日、継続時間、及び放送チャネルに加えて、TV番組名、あらすじ、俳優、ディレクタ等である。そして、キーワード214は英数字の語のリストであり、特定のクリップのコンテンツを簡単に記述する１つ以上のキーワードを表す。

スケジューリングメタデータに関し、動的優先度（ダイナミックプライオリティ）201は、指定されたクリップをブロードキャスト又は送信する際の実際の優先度を表す数値である。送信回数202は、指定されたクリップのブロードキャスト又は送信されている回数を表す数値である。待ち時間203は、指定されたクリップが最後にブロードキャストされて以来経過している秒数を表す数値である。そして、キーワード204は、英数字の語のリストであり、指定されたクリップ内のコンテンツを簡単に記述する１つ以上のキーワードを表す。上述したように、キーワードは、スケジューリングメタデータ200内にあってもよいし、あるいはコンテンツメタデータ210内にあってもよい。前者の場合、キーワード204は、記述213を分析するスケジューラ240により決定される。後者の場合、キーワード214は、コンテンツメタデータ210の一部としてオペレータにより設定される。

図９を参照するに、本発明原理によるスケジューリング方法例が示されている。ステップ305において、スケジューラ240は、スケジュールの静的部分（後述）に加えて、スケジューリングの頻度fs316を初期化及び決定する。スケジューリング頻度fs316は、一例として、スケジュールの静的部分であるように事前に決定されており、例えば、それらは図７のメモリ195に保存されている値である。これらの値は信号243によって（例えば、ブロードキャスト／コンソール（不図示）を介して）オペレータにより設定することもできる。スケジューリング頻度fs316は、スケジュールがどの程度頻繁に生成されるかを決める。ステップ310において、スケジューラ240は、コンテンツデータベース235に保存されているクリップのコンテンツメタデータを抽出する。

ステップ315において、スケジューラ240は、スケジューリング頻度fs316により決定される、スケジュールを生成する時間になったか否かを確認する。スケジュールを生成する時間でなかった場合、スケジューラ240は、コンテンツデータベース235が更新されているか否かをステップ325において（例えば、図７の信号239により）確認する。コンテンツデータベース235が更新されていなかった場合、スケジューラ240は、ステップ315において、スケジュールを生成する時間であるか否かを再び確認する。しかしながら、コンテンツデータベース235が更新されていた場合、スケジューラ240は、ステップ310において、更新されているコンテンツを抽出する。この更新されているコンテンツは、変更後のコンテンツ、新しいコンテンツ又は消去されたコンテンツを表す。この点に関し、スケジューラ240は、ステップ310において必要な処理を実行し、抽出されるコンテンツメタデータを必要に応じて生成、更新又は削除する。

ステップ315において、スケジュールを生成する時間であることをスケジューラ240が確認した場合、実行フローはステップ320に進み、特定されたクリップ各々について、スケジューラ240はスケジューリングメタデータの値を決定又は更新し、スケジュールを決定する。先ず、スケジューラ240は、必要に応じて、記述213を分析し、スケジューリングメタデータのキーワードフィールド204のキーワードを決定する。或いは、スケジューラ240は、存在するキーワード214を使用する。次に、スケジューラ240は、特定されているクリップ（コンテンツID211）の実際の優先度を表す値を決定し、その値を動的優先度（のフィールド）201に格納する（これについては後述する。）。また、スケジューラ240は、特定されているクリップが送信された回数を表現する送信回数202の値を更新し、特定されているクリップが最後にブロードキャストされて以来経過した秒数を表す待ち時間203の値を更新する。特定されているクリップに関するスケジューリングメタデータが決定されると、スケジューラ240は、（信号241を介して）ESG生成部215が使用する及び（信号242を介して）FLUTE送信部220が使用するスケジュールを生成する。実行フローはステップ325に進む。簡明化のため、他の終了及び／又はエラーの状態は、図示のフローチャートには示されていないことに留意すべきである。受信機及び送信機の双方の側を不必要に複雑化するおそれを回避するため、スケジューラ240は、一例としてプリエンプティブでない（non-preemptive）スケジューラとして設計される。これは、ビデオクリップの各々又は他の如何なるファイルも小さなチャンク（chunk）に分割されず、送信信号は異なる時間スロットにわたって分散しないことを意味する。換言すると、コンテンツ送信が始まると、終了するまでその送信は、他のクリップを送信するスケジューラ240による割り込みを受けない。これは、端末における受信完了に至るまでに要する時間を最小化することに資する。しかしながら、発明概念はそのような形態に限定されず、プリエンプティブ方式のスケジューラにも適用できる。

上述したように、スケジューラ240はスケジュールを生成する。本発明原理による例示的なスケジュール400が、図１０に示されている。スケジュール400は、静的な部分401と動的な部分410とを有する。静的な部分401は、J個のクリップA（401−1）、C（401−2）、．．．F（401−J）（J≧０）を有し、動的な部分410は、K個のクリップD（410−1）、．．．E（410−K）（K≧０）を有する。スケジュールの継続時間は、終了時間マイナス開始時間である（すなわち、t_E−t_S）。図１０から分かるように、静的部分401は開始時間t_Sから始まり、時間t_Dにて終了する。後者は動的部分410の開始時間でもあり、個の部分はスケジュール終了時間t_Eにて終了する。図１０から分かるように、各クリップは、関連する持続時間（継続時間）を有する。例えば、クリップC（410−2）は、D_Cという関連する継続時間を有する。図１０は静的部分及び動的部分を示しているが、各部分のクリップ数は、ゼロでもよく、例えばt_Sがt_Dに等しくてもよいことに、留意すべきである。

図１１を参照するに、図９のステップ320にて使用されるフローチャート例が示されている。新しいスケジュールを生成する時間になった場合、図１１のステップ350において、スケジュール時間tは、例えばt_S＝0に設定される。ステップ355において、スケジューラ240は、先行するスケジュールが存在するか否かを確認する。先行するスケジュールが存在していた場合、ステップ360において、スケジューラ240は先行するスケジュールをロード（取得）し、先行するスケジュールの動的部分の開始時間（例えば、図１０のスケジュールのt＝t_D）に等しくなるようにtを設定する。いずれにせよ、ステップ365において、そのスケジューリングセッションについて抽出されたコンテンツ又はクリップ各々の動的優先度（Dp（t））を決定する（これについては後述する。）。ステップ370において、最高の動的優先度Dp（t）を有するクリップ（i）が、スケジュール時間tから始まる新たなスケジュールの中に設定される。クリップ（i）は、Diという関連する継続時間を有する。ステップ375において、スケジュール時間tは、t＝t＋Diだけ進められる。ステップ380において、スケジュール時間tは、スケジュール終了時間に関して検査される。スケジュールの終了に到達していた場合、スケジューラ240は、ステップ385における新たなスケジュールに戻る又は生成する。しかしながら、スケジュールの終了に至っていなかった場合、ステップ365において残りのクリップについて動的優先度Dp（t）を再計算し、最高の動的優先度（Dp（t））を有するクリップを再び選択する等の処理を行う。このプロセスは、スケジューラ240がスケジュール全体を埋め尽くすまで反復する。フローチャートに示されているように、先行するスケジュールがシステムに存在していた場合、動的優先度計算の前に、開始時間「t」が調整される。その場合、先行するスケジュールの静的部分のイベントは、変更を加えずに新たなスケジュールの中にコピーされる。これは、スケジュールを受信機においてさらに予測しやすくするために行われる。

特定の時点tにおいてスケジュールされるクリップは、その時点におけるクリップの動的優先度により決定されることを、図１１のフローチャートは示している。図１２は、図１１のステップ365の一例を示す。ステップ450において、スケジューラ240は、現在のスケジュール時間t及び現在の継続時間Diをロードする。先行するスケジュールが一切存在しておらず、かつ目下のスケジューリングセッションにおいてクリップが一切スケジューリングされていなかった場合、現在の継続時間Diはゼロに等しい。先行するスケジュールは存在するが、そのスケジューリングセッションにおいてクリップが一切スケジューリングされていなかった場合、Diは、動的部分の開始時間tD及び静的部分の開始時間の差分に等しい。それ以外の場合、Diは、スケジュールされた最後のクリップの継続時間に等しい。ステップ455において、スケジューラ240は、全てのクリップの送信回数（例えば、図８の送信回数202）を更新し、全てのクリップの最後のブロードキャスト時間も更新する。ステップ460において、スケジューラ240は、現在の継続時間Diの値を検査する。現在の継続時間Diの値がゼロに等しかった場合、ステップ470において、各クリップに対する待ち時間Wt（図８に示される待ち時間203として示される）が、次式にしたがって計算され、
Wt＝クリップ（i）の最終ブロードキャスト時間−t （1）
これは単にそのクリップに関する現在時間と最後のブロードキャスト時間との差分である。しかしながら、現在の継続時間Diの値がゼロに等しくなかった場合、ステップ465において、その継続時間に対して、各クリップの待ち時間Wt（図８に示される待ち時間203として示される）を加え、Wtは次式にしたがって計算され、
Wt＝Wt＋Di （2）
Diは先行するスケジューリングされているクリップの継続時間（又は、スケジュールの静的部分の継続時間）を表す。

ステップ475において、スケジューラ240は、送信用に未だスケジュールされていないクリップの相違度合い（dissimilarity）を決定する。この点に関し、ブロードキャストによるプッシュVODアプリケーションを実現する場合、フィードバックチャネルが不足している。エンドユーザが存在することを送信者に通知するリバースチャネルが存在しない。プッシュVODアプリケーションの場合、優先度が互いに異なる様々なユーザが広く存在するのが一般的である。この特徴を考慮に入れないスケジューラは、プッシュVODアプリケーションにとって理想的ではない。例えば、サッカーワールドカップのハイライトを入手するために、ニュースや音楽ビデオのクリップの送信が終了するのを待たなければならない場合、熱狂的なサッカーファンは、そのようなプッシュVODアプリケーションを決して好まないであろう。

様々な視聴者が存在する可能性を考慮に入れるため、本発明原理によれば、図１２のステップ475において、既にスケジューリングされているクリップと比較して、スケジューリングに利用可能なクリップ各々の相違度合いの重み（ウェイト）を生成する。例えば、時間tにおいて最も相違しているクリップは、他のクリップよりも大きな相違度のウェイト値を有する。この相違度のウェイト値は、クリップの動的優先度を決定する際に以後使用され、その結果により（後述するように他の要因を考慮せずに）、同様なクリップを並べて次々と送信するのではなく、相違するクリップ同士を互いに隣接させて送信するようにスケジューリングを行う。スケジュールされるクリップがスケジュールされているクリップトドの程度似ているかを見出すため、例えば、スケジューラは、各クリップに関連するキーワードデータ（図８のキーワード204）を利用する。上述したように、コンテンツプロバイダはこのキーワードデータを提供することができ、及び／又はオペレータもコンテンツをさらに分類する追加的なキーワードを指定することができる。あるいは、上述したように、スケジューラ240は図８の記述213を分析し、キーワード204に保存するキーワードを自ら形成することもできる。特定のクリップに対するキーワード204又はキーワード214内のキーワードのリスト全体が、他のクリップのキーワード各々と比較され、類似度が得られる。２つのキーワード群の間の関連性を計算する幾つかの方法がある。例えば、２つのベクトルのドット積（dot product）を利用して、それらの関連性を見出してもよい。

一例として、ステップ475において、スケジューラは２つのクリップ間の以下の類似度計算を実行し、例えば、スケジュールされていないクリップがクリップXであり、最後にスケジュールされているクリップがクリップYである。

ここで、S（x，y）はクリップX及びクリップY間の類似度であり、NsはクリップX及びクリップYにおける同様なキーワードの数であり、N（x）はクリップXにおけるキーワードの総数であり、N（y）はクリップYにおけるキーワードの総数である。数式（3）によると、S（x，y）の値は０及び１の間で変化し得る。値１は完全に一致するクリップ同士であることを表し、値０は全く異なるクリップ同士であることを表す。したがって、相違度合いは、次式のように書ける。

D_S（x，y）＝1−S（x，y） （4）
スケジュールされていないクリップ各々に対するこの相違度合いD_S（x，y）は、スケジューラ240がクリップの動的優先度を決定する際に使用される。このプロセスにおいて、オペレータ／コンテンツプロバイダが指定したキーワードは、あらすじ／要約のフィールドを解析することで、スケジューラにより生成されたキーワードよりもさらに重み付けする。

類似度の計算は、以前の者と比較した場合に最も相違しているクリップを特定するために行われるだけでなく、過去の送信履歴と比較した場合に最も異なるクリップを見出すようにも拡張できることに、留意すべきである。これは、相違度の計算を、過去の相違度の移動平均をとるようにすることで達成できる。したがって、数式（3）及び（4）に加えて、スケジューラ240は相違度の計算をさらに洗練してもよい。特に、継続時間Δtを有するクリップXが時刻「t−Δt」においてスケジュールされることを仮定してもよい。時間「t」における各クリップのDsは、次式のように計算できる。

Ds（t）＝（1−α）*Ds（x，i）＋α*Ds（t−Δt） （5）
ここで、Ds（x，i）はクリップXに対するクリップ（i）の（数式（3）及び（4）による）相違度合いであり、Ds（t−Δt）は時刻t−Δtにおける（すなわち、以前のスケジューリングインターバルにおける）クリップ（i）の相違度の値であり、αは０ないし１の間で変化する定数である。過去の履歴に対するものよりも、最近スケジュールされたクリップに対する相違度の方に多くのウェイトが与えられるように、αの値は決定される。

スケジュールされていないクリップ各々について相違度合いを決定した後、スケジューラ240は、スケジュールされていないクリップ全てについて、ステップ480において動的優先度を決定する。一例として、時間「t」における各クリップの動的優先度は、次式により与えられる。

Dp（t）＝KpP＋KdDs（t）＋KwWt−KsSc （6）
ここで、D（t）は時間tにおける動的優先度であり、Pはオペレータ／コンテンツプロバイダが与えたクリップの優先度（例えば、図８の優先度212）であり、D（t）は時間tにおけるクリップの上記の類似度であり（あるいは、Ds（x，y）がDs（t）の代わりに使用されてもよい。）、Wtは時間tにおけるクリップの待ち時間であり、Scはクリップの送信回数であり、Kp、Kd、Kw及びKsは、オペレータ優先度、相違度、経過時間及び送信回数各々に対する相対的なウェイトを決定する定数である。これらの定数は事前に設定可能であるが、これらの定数は最適なスケジュールをもたらすようにマニュアルで調整されてもよいし、あるいは視聴者からの選択的な統計的なフィードバックを利用してスケジューラが調整してもよい。統計的なフィードバックは、様々な時点で視聴する視聴者からのオフラインフィードバックの集合である。ウェブポータルやSMS（ショートメッセージサービス）を用いたゲートウェイや他の通信チャネルを通じて実現されてもよい。

数式（6）の観点から動的優先度が説明されたが、P、Ds（t）、Wt及びScの変数の内の１つ、２つ又は３つを利用して動的優先度を決定してもよいことに、留意を要する。本発明原理によれば、動的優先度を決定するために、これら４つに加えて追加的なパラメータが定義されてもよい。

上述したように、一例として、送信回数Scは、クリップが送信された回数をスケジューリングプロセスで考慮に入れるために使用されている。例えば、ビデオクリップブロードキャストシステムの場合、視聴者は常に新しいクリップを眺めている。一般に、視聴者は古いものよりも新しいクリップを好み、しばしば、古いクリップがオペレータやコンテンツプロバイダにより上位に格付けされていた場合でさえ、新しいクリップが好まれる。したがって、スケジューラは、クリップが送信された回数を考慮に入れるべきであり、それに応じてクリップのスケジュールを立てるべきである。スケジューラは、Scを使用して、特定のクリップが送信された回数を計数することで、上記の要請に応じる。全ての新しいクリップは、ゼロである送信回数Scを有する。クリップの動的優先度を決定する際、スケジューラは、送信回数に直接比例するように優先度を減らす。言い換えれば、送信回数が低いほど、動的優先度における値は高くなる。

この場合、スケジューラは高優先度のコンテンツを優先し、古いクリップよりも新しいクリップを格別に配慮するので、新たなクリップが頻繁に追加される場合、低優先度のクリップは、送信されることなくいつまでもデータベース内に保持されることになってしまう。これを補填するため、スケジューラは、数式（6）のパラメータWtによりクリップの年齢を考慮に入れる。すなわち、クリップの動的優先度は、待ち時間が増えるにつれて高くなる。

クリップのオペレータ／コンテンツプロバイダの優先度Pが上昇すると、動的優先度も直接的に上昇することも数式（6）から分かる。したがって、オペレータ／コンテンツプロバイダの好みのクリップは、早期にスケジュールに入る傾向がある。

ステップ485において、スケジューラ240は、時間tにおける最高の又は最大の動的優先度Dp（t）を有するクリップを送信用に選択し、そのクリップをスケジュールに入れる。複数のクリップが、同じ動的優先度を持っていた場合、スケジューラ240はそれらの内いずれかを選択してもよいし、あるいは動的優先度が等しいクリップの中でラウンドロビン法によるスケジュールが実行されてもよいことに、留意を要する。例えば、一群のクリップの動的優先度が全て同じ値になった場合、スケジューラは、その一群の中でスケジュールを行うことを単に繰り返し、それら全てが送信されることを保証してもよい。

ステップ490において、選択されたクリップの待ち時間（例えば、図８の待ち時間203）はゼロに設定され、Diは選択されたクリップの継続時間に設定され、スケジューリングプロセスの次回の反復において、このDiの値が（上記の）ステップ450で使用される。

上述したように、スケジュールの予測可能性は重要である。片方向ブロードキャスト環境の場合、受信機は、それがコンテンツの選択的な受信を行うためのスケジュール及びメタデータ情報を非常に当てにしている。したがって、受信機が事前にスケジュールを受け取ることは非常に大切なことである。さらに、新たなコンテンツの追加に起因して又は他の何らかの理由により何らかのスケジュールが変わった場合、最新のスケジュールが全ての受信機に送信される必要がある。スケジューラは、例えばT＝1／fs毎に周期的に最新のスケジュールを送信することでその要請に応じ、fsは上述したようにスケジュールの頻度である。周期的な最新のスケジュールは、例えば、新たにスケジュールされたイベント及びその他のスケジュールコンテンツに関連するメタデータを含む。この情報を使用して、受信機は、コンテンツを受信する必要の有無及びコンテンツを取得するように同調する時間を決定することができる。これにより端末は電力及びストレージ空間の両方を節約できる。

しかしながら、実際のシステムの場合、スケジュール更新の頻度や、端末における最新スケジュールの速やかな受信には制限がある。言い換えれば、スケジュールがサーバで変わった場合、それを受信機が知るまでにはある程度時間がかかる。この遅延を、端末における最小スケジュール更新インターバルとして以下で考察する。この最小スケジュール更新インターバ及びそれによる予測困難性に対処するため、本発明原理によれば、スケジューラは、図１０に示すような静的部分と動的部分にスケジュールを分ける、という新たな概念を導入している。

これは図１３にさらに示されている。この図は、連続的な時間インターバルにわたって、スケジューラ240が３つのESG701、702及び703を形成している様子を示す。簡明化のため、ESGは１分毎に形成され、先行するスケジュールは存在しないものとする。スケジューラ240が時間０に作成した第１ESGは、EGS701である。ESG701を作成する際、スケジューラ240は、クリップA、B、C、D及びEが送信に利用可能であることを確認し、図９、１１及び１２の上記のスケジューリングプロセスにしたがって図１３に示されるようにそれらの送信の予定を立てる。図１３から分かるように、ESG701において、クリップA、B、D及びEの各々は１分間の継続時間を有するが、クリップCは２分間の継続時間を有する。さらに、２分間の継続時間を有する静的な部分401が事前に決定されており、ESG401以後の部分がESGの動的部分410として指定されていることが仮定されている。

次のスケジューリングインターバルにおいて、スケジューラ240は、クリップB、C、D、E及びFが送信に利用可能であることを確認する（クリップAは送信されている。）。さらに、スケジューラ240は、先行するスケジュール（ESG701）が存在することを確認し、その静的部分401を確認する。上述したように、スケジューラ240は、一例では、プリエンプティブ方式ではないスケジューラとして設計される。これは、ビデオクリップの各々又は他のどのコンテンツファイルも小さなチャンクに分割されず、送信信号は異なる複数のタイムスロットにわたって分散されないことを意味する。したがって、静的部分401は２分間の継続時間を有するように規定されるが（２分はクリップCの中央に該当する）、静的部分401はクリップC全体を包含するために一時的に拡張される。言い換えれば、静的部分は２分間の最低継続時間を有する。その結果、クリップB及びCは、ESG701において過去に決定された送信内容としてスケジュールされる。しかしながら、図１３から分かるように、クリップD、E及びFの送信の動的優先度を再計算する際、動的部分410の中にクリップFが、クリップD及びEの前に送信されるようにスケジュールされている。したがって、例えば、ESG702の中のクリップDは、クリップDがESG701において所有していたものとは異なる送信順位又は優先度を有する。

そして、次のスケジューリングインターバルにおいて、スケジューラ240は、クリップC、D、E、F及びGが送信に利用可能なことを確認する（クリップBは送信されている。）。さらに、スケジューラ240は、過去のスケジュール（ESG702）が存在していることを確認し、静的部分401を確認する。しかしながら、今回の静的部分401は２分間に戻される。なぜなら、静的部分401はクリップCしか含んでいないからである。かくてクリップCは、ESG702の中で過去に決定されている送信としてスケジュールされる。しかしながら、図１３から分かるように、動的部分410のクリップD、E、F及びGの送信の動的優先度を再計算する際、クリップGが、クリップF、D及びEの前に送信されるようにスケジュールされている。したがって、例えば、ESG703におけるクリップFは、クリップFがESG702において所有していたものとは異なる送信順位又は優先度を有する。

上記によれば、人の時点でスケジューラが生成するスケジュールは、２つの部分を有する。原罪のスケジュールの中の静的部分は、過去のスケジュールに存在していたイベントを、対応する期間の中に含んでいる。スケジュールの静的部分は、スケジュールが進行するにつれて、時間軸上で先行して進行する。すなわち、静的部分が30秒であった場合、ある時点tにおいて作成されるスケジュールは、時間tないしt＋30に及ぶ静的部分を有し、t＋1秒において作成されるスケジュールはt＋1ないしt＋31に及ぶ静的部分を有する。

再スケジュールがなされるときは常に、新たな再スケジュールによる変更は、スケジュールの動的部分に対応付けられ、動的部分はt＋（静的部分の継続時間）から始まり、tは再スケジュールの時点を表す。新たなスケジュールの静的部分は、過去のスケジュールの中で、tないしt＋（静的部分の継続時間）の期間に対応するイベントを取得することで設定される。一定の持続時間が静的部分として構築されていたとしても（例えば、30秒間）、図１３のESG701、702及び703に示されるように、静的部分は、正確には、静的部分におけるクリップの継続時間に応じて変化する。

スケジュールの静的部分の期間（静的期間）は、ある周期により調整されてもよい。理想的には、静的期間は、端末が必要とする最小スケジュール更新インターバルに等しい。また、必要に応じて、再スケジュールの間隔（周期、インターバル）が調整され、新たなスケジュールの処理及び送信における如何なるオーバーヘッドにも対処できるようにする。かくて、如何なる再スケジュールの変更も端末に送信され、その間、端末は不変な静的部分を当てにすることができる。

図１４を参照するに、本発明原理による受信機100の一例が示されている。本発明概念に関する受信機100の部分のみが示されている。受信機100は、何らかのプロセッサベースのプラットフォームを表現し、例えば、PC、パーソナルディジタルアシスタント（PDA）、セルラ電話、移動ティ時たるテレビジョン（DTV）等である。この場合において、受信機100は、図１４においてプロセッサ890及びメモリ895として示されているような１つ以上の関連するプロセッサ及び付随するメモリを含む。この場合において、コンピュータプログラムやソフトウエアが、プロセッサ890による実行に備えてメモリ895に格納されている。後者は1つ以上の保存されたプログラムによる制御プロセッサを表現し、これらは受信機能に専用である必要はなく、例えばプロセッサ890は受信機1000の他の機能を制御してもよい。メモリ895は、例えばランダムアクセスメモリ（RAM）やリードオンリメモリ（ROM）等のような何らかのストレージデバイスを表現しており、受信機100の内部にあっても外部にあってもよく、必要に応じて揮発性でも不揮発性でもよい。受信機100は、DVB−H受信部810、IPデカプセル化部815及びFLUTE受信部820を有する。これらの要素の全部又は一部は、プロセッサ890及びメモリ895により示されるようなソフトウエアとして実現されてもよい。DVB−H受信部810は、アンテナ805を介してDVB−H信号186（図６）を受信し、復調した信号をIPデカプセル化部815に与える。後者は、ALCパケットをFLUTE受信部820に与え、FLUTE受信部820は信号821により示されているようにコンテンツを復元する。このコンテンツは、（点々830により示されているように）当該技術分野で知られているように受信機100によりさらに処理されてもよい。上述したように、本発明概念によれば、プロセッサ890は静的部分及び動的部分を有するESGを復元し、選択したクリップ（コンテンツ）を特定するために使用する。この例の場合、FLUTE受信部820及びDVB−H受信部810は、制御信号809及び819により示されているようにプロセッサ890により電源がオン及びオフされ、少なくとも選択されないいくつかのコンテンツに対して、受信機100は節約された電力で動作する。したがって、プロセッサ890は、ESGの少なくとも動的部分に合わせ、受信した番組ガイドの中で表現されているコンテンツを選択的に受信するスケジュールを立てる。

図１５には、本発明原理による受信機900の別の例が示されている。本発明概念に関する受信機900の部分のみが示されている。受信機900は、DVB−H受信部910、復調／復号部915、トランスポートプロセッサ920、コントローラ950及びメモリ960を有する。アナログディジタル変換器、フロントエンドフィルタ等のような受信機の他の要素は、簡明化のため図示されていないことに、留意を要する。トランスポートプロセッサ920及びコントローラ950の各々は、１つ以上のマイクロプロセッサ及び／又はディジタル信号プロセッサ（DSP）を表し、プログラムの実行に備えてデータを格納するメモリを含む。この場合において、メモリ960は、受信機900内のメモリを表し、例えば、トランスポートプロセッサ920の何らかのメモリ及び／又はコントローラ950を含む。図示の双方向データ及び制御バス901は、ともに示される受信機900の要素の内の様々なものを結合する。バス901は、例えば個々の信号が（並列的に及び／又は直列的に）使用されてもよいこと等を示しているにすぎず、受信機900の要素間でデータ及び制御シグナリングを伝送する。DVB−H受信部910は、DVB−H信号909を受信し、ダウンコンバートされたDVB−H信号911を復調／復号部915に与える。後者は、信号911に対して復調及びデコードを行い、デコードされた信号916をトランスポートプロセッサ920に与える。トランスポートプロセッサ920は、パケットプロセッサであり、リアルタイムプロトコル及びFLUTE／ALCプロトコルスタック双方を備え、DVB−Hにしたがってリアルタイムコンテンツ又はファイル形式のコンテンツを復元する。トランスポートプロセッサ920は、制御信号921により示されているように（点々991により示されているように）、適切な後続の回路へコンテンツを与える。コントローラ950は、バス901を介して、上記のフローチャートにしたがってトランスポートプロセッサ920を制御し、図１３のESGにより表現されているようなESG情報をメモリ960に保存するために復元する。コントローラ950は、受信したESGの静的及び動的部分の内、選択されるクリップ（コンテンツ）に応答して、制御信号951、952、953を介して（バス901を介して）本発明原理にしたがって、トランスポートプロセッサ920、DVB−H受信部910及び復調／復号部915の電力管理能を実行する。したがって、コントローラ950は、ESGの動的部分に少なくとも適合し、受信した番組ガイド内で表現されている選択するコンテンツの受信のスケジュールを立てる。

図１６には、受信機100又は受信機900において使用されるフローチャート例が示されている。ステップ505において、受信機は静的部分及び動的部分を有するESGを受信し、静的部分において表現されているコンテンツの送信順序は、過去に受信した番組ガイドの中で対応するコンテンツの送信順序から決定され、動的部分において表現されているコンテンツの送信順序は、過去に受信した番組ガイドにおける対応するコンテンツの送信順序と異なる場合がある。ESG702の場合、静的部分401において表現されているコンテンツの送信順序は、ESG701から決定されるが、動的部分410において表現されているコンテンツの送信順序は、ESG701により表現されている過去に受信した番組ガイドの中において、対応するコンテンツの送信順序と異なる。例えば、（既に受信されている番組ガイドである）ESG701の場合、クリップD及びEは、４分及び５分の時点で送信するようにそれぞれスケジューリングされている。しかしながらESG702の場合、クリップD及びEは５分及び６分の時点で送信されるようにそれぞれスケジューリングされており、送信順序が変わっていることが分かる。図１６を参照するに、ステップ510において、受信機は、例えば、既に受信しているESGと対比（比較）することで、又はESGのバージョン番号（図示せず）を利用することで、ESGの動的部分が、過去に受信しているESGから変化しているか否かを判断する。ESGの動的部分が変化していた場合、受信機はステップ515において必要に応じて何らかの電力管理スケジュールを更新する。例えば、クリップDが受信機において選択されているコンテンツであった場合、ESG701を受信した際、受信機はt＝4分に受信するスケジュールを予定するであろう。しかしながら、ESG702を受信すると、受信機は、番組ガイドの動的部分の変更を検出し、t＝5分にクリップDは伝送されるので、選択されたコンテンツの受信のスケジュールをそのように立てる。こうして受信機は、受信した番組ガイドの動的部分に少なくとも適合して、受信した番組ガイドの中で表現されている選択したコンテンツの受信のスケジュールを立てる。

状況に応じて帯域幅が変わる（opportunistic bandwidth）環境（例えば、可変ビットレート（VBR）の環境）において、出力チャネルの帯域幅は一定ではないことに、留意を要する。これは、スケジューラが行うタイミング計算に全て影響する。この影響を考慮するため、スケジューラには、帯域幅フィードバックインターフェースが備えられる。したがって、スケジューラ240は出力帯域幅を監視し、各クリップの伝送の継続時間を計算し（継続時間＝クリップのサイズ／帯域幅）、スケジューラが次のクリップをスケジュールする時間を決定する。これは図１７のサーバ150’に示されており、この図は図７と同様であるが、FLUTE送信部220からスケジューラ240へのフィードバック通信経路244が設けられている点が異なる。その結果、スケジューラ240は、帯域幅の変動を定常的に監視し、FLUTE送信部220が、送信完了の際にフィードバック通信経路244を介してスケジューラ240に通知を行って以来の変動を、統計的に予測する。したがって、長期的には、スケジューラが行うタイミング推定は、より正確なものになる。さらに、スケジューラは、コンテンツ送信各々のステータスを更新することもできる。これは、VBR環境における送信回数計算の誤差を最小化する。

上述したように、本発明概念は、ブロードキャストネットワークにおいて送信するマルチメディアファイルをスケジューリングする際のいくつもの問題に対処する。例えば、本発明概念は、例えば、新たなクリップの追加及び／又は削除に応じて、コンテンツデータベースがある周期で変わることを可能にする。さらに、個々のクリップに関するオペレータのこのみも時間とともに変更可能である。さらに、スケジューラは、CBR（一定のビットレート）の出力チャネルにもVBR（可変ビットレート）の出力チャネルにも適用可能である。

本発明概念はDVB−Hシステムの観点から説明されてきたが、本発明概念はそれに限定されないことに、留意を要する。さらに、本発明概念は、スケジューリングメタデータにおける特定数の要素とともに説明されてきたが、本発明概念はそれに限定されず、追加的な又はより少ないフィールドによりスケジューリングメタデータを構築してもよい。また、スケジューラはサーバ又はヘッドエンドの一部分として説明されたが、本発明はそれに限定されず、スケジューラは、サーバから離れてスケジューリング情報をESG及び／又はFLUTE送信部へ提供してもよい。

したがって、上記の説明は本発明概念を例示しているにすぎず、当業者は様々な代替例を見出すことができ、その代替例は、明示的には記述されてはいないが、本発明原理により実現されかつ本発明の精神及び範囲内のものである。例えば、個別的な機能要素の観点から説明されているが、これらの機能要素は１つ以上の集積回路（IC）において実現されてもよい。同様に、個別的な要素として説明されているが、（例えば図７の）それらの要素の全部又は一部が、例えばディジタル信号プロセッサのような格納されたプログラムにより制御されるプロセッサとして実現されてもよく、そのプロセッサは、例えば図９、１１及び１２における１つ以上のステップに対応する関連ソフトウエアを実行する。さらに、本発明原理は、例えば、ワイヤレスフィデリティ（Wi-Fi）、セルラ等のような他のタイプの通信システムにも適用可能である。本発明概念は、固定受信機や移動受信機にも適用可能である。したがって、様々な変形例が説明済みの実施形態になされてよいこと、及び他の形態が導出されてよいことが、本発明の精神及び範囲から逸脱せずになされることが理解されるであろう。

Claims (20)

1. コンテンツファイルの送信順序を動的な優先度の関数として決定するステップであって、前記優先度は、前記コンテンツファイル同士の相違度に少なくともしたがって決定される、ステップと、
   決定された送信順序にしたがって前記コンテンツファイルを送信するステップと
   を有する方法。
2. 前記相違度は、前記コンテンツファイル同士がどの程度似ているかを表現する、請求項１記載の方法。
3. 前記コンテンツファイルは、オーディオクリップ又はビデオクリップである、請求項１記載の方法。
4. コンテンツファイル各々に関連する送信回数、待ち時間の値及びコンテンツプロバイダの値の内の少なくとも１つにしたがって、各コンテンツファイルの前記動的な優先度が決定される、請求項１記載の方法。
5. 前記決定した送信順序を表現する電子サービスガイドを生成するステップと、
   前記電子サービスガイドを送信するステップと
   をさらに有する請求項１記載の方法。
6. 前記決定するステップにおいて、
   各コンテンツファイル関連する記述データと、送信用に過去にスケジュールされている少なくとも１つのコンテンツファイルに関連する記述データとを比較し、各コンテンツファイルの相違度を決定する、請求項１記載の方法。
7. 前記記述データが、クリップのメタデータである、請求項５記載の方法。
8. 前記記述データが、各クリップに関連するキーワードを表す、請求項５記載の方法。
9. 前記送信順序におけるコンテンツファイルの一部分は、以後に送信されるコンテンツファイルの動的な優先度の値に等しい又はそれより大きくないように関連付けられた動的な優先度の値を有する、請求項１記載の方法。
10. 前記決定するステップにおいて、使用する出力帯域幅を監視し、コンテンツファイルの送信時間を調整する、請求項１記載の方法。
11. コンテンツファイルの送信順序を動的な優先度の関数として決定するプロセッサであって、前記優先度は、前記コンテンツファイル同士の相違度に少なくともしたがって決定される、プロセッサと、
    決定された送信順序にしたがって前記コンテンツファイルを送信するモジュレータと
    を有する装置。
12. 前記相違度は、前記コンテンツファイル同士がどの程度似ているかを表現する、請求項１１記載の装置。
13. 前記コンテンツファイルは、オーディオクリップ又はビデオクリップである、請求項１１記載の装置。
14. コンテンツファイル各々に関連する送信回数、待ち時間の値及びコンテンツプロバイダの値の内の少なくとも１つにしたがって、各コンテンツファイルの前記動的な優先度が決定される、請求項１１記載の装置。
15. 前記プロセッサにより電子サービスガイドが送信用に生成され、該電子サービスガイドは、前記決定した送信順序を表現する、請求項１１記載の装置。
16. 前記プロセッサが、各コンテンツファイル関連する記述データと、送信用に過去にスケジュールされている少なくとも１つのコンテンツファイルに関連する記述データとを比較し、各コンテンツファイルの相違度を決定する、請求項１１記載の装置。
17. 前記記述データが、クリップのメタデータである、請求項１６記載の装置。
18. 前記記述データが、各クリップに関連するキーワードを表す、請求項１６記載の装置。
19. 前記送信順序におけるコンテンツファイルの一部分は、以後に送信されるコンテンツファイルの動的な優先度の値に等しい又はそれより大きくないように関連付けられた動的な優先度の値を有する、請求項１１記載の装置。
20. 前記プロセッサが、使用する出力帯域幅を監視し、コンテンツファイルの送信時間を調整する、請求項１１記載の装置。

Images