(57)【特許請求の範囲】
【請求項１】
視聴覚コンテンツストリームをＭＰＥＧ−２プライベートセクションでカプセル化する方法であって、
ａ．既定値を、ｔａｂｌｅ＿ｉｄのフィールドに入れるステップと、
ｂ．連続的にインクリメントした値を、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れるステップと、
ｃ．前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドの値がｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れられた既定値（０から２５５まで）に達する時に、前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスは０でリスタートされるステップと、
ｄ．前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスがリスタートされる時に、連続的にインクリメントした値をｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れるステップと、
ｅ．前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドの値が該フィールドの最大既定値（１から３１まで）に達する時に、前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドのシーケンスは初期既定値（０から前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒの最大既定値−１まで）でリスタートされるステップと、
ｆ．前記ＭＰＥＧ−２プライベートセクションの最大既定サイズを超えないように、順番に、できるだけ多くの視聴覚コンテンツのチャンクまたはパッケージを、前記ＭＰＥＧ−２プライベートセクションのｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールド内に収まるように、該フィールドに追加するステップと、
ｇ．ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈおよびＣＲＣのフィールドに対して計算した値を入れるステップと、
ｈ．ＭＰＥＧ−２トランスポートストリームのパケットのシーケンスにおける前記ＭＰＥＧ−２プライベートセクションを分割し、該分割したもの全てについてｐａｃｋｅｔ＿ｉｄ（ＰＩＤ）のフィールドに同じ既定値を入れるステップと、
を含む方法。
【請求項２】
前記視聴覚コンテンツストリームは、ＲＴＰ制御パッケージ、ＲＴＰパッケージ、ＲＴＳＰパッケージ、またはそれらの組み合わせを含む、請求項１に記載の方法。
【請求項３】
前記ＭＰＥＧ−２プライベートセクションの一部は、ＲＴＰセッション記述子で構成される、請求項２に記載の方法。
【請求項４】
前記視聴覚コンテンツストリームは、前記ＭＰＥＧ−２トランスポートストリームのパッケージのストリームに含まれる、請求項１に記載の方法。
【請求項５】
ＭＰＥＧ−２トランスポートストリームで多重送信されるように視聴覚コンテンツをＭＰＥＧ−２プライベートセクションでカプセル化するためのデバイスであって、
前記デバイスは、視聴覚コンテンツストリームを受信する入力、生成された前記ＭＰＥＧ−２プライベートセクションのシーケンスを出力する出力、および、プロセッサ、ＲＡＭメモリ、および、繰り返し実行される符号化された命令のセットを含む電子回路を備え、
前記命令のセットは、
ａ．既定値を、ｔａｂｌｅ＿ｉｄのフィールドに入れるステップと、
ｂ．連続的にインクリメントした値を、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れるステップと、
ｃ．前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドの値がｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れられた既定値（０から２５５まで）に達する時に、前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスは０でリスタートされるステップと、
ｄ．前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドのシーケンスがリスタートされる時に、連続的にインクリメントした値をｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れるステップと、
ｅ．前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドの値が該フィールドの最大既定値（１から３１まで）に達する時に、前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドのシーケンスは初期既定値（０から前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒの最大既定値−１まで）でリスタートされるステップと、
ｆ．前記ＭＰＥＧ−２プライベートセクションの最大既定サイズを超えないように、順番に、できるだけ多くの前記視聴覚コンテンツのチャンクまたはパッケージを、前記ＭＰＥＧ−２プライベートセクションのｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールド内に収まるように、該フィールドに追加するステップと、
ｇ．ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈおよびＣＲＣのフィールドに対して計算した値を入れるステップと、
ｈ．前記ＭＰＥＧ−２トランスポートストリームのパケットのシーケンスにおける前記ＭＰＥＧ−２プライベートセクションを分割し、該分割したものの全てについてｐａｃｋｅｔ＿ｉｄ（ＰＩＤ）のフィールドに同じ既定値を入れるステップと、
を含む、デバイス。
【請求項６】
請求項５に記載のＭＰＥＧ−２トランスポートストリームで多重送信されるように視聴覚コンテンツをＭＰＥＧ−２プライベートセクションでカプセル化するためのデバイスであって、
前記視聴覚コンテンツストリームは、ＲＴＰ制御パッケージ、ＲＴＰパッケージ、ＲＴＳＰパッケージ、またはそれらの組み合わせを含む、デバイス。
【請求項７】
請求項６に記載のＭＰＥＧ−２トランスポートストリームで多重送信されるように視聴覚コンテンツをＭＰＥＧ−２プライベートセクションでカプセル化するためのデバイスであって、
ＭＰＥＧ−２プライベートセクションの一部は、ＲＴＰセッション記述子で構成される、デバイス。
【請求項８】
請求項５に記載のＭＰＥＧ−２トランスポートストリームで多重送信されるように視聴覚コンテンツをＭＰＥＧ−２プライベートセクションでカプセル化するためのデバイスであって、
前記視聴覚コンテンツストリームは、前記ＭＰＥＧ−２トランスポートストリームのパッケージのストリームに含まれる、デバイス。
【請求項９】
デジタルＴＶ信号放送を通じて、デジタルＴＶ信号放送をチューニングする能力がないユーザデバイスに、視聴覚コンテンツおよび／またはデータを配信する方法であって、
ａ．視聴覚コンテンツのストリームを、ＭＰＥＧ−２プライベートセクションでカプセル化するステップであって、
ｉ．既定値を、ｔａｂｌｅ＿ｉｄのフィールドに入れるステップと、
ｉｉ．連続的にインクリメントした値を、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れるステップと、
ｉｉｉ．前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドの値がｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れられた既定値（０から２５５まで）に達する時に、前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスは０でリスタートされるステップと、
ｉｖ．前記ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドのシーケンスがリスタートされる時に、連続的にインクリメントされる値をｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドに入れるステップと、
ｖ．前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドの値が該フィールドの最大既定値（１から３１まで）に達する時に、前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドのシーケンスは初期既定値（０から前記ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒの最大既定値−１まで）でリスタートされるステップと、
ｖｉ．前記ＭＰＥＧ−２プライベートセクションの最大既定サイズを超えないように、順番に、できるだけ多くの前記視聴覚コンテンツのチャンクまたはパッケージを、前記ＭＰＥＧ−２プライベートセクションのｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールド内に収まるように、該フィールドに追加するステップと、
ｖｉｉ．ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈおよびＣＲＣのフィールドに対して計算した値を入れるステップと、
ｖｉｉｉ．ＭＰＥＧ−２トランスポートストリームのパケットのシーケンスにおける前記ＭＰＥＧ−２プライベートセクションを分割し、かつ、該分割したものの全てについてｐａｃｋｅｔ＿ｉｄ（ＰＩＤ）のフィールドに同じ既定値を入れるステップと、を含むステップと、
ｂ．デジタルＴＶ信号放送を形成するＭＰＥＧ−２トランスポートストリーム内のＭＰＥＧ−２プライベートセクションを多重送信するステップと、
ｃ．対話型アプリケーションを前記デジタルＴＶ信号放送に含めるステップと、
ｄ．前記デジタルＴＶ信号放送をデジタルＴＶ受信機でチューニングするステップと、
ｅ．前記デジタルＴＶ信号を復号し、かつ、前記デジタルＴＶ受信機においてメインＴＶコンテンツを再現するステップと、
ｆ．前記デジタルＴＶ受信機の実行環境において、前記デジタルＴＶ信号放送内で受信される前記対話型アプリケーションを実行するステップと、
ｇ．前記対話型アプリケーション内で実装されるデータネットワーク用の通信プロトコルを使用して、ローカルエリアネットワークに接続される他のユーザデバイスを発見し、かつ、前記視聴覚コンテンツおよび／または前記データの利用可能性を通知するステップと、
ｈ．前記ユーザデバイスにおいてまたは前記ユーザデバイスにインストールされたアプリケーションによって実装される前記データネットワーク用の通信プロトコルを使用して、
ｉ．前記対話型アプリケーション内で実装される前記データネットワーク用の通信プロトコルを使用して、配信を要求した前記ユーザデバイスに、前記視聴覚コンテンツおよび／または前記データを配信するステップと、
ｊ．前記視聴覚コンテンツおよび／または前記データの配信を前記対話型アプリケーションに要求する前記ユーザデバイスにおいて、前記ユーザデバイス、または、前記ユーザデバイスにインストールされるアプリケーションによって、実装された前記データネットワーク用の通信プロトコルを使用して、前記視聴覚コンテンツおよび／または前記データを受信するステップと、
ｋ．要求される前記視聴覚コンテンツおよび／または前記データを前記ユーザデバイスにおいて復号、処理、および再生を可能にするステップと、を含む方法。
【請求項１０】
前記ＴＶ信号放送は、地上波、衛星、または有線によるものである、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタルＴＶ放送の分野の方法、デバイス、および対話型アプリケーション、ならびに、デジタルＴＶのチューニングリソースを有さないユーザデバイスに関する。特に、本発明は、既に入手可能なデータ放送技術を使用して、放送デジタルＴＶ信号によって、デジタル信号をチューニングするためのリソースを有さないユーザデバイスへのコンテンツおよび／またはデータの伝送を可能にするデジタルＴＶ放送の分野の方法、デバイスならびに対話型アプリケーションに関する。
【背景技術】
【０００２】
特許出願の国際公開第２０１３／１０４０４４号パンフレットは、インターネットアクセス付きまたは無しの複数の携帯型ユーザデバイスと、デジタルＴＶ受信機によって受信されるデジタルＴＶ信号におけるコンテンツとを同期させるための技法を記載している。さらに、この文献は、ＩＳＯ１３８１８−６に記載されるように、ＤＳＭＣＣデータ（またはオブジェクト）カルーセルを使用して、放送デジタルＴＶ信号における対話型アプリケーションの伝送方法を記載している。この対話型アプリケーションは、デジタルＴＶミドルウェアとしても知られているデータ放送実行環境内のデジタルＴＶ受信機によって復号されかつ実行され、かかる実行環境において利用可能なＡＰＩを使用して、デジタルＴＶ受信機が接続される同じローカルエリアネットワーク（ＬＡＮ）に接続される他のデバイスを見出し、かつ、それら他のデバイスへ、ＤＳＭＣＣデータ（またはオブジェクト）カルーセルにおける対話型アプリケーションと共に伝送されているコンテンツを転送する。また、放送局によって送られるコンテンツと、ユーザデバイスに示されるコンテンツとを同期するためのこの方法による能力が記載されている。ユーザデバイスは、多くの場合、コンパニオンデバイスとしても知られている、第二画面アプリケーションを作動させているタブレットまたはスマートフォンなどの第二画面デバイスであってよい。
【０００３】
この技法の不利点は、ユーザデバイスに配信できるコンテンツの全体のサイズが、ＤＳＭＣＣデータカルーセルで伝送できるもののサイズに制限されることである。また、利用可能なコンテンツおよびコンテンツの同期の応答時間は、ＤＳＭＣＣデータカルーセル更新のダウンロードを完了するためにデジタルＴＶ受信機によって必要とされる、普通は１０秒以上の時間によって限定される。これらの制限は、例えば１０秒を上回るビデオファイルといった非常に長い視聴覚コンテンツか、さらには、例えばライブビデオストリームといったライブコンテンツの配信を実行不可能にする。
【０００４】
ＩＳＯ１３８１８−１規格ではＭＰＥＧ−２システム、とりわけ、ＭＰＥＧ−２プライベートセクションについて定めている。ＭＰＥＧ−２プライベートセクションは、デジタルＴＶ用ＭＰＥＧ−２トランスポートストリームに含まれ得るデータ構造である。ＰＳＩとして知られているこれらの構造のセットは、通常は、オーディオ、ビデオ、字幕、クローズドキャプション、ＤＳＭＣＣカルーセルおよびストリームイベント、対話型アプリケーション信号方式などのエレメンタリストリーム、または、電子番組ガイド（ＥＰＧ）を供給するチャンネルプログラミング情報といった、サービスおよびそれらのコンポーネントをリスト化しかつ特定するＭＰＥＧ−２トランスポートストリームを記述するメタデータを含むために使用される。これらの構造は、識別子として、ｐａｃｋｅｔ＿ｉｄ（ＰＩＤ）およびｔａｂｌｅ＿ｉｄ（ＴＩＤ）を有する。ＰＩＤおよびＴＩＤのいくつかの値は、デジタルＴＶシステムにおける特定機能のために確保されるが、いくつかの他の確保されない識別子は、任意の他のタイプの情報の伝送用に使用できる。図３は、ＭＰＥＧ−２プライベートセクションの構造について詳述している。ＭＰＥＧ−２プライベートセクション構造の最大サイズは４０９５バイトまでに限定される。
【０００５】
デジタルＴＶのいくつかの対話型システムは、対話型アプリケーションがデジタルＴＶ受信機によって受信されるＭＰＥＧ−２トランスポートストリームからＭＰＥＧ−２プライベートセクション構造を抽出することを可能にするためのＡＰＩまたは機構を含むことも、当業者には既知である。例として、ＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓは、Ｇｌｏｂａｌｌｙ  Ｅｘｅｃｕｔａｂｌｅ  ＭＨＰ（ＧＥＭ）、またはブラジル標準ＡＢＮＴ  ＮＢＲ  １５６０６−６に定められるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇに基づくシステムに存在することが言える。
【０００６】
近年では、タブレットおよびスマートフォンなどの携帯型デバイスの数の増加に伴って、第二画面デバイスまたは第二画面アプリケーションの概念はエンターテインメント分野、特にＴＶ分野で高まっている。一般的に、第二画面による解決策は、ユーザが、ＴＶ受信機に表示されるメインコンテンツ、すなわち、第一画面を補足する視聴覚コンテンツおよび／またはデータにアクセスできるようにする。これらの解決策の多くは、インターネットアクセスが補足コンテンツを検索しかつ表示するために第二画面デバイスを利用可能であるかに左右される。このタイプの解決策の不利点は、サーバのインフラストラクチャおよび帯域幅が大量の同時に行われるアクセス、例えば、１２００万以上もの同時に行われるアクセスを確実にサポートできるように、放送局側で投資およびメンテナンスに高額を費やす場合があることである。他方で、メインＴＶコンテンツが伝送される同デジタルＴＶ信号放送においてこれらの補足コンテンツを提供することははるかに経済的効率が良い。後述される図１は、インターネットを通して補足コンテンツをユーザデバイスに配信するための方法の概要を示す。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は、デジタルＴＶ信号放送を受信する能力がないユーザデバイスにデジタルＴＶ信号放送で伝送される視聴覚コンテンツおよび／またはデータを配信するための、方法、ＭＰＥＧ−２プライベートセクションカプセル化デバイス、対話型アプリケーション、データネットワーク用通信プロトコル、および他の機構に関する。
【課題を解決するための手段】
【０００８】
いくつかの実装形態では、本発明による、デジタルＴＶ信号放送を受信する能力がないユーザデバイスに視聴覚コンテンツおよび／またはデータを配信するための方法は、視聴覚コンテンツをユーザデバイスにおいて再現できるフォーマットに適応させる（またはトランスコーディングする）ためのデバイスを含む。これらの適応処理は、例えば、ビデオの解像度およびアスペクト比、オーディオおよびビデオビットレート、ならびに、オーディオおよびビデオ符号化の調整を含むことができる。
【０００９】
本発明によるいくつかの実装形態では、方法は、適応させた視聴覚コンテンツおよび／またはデータをＭＰＥＧ−２プライベートセクションでカプセル化し、かつ、デジタルＴＶ信号放送で伝送されるようにＭＰＥＧ−２トランスポートストリームでの後の多重送信のためにＭＰＥＧ−２トランスポートストリームパケットのストリームでシリアル化するためのＭＰＥＧ−２プライベートセクションカプセル化デバイスを含む。
【００１０】
本発明によるいくつかの実装形態では、デジタルＴＶ信号放送で伝送される同ＭＰＥＧ−２トランスポートストリームにおいて、デジタルＴＶ受信機による実行用の対話型アプリケーションは多重化されかつ伝送される。予想できるように、このＭＰＥＧ−２トランスポートストリームは、メインＴＶコンテンツ、すなわち、オーディオ、ビデオ、クローズドキャプション／字幕なども含む。
【００１１】
本発明によるいくつかの実装形態では、デジタルＴＶ受信機はＴＶセットまたはセットトップボックスとすることができる。デジタルＴＶ受信機は、デジタルＴＶ信号放送にチューニングする時、ＭＰＥＧ−２トランスポートストリームを復号し、かつ、デジタルＴＶ受信機の画面およびスピーカーにおいて、オーディオ、ビデオ、クローズドキャプション／字幕であるメインＴＶコンテンツを再現する。あるいは、セットトップボックスの場合、これらのコンテンツは対応するオーディオおよびビデオ出力から出力される。さらには、デジタルＴＶ受信機は、対話型アプリケーションをその受信機の実行範囲内で、または、ＭＨＰ、Ｇｉｎｇａなどの対話型デジタルＴＶミドルウェア内で復号かつ実行する。対話型アプリケーションは、視聴覚コンテンツおよび／またはデータをＭＰＥＧ−２トランスポートストリームからカプセル化するＭＰＥＧ−２プライベートセクションを抽出するための実行環境で利用可能なＡＰＩを使用する。これらのＡＰＩの例として、Ｇｌｏｂａｌｌｙ  Ｅｘｅｃｕｔａｂｌｅ  ＭＨＰ（ＧＥＭ）仕様、またはブラジル標準ＡＢＮＴ  ＮＢＲ  １５６０６−６によって指定されるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇに基づくシステムの、ＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓが挙げられ得る。
【００１２】
本発明によるいくつかの実装形態では、デジタルＴＶ受信機はローカルエリアネットワーク（ＬＡＮ）に接続される。このＬＡＮは、有線（イーサネット）（イーサネットは登録商標。以下同じ）は、無線（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎまたは同様のものなど）、または、有線および無線の両方のタイプの組み合わせとすることができる。
【００１３】
本発明によるいくつかの実装形態では、対話型アプリケーションおよびユーザデバイスによって、これらの間で同じＬＡＮに接続される時の通信のために、ＩＰネットワークに基づいて、データネットワーク用通信プロトコルが実装される必要がある。
【００１４】
本発明によるいくつかの実装形態では、データネットワーク用通信プロトコルは、対話型アプリケーションおよびユーザデバイスが同じＬＡＮにおける互いの存在を認識できるようにする発見機構を提供する。
【００１５】
本発明によるいくつかの実装形態では、この発見機構は、対話型アプリケーションがその存在をユーザデバイスに通知すること、ユーザデバイスがそのデバイス各々の存在を対話型アプリケーションに通知すること、または、これら両方の任意の組み合わせを必要とする場合がある。
【００１６】
本発明によるいくつかの実装形態では、データネットワーク用通信プロトコルは、視聴覚コンテンツ通知機構、および、ユーザデバイスが対話型アプリケーションを通して利用可能であるコンテンツを認識できるようにするデータ通知機構を提供する。これらの機構のいくつかの実装形態では、対話型アプリケーションがかかるコンテンツの利用可能性を通知すること、ユーザデバイスが一定時間内で利用可能であるコンテンツについて対話型アプリケーションに問い合わせすること、または、これらの任意の組み合わせが必要とされる場合がある。
【００１７】
本発明によるいくつかの実装形態では、データネットワーク用通信プロトコルは、ユーザデバイスが、ＭＰＥＧ−２トランスポートストリームから抽出された視聴覚コンテンツおよび／またはデータを配信するように対話型アプリケーションに要求できるようにする視聴覚コンテンツ要求機構およびデータ要求機構を提供する。
【００１８】
本発明によるいくつかの実装形態では、データネットワーク用通信プロトコルは、対話型アプリケーションが、ＭＰＥＧ−２トランスポートストリームから抽出された視聴覚コンテンツおよび／またはデータをユーザデバイスに配信できるようにする視聴覚コンテンツ配信機構およびデータ配信機構を提供することができる。
【００１９】
本発明によるいくつかの実装形態では、ユーザデバイスは、対話型アプリケーションによって配信された視聴覚コンテンツおよび／またはデータを受信できるものとし、かつ、復号プロセス、処理および解釈を行って、そのデバイスの各々の画面およびスピーカーで視聴覚コンテンツおよび／もしくはデータを再生するならびに／または呈示することができるものとする。
【００２０】
本発明によるいくつかの実装形態では、ユーザデバイスは、タブレット、スマートフォン、パーソナルコンピュータ、および、ＬＡＮに接続でき、かつ、画面、およびスピーカーまたはヘッドフォンなどのオーディオ出力を有する任意の他のデバイス、または、これらの要素の任意の組み合わせであってよい。
【００２１】
本発明によるいくつかの実装形態では、ユーザデバイスは、本明細書に記載される動き、機能性、およびプロトコルをサポートするための１つまたは複数のアプリケーションを実行することができる。
【図面の簡単な説明】
【００２２】
【図１】インターネットを使用してユーザデバイスに補足コンテンツを配信するための既存の方法の概要を示すブロック図である。
【図２】デジタルＴＶ信号放送のチューニング能力がないユーザデバイスに視聴覚コンテンツおよび／またはデータを配信するための方法の概要を示すブロック図である。
【図３】デジタルＴＶ信号放送のチューニング能力がないユーザデバイスに視聴覚コンテンツおよび／またはデータを配信するための伝送プロセスを示すブロック図である。
【図４】ＭＰＥＧ−２プライベートセクションの論理構造を示す図である。
【図５】図５は、各機構を概略の説明図である。
【図６】図６は、各機構の詳細な説明図である。
【発明を実施するための形態】
【００２３】
技術的問題点
本発明の目的は、デジタルＴＶ信号放送を受信する能力がないユーザデバイスにデジタルＴＶ信号放送で伝送される視聴覚コンテンツおよび／またはデータを配信するための手段を提供することである。ユーザデバイスの例には、メイン画面またはメインデバイスとしても知られているデジタルＴＶ受信機に再生されるメインＴＶコンテンツを補足するコンテンツにアクセスするために第二画面デバイスとして使用されるタブレットまたはスマートフォンを挙げることができる。このような補足コンテンツは、例えば、ビデオクリップおよび／もしくはオーディオ、ライブビデオ放送などの視聴覚コンテンツ、または、例えば、テキスト、写真、統計データなどのデータであってよい。通常、補足コンテンツは、メインＴＶコンテンツに関連があるものとすることができるが、これは必要条件ではない。
【００２４】
かかるユーザデバイスにおいてデジタルＴＶ信号放送を受信する能力がないことによって、一般的に、補足コンテンツはインターネット接続によって受信される。
【００２５】
図１は、コンテンツ制作者（４００）が、デジタルＴＶ受信機（４１２）の画面およびスピーカーにおいて再現されるメインＴＶコンテンツであるデジタルＴＶ信号放送（４１０）を生成しかつ伝送するデジタルＴＶ放送局（４０４）にメインＴＶコンテンツ（４０２）を送信する状況を示す。並行して、コンテンツ制作者（４００）は、通常は、視聴覚コンテンツおよび／またはデータ（４１４）である補足コンテンツを、インターネット（４２０）に接続されるデジタルＴＶ放送局のサーバ（４１６）へ配信する。ユーザデバイス（４２２）は、補足コンテンツ（４１８）をデジタルＴＶ放送局のサーバ（４１６）から取り込み、かつ、このコンテンツをこれらデバイスの各々の画面に呈示する。要求されるデジタルＴＶ放送局のサーバの帯域幅（４２４）およびサーバ（４１６）は、補足コンテンツ（４１８）を要求するユーザデバイス（４２２）の数に従って増加する。よって、このタイプのコンテンツを配信するためにインターネットを使用すると、以下の欠点は不可避である。
ａ．局のそばにおけるブロードバンドおよびサーバインフラストラクチャへの投資は、補足コンテンツにアクセスするユーザ数に比例して増加する。
ｂ．配信の信頼性およびユーザ体験は、ユーザ側のインターネットアクセスの帯域幅および品質によって影響を受ける可能性がある。
【００２６】
加えて、対話型ＴＶとしても知られている上述されるシステムのデータ放送において使用されるカルーセル技法には、ＤＳＭＣＣデータカルーセルまたはＤＳＭＣＣオブジェクトカルーセルプロトコル（ＩＳＯ１３８１８−６）を使用するビデオコンテンツまたはライブビデオコンテンツといった大きなファイルを配信できないという、カルーセルで送られる最大サイズのコンテンツに関連する限界がある。
【００２７】
本発明は、ユーザ側のインターネットアクセスの利用可能性に関係なく、信頼できる配信および保証されたユーザ体験と共に、追加の費用がかからずに、上述されるようなインターネットを使用したコンテンツ配信の欠点を回避して、デジタルＴＶ信号放送で使用されない帯域幅を使用した補足コンテンツの配信を可能にする。
【００２８】
技術的解決策−概要
本発明は、ライブオーディオまたはビデオストリームを含む、継続時間またはサイズが限定されることのないオーディオまたはビデオストリームなどの補足コンテンツの配信を可能にする。
【００２９】
図２は本発明の概要を示す。コンテンツ制作（１００）のプロセスは、オーディオ、ビデオ、字幕および／またはクローズドキャプション、ならびに、通常は従来のデジタルＴＶ信号放送サービスによって生成される任意の他のコンテンツを含むメインＴＶコンテンツ（１０２）をもたらす。加えて、コンテンツ制作（１００）は、ユーザデバイスにおける再生用の視聴覚コンテンツ（１０４）とも呼ばれる補足コンテンツをもたらす。ＭＰＥＧ−２トランスポートストリームとして符号化されるデジタルＴＶ信号放送（１１０）の視聴覚コンテンツおよび／またはデータ（１０４）を抽出すること、および、このようなコンテンツおよび／またはデータをユーザデバイスに転送することができる対話型アプリケーション（１０６）も提供される。デジタルＴＶ放送局（１０８）は、メインＴＶコンテンツ（１０２）、視聴覚コンテンツおよび／またはデータ（１０４）、ならびに対話型アプリケーション（１０６）を含むデジタルＴＶ信号放送を生成しかつ伝送する。
【００３０】
デジタルＴＶ受信機（１１２）は、ＭＰＥＧ−２トランスポートストリームを復号し、かつ、メインＴＶコンテンツ、すなわちオーディオ、ビデオ、クローズドキャプション／字幕などを再現するためにデジタルＴＶ信号放送をチューニングするか、あるいは、セットトップボックスの場合、コンテンツは各オーディオおよびビデオ出力から出力される。
【００３１】
デジタルＴＶ受信機はまた、対話型アプリケーション（１１８）をその受信機の実行環境（１１６）内で復号かつ実行する。実行環境の例には、ＭＨＰ、Ｇｉｎｇａなどの対話型デジタルＴＶミドルウェアを挙げることができる。対話型アプリケーション（１１８）は、カプセル化された視聴覚コンテンツおよび／またはデータ（１２０）で構成されているＭＰＥＧ−２プライベートセクションをＭＰＥＧ−２トランスポートストリームから抽出するための実行環境（１１６）で利用可能なＡＰＩを使用する。これらのＡＰＩの例として、Ｇｌｏｂａｌｌｙ  Ｅｘｅｃｕｔａｂｌｅ  ＭＨＰ（ＧＥＭ）仕様、およびブラジル標準ＡＢＮＴ  ＮＢＲ  １５６０６−６によって指定されるｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇのＡＰＩに基づくシステムで利用可能なＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓが挙げられ得る。
【００３２】
デジタルＴＶ受信機（１１２）を、有線（例えばイーサネット）、無線（例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎネットワークまたは同様のものなど）、または、有線および無線の両方のタイプの組み合わせとすることができるＬＡＮ（１２２）に接続させる必要がある。
【００３３】
また、ユーザデバイス（１２６）が視聴覚コンテンツおよび／またはデータを受信しかつ再現できるようにするために、これらデバイスは、デジタルＴＶ受信機（１１２）と同じＬＡＮ（１２２）で接続される必要がある。例として、ユーザデバイス（１２６）は、タブレット、スマートフォン、パーソナルコンピュータ、または、ＬＡＮ（１２２）に接続でき、かつ、画面、および／または、スピーカーまたはヘッドフォンなどのオーディオ出力を有する任意の他のデバイスとすることができる。いくつかの実装形態では、ユーザデバイス（１２６）は、本発明によってこれらデバイスによるものである動き、機能性およびプロトコルを実装するために１つまたは複数のアプリケーションをホストとして処理しかつ実行できる。
【００３４】
技術的解決策−放送局側
本発明のプロセスにおいて入力されるのは、現状技術のコンテンツ制作（２００）ワークフローによって生成されるコンテンツである。コンテンツ制作（２００）は、オーディオ、ビデオ、字幕、クローズドキャプション、および、一般的に従来のデジタルＴＶ放送サービスのために生成されることが多い任意の他のコンテンツを含むメインＴＶコンテンツ（２０２）をもたらす。さらに、コンテンツ制作（２００）は、ユーザデバイスにおける再生用の視聴覚コンテンツ（２０４）とも呼ばれる補足コンテンツをもたらす。
【００３５】
コンテンツ制作（２００）によってもたらされるような、ユーザデバイスにおける再生用の視聴覚コンテンツ（２０４）の場合、ユーザデバイスにおいて再現されるように、または、小さなチャンクに分けて伝送されるように適応させる必要があり、トランスコーダデバイス（２０６）は、視聴覚コンテンツを再符号化するために使用される。かかる適応処理は、例えば、ビデオ解像度およびそのアスペクト比、オーディオおよびビデオビットレート、ならびに、オーディオおよびビデオ符号化の調整、および、視聴覚コンテンツをストリームとして送信可能なフォーマットに変換する必要がある可能性がある任意の他の調整を含むことができる。ストリームとして送信できるフォーマットの例として、ＭＰＥＧ−２トランスポートストリームプロトコル、ＲＴＰ／ＲＴＰＳ、ＨＬＳなどで使用されるものの任意のものが挙げられ得る。トランスコーダデバイス（２０６）は、ユーザデバイスにおいて再生されるように適応された視聴覚コンテンツ（２０８）を出力する。このステップは、コンテンツ制作（１００）（２００）によってもたらされる視聴覚コンテンツが、既に、ユーザデバイスにおいて再生される（２０８）のに、かつ、ストリーム形式で伝送されるのに適したフォーマットである場合は無視できる。
【００３６】
ユーザデバイスにおいて再生されるように既に適応させている視聴覚コンテンツ（２０８）は、その後、ＭＰＥＧ−２プライベートセクションカプセル化デバイス（２１２）によってＭＰＥＧ−２プライベートセクションでカプセル化される。ＭＰＥＧ−２プライベートセクションカプセル化デバイス（２１２）は、以下のステップから成る方法を使用してＭＰＥＧ−２プライベートセクションのシーケンスを生成する。
ａ．既定値を、ｔａｂｌｅ＿ｉｄのフィールドに割り当てる。
ｂ．連続的にインクリメントさせる値を、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに割り当てる。
ｃ．ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドの値がｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドに割り当てられた（０から２５５までの）既定値に達する度に、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスは０でリスタートされる。
ｄ．ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのシーケンスがリスタートされる度に、連続的にインクリメントさせる値を、ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドに割り当てる。
ｅ．ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドの値が（１から３１までの）このフィールドの最大既定値に達する度に、シーケンスは（０からｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒの最大既定値−１までの）既定の初期値でリスタートされる。
ｆ．ＭＰＥＧ−２プライベートセクションに対して定められた最大既定サイズ（大抵の場合、最大既定サイズは４０９５バイト）を超えないように、順番に、できるだけ多くの視聴覚コンテンツ（２０８）のチャンクまたはパッケージをこのフィールド内に収めるように、ＭＰＥＧ−２プライベートセクションのｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールドに追加する。
ｇ．ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈおよびＣＲＣのフィールドに対して値を計算しかつ設定する。
ｈ．ＭＰＥＧ−２トランスポートストリームパケット（２１４）のシーケンスにおけるＭＰＥＧ−２プライベートセクションを分割し、かつ、それらの全てに、ｐａｃｋｅｔ＿ｉｄ（ＰＩＤ）のフィールドに対する同じ既定値を設定する。
ｉ．生成されたＭＰＥＧ−２トランスポートストリームパケット（２１４）をＭＰＥＧ−２トランスポートストリームマルチプレクサ（２２２）に配信する。
【００３７】
（ａ）から（ｉ）までのステップが継続的に繰り返される間、視聴覚コンテンツは利用可能である。
【００３８】
上記方法のステップ（ｆ）の変形例によって、視聴覚コンテンツのチャンクまたはパッケージを、生成されるＭＰＥＧ−２プライベートセクションの現在のものと次のものとの間で分割することができ、適用可能となる度に、ＭＰＥＧ−２プライベートセクションが可能とされる最大サイズを有する限り適用可能となる（ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈのフィールド−通常は４０９５バイト）。このアプローチは、より少ないＭＰＥＧ−２プライベートセクションでより多くの視聴覚コンテンツのチャンクおよびパッケージを配信させることができるため、より効果的である。
【００３９】
本発明によるいくつかの実装形態では、トランスコーダデバイスは、後にＭＰＥＧ−２プライベートセクションカプセル化デバイスによってＭＰＥＧ−２プライベートセクションでカプセル化される、ＲＴＰ制御パッケージ、ＲＴＰおよびＲＴＰセッション記述子パッケージで構成されているストリームのフォーマットでユーザデバイスに呈示するように適応させた視聴覚コンテンツを提供することができる。
【００４０】
本発明による他の実装形態では、トランスコーダデバイスは、後にＭＰＥＧ−２プライベートセクションカプセル化デバイスによってＭＰＥＧ−２プライベートセクションでカプセル化される、ＭＰＥＧ−２トランスポートストリームパッケージで構成されているストリームのフォーマットでユーザデバイスに呈示するように適応される視聴覚コンテンツを提供できる。
【００４１】
ユーザデバイスに呈示するように適応された視聴覚コンテンツ（２０８）に加えて、ＭＰＥＧ−２プライベートセクションカプセル化デバイス（２１２）は、ユーザデバイスによって解釈できる包括的なデータ（２１０）のチャンクまたは構造で構成されているＭＰＥＧ−２プライベートセクションを生成することができる。カプセル化プロセスは、ユーザデバイスに呈示するために適応された視聴覚コンテンツ（２０８）について説明されるものと全く同じである。
【００４２】
さらに、デジタルＴＶ受信機による実行用の対話型アプリケーション（２１６）は、対話型アプリケーションのエンコーダデバイス（２１８）によって符号化される。
【００４３】
メインＴＶコンテンツＴＶ（２０２）、符号化された対話型アプリケーション（２２０）、およびＭＰＥＧ−２プライベートセクションでカプセル化された視聴覚コンテンツおよび／またはデータ（２１４）は、デジタルＴＶ信号放送で伝送される（２２６）のに適したＭＰＥＧ−２トランスポートストリーム信号（２２４）を生成することになるＭＰＥＧ−２トランスポートストリームマルチプレクサ（２２２）へ転送される。最後に、デジタルＴＶ伝送デバイス（２２６）はデジタルＴＶ信号放送を伝送する。これらの伝送信号の例として、地上波ＴＶ無線周波数信号、衛星ＴＶ信号、またはケーブルＴＶ信号が挙げられ得る。
【００４４】
技術的解決策−受信側
デジタルＴＶ受信機（１１２）は、デジタルＴＶ信号放送にチューニングし、ＭＰＥＧ−２トランスポートストリームを復号し、メインＴＶコンテンツ、すなわち、オーディオ、ビデオ、クローズドキャプション／字幕などをこの受信機の画面およびスピーカ（１１４）で再現する。あるいは、セットトップボックスの場合、画像および音は、それぞれのオーディオおよびビデオ出力から出力される。
【００４５】
デジタルＴＶ受信機はまたは、その実行環境（１１６）内で対話型アプリケーション（１１８）を復号しかつ実行する。実行環境は、ＭＨＰ、Ｇｉｎｇａなどの対話型デジタルＴＶミドルウェアとすることができる。対話型アプリケーション（１１８）は、実行環境（１１６）で利用可能なＡＰＩを使用して、ＭＰＥＧ−２トランスポートストリームから、視聴覚コンテンツおよび／またはカプセル化データ（１２０）で構成されているＭＰＥＧ−２プライベートセクションを抽出する。これらＡＰＩの例として、Ｇｌｏｂａｌｌｙ  Ｅｘｅｃｕｔａｂｌｅ  ＭＨＰ（ＧＥＭ）仕様、またはＡＢＮＴ  ＮＢＲ  １５６０６−６において指定されるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇに基づくシステムにおいて利用可能なＡＰＩのｏｒｇ．ｄａｖｉｃ．ｍｐｅｇ．ｓｅｃｔｉｏｎｓが挙げられ得る。
【００４６】
デジタルＴＶ受信機（１１２）はＬＡＮ（１２２）に接続される必要がある。このＬＡＮ（１２２）は、有線（例えばイーサネット）、無線（ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎネットワークまたは同様のものなど）、または、有線および無線の両方のタイプの組み合わせとすることができる。
【００４７】
また、ユーザデバイス（１２６）は、視聴覚コンテンツおよび／またはデータを受信しかつ再現するために、デジタルＴＶ受信機（１１２）と同じＬＡＮ（１２２）で接続されなければならない。例として、ユーザデバイス（１２６）は、タブレット、スマートフォン、パーソナルコンピュータ、または、ＬＡＮ（１２２）に接続でき、かつ、画面、および／または、スピーカーまたはヘッドフォンなどのオーディオ出力を有する任意の他のデバイスとすることができる。いくつかの実装形態では、ユーザデバイス（１２６）は、本発明によってこれらデバイスによるものである動き、機能性および通信プロトコルを実装するために１つまたは複数のアプリケーションをホストとして処理しかつ実行できる。
【００４８】
デジタルＴＶ受信機（１１２）で実行されている対話型アプリケーション（１１８）、およびユーザデバイス（１２６）は、共通のデータネットワーク用通信プロトコルを使用して互いに通信する。かかるデータネットワーク用通信プロトコルは、全てのユーザデバイスおよび対話型アプリケーションによって実装される。データネットワーク用通信プロトコルは、対話型アプリケーションおよびユーザデバイスの発見、視聴覚コンテンツ通知、データ通知、視聴覚コンテンツ要求、データ要求、視聴覚コンテンツ配信、およびデータ配信のための機構を含む。
【００４９】
データネットワーク用通信プロトコルを使用して、ユーザデバイス（１２６）は、
ａ．対話型アプリケーションの存在を認識し、
ｂ．視聴覚コンテンツの利用可能性を認識し、
ｃ．データの利用可能性を認識し、
ｄ．視聴覚コンテンツの配信を対話型アプリケーション（１１８）に要求し、
ｅ．データの配信を対話型アプリケーション（１１８）に要求し、
ｆ．視聴覚コンテンツ（１２４）を対話型アプリケーション（１１８）から受信し、
ｇ．データ（１２４）を対話型アプリケーション（１１８）から受信する。
【００５０】
ユーザデバイス（１２６）は、それら各々の画面および／またはスピーカーにおいて、受信された視聴覚コンテンツおよび／またはデータを復号し、処理し、再現する。
【００５１】
技術的解決策−対話型アプリケーションとユーザデバイスとの間のデータネットワーク用通信プロトコル
デジタルＴＶ受信機（１１２）およびユーザデバイス（１２６）において実行される対話型アプリケーション（１１８）は、それらの間の通信を可能にするデータネットワーク用通信プロトコルを実装しなければならない。対話型アプリケーション（１１８）が実行される全てのユーザデバイス（１２６）およびデジタルＴＶ受信機（１１２）は同じＬＡＮ（１２２）に接続される。データネットワーク用通信プロトコルは、とりわけ、図６に示されるような以下の機構を企図する場合がある。
ａ．発見（５０４）：対話型アプリケーション（５００）およびユーザデバイス（５０２）が同じＬＡＮに接続される時に互いの存在を認識できるようにするための機構。
ｂ．視聴覚コンテンツ通知（５０６）：ユーザデバイス（５０２）が、対話型アプリケーション（５００）を通して提供されかつユーザデバイスによって消費されることになる視聴覚コンテンツの利用可能性を認識できるようにする機構。
ｃ．データ通知（５０８）：ユーザデバイス（５０２）が、対話型アプリケーション（５００）を通して提供されかつユーザデバイスによって消費されることになるデータの利用可能性を認識できるようにする機構。
ｄ．視聴覚コンテンツの要求（５１０）：ユーザデバイス（５０２）が視聴覚コンテンツを配信するように対話型アプリケーション（５００）に要求できるようにする機構。
ｅ．データの要求（５１２）：ユーザデバイス（５０２）がデータを配信するように対話型アプリケーション（５００）に要求できるようにする機構。
ｆ．視聴覚コンテンツの配信（５１４）：対話型アプリケーション（５００）からユーザデバイス（５０２）へ視聴覚コンテンツを配信するための機構。
ｇ．データの配信（５１６）：対話型アプリケーション（５００）からユーザデバイス（５０２）へデータを配信するための機構。
【００５２】
データネットワーク用通信プロトコルは、ＵＤＰデータグラム（二地点間ＵＤＰデータグラム、一地点対多地点ＵＤＰデータグラム、および放送ＵＤＰデータグラム）およびＴＣＰ接続の任意の組み合わせを使用したメッセージ交換として実装可能である。
【００５３】
本発明による種々の実装形態では、通信プロトコルは、対話型アプリケーション（５００）によって、ユーザデバイス（５０２）によって、またはそれらのうちの任意の１つによって開始されるように設計されてよい。
【００５４】
視聴覚コンテンツおよび／またはデータを配信するための機構の実装形態は、ＭＰＥＧ−２トランスポートストリームから抽出される未処理のＭＰＥＧ−２プライベートセクションの配信を考慮することができる。あるいは、視聴覚コンテンツおよび／またはデータを配信するための機構の実装形態は、ＭＰＥＧ−２トランスポートストリームから抽出されるＭＰＥＧ−２プライベートセクションを復号／処理し、かつ、ＭＰＥＧ−２プライベートセクションのヘッダーおよびＣＲＣを廃棄して、カプセル化された視聴覚コンテンツおよび／またはデータのみをユーザデバイス（５０２）に配信するために、デジタルＴＶ受信機で実行されている対話型アプリケーション（５００）を考慮することができる。
【００５５】
ユーザデバイスの場合、記載される、データネットワーク用通信プロトコルの実装形態は、ユーザデバイスに内蔵可能であるか、ユーザデバイスにおいてインストールされかつ実行される１つまたは複数のユーザアプリケーションによって実装可能である。
【００５６】
技術的解決策−全般的な利点
ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのフィールドおよびｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒのフィールドの値を定めるために使用される方法は、視聴覚コンテンツ（２０８）および／またはデータ（２１０）の新しいチャンクまたはパッケージの継続的な配信を可能にする。ＭＰＥＧ−２プライベートセクションでカプセル化されたかかるチャンクおよびパッケージ（２１４）の有効期限は、一般的に非常に短く、ユーザデバイス（１２６）によって即座に処理されかつ廃棄されることが考えられる。ユーザデバイス（１２６）が利用可能ではないか視聴覚コンテンツの配信を要求していない場合、対話型アプリケーション（１１８）はかかるチャンクまたはパッケージを即座に廃棄する。このために、本発明による方法はまた、ライブ視聴覚コンテンツ放送に適用可能である。
【００５７】
実施例
以降、上記で詳述されるような、本発明の方法、デバイス、プロトコル、および対話型アプリケーションの実装例が論証される。しかしながら、このような実施例は、他の形式の実装形態が当業者には想起可能であるため、本発明の範囲および限界を限定するものと考えられるべきではない。
【００５８】
実装例−放送側
実施例１−ＲＴＰストリームを使用した視聴覚コンテンツの符号化
放送システムは、ブラジルのデジタルＴＶシステムＩＳＤＢ−Ｔに従って構築され、かつ、局の伝送ワークフローに容易に統合される。
【００５９】
メインＴＶコンテンツは、Ｈ．２６４およびＭＰＥＧ−４  ＡＡＣそれぞれの符号化方式を使用したビデオおよびオーディオストリームとすることができ、クローズドキャプションも含まれ得る。電子番組ガイド（ＥＰＧ）用のデータ、および他のサービス情報（ＳＩ）メタデータは、ＡＢＮＴ  ＮＢＲ  １５６０３の規格に従って生成できかつ含まれ得る。
【００６０】
対話型アプリケーションは、Ｇｉｎｇａミドルウェア規格（ＡＢＮＴ  ＮＢＲ  １５６０６）に従って開発でき、ＡＢＮＴ  ＮＢＲ  １５６０６−６で指定されるＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇを使用して、ＭＰＥＧ−２プライベートセクションをデジタルＴＶ信号放送に含まれるＭＰＥＧ−２トランスポートストリームから抽出することができる。データネットワーク用通信プロトコルは、Ｇｉｎｇａミドルウェア規格（ＡＢＮＴ  ＮＢＲ  １５６０６−４）にも含まれる、Ｐｅｒｓｏｎａｌ  Ｂａｓｉｓ  Ｐｒｏｆｉｌｅ  １．２．１で指定されるｊａｖａ．ｎｅｔパッケージによって提供されるＡＰＩで実装できる。
【００６１】
対話型アプリケーションエンコーダデバイスは、ＤＳＭＣＣオブジェクトカルーセルプロトコルでＧｉｎｇａアプリケーションを符号化するために使用されるＧｉｎｇａ対話式プレイアウトデバイスで実装されてよい。
【００６２】
ＭＰＥＧ−２トランスポートストリームの多重化および放送は、従来のＩＳＤＢ−ＴデジタルＴＶ放送で既に使用されているのと同じ機器を使用して行われ得る。
【００６３】
コンテンツ制作プロセスによってもたらされるユーザデバイスのための視聴覚コンテンツは、ＦｕｌｌＨＤビデオおよびオーディオストリームとすることができ、事前録画またはライブ放送でき、ビデオおよびオーディオそれぞれに対して、Ｈ．２６４およびＭＰＥＧ−４  ＡＡＣの符号化方式を使用して符号化可能である。ビットレートは、ＦｕｌｌＨＤフォーマットに対する高品質放送を可能にする任意の値を有することができる（例えば、１３Ｍｂｐｓ）。
【００６４】
トランスコーダデバイスは、ＦｕｌｌＨＤビデオを、ユーザデバイスによって再現されるのに適した解像度、符号化、ビットレート、およびフレームレートに再符号化する（例えば、７２０×３６２、Ｈ．２６４、１５ｆｐｓ）。同様に、オーディオは、ユーザデバイスにおいて再生されるのに適切なフォーマット、ビットレート、サンプルレート、および符号化に再符号化される（例えば、ＭＰＥＧ−４  ＡＡＣ  ＨＥ）。全ビットレートは５００Ｋｂｐｓに低減される。適応させたストリームは、ＲＴＰパッケージおよびＲＴＰ制御パッケージで構成されている、ＲＴＰストリームとしてＲＴＰ／ＲＴＳＰプロトコルを使用してトランスコーダデバイスによって生成される。トランスコーダデバイスはまた、ＲＴＰセッション記述子のタイプのデータ構造を生成する。
【００６５】
ＭＰＥＧ−２プライベートセクションカプセル化デバイスは、トランスコーダデバイスによって生成された、ＲＴＳＰストリームパッケージ、ＲＴＰ制御パッケージ、およびＲＴＰセッション記述子を受信し、かつ、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールドにおいてＲＴＰ／ＲＴＳＰパッケージを加えてＭＰＥＧ−２プライベートセクションを生成する。生成されたＭＰＥＧ−２プライベートセクションは、ＭＰＥＧ−２トランスポートストリームパケットのシーケンスとしてＭＰＥＧ−２トランスポートストリームマルチプレクサに転送され、最終的に、デジタルＴＶ信号放送に挿入される。
【００６６】
実施例２−ＭＰＥＧ−２トランスポートストリームのストリームを使用した視聴覚コンテンツの符号化
実施例１から導き出される他の実装例では、トランスコーダデバイスは、ＦｕｌｌＨＤビデオを、ユーザデバイスによって再生されるのに適した解像度、コード化、ビットレート、およびフレームレートに再符号化する（例えば、７２０×３６２、Ｈ．２６４、１５ｆｐｓ）。同様に、オーディオは、ユーザデバイスにおいて再生されるのに適切なフォーマット、ビットレート、サンプルレート、および符号化に再符号化される（例えば、ＭＰＥＧ−４  ＡＡＣ  ＨＥ）。全ビットレートは５００Ｋｂｐｓに低減される。適応させたストリームは、ストリームを復号するために必要とされるＰＳＩを含む、ＭＰＥＧ−２トランスポートストリームのシーケンスで構成されているストリームとしてＭＰＥＧ−２トランスポートストリームプロトコルを使用してトランスコーダデバイスによって生成される。
【００６７】
ＭＰＥＧ−２プライベートセクションカプセル化デバイスは、トランスコーダデバイスによって生成されるＭＰＥＧ−２トランスポートストリームパケットのシーケンスのストリームを受信し、かつ、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅのフィールドにおいてＭＰＥＧ−２トランスポートストリームパケットを加えてＭＰＥＧ−２プライベートセクションを生成する。生成されたＭＰＥＧ−２プライベートセクションは、ＭＰＥＧ−２トランスポートストリームパケットのシーケンスとしてＭＰＥＧ−２トランスポートストリームマルチプレクサに転送され、最終的に、デジタルＴＶ信号放送に挿入される。
【００６８】
実装例−受信側
デジタルＴＶ受信機の実装例として、ＡＢＮＴ  ＮＢＲ  １５６０６に従ったＧｉｎｇａ対話型ミドルウェアサポートも含むＩＤＳＢ−ＴデジタルＴＶサービスをチューニングしかつ復号することができ、イーサネットインターフェイスまたはＷｉ−ＦｉによってＬＡＮに接続できるＴＶ装置またはセットトップボックスのどちらかが考えられ得る。
【００６９】
前の節で説明したように、インストールされ、かつ、ＩＳＤＢ−ＴデジタルＴＶ信号放送で放送されているＧｉｎｇａ対話型アプリケーションによって実施される同じデータネットワーク用通信プロトコルを実装するアプリケーションを実行している、任意のユーザのスマートフォンまたはタブレットなどの、使用できる多くのユーザデバイスがあることは強調されるべきである。このアプリケーションは、ＭＰＥＧ−２プライベートセクションでカプセル化されて配信されている視聴覚コンテンツをユーザが選択しかつ再現することができるようにするユーザインターフェイスを有することができる。通常、この機能性は、第二画面アプリケーションといったより一層複雑なアプリケーションの一部とすることが可能である。
【００７０】
実装例−対話型アプリケーションとユーザデバイスとの間のデータネットワーク用通信プロトコル
対話型アプリケーションは、Ｇｉｎｇａミドルウェア仕様、ＡＢＮＴ  ＮＢＲ  １５６０６規格に従って開発できる。データネットワーク用通信プロトコルは、ブラジルＡＢＮＴ  ＮＢＲ  １５６０６−４規格のように、Ｇｉｎｇａミドルウェア仕様の一部でもあるＰｅｒｓｏｎａｌ  Ｂａｓｉｓ  Ｐｒｏｆｉｌｅ１．２．１において指定されるｊａｖａ．ｎｅｔパッケージで利用可能なＡＰＩで実装できる。
【００７１】
ユーザデバイスで実行されるアプリケーションの場合、データネットワーク用通信プロトコルは、かかるプラットフォーム（例えば、ｉＯＳおよびアンドロイド）で利用可能なネットワークアクセスＡＰＩを使用して実装できる。
【００７２】
この例では、発見機構は、図６のａに示されるように、１０秒ごとに放送ＵＤＰデータグラムとしてメッセ−ジを送信する対話型アプリケーション（６００）によって実装されてよい。
【００７３】
この例では、視聴覚コンテンツおよびデータ通知機構は、図６のａに示されるように、対話型アプリケーション（６００）が、１０秒ごとに放送ＵＤＰデータグラムとして視聴覚コンテンツおよび利用可能なデータについての情報ならびに詳細で構成されているメッセージを送信するように実装できる。
【００７４】
視聴覚コンテンツ要求機構およびデータ要求機構は、図６のｂに示されるように、ユーザデバイス（６０２）において実行されるアプリケーションが、二地点間ＵＤＰデータグラムとして、対話型アプリケーション（６００）へ、通知された視聴覚コンテンツおよび／またはデータの配信を要求するメッセージ（６１２）を送信するように実装可能である。それぞれのユーザデバイスは、５秒ごとにこのメッセージ（６１２）を送信しなければならない。対話型アプリケーション（６００）がある一定時間（例えば１０秒）に所与のユーザデバイス（６０２）からのこのメッセージ（６１２）の受信を停止する場合、対話型アプリケーション（６００）は、ユーザデバイス（６０２）が視聴覚コンテンツおよび／またはデータの受信にもはや関心がなく、この所与のユーザデバイス（６０２）への配信を停止しようとしていることを推定する。
【００７５】
視聴覚コンテンツ配信機構およびデータ配信機構は、図６のｃに示されるように、対話型アプリケーション（６００）がかかる配信を前に要求していたそれぞれのユーザデバイス（６０２）に対して視聴覚コンテンツおよび／またはデータで構成されているメッセージ（６１６）を送信するように実装できる。これらのメッセージ（６１６）は二地点間ＵＤＰデータグラムとしてＬＡＮを通して送信できる。メッセージ（６１６）は、ＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇによってＭＰＥＧ−２トランスポートストリームから抽出されたそれぞれのＭＰＥＧ−２プライベートセクション（６１４）に対して送られたものとすることができ、このようなＭＰＥＧ−２プライベートセクションのコンテンツ全てを伝えることができる。
【００７６】
この解決策の他の実装例では、視聴覚コンテンツ要求機構およびデータ要求機構は、ユーザデバイスにおいて実行されるアプリケーションが対話型アプリケーションとのＴＣＰ接続を確立するように実装可能である。このＴＣＰ接続が確立されると、視聴覚コンテンツおよび／またはデータ配信はＴＣＰ接続がオープンされる時間で生じることになる。この場合、対話型アプリケーションは、このＴＣＰ接続によって視聴覚コンテンツおよび／またはデータで構成されているメッセージを送信することになる。メッセージは、ＡＰＩのｃｏｍ．ｓｕｎ．ｄｔｖ．ｆｉｌｔｅｒｉｎｇによってＭＰＥＧ−２トランスポートストリームから抽出されたそれぞれのＭＰＥＧ−２プライベートセクションに対して送られたものとすることができ、このようなＭＰＥＧ−２プライベートセクションのコンテンツ全てを伝えることができる。ＴＣＰ接続は、視聴覚コンテンツおよび／またはデータの配信に割り込まざるを得ないことを対話型アプリケーションに示して、ユーザデバイスによってクローズされてよい。
【図１】
0006679500.tif 000002
【図２】
0006679500.tif 000003
【図３】
0006679500.tif 000004
【図４】
0006679500.tif 000005
【図５】
0006679500.tif 000006
【図６】
0006679500.tif 000007