(57)【特許請求の範囲】
【請求項１】
内容クリエータにより、オーディオ／ビデオの内容に関連するアナウンスメント，リソースファイル，及びトリガファイルを含むエンハンスメントデータの様々なレイヤーを創り出して、このレイヤー化されたデータを、レイヤー化する機能のないプロトコルを用いて通信するための方法であって、
レイヤー化されていないエンハンスメントデータに関連する第１のアナウンスメント、及び、それぞれが１つ又はそれ以上の前記トリガファイルのソース又は１つ又はそれ以上の前記リソースファイルのソースを含む複数のレイヤーを有するレイヤー化されたエンハンスメントデータに関連する第２のアナウンスメントを、搬送媒体からそれぞれ受信する複数のレシーバプラットフォームにおいてそれぞれ検出するステップと、
前記第２のアナウンスメントの中で示された、前記エンハンスメントデータのレイヤーの種々のコレクションを含む選択肢を認識するステップと、
能力情報ファイルに記述されている前記複数のレシーバプラットフォームの能力についての情報と、受信された前記第２のアナウンスメントにおいて示されたバンド幅及びキャッシュについての要求事項とを比較した結果に基づいて、前記第２のアナウンスメント内の前記選択肢の１つを前記複数のレシーバプラットフォームのそれぞれについて選択するステップと、
前記選択された選択肢に基づいて、前記それぞれのトリガファイル又はリソースファイルを含む１つ以上のレイヤーを受信するステップと、
をそれぞれ含むことを特徴とする方法。
【請求項２】
前記第２のアナウンスメントを検出するステップが、複数のセクションを含むアナウンスメントを検出するステップを含み、前記複数のセクションの各々がエンハンスメントデータのレイヤーを参照することを特徴とする請求項１に記載の方法。
【請求項３】
前記第２のアナウンスメント内の前記選択肢を検査するステップが、前記アナウンスメントのどのセクションが対応する選択肢に関連するかを決定するステップを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記決定するステップが、前記各選択肢に関連するセッション記述プロトコルアナウンスメントン（Session Description Protocol announcement）の媒体セクションを決定するステップを含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記レシーバプラットフォームが、前記選択肢の１つを受信することができるかどうかを決定するステップをさらに備えることを特徴とする請求項３に記載の方法。
【請求項６】
前記エンハンスメントデータの１つ又はそれ以上のレイヤーを受信するステップが、高品位テレビエンハンスメントフォーラム仕様（Advanced Television Enhancement Forum Specification）に基づいて、エンハンスメントデータを受信するステップを含むことを特徴とする請求項１に記載の方法。
【請求項７】
内容クリエータにより、オーディオ／ビデオの内容に関連するアナウンスメント，リソースファイル，及びトリガファイルを含むエンハンスメントデータの様々なレイヤーを創り出して、このレイヤー化されたデータを、レイヤー化する機能のないプロトコルを用いて通信するレシーバシステムであって、
レイヤー化されないエンハンスメントデータに関連する第１のアナウンスメント、及び、レイヤー化されたエンハンスメントデータに関連する第２のアナウンスメントを搬送媒体から受信する受信モジュールと、
前記第２のアナウンスメントを検出した場合は、能力情報ファイルに記述されている前記複数のレシーバプラットフォームの能力についての情報と、受信された前記第２のアナウンスメントにおいて示されたバンド幅及びキャッシュについての要求事項とを比較した結果に基づいて、前記レイヤー化されたエンハンスメントデータの選択肢の１つを選択し、かつ、前記各々のリソースファイル及びトリガファイルを含む前記選択された選択肢に関連する１つ又はそれ以上のレイヤーを前記レシーバシステムに受信することを可能ならしめるコントローラと、
をそれぞれ備え、
前記レイヤー化されたエンハンスメントデータが、各々が前記１つ又はそれ以上のレイヤーを含む複数の選択肢に関連するエンハンスメントデータの前記複数のレイヤーのストリームを含み、前記各レイヤーが前記１つ以上のトリガファイルのソース又は前記１つ以上のリソースファイルのソースを含むこと、
を特徴とするレシーバシステム。
【請求項８】
前記レシーバシステムの能力を記述している情報を含む記憶装置をさらに備えることを特徴とする請求項７に記載のレシーバシステム。
【請求項９】
前記コントローラが、前記第２のアナウンスメントの中で示された前記選択肢を識別することを特徴とする請求項７に記載のレシーバシステム。
【請求項１０】
前記各エンハンスメントデータの選択肢が、１つ以上の能力についての要求事項を識別する情報を含むことを特徴とする請求項７に記載のレシーバシステム。
【請求項１１】
前記１つ又はそれ以上の能力についての要求事項が、記憶能力についての要求事項を含むことを特徴とする請求項１０に記載のレシーバシステム。
【請求項１２】
前記１つ又はそれ以上の能力についての要求事項が、バンド幅についての要求事項を含むことを特徴とする請求項１０に記載のレシーバシステム。
【請求項１３】
前記エンハンスメントデータが、高品位テレビエンハンスメントフォーラム仕様に基づいていることを特徴とする請求項７に記載のレシーバシステム。
【発明の詳細な説明】
【発明の属する技術分野】
【０００１】
背景
本発明は、複数のレイヤー内のオーディオ／ビデオの内容に関連したエンハンスメントデータの通信に関する。
【従来の技術】
【０００２】
プログラムのサブタイトル、緊急メッセージ、字幕メッセージ、及びプログラムガイド情報などの補助的情報は、通常のテレビ内容と一緒に送信される。ごく最近では、テレビ内容と一緒に送られる他のタイプの補助的情報には、ウェブページ、マルチメディア情報、又は他のディジタルファイルなどのエンハンスメントデータが含まれている。補助的情報は、アナログのテレビ放送信号の垂直帰線消去期間（ＶＢＩ）中に送られるか、又はディジタル送信搬送媒体上のディジタルのテレビ内容と共に送られる。
【０００３】
テレビ内容と一緒に補助的情報の送信を行うことについての種々の仕様（規格）がある。１つの仕様は、高品位テレビエンハンスメントフォーラム（Advanced Television Enhancement Forum）（ＡＴＶＥＦ）仕様の１９９９年２月２日付けのドラフトバージョン1.1r26である。このＡＴＶＥＦ仕様は、アナログシステム及びケーブルシステム、衛星システム、地上波システムなどのディジタルシステムの両方のテレビ内容と一緒に、エンハンスメントデータの送信を提供するために設計されている。
【０００４】
【発明が解決しようとする課題】
受信プラットフォームによって受信され得るエンハンスメントデータ又は他のタイプの補助的情報の量は、その能力（例えば、記憶能力、処理能力、及びデータ転送速度についての能力を含む）に大いに依存している。受信プラットフォームが異なると、能力が違うことがある。例えば、初期バージョンのセットトップボックスのようないくつかの比較的低能力の受信プラットフォームのバンド幅は、補助的情報を受信するためには比較的狭い。できるだけ多くの視聴者が補助的情報を確実に受信するためには、内容クリエータは、そのような低能力の受信プラットフォームを目標に送信する補助的情報の量を減少させることがある。この場合の想定は、大多数の視聴者がそのようなプラットフォームを使用していることである。このため、エンハンスメントデータ又は他のタイプの補助的情報の品質及び利用可能な機能が、比較的低い能力の受信プラットフォームに適応するために限定されることがある。このため、視聴者に提供することができる選択肢が制限されることになる。
【０００５】
【課題を解決するための手段】
概要
一般に、１つの実施形態によれば、オーディオ／ビデオの内容に関連するエンハンスメントデータを通信する方法には、受信システムの中でエンハンスメントデータを受信するステップが含まれる。このエンハンスメントデータは、それぞれが１つ又はそれ以上のエンハンスメントデータのレイヤーを含む複数の選択肢（alternative）に関連している。選択肢の１つは、レシーバシステムの能力に基づいて選択され、選択された選択肢に関連する１つ又はそれ以上のレイヤーが受信される。
【０００６】
他の特徴及び実施形態は、以下の説明及び特許請求の範囲から明らかになるであろう。
【０００７】
【発明の実施の形態】
詳細な説明
以下の説明の中では、本発明を理解してもらうために多数の細部が記載されている。しかしながら、本発明はこれらの細部なしで実行することができ、また説明した実施形態から多数の変形及び修正が可能であることは、当業者は理解されよう。例えば、高品位テレビエンハンスメントフォーラム（ＡＴＶＥＦ）仕様、１９９９年２月２日付けのドラフトバージョン1.1r26のバージョンを参照するが、ＡＴＶＥＦ仕様の他のバージョン、又はオーディオデータ又はビデオデータ（例えば、テレビ内容）を含む内容を有する補助的情報の送信に関する他の仕様及び技術は、さらに別の実施形態の中に含まれるものとする。
【０００８】
この説明の中で用いられているような、オーディオ／ビデオ（Ａ／Ｖ）の内容という用語は、視聴者及び／又は聴取者に提示するために、１つ以上の受信サイトに送信又は配信することができる全てのタイプのオーディオデータ及び／又はビデオデータを含むものとする。Ａ／Ｖ内容の例は、テレビの内容である。本願で使用するＡ／Ｖの内容は、オーディオ及びビデオ部分の両方又はオーディオ及びビデオ部分の１つを含む内容のことを指す。また、レイヤー化する機能とは、単に、レイヤー（層）を扱う能力をいい、レイヤー化とは、単に、レイヤーの構造（階層構造）にすることをいう。また、アナウンスメントは、リソースのストリーム及びトリガのストリームの両方のロケーションを記述するのもであり、リソースファイルは、単に、エンハンスメントデータの内容を含むアナウンスメントの一部であり、トリガファイルは、エンハンスメントデータをＡ／Ｖ内容の送信に同期させるものである。
【０００９】
図１を参照すると、１つの実施形態による情報配信システム１０には、内容クリエータ１２、トランスポートオペレータシステム１４、及び複数のレシーバ１６が含まれている。レシーバ１６は、家庭，オフィス，娯楽施設，又は他の場所を含む様々な受信サイトに配置することができる。内容クリエータ１２は、リンク２４を介してトランスポートオペレータシステム１４に伝送されるエンハンスメントデータ（又は他のタイプの補助的情報）及びテレビの内容（又はＡ／Ｖ内容を含む他のタイプの内容）を創り出す。エンハンスメントデータは、グラフィックス（例えば、ウェブページ，マルチメディア情報，又は他のデータファイル）、プレゼンテーション用レイアウト、及び同期情報を含むことができる。エンハンスメントデータとＡ／Ｖとの内容の組合わせを、エンハンスドＡ／Ｖ内容と呼ぶ。他のタイプの補助的情報には、プログラムのサブタイトル，字幕メッセージ，緊急メッセージ，及びプログラムガイド情報が含まれる。
【００１０】
トランスポートオペレータシステム１４は、地上，ケーブル，衛星，又は他のタイプの送信機能（アナログ又はディジタルの両方）を含むことができるエンハンスドＡ／Ｖ内容配信用インフラストラクチャーを提供する。Ａ／Ｖ内容及びエンハンスメントデータを、搬送（トランスポート）媒体２２を介してレシーバ１６に送信することができる。この搬送媒体２２は、地上，ケーブル，衛星，又は他のタイプのリンクとすることができる。図１は、搬送媒体２２を衛星リンクとして示している。レシーバ１６には、テレビ，セットトップボックス，パーソナルコンピュータ，又はＡ／Ｖ内容及び関連するエンハンスメントデータ，又は他のタイプの補助的情報を受信するように構成された他のタイプのシステムが含まれている。さらに別の実施形態では、レシーバ１６は、所定の地理上の領域内に配信するためのエンハンスドＡ／Ｖ内容を受信する、地理的領域センタのような配信システムも含むことができる。
【００１１】
いくつかの実施形態では、内容クリエータ１２は、複数のレシーバ１６に配信するために、エンハンスメントデータの異なったレイヤーを創り出すことができる。これらのレイヤーは、エンハンスメントデータを受信するために、異なった機能を有する様々なタイプとすることができる。例えば、レシーバ１６の記憶容量，処理速度，及びデータ転送速度は異なっていてもよい。レシーバ１６とは別に、他のレシーバのプラットフォームを搬送媒体２２に結合して、エンハンスドＡ／Ｖ内容を受信することもできる。
【００１２】
１つの実施形態によれば、レシーバのプラットフォームは、その機能に応じて、エンハンスメントデータの１つ以上のレイヤーを選択的に受信することができる。エンハンスメントデータは、それぞれが異なった数のレイヤーを含むいくつかの選択肢に関連している。これにより、比較的低い能力のレシーバのプラットフォームは、より少ない数のレイヤーを持つ選択肢を受信することを選択でき、一方、比較的高い能力のレシーバのプラットフォームは、より多くのレイヤーを有する選択肢を受信することを選んで、視聴者により多くのエンハンスメント機能を与えることができる。このように、第１の選択肢は、第１のエンハンスメントデータのセットを含み、第２の選択肢は、さらに別のデータに加えて第１のセットを含む第２のエンハンスメントデータのセットを含み、第３の選択肢は、エンハンスメントデータの他のソースを含む第３のエンハンスメントデータのセットを含み、第４以降のエンハンスメントデータも同様である。
【００１３】
エンハンスメントデータの複数のレイヤーは、トランスポートオペレータシステム１４により搬送媒体２２上のストリームの中で送信され、種々のレシーバのプラットフォームは、エンハンスメントデータの複数の選択肢の１つを選択することにより、異なった組合せのレイヤーを選ぶことができる。本発明のいくつかの実施形態では、エンハンスメントデータのレイヤーを、選択肢の数の回数だけ再送信する必要はない。このため、エンハンスメントデータのレイヤーを１つのストリームの中で送信することができ、各種のレシーバは、所望の選択肢に基づいてレイヤーを選択して受信することができる。その結果、搬送媒体２２のバンド幅は、様々な選択肢に関連するエンハンスメントデータの異なるグループを別々に送信しなければならないことによって消費されることはない。
【００１４】
ＡＴＶＥＦ仕様に基づいたエンハンスメントデータは、それぞれが３つのコンポーネント、すなわち、アナウンスメント，リソース，及びトリガを有するエンハンスメントを含んでいる。ＡＴＶＥＦアナウンスメントは、エンハンスメントデータが送信されていることを示し、リソースは、エンハンスメントデータの内容を含むファイルを備え、またトリガは、エンハンスメントデータをＡ／Ｖ内容の送信に同期させる。アナウンスメントは、リソースのストリーム及びトリガのストリームの両方の位置を記述することができる。
【００１５】
それぞれのＡ／Ｖチャネル（例えば、ＴＶチャネル）については、１つ以上のエンハンスメントを、ユーザに示す選択として提供することができる。ユーザは、どのエンハンスメントを、もしあれば、視聴するかを選択することができる。さらに、各エンハンスメントは複数の選択肢（例えば、異なった言語による選択肢）を有することができる。ＡＴＶＥＦ仕様は、提供されるエンハンスメントに関連するアナウンスメント，リソースのファイル，及びトリガを送信するために、マルチキャストプロトコル（例えば、ＩＰマルチキャスト）を利用することができる。ＩＰは、１９８１年９月発行の、「Internet Protocol」という表題の、「Request for Comment (RFC) 791」の中で記載されている。ＩＰマルチキャストプロトコルは、１９９２年２月付け発行の、「Multicast Transport Protocol」という表題のＲＦＣ１３０１の中に記載されている。ＲＦＣは、ウェブサイト[http://www.ietf.org/rfc.html]で利用することができる。さらに、一方向ＩＰマルチキャスト送信プロトコル（例えば、ＡＴＶＥＦ仕様の中で記載された「Unidirectional Hypertext Transfer Protocol」すなわち、ＵＨＴＴＰ）を使用して、リソースデータを配信することができる。
【００１６】
従来は、ＡＴＶＥＦアナウンスメントは、所定のＩＰアドレス及びポートに到達する。アナウンスメントの中には、ＡＴＶＥＦ仕様の中で指定されたリソース及びトリガのストリームの位置が、リソースのファイル及びトリガのファイルを見つけることができるＩＰアドレス及びポートとして記載されている。ＡＴＶＥＦアナウンスメントは、１９９８年４月に発行された「ＳＤＰ」すなわち、「Session Description Protocol」という表題のＲＦＣ２３２７の中で記述されているような、「Session Description Protocol (SDP)」のアナウンスメントとすることができる。
【００１７】
それぞれのＡＴＶＥＦアナウンスメントは、ＡＴＶＥＦプレゼンテーション又はアプリケーション（例えば、プログラム又はスクリプト）とすることができる別々のエンハンスメント用のものである。例としては、金融アプリケーション，スポーツアプリケーション，広告プログラム，ＴＶショーに直接関連するエンハンスメント，及び他のプレゼンテーション又はアプリケーションが含まれる。リソース及びトリガファイルの位置に加えて、アナウンスメントの中に含むことができる他の情報を以下に記載する。各アナウンスメントには、関連するエンハンスメントを識別するために、汎用固有識別子（ＵＵＩＤ）のような識別子が含まれる。アナウンスメントの中のフィールドは、送信されたエンハンスメントデータのバンド幅を示しており、これは秒当たりのキロビット（kbps）で表現されている。別のフィールドは、エンハンスメントを実行する間に必要とされるキャッシュ記憶の推定値を示す。バンド幅及びキャッシュ記憶用フィールドをレシーバプラットフォームが使用して、エンハンスメントを最初から最後までうまく実行できるかどうかを十分に判断する。アナウンスメントの中にある他のフィールドには、エンハンスメントデータを実行する言語の識別番号，エンハンスメントの開始及び終了時刻，及び他のタイプの情報が含まれる。アナウンスメントは、エンハンスメントの複数の選択肢に対応する複数のセクションに分離することができる。アナウンスメントがＳＤＰフォーマットの場合には、複数のセクションは媒体セクションとなる。
【００１８】
本発明のいくつかの実施形態によると、それぞれがリソースデータ又はトリガファイルのソースを参照する１つ以上のセクションを用いて、各選択肢を識別することができる。そのような実施形態では、各ソースは、エンハンスメントデータのレイヤーに対応している。このため、例えば、第１のレイヤーは第１のアドレスに配置されたソースを含み、第２のレイヤーは第２のアドレスに配置されたソースを含み、第３以降のレイヤーについても同様である。アナウンスメント内の各選択肢は、そのようなデータの複数のレイヤーを参照する。例えば、第１の選択肢は第１のアドレスにあるソースを参照し、第２の選択肢は第１のアドレスにあるソース及び第２のアドレスにある別のソースを参照し、以下同様である。レシーバプラットフォームは、このレシーバプラットフォームの能力（例えば、その記憶能力，処理速度，データ転送速度など）に基づいて、アナウンスメント内で識別された選択肢の１つを選択することができる。
【００１９】
ＡＴＶＥＦ仕様以外のプロトコルを別の実施形態の中で使用する場合には、アナウンスメントは、補助的情報が存在するそのような他のプロトコルが提供する全ての表示を参照する。さらに、そのような他のプロトコルは、補助的情報の内容及びタイミングすなわち同期情報を含むファイル又はパケットを提供することができる。
【００２０】
図２を参照すると、内容クリエータ１２及び（レシーバ１６のような）レシーバプラットフォームの中のコンポーネントが示されている。内容クリエータ１２は、内容クリエータ１２からのデータをリンク２４を介してトランスポートオペレータシステム１４に送信する送信ポート１０２を備えている。受信されたエンハンスメントデータは、１つ以上のレシーバプラットフォームに送信するように、トランスポートオペレータシステム１４によって処理される。内容クリエータ１２の中では、コントローラ１０６において実行可能なエンハンスメントデータ創作ルーチン１０８が、いくつかの実施形態に基づいて、レイヤーの中にエンハンスメントデータを創り出すことができる。創作ルーチン１０８は、初めは記録媒体１０４に記憶され、実行する場合にはコントローラ１０６によってロードされる。ユーザインターフェースモジュール１０５（ソフトウェア及び／又はハードウェアのコンポーネントから成る）により、１人以上のオペレータ又は開発者が、エンハンスメントデータのレイヤーが創り出される要求事項を入力することができる。
【００２１】
レシーバプラットフォーム（例えば、レシーバ１６）においては、レシーバモジュール１１４が搬送媒体２２に接続されている。搬送媒体２２に伝送されたデータは、レシーバモジュール１１４を通過する。搬送媒体２２から受信されたデータは、レシーバモジュール１１４を通過してレシーバプラットフォーム内の受信ディバイスドライバ１１８に入力される。この受信ディバイスドライバ１１８は、Ａ／Ｖ内容を切り離すことができる。このＡ／Ｖ内容は、Ａ／Ｖルーチン又はアプリケーション１１６に送られて、Ａ／Ｖ内容がプレゼンテーション又は配信用に処理される。受信ディバイスドライバ１１８は、エンハンスメントデータをエンハンスメント処理ルーチン１２０に進める。このように、搬送媒体２２上で受信されたストリームは、Ａ／Ｖ内容とエンハンスメントデータとに切り離され、エンハンスメントデータは、さらなる処理のためにエンハンスメント処理ルーチン１２０に送られる。
【００２２】
ディバイスドライバ１１８，エンハンスメント処理ルーチン１２０，及びＡ／Ｖルーチン１１６を含むレシーバプラットフォーム内のソフトウェアは、コントローラ１２２において実行することができる。このコントローラ１２２は、マイクロプロセッサ，マイクロコントローラ，又は他の適当なコントロールディバイスとすることができる。メモリ１２４がコントローラ１２２に接続されている。別の記憶装置１２６（実施例では、ハードディスクドライブのような大容量記憶装置とすることができる）にもコントローラ１２２はアクセス可能である。受信プラットフォームの能力（例えば、利用可能な記憶容量，処理速度，転送速度など）を記述する情報を含む能力情報ファイル１４０は、記憶装置１２６内に記憶することができる。本発明のいくつかの実施形態によれば、エンハンスメント処理ルーチン１２０は、各エンハンスメントに関連する利用可能な選択肢を決めるために、レシーバモジュール１１４及び受信ディバイスドライバ１１８を通って受信されるアナウンスメントを検査（すなわち、認識）することができる。与えられた選択肢に基づいて、エンハンスメント処理ルーチン１２０は、受信する選択肢の１つを選択することができる。
【００２３】
前に列挙した情報のカテゴリーに加えて、ＡＴＶＥＦアナウンスメントは、自身をアナウンスメントと識別するために、所定のストリング、例えば、「a=type:tve」を含むこともできる。下位互換性（逆互換性）を図るため、従来のＡＴＶＥＦシステムによる第１のタイプのアナウンスメントは、所定のストリング（記号列）を含むことができる。従来のＡＴＶＥＦシステムによる第１のタイプのアナウンスメントは、エンハンスメントの複数の選択肢を指定することができるが、１つの実施形態によるリソースファイルのレイヤー化は提供されない。従来のＡＴＶＥＦシステムによれば、新しいデータのソースがアナウンスメントの中で参照されるごとに、新しい選択肢が定義される。
【００２４】
本発明のいくつかの実施形態によれば、第２のタイプのアナウンスメントを、第１のタイプのアナウンスメントと一緒に送ることができる。この第２のタイプのアナウンスメントは、それぞれがリソースデータの１つ又はそれ以上のレイヤー（又はソース）に関連付けられる複数の選択肢を識別することができる。第２のタイプのアナウンスメントは、所定のストリング、例えば、「a=type:tve」なしで送信することができる。それに代えて、第２のタイプのアナウンスメントは、別の所定のストリング、例えば、「a=type:x2tve」を含んで、新しいタイプのアナウンスメントを受信したことを識別することができる。新しいタイプのアナウンスメントを受信することができるレシーバプラットフォームは、対応する第２のタイプのアナウンスメントと同じＡＴＶＥＦエンハンスメント識別子ＵＵＩＤを有する第１のタイプのアナウンスメント（例えば、ストリング「a=type:tve」を含むアナウンスメント）を無視するようにプログラムすることができる。
【００２５】
図３に示すように、情報配信システム１０の実施例は、比較的低い能力のレシーバ１６Ａ及び比較的高い能力のレシーバ１６Ｂを備えている。さらに異なる能力を持つ別のリザーバプラットフォームも備えることも可能である。図示した実施例では、ストリング「tve-alt:1」及び「tve-alt:2」によって識別された２つの選択肢が示されている。この実施形態では、Ｎ番目の選択肢が、ストリング「tve-alt:N」を用いて識別される。図示したように、（第２のタイプの）アナウンスメント３５０は、複数のセクション３００，３０２，３０４，３０６，３０８，及び３１０を備えている。セクション３１０は、エンハンスメントの識別子ＵＵＩＤ及び受信したアナウンスメントが第２のタイプであることを識別するための第２のタイプの所定のストリング、例えば、「a=type:x2tve」のような全般的な情報を含んでいる。セクション３００，３０２，３０４，３０６，及び３０８は、例えば、ＳＤＰフォーマットによる媒体セクションである。
【００２６】
各セクション３００〜３０８は、エンハンスメントデータ（リソースファイル又はトリガファイル）の１つのソースを示しており、アナウンスメント３５０に対応するエンハンスメントの複数の選択肢の１つに関連付けることができる。セクション３００は、アドレスＡ１に配置されたトリガファイルを識別し、「tve-alt:1」により示された第１の選択肢に関連付けられる。セクション３００は、トリガファイルに関連したバンド幅が１kbpsであることを示すこともできる。セクション３０２は、アドレスＡ２に配置されたリソースファイルを参照し、「tve-alt:1」によって示されるように第１の選択肢に関連付けられる。さらに、セクション３０２は、アドレスＡ２でリソースファイルを受信するためのバンド幅が１０kbpsで、キャッシュについての要求事項が１００kBであることも示している。バンド幅は、データを適切に受信及び処理するために必要なデータ転送速度のことを指す。キャッシュについての要求事項は、レシーバプラットフォームにおけるプレゼンテーションの間に、エンハンスメントデータを記憶するために必要とされる記憶容量のことを言う。バンド幅及びキャッシュ記憶についての要求事項は、エンハンスメントデータを受信及び処理するための能力の要求事項と呼ばれる。他のタイプの能力についての要求事項は、さらに別の実施形態の中に含まれる。
【００２７】
セクション３０４，３０６，及び３０８は、（「tve-alt:2」で識別されるように）第２の選択肢に関連付けられる。セクション３０４は、アドレスＡ３でトリガファイルを参照し（バンド幅は１kbps）、セクション３０６は、アドレスＡ２でリソースファイルを識別し（バンド幅は１０kbpsで、キャッシュの要求事項は１００kB）、またセクション３０８は、アドレスＡ４でリソースファイルを参照する（バンド幅は、１０００kbpsで、キャッシュの要求事項は５０００kB）。図示した実施例では、第２の選択肢に関連付けられたセクション３０６は、第１の選択肢に関連付けられたセクション３０２と同じリソースファイルのソース（アドレスＡ２に配置される）を参照する。さらに、第２の選択肢は、アドレスＡ４のソースからのリソースファイルの第２のレイヤーを含んでいる。
【００２８】
レシーバ１６Ａ（能力が比較的低いレシーバ）内のエンハンスメント処理ルーチン１２０は、アナウンスメント３５０を検査して、どの選択肢を選択するかを決定する。レシーバ１６Ａが第２の選択肢の要求事項を扱うことができない場合には、上述のエンハンスメント処理ルーチン１２０は、アドレスＡ１におけるストリーム（第１の選択肢のトリガ）及びアドレスＡ２におけるストリーム（第１の選択肢に関連するリソースファイル）を受信して第１の選択肢を選択する。別のレシーバ１６Ｂは、アナウンスメント３５０のその受信したコピーを検査して、どの選択肢を選択するかを決定する。レシーバ１６Ｂが第２の選択肢を処理することができる場合には、レシーバ１６Ｂは、アドレスＡ３におけるストリームからトリガを、またアドレスＡ２及びＡ４におけるストリームからリソースファイルを受信することを選択する。別の選択肢が、アナウンスメント３５０の中に存在する。図示した実施例では、低い能力のレシーバ１６Ａはテレビとする一方、高い能力のレシーバ１６Ｂはパーソナルコンピュータを備えることができる。
【００２９】
図４には、本発明の１つの実施形態に基づいてエンハンスメント処理ルーチン１２０によって実行されるタスクが記述されている。エンハンスメント処理ルーチン１２０は、エンハンスメントデータが受信されているかどうかを決定する（ステップ４０２）。これは、アナウンスメントを受信したかどうかを決定することにより実行される。アナウンスメントは、所定のストリング「a=type:tve」又は「a=type:x2tve」を含むパケットとすることができる。エンハンスメントデータを受信している場合には、ルーチン１２０は、１つ又はそれ以上の第２のタイプのアナウンスメント、例えば、ストリング「a=type:x2tve」を有するアナウンスメントが受信されているかどうかを決定する（ステップ４０４）。エンハンスメントデータを受信していない場合には、第１のタイプのアナウンスメント、例えば、ストリング「a=type:tve」を持つアナウンスメントが、従来のＡＴＶＥＦ技術により処理される（ステップ４１４）。第２のタイプのアナウンスメントを受信している場合には、同じエンハンスメント識別子（ＵＵＩＤ）を有するどのような第１のタイプのアナウンスメントも、ルーチン１２０により無視される（ステップ４０６）。次に、ルーチン１２０は、第２のタイプのアナウンスメントの中で示された選択肢を検査する（ステップ４０８）。別の選択肢に関連するセクションに含まれた情報に基づいて、例えば、能力情報ファイル１４０（図２参照）で決定されたような、受信プラットフォームの能力によって、ルーチン１２０は選択肢の１つを選択する（ステップ４１０）。能力情報ファイル１４０は、レシーバプラットフォームの能力を識別する情報を含んでいる。この能力は、処理ルーチン１２０によって、第２のタイプのアナウンスメント３５０において示されたバンド幅及びキャッシュについての要求事項と比較される。次に、ルーチン１２０は、選択された選択肢に関連する表示されたアドレスでストリームを受信する（ステップ４１２）。
【００３０】
図５には、内容クリエータ１２内のエンハンスメントデータ創作ルーチン１０８が実行するエンハンスメントデータ創作プロセスが示されている。所望のエンハンスメントプログラミングにより、創作ルーチン１０８は、エンハンスメントデータのレイヤーを創り出す（ステップ５０２）。このエンハンスメントプログラミングは、オペレータがユーザインターフェースモジュール１０５を介して指定し、また記憶装置１０４に記憶させることができる。前述したように、各レイヤーは、リソースファイル及びトリガファイルの異なったソースと関連付けることができる。次に、創作ルーチン１０８は、送信されるエンハンスメントに対応する１つ又はそれ以上のアナウンスメントを創り出す（ステップ５０４）。各アナウンスメントは、複数の選択肢及び関連するファイルのソースを識別する複数のセクションを含む。アナウンスメントは、バンド幅の情報及びキャッシュ記憶についての情報を含む能力についての要求事項を識別する情報も備えている。アナウンスメントは、トランスポートオペレータシステム１４の内容クリエータ１２によって、配信するために送信される（ステップ５０６）。
【００３１】
本発明のいくつかの実施形態には、以下のような１つ以上の利点がある。より高い能力のレシーバ１６Ｂについては、より高い品質のエンハンスメントデータをストリームから受信することができ、一方機能が少ない別のエンハンスメントデータは、能力が低いレシーバ１６Ａが同じストリームから受信することができる。エンハンスメントデータをレイヤー化することにより、より高い能力のレシーバプラットフォームに与えることができる機能及び選択肢を犠牲にすることなく、より広範な視聴に広げることができる。
【００３２】
（例えば、モジュール，ルーチン，又は他のレイヤーで作られた）各種のソフトウェアを、情報配信システムのディバイスの中の１つ又はそれ以上のマシンルート決め可能記憶媒体に記憶させる又は明白に具体化させることができる。ソフトウェアの命令を明白に具体化するに好適な記憶媒体には、ダイナミック又はスタティックランダムアクセスメモリ、消去可能プログラマブルリードオンリーメモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブルリードオンリーメモリ（ＥＥＰＲＯＭ）、及びフラッシュメモリなどの半導体メモリ装置；固定、フロッピー、及び取外し可能ディスクなどの磁気ディスク；テープを含む他の磁気媒体；及びＣＤ（コンパクトディスク）又はＤＶＤ（ディジタルビデオディスク）ディスクなどの光学媒体を含む、種々の形状のメモリが含まれる。１つ又はそれ以上の記憶媒体に記憶された命令は、実行される場合には、情報配信システム内の装置にプログラムされた動作を実行させる。
【００３３】
情報配信システム内のディバイスに多くの異なった方法の１つで、ソフトウェアをロードすることができる。例えば、１つ以上の記憶媒体に記憶された、又はネットワークのインターフェースカード、モデム又はインターフェース機構を介して送られた命令又は他のコードセグメントをシステムの中にロードして、プログラムされた動作を行うように実行させることができる。ローディング又はトランスポートプロセスの中で、搬送波が電話，ネットワークライン，ワイヤレスリンク，ケーブルなどを通して送信される場合に組み込まれるデータ信号は、命令又はコードセグメントを情報配信システム内のディバイスに送ることができる。
【００３４】
本発明を限られた数の実施形態に関連して説明してきたが、当業者はこれからの多くの修正及び変更を理解されよう。添付の特許請求の範囲の記載が、本発明の真の精神及び範囲の中に入る全てのそのような修正や変更をカバーするものとする。
【図面の簡単な説明】
【図１】  オーディオ／ビデオの内容に関連する補助的情報を通信する情報配信システムの実施形態を示すブロック図である。
【図２】  図１の情報配信システムにおける１つの実施形態による内容クリエータ及びレシーバプラットフォームのブロック図である。
【図３】  図２のレシーバプラットフォームによる、実施形態に係る送信情報のレイヤーの受信を示す図である。
【図４】  図２のレシーバプラットフォームにおける、実施形態に係るエンハンスメント処理ルーチンを示すフローチャートである。
【図５】  実施形態に基づいて補助的情報のレイヤーを作るための、図２の内容クリエータにおけるルーチンを示すフローチャートである。
【図１】
0003653494.tif 000002
【図２】
0003653494.tif 000003
【図３】
0003653494.tif 000004
【図４】
0003653494.tif 000005
【図５】
0003653494.tif 000006